msl.org.pl · Web viewWord, PDF) oraz fotografii i multimediów, także możliwość tworzenia...

Dotyczy projektu pn. „Cyfrowe udostępnianie zasobów Muzeum Sztuki w Łodzi” współfinansowanego w ramach Działania 2.3 Cyfrowa dostępność i użyteczność informacji sektora publicznego, Poddziałanie 2.3.2 Cyfrowe udostępnienie zasobów kultury, oś priorytetowa II E-administracja i otwarty rząd Programu Operacyjnego Polska Cyfrowa

Załącznik nr 1 do OPZ

Architektura Rozwiązania.Architektura Rozwiązania musi być zgodna z założeniami Rozwiązania

wynikającymi ze Studium Wykonalności projektu pn. „Cyfrowe udostępnienie zasobów Muzeum Sztuki w Łodzi”, które stanowi Załącznik nr 2 do OPZ.Ogólny opis architektury Rozwiązania.

System musi funkcjonować na infrastrukturze serwerowo-macierzowej dostarczonej przez Wykonawcę, która musi zapewnić wymagania jakościowe w pkt. 10.3.d OPZ. System będzie się składał z Ewidencji Zbiorów Muzealnych, zbudowanej z modułów opisanych w dalszej części tego Załącznika do OPZ. Ta ewidencja będzie stanowiła podstawę działania całego Systemu. System będzie także zawierał komponent - Repozytorium Zdigitalizowanych Dzieł. W tym module będą przechowywane wszystkie kopie cyfrowe poszczególnych obiektów sztuki. Zgromadzone w Repozytorium dane (pliki graficzne, obrazy 2D, obrazy 3D, filmy, pliki dźwiękowe itp.) będą za pomocą API dostępne w Ewidencji Zbiorów Muzealnych oraz w Portalu Internetowym, oraz udostępniane w API publicznym.

W ramach realizacji Zamówienia, portal internetowy Muzeum Sztuki w Łodzi nie będzie modyfikowany w zakresie wizualnym, a także architektonicznym. Realizacja Systemu w ramach Zamówienia musi zapewnić zasilenie (poprzez API) istniejącej w Portalu bazy danych zgodnie ze specyfikacją struktury bazy danych tego Portalu.

Jednym z istotnych elementów Systemu jest również moduł publicznego API, za pomocą którego dane z Systemu będą udostępniane zarówno zainteresowanym osobom, jak i do istniejących repozytoriów w tym np. do Systemu KRONIK@. Moduł publicznego API musi być uruchomiony na dedykowanym serwerze w wydzielonej strefie bezpieczeństwa sieci, tak aby zapewnić bezpieczeństwo Systemu.

Szczegółową architekturę Rozwiązania, model przepływu danych pomiędzy modułami, zakres wymaganych danych opisujących eksponat, procesy

1


zarządzania danymi zostaną ustalone podczas realizacji Etapu I w Projekcie Rozwiązania.

2


Powyższy diagram prezentuje ogólne odzwierciedlenie komunikacji pomiędzy komponentami. Zawiera istniejący obecnie Portal on-line, który należy dostosować, aby możliwa była poprawna integracja, nowe oprogramowanie Systemu Muzealnego ewidencji zdigitalizowanych zasobów - stanowiące nową główną bazę danych, moduł repozytorium zdigitalizowanych dzieł - stanowiące bazę danych plików zdigitalizowanych i źródłowych, planowane Publiczne API - stanowiące kontrolowany i publiczny dostęp do obiektów, przez które będzie udostępniał informacje o obiektach, w wersji web oraz umożliwi pewne ograniczone dostępny do plików źródłowych z Repozytorium Zdigitalizowanych Dzieł.

3


wymaganie opis

Oprogramowanie Systemu Muzealnego do Ewidencji Zbiorów Muzealnych - Ogólne

OSM.1 Rozbudowana platforma do zarządzania zbiorami (obiektami w inwentarzu, różnych księgach i rejestrach pomocniczych – kopie archiwizacyjne i ekspozycyjne, rekonstrukcje, multimedia). Oprogramowanie udostępniające otwarte API.

OSM.2 Zarządzanie kolekcją i dostosowane do obsługi dzieł w tradycyjnych technikach, jak i dzieł audiowizualnych (w oparciu o wypracowane i omówione z muzeum potrzeby, w tym możliwość zarządzania ich kopiami archiwizacyjnymi, dystrybucyjnymi, czyli ekspozycyjnymi, wglądówkami oraz dokumentami z nimi związanymi (umowy wypożyczenia, licencje, protokoły)).

OSM.3 Obsługa dokumentów dotyczących dzieł sztuki (umowy wypożyczenia, licencje, protokoły itp.).

OSM.4 Zarządzanie organizacją wystaw np. pracą z bieżącymi i nadchodzącymi projektami muzealnymi, czyli rezerwacją obiektów własnych i zarządzaniem obiektami wypożyczanymi.

OSM.5 Powiadamianie użytkowników (np. mailowe) i włączanie poszczególnych użytkowników w procesy.

OSM.6 Zarządzanie multimediami obejmujące kompleksową obsługę procesu załączania kopii cyfrowych/odwzorowań dzieł w kolekcji, kontrolowania praw ich udostępniania (umowy, licencje) oraz zarządzania kopiami wzorcowymi, a także umożliwienie zarządzanie kopiami cyfrowymi archiwalnych wizerunków (np. stare wizerunki prac) i historią zbiorów (możliwość archiwizacji danych na temat prac zaginionych).

OSM.7 Sporządzanie rozbudowanych statystyk zarówno dotyczących samych zbiorów, procesów związanych z zarządzaniem zbiorami,

4


jak i związanych z ich udostępnianiem online na portalu.

OSM.8 Sporządzanie rozbudowanych opisów konserwatorskich wraz z konserwatorską dokumentacją fotograficzną.

OSM.9 W celu udostępniania informacji o zbiorach szerokiemu odbiorcy, system musi być również zintegrowany z portalem „zasoby.msl.org.pl” i umożliwiać udostępnianie wskazanych treści oraz multimediów 2D i 3D w portalu.

OSM.10 System musi mieć możliwość ograniczania dostępu do widoków i edycji pól dla poszczególnych użytkowników (nadawanie uprawnień użytkownikom).

OSM.11 System musi mieć opcję autozapisu danych, w określonym czasie definiowanym w Systemie w trakcie pracy użytkownika, co zabezpieczy przed ich utratą w czasie pracy.

OSM.12 System musi uwzględniać wyszukiwanie proste i zaawansowane.

OSM.13 System musi zapewnić wielojęzyczność, przez co Zamawiający rozumie możliwość zapisania poszczególnych cech opisujących obiekt w Ewidencji Zbiorów Muzealnych w dwóch językach.

OSM.14 System musi zostać wykonany w architekturze 3-warstwowej, w której klient łączy się z serwerem aplikacji poprzez przeglądarkę internetową, a procesy związane z przetwarzaniem danych są realizowane przez serwer aplikacyjny.Zamawiający nie uzna, że System został wykonany w architekturze 3-warstwowej, jeżeli użytkownik będzie łączyć się z serwerami aplikacji z wykorzystaniem rozwiązań terminalowych jako metody dostępu użytkownika do serwera aplikacji.

OSM.15 System musi posiadać interfejsy WebService do komunikacji z innymi systemami jako podstawowy model integracji z innymi systemami.

5


OSM.16 Poprzez interfejsy WebService System musi realizować funkcjonalność aktualizacji własnych danych oraz udostępniać dane do innych systemów.

OSM.17 Interfejsy WebService muszą zapewniać funkcjonalność szyfrowania transmisji danych przy wykorzystaniu certyfikatów X.509.

OSM.18 Zakres danych wymienianych do i z Systemu poprzez WebService-y zostanie uzgodniony w Projekcie Rozwiązania.

OSM.19 Komunikaty o ostrzeżeniach, błędach, informacjach w Oprogramowaniu Aplikacyjnym Standardowym i Oprogramowaniu Dedykowanym prezentowane muszą być w języku polskim.

OSM.20 System musi zapewnić pełną spójność danych we wszystkich Modułach.

OSM.21 Pliki konfiguracyjne Systemu nie mogą być szyfrowane i muszą być dostępne do samodzielnej zmiany przez Zamawiającego, w przeciwnym przypadku Wykonawca musi przekazać uprawnionym osobom ze strony Zamawiającego wszystkie niezbędne do deszyfracji i wprowadzania zmian narzędzia (oprogramowanie i pełny opis metod działania w Dokumentacji administratora).

OSM.22 Oprogramowanie Aplikacyjne nie może przechowywać loginów i haseł w plikach konfiguracyjnych.

OSM.23 Oprogramowanie Aplikacyjne Standardowe oraz Oprogramowanie Dedykowane muszą posiadać funkcjonalność, która zapewni, że użytkownik z uprawnieniami Administratora Systemu będzie miał dostęp do słownika loginów i haseł wykorzystywanych przez Oprogramowanie Aplikacyjne Standardowe lub Oprogramowanie Dedykowane do łączenia się z innymi systemami.

OSM.24 System musi zapewniać jednolity interfejs użytkownika dla wszystkich obszarów funkcjonalnych, a funkcje powtarzające się w różnych Modułach powinny być dostępne dla użytkownika pod taką

6


samą nazwą w menu i pod takim samym klawiszem skrótu, zapewniając w maksymalny sposób jednolitość obsługi.

OSM.25 System musi zapewnić dostęp do wszystkich danych Systemu transakcyjnego w czasie rzeczywistym.

OSM.26 Porządek sortowania musi uwzględniać alfabet polski (A, Ą, B, C, Ć… a nie A, B, C … Z, Ą, Ę, Ć). Porządek sortowania (w kolejności od najmniejszej do największej lub odwrotnie) numerów liczb zapisanych jako tekst musi być identyczna jak w przypadku liczb.

OSM.27 Musi być zachowana jednolitość i jednoznaczność ikon, przycisków itp. w całym Systemie.

OSM.28 Oprogramowanie Aplikacyjne powinno uniemożliwiać jednoczesną edycję danych przez więcej niż jednego użytkownika. W przypadku próby edycji danych przez kolejnego użytkownika powinien być wyświetlany odpowiedni komunikat, w tym może być wyświetlana informacja o użytkowniku, który aktualnie dokonuje ich edycji.

OSM.29 Pola wymaganych danych muszą być oznaczone w sposób wyraźny

i jednolity dla całego Oprogramowania oraz wyraźnie oddzielone od pól opcjonalnych.

OSM.30 Pola danych nieedytowalnych powinny być oznaczone w sposób wyraźny i jednolity dla całego Oprogramowania. Informacje w nich wyświetlane nie mogą podlegać edycji.

OSM.31 Oferowane Rozwiązanie musi poprawnie funkcjonować na stacjach roboczych użytkowników, którzy pracują w profilu indywidualnym bez uprawnień administratora stacji roboczej. Żaden z elementów oferowanego Systemu nie może wymagać do swojej poprawnej pracy posiadania uprawnień administratora na stacji roboczej użytkownika.

7


OSM.32 System musi mieć walidację poszczególnych pól w formularzach (tych, których jest możliwość i zasadność).

OSM.33 System musi zapewnić możliwość parametryzacji tworzonych raportów i analiz poprzez zastosowanie filtrów ograniczających, agregatów oraz innych mechanizmów.

OSM.34 System musi zapewnić możliwość wykorzystania predefiniowanych wzorców raportów/analiz/zestawień.

OSM.35 System musi zapewnić możliwość tworzenia i zapisywania własnych raportów przez użytkowników niebędących Administratorami Systemu.

OSM.36 Słowniki w Systemie muszą być wspólne dla wszystkich modułów oraz komponentów. System musi zapewniać, że modyfikacja słownika następuje tylko w jednym miejscu, a synchronizacja do pozostałych miejsc jest automatyczna, on-line i równolegle przebiegająca.

OSM.37 System musi zabezpieczać dane przed przypadkowym usunięciem – generować ostrzeżenia o nieodwracalnym usunięciu danych.

OSM.38 System musi uniemożliwiać usunięcie danych np. słownikowych, jeśli zostały one już przypisane do innych danych.

OSM.39 System musi zapewniać automatyczne sprawdzanie poprawności wprowadzanych do Systemu danych typu NIP, PESEL, REGON razem ze sprawdzaniem sumy kontrolnej. Sprawdzanie poprawności numeru NIP dot. wszystkich krajów Unii Europejskiej. System musi być niewrażliwy na różne sposoby zapisu numerów NIP (np. z separatorami lub bez).

OSM.40 System musi uwzględniać skróty klawiszowe funkcjonujące w środowisku Windows.

OSM.41 System musi zapewnić możliwość eksportu wszystkich widoków ekranowanych i wygenerowanych raportów do następujących

8


formatów: .txt, .xlsx, .docx, .pdf, .xml, .rtf oraz .csv.

OSM.42 System musi zapewniać użytkownikowi dostęp do wbudowanej pomocy kontekstowej dostępnej z każdego ekranu w Systemie. Pomoc kontekstowa musi być w języku polskim i zawierać wszystkie informacje potrzebne przeszkolonemu użytkownikowi w celu poprawnej pracy w Systemie.

OSM.43 Cała komunikacja pomiędzy klientem a serwerem musi być szyfrowana za pomocą certyfikatów SSL.

OSM.44 Modyfikacje wierszy danych w Systemie nie mogą blokować niezależnych odczytów, odczyt wierszy nie może ich blokować do celów modyfikacji. Spójność odczytu musi gwarantować uzyskanie rezultatów zapytań odzwierciedlających stan danych z chwili jego rozpoczęcia, niezależnie od modyfikacji przeglądanego zbioru danych.

OSM.45 System musi zapewnić możliwość dodania wielu załączników do jednego obiektu z możliwością przypisywania ich do określonego pola opisu oraz ich wersjonowania o ile zachodzi taka potrzeba.

OSM.46 System musi zapewniać funkcjonalność wklejania (ze schowka systemowego) treści do pól formularzy oraz kopiowania (do schowka systemowego) z pól na formularzu.

OSM.47 System musi dawać możliwość wprowadzania czcionek w innych niż łaciński alfabetach - musi istnieć łatwy dostęp do znaków specjalnych w każdym miejscu, gdzie wprowadzany jest jakikolwiek tekst.

OSM.48 Historia wprowadzanych zmian powinna być zapisywana i możliwa do zobaczenia przez uprawnionych użytkowników.

OSM.49 Musi powstać instrukcja w języku polskim do obsługi oprogramowania Systemu Muzealnego do Ewidencji Zbiorów Muzealnych.

9


OSM.50 System musi zapewnić poprawną integrację z Systemem KRONIKA@ zgodnie z wymaganiami Systemu KRONIK@ zarówno pod względem technicznym oraz zakresu udostępnianych danych.

OSM.51 Interfejsy API w Systemie muszą być zgodne ze standardem interfejsów otwartych danych dostępnym pod adresem https://dane.gov.pl/pl/article/785,standard-interfejsu-programistycznego-aplikacji-api-final.

OSM.52 System umożliwi bezpieczne połączenie zdalnych użytkowników z użyciem protokołu SSL (protokół SSL 3.0 / TLS).

OSM.53 System musi zapewnić audyt systemowy - udokumentowanie historii czynności związanych z zasobami i dostępów do zasobów – audyt systemowy musi odbywać się automatycznie. System musi zapewnić raporty o zmianach dokonywanych na danych osobowych wraz z informacją, kiedy i kto jej dokonał.

OSM.54 System musi zapewnić generowanie raportu, o danych osobowych zgromadzonych dla danego kontrahenta.

OSM.55 Dokumenty umów prawno-autorskich lub własnościowych (darowizny, depozytowe, kupna-sprzedaży) powinny być możliwe do zobaczenia zarówno wylistowane razem (z możliwością wyszukiwania po nazwie plików umów), jak i z poziomu danego rekordu, którego dana umowa dotyczy. Podłączenie jednej umowy pod dany rekord, musi powodować automatyczne umieszczenie jej na liście umów prawno-autorskich i własnościowych, a dopinanie umowy do rekordu winno być możliwe zarówno poprzez podłączenie nowej umowy, jak i wyszukanie istniejącej w systemie z listy. System nie powinien pozwalać na podłączanie umów o tych samych nazwach plików (bez dublażu). Szczegóły tej funkcjonalności muszą być dopracowane z Zamawiającym podczas Etapu I.

10


Moduł Obiekty

Obiekty.1 Moduł obiektów jest kluczowym modułem zbiorów MS. Połączony z Multimediami i pośrednio z informacjami zawartymi w Repozytorium Zdigitalizowanych Dzieł, posiadający wersję API Obiektów (wizerunki prac i zdigitalizowane wersje dzieł audiowizualnych w różnych formatach). Moduł obiektów ma umożliwiać m.in.: zmiany widoku wyświetlanych pól w widoku obiektu, powielanie obiektów (rekordu w bazie - dla ułatwienia i przyspieszenia wytworzenia podobnego obiektu), tworzenia powiązań obiektów, tworzenia przemieszczeń obiektów (np. ruch wewnętrzny), tworzenia ocen stanu zachowania, tworzenia opisów, dodawania tłumaczeń, przełączanie obiektów (poprzedni/następny) w trybie przeglądania, wyświetlenia historii zmian, tworzenia wydruków.

Obiekty.2 Moduł ma zawierać różnorodne dane na temat dzieł w kolekcji MSŁ. Umożliwiać zarządzanie, przeglądanie i edycję danych. Posiadać zaawansowane pełnotekstowe wyszukiwarki i zarządzanie procesami związanymi ze zbiorami.

Obiekty.3 System musi pozwolić na obsługę procesów wewnętrznych MSŁ, które funkcjonują z wykorzystaniem danych z modułu obiektów z możliwością powiadamiania określonych użytkowników lub grup użytkowników o potrzebie realizacji kolejnego etapu procesu.

Obiekty.4 System musi zapewnić generowanie ksiąg inwentarzowych i rejestrów pomocniczych.

Obiekty.5 Moduł będzie umożliwiał przeprowadzenie zmian hurtowych, zaawansowanego filtrowania i wyświetlania obiektów, możliwość dodania w sposób szybki obiektu oraz w sposób szczegółowy obiektu.

Obiekty.6 Wyświetlanie wielu obiektów powinno być możliwe w kilku trybach

11


szczegółowości i w różnym układzie prezentacji danych.

Obiekty.7 Moduł w listach obiektów musi posiadać paginację, możliwość zaznaczania i odznaczania wielu obiektów, zmian hurtowych, tworzenia wydruków, wyświetlania statystyk, tworzenia rejestrów wyświetlonych obiektów, tworzenia rejestrów z zaznaczonych obiektów.

Obiekty.8 Moduł musi zapewniać funkcjonalność dołączania kopii cyfrowych z Repozytorium Zdigitalizowanych Dzieł i ich prezentację w interfejsie użytkownika.

Obiekty.9 Moduł musi zapewnić funkcjonalność importu przygotowanych kopii cyfrowych do Repozytorium Zdigitalizowanych Dzieł. Funkcja importu musi zapewniać hurtowe dodanie kopii cyfrowych do Repozytorium.

Obiekty.10 Moduł w ramach funkcjonalności hurtowego importu kopii cyfrowych musi pozwolić:

1. Dodawać jednocześnie wiele plików z wizualizacjami danego obiektu sztuki w ramach edycji danego obiektu w Module Obiekty.

2. Importowanie do Systemu jednocześnie wielu plików z wizualizacjami do wielu obiektów sztuki posiadających nadany numer inwentarzowy i na podstawie nazwy pliku (schemat nazewniczy zostanie ustalony w trakcie realizacji Etapu I) System automatycznie przypisze je (utworzy relacje) do właściwych rekordów opisujących obiekty sztuki – tak jakby były importowane zgodnie z pkt. 1 powyżej.

Obiekty.10 System po zaimportowaniu kopii cyfrowych do Repozytorium musi:1. Dla plików graficznych:a. Wykonać kopie o obniżonej rozdzielczości tzw. wglądówkę.b. Umieścić w strukturze Repozytorium wszystkie kopie cyfrowe w

celu przyporządkowania do właściwych folderów w strukturze plików Repozytorium (struktura folderów będzie uzgodniona w trakcie realizacji etapu pierwszego)

12


2. Dla plików tekstowych, dźwiękowych, filmowych:a. Umieścić w strukturze Repozytorium wszystkie kopie cyfrowe w

celu przyporządkowania do właściwych folderów w strukturze plików Repozytorium (struktura folderów będzie uzgodniona w trakcie realizacji etapu pierwszego)

b. Dla plików filmowych możliwość umieszczenia plików z napisami.

Obiekty.11 Moduł w trakcie importu kopii cyfrowych musi weryfikować pliki po nazwie i na podstawie nazwy przyporządkowywać do obiektów w Ewidencji Zbiorów Muzealnych. Schemat nazewnictwa plików będzie ustalony w trakcie realizacji I Etapu.

Obiekty.12 Za pomocą systemu w ramach modułu musi być też możliwość zarządzania repozytorium / archiwum kopii ekspozycyjnych, archiwizacyjnych filmowych, dźwięków i innych plików, gdzie będą obsługiwane różne formaty. Zarządzanie będzie się odbywało za pomocą Przeglądarki Repozytorium.

Obiekty.13 Moduł musi zapewnić dostęp do wizualizacji wglądówki dzieła audiowizualnego, szybkiego odsłuchu, możliwość pobrania kopii pliku w różnych formatach do celów np. Wypożyczenia (w tym dostęp do oryginalnych nieskompresowanych materiałów). Pobranie musi być możliwe tylko dla uprawnionych użytkowników. Dostęp do wglądówki, wglądówek dzieła musi być możliwy z poziomu modułu systemu.

Obiekty.14 Tworzenie nowego rekordu obiektu musi być możliwe poprzez wypełnianie pustej formatki, powielenie istniejącego rekordu obiektu w całości lub dla wybranych pól.

Obiekty.15 Moduł powinien umożliwiać wpisanie nieograniczonego datowania oraz nieograniczonej wartości dzieł (bez ograniczenia w podawanych kwotach, w ilości do 7 miejsc po przecinku). Wartości mogą być wyrażone w jednej lub wielu walutach.

13


Obiekty.16 Dane dla pól możliwych do zesłownikowania powinny być wprowadzane ze słownika, dla pozostałych pól dane wprowadzane są ręcznie.

Obiekty.17 Ze względu na zmienność danych w czasie, a zarazem z uwagi na konieczność zachowania danych historycznych, wykonawca opracuje i uzgodni z muzeum mechanizm zapisu danych historycznych (np. dawnych nazw historycznych, dawnych lokalizacji, dawnych numerów itd.).

Obiekty.18 Moduł zostanie wyposażony w narzędzia do hurtowej edycji danych (w tym numerów identyfikacyjnych), która będzie mogła być przeprowadzona na dowolnych, wskazanych przez użytkownika polach pojedynczego rekordu obiektu lub danego zbioru rekordów obiektów.

Obiekty.19 W module dla wybranych pól w rekordzie obiektu musi być możliwość zapisania sformatowanej treści za pomocą edytora WYSIWYG.

Obiekty.20 Moduł musi zapewniać dla każdego rekordu obiektu zapisywanie informacji o dowolnym typie zbiorów, jakie znajdują się w muzeum, w tym umożliwiać szczegółowy opis dzieł audiowizualnych i cyfrowych z uwzględnieniem ich specyfiki.Moduł musi cechować się możliwością dodania kolejnych pól i podpól oraz tworzenia dodatkowych relacji w przyszłości.W przypadku niektórych elementów opisu obiektów konieczne jest umożliwienie zarówno wprowadzanie danych o charakterze słownikowym, jak i opisowym (np. wydarzenia z polem słownikowanym i opisowym).Zestaw danych opisujących musi zawierać m.in. następujące typy danych i pola:1. Numer inwentarzowy;

14


2. Rodzaj księgi inwentarzowej;3. Bezwzględnie musi być możliwość wprowadzenia

przełamanego numeru dla zespołów i jeżeli zajdzie taka potrzeba – dla obiektów złożonych;

4. Musi istnieć możliwość zbiorczego nadawania numerów inwentarzowych dla zdefiniowanego zbioru (np. Zestawienia obiektów)

5. Musi pozwalać na dokumentowanie historii kolejno nadawanych obiektowi numerów ewidencyjnych;

6. Musi pozwalać na wprowadzanie numerów przełamanych, w tym numerów elementu od-do;

7. Musi podpowiadać kolejny numer, ale też pozwalać na wpisywanie „z ręki”;

8. Poza numerami w formie zgodnej z formą ustaloną w odpowiednim słowniku, system powinien pozwalać na wprowadzenie całkowicie dowolnego numeru identyfikacyjnego data wpisu;

9. Data wpisu obiektu do inwentarza;10. Data wykreślenia obiektu z inwentarza;11. Klasyfikacja inwentarzowa;12. Typ obiektu (pojedynczy, złożony, zespół);13. Liczba sztuk inwentarzowych;14. Liczba części;15. Inne numery ewidencyjne;16. Twórca;17. Pole dotyczące twórcy/wytwórni winno umożliwiać podanie

autorstwa (atrybucji) obiektu, zarówno jednostkowego, jak i zbiorowego;

18. Musi istnieć możliwość wskazania twórcy lub twórców zasadniczego(ych) spośród wielu twórców przypisanych do danego dzieła;

19. Tytuł;20. Inne nazwy i tytuły;21. Cykl, komplet;

15


22. Cechy charakterystyczne;23. Słowa kluczowe;24. Data powstania (także od-do):25. Musi istnieć możliwość opisania znaczenia daty lub wielu dat

względem każdej części dzieła, jeżeli składa się ono z części powstałych w różnym czasie;

26. Miejsce powstania/znalezienia;27. Musi być możliwość zobaczenia nazw alternatywnych

miejscowości i wyszukiwania po nich. Dla przykładu bułhak tworzył w wilnie w polsce w latach 20. I 30. Teraz to vilnius, litwa. Trzeba móc wyszukiwać po nazwach historycznych i aktualnych oraz powinna być możliwość ich załączania wg uznania użytkownika (czyli historyczna i aktualna, albo dwie historyczne i aktualna). Zawsze oprócz historycznej winna pojawiać się aktualna.

28. Rodzaj obiektu;29. Tworzywo;30. Technika;31. Wymiary ( w tym waga, czas itd.);32. Musi pozwalać na wprowadzenie dowolnych wymiarów do

obiektów, w tym wagi i innych charakterystyk obiektu, które można wyrazić miarą;

33. Musi istnieć wprowadzenia dowolnej liczby wymiarów do całego obiektu i dowolnej jego części / fragmentu;

34. Musi istnieć możliwość łączenia w grupy wielu wymiarów dotyczących tego samego aspektu (obiektu lub części / fragmentu); wymiary muszą być wyświetlane w połączeniu w grupy (np. Z ramą, bez ramy itd.);

35. Musi istnieć możliwość ustawiania sekwencji wymiarów i oznaczania jednego lub więcej wymiarów jako głównych (podstawowych);

36. Gabaryty;37. Wymiary uzupełniające;38. Dane dotyczące edycji (dzieło w edycji, czy unikat, czy edycja

16


limitowana, nielimitowana, edycja nieznana, nr edycji);39. Sygnatury;40. Napisy i znaki;41. Sposób i miejsce oznakowania;42. Opis fizyczny;43. Nota naukowa;44. Nota popularnonaukowa;45. Nota techniczna (w tym warunki ekspozycji, potrzebny sprzęt

itd.);46. Nota na portal (nota na stronę online);47. Określnie czy nota na portal gotowa do publikacji: tak/nie48. Publikacja noty na portal: tak/nie (funkcje hurtowe: powinna

być możliwość opublikowania wielu not naraz w zależności od wyliczonych numerów inwentarzowych)

49. Data pierwszej publikacji online rekordu (automatycznie)50. Uwagi odnośnie montażu pracy, sprzęt pomocniczy itd.;51. Dawne atrybucje;52. Proweniencja;53. Pochodzenie obiektu (sposób nabycia, dane darczyńcy,

sprzedającego itd., podstawa nabycia, data nabycia, numery wejściowe itd.);

54. Wartość (nabycia, inwentarzowa, ubezpieczeniowa itd., możliwe do podania w różnych walutach)

55. Historia;56. Analogie;57. Pierwowzór;58. Kopie;59. Właściciel;60. Prawa autorskie;61. Powinna być automatycznie wyświetlana graficzną informację o

przynależności lub nie obiektu do domeny publicznej na podstawie danych obiektu;

62. Czy dane z rekordu gotowe do publikacji: tak/nie63. Publikacja online wskazanych danych z rekordu: tak/nie

(funkcje hurtowe: powinna być możliwość opublikowania wielu 17


not naraz w zależności od wyliczonych numerów inwentarzowych);

64. Data pierwszej publikacji online rekordu (automatycznie)65. Klasyfikacja gus;66. Dział;67. Status obiektu;68. Lokalizacja w muzeum, powinna istnieć funkcja hurtowego

wprowadzania lokalizacji dla zbioru obiektów (np. Użyczanych, konserwowanych, przenoszonych);

69. Udział w wydarzeniach (w tym osobna rubryka, obecność na ekspozycji w ms, ponadto, nazwa wydarzenia, miejsce wydarzenia, daty trwania wydarzenia i pozostałe dane, jak np. Organizator wydarzenia itd.), powinna istnieć możliwość hurtowego wprowadzania obiektów związanych z danym wydarzeniem;

70. Bibliografia, powinna istnieć możliwość hurtowego wprowadzania obiektów związanych z danym wpisem bibliograficznym;

71. Konserwacja (stan zachowania, opis technologiczny konserwatorski, prace konserwatorskie itd., funkcje hurtowe);

72. Uwagi / inne’73. Opracowanie danych;74. Multimedia (zakres tych danych opisany osobno).Ponadto powinna istnieć możliwość opisu pól dla dzieł audiowizualnych, dźwiękowych i cyfrowych, w zakresie między innymi takich danych, jak:

1. Autor/Autorzy (z możliwością połączenia z funkcją, autorów poszczególnych elementów dzieła (reżyseria, realizacja itd.);

2. Tytuł;3. Data powstania;4. Data pierwszej dystrybucji;5. Zapis barwny, czy czarno-biały;6. Film niemy, czy dźwiękowy;

18


7. Zapis mono, czy stereo;8. Numer edycji;9. Rodzaj typu nagrania i sposobu jego prezentacji: video audio,

jednokanałowe, wielokanałowe itd.;10. Wytyczne dotyczące odtwarzania analogowego. Czy trzeba

pokazywać na nośniku analogicznym do pierwotnego, czy dopuszczalne jest odtwarzanie cyfrowe? Jeśli odpowiedź jest twierdząca konieczna jest informacja: jak postępować w przypadku przedawnienia technologii pierwotnej prezentacji dzieła?;

11. Język i dostępne pliki tłumaczeń;12. Miejsce na informację, czy dopuszczalne jest wprowadzenie

napisów z tłumaczeniem na inny język/ ewentualne wytyczne;13. Materiał: Nośnik, na jakim zostało dzieło audiowizualne i

cyfrowe przekazane (oryginał, kopia matka);14. Technika: Sposób zapisu w jakim dzieło audiowizualne i

cyfrowe przekazane;15. Nośniki dodatkowe na jakich zostało dzieło audiowizualne i

cyfrowe przekazane;16. Dodatkowe sposoby zapisu w jakich dzieło audiowizualne i

cyfrowe zostało przekazane;17. Miejsce na linkowanie oryginału/kopii matki, kopii cyfrowej

archiwizacyjnej surowej, kopii archiwizacyjnej cyfrowej po rekonstrukcji, kopii dystrybucyjnej /ekspozycyjnej, poglądowej (miejsce na odznaczanie rodzaj standardu, rozdzielczość itd.);

18. Pierwsza technika zapisu (jeśli inna niż na przekazanym nośniku);sposób odtwarzania/prezentacji;

19. Dopuszczalny format dystrybucyjny (np. Zapis cyfrowy zamiast taśmy filmowej);

20. Czy można w przyszłości zmieniać format do aktualnie obowiązującego?;

21. Oryginalna rozdzielczość;22. Aspect ratio. Oraz pole na określenie, czy można zmienić

proporcje oryginalnego dzieła w celu dostosowania obrazu od urządzenia wyświetlającego? A także, czy Czy oryginalna

19


rozdzielczość może być zmieniona (podwyższona) do możliwości / wymagania współczesnego wyświetlacza lub do przestrzeni w której jest wyświetlana (ryzyko pikselizacji)?

23. Czy dopuszczalna jest ekspozycja w pętli?24. Specyfikacja urządzeń do ekspozycji dzieła (np. Tylko projektor

filmowy, projektor multimedialny, kineskop CRT, monitor LCD itp. Lub bez ograniczeń);

25. Specyfikacja sposobu odtwarzania dźwięku (np. Z głośników, tylko z słuchawek, czy bez ograniczeń);

26. Specyfikacja przestrzeni dla prezentacji dzieła (konkretne wskazania lub bez ograniczeń);

27. Inne uwagi ważne dla przechowywania, archiwizacji, digitalizacji i dystrybucji dzieła;

28. Inne uwagi ważne dla eksponowania dzieła.

Każdy obiekt dostępny przez API powinien być opisany zgodnie z podstawowymi metadanymi typu Dublin Core oraz innymi wspieranymi standardami opisów obiektów kultury i nauki (jako metadane rozszerzone).

UWAGA!!! Zestaw pól opisujących rekord obiektu zostanie doprecyzowany i ostatecznie zdefiniowany w trakcie realizacji Etapu I. Zamawiający zastrzega sobie możliwość dodania/usunięcia na żądanie dowolnych jednostek informacji w trakcie wdrożenia i dostosowania systemu.

W systemie opis rekordu musi zapewniać informacje niezbędne do poprawnej integracji z systemem KRONIK@ zgodnie z obowiązującym przepisami prawa a zakresie integracji systemów obsługi muzeów z Systemem KRONIK@.

Obiekty.21 Moduł musi być podzielny na obszary funkcjonalne/bloki grupujące wybrane metadane. Użytkownik musi mieć możliwość wyborów wcześniej zdefiniowanych widoków, które ograniczają zakres wyświetlanych danych dla poszczególnych funkcjonalności/bloków.

20


Obiekty.22 Moduł będzie umożliwiał przeprowadzenie zmian hurtowych, zaawansowanego filtrowania i wyświetlania obiektów.

Obiekty.23 Wyświetlanie wielu rekordów obiektów w kilku trybach: widoku szczegółowym z widocznymi danymi obiektu, np. widoku tabelarycznym, widoku kafelkowym. Zamawiający uszczegółowi zakres danych na Etapie I.

Obiekty.24 System w ramach modułu musi automatycznie nadawać nowe numery inwentarzowe złożone z oznaczeń numerycznych i literowych, wg schematów podanych przez Zamawiającego.

Obiekty.25 Moduł musi umożliwiać szybką edycję – tj. niezależnie od zmiany widoku pól.

Obiekty.26 Moduł musi umożliwiać kopiowanie zawartości pól i wklejanie ich do tożsamych pól w formatce obiektu.

Obiekty.27 Moduł musi umożliwiać tworzenie własnych widoków formatki obiektu – ich liczba musi być nieograniczona. Użytkownik musi mieć możliwość zgrupowania sekcji i stworzenia dowolnej liczby sekcji. W sekcji musi być możliwość wyboru pól formatki obiektu.

Obiekty.28 Moduł musi umożliwiać generowanie różnych wykazów i raportów z obiektów: kart ewidencyjnych, kart magazynowych, zwykłych wykazów w różnych opcjach, nalepek i innych nowych szablonów wskazanych przez użytkownika, jak i eksport danych do pliku XML, CSV, PDF, RTF, DOCX.

Obiekty.29 Moduł musi umożliwiać tworzenie różnych typów wykazów obiektów, kart naukowych, kart magazynowych, nalepek i innych wykazanych przez użytkownika szablonów dokumentów.

Obiekty.30 Wskazane pola rekordu obiektu z otwartą edycją typu WYSIWYG, z wykorzystaniem nowoczesnych edytorów muszą umożliwiać podłączanie plików.

Obiekty.31 Tworzenie nowych obiektów, nawet w liczbach hurtowych

21


maksymalnie 300 nie może zakłócić pracy w systemie.

Obiekty.32 Moduł musi mieć możliwość stworzenia podrekordu obiektu, to jest elementów zespołu lub elementów obiektu złożonego bazując na stworzonym już obiekcie. W przypadku możliwości tworzenia podrekordu zarówno dla elementu zespołu (obowiązkowo), jak i dla elementu obiektu złożonego (decyzją użytkownika) system musi potrafić automatycznie policzyć ilość pozycji inwentarzowych oraz ilość sztuk inwentarzowych (rozróżniając zespoły od obiektów złożonych).

Obiekty.33 Użytkownik musi mieć możliwość wskazania liczby elementów oraz pozycji - musi być możliwość sklonowania istniejącego obiektu na nowym numerze inwentarzowym.

Obiekty.34 Moduł nie powinien pozwalać na powielenie numeru inwentarzowego.

Obiekty.35 Musi istnieć możliwość wpisania relacji między rekordami obiektów wraz z typem tej relacji. Tworzenia powiązań rekordów obiektów, grupowania rekordów obiektów / agregacji.

Obiekty.36 Poza zbiorami własnymi instytucji moduł musi pozwalać na ewidencjonowanie oraz dokumentowanie przedmiotów obcych, zarówno przechowywanych w instytucji długoterminowo (tzw. depozyty), jak i krótkoterminowo (takich jak obiekty przekładane do ocen w celu nabycia, obiekty przyjmowane do badań, obiekty przyjmowane na wystawy czasowe itd.), bądź także obiekty spoza instytucji, opisywane lub ewidencjonowane z użyciem systemu (zarazem nie znajdujące się w posiadaniu instytucji).

Obiekty.37 Z uwagi na istnienie w systemie rekordów obiektów, które nie pełnią funkcji pozycji dokumentacji ewidencyjnej (nie posiadają numeru identyfikacyjnego / numeru inwentarza czerpanego z księgi inwentarzowej / depozytowej lub innego rodzaju ewidencji) musi istnieć w systemie możliwość bezwzględnej identyfikacji także i

22


tych rekordów.

Obiekty.38 Moduł musi umożliwiać nadawanie klasyfikacji ewidencjonowania np. utraconych czy wykreślonych obiektów. Rekord takiego obiektu zyskuje graficzne wyraźne oznaczenie.

Obiekty.39 Moduł musi m.in. odnotowywać klasyfikacje ewidencjonowania lub łącznie kilka statusów każdego obiektu lub jego części. Jak np.:1. Własność (własność, depozyt) / wypożyczenie;2. Charakter wpisu w ewidencję (np. w ewidencji, wykreślony itd.);3. Muzealium, czy obiekt z ewidencji pomocniczej;4. Czy podlega, nie podlega podliczeniom;5. Status (w muzeum, poza muzeum, wypożyczony,

zarezerwowany, w magazynie, na ekspozycji itd.).

Obiekty.40 Status obiektu winien być nadawany automatycznie w razie włączenia obiektu w określoną procedurę (np. wypożyczenia).

Obiekty.41 Powinna istnieć możliwość wykazania w obrębie danych o miejscu przechowywania, gdzie są przechowywane poszczególne elementy zespołu lub obiektu złożonego.

Obiekty.42 1. W rekordzie obiektu w określonych polach konserwacji musi być możliwość opisu stanu zachowania:a. możliwość tworzenia stanów zachowania poprzez

generowanie raportów ze stanów zachowania obiektu, z głównymi danymi o dziele m.in. autor, nr inwentaryzacyjny, technika, tytuł, czas powstania oraz fotograficznym odwzorowaniem różnych widoków dzieła. Możliwość tworzenia ocen stanu zachowania z wykorzystaniem specjalnie zaprojektowanego edytora graficznego, umożliwiającego rysowanie kresek, kółek, tekstów, wielokątów na fotografii obiektu.

2. Tworzenie opisu technologicznego obiektów.

23


3. Możliwość załączania dokumentacji konserwatorskiej w postaci plików (np. Word, PDF) oraz fotografii i multimediów, także możliwość tworzenia tabel stratygraficznych.

Obiekty.43 Moduł musi pozwalać użytkownikowi na określenie czy dany rekord może zostać eksportowany do portalu i czy ma być dostępny przez API.

Obiekty.44 Poza nadaniem odpowiedniego statusu/flagi oznaczającej możliwość eksportu/publikacji obiektu musi też istnieć możliwość wskazania, które dane (pola rekordu obiektu) będą publikowane poprzez wskazanie uprzednio zdefiniowanego zestawu danych.

Obiekty.45 Akceptacja multimedium i zespołu danych rekordu do publikacji w portalu powinny odbywać się osobno. Powinno być możliwe eksportowanie do portalu samych metadanych: np. nazwisko, tytuł dzieła, numer inwentarzowy itd., wizerunku rekordu obiektu, na którym nie ciążą ograniczenia copyrights.

Obiekty.46 Dostęp do niektórych zasobów poprzez API powinien być możliwy dla użytkowników z odpowiednimi prawami dostępu.

Obiekty.47 Moduł musi mieć możliwość wyświetlania listy dokumentów oczekujących na akceptację do eksportu do portalu.

Multimedia

Obiekty.48 Moduł musi obsługiwać multimedia różnego typu (obraz, dźwięk, wideo, tekst) w formatach wskazanych przez Zamawiającego.

Obiekty.49 Moduł musi umożliwiać odtwarzanie multimediów np. plików filmowych, audio w Ewidencji Zbiorów Muzealnych.

Obiekty.50 Moduł musi umożliwiać pełnotekstowe przeszukiwanie bazy danych Ewidencji Zbiorów Muzealnych oraz wg kryteriów np.: rodzaj księgi, nr identyfikacyjny, twórca, materiał; dla multimedium: nr identyfikujący, data wykonania, data rejestracji i inne wskazane przez Zamawiającego.

Obiekty.51 Dokumentacja multimediów musi być prezentowana w rekordzie 24


obiektu w postaci głównej ikony oraz w formie rozszerzonej o dodatkowe przypisane jej multimedia uzgodnione z Zamawiającym.

Obiekty.52 Moduł musi umożliwiać ustalania sekwencji, kolejności prezentacji multimediów w rekordzie (np. metodą przeciągnij i upuść).

Obiekty.53 Moduł musi pozwolić na dowolne obracanie odwzorowania plików graficznych (powinien obsługiwać je w 360 stopniach), powiększanie, zmniejszanie wybranego odwzorowania bez rzeczywistej zmiany orientacji i rozmiaru pliku.

Obiekty.54 Dla każdego rekordu obiektu moduł musi automatycznie tworzyć albumy, które będą przechowywały różne multimedia obiektu. Dostęp do wybranych albumów tylko z poziomu uprawnionych użytkowników. Np. album mógłby powstać w momencie dodania pierwszego pliku.

Obiekty.55 Moduł powinien automatycznie wyświetlać graficzną informację o rodzajach multimediów podłączonych do rekordu.

Obiekty.56 Wglądówki (plik do podglądu) w rekordzie obiektu muszą być tworzone na podstawie wskazanych plików. Ostateczna jakość wglądówki do ustalenia z Zamawiającym na Etapie I.

Obiekty.57 Moduł musi posiadać narzędzia do zarządzania multimediami, mi.in. decydowania, poprzez nadawanie określonych statusów/flag itp. o następujących działaniach:a. Które z multimediów obiektu będą eksportowane z systemu

bazodanowego do publikacji w portalu internetowym (Zasoby).b. Które z multimediów obiektu będą drukowane na raportach, ze

szczególnym wskazaniem, które multimedium na jakim raporcie będzie drukowane (np.: na kwerendach, na karcie ewidencyjnej, na karcie naukowej, karcie magazynowej).

c. inne wskazane przez Zamawiającego.

25


Obiekty.58 Moduł musi mieć możliwość oznaczania dokumentacji multimedialnej informacją o posiadaniu lub nie praw autorskich do multimedium.

Obiekty.59 Moduł musi automatycznie wyświetlić graficzną informacje w rekordzie o przynależności lub nie obiektu do domeny publicznej na podstawie danych obiektu, biorąc kolejno pod uwagę np.: upływ czasu od daty śmierci twórcy, upływ czasu od momentu powstania dzieła, jeżeli twórca lub data jego śmierci nie są znane należy ręcznie oznaczyć przynależność do domeny publicznej.

Obiekty.60 Moduł musi automatycznie stworzyć dla każdej podłączanej do Repozytorium dokumentacji multimedialnej etykietę zawierającą informację o jej metadanych.

Dane do etykiety będą zawierały wskazane informację z danych rekordu i dokumentacji multimedialnej z przynajmniej jednym polem opisowym. Szczegółowa lista danych zostanie wskazana przez Zamawiającego.

Moduł przy tworzeniu etykiety dla dokumentacji multimedialnej nie zmieni nazwy tej dokumentacji. Dotyczy to plików źródłowych np.: pliki graficzne RAW, TFF, czy różne pliki multimedialne.

Moduł przy tworzeniu etykiety dla skompresowanej wglądówki podpisze ją zgodnie ze schematem wskazanym przez Zamawiającego.

Obiekty.61 Moduł musi umożliwiać zmianę danych w etykiecie/etykietach dokumentacji multimedialnej w trybie pojedynczym i hurtowym.

Moduł musi automatycznie dokonywać zmiany w etykiecie/etykietach dokumentacji multimedialnej, kiedy taka zmiana dokona się w obrębie rekordu obiektu np.: obiekt zyskał

26


drugi tytuł, wystąpiła literówka.

Obiekty.62 Moduł musi generować raporty o błędach powstałych w procesie podłączania multimediów do rekordu.

Obiekty.63 Funkcja pobierania z systemu oryginalnego pliku (plików) musi posiadać mechanizm automatycznego nadpisywania danych wg kolejności ustalonej z Zamawiającym np.:a. tytuł/nazwa obiektub. twórca obiektuc. datowanie obiektud. nazwa instytucjie. prawa autorskie do obiektuf. określenie kopia ekspozycyjnaFunkcja pobierania pliku/plików z Repozytorium musi umożliwiać oznaczenie jakie informacje o obiekcie znajdą się w dołączonej etykiecie.Nie wszystkie dane z etykiety muszą być dołączane do pobieranego zdjęcia.

Obiekty.64 Moduł powinien umożliwiać wyszukiwanie dowolnego multimedium zarówno z użyciem kryteriów (metadanych) właściwych dla multimediów, jak i z użyciem kryteriów wyszukiwania (metadanych) właściwych dla obiektu.

Obiekty.65 Uprawniony użytkownik powinien mieć możliwość pobierania wszystkich dokumentacji multimedialnych podłączonych do rekordu zarówno z poziomu przeglądarki Repozytorium jak i z poziomu rekordu obiektu.

Obiekty.66 Na poziomie podstawowej edycji dokumentacji multimedialnej obiektu sztuki Moduł musi informować o jego klasyfikacji inwentarzowej np. czy obiekt jest w ewidencji, jest ubytkiem (anulowanym), ubytkiem (reinwentaryzowanym), i innym do ustalenia z Zmawiającym.

Obiekty.67 Na poziomie podstawowej edycji dokumentacji multimedialnej 27


obiektu sztuki Moduł musi informować o tym, czy obiekt jest np.: obiektem pojedynczym, obiektem złożonym, zespołem obiektów.

Obiekty.68 Moduł musi umożliwiać wydruk nieograniczonej liczby obiektów w raportach.

Obiekty.69 Moduł powinien umożliwiać podejrzenie załączonych do rekordu obiektu odwzorowań oraz plików multimedialnych przy pomocy wbudowanego odtwarzacza dostosowanego do rodzaju odtwarzanego typu plików. W przypadku dużych oraz niepopularnych plików multimedialnych Zamawiający dopuszcza podgląd załączonych skompresowanych wersji plików (wielkość oraz ograniczenia typów plików zostaną określone w Etapie 1).

Obiekty.70 Moduł musi umożliwiać sortowanie multimediów np. po rozmiarze, nazwie, dacie (np. zaimportowania, modyfikacji).

Obiekty.71 Moduł musi obsługiwać wgrywanie wielu plików jednocześnie.

Obiekty.72 Moduł powinien zapewnić pozostawienie widoku ewidencji po zakończeniu np.: procesu edycji rekordu obiektu w miejscu rozpoczęcia tej edycji.

Obiekty.73 Moduł musi zapewnić efektywne i wolne od błędów tworzenie kwerend wg zadanych kryteriów (zostaną określone przez Zamawiającego na Etapie I) oraz wyszukiwanie pełnotekstowe.

Obiekty.74 Zbiór wybranych kryteriów kwerendowych musi być wyświetlany łącznie, a użytkownik musi mieć możliwość ujmowania poszczególnych kryteriów z zapytania lub dodawania kolejnych np. metodą przenieś/upuść.

Obiekty.75 Wszystkie kryteria wyszukiwania podczas tworzenia kwerendy powinny być pogrupowane i zaprezentowane użytkownikowi. W szczególności musi być zachowana zasada pełnej widoczności wszystkich kryteriów zadanych do wyszukiwania lub zapytania

28


kwerendowego.

Obiekty.76 Moduł musi posiadać możliwość zapisania zdefiniowanych wcześniej kwerend oraz powinna istnieć możliwość wyeksportowania wyników kwerendy do rejestru.

Obiekty.77 Możliwość wprowadzania różnych kryteriów zawężania danych wybranych pól (np. mniejsze, większe, zakres danych, logiczne ‘lub’).

Widoki

Obiekty.78 Moduł musi umożliwiać różnorodne przeglądanie stron z rekordami i innymi danymi - np. utworzenie nowej zakładki czy okna z danymi wg uznania użytkownika (jednocześnie otwarcie kilka rekordów z dziełami, czy szczegółowymi danymi dzieła), przechodzenia do kolejnych wskazanych stron, wracania do strony poprzedniej itd. w sposób płynny, prosty i intuicyjny.

Obiekty.79 Moduł powinien umożliwiać przeglądanie danych za pomocą różnych widoków. Każdy użytkownik będzie mógł ustawić swój domyślny widok spośród wszystkich dostępnych widoków zdefiniowanych w module. Szczegóły widoków zostaną ustalone z Zamawiającym w Etapie I.

Obiekty.80 Moduł musi umożliwiać tworzenie indywidualnych widoków z danymi obiektów wg indywidualnie sformułowanych kryteriów - musi też umożliwiać stworzenie własnego widoku do pracy z rekordami (np. użytkownik zaznacza sobie kolejność pól czy to, co ma się mu pokazywać).

Obiekty.81 Moduł musi umożliwiać przeglądanie danych za pomocą różnych widoków np.: kafelki, tabela.

Obiekty.82 Moduł musi umożliwiać zmianę liczby widocznych elementów na stronie.

Obiekty.83 W przypadku wyświetlania wielu rekordów musi być możliwość

29


sortowania tych rekordów według zadanych kryteriów (np. twórca rosnąco, datowanie rosnąco itd.)

Obiekty.84 Musi być możliwość wyboru danych, które są wyświetlane w widoku wielu rekordów obiektów. Domyślnie powinny być to dane podstawowe np.: nr identyfikacyjny, dział, nazwa/rodzaj, twórca, tytuł, miejsce powstania, data, wymiary, technika, tworzywo, lokalizacja, status i pochodzenie (dar, przekaz itp.).

Obiekty.85 W przypadku widoku wielu rekordów obiektów powinny pokazywać się daty odnoszące się do statusu obiektów (np. w wypożyczeniu od-do, na ekspozycji od-do itd., zarezerwowany od-do).

Obiekty.86 W widoku wielu rekordów obiektów musi być możliwość skorzystania z podręcznego filtra statusów nadanych dla obiektów.

Obiekty.87 Szablon interfejsów powinien obsługiwać RWD, powinien być wykonany w sposób nowoczesny i intuicyjny. Interfejsy powinny być szybkie, skrypty i style skompresowane.

Moduł Rejestry

Rejestry.1 Moduł będzie umożliwiał prowadzenie rejestrów z obiektów, słowników i multimediów oraz zarządzanie nimi.

Rejestry.2 Możliwości modułu rejestrów z rekordów obiektu to również dodawanie nowego rejestru, edytowanie wcześniej dodanego, filtrowania rejestrów, zarządzania elementami rejestru, scalania kilku rejestrów, nadawania statusów do rejestrów, możliwość wydruków rejestru (np. PDF) oraz export do .xlsx, docx.

Rejestry.3 Tworzenie nowego rejestru musi być możliwe wg zadanych dowolnych kryteriów odnośnie do wszystkich rekordów obiektów. Łączenie i tworzenie dowolnych zapytań np. Chcę znaleźć wszystkie

30


fotografie, powstałe w wybranym zakresie czasu, sygnowane, wybranych artystów itd.).

Rejestry.4 Moduł musi posiadać funkcję tworzenia dowolnego rodzaju rejestrów, zarówno dla rekordów obiektów, rekordów multimediów, rekordów słownikowych.

Rejestry.5 Tworzenie rejestrów (zestawień) powinno odbywać się poprzez wskazanie danego rekordu obiektu (np. podanie numeru identyfikacyjnego) lub wyszukanie rekordów obiektów.

Rejestry.6 Nie może istnieć systemowe ograniczenie liczby obiektów w rejestrze. Moduł musi mieć możliwość operowania na nieograniczonych liczbowo rejestrach.

Rejestry.7 Rejestry winny mieć charakter publiczny oraz z ograniczonym statusem (do ustawienia) - każdy użytkownik powinien mieć możliwość przydzielenia dostępu do przeglądu i/lub edycji przygotowanych przez siebie rejestrów/zestawień wszystkim użytkownikom lub użytkownikom wskazanym przez siebie w drodze wyboru.

Rejestry.8 Tworzenie nowego rejestru poprzez wprowadzanie numeru identyfikacyjnego obiektu musi być możliwe poprzez wpisanie go z klawiatury lub poprzez odczyt kodu np. graficznego (QR).

Rejestry.9 W rejestrach musi być dostępna funkcjonalność dodawania obiektów do rejestru z pliku (po numerach inwentarzowych).

Rejestry.10 W rejestrach musi być możliwość sortowania rekordów obiektów wg pól tych rekordów np.: po tytule, po autorze, po numerze inwentarzowym.

Rejestry.11 W rejestrach musi być możliwość wyboru strony oraz liczby widocznych elementów na stronie.

Rejestry.12 W rejestrach musi być możliwość filtrowania rejestrów po takich polach jak np. dziale, właścicielu rejestru, numerze rejestru. Musi być możliwe wyszukiwanie pełnotekstowe w rekordach rejestru.

31


Ponadto musi być możliwość sortowania po rekordach rejestrów.

Rejestry.13 Opis rejestru powinien posiadać informacje takie jak liczba rekordów w rejestrze, data utworzenia, właściciel rejestru itp. przyciski akcji takie jak edycja rejestru, podgląd rejestru.

Rejestry.14 Użytkownik, który nie posiada uprawnień do danego rejestru nie może go widzieć na liście rejestrów. Ponadto muszą istnieć systemowe ograniczenia dostępu na podstawie ról i określonego dostępu per użytkownik (RBAC).

Moduł Statystyki

Statystyki.1 Moduł odpowiedzialny za zbieranie statystyk okresowych, generowania statystyk (statystyki użytkowników, statystyki okresowe czy sprawozdania MKiDN/NIK).

Statystyki.2 W module Statystyk znajdą się również takie komponenty jak obsługa różnych rodzajów ksiąg inwentarzowych, także inwentarzy pomocniczych i będzie on umożliwiał różne typy wydruków, całości lub wybranych ksiąg.

Statystyki.3 Statystyki mają też dotyczyć aktywności użytkowników, pracy w systemie, obiektów udostępnianych online, obiektów udostępnianych na wystawy lub obiektów na nie rezerwowanych.

Statystyki.4 Moduł powinien mieć możliwość wykazywania i tworzenia statystyk wskazanych przez użytkownika.

Statystyki.5 Różnego rodzaju eksporty statystyk (np. .xlsx, PDF)

Statystyki.6 W module muszą istnieć predefiniowane kwerendy dla podstawowych statystyk oraz podstawowe zestawienia statystyczne widoczne od razu na karcie widoku statystyk np. liczby obiektów, liczby obiektów wypożyczonych ogółem, liczby obiektów wypożyczonych w wybranym okresie czasowym, lokalizacje, liczby wpisów inwentarzowych itp. liczba

32


i lista obiektów na galerii, liczba i lista obiektów w danym wypożyczeniu, liczba i lista obiektów w danej rezerwacji. Podstawowy zakres statystyk zostanie uzgodniony z Zamawiającym na Etapie I.

Statystyki.7 Moduł musi umożliwiać drukowanie ksiąg inwentarzowych ze szczegółowymi danymi nt. zawartości ksiąg np. informacjami o wykreślonych pozycjach.

Statystyki.8 Statystyki musza ̨ uwzględniać́ informacje takie jak: liczba opublikowanych obiektów: wszystkich lub wg podziału; liczba opublikowanych obiektów z konkretnym oznaczeniem np. słowo kluczowe; liczba zaktualizowanych obiektów; liczba obiektów bez zdjęć; liczba obiektów z oznaczeniem np.: domena publiczna, liczba obiektów aktualnie na galerii; wykaz obiektów posiadających nieuzupełnione wskazane pola rekordu.

Statystyki.9 Moduł powinien umożliwiać raportowanie, ile obiektów zostało wpisanych w określonym czasie, ile jest obiektów w kolekcji.

Statystyki.10 Możliwość skierowania raportu na ekran, drukarkę lub zapis do pliku w formacie XLSX, RTF, XML, HTML, PDF.

Statystyki.11 Musi być możliwość zliczania wartości dzieł wg zadanych kryteriów np. inwentarzowej.

Statystyki.12 Musi być możliwość zliczania liczby pozycji inwentarzowych oraz pozycji inwentarzowych z liczbowym wyliczeniem elementów w obiektach będących zespołami, t.j. zliczenie głównych pozycji inwentarzowych a także osobno zliczenie głównych numerów inwentarzowych i liczby podjednostek inwentarzowych w przypadku przełamanych numerów t.j. zespołów.

Moduł Generatora Dokumentów

Generator.1 Moduł musi umożliwiać generowanie i zarządzanie dokumentami tj.: umowy, aneksy do umów, protokoły, ruchu wewnętrznego,

33


raporty, zestawienia i inne wydruki z Systemu.

Generator.2 Moduł musi posiadać możliwość generowania dokumentów na podstawie wcześniej zdefiniowanych szablonów.

Generator.3 Moduł musi mieć możliwość listowania, wyświetlania, filtrowania i sortowania dokumentów po: numerze, typie, dacie, twórcy i innych polach - szczegóły pól zostaną ustalone przez Zamawiającego.

Generator.4 Jeżeli użytkownik posiada takie uprawnienia to musi mieć możliwość, dodawania, edycji, usuwania dokumentów.

Generator.5 Użytkownik po wejściu w dany dokument musi mieć możliwość wygenerowania raportu powiązanych z danym dokumentem obiektów.

Generator.6 Dokumenty w ruchu wewnętrznym mogą być przypisywane do użytkownika tj. twórca dokumentu może przypisać inną osobę w systemie do której dokument powinien dotrzeć.

Generator.7 Dokumenty muszą posiadać historię swojej modyfikacji.

Generator.8 Moduł musi mieć możliwość stworzenia nowego szablonu dokumentu przez użytkownika.

Generator.9 Moduł musi mieć dostosowane wzory dokumentów i wyciągów do istniejących u Zamawiającego typów ewidencjonowania oraz możliwość tworzenia nowych dokumentów w zakresie ewidencjonowania lub wprowadzania korekt do już istniejących dokumentów (Księga Inwentarzowa, Księga Depozytów, Księga Wpływu, Księga Zakupów, protokoły – do uzgodnienia z Zamawiającym).

Generator.10 Moduł musi mieć możliwość tworzenia rejestrów pomocniczych. Moduł musi mieć możliwość dostosowania wzorów dokumentów i wyciągów do istniejących u Zamawiającego zasad nabywania i ruchu dzieł sztuki (wewnętrznego i zewnętrznego).

Generator.11 Moduł musi mieć możliwość tworzenia nowych dokumentów w 34


zakresie nabywania i ruchu dzieł sztuki lub wprowadzania korekt do już istniejących dokumentów (Księga Ruchu, umowy nabywania, protokoły – do uzgodnienia z Zamawiających).

Generator.12 Moduł musi umożliwiać generowanie kart i innych formatów dokumentów do wydruku w wersji edytowalnej. Formaty dokumentów powinny być uzgodnione z Zamawiającym i możliwe do modyfikowania przez Zamawiającego.

Moduł Słowników

Słowniki.1 Moduł musi umożliwiać tworzenie słowników (płaskich i hierarchicznych), dodawania tłumaczeń do słowników, scalania haseł słownikowych, dodawania nowego hasła słownikowego lub edycja już dodanego.

Słowniki.2 Lista słowników w module musi zawierać dokumenty ewidencyjne, działy, jednostki, klasyfikację GUS, klasyfikację praw autorskich, kontrahentów i podmiotów, lokalizacje, rodzaje akcesji, rodzaje obiektów, klasyfikację ról, słowa kluczowe, słowniki synonimów, szablonów wymiarów, technik, tworzyw, twórców, wydarzeń, bibliografii, nazw geograficznych, wymiarów, sprzętu pomocniczego, sposobu nabycia, celu wydawania obiektów oraz inne ustalone z Zamawiającym.

Słowniki.3 Moduł musi mieć możliwość dokonywania zmian w słownikach z poziomu robienia rekordu (bez konieczności zamykania okna rekordu i wchodzenia do słownika).

Słowniki.4 Moduł musi we wszystkich miejscach, gdzie używane są terminy skrócone (także nazwa skrócona w bibliografii) użytkownik dokonując wyboru terminu skróconego musi widzieć pełny termin np. za pomocą pop-up’u.

Słowniki.5 Do wszelkiego rodzaju danych słownikowych muszą zostać przygotowane narzędzia/funkcje umożliwiające wykonywanie edycji, a także porządkowanie haseł, scalanie, hierarchizacja,

35


edycja dodawania i modyfikowanie terminów, ich wyszukiwanie, usuwanie itd.

Słowniki.6 Moduł musi mieć możliwość zarządzania słownictwem kontrolowanym i użycia standardowych tezaurusów i słowników, zarówno w drodze kopiowania/pobierania tezaurusów zewnętrznych (pozyskanych z innych źródeł), jak i integracji on-line (możliwe integracje do uszczegółowienia z Zamawiającym).

Słowniki.7 Moduł musi pozwalać na implementację słowników zewnętrznych, np. takich jak Iconclass, Art and Architecture Thesaurus, Union List of Artist Names, Thesaurus of Geographic Names i zapewnienie ich cyklicznej aktualizacji.

Słowniki.8 Słowniki w module muszą być wspólne dla pozostałych modułów oraz komponentów. Moduł musi zapewniać, że modyfikacja słownika następuje tylko w jednym miejscu, a synchronizacja do pozostałych miejsc jest automatyczna, on-line i synchroniczna.

Słowniki.9 Uprawnienia do edycji i podglądu słowników powinny wynikać z przyznanej roli.

Słowniki.10 Moduł musi weryfikować poprawność wprowadzanych danych pod kątem ich kompletności i spójności oraz zgodności ze zdefiniowanymi słownikami, wspomagać użytkownika poprzez oferowanie list wyboru i wyszukiwania kontekstowego przy wprowadzaniu danych.

Moduł RBAC Zarządzanie użytkownikami

RBAC.1 Moduł będzie wykorzystywany do dodawania nowego użytkownika, aktualizacji profilu użytkownika, nadania uprawnień działowych, zablokowania użytkownika, usunięcia użytkownika. Minimalna ilość pól użytkownika to imię i nazwisko, nazwa użytkownika, e-mail, dział, data rejestracji oraz jego rola i status w systemie. Zarządzanie rolami odbywać będzie się poprzez definiowanie roli

36


(zakres uprawnień) lub edycji już wcześniej dodanej. Moduł będzie posiadał możliwość kopiowania roli, czyli utworzenia nowej na bazie istniejącej oraz możliwość usunięcia roli wraz z odpięciem i alertami w przypadku, gdy role są używane w systemie użytkowników i dzieł (z akceptacją usunięcia ich i poinformowania o skutkach).

RBAC.2 Moduł nie może posiadać ograniczenia co do liczby użytkowników ani co do liczby użytkowników zalogowanych w tym samym czasie.

RBAC.3 Warunkiem korzystania z systemu jest utworzenie konta w systemie przez administratora systemu.

RBAC.4 System użytkowników powinien posiadać metody logowania i autentykacji.

RBAC.5 Moduł musi posiadać możliwość blokowania użytkowników przez konto użytkownika o określonych prawach (dezaktywowania konta bez możliwości jego usunięcia).

RBAC.6 Administrator ma mieć możliwość wyświetlania nieaktywnych i dezaktywowanych użytkowników, użytkownik taki powinien być oznaczony.

RBAC.7 Administrator musi mieć możliwość edycji konta użytkownika, wprowadzenia nowego hasła, zresetowania hasła użytkownika itp. nie może mieć jednak wglądu do hasła użytkownika.

RBAC.8 Hasła użytkowników w Systemie nie mogą być zapisywane plain tekstem – muszą być szyfrowane np. metodą Scrypt, bcrypt, argon2 lub innym nowoczesnym sposobem szyfrowania. Zamawiający nie dopuszcza szyfrowania haseł algorytmem MD5.

RBAC.9 Uprawnienia i profile użytkowników - funkcjonalność umożliwiająca przydzielanie praw i przydzieleniu ról użytkownikom. Typy kont, role oraz prawa zostaną określone

37


podczas tworzenia systemu z Zamawiającym.

RBAC.10 Moduł musi umożliwiać wydajne wyszukiwanie użytkowników w systemie. Powinna istnieć lista użytkowników dostępna użytkownikom z rolą Administrator.

RBAC.11 Moduł musi wymuszać zmianę hasła po utworzeniu konta przez administratora.

RBAC.12 Moduł musi umożliwiać przypisanie użytkownika do grup użytkowników np. działu.

RBAC.13 Moduł musi umożliwiać nadawanie uprawnień i przydzielanie ról każdemu użytkownikowi.

RBAC.14 Moduł musi posiadać funkcjonalność hurtowego nadawania uprawnień.

RBAC.15 Moduł musi umożliwiać tworzenie dowolnej liczby ról dla jednego użytkownika.

RBAC.16 Moduł musi umożliwiać edycję profilu użytkownika – ustawienie hasła, opisu, preferowanego widoku listy i szablonu obiektu.

RBAC.17 Dostęp użytkowników do poszczególnych funkcji Systemu musi być regulowany przez Administratora odpowiednimi uprawnieniami z wykorzystaniem Ról.

RBAC.18 Role powinny być zdefiniowane w zależności od czynności wykonywanych przez użytkowników Systemu.

RBAC.19 System musi umożliwić całkowite lub częściowe ograniczenie dostępu do wybranych danych poszczególnym użytkownikom bądź grupom użytkowników.

RBAC.20 W momencie Startu Produkcyjnego, System musi mieć zdefiniowane Role uprawnień, określające dostęp do Modułów Systemu dla użytkowników.

38


RBAC.21 System zarządzania uprawnieniami użytkowników (Rolami) musi umożliwiać m.in.: kopiowanie definicji Ról, grupowe nadawanie uprawnień do Roli (np. po wyborze Roli wskazuje się użytkowników mających mieć do niej uprawnienie), modyfikowanie Ról itp.

RBAC.22 Autentykacja i autoryzacja użytkowników w Systemie będzie realizowana poprzez moduł RBAC.

RBAC.23 Każdy użytkownik w Systemie musi mieć niepowtarzalny identyfikator w systemie (Login).

RBAC.24 Każdy użytkownik musi mieć zdefiniowane hasło w systemie.

RBAC.25 System musi zapewniać dla każdego hasła możliwość zdefiniowania stopnia złożoności hasła co najmniej w zakresie:a) minimalnej długości hasła ib) Poziom złożoności hasła - umożliwia określenie stopnia

skomplikowania hasła poprzez zaznaczenie pól wyboru: wymagaj liter - hasło musi zawierać przynajmniej

jedną literę od A do Z, wymagaj cyfr - hasło musi zawierać przynajmniej jedną

cyfrę od 0 do 9, wymagaj znaków specjalnych - hasło musi zawierać

przynajmniej jeden znak spoza grupy znaków alfanumerycznych np. "#", "$", "%",

wymagaj wielkich i małych liter - hasło musi zawierać przynajmniej jedną literę wielką oraz małą.

RBAC.26 Użytkownik Systemu musi mieć możliwość samodzielnej zmiany hasła w dowolnym momencie po podaniu dotychczas ustawionego hasła.

RBAC.27 Uprawnienia do usuwania/kasowania rekordów obiektów w module winny być reglamentowane. Podobnie nadawania im statusu obiektów niepodlegających podliczeniu.

39


RBAC.28 W module musi być możliwość zablokowania logowania się do Systemu wszystkich lub wybranych użytkowników (np. w trakcie prowadzonych prac konserwacyjnych).

RBAC.29 W module musi być możliwość wylogowania wszystkich lub wskazanych użytkowników pracujących aktualnie w Systemie.

Moduł Konfiguracji systemowych

Konfiguracja.1 Moduł ma umożliwić definiowanie przez administratora okresu czasu jaki system musi wymuszać na użytkowniku zmianę hasła.

Konfiguracja.2 Administrator musi mieć możliwość tworzenia szablonów widoków dostępnych w całym systemie.

Konfiguracja.3 Moduł musi umożliwiać konfiguracja:1. Częstotliwości zmiany hasła2. Ustawienia trudności hasła3. Danych instytucji4. Adresów e-mail powiadamiania o zdarzeniach i logach

Konfiguracja.4 Administrator musi mieć możliwość wglądu do modułów logów (historii logowań użytkowników, zdarzeń w systemie).

Konfiguracja.5 Administrator musi mieć możliwość edycji wszystkimi rekordami obiektów i multimediami bez ograniczeń.

Konfiguracja.6 Moduł musi mieć możliwość dodawania i edycji składni oznaczeń ewidencyjnych.

Konfiguracja.7 Możliwość zdefiniowania widoków publicznych metryczki obiektu o charakterze globalnym dostępnym dla użytkowników i w publicznym API.

Konfiguracja.8 Inne wymagania dot. możliwości administratora systemu zostaną doprecyzowane wraz z Zamawiającym.

Moduł LOGI

Logi.1 Dostępne dla administratora - Możliwość z poziomu aplikacji zweryfikowania logów dotyczących importu multimediów,

40


przeglądania potencjalnych błędów aplikacji, wyjątków, informacji nt. wysyłek e-mail, dane nt. zajętości multimediów itd.

Logi.2 W kontekście użytkowników: funkcję zapisu zdarzeń typu data i czas założenia konta, logowania do systemu (w tym login użytkownika), przeglądania zasobów, modyfikacji danych i udostępniania. Każdy użytkownik powinien mieć możliwość uzyskania raportu dotyczącego własnej aktywności.

Logi.3 Lista błędów systemowych - w zależności od użytego języka programowania, wraz z notyfikacją email na wybrane konto.

Logi.4 W module wszystkie operacje (a w szczególności operacje zmiany konfiguracji, zmiany modelu uprawnień oraz zmiany uprawnień) muszą być audytowane i zapisywane w logach, możliwych do odczytania poprzez Standardowe Oprogramowanie Aplikacyjne na poziomie co najmniej kto, kiedy i co.

Logi.5 Moduł musi zapewniać monitorowanie aktywności użytkowników w Systemie.

Logi.6 Moduł musi wyświetlać listę aktualnie zalogowanych użytkowników.

Logi.7 Moduł musi umożliwiać wyświetlenie listy nieudanych prób logowania do Systemu.

Logi.8 Moduł musi zapewniać możliwość raportowania aktualnie przydzielonych uprawnień.

Logi.9 Moduł musi odnotowywać kto i kiedy wprowadził daną informację do Ewidencji Zbiorów Muzealnych. Dla danych, które są modyfikowane moduł musi zapisywać informacje kto i kiedy dokonał modyfikacji oraz wartość danej przed zmianą i po zmianie.

Moduł Publicznego API

API.1 Moduł musi zapewnić udostępnienie zasobów określonej grupy obiektów on-line za pomocą API dostępnego publicznie. Moduł umożliwi zainteresowanym pobieranie danych w formacie JSON lub XML odpowiednio ustrukturyzowane. W ramach API zostanie

41


wytworzona zaawansowana wyszukiwarka dzieł. Moduł publicznego będzie implementowało również autoryzację oAuth 2.0 - która pozwoli na logowanie, pozyskiwanie dostępów i ról.

API.2 Dostęp do danych poprzez Moduł publicznego API będzie możliwy po dokonaniu autentykacji i autoryzacji użytkownika.

API.3 Moduł API będzie dostępny jako portal internetowy, który musi spełniać wymagania WCAG 2.1 na poziomie AA oraz musi posiadać funkcjonalność RWD (Responsive Web Design). Komunikacja z portalem musi być szyfrowana za pomocą certyfikatu SSL. Wykonawca jest zobowiązany zapewnić odpowiedni certyfikat do końca okresu związania z Umową. Dostarczony certyfikat musi być wystawiony przez Wystawcę, który jest na liście zaufanych głównych wystawców certyfikatów przez Microsoft.

API.4 Użytkownik, który będzie chciał pobrać udostępnione publiczne dane z Systemu, będzie musiał zalogować się do Module. Moduł musi umożliwiać założenie konta z funkcją potwierdzania konta poprzez wysłanie linku aktywacyjnego na konto e-mail, które użytkownik wskaże w procesie rejestracji. Po utworzeniu konta, użytkownik w swoim profilu, będzie mógł korzystać z funkcji: przypomnienie i reset hasła, sprawdzanie stanu zalogowania, dostęp do danych profilu użytkownika, resetowanie tokenu logowania

API.5 Moduł musi zapewnić dostęp do list rekordów obiektów, z limitem i paginacją.

API.6 Moduł musi zapewnić dostęp do danych udostępnionych rekordów obiektów i multimediów.

API.7 Moduł musi zapewnić dostęp do danych prywatnych obiektów i multimediów - pod warunkiem, że użytkownik jest zalogowany i posiada prawa.

API.8 Moduł musi być zgodny z standardem otwartych danych dostępnym po adresem: https://dane.gov.pl/pl/article/785,standard-

42


interfejsu-programistycznego-aplikacji-api-final

API.9 Moduł musi dokonywać weryfikacji udostępnionych danych pod względem poprawności formatu danych, wysyłane zapytania powinny zostać przefiltrowane mechanizmem np. jsonschema.

API.10 Dokumentacja API wraz z umieszczeniem dokumentacji na podstronie projektu.

API.11 Na portalu Modułu musi być dostępna wyszukiwarka Obiektów, która pozwala na wyszukiwanie według zadanych kryteriów uwzględniając np.:- kolekcje- artystę, autora- tytuły dzieła- fragmenty treści (wyszukiwanie pełnotekstowe)- datowanie- nr. inwentarzowy- rodzaj / typ dzieła- technikę wykonania dzieła, materiały- datę nabycia oraz zakresy innych dat np. powstania- miejsce wydarzenia- i inne.Wyszukane dane będzie można sortować.Szczegółowy zakres danych udostępnianych poprzez Moduł dla użytkowników zostanie ustalony podczas realizacji Etapu I.

API.12 API powinno umożliwiać dostęp do danych szczegółowych obiektów po identyfikatorze pojedynczego obiektu.

API.13 API powinno udostępniać informacje takie jak licznik użyć danego obiektu, licznik pobrań.

API.14 Dane, które mają być udostępniane poprzez Moduł Publicznego API będą oznaczane odpowiednim statusem w Module Obiekty.

API.15 Sposób udostępniania danych w Module, będzie spełniał kryteria oznaczające 3 gwiazdki w skali „5 Star Open Data”.

43


Moduł Integracyjny

Integracja.1

W systemie musi istnieć Moduł Integracyjny, który będzie stanowił połączenie Ewidencji Zbiorów Muzealnych z istniejącym Portalem on-line. Moduł musi pozwalać przesyłać i aktualizować dane pomiędzy Ewidencją Zbiorów Muzealnych a istniejącym Portalem on-line Muzeum Sztuki.Integracja z Portalem on-line będzie polegała na przesyłaniu do bazy danych w Portalu, zgodnie ze strukturą bazy danych Portalu, informacji o obiekcie muzealnym.

Integracja.2 Aktualizacja treści w opublikowanych wcześniej w Portalu on-line rekordach musi się, odbywać automatycznie.

Integracja.3 Rekordy w Module Obiektów muszą mieć́ ustalone statusy publikacji np.:1. niepublikowany2. gotowy do publikacji3. opublikowanyNa podstawie statusu danego rekordu w zakresie publikacji go w Portalu on-line, w module będą możliwe do podjęcia określone działania. Sposób realizacji procesów przy poszczególnych statusach zostanie uzgodniony podczas realizacji Etapu I.

44


Integracja.4 W Module musi być dostęp do listy rekordów obiektów, które są ostatnio zaktualizowane i oznaczone jako gotowe do publikacji.

Integracja.5 Moduł powinien dawać możliwość oznaczania pojedynczo lub hurtowo grupy rekordów obiektów do publikacji (status: gotowy do publikacji).

Integracja.6 Moduł Integracji musi okresowo zaktualizować dane do rekordów oznaczonych jako opublikowane. Aktualizacja powinna odbywać się w możliwym do ustawienia interwale czasowym.

Integracja.7 Eksportowane dane z określonych pól rekordu obiektu w Ewidencji Zbiorów Muzealnych powinny odpowiadać polom w Portalu on-line MSŁ i zawierać m.in dane takie jak:

1. Nazwa / Tytuł2. Artysta3. Artysta (2)4. Rodzaj (typ)5. Technika6. Datowanie7. Kolekcja8. Data nabycia9. Sposób nabycia10. Tagi11. Słowa kluczowe, powiązania12. Rozmiar13. Materiały14. Numer inwentarzowy15. Licencja16. Udział w wystawach17. Bibliografia18. Prawa autorskie19. Czy dzieło dostępne na ekspozycji20. Dokumentacja multimedialna

Integracja.8 Moduł musi dostosować ́ wielkość ́ przesyłanych do udostępnienia 45


w Portalu on-line dokumentacji multimedialnej do zunifikowanej, optymalnej, ustalonej z Zamawiającym wielkości oraz formatu.

Integracja.9 Moduł musi pozwalać na eksport plików każdego typu, które są powiązane z rekordem obiektu w Ewidencji Zbiorów Muzealnych i oznaczone tam statusem "gotowy do publikacji”.

Integracja.10 Moduł musi uwzględniać prezentację w Portalu on-line rekordów obiektów złożonych i zespołów.

Integracja.11 Nowo powstające oprogramowanie musi zostać dostosowane do istniejącego Portalu on-line MSŁ.

Integracja.12 Integracja musi umożliwiać przyporządkowanie, publikację odpowiednich danych (rekordu obiektu wraz z ew. dokumentacją multimedialną) eksportowanych z Ewidencji w odpowiednich kolekcjach (zakładkach) Portalu on-line.

Integracja.13 Moduł musi zapewniać funkcjonalność usuwania danych z bazy danych Portalu w przypadku, gdy dla danego obiektu zostanie ustawiony odpowiedni status.

Integracja.14 Moduł musi zapewniać integrację z systemem KRONIK@ zgodnie z obowiązującymi przepisami prawa powszechnie obowiązującego i zgodnie ze standardem opublikowanym na stronie https://www.gov.pl/web/cyfryzacja/kronik-krajowe-repozytorium-obiektow-nauki-i-kulturyDane udostępniane do Systemu KRONIK@ będą udostępniane niezależnie od wyszukiwarki obiektów, która będzie dostępna w Module i wymogu logowania się użytkownika.

Moduł Procedury

Procedury.1 Szereg procedur muzealnych, jak np. akcesja, użyczenia, wypożyczenia, konserwacje, kwerendy, realizacja zamówień fotograficznych, wypożyczenia kopii ekspozycyjnych dzieła wymaga współdziałania szeregu komórek muzeum program musi posiadać narzędzia umożliwiające pracę grupową.

46

https://www.gov.pl/web/cyfryzacja/kronik-krajowe-repozytorium-obiektow-nauki-i-kultury

https://www.gov.pl/web/cyfryzacja/kronik-krajowe-repozytorium-obiektow-nauki-i-kultury


Procedury.2 Moduł musi umożliwiać ustalanie sekwencji zdarzeń, ustawienie i kontrolę realizacji terminów procesów (np. informować o kolizji terminów, o zaplanowaniu kilku zadań w tym samym czasie odnośnie rekordów obiektu).

Procedury.3 Moduł musi umożliwić przesyłanie rezultatów pracy pomiędzy komórkami (np. rejestrów) oraz powiadamiania (w tym także generowania powiadomień mailowych) o przydzieleniu zadań i o wykonaniu zadań.

Procedury.4 Moduł musi umożliwić wznawianie wykonanych zadań w razie potrzeby zmiany zakresu obiektów muzealnych związanych z zadaniem, dat zadania/procesu (np. zmiana ilości użyczonych obiektów, zmiana terminów (prolongata).

Procedury.5 Narzędzia pracy grupowej muszą umożliwiać przydzielanie zadań do jednego lub wielu poszczególnych użytkowników oraz do zbiorów użytkowników, przede wszystkim użytkowników przypisanych do jednostek organizacyjnych.

Procedury.7 Moduł musi być rodzajem platformy do pracy dla różnych działów wymieniających się danymi i odznaczającymi swój udział na różnych etapach realizacji danego procesu.

Procedury.8 Moduł musi informować użytkowników o zmianie statusu sprawy w danym procesie automatycznie na pracowniczy adres mailowy (np. że daną pracę należy przygotować do użyczenia, zdjąć ze stałej ekspozycji, albo po prostu, że zostały jeszcze np. trzy tygodnie do początku użyczenia, lub do umówionego terminu transportu).

Procedury.9 Moduł musi umożliwiać generowanie listy obiektów zaangażowanych w dane procesy (np. zarezerwowanych do wypożyczenia, obecnych na wystawach własnych i cudzych, wykaz prac artysty ze wskazaniem na co i kiedy są zarezerwowane, itd.). Listy powinny być możliwe do generowania w różny sposób (np. wyłącznie obiekty główne bez

47


podkart).

Procedury.10 W ramach kompleksowego zajmowania się procesami związanymi z zarządzaniem zbiorami moduł musi mieć skonstruowane możliwie prosto sposoby linkowania dzieł zaangażowanych w danych proces z wydarzeniami, które ich dotyczą (np. przy wpisywaniu nowej wystawy, możliwość automatycznego podłączenia obiektów w nią zaangażowanych i ta informacja pojawia się automatycznie w rekordzie obiektu – nie trzeba jej osobno wpisywać itd.).

Procedury.11 Moduł musi udostępniać graficzną informację o tym czy dzieło jest w wypożyczeniu, rezerwacji itp. we wszystkich widokach, w których to dzieło się pojawia (sposób i rodzaje koniecznych typów statusu oraz ich oznaczenia do uzgodnienia z Zamawiającym, np. rezerwacja dzieła, akceptacja dyrekcji do wypożyczenia, udział dzieła w ekspozycji na galerii, wydanie dzieła do depozytu, ubytek reinwentaryzowany itd.).

Procedury.12 Musi istnieć możliwość przeglądu wszystkich procedur, w których uczestniczył lub uczestniczy dany obiekt.

Procedury.13 W przypadku procedur, które powodują automatyczne wytworzenie, edycję jakichkolwiek danych lub ich zablokowanie, możliwość wprowadzania niezbędnych zmian i korekt przez odpowiednio upoważnionych użytkowników.

Procedury.14 W szczególności moduł musi posiadać narzędzia wspomagające terminowe zamykanie wszelkich procedur, w szczególności takich jak terminowy zwrot obiektów właścicielowi, takie jak przypomnienia systemowe. Moduł powinien wspomagać działanie tych procedur na przykład poprzez wysyłanie e-maila do osób pracujących w procedurze o zbliżającym się terminie wypożyczenia itd.

48


Moduł Repozytorium Zdigitalizowanych Dzieł

Repozytorium.1

Oprogramowanie składujące, zabezpieczające i udostępniające zasoby zdigitalizowanych dzieł.

Repozytorium.2 Moduł RZD ma pełnić funkcję „magazynu” zdigitalizowanych dzieł, tj. plików graficznych, multimedialnych a także skanów dokumentów oraz innych plików funkcjonujących w Systemie jako załączniki. Użytkownik będzie zarządzał zdigitalizowanym zbiorem poprzez moduł Obiekty.

Repozytorium.3 W Repozytorium Zdigitalizowanych Dzieł musi powstać struktura katalogów ustalona z Zamawiającym na Etapie I.

Repozytorium.4 Zamawiający dopuszcza możliwość wgrywania do repozytorium dużych plików z pominięciem modułu Obiekty, gdy z uwagi na ograniczenia technologiczne, przesyłanie dużych plików nie będzie możliwe do realizacji bezpośrednio z modułu Obiekty. Dostęp do wgrywania plików do RZD poza modułem Obiekty, musi być ograniczone do grupy osób posiadających

49


odpowiednie uprawnienia.

Repozytorium.5 Moduł RZD musi udostępniać przechowywane pliki do innych modułów oraz Portalu poprzez API – Moduł integracyjny lub Moduł Publicznego API.

Repozytorium.6 Moduł w ramach repozytorium musi obsługiwać wszystkie typy dokumentacji (obraz, dźwięk, video, tekst).

Repozytorium.7 Moduł musi być wykonany w technologii umożliwiającej realizację kopii zapasowych zgodnie z funkcjonalnościami opisanymi dla komponentu kopii zapasowych.

Repozytorium.8 Moduł musi zapewniać funkcjonalność wersjonowania przechowywanych plików.

Repozytorium.9 Administrator Systemu musi mieć możliwość bezpośredniego dostępu do plików zeskładowanych w RZD.

Repozytorium.10 Moduł musi funkcjonować na macierzach dyskowych dostarczonych przez Wykonawcę w ramach Zamówienia, skonfigurowanych w sposób zapewniający odpowiedni poziom redundancji na poziomie sprzętowych macierzy.

Wymagania dla funkcjonalności kopii zapasowych

Zaoferowane rozwiązania w zakresie wykonywania kopii zapasowych musi zapewnić tworzenie kopii zapasowej danych oraz wszystkich elementów aplikacji w czasie normalnej pracy Systemu.

Zaoferowane rozwiązania w zakresie wykonywania kopii zapasowych musi zapewnić kopie obiektów bezpośrednio w bazie danych, np. tabel oraz otwartych plików, plików systemowych, itp.

Zaoferowane rozwiązania w zakresie wykonywania kopii zapasowych musi zapewnić wykonywania kopii zapasowych w trybie kopii pełnej oraz kopii przyrostowej lub różnicowej.

System kopii zapasowej musi zapewnić zapis danych w kopii na dedykowane urządzenie, którą to w ramach całego Systemu dostarczy

50


Wykonawca.

Zaoferowane rozwiązania w zakresie wykonywania kopii zapasowych musi zapewnić mechanizm deduplikacji danych.

Zaoferowane rozwiązania w zakresie wykonywania kopii zapasowych musi zapewnić skuteczne mechanizmy odtwarzania danych z wykonanych kopii zapasowych.

Wykonawca musi wykonać pełną dokumentacje tworzenia kopii zapasowych oraz przywracania danych w przypadku awarii systemu. Dokumentację należy dołączyć do dokumentacji całego Systemu.

51

msl.org.pl · Web viewWord, PDF) oraz fotografii i multimediów, także możliwość tworzenia...

Documents

Transcript of msl.org.pl · Web viewWord, PDF) oraz fotografii i multimediów, także możliwość tworzenia...