Modelowanie i analiza systemów informatycznych

Modelowanie i analiza systemów informatycznych.

Modelowanie i analiza systemówinformatycznych.

dr Robert Plebaniak

12 stycznia 2014 roku


Metodyka RUP

Wykład 10


Metodyka RUP

Metodyka RUP


Metodyka RUP

Znaczenie iteracyjno-przyrostowego procesuprojektowania systemów

Metodyka (ang. methodology) tworzenia systemówinformatycznych (TSI) stanowi spójny, logicznie uporządkowanyzestaw metod i procedur o charakterze technicznym iorganizatorskim, pozwalających zespołowi projektowemu realizowaćcykl życia systemu.Ogólnie metodyki można podzielić na strukturalne, obiektowe ispoł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 unifikacjiobiektowego procesu tworzenia systemu nosiła nazwę USDP(Unified Software Development Process). Autorami USDP są l.Jacobson, G. Booch oraz J. Rumbaugh. Jest to metodykarodzajowa (ang. generic), stwarzająca możliwość opracowywaniaróżnych jej konfiguracji i implementacji.


Metodyka RUP

Metodyka rodzajowa

Do głównych cech tego podejścia należą:I ukierunkowanie na przypadki użycia;I potraktowanie architektury systemu jako centralnegozagadnienia w procesie tworzenia oprogramowania;

I iteracyjno-przyrostowy charakter procesu tworzenia systemu.


Metodyka RUP

RUP

RUP (ang. Rational Unified Process ) to metodyka tworzeniasystemów informatycznych oparta na paradygmacie obiektowości ijęzyku UML, zaproponowana przez korporację Rational Software.Jako kompletna metodyka RUP zawiera następujące elementy:

I przyrostowo-iteracyjny cykl życia systemu;I pojęcia, metody i techniki z zakresu języka UML i inne, w tymheurystyczne;

I zintegrowany pakiet narzędzi CASE, wspomagający stosowanieelementów metodyki;

I role zdefiniowane w zespole projektowym i proceduryzarządzania projektem;

I kryteria oceny i monitorowania postępu prac;I hipertekstową bazę wiedzy;I internetowy serwis wspomagający metodykę i jej użytkowników.


Metodyka RUP

RUP

Metodyka RUP jest ukształtowana w sposób umożliwiającydopasowanie procesu tworzenia systemu do potrzeb konkretnegoprzedsięwzięcia na podstawie pełnego spektrum swoich możliwości.W efekcie RUP jest elastyczny - znajduje zastosowanie zarówno przymniejszych, 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:I rozwijaniem poszczególnych dyscyplin, w tym przepływówpracy oraz dotyczących ich dokumentów;

I wprowadzeniem modułów dodatkowych (ang. plug-ins) RUPoraz integracją i włączaniem nowych narzędzi CASE,wspomagających metodykę RUP;

I reorganizacją układu hipertekstowej bazy wiedzy;I zdefiniowanymi w metodyce artefaktami - modelami idokumentami.


Metodyka RUP

USDP

Założenia rodzajowej metodyki USDP, iteracyjno-przyrostowy cyklżycia systemu, a także kategorie modelowania języka UMLwykorzystywane są przez inne, aktualnie rozwijane metodykiobiektowe. Do najbardziej interesujących należą:

I XP (Extreme Programming);I Agile;I Scrum,I 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ę nazasadniczym novum - iteracyjno–przyrostowym (ang.iterative-incremental) cyklu życia systemu. Ma on postaćdwuwymiarową.


Metodyka RUP

Struktura RUP

Linia pozioma reprezentuje czas, a zatem dynamiczny aspektprocesu TSI, uwzględniając:

I fazy;I iteracje;I punkty przeglądu.

Z kolei linia pionowa odzwierciedla statyczny aspekt procesu TSI, tj.jego opis w kategoriach:

I dyscyplin;I czynności;I artefaktów;I ról;I przepływów pracy.


Metodyka RUP

Struktura RUP


Metodyka RUP

Rola

Rola oznacza obowiązki i kompetencje osoby lub zespołuzaangażowanego w proces tworzenia systemu informatycznego lubjego wycinka. W wyniku realizacji roli powstają oczekiwaneartefakty. Spektrum ról, odpowiadających często współczesnymzawodom informatycznym, jest bardzo szerokie i wiąże się zmożliwościami zaawansowanych technologii informatycznych.Przykładami ról w metodyce RUP są: menadżer projektu, inzynierprocesu, 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órejpowstaje 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 tematyczniegłównym obszarom tworzenia systemów informatycznych.


Metodyka RUP

Dyscypliny podstawowe

Dyscypliny podstawowe stanowią rdzeń procesu tworzeniasystemu. Należą do nich:

I modelowanie biznesowe;I specyfikacja wymagań;I analiza i projektowanie;I programowanie;I testowanie;I wdrożenie.


Metodyka RUP

Dyscypliny wspomagające

Dyscypliny wspomagające realizują funkcje zarządcze ikonfiguracyjne w procesie tworzenia systemu. Można do nichzaliczyć:

I zarządzanie konfiguracjami i zmianami;I zarządzanie projektem;I przygotowanie środowiska.


Metodyka RUP

Układ i zależności pomiędzy wymienionymidyscyplinami


Metodyka RUP

Podstawowy zakres merytoryczny dyscyplin w procesieRUP

Modelowanie biznesowe (ang. - business modeling) zawiera wizjęnowej, docelowej organizacji, definicje występujących w jej ramachprocesów, ról i zakresów odpowiedzialności. Informacje teprzedstawia się w postaci biznesowych diagramów.Specyfikacja wymagań (ang. requirements) - oznaczaopracowanie wizji systemu, modelu przypadków użycia izdefiniowanie wymagań niefunkcjonalnych.


Metodyka RUP


Analiza i projektowanie (ang. analysis and design ) - zawieraanalizę i projekt systemu z wykorzystaniem całego spektrumdiagramów UML.Programowanie (ang. implementation ) - pozwala na opracowaniekodu źródłowego w wybranym języku programowania orazkompilację kodu i integrację komponentów.Testowanie (ang. test) - oznacza planowanie testów oraz ocenęsystemu poprzez wykonanie szeregu testów.


Metodyka RUP


Wdrożenie (ang. deployment ) - dotyczy instalacji oprogramowaniasystemu i formalną akceptację kolejnych wersji systemu przezklienta czy użytkownika.Zarządzanie konfiguracjami i zmianami (ang. configuration andchange menagement) - obejmuje kontrole wersji artefaktówopracowanych podczas kolejnych iteracji.Zarządzanie projektem (ang. project menagement) - oznaczaplanowanie i kontrole realizacji projektu.Przygotowanie środowiska (ang. environment) - obejmujeprzygotowanie infrastruktury dla skutecznej realizacji projektu.


Metodyka RUP

Fazy

Fazą (ang. phase) w metodyce RUP jest okres między kolejnymipunktami przeglądu cyklu iteracyjno-przyrostowego, w którymzrealizowano niezbędne czynności i opracowano adekwatne artefakty.Metodyka RUP wprowadza cztery fazy:

I rozpoczęcie (ang. inception);I opracowanie (ang. elaboration);I budowa (ang. construction);I 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 integracjaartefaktó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; jejefektem jest kolejny przyrost systemu.


Metodyka RUP

Fazy w metodyce RUP i ich cele

Rozpoczęcie (ang. inception) - wypracowanie ogólnej wizjiprzedsięwzięcia oraz osiągnięcie zrozumienia i akceptacji projektu zestrony wszystkich jego uczestników.Opracowanie (ang. elaboration) - ustalenie architektury systemu,stworzenie planu projektu oraz wyeliminowanie elementówwysokiego ryzyka z projektu.Budowa (ang. construction) - stworzenie systemu na podstawieprzyjętej architektury.Przekazanie (ang. transition) - dostarczenie gotowego systemuużytkownikom czy klientom.


Modelowanie biznesowe




Znaczenie modelowania biznesowego

W procesie tworzenia systemu zgodnym z metodyką RUP pierwsządyscypliną iteracyjno-przyrostowego cyklu życia systemu jestmodelowanie biznesowe.Modelowanie biznesowe (ang. business modeling) jest sposobemodwzorowywania i dokumentowania procesów biznesowych. Wnawiązaniu do kategorii modelowania języka UML, wyróżnić można:

I modelowanie systemowe - ukierunkowane na tworzenie systemuinformatycznego, jego oprogramowania oraz infrastrukturysprzętowej;

I modelowanie biznesowe.



Reengineering

Modelowanie biznesowe można połączyć z reengineeringiemprocesów biznesowych (ang. Business Process Reengineering) - wskrócie BPR - w przypadku, gdy zamierza się dokonać radykalnejzmiany funkcjonowania organizacji i opracować modele nowychprocesów biznesowych.Modele biznesowe znajdują zastosowanie przede wszystkim wpierwszej fazie cyklu życia RUP, fazie rozpoczęcia, a w mniejszymzakresie także w kolejnych fazach (opracowaniu, budowie orazprzekazaniu).



Modelowanie biznesowe w procesie tworzenia systemu



Podstawowe kategorie pojęciowe oraz notacja graficzna

Model biznesowy, podobnie jak model systemu informatycznego,jest przedstawiany w postaci diagramów. Diagramy biznesowe są wujęciu czysto technicznym odpowiednikami diagramówsystemowych. Tak więc możliwe jest przystosowanie do potrzebmodelowania biznesowego większości diagramów wymienionych wspecyfikacji języka UML 2.0, czyli:

I diagramów przypadków użycia;I diagramów klas;I diagramów obiektów;I diagramów czynności;I diagramów maszyny stanowej;I diagramów interakcji;I diagramów struktur połączonych;I diagramów pakietów.



Praktyczne zastosowanie

Ze względu na specyfikę funkcjonowania rzeczywistych organizacjinajwiększe praktyczne zastosowanie mają następujące rodzajediagramów biznesowych:

I biznesowe diagramy przypadków użycia;I biznesowe diagramy klas;I biznesowe diagramy czynności;I biznesowe diagramy sekwencji;I biznesowe diagramy pakietów.



Podstawowe kategorie modelowania diagramówbiznesowych

W przypadku modelowania biznesowego niezbędne stają siękategorie modelowania, które nie są elementami diagramówopisujących oprogramowanie. Kategorie te mają charakterstereotypów graficznych.Biznesowe diagramy stworzone w ramach modelowania biznesowegosą transformowane w kolejnych fazach iteracyjno-przyrostowegocyklu RUP w analityczne lub systemowe diagramy języka UML.Transformacja diagramów biznesowych w systemowe nie zachodziautomatycznie. Do osiągnięcia ostatecznego efektu modelowaniasystemowego niezbędna jest praca analityczna i projektowa twórcówsystemu, stosownie do zaleceń UML i RUP.












Biznesowy kontekst systemu księgarni



Biznesowy diagram przypadków użycia systemuksięgarni



Mapa procesów biznesowych funkcjonowania księgarni



Czynność przypadku ”Dokonaj zakupu”



Biznesowy diagram sekwencji



Biznesowy diagram klas



Biznesowy diagram klas z pracownikami biznesowymi



Jednostki organizacyjne księgarni



Zależność pomiędzy działami a pracownikami



Koniec wykładu 10.


Modelowanie analityczne

Wykład 11






Znaczenie modelowania analitycznego

Modelowanie analityczne to technika wspomagająca język UML,która słóży do dokumentowania wyników prac analitycznych iwczesnych prac projektowych.Diagramy modelowania analitycznego wspomagają dyscyplinęanalizy i projektowania; zostały zaproponowane przez I. Jacobsonaw metodyce OOSE [Jacobson-1992]. W praktyce diagramy teumożliwiają przejście od diagramów przypadków użycia oraz ichscenariuszy do diagramów klas oraz diagramów interakcji napoziomie konceptualnym i implementacyjnym.



Diagram modelowania analitycznego w procesietworzenia systemu



Podstawowe kategorie pojęciowe oraz notacja graficzna

Model analityczny (ang. analysislrobustness model), grupującydiagramy analityczne, można traktować jako rodzaj wstępnegoprojektu. Jego celem jest wspomaganie identyfikacji klas.Podstawowymi elementami diagramów modelowania analitycznegosą:

I klasy analityczne;I aktorzy;I związki.



Notacja graficzna

Diagramy analityczne modelowane są jako diagramy klas zzastosowaniem trzech stereotypowanych klas:

I granicznych (ang. boundary);I sterujących (ang. control);I przechowujących (ang. entity).



Notacja

W praktyce podczas analizy scenariuszy przypadku użyciaidentyfikuje się obiekty analityczne, które podczas projektowaniasystemu ulegają przekształceniu w różne kategorie modelowaniawłaściwe dla poziomu implementacyjnego, takie jak atrybuty klas,operacje lub same klasy. W związku z tym te kategorie modelowaniaanalitycznego w literaturze przedmiotu określane są często mianemobiektów analitycznych.



Notacja oraz charakterystyka klas analitycznych









Notacja oraz charakterystyka

W trakcie opracowywania diagramów modelowania analitycznegowykorzystywany jest również symbol aktora zaczerpnięty zdiagramów przypadków użycia. Poszczególne typy klas sąpowiązane. Kluczowe znaczenie odgrywa w tym kontekście związekasocjacji, przy czym asocjacje te mogą być dwukierunkowe lub miećprzypisany kierunek nawigacji uszczegóławiający specyfikacjęsposobu przepływu informacji.



Diagram analityczny



Zasady obowiązujące w diagramach modelowaniaanalitycznego

Przyjmujemy nastepujce oznaczenia;I symbol ”+” oznacza, że elemanty wyszczególnione w danymwierszu i kolumnie mogą się łączyć;

I symbol ”-” łączenie elementów wyszczgólnionych w danymwierszu i kolumnie jest niepoprawne.



Zasady obowiązujące w diagramach modelowaniaanalitycznego



Proces tworzenia modelu analitycznegoTworzenie diagramów modelowania analitycznego poprzedzone jestw ramach iteracyjno-przyrostowego procesu RUP modelowaniembiznesu oraz specyfikacją wymagań tworzonego systemu w postacisystemowych diagramów przypadków użycia. Stąd proces ten możnapodzielić na następujące etapy:1. wyselekcjonowanie, stosownie do złożoności dziedzinyprzedmiotowej, odpowiednich:

I diagramów modelu biznesowego,I diagramu (diagramów) przypadków użycia oraz jego (ich)scenariuszy;

2. przeniesienie aktorów z diagramów przypadków użycia nadiagramy analityczne;

3. identyfikacją klas analitycznych i określenie ich rodzajów;

4. integracją poszczególnych zidentyfikowanych elementów wformie diagramów analitycznych składających się na modelanalityczny.



Konwersja kategorii biznesowych na kategorie klasanalitycznych

W trakcie tego procesu obowiązują określone zasady konwersji zmodeli biznesowych i systemowych diagramów przypadków użyciana kategorie diagramów modelowania analitycznego.Analogicznie, należy zauważć, że sporządzenie klas analitycznych napodstawie systemowych przypadków użycia nie polega nabezpośredniej zamianie notacji. Konwersja systemowego modeluprzypadków użycia na modele analityczne obejmuje przekształcenieaktorów w klasy graniczne bądź ich bezpośrednie przeniesienie.Natomiast przypadki użycia są przekształcane w odpowiednierodzaje klas analitycznych - graniczne, sterujące i przechowujące. Wdalszych iteracjach RUP klasy analityczne przekształcane są w klasysystemu.









Model analityczny


Komputerowe wspomaganie modelowania systemu




Pakiety CASE wspomagajce UML i RUP

Metodyki tworzenia systemów informatycznych są komputerowowspomagane przez narzędzia CASE (Computer Aided SoftwareEngineering). Firmy komputerowe oraz naukowe środowiskoinformatyczne opracowały wiele tego typu narzędzi modelowaniasystemów. Ich znaczenie rośnie wraz ze wzrostem zakresu projektu,co skutkuje rozbudowaną i niezwykle trudną w zarządzaniudokumentacją. Zarówno metodyka RUP, jak i język UML sąwspomagane przez narzędzia CASE.



Pakiet CASE

Zastosowanie narzędzi CASE pozwala na wykonanie następującychzadań w procesie tworzenia systemów:

I wspomaganie specyfikacji i dokumentowania projektówinformatycznych;

I sprawdzanie semantycznej poprawności diagramów UML imodelu jako całości;

I wspomaganie iteracyjno-przyrostowego cyklu życia systemu;I generowanie szkieletowego kodu źródłowego na podstawiemodelu systemu;

I inżynierię zwrotną (ang. reverse engineering);I synchronizację modelu systemu z kodem źródłowym;I możliwość równoległego tworzenia oprogramowania przez wieluczłonków zespołu projektowego.



Pakiety CASE

Stopień akceptacji oprogramowania CASE, ukierunkowanego najęzyk UML i metodykę RUP, jest w środowisku profesjonalnymzróżnicowany. W niektórych przypadkach jest ono traktowane jakonieodłączny element tworzenia oprogramowania, w innychwykorzystywane są jedynie poszczególne funkcje.



Wybrane narzędzia CASE dla UML i RUP



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;




iod - diagram sterowania interakcją;

sd - diagram sekwencji;

cd - diagram komunikacji;

cod - diagram komponentów;

dd - diagram rozlokowania;

td - diagram harmonogramowania.









Generowanie szkieletowego kodu źródłowego

Generowanie kodu jest jedną z fundamentalnych opcji w cyklu życiasystemu i ważną cechą narzędzia CASE. Naturalnie w efekcie jejwykorzystania nie powstaje pełna, możliwa do natychmiastowegouruchomienia 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ązkipomiędzy elementami modelu i komponenty. Zawartośćposzczegłlnych operacji musi być następnie uzupełniona przezprogramistów.



Zaletywykorzystania funkcji generowania koduZalety wykorzystania funkcji generowania kodu:

I pomaga w utrzymaniu przejrzystości jego struktury i eliminujewiele pomyłek technicznych, które programiści mogą popełnićna wczesnym etapie kodowania;

I zasadniczo skraca czas tworzenia gotowego systemu.

Należy jednak pamietać, że:I nie wyręcza jednak twórcy systemu w czynnościach innych niżrutynowe, takich jak projektowanie interfejsu użytkownika(GUI);

I wymaga także konsekwentnego przestrzegania pewnych regułmodelowania;

I wskazane jest ponadto wykorzystywanie funkcji sprawdzaniapoprawności semantycznej modelu przed przejściem dogenerowania kodu, jeśli opcja taka oferowana jest przeznarzędzie CASE.



Zestawienie możliwości generowania kodu oferowanychprzez wyselekcjonowane narzędzia CASE









Inżynieria zwrotna

Zdolność przeprowadzenia inżynierii zwrotnej to zdolność doutworzenia 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ścikodu systemu względem jego modelu. Zależność ta jestdwukierunkowa 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 tympoprawek w dokumentacji. Praktyka tworzenia systemówinformatycznych dowodzi, że posiadanie aktualnego modelu systemujest nie do przecenienia.



Inżynieria zwrotna



Inżynieria zwrotna



Obsługiwane platformy

Wysiłki producentów oprogramowania narzędziowego zmierzającedo wydłużenia listy obsługiwanych platform zwiększają elastycznośćzespołu projektowego.Wspieranie systemów z rodziny Windows można określić jakopowszechną praktykę. Jest tak w przypadku wszystkichanalizowanych 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 wersjiprzeznaczonej dla systemu operacyjnego MacOS.



Koniec wykładu 11.


Integracja systemów informatycznych

Wykład 12




Integrację definiuje się jako połączenie niejednorodnych składnikóww całość, tak że współdziałając w ramach tej całości wzmagająswoją skuteczność.Podkreślany jest ten synergistyczny efekt integracji. Terminintegracja odnoszony jest także do integracji zarządzaniaorganizacją jego systemu informacyjnego. W takim ujęciu oznaczaprzede wszystkim integrację systemu zarządzania i systemówinformacji zorientowanych na wspomaganie podejmowania decyzji, zktórych każdy już przedstawia określony poziom integracji. Jakopodstawowy cel integracji systemów informatycznych wymienia sięczęsto ”integrację biznesu”. Ta integracja biznesu jest możliwa doosiągnięcia za pomocą integracji procesów biznesowych poprzezrekonstrukcję i integrację samych procesów oraz systemówinformacji, które wspomagają te procesy.




Integracja systemów informatycznych jest też rozważana wkontekście koncepcji M. Portera - łańcucha tworzenia wartości,odnoszącego się do działalności jednej firmy, jak i tzw. ciągówgospodarczych obejmujących kilka wewnątrzfirmowych łańcuchówgospodarczych. Stąd kryteria oceny poziomu integracji odnoszą siędo współdziałania partnerów w tworzeniu wartości w ramachprzedsiębiorstwa oraz partnerów biznesowych na rynku, sięgając ażdo klientów.



Integracja

W literaturze rozważane są różne typy, czy też formy integracji.Przykładowo wymienia się:

I integrację systemową (ang. system integration);I integrację aplikacji (ang. application integration);I integrację biznesową (ang. business integration).



Integracja systemowa

Integracja systemowa jest rozumiana jako taka integracja, któradotyczy komunikacji między systemami, tj. połączenia i wymianydanych za pomocą sieci komputerowych i protokołówkomunikacyjnych.



Integracja aplikacji

Integracja aplikacji dotyczy współdziałania aplikacji realizowanychna różnych platformach sprzętowych i oprogramowania, jak równieżwspólnego użytkowania danych przez różne aplikacje (commonshared data). Integracja aplikacji jest realizowana za pomocątworzenia środowisk przetwarzania rozproszonego, interfejsówprogramów użytkowych API (Application Program Interfaces) istandardów w zakresie wymiany danych.



Integracja biznesowa

Integracja biznesowa dotyczy koordynacji procesów gospodarczych.Wymaga zrozumienia zasad działania biznesu i precyzyjnegozdefiniowania reguł operacyjnych biznesu.



Usługi integracyjne

Wyróznia się następujące rodzaje usług integracyjnychodpowiadających różnym poziomom integracji:

I kompleksowe usługi doradczo-biznesowe, mające na celuprzebudowę firmy (ang. /T total solution provider) - integracjana poziomie biznesu;

I kompleksowe usługi, mające na celu doprowadzenie dowdrożenia oprogramowania biznesowego (ang. TT solutionprovider) - integracja na poziomie aplikacji;

I usługi z zakresu instalacji oprogramowania komunikacyjnego,biurowego, systemów operacyjnych (ang. IT systemsintegrator) - integracja na poziomie systemowym;

I usługi z zakresu instalacji sieci ( IT] network systemsintegrator) - integracja na poziomie systemowym.



Integrator

Jako typową paletę usług integratora wymienia się:I integrację systemów w postaci sprzętu, sieci i oprogramowaniaróżnych producentów,

I konsultacje dotyczące różnych etapów cyklu życia systemu,I tworzenie oprogramowania na zamówienie klienta,I zarządzanie projektami informatycznymi,I utrzymywanie systemu komputerowego klienta,I zapobieganie i usuwanie skutków katastrof.

Coraz częściej poleca się usługi integratora intenetowego.



IntegracjaKrokami prowadzącymi do osiągnięcia pełnej integracji w dziedziniesystemów informatycznych jest osiągnięcie komputerowozintegrowanego wytwarzania (ang. Computer IntegratedManufacturing) oraz komputerowo zintegrowanego zarządzania(ang. Computer Integrated Management) oraz obu tych obszarów.Architektury i modele referencyjne, to narzędzia ułatwiającezintegrowane spojrzenie na systemy informatyczne przez pryzmatprocesów gospodarczych. Pod pojęciem architektur i modelireferencyjnych rozumie się architektury i modele opracowane woparciu o zebrane doświadczenia gospodarowaniaprzedsiębiorstwami i wdrażania systemów informatycznych,zawierające ogólne rozwiązania, np. dla określonej branży lubdziedziny zastosowań, i stanowiące podstawę opracowywaniaarchitektur i modeli dla ”konkretnych” - rzeczywistych sytuacjiprzedsiębiorstw lub dokonywania oceny ”konkretnych” jużwdrożonych architektur i modeli Używane tu słowo referencyjnypochodzi od łacińskiego słowa referre (odnosić się, informować,odwoływać się, rekomendować).



Architektura lub model referencyjnyArchitektura lub model referencyjny powinny być wzorcamipowszechnie uznawanymi, które mogą zostać użyte jako rozwiązaniawyjściowe przystosowywane do indywidualnych potrzeb.Architektury i modele referencyjne stwarzają podstawy integracjisfery biznesowej i sfery technologii informatycznych. Przykładamiznanych architektur referencyjnych są:

I CIMOSA (Open System Architecture for Computer IntegratedManufacturing);

I GRAI/GIM (Graphes de Resultats et Actives Interrelies/GRAIIntegrated Methodology);

I PERA (Purdue Enterprise Reference Architecture);I GERAM (Generalized Enterprise Reference Architecture andMethodology);

I SOM (Semantic Object Model Architecture);I IFIP (Information System Methodology Organizacji IFIP(International Federation for Information Processing).



Model referencyjny

Przykłady znanych modeli referencyjnych:I modele referencyjne ARIS;I model referencyjny SAP R/3;I modele Baan.



Architektury i modele referencyjne

Architektury i modele referencyjne, opracowywane przezproducentów oprogramowania, firmy wdrażające systemyinformatyczne, 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 zróżnych ”punktów widzenia”, takich jak: dane, funkcje, organizacja,proces gospodarczy i na różnych poziomach opisu, odpowiadającychfazom cyklu życia systemu: analiza i definiowanie wymagańużytkownika, projektowanie, wdrażanie, utrzymywanie systemu.



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 jejidentyfikację, archiwowanie, inwentaryzację, powiększanie(pozyskiwanie), wykorzystywanie. W organizacjach niezbędne jestzapewnienie możliwości współużytkowania wiedzy i swobodnegoprzepływu informacji (dystrybucja informacji i wiedzy). Wymaga tointegracji narzędzi IT, takich jak systemy baz wiedzy, siecineuronowe, systemy wspomagania decyzji grupowych (pracygrupowej), hurtownie danych, systemy pozyskiwania danych (datamining).



Organizacje wirtualne

Wirtualne organizacje istnieją dzięki nowej technologii pracy w sieci,umożliwiającej rozproszoną pracę. Wirtualne przedsiębiorstwadziałaj ą tak jak inne firmy, lecz nie mają osobowości prawnej. Worganizacji wirtualnej procesy gospodarcze przebiegaj ą poprzezwiele zlokalizowanych w różnych miejscach punktów sprzedaży iprodukcji, i sięgają do zewnętrznych partnerów przedsiębiorstwa(dostawcy i klienci). Nowa forma przedsiębiorstw skłania doposzukiwania odpowiedzi na pytanie o przydatność dla takichorganizacji architektur i modeli, zapewniających integracjęsystemów informatycznych, utworzonych dla organizacji”tradycyjnych” i tworzenia odpowiednio dostosowanych.



Integracja

Sposób rozumienia integracji zmienia się i pozostaje w ścisłejzależności od osiągniętego poziomu rozwoju w zakresie technologiiIT i zarządzania. Towarzyszy temu rozwój całościowych koncepcji,takich jak komputerowo zintegrowane wytwarzanie (ComputerIntegrated Manufacturing), komputerowo zintegrowane zarządzanie(Computer Integrated Management), komputerowo zintegrowaneprzedsiębiorstwo - biznes (Computer Integrated Business), któreprzedstawiają wskazówki, co do realizacji integracji w dziedziniesystemów informatycznych.System informatyczny przedsiębiorstwa przestaje być uważany zaodrębny element, wymagający ”samodzielnej” integracji, ale corazczęściej jest uważany za immanentny składnik całościowotraktowanego przedsiębiorstwa, co znajduje swój wyraz m.in. wcoraz powszechniejszym używaniu terminu zintegrowaneprzedsiębiorstwo zamiast zintegrowany system informatyczny.




Integracją systemów informatycznych nazywamy osadzanieistniejących i nowych systemów informatycznych w istniejącymśrodowisku informatycznym.



Integracja

Integracja systemów informatycznych wymaga wiedzy o środowiskusystemu informatycznego oraz jego otoczeniu. Integrowany systeminformatyczny osadzany jest w środowisku biznesowym i dlategokonieczna jest znajomość otaczających go procesów biznesowych.W celu umożliwienia efektywnego współdziałania systemuinformatycznego z otoczeniem (tj. innymi systemamiinformatycznymi) należy skonstruować odpowiednie interfejsy.



Interfejs

Komunikacja między systemami informatycznymi odbywa się zapośrednictwem interfejsów. W związku z tym interfejs jestpodstawowym elementem modelu integracji systemów. Za jegopośrednictwem system informatyczny przesyła informacje do innegosystemu informatycznego.



Integracja

W konsekwencji można stwierdzić, że modelowanie integracji toinaczej modelowanie komunikatów wymienianych (przez interfejsy)między różnymi systemami informatycznymi oraz procesy niezbędnedo tej wymiany komunikatów.



Poziom analizy

Na potrzeby integraci systemów informatycznych musimyzdefiniować, które informacje mają być wymieniane oraz w jakisposób. Z tego powodu model integracji systemów opisujemy biorącpod uwagę różne punkty widzenia (perspektywy).Najogólniejszy podział związany z perspektywami wyodrębina, dwieperspektywy, tj.

I perspektywę procesu obrazującą aktywności podejmowaneprzez system informatyczny podczas wymiany komunikatów zinnymi systemami informatycznymi;

I perspektywę statyczną opisującą zawartość i strukturę obiektówbiznesowych podlegających wymianie (stanowiącychkomunikat).



Elementy perspektywy

Aktywności, które muszą zostać wykonane w celu wymianykomunikatów między systemami informatycznymi, można opisać zapomocą diagramów sekwencji i diagramów aktywności:

I Diagram sekwencji opisuje chronologiczną kolejność wymianykomunikatów między systemami informatycznymi;

I Diagram aktywności opisuje przepływ działań. Obrazuje onzależności między indywidualnymi akcjami oraz przepływobiektów biznesowych.



Perspektywa procesu

Etapy konstrukcji perspektywy procesu:

1. Określenie interfejsów, czyli pomiędzy jakimi systemamiinformatycznymi odbywa się komunikacja?

2. Identyfikacja zaangażowanych systemów, czyli które systemyinformatyczne 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żnionepodejmowane akcje?

6. Weryfikacja perspektywy, czyli czy wszystko wydaje się działać?



Elementy perspektywy

Do zilustrowania obiektów biznesowych w perspektywie statycznejmodelu integracji systemów wykorzystać można diagramy klas.



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 obiektubiznesowego?

3. Adaptacja klas i atrybutów z diagramu klas systemuinformatycznego, czyli jakie informacje mają być uwzględnionena 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 jakiezwiązki klas będą potrzebne?

6. Weryfikacja perspektywy, czyli czy wszystko wydaje się działać?



Integrowanie w przedsiebiorstwach

Zastosowanie architektury obserwatora procesu pozwala nazintegrowanie rożnych systemów informatycznych wprzedsiębiorstwie. Generalnie, idea obserwatora procesu polega nautworzeniu jednolitego, spójnego modelu danych bieżących(utworzenie „obrazu bieżącego stanu całej produkcji) iudostępnianie go aplikacjom biznesowym według ich potrzebpoprzez międzynarodowe standardy komunikacji (standard OPC) iwymiany danych.



OPC

Zastosowanie serwera OPC, w roli obserwatora procesu, dointegracji systemów w przedsiębiorstwie pozwala nausystematyzowanie struktury połączeń z warstwą procesową ipozyskiwanie danych w jednorodny, zgodny z międzynarodowymistandardami komunikacyjnymi sposób. Raz pobrane dane, służąwielu różnym systemom informatycznym. To istotnie podnosiefektywność pozyskiwania i transferu danych w przedsiębiorstwie.



OPC

OPC jest otwartym standardem komunikacyjnym stosowanym wautomatyce przemysłowej i informatycznych systemach wyższychwarstw, a mianowicie biznesowej i zarządzania, przedsiębiorstwprzemysłowych. Interoperacyjność aplikacji jest zapewniona dziękiutworzeniu i utrzymywaniu specyfikacji otwartych standardów.Utrzymaniem i rozwojem standardu zajmuje się OPC Foundation.OPC powstał i został tak zaprojektowany, aby łączyć aplikacjebazujące na systemach operacyjnych ogólnego stosowania (np.Windows) ze sprzętem i oprogramowaniem aplikacyjnym automatykiprzemysłowej (urządzenia procesowe), nadzorującym i sterującymprocesem 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żneod typu oraz źródła danych.



OPC

Dla wielu pakietów oprogramowania serwer OPC dostarcza wjednolity sposób danych z urządzeń sterujących i nadzorującychproces technologiczny (dane procesowe) takich, jak sterowniki PLC,czy systemy DCS. Tradycyjnie, jeżeli jakieś oprogramowanie mamieć dostęp do danych procesowych, musi zostaćzaimplementowany specjalny sterownik. Zadaniem OPC jestzdefiniowanie wspólnego interfejsu, który utworzony raz - może byćwykorzystywany przez dowolnego klienta biznesowego,oprogramowanie SCADA, HMI lub dowolny pakiet oprogramowania.



OPC

Bazując na standardach Microsoft OLE (ang. Object Linking andEmbedding), COM(ang. Component Object Model) i DCOM (ang.Distributed Component Object Model), technologia OPC definiujeinterfejsy przeznaczone do komunikacji z urządzeniamiprzemysłowymi, przez co pozwala uniezależnić oprogramowaniemonitorujące od różnorodnych rozwiązań stosowanych przezproducentów sprzętu procesowego. Technologie COM/DCOMdostarczają infrastrukturę i środowisko programistyczne dlatworzenia i rozwoju oprogramowania. Obecnie są dostępne setkiserwerów i klientów OPC.



OPCW ramach projektu zajmującego się standaryzacją OPC powstałyróżne specyfikacje, z których każda definiuje odrębnąfunkcjonalność. Wśród istniejących specyfikacji możemy wyróżnić:

I OPC Data Access (OPC DA) - umożliwia dostęp doaktualnych danych generowanych w czasie rzeczywistym. Przypomocy OPC DA do serwera OPC kierowane są zapytania oaktualne wartości zmiennych procesowych - np. temperatur,ciśnień itp. Komunikacja z każdym serwerem odbywa się w takisam sposób, z wykorzystaniem tego samego formatu. Klient niemusi wiedzieć w jaki sposób serwer komunikuje się zurządzeniem. Wielu klientów może korzystać jednocześnie ztych samych danych udostępnianych przez serwer.

I OPC Historical Data Access (OPC HDA) - umożliwiaprzeglądanie i analizę zgromadzonych danych historycznych, npw celu oceny wydajności systemu czy przewidywania błędów.Klient uzyskuje dostęp do zarchiwizowanych danych (odczytówjakiegoś urządzenia itp.) poprzez zgłaszanie zapytań do serweraOPC HDA.



OPC

I OPC Alarms and Events (OPC AE) - służy do informowania owystę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ązaneze stanem, jak np. zdarzenie przejścia danej wartości dopoziomu alarmowego lub niezwiązane ze stanem, jak zmianykonfiguracji, czy błędy systemowe. Serwery OPC AE mogąpobierać dane bezpośrednio z urządzenia lub z serwera OPCDA. Serwer OPC AE może być samodzielnym modułem lub teżwchodzić w skład serwera OPC DA.

I OPC Security - służy zapewnieniu bezpieczeństwa dostępu dodanych oferowanych przez serwery OPC. Umożliwia poprawnąweryfikację klienta, który chce uzyskać dostęp i poprawnościtransmisji (czy dane nie zostały zmienione).



Koniec wykładu 12.


Metodologia zwinna

Wykład 13


Metodologia zwinna

Metodologia zwinna

Obecnie najczęściej wykorzystywane systemy informacyjne wdziedzinie ekonomii i zarządzania ukierunkowane są głównie nausprawnianie zarządzania w celu lepszego zaspokajania potrzebwszystkich uczestników procesów gospodarczych.


Metodologia zwinna


Metodologia zwinna

Innowacje w systemach informatycznych

Najważniejsze kierunki innowacji wprowadzanych w systemachinformacyjnych oparte są o wymagania:

I integracji systemów, danych i procesów;I unifikacji funkcji cząstkowych systemów;I zwiększania dostępności do bazy danych dla wszystkichkomórek organizacyjnych;

I upowszechniania nowoczesnych sposobów prezentacji danych(wizualizacji) dla celów wspomagania ich analizy;

I doskonalenia procesów podejmowania decyzji i ichprzekazywania;

I 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:

I zapewnienia kompleksowego charakteru funkcjonalnego całegosystemu;

I stałego podnoszenia zaawansowania merytorycznego itechnologicznego;

I zmierzania do elastyczności funkcjonalnej i strukturalnej;I zapewnienia stałej zgodności ze zmieniającymi się elementamiotoczenia systemowego, azwłaszcza z aktualnym stanemprawnym, ewoluującym zgodnie z przyjętymi proceduramilegislacyjnymi.


Metodologia zwinna

Ekonomiczne systemy informacyjne są projektowane i realizowane wtaki sposób, aby dane przetwarzane przez ów system byłybezpieczne i na każdym jego etapie chronione.

Dlatego też w jak największym stopniu musi być zapewnionapoufność i integralność wszelkich danych posiadanych przez system,a dostępność do danych zawartych w systemie powinna być zgodnaz przyjętą hierarchią haseł i przywilejów dostępu.


Metodologia zwinna

Mimo wielu lat rozwoju ryzyko prowadzenia projektówinformatycznych nadal jest duże.

W USA rozwój oprogramowania pochłania rocznie 250 mld dolarówrocznie, w postaci około 175 tys. projektów informatycznych.Badania Standish Group dla rynku Amerykańskiego dowodzą, że31% z tych projektów jest przerywanych na jednym z etapówpośrednich, zaś 52% projektów przekracza planowany budżet.Typowy system informatyczny jest droższy niż planowano o średnio89%.


Metodologia zwinna

Metodologia

Dlatego niezbędna jest właściwa metodologia projektowania iwdrażania systemów informatycznych.Stosowną metodologię dostarcza głównie inżynieriaoprogramowania.Inżynieria oprogramowania jest praktycznym zastosowaniemwiedzy naukowej do projektowania i tworzenia systemówinformacyjnych i informatycznych oraz dokumentacji wymaganej doich opracowania, uruchomienia oraz pielęgnacji.Najnowsze prace odwołujące się do inżynierii oprogramowaniaprzewidują występowanie aż 12 faz procesu projektowego.


Metodologia zwinna


Metodologia zwinna

1. Inicjalizacja systemu i wstępne planowanie:Znalezienie potencjalnego obszaru zastosowania systemuinformatycznego, który wspomoże lub zastąpi dotychczasowemetody przetwarzania informacji.

2. Analiza wymagań i specyfikacja wymagań:Identyfikacja problemów, które nowy system informacyjny marozwiązać. Zarysowanie właściwości operacyjnych systemu,wydajności i zasobów sprzętowych niezbędnych do użytkowaniai konserwowania systemu.

3. Specyfikacja funkcjonalna i prototypowanie:Identyfikacja i formalizacja obiektów obliczeń, ich atrybutów izależności. Specyfikacja transformacji, którym obiekty będąpodlegać.


Metodologia zwinna

4. Dekompozycja problemu:Podział systemu na logiczne podsystemy na podstawiewymagań i specyfikacji. Analiza logicznych podsystemów podką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, komponentamii modułami w sposób uwzględniający szczegóły ich budowy iwymagania wobec nich.

6. Szczegółowe projektowanie i specyfikacja komponentów:Opracowanie i kodyfikowanie metod przetwarzania informacji wkomponentach.

7. Implementacja komponentów i usuwanie błędów:Wytwarzanie kodu źródłowego komponentów na podstawieuprzednich specyfikacji. Testowanie podstawowych funkcjikomponentów.


Metodologia zwinna

8. Asemblacja systemu i testowanie:Weryfikacja komponentów pod kątem kompletności i zgodnościze 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 wtrakcie prowadzenia projektu pod kątem raportów dla odbiorcy.

10. Opracowanie procedur instalacyjnych i instalacja:Opracowanie dokumentacji instalacyjnej opisującej sposóbinstalacji systemu.

11. Szkolenie dla użytkowników:Zapoznanie użytkowników z systemem. Zapoznanie ich zmożliwościami i ograniczeniami systemu.

12. Użytkowanie i konserwacja oprogramowania:Użytkowanie, usuwanie błędów dostrzeżonych w trakcieużytkowania, rozbudowywanie systemu o nowe właściwości,poprawa wydajności systemu.


Metodologia zwinna

Luka poznawczaJednak 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 trakcieanalizy dostrzegane i nie zostaną wyczerpująco opracowane, możnawięc określać je mianem ryzykownych punktów projektu. Wokółtych zagadnień Boehm zbudował spiralny model tworzeniaoprogramowania


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żdegouczestnika procesu (win condition). Należy doprowadzić donegocjacji pomiędzy uczestnikami podczas oceny prototypów, jeśliich warunki sukcesu wykluczają się.


Metodologia zwinna


Metodologia zwinna

Metodologie zwinneArchitektury i modele referencyjne

Metody kaskadowe i spiralne bywają czasem nadmierniesformalizowane, dlatego w ostatnich latach zaczęto lansowaćbardziej swobodną metodykę projektowania systemówinformatycznych, 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 metodprojektowania są dosyć oczywiste i łatwe do zaakceptowania:

I ludzie, ich kontakty, zdolność do rozwiązywania problemów sąważniejsze niż sztywne procedury i narzędzia zarządzania,

I wynikiem projektu jest pracujące oprogramowanie a niedokumentacja,

I z użytkownikiem się współpracuje a nie negocjuje kontrakt,I ważniejsza jest umiejętność reagowania na zmieniające sięwarunki otoczenia niż podążanie za opracowanym na wstępieplanem.


Metodologia zwinna

Rozwój metodyki projektowania systemówinformatycznych w kierunku metod „zwinnych


Metodologia zwinna

Skala dojrzałości modeli tworzenia systemówinformatycznych pokazuje, że metody „zwinne możnastosować głównie dla niezbyt dużych systemów.


Metodologia zwinna

Metodyki zwinne

Wśród metod zwinnych obecnie można wymienić:I Metodyka Crystal (Crystal family),I Projektowanie zorientowane na właściwości (Feature DrivenDevelopment),

I Modelowanie zwinne (Agile Modeling),I Programowanie ekstremalne (Extreme Programming),I Adaptacyjny rozwój oprogramowania (Adaptive SoftwareDevelopment),

I Metodyka scrum (Scrum development),I Prototypowanie (Prototyping methodology),I Szybkie programowanie internetowe (Internet SpeedDevelopment),

I 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ściprojektu (kategoryzowanego poprzez litery C, D, E, L) i wzależności od jego rozmiaru, mierzonego liczbą projektantówzaangaż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ącychetapów.


Metodologia zwinna




Metodologia zwinna

Założeniem leżącym u podstaw FDD jest inkrementacyjneopracowywanie 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 iiteracyjnie dzielona na coraz to mniejsze znaczeniowo obszary.Każdy niepodzielny obszar znaczeniowy jest opracowywany przezprzypisaną do niego grupę projektantów, w wyniku czego powstajemodel szczegółowy, będący składnikiem całościowego modelusystemu.


Metodologia zwinna




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ścigłówne, które rozpadają się na zestawy funkcjonalności w kolejnychhierarchiach.Listy te są przeglądane przez użytkowników i inwestorów w celukontroli poprawności i kompletności.


Metodologia zwinna




Metodologia zwinna

Planowanie nakłada na kierownictwo projektu obowiązekopracowania długookresowego planu prac powiązanego zfunkcjonalnościami, ich zależnościami i priorytetami.Poszczególne elementy listy funkcjonalności przydzielane sązespołom a w ich ramach konkretnym programistom opiekunomklas.Klasa jest tu rozpatrywana w rozumieniu programowaniaobiektowego.


Metodologia zwinna




Metodologia zwinna

Kolejne fazy: Projektowanie funkcjonalności i wykonaniefunkcjonalności wykonuje się iteracyjnie i jeśli to możliwerównolegle.Każda funkcjonalność znajduje swą realizację wewnątrz obiektu(klasy), do każdej klasy przyporządkowany jest programista dbającyo jej spójność, poprawność i efektywność kodu. Jest on zarządzającyobiektem (klasą). Zarządzający obiektami są formowani w małezespoły (feature teams). Sposób organizacji zespołów w przybliżeniuodzwierciedla hierarchię funkcjonalności.Istotną postacią w zespole projektowym jest zarządca konfiguracjizajmujący się zagadnieniami kontroli wersji i identyfikacją każdej„historycznej wersji kodu źródłowego.


Metodologia zwinna

DSDM - Metodyka Projektowania SystemówZmiennych w Czasie

Inną ważną metodologię projektowania zaproponowało brytyjskiekonsorcjum DSDM. Biorąc pod uwagę fakt, że zadania związane zprojektowanym systemem zawsze podlegają zmianom opracowanoMetodykę Projektowania Systemów Zmiennych w Czasie DSDM(Dynamic Systems Development Methods).


Metodologia zwinna

DSDM

Proces DSDM składa się z:I inspekcji zastosowalności,I badań biznesowych,I iteracyjnego opracowania modelu funkcjonalnego (Functionalmodel iteration),

I iteracyjnego projektowania i implementacji (Design and builditeration),

I wdrożenia.


Metodologia zwinna

Inspekcji zastosowalności

Inspekcja zastosowalności wykonywana jest jednokrotnie napoczątku projektu po to aby potwierdzić zasadność stosowaniametody DSDM. W trakcie tej fazy wstępnie określa się ryzykownepunkty w projekcie, jeśli to niezbędne buduje się prototypy.Rozległość prac w tej fazie jest ograniczona do kilku tygodni.


Metodologia zwinna

Badania biznesowe

Badania biznesowe mają na celu wstępne rozpoznanie zagadnienia iidentyfikację osób po stronie odbiorcy, które są kluczowe dlaprojektu lub jego części. Osoby te zostaną w późniejszym okresiewłączone w proces opracowywania systemu. Wyniki tej fazy totakże wysokopoziomowy opis systemu (Businnes Area Definition),specyfikacja zakresu systemu, zarys architektury systemu (SystemArhitecture Definiction) oraz Plan prototypowania (OutlinePrototyping Plan).


Metodologia zwinna

Iteracyjnego opracowania modelu funkcjonalnego

Budowa modelu funkcjonalnego jest działaniem składającym sięnaprzemiennie z procesów analizy i budowy prototypów. Wynikiprototypowania służą do poprawienia i uszczegółowienia modelianalitycznych. Jeśli to możliwe prototypy są udoskonalane w takisposób, by można było je włączyć do produktu końcowego.Wynikiem tej fazy jest model funkcjonalny oraz kod prototypów.Prototypowanie jest często traktowane jako forma testowaniamodelu funkcjonalnego.


Metodologia zwinna

W każdej pętli iteracji tworzone są następujące dokumenty:I lista funkcjonalności do opracowania wraz z ich priorytetami,I uwagi i komentarze użytkowników na temat prac w aktualnymcyklu (Functional prototyping review documents),

I wymagania niefunkcjonalne,I analiza ryzyka pod kątem dalszych prac.


Metodologia zwinna

Projektowanie i implementacja

Projektowanie i implementacja to właściwa faza budowaniasystemu. Wyniki prac nad modelem funkcjonalnym są przetwarzanew kod źródłowy właściwego produktu. Prototypy powstałe w trakcieprac nad modelem funkcjonalnym mogą być w tej fazie adaptowanedo kodu aplikacji. Wynikiem tej fazy jest przetestowany produktzawierający uzgodniony wcześniej zestaw funkcjonalności.


Metodologia zwinna

DSDM

Zaletą metodyki DSDM jest to, że na każdym etapie projektowaniai budowy systemu produkt jest oceniany przez twórców iużytkowników, a uwagi wynikające z oceny opracowywane są wramach kolejnych iteracji.


Metodologia zwinna

DSDMDSDM literalnie wprowadza następujące praktyki:

I Aktywny udział użytkownika w procesie tworzeniaoprogramowania;

I Zespoły DSDM muszą być uprawnione do podejmowaniadecyzji;

I Naciska się na częste dostarczanie nowych wersjioprogramowania;

I Nowe wersje są oceniane pod kątem odpowiedniości dlazastosowań biznesowych;

I Stosuje się iteracyjne i inkrementalne podejście do tworzeniaoprogramowania;

I Prowadzi się kontrolę wersji tak by każda zmiana byłaodwracalna;

I Wymagania systemowe są określane zgrubnie i sąuszczegóławiane samym procesem DSDM;

I Testowanie jest integralną częścią wszystkich faz w projekcie.


Metodologia zwinna

Programowanie ekstremalne

Programowanie ekstremalne (eXtreme Programming) powstało jakopróba zaradzenia problemom związanym z długimi cyklamidostarczania oprogramowania i spadkiem zainteresowania inwestorazadaniem.XP charakteryzują: ewolucyjne podejście do projektowania iprogramowania oraz ekstremalnie ścisła współpraca z odbiorcą.Zasadą są ekstremalnie krótkie iteracje w dostarczaniu kolejnychwersji oprogramowania prowadzące do szybkich odpowiedziużytkownika.Przy wytwarzaniu oprogramowania stosuje się programowanie wparach, ustawiczną przebudowę (refactoring) kodu źródłowego,ustawiczną integrację i testowanie połączonych modułów.


Metodologia zwinna

Programowanie ekstremalne

Hasła towarzyszące projektowaniu XP to:I gra w planowanie (planning game),I szybkie iteracje,I porozumienie pomiędzy użytkownikiem i programistami zapomocą metafor,

I prostota kodu (brzytwa Ockhama),I ustawiczne testowanie i integracja modułów,I programowanie w parach,I kolektywne posiadanie kodu,I unikanie nadgodzin,I komunikacja pomiędzy programistami poprzez kod źródłowy,I konstrukcja kodu źródłowego wedle zasad akceptowanych iprzestrzeganych w całym zespole.


Metodologia zwinna

XP

Jedna z zasad XP głosi, że nie ma uniwersalnej metody prowadzeniaprojektu informatycznego. Wobec tego praktyki XP powinny byćprzystosowywane do aktualnych potrzeb i specyfiki projektu. Wcyklu życia projektu XP wyróżnia się fazy:

I eksploracji,I planowania,I iteracji wykonawczych,I przygotowania do produkcji,I utrzymania w ruchu,I zakończenia projektu.


Metodologia zwinna

Projektowanie (i programowanie) ekstremalne


Metodologia zwinna

Faza eksploracji

W fazie eksploracji zespół projektowy zapoznaje się z tematem praci pozyskuje podstawowe informacje od użytkownika. Użytkownikprzedstawia sposób użytkowania systemu poprzez opowiadania(„story), na podstawie których budowany jest zarys architekturysystemu oraz budowana jest lista funkcjonalności. W tym czasieprojektanci testują wybraną technologię tworząc niezbędneprototypy oraz zapoznają się z używanymi narzędziami.


Metodologia zwinna

Faza planowania

Opowiadania przedstawione przez użytkownika są analizowane inadawane są im priorytety. W porozumieniu z użytkownikiemzestawiana jest lista funkcjonalności, które mają być opracowane.Programiści oceniają czas realizacji zadań i ustalany jestharmonogram prac i termin zakończenia prac.


Metodologia zwinna

Faza iteracji wykonawczych

Składa się z jedno lub kilkutygodniowych mini cykliimplementujących kolejne właściwości systemu. Wykonywane sądziałania analityczne, projektowe, kodowanie i testowanie. Na końcukażdego mini cyklu wykonywane są testy oprogramowaniazaplanowane przez użytkownika.


Metodologia zwinna

Faza przygotowania do produkcji

W tej fazie system zawierający uzgodnioną porcję funkcjonalnościjest przygotowywany do wdrożenia. Pojawiające się uwagiużytkownika są implementowane lub przeznaczane do implementacjiw następnej wersji oprogramowania. Wykonywane są dodatkowegruntowne testy.


Metodologia zwinna

Faza konserwacji

Użytkownik jest wyposażony w działającą wersję oprogramowania,która wymaga opieki i nadzoru. Zespół projektowy w tym samymczasie wykonuje kolejną wersję oprogramowania. W trakcie pracy zoprogramowaniem odbiorca formułuje kolejne postulaty dla zespołuprojektowego. Wejście fazę produkcji często pociąga za sobą zmianyw zespołach projektantów i wzrost zatrudnienia. Wysiłekpoświęcany na utrzymanie w ruchu wersji produkcyjnej wpływa nazminiejszenie prędkości opracowywania nowej wersjioprogramowania.


Metodologia zwinna

Zakończenie projektu

Gdy użytkownik nie jest już zainteresowany dodawaniemfunkcjonalności do oprogramowania, tempo współpracy zużytkownikiem spada, formułowane wnioski o rozszerzeniefunkcjonalności mają charakter drugorzędny i często nie sąwdrażane z powodów ekonomicznych. W tej fazie zespół projektowypodejmuje decyzję o zakończeniu projektu, blokuje zmiany warchitekturze systemu i kodzie źródłowym, opracowujedokumentację systemu i projektu, ostateczne wersje instrukcjiużytkownika oraz instrukcje konserwacji.


Metodologia zwinna

Metodyka SCRUM

Istotą metody Scrum jest adaptacyjny, samoorganizujący się proceswytwarzania oprogramowania. Nazwę zapożyczono ze strategii gryw rugby.Scrum jest w istocie techniką zarządzania projekteminformatycznym, utworzoną na podstawie doświadczeń w realnychprojektach. Koncentrując się na zadaniach zarządzania pozostawiawolny wybór w wyborze technik prowadzenia pracprogramistycznych. Zakłada jednakże ewolucyjny styl tworzeniaoprogramowania.


Metodologia zwinna

Metodyka SCRUM

Podstawę adaptacyjności w Scrum stanowi założenie, że rozwójoprogramowania zachodzi w niestałych warunkach, na któreskładają się: nieprzewidywalne zmiany w wymaganiach, terminach,zasobach oraz dostępnych technologiach, wobec czego sam procestworzenia oprogramowania jest złożony i nieprzewidywalny.Scrum zastosowane w praktyce, jak twierdzą twórcy, jest w stanieusprawnić stosowane metody produkcji oprogramowania, boprzewiduje częste działania zarządcze skupiające się naidentyfikowaniu problemów i przeszkód w pracach inżynieryjnych.


Metodologia zwinna

Proces Scrum podzielony jest na trzy główne etapy:I rozpoczęcie gry (pregame),I faza produkcji (development phase),I gra na zakończenie (postgame).


Metodologia zwinna

Faza rozpoczęcia

Faza rozpoczęcia obejmuje czynności planowania i opracowaniazarysu architektury systemu (Architecture high level design). Wtrakcie tej fazy wszystkie znane wymagania są spisywane iopracowywana jest lista wymagań (Product backlog list). Lista tajest otwarta, a zadania do realizacji dopisywane są do niej w trakciecałego procesu tworzenia oprogramowania.Źródłem wymagań są przede wszystkim użytkownicy, ale równieżdział marketingu i sprzedaży, dział obsługi klienta oraz sam zespółprojektantów-programistów. Wymaganiom zestawionym na liścieprzypisywane są priorytety. Na podstawie listy opracowywana jestarchitektura systemu.


Metodologia zwinna

Każdorazowo, gdy do listy dopisywane są nowe wymagania, są onerozpatrywane w ramach specjalnego spotkania (Design ReviewMeeting). Rozpatrywane są również zmiany w architekturze systemuwynikłe z wprowadzenia nowych wymagań.Finalnie, w ramach oddzielnego spotkania, tworzony jest podzbiórlisty wymagań. Zawarte tam wymagania przeznaczone są dorealizacji w ramach aktualnej iteracji (sprint backlog list).Każdy cykl to w istocie podprojekt kaskadowy składający się zopracowania wymagań, analizy, projektowania, kodowania iwdrożenia trwający nie dłużej niż 30 dni.


Metodologia zwinna

Czynności zarządcze w fazie produkcji zasadzają się na spotkaniachorganizacyjnych.

I Rozpoczęcie prac związane jest ze Spotkaniem PlanowaniaCyklu (Sprint planning meeting),

I Zakończenie prac z nieformalnym Spotkaniem Przeglądowym(Scrum Review meeting).

I Są również Codzienne Spotkania Zespołu projektantów iprogramistów (Daily Scrum meeting).


Metodologia zwinna

Spotkanie Planowania Cyklu (Sprint planning meeting)organizowane jest przez zarządcę procesu dwukrotnie. W pierwszymspotkaniu biorą udział użytkownicy, nabywcy, zarząd i zespółprojektantów. Ustala się cele i priorytety właśnie rozpoczynającej sięiteracji. Wymagania wpisuje się we wspomnianą wyżej listę (Sprintproduct backlog). W drugim spotkaniu biorą udział jedyniewykonawcy i Zarządca Scrum, którzy ustalają sposóbprzeprowadzenia prac przy implementacji wymagań.


Metodologia zwinna

Codzienne Spotkania Scrum (Daily Scrum meeting) są krótkie,najwyżej 15 minut, mają na celu motywowanie personelu orazśledzenie postępów prac. W trakcie spotkania omawiane sąproblemy oraz planowane są posunięcia z nich wynikające. Wspotkaniach uczestniczy zespół projektantów i programistów orazzarządca Scrum.


Metodologia zwinna

Spotkanie podsumowujące (Scrum Review Meeting) odbywa się wostatni dzień trwania iteracji produkcyjnej (iteracja nie trwa więcejniż 30 dni). Omawiane są na nim postępy prac oraz formułowane sąwnioski, nowe wpisy do listy wymagań lub postulowane są generalnezmiany w architekturze systemu.


Metodologia zwinna

Faza zakończenia projektu

Faza zakończenia projektu rozpoczyna się wraz z ustaleniempomiędzy użytkownikiem a projektantami, że wymagania sązrealizowane (lista wymagań jest pusta). System jest przygotowanydo instalacji. W tej fazie wykonywana jest ostateczna integracjamodułów i testowanie, a także przygotowuje się dokumentację.


Metodologia zwinna

Scrum wprowadza interesujące narzędzie zarządcze jest nimomawiana już lista wymagań (produkt backlog list). Opisuje onawszystko to, co powinno się znaleźć w ostatecznej wersjioprogramowania (wedle aktualnej wiedzy). W ten sposób listawymagań opisuje wszystko, co należy zrobić w projekcie. Listazwykle zawiera właściwości, funkcje, usterki, defekty, żądaniarozszerzeń i żądania uaktualnień technologicznych.Do zarządzania listą przeznaczony jest pracownik - ZarządcaProjektu. On trzyma pieczę nad dodawaniem nowych pozycji dolisty, jak i usuwaniem pozycji gdy są zrealizowane. W pragmatycerozwoju oprogramowania „open source taka lista nosi nazwę „to dolist.


Metodologia zwinna

Na diagramie przebiegu projektu nie przedstawiono jednegoistotnego procesu biegnącego niezależnie od procesów wytwórczych.Jest nim estymacja pracochłonności. W trakcie całego projekturównolegle z pracami projektowymi i implementacyjnymi trwa procesoceny pracochłonności postulatów zawartych w liście wymagań.W początkowych fazach projektu oceny te są zgrubne, lecz w miaręgromadzenia informacji z postępu prac implementacyjnych stają sięcoraz bardziej dokładne. Proces estymacji pracochłonności polegana gromadzeniu informacji statystycznych o przebiegu projektu iwyznaczaniu kosztu prac na ich podstawie. Estymacjapracochłonności nie bierze pod uwagę dużych zmian w architekturzesystemu lub użytkowanej technologii.


Metodologia zwinna

W przypadku projektu prowadzonego metodą Scrum od początkuzaleca się by użytkownik wraz z zespołem projektantów spędziłkilkanaście dni nad opracowaniem listy wymagań. Muszą się w niejznaleźć zapisy dotyczące zarówno wymagań biznesowych jak itechnologicznych. Celem nadrzędnym pierwszej iteracji produkcyjnejjest pokazanie użytkownikowi jakiegoś fragmentu funkcjonalnościsystemu zaimplementowanego w ramach wybranej technologii.Należy przewidzieć dużą ilość pracy przy pierwszej iteracji, bodochodzą tu prace nad opracowaniem szkieletu systemu, do któregobędą dodawane funkcjonalności w ramach kolejnych iteracji.Pierwsza iteracja produkcyjna różni się od kolejnych również z tegopowodu, że na jej listę wymagań wpisane są takie zadania jak:zapoznanie się z technikami Scrum, organizacje zespołów Scrum,rozdział ról w projekcie. Dalsze iteracje są prostsze i szybsze.


Metodologia zwinna

Nowoczesne metodyki prowadzenia projektu informatycznego różniąsię od tradycyjnych metod generalną ideą. Podczas gry tradycyjnemetody prowadzenia projektu w zamyśle sprzedają produkt -oprogramowanie, nowe techniki zarządzania sprzedają usługęopracowanie oprogramowania.


Metodologia zwinna

Generalne własności:I Wszystkie opisywane techniki zakładają ścisłą współpracę zużytkownikiem czy odbiorcą. Właściwie postuluje się włączenieużytkownika w proces projektowania oprogramowania (eXtremeProgramming).

I Sprzedawana jest usługa tworzenia oprogramowania a niegotowy produkt - oprogramowanie, tak więc użytkownik jesttym, kto podejmuje decyzje co i w jakiej kolejności będzie wprojekcie wykonywane.

I Istotną wagę przywiązuje się do poprawnego szacowaniakosztów prac, tak by inwestor/użytkownik mógł świadomieplanować swe wydatki na rozwój oprogramowania.


Metodologia zwinna

Generalne własności:I Zobowiązuje się wytwórcę oprogramowania do tego, że każdymswym działaniem powinien udowadniać inwestorowi efektywnewykorzystanie czasu i powierzonych mu środków.

I Sprzedając usługę programowania rezygnuje się z zysków zponownego użycia kodu i modeli analitycznych, bo praceodniesione są do niepowtarzalnego projektu. Przy takimzałożeniu rozległa dokumentacja projektowa staje się zbędnymkosztem obciążającym użytkownika i unika się jej.

I Uproszczenia dokumentacyjne wymuszają specyficzny sposóbporozumiewania się z użytkownikiem. W trakcie tworzeniaoprogramowania często (na bieżąco) zadaje się mu pytania iprośby o potwierdzenie dotyczące niewielkiego zakresufunkcjonalności. Stąd wynikają inkrementalny sposóbdostarczania programowania oraz krótkie iteracjeimplementacyjne (XP, Scrum).


Metodologia zwinna

Generalne własności:I Nie specyfikuje się formalnych punktów kontrolnych wprojekcie - nie są one potrzebne, gdyż zakończenie każdejiteracji jest punktem kontrolnym samym w sobie. Z drugiejstrony wprowadzenie sformalizowanych punktów kontrolnychnie we wszystkich technikach jest możliwe.

I Sekwencyjna realizacja wymagań użytkownika powoduje częstezmiany w architekturze systemu i konieczność przebudowykodu. W nowych metodykach zadanie przebudowy kodupostrzega się nie jako wyjątek, lecz jako regułę.


Metodologia zwinna

Koniec wykładu 13.


Metodologia zwinna

Bibliografia

Włodzimierz Dąbrowski, Andrzej Stasiak, Michał Wolski,Modelowanie systemów informatycznych w języku UML 2.1

Wojciech Olejniczak, Zdzisław Szyjewski, Inżynieria systemówinformatycznych w e-gospodarce.

Stanisław Wrycza, Bartosz Marcinkowski, KrzysztofWyrzykowski, Język UML 2.0 w modelowaniu systemówinformatycznych.

Tańska Halina, Analiza sytsemów informatycznych.

Kisielnicki J., Sroka H., Systemy informacyjne biznesu.Informatyka dla zarządzania, Placet, Warszawa 2005

Tadueszewicz R. Projektowanie systemów informacyjnych -http://www.uci.agh.edu.pl/uczelnia/tad/PSI11/.

Documents

Modelowanie i analiza systemów informatycznych