Modelowanie i analiza systemów informatycznych. dr Robert Plebaniak 12 stycznia 2014 roku
Metodyka RUP Wykład 10
Metodyka RUP Metodyka RUP
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.
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.
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.
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.
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.
Metodyka RUP Rozwój metodyki RUP
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.
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).
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ą.
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.
Metodyka RUP Struktura RUP
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.
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.
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.
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.
Metodyka RUP Układ i zależności pomiędzy wymienionymi dyscyplinami
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.
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.
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.
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).
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.
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.
Modelowanie biznesowe Modelowanie biznesowe
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.
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).
Modelowanie biznesowe Modelowanie biznesowe w procesie tworzenia systemu
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.
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.
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.
Modelowanie biznesowe Podstawowe kategorie modelowania diagramów biznesowych
Modelowanie biznesowe Podstawowe kategorie modelowania diagramów biznesowych
Modelowanie biznesowe Podstawowe kategorie modelowania diagramów biznesowych
Modelowanie biznesowe Biznesowy kontekst systemu księgarni
Modelowanie biznesowe Biznesowy diagram przypadków użycia systemu księgarni
Modelowanie biznesowe Mapa procesów biznesowych funkcjonowania księgarni
Modelowanie biznesowe Czynność przypadku Dokonaj zakupu
Modelowanie biznesowe Biznesowy diagram sekwencji
Modelowanie biznesowe Biznesowy diagram klas
Modelowanie biznesowe Biznesowy diagram klas z pracownikami biznesowymi
Modelowanie biznesowe Jednostki organizacyjne księgarni
Modelowanie biznesowe Zależność pomiędzy działami a pracownikami
Modelowanie biznesowe Koniec wykładu 10.
Modelowanie analityczne Wykład 11
Modelowanie analityczne Modelowanie analityczne
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.
Modelowanie analityczne Diagram modelowania analitycznego w procesie tworzenia systemu
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.
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).
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.
Modelowanie analityczne Notacja oraz charakterystyka klas analitycznych
Modelowanie analityczne Notacja oraz charakterystyka klas analitycznych
Modelowanie analityczne Notacja oraz charakterystyka klas analitycznych
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.
Modelowanie analityczne Diagram analityczny
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.
Modelowanie analityczne Zasady obowiązujące w diagramach modelowania analitycznego
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.
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.
Modelowanie analityczne Konwersja kategorii biznesowych na kategorie klas analitycznych
Modelowanie analityczne Konwersja kategorii biznesowych na kategorie klas analitycznych
Modelowanie analityczne Model analityczny
Komputerowe wspomaganie modelowania systemu Komputerowe wspomaganie modelowania systemu
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.
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.
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.
Komputerowe wspomaganie modelowania systemu Wybrane narzędzia CASE dla UML i RUP
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;
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.
Komputerowe wspomaganie modelowania systemu Zakres wspomagania diagramów UML
Komputerowe wspomaganie modelowania systemu Zakres wspomagania diagramów UML
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.
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.
Komputerowe wspomaganie modelowania systemu Zestawienie możliwości generowania kodu oferowanych przez wyselekcjonowane narzędzia CASE
Komputerowe wspomaganie modelowania systemu Zestawienie możliwości generowania kodu oferowanych przez wyselekcjonowane narzędzia CASE
Komputerowe wspomaganie modelowania systemu Zestawienie możliwości generowania kodu oferowanych przez wyselekcjonowane narzędzia CASE
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.
Komputerowe wspomaganie modelowania systemu Inżynieria zwrotna
Komputerowe wspomaganie modelowania systemu Inżynieria zwrotna
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.
Komputerowe wspomaganie modelowania systemu Koniec wykładu 11.
Integracja systemów informatycznych Wykład 12
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.
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.
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).
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.
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.
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.
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.
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.
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ć).
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).
Integracja systemów informatycznych Model referencyjny Przykłady znanych modeli referencyjnych: modele referencyjne ARIS; model referencyjny SAP R/3; modele Baan.
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.
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).
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.
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.
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.
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.
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.
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.
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).
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.
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ć?
Integracja systemów informatycznych Elementy perspektywy Do zilustrowania obiektów biznesowych w perspektywie statycznej modelu integracji systemów wykorzystać można diagramy klas.
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ć?
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.
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.
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.
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.
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.
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
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).
Integracja systemów informatycznych Koniec wykładu 12.
Metodologia zwinna Wykład 13
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.
Metodologia zwinna
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.
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.
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.
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%.
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.
Metodologia zwinna
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ć.
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.
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.
Metodologia zwinna Luka poznawcza Jednak nawet najlepsza metodologia nie zabezpiecza przed błędami, bo istnieje luka poznawcza w projektach informatycznych.
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
Metodologia zwinna
Metodologia zwinna
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ę.
Metodologia zwinna
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.
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.
Metodologia zwinna Rozwój metodyki projektowania systemów informatycznych w kierunku metod zwinnych
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.
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).
Metodologia zwinna Jedna ze zwinnych metodologii, nazywana Crystal
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).
Metodologia zwinna Cristal Na tej podstawie proponowana jest cała rodzina metod typu Cristal. Ich mapa podana jest niżej.
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.
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.
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.
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.
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.
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.
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.
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.