Utrzymanie i rozwój aplikacji EBS

Agencja Restrukturyzacji i Modernizacji Rolnictwa

Opis przedmiotu zamówienia - utrzymanie i rozwój aplikacji EBS.
W ramach przedmiotowego zapotrzebowania wykonane zostaną następujące zadania:
1) Usługi Utrzymania systemu aplikacyjnego EBS, na które złożą się następujące usługi:
a) Grupa usług utrzymania środowisk:
— usługa administracji środowiskami,
— usługa monitorowania dostępności i wydajności,
— usługa instalacji.
b) Grupa usług zapewnienia jakości oprogramowania:
— usługa usuwania wad,
— usługa zarządzania kodem,
— usługa zarządzania konfiguracją,
— usługa integracji i certyfikacji oprogramowania,
— usługa utrzymania dokumentacji.
c) Grupa usług administracji systemem informatycznym:
— usługa administracji systemem informatycznym.
d) Usługa konsultacji.
e) Usługa Zleceń operacyjnych.
2) Usługi Rozwoju systemu aplikacyjnego EBS, na które składają się następujące usługi:
a) Usługa Modyfikacji Aplikacji EBS rozumiana jako rozwój oprogramowania, poprzez tworzenie nowych modułów (wyłączając modyfikację kodu bazowego istniejących modułów Systemu Aplikacyjnego), w zależności od zmian prawnych oraz przepisów wykonawczych i wewnętrznych Agencji, zmian wymagań użytkowników, zaleceń audytorów, bądź z potrzeby integracji tych systemów z innymi systemami informatycznymi.
b) Usługa Ulepszania Aplikacji EBS rozumiana jako usługa ulepszania istniejącego oprogramowania, poprzez zmianę jego istniejących modułów i funkcji, w zależności od zmian prawnych oraz przepisów wykonawczych i wewnętrznych ARiMR, zmian wymagań użytkowników, zaleceń audytorów, bądź z potrzeby integracji tych systemów z innymi systemami informatycznymi.
W ramach powyższych Usług będą wytwarzane takie produkty jak:
1. AOM - Analityczny Opis Modyfikacji (AOM) to zbiór dokumentów specyfikujących - w podziale na obszary - funkcjonalność modułów Systemu Informatycznego realizowanych w zakresie wymagań określonych w Modyfikacji/Ulepszeniu.
Na AOM mogą składać się elementy (artefakty):
1) Specyfikacja workflow aplikacji – prezentuje w postaci diagramu zbiór zadań (wykonywanych przez użytkownika lub system) występujących kolejno po sobie,
2) Specyfikacja prototypu aplikacji (prototyp funkcjonalny) – prezentuje uproszczony sposób interakcji użytkownika z aplikacją. Prototyp funkcjonalny prezentuje wyłącznie sposób interakcji użytkownika z modułami Modyfikacji/Ulepszenia, określa wygląd, zakres informacyjny oraz logikę przejść pomiędzy poszczególnymi formularzami. Prototyp funkcjonalny uzupełnia opis funkcji użytkownika modułów Modyfikacji/Ulepszenia poprzez jej wizualizację, stanowi uproszczony widok docelowych modułów Modyfikacji/Ulepszenia niezawierających rzeczywistych danych. Prototyp funkcjonalny przedstawiony w formie aplikacji interaktywnego modelu komponentów i ekranów w archiwum Enterprise Architekt (nie zapisuje, nie drukuje i nie operuje na wprowadzanych danych). W szczególnych przypadkach rolę prototypu funkcjonalnego pełnić może kolekcja zrzutów ekranowych ilustrująca wygląd docelowych formularzy, wraz z logiką przejść przedstawioną w postaci diagramów lub opisów formalnych,
3) Specyfikacja przypadków użycia, w tym:
a) a) diagramy przypadków użycia;
b) b) diagramy aktywności prezentują:
— funkcje użytkownika – opis realizowanych akcji przez użytkownika i system (przebiegi, reguły),
— funkcje systemowe - opis realizowanych akcji przez system (przebiegi, reguły).
c) c) tabele / drzewa decyzyjne opisując warunki związane z określonymi działaniami oraz ograniczenia na związane z nimi zachowania,
4) Specyfikacja wzorów i zakresów dokumentów, raportów wyjściowych, sprawozdań.
5) Specyfikacja modelu dziedziny:
a) model statyczny (klas);
b) dynamiczny (diagram stanów);
c) słowniki.
6) Parametry biznesowe.
7) Wymagania niefunkcjonalne dla Modyfikacji/Ulepszenia.
8) Dokumenty powiązane.
9) Założenia do konfiguracji Systemu Informatycznego.
2. Oprogramowanie - oznacza oprogramowanie wytworzone w ramach realizacji Umowy, wchodzące w skład Modyfikacji lub Ulepszenia.
3. Dokumentacja – oznacza Dokumentację odnoszącą się do Modyfikacji lub Ulepszenia w ramach której wytwarzana jest:
a) Dokumentacja Użytkownika – stanowi opis aplikacji, przeznaczony dla użytkownika końcowego (tj. osoby korzystającej z aplikacji). Dokumentacja Użytkownika powinna zawierać m.in.: dokładny opis realizowanej funkcjonalności, opis elementów znajdujących się na poszczególnych ekranach, opis wyświetlanych komunikatów informujących o błędach w trackie pracy użytkownika końcowego.
b) Dokumentacja Administratora stanowi opis procedur administracyjnych wraz z opisem (instrukcją) instalacji i konfiguracji aplikacji oraz zaleceniami eksploatacyjnymi. Instrukcja instalacji i konfiguracji powinna zawierać m.in.: procedury instalacji poszczególnych elementów składowych oprogramowania niezbędnych do działania aplikacji, na infrastrukturze informatycznej oraz konfiguracji w tym konfigurację systemu operacyjnego, baz danych, serwera aplikacyjnego, systemów dostępowych i autentykacyjnych, macierz ról i uprawnień oraz instalację i konfigurację dla Modyfikacji/Produktu. Zalecenia eksploatacyjne powinny zawierać m.in.: procedury uruchamiania i zatrzymania wszystkich komponentów aplikacji wraz z ich odpowiednią sekwencją, wskazanie sposobu uruchamiania procedur wykonania kopii zapasowych aplikacji oraz odtwarzania aplikacji po awarii, procedury sprawdzania prawidłowego działania wszystkich komponentów aplikacji, a także diagnostykę i procedury reakcji na awarie i poważne problemy aplikacji.
c) Dokumentacja Techniczna stanowi dokładny opis działania aplikacji, przeznaczony dla osób posiadających wiedzę z zakresu tworzenia i projektowania systemów aplikacyjnych i implementujących późniejsze Modyfikacje aplikacji. Dokumentacja Techniczna zawiera w sobie lub rozszerza przygotowany wcześniej Projekt Techniczny tj. m.in.: specyfikację projektową (ogólnych opis przyjętego rozwiązania dla oprogramowania w tym podział na komponenty), specyfikację komponentów (opisy głównych komponentów rozwiązania), specyfikację oraz mapowanie klas oprogramowania, listę tabel wraz z opisem, relację powiązań pomiędzy tabelami, listę narzędzi wykorzystywanych w procesie rozwoju oprogramowania oraz opis sposobu komplikacji kodu źródłowego, model rozmieszczenia komponentów w środowisku teleinformatycznym.
Dokumentacja jest opracowywana przez Kierownika Obszaru Implementacji, Kierownika Utrzymania oraz Kierownika Obszaru Infrastruktury (w zakresie Dokumentacji Technicznej i Administratora - odpowiednio w ramach kompetencji) oraz przez Kierownika Obszaru Analizy (w zakresie Dokumentacji Użytkownika), w przypadku zgłoszenia wymagania realizowanego siłami wewnętrznymi DI bądź Wykonawcę Zewnętrznego.
4. Projekt Techniczny przygotowywany jest w celu przedstawienia technicznych aspektów projektowanego oprogramowania systemu aplikacyjnego przed jego wytworzeniem lub modyfikacją i stanowi część Dokumentacji Technicznej, przygotowywanej w późniejszym etapie.
Projekt Techniczny opisuje:
a) projekt techniczny architektury (perspektywy systemu, architektury, dokumentów, bezpieczeństwa);
b) projekt techniczny infrastruktury;
Dokument Projektu Technicznego bazuje na założeniach uzgodnionej Koncepcji Architektury i jest opracowywany przez:
c) Koordynatora ds. Architektury w przypadku zgłoszenia wymagania realizowanego siłami wewnętrznymi DI bądź;
d) Wykonawcę Zewnętrznego i uzgodniony z Koordynatorem ds. Architektury po stronie ARiMR.

Termin
Termin składania ofert wynosił 2012-02-03. Zamówienie zostało opublikowane na stronie 2011-12-19.

Dostawcy
Następujący dostawcy są wymienieni w decyzjach o przyznaniu zamówienia lub innych dokumentach dotyczących zamówień:
Kto?

Co?

Historia zamówień
Data Dokument
2011-12-19 Ogłoszenie o zamówieniu
2012-01-12 Dodatkowe informacje
2012-01-25 Dodatkowe informacje
2012-02-03 Dodatkowe informacje
2012-02-23 Dodatkowe informacje
2013-02-27 Ogłoszenie o udzieleniu zamówienia