Załącznik nr 5 do SIWZ Szczegółowy Opis Przedmiotu Zamówienia (SOPZ) O p i s p r z e d m i o t u z a m ó w i e n i a n a :

Transkrypt

1 Załącznik nr 5 do SIWZ Szczegółowy Opis Przedmiotu Zamówienia (SOPZ) O p i s p r z e d m i o t u z a m ó w i e n i a n a : System informatyczny do przyjmowania i rozpatrywania wniosków w Ministerstwie Sportu i Turystyki

2 Spis treści I. Wprowadzenie 41 II. Słownik uŝywanych wyrazów 42 III. Ogólne informacje o projekcie 44 IV. Opis procesu przyjmowania wniosków 45 V. Wymagania funkcjonalne SI 48 VI. Wymagania ogólne 57 VII. Wymagania niefunkcjonalne 62 VIII. Lista obowiązujących przepisów prawnych, rozporządzeń i zarządzeń 64

3 1.Wprowadzenie W Ministerstwie Sportu i Turystyki istnieje kilka departamentów podzielonych ze względu na pełnione funkcje : 1. Departament Ekonomiczno-Finansowy 2. Departament Infrastruktury Sportowej 3. Departament Kształcenia i Doskonalenia Zawodowego 4. Departament Prawno-Kontrolny 5. Departament Sportu Kwalifikowanego i MłodzieŜowego 5.1 Sport Kwalifikowany 5.2 Sport MłodzieŜowy 6. Departament Sportu Powszechnego 6.1 Sport powszechny 6.2 Sport osób niepełnosprawnych 7. Departament Turystyki 8. Departament Współpracy Międzynarodowej Niniejsza specyfikacja w szczególności dotyczy Departamentu Infrastruktury Sportowej w dalszej części dokumentu oznaczony jako DIS, Departamentu Sportu Kwalifikowanego i MłodzieŜowego w dalszej części jako DSKiM, Departamentu Sportu Powszechnego w dalszej części jako DSP. Dane departamenty są między innymi odpowiedzialne za przeprowadzanie Otwartych Konkursów ofert lub wniosków dalej zwanych konkursami w celu zlecania realizacji zadań publicznych oraz przyjmowanie wniosków w określonych programach. Realizacja konkursów odbywa się w ramach ustalonego zakresu działań lub programu, w wyniku czego departamenty odpowiedzialne są równieŝ za rozpatrywanie wpływających do Ministerstwa Sportu i Turystyki wniosków i ofert.

4 II. Słownik uŝywanych wyrazów UŜyty skrót Opis MSiT Ministerstwo Sportu i Turystyki DIS Departament Infrastruktury Sportowej DSP Departament Sportu Powszechnego DSKiM Departament Sportu Kwalifikowanego i MłodzieŜowego DEF Departament Ekonomiczno-Finansowy Minister W danym dokumencie, jeŝeli nie podano inaczej określa Ministra Ministerstwa Sportu i Turystyki Podmiot Jako podmiot określa się organizacje pozarządowe wyszczególnione w ustawie o działalności poŝytku publicznego i wolontariacie, jednostki samorządu terytorialnego oraz Centralny Ośrodek Sportu, polskie związki sportowe, ogólnokrajowe stowarzyszenia lub związki stowarzyszenia w zakresie kultury fizycznej i sportu kwalifikowanego, akademie wychowania fizycznego lub inne szkoły wyŝsze, jednostki samorządu terytorialnego prowadzące szkołę mistrzostwa sportowego o strategicznym znaczeniu dla sportu SIWZ Specyfikacja Istotnych Warunków Zamówienia Drag and drop Przeciągnij i upuść (ang. drag and drop) pojęcie określa udogodnienie związane z tworzeniem np. formularzy za pomocą przeciągania elementów z menu obiektów w odpowiedni obszar i upuszczenie je w tym miejscu gdzie chcemy umieścić dany element.

5 UŜyty skrót Opis Use Case Przypadki UŜycia FRKF Fundusz Rozwoju Kultury Fizycznej Maska Maska wprowadzania jest uŝywana do formatowania danych i sterowania tym, jakie wartości mogą być wprowadzane. Maska wprowadzania składa się ze znaków literowych oraz znaków specjalnych określających rodzaj wartości, które mogą zostać wprowadzone w pustym miejscu. Maski wprowadzania są uŝywane głównie w polach tekstowych i w polach typu Data/Godzina, ale mogą być uŝywane równieŝ w polach typu Liczba i Waluta. Wniosek Dla uproszczenia w dokumenecie przyjęto nazywać wnioskiem: wnioski, zgłoszenia, oferty

6 III. Ogólne informacja o projekcie Przedmiotem niniejszego zamówienia jest zaprojektowanie, wykonanie, wdroŝenie i utrzymanie na serwerach zewnętrznych (w okresie wynikającym z informacji podanych w Ofercie - min. 12 miesięcy) Systemu Informatycznego wspierającego Ministerstwo Sportu i Turystyki w przyjmowaniu i rozpatrywaniu składanych ofert i wniosków oraz rozliczaniu zawartych umów. System Informatyczny (SI) ma zapewnić; kontrole, monitoring i sprawozdawczość nad procesami od momentu złoŝenia wniosku przez podmiot drogą elektroniczną, poprzez etapy oceny złoŝonych wniosków po stronie MSiT wraz z procedurą zmian wnioskowanych kwot, podpisania umowy o dofinansowanie z moŝliwością zawierania aneksów do umowy, obsługi składanych wniosków o uruchomienie środków, prowadzenie kontroli jego realizacji, przyjmowaniu kosztorysów lub zbiorczych zestawień kosztów aŝ po zakończenie realizacji projektu i sporządzenie rozliczenia umowy, raportów z osiągniętych efektów, zbiorczych raportów oraz danych do rocznych statystyk. Wsparcie dla Zamawiającego, w zakresie pomocy dla uŝytkowników w korzystaniu z systemu, dokonywania zmian w konfiguracji systemu, implementacji i wdraŝania nowych funkcjonalności, nieobjętych SIWZ w czasie objętym gwarancją. Przeprowadzenie szkoleń dla uŝytkowników.

7 IV. Opis procesu przyjmowania wniosków W Ministerstwie obowiązują Wytyczne przyznawania i rozliczania dotacji na dofinansowanie lub sfinansowanie zadań publicznych z zakresu kultury fizycznej i sportu w Ministerstwie Sportu i Turystyki. Wedle tych wytycznych oraz sposobu organizacji przyjmowania pism do MSiT w procesie przetwarzania wniosków po stronie MSiT moŝna wyróŝnić następujące kroki: 1. Opis słowny 1.1 Przyjęcie wniosków w kancelarii głównej MSiT. 1.2 Przekazanie wniosków do sekretariatów w danych departamentach. 1.3 Rozdysponowanie wniosków na pracowników merytorycznych wchodzących w skład powołanego zespołu konkursowego/zespołu do spraw opiniowania wniosków. 1.4 Ocena formalno-merytoryczna złoŝonych dokumentów, przez członka zespołu na dowód czego sporządzany jest jednostkowy Protokół Oceny określony przez zarządzenie. Przy ocenie oferty lub wniosku członek zespołu kieruje się określonymi w Regulaminie Pracy Zespołu kryteriami. W części departamentach przyznawane są wartości punktowe wedle których wniosek zostaje ropatrzony pozytywnie lub negatywnie. 1.5 Ustalany jest termin posiedzenia zespołu konkursowego/zespołu do spraw opiniowania wniosków. Na posiedzeniu zespół ustala wysokość sfinansowania lub dofinansowania zadania publicznego, uwzględniając ówczesną analizę dokonaną w jednostkowym Protokole Ocen oraz kwotę wnioskowaną we wniosku. Rodzaj podjętego rozstrzygnięcia dopisywany jest w jednostkowym Protokole Ocen oraz zostaje sporządzany zbiorczy Protokół Ocen zawierający wykaz podmiotów, których oferty lub wnioski zostały ocenione pozytywnie, negatywnie lub zostały odrzucone. 1.6 Podpisany przez wszystkich członków zespołu konkursowego/zespołu do spraw opiniowania wniosków zbiorczy Protokół Ocen zostaje przekazany do DEF w celu potwierdzenia posiadanych środków finansowych a następnie zostaje przekazany do Ministra do zatwierdzenia. 1.7 Informacje o dacie i rodzaju rozstrzygnięcia przez Ministra zamieszcza się w zbiorczym Protokole Ocen. 1.8 Kopia zatwierdzonego Protokółu Zbiorczego zostaje przekazana do Departamentu Ekonomiczno- Finansowego. 1.9 MoŜe nastąpić uniewaŝnienie konkursu, jeŝeli nie złoŝono Ŝadnej oferty, wniosku lub Ŝadne ze złoŝonych ofert, wniosków nie spełnia wymogów zawartych w ogłoszeniu konkursu Wyniki konkursu podawane są do publicznej wiadomości zgodnie z zarządzeniem Po ogłoszeniu wyników zostaje wysłana informacja o wstępnym przyznaniu dotacji do podmiotów, które zostały wyłonione i zostaje przygotowany projekt umowy dla tych podmiotów. W przypadku, gdy została przyznana niŝsza kwota niŝ wnioskowana, w zaleŝności od departamentu podmiot jest zobowiązany do złoŝenia aktualizacji wniosku wraz z niezbędnymi załącznikami do podpisania umowy. Niedokonanie aktualizacji w określonym terminie stanowi podstawę do anulowania przyznanej dotacji. W przypadku przyznania dotacji o takiej samej kwocie jak wnioskowana, załącznikiem umowy są dokumenty będące składnikiem rozpatrywanego wniosku

8 1.12 W niektórych realizowanych programach, wnioskodawca musi zloŝyć dodatkowo wniosek o uruchomienie środków, który jest rozpatrywany na podstawie dołączonych sprawozdań, informacji uzupełniających, protokołów odbioru i faktur. Wnioskodawca moŝe wielokrotnie złoŝyć wniosek o uruchomienie środków Kolejnym etapem jest rozliczenie pod względem merytorycznym i finansowym. Rozliczenia dotacji celowej prowadzi departament w trybie i na zasadach określonych w zarządzeniu Dyrektora Generalnego Ministerstwa, wprowadzającego wytyczne w sprawie postępowania przy rozliczeniu dotacji celowych. Potwierdzenie wykonania i rozliczenia zadania dokonywane jest przez pracownika departamentu na Karcie Rozliczenia Sporządzoną i podpisana Kartę Rozliczeń w trzech egzemplarzach pracownik przekazuje dyrektorowi departamentu do akceptacji Jeden z egzemplarzy Karty Rozliczeń po akceptacji zostaje przekazany do Departamentu Ekonomiczno-Finansowego Departament informuje podmiot o przyjęciu bądź odrzuceniu sprawozdania lub rozliczenia. Przyjęcie sprawozdania lub rozliczenia końcowego jest równowaŝne z rozliczeniem dotacji. Podmiot w przypadku zaistniałych okoliczności, które są niezaleŝne od podmiotu a które uniemoŝliwiają złoŝenie sprawozdania lub rozliczenia w określonym w umowie terminie, moŝe zwrócić się do Ministra o przedłuŝenie terminu, przy czym termin ten nie moŝe być dłuŝszy od ustalonego limitu czasowego dla danego programu.

9 2. Opis graficzny

10 V. Wymagania funkcjonalne SI 1. Opis ogólny System Informatyczny powinien składać się z 3 głównych modułów szczegółowo opisanych w dalszej części dokumentu. Pierwszy moduł pozwalający po zalogowaniu podmiotu do SI składać wnioski na wybrany konkurs lub program z wybranego departamentu, pobieranie umowy i aneksów, składanie wniosków o uruchomienie środków oraz składanie rozliczeń. Drugi moduł dla pracowników MSiT wspierający cały proces przetwarzania wniosków i ofert, oraz trzeci najbardziej rozbudowany moduł administracyjny, pozwalający na zarządzanie pozostałymi modułami. Ze względu na specyfikę pracy MSiT, które jest zobligowane do przestrzegania ustaw, rozporządzeń i zarządzeń przy ogłaszaniu, rozpatrywaniu i rozliczaniu konkursów/programów naleŝy uwzględnić, Ŝe formularze w ofertach i wnioskach jak i dołączane załączniki maja charakter zmienny i system musi umoŝliwić z panelu administracyjnego wprowadzanie nowych wniosków oraz zmian w juŝ istniejących na zasadzie drag and drop. 2. UŜytkownicy systemu Wyszczególnieni uŝytkownicy systemu: a) Podmiot konto główne - PKG b) Podmiot subkonto - PS c) Pracownik Merytoryczny - PM d) Naczelnik e) Dyrektor f) Moderator g) Administrator 3. Opis uprawnień 3.1 Moduł Podmiot PKG musi posiadać uprawnienia do rejestracji w systemie SI oraz do logowania do modułu dla niego przeznaczonego. Po zalogowaniu PKG powinien mieć moŝliwość złoŝenia wniosku w wybranym konkursie lub programie oraz wprowadzeniu potrzebnych do tego dokumentów w tej chwili udostępnianych jako załączniki na stronie Podczas rejestracji wyznaczony pracownik MSiT musi zweryfikować konta PKG i dopiero po akceptacji rejestracji podmiot będzie mógł się logować do systemu. PKG powinien mieć moŝliwość edycji swoich danych w profilu. Z poziomu swojego profilu PKG powinien mieć moŝliwość wprowadzania subkont - PS i nadanie im uprawnień do: zgłaszania nowych wniosków, do przeglądania złoŝonych wniosków przez innych PS oraz do ich edycji. SI powinien umoŝliwić ustawienie stałego IP w profilu do autentykacji dla danego konta. PS nie ma uprawnienia do edycji profilu PKG. W profilu PS moŝe tylko zmienić swoje hasło. PKG powinien widzieć wszystkie przez siebie jak i PS złoŝone wnioski, natomiast PS powinien domyślnie widzieć tylko swoje wnioski o ile nie zostały mu nadane inne uprawnienia przez PKG.

11 3.2 Moduł Pracownik PM powinien mieć uprawnienia do logowania do systemu i zmiany w swoim profilu swojego hasła. PM powinien domyślnie widzieć wszystkie wnioski, które zostały mu przydzielone przez Naczelnika lub Dyrektora danego departamentu. Dyrektor moŝe nadać uprawnienia PM do przeglądania wszystkich wniosków w danym departamencie. Edycja powinna być moŝliwa tylko dla tego PM, któremu został przydzielony wniosek. W niektórych departamentach PM powinien mieć moŝliwość przekazania wniosku do drugiego PM. W niektórych departamentach jest potrzeba wprowadzenia uŝytkownika Naczelnik, który jest odpowiedzialny za przydzielenie do odpowiedniego PM wpływających wniosków do departamentu oraz ewentualne odebranie wniosku z konta PM w swoim departamencie. Poza tymi uprawnieniami dziedziczy wszystkie uprawnienia po PM. Dyrektor dziedziczy wszystkie uprawnienia po Naczelniku i PM oraz posiada uprawnienia do wprowadzenia do systemu Komisji Konkursowej lub Zespołu do spraw opiniowania wniosków, wybierając w tym celu z listy swoich PM z departamentu określoną ilość osób i przydzielenie ich do wybranego Konkursu/Programu realizowanego przez dany departament. Dyrektor powinien mieć moŝliwość przydzielenia swoim PM uprawnień do sporządzania określonych raportów i statystyk dla całego departamentu oraz do przekazywania i odbierania wniosków z kont PM. 3.3 Moduł Administrator Moderator powinien mieć dostęp do modułów w panelu administracyjnym do dodawania konkursów/programów, formularzy wniosków, formularzy ocen oraz formularzy statystyk i raportów. Administrator dziedziczy wszystkie uprawnienia po Moderatorze oraz powinien mieć moŝliwość dodawania UŜytkowników do panelu pracownika i administratora oraz nadania im odpowiednich uprawnień. Administrator powinien mieć moŝliwość zmiany logo dla panelu SI. 4. Moduły SI 4.1 Opis modułu podmiot: Moduł dla podmiotu musi być dostępny poprzez logowanie do systemu. JeŜeli dany podmiot nie ma jeszcze załoŝonego konta, musi mieć moŝliwość zarejestrowania się w SI. Dane tego podmiotu muszą być zweryfikowane, podczas rejestracji przez wyznaczoną osobę w ministerstwie. Po zalogowaniu na konto powinno być dostępne proste w uŝyciu menu pozwalające przechodzić między kategoriami : -Aktualności, -Konkursy/Programy, -Wniosek, -Umowa, -Rozliczenie, -Profil.

12 W kategorii Aktualności powinna być widoczna lista wiadomości wysłanych przez pracowników MSiT i monity, krótka lista najszybciej kończących się konkursów oraz lista dziesięciu najnowszych złoŝonych juŝ wniosków wraz z ich statusem. Kategoria Aktualności powinna pozwolić podmiotowy na szybką orientację w bieŝących sprawach dotyczących konta i składanych wniosków. W zaleŝności od uprawnień powinny być widoczne albo wnioski tylko danego PS albo wnioski złoŝone przez wszystkich PS przypisanych do danego podmiotu. Podmiot nie moŝe wysyłać wiadomości do MSiT poprzez SI. W kategorii Konkursy/Programy musi być prosty sposób nawigacji między dostępnymi konkursami/programami departamentów DIS, DSKiM oraz DSP oraz szczegółowy podgląd do juŝ złoŝonych wniosków i ich status, informacje o umowie i aneksach - czy została udostępniona, pobrana, o rozliczeniu czy zostało złoŝone - jeśli nie to ile czasu pozostało do końca terminu i ewentualne monity. Po wybraniu departamentu powinna pokazywać się lista z aktualnymi konkursami/programami- nazwa, opis, data zakończenia. Po wybraniu jednego z nich powinien uaktywnić się formularz danego wniosku do wypełnienia. PoniewaŜ formularze zgłoszeniowe zawierają duŝą ilość pól, SI musi zapewnić częściowe wypełnienie pól automatycznie z dostępnych danych podanych podczas rejestracji, moŝliwość zapisania wersji roboczej dostępnej po zapisaniu w kategorii wniosek ze statusem wersja robocza. SI musi kontrolować poprawność danych i uniemoŝliwić złoŝenie wniosku w przypadku nie wypełnienia wszystkich obowiązkowych pól. Na stronie internetowej MSiT do kaŝdego wniosku dołączone są pliki do pobrania. W zaleŝności od Konkursu/Programu zawierają one kosztorysy lub zbiorcze zestawienie kosztów, harmonogramy, preliminarze. System musi umoŝliwić wybór sposobu wprowadzania danych z wyŝej wymienionych plików, między wpisywaniem danych na stronie do formatek lub wypełnieniu pobranych na dzień dzisiejszy plików Excel i zaczytaniu ich do SI. Gdy podmiot wypełni wszystkie wymagane pola i załączniki moŝe złoŝyć wniosek do Konkursu/Programu. Dodatkowo SI powinien pozwolić podmiotowi na załączenie własnych zeskanowanych dokumentów. Po wciśnięciu przycisku złóŝ wniosek następuję: wygenerowanie numeru dla danego dokumentu, zostaje on zablokowany uniemoŝliwiając wprowadzania zmian przez podmiot, otwiera się plik pdf do druku, który podmiot musi wysłać pocztą do MSiT. ZłoŜony wniosek trafia do puli dokumentów danego departamentu, gdzie następnie jest przydzielany do odpowiedniego PM. Status złoŝonego wniosku zmienia się z wersja robocza na -Oczekujący, jeŝeli jeszcze nie został sprawdzony przez PM, -W realizacji, kiedy jest w ocenie jednostkowej, -Odrzucony, jeśli nie spełnił odpowiednich wymagań, -Zaakceptowany, kiedy spełnił wszystkie kryteria i moŝe nastąpić podpisanie umowy, -Rozliczony, kiedy zostało przyjęte rozliczenie. W kategorii Wniosek podmiot moŝe zobaczyć wszystkie swoje wnioski oraz ich status. Wnioski o statusie wersja robocza lub oczekujący mogą być edytowane w przypadku zmiany statusu przez PM na inny, wniosek powinien być dla podmiotu zablokowany przed edycją. Kiedy MSiT rozpatrzy dany dokument pozytywnie w kategorii umowa, wyświetli się link z dokumentem do pobrania, podpisania i wysłania pocztą do MSiT. JeŜeli dokument został rozpatrzony pozytywnie ale na inną kwotę, w niektórych departamentach PM wysyła wiadomość do podmiotu, Ŝe naleŝy poprawić wniosek i wysłać ponownie do MSiT i dopiero wtedy jest generowana umowa. W przypadku sporządzenia aneksu przez MSiT, ten

13 równieŝ powinnien być udostepniony w SI dla podmiotu. W ustalonej formie przez rozporządzenia i zarządzenia oraz w określonym czasie wpisanym do umowy, podmiot musi złoŝyć rozliczenie. W kategorii Rozliczenie podmiot powinien mieć moŝliwość złoŝenia rozliczenia do wyboru przez pobranie odpowiednich plików Excel, CSV lub wpisaniu do formatek do wybranej uprzednio z listy umowy. Następnie SI musi umoŝliwić zaczytanie danych plików do bazy oraz wyświetlać je po wybraniu danego rozliczenia z listy. W kategorii Profil uŝytkownik PKG powinien mieć moŝliwość: Edycji własnych danych typu adres, numer telefonu, NIP, zmiany hasła, i inne zidentyfikowane podczas etapu analizy ujętej w harmonogramie. KaŜdą zmianę na koncie PKG (typu hasło, dane teleadresowe podmiotu) musi potwierdzić administrator. Dodanie kont PS i nadanie im uprawnień; do składania wniosków, tylko do oglądania wniosków w SI, pobierania dokumentów z SI, dostęp tylko do swoich wniosków czy teŝ do innych wniosków składanych przez PS danego PKG, ustawianie automatycznego wysyłania powiadomień na podany w profilu adres mailowy, kiedy MSiT wyśle wiadomość lub monit. Moduł podmiot Znak Wykaz Uwagi MPO-1 Logowanie do systemu TAK / NIE MPO-2 Rejestracja nowego podmiotu TAK / NIE MPO-3 Konto główne TAK / NIE MPO-4 Subkonto TAK / NIE MPO-5 Aktualności TAK / NIE MPO-6 Konkursy/Programy TAK / NIE MPO-7 Wniosek TAK / NIE MPO-8 Wersja robocza TAK / NIE MPO-9 Powiadomienia na maila TAK / NIE

14 Znak Wykaz Uwagi MPO-10 Umowa TAK / NIE MPO-11 Rozliczenie TAK / NIE MPO-12 Weryfikacja poprawności danych TAK / NIE MPO-13 Numeracja automatyczna TAK / NIE MPO-14 Wniosek o uruchomienie środków TAK / NIE 4.2 Opis modułu pracownik: Moduł pracownik musi być dostępny poprzez logowanie do systemu [po SSL]. W odróŝnieniu od kont PKG i PS pracownicy nie mogą sami się zarejestrować w SI. Pracowników do systemu powinien dodawać administrator lub moderator. Po zalogowaniu PM do systemu powinno być widoczne intuicyjne menu: -Wiadomości, -Wnioski, -Ocena, -Umowa, -Transze, -Rozliczenie, -Statystyki i raporty. W kategorii Wiadomości PM powinien widzieć najstarsze wnioski ze statusem oczekującym, które moŝe zaakceptować co powinno przenieść dany wniosek do kategorii Wnioski na danym koncie PM. PM w kategorii Wiadomości powinien teŝ widzieć monity, które system wysyła w celu informowania PM, Ŝe danym podmiotą mija termin dostarczenia poprawek, umowy, rozliczeń oraz umoŝliwić wysłanie podmiotowi wiadomości w systemie, która automatycznie powinna być wysłana na adres mailowy podany w profilu danego podmiotu. W kategorii Wnioski powinny być widoczne wszystkie jeszcze nie ocenione i nie rozliczone wnioski oraz ich status. SI musi pozwolić na wprowadzenie nowego wniosku do systemu w przypadku kiedy podmiot swoje dokumenty złoŝył tylko poprzez pocztę. W kategorii Ocena PM powinien móc dodać nową ocenę formalno-merytoryczną, ekonomiczną lub merytoryczno-techniczną do wniosku na określonym formularzu zgodnie z rozporządzeniami i zarządzeniami dotyczącego danego konkursu/programu. Po zapisaniu oceny PM musi mieć moŝliwość wygenerowania raportu poprzez zaznaczenie tych ocen, które chce na nim umieścić. Dodatkowo do Oceny zbiorowej mogą być wymagane dodatkowe dane podmiotów, w związku z tym naleŝy umoŝliwić wybranie i wyeksportowanie do plików Excel, Word, PDF, CSV, XML, PDF odpowiedniego zestawienia. W niektórych departamentach istnieje potrzeba przekazywania między PM wniosków do wykonania kompletnej oceny.

15 Ocenę zbiorową wprowadza do SI wydelegowany przez dyrektora departamentu PM. Po przyznaniu danemu podmiotowi na wybrany konkurs/pogram środków finansowych musi być moŝliwość wygenerowania umowy. W kategorii Umowa musi być moŝliwość wygenerowania nowej umowy oraz wygenerowanie powiadomienia do podmiotu o przyznaniu środków i ewentualnych poprawkach do naniesienia. W tym celu PM mógłby odblokować złoŝony wniosek na czas określony a procedura po stronie podmiotu jest taka sama jak przy składaniu wniosku przy czym wniosek jest zapisany jako kolejna wersja i PM powinien mieć moŝliwość wglądu do wniosku pierwszego jak i drugiego. Po naniesieniu poprawek i naciśnięciu złóŝ wniosek powinno pokazać się okienko z dokumentem do wydruku i nastąpi ponowna blokada formularza. W niektórych konkursach/programach istnieje potrzeba podczas generowania umowy wprowadzenia transz i dat wypłacania określonych kwot, które powinny automatycznie być widoczne w kategorii Transze. Po wygenerowaniu umowy SI powinien umoŝliwić eksport paczek (format: XML/XQuery, XML Schema, XSLT) z danymi, związanymi z rejestracją umów do istniejącego systemu finansowego MSiT. Natomiast system finansowy MSiT udostępni dane o zrealizowanych płatnościach zgodnie z podpisanymi umowami do zaimportowania w formacie XLS, XML do SI. Szczegóły dotyczące wymaganych pól oraz zakresu ostatecznej funkcjonalności zostaną określone na etapie analizy i tworzenia dokumentacji projektowej. W tym miejscu PM powinien mieć teŝ moŝliwość wysłania monitów do PKG i PS. Poprzez wysłanie rozumie się zarówno pojawianie się informacji na danym koncie PS i PKG o monicie jak i automatyczne wysłanie powiadomienia drogą mailową na podany adres mailowy w profilu. Powinna istnieć moŝliwość ustawienia automatycznego wysyłania monitów do wielu UŜytkowników. Podczas generowania umowy poszczególne pola powinny się automatycznie wypełniać danymi danego podmiotu oraz danymi z wprowadzonego wniosku. Umowy ze względu na charakter pracy MSiT mogą się zmieniać, naleŝy uwzględnić sposób dodawania nowego szablonu umowy do SI przez Dyrektora lub uprawnioną do tego osobę w departamencie. W niektórych przypadkach istnieje konieczność zmiany podanych terminów i wysokości transz. W kategorii Umowa musi być moŝliwość sporządzenia aneksu do istniejącej juŝ umowy. Kiedy zostanie uruchomione tworzenie aneksu do wybranej umowy PM powinien mieć moŝliwość wybrania tych pól z umowy, które muszą ulec zmianie i powinien mieć moŝliwość dodania opisu uzasadniającego zmiany. Kategoria Transza jest dla poszczególnych konkursów opcjonalna. JeŜeli w czasie generowania umowy zostały dodane transze to w tym miejscu musi pokazać się zestawienie podmiotów oraz transz do wypłacenia w danym miesiącu o ile dany podmiot spełnił wszystkie wymogi. Takie zestawienie co miesiąc musi być wygenerowane i wydrukowane, a następnie zostaje przekazane do DEF. W kategorii Rozliczenie muszą być dostępne złoŝone rozliczenia podmiotów do sprawdzenia. PM po weryfikacji moŝe zaakceptować rozliczenie lub nie. JeŜeli rozliczenie zostało zaakceptowane to powinien być dostępny formularz zgodny z wymogami rozporządzeń i zarządzeń obowiązujących w MSiT, w którym powinny automatycznie uzupełniać się i przeliczać kwoty podane przez podmiot w rozliczeniu. NaleŜy uwzględnić moŝliwość składania rozliczeń częściowych np. na etapy półrocze w zaleŝności od Konkursu/Programu. W kategorii Statystyki i raporty dany PM powinien mieć moŝliwość wygenerowania i wyeksportowania dowolnego zestawienia dotyczącego całego przebiegu rozpatrywania wniosków dla podmiotu, konkursu/programu, który został mu przydzielony. SI powinien udostępniać moŝliwość zapisania szablonu raportu aby PM nie deklarował za kaŝdym razem od nowa kryteriów wyboru. Wygenerowane zestawienia

16 powinny mieć moŝliwość eksportu do plików Excel, Word, PDF, CSV i XML. Dodatkowo Naczelnik i Dyrektor powinni mieć moŝliwość tworzenia raportów i statystyk dla całego departamentu z podziałem na PM. NaleŜy uwzględnić dostęp do danych skompresowanych, opisanych w Części VI pkt.12 w dalszej części specyfikacji. Kategoria PM powinna być dostępna tylko dla dyrektorów departamentu. W tym miejscu dyrektor powinien przydzielać swoich PM do danego konkursu/programu i nadawać im uprawnienia oraz wprowadzać z listy PM skład komisji/zespołu wybrany do danego konkursu/programu. We wszystkich kategoriach powinien być zaimplementowany prosty sposób wyszukania danego dokumentu czy podmiotu poprzez wybranie odpowiedniego parametru z listy np. po nazwie podmiotu, nip i innych dostępnych danych. Dodatkowo w miejscach gdzie widoczne są listy, tabele lub w szczegółowym podglądzie dokumentu powinna być moŝliwość wyeksportowania do plików: Excel, CSV, XML, PDF, DOC, DOCX jak i sortowanie po nazwach w nagłówkach. Dodatkowo dla UŜytkowników Naczelnik i Dyrektor musi istnieć moŝliwość przydzielenia i odbierania wniosku od i do danego PM. Moduł dla pracownika MSiT Znak Wykaz Uwagi MPR-1 Logowanie Pracownika do systemu TAK / NIE MPR-2 Wiadomości i monity TAK / NIE MPR-3 Pula wniosków TAK / NIE MPR-4 Wysyłanie wiadomości TAK / NIE MPR-5 Wnioski TAK / NIE MPR-6 Ocena TAK / NIE MPR-7 Umowa TAK / NIE MPR-8 Generowanie dokumentów TAK / NIE MPR-9 Rozliczenie TAK / NIE MPR-10 Transze TAK / NIE MPR-11 Statystyka i raporty TAK / NIE

17 Znak Wykaz Uwagi MPR-12 Eksport danych do PDF, xls, xml, cvs, Excel, Word TAK / NIE MPR-13 Nadanie uprawnień TAK / NIE MPR-14 Wybór komisji/zespołu TAK / NIE MPR-15 Przypisanie do konkursu/programu TAK / NIE MPR-16 Sortowanie TAK / NIE MPR-17 Wyszukiwarka TAK / NIE 4.3 Opis modułu administratora Panel administratora musi być dostępny poprzez logowanie. UŜytkownik administrator musi być wcześniej zdefiniowany i dodany do bazy danych. Po zalogowaniu musi być dostępne intuicyjne menu zawierające kategorie: -Dziennik zdarzeń -Zarządzanie kontami -Formularze -Raporty i Statystyki -Ustawienia W kategorii Dziennik zdarzeń system powinien pokazywać listę najnowszych zarejestrowanych zdarzeń oraz umoŝliwić wyszukanie i sortowanie po dacie, IP, podmiocie, uŝytkowniku, rodzaju zdarzenia. W kategorii Zarządzanie kontami administrator powinien mieć moŝliwość weryfikacji i zatwierdzania kont PKG, dodawania departamentów i ich dyrektorów, konkursów i programów oraz odpowiednich do nich monitów, UŜytkowników oraz ich uprawnień. W kategorii Formularze powinno znajdować się narzędzie do swobodnego tworzenia formularzy wniosków, ofert, ocen, rozliczeń i pozwalające przypisać je do odpowiednich konkursów/programów. Narzędzie powinno pozwalać w łatwy sposób wybrać potrzebne formatki oraz powiązanie ich z danymi z bazy danych w taki sposób aby mogły się podczas wypełniania uzupełnić juŝ istniejącymi danymi podmiotów. Podczas tworzenia nowych formatek naleŝy określić czy wypełnienie danego pola przez podmiot jest obowiązkowe czy moŝe zostać pominięte. Do tego narzędzia uprawnienia powinien mieć i administrator i moderator. W kategorii Raporty i Statystyki administrator i moderator powinien mieć moŝliwość tworzenia zestawień obejmujące wszystkie departamenty i wszystkie podmioty oraz eksportowanie uzyskanych danych do formatów PDF, xls, html, xml, csv, Excel, Word.

18 W kategorii Ustawienia administrator powinien mieć moŝliwość konfigurowania SI. Administrator powinien mieć moŝliwość ustawienie automatycznych wiadomości wysyłanych przez SI do UŜytkowników. NaleŜy uwzględnić potrzebę zmiany logo lub w przypadku uŝycia teŝ i bannera. Moduł dla administratora Znak Wykaz Uwagi MA-1 Logowanie do systemu TAK / NIE MA-2 Zarządzanie kontami TAK / NIE MA-3 Dziennik zdarzeń TAK / NIE MA-5 Formularze TAK / NIE MA-6 Raporty i Statystyki TAK / NIE MA-7 Zmiana logo/koloru TAK / NIE MA-8 Eksport danych TAK / NIE MA-9 Sortowanie TAK / NIE MA-10 Weryfikacja PKG TAK / NIE

19 VI. Wymagania ogólne 1. Dokumentacja 1.1 Dokumentacja projektowa Przed rozpoczęciem implementacji systemu, wykonawca przeprowadzi analizę w celu wyspecyfikowania funkcjonalności systemu. Na potrzeby wykonania analizy przez Wykonawcę, Zamawiający umoŝliwi prowadzenie spotkań analitycznych ze wskazanymi pracownikami Zamawiającego. W terminie podanym w SOPZ jest określony termin dostawy dokumentacji projektowej, która powinna zawierać model i opis przypadków uŝycia (Use case) w notacji UML, diagram stanów oraz opis zidentyfikowanych reguł biznesowych z uwzględnieniem tych sprawdzających poprawność wprowadzonych danych do SI i tych pól które SI ma automatycznie wypełniać. Dostarczona dokumentacja musi zostać zaakceptowana przez Zamawiającego. W terminie do 10 dni po zatwierdzeniu dokumentacji projektowej zamawiający sporządzi protokół odbioru etapu pierwszego, który zostanie podpisany przez Zamawiającego i Wykonawcę. 1.2 Dokumentacja Techniczna Na etapie wdroŝeń naleŝy dostarczyć szczegółową dokumentację techniczną zawierającą opis architektury systemu, wyszczególnione moduły, opis uŝytych technologii, standardów, bibliotek i platform programistycznych oraz opis uŝytych funkcji. 1.3 Dokumentacja uŝytkowa Na etapie szkoleń naleŝy dostarczyć dokumentację uŝytkową zawierającą wskazówki dla UŜytkowników poszczególnych modułów umoŝliwiające rozpoczęcie pracy w SI. Opcjonalnie, za zgodą Zamawiającego, mogą być dostarczone filmy instruktaŝowe. 2. Layout Wykonawca jest zobowiązany do przedstawienia w odpowiednim terminie 3 projektów układu stron dla kaŝdego modułu z których jeden zostanie wybrany. NaleŜy zadbać o to aby układ strony był przejrzysty i łatwy w uŝyciu. 3. Wyszukiwanie Dla kaŝdego rodzaju danych dostępnych w systemie, system musi umoŝliwiać wyszukiwanie: -pełnotekstowe -wg kluczowych własności, wyświetlanych w liście. 4. Dane historyczne Uzupełnienie systemu o dane historyczne z dostarczonych przez zamawiającego plików Excel. 5. Słowniki systemowe SI musi zawierać następujące słowniki: Rodzaj podmiotów, Dyscypliny sportowe, Rodzaje obiektów, Rodzaje sprzętu sportowego, słowniki zidentyfikowane podczas analizy wykonawcy. SI powinnien równieŝ posiadać moŝliwość dodawania nowych

20 słowników w panelu administracyjnym i umoŝliwić wykorzystanie słowników podczas tworzenia nowych formularzy. Dodatkowe słowniki uwzględniające export/import danych z SI do systemu finansowego MSiT (np. słownik budŝetu zadaniowego, źródła finansowania, kontrahentów, placówka zgodne z systemem finansowym MSiT). 6. Podpis elektroniczny Na dzień dzisiejszy SI nie będzie przyjmował wniosków wyłącznie drogą elektroniczną jednak system powinien mieć moŝliwość w przyszłości włączenia funkcji podpisu elektronicznego i obsługe certyfikatów kwalifikowanych. 7. Testy Na podstawie zatwierdzonego projektu funkcjonalnego systemu, wykonawca opracuje plan testów funkcjonalnych systemu, składający się ze scenariuszy testowych weryfikujących spełnienie wymagań funkcjonalnych. Wykonawca opracuje i przedstawi metodykę przeprowadzenia testów wydajnościowych. Metodyka ta powinna obejmować co najmniej wybór narzędzia do przeprowadzenia testów, scenariusz testów. Metodyka testów wydajnościowych będzie podlegała zatwierdzeniu przez Zamawiającego. Testy jednostkowe wykonawca zobowiązuję się prowadzić we własnym zakresie. Wykonawca zobowiązuję się do wykonania testów bezpieczeństwa i dostarczenia do MSiT raportu. 8. Bezpieczeństwo NaleŜy uwzględnić, Ŝe SI będzie systemem udostępnianym na zewnątrz w związku z tym naleŝy szczególnie zadbać o bezpieczeństwo przysyłanych i składowanych danych przez zastosowanie; SSL, uniemoŝliwienie przeprowadzenie znanych ataków internetowych np: SQLInjection, Cross Site Scripting. dostępu do systemu wyłącznie po zalogowaniu przy pomocy identyfikatora oraz hasła. Hasła uŝytkowników muszą być przechowywane w systemie w formie nie pozwalającej na ujawnienie hasła [algorytm SHA2], mechanizmów kontrolnych spójności danych, Zmiany hasła dla konta PKG zatwierdza administrator z panelu administracyjnego. Zamawiający zobowiązuje Wykonawcę do wykupienia certyfikatu SSL dla SI na czas objęty gwarancją. System musi rejestrować zdarzenia systemowe w zakresie pozwalającym na przypisanie odpowiedzialności uŝytkowników za wykonane operacje. Rejestrowane muszą być co najmniej następujące zdarzenia: błąd logowania uŝytkownika, zakładanie nowego konta PKG, zmiany hasła PKG i wszystkich UŜytkowników z MSiT. Rejestrowanie zdarzeń systemowych musi obejmować co najmniej następujące informacje: datę i godzinę operacji,

21 identyfikator uŝytkownika, IP uŝytkownika, kontekst zdarzenia. Dodatkowo w przypadku potrójnego błędnego wpisania hasła do systemu, SI musi zablokować dostęp dla danego IP i dla danego uŝytkownika na okres 3 dni do systemu. W przypadku zgłoszenia podmiotu do MSiT prośby o odblokowanie konta we wcześniejszym terminie Administrator powinien mieć moŝliwość odblokowania danego konta z modułu admin. Baza danych powinnia przechowywać dane zaszyfrowane. Wykonawca jest zobowiązany do ustalenia odpowiedniej polityki bezpieczeństwa i chronienie pomieszczeń przechowujących serwery przed dostępem nie powołanych osób fizycznych. 9. Szkolenie Wykonawca przeprowadzi następujące szkolenia: Szkolenie wszystkich grup uŝytkowników SI, obejmie sposób realizacji w systemie pełnego procesu rozpatrywania wniosków od momentu złoŝenia wniosku, poprzez etapy oceny, podpisania umowy, obsługi składanych wniosków o płatność, wysyłanie wiadomości i monitów, aŝ po zakończenie realizacji projektu i tworzenia raportów. Szkolenie Administratorów i Redaktorów, obejmujące administrację i konfigurację systemu oraz procesu budowania nowych formularzy. Jedna grupa szkoleniowa moŝe liczyć maksymalnie 10 osób. Łączna liczba uczestników szkolenia wynosi 80 osób. Szkolenia zostaną przeprowadzone w terminach uzgodnionych przez Wykonawcę z Zamawiającym, po podpisaniu przez strony Protokołu Odbioru Systemu. Wiedza UŜytkowników, zdobyta na szkoleniu zostanie zweryfikowana dowolną formą zaproponowaną przez Wykonawcę, którą potwierdzi pisemnie i przedstawi Zamawiającemu. Zamawiający zapewnia salę, rzutnik oraz ekran do prezentacji. Szkolenie odbędzie się w formie warsztatów, tj. kaŝdemu uŝytkownikowi Wykonawca zapewni materiały oraz komputer (bez dostępu do sieci internetowej). 10. Gwarancja i Wsparcie Wykonawca zapewni wsparcie dla Zamawiającego, obejmujące: 1) pomoc typu hot-line w korzystaniu z SI,

22 2) dokonywanie zmian w konfiguracji systemu (implementację i wdraŝanie zmian funkcjonalności objętych SIWZ) w okresie objętym umową od momentu podpisania końcowego Protokołu Odbioru Systemu, 3) implementację i wdraŝanie nowych funkcjonalności nieobjętych SIWZ w wymiarze 250 roboczogodzin, 4) nieodpłatne usunięcie wszelkich błędów i problemów technicznych uniemoŝliwiających prawidłowe funkcjonowanie SI, 5) aktualizacje zawierające; nowe biblioteki programistyczne, frameworki itp. ze względu na rozwój oprogramowania obsługującego SI oraz wykrycie nowych form ataku na serwisy internetowe. Wykonawca udziela bezterminowej gwarancji na prawidłowe funkcjonowanie posiadanego oprogramowania wraz z prawem do bezpłatnej aktualizacji do nowych wersji produktu przez okres 3 lat, przy czym okres gwarancyjny rozpocznie się w dniu podpisania Protokołu Odbioru Końcowego. W okresie gwarancji Wykonawca zapewni stały kontakt w celu udzielania nieodpłatnych konsultacji i pomocy technicznej w dni robocze, w godz. 8:30-16:30 pod numerem telefonu., faxem., Mailem.. Zgłoszenia o błędach, awariach i nieprawidłowościach zaistniałych w działaniu systemu przyjmowane będą, w godzinach , w dni robocze pod numerami telefonów:..; faxu ; . Reakcja serwisu rozumiana jako przystąpienie do usunięcia awarii lub zaistniałych nieprawidłowości nastąpi nie później niŝ w ciągu 2 godzin od momentu zgłoszenia przez Zamawiającego faksem bądź drogą elektroniczną do siedziby Wykonawcy. Czas od momentu zgłoszenia awarii do uruchomienia podstawowej funkcjonalności systemu, rozumianej jako przywrócenie dostępności formy i treści prezentowanych stron sprzed awarii, nie moŝe przekraczać 4 godzin. Wykonawca gwarantuje całkowite usunięcie awarii lub zaistniałych nieprawidłowości w ciągu 48 godzin od momentu ich zgłoszenia przez Zamawiającego (doprowadzenie systemu do pełnej funkcjonalności). Pozostałe warunki gwarancyjne i serwisowe podlegają standardowej procedurze. Wykonawca dopuszcza całkowitą zmianę wyglądu graficznego oprogramowania przez Zamawiającego bez utraty gwarancji. Wykonawca dopuszcza dobudowywanie własnych modułów pisanych przez uprawnionych pracowników Zamawiającego, jednak Wykonawca nie będzie w stanie utrzymać gwarancji bezpieczeństwa w części nowopowstałych funkcjonalności, modułów oraz komunikacji z istniejącą aplikacją). Wykonawca przedkłada Zamawiającemu potwierdzenie wykonania audytu bezpieczeństwa aplikacji. Jednocześnie Zamawiający zastrzega przeprowadzenie testów bezpieczeństwa po wykonaniu oprogramowania tj. równieŝ po podpisaniu Protokołu Końcowego. Wykonawca dokona wszelkich poprawek, które będą wynikiem ww. testów, w ramach gwarancji. Zamawiający moŝe dochodzić roszczeń z tytułu gwarancji takŝe po upływie terminu gwarancji, określonego w ust. 1, jeŝeli reklamował wadę przed upływem tego terminu. Zamawiający ma moŝliwość korzystania z uprawnień wynikających z rękojmi w okresie trwania gwarancji. Po jednokrotnym bezskutecznym wezwaniu do usunięcia wad i usterek, Zamawiający moŝe zlecić ich usunięcie osobie trzeciej na koszt Wykonawcy. PowyŜsze dotyczy równieŝ nieprawidłowego wykonania napraw przez Wykonawcę.

23 11. Licencja Wykonawca przekazuje prawa autorskie, licencje w zakresie tworzonego oprogramowania na rzecz Zamawiającego, tj. bezterminowego uŝytkowania aplikacji/systemu. Utrzymanie aplikacji na serwerach wskazanych przez Wykonawcę i zaakceptowanych przez Zamawiającego nie wymaga przekazania praw licencyjnych związanych z systemem, bazą danych. 12. Archiwizacja danych 12.1 Serwer Wykonawca zapewni tworzenie backupów wszystkich danych z częstotliwością dwa razy dziennie w trakcie pracy SI. Dostęp do dziennych kopii danych będzie moŝliwy przez 30 dni, Dostęp do kopii miesięcznych oraz rocznych będzie ustalony z Zamawiającym podczas szczegółowej analizy SI Powinien umoŝliwić archiwizacje i kompresje danych z panelu administracyjnego, która powinna być wykonywana automatycznie raz na 2-3 lata z moŝliwością zmiany tego okresu. Dodatkowo Administrator powinien mieć moŝliwość w dowolnym momencie wyeksportowania, zarchiwizowania lub skompresowania danych z poziomu panelu. UmoŜliwienie dostępu dla UŜytkowników SI do danych archiwalnych przy zachowaniu norm wydajnościowych. Dostęp do danych archiwalnych rozliczonych umów/zamkniętych dokumentów realizowany w następujący sposób; UŜytkownik widzi swoje (w zaleŝności od uprawnień) dokumenty archiwalne na poziomie panelu. Od strony architektury systemu, dostęp do danych archiwlanych realizowanych przez mechanizmy archiwizacyjne (tj. po rozpakowaniu paczki z danymi z roku 2002 system zrealizuje dostęp dla uŝytkownika tylko do odczytu) Zakresy dat widoczności danych archiwalnych zostaną ustalone podczas szczegółowej analizy.

24 VII. Wymagania niefunkcjonalne System Informatyczny musi być dostosowany do najpopularniejszych przeglądarek internetowych w tym: Internet Explorer w wersjach 6.x i nowsze, Firefox w wersjach 2.x i nowsze, Google Chrome w wersjach 4.x i nowsze, Opera w wersjach 8.x i nowsze, Safari w wersjach 4.x i nowsze. Wydajność systemu Wybrana technologia powinna zapewniać wysoką skalowalność systemu, poprzez moŝliwość zastosowania w przyszłości architektury klastra wydajnościowego. System musi umoŝliwić jednoczesną prace dla modułu podmiotu co najmniej dla 1000-ca osób a dla modułów MSiT co najmniej 200 osób. ObciąŜenie serwerów podczas pracy aplikacji nie powinno przekraczać 60% (CPU,RAM). Czas oczekiwania na załadowanie strony nie powinien przekraczać 5 sekund. Wykonawca gwarantuje 99,5% dostępności serwisu w sieci. Skalowalność treści na stronie SI System musi dopasowywać swoją zawartość strony do rozdzielczości monitora danego uŝytkownika. Architektura systemu System musi być zaimplementowany w architekturze wielowarstowej. Zamawiający preferuje wykorzystywanie wzorców projektowych w tym wzorzec MVC. Aplikacja ma być oparta o standardy W3C min. WAI-AAA, WCAG 1.0, CSS 1,2, HTML 4, XML - XQuery, XML Schema, XSLT UŜyteczność strony (Usability) System powinien być intuicyjny i prosty w uŝyciu, czas oczekiwania na załadowanie strony nie powinien przekraczać 5 sekund. SI powinien umoŝliwić w prosty sposób zmiany wielkości czcionki w skali małe litery, średnie i duŝe. System powinien automatycznie uzupełniać pola formatek danymi, które są mu dostępne z danego konta oraz umoŝliwić przejście między formatkami za pomocą klawisza Tab. Listy i tabele powinny mieć moŝliwość sortowania. Pełna obsługa błędów wraz z komunikatami dla UŜytkowników. Zakres prac będących przedmiotem zamówienia i harmonogram odbioru Zadanie Czas realizacji Sposób odbioru Analiza i dokumentacja projektowa 1-5 tydzień po podpisaniu umowy weryfikacja przypadków uŝycia ewentualne poprawki harmonogramu poprzez dyrektorów i akceptacja Projekty Interface-ów 5-6 tydzień od podpisania umowy wybór layoutu przez dyrektorów i informatyków

25 Zadanie Czas realizacji Sposób odbioru Prototypownie 7-13 tydzień od podpisania umowy weryfikacja poprzez testy z wybranymi uŝytkownikami Wersja testowa i poprawki tydzień po podpisaniu umowy Informatycy i wybrani uŝytkownicy Testy bezpieczeństwa i poprawki tydzień po podpisaniu umowy testy przeprowadza firma zewnętrzna i po zapoznaniu się z ich opinią akceptacja informatyków WdroŜenie tydzień po podpisaniu umowy informatycy Szkolenia tydzień po podpisaniu umowy dyrektor administracyjny Dostrojenie tydzień po podpisaniu umowy wszyscy zainteresowani Praca będzie realizowana w 3 następujących etapach: I etap składający się z analizy i opracowania dokumentacji projektowej oraz ewentualnych poprawek harmonogramu oraz przygotowaniem projektów interface-ów II etap składający się z prototypownia, realizacji wersji testowej i poprawek, realizacji testów bezpieczeństwa i poprawek oraz wdroŝenia II etap III etap składający się ze szkolenia i dostrojenia WW. etapy będą powiązane z płatnościami. Dedykowany zespół do realizacji przedmiotu zamówienia. Zamawiający wymaga, aby Wykonawca dedykował do realizacji przedmiotu zamówienia zespół. W skład którego muszą wchodzić osoby posiadające wiedze i doświadczenie w następującym zakresie: będzie dysponował co najmniej następującymi osobami, które będą uczestniczyły w realizacji przedmiotu zamówienia: W skład zespołu muszą wchodzić m.in. następujące osoby: kierownik projektu, analityk, specjalista ds. wdroŝeń i utrzymania oraz programista. Zespół powinien mieć doświadczenie w zakresie projektowania i wdraŝania na: aplikacji zbudowanych w oparciu o wzorce projektowe, wysokowydajnych relacyjnych baz danych, procesów biznesowych, przepływu danych, bezpiecznych aplikacji (komunikacja oparta o SSL, szyfrowanie danych, znajomość i umiejętność tworzenia zabezpieczeń aplikacji i sprzętu przed atakami sieciowymi), aplikacji typu CMS, CRM itp., utrzymania wysokiej dostępności usług, Ponadto muszą wykazać następującą wiedzę i doświadczenie Kierownik Projektu:

26 a) w ciągu ostatnich 3 lat przed dniem wszczęcia postępowania o udzielenie zamówienia pełnił funkcję kierownika projektu lub zastępcy kierownika projektu, w co najmniej jednym zakończonym projekcie informatycznym polegającym na budowie systemu informatycznego o wartości minimum ,00 zł brutto (jeŝeli wartość ta była ustalona w walucie innej niŝ PLN naleŝy dokonać przeliczenia kwoty w innej walucie na PLN wg średniego kursu NBP waluty z dnia wszczęcia niniejszego postępowania o udzielenie zamówienia), b) posiada znajomość zasad zarządzania projektami. Analityk: posiada minimum dwuletnie (2) doświadczenie zawodowe w zakresie udziału w realizacji projektów informatycznych, w tym: a) doświadczenie w zakresie zbierania i specyfikacji wymagań funkcjonalnych i niefunkcjonalnych, oraz identyfikowania załoŝeń i ograniczeń systemowych, b) doświadczenie w zakresie opracowywania modelu danych (zakresu gromadzonych i przetwarzanych danych) z wykorzystaniem standardu UML 2.0. Specjalista ds. wdroŝenia i utrzymania : a) w ciągu ostatnich 2 lat przed dniem wszczęcia postępowania o udzielenie zamówienia odpowiadał za administrowanie i utrzymanie systemu informatycznego o wartości minimum ,00 zł brutto, b) posiada doświadczenie zawodowe w zakresie udziału w realizacji projektów informatycznych, w tym: doświadczenie w zakresie wdraŝania systemów informatycznych, doświadczenie w administrowaniu i utrzymaniu systemów informatycznych, Programista: w ciągu ostatnich 3 lat przed dniem wszczęcia postępowania o udzielenie zamówienia odpowiadał za implementację co najmniej dwóch systemów informatycznych o architekturze wielowarstwowej wykorzystujących relacyjne bazy danych.

27 VIII. Lista obowiązujących przepisów prawnych, rozporządzeń i zarządzeń Departamenty w MSiT podczas swojej pracy kierują się odpowiednimi ustawami, rozporządzeniami i zarządzeniami. SI podczas odbioru musi posiadać wprowadzone formularze wniosków/ofert, formularze ocen, szablony umów, formularze rozliczeń obowiązujące w danym roku zgodne ze wzorami wymienionych rozporządzeń i zarządzeń. USTAWA z dnia 24 kwietnia 2003 r. o działalności poŝytku publicznego i o wolontariacie oraz inne ustawy wyszczególnione w rozporządzeniach i zarządzeniach podanych poniŝej, Rozporządzenia Rozporządzenie Ministra Sportu i Turystyki z dnia 23 sierpnia 2010 r. w sprawie dofinansowania zadań ze środków Funduszu Rozwoju Kultury Fizycznej (Dz. U. 156 poz. 1051). Ministra Sportu z dnia 22 września 2006 r. w sprawie wyróŝnień i nagród dla zawodników (Dz. U. Nr 181, poz. 1332) Ministra Sportu z dnia 27 lutego 2006 r. w sprawie przyznawania nagród i wyróŝnień zawodnikom nieposiadającym licencji zawodnika (Dz. U. Nr 37, poz. 258) Rozporządzenia Ministra Sportu z dnia 6 czerwca 2007 r. w sprawie nagradzania za szczególne osiągnięcia w dziedzinie kultury fizycznej (Dz. U. Nr 113, poz. 777) Ministra Sportu z dnia 20 września 2006 r. w sprawie stypendiów sportowych dla członków kadry narodowej (Dz. U. Nr 169, poz ze zm.) Rozporządzeniem Ministra Pracy i Polityki Społecznej z dnia 27 grudnia 2005 r. w sprawie wzoru oferty realizacji zadania publicznego, ramowego wzoru umowy o wykonanie zadania publicznego i wzoru sprawozdania z wykonania tego zadania (Dz. U. Nr 264, poz. 2207) Rozporządzenie Ministra Sportu i Turystyki z dnia 9 lutego 2009 r. w sprawie wykazu zawodów sportowych osób głuchych odbywających się przed 2001 r. (Dz. U. Nr 29, poz. 187) Rozporządzenie Ministra Sportu i Turystyki z dnia 9 lutego 2009 r. w sprawie wykazu zawodów sportowych osób niepełnosprawnych odbywających się przed 1992 r. (Dz.U. Nr 29, poz. 186) Rozporządzenie Ministra Sportu i Turystyki z dnia 6 kwietnia 2009 r. w sprawie dofinansowania ze środków budŝetu państwa zadań związanych z budową i remontami obiektów sportowych oraz rozwijaniu sportu (Dz.U. Nr 56, poz. 463) Rozporządzenie Ministra Sportu z dnia 31 października 2005 r. w sprawie dofinansowania zajęć ze środków Funduszu Zajęć Sportowo-Rekreacyjnych dla Uczniów (Dz.U. Nr 226, poz. 1942) Rozporządzenie Ministra Sportu i Turystyki z dnia 23 sierpnia 2010 r. w sprawie dofinansowania zadań ze środków Funduszu Rozwoju Kultury Fizycznej (Dz. U. 156 poz. 1051).

28 Zarządzenia Zarządzenie nr 40 Ministra Sportu i Turystyki z dnia 4 grudnia 2009 r. Zarządzenie Nr 36 Ministra Sportu i Turystyki z dnia 2 grudnia 2008 r. Zarządzenie nr 35 Ministra Sportu i Turystyki z dnia 6 listopada 2009 r. Po podpisaniu umowy zostaną dostarczone kolejne zarządzenia wewnętrzne MSiT dotyczących procedur obowiązujących w departamentach.