SIWZ - PARP - SI KSU MSP

Transkrypt

Załącznik nr 1 – Zakres Zadań Wykonawcy
Zakres Zadań Wykonawcy
„Analiza systemu LSI (Lokalnego Systemu Informatycznego) oraz
prace programistyczne dostosowania systemu do potrzeb
ekstranetu”
Strona 1 z 56
1
INFORMACJE O ZAMAWIAJĄCYM .................................................................................................... 4
1.1
1.2
PARP ................................................................................................................................................... 4
FINANSOWANIE ..................................................................................................................................... 4
2
PRZEDMIOT ZAMÓWIENIA .................................................................................................................. 4
3
ZAKRES PRAC BĘDĄCYCH PRZEDMIOTEM ZAMÓWIENIA ...................................................... 5
OPRACOWANIE ORGANIZACJI PROJEKTU I HARMONOGRAMU ................................................................ 6
3.1
Organizacja projektu....................................................................................................................... 6
3.1.1
Harmonogram ................................................................................................................................. 6
3.1.2
ASYSTA TECHNICZNA ........................................................................................................................... 8
3.2
SERWIS GWARANCYJNY ........................................................................................................................ 9
3.3
4
WYMAGANIA DOTYCZĄCE LSI ........................................................................................................ 10
4.1
4.2
4.3
4.4
4.4.1
4.4.2
4.4.3
4.4.4
4.4.5
4.5
4.5.1
4.5.2
4.5.3
4.5.4
4.5.5
4.5.6
4.6
4.6.1
4.6.2
5
ZAŁOŻENIA ......................................................................................................................................... 10
SŁOWNICZEK ...................................................................................................................................... 11
WYMOGI DOTYCZĄCE ESTETYKI I ERGONOMII .................................................................................... 15
INTERFEJS UŻYTKOWNIKA .................................................................................................................. 16
Wymagania dotyczące Interfejsu użytkownika .............................................................................. 16
E-Dostępność ................................................................................................................................ 17
Technologia zastosowana do budowy interfejsu ........................................................................... 17
Nawigacja ..................................................................................................................................... 17
Graficzne rozmieszczenie elementów interfejsu ............................................................................ 18
WYMAGANIA DOTYCZĄCE UŻYTECZNOŚCI ......................................................................................... 19
Formularze .................................................................................................................................... 19
Odnośniki ...................................................................................................................................... 19
Typografia i formatowanie tekstu .................................................................................................. 19
Układ elementów ........................................................................................................................... 20
Grafika .......................................................................................................................................... 20
Komunikaty o błędach ................................................................................................................... 20
WYMAGANIA TECHNICZNE DOTYCZĄCE SYSTEMU ............................................................................. 20
Modułowa budowa Systemu .......................................................................................................... 21
Bezpieczeństwo Systemu ................................................................................................................ 21
MODUŁY LSI ........................................................................................................................................... 22
5.1
5.2
5.2.1
5.2.2
5.2.3
5.2.4
5.2.5
5.2.6
5.2.7
5.2.8
5.3
5.3.1
5.3.2
5.3.3
5.3.4
5.3.5
5.4
5.4.1
5.4.2
5.5
SŁOWNIKI STATUSÓW ......................................................................................................................... 23
MODUŁ OBSŁUGI KONKURSÓW ........................................................................................................... 24
Funkcjonalność „zarządzanie konkursami” ................................................................................. 24
Funkcjonalność „rejestracja wniosków o dofinansowanie” ......................................................... 25
Funkcjonalność „dekretacja wniosków do oceny formalnej” ....................................................... 25
Funkcjonalność „ocena formalna” ............................................................................................... 26
Funkcjonalność „dekretacja wniosków do oceny merytorycznej” ................................................ 28
Funkcjonalność „ocena merytoryczna” ........................................................................................ 29
Funkcjonalność „oprotestowanie wniosku” ................................................................................. 30
Funkcjonalność „generowanie listy rankingowej” ....................................................................... 31
MODUŁY BENEFICJENTA .................................................................................................................... 32
Rejestracja/logowanie ................................................................................................................... 32
Generator Wniosków Aplikacyjnych ............................................................................................. 32
Generator Wniosków Płatniczych ................................................................................................. 34
„Moje wnioski” ............................................................................................................................. 34
Pomoc............................................................................................................................................ 38
MODUŁ REALIZACJI PROJEKTÓW......................................................................................................... 40
Umowy i aneksy............................................................................................................................. 40
Wnioski o płatność ........................................................................................................................ 41
MODUŁ KONTROLI I EWIDENCJI NIEPRAWIDŁOWOŚCI ......................................................................... 44
Strona 2 z 56
5.5.1
Wymagania funkcjonalne .............................................................................................................. 44
Wymagania funkcjonalne – wydruki ............................................................................................. 45
5.5.2
Ewidencja nieprawidłowości - wymagania funkcjonalne.............................................................. 45
5.5.3
MODUŁ ADMINISTRACYJNY ................................................................................................................ 46
5.6
Modelowanie procesów ................................................................................................................. 46
5.6.1
Konfiguracja i zarządzanie ........................................................................................................... 46
5.6.2
OBECNY SYSTEM LSI .......................................................................................................................... 47
5.7
SPRAWOZDAWCZOŚĆ I RAPORTY ........................................................................................................ 47
5.8
6
INTEGRACJA DANYCH ........................................................................................................................ 47
6.1
6.2
6.3
7
INTEGRACJA Z SYSTEMEM KSI (SIMIK 07-13) ................................................................................... 48
INTEGRACJA Z SYSTEMEM CMS WEB.GOV.PL I EXTRANETEM ............................................................ 48
INTEGRACJA Z INNYMI ŹRÓDŁAMI DANYCH ........................................................................................ 48
TESTY FUNKCJONALNOŚCI I ODBIÓR SYSTEMU ....................................................................... 48
7.1
7.2
SPECYFIKACJA TESTÓW ...................................................................................................................... 48
ODBIÓR PRZEDMIOTU ZAMÓWIENIA.................................................................................................... 51
8
MIGRACJA DANYCH Z DOTYCHCZASOWYCH SYSTEMÓW BAZODANOWYCH ............... 51
9
UWARUNKOWANIA BUDOWY SYSTEMU ....................................................................................... 51
9.1
9.1.1
9.1.2
9.1.3
9.1.4
9.1.5
9.2
9.3
9.4
9.5
9.6
UWARUNKOWANIA PRAWNO – ORGANIZACYJNE ................................................................................ 51
Akty prawne ................................................................................................................................... 51
Regulaminy działania 8.1 i 8.2 PO IG .......................................................................................... 53
Wymogi struktury organizacyjnej .................................................................................................. 53
Nowelizacje aktów prawnych ........................................................................................................ 53
Przeniesienie autorskich praw majątkowych ................................................................................ 53
UWARUNKOWANIA TECHNICZNE ........................................................................................................ 54
OBCIĄŻENIE SYSTEMU ........................................................................................................................ 55
ZWIĘKSZANIE WYDAJNOŚCI ................................................................................................................ 55
WYMAGANIA MODYFIKOWALNOŚCI ................................................................................................... 55
WYMAGANIA DOSTĘPNOŚCI ................................................................................................................ 56
Strona 3 z 56
1 Informacje o Zamawiającym
1.1 PARP
Polska Agencja Rozwoju Przedsiębiorczości (PARP) jest agencją rządową podlegającą Ministrowi
Gospodarki. Powstała na mocy Ustawy z dnia 9 listopada 2000 roku o utworzeniu Polskiej Agencji
Rozwoju Przedsiębiorczości. Jej zadaniem jest zarządzanie funduszami pochodzącymi
z budżetu państwa i Unii Europejskiej, przeznaczonymi na wspieranie przedsiębiorczości i rozwój
zasobów ludzkich, ze szczególnym uwzględnieniem potrzeb mikroprzedsiębiorców, małych i średnich
przedsiębiorstw. PARP jest także jedną z instytucji odpowiedzialnych za wdrażanie działań
finansowanych z Funduszy Strukturalnych.
Celem działania Agencji jest realizacja programów rozwoju gospodarki zwłaszcza w zakresie
wspierania:
• rozwoju małych i średnich przedsiębiorstw,
• rozwoju eksportu,
• rozwoju regionalnego,
• wykorzystywania nowych technik i technologii,
• rozwoju zasobów ludzkich.
Cel ten jest realizowany między innymi przez:
• wsparcie m.in. dla firm sektora MSP, instytucji działających na rzecz rozwoju MSP,
• instytucji szkoleniowych oraz instytucji rynku pracy,
• usługi doradcze i eksperckie,
• ułatwianie przedsiębiorcom dostępu do wiedzy, informacji gospodarczej, opracowań i analiz,
• organizowanie przedsięwzięć informacyjnych i promocyjnych.
1.2 Finansowanie
Zamówienie finansowane jest ze środków projektu systemowego „Uruchomienie wielofunkcyjnej
platformy komunikacji internetowej wspierającej realizację działań 8.1 i 8.2 PO IG” realizowanego w
ramach działania 8.1 PO IG. Projekt nadzorowany przez Ministerstwo Spraw Wewnętrznych
i Administracji współfinansowany jest ze środków Europejskiego Funduszu Rozwoju Regionalnego.
2 Przedmiot zamówienia
Przedmiotem zamówienia jest rozbudowa portalu „Wspieramy e-biznes” poprzez zaprojektowanie
wykonanie i wdrożenie modułów Lokalnego Systemu Informatycznego (LSI) oraz zintegrowanie z
obecnym systemem CMS portalu oraz budowanymi równolegle modułami Extranetu.
Wdrożenie ma następujące cele:
• podniesienie efektywności zarządzania działaniami 8.1 oraz 8.2 PO IG,
• poprzez zintegrowanie z istniejącym systemem CMS udostępnienie potencjalnym
i rzeczywistym wnioskodawcom działań 8.1 i 8.2 Programu Operacyjnego Innowacyjna
Gospodarka (PO IG) jednego miejsca służącego komunikacji i interakcji pomiędzy
wnioskodawcą a instytucjami biorącymi udział w procesie przyznawania i kontroli
dofinansowania,
• rejestrowanie całego cyklu życia wniosku/projektu, od rejestracji beneficjenta, rejestracji
wniosku, generowania szczegółowych sprawozdań i raportów a także rejestrowania kontroli i
archiwizację.
Strona 4 z 56
•
udostępnienie wybranym użytkownikom PARP i innych instytucji zaangażowanych w nadzór
nad realizacją projektów możliwości łatwego generowania zestawień statystycznych z bazy
danych dotyczącej działań 8.1 i 8.2 PO IG,
Grupa docelową są, w ramach szczegółowych uprawnień:
• potencjalni wnioskodawcy działań 8.1 i 8.2 PO IG,
• rzeczywiści wnioskodawcy działań 8.1 i 8.2 PO IG,
• pracownicy Regionalnych Instytucji Finansujących,
• Eksperci oceniający projekty współpracujący z Regionalnymi Instytucjami Finansującymi,
• użytkownicy instytucji nadzorujących realizację projektów w ramach PO IG (PARP, MSWiA,
MRR)
Szczegółowy opis przedmiotu zamówienia zawarty jest w niniejszym dokumencie.
3 Zakres prac będących przedmiotem zamówienia
W ramach realizacji zamówienia Wykonawca:
1) W ramach etapu I:
a) Dokona weryfikacji kompleksowego pełnego procesu realizacji projektu w ramach działania 8.1
i 8.2 PO IG (m.in. złożenie Wniosku, ocena, podpisanie umowy, realizacja projektu, płatności) na
podstawie spotkań z Zespołem merytorycznym nadzorującym realizację zadania oraz przekazanych
przez Zamawiającego dokumentów (m.in. Regulamin przeprowadzenia konkursu, Wzór umowy z
beneficjentem, Regulamin współpracy z RIF, Procedura odwoławcza),
b) Wykona analizę dokumentacji technicznej Platformy CMS PARP w celu zaplanowania
zachowania kompatybilności wdrażanych modułów Systemu LSI i Ekstranetu z CMS
PARP, określi sposób komunikacji pomiędzy LSI a istniejącym systemem CMS, oraz zapewni
komunikcję pomiędzy LSI a budowanym równolegle Extranetem
c) Zbada i sprecyzuje potrzeby Zamawiającego względem szczegółowych wymagań realizacji
poszczególnych funkcjonalności LSI (ZZW precyzuje co ma system realizować analiza odpowie
jak to ma system realizować),
d) Opracuje i przedstawi do akceptacji Zamawiającemu szczegółowy harmonogram i zasady
organizacji przedsięwzięcia,
e) Opracuje i przedstawi do akceptacji Zamawiającemu procedurę odbioru LSI na poszczególnych
etapach, wspólnego audytu oraz odbioru końcowego zintegrowanego systemu,
f) Określi zasady i procedury oraz świadczyć będzie Zamawiającemu usługę asysty technicznej,
g) Określi warunki gwarancji,
h) Dostarczy dokumentację modelowania procesów, specyfikację funkcjonalną, projekt baz danych
oraz projekt komunikacji pomiędzy LSI a extranetem,
2) W ramach etapu II:
i) Wykona moduł administracyjny Systemu LSI,
j) Przeprowadzi na podstawie uprzednio zaakceptowanych szczegółowych scenariuszy testy
wewnętrzne oddanego modułu LSI,
3) W ramach etapu III:
k) Wykona moduł obsługi konkursów Systemu LSI
l) Przeprowadzi na podstawie uprzednio zaakceptowanych szczegółowych scenariuszy testy
wewnętrzne oddanego modułu LSI,
4) W ramach etapu IV:
m) Wykona moduły beneficjenta Systemu LSI
n) Dokona integracji LSI z systemem Extranet
Strona 5 z 56
o) Wdroży funkcjonalność sprawozdawczości i raportów w zakresie opisanym w rozdziale 5.8
p) Przeprowadzi na podstawie uprzednio zaakceptowanych szczegółowych scenariuszy testy
wewnętrzne oddanych modułów LSI,
q) Przeprowadzi wraz z Zamawiającym i niezależnymi ekspertami wspólny Audyt wdrożonych tym i
poprzednich etapach modułów systemu LSI,
5) W ramach etapu V:
r) Dokona migracji, połączenia, weryfikacji spójności danych z obecnego systemu LSI i platformy
CMS,
6) W ramach etapu VI:
s) Wykona moduł realizacji projektów Systemu LSI
t) Wykona moduł kontroli i ewidencji nieprawidłowości Systemu LSI
u) Przeprowadzi na podstawie uprzednio zaakceptowanych szczegółowych scenariuszy testy
wewnętrzne oddanych modułów LSI,
v) Przeprowadzi wraz z Zamawiającym i niezależnymi ekspertami wspólny Audyt wdrożonych tym i
poprzednich etapach modułów systemu LSI,
7) W ramach etapu VII:
w) świadczyć będzie usługę gwarancji,
x) Przeprowadzi wraz z Zamawiającym i niezależnymi ekspertami wspólny Audyt zintegrowanego
systemu (LSI i Extranetu).
3.1 Opracowanie organizacji projektu i harmonogramu
3.1.1 Organizacja projektu
Wykonawca opracuje zasady realizacji projektu, obejmujące swym zakresem, co najmniej następujące
elementy:
1. Opis organizacji prowadzenia Projektu (metodyki prowadzenia projektu) w tym wytyczne dla
Zamawiającego w zakresie wpływającym na jakość i terminowość oddania systemów,
2. Skład Zespołu Projektowego z opisem ról każdej osoby oraz zakresów jej odpowiedzialności,
3. Opis procesów zarządczych w Projekcie:
3.1. raportowanie,
3.2. zarządzanie dokumentacją,
3.3. zarządzanie zmianą.
4. Sposób komunikacji pomiędzy Wykonawcą i Zamawiającym,
5. Opis metodyki tworzenia i wdrażania oprogramowania,
6. Metodę gromadzenia informacji o ryzykach oraz zarządzania ryzykiem,
7. Sposób prowadzenia przeglądów jakości (quality assurance) dla tworzonego Systemu,
8. Szczegółowy harmonogram uwzględniający równoległe prace Zespołów, oraz terminy
przekazywania dokumentacji do decyzji zamawiającego wraz z planowanymi terminami
akceptacji gwarantującymi terminowe wykonanie zamówienia.
3.1.2 Harmonogram
Szczegółowy harmonogram projektu uwzględniający równoległe prace Zespołów, oraz terminy
przekazywania dokumentacji do decyzji zamawiającego wraz z terminami akceptacji gwarantującymi
Strona 6 z 56
terminowe wykonanie zamówienia powinien zawierać przynajmniej następujące elementy:
Proponowane terminy
Przekazanie
Akceptacja
Etap I
1. Przedstawienie do akceptacji:
a) Szczegółowego
przedsięwzięcia
harmonogramu
i
zasad
organizacji 19.08.2009
b) Procedury odbioru Systemu na poszczególnych etapach,
wspólnego audytu oraz odbioru końcowego
c) Zasad i procedury Asysty Technicznej
d) Warunków gwarancji
2. Analiza wymagań funkcjonalnych:
a) Weryfikacja kompleksowego pełnego procesu realizacji
projektu w ramach działania 8.1 i 8.2 PO IG,
b) Analiza dokumentacji technicznej Platformy CMS PARP
c) Analiza
szczegółowych
wymagań
poszczególnych funkcjonalności LSI
realizacji
3. Przedstawienie do akceptacji:
a) Dokumentacji modelowania procesów
b) Specyfikacji funkcjonalnej
c) Projektu baz danych
d) Projektu komunikacji pomiędzy LSI a extranetem
Etap II
Wdrożenie modułu administracyjnego
Testy wewnętrzne
Akceptacja wdrożenia przez Zamawiającego
Etap III
Wdrożenie modułu obsługi konkursów
Testy wewnętrzne
Akceptacja wdrożenia przez Zamawiającego
Etap IV
Wdrożenie modułów beneficjenta
Wdrożenie funkcjonalności sprawozdawczości i raportów w
zakresie opisanym w rozdziale 5.8
Strona 7 z 56
20.08.2009
Integracja LSI z systemem Extranet
Testy wewnętrzne
Testy akceptacyjne wdrożonych w etapach II-IV modułów systemu
LSI
Etap V
Migracja i połączenia danych z obecnego systemu LSI do
platformy CMS i LSI
Etap VI
Wdrożenie modułu realizacji projektów
Wdrożenie modułu kontroli i ewidencji nieprawidłowości
Testy wewnętrzne
Testy akceptacyjne Systemu LSI
20 listopad 2009r.
Etap VII
Usługa gwarancji
Przeprowadzenie wraz z Zamawiającym i niezależnymi ekspertami W
terminie
wspólnego Audytu zintegrowanego systemu
uzgodnionym
przez strony,
nie później niż
10
grudnia
2009 r.
Odbiór końcowy systemu
3.2 Asysta techniczna
W ramach przedsięwzięcia, po wdrożeniu pełnej funkcjonalności LSI, od daty odbioru końcowego –
do końca trwania umowy, Wykonawca zapewni usługę asysty technicznej - stałej opieki
powdrożeniowej obejmującej:
1. Konsultacje i pomoc udzielaną w zakresie funkcjonowania LSI,
2. Konsultacje telefoniczne w zakresie funkcjonowania LSI udzielane dla pracowników
Zamawiającego oraz użytkowników (RIF, PARP, MSWiA, MRR) LSI,
3. Wszelkie zmiany definiowalnych elementów LSI oraz zmiany wprowadzane
do LSI uwzględniające zmiany w obowiązującym prawodawstwie.
W przypadku zmian w przepisach prawa, które powodują konieczność zmiany funkcjonowania
Systemu, a które nastąpią w trakcie trwania asysty technicznej, Wykonawca dokona aktualizacji
Systemu polegającej na dostosowaniu go do zmieniających się przepisów prawa w terminie najpóźniej
do 7 dni przed wejścim w życie nowych przepisów prawa.
Koszt usługi będzie wliczony do oferty cenowej i nie będzie objęty dodatkowymi opłatami.
Strona 8 z 56
3.3 Serwis gwarancyjny
W ramach przedsięwzięcia, po wdrożeniu pełnej funkcjonalności Systemów, przez czas określony w
ofercie jednak nie krótszy niż do końca trwania okresu gwarancyjnego na System CMS PARP,
Wykonawca będzie zobowiązany do zapewnienia serwisu gwarancyjnego.
Wykonawca określi możliwości rozbudowy LSI o nowe moduły określając kryteria, jakie muszą
spełniać nowo przyłączane moduły, tak aby zachować poprawność działania zintegrowanego systemu
(LSI, Platforma CMS, budowany równolegle Extranet) z jednoczesnym zachowaniem gwarancji.
1. Specyfikacja serwisu gwarancyjnego:
1. Wykonawca gwarantuje Zamawiającemu, że wdrożony do eksploatacji LSI jest wolny od wad
fizycznych oraz sprawny w działaniu, a w szczególności:
a) Nie zawiera istotnych wad uniemożliwiających lub ograniczających eksploatację
modułów w całym oprogramowaniu wchodzącym w skład tego systemu, wykonanym lub
dostarczonym przez Wykonawcę;
b) Jest kompatybilny z programami i innymi systemami Zamawiającego zgodnie
z założeniami niniejszego przedsięwzięcia i nie powoduje awarii i błędów innych
systemów, z którymi jest sprzężony,
c) Wszelkie usługi instalacyjno - wdrożeniowe są kompletne, poprawne i wykonane zgodnie
z dokumentacją techniczną
2. Usunięte zostaną wady w tworzonych modułach stwierdzone jeszcze w okresie trwania
zamówienia, których termin usunięcia przypada na okres obowiązywania gwarancji.
3. Okres gwarancji na LSI kończy się najwcześniej wraz z końcem okresu gwarancyjnego na System
CMS PARP i liczony jest od dnia podpisania bez zastrzeżeń Protokołu Odbioru Końcowego
Umowy.
4. W ramach gwarancji Wykonawca zobowiązuje się do nieodpłatnego usuwania wszelkich wad
w funkcjonowaniu LSI zgodnie z obsługą zobowiązań gwarancyjnych zawartą punkcie 3.3.2
niniejszego Załącznika.
5. Zamawiający ma obowiązek zgłosić wady objęte niniejszą gwarancją niezwłocznie po ich
wystąpieniu, do przedstawiciela Wykonawcy.
6. Termin gwarancji dla LSI ulega przedłużeniu o czas, w ciągu którego Zamawiający
nie mógł korzystać z LSI.
7. W wypadku nie wywiązywania się Wykonawcy z zobowiązań gwarancyjnych Zamawiający
ma prawo skorzystać na koszt Wykonawcy, z usług zastępczych bez utraty prawa gwarancji.
8. Wykonawca zobowiązuje się do podpisania umowy na serwis pogwarancyjny na żądanie
Zamawiającego. Cena świadczenia serwisu pogwarancyjnego zostanie ustalona odrębną umową
serwisową.
2. Procedury serwisu gwarancyjnego:
1. Interwencja grupy serwisowej na podstawie zgłoszeń e-mail, telefonicznych (potwierdzonych
e-mail), systemem Mantis lub faksem,
2. Efektywna reakcja grupy serwisowej w ciągu 12 godzin od zgłoszenia awarii, błędu
krytycznego lub innej usterki,
3. Usunięcie awarii systemu oraz odtworzenie danych w ciągu 24 godzin od chwili rozpoczęcia
akcji przez grupę serwisową,
4. Usunięcie każdego błędu krytycznego (uniemożliwiającego pracę systemu) w ciągu
24 godzin od zgłoszenia błędu. Usunięcie odbędzie się w dwóch fazach:
Strona 9 z 56
i.
w ciągu pierwszych 6 godzin od zgłoszenia przez Zamawiającego, Wykonawca określi, w
jaki sposób należy eksploatować System tak aby wyeliminować ryzyko wynikające
ze stwierdzonego błędu,
ii. w ciągu następnych 18 godzin Wykonawca przywróci całkowitą funkcjonalność Systemu
wraz z odzyskanymi danymi.
5. Usuwanie błędów niekrytycznych w terminie do 5 dni roboczych od zgłoszenia błędu,
6. Uaktualnień oprogramowania po usunięciu błędów krytycznych w systemie.
7. Przeprowadzenie testów i/lub innych czynności sprawdzających poprawność działania
systemu po dokonaniu naprawy.
8. Wykonawca sporządzi protokół usunięcia błędu, w którym określi przyczyny wystąpienia
błędu oraz procedurę usunięcia i przywrócenia Systemu.
9. Instalowanie usprawnień, łat programowych, aktualizacji i poprawek do Extranetu i LSI.
10. Uaktualnianie dokumentacji systemów
Koszt usługi serwisu gwarancyjnego będzie wliczony do oferty cenowej i nie objęty dodatkowymi
opłatami.
4 Wymagania dotyczące LSI
4.1 Założenia
1. Moduły powinny korzystać z platformy sprzętowej, oprogramowania, baz danych PARP i bazy
użytkowników Platformy CMS PARP. W trakcie przygotowania Projektu Technicznego Systemu
Wykonawca dążyć będzie do oparcia Systemu w jak największej części na platformie sprzętowej i
programistycznej Platformy CMS PARP.
2. Moduły rozliczeń i składania wniosków LSI muszą zostać powiązane z nawigacją globalną
serwisu, np poprzez umieszczenie ich jako zakładek.
3. Użytkownicy Systemu muszą otrzymać dostęp do wszystkich jego części (Portal, LSI, Extranet, a
w przyszłości kolejne moduły systemu) poprzez jeden, wspólny i jednorodny interfejs użytkownika
(interfejs WWW),
4. Interfejs użytkownika, w szczególności jego wygląd zewnętrzny, sposób nawigacji powinien być
spójny z interfejsem Portalu i zgodny z założeniami SIWZ na „Zaprojektowanie, wykonanie i
wdrożenie portalu wspierającego realizację działań 8.1 i 8.2 Programu Operacyjnego Innowacyjna
Gospodarka (PO IG) z wykorzystaniem systemu zarządzania treścią stron internetowych CMS”
(dokumentacja przetargowa dostępna pod adresem http://bip.parp.gov.pl/index/more/5700). Nowe
moduły Systemu powinny być zaprojektowane i przedstawione tak, aby z punktu widzenia
użytkowników stanowiły jego integralną część.
5. Wykonawca określi sposób identyfikacji i uwierzytelnienia użytkowników systemu LSI.
Wykonawca określi czy w tym celu będzie korzystać z mechanizmów wdrożonych w Portalu.
6. Integracja Systemu z Platformą CMS PARP i mechanizmami wykorzystywanymi w Portalu
zapewni funkcjonalność "single login", czyli jednokrotne uwierzytelnienie użytkownika w trakcie
korzystania z zasobów Portalu i Systemu. Użytkownicy nie będą musieli także przechodzić
dwukrotnie procesu rejestracji.
7. Na jednym loginie tylko jeden użytkownik będzie mógł modyfikować i wprowadzać do Systemu
dane. Jeśłi inny użytkownik korzysta z tego samego loginu powinien otrzymać komunikat o
Strona 10 z 56
zablokowaniu możliwości wprowadzania / edycji danych.
8. System musi zostać zaprojektowany i wdrożony w sposób, który zagwarantuje utrzymanie
poziomu mechanizmów bezpieczeństwa, możliwości zwiększenia wydajności i wymogów co do
obciążenia Platformy Systemowej. Wykonawca otrzyma dostęp do dokumentów wdrożeniowych (w
tym do projektu technicznego i specyfikacji funkcjonalnej obecnego Systemu LSI ) przygotowanych
w ramach realizacji tej platformy. Wykonawca zapewni mechanizm efektywnego tworzenia kopii
bezpieczeństwa danych i wszelkich plików wchodzących w skład Systemu.
9. Od strony ogólnej funkcjonalności, System powinien oferować:
a) elastyczne sporządzanie potrzebnych raportów z możliwością generowania na ich podstawie
dokumentów w różnych formatach (strony WWW, PDF, MS Excel, MS Word, pliki
OpenOffice, Pliki MS Access, XML, CSV) na podstawie zgromadzonych danych – z
podziałem na raporty podstawowe i raporty zaawansowane.
b) zarządzanie dokumentami (umożliwiając tworzenie, edycję oraz wyszukiwanie dokumentów),
c) zarządzanie szablonami dokumentów (umożliwiając generowanie dokumentów w różnych
formatach - strony WWW, MS Word, OpenOffice, MS Excel, PDF - na podstawie szablonów
dokumentów umieszczonych w bazie danych, oraz tworzenie takich szablonów. Przykładem
tego typy dokumentów są różnego rodzaju umowy, pisma do wnioskodawców
przechowywane w Systemie obsługi działań PO IG)
d) wersjonowanie informacji przechowywanych w Systemie – wersjonowanie danych i
szablonów, wymodelowanych procesów, ect.
e) proste i intuicyjne zarządzanie Systemem, użytkownikami, nadawaniem ról i uprawnień,
f) proste i intuicyjne sposoby na wprowadzanie danych do Systemu (formularze, sprawozdania,
etc. wraz z odpowiednimi kreatorami),
g) proste i wydajne wyszukiwania wszelkich informacji w Systemie.
4.2 Słowniczek
1. ACL (ang. Access Control List) - lista kontroli dostępu. W systemach Unix poprzez rozszerzenie
możliwości systemu plików, umożliwia bardziej rozbudowaną i dokładną kontrolę dostępu do
plików, w porównaniu do standardowych uprawnień w systemie.
2. Atom - standard kanałów informacyjnych, następca RSS 2.0. Specyfikacja języka znajduje się w
RFC 4287.
3. Atrybut - cecha, właściwość danej treści w module.
4. Audyt - Ogół działań, poprzez które uzyskuje się niezależną ocenę funkcjonowania instytucji,
legalności, gospodarności, celowości, rzetelności; audyt jest zazwyczaj wykonywany przez
odrębną komórkę, podporządkowaną bezpośrednio kierownikowi instytucji (wewnętrzny) lub
przez firmę zewnętrzną (zewnętrzny).
5. B2B – oprogramowanie wspierające przedsięwzięcia biznesowe prowadzone między
przedsiębiorcami.
6. Backup (kopia bezpieczeństwa) - dane, które mają służyć do odtworzenia oryginalnych danych w
przypadku ich utraty lub uszkodzenia.
7. Beneficjent - wnioskodawca, który podpisał umowę o dofinansowanie i realizuje projekt zgodnie
z jej postanowieniami. Przedkłada wniosek o płatność do właściwej Regionalnej Instytucji
Finansującej.
8. CAPTCHA (ang. Completely Automated Public Turing Test to Tell Computers and Humans
Apart) - rodzaj techniki stosowanej jako zabezpieczenie w formularzach na stronach WWW. Dla
Strona 11 z 56
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
przesłania danych konieczne jest przepisanie treści z pliku graficznego (zazwyczaj losowo
dobranych znaków bądź krótkiego wyrazu).
CMS - system zarządzania treścią (ang. Content Management System) to aplikacja lub zestaw
aplikacji internetowych pozwalających na łatwe tworzenie oraz późniejszą aktualizację i
rozbudowę Portalu przez użytkowników o odpowiednich uprawnieniach. Kształtowanie treści i
sposobu ich prezentacji w Extranecie, Portalu zarządzanym poprzez CMS odbywa się za pomocą
prostych w obsłudze interfejsów użytkownika, w postaci serwisu WWW.
Cookies (ciasteczka) - to niewielkie informacje tekstowe, wysyłane przez serwer WWW i
zapisywane po stronie użytkownika (zazwyczaj na twardym dysku). Domyślne parametry
ciasteczek pozwalają na odczytanie informacji w nich zawartych jedynie serwerowi, który je
utworzył.
CSS - kaskadowe arkusze stylów (ang. Cascading Style Sheets). Język służący do opisu formy
prezentacji (wyświetlania) strony WWW.
E-book - publikacja elektroniczna. Treść zapisana w formie elektronicznej, przeznaczona do
odczytania za pomocą odpowiedniego oprogramowania zainstalowanego w urządzeniu
komputerowym.
eDostępność – ogólne zasady kreowania systemów informatycznych dla użytkowników
niepełnosprawnych spełniające wymogi WCAG 1.0.
Edytor WYSIWYG - edytor umożliwiający wprowadzanie i edycję treści (formatowanie tekstu,
wstawianie odnośników, plików graficznych, wideo i audio) bez znajomości składni języka
HTML. Edytor WYSIWYG pozwala uzyskać wynik publikacji na stronie WWW identyczny lub
bardzo zbliżony do obrazu na ekranie podczas edycji.
Favicon – (ang. FAVourite ICON - ulubiona ikona) - jest to znak graficzny, który znajduje się tuż
obok adresu WWW w pasku adresu przeglądarki internetowej lub tuż obok tytułu strony w pasku
tytułowym karty przeglądarki.
Formularz - moduł wchodzący w skład strony internetowej z rubrykami do wypełnienia.
Funkcjonalność - funkcja, która zostanie zrealizowana w LSI, Extranecie, CMS za pomocą
danego modułu.
GW - Generator Wniosków - funkcjonalność wypełniania i generowania Wniosku o
dofinansowanie dla działania 8.1 i 8.2 PO IG w interfejsie użytkownika Systemu,
HTML - hipertekstowy język znaczników (ang. HyperText Markup Language). Język
wykorzystywany do tworzenia stron internetowych.
Instytucja Pośrednicząca (IP) - Minister Spraw Wewnętrznych i Administracji (MSWiA)
nadzoruje prawidłowość procesu wyboru i realizacji projektów – w szczególności: zatwierdza
dokumenty związane z realizacją działania, uczestniczy w kontroli systemowej IW oraz w
kontrolach realizacji projektów na miejscu, akceptuje przekazywane przez IW listy projektów
rekomendowanych do dofinansowania. Uczestniczy w ewaluacji wdrażania.
Instytucja Wdrażająca (IW) - Polska Agencja Rozwoju Przedsiębiorczości (PARP), odpowiada
za proces prawidłowej realizacji działania w zakresie powierzonych jej zadań. Powołuje członków
Komisji Konkursowej w RIF. Weryfikuje przygotowane przez Regionalne Instytucje Finansujące
listy projektów rekomendowanych do dofinansowania, które następnie przekazuje IP do
akceptacji. Uczestniczy w rozpatrywaniu odwołań zgodnie z procedurą odwoławczą zatwierdzoną
przez IZ. Przeprowadza wyrywkową kontrolę realizacji projektów na miejscu. Weryfikuje wnioski
beneficjentów o płatność i realizuje płatności na rzecz beneficjentów. Odpowiada za przepływ
informacji pomiędzy IW a Regionalnymi Instytucjami Finansującymi. Koordynuje działania
informacyjne i promocyjne.
Instytucja Zarządzająca (IZ) - Minister Rozwoju Regionalnego, zatwierdza dokumenty
związane z realizacją działania, uczestniczy w kontroli systemowej IP i IW, zatwierdza
przekazywane przez IP listy projektów rekomendowanych do dofinansowania.
Strona 12 z 56
23. Interfejs użytkownika - środowisko wykorzystywane do interakcji użytkownika z urządzeniem,
programem.
24. Kontrola finansowa - Mechanizmy i środki zapewniające prawidłowe funkcjonowanie procesu
gromadzenia i dysponowania funduszami Wspólnoty, jak również publicznymi środkami
krajowymi. Kontrola finansowa obejmuje kontrolę zarządzania oraz audyt.
25. Kwalifikowalność wydatków - Spełnienie przez wydatki poniesione w ramach działań lub
operacji określonych warunków, do których należą: (1) zgodność z wymogami Funduszu, z
którego miałaby pochodzić pomoc; (2) spójność planowanych działań lub operacji
z zatwierdzonym programem operacyjnym.
26. Link, url - w technologiach komputerowych hiperłącze - element nawigacyjny dający możliwości
przemieszczania się pomiędzy elementami strony internetowej. Klikniecie lub naciśnięcie
powoduje przejście do wybranego celu.
27. LSI – Lokalny System Informatyczny u Zamawiającego i obsługujący działania 8.1 i 8.2 PO IG,
28. Moderowanie treści – edycja lub usuwanie treści niepożądanych (np. niecenzuralne słowa,
reklamy) z Extranetu.
29. Moduł – pojedynczy element, z którego zbudowany jest LSI, Extranet, CMS.
30. Monitorowanie - Proces systematycznego zbierania i analizowania wiarygodnych informacji
finansowych i statystycznych dotyczących wdrażania projektów, którego celem jest zapewnienie
zgodności realizacji projektów i programu z wcześniej zatwierdzonymi założeniami realizacji.
31. Nieprawidłowości - Jakiekolwiek naruszenie przepisu prawa wspólnotowego wynikające z
działania lub zaniechania podmiotu gospodarczego, które powoduje lub mogłoby spowodować
szkodę w budżecie ogólnym Unii Europejskiej w drodze finansowania nieuzasadnionego wydatku
z budżetu ogólnego, zgodnie z rozporządzeniem rady 1083/2006.
32. Platforma CMS PARP - system informatyczny PARP wdrożony w ramach umowy na
„Zaprojektowanie, wykonanie i wdrożenie portalu wspierającego realizację działań 8.1 i 8.2
Programu Operacyjnego Innowacyjna Gospodarka (PO IG) z wykorzystaniem systemu
zarządzania treścią stron internetowych CMS”,
33. Plik graficzny– każdy plik graficzny (a co najmniej te z rozszerzeniem PNG, JPEG (JPG), GIF
(wersja 98a), ICO) występujący w Extranecie lub mający być w nim umieszczony.
34. PO IG - Program Operacyjny Innowacyjna Gospodarka,
35. Polska Agencja Rozwoju Przedsiębiorczości (PARP) - Agencja utworzona na podstawie
przepisów ustawy z dnia 9 listopada 2000 r. o utworzeniu Polskiej Agencji Rozwoju
Przedsiębiorczości (Dz. U. Nr 109, poz. 1158, z 2002 r. Nr 25, poz. 253, Nr 66, poz. 596 i Nr 216,
poz. 1824 oraz z 2004 r. Nr 145, poz.1537).
36. Portal - portal informacyjny Web.gov.pl wspierający realizację działań 8.1 i 8.2 PO IG
zarządzany przez Platformę CMS PARP,
37. Programowanie - Proces organizowania, podejmowania decyzji i finansowania, prowadzony w
kilku etapach w celu wdrażania, na bazie wieloletniej współpracy, wspólnych działań Wspólnoty i
państw członkowskich dla osiągnięcia określonych celów znajdujący wyraz w przygotowaniu
dokumentów programowych.
38. Projekt - Przedsięwzięcie realizowane w ramach programu operacyjnego na podstawie umowy o
dofinansowanie, zawieranej między beneficjentem a instytucją zarządzającą, instytucją
pośredniczącą, instytucją wdrażającą (instytucją pośredniczącą II stopnia).
39. Projekt Techniczny Systemu - dokument opisujący szczegółowo planowane rozwiązanie
techniczne Systemu przygotowany przez Wykonawcę,
40. Przeglądarka (przeglądarka internetowa) – program komputerowy, służący do pobierania i
wyświetlania internetowych stron internetowych.
41. Punkty Konsultacyjne (PK) – udzielają potencjalnym wnioskodawcom informacji nt.
instrumentów wsparcia dostępnych w ramach poszczególnych Programów Operacyjnych, zasad
Strona 13 z 56
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
udzielania wsparcia oraz typów projektów kwalifikujących się do objęcia pomocą w ramach
poszczególnych działań, informują, jakie są najczęstsze błędy popełniane przez wnioskodawców.
Regionalna Instytucja Finansująca (RIF) - przyjmuje wnioski o dofinansowanie i dokonuje
oceny formalnej i merytorycznej, zgodnie z kryteriami wyboru projektów zatwierdzonymi przez
Komitet Monitorujący PO IG. Zapewnia obsługę Komisji Konkursowej, przygotowuje i
przekazuje do IW listę projektów rekomendowanych do dofinansowania, weryfikuje dokumenty
dostarczone przez wnioskodawcę na etapie podpisywania umowy o dofinansowanie, przygotowuje
i podpisuje umowy o dofinansowanie. Przyjmuje, weryfikuje i przekazuje do IW wnioski o
płatność. Rekomenduje IW dokonanie płatności na rzecz beneficjentów z tytułu realizacji
projektu. Prowadzi monitoring realizowanych projektów. Uczestniczy w realizacji działań
informacyjnych i promocyjnych.
RSS – (ang. Really Simple Syndication - RSS 2.0), rodzina języków znacznikowych służących do
publikacji często zmieniających się treści.
Sonda internetowa - interaktywny element stron WWW. Sonda ma formę prostej ankiety
składającej się z jednego pytania z możliwością jednej lub kilku odpowiedzi.
Specyfikacja Funkcjonalna Systemu - dokument opisujący szczegółowo planowane funkcje
Systemu przygotowany przez Wykonawcę,
Sprawozdawczość - Sprawozdawanie z postępu wdrażania programu lub projektów
współfinansowanych z funduszy pomocowych. Sprawozdawczość obejmuje zbieranie informacji
dotyczących wdrażania poszczególnych programów z uwzględnieniem działań/grup operacji, osi
priorytetowych, w postaci danych liczbowych, finansowych, wskaźników i innego rodzaju
informacji oraz przekazywanie ich odpowiednim instytucjom w określonej formie i terminach dla
potrzeb monitorowania realizacji programu operacyjnego na każdym poziomie jego wdrażania.
Superadministrator - użytkownik dysponujący najwyższymi uprawnieniami w Systemie.
System – całość struktury której rdzeniem są gotowe elementy: CMS, Portal, elementy będące
przedmiotem zamówienia LSI, wraz z budowanym równolegle Extranetem oraz planowane
rozszerzenia: platforma promocyjna.
System Informatyczny Monitoringu i Kontroli Finansowej Funduszy Strukturalnych i
Funduszu Spójności (SIMIK) - Narzędzie informatyczne umożliwiające zarządzanie,
monitorowanie, kontrolę i ocenę programów operacyjnych współfinansowanych z funduszy
strukturalnych
Tag - słowo kluczowe opisujące konkretną treść. Każdej jednostce informacji można przypisać
dowolną liczbę tagów. Otagowanie oznacza proces polegający na opisaniu danego elementu lub
treści za pomocą słów kluczowych.
Umowa - umowa pomiędzy Zamawiającym a Wykonawcą, na podstawie której Wykonawca
realizuje Projekt,
UU (ang. Unique User) liczba unikalnych użytkowników - termin określający prawdopodobną
liczbę pojedynczych osób odwiedzających Portal, identyfikowanych na podstawie mechanizmu
cookies.
Użytkownik wewnętrzny – użytkownik Systemu posiadający swoje konto. Pracownik PARP
mających wpływ na kreowanie wizerunku i treści Systemu: administrator, redaktor. Mogący
kreować, redagować i zarządzać, informacjami publikowanymi na Portalu.
Użytkownik zewnętrzny (społecznościowy) – każdy użytkownik, który uzyskał dostęp do
Systemu; beneficjent, ekspert PARP, przedstawiciel RIF, MRR, MSWiA, internauta poszukujący
konkretnych rozwiązań i wiedzy o przedsiębiorczości elektronicznej, technologiach B2B,
pozyskiwaniu funduszy w ramach działań 8.1 i 8.2 Programu Operacyjnego Innowacyjna
Gospodarka.
Wdrażanie - Urzeczywistnienie projektu programu operacyjnego. Wdrażaniem są wszystkie
czynności związane z realizacją, sprawozdawczością, kontrolą, oceną i koordynacją działań. Etap
wdrażania następuje po etapie programowania.
Strona 14 z 56
56. WIKI - moduł funkcjonalny pozwalający w prosty sposób współtworzyć treść informacyjną przez
wielu użytkowników. Każdy uprawniony użytkownik WIKI ma możliwość dodawania stron,
modyfikowania już istniejących. Dzięki rejestrowaniu każdej z wersji stron w ramach historii
zmian oraz funkcjonalności porównywania wersji każdy czytelnik i współtwórca treści może
zobaczyć jak przyrastała treść.
57. Wniosek o dofinansowanie - wniosek o dofinansowanie realizacji projektu, przygotowany przez
wnioskodawcę zgodnie z Instrukcją wypełniania wniosku, na formularzu zamieszczonym w
powszechnie dostępnej sieci tele-informatycznej. Wniosek zawiera m.in.: informacje o działaniach
planowanych do realizacji, budżet wraz z wyszczególnieniem kategorii wydatków
kwalifikowanych i źródłami finansowania, wskaźniki produktu i rezultatu, informacje na temat
zgodności realizacji projektu z politykami horyzontalnymi.
58. Wniosek o płatność - Dokument przedkładany przez zobowiązanego do tego Beneficjenta celem
rozliczenia otrzymanych środków lub refundacji poniesionych wydatków, dokument służyć może
także wnioskowaniu o płatność zaliczkową.
59. Wnioskodawca - przygotowuje wniosek wraz z załacznikami i składa go do Regionalnej
Instytucji Finansującej właściwej z punktu widzenia miejsca realizacji projektu.
60. Wspólny Słownik Zamówień - Zgodnie z rozporządzeniem (WE) Parlamentu Europejskiego i
Rady nr 2195/2002 z dnia 5 listopada 2002 r. w sprawie Wspólnego Słownika Zamówień CPV
(Dz. Urz. WE L 340 z 16.12.2002, str. 0001-0562, Dz. Urz. UE Polskie wydanie specjalne, rozdz.
6, t. 7, str. 3, z późn. zm.).
61. Wydatki kwalifikowane - Wydatki, których poniesienie jest merytorycznie uzasadnione i które
spełniają kryteria zasadności wyznaczone przez Instytucję Zarządzającą.
62. Wykonawca - Osoba fizyczna, osoba prawna albo jednostka organizacyjna nie posiadająca
osobowości prawnej, która ubiega się o udzielenie zamówienia publicznego, złożyła ofertę lub
zawarła umowę w sprawie zamówienia publicznego.
4.3 Wymogi dotyczące estetyki i ergonomii
Interfejs użytkownika, w szczególności jego wygląd zewnętrzny, sposób nawigacji powinien być
spójny z interfejsem Portalu i zgodny z założeniami SIWZ na „Zaprojektowanie, wykonanie i
wdrożenie portalu wspierającego realizację działań 8.1 i 8.2 Programu Operacyjnego Innowacyjna
(dokumentacja przetargowa dostępna pod adresem http://bip.parp.gov.pl/index/more/5700),
Elementy graficzne Systemu winny spełniać wymagania:
1. System ma posiadać minimalistyczną, nieprzysłaniającą treści oprawę graficzną zgodną
z systemem identyfikacji wizualnej PARP 1 oraz dotychczas wdrożonym portalem.
2. Wygląd Systemu ma kojarzyć się użytkownikom z rzetelnymi informacjami, innowacyjnością
i dynamizmem, jednocześnie podkreślając profesjonalizm i kreując go na źródło wiarygodnej
wiedzy.
3. System będzie używał Favicon zaprojektowany dla portalu Web.gov.pl.
Nowe moduły Systemu powinny być zaprojektowane, skonfigurowanie i przedstawione tak, aby z
punktu widzenia użytkowników stanowiły jego integralną część.
1
Wytyczne dostępne na stronie http://www.parp.gov.pl/index/index/101
Strona 15 z 56
4.4 Interfejs użytkownika
Wykonawca wykona projekt interfejsu użytkownika Systemu zgodnie z zawartymi poniżej
wytycznymi i definicjami, zawierający odpowiednio, z podziałem na portal wewnętrzny (strefę
administracyjną) oraz część zewnętrzną (strefę użytkowników)
1. Mapa całości Serwisu.
2. Logika nawigacji w serwisie
3. Struktura menu (bądź odpowiednie struktury menu), wynikająca z logiki nawigacji.
4. Projekt rozmieszczenia poszczególnych elementów interfejsu na ekranie
5. Projekt graficzny kompletnych layoutów (z opisem użytych w nim elementów).
a) Strony startowej,
b) Generatora wniosków
4.4.1 Wymagania dotyczące Interfejsu użytkownika
Wykonawca przedstawi projekt interfejsu użytkownika, kierując się zawartymi w tym rozdziale
wskazówkami i informacjami.
Jako nadrzędne kryteria stawiane interfejsowi użytkownika Systemu Zamawiający rozumie:
1. Intuicyjność:
a) Interfejs użytkownika powinien nawiązywać do standardowych reguł budowy GUI (Graphical
User Interface), przyzwyczajeń użytkownika wynikających z codziennego korzystania
z komputera, oraz przyzwyczajeń użytkownika związanych z wykonywanymi na co dzień
czynnościami wynikającymi z obowiązków zawodowych,
b) Ikony zastosowane w interfejsie powinny być jasnymi, zrozumiałymi dla użytkownika
symbolami.
2. Spójność:
a) Każdy element interfejsu dotyczący konkretnego rodzaju czynności powinien być opisany
w ten sam sposób, bez względu na miejsce aplikacji, w którym się pojawia,
b) W każdym miejscu aplikacji (każdym module aplikacji) winien być zachowany spójny układ
elementów interfejsu,
c) We wszystkich modułach Systemu winien być stosowany ten sam zestaw czytelnych
dla użytkownika ikon.
3. Prostota:
Interfejs użytkownika oraz wszystkie jego elementy powinny układać się w prosty i logiczny
układ, zaś zastosowane terminy i określenia winny w jasny i jednoznaczny sposób informować
użytkownika o koniecznych do wykonania przez niego operacjach.
4. Ochrona:
Interfejs użytkownika powinien być tak skonstruowany, by ustrzec użytkowników przez
wykonaniem nieprawidłowej czynności poprzez odpowiedni układ oraz kolejność koniecznych
do wykonania operacji.
5. Tolerancja
Interfejs użytkownika winien być tak skonstruowany, by "wybaczać" użytkownikowi popełnione
przez niego błędy, na przykład przez zapytanie, czy powinno się zachować zmiany w dokumencie,
który użytkownik chce właśnie zamknąć.
6. Lekkość:
Strona 16 z 56
a) Ze względu na specyfikę aplikacji LSI, działających z wykorzystaniem przeglądarki sieci Web
oraz Internetu jako medium, wszystkie elementy interfejsu powinny być maksymalnie
zoptymalizowane,
b) Długie strony winny umożliwiać wydruk całości treści.
7. Informacje zwrotne i dialog:
Interfejs powinien zapewniać wyświetlanie informacji zwrotnych dotyczących działań
użytkownika i jednocześnie prowadzić "dialog" z użytkownikiem poprzez wyświetlanie
dodatkowych podpowiedzi i pytań podczas wykonywanych przez niego operacji.
8. Logika:
Np. interfejs użytkownika powinien być tak zbudowany, aby formularze wymagające
wprowadzania dużej ilości danych były podzielone na zakładki w logiczny sposób grupujące pola
formularzy.
4.4.2 E-Dostępność
Kierując się wytycznymi WAI organizacji W3C określającymi zasady kreowania systemów
internetowych dla użytkowników niepełnosprawnych wykonawca przedstawi projekt interfejsu
graficznego użytkownika w wersji dla osób niedowidzących lub słabowidzących.
1. System musi spełniać dyrektywy e-Dostępności 2.
2. Aktywacja interfejsu spełniającego wymagania e-Dostępności winna odbywać się w sposób
intuicyjny i widoczny przede wszystkim dla osób niepełnosprawnych.
3. Przy przejściu pomiędzy częściami Systemu (Extranet, LSI, Portal, platforma promocyjna) muszą
być przekazywane/pobierane informacje o wybranym interfejsie.
4.4.3 Technologia zastosowana do budowy interfejsu
1. Graficzny interfejs użytkownika powinien być zbudowany w języku HTML, zgodnie
ze standardami W3C.
2. Interfejs powinien być dostosowany przede wszystkim do przeglądarek Internet Explorer
(w wersji 6.x i wyższych), Firefox (w wersji 3.x i wyższych), Opera (w wersji 9.x i wyższych),
przy czym wymagane jest od Wykonawcy zapewnienie 100% funkcjonalności interfejsu
użytkownika w tych przeglądarkach.
3. Zamawiający dopuszcza użycie m.in. języka skryptowego JavaScript, Ajax i innych po stronie
użytkownika w celu polepszenia funkcjonalności interfejsu użytkownika.
4. Konfigurowanie szaty graficznej winno odbywać się jedynie za pomocą szablonów wyglądu dla
modułów oraz arkuszy styli CSS administrowanych z poziomu Systemu CMS portalu.
4.4.4 Nawigacja
System nawigacji Systemu musi być logiczny i przejrzysty. Zamawiający wymaga
od Wykonawcy zapewnienia następujących wymagań dotyczących nawigacji w Systemie:
1. Jednoznaczne opisy nawigacji:
a) LSI musi zapewniać użytkownikowi czytelne i zrozumiałe hasła i elementy nawigacyjne,
2
Zgodnie z międzynarodowymi wytycznymi dotyczące dostępności zawartości stron internetowych, (ang. Web Content Accessibility
Guidelines 1.0) określonymi przez organizację W3C (World Wide Web Consortium). Internet http://www.w3.org/TR/WAIWEBCONTENT/
Strona 17 z 56
b) LSI musi zapewniać użytkownikowi jednoznaczną i czytelną informację o tym,
w którym miejscu LSI w danym momencie się znajduje,
c) System musi zapewniać użytkownikowi zawsze dostęp do:
i. Strony startowej,
ii. Mechanizmu wylogowania,
iii. Poziomu nadrzędnego,
iv. Elementów głównych aktualnego poziomu,
v. Elementów sąsiednich,
vi. Poziomu podrzędnego.
vii. Ścieżki dostępu (breadcrumbs)
Elementy te powinny zawsze być umieszczone w stałych miejscach ekranu.
2. Komponenty widoczne na wielu stronach takie jak menu, zakładki itp. powinny znajdować się
zawsze w tym samym miejscu i nie mogą znacząco różnić się wyglądem.
3. Przycisk „cofnij/wróć” w przeglądarce nie może być blokowany i musi wykonywać akcje zgodne
z oczekiwaniem użytkownika: przenosić go na stronę poprzednią lub następną - przy zachowaniu
względów bezpieczeństwa (po wylogowaniu użytkownikowi nie wyświetli się poprzednia
zawartość). Przy przejściach przyciskiem „cofnij/wróć” w przeglądarce jeśli użytkownik pracuje
na formularzach w zakładkach ich wypełniona treść jest zapisywana.
4. Stan zalogowania użytkownika winien być widoczny na portalu:
a) użytkownik gość – z dostępną opcją: zaloguj, zarejestruj (oraz odnośnik do informacji z
prezentacją korzyści z rejestracji), przypomnij hasło,
b) użytkownik zalogowany „Jan Kowalski” – z dostępną opcją wyloguj, mój profil.
5. Bezpośredni dostęp:
a) Nawigacja powinna umożliwiać szybki dostęp do wszystkich informacji niezależnie
od ich umiejscowienia w strukturze informacyjnej Portalu.
Wykonawca rozważy możliwość wykorzystania stopki do celów użytkowych jako powtórzonej
nawigacji (tzw. fat footer), breadcrumbs i innych dobrych praktykach związanych z nawigacją jeśli
będą zasadne.
4.4.5 Graficzne rozmieszczenie elementów interfejsu
Zamawiający będzie wymagał od Wykonawcy dostarczenia graficznego projektu rozmieszczenia
poszczególnych elementów na ekranie. Elementy, na które Wykonawca zwróci szczególną uwagę to:
1. Hierarchia wizualna,
2. Siatka rozmieszczenie stałych elementów,
3. Nagłówki i stopki stron,
4. Ramki, jeżeli interfejs ma być zbudowany z użyciem ramek, Wykonawca musi podać
uzasadnienie takiego użycia,
5. Rozmieszczenie i funkcjonalność przycisków stałych (np. przycisk wydruku lub eksportu
zawartości strony).
Strona 18 z 56
4.5 Wymagania dotyczące użyteczności
4.5.1 Formularze
1. Formularze muszą posiadać funkcję sprawdzania ich poprawności w trakcie wypełniania.
Użytkownik zostanie poinformowany o błędzie po wprowadzeniu niewłaściwej lub niepełnej
informacji w pole formularza.
2. Komunikat o błędzie wskaże użytkownikowi miejsce popełnienia błędu poprzez dodanie szerszej
ramki i podświetlenie pola, w którym popełniono błąd oraz dodania komentarza do pola w,
którym został popełniony błąd zawierającego instrukcję korekty. Użytkownik nie powinien
musieć wypełniać ponownie pól, które uprzednio wypełnił poprawnie.
3. Formularze wykorzystywane na stronach muszą przechowywać dane wpisywane przez
użytkownika, tak aby w sytuacji nieplanowanego przerwania procesu wypełniania formularza
wprowadzone informacje były ponownie dostępne dla użytkownika w trakcie danej sesji.
Szczególnie dotyczy to formularzy wypełnianych w zakładkach. Przy przejściu pomiędzy
zakładkami dane wypełnione powinny być zapisywane.
4. Pola obowiązkowe do wypełnienia w formularzach muszą być wyraźnie oznaczone.
5. Użytkownik powinien być poinformowany o formacie w jakim System oczekuje od niego danych.
Zaleca się używanie ogólnie przyjętych dobrych wzorców projektowych, które minimalizują błędy
użytkownika przy wypełnianiu formularzy - np. wybór daty przez kalendarz opisany w Zbiorze
Wzorców
Projektowych
Yahoo
(http://developer.yahoo.com/ypatterns/pattern.php?pattern=calendar)
6. Administrator może dodać biblioteki walidacyjne (sprawdzające poprawność wypełnionych
danych).
7. Formularze muszą być zabezpieczone przed wprowadzaniem niebezpiecznych procedur
wewnętrznych.
4.5.2 Odnośniki
1. Odnośniki na stronie muszą być odpowiednio wyróżnione graficznie (np. podkreślone,
zaznaczone innym kolorem).
2. Odnośniki muszą być odpowiednio nazwane i opisane. Muszą posiadać atrybut „title”.
3. Odnośniki powinny być budowane bez użycia JavaScript, jeżeli konieczne jest jednak użycie
JavaScript w odnośniku, parametr href nie może być pusty.
4. Odnośniki zawarte w tekście, które prowadzą do stron już odwiedzonych w trakcie danej sesji,
muszą być oznaczone graficznie (np. zaznaczone innym kolorem).
5. Wszystkie odnośniki kierujące użytkownika na stronę wewnątrz Systemu muszą być domyślnie
otwierane w tym samym oknie co System.
6. Wszystkie odnośniki kierujące poza System powinny być otwierane w nowych oknach.
7. W listach wymieniających pojedyncze treści gdy poza tytułem treści jest ikona/plik graficzny
reprezentujący każdą z pozycji listy - dana ikona/ plik graficzny musi być linkiem
do wymienianej treści np. artykułu, aktualności (podobnie jak tytuł).
4.5.3 Typografia i formatowanie tekstu
1. Czcionki użyte na stronie powinny mieć wielkość minimum 12 punktów, zaleca się używanie
fontów bezszeryfowych,
2. Nie należy używać pogrubienia do całych akapitów.
3. Należy unikać czcionek, które nie są domyślnie zainstalowane w systemach operacyjnych
z rodziny Microsoft Windows lub systemach równoważnych.
4. Kolor tekstu musi być kontrastowy z tłem, preferowany jest czarny lub ciemnoszary tekst
na białym tle.
Strona 19 z 56
5. Czcionki użyte do przygotowania szaty graficznej będą zgodne z systemem identyfikacji
wizualnej PARP
4.5.4 Układ elementów
1. Treści na stronie głównej powinny być tak rozmieszczone, aby użytkownik przewijał stronę
jak najmniejszą ilość razy.
2. Najważniejsze funkcjonalności i treści powinny być łatwo dostępne dla użytkownika
(w odległości maksymalnie 3 kliknięć od strony głównej).
3. System nie powinien przewijać się w poziomie w przeglądarce – maksymalna szerokość Portalu
to 980 pikseli.
4. Szata graficzna LSI musi być zoptymalizowana do wyświetlania w najpopularniejszej obecnie
rozdzielczości monitora (1024x768 pikseli).
5. W przypadku wprowadzania dużych ilości danych (np. w Generatorze Wniosków) arkusze z
kolejnymi danymi powinny być zorganizowane w zakładkach.
4.5.5 Grafika
1. Pliki graficzne, które są elementami treści informacyjnej (zdjęcia, diagramy, wykresy, ilustracje)
na stronie powinny mieć wypełniony parametr „alt”.
2. Jeśli plik graficzny, który chcemy wyświetlić na stronie, jest duży, należy umieszczać jego
miniaturkę (stworzoną przez system w momencie dodawania grafiki), będącą odnośnikiem do
zdjęcia o wymiarach dostosowanych do wielkości okna przeglądarki użytkownika.
4.5.6 Komunikaty o błędach
1. Komunikaty wyświetlane przez System (np. komunikat o błędach, informacje zwracane przez
wyszukiwarkę) muszą zrozumiale informować użytkownika o tym, jakie jest źródło błędu i jaka
reakcja na błąd jest zalecana przez System.
2. Na stronach błędów (m.in. 401, 403, 404, 500, 503) muszą być wyświetlone zrozumiałe dla
użytkownika komunikaty o błędach, mapa Portalu i pole wyszukiwarki. Treść tych stron powinna
być konfigurowalna.
3. Użytkownicy muszą otrzymywać zrozumiałą informację, jeśli rozpoczną wyszukiwanie
nie wpisując w pole wyszukiwarki tekstu.
4. Użytkownicy muszą otrzymywać zrozumiały komunikat w przypadku braku wyników
wyszukiwania.
4.6 Wymagania techniczne dotyczące Systemu
Wykonawca, po dokonaniu analizy możliwości technicznych rozbudowy istniejącego Systemu LSI i
Platformy CMS PARP przedstawi ewentualne rekomendacje zmian w platformie sprzętowej i
oprogramowaniu. Kompatybilność Systemu (założeń projektowych i wykonania Systemu) z Platformą
CMS PARP dotyczy takich aspektów jak:
a) Użyty system operacyjny,
b) Użyty serwer WWW i baz danych,
c) Polityka bezpieczeństwa przechowywanych danych i Systemu,
d) Zapewnienie ciągłości pracy,
e) Kopie bezpieczeństwa i przywracanie danych.
Podstawowy opis istniejącego Systemu LSI stanowi załącznik nr 1. Wykonawca może się oprzeć na
istniejących modułach LSI, może też wykonać wszystkie moduły samodzielnie. Wykorzystanie
istniejących modułów LSI nie może zmniejszać funkcjonalności całego systemu, ani być traktowane
jako ograniczenie projektowe.
Strona 20 z 56
System przy podstawowym założeniu mobilności, oszczędności i bezpieczeństwa, winien spełniać
wymagania techniczne w oparciu o przewidywaną obciążalność Systemu wynikającą z liczby
użytkowników wewnętrznych (PARP, RIF, Redaktorzy) działających w systemie oraz pozostałych
użytkowników społecznościowych (beneficjenci, wnioskodawcy, potencjalni wnioskodawcy)
korzystających z Systemu, określoną podczas analizy potrzeb użytkowników, jednak nie mniejszą niż
20 000 użytkowników korzystających jednocześnie z Systemu.
4.6.1 Modułowa budowa Systemu
Ze względu na wymaganą elastyczność oraz możliwość rozbudowy wymaga się, aby:
1. System był zbudowany z modułów,
2. Do systemu można dodawać kolejne funkcjonalności,
3. Funkcjonalności modułów były rozszerzalne,
4. System pozwalał na łączenie ze sobą modułów w celu uzyskania pożądanych funkcjonalności,
5. Każdy moduł i funkcjonalność winna posiadać ustawienia w panelu administracyjnym
parametrów domyślnych.
4.6.2 Bezpieczeństwo Systemu
Ze względu na charakter danych przechowywanych, przetwarzanych i prezentowanych użytkownikom
przez System, System zapewniać będzie poziom bezpieczeństwa oraz wymagane prawem procedury
wynikające z następujących aktów prawnych:
1. Ustawa o ochronie danych osobowych z dnia 29 sierpnia 1997 r. z późniejszymi zmianami,
2. Rozporządzenie ministra spraw wewnętrznych i administracji z dnia 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, z późniejszymi zmianami.
Bezpieczeństwo rozumiane jest jako wielopłaszczyznowe zapewnienie bezpieczeństwa danych między
innymi poprzez:
1. Zabezpieczenie LSI przed włamaniami – system firewall.
2. Wykonywanie zapasowych kopii danych i ich przywracanie przez uprawnionych użytkowników
Zamawiającego i Wykonawcy, zgodnie z ich procedurami.
3. Zapewnienie ciągłości pracy LSI. Wymagana dostępność na poziomie 99,7% w skali roku, 100 %
w momentach krytycznych, tj. w trakcie naboru wniosków.
Ponadto, na bezpieczeństwo Systemu składają się również czynniki takie jak:
1. Bezpieczeństwo proponowanych systemów operacyjnych.
2. Bezpieczeństwo oprogramowania serwera baz danych.
3. Bezpieczeństwo oprogramowania serwera aplikacji.
4. Bezpieczeństwo oprogramowania serwera http.
Dostęp do LSI powinien być odpowiednio zabezpieczony, przynajmniej poprzez zastosowanie
następujących mechanizmów:
Strona 21 z 56
• nazwę użytkownika i hasło (identyfikacja użytkowników),
• komunikacja na linii klient-system zaszyfrowana przy pomocy SSL.
System powinien generować logi zawierające:
1. Informacje o istotnych działaniach poszczególnych użytkowników, takich jak:
a) logowanie,
b) dokonanie edycji danych (wpis nowych, zmiana, usunięcie), zawierające:
i. unikalną nazwę użytkownika,
ii. datę wykonania operacji,
iii. nazwę wykonywanej operacji.
iv. adres IP stacji roboczej użytkownika,
2. Informacje dotyczące:
a) pomyślnych prób zalogowania,
b) nieudanych prób zalogowania.
Ostania udana i ostania nieudana próba logowania musi być komunikowana użytkownikowi
3. Informacje o zablokowaniu konta użytkownika po przekroczeniu zadanej przez administratora
liczby nieudanych prób zalogowania.
4. Informacje o zmianie zasad bezpieczeństwa (wprowadzenie/edycja/usunięcie):
a) roli systemowej,
b) użytkownika,
c) grupy użytkowników,
d) praw dostępu do elementu LSI.
5. Eksport zestawień do plików (m.in. XLS, CSV, XML)
Wykonawca zapewni wysoki poziomu bezpieczeństwa Systemu uwzględniając m.in. powyższe
kryteria.
5 Moduły LSI
Celem Lokalnego Systemu Informatycznego (LSI) jest obsługa procesu złożenia wniosku o
dofinansowanie a następnie obsługa realizacji projektów wdrażanych w ramach działań 8.1 i 8.2
Programu Operacyjnego Innowacyjna Gospodarka. Zasilanie systemu danymi następuje w dużej
mierze poprzez beneficjenta (potencjalnego beneficjenta). Założeniem jest pełna kontrola nad
procesem dofinansowania – system rejestruje go od momentu złożenia wniosku o dofinansowanie,
poprzez etapy oceny, podpisywania umów, składanie wniosków o płatność aż do zakończenia
realizacji projektu i wypłatę ostatniej transzy dofinansowania oraz monitorowania rezultatów
projektów.
System zrealizowany zostanie jako rozbudowa istniejącego Systemu CMS o funkcjonalności LSI.
Wykonawca może bazować na istniejących już modułach LSI:
1. Modułu Generator Wniosków Aplikacyjnych
2. Modułu Generator Wniosków Płatniczych
3. Modułu Rejestracji Wniosków
4. Modułu Oceny Wniosków
Strona 22 z 56
Wykorzystanie w/w modułów nie może ograniczać oczekiwanej funkcjonalności Systemu.
Ilekroć pojawia
się w systemie
możliwość
wysłania
informacji/dokumentu
do
Wnioskodawcy/Beneficjenta system powinien umożliwiać także wysyłkę faxu do
Wnioskodawcy/Beneficjenta (na numer określony we wniosku), wraz z otrzymaniem potwierdzenia
odbioru, do czasu zakończenia umowy usługi fax powinny być wykonywane na serwerze faxów
Wykonawcy. Funkcjonalność tę można globalnie włączać i wyłączać na poziomie administracyjnym.
5.1 Słowniki statusów
W ramach modułów LSI używane są statusy wniosku. Statusy zależnie od odbiorcy podlegają
słownikowaniu. Statusy i ich przypisanie są definiowalne przez administratora. Słowniki statusów
mogą być wykorzystywane do statystyk, korespondencji, eksportów danych, ect. Statusy wymienione
w dokumencie i ich słownikowe odzwierciedlenie to:
Statsuy LSI
brak statusu
oceniany formalnie
Statusy „Moje wnioski”
wniosek został złożony
wniosek jest oceniany
formalnie
Statusy RIF
brak statusu
oceniany formalnie
wniosek jest
niekompletny
konfliktowy
wniosek jest niekompletny oceniany formalnie
brak statusu
formalnie
brak statusu
potrzebne uzupełnienie
do oceny formalnej
potrzebne uzupełnienie do oceniany formalnie
oceny formalnej
brak statusu
pozytywny formalnie
merytorycznie
w trakcje oceny
negatywny formalnie
wniosek został odrzucony negatywny formalnie
z powodów formalnych
brak statusu
ocena formalna wniosku
została oprotestowana
ocena formalna wniosku
została oprotestowana
brak statusu
konfliktowy
pozytywny formalnie
oceniany formalnie
Statusy KSI
brak statusu
brak statusu
potrzebne wyjaśnienia do potrzebne wyjaśnienia do
oceny merytorycznej
oceny merytorycznej
oceniany merytorycznie w trakcje oceny
wycofany
wycofany
wycofany
odrzucony (jeśli został
wycofany po
pozytywnym przejściu
oceny formalnej)
brak statusu (jeśli
został wycofany przed
pozytywnym przejściem
oceny formalnej)
rekomendowany
wniosek został
pozytywnie oceniony
merytorycznie
rekomendowany
Strona 23 z 56
zatwierdzony
nierekomendowany
wniosek nie uzyskał
pozytywnej oceny
merytorycznej
nierekomendowany
ocena merytoryczna
wniosku została
oprotestowana
ocena merytoryczna
wniosku została
oprotestowana
oceniany merytorycznie w trakcje oceny
odrzucony
wniosek został odrzucony wniosek został odrzucony nierekomendowany
(po proteście)
odrzucony
potrzebne dokumenty do
umowy
potrzebne dokumenty do
umowy
umowa w
przygotowaniu
zatwierdzony
gotowa umowa
rezygnacja z
dofinansowania
gotowa umowa
rezygnacja z
dofinansowania
gotowa umowa
rezygnacja z
dofinansowania
zatwierdzony
odrzucony
projekt w trakcie
realizacji
projekt w realizacji
projekt w trakcie
realizacji
zatwierdzony
wniosek o rozwiązanie
umowy
wniosek o rozwiązanie
umowy
projekt w trakcje
realizacji
zatwierdzony
umowa rozwiązana
projekt zakończony
umowa rozwiązana
projekt zakończony
umowa rozwiązana
projekt zakończony
zatwierdzony
zatwierdzony
5.2 Moduł obsługi konkursów
5.2.1 Funkcjonalność „zarządzanie konkursami”
Nabór wniosków o dofinansowanie rozpoczyna się od ogłoszenia konkursu. Ustalany jest
harmonogram konkursów na dłuższy okres lecz może on ulec zmianie. System LSI będzie
ewidencjonował ogłaszane konkursy oraz umożliwiał ich harmonogramowanie.
Moduł musi posiadać możliwość określania operatorów (uprawnionych użytkowników)
poszczególnych osi/działań/priorytetów. Tę funkcję może sprawować moduł administracyjny.
5.2.1.1 Wymagania funkcjonalne
Ewidencjonowanie ogłaszanych konkursów.
Harmonogramowanie konkursów.
Rejestracja historii zamian danych konkursowych.
Określanie ram czasowych, otwieranie i zamykanie naborów (także automatyczne po spełnieniu
założeń określonych w otwarciu – np. po przekroczeniu kwoty środków (także określanych jako
przekroczenie procentowe alokacji przeznaczonej na działania w danej rundzie) przeznaczonych
na dany konkurs, możliwe określenie zamknięcia naboru 3 dni (wartość definiowalna) po
przekroczeniu kwoty środków przeznaczonych na dany konkurs. Wnioski są sumowane w
momencie zarejestrowania wniosku przez RIF.)
5. Możliwość raportowania z podziałem na:
1.
2.
3.
4.
- osie priorytetowe, działania, poddziałania,
Strona 24 z 56
- ramy czasowe.
- listy konkursów, także z podziałem wg statusu zawierającą informacje o poszczególnych
konkursach.
5.2.2 Funkcjonalność „rejestracja wniosków o dofinansowanie”
Przyjmowanie wniosków o dofinansowanie odbywa się na określony aktywny konkurs. Wnioski
przyjmowane od dnia ogłoszenia do dnia zamknięcia konkursu są rejestrowane i przechodzą do etapu
oceny. Wnioski które wpłyną po terminie konkursu są zapisywane w systemie ale zostaną odrzucone
na etapie oceny formalnej.
Beneficjent ma możliwość wypełnienia wniosku przed terminem ogłoszenia konkursu i aktywowania
go w momencie ogłoszenia konkursu.
1. Automatyczne nadanie numeru wniosku i informacji o dacie i godzinie wpłynięcia wniosku, w
tym z wykorzystaniem niezależnych od PARP i niepodważalnych procesowo źródeł znaczników
czasu.
2. System LSI przyporządkowuje nr do wniosku beneficjenta, podpina go pod konto w Extranecie beneficjent może mieć możliwość śledzenia stanu rozpatrywania tego dokumentu.
3. Możliwość wydrukowania etykiety adresowej wraz z numerem będącym identyfikatorem
beneficjenta w systemie.
4. Możliwość stworzenia listy adresowej w formacie CSV
5. Możliwość złożenia wniosku w postaci elektronicznej (w przeciągu 10 dni powinna zostać
dostarczona podpisana postać papierowa – możliwość konfiguracji dat brzegowych). Wersja
elektroniczna poprzez panel beneficjenta jest zapisywana w systemie z zablokowaną możliwością
zmian.
6. Możliwość rejestracji wpływu wersji papierowej z datą i godziną wpływu.
7. Możliwość wysłania informacji o uwagach i poleceniach poprawy dokumentacji. RIF oznacza
pola do poprawy wraz komentarzem. RIF może odznaczyć tylko te pola, które zostały wcześniej
globalnie ustawione jako możliwe do poprawy przez administratora systemu.
8. Korespondencja urzędu z beneficjentem na etapie oceny wniosków.
9. Informacje zawarte we wniosku muszą zawierać wszystkie dane z wniosków aplikacyjnych.
10. Walidacja pól wniosków.
11. Możliwość dołączenia modułu do podpisania wniosku kluczem certyfikowanym i
niecertyfikowanym przez Wnioskodawcę/Beneficjenta i przedstawicieli RIF/PARP oraz
utworzenie archiwum podpisanych cyfrowo dokumentów,
12. Blokowanie wniosku
5.2.2.2 Wymagania techniczne
1. Numer seryjny wpływowy powinien zawierać mechanizm wewnętrznego sprawdzania poprawności
(suma kontrolna etc). Mechanizm powinien być elastyczny na tyle, żeby w przyszłości można było
wprowadzić kody paskowe zgodne z EAN128.
5.2.3 Funkcjonalność „dekretacja wniosków do oceny formalnej”
Dekretacja wniosków realizowana jest w systemie przez upoważnioną osobę.
Strona 25 z 56
1. Wnioski są dekretowane na lokalne RIF-y zgodnie z lokalizacją wskazaną we wniosku. Na
poziomie administracyjnym możliwe jest przypisanie do każdej lokalizacji odpowiedniego RIF-u
dla każdego działania.
2. Tworzenie i zarządzanie listą pracowników z podziałem na osie, działania, poddziałania i
konkursy. Także na poziomie RIF-ów (oddzielne listy pracowników i uprawnionych do
dekretowania osób)
3. Przyporządkowanie ma się odbywać z uwzględnieniem wag obciążeniowych pracowników.
4. Dopuszczenie ewidencjonowanej korekty ręcznej w szczególnych sytuacjach przez uprawnionych
użytkowników.
5. Możliwość dodawania komentarzy do wniosku aplikacyjnego i do konkretnej dekretacji.
6. Grupowanie wniosków do dekretacji wg osi, działań, poddziałań, konkursów i dekretacja
wybranych grup.
7. Sortowanie wniosków wg terminu.
8. Publikacja, wydruk, eksport do Excela listy wpływu wniosków wraz z czasem wpływu.
9. Wydruk, eksport do Excela listy wniosków wraz z ich dekretacjami.
10. Zmiana statusu po dekretacji.
11. Generowanie informacji o zbliżających się terminach dekretacji oraz o ich przekroczeniu.
12. Przyporządkowanie dotyczy dwóch pracowników do każdego z etapów.
13. Po ustawieniu właściwej dekretacji – akceptacja lub jej odwołanie.
14. Ewidencja zmian dekretacji (po akceptacji).
15. Cofnięcie dekretacji – zamiana statusu wniosku. Wraca on do wniosków niezadekretowanych.
5.2.4 Funkcjonalność „ocena formalna”
Ocena formalna jest przeprowadzana przez dwóch pracowników RIF. Ocena jest przeprowadzana
metodą „zero-jedynkową”. Lista pól do oceny musi być zgodna z regulaminem przeprowadzania
konkursu dla danego priorytetu/działania/programu operacyjnego. W przypadku zmiany kryteriów
oceny (np. ocena punktowa) musi istnieć możliwość zmiany formy oceny w systemie LSI.
Od decyzji o nie zakwalifikowaniu projektu do dalszego etapu procedury oceny istnieje możliwość
wniesienia protestu.
W przypadku oceny poprawności formalnej możliwe jest jednorazowe skierowanie wniosku do
uzupełnienia lub poprawy stwierdzonych w nim braków lub błędów.
W przypadku uzupełnienia wniosku przez wnioskodawcę – po odblokowaniu możliwości poprawy
wniosku przez RIF wnioskowa składa ponownie wniosek poprawiony i jest on wczytywany do
systemu przez osobę, na którą jest zadekretowany. Procedura oceny poprawności jest powtarzana.
1. Nadawanie wnioskom odpowiedniego statusu:
a. oceniany formalnie – status nadany automatycznie momencie zadekretowania wniosku
b. wniosek jest niekompletny
c. potrzebne uzupełnienie do oceny formalnej
d. wniosek konfliktowy – zaznaczenie statusu powoduje przeniesienie oceny wniosku do
innego RIF, wybór RIF należy do PARP. Do tego statusu konieczne jest wprowadzenie
komentarza.
e. wycofany
f. negatywny formalnie
g. pozytywny formalnie – status w przypadku pozytywnej weryfikacji formalnej
Strona 26 z 56
h. inne określone przez administratora
2. Do statusów można wprowadzać wyjaśnienia (przy ewentualnym użyciu edytowalnego słownika).
3. Możliwość generowania, wysyłania i dołączenia do oceny wniosku pism przychodzących i
wychodzących dowolnym formacie.
4. Możliwość weryfikacji zgodności (identyczności) papierowej wersji wniosku o dofinansowanie z
elektroniczną za pomocą sumy kontrolnej.
5. Możliwość podglądu dokumentów w formacie PDF.
6. Możliwość dołączenia do oceny wniosku notatek dotyczących kontaktów z beneficjentem np.
treści rozmów telefonicznych lub innych ustaleń. Notatka powinna mieć możliwość ustawienia
przypomnienia pojawiającego się na wśród komunikatów systemowych.
7. Sortowanie spraw według terminu realizacji danego zadania. Generowanie ostrzeżeń odnośnie
przekroczenia lub zbliżania się terminów wśród komunikatów systemowych.
8. Personalizowana korespondencja seryjna do grup beneficjentów według co najmniej
następujących kryteriów:
a. statusu wniosku,
b. osi priorytetowej, działania, poddziałania,
c. konkursu,
d. ręcznego wyboru.
Wybór listy adresatów następuje wg w/w kryteriów i wg uprawnień danego użytkownika
wysyłającego korespondencje (RIF lokalny może wysyłać korespondencje lokalnie, ect.).
9. W ramach korespondencji możliwość korzystania z szablonów dokumentów. Możliwy jest też
upload dokumentu do systemu.
10. Raportowanie ze stanu zaawansowania oceny wniosków z podziałem co najmniej na:
a. statusy wniosków,
b. osie priorytetowe, działania, poddziałania,
c. konkursy,
d. osoby oceniające,
e. terminy wymaganej oceny, terminy faktycznej oceny, terminy dekretacji, przekroczenia
terminów
f. kategorie interwencji, itp.
Na powyższe kryteria powinno być możliwe założenie filtrów.
5.2.4.2 Wymagania funkcjonalne dotyczące oceny wniosków
1.
2.
3.
4.
5.
6.
7.
8.
System wyświetla wnioski do oceny dla zalogowanego pracownika Oddziału Oceny Projektów.
Ocena wykonywana jest sekwencyjnie przez osoby zadekretowane do oceny wniosku.
W przypadku rozbieżności decyduje ocena drugiej osoby (sprawdzającej).
Każdy z oceniających wprowadza ocenę TAK/NIE zgodnie z kartą oceny na formularzu
elektronicznym
Ocena negatywna pociąga za sobą konieczność wprowadzenia wyjaśnienia (przy ewentualnym
Użyciu edytowalnego słownika).
Wydruk karty oceny według definiowalnego wzoru z automatycznym wypełnianiem danymi
beneficjenta i osób oceniających wniosek, wraz z wprowadzonymi przez nich ocenami.
Wydruk formularza oceny z danymi beneficjenta oraz identyfikacją wniosku i danymi osób
oceniających.
W przypadku podjęcia decyzji o nie zakwalifikowaniu projektu do dalszego etapu procedury
oceny przesłanie informacji do Wnioskodawcy o możliwości wniesienia protestu, wraz z opisem
procedury i możliwymi dokumentami
Strona 27 z 56
5.2.4.3 Wymagania funkcjonalne dotyczące obsługi wniosków błędnych
1. W przypadku oceny poprawności formalnej możliwe jest skierowanie wniosku do uzupełnienia
lub poprawy stwierdzonych w nim braków lub błędów. Konieczność możliwości wysłania emailowego powiadomienia wnioskodawcy. Zmiana statusu na:
a. wniosek jest niekompletny lub
b. potrzebne uzupełnienie do oceny formalnej
c. inne określone przez administratora
2. W przypadku wystąpienia błędów podczas weryfikacji formalnej system umożliwi
wygenerowanie listy błędów wykrytych podczas weryfikacji.
3. W przypadku wystąpienia błędów system umożliwi określenie terminu złożenia kolejnej
(poprawionej) wersji wniosku o dofinansowanie.
4. W przypadku uzupełnienia wniosku przez beneficjenta – beneficjent składa ponownie wniosek
poprawiony i jest on ponownie dekretowany. Procedura oceny poprawności jest powtarzana.
Beneficjent wypełnia tylko te pola, które zostały oznaczone jako do poprawy przez osobę
oceniającą. Beneficjent na tym etapie może poprawić wniosek dwa razy (parametr edytowalny z
poziomu administratora)
5. Wydruk wezwania do poprawy wniosku wg definiowanego wzoru z automatycznym
wypełnianiem pól do poprawy, komentarza do pól, danymi beneficjenta oraz numerem wniosku
(automatyczne dołączanie pisma do korespondencji odnośnie tego wniosku).
6. Generowanie innych pism wg szablonu umożliwiającego automatyczne pobieranie danych z
wniosku. Możliwy jest też download i upload dokumentu z/do systemu.
7. Możliwość wysłania pism wymienionych w p. 5.1.4 w formie e-maila i poczty wewnętrznej.
8. Ewidencja wersji wniosków.
5.2.5 Funkcjonalność „dekretacja wniosków do oceny merytorycznej”
Dekretacja wniosków odbywa się analogicznie do dekretacji wniosków na ocenę formalną z tą
różnicą, że dekretuje się na konkretne posiedzenie Komisji Konkursowej. Komisja składa się z
Przewodniczącego, Sekretarza i co najmniej trzech członków. Komisja może się składać zarówno z
pracowników RIF jak i niezależnych ekspertów. Dekretacja odbywa się na dwóch członków komisji.
W przypadku niezgodności oceny dekretacja na trzeciego członka komisji.
1. Wnioski są dekretowane na Komisje Konkursowe lokalnych RIF-ów zgodnie z lokalizacją
wskazaną we wniosku. Każdy RIF posiada jedną Komisję Konkursową. Na poziomie
administracyjnym możliwe jest przypisanie do każdej lokalizacji odpowiedniego RIF-u dla
każdego działania.
2. Tworzenie i zarządzanie listą komisji konkursowych pracowników z podziałem na osie, działania,
poddziałania i konkursy. Także na poziomie RIF-ów (oddzielne listy pracowników i
uprawnionych do dekretowania osób)
3. Dopuszczenie ewidencjonowanej korekty ręcznej w szczególnych sytuacjach.
4. Możliwość dodawania komentarzy do wniosku aplikacyjnego i do konkretnej dekretacji.
5. Grupowanie wniosków do dekretacji wg osi, działań, poddziałań, konkursów i dekretacja
wybranych grup.
6. Sortowanie wniosków wg terminu.
7. Wydruk, eksport do Excela listy wniosków wraz z ich dekretacjami.
8. Zmiana statusu po dekretacji.
9. Generowanie informacji o zbliżających się terminach dekretacji oraz o ich przekroczeniu.
10. Przyporządkowanie dotyczy dwóch pracowników do każdego z etapów.
Strona 28 z 56
11. Po ustawieniu właściwej dekretacji – akceptacja lub jej odwołanie.
12. Ewidencja zmian dekretacji (po akceptacji).
13. Cofnięcie dekretacji – zamiana statusu wniosku. Wraca on do wniosków niezadekretowanych.
5.2.6 Funkcjonalność „ocena merytoryczna”
1.1. pozytywny formalnie – status nadawany w przypadku pozytywnej weryfikacji formalnej, w
części oceny formalnej
1.2. potrzebne wyjaśnienia do oceny merytorycznej
1.3. rekomendowany
1.4. nierekomendowany
1.5. wycofany
1.6. inne określone przez administratora
3. Możliwość dołączenia do oceny wniosku pism przychodzących i wychodzących w dowolnym
formacie.
4. Możliwość podglądu dokumentów w formacie PDF.
treści rozmów telefonicznych lub innych ustaleń. Notatka powinna mieć Możliwość ustawienia
przypomnienia (pojawiającego się na wśród komunikatów systemowych).
6. Sortowanie spraw według terminu realizacji danego zadania. Generowanie ostrzeżeń o
przekroczeniu lub zbliżaniu się końca terminów wśród komunikatów systemowych.
• statusu wniosku,
• osi priorytetowej, działania, poddziałania,
• konkursu,
• ręcznego wyboru.
8. Raportowanie ze stanu zaawansowania oceny wniosków według co z podziałem na:
• statusy wniosków,
• osie priorytetowe, działania, poddziałania,
• konkursy,
• osoby oceniające,
• terminy wymaganej oceny, terminy faktycznej oceny, terminy dekretacji, przekroczenia
terminów
• kategorie interwencji, itp.
Na powyższe kryteria powinno być możliwe założenie filtrów.
5.2.6.2 Wymagania funkcjonalne dotyczące oceny wniosków
1. Wniosek może być na etapie oceny merytorycznej przesłany do ponownej oceny formalnej.
2. Ocena merytoryczna dokonywana jest w systemie zero-jedynkowym – tak/nie. Do ocen można
dołączyć komentarz. Niespełnienie warunków powoduje automatyczne odrzucenie wniosku o
dofinansowanie projektu.
Strona 29 z 56
3. Ocena negatywna pociąga za sobą konieczność wprowadzenia wyjaśnienia (przy ewentualnym
użyciu edytowalnego słownika).
4. W przypadku rozbieżnej oceny przez dwóch oceniających wniosek jest przekazywany do oceny
trzeciemu członkowi komisji.
5. Na wniosek członków komisji przewodniczący może zwrócić się do wnioskodawcy o wyjaśnienia
(fax, e-mail). Wyjaśnienia stają się integralną częścią wniosku.
6. Komisja Konkursowa może dokonać korekty wydatków kwalifikujących się do objęcia
wsparciem. Ma prawo do redukcji do wysokości 10% łącznych wydatków. W takim przypadku do
decyzji musi być dodany komentarz. Zmniejszeniu podlega wówczas rekomendowana kwota
dofinansowania oraz/lub rekomendowany procent kosztów kwalifikowanych.
7. Wydruk karty oceny według definiowalnego wzoru z automatycznym wypełnianiem danymi
beneficjenta i osób oceniających wniosek wraz z wprowadzonymi przez ekspertów ocenami.
8. Wydruk formularza oceny z danymi beneficjenta oraz identyfikacją wniosku i danymi osób
oceniających.
9. Wydruk wezwania do złożenia wyjaśnień do wniosku wg definiowanego wzoru z automatycznym
wypełnianiem danymi beneficjenta oraz numerem wniosku (automatyczne dołączanie pisma do
korespondencji dotyczącej danego wniosku).
10. Generowanie Protokołu z prac komisji konkursowych
11. Generowanie innych pism wg szablonu umożliwiającego automatyczne pobieranie danych z
wniosku.
5.2.7 Funkcjonalność „oprotestowanie wniosku”
Ocena wniosku (formalna i merytoryczna) może zostać oprotestowana przez beneficjenta.
5.2.7.1 Wymagania funkcjonalne dla wnioskodawcy
1. Możliwość wprowadzenia wniosku przez wnioskodawcę wg. przygotowanych szablonów,
możliwość załączania załączników w dowolnym formacie. Możliwość podglądu dokumentów w
formacie PDF. Możliwość przejścia z Extranetu do szablonów w LSI.
2. Możliwość wydruku
5.2.7.2 Wymagania funkcjonalne dla RIF
1.1. ocena formalna wniosku została oprotestowana – status nadawany automatycznie w
momencie wprowadzenia wniosku
1.2. ocena merytoryczna wniosku została oprotestowana – status nadawany automatycznie w
momencie wprowadzenia wniosku
1.3. wycofany
1.4. wniosek został odrzucony (po proteście)
1.5. inne określone przez administratora
9. Możliwość korespondencji z wnioskodawcą, także wg. przygotowanych szablonów, możliwość
załączania załączników w dowolnym formacie. Możliwość podglądu dokumentów w formacie
PDF.
10. Możliwość wydruku
przypomnienia (pojawiającego się na wśród komunikatów systemowych).
Strona 30 z 56
12. Sortowanie spraw według terminu realizacji danego zadania. Generowanie ostrzeżeń o
przekroczeniu lub zbliżaniu się końca terminów wśród komunikatów systemowych.
13. W przypadku zmiany oceny w LSI zarejestrowana zostaje nowa ocena i następuje zmiana statusu
na wniosek jest oceniony merytorycznie lub rekomendowany.
5.2.8 Funkcjonalność „generowanie listy rankingowej”
Generowanie listy rankingowej jest możliwe dopiero po dokonaniu oceny ostatniego wniosku na dany
konkurs. Wnioski, które przeszły pozytywnie wszystkie etapy oceny ustawiane są na liście
rankingowej wg. daty wpływu kompletnego (tj. jeśli wniosek był uzupełniany to datą wpływu jest
data ostatniego uzupełnienia) wniosku i certyfikowanego oznaczenia czasem (lub innego kryterium
ustalonego przy wprowadzaniu formularz oceny wniosku przez administratora). Lista rankingowa
zawiera listę wniosków, które przeszły pozytywnie ocenę formalną i merytoryczną. Lista rankingowa
składa się z dwóch dokumentów:
1) Lista projektów rekomendowanych do dofinansowania
2) Lista projektów nierekomendowanych do dofinansowania.
Listy i protokoły z prac komisji konkursowych są weryfikowane przez PARP, następnie przez
Instytucję Zarządzającą. Dopiero po akceptacji listy i statusy wymienione w p. 5.1.8.1 mogą zostać
wygenerowane.
Weryfikacja przebiega poza systemem. System musi umożliwiać wprowadzenie danych przez
uprawnionego pracownika merytorycznego PARP.
1. Generowanie listy rankingowej
2. Wyliczanie algorytmu wpływu kompletnego wniosku wg. formuły:
do daty złożenia pierwotnej wersji wniosku zostaje doliczona liczba dni pomiędzy dniem
następnym po wysłaniu wezwania przez RIF do uzupełnienia wniosku a dniem wpływu
uzupełnienia do RIF (nie wliczając czasu na dokonanie oceny formalnej). Dla ustalenia daty
kompletności wniosku pomija się dni wolne od pracy (w szczególności weekend) należy brać
wszystkie dni robocze od dnia następnego po wysłaniu wezwania do poprawy do dnia złożenia
uzupełnienia włącznie.
3. Tworzenie na podstawie decyzji Komisji
• List projektów rekomendowanych do dofinansowania
• List projektów nierekomendowanych do dofinansowania
4. Wydruk w/w dokumentów
5. Statusy wniosków:
• zatwierdzony do dofinansowania,
• zatwierdzony do dofinansowania ze zmniejszonym poziomem dofinansowania,
• konkursu,
Generowanie pisma z informacją o zatwierdzeniu wniosku do dofinansowania
7. Generowanie umowy z beneficjentem o dofinansowaniu realizacji projektu.
Strona 31 z 56
8. Generowanie pisma z zapytaniem o zgodę na zmniejszony poziom dofinansowania.
9. W/w dokumenty można edytować, możliwy jest też upload dokumentu do systemu.
5.3 Moduły Beneficjenta
5.3.1 Rejestracja/logowanie
Moduł musi umożliwiać rejestrowanie wnioskodawcy/beneficjentów nie posiadających jeszcze
dostępu do systemu poprzez formularz na stronie internetowej systemu. Beneficjent może być
zalogowany tylko na jedną sesję w danym czasie. Nie jest możliwe równoczesne wprowadzanie
danych przez dwóch pracowników beneficjenta zalogowanych na te samo konto.
1. Automatyczna weryfikacja wprowadzanych danych
2. Możliwość rejestracji beneficjenta (z poziomu administratora możliwość walidacji pól)
3. Generowanie linka aktywacyjnego wysyłanego na podany w formularzu rejestracyjnym adres
email.
4. Możliwość zarządzania danymi (od momentu podpisania umowy część danych może być
modyfikowana tylko po zgodzie osoby obsługującej wniosek)
5. Logowanie do systemu –za pomocą jednego loginu (e-mail) i hasła do wszystkich części portalu
6. Logowanie realizowane ma być przy zastosowaniu protokołu szyfrującego - SSL
7. Moduł musi posiadać możliwość dobudowania w przyszłości także możliwości zastosowania
identyfikacji i certyfikacji wprowadzanych przez beneficjenta informacji poprzez podpis
elektroniczny.
5.3.2 Generator Wniosków Aplikacyjnych
Zaproponowany przez Wykonawcę generator musi być efektywny i bezawaryjny. Ponieważ kolejność
składania wniosków ma bardzo duże znaczenie dlatego należy dla wszystkich zainteresowanych
stworzyć takie same szanse pracy z generatorem. Wnioskodawca może składać wniosek poprzez
wypełnienie odpowiednich formularzy odwzorowujących wnioski aplikacyjne zamieszczone na
stronie WWW Polskiej Agencji Rozwoju Przedsiębiorczości. Wnioskodawca musi się wcześniej
zarejestrować przez WWW. Po zalogowaniu wnioskodawca powinien mieć możliwość tworzenia
wniosku etapami, bez konieczności przekazania ostatecznej wersji wniosku za pierwszym
logowaniem. Wnioskodawca może zarejestrować się przed konkursem i przed konkursem wypełnić
wniosek o statusie roboczym, który może wykorzystać po ogłoszeniu konkursu. Wniosek o statusie
roboczym może zmodyfikować przed ostatecznym zatwierdzeniem.
Jeśli moduł stworzony przez Wykonawcę zastąpi obecny Generator Wniosków dostępny pod
adresem https://bazy.parp.gov.pl/lsi1/8/ to wykonawca zagwarantuje wszystkim użytkownikom
zarejestrowanym w obecnym Generatorze od momentu uruchomienia Modułu Beneficjenta możliwość
zalogowania się w Portalu i dostępu do swoich danych (używając nazwy użytkownika i hasła, których
używali do logowania się do obecnego Generatora Wniosków). Wykonawca podejmie współpracę z
Zamawiającym, aby od tego momentu na stronie obecnego Generatora Wniosków znalazła się
informacja o zmianach, konsekwencjach dla Beneficjentów.
5.3.2.1 Wymagania funkcjonalne do generatora wniosków
1. Wprowadzanie za pomocą formularzy. Informacje zawarte we wniosku muszą zawierać
wszystkie dane z wniosków aplikacyjnych, których wzory zostaną dostarczone.
Strona 32 z 56
2. Generator powinien umożliwiać wygenerowanie wniosku do różnych programów, osi,
priorytetów, działań i poddziałań, w szczególności dla PO IG 8.1 i 8.2, a także dla innych jeśli
zostaną zdefiniowane ścieżki inne niż dla PO IG 8.1, 8.2.,
3. Wydruk wersji roboczych, z oznaczeniem statusu roboczego za pomocą „znaku wodnego”.
4. Wydruk wniosku musi być w postaci zgodnej ze wzorami wniosków.
5. Realizacja logiki odpowiadającej wzorom wniosków
6. Kontrolowanie poprawności wprowadzanych danych – automatyczna walidacja danych na
każdym etapie wypełniania (przy przejściu pomiędzy zakładkami)
7. Umożliwienie wprowadzenia słownika do weryfikacji kodów PKD/EKD, który uniemożliwi
wypełnianie dalszej części wniosku Wnioskodawcy w przypadku wykluczenia danego PKD/EKD
i zasygnalizowanie Wnioskodawcy, że wpisane kody podlegają wykluczeniu.
8. Powinien posiadać słowniki ułatwiające wprowadzane danych przez beneficjenta. Zamawiający
udostępni słowniki, które już posiada. Słowniki powinny być edytowalne.
9. Umożliwienie wprowadzania, edycji i zapisywania wszystkich danych
10. Opatrzenie każdej strony wydruku sumą kontrolną
11. Możliwość dodatkowej weryfikacji, na życzenie wnioskowdacy, przed akceptacją wniosku przez
wnioskodawcę
12. Ostateczne zatwierdzeniu wniosku powoduje zabezpieczenie danych przed edycją.
13. Możliwość uzupełnienia lub poprawy wniosku przez wnioskodawcę tylko w przypadkach
przewidzianych przez procedurę i tylko w polach wyznaczonych przez uprawnionego
użytkownika. System zachowuje wszystkie wersje zaakceptowanych przez użytkownika
wniosków.
14. Możliwość tworzenia wniosków o statusie roboczym, także przed ogłoszeniem konkursu.
5.3.2.2 Wymagania techniczne do generatora wniosków
1. Korzystanie z wniosku ma być zapewnione przez aplikację udostępniającą funkcjonalność
wniosku, realizującą logikę zapisaną we wniosku.
2. Wniosek elektroniczny powinien umożliwiać zawarcie w nim logiki obsługi (proste operacje
matematyczne, listy rozwijane wpływające na dalszą część wniosku).
3. Generator wniosków elektronicznych ma mieć możliwość umieszczenia w nim obrazów oraz
załączników w dowolnym formacie (we wniosku), jeśli taką potrzebę reguluje regulamin dla
danego działania/poddziałania.
4. W pliku wniosku należy zapisywać, oprócz danych i sposobu wizualizacji wniosku, również
informacje o podpisach (np. uprawnienia do ich wykonania) oraz dla poszczególnych pól (lub
grup pól) wniosku teksty pomocy i podpowiedzi, reguły walidacji wniosku, wartości domyślne.
Wszystkie te informacje powinny mieć w przyszłości możliwość rozbudowania o zabezpieczenia
podpisami autoryzującymi oraz podpisem wzoru wniosku.
5. Należy przewidzieć możliwość wymiany informacji poprzez wbudowane mechanizmy
komunikacji z wykorzystaniem poczty elektronicznej oraz wymiany informacji z użyciem
protokołu SOAP.
6. Należy umożliwić zapis wniosku elektronicznego w formacie PDF, xml.
7. Należy umożliwić wydruk wniosku elektronicznego zgodnie z jego reprezentacją na ekranie.
8. Należy przyjąć, że wnioskodawca/beneficjent nie ponosi dodatkowych kosztów związanych z jego
funkcjonowaniem – aplikacja do używania wniosku przez wnioskodawców/beneficjentów
powinna być bezpłatna.
9. W przypadku podjęcia decyzji odnośnie wykorzystania elektronicznego podpisu
kwalifikowanego, należy umożliwić podpisanie wniosku elektronicznym podpisem
kwalifikowanym. Generator wniosków wraz z wnioskiem elektronicznym ma umożliwić w
przyszłości korzystanie z Elektronicznej Skrzynki Podawczej i Urzędowego Poświadczenia
Odbioru w sposób synchroniczny z wykorzystaniem bezpiecznych (szyfrowanych) protokołów
Strona 33 z 56
komunikacyjnych (HTTPS SSL) oraz zapewnić integrację z wewnętrznym systemem obiegu
informacji w PARP oraz umożliwić składanie i weryfikację kwalifikowanego podpisu
elektronicznego zgodnie z wymaganiami określonymi w odpowiednich aktach prawnych.
5.3.3 Generator Wniosków Płatniczych
Beneficjent w trakcie trwania projektu będzie systematycznie przekazywał wnioski o płatność,
również w wersji elektronicznej. Zakłada się, że w celu przygotowania wniosku o płatność,
wnioskodawca będzie się posługiwał Generatorem Wniosku o Płatność Beneficjenta, który po
sporządzeniu wniosku o płatność wygeneruje odpowiedni plik. Lokalny System Informatyczny
powinien umożliwić:
• pobranie Generatora Wniosku o Płatność Beneficjenta
• automatyczne wczytywanie danych z plików XML wygenerowanych przez Generator
Wniosku o Płatność Beneficjenta
• możliwość dołączania plików dodatkowych (np. skany, kopie faktur, ect. w dowolnym
formacie)
• wydruk wniosków i tworzenia plików PDF, na podstawie wczytanych danych
Aplikacja działa offline i generuje pliki w formacie XML.
5.3.4 „Moje wnioski”
1. Moduł „Moje wnioski” informujący o statusie realizacji wniosku/projektu we wszystkich etapach
jego realizacji, od rejestracji wnioskodawcy, rejestracji wniosku, poprzez składanie wniosków o
płatność, generowanie szczegółowych sprawozdań i raportów a także rejestrowanie kontroli i
archiwizację.
2. Moduł
„Moje
wnioski” jest
modułem przeznaczonym do
użytkowania przez
Wnioskodawcą/Beneficjenta.
3. Pracownicy RIF/PARP opiekujący się danym Beneficjentem mają możliwość podglądu
statusu jego wniosków z poziomu LSI.
4. Funkcjonalność modułu jest dostępna dla osób, które zostały zarejestrowane w LSI.
5. Wnioskodawca/beneficjent będzie miał możliwość (korzystając z przydzielonego przy rejestracji
loginu i hasła) sprawdzania statusu wniosku / projektu, który złożył.
6. Moduł pobiera dane z LSI (sposób i częstotliwość pobierania danych określi Wykonawca).
7. Moduł musi umożliwiać operowanie na liście wniosków i kartach projektów.
8. Lista wniosków zawiera: numer porządkowy, nazwę projektu, numer wniosku (w momencie jego
nadania), status realizacji, link „zobacz szczegóły >>” kierujący do karty projektu, opcjonalny
znacznik do sygnalizacji zmiany statusu lub zmian na karcie projektu. Na Liście wniosków
administrator będzie mógł dodać link przekierowujący do miejsca, gdzie można dodać kolejny
wniosek.
9. Karta projektu zawiera bieżący status (i jego szczegóły), zbliżające się terminy operacji
związanych z wnioskiem/projektem, historię operacji dotyczących wniosku/projektu, możliwość
przejścia (np. w formie zakładki – „dokumenty projektu”) do podglądu dokumentów i projektów
dokumentów związanych z projektem.
10. Ilekroć w statusach pojawia się informacja o terminach muszą być one powiązane z kalendarzem.
11. Ilekroć w statusach pojawia się dokument musi być on zapisywany, beneficjent musi mieć
możliwość jego podglądu i wydruku.
12. Każda zmiana statusu musi być anonsowana beneficjentowi/wnioskodawcy pocztą e-mail.
13. Statusy realizacji:
a. wniosek został złożony (tylko jeśli informacja z LSI „tak”, jeśli nie wniosek nie pojawia się na
liście), na karcie projektu możliwość podglądu wniosku.
Strona 34 z 56
b. wniosek jest oceniany formalnie – tylko wniosek kompletny i złożony prawidłowo ze względu
na siedzibę wnioskodawcy i podlega ocenie. Decyduje RIF, ma odzwierciedlenie w LSI. Na
karcie projektu pojawia się informacja (moduł pomocy) dla wnioskodawcy o maksymalnym
terminie oceny formalnej,
c. wniosek jest niekompletny. Decyduje RIF, ma odzwierciedlenie w LSI. Na karcie projektu
pojawia się informacja (moduł pomocy) dla wnioskodawcy czy i w jaki sposób może
uzupełnić wniosek (moduł pomocy), jeśli nie to informacja (moduł pomocy) zawierająca
sugestię zgłoszenia wniosku w kolejnej turze naboru.
d. potrzebne uzupełnienie do oceny formalnej – status w przypadku braków lub uchybień
formalnych we wniosku o dofinansowanie projektu. RIF informuje wnioskodawcę o
konieczności poprawy/uzupełnienia wniosku. W takim przypadku na karcie projektu
powinna pojawiać się informacja, które z kryteriów formalnych nie zostały spełnione
(informacja z LSI). System musi umożliwiać powrót do Modułów Beneficjenta LSI i
uzupełnienia/poprawy wniosku w określonym terminie.
e. wniosek został odrzucony z powodów formalnych - w przypadku braku uzupełnień lub
niespełnienia kryteriów kwalifikacyjnych wniosek jest odrzucany. Wnioskodawca zostaje
poinformowany o odrzuceniu wniosku i możliwości złożenia protestu od oceny formalnej
wniosku. Potrzebna informacja (moduł pomocy) o procedurze protestu, terminach i miejscach
jego złożenia.
f. wniosek jest oceniany merytorycznie - wniosek, który pozytywie przejdzie etap oceny
formalnej kierowany jest do oceny merytorycznej. Przy tym statusie w karcie projektu
informacja (moduł pomocy), kiedy najpóźniej wniosek zostanie oceniony merytorycznie i jak
wygląda procedura.
g. potrzebne wyjaśnienia do oceny merytorycznej - Jeśli zachodzi potrzeba dostarczenia
wyjaśnień wnioskodawca zostaje poinformowany e-mailem o konieczności ich dostarczenia.
Informacja (moduł pomocy) do wnioskodawcy do kiedy ma złożyć wyjaśnienia i w jakiej
formie, jeśli przez formularz w LSI to link do Modułów Beneficjenta LSI.
h. wniosek został pozytywnie oceniony merytorycznie – Po zatwierdzeniu listy rankingowej
projektów rekomendowanych przez Ministra Rozwoju Regionalnego, PARP publikuje listę
zatwierdzonych do wsparcia projektów na stronie internetowej oraz informuje (także emailem) beneficjentów o przyznaniu wsparcia. UWAGA: Kwota dofinansowania
zarekomendowana przez Komisję Konkursową może ulec zmianie, choć nie może
przewyższać kwoty wnioskowanej. W uzasadnionych przypadkach Komisja Konkursowa
może rekomendować udzielenie wsparcia w kwocie niższej niż wnioskowana. Zmniejszeniu
podlega wówczas rekomendowana kwota dofinansowania oraz/lub rekomendowany procent
kosztów kwalifikowanych. Wnioskodawca musi zostać w szczegółach e-maila
poinformowany o zmianie kwoty. W każdym przypadku potrzebna informacja o dokumentach
potrzebnych do podpisania umowy, terminie, miejscu i formie ich dostarczenia. Wszystkie
powyższe informacje (moduł pomocy) pojawiają się także na karcie projektu.
i. wniosek nie uzyskał pozytywnej oceny merytorycznej - jeśli wniosek nie uzyska pozytywnej
oceny, wnioskodawca ma prawo do złożenia protestu. Na karcie projektu potrzebna
informacja (moduł pomocy) o procedurze protestu, terminach i miejscach jego złożenia, jeśli
możliwe poprzez LSI to odpowiedni link do Modułów Beneficjenta LSI.
j. ocena formalna wniosku została oprotestowana – nadesłany protest jest sprawdzany przez
pracownika RIF - terminowość i poprawność złożonego protestu. Jeśli protest nie podlegał
rozpatrzeniu RIF pisemnie i e-mailowo informuje wnioskodawcę o przyczynach
nierozpatrzenia. W przypadku protestów podlegających rozpatrzeniu po przeprowadzonej
ocenie do LSI zostaje wprowadzona decyzja odnośnie protestu. Przeprowadzenie oceny
następuje zgodnie z procedurą "Ocena wniosków o dofinansowanie projektów". Do LSI
zostaje wprowadzona decyzja odnośnie protestu. W przypadku zmiany oceny w LSI
Strona 35 z 56
zarejestrowana zostaje nowa ocena i następuje przejście do statusu wniosek jest oceniony
merytorycznie. Jeśli decyzją RIF protest zostaje odrzucony RIF przekazuje dokumenty dot.
protestu do IZ.
k. ocena merytoryczna wniosku została oprotestowana – nadesłany protest jest sprawdzany
przez pracownika RIF - terminowość i poprawność złożonego protestu. Jeśli protest nie
podlegał rozpatrzeniu RIF pisemnie i e-mailowo informuje wnioskodawcę o przyczynach
nierozpatrzenia. W przypadku protestów podlegających rozpatrzeniu po przeprowadzonej
ocenie do LSI zostaje wprowadzona decyzja odnośnie protestu. Przeprowadzenie oceny
następuje zgodnie z procedurą "Ocena wniosków o dofinansowanie projektów". Do LSI
zostaje wprowadzona decyzja odnośnie protestu. W przypadku zmiany oceny w LSI
zarejestrowana zostaje nowa ocena i następuje przejście do statusu wniosek został
pozytywnie oceniony merytorycznie. Jeśli decyzją RIF protest zostaje odrzucony RIF
przekazuje dokumenty dot. protestu do IZ.
l. wniosek został odrzucony – informacja o przyczynach odrzucenia protestu. Wnioskodawca ma
możliwość podglądu historii.
m. wycofany – na etapie oceny formalnej i merytorycznej, a przed ogłoszeniem listy
dofinansowanych wniosków Wnioskodawca ma prawo wycofać wniosek, po zgłoszeniu
decyzji o wycofaniu wniosku, zostaje nadany status. Wnioskodawca ma możliwość podglądu
historii.
n. potrzebne dokumenty – W przypadku wystąpienia braków w dokumentacji następuje wysłanie
e-mailowego ponaglenia do dostarczenia lub uzupełnienia dokumentacji niezbędnej do
sporządzenia umowy. Na karcie projektu informacja (moduł pomocy) o potrzebnych
dokumentach (ewentualnie możliwość ich dodania) procedurze i terminach. W przypadku nie
otrzymania dokumentacji w terminie, poinformowanie e-mailowe o braku możliwości
podpisania umowy.
o. gotowa umowa – gdy wnioskodawca złoży dokumenty niezbędne do podpisania umowy i
pracownik RIF stwierdzi kompletność nadesłanych dokumentów to zaznacza on odpowiednie
pole w LSI. LSI generuje numer umowy i plik z umową. W Ekstranecie musi być możliwość
pobrania i wydruku pliku. Podpisanie umowy przez beneficjenta następuje w siedzibie RIF lub
umowa jest przesyłana wnioskodawcy do podpisu pocztą. Jeśli beneficjent ma możliwość
wyboru to w tym miejscu może go określić. W LSI rejestrowana jest data wysłania umowy,
data podpisania umowy oraz login osoby odpowiedzialnej za umowę. Czas na podpisanie i
odesłanie umowy. Beneficjent ma wgląd w te dane (moduł pomocy). W przypadku opóźnień
generowane z automatu (i ręcznie) przypomnienia. W przypadku nie przesłania umowy w
terminie, wysłanie przez RIF informacji ponaglającej.
p. rezygnacja od dofinansowania - W przypadku nie otrzymania podpisanej obustronnie umowy
pomimo ponaglenia, pismo informujące i informacja w statusie o odstąpieniu od decyzji o
przyznaniu dofinansowania.
q. projekt w realizacji - obustronnie podpisana umowa wpływa do RIF i jest przekazana do
PARP. Informacja pojawia się po wprowadzeniu do LSI danych z umowy.
Na karcie szczegółu:
i. umowa - beneficjent ma możliwość podglądu i wydruku kopii umowy, ma także
możliwość przejścia do innych dokumentów projektu.
ii. sprawozdania - potrzebny odnośnik do informacji (moduł pomocy) o konieczności
przesyłania sprawozdań (półrocznych i końcowych), wraz z terminami i sposobami ich
dostarczania. Możliwość przesłania sprawozdania półrocznego i końcowego.
Beneficjent ma możliwość przejścia do Modułów Beneficjenta LSI i wypełnienia
wniosków o płatność okresową lub końcową (część finansowa oraz sprawozdawczą).
W LSI sprawozdania otrzymują numer oraz dekretowane jest na pracownika
zajmującego się daną sprawą. W przypadku braków, błędów Beneficjent zostaje
Strona 36 z 56
powiadomiony e-mailem o tym fakcie. W LSI rejestrowana jest data wysłania pisma
oraz informacje dodatkowe. Beneficjent ma w Ekstranecie możliwość podglądu tych
danych (a także wcześniej wysłanych sprawozdań i wniosków w zakładce „dokumenty
projektu”).
iii. aneksy – beneficjent jest informowany (moduł pomocy) o możliwościach aneksowania
umowy. Beneficjent musi mieć możliwość przejścia do Modułów Beneficjenta LSI
celem złożenia wniosku o aneksowanie możliwych do zaneksowania punktów wniosku
o dofinansowanie. W przypadku konieczności uzupełnienia wniosku RIF/PARP może
wezwać e-mailowo do uzupełnień. Beneficjent jest informowany (moduł pomocy) kiedy
jego wniosek zostanie rozpatrzony, przez RIF (a po rozpatrzeniu pozytywnie przez RIF,
także przez PARP). Po decyzji RIF/PARP wysłanie e-maili do beneficjenta, w
przypadku pozytywnej decyzji PARP dodatkowa informacja o przygotowaniu projektu
aneksu i możliwości jego pobrania, konieczności podpisania i odesłania. RIF ma też
możliwość akceptacji zmian wnioskowanych przez beneficjenta bez konieczności
sporządzenia aneksu. W przypadku akceptacji i zarejestrowaniu zmian w LSI e-mail do
Beneficjenta i PARP o wprowadzonych zmianach. W przypadku braku akceptacji także
e-mailowe poinformowanie Beneficjenta o tym fakcie. Aneksy mogą być także
tworzone z inicjatywy RIF/PARP. W takim przypadku informacja e-mailowa do
beneficejnta o konieczności aneksowania umowy i udostępnienie możliwości pobrania
aneksu.
Baza przechowuje aneksy, beneficjent ma możliwość podejrzenia archiwum i każdego
aneksu poprzez zakładkę „dokumenty projektu”. Aneksy są numerowane i datowane.
iv. informacja (moduł pomocy) o możliwości i procedurze rozwiązania umowy na wniosek
beneficjenta, wraz z możliwością przejścia do Modułów Beneficjenta LSI i wysłania
wniosku.
v. wnioski o płatność - informacja (moduł pomocy) o terminach i warunkach wypłacenia
dofinansowania. Możliwość przejścia do generatorów sprawozdań/wniosków (LSI) o
płatności okresowe i końcowe. Podgląd statusu wniosku o płatność (zmiany statusów
sygnalizowane automatycznym e-mailem do beneficjenta):
o zarejestrowany
o nadany numer KSI
o zweryfikowany przez RIF
o potrzebne uzupełnienie dokumentacji (dodatkowo informacja jakie
uzupełnienie)
o zgłoszono zastrzeżenia (dodatkowa informacja kto (PARP/RIF), jakie
zastrzeżenia, gdzie uzupełnić dane)
o wysłano ponaglenia (w przypadku braku uzupełnień w terminie),
o wniosek odrzucony (dodatkowa informacja dlaczego)
o zaakceptowany przez PARP,
o częściowo zaakceptowany (dodatkowo informacja o zmienionej kwocie
wraz z uzasadnieniem obniżenia kwoty płatności)
o płatność przekazana
wraz z wnioskami o płatność przekazywane są dokumenty uzupełniające (np umowy
leasingu, umowiy z dostawca usług lub materiałów, ect.). Umowy są weryfikowane
wraz z pozostałymi dokumentami związanymi z rozliczeniem. Ekstranet powinien
umożliwiać podgląd dotychczas wysłanych dokumentów poprzez zakładkę „dokumenty
projektu”.
vi. informacja (moduł pomocy) o możliwości kontroli projektu, a w momencie jej
przeprowadzania możliwość do szczegółów. Kontrole mogą się odbywać w trakcie
realizacji projektu, ale także po zakończeniu realizacji projektu ale przed wypłatą
Strona 37 z 56
dofinansowania jak również po wypłacie dofinansowania. Beneficjent dostaje
informacje o planowanej kontroli (termin, zakres). Informacje po zakończonej kontroli
(część jawna z LSI), ma możliwość pobrania dokumentu informacja pokontrolna ,
beneficjent może wnieść zastrzeżenia do informacji pokontrolnej; po otrzymaniu
zastrzeżeń lub wyjaśnień do informacji pokontrolnej od beneficjenta; rozpatrzenie
zastrzeżeń i wyjaśnień otrzymanych od Beneficjenta; wezwanie beneficjenta do
podpisania informacji pokontrolnej w ciągu 7 dni od otrzymania wezwania; otrzymanie
podpisanej informacji pokontrolnej; ewentualność – stwierdzenie nieprawidłowości.
r. wniosek o rozwiązanie umowy – status po wysłaniu przez Beneficjenta odpowiedniego
wniosku. W szczegółach informacja (moduł pomocy) o terminach i dalszej procedurze, czyli
weryfikacji w RIF lub PARP wszystkich (powziętych z różnych źródeł) informacji mogących
stanowić podstawę do wypowiedzenia umowy. Informacja (moduł pomocy) dla beneficjenta o
prowadzonej weryfikacji. Beneficjent może mieć możliwość przedstawienia wyjaśnień. W
przypadku stwierdzenia uchybień określonych w Umowie o dofinansowanie, stanowiących
podstawę do jej wypowiedzenia przedstawienie rekomendacji wypowiedzenia umowy o
dofinansowanie (RIF przekazuje pełną dokumentację będącą podstawą do rozwiązania umowy
do PARP).
s. umowa rozwiązana –
i. jeśli na wniosek beneficjenta – to status pojawia się po podpisaniu pisma
potwierdzającego rozwiązanie umowy o dofinansowanie przez upoważnionego
przedstawiciela RIF następuje wysłanie do Beneficjenta pisma potwierdzającego
rozwiązanie umowy o dofinansowanie. Rozwiązanie umowy (niezależnie czy na wniosek
beneficjenta, czy po weryfikacji jest rejestrowane w LSI przez pracownika RIF.
ii. jeśli po weryfikacji ze strony RIF/PARP - to status pojawia się po weryfikacji
dokumentacji w PARP. W przypadku konieczności zwrotu informacja o wysokości kwoty
podlegającej zwrotowi w związku z wypowiedzeniem umowy. Możliwość pobrania
ostatecznego projektu wypowiedzenia umowy o dofinansowanie wraz z wezwaniem do
zwrotu ustalonej kwoty. Wypowiedzenie wysłane jest do beneficjenta. Informacja także emailem. Informacja o ostatecznym terminie zwrotu środków. Informacja o numerze konta.
Po zaksięgowaniu zwrotu zwrot dofinansowania na właściwym koncie informacja. W
przypadku braku zwrotu informacja o przekazaniu należności do windykacji.
t. Projekt zakończony – status nadawany automatycznie po zamknięciu projektu. Możliwość
podglądu historii. Informacja o możliwej kontroli po zakończeniu projektu.
14. Umowa, aneks i wszystkie inne dokumenty istotne dla realizacji projektu podpisywanie są
najpierw przez pełnomocnika PARP w RIF lub przez PARP następnie są przesyłane do podpisu
beneficjenta.
5.3.5 Pomoc
Moduł zawiera zbiór zasad i przepisów ustalających sposób postępowania w sytuacjach braku wiedzy
na temat prawidłowego administrowania/użytkowania LSI. Moduł oferuje funkcjonalność równoległą
dla funkcjonalności wdrażanej w Extranecie.
1. Odnośnik do modułu stale widoczny w Extranecie/LSI.
2. Do każdego elementu uprawniony użytkownik może przypisać odnośnik (także graficzny) do
tematów pomocy do poszczególnych elementów Extranetu/LSI.
3. Wykonawca projektując i wykonując Moduł udostępni funkcjonalność umożliwiającą dodanie
przez upoważnionych pracowników PARP dodatkowych tekstów pomocy lub odnośników do
części informacyjnej Portalu przy każdej funkcjonalności kierowanej do Beneficjentów, czyli
Strona 38 z 56
zapewni możliwość prezentowania
informacyjnych Portalu.
dodatkowych
odnośników
do
wybranych
treści
4. System musi co najmniej umożliwić:
a) Opis poszczególnych modułów wchodzących w skład Extranetu/LSI,
b) Wskazówki dotyczące użytkowania wszystkich modułów,
c) Tworzenie automatycznych podpowiedzi - opis działań możliwych do wykonania przez
użytkownika w danym miejscu (w Extranecie) i czasie (momencie procedury opisanej w
module „Moje wnioski”),
d) Na umieszczanie graficznych odnośników do pomocy przy elementach mogących sprawiać
kłopoty użytkownikowi.
e) Wyświetlanie podpowiedzi pomocy w miejscu umieszczenia odnośnika graficznego, z
możliwością umieszczenia podpowiedzi za pomocą „dymka”.
f) Wyszukiwanie określonego problemu w drzewie zagadnień,
i.
spis tematów kluczowych,
ii. spis rozszerzony z uszczegółowieniem problemów,
d) Wyszukiwanie określonego problemu z użyciem formularza szukaj.
i.
wyszukiwarka winna spełniać m.in. kryterium dokładności - przez co rozumie się
zwracanie takich wyników, które jak w największym stopniu pasują do szukanego tematu,
ii. wyszukiwarka winien korygować błędy literowe,
iii. mechanizm wyszukiwania winien uwzględniać odmiany wpisywanych słów.
5.3.5.1 Administracja modułem pomocy
Extranet/LSI musi umożliwiać uprawnionym użytkownikom edytowanie i rozwijanie treści zawartych
w module pomocy dostępnym odpowiednio dla użytkowników Extranetu/LSI.
Moduł musi pozwalać minimum na:
1. dodawanie nowych i edytowanie aktualnych tematów, wraz z odpowiadającymi im podtematami
w drzewie zagadnień,
2. dodawanie nowych i edytowanie istniejących podtematów występujących w ramach tematu
głównego,
3. zmiany wyświetlanej nazwy każdego tematu i podtematu,
4. usunięcie tematu głównego/lub wybranego podtematu z tematu głównego,
5. łączenie tematów głównych (w przypadku połączenia tematów głównych wszystkie treści
przypisane do obu łączonych tematów po operacji muszą być przypisane do tematu połączonego),
6. łączenie i przesunięcie podtematu do innego tematu głównego.
7. przypisywanie odnośników (także w formie graficznej) do tematów pomocy do poszczególnych
elementów Extranetu/LSI.
Strona 39 z 56
5.4 Moduł realizacji projektów
5.4.1 Umowy i aneksy
5.4.1.1 Wymagania funkcjonalne dotyczące zawierania i aneksowania
umów
a. potrzebne dokumenty do umowy
b. gotowa umowa
c. rezygnacja od dofinansowania
d. wycofany
e. projekt w trakcie realizacji
f. inne określone przez administratora
3. Możliwość- dla uprawnionych użytkowników - generowania umowy z szablonu z automatycznym
wstawianiem danych beneficjenta
4. Generowanie umowy, aneksów harmonogramu rzeczowo-finansowego i pisma przewodniego wg.
szablonów dokumentów. Po wygenerowaniu pismo można edytować, możliwy jest też download /
upload dokumentu do/z systemu.
5. Generowanie numeru umowy/aneksu.
6. Ewidencja umów oraz aneksów. Rejestrację i podgląd historii zmian z odpowiednimi filtrami
(podgląd dla danego beneficjenta, ect.)
a. mechanizm umożliwiający zapisywanie kluczowych dat dla umów/aneksów:
wygenerowania, wysłania do beneficjenta, podpisania przez beneficjenta, dostarczenia do
RIF, przekazania do PARP, rozwiązania
b. generowanie zestawienia umów dla danego beneficjenta
7. Przegląd umów/aneksów z beneficjentami wraz z wyszukiwarką i możliwością podglądu stanu
umowy (wraz ze zmianami wprowadzonymi aneksami) na zadany dzień.
8. Modyfikacja umów/aneksów przed ostatecznym zatwierdzeniem.
9. Wydruk pisma przewodniego do umowy lub aneksu wysyłanego do beneficjenta do podpisania.
10. Wydruk umowy lub aneksu.
11. Tworzenie listy projektów na podstawie podpisanych umów. Do projektów dołączane będą dane z
dokumentów z nimi powiązanych:
• dane beneficjenta
• umowa, aneksy i zmiany,
• wnioski o płatność,
• kontrole i nieprawidłowości,
• zaliczki,
• kwoty odzyskane,
• inne
12. Tworzenie po podpisaniu umowy lub aneksu pliku wsadowego w formacie XML do
przygotowania przez beneficjenta wniosku o płatność w Generatorze Wniosków Płatniczych. Plik
ten zawierał będzie niezbędne informacje o projekcie pochodzące z systemu. Dla beneficjenta
dostępny będzie poprzez Extranet.
PDF.
Strona 40 z 56
• konkursu,
15. Możliwość dołączenia do notatek dotyczących kontaktów z beneficjentem np. treści rozmów
telefonicznych lub innych ustaleń. Notatka powinna mieć Możliwość ustawienia przypomnienia
(pojawiającego się na wśród komunikatów systemowych).
16. Możliwość dołączania dokumentów przesłanych przez beneficjenta
17. Możliwość generowania ostrzeżeń o przekroczeniu lub zbliżaniu się końca terminów wśród
komunikatów systemowych.
a. Także komunikaty generowane automatycznie – daty wynikają z harmonogramu
(załącznika do umowy), który jest odbiciem przebiegu rzeczowo-finansowego z
Generatora Wniosku
b. Komunikaty są widoczne dla Beneficjenta poprzez Extranet
c. Komunikaty są też widoczne dla pracowników obsługujących (RIF)
i. Obsługujących danych beneficjentów
ii. Dla całego RIF z przypisanymi do obsługi beneficjenta osobami.
5.4.1.2 Wymagania funkcjonalne dotyczące rozwiązywania umów
a. wniosek o rozwiązanie umowy
b. umowa rozwiązana
c. inne określone przez administratora
3. Możliwość generowania dokumentów dotyczących rozwiązania umowy przez strony. Po
wygenerowaniu pismo można edytować, możliwy jest też download / upload dokumentu do/z
systemu.
PDF.
5. Możliwość dołączenia do notatek dotyczących kontaktów z beneficjentem np. treści rozmów
telefonicznych lub innych ustaleń. Notatka powinna mieć Możliwość ustawienia przypomnienia
(pojawiającego się na wśród komunikatów systemowych).
6. Możliwość Generowanie ostrzeżeń o przekroczeniu lub zbliżaniu się końca terminów wśród
komunikatów systemowych.
7. Tworzenie listy rozwiązanych umów i dopisywanie do niej każdej kolejnej rozwiązywanej
umowy.
8. Aktualizacja informacji w rejestrach kwot do odzyskania, kwot odzyskanych i kwot wycofanych,
itp. dotyczących rozwiązanej umowy.
5.4.2 Wnioski o płatność
1. Statusy wniosków o płatność:
Strona 41 z 56
a.
b.
c.
d.
e.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
zarejestrowany
nadany numer KSI
zweryfikowany przez RIF
potrzebne uzupełnienie dokumentacji (dodatkowo informacja jakie uzupełnienie)
zgłoszono zastrzeżenia (dodatkowa informacja kto (PARP/RIF), jakie zastrzeżenia, gdzie
uzupełnić dane)
f. wysłano ponaglenia (w przypadku braku uzupełnień w terminie),
g. wniosek odrzucony (dodatkowa informacja dlaczego)
h. zaakceptowany przez PARP,
i. częściowo zaakceptowany (dodatkowo informacja o zmienionej kwocie wraz z
uzasadnieniem obniżenia kwoty płatności)
j. płatność przekazana
Możliwość dołączenia do procesu rozpatrywania wniosku o płatność pism przychodzących i
wychodzących w dowolnym formacie. Możliwość podglądu dokumentów w formacie PDF.
Możliwość dołączenia do oceny wniosku notatek dotyczących kontaktów z beneficjentem np.
przypomnienia (pojawiającego się wśród komunikatów systemowych). Możliwość ograniczenia
dostępu użytkowników systemu do tych danych np. tylko dla osób sporządzających notatkę i dla
ich przełożonych.
Sortowanie rozpatrywania wniosków według terminu realizacji danego zadania.
Generowanie ostrzeżeń odnośnie przekroczenia lub zbliżania się terminów wśród komunikatów
systemowych).
Personalizowana korespondencja seryjna do grup beneficjentów według co najmniej
• konkursu,
Raportowanie ze stanu zaawansowania rozpatrywania wniosków o płatność z funkcją
automatycznego porównywania osiągniętych wskaźników z wyznaczonymi,
Raportowanie o złożonych wnioskach o płatność w ramach projektu (poprawnych i ogółem) oraz
tworzenie statystyk z podziałem na m.in. osie priorytetowe, działania, poddziałania, narastająco i
w danym okresie.
Generowanie raportów umów z przypadającymi dla danego miesiąca wnioskami o płatność.
Generowanie aktualnych harmonogramów projektów w celu monitowania zbliżających się
terminów o płatność.
Sporządzanie dokumentów wg. szablonów (poświadczenia, deklaracje, wnioski o płatność)
5.4.2.2 Wymagania funkcjonalne-rozpatrywanie wniosków o płatność
1. Dekretacja wniosków o płatność na pracowników odpowiednich regionalnych RIF.
2. Wyświetlanie listy wniosków zadekretowanych na danego pracownika.
3. Wczytanie wersji elektronicznej wniosku o płatność do LSI. Jego postać jest wygenerowana w
Generatorze Wniosków Płatniczych. Wczytanie wniosku do systemu pociąga za sobą
wygenerowanie numeru wniosku o płatność.
4. Informacje ogólne o projekcie (między innymi tytuł projektu, nr projektu, kwota dofinansowania,
okres realizacji projektu, oś priorytetowa, działanie, poddziałanie), którego dotyczy rozpatrywany
wniosek o płatność.
Strona 42 z 56
5. Informacja o umowie o dofinansowanie dotyczącej projektu, którego wniosek o płatność
pracownik rozpatruje (między innymi nr wniosku, nr umowy, data podpisania umowy, wartość
projektu ogółem, wydatki kwalifikowane, wydatki niekwalifikowane, wkład własny, procent
dofinansowania, dofinansowanie, plan finansowy projektu, środki z budżetu państwa, pomoc
publiczna, informacje o przeprowadzonych kontrolach).
6. Informacje na temat Beneficjenta (nazwa Beneficjenta, dane teleadresowe, forma prawna, NIP,
REGON, nr rachunku bankowego, status podatnika VAT).
7. Informacje o planie finansowym dotyczącym rozpatrywanego wniosku (wydatki ogółem,
kwalifikowane, niekwalifikowane, informacja nt. zrealizowanego planu finansowego na podstawie
dotychczas zrealizowanych wniosków o płatność).
8. Informacje o liście mierzalnych wskaźników projektu oraz poziomie ich realizacji.
9. Zatwierdzanie wniosku o płatność na poziomie kwalifikowania poszczególnych pozycji wniosku
(faktur).
10. Generowanie z systemu korespondencji do beneficjenta dotyczącej błędów, niekwalifikowania
poszczególnych wydatków z możliwością śledzenia terminu odpowiedzi.
11. Wczytywanie poprawionych wniosków o płatność do systemu analogicznie do oryginału, z
nadaniem numeru kolejnego. System musi ewidencjonować i zarządzać wersjami tych
dokumentów.
12. Zlecanie kontroli doraźnej w przypadku wątpliwości lub wykrycia rażących nieprawidłowości.
Rozpatrywanie wniosku zostaje wstrzymane do czasu zakończenia kontroli.
13. Informacja zwrotna dotycząca zaleceń pokontrolnych dotyczących rozpatrywanego wniosku o
płatność.
14. Akceptacja (poświadczenie) wniosku o płatność przez uprawnionego użytkownika oraz
zatwierdzenie wniosku o płatność przez uprawnionego użytkownika
15. Wygenerowanie dokumentów finansowych i informacji do beneficjenta. Wraz z możliwością ich
edycji.
16. Zarządzanie płatnościami częściowymi.
17. Generowanie zbiorczych wniosków (poświadczeń i deklaracji wydatków) na podstawie statusów
wniosków
18. Wykonawca musi przewidzieć w przyszłości możliwość eksportu dyspozycji operacji
finansowych do programu finansowo księgowego. Zadaniem jest opis sposobu rozszerzenia
modułu o taką funkcjonalność.
5.4.2.3 Wymagania funkcjonalne – generowane dokumenty i zestawienia
1. Wynik weryfikacji wniosku o płatność.
2. Wydatki kwalifikowane wskazane przez beneficjenta we Wniosku o płatność oraz wnioskowana
kwota dofinansowania.
3. Zestawienie wydatków kwalifikowanych objętych Wnioskiem w rozbiciu na pozycje (faktury) –
po autoryzacji.
4. Zestawienie wydatków uznanych do refundacji w rozbiciu na pozycje (faktury) – po autoryzacji.
5. Wydruk harmonogramu rzeczowo-finansowego.
6. Raport płatności na rzecz beneficjenta.
7. Informacje o realizacji wskaźników dotyczących osi priorytetowych, działania, projektu.
8. Informacje o podziale wydatkowanych środków na kategorie interwencji.
9. Informacje o finansach według źródeł finansowania.
10. Zestawienie zaliczek.
11. Zestawienie przeprowadzonych kontroli i ich wyników z podziałem na realizacje poprawne i
zawierające nieprawidłowości.
12. Zestawienie zaplanowanych kontroli wraz z planowanymi terminami ich realizacji.
13. Informacje dotyczące kwot odzyskanych i kwot do odzyskania
Strona 43 z 56
14. Informacje dotyczące kwot wycofanych.
15. Stan alokacji z podziałem na osie priorytetowe, działania, poddziałania
5.4.2.4 Integracja LSI z system finansowo-księgowym
1. Wykonawca musi przewidzieć w przyszłości możliwość eksportu dyspozycji operacji
finansowych do programu finansowo księgowego. Zadaniem jest opis sposobu rozszerzenia
modułu o taką funkcjonalność.
2. Tworzenie zestawień przekazanych transz dotacji w ramach poszczególnych projektów
3. Tworzenie zestawień na podstawie danych wprowadzonych do LSI zawierających całkowite
wartości podpisanych umów w rozbiciu na lata i źródła finansowania, wraz z danymi z umowy,
takimi jak: nazwa projektodawcy, numer rachunku bankowego dla projektu, nr umowy, nr
projektu, Oś Priorytetowa, numer Działania.
4. Tworzenie zestawień wypłat, z podziałem na poszczególne osie priorytetowe i działania w danym
okresie.
5.5 Moduł kontroli i ewidencji nieprawidłowości
Moduł ułatwia ewidencję przeprowadzanych kontroli w ramach realizowanych programów. Kontrole
mogą się odbywać w trakcie realizacji projektu, ale także po zakończeniu realizacji projektu. Przed
rozpoczęciem kontroli Beneficjent powinien być poinformowany o planowanej kontroli
Możliwe są różne rodzaje kontroli (doraźna, planowa, sprawdzająca).
5.5.1 Wymagania funkcjonalne
1. Harmonogramowanie kontroli.
2. Informowanie beneficjentów o planowanej kontroli (wprowadzenie terminu i zakresu i dla
określonego beneficjenta).
3. Dekretacja kontroli projektu na upoważnionych pracowników
4. Zarządzanie (wprowadzanie, edycja, wersjonowanie) przebiegiem kontroli (dokumentowanie
kontroli) oraz zaleceniami pokontrolnymi (komunikacja z beneficjentem poprzez extranet).
5. Obsługa raportów pokontrolnych.
6. Możliwość dołączenia do procesu kontroli pism przychodzących i wychodzących w dowolnym
formacie. Możliwość podglądu dokumentów w formacie PDF.
7. Możliwość dołączenia do raportów pokontrolnych notatek dotyczących kontaktów z
beneficjentem np. treści rozmów telefonicznych lub innych ustaleń. Notatka powinna mieć
Możliwość ustawienia przypomnienia, pojawiającego się na wśród komunikatów systemowych.
8. Dostęp do pełnych informacji dotyczących projektu
9. Ponieważ beneficjent może wnieść zastrzeżenia do informacji pokontrolnej:
9.1. możliwość wprowadzenia zastrzeżeń/wyjaśnień beneficjenta
9.2. rozpatrzenie zastrzeżeń i wyjaśnień otrzymanych od beneficjenta;
9.3. wezwanie beneficjenta do podpisania informacji pokontrolnej
10. Rejestrowanie kontroli
10.1.
numer i termin przeprowadzenia kontroli,
10.2.
instytucja kontrolująca,
10.3.
skład zespołu kontrolującego,
10.4.
nazwa beneficjenta,
10.5.
zakres przedmiotowy kontroli,
10.6.
podstawa prawna kontroli,
10.7.
okres realizacji projektu lub projektów objęty kontrolą,
10.8.
tytuł projektu lub projektów poddawanych kontroli,
Strona 44 z 56
10.9.
ustalenia z kontroli (opis stanu faktycznego, główne wnioski, wykryte naruszenia) wynik
kontroli (czy jest pozytywny lub negatywny),
10.10. osoby podpisujące protokół z datami podpisania.
10.11. zalecenia pokontrolne,
10.12. terminy realizacji zaleceń pokontrolnych,
10.13. kwota do odzyskania,
10.14. stan wprowadzenia zaleceń pokontrolnych.
11. Mechanizm zbierania uwag pokontrolnych jawnych i tajnych
12. Eksport do pliku w formacie xml, PDF, xls, rtf oraz wydrukowanie protokołu z kontroli według
przyjętych wzorców protokołów dla danego programu, priorytetu, działania.
5.5.2 Wymagania funkcjonalne – wydruki
1.
2.
3.
4.
5.
6.
Wydruk harmonogramu kontroli na dany okres.
Wydruk arkusza pokontrolnego
Zestawienie skontrolowanych projektów.
Zestawienie projektów zaplanowanych do kontroli.
Zestawienie projektów nie objętych kontrolą
Wydruki skontrolowanych i zaplanowanych do kontroli projektów z możliwością edycji według
m.in.:
- możliwości wydruku wg osi priorytetowych i działań
- możliwości wydruku wg okresów przeprowadzania kontroli - kwartalne/roczne
- możliwości wydruku wg obszarów jednostek kontrolowanych,
- możliwości wydruku wg miejsca realizacji projektów (województwo / miasto),
- możliwości wydruku wg kwot dofinansowania,
- możliwości wydruku wg projektów, w których były nieprawidłowości,
- możliwości wydruku wg kwot wykrytych nieprawidłowości,
- możliwości wydruku wg kwot odzyskanych oraz kwot pozostałych do odzyskania.
7. W/w dokumenty muszą posiadać możliwość edycji.
5.5.3 Ewidencja nieprawidłowości - wymagania funkcjonalne
1. Na każdym etapie realizacji projektu możliwe jest wykrycie nieprawidłowości.
2. Rejestrowanie nieprawidłowości minimum następujących danych:
2.1. numer nieprawidłowości,
2.2. numer umowy o dofinansowanie,
2.3. nazwa beneficjenta,
2.4. tytuł projektu,
2.5. data wykrycia nieprawidłowości,
2.6. rodzaj nieprawidłowości,
2.7. kwota nieprawidłowości (w podziale na środki wspólnotowe i krajowe w PLN, ogólna kwota
n eprawidło
i
wo cśi w PLN i w Eu or oraz data kursu Euro służąca do przeliczenia
nieprawidłowości),
2.8. kwota do odzyskania (w podziale na należność główną oraz należne odsetki),
2.9. opis nieprawidłowości,
2.10.
opis tekstowy odnośnie działań następczych,
2.11.
informacja o odzyskaniu (w podziale na środki wspólnotowe i krajowe w PLN, ogólna
kwota nieprawidłowości w PLN czerpana z rejestru dłużników)
2.12.
Data rozpoczęcia procedury odzyskiwania
2.13.
Instytucja rozpoczynająca procedurę odzyskiwania
2.14.
inne wprowadzane przez administratora
Strona 45 z 56
3.
4.
5.
6.
Ewidencja nieprawidłowości zgłaszanych do Komisji Europejskiej (KE).
Ewidencja nieprawidłowości niepodlegających zgłoszeniu do Komisji Europejskiej.
Tworzenie Raportów o nieprawidłowościach – bieżących i kwartalnych.
Dołączanie spersonalizowanej korespondencji.
5.6 Moduł administracyjny
5.6.1 Modelowanie procesów
1. Skalowalność i możliwość aktywowania kolejnych procesów „ścieżek” realizacji dla różnych
programów, osi, priorytetów, działań i poddziałań nie ujętych w specyfikacji na dzień rozpoczęcia
realizacji projektu.
2. Osoba o odpowiednimi uprawnieniami ma możliwość dodania kolejnego procesu przetwarzania
wniosku z wszystkimi etapami jego funkcjonowania (ustalanie statusów (także ich słowników),
ustalanie zadań, osób je wykonujących, powiązania, przypisane szablony dokumentów,
uprawnienia w ramach procesów, określani możliwych do prowadzenia dokumentów,
załączników (a także ich ilości i wagi), ect.)
3. Modelowanie procesów podlega wersjonowaniu
4. Edycja procesu jest stworzeniem jego nowej wersji.
5. System udostępniać będzie narzędzia do tworzenia i edycji formularzy użytych procesach.
6. System umożliwiał będzie modyfikację formularzy (wszystkich wymaganych wzorców
dokumentów). Utworzone formularze będą zapisywane w bibliotece formularzy, która umożliwi
ich dalsze wykorzystanie przez uprawnionych użytkowników. W ramach funkcjonalności możliwa
będzie:
6.1. konfiguracja mechanizmów walidacyjnych w formularzach
6.2. edycja istniejących, deaktywowanie (ukrywanie) i dodawanie nowych pól, list, tabel w
formularzach.
6.3. wersjonowanie formularzy
5.6.2 Konfiguracja i zarządzanie
Moduł konfiguracyjny ma umożliwiać konfiguracje systemu pod kątem zarządzania danymi:
1. Procedura instalacji Systemu,
2. Konfiguracja wszystkich elementów Systemu,
a. Zarządzanie słownikami i ich wersjonowanie
b. Zarządzanie listami
c. Obsługa formularzy – dodawanie, edycja i usuwanie dokumentów automatycznie
generowanych przez system i parsowanych w oparciu o „znaczniki specjalne”. Znaczniki
specjalne mają się odwoływać do pól bazy danych co umożliwi personalizowanie
korespondencji. Dopuszcza się Tagi wyliczeniowe, które będą odpowiadały odpowiednim
operacjom matematycznym, tekstowym itp. zawartych w standardzie języka SQL
wspieranym przez System Zarządzania Bazą Danych, na którym zainstalowana jest baza
danych LSI.
d. Edycja pól we wnioskach, ustalanie walidacji, kryteriów oceny, ect.
e. Zarządzanie i tworzenie szablonów dokumentów
f. zarządzanie użytkownikami (dodawanie i usuwanie kont użytkowników LSI)
g. zarządzanie prawami dostępu użytkowników, stopniowanie dostępu (podglądu i edycji) do
poszczególnych elementów systemu (modułów i ich instancji)
h. wgląd do logów systemowych.
3. Procedura aktywacji i dezaktywacji Modułów wchodzących w skład Systemu,
4. Konfiguracja środowiska bazy danych Systemu,
Strona 46 z 56
5. Obsługa podstawowych funkcji bazy danych Systemu,
6. Procedura reagowania w typowych sytuacjach awaryjnych.
5.7 Obecny system LSI
Podstawowy opis istniejącego Systemu LSI zawiera załącznik nr 1.
5.8 Sprawozdawczość i raporty
1. LSI musi umożliwiać generowanie plików xml zgodnych ze standardami komunikacji z KSI 3
(SIMIK 07-13) – Krajowy System Informatyczny, omówionymi w rozdziale 6.
2. Architektura danych musi, poprzez stworzenie znormalizowanych tablic danych, pozwalać na
eksport danych do Microsoft Access oraz translację do definiowalnych raportów.
6 Integracja danych
Wymagana jest integracja Systemu LSI z innymi współpracującymi systemami poprzez utworzenie
interfejsu wymiany danych. LSI będzie współpracował m.in. z KSI (SIMIK 07-13) oraz Extranetem
Podstawowy zakres wymiany danych pomiędzy systemami został zdefiniowany w niniejszym
dokumencie na etapie opisu procesów. Wykonawca systemu będzie zobowiązany do zweryfikowania i
uzgodnienia z Zamawiającym ostatecznego zakresu wymiany danych.
System wymaga spełnienia wszystkich poniższych kryteriów:
• Zgodność z wymaganiami określonymi w normie ISO / IEC 9126 lub równoważnej na etapie
projektowania, wdrażania i modyfikowania Systemu.
• Spełnienie minimalnych wymagań dla systemów teleinformatycznych zgodnie ze standardami
podanymi w Rozporządzeniu Rady Ministrów z dnia 11 października 2005 r. w sprawie
minimalnych wymagań dla systemów teleinformatycznych.
• Wsparcie dla standardu J2EE lub równoważnego na poziomie serwera aplikacji.
• Wsparcie dla standardu web services w zakresie wymiany informacji pomiędzy aplikacjami w
zależności od typu rozwiązania.
• Wsparcie dla standardu wymiany danych XML.
• Wsparcie dla otwartych standardów (nie w przypadku systemów operacyjnych).
• System udostępni rejestr wydarzeń, które miały miejsce w systemie.
• Rejestr wydarzeń powinien dostarczyć śladów działań konkretnego Użytkownika systemu i
przez to stanowić podstawę wypełnienia wymogów odpowiedzialności za bezpieczeństwo
systemu. Ścieżka audytu ma ponadto służyć identyfikacji drogi przepływu, przetwarzania
informacji pomiędzy aplikacjami systemu i poziomów dostępu Użytkowników.
• Zgodność z Ustawą z dnia 29 sierpnia 1997 r. o ochronie danych osobowych (Dz. U. z 2002 r.
Nr 101, poz. 926, z późn. zm.)
Minimalny zakres danych koniecznych do wprowadzenia do KSI został określony w załączniku nr 4 i nr 5 do dokumentu
„Narodowe Strategiczne Ramy Odniesienia 2007-2013. Wytyczne w zakresie warunków gromadzenia i przekazywania
danych w formie elektronicznej” oraz w załączniku nr 1 do „Wytycznych Ministra Rozwoju Regionalnego w zakresie
sprawozdawczości”.
Dane z lokalnego systemu do systemu krajowego przekazywane powinny być w postaci plików z danymi w formacie XML.
Struktura i format plików XML opisane zostały za pomocą języka XML Schema, które umieszczono na stronie Ministerstwa
Finansów pod adresem www.mf.gov.pl w zakładce Ministerstwo Finansów, następnie Unia Europejska / SIMIK/ SIMIK 07 –
13 Schematy XML oraz z regułami opisanymi w dokumencie „SimikXML – Reguły zgodności danych”. Dodatkowe
wymagania odnośnie przekazywania danych zostały opisane w dokumencie „System SIMIK 07-13. SimikXML –
Specyfikacja protokołu integracji LSI i KSI”.
3
Strona 47 z 56
•
•
•
Zgodność z Ustawą o informatyzacji działalności podmiotów realizujących zadania publiczne
(Dz. U. 2005 r., Nr 64, poz. 565 z późn. zm.) z dnia 17 lutego 2005 r.
Zgodność z Ustawą z dnia 18 września 2001 r. o podpisie elektronicznym (Dz. U. z 2001 r. Nr
130, poz. 1450 z późn. zm.).
Dla interfejsu www standard kodowania stron zgodny z W3C, kodowanie polskich znaków
zgodnie z UTF-8.
6.1 Integracja z systemem KSI (SIMIK 07-13)
KSI (SIMIK 07-13) – Krajowy System Informatyczny, jest systemem rejestracyjnym, który gromadzi
dane wprowadzane do centralnej bazy danych po wystąpieniu określonych zdarzeń (np. po
stwierdzeniu, że złożony wniosek o dofinansowanie projektu spełnia wymogi formalne). Różne
instytucje biorące udział we wdrażaniu poszczególnych programów operacyjnych (w tym PARP)
wprowadzają dane do KSI. Dane mogą być wprowadzane w dwojaki sposób. Mogą być uzupełniane
poprzez manualne wpisywanie (edytowanie) danych do kolejnych pól lub przy pomocy eksportów
generowanych z Lokalnych Systemów Informatycznych w postaci plików XML o ściśle określonej
strukturze. KSI umożliwia w szczególności gromadzenie danych w następującym zakresie:
• ewidencjonowanie wniosków o dofinansowanie projektu,
• ewidencjonowanie umów/decyzji o dofinansowanie projektu,
• ewidencjonowanie wniosków o płatność,
• ewidencjonowanie danych dotyczących kontroli poszczególnych projektów.
W związku z powyższym, System Extranet powinien zapewnić możliwość wymiany danych z KSI.
Minimalny zakres danych koniecznych do wprowadzenia w KSI został określony w załączniku nr 4 i
nr 5 do dokumentu „Narodowe Strategiczne Ramy Odniesienia 2007-2013. Wytyczne w zakresie
warunków gromadzenia i przekazywania danych w formie elektronicznej” oraz w załączniku nr 1 do
„Wytycznych Ministra Rozwoju Regionalnego w zakresie sprawozdawczości”.
Przy użyciu interfejsu wymiany, dane z lokalnego systemu przekazywane będą w postaci plików w
formacie XML. Struktura i format plików XML opisane zostały za pomocą języka XML Schema,
które umieszczono na stronie Ministerstwa Finansów pod adresem www.mf.gov.pl w zakładce
Ministerstwo Finansów, następnie Unia Europejska / SIMIK/ SIMIK 07 – 13 Schematy XML oraz z
regułami opisanymi w dokumencie „SimikXML – Reguły zgodności danych”. Dodatkowe wymagania
odnośnie przekazywania danych zostały opisane w dokumencie „System SIMIK 07-13. SimikXML –
Specyfikacja protokołu integracji LSI i KSI”.
6.2 Integracja z Systemem CMS web.gov.pl i Extranetem
System CMS i Portal web.gov.pl jako źródło informacji dla beneficjentów działań 8.1 i 8.2 PO IG
będą reprezentować informacje związane z realizacją wniosków w powyższych działaniach.
Wymagana jest integracja Systemu LSI z Systemem Extranet w celu publikacji koniecznych zestawień
i podglądu danych z realizacji wniosków.
6.3 Integracja z innymi źródłami danych
Wykonawca uwzględni w Systemie funkcjonalność pozwalającą przy użyciu interfejsu wymiany
danych na definiowanie innych zewnętrznych źródeł danych.
7 Testy funkcjonalności i odbiór systemu
7.1 Specyfikacja testów
W trakcie trwania Umowy przewiduje się następujące typy testów:
Strona 48 z 56
1. Testy wewnętrzne - przeprowadzane przez zespół Wykonawcy przed dostawą oprogramowania
Zamawiającemu. Testy zostaną przeprowadzone wg scenariuszy testowych
przygotowanych przez Wykonawcę, a Zaakceptowanych przez Zamawiającego. W ramach
testów wewnętrznych zostaną przeprowadzone testy iteracyjne - organizowane i przygotowywane
przez Wykonawcę testy komponentów oprogramowania (modułów) z udziałem użytkownika
końcowego.
Wykonawca jest odpowiedzialny za:
a) przygotowanie danych testowych,
b) przygotowanie scenariuszy testów i przekazanie ich Zamawiającemu do wglądu,
c) przygotowanie środowiska testowego,
d) aktywowanie modułów,
e) ładowanie danych testowych.
Wykonanie testów iteracyjnych ma zapewnić użytkownikom końcowym możliwość oceny
funkcjonalności przygotowanego oprogramowania, wykrycia błędów w oprogramowaniu
na wczesnym etapie i zgłoszenie uwag, zmian oraz uzupełnień do założonej funkcjonalności.
Testy iteracyjne składają się z następujących rodzajów testów funkcjonalnych:
a) testy czarnej skrzynki - testy odnoszą się do specyfikacji pracy systemu. Podczas analizy
wyników testów nie jest badany wewnętrzny sposób realizacji funkcji systemu. Testy
weryfikują implementację funkcjonalności z podaną w specyfikacji. Dane wejściowe
i oczekiwane wyniki przygotowywane są na podstawie specyfikacji. Podczas testów system
jest traktowany jak czarna skrzynka, na wejściu której podajemy przygotowane dane
wejściowe i sprawdzamy, czy otrzymane wyniki zgadzają się z oczekiwanymi.
b) testy modułowe - testy funkcjonalnej całości określonego fragmentu systemu (modułu), które
mają na celu sprawdzenie, czy aplikacja działa zgodnie z uzgodnioną specyfikacją wymagań
dla poszczególnych modułów. Upewnienie się, że każda funkcja umożliwia realizację
wszystkich dopuszczalnych akcji i sytuacji, oraz uniemożliwia realizację każdej akcji
i sytuacji zabronionej,
c) testy GUI - sprawdzenie poprawności nawigacji w systemie,
d) interfejsu i specyfikacji help-u,
e) testy administracji i kontroli procedur administracji,
4. Testy akceptacyjne - przygotowane i przeprowadzone przez Zamawiającego testy wytworzonego
systemu informatycznego w środowisku testowym odseparowanym od środowiska
produkcyjnego. Testy te wykonywane są u Zamawiającego, na sprzęcie dostarczonym i
przygotowanym przez Wykonawcę w obecności przedstawicieli Wykonawcy i audytorów
zewnętrznych. Przed rozpoczęciem testów Wykonawca przeprowadzi szkolenie dla zespołu
testowego. Wykonawca odpowiada za:
a) przygotowanie planu testów, danych testowych
b) dostarczenie arkuszy testowych,
c) przygotowanie środowiska testowego,
d) instalację aplikacji,
e) ładowanie danych testowych,
f) przygotowanie scenariuszy testowych zawierających co najmniej następujące pola dla każdego
testowanego przypadku: nazwa przypadku użycia, opis testu, warunki wstępne, procedurę
testową, oczekiwane rezultaty. Scenariusze testowe podlegają akceptacji przez
Zamawiającego.
Wykonanie testów akceptacyjnych ma potwierdzić, że system spełnia założone kryteria jakości,
w tym że jego funkcjonalność jest zgodna z wymaganiami biznesowymi użytkowników i nie
zawiera błędów uniemożliwiających jego użycie. Wynikiem testów akceptacyjnych jest raport
Strona 49 z 56
z testów, który jest podstawą sporządzenia Protokołu Akceptacji Produktu lub Usługi. Testy
akceptacyjne będą składały się z następujących typów testów:
a) Testy funkcjonalne:
a) testy czarnej skrzynki - testy odnoszą się do specyfikacji pracy systemu. Podczas analizy
wyników testów nie jest badany wewnętrzny sposób realizacji funkcji systemu. Testy
weryfikują implementację funkcjonalności z podaną w specyfikacji. Dane wejściowe
i oczekiwane wyniki przygotowywane są na podstawie specyfikacji. Podczas testów
system jest traktowany jak czarna skrzynka, na wejściu której podajemy przygotowane
dane wejściowe sprawdzamy, czy otrzymane wyniki zgadzają się z oczekiwanymi,
b) testy modułowe - testy funkcjonalnej całości określonego fragmentu systemu (modułu),
które mają na celu sprawdzenie, czy aplikacja działa zgodnie z uzgodnioną specyfikacją
wymagań dla poszczególnych modułów. Upewnienie się, że każda funkcja umożliwia
realizację wszystkich dopuszczalnych akcji i sytuacji, oraz uniemożliwia realizację każdej
akcji i sytuacji zabronionej,
c) testy GUI - sprawdzenie nawigacji w systemie, sprawdzenie poprawności interfejsu
i specyfikacji modułu help ,
d) testy administracji i kontroli procedur administracji,
b) Testy integracyjne:
i. testy instalacji i uzyskanej konfiguracji – testy polegają na sprawdzeniu kompletności
instalacji, zgodności przebiegu procesu instalacji z instrukcją, dokumentacją oraz
poprawności uzyskanej konfiguracji,
ii. testy komunikacji między modułami - testy poprawności powiązań między modułami.
Celem testu jest wykazanie, że poszczególne moduły systemu prawidłowo ze sobą
współpracują i na tej podstawie dalsze testy sprawdzają czy funkcjonalność systemu
wymagająca zaangażowania wielu modułów jest również realizowana prawidłowo,
c) Testy wydajnościowe i bezpieczeństwa:
i. testy wydajności - dotyczą wydajności działania systemu w różnych warunkach jego
obciążenia. Testy weryfikują czy system jest w stanie w oczekiwanym czasie
obsłużyć/wykonać oczekiwaną ilość danych/funkcji. Testy wymagają pomiarów czasu
wykonania poszczególnych funkcji i zweryfikowania przepustowości kanałów
przeznaczonych do obsługi danych. W celu uzyskania właściwej oceny należy
zasymulować w miarę możliwości rzeczywiste warunki pracy systemu w jego
rzeczywistym środowisku wraz z symulowanym obciążeniem rzeczywistym kanałów
transmisji danych,
ii. testy obciążenia znamionowego - celem testu jest zweryfikowanie zachowania się systemu
w typowych warunkach, potwierdzając tym samym prawidłową, stabilną pracę systemu,
z wydajnością nie mniejszą od oczekiwanej, zdefiniowaną w dokumentacji technicznej,
iii. testy przeciążenia – celem testu jest zweryfikowanie zachowania się systemu
w nietypowych warunkach. Test zazwyczaj ma potwierdzić, że system zachowuje się
stabilnie i nie doprowadza do utraty danych (niespójności bazy itp.),
iv. testy stabilności - kontrola stabilnej pracy systemu przez czas minimum 24 godzin,
v. testy bezpieczeństwa – w tym bezpieczeństwo dostępu do danych i zabezpieczenia danych
przed utratą, administracja użytkownikami i bazą danych, zakres dostępu do funkcji
i danych, cross site scripting, SQL injection, ; Reakcja na nieoczekiwane dane. Reakcja na
podmianę komponentów, bibliotek systemu, itp.
vi. testy regresywne – wykonywane po wprowadzeniu zmian do systemu i mające na celu
sprawdzenie, czy nowo wprowadzone poprawki nie mają wpływu na wcześniej
zrealizowane funkcje systemu,
Po zakończeniu każdego etapu wdrożeniowego, na podstawie przeprowadzonych testów kończących
każdy etap zostaną sporządzone raporty końcowe.
Strona 50 z 56
W trakcie trwania projektu mogą zostać wykonane testy funkcjonalności dotyczące zakończonych
etapów. Zamawiający z miesięcznym wyprzedzeniem poinformuje o dacie rozpoczęcia w/w testów. W
pracach komisji wykonującej w/w testy mogą uczestniczyć także powołani przez Zamawiającego
Eksperci.
7.2 Odbiór przedmiotu zamówienia
Akceptacja i odbiór systemu w podziale na etapy odbędzie się na podstawie:
1. Oświadczenia Wykonawcy o przeprowadzeniu testów wewnętrznych zgodnie ze specyfikacją
załączoną do oświadczenia. Oświadczenie musi zawierać informacje o ich wyniku.
2. Oświadczeniu wykonawcy o zgodności wykonanego projektu z uwarunkowaniami budowy
systemu wymienionymi w ZZW w tym w szczególności z aktami prawnymi i uwarunkowaniami
technicznymi.
3. Protokołów z testów akceptacyjnych przeprowadzonych wspólnie przez Zamawiającego i
Audytorów zewnętrznych, Wykonawcę na sprzęcie Wykonawcy wg scenariuszy testowych
dostarczonych przez Wykonawcę, a Zaakceptowanych przez Zamawiającego.
8 Migracja danych
bazodanowych
z
dotychczasowych
systemów
W zakresie projektu budowy i wdrożenia Systemu LSI przewidziana jest migracja danych polegająca
na przeniesieniu do Systemu LSI wszystkich wymaganych danych z następujących źródeł:
- KSI (SIMIK 07-13) - import wymaganego, dostępnego zakresu danych (format xml),
- System LSI-PARP- aktualnie funkcjonujący systemem do obsługi beneficjentów działań 8.1 i 8.2,
• import wszystkich danych z dotychczasowego systemu LSI
• import z plików xls,
• Import z plików xml
• Import z MS Access
• Wprowadzenie danych z kart uprawnień (przekazanych w formie papierowej w ilości około
50)
Przed wykonaniem tego procesu Wykonawca przygotuje projekt automatycznego dwukierunkowego
transferu i migracji danych, który umożliwi jej sprawną realizację. Proces migracji danych będzie
realizowany przez Wykonawcę w trakcie realizacji i wdrożenia Systemu. Szczegółowy zakres danych,
które będą podlegać migracji zostanie zdefiniowany przez Wykonawcę, przy współpracy
Zamawiającym.
Szacunkowy zakres danych do migracji dla PO IG działań 8.1 i 8.2 informacje o projektach w tym:
dane historyczne, wnioski projektowe (także nie realizowane), wnioski o dofinansowanie,
umowy/decyzje z aneksami, wnioski o płatność, i dane dotyczące kontroli projektu, - ok.10000
projektów. Dane dodatkowe dotyczące zestawień dla Instytucji Pośredniczących oraz Instytucji
Wdrażających.
9 Uwarunkowania budowy Systemu
9.1 Uwarunkowania prawno – organizacyjne
9.1.1 Akty prawne
Podstawowymi aktami prawnymi stanowiącymi wytyczne do budowy Systemu LSI są aktualne
obowiązujące wersje następujących dokumentów:
Strona 51 z 56
a) ustawa z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych (Dz. U. z 2006 r., nr 90,
poz. 631 z późn. zm.); Ustawa z dnia 9 listopada 2000 r. o utworzeniu Polskiej Agencji Rozwoju
Przedsiębiorczości (D.U, 2007 Nr 42, poz. 275 z późn. zm.).
b) Zarządzenie nr 46 Ministra Gospodarki i Pracy z dnia 28 grudnia 2004 r. zmieniające zarządzenie
w sprawie nadania statutu Polskiej Agencji Rozwoju Przedsiębiorczości.
c) Działania 8.1 i 8.2 Programu Operacyjnego Innowacyjna Gospodarka:
a. Szczegółowy opis priorytetów Programu Operacyjnego Innowacyjna Gospodarka 2007-2013,
b. Harmonogram uruchomienia Programu Operacyjnego Innowacyjna Gospodarka 2007-2013,
c. Rozporządzenie Ministra Rozwoju Regionalnego w sprawie udzielania przez PARP pomocy
finansowej w ramach Programu Operacyjnego Innowacyjna Gospodarka, opublikowane w
Dzienniku Ustaw z dnia 7 kwietnia 2008 r. nr 68 poz. 414,
d. Program Operacyjny Innowacyjna Gospodarka w wersji zatwierdzonej przez Radę Ministrów
30 października 2007 r8.
d) Specyfikacja Istotnych Warunków Zamówienia (SIWZ) na „Przygotowanie, realizację i
koordynację kampanii promocyjnej i Public Relations portalu wspierającego realizację działań 8.1 i
8.2 Programu Operacyjnego Innowacyjna Gospodarka (PO IG) w 2008 i 2009 r.” (dokumentacja
przetargowa dostępna pod adresem http://bip.parp.gov.pl/index/more/5646)
e) Rozporządzenie Ministra Gospodarki i Pracy z dnia 27 stycznia 2005 r. w sprawie Krajowego
Systemu Usług dla Małych i Średnich Przedsiębiorstw (Dz.U. Nr 27, poz. 221).
f) Strategia Komunikacji Funduszy Strukturalnych w Polsce w ramach Narodowej Strategii Spójności
na lata 2007-2013.
Dokumentacja techniczna:
g) System Identyfikacji Wizualnej PARP.
h) Specyfikacja Istotnych Warunków Zmówienia na „Zaprojektowanie, wykonanie i wdrożenie
portalu wspierającego realizację działań 8.1 i 8.2 Programu Operacyjnego Innowacyjna
(dokumentacja przetargowa dostępna pod adresem http://bip.parp.gov.pl/index/more/5700),
i) Szczegółowe warunki przekazywania danych z LSI (SIMIK 07-13) zawarte w przygotowanym
przez Ministerstwo Finansów dokumencie „Specyfikacja protokołu integracji LSI i KSI (SIMIK
07-13)”,
j) Rozporządzenie Rady Ministrów w sprawie minimalnych wymagań dla systemów
teleinformatycznych (Dz. U. 2005 nr 212 poz. 1766).
k) Opublikowane standardy i specyfikacje techniczne w szczególności World Wide Web Consortium.
l) Ustawa z dnia 14 czerwca 1960 r. Kodeks postępowania administracyjnego (Dz.U. 1960 nr 30 poz.
168).
m) Ustawa z dnia 18 września 2001 r. o podpisie elektronicznym (Dz.U.2001 nr 130 poz. 1450).
n) Ustawa z dnia 27 lipca 2001 r. o ochronie baz danych (Dz.U. z 2001 r. Nr 128, poz. 1402, z 2004 r.
Nr 96, poz. 959).
o) Ustawa z dnia 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną (Dz. U. Nr 144, poz. 1204,
z późn. zm).
p) Ustawa z dnia 29 sierpnia 1997r o ochronie danych osobowych (Dz.U.1997 nr 133 poz. 883);
q) Ustawa z dn. 17 luty 2005r o informatyzacji działalności podmiotów realizujących zadania
publiczne (Dz.U.Nr 67 poz. 619).
r) Ustawa o dostępie do informacji publicznej z dnia 06.09.2001 (Dz.U.nr 112, poz.1198 z póź.zm.).
s) Rozporządzenie MSWiA z dn. 30 październik 2006 r. w niezbędnych elementów struktury
dokumentów elektronicznych.
t) Rozporządzenie MSWiA z dn. 30 październik 2006 r. w sprawie szczegółowego sposobu
postępowania z dokumentami elektronicznymi.
Strona 52 z 56
u) Rozporządzenie MSWiA z dn. 2 listopad 2006 r. w sprawie wymagań technicznych formatów
zapisu i informatycznych nośników danych, na których utrwalono materiały archiwalne
przekazywane do archiwów państwowych.
v) Rozporządzenie Prezesa Rady Ministrów z dnia 29 września 2005 r. w sprawie warunków
organizacyjno-technicznych doręczania dokumentów elektronicznych podmiotom publicznym
(Dz.U. 2005 nr 200 poz. 1651).
w) Rozporządzenie z dnia 27 listopada 2006 roku (Dz. U. Nr 227, poz. 1664) w sprawie sporządzania i
doręczania pism w formie dokumentów elektronicznych z dnia 27 listopada 2006 roku.
Wymogi te zostaną zidentyfikowane przez Wykonawcę podczas analizy potrzeb Zamawiającego.
9.1.2 Regulaminy działania 8.1 i 8.2 PO IG
Kolejnymi aktami prawnymi stanowiącymi wytyczne do budowy LSI są aktualne obowiązujące
wersje następujących dokumentów:
1. Regulamin przeprowadzania konkursu w ramach Programu Operacyjnego Innowacyjna
Gospodarka Priorytet 8: Społeczeństwo informacyjne – zwiększanie innowacyjności gospodarki
Działanie 8.1: Wspieranie działalności gospodarczej w dziedzinie gospodarki elektronicznej wraz
z załącznikami
2. Regulamin przeprowadzania konkursu w ramach Programu Operacyjnego Innowacyjna
Gospodarka Priorytet 8: Społeczeństwo informacyjne – zwiększanie innowacyjności gospodarki
Działanie 8.2: Wspieranie wdrażania elektronicznego biznesu typu B2B
Wymogi te zostaną zidentyfikowane przez Wykonawcę podczas analizy potrzeb Zamawiającego.
9.1.3 Wymogi struktury organizacyjnej
Ponadto Wykonawca dostosuje System do wymogów wynikających ze struktury organizacyjnej PARP
oraz instytucji zewnętrznych i potrzeb wynikających z zakresu obowiązków merytorycznych
poszczególnych zespołów i sekcji, odpowiedzialnych za realizację PO IG, w tym RIF.
9.1.4 Nowelizacje aktów prawnych
W przypadku zmian w przepisach prawnych zostanie przeprowadzona aktualizacja Systemu
i dostosowanie go do nowych norm prawnych (w czasie trwania okresu gwarancyjnego) najpóźniej do
dnia wejścia w życie nowych przepisów prawnych – chyba, że normy prawne określają termin wejścia
w życie przepisu w inny sposób.
9.1.5 Przeniesienie autorskich praw majątkowych
1. Wykonawca przekaże Zamawiającemu kody źródłowe oprogramowania wytworzonego w wyniku
realizacji Umowy oraz przeniesie autorskie prawa majątkowe, każdorazowo wraz z dostawą nowej
zaakceptowanej wersji systemu oraz po zakończeniu realizacji Umowy z chwilą podpisania
protokołu odbioru produktów Projektu.
2. Wykonawca przenosi na Zamawiającego autorskie prawa majątkowe do produktów
wytworzonych w wyniku realizacji Umowy, w tym zwłaszcza oprogramowania, dokumentacji
technicznej i wszystkich dokumentów będących wynikiem realizacji Umowy oraz prawo
do zezwalania na wykonywanie zależnego prawa autorskiego na zasadach określonych w
niniejszym Rozdziale oraz umowie.
3. Autorskie prawa majątkowe do produktów powstałych w wyniku realizacji Umowy przechodzą na
Zamawiającego z chwilą dokonania ich protokolarnego odbioru. Przeniesienie autorskich praw
majątkowych na Zamawiającego obejmuje wszelkie pola eksploatacji wskazane w art. 50 i 74 ust.
Strona 53 z 56
4 ustawy z dnia 4 lutego 1994 r. o prawie autorskim i prawach pokrewnych (Dz. U. z 2006r.
Nr 90, poz. 631, z późn. zm.) oraz następujące pola eksploatacji obejmujące prawo do:
a) wykorzystywania, utrwalania i zwielokrotniania oprogramowania wykonywalnego i kodów
źródłowych w całości lub w części środkami i formie dysków twardych, tasiemek streamerów,
dyskietek, nośników CD-R/RW, DVD-R/RW, przenośnej pamięci zewnętrznej, poczty
elektronicznej, za pomocą internetu lub intranetu, przesyłania za pomocą sieci
bezprzewodowych, na wydrukach papierowych,
a) tłumaczenia, przystosowywania, rozbudowy, zmiany układu lub innej zmiany
w oprogramowaniu, w tym: uzupełnienia, skracania, przeróbki oraz sporządzania nowej wersji
oprogramowania wykonywalnego i kodów źródłowych,
b) rozpowszechniania przy pomocy nośników informacji, określonych w pkt. 1,
c) odpłatnego lub nieodpłatnego udostępniania do korzystania osobom trzecim (licencja), najmu
i dzierżawy oprogramowania lub jego kopii,
d) modyfikowania kodu źródłowego we własnym zakresie lub przez osoby trzecie.
4. W ramach wynagrodzenia za wykonanie umowy Wykonawca przeniesie w dniu odbioru
końcowego na Zamawiającego autorskie prawa majątkowe, w tym prawo do zezwalania na
wykonywanie zależnego prawa autorskiego, do wszystkich nowo powstałych pól eksploatacji
systemu.
9.2 Uwarunkowania techniczne
Obecnie Zamawiający wykorzystuje do obsługi aplikacji internetowych systemy operacyjne i
rozwiązania typu open-source.
Serwery www i aplikacyjne Apache/Tomcat,
Silniki baz danych MySQL i PostgreSQL.
Zamawiający oczekuje od Wykonawcy dostosowania się do obecnie wykorzystywanych przez PARP
standardów.
Dodatkowe wymagania:
1. Język programowania:
a. PHP5 całkowicie obiektowy w standardzie strict.
b. Wymagany interfejs do bazy PDO.
c. Wymagane używanie jednej z wybranych bibliotek template dla html.
d. Kodowanie w standardzie UTF8.
e. Wymaganie użycie autoload i globalnego router’a całego systemu.
f. Zamawiający dopuszcza wykorzystanie technologii Ajax, JavaScript
2. Preferowanie bazy danych: w kolejności: PostgreSQL 8.x, MySQL 5.x
3. Komunikacja z innymi systemami (np. extranet)
a. Komunikacja powinna być zrealizowana za pomocą standardu SOAP.
b. Zaimplementowane powinny być podstawowe funkcjonalności:
i. po autoryzacji i otrzymaniu klucza pobranie określonych danych dla
Extranetu
ii. autoryzacja na poziomie superadministratora powinna pozwalać na export
dowolnej tablicy lub view z bazy do formatu XML
4. Synchronizacja danych VPN – VPN lub inny przezroczysty dla samego systemu. Szczegółowe
ustalenia na etapie przedwdrożeniowym. Koszt urządzeń lub implementacji po stronie
Zamawiającego.
Strona 54 z 56
9.3 Obciążenie systemu
W celu zachowania spójności i kompatybilności z CMS podczas tworzenia projektu konfiguracji
systemu Wykonawca winien kierować się przewidywanym obciążeniem całego Systemu, przyjmując,
że Platforma (LSI, Extranet i CMS) będzie odwiedzany przez 20 000 użytkowników jednocześnie.
Wykonawca określi przede wszystkim:
1. Techniczne dane na temat wzorcowego czasu reakcji działania systemu (szybkość działania)
2. Prognozowany przyrost danych w Systemie.
3. Prognozowaną ilość przesyłanych danych.
4. Liczbę przesyłanych wiadomości.
5. Obciążenie serwerów jak i wymaganą pojemność dyskową do prawidłowej pracy Systemu.
9.4 Zwiększanie wydajności
Przy założeniu stale rosnącej ilość użytkowników, co wiąże się z problemem rosnącego obciążenia
serwerów: zużycia pamięci operacyjnej i dyskowej Wykonawca w procesie tworzenia Systemu będzie
się kierował możliwością skalowalności Systemu z założeniem zwiększenia wydajności i szybkości
działania. Założeniem Wykonawcy będzie dążenie do rozwiązania spełniającego wymogi systemu
klasy Enterprise. Wykonawca przeanalizuje i wdroży najlepsze rozwiązanie mając na uwadze między
innymi takie rozwiązania jak:
1. Replikacja baz danych serwera.
2. Tworzenie rozwiązań klastrowych
na odrębnych serwerach.
–
przez
uruchomienie
kilku
instancji
Systemu
3. Udostępnianie wszystkich współdzielonych plików jako udziałów NFS (Network File System).
4. Rozłożenie obciążenia generowanego przez skrypty na kilka serwerów fizycznych przy
wykorzystaniu serwera Proxy.
5. Natywne rozwiązanie klastrowe dla bazy MySQL (NDB cluster).
6. Rozwiązania mysqlproxy i memcached.
9.5 Wymagania modyfikowalności
a) Modyfikowalność wg normy ISO/IEC 9126 to łatwość przystosowywania systemu do
zmieniających się wymagań Użytkownika (rozbudowa).
b) Istnieje możliwość zwiększania liczby Użytkowników Systemu bez konieczności zmian
projektowych.
c) Brak technicznych ograniczeń dotyczących liczby jednocześnie pracujących Użytkowników
(skalowalność systemu).
d) Brak technicznych ograniczeń na ilość danych gromadzonych w systemie.
e) System powinien być przenośny na platformę (sprzętową i bazodanową) o niższych i o
wyższych parametrach.
f) Dostawca powinien zapewnić poprzez parametryzację możliwość łatwego dostosowania
systemu i uniknięcia zmiany oprogramowania przy zmieniających się wymaganiach, np.
prawnych, proceduralnych, rynkowych lub zmian w zakresie wymiany danych pomiędzy LSI
a systemem KSI (SIMIK 07-13), Generatorem Wniosków o Płatność POIG.
g) Konkretne parametry powinny być ustalone w trakcie analizy szczegółowej.
Strona 55 z 56
9.6 Wymagania dostępności
a) Zamawiający wymaga dostępności wg normy ISO/IEC 9126 określającej czas i warunki, na
jakich system jest dostępny. Z pojęciem dostępności (wg metodologii SDLC, COBIT
AI2.2.13) wiążą się również oprócz dostępu do systemu takie elementy, jak: możliwości
uruchomienia systemu na jak największej ilości platform technologicznych i sprzętowych, a
także wymuszenie odpowiedniej modularności systemu, właściwej dokumentacji oraz redukcji
do minimum przestojów.
b) Praca systemu w zakresie wypełniania ogólnodostępnych formularzy elektronicznych
wniosków w trybie ciągłym, minimum 24h/d - 7d/w - 365d/y.
c) Dostęp (on-line) do wszystkich danych gromadzonych w Systemie, w okresie jego
eksploatacji.
d) Dostępność oprogramowania i technologii, w oparciu o które zbudowany jest System.
e) Możliwość ograniczenia dostępu do wybranych zasobów przez niepowołane osoby.
f) Dostępność do odpowiedniej dokumentacji Systemu (projektowej, technicznej,
administracyjnej, eksploatacyjnej [procedury] i dokumentacji Użytkownika).
Strona 56 z 56

SIWZ - PARP - SI KSU MSP

Transkrypt

Podobne dokumenty

Specjalista ds. wsparcia IT

Instrukcja obsługi Generatora Wniosków o Dofinansowanie

Projekt uchwaly na ZWZ 30 czerwca 2014 podzial

Wymagania techniczne i konfiguracja przeglądarek internetowych.

Problemy podgrzewania wody użytkowej – jakie pH i LSI?

Załącznik nr 4 - inf

WAKACJE W LSI LONDON, KINGSTON 2011

Załącznik nr 6 do SIWZ

Załącznik nr. 7 WYKAZ NARZĘDZI, WYPOSAŻENIA ZAKŁADU I