Usługa informatyczna pn.: Platforma Wymiany Informacji etap I

Wielkość lub zakres

Szczegółowy opis przedmiotu zamówieniaNazwa zamówienia: Usługa informatyczna pn.: Platforma Wymiany Informacji etap IZamiarem Zamawiającego – Opolskiego Centrum Rozwoju Gospodarczego, w ramach projektu pn.: „Opolska Platforma Innowacji”, jest stworzenie:— platformy cyfrowej „szytą na miarę” dla Zamawiającego (dalej „Serwisy PWI”, „serwis internetowy”, „serwis”) zapewniającej wymianę informacji, promocję i wsparcie dla podmiotów, organizacji i instytucji z województwa opolskiego.Platforma IT powinna zaspokoić opisane w tym dokumencie i zidentyfikowane w wyniku realizacji przedmiotu zamówienia potrzeby informacyjne Zamawiającego.W ramach projektu stworzony zostanie serwis internetowy opi.opolskie.pl oraz Klub150.opolskie.pl stanowiące platformę cyfrową dla partnerów OPI, członków Klubu 150, pracowników OCRG oraz pozostałych podmiotów o charakterze regionalnym, działających w podobnym obszarze tematycznym.W serwisie będą prezentowane informacje i dane dotyczące:— problemów inwestycyjnych,— działań wspierających rozwój inwestycji,— programów realizowanych na terenie województwa opolskiego,— firmy, instytucji i organizacji działających w regionie.Serwisu OCRG będą miały również charakter portalu społecznościowego, którego zadaniem będzie:— współdzielenie się wiedzą, doświadczeniem i zasobami,— konsultowanie i monitorowanie realizacji projektów,— nawiązywanie kontaktów biznesowych,— promocja firm, instytucji i przedsięwzięć.Przedmiotem niniejszego zamówienia jest wykonanie zadania wynikającego z zapotrzebowania na współdzielenie danych zarówno wewnątrz organizacji, jak i w kontaktach zewnętrznych oraz promocję inicjatyw w regionie i skierowanych do podmiotów z terenu województwa.1. Wymagania dla Serwisów Platformy Wymiany Innowacji1.1. Podstawowe założenia systemuZamawiający wymaga dostawy systemu zarządzania treścią (CMS), systemu do tworzenia i zarządzania portalem internetowym, pozwalającego w swobodny sposób na zarządzanie zawartością stron WWW przez użytkowników kreujących treści oraz kodu źródłowego dostarczonego systemu. Portal powinien realizować poniższe funkcje:1) Zawierać mechanizm tworzenia stron internetowych dla dowolnej ilości stron, w dowolnej szacie graficznej.2) Umożliwiać dynamiczne zarządzanie treściami publikowanych dokumentów i serwisów,3) Zapewniać rejestrowanie i uwierzytelnianie użytkowników.4) Dostęp do części aplikacyjnej portalu powinien być zabezpieczony mechanizmami uwierzytelniania i autoryzacji.5) Umożliwiać wyszukiwanie dokumentów i informacji publikowanych w serwisie na podstawie zdefiniowanych kryteriów.6) Zawierać integralny mechanizm tworzenie raportów obrazujących statystyki wykorzystania serwisu, ilość odsłon poszczególnych części serwisu.7) Powinien być tworzony zgodnie z obowiązującymi standardami tworzenia serwisów internetowych (szczegółowe informacje znajdują się w wymaganiach technicznych dla tworzonego rozwiązania).8) Na dzień wdrożenia system CMS musi być zgodny z aktualnym stanem prawnym w tym wymaganiami określonymi w Rozporządzeniu Rady Ministrów z dnia 11 października 2005 roku w sprawie minimalnych wymagań dla systemów teleinformatycznych.9) System CMS musi mieć możliwość prezentowania informacji / dokumentów w sposób pozwalający na ich wykorzystanie przez osoby niedowidzące zgodnie z inicjatywą WAI organizacji W3C oraz prezentowania treści portalu w formie audio (synteza mowy).10) Pojedyncza instalacja systemu CMS powinna mieć możliwość obsługi wielu portali umieszczonych na serwerze zlokalizowanych pod wieloma domenami internetowymi, gdzie pod każdą domeną może znajdować się oddzielny serwis poświęcony konkretnej tematyce.11) System CMS powinien udostępniać opcję umieszczania w stopce lub nagłówku artykułu informację o dacie utworzenia, modyfikacji oraz autorze artykułu.12) System CMS musi umożliwiać umieszczanie i prezentację przy wykorzystaniu przeglądarki internetowej uruchomionej na komputerze użytkownika plików o dowolnym formacie, standardowo wykorzystywanych w systemach internetowych. Mogą to być różnego rodzaju pliki – tekstowe, grafiki, zdjęcia, prezentacje, animacje flash, audio, video, audio-video itp.13) System CMS musi posiadać funkcjonalność wyszukiwania informacji. Mechanizm wyszukiwania musi posiadać funkcję wyszukiwania pełnotekstowego w treściach zamieszczonych w Systemie CMS oraz wyszukiwania prostego i zaawansowanego.14) System CMS musi mieć możliwość uruchamiania kanałów informacyjnych w formatach RSS, Atom, XML oraz newsletter.15) System CMS musi umożliwiać nadawanie określonych uprawnień poszczególnym użytkownikom zaangażowanym w proces publikacyjny, na poszczególnych jego etapach (np.: redaktor, korektor, zatwierdzający, publikujący).16) System CMS musi umożliwiać jednoczesną pracę wielu użytkownikom w pełnym udostępnionym im zakresie.17) Administrator Systemu CMS musi posiadać możliwość tworzenia grup kompetencyjnych (np. administratorzy, redaktorzy, moderatorzy itp.). Użytkownicy z poszczególnych grup mogą posiadać zróżnicowane prawa dostępu do określonych części serwisu (np. działów tematycznych lub typów informacji, stron danego działania) oraz określonych czynności (np. tworzenie treści, edycja, usuwanie, korygowanie menu). Administrator musi posiadać indywidualne prawo przydzielania dostępu do poszczególnych sekcji panelu administracyjnego.18) System CMS musi posiadać i udostępniać panel administracyjny. Panel administracyjny i jego pełna funkcjonalność, musi być dostępna po zalogowaniu przez użytkownika poprzez przeglądarkę internetową.19) System CMS musi zawierać narzędzia służące do budowy i zarządzania strukturą portali, możliwość samodzielnej budowy menu oraz dodawania menu w dowolnych miejscach.20) W panelu administracyjnym powinna być dostępna opcja wyświetlania ostatnio dodanych lub zmodyfikowanych artykułów.21) System CMS musi posiadać możliwość przywrócenia usuniętych elementów .22) W panelu administracyjnym w obszarze edycji menu kolejność elementów menu może zostać dowolnie ustalona. Każdą dokonaną zmianę zawartości menu z poziomu panelu administracyjnego należy zaakceptować by była widoczna na stronie zewnętrznej danego portalu.23) System CMS musi posiadać funkcjonalność generowania mapy strony.24) Wymagane jest, aby system CMS był zbudowany z modułów umożliwiających elastyczne dopasowania systemu do potrzeb. Moduły muszą być w pełni kompatybilne ze sobą, jak i ze źródłem systemu. Ponadto moduły muszą mieć możliwość rozbudowy lub zmian. Kod źródła systemu powinien być tak skonstruowany, aby możliwe było tworzenie dodatkowych modułów funkcjonalne systemu. Każdy moduł zawarty w systemie można wykorzystać wielokrotnie na wielu portalach zawartych w systemie CMS.25) System CMS musi umożliwiać tworzenie przez użytkownika wewnętrznego, bez znajomości programowania, formularzy wraz z bazami gromadzącymi dane zebrane przez formularze. Użytkownik wewnętrzny powinien mieć możliwość przeglądania oraz sortowania rekordów utworzonej bazy oraz ich eksportu w postaci listy do pliku .xls, .csv, oraz .txt. Przed opublikowaniem formularza użytkownik wewnętrzny powinien mieć możliwość przetestowania utworzonego formularza z bazą. Użytkownik powinien mieć możliwość w prosty sposób podpięcia formularza do danego miejsca w portalu lub w treści artykułu.26) System CMS musi posiadać buforowanie zawartości stron (Web cashing).27) System CMS powinien posiadać funkcjonalność umożliwiającą zgłaszanie błędów przez użytkowników zewnętrznych – dostępna np. jako mała ikona pod każdym materiałem.28) System CMS musi posiadać moduł galerii zdjęć, plików audio, plików wideo oraz innych plików z możliwością podziału tematycznego, ich dodawania, usuwania, zmiany katalogu np. przez użytkownika wewnętrznego z odpowiednimi uprawnieniami nadanymi przez administratora.29) System CMS musi posiadać mechanizm pozwalający na łatwe umieszczenie wprowadzonej do niego treści we wskazanej lokalizacji. System CMS powinien dopuszczać sposób modyfikacji prezentowania publikowanych informacji poprzez: tworzenie nowych szablonów, modyfikację istniejących szablonów, modyfikację układu, zawartości i sposobu prezentacji informacji (kolor, kształt elementów składowych, np.: czcionki, elementy graficzne).30) System CMS musi posiadać funkcję podglądu i testowania nowo utworzonych elementów/wprowadzonych materiałów w celu ich weryfikacji przed ich powszechnym udostępnieniem.31) System CMS musi mieć możliwość określania czasu publikacji treści (treść będzie dostępna w Internecie wyłącznie w określonym przez użytkownika wewnętrznego przedziale czasowym).32) System CMS musi wykorzystywać tzw. szablony. Sposób prezentacji (w tym wydruk) i aranżacja obiektów umieszczonych w serwisach będzie określana za ich pomocą. Będą one stanowiły integralny element Systemu, tzn. podlegały zarządzaniu i wersjonowaniu. To, jaki szablon używany jest do wizualizacji i jakiego obiektu (strony), określa Użytkownik wewnętrzny, dysponujący odpowiednimi uprawnieniami w systemie, poprzez „dowiązanie” szablonu do instalacji tego obiektu.33) System CMS musi posiadać repozytorium plików graficznych, multimedialnych, dokumentów PDF, plików tekstowych, wideo, dźwiękowych itp. Zasoby zebrane w repozytorium mogą być wykorzystane wielokrotnie w różnych miejscach portali. Podczas edycji lub tworzenia artykułu dostępny jest panel umożliwiający przeglądanie całego repozytorium z możliwością wybrania plików do publikacji. Każdemu elementowi w repozytorium przypisywany będzie unikalny identyfikator. Administrator ma możliwość nadawania praw użytkownikom do umieszczania, edycji i usuwania plików z repozytorium.34) Każdy artykuł stworzony w systemie może być publikowany w wielu miejscach niezależnie. Może być dostępny również jako skrót w Aktualnościach, w nagłówkach RSS, Newsletterach, dodatkowo fragment artykułu może pojawić się w postaci nadruku na ilustracji w innym miejscu serwisu. Reedycja artykułu po uzyskaniu akceptacji powinna spowodować aktualizację we wszystkich miejscach, w których artykuł został użyty.35) Każda strona serwisu musi mieć możliwość wysłania powiadomienia mailem do innego użytkownika o danym dokumencie.36) Możliwość drukowania treści strony w wersji przygotowanej do tego celu oraz generowania dokumentów/stron w wersji „do druku". Wersja „do druku" powinna zawierać jedynie główną część informacji wyświetlanych na stronie tj. bez nagłówka, stopki lub innych elementów nawigacyjnych wraz z umieszczeniem adresu strony, z której dokonywany jest wydruk oraz datę wygenerowania wersji do druku.37) Praca użytkowników wewnętrznych serwisów powinna być intuicyjna i pozbawiona elementów technicznych typowych dla pracy webmastera. Pracujący w trybie online edytor WYSIWYG powinien pozwalać na pracę z tekstami publikowanymi w serwisach. Możliwość edycji materiału w języku HTML powinna stanowić opcję przeznaczoną dla bardziej zaawansowanych użytkowników.38) Każdy dokument tworzony w CMS może zostać w dowolnej chwili zapisany jako wersja robocza. Taki niedokończony dokument powinien być zapamiętywany w systemie i nie powinien być kierowany do publikacji – w każdym momencie można jednak do niego wrócić i po uzyskaniu satysfakcjonującej postaci opublikować.39) System CMS musi zapewniać wersjonowanie stron oraz dokumentów w nim umieszczonych.40) System CMS musi mieć mechanizm rejestrowania i przeglądu operacji (tj.: utworzenie, modyfikacja, zablokowanie, usunięcie, zmiana stanu) na jego dokumentach, stronach i ich zawartości, przy czym muszą być również rejestrowane dane pozwalające ustalić, kto i kiedy wykonywał daną operację. Dane gromadzone w ten sposób muszą m.in. zasilać system raportowania.41) W Systemie CMS musi być możliwość obejrzenia historii operacji na wybranej stronie, jej zawartości, dokumencie oraz historii przebiegu procesu publikacyjnego.42) System CMS powinien umożliwiać rejestrowanie statystyk odsłon stron, pobrań plików oraz wpisywanych wyrazów w wyszukiwarce np. System CMS powinien posiadać opcję statystyk użytkowników (rejestrowanie czasu przebywania na witrynie, najczęściej oglądane artykuły itd.).43) System CMS musi posiadać mechanizm autoryzowania przez redaktora strony każdej informacji udostępnionej w Internecie. Dotyczy to w szczególności mechanizmu forum dyskusyjnego.44) Usługi muszą wykorzystywać standardy dla struktur danych w postaci XML, dla komunikatów w oparciu o protokół SOAP 1.2. Dla opracowanych usług muszą zostać dostarczone również opisy interfejsów w postaci zbiorów WSDL i XSD. 36. Mechanizmy integracyjne Systemu CMS muszą zawierać Szynę Integracyjną (SI), która obsługuje następujące usługi:a. usługi zarządzania tożsamością;b. usługi zachowania poufności i bezpieczeństwa;c. usługi prezentacji i punktu dostępu;d. usługi publikacji i wyszukiwania usług;e. usługi dostępu do rejestrów i baz danych;f. usługi integracyjne;g. usługi operowania danymi;h. usługi zarządzania systemem;i. usługi komunikacyjne.1.2. Wymagania techniczne dla dostarczanego rozwiązania45) Lokalizacja Serwisów OPI wraz z infrastrukturą sprzętową oraz oprogramowaniem systemowym i bazodanowym jest zapewniona przez Zamawiającego i pozostaje poza projektem. Infrastruktura zbudowana jest w oparciu o opis architektury dostarczony przez Wykonawcę w ramach Oferty.46) Interfejs użytkownika systemu nie może wymagać instalowania na stacjach roboczych żadnych elementów aplikacji odpowiedzialnych za przetwarzanie danych systemu. Na stacjach roboczych mogą być instalowane tylko i wyłącznie komponenty odpowiedzialne za komunikację z serwerami i obsługę warstwy prezentacyjnej systemu.47) Serwisy informacyjne będą oparte na relacyjnych lub relacyjno-obiektowych bazach danych, wyposażone w narzędzia zarządzania treścią (CMS), dokumentami i aplikacjami przy pomocy dostarczonych narzędzi administratorskich.48) Serwis powinien umożliwiać publikację dokumentów w formacie: HTML, XHTML, XML, XSD, PDF, formatach tekstowych i pochodnych.49) Całość rozwiązania musi być napisana i pracować w architekturze zorientowanej na usługi (SOA). Dla wszystkich obszarów funkcjonalnych systemu, musi być wydzielona warstwa integracyjna, która będzie odpowiedzialna za integrację z zewnętrznymi źródłami danych oraz udostępniać im dane z systemu w formie API.50) Do każdej części serwisu musi być możliwość podania unikatowego adresu URL.51) Wszystkie aplikacje dostarczone w ramach zadania będą musiały spełnić warunki określone w rozporządzeniu Rady Ministrów dotyczącym Krajowych Ram Interoperacyjności.52) System ma umożliwiać zdalny dostęp do jego funkcjonalności i mechanizmów z wykorzystaniem bezpiecznego protokołu https.53) Portal musi umożliwiać zdalne edytowanie treści przez niego zarządzanych, z wykorzystaniem bezpiecznego protokołu https.54) Zamawiający wymaga, aby portale i strony wygenerowane przez system były prawidłowo obsługiwane przez przeglądarki MS Internet Explorer 8.x, 9.x; Mozilla Firefox 3.x, 4.x, 5.x; Google Chrome 12.x; Opera 11.x; Apple Safari 5.x.55) Zamawiający wymaga, aby system zapewniał bezpieczną transmisję danych między aplikacjami, apletami klienckimi a centralną bazą danych systemu (zabezpieczoną przed niepowołanym odczytem i modyfikacją) w ramach definiowalnych ustawień systemu.56) Portal musi wspierać rozwiązania klastrowe, realizowane przy pomocy narzędzi wykorzystanych w projekcie.57) Serwis powinien zostać wykonany w zgodności z następującymi standardami:a. XHTML 1.1,b. CSS 2.1,c. WCAG 2.0,d. Section 508e. Strony serwisu muszą być zgodne ze standardami tworzenia stron internetowych W3C. Muszą one pomyślnie przejść weryfikację przez walidatory znajdujące się na stronach http://validator.w3.org/ (weryfikacja XHTML) oraz http://1iasaw.w3.org/cssvalidator/ (weryfikacja CSS).Zamawiający wymaga utworzenia systemu kont o uprawnieniach administratorskich, pozwalającego na zarządzanie całym portalem lub jego częścią.1.3. Panel administracyjny Portalu(a) Administracja systememZamawiający oczekuje realizacji następujących funkcji:1) dodawanie, edycja, usuwanie użytkowników,2) określanie roli użytkowników w systemie,3) określanie czasu aktualności (publikacji) dokumentu,4) prowadzenie historii zmian w serwisie (z dostępem do dokumentów archiwalnych),5) skalowalność portalu w zależności od rozdzielczości ekranu,6) indywidualizacja i kategoryzacja, definiowanie dowolnych rodzajów uprawnień oraz hierarchicznej struktury grup użytkowników,7) posiadanie modułu autoryzacyjnego umożliwiającego nakładanie praw do korzystania z wybranych dokumentów i aplikacji,8) funkcje ułatwiające wyszukiwanie potrzebnych informacji, możliwość budowania złożonych kryteriów wyszukiwania i sortowania informacji.1.4. Użytkownicy Portalu(a) Rodzaje kont użytkownikówKonta użytkowników mogą być zakładane przez administratorów kont na różnych poziomach lub samodzielnie przez użytkowników. Zamawiający wymaga, aby system umożliwiał tworzenie następujących rodzajów kont:1. Konta z autoryzacją2. Konta bez autoryzacjiPrzez konta z autoryzacją Zamawiający rozumie konto, dla którego tożsamość jego właściciela została potwierdzona w sposób wymagany przez portal, w szczególności przez osobę trzecią, będącą posiadaczem konta autoryzowanego przez administratora portalu.Wymagany jest mechanizm tworzenia kont w strukturze hierarchicznej, np. administrator – zakłada konto użytkownika z uprawnieniami do zakładania kont – użytkownik z uprawnieniami do zakładania kont (administrator grupy) – zakłada konta standardowym użytkownikom.System powinien umożliwiać tworzenie definiowalnej, hierarchicznej struktury kont użytkowników z mechanizmem zawierania grup.Zamawiający wymaga kratownicowego (zwane także kratowym) systemu uprawnień. Zamawiający wymaga określenia praw dostępu na poziomie funkcjonalności i administrowanych treści, łącznie z możliwością określania funkcji do których dany użytkownik może uzyskać dostęp.System musi rozpoznawać czy dane konto jest kontem z autoryzacją czy bez autoryzacji i po rozpoznaniu tej cechy udostępniać funkcjonalności, bez konieczności dodatkowego definiowania uprawnień.Przez konta bez autoryzacji Zamawiający rozumie konta zakładane przez użytkowników portalu we własnym zakresie. Zamawiający wymaga weryfikacji konta przez wysłanie stosownej wiadomości na wskazany przez zakładającego konto adres poczty elektronicznej. Zamawiający ma mieć możliwość określania, przy pomocy jakiego systemu dostępu użytkownik otrzymuje dostęp do danej funkcjonalności. Zamawiający wymaga mechanizmu autoryzacji poprzez usługi przechowywania tożsamości Google, Facebook, WindowsLiveID.(b) Administracja użytkownikamiZamawiający wymaga, że system umożliwi administrowanie użytkownikami zgodnie z przydzielonymi rolami. Administrator może modyfikować ustawienia dotyczące poszczególnych ról. Może także w zależności od posiadanej roli – zarządzać kontami innych użytkowników, wszystkimi lub tylko niektórymi danymi. Zaimplementowane funkcje muszą zapewnić zgodność systemu z wymogami Ustawy o ochronie danych osobowych.W programie musi istnieć możliwość automatycznego wylogowania użytkownika po zdefiniowanym okresie bezczynności (czas nieaktywności) oraz zablokowanie dostępu do konta po zdefiniowanej ilości nieudanych prób logowania.(c) Uprawnienia użytkowników do Serwisu1) Administrator – pełen dostęp do ustawień i zawartości serwisu2) Redaktor – dostęp do modyfikacji treści serwisu nadanych przez administratora, brak dostępu do ustawień serwisu.3) Moderator – dostęp do modyfikacji treści serwisu nadanych przez administratora, brak dostępu do ustawień serwisu.4) Użytkownik zarejestrowany ma dostęp tylko do odczytu, i do wpisywania informacji, które wynikają z danej funkcjonalności (np. forum, formularz rejestracyjny, itd.)5) Użytkownik – osoba przeglądająca treści serwisu bez możliwości logowania.(d) Bezpieczeństwo dostępu i zawartościCMS musi posiadać tzw. Moduł bezpieczeństwa. Jego zadanie to bezpieczne prezentowanie treści, zarządzanie formularzami internetowymi, walidacja danych wprowadzanych z Internetu, dodawanie walidacji w oparciu o tzw. Captcha, posiadanie filtru wprowadzanych treści w oparciu o tzw. Słownik wulgaryzmów. Moduł bezpieczeństwa, dynamicznie podmieniając i rozszerzając odpowiednie elementy, które użytkownik wstawił na stronie lub zostały wygenerowane z opisu formularza w XML, musi zabezpieczyć system przed atakami, w szczególności przed atakami typu SQL Injection.Funkcje systemu oraz jego zasoby informacyjne muszą zostać zabezpieczone za pomocą systemu kontroli uprawnień który pozwoli kontrolować co najmniej następujące uprawnienia:1) logowanie do systemu;2) uruchomienie modułu/funkcji;3) wytworzenie rekordu;4) wyświetlenie rekordu;5) zmiana rekordu;6) usunięcie rekordu.Zamawiający oczekuje, iż dostęp do narzędzi będzie się określać dla poszczególnych grup użytkowników, tak aby dokładnie określić jaki poziom dostępu daje dostęp do jakich narzędzi:1) edycja treści – możliwość edytowania i usuwania treści oraz możliwość wyłączania treści lub włączenia/wyłączenia w określonym czasie,2) formatowanie treści – podstawowe funkcjonalności umożliwiające formatowanie treści przy pomocy edytora WYSIWYG np. bold, kursywa, hiperłącze, wstawienie obrazka,3) edycja kategorii – możliwość edycji lub dodania nowej kategorii dla publikowanych treści,4) komentarze – możliwość dodania komentarza do konkretnej treści,5) oceny – możliwość oceniania treści,6) zgłoszenie do moderacji – możliwość zgłoszenia tekstu do moderacji w przypadku podejrzenia naruszenia warunków korzystania z portalu,7) wyszukiwarka – możliwość przeszukania portalu wg frazy podanej w zapytaniu,8) pomoc i FAQ– dostęp do podstawowych informacji dotyczących portalu, najczęściej pojawiające się pytania użytkowników i odpowiedzi oraz dostęp do pomocy przy tworzeniu i edytowaniu treści i opcji np. w formie filmów instruktażowych,9) raporty i statystyki – dostęp do raportów i statystyk poszczególnych grup i użytkowników-takich, których nie dostarczają standardowe narzędzia wchodzące w skład oprogramowania serwera lub zewnętrznych narzędzi (np. google analytics, urchin). Zewnętrzne narzędzie będzie dostarczało informacje dotyczącą częstotliwości odwiedzin strony, ale nie będzie pokazywało statystyki z ilości publikacji danego użytkownika – co powinien pokazać wewnętrzny system raportowania.(e) Bezpieczeństwo prawne portaluZamawiający wymaga mechanizmu pozwalającego na tworzenie niezależnych regulaminów korzystania z poszczególnych usług systemu. Wymagane jest rejestrowanie wyrażonych przez użytkowników oświadczeń woli. Zamawiający wymaga, aby korzystanie z serwisu w części związanej z tworzeniem i wprowadzaniem danych wymagało akceptacji stosownego regulaminu.Każda treść wprowadzona przez użytkowników będzie posiadała opisaną ikonę umożliwiającą zgłoszenie moderacji. Zastosowanie tej ikony pozwoli również na zgłaszanie, że dana treść jest nieaktualna lub wymaga poprawki.Zamawiający oczekuje, iż każdy użytkownik z grupy, która posiada odpowiednie prawa dostępu może edytować treści. Jeżeli grupa jest z ograniczeniami to modyfikowana treść wymaga autoryzacji przez użytkownika lub grupy użytkowników z grupy o wyższych uprawnieniach. Prezentacja wszystkich treści powinna mieć wspólny wygląd niezależnie od miejsca i roli użytkownika.1.5. ŚrodowiskoSystem będzie składał się z następujących środowisk:1) produkcyjnego wraz z zapasowym,2) testowego.3) Zamawiający wymaga, aby Wykonawca w ramach Road Mapy rozwoju oprogramowania zapewnił i przedstawił plany rozwojowe dostarczanego rozwiązania.a. Zapasowe środowisko produkcyjne będzie działało jako pasywna kopia, aktywowana manualnie w wypadku awarii środowiska Produkcyjnego.b. Środowisko testowe powinno być odizolowane od środowiska produkcyjnego na poziomie fizycznych serwerów, a jego sizing powinien odpowiadać 10% wydajności środowiska produkcyjnego.4) Zamawiający wymaga, aby oprogramowanie miało możliwość programowego przerwania wybranych zadań wykonywanych na środowisku.1.6. Wymagania dotyczące prezentacji danych w Portalu(a) FrontendSkórka serwisu (szablon) powinna zostać wykonana zgodnie z aktualnymi najlepszymi praktykami dotyczącymi wydajności aplikacji pod kątem czasu ładowania się strony.W szczególności:1) Wszelkie grafiki wykorzystywane jako elementy interfejsu, powinny być połączone w jeden “sprite”2) Ikony lub inne znaki graficzne powinny być połączone w plik czcionki (woff, ttf) i serwowane jako jeden zasób3) Małe obrazki, będące elementami interfejsu, powinny być zaszyte w plikach css w postaci ciągu data:image base644) Wszelkie zasoby statyczne, będące częścią interfejsu graficznego (css,js, ikony, czcionki, obrazki interfejsu) powinny być serwowane z osobnej subdomeny5) Obrazki niebędące elementami interfejsu powinny być ładowane z wykorzystaniem mechanizmu “lazy load” - co oznacza ich załadowanie dopiero w momencie, gdy użytkownik przewinie stronę w przeglądarce do miejsca w którym powinna się wyświetlić dana grafika.6) Mechanizm lazyload powinien działać także dla elementów poziomych, takich jak karuzela, która standardowo nie podpada pod mechanizmy lazyload, ponieważ mechanizm uznaje, że wszystkie występujące w jej obrębie grafiki, znajdują się w polu widzenia użytkownika - pomiar na podstawie osi pionowej.7) Pliki javascript i css powinny być łączone w jeden plik i kompresowane.8) Biblioteki javascript, takie jak jquery, powinny być pobierane z adresów CDN Google/Microsoft - jako jedyne są wyłączone z obowiązku łączenia i kompresji.9) Ze względu na RFC2616, to aplikacja steruje nagłówkami expires, w związku z czym, obrazki oraz inne elementy statyczne, powinny mieć ustawiony maksymalny czas przedawniania.10) Strony powinny wysyłać nagłówki ETag aby umożliwić weryfikację, czy wersja leżąca w cache przeglądarki jest aktualną wersją strony.11) Wszelkie skrypty powinny być ładowane asynchronicznie, a układ strony i podstawowe definicje elementów powinny zapobiegać “skakaniu” layoutu jeśli któryś ze skryptów zmienia jego wygląd/położenie elementów.12) Reguły CSS oraz modyfikacje w drzewie DOM wykonywane poprzez skrypty javascript, powinny powodować minimalną liczbę zdarzeń typu reflow w przeglądarce.13) Strona może wykorzystywać framework css14) Strona powinna zawierać minimalną ilość kodu html, tak aby proporcja treści strony do kodu wyświetlającego tą treść była jak największa15) Szczególną uwagę należy tutaj zwrócić na generowanie nadmiarowych klas i identyfikatorów, oraz wielokrotnie zagnieżdżonych znaczników, przez system CMS16) Obrazki wysyłane przez serwer nie powinny być kompresowane przez serwer (gzip) a jedynie optymalizowane przez aplikację w momencie generowania miniatur.(b) StyleSystem powinien gwarantować jednolitość styli formatowania tekstu dla całego serwisu (styl domyślny) przyporządkowywany automatycznie niezależnie od użytkownika w zależności od modułów do jakich treść jest wprowadzana.Style powinny być skonstruowane czytelnie na zasadach dziedziczenia i umieszczone w pliku css lub w plikach css o ile takie zastosowanie ma swoje logiczne uzasadnienie wraz z opisem sposobu ich konstrukcji i wskazaniem modułów, dla których są dedykowane.(c) GrafikaNależy opracować szablony dedykowane dla elementów treści tworzonych w ramach serwisu, umożliwiających skalowalność i rozszerzanie serwisu o nowe artykuły i treści. Szczegółowy zakres szablonów i ich zastosowanie zostaną opracowane na etapie projektu serwisu.Portal powinien spełniać poniższe wymagania:1) Projekt koncepcyjny serwisu powinien zawierać propozycje szablonów graficznych opartą na modelu pudełkowym (ang. box model), przy czym system CMS nie powinien stwarzać ograniczeń kompozycyjnych.2) Każda strona WWW winna być generowana dynamicznie, w oparciu o szablony i zawartość baz danych.3) Poszczególne elementy strony jak nagłówek, stopka, treść główna czy menu boczne powinny być tworzone jako samodzielne komponenty.4) Układ graficzny ma pozwalać na opcjonalne umieszczanie na stronie głównej banerów, elementów grafiki reklamowej oraz informacji dodatkowych.5) Powinna zostać przygotowana również "wersja żałobna" Portalu jako alternatywna wersja graficzna wykonana w odcieniach szarości.2. Moduły PortaluLista modułów wraz z opisem funkcjonalnym znajduje się w Załączniku 3.3. Dodatkowa funkcjonalność3.1. Statystki1) Statystyki – zarówno dla całego serwisu oraz poszczególnych jego działów i stron, gromadzące minimum następujące informacje, np.:2) Statystyka liczby wejść na stronę,3) Statystyka ilości odsłon stron (na poziomie pojedynczej podstrony),4) Statystyka ilości odwiedzających,5) Statystyka ilości subskrybentów newsletterów i RSS,6) Statystyka wykorzystania dostępnego pasma – ruch przychodzący i wychodzący,7) Statystyka długości oraz terminy przerw w funkcjonowaniu serwisu8) Statystyka liczby pobrań dla plików umieszczonych w serwisie (na poziomie pojedynczego pliku)9) Statystyki muszą być wyposażone w filtr pozwalający na wyświetlanie danych statystycznych dla wskazanych przedziałów czasowych (od „dzień, miesiąc rok" do„dzień, miesiąc, rok").3.2. Mechanizm analityczny (Google Analytics)1) Strona powinna implementować zbieranie danych za pomocą mechanizmu Google Analytics, zgodnie z instrukcją dostarczoną w ramach specyfikacji strony. Wykonawca powinien zakładać wdrożenie zaawansowanej analityki, w tym wykorzystania mechanizmów takich jak śledzenie zdarzeń, “zmienne niestandardowe”, eCommerce, wirtualne odsłony, zliczanie danych do wielu profili, przekazywanie zmiennych js na potrzeby Tag Managera, oraz różne inne, dowolne modyfikacje kodu Google Analytics.2) Aplikacja powinna przekazywać do kodu strony, zdefiniowane w specyfikacji zmienne, zawierające przykładowo typ wyświetlanej strony, jej autora bądź kategorię w której dany wpis został opublikowany, tak, aby można je było następnie wykorzystać podczas wdrażania zliczania statystyk.3.3. Wyszukiwanie informacjiPortal powinien mieć możliwość wyszukania odpowiednich treści. Lista wymagań dla wyszukiwania informacji została przedstawiona poniżej:1) Wyszukiwarka wewnętrzna będzie jednym z podstawowych narzędzi pozwalających na sprawne i szybkie znajdowanie informacji zawartych na platformie.2) Serwis umożliwi wyszukiwanie informacji w oparciu o wyszukiwarkę zaawansowaną obejmującą przeszukiwanie zawartości serwisu również w plikach tekstowych lub PDF.3) Wyszukiwarka powinna zostać wdrożona z wykorzystaniem usługi Apache Solr w wersji co najmniej 3.5.4) Wyszukiwarka powinna indeksować treści w sposób przyrostowy - bez konieczności zatrzymywania aplikacji na czas reindeksacji treści.5) Dokładna lista indeksowanych pól zostanie dostarczona wykonawcy w ramach specyfikacji serwisu. Wykonawca powinien zakładać, że wyszukiwarka pozwala wyszukiwać po wszystkich polach dostępnych dla danego typu treści.6) Wyszukiwarka powinna wykorzystywać możliwość grupowania wyników (faceting).7) Wyszukiwarka powinna mieć zaimplementowane zaawansowane rozwiązania, takie jak stemming, listy synonimów, listy słów zakazanych (badwords).8) Wyszukiwarka powinna obsługiwać mechanizm automatycznego podpowiadania w polu wyszukiwania serwisu (autocomplete), wyświetlającego wyniki na podstawie ustalonych przez Zleceniodawcę reguł.9) Wyszukiwarka powinna integrować się z systemem w taki sposób, aby możliwe było za jej pomocą ładowanie treści do bloków typu “podobne artykuły”, “ostatnie artykuły”, “tego dnia wydarzyło się” itp.10) Wyszukiwarka powinna umożliwiać konfigurację zaawansowanego algorytmu sortowania wyników na podstawie wag przypisywanych do każdego pola zdefiniowanego dla treści serwisu.11) Wyszukiwarka powinna umożliwiać zmianę algorytmu ważenia w zależności od miejsca w którym wyświetlamy wyniki - inne wagi przypisujemy polom na ekranie wyników wyszukiwania, inne w blokach typu “ostatnie treści”, “podobne artykuły” etc.12) Wyszukiwarka powinna umożliwiać automatyczne podświetlanie wyszukiwanych fraz, bądź ich synonimów na ekranie wyników wyszukiwania, oraz wycinanie fragmentów artykułów, tak aby zajawka artykułu zawierała szukane frazy.3.4. BaneryFunkcjonalność umieszczania banerów w uzgodnionych miejscach Portalu, umożliwiająca samodzielne zarządzanie publikowanymi w portalu banerami informacyjnymi (wydarzenia, konferencje, szkolenia itp.) lub reklamowymi. Będzie umożliwiała kontrolowaną publikację banerów według ustalonych przez administratora kryteriów i kombinacji. Będzie umożliwiała monitorowanie danych o prezentowanych banerach (czas, liczba wyświetleń, kliknięć , itp.). Umożliwiać będzie publikowanie informacji promocyjno– reklamowej oraz monitorowanie jej skuteczności. Jako banera w Portalu redaktor będzie mógł użyć następujących typów obiektu: pliku graficznego (gif, jpg, png, bmp), animacji flash oraz animacji flash ze skryptem, ankiety/sondy, kodu html z innego systemu lub aplikacji. Dodatkowo wyposażony zostanie w Kreator banerów flash umożliwiający wprowadzanie i usuwanie zdjęć , które będą prezentowane w nagłówku w postaci „przechodzenia” kolejno zdjęć . Stwarzać to musi wrażenie animacji flash.Prezentację banerów flash, których zawartość będzie mógł zmieniać redaktor nadzorujący funkcjonalność. Do stworzenia nowej zawartości banera flash nie będzie wymagana żadna wiedza informatyczna. Za pomoc ą przygotowanego formularza można będzie wgrać do wnętrza obiektu flash grafiki i zaplanować sposób ich animacji. Zamawiający oczekuje możliwości prezentacji banerów flash w nagłówku strony. Planowane funkcjonalności w przypadku banera dla pliku graficznego:1) dodawanie i edycja banera,2) wybór miejsca wyświetlania banera na stronie (według ustalonych w projekcie graficznym miejsc banerowych),3) zarządzanie banerem (wybór banera),4) tytuł banera, – plik banera,5) tekst w pozycji „ALT”,6) adres odnośnika,7) wybór sposobu wyświetlania strony, do której prowadzi baner (nowe okno/to samo okno),8) data publikacji od-do,9) godziny wyświetlania banera,10) maksymalna ilość kliknięć ,11) maksymalna ilość wyświetleń,12) ukrycie banera,13) informacja o ustawieniach banerów w formie tabelarycznej.W przypadku innych typów obiektów pola formularza będą dostosowane do jego charakteru. Wymagane formaty plików, które będą zamieszczane jako banery to: jpg, png, swf, gif, animowany gif. Baner będzie mógł być publikowany globalnie dla całego systemu (w tym samym miejscu) lub indywidualnie dla modułów. Będzie istniała możliwość tworzenia grup banerów, dodawania banerów do grupy która będzie publikowana w jednym miejscu. Banery w tym samym miejscu jednej grupy będą posiadały możliwość rotacji i ustawienia jej rodzaju (np. kolejno, losowo).3.5. Wersja dla niepełnosprawnych/słabowidzącychProjekty graficzne wraz z arkuszami CSS powinny uwzględniać potrzeby osób z niepełnosprawnością narządu wzroku i udostępniać takie rozwiązania jak:— Wysoki kontrast - (Włącz / Wyłącz),— Powiększenie / pomniejszenie czcionki,— Współpraca z oprogramowaniem, wspomagającym czytanie,— Możliwość nawigacji z poziomu klawiatury (bez użycia myszki).— Instrukcję korzystania z w/w funkcji.3.6. SEOSerwis powinien być zbudowany zgodnie z aktualnymi najlepszymi praktykami SEO, zaczynając od tak podstawowych spraw, jak przyjazne adresy url, prawidłowe wykorzystanie tagów html na stronie, poprzez pełną implementację mikroformatów, optymalizacji obrazków poprzez automatyczne generowanie ich nazw i wypełnianie pól alt/title, aż po automatyczne mechanizmy pozwalające na szybką indeksację serwisu przez crawlery.Serwis powinien automatycznie tworzyć sitemapy XML (artykuły oraz grafiki), oraz zgłaszać je po wygenerowaniu do Google.Serwis powinien zawierać mechanizmy, które automatycznie będą tworzyły linki dla określonego zestawu fraz, kierujące do innych podstron serwisu, bądź poza serwis.Powyższy mechanizm powinien przewidywać limity liczby linków w pojedynczym artykule.CMS powinien umożliwiać ręczne nadpisanie adresu url danej strony, automatycznie obsługując przekierowania z wszystkich poprzednich adresów za pomocą przekierowania 301.CMS w ramach obsługi przyjaznych adresów, nie powinien pozwalać na indeksowanie stron w ścieżkach systemowych, takich jak /taxonomy/term/1, lecz automatycznie przekierowywać z nich na prawidłowy, przyjazny adres, który będzie indeksowany.Wdrożenie powinno zagwarantować 100% przekierowań z poprzednich adresów, pod którymi występowały artykuły na nowe adresy w obrębie nowego systemu. Przekierowania te dotyczą także stron innych, które także będą migrowane w obręb serwisu.W przypadku, gdy artykuł jest pisany w języku innym niż angielski lub polski, adresy URL artykułów (slugi), powinny być tworzone na podstawie dodatkowego pola, w które autor wpisu wprowadzi tytuł artykułu po angielsku. System nie powinien tego procesu automatyzować, a pole powinno być obowiązkowe.3.7. Integracja z Socjal MediaSerwis internetowy (Portal) musi zapewniać możliwość integracji z najpopularniejszymi serwisami społecznościowymi działającym w sieci Internet, takimi jak:1) Twitter,2) Facebook,3) Pinterest.Dokładny poziom integracji zostanie określony w specyfikacji serwisu.Wykonawca powinien zakładać, że jest to ponadstandardowy poziom integracji, wykorzystujący przykładowo automatyczne wstawianie danych opengraph na potrzeby serwisu Facebook, automatyczne skracanie adresów url przy wysyłaniu informacji na serwis Twitter, możliwość automatycznego eksportu galerii do serwisu Pinterest, możliwość wykorzystania mechanizmu “social reading” serwisu Facebook, możliwość wykorzystania mechanizmu komentarzy Facebook dołączanych do wpisu, wraz z wyświetlaniem w treści strony kopii tych komentarzy, tak aby były one indeksowane przez roboty wyszukiwarek.3.8. Wersja mobilnaSerwis poza responsive layout, powinien mieć przygotowaną wersję mobilną serwisu z osobnym layoutem. Wersja mobilna powinna umożliwiać użytkownikowi przełączenie się z powrotem to standardowej wersji serwisu, i pamiętać ten wybór. Zamawiający wymaga, aby portale i strony wygenerowane przez system były prawidłowo obsługiwane na urządzeniach mobilnych, w szczególności na urządzeniach pod kontrolą systemu Android i Windows Phone.3.9. MultisiteSystem powinien obsługiwać wiele domen/subdomen bez konieczności stawiania osobnej kopii aplikacji. Solr powinien wiedzieć, że dany artykuł jest z konkretnej domeny i umożliwiać filtrowanie po tym polu.ACL systemu powinien umożliwiać sterowanie dostępem użytkownika do konkretnej domeny z różnymi poziomami uprawnień - przykładowo, ten sam użytkownik może być redaktorem naczelnym jednego z podserwisów, ale na innym serwisie ma pozycję redaktora.3.10. WielojęzykowośćSystem powinien umożliwiać tworzenie wielu wersji językowych danej strony. Powinien pozwalać na tłumaczenie artykułów ale także na pisanie zupełnie niezależnych treści dla danej wersji językowej.Interfejs serwisu powinien być w pełni w języku polskim i przetłumaczony na języki angielski oraz umożliwiać tłumaczenie na inne języki.Serwis powinien w pełni obsługiwać zapisy języków z rodzin:1) wschodniosłowiańskiej (cyrylica),2) chińsko-tybetańskiej,3) afroazjatyckiej (zapis od prawej do lewej).3.11. Okresowe zadania konserwacyjne dla Serwisu1) System CMS powinien posiadać automatyczne zadania konserwujące, odpalane za pomocą mechanizmu CRON. Mechanizm ten powinien działać niezależnie od ruchu na stronie - to znaczy, że nie może być wywoływany w momencie wejścia użytkownika na stronę, lecz za pomocą wewnętrznego dziennika zadań systemu. Mechanizmy te powinny dbać o odświeżanie wszelkiego typu indeksów, cache, logów itp. mechanizmów które mogą sprawić, że aplikacja będzie działała wolniej niż zakładane w SLA parametry.2) System powinien automatycznie sprawdzać dostępność aktualizacji i informować o wszelkich znanych zagrożeniach, zarówno administratora aplikacji po stronie OCRG, jak i osobę odpowiedzialną po stronie Wykonawcy.3.12. Obsługa błędów1) Wszelkie błędy, zarówno te leżące po stronie aplikacji (404 etc.) jak i te leżące po stronie serwera (500, 503), powinny mieć przygotowane osobne layouty, prezentujące użytkownikowi informacje o problemie.2) Strony te powinny także mieć wdrożone śledzenie w Google Analytics aby umożliwić centralne zbieranie informacji o błędach.3) Aplikacja powinna zapisywać informacje o błędach aby umożliwić identyfikację ich przyczyn i ułatwić zapobieganie ich kolejnym wystąpieniom.4) Aplikacja powinna przechowywać informacje o 5000 ostatnich błędów (system powinien automatycznie odcinać starsze dane).4. Bezpieczeństwo1) Wykonawca zobowiązany jest do wykonania pełnej dokumentacji bezpieczeństwa i bezpiecznego dostępu do serwisu, danych.2) System powinien szyfrować hasła użytkowników za pomocą bcrypt, z unikalną “solą” dla każdego użytkownika.3) Hasło, zarówno w formie plaintext jak i zahashowanej, nie powinno się znaleźć w żadnym typie pamięci cache.4) Kopia deweloperska serwisu powinna anonimizować bazę poprzez nadpisywanie losowymi wartościami wszelkich danych osobowych w niej zawartych. Powinna też nadpisywać hasła użytkowników tak aby jej wykradzenie nie pozwalało na uzyskanie dostępu do wersji live serwisu.5) Serwis powinien umożliwiać logowanie się użytkownikom tylko z określonych zakresów adresów IP.6) Wszelkie dodatkowe usługi wykorzystywane przez aplikacje, powinny być dokładnie opisane, wraz z informacjami w jaki sposób aplikacja się z nimi komunikuje. przykładem może być tutaj usługa memcache, która powinna komunikować się na porcie 11211 i ograniczać możliwość łączenia się z nią tylko do adresu IP serwera na którym stoi aplikacja. Inne, przykładowe usługi: Varnish, Solr, redis, aplikacja skracająca adresy URL.7) Wszelkie pola formularzy powinny podlegać walidacji zarówno po stronie przeglądarki użytkownika, jak i po stronie systemu.8) Zapytania do baz danych powinny być zabezpieczone przed atakami typu SQL injection, w szczególności powinny używać parametrów.9) Mechanizmy obsługujące ładowanie do serwisu zdjęć, powinny być zabezpieczone przed atakami LFI i innymi, które można wykonać z pomocą tego typu mechanizmów.10) Pliki cookie powinny być zabezpieczone przed dostępem z poziomu skryptów javascript poprzez ustawienie flag HTTP only.11) Wykonawca, w ramach zlecenia przeprowadzi testy bezpieczeństwa aplikacji za pomocą narzędzia klasy skipfish, rozwiąże wszelkie znalezione problemy i usunie luki bezpieczeństwa oraz dostarczy Zleceniodawcy finalny raport z automatycznego audytu wykonanego tym narzędziem.12) Serwis powinien zapewniać bezpieczeństwo i być odpornym na:a. Parameter Tamperingb. SQL Injectionc. HTML Injectiond. Command Injectione. XSS - Cross-Site-Scriptingf. CSRF - Cross Site Request Forgeriesg. CRLF Injectionh. Denial of Service - i odmiany tego ataku (DDoS - Distributed Denial of Service, DRDoS - Distributed Reflection Denial of Server, Session DoS, Buffer-Overflow) 9.3.10.Google Hackingi. Path Traversal, Directory Traversalj. Forceful Browning13) Bezpieczeństwo informacji rozumiane jest - zgodnie z normą PN-ISO/IEC 27001:2007 - jako zachowanie poufności, integralności i dostępności informacji. Dodatkowo mogą być brane pod uwagę inne własności, takie jak autentyczność, rozliczalność, nie zaprzeczalność i niezawodność.14) Mechanizmy bezpieczeństwa, zastosowane do ochrony informacji, spełniać muszą przynajmniej wymagania określone w Załączniku A do normy PN-ISO/IEC 27001:2007.15) Mechanizmy i procedury zapewnienia ciągłości działania systemu, w tym Plany Ciągłości Działania Systemu i Plany Odtwarzania po katastrofie, spełniać muszą przynajmniej wymagania zawarte w normie BS 25999-1 i BS 25999-2.16) Mechanizmy i procedury zarządzania jakością usług muszą spełniać wymagania i zalecenia zawarte w normach PN-ISO/IEC 20000-1:2007 oraz PN-ISO/IEC 20000-2:2007.17) Analiza ryzyka zasobów informacyjnych musi być przeprowadzona zgodnie z wytycznymi zawartymi w normie PN-ISO/IEC 27005.18) Plany i procedury z zakresu prowadzenia audytów bezpieczeństwa muszą bazować na obowiązujących normach bezpieczeństwa oraz metodykach i zaleceniach z zakresu audytu bezpieczeństwa, w tym:a. PN-ISO/IEC 27001:2007,b. BS 25999-1,c. BS 25999-2,d. PN-ISO/IEC 20000-1:2007,e. PN-ISO/IEC 20000-2:2007.19) Dane muszą być przechowywane w systemach relacyjnych baz danych, do których zapewniony jest dostęp zgodny ze standardem SQL.20) Użyte systemy relacyjnych baz danych muszą zapewniać aplikacjom dostęp do danych za pośrednictwem interfejsu aplikacyjnego zgodnego ze standardem ODBC.21) Opracowany musi zostać standardowy model danych, elementów danych oraz metadanych definiujących środowisko współdzielenia danych wraz z odpowiednim repozytorium.22) Każdy element danych musi mieć właściciela odpowiedzialnego za nadzór merytoryczny nad danymi.23) W ramach systemu musi znajdować się mechanizm rejestrowania historii zdarzeń i komunikatów, umożliwiający zapamiętywanie wszystkich lub wybranych informacji audytowych. Mechanizm ten musi umożliwić monitorowanie i przegląd poszczególnych kroków w ramach określonych procesów wymiany informacji (procesów biznesowych).24) Dane muszą być zarządzane w sposób scentralizowany i współdzielone z punktu widzenia procesów biznesowych oraz lokalizacji poszczególnych komórek organizacji. Te same dane mogą być wprowadzane do systemu tylko raz.25) Dane muszą być zdefiniowane w spójny sposób, a ich definicje jednolite, zrozumiałe i dostępne wszystkim użytkownikom.26) Dane osobowe przechowywane i przetwarzane w Portalu muszą być zarządzane, przetwarzane składowane zgodnie z Ochroną danych osobowych.27) Rozwiązanie musi dostarczać mechanizmy kontroli dostępu administratorów umożliwiające dostęp do Systemu wyłącznie po jednoznacznym zidentyfikowaniu przeprowadzonym w ramach procesu uwierzytelnienia.28) Rozwiązanie musi zapewniać odpowiednie mechanizmy uwierzytelniania użytkowników nieanonimowych.29) Rozwiązanie musi zapewniać odpowiednie zabezpieczenia przed nieautoryzowanym dostępem na poziomie serwera usług.30) Rozwiązanie musi przechowywać i przesyłać hasła użytkowników wyłącznie w postaci zabezpieczonej.31) Rozwiązanie musi zapewniać mechanizmy kontroli uprawnień oparte na rolach, umożliwiające kontrolę poziomu dostępu każdego użytkownika zarówno w zakresie dostępu do danych przetwarzanych jak i korzystania z jego funkcjonalności. System uprawnień musi umożliwić ograniczenie dostępu wyłącznie do takich danych oraz takiego zakresu funkcji, jaki jest niezbędny użytkownikowi.32) Rozwiązanie musi posiadać mechanizmy umożliwiające rozliczalność działań użytkowników systemowych i nieanonimowych.33) Rozwiązanie musi posiadać mechanizmy umożliwiające rozliczalność działań administracyjnych związanych z nadawaniem i odbieraniem uprawnień.34) Rozwiązanie musi umożliwiać pełen audyt/rozliczalność operacji.35) Rozwiązanie musi umożliwiać podział użytkowników na grupy z możliwością przynależenia do kilku grup równocześnie.36) Rozwiązanie musi umożliwiać zarządzanie użytkownikami oraz grupami w zakresie ustalania uprawnień.37) Rozwiązanie musi umożliwiać blokowanie dostępu określonych grup użytkowników do zdefiniowanych zasobów Systemu.38) W przypadku szyfrowania, rozwiązanie musi implementować mechanizmy kryptograficzne. Moc wykorzystanych algorytmów kryptograficznych nie może być mniejsza od mocy zapewnianej przez takie algorytmy jak 3DES, AES-128, RSA-1024, SHA-1.39) Rozwiązanie musi zapewniać zabezpieczenie transmisji danych wrażliwych pomiędzy urządzeniem końcowym a serwerami aplikacyjnymi. Poziom zabezpieczenia transmisji nie może być mniejszy od poziomu zapewnianego przez protokoły SSLver. 3.0/TLSver. 1.1 z kluczem o długości 128 bitów.40) W przypadku szyfrowania rozwiązanie musi umożliwiać wykorzystanie usług kryptografii niesymetrycznej (PKI), w szczególności:a. oznaczania dokumentów wiarygodnym czasem przez zaufany urząd znakowania czasem będący na liście kwalifikowanych podmiotów świadczących usługi certyfikacyjne,b. elektronicznego podpisywania dokumentów za pomocą certyfikatów kwalifikowanych,c. weryfikacji podpisu elektronicznego.41) Rozwiązanie musi informować o dostępności usług.42) Rozwiązanie musi zapewniać mechanizmy logowania operacji: prób logowania i wylogowania użytkownika, modyfikacji danych, wykonanych akcji w Systemie wraz z rejestracją czasu operacji, identyfikatora użytkownika oraz wyniku operacji.43) Rozwiązanie musi zapewniać mechanizmy przechowywania logów systemowych w sposób chroniący je przed modyfikacją i nieuprawnionym usunięciem.44) Rozwiązanie musi zapewniać mechanizmy monitorowania podatności mających wpływ na bezpieczeństwo Systemu.45) Rozwiązanie musi zapewniać mechanizmy monitorowania integralności kluczowych elementów Systemu.46) Rozwiązanie musi zapewniać usługi synchronizacji czasu.47) Rozwiązanie musi zapewniać mechanizmy zarządzania konfiguracją.5. Skalowanie Serwisu OPIStworzone rozwiązanie powinno funkcjonować w następującej skali (wartości minimalne):1) Liczba Administratorów (po stronie Zamawiającego) – 5;2) Liczba Redaktorów i Moderatorów (po stronie Zamawiającego) – 30;3) Liczba użytkowników zewnętrznych, mających prawo do wprowadzania danych do systemu, poprzez system zapytań – 50 do 10000 (ostatnia liczba odpowiada liczbie na koniec wdrażania projektu);4) Wolumen danych w bazie relacyjnej hurtowni danych – 5 TB.6. Zarządzanie projektemDla potrzeb niniejszego zamówienia przez „projekt” rozumie się ogół zadań i czynności, jakie podejmuje Wykonawca i w jakie zaangażowany jest Zamawiający, w celu wykonania przedmiotu zamówienia. Wymagania co do zarządzania projektem są następujące:1) Projekt musi być realizowany zgodnie z metodyką, w której certyfikowany jest kierownik projektu lub równoważną.2) Musi zostać zdefiniowany zespół projektowy po stronie Zamawiającego oraz Wykonawcy wraz z określeniem ról i odpowiedzialności członków zespołu.3) Wykonawca przy współpracy z Zamawiającym musi opracować Plan Projektu zawierający co najmniej:a. Harmonogram realizacji projektu,b. Strukturę zespołu projektowego wraz z opisem ról i obowiązków,c. Strategię zarządzania jakością w projekcie,d. Strategię zarządzania ryzykiem w projekcie,e. Strategię zarządzania konfiguracją w projekcie.f. Strategię zarządzania komunikacją w projekcie.g. Mechanizmy sterowania, na które składają się co najmniej:— Raport okresowy,— Raport z punktów kontrolnych,— Raport o zagadnieniu,— Raport nadzwyczajny,— Grupa zadań,— Protokół przekazania.h. Jeżeli w przyjętej przez Wykonawcę metodyce nie występują wskazane powyżej mechanizmy sterowania, Wykonawca jest zobowiązany zapewnić równoważność informacyjną stosowanych dokumentów, rozumianą jako umieszczenie w stosowanych dokumentach tych samych informacji co w ww. mechanizmach sterowania.6.1. Wykonanie Analizy PrzedwdrożeniowejPodczas wykonania Analizy Przedwdrożeniowej należy uwzględnić poniższe wymagania:1) Zamawiający wymaga wykonania przez Wykonawcę realizującego zamówienie Analizy Przedwdrożeniowej obejmującej zadania dla wszystkich modułów/aplikacji we współpracy z pozostałymi podmiotami realizującymi Przedmiot Zamówienia w terminie 2 miesięcy od daty podpisania ostatniej umowy podpisywanej w ramach niniejszego postępowania o udzielenie zamówienia publicznego,2) Zamawiający wymaga wykonywania przez Wykonawcę realizującego zamówienie Analizy Przedwdrożeniowej funkcji koordynatora prac realizowanych przez wszystkie podmioty zaangażowane do wykonania Przedmiot Zamówienia,3) W ramach Analizy Przedwdrożeniowej Wykonawca zrealizuje co najmniej następujące prace:a. sporządzi wykaz prac oraz szczegółowy opis i harmonogram budowy projektu w tym:— szczegółowy opis instalacji i konfiguracji funkcjonalności opisanych w SIWZ,— wykaz oraz szczegółowy opis i harmonogram wykonania niezbędnych prac programistycznych związanych z dostosowaniem i modyfikacją rozwiązania oferowanego przez Wykonawcę.4) Przygotuje wykaz podstawowych funkcjonalności związanych z obsługą kluczowych procesów z opisem sposobu ich realizacji,5) Ustali ostateczną kolejność wdrożenia poszczególnych bloków wraz z ich modułami/aplikacjami,6) Przedstawi do akceptacji Zamawiającego organizację i metodykę zarządzania projektem,7) Ustali skład Zespołu Wdrożeniowego z podziałem na role i zadania poszczególnych członków zespołu,8) Przeprowadzi ze wszystkimi Wykonawca szczegółowe ustalenia dotyczące oznakowania produktów wytworzonych i dostarczonych przez Wykonawcę wskazujące, że Projekt jest współfinansowany ze środków Unijnych, poprzez dodanie logo, nazwy Projektu oraz źródła finansowania zgodnie z podanymi wcześniej zasadami.7. Dokumentacja realizacji przedmiotu zamówieniaWykonawca zobowiązany jest do przygotowania i przedstawienia Zamawiającemu do akceptacji następującej dokumentacji w związku z realizacją przedmiotu zamówienia.Dokumentacja powinna się składać z:1) Specyfikacji Funkcjonalnej opisującej sposób wdrożenia danych rozwiązań określonych przez Zamawiającego,2) Specyfikacji Technicznej składającej się z:a. szczegółowego opisu wymagań technicznych aplikacji zawierającej informacje o wszelkich, wymaganych przez aplikację usługach, programach i bibliotekach, wraz z ich wersjami (PHP 5.3, java, biblioteki do konwersji grafiki, biblioteki kryptograficzne, rozszerzenia PHP etc.),b. szczegółowej, wygenerowanej automatycznie z kodu źródłowego aplikacji, dokumentacji w postaci dokumentu elektronicznego.Wykonawca ma obowiązek aktualizować dokumentację podczas wprowadzania zmian, bądź poprawek w systemie, także po wykonaniu zlecenia, w okresie trwania gwarancji.Wykonawca powinien prowadzić dokumentację zmian w repozytorium wykorzystanym podczas tworzenia aplikacji. Zamawiający powinien mieć pełen dostęp co najmniej do gałęzi produkcyjnej aplikacji w repozytorium, z możliwością podejrzenia zmian oraz komentarzy dotyczących tych zmian.7.1. Szczegółowa analiza potrzeb informacyjnych ZamawiającegoAnaliza w terminie 1 miesiąca od daty podpisania umowy Wykonawca dokona szczegółowej analizy potrzeb informacyjnych Zamawiającego, czego wyniki przedstawi w postaci dokumentu podlegającego zatwierdzeniu Zamawiającego i będącego podstawą do realizacji prac nad zaprojektowaniem, wykonaniem i wdrożeniem Platformy IT.7.2. Analiza wymagań na podstawie specyfikacji dostarczonej przez Zamawiającego1) Analiza wymagań funkcjonalnych – w centrum uwagi których znajdują się proponowane rozwiązania modułu / komponentu / oprogramowania. Stanowią one uporządkowaną według istotności listę możliwości, jakie muszą posiadać ww. elementy, by spełnić biznesowe wymagania użytkownika.2) Analiza wymagań niefunkcjonalnych – odnoszących się do właściwości modułu / komponentu / oprogramowania, które muszą one posiadać, a które dotyczą takich aspektów jak interfejs użytkownika, zabezpieczenia dostępu, dostępność, solidność, awarie systemu, jego integrację, migrację, dokumentację itp.3) Zależności i ograniczenia – przedstawienie wszelkich zależności i ograniczeń.4) Rejestr Ryzyk – określenie ryzyk w odniesieniu do zakresu dokumentu.5) Lista artefaktów wraz z ich identyfikatorem, typem, nazwą, numerem wersji oraz listą wymagań, którą dany artefakt realizuje.6) Specyfikacja przypadków użycia, w tym:a. diagram przypadków użycia,b. funkcje użytkownika – opis realizowanych funkcji użytkownika ze wskazaniem zadań biznesowych, w szczególności np.: przebiegi, reguły, komunikaty błędów,c. funkcje systemowe - opis realizowanych funkcji systemowych ze wskazaniem zadań biznesowych, w szczególności np.: przebiegi, reguły, komunikaty błędów,d. tabele / drzewa decyzyjne.7) Założenia dotyczące architektury Serwisu.8) Specyfikacja modelu dziedziny (diagram stanów).7.3. Projekt Serwisu OPIProjekt Serwisu OPI musi zawierać:1) Założenia dotyczące bezpieczeństwa;2) Wymagania dla infrastruktury technicznej:a. wymagania wydajnościowe dla infrastruktury sieciowej,b. wymagania na środowisko sprzętowe,c. wymagania na oprogramowanie systemowe i bazodanowe,d. szacunkowy koszt infrastruktury wraz z założeniami szacowania.3) Opis architektury Serwisu.4) Stosowane standardy i rozwiązania.5) Detaliczny opis poszczególnych modułów/komponentów (przedstawionych w modelu logicznym) – określenie interfejsów wejściowych, wyjściowych oraz opis sposobu przetwarzania.6) Słowniki.Wraz z końcem realizacji zamówienia całą wynikającą dokumentację Wykonawca zaktualizuje do dokumentacji wykonawczej.7.4. Dokumentacja użytkownikaDokumentacja Użytkownika musi uwzględniać podręczniki dla każdej z opisanych ról tzn.:— Administratora— Redaktor— Moderator— Użytkownik zarejestrowany— Użytkownik niezarejestrowanyi zawierać dokładny opis realizowanej funkcjonalności.7.5. Plan testów funkcjonalnychDokument przedstawiający zakres oraz sposób przeprowadzenia testów funkcjonalnych Serwisu OPI musi zawierać:1) Sprzęt i oprogramowanie wymagane do przeprowadzenia testów,2) Opis planu testów akceptacyjnych,3) Opis scenariuszy testowych,4) Opis przypadków testowych.7.6. Plan testów niefunkcjonalnychDokument przedstawiający zakres oraz sposób przeprowadzenia testów niefunkcjonalnych Serwisu OPI musi zawierać:1) Opis technik wykorzystywanych w trakcie testów wydajnościowych;2) Sprzęt i oprogramowanie wymagane do przeprowadzenia testów;3) Opis obserwowanych parametrów pracy systemu;4) Opis przebiegu testów, w tym przypadki i scenariusze testów.7.7. Dokumentacja administratoraDokumentacja zawierająca opis procedur administracyjnych wraz z opisem (instrukcją) instalacji i konfiguracji sytemu. W ramach dokumentacji administratora muszą znaleźć się również zalecenia eksploatacyjne. Opisy zawarte w dokumentacji administratora skierowane będą do osób biegle posługujących się narzędziami informatycznymi, wykorzystywanymi na potrzeby rozwiązania oraz posiadających odpowiednie certyfikaty producentów tych narzędzi. Wymagany zakres dokumentu przedstawia się następująco:1) Instrukcja Instalacji i Konfiguracji (element dokumentacji administratora) zawiera procedury instalacji poszczególnych elementów składowych oprogramowania oraz ich konfiguracji:a. konfigurację systemu operacyjnego w zakresie wymaganym do instalacji Serwisu OPI,b. konfigurację baz danych,c. konfigurację serwera aplikacyjnego,d. konfigurację systemów dostępowych i autentykacyjnych w zakresie wymaganym do instalacji Serwisu OPI,e. instalację i konfigurację Serwisu OPI,f. dodatkowe wskazówki ułatwiające proces instalacji i konfiguracji,g. macierz ról i uprawnień.2) Zalecenia eksploatacyjne muszą zawierać:a. procedury uruchamiania i zatrzymywania wszystkich modułów/komponentów danego rozwiązania wraz z ich odpowiednią sekwencją,b. wskazanie sposobu uruchamiania procedur wykonywania kopii zapasowych,c. wskazanie sposobu uruchamiania procedur odtwarzania po awarii,d. procedury sprawdzania prawidłowego działania wszystkich komponentów,e. diagnostyka i procedury reakcji na nieprawidłowe działanie.8. Szkolenia użytkowników1) Szkolenia odbędą się w siedzibie Zamawiającego.2) Wykonawca przedstawi Zamawiającemu wstępny program szkolenia wraz z harmonogramem szkoleń, w terminie do 14 dni kalendarzowych od zawarcia umowy. Akceptacja i uzgodnienie pomiędzy Wykonawcą i Zamawiającym programu i harmonogramu przeprowadzenia szkoleń nastąpi w terminie do 21 dni kalendarzowych od zawarcia umowy. Zmiany w terminach realizacji szkoleń ujętych w szczegółowym harmonogramie powinny być uzgadniane przez Strony w formie pisemnej, najpóźniej na 7 dni przed zaplanowanym terminem rozpoczęcia szkoleń. Do uzgodnionego programu i harmonogramu szkoleń zostaną dołączone:a. nazwiska i dane kontaktowe koordynatorów szkoleń, wyznaczonych przez Zamawiającego i Wykonawcę, każdy ze swojej strony, osoby do współdziałania, odpowiedzialne za koordynowanie i obsługę wszelkich czynności dotyczących organizacji szkoleń. Zmiana osób wyznaczonych do współdziałania może nastąpić poprzez e-mailowe powiadomienie drugiej strony Umowy,b. lista osób wskazanych do realizacji Szkoleń ze strony Wykonawcy, posiadających co najmniej doświadczenie, wiedzę i kwalifikacje zawodowe wymagane w SIWZ w zakresie kwalifikacji i potencjału kadrowego Wykonawcy. Zmiana osób realizujących Szkolenia ze strony Wykonawcy wymaga formy e-mailowej i może być dokonana jedynie za uprzednią zgodą Zamawiającego. Zamawiający nie odmówi takiej zgody bez ważnych i uzasadnionych przyczyn.3) Skład poszczególnych grup szkoleniowych ustala Zamawiający. W celu umożliwienia realizacji zobowiązań Wykonawcy w zakresie przedmiotu szkolenia, Zamawiający zobowiązuje się do dostarczenia Wykonawcy niezbędnych informacji służących do sporządzenia niezbędnej dokumentacji ze wskazaniem instytucji, imienia i nazwiska, stanowiska służbowego oraz danych kontaktowych Uczestników szkolenia. W pojedynczej sesji szkoleniowej może uczestniczyć maksymalnie 5 osób szkolonych.4) Wykonawca wystawi certyfikat dla wszystkich uczestników szkolenia, ze wskazaniem zakresu merytorycznego szkoleń; wzór certyfikatu podlega zatwierdzeniu przez Zamawiającego.5) Wykonawca po przeprowadzeniu każdego szkolenia zobowiązany będzie do przygotowania i przekazania uczestnikom szkoleń ankiet ewaluacyjnych oceniających szkolenie. Ankieta oceniać będzie min. organizację szkolenia, treść wykładów (w tym: przygotowanie merytoryczne wykładowcy i stopień realizacji programu szkolenia) oraz wpływ szkolenia na wzrost wiedzy oraz umiejętności praktycznych uczestników. Wykonawca zobowiązany będzie do przedstawienia w terminie 14 dni kalendarzowych od daty przeprowadzenia ostatniego szkolenia ostatecznego raportu ewaluacyjnego, zawierającego pełną analizę ocen szkoleń przez uczestników.6) W przypadku gdy ponad 50% ankiet będzie zawierało negatywną ocenę szkolenia, Wykonawca będzie zobowiązany do jego powtórzenia w ustalonym z Zamawiającym terminie, pokrywając wszystkie koszty z tym związane, wraz z kosztami delegacji uczestników szkolenia. Negatywna ocena oznaczać będzie uzyskanie oceny „bardzo nisko”, „nisko” lub „nie”.7) Wykonawca opracuje materiały szkoleniowe i przekaże każdemu uczestnikowi w postaci prezentacji zawierającej slajdy ze szkolenia obejmujące każde z zagadnień wchodzących w zakres tematyki szkoleń. Prezentacja zawierająca slajdy ze szkolenia przygotowana w formie elektronicznej na płycie CD/DVD lub pamięci przenośnej USB powinna być dostarczona do Zamawiającego na 2 tygodnie przed rozpoczęciem szkoleń. Wykonawca ponosi wszelkie koszty związane z przygotowaniem, powieleniem oraz przekazaniem materiałów szkoleniowych uczestnikom (na płycie CD/DVD lub pamięci USB).8) W ramach wykonania przedmiotu szkolenia Wykonawca zobowiązany jest w szczególności do:a. przed rozpoczęciem szkolenia – skompletowania deklaracji uczestnictwa w projekcie oraz oświadczeń o wyrażeniu zgody na przetwarzanie danych osobowych, stanowiących warunek uczestnictwa w szkoleniu,b. przeprowadzenia szkoleń w języku polskim, zgodnie z zakresem przedmiotowym i w terminach określonych zgodnie z pkt 1,c. prowadzenia ewidencji osób przeszkolonych, w formie list obecności podpisywanych przez wszystkich Uczestników każdego dnia szkolenia ze wskazaniem instytucji, imienia i nazwiska oraz stanowiska służbowego,d. kompletowania list potwierdzających odbiór materiałów szkoleniowych oraz list potwierdzających odbiór zaświadczeń (certyfikatów) o ukończeniu szkolenia,e. przestrzegania przepisów o ochronie danych osobowych, w tym:— niewykorzystania danych osobowych w sposób inny niż służący wykonaniu umowy,— przetwarzania danych osobowych w miejscach, na urządzeniach, w sposób i przez osoby gwarantujące zabezpieczenie tych danych zgodnie z przepisami o ochronie danych osobowych,— umożliwienia Zamawiającemu przeprowadzenia kontroli sposobu wykorzystania danych osobowych,9) opracowania i przekazania Zamawiającemu do 5 dnia każdego miesiąca następującego po zakończeniu miesiąca kalendarzowego, w jakim realizowano szkolenie, stosownie do postanowień umowy o powierzeniu przetwarzania danych osobowych w zakresie realizowanego szkolenia:a. list obecności na poszczególnych szkolenia oraz zbiorczej listy osób objętych szkoleniem w danym miesiącu,b. deklaracji uczestnictwa w projekcie oraz oświadczeń o wyrażeniu zgody na przetwarzanie danych osobowych - dokumenty w wersji papierowej,c. kopii certyfikatów wydanych uczestnikom szkoleń,10) W programach szkoleń wymagane są ćwiczenia praktyczne na instancji testowej systemu.11) Wymagane jest, aby prowadzone szkolenia i materiały szkoleniowe były w języku polskim.12) Specyfikacja ilościowa wymaganych szkoleń znajduje się w poniższej tabeli:Zakres przedmiotowy Minimalna długość sesji Liczba osób do przeszkoleniaObsługa Serwisu OPI dla Administratorów Szkolenie 3-dniowe, każdego dnia przeprowadzonych zostanie 8 godzin szkoleniowych do 5Obsługa Serwisu OPI dla Redaktorów Szkolenie 2-dniowe, każdego dnia przeprowadzonych zostanie 8 godzin szkoleniowych do 5Obsługa Serwisu OPI dla Moderatorów Szkolenie 2-dniowe, każdego dnia przeprowadzonych zostanie 8 godzin szkoleniowych do 59. Obsługa developerska1) Zapewnienia obsługi deweloperskiej serwisu PWI polegającej na rozbudowywaniu i modernizowaniu PWI według potrzeb zgłaszanych przez użytkowników PWI (członków Klubu 150, partnerów OPI, pracowników OCRG i innych) w ilości do łącznie 800 roboczo- godzin w okresie od zakończenia szkoleń opisanych w punkcie 8 do 20 grudnia 2014 w siedzibie Zamawiającego lub zdalnie przez co najmniej dwóch informatyków mającego doświadczenie w zakresie realizacji analogicznej usługi. Ilość zrealizowanych roboczo-godzin będzie potwierdzana przez Zamawiającego na bieżąco za pośrednictwem prostego w obsłudze modułu w ramach serwisu PWI pozwalającego również na określenie ilości łącznie wykorzystanych roboczo-godzin.2) W ramach powyższego zapewnienia minimum comiesięcznych spotkań w siedzibie Zamawiającego polegających na:a. Szkoleniach pracowników OPI z wykorzystywania PWI w tym zwłaszcza nowych funkcjonalności powstałych w okresie obsługi deweloperskiej.b. Omówieniu przez obie strony dodatkowych potrzeb w zakresie rozwoju PWI deweloperskich w ramach obsługi deweloperskiej:i. zgłaszanych uwag i pomysłów użytkowników PWI dotyczących korzystania z serwisu,ii. dodatkowych potrzeb i usprawnień PWI,iii. realizacji zgłaszanych modyfikacji,iv. ustalanie dalszych harmonogramów prac.3) Ponadto Zamawiający przeprowadzi badania ankietowego aktywnych użytkowników serwisu PWI oraz członków Klubu 150, którzy jeszcze nie korzystali z serwisu w terminie 30 dni od zakończenia szkoleń opisanych w punkcie 8 Zamawiający powinien przeprowadzić minimum 100 ankiet w formie elektronicznej lub telefonicznej. Ankiety powinny zdiagnozować potrzeby użytkowników oraz potencjalnych użytkowników w zakresie wprowadzenia zmian i modyfikacji do serwisu. Ankieta powinna w szczególności określić zainteresowanie stworzeniem modułu Analityki Biznesowej (Business intelligence) oraz ewentualnego zakresu jego funkcjonalności (na podstawie załączonego SIWZ na BI – załącznik nr 1 ) oraz stopnia prawdopodobieństwa korzystania z niego.4) Wyniki ankiety powinny zostać przeanalizowane przez Wykonawcę i przedstawione Zamawiającemu w formie raportu z rekomendacjami dalszego rozwoju serwisu w szczególności z określeniem przydatności, ewentualnego zakresu oraz prawdopodobieństwa korzystania z modułu Analityki Biznesowej przez aktywnych oraz potencjalnych użytkowników serwisu PWI. Raport powinien zostać przedstawiony zamawiającemu do 40 dni kalendarzowych od zakończenia szkoleń opisanych w punkcie 8. Powyższy raport będzie podstawą do ewentualnej realizacji Etapu II Serwisu PWI. Po Przyjęciu powyższego raportu przez Zamawiającego, Wykonawca zmodyfikuje załączonego SIWZ na BI – załącznik nr 1 zgodnie z raportem i przekaże Zmawiającemu .10. Wymagania prawne dla dostarczanego rozwiązania10.1. Ogólne wymagania prawne dla dostarczanego rozwiązania1) Wykonawca zapewnia i zobowiązuje się, że korzystanie przez Zamawiającego z dostarczonych produktów nie będzie stanowić naruszenia praw osobistych, majątkowych praw autorskich i majątkowych osób trzecich.2) Oferowane oprogramowanie w dniu składania ofert nie może być przeznaczone przez producenta do wycofania z produkcji, do wycofania ze sprzedaży lub wsparcia technicznego.3) Zamawiający wymaga, by dostarczone oprogramowanie było oprogramowaniem w wersji aktualnej na dzień poprzedzający dzień składania ofert.4) Dla oprogramowania objętego niniejszym zamówieniem należy dostarczyć: licencje, nośniki instalacyjne oraz instrukcje.10.2. Licencje1) Udzielenie na czas nieoznaczony (tj. także w okresie wykraczającym poza okres obowiązywania umowy wdrożeniowej i gwarancyjnej) pisemnej, niewyłącznej, nieodwołalnej i nieograniczonej terytorialnie licencji na korzystanie z przedmiotu zamówienia oraz dostarczenie licencji na czas nieoznaczony, niewyłącznych, nieodwołalnych i nieograniczonych terytorialnie na jednoczesne korzystanie na dowolnej liczbie stanowisk z innych komercyjnych oprogramowań zewnętrznych (z wyłączeniem systemu bazy danych oraz systemu operacyjnego serwera), niezbędnych do funkcjonowania Systemu, na wszystkich znanych w dniu przeniesienia polach eksploatacji, w tym wymienionych w art.74 ust.4 ustawy z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych, jak również licencji na korzystanie z dokumentacji do tych oprogramowań na polach eksploatacji wymienionych w art. 50 ww. ustawy – wystawionych przez producentów tych oprogramowań (podmioty, którym przysługują autorskie prawa majątkowe do nich) na Zamawiającego jako licencjobiorcę.2) Licencje muszą pozwalać na dowolną liczbę instalacji dostarczonego systemu w zasobach Zamawiającego (w tym w jednostkach organizacyjnych podległych Zamawiającemu), nielimitowaną liczbę użytkowników, swobodne przenoszenie systemu pomiędzy serwerami Zamawiającego lub wynajętymi przez niego zasobami.3) Licencjonowanie musi uwzględniać prawo do bezpłatnego pozyskiwania i instalacji udostępnianych przez producenta uaktualnień (update i upgrade), poprawek krytycznych i opcjonalnych przez okres wdrożenia i w okresie 36 miesięcy od daty odebrania przez Zamawiającego przedmiotu zamówienia. W tym okresie Wykonawca nie może zaprzestać świadczenia usług wsparcia.10.3. Autorskie prawa majątkoweWykonawca przekaże Zamawiającemu wyłączne autorskie prawa majątkowe do koncepcji rozwoju i funkcjonowania systemu zarządzania treścią (CMS) – wyników Analizy Przedwdrożeniowej.Z dniem przyjęcia dzieła, Wykonawca przeniesie na Zamawiającego niewyłączne autorskie prawa majątkowe do systemu zarządzania treścią (CMS) na następujących polach eksploatacji: utrwalenie (sporządzenie egzemplarza, który mógłby służyć publikacji utworu), digitalizacja, wprowadzenie do pamięci komputera i sieci komputerowej Zamawiającego, sporządzenie wydruku komputerowego, zwielokrotnienie poprzez druk lub nagranie na nośniku magnetycznym w postaci elektronicznej, wprowadzenie do obrotu w przypadku rezygnacji Zamawiającego z eksploatacji utworu, nieodpłatne wypożyczenie lub udostępnienie zwielokrotnionych egzemplarzy, wprowadzanie w całości lub części do sieci komputerowej Internet w sposób umożliwiający transmisję odbiorczą przez zainteresowanego użytkownika łącznie z utrwalaniem w pamięci RAM w oryginalnej (polskiej) wersji językowej i w tłumaczeniu na języki obce wraz z prawem do dokonywania opracowań, przemontowań i zmian układu, na terytorium Polski oraz poza jej granicami a także zezwala Zamawiającemu na wykonywanie zależnego prawa autorskiego.11. Wymagania dla gwarancji i serwisu gwarancyjnego1) Całość rozwiązania musi zostać objęta 12 miesięczną gwarancją/wsparciem od dnia odbioru.2) System musi zapewniać dostępność na poziomie:a. SLA dla aktywności, które angażują wyłącznie użytkowników wewnętrznych (po stronie OCRG): wymagana dostępność – w godzinach pracy + dodatkowe 2 godziny (10 godzin na dobę);b. SLA dla aktywności, które angażują zarówno użytkowników wewnętrznych (po stronie Zamawiającego) jak i zewnętrznych – 22/7/365 (dopuszczalne 2 godziny przerwy technicznej).3) Wykonawca musi zapewnić aktualizacje oprogramowania przez okres 12 miesięcy od daty podpisania protokołu odbioru końcowego.4) Wykonawca musi zapewnić help desk dostępny dla użytkowników wewnętrznych (po stronie Zamawiającego) 24 godziny na dobę, 7 dni w tygodniu, 365 dni w roku.5) Obsługa serwisowa musi być realizowana w języku polskim.6) Zgłoszenie problemu będzie przyjmować jedną z trzech kategorii:a. błąd kategorii A (Krytyczny) - błąd blokujący możliwość użycia systemu lub uruchomienia podstawowej funkcjonalności systemu,b. błąd kategorii B (Wysoki) - błąd mający znaczny wpływ na realizację podstawowej funkcjonalności Systemu (przy czym istnieje możliwość realizacji podstawowych funkcji systemu),c. błąd kategorii C (Niski) - błąd sprawia, że stan systemu umożliwia realizację działań wynikających z określonych wymagań lub ma mały lub minimalny wpływ na działanie systemu.7) Czas reakcji na zgłoszenie jest rozumiany jako czas, który upłynął od momentu zgłoszenia (status Nowy) do momentu podjęcia zgłoszenia (status Przyjęty do realizacji). Czas reakcji zgłoszenia jest uzależniony od kategorii błędu i wymagany jest na następującym poziomie:a. błąd kategorii A (Krytyczny) - 2 godziny,b. błąd kategorii B (Wysoki) - 4 godziny,c. błąd kategorii C (Niski) - 1 dzień roboczy.1) Czas realizacji zgłoszenia jest rozumiany jako czas, który upłynął od momentu podjęcia zgłoszenia (status Przyjęty do realizacji) do momentu przekazania aktualizacji naprawczej (status Przekazano rozwiązanie).Czas realizacji zgłoszenia jest uzależniony od kategorii błędu i wymagany jest na następujących poziomie:a. błąd kategorii A (Krytyczny) – 8 godzin,b. błąd kategorii B (Wysoki) – 3 dni robocze,c. błąd kategorii C (Niski) – 7 dni roboczych.2) Powyższe parametry zostają wydłużone o czas dostarczenia aktualizacji od producenta OPROGRAMOWANIA STANDARDOWEGO, jeżeli naprawa błędu OPROGRAMOWANIA STANDARDOWEGO tego wymaga.12. WyłączeniaW zakres przedmiotu zamówienia NIE wchodzi:1) Dostawa sprzętu teleinformatycznego wraz z oprogramowaniem systemowym i bazodanowym.2) Zapewnienie łącz teleinformatycznych.3) Wdrożenie systemu do archiwizacji.13. Punkty styku z innymi systemami1) ActiveDirectory w zakresie uprawnień.2) Serwisy społecznościowe: Twitter, Facebook, Pinterest.3) Mechanizm Google Analytics.14. Warunki odbioru przedmiotu zamówienia14.1. DefinicjeEtap Techniczny Projektu – większy fragment projektu; zbiór obejmujący, co najmniej jedną część projektu. Części te (Grupy Zadań), poza przynależnością do jednego etapu, charakteryzują się względem siebie luźną relacją czasową, to jest mogą występować równocześnie, lub w innej kolejności niż w opisie etapu.Etap Zarządczy Projektu – fragment projektu obejmujący wszystkie części projektu występujące w określonym czasie, tzn. grupujące części różnych etapów technicznych.Grupa Zadań – fragment etapu technicznego, zawierający zestaw prac związanych z jego realizacją. Grupy zadań dla każdego etapu technicznego są definiowane w Planie Projektu.Odbiór – zatwierdzenie przez Zamawiającego wykonania części projektu, etapu projektu, lub projektu jako całości. Od odbioru nie ma odwołania, natomiast może towarzyszyć mu protokół rozbieżności.Procedura odbioru – sposób postępowania stron w trakcie odbioru.Jednostka – podmiot, którego dotyczy Grupa Zadań.Zamawiający – OCRG.Kierownik Projektu po stronie Zamawiającego – Osoba, której Zamawiający powierzył kierowanie projektem.14.2. Etapy projektuProjekt jest realizowany w oparciu o 2 rodzaje etapów: etapy techniczne i etapy zarządcze.Etapy techniczne określają ramy w których dostarczane są konkretne produkty projektu. W projekcie zdefiniowano następujące etapy techniczne:Etap Produkty dostarczane w ramach etapu01 Plan Projektu02 Opracowanie koncepcji Serwisu PWILicencje na oprogramowanieZainstalowany i skonfigurowany Serwisu PWI03 SzkoleniaDokumentacja04 Obsługa deweloperskaEtap techniczny 01 jest traktowany jako etap inicjowania i jego zakończenie warunkuje rozpoczęcie realizacji kolejnych etapów.Etapy techniczne 02 i 03 mogą przebiegać równolegle oraz rozpoczęcie Etapu 03 nie jest uwarunkowane zakończeniem Etapu 02.W ramach etapów technicznych określone są Grupy Zadań, które definiują pakiety prac do wykonania. Prawidłowe zrealizowanie wszystkich grup zadań w ramach etapu technicznego jest równoznaczne ze zrealizowaniem zakresu etapu technicznego.Etapy zarządcze są niezależne od etapów technicznych. Każdy etap zarządczy trwa 3 miesiące kalendarzowe. Etapy zarządcze nie mogą przebiegać równolegle oraz rozpoczęcie kolejnego etapu zarządczego może nastąpić dopiero po zakończeniu poprzedniego.14.3. Rodzaje odbiorówOdbiory z punktu widzenia zarządczego dzielimy na:Odbiór Grupy Zadań,Odbiór Etapu Technicznego,Odbiór Końcowy Projektu.Odbiory z punktu widzenia technicznego dzielimy na:Odbiór ilościowy – polega na sprawdzeniu czy liczba dostarczonych produktów odpowiada liczbie zamówionych produktów,Odbiór jakościowy – polega na sprawdzeniu czy dostarczone produkty spełniają założone normy jakości.14.4. Odbiór Grupy Zadań(a) Dane wejściowe do procedury1) Dokument Grupa Zadań (GrZad) zawiera:a. Listę produktów wytwarzanych w ramach Grupy Zadań,b. Daty:— Planowanego rozpoczęcia realizacji Grupy Zadań,— Planowanego przekazania Grupy Zadań,— Planowanego rozpoczęcia odbioru Grupy Zadań,— Planowanego zakończenia realizacji Grupy Zadań,2) Dokument Protokół Przekazania Grupy Zadań (ProtPrz) zawiera:a. Listę produktów wytwarzanych w ramach Grupy Zadań (tą samą, która jest zawarta w GrZad),b. Datę przekazania Grupy Zadań.Jeżeli w trakcie realizacji Grupy Zadań wystąpiła konieczność zmiany jakichkolwiek terminów, to zmiana taka musiała być realizowana w trybie zgłoszenia zagadnienia (Raport o Zagadnieniu). Oznacza to, że w momencie składania Protokołu Przekazania Grupy Zadań daty rozpoczęcia i zakończenia odbioru określone w dokumencie Grupa Zadań są aktualne.(b) Procedura odbioru Grupy Zadań1) Wykonawca w ciągu 1 dnia po zakończeniu prac realizowanych w ramach danej Grupy Zadań przedkłada Kierownikowi Projektu po stronie Zamawiającego Protokół Przekazania Grupy Zadań.2) Kierownik Projektu po stronie Zamawiającego bezzwłocznie potwierdza fakt otrzymania Protokołu Przekazania Grupy Zadań.3) Kierownik Projektu po stronie Zamawiającego najpóźniej następnego dnia powiadamia uczestników odbioru (tzn. Zamawiającego, Jednostkę i Wykonawcę) o terminie (data jest określona w dokumencie Grupa Zadań) i miejscu odbioru (miejsce lokalizacji produktu jest określone w Rejestrze Konfiguracji).4) We wskazanym miejscu i terminie Wykonawca przeprowadza procedurę odbioru zgodnie ze scenariuszem odbioru adekwatnym do odbieranego typu produktu. Odbiór jest przeprowadzany przy udziale Jednostki, opcjonalnym udziale Zamawiającego oraz formalnym i merytorycznym nadzorze Kierownika Projektu po stronie Zamawiającego.5) Dalsze działania są zależne od wyniku realizacji scenariusza odbioru:a. Jeżeli wszystkie produkty z odbieranej Grupy Zadań spełniają założone kryteria jakościowe wówczas uczestnicy odbioru podpisują Protokół Odbioru Grupy Zadań. Jest to równoznaczne z zakończeniem Grupy Zadań.b. W przeciwnym wypadku Kierownik Projektu po stronie Zamawiającego analizuje wpływ nieodebrania Grupy Zadań na harmonogram Etapu Technicznego.— Jeżeli zdaniem Kierownika Projektu po stronie Zamawiającego nieodebranie Grupy Zadań nie będzie miało wpływu na termin zakończenia Etapu Technicznego wówczas Kierownik Projektu po stronie Zamawiającego przedkłada Zamawiającemu raport o zagadnieniu w terminie 3 dni od daty podjęcia decyzji o nieodebraniu Grupy Zadań.— W przeciwnym wypadku Kierownik Projektu po stronie Zamawiającego przedkłada Raport Nadzwyczajny, w którym informuje Zamawiającego o niedotrzymaniu terminu zakończenia etapu technicznego.6) Procedura odbioru Grupy Zadań zostaje zakończona.14.5. Odbiór Etapu Technicznego(a) Dane wejściowe do proceduryOdbiór Etapu Technicznego następuje w oparciu o wcześniej dokonane odbiory Grup Zadań.Raporty Odbioru Grup Zadań zawierają informacje o Grupach Zadań, które zostały odebrane w ramach Etapu Technicznego.Plan Etapu Technicznego zawiera informacje o wszystkich Grupach Zadań, jakie muszą zostać zrealizowane w ramach Etapu Technicznego.(b) Procedura odbioru Etapu Technicznego1) Wykonawca po odebraniu wszystkich Grup Zadań w ramach Etapu Technicznego przedkłada Kierownikowi Projektu po stronie Zamawiającego projekt Raportu Końcowego Etapu Technicznego.2) Kierownik Projektu po stronie Zamawiającego (w uzgodnieniu z Zamawiającym i Wykonawcą) w ciągu 3 dni wyznacza termin przeglądu dokumentacji.3) Kierownik Projektu po stronie Zamawiającego w obecności Zamawiającego i Wykonawcy weryfikuje dokumentację projektową potwierdzając, sprawdzając czy wszystkie Grupy Zadań w ramach Etapu Technicznego zostały odebrane.4) Dalsze działania są zależne od wyniku realizacji scenariusza odbioru:a. Jeżeli wszystkie Grupy Zadań zostały odebrane, Kierownik Projektu po stronie Zamawiającego w ciągu 3 dni przygotowuje Raport Końcowy Etapu Technicznego, a Zamawiający go zatwierdza na najbliższym posiedzeniu Zamawiającego.b. W przeciwnym wypadku Kierownik Projektu po stronie Zamawiającego analizuje wpływ nieodebrania Etapu Technicznego datę odbioru końcowego Projektu.— Jeżeli zdaniem Kierownika Projektu po stronie Zamawiającego nieodebranie Etapu Technicznego nie będzie miało wpływu na termin zakończenia Projektu wówczas Kierownik Projektu po stronie Zamawiającego przedkłada Zamawiającemu Raport o Zagadnieniu w terminie 3 dni od daty podjęcia decyzji o nieodebraniu Etapu Technicznego.— W przeciwnym wypadku Kierownik Projektu po stronie Zamawiającego przedkłada Raport Nadzwyczajny, w którym informuje Zamawiającego o niedotrzymaniu terminu zakończenia projektu.5) Po pozytywnym przejściu określonych powyżej kroków procedura odbioru Etapu Technicznego zostaje zakończona.14.6. Odbiór końcowy projektu(a) Dane wejściowe do proceduryOdbiór końcowy projektu następuje w oparciu o wcześniej dokonane odbiory Etapów Technicznych.Plan Projektu zawiera informacje o wszystkich Etapach Technicznych, jakie muszą zostać zrealizowane w ramach Projektu.(b) Procedura odbioru końcowego projektu1) Wykonawca po odebraniu wszystkich Etapów Technicznych w ramach Projektu przedkłada Kierownikowi Projektu po stronie Zamawiającego projekt Raportu Końcowego Projektu2) Kierownik Projektu po stronie Zamawiającego (w uzgodnieniu z Zamawiającym i Wykonawcą) w ciągu 3 dni wyznacza termin przeglądu dokumentacji.3) Kierownik Projektu po stronie Zamawiającego w obecności Zamawiającego i Wykonawcy weryfikuje dokumentację projektową, sprawdzając czy wszystkie Etapy Techniczne w ramach Projektu zostały odebrane.4) Dalsze działania są zależne od wyniku realizacji scenariusza odbioru:a. Jeżeli wszystkie Etapy Techniczne zostały odebrane Kierownik Projektu po stronie Zamawiającego w ciągu 3 dni przygotowuje Raport Końcowy Projektu, który Zamawiający zatwierdza. Po zatwierdzeniu Raportu Końcowego Projektu, strony podpisują Protokół Odbioru Końcowego.b. W przeciwnym wypadku Kierownik Projektu po stronie Zamawiającego analizuje czy istnieje jeszcze bufor czasowy pozwalający na zakończenie projektu w terminie.— Jeżeli zdaniem Kierownika Projektu po stronie Zamawiającego istnieje bufor czasowy pozwalający na zakończenie projektu w terminie wówczas Kierownik Projektu po stronie Zamawiającego przedkłada Zamawiającemu Raport o zagadnieniu w terminie 3 dni od daty podjęcia decyzji o nieodebraniu Projektu.— W przeciwnym wypadku Kierownik Projektu po stronie Zamawiającego przedkłada Raport Nadzwyczajny, w którym informuje Zamawiającego o niedotrzymaniu terminu zakończenia projektu.5) Procedura odbioru końcowego Projektu zostaje zakończona.14.7. Kryteria jakościowe i ilościoweKryteria jakościowe i ilościowe odnoszą się do odbioru gotowego produktu. Są to listy kontrolne do procedury odbioru ze wskazanym źródłem danych do weryfikacji.(a) OprogramowanieKryterium Norma Metoda kontroliKryteria jakościoweFunkcjonalność oprogramowania Spełnienie w 100 % wymagań funkcjonalnych określonych w OPZ i Ofercie Wykonawcy oraz brak incydentów na ścieżce negatywnej Scenariusz testowy pokrywający 100 % funkcjonalności oraz scenariusze własne ZamawiającegolubScenariusz testowy potwierdzający wersję oprogramowania oraz porównanie dokumentacji producenta oprogramowania z wymaganiami zawartymi w OPZ (dotyczy wyłącznie oprogramowania licencjonowanego)Instalacja oprogramowania Dostarczone oprogramowanie jest zainstalowane na sprzęcie na którym będzie docelowo używane PrzeglądKonfiguracja oprogramowania Dostarczone oprogramowanie jest skonfigurowane w sposób umożliwiający jego użycie bez wprowadzania dodatkowych ustawień Jednorazowe uruchomienieLicencjonowanie Dostarczone dokumenty potwierdzające prawa do licencji są zgodne z umową licencyjną Porównanie przedłożonych dokumentów z licencją udzielaną przez producenta oprogramowania (dotyczy oprogramowania licencjonowanego)Nośniki Dostarczono komplet nośników z oprogramowaniem oraz oprogramowanie dostarczone na nośnikach umożliwia zainstalowanie Serwisu OPI Przegląd oraz jednorazowa instalacjaKryteria ilościoweLiczba licencji Liczba dostarczonych licencji odpowiada liczbie wynikającej z OPZ Przegląd dokumentu licencyjnegoLiczba instalacji Liczba instalacji odpowiada liczbie wynikającej z oferty Wykonawcy Przegląd raportów z instalacji(b) DokumentacjaKryterium Norma Metoda kontroliKryteria jakościoweStruktura dokumentu Dokument jest podzielony na rozdziały, podrozdziały i sekcje PrzeglądKompletność dokumentu Dokument zawiera wszystkie elementy opisane w OPZ Porównanie dokumentu z wymaganiami zawartymi w OPZKompletność dokumentacji Każdy produkt podlegający odbiorowi (poza dokumentacją i promocją) posiada dokumentację Porównanie listy dokumentacji listą produktów podlegających odbiorowiSpójność dokumentu Występuje wzajemna zgodność pomiędzy wszystkimi rodzajami informacji umieszczonymi w dokumencie, jak i brak logicznych sprzeczności pomiędzy informacjami zawartymi we wszystkich przekazanych dokumentach oraz we fragmentach tego samego dokumentu. PrzeglądFormat dokumentu elektronicznego Wersja elektroniczna dokumentu jest przekazana w formatach Word i PDF Otwarcie dokumentu za pomocą (odpowiednio) MS Word 2010 lub Adobe ReaderNośnik dokumentu Wersja elektroniczna dokumentu jest przekazana na płycie CD lub DVDWersja papierowa dokumentu jest przekazana w formie drukowanej i trwale oprawionej Otworzenie dokumentu bezpośrednio z płyty umieszczonej w czytniku CD lub DVDPrzeglądJęzyk dokumentacji Dokumentacja jest dostarczona w całości w języku polskim PrzeglądKryteria ilościoweWersja elektroniczna Zostanie dostarczona 1 płyta CD lub DVD zawierająca całość dokumentacji podlegającej odbiorowi Przegląd plików na płycie i porównanie ich z listą dokumentacjiWersja papierowa Zostaną dostarczone 3 egzemplarze dokumentacji podlegającej odbiorowi Sprawdzenie kompletności poprzez porównanie z listą dokumentacji.Sprawdzenie listy egzemplarzy dla każdego rodzaju dokumentacji(c) SzkoleniaKryterium Norma Metoda kontroliKryteria jakościoweSpełnienie wymagań ogólnych Spełnienie wszystkich wymagań ogólnych Lista kontrolnaJęzyk szkolenia Szkolenia muszą być przeprowadzone w języku polskim Przegląd oświadczeń wykonawcyZakres szkolenia Zakres szkolenia jest zgodny z wymaganiami na szkolenia Przegląd materiałów szkoleniowychMateriały szkolenia Każdy uczestnik otrzymuje wydrukowany komplet materiałów szkoleniowych w języku polskim Przegląd materiałówLiczebność grup Pojedyncza sesja szkoleniowa jest przeprowadzana dla maksymalnie 5 osób Przegląd listy obecnościCertyfikat Każdy uczestnik otrzymuje certyfikat ukończenia szkolenia Przegląd kopii certyfikatówKryteria ilościoweLiczba uczestników szkoleń do 30 Przegląd list obecnościLiczba dni szkoleniowych 9 Przegląd harmonogramu szkoleń153 746,67

Informacje dodatkowe

§ 8

1. Zmiany postanowień niniejszej umowy wymagają formy pisemnej, pod rygorem nieważności.

2. Zamawiający dopuszcza następujące zmiany postanowień zawartej umowy, gdy:

1) wystąpią okoliczności, które nie mogły być przewidziane przed podpisaniem umowy

(np. przyczyny techniczne leżące po stronie Zamawiającego), nie wynikające z zaniedbań którejś ze stron, a czas wydłużenia jest niezbędny do realizacji przedmiotu umowy, możliwe jest wydłużenie czasu realizacji umowy,

2) zmian dotyczących wydłużenia terminów nanoszenia poprawek i opiniowania w sytuacji gdy osoba odpowiedzialna za realizację umowy po stronie Zamawiającego zgodnie z § 2 ust 4 będzie przebywać na zwolnieniu chorobowym, delegacji bądź na urlopie,

3) nastąpi zmiana w zakresie przepisów prawnych mających bezpośredni wpływ na realizację przedmiotu umowy.

(numeracja zgodna z wzorem umowy)