Zastosowania metody HAZOP w inżynierii oprogramowania
|
|
- Władysława Wieczorek
- 8 lat temu
- Przeglądów:
Transkrypt
1 Zastosowania metody HAZOP w inżynierii oprogramowania Aleksander Jarzębowicz Streszczenie: Artykuł przedstawia HAZOP metodę analizy modeli systemów oraz jej zastosowania w dziedzinie inżynierii oprogramowania do identyfikacji błędów obecnych w modelach. Omawiane są różne obszary stosowalności związane z różnymi klasami błędów: defektów modelowania, zdarzeń niebezpiecznych dla otoczenia systemu oraz zagrożeń związanych z zabezpieczeniem systemu. Artykuł prezentuje również dotychczasowy stan badań związanych z metodą oraz najbliższe perspektywy jej rozwoju. 1. Wstęp Technologie informacyjne zyskują coraz większą popularność i zakres zastosowań w różnych dziedzinach życia. Oprogramowanie z jednej strony zastępuje istniejące rozwiązania, oparte na innych technologiach, a także pracę ludzi, z drugiej natomiast jest z marszu wprowadzane do zupełnie nowych dziedzin problemowych, które dopiero się kształtują. Konsekwencją tego jest fakt, że mamy do czynienia z coraz większym stopniem zależności osób, organizacji, a nawet społeczeństw od oprogramowania. Pociąga to za sobą pewne niebezpieczeństwa. Niewłaściwe; obarczone błędami lub po prostu niezgodne z potrzebami użytkownika działanie oprogramowania może skutkować poważnymi problemami np. brakiem możliwości prawidłowego funkcjonowania przedsiębiorstwa (w przypadku systemu wdrożonego w firmie) czy też zagrożeniem życia ludzkiego (w przypadku systemu używanego w samolocie lub szpitalu). Oprogramowanie w przeciwieństwie do innych, bardziej tradycyjnych technologii jest odporne na tzw. błędy przypadkowe czyli związane z eksploatacją. Nie ulega zużyciu, odkształceniom ani uszkodzeniom mechanicznym. Jednakże jest z nim nieodłącznie związany inny rodzaj błędów błędy projektowe, polegające na wytworzeniu produktu nie spełniającego wyspecyfikowanych wymagań, bądź też w ogóle niewłaściwym wyspecyfikowaniu wymagań. Z tego typu błędami mamy do czynienia już w najwcześniejszych etapach tworzenia oprogramowania i wynikających z nich produktach. Jednym z tych etapów jest faza analizy, której głównym produktem jest pewien model systemu (np. obiektowy). Niniejszy artykuł koncentruje się na identyfikacji i poprawie błędów na podstawie analizy obiektowego modelu systemu. W używanym powyżej pojęciu błędu projektowego kryje się co najmniej kilka różnych rodzajów nieprawidłowości. Podstawowym rodzajem są defekty polegające na nieprawidłowym odwzorowaniu w modelu (albo innej reprezentacji systemu) rzeczywistości dziedziny problemowej lub wymagań użytkownika. W sytuacji gdy defekty te pozostaną nie wykryte, powodują wręcz z definicji, że wytworzony system nie będzie działał poprawnie. W przypadku niektórych klas 1
2 systemów istnieją jednak pewne dużo trudniejsze do wykrycia i wymagające odrębnej analizy rodzaje błędów. Chodzi tu po pierwsze o sytuacje, w których prawidłowo funkcjonujący system może ulec awarii i zagrozić swojemu otoczeniu na skutek np. nietypowego pobudzenia, zakłóceń lub awarii jednego z komponentów. Po drugie, poprawne działanie systemu może zostać (przy braku wystarczających zabezpieczeń) zakłócone na skutek złośliwego ataku. W pierwszym przypadku mówi się o tzw. hazardzie czyli zdarzeniu niebezpiecznym, mogącym prowadzić do wypadku w otoczeniu systemu. Jest to pojęcie związane z systemowym atrybutem bezpieczeństwa (ang. safety) definiowanym jako poziom gwarancji, że funkcjonowanie systemu nie zagrozi jego otoczeniu. Identyfikacja i analiza hazardów jest konieczna w przypadku systemów wdrażanych w środowisku, w którym może dojść do sytuacji groźnych lub wręcz katastrofalnych. Jako przykłady można wymienić systemy związane z dziedzinami takimi jak: medycyna, transport (w tym lotniczy), energetyka, wojskowość i wiele innych. W drugim natomiast przypadku, przedmiotem zainteresowania jest zabezpieczenie (ang. security) czyli atrybut systemu określający stopień odporności systemu na celowe ataki z zewnątrz. Wymagana jest analiza zagrożeń dotyczących zabezpieczenia (ang. security threats). Z koniecznością wykonania takiej analizy mamy do czynienia w przypadku systemów, dla których bardzo istotne jest uniemożliwienie dostępu użytkownikom nieuprawnionym do korzystania z systemu oraz ochrona zasobów systemu przed nieupoważnionym ujawnieniem lub manipulacją. W kategorii tej mieszczą się na przykład systemy związanych z elektronicznym biznesem, bankowością, administracją itp. Oczywiście powyższe trzy kategorie nie wyczerpują wszystkich możliwych błędów projektowych, z jakimi można się zetknąć podczas prac nad systemami informatycznymi. Ich znaczenie jest jednak na tyle istotne, że warto poświęcić więcej uwagi problemowi ich wykrywania, i to na możliwie najwcześniejszym etapie rozwoju systemu. Z potrzebą taką najczęściej spotykamy się w przypadku zwykłych defektów modelowania, dotyczy to praktycznie każdego systemu. Z hazardami i zagrożeniami można się zetknąć jedynie w kontekście niektórych, niekiedy dość specyficznych klas systemów, jednak potencjalne konsekwencje ich wystąpienia nadają zagadnieniu ich wykrywalności duże znaczenie. W przypadku wszystkich trzech rodzajów błędów, ich wykrywanie nie jest zwykle sprawą łatwą. Główną przyczyną jest rosnąca złożoność systemów, w efekcie której coraz trudniejsze staje się intelektualne panowanie nad całym systemem, a co za tym idzie również jego kolejnymi reprezentacjami opracowywanymi w cyklu wytwarzania. Dodatkowo, dla hazardów i zagrożeń nie wystarczy jedynie porównanie analizowanej reprezentacji systemu z wymaganiami systemowymi lub opisem dziedziny problemowej. Ich identyfikacja wymaga bardzo kreatywnego myślenia, rozpatrywania specyficznych sytuacji i kombinacji różnych zdarzeń. Wszystko to sprawia, że konieczne staje się usystematyzowanie procesu wykrywania błędów oraz zapewnienie niezbędnego wsparcia biorącym w nim udział analitykom. Wsparcie takie polega na umiejętnym sterowaniu uwagą 2
3 analityka i wyposażeniu go w odpowiednie wzorce, listy kontrolne, narzędzia itp. Jednym z możliwych rozwiązań jest wykorzystanie do tego celu metody HAZOP, a ściślej rzecz biorąc którejś z jej adaptacji ukierunkowanej na określony rodzaj błędów. W dalszej części artykułu zostanie pokazane, w jaki sposób możliwe jest wykrywanie poszczególnych omawianych powyżej rodzajów błędów za pomocą różnych wariantów metody HAZOP. 2. Metoda HAZOP Metoda HAZOP (ang. Hazard and Operability Study) została opracowana z myślą o wykrywaniu błędów w modelach systemów na drodze systematycznego przeglądu modelu, koncentracji na jego wybranych fragmentach i sugerowaniu analitykowi potencjalnych nieprawidłowości. Z uwagi na ciekawą historię metody, warto omówić jej genezę i kilka znanych zastosowań. Początki oryginalnej metody HAZOP sięgają lat 60. W brytyjskim przemyśle chemicznym i naftowym pojawiła się wówczas potrzeba opracowania techniki pozwalającej na identyfikację i analizę hazardów na podstawie modeli instalacji fabryk chemicznych. Instalacje takie, w dużym uproszczeniu, składają się z różnych elementów takich jak pompy, zbiorniki czy reaktory chemiczne oraz z połączeń (rur) pomiędzy nimi, którymi przepływają substancje chemiczne. Z doświadczeń dostępnych w tej dziedzinie przemysłowej wynikało, że na ogół wszystkie błędy prowadzące do awarii systemu manifestują się w połączeniach, w postaci odchyleń od prawidłowych (zgodnych z projektem) parametrów tych połączeń. Tak więc, przedmiotem zainteresowania metody stały się połączenia oraz ich parametry (atrybuty) takie jak: przepływ, temperatura, ciśnienie. W celu zapewnienia kompletności analizy zdecydowano się na wykorzystanie zbioru słów kluczowych (ang. guidewords), które w sposób ogólny sugerują wszelkie możliwe rodzaje odchyleń. Słowa kluczowe przyjmują postać krótkich fraz np.: NO, MORE, LESS, REVERSE,, PART OF, OTHER THAN. Zestawienie atrybutu połączenia i słowa kluczowego daje konkretną interpretację odchylenia od prawidłowej wartości atrybutu. Przykłady takich interpretacji: atrybut: przepływ, słowo kluczowe: NO, interpretacja: brak przepływu w rurze; atrybut: temperatura, słowo kluczowe: LESS, interpretacja: temperatura substancji w rurze jest niższa niż zakładana w projekcie; Należy zauważyć że niektóre kombinacje atrybutów i słów kluczowych nie dają sensownych interpretacji. Analiza polegała na systematycznym rozpatrywaniu wszystkich połączeń i ich atrybutów oraz stosowaniu do poszczególnych atrybutów kolejnych słów kluczowych. Daje to pewne gwarancje, że żaden fragment systemu nie zostanie pominięty oraz ogranicza w danej chwili zakres rozważań do pojedynczej, konkretnej nieprawidłowości, jaka może wystąpić w systemie. Poszczególne nieprawidłowości są rozpatrywane pod kątem możliwości ich wystąpienia oraz potencjalnych konsekwencji. 3
4 Metoda HAZOP odniosła sukces i do dziś jest szeroko stosowana w przemyśle chemicznym, a także w innych gałęziach przemysłu np. nuklearnej. Tymczasem wraz z rozwojem informatyki i coraz powszechniejszym stosowaniem oprogramowania w obszarach wymagających rozpatrzenia kwestii bezpieczeństwa, pojawiła się potrzeba opracowania podobnych technik analitycznych w dziedzinie informatycznej. W tej sytuacji podjęto próby zaadaptowania do potrzeb inżynierii oprogramowania sprawdzonych metod, stosowanych w innych dziedzinach inżynierskich, m.in. HAZOPu. Przystosowanie takie wymagało opracowania następujących zagadnień: wybór odpowiedniej reprezentacji systemu; wybór elementów reprezentacji stanowiących analogię połączeń i atrybutów chemicznego HAZOPu; dobór słów kluczowych; ustalenie interpretacji dla poszczególnych par atrybutów i słów kluczowych; Prace w tym zakresie zostały wykonane w pierwszej połowie lat 90. Początkowo stosowano HAZOP jedynie do diagramów przepływu danych [1], z uwagi na podobieństwa pojęciowe pomiędzy przepływami substancji w instalacjach chemicznych i przepływami informacji w systemach informatycznych. Z czasem okazało się, że jako połączenie (podstawowe pojęcie metody, element podlegający analizie) można rozważać bardzo odmienne pojęciowo elementy różnego rodzaju reprezentacji systemów np. związek na diagramie ERD lub diagramie klas, czy też przejście na diagramie stanów. W efekcie opracowane zostały reguły adaptacji metody HAZOP dla kilku reprezentacji systemów i związanych z nimi konkretnych notacji modelowania ([2],[3],[4]). Wszystkie te doświadczenia zostały zebrane w standardzie [5] brytyjskiego Ministerstwa Obrony dotyczącym stosowania metody HAZOP do systemów zawierających oprogramowanie. Standard definiuje uniwersalny zestaw słów kluczowych (patrz Tablica 1), kryteria prowadzenia analizy dla różnych rodzajów reprezentacji systemów oraz model procesu prowadzenia analiz w ramach m.in. spotkań grupowych. Fakt stosowania metody w różnych dziedzinach inżynierskich, do różnych rodzajów diagramów i notacji oraz z ukierunkowaniem na różne cele (defekty, hazardy, zagrożenia), sprawia że trudno niekiedy dopatrzyć się cech wspólnych i dostrzec, że chodzi o tę samą metodę. Wśród wspólnych, najbardziej charakterystycznych mechanizmów metody, które zarazem decydują o jej skuteczności znajdują się: koncentracja na pewnych dobrze określonych elementach modelu (połączenia) i wyróżnienie ich możliwie atomowych, niepodzielnych fragmentów lub własności (atrybuty); wykorzystanie zestawu słów kluczowych sugerujących różne rodzaje nieprawidłowości; zestawianie słów kluczowych z atrybutami elementów i opracowanie interpretacji takich par jako sugestii pewnych błędów projektowych, które mogą wiązać się z użyciem w modelu elementu danego typu; 4
5 opracowanie list kontrolnych zawierających dla wszystkich rozpatrywanych elementów sugestie błędów, które mogą ich dotyczyć; systematyczny przegląd modelu z wykorzystaniem list kontrolnych i podejmowanie dla każdej sugestii błędu decyzji, czy rzeczywiście jest ona prawdziwa dla aktualnie analizowanego elementu modelu; stosowanie do rejestracji wyników charakterystycznych struktur danych zawierających informacje o analizowanym elemencie, sugestii błędu oraz decyzji analityka/analityków (tzw. tabele HAZOP); Tablica 1 Słowo kluczowe Ogólna interpretacja NO MORE LESS PART OF REVERSE OTHER THAN EARLY LATE BEFORE AFTER Kompletny brak zamierzonego rezultatu, przy jednoczesnym braku innych efektów Zbyt wysoka wartość parametru ilościowego Zbyt niska wartość parametru ilościowego Oprócz zamierzonego rezultatu otrzymano inny, dodatkowy Zamierzony rezultat został uzyskany tylko częściowo Otrzymano logiczne przeciwieństwo zamierzonego rezultatu Brak zamierzonego rezultatu, ale otrzymano inny, odmienny Zdarzenie zachodzi wcześniej niż zamierzono Zdarzenie zachodzi później niż zamierzono Zdarzenie zachodzi przed innym zdarzeniem, w stosunku do którego miało być późniejsze Zdarzenie zachodzi po innym zdarzeniu, w stosunku do którego miało być wcześniejsze 3. Obszary zastosowań metody Zarówno standard 00-58, jak i pozostałe cytowane w poprzednim rozdziale prace odnoszą się do wykorzystania metody HAZOP do wykrywania hazardów, a więc do zastosowań w dziedzinie bezpieczeństwa systemów. W ostatnich latach pojawiły się jednak pomysły ukierunkowania analizy na inne rodzaje błędów projektowych: zagrożeń związanych z zabezpieczeniem systemu oraz zwykłych defektów modelowania. Te nowe zastosowania wynikają w sposób dość naturalny z głównej idei HAZOPu i nie stanowią zbyt daleko idącej modyfikacji metody. Różnice dotyczą doboru analizowanych elementów i ich atrybutów oraz słów kluczowych, a także (i to przede wszystkim) sposobu tworzenia interpretacji dla 5
6 par atrybut-słowo kluczowe. Mając na uwadze określoną kategorię błędów projektowych, które mają być wykrywane, można tak dobrać interpretacje poszczególnych par, aby sugerowały właśnie taki rodzaj błędów. Kwestie te stanowią główną różnicę pomiędzy poszczególnymi wariantami metody, chociaż nie jedyną. W każdym z trzech omawianych zastosowań spotykane są odmienne rozwiązania dotyczące organizacji procesu analizy (np. podział pracy - indywidualna lub zespołowa, zakres rozważań nad pojedynczą sugestią błędu). Poniżej, w kolejnych podrozdziałach przedstawiane są szczegóły zastosowań metody HAZOP w trzech omawianych wcześniej obszarach problemowych Wykrywanie defektów Analiza ukierunkowana jest na wykrywanie defektów polegających na błędnym odwzorowaniu modelowanej rzeczywistości w danej reprezentacji systemu. Przykładem takiej reprezentacji mogą być diagramy klas wchodzące w skład notacji UML. Podstawowymi elementami podlegającymi w ich przypadku analizie są związki obecne na tych diagramach, w szczególności te najczęściej używane: powiązanie (ang. association) i uogólnienie (ang. generalization). Jako atrybuty przyjmowane są przyporządkowane im w UML charakterystyki (nazwa, liczność itp.) a także tożsamość tych związków sam fakt ich istnienia. Wykorzystywany jest uniwersalny zestaw słów kluczowych pokazany w Tablicy 1. Interpretacje nadawane zestawieniom atrybut-słowo kluczowe ustalane są pod kątem wychwycenia typowych defektów popełnianych przy wykorzystaniu danego atrybutu w modelowaniu. Przykładowe interpretacje przedstawiają Tablice 2-4. Atrybutem w Tablicy 2 jest związek uogólnienia (jego tożsamość ), natomiast atrybutami Tablic 3 i 4 są charakterystyki związku typu powiązanie, odpowiednio: nazwa (ang. name) i agregacja (ang. aggregation). Tablica 2 Atrybut: Generalization Słowo kluczowe MORE LESS Interpretacja Klasy nie pozostają ze sobą w związku dziedziczenia, cały związek jest zbędny i powinien być usunięty Zbyt wiele klas dziedziczących, niektóre są zbędne Zbyt mało klas dziedziczących, brak niektórych potrzebnych klas OTHER THAN Zdefiniowany związek jest niepoprawny, powinien być zdefiniowany inny związek niż uogólnienie Tablica 3 6
7 Atrybut: Association.name Słowo kluczowe NO REVERSE OTHER THAN PART OF Interpretacja Związek nie ma nazwy mimo, że powinien być nazwany Błędny kierunek odczytywania nazwy związku, w którym znajdują się klasy Nazwa związku jest nieprawidłowa i nie oddaje jego znaczenia; należy użyć innej nazwy Nazwa związku jest zbyt ogólna, należy ją uszczegółowić Nazwa oddaje jedynie częściowo istotę związku, należy ją uogólnić Tablica 4 Atrybut: Association.aggregation Słowo kluczowe NO OTHER THAN MORE LESS Interpretacja Nie zaznaczono agregacji, która powinna wystąpić Zaznaczono agregację, która w rzeczywistości nie ma miejsca Zaznaczono niewłaściwy typ agregacji tzn. silną zamiast słabej lub odwrotnie Agregacja obejmuje zbyt wiele klas składowych, niektóre nie powinny wchodzić w jej skład Agregacja nie obejmuje niektórych klas (obecnych na diagramie lub też nie), które powinny wchodzić w jej skład W przypadku błędów projektowych będących defektami modelowania, analiza polega jedynie na ich wykryciu i udokumentowaniu. Nie dochodzi się ich przyczyn ani nie zastanawia nad konsekwencjami, jakie mogły by mieć gdyby pozostały nie wykryte. Zalecane jest przyjęcie procesu dwufazowego. W fazie pierwszej niezależny (niezaangażowany w tworzenie modelu) analityk wykrywa i rejestruje defekty. W fazie drugiej wyniki pracy analityka trafiają do autora modelu, który dokonuje ich weryfikacji. Weryfikacja polega na ocenie czy defekt opisany przez analityka rzeczywiście ma miejsce, czy też np. analityk nie zrozumiał jakiegoś rozwiązania. Potwierdzone defekty powinny następnie zostać poprawione, najlepiej również przez autora modelu. Więcej informacji o tym zastosowaniu metody można znaleźć w [6]. 7
8 3.2. Analiza hazardów Jest to najstarsza i najbardziej znana dziedzina zastosowań metody HAZOP. Analizie podlegają modele opisujące dynamiczne zachowanie systemu np. znane z UML diagramy stanów lub diagramy interakcji. Przedmiotem zainteresowania analizy są elementy reprezentujące dynamiczne zmiany zachodzące w systemie np. przejście (ang. transition) w przypadku diagramu stanów lub komunikat (ang. message) w przypadku diagramu interakcji. Za atrybuty przyjmowane są wybrane charakterystyki tych elementów. W dziedzinie analizy hazardów, interpretacje tworzone przez odnoszenie słów kluczowych do atrybutów mają za zadanie sugerować różnego rodzaju zakłócenia dotyczące zmian zachodzących podczas pracy systemu. W Tablicach 5 i 6 znajdują się zaczerpnięte z [7] przykłady interpretacji dla zdarzenia uruchamiającego przejście (ang. trigger) oraz dla komunikatu. Inne zestawy interpretacji zostały zaproponowane w pracy [8]. Tablica 5 Atrybut: Transition.trigger Słowo kluczowe NO OTHER THAN EARLY LATE BEFORE AFTER Interpretacja Zdarzenie nie zachodzi Oprócz oczekiwanego zdarzenia zachodzi inne Zamiast oczekiwanego zdarzenia zachodzi inne Zdarzenie zachodzi wcześniej niż jest spodziewane Zdarzenie zachodzi później niż jest spodziewane Zdarzenie zachodzi przed zdarzeniem/akcją które powinno je poprzedzać Zdarzenie zachodzi po zdarzeniu/akcji które powinno zajść po nim W ramach analizy hazardów dla każdej tego typu sugestii wystąpienia zakłócenia należy odpowiedzieć na następujące pytania: Czy w ogóle możliwe jest wystąpienie takiego zakłócenia? Jakie mogą być tego przyczyny? Jakie może mieć ono konsekwencje dla całego systemu? Jeśli wykryte zostanie zakłócenie, które może zagrozić bezpieczeństwu systemu (czyli hazard), odpowiedzi na powyższe pytania stanowią punkt wyjścia do zmiany projektu systemu w taki sposób aby wyeliminować przyczyny hazardu lub ograniczyć jego konsekwencje. Wszystko to stanowi zagadnienie dużo bardziej skomplikowane niż wykrywanie defektów modelowania i wymaga zaangażowania większej liczby osób. Analiza przeprowadzana jest w ramach spotkania grupowego 8
9 z udziałem m.in. projektantów systemu, użytkowników oraz ekspertów dziedzinowych. Tablica 6 Atrybut: Message Słowo kluczowe NO OTHER THAN EARLY LATE BEFORE AFTER Interpretacja Komunikat nie zostaje przekazany Komunikat zostaje powtórzony Przekazany komunikat jest niepoprawny Komunikat zostaje przekazany zbyt wcześnie Komunikat zostaje przekazany zbyt późno Komunikat zostaje przekazany przed innym, który powinien go poprzedzać Komunikat zostaje przekazany po innym, który powinien być przekazany po nim 3.3. Analiza zagrożeń W tej dziedzinie zastosowań do metody wprowadzono pewne modyfikacje, które na pierwszy rzut oka wydają się odbiegać w znaczny sposób od pierwowzoru. W rzeczywistości jednak wszystkie główne założenia metody HAZOP pozostają aktualne. Pierwsza różnica polega na tym, że analizowanymi elementami nie są połączenia, lecz wchodzące w skład rozważanego systemu komponenty, które wymagają odpowiedniego zabezpieczenia. Jest to pojęcie bardzo szerokie. Do komponentów takich można zaliczyć zarówno rekord w bazie danych lub wiadomość , jak i firewall lub sieć komunikacyjną. Druga różnica dotyczy atrybutów, które są takie same dla każdego komponentu. Atrybutami tymi są trzy aspekty składające się na pojęcie zabezpieczenia: poufność, integralność i dostępność. Zrezygnowano również z tradycyjnego zestawu słów kluczowych. Zamiast tego wyróżniono dwa odrębne zestawy: pierwszy z nich sugeruje intencjonalność zaistniałego zagrożenia (celowe lub przypadkowe), drugi natomiast wskazuje przyczynę/sprawcę zagrożenia (np. wirus, haker, usterka techniczna). Przykładowe kombinacje atrybutów i słów kluczowych przedstawione są w Tablicy 7, opracowanej na podstawie [9]. Tablica posiada dość interesującą konstrukcję. Interpretacje można otrzymać po prostu czytając kolejne pola poszczególnych wierszy. 9
10 Tablica 7 Słowo kluczowe I utrata Atrybut Komponent spowodowana przez celowa utrata integralności programu pocztowego spowodowana przez przypadkowa utrata dostępności serwera spowodowana przez celowa utrata poufności rekordu danych spowodowana przez Słowo kluczowe II wirusa usterkę techniczną hakera Wszystkie zagrożenia otrzymane w wyniku takich kombinacji muszą zostać przeanalizowane pod kątem możliwych przyczyn i konsekwencji, podobnie jak ma to miejsce w przypadku hazardów. Wyniki analizy mogą stanowić przesłanki do wprowadzenia zmian w projekcie systemu np. wprowadzeniu dodatkowych zabezpieczeń. 5. Zakończenie Przedstawione w niniejszym artykule przykłady zastosowań metody HAZOP świadczą o jej potencjalnie dużej użyteczności w różnych dziedzinach inżynierii oprogramowania. Na szczególną uwagę zasługuje wykorzystanie metody do wykrywania defektów modelowania, które może okazać się pomocne w przypadku praktycznie każdego projektu informatycznego. Skuteczność tego typu analiz została już potwierdzona eksperymentalnie. W chwili obecnej, w kilku ośrodkach naukowych trwają prace nad jak najpełniejszym przystosowaniem metody do notacji UML, za pomocą której tworzona jest obecnie ogromna większość modeli systemów. Jest to o tyle istotne, że standard i inne źródła wiedzy o metodzie odwołują się do starszych notacji i metodyk, które zostały już w powszechnym użyciu zastąpione przez UML. W rezultacie pewna część podawanych w tych dokumentach informacji straciła swoją wartość i nie może mieć zastosowania w aktualnie realizowanych przedsięwzięciach informatycznych. W najbliższym czasie przewidywany jest rozwój młodszych obszarów zastosowań metody (wykrywania defektów oraz analizy zagrożeń), dla których nie opracowano jeszcze kompletnych rozwiązań. Praca badawcza autora artykułu związana jest głównie z zagadnieniem zastosowania HAZOPu do wykrywania defektów i obejmuje zarówno działania związane z adaptacją metody, jak również prace nad wytworzeniem narzędzia informatycznego wspomagającego prowadzenie analiz. 10
11 Literatura 1. Earthy J. V.; Hazard and operability studies as an approach to software safety assessment ; I.E.E. Computing and Control Division Colloquium on Hazard Analysis, Institution of Electrical Engineers, Digest No.: 1992/198; Chudleigh M.; Hazard Analysis Using HAZOP: A Case Study ; materiały konferencyjne SAFECOMP 93; McDermid J., Pumfrey D.; Development of hazard analysis to aid software design ; materiały konferencyjne COMPASS `94; Fencott P. C., Hebbron B. D.; The Application Of Hazop Studies To Integrated Requirements Models For Control Systems ; materiały konferencyjne SAFECOMP 94; UK Ministry of Defense; HAZOP Studies on System Containing Programmable Electronics ; Defense Standard 00-58; Górski J., Jarzębowicz A.; Wykrywanie anomalii w modelach obiektowych za pomocą metody UML-HAZOP ; w mat. IV Krajowej Konferencji Inżynierii Oprogramowania; Jarzębowicz A.; Wspomaganie analizy systemu informatycznego metodą dewiacji przepływów ; praca magisterska, Wydział Elektroniki, Telekomunikacji i Informatyki, Politechnika Gdańska; Lano K., Clark D., Androutsopoulos K.; Safety and security analysis of object-oriented models ; materiały konferencyjne SAFECOMP 2002; Winther R., Johansen O-A., Gran B. A.; Security assessments of safety critical systems using HAZOPs ; materiały konferencyjne SAFECOMP 2000;
Metoda inspekcji modeli obiektowych
Metoda inspekcji modeli obiektowych Aleksander Jarzębowicz olek@eti.pg.gda.pl Katedra Inżynierii Oprogramowania Politechnika Gdańska Seminarium Katedralne 5 luty 2008 Plan prezentacji Motywacja: defekty
Bardziej szczegółowoKomputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl
Komputerowe Systemy Przemysłowe: Modelowanie - UML Arkadiusz Banasik arkadiusz.banasik@polsl.pl Plan prezentacji Wprowadzenie UML Diagram przypadków użycia Diagram klas Podsumowanie Wprowadzenie Języki
Bardziej szczegółowoZagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)
Zagadnienia (1/3) Rola modelu systemu w procesie analizy wymagań (inżynierii wymagań) Prezentacja różnego rodzaju informacji o systemie w zależności od rodzaju modelu. Budowanie pełnego obrazu systemu
Bardziej szczegółowoZarządzanie bezpieczeństwem informacji przegląd aktualnych standardów i metodyk
Zarządzanie bezpieczeństwem informacji przegląd aktualnych standardów i metodyk dr T Bartosz Kalinowski 17 19 września 2008, Wisła IV Sympozjum Klubu Paragraf 34 1 Informacja a system zarządzania Informacja
Bardziej szczegółowoTabela 1. Ogólne słowa kluczowe HAZOPu
Wersja postprint artykułu opublikowanego na IV Krajowej Konferencji Inżynierii Oprogramowania, Tarnowo Podgórne k. Poznania, 5-8 października 2002, Poznań: Wydawnictwo Nakom 2002 str. 25-40. Wykrywanie
Bardziej szczegółowoProjektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34
Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34 Projektowanie oprogramowania cd. 2/34 Modelowanie CRC Modelowanie CRC (class-responsibility-collaborator) Metoda identyfikowania poszczególnych
Bardziej szczegółowoAutor: Artur Lewandowski. Promotor: dr inż. Krzysztof Różanowski
Autor: Artur Lewandowski Promotor: dr inż. Krzysztof Różanowski Przegląd oraz porównanie standardów bezpieczeństwa ISO 27001, COSO, COBIT, ITIL, ISO 20000 Przegląd normy ISO 27001 szczegółowy opis wraz
Bardziej szczegółowoDiagramy 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ółowoPodstawy inżynierii oprogramowania
Podstawy inżynierii oprogramowania Modelowanie. Podstawy notacji UML Aleksander Lamża ZKSB Instytut Informatyki Uniwersytet Śląski w Katowicach aleksander.lamza@us.edu.pl Zawartość Czym jest UML? Wybrane
Bardziej szczegółowoPRZEWODNIK PO PRZEDMIOCIE
Nazwa przedmiotu: PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH I KARTA PRZEDMIOTU CEL PRZEDMIOTU PRZEWODNIK PO PRZEDMIOCIE C1. Podniesienie poziomu wiedzy studentów z inżynierii oprogramowania w zakresie C.
Bardziej szczegółowoModel referencyjny doboru narzędzi Open Source dla zarządzania wymaganiami
Politechnika Gdańska Wydział Zarządzania i Ekonomii Katedra Zastosowań Informatyki w Zarządzaniu Zakład Zarządzania Technologiami Informatycznymi Model referencyjny Open Source dla dr hab. inż. Cezary
Bardziej szczegółowoInformatyka w kontroli i audycie
Informatyka w kontroli i audycie Informatyka w kontroli i audycie Wstęp Terminy zajęć 30.11.2013 - godzina 8:00-9:30 ; 9:45-11:15 15.12.2013 - godzina 8:00-9:30 ; 9:45-11:15 05.04.2014 - godzina 15:45-17:15
Bardziej szczegółowoZnaczenie norm ISO w znowelizowanej ustawie o ochronie danych osobowych (RODO)
Znaczenie norm ISO w znowelizowanej ustawie o ochronie danych osobowych (RODO) Normy ISO 31000, ISO 27001, ISO 27018 i inne Waldemar Gełzakowski Witold Kowal Copyright 2016 BSI. All rights reserved. Tak
Bardziej szczegółowoPraktyczne aspekty stosowania metody punktów funkcyjnych COSMIC. Jarosław Świerczek
Praktyczne aspekty stosowania metody punktów funkcyjnych COSMIC Jarosław Świerczek Punkty funkcyjne Punkt funkcyjny to metryka złożoności oprogramowania wyznaczana w oparciu o określające to oprogramowanie
Bardziej szczegółowoZnaczenie norm ISO w znowelizowanej ustawie o ochronie danych osobowych (RODO)
Znaczenie norm ISO w znowelizowanej ustawie o ochronie danych osobowych (RODO) Normy ISO 31000, ISO 27001, ISO 27018 i inne Waldemar Gełzakowski Copyright 2016 BSI. All rights reserved. Tak było Na dokumentację,
Bardziej szczegółowoKATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA
KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA Przygotował: mgr inż. Radosław Adamus Wprowadzenie Podstawą każdego projektu, którego celem jest budowa oprogramowania są wymagania, czyli warunki,
Bardziej szczegółowoPriorytetyzacja przypadków testowych za pomocą macierzy
Priorytetyzacja przypadków testowych za pomocą macierzy W niniejszym artykule przedstawiony został problem przyporządkowania priorytetów do przypadków testowych przed rozpoczęciem testów oprogramowania.
Bardziej szczegółowoTransformacja wiedzy w budowie i eksploatacji maszyn
Uniwersytet Technologiczno Przyrodniczy im. Jana i Jędrzeja Śniadeckich w Bydgoszczy Wydział Mechaniczny Transformacja wiedzy w budowie i eksploatacji maszyn Bogdan ŻÓŁTOWSKI W pracy przedstawiono proces
Bardziej szczegółowo1. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI
KARTA PRZEDMIOTU przedmiotu Stopień studiów i forma Rodzaj przedmiotu Grupa kursów Zaawansowane techniki analizy systemowej oparte na modelowaniu warsztaty Studia podyplomowe Obowiązkowy NIE Wykład Ćwiczenia
Bardziej szczegółowoMaciej Oleksy Zenon Matuszyk
Maciej Oleksy Zenon Matuszyk Jest to proces związany z wytwarzaniem oprogramowania. Jest on jednym z procesów kontroli jakości oprogramowania. Weryfikacja oprogramowania - testowanie zgodności systemu
Bardziej szczegółowoSystem Kontroli Bazy Danych Topograficznych (SKBDT) zawód kartografa?
System Kontroli Bazy Danych Topograficznych (SKBDT) zawód kartografa? Koszalin, 15-16.05.2006 III Zawodowa Konferencja Zawód kartografa 200910151500 Agenda 1. Koncepcja SKBDT 2. Podstawowe założenia koncepcji
Bardziej szczegółowoSpis treści. Analiza i modelowanie_nowicki, Chomiak_Księga1.indb :03:08
Spis treści Wstęp.............................................................. 7 Część I Podstawy analizy i modelowania systemów 1. Charakterystyka systemów informacyjnych....................... 13 1.1.
Bardziej szczegółowoJak zostać dobrym analitykiem? Wpisany przez RR Nie, 21 paź 2012
Analityk systemów informatycznych to zawód cieszący się w ostatnich latach rosnącą popularnością. Młodych ludzi zachęcają liczne oferty pracy, perspektywa wysokich zarobków i możliwość podnoszenia kwalifikacji.
Bardziej szczegółowoGalileo - 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ółowoAnalityk i współczesna analiza
Analityk i współczesna analiza 1. Motywacje 2. Analitycy w IBM RUP 3. Kompetencje analityka według IIBA BABOK Materiały pomocnicze do wykładu z Modelowania i Analizy Systemów na Wydziale ETI PG. Ich lektura
Bardziej szczegółowoPRZEWODNIK PO PRZEDMIOCIE
Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH Modeling and analysis of computer systems Kierunek: Informatyka Forma studiów: Stacjonarne Rodzaj przedmiotu: Poziom kwalifikacji: obowiązkowy
Bardziej szczegółowoSpis treúci. 1. Wprowadzenie... 13
Księgarnia PWN: W. Dąbrowski, A. Stasiak, M. Wolski - Modelowanie systemów informatycznych w języku UML 2.1 Spis treúci 1. Wprowadzenie... 13 2. Modelowanie cele i metody... 15 2.1. Przegląd rozdziału...
Bardziej szczegółowoosobowe pracowników laboratorium SecLab EMAG w rozumieniu przepisów Kodeksu Pracy, konsultantów, stażystów oraz inne osoby i instytucje mające dostęp
Bezpieczeństwo danych projektowych w środowisku według ISO/IEC 27001 oraz ciągłość procesów wytwarzania i utrzymania w środowisku według BS 25999 warsztaty z wykorzystaniem specjalistycznego narzędzia
Bardziej szczegółowoKarta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty
Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty przedmiotu Stopień studiów i forma: Rodzaj przedmiotu Kod przedmiotu Grupa kursów Zaawansowane techniki analizy
Bardziej szczegółowoŚwiat rzeczywisty i jego model
2 Świat rzeczywisty i jego model Świat rzeczywisty (dziedzina problemu) Świat obiektów (model dziedziny) Dom Samochód Osoba Modelowanie 3 Byty i obiekty Byt - element świata rzeczywistego (dziedziny problemu),
Bardziej szczegółowoArchitektura bezpieczeństwa informacji w ochronie zdrowia. Warszawa, 29 listopada 2011
Architektura informacji w ochronie zdrowia Warszawa, 29 listopada 2011 Potrzeba Pomiędzy 17 a 19 kwietnia 2011 roku zostały wykradzione dane z 77 milionów kont Sony PlayStation Network. 2 tygodnie 25 milionów
Bardziej szczegółowoPYTANIA PRÓBNE DO EGZAMINU NA CERTYFIKAT ZAAWANSOWANY REQB KLUCZ ODPOWIEDZI. Część DODATEK
KLUCZ ODPOWIEDZI Część DODATEK 8.1 9.4 PYTANIA PRÓBNE DO EGZAMINU NA CERTYFIKAT ZAAWANSOWANY REQB Na podstawie: Syllabus REQB Certified Professional for Requirements Engineering, Advanced Level, Requirements
Bardziej szczegółowoBezpieczeń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ółowoProjekt 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ółowoEwa Stemposz Andrzej Jodłowski Alina Stasiecka. Zarys metodyki wspierającej naukę projektowania systemów informacyjnych
Ewa Stemposz Andrzej Jodłowski Alina Stasiecka Zarys metodyki wspierającej naukę projektowania systemów informacyjnych Dr inż. Ewa Stemposz prowadzi działalność naukowo-dydaktyczną w Polsko-Japońskiej
Bardziej szczegółowoSummary in Polish. Fatimah Mohammed Furaiji. Application of Multi-Agent Based Simulation in Consumer Behaviour Modeling
Summary in Polish Fatimah Mohammed Furaiji Application of Multi-Agent Based Simulation in Consumer Behaviour Modeling Zastosowanie symulacji wieloagentowej w modelowaniu zachowania konsumentów Streszczenie
Bardziej szczegółowoDiagramu Związków Encji - CELE. Diagram Związków Encji - CHARAKTERYSTYKA. Diagram Związków Encji - Podstawowe bloki składowe i reguły konstrukcji
Diagramy związków encji (ERD) 1 Projektowanie bazy danych za pomocą narzędzi CASE Materiał pochodzi ze strony : http://jjakiela.prz.edu.pl/labs.htm Diagramu Związków Encji - CELE Zrozumienie struktury
Bardziej szczegółowoPolityka bezpieczeństwa przeznaczona dla administratora danych, który nie powołał administratora bezpieczeństwa informacji
Polityka bezpieczeństwa przeznaczona dla administratora danych, który nie powołał administratora bezpieczeństwa informacji POLITYKA BEZPIECZEŃSTWA. 1 1. PODSTAWA PRAWNA Niniejsza Polityka bezpieczeństwa
Bardziej szczegółowoAnaliza 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ółowoWdrożenie nowych proinnowacyjnych usług sprzyjających dyfuzji innowacji w sektorze MSP nr umowy: U- POIG.05.02.00-00-016/10-00
Regulamin usługi Wdrożenie nowych proinnowacyjnych usług sprzyjających dyfuzji innowacji w sektorze MSP nr umowy: U- POIG.05.02.00-00-016/10-00 Projekt realizowany jest w ramach Działania 5.2 Wsparcie
Bardziej szczegółowoBazy danych. Zachodniopomorski Uniwersytet Technologiczny w Szczecinie. Wykład 3: Model związków encji.
Zachodniopomorski Uniwersytet Technologiczny w Szczecinie Bazy danych Wykład 3: Model związków encji. dr inż. Magdalena Krakowiak makrakowiak@wi.zut.edu.pl Co to jest model związków encji? Model związków
Bardziej szczegółowoModelowanie obiektowe - Ćw. 3.
1 Modelowanie obiektowe - Ćw. 3. Treść zajęć: Diagramy przypadków użycia. Zasady tworzenia diagramów przypadków użycia w programie Enterprise Architect. Poznane dotychczas diagramy (czyli diagramy klas)
Bardziej szczegółowoNazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH. Modeling and analysis of computer systems Forma studiów: Stacjonarne
Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH Kierunek: Informatyka Modeling and analysis of computer systems Forma studiów: Stacjonarne Rodzaj przedmiotu: obowiązkowy w ramach specjalności:
Bardziej szczegółowoPodstawy programowania III WYKŁAD 4
Podstawy programowania III WYKŁAD 4 Jan Kazimirski 1 Podstawy UML-a 2 UML UML Unified Modeling Language formalny język modelowania systemu informatycznego. Aktualna wersja 2.3 Stosuje paradygmat obiektowy.
Bardziej szczegółowoMetoda generowania typowych scenariuszy awaryjnych w zakładach dużego i zwiększonego ryzyka - ExSysAWZ
Metoda generowania typowych scenariuszy awaryjnych w zakładach dużego i zwiększonego ryzyka - ExSysAWZ A.S. Markowski, M. Pietrzykowski, R.J. Żyłła Politechnika Łódzka Katedra Inżynierii Bezpieczeństwa
Bardziej szczegółowoProjektowanie systemów informatycznych. wykład 6
Projektowanie systemów informatycznych wykład 6 Iteracyjno-przyrostowy proces projektowania systemów Metodyka (ang. methodology) tworzenia systemów informatycznych (TSI) stanowi spójny, logicznie uporządkowany
Bardziej szczegółowoFeature Driven Development
Feature Driven Development lekka metodyka tworzenia oprogramowania Kasprzyk Andrzej IS II Wstęp Feature Driven Development (FDD) to metodyka tworzenia oprogramowania, która wspomaga zarządzanie fazami
Bardziej szczegółowoZasady 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ółowoWprowadzenie do metodologii modelowania systemów informacyjnych. Strategia (1) Strategia (2) Etapy Ŝycia systemu informacyjnego
Etapy Ŝycia systemu informacyjnego Wprowadzenie do metodologii modelowania systemów informacyjnych 1. Strategia 2. Analiza 3. Projektowanie 4. Implementowanie, testowanie i dokumentowanie 5. WdroŜenie
Bardziej szczegółowoBezpieczeństwo danych w sieciach elektroenergetycznych
Bezpieczeństwo danych w sieciach elektroenergetycznych monitorowanie bezpieczeństwa Janusz Żmudziński Polskie Towarzystwo Informatyczne Nadużycia związane z bezpieczeństwem systemów teleinformatycznych
Bardziej szczegółowoWybawi się od niebezpieczeństwa jedynie ten, kto czuwa także gdy czuje się bezpieczny Publiusz Siro. Audyt bezpieczeństwa
Wybawi się od niebezpieczeństwa jedynie ten, kto czuwa także gdy czuje się bezpieczny Publiusz Siro Audyt bezpieczeństwa Definicja Audyt systematyczna i niezależna ocena danej organizacji, systemu, procesu,
Bardziej szczegółowoInżynieria oprogramowania
Inżynieria oprogramowania Instrukcja do laboratorium rok akad. 2014/2015 Informacje podstawowe: Celem laboratorium jest nabycie przez studentów praktycznej umiejętności wykonywania modeli analitycznych
Bardziej szczegółowoEtapy życia oprogramowania
Modele cyklu życia projektu informatycznego Organizacja i Zarządzanie Projektem Informatycznym Jarosław Francik marzec 23 w prezentacji wykorzystano również materiały przygotowane przez Michała Kolano
Bardziej szczegółowoProjekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON
Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON Opis szkoleń z obszaru INFORMATYKA planowanych
Bardziej szczegółowoInżynieria Oprogramowania w Praktyce
Inżynieria Oprogramowania w Praktyce Ogólna prezentacja kierunku Projekt współfinansowany ze środków Unii Europejskiej w ramach Europejskiego Funduszu Społecznego. www.aict.pjwstk.edu.pl 1 Kogo chcemy
Bardziej szczegółowoInżynieria oprogramowania. Wykład 6 Analiza i specyfikowanie wymagań
Inżynieria oprogramowania Wykład 6 Analiza i specyfikowanie wymagań Proces inżynierii wymagań Feasibility Study Feasibility Report Requirements Analysis System Models Requirements Definition Definition
Bardziej szczegółowoFMEA. Tomasz Greber tomasz@greber.com.pl. Opracował: Tomasz Greber (www.greber.com.pl)
FMEA Tomasz Greber tomasz@greber.com.pl FMEA MYŚLEĆ ZAMIAST PŁACIĆ Dlaczego FMEA? Konkurencja Przepisy Normy (ISO 9000, TS 16949 ) Wymagania klientów Powstawanie i wykrywanie wad % 75% powstawania wad
Bardziej szczegółowoMetodyka zarządzania ryzykiem w obszarze bezpieczeństwa informacji
2012 Metodyka zarządzania ryzykiem w obszarze bezpieczeństwa informacji Niniejszy przewodnik dostarcza praktycznych informacji związanych z wdrożeniem metodyki zarządzania ryzykiem w obszarze bezpieczeństwa
Bardziej szczegółowoSTATYSTYKA EKONOMICZNA
STATYSTYKA EKONOMICZNA Analiza statystyczna w ocenie działalności przedsiębiorstwa Opracowano na podstawie : E. Nowak, Metody statystyczne w analizie działalności przedsiębiorstwa, PWN, Warszawa 2001 Dr
Bardziej szczegółowoZestawienie metod, technik i narzędzi badawczych wykorzystywanych przez urzędy podczas przeprowadzania diagnozy
Zestawienie metod, technik i narzędzi badawczych wykorzystywanych przez urzędy podczas przeprowadzania diagnozy Lp. Metody / narzędzia Informacje / objaśnienia 1 ANALIZA W tej kategorii znajdują się dokumenty,
Bardziej szczegółowoUsługi analityczne budowa kostki analitycznej Część pierwsza.
Usługi analityczne budowa kostki analitycznej Część pierwsza. Wprowadzenie W wielu dziedzinach działalności człowieka analiza zebranych danych jest jednym z najważniejszych mechanizmów podejmowania decyzji.
Bardziej szczegółowoAgile vs PRINCE2. 2014/2015 I rok st. magisterskie Informatyka
Agile vs PRINCE2 Ewa Solecka - specjalność ogólna- 1117627 Przemysław Mrozowski specjalność ogólna- 1121130 Michał Roztoczyński specjalność ogólna - 1118910 2014/2015 I rok st. magisterskie Informatyka
Bardziej szczegółowoPytania z przedmiotów kierunkowych
Pytania na egzamin dyplomowy z przedmiotów realizowanych przez pracowników IIwZ studia stacjonarne I stopnia Zarządzanie i Inżynieria Produkcji Pytania z przedmiotów kierunkowych 1. Co to jest algorytm?
Bardziej szczegółowoPromotor: 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ółowoRysunek 1: Przykłady graficznej prezentacji klas.
4 DIAGRAMY KLAS. 4 Diagramy klas. 4.1 Wprowadzenie. Diagram klas - w ujednoliconym języku modelowania jest to statyczny diagram strukturalny, przedstawiający strukturę systemu w modelach obiektowych przez
Bardziej szczegółowoPOLITYKA BEZPIECZEŃSTWA w zakresie ochrony danych osobowych w ramach serwisu zgloszenia24.pl
POLITYKA BEZPIECZEŃSTWA w zakresie ochrony danych osobowych w ramach serwisu zgloszenia24.pl SPIS TREŚCI I. POSTANOWIENIA OGÓLNE... 2 II. DEFINICJA BEZPIECZEŃSTWA INFORMACJI... 2 III. ZAKRES STOSOWANIA...
Bardziej szczegółowoAkupunktura Trudności w projektowaniu badań klinicznych
Akupunktura Trudności w projektowaniu badań klinicznych AKUPUNKTURA TRUDNOŚCI W PROJEKTOWANIU BADAŃ KLINICZNYCH Bartosz Chmielnicki słowa kluczowe: Akupunktura, metodologia, medycyna oparta na faktach,
Bardziej szczegółowoMaciej Byczkowski ENSI 2017 ENSI 2017
Znaczenie norm ISO we wdrażaniu bezpieczeństwa technicznego i organizacyjnego wymaganego w RODO Maciej Byczkowski Nowe podejście do ochrony danych osobowych w RODO Risk based approach podejście oparte
Bardziej szczegółowoAnaliza i projektowanie obiektowe 2017/2018. Wykład 3: Model wiedzy dziedzinowej
Analiza i projektowanie obiektowe 2017/2018 Wykład 3: Model wiedzy dziedzinowej Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Model wiedzy dziedzinowej
Bardziej szczegółowoDiagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska
Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Wprowadzenie Modelowanie biznesowe jest stykiem między
Bardziej szczegółowoWPROWADZENIE DO UML-a
WPROWADZENIE DO UML-a Maciej Patan Instytut Sterowania i Systemów Informatycznych Dlaczego modelujemy... tworzenie metodologii rozwiązywania problemów, eksploracja różnorakich rozwiązań na drodze eksperymentalnej,
Bardziej szczegółowoAnaliza i projektowanie obiektowe w UML Kod przedmiotu
Analiza i owanie obiektowe w UML - opis przedmiotu Informacje ogólne Nazwa przedmiotu Analiza i owanie obiektowe w UML Kod przedmiotu 11.3-WK-MATP-UML-W-S14_pNadGen5M44E Wydział Kierunek Wydział Matematyki,
Bardziej szczegółowoWykład I. Wprowadzenie do baz danych
Wykład I Wprowadzenie do baz danych Trochę historii Pierwsze znane użycie terminu baza danych miało miejsce w listopadzie w 1963 roku. W latach sześcdziesątych XX wieku został opracowany przez Charles
Bardziej szczegółowoSystemy zarządzania bezpieczeństwem informacji: co to jest, po co je budować i dlaczego w urzędach administracji publicznej
Systemy zarządzania bezpieczeństwem informacji: co to jest, po co je budować i dlaczego w urzędach administracji publicznej Wiesław Paluszyński Prezes zarządu TI Consulting Plan prezentacji Zdefiniujmy
Bardziej szczegółowoTematy prac magisterskich Rok akademicki 2013/2014
Dr hab. inż. Jan Werewka, prof. n. AGH Wydział EAIiIB AGH E-mail: werewka@agh.edu.pl www: http://home.agh.edu.pl/werewka Tematy prac magisterskich Rok akademicki 2013/2014 Temat 1 Architektura przedsięwzięcia
Bardziej szczegółowoMODEL KOMPETENCYJNY DYREKTORA
MODEL KOMPETENCYJNY DYREKTORA JAKO NARZĘDZIE WSPOMAGAJĄCE ZARZĄDZANIE PLACÓWKĄ ZARZĄDZANIE PO WROCŁAWSKU prof. UWr Kinga Lachowicz-Tabaczek Instytut Psychologii Uniwersytetu Wrocławskiego, HR Projekt Wrocław
Bardziej szczegółowoNarzędzia CASE dla.net. Łukasz Popiel
Narzędzia CASE dla.net Autor: Łukasz Popiel 2 Czym jest CASE? - definicja CASE (ang. Computer-Aided Software/Systems Engineering) g) oprogramowanie używane do komputerowego wspomagania projektowania oprogramowania
Bardziej szczegółowoProces badawczy schemat i zasady realizacji
Proces badawczy schemat i zasady realizacji Agata Górny Zaoczne Studia Doktoranckie z Ekonomii Warszawa, 23 października 2016 Metodologia i metoda naukowa 1 Metodologia Metodologia nauka o metodach nauki
Bardziej szczegółowoCzym jest jakość? Według najbardziej
Są to cechy istotne z punktu widzenia konsumenta. Producent musi oprócz tego brać pod uwagę zyskowność i działalność konkurencji, co często jest w konflikcie z jakością technologiczną produktu. Bardzo
Bardziej szczegółowoOpis metodyki i procesu produkcji oprogramowania
Opis metodyki i procesu produkcji oprogramowania Rational Unified Process Rational Unified Process (RUP) to iteracyjny proces wytwarzania oprogramowania opracowany przez firmę Rational Software, a obecnie
Bardziej szczegółowoZalety projektowania obiektowego
Zalety projektowania obiektowego Łatwe zarządzanie Możliwość powtórnego użycia klas obiektów projektowanie/programowanie komponentowe W wielu przypadkach występuje stosunkowo proste mapowanie pomiędzy
Bardziej szczegółowoPodstawy modelowania programów Kod przedmiotu
Podstawy modelowania programów - opis przedmiotu Informacje ogólne Nazwa przedmiotu Podstawy modelowania programów Kod przedmiotu 11.3-WI-INFP-PMP Wydział Kierunek Wydział Informatyki, Elektrotechniki
Bardziej szczegółowoZapewnij sukces swym projektom
Zapewnij sukces swym projektom HumanWork PROJECT to aplikacja dla zespołów projektowych, które chcą poprawić swą komunikację, uprościć procesy podejmowania decyzji oraz kończyć projekty na czas i zgodnie
Bardziej szczegółowoWykład 1 Inżynieria Oprogramowania
Wykład 1 Inżynieria Oprogramowania Wstęp do inżynierii oprogramowania. Cykle rozwoju oprogramowaniaiteracyjno-rozwojowy cykl oprogramowania Autor: Zofia Kruczkiewicz System Informacyjny =Techniczny SI
Bardziej szczegółowoAnaliza i projektowanie obiektowe 2016/2017. Wykład 8: Przypisywanie obiektom odpowiedzialności (2)
Analiza i projektowanie obiektowe 2016/2017 Wykład 8: Przypisywanie obiektom odpowiedzialności (2) Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Wzorce
Bardziej szczegółowoArchitektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu.
Architektura Systemu Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu. Architektura jest zbiorem decyzji dotyczących: organizacji systemu komputerowego,
Bardziej szczegółowoEtapy życia oprogramowania. Modele cyklu życia projektu. Etapy życia oprogramowania. Etapy życia oprogramowania
Etapy życia oprogramowania Modele cyklu życia projektu informatycznego Organizacja i Zarządzanie Projektem Informatycznym Jarosław Francik marzec 23 Określenie wymagań Testowanie Pielęgnacja Faza strategiczna
Bardziej szczegółowoWaterfall model. (iteracyjny model kaskadowy) Marcin Wilk
Waterfall model (iteracyjny model kaskadowy) Marcin Wilk Iteracyjny model kaskadowy jeden z kilku rodzajów procesów tworzenia oprogramowania zdefiniowany w inżynierii oprogramowania. Jego nazwa wprowadzona
Bardziej szczegółowoUML w Visual Studio. Michał Ciećwierz
UML w Visual Studio Michał Ciećwierz UNIFIED MODELING LANGUAGE (Zunifikowany język modelowania) Pozwala tworzyć wiele systemów (np. informatycznych) Pozwala obrazować, specyfikować, tworzyć i dokumentować
Bardziej szczegółowoKOSZTY JAKOŚCI JAKO NARZĘDZIE ZARZĄDZANIA JAKOŚCIĄ
Narzędzia jakości w doskonaleniu i zarządzaniu jakością, red. Sikora T., Akademia Ekonomiczna w Krakowie, Kraków 2004, ss. 137-141 Urszula Balon Katedra Towaroznawstwa Ogólnego i Zarządzania Jakością Akademia
Bardziej szczegółowoBłędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation)
Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation) Zarządzanie wymaganiami Ad hoc (najczęściej brak zarządzania nimi) Niejednoznaczna, nieprecyzyjna komunikacja Architektura
Bardziej szczegółowoZmiany wymagań normy ISO 14001
Zmiany wymagań normy ISO 14001 Międzynarodowa Organizacja Normalizacyjna (ISO) opublikowała 15 listopada br. zweryfikowane i poprawione wersje norm ISO 14001 i ISO 14004. Od tego dnia są one wersjami obowiązującymi.
Bardziej szczegółowoNarzędzia Informatyki w biznesie
Narzędzia Informatyki w biznesie Przedstawiony program specjalności obejmuje obszary wiedzy informatycznej (wraz z stosowanymi w nich technikami i narzędziami), które wydają się być najistotniejsze w kontekście
Bardziej szczegółowoProjektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Modelowanie danych Diagramy ERD
Projektowanie systemów informatycznych Roman Simiński roman.siminski@us.edu.pl siminskionline.pl Modelowanie danych Diagramy ERD Modelowanie danych dlaczego? Od biznesowego gadania do magazynu na biznesowe
Bardziej szczegółowoPOLITYKA BEZPIECZEŃSTWA OCHRONY DANYCH OSOBOWYCH w przedsiębiorstwie QBL Wojciech Śliwka Daszyńskiego 70c, Ustroń
POLITYKA BEZPIECZEŃSTWA OCHRONY DANYCH OSOBOWYCH w przedsiębiorstwie QBL Wojciech Śliwka Daszyńskiego 70c, 43-450 Ustroń Administrator Danych Osobowych: Wojciech Śliwka 1. PODSTAWA PRAWNA Niniejsza Polityka
Bardziej szczegółowoKARTA PRZEDMIOTU. 1. Informacje ogólne. 2. Ogólna charakterystyka przedmiotu. Inżynieria oprogramowania, C12
KARTA PRZEDMIOTU 1. Informacje ogólne Nazwa przedmiotu i kod (wg planu studiów): Nazwa przedmiotu (j. ang.): Kierunek studiów: Specjalność/specjalizacja: Poziom kształcenia: Profil kształcenia: Forma studiów:
Bardziej szczegółowoCel walidacji- zbadanie, czy procedura/wyrób/technologia/projekt/... może zostać w sposób niebudzący wątpliwości wprowadzona/y/e do użytkowania
1. Proszę krótko scharakteryzować w sposób "ilościowy": a) produkt i technologię wytwarzania tego produktu przez firmę którą założyła Pani/Pana podgrupa oraz wyjaśnić dlaczego wybrana technologia jest
Bardziej szczegółowoOpinia o pracy doktorskiej pt. On active disturbance rejection in robotic motion control autorstwa mgr inż. Rafała Madońskiego
Prof. dr hab. inż. Tadeusz Uhl Katedra Robotyki i Mechatroniki Akademia Górniczo Hutnicza Al. Mickiewicza 30 30-059 Kraków Kraków 09.06.2016 Opinia o pracy doktorskiej pt. On active disturbance rejection
Bardziej szczegółowo12) Wadą modelu kaskadowego jest: Zagadnienia obowiązujące na egzaminie z inżynierii oprogramowania: 13) Wadą modelu opartego na prototypowaniu jest:
Zagadnienia obowiązujące na egzaminie z inżynierii oprogramowania: 1) Oprogramowanie to: 2) Produkty oprogramowania w inżynierii oprogramowania można podzielić na: 3) W procesie wytwarzania oprogramowania
Bardziej szczegółowo