Source: http://docplayer.pl/1487489-W-systemach-bedacych-czescia-skladowa-europejskiej-sieci-zarzadzania-ruchem-lotniczym.html
Timestamp: 2017-04-26 13:53:13+00:00

Document:
w systemach będących częścią składową europejskiej sieci zarządzania ruchem lotniczym. - PDF
w systemach będących częścią składową europejskiej sieci zarządzania ruchem lotniczym.
Download "w systemach będących częścią składową europejskiej sieci zarządzania ruchem lotniczym."
1 54 Wytyczne NR 9 PREZESA URZĘDU LOTNICTWA CYWILNEGO z dnia 13 lipca 2011 r. w sprawie wprowadzenia do stosowania zasad oceny bezpieczeństwa oprogramowania stosowanego w systemach będących częścią składową europejskiej sieci zarządzania ruchem lotniczym Na podstawie art. 21 ust. 2 pkt 16 ustawy z dnia 3 lipca 2002 r. Prawo lotnicze (Dz. U. z 2006 r. Nr 100, poz. 696, z późn. zm. 1) ) zarządza się, co następuje: 1.1. W celu podniesienia poziomu bezpieczeństwa operacyjnego służb żeglugi powietrznej wykorzystujących systemy informatyczne zaleca się stosowanie Zasad oceny bezpieczeństwa oprogramowania stosowanego w systemach będących częścią składową europejskiej sieci zarządzania ruchem lotniczym. 2. Zasady, o których mowa w ust. 1, stanowią załącznik do wytycznych 2). 2. Wytyczne wchodzą w życie z dniem podpisania. Prezes Urzędu Lotnictwa Cywilnego Grzegorz Kruszyński 1) Zmiany tekstu jednolitego wymienionej ustawy zostały ogłoszone w Dz. U. z 2006 r. Nr 104, poz. 708 i 711, Nr 141, poz. 1008, Nr 170, poz i Nr 249, poz. 1829, z 2007 r. Nr 50, poz. 331 i Nr 82, poz. 558, z 2008 r. Nr 97, poz. 625, Nr 144, poz. 901, Nr 177, poz. 1095, Nr 180, poz i Nr 227, poz. 1505, z 2009 r. Nr 18, poz. 97 i Nr 42, poz. 340, z 2010 r. Nr 47, poz. 278 i Nr 182, poz oraz z 2011 r. Nr 80, poz. 432 i Nr 106, poz ) Załącznik do niniejszych wytycznych jest dostępny na stronie internetowej Urzędu Lotnictwa Cywilnego oraz w Ośrodku Informacji Naukowej, Technicznej i Ekonomicznej Urzędu Lotnictwa Cywilnego, ul. Marcina Flisa 2, Warszawa, tel. (22) , (22)2 Załącznik do Wytycznych nr 9 Prezesa Urzędu Lotnictwa Cywilnego z dnia 7 lipca 2011 r. zasady oceny bezpieczeństwa oprogramowania stosowanego w systemach będących częścią składową europejskiej sieci zarządzania ruchem lotniczym Warszawa, 20113 Preambuła Zasady oceny bezpieczeństwa oprogramowania stosowanego w systemach będących częścią składową europejskiej sieci zarządzania ruchem lotniczym są zbiorem informacji oraz zaleceń Prezesa Urzędu Lotnictwa Cywilnego kierowanym do instytucji zapewniających służby żeglugi powietrznej, zwanych dalej instytucjami, stosownie do postanowień Rozporządzenia Komisji (WE) nr 482/2008 z dnia 30 maja 2008 r. ustanawiającego system zapewnienia bezpieczeństwa oprogramowania do stosowania przez instytucje zapewniające służby żeglugi powietrznej oraz zmieniającego załącznik II do rozporządzenia (WE) nr 2096/2005 (Dz. Urz. L 141 z , str. 5 10). Na podkreślenie zasługuje fakt, iż wytyczne nie są źródłem prawa, a jedynie określeniem dobrych praktyk oraz zaleceń, które mogą pozytywnie wpłynąć na jakość usług świadczonych przez instytucje dostarczające ATS, CNS lub zapewniające ATFM lub ASM, przyczyniając się do poprawy bezpieczeństwa operacyjnego w systemie zarządzania ruchem lotniczym. Wytyczne zostały opracowane na podstawie standardów oraz zalecanych metod postępowania Europejskiej Organizacji do Spraw Bezpieczeństwa Żeglugi Powietrznej (EUROCONTROL), a także doświadczeń zebranych przez inspektorów Departamentu Żeglugi Powietrznej Urzędu Lotnictwa Cywilnego. Publikacja niniejszego dokumentu ma na celu poprawę standardów pracy w zakresie bezpieczeństwa oprogramowania wykorzystywanego w systemie zarządzania ruchem lotniczym. Dokumenty normatywne Lp. Tytuł dokumentu Numer Dziennika Urzędowego UE Skrót użyty w tekście 1. Rozporządzenie Komisji (WE) nr 482/2008 z dnia 30 maja 2008 r. ustanawiające system zapewnienia bezpieczeństwa oprogramowania do stosowania przez instytucje zapewniające służby żeglugi powietrznej oraz zmieniające załącznik II do rozporządzenia (WE) nr 2096/2005 L 141/5-10 rozporządzenie nr 482/ Rozporządzenie Komisji (WE) nr 2096/2005 z dnia 20 grudnia 2005 r. ustanawiającym wspólne wymogi dotyczące zapewniania służb żeglugi powietrznej L 335/13-30 rozporządzenie nr 2096/ Rozporządzenie (WE) nr 552/2004 Parlamentu Europejskiego i Rady z dnia 10 marca 2004 r. w sprawie interoperacyjności Europejskiej Sieci Zarządzania Ruchem Lotniczym (Rozporządzenie w sprawie interoperacyjności), zmienione przez Rozporządzenie (WE) nr 1070/2009 Parlamentu Europejskiego i Rady z dnia 21 października 2009 r. L 96/26-42 rozporządzenie nr 552/ Rozporządzenie Komisji (WE) nr 1315/2007 z dnia 8 listopada 2007 r. w sprawie nadzoru nad bezpieczeństwem w zarządzaniu ruchem lotniczym oraz zmieniające rozporządzenie (WE) nr 2096/2005 L 291/16-22 rozporządzenie nr 1315/2007 Stosowane określenia i definicje W niniejszym dokumencie przyjęto definicje określone w art. 2 rozporządzenia nr 482/2008. Ponadto zastosowanie mają niżej wymienione definicje i określenia: Wyposażenie Wyposażenie to platforma sprzętowa wraz z zainstalowanym na niej oprogramowaniem. Oprogramowanie istniejące Oprogramowanie istniejące to wszelkie oprogramowanie, które nie jest napisane specjalnie dla danej aplikacji, jednakże jest wykorzystywane w kodzie źródłowym lub bierze udział w procesie tworzenia kodu wynikowego. Z reguły jest to oprogramowanie typu COTS. Typowymi przykładami takiego oprogramowania są: systemy operacyjne (Windows, Linux, OpenVMS itp.)4 silniki baz danych (Oracle RDBM, PostgreSQL, MySQL, SQL Server itp.) serwery aplikacji (middleware) środowiska uruchomieniowe (Java Virtual Machine itp.) Oprogramowanie typu CUSTOM Oprogramowanie typu CUSTOM to oprogramowanie tworzone przez zewnętrznego lub wewnętrznego dostawcę na indywidualne zamówienie użytkownika, przy czym w obu przypadkach może wykorzystywać oprogramowanie istniejące. Oprogramowanie typu COTS 1x10-4 Oprogramowanie typu COTS 1x10-4 to oprogramowanie, dla którego określona w drodze analizy bezpieczeństwa maksymalna dopuszczalna liczba usterek wyposażenia przypadająca na jedną godzinę pracy jest równa 1x10-4 bądź większa. Przy czym wyposażenie to musi stanowić moduł możliwy do bezpośredniego wyodrębniania z systemu. Przykładami takiego wyposażenia mogą być: hub, switch, router, modem, system zobrazowania danych radarowych. Oprogramowanie typu COTS 1x10-5 Oprogramowanie typu COTS 1x10-5 to oprogramowanie, dla którego określona w drodze analizy bezpieczeństwa maksymalna dopuszczalna liczba usterek wyposażenia przypadająca na jedną godzinę pracy jest równa 1x10-5 bądź mniejsza. Przy czym wyposażenie to musi stanowić moduł możliwy do bezpośredniego wyodrębniania z systemu. Przykładami takiego wyposażenia mogą być: hub, switch, router, modem, system zobrazowania danych radarowych. AEL (Assurance Evidence Level) Poziom Zapewniania Dowodów AEL określa minimalny zestaw dowodów niezbędnych do potwierdzenia spełnienia wymagań bezpieczeństwa. AEL jest przydzielany zgodnie z sekcją 4 punktu załącznika II do rozporządzenia (WE) nr 2096/2005 odzwierciedloną w poniższej tabeli (Tab. A) w drodze analizy zagrożeń jakie niosą za sobą awarie oprogramowania z punktu widzenia działania systemu. Zaleca się przeprowadzanie analizy zagrożeń w ramach analizy bezpieczeństwa, zgodnej z wymaganiami ESARR 4. Tab. A. Zależność AEL od wagi zagrożenia Poziom AEL Waga zagrożenia Wypadek Poważny incydent Większy incydent Znaczący incydent Bez bezpośredniego wpływu na bezpieczeństwo Postanowienia ogólne Cel wydania zasad Niniejsze zasady mają na celu zapewnienie ograniczenia ryzyka związanego z wykorzystaniem oprogramowania w Europejskiej Sieci Zarządzania Ruchem Lotniczym (oprogramowanie EATMN ), do akceptowalnego poziomu. Przepis art. 3 ust. 3 rozporządzenia nr 482/2008 nakłada na instytucje obowiązek złożenia zapewnienia krajowej władzy lotniczej, że ustanowiony przez nie system bezpieczeństwa oprogramowania gwarantuje prawidłowość procesów zachodzących w cyklu życia oprogramowania. W celu spełnienia tego obowiązku zaleca się, aby instytucja przedstawiła Prezesowi Urzędu Lotnictwa Cywilnego jako krajowej władzy lotniczej dokument potwierdzający pozytywne zakończenie oceny bezpieczeństwa oprogramowania. Niniejsze zasady określają dobre praktyki pomocne przy opracowywaniu przez instytucje szczegółowych procedur i sposobów oceny bezpieczeństwa oprogramowania stosowanego w systemie zarządzania ruchem lotniczym. Niniejsze zasady nie wykluczają stosowania przez instytucje innych procedur i sposobów oceny bezpieczeństwa oprogramowania, z zastrzeżeniem art. 3 ust. 3 rozporządzenia nr 482/2008. Zakres stosowania Zgodnie z rozporządzeniem nr 482/2008 od dnia 1 stycznia 2009 r. nowe oprogramowanie, a od dnia 1 lipca 2010 r. dokonywane zmiany w oprogramowaniu działających na ten dzień systemów ATS, ASM, ATFM oraz CNS wymagają stosownej weryfikacji. W związku z powyższym zaleca się stosowanie niniejszych zasad do wszelkich oprogramowań wykorzystywanych operacyjnie w systemach ATS, ASM, ATFM oraz CNS, będących częścią EATMN.5 Działania instytucji związane z oceną bezpieczeństwa oprogramowania Zaleca się, aby wykonanie przez instytucję oceny bezpieczeństwa każdego oprogramowania wykorzystywanego operacyjnie w systemach ATS, ASM, ATFM oraz CNS będących częścią składową EATMN było potwierdzone przez wydanie Deklaracji bezpieczeństwa oprogramowania. Zalecane metody oceny bezpieczeństwa oprogramowania Określenie dowodów i argumentów dla oprogramowania typu CUSTOM W przypadku gdy oprogramowanie typu CUSTOM wykorzystuje oprogramowanie istniejące, proces oceny bezpieczeństwa musi obejmować funkcjonalną całości oprogramowania. Potwierdzenie zasadności wymagań bezpieczeństwa Dla wykazania, że dostępne argumenty i dowody prawidłowo identyfikują wymogi konieczne i wystarczające do osiągnięcia dopuszczalnego poziomu bezpieczeństwa oprogramowania w ramach systemu, powinno się ustalić czy: 1) wymagania bezpieczeństwa oprogramowania pozostają ważne na poziomie wymagań bezpieczeństwa systemu; 2) wymagania bezpieczeństwa oprogramowania określają bezpieczne zachowania oprogramowania; 3) wymagania bezpieczeństwa oprogramowania obejmują: a) specyfikację dla każdego z atrybutów zachowań oprogramowania w postaci wymagań funkcjonalnych i niefunkcjonalnych (wymagania czasowe, odporność na nietypowe warunki operacyjne, niezawodność, dokładność, wykorzystanie zasobów docelowej platformy sprzętowej i tolerancja na przeciążenia), b) potwierdzenie, że dany atrybut nie ma zastosowania; 4) wszystkie rodzaje niebezpiecznych awarii oprogramowania zostały określone: a) dla AEL 1,2,3,4,5 w wymaganiach oprogramowania, b) dla AEL 1,2,3,4 w architekturze wewnętrznej, c) dla AEL 1,2 na poziomie kodu źródłowego; 5) wszystkie rodzaje niebezpiecznych awarii, które zostały zidentyfikowane na każdym z poziomów projektowych lub w czasie implementacji oprogramowania odnoszą się do wymagań bezpieczeństwa oprogramowania, platformy sprzętowej i systemu operacyjnego lub udokumentowano, że nie ma takiej potrzeby; 6) wymagania bezpieczeństwa oprogramowania zostały określone w sposób wyraźny oraz taki, aby były łatwe do odróżnienia od innych wymagań; 7) wymagania bezpieczeństwa oprogramowania zostały określone w sposób wystarczająco szczegółowy i przejrzysty, aby umożliwić opracowanie i wdrożenie wymaganego poziomu bezpieczeństwa; 8) dostępne są pośrednie dowody i argumenty wykazujące, że: a) zapisy (notacje) specyfikacji wspierają identyfikację awarii oprogramowania, które powodują zagrożenie na poziomie systemu, b) zastosowano najlepsze dostępne metody i techniki analityczne dla atrybutów wymagań bezpieczeństwa oprogramowania, c) narzędzia, wykorzystywane w procesach analizy, zostały sprawdzone i zatwierdzone przez instytucję, d) narzędzia, użyte do dostarczenia i/lub przedstawienia wymagań bezpieczeństwa oprogramowania, zostały sprawdzone i zatwierdzone przez instytucję. Potwierdzenie spełnienia wymagań bezpieczeństwa Zaleca się, aby potwierdzenie spełnienia wymagań bezpieczeństwa odbywało się poprzez dostarczenie dowodów i argumentów w postaci dokumentów, których formy są zgodne z tabelą nr 1 określoną w pkt. 5 niniejszych zasad. Zaleca się również, aby źródła dowodów dla każdego z atrybutów zachowań oprogramowania były zgodne z tabelą nr 2 określoną w pkt. 5 niniejszych zasad. Jednocześnie zaleca się korzystanie z tabeli nr 3 określonej w pkt. 5 niniejszych zasad przy ustalaniu zakresu testów i analiz przeprowadzanych dla każdego z atrybutów zachowań oprogramowania. Potwierdzenie możliwości śledzenia wymagań bezpieczeństwa Bezpośrednie dowody i argumenty na spełnienie wymogu możliwości śledzenia wymagań bezpieczeństwa oprogramowania powinny wykazać, że każdy wymóg bezpieczeństwa wprowadzony na każdym poziomie projektowym był śledzony6 do tego poziomu, na którym wykazane zostało jego spełnienie - także w powiązaniu z wymaganiem w zakresie bezpieczeństwa systemu. Pośrednie dowody i argumenty potwierdzające możliwości śledzenia wymagań bezpieczeństwa powinny wykazać, że: 1) zapis (notacja) śledzenia wymagań bezpieczeństwa oprogramowania jest jednoznaczny i stosowany konsekwentnie; 2) monitorowanie obejmuje wszystkie oprogramowania istniejące wchodzące w skład nowotworzonego oprogramowania oraz aplikacje, do których się ono odwołuje; 3) zapis (notacja) śledzenia wymagań bezpieczeństwa oprogramowania umożliwia śledzenie wymagań zarówno w przód jak i wstecz; 4) wykorzystane procedury i narzędzia zapewniają, że jakakolwiek utrata śledzenia lub jego nieprawidłowość zostaną wykryte i skorygowane; 5) wszelkie narzędzia wykorzystywane do śledzenia zostały zweryfikowane i zatwierdzone przez instytucję. Potwierdzenie spójności konfiguracji Zaleca się by narzędzia wykorzystywane do tworzenia i utrzymania spójności konfiguracji zostały zweryfikowane i zatwierdzone przez instytucję, a przeprowadzona kontrola zachodzących zmian konfiguracji oraz system zarządzania konfiguracją umożliwiał zachowanie spójności konfiguracji podczas całego cyklu życia oprogramowania. Dowody i argumenty potwierdzające spójność konfiguracji to: 1) kod obiektowy; 2) kod źródłowy; 3) ustalone wymagania (wymagania systemu, wymagania bezpieczeństwa oprogramowania, inne wymagania dotyczące oprogramowania); 4) opracowane instrukcje obsługi i inne instrukcje związane z oprogramowaniem; 5) dane z badań, skrypty testowe, programy; 6) dane na temat wersji sprzętu używanego przy generowaniu danych testowych, stymulacji badań i rejestrowaniu wyników badań; 7) opisy pośrednich stanów projektowania oprogramowania, zarówno w języku naturalnym lub formalnych lub półformalnych notacji; 8) wyniki analiz bezpieczeństwa podejmowanych w sprawie systemu i oprogramowania; 9) dane na temat wersji systemu oraz innych narzędzi programistycznych służących do kompilacji, w tym dane na temat konfiguracji sprzętu. Powyższe dowody i argumenty powinny dotyczyć weryfikowanej wersji oprogramowania lub zawierać argumenty potwierdzające relacje zachodzące pomiędzy nimi a weryfikowaną wersją oprogramowania. Ponadto dowody i argumenty powinny być sformułowane klarownie i jednoznacznie zidentyfikowane, a ich zmiany powinny mieć uzasadnienie i być widoczne. Potwierdzenie braku interferencji funkcji związanych z bezpieczeństwem z innymi funkcjami Brak interferencji powinien być potwierdzony poprzez wykazanie, iż: 1) wszelkie funkcje oprogramowania nie wynikające z wymagań bezpieczeństwa nie zakłócają działania funkcji związanych z bezpieczeństwem oprogramowania; 2) notacje używane w analizie interferencji są w stanie wspierać wykrywanie i korygowanie wszystkich istotnych mechanizmów interferencji; 3) stosowane metody i techniki analityczne są właściwe dla identyfikacji i analizy mechanizmów zakłóceń/interferencji; 4) założenia przyjęte do analizy (np. środowisko operacyjne, sprzęt, system operacyjny, interfejsy) zostały zatwierdzone przez instytucję; 5) modele wykorzystane do analizy są adekwatną reprezentacją architektury oprogramowania; 6) zastosowano procedury i/lub narzędzia wykrywające i korygujące interferencję; 7) narzędzia wykorzystywane do wspierania wykrywania lub korekcji interferencji nie miały negatywnego wpływu na wyniki lub operacyjność systemu; 8) narzędzia wykorzystywane do wykrywania lub korygowania interferencji zostały zweryfikowane i zatwierdzone przez instytucję.7 Dowody i argumenty dla oprogramowania typu COTS Zaleca się ocenę bezpieczeństwa oprogramowania typu COTS według systemu punktacji przedstawionego w tabeli Tab. 4 określonej w pkt. 5 niniejszych zasad - dla oprogramowania typu COTS 1x10-4 oraz w Tab. 5 określonej w pkt. 5 niniejszych zasad - dla oprogramowania typu COTS 1x10-5. Zaproponowany system przewiduje uzyskanie co najmniej 100 punktów świadczących o pomyślnie zakończonej ocenie bezpieczeństwa oprogramowania. Ponadto dla oprogramowania typu COTS 1x10-5 zaleca się uzyskanie potwierdzenia: 1) zasadności wymagań bezpieczeństwa; 2) spójności konfiguracji; 3) braku interferencji funkcji związanych z bezpieczeństwem z innymi funkcjami. Potwierdzenie zasadności wymagań bezpieczeństwa Dla wykazania, że dostępne argumenty i dowody prawidłowo identyfikują wymogi konieczne i wystarczające do osiągnięcia minimalnego dopuszczalnego poziomu bezpieczeństwa oprogramowania w ramach systemu, zaleca się prowadzenie dokumentacji poświadczającej, że: 1) przeprowadzono analizę bezpieczeństwa systemu, podczas której zidentyfikowano wymagania bezpieczeństwa systemu na poziomie wyposażenia; 2) przeprowadzono analizę wymagań bezpieczeństwa wyposażenia, w celu identyfikacji wymagań bezpiecznych zachowań oprogramowania; 3) przeprowadzono analizę bezpieczeństwa specyfikacji wyposażenia, w celu identyfikacji zachowań zawartych w wymaganiach bezpiecznych zachowań oprogramowania i ustalono, czy nie istnieją inne, dalsze wymagania bezpieczeństwa; 4) stworzono i oceniono macierz zależności pomiędzy analizą bezpieczeństwa specyfikacji wyposażenia a specyfikacją wyposażenia; 5) stworzono i oceniono macierz zależności pomiędzy specyfikacją wyposażenia a specyfikacją oprogramowania. Potwierdzenie spójności konfiguracji Dla wykazania spójności konfiguracji zaleca się: 1) jednolite zidentyfikowanie wyposażenia i dokumentów (muszą posiadać unikalne identyfikatory); 2) sporządzenie oświadczenia, że przedstawione dokumenty odnoszą się do weryfikowanej wersji wyposażenia lub, że dokumenty odnoszące się do innej wersji pozostają ważne dla wersji weryfikowanej (wraz z uzasadnieniem). Potwierdzenie braku interferencji funkcji związanych z bezpieczeństwem z innymi funkcjami Dla wykazania braku interferencji funkcji związanych z bezpieczeństwem z innymi funkcjami zaleca się prowadzenie dokumentacji poświadczającej: 1) przeprowadzenie testów na poziomie wyposażenia, w tym w zakresie oczekiwanych działań; 2) reputację dostawcy; 3) wysoki poziom szczegółowości przewidywanych zachowań w specyfikacji wyposażenia; 4) prowadzenie wykazów: ujawnionych błędów, znanych problemów, etc.; 5) stosowanie norm i standardów używanych w procesie tworzenia oprogramowania; 6) przeprowadzenie testów interfejsów na różnych poziomach projektu. Zaleca się uzyskanie od dostawcy oprogramowania dokumentacji na temat stosowanych mechanizmów przeciwdziałających interferencji, w szczególności 1) stosowanych technik unikania wad; 2) stosowanych technik wykrywania wad; 3) używania jednostek zarządzania pamięcią; 4) stosowania niskich sprzężeń (low coupling) w architekturze oprogramowania; 5) tworzenia oddzielnych zadań dla oprogramowania; 6) wyłączania zbędnych funkcji w systemie operacyjnym.8 Deklaracja bezpieczeństwa oprogramowania Zawartość deklaracji bezpieczeństwa oprogramowania Zaleca się sporządzanie Deklaracji bezpieczeństwa oprogramowania, która w sposób formalny potwierdzi przeprowadzenie pozytywnej oceny bezpieczeństwa oprogramowania, zgodnie z wymogami określonymi w rozporządzeniu nr 482/2008. Zaleca się wpisywanie w Deklaracji bezpieczeństwa oprogramowania co najmniej następujących danych: 1) nazwy oprogramowania; 2) rodzaju i typu oprogramowania; 3) nazwy i typu systemu, w którym oprogramowanie będzie wykorzystywane; 4) opisu systemu; 5) nazwy i adresu producenta oprogramowania lub jego autoryzowanego przedstawiciela we Wspólnocie (z podaniem znaku towarowego i pełnego adresu, oraz w przypadku autoryzowanego przedstawiciela, z podaniem znaku towarowego producenta); 6) nazwy podmiotu, który dokonał oceny bezpieczeństwa oprogramowania. Zaleca się zamieszczanie czytelnego podpisu osoby odpowiedzialnej za ocenę bezpieczeństwa oprogramowania na Deklaracji bezpieczeństwa oprogramowania. Dokumenty związane z deklaracją bezpieczeństwa oprogramowania Zaleca się dołączenie do Deklaracji bezpieczeństwa oprogramowania: 1) protokołu przekazania do eksploatacji; 2) kopii analizy bezpieczeństwa systemu; 3) raportów z testów funkcjonalnych i technicznych ; 4) specyfikacji oprogramowania * ; 5) specyfikacji funkcjonalno-technicznej systemu * ; 6) ocen oprogramowania typu COTS, w szczególności przeprowadzonych według stosownych tabel określonych w pkt. 5 do niniejszych zasad. Tabele: Tab. 1 Formy dowodów AEL 5 4 Dowody wynikające z testów Kryteria testu Specyfikacja testu Wyniki testu Oświadczenie wybór najlepszych praktyk/ norm / narzędzi Oświadczenie wszystkie badania spełniają kryteria / uzasadnienie niedotrzymania kryteriów Oświadczenie weryfikacja i zatwierdzenie narzędzi i procedur Raport weryfikacja wykorzystania standardów/ wytycznych / narzędzi Raport analiza błędów narzędzi i procedur Opracowanie i uzasadnienie specjalnego projektu testów Dowody wynikające z doświadczenia służb Oświadczenie zakres zgromadzonej przez służby dokumentacji wspiera określone twierdzenia Oświadczenie oprogramowanie odpowiada twierdzeniom służb Oświadczenie środowisko operacyjne odpowiada twierdzeniom służb Oświadczenie zakres zgromadzonej przez służby dokumentacji jest kompletny i poprawny Zgromadzona przez służby dokumentacja Procedura DRACAS (Data Reporting Analysis and Corrective Action System) Raport analiza błędów narzędzi i procedur Dowody analityczne Oświadczenia wybór najlepszych praktyk / standardów / technik / narzędzi/ notacji Oświadczenie analiza prezentuje, że kryteria są spełnione dla wszystkich atrybutów /uzasadnienie niespełnienia kryteriów Oświadczenie weryfikacja i zatwierdzanie poprawności narzędzi Wyniki analizy Raport weryfikacja wykorzystania wytycznych/ standardów/ zapisów/ technik/ narzędzi/ notacji Opracowane i uzasadnione procesu określającego rozwój projektu Zasady dotyczące pracowników oraz ich kompetencje (wraz z uzasadnieniem) Raport analiza błędów narzędzi * Dokument w wersji elektronicznej.9 3 2 1 Raport weryfikacja kryteriów testowych Sprawozdanie ocena wyników badań Sprawozdanie adekwatność danych testowych (w tym uzasadnienie pokrycia) Raport weryfikacja wykorzystania specjalnego projektu badania procesów Raport weryfikacja i zatwierdzanie narzędzi i procedur Ocena testów przez niezależny departament Ocena testów przez niezależną organizację Raport analiza zakresu twierdzeń służb Raport analiza podobieństwa oprogramowania / uzasadnienie różnic Raport analiza podobieństwa środowiska operacyjnego / uzasadnienie różnic Raport weryfikacja użycia DRACAS oraz narzędzi wspierających Ocena przeprowadzonej analizy, zweryfikowana oraz uzasadniona przez niezależny departament Ocena przeprowadzonej analizy, zweryfikowana oraz uzasadniona przez niezależną organizację Raport weryfikacja kryteriów Raport ocena wyników Raport ocena procesu rozwoju (wszystkie możliwe środki zostały podjęte w celu zapewnienia, że produkt jest wolny od błędów) Raport adekwatność kryteriów (w tym uzasadnienie pokrycia) Raport weryfikacja wykorzystania konkretnych procesów w rozwoju projektu Raport weryfikacja i zatwierdzanie narzędzi Raport weryfikacja kompetencji personelu Ocena przeprowadzona przez niezależny departament Ocena przeprowadzona przez niezależną organizację UWAGI! 1. Powyższe dowody się kumulują. Oznacza to, że wszystkie dowody dla wyższego AEL powinny być zawarte w dowodach niższego AEL. 2. W przypadku badań statystycznych lub w dziedzinie doświadczenia argumenty należy potwierdzić na poziomie ufności równym 95%. 3. Dla AEL 3 do 5, wszelkie różnice między środowiskiem operacyjnym a testowym są identyfikowane, a ich wpływ na ocenę wyników badań musi zostać ujęty w raporcie. 4. Dla AEL 1 i 2, badania wykonywane są dla identycznej jak docelowa konfiguracji operacyjnej systemu. Tab. 2 Źródła dowodów AEL Akceptowalne źródła dowodów (należy wybrać tylko jedną kolumnę dla danego wiersza) Wymagania funkcjonalne; Wymagania czasowe; Odporność na nietypowe warunki operacyjne 5 TESTOWANIE DOŚWIADCZENIE SŁUŻB, 4 TESTOWANIE DOŚWIADCZENIE SŁUŻB, 3, Doświadczenie służb 2, Doświadczenie służb 1 Niezawodność 5 TESTOWANIE 4 TESTOWANIE 3 DOŚWIADCZENIE SŁUŻB, DOŚWIADCZENIE SŁUŻB, DOŚWIADCZENIE SŁUŻB, Doświadczenie służb, Doświadczenie służb,, Doświadczenie służb 2, Doświadczenie służb 1, Doświadczenie służb10 5 TESTOWANIE 4 TESTOWANIE, Analiza Dokładność; Wykorzystanie zasobów docelowej platformy sprzętowej DOŚWIADCZENIE SŁUŻB, Analiza, Doświadczenie służb, Doświadczenie służb, 3 Doświadczenie służb, TESTOWANIE TESTOWANIE, Analiza TESTOWANIE, Analiza Tolerancja na przeciążenia DOŚWIADCZENIE SŁUŻB, Analiza, (deterministyczny projekt przeciążenia) (deterministyczny projekt przeciążenia) Doświadczenie służb, Doświadczenie służb, Doświadczenie służb, TESTOWANIE, Analiza (niedeterministyczny projekt przeciążenia) TESTOWANIE, Analiza (niedeterministyczny projekt przeciążenia) Tab. 3 Zakres testów i analiz Atrybuty zachowań oprogramowania Wymagania funkcjonalne Wymagania czasowe Odporność na nietypowe warunki operacyjne Niezawodność Dokładność Wykorzystanie zasobów docelowej platformy sprzętowej Tolerancja na przeciążenia Testy Doświadczenie służb Analizy Testy funkcjonalne Analiza znanych wad produktu Testy czasu reakcji Testy maksymalnej wydajności Wprowadzanie błędnych danych (wewnętrzne i i/o) Testy uszkodzenia zasilania i wyposażenia Testy niezawodności (użycie oczekiwanego profilu operacyjnego) Dowody z testów wysokiego pokrycia Błędy pomiarów dla znanych przypadków testowych Testy przypadków największego obciążenia (dyski, pamięć operacyjna, wejścia/wyjścia, kanały komunikacji, procesor) Testy nadmiernego obciążenia Analiza znanych wad produktu Dowody w postaci raportów z incydentów na skuteczność środków podnoszących odporność na uszkodzenia Pomiaru zakresu niezawodności (na podstawie zbliżonego profilu operacyjnego) Szacunki oparte na znanych wadach i czasie pracy operacyjnej już działających zbliżonych aplikacji Analiza znanych wad produktu Dane uzyskane z monitorowania wykorzystania zasobów przez inne zbliżone aplikacje Analiza znanych wad produktu Formalny dowód poprawnego działania Analiza najgorszego przypadku czasowego Modelowanie wydajności Dowody na poparcie, że wewnętrzne i zewnętrzne nieprawidłowości zostaną wykryte oraz, że odpowiednie akcje zostaną podjęte Dowody potwierdzające niskie prawdopodobieństwo wystąpienia wad (wynikające z analizy procesów i produktu) np. analiza statyczna, analiza zgodności, miara złożoności, jakość narzędzi wsparcia Gęstość błędów w podobnych projektach. Analiza numeryczna Analiza stabilności algorytmu Model dokumentacji ze statycznego przydzielenia zasobów startowych. Analiza przypadku najgorszego wykorzystania zasobów Dowody, że system w warunkach przeciążenia będzie stopniowo ulegał degradacji11 Tab. 4 Oceny dla COTS 1x10-4 Zintegrowane punkty oceny oprogramowania COTS 1 x 10-4 Wyszczególnienie Ilość punktów wg kryteriów Dowody Liczba uzyskanych punktów Wykonany test = przyznanie punktów; maksymalnie: 90 Factory Acceptance Test Skrypt testu; 2. Wyniki testu; 3. Test Traceability matrix. Site Acceptance Test 20 ANSP Soak Test i obserwacje późniejsze w czasie: 1 tydzień 2 tygodnie 1 miesiąc Uruchomienie systemu na określony czas (bez resetowania), podczas którego są wprowadzane dane wejściowe odpowiadające zakresowi normalnej pracy. Test przeprowadzany po teście funkcjonalnym. Wszystkie wymagania związane z funkcjami bezpieczeństwa muszą być przetestowane (SAT lub FAT). Test musi obejmować skrajne warunki, w jakich system ma działać Skrypt testu; 2.Wyniki testu Korzystanie z systemu (praca testowa) w czasie: 1 tydzień 2 tygodnie 1 miesiąc Korzystanie z systemu i brak nieprawidłowości w jego działaniu Test wykonywany przez dostawcę w czasie: 1 miesiąc 2 miesiące 6 miesięcy Dowód, że system był używany i żadne nieprawidłowości nie zostały wykryte. Test przeprowadzany po teście funkcjonalnym Skrypt testu; 2. Wyniki testu ŁĄCZNIE Doświadczenie służb Tylko jeden z poniższych elementów może być wykorzystany; Takie samo oprogramowanie na takiej samej platformie 1 rok 5 lat 10 lat to, że 100% kodu aplikacji pozostało niezmienione oraz platforma sprzętowa jest taka sama) 2. Oświadczenie o zaobserwowanych awariach (wszelkie błędy Oprogramowanie o zbliżonej wersji na takiej samej platformie 1 rok 5 lat 10 lat Takie samo oprogramowanie na zbliżonej platformie (system operacyjny i/lub hardware) Takie samo oprogramowanie na innej platformie (system operacyjny i/lub hardware) rok 5 lat 10 lat rok 5 lat 10 lat to, że 95% kodu aplikacji pozostało niezmienione); 2. Oświadczenie o zaobserwowanych awariach (wszelkie błędy to, że 100% kodu aplikacji pozostało niezmienione - wyłączając system operacyjny i sterowniki); 2. Oswiadczenie o zaobserwowanych awariach (wszelkie błędy to, że 95% kodu aplikacji pozostało niezmienione); 2. Oświadczenie o zaobserwowanych awariach (wszelkie błędy Podobne oprogramowanie od tego samego dostawcy 1 rok 5 lat 10 lat Dowody na odpowiednio niską częstotliwość błędów związanych z ponownie użytym kodem aplikacji. Minimum 5% ponownie użytego kodu. ŁĄCZNIE Doświadczenie dostawcy oraz ekspertyzy Maksymalnie można uzyskać 20 punktów Dostawca ma doświadczenie w rozwoju i wprowadzaniu tego typu oprogramowania na rynku ATM 5 lat 10 lat 15 lat Dowodów dostawcy na sukcesy w danym sektorze rynku. Niskie Średnie Wysokie Personel dostawcy wykazał się specjalistyczną wiedzą zaufanie zaufanie zaufanie Dowody w postaci CV kluczowych osób zaangażowanych w projekt Dostawca projekt/rozwój Maksymalnie można uzyskać 30 punktów Dostawca może przedstawić pomyślnie przeprowadzenie odpowiednich procesów w cyklu życia oprogramowania Procesy zgodne z EC 61508, ED 109 lub inną normą. Normy te zalecają poziomy rygorystyczności procesów cyklu życia oprogramowania. Wiedza na temat wewnętrznych cech konstrukcyjnych (funkcji), które zostały wprowadzone w celu ograniczenia możliwości niepożądanego działania systemu Funkcje systemowe, takie jak ograniczenie zakresu danych wejściowych lub usuwanie niepotrzebnych elementów systemu operacyjnego w celu zapewnienia znacznie większej pewność, że system będzie działać prawidłowo. ŁĄCZNIE R A Z E M Poniżej zalecanego poziomu Na zalecanym poziomie Powyżej zalecanego poziomu Niektóre funkcje Wszystkie funkcje Certyfikat zgodności produktu LUB 2. Niezależny audyt zgodności LUB 3. Niezależny audyt zasadności procedur dostawcy Dowody potwierdzające skuteczność funkcji. UWAGA: Jeżeli rozwiązania systemowe zostały potwierdzone na poziomie oprogramowania, to dowody muszą prezentować ich powiązania z wymaganiami funkcjonalnymi.12 Tab. 5 Oceny dla COTS 1x10-5 Zintegrowane punkty oceny oprogramowania COTS 1 x 10-5 Wyszczególnienie Ilość punktów wg kryteriów Dowody Liczba uzyskanych punktów Wykonany test = przyznanie punktów; maksymalnie: 75 Factory Acceptance Test 10 1.Skrypt testu; 2.Wyniki testu; 3.Test Traceability matrix. Site Acceptance Test 10 ANSP Soak Test i obserwacje późniejsze w czasie: 1 tydzień 2 tygodnie 1 miesiąc Uruchomienie systemu na określony czas (bez resetowania), podczas którego są wprowadzane dane wejściowe odpowiadające zakresowi normalnej pracy. Test przeprowadzany po teście funkcjonalnym. Wszystkie wymagania związane z funkcjami bezpieczeństwa muszą być przetestowane (SAT lub FAT). Test musi obejmować skrajne warunki, w jakich system ma działać Skrypt testu; 2.Wyniki testu Korzystanie z systemu (praca testowa) w czasie: 1 tydzień 2 tygodnie 1 miesiąc Korzystanie z systemu i brak nieprawidłowości w jego działaniu Test wykonywany przez dostawcę w czasie: 1 miesiąc 2 miesiące 6 miesięcy Dowód, że system był używany i żadne nieprawidłowości nie zostały wykryte. Test przeprowadzany po teście funkcjonalnym Skrypt testu; 2.Wyniki testu ŁĄCZNIE Doświadczenie służb Takie samo oprogramowanie na takiej samej platformie 1 rok 5 lat 10 lat Tylko jeden z poniższych elementów może być wykorzystany; Oprogramowanie o zbliżonej wersji na takiej samej platformie 1 rok 5 lat 10 lat Takie samo oprogramowanie na zbliżonej platformie (system operacyjny i/lub hardware) Takie samo oprogramowanie na innej platformie (system operacyjny i/lub hardware) rok 5 lat 10 lat rok 5 lat 10 lat to, że 100% kodu aplikacji pozostało niezmienione oraz platforma sprzętowa jest taka sama) 2. Oświadczenie o zaobserwowanych awariach (wszelkie błędy to, że 95% kodu aplikacji pozostało niezmienione); 2. Oświadczenie o zaobserwowanych awariach (wszelkie błędy to, że 100% kodu aplikacji pozostało niezmienione - wyłączając system operacyjny i sterowniki); 2. Oświadczenie o zaobserwowanych awariach (wszelkie błędy to, że 95% kodu aplikacji pozostało niezmienione); 2. Oświadczenie o zaobserwowanych awariach (Wszelkie błędy Podobne oprogramowanie od tego samego dostawcy 1 rok 5 lat 10 lat Dowody na odpowiednio niską częstotliwość błędów związanych z ponownie użytym kodem aplikacji. Minimum 5% ponownie użytego kodu. ŁĄCZNIE Doświadczenie dostawcy oraz ekspertyzy Maksymalnie można uzyskać 20 punktów Dostawca ma doświadczenie w rozwoju i wprowadzaniu tego typu oprogramowania na rynku ATM Personel dostawcy wykazał się specjalistyczną wiedzą 5 lat 10 lat 15 lat Dowodów dostawcy na sukcesy w danym sektorze rynku. Niskie Średnie Wysokie zaufanie zaufanie zaufanie Dowody w postaci CV kluczowych osób zaangażowanych w projekt Dostawca projekt/rozwój Maksymalnie można uzyskać 30 punktów Dostawca może przedstawić pomyślnie przeprowadzenie odpowiednich procesów rozwojowych w rozwoju oprogramowania Procesy zgodne z EC 61508, ED 109 lub inną normą. Normy te zalecają poziomy rygorystyczności procesów cyklu życia oprogramowania. Wiedza na temat wewnętrznych cech konstrukcyjnych (funkcji), które zostały wprowadzone w celu ograniczenia możliwości niepożądanego działania systemu Funkcje systemowe, takie jak ograniczenie zakresu danych wejściowych lub usuwanie niepotrzebnych elementów systemu operacyjnego w celu zapewnienia znacznie większej pewność, że system będzie działać prawidłowo. ŁĄCZNIE R A Z E M Poniżej zalecanego poziomu Na zalecanym poziomie Powyżej zalecanego poziomu Niektóre funkcje Wszystkie funkcje Certyfikat zgodności produktu LUB 2. Niezależny audyt zgodności LUB 3. Niezależny audyt zasadności procedur dostawcy Dowody potwierdzające skuteczność funkcji. UWAGA: Jeżeli rozwiązania systemowe zostały potwierdzone na poziomie oprogramowania, to dowody muszą prezentować ich powiązania z wymaganiami funkcjonalnymi oraz wymaganiami bezpieczeństwa systemu. Pokazać jeszcze
Rozdział I Szczegółowy opis przedmiotu umowy Załącznik nr 1 do Umowy Architektura środowisk SharePoint UMWD 1. Środowisko SharePoint UWMD (wewnętrzne) składa się z następujących grup serwerów: a) Środowisko Bardziej szczegółowo Zasady organizacji projektów informatycznych
Zasady organizacji projektów informatycznych Systemy informatyczne w zarządzaniu dr hab. inż. Joanna Józefowska, prof. PP Plan Definicja projektu informatycznego Fazy realizacji projektów informatycznych Bardziej szczegółowo INŻYNIERIA OPROGRAMOWANIA TESTOWANIE SYSTEMOWE
INŻYNIERIA OPROGRAMOWANIA TESTOWANIE SYSTEMOWE Ważne pojęcia (I) Warunek testowy (test condition) to element lub zdarzenie modułu lub systemu, który może być zweryfikowany przez jeden lub więcej przypadków Bardziej szczegółowo PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT WERSJA Załącznik nr 4.4 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT WERSJA numer wersji Bardziej szczegółowo PLAN ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA PROJEKT WERSJA Załącznik nr 4.6 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PLAN ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA PROJEKT WERSJA Bardziej szczegółowo POLSKIE CENTRUM AKREDYTACJI
POLSKIE CENTRUM AKREDYTACJI AKREDYTACJA JEDNOSTEK ORGANIZACYJNYCH UBIEGAJĄCYCH SIĘ O ZGODĘ PREZESA URZĘDU TRANSPORTU KOLEJOWEGO NA WYKONYWANIE OCEN ZGODNOŚCI W OBSZARZE KOLEI Wydanie 1 Warszawa, 27.10.2015 Bardziej szczegółowo DZIENNIK USTAW RZECZYPOSPOLITEJ POLSKIEJ
DZIENNIK USTAW RZECZYPOSPOLITEJ POLSKIEJ Warszawa, dnia 20 czerwca 2016 r. Poz. 878 ROZPORZĄDZENIE MINISTRA CYFRYZACJI 1) z dnia 17 czerwca 2016 r. w sprawie dokonywania oceny zgodności urządzeń radiowych Bardziej szczegółowo PROCEDURA ADMINISTROWANIA ORAZ USUWANIA AWARII I BŁĘDÓW W CSIZS
Załącznik nr 3 do umowy nr 10/DI/PN/2016 PROCEDURA ADMINISTROWANIA ORAZ USUWANIA AWARII I BŁĘDÓW W Rozdział 1. ADMINISTROWANIE 1. Wykonawca, w celu zapewnienia ciągłości funkcjonowania, zobowiązuje się Bardziej szczegółowo POLSKIE CENTRUM AKREDYTACJI
POLSKIE CENTRUM AKREDYTACJI AKREDYTACJA JEDNOSTEK OCENIAJĄCYCH DO DZIAŁALNOŚCI OBJĘTEJ ROZPORZĄDZENIEM WYKONAWCZYM KOMISJI (UE) NR 402/2013 Wydanie 1 Warszawa, 13.03.2015 r. Spis treści 1 Wprowadzenie... Bardziej szczegółowo Szczegółowy opis przedmiotu zamówienia
Załącznik nr 2 do Zapytania Ofertowego nr 07/04/IT/2016 Szczegółowy opis przedmiotu zamówienia Utrzymanie i rozwój systemów GREX, SPIN, TK, AMOC, Obsługa Rewidentów 1 SPIS TREŚCI Wprowadzenie... 3 1. Specyfikacja Bardziej szczegółowo Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym
Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym konceptualnym modelem danych jest tzw. model związków encji (ERM Bardziej szczegółowo IO - Plan wdrożenia. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006
Usługa: Audyt kodu źródłowego Audyt kodu źródłowego jest kompleksową usługą, której głównym celem jest weryfikacja jakości analizowanego kodu, jego skalowalności, łatwości utrzymania, poprawności i stabilności Bardziej szczegółowo Specyfikacja dodatkowa. Wersja <1.0>
Wersja [Uwaga: Niniejszy wzór dostarczony jest w celu użytkowania z Unified Process for EDUcation. Tekst zawarty w nawiasach kwadratowych i napisany błękitną kursywą Bardziej szczegółowo Warszawa, dnia 21 czerwca 2013 r. Poz. 15 OBWIESZCZENIE KOMISJI NADZORU FINANSOWEGO. z dnia 21 czerwca 2013 r.
DZIENNIK URZĘDOWY Warszawa, dnia 21 czerwca 2013 r. Poz. 15 OBWIESZCZENIE z dnia 21 czerwca 2013 r. w sprawie ogłoszenia jednolitego tekstu uchwały Nr 384/2008 Komisji Nadzoru Finansowego w sprawie wymagań Bardziej szczegółowo Testowanie i walidacja oprogramowania
i walidacja oprogramowania Inżynieria oprogramowania, sem.5 cz. 3 Rok akademicki 2010/2011 Dr inż. Wojciech Koziński Zarządzanie testami Cykl życia testów (proces) Planowanie Wykonanie Ocena Dokumentacja Bardziej szczegółowo Załącznik Nr 1. Istotne warunki zamówienia do przetargu nieograniczonego na wykonanie pakietu usług programistycznych
Załącznik Nr 1 Do pisma IMP PAN l.dz. ZDN/1234/2007 z 2007-06-19 o ogłoszeniu przetargu nieograniczonego na pakiet usług programistycznych, których wartość nie przekracza progu, od którego obowiązuje prawo Bardziej szczegółowo Testowanie oprogramowania
Testowanie oprogramowania 1/17 Testowanie oprogramowania Wykład 01 dr inż. Grzegorz Michalski 13 października 2015 Testowanie oprogramowania 2/17 Dane kontaktowe: Kontakt dr inż. Grzegorz Michalski pokój Bardziej szczegółowo AERONAUTICAL DATA QUALITY
AERONAUTICAL DATA QUALITY Rozporządzenie Komisji (UE) NR 73/2010 Warszawa, 14.11.2013 r. PRZEDMIOT I ZAKRES ROZPORZĄDZENIA Ustanowienie wymagań dotyczących jakości danych i informacji lotniczych pod względem Bardziej szczegółowo Studia podyplomowe PROGRAM NAUCZANIA PLAN STUDIÓW
01-447 Warszawa ul. Newelska 6, tel. (+48 22) 34-86-520, www.wit.edu.pl Studia podyplomowe BEZPIECZEŃSTWO I JAKOŚĆ SYSTEMÓW INFORMATYCZNYCH PROGRAM NAUCZANIA PLAN STUDIÓW Studia podyplomowe BEZPIECZEŃSTWO Bardziej szczegółowo ZASADY UZNAWANIA PROGRAMÓW KOMPUTEROWYCH
PRZEPISY PUBLIKACJA NR 14/P ZASADY UZNAWANIA PROGRAMÓW KOMPUTEROWYCH 1998 GDAŃSK Publikacja Nr 14/P Zasady uznawania programów komputerowych stanowi rozszerzenie wymagań Części I Zasady klasyfikacji 1998 Bardziej szczegółowo Oświadczenie o stanie kontroli zarządczej. Dyrektora Poradni Psychologiczno-Pedagogicznej nr 1 w Bydgoszczy. za rok 2012
Oświadczenie o stanie kontroli zarządczej Dyrektora Poradni Psychologiczno-Pedagogicznej nr 1 w Bydgoszczy za rok 2012 Dział I Jako osoba odpowiedzialna za zapewnienie funkcjonowania adekwatnej, skutecznej Bardziej szczegółowo Metodyka projektowania komputerowych systemów sterowania
Metodyka projektowania komputerowych systemów sterowania Andrzej URBANIAK Metodyka projektowania KSS (1) 1 Projektowanie KSS Analiza wymagań Opracowanie sprzętu Projektowanie systemu Opracowanie oprogramowania Bardziej szczegółowo ZAPYTANIE OFERTOWE. Zamawiający. Przedmiot zapytania ofertowego. Wrocław, dnia 23.03.2015 r.
ZAPYTANIE OFERTOWE Wrocław, dnia 23.03.2015 r. W związku z realizacją przez Nova Telecom spółka z ograniczoną odpowiedzialnością, projektu pn.: Wdrożenie zintegrowanego systemu klasy B2B, umożliwiającego Bardziej szczegółowo Tom 6 Opis oprogramowania
Część 9 Narzędzie do wyliczania wskaźników statystycznych Diagnostyka Stanu Nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 31 maja 2012 Historia dokumentu Nazwa dokumentu Nazwa Bardziej szczegółowo Część I - Załącznik nr 7 do SIWZ. Warszawa. 2011r. (dane Wykonawcy) WYKAZ OSÓB, KTÓRYMI BĘDZIE DYSPONOWAŁ WYKONAWCA DO REALIZACJI ZAMÓWIENIA
CSIOZ-WZP.65.48.20 Część I - Załącznik nr 7 do SIWZ Warszawa. 20r. (dane Wykonawcy) WYKAZ OSÓB, KTÓRYMI BĘDZIE DYSPONOWAŁ WYKONAWCA DO REALIZACJI ZAMÓWIENIA Wykonawca oświadcza, że do realizacji zamówienia Bardziej szczegółowo Specyfikacja usług. 1. Zakup usług informatycznych dla realizacji dostępu do systemu dla obsługi relacji B2B.
W zawiązku z otrzymaniem dofinansowania na projekt: Zautomatyzowany system B2B elektronicznej wymiany dokumentów i danych, realizowany w ramach Programu Operacyjnego Innowacyjna Gospodarka, Działanie 8.2:Wspieranie Bardziej szczegółowo PROJEKT INTERFEJSU UśYTKOWNIKA PROJEKT WERSJA Załącznik nr 4.5 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PROJEKT INTERFEJSU UśYTKOWNIKA PROJEKT WERSJA numer wersji Bardziej szczegółowo KOMISJA WSPÓLNOT EUROPEJSKICH. Projekt. ROZPORZĄDZENIE KOMISJI (UE) nr /2011. z dnia [ ] r.
PL PL PL KOMISJA WSPÓLNOT EUROPEJSKICH Projekt Bruksela, dnia [ ] r. C ROZPORZĄDZENIE KOMISJI (UE) nr /2011 z dnia [ ] r. zmieniające rozporządzenie (WE) nr 2042/2003 w sprawie nieprzerwanej zdatności Bardziej szczegółowo KOMISJA WSPÓLNOT EUROPEJSKICH. Projekt ROZPORZĄDZENIE KOMISJI (UE) NR /2010. z dnia [ ] r.
KOMISJA WSPÓLNOT EUROPEJSKICH Bruksela, dnia [ ] r. Projekt ROZPORZĄDZENIE KOMISJI (UE) NR /2010 z dnia [ ] r. w sprawie nadzoru nad bezpieczeństwem w zarządzaniu ruchem lotniczym i służbach żeglugi powietrznej Bardziej szczegółowo udokumentowanych poprzez publikacje naukowe lub raporty, z zakresu baz danych
Rola architektury systemów IT Wymagania udokumentowanych poprzez publikacje naukowe lub raporty, z zakresu metod modelowania architektury systemów IT - UML, systemów zorientowanych na usługi, systemów Bardziej szczegółowo L 201/50 Dziennik Urzędowy Unii Europejskiej 3.8.2010
L 201/50 Dziennik Urzędowy Unii Europejskiej 3.8.2010 SPROSTOWANIA Sprostowanie do rozporządzenia Komisji (WE) nr 1217/2003 z dnia 4 lipca 2003 r. ustanawiającego wspólne specyfikacje dla krajowych programów Bardziej szczegółowo IO - Plan testów. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006
IO - Plan testów M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak 5 czerwca 2006 1 SPIS TREŚCI 2 Spis treści 1 Historia zmian 3 2 Zakres testów 3 2.1 Integration testing - Testy spójnosci.............. 3 2.2 Bardziej szczegółowo Aplikacja serwerowa Platformy Prezentacyjnej Opis produktu
Aplikacja serwerowa Platformy Prezentacyjnej Opis produktu Polska Organizacja Turystyczna ul. Chałubińskiego 8 00-613 Warszawa Spis treści 1 Założenia wstępne... 1 1.1 Informacje wstępne... 1 1.2 Cel projektu... Bardziej szczegółowo ZAPYTANIE OFERTOWE. nr 1/UE/2014. z dnia 7.01.2014 r. w związku z realizacją projektu pn.
Projekt współfinansowany ze środków Unii Europejskiej w ramach Europejskiego Funduszu Rozwoju Regionalnego ZAPYTANIE OFERTOWE nr /UE/204 z dnia 7.0.204 r. w związku z realizacją projektu pn. Wdrożenie Bardziej szczegółowo ROZPORZĄDZENIE MINISTRA GOSPODARKI 1) z dnia 17 grudnia 2010 r.
Dziennik Ustaw Nr 8 534 Poz. 32 32 ROZPORZĄDZENIE MINISTRA GOSPODARKI 1) z dnia 17 grudnia 2010 r. w sprawie procedur oceny zgodności wyrobów wykorzystujących energię oraz ich oznakowania 2) Na podstawie Bardziej szczegółowo KRYTERIA CERTYFIKACJI
KRYTERIA CERTYFIKACJI ZGODNIE Z WYMAGANIAMI AQAP 2110, AQAP 2120, AQAP 2130, AQAP 2105, AQAP 2210 SPIS TREŚCI Rozdział 1 Polityka dotycząca stosowania AQAP w organizacji Str. 3 Rozdział 2 Wymagania dotyczące Bardziej szczegółowo Szkolenie Stowarzyszenia Polskie Forum ISO 14000 Zmiany w normie ISO 14001 i ich konsekwencje dla organizacji Warszawa, 16.04.2015
Wykorzystanie elementów systemu EMAS w SZŚ według ISO 14001:2015 dr hab. inż. Alina Matuszak-Flejszman, prof. nadzw. UEP Agenda Elementy SZŚ według EMAS (Rozporządzenie UE 1221/2009) i odpowiadające im Bardziej szczegółowo PLAN WDROśENIA SYSTEMU PROJEKT WERSJA Załącznik nr 4.3 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PLAN WDROśENIA SYSTEMU PROJEKT WERSJA numer wersji Bardziej szczegółowo Projektowanie oprogramowania
Wrocław, 27.09.2010 1. Warunki wstępne Projektowanie oprogramowania Warunkiem uczestnictwa w zajęciach jest zaliczenie przedmiotu: Podstawy inżynierii oprogramowania (ćwiczenia) Zajęcia składają się z Bardziej szczegółowo Usprawnienie procesu zarządzania konfiguracją. Marcin Piebiak Solution Architect Linux Polska Sp. z o.o.
Usprawnienie procesu zarządzania konfiguracją Marcin Piebiak Solution Architect Linux Polska Sp. z o.o. 1 Typowy model w zarządzaniu IT akceptacja problem problem aktualny stan infrastruktury propozycja Bardziej szczegółowo Załącznik nr 4 do Zarządzenia Dyrektora nr 15/2010 z dnia 8 marca 2010 r.
Załącznik nr 4 do Zarządzenia Dyrektora nr 15/2010 z dnia 8 marca 2010 r. Instrukcja dokonywania samooceny oraz sporządzania oświadczenia o stanie kontroli zarządczej w Szkole Podstawowej nr 4 im. Kawalerów Bardziej szczegółowo Strona znajduje się w archiwum.
Strona znajduje się w archiwum. Zapytanie odnośnie SIWZ w postępowaniu na dostawę oprogramowania, sprzętu i wdrożenie dedykowanego systemu backupowego dla serwerów Unix oraz Windows w MSP Warszawa, dnia Bardziej szczegółowo Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32
Analiza i projektowanie oprogramowania Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania 2/32 Cel analizy Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie: Bardziej szczegółowo Zapytanie ofertowe. Skawina 7 listopada 2014
Skawina 7 listopada 2014 Zapytanie ofertowe Szanowni Państwo, W związku z realizacją projektu pt. Elektroniczna wymiana informacji pomiędzy partnerami w biznesie szansą na rozwój firmy HAUTEC Sp. z o.o., Bardziej szczegółowo Standard określania klasy systemu informatycznego resortu finansów
Dane dokumentu Nazwa Projektu: Kontrakt Konsolidacja i Centralizacja Systemów Celnych i Podatkowych Studium Projektowe Konsolidacji i Centralizacji Systemów Celnych i Podatkowych (SPKiCSCP) Numer wersji Bardziej szczegółowo ZAŁĄCZNIK NR 1.8 do PFU Serwery wraz z system do tworzenia kopii zapasowych i archiwizacji danych - wyposażenie serwerowni
ZAŁĄCZNIK NR 1.8 do PFU Serwery wraz z system do tworzenia kopii zapasowych i archiwizacji danych - wyposażenie serwerowni 1. Serwer główny 1 szt. Komponent Obudowa Płyta główna Wydajność Pamięć RAM Karta Bardziej szczegółowo Księga Zintegrowanego Systemu Zarządzania ZINTEGROWANY SYSTEM ZARZĄDZANIA
Strona: 1 z 5 1. Opis systemu zintegrowanego systemu zarządzania 1.1. Postanowienia ogólne i zakres obowiązywania W Samodzielnym Zespole Publicznych Zakładów Lecznictwa Otwartego Warszawa Ochota jest ustanowiony, Bardziej szczegółowo Część I Rozpoczęcie pracy z usługami Reporting Services
Spis treści Podziękowania... xi Wprowadzenie... xiii Część I Rozpoczęcie pracy z usługami Reporting Services 1 Wprowadzenie do usług Reporting Services... 3 Platforma raportowania... 3 Cykl życia raportu... Bardziej szczegółowo Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie
Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie informatycznej. Zadaniem systemu jest rejestracja i przechowywanie Bardziej szczegółowo ROZPORZĄDZENIE DELEGOWANE KOMISJI (UE) NR
28.5.2014 L 159/41 ROZPORZĄDZENIA ROZPORZĄDZENIE DELEGOWANE KOMISJI (UE) NR 574/2014 z dnia 21 lutego 2014 r. zmieniające załącznik III do rozporządzenia Parlamentu Europejskiego i Rady (UE) nr 305/2011 Bardziej szczegółowo ZAPYTANIE OFERTOWE. Wdrożenie systemu B2B w celu automatyzacji procesów biznesowych zachodzącymi między Wnioskodawcą a partnerami biznesowymi
Wrocław, 28 sierpnia 2014 r. ZAPYTANIE OFERTOWE KIEZA MARCIN MARCIN KIEZA PRO - CHEMIA PPH z siedzibą w Marcinkowicach przy ulicy Letnia 8a (55-200, Oława I) realizując projekt pt. Wdrożenie systemu B2B Bardziej szczegółowo Strategia identyfikacji, pomiaru, monitorowania i kontroli ryzyka w Domu Maklerskim Capital Partners SA
Strategia identyfikacji, pomiaru, monitorowania i kontroli ryzyka zatwierdzona przez Zarząd dnia 14 czerwca 2010 roku zmieniona przez Zarząd dnia 28 października 2010r. (Uchwała nr 3/X/2010) Tekst jednolity Bardziej szczegółowo Krzysztof Wawrzyniak Quo vadis BS? Ożarów Mazowiecki, styczeń 2014
1 QUO VADIS.. BS? Rekomendacja D dlaczego? Mocne fundamenty to dynamiczny rozwój. Rzeczywistość wdrożeniowa. 2 Determinanty sukcesu w biznesie. strategia, zasoby (ludzie, kompetencje, procedury, technologia) Bardziej szczegółowo Promotor: dr inż. Krzysztof Różanowski
Warszawska Wyższa Szkoła Informatyki Prezentacja do obrony pracy dyplomowej: Wzorcowa polityka bezpieczeństwa informacji dla organizacji zajmującej się testowaniem oprogramowania. Promotor: dr inż. Krzysztof Bardziej szczegółowo produkować, promować i sprzedawać produkty, zarządzać i rozliczać przedsięwzięcia, oraz komunikować się wewnątrz organizacji.
Wspieramy w doborze, wdrażaniu oraz utrzymaniu systemów informatycznych. Od wielu lat dostarczamy technologie Microsoft wspierające funkcjonowanie działów IT, jak i całych przedsiębiorstw. Nasze oprogramowanie Bardziej szczegółowo Tom 6 Opis oprogramowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli obmiaru do celów fakturowania
Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli Diagnostyka stanu nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 21 maja 2012 Historia dokumentu Bardziej szczegółowo Bezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC 27001 oraz BS 25999 doświadczenia audytora
Bezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC 27001 oraz BS 25999 doświadczenia audytora Krzysztof Wertejuk audytor wiodący ISOQAR CEE Sp. z o.o. Dlaczego rozwiązania Bardziej szczegółowo Znak pisma: DKZ-14.15-70-06/12-PT Warszawa, dnia 24 stycznia 2012 r. Zapytanie ofertowe na
Znak pisma: DKZ-14.15-70-06/12-PT Warszawa, dnia 24 stycznia 2012 r. Zapytanie ofertowe na Przeprowadzenie specjalistycznego audytu użyteczności Platformy Wspieramy e-biznes www.web.gov.pl. I. ZAMAWIAJĄCY Bardziej szczegółowo Dokumentacja aplikacji Szachy online
Projekt z przedmiotu Technologie Internetowe Autorzy: Jakub Białas i Jarosław Tyma grupa II, Automatyka i Robotyka sem. V, Politechnika Śląska Przedmiot projektu: Aplikacja internetowa w języku Java Dokumentacja Bardziej szczegółowo Załącznik nr 3 Reguły prowadzenia kontroli wniosków o płatność beneficjenta. Rozdział 1 - Tryb prowadzenia kontroli wniosków o płatność beneficjenta
Załącznik nr 3 Reguły prowadzenia kontroli wniosków o płatność beneficjenta Rozdział 1 - Tryb prowadzenia kontroli wniosków o płatność beneficjenta 1) Kontrole wniosków o płatność beneficjenta są przeprowadzane Bardziej szczegółowo 7. zainstalowane oprogramowanie. 8. 9. 10. zarządzane stacje robocze
Specyfikacja oprogramowania do Opis zarządzania przedmiotu i monitorowania zamówienia środowiska Załącznik nr informatycznego 1 do specyfikacji Lp. 1. a) 1. Oprogramowanie oprogramowania i do systemów Bardziej szczegółowo OGŁOSZENIE O ZAMÓWIENIU
Nr sprawy: AZI-79/I/EJ/2011 Bielsko-Biała, 31.05.2011 r. OGŁOSZENIE O ZAMÓWIENIU Do postępowania o udzielenie zamówienia publicznego prowadzonego w trybie negocjacje z ogłoszeniem, o wartości nie przekraczającej Bardziej szczegółowo POLSKIE CENTRUM AKREDYTACJI
POLSKIE CENTRUM AKREDYTACJI AKREDYTACJA DO CELÓW NOTYFIKACJI W ODNIESIENIU DO DYREKTYWY PARLAMENTU EUROPEJSKIEGO I RADY 2008/57/WE W SPRAWIE INTEROPERACYJNOŚCI SYSTEMU KOLEI WE WSPÓLNOCIE Wydanie 1 Warszawa, Bardziej szczegółowo Wyższa Szkoła Bankowa w Toruniu ul. Młodzieżowa 31a 87-100 Toruń www.wsb.pl/torun Toruń, dnia 17.04.2014r. ZAPYTANIE OFERTOWE nr 1/NOR/0119/2014
Wyższa Szkoła Bankowa w Toruniu ul. Młodzieżowa 31a 87-100 Toruń www.wsb.pl/torun Toruń, dnia 17.04.2014r. ZAPYTANIE OFERTOWE nr 1/NOR/0119/2014 Zamawiający: Wyższa Szkoła Bankowa w Toruniu z siedzibą Bardziej szczegółowo ROZPORZĄDZENIE MINISTRA FINANSÓW 1) z dnia 27 stycznia 2011 r.
132 ROZPORZĄDZENIE MINISTRA FINANSÓW 1) z dnia 27 stycznia 2011 r. w sprawie wymogów dla systemów wyliczania utrzymywanych w podmiotach objętych obowiązkowym systemem gwarantowania Na podstawie art. 38j Bardziej szczegółowo Instrukcja dla Oferenta. Strona 1 z 9
Definicje Instrukcja dla Oferenta System B2B cały system informatyczny (zarówno software autorski, jak i licencje serwerowe, stanowiskowe, bazodanowe, etc.) obejmujący całą funkcjonalność wskazaną we wszystkich Bardziej szczegółowo DZIENNIK USTAW RZECZYPOSPOLITEJ POLSKIEJ
DZIENNIK USTAW RZECZYPOSPOLITEJ POLSKIEJ Warszawa, dnia 8 czerwca 2016 r. Poz. 806 ROZPORZĄDZENIE MINISTRA ROZWOJU 1) z dnia 2 czerwca 2016 r. w sprawie wymagań dla sprzętu elektrycznego 2) Na podstawie Bardziej szczegółowo Skrót wymagań normy ISO 9001/2:1994, PN-ISO 9001/2:1996
Skrót wymagań normy ISO 9001/2:1994, PN-ISO 9001/2:1996 (pojęcie wyrób dotyczy też usług, w tym, o charakterze badań) 4.1. Odpowiedzialność kierownictwa. 4.1.1. Polityka Jakości (krótki dokument sygnowany Bardziej szczegółowo ISTOTNE POSTANOWIENIA UMOWY NR GIODO/2015/.../...
ISTOTNE POSTANOWIENIA UMOWY NR GIODO/2015/.../... Załącznik nr 5 do SIWZ zawartej w trybie art.... ustawy z dnia 29 stycznia 2004 r. Prawo zamówień publicznych (Dz. U. z 2010 r., Nr 113, poz. 759 z późn. Bardziej szczegółowo Metodologia weryfikacji wymagań IRIS w obszarze Projektowania i Rozwoju w teorii i praktyce. Szymon Wapienik TUV NORD Polska
Metodologia weryfikacji wymagań IRIS w obszarze Projektowania i Rozwoju w teorii i praktyce Szymon Wapienik TUV NORD Polska WARSZTATY SIRTS Metodologia weryfikacji wymagań IRIS Warszawa 25 listopada 2009r. Bardziej szczegółowo NADZÓR NAD WYPOSAŻENIEM POMIAROWYM W PRAKTYCE LABORATORYJNEJ NA PRZYKŁADZIE WAGI ELEKTRONICZEJ
Klub Polskich Laboratoriów Badawczych POLLAB NADZÓR NAD WYPOSAŻENIEM POMIAROWYM W PRAKTYCE LABORATORYJNEJ NA PRZYKŁADZIE WAGI ELEKTRONICZEJ Andrzej Hantz Centrum Metrologii im. Zdzisława Rauszera RADWAG Bardziej szczegółowo BANK SPÓŁDZIELCZY w Krzeszowicach
BANK SPÓŁDZIELCZY w Krzeszowicach Polityka informacyjna Banku Spółdzielczego w Krzeszowicach dotycząca adekwatności kapitałowej Krzeszowice, 2014. r. Spis treści 1. Postanowienia ogólne... 3 2. Zakres Bardziej szczegółowo WARUNKI GWARANCJI I SERWISU GWARANCYJNEGO
Załącznik nr 3 do Umowy nr.. z dnia r. Warunki gwarancji i serwisu gwarancyjnego WARUNKI GWARANCJI I SERWISU GWARANCYJNEGO 1. Definicję pojęć: Celem opisania warunków świadczenia usług serwisowych definiuje Bardziej szczegółowo (Tekst mający znaczenie dla EOG)
30.9.2014 L 284/9 ROZPORZĄDZENIE WYKONAWCZE KOMISJI (UE) NR 1029/2014 z dnia 26 września 2014 r. zmieniające rozporządzenie (UE) nr 73/2010 ustanawiające wymagania dotyczące jakości danych i informacji Bardziej szczegółowo 1. Wyjaśnienia/Zmiana treści specyfikacji istotnych warunków zamówienia/przedłużenie terminu składania ofert
Sygnatura postępowania: BZP/31/DRI/2015 BGK BANK GOSPODARSTWA KRAJOWEGO Warszawa, 8 lipiec 2015 r. Zamawiający: Bank Gospodarstwa Krajowego Al. Jerozolimskie 7 00-955 Warszawa Biuro Zamówień Publicznych Bardziej szczegółowo PROCEDURA UTRZYMANIA I ROZWOJU KWESTIONARIUSZA ZAINTERESOWAŃ ZAWODOWYCH
Załącznik nr 2 do umowy nr 37/DI/PN/2013 PROCEDURA UTRZYMANIA I ROZWOJU KWESTIONARIUSZA ZAINTERESOWAŃ ZAWODOWYCH Rozdział 1. WPROWADZENIE Celem niniejszego dokumentu jest sprecyzowanie procedury zarządzania Bardziej szczegółowo Instrukcja dla Oferenta
Instrukcja dla Oferenta Definicje System B2B cały system informatyczny (zarówno software autorski, jak i licencje serwerowe, stanowiskowe, bazodanow Instrukcja. Należy wypełnić WSZYSTKIE POLA oznaczone Bardziej szczegółowo Zasady funkcjonowania systemu kontroli zarządczej w Urzędzie Miasta Lublin i jednostkach organizacyjnych miasta Lublin akceptowalny poziom ryzyka
w sprawie określenia zasad funkcjonowania systemu kontroli zarządczej w Urzędzie Miasta Lublin i jednostkach organizacyjnych miasta Lublin - wydanie drugie Zasady funkcjonowania systemu kontroli zarządczej Bardziej szczegółowo Wydanie 3 Warszawa, 20.06.2007 r.
. POLSKIE CENTRUM AKREDYTACJI POLITYKA POLSKIEGO CENTRUM AKREDYTACJI DOTYCZĄCA ZAPEWNIENIA SPÓJNOŚCI POMIAROWEJ Wydanie 3 Warszawa, 20.06.2007 r. 1. Wstęp Niniejsza Polityka jest zgodna z dokumentem ILAC-P10:2002 Bardziej szczegółowo I. Postanowienia ogólne.
PROCEDURY KONTROLI ZARZĄDCZEJ Załącznik Nr 1 do zarządzenia nr 291/11 Prezydenta Miasta Wałbrzycha z dnia 15.03.2011 r. I. Postanowienia ogólne. 1 Procedura kontroli zarządczej została opracowana na podstawie Bardziej szczegółowo Szczegółowy Opis Przedmiotu Zamówienia. System monitoringu (CCTV) oraz system integrujący do zarządzania bezpieczeństwem dla CEUE
Załącznik nr 8... /nazwa i adres Wykonawcy/.. miejscowość i data Szczegółowy Opis Przedmiotu Zamówienia System monitoringu (CCTV) oraz system integrujący do zarządzania bezpieczeństwem dla CEUE Dostawa Bardziej szczegółowo Wykaz osób w postępowaniu o udzielenie zamówienia publicznego nr 32-CPI-WZP-2244/13. Podstawa do dysponowania osobą
Załącznik nr 8 do SIWZ Wykaz osób w postępowaniu o udzielenie zamówienia publicznego nr 3-CPI-WZP-44/13 Lp. Zakres wykonywanych czynności Liczba osób Imiona i nazwiska osób, którymi dysponuje wykonawca Bardziej szczegółowo POLSKIE CENTRUM AKREDYTACJI
POLSKIE CENTRUM AKREDYTACJI AKREDYTACJA ORGANIZATORÓW BADAŃ BIEGŁOŚCI WYMAGANIA SZCZEGÓŁOWE Wydanie 4 Warszawa, 1.08.2014 r. Spis treści 1 Wprowadzenie...3 2 Ogólne zasady udzielania i utrzymywania akredytacji Bardziej szczegółowo 2) stosowane metody i środki uwierzytelnienia oraz procedury związane z ich zarządzaniem i użytkowaniem,
Wskazówki dotyczące sposobu opracowania instrukcji określającej sposób zarządzania systemem informatycznym, służącym do przetwarzania danych osobowych, ze szczególnym uwzględnieniem wymogów bezpieczeństwa Bardziej szczegółowo ActiveXperts SMS Messaging Server
Stratus Avance został zaprojektowany w sposób, który w przypadku wystąpienia awarii ma zminimalizować czas przestoju i zapobiec utracie danych. Jednocześnie rozwiązanie ma być tanie i łatwe w zarządzaniu. Bardziej szczegółowo ZAŁĄCZNIK Nr 3 do CZĘŚCI II SIWZ
ZAŁĄCZNIK Nr 3 do CZĘŚCI II SIWZ WYMAGANIA BEZPIECZEŃSTWA DLA SYSTEMÓW IT Wyciąg z Polityki Bezpieczeństwa Informacji dotyczący wymagań dla systemów informatycznych. 1 Załącznik Nr 3 do Część II SIWZ Wymagania Bardziej szczegółowo Z dnia 2016 r. w sprawie zakresu i warunków korzystania z elektronicznej platformy usług administracji publicznej
ROZPORZĄDZENIE Projekt 03.06.2016 r. MINISTRA CYFRYZACJI 1) Z dnia 2016 r. w sprawie zakresu i warunków korzystania z elektronicznej platformy usług administracji publicznej Na podstawie art. 19a ust. Bardziej szczegółowo Ełk, dn. 15.10.2013 r. DOMSET Marcin Brochacki. ul. Wojska Polskiego 43 lok. 3, 19-300 Ełk. Nip 848-172-84-22 ZAPYTANIE OFERTOWE
Ełk, dn. 15.10.2013 r. DOMSET Marcin Brochacki ul. Wojska Polskiego 43 lok. 3, 19-300 Ełk Nip 848-172-84-22 ZAPYTANIE OFERTOWE Firma DOMSET Marcin Brochacki zwraca się z prośbą o przesłanie oferty cenowej Bardziej szczegółowo PROCEDURA KONTROLI ZARZĄDZCZEJ. Szkoły Podstawowej w Ligocie Małej
PROCEDURA KONTROLI ZARZĄDZCZEJ Szkoły Podstawowej w Ligocie Małej I. Postanowienia ogólne 1. Procedury kontroli zarządczej zostały opracowane na podstawie art. 69 ust. 1 pkt 2 ustawy z dnia 27 sierpnia Bardziej szczegółowo WZ PW Norma ISO/IEC 27001:2013 najnowsze zmiany w systemach zarzadzania bezpieczeństwem informacji IT security trends
Norma ISO/IEC 27001:2013 najnowsze zmiany w systemach zarzadzania bezpieczeństwem informacji dr inż. Bolesław Szomański Wydział Zarządzania Politechnika Warszawska b.szomański@wz.pw.edu.pl Plan Prezentacji Bardziej szczegółowo Załącznik nr 19 do Umowy nr... z dnia... Plan Testów Systemu. Projekt ZEFIR 2
Załącznik nr 19 do Umowy nr... z dnia... Plan Testów Systemu Projekt ZEFIR 2 1 Metryka dokumentu Nazwa projektu Właściciel projektu Izba Celna Wykonawca* Produkt Autorzy Plik_wersja Bardziej szczegółowo PROCEDURA ADMINISTROWANIA ORAZ USUWANIA AWARII I BŁĘDÓW W SI EKSMOON
Załącznik nr 3 do umowy nr 31/DI/PN/2015 PROCEDURA ADMINISTROWANIA ORAZ USUWANIA AWARII I BŁĘDÓW W SI EKSMOON Rozdział 1. ADMINISTROWANIE 1. Wykonawca zobowiązuje się do administrowania środowiskiem produkcyjnym Bardziej szczegółowo Procedura Odbioru. 1. Niniejsza Procedura odbioru obejmuje:
1. Niniejsza Procedura odbioru obejmuje: Załącznik nr 3 do Umowy nr... z dnia... zmodyfikowany w dniu 18.05.2015 r. Procedura Odbioru a) proces uzgadniania wykazu Produktów do odbioru; b) proces uzgadniania Bardziej szczegółowo Pytania i wyjaśnienia treści Specyfikacji Istotnych Warunków Zamówienia
Warszawa, 11 kwietnia 2013 r. Dotyczy: postępowania prowadzonego w trybie przetargu nieograniczonego na Usługi wsparcia technicznego, utrzymania oraz rozwoju systemu Soprano, Phoenix oraz Register Plus Bardziej szczegółowo Procedura: Postępowanie Z Niezgodnością, Działania Korygujące I Zapobiegawcze
Procedura: Postępowanie Z Niezgodnością, Działania Korygujące I Zapobiegawcze I. CEL PROCEDURY Celem niniejszego dokumentu jest zapewnienie skutecznych mechanizmów identyfikowania i zagrożeń oraz uruchamiania Bardziej szczegółowo System monitorowania realizacji strategii rozwoju. Andrzej Sobczyk
System monitorowania realizacji strategii rozwoju Andrzej Sobczyk System monitorowania realizacji strategii rozwoju Proces systematycznego zbierania, analizowania publikowania wiarygodnych informacji, Bardziej szczegółowo Galileo - encyklopedia internetowa Plan testów
Galileo - encyklopedia internetowa Plan testów Sławomir Pawlewicz Alan Pilawa Joanna Sobczyk Matek Sobierajski 5 czerwca 2006 1 Spis treści 1 Wprowadzenie 3 1.1 Cel.......................................... Bardziej szczegółowo Warunki realizacji Zamówienia
Warunki realizacji Zamówienia 1. Przedmiotem zamówienia jest świadczenie usług serwisu pogwarancyjnego i wsparcia technicznego inżyniera dla infrastruktury sieciowej eksploatowanej w ośrodkach przetwarzania Bardziej szczegółowo 2017 © DocPlayer.pl Polityka prywatności | Warunki świadczenia usług | Zwrotny adres

References: art. 21
 art. 2
 art. 3
 art. 3
 art. 38
 art. 19
 art. 69