Załącznik nr 4 do Umowy nr … z dnia ………….…
Załącznik nr 4 do Umowy nr … z dnia ………….…
Dokumentacja Systemu i wymagania w tym zakresie
1. Dokumentacja Systemów
1.1. Dokumentacja Systemu ZISAR zmodernizowanego w trakcie realizacji umowy ZISAR PLUS
Wykonawca będzie zobowiązany do wytworzenia i dostarczenia Zamawiającemu dokumentacji wymienionej w Tabeli 1. Dokumentacja ma uwzględniać wymagania wynikające z SIWZ i Umowy, elementy określone w załączonych szablonach, wymagania zdefiniowane dla poszczególnych dokumentów w niniejszym załączniku, a także dotychczasową zawartość odnośnej dokumentacji dla Systemu ZISAR określonej w punkcie 1.3. w zakresie, który nie ulega zmianom, w tym również zawartość wynikającą z uzupełnienia dokumentacji określonej w punkcie 1.3., dokonanej przez Wykonawcę w oparciu o przeprowadzoną inwentaryzację z natury Systemu ZISAR, w trakcie której Wykonawca zobowiązany jest do zidentyfikowania i udokumentowania wszystkich właściwości eksploatowanego systemu. Określenie Projektu Infrastruktury Technicznej Systemu obejmuje uwzględnienie udostępnionych środowisk systemu określonych w Projekcie Infrastruktury Teleinformatycznej ZISAR II z odpowiednim jego uzupełnieniem zgodnie z szablonem dokumentu z pkt. 3.
Po dokonaniu odbioru dokumentacji przez Zamawiającego, Wykonawca będzie zobowiązany do jej bieżącej aktualizacji zgodnie z postanowieniami Umowy.
Wytworzenie dokumentacji nastąpi z wykorzystaniem szablonów dokumentów z pkt 3 „Wykaz szablonów dokumentów” (dotyczy dokumentów, dla których szablony zostały określone) oraz zgodnie z wymaganiami z pkt 4 „Wykaz wymagań w zakresie minimalnej zawartości dokumentów” niniejszego Załącznika (dotyczy dokumentów, dla których zostały określone wymagania).
L.p. | Nazwa | Szablon/Wymaganie |
I. Dokumentacja zarządcza | ||
1. | Plan zarządzania wymaganiami | Szablon Z1 |
2. | Plan zarządzania konfiguracją oprogramowania | Szablon Z2 |
3. | Plan Umowy | Zgodnie z szablonem i wymaganiami określonymi w zał.2 do Umowy |
II. Standardy dokumentacji obowiązującej w ramach realizacji umowy ZISAR PLUS | ||
1. | Specyfikacja Procesów Biznesowych Systemu ZISAR | Szablon nr 1 |
2. | Specyfikacja Wymagań Systemu ZISAR | Szablon nr 2 |
3. | Mapa Wymagań Systemu ZISAR | Szablon nr 3 |
4. | Model Danych Systemu ZISAR | Szablon nr 7 Wymaganie WD07 |
L.p. | Nazwa | Szablon/Wymaganie |
5. | Projekt Infrastruktury Teleinformatycznej Systemu ZISAR | Szablon nr 4 Wymaganie WD04 |
6. | Projekt realizacji systemu informatycznego dla Systemu ZISAR | Szablon nr 5 |
7. | Plan Integracji Systemu ZISAR | Szablon nr 7 |
8. | Plan Wdrożenia Systemu ZISAR | Szablon nr 8 |
9. | Specyfikacja Migracji Danych Systemu ZISAR * | Szablon nr 9 |
10. | Dokumentacja Architektury Systemu ZISAR | Szablon nr 10 |
11. | Specyfikacja Techniczna XML Systemu ZISAR | Wymaganie WD03 |
12. | Specyfikacja Techniczna Systemu ZISAR (Standard Komunikacji ) | Wymaganie WD08 |
13. | Podręcznik Administratora Systemu ZISAR (zawierający wyodrębnione, oddzielne części dokumentu, przeznaczone dla administratora technicznego oraz administratora merytorycznego) | Szablon nr 11 Wymaganie WD01 |
14. | Podręcznik Użytkownika Systemu ZISAR | Szablon nr 15 Wymaganie WD06 |
15. | Dokumentacja Bezpieczeństwa Systemu ZISAR | Szablon nr 12 |
16. | Pakiet kodów źródłowych ** | Szablon nr 13 |
Tabela 1. Dokumentacja Systemu
* Dokument wymagany wyłącznie w przypadku realizowania migracji danych
**dokument dostarczany przy każdej dostawie oprogramowania
1.2. Dokumentacja referencyjna
1.2.1. Dokumentacja referencyjna udostępniana w ramach SIWZ
Dokumentacja referencyjna składa się z elementów dokumentacji technicznej Resortu Finansów, określanych w Umowie jako EDIT, w skład których wchodzi Techniczna Architektura Referencyjna, określana w Umowie jako ARIT. Poniższe zestawienie zawiera wykaz dokumentacji ARIT i EDIT.
L.p. | Nazwa | Oznaczenie | Wersja |
1. | Architektura Referencyjna Środowiska IT CPD MF (ARIT) | ARIT (Załącznik nr 1 do EDIT - EDIT_1) | 1.6 |
2. | Załącznik A do ARIT - Bloki architektoniczne środowiska teleinformatycznego | ARIT-A | 1.9 |
3. | Załącznik B do ARIT - Standardy parametrów oprogramowania infrastrukturalnego | ARIT-B | 2.5 |
4. | Załącznik C do ARIT - Standardy parametrów technicznych urządzeń teleinformatycznych | ARIT-C | 2.8 |
5. | Załącznik D do ARIT - Wsparcie dla klas bezpieczeństwa i systemów informatycznych | ARIT-D | 1.6 |
L.p. | Nazwa | Oznaczenie | Wersja |
6. | Załącznik E do ARIT - Standardy proceduralne i dokumentacyjne | ARIT-E | 1.9 |
7. | Specyfikacja konfiguracji bloków architektonicznych | ARIT-4 | 0.05 |
8. | Standard określania klasy bezpieczeństwa systemu informatycznego resortu finansów | ARIT-3 | 2.0 |
9. | Standard określania klasy systemu informatycznego resortu finansów | ARIT-2 | 2.0 |
10. | Szablon Projektu Infrastruktury Teleinformatycznej Systemu | ITS (EDIT-5) | 0.05 |
11. | Klasyfikacja Komponentu SISC | EDIT-6 | 0.03 |
12. | Szablon Planu testów, wraz z załącznikami (szablonami): 1. Scenariusze testowe 2. Dane testowe 3. Przypadki testowe 4. Raport z testów 5. Skrócony raport z testów 6. Listy kontrolne dla testów | EDIT-7 | 1.0 1.0 1.0 1.0 1.0 1.0 0.19 |
13. | Podręcznik Użytkownika Systemu TestReg_Mantis 1. Formularz zgłoszenia użytkownika 2. Formularz awaryjnego zgłoszenia z testów | EDIT-8 | 2.0 |
14. | Podręcznik operatora III Linii Wsparcia | EDIT-9 | 0.7 |
15. | Wniosek o utworzenie operatora III Linii Wsparcia | EDIT-10 | - |
16. | Formularz parametryzacji narzędzia SD | EDIT-11 | - |
17. | Warunki gwarancji HARF | EDIT-12 | - |
18. | Lista Kontrolna – realizacja wymagań WCAG 2.0 | EDIT-13 | 0.1 |
19. | Plan Realizacji Umowy. Strategia testowania. | EDIT-14 | - |
20. | Wymagania dla budowanych i modernizowanych komponentów SISC wynikające ze Studium Wykonalności PUESC | EDIT-15 | 0.2 |
Tabela 2. Krajowa dokumentacja referencyjna udostępniana w ramach SIWZ
1.2.2. Dokumentacja systemu ZISAR udostępniana w ramach SIWZ
Zamawiający w ramach realizowanego postępowania udostępni na wniosek niżej wymienioną dokumentację pod warunkiem złożenia oświadczenia o zachowaniu poufności ( załącznik I do SIWZ). W zakresie dokumentacji systemu ZISAR, od momentu rozpoczęcia świadczenia przez Wykonawcę Usługi Utrzymania Systemu oraz Usługi Rozwoju, Wykonawca zobowiązany będzie do jej aktualizacji, aż do momentu dostarczenia dokumentacji dla Systemu, wytworzonej dla oprogramowania dostarczonego w ramach Etapu III związanego z odbiorem, o którym mowa w załączniku nr 3 do Umowy. Dodatkowo, w oparciu o inwentaryzację z natury przeprowadzoną przed rozpoczęciem świadczenia Usługi Utrzymania, Wykonawca uzupełni i zaktualizuje poniższą dokumentację, uwzględniając w niej wszystkie zidentyfikowane właściwości Systemu.
L.p. | Nazwa | Oznaczenie | Wersja |
Ogólne | |||
1. | Wyciąg ze Studium Wykonalności Projektu PUESC | SW | 30.08.2017 v. 1.00 |
Dokumenty związane z Projektem ZISAR | |||
1. | Szczegółowa Specyfikacja Systemu ZISAR | SSS | Wersja 4.0 z dnia 28.11.2014 roku |
2. | Podręcznik Administratora Systemu | PAS | Wersja 5.0 z dnia 11.09.2014 roku |
3. | Dokumentacja Administratora Technicznego | DAT | Wersja 5.0 z dnia 31.10.2014 |
4. | Dokumentacja Administratora Merytorycznego | DAM | Wersja 5.0 z dnia 31.10.2014 |
5. | Dokumentacja użytkownika systemu ZISAR | DUS | wersja 6.4 z dnia 27.09.2016 |
6. | Standard Komunikacji | SK | wersja 7.2 z dnia 09.07.2015 |
7. | Zbiór zrealizowanych Wniosków Zmian | ZWZ | z dnia 19.06.2018 |
Dokumenty związane z Projektem ZISAR II | |||
1. | Infrastruktura Teleinformatyczna Systemu | ITS | Wersja 1.1 z dnia 09.03.2018 |
2. | Zbiór specyfikacji szczegółowych ZISAR II | ZSS | z dnia 19.06.2018 |
Dodatkowo komplet dokumentacji powykonawczej i eksploatacyjnej dostarczonej w ramach realizacji Umowy na ZISAR II po jej odbiorze przez Zamawiającego, na który będą składały się dokumenty: | |||
1. | Standardy Komunikacji | SK | Wersja 8.1 z dnia 14.06.2018 |
2. | Podręcznik Użytkownika | PodrUżytk_ZIS AR II | |
3. | Podręcznik Administratora Technicznego | PodrAdmTech_ ZISAR II | |
4. | Podręcznik Administratora Merytorycznego | PodrAdmMeryt_ ZISAR II | |
Tabela 3. Dokumentacja udostępniona w ramach SIWZ
1.3. Dokumentacja dodatkowa przekazywana po zawarciu Umowy
Zamawiający dostarczy Wykonawcy po zawarciu Umowy dokumentację, w wersjach aktualnych na dzień podpisania Umowy pozyskaną w ramach dostawy dokumentacji poprojektowej w ramach obecnej realizacji umowy uzupełniającej ZISAR II.
L.p. | Nazwa | Oznaczenie | Wersja |
Ogólne | |||
Dokumenty związane z Projektem ZISAR/ZISAR II | |||
1. | Dokumentacja powykonawcza infrastruktury technicznej systemu ZISAR” (zał C13 do OPZ) | Wersja 1.0 z dnia 20.11.2014 | |
2. | Dokumentacja architektury systemu Informatycznego” (zał C5 do OPZ) | Wersja 1.0 z dnia | |
3. | Dokumentacja bezpieczeństwa” (zał C17 do OPZ) | Wersja 1.0 z dni 31.10.2014 | |
4. | Powykonawcza Specyfikacja Techniczna ZISAR-II | PST_ZISAR II | |
5. | Dokumentacja Bezpieczeństwa ZISAR II | DokBezp_ZISAR II | |
6. | Dokumentacja Eksploatacyjna ZISAR II, która będzie zawierać procedury awaryjne oraz instrukcje, plany i procedury gwarancji oraz wsparcia utrzymania | DokEkspl_ZISAR II | |
7. | Kody źródłowe oprogramowania | ||
Tabela 4. Dokumentacja dodatkowa udostępniona po podpisaniu umowy
1.4. Dokumentacja dotycząca bezpieczeństwa informacji
1.4.1. Wykonawca wytwarzając System jest obowiązany do przestrzegania obowiązujących przepisów prawa krajowego i wspólnotowego określających wymogi związane z bezpieczeństwem informacji, w tym w szczególności:
▪ ROZPORZĄDZENIE PARLAMENTU EUROPEJSKIEGO I RADY (UE) 2016/679 Z DNIA 27 KWIETNIA 2016 R. W SPRAWIE OCHRONY OSÓB FIZYCZNYCH W ZWIĄZKU Z PRZETWARZANIEM DANYCH OSOBOWYCH I W SPRAWIE SWOBODNEGO PRZEPŁYWU TAKICH DANYCH ORAZ UCHYLENIA DYREKTYWY 95/46/WE (OGÓLNE ROZPORZĄDZENIE O OCHRONIE DANYCH)
Zgodnie z art. 99 ogólnego rozporządzenia o ochronie danych, rozporządzenie wchodzi w życie 20 dnia po publikacji w Dzienniku Urzędowym UE, a będzie stosowane od dnia 25 maja 2018 r.
▪ Ustawa z dnia 10.05.2018 roku o ochronie danych osobowych (Dz.U. poz.1000)
30.11.2014
a
▪ Rozporządzenie Ministra Spraw Wewnętrznych i Administracji w sprawie dokumentacji przetwarzania danych osobowych oraz warunków technicznych i organizacyjnych, jakim powinny odpowiadać urządzenia i systemy informatyczne służące do przetwarzania danych osobowych
▪ Ustawa o informatyzacji działalności podmiotów realizujących zadania publiczne
▪ Rozporządzenie Rady Ministrów w sprawie Krajowych Ram Interoperacyjności, minimalnych wymagań dla rejestrów publicznych i wymiany informacji w postaci elektronicznej oraz minimalnych wymagań dla systemów teleinformatycznych
1.4.2. Dokumenty regulujące ewentualne pozostałe wymogi dotyczące bezpieczeństwa informacji, wynikające z aktów wewnętrznych resortu, procedur i wytycznych, zostaną przekazane Wykonawcy po podpisaniu Umowy.
2. Wymagania jakościowe dla dokumentacji
W.1. Język dokumentów:
Wszystkie dokumenty muszą być dostarczone w języku polskim z zachowaniem ogólnie przyjętych zasad poprawności językowej. Dopuszczalne jest przywołanie cytatów w języku angielskim, nazw lub tytułów dokumentów opracowanych w języku angielskim z dokładnym podaniem źródła, bez konieczności tłumaczenia.
W.2. Forma dokumentów:
Wszystkie dokumenty muszą być sporządzone i dostarczone w formie elektronicznej w formacie plików zgodnych z programem MS Word 97 – 2003 lub jego wyższymi wersjami oraz w jednym egzemplarzu w formie papierowej.
W.3. Medium transportowe:
Poczta elektroniczna lub, za zgodą Zamawiającego, publikacja na udostępnionym przez Wykonawcę serwerze SFTP + jeden egzemplarz w wersji papierowej przekazywany osobiście lub za pośrednictwem kuriera. W przypadku dokumentów, których rozmiar uniemożliwia przekazanie za pośrednictwem poczty elektronicznej, Wykonawca jest zobowiązany do ich dostarczenia na nośniku optycznym lub pamięci USB.
W.4. Nazewnictwo
Nazwa pliku dokumentu składa się z symboli oraz wersji, oddzielonych kreskami
(projekt_system_rodzaj_w_1_00_datawydania):
- projekt- kod nadany projektowi (PUESC.P7.1)
system – kod systemu (ZISAR)
rodzaj – kod określający tematykę jakiej dotyczy produkt (np. TCH)
wersja – numer wersji wydania dokumentu (np. w_1_00)
data wydania – data wydania dokumentu w formacie RRRRMMDD (np.: 20171030).
W.5. Oznaczanie
Mając na uwadze zobowiązania wynikające z porozumienia o dofinansowanie projektu
Dokumentacja ma być oznaczana również zgodnie z zasadami określonymi w Podręczniku identyfikacji wizualnej Ministerstwa Finansów i Krajowej Administracji Skarbowej.
W.6. Format typograficzny dokumentu
Typografia dokumentu określa układ drukarski treści dokumentu oraz zastosowane kroje i typy czcionek i ich funkcje w tekście.
Poniżej zamieszczono opis formatu każdego z elementów typograficznych.
W.6.1. Marginesy
Lewy: 2,5 cm
Prawy: 2 cm
Górny: 2,5 cm
Dolny: 3 cm
W.6.2. Format strony
A4 - orientacja pionowa
Dopuszczalny jest większy format strony i/lub orientacja dla załączników do dokumentu, w przypadku konieczności zapewnienia czytelności zamieszczonych informacji, np. diagramy
W.6.3. Tytuły rozdziałów i sekcji
Nagłówki sekcji, rozdziałów i podrozdziałów zawierają zagnieżdżaną numerację konspektu. Odpowiednio style nagłówkowe są wyróżnione od zwykłego tekstu rodzajem i wielkością czcionki. Nagłówki wyróżnione są czcionką Arial Black.
W.6.4. Tekst
Tekst pisany jest czcionką Xxxxx, rozmiar 11.
Tekst wyrównany jest do lewego i prawego marginesu (wyjustowany).
W.6.5. Uwagi
Uwagi wyróżniane są pogrubianym słowem „Uwaga“ i znakiem „!“.
W.6.6. Rysunki
Rysunki powinny mieścić się w marginesach dokumentu, wyśrodkowane w poziomie.
W.6.7. Podpis pod rysunkiem
Rysunki są numerowane w sposób ciągły w obrębie całego dokumentu. Podpis rysunku zapisany jest pochyłą czcionką Arial o rozmiarze 9.
W.6.8. Tabela
Krawędzie tabel oznaczone są czarną linią standardowej szerokości. Nagłówek tabeli zapisany jest pogrubioną czcionką Arial o rozmiarze 10, tekst nagłówka wyśrodkowany jest w poziomie i
pionie w obrębie komórek. Tekst w tabeli zapisany jest czcionką Arial o rozmiarze 10, wyśrodkowany w pionie oraz wyrównany do lewego i prawego marginesu w obrębie komórek. Wyliczenia w tabeli oznaczone są kropkami i wcięciami. Rozmiar tabel jest dostosowany do ich zawartości. Tabela mieścić się powinna w marginesach dokumentu. W tabelach dzielonych na kilka stron, należy wiersz nagłówka tabeli powtórzyć na początku każdej strony.
W.6.9. Podpis pod tabelą
Tabele są numerowane w sposób ciągły w obrębie całego dokumentu. Podpis tabeli zapisany jest pochyłą czcionką Arial o rozmiarze 9.
W.6.10. Wyliczenia
Dla wyliczeń stosowany jest znak kropki bądź cyfra i odpowiednie wcięcie zależnie od poziomu wyliczenia.
W.6.11. Przypisy
Przypisy są numerowane w sposób ciągły w obrębie całego dokumentu. Ich oznaczenie w tekście jest zgodne co do formatu z tekstem, w którym je zamieszczono. Tekst przypisu pisany jest czcionką Xxxxx, rozmiar 9.
W.7. Układ dokumentacji:
W.7.1. Układ nagłówka i stopki dokumentu
Poniżej zamieszczono wzór układu nagłówka dokumentu
Poniżej zamieszczono wzór układu stopki dokumentu
W.7.2. Strona tytułowa
Strona tytułowa zawiera nazwę systemu, nazwę podsystemu (jeżeli dotyczy), nazwę dokumentu oraz jego wersję. Elementy te znajdować się powinny w środkowej części strony, wyrównane do prawej krawędzi tekstu, zapisane czcionką Arial Black.
W.7.3. Metryka dokumentu
Metryka dokumentu zawiera nazwę systemu, dane wykonawcy, nazwę właściciela systemu, nazwę produktu, listę autorów dokumentu (imię i nazwisko oraz inicjały), nazwę pliku dokumentu i liczbę stron dokumentu.
Poniżej zamieszczono wzór metryki dokumentu.
Nazwa systemu | |||
Właściciel systemu | Ministerstwo Finansów–Departament Kontroli i Analiz | ||
Wykonawca | |||
Produkt | |||
Autorzy | Xxx Xxxxxxxx (JK) | ||
Plik - nazwa | Liczba stron | ||
W.7.4. Historia zmian dokumentu
Tabela historii zmian w dokumencie zawiera: numer edycji i rewizji (wersję) dokumentu, datę wydania wersji dokumentu, opis podający powód powstania kolejnej wersji dokumentu, operacje, jakich dokonano na dokumencie oraz wykaz zmienionych rozdziałów, inicjały autora zmian oraz datę kontroli jakości.
Poniżej zamieszczono wzór Historii zmian dokumentu.
Edycja i rewizja | Data wydania | Opis | Akcja (*) | Rozdział y (**) | Autorz y (***) | Data Kontroli Jakości |
0.01 | 2011-03-25 | Utworzenie dokumentu | W | W | JK | 2011-11-11 |
0.02 | 2011-03-29 | Weryfikacja treści dokumentu | W,We | W | JK | 2011-11-30 |
(*) Akcje: W = Wstaw, Z = Zamień, We = Weryfikuj, N = Nowy (**) Rozdziały: W = Wszystkie
(***) Autorzy: Inicjały – szczegóły w Metryce dokumentu
W.7.5. Spisy treści, tabel oraz rysunków
Każdy dokument musi zawierać co najmniej 3 poziomowy spis treści oraz spisy zamieszczonych w dokumencie tabel i rysunków ponumerowanych w kolejności w ramach całego dokumentu. Spisy muszą zawierać odniesienia do numerów stron.
W.7.6. Wstęp
W.7.6.1. Cel dokumentu
Ta sekcja zawiera określenie przeznaczenia dokumentu oraz wszystkich istotnych zadań, jakie ma on spełniać.
W.7.6.2. Zastosowanie
W tej sekcji należy opisać zakres tematyczny, do której odnosi się tworzony dokument.
W.7.6.3. Dokumenty obowiązujące i pomocnicze
Sekcja ta zawiera odniesienie do dokumentów obowiązujących, czyli takich, które muszą być wyraźnie wymienione w dokumencie, a zawierają wymagania obowiązujące przy tworzeniu dokumentu (wymagania, które muszą być spełnione i których spełnienie można zweryfikować) oraz do dokumentów pomocniczych, czyli takich, które mogą być wymienione w tekście dokumentu i nie zawierają obowiązujących wymagań. Odwołania do dokumentów powinny być jednoznaczne.
Poniżej zamieszczono wzór tabeli dokumentów obowiązujących i pomocniczych.
Lp. | ID | Nazwa | Oznaczenie | Wersja | Data |
1 | D01 | PUESC.P7.1- Założenia Projektu | PUESCDKA71- ZPR | 2.00 | 2016-07-09 |
2 | D02 | PUESC.P7.1 - Plan Etapu Inicjowania Projektu | PUESCDKA71- PLE | 2.00 | 2016-07-09 |
W poszczególne kolumny wprowadza się następujące dane: Lp. - liczba porządkowa pozycji,
ID - identyfikator dokumentu, którym posługiwać się będzie autor w tekście, Nazwa – Nazwa dokumentu np. Plan Umowy,
Oznaczenie - literowy symbol dokumentu, np. PUESCDKA71-WMG, Wersja - Wersja dokumentu np. 1.01.
Data – Data wydania wersji dokumentu np. 2016-11-12
W.7.6.4. Słownik przyjętych skrótów, akronimów i definicji
Dokumenty powinny zawierać dwa wykazy: „Używane skróty i akronimy” oraz „Definicje”. Oba wykazy zawierają odpowiednio wyjaśnienia skrótów i akronimów oraz objaśnienia terminów stosowanych w danym dokumencie w zakresie tematycznym obejmującym tworzony dokument. Wykazy należy posegregować alfabetycznie. Słownik skrótów, akronimów i definicji musi być jednolity we wszystkich dostarczanych dokumentach i ma być zgodny z terminologią przyjętą przez Zamawiającego w dokumentacji przetargowej i Umowie. W szczególnie uzasadnionych wypadkach, za zgodą Zamawiającego, możliwa jest zmiana przyjętych definicji.
Poniżej zamieszczono wzór tabeli skrótów i akronimów.
Skrót / Akronim | Opis |
Poniżej zamieszczono wzór tabeli definicji.
Definicja | Opis |
W.7.6.5. Zawartość merytoryczna dokumentu
Ta część prezentuje merytoryczną zawartość dokumentu oraz znaczenie poszczególnych rozdziałów, może także sugerować sposób korzystania z dokumentu. Zawartość dokumentu można przedstawić w postaci diagramu lub w postaci oddzielnych opisów odnoszących się do poszczególnych rozdziałów.
W.7.7. Sekcje zawierające treść dokumentu
Sekcje te zawierają treść dokumentu. Jeżeli dla jakiegoś typu dokumentu został określony szczegółowy opis wymaganej zawartości i/lub szablon, to tematyka poszczególnych sekcji dokumentu musi być zgodna z tym opisem i/lub szablonem. Jeśli dla jakiegoś dokumentu zostały określone wymagania z nim związane, to tematyka poszczególnych sekcji dokumentu musi spełniać te wymagania.
W.7.7.1. Wartość użytkowa
W oparciu o treść dokumentu możliwe jest efektywne użytkowanie produktów, wykonywanie opisywanych funkcji, weryfikacja realizacji wymagań, realizacja testów, a także opracowanie i wdrażanie kolejnych produktów.
W.7.7.2. Kompletność
Dostarczane dokumenty muszą w sposób wyczerpujący opisywać całość przedstawianego zagadnienia bez braków, które mogłyby utrudniać lub uniemożliwiać poznanie i weryfikację tych zagadnień.
W.7.7.3. Spójność
Dokumenty nie mogą zawierać informacji sprzecznych, powtarzających się, nieistotnych lub nie mających związku z zagadnieniem merytorycznym, którego dotyczą. Treści zawarte w całości wytwarzanej dokumentacji muszą być wzajemnie logicznie powiązane.
Liczba rozdziałów, podrozdziałów i sekcji powinna być uzależniona od charakteru i poziomu szczegółowości zagadnienia, któremu poświęcony jest dokument. Podział dokumentu na części podrzędne, musi być przejrzysty i logicznie spójny umożliwiający bezproblemowe wyszukiwanie informacji w tekście.
We wszystkich dokumentach musi być stosowane jednolite nazewnictwo i terminologia.
Odwołania do innych dokumentów wskazują dokładnie ich wersję oraz miejsce odniesienia. Dokument musi być spójny wewnętrznie jak i z pozostałą dokumentacją (w tym z dokumentami powiązanymi).
W.7.7.4. Aktualność
Treść dokumentacji musi być zgodna z wytworzonymi produktami. Dokumentacja musi być aktualizowana stosownie do modyfikacji produktów wprowadzonych w wyniku zmian.
W.8. Wersjonowanie dokumentacji
Numer wersji dokumentu składa się z dwóch liczb naturalnych (numer główny i numer poboczny
- kolejny numer i numer poboczny – dwucyfrowy kolejny numer, liczony od 00 dla każdego
kolejnego numeru głównego) rozdzielonych kropką oraz opcjonalnego znacznika wersji roboczej dokumentu – status dokumentu ‘Roboczy’.
Każde przekazanie dokumentu od jego autora do kogokolwiek oznacza zamrożenie wersji dokumentu, nawet wersji roboczej. Nie jest dopuszczalne dokonywanie zmian w zamrożonej wersji dokumentu bez zaznaczenia zmiany wersji dokumentu.
Jakiekolwiek modyfikacje dokumentu wymuszają podniesienie wersji dokumentu (zwiększenie numeru pobocznego wersji). Zatwierdzenie dokumentu także wymusza podniesienie wersji dokumentu (zwiększenie numeru głównego) oraz usunięcie znacznika dokumentu roboczego. Każdy dokument w wersji roboczej musi posiadać znacznik dokumentu roboczego zaznaczony w metryce dokumentu.
Każda zmiana wersji dokumentu wiąże się z opisaniem w metryce dokumentu zakresu wprowadzonych modyfikacji – streszczenia zmian. Nie jest dopuszczalna zmiana wersji dokumentu bez jasnego i zwięzłego streszczenia wprowadzonych zmian.
Wszelkie zmiany w dokumentacji dokonywane są w trybie śledzenia zmian np. MS Word Dopiero akceptacja dokumentu jest równoznaczna z wyłączeniem tego trybu.
3. Wykaz szablonów dokumentów (zał. 4a do Umowy)
Szablon nr 1 do Załącznika nr 4a „Specyfikacja Procesów Biznesowych Systemu” Szablon nr 2 do Załącznika nr 4a „Specyfikacja Wymagań Systemu Informatycznego” Szablon nr 3 do Załącznika nr 4a „Mapa Wymagań Systemu”
Szablon nr 4 do Załącznika nr 4a „Projekt Infrastruktury Teleinformatycznej Systemu” Szablon nr 5 do Załącznika nr 4a „Projekt Realizacji Systemu Informatycznego” Szablon nr 6 do Załącznika nr 4a „Projekt Interfejsu Użytkownika”
Szablon nr 7 do Załącznika nr 4a „Plan Integracji Systemu” Szablon nr 8 do Załącznika nr 4a „Plan Wdrożenia Systemu” Szablon nr 9 do Załącznika nr 4a „Specyfikacja Migracji danych”
Szablon nr 10 do Załącznika nr 4a „Dokumentacja Architektury Systemu Informatycznego” Szablon nr 11 do Załącznika nr 4a „Podręcznik Administratora Systemu”
Szablon nr 12 do Załącznika nr 4a „Dokumentacja Bezpieczeństwa” Szablon nr 13 do Załącznika nr 4a „Pakiet Kodów Źródłowych”
Szablon nr 14 do Załącznika nr 4a „Opis Kontraktu Dla Usługi Udostępnianej na PI MF” Szablon nr 15 do Załącznika nr 4a „Podręcznik Użytkownika Systemu Informatycznego” Szablon nr Z1 do Załącznika nr 4a „Plan Zarządzania Wymaganiami”
Szablon nr Z2 do Załącznika nr 4a „Plan Zarządzania Konfiguracją Oprogramowania”
4. Wykaz wymagań w zakresie minimalnej zawartości dokumentów (w przypadku dokumentów posiadających szablony jest to wykaz zawartości dodatkowej w stosunku do określonej w tych szablonach)
Identyfikator | Szczegóły |
Identyfikator | Szczegóły |
WD01 | Minimalna zawartość dokumentu - Podręcznik Administratora: 1. Zawartość określona w ogólnych wymaganiach dotyczących dokumentacji. 2. Wyodrębnione części dokumentu dla administratora technicznego i merytorycznego. 3. Ogólna charakterystyka (cel systemu, sposób przesyłania komunikatów z diagramami przebiegu przetwarzania wszystkich komunikatów z opisem, gdzie należy szukać informacji o powodzeniu danego etapu przetwarzania, generowaniu zwrotnych komunikatów, odbiorze komunikatów, przeglądanie repozytorium komunikatów, współpraca z innymi systemami ujęta w diagramach przebiegu). 4. Wymagania platformy sprzętowo-programowej i platformy programowej (minimalne wymagania sprzętowe dla każdego komponentu, licencje). 5. Instalacja i konfiguracja systemu (kolejność i poszczególne kroki instalacyjne umożliwiające odtworzenie systemu, pełna instalacja i konfiguracja wszystkich komponentów, opis każdego instalowanego elementu, parametryzacja). 6. Lista wszystkich składników wymaganych do instalacji każdego komponentu, z podaniem producenta, wersji. 7. Weryfikacja poprawności instalacji. 8. Aktualizacja oprogramowania. 9. Obsługa podstawowa systemu, opis dla administratorów dziedzinowych oraz technicznych (konfigurowanie oraz obsługa komunikacji wybranego systemu), czynności administracyjne (zarządzanie użytkownikami, zarządzanie parametrami, przeglądanie raportów, monitorowanie logów, nadzór nad wielkością baz danych, czynności cykliczne itp.). 10. Obsługa awaryjna systemu (sprawdzanie poprawności działania wszystkich komponentów logicznych i infrastrukturalnych, sposób postępowania w przypadku awarii komponentu/komponentów, przywracanie systemu do normalnej pracy po awarii), wyszukiwanie komunikatów (w bazach danych, logach systemu, itp.) na podstawie ich identyfikatorów na każdym etapie ich przetwarzania opisanym w diagramach przebiegu. 10.1. Procedura odtworzenia baz danych z kopii zapasowej – ze stratą danych, zawierająca czynności prowadzące do minimalizacji wpływu awaryjnego odtworzenia na realizowane procesy biznesowe. 10.2. Zarządzanie użytkownikami. |
WD03 | Specyfikacja publiczna musi być podzbiorem specyfikacji pełnej i zawierać tylko komunikaty służące do komunikacji z użytkownikami zewnętrznymi. Minimalna zawartość dokumentu - Specyfikacja Techniczna XML: 1. Zawartość określona w ogólnych wymaganiach dotyczących dokumentacji. 2. Wymagana wiedza, przyjęte konwencje, objaśnienia stosowanych diagramów, pakietów, komponentów, klas, atrybutów, itp. 3. Komunikaty XML a. Rola komunikatu b. Struktura komunikatu c. Zawartość informacyjna d. Reguły e. Schemat f. Przykłady |
WD04 | Minimalna zawartość dokumentu - Projekt Infrastruktury Teleinformatycznej Systemu: 1. Dokument musi zawierać elementy określone w ogólnych wymaganiach |
Identyfikator | Szczegóły |
dotyczących dokumentacji. 2. Techniczna architektura referencyjna systemów informatycznych resortu finansów wymaga, aby były budowane z wykorzystaniem dedykowanych dla nich zestandaryzowanych elementów, nazywanych blokami architektonicznymi. Pozostałe usługi informatyczne, niezbędne do prawidłowego działania bloków architektonicznych oraz osadzonych w nich komponentów aplikacyjnych zapewniają współdzielone Systemy Infrastrukturalne. Techniczna architektura referencyjna składa się z następujących elementów: 3. Architektura referencyjna środowiska IT CPD MF wraz z załącznikami: 3.1. Załącznik A – Bloki architektoniczne środowiska teleinformatycznego 3.2. Załącznik B – Standardy parametrów oprogramowania infrastrukturalnego 3.3. Załącznik C – Standardy parametrów technicznych urządzeń teleinformatycznych 3.4. Załącznik D – Wsparcie dla klas bezpieczeństwa i systemów informatycznych 3.5. Załącznik E – Standardy proceduralne i dokumentacyjne 4. Specyfikacja konfiguracji bloków architektonicznych. 5. Standard określania klasy bezpieczeństwa systemu informatycznego resortu finansów. 6. Standard określania klasy systemu informatycznego resortu finansów. 7. Wykonawca na podstawie Technicznej architektury referencyjnej opracuje i uzgodni z Zamawiającym Projekt Infrastruktury Teleinformatycznej Systemu ZISAR zmodernizowanego w trakcie realizacji ZISAR umowy ZISAR PLUS zgodnie z zakresem i formą przekazanego dokumentu - „Szablon Projektu Infrastruktury Teleinformatycznej Systemu” załącznik nr 5 EDIT (Projekt ITS). 8. Wykonawca w Projekcie Infrastruktury Teleinformatycznej Systemu ZISAR, zgodnie z przyjętą architekturą referencyjną przedstawi listę bloków architektonicznych (wybranych z katalogu znajdującym się w załączniku A ARIT - Bloki architektoniczne środowiska teleinformatycznego), które będą stanowiły zakres Infrastruktury technicznej, na której w kolejnym etapie zbuduje, uruchomi, przetestuje, wdroży wszystkie środowiska Systemu ZISAR oraz będzie gwarantował ich prawidłowe funkcjonowanie. 9. Wykonawca podczas tworzenia Projektu Infrastruktury Teleinformatycznej Systemu ZISAR zmodyfikowanego w trakcie realizacji umowy ZISAR PLUS musi zoptymalizować Infrastrukturę techniczną. Wyspecyfikowana przez Wykonawcę lista bloków architektonicznych musi mieć uzasadnianie wynikające z wymagań postawionych przez Zamawiającego w stosunku do budowanego Systemu ZISAR. 10. Projekt Infrastruktury Teleinformatycznej Systemu musi zawierać opis wszystkich środowisk Systemu ZISAR. 11. W Projekcie Infrastruktury Teleinformatycznej systemu Wykonawca między innymi wyspecyfikuje: 12. Usługi dostępowe zgodnie z definicjami usług dostępowych SMTP, HTTP. 13. Oprogramowanie serwerów aplikacyjnych zgodnie z definicjami aplikacyjnych bloków architektonicznych. 14. Oprogramowanie baz danych zgodnie z definicjami bazodanowych bloków architektonicznych. 15. Wykonawca do wybranych bloków architektonicznych systemów operacyjnych może przypisać jedynie: 16. Oprogramowanie wytworzone przez Wykonawcę w celu zbudowania, uruchomienia, przetestowania, wdrożenia i gwarantowania prawidłowego funkcjonowania wszystkich środowisk Systemu ZISAR, 17. Inne, niż określone w definicjach aplikacyjnych bloków architektonicznych, oprogramowanie serwerów aplikacyjnych zintegrowanych z Oprogramowaniem typu COTS. |
Identyfikator | Szczegóły |
18. Wykonawca w Projekcie Infrastruktury Teleinformatycznej Systemu ZISAR zmodyfikowanego w trakcie realizacji umowy ZISAR PLUS musi przedstawić techniczną architekturę docelową Systemu ZISAR w oparciu o bloki architektoniczne i usługi określone w dokumencie załączniku A ARIT: Bloki architektoniczne środowiska teleinformatycznego 19. W przypadku użycia komponentów programowych innych niż zdefiniowane w blokach architektonicznych Wykonawca musi zastosować się do poniższych zasad: 20. Wykonawca musi przedefiniować blok architektoniczny, w którym zamierza użyć komponentów innych niż wskazane przez Zamawiającego, zastępując wersję oryginalną wersją przedefiniowaną z zastrzeżeniem utrzymania niezmienionej liczby bloków architektonicznych opisanych w dokumencie w załączniku A ARIT: Bloki architektoniczne środowiska teleinformatycznego 21. Przedefiniowany przez Wykonawcę blok architektoniczny musi spełniać wszystkie wymagania wyspecyfikowane dla wersji oryginalnej bloku architektonicznego. 22. Wykonawca przedefiniowując blok architektoniczny nie może rozszerzyć jego przeznaczenia, na przykład nie jest dozwolone łączenie w ramach jednego bloku architektonicznego funkcjonalności bloku architektonicznego zapewniającego usługi relacyjnej bazy danych i funkcjonalności bloku architektonicznego zapewniającego usługi serwera aplikacyjnego zgodnego ze standardem JEE. 23. Zamawiający dopuszcza wykorzystanie przez Wykonawcę fizycznych bloków architektonicznych jedynie w środowiskach Systemu ZISAR zaklasyfikowanych jako system klasy BX. | |
WD06 | Minimalna zawartość dokumentu - Podręcznik Użytkownika: 1. Dokument musi zawierać elementy określone w ogólnych wymaganiach dotyczących dokumentacji. 2. Dokumentacja „Podręcznik Użytkownika” musi zawierać opis wszystkich funkcji dostępnych dla użytkownika, zaimplementowanych w systemie. 3. Dokumentacja „Podręcznik Użytkownika” ma systematyzować zagadnienia związane z obsługą funkcji systemu, ułatwiając ich zrozumienie i opanowanie obsługi. 4. Obsługa zagadnień w systemie zostanie opatrzona stosownymi przykładami ilustrującymi wymagane działania użytkownika |
WD07 | Minimalna zawartość dokumentu – Model Danych: 1. Dokument musi zawierać elementy określone w ogólnych wymaganiach dotyczących dokumentacji. 2. Wykonawca opracuje Model Danych w zakresie: a. danych rejestrowanych w systemie podczas obsługi procesów biznesowych b. danych zawartych w komunikatach XML obsługiwanych przez system. 3. Model danych powinien zawierać: a. Hierarchiczny model klas b. Diagram modelu klas c. Nazwy i zawartość klas d. Mapowanie atrybutów klas do elementów xml, dla danych stosowanych w komunikatach xml e. Opis danych i przynależność danych do klas f. Mapowanie klas i atrybutów klas do nazw tabel i pól w bazie danych. g. Diagram związków encji (ERD) dla danych znajdujących się w bazie danych. h. Listę dopuszczalnych wartości lub odwołanie do słownika dopuszczalnych wartości dla każdej danej (atrybutu klasy, elementu XML, pola w bazie |
Identyfikator | Szczegóły |
danych) jeśli dana może zawierać wartości zesłownikowane. i. Hierarchiczny diagram struktury danych komunikatów | |
WD08 | Minimalna zawartość dokumentu - Specyfikacja Techniczna Systemu ZISAR zmodyfikowanego w trakcie realizacji umowy ZISAR PLUS (Standard Komunikacji): 1. Dokument musi zawierać elementy określone w ogólnych wymaganiach dotyczących dokumentacji. 2. Wymagana wiedza, przyjęte konwencje, objaśnienia stosowanych diagramów, pakietów, komponentów, klas, atrybutów, itp. 3. Model wdrożeniowy dla usługi Analizy Ryzyka w ramach oczekiwanej integracji z systemem transakcyjnym SISC, wymagania odnośnie interfejsów systemów klienckich, przepływów ruchu sieciowego. 4. Specyfikacje Techniczne wszystkich kanałów komunikacyjnych dotyczących komunikacji pomiędzy systemem ZISAR i systemami zewnętrznymi, zawierające minimum: 4.1. Szczegółowy opis kierunków i kanału komunikacji, 4.2. Opis operacji biznesowych w każdym zaprojektowanym kierunku komunikacji, 4.3. Opis struktury danych w każdym zaprojektowanym kierunku komunikacji, 4.4. Diagramy struktur danych, przepływy komunikatów/dokumentów, 4.5. Przykłady komunikatów, |
Tabela 5. Wykaz wymagań w zakresie minimalnej (dodatkowe) zawartości dokumentów