Utrzymanie, usuwanie bieżących błędów i problemów oraz modyfikacje funkcjonalne systemu MEWA2.0

Transkrypt

1 Projekt współfinansowany z Europejskiego Funduszu Społecznego Utrzymanie, usuwanie bieżących błędów i problemów oraz modyfikacje funkcjonalne systemu 2.0 Spis treści OPIS PRZEDMIOTU ZAMÓWIENIA... 2 OPIS SYSTEMU... 2 ARCHITEKTURA SYSTEMU... 2 MODUŁ... 3 Front-End... 3 Back-End... 3 MODUŁ... 3 ZADANIA DO REALIZACJI... 3 ZADANIE 1 - UTRZYMANIE APLIKACJI I USUWANIE BŁĘDÓW I PROBLEMÓW Usuwanie błędów... 4 Przegląd kodu... 5 Refaktoryzacja kodu... 5 Pokrycie testami kodu... 6 Aktualizacja dokumentacji... 6 ZADANIE 2 - PRZEBUDOWA APLIKACJI ORAZ MODYFIKACJE FUNKCJONALNE SYSTEMU W OKREŚLONYM ZAKRESIE HARMONOGRAM TERMINY W PROJEKCIE ZASADY ROZLICZANIA PRAC WYMAGANIA DOTYCZĄCE ŚRODOWISKA PRACY ŚRODOWISKO DEWELOPERSKIE ŚRODOWISKO SERWISOWE ŚRODOWISKO PRACY WYMAGANIA DOTYCZĄCE JAKOŚCI KODU NOTACJA NAZEWNICTWO TEST-DRIVEN DEVELOPMENT TESTOWANIE METODYKA PRACY SCRUM WYMAGANIA DOTYCZĄCE DOKUMENTACJI UŻYTKOWA TECHNICZNA Strona 1 z 17

2 Opis Przedmiotu Zamówienia Przedmiotem zamówienia jest utrzymanie Lokalnego Systemu Teleinformatycznego 2.0, usuwanie bieżących błędów i problemów systemu oraz modyfikacje funkcjonalne systemu w ramach zamówionej puli 1700 godzin. Usługa będzie realizowana w latach Rozliczenie będzie następować w oparciu o przepracowane godziny w okresach rozliczeniowych zgodnie z przekazywanymi zleceniami wykonania prac. Całość zamówienia podzielona jest na 2 zadania: Zadanie 1: Utrzymanie aplikacji i usuwanie bieżących błędów i problemów. Zadanie 2: Przebudowa aplikacji oraz modyfikacje funkcjonalne systemu w określonym zakresie. Poniżej przedstawiono podział wymaganej puli godzin na zadania. Nr zadania Limit roboczogodzin na zadanie Realizacja do Zadanie Przez cały okres umowy lub do wyczerpania limitu godzin Zadanie Realizacja zadania zgodnie z terminami wyznaczonymi w tabeli dot. Zadania 2 w kolumnie Termin realizacji Opis Systemu System 2.0 jest narzędziem przeznaczonym do obsługi procesu ubiegania się o środki pochodzące z Regionalnego Programu Operacyjnego Województwa Mazowieckiego Główne cele to: przygotowanie, edycja i wysłanie podpisanego elektronicznie wniosku o dofinansowanie projektu, przechowywanie i dostęp do dokumentów projektu w formie elektronicznej, wymiana informacji. Wnioskodawcy są zobligowani do stosowania elektronicznego formularza wniosku o dofinansowanie, uwierzytelnionego przez podpis elektroniczny z certyfikatem kwalifikowanym lub przez nieodpłatny profil zaufany na platformie epuap. Celem obecnej odsłony projektu jest utrzymanie systemu oraz podniesienie jakości obecnie wytworzonego oprogramowania poprzez działania zgodnie z najlepszymi praktykami tworzenia oprogramowania. W celu podniesienia standardów jakościowych tworzenia oprogramowania Zamawiający dopuszcza powołanie zewnętrznego nadzoru autorskiego nad wybranym wykonawcą. Architektura systemu System 2 składa się z 2 modułów Strona 2 z 17

3 Moduł Mewa 2.0 część front End Moduł część Back Office Moduł Pierwszy moduł aplikacji składa się z 2 komponentów Front-End Back-End Poniżej przedstawiono skrócony opis komponentów modułu. Front-End Część FRONT-END napisania jest w technologii React.js. Kod ten odpowiedzialny jest za obsługę formularzy wniosków, przekazywanych do systemu BACK-END. Brak komentarzy w kodzie Back-End Część BACK-END napisana jest w technologii C# z wykorzystaniem MVC Framework oraz MS SQL. Obecny kod składa się z około 12 tysięcy linii kodu Moduł Moduł napisany jest w technologii C# z wykorzystaniem MVC Framework, zintegrowanej z farmą SharePoint, dedykowaną do obsługi aplikacji. Obecny kod składa się z około 32 tysięcy linii kodu. Zadania do realizacji W ramach niniejszego Zamówienia Wykonawca zobowiązany jest do realizacji następujących zadań: Zadanie 1 Utrzymanie aplikacji i usuwanie błędów i problemów. Zadanie 2 Przebudowa aplikacji oraz modyfikacje funkcjonalne systemu w określonym zakresie. Poniżej przedstawiono szczegółowy zakres każdego z zadań. Ramy czasowe dla zadań definiuje rozdział Harmonogram. Zadanie 1 - Utrzymanie aplikacji i usuwanie błędów i problemów. Głównym celem Zadania 1 jest zapewnienie ciągłości działania obecnego systemu oznacza to w szczególności: Usuwania błędów występujących w aplikacji Przegląd kodu, w szczególności ostrzeżeń wynikających z automatycznej analizy kodu. Refaktoryzacja kodu Pokrycie testami kodu Aktualizacja dokumentacji Strona 3 z 17

4 Usuwanie błędów Wykonawca zobowiązany jest naprawiać wszystkie błędy zgłaszane przez zamawiającego poprzez środowisko serwisowe podczas całego okresu trwania umowy lub do wyczerpania godzin. Do Wykonawcy należy : Analizowanie zgłoszonych problemów dotyczących Systemu, Opracowanie i wdrożenia obejścia problemu, w przypadku gdy usunięcie problemu nie jest możliwe, Przygotowywanie poprawek wprowadzanych w ustalanych cyklach wydawania nowej wersji (dla błędów standardowych) lub w postaci łat wdrażanych doraźnie dla błędów krytycznych. Usuwanie awarii Systemu, Gotowość do świadczenia usługi (Standby) Przyjmowanie oraz klasyfikacja zgłoszeń, Gotowość do rozwiązywania Problemów w trybie Pomocy zdalnej i Interwencji, Gotowość do świadczenia Wizyt serwisowych. Wizyta serwisowa Instalowanie nowych wersji Systemu; Testy poprawności działania Systemu; Aktualizacja dokumentacji Systemu. Zasady zgłaszania błędów, kategorie zgłoszeń i czas reakcji Zgłoszenia W sytuacji zgłoszenia przez administratorów aplikacji awarii/ błędu systemu przedstawiciel Wykonawcy wyznaczony do realizacji umowy jest zobowiązany do podjęcia działań w celu usunięcia sytuacji problemowej. W sytuacji wystąpienia błędów lub zgłoszenia przez przedstawiciela Zamawiającego zgłoszenia serwisowego, Wykonawca zobowiązany jest do reakcji oraz realizacji zadań naprawczych w czasie określonym w tabeli poniżej. Kategorie zgłoszeń i czas reakcji W przypadku konieczności wykonania naprawy za pośrednictwem zdalnego dostępu reakcja nastąpi w ciągu przewidzianego zakresu czasowego od chwili udostępnienia przez Zamawiającego zdalnego. Metody komunikacji Wykonawca dopuszcza komunikację: poprzez środowisko serwisowe telefonicznie na numery telefonów komórkowych osób wyznaczonych do realizacji umowy. za pomocą poczty elektronicznej za pomocą adresów osób wyznaczonych do realizacji umowy. W sytuacjach kiedy ww. metody nie są możliwe lub skuteczne możliwa jest komunikacja za pomocą pism (poczty, kuriera lub faksów): na adres Zamawiającego i siedziby firmy Wykonawcy. Strona 4 z 17

5 Gwarantowany poziom świadczenia usługi utrzymania aplikacji i usuwania błędów i problemów (SLA) Warunki i zakres serwisu aplikacji w oferowanym okresie spełniać ma następujące warunki:. 1. Wsparcie będzie świadczone zdalnie lub w siedzibie Zamawiającego, mieszczącej się przy ulicy Jagiellońskiej 74 w Warszawie lub w innych miejscu wskazanym przez Zamawiającego na terenie Warszawy w godzinach roboczych 8-16 Priorytet Opis Czas Reakcji Wysoki Średni Niski Błąd w oprogramowaniu, który wystąpił podczas normalnej eksploatacji Systemu, uniemożliwiający poprawną pracę środowiska pod kątem działalności operacyjnej lub biznesowej dla wszystkich lub znacznej populacji użytkowników Systemu (powyżej 60%). Błąd w oprogramowaniu, który wystąpił podczas normalnej eksploatacji Systemu, utrudniający poprawną pracę środowiska pod kątem działalności operacyjnej lub biznesowej Zamawiającego. Wnioski Zamawiającego, prośby o analizę, zapytania. Czasy przywrócenia podstawowej funkcjonalności - podane wartości 4 h 16 godzin roboczych 8 h 24 godziny robocze 2 dni robocze - Przegląd kodu W ramach tej części zadania Wykonawca zapozna się kodem oraz dokumentacją systemu. Pojawiąjące się w kodzie aplikacji ostrzeżenia mogą być przyczyną nieustalonych zachowań oprogramowania i należy wykonać ich analizę i ich usunięcie w pierwszej kolejności. Refaktoryzacja kodu Celem tego zadania jest wprowadzanie zmian w kodzie aplikacji, które nie zmieniają jej funkcjonalności, ale poprawią optymalizację i jakość kodu. Refaktoryzacja obejmować ma następujące elementy: modyfikowanie elementów systemu w celu wpasowania ich w przyjęte standardy i wzorce poszukiwanie nowych standardów i wzorców, które pojawiły się w systemie w trakcie jego rozwoju i ich precyzyjne definiowanie Usystematyzowanie i poprawa nazewnictwa zmiennych. Uzupełnienie brakujących komentarzy w kodzie Uzupełnienie znaczników do automatycznej budowy specyfikacji wewnętrznej Usystematyzowanie kodu na wykorzystanie jednej wersji bibliotek.net zamiast trzech Poprawa/aktualizacja metryk kodu. Strona 5 z 17

6 Pokrycie testami kodu Podniesienie jakości kodu poprzez uzupełnienie napisanego kodu o automatyczny test sprawdzający dodawaną funkcjonalność, zgodnie ze standardami Test-Driven development. W ramach tego zadania Wykonawca ma dokonać uzupełnienie kodu o wymienione testy. Aktualizacja dokumentacji Wykonawca zobowiązany jest do aktualizacji dokumentacji w następujących obszarach: Architektura aplikacji Architektura Infrastruktury Dokumentacja kodu Efektem tego zadania mają być: Udokumentowane założenia architektoniczne w aplikacji Komunikacja aplikacji z systemami zewnętrznymi (epuap, SL 2014, Teryt) Dokumentacja użytych klas Dokumentacja modułów Architektura farmy SharePoint Wykaz wykorzystanych bibliotek. Zadanie 2 - Przebudowa aplikacji oraz modyfikacje funkcjonalne systemu w określonym zakresie. Lp. Funkcjonalność System Szczegółowy opis Termin realizacji I. Wniosek o dofinansowanie projektu wygląd/ funkcjonowanie 1. Modyfikacja sekcji F. Oświadczenia wniosku o dofinansowanie EFS i sekcji G. Oświadczenia we wniosku o dofinansowanie EFRR / modyfikacja formularza typu WniosekWUP 2. Modyfikacja w zakresie ilości znaków dostępnych dla wnioskodawców w poszczególnych polach wniosku o dofinansowanie EFS Modyfikacja istniejących oświadczeń, dodanie nowych (m. in. oświadczenie dot. VAT), dodanie pola adres e- mail do sekcji B formularza typu WniosekWUP, aktualizacji walidacji pól, uwzględnienie zmian w transformacie do pliku.pdf i wizualizacji w - C2.1.2 o 1000 znaków do 4000 znaków; - C3.1 o 1500 znaków do 3500 znaków; - C3.2 o 500 znaków do 1500 znaków; - C3.3 o 2000 znaków do 3000 znaków; - D4 o 500 znaków do 1500 znaków; Strona 6 z 17

7 3. Kwota VAT we wniosku o dofinansowanie EFRR 4. Modyfikacja formuł w formularzu EFS 5. Generowanie sumy kontrolnej wniosku o dofinansowanie i zapisywanie jej w pliku xml oraz pdf. 6. Wizualizacji formularza wniosku o dofinansowanie EFS i EFRR / - D5 o 1000 znaków do 2500 znaków. Łączna dodatkowa ilość znaków: 6500 znaków Możliwość wpisywania kwoty VAT ręcznie, niezależnie od zaproponowanych stawek w słowniku. 1) Obliczanie pola A11 w EFS: jeżeli E1.10 Wkład własny jest <= (A8*0,2) to A11.: A8*0,8 // czyli jak dotychczas w przeciwnym razie A8 = A10 Zobowiązanie wynikające z kontroli systemowej IZ oraz zapotrzebowania użytkowników (w szczególności WWS oraz WUP). Sumą kontrolną powinien być oznaczony każdy plik wniosek.xml i wniosek.pdf, które wpływają do SP czyli te, które tworzą kolejne wersje wniosku (1.0, 2.0 itd). Przykładowy format: XXXX-XXXX- XXXX-XXXX (X - litera bądź cyfra). Dotyczy wersji wniosku EFS/EFRR/WUP. - Poprawki widoczności sekcji E2 w formularzu EFS (zarówno w zakresie wizualizacji wniosku w SP, jak i generowania pliku pdf) : Obecnie wiersz dotyczący poszczególnego wydatku dzielony jest na kilka tabel, przez co praca z budżetem wniosku staje się mocno utrudniona. Należy doprowadzić do sytuacji, że wszystkie Strona 7 z 17

8 7. Poprawa (zachowanie) formatowania pól opisowych we wniosku o dofinansowanie (zarówno w zakresie wizualizacji wniosku w SP, jak i generowania pliku pdf) 8. Modyfikacja /poprawa funkcji walidacji dla Wniosek EFS / informacje dotyczące poszczególnego wydatku w danym roku będą przedstawiane w jednej tabeli (format A4) natomiast ostatnia tabela będzie pokazywała sumę z całego okresu realizacji projektu. - Zmiany wizualizacja formularza EFRR w zakresie sekcji E Wskaźniki i F Budżet. - poprawa numeracji we wniosku EFS (powtarzający się nr C1.6.) Zarówno wizualizacja wniosku w SP, jak i transformata do PDF nie czyta akapitów w formularzu przez co wniosek staje się mniej czytelny. Dotyczy wersji wniosku EFS/EFRR/WUP. Obecnie informacja o błędzie walidacji wyświetlana w lewym menu nie jest wyświetlana dla sekcji E2, E3 i E4 przed przejściem użytkownika do tych sekcji. Informacja o błędzie powinna być ustawione tak, jak np. w sekcji A czy B. Gdy projekt przekracza 2 mln PLN a beneficjent nie wypełni pola ryzyko C.4, formularz nie wyświetla błędu. - poprawna walidacja. Powinien być wyświetlony błąd oraz brak możliwości walidacji projektu ( : do zweryfikowania, czy problem nadal występuje) Strona 8 z 17

9 9. Rozróżnienie we wniosku EFS, co najmniej na poziomie generowanego xml-a, rodzaju wskaźnika (kluczowy / specyficzny / własny/) 10. Zamówienia publiczne /MEW A 11. Możliwość posługiwania się wskaźnikami z wartości dziesiętnymi we wniosku o dofinansowanie EFS Dodanie tagów xml dot. rodzaju wskaźników i uwzględnienie tego w zdefiniowanym raporcie wskaźnikowym. Wyodrębnić moduł zamówień publicznych z formularza w celu modyfikacji niezależnej od modyfikacji wniosku. Możliwość definiowania wskaźników, dla których dopuszczone jest wprowadzenie wartości z dokładnością do dwóch miejsc po przecinku w module administratora; odpowiednia modyfikacji pól formularza umożliwiająca wprowadzenie tak zdefiniowanej wartości 12. Poprawa działania aplikacji w ramach pola dotyczącego ryzyk (formularz EFS) Wprowadzenie zbyt dużej ilości znaków do ryzyk, pomimo zmieszczenia się w ramach widocznego limitu) powoduje błąd pobierania pdf-a oraz xml i tym samym brak możliwości podpisania wniosku - Błąd xml 101 albo brak możliwości pobrania danych z serwera II. Wniosek o dofinansowanie funkcja porównywania 1. modyfikacja funkcjonalności "Porównaj wersje xml" dla Typ projektu: Wniosek EFS i Wniosek EFRR W przypadku formularza EFS i EFRR umożliwienie wyboru wersji, które mają być porównane - dotychczas porównywane są dwie ostatnie wersje. Możliwość skorzystania z tej funkcji również z list wydziałów wdrożeniowych Strona 9 z 17

10 2. modyfikacja funkcjonalności "Porównaj wersje xml" dla Typ projektu: Wniosek WUP III. (obecnie funkcjonalność jest dostępna z poziomu listy Wnioski) Działania analogiczne do Wniosek EFS i Wniosek EFRR Raportowanie 1. Moduł raportowanie Możliwość dodawania zapytań SQL 2. Możliwość generowania Dla wszystkich raportu z plików PW wniosków i w podziale 3. Umożliwienie raportowania Wnioskodawców i Partnerów Wnioskodawcy po NIP IV. 1. Zmiany w funkcjonowaniu części aplikacji związanej z przydzielaniem zadań dla Beneficjentów (np. zamykanie zadań nieobsłużonych w / automatyczne zamykanie zadań przeterminowanych skutkująca brakiem możliwości wysłania realizacji zadania po terminie wniosku do po terminie, wprowadzenie dodatkowego typu zadania skutkujące wysyłaniem do wnioskodawcy różnych powiadomień (zadania podpisane i nie podpisane) 2. Dokonanie poprawy funkcjonowania panelu oceny finalnej EFS 3. Powiadomienia w postaci np. a dla użytkowników systemu o aktywności wnioskodawców 4. Generowanie na wydrukowanych załącznikach/dokumentac h do umowy oraz wszelkiej / na konkursy. Dla wszystkich wniosków i w podziale na konkursy. - ogólne Poprawa funkcji zliczania punktów, możliwość aktualizacji punktów Zobowiązanie wynikające z kontroli systemowej IZ oraz zapotrzebowania Strona 10 z 17

11 IV. korespondencji przesłanej przez wnioskodawcę informacji zawierającej datę wydruku, datę złożenia, "Dokument podpisany elektronicznie" do rozważenia "Dokument podpisany elektronicznie przez Jana Nowaka" użytkowników (w szczególności WWS oraz WUP). Sumą kontrolną powinien być oznaczony każdy plik wniosek.xml i wniosek.pdf, które wpływają do SP czyli te, które tworzą kolejne wersje wniosku (1.0, 2.0 itd). Przykładowy format: XXXX-XXXX- XXXX-XXXX (X - litera bądź cyfra). Funkcjonowanie moduł oceny 1. Negocjacje EFS Wprowadzenie dodatkowej karty negocjacyjnej w ramach oceny merytorycznej EFS i uwzględnienie jej w przypisywaniu zadań, panelu oceny finalnej oraz zmianie statusów 2. Ponowna ocena formalna na wniosek wydziału wdrażania (ścieżka EFRR) 3. Ponowna ocena OOŚ i ocena pomoc publicznej przed podpisaniem umowy (ścieżka EFRR) 4. Przekształcanie kart oceny merytorycznej w pdf w systemie Stworzyć nową funkcjonalność polegającą na potwierdzaniu statusu wniosku przez WOF zlecane przez WWR. Stworzyć nową funkcjonalność na etapie przed podpisaniem umowy. Wyniki oceny są przekazywane za pomocą systemu do beneficjenta, nie wymagają podpisu, aby je przekazać w formacje nie edytowalnym musimy je wydrukować w pdf - w systemie powinno być dostępne narzędzie umożliwiające przekształcenie karty oceny w pdf lub zablokowanie jej do edycji i umożliwiające zaciemnienie imienia i nazwiska oceniającego, a następnie dołączenie Strona 11 z 17

12 5. Modyfikacja funkcjonowania oceny formalnej EFS 6. Poprawienie daty na karcie weryfikacji wymogów formalnych (ścieżka EFS) 7. Panel oceny finalnej po ocenie formalnej (ścieżka EFS) do korespondencji w zadaniach dla beneficjenta. Poprawa w zakresie statusów / ew. połączenie etapu weryfikacji wymogów formalnych z oceną formalną Generowanie na kartach weryfikacji i KOF w pozycji data wpłynięcia uzupełnionego wniosku: data zarejestrowanego uzupełnienia wniosku - wynik kontroli MR. Podświetlenie panelu finalnej oceny formalnej na czerwono w przypadku negatywnej oceny V. Funkcjonowanie - wdrażanie 1. Lista wnioski WWS/WWR Dodanie kolumny "status umowy : W trakcie podpisywania umowy (wartość domyślna po przeniesieniu wniosku na listę; Umowa podpisana; Umowa zakończona, Umowa rozwiązana. (ew. dodatkowe statusy: Rezygnacja, Cofnięty do etapu oceny). Ponadto dostępność z poziomu menu dla wniosku do: - Historia wersji Pokazuje historię wersji wpisów na liście dla danego wniosku - Porównaj wniosek Porównuje wersje wniosków o dofinansowanie w ramach tego samego projektu (patrz moduł: Porównywanie wniosków) - Przedstawiciele Strona 12 z 17

13 wnioskodawcy Pokazuje Przedstawicieli wniosku o dofinansowanie wskazanych na etapie składania wniosku przez wnioskodawcę lub później w wyniku aktualizacji. - Dodaj zadanie dla wnioskodawcy Tworzy zadanie dla wnioskodawcy 2. Karta kompletności na zakończenie projektu 3. Formularz zgłoś problem powinien zawierać nr konkursu 4. Stworzenie tabeli z protestami dla WUP analogicznej do stosowanej przez MJWPU Automatyczna aktualizacji danych na listach WWS/WWR zgodnie z faktycznymi danymi wynikającymi z wniosków o dofinansowanie / przebiegiem procesów) Możliwość załączania edytowalnej wersji pliku WORD w celu wprowadzenia do niego zmian przez użytkowników z różnych wydziałów (lub porównywalnego rozwiązania)tworzenie kart z menu na listach WWS/WWR. Udostępnianie karty właściwym komórkom organizacyjnym. Inne Z zachowaniem siatki uprawnień. Harmonogram Zamawiający wymaga realizacji prac zgodnie z następującymi wymaganiami Strona 13 z 17

14 Terminy w projekcie Tabela 1. Harmonogram prac Lp Zadanie Terminy 1 Zadanie 1: Utrzymanie aplikacji i usuwanie bieżących błędów i problemów Do , począwszy od momentu podpisania umowy. Gotowość do realizacji prac w ciągu 2 tygodni od podpisania 2 Zadanie 2: Przebudowa aplikacji oraz modyfikacje funkcjonalne systemu w określonym zakresie. umowy Realizacja zadania zgodnie z terminami wyznaczonymi w tabeli dot. Zadania 2 w kolumnie Termin realizacji Zamawiający przewiduje możliwość wprowadzenia zmian w zakresie terminów realizacji poszczególnych elementów składowych Zadania 2 (wskazanych powyżej), tj. Zamawiający przewiduje możliwość wydłużenia terminu realizacji poszczególnych elementów, jednakże nie dłużej niż do 6 miesięcy od dnia zawarcia umowy. Zmiana może zostać wprowadzona w przypadku wystąpienia sytuacji związanych z działaniem siły wyższej, tj. wyjątkowych zdarzeń lub niezwykłych i nieprzewidzianych okoliczności niezależnych od Strony, która się na nie powołuje i których konsekwencji mimo zachowania należytej staranności nie można było uniknąć, np. zmiany w przepisach prawa, które mają wpływ na kształt prowadzonego projektu, zmiany wytycznych, wpływających na opisane powyżej modyfikacje, uzasadnione problemy techniczne/technologiczne, które wymuszają zastosowanie innych, nieprzewidywanych dotychczas rozwiązań. Zamiany muszą być zaakceptowana przez obie ze stron. Żadna ze zmian nie może spowodować zwiększenia ceny za realizację przedmiotu zamówienia. Żadna ze zmian nie może wpłynąć na wydłużenie terminu realizacji innych elementów przedmiotu zamówienia. Żadna ze zmian nie może wpływać negatywnie na jakość realizowanych usług. Do dokonania zmiany wymagane jest zawarcie stosownego aneksu. Zasady rozliczania prac Zamawiający przewiduje podział limitu oferowanych godzin na zadania, zgodnie z tabelą poniżej. Nr zadania Limit roboczogodzin Realizacja do na zadanie Zadanie Przez cały okres umowy lub do wyczerpania limitu godzin Zadanie do lub do wyczerpania godzin Zamawiający dopuszcza możliwość zmian w liczbie godzin, które przewidziano na realizację poszczególnych zadań. Godziny mogą zostać wykorzystane naprzemiennie pomiędzy zadaniami jednakże w stopniu nie większym niż 350 godzin przeznaczonych na realizację danego zadania. Powyższe zmiany mogą zostać wprowadzone w przypadku niewykorzystania maksymalnej liczby godzin przeznaczonej na jedno z zdań lub w przypadku uzasadnionych okoliczności wpływających na konieczność zwiększenia liczby godzin któregokolwiek z zdań. Żadna ze zmian nie może spowodować zwiększenia ceny za realizację przedmiotu zamówienia. Żadna ze zmian nie może wpłynąć na wydłużenie terminu realizacji innych elementów przedmiotu zamówienia. Żadna ze zmian nie może wpływać negatywnie Strona 14 z 17

15 na jakość realizowanych usług. Do dokonania zmiany wymagane jest zawarcie stosownego aneksu. Wymagania dotyczące środowiska pracy Środowisko deweloperskie Podczas realizowania projektu wykonawca stworzy środowisko deweloperskie na infrastrukturze zamawiającego. Środowisko deweloperskie musi zawierać repozytorium kodu wraz z systemem kontroli wersji. Środowisko serwisowe Podczas realizowania projektu wykonawca zapewni środowisko serwisowe w celu zgłaszania i obsługi błędów zgłaszanych przez Zamawiającego w ramach Zadania 1. System ten ma być dostępny przez przeglądarkę z sieci Internet. Powinien umożliwić zalogowanie się pracownikom Zamawiającego i umożliwiać zarówno zgłaszanie błędów, jak również śledzenie postępów realizacji zgłoszenia. Środowisko pracy Zadania będą realizowane, co do zasady w siedzibie Zamawiającego lub w innej lokalizacji na terenie Warszawy wskazanej przez Zamawiającego. Zamawiający zapewni przedstawicielom wykonawcy dostęp do pomieszczeń zamawiającego wyposażonych tylko w biurka i miejsca siedzące w których będą prowadzone prace związane z realizacja przedmiotu zamówienia. Wykonawca zapewni wyposażenie niezbędne do realizacji Umowy tj. dostęp do Internetu, właściwy sprzęt, niezbędne oprogramowanie inne wyposażenie konieczne do prawidłowego realizacji przedmiotu zamówienia. Wykonawca zapewni wykonanie prac związanych z realizacja przedmiotu zamówienia zgodnie z zachowaniem procedur i regulaminów obowiązujących u zamawiającego. Wymagania dotyczące jakości kodu Wytwarzany kod w ramach niniejszego projektu spełniać ma na następujące zasady przy rozbudowie systemu. Notacja Podczas realizowania projektu stosowana ma być ogólnie przyjęta notacja funkcjonująca w środowisku.net- PascalCase, zaczynając każde ze słów wielką literą. Parametry metod i nazwy zmiennych nazywane mają być według notacji camelcase. Nazwy interfejsów zaczynać się mają od litery I (IEnumerable). Metody zwracające wartości typu boolowskiego zaczynać się mają się od słowa Is (IsValid()). Pozostałe nazwy metod występować mają w formie czasownika w trybie rozkazującym (GetData()). Strona 15 z 17

16 Nazewnictwo Nazwy używane w programie opisują rozwiązywany problem i informują o przeznaczeniu danego elementu. Dla lepszej czytelności kodu zamiast logiki stojącej za pewną liczbą opisanej w komentarzu należy zastosować enum lub stałe o stosownej nazwie w celu uniknięcia niezrozumiałych skrótów, przekazywania zbędnych informacji, ale przede wszystkim ułatwieniu pracy zespołowej nad zadaniem. Test-Driven development Technika tworzenia oprogramowania polegająca na wielokrotnym powtarzaniu kilku kroków: Pisania testów, które na obecnym etapie nie powinny się udać. Pisania kodu, którego zadaniem jest przejście napisanych wcześniej testów. Refaktoryzacja napisanego kodu, żeby spełniał oczekiwane standardy. Zamawiający wymaga, aby to podejście stosowane było w projekcie. Kroki te powtarzane mają być aż do dostarczenia pełnej funkcjonalności. Metoda ta ma także być stosowana do wprowadzania zmian w istniejącej aplikacji. Testowanie W czasie realizacji prac Wykonawca zobowiązany jest do przeprowadzania testów. Testy mają na celu weryfikację oraz walidację oprogramowania. Metodyka pracy Scrum Prace programistyczne mają być zgodnie z metodologią SCRUM. Produkty prac będą dostarczone w określonym przedziale czasowym zwanym przebiegiem (ang. sprint). Na etapie realizacji prac Zamawiający zdefiniuje cykl sprintu, który będzie wynosił 2 tygodnie. Efektem przebiegu za każdym razem ma być dostarczenie użytkownikom kolejnej działającej wersji produktu. Zasadą jest to, że zmiany wprowadzane w jednym przebiegu muszą być namacalne dla użytkowników. Muszą wnosić wartość funkcjonalną Wymagania dotyczące dokumentacji W czasie realizacji projektu Wykonawca zobowiązany jest do tworzenia lub uzupełniania dokumentacji użytkowej oraz technicznej. Użytkowa Zamawiający wymaga, aby w trakcie projektu powstała dokumentacja użytkowa. Jest to opis programu przeznaczony dla jego użytkownika. W ramach prowadzonych prac mając być przygotowane następujące dokumenty: pliki pomocy informacje ogólne o programie i sposobie jego obsługi. Instrukcja użytkownika Instrukcja administratora. Techniczna Zamawiający wymaga, aby prowadzona była dokumentacja techniczna. Dokumentacja techniczna przeznaczona jest dla osób, których zadaniem będzie modyfikacja programu. Strona 16 z 17

17 Zawiera dokładne opisy działania programu, algorytmów w nim zastosowanych, informacje o poszczególnych komponentach. Dokumentacja techniczna składać ma się z następujących elementów: Znaczniki pozwalające może zostać wygenerowana automatycznie w środowisku Visual Studio poprzez odpowiednie oznaczenia. Dokumentację architektoniczno funkcjonalną zawierającą architekturę systemu, z podziałem na moduły, podsystemy, interfejsy. Elementami wymaganymi są statyczny model strukturalny, dynamiczny model procesu, model interfejsów, model związków opisujący przepływy danych pomiędzy podsystemami. Informacje dodatkowe: SharePoint Server 2013 uruchomiony w architekturze trójwarstwowej farmy w oparciu o MS SQL 2012 standard Edition oraz Windows Server 2012 standard jako system operacyjny dla wszystkich serwerów. Wszystkie serwery są w jednej domenie i są uruchomione na środowisku wirtualnym Hyper-V (w oparciu o Windows Server 2012 Datacenter). Więcej informacji na temat wymagań dotyczących tworzenia systemu można znaleźć na stronie internetowej Zamawiającego link: Ze względu na sposób wykonania systemu Zamawiający posługuje się nazwami handlowymi poszczególnych elementów składających się na pełne środowisko pracy systemu, gdzie z przyczyn technologicznych nie ma możliwości zastosowania rozwiązania innego, niż zostało to pierwotnie ustalone. Zamawiający dopuszcza rozwiązania równoważne, gwarantujące należytą realizację przedmiotu zamówienia, w sposób wymagany przez Zamawiającego. Każde rozwiązanie równoważne (dotyczące zarówno nazewnictwa wskazanego w Szczegółowym Opisie Przedmiotu Zamówienia, jak i informacji wskazanych w treści SIWZ) musi zapewniać całkowitą zgodność z rozwiązaniami wykorzystanymi w posiadanym przez Zamawiającego systemie, nie może powodować konieczności zmiany środowiska pracy oraz poszczególnych funkcjonalności systemu, nie może powodować powstawania błędów w systemie, nie może negatywnie wpływać na działanie systemu, w tym na jego szybkość i wydajność. Z uwagi na powyższe, wszelkie odniesienia do nazewnictwa i funkcjonalności (w tym nazwy handlowe) są zgodne z art. 29 ust. 3 ustawy P.z.p., a ich użycie jest uzasadnione specyfiką prowadzonego zamówienia. Strona 17 z 17