zakres zadań wykonawcy - web.gov.pl · p) przeprowadzi na podstawie uprzednio zaakceptowanych...

Załącznik nr 1 – Zakres Zadań Wykonawcy

Strona 1 z 56

Zakres Zadań Wykonawcy „Analiza systemu LSI (Lokalnego Systemu Informatycznego) oraz

prace programistyczne dostosowania systemu do potrzeb ekstranetu”


Strona 2 z 56

1 INFORMACJE O ZAMAWIAJĄCYM .................................................................................................... 4

1.1 PARP ................................................................................................................................................... 41.2 FINANSOWANIE ..................................................................................................................................... 4

2 PRZEDMIOT ZAMÓWIENIA .................................................................................................................. 4

3 ZAKRES PRAC BĘDĄCYCH PRZEDMIOTEM ZAMÓWIENIA ...................................................... 5

3.1 OPRACOWANIE ORGANIZACJI PROJEKTU I HARMONOGRAMU ................................................................ 63.1.1 Organizacja projektu ....................................................................................................................... 63.1.2 Harmonogram ................................................................................................................................. 6

3.2 ASYSTA TECHNICZNA ........................................................................................................................... 83.3 SERWIS GWARANCYJNY ........................................................................................................................ 9

4 WYMAGANIA DOTYCZĄCE LSI ........................................................................................................ 10

4.1 ZAŁOŻENIA ......................................................................................................................................... 104.2 SŁOWNICZEK ...................................................................................................................................... 114.3 WYMOGI DOTYCZĄCE ESTETYKI I ERGONOMII .................................................................................... 154.4 INTERFEJS UŻYTKOWNIKA .................................................................................................................. 16

4.4.1 Wymagania dotyczące Interfejsu użytkownika .............................................................................. 164.4.2 E-Dostępność ................................................................................................................................ 174.4.3 Technologia zastosowana do budowy interfejsu ........................................................................... 174.4.4 Nawigacja ..................................................................................................................................... 174.4.5 Graficzne rozmieszczenie elementów interfejsu ............................................................................ 18

4.5 WYMAGANIA DOTYCZĄCE UŻYTECZNOŚCI ......................................................................................... 194.5.1 Formularze .................................................................................................................................... 194.5.2 Odnośniki ...................................................................................................................................... 194.5.3 Typografia i formatowanie tekstu .................................................................................................. 194.5.4 Układ elementów ........................................................................................................................... 204.5.5 Grafika .......................................................................................................................................... 204.5.6 Komunikaty o błędach ................................................................................................................... 20

4.6 WYMAGANIA TECHNICZNE DOTYCZĄCE SYSTEMU ............................................................................. 204.6.1 Modułowa budowa Systemu .......................................................................................................... 214.6.2 Bezpieczeństwo Systemu ................................................................................................................ 21

5 MODUŁY LSI ........................................................................................................................................... 22

5.1 SŁOWNIKI STATUSÓW ......................................................................................................................... 235.2 MODUŁ OBSŁUGI KONKURSÓW ........................................................................................................... 24

5.2.1 Funkcjonalność „zarządzanie konkursami” ................................................................................. 245.2.2 Funkcjonalność „rejestracja wniosków o dofinansowanie” ......................................................... 255.2.3 Funkcjonalność „dekretacja wniosków do oceny formalnej” ....................................................... 255.2.4 Funkcjonalność „ocena formalna” ............................................................................................... 265.2.5 Funkcjonalność „dekretacja wniosków do oceny merytorycznej” ................................................ 285.2.6 Funkcjonalność „ocena merytoryczna” ........................................................................................ 295.2.7 Funkcjonalność „oprotestowanie wniosku” ................................................................................. 305.2.8 Funkcjonalność „generowanie listy rankingowej” ....................................................................... 31

5.3 MODUŁY BENEFICJENTA .................................................................................................................... 325.3.1 Rejestracja/logowanie ................................................................................................................... 325.3.2 Generator Wniosków Aplikacyjnych ............................................................................................. 325.3.3 Generator Wniosków Płatniczych ................................................................................................. 345.3.4 „Moje wnioski” ............................................................................................................................. 345.3.5 Pomoc ............................................................................................................................................ 38

5.4 MODUŁ REALIZACJI PROJEKTÓW ......................................................................................................... 405.4.1 Umowy i aneksy ............................................................................................................................. 405.4.2 Wnioski o płatność ........................................................................................................................ 41

5.5 MODUŁ KONTROLI I EWIDENCJI NIEPRAWIDŁOWOŚCI ......................................................................... 44


Strona 3 z 56

5.5.1 Wymagania funkcjonalne .............................................................................................................. 445.5.2 Wymagania funkcjonalne – wydruki ............................................................................................. 455.5.3 Ewidencja nieprawidłowości - wymagania funkcjonalne .............................................................. 45

5.6 MODUŁ ADMINISTRACYJNY ................................................................................................................ 465.6.1 Modelowanie procesów ................................................................................................................. 465.6.2 Konfiguracja i zarządzanie ........................................................................................................... 46

5.7 OBECNY SYSTEM LSI .......................................................................................................................... 475.8 SPRAWOZDAWCZOŚĆ I RAPORTY ........................................................................................................ 47

6 INTEGRACJA DANYCH ........................................................................................................................ 47

6.1 INTEGRACJA Z SYSTEMEM KSI (SIMIK 07-13) ................................................................................... 486.2 INTEGRACJA Z SYSTEMEM CMS WEB.GOV.PL I EXTRANETEM ............................................................ 486.3 INTEGRACJA Z INNYMI ŹRÓDŁAMI DANYCH ........................................................................................ 48

7 TESTY FUNKCJONALNOŚCI I ODBIÓR SYSTEMU ....................................................................... 48

7.1 SPECYFIKACJA TESTÓW ...................................................................................................................... 487.2 ODBIÓR PRZEDMIOTU ZAMÓWIENIA .................................................................................................... 51

8 MIGRACJA DANYCH Z DOTYCHCZASOWYCH SYSTEMÓW BAZODANOWYCH ............... 51

9 UWARUNKOWANIA BUDOWY SYSTEMU ....................................................................................... 51

9.1 UWARUNKOWANIA PRAWNO – ORGANIZACYJNE ................................................................................ 519.1.1 Akty prawne ................................................................................................................................... 519.1.2 Regulaminy działania 8.1 i 8.2 PO IG .......................................................................................... 539.1.3 Wymogi struktury organizacyjnej .................................................................................................. 539.1.4 Nowelizacje aktów prawnych ........................................................................................................ 539.1.5 Przeniesienie autorskich praw majątkowych ................................................................................ 53

9.2 UWARUNKOWANIA TECHNICZNE ........................................................................................................ 549.3 OBCIĄŻENIE SYSTEMU ........................................................................................................................ 559.4 ZWIĘKSZANIE WYDAJNOŚCI ................................................................................................................ 559.5 WYMAGANIA MODYFIKOWALNOŚCI ................................................................................................... 559.6 WYMAGANIA DOSTĘPNOŚCI ................................................................................................................ 56


Strona 4 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 5 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 6 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 7 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 harmonogramu i zasad organizacji przedsięwzięcia

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

19.08.2009 20.08.2009

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ń realizacji poszczególnych funkcjonalności LSI

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 8 z 56

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 wspólnego Audytu zintegrowanego systemu

W terminie 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 9 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 10 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

http://bip.parp.gov.pl/index/more/5700�





Strona 11 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 12 z 56

przesłania danych konieczne jest przepisanie treści z pliku graficznego (zazwyczaj losowo dobranych znaków bądź krótkiego wyrazu).

9. 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.

10. 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ł.

11. CSS - kaskadowe arkusze stylów (ang. Cascading Style Sheets). Język służący do opisu formy prezentacji (wyświetlania) strony WWW.

12. E-book - publikacja elektroniczna. Treść zapisana w formie elektronicznej, przeznaczona do odczytania za pomocą odpowiedniego oprogramowania zainstalowanego w urządzeniu komputerowym.

13. eDostępność – ogólne zasady kreowania systemów informatycznych dla użytkowników niepełnosprawnych spełniające wymogi WCAG 1.0.

14. 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.

15. 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.

16. Formularz - moduł wchodzący w skład strony internetowej z rubrykami do wypełnienia. 17. Funkcjonalność - funkcja, która zostanie zrealizowana w LSI, Extranecie, CMS za pomocą

danego modułu. 18. 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, 19. HTML - hipertekstowy język znaczników (ang. HyperText Markup Language). Język

wykorzystywany do tworzenia stron internetowych. 20. 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.

21. 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.

22. 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 13 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 14 z 56

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.

42. 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.

43. 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.

44. 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.

45. Specyfikacja Funkcjonalna Systemu - dokument opisujący szczegółowo planowane funkcje Systemu przygotowany przez Wykonawcę,

46. 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.

47. Superadministrator - użytkownik dysponujący najwyższymi uprawnieniami w Systemie. 48. 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.

49. 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

50. 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.

51. Umowa - umowa pomiędzy Zamawiającym a Wykonawcą, na podstawie której Wykonawca realizuje Projekt,

52. 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.

53. 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.

54. 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.

55. 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 15 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 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), Elementy graficzne Systemu winny spełniać wymagania: 1. System ma posiadać minimalistyczną, nieprzysłaniającą treści oprawę graficzną zgodną

z systemem identyfikacji wizualnej PARP1

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.

oraz dotychczas wdrożonym portalem.

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 16 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 17 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ści2

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/WAI-WEBCONTENT/

http://www.w3.org/TR/WAI-WEBCONTENT/�

http://www.w3.org/TR/WAI-WEBCONTENT/�


Strona 18 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 19 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.

http://developer.yahoo.com/ypatterns/pattern.php?pattern=calendar�


Strona 20 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 21 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 22 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 23 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 Statusy „Moje wnioski” Statusy RIF Statusy KSI brak statusu wniosek został złożony brak statusu brak statusu oceniany formalnie wniosek jest oceniany

formalnie oceniany formalnie brak statusu

wniosek jest niekompletny

wniosek jest niekompletny oceniany formalnie brak statusu

konfliktowy wniosek jest oceniany formalnie

konfliktowy brak statusu

potrzebne uzupełnienie do oceny formalnej

potrzebne uzupełnienie do oceny formalnej

oceniany formalnie brak statusu

pozytywny formalnie wniosek jest oceniany merytorycznie

pozytywny formalnie w trakcje oceny

negatywny formalnie wniosek został odrzucony z powodów formalnych

negatywny formalnie brak statusu

ocena formalna wniosku została oprotestowana

ocena formalna wniosku została oprotestowana

oceniany formalnie brak statusu

potrzebne wyjaśnienia do oceny merytorycznej

potrzebne wyjaśnienia do 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 zatwierdzony


Strona 24 z 56

nierekomendowany wniosek nie uzyskał pozytywnej oceny merytorycznej

nierekomendowany odrzucony

ocena merytoryczna wniosku została oprotestowana

ocena merytoryczna wniosku została oprotestowana

oceniany merytorycznie w trakcje oceny

wniosek został odrzucony (po proteście)

wniosek został odrzucony nierekomendowany odrzucony

potrzebne dokumenty do umowy

potrzebne dokumenty do umowy

umowa w przygotowaniu

zatwierdzony

gotowa umowa gotowa umowa gotowa umowa zatwierdzony rezygnacja z dofinansowania

rezygnacja z dofinansowania

rezygnacja z dofinansowania

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 umowa rozwiązana umowa rozwiązana zatwierdzony projekt zakończony projekt zakończony projekt zakończony 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 1. Ewidencjonowanie ogłaszanych konkursów. 2. Harmonogramowanie konkursów. 3. Rejestracja historii zamian danych konkursowych. 4. 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:

- osie priorytetowe, działania, poddziałania,


Strona 25 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.

5.2.2.1 Wymagania funkcjonalne 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 26 z 56

5.2.3.1 Wymagania funkcjonalne 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.

5.2.4.1 Wymagania funkcjonalne 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 27 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. System wyświetla wnioski do oceny dla zalogowanego pracownika Oddziału Oceny Projektów. 2. Ocena wykonywana jest sekwencyjnie przez osoby zadekretowane do oceny wniosku. 3. W przypadku rozbieżności decyduje ocena drugiej osoby (sprawdzającej). 4. Każdy z oceniających wprowadza ocenę TAK/NIE zgodnie z kartą oceny na formularzu

elektronicznym 5. Ocena negatywna pociąga za sobą konieczność wprowadzenia wyjaśnienia (przy ewentualnym

Użyciu edytowalnego słownika). 6. 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. 7. Wydruk formularza oceny z danymi beneficjenta oraz identyfikacją wniosku i danymi osób

oceniających. 8. 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 28 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 e-mailowego 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.

5.2.5.1 Wymagania funkcjonalne 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 29 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”

5.2.6.1 Wymagania funkcjonalne 1. Nadawanie wnioskom odpowiedniego statusu:

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

2. Do statusów można wprowadzać wyjaśnienia (przy ewentualnym użyciu edytowalnego słownika). 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. 5. 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).

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.

7. Personalizowana korespondencja seryjna do grup beneficjentów według co najmniej następujących kryteriów: • statusu wniosku, • osi priorytetowej, działania, poddziałania, • konkursu, • 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.).

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 30 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. Nadawanie wnioskom odpowiedniego statusu:

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

2. Do statusów można wprowadzać wyjaśnienia (przy ewentualnym użyciu edytowalnego słownika). 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 11. 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).


Strona 31 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.

5.2.8.1 Wymagania funkcjonalne 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,



Generowanie pisma z informacją o zatwierdzeniu wniosku do dofinansowania 7. Generowanie umowy z beneficjentem o dofinansowaniu realizacji projektu.


Strona 32 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.

5.3.1.1 Wymagania funkcjonalne 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.

https://bazy.parp.gov.pl/lsi1/8/�


Strona 33 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 34 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 35 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 e-mailem) 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 36 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 37 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 38 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 e-mailem. 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 39 z 56

zapewni możliwość prezentowania dodatkowych odnośników do wybranych treści informacyjnych Portalu.

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 40 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

1. Nadawanie wnioskom odpowiedniego statusu: 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

2. Do statusów można wprowadzać wyjaśnienia (przy ewentualnym użyciu edytowalnego słownika). 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.

13. 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.


Strona 41 z 56



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 1. Nadawanie wnioskom odpowiedniego statusu:

a. wniosek o rozwiązanie umowy b. umowa rozwiązana c. 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 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.

4. 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.

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ść

5.4.2.1 Wymagania funkcjonalne 1. Statusy wniosków o płatność:


Strona 42 z 56

a. zarejestrowany b. nadany numer KSI c. zweryfikowany przez RIF d. potrzebne uzupełnienie dokumentacji (dodatkowo informacja jakie uzupełnienie) e. 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

2. 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.

3. 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ę 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.

4. Sortowanie rozpatrywania wniosków według terminu realizacji danego zadania. 5. Generowanie ostrzeżeń odnośnie przekroczenia lub zbliżania się terminów wśród komunikatów

systemowych). 6. Personalizowana korespondencja seryjna do grup beneficjentów według co najmniej

następujących kryteriów: • statusu wniosku, • osi priorytetowej, działania, poddziałania, • konkursu, • ręcznego wyboru.


7. Raportowanie ze stanu zaawansowania rozpatrywania wniosków o płatność z funkcją automatycznego porównywania osiągniętych wskaźników z wyznaczonymi,

8. 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.

9. Generowanie raportów umów z przypadającymi dla danego miesiąca wnioskami o płatność. 10. Generowanie aktualnych harmonogramów projektów w celu monitowania zbliżających się

terminów o płatność. 11. 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 43 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 44 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 45 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. Wydruk harmonogramu kontroli na dany okres. 2. Wydruk arkusza pokontrolnego 3. Zestawienie skontrolowanych projektów. 4. Zestawienie projektów zaplanowanych do kontroli. 5. Zestawienie projektów nie objętych kontrolą 6. 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 ieprawidło wo ści w PLN i w Eu ro 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 46 z 56

3. Ewidencja nieprawidłowości zgłaszanych do Komisji Europejskiej (KE). 4. Ewidencja nieprawidłowości niepodlegających zgłoszeniu do Komisji Europejskiej. 5. Tworzenie Raportów o nieprawidłowościach – bieżących i kwartalnych. 6. 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 47 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

2. Architektura danych musi, poprzez stworzenie znormalizowanych tablic danych, pozwalać na eksport danych do Microsoft Access oraz translację do definiowalnych raportów.

(SIMIK 07-13) – Krajowy System Informatyczny, omówionymi w rozdziale 6.

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.)

3 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”.

http://www.mf.gov.pl/�


Strona 48 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 49 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 50 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 51 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 z dotychczasowych systemów bazodanowych

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 52 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 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),

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 53 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 54 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 55 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 – przez uruchomienie kilku instancji Systemu na odrębnych serwerach.

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 56 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).

zakres zadań wykonawcy - web.gov.pl · p) przeprowadzi na podstawie uprzednio zaakceptowanych...

Documents