Modelowanie i analiza systemów informatycznych.
|
|
- Bartosz Kwiecień
- 8 lat temu
- Przeglądów:
Transkrypt
1 Modelowanie i analiza systemów informatycznych. dr Robert Plebaniak 12 stycznia 2014 roku
2 Metodyka RUP Wykład 10
3 Metodyka RUP Metodyka RUP
4 Metodyka RUP Znaczenie iteracyjno-przyrostowego procesu projektowania systemów Metodyka (ang. methodology) tworzenia systemów informatycznych (TSI) stanowi spójny, logicznie uporządkowany zestaw metod i procedur o charakterze technicznym i organizatorskim, pozwalających zespołowi projektowemu realizować cykl życia systemu. Ogólnie metodyki można podzielić na strukturalne, obiektowe i społeczne.
5 Metodyka RUP Podejście obiektowe Podobnie jak w przypadku metodyk strukturalnych, pojawił się szereg propozycji związanych z modelowaniem obiektowym. Największe uznanie zdobyły podejścia OMT, OOAD i OOSE, inkorporujące pewne elementy metodyki. Pierwsza próba unifikacji obiektowego procesu tworzenia systemu nosiła nazwę USDP (Unified Software Development Process). Autorami USDP są l. Jacobson, G. Booch oraz J. Rumbaugh. Jest to metodyka rodzajowa (ang. generic), stwarzająca możliwość opracowywania różnych jej konfiguracji i implementacji.
6 Metodyka RUP Metodyka rodzajowa Do głównych cech tego podejścia należą: ukierunkowanie na przypadki użycia; potraktowanie architektury systemu jako centralnego zagadnienia w procesie tworzenia oprogramowania; iteracyjno-przyrostowy charakter procesu tworzenia systemu.
7 Metodyka RUP RUP RUP (ang. Rational Unified Process ) to metodyka tworzenia systemów informatycznych oparta na paradygmacie obiektowości i języku UML, zaproponowana przez korporację Rational Software. Jako kompletna metodyka RUP zawiera następujące elementy: przyrostowo-iteracyjny cykl życia systemu; pojęcia, metody i techniki z zakresu języka UML i inne, w tym heurystyczne; zintegrowany pakiet narzędzi CASE, wspomagający stosowanie elementów metodyki; role zdefiniowane w zespole projektowym i procedury zarządzania projektem; kryteria oceny i monitorowania postępu prac; hipertekstową bazę wiedzy; internetowy serwis wspomagający metodykę i jej użytkowników.
8 Metodyka RUP RUP Metodyka RUP jest ukształtowana w sposób umożliwiający dopasowanie procesu tworzenia systemu do potrzeb konkretnego przedsięwzięcia na podstawie pełnego spektrum swoich możliwości. W efekcie RUP jest elastyczny - znajduje zastosowanie zarówno przy mniejszych, jak i dużych projektach informatycznych.
9 Metodyka RUP Rozwój metodyki RUP
10 Metodyka RUP RUP Najważniejsze obszary zmian w zakresie metodyki związane były z: rozwijaniem poszczególnych dyscyplin, w tym przepływów pracy oraz dotyczących ich dokumentów; wprowadzeniem modułów dodatkowych (ang. plug-ins) RUP oraz integracją i włączaniem nowych narzędzi CASE, wspomagających metodykę RUP; reorganizacją układu hipertekstowej bazy wiedzy; zdefiniowanymi w metodyce artefaktami - modelami i dokumentami.
11 Metodyka RUP USDP Założenia rodzajowej metodyki USDP, iteracyjno-przyrostowy cykl życia systemu, a także kategorie modelowania języka UML wykorzystywane są przez inne, aktualnie rozwijane metodyki obiektowe. Do najbardziej interesujących należą: XP (Extreme Programming); Agile; Scrum, DSDM (Dynamie Systems Development Method).
12 Metodyka RUP Struktura RUP Przez kilka dekad dominującym wzorcem cyklu życia systemu był cykl liniowy, a później spiralny. Metodyka RUP opiera się na zasadniczym novum - iteracyjno przyrostowym (ang. iterative-incremental) cyklu życia systemu. Ma on postać dwuwymiarową.
13 Metodyka RUP Struktura RUP Linia pozioma reprezentuje czas, a zatem dynamiczny aspekt procesu TSI, uwzględniając: fazy; iteracje; punkty przeglądu. Z kolei linia pionowa odzwierciedla statyczny aspekt procesu TSI, tj. jego opis w kategoriach: dyscyplin; czynności; artefaktów; ról; przepływów pracy.
14 Metodyka RUP Struktura RUP
15 Metodyka RUP Rola Rola oznacza obowiązki i kompetencje osoby lub zespołu zaangażowanego w proces tworzenia systemu informatycznego lub jego wycinka. W wyniku realizacji roli powstają oczekiwane artefakty. Spektrum ról, odpowiadających często współczesnym zawodom informatycznym, jest bardzo szerokie i wiąże się z możliwościami zaawansowanych technologii informatycznych. Przykładami ról w metodyce RUP są: menadżer projektu, inzynier procesu, analityk procesów biznesowych, analityk systemowy, projektant testów, testujacy, specjalista ds. narzędzi CASE. Przepływ pracy - stanowi sekwencję czynności, w wyniku której powstaje lub jest przetwarzany artefakt.
16 Metodyka RUP Dyscypliny Dyscyplina (ang. discipline), jest kolekcją powiązanych czynności, artefaktów, ról oraz przepływów pracy odpowiadających tematycznie głównym obszarom tworzenia systemów informatycznych.
17 Metodyka RUP Dyscypliny podstawowe Dyscypliny podstawowe stanowią rdzeń procesu tworzenia systemu. Należą do nich: modelowanie biznesowe; specyfikacja wymagań; analiza i projektowanie; programowanie; testowanie; wdrożenie.
18 Metodyka RUP Dyscypliny wspomagające Dyscypliny wspomagające realizują funkcje zarządcze i konfiguracyjne w procesie tworzenia systemu. Można do nich zaliczyć: zarządzanie konfiguracjami i zmianami; zarządzanie projektem; przygotowanie środowiska.
19 Metodyka RUP Układ i zależności pomiędzy wymienionymi dyscyplinami
20 Metodyka RUP Podstawowy zakres merytoryczny dyscyplin w procesie RUP Modelowanie biznesowe (ang. - business modeling) zawiera wizję nowej, docelowej organizacji, definicje występujących w jej ramach procesów, ról i zakresów odpowiedzialności. Informacje te przedstawia się w postaci biznesowych diagramów. Specyfikacja wymagań (ang. requirements) - oznacza opracowanie wizji systemu, modelu przypadków użycia i zdefiniowanie wymagań niefunkcjonalnych.
21 Metodyka RUP Podstawowy zakres merytoryczny dyscyplin w procesie RUP Analiza i projektowanie (ang. analysis and design ) - zawiera analizę i projekt systemu z wykorzystaniem całego spektrum diagramów UML. Programowanie (ang. implementation ) - pozwala na opracowanie kodu źródłowego w wybranym języku programowania oraz kompilację kodu i integrację komponentów. Testowanie (ang. test) - oznacza planowanie testów oraz ocenę systemu poprzez wykonanie szeregu testów.
22 Metodyka RUP Podstawowy zakres merytoryczny dyscyplin w procesie RUP Wdrożenie (ang. deployment ) - dotyczy instalacji oprogramowania systemu i formalną akceptację kolejnych wersji systemu przez klienta czy użytkownika. Zarządzanie konfiguracjami i zmianami (ang. configuration and change menagement) - obejmuje kontrole wersji artefaktów opracowanych podczas kolejnych iteracji. Zarządzanie projektem (ang. project menagement) - oznacza planowanie i kontrole realizacji projektu. Przygotowanie środowiska (ang. environment) - obejmuje przygotowanie infrastruktury dla skutecznej realizacji projektu.
23 Metodyka RUP Fazy Fazą (ang. phase) w metodyce RUP jest okres między kolejnymi punktami przeglądu cyklu iteracyjno-przyrostowego, w którym zrealizowano niezbędne czynności i opracowano adekwatne artefakty. Metodyka RUP wprowadza cztery fazy: rozpoczęcie (ang. inception); opracowanie (ang. elaboration); budowa (ang. construction); przekazanie (ang. transition).
24 Metodyka RUP Iteracje System informatyczny jest rozwijany w kolejnych iteracjach (ang. iterations), występujących w ramach każdej z wymienionych faz. Przejście pomiędzy iteracjami poprzedza przyrostowa integracja artefaktów otrzymanych we wszystkich dotychczasowych iteracjach. Iteracja w metodyce RUP to pojedynczy cykl w ramach fazy, polegający na realizacji czynności poszczególnych dyscyplin; jej efektem jest kolejny przyrost systemu.
25 Metodyka RUP Fazy w metodyce RUP i ich cele Rozpoczęcie (ang. inception) - wypracowanie ogólnej wizji przedsięwzięcia oraz osiągnięcie zrozumienia i akceptacji projektu ze strony wszystkich jego uczestników. Opracowanie (ang. elaboration) - ustalenie architektury systemu, stworzenie planu projektu oraz wyeliminowanie elementów wysokiego ryzyka z projektu. Budowa (ang. construction) - stworzenie systemu na podstawie przyjętej architektury. Przekazanie (ang. transition) - dostarczenie gotowego systemu użytkownikom czy klientom.
26 Modelowanie biznesowe Modelowanie biznesowe
27 Modelowanie biznesowe Znaczenie modelowania biznesowego W procesie tworzenia systemu zgodnym z metodyką RUP pierwszą dyscypliną iteracyjno-przyrostowego cyklu życia systemu jest modelowanie biznesowe. Modelowanie biznesowe (ang. business modeling) jest sposobem odwzorowywania i dokumentowania procesów biznesowych. W nawiązaniu do kategorii modelowania języka UML, wyróżnić można: modelowanie systemowe - ukierunkowane na tworzenie systemu informatycznego, jego oprogramowania oraz infrastruktury sprzętowej; modelowanie biznesowe.
28 Modelowanie biznesowe Reengineering Modelowanie biznesowe można połączyć z reengineeringiem procesów biznesowych (ang. Business Process Reengineering) - w skrócie BPR - w przypadku, gdy zamierza się dokonać radykalnej zmiany funkcjonowania organizacji i opracować modele nowych procesów biznesowych. Modele biznesowe znajdują zastosowanie przede wszystkim w pierwszej fazie cyklu życia RUP, fazie rozpoczęcia, a w mniejszym zakresie także w kolejnych fazach (opracowaniu, budowie oraz przekazaniu).
29 Modelowanie biznesowe Modelowanie biznesowe w procesie tworzenia systemu
30 Modelowanie biznesowe Podstawowe kategorie pojęciowe oraz notacja graficzna Model biznesowy, podobnie jak model systemu informatycznego, jest przedstawiany w postaci diagramów. Diagramy biznesowe są w ujęciu czysto technicznym odpowiednikami diagramów systemowych. Tak więc możliwe jest przystosowanie do potrzeb modelowania biznesowego większości diagramów wymienionych w specyfikacji języka UML 2.0, czyli: diagramów przypadków użycia; diagramów klas; diagramów obiektów; diagramów czynności; diagramów maszyny stanowej; diagramów interakcji; diagramów struktur połączonych; diagramów pakietów.
31 Modelowanie biznesowe Praktyczne zastosowanie Ze względu na specyfikę funkcjonowania rzeczywistych organizacji największe praktyczne zastosowanie mają następujące rodzaje diagramów biznesowych: biznesowe diagramy przypadków użycia; biznesowe diagramy klas; biznesowe diagramy czynności; biznesowe diagramy sekwencji; biznesowe diagramy pakietów.
32 Modelowanie biznesowe Podstawowe kategorie modelowania diagramów biznesowych W przypadku modelowania biznesowego niezbędne stają się kategorie modelowania, które nie są elementami diagramów opisujących oprogramowanie. Kategorie te mają charakter stereotypów graficznych. Biznesowe diagramy stworzone w ramach modelowania biznesowego są transformowane w kolejnych fazach iteracyjno-przyrostowego cyklu RUP w analityczne lub systemowe diagramy języka UML. Transformacja diagramów biznesowych w systemowe nie zachodzi automatycznie. Do osiągnięcia ostatecznego efektu modelowania systemowego niezbędna jest praca analityczna i projektowa twórców systemu, stosownie do zaleceń UML i RUP.
33 Modelowanie biznesowe Podstawowe kategorie modelowania diagramów biznesowych
34 Modelowanie biznesowe Podstawowe kategorie modelowania diagramów biznesowych
35 Modelowanie biznesowe Podstawowe kategorie modelowania diagramów biznesowych
36 Modelowanie biznesowe Biznesowy kontekst systemu księgarni
37 Modelowanie biznesowe Biznesowy diagram przypadków użycia systemu księgarni
38 Modelowanie biznesowe Mapa procesów biznesowych funkcjonowania księgarni
39 Modelowanie biznesowe Czynność przypadku Dokonaj zakupu
40 Modelowanie biznesowe Biznesowy diagram sekwencji
41 Modelowanie biznesowe Biznesowy diagram klas
42 Modelowanie biznesowe Biznesowy diagram klas z pracownikami biznesowymi
43 Modelowanie biznesowe Jednostki organizacyjne księgarni
44 Modelowanie biznesowe Zależność pomiędzy działami a pracownikami
45 Modelowanie biznesowe Koniec wykładu 10.
46 Modelowanie analityczne Wykład 11
47 Modelowanie analityczne Modelowanie analityczne
48 Modelowanie analityczne Znaczenie modelowania analitycznego Modelowanie analityczne to technika wspomagająca język UML, która słóży do dokumentowania wyników prac analitycznych i wczesnych prac projektowych. Diagramy modelowania analitycznego wspomagają dyscyplinę analizy i projektowania; zostały zaproponowane przez I. Jacobsona w metodyce OOSE [Jacobson-1992]. W praktyce diagramy te umożliwiają przejście od diagramów przypadków użycia oraz ich scenariuszy do diagramów klas oraz diagramów interakcji na poziomie konceptualnym i implementacyjnym.
49 Modelowanie analityczne Diagram modelowania analitycznego w procesie tworzenia systemu
50 Modelowanie analityczne Podstawowe kategorie pojęciowe oraz notacja graficzna Model analityczny (ang. analysislrobustness model), grupujący diagramy analityczne, można traktować jako rodzaj wstępnego projektu. Jego celem jest wspomaganie identyfikacji klas. Podstawowymi elementami diagramów modelowania analitycznego są: klasy analityczne; aktorzy; związki.
51 Modelowanie analityczne Notacja graficzna Diagramy analityczne modelowane są jako diagramy klas z zastosowaniem trzech stereotypowanych klas: granicznych (ang. boundary); sterujących (ang. control); przechowujących (ang. entity).
52 Modelowanie analityczne Notacja W praktyce podczas analizy scenariuszy przypadku użycia identyfikuje się obiekty analityczne, które podczas projektowania systemu ulegają przekształceniu w różne kategorie modelowania właściwe dla poziomu implementacyjnego, takie jak atrybuty klas, operacje lub same klasy. W związku z tym te kategorie modelowania analitycznego w literaturze przedmiotu określane są często mianem obiektów analitycznych.
53 Modelowanie analityczne Notacja oraz charakterystyka klas analitycznych
54 Modelowanie analityczne Notacja oraz charakterystyka klas analitycznych
55 Modelowanie analityczne Notacja oraz charakterystyka klas analitycznych
56 Modelowanie analityczne Notacja oraz charakterystyka W trakcie opracowywania diagramów modelowania analitycznego wykorzystywany jest również symbol aktora zaczerpnięty z diagramów przypadków użycia. Poszczególne typy klas są powiązane. Kluczowe znaczenie odgrywa w tym kontekście związek asocjacji, przy czym asocjacje te mogą być dwukierunkowe lub mieć przypisany kierunek nawigacji uszczegóławiający specyfikację sposobu przepływu informacji.
57 Modelowanie analityczne Diagram analityczny
58 Modelowanie analityczne Zasady obowiązujące w diagramach modelowania analitycznego Przyjmujemy nastepujce oznaczenia; symbol + oznacza, że elemanty wyszczególnione w danym wierszu i kolumnie mogą się łączyć; symbol - łączenie elementów wyszczgólnionych w danym wierszu i kolumnie jest niepoprawne.
59 Modelowanie analityczne Zasady obowiązujące w diagramach modelowania analitycznego
60 Modelowanie analityczne Proces tworzenia modelu analitycznego Tworzenie diagramów modelowania analitycznego poprzedzone jest w ramach iteracyjno-przyrostowego procesu RUP modelowaniem biznesu oraz specyfikacją wymagań tworzonego systemu w postaci systemowych diagramów przypadków użycia. Stąd proces ten można podzielić na następujące etapy: 1. wyselekcjonowanie, stosownie do złożoności dziedziny przedmiotowej, odpowiednich: diagramów modelu biznesowego, diagramu (diagramów) przypadków użycia oraz jego (ich) scenariuszy; 2. przeniesienie aktorów z diagramów przypadków użycia na diagramy analityczne; 3. identyfikacją klas analitycznych i określenie ich rodzajów; 4. integracją poszczególnych zidentyfikowanych elementów w formie diagramów analitycznych składających się na model analityczny.
61 Modelowanie analityczne Konwersja kategorii biznesowych na kategorie klas analitycznych W trakcie tego procesu obowiązują określone zasady konwersji z modeli biznesowych i systemowych diagramów przypadków użycia na kategorie diagramów modelowania analitycznego. Analogicznie, należy zauważć, że sporządzenie klas analitycznych na podstawie systemowych przypadków użycia nie polega na bezpośredniej zamianie notacji. Konwersja systemowego modelu przypadków użycia na modele analityczne obejmuje przekształcenie aktorów w klasy graniczne bądź ich bezpośrednie przeniesienie. Natomiast przypadki użycia są przekształcane w odpowiednie rodzaje klas analitycznych - graniczne, sterujące i przechowujące. W dalszych iteracjach RUP klasy analityczne przekształcane są w klasy systemu.
62 Modelowanie analityczne Konwersja kategorii biznesowych na kategorie klas analitycznych
63 Modelowanie analityczne Konwersja kategorii biznesowych na kategorie klas analitycznych
64 Modelowanie analityczne Model analityczny
65 Komputerowe wspomaganie modelowania systemu Komputerowe wspomaganie modelowania systemu
66 Komputerowe wspomaganie modelowania systemu Pakiety CASE wspomagajce UML i RUP Metodyki tworzenia systemów informatycznych są komputerowo wspomagane przez narzędzia CASE (Computer Aided Software Engineering). Firmy komputerowe oraz naukowe środowisko informatyczne opracowały wiele tego typu narzędzi modelowania systemów. Ich znaczenie rośnie wraz ze wzrostem zakresu projektu, co skutkuje rozbudowaną i niezwykle trudną w zarządzaniu dokumentacją. Zarówno metodyka RUP, jak i język UML są wspomagane przez narzędzia CASE.
67 Komputerowe wspomaganie modelowania systemu Pakiet CASE Zastosowanie narzędzi CASE pozwala na wykonanie następujących zadań w procesie tworzenia systemów: wspomaganie specyfikacji i dokumentowania projektów informatycznych; sprawdzanie semantycznej poprawności diagramów UML i modelu jako całości; wspomaganie iteracyjno-przyrostowego cyklu życia systemu; generowanie szkieletowego kodu źródłowego na podstawie modelu systemu; inżynierię zwrotną (ang. reverse engineering); synchronizację modelu systemu z kodem źródłowym; możliwość równoległego tworzenia oprogramowania przez wielu członków zespołu projektowego.
68 Komputerowe wspomaganie modelowania systemu Pakiety CASE Stopień akceptacji oprogramowania CASE, ukierunkowanego na język UML i metodykę RUP, jest w środowisku profesjonalnym zróżnicowany. W niektórych przypadkach jest ono traktowane jako nieodłączny element tworzenia oprogramowania, w innych wykorzystywane są jedynie poszczególne funkcje.
69 Komputerowe wspomaganie modelowania systemu Wybrane narzędzia CASE dla UML i RUP
70 Komputerowe wspomaganie modelowania systemu Zakres wspomagania diagramów UML Wprowadźmy następujące oznaczenia: ud - diagram przypadków użycia; cld - diagram klas; sm - diagram maszyny stanowej; ad - diagram czynności; csd - diagram struktur połączonych;
71 Komputerowe wspomaganie modelowania systemu Zakres wspomagania diagramów UML iod - diagram sterowania interakcją; sd - diagram sekwencji; cd - diagram komunikacji; cod - diagram komponentów; dd - diagram rozlokowania; td - diagram harmonogramowania.
72 Komputerowe wspomaganie modelowania systemu Zakres wspomagania diagramów UML
73 Komputerowe wspomaganie modelowania systemu Zakres wspomagania diagramów UML
74 Komputerowe wspomaganie modelowania systemu Generowanie szkieletowego kodu źródłowego Generowanie kodu jest jedną z fundamentalnych opcji w cyklu życia systemu i ważną cechą narzędzia CASE. Naturalnie w efekcie jej wykorzystania nie powstaje pełna, możliwa do natychmiastowego uruchomienia aplikacja. Generowany kod źródłowy jest określany jako szkieletowy - generowana jest struktura oprogramowania, w szczególności klasy, atrybuty wraz z ich właściwościami, sygnatury operacji, związki pomiędzy elementami modelu i komponenty. Zawartość poszczegłlnych operacji musi być następnie uzupełniona przez programistów.
75 Komputerowe wspomaganie modelowania systemu Zaletywykorzystania funkcji generowania kodu Zalety wykorzystania funkcji generowania kodu: pomaga w utrzymaniu przejrzystości jego struktury i eliminuje wiele pomyłek technicznych, które programiści mogą popełnić na wczesnym etapie kodowania; zasadniczo skraca czas tworzenia gotowego systemu. Należy jednak pamietać, że: nie wyręcza jednak twórcy systemu w czynnościach innych niż rutynowe, takich jak projektowanie interfejsu użytkownika (GUI); wymaga także konsekwentnego przestrzegania pewnych reguł modelowania; wskazane jest ponadto wykorzystywanie funkcji sprawdzania poprawności semantycznej modelu przed przejściem do generowania kodu, jeśli opcja taka oferowana jest przez narzędzie CASE.
76 Komputerowe wspomaganie modelowania systemu Zestawienie możliwości generowania kodu oferowanych przez wyselekcjonowane narzędzia CASE
77 Komputerowe wspomaganie modelowania systemu Zestawienie możliwości generowania kodu oferowanych przez wyselekcjonowane narzędzia CASE
78 Komputerowe wspomaganie modelowania systemu Zestawienie możliwości generowania kodu oferowanych przez wyselekcjonowane narzędzia CASE
79 Komputerowe wspomaganie modelowania systemu Inżynieria zwrotna Zdolność przeprowadzenia inżynierii zwrotnej to zdolność do utworzenia bądź modyfikacji modelu systemu na podstawie kodu źródłowego aplikacji. Inżynieria zwrotna, wykorzystywana w połączeniu z funkcją generowania kodu źródłowego, umożliwia zachowanie spójności kodu systemu względem jego modelu. Zależność ta jest dwukierunkowa i jest określana mianem inżynierii wahadłowej (ang. round-trip engineering). Dzięki inżynierii zwrotnej można zsynchronizować oba te artefakty, nawet jeśli w kodzie dokonano zmian, nie nanosząc przy tym poprawek w dokumentacji. Praktyka tworzenia systemów informatycznych dowodzi, że posiadanie aktualnego modelu systemu jest nie do przecenienia.
80 Komputerowe wspomaganie modelowania systemu Inżynieria zwrotna
81 Komputerowe wspomaganie modelowania systemu Inżynieria zwrotna
82 Komputerowe wspomaganie modelowania systemu Obsługiwane platformy Wysiłki producentów oprogramowania narzędziowego zmierzające do wydłużenia listy obsługiwanych platform zwiększają elastyczność zespołu projektowego. Wspieranie systemów z rodziny Windows można określić jako powszechną praktykę. Jest tak w przypadku wszystkich analizowanych narzędzi. Popularną platformą jest również Linux. Jedynie narzędzia AnyLogic oraz Enterprise Architect nie występują w wersji przeznaczonej dla tego systemu operacyjnego. ArgoUML, Poseidon for UML oraz Together występują ponadto w wersji przeznaczonej dla systemu operacyjnego MacOS.
83 Komputerowe wspomaganie modelowania systemu Koniec wykładu 11.
84 Integracja systemów informatycznych Wykład 12
85 Integracja systemów informatycznych Integracja systemów informatycznych Integrację definiuje się jako połączenie niejednorodnych składników w całość, tak że współdziałając w ramach tej całości wzmagają swoją skuteczność. Podkreślany jest ten synergistyczny efekt integracji. Termin integracja odnoszony jest także do integracji zarządzania organizacją jego systemu informacyjnego. W takim ujęciu oznacza przede wszystkim integrację systemu zarządzania i systemów informacji zorientowanych na wspomaganie podejmowania decyzji, z których każdy już przedstawia określony poziom integracji. Jako podstawowy cel integracji systemów informatycznych wymienia się często integrację biznesu. Ta integracja biznesu jest możliwa do osiągnięcia za pomocą integracji procesów biznesowych poprzez rekonstrukcję i integrację samych procesów oraz systemów informacji, które wspomagają te procesy.
86 Integracja systemów informatycznych Integracja systemów informatycznych Integracja systemów informatycznych jest też rozważana w kontekście koncepcji M. Portera - łańcucha tworzenia wartości, odnoszącego się do działalności jednej firmy, jak i tzw. ciągów gospodarczych obejmujących kilka wewnątrzfirmowych łańcuchów gospodarczych. Stąd kryteria oceny poziomu integracji odnoszą się do współdziałania partnerów w tworzeniu wartości w ramach przedsiębiorstwa oraz partnerów biznesowych na rynku, sięgając aż do klientów.
87 Integracja systemów informatycznych Integracja W literaturze rozważane są różne typy, czy też formy integracji. Przykładowo wymienia się: integrację systemową (ang. system integration); integrację aplikacji (ang. application integration); integrację biznesową (ang. business integration).
88 Integracja systemów informatycznych Integracja systemowa Integracja systemowa jest rozumiana jako taka integracja, która dotyczy komunikacji między systemami, tj. połączenia i wymiany danych za pomocą sieci komputerowych i protokołów komunikacyjnych.
89 Integracja systemów informatycznych Integracja aplikacji Integracja aplikacji dotyczy współdziałania aplikacji realizowanych na różnych platformach sprzętowych i oprogramowania, jak również wspólnego użytkowania danych przez różne aplikacje (common shared data). Integracja aplikacji jest realizowana za pomocą tworzenia środowisk przetwarzania rozproszonego, interfejsów programów użytkowych API (Application Program Interfaces) i standardów w zakresie wymiany danych.
90 Integracja systemów informatycznych Integracja biznesowa Integracja biznesowa dotyczy koordynacji procesów gospodarczych. Wymaga zrozumienia zasad działania biznesu i precyzyjnego zdefiniowania reguł operacyjnych biznesu.
91 Integracja systemów informatycznych Usługi integracyjne Wyróznia się następujące rodzaje usług integracyjnych odpowiadających różnym poziomom integracji: kompleksowe usługi doradczo-biznesowe, mające na celu przebudowę firmy (ang. /T total solution provider) - integracja na poziomie biznesu; kompleksowe usługi, mające na celu doprowadzenie do wdrożenia oprogramowania biznesowego (ang. TT solution provider) - integracja na poziomie aplikacji; usługi z zakresu instalacji oprogramowania komunikacyjnego, biurowego, systemów operacyjnych (ang. IT systems integrator) - integracja na poziomie systemowym; usługi z zakresu instalacji sieci ( IT network systems integrator) - integracja na poziomie systemowym.
92 Integracja systemów informatycznych Integrator Jako typową paletę usług integratora wymienia się: integrację systemów w postaci sprzętu, sieci i oprogramowania różnych producentów, konsultacje dotyczące różnych etapów cyklu życia systemu, tworzenie oprogramowania na zamówienie klienta, zarządzanie projektami informatycznymi, utrzymywanie systemu komputerowego klienta, zapobieganie i usuwanie skutków katastrof. Coraz częściej poleca się usługi integratora intenetowego.
93 Integracja systemów informatycznych Integracja Krokami prowadzącymi do osiągnięcia pełnej integracji w dziedzinie systemów informatycznych jest osiągnięcie komputerowo zintegrowanego wytwarzania (ang. Computer Integrated Manufacturing) oraz komputerowo zintegrowanego zarządzania (ang. Computer Integrated Management) oraz obu tych obszarów. Architektury i modele referencyjne, to narzędzia ułatwiające zintegrowane spojrzenie na systemy informatyczne przez pryzmat procesów gospodarczych. Pod pojęciem architektur i modeli referencyjnych rozumie się architektury i modele opracowane w oparciu o zebrane doświadczenia gospodarowania przedsiębiorstwami i wdrażania systemów informatycznych, zawierające ogólne rozwiązania, np. dla określonej branży lub dziedziny zastosowań, i stanowiące podstawę opracowywania architektur i modeli dla konkretnych - rzeczywistych sytuacji przedsiębiorstw lub dokonywania oceny konkretnych już wdrożonych architektur i modeli Używane tu słowo referencyjny pochodzi od łacińskiego słowa referre (odnosić się, informować, odwoływać się, rekomendować).
94 Integracja systemów informatycznych Architektura lub model referencyjny Architektura lub model referencyjny powinny być wzorcami powszechnie uznawanymi, które mogą zostać użyte jako rozwiązania wyjściowe przystosowywane do indywidualnych potrzeb. Architektury i modele referencyjne stwarzają podstawy integracji sfery biznesowej i sfery technologii informatycznych. Przykładami znanych architektur referencyjnych są: CIMOSA (Open System Architecture for Computer Integrated Manufacturing); GRAI/GIM (Graphes de Resultats et Actives Interrelies/GRAI Integrated Methodology); PERA (Purdue Enterprise Reference Architecture); GERAM (Generalized Enterprise Reference Architecture and Methodology); SOM (Semantic Object Model Architecture); IFIP (Information System Methodology Organizacji IFIP (International Federation for Information Processing).
95 Integracja systemów informatycznych Model referencyjny Przykłady znanych modeli referencyjnych: modele referencyjne ARIS; model referencyjny SAP R/3; modele Baan.
96 Integracja systemów informatycznych Architektury i modele referencyjne Architektury i modele referencyjne, opracowywane przez producentów oprogramowania, firmy wdrażające systemy informatyczne, ośrodki naukowe, konsorcja, firmy konsultingowe są stale modyfikowane i rozwijane. Powstają także całkiem nowe. Widoczne jest dążenie do ujęcia systemów informatycznych z różnych punktów widzenia, takich jak: dane, funkcje, organizacja, proces gospodarczy i na różnych poziomach opisu, odpowiadających fazom cyklu życia systemu: analiza i definiowanie wymagań użytkownika, projektowanie, wdrażanie, utrzymywanie systemu.
97 Integracja systemów informatycznych Wiedzę przedsiębiorstwa jako czynnik integrujący systemy informatyczne Wiedza jest traktowana jak zasób firmy, którym trzeba zarządzać, tak jak innymi zasobami. Zarządzanie wiedzą obejmuje jej identyfikację, archiwowanie, inwentaryzację, powiększanie (pozyskiwanie), wykorzystywanie. W organizacjach niezbędne jest zapewnienie możliwości współużytkowania wiedzy i swobodnego przepływu informacji (dystrybucja informacji i wiedzy). Wymaga to integracji narzędzi IT, takich jak systemy baz wiedzy, sieci neuronowe, systemy wspomagania decyzji grupowych (pracy grupowej), hurtownie danych, systemy pozyskiwania danych (data mining).
98 Integracja systemów informatycznych Organizacje wirtualne Wirtualne organizacje istnieją dzięki nowej technologii pracy w sieci, umożliwiającej rozproszoną pracę. Wirtualne przedsiębiorstwa działaj ą tak jak inne firmy, lecz nie mają osobowości prawnej. W organizacji wirtualnej procesy gospodarcze przebiegaj ą poprzez wiele zlokalizowanych w różnych miejscach punktów sprzedaży i produkcji, i sięgają do zewnętrznych partnerów przedsiębiorstwa (dostawcy i klienci). Nowa forma przedsiębiorstw skłania do poszukiwania odpowiedzi na pytanie o przydatność dla takich organizacji architektur i modeli, zapewniających integrację systemów informatycznych, utworzonych dla organizacji tradycyjnych i tworzenia odpowiednio dostosowanych.
99 Integracja systemów informatycznych Integracja Sposób rozumienia integracji zmienia się i pozostaje w ścisłej zależności od osiągniętego poziomu rozwoju w zakresie technologii IT i zarządzania. Towarzyszy temu rozwój całościowych koncepcji, takich jak komputerowo zintegrowane wytwarzanie (Computer Integrated Manufacturing), komputerowo zintegrowane zarządzanie (Computer Integrated Management), komputerowo zintegrowane przedsiębiorstwo - biznes (Computer Integrated Business), które przedstawiają wskazówki, co do realizacji integracji w dziedzinie systemów informatycznych. System informatyczny przedsiębiorstwa przestaje być uważany za odrębny element, wymagający samodzielnej integracji, ale coraz częściej jest uważany za immanentny składnik całościowo traktowanego przedsiębiorstwa, co znajduje swój wyraz m.in. w coraz powszechniejszym używaniu terminu zintegrowane przedsiębiorstwo zamiast zintegrowany system informatyczny.
100 Integracja systemów informatycznych Integracja systemów informatycznych Integracją systemów informatycznych nazywamy osadzanie istniejących i nowych systemów informatycznych w istniejącym środowisku informatycznym.
101 Integracja systemów informatycznych Integracja Integracja systemów informatycznych wymaga wiedzy o środowisku systemu informatycznego oraz jego otoczeniu. Integrowany system informatyczny osadzany jest w środowisku biznesowym i dlatego konieczna jest znajomość otaczających go procesów biznesowych. W celu umożliwienia efektywnego współdziałania systemu informatycznego z otoczeniem (tj. innymi systemami informatycznymi) należy skonstruować odpowiednie interfejsy.
102 Integracja systemów informatycznych Interfejs Komunikacja między systemami informatycznymi odbywa się za pośrednictwem interfejsów. W związku z tym interfejs jest podstawowym elementem modelu integracji systemów. Za jego pośrednictwem system informatyczny przesyła informacje do innego systemu informatycznego.
103 Integracja systemów informatycznych Integracja W konsekwencji można stwierdzić, że modelowanie integracji to inaczej modelowanie komunikatów wymienianych (przez interfejsy) między różnymi systemami informatycznymi oraz procesy niezbędne do tej wymiany komunikatów.
104 Integracja systemów informatycznych Poziom analizy Na potrzeby integraci systemów informatycznych musimy zdefiniować, które informacje mają być wymieniane oraz w jaki sposób. Z tego powodu model integracji systemów opisujemy biorąc pod uwagę różne punkty widzenia (perspektywy). Najogólniejszy podział związany z perspektywami wyodrębina, dwie perspektywy, tj. perspektywę procesu obrazującą aktywności podejmowane przez system informatyczny podczas wymiany komunikatów z innymi systemami informatycznymi; perspektywę statyczną opisującą zawartość i strukturę obiektów biznesowych podlegających wymianie (stanowiących komunikat).
105 Integracja systemów informatycznych Elementy perspektywy Aktywności, które muszą zostać wykonane w celu wymiany komunikatów między systemami informatycznymi, można opisać za pomocą diagramów sekwencji i diagramów aktywności: Diagram sekwencji opisuje chronologiczną kolejność wymiany komunikatów między systemami informatycznymi; Diagram aktywności opisuje przepływ działań. Obrazuje on zależności między indywidualnymi akcjami oraz przepływ obiektów biznesowych.
106 Integracja systemów informatycznych Perspektywa procesu Etapy konstrukcji perspektywy procesu: 1. Określenie interfejsów, czyli pomiędzy jakimi systemami informatycznymi odbywa się komunikacja? 2. Identyfikacja zaangażowanych systemów, czyli które systemy informatyczne wymieniają się informacjami? 3. Identyfikacja aktywności i przepływów, czyli co należy wykonać i kto jest za to odpowiedzialny? 4. Zidentyfikowanie komunikatów, czyli jakie komunikaty będą wymieniane? 5. Zdefiniowanie reguł, czyli od czego są uzależnione podejmowane akcje? 6. Weryfikacja perspektywy, czyli czy wszystko wydaje się działać?
107 Integracja systemów informatycznych Elementy perspektywy Do zilustrowania obiektów biznesowych w perspektywie statycznej modelu integracji systemów wykorzystać można diagramy klas.
108 Integracja systemów informatycznych Perspektywa statyczna Etapy konstrukcji perspektywy statycznej: 1. Zgromadzenie informacji niezbędnych dla obiektu biznesowego, czyli co chcemy przesyłać? 2. Skonstruowanie diagramu klas, czyli jaka jest struktura obiektu biznesowego? 3. Adaptacja klas i atrybutów z diagramu klas systemu informatycznego, czyli jakie informacje mają być uwzględnione na diagramie klas? 4. Pozyskanie innych elementów danych, czyli skąd wziąć pozostałe dane? 5. Zdefiniowanie klas i związków obiektu biznesowego, czyli jakie związki klas będą potrzebne? 6. Weryfikacja perspektywy, czyli czy wszystko wydaje się działać?
109 Integracja systemów informatycznych Integrowanie w przedsiebiorstwach Zastosowanie architektury obserwatora procesu pozwala na zintegrowanie rożnych systemów informatycznych w przedsiębiorstwie. Generalnie, idea obserwatora procesu polega na utworzeniu jednolitego, spójnego modelu danych bieżących (utworzenie obrazu bieżącego stanu całej produkcji) i udostępnianie go aplikacjom biznesowym według ich potrzeb poprzez międzynarodowe standardy komunikacji (standard OPC) i wymiany danych.
110 Integracja systemów informatycznych OPC Zastosowanie serwera OPC, w roli obserwatora procesu, do integracji systemów w przedsiębiorstwie pozwala na usystematyzowanie struktury połączeń z warstwą procesową i pozyskiwanie danych w jednorodny, zgodny z międzynarodowymi standardami komunikacyjnymi sposób. Raz pobrane dane, służą wielu różnym systemom informatycznym. To istotnie podnosi efektywność pozyskiwania i transferu danych w przedsiębiorstwie.
111 Integracja systemów informatycznych OPC OPC jest otwartym standardem komunikacyjnym stosowanym w automatyce przemysłowej i informatycznych systemach wyższych warstw, a mianowicie biznesowej i zarządzania, przedsiębiorstw przemysłowych. Interoperacyjność aplikacji jest zapewniona dzięki utworzeniu i utrzymywaniu specyfikacji otwartych standardów. Utrzymaniem i rozwojem standardu zajmuje się OPC Foundation. OPC powstał i został tak zaprojektowany, aby łączyć aplikacje bazujące na systemach operacyjnych ogólnego stosowania (np. Windows) ze sprzętem i oprogramowaniem aplikacyjnym automatyki przemysłowej (urządzenia procesowe), nadzorującym i sterującym procesem technologicznym. Jest to otwarty standard komunikacji, który pozwala używać jednolitych metod dostępu i opisu danych (interfejsu) dla procesu technologicznego. Metody te są niezależne od typu oraz źródła danych.
112 Integracja systemów informatycznych OPC Dla wielu pakietów oprogramowania serwer OPC dostarcza w jednolity sposób danych z urządzeń sterujących i nadzorujących proces technologiczny (dane procesowe) takich, jak sterowniki PLC, czy systemy DCS. Tradycyjnie, jeżeli jakieś oprogramowanie ma mieć dostęp do danych procesowych, musi zostać zaimplementowany specjalny sterownik. Zadaniem OPC jest zdefiniowanie wspólnego interfejsu, który utworzony raz - może być wykorzystywany przez dowolnego klienta biznesowego, oprogramowanie SCADA, HMI lub dowolny pakiet oprogramowania.
113 Integracja systemów informatycznych OPC Bazując na standardach Microsoft OLE (ang. Object Linking and Embedding), COM(ang. Component Object Model) i DCOM (ang. Distributed Component Object Model), technologia OPC definiuje interfejsy przeznaczone do komunikacji z urządzeniami przemysłowymi, przez co pozwala uniezależnić oprogramowanie monitorujące od różnorodnych rozwiązań stosowanych przez producentów sprzętu procesowego. Technologie COM/DCOM dostarczają infrastrukturę i środowisko programistyczne dla tworzenia i rozwoju oprogramowania. Obecnie są dostępne setki serwerów i klientów OPC.
114 OPC W ramach projektu zajmującego się standaryzacją OPC powstały różne specyfikacje, z których każda definiuje odrębną funkcjonalność. Wśród istniejących specyfikacji możemy wyróżnić: OPC Data Access (OPC DA) - umożliwia dostęp do aktualnych danych generowanych w czasie rzeczywistym. Przy pomocy OPC DA do serwera OPC kierowane są zapytania o aktualne wartości zmiennych procesowych - np. temperatur, ciśnień itp. Komunikacja z każdym serwerem odbywa się w taki sam sposób, z wykorzystaniem tego samego formatu. Klient nie musi wiedzieć w jaki sposób serwer komunikuje się z urządzeniem. Wielu klientów może korzystać jednocześnie z tych samych danych udostępnianych przez serwer. OPC Historical Data Access (OPC HDA) - umożliwia przeglądanie i analizę zgromadzonych danych historycznych, np w celu oceny wydajności systemu czy przewidywania błędów. Klient uzyskuje dostęp do zarchiwizowanych danych (odczytów jakiegoś urządzenia itp.) poprzez zgłaszanie zapytań do serwera OPC HDA. Modelowanie i analiza systemów informatycznych. Integracja systemów informatycznych
115 Integracja systemów informatycznych OPC OPC Alarms and Events (OPC AE) - służy do informowania o występujących w systemie zdarzeniach i zgłaszanych alarmach. Przez alarm rozumiany jest nienormalny stan jakiegoś obiektu, wymagający szczególnej uwagi. Zdarzenie może być związane ze stanem, jak np. zdarzenie przejścia danej wartości do poziomu alarmowego lub niezwiązane ze stanem, jak zmiany konfiguracji, czy błędy systemowe. Serwery OPC AE mogą pobierać dane bezpośrednio z urządzenia lub z serwera OPC DA. Serwer OPC AE może być samodzielnym modułem lub też wchodzić w skład serwera OPC DA. OPC Security - służy zapewnieniu bezpieczeństwa dostępu do danych oferowanych przez serwery OPC. Umożliwia poprawną weryfikację klienta, który chce uzyskać dostęp i poprawności transmisji (czy dane nie zostały zmienione).
116 Integracja systemów informatycznych Koniec wykładu 12.
117 Metodologia zwinna Wykład 13
118 Metodologia zwinna Metodologia zwinna Obecnie najczęściej wykorzystywane systemy informacyjne w dziedzinie ekonomii i zarządzania ukierunkowane są głównie na usprawnianie zarządzania w celu lepszego zaspokajania potrzeb wszystkich uczestników procesów gospodarczych.
119 Metodologia zwinna
120 Metodologia zwinna Innowacje w systemach informatycznych Najważniejsze kierunki innowacji wprowadzanych w systemach informacyjnych oparte są o wymagania: integracji systemów, danych i procesów; unifikacji funkcji cząstkowych systemów; zwiększania dostępności do bazy danych dla wszystkich komórek organizacyjnych; upowszechniania nowoczesnych sposobów prezentacji danych (wizualizacji) dla celów wspomagania ich analizy; doskonalenia procesów podejmowania decyzji i ich przekazywania; zmierzania do budowy modułowej i otwartości całego systemu.
121 Metodologia zwinna Wymagania projektowanego systemu Dalsze wymagania dotyczące projektowanego systemu są następujące: zapewnienia kompleksowego charakteru funkcjonalnego całego systemu; stałego podnoszenia zaawansowania merytorycznego i technologicznego; zmierzania do elastyczności funkcjonalnej i strukturalnej; zapewnienia stałej zgodności ze zmieniającymi się elementami otoczenia systemowego, azwłaszcza z aktualnym stanem prawnym, ewoluującym zgodnie z przyjętymi procedurami legislacyjnymi.
122 Metodologia zwinna Ekonomiczne systemy informacyjne są projektowane i realizowane w taki sposób, aby dane przetwarzane przez ów system były bezpieczne i na każdym jego etapie chronione. Dlatego też w jak największym stopniu musi być zapewniona poufność i integralność wszelkich danych posiadanych przez system, a dostępność do danych zawartych w systemie powinna być zgodna z przyjętą hierarchią haseł i przywilejów dostępu.
123 Metodologia zwinna Mimo wielu lat rozwoju ryzyko prowadzenia projektów informatycznych nadal jest duże. W USA rozwój oprogramowania pochłania rocznie 250 mld dolarów rocznie, w postaci około 175 tys. projektów informatycznych. Badania Standish Group dla rynku Amerykańskiego dowodzą, że 31% z tych projektów jest przerywanych na jednym z etapów pośrednich, zaś 52% projektów przekracza planowany budżet. Typowy system informatyczny jest droższy niż planowano o średnio 89%.
124 Metodologia zwinna Metodologia Dlatego niezbędna jest właściwa metodologia projektowania i wdrażania systemów informatycznych. Stosowną metodologię dostarcza głównie inżynieria oprogramowania. Inżynieria oprogramowania jest praktycznym zastosowaniem wiedzy naukowej do projektowania i tworzenia systemów informacyjnych i informatycznych oraz dokumentacji wymaganej do ich opracowania, uruchomienia oraz pielęgnacji. Najnowsze prace odwołujące się do inżynierii oprogramowania przewidują występowanie aż 12 faz procesu projektowego.
125 Metodologia zwinna
126 Metodologia zwinna 1. Inicjalizacja systemu i wstępne planowanie: Znalezienie potencjalnego obszaru zastosowania systemu informatycznego, który wspomoże lub zastąpi dotychczasowe metody przetwarzania informacji. 2. Analiza wymagań i specyfikacja wymagań: Identyfikacja problemów, które nowy system informacyjny ma rozwiązać. Zarysowanie właściwości operacyjnych systemu, wydajności i zasobów sprzętowych niezbędnych do użytkowania i konserwowania systemu. 3. Specyfikacja funkcjonalna i prototypowanie: Identyfikacja i formalizacja obiektów obliczeń, ich atrybutów i zależności. Specyfikacja transformacji, którym obiekty będą podlegać.
127 Metodologia zwinna 4. Dekompozycja problemu: Podział systemu na logiczne podsystemy na podstawie wymagań i specyfikacji. Analiza logicznych podsystemów pod kątem użycia już istniejących komponentów informatycznych. Selekcja rozwiązań: wykonać samodzielnie, kupić, wykorzystać już istniejące. 5. Projekt architekturalny i specyfikacja konfiguracji: Określenie zależności pomiędzy podsystemami, komponentami i modułami w sposób uwzględniający szczegóły ich budowy i wymagania wobec nich. 6. Szczegółowe projektowanie i specyfikacja komponentów: Opracowanie i kodyfikowanie metod przetwarzania informacji w komponentach. 7. Implementacja komponentów i usuwanie błędów: Wytwarzanie kodu źródłowego komponentów na podstawie uprzednich specyfikacji. Testowanie podstawowych funkcji komponentów.
128 Metodologia zwinna 8. Asemblacja systemu i testowanie: Weryfikacja komponentów pod kątem kompletności i zgodności ze specyfikacją. Asemblacja produktu z komponentów, weryfikacja wydajności podsystemów systemu jako całości. 9. Przegląd dokumentacji i dostarczenie systemu: Opracowywanie i systematyzowanie dokumentacji powstałej w trakcie prowadzenia projektu pod kątem raportów dla odbiorcy. 10. Opracowanie procedur instalacyjnych i instalacja: Opracowanie dokumentacji instalacyjnej opisującej sposób instalacji systemu. 11. Szkolenie dla użytkowników: Zapoznanie użytkowników z systemem. Zapoznanie ich z możliwościami i ograniczeniami systemu. 12. Użytkowanie i konserwacja oprogramowania: Użytkowanie, usuwanie błędów dostrzeżonych w trakcie użytkowania, rozbudowywanie systemu o nowe właściwości, poprawa wydajności systemu.
129 Metodologia zwinna Luka poznawcza Jednak nawet najlepsza metodologia nie zabezpiecza przed błędami, bo istnieje luka poznawcza w projektach informatycznych.
130 Metodologia zwinna Luka poznawcza Zagadnienia zaliczające się do luki poznawczej, nie są w trakcie analizy dostrzegane i nie zostaną wyczerpująco opracowane, można więc określać je mianem ryzykownych punktów projektu. Wokół tych zagadnień Boehm zbudował spiralny model tworzenia oprogramowania
131 Metodologia zwinna
132 Metodologia zwinna
133 Metodologia zwinna Teoria Win-Win Rozważa się także rozwinięcie modelu spiralnego w oparciu o tzw. teorię Win-Win. Teoria W-W podpowiada, że należy zidentyfikować wszystkich tych, którzy mają wpływ na przebieg i wynik projektu. Mogą to być użytkownicy, inwestorzy, agendy rządowe i ich regulacje prawne, firmy programistyczne itp. Należy określić warunki sukcesu każdego uczestnika procesu (win condition). Należy doprowadzić do negocjacji pomiędzy uczestnikami podczas oceny prototypów, jeśli ich warunki sukcesu wykluczają się.
134 Metodologia zwinna
135 Metodologia zwinna Metodologie zwinnearchitektury i modele referencyjne Metody kaskadowe i spiralne bywają czasem nadmiernie sformalizowane, dlatego w ostatnich latach zaczęto lansować bardziej swobodną metodykę projektowania systemów informatycznych, nazywaną agile software development methods. W polskiej literaturze odpowiednie metody zwykło się określać jako zwinne.
136 Metodologia zwinna Manifest Podstawowe składniki manifestu zwolenników zwinnych metod projektowania są dosyć oczywiste i łatwe do zaakceptowania: ludzie, ich kontakty, zdolność do rozwiązywania problemów są ważniejsze niż sztywne procedury i narzędzia zarządzania, wynikiem projektu jest pracujące oprogramowanie a nie dokumentacja, z użytkownikiem się współpracuje a nie negocjuje kontrakt, ważniejsza jest umiejętność reagowania na zmieniające się warunki otoczenia niż podążanie za opracowanym na wstępie planem.
137 Metodologia zwinna Rozwój metodyki projektowania systemów informatycznych w kierunku metod zwinnych
138 Metodologia zwinna Skala dojrzałości modeli tworzenia systemów informatycznych pokazuje, że metody zwinne można stosować głównie dla niezbyt dużych systemów.
139 Metodologia zwinna Metodyki zwinne Wśród metod zwinnych obecnie można wymienić: Metodyka Crystal (Crystal family), Projektowanie zorientowane na właściwości (Feature Driven Development), Modelowanie zwinne (Agile Modeling), Programowanie ekstremalne (Extreme Programming), Adaptacyjny rozwój oprogramowania (Adaptive Software Development), Metodyka scrum (Scrum development), Prototypowanie (Prototyping methodology), Szybkie programowanie internetowe (Internet Speed Development), Pragmatyczne programowanie (Pragmatic Programming).
140 Metodologia zwinna Jedna ze zwinnych metodologii, nazywana Crystal
141 Metodologia zwinna Metodyka Cristal Metodyka Cristal ma odmiany w zależności od stopnia krytyczności projektu (kategoryzowanego poprzez litery C, D, E, L) i w zależności od jego rozmiaru, mierzonego liczbą projektantów zaangażowanych w tworzenie projektu. Kategorie krytyczności projektowanego systemu: C Komfortowe (Comfort), D Zarządzające Finansami (Discretionary Money), E Finansowo istotne (Essential Money), L Krytyczne dla Życia (Life Critical).
142 Metodologia zwinna Cristal Na tej podstawie proponowana jest cała rodzina metod typu Cristal. Ich mapa podana jest niżej.
143 Metodologia zwinna Projektowanie zorientowane na właściwości (FDD-Feature Driven Development) Projekt w myśl FDD składa się z pięciu sekwencyjnie następujących etapów.
144 Metodologia zwinna Projektowanie zorientowane na właściwości (FDD-Feature Driven Development) Projekt w myśl FDD składa się z pięciu sekwencyjnie następujących etapów.
145 Metodologia zwinna Założeniem leżącym u podstaw FDD jest inkrementacyjne opracowywanie poszczególnych funkcjonalności systemu (features). Prace rozpoczynają się od określenia ogólnego modelu systemu. Zespół projektantów korzysta z opracowanych wcześniej wymagań systemowych i przypadków użycia. Określana jest domena projektu i iteracyjnie dzielona na coraz to mniejsze znaczeniowo obszary. Każdy niepodzielny obszar znaczeniowy jest opracowywany przez przypisaną do niego grupę projektantów, w wyniku czego powstaje model szczegółowy, będący składnikiem całościowego modelu systemu.
146 Metodologia zwinna Projektowanie zorientowane na właściwości (FDD-Feature Driven Development) Projekt w myśl FDD składa się z pięciu sekwencyjnie następujących etapów.
147 Metodologia zwinna W następnym etapie na podstawie specyfikacji wymagań systemowych oraz opracowanego modelu/modeli opracowywane są listy funkcjonalności. Listy te mają charakter hierarchiczny i zawierają funkcjonalności główne, które rozpadają się na zestawy funkcjonalności w kolejnych hierarchiach. Listy te są przeglądane przez użytkowników i inwestorów w celu kontroli poprawności i kompletności.
148 Metodologia zwinna Projektowanie zorientowane na właściwości (FDD-Feature Driven Development) Projekt w myśl FDD składa się z pięciu sekwencyjnie następujących etapów.
149 Metodologia zwinna Planowanie nakłada na kierownictwo projektu obowiązek opracowania długookresowego planu prac powiązanego z funkcjonalnościami, ich zależnościami i priorytetami. Poszczególne elementy listy funkcjonalności przydzielane są zespołom a w ich ramach konkretnym programistom opiekunom klas. Klasa jest tu rozpatrywana w rozumieniu programowania obiektowego.
150 Metodologia zwinna Projektowanie zorientowane na właściwości (FDD-Feature Driven Development) Projekt w myśl FDD składa się z pięciu sekwencyjnie następujących etapów.
Projektowanie 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ółowoModelowanie i analiza systemów informatycznych.
Modelowanie i analiza systemów informatycznych. dr Robert Plebaniak 2 grudnia 2013 roku Metodyka RUP Wykład 10 Metodyka RUP Metodyka RUP Metodyka RUP Znaczenie iteracyjno-przyrostowego procesu projektowania
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ół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ół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ół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ółowoLekkie metodyki. tworzenia oprogramowania
Lekkie metodyki tworzenia oprogramowania Programowanie zwinne ( Agile software development) grupa metodyk wytwarzania oprogramowania opartego o programowanie iteracyjne (model przyrostowy). Wymagania oraz
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ół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ół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ółowoZakres wykładu. Podstawy InŜynierii Oprogramowania
Zakres wykładu Pojęcia podstawowe InŜynierii Oprogramowania Proces wytwarzania oprogramowania Artefakty procesu wytwarzania i ich modele Jakość oprogramowania Literatura: [1] Sacha K., InŜynieria oprogramowania,
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ół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ół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ół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ółowoProgramowanie zespołowe
Programowanie zespołowe Laboratorium 4 - modele tworzenia oprogramowania, manifest Agile i wstęp do Scruma mgr inż. Krzysztof Szwarc krzysztof@szwarc.net.pl Sosnowiec, 14 marca 2017 1 / 21 mgr inż. Krzysztof
Bardziej szczegółowoSiR_13 Systemy SCADA: sterowanie nadrzędne; wizualizacja procesów. MES - Manufacturing Execution System System Realizacji Produkcji
System informatyczny na produkcji: Umożliwi stopniowe, ale jednocześnie ekonomiczne i bezpieczne wdrażanie i rozwój aplikacji przemysłowych w miarę zmiany potrzeb firmy. Może adoptować się do istniejącej
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ółowoREQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN
REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN Podziękowania REQB Poziom Podstawowy Przykładowy Egzamin Dokument ten został stworzony przez główny zespół Grupy Roboczej REQB dla Poziomu Podstawowego. Tłumaczenie
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ółowoZarządzanie projektami. Wykład 2 Zarządzanie projektem
Zarządzanie projektami Wykład 2 Zarządzanie projektem Plan wykładu Definicja zarzadzania projektami Typy podejść do zarządzania projektami Cykl życia projektu/cykl zarządzania projektem Grupy procesów
Bardziej szczegółowoWytwarzanie oprogramowania
AiPA 6 Wytwarzanie oprogramowania Proces tworzenia oprogramowania jest procesem przekształcenia wymagań w oprogramowanie zgodnie z metodyką, która określa KTO CO robi JAK i KIEDY. - Wymagania Proces tworzenia
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ółowoIteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1
Iteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1 Zofia Kruczkiewicz 1 Zunifikowany iteracyjno- przyrostowy proces tworzenia oprogramowania kiedy? Przepływ działań Modelowanie przedsiębiorstwa
Bardziej szczegółowoCel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2
Wyższa Szkoła Menedżerska w Legnicy Systemy informatyczne w przedsiębiorstwach Zarządzanie, ZIP, sem. 6 (JG) Modelowanie wymagań Wykład 2 Grzegorz Bazydło Cel wykładu Celem wykładu jest przekazanie wiedzy
Bardziej szczegółowoMichał Adamczyk. Język UML
Michał Adamczyk Język UML UML I. Czym jest UML Po co UML II.Narzędzia obsługujące UML, edytory UML III.Rodzaje diagramów UML wraz z przykładami Zastosowanie diagramu Podstawowe elementy diagramu Przykładowy
Bardziej szczegółowoSpis treści. Dzień 1. I Wprowadzenie (wersja 0906) II Dostęp do danych bieżących specyfikacja OPC Data Access (wersja 0906) Kurs OPC S7
I Wprowadzenie (wersja 0906) Kurs OPC S7 Spis treści Dzień 1 I-3 O czym będziemy mówić? I-4 Typowe sytuacje I-5 Klasyczne podejście do komunikacji z urządzeniami automatyki I-6 Cechy podejścia dedykowanego
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ół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ółowoOrganizacja procesu projektowania, rozwoju i serwisowania systemu wspomagającego zarzadzanie uczelnią
Organizacja procesu projektowania, rozwoju i serwisowania systemu wspomagającego zarzadzanie uczelnią Marek Bieniasz Sławomir Umpirowicz Piotr Miszewski Kraków, 10 13 września 2012 Plan prezentacji Informacje
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ółowoKurs OPC S7. Spis treści. Dzień 1. I OPC motywacja, zakres zastosowań, podstawowe pojęcia dostępne specyfikacje (wersja 1501)
Spis treści Dzień 1 I OPC motywacja, zakres zastosowań, podstawowe pojęcia dostępne specyfikacje (wersja 1501) I-3 O czym będziemy mówić? I-4 Typowe sytuacje I-5 Klasyczne podejście do komunikacji z urządzeniami
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ółowoWprowadzenie do systemów informacyjnych
Wprowadzenie do systemów informacyjnych Kryteria oceny systemu Podstawowe metody projektowania UEK w Krakowie Ryszard Tadeusiewicz 1 UEK w Krakowie Ryszard Tadeusiewicz 2 Technologia informatyczna dzisiaj
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ółowoWykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych
Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych dr inż. Adam Iwaniak Infrastruktura Danych Przestrzennych w Polsce i Europie Seminarium, AR Wrocław
Bardziej szczegółowoIn ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania
In ż ynieria oprogramowania wykład II Modele i fazy cyklu życia oprogramowania prowadzący: dr inż. Krzysztof Bartecki www.k.bartecki.po.opole.pl Proces tworzenia oprogramowania jest zbiorem czynności i
Bardziej szczegółowoRUP. Rational Unified Process
RUP Rational Unified Process Agenda RUP wprowadzenie Struktura RUP Przepływy prac w RUP Fazy RUP RUP wprowadzenie RUP (Rational Unified Process) jest : Iteracyjną i przyrostową metodyka W pełni konfigurowalną
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ółowoInżynieria oprogramowania. Jan Magott
Inżynieria oprogramowania Jan Magott Literatura do języka UML G. Booch, J. Rumbaugh, I. Jacobson, UML przewodnik użytkownika, Seria Inżynieria oprogramowania, WNT, 2001, 2002. M. Fowler, UML w kropelce,
Bardziej szczegółowoANALIZA EKONOMICZNO-FINANSOWA
PROGRAM STUDIÓW FINANSE, RACHUNKOWOŚĆ ZARZĄDCZA I CONTROLLING PRZEDMIOT ZAGADNIENIA GODZ. ZAAWANSOWANE NARZĘDZIA RACHUNKOWOŚCI Rachunkowość zarządcza Prognozowanie sprzedaży i kosztów, rachunki optymalizacyjne
Bardziej szczegółowoAnaliza biznesowa a metody agile owe
Analiza biznesowa a metody agile owe P6S_WG01 ma wiedzę w zakresie metodyk zwinnych P6S_WG02 ma wiedzę w zakresie zwinnego gromadzenia i zarządzania wymaganiami P6S_WG03 zna i rozumie proces wytwarzania
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ółowoKurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017
Wykład 12 7 czerwca 2017 Czym jest UML? UML składa się z dwóch podstawowych elementów: notacja: elementy graficzne, składnia języka modelowania, metamodel: definicje pojęć języka i powiazania pomiędzy
Bardziej szczegółowoProjektowanie Modeli Usług dla rozwiązań typu SOA
Projektowanie Modeli Usług dla rozwiązań typu SOA Service Oriented Modeling and Architecture (SOMA ) IBM Global Business Services, zdefiniował zestaw usług konsultingowych oraz narzędzi pomagających organizacjom
Bardziej szczegółowoAnaliza i projekt systemu pracy grupowej z zastosowaniem metodyki SCRUM w technologii SharePoint Karolina Konstantynowicz
Analiza i projekt systemu pracy grupowej z zastosowaniem metodyki SCRUM w technologii SharePoint Karolina Konstantynowicz Promotor dr inż. Szymon Supernak Warszawa, 22.05.2014 Plan prezentacji 1. Cel i
Bardziej szczegółowoCo to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką?
ROZDZIAŁ1 Podstawy inżynierii oprogramowania: - Cele 2 - Zawartość 3 - Inżynieria oprogramowania 4 - Koszty oprogramowania 5 - FAQ o inżynierii oprogramowania: Co to jest jest oprogramowanie? 8 Co to jest
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ółowoEgzamin / zaliczenie na ocenę*
WYDZIAŁ PODSTAWOWYCH PROBLEMÓW TECHNIKI Zał. nr 4 do ZW33/01 KARTA PRZEDMIOTU Nazwa w języku polskim : INŻYNIERIA OPROGRAMOWANIA Nazwa w języku angielskim: SOFTWARE ENGINEERING Kierunek studiów (jeśli
Bardziej szczegółowoAnaliza i projektowanie obiektowe 2016/2017. Wykład 10: Tworzenie projektowego diagramu klas
Analiza i projektowanie obiektowe 2016/2017 Wykład 10: Tworzenie projektowego diagramu klas Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Projektowy
Bardziej szczegółowoCykle życia systemu informatycznego
Cykle życia systemu informatycznego Cykl życia systemu informatycznego - obejmuję on okres od zgłoszenia przez użytkownika potrzeby istnienia systemu aż do wycofania go z eksploatacji. Składa się z etapów
Bardziej szczegółowoDr Katarzyna Grzesiak-Koped
Dr Katarzyna Grzesiak-Koped 2 Tworzenie oprogramowania Najlepsze praktyki IO Inżynieria wymagao Technologia obiektowa i język UML Techniki IO Metodyki zwinne Refaktoryzacja Mierzenie oprogramowania Jakośd
Bardziej szczegółowoINŻYNIERIA OPROGRAMOWANIA
INSTYTUT INFORMATYKI STOSOWANEJ 2013 INŻYNIERIA OPROGRAMOWANIA Inżynieria Oprogramowania Proces ukierunkowany na wytworzenie oprogramowania Jak? Kto? Kiedy? Co? W jaki sposób? Metodyka Zespół Narzędzia
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ół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ół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ółowoZARZĄDZANIE WYMAGANIAMI ARCHITEKTONICZNYMI
ZARZĄDZANIE WYMAGANIAMI ARCHITEKTONICZNYMI XVIII Forum Teleinformatyki mgr inż. Michał BIJATA, doktorant, Wydział Cybernetyki WAT Michal.Bijata@WAT.edu.pl, Michal@Bijata.com 28 września 2012 AGENDA Architektura
Bardziej szczegółowoKARTA PRZEDMIOTU. 1) Nazwa przedmiotu: INŻYNIERIA SYSTEMÓW I ANALIZA SYSTEMOWA. 2) Kod przedmiotu: ROZ-L3-20
Z1-PU7 WYDANIE N2 Strona: 1 z 5 (pieczęć wydziału) KARTA PRZEDMIOTU 1) Nazwa przedmiotu: INŻYNIERIA SYSTEMÓW I ANALIZA SYSTEMOWA 3) Karta przedmiotu ważna od roku akademickiego: 2014/2015 2) Kod przedmiotu:
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ół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ółowoSTUDIA NIESTACJONARNE I STOPNIA Przedmioty kierunkowe
STUDIA NIESTACJONARNE I STOPNIA Przedmioty kierunkowe Technologie informacyjne prof. dr hab. Zdzisław Szyjewski 1. Rola i zadania systemu operacyjnego 2. Zarządzanie pamięcią komputera 3. Zarządzanie danymi
Bardziej szczegółowoInżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu
Inżynieria wymagań Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia Część 5 Definicja systemu Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements Management with Use
Bardziej szczegółowoSYSTEMY INFORMATYCZNE ćwiczenia praktyczne
SYSTEMY INFORMATYCZNE ćwiczenia praktyczne 12.03.2019 Piotr Łukasik p. 373 email: plukasik@agh.edu.pl / lukasik.pio@gmail.com www.lukasikpiotr.com Zakres tematyczny implementacji projektu informatycznego
Bardziej szczegółowoKIERUNKOWE EFEKTY KSZTAŁCENIA KIERUNEK STUDIÓW INFORMATYCZNE TECHNIKI ZARZĄDZANIA
KIERUNKOWE EFEKTY KSZTAŁCENIA KIERUNEK STUDIÓW INFORMATYCZNE TECHNIKI ZARZĄDZANIA Nazwa kierunku studiów: Informatyczne Techniki Zarządzania Ścieżka kształcenia: IT Project Manager, Administrator Bezpieczeństwa
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ół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ółowoModelowanie i analiza systemów informatycznych
Modelowanie i analiza systemów informatycznych MBSE/SysML Wykład 11 SYSMOD Wykorzystane materiały Budapest University of Technology and Economics, Department of Measurement and InformaJon Systems: The
Bardziej szczegółowoInformacja o firmie i oferowanych rozwiązaniach
Informacja o firmie i oferowanych rozwiązaniach Kim jesteśmy INTEGRIS Systemy IT Sp. z o.o jest jednym z najdłużej działających na polskim rynku autoryzowanych Partnerów Microsoft w zakresie rozwiązań
Bardziej szczegółowoREFERAT PRACY DYPLOMOWEJ
REFERAT PRACY DYPLOMOWEJ Temat pracy: Projekt i implementacja środowiska do automatyzacji przeprowadzania testów aplikacji internetowych w oparciu o metodykę Behavior Driven Development. Autor: Stepowany
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ółowoJAK OPTYMALNIE DOBRAĆ ODPOWIEDNIE TECHNOLOGIE INFORMATYCZNE?
K O N F E R E N C J A I N F O S H A R E 2 0 0 7 G d a ń s k 25-26.04.2007 JAK OPTYMALNIE DOBRAĆ ODPOWIEDNIE TECHNOLOGIE INFORMATYCZNE? Zespół Zarządzania Technologiami Informatycznymi Prezentacja dr inż.
Bardziej szczegółowoProcesowa specyfikacja systemów IT
Procesowa specyfikacja systemów IT BOC Group BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management Office
Bardziej szczegółowoRozpoczęcie, inicjacja (ang. inception
Wydział Informatyki PB Analogia do budowanego domu Inżynieria oprogramowania II Wykład 2: Proces tworzenia oprogramowania (na podstawie Unified Process) Marek Krętowski pokój 206 e-mail: mkret@ii.pb.bialystok.pl
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 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ółowoCzęść 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ółowoSzczególne problemy projektowania aplikacji internetowych. Jarosław Kuchta Projektowanie Aplikacji Internetowych
Szczególne problemy projektowania aplikacji Jarosław Kuchta Miejsce projektowania w cyklu wytwarzania aplikacji SWS Analiza systemowa Analiza statyczna Analiza funkcjonalna Analiza dynamiczna Analiza behawioralna
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ółowoAnaliza i programowanie obiektowe 2016/2017. Wykład 6: Projektowanie obiektowe: diagramy interakcji
Analiza i programowanie obiektowe 2016/2017 Wykład 6: Projektowanie obiektowe: diagramy interakcji Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Przejście
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ół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ółowoKonfiguracja modelowania w procesie wytwarzania oprogramowania
Konfiguracja modelowania w procesie wytwarzania oprogramowania Anna Bobkowska Materiały pomocnicze do wykładu z Modelowania i Analizy Systemów na Wydziale ETI PG. Ich lektura nie zastępuje obecności na
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ółowoGłówne składowe przedsiębiorstwa: procesy,technologia, ludzie, organizacja.
Projektowanie systemów informacyjnych - wprowadzenie Trzy przyczyny konieczności używania systemów informatycznych przy korzystaniu z danych, informacji i wiedzy: 1.gwałtowne powiększenie się zasobów informacyjnych,
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ółowoWybór ZSI. Zakup standardowego systemu. System pisany na zamówienie
Wybór ZSI Zakup standardowego systemu System pisany na zamówienie Zalety: Standardowy ZSI wbudowane najlepsze praktyki biznesowe możliwość testowania przed zakupem mniej kosztowny utrzymywany przez asystę
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ółowoUML cz. III. UML cz. III 1/36
UML cz. III UML cz. III 1/36 UML cz. III 2/36 Diagram współpracy Diagramy współpracy: prezentują obiekty współdziałające ze sobą opisują rolę obiektów w scenariuszu mogą prezentować wzorce projektowe UML
Bardziej szczegółowoJakość w procesie wytwarzania oprogramowania
Jarosław Kuchta Jakość Oprogramowania http://www.eti.pg.gda.pl/katedry/kask/pracownicy/jaroslaw.kuchta/jakosc/ J.Kuchta@eti.pg.gda.pl Względny koszt wprowadzania zmian w zależności od fazy realizacji projektu
Bardziej szczegółowoProjekty BPM z perspektywy analityka biznesowego. Wrocław, 20 stycznia 2011
Projekty BPM z perspektywy analityka biznesowego Wrocław, 20 stycznia 2011 Agenda Definicja pojęć: Analiza biznesowa oraz analityk biznesowy Co kryje się za hasłem BPM? Organizacja zarządzana procesowo
Bardziej szczegółowoDLA SEKTORA INFORMATYCZNEGO W POLSCE
DLA SEKTORA INFORMATYCZNEGO W POLSCE SRK IT obejmuje kompetencje najważniejsze i specyficzne dla samego IT są: programowanie i zarządzanie systemami informatycznymi. Z rozwiązań IT korzysta się w każdej
Bardziej szczegółowoMODELE CYKLU ŻYCIA OPROGRAMOWANIA (1) Model kaskadowy (często stosowany w praktyce do projektów o niewielkiej złożonoś
OPROGRAMOWANIA (1) Model kaskadowy (często stosowany w praktyce do projektów o niewielkiej złożonoś (często stosowany w praktyce do projektów o niewielkiej złożoności) wymagania specyfikowanie kodowanie
Bardziej szczegółowoWykaz 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ółowoInżynieria oprogramowania (Software Engineering)
Inżynieria oprogramowania (Software Engineering) Wykład 2 Proces produkcji oprogramowania Proces produkcji oprogramowania (Software Process) Podstawowe założenia: Dobre procesy prowadzą do dobrego oprogramowania
Bardziej szczegółowoZarządzanie i realizacja projektów systemu Microsoft SharePoint 2010
Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010 Geoff Evelyn Przekład: Natalia Chounlamany APN Promise Warszawa 2011 Spis treści Podziękowania......................................................
Bardziej szczegółowoWykład 3 Wymagania. MIS n Inżynieria oprogramowania Październik Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie
Wykład 3 MIS-1-505-n Inżynieria Październik 2014 Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie 3.1 Agenda 1 2 3 4 5 3.2 Czynności w czasie produkcji. Inżynieria stara się zidentyfikować
Bardziej szczegółowoLeszek Dziubiński Damian Joniec Elżbieta Gęborek. Computer Plus Kraków S.A.
Leszek Dziubiński Damian Joniec Elżbieta Gęborek Computer Plus Kraków S.A. Wykorzystanie Microsoft Project Server w procesie zarządzania projektami Kompetencje partnerskie Gold: Portals and Collaboration
Bardziej szczegółowoWarsztaty FRAME. Sygnatura warsztatu: W1 (W3) Czas trwania: 3 dni
Sygnatura warsztatu: W1 (W3) Czas trwania: 3 dni Warsztaty FRAME I. Cel Zapoznanie uczestników z możliwościami wykorzystania Europejskiej Ramowej Architektury ITS FRAME (zwanej dalej FRAME ) oraz jej narzędzi
Bardziej szczegółowoUsprawnienie 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ół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ółowo