Informacje o przetargu
Usługa informatyczna pn.: Platforma Wymiany Informacji etap I. - polska-opole: usługi w zakresie projektowania stron www
Opis przedmiotu przetargu: 3.1 nazwa zamówienia usługa informatyczna pn. platforma wymiany informacji etap i. przedmiot zamówienia składa się następujących elementów – części 3.1.1 wykonanie strony internetowej pwi, 3.1.2 szkolenia z zakresu obsługi pwi, 3.1.3 obsługa deweloperska (rozwojowa). powyższe elementy nie stanowią odrębnych części zamówienia. ii.1.6)
Zamawiający:
Opolskie Centrum Rozwoju Gospodarki
Adres: | ul. Krakowska 38, 45-075 Opole, woj. opolskie |
---|---|
Dane kontaktowe: | email: biuro@ocrg.opolskie.pl tel: 77 40 33 600 fax: 77 40 33 609 |
Dane postępowania
ID postępowania: | 7193720141 | ||
---|---|---|---|
Data publikacji zamówienia: | 2014-03-01 | Termin składania wniosków: | 2014-04-10 |
Rodzaj zamówienia: | usługi | Tryb& postępowania [PN]: | Przetarg nieograniczony |
Czas na realizację: | 254 dni | Wadium: | 4500 ZŁ |
Oferty uzupełniające: | NIE | Oferty częściowe: | NIE |
Oferty wariantowe: | NIE | Przewidywana licyctacja: | NIE |
Ilość części: | 0 | Kryterium ceny: | 100% |
WWW ogłoszenia: | http://ocrg.opolskie.pl | Informacja dostępna pod: | Opolskie Centrum Rozwoju Gospodarki ul. Spychalskiego 1a, 45-716 Opole, woj. opolskie |
Okres związania ofertą: | 60 dni |
Kody CPV
72413000-8 | Usługi w zakresie projektowania stron WWW |
Wyniki
Nazwa części | Wykonawca | Wartość |
---|---|---|
Przedmiotem niniejszego zamówienia jest zorganizowanie i przeprowadzenie superwizji dla asystentów rodziny i specjalistów (psychologów, pedagogów) współpracujących z rodzinami | Nfinity.pl Sp. z o.o. Wrocław | 158 424,00 |
Barometr Ryzyka NadużyćRaport końcowy na temat potencjalnego ryzyka nadużyć dla wskazanej części wyniku postępowania przetargowego.
| Dane ogłoszenia o wyniku: Data udzielenia: 2014-06-03 Dotyczy cześci nr: 0 Kody CPV: 72413000 Ilość podmiotów składających się na wykonawcę: 1 Kwota oferty w PLN: 158 424,00 zł Minimalna złożona oferta: 158 424,00 zł Ilość złożonych ofert: 5 Ilość ofert odrzuconych przez zamawiającego: 0 Minimalna złożona oferta: 158 424,00 zł Maksymalna złożona oferta: 158 424,00 zł | |
TI | Tytuł | Polska-Opole: Usługi w zakresie projektowania stron WWW |
---|---|---|
ND | Nr dokumentu | 71937-2014 |
PD | Data publikacji | 01/03/2014 |
OJ | Dz.U. S | 43 |
TW | Miejscowość | OPOLE |
AU | Nazwa instytucji | Opolskie Centrum Rozwoju Gospodarki |
OL | Język oryginału | PL |
HD | Nagłówek | Państwa członkowskie - Zamówienie publiczne na usługi - Ogłoszenie o zamówieniu - Procedura otwarta |
CY | Kraj | PL |
AA | Rodzaj instytucji | R - Agencja/Biuro regionalne lub lokalne |
DS | Dokument wysłany | 27/02/2014 |
DT | Termin | 10/04/2014 |
NC | Zamówienie | 4 - Zamówienie publiczne na usługi |
PR | Procedura | 1 - Procedura otwarta |
TD | Dokument | 3 - Ogłoszenie o zamówieniu |
RP | Legislacja | 5 - Unia Europejska, z udziałem krajów GPA |
TY | Rodzaj oferty | 1 - Oferta całościowa |
AC | Kryteria udzielenia zamówienia | 1 - Najniższa cena |
PC | Kod CPV | 72413000 - Usługi w zakresie projektowania stron WWW |
OC | Pierwotny kod CPV | 72413000 - Usługi w zakresie projektowania stron WWW |
RC | Kod NUTS | PL522 |
IA | Adres internetowy (URL) | http://ocrg.opolskie.pl |
DI | Podstawa prawna | Dyrektywa klasyczna (2004/18/WE) |
Polska-Opole: Usługi w zakresie projektowania stron WWW
2014/S 043-071937
Ogłoszenie o zamówieniu
Usługi
Sekcja I: Instytucja zamawiająca
Opolskie Centrum Rozwoju Gospodarki
ul. Spychalskiego 1A
Punkt kontaktowy: Dział Organizacyjno-Administracyjny
Osoba do kontaktów: Barbara Rokosz
45-716 Opole
POLSKA
Tel.: +48 774033631
E-mail: b.rokosz@ocrg.opolskie.pl
Faks: +48 774033609
Adresy internetowe:
Ogólny adres instytucji zamawiającej: http://ocrg.opolskie.pl
Więcej informacji można uzyskać pod adresem: Powyższy(-e) punkt(-y) kontaktowy(-e)
Specyfikacje i dokumenty dodatkowe (w tym dokumenty dotyczące dialogu konkurencyjnego oraz dynamicznego systemu zakupów) można uzyskać pod adresem: Powyższy(-e) punkt(-y) kontaktowy(-e)
Oferty lub wnioski o dopuszczenie do udziału w postępowaniu należy przesyłać na adres: Powyższy(-e) punkt(-y) kontaktowy(-e)
Sekcja II: Przedmiot zamówienia
Kategoria usług: nr 7: Usługi komputerowe i usługi z nimi związane
Główne miejsce lub lokalizacja robót budowlanych, miejsce realizacji dostawy lub świadczenia usług: Opole.
Kod NUTS PL522
Przedmiot zamówienia składa się następujących elementów – części:
3.1.1 Wykonanie strony internetowej PWI,
3.1.2 Szkolenia z zakresu obsługi PWI,
3.1.3 Obsługa deweloperska (rozwojowa).
Powyższe elementy nie stanowią odrębnych części zamówienia.
72413000
Nazwa zamówienia: Usługa informatyczna pn.: Platforma Wymiany Informacji etap I
Zamiarem 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 Innowacji
1.1. Podstawowe założenia systemu
Zamawiają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ązania
45) 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 508
e. 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 systemem
Zamawiają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ów
Konta 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 autoryzacji
Przez 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żytkownikami
Zamawiają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 Serwisu
1) Administrator – pełen dostęp do ustawień i zawartości serwisu
2) 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ści
CMS 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 portalu
Zamawiają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. Środowisko
System 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) Frontend
Skó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ób
3) Małe obrazki, będące elementami interfejsu, powinny być zaszyte w plikach css w postaci ciągu data:image base64
4) Wszelkie zasoby statyczne, będące częścią interfejsu graficznego (css,js, ikony, czcionki, obrazki interfejsu) powinny być serwowane z osobnej subdomeny
5) 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 css
14) Strona powinna zawierać minimalną ilość kodu html, tak aby proporcja treści strony do kodu wyświetlającego tą treść była jak największa
15) Szczególną uwagę należy tutaj zwrócić na generowanie nadmiarowych klas i identyfikatorów, oraz wielokrotnie zagnieżdżonych znaczników, przez system CMS
16) Obrazki wysyłane przez serwer nie powinny być kompresowane przez serwer (gzip) a jedynie optymalizowane przez aplikację w momencie generowania miniatur.
(b) Style
System 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) Grafika
Należ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 Portalu
Lista modułów wraz z opisem funkcjonalnym znajduje się w Załączniku 3.
3. Dodatkowa funkcjonalność
3.1. Statystki
1) 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 serwisu
8) 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 informacji
Portal 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. Banery
Funkcjonalność 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ących
Projekty 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. SEO
Serwis 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 Media
Serwis 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 mobilna
Serwis 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. Multisite
System 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 Serwisu
1) 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ów
1) 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ństwo
1) 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 Tampering
b. SQL Injection
c. HTML Injection
d. Command Injection
e. XSS - Cross-Site-Scripting
f. CSRF - Cross Site Request Forgeries
g. CRLF Injection
h. 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 Hacking
i. Path Traversal, Directory Traversal
j. Forceful Browning
13) 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 OPI
Stworzone 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 projektem
Dla 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żeniowej
Podczas 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ówienia
Wykonawca 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ącego
Analiza 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ącego
1) 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 OPI
Projekt 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żytkownika
Dokumentacja Użytkownika musi uwzględniać podręczniki dla każdej z opisanych ról tzn.:
— Administratora
— Redaktor
— Moderator
— Użytkownik zarejestrowany
— Użytkownik niezarejestrowany
i zawierać dokładny opis realizowanej funkcjonalności.
7.5. Plan testów funkcjonalnych
Dokument 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 niefunkcjonalnych
Dokument 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 administratora
Dokumentacja 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ów
1) 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 przeszkolenia
Obsługa Serwisu OPI dla Administratorów Szkolenie 3-dniowe, każdego dnia przeprowadzonych zostanie 8 godzin szkoleniowych do 5
Obsługa Serwisu OPI dla Redaktorów Szkolenie 2-dniowe, każdego dnia przeprowadzonych zostanie 8 godzin szkoleniowych do 5
Obsługa Serwisu OPI dla Moderatorów Szkolenie 2-dniowe, każdego dnia przeprowadzonych zostanie 8 godzin szkoleniowych do 5
9. Obsługa developerska
1) 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ązania
10.1. Ogólne wymagania prawne dla dostarczanego rozwiązania
1) 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. Licencje
1) 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ątkowe
Wykonawca 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 gwarancyjnego
1) 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łączenia
W 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 systemami
1) ActiveDirectory w zakresie uprawnień.
2) Serwisy społecznościowe: Twitter, Facebook, Pinterest.
3) Mechanizm Google Analytics.
14. Warunki odbioru przedmiotu zamówienia
14.1. Definicje
Etap 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 projektu
Projekt 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 etapu
01 Plan Projektu
02 Opracowanie koncepcji Serwisu PWI
Licencje na oprogramowanie
Zainstalowany i skonfigurowany Serwisu PWI
03 Szkolenia
Dokumentacja
04 Obsługa deweloperska
Etap 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ów
Odbiory 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 procedury
1) 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 procedury
Odbió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 Technicznego
1) 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 procedury
Odbió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 projektu
1) Wykonawca po odebraniu wszystkich Etapów Technicznych w ramach Projektu przedkłada Kierownikowi Projektu po stronie Zamawiającego projekt Raportu Końcowego Projektu
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ą, 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ściowe
Kryteria 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) Oprogramowanie
Kryterium Norma Metoda kontroli
Kryteria jakościowe
Funkcjonalność 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ącego
lub
Scenariusz 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ąd
Konfiguracja oprogramowania Dostarczone oprogramowanie jest skonfigurowane w sposób umożliwiający jego użycie bez wprowadzania dodatkowych ustawień Jednorazowe uruchomienie
Licencjonowanie 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 instalacja
Kryteria ilościowe
Liczba licencji Liczba dostarczonych licencji odpowiada liczbie wynikającej z OPZ Przegląd dokumentu licencyjnego
Liczba instalacji Liczba instalacji odpowiada liczbie wynikającej z oferty Wykonawcy Przegląd raportów z instalacji
(b) Dokumentacja
Kryterium Norma Metoda kontroli
Kryteria jakościowe
Struktura dokumentu Dokument jest podzielony na rozdziały, podrozdziały i sekcje Przegląd
Kompletność dokumentu Dokument zawiera wszystkie elementy opisane w OPZ Porównanie dokumentu z wymaganiami zawartymi w OPZ
Kompletność dokumentacji Każdy produkt podlegający odbiorowi (poza dokumentacją i promocją) posiada dokumentację Porównanie listy dokumentacji listą produktów podlegających odbiorowi
Spó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ąd
Format dokumentu elektronicznego Wersja elektroniczna dokumentu jest przekazana w formatach Word i PDF Otwarcie dokumentu za pomocą (odpowiednio) MS Word 2010 lub Adobe Reader
Nośnik dokumentu Wersja elektroniczna dokumentu jest przekazana na płycie CD lub DVD
Wersja papierowa dokumentu jest przekazana w formie drukowanej i trwale oprawionej Otworzenie dokumentu bezpośrednio z płyty umieszczonej w czytniku CD lub DVD
Przegląd
Język dokumentacji Dokumentacja jest dostarczona w całości w języku polskim Przegląd
Kryteria ilościowe
Wersja 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ą dokumentacji
Wersja 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) Szkolenia
Kryterium Norma Metoda kontroli
Kryteria jakościowe
Spełnienie wymagań ogólnych Spełnienie wszystkich wymagań ogólnych Lista kontrolna
Język szkolenia Szkolenia muszą być przeprowadzone w języku polskim Przegląd oświadczeń wykonawcy
Zakres szkolenia Zakres szkolenia jest zgodny z wymaganiami na szkolenia Przegląd materiałów szkoleniowych
Materiały szkolenia Każdy uczestnik otrzymuje wydrukowany komplet materiałów szkoleniowych w języku polskim Przegląd materiałów
Liczebność grup Pojedyncza sesja szkoleniowa jest przeprowadzana dla maksymalnie 5 osób Przegląd listy obecności
Certyfikat Każdy uczestnik otrzymuje certyfikat ukończenia szkolenia Przegląd kopii certyfikatów
Kryteria ilościowe
Liczba uczestników szkoleń do 30 Przegląd list obecności
Liczba dni szkoleniowych 9 Przegląd harmonogramu szkoleń
Szacunkowa wartość bez VAT: 153 746,67 PLN
Sekcja III: Informacje o charakterze prawnym, ekonomicznym, finansowym i technicznym
8.1.1 Oferta musi być zabezpieczona wadium w wysokości: 4 500,00 PLN (słownie: cztery tysiące pięćset złotych 00/100).
8.2 Formy wadium
Wadium może być wniesione w następujących formach:
8.2.1 pieniądzu,
8.2.1 poręczeniach bankowych lub poręczeniach spółdzielczej kasy oszczędnościowo-kredytowej
z tym, że poręczenie kasy jest zawsze poręczeniem pieniężnym,
8.2.1 gwarancjach bankowych,
8.2.1 gwarancjach ubezpieczeniowych,
8.2.1 poręczeniach udzielanych przez podmioty, o których mowa w art. 6b ust. 5 pkt 2 ustawy z dnia 9 listopada 2000 r. o utworzeniu Polskiej Agencji Rozwoju Przedsiębiorczości (Dz. U. Nr 109, poz. 1158, z późn. zm.)
8.3 Sposób i miejsce składania wadium
8.3.1 Wadium w formie pieniężnej należy wnieść przelewem na rachunek bankowy zamawiającego: bank Millennium numer konta: 80 1160 2202 0000 0002 4115 4944 z adnotacją: "Wadium – nr sprawy: DOA/323/12/2014".
8.3.2 Wadium wnoszone w formach wskazanych w pkt. od 8.2.1.2 do 8.2.1.5 należy złożyć w formie oryginału w siedzibie Zamawiającego, w sekretariacie, przed upływem terminu składania ofert. Do oferty należy załączyć potwierdzoną za zgodność z oryginałem kserokopię złożonego dokumentu.
8.3.3 Z treści gwarancji (poręczenia) musi jednoznacznie wynikać, jaki jest sposób reprezentacji gwaranta. Gwarancja musi być podpisana przez upoważnionego (upełnomocnionego) przedstawiciela gwaranta. Podpis winien być sporządzony w sposób umożliwiający jego identyfikację np. złożony wraz z imienną pieczątką lub czytelny (z podaniem imienia i nazwiska).
8.3.4 Z treści gwarancji winno wynikać, że jest gwarancja nieodwołalną oraz bezwarunkową, wykonalna na terenie Rzeczpospolitej Polskiej, na pierwsze pisemne żądanie zgłoszone przez zamawiającego w terminie związania ofertą, zobowiązanie gwaranta do wypłaty zamawiającemu pełnej kwoty wadium w okolicznościach określonych w art. 46 ust. 4a i ust. 5 ustawy Prawo zamówień publicznych.
8.4 Obowiązujące zasady wnoszenia i zwrotu wadium określone zostały w art. 45-46 ustawy Pzp.
(numeracja zgodna z SIWZ)
Wykonawcy mogą wspólnie ubiegać się o udzielenie zamówienia, jako konsorcjum. W takim przypadku ich oferta musi spełniać następujące wymagania:
6.7.1 Wykonawcy wspólnie ubiegający się o udzielenie zamówienia ustanowią pełnomocnika do reprezentowania ich w postępowaniu o udzielenie zamówienia albo reprezentowania
w postępowaniu i zawarcia umowy w sprawie zamówienia publicznego.
6.7.2 Przepisy dotyczące wykonawcy stosuje się odpowiednio do wykonawców wspólnie ubiegających się o udzielenie zamówienia.
6.7.3 Jeżeli oferta wykonawców, wspólnie ubiegających się o udzielenie zamówienia, została wybrana, zamawiający może żądać przed zawarciem umowy w sprawie zamówienia publicznego umowy regulującej współpracę tych wykonawców.
6.7.4 Wszelka korespondencja oraz rozliczenia dokonywane będą wyłącznie z pełnomocnikiem (liderem konsorcjum),
6.7.5 Wykonawcy wspólnie ubiegający się o udzielenie zamówienia składają oświadczenia,
z których treści wynikać będzie, że razem/łącznie spełniają warunki udziału w postępowaniu wynikające z art. 22 ust. 1 ustawy Pzp (wzór oświadczenia stanowi zał. nr 2 do SIWZ).
6.7.6 Wykonawcy wspólnie ubiegający się o udzielenie zamówienia składają oddzielnie oświadczenia o nie podleganiu wykluczeniu z art. 24 ust. 1 ustawy Pzp (wzór oświadczenia stanowi zał. nr 3 do SIWZ) oraz oddzielnie listę podmiotów należących do tej samej grupy kapitałowej w rozumieniu ustawy z dnia 16 lutego 2007 r. o ochronie konkurencji i konsumentów albo informacji o tym, że nie należą do grupy kapitałowej (wg załączonego wzoru –zał. nr 6 do SIWZ).
(numeracja zgodna z SIWZ)
1. O udzielenie zamówienia mogą ubiegać się Wykonawcy, którzy spełniają ogólne warunki dotyczące:
5.1.1 posiadania uprawnień do wykonywania określonej działalności lub czynności, jeżeli przepisy prawa nakładają obowiązek ich posiadania.
Zamawiający nie stawia szczególnych wymagań w zakresie spełniania tego warunku. Wykonawca potwierdza spełnianie tego warunku poprzez złożenie oświadczenia (wg wzoru w zał. nr 2 do SIWZ)
5.1.2 posiadania wiedzy i doświadczenia;
W postępowaniu mogą wziąć udział Wykonawcy, którzy w okresie ostatnich trzech lat przed upływem terminu składania ofert, a jeżeli okres prowadzenia działalności jest krótszy - w tym okresie wykonali bądź wykonują należycie minimum jedną usługę informatyczną polegającą na stworzeniu platformy internetowej związanej z wymianą informacji oraz posiadają doświadczenie w zakresie prowadzenia szkoleń z zakresu obsługi stworzonego portalu, jako ich administrator, moderator i redaktor oraz posiadają doświadczenie w obsłudze deweloperskiej – rozwojowej portalu o wartości tej usługi nie mniejszej niż 150.000,00 zł netto.
Wszystkie powyższe cechy wymienionego doświadczenia muszą dotyczyć jednej usługi rozumianej, jako jeden projekt informatyczny uwzględniający kompleksowo zakres wymaganego doświadczenia.
5.1.3 dysponowania odpowiednim potencjałem technicznym oraz osobami zdolnymi do wykonania zamówienia;
Wykonawca musi wykazać, że dysponuje lub będzie dysponował na czas realizacji zamówienia zespołem tj.: osobami, które będą uczestniczyć w wykonaniu niniejszego zamówienia, legitymującymi się odpowiednimi kwalifikacjami zawodowymi, doświadczeniem i wykształceniem niezbędnym do jego wykonania tj.:
5.1.3.1 min. 1 osobą - koordynatora projektu po stronie Wykonawcy:
— posiadającą wykształcenie wyższe informatyczne (I lub II stopnia i uzyskała tytuł licencjata, inżyniera, magistra lub tytuł równorzędny z dziedziny informatyki)
oraz
— posiadającą kwalifikacje zawodowe niezbędne do zarządzania zespołem min. 4 osób (informatyków operacyjnych)
oraz
— posiadającą doświadczenie zdobyte w okresie ostatnich 3 lat przed dniem wszczęcia niniejszego postępowania – w zarządzaniu zespołem informatyków przy realizacji, co najmniej 2 projektów informatycznych o wartości tych projektów na min. 150.000,00 zł netto każdy projekt.
5.1.3.2 min. 4 osób – informatyków operacyjnych:
— posiadających (każdy) wykształcenie wyższe informatyczne (I lub II stopnia i uzyskały tytuł licencjata, inżyniera, magistra lub tytuł równorzędny z dziedziny informatyki)
oraz
— posiadających (każdy) doświadczenie zdobyte w okresie w okresie ostatnich 3 lat przed dniem wszczęcia niniejszego postępowania – w realizacji, co najmniej 2 projektów informatycznych o wartości tych projektów na min. 150.000,00 zł netto każdy projekt.
5.1.4 sytuacji ekonomicznej i finansowej
Zamawiający nie stawia szczególnych wymagań w zakresie spełniania tego warunku. Wykonawca potwierdza spełnianie tego warunku poprzez złożenie oświadczenia (wg wzoru w zał. nr 2 do SIWZ).
6. Wykaz oświadczeń lub dokumentów, jakie mają dostarczyć wykonawcy w celu potwierdzenia spełniania warunków udziału w postępowaniu
6.1 W celu oceny spełniania przez wykonawców warunków, o których mowa w art. 22 ust. 1 ustawy Pzp Wykonawcy przystępujący do niniejszego postępowania zobowiązani są złożyć:
6.1.1 oświadczenie o spełnianiu warunków udziału w postępowaniu (wg wzoru na załączniku nr 2 do SIWZ),
6.1.2 wykaz wykonanych, a w przypadku świadczeń okresowych lub ciągłych również wykonywanych głównych dostaw lub usług, w okresie ostatnich trzech lat przed upływem terminu składania ofert albo wniosków o dopuszczenie do udziału
w postępowaniu, a jeżeli okres prowadzenia działalności jest krótszy - w tym okresie, wraz z podaniem ich wartości, przedmiotu, dat wykonania i podmiotów, na rzecz których dostawy lub usługi zostały wykonane, oraz załączeniem dowodów, czy zostały wykonane lub są wykonywane należycie (wzór wykazu stanowi załącznik nr 4 do SIWZ),
6.1.3 wykaz osób, które będą uczestniczyć w wykonywaniu zamówienia, w szczególności odpowiedzialnych za świadczenie usług, kontrolę jakości lub kierowanie robotami budowlanymi, wraz z informacjami na temat ich kwalifikacji zawodowych, doświadczenia i wykształcenia niezbędnych do wykonania zamówienia, a także zakresu wykonywanych przez nie czynności, oraz informacją o podstawie do dysponowania tymi osobami (wzór wykazu stanowi załącznik nr 5 do SIWZ).
6.2 Dotyczące art. 24 ust. 1 ustawy Pzp:
W celu wykazania braku podstaw do wykluczenia z postępowania o udzielenie zamówienia Wykonawcy w okolicznościach, o których mowa w art. 24 ust. 1 ustawy Pzp Zamawiający żąda złożenia następujących dokumentów:
6.2.1 oświadczenia o braku podstaw do wykluczenia (wg wzoru na załączniku nr 3 do SIWZ),
6.2.2 aktualnego odpisu z właściwego rejestru lub z centralnej ewidencji i informacji o działalności gospodarczej, jeżeli odrębne przepisy wymagają wpisu do rejestru lub ewidencji, w celu wykazania braku podstaw do wykluczenia w oparciu o art. 24 ust. 1 pkt 2 ustawy, wystawionego nie wcześniej niż 6 miesięcy przed upływem terminu składania wniosków o dopuszczenie do udziału w postępowaniu o udzielenie zamówienia albo składania ofert;
6.2.3 aktualnego zaświadczenia właściwego naczelnika urzędu skarbowego potwierdzającego, że wykonawca nie zalega z opłacaniem podatków, lub zaświadczenia, że uzyskał przewidziane prawem zwolnienie, odroczenie lub rozłożenie na raty zaległych płatności lub wstrzymanie w całości wykonania decyzji właściwego organu - wystawionego nie wcześniej niż 3 miesiące przed upływem terminu składania wniosków o dopuszczenie do udziału w postępowaniu o udzielenie zamówienia albo składania ofert;
6.2.4 aktualnego zaświadczenia właściwego oddziału Zakładu Ubezpieczeń Społecznych lub Kasy Rolniczego Ubezpieczenia Społecznego potwierdzającego, że wykonawca nie zalega
z opłacaniem składek na ubezpieczenia zdrowotne i społeczne, lub potwierdzenia, że uzyskał przewidziane prawem zwolnienie, odroczenie lub rozłożenie na raty zaległych płatności lub wstrzymanie w całości wykonania decyzji właściwego organu - wystawionego nie wcześniej niż 3 miesiące przed upływem terminu składania wniosków o dopuszczenie do udziału w postępowaniu o udzielenie zamówienia albo składania ofert;
6.2.5 aktualnej informacji z Krajowego Rejestru Karnego w zakresie określonym w art. 24 ust. 1 pkt 4-8 ustawy, wystawionej nie wcześniej niż 6 miesięcy przed upływem terminu składania wniosków o dopuszczenie do udziału w postępowaniu o udzielenie zamówienia albo składania ofert;
6.2.6 aktualnej informacji z Krajowego Rejestru Karnego w zakresie określonym w art. 24 ust. 1 pkt
9 ustawy, wystawionej nie wcześniej niż 6 miesięcy przed upływem terminu składania wniosków o dopuszczenie do udziału w postępowaniu o udzielenie zamówienia albo składania ofert.
6.2.7 aktualnej informacji z Krajowego Rejestru Karnego w zakresie określonym w art. 24 ust. 1 pkt 10 i 11 ustawy, wystawionej nie wcześniej niż 6 miesięcy przed upływem terminu składania wniosków o dopuszczenie do udziału w postępowaniu o udzielenie zamówienia albo składania ofert.
6.3 Dot. Podmiotów zagranicznych
6.3.1 Jeżeli, w przypadku wykonawcy mającego siedzibę na terytorium Rzeczypospolitej Polskiej, osoby, o których mowa w art. 24 ust. 1 pkt 5-8, 10 i 11 ustawy, mają miejsce zamieszkania poza terytorium Rzeczypospolitej Polskiej, wykonawca składa w odniesieniu do nich zaświadczenie właściwego organu sądowego albo administracyjnego miejsca zamieszkania, dotyczące niekaralności tych osób w zakresie określonym w art. 24 ust. 1 pkt 5-8,10 i 11 ustawy, wystawione nie wcześniej niż 6 miesięcy przed upływem terminu składania wniosków
o dopuszczenie do udziału w postępowaniu o udzielenie zamówienia albo składania ofert, z tym że w przypadku gdy w miejscu zamieszkania tych osób nie wydaje się takich zaświadczeń - zastępuje się je dokumentem zawierającym oświadczenie złożone przed właściwym organem sądowym, administracyjnym albo organem samorządu zawodowego lub gospodarczego miejsca zamieszkania tych osób lub przed notariuszem.
6.3.2 Jeżeli wykonawca ma siedzibę lub miejsce zamieszkania poza terytorium Rzeczypospolitej Polskiej, zamiast dokumentów, o których mowa w pkt. 6.2:
a) pkt 6.2.2-6.2.4 i 6.2.6 - składa dokument lub dokumenty wystawione w kraju, w którym ma siedzibę lub miejsce zamieszkania, potwierdzające odpowiednio, że:
- nie otwarto jego likwidacji ani nie ogłoszono upadłości,
- nie zalega z uiszczaniem podatków, opłat, składek na ubezpieczenie społeczne i zdrowotne albo że uzyskał przewidziane prawem zwolnienie, odroczenie lub rozłożenie na raty zaległych płatności lub wstrzymanie w całości wykonania decyzji właściwego organu,
- nie orzeczono wobec niego zakazu ubiegania się o zamówienie,
b) pkt 6.2.5 i 6.2.7 - składa zaświadczenie właściwego organu sądowego lub administracyjnego miejsca zamieszkania albo zamieszkania osoby, której dokumenty dotyczą, w zakresie określonym w art. 24 ust. 1 pkt 4-8,10 i 11 ustawy.
6.3.3 Dokumenty, o których mowa w pkt 6.3.2 lit. a tiret pierwsze i trzecie, lit. b powinny być wystawione nie wcześniej niż 6 miesięcy przed upływem terminu składania wniosków o dopuszczenie do udziału w postępowaniu o udzielenie zamówienia albo składania ofert. Dokument, o którym mowa w pkt 6.3.2 lit. a tiret drugie, powinien być wystawiony nie wcześniej niż 3 miesiące przed upływem terminu składania wniosków o dopuszczenie do udziału w postępowaniu o udzielenie zamówienia albo składania ofert.
6.3.4 Jeżeli w kraju miejsca zamieszkania osoby lub w kraju, w którym wykonawca ma siedzibę lub miejsce zamieszkania, nie wydaje się dokumentów, o których mowa w 6.3.2 SIWZ, zastępuje się je dokumentem zawierającym oświadczenie, w którym określa się także osoby uprawnione do reprezentacji wykonawcy, złożone przed właściwym organem sądowym, administracyjnym albo organem samorządu zawodowego lub gospodarczego odpowiednio kraju miejsca zamieszkania osoby lub kraju, w którym wykonawca ma siedzibę lub miejsce zamieszkania, lub przed notariuszem. Do dokumentów stosuje się pkt. 6.3.3 odpowiednio.
6.4 Dot. art. 24 ust. 2 pkt. 5) i art. 24b ust. 3 ustawy Pzp - Lista podmiotów należących do tej samej grupy kapitałowej:
W celu wykazania braku podstaw do wykluczenia z postępowania o udzielenie zamówienia
w okolicznościach, o których mowa w art. 24 ust. 2 pkt. 5) i art. 24b ust. 3 ustawy Pzp Wykonawcy przystępujący do niniejszego postępowania zobowiązani są złożyć listę podmiotów należących do tej samej grupy kapitałowej w rozumieniu ustawy z dnia 16 lutego 2007 r. o ochronie konkurencji
i konsumentów albo informacji o tym, że nie należy do grupy kapitałowej (wg załączonego wzoru –zał. nr 6 do SIWZ).
6.5 Oświadczenia i dokumenty niezbędne do przeprowadzenia postępowania
6.5.1 wypełniony formularz ofertowy (wg załączonego wzoru –zał. nr 1),
6.5.2 pełnomocnictwo podmiotów występujących wspólnie (jeżeli dotyczy),
6.5.3 oświadczenia i dokumenty, o których mowa, w pkt. 6.1 - 6.4 SIWZ.
6.6 Forma dokumentów
Dokumenty sporządzone w języku obcym muszą być złożone wraz z tłumaczeniem na język polski, poświadczone przez wykonawcę.
(numeracja zgodna z SIWZ)
Sekcja IV: Procedura
Sekcja VI: Informacje uzupełniające
Podać odniesienie do projektu (projektów) i/lub programu (programów): "Inwestujemy w Twoją przyszłość”
Projekt współfinansowany przez Unię Europejską ze środków Europejskiego Funduszu Rozwoju Regionalnego
w ramach Regionalnego Programu Operacyjnego Województwa Opolskiego na lata 2007-2013
Oś priorytetowa 1 Wzmocnienie atrakcyjności gospodarczej regionu
Działanie 1.3 Innowacje, badania, rozwój technologiczny
Poddziałanie 1.3.1. Wsparcie sektora B+R oraz innowacji na rzecz przedsiębiorstw
„Opolska Platforma Innowacji”
nr decyzji: RPOP.01.03.01-16-016/12-00 z dnia 10.12.2012 r.
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)
Urząd Zamówień Publicznych
ul. Postępu 17a
02-676 Warszawa
POLSKA
E-mail: odwolania@uzp.gov.pl
Tel.: +48 224587801
Adres internetowy: http://www.uzp.gov.pl/
Faks: +48 224587700
1) w terminie 10 dni od dnia przesłania informacji o czynności zamawiającego stanowiącej podstawą jego wniesienia – jeżeli zostały przesłane w sposób określony w art. 27 ust. 2, albo w terminie 15 dni – jeżeli zostałyprzesłane w inny sposób – w przypadku, gdy wartość zamówienia jest równa lub przekracza kwoty określone wprzepisach wydanych na podstawie art. 11 ust. 8;
2. Odwołanie wobec treści ogłoszenia o zamówieniu, a jeżeli postępowanie jest prowadzone w trybie przetargunieograniczonego, także wobec postanowień specyfikacji istotnych warunków zamówienia, wnosi się wterminie:
1) 10 dni od dnia publikacji ogłoszenia w Dzienniku Urzędowym Unii Europejskiej lub zamieszczeniaspecyfikacji istotnych warunków zamówienia na stronie internetowej – jeżeli wartość zamówienia jest równa lubprzekracza kwoty określone w przepisach wydanych na podstawie art. 11 ust. 8.
3. Odwołanie wobec czynności innych niż określone w ust. 1 i 2 wnosi się:
1) w przypadku zamówień, których wartość jest równa lub przekracza kwoty określone w przepisachwydanychna podstawie art. 11 ust. 8 – w terminie 10 dni od dnia, w którym powzięto lub przy zachowaniu należytejstaranności można było powziąć wiadomość o okolicznościach stanowiących podstawę jego wniesienia".
Urząd Zamówień Publicznych
ul. Postępu 17a
02-676 Warszawa
POLSKA
E-mail: odwolania@uzp.gov.pl
Tel.: +48 224587801
Adres internetowy: http://www.uzp.gov.pl/
Faks: +48 224587700
TI | Tytuł | Polska-Opole: Usługi w zakresie projektowania stron WWW |
---|---|---|
ND | Nr dokumentu | 81604-2014 |
PD | Data publikacji | 11/03/2014 |
OJ | Dz.U. S | 49 |
TW | Miejscowość | OPOLE |
AU | Nazwa instytucji | Opolskie Centrum Rozwoju Gospodarki |
OL | Język oryginału | PL |
HD | Nagłówek | Państwa członkowskie - Zamówienie publiczne na usługi - Dodatkowe informacje - Procedura otwarta |
CY | Kraj | PL |
AA | Rodzaj instytucji | R - Agencja/Biuro regionalne lub lokalne |
DS | Dokument wysłany | 06/03/2014 |
DT | Termin | 10/04/2014 |
NC | Zamówienie | 4 - Zamówienie publiczne na usługi |
PR | Procedura | 1 - Procedura otwarta |
TD | Dokument | 2 - Dodatkowe informacje |
RP | Legislacja | 5 - Unia Europejska, z udziałem krajów GPA |
TY | Rodzaj oferty | 1 - Oferta całościowa |
AC | Kryteria udzielenia zamówienia | 1 - Najniższa cena |
PC | Kod CPV | 72413000 - Usługi w zakresie projektowania stron WWW |
OC | Pierwotny kod CPV | 72413000 - Usługi w zakresie projektowania stron WWW |
RC | Kod NUTS | PL522 |
Polska-Opole: Usługi w zakresie projektowania stron WWW
2014/S 049-081604
Opolskie Centrum Rozwoju Gospodarki, ul. Spychalskiego 1A, Dział Organizacyjno-Administracyjny, Osoba do kontaktów: Barbara Rokosz, Opole45-716, POLSKA. Tel.: +48 774033631. Faks: +48 774033609. E-mail: b.rokosz@ocrg.opolskie.pl
(Suplement do Dziennika Urzędowego Unii Europejskiej, 1.3.2014, 2014/S 43-071937)
CPV:72413000
Usługi w zakresie projektowania stron WWW
Zamiast:
II.2.1) Całkowita wielkość lub zakres:
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
—.
Powinno być:II.2.1) Całkowita wielkość lub zakres:
Załącznik nr 3
do
SZCZEGÓŁOWEGO OPISU PRZEDMIOTU ZAMÓWIENIA
pn. „Platforma Wymiany Informacji etap I”
Moduły funkcjonalne Serwisów Platformy Wymiany Informacji
Moduł Artykuły
Moduł Artykuły rozumiany jest jako komponent Serwisu umożliwiający:
tworzenie i publikowania treści na stronach w ramach Serwisu PWI
przechowywania materiałów typu zdjęcia, firmy, pliki do pobrania, w tzw. bibliotekach
tworzenie i edycja biblioteki linków
tworzenia kalendarium wydarzeń
Moduł Artykuły może być kopiowany na dowolną stronę w ramach Serwisu PWI i za każdym razem tworzone są właściwe dla modułu komponenty w bazie danych.
Tworzenie treści do publikacji
Tworzenie artykułów musi być jak najbardziej przyjazne dla Redaktora, w związku z tym musi być wyposażony w WYSIWYG. W treści artykułu Redaktor może wprowadzać teksty, zamieszczać zdjęcia, filmy, pliki do pobrania lub linki pobierane z bibliotek. Wstawiając zdjęcia i filmy musi być wymagane od Redaktora opisania ich tekstem alternatywnym. Pliki do pobrania i linki kierujące do innych stron dla odwiedzających widoczne są jako wyróżniony tekst.
Każda tworzona na stronę treść powinien mieć przypisane atrybuty tj.:
— autor treści
— tytuł widoczny na stronie
— data utworzenia
— zakres czasowy w jakim treść ma być widoczny lub bezterminowo
— słowa kluczowe
Dodatkowo każda treść musi mieć możliwość określenia gdzie i jak ma być publikowana tzn.:
3. czy zapowiedź treści będzie widoczna w Aktualnościach
4. uprawnienia do czytania treści mają:
1. wszyscy odwiedzający stronę
2. tylko Użytkownicy zarejestrowani
Użytkownicy niezarejestrowani tylko do ograniczonej części.
Jeśli treść dla Użytkowników niezarejestrowanych jest dostępna tylko częściowo, to na końcu widocznej treści musi być link typu „czytaj więcej”, po kliknięciu którego odwiedzający stronę będzie miał otwierane okno do rejestracji Profilu.
Każda treść publikowana na stronie musi zawierać elementy:
— Tytuł
— Autor
— Data publikacji
— Historia zmian po opublikowaniu treści
Moduł musi umożliwiać prowadzenie pracy grupowej nad treścią przeznaczoną do publikacji. Już po publikacji treści na stronie jest możliwość edycji, w systemie musi być przechowywana informacja o dokonanych zmianach, dane autora zmian oraz termin zamiany.
Moduł musi umożliwiać publikację artykułu nie tylko na stronie której dotyczy, ale również na pozostałych stronach składających się na Serwis PWI.
Aktualności
Komponent jest ściśle powiązany z komponentem tworzenia treści. Każda treść publikowana na stronie może, ale nie musi, być zamieszczana w formie zapowiedzi w Aktualnościach. Dla odwiedzającego stronę Aktualności będą widoczne jako element strony. W zależności od tego jaką dostępność treści określi Redaktor taka też będzie zapowiedź wyświetlana na stronie, tzn.:
5) dla wszystkich Użytkowników,
6) tylko dla Użytkowników zarejestrowanych.
Kalendarium wydarzeń
Kalendarium wydarzeń może być zablokowane, co znaczy, że nie będzie widoczne na danej stronie. Do wyłączenia komponentu ma uprawnienia tylko Administrator. Komponent umożliwia wyświetlanie informacji o wydarzenia w formie terminarza. Z wpisami na terminarzu muszą być powiązane treści, galerie zdjęć, filmy. W zależności od dostępności materiału powiązanego wpisy do kalendarium, wpis będzie widoczny dla:
— wszystkich odwiedzających stronę,
— tylko dla Użytkowników zarejestrowanych.
Biblioteki
Biblioteki są bazami danych w których przechowywane są:
13) zdjęcia
14) filmy
15) pliki do pobrania
16) linki
Zdjęcia, filmy i pliki do pobrania (poniżej nazywane dokumenty) będą pobierane z zasobów na dyskach lokalnych Redaktorów/Administratorów. Rozwiązanie musi być przyjazne dla użytkownika i mechanizm ma być zbliżony do powszechnie stosowanych rozwiązań z tego obszaru. Wprowadzenie może odbywać się na zasadzie pojedynczych dokumentów lub pobierania masowego. Zdjęcia, filmy i pliki do pobrania porządkowane w katalogi w celu łatwiejszego zarządzania zawartością bibliotek. Każdy wprowadzony dokument musi mieć przypisane atrybuty:
autor, który nie musi być Redaktorem lub Administratorem
data zapisu w bibliotece
słowa kluczowe
Przy pobieraniu masowym dokumentów do bibliotek, atrybuty do poszczególnych dokumentów przypisywane są globalnie dla wszystkich dokumentów wprowadzanych w ramach jednej sesji.
Biblioteka linków tworzona jest przez Administratora lub Redaktora. W celu łatwiejszego zarządzania biblioteką linków Administrator/Redaktor wprowadzając link do komponentu nadaje mu się niepowtarzalną nazwę, która później będzie wyświetlana jako domyślny tekst na stronie, ale możliwy do zmiany.
Galerie zdjęć
Pliki zamieszczane w bibliotece mogą mieć rozszerzenia typowe dla plików graficznych a ograniczenia wielkości oraz rozdzielczości będą ustalane przez Wykonawcę na etapie projektowania Serwisu. Komponent musi mieć funkcjonalność pozwalającą na zamieszczanie zdjęć w formie galerii zdjęć, w ramach wprowadzanych treści, jak również jako osobne elementy na stronie. Galerie zamieszczane jako osobne elementy muszą być opatrzone tytułem oraz przed publikacją muszą być opisane przez Redaktora atrybutami:
— autor galerii
— tytuł galerii
— data utworzenia
— zakres czasowy w jakim galeria ma być widoczny lub bezterminowo
— słowa kluczowe
Galeria zdjęć przed zamieszczeniem musi mieć określoną dostępność:
10) dla wszystkich czytelników strony,
11) tylko dla Użytkowników zarejestrowanych.
Prezentacja filmów
Pliki zamieszczane w bibliotece mogą mieć rozszerzenia typowe dla plików filmowych, ograniczenia wielkości oraz rozdzielczości będą ustalane przez Wykonawcę na etapie projektowania Serwisu. Komponent musi mieć funkcjonalność pozwalająca na zamieszczanie filmu jako osobnego elementu strony lub w ramach wprowadzanych treści. Film jako osobny element musi być opatrzony tytułem oraz przed publikacją musi być opisany przez Redaktora atrybutami:
— autor filmu
— tytuł tytuł
— data utworzenia
— zakres czasowy w jakim film ma być widoczny lub bezterminowo
— słowa kluczowe
Film przed zamieszczeniem musi mieć określoną dostępność:
1. dla wszystkich czytelników strony,
2. tylko dla Użytkowników zarejestrowanych.
Pliki do pobrania
Pliki zamieszczane w bibliotece mogą w być zapisane jako PDF lub z rozszerzeniami typowymi dla plików tekstowych, arkuszy kalkulacyjnych a ich ograniczenia wielkości ustalane przez Wykonawcę na etapie projektowania Serwisu. Pliki do pobrania zawsze muszą być powiązane z treściami zamieszczonymi na stronie i prezentować się jako link do dokumentu. Przy linku musi być ikona informująca czytelnika o rozszerzeniu pliku.
Plik do pobrania przed zamieszczeniem musi mieć określoną dostępność:
— dla wszystkich czytelników strony,
— tylko dla Użytkowników zarejestrowanych.
Moduł Newsletter
Moduł Newsletter rozumiany jest jako komponent Serwisu umożliwiający:
zbieranie i magazynowanie adresów mailowych odbiorców newslettera,
tworzenie, zarządzanie treścią i archiwizowanie newsletterów,
masową wysyłkę e-mailigów.
Moduł może być kopiowany na dowolną stronę w ramach Serwisu PWI, za każdym razem tworzona jest osobna baza danych odbiorców i archiwum newsletterów.
Zapisy na newsletter i zarządzanie adresami e-mail
Na dowolnej stronie w ramach Serwisu PWI widoczny będzie pole umożliwiające wpisanie adresu mailowego, na który później będzie kierowany newsletter. Moduł w zależności od ustawień będzie publiczny tzn. widoczny dla Użytkowników niezarejestrowanych i Użytkowników zarejestrowanych lub ograniczony, tzn. tylko dla Użytkowników Zarejestrowanych. Moduł musi mieć funkcjonalność uniemożliwiającą dublowanie się adresów mailowych, tzn. nie będzie możliwości wielokrotnego wpisania tego samego adresu. Przy próbie wpisania adresu już istniejącego w bazie. W każdym szablonie musi być zawarta informacja o możliwości usunięcia adres e-mail z bazy danych oraz link, po kliknięciu którego adres mailowy będzie automatycznie usuwany z bazy danych.
Tworzenie newslettera
W ramach modułu dostępnych będzie 3-4 szablonów newsletterów dla każdej strony, na jakiej zamieszczony zostanie moduł. Szata graficzna newslettera musi być zgodna z linią graficzną strony, na której jest umieszczony moduł. Redaktor newslettera każdorazowo będzie wybierał szablon tworzonego newslettera. W celu ułatwienia redagowania treści moduł wyposażony będzie w WYSIWYG. W treści będzie możliwość umieszczania tekstów, plików graficznych i hiperłączy. Tworzony newsletter będzie można zapisać jako wersję roboczą i powrócić do jego edycji oraz zapisać do późniejszej wysyłki.
Wysyłka newslettera
Moduł wyposażony będzie w mechanizmy do masowej wysyłki z wykorzystaniem bazy danych adresów mailowych odbiorców. Przy generowaniu wysyłki masowej będzie możliwość wysyłki z opóźnieniem, tzn. wskazaniem dnia i godziny uruchomienia. Po zakończeniu wysyłki Administrator/Redaktor będzie otrzymywał raport z uwzględnieniem:
b. całkowitej liczby adresów mailowych na które został wysłanym e-mailing
c. liczby adresów mailowych na które wysyłka zakończyła się błędem wraz z listą tych adresów.
Archiwizacja
Wysłane newslettery będą archiwizowane w systemie wraz z informacją o terminie wysyłki, całkowitej liczbie adresów mailowych na które zostały skierowane oraz liczbie skutecznych doręczeń.
Raporty
Moduł wyposażony będzie w mechanizm raportowania umożliwiający prezentacje w formie tabelarycznej i eksport danych do powszechnie używanych arkuszy kalkulacyjnych oraz w formie graficznej i eksport do pliku PDF. Dane do raportu będzie można ograniczyć przedziałami czasowymi.
Moduł Profil
Moduł może być kopiowany na dowolną stronę w ramach Serwisu PWI, za każdym razem tworzona jest osobna baza danych.
Administrator instalując i konfigurując moduł ma możliwość włączenia wszystkich komponentów albo tylko wybrane funkcjonalności, np. bez czatów audio lub wideokonferencji.
Dodawania nowego profilu
Profil jest tworzony z inicjatywy Użytkownika niezarejestrowanego. Rejestracja następuję po wypełnieniu formularza. Pola podzielone są na pola wymagane i dodatkowe. Liczba i treść pól jest ustalana przez Administratora w momencie instalacji i konfigurowania modułu na stronie.
Po wypełnieniu przez Użytkownika profilu i zaakceptowaniu regulaminu, dane przesyłane są do Administratora, który akceptuje lub odrzuca profil. Administrator jest informowany mailem o nowej rejestracji. Jeśli Administrator zaakceptuje profil, do Użytkownika przesyłany jest mail, na adres podany w formularzu rejestracyjnym, z informacją o akceptacji i linkiem aktywującym profil. Jeśli Administrator odrzuci rejestrację podpisu, Użytkownik jest informowany o odrzuceniu.
Moduł ma mechanizmy ograniczające możliwość zarejestrowania więcej niż jednego użytkownika z wykorzystaniem tego samego adresu mailowego.
Logowanie do profilu
Każdy Użytkownik zarejestrowany ma niepowtarzalny login i hasło, a system gwarantuje mechanizmy bezpieczeństwa chroniące dane zawarte w profilu przed niepożądaną zmianą. Moduł wyposażony jest w mechanizmy umożliwiające zmianę hasła oraz przypomnienie hasła.
Zarządzanie profilem
Każdy Użytkownik zarejestrowany ma możliwość edycji i zmiany swoich danych oraz usunięcia profilu. Administrator w razie naruszenia przez Użytkownika zarejestrowanego przepisów prawa RP, zasad dobrych obyczajów lub złamania regulaminu może skorzystać z jednej z form represji:
1) Ostrzec Użytkownika wysyłając maila
2) Ograniczyć dostęp do wybranych funkcjonalności
3) Zablokować dostęp
4) Usunąć profil
Taksonomia profili
Każdy Użytkownik zarejestrowany jest zobowiązany do określenia słów kluczowych wybieranych ze słownika. Słownik będzie opracowany na etapie projektowania Serwisu PWI. Użytkownicy mogą również zgłosić swoje propozycje słów kluczowych do Administratora.
Aktywności
Każdy Użytkownik zarejestrowany będzie mógł przeglądać aktywność tzn.:
1) Linki do swoich wpisów na forach i w grupach dyskusyjnych
2) Informacje o odpowiedziach do wypowiedzi Użytkownika
3) Informacje o pozytywnych (plusy) i negatywnych (minusy) opiniach wypowiedzi Użytkownika Zarejestrowanego
4) Informacje kto wyświetlał profil Użytkownika Zarejestrowanego
5) Listę Użytkowników zarejestrowanych, których Użytkownik Zarejestrowany (właściciel profilu) zaprosił do kontaktu, a nie zostały te zaproszenia jeszcze rozpatrzone przez zapraszanych
Wgląd do tych informacji będzie miał również Administrator.
Wyszukiwanie kontaktów
Użytkownik zarejestrowany może przeglądać profile innych Użytkowników Zarejestrowanych po imieniu i nazwisku, słowach kluczowych, innych polach, które będą określane w trakcie projektowania serwisu.
Zaproszenia do kontaktu
Użytkownik Zarejestrowany może zapraszać do swoich kontaktów innych Użytkowników Zarejestrowanych, poprzez kliknięcie w profilu zapraszanego Użytkownika Zarejestrowanego ikony „zaproś do kontaktu”. Zapraszany Użytkownik Zarejestrowany otrzyma na skrzynkę e-mail w Serwisie PWI informację o zaproszeniu do kontaktu. Zaproszenie można zaakceptować i wtedy profil automatycznie umieszczany jest na Liście kontaktów obu Użytkowników zarejestrowanych, a wysyłający otrzymuje na e-mail w Serwisie PWI informacje o akceptacji. Zaproszenie może zostać odrzucone i wtedy zapraszający otrzymuje informacje na swój e-mail informację o odrzuceniu zaproszenia.
Lista kontaktów
Lista kontaktów zawiera linki do profili Użytkowników Zarejestrowanych, którzy przyjęli zaproszenia do kontaktu Użytkownika Zarejestrowanego (właściciela profilu) lub zaproszenia zostały zaakceptowane przez Użytkownika Zarejestrowanego (właściciela profilu).
Lista obserwowanych kontaktów
Użytkownik Zarejestrowany może obserwować aktywność Użytkowników z listy kontaktów. Użytkownik Zarejestrowany będzie widział wpisy na forach lub/i grupach dyskusyjnych, zmiany w profilach, wpisy na blogu.
Skrzynka e-mail
Użytkownicy Zarejestrowani będą mogli komunikować się za pomoc wiadomości e-mail. Wiadomości mogą być odbierane tylko od Użytkowników Zarejestrowanych, którzy są na liście kontaktów adresata. Wiadomości mogą być wysyłane przez Użytkownika zarejestrowanego do Użytkowników zarejestrowanych z listy kontaktów nadawcy. Użytkownik zarejestrowany może wysyłać jedną wiadomość do wielu Użytkowników jednocześnie.
Chat Audio
Użytkownicy zarejestrowani mogą komunikować się za pomocą chatu audio w czasie rzeczywistym. Komunikacja może być tylko pomiędzy Użytkownikami, którzy wcześniej wyrazili zgodę na kontakt (zaakceptowane zaproszenie do Listy kontaktów). Komunikacja musi wymagać zgody obu Użytkowników zarejestrowanych.
Wideokonferencje
Użytkownicy Zarejestrowani mogą komunikować się za pomocą wideokonferencji w czasie rzeczywistym. W wideokonferencji może uczestniczyć wielu Użytkowników zarejestrowanych. Komunikacja może być tylko pomiędzy Użytkownikami, którzy wcześniej wyrazili zgodę na kontakt (zaakceptowane zaproszenie do Listy kontaktów). Komunikacja musi wymagać zgody wszystkich Użytkowników Zarejestrowanych.
Blogi
Użytkownik zarejestrowany występuje do Administratora o zarejestrowanie bloga. Występując o zgodę Użytkownik zarejestrowany musi wypełnić formularz w którym określi profil planowanego bloga, określi słowa kluczowe. Redagowana treść może być uzupełniana o pliki graficzne, video, pliki do pobrania, linki do innych stron. W celu zapewnienia łatwości edycji treści musi być zastosowany WYSIWYG. Nowy wpis może być edytowany i zapisany do późniejszej publikacji. Po opublikowaniu wpisu na stronie musi być widoczna data publikacji.
Poniżej każdego wpisu na blogu musi być dostępne forum dla Użytkowników zarejestrowanych. Nad zachowaniem zasad dobrych obyczajów, regulaminu Serwisu PWI oraz przepisów prawa czuwa autor bloga oraz Moderator i mają możliwość usuwania wpisów łamiących ww. zasady. W miejscu usuniętego wpisu wyświetlany jest komunikat o przyczynie usunięcia wpisu, a do Użytkownika zarejestrowanego dokonującego usuwanego wpisu wysyłana jest wiadomość e-mail na skrzynkę w Serwisie PWI.
Moduł Badania
Moduł może być kopiowany na dowolną stronę w ramach Serwisu PWI, za każdym razem tworzona jest osobna baza danych.
Wyświetlanie modułu na stronie
Na stronie wyświetlać będzie się moduł z pytaniami (sondy/ankiety/głosowania). Odpowiedzi udzielać mogą tylko Użytkownicy zarejestrowani. Po udzieleniu odpowiedzi wyświetlać będą się statystki udzielonych odpowiedzi w formie wykresu.
Zarządzanie badaniami
Do zarządzania modułem uprawnienia będą mieli tylko:
1) Administrator
2) Redaktor
Uprawnieni użytkownicy będą mieli możliwość umieszczania modułu na stronie oraz tworzenia pytań i odpowiedzi. Odpowiedzi mogą mieć formę checkboxów (pola do zaznaczenia), listy jednokrotnego wyboru, list wielokrotnego wyboru. Po uruchomieniu modułu na stronie nie będzie możliwości zmiany treści pytania i odpowiedzi. Przy umieszczaniu modułu na stronie będzie można określić przedział czasowy w jakim moduł będzie widoczny lub liczby odpowiedzi wymagane,j po której moduł będzie zamykany.
Zarządzanie wynikami
Do zarządzania wynikami uprawnieni są tylko:
1) Administrator,
2) Redaktor.
Wyniki badania będą przechowywane w bazie danych. Wyniki będzie można eksportować do pliku xlsm, xls oraz innych aplikacji open source. Po zakończeniu badań wyniki badań będą publikowane w formie artykułu. Publikacja wyników ostatecznych badania będzie działaniem wymuszanym ręcznie przez uprawnionych użytkowników.
Moduł Projekty
Moduł Projekty może być kopiowany na dowolną stronę w ramach Serwisu PWI i za każdym razem tworzone są właściwe moduły bazy danych. Jego celem jest prezentacja projektów realizowanych w województwie opolskim.
Prezentacja projektu
Opis projektu zawiera elementy:
1) Nazwę projektu
2) Skrócony opis projektu
3) Branże
4) Słowa kluczowe wybierane ze słownika
5) Prezentacja osoby lub osób lub/i firmy realizującej projekt
6) Pliki graficzne, video, dokumenty
7) Mapę Google
8) Forum dyskusyjne dedykowane projektowi
Prawa dostępu
Użytkownik zarejestrowany ma uprawnienia do:
1) Zamieszczania informacji o swoich projektach
2) Przeglądania pełnej informacji o wszystkich projektach
3) Uczestniczyć w formach dyskusyjnych dot. projektu
Użytkownik niezarejestrowany może tylko przeglądać podstawowe informacje o projekcie:
1) Nazwę projektu
9) Skrócony opis projektu
10) Branże
11) Słowa kluczowe wybierane ze słownika
12) Prezentacja osoby lub osób lub/i firmy realizującej projekt
Użytkownicy mogą wyszukiwać, filtrować i sortować projekty np. wg branży, słów kluczowych.
Moduł Ogłoszenia
Moduł Ogłoszenia może być kopiowany na dowolną stronę w ramach Serwisu PWI i za każdym razem tworzone są właściwe moduły bazy danych.
Zamieszczenie ogłoszenia
Ogłoszenie może być zamieszczone przez Użytkowników niezarejestrowanych lub/i Użytkowników zarejestrowanych w zależności od ustawień wybranych przez Administratora podczas instalacji i konfiguracji modułu.
Użytkownik wypełnia formularz na stronie internetowej, poza treścią ogłoszenia wybiera parametry, które będą umożliwiać wyszukiwanie ogłoszeń, typu branża/słowa kluczowe/lokalizacja/rodzaj oferty oraz dane kontaktowe i termin ważności ogłoszenia. Dane kontaktowe ogłoszeniodawcy będą tylko do wiadomości właściciela strony i nie będą widoczne na stronie, chyba, że ogłoszeniodawca umieści je w treści ogłoszenia. Parametry ogłoszenia będą ustalane przez Administratora podczas instalacji i konfiguracji modułu.
Treść ogłoszenia może być uzupełniona przez pliki graficzne, pliki video i inne dokumenty.
Po wypełnieniu wymaganych pól formularz będzie przesyłany do Administratora, która opublikuje ogłoszenie. Użytkownik będzie informowany o opublikowaniu ogłoszenia.
Publikacja
Ogłoszenie będzie widoczne we wskazanym przedziale czasowym. Osoba zainteresowana ogłoszeniem może na nie odpowiedzieć z wykorzystaniem formularza kontaktowego umieszczonego bezpośrednio przy ogłoszeniu. Formularz kontaktowy musi zawierać pola:
1) imię i nazwisko, ew. firma
2) adres e-mail
3) pole tekstowe do wpisania wiadomości.
Odpowiedź na ogłoszenie będzie kierowana bezpośrednio na adres e-mail ogłoszeniodawcy oraz kopia do wiadomości nadawcy.
Ogłoszenia wyświetlane są w formie skróconej i domyślnie uszeregowane zgodnie z datą publikacji. Użytkownik przeglądający ogłoszenia może filtrować ogłoszenia/sortować/wyszukiwać ogłoszenia zgodnie z przyjętymi parametrami.
Pełna treść ogłoszenia wyświetlana jest na osobnej stronie po kliknięciu Użytkownika na wersję skróconą.
Moduł Wizytówki
Moduł Wizytówki może być kopiowany na dowolną stronę w ramach Serwisu PWI i za każdym razem tworzone są właściwe moduły bazy danych. Wizytówki mają być bazą danych firm, organizacji lub instytucji i zawierać dane teleadresowe interesujące czytelników strony.
Wyświetlanie wpisów
Przewidziane są Wizytówki w wersji podstawowej, widoczny dla wszystkich odwiedzających stronę tzn.:
1) nazwa firmy/organizacji/instytucji
2) adres
3) strona www
4) logo/znak graficzny
oraz w wersji rozszerzonej, tylko dla Użytkowników zarejestrowanych, tzn.:
1) dane jak powyżej
2) telefon kontaktowy
3) adres e-mail
4) profile Użytkowników zarejestrowanych powiązanych z wizytówką
Odwiedzający strony musi mieć możliwość wyszukania wizytówek interesujących go firm/organizacji/instytucji po parametrach:
1) branża
2) miejscowość
3) słowa kluczowe
Wyświetlane wizytówki muszą mieć link do mapy Google, gdzie będzie wskazana lokalizacja firmy/organizacji/instytucji.
Zarządzanie wpisami
Powiązanie profilu Użytkownika zarejestrowanego z Wizytówką jest możliwe tylko z inicjatywy Użytkownika i po akceptacji przez Administratora.
Dane zamieszczane w Module Wizytówki będą wprowadzane do systemu przez Administratora lub Redaktora. Informacje o firmach/organizacjach/instytucjach mogę być przesyłane tylko przez Użytkowników zarejestrowanych za pośrednictwem formularza zamieszczonego na stronie.
Moduł Lista zakupowa
Moduł Lista zakupowa może być kopiowany na dowolną stronę w ramach Serwisu PWI i za każdym razem tworzone są właściwe moduły bazy danych. Przeznaczeniem moduły jest umożliwienie dokonywania zakupów grupowych przez Użytkowników zarejestrowanych.
Tworzenie listy
Lista tworzona jest przez Administratora lub na prośbę Użytkownika zarejestrowanego, tzn. Użytkownik wypełnia formularz a wybór pól do formularza będzie ustalany na etapie projektowania modułu. Każda lista zakupowa musi mieć krótki opis i być określona parametrami:
1) nazwa,
2) branża,
3) słowa kluczowe,
4) termin zbierania zainteresowanych zakupem grupowym
Lista zakupowa musi mieć Moderatora. Moderatorem może być Użytkownik zarejestrowany, którego zadaniem będzie udzielanie odpowiedzi i koordynowanie negocjacji oraz realizacji zamówienia, ale tylko w ramach grupy zakupowej.
Dodawanie wpisów
Użytkownik zarejestrowanych może wyszukiwać listy zakupowe na podstawie zadanych kryteriów wyszukiwania.
Użytkownik zarejestrowany zainteresowany dokonaniem zakupu z wybranej listy, deklaruje chęć przystąpienia oraz wpisuje szczegóły swojego zapotrzebowania.
Zamykanie listy
Po zakończeniu terminu zbierania zapotrzebowania lista jest zamykana i zamieszczana jest informacja o kontrahencie realizującym listę zakupów.
Jeśli w określonym terminie nie zostanie zebrana wystarczająca liczba Użytkowników zarejestrowanych to Administrator lub Moderator może przedłużyć termin wyświetlania.
Dodatkowe funkcjonalności modułu
W ramach modułu Lista zakupowa działać będą wizytówki firm, a Użytkownicy zarejestrowani będą mogli dokonywać oceny kontrahentów.
Inne dodatkowe informacje
Informacje do poprawienia lub dodania w odpowiedniej dokumentacji przetargowej.
Więcej informacji w odpowiedniej dokumentacji przetargowej.
Do załącznika nr 1A do SIWZ dodano tym samym zał. nr 3 o takiej samej treści jak w niniejszej zmianie ogłoszenia.
TI | Tytuł | Polska-Opole: Usługi w zakresie projektowania stron WWW |
---|---|---|
ND | Nr dokumentu | 88418-2014 |
PD | Data publikacji | 15/03/2014 |
OJ | Dz.U. S | 53 |
TW | Miejscowość | OPOLE |
AU | Nazwa instytucji | Opolskie Centrum Rozwoju Gospodarki |
OL | Język oryginału | PL |
HD | Nagłówek | Państwa członkowskie - Zamówienie publiczne na usługi - Dodatkowe informacje - Procedura otwarta |
CY | Kraj | PL |
AA | Rodzaj instytucji | R - Agencja/Biuro regionalne lub lokalne |
DS | Dokument wysłany | 11/03/2014 |
DT | Termin | 10/04/2014 |
NC | Zamówienie | 4 - Zamówienie publiczne na usługi |
PR | Procedura | 1 - Procedura otwarta |
TD | Dokument | 2 - Dodatkowe informacje |
RP | Legislacja | 5 - Unia Europejska, z udziałem krajów GPA |
TY | Rodzaj oferty | 1 - Oferta całościowa |
AC | Kryteria udzielenia zamówienia | 1 - Najniższa cena |
PC | Kod CPV | 72413000 - Usługi w zakresie projektowania stron WWW |
OC | Pierwotny kod CPV | 72413000 - Usługi w zakresie projektowania stron WWW |
RC | Kod NUTS | PL522 |
Polska-Opole: Usługi w zakresie projektowania stron WWW
2014/S 053-088418
Opolskie Centrum Rozwoju Gospodarki, ul. Spychalskiego 1A, Dział Organizacyjno-Administracyjny, Osoba do kontaktów: Barbara Rokosz, Opole45-716, POLSKA. Tel.: +48 774033631. Faks: +48 774033609. E-mail: b.rokosz@ocrg.opolskie.pl
(Suplement do Dziennika Urzędowego Unii Europejskiej, 1.3.2014, 2014/S 43-071937)
CPV:72413000
Usługi w zakresie projektowania stron WWW
Zamiast:
VI.3) Informacje dodatkowe:
[...]
Powinno być:VI.3) Informacje dodatkowe:
[...]
Informacja w ogłoszeniu 2014/S 049-081604 o zmianie ogłoszenia zawiera informacje uzupełniające do ogłoszenia pierwotnego i tym samym nie zastępuje się danych zwartych w ogłoszeniu pierwotnym lecz uzupełnia o informacje dodatkowe w zakresie treści załącznika 3 do załącznika 1A do SIWZ (Szczegółowy opis przedmiotu zamówienia) tak jak podano w formularzu ogłoszenia przekazanego do publikacji DUUE z dnia 6.3.2014 (dd/mm/rrrr) – ID:2014-030912
VI.3.6) Tekst, który należy dodać do pierwotnego ogłoszenia
Miejsce, w którym należy dodać tekst:
II.2.1) Całkowita wielkość lub zakres:
W związku z powyższym pełen opis przedmiotu zamówienia zawiera ogłoszenie pierwotne oraz zmiana ogłoszenia w zakresie informacji dodatkowych do ogłoszenia pierwotnego. Sformułowanie zawarte w opublikowanej zmianie ogłoszenia "zamiast" nie jest prawdziwe.
TI | Tytuł | Polska-Opole: Usługi w zakresie projektowania stron WWW |
---|---|---|
ND | Nr dokumentu | 194971-2014 |
PD | Data publikacji | 11/06/2014 |
OJ | Dz.U. S | 110 |
TW | Miejscowość | OPOLE |
AU | Nazwa instytucji | Opolskie Centrum Rozwoju Gospodarki |
OL | Język oryginału | PL |
HD | Nagłówek | - - Usługi - Ogłoszenie o udzieleniu zamówienia - Procedura otwarta |
CY | Kraj | PL |
AA | Rodzaj instytucji | R - Agencja/Biuro regionalne lub lokalne |
HA | EU Institution | - |
DS | Dokument wysłany | 06/06/2014 |
NC | Zamówienie | 4 - Usługi |
PR | Procedura | 1 - Procedura otwarta |
TD | Dokument | 7 - Ogłoszenie o udzieleniu zamówienia |
RP | Legislacja | 5 - Unia Europejska, z udziałem krajów GPA |
TY | Rodzaj oferty | 9 - Nie dotyczy |
AC | Kryteria udzielenia zamówienia | 1 - Najniższa cena |
PC | Kod CPV | 72413000 - Usługi w zakresie projektowania stron WWW |
OC | Pierwotny kod CPV | 72413000 - Usługi w zakresie projektowania stron WWW |
RC | Kod NUTS | PL522 |
IA | Adres internetowy (URL) | http://ocrg.opolskie.pl/ |
DI | Podstawa prawna | Dyrektywa klasyczna (2004/18/WE) |
Polska-Opole: Usługi w zakresie projektowania stron WWW
2014/S 110-194971
Ogłoszenie o udzieleniu zamówienia
Usługi
Sekcja I: Instytucja zamawiająca
Opolskie Centrum Rozwoju Gospodarki
ul. Spychalskiego 1A
Punkt kontaktowy: Dział Organizacyjno-Administracyjny
Osoba do kontaktów: Barbara Rokosz
45-716 Opole
Polska
Tel.: +48 774033631
E-mail: b.rokosz@ocrg.opolskie.pl
Faks: +48 774033609
Adresy internetowe:
Ogólny adres instytucji zamawiającej: http://ocrg.opolskie.pl/
Sekcja II: Przedmiot zamówienia
Kategoria usług: nr 7: Usługi komputerowe i usługi z nimi związane
Główne miejsce lub lokalizacja robót budowlanych, miejsce realizacji dostawy lub świadczenia usług: Opole.
Kod NUTS PL522
Przedmiot zamówienia składa się następujących elementów - części:
3.1.1 Wykonanie strony internetowej PWI,
3.1.2 Szkolenia z zakresu obsługi PWI,
3.1.3 Obsługa deweloperska (rozwojowa).
Powyższe elementy nie stanowią odrębnych części zamówienia.
72413000
Łącznie z VAT. Stawka VAT (%) 23
Sekcja IV: Procedura
Ogłoszenie o zamówieniu
Numer ogłoszenia w Dz.U.: 2014/S 43-071937 z dnia 1.3.2014
Inne wcześniejsze publikacje
Numer ogłoszenia w Dz.U.: 2014/S 49-081604 z dnia 11.3.2014
Sekcja V: Udzielenie zamówienia
Nfinity.pl Sp. z o.o.
ul. Wandy 7/4
53-320 Wrocław
Wartość: 153 746,67 PLN
Bez VAT
Całkowita końcowa wartość zamówienia:
Wartość: 158 424 PLN
Łącznie z VAT. Stawka VAT (%) 23
Sekcja VI: Informacje uzupełniające
Podać odniesienie do projektu (projektów) i/lub programu (programów): "Inwestujemy w Twoją przyszłość”
Projekt współfinansowany przez Unię Europejską ze środków Europejskiego Funduszu Rozwoju Regionalnego
w ramach Regionalnego Programu Operacyjnego Województwa Opolskiego na lata 2007-2013
Oś priorytetowa 1 Wzmocnienie atrakcyjności gospodarczej regionu
Działanie 1.3 Innowacje, badania, rozwój technologiczny
Poddziałanie 1.3.1. Wsparcie sektora B+R oraz innowacji na rzecz przedsiębiorstw
„Opolska Platforma Innowacji”
nr decyzji: RPOP.01.03.01-16-016/12-00 z dnia 10.12.2012 r.
Urząd Zamówień Publicznych
ul. Postępu 17a
02-676 Warszawa
Polska
E-mail: odwolania@uzp.gov.pl
Tel.: +48 224587801
Adres internetowy: http://www.uzp.gov.pl/
Faks: +48 224587700
1) w terminie 10 dni od dnia przesłania informacji o czynności zamawiającego stanowiącej podstawą jego wniesienia – jeżeli zostały przesłane w sposób określony w art. 27 ust. 2, albo w terminie 15 dni – jeżeli zostały przesłane w inny sposób – w przypadku, gdy wartość zamówienia jest równa lub przekracza kwoty określone w przepisach wydanych na podstawie art. 11 ust. 8;
2. Odwołanie wobec treści ogłoszenia o zamówieniu, a jeżeli postępowanie jest prowadzone w trybie przetargu nieograniczonego, także wobec postanowień specyfikacji istotnych warunków zamówienia, wnosi się w terminie:
1) 10 dni od dnia publikacji ogłoszenia w Dzienniku Urzędowym Unii Europejskiej lub zamieszczenia specyfikacji istotnych warunków zamówienia na stronie internetowej – jeżeli wartość zamówienia jest równa lub przekracza kwoty określone w przepisach wydanych na podstawie art. 11 ust. 8.
3. Odwołanie wobec czynności innych niż określone w ust. 1 i 2 wnosi się:
1) w przypadku zamówień, których wartość jest równa lub przekracza kwoty określone w przepisach wydanych na podstawie art. 11 ust. 8 – w terminie 10 dni od dnia, w którym powzięto lub przy zachowaniu należytej staranności można było powziąć wiadomość o okolicznościach stanowiących podstawę jego wniesienia"
Urząd Zamówień Publicznych
ul. Postępu 17a
02-676 Warszawa
Polska
E-mail: odwolania@uzp.gov.pl
Tel.: +48 224587801
Adres internetowy: http://www.uzp.gov.pl/
Faks: +48 224587700