Utrzymanie i rozwój aplikacji EBS. - pl-warszawa: usługi w zakresie konserwacji i napraw oprogramowania

Opis przedmiotu przetargu: 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. ii.1.6)