Zapytaniem dot. systemu informatycznego

Transkrypt

Zapytanie ofertowe dot.
utworzenia portalu
internetowego
Fundacja Rozwoju Podhala
Spis treści
Spis tabel .......................................................................................... 2
Spis rysunków .................................................................................. 2
1. Wstęp ........................................................................................... 3
1.1. Informacje wstępne ......................................................................... 3
1.2. Cel oraz założenia projektu .............................................................. 6
2. Słownik pojęć ............................................................................... 6
3. Wymagania bezwzględne dla systemu ...................................... 11
3.1. Wymagania ogólne ........................................................................ 11
3.2. Wymagania merytoryczne .............................................................. 12
4. Wymagania funkcjonalne .......................................................... 25
4.1. Opis metodyki ............................................................................... 25
4.2. Tabela wymagań funkcjonalnych .................................................... 26
5. Architektura ............................................................................... 41
5.1. Architektura aplikacji ..................................................................... 41
5.1.1. Warstwa sieciowa ................................................................ 42
5.1.2. Warstwa aplikacyjna ............................................................ 42
5.1.3. Warstwa danych .................................................................. 42
5.2. Architektura danych....................................................................... 42
5.3. Architektura aplikacji ..................................................................... 42
5.4. Integracja z systemami zewnętrznymi ............................................ 44
5.5. Integracja z systemami portalowymi. .............................................. 44
5.5.1. Śledzenie aktywności użytkowników ..................................... 44
5.5.2. Zapis do newslettera............................................................ 45
5.6. Architektura sprzętowa oraz systemowa. ........................................ 45
5.6.1. Środowisko ......................................................................... 45
5.6.2. Licencjonowanie .................................................................. 46
5.6.3. Urządzenia peryferyjne ........................................................ 46
5.6.4. Gwarancja sprzętu ............................................................... 46
5.7. Wymagania dotyczące administracji systemem ................................ 47
5.8. Bezpieczeństwo systemu. ............................................................... 48
6. Wygląd interfejsu użytkownika ................................................. 53
6.1. Użyteczność (Usability) .................................................................. 53
7. Utrzymanie systemu .................................................................. 56
7.1. Zakres i metoda świadczenia usługi asysty technicznej .................... 56
7.2. Gwarancja oprogramowania ........................................................... 57
8. Szkolenia .................................................................................... 59
Fundusze Europejskie dla Małopolski
„Projekt współfinansowany przez Unię Europejską w ramach Małopolskiego Regionalnego Programu
Operacyjnego na lata 2007-2013”
Spis tabel
Tabela
Tabela
Tabela
Tabela
Tabela
Tabela
Tabela
Tabela
Tabela
Tabela
1. Słownik pojęć. ...............................................................................................................11
2 Przykład wypełnienia tabeli PASS przez Wykonawcę .........................................................25
3 Tabela wymagań funkcjonalnych. ....................................................................................40
4 Architektura Aplikacji ......................................................................................................44
5 Wymagania do administracji systemem. ...........................................................................48
6 Wymagania bezpieczeństwa systemu. ..............................................................................53
7 Wymagania ergonomii interfejsu użytkownika. .................................................................56
8 Utrzymanie systemu. ......................................................................................................59
9 Kategoria i klasyfikacja błędów ........................................................................................69
10 Niezbędna dokumentacja. .............................................................................................73
Spis rysunków
Rysunek 1. Diagram hierarchii funkcji ............................................................................................15
1. Wstęp
1.1. Informacje wstępne
Zamówienie będzie realizowane w ramach projektu pn. "Wspieranie gospodarczego wykorzystania
odnawialnych źródeł energii w Małopolsce poprzez budowanie europejskiej sieci współpracy”
współfinansowanego przez Unię Europejską w ramach Małopolskiego Regionalnego Programu
Operacyjnego na lata 2007-2013 w ramach Osi Priorytetowej 8 „Współpraca Międzyregionalna”,
Działanie 8.2 „Budowanie pozycji Małopolski w europejskich sieciach współpracy.
Działania w ramach projektu stanowią element programu działań mających na celu wykorzystanie
nowoczesnych narzędzi celem zbudowania profesjonalnej współpracy międzynarodowej w dziedzinie
Odnawialnych Źródeł Energii wraz z narzędziami do badania użytkowników platformy oraz
umożliwiające wymianę wiedzy między partnerami. Platforma OZE ma umożliwić wymianę danych,
obliczeń, wyników testów, doświadczeń między wieloma podmiotami osobami (zapewniając
odpowiedni poziom poufności informacji dzięki zastosowanym mechanizmom autentykacji). Platforma
ma być bazą wiedzy, doświadczeń i kontaktów, które aktualnie w Polsce nie mają swojego
odpowiednika. Misją stworzenia w/w portalu jest nie tylko powstanie strony internetowej
udostępniającej określoną wiedzę i treści, ale również stworzenie platformy, która stworzy
automatyczny
system
współpracy
między
partnerami
projektu,
w
tym
także
instytucjami
międzynarodowymi.
Stworzony system będzie otwarty i posiadać będzie możliwość dalszego rozwoju merytorycznego jak i
możliwość podłączania kolejnych partnerów projektu.
Oprogramowanie powinno zostać skonfigurowane i wdrożone w środowisku docelowym.
Dodatkowo Zamawiający wymagać będzie przekazania:
- kodów źródłowych wytworzonego oprogramowania;
- specyfikacji środowiska sprzętowo-systemowego wymaganego do przeprowadzenia procedury
generacji kodu wynikowego;
- instrukcji generacji kodu wynikowego (reguły kompilacji);
- narzędzi do przygotowania wersji instalacyjnej;
- narzędzi do instalacji wytworzonego oprogramowania wraz z dokumentacją; instalacji;
- plików konfiguracyjnych oprogramowania narzędziowego, oprogramowania pośredniczącego,
oprogramowania systemowego w szczególności: systemu operacyjnego, systemu baz danych,
oprogramowania użytkowego.
Stworzenie platformy internetowej ma być rozwiązaniem otwartym, co ma zapewnić Fundacji pełną
swobodę w zakresie późniejszego rozwijania funkcjonalności platformy. Generalnym założeniem
przeprowadzonego postępowania ofertowego ma być uniknięcie uzależnienia zamawiającego od
jednego wykonawcy.
Wykonawca zobowiązany będzie udzielić niewyłącznej i bezterminowej licencji, bez ograniczeń
terytorialnych na wszelkie skrypty/programy powstałe w wyniku lub w związku z wykonywaniem
niniejszego systemu a w szczególności na system główny, na infrastrukturę informatyczną, jak również
na wszystkie elementy i pliki źródłowe, które zostaną wykorzystane do przygotowania skryptów/
programów powstałych w ramach realizacji postanowień zawartej w późniejszym czasie Umowy.
Udzielona licencja, o której mowa powyżej ma objąć wszelkie pola eksploatacji. Licencja powinna
zostać
udzielona
na
okres
7
lat.
Wyłoniona firma będzie się również zajmowała
administrowaniem strony, zarówno w czasie realizacji projektu jak i w okresie jego 5-letniej
trwałości.
Niniejszy dokument określa wymagania funkcjonalne oraz podstawowe wymagania techniczne
systemów nie określając technologii, w jakiej zostanie wykonany system ze względu na przeznaczenie
dokumentu, jakim jest jego wykorzystanie na etapie postępowania o udzielenie zamówienia.
Zakładane ramy czasowe wykonania systemu:
Termin rozpoczęcia prac – 1 sierpnia 2013 r.
Termin zakończenia prac – 31 października 2014 r.
Sposób porozumiewania się z Zamawiającym:
Upoważnionym do udzielania informacji w sprawie zapytania ofertowego jest Konrad Kosierkiewicz.
Adres do korespondencji w sprawie zamówienia: Fundacja Rozwoju Podhala, ul. Chałupnika 12e/8,
31-464 Kraków.
E-mail do korespondencji w sprawie zamówienia: [email protected]
Telefon do kontaktów w sprawie zamówienia: 661613850
Opis sposobu przygotowania oferty:
Oferta powinna zawierać co najmniej:
–
Datę sporządzenia
–
Nazwę i adres oferenta
–
Oświadczenie o posiadanym doświadczeniu i zdolności do realizacji zamówienia
–
Pieczęć firmową, imię i nazwisko oraz podpis osoby reprezentującej
–
Wartość netto i brutto oferty razem
–
Warunki płatności
–
Warunki gwarancji i serwisu
–
Datę ważności oferty (min. 14 dni)
Oferta powinna być złożona w języku polskim. Ceny w ofercie powinny być podane w kwotach netto,
w złotych polskich. W ofercie powinien być przedstawiony harmonogram płatności. Oferta musi
zawierać informację o spełnianiu przez wykonawcę kryterium doświadczenia. W ofercie powinna być
wskazana osoba do kontaktów w sprawie oferty i adres mailowy, na który będzie przesyłana
korespondencja.
Oferta powinna być wydrukowana, parafowana na każdej stronie i podpisana przez osobę lub osoby
upoważnione do reprezentacji firmy. W przypadku składania oferty drogą elektroniczną podpisana
oferta powinna być zeskanowana i przesłana drogą mailową w formacie PDF lub DOC.
Termin i sposób składania ofert:
Oferty należy składać do dnia 24.07.2013, do godziny 15.00.
Dopuszcza się składanie ofert drogą elektroniczną w formacie PDF lub DOC na adres mailowy
[email protected]
Wymagania stawiane wykonawcom:
Wykonawca winien posiadać doświadczenie w realizacji prac programistycznych w zakresie systemów
komputerowych i CRM. Kryterium to będzie oceniane na podstawie informacji podanych przez
wykonawcę w ofercie. Z uwagi na specyfikę tematyki systemu mile widziane jest doświadczenie
inżynierskie.
Kryteria wyboru oferty:
Każda oferta będzie oceniana poprzez punktację od 0 do 100 pkt., przy czym punkty będą
przydzielane wg następujących kryteriów:
1.
cena oferty – waga 90%
3.
warunki gwarancji i serwisu pogwarancyjnego – waga 10%
Zamówienie do realizacji otrzyma ten Wykonawca, który otrzyma w ogólnej ocenie największą ilość
punktów.
Zamawiający nie przewiduje trybu odwoławczego i zastrzega sobie prawo do unieważnienia
postępowania ofertowego bez podania przyczyny.
Termin powiadomienia o wyborze oferty:
Wykonawca zostanie powiadomiony drogą mailową o wyborze jego oferty, jako najkorzystniejszej
najpóźniej do 31.07.2013 roku.
1.2. Cel oraz założenia projektu
Celem projektu jest zaprojektowanie, wykonanie, wdrożenie i uruchomienie systemu
informatycznego, który zostanie wykorzystany dla budowania lojalności oraz pogłębiania relacji z
użytkownikiem, przy wykorzystaniu technik spersonalizowanej komunikacji. Dzięki wdrożonemu
systemowi zostanie zwiększona skuteczność zarządzania kampaniami marketingowymi prowadzonymi
na terenie kraju oraz za granicą. Wdrażany system będzie gromadził dane o użytkownikach do jednej
bazy danych, budując w ten sposób zaawansowaną bazę wiedzy o użytkownikach.
Funkcjonalnie wdrażany system będzie podzielony na dwa moduły funkcjonalne

CRM (Customer relationship management) – odpowiedzialny za budowanie relacji z
użytkownikami, przechowywanie danych i ich analizę.

CMS (Conetent Menagement system) – odpowiedzialny za wizualizację ogólno
dostępnej części aplikacji, dla niezalogowanych interesantów.
Wymaganiem głównym jest aby powyższe dwa moduły współpracowały z sobą w wymianie
danych.
System wykorzystując zgromadzone dane zaoferuje dostarczanie użytkownikom informacji,
których główną formą jest newsletter. Definiowanie odbiorców newslettera powinno odbywać się na
podstawie parametrów zawartych w dynamicznym profilu użytkownika lub na podstawie list
wybranych użytkowników. Dane gromadzone w bazie będą pobierane oraz dostarczane przez inne
systemy współpracujące z systemem CRM .
Wdrażany CRM musi być rozwiązaniem składającym się z infrastruktury sprzętowej i
oprogramowania. Ma być to narzędzie, dzięki któremu Fundacja będzie mógł zastosować model
indywidualnego podejścia do klienta i przekazywania mu dopasowanych informacji - zgodnych z jego
preferencjami. Użytkownikami systemu będą pracownicy fundacji, a także pracownicy podmiotów
współpracujących zarówno polskich jak i zagranicznych. Klientami systemu będą wszyscy internauci
wchodzący na stronę głównego portalu, odbiory newsletterów i materiałów promocyjnych.
CRM będzie wykorzystywany na wielu rynkach za granicą.
2. Słownik pojęć
Pojęcie
ACID 3
Opis
Test, stwierdzający, czy przeglądarki internetowe
spełnieniają standardy internetowe wyznaczane przez
Analiza Błędu
Auth 2.0
Awaria
Błąd
CMS
CRM
Czas Obejścia
Czas Reakcji #1
Czas Reakcji #2
Czas Rozwiązania
Czas Naprawy
Dane
DC
Double opt-in
Formaty plików
dla eksportu
danych
Formaty plików
dla importu
danych
organizację W3C.
Działania mające na celu wskazanie technicznej przyczyny
Błędu i załączenie logów bądź komunikatów
międzysystemowych.
Otwarty protokół autoryzacji
Niezgodne z wymaganiami zawartymi w Umowie działanie
całości bądź dowolnej części Systemu.
Zdarzenie polegające na niezgodnej z Dokumentacją pracy
Systemu; Problem informatyczny.
Content Menagement System
ang. Customer Relationship Management – to zestaw
procedur i narzędzi istotnych w zarządzaniu kontaktami z
klientami.
Czas liczony od chwili dokonania Zgłoszenia Błędu lub
Zgłoszenia Serwisowego przez Zamawiającego do
Wykonawcy do chwili dostarczenia Obejścia do
Zamawiającego przez Wykonawcę.
Czas pomiędzy dokonaniem zgłoszenia Błędu lub Zgłoszenia
Serwisowego, a momentem rozpoczęcia przez Wykonawcę
prac nad usuwaniem Błędu wraz z przekazaniem
Zamawiającemu informacji o planowanych działaniach lub
przekazaniem uzasadnionej informacji do Zamawiającego o
innym, niż produkt Wykonawcy, źródle błędu.
Czas pomiędzy dokonaniem Zgłoszenia Serwisowego, a
momentem rozpoczęcia przez Wykonawcę prac nad
usuwaniem Błędu, w szczególności polegające na zdalnym
połączeniu z Systemem lub rozmowie telefonicznej.
Czas liczony od chwili dokonania zgłoszenia Błędu lub
Zgłoszenia Serwisowego przez Zamawiającego do chwili
dostarczenia Rozwiązania do Zamawiającego przez
Wykonawcę.
Czas pomiędzy zakończeniem Czasu Reakcji, a wykonaniem
Naprawy i zgłoszeniem gotowości do odbioru Naprawy.
Wszelkie dane, w tym dane osobowe, zawarte
lub przetwarzane w istniejących systemach Zamawiającego
(niezależnie od rodzaju nośnika, na/w którym są zapisane,
przechowywane lub przetwarzane), związane z obsługą
i eksploatacją Systemu. Obejmują postaci: oryginalną, kopii
bezpieczeństwa i kopii archiwalnej.
ang.Dynamic Content– System Zarządzania Treścią;
system pozwalający na łatwe utworzenie serwisu WWW
oraz jego późniejszą aktualizację i rozbudowę przez
redakcyjny personel nieposiadający specjalistycznej wiedzy
technicznej.
Subskrypcja z potwierdzeniem. Użytkownik, który dokonał
subskrypcji elektronicznej musi otrzymać wiadomość na
podany w formularzu zapisu adres email zawierającą link
aktywujący. Dopóki, gdy subskrypent nie kliknie na link
aktywujący, jego konto jest nieaktywne.
Formaty plików, do których dane będą mogły być
wyeksportowane z bazy CRM: Excel 97-2003 (XLS), Excel
2007 (XLSX), Comma Separated Values (CSV), Portable
Document Format (PDF), Extensible Markup Language
(XML), Word 97-2003 (DOC), Word 2007 (DOCX). Przy
czym do eksportu raportów zastosowanie mają mieć
formaty DOC/DOCX oraz PDF, a do eksportu pozostałych
danych XLS/XLSX, CSV, XML.
Formaty plików Excel 97-2003 (XLS), Excel 2007 (XLSX),
Comma Separated Values (CSV), Extensible Markup
Language (XML), do których dane będą mogły być
GIODO
ITI’L
Kategoria
Klaster
niezawodnościowy
Komponent
Klient
zaimportowane do bazy CRM:
Generalny Inspektor Ochrony Danych Osobowych.
ang. Information Technology Infrastructure Library – zbiór
najlepszych praktyk, w jaki sposób efektywnie i skutecznie
oferować usługi informatyczne.
Istotność defektu z punktu widzenia funkcjonalności.
Przypisywana jest przez testera.
zespół komputerów dublujących nawzajem swoje funkcje
(łączenie równoległe). W razie awarii jednego z węzłów,
następuje automatyczne przejęcie jego funkcji przez inne
węzły.
niezależnie wytworzony, skompilowany (z ukrytymi
szczegółami implementacyjnymi) moduł programowy,
udostępniający swą funkcjonalność za pomocą
jednoznacznie zdefiniowanego interfejsu, zdolny do
współdziałania z większą całością (systemem) oraz innymi
komponentami
Pod pojeciem klienta rozumie się:
- użytkowników poszukujących informacji (relacja B2C),
- partnerów Fundacji i innych organizacji uczestniczących w
systemie (relacja B2B) ,
ang. Business-to-Business (B2B), to ogół relacji między
firmą a partnerami, pośrednikami, dostawcami,
dystrybutorami oraz punktami sprzedaży i świadczenia
usług. Klientem w relacjach B2B jest np. tour operator,
hotele itp.
Business-to-consumer (B2C), to nazwa relacji
występujących pomiędzy firmą a klientem końcowym,
często realizowanych za pomocą Internetu, choć nie tylko.
Stroną inicjującą transakcje jest firma. Klientem w relacji
B2C jest np. turysta.
LDAP
Lekki Protokół Usług Katalogowych (ang. Lightweight
Directory Access Protocol ) - protokół przeznaczony do
korzystania z usług katalogowych, bazujący na standardzie
X.500. Jest to również nazwa usługi katalogowej
pozwalającej na wymianę informacji za pośrednictwem
TCP/IP.
Load balancing
Równoważenie obciążenia czyli technika rozpraszania
obciążenia pomiędzy wiele procesorów, komputerów,
dysków, połączeń sieciowych lub innych zasobów.
Trwałe przywrócenie pełnej funkcjonalności Systemu oraz
usunięcie przyczyn wystąpienia Awarii, umożliwiające
korzystanie z Systemu bez utrudnień.
Zaakceptowane przez Zamawiającego dostarczenie przez
Wykonawcę tych elementów Rozwiązania, których
implementacja umożliwia zachowanie funkcjonalności
Systemu (w szczególności dostępności, stabilności i
wydajności realizacji dowolnej funkcjonalności wspieranej
przez System) i jakości Danych, pomimo obecności Błędu.
Wraz z dostarczeniem Obejścia Wykonawca dostarcza
instrukcję jego stosowania. Każde Obejście musi docelowo
zakończyć się trwałym usunięciem Błędu.
termin określający oprogramowanie, które może być
uruchamiane, kopiowane, rozpowszechniane, analizowane
oraz zmieniane i poprawiane przez użytkowników.
Oprogramowanie, aby można je było nazwać wolnym, musi
spełniać kilka podstawowych założeń, które zostały zawarte
w definicji Wolnego Oprogramowania opublikowanej przez
Naprawa
Obejście
Open Source
Oprogramowanie
narzędziowe
Oprogramowanie
pośredniczące
Oprogramowanie
systemowe
Oprogramowanie
użytkowe
PASS
PKI
Prince 2
Produkt
Przygotowanie
Środowisk
Testowych
Fundacja
Remarketing
RSA
RFC
Rozwiązanie #1
Free Software Foundation.
Rodzaj oprogramowania, który wspomaga zarządzanie
zasobami sprzętowymi poprzez dogodne interfejsy użytkowe
oraz usprawnia, modyfikuje oprogramowanie systemowe w
celu usprawnienia wykonywania programów w bardziej
wygodny i wydajny sposób, a przy tym pozbawiony błędów.
(ang. middleware) jest to rodzaj oprogramowania
umożliwiający
komunikację
pomiędzy
różnymi
aplikacjami/usługami
lub
systemami.
Architektura
oprogramowania pośredniczącego jest wykorzystywana
głównie w systemach rozproszonych przy łączeniu ze sobą
różnych
komponentów
oprogramowania
(często
znajdujących się na różnych platformach) lub komunikacji z
kanałami dostępu do nich. Przykład: systemy baz danych
takie jak: MYQL, SQL Server, PostgreSql
(ang. system software) — zespół programów sterujących
działaniem jednostki centralnej i urządzeń zewnętrznych,
organizujących logiczną przestrzeń adresową komputera
oraz system plików, a tworzących warunki do
opracowywania i wykonywania innych programów
(kompilatory, edytory), nazywany ogólnie systemem
operacyjnym. Przykład: system operacyjny Linux, Unix,
Windows, Mac i etc.
Oprogramowanie
oferujące
bezpośredni
kontakt
z
człowiekiem, czyli interakcję z użytkownikiem komputera.
Oprogramowanie
użytkowe
przeznaczone
jest
do
wykonywania czynności poleconych przez użytkownika oraz
rozwiązywania problemów zadanych przez użytkownika. W
rzoumieniu Zamawiającego takim oprogramowaniem jest
również system CRM, CMS.
ang. Professional Approach to System Selection – metodyka
zbierania informacji o wymaganiach do systemów
informatycznych
PKI (Public Key Infrastructure) - infrastruktura klucza
publicznego
Metodyka zarządzania projektami, oparta o pozytywne oraz
negatywne doświadczenia kierowników projektów z całego
świata.
Wydzielona cześć dokumentacji systemu przekazana
Zamawiającemu do odbioru końcowego.
Zainstalowanie Systemu oraz jego konfiguracja pozwalająca
na prowadzenie Testów, wraz z danymi niezbędnymi do
prowadzenia testów na Środowisku Testowym. Szczegółowe
wymagania dotyczące przygotowania Środowiska
Testowego będą przedmiotem odrębnych ustaleń na etapie
planowania testów.
FUNDACJA ROZWOJU PODHALA
Działania zmierzające do pobudzenia popytu, który uległ
obniżeniu na skutek niedostosowanej lub nietrafionej
strategii marketingowej w poprzednim okresie.
Asymetryczny algorytm kryptograficzny z kluczem
publicznym.
ang. Request for Comments zbiór technicznych oraz
organizacyjnych dokumentów mających formę
memorandum związanych z Internetem oraz sieciami
komputerowymi. Publikacją RFC zajmuje się Internet
Engineering Task Force.
Trwałe usunięcie Błędu poprzez przywrócenie pełnej
funkcjonalności w pełni zgodnej z aktualną Dokumentacją
Rozwiązanie #2
SASL
SSO
Środowisko
Testowe
Testy
bezpieczeństwa
Testy Systemowe
(SYS)
Testy
Akceptacyjne
Użytkownika
(UAT)
Testy
Wydajnościowe
(EFF)
Testy Instalacyjne
(INS)
Użytkownik
oraz usunięcie wszelkich przyczyn i skutków wystąpienia
Błędu.
Przez rozwiązanie problemu rozumie się następujące
czynności:

Wskazanie źródła problemu

Wskazanie wymaganych zmian
konfiguracyjnych (poprzez zmianę wersji czy
zainstalowanie poprawki)

Wskazanie sposobu tymczasowego
zminimalizowania skutków występowania
problemu, do czasu opracowania rozwiązania
docelowego
Wskazanie sposobu realizacji zadania w ramach wsparcia
zewnętrznego Dostawcy.
ang. Simple Authentication and Security Layer. Jedna z
metod uwierzytelniania, stosowana w protokole LDAP.
ang. single sign-on – możliwość jednorazowego
zalogowania się do usługi sieciowej i uzyskania dostępu do
wszystkich autoryzowanych zasobów zgodnych z tą usługą.
Infrastruktura teleinformatyczna wraz z zainstalowanymi
Systemami zbudowana na wzór Środowiska Produkcyjnego
pozwalająca na przeprowadzenie testów. W zależności od
rodzaju testów środowiska te mogą być rozłączne i mieć
różną konfigurację.
Proces testów, które mają na celu odnalezienie miejsc w
systemie, gdzie dane firmy i jej klientów nie są bezpieczne
lub pojawia się podatność na możliwy atak.
Proces testów sprawdzających, wykonywanych po
pomyślnej integracji jednostek wchodzących w skład
danego Systemu będącego przedmiotem testowania.
Sprawdzają one czy System jako całość spełnia postawione
wymagania funkcjonalne i jakościowe.
Proces testów sprawdzających, czy zmiana realizuje
zdefiniowane cele biznesowe. W zakres testów UAT wchodzi
weryfikacja procesów i procedur biznesowych,
realizowanych przez System oraz systemy zintegrowane, w
celu wykazania, że System spełni wymogi biznesowe
przedstawione w specyfikacjach systemowych, posiada
wymagane funkcjonalności oraz czy działają one zgodnie z
oczekiwaniami użytkowników.
Proces testów, którego celem jest sprawdzenie czy zmiana
lub System spełnia wymagania wydajnościowe, identyfikacja
„wąskich gardeł” w przetwarzaniu procesów biznesowych w
obrębie Systemu oraz komunikacji międzysystemowej.
Proces testów weryfikujących gotowość zmiany do
wdrożenia poprzez ocenę wpływu wdrożenia na poziomy
usług świadczonych w oparciu o modyfikowany System oraz
jakości procedur wdrożeniowych.
Użytkownik systemu CRM, CMS, który loguje się do
systemu. Może dodawać obiekty do systemu,
administrować, zarządzać danymi i treścia.
Usability
Użyteczność czyli własność produktów decydująca o ich
jakości użytkowej, funkcjonalności i spełnianiu oczekiwań w
warstwie użytkowej.
Social Media
Social media to media do społecznościowych interakcji w
postaci rozbudowanego zestawu narzędzi komunikacyjnych
wykraczających poza dotychczasową komunikację
Wykonawca
WYSIWYG
XML
Zamawiający
społecznościową.
Firma implementująca i wdrażająca system.
ang. what you see is what you get – to co widzisz, jest
tym co otrzymasz. Rozwiązanie informatyczne stosowane w
edytorach treści, pozwalające użytkownikowi na
skomponowanie treści, formatu, stylu, itp. bez konieczności
posiadania wiedzy programistycznej.
ang. Extensible Markup Language - uniwersalny język
formalny przeznaczony do reprezentowania różnych danych
w strukturalizowany sposób. XML jest niezależny od
platformy, co umożliwia łatwą wymianę dokumentów
pomiędzy różnymi systemami.
FUNDACJA ROZWOJU PODHALA lub podmiot/y trzeci/e
działający/e w jej imieni.
Tabela 1. Słownik pojęć.
Niektóre pojęcia zostały wyjaśnione na podstawie otwartej encyklopedii Wikipedia.
3. Wymagania bezwzględne dla systemu
3.1. Wymagania ogólne
Wymagania ogólne stawiane Systemowi:
1. System będzie zgodny z wymaganiami aktów prawnych, do stosowania których jest
zobowiązana FUNDACJA ROZWOJU PODHALA i jej partnerzy, a w szczególności z:
1)
ustawą z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (tj. Dz. U. z 2002 r.
Nr 101 poz. 926 z późn zm.),
2)
ustawą z dnia 27 lipca 2001 o ochronie baz danych (Dz. U. z 2001 r. Nr 128 poz. 1402
z późn. zm.),
3)
Rozporządzenie
Ministra Spraw Wewnętrznych i Administracji z 29 kwietnia
2004 r. w sprawie dokumentacji przetwarzania danych osobowych oraz warunków
technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy
informatyczne służące do przetwarzania danych osobowych ( Dz.
U. z 2004 r.
Nr 100, poz. 1024).
2. Rozporządzeniem Prezesa Rady Ministrów z dnia 20 lipca 2011 w sprawie podstawowych
wymagań bezpieczeństwa teleinformatycznego (Dz. U. Nr 159 z 2011 r., poz. 948 z późn.
Zm.).Wykonawca zapewni zgodność Systemu z przepisami prawa obowiązującymi w dniu
uruchomienia produkcyjnego Systemu.
3. System będzie pracować w języku polskim i angielskim. Dotyczy to między innymi
komunikatów, interfejsu użytkownika, raportów, sortowania.
4. System będzie rozwiązaniem zintegrowanym z innymi systemami zewnętrznymi. Dane do
Systemu będą wprowadzane, a następnie udostępniane systemom, w których są potrzebne.
5. System powinien umożliwiać pracę na przeglądarkach internetowych, zgodnych z ACID 3, na
poziomie 100/100.
6. Dostęp do Systemu zgodnie z przyznanymi uprawnieniami dla użytkowników będzie
realizowany poprzez przeglądarkę internetową.
7. System umożliwi udostępnianie danych podmiotom współpracującym z Zamawiającym
poprzez protokoły wymiany danych oparte na architekturze Webservice z użyciem
komunikatów XML.
8. Zastosowana technologia powinna umożliwiać migrację danych Systemu na inną platformę
systemu operacyjnego.
9. System będzie umożliwiać generowanie wielu formatów plików dla eksportu danych i
raportów.
10. System będzie zbudowany na bazie danych typu SQL.
11. System będzie posiadać jednolite środowisko bazodanowe dla wszystkich składników Systemu
(oprogramowanie korzystające z tej samej bazy danych, pracujące na tej samej platformie).
12. System powinien być rozwiązaniem otwartym, zapewniającym rozbudowę o nowe funkcje
realizujące potrzeby użytkownika.
13. System będzie umożliwiać administratorowi określenie praw użytkownika do dostępu do
określonych danych, funkcji, modułów, raportów.
14. System powinien posiadać jednolity interfejs wykonany w jednolitej technologii.
15. System będzie umożliwiać budowanie raportów samodzielnie przez użytkownika lub
administratorów dla wszystkich zgromadzonych w systemie danych poprzez zintegrowany z
systemem generator raportów.
16. System będzie zawierać dynamiczne metody filtrowania i sortowania danych.
17. System będzie umożliwiać wykonywanie wielowymiarowej analizy danych.
18. System będzie posiadać opracowaną Dokumentację Projektową oraz wyczerpującą i łatwą w
interpretowaniu Dokumentację Użytkową (instrukcje stanowiskowe powinny umożliwiać
użytkownikowi samodzielną pracę w Systemie), napisaną w języku polskim i angielskim.
19. System powinien posiadać możliwość identyfikacji użytkownika wprowadzającego zmiany do
systemu i historię wprowadzanych zmian z uwzględnieniem daty i czasu.
20. System powinien zapewniać rejestrację realizowanych funkcji eksportu danych wraz ze
wskazaniem użytkownika, daty oraz zakresu eksportowanych danych
3.2. Wymagania merytoryczne
Wdrażany system będzie spełniał cele opisane w rozdziale 1.2. niniejszego dokumentu.
Główne funkcje (core systemu) jakie będzie realizował system to:
1. rejestracja, edycja, usuwanie danych Klienta,
2. wsparcie procesu budowania relacji z Klientem,
3. rejestracja i analiza aktywności Klienta,
4. tworzenie i aktualizacja dynamicznego profilu Klienta,
5. tworzenie i redagowanie materiałów informacyjnych i promocyjnych, w tym komponowanie
dedykowanych, zindywidualizowanych i spersonalizowanych materiałów informacyjnych i
promocyjnych
6. dystrybucja materiałów informacyjnych i promocyjnych,
7. zarządzanie i prowadzenie kampanii marketingowych
8. prowadzenie analiz i opracowywanie raportów dla przeprowadzonych kampanii, bazy klientów
9. prowadzenie re-marketingu dla wybranych grup klientów.
10. automatyczną wysyłkę wiadomości okolicznościowych (np. życzenia urodzinowe, życzenia
świąteczne itp.).
Na poniższym rysunku przedstawiono diagram hierarchii funkcji Systemu.
Dane klienta
Rejestracja danych
Edycja danych
Usuwanie danych
Kontakt z Klientem
Rejestracja kontaktów
Wsparcie kontaktów
Monitoring aktywności
Klienta
Rejestracja danych o
aktywności
Analiza danych
Usuwanie danych
Dynamiczny profil Klienta
Definiowanie cech i
atrybutów
Tworzenie dynamicznego
profilu
Aktualizacja dynamicznego
profilu
Usuwanie profilu
Materiały informacyjne i
promocyjne
Tworzenie materiałów
Edycja materiałów
Publikacja materiałów
Usuwanie materiałów
Komponowanie newslettera
Dystrybucja materiałów
Zarządzanie bazą adresową
Tworzenie wiadomości email
Wysyłanie wiadomości e-mail
Obsługa wiadomości
zwrotnych
Obsługa akcji
marketingowych
Planowanie akcji
Wsparcie prowadzenia akcji
Rozliczanie akcji
Analizy i raporty
Prowadzenie analiz
Tworzenie raportów
Tworzenie, edycja i usuwanie
szablonów raportów
Rysunek 1. Diagram hierarchii funkcji
System będzie umożliwiał zapisanie, przechowywanie, edytowanie i usuwanie danych Klienta, który
dokona rejestracji poprzez wskazane strony internetowe. Rejestrowane dane Klienta to między innymi:
1) numer klienta (ID),
2) nazwa skrócona - login (maksymalna liczba znaków),
3) nazwa instytucji / firmy
4) imie i nazwisko
5) kraj,
6) kod pocztowy,
7) miasto,
8) ulica,
9) adres, adres korespondencyjny, adres inny,
10) telefon,
11) dodatkowy telefon,
12) tel. kom.,
13) fax,
14) adres e-mail,
15) deklaracja zgody na przetwarzanie danych,
16) cel przetwarzania danych (wewnętrzne, marketingowe),
17) opis,
18) komentarze,
19) uwagi,
20) status (aktywny / nieaktywny),
21) adres IP komputera, z którego łączy się Klient z wybranymi serwisami,
22) informacje zawarte w plikach cookies.
23) przynależność do grupy / grup użytkowników
Podczas prac projektowych na etapie analizy przedwdrożeniowej zakres powyższych danych może
zostać rozszerzony. Wykonawca musi uwzględnić taką możliwość w przygotowywanej przez siebie
ofercie.
System będzie również wykorzystywany jako wsparcie bezpośrednich kontaktów z Klientem
inicjowanych przez przedstawicieli Partnerów Zamawiającego. Oznacza to, że wybrane funkcje
systemu będą udostępnione Partnerom. Lista funkcji udostępnionych partnerom zostanie opracowana
na etapie analizy przedwdrożeniowej.
System będzie gromadził i poddawał analizie dane o aktywności Klienta we wskazanych serwisach
internetowych, m.in.:

kliknięć w poszczególne linki odsyłające do stron lub podstron dotyczących konkretnej
tematyki, np. funduszy unijnych, turystyki na podhalu, regionu, itp.

tematyki, treści odwiedzanych stron,

analizy słów kluczowych wpisywanych w polach wyszukiwania,

czasu spędzonego na stronach o wybranych tematykach
Informacje o aktywności użytkownika w Internecie są gromadzone i przetwarzane przy wykorzystaniu
targetowania behawioralnego. Źródłem danych o subskrybentach są portale internetowe, portale typu
social media, systemy ankietowe oraz inne systemy przetwarzające informacje o użytkownikach.
CRM powinien umożliwiać analizę stron internetowych partnerów współpracujących z Fundacją.
Gromadzone dane, w połączeniu z danymi uzyskanymi z ankiet, newsletterów i innych źródeł, będą
poddawane przez system analizie, na podstawie której tworzony będzie dynamiczny profil Klienta.
Dane poddawane analizie będą obejmowały w szczególności:
1) zainteresowania,
2) aktywność (klikanie w dany element, ilość kliknięć, częstotliwość, itp.),
3) geolokalizacje,
4) cechy demograficzne (wiek, płeć),
5) analiza statystyczna treści,
6) zamawiane produkty (broszury, newslettery, itp.)
7) profil prowadzonej działalności
Wszelka analiza danych musi odbywać się z zachowaniem zasad prywatności Klienta i z
przestrzeganiem przepisów polskiego prawa i przepisów Unii Europejskiej.
W ramach analizy danych dotyczących lokalizacji system pozwoli w szczególności na tzw.
geotargetowanie o dowolnym stopniu szczegółowości (kraj, region, miejscowość).
Dynamiczny profil klienta to zbiór cech posiadanych lub nieposiadanych przez Klienta. System zapewni
możliwość definiowania cech i atrybutów na podstawie których tworzone są profile. System umożliwi
wykorzystanie dowolnej ilość cech i atrybutów.
Utworzony profil Klienta będzie profilem dynamicznym, aktualizowanym na bieżąco, co oznacza, że
analiza w/w aspektów aktywności Klienta będzie powtarzana wielokrotnie, a w przypadku
zidentyfikowania zmian, tworzony profil będzie oznaczany innymi atrybutami. Częstotliwość
automatycznej analizy profilu Klienta zostanie określona na etapie analizy przedwdrożeniowej
systemu, jednak nie powinna być rzadsza niż raz w miesiącu.
System musi umożliwić tworzenie i redagowanie treści newsletterów. W tym celu system musi
posiadać funkcjonalność dynamicznej zmiany treści – DC. System musi umożliwiać utworzenie treści
zgodnie ze zdefiniowanym formatem, zarządzanie tą treścią przez wyznaczonych użytkowników,
edytowanie i usuwanie treści, itp. Dla tej funkcjonalności system musi spełniać założenia WYSIWYG.
System będzie dawał możliwość wysyłania treści do subskrybenta zgodnie z jego oczekiwaniami i
zainteresowaniami. Dynamiczny profil Klienta, poprzez zestaw przypisanych atrybutów będzie określał,
które treści materiałów informacyjnych i promocyjnych zostaną umieszczone na dedykowanym i
zindywidualizowanym newsletterze wysłanym do konkretnego Klienta. Przykład: Klient, użytkownik
wskazanego serwisy internetowego dotyczącego tematyki turystycznej „klika” w odnośniki dotyczące
wybranej dziedziny, np. funduszy unijnych. Dodatkowo „klika” na odnośniki dotyczące wskazanego
regionu geograficznego. Na podstawie tych danych, a także na podstawie innych danych
zgromadzonych, np. podczas rejestracji Klienta w serwisie, takich jak wiek, możliwe będzie określenie
profilu Klienta jako np. „młodego klienta aktywnego zainteresowanego dotacjami w małopolsce”, a
następnie na tej podstawie możliwe będzie skomponowanie treści dedykowanych takiemu profilowi.
Atrybuty
definiujące
poszczególne
typy
profili
zostaną
zdefiniowane
na
etapie
analizy
przedwdrożeniowej.
Skomponowane
materiały
informacyjne
i
promocyjne
będą
miały
charakter
dedykowany,
zindywidualizowany i spersonalizowany. Materiały wysyłane do danego Klienta będą mogły być
komponowane automatycznie przez system poprzez wybranie spośród wszystkich dostępnych
tematów, treści spełniających zdefiniowane pod kątem dopasowania do zainteresowań danego Klienta
kryteria. Co nie wykluczy przygotowania newsletterów w sposób tradycyjny, nieautomatyczny.
System będzie posiadał funkcję wysyłania masowej ilości wiadomości elektronicznych, tzw. mailing.
System powinien umożliwiać automatyczną weryfikacje adresów e-mail. W przypadku braku
możliwości dostarczenia wiadomości na adres e-mail adresata, system powinien oznaczyć adres jako
nieprawidłowy (np. do ponownej weryfikacji) i tym samym nie brać go pod uwagę przy kolejnych
wysyłkach newslettera.
W ramach tej funkcji system będzie umożliwiał:
1) tworzenie i zarządzanie bazą adresów e-mail,
2) składanie treści, tworzenie oraz wysyłanie wiadomości e-mail,
3) obsługę informacji zwrotnych.
4) Weryfikacja adresów tzw. Double opt-in
5) System antyspamowy
6)
Wysyłka maili w standardzie UTF i ISO
Zabezpieczenie przed „Czarną Listą Spamową”.
System powinien również wspierać prowadzone kampanie marketingowe na portalach
internetowych typu Social Media. System prócz standardowego sposobu wysyłki newsletterów na
adres mailowy powinien również umożliwiać publikacje newsletterów w portalach społecznościowych
takich jak Facebook, Blip, Twitter, w postaci odnośników do pojedynczej strony WWW z newsletterem.
Ponadto system powinien być wzbogacony o dodatkowe przyciski (ikony portali społecznościowych) w
edytorze WYSWIG
umożliwiające ich wstawienie do newslettera. System
wiadomości dzielenie się
umożliwi odbiorcy
nią ze znajomymi w portalu społecznościowym. Po „kliknięciu” na ikonę
„podziel się” portalu społecznościowego, umieszczoną w newsletterze, użytkownik zostanie
przeniesiony na stronę logowania do serwisu społecznościowego oraz po weryfikacji tożsamości,
poproszony o potwierdzenie dodania wpisu.
Poza mailingiem system będzie wykorzystywany do wsparcia kierowanej do Klienta obsługi
korespondencji tradycyjnej. System umożliwi wydruk dokumentów oraz etykiet wysyłkowych.
Ponadto,
poza
komponowaniem
dedykowanych
newsletterów
system
będzie
miał
funkcje
automatycznego tworzenia i wysyłki do Klienta zindywidualizowane wiadomości okolicznościowe, np.
życzenia urodzinowe itp. Szczegółowa lista typów wiadomości okolicznościowych zostanie określona na
etapie analizy przedwdrożeniowej.
Poza wymienionymi wyżej funkcjami System zapewni możliwość prowadzenia wielowymiarowych
analiz, tworzenia raportów i zestawień z poziomu użytkownika. Wykonawca w ramach realizacji
zamówienia będzie zobowiązany dostarczyć zestaw 50 gotowych raportów oraz generator raportów narzędzie do samodzielnego definiowania szablonów raportów przez uprawnionych użytkowników
Systemu. Zawartość raportów, do dostarczenia których zobowiązanych będzie wykonawca, zostanie
określona na etapie analizy przedwdrożeniowej.
Aplikacja powinna posiadać możliwość generowanie szczegółowych raportów dotyczących:

kampanii marketingowych,

danych zawartych w bazie kontaktowej CRM,

zbiorczych
zestawień
klientów
według
kraju
pochodzenia,
preferencji,
liczby
odwiedzin, wyświetlonych stron, czasu spędzonego na stronie, częstotliwości odwiedzin,
kliknięć (linki na stronie/zdjęcia).
Wszelkie dane raportowe
powinny być przedstawiane w formacie tekstowym
(tabelaryczne
zestawienie danych) i graficzne w postaci wykresów.
1)
Wymaganie ogólne:

2)
możliwość wyświetlania dynamicznych raportów dla wszystkich kampanii mailowych,
Prezentacja danych:

graficzne przestawienie danych dla każdej kampanii wysyłkowej wyświetlony według
kryteriów czasowych ustalonych przez użytkownika,

graficzna prezentacja wysłanych maili oraz maili zwróconych/niedostarczonych
wyświetlony według kryteriów czasowych ustalonych przez użytkownika,

graficzna prezentacja ilości danych wysłanych dla każdej kampanii wysyłkowej oraz
sumy transferu danych dla wszystkich kampanii wyświetlony według kryteriów czasowych
ustalonych przez użytkownika.
3)
Szczegóły indywidualnych kampanii:

ogólne informacje o kampanii zawierające dane o jej identyfikatorze, dane
wysyłającego, nazwa newslettera, średnia wielkość (w KB) każdego maila, ilość wysłanych
maili i sumaryczny transfer danych dla danej wysyłki,

informacje
statystyczne
powinny
zawierać
dane
dotyczące,
ilości
otwartych/przeczytanych newsletterów, ilości niedostarczonych (współczynnik odrzuceń)
newsletterów, ilości kliknięć w wysłanych newsletterach, sumaryczną ilość wysłanych maili z
możliwością exportu tych danych do formatów eksportowych (patrz: Słownik),

tabela najpopularniejszych linków w newsletterze zawierająca link, ilość kliknięć, listę
odbiorców, którzy kliknęli na link oraz możliwość danych do formatów eksportowych (patrz:
Słownik),

4)
mapę kliknięć (heatmap) newslettera.
Graficzne i tekstowe statystyki z podziałem na okresy:

możliwość wyświetlenia statystyk z podziałem na raporty miesięczne (od 1 do 6
miesięcy), półroczne, roczne i od początku istnienia systemu,

możliwość wyświetlenia statystyk dla każdego newslettera,

Możliwość wyświetlenia statystyk dla poszczególnych kampanii.

Informacja o numerze otwarć i kliknięć z podziałem na dni i godziny.

Data wysyłki.
5)
Analizy specjalne:

Porównanie zachowania wybranych grup odbiorców ilustrujący liczbę otwarć i kliknięć
według np.: płci, mieszkańców danego regionu, miasta itd.
System musi umożliwiać dokonywanie importu danych zawartych w plikach. Import danych
powinien się odbywać przy pomocy kreatora importu. System powinien umożliwiać obsługę formatów
plików dla importu danych (patrz: słownik).
Eksport danych z systemu powinien odbywać się po
określeniu zakresu oraz ilości pobieranych danych z systemu do formatów eksportowych.
System musi umożliwiać dokonywanie eksportu danych. Eksport danych powinien odbywać się
z wykorzystaniem kreatora eksportu. Kreator powinien umożliwić sprawną modyfikację rodzaju oraz
zakresu danych. Ze względu na wrażliwość przechowywanych informacji system nie powinien
zezwalać na masowy eksport całej bazy danych. Zakres oraz rodzaj eksportowanych danych powinien
być określany na podstawie przyznanych uprawnień przez administratora.
System umożliwi zarządzanie treścią portalu. Użytkownik CMS, edytując treść powinien to
robić w trybie In-line. Czyli edytując daną treść od razu widzi jak będzie ona wyglądała docelowo. W
skład zarządzania treścią będą wchodzić następujące komponenty:
a) Publicystyka – katalog artykułów (możliwy dowolny podział, możliwość rozbudowy)
Na początek będą pogrupowane w następujących grupach tematycznych:
 Energia solarna
 Energia wiatrowa
 Energia geotermalna
 Biomasa
 Energia wodna
 Biogaz
 Recycling
Każdy artykuł będzie mógł być komentowany, będzie go można wydrukować, wysłać
znajomym czy też opublikować w portalach społecznościowych.
System ma być tak zaprojektowany aby umożliwić korzystanie z portalu przez osoby
słabiej widzące.
Artykuł będzie mieć datę publikacji.
Musi być możliwość pełnej administracji drzewem katalogów publikacji.
Artykuł będzie mógł być wyróżniony na pierwszej stronie serwisu, oraz musi być
możliwość ustalania kolejności artykułów w liście. Wyróżnione artykuły będą
pokazywać się w pierwszej kolejności. Należy przewidzieć możliwość dynamicznych
rotatorów w odniesieniu do polecanych artykułów / opracowań
b) Kalendarz wydarzeń – będzie to katalog wydarzeń, które są istotne dla
zainteresowanych problematyką OZE. Mogą to być np. terminy przyjmowania wniosków
w ramach projektów unijnych polegających na finansowaniu OZE, terminy konferencji,
targów, wystaw poświęconych OZE. Na portalu będzie stworzony mechanizm szybkiego
wyszukiwania wydarzenia podając interesujący nas zakres dat, miejsce
oraz
ewentualnie rodzaj wydarzenia. Do każdego wydarzenia będzie można dodać załączniki
(zaproszenia, ulotki), film, zdjęcia. Do każdego wydarzenia użytkownicy będą mogli
dopisać swój komentarz, polecić znajomym, wydrukować. Będzie możliwość zapisania
się do „przypominacza” o nadchodzących wydarzeniach, tak aby zainteresowany nie
zapomniał o imprezie. Na głównej stronie portalu będą prezentowane najciekawsze
wydarzenia w danym obszarze. Będzie istnieć możliwość wyróżnienia wydarzenia w
liście prezentowanych imprez. Wydarzenia będą podzielone na grupy. Musi być
możliwość zrobienia dowolnego podziału.
c) Katalog informacyjny – będzie zawierał spis firm, usług oraz organizacji których
zakres działania dotyczy problematyki OZE. Na początek zostanie zrealizowany
następujący podział:
A) Edukacja i działalność badawczo rozwojowa
 Wyższe uczelnie zajmujące się problematyką OZE
 Jednostki naukowo - badawcze
 Centra badawczo - rozwojowe
 Instytuty wydające opinie i certyfikaty techniczne
 Szkoły niższego szczebla, w tym szkoły zawodowe zainteresowane
problematyką OZE
B) Najnowsze technologie OZE
 Wymiana informacji o technologiach wykorzystywanych w OZE
 Najnowsze wynalazki, patenty i rozwiązania z zakresu OZE
 Aktualne inwestycje w obszarze OZE
 Wykorzystanie nowoczesnych technologii w OZE
C) Finansowanie OZE
 Fundusze unijne na rozwój i wykorzystanie OZE
 Produkty specjalistyczne banków na finansowanie OZE
 Projekty NFOŚ na finansowanie OZE
 Inne źródła finansowania: program szwajcarski, granty norweskie
Karta opisowa każdego „obiektu” będzie mieć ujednolicona formę prezentacji. Będą
jednak niektóre kategorie gdzie karta prezentacji, wyszukiwarka będą dostosowane do
szczegółowych wymagań danej kategorii. Każdy opis będzie można wydrukować, dodać
komentarz, przesłać znajomemu, dodać do ulubionych. Zaprezentowany powyżej podział
będzie rozbudowywany.
Zostanie na portalu umieszczona poddstrona z mapa interaktywną na której zostaną
zaprezentowane lokalizacje poszczególnych firm, instytucji. Będzie można zawęzić prezentacje
instytucji do poszczególnej kategorii, np. pokazać tylko instytuty zajmujące się biomasą albo
przedsięwzięcia poświęcone energetyce wiatru (np rozmieszczenie farm wiatrowych). Każdy
opis będzie zawierał mapę z lokalizacją danej jednostki.
d) Przewodnik po OZE - będzie to dział w którym zostaną prezentowane najciekawsze
zrealizowane inwestycje w OZE w Polsce (szczególnie w Małopolsce) oraz w państwach,
z których pochodzą partnerzy.
Dodatkowo będzie możliwość zgłaszania miejsc, opisów przez użytkowników portalu.
Opisy będą moderowane przez administratora. Do każdego opisu można dodać zdjęcia,
film, link do ciekawej strony. Każdy opis będzie zawierać link do mapy, będzie można
podyskutować na forum. Propozycje projektów OZE będą zgłaszane przez partnerów
portalu (później można to grono poszerzyć na innych użytkowników portalu).
e) Ogłoszenia – ogłoszenia typu szukam technologii, szukam partnera do projektu itp.
Umieszczanie ogłoszeń jest bezpłatne. Moderowane przez administratora. Ogłoszenia
będą mogli do systemu dodawać użytkownicy i klienci. Użytkownicy dodatkowo będą
mogli administrować wszystkimi ogłoszeniami. Podomioty współpracujące będą mogły
mieć swoje dedykowane tablice ogłoszeń w systemie.
Będzie rejestrowana aktywność klientów klikających po podstronach ogłoszeń.
f)
Blog – Blog portalu prowadzony przez obsługę portalu mający na celu prezentowanie
nowości na portalu. Blogi tworzyć będą mogli pracownicy Fundacji a także podmioty
współpracujące z fundacją. Każdy z blogów będzie mógł być dedykowany pod
konkretny podmiot współpracujący.
g) Książki i multimedia – zapowiedzi wydawnictw, czasopism – katalog artykułów
poświęconych problematyce OZE. Każdy z podmiotów będzie mógł tworzyć swoje
własne podstrony niezależnie od głównej strony.
h) Konkursy kierowane do użytkowników portalu; w ramach wdrożenia ma
powstać moduł zarządzania konkursami. Klienci będą mogli uczestniczyć w
konkursach. Podmioty współpracujące będą modły tworzyć własne konkursy w
swojej części portalu i prezentować w ramach własnej aktywności.
i) Gry i zabawy promujące ekologię, oszczędzanie energii i uświadamiających
problematykę OZE – w ramach projektu ma zostać stworzony mechanizm
zarządzania grami internetowymi. Użytkownicy będą mogli dodawać własne gry
flaszowe w odpowiednich strefach portalu i nimi zarządzać. Przy wdrożeniu
Wykonawca zaimplementuje 20 grier i udostępni je w portalu. Specyfikacja
gier powstanie na etapie przedwdrożeniowej analizy.
j) Pliki filmowe – katalog teledysków, filmów które są umieszczone na portalu
youtube a dotyczą szeroko rozumianej problematyki uświadamiania
ekologicznego i wspierania sektora OZE; System umożliwi zarządzanie tymi
filmami dla pracowników Fundacji a także dla pracowników podmiotów
współpracujących.
k) Świat – ciekawe informacje o światowych tendencjach w zakresie OZE
Moduł umożliwiający dodawanie, redagowanie, publikowanie i zarządzanie dla
Zmawiającego a także dla podmiotów współpracujących.
l) Do wydruku lista materiałów przeznaczonych do wydruku dla
zainteresowanych użytkowników portalu
Specjalny moduł opowiedzialny za zarządzanie materiałami do wydruku i
pobrania. Będą to specjalne materiały przygotowane do pobrania, wydruku lub
zamówienia przez klienta. Podmioty współpracujące w ramach swojej części
systemu także będą mogły tworzyć swoje biblioteki i zbiory materiałów.
m) Artykuły - opracowania o charakterze łatwiejszym w odbiorze, mające bardziej
charakter publicystyczny (w przeciwieństwie do strefy partnerów gdzie
dominuje podejście specjalistyczne, eksperckie a nawet naukowe)
Dla każdego ze współpracujących podmiotów będzie możliwość definiowania
własnych artykułów.
n) Zabawy edukacyjne w języku angielskim – lista artykułów z zabawami.
Moduł zarządzania wszelkimi internetowymi zabawami edukacyjnymi mający na
celu zainteresowanie problematyką języka angielskiego.
Wszyscy użytkownicy będą mogli tworzyć swoje własne dedykowane zabawy
dedykacyjne.
o) Szkoła - lista informacji edykacyjnych.
Współdzielony moduł wymiany informacji i jej publikacji w ramach informacji
edukacyjnych.
p) Rejestracja / logowanie / konto – dostęp do niektórych części portalu
będzie ograniczony tylko dla zarejestrowanych użytkowników
ewentualnie dostępny tylko dla partnerów. Aby założyć konto użytkownik
musi podać swój email i wybrać hasło. Danymi dodatkowymi jakie będzie
mógł wpisać użytkownik to miejsce zamieszkania, dzielnica,
zainteresowania, zdjęcie. – awatar
q) Forum - forum internetowe tylko dla zalogowanych użytkowników.
Możliwość moderacji wpisów. Kategoryzacja. Każdy podmiot
współpracujący będzie posiadał własny dedykowany dział, w którym
będzie mógł definiować własne fora i je publikować.
r)
Wyszukiwanie w portalu – globalna kontekstowa wyszukiwarka w
portalu, potrafiąca odnaleźć informację we wszystkich obiektach i ich
atrybutach.
W systemie będzie także przeglądarka wewnętrzna obejmująca zarówno
system CMS jak i CRM umożliwiająca także globalne przeszukiwanie
bazy CRM.
s)
Podsystemy dedykowane dla partnerów – każdy z partnerów będzie miał
możliwość zdefiniowania własnego podsystemu w ramach CMS i CRM.
W ramach systemu CMS będzie posiadał włąsną podstroję w pełni
zarządzana i modyfikowaną przez niego. W ramach systemu CRM
użytkownik współpracujący będzie posiadał własny kompletny podsystem
zarządzania danymi klientów i relacjami z nimi. Takie podejście zachęci
inne podmioty do współpracy z Fundacją.
Fundacja dzięki udostępnieniu systemu, będzie mogła korzystać z
materiałów podmiotów współpracujących. Zakres wymienianych danych
będzie definiowany w systemie przez administratora, a formalnie
regulowany będzie umowami z partnerami.
t)
Moduł SEO – system portalowy ma być przystosowany do optymalnego
pozycjonowania w oparciu o wytyczne Google. Wykonawca przedstawi
odpowiedni
scenariusz
postępowania
na
etapie
analizy
przedwdrożeniowej.
W systemie CRM powinien być dostępny moduł poczty email.
Moduł umożliwia zdefiniowanie konta poczty przychodzącej. Każda korespondencja e-mail
przychodząca do firmy będzie miedzy innymi przechodzić przez system i będzie rozdzielana i
przypisywana do odpowiednich kart klientów.
Takie postępowanie spowoduje, że w karcie klienta oprócz pozostałych dokumentów powiązanych,
będą znajdować się emaile. Proces ten będzie w pełni automatyczny.
Funkcjonalność e-learning zarządzał będzie materiałami szkoleniowymi, kursami i egzaminami.
- materiały do druku
- interaktywne formularze
- formularze egzaminacyjne
- system ocen
- inne materiały multimedialne zdefiniowane na etapie analizy.
Części systemu CMS i CRM mają współpracować ze sobą i się komunikować ze sobą. W CRM między
innymi ma być badana aktywność na portalu użytkowników. Portal ma korzystać z bazy danych
(wiedzy) systemu CRM.
Wszystkie aktywności klientów i użytkowników mają być logowane i możliwe do przeszukiwania, w
szczególności zmiany obiektów. Zakres parametrów zostanie określony podczas analizy.
4. Wymagania funkcjonalne
W niniejszym rozdziale przedstawione zostały szczegółowe wymagania funkcjonalne stawiane
Systemowi.
4.1. Opis metodyki
Wymagania funkcjonalne przedstawione poniżej zostały zidentyfikowane w oparciu o predefiniowane
tabele PASS. Dla każdego z wymagań określono jego priorytet:

Wartość 2 – kluczowe z punktu widzenia Fundacji, ich spełnienie stanowi jedno z
podstawowych kryteriów oceny proponowanego rozwiązania.

Wartość 1 – ważne lub mogące okazać się przydatne w przyszłości, poziom spełnienia tych
funkcjonalności stanowi dodatkowe kryterium oceny rozwiązania
W oparciu o tak wypełnione tabele Wykonawca systemu informatycznego, któremu poświęcone
została kolumna SPEŁNIA oraz Uwagi, będzie definiował możliwość spełnienia wymagań stawianych
przed nowym systemem CRM dla Polskiej Organizacji Turystycznej.
Tabela 2 Przykład wypełnienia tabeli PASS przez Wykonawcę
Znaczenie
Spełnia
funkcjonalność dostarczona w standardzie
1
brak możliwości realizacji funkcjonalności w
proponowanym systemie
0
4.2. Tabela wymagań funkcjonalnych
Fundacja Rozwoju Podhala
WYMAGANIA FUNKCJONALNE DO SYSTEMU
FUN 1.00
FUN 1.01
FUN 1.02
FUN 1.03
FUN 1.04
FUN 1.05
FUN 1.06
FUN 1.07
FUN 1.08
FUN 1.09
FUN 1.10
FUN 1.11
FUN 1.12
FUN 1.13
FUN 1.14
FUN 1.15
FUN 1.16
FUN 1.17
FUN 1.18
FUN 1.19
FUN 1.20
FUN 1.21
Funkcjonalność
Wykonawca
Spełnia
Lp.
Zamawiający
SYSTEM CRM. CMS
Uwagi
WYMAGANIA FUNKCJONALNE
OBSŁUGA KLIENTA
Numer klienta (ID)
2
Imię i nazwisko
2
Nazwa skrócona
2
(maksymalna liczba znaków)
Nazwa instytucji / Firma
2
Pełniona funkcja
2
Kod pocztowy
2
Miasto
2
Ulica
2
Adres, adres korespondencyjny,
2
adres inny
Telefon
2
Dodatkowy telefon
2
Tel. kom.
2
Fax
2
E-mail
2
Deklaracja zgody na
2
przetwarzanie danych
Cel przetwarzania danych
2
(wewnętrzne, marketingowe)
Opis / komentarze / uwagi
1
Status (aktywny / nieaktywny)
2
Przynależność do grupy / grup
Możliwość definiowania
1
dodatkowych pól
REJESTR KONTAKTÓW Z
KLIENTEM
Telefoniczne
2
E-mailowe
2
FUN 1.22
FUN 1.23
FUN 1.24
FUN 2.00
FUN 2.01
FUN 2.02
FUN 2.03
FUN 2.04
FUN 2.05
FUN 2.06
FUN 2.07
FUN 2.08
FUN 2.09
FUN 2.10
FUN 2.11
FUN 2.12
FUN 2.13
FUN 2.17
FUN 2.23
FUN 2.24
FUN 2.25
Ilość i rodzaj materiałów
1
wysłanych do Klienta
Podpowiadanie tematów
2
zainteresowań
Rejestr "spraw" związanych z
1
klientem
DZIAŁANIA MARKETINGOWE
Zamawianie broszur w wersji
2
elektronicznej
Zamawianie broszur w wersji
1
drukowanej.
Tworzenie dynamicznych profili
2
klientów.
Szczegółowe informacje o
produktach dla określonego
2
klienta (newslettery, broszury,
itp.)
Premiowanie aktywności
2
klientów (klikanie)
Wykaz planowanych akcji
2
marketingowych
Przygotowanie budżetu
2
marketingu i harmonogramu
Podział na etapy i zadania
2
Przypisanie osoby
odpowiedzialnej za dany etap /
2
zadanie
Przypisanie osób do
2
poszczególnych zadań
Tworzenie harmonogramów
2
czasowych dla etapów i zadań
Przypisanie środków z budżetu
2
na dany etap / zadanie
Tworzenie ofert, promocji
2
(również spersonalizowanych)
Ustalanie priorytetów zadań do
2
wykonania
REALIZACJA DZIAŁAŃ KAMPANII
MARKETINGOWYCH
Przygotowywanie
korespondencji seryjnej do
klientów: e-mail, faks, w sposób
2
tradycyjny (możliwość nadruku
na koperty)
Premiowanie aktywności
2
klientów na stronach (klikanie)
NEWSLETTER
Tworzenie, edytowanie i
2
usuwanie treści newslettera
Dodawanie obrazów oraz
multimediów do treści
2
newslettera, w szczególności:
wideo, zdjęć
FUN 2.26
FUN 2.27
FUN 2.28
FUN 2.29
FUN 2.30
FUN 2.31
FUN 2.32
FUN 2.33
FUN 2.34
FUN 2.35
FUN 2.36
FUN 2.37
FUN 2.38
FUN 2.39
FUN 2.40
FUN 2.41
Komponowanie dedykowanych,
zindywidualizowanych i
spersonalizowanych
newsletterów na podstawie
zdefiniowanych atrybutów.
Wysyłanie spersonalizowanych
kryteriów ustalonych przez
redaktora
Wysyłanie spersonalizowanych
kryteriów znajdujących się w
profilu odbiorcy
Automatycznie wyszukiwane i
pobieranie na podstawie
kryteriów ustalonych przez
redaktora i/lub zdefiniowanych
w profilu odbiorcy
Wbudowany edytor WYSIWYG
przeznaczony dla osób
redagujących newsletter w
module wyświetlającym
ostateczną formę graficzną
newslettera
Rezygnacja z newslettera
poprzez formularz rezygnacji.
Zapis do newslettera w
standardzie double opt-in.
Oznaczanie nieaktualnych
adresów e-mail na podstawie
zwrotnych wiadomości
Automatyczne wysyłanie
wiadomości sugerujących
wypisanie się z newslettera, w
przypadku braku aktywności
odbiorcy.
SZABLONY
Stopka edycji profilu
Stopka podglądu WWW
Możliwość tworzenia stopek
typu Social Media.
Obsługa (tworzenie, edytowanie
i komponowanie) newsletterów
w min. 5 językach, na min. 10
rynków docelowych.
Możliwość późniejszego
definiowania kolejnych rynków
zagranicznych dla potrzeb
newsletter
Możliwość podglądu wysyłanego
maila na stronie
Test popularnych skrzynek
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
FUN 2.42
FUN 2.43
FUN 2.44
FUN 2.45
FUN 3.00
FUN 3.01
FUN 3.02
FUN 3.03
FUN 3.04
FUN 3.05
FUN 3.06
FUN 3.07
FUN 3.08
poczty elektronicznej w celu
weryfikacji czy wiadomość
elektroniczna nie została
zakwalifikowana jako spam.
Test poprawnego wyświetlania
newslettera dla popularnych
skrzynek poczty elektronicznej.
Możliwość wybrania szablonu dla
newslettera z Biblioteki
szablonów
Możliwość dodawania kolejnych
szablonów graficznych dla
newsletterów.
Możliwość eksportu szablonów
do formatów eksportu danych.
RAPORTOWANIE
Możliwość wyświetlania
dynamicznych raportów dla
wszystkich kampanii mailowych
Przedstawienie danych
raportowych w formie graficznej
oraz w formie tekstowej, jako
tabele wraz z mapą kliknięć na
stronach
Możliwość tworzenia przez
użytkowników własnych
raportów, zestawień i
dokumentów poprzez
wbudowany kreator raportów
Możliwość tworzenia szablonów
dla dokumentów, raportów i
zestawień
Kreator raportów powinien
umożliwiać dowolne
definiowanie kolumn w
zestawieniu, ich kolejności oraz
sposobu sortowania danych
umożliwiać zmiany szerokości,
opisu, koloru, oraz innych
parametrów prezentacji w
zestawieniu
umożliwiać prezentację danych
w postaci tabel, wykresów
Możliwość zapisu wyników
raportów do plików w formatach
eksportowych (patrz: Słownik)
Możliwość wydruku do pliku lub
na drukarkę przygotowanego
zestawienia w postaci, w jakiej
użytkownik widzi zestawienie na
monitorze
2
2
2
2
1
2
2
1
2
1
2
2
2
FUN 3.09
FUN 3.10
FUN 3.11
FUN 3.12
FUN 3.13
FUN 3.14
FUN 3.15
FUN 3.16
FUN 3.17
Możliwość generowania
dokumentów oraz raportów i
zestawień na podstawie
predefiniowanych szablonów, w
których część danych będzie
wypełniana automatycznie
danymi z bazy danych
Możliwość zdefiniowania
dostępu do zestawienia dla
innych użytkowników
System powinien umożliwiać wykorzystanie całych tabel oraz ich
poszczególnych pól do
definiowania szablonów
raportów
System powinien umożliwiać
definiowanie wyboru danych
(filtrowanie) wg dowolnych
warunków logicznych z
wykorzystaniem tabel i ich pól w
ramach bazy danych
Udostępnianie listy
predefiniowanych raportów
PREZENTACJA DANYCH
Graficzne i tabelaryczne
przedstawienie danych dla
każdej kampanii wysyłkowej
wyświetlony według kryteriów
czasowych ustalonych przez
użytkownika.
Graficzna i tabelaryczna
reprezentacja wysłanych maili
oraz maili
zwróconych/niedostarczonych
użytkownika
Graficzna i tabelaryczna
reprezentacja ilości danych
wysłanych dla każdej kampanii
wysyłkowej oraz sumy transferu
danych dla wszystkich kampanii
użytkownika
SZCZEGÓŁY INDYWIDUALNYCH
KAMPANII
Ogólne informacje o kampanii
zawierające dane o jej
identyfikatorze, dane
wysyłającego , nazwa
newslettera, średnia wielkość (w
KB) każdego maila, ilość
wysłanych maili i sumaryczny
2
1
1
2
1
2
2
1
2
FUN 3.18
FUN 3.19
FUN 3.20
FUN 3.21
FUN 3.22
FUN 3.23
FUN 3.24
FUN 3.25
FUN 3.26
FUN 3.27
transfer danych dla danej
wysyłki.
Informacje statystyczne
zawierające dane dotyczące,
ilości otwartych/przeczytanych
newsletterów, ilości
niedostarczonych (bounce rate)
newsletterów, ilości kliknięć w
wysłanych newsletterach ,
sumaryczną ilość wysłanych maili
z możliwością eksportu tych
danych do formatów
Prezentacja danych
statystycznych w formie
graficznej
Tabelaryczne zestawienie
najpopularniejszych linków w
newsletterze zawierająca link,
ilość kliknięć, listę odbiorców,
którzy kliknęli na link oraz
eksport danych do formatów
Mapa kliknięć (heatmap)
newslettera
GRAFICZNE I TEKSTOWE
STATYSTYKI WEDŁUG
OKRESÓW
Możliwość wyświetlenia
statystyk z podziałem na raporty
miesięczne (od 1 do 6 miesięcy),
półroczne, roczne i od początku
istnienia systemu
statystyk dla każdego
newslettera
statystyk dla poszczególnych
kampanii
Informacja o numerze otwarć i
kliknięć z podziałem na dni i
godziny
informacja o dacie wysyłki
newsletterów, broszur
elektronicznych, broszur
papierowych itp.
ANALIZY SPECJALNE
Porównanie zachowania
wybranych grup odbiorców
ilustrujący liczbę otwarć i kliknięć
według np.: płci, miejsca
zamieszkania
PROFILOWANIE DANYCH
2
2
1
2
2
2
2
1
2
2
FUN 4.00
FUN 4.01
FUN 4.02
FUN 4.03
FUN 4.04
FUN 4.05
FUN 4.06
FUN 4.07
FUN 4.08
FUN 4.09
FUN 4.10
FUN 5.00
FUN 5.01
FUN 5.02
FUN 5.03
Określenie preferencji i
zainteresowań klientów
umożliwiający rejestrowanie ich
2
aktywności na stronie po
zalogowaniu się do wcześniej
stworzonego konta na portalu
Definiowanie cech profilu
użytkownika oraz jego
2
modyfikację
Gromadzenie pełnych danych na
temat ścieżek kliknięć
2
użytkowników,
Oznaczenie użytkowników za
2
pomocą cookies
Walidacje profili pod kątem
2
żywotności cookies
Aktualizacje danych w czasie
1
rzeczywistym.
Możliwość definiowania profili
targetowania zgodnie z
2
przyjętymi kryteriami.
Śledzenie reakcji odbiorców
kampanii poprzez rejestrowanie
1
– kto i kiedy otrzymał, otworzył,
usunął wiadomość
Gromadzenie pełnych danych na
podstawie przeprowadzonych
2
ankiet, sondażowych
Pobieranie statystyk o
użytkownikach korzystających z
podstawowych narzędzi
2
polska.travel jak np.
wyszukiwarka noclegów
Wyodrębnianie podzbioru
turystów z całej bazy turystów na
podstawie dowolnej ilości
kryteriów dotyczących
przypisanych turystom cech i
atrybutów. Uzyskany podzbiór
może być użyty w innych
2
funkcjonalnościach (np. jako
grupa odbiorców w wysyłce
newsletterów albo jako
analizowana grupa w
przygotowywaniu zestawień),
aby określić ich zakres
OBSŁUGA KANAŁÓW KOMUNIKACYJNYCH
IDENTYFIKACJA KLIENTA
Po adresie e-mail
2
Numerze ID
2
Po numerze telefonu
2
Dynamiczne porównywanie
2
treści
FUN 5.04
FUN 5.05
FUN 5.06
FUN 5.07
FUN 6.00
FUN 6.01
FUN 6.02
FUN 6.03
FUN 6.04
FUN 6.05
FUN 6.06
FUN 6.07
Monitorowanie aktywności
klientów na stronach WWW
Automatyczne uzupełnianie
danych klienta, umieszczonych
przez niego na stronie WWW
WYSYŁANIE WIADOMOŚCI Z
POZIOMU SYSTEMU CRM
Adres e-mail
Wydruk dokumentów i etykiet
wysyłkowych
OPERACJE NA DANYCH
wprowadzanie, przetwarzanie,
wyszukiwanie oraz prezentację
danych gromadzonych w bazie
danych za pomocą interfejsu
webowego, zestawień i
raportów, oraz wymiany danych
z innymi systemami.
wprowadzanie danych za
pośrednictwem formularzy
webowych
zarządzanie rekordami, a w
szczególności znajdowanie,
edytowanie, usuwanie,
wyszukiwanie duplikatów,
scalanie, sprawdzanie
uprawnień, udostępnianie,
kopiowanie oraz importowanie i
eksportowanie danych
zarządzanie kartoteką
(rekordem) klienta.
System powinien wymuszać na
użytkowniku wpisywanie danych
zgodnie z ustalonymi formatami
daty, miar, kwot, tekstu itp.
pobieranie danych
udostępnianych przez inne
systemy poprzez web serwis
oraz protokoły wymiany danych
przekazywanie danych do innych
systemów poprzez interfejs
wymiany danych zgodny z
architekturą WebService
System powinien zapewniać
walidację typu danych oraz
zakresu i spójności danych
podczas wprowadzania danych
2
2
2
1
2
2
2
2
2
1
2
2
FUN 6.08
FUN 6.09
FUN 6.10
FUN 6.11
FUN 6.12
FUN 6.13
FUN 6.14
FUN 6.15
FUN 6.16
FUN 6.17
FUN 6.18
FUN 6.19
do systemu
System powinien uniemożliwiać
wielokrotne wpisanie tych
samych danych źródłowych
wprowadzanie danych i edycję
danych tylko uprawnionym
użytkownikom
dokonywanie korekt
wprowadzonych danych i
załączników wyłącznie przez
uprawnionych użytkowników
zachowując pełną historię zmian
użytkownikowi wprowadzenie
danych wykraczających poza
dopuszczalny zakres
eksportowanie danych do
formatów eksportowych (patrz:
Słownik)
Pobieranie danych z bazy CRM za
pośrednictwem web serwisów
Dodawanie obiektów do bazy
CRM ręcznie przez użytkownika
PRZECHOWYWANIE
PLIKÓW W SYSTEMIE
Dodawanie obiektów do bazy
CRM ręcznie przez użytkownika
Kategoryzacja plików
Możliwość wersjonowania
plików
Możliwość wyszukiwania plików
w systemie
Śledzenie historii plików
Analizator logów
System powinien badać
FUN 7.00
aktywność użytkowników
System powinien badać
FUN 7.01
aktywność klientów
Wszystkie zmiany edycje
FUN 7.02
powinny być rejestrowane z
informacją co zostało zmienione.
System notyfikuje czas zmiany i
FUN 7.03
wersję
Publicystyka
FUN 8.00
Tworzenie nowych artykułów
Workflow Tworzenie, edycja,
FUN 8.01
korekta, zatwierdzanie do
publikacji, publikacja
FUN 8.02
Historia wersji
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
FUN 8.03
FUN 8.04
FUN 8.05
FUN 8.06
Dostęp dla podmiotów
współpracujących
Osobny dział dostępu i publikacji
materiałów dla podmiotów
współpracujących
Wymiana danych pomiędzy
podmiotami.
Inlinowy edytor treści
2
2
2
2
Wydarzenia
FUN 9.00
FUN 9.01
FUN 9.02
FUN 9.03
FUN 9.04
FUN 9.05
FUN 9.06
FUN 9.07
Tworzenie nowych wydarzeń
Historia wersji
współpracujących
współpracujących
podmiotami.
Prezentacja w formie kalendarza
2
2
2
2
2
2
2
2
Katalog informacyjny
FUN 10.00
FUN 10.01
FUN 10.02
FUN 10.03
FUN 10.04
FUN 10.05
FUN 10.06
FUN 10.07
Tworzenie nowych obiektów
informacyjnych
Historia wersji
współpracujących
współpracujących
podmiotami.
Dostęp mobilny
2
2
2
2
2
2
2
2
Przewodnik
FUN 11.00
FUN 11.01
FUN 11.02
FUN 11.03
Tworzenie nowych elementów
przewodnika
Historia wersji
2
2
2
2
FUN 11.04
FUN 11.05
FUN 11.06
FUN 11.07
współpracujących
współpracujących
podmiotami.
Dostęp mobilny
2
2
2
2
Ogłoszenia
FUN 12.00
FUN 12.01
FUN 12.02
FUN 12.03
FUN 12.04
FUN 12.05
FUN 12.06
FUN 12.07
Tworzenie nowych ogłoszeń
Historia wersji
współpracujących
współpracujących
podmiotami.
Dostęp mobilny
2
2
2
2
2
2
2
2
Blog
FUN 13.00
FUN 13.01
FUN 13.02
FUN 13.03
FUN 13.04
FUN 13.05
FUN 13.06
FUN 13.07
Tworzenie nowych blogów i jego
elementów
Historia wersji
współpracujących
współpracujących
podmiotami.
Dostęp mobilny
2
2
2
2
2
2
2
2
Książki i multimedia
FUN 14.00
FUN 14.01
FUN 14.02
FUN 14.03
Tworzenie nowych obiektów
Historia wersji
współpracujących
2
2
2
2
FUN 14.04
FUN 14.05
FUN 14.06
FUN 14.07
współpracujących
podmiotami.
Dostęp mobilny
2
2
2
2
Konkursy
FUN 15.00
FUN 15.01
FUN 15.02
FUN 15.03
FUN 15.04
FUN 15.05
FUN 15.06
FUN 15.07
Tworzenie nowych konkursów
Historia wersji
współpracujących
współpracujących
podmiotami.
Dostęp mobilny
2
2
2
2
2
2
2
2
Gry i zabawy
FUN 16.00
FUN 16.01
FUN 16.02
FUN 16.03
FUN 16.04
FUN 16.05
FUN 16.06
FUN 16.07
FUN 16.08
Tworzenie nowych obiektow gier
i zabaw i osadzanie w nich
elementów flaszowych
(gotowych gier np.)
Historia wersji
współpracujących
współpracujących
podmiotami.
Dostęp mobilny
Stworzenie gier w ilości 20 sztuk.
(flash)
2
2
2
2
2
2
2
2
2
Swiat
FUN 17.00
FUN 17.01
2
2
FUN 17.02
FUN 17.03
FUN 17.04
FUN 17.05
FUN 17.06
FUN 17.07
Historia wersji
współpracujących
współpracujących
podmiotami.
Dostęp mobilny
2
2
2
2
2
2
Zabawy edukacyjne
FUN 18.00
FUN 18.01
FUN 18.02
FUN 18.03
FUN 18.04
FUN 18.05
FUN 18.06
FUN 18.07
Historia wersji
współpracujących
współpracujących
podmiotami.
Dostęp mobilny
2
Historia wersji
współpracujących
współpracujących
podmiotami.
Dostęp mobilny
2
2
2
2
2
2
2
2
Szkoła
FUN 19.00
FUN 19.01
FUN 19.02
FUN 19.03
FUN 19.04
FUN 19.05
FUN 19.06
FUN 19.07
2
2
2
2
2
2
2
Filmy
FUN 20.00
FUN 20.01
FUN 20.02
Tworzenie nowych elementów i
osadzanie filmów
Historia wersji
2
2
2
FUN 20.03
FUN 20.04
FUN 20.05
FUN 20.06
współpracujących
współpracujących
podmiotami.
Inlinowy edytor treści opisu
2
2
2
2
Materiały do druku
FUN 21.00
FUN 21.01
FUN 21.02
FUN 21.03
FUN 21.04
FUN 21.05
FUN 21.06
Tworzenie nowych elementów i
osadzanie materiałow
Historia wersji
współpracujących
współpracujących
podmiotami.
2
2
2
2
2
2
2
Forum
FUN 22.00
FUN 22.01
FUN 22.02
FUN 22.03
FUN 22.04
FUN 22.05
FUN 22.06
forum i dedykowany forów przez
podmioty
Historia wersji
współpracujących
współpracujących
podmiotami.
2
2
2
2
2
2
2
Wyszukiwanie w portalu
FUN 23.00
FUN 23.01
FUN 23.02
FUN 23.03
Wyszukiwanie w danych CMS,
wszystkie moduły
Wyszukiwanie danych CRM
Wyszukiwarka CRM zawiera
wyszukiwarke CMS
Prezentacja szukanej frazy jako
pogrubionej
2
2
2
2
SEO
FUN 24.00
FUN 24.01
FUN 24.02
FUN 24.03
Przyjazne linki
„Lekkie” strony
Odpowiednio zdefiniowane tagi
np. <p> itd.
Stworzenie systemu zgodnie z
wymogami Google odnośnie SEO
2
2
2
2
Wizytówki i strony dedykowane
FUN 25.00
FUN 25.01
FUN 25.02
FUN 25.03
FUN 25.04
Każdy partner będzie mógł mieć
dedykowana podstrone
portalowa
Każdy partner będzie mogł mieć
dedykowaną cześć CRM
Partnerzy maja dostęp do
wszystkich modułów
Partnerzy mogą wymieniać się
danymi
Zamawiający administruje
uprawnieniami, dostępem do
podsystemów partnerów
2
2
2
2
2
Moduł pocztowy
FUN 26.00
FUN 26.01
FUN 26.02
FUN 26.03
FUN 26.04
FUN 26.05
Podpinanie skrzynek przez POP3
Definiowanie wielu szkynek
(globalne, lokalne)
Ściąganie maili
Obsługa załączników w mailach
Przyporządkowanie do kart
klientów maili
Tworzenie maili
2
2
2
2
2
2
Moduł e-learning
FUN 27.00
FUN 27.01
FUN 27.02
FUN 27.03
FUN 27.04
FUN 27.05
Definiowanie materiałow
dydaktycznych (tekst, PDF,
obraz, film)
Tworzenie i zarzadzanie testami
Tworzenie i zarządzanie kursami
Tworzenie grup kursowych
Zarządzanie uczestnikami kursów
Oceny przebytych kursów
2
2
2
2
2
2
Tabela 3 Tabela wymagań funkcjonalnych.
5. Architektura
Wykonawca zobowiązany jest przedstawić szczegółowy opis i schemat architektury
proponowanego rozwiązania w podziale modułowym. Dla każdego modułu Wykonawca zobowiązany
jest przedstawić szczegółowy opis architektury wraz ze specyfikacją licencji wymaganych dla realizacji
wszystkich funkcjonalności.
Wykonawca zobowiązany jest do zaprezentowania sposobów integracji wszystkich modułów
rozwiązania z uwzględnieniem proponowanych metod komunikacji, protokołów transmisji etc.
Wykonawca
na
podstawie
wartości parametrów
określonych poniżej
zobowiązany
jest
do
wyszczególnienia odpowiedniej architektury sprzętowej w podziale na poszczególne komponenty
(serwery, macierze dyskowe, backup itd.), biorąc pod uwagę zapewnienie odpowiedniej wydajności
rozwiązania oraz wymagań związanych z dostępnością i skalowalnością oraz kosztami rozwiązania.
Wykonawca przedstawi mapowanie komponentów logicznych (modułów rozwiązania) na komponenty
infrastruktury sprzętowej oraz przedstawi wszystko w postaci odpowiednich diagramów UML.
Zastosowane rozwiązanie nie może być rozwiązaniem zamkniętym technologicznie. Wymaga się aby
Wykonawca zaprojektował system w otwartej architekturze, umożliwiającej jej przyszłą rozbudowę
przez wielu dostawców. Otwartość architektury, skalowalność, możliwość ponownego użycia kodu i
wykonywania zmian przez wielu dostawców będą jednymi z kryteriów akceptacji projektu
technicznego.
5.1. Architektura aplikacji
System CRM będzie posiadał architekturę wielowarstwową oddzielając warstwę dostępową,
odpowiedzialną za zarządzanie i przekazywanie połączeń, od warstwy aplikacyjnej, zajmującej się
prezentacją informacji wraz z całą logiką, oraz wydzielając warstwę danych odpowiedzialnej za
przechowywanie i udostępnianie informacji.
1) Warstwa sieciowa – odpowiedzialna za zarządzanie połączeniami.
2) Warstwa aplikacyjna – odpowiedzialna za logikę biznesową systemu oraz
prezentację danych.
3) Warstwa danych – przechowująca i udostępniająca informacje z baz danych i plików.
5.1.1. Warstwa sieciowa
Będzie to warstwa składająca się ze sprzętu i oprogramowania odpowiadająca za zarządzanie
ruchem sieciowym oraz wysyłaniem go do węzłów sieci. Warstwa dostępowa będzie posiadała usługę
rozłożenia ruchu (ang. loadbalancing). Usługa ta będzie odpowiedzialna za rozłożenie ruchu między
serwerami tak żeby odpowiedzi aplikacji były najkrótsze. Dodatkowo będzie ona minimalizowała
ryzyko przeciążenia systemu.
5.1.2. Warstwa aplikacyjna
W architekturze systemu warstwa ta ma za zadanie zgrupowania komponentów na serwerach.
Do warstwy tej będzie należeć warstwa prezentacji i logiki biznesowej.
Warstwa prezentacji będzie składała się z komponentów wyświetlających interfejs użytkownika. Do
komponentów tych będą należały aplikacje webowe odpowiedzialne za obszar informatora,
administracji użytkownikami oraz administracji treścią zawartą w bazie informacji turystycznej.
Warstwa logiki biznesowej będzie odpowiedzialna za przetwarzanie reguł i procesów biznesowych oraz
walidację danych wprowadzanych do systemu.
5.1.3. Warstwa danych
Warstwa będzie składała się z relacyjnej bazy danych oraz opcjonalnie z przestrzeni dyskowej
służącej do obsługi zapisu i odczytu plików. Zadaniem warstwy będzie przechowywanie informacji w
sposób bezpieczny oraz zapewnienie mechanizmów archiwizacji danych.
5.2. Architektura danych
Podstawę systemu CRM/CMS będzie stanowiła relacyjna baza danych zapewniająca stosowne
struktury dla gromadzenia, przetwarzania i przygotowywania analiz danych niezbędnych dla Fundacji.
Celem dla architektury danych w bazie jest spełnienie oczekiwania uzyskania możliwości szybkiego
wyszukiwania danych znajdujących się w systemie, udostępniania danych systemom zewnętrznym.
Fundacja nie określa struktury bazy danych. Zaprojektowanie tabel oraz opisujących je relacji będzie
należało do wykonawcy systemu CRM/CMS. Zaprojektowana baza musi gwarantować wydajne
działanie systemu, zgodnie z przyjętymi przez Fundacje wymaganiami.
5.3. Architektura aplikacji
Fundacja rozwoju Podhala
AA 1.00
AA 1.01
AA 1.02
AA 1.03
AA 1.04
AA 1.05
AA 1.06
AA 1.07
AA 1.08
AA 1.09
AA 1.10
AA 1.11
Funkcjonalność
Wykonawca
Spełnia
Lp.
Zamawiający
SYSTEM CRM/CMS
Uwagi
ARCHITEKTURA APLIKACJI
Możliwość integracji z dowolnymi
systemami posiadającymi treści i
2
materiały promocyjne.
Aplikacja powinna być oparta na
2
architekturze 64 bitowej.
Aplikacja powinna być zbudowana w
2
oparciu o architekturę klient-serwer
Model architektury powinien być
trójwarstwowy zapewniający
rozdzielenie warstwy logiki
2
biznesowej, warstwy prezentacji oraz
warstwy dostępu do danych
Wbudowany mechanizm WorkFlow
służący do wymiany informacji, pracy 2
pomiędzy użytkownikami
Aplikacja powinna mieć budowę
2
modułową
Możliwość wyświetlania danych bez
konieczności przeładowywania
1
całych stron przy wykorzystaniu
przeglądarki internetowej
Metadane (opisujące dokumenty,
kartoteki, słowniki itp.) powinny być
zarządzane przez serwer bazy
1
danych, natomiast fizyczne pliki
powinny być przechowywane w
osobnych repozytoriach
Możliwość rozbudowy o kolejne
2
moduły funkcjonalne
Aplikacja powinna być w pełni
skalowalna, umożliwiać zwiększanie
2
liczby użytkowników oraz
zwiększanie i rozbudowę zasobów
Dostęp do aplikacji powinien być
związany z uwierzytelnieniem
2
użytkownika, co najmniej poprzez
podanie unikalnej nazwy i hasła
Aplikacja powinna umożliwiać
jednoczesny dostęp do danych wielu
użytkownikom przy zapewnieniu
2
ochrony tych danych przed utratą
spójności lub zniszczeniem
Aplikacja powinna wspierać
wykorzystanie SSO (Single Sign On).
ZAKŁADANY WOLUMEN
Liczba użytkowników systemu: maks
400
Liczba generowanych i wysyłanych
newsletterów: maks 5000
miesięcznie.
Skalowalność systemu poprzez
zastosowanie m.in. technologii
clustrowania
AA 1.12
AA 1.13
AA 1.14
AA 1.15
1
2
2
2
Tabela 4 Architektura Aplikacji
5.4. Integracja z systemami zewnętrznymi
System musi posiadać elementy zapewniające możliwość integracji z systemami zewnętrznymi
zapewniając możliwość dynamicznej wymiany danych, która powinna się odbywać przy wykorzystaniu
otwartych
protokołów
i
standardów
–
pamiętając
jednakże
o
konieczności
zapewnieniu
bezpieczeństwa danych osobowych. Dostarczony przez Wykonawcę system CRM powinien zawierać
komponenty umożliwiające pełną, automatyczną integrację poprzez:

Interfejs programowy aplikacji

Usługi WebServices
Oprócz tego system powinien pozwalać na integrację półautomatyczną opartą o import
danych z plików o formatach CSV oraz XML. Podczas importu z tych plików użytkownik musi mieć
możliwość określenia która kolumna (CSV) lub który znacznik (XML) zawiera jaki tych typ danych (np.
imię, nazwisko, email) oraz czy należy ten zbiór danych importować.
Dane przyjęte do systemu CRM w sposób zarówno automatyczny jak i półautomatyczny
powinny być sprawdzone pod kątem poprawności (np. walidacja adresu email) oraz sprawdzone czy
nie są duplikatami albo aktualizacjami danych już zgromadzonych. Stosowne komunikaty powinny być
wówczas zapisane w dzienniku aktualizacji, aby użytkownik systemu CRM mógł później się z tym
zapoznać i dokonać analizy problemów importowych.
5.5. Integracja z systemami portalowymi.
5.5.1. Śledzenie aktywności użytkowników
Internauta korzystając z portalu internetowego będzie śledzony za pomocą mechanizmu
opartego o pliki Cookies, a zadaniem Wykonawcy jest stworzyć ten mechanizm i uczynić go
dostępnym dla partnerów Zamawiającego. Ponieważ nie będą zbierane dane osobowe, to śledzenie to
odbywać się będzie bez wiedzy i wyrażenia zgody internauty. Informacje jakie będą zbierane to:

Odwiedzane adresy URL

Data zdarzenia

Informacje regionalne (język i pochodzenie internauty) możliwe do wydobycia z przeglądarki
internetowej
5.5.2. Zapis do newslettera

System portalowy otrzymuje wygenerowane w systemie CRM login i hasło, aby korzystając z
nich wywoływać odpowiednie procedury po stronie systemu CRM. Wywołanie procedury
odbywa się przez wysłanie standardowego żądania POST protokołem HTTPS na odpowiedni
adres internetowy związany z systemem CRM. Zbiór dostępnych procedur (czyli API) musi
zawierać: Procedura aktualizacji danych turysty

Procedura zapisu do wskazanego newslettera

Procedura wypisania klienta ze wskazanego newslettera

Procedura pobrania listy newsletterów, do których portal może zapisać turystę
5.6. Architektura sprzętowa oraz systemowa.
5.6.1. Środowisko
W ramach przedmiotu zamówienia proponuje się pełną wirtualizacje systemów operacyjnych
(dynamiczny przydział procesorów, pamięci, kanałów dostępu do dysków i sieci). Dostarczony projekt
informatyczny musi uwzględniać taki sposób działania infrastruktury, aby awaria któregokolwiek z
serwerów (zarówno fizycznych jak i logicznych) obsługujących poszczególne warstwy Systemu CRM
nie miała wpływu na jego dostępność. Zakłada się dublowanie kluczowych elementów infrastruktury
tak, aby można było zmniejszyć ryzyko wystąpienia pojedynczej awarii, która uniemożliwi pracę
Systemu CRM.
System będzie składał się z trzech środowisk:
1) środowisko produkcyjne o najlepszych parametrach technicznych odpowiedzialne za stałe
utrzymanie ruchu połączeń,
2) środowisko testowe przeznaczone do testowania odbieranych poszczególnych funkcjonalności.
Środowisko będzie posiadało wszystkie komponenty jakie będą występować w środowisku
produkcyjnym jednak będzie też posiadało o wiele niższą moc obliczeniową.
3) środowisko zapasowe przeznaczone do przejęcia ruchu w przypadku awarii środowiska
produkcyjnego. Środowisko techniczne będzie posiadało 60% mocy obliczeniowej środowiska
produkcyjnego.
5.6.2. Licencjonowanie
Technologia zastosowana przy realizacji projektu nie wymaga zakupu licencji stanowiskowych.
Dostarczone licencje dla oprogramowania są bezterminowe, z możliwością 15 letniego wypowiedzenia
umowy licencji bezterminowej. Rodzaj wykupionej licencji musi być uwzględniony przez Wykonawcę w
taki sposób, aby było możliwe realizowanie czasu dostępności na poziomie określonym w umowie SLA.
5.6.3. Urządzenia peryferyjne
Aplikacja musi posiadać niezbędne interfejsy komunikacyjne do współpracy z urządzeniami
peryferyjnymi takimi jak np. drukarkaitp.
5.6.4. Gwarancja sprzętu
1. Gwarancja obejmuje pełny serwis oraz globalne wsparcie producenta przez minimum 36 miesięcy
dla dostarczonego przez Wykonawcę sprzętu. Termin gwarancji rozpoczyna się od dnia
następnego po dniu podpisania protokołu odbioru końcowego.
2. W okresie gwarancji Wykonawca zobowiązany jest, bez odrębnego wynagrodzenia, do
dostarczania
nowych
wersji
firmware,
sterowników,
oprogramowania
narzędziowego,
systemowego, oprogramowania pośredniczącego oraz uaktualnień oprogramowania (nośniki oraz
procedury instalacyjne wraz z opisem wprowadzonych zmian) do siedziby Zamawiającego.
3. W przypadku wystąpienia w ciągu pierwszego roku gwarancji: awarii, wady bądź usterki seryjnej
tych samych elementów lub podzespołów
dostarczonym sprzęcie danego typu, Wykonawca
zobowiązany jest na żądanie Zamawiającego, do wymiany elementu lub podzespołu na swój
koszt, w całym sprzęcie stanowiącym przedmiot zamówienia. Wymiana powinna zostać wykonana
w terminie do 2 tygodni od otrzymania żądania.
4. W okresie gwarancji Wykonawca nie może odmówić wymiany podzespołu na nowy, wolny od
wad,
w
przypadku
niewykonania
naprawy
w
terminie
30
dni
od
daty
zgłoszenia
wady/awarii/usterki lub ponownego wystąpienia wady/awarii/usterki tego samego podzespołu.
5. Naprawy będą wykonywane zgodnie z procedurami serwisowymi opracowanymi przez Wykonawcę
i zaakceptowanymi przez Zamawiającego.
6. Zapisane danymi Zamawiającego nośniki informacji mogą być naprawiane jedynie w miejscu
użytkowania, a w przypadku konieczności wymiany uszkodzonych nośników lub wymiany sprzętu
na nowy, wolny od wad, nośniki informacji nie podlegają zwrotowi do Wykonawcy.
7. Wykonawca obowiązany będzie prowadzić rejestr interwencji serwisowych i dostarczać
Zamawiającemu kwartalne raporty w formie pisemnej i na nośniku elektronicznym dotyczące
między innymi liczby interwencji, czasu naprawy, specyfikacji wymienionych lub naprawionych
elementów.
8. Wykonawca zobowiązany będzie do zagwarantowania, że wydajność każdego komponentu
infrastruktury systemu CRM nie przekroczy poziomu 80% maksymalnej, dostępnej wydajności po
wdrożeniu wszystkich usług systemu CRM wyspecyfikowanych w Załączniku nr 9 do Umowy
9. W przypadku przekroczenia progu wydajności komponentu wskazanego w ust. 8 Wykonawca
zobowiązany będzie do wymiany ww. komponentu na nowy, bardziej wydajny, w terminie
wskazanym przez Zamawiającego oraz nieodpłatne wykonanie wszystkich prac związanych z
przeniesieniem i dostosowaniem środowiska Platformy Integracyjnej i/lub Systemu Monitorowania
do nowego komponentu w terminie wskazanym przez Zamawiającego.
5.7. Wymagania dotyczące administracji systemem
Dostęp do systemu powinien być możliwy po zalogowaniu użytkownika i za pomocą
przeglądarki internetowej.
Polska Organizacja Turystyczna
AS 1.00
AS 1.01
AS 1.02
AS 1.03
Funkcjonalność
Wykonawca
SPEŁNIA
Lp.
Zamawiający
SYSTEM CRM
Uwagi
ADMINISTRACJA SYSTEMEM
Moduł administracyjny, do którego
dostęp mogą mieć tylko uprawnieni
2
użytkownicy – administratorzy
Moduł administracyjny systemu
powinien umożliwiać zarządzanie
2
użytkownikami, uprawnieniami,
dostępem oraz konfiguracją systemu
Panel logowania powinien być
dostępny po przez kanał SSL VPN.
administratorowi podgląd
użytkowników zalogowanych do
2
2
systemu
AS 1.04
AS 1.05
AS. 1.06
AS 1.07
AS 1.08
AS 1.09
AS 1.10
AS 1.11
AS 1.12
AS 1.13
administratorowi przeglądanie
historii logowania użytkowników
zarządzanie kontami użytkowników,
co najmniej w zakresie:
1/ dodawania/edycji/zablokowania
/usuwania konta użytkownika (login,
hasło, imię, nazwisko, email, telefon,
organizacja);
2/ ustawienia cyklicznej zmiany
hasła;
3/ ustawienia czasu ważności konta;
4/ ustawienia praw dostępu dla
użytkownika;
zarządzanie kontami użytkowników
zakresie wymuszenia konieczności
aktywacji konta przez
administratora.
udostępnianie danych wspólnych
grupom, dla których dane posiadają
wspólny identyfikator
dodawanie/edycję/usuwanie/
danych słownikowych
System powinien zapewnić zapis
historii zmian dodawania/ edycji/
usuwania/ podziału danych w
systemie
Możliwość wysyłania alertów
przypomnień powiązanych z
kalendarzami
Możliwość wysyłania alertów na
adresy pocztowe użytkowników
zdefiniowane w systemie
Możliwość zbierania statystyk z
użytkowania systemu
Tworzenie statystyk dotyczących
importu i eksportu danych
2
2
2
2
2
2
2
2
1
1
Tabela 5 Wymagania do administracji systemem.
5.8. Bezpieczeństwo systemu.
Wykonawca systemu powinien zwrócić szczególną uwagę na przygotowanie systemu pod
kątem zabezpieczeń, ze względu na wrażliwość przechowywanych danych w bazie danych systemu.
System powinien posiadać zabezpieczenia wynikające ze stanu prawnego, zgodnie z najlepszymi
praktykami stosowanymi na rynku. Wykonawca w ramach gwarancji będzie zapewniał monitorowanie
systemu pod kątem bezpieczeństwa.
Aplikacja musi mieć panel logowania, umożliwiający uwierzytelnianie osób korzystających z
systemu na podstawie nazwy użytkownika oraz hasła. Uwierzytelnianie użytkowników systemu po
winno odbywać się poprzez protokół LDAP, przy wykorzystaniu schematu SASL. Ponadto system
powinien mieć możliwość uwierzytelniania użytkowników poprzez loginy i hasła zapisane w bazie
systemu.
Wdrożone rozwiązania powinny posiadać następujące cechy:

autentyczność,

niezaprzeczalność,

poufność,

integralność,

dostępność,

rozliczalność.
W ramach projektowania procedur konieczne będzie zaimplementowanie niezbędnych mechanizmów
kontrolnych obejmujących m.in.:
1) Kontrolę dostępu do informacji, która będzie pozwalała na wyeliminowanie działania
użytkowników lub systemów, które byłyby szkodliwe dla systemu i organizacji. Występować będzie
szereg uprawnień do korzystania z danych, ich modyfikacji i usuwania. Dodatkowo przewiduje się
kontrolę dostępu innych systemów do danych. Wszystkie operacje dotyczące pracy użytkowników
lub innych systemów będą zapisywane. Dostęp do poszczególnych obiektów będzie podlegał
mechanizmowi dziedziczenia tzn. na podstawie relacji między obiektami posiadając prawa do
elementu nadrzędnego użytkownik lub system będzie miał nadane prawa do elementu
podrzędnego chyba, że zostaną mu one zabrane poprzez odpowiednie mechanizmy nadawania
uprawnień
2) Podział obowiązków - mechanizmy zatwierdzania transakcji przez osoby uprawnione.
3) Wykorzystanie
aplikacyjnych
mechanizmów
kontrolnych
-
zmniejszających
prawdopodobieństwo popełnienia błędu przez operatora poprzez zastosowanie odpowiednich
formatów danych, sum kontrolnych oraz
4) Audytowalność - mechanizmy przechowywania i archiwizacji logów z informacjami o dostępie
do systemu i realizowanych przez użytkowników transakcjach.
5) Integralność - każdy obiekt zapisany w systemie będzie zawierał informację dotyczące, kto i
kiedy je utworzył, edytował lub skasował.
6) Poufność - zostaną zastosowane metody kryptograficzne w celu zapewnienia poufności danych
przesyłanych między systemami. Sugerowane jest wykorzystanie protokołu TLS v 1.1 przy
komunikacji między węzłami systemu.
System CRM musi być odporny na ataki internetowe (łamanie haseł, ataki SQL injection, ataki
denial of service itp.). System CRM powinien być zabezpieczony przez masowym kopiowaniem
/eksportowaniem bazy danych do plików a także przed pobraniem masowym danych mimo
nieudostępniania takiej funkcjonalności poprzez interfejs użytkownika.
Kontrola dostępu do poszczególnych funkcjonalności w systemie powinna odbywać się na
podstawie ról, w zależności od zakresu obowiązków poszczególnych użytkowników. Rola są
przyznawane odpowiednie uprawnienia w systemie CRM. Role są przypisywane do odpowiadających
im użytkownikom, przez
co uzyskują oni dostęp do wykonywania określonych czynności
zdefiniowanych dla tych ról. System powinien spełniać następujący przydział uprawnień ze względu
na:
a) Użytkownik w wielu grupach,
b) Grupy użytkowników,
c) Zadania,
d) Grupy zadań,
e) Dostęp grupie użytkowników do zadań,
f) Dostęp grupie użytkowników do grupy zadań,
g) Dostęp pojedynczemu użytkownikowi do zadań,
h) Dostęp pojedynczemu użytkownikowi do grupy zadań,
i) Hierarchia grup (dziedziczenie)
System musi się opierać na następującej klasyfikacji użytkowników:
a.
Super-Administratorzy (tj. administratorzy o najwyższym poziomie uprawnień),
b.
Pracownicy,
c.
Pracownicy partnerów
Dostęp do danych w systemie powinien być określony na podstawie trzech atrybutów:
1. Atrybut do odczytu
2. Atrybut do zapisu
3. Atrybut wykonania
Zgodnie z wymogami bezpieczeństwa będą wykonywane kopie zapasowe systemu.
Wykonawca jest zobowiązany do skonfigurowania środowiska do tworzenia kopii zapasowej, w taki
sposób, aby była możliwość bezproblemowego zapisania jak i odtworzenia kopii zapasowej systemu
CRM.
BS 1.00
BS 1.01
BS 1.02
BS 1.03
BS 1.04
BS 1.05
BS 1.06
BS 1.07
Funkcjonalność
Wykonawca
SPEŁNIA
Lp.
Zamawiający
SYSTEM CRM
Uwagi
Bezpieczeństwo aplikacji
Konfiguracja długości minimalnej
i maksymalnej długości haseł
2
użytkownika.
Walidacja haseł niedopuszczalnych:
pustych, takich samych jak nazwa
2
użytkownika, których częścią jest
imię i nazwisko użytkownika.
Walidację minimalnych wymagań,
co do złożoności haseł: obecność
2
małych i wielkich liter, cyfr, znaków
specjalnych.
Możliwość konfiguracji, jako
parametru liczby dni, po której
1
wymusza jest zmiana hasła.
Przechowywanie hasła w postaci
2
niejawnej (hash +salt).
Zapisywanie historii operacji,
2
logowania, zdarzeń.
Rejestracja systemu dokonującego
zmiany w bazie CRM wraz z
2
informacją o lokalizacji sieciowej
(adres IP).
Zarządzanie użytkownikami,
dostępem i uprawnieniami dla
2
użytkowników poprzez moduł
administracyjny systemu.
BS 1.08
System powinien rozróżniać grupy
użytkowników
2
BS 1.09
dodawanie oraz modyfikacje
użytkowników, dodawanie oraz
zmianę uprawnień, definiowanie i
modyfikację ról i grup
2
użytkowników.
BS 1.10
BS 1.11
BS 1.12
BS 1.13
BS 1.14
BS 1.15
BS 1.16
BS 1.17
BS 1.18
BS 1.19
BS 2.00
System powinien rejestrować pełną
historię zmian dokonywanych w
ramach modułu zarządzania
użytkownikami, uprawnieniami i
dostępu, w szczególności
rejestrować historię zmian
uprawnień.
System powinien umożliwiać łatwą i
jednoznaczną identyfikację
użytkowników wykonujących
czynności w systemie.
odtworzenie pełnej historii
aktywności użytkownika w
dowolnym okresie czasu.
tworzenie wielu grup
użytkowników, ról.
nadawanie wielu ról jednemu
użytkownikowi poprzez
uczestnictwo w wielu grupach.
nadawanie dostępu do konkretnych
danych na poziomie zapisu, odczytu,
modyfikacji, usunięcia.
dokonywanie działań w systemie,
w szczególności zmian przez
nieuwierzytelnionych właściwie
użytkowników.
Spełnienie istotnych warunków
bezpieczeństwa zgodnie z
wymaganiami aktów prawnych, do
stosowania których jest zobowiązana
Polska Organizacja Turystyczna i jej
partnerzy.
System powinien być zabezpieczony
przed masowym eksportem danych
(w szczególności danych
osobowych).
Dostęp do panelu logowania
powinien odbywać się poprzez sieć
VPN (w tym SSL VPN).
2
2
1
2
2
2
2
2
2
2
Bezpieczeństwo integracji
System powinien posiadać
mechanizmy bezpieczeństwa
(kontrola dostępu do usług,
2
podpisywanie, szyfrowanie),
walidacja komunikatów przed ich
dostarczeniem do odbiorcy
BS 2.01
BS 2.02
BS 2.03
Zapewnienie możliwości dla
developera, przy zachowaniu
odpowiednich uprawnień i
ograniczeń z zachowaniem również
kontroli wersji i zasadami
uaktualnień na gorąco (ang. hot
deployment), modyfikacji definicji
usług, zasady transformacji
komunikatów, polityki
bezpieczeństwa dostępu
Zabezpieczenie transmisji danych
przy wykorzystaniu protokołu TLS v.
1.1
Uwierzytelnianie API poprzez
protokół OAuth 2.0
1
2
2
Kopia bezpieczeństwa
BS 2.11
Konfiguracja środowiska do
wykonywania kopii zapasowej
2
BS 2.12
Zapewnienie ciągłości pracy
środowiska przy wykorzystaniu
dostępnych technik
informatycznych w szczególności
poprzez zrównoważenie obciążenia
(load balancing), klaster
niezawodnościowy i etc.
2
Tabela 6 Wymagania bezpieczeństwa systemu.
6. Wygląd interfejsu użytkownika
Podstawowym wymaganiem do systemu jest zastosowanie odpowiednich reguł podczas jego
implementacji, które będą rzutowały na bezpieczeństwo systemu oraz na jego intuicyjność dla
użytkowników końcowych go obsługujących.
6.1. Użyteczność (Usability)
1. System powinien posiadać intuicyjny interfejs użytkownika systemu oraz współpracować z
nowoczesnymi przeglądarkami internetowymi, zgodnymi z ACID 3, na poziomie 100/100.
2. CRM musi zostać dokładnie przetestowany pod kątem wyświetlania oraz działania w przeglądarkach
różnych producentów, zgodnych z ACID 3, na poziomie 100/100. Aplikacja pod każdą z tych
przeglądarek musi prezentować się podobnie oraz działać poprawnie.
3. Wykonawca powinien zadbać o wtyczki stosowane w witrynie. Aplikacja powinna wykorzystywać
standardowe wtyczki zainstalowane w przeglądarce. Niedopuszczalne jest tworzenie niestandardowych
wtyczek.
4. Rozdzielczość monitora nie powinna mieć znaczącego wpływu na wyświetlanie aplikacji. Aplikacja
powinna automatycznie dostosowywać swój rozmiar do wykrytej rozdzielczości monitora.
5. Stosowanie ikon zamiast przycisków – wszystkie przyciski mają formę opisu tekstowego. Część z
nich może zostać zastąpiona jasno zrozumiałymi ikonami (np. znak drukarki zamiast przycisku
„Drukuj”), aby zachować przejrzystość strony.
6. Sprawne drukowanie zawartości stron - zalecane jest utworzenie dwóch wersji szablonów stron –
jednego dla wyświetlania treści na ekranie, drugiego w układzie dostosowanym do wydrukowania.
Wersje stron przeznaczone do druku powinny być pozbawione wszelkich zbędnych elementów, takich
jak pasek nawigacji, wyszukiwarka, elementy interaktywne itp.
7. Teksty aplikacji muszą być prezentowane przy uwzględnieniu optymalnego kroju czcionki, jej
rozmiaru oraz kolorystyki. Nie należy stosować więcej niż dwóch krojów czcionki na jednej stronie.
8. Układ graficzny aplikacji CRM powinien zostać dostosowany zgodnie z księgą identyfikacji wizualnej
zamawiającego.
Logotypy POT muszą zostać umieszczone w widocznym miejscu z zachowaniem
wymaganej wielkości. Strony aplikacji powinny zapewniać bezpośredni dostęp
do strony internetowej organizacji, czyli Zamawiającego. Optymalnym rozwiązaniem jest standardowe
umieszczenie odnośnika w logo organizacji.
9. Nie należy duplikować funkcjonalności przeglądarek internetowych poprzez np. wstawianie
dodatkowych przycisków umożliwiających ustawienie aplikacji, jako strony startowej czy też dodanie
jej do zakładek.
10. Zastosowane na stronie głównej style elementów tekstowych powinny być w takiej tonacji, aby nie
zlewały się one z elementami graficznymi. Zaleca się stosowanie wysoce kontrastowej kolorystyki dla
prezentacji najważniejszych elementów. Nie powinno się natomiast stosować elementów graficznych
rozpraszających uwagę użytkownika.
11. Nie należy rezygnować ze stosowania ekranów powitalnych. Konieczne jest przygotowanie strony
przedstawiającej
komunikat
techniczny
informujący
o
wystąpieniu
problemu
technicznego
uniemożliwiającego działanie aplikacji oraz przewidywanym czasie jego rozwiązania.
Strona powinna być zaprojektowana w ten sposób, aby nie wymagała przewijania w poziomie.
Uniknięcie przewijania w pionie jest często niemożliwe, ważne jest zatem, aby elementy najważniejsze
znajdowały się powyżej linii przewijania, zaś elementy mniej ważne pod nią.
12. Minimalizowanie ilości zbędnych elementów witryny. Zgodnie z tą zasadą proponuje się
ograniczoną
zawartość
menu
oraz
niewielką
liczbę
elementów
na
stronie,
w celu zachowania jej przejrzystości. Najważniejsze zadania witryny powinny być przedstawione w
elementach menu.
GUI 1.00
GUI 1.01
GUI 1.02
GUI 1.03
GUI 1.04
GUI 1.05
GUI 1.06
Funkcjonalność
Wykonawca
Spełnia
Lp.
Zamawiający
SYSTEM CRM
Uwagi
ERGONOMIA INTERFEJSU UŻYTKOWNIKA
Graficzny interfejs użytkownika (GUI)
systemu będzie dostępny za
2
pośrednictwem przeglądarki
internetowej.
Graficzny interfejs użytkownika
będzie przystosowany do
wyświetlenia na urządzeniach
1
mobilnych (tablety, telefony
komórkowe).
Interface web musi być poprawnie
interpretowany i wyświetlany przez
nowoczesne przeglądarki
2
internetowe zgodne z ACID 3, na
poziomie 100 / 100.
Poszczególne moduły systemu
powinny posiadać przejrzyste i
2
logiczne menu, jednolite rozwiązania
graficzne
Tworzenie
wyświetlanych/drukowanych danych
Logiczne, przejrzyste i zwięzłe
komunikaty o błędach na poziomie
użytkownika
Polskojęzyczny interfejs użytkownika
i administratora
2
2
2
GUI 1.07
Interfejs użytkownika i
administratora w wersji angielskiej
1
GUI 1.08
Dostęp do pomocy kontekstowej dla
użytkownika na wszystkich ekranach
2
Tabela 7 Wymagania ergonomii interfejsu użytkownika.
7. Utrzymanie systemu
7.1. Zakres i metoda świadczenia usługi asysty
technicznej
1. Wykonawca musi zapewnić Zamawiającemu możliwość całodobowego składania zleceń
serwisowych (incydentów) z siedziby Zamawiającego.
2. Pod nadzorem Zamawiającego przez okres jednego roku od daty zakończenia Etapu IV
umowy Wykonawca musi świadczyć usługi, objęte metodyką ITIL w zakresie realizacji
procesów:
a. utrzymania działania operacyjnego (ang. Operations)
b. wsparcia technicznego (ang. Technical Support) w zarzadzaniu dostarczonego
wdrożonego oprogramowania (w tym również serwisowania przez okres 36 miesięcy
wdrożonego
sprzętu
oraz
oprogramowania
narzędziowego,
systemowego,
pośredniczącego
3. Do rozwiązania problemu dopuszcza się zastosowanie przez Wykonawcę obejścia problemu
(ang. work-around) przywracającego wymaganą funkcjonalność rozwiązania. Jednakże w
takim przypadku Wykonawca w terminie 31 dni od dnia realizacji obejścia problemu jest
zobowiązany do przeprowadzenia pełnej naprawy rozwiązania.
4. W przypadku awarii części sprzętowej rozwiązania Wykonawca musi dostarczyć sprzęt
zastępczy o parametrach nie gorszych niż sprzęt podstawowy do momentu przywrócenia
sprawności sprzętu podstawowego.
5. W trakcie okresu świadczenia usług zarządzania infrastrukturą i oprogramowania Wykonawca
musi przygotować pracowników Zamawiającego do samodzielnego wykonywania, po ustaniu
okresu świadczenia usług przez Wykonawcę, wszelkich niezbędnych czynności w tym zakresie.
6. Wykonawca
musi
udostępnić
Zamawiającemu
do
końca
okresu
gwarancyjnego
oprogramowanie wspierające wdrożone procesy Zarządzania Usługami oraz Zarządzania
Infrastrukturą. (np. Service Desk).
7.2. Gwarancja oprogramowania
Wykonawca w ramach gwarancji powinien zapewniać aktualizację oprogramowania CRM oraz
wszelkich
komponentów
oprogramowania
(w
szczególności
systemu
bazowego
na
którym
zainstalowany jest CRM, oprogramowania bazy danych).Wykonawca zobowiązuje się do wdrożenia
krytycznych aktualizacji zabezpieczeń nie później niż 7 dni roboczych od daty ich wydania, po
uprzednim ich przetestowaniu i dostarczeniu raportów z testów Zamawiającemu. Szczegóły dotyczące
gwarancji znajdują się w załączniku nr Umowa SLA oraz Istotne Postanowienia Umowy.
USC 1.00
USC 1.01
USC 1.02
USC 1.03
USC 1.04
USC 1.05
Funkcjonalność
Wykonawca
Spełnia
Lp.
Zamawiający
SYSTEM CRM
Uwagi
UTRZYMANIE SYSTEMU CRM
Usługi gwarancyjne na poprawne
funkcjonowanie aplikacji na okres 12
miesięcy od dnia podpisania
2
protokołu odbioru końcowego
aplikacji
Pomoc w wypadku trudności z
wykonaniem prac operatorskich w
2
systemie
Pomoc w zakresie rozwiązywania
bieżących problemów i obsługi
2
systemu
Pomoc w diagnostyce problemów
2
związanych z działaniem aplikacji
Zapewnienie poprawnego działania
aplikacji i usuwania wad aplikacji, w
2
tym napraw błędów, usterek i awarii
krytycznych
W przypadku awarii serwera
odtworzenie systemu na inny serwer
2
pod warunkiem otrzymania nośnika z
USC 1.06
USC 1.07
USC 1.08
USC 1.09
USC 1.10
USC 1.11
USC 1.12
USC 1.13
USC 1.14
USC 1.15
USC 1.16
USC 1.17
USC 1.18
USC 1.19
aktualną, poprawną kopią danych
Możliwość wykonywania za
pośrednictwem Internetu naprawy
usterki i awarii krytycznej
bezpośrednio po ustaleniu jego
przyczyny i wykonanie korekty
oprogramowania
Wdrożenie aktualizacji systemu w
sposób niezakłócający bieżącego
użytkowania systemu
Aktualizacja dokumentacji
konfiguracji i użytkowej
Przedstawienie wyceny prac w ciągu
7 dni od ich zgłoszenia, wycena
powinna definiować jednoznaczny
zakres prac, pracochłonność ich
realizacji i wycenę
Przedstawienie wyceny prac
dodatkowych z pomocą
sformalizowanych metod wyceny np.
metodyka punktów funkcyjnych
Aktualizacja systemu do
obowiązujących przepisów prawa z
wyprzedzeniem co najmniej 3 dni
przed wejściem obowiązujących
przepisów
Prowadzenie prac rozwojowych
mających na celu modernizację
aplikacji oraz usprawnienie jego
funkcji
Monitoring pod kątem
występowania błędów
Zapewnienie zgodności aplikacji z
obowiązującymi przepisami
obowiązującymi na ternie RP oraz UE
Dostarczanie aktualizacji aplikacji
obejmujących wyeliminowanie
usterek i dostosowanie do
obowiązujących przepisów
Dla wdrożonych w ramach
zamówienia usług Wykonawca musi
udokumentować i wdrożyć
efektywne i zgodne z podejściem ITIL
procesy Zarządzania Usługami IT
(ang. IT Service Management)
PRACE ROZWOJOWE
Dostępność kodu źródłowego
Możliwość prowadzenia prac
rozwojowych przez dowolnych,
zewnętrznych dostawców
INTEGRACJA
System IBM SPSS
2
1
2
2
1
2
2
2
2
2
1
2
2
2
USC 1.20
USC 1.21
USC 1.22
USC 1.23
USC 1.24
USC 1.25
System Contact Center
systemami portalowymi (w
szczególności Narodowy Portal
Turystyczny, portale turystyczne
partnerów Zamawiającego),
SOCIAL MEDIA
portalami typu Social Media takimi
jak np. Facebook, Google +, Twitter.
Generowanie odnośników do
pojedynczych stron www z
newsletterem, umieszczanych na
oficjalnych profilach
społecznościowych Zamawiającego,
Formularz zapisu do Newslettera
(CRM) wystawiony na portalu
społecznościowym Facebook
Możliwość dzielenia się
newsletterem ze znajomymi poprzez
ikony typu „podziel się”
2
2
2
2
2
2
Tabela 8 Utrzymanie systemu.
8. Szkolenia
Wykonawca w ramach realizacji przedmiotu Zamówienia zobowiązany jest do przeszkolenia
użytkowników w zakresie użytkowania i eksploatacji systemu.
1) Szkolenie dla 2 administratorów wytypowanych przez Zamawiającego do obsługi technicznej
w zakresie pozwalającym na uruchomienie i administrowanie Systemem CRM, w tym szkolenie
z integracji kolejnych systemów współpracujących z Systemem CRM. Ukończenie szkolenia
będzie potwierdzone certyfikatem ukończenia szkolenia wystawionym przez Wykonawcę, w
przypadku gdy System CRM oraz wchodzące w jego skład oprogramowanie będzie wyłącznie
jego dziełem i własnością, zaś w przypadku, gdy do wytworzenia Systemu CRM zostanie użyte
oprogramowanie nie będące dziełem lub własnością Wykonawcy certyfikat będzie wystawiał
producent danego oprogramowania lub w imieniu producenta oprogramowania Wykonawca.
W przypadku, gdy System CRM będzie składał się z oprogramowania różnych producentów
zakres certyfikowanego szkolenia zostanie uzgodniony z Zamawiającym;
2) Szkolenia prowadzone będą przez wykładowców certyfikowanych w zakresie produktów
stanowiących przedmiot szkolenia.
3) Dopuszczalne jest, aby szkolenia były wykonane przez pracowników Wykonawcy w przypadku,
gdy wdrażany odpowiednik typu OpenSource nie ma odpowiednika komercyjnego.
4) W przypadku wdrożenia oprogramowania typu OpenSource, dla którego istnieje odpowiednik
komercyjny Wykonawca będzie musiał przeprowadzić autoryzowane szkolenia związane z
komercyjnym jego odpowiednikiem.
5) Weryfikacją uzyskanej wiedzy ze szkolenia dla 4 administratorów będzie egzamin, którego
zaliczenie spowoduje uzyskanie dodatkowego certyfikatu producenta oprogramowania
potwierdzającego wiedzę na odpowiednim poziomie;
6) Wykonawca przeszkoli administratorów w zakresie wdrażania i eksploatacji.
Szkolenia
powinny objąć w szczególności:
a) Instalację, ładowanie danych i testy po instalacyjne,
b) Konfigurację,
c) Archiwizację,
d) Backup i restore,
e) Administrowanie systemami i bazami danych stanowiących platformę systemu,
f)
Procedury wdrażania i eksploatacji systemu,
g) Procedury wspierania procesów biznesowych Klienta,
7) szkolenie trenerskie dla 10 użytkowników końcowych Zamawiającego wytypowanych do
obsługi systemu CRM. Zakres szkolenia obejmuje pełną obsługę systemu przez użytkowników
końcowych, w tym szkolenie dla 3 użytkowników obejmujących administrację systemem CRM
przez administratorów regionalnych.
8) Szkolenia będą się odbywały w miejscu wyznaczonym przez Wykonawcę po uprzednim
uzgodnieniu oraz pisemnej akceptacji przez Zamawiającego;
9) Na czas szkoleń Wykonawca zagwarantuje pomieszczenie wraz z projektorem multimedialnym
oraz ze stanowiskami komputerowymi dla wszystkich osób biorących udział w szkoleniu,
10) Wykonawca
zapewni
materiały
szkoleniowe
w
postaci
materiałów
piśmienniczych,
niezbędnych materiałów szkoleniowych takich jak: instrukcji użytkowania systemu CRM,
administracji systemem CRM dla pracowników eksploatacji i utrzymania w wersji papierowej
oraz elektronicznej,
11) Materiały szkoleniowe swoją treścią będą odpowiadały zakresowi szkolenia. Materiały zostaną
przygotowane w formie oprawionych wydruków komputerowych oraz w formie elektronicznej
w postaci prezentacji multimedialnych na płytach CD Materiały zostaną opracowane w języku
polskim. W okresie objętym gwarancją, po każdej zmianie w systemu, wykonawca będzie
zobowiązany do uaktualnienia i dostarczenia nowych wersji materiałów szkoleniowych
uwzględniających dokonane zmiany.
12) Zamawiający dopuszcza
organizowanie szkoleń w mniejszych grupach osób, o liczbie nie
mniejszej niż 6 osób na grupę, przy czym Wykonawca jest zobowiązany do przedstawienia
harmonogramu szkolenia z podziałem na liczbę osób oraz liczbę grup.
13) Każdy z uczestników szkolenia trenerskiego otrzyma certyfikat ukończenia szkolenia,
wystawiony przez Wykonawcę.
9. Warunki SLA.
1. Usługi
Na potrzeby określenia jakości świadczenia usług, w ramach niniejszej umowy definiuje się
następującą usługę dostępu do Systemu, którą Wykonawca świadczy na rzecz Zamawiającego.
„Dostęp do Systemu” rozumiany jako realizacja przez CRM wszystkich funkcjonalności zgodnie
z zatwierdzoną dokumentacją oraz obowiązującym prawem. Warunki SLA obowiązują od momentu
zakończenia trzymiesięcznej asysty Systemu w siedzibie Zamawiającego w pierwszym okresie
eksploatacji produkcyjnej.
2. Podstawowe parametry i zakres usług
2.1.
Usługi będą świadczone w dni robocze tj. od poniedziałku do piątku w godzinach 8-18
2.2.
Zakres usługi „dostęp do Systemu”:
2.2.1.
zapewnienie funkcjonowania Systemu, w tym zapewnienie bezpieczeństwa, asysty
technicznej, aktualizacji oraz rozbudowy oprogramowania narzędziowego i infrastruktury
systemowej,
2.2.2.
wykonanie oraz instalacja nowych wersji modułów, systemów, funkcjonalności Systemu
zgodnie z ustalonym harmonogramem zmian po zaakceptowaniu wyników testów
akceptacyjnych przez Zamawiającego,
2.2.3.
diagnostyka, optymalizacja i usuwanie błędów Systemu oraz świadczenie pomocy
Zamawiającemu w zakresie obsługi Systemu,
2.2.4.
utrzymanie pełnej dokumentacji niezbędnej do prawidłowej eksploatacji i serwisu Systemu
oraz udostępnianie jej Zamawiającemu,
2.3.
Wykonawca ma prawo do korzystania z okien serwisowych, na potrzeby wykonywania
niezbędnych prac serwisowych. Okna serwisowe mogą być realizowane jeden raz w
miesiącu oraz dodatkowo dwa razy w ciągu roku (tzn. łącznie 14 okien serwisowych w
ciągu
12-stu
kolejnych
miesięcy
świadczenia
usług),
w
godzinach
20.00-6.00.
Wykonawca, z co najmniej 5-dniowym wyprzedzeniem będzie każdorazowo informował
pisemnie Zamawiającego o zamiarze wykorzystania Okna serwisowego. Czas trwania
okien serwisowych nie wlicza się do czasu świadczenia usług. Podczas trwania prac w
czasie okna serwisowego Wykonawca zapewni publikację pod adresami internetowymi
Systemu komunikatu o trwających pracach serwisowych.
2.4.
W przypadku konieczności wprowadzania uzgodnionych przez Strony zmian w Systemie,
Strony mogą uzgodnić dodatkowe okna serwisowe, poza wymienionymi w pkt. 2.3. Czas
ich trwania nie będzie wliczony do czasu świadczenia usług.
3. Parametry jakości świadczenia usługi
LP
Opis parametrów
Poziom Jakości
Częstotliwość
Usług
mierzenia
95%
Miesięczna
Dostępność usługi „dostęp
1.
do
Systemu”
w
ciągu
jednego miesiąca
Maksymalny czas trwania
2.
jednorazowej
niedostępności
usługi
4 godz.
Przy
każdorazowym
wystąpieniu zdarzenia
„dostęp do Systemu”
Czas generowania strony
3.
(z
wyłączeniem
zawierających
stron
statystyki,
< 4 sekund
Miesięczna
< 10 sekund
Miesięczna
< 3 sekund
Miesięczna
raporty)
4.
5.
3.1.
Czas generowania wyniku
zapytania
Czas
przejścia
pomiędzy
stronami
Wykonawca
jest
zobowiązany
do
opracowania
niezbędnych
mechanizmów
oraz
dostarczenia narzędzi umożliwiających monitorowanie i raportowanie parametrów jakości
świadczenia usług.
3.2.
Na potrzeby oceny jakości świadczenia usług przyjmuje się następujące założenia:
3.2.1.
w ciągu 1 dnia roboczego dopuszcza się, że 5% generowanych stron przekroczy o nie
więcej niż 200% maksymalny czas generowania strony;
3.2.2.
w ciągu 1 dnia roboczego dopuszcza się, że 2% przejścia pomiędzy stronami przekroczy o
nie więcej niż 200% maksymalny czas przejścia pomiędzy stronami.
4. Usługi serwisowe
4.1.
Wykonawca będzie świadczył usługę obsługi zgłoszeń serwisowych Zamawiającego w dni
robocze tj. od poniedziałku do piątku w godzinach 8-18
4.2.
Obsługa zgłoszeń serwisowych będzie realizowana za pośrednictwem:

telefonu, pod numerem ………

poczty elektronicznej, pod adresem ……

faksu, pod numerem ………

narzędzia do obsługi zleceń serwisowych dostarczonego przez Wykonawcę
4.3.
Za moment zgłoszenia przyjmuje się odpowiednio:

datę i godzinę zakończenia rozmowy telefonicznej,

datę i godzinę wysłania wiadomości e-mail,

datę
i
godzinę
wysłania
faksu
(potwierdzoną
standardowym
wydrukiem
z
faksu
Zamawiającego).
Szczegółowe zasady obsługi zgłoszeń serwisowymi określone są w pkt. 9
4.4.
Nieprawidłowe działanie usług określa się jako:

Awarię krytyczną – tzn. każdy incydent powodujący niedostępność usługi,

Usterkę – tzn. pozostałe incydenty związane ze świadczeniem usług, nie powodujące jednak
niedostępności usług.
4.5.
Wykonawca gwarantuje następujące czasy reakcji dla usług i kategorii zgłoszeń
serwisowych:
Uciążliwość
(severity)
Wpływ
usługi
na
proces
biznesowy
Maksymalny
Maksymalny
czas
czas reakcji
usunięcia
awarii
Poziom
1
(Krytyczny)
Krytyczny,
4 godziny
wymagający
8
godzin
roboczych
natychmiastowego
rozwiązania.
Poziom 2
(Normalny)
Znaczący,
rozwiązanie
jest
użyteczne,
ale
8 godzin
3 dni robocze
24 godziny
10
jego
funkcjonalność
jest
znacząco
ograniczona.
Poziom 3
(niski)
Nieznaczny,
rozwiązanie
jest
użyteczne,
ale
dni
roboczych
jego
funkcjonalność
jest ograniczona.
4.6.
Wykonawca gwarantuje w przypadku Awarii Krytycznej (poziom 1) czasy naprawy nie
dłuższy niż 8 godzin roboczych
4.7.
Wykonawca gwarantuje w przypadku usterek zwyczajnych
(Poziom 2) czas naprawy nie dłuższy niż 3 dni robocze.
4.8.
Wykonawca gwarantuje w przypadku usterek o niskiej uciążliwości(Poziom 3) czas
naprawy nie dłuższy niż 10 dni roboczych.
5. Do rozwiązania problemu dopuszcza się zastosowanie przez Wykonawcę obejścia problemu
(ang. work-around) przywracającego wymaganą funkcjonalność rozwiązania. Jednakże w takim
przypadku Wykonawca w terminie 31 dni od dnia realizacji obejścia problemu jest zobowiązany
do przeprowadzenia pełnej naprawy rozwiązania.
7. W okresie gwarancji Wykonawca zobowiązany jest, bez odrębnego wynagrodzenia, do
dostarczania nowych wersji oprogramowania a w szczególności: firmware, biosu, sterowników,
oprogramowania
narzędziowego,
oprogramowania
pośredniczącego,
oprogramowania
systemowego oraz uaktualnień oprogramowania użytkowego (nośniki oraz procedury instalacyjne
wraz z opisem wprowadzonych zmian) do siedziby Zamawiającego.
8. W przypadku wystąpienia w ciągu pierwszego roku gwarancji: awarii, wady bądź usterki seryjnej
tych samych elementów lub podzespołów
dostarczonym sprzęcie danego typu, Wykonawca
zobowiązany jest na żądanie Zamawiającego, do wymiany elementu lub podzespołu na swój
koszt, w całym sprzęcie stanowiącym przedmiot zamówienia. Wymiana powinna zostać wykonana
w terminie do 2 tygodni od otrzymania żądania.
9. W okresie gwarancji Wykonawca nie może odmówić wymiany podzespołu na nowy, wolny od
wad,
w
przypadku
niewykonania
naprawy
w
terminie
30
dni
od
daty
zgłoszenia
wady/awarii/usterki lub ponownego wystąpienia wady/awarii/usterki tego samego podzespołu.
10. Naprawy będą wykonywane zgodnie z procedurami serwisowymi opracowanymi przez Wykonawcę
i zaakceptowanymi przez Zamawiającego.
11. Zapisane danymi Zamawiającego nośniki informacji mogą być naprawiane jedynie w miejscu
użytkowania, a w przypadku konieczności wymiany uszkodzonych nośników lub wymiany sprzętu
na nowy, wolny od wad, nośniki informacji nie podlegają zwrotowi do Wykonawcy.
12. Wszystkie wykonane przez Wykonawcę interwencje serwisowe dla dostarczonej infrastruktury
sprzętowej wykonywane w ramach umowy wymagają dokumentacji w formie pisemnej na
formularzach: „Zgłoszenie awarii”, którego wzór stanowi Załącznik nr 13 do umowy oraz “Protokół
z naprawy”, którego wzór stanowi Załącznik nr 14 do umowy.
13. Wykonawca obowiązany będzie prowadzić rejestr interwencji serwisowych i dostarczać
Zamawiającemu kwartalne raporty w formie pisemnej i na nośniku elektronicznym dotyczące
między innymi liczby interwencji, czasu naprawy, specyfikacji wymienionych lub naprawionych
elementów.
14. Wykonawca zobowiązany będzie do zagwarantowania, że wydajność każdego komponentu
infrastruktury nie przekroczy poziomu 80% maksymalnej, dostępnej wydajności po wdrożeniu
wszystkich usług systemu CRM wyspecyfikowanych w Załączniku nr do Umowy.
15. W przypadku przekroczenia progu wydajności komponentu wskazanego w ust. 8 Wykonawca
zobowiązany będzie do wymiany ww. komponentu na nowy, bardziej wydajny, w terminie
wskazanym przez Zamawiającego oraz nieodpłatne wykonanie wszystkich prac związanych z
przeniesieniem i dostosowaniem środowiska CRM i innych komponentów oprogramowania w
terminie wskazanym przez Zamawiającego.
16. Wykonawca obowiązany będzie do udzielenia 12 miesięcznej gwarancji na wszystkie wykonane
zgodnie z §
Umowy usługi. Termin gwarancji rozpoczyna się od daty zakończenia realizacji
modyfikacji na zasadach ustalonych dla Etapu IV
14. W
ramach
usług
serwisowych
Wykonawca
zobowiązany
jest
do,
aktualizacji
wersji
oprogramowania urządzeń oraz zmiany konfiguracji urządzeń, w zakresie niezbędnym do
zapewnienia świadczenia usług na poziomie jakości określonym w niniejszym dokumencie oraz
zapewnienia odpowiedniego poziomu bezpieczeństwa.
15. Wszelkie koszty logistyczne związane z zapewnieniem właściwego poziomu świadczenia usługi
ponosić będzie Wykonawca.
15.1.
W ramach usług serwisowych Wykonawca jest zobowiązany do utrzymania pełnej
dokumentacji niezbędnej do prawidłowej eksploatacji i serwisu Systemu oraz udostępnianie
jej Zamawiającemu.
15.2.
W
ramach
usług
serwisowych
Wykonawca
będzie
również
udzielał
konsultacji
Zamawiającemu w zakresie związanym z przedmiotem umowy. Konsultacji będą udzielać
eksperci Wykonawcy. Konsultacje będą realizowane za pośrednictwem:

telefonu, pod ogólnopolskim numerem ….

poczty elektronicznej, pod adresem …….

bezpośrednio w siedzibie Zamawiającego.
Zamawiający będzie zgłaszał potrzebę konsultacji bezpośrednich (w siedzibie Zamawiającego) na
co najmniej 3 dni robocze wcześniej.
Wykonawca ma obowiązek udzielić konsultacji w terminie nie dłuższym niż 3 dni robocze od dnia
przekazania zapytania telefonicznego, lub pocztą elektroniczną.
16. Raportowanie
16.1.
Do obowiązków Wykonawcy należy ciągłe monitorowanie, pomiar i rejestrowanie
parametrów jakości świadczenia usług.
16.2.
Wykonawca będzie również monitorował, mierzył i rejestrował parametry jakości usług
serwisowych.
16.3.
Wykonawca ma obowiązek przesyłać Zamawiającemu do 20 dnia następnego miesiąca
raporty SLA, określające poziom świadczenia usług w danym miesiącu. Raporty te będą
dostarczane do siedziby Zamawiającego. Raporty będą podstawą do wyliczania kar
umownych w sposób określony w pkt. 6.
16.4.
Raport jakości usług serwisowych musi zawierać co najmniej następujące informacje:

ilość zleceń serwisowych zgłoszonych w danym miesiącu w poszczególnych kategoriach,

średni
czas
reakcji
dla
zleceń
zgłoszonych
w
danym
miesiącu,
w poszczególnych kategoriach,

wykaz zleceń, dla których przekroczony został czas reakcji wraz z informacją o wielkości
opóźnienia,

średni czas naprawy dla zleceń zgłoszonych w danym miesiącu, w poszczególnych
kategoriach,

wykaz zleceń, dla których przekroczony został czas naprawy wraz z informacją o wielkości
opóźnienia,

wykaz zrealizowanych w danym miesiącu konsultacji, wraz z informacją o terminie udzielania
konsultacji i wskazaniem przypadków, dla których przekroczono termin określony w
………………
Szczegółowy wzór raportu strony ustalą do dnia ………………….
16.5.
Wykonawca zapewni dostęp do systemu monitorującego parametry jakości świadczenia
usług, dla maksymalnie 5-ciu wyznaczonych pracowników Zamawiającego.
10. Szczegółowe zasady obsługi zgłoszeń
serwisowych muszą być zgodne z systemem
praktyk Biblioteki ITIL - Zarządzanie
Usługami IT (ang. IT Service Management):
Wsparcia Usług (ang. Service Support):
a) zarządzania incydentami (ang. Incident Management),
b) zarządzania problemami (ang. Problem Management),
c) zarządzania zmianami (ang. Change Management),
d) zarządzania wydaniami (ang. Release Management),
e) zarządzania konfiguracją (ang. Configuration Management),
f) działania operacyjnego (ang.Operations).
11. Testy akceptacyjne
Zamawiający wymaga zastosowania następującej kategorii i klasyfikacji błędów dla testów
dostarczonego w ramach postępowania rozwiązania:
Błąd klasy A (Critical –
dla błędów
Dla błędu zidentyfikowanego na środowisku produkcyjnym:
Błąd, któremu towarzyszy wystąpienie co najmniej jednego
występujących na
środowisku
produkcyjnym)
z następujących objawów:

niedostępność systemu lub interfejsu

brak możliwości realizacji podstawowego procesu
biznesowego dla danego projektu

niespełnienie wymagań wydajnościowych w zakresie
jednego lub więcej podstawowych procesów biznesowych
(dotyczy testów wydajnościowych)
Dla błędu występującego na środowisku produkcyjnym (w trakcie
Stabilizacji):
(Critical) Błąd, któremu towarzyszy wystąpienie co najmniej jednego
Błąd klasy B (High – dla
błędów występujących
na środowisku
produkcyjnym)

odczuwalne zachwianie dostępności, stabilności lub
wydajności co najmniej jednego składnika funkcjonalnego
Systemu;

podwyższona ważność biznesowa dla zidentyfikowanego
zaburzenia funkcjonalności Systemu;

utrata Danych lub naruszenie ich spójności.

niedostępność bądź istotna wada w działaniu jednej (lub
więcej) kluczowych funkcjonalności systemu

brak możliwości realizacji lub krytyczny błąd w realizacji
procesu biznesowego

niespełnienie wymagań wydajnościowych dla dowolnego
procesu biznesowego (dotyczy testów wydajnościowych)
Stabilizacji):
(High) Błąd, któremu towarzyszy ograniczenie realizacji lub uciążliwość
(spowolnienie) realizacji co najmniej jednej z funkcji Systemu.
Błąd klasy C (Medium –
dla błędów
występujących na
środowisku
produkcyjnym)
z następujących objawów (ale możliwe jest obejście błędu):
1.
niedostępność bądź wada w działaniu funkcjonalności
systemu,
2.
błąd w realizacji procesu biznesowego
Stabilizacji):
Oznacza zakłócenie pracy Systemu mogące mieć wpływ na funkcjonalność
Systemu, natomiast nie ograniczające zdolności operacyjnych Systemu.
Błąd klasy D (Low - dla
błędów występujących
na środowisku
produkcyjnym)
z następujących objawów (ale możliwe jest obejście błędu):

wpływ na funkcjonalność, nie ograniczający zdolności
operacyjnych systemu

utrudnienie w obrębie obsługi lub wspomagania procesu
biznesowego nie ograniczające możliwości jego realizacji

uciążliwe dla użytkownika spowolnienie działania Systemu,
nie ograniczające możliwości realizacji jego funkcji zgodnie
lub nieoptymalne wydajnościowo przetwarzanie procesu
biznesowego w obrębie Systemu lub w komunikacji
międzysystemowej (dotyczy testów wydajnościowych)
Stabilizacji):
Każdy inny Problem nie wymieniony w kategorii A, B i C.
Tabela 9 Kategoria i klasyfikacja błędów
Scenariusze do testów akceptacyjnych powinny zostać opracowane przez Wykonawcę, w
uzgodnieniu z Zamawiającym. Przy opracowywaniu scenariuszy testowych należy przyjąć
następującą klasyfikację:
1. Priorytet 1 – scenariusze dotyczące kluczowych funkcjonalności, weryfikujące głównie
pozytywne warunki testowe
2. Priorytet 2 – scenariusze dotyczące funkcji ważnych biznesowo oraz uwzględniające przebiegi
negatywne i alternatywne dla funkcji kluczowych
3. Priorytet 3 – scenariusze dotyczące mniej ważnych funkcjonalności.
Dokument wymagań testów akceptacyjnych
Wykonawca dostarczy dokument zawierający zobowiązanie do dotrzymania następujących standardów
i wymagań odnośnie testów akceptacyjnych:
a) Wyniki testów akceptacyjnych mogą być użyte do weryfikacji wyników innych testów,
unieważniając tym samym decyzje podjęte na ich podstawie.
b) Spełnienie lub niespełnienie kryteriów akceptacji rozstrzygane jest w trakcie testów
akceptacyjnych, a nie podczas innych przedsięwzięć.
c) W przygotowaniu scenariuszy testów akceptacyjnych mogą uczestniczyć reprezentanci
użytkowników końcowych i ich partnerów.
d) Obsługa incydentów i problemów podczas testów akceptacyjnych powinna być realizowana
przez Help Desk Wykonawcy.
e) Podczas testów akceptacyjnych obowiązuje interpretacja kryteriów akceptacji i wyników
testów zgodna z interpretacją Klienta eksploatacji.
f)
Scenariusze testów akceptacyjnych odpowiadają działaniom w środowisku Klienta eksploatacji,
które zostało zmienione wskutek wdrażania systemu.
g) Testowanie powinno być wykonywane przez osoby przeszkolone zgodnie z planem wdrożenia.
h) Pozytywne wyniki testów akceptacyjnych powinny zostać potwierdzone w warunkach
eksploatacji.
i)
Testy akceptacyjne powinny objąć pełen zakres testów czarnej skrzynki i nie mogą
obejmować debuggowania, ponadto musi być przewidziana próbna eksploatacja i ocena usług
przez Klienta eksploatacji.
j)
W zakres testów akceptacyjnych powinno wejść:

Przygotowanie środowiska do instalacji systemu.

Instalacja systemu, ładowanie danych i test po instalacyjny.

Realizacja scenariuszy zgodnych z Biznesowymi Przypadkami Użycia.

Realizacja scenariuszy zgodnych z alternatywnymi przebiegami Przypadków
Użycia.

Testowanie
parametrów
pojemności,
jakości
i
przyjazności
interfejsu,
dostępności, bezpieczeństwa oraz procedur przywracania ciągłości i powrotu do
starego systemu.

Ocena dokumentacji użytkownika, szkoleń i skutków reorganizacji dokonanej
wskutek wdrożenia.
k) Każdy incydent lub problem powstały podczas wdrażania może mieć wpływ na akceptację, tak
jakby powstał podczas testów akceptacyjnych.
l)
Raport z testów akceptacyjnych powinien być dokumentem decydującym o akceptacji
systemu.
m) Do raportu z testów akceptacyjnych powinna być dołączona dokumentacja robocza wszystkich
testów wykonywanych na potrzeby akceptacji oraz zestawienie próśb o zmianę i zmian
zrealizowanych podczas wdrażania.
Testy bezpieczeństwa
Testy bezpieczeństwa zostaną wykonane przez Zamawiającego na podstawie strategii testowania
opracowanej przez Zamawiającego.
Testy systemowe
Testy systemowe zostaną wykonane przez Zamawiającego na podstawie strategii testowania
opracowanej przez Zamawiającego.
Testy integracyjne
Testy integracyjne zostaną wykonane przez Zamawiającego na podstawie strategii testowania
opracowanej przez Zamawiającego
12. Dokumentacja systemu
Wykonawca jest zobowiązany do wykonania i dostarczenia niezbędnej dokumentacji
dla
oferowanego rozwiązania. Szczegóły kryteriów jakie dokumentacja powinna zawierać została opisana
w tabeli.
L.p.
Rodzaj dokumentacji
1.
Szczegółowy
harmonogramy realizacji
przedmiotu umowy
Zawartość
Wykonawca dostarczy dokument, który powinien zawierać
terminy dostarczenia:
Planu
projektu,
specyfikacji
wymagań,
polityki
bezpieczeństwa, prototypu systemu i raportu z testów
akceptacyjnych;
Ponadto dokument powinien zawierać terminy wszystkich
dostaw oraz terminy:
uruchomienia systemu, akceptacji systemu i osiągnięcia
pełnej zdolności produkcyjnej przez system;
konstrukcję modelu logicznego systemu;
2.
architekturę fizyczną systemu;
Dokumentacja analityczno
– techniczna
szczegółowy opis działania wszystkich usług wchodzących
w skład przedmiotu zamówienia;
szczegółowy opis skonfigurowania urządzeń oraz
oprogramowania (m.in. oprogramowania systemowego,
oprogramowania narzędziowego, oprogramowania
pośredniczącego, oprogramowania użytkowego);
zakres funkcjonalny systemu;
sposób konfiguracji klastra;
politykę zarządzania partycjami serwera;
politykę backupu i odtworzenia systemu po awarii;
Wykonawca dostarczy dokument, który powinien zawierać:
3.
Schemat i opis struktury i organizacji połączeń sieciowych;
Schemat i opis połączeń sprzętu komputerowego i urządzeń
dodatkowych;
Dokumentacja architektury
systemu
Schemat i opis organizacji informacji przetwarzanych w
systemie, obejmujący zarówno strukturę oprogramowania
współpracującego z systemem (np. oprogramowanie
sieciowe, systemy operacyjne, bazy danych) jak też
strukturę wewnętrzną oprogramowania systemowego
(podsystemy, funkcje, moduły, tablice);
Opis parametrów sprzętu, urządzeń i komponentów
oprogramowania;
Schemat i opis integracji systemu z innymi systemami;
Wytyczne dla programistów implementujących system
CRM,
oraz
osób
dokonujących
audytu
kodu
(administratorzy, projektanci).
Materiały szkoleniowe
4.
Dokumentacja techniczna systemu;
Podręcznik dla użytkownika;
Podręczniki dla administratorów;
Dokumentacja
użytkownika
Instrukcje instalacji i konfiguracji;
Opis procedur zarządzania wersją i konfiguracją;
Definicje procedur wdrożeniowych;
Definicje procedur eksploatacyjnych;
Scenariusze testów akceptacyjnych, przeznaczone do użytku
podczas wdrażania pilotażowego i próbnej eksploatacji;
6.
Plan testów
Wykonawca dostarczy dokument zawierający uzgodnione
terminy testów akceptacyjnych oraz innych testów, którymi
zainteresowani są przedstawiciele użytkowników
i eksploatacji.
Wykonawca dostarczy raport z testów akceptacyjnych, który
powinien zawierać:
8
Raport testów
akceptacyjnych
Wniosek o akceptację lub odrzucenie systemu;
Jeżeli raport zawiera wniosek o akceptację, to powinien
zawierać:
a) zbiorcze zestawienia incydentów, problemów i
znanych błędów;
b) Pełną dokumentację roboczą testów (scenariusze,
zgłoszenia incydentów);
c) Wyniki pomiarów i obliczeń dotyczących;
awaryjności, wydajności, wytrzymałości i innych
parametrów zdefiniowanych w strategii akceptacji
Wykonawca dostarczy dokumentację obejmującą:
9
Opis zbiorów informacji, w tym danych osobowych i innych
informacji wrażliwych oraz czy dane osobowe są
przedmiotem zgłoszenia do GIODO.
Wymagania dotyczące dostępności, poufności i integralności
danych.
Ocenę krytyczności systemu;
Dokument Polityka
bezpieczeństwa dla
systemu CRM.
Procedury bezpiecznej eksploatacji;
Procedury awaryjne;
Plany ciągłości działania;
Zasady wykonywania i przechowywania kopii zapasowych;
Procedury testowania poprawności odtwarzania systemu i
danych (restore);
Procedury bezpiecznego testowania eksploatacji systemu w
środowisku produkcji;
Zasady monitorowania;
Tabela 10 Niezbędna dokumentacja.
Dokumentacja analityczna.
1. Dokumentacja analityczna powinna zawierać szczegółową analizę wymagań zamawiającego a w
tym co najmniej:
a)
szczegółowej analizy wymagań funkcjonalnych i niefunkcjonalnych;
b)
analizy ryzyka;
c)
analizy bezpieczeństwa dostarczanego rozwiązania;
2. Dokumentacji z przeprowadzonych prac analitycznych w formie wydruku, zapisu elektronicznego
oraz streszczenie dla komitetu sterującego w formie prezentacji.
3. Wykonawca po zatwierdzeniu przez Zamawiającego przedstawionych wyników analizy, wykona
projekt techniczny uwzględniający sprzęt, oprogramowanie oraz założenia techniczne i funkcjonalne
przedstawione w niniejszej specyfikacji, w zakresie:

konstrukcję modelu logicznego systemu,

architekturę fizyczną systemu,

szczegółowy opis działania wszystkich usług wchodzących w skład przedmiotu zamówienia,

szczegółowy opis skonfigurowania urządzeń oraz oprogramowania systemowego i
narzędziowego,

sposób konfiguracji klastra,

politykę zarządzania partycjami serwera

politykę backupu i odtworzenia systemu po awarii.
3. Wykonawca po zatwierdzeniu przez Zamawiającego przedstawi dokumentacje dla zrealizowanych
w ramach przedmiotu Zamówienia zakres funkcjonalny, a w szczególności jeśli dotyczy:
a) model biznesowy realizowanych procesów,
b) model architektury systemu,
c) diagramy przypadków użycia,
d) diagramy aktywności,
e) diagramy przepływów,
f)
diagramy stanów,
g) modele analityczne klas,
h) modele projektowe klas,
i)
modele danych,
j)
kod źródłowy.
13. Prowadzenie projektu
Metodologia prowadzenia projektu zgodnie z PRINCE 2 lub równoważna. Wymagane
dokumenty:
 Struktura Organizacyjna
 Plan Projektu uwzględniający w szczególności definicje prac i produktów
wykonywanych w ramach umowy
 Strategia Zarządzania Jakością oraz Plan Jakości
 Strategia Zarządzania Ryzykiem oraz Rejestr Ryzyka
 Plan Komunikacji
 Harmonogramu realizacji przedmiotu umowy

Zapytaniem dot. systemu informatycznego

Transkrypt

Podobne dokumenty

gry dla dzieci 29.01.2013 Fun English w bibliotece

OPERA FUN 405200 TAPETY DLA DZIECI ARTHOUSE

Franczyza - FUNPIZZA

rekomendacja

Zasady naszych osiągnięć Uczyć się z czyć się z czyć się z czyć się