Informační technologie a systémová analýza

Prezentace na téma: "Informační technologie a systémová analýza"— Transkript prezentace:

1 Informační technologie a systémová analýza
BU04 Přednášky 2011, J. Macur, AIU FAST VUT

2 Věcný harmonogram Systém a související pojmy Životní cyklus systému
Předběžná analýza Techniky rozhodování Datová a procesní analýza Používané platformy a techniky pro implementaci Testování a zajišťování kvality

3 Pojem systému Systém představuje integrovanou sadu interoperabilních prvků, z nichž každý má definované a ohraničené možnosti a synergicky slouží k uspokojování operačních potřeb uživatele v určitém provozním prostředí s definovanými výstupy a pravděpodobností úspěchu. integrovaná sada - hierarchické úrovně fyzických prvků, subjektů, nebo komponent interoperabilita – vzájemná kompatibilita ve formě a funkcích (komplementarita – vzájemné doplňování, existují však redundantní systémy) ohraničenost – jasně definovaná funkce a určení v systému synergicky – přidaná hodnota součinnosti (systém není součet částí) systém má vždy svůj účel (tj. důvod existence) a hodnotu pro uživatele hodnota systému – návratnost investic vzhledem k uspokojení provozních potřeb definované výstupy – zainteresované strany očekávají, že systém přinese výsledky, které jsou kvantifikovatelné, měřitelné a ověřitelné pravděpodobnost úspěchu – dosažení určitého výsledku zahrnuje určitý stupeň nejistoty a rizika. Míra úspěšnosti je určena různými faktory (spolehlivost, dostupnost, udržovatelnost ap.)

4 Důležitost definice systému
Vyjasnění pojmu a konsensus v jeho chápání. Úrovně: osobní v rámci vývojového týmu v rámci organizace (management) zákazníci a uživatelé Vlastní definice zavádějí a používají celosvětově důležité organizace, např. International Council on Systems Engineering (INCOSE) Institute of Electrical and Electronic Engineers (IEEE) American National Standards Institute (ANSI)/Electronic Industries Alliance (EIA) International Standards Organization (ISO) US Department of Defense (DoD) US National Aeronautics and Space Administration (NASA) US Federal Aviation Administration (FAA) Často potřebujeme definici přizpůsobit – pozor na bezbřehost nebo přílišnou specifičnost v chápání pojmu

5 Formy systémů Různé formy, struktura a chování systémů.
Např. systémy ekonomické, vzdělávací, finanční, ochrany životního prostředí, zdravotnické, podnikové, pojištění, sociální, psychologické, kulturní, pro rozdělování zdrojů, dopravní, komunikační, zábavné, systémy státní správy apod. Systémový kontext – systém obvykle zahrnuje lidské zdroje, produkty a služby Produkt – entita se specifickými vlastnostmi (forma, účel, funkce). Obecně postrádá schopnost (inteligenci) použití bez lidské asistence (kladivo samo sebe nepoužije pro zatloukání hřebíků). Služba – podporující nástroj, který umožňuje systému nebo uživateli efektivnější dosažení cíle nebo výkonu.

6 Analytický konstrukt systému

7 Základní typy informačních systémů
Informační potřeby jsou různé v různých organizačních úrovních. Podle toho lze rozdělit informace na strategické informace - potřebné pro top management většinou pro rozhodování (například vývoj tržeb pro nastavení politiky organizace) manažerské informace - pro krátkodobá rozhodnutí a plány pro organizaci (analýza prodeje za posledních čtvrtletí nebo detaily roční produkce). U většiny velkých organizací samostatné MIS oddělení. provozní informace - týkají se denních nebo krátkodobých informačních potřeb organizace.  Nutné pro provádění každodenní operativní činnosti. Transaction Processing System nebo systém zpracování dat.  (Např. evidence docházky zaměstnanců, proces vyřizování objednávek, pohyb na účtech atd.) Systémy transakčního zpracování Manažerské informační systémy Systémy pro podporu rozhodování

8 Transakční systémy Transakční procesy organizace. Transakce může být jakákoli činnost organizace, která má ACID vlastnosti (atomicity, consistency, isolation, durability). Typy transakci se liší od organizace k organizaci, nicméně některé transakce jsou společné téměř všem organizacím (správa zaměstnanců, evidence dovolených, docházka). Standardní databázové techniky poskytují vysokou rychlost a přesné zpracování evidence základních provozních procesů. Patří mezi ně kalkulace, uložení a vyhledávání dat. Systémy zpracování transakcí poskytují rychlost a přesnost a jsou naprogramovány tak, aby podporovaly rutinní operační funkce organizace. Uživatelé často považují tento typ systémů za jedinou možnost, protože s ním často pracují a jeho výhody jsou snadno pochopitelné.

9 Manažerské informační systémy
Tyto systémy pomáhají nižšímu managementu v řešení problémů a rozhodování. Využívají zejména výsledky zpracování transakcí a některé další informace. Většinou se jedná o soubor funkcí pro zpracování informací, které zvládnou vyřízení dotazů v reálném čase.  Důležitou součástí je databáze MIS, která je často nahrazována těžkopádným online vytěžováním transakcí. Speciální databáze umožňuje ochranu citlivých dat, která se v případě její neexistence nahrazuje chráněnými pohledy.

10 Systémy pro podporu rozhodování
Tyto systémy pomáhají vyššímu management provádět dlouhodobá nestrukturovaná nebo polostrukturovaná rozhodnutí. Rozhodnutí je považováno za nestrukturované, pokud neexistují jasné postupy pro rozhodování, a pokud faktory, které je třeba zohlednit při rozhodování, nelze v předstihu snadno identifikovat. Tato rozhodnutí obvykle nemají reprodukovatelnou povahu. Některé události se opakují jen zřídka nebo se objeví pouze jednou. Systém pro podporu rozhodování musí být velmi flexibilní. Uživatel by měl být schopen vytvářet vlastní zprávy s využitím dat a ve formátu, které jsou specifické pro konkrétní situaci.

11 Analýza a návrh informačních systémů
Rozvoj každého informačního systému probíhá ve dvou hlavních fázích: analýza a návrh. Během analytické fáze je třeba nalézt představu o celkovém fungování systému, definovat požadavky a cíle, které vedou k návrhu nového systému. Ve fázi analýzy stávajícího systému nebo nově navrhovaného systéme se rozhodujeme, zda je stávající nebo navrhovaný systém vůbec žádoucí či nikoliv nebo zda stávající systém změnit (zlepšit). Jedná se tedy o proces zkoumání systému, identifikace problémů a na základě informací doporučit tvorbu nebo vylepšení systému. Návrh systému je proces plánování nového systému, nebo náhrady, resp. doplnění stávajícího systému. Analýza uvádí, jaký systém by se měl dělat. Návrh popisuje proces dosažení cíle. Po analýze a návrhu nastupuje fáze vlastní realizace (implementace návrhu). Po realizaci máme k dispozici funkční systém, který vyžaduje průběžnou údržbu. 

12 Diagram budování systému

13 Systémový analytik Osoba (nebo osoby), který participují na všech fázích vývoje informačního systému. Analytik musí dohlížet na to, aby byl systém vždy v souladu s určenými cíli a také s cíli organizace. Role systémového analytika se liší od organizace k organizaci. Většinou je však odpovědný za následující procesy podle velikosti organizace a rozsahu systému: Systémová analýza – zahrnuje získání dostatečných údajů o podnikatelské činnosti organizace, její struktury a standardních procesech v organizaci. Jedná se o získávání informací a určení požadavků. Odpovědnost zahrnuje definici požadavků na systém, nikoli návrhu systému. Systémová analýza a návrh – analytik je také zodpovědný za návrh nového systému (aplikace) až do úrovně datové a procesní analýzy. Systémová analýza, návrh a implementace – analytik pracuje i jako programátor, kdy vytváří algoritmy a kód realizující navrhovanou aplikaci. Vzhledem k různým povinnostem, které se vyžadují od systémového analytika, mohou tuto roli vykonávat v různých fázích životního cyklu osoby s různými dovednostmi. Kromě technického know- how pro vývoj informačních systémů by měl systémový analytik mít také tyto znalosti: "Obchodní" znalosti - měl by být obeznámen s obecným fungováním všech druhů procesů v organizaci. Interpersonální dovednosti - v různých fázích vývoje systému musí komunikovat s uživateli a extrahovat od nich požadavky na systém. Schopnost řešení problémů - dovednost rychle nalézat alternativní řešení problémů vyskytujících se v různých fázích vývoje systému.

14 Koncoví uživatelé systému
Používají počítače k výkonu své práce, (desktop operátoři).  Kategorie koncových uživatelů: Zejména uživatelé přímo komunikující se systémem. Jsou to lidé, kteří pořizují vstupní data a získávají výstupní data transakčního charakteru. Např. operátor rezervačního systému – vkládá a ruší rezervace podle požadavků a údajů o obsazení. Pracuje přímo s datovými záznamy. Stále častěji jsou operátory přímo klienti organizace. Nepřímí koncoví uživatelé bez přímé interakce se systémem, avšak těžící z výsledků poskytovaných systémem. Často se jedná o manažery organizace používající tento systém. Existuje třetí typ uživatelů, kteří nesou odpovědnost za využívání systému. Obvykle dohlížejí na investice do rozvoje nebo údržby systému. Čtvrtý typ uživatelů jsou top manažeři, kteří jsou odpovědní za vyhodnocení rizika při selhání systému.

15 Základní prvky informačního systému
Zdroje (HW, SW, LW) Postupy – systém pravidel (např. poskytování úvěrů s úrokovou sazbou závislou na typu účtu) Data – vstup a výstup. Procesy IS vytváří ze vstupních dat potřebný výstup (vlastní účel systému) Přechodná data – dočasné informace pro vytvoření výstupů. Nezbytná v případě složitých procesů. Nelze je podcenit, na jejich přesnosti závisí relevance výstupů. Procesy – vlastní funkční prvek systému. V rámci definovaných postupů dosahují s využitím zdrojů stanoveného cíle.

16 Důležité charakteristiky IS
Cíl – co nejpřesnější, avšak nesmí svazovat. Příklady nevhodného cíle: maximalizace zisku, automatizace agendy ap. Standardy – v rámci systému existuje vždy řada standardů, které by měly být respektovány (komunikační protokoly, používané algoritmy, legislativa ap.) Prostředí – každý systém existuje v nějakém prostředí. Měl by být navržen tak, aby se dokázal dobře přizpůsobit jeho předpokládaným změnám (s flexibilitou však roste režie vývoje, je nutný kompromis) Zpětná vazba – důležitá, avšak často opomíjená součást systému. Umožňuje evoluci k žádoucímu chování. Předpokládá vliv výstupních nebo dočasných dat na vstupní data. Hranice a rozhraní – systém působí v oblasti s definovanou hranicí. Je-li třeba působení za hranicemi, jedná se o rozhraní (interface) pro spolupráci s jiným systémem.

17 Klasifikace systémů Různá kritéria klasifikace
Fyzické vs. abstraktní systémy Otevřené vs. uzavřené systémy Přirozené vs. umělé systémy Formální vs. neformální Počítačově orientované systémy

18 Koncept životního cyklu systému
Zavádí určité standardy do procesu budování nebo vylepšování informačního systému. Vývoj systému by měl začít s kategorizací potřeb uživatelů. Fáze předběžné analýzy - zahrnuje hodnocení současného stavu, shromažďování informací, studie proveditelnosti, schvalování požadavků. Studie proveditelnosti obsahuje část technickou, ekonomickou (Cost-Benefit analýza), legislativní a provozní.  Další fáze zahrnují standardní analýzu, návrh, implementaci, testování atd. Nejpoužívanější modely životního cyklu - Vodopád, Prototypový model, objektově-orientovaný model, spirálový model a metoda vývoje dynamického systému (DSDM).

19 Fáze analýzy požadavků
Analýza požadavků se provádí s cílem pochopit problém, který má systém vyřešit (např. problém automatizace stávajícího manuálního procesu).  Důraz je kladen na určení, co musí systému splňovat, nikoli jak dosáhnout cílů.  Problém nekompatibility klienta a vývojáře. Komunikační propast, která musí být odpovídajícím způsobem překlenuta během analýzy požadavků. Výstupem této fáze je obvykle dokument popisující všechny požadavky. Osoba odpovědná za analýzu požadavků - systémový analytik. Dvě hlavní aktivity v této fázi - vlastní pochopení a specifikace požadavků, analytik musí pochopit problém a jeho kontext.  Dokument se specifikací požadavků musí uvádět všechny funkční a výkonnostní požadavky, formáty vstupů, výstupů a veškeré požadované standardy a všechna omezení, která vystupují v důsledku politického, ekonomického a bezpečnostních prostředí.  Fáze končí auditem dokumentu. Základním účelem tohoto ověření je zajistit, že požadavky uvedené v dokumentu odrážejí skutečné požadavky a potřeby a že jsou specifikovány všechny a úplně. Audit provádí nezávislá skupina, v níž je obvykle zastoupen i budoucí klient.

20 Fáze návrhu De facto plán řešení problému specifikovaného dokumentem požadavků. Výstupem této fáze je návrh dokumentu, který je používán později v průběhu implementace, testování a údržby. Projektová činnost je často rozdělena do dvou samostatných fází - návrh systému a prováděcí projekt. Cíle návrhu systému (top-level design) - identifikovat moduly, které by měly být v systému, specifikace těchto modulů, popis jejich vzájemného působení k dosažení žádoucích výsledků.  Detailní návrh (prováděcí projekt) určí vnitřní logiku jednotlivých modulů uvedených v návrhu systému, hlavní datové struktury a algoritmické konstrukce jednotlivých modulů. Logika modulu je obvykle popsána schematicky (high-level design description language) a je nezávislá na cílovém jazyce, ve kterém bude systém nakonec realizován.  Ve fázi návrhu vzniknou obvykle dva samostatné dokumenty - jeden pro návrh systému a jeden pro detailní návrh. Metodika návrhu je systematický přístup k tvorbě návrhu. Používají se dva základní principy – rozdělení problému na relativně samostatné části a abstrakce. Velký systém nelze řešit jako celek, a tak je pro účely návrhu rozdělen na menší systémy. Abstrakce je pojem vztahující se k problému rozdělení. Projektová činnost se zaměřuje na jednu část systému, která však spolupracuje s ostatními částmi systému. Jasná představa o vzájemném působení je zásadní pro správné navrhování část. Abstrakce systému nebo jeho části definuje celkové chování na abstraktní úrovni, aniž by se zabývala interními detaily. Při návrhu části systému musíme pochopit pouze abstrakci ostatních částí, s nimiž daná část komunikuje. Použití abstrakce umožňuje praxi "rozděl a panuj". Stejně jako každá jiná fáze, i fáze návrhu by měla končit auditem (ověřovacím procesem). Pokud návrh není přímo spustitelný (většinou), musí být provedeno posouzení projektové dokumentace. Obvykle alespoň dva nezávislí auditoři - jeden pro top-level návrh systému a jeden pro detailní návrh.

21 Fáze kódování Oproti návrhu je většinou již přímočará
Náklady jsou obvykle mnohem nižší než testovací fáze a údržba, proto je třeba dbát na maximální transparentnost a jednoduchost. Tomu napomáhají různé techniky – metoda strukturovaného programování, objektově-orientované programování apod.

22 Fáze testování Hlavní kontrola kvality se základní funkcí detekovat chyby v softwaru.  Při analýze a návrhu jsou výstupem dokumenty. Po fázi kódování máme však k dispozici spustitelné programy. To znamená, že testy mohou odhalit nejen chyby při kódování, ale také chyby, které vznikly během předchozích fází. Cílem testování je odhalit chyby analýzy, návrhu i kódování. Proto probíhá testování obvykle v různých úrovních. Nejprve se provádějí testy různých části modulu pro detekci chyb v kódu. Pak jsou postupně integrovány do subsystémů (integrační testy), které jsou pak dále spouštěny tak, že nakonec tvoří celý systém (testování systému). Součástí testů je ověření, zda jsou splněny všechny požadavky analýzy. Pro úspěšné testování je zásadní správný výběr testovacích případů. Dva různé přístupy k výběru testovacích případů - funkční testování a strukturální testování. Při funkčním testování se s moduly zachází jako s černou skříňku. Důraz je kladen na testování vnějšího chování systému. V strukturálním testování jsou testovací příklady vybrány na základě logiky modulů. Strukturální testování se používá pro nižší úrovně testování a funkční testování se používá pro vyšší úrovně. Testování je velmi kritická a časově náročná činnost, je nutné řádné plánování celého procesu testování. Výstupem by měl být dokument, který uvádí všechny testované případy spolu s očekávanými výstupy. Během testování je skutečný výsledek porovnáván s očekávaným výstupem. Testovací zpráva obsahuje popis testovacích případů a výsledek jejich provedení, chybová zpráva popisuje chyby a opatření přijatá k jejich odstranění.

23 Náklady na vývoj a rozdělení chyb ve fázích vývoje
Náklady na vývoj, typické rozložení intenzity v různých fázích je cca Analýza - 10%, návrh - 20%, kódování - 20%, testování - 50% Přesná čísla se budou lišit podle organizace a typu projektu.  Cílem by tedy nemělo být snížení nákladů na kódování, ale snížit náklady na testování a údržbu, na úkor zvýšení nákladů na návrh a kódování. Náklady na testování a údržbu mohou být výrazně sníženy, pokud je software dobře navržen a implementován. Představa, že programování je ústřední činností při vývoji softwaru panuje do značné míry proto, že programování bylo považováno za obtížný úkol, resp. "umění". Dalším důsledkem tohoto druhu myšlení je víra, že chyby z velké části vznikají během programování, neboť je nejstarší činností v oblastech vývoje softwaru a nabízí mnoho příležitostí k vzniku chyb. Chyby se však mohou objevit v jakékoli fázi vývoje. Typické rozložení chyb je Analýza - 20%, návrh - 30%, kódování - 50% Chyby se tesy vyskytují v celém procesu vývoje. Nicméně náklady na opravy jednotlivých fází nejsou stejné a závisí na tom, kdy bude chyba zjištěna a opravena. Lze očekávat, že čím větší zpoždění při odhalování chyb, tím dražší náprava. Chyba, které nastane v průběhu analýzy, je-li opravena až po dokončení kódování, může stát mnohonásobně více, než oprava chyby ve stejné fázi, kde vznikla.  Ve skutečnosti je testování často jediným místem, kde se zjišťují chyby. Pokud kvůli omezení nákladů navíc zredukujeme testování, bude výsledkem nespolehlivý software. Detekce a oprava chyb by měla být kontinuální proces, který probíhá v celém vývoji softwaru. Z hlediska životního cyklu to znamená, že bychom se měli pokusit ověřit každou fázi před zahájením další.

24 Životní cyklus – metoda vodopádu
Jednotlivé fáze na sebe navazují, k další fázi se přistupuje po ukončení předcházející fáze. Výsledkem modelu vodopádu je nejen konečný IS spolu s dokumentací. Existuje celá řada dílčích výstupů, které musí být vytvořeny tak, aby byl výstupní produkt použitelný. Zejména to je Analýza požadavků Plán projektu Návrh systému Realizační dokument Plán testování a protokol o provedených testech Výsledný kód Softwarové manuály (uživatelský manuál, instalační manuál, atd.) Revizní zprávy Kromě posledního to jsou všechny výstupy fází životního cyklu.  Recenzní řízení (review) - nezbytné zejména pro požadavky a přípravné fáze, protože jiné formy auditu obvykle nejsou k dispozici.  Hodnotící zprávy jsou výsledky hodnocení v různých fázích produktu

25 Výhody a nevýhody modelu vodopádu
Snadno se uživatelům vysvětluje Etapy a činnosti jsou dobře definované Jednoznačné vytvoření časového harmonogramu projektu Ověřování v každé fázi zajišťuje včasné zjištění chyb Nevýhody U velkých projektů s dlouhou realizací může být analýza zastaralá již v době návrhu systému. Lineární návaznost jednotlivých fází způsobuje špatnou zpětnou vazbu a zbytečné investice. Chybí možnost zkoušení alternativních řešení

26 Metoda prototypování Již ve fázi analýzy ověřuje některé závěry pomocí tzv. prototypů. Rychlý funkční návrh řešení pomocí neformálního návrhu umožňuje zpřesňování analýzy požadavků i vlastního návrhu. Nepoužívá se u malých systémů z důvodů vyšších nákladů (dvojí vývoj). Na druhé straně zlevňuje návrhovou a testovací fázi.

27 Výhody a nevýhody prototypování
Uživatelé jsou aktivně zapojeni do vývoje (uživatelé kvalifikovaněji formulují své požadavky). Funkční model systému umožňuje uživatelům lépe porozumět systému, který je vyvvíjen. Chyby mohou být detekovány mnohem dříve, protože je k dispozici přímý dohled nad postupným vývojem. Rychlejší zpětná vazba od uživatelů obvykle vede k lepšímu řešení. Nevýhody Množství oprav během implementace Nebezpečí zvýšení komplexnosti systému – prototypy mohou vést k sofistikovanému řešení částí, kde je to zbytečné.

28 Metoda iterací Postupné iterace pro vylepšování hrubého jádra systému.
Metoda by měla přinést výhody vodopádu i prototypů. Vytvoření seznamu požadavků (funkcionality), které musí systém splňovat. Postupné plnění jednotlivých úkolů až do vyčerpání seznamu. Fáze návrhu, realizace a analýzy v každé iteraci. Seznam úkolů je klíčový pro celou metodu. Analýza prováděná v každém kroku dává příležitost k redefinici požadavků resp. návrhu kroku.

29 Metoda spirály (Böhm) Životní cyklus zobrazen v podobě spirály s mnoha cykly. Radiální souřadnice – celkové náklady Úhlová souřadnice – pokrok dosažený v rámci cyklu spirály Každý cyklus začíná identifikací cílů tohoto cyklu. Cíle lze dosáhnout různými alternativami. Dalším krokem v rámci cyklu spirály je vyhodnotit tyto alternativy se zahrnutím nejistoty a rizika.  Zejména používáme srovnávací analýzy, simulace a prototypování.  Dalším krokem je vývoj systému s ohledem na rizika.  Nový cyklus

30 Metoda spirály – cyklus
Cyklus spirály se skládá ze čtyř kvadrantů Kvadrant 1 – Analýza: stanovení cílů, omezení (constraints), alternativ pro jejich dosažení Kvadrant 2 – Vyhodnocení: alternativ, identifikace rizik a jejich eliminace Kvadrantu 3 – Vývoj a ověření výsledku Kvadrant 4 – Plánování dalšího cyklu (iterace) Spirálový přístup se zaměřuje zejména na analýzu rizik a minimalizaci projektových rizik rozdělením projektu na menší segmenty a umožněním změn během procesu vývoje. V průběhu vývoje je také možné vyhodnocovat rizika a zvažovat další pokračování projektu v průběhu životního cyklu. Každý cyklus spirály spouští stejný sled kroků pro každou část produktu a pro každou úroveň elaborace (od konceptuálních dokumentů až po programování jednotlivých programů). V počátku každého cyklu se identifikují zainteresované subjekty a jejich podmínky kladené na úspěch iterace, na konci každého cyklu se provádí revize a předání.

31 Metoda RAD Rapid Application Development (RAD) je takový přístup k vývoji software, který zahrnuje iterativní vývoj prototypů. RAD byl původně použit k označení procesu vývoje software, který zavedl James Martin v roce 1991. Rychlý vývoj a zavedení systémů při relativně nízkých investičních nákladech. Snaha snížit nebezpečí projektových rizik rozdělením projektu na menší segmenty a umožněním změn během procesu vývoje. Soustředí se na rychlý vývoj vysoce kvalitních systémů především pomocí iterativního protypování ve všech stádiích vývoje, aktivním zapojením uživatele a automatizovaných vývojových nástrojů. Klíčový důraz je kladen na naplňování business potřeb, přičemž na technologickou nebo technickou dokonalost je kladen menší důraz. Řízení projektu zahrnuje stanovení priorit vývoje a stanovení dodacích lhůt nebo časových rámců. Pokud se projekt zpožďuje, postupuje se spíše snižováním požadavků, než posouváním termínu, aby byl termín naplněn. Obecně zahrnuje techniku JAD (Joint Application Development, Joint Application Design), který intenzivně zapojuje uživatele do procesu návrhu systému a to buď prostřednictvím shody na strukturovaných seminářích, nebo pomocí elektronicky vedené interakce. Aktivní zapojení uživatelů je nutností. Na rozdíl od jednorázových prototypů vzniká produkční software iterativně. Je vytvářena dokumentace potřebná pro snazší budoucí vývoj či údržbu. V rámci těchto postupů je možné použít standardní systémovou analýzu a design.

32 Další metody Objektově orientovaný design (OOD), také známý jako objektově orientovaná analýza a design (OOAD), který zavedl Grady Booch. Tento model zahrnuje šest typů diagramů: diagram tříd (class), objektový diagram (object), stavový diagram (state transition), diagram interakcí (interaction), modulový diagram (module) a procesní diagram (process). Programování metodou shora-dolů (dekompozice) – poprvé formulován výzkumníky IBM (Harlan Mills a Niklaus Wirth). Unified Process (UP) je framework pro iterativní vývoj software založení na UML (Unified Modeling Language). Vývoj se organizuje do čtyř etap (Inception, Elaboration, Construction, and Guidelines), z nichž každá se skládá z jedné nebo více iterací. Jednou z nejznámějších aplikací UP je RUP (Rational Unified Process). Agile Software Development zahrnuje skupinu metodik pro vývoj software založených na iterativním vývoji, kde se požadavky i řešení vyvíjí prostřednictvím spolupráce mezi jednotlivými týmy. Termín byl v roce formulován manifestem. Integrated Software Development je metodický framework pro vývoj software zaměřený na dodávku výsledného produktu, který používá tři primární složky životního cyklu (projektový management, vývoj software a testování software). Tyto lze využít pomocí rozličných přístupů k vývoji software (iterativní, vodopádový, spirála, ...). Požadavky i řešení se vyvíjí prostřednictvím spolupráce mezi jednotlivými týmy.

33 Stavový diagram Zachycuje stavy systému a přechody mezi nimi na základě událostí Identifikace stavů není triviální záležitost Diagram zároveň ukazuje časovou kauzální návaznost dějů v systému Pro celkový systém se obvykle nepořizuje, pouze v částech, které mají charakter "konečného automatu", a kde umožňuje lepší orientaci. Je zcela nezbytný u průmyslových systémů (automatizovaných linek ap.)-

34 Příklad stavového diagramu bankomatu

35 Funkční požadavky a diagram datového toku
Po analýze proces návrhu pomocí různých modelovacích technik Koncepční návrh se skládá ze dvou prvků: datový model a funkční modely. Datové modelování je technika pro organizaci a dokumentaci dat.  Procesní model je technika pro organizaci a dokumentování systému (procesy, vstupy, výstupy, vazba na data) . Obecně platí, že tyto modely obsahovat tyto informace. Jaké procesy tvoří systém? Jaká data jsou používány v jednotlivých procesech? Která se ukládají? Která data tvoří vstupy a výstupy systému? Proces lze chápat také jako transformaci vstupu na výstupní data. Diagram datového toku je nástroj, který ukazuje pohyb dat v rámci procesu. nebo celého systému.

36 Konstrukční komponenty
Moduly – subsystémy. Relativně nezávislé a malé části zlepšují přehlednost a organizaci systému. Hierarchická koncepce je vítaná (společné části organizované do modulů – cesta k odstranění funkčních duplicit) Procesy – reprezentují funkcionalitu systému. Proces je vykonáván opakovaně, má definovatelný počátek a konec a identifikovatelné vstupy a výstupy.  Např. vytvoření objednávky, vyřízení objednávky, vystavení faktury ap. Identifikace a parametry procesů jsou součástí funkčního modelování. V této fázi definujeme CO se děje nikoli JAK. Vstupy a výstupy – obvykle ve formulářové podobě. V mnoha případech je výstup důvodem tvorby systému. Měl by přinášet proti vstupům "přidanou hodnotu". Vstupy zahrnují validaci a kontrolu chyb. Navrhování databází a souborů – určeno v datové analýze. Častým problémem je ukládání binárních dat (soubor vs. databáze). Rozhraní – návrh zahrnuje zejména komfortní uživatelské rozhraní. Pro externí systémy je však důležitý i návrh datového rozhraní, dnes majoritně založeném na XML. Součástí rozhraní je rovněž konzistentní systém nabídek, logická navigace, poskytování pouze relevantních informací pro daný kontext. Vysvětlující chybové zprávy, možnost zpětné akce, nápověda.

37 Diagram datového toku Externí entita Zákazníci Potvrzení platby
Čtyři základní symboly Externí entita reprezentuje zdroj dat nebo výstup dat ze systému. Určuje hranice systému, často vnější systém. Symbol datového toku reprezentuje pohyb údajů. Znázorňuje obvykle tok dat mezi procesy. Datové toky bychom měli pojmenovat (objednávky, platby, reklamace). Úložiště dat (datový sklad) – symbol reprezentuje dočasná nebo trvalá data, která tvoří "inventář" systému. Na rozdíl od datových toků jsou "nepohyblivá" (nepřesunují se). Vazbu na datové sklady mají pouze procesy. Procesy jsou činnosti transformující příchozí datové toky na odchozí datové toky. Proto musí mít všechny procesy vstupy a výstupy. Proces je vždy připraven přijímat data.Hlavní funkcí procesů jsou výpočty a rozhodování. Procesy jsou pojmenovány obvykle jedním pečlivě vybraným slovesem a předmětem. (žádný podmět). Každý proces by měl představovat jednu funkci nebo činnost. Jestliže je v názvu "a", lze pravděpodobně proces rozdělit.  Externí entita objednávka Zákazníci Potvrzení platby

38 Příklad diagramu datového toku

39 Diagram datového toku Není diagramem řízení (flowchart) - není procedurálně orientován. Hovoří o toku dat nikoli o způsobu organizace nebo řízení. Neobsahuje cykly ani rozhodování. Při tvorbě je vhodné začít od hrubých datových toků a postupně rozvíjet diagram do detailnějších variant. Je třeba se vyhnout procedurálním otázkám (jak se to udělá), soustředit se na identifikaci (co se dělá), důsledně pojmenovávat všechny komponenty.

40 Datový slovník Pojmenované komponenty v diagramu datového toku je třeba podrobněji popsat a vysvětlit. K tomu slouží "datový slovník". Představuje popisná data o datech – metadata. Pro metadata se často používá formalizmus regulárních výrazů ap. Příklad prenosDat = {okamžitě | denně | týdně} platba = {kartou | v hotovosti}+ {Kč | $} Pečlivost a dodržování stanovených konvencí při tvorbě diagramu a přidruženého slovníku se vyplácí a svědčí o kultuře a kvalifikaci vývojového týmu.

41 Komplementarita datového a procesního modelu