Umowy szczegółowego,

Transkrypt

1 Załącznik nr 1 do SIWZ OPIS PRZEDMIOTU ZAMÓWIENIA Przedmiotem zamówienia jest usługa wykonania i wdrożenia Modułu Wizytówki Multimedialne portalu internetowego Interizon Pomorskiego Klastra ICT (zawiązanegoo na mocy umowy partnerstwa z dnia 29 października 2009r.) ), zwanego dalej modułem, realizowanego w ramach projektu ICT INNOVA Wzrostt konkurencyjności i innowacyjności Pomorza poprzez rozwój klastra kluczowego branży ICT, finansowanego i realizowanego w ramach Regionalnego Programu Operacyjnego dla Województwa Pomorskiego na lata , Działanie D Wizytówka multimedialna jest zbiorem elementów tekstowych oraz graficznych w postaci pliku pdf., tworzonym przez użytkownika modułu. Plik ten generowany będzie za pomocą modułu, przy wykorzystaniu bazy danych całego portalu. Wizytówka multimedialna spełniać będzie funkcje informacyjne oraz promocyjne na rzecz Interizon Pomorskiego Klastra ICT oraz jego Uczestników. Ma również stanowić źródło informacji o Klastrze i jego działaniach dla d użytkowników nie należących do Klastra, ale nim zainteresowanych. A. Opis czynności w ramach realizacji przedmiotu zamówienia Na przedmiot zamówienia w szczególności składać się będą następujące czynności: 1) Opracowanie modułu portalu, opisanego w niniejszym dokumencie, oraz zgodnie z uwarunkowaniami dla całego portalu wskazanymi w Opisie portalu, jak również dostarczenie kompletnego oprogramowania modułu portalu wraz ze wszystkimi składnikami niezbędnymi do jegoo prawidłowego działaniaa (wykorzystane aplikacje, system CMS, niezbędne licencje itp.) i przeniesieniee na Zamawiającego wszelkich majątkowych praw autorskich do modułu portalu i jego składników orazz dokumentacji. 2) Wdrożenie (zainstalowanie i skonfigurowanie) modułu portalu p na platformie sprzętowej udostępnionej przez Zamawiające ego, gwarantując jego pełną funkcjonalność. 3) Przygotowanie dokumentacji dla modułu portalu (w postaci elektronicznej) obejmującej: a) Dokumentację techniczną, t obejmującą instrukcję instalacji i konfiguracji oprogramowania oraz instrukcję obsługi dla użytkownika włącznie; ; b) Dokumentację kodu źródłowego. 4) Zapewnienie 24 miesięcznej gwarancji na moduł portalu w tym okresie, według zasad opisanych w punkcie 10 niniejszego dokumentu. Wykonawca zobowiązany jest do przedstawienia na 2 dni przed podpisaniem Umowy szczegółowego, uzgodnionego z Zamawiającym, harmonogramuu prac związanych z wykonaniem zamówienia. Realizując przedmiot umowy Wykonawca zobowiązuje się s do pełnej dyspozycyjności przedstawiciela Wykonawcy, jakiej wymaga należyte i terminowe realizowanie prac wskazanych w niniejszej umowie, w tym osobistej obecności u Zamawiające ego, w sytuacjach uzasadnionych koniecznością współpracy z Zamawiającym w ramach realizacji zamówienia. z Projekt finansowany w ramach Regionalnego Programuu Operacyjnego dla Województwa Pomorskiego na lata

2 Na każdym etapie opracowania modułu Wizytówki Multimedialne, na którym pojawi się możliwość kilku opcji spełnienia założeń i wymagań Zamawiającego, Wykonawca zobowiązany jest skonsultować wybrany wariant rozwiązania z Zamawiającym i uzyskać jego pisemną zgodę na wybrane rozwiązanie. B. Opis Modułu Wizytówki Multimedialne (założenia i wymagania dla modułu) 1. Opis modułu Moduł powinien zostać zbudowany w oparciu o technologię XHTML/1.0 oraz być zgodny z funkcjonującym systemem zarządzania treścią CMS portalu Interizon Pomorskiego Klastra ICT. Powinien być kompatybilny z opisem portalu, stanowiącym załącznik. Moduł powinien poprawnie funkcjonować we wszystkich popularnych przeglądarkach internetowych, a w szczególności: W systemach Windows XP, Vista, 7: Internet Explorer 8.0 i 9.0, Firefox 3.x i nowszy, Opera 9.5 i nowsza, Safari 3.x i nowszy, Chrome 2.0 i nowszy; W systemach Macintosh OS X 10.4 lub 10.5: Firefox 3.x i nowszy, Opera 9.5 i nowsza, Safari 3.x. i nowszy, Chrome 2.0 i nowszy; W systemach Linux: Firefox 3.x i nowszy, SeaMonkey 1.11 i nowszy. Moduł portalu powinien zostać przystosowany do obsługi przez przeglądarki internetowe dostępne na urządzeniach mobilnych. Moduł powinien być dostosowany do rozdzielczości ekranu 1280x1024 pikseli lub większej. Wykonawca wykona moduł portalu w sposób, oraz w oparciu o technologie, umożliwiające późniejsze wprowadzanie zmian i modyfikacji, przez Zamawiającego. Moduł powinien posiadać interfejs w co najmniej 2 wersjach językowych polskiej i angielskiej. Językiem domyślnym modułu portalu powinien być język polski. Użytkownik powinien mieć możliwość wyboru wersji językowej samodzielnie. Moduł powinien umożliwiać łatwe dodawanie kolejnych wersji językowych. Moduł powinien umożliwiać generowanie Wizytówek Multimedialnych w postaci dokumentu elektronicznego w formacie pdf wzbogaconego o elementy graficzne (np. w formatach jpeg, png itp.), na podstawie wybranego szablonu, opisanego w pkt 2 niniejszego dokumentu. Moduł będzie umożliwiał tworzenie trzech (3) typów Wizytówek Multimedialnych, tj. dla: 1) pojedynczego podmiotu Klastra (UK), 2) grupy podmiotów Klastra (UK), 3) Klastra. 2. Szablony Wizytówek Multimedialnych Szablon Wizytówki Multimedialnej to określenie układu treści (sposób rozmieszczenia), która ma się na niej znaleźć. Treść, którą zostanie wypełniony szablon, będzie pobierana z bazy danych portalu Klastra, według wyboru użytkownika modułu. Szablon definiuje, oprócz rozmieszczenia konkretnych treści, także formatowanie elementów graficznych (wymiary, rozdzielczość itp.) oraz elementów tekstu (liczba znaków, krój czcionki, wielkość czcionki itp.). 2

3 Wykonawca, w ramach realizacji zamówienia powinien opracować trzy (3) rodzaje szablonów, według następujących kategorii : Szablon dla pojedynczego podmiotu Klastra (Uczestnik Klastra), Szablon dla grupy podmiotów Klastra, Klaster jako całość. W przypadku każdej z wymienionych powyżej grup, powinna istnieć możliwość tworzenia wizytówki multimedialnej, wg co najmniej pięciu różnych (5) szablonów. Każdy szablon (zarówno dla danej kategorii jak i wewnątrz danej kategorii) powinien umożliwiać generowanie wizytówki w odmiennych wersjach językowych. Domyślną wersją językową Wizytówki Multimedialnej jest wersja polska. Użytkownik modułu powinien mieć również możliwość samodzielnego wyboru wersji językowej, w której tworzona będzie wizytówka multimedialna. 2.1 Szablon Wizytówki Multimedialnej dla pojedynczego podmiotu oraz dla grupy podmiotów Klastra Przygotowany przez Wykonawcę szablon powinien zawierać pola, w których umieszczone zostaną przedstawione poniżej dane: nazwa Uczestnika Klastra, logo Uczestnika Klastra, hasło przewodnie Uczestnika Klastra, krótka prezentacja zakresu działalności firmy (branża/systemy/tworzone rozwiązania), schemat organizacyjny podmiotu, klienci, innowacyjne projekty (zrealizowane, w trakcie realizacji, złożone), certyfikaty / nagrody i wyróżnienia, partnerzy, kontakt, oraz dodatkowo, w zależności od ich wypełnienia, pola które mogą być generowane za pomocą formularza o którym mowa w punkcie 4 ppkt 1). 2.2 Szablon wizytówki Klastra Przygotowany przez Wykonawcę szablon powinien zawierać pola, w których umieszczone zostaną następujące dane: nazwa Klastra, logo Klastra hasło przewodnie Klastra, krótka prezentacja misji, wizji, celów, historia, struktura organizacyjna, Uczestnicy Klastra/ członkowie (zestawienie: mikro, małe, średnie, duże, instytucje otoczenia biznesu oraz inne), zatrudnienie / branże, innowacyjne projekty, nagrody i wyróżnienia, 3

4 kontakt, oraz dodatkowo, w zależności od ich wypełnienia, pola które mogą być generowane za pomocą formularza o którym mowa w punkcie 4 ppkt 1). 3. Kategorie użytkowników modułu Przygotowany przez Wykonawcę moduł powinien przewidywać zastosowanie dla poniższych kategorii użytkowników: 3.1 Administrator Osoba administrująca systemem (portalem klastra), która ma możliwość jego konfiguracji. Posiada pełne uprawnienia względem modułu, opisane w punkcie 4 poniżej. 3.2 Użytkownik Biuro Klastra Użytkownik Biura Klastra zalogowany do modułu z pełnymi uprawnieniami, określonymi w punkcie 4 poniżej 3.3 Użytkownik zalogowany Użytkownik zewnętrzny zalogowany do modułu, powinien posiadać uprawnienia określone w ppkt. 4), 5), 6) punktu 4 poniżej. 3.4 Użytkownik niezalogowany Użytkownik zewnętrzny niezalogowany, gość odwiedzający portal Klastra. Powinien posiadać uprawnienia określone w ppkt. 6) punktu 4 poniżej. 4. Wymagania funkcjonalne modułu 1) Dodawanie, modyfikowanie, usuwanie danych, które będą zawarte w Wizytówce Multimedialnej. Wprowadzanie danych powinien umożliwiać formularz elektroniczny. Formularz powinien zawierać pola, w których automatycznie umieszone zostaną informacje dostępne w bazie danych portalu Klastra (wskazane przez Zamawiającego) oraz dodatkowo niżej przedstawione pola: Oczekiwania podmiotu wobec partnerów, Produkty i/lub usługi: format: nazwa produktu, link do strony zawierającej więcej informacji na temat produktu lub usługi, Użytkownik Biuro Klastra powinien mieć dodatkowo możliwość edycji formularza zawierającego następujące pola: Misja, wizja, Cele, Historia, Logo (element graficzny), Zdjęcia (elementy graficzny, max. 10), Wykresy (elementy graficzne, max. 5), Dane teleadresowe, 4

5 Sukcesy, Korzyści, Produkty i/lub usługi, Technologie, Projekty. Pola te nie powinny być widoczne dla innych typów użytkowników, poza administratorem systemu. 2) Dodawanie, usuwanie wersji językowej Wizytówki Multimedialnej. 3) Dodawanie, modyfikowanie, usuwanie szablonów. 4) Generowanie Wizytówki Multimedialnej dla określonego przez użytkownika sytemu, Uczestnika Klastra w formacie pdf za pomocą wybranego szablonu, z listy dostępnych szablonów, oraz dla wybranego języka. 5) Generowanie Wizytówki Multimedialnej dla Klastra w formacie pdf za pomocą wybranego, szablonu, z listy dostępnych szablonów, oraz dla wybranego języka. 6) Generowanie Wizytówki Multimedialnej dla określonej, przez użytkownika systemu, grupy Uczestników Klastra według różnych kryteriów np. branży, technologii, wielkości podmiotu (mikro, małe, średnie, duże), typu podmiotu (instytucja otoczenia biznesu, instytucja nauki i edukacji, i in.), obszar działalności (województwo), itp. w formacie pdf oraz dla wybranego szablonu Wizytówki Multimedialne Grupy Podmiotów Klastra z listy dostępnych szablonów oraz dla wybranego języka. 7) Generowane pliki powinny być zapisywane na dysku lokalnym Użytkownika modułu. 5. Wymagania niefunkcjonalne 1) Zgodność modułu z systemem CMS na którym działa portal Klastra (bezproblemowe współdziałanie modułu z systemem CMS portalu), zgodnie opisem zawartym z załącznikiem nr 2 do SIWZ, 2) Moduł powinien korzystać z danych gromadzonych w istniejącej bazie danych portalu Klastra, 6. Wymagania w zakresie jakości dostarczonego kodu Kod oprogramowania dostarczonego przez Wykonawcę powinien opierać się na wytycznych architektury MVC dla aplikacji internetowych. W szczególności oznacza to, że: kod podzielony zostanie zgodnie z założeniami architektury MVC, wszystkie zapytania do bazy danych odbywać się będą wyłącznie przez funkcje w warstwie "modelu", wszystkie funkcje generujące kod HTML zawarte będą w warstwie "widoku" (pomocnicze funkcje służące do opisu instancji obiektu klasy modelu mogą być zawarte w kodzie modelu), każda funkcja kontrolera obsługiwać będzie pojedyncze zapytanie HTTP (request response). Ponadto, interfejsy graficzne użytkownika obsługiwane muszą być przez przeglądarki obsługujące język JavaScript. Funkcje obsługujące warstwę kodu JavaScript: 5

6 zawarte będą w statycznych plikach kodu JavaScript, nie będą generowane dynamicznie przez kod innego języka skryptowego, pliki kodu JavaScript ładowane będą asynchronicznie przy użyciu funkcji podobnej do jquery.getscript() [ lub połączone w jeden zminifikowany plik kodu [ Wykonawca dostarczy kod w formie źródłowej pozwalającej na dalszy jego rozwój. Kod każdej funkcji będzie udokumentowany w sposób pozwalający na wygenerowanie automatycznej dokumentacji (API) każdej klasy. Dokumentacja komentarzowa zawierać będzie przynajmniej: opis wszystkich danych wejściowych (sygnatura funkcji oraz opis roli każdej zmiennej), opis danych wyjściowych (format i znaczenie), przynajmniej jedno zdanie opisujące działanie funkcji. Dokumentacja kodu powinna być kompletna, aby umożliwić rozwijanie kodu po zapoznaniu się z dokumentacją (bez konieczności analizowania kodu). Jeśli Wykonawca opierał będzie system na gotowych bibliotekach, zobowiązany jest on wybierać te, których interfejs programistyczny jest udokumentowany w stopniu pozwalającym programistom wykorzystanie biblioteki po zapoznaniu się z dokumentacją. W razie wykorzystania w oprogramowaniu bibliotek, udostępnionych publicznie jako Open Source, Wykonawca oświadcza, iż Zamawiający będzie mógł z nich korzystać bez ograniczeń oraz nie jest wymagane uzyskanie w tym zakresie jakichkolwiek zgód lub opłat na rzecz jakichkolwiek osób trzecich. Działanie kodu musi być zgodne z dokumentacją. Jeśli Wykonawca lub Zamawiający wykryją działanie kodu niezgodne z dokumentacją, Wykonawca zobowiązany będzie do wprowadzenia niezbędnych poprawek przed oddaniem ukończonego rezultatu zamówienia, lub w ramach gwarancji jako naprawienie wady istotnej ( błąd ważny ). 7. Dokumentacja modułu Sporządzając dokumentację modułu portalu Wykonawca zastosuje powszechnie przyjęte standardy dotyczące tworzenia kodu źródłowego oraz dokumentowania podstawowych funkcji i funkcjonalności modułu. Wykonawca dostarczy Zamawiającemu pełną dokumentację modułu portalu zawierającą dokumentację techniczną oraz dokumentację kodu źródłowego, najpóźniej w dniu odbioru modułu portalu przez Zamawiającego. Przy tworzeniu dokumentacji zaleca się wykorzystanie notacji UML 2.0. Wszystkie dokumenty powinny charakteryzować się wysoką jakością, na którą będą miały wpływ, takie czynniki jak: struktura dokumentu, rozumiana jako podział danego dokumentu na rozdziały, podrozdziały i sekcje, w czytelny i zrozumiały sposób, zachowanie standardów, rozumianych jako zachowanie spójnej struktury, formy i sposobu pisania dla poszczególnych dokumentów oraz fragmentów tego samego dokumentu, kompletność dokumentu, rozumiana jako pełne, bez wyraźnych luk czy braków, przedstawienie omawianego problemu obejmujące całość z danego zakresu rozpatrywanego zagadnienia, 6

7 spójność i niesprzeczność dokumentu, rozumiane jako zapewnienie wzajemnej zgodności 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. Dokumentacja modułu portalu musi zostać opracowana w języku polskim; jedynym dopuszczalnym wyjątkiem jest dokumentacja oprogramowania standardowego dostarczona w formie dystrybuowanej przez producenta w języku angielskim. 7.1 Dokumentacja techniczna modułu portalu W skład dokumentacji technicznej modułu portalu muszą wejść następujące elementy: 1) Opis techniczny modułu portalu powinien składać się z co najmniej następujących elementów: a. dokładny opis techniczny uzupełniony i zaktualizowany podczas implementacji, b. opis architektury modułu ze wszystkimi szczegółami, c. opis umożliwiający rozbudowę modułu uwzględniający w szczególności: tworzenie nowych funkcjonalności, tworzenie szablonów zawartości, sposób integracji aplikacji zewnętrznych, d. opis opracowanych interfejsów programistycznych: wymieniających informacje z innymi systemami, udostępniających informacje w formatach maszynowych (RSS, JSON, etc.), e. opis sposobu rozwiązywania problemów i optymalizacji, f. opis interfejsu użytkownika, g. opis instalacji i konfiguracji modułu, h. opis przeprowadzonych testów. 2) Opis procedur eksploatacyjnych Procedury eksploatacyjne muszą zawierać opis procedur w zakresie: a. administrowania zarządzania uprawnieniami, analiza użytkowania modułu portalu (log działań użytkowników), analiza pracy administratora (log działań administratora), b. bezpieczeństwa obsługi codziennej systemu zabezpieczeń, postępowania w sytuacjach alarmowych (reakcja na incydenty), odtworzenia modułu portalu po awarii. 3) Dokumentacja użytkownika moduł musi posiadać pełną dokumentację użytkownika opisującą możliwości konfiguracji aplikacji przez użytkownika, dostępnych funkcjonalności oraz możliwej interakcji. Dotyczy to także opisów interfejsów użytkownika. Dokumentacja użytkownika ma stanowić instrukcję korzystania z modułu. 4) Dokumentacja administratora portal musi posiadać pełną dokumentację administracyjną opisującą możliwości konfiguracyjne i zarządcze, również dokumentację mającą na celu 7

8 zestawienie informacji o możliwych problemach modułu portalu (zapisanych w logu) z opisem komunikatów identyfikujących problem i sposobem obejścia problemu. 7.2 Dokumentacja kodów źródłowych Dokumentacja kodów źródłowych musi zawierać: 1) listy pakietów i klas w poszczególnych pakietach, 2) hierarchię klas w pakiecie, 3) model zależności między klasami dla całego zbioru pakietów, 4) opis dla każdego pakietu, klasy, interfejsu lub metody z jej parametrami wraz z możliwymi zastosowaniami oraz przykładami użycia, 5) alfabetyczny indeks wszystkich klas, konstruktorów, pól i metod. Przekazany Zamawiającemu kod będzie zawierał taką liczbę komentarzy, która pozwoli programiście niezaangażowanemu w opracowanie niniejszego modułu portalu, przystąpić do jego modyfikacji natychmiast po zapoznaniu się z dokumentacją. Dokumentacja dla Administratorów opisywać będzie: a) mechanizmy platformy wykorzystywanej w procesie budowy, testowania oraz wdrażania aplikacji modułu portalu, ich ograniczenia i wymagania, b) mechanizmy wykorzystywane przez same aplikacje, ich ograniczenia oraz wymagania, c) języki (notacje) służące do definiowania składników aplikacji wraz z określeniem ich ograniczeń i wymagań, d) szczegółową specyfikację wymagań Zamawiającego, e) architekturę modułu portalu ze wszystkimi szczegółami. 8. Przekazanie dokumentacji Dokumentacja modułu portalu zostanie przekazana Zamawiającemu w trzech formach: a) Elektronicznej wersje robocze oraz wersja ostateczna edytowalna (umożliwiająca ewentualne aktualizacje) na płytach CD/DVD, w tym materiały instruktażowe dla administratora modułu portalu; b) System podpowiedzi wewnątrz interfejsu administracyjnego dokumentacja użytkownika dotycząca poszczególnych aspektów działania modułu portalu powinna być dostępna z poziomu interfejsu administracyjnego; c) Modele modułu portalu (repozytorium z wykorzystywanego narzędzia CASE) wynikające z przyjętych przez Wykonawcę i uzgodnionych w cyklu realizacji modułu portalu i narzędzi CASE wybranych do tego celu, w szczególności model wymagań modułu portalu. Modele muszą być przekazane w formacie umożliwiającym odczyt modeli za pomocą oprogramowania Open Source. Wykonawca dostarczy wszystkie części dokumentacji, o której mowa w pkt 8, do siedziby Zamawiającego, w formie elektronicznej, zapisanej na dysku CD, usystematyzowanej odpowiednio w ramach każdej części dokumentacji. Dokumentacja ta będzie przekazywana po zakończeniu każdego z etapów prac nad wykonaniem modułu portalu, zgodnie z ustalonym z Zamawiającym harmonogramem, natomiast ostateczna wersja dokumentacji modułu portalu 8

9 zostanie przekazana Zamawiającemu przed zakończeniem prac. Każda z ww. części dokumentacji powinna być przekazana Zamawiającemu w ramach odpowiednich protokołów zdawczo odbiorczych. 9. Prawa własności intelektualnej Wykonawca przeniesie na Zamawiającego całość autorskich praw majątkowych do wszystkich utworów wytworzonych w ramach realizacji przedmiotu zamówienia, w szczególności do Dokumentacji i programów komputerowych, które zostały opracowane lub użyte na potrzeby modułu portalu wraz z kodami źródłowymi, na wszystkich polach eksploatacji wymienionych w art. 50 i art. 74 ust. 4 Ustawy o prawach autorskich i prawach pokrewnych, łącznie z prawem do lincencjonowania oraz przenoszenia tych praw na inne podmioty. Wykonawca przeniesie na Zamawiającego również prawo udzielania zezwoleń na wykonywanie zależnego prawa autorskiego, a także prawa do know how i prawa własności przemysłowej, zawarte w rezultatach prac Wykonawcy. Dokonanie każdej modyfikacji lub aktualizacji utworów (wymaganych w okresie gwarancji), zwłaszcza oprogramowania i Dokumentacji modułu portalu przez Wykonawcę będzie skutkować przekazaniem Zamawiającemu majątkowych praw autorskich do tych modyfikacji, a także aktualnych kodów źródłowych aplikacji wraz z pełną dokumentacją, na wszystkich polach eksploatacji jak wobec pierwotnej postaci modułu portalu i jego dokumentacji. Przeniesienie autorskich praw majątkowych nie dotyczy oprogramowania obcego, o którym mowa w pkt 1 niniejszego dokumentu wraz z jego dokumentacją, na które Zamawiający otrzyma bezterminowe licencje (bez prawa wypowiedzenia) i uprawniające do korzystania przez nieograniczoną liczbę użytkowników oraz do instalacji i uruchomienia na sprzęcie będącym przedmiotem zamówienia. Wykonawca z chwilą przekazania Zamawiającemu efektów realizacji przedmiotu zamówienia stanowiących lub zawierających know how Wykonawcy, przeniesie na Zamawiającego wszelkie prawa do korzystania z nich bez ograniczeń co do zakresu, terminu, formy oraz terytorium, tj. w każdym celu prawnie dozwolonym, jaki może znaleźć zastosowanie w działalności Zamawiającego w odniesieniu do funkcjonowania Interizon Pomorskiego Klastra ICT. 10. Gwarancja i serwis Wykonawca zobowiązany jest zapewnić 24 miesięczną gwarancję na moduł portalu i serwis jego funkcjonowania. W ramach gwarancji Wykonawca będzie dostarczał poprawki, modyfikacje i aktualizacje modułu portalu oraz prowadził będzie wszelkie prace serwisowe mające na celu wyeliminowanie nieprawidłowości w działaniu modułu portalu, działającego niezgodnie z wymaganiami albo nie działającego wcale. Okres gwarancji liczony będzie od momentu wdrożenia modułu portalu i protokolarnego przekazania Zamawiającemu (podpisania protokołów zdawczo odbiorczych przez Zamawiającego i Wykonawcę) wszystkich składników modułu portalu i jego Dokumentacji. W celu ustalenia czasów reakcji serwisowych na zgłoszenia, błędy podzielono na 3 grupy: 1. Błąd zwykły problem nie powodujący bezpośredniego wpływu na obniżenie funkcjonalności modułu portalu. Ta grupa błędów obejmuje niewielkie rozbieżności funkcjonalności w porównaniu z opisami w dokumentacji modułu portalu, o której mowa w pkt. 8 oraz sporadyczne problemy i niedogodności w działaniu modułu portalu. 9

10 2. Błąd ważny problem powodujący poważne niedogodności w pracy modułu portalu oraz powtarzające się zakłócenia, które mogą mieć wpływ na funkcjonalność modułu portalu. 3. Błąd krytyczny problem mający globalny wpływ na działalność modułu portalu, w tym awaria oprogramowania oraz zabezpieczeń modułu portalu. W przypadku błędów zwykłych czas usunięcia błędów wynosi maksymalnie 5 dni, błędów ważnych 1 dni, błędów krytycznych 8 h. Czas usunięcia błędów jest to czas, jaki może upłynąć od momentu przyjęcia zgłoszenia do przywrócenia normalnego, zgodnego z Umową, funkcjonowania modułu portalu. Błąd uważa się za usunięty, gdy Wykonawca dostarczy i zainstaluje Zamawiającemu oprogramowanie lub jego część wolną od błędów, lub gdy Wykonawca przywróci oprogramowanie do działania poprzez zastosowanie środków zastępczych eliminujących źródło powstawania błędów. Zamawiający dopuszcza możliwość każdorazowego ustalenia z Wykonawcą co do wydłużenia wyżej wskazanych terminów usunięcia błędów w szczególnych przypadkach zgłoszonych i uzasadnionych przez Wykonawcę. Zgłoszenie takie podlega wyraźnej akceptacji Zamawiającego. W przypadku braku lub nieprawidłowego uzasadnienia przez Wykonawcę Zamawiający może nie udzielić akceptacji i Wykonawca będzie zobowiązany do zachowania wyżej wskazanych terminów. Wydłużenie wyżej wskazanych terminów jest także możliwe po uzyskaniu akceptacji Zamawiającego dla wskazanego przez Wykonawcę sposobu obejścia awarii, umożliwiającego normalne korzystanie z modułu portalu. Serwis ma być zapewniony co najmniej w dni robocze, czyli od poniedziałku do piątku w godz. od 8:00 do 16:00, z wyłączeniem dni ustawowo wolnych od pracy. Wszelkie wady i nieprawidłowości będą zgłaszane przez Zamawiającego niezwłocznie, drogą mailową lub faksem na podane adresy i numery wskazanych osób kontaktowych. 10