CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska tel: +48 22 597-09-27 • fax: +48 22 597-09-37 [email protected]• www.csioz.gov.pl Skrytka ESP: /csiozgovpl/SkrytkaESP 1 Załącznik nr 3 Koncepcja Architektury Spis Treści Załącznik nr................................................................................................................................................... 1 Koncepcja Architektury .............................................................................................................................. 1 1 Wprowadzenie .............................................................................................................................................. 2 1.1 Cel dokumentu .................................................................................................................................... 2 1.2 Zakres ................................................................................................................................................. 2 1.3 Definicje .............................................................................................................................................. 2 1.4 Założenia niefunkcjonalne .................................................................................................................. 2 2 Architektura Aplikacji ................................................................................................................................ 18 2.1 Technologie ....................................................................................................................................... 21 2.2 Podsystemy i komponenty ............................................................ Błąd! Nie zdefiniowano zakładki. 2.3 Perspektywy systemu ....................................................................................................................... 23 2.3.1 Perspektywa danych ......................................................................................................................... 23 2.3.2 Perspektywa dokumentów ................................................................................................................ 24 2.3.3 Perspektywa bezpieczeństwa – dostępy, protokoły ......................................................................... 24 3 Specyficzne warunki i ograniczenia ........................................................................................................ 24 3.1 Problemy i ograniczenia technologiczne w oprogramowaniu standardowym .................................. 24
24
Embed
Koncepcja Architektury - csioz.gov.pl · Koncepcja architektoniczna zawiera wszelkie wymagania dotyczące architektury systemu dla wytwarzanego oprogramowania. Dokument jest aktualizowany
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
Załącznik nr ................................................................................................................................................... 1
Koncepcja Architektury .............................................................................................................................. 1
1 Wprowadzenie .............................................................................................................................................. 2
1.1 Cel dokumentu .................................................................................................................................... 2
2.1 Technologie ....................................................................................................................................... 21
2.2 Podsystemy i komponenty ............................................................ Błąd! Nie zdefiniowano zakładki.
2.3 Perspektywy systemu ....................................................................................................................... 23
2.3.1 Perspektywa danych ......................................................................................................................... 23
1 Wprowadzenie Koncepcja architektoniczna przedstawia całość systemu e-Krew i jego powiązanie z innymi systemami. Dokument opisuje założenia niefunkcjonalne oraz podstawowe standardy techniczne wykonania systemu. Przedstawione są w szczególności podsystemy i komponenty systemu oraz sposób komunikacji z innymi systemami.
1.1 Cel dokumentu
Celem dokumentu jest przedstawienie technicznych aspektów systemu. Dokument stanowi element OPZ (Opis Przedmiotu Zamówienia).
1.2 Zakres
Koncepcja architektoniczna zawiera wszelkie wymagania dotyczące architektury systemu dla wytwarzanego oprogramowania. Dokument jest aktualizowany wraz z rozwojem systemu. Utworzenie systemu rozpoczyna cykl życia tego dokumentu. Kolejne zmiany w systemie powodują aktualizację dokumentu. Wszelkie zmiany śledzone są w historii zmian dokumentu. [Zapis w historii zmian może mieć postać: „uzględniono zmiany dla Propozycji XXX”.] Szczegółowe opisy dotyczące sposobu implementacji znajdą się w Projekcie Technicznym.
1.3 Definicje
Definicje występujących w dokumencie – techniczne jak i analityczne.
PWDL Podmiot Wykonujący Działalność Leczniczą
CKiK Centrum Krwiodawstwa i Krwiolecznictwa
IHiT Instytut Hematologii i Transfuzjologii
OT Oddział Terenowy
1.4 Założenia niefunkcjonalne
1. Interfejs Użytkownika
Wymaganie Opis wymagania
WYM.OPZ.GUI.NFN.01
Interfejs przeglądarkowy
Interfejs graficzny przeznaczony dla użytkownika końcowego zrealizowany
zostanie jako zestaw aplikacji serwerowych prezentujących dane w
przeglądarce po stronie klienta. Zamawiający może wyrazić zgodę na
odstępstwo od tej reguły.
WYM.OPZ.GUI.NFN.02
Wersje przeglądarek
System umożliwiać będzie pracę z następującymi przeglądarkami:
Microsoft Internet Explorer w wersji 11.0 i wyższych,
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
System musi zapewnić pomoc kontekstową dla Użytkowników. Treść pomocy
kontekstowej ma być łatwo modyfikowalna przez administratorów systemu
poprzez edytor WYSIWYG.
WYM.OPZ.GUI.NFN.11
Komunikaty systemowe
Wszystkie komunikaty o błędach i nieprawidłowościach pracy generowane przez system e-Krew muszą być wyświetlane w języku polskim i sformułowane w sposób zrozumiały dla użytkownika.
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
System musi umożliwiać planowe wykonywanie kopii zapasowych
danych, w postaci pełnej lub przyrostowej
WYM.OPZ.BEZ.17
Kopie zapasowe
System musi umożliwiać swobodne ustalanie harmonogramu
automatycznego tworzenia kopii zapasowych danych. Poza
mechanizmem automatycznym, musi umożliwiać wykonanie kopii
zapasowej w dowolnej chwili na żądanie administratora
WYM.OPZ.BEZ.18
Redundancja systemu
System, w ramach jednego ośrodka, musi być zbudowany z elementów
redundantnych zapewniających automatyczne przejęcie funkcji elementu,
który uległ awarii. Takie przejęcie musi być niewidoczne dla aktorów
korzystających z systemu. Elementy redundantne muszą być
wykorzystywane przy normalnym działaniu systemu do obsługiwania
części obciążenia.
WYM.OPZ.BEZ.19
Dostępność
i integralność
System musi umożliwiać wielu użytkownikom równoległy dostęp do tych
samych danych lub obszarów funkcjonalnych bez utraty integralności
danych
WYM.OPZ.BEZ.20
Bezpieczne usuwanie
danych
Podsystemy muszą zapewnić mechanizmy bezpiecznego usuwania
danych wrażliwych.
WYM.OPZ.BEZ.21
Zgodność systemu
Zgodność systemu e-Krew z normą ISO 27001 w zakresie systemowego zabezpieczenia dostępu do danych przetwarzanych w systemie e-Krew.
WYM.OPZ.BEZ.22
Audyt systemowy
System powinien umożliwiać audyt systemowy - udokumentowanie historii czynności związanych z zasobami i dostępów do zasobów – tj. monitorowanie nieautoryzowanego dostępu. Włączona klasa ochrony C2 [TCSEC] (śledzenie dostępu, identyfikacja użytkownika, kontrola dystrybucji uprawnień).
WYM.OPZ.BEZ.23
Monitorowanie i
detekcja ataków
sieciowych
System powinien umożliwiać monitorowanie i detekcję ataków sieciowych - monitorowanie zdarzeń bezpieczeństwa i powiadamianie – minimum analiza logów systemowych, aplikacji, poprzez skrypty opracowane przez administratorów.
WYM.OPZ.BEZ.24 Logi
systemowe
System e-Krew musi tworzyć i utrzymywać log systemu, rejestrujący historię logowania do systemu wszystkich użytkowników oraz wykonane przez nich czynności wprowadzania, modyfikacji i usuwania danych.
WYM.OPZ.BEZ.25
Logi systemowe
W przypadku każdej (zarówno udanej, jak i nieudanej) próby uwierzytelnienia i wylogowania z Systemu, musi on rejestrować następujące informacje: czas wykonania próby uwierzytelnienia z
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
dokładnością do 1 sekundy, wprowadzony identyfikator użytkownika, adres IP komputera z którego wykonano próbę uwierzytelniania, rezultat procedury uwierzytelniania oraz autoryzacji (przyznanie lub odmowa dostępu z informacją o przyczynie odrzucenia)
WYM.OPZ.BEZ.26
Zarządzanie
uprawnieniami
W systemie e-Krew musi istnieć możliwość utworzenia kont administratorów regionalnych dla RCKIK, odpowiedzialnych za tworzenie kont i zarządzanie uprawnieniami operatorów pracujących tylko w jednostkach CKIK, OT, PWDL, PCK w danym regionie. Konta i role użytkowników będą obsługiwane przez platformę e-Krew.
WYM.OPZ.BEZ.27
Nieudane próby
logowania i dostępu
System e-Krew musi umożliwiać rejestrację nieudanych prób logowania oraz prób nieautoryzowanego dostępu.
WYM.OPZ.BEZ.28
Konsola administracyjna
System e-Krew musi posiadać konsolę administratora umożliwiającą z jednego miejsca zarządzanie użytkownikami, uprawnieniami i konfiguracją systemu.
WYM.OPZ.BEZ.29
Logi administracyjne
System musi posiadać log dla użytkowników z uprawnieniami administracyjnymi
WYM.OPZ.BEZ.30
Protokoły
komunikacyjne
System e-Krew zapewnia realizację usług przez umieszczanie i odbieranie dokumentów elektronicznych w formacie XML w strukturach i formatach umożliwiających komunikację pomiędzy systemami teleinformatycznymi, z wykorzystaniem protokołów komunikacyjnych i szyfrujących, o których mowa w art. 13 ust. 2 pkt 2 lit. a ustawy z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz. U. z 2013 r. poz. 235). System eKrew musi umożliwiać przesyłanie pomiędzy nim i systemami LSI dokumentacji medycznej (np. wyniki badań) zgodnie ze standardem HL7 CDA.
WYM.OPZ.BEZ.31 Podpis
dokumentów w
systemie
Dokumenty elektroniczne ewidencjonowane w systemie e-Krew (np. wyniki badań), podpisane powinny być bezpiecznym podpisem elektronicznym w rozumieniu art. 3 pkt 2 ustawy z dnia 18 września 2001 r. o podpisie elektronicznym (Dz. U. z 2013 r. poz. 262) albo potwierdzonym profilem zaufanym ePUAP w rozumieniu art. 3 pkt 15 ustawy z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne.
WYM.OPZ.BEZ.32
Zarządzanie
uprawnieniami
Wymagane jest aby dokumentacja zawierała dokładny wykaz uprawnień z opisaniem czynności, zadań lub transakcji jakie mogą być wykonane. W przypadku ról kompleksowych należy jednoznacznie opisać uprawnienia osobno dla każdej roli.
WYM.OPZ.BEZ.33
Zarządzanie
System powinien posiadać mechanizm uprawnień oparty na rolach (tzw. Role Base Acccess Control – RBAC).
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
Role nie powinny być przypisywane bezpośrednio konkretnym osobom lecz uprawnienia powinny być grupowane w zbiory przypisane do ról w systemie.
WYM.OPZ.BEZ.35
Zarządzanie
uprawnieniami
W systemie nie mogą istnieć nieudokumentowane w dokumentacji konta techniczne. Jeśli usunięcie zbędnych kont nie jest możliwe, muszą one zostać zablokowane. Konieczne do poprawnego działania systemu konta techniczne powinny mieć przyznany minimalny wymagany zakres uprawnień (np. konto w bazie danych wykorzystywane jedynie do wyświetlania informacji powinno mieć wyłącznie uprawnienia do odczytu, wyłącznie do niezbędnych tabel).
WYM.OPZ.BEZ.36
Zarządzanie
uprawnieniami
Wszystkie domyślne hasła kont technicznych muszą zostać zmienione.
WYM.OPZ.BEZ.37
Zarządzanie
uprawnieniami
Do systemu musi zostać dołączona procedura zmiany haseł wszystkich kont technicznych.
WYM.OPZ.BEZ.38
Zarządzanie
uprawnieniami
System musi umożliwiać zdefiniowanie daty wygaśnięcia ważności konta użytkownika. Po przekroczeniu daty wygaśnięcia, konto musi być przez system automatycznie blokowane
WYM.OPZ.BEZ.39
Zarządzanie
uprawnieniami
System nie powinien umożliwiać usuwania kont z którymi powiązane są jakiekolwiek dane. Jeżeli w systemie jest taka funkcjonalność, powinna ona być zablokowana.
WYM.OPZ.BEZ.40
Zarządzanie
uprawnieniami
W systemie musi istnieć możliwość trwałego zablokowania konta. Funkcja ta powinna być używana zamiast funkcji usuwania kont.
WYM.OPZ.BEZ.41
W systemie powinien funkcjonować mechanizm powodujący zakończenie lub zablokowanie sesji w przypadku nieaktywności użytkownika przekraczającej 15 minut (parametr konfigurowalny). W przypadku sesji Administratora, zamykanie lub blokowanie sesji musi następować po 5 minutach nieaktywności (parametr konfigurowalny).
WYM.OPZ.BEZ.42 System nie może wyświetlać w sposób czytelny (np. na ekranie monitora itp.) wprowadzanych haseł lub numerów PIN.
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
WYM.OPZ.BEZ.43 W przypadku nieudanej próby uwierzytelnienia system nie może informować użytkownika o tym, które wprowadzone przez niego dane są niepoprawne (powinien jedynie wyświetlić ogólny komunikat mówiący o nieudanym logowaniu, bez podawania przyczyny).
WYM.OPZ.BEZ.44 W przypadku, gdy wymagane jest uwierzytelnianie na poziomie integracji WebServices powinno być ono realizowane zgodnie z WS Basic Security Profile Version 1.0
WYM.OPZ.BEZ.45 W przypadku przetwarzania danych osobowych System, musi rejestrować następujące informacje: czas przetwarzania (odczytu/modyfikacji/usuniecia/wydruku) z dokładnością do 1 sekundy, identyfikator użytkownika dokonującego przetwarzania, identyfikator przetwarzanego rekordu.
WYM.OPZ.BEZ.46 W przypadku gdy System umożliwia masowy eksport, możliwość ta powinna być ograniczona do jak najmniejszej ilości pracowników. Jeżeli to możliwe i rozsądne, powinna istnieć osobna rola związana z masowym eksportem danych
WYM.OPZ.BEZ.47
Zgodność
System musi być zgodny ze standardem bezpieczeństwa aplikacji OWASP TOP 10 (aktualne wydanie).
WYM.OPZ.BEZ.48
W przypadku serwisu WWW WYMAGANA jest obsługa dedykowanych ekranów dla kodów http 4xx i 5xx
WYM.OPZ.BEZ.49
Dokumentacja
Wykonawca zobowiązany jest do dostarczenia dokumentacji dla administratora wraz z opisem procedur instalacji, aktualizacji bądź przywrócenia Systemu
3. Dostępność
Wymaganie Opis wymagania
WYM.OPZ.DOS.NFN.01
Ciągłość pracy
System musi pracować w trybie 24x7 w obszarze dystrybucji krwi oraz w
obszarze rejestrowania się Dawcy przez Internet. W pozostałych
obszarach system powinien zachować ciągłość pracy w godzinach pracy
użytkowników systemu.
WYM.OPZ.DOS.NFN.09
Dostępność Systemu
System e-Krew może być niedostępny, w każdym roku świadczenia
Usług Gwarancyjnych, maksymalnie: 17 godzin 31 minut 53 sekundy, a
w miesiącu nie więcej niż 2 godziny.
WYM.OPZ.DOS.NFN.02
Lokalizacje
Architektura Systemu musi umożliwiać instalację Systemu w dwóch
lokalizacjach:
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
WYM.TECH.ARC.NFN.007 – Technologie frontendowe HTML5/CSS3/JS
WYM.TECH.ARC.NFN.008 – platforma do tworzenia, wdrażania i uruchamiania aplikacji
Docker CE, HAProxy, Kubernates
WYM.TECH.ARC.NFN.009 – Integracja z następującymi narzędziami monitorującymi
Zabbix, ELK
WYM.TECH.ARC.NFN.010 – Środowisko wirtualizacyjna Vmware vSphere Standard
2 Architektura Aplikacji Platforma E-krew zostanie zrealizowana w architekturze centralnej, klient-serwer. Dostęp użytkowników do Platformy odbywać się będzie przy pomocy cienkiego klienta oraz poprzez Web Service’y. Poniższy obraz obrazuje główne elementy i otoczenie Platformy.
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
Platfromę możemy podzielić na 3 klasy oprogramowania:
Oprogramowanie pozwalające na udostępnianie e-usług dla dawców, kandydatów na dawców, CKiK
oraz podmiotów wykonujących działalność leczniczą (kolor pomarańczowy);
Wartstwę integracyjną z innymi e-usługami oraz systemami (kolor zielony);
Hurtownię danych(kolor czerwony).
Dodatkowo na powyższym obrazie umiejscowione zostały e-usługi i systemy zewnętrzne z którymi platforma będzie wymieniać dane. Część pomarańczowa została podzielona na mniejsze moduły, których głównymi zadaniami będą:
a) Portal e-Krew: moduł będzie odpowiedzialny za udostępnienie graficznego interfejsu użytkownika GUI
dla:
a. Dawców oraz kandydatów dla dawców w celu umówienia się na wizytę w wybranym oddziale
RCKiK, uzyskania zaświadczenia do Urzędu Skarbowego, uzyskanie informacji o
przeprowadzonych badaniach oraz złożeniu deklaracji o wycofaniu donacji.
b. Podmiotów wykonujących działalność leczniczą w celu uruchomienia procedury zamówienia
krwi oraz jej składników.
b) Moduł wsparcia procesów biznesowych, który będzie miał zaimplementowane wszelkie procesy
funkcjonalne niezbędne do obsługi funkcjonalności Portalu e-Krew.
c) Rejestry:
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
ii. Kwestionariusze przekazane przez dawców i kandydatów na dawców;
iii. Dane o reakcjach niepożądanych w trakcie i po donacji;
iv. Wyniki badań immunohematologicznych i wirusoligicznych;
v. Oznaczenie dawców o rzadkich grupach krwi;
vi. Dane o dyskwalifikacjach dawców i kandydatów na dawców.
b. Kartoteka donacji posiadająca dane o:
i. Informacje o stanach magazynowych krwi i jej składników w poszczególnych centrach;
ii. Zamówienia na krew i jej składniki od podmiotów wykonujących działalność leczniczą;
iii. Elementy książki transfuzyjnej;
iv. Informacje związane z karencjonowaniem osocza.
Połączenie systemu e-Krew z innymi systemami wykonywane będzie przez warstwę integracyjną.. Integracja systemów zewnętrznych odbywać się będzie poprzez API/WebService. W ramach projektu zostanie zbudowana integracja z systemami Centrów Krwiodawstwa i Krwiolecznictwa oraz Insytytutu Hematologii i Transfuzjologii. W ramach prac projektowych należy wybrać i wdrożyć odpowiednie mechanizmy cache’ujące – wybór mechanizmu należy ustalić z Zamawiającym. W trakcie analizy wstępnej oszacowano następujące parametry mające wpływ na wydajność powstającego systemu:
Usługa Liczba
Potencjalna liczba użytkowników systemu e-Krew (wg. Danych z 2015roku). 630 000
Liczba potencjalnych jednostek w których pracownicy powinni posiadać
dostęp do systemu
Około 1000
Średnia roczna liczba donacji obsługiwanych przez system e-Krew (liczba
może rosnąć w czasie)
1 300 000
Średnia liczba jednostek krwi i jej składników wydawanych do lecznictwa w
ciągu roku
1 600 000
Średnia liczba jednostek PWDL przetaczających krew Około 900
Szacowania minimalna liczba operatorów PWDL wykorzystujących system e-
Krew do obsługi zamówień na krew i jej składniki
Około 3000
Liczba dawców zarejestrowanych w aktualnym Rejestrze Dawców Około 3 300 000
Szacunkowa minimalna liczba operatorów w regionalnych i resortowych CKiK 4000
Liczba wyjazdów ekip wyjazdowych (dane za 2015rok) 13 694
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
Sumaryczna maksymalna liczba pobranych w ciągu jednego dnia donacji
(dane z ostatnich 12-miesięcy) we wszystkich CKiK, OT i ekipach
wyjazdowych
9 300
Sumaryczna maksymalna liczba zamówień w ciągu jednego dnia (dane z
ostatnich 12-miesięcy) we wszystkich CKiK
3 100
Brak ograniczeń technologicznych na ilość gromadzonych danych,
zarejestrowanych użytkowników systemu (z ramienia CKiK i PWDL),
Dawców, czy liczbę użytkowników systemu będących jednocześnie online
Skalowalność systemu
Średni czas odpowiedzi systemu na operację wyzwoloną przez użytkownika
(zapis formularza, wyświetlenie rekordów itp.). Wyłączenie stanowią raporty
generowane przez system cyklicznie i na żądanie użytkownika.
Maksymalnie 1
sekunda
Dodatkowo na etapie projektowania i wytwarzania oprogramowania (w szczególności projektowania bazy danych) należy uwzględnić następujące szacunki dotyczące wolumetrii danych:
Baza danych Liczba
rekordów
rocznie
Skumulowana
liczba
rekordów do
roku 2021
Wielkość
rekordu
Szacowany
wolumen
danych w roku
2021
Kartoteka dawców 2,8 mln 2,8 mln1 10 KB 27 GB
Kartoteka biorców 0,9 mln 2,7 mln 10 KB 27 GB
Kartoteka donacji – baza donacji 1,3 mln 3,9 mln 10 KB 37 GB
Kartoteka donacji – baza
wytworzonych jednostek krwi
2,5 mln 7,5 mln 10 KB 72 GB
2.1 Technologie
W trakcie uzgodnień projektowych założono że aplikacja będzie wykorzystywała następujące technologie wykonania aplikacji.
Standard Zakres użycia
1 Przyjęto założenie, iż zarejestrowanymi dawcami są te same osoby, podczas gdy biorcami są różne osoby z całego
społeczeństwa. Dlatego liczba rekordów kartoteki dawców nie zmienia się w czasie, podczas gdy liczba rekordów
kartoteki biorców rośnie z upływem lat.
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
Opis każdego komponentu na diagramie i zakres jego wykorzystania:
Nazwa Rola w systemie Zakres wykorzystania
ePuap Uwierzytelnianie użytkowników
Uwierzytelnianie użytkowników w systemie e-Krew
Systemy CKiK Wsparcie realizacji e-usług
Obsługa procesów biznesowych po stronie CKiK
Systemy IHiT Wsparcie realizacji e-usług
Obsługa procesów biznesowych po stronie IHiT
System Monitorowania Zagrożeń
Wymiana danych o zarażonych chorych
Informowanie Systemu e-Krew i SMZ o osobach, które sa zarażone między innymi HIV, WZW
Systemy PWDL Wsparcia pracy PWDL Wystawienie jednolitego API dla wszystkich systemów PWDL, dzięki czemu PWDL będą mogły zamawiać krew, powiadamiać o niepożądanych zdarzeniach/reakcjach oraz uzyskać informacje w ramach procedury „look back”
Hurtownia danych P1 Gromadzenie danych raportowych, tworzenie raportów
Gromadzenie danych z systemu oraz tworzenie raportów określonych przez Partnerów.
2.3 Perspektywy systemu
[Zawiera odwołanie do komponentów z punktów powyżej oraz opis słowny do każdej perspektywy. Dodatkowo dla każdej perspektywy przedstawiamy tabelę lub diagram. Tabela zawiera opis danego aspektu dla komponentów systemu. Tabela może nie być kompletna – w tym znaczeniu, że niektóre zagadnienia są rozstrzygane na poziomie Projektu Technicznego.] Szczegółowy opis systemu w podziale na perspektywy znajdzie się w Projekcie Technicznym.
2.3.1 Perspektywa danych
[Specyficzne formaty pośrednie i sposób składowania danych, które nie wynikają wprost z wymagań funkcjonalnych stosowane w systemie, np. pliki Excel, JPG, ZIP, XML, BLOB, plik tymczasowy, cache. [Rozdział powien opisywać przepływy danych, z otoczenia do aplikacji oraz wewnątrz aplikacji.] Jeśli cały system przechowuje tylko atomowe dane alfanumeryczne w relacyjnej bazie danych punkt może zostać pominięty.]
System / komponent Format/ struktura danych
Komentarz
CENTRUM SYSTEMÓW INFORMACYJNYCH OCHRONY ZDROWIA ul. Stanisława Dubois 5A • 00-184 Warszawa, Polska
[Zawartość analogiczna jak w punkcie „Perspektywa Danych” odnoszące się do dokumentów ]
System / komponent Format/ struktura danych
Komentarz
2.3.3 Perspektywa bezpieczeństwa – dostępy, protokoły
[Założenia ogólne w punktach]
np. oddzielenie ruchu z internetu od ruchu wewnętrznego
Stosowany model autoryzacji do funkcji użytkownika]
[Diagram obrazujący podane założenia ogólne lub alternatywnie opis w tabeli.]
System / komponent Aspekt bezpieczeństwa Komentarz
3 Specyficzne warunki i ograniczenia Specyficzne warunki i ograniczenia założeń architektonicznych.
3.1 Problemy i ograniczenia technologiczne w oprogramowaniu standardowym
[Tutaj należy wymienić znane ograniczenia i błędy związane z oprogramowaniem, które wpływają na wybór architektury. W przypadku gdy używane są nowe elementy stosu technologicznego należy określić ryzyko użycia.]