Analýza a modelování softwarových systémů PDF

Analýza a modelování softwarových systémů Úvodní informace, úvod do předmětu doc. Ing. Radek Šilhavý, Ph.D. doc. Ing. Radek Šilhavý, Ph.D....

Analýza a modelování softwarových systémů Úvodní informace, úvod do předmětu doc. Ing. Radek Šilhavý, Ph.D. doc. Ing. Radek Šilhavý, Ph.D. 1  Čím se budeme zabývat o Softwarová analýza - Analogie stavby domu. o Paralely mezi fázemi výstavby a vývoje software. Potřeba a cíle o Jak identifikujeme potřebu nového domu? Růst rodiny, potřeba změny, nová práce. o Analogie v softwaru: Nový trh, nové technologie, potřeba automatizace. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 2  Čím se budeme zabývat, II Plánování je klíčové Proces výběru architekta, konzultace, revize návrhů a konečné schválení plánu. V softwaru: Výběr týmu, definování požadavků, návrh řešení a revize. Postavení základů Význam pevných základů pro stabilitu domu. Příprava terénu, základové desky. V softwaru: Výběr správných technologií, databází a nástrojů pro projekt. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 3  Čím se budeme zabývat, III Fáze Výstavby o Postupné budování domu, od zdí po střechu. Koordinace různých řemeslníků. o V softwaru: Kódování různých částí aplikace, integrace a testování. Dokončení a Ladění o Estetické a funkční dokončení domu. Malování, instalace zařízení. o V softwaru: Ladění, testování, uživatelské testy a zpětná vazba. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 4  Čím se budeme zabývat, IV Předání Klíčů o Proces předání domu novým majitelům. Kontrolní seznamy, dokumentace. o V softwaru: Nasazení aplikace, školení uživatelů, dokumentace. Život po Předání /Údržba a Aktualizace o Jak se postarat o dům po jeho dokončení? Pravidelná údržba, opravy. o V softwaru: Aktualizace, opravy chyb, rozšíření funkcí, podpora. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 5 doc. Ing. Radek Šilhavý, Ph.D. 6  Organizace přednášky o Vyučovací hodina má 50 minut výuky + 10 minut přestávka. Typicky má přednáška 2 h a cvičení také 2 h. o Přednášky budou zaměřeny praktické a budeme se zabývat více modelování než teorií (postupně několik ukázkových projektů). doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 7  Organizace cvičení o Ing. Darina Bajusová o 1. až 8. týden – práce na modelování softwaru pomocí UML (nejen). o 9. týden (od. 7. listopadu) – práce na týmovém semestrálním projektu na zvolené téma. o Odevzdání projektu do konce 13. týdne v semestru. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 8  Stránka předmětu o moodle.utb.cz o Najít AP1AM o Klíč k zápisu – dle cvičení doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 9  Dostupné materiály o moodle.utb.cz o Možnost využívat Sparx Enterprise Architect i doma. o Instalace a instrukce na moodlu doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 10  Hodnocení o Zkouška – písemný test – moodle. o Zápočet – semestrální práce – projekt v malém týmu. Najděte si ideálně kolegy z kruhu. o Informace o zápočtu na moodlu. o Témata projektů ve stag.utb.cz – sekce semestrální práce. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 11  Co budeme dělat o Co je to vývoj software? o Co je to analýza? o Jak vzniká software? o Platí to i pro Facebook, Instagram, eshopy – třeba alza.cz? o Softwarové inženýrství ? – další snímek. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 12  Význam Softwarového inženýrství o Moderní ekonomika je závislá na softwaru (Sommerville, 2015). o Softwarové inženýrství metodikami, metodickými postupy, pravidly a návaznostmi vývoje software o Poskytuje postupy pro celý proces vývoje software. o Zavádí systematický přístup k vývoji. o Náklady na software jsou často vyšší než na hardware, na kterém běží. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 13  Co je to inženýrství? o Návrh řešení praktického problému v potřebné kvalitě a s přijatelnými náklady a při aplikaci aktuálního stavu znalostí (ne autora, ale v oboru). o Věda by měla spíše hledat řešení experimenty. o Inženýr tím, že postaví zařízení nebo prototyp. A i software je svého druhu zařízení. o I když: software je abstraktní, nemá fyzikální vlastnosti omezující chovní ani složitost. o I když: software se neopotřebovává a jeho spolehlivost se tak v čase nemění. o I když: všechny kopie jsou zcela identické. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 14  Mýty o Software je méně nákladný než vývoj fyzických zařízení – hardware. o Software je jednoduché nahradit, vyměnit nebo aktualizovat. o Počítač je spolehlivější než klasické stroje a zařízení. o Software je možné formálně (matematicky) ověřit na správnost. (je, ale ne 100 %). o Opakované využívání (software reuse) hotových částí zvýší spolehlivost a bezpečnost. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 15  Základní otázky o Co je to software o Ne jen zdrojový kód, ale taky vývojová dokumentace, příručky. o Atributy dobrého software o Funkcionalita, výkonnost, udržovatelnost, spolehlivost, použitelnost. o Systémové inženýrství a Softwarové inženýrství (Sommerville, 2015) o SWI je disciplína, která je součástí SI. o SI se zabývá vývojem počítačových systémů - tj. návrh, vývoj hardware i software, stavební práce, procesní otázky. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 16  Základní otázky o Jakou jsou nejlepší techniky a postupy? o Nelze stanovit. Záleží na řešené otázce. o Příklady: o Při vývoj her je vhodné používat prototypování. o Pro bezpečnostně kritický systém je potřeba pečlivá analýza a formální specifikace. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 17  Definice o Definice IEEE: Jedná se o aplikaci systematického, disciplinovaného, měřitelného přístupu k vývoji, tvorbě a údržbě softwaru. (Sommerville, 2015) o Definice NATO: Disciplína, která se zabývá zavedením a používáním řádných inženýrských principů do tvorby software, kde cílem je ekonomická tvorba a spolehlivý software na dostupném HW. Definice dle NATO 1968: Disciplína, která se zabývá zavedením a používáním řádných inženýrských principů do tvorby software, kde cílem je ekonomická tvorba a spolehlivý software na dostupném HW. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 18  Historie disciplíny o V 60. letech se množili projekty, které nebyly řešeny včas = Softwarová krize. o Obvykle se uvádí 1968, první konference s názvem „Software engineering“. Organizuje ji NATO.(Naur, 1969) o Rostly chybné projekty, docházelo k haváriím. o Částečně z důvodů růstu využití počítačů. o Krize souvisí se stoupající složitostí, Malé využití počítačů – malé projekty. o Velké projekty, velké problémy, Růst Rozpočtu, nedodržení času, požadavků, funkčnosti. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 19  Co je to softwarový produkt o Generický produkt o Vyvíjený z popudu vývojářské firmy, krabicový produkt. o Kancelářské aplikace, grafické programy, účetnictví. o Existuje prototypový uživatel – tedy obecně definovaná představa, kdo bude uživatel. o Změny zadává marketing nebo samotné vývojové oddělení. o Lze se setkat s pojmem Commercial off-the-shelf (COTS). o Konfigurace je potřebná / možná. o Zákazový vývoj o Vyvíjený na základě požadavků zákazníka. o Bankovní aplikace, elektronické obchody. o Změny a požadavky řídí zadavatel. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 20  Co je to softwarový proces o Množina činností, jejichž cílem je vývoj nebo modernizace software. o Základní činnosti – společné pro všechny procesy. o Jen stručně obecně na úvod: o Koncepce - úvodní studie. o Analýza - Požadavky a Návrh. o Implementace - Kódování. o Testování. o Používání a údržba. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 21  Modely softwarového procesu o Někdy také modely softwarového procesu. o Jedná se o posloupnost činností, které musí být vykonány, aby vznikl software. o Ideální model obsahuje analýzu, návrh, sestavení, testování, používání a to v sekvenčním uspořádání. o Realitou je však vždy více či méně iterativní uspořádání. o Přinejmenším v každé z uvedených etap. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 22  Vodopádový model o Je zde tedy dlouhá prodleva mezi zadáním a spustitelným systém. o Důraz na dokumentaci. Což je přínosem pro přemýšlení o problému a návrh řešení. o Další etapa začne, až předchozí skončí. o Existuje celá řada modifikací - > opakování více menších vodopádů za sebou. Což je základ pro přírůstkové modely. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 23  Vodopádový model, II o Winston W. Royce prezentuje práci “Managing the development of Large Software Systems. 1987.(Royce, 1987) o Problémy: o Je prakticky nemožné fáze oddělit pevně. o Je obtížné odhalit chyby. o Výhodný je tam: o Kde je potřeba mít formální analýzu. o V systémovém inženýrství, dělba na subsystémy. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 24  Vodopádový model, schéma doc. Ing. Radek Šilhavý, Ph.D. 25  Přírůstkový, inkrementální přístup o Založeno na verzování. o Projekt je rozdělen na dílčí části - verze/sestavení. o Do novějších sestavení vždy dodána nová funkčnost. o Finální sestavení obsahuje celý systém. o Lze říci, že se jedná o sekvenci několika za sebou jdoucích „vodopádů“. o Toto dělení umožňuje sledování postupu vývoje a také reakce na změnu zadání. (Sommerville, 2015) doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 26  Spirálový model o Každý přírůstek je popsána otočkou spirály. o V prvním kole realizujeme základní koncept a plán jak budeme postupovat. o Sestavení požadavků první úrovně, tedy ty rámcové. o Postupně se přidávají další kola, dokud existují nevyřešená rizika nebo požadavky. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 27  Spirálový model, schéma Analýza Plánování Hodnocení Vývoj doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 28  Metoda Tunel o Mezi pracovníky se rozdělí projekt dle částí. (Eshop: Evidence zákazníků, Evidence Objednávek, Správa zboží apod.). o Každý pak provádí všechny činnosti. Sám provede analýzu, návrh a ve finále píše kód a testuje. o Není zde dělení dle rolí - analytik, návrhář, programátor. o TOMUTU PRINCIPU je potřeba se VYHNOUT. (KRAVAL) doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 29  Poznámka o Čím dříve je chyba nalezena, tím je její náprava levnější. o Chyby jsou obvykle distribuovány takto (Sommerville, 2015): o 50 % Požadavky o 30 % Návrh o 10 % Programování o 10 % Ostatní etapy o Proto lze doporučit využívání spíše přírůstkových modelů. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 30  Dotazy? doc. Ing. Radek Šilhavý, Ph.D. 31  Analýza a modelování Význam Business procesů Business Process Model Notation (BPMN) doc. Ing. Radek Šilhavý, Ph.D. 32  Vývojový diagram o Víte co je vývojový diagram? doc. Ing. Radek Šilhavý, Ph.D. 33  Co je business process? Definice: Obchodní proces je soubor souvisejících, strukturovaných aktivit nebo úkolů, které vedou k dosažení konkrétního cíle nebo výsledku pro konkrétního zákazníka nebo skupinu zákazníků. Důležitost: Porozumění obchodním procesům je klíčové pro efektivní analýzu softwarových požadavků, protože software často modeluje nebo automatizuje tyto procesy. Příklad: Představte si proces objednávání v e-shopu - od výběru produktu zákazníkem až po jeho doručení. Každý krok v tomto procesu může být modelován a optimalizován pomocí softwaru. doc. Ing. Radek Šilhavý, Ph.D. 34  Co je to proces? o Základní prvek procesního řízení. o Proces je uspořádaná množina aktivit, které přinášení hodnotu (plní cíl podniku). o Proces má vstupní a výstupní atributy a definuje se i vlastník procesu. o Je to tedy popis nějaké činnosti v organizaci. o Procesem je tedy popis jak si něco koupit, jak se zapsat na zkoušku, jak probíhá úhrada faktur apod. doc. Ing. Radek Šilhavý, Ph.D. 35  Typy procesů o Hlavní procesy – výstup přímo využíván uživatelem. o Řídící procesy – činnosti nutné pro chod podniku – činnost manažerů) o Podpůrné procesy – např. marketing, podporují hlavní činnost. o Vedlejší procesy – pomocní činnosti v podniku – účtárna, mzdová apod. doc. Ing. Radek Šilhavý, Ph.D. 36  Cíle procesu o Musí být jasné jako cíle organizace má, a jak k nim proces přispívá a směřuje. o Je potřeba to měřit, tedy sledovat. o Existují metriky – indikátory (např. počet zákazníků, množství chyb, počet vrácených výrobků, počet získaných objednávek apod.). doc. Ing. Radek Šilhavý, Ph.D. 37  Procesní řízení o Jedná se o sledování podnikových procesů, cílem je jejich zlepšení. o Slouží pro sladění informačních technologií a řízení organizace. o Představuje techniky, metody, postupy i nástroje aby bylo možné procesy analyzovat, kontrolovat. doc. Ing. Radek Šilhavý, Ph.D. 38  Procesní řízení, II o Návrh procesu – sběr a analýza dosavadních procesů (např. zachycení v BPMN). o Modelování procesů – modelování průběhu procesů s různými vstupní i výstupními atributy. o Implementace procesů – využívání navrženého procesu v praxi. o Monitorování procesu – sledování a sběr dat pro reportování – snaha o měřitelné parametry. doc. Ing. Radek Šilhavý, Ph.D. 39  Procesní řízení, III o Optimalizace procesů – využívání vytvořených reportů pro zlepšení činnosti organizace (zrychlení, vyšší produktivita, apod.) doc. Ing. Radek Šilhavý, Ph.D. 40  Business procesy a modelování o Popisují fungování firmy a postup jak řeší úkoly. Představuje zachycení reality instituce. o Celkový pohled na strukturu a činnosti organizace. o Lze využít pro optimalizaci činnosti – zlepšení nebo odstranění špatných postupů. o Využívá se aktivitních diagramů UML nebo častěji notace Business Process Model Notation (BPMN). o Důležité je určit si úroveň práce – Interní procesy, externí procesy, vazby. o Dále zda se bude stav současný (as-is) nebo budoucí. o Pro analýzu je vhodné znát budoucí stav procesu - obsahuje činnosti IS. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 41  Význam modelování procesů o Určení činnosti a odpovědnost zaměstnanců nebo oddělení. o Zlepšení způsobu práce. o Význam pro nově příchozí – poznání, jak organizace funguje. o Význam pro analýzu požadavků – analytik ví jak organizace funguje. doc. Ing. Radek Šilhavý, Ph.D. 42  Business Process Model Notation o Lze srovnat s vývojovými diagramy nebo aktivitním modelem v UML. o Slouží pro zachycení toku aktivity a zpráv mezi nimi. o Lze využít pro servisně orientovanou architekturu. o Nelze: o Provést rozdělení na funkce v BPMN. o Není to o řídicí struktuře v podniku. o Není to o datovém modelování. doc. Ing. Radek Šilhavý, Ph.D. 43  Základní prvky diagramu BPMN doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 44  Diagram vyšší úrovně o Využívají se subprocesy doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 45 Diagram atomický aktivit doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 46 Přechod z procesu do procesu doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 47  BPMN - Prvky o Flow Objects (Tokové objekty) - Objekty, které souvisí s tokem informací v procesu. o Event (Událost) - značí se kroužkem, přímo ovlivňují tok procesu, události, jimiž proces začne, skončí, či které nastanou v jeho průběhu o Activity (Aktivita) - obdélník s kulatými rohy, znázorňuje činnost či práci, může být buďto atomická (tzv. Task) nebo v sobě může obsahovat samostatný proces, pak se tato aktivita nazývá subprocesem (Model, 2011) doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 48  BPMN - Prvky o Gateway (Brána) - značí se čtvercem či kosočtvercem, stojícím na špici, označuje rozbíhání či souběh toků procesu, např. rozhodování či paralelní zpracování o Connecting Objects (Spojovací objekty) - Objekty, které slouží k spojení tokových objektů navzájem či s artefakty. o Sequence Flow (Sekvenční tok) - nepřerušovaná čára s vyplněnou šipkou, určuje sekvenci (pořadí) aktivit. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 49  BPMN - Prvky o Message Flow (Tok zpráv) - přerušovaná čára s prázdnou šipkou, znázorňuje tok zpráv mezi dvěma účastníky procesu. o Association (Asociace)- přerušovaná čára, umožňuje spojit objekt s nějakou dodatečnou informací. o Artifacts (Artefakty) - značí nějaké upřesňující informace pro proces, nemají vliv na jeho tok. o Data Object (Datový objekt) - značí se obdélníkem s přehnutým rohem (list papíru), reprezentuje data, se kterými pracují aktivity. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 50  BPMN - Prvky o Group (Seskupení) - obdélník kreslený přerušovanou čárou, seskupení aktivit z analytických či dokumentačních důvodů. o Annotation (Poznámka) - text, jenž je spojen asociací s jiným grafickým objektem,poskytuje dodatečnou textovou informace. o Swimlanes (Plavecké dráhy)- Slouží k zobrazení účastníků procesu či uspořádání činnosti v procesu např. podle rolí. (Model, 2011) doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 51  BPMN - Prvky o Pool- ohraničuje proces, v jeho záhlaví je název poolu, reprezentuje účastníka procesu, v rámci jednoho poolu se nachází právě jeden samostatný proces, komunikace mezi pooly probíhá pomocí zpráv (message flow) o Lane (Dráha), část poolu, slouží k uspořádání a kategorizaci aktivit, může značit např. role, oddělení či funkce organizace, komunikace mezi dráhami probíhá pomocí sekvenčního toku (sequence flow). doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 52 Ukázka Pizza doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 53  Dotazy? doc. Ing. Radek Šilhavý, Ph.D. 54  Vývojové metodiky Unified Process SCRUM (Skrumáž) Extrémní programování doc. Ing. Radek Šilhavý, Ph.D. 55  Co jsou to vývojové metodiky o Metodiky představují doporučené postupy pro vývoj softwaru (Sommerville, 2015). o Metodiky určují způsob práce, průběh vývoje a používané nástroje (někdy). o Metodiky jsou založeny na modelu softwarového procesu. o Metodiky lze označovat jako rigorózní nebo jako agilní - dle základního přístup k vývoji. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 56  Unified Process o Jeden ze zástupců klasických rigorózních metodik. Existuje jako volný průmyslový standard. (Arlow & Neustadt, 2005) o Inkrementační metodika – založená na iteracích. o Založená na případech užití a požadavcích. o Generický postup, který lze volně přizpůsobovat potřebám. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 57  Typická složení iterace UP Sběr Implementace Analýza Návrh řešení Testování požadavků Kódování doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 58  Fáze metodiky Unified Process I. Fáze o Kolik bude iterací v každé fázi? Počátek Inception To záleží na celkovém rozsahu vytvářeného softwaru. II. Fáze o Každá fáze má definovány Rozpracování Elaboration milníky, které je potřeba dosáhnout. III. Fáze o Fáze se provádí vždy iterativně – Konstrukce Construction nejedná se o vodopád. IV. Fáze doc. Ing. Radek Šilhavý, Ph.D. Přechod/Nasazení fhs.utb.cz Transition 59  Rozložení základních činností ve fázích (Arlow & Neustadt, 2005) doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 60  Rozložení základních činností ve fázích o Základní činnosti mají různou míru důležitosti a priority v fázích. o Každá fáze má určitou základní činnost, která je dominantní. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 61  I. Fáze - Počátek o Cíle fáze: o Studie proveditelnosti. Rozhodnou o realizovatelnosti systému. Navrhnout klíčové požadavky. Identifikovat rizika. o Milníky: o Rozsah systému je navržen. Jsou zachyceny a odsouhlaseny klíčové požadavky. o Je vytvořen nástin architektury. Jsou vyhodnocena rizika. o Studie proveditelnosti je odsouhlasena. Zákazník souhlasí s parametry projektu. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 62  I. Fáze – Počátek (Graficky) doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 63  II. Fáze - Rozpracování o Cíle fáze: o Vytvoření spustitelného výchozího zpracování architektury. o Definování hodnocení rizik a kritérii kvality (míra chybovosti apod.). o Vypracování případu užití - min. 80% pokrytí požadavků. o Vypracování plánu vývoje pro fází konstrukce/implementace. o Vypracování nabídky - rozbor času, vybavení, lidí a nákladů. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 64  II. Fáze – Rozpracování (b) o Milníky: o Aktualizace vyhodnocení rizik. o Vypracovaný realistický plán, který umožní nabídku. o Realizační cíl, obchodní cíl byl ověřen proti plánu. o Stakeholder souhlasí s pokračováním. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 65  II. Fáze – Rozpracování (Graficky) doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 66  III. Fáze – Konstrukce o Cíle fáze: o Dokončení případu užití, vč. realizací. o Dokončení analýzy, návrhu, implementace a testování. o Ověření, udržování integrity architektury. o Vyhodnocení rizik. o Milníky fáze: o Produkt je připraven k beta testování u zákazníka. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 67  III. Fáze – Konstrukce (Graficky) doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 68  IV. Fáze – Přechod o Cíle fáze: o Oprava chyb. o Příprava prostředí zákazníka k nasazení, případné úpravy systému pro nasazení v prostředí zákazníka. o Úpravy dle nalezených chyb (např. z akceptačních testů). o Tvorba uživatelské příručky a další dokumentace. o Podpora uživatelů u zákazníka. o Vypracování zprávy o projektu. Poznatky, zkušenosti, problémy. o Milníky fáze: o Provedení testů, akceptačního testování a oprava chyb je dokončena. o Nasazení software k zákazníkovi. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 69  IV. Fáze – Přechod (Graficky) doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 70  SCRUM a Extrémní programování o Zástupci agilních vývojových metod. o Vývoj agilních metod je motivován snahou o rychlý vývoj a snížení nákladů: o Zaměřuje se na kódování než na návrh. o Jsou založené na přírůstkovém přístupu. o Dodávají funkční software rychle a rychle přizpůsobovat požadavkům. o Agilní metody se nejvíce hodí pro malé až střední aplikace nebo běžný software pro PC. o Významný podíl uživatele na vývoj - resp. na požadavcích, hodnocení. o Základem jsou lidé, ne metodiky. o Cílem je vše maximálně zjednodušit. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 71  Agilní přístup - nevýhody o Je potřeba udržet pozornost uživatelů, kteří se podílejí na vývoji. o Ne všichni vývojáři jsou schopni akceptovat zásady agilních metod. o Určit prioritu požadavků není snadné – zejména pokud je více uživatelů. o Smluvní podmínky – smlouvy jsou obtížnější. Není propracované zadání na začátku. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 72  xP – Extrémní programování o Dříve nejpoužívanější agilní metodika (Dnes ji vytlačuje SCRUM). o Extrémní programování (XP) (Sommerville, 2015): o Nové verze - sestavení se produkují i několikrát denně. o Přírůstky se předávají cca 1x 14 dnů. o Všechny testy se provádí před sestavením a sestavení se předává pouze pokud testy dopadli se správnými výsledky. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 73  xP – Extrémní programování - Graficky Výběr user story Vyhodnocení Rozklad na systému úkoly Vydání Plán sestavení sestavení Vývoj, Integrace, Testování doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 74  Princip xP o Plánování přírůstků - Požadavky zaznamenávají stručně, dále se dělí na úkoly. o Malé sestavení - Sestavení se vydávají často, zohledňuje se důležitost požadavků. o Jednoduchý design - Design se provádí pouze v nezbytné úrovni. o Testování - Využívání velkého množství testů - např. jednotkových. o Refactoring - Spočívá v neustálém zlepšování kódu, kdykoliv je zlepšení možné. Bez změny výstupních vlastností. o Párové programování - 2 vývojáři, jeden vyvíjí, druhý kontroluje. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 75  Princip xP (b) o Sdílení kódu - nejasné dělení mezi vývojáře. o Průběžná integrace - každá hotová součást se ihned integruje, pak se celek opětovně testuje. o Přítomnost zákazníka - Zástupce zákazníka je "na plný úvaze" přítomen u vývoje. Jeho hlavním úkolem je "přinášení" požadavků. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 76  Jak si představit párové programování? o V XP programátoři pracují ve dvojicích. o Vede to k produkci kvalitnějšího kódu, sdílení znalostní apod. o Kód je kontrolován ihned po nasání – vzájemná kontrola ve dvojici. o Což podporuje refactoring kódu, z této zvyšující se kvality profituje celý tým. o Ukazuje se, že produktivita práce je podobná, jako u klasického přístupu – tedy není zde pokles. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 77  Dokumentace požadavků v XP (a jiných agilních metodikách) o V XP, jsou realizovány jako scénář činnosti, zapsané stručně. Zapisují se nejčastěji ve formě karet. o Požadavky se dále dělí do implementačních úkolů. Tyto úkoly se využívají pro odhad pracnosti a nákladů na vývoj. Požadavky tedy musí být podrobné jen tak, aby tyto odhady byly možné. o Zákazník následně vybírá, které požadavky budou zahrnuty v dalším sestavení. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 78  Ukázka User Story a rozpadu na úkoly Stažení a tisk článku Úkol 1: Implementace základního workflow Nejprve dojde k výběru článku, který má být Úkol 2: Implementace katalogu a výběru článků zobrazen. Pak je potřeba říci systému, jak bude přístup k článku placen - zda předplatným, Úkol 3: Implementace platebních metod účtem organizace nebo platební kartou. Platba je možná třemi způsoby. Uživatel vybírá způsob Dále je potřeba vyplnit a podepsat formulář platby. Pokud má předplatné, tak může zadat svůj autorských práv. Poté dojde ke stažení článku. předplatitelský účet, který je ověřen v systému. Případně Následuje výběr tiskárna a je potřeba v systému může zadat číslo institucionální předplatitelské číslo. označit článek jako vytištěný. Pokud je platné, tak je platba zaúčtována na tento účet. Poslední možností je zadání čísla karty (16 míst) a doby Pokud se jedná o článek s právem tisku, ale ne platnosti karty. Oba údaje jsou ověřeny a v případě ukládaní je příslušný soubor vymazán z kladného výsledku je platba zaúčtována na zadanou kartu. počítače. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 79  xP a testování Test 4: Ověření kreditní karty o XP využívá testy řízený vývoj. Ověření, že všechny bajty jsou čísla. Ověření, že měsíc leží mezi 1 a 12 a rok je vyšší nebo roven o Testy vycházejí ze scénářů. aktuálnímu roku. Pomocí prvních 4 číslic, ověření vydavatele karty v tabulce o Uživatelé se podílejí na návrhu vydavatelů karet. testů i ověření výsledků. Ověření platnosti karty u vydavatele – zasláním čísla karty a platnosti. o Automatické testování je využíváno vždy před vydáním sestavení. Výstup Karta je v pořádku. Ověření karty selhalo. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 80  Jak je to s testy v xP o Testy se píší před zahájením vývoje, ověří se, že všechny neprojdou. o Testy jsou ve formě programů. Mohou být tedy spouštěny automaticky. o Všechny testy (nové i původní) jsou spouštěny, když je přidána nová funkcionalita. o Využíváním nových i původních testů, umožní poznat, zda nová funkcionalita ovlivňuje již hotové části. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 81  SCRUM o Moderní agilní metodika (Beck et al., 2001; Schwaber, 2004). o Velmi populární v současné době. o Využívá se Interativní/Přírustkový vývoj. o Patří mezi agilní metodiky. o Co znamená SCRUM? – Skrumáž – termín z ragby. o Není to tedy zkratka. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 82  Základní princip SCRUMu o Charakteristika SCRUMu se skládá z činností: o Produktový backlog. o Sprint backlog. o Sprint (2,3 týdny, 24 hodin). o Vývoj spustitelné části SW. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 83  Pojmy ve SCRUMu o Product Owner: o Vytváří backlog, představuje zákazníka, konzultuje požadavky. o Formulace a uspořádání položek. o Odpovědný za porozumění. o Musí mít vliv a autoritu. o Tým o Všichni jsou vývojáři - kdo se účastní realizace – programátoři, designéři UI apod. o Samoorganizující – nikdo týmu neříká to uděláme tak a tak. o Odpovědnost celého týmu (I když jsou zde specialisté). o 4 až 9 členů. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 84  Pojmy ve SCRUMu (b) o ScrumMaster o V podstatě „projektový manažer“, zajišťuje, že vše jde jak má. o Formulace vizí projektu a koordinace. o Měl být schopen „naučit“ tvorbu dobrého backlogu. o Je „moderátorem“. o Odstraňuje překážky, na které tým narazí... doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 85  Význam Backlog-u o Backlog o Přehled co je potřeba udělat. o Vlastnosti, funkce, požadavky, opravy chyb. o Určení priority. o Tvoří jej User Stories. o Určujeme odhad pracnosti (body). o Definice naplnění tj. kdy je hotovo. o Co je to Sprint Backlog. o Totéž jen v rámci jednoho sprintu - iterace. o Mění se během práce – doplňuje, upravuje. doc. Ing. Radek Šilhavý, Ph.D. fhs.utb.cz 86  Přírůstek ve SCRUM-u o Množina dokončení položek produktového backlogu. o Po ukončení sprintu je „hotovo“. o Co znamená Hotovo? o Položka produktového backlogu (story) je v určitém stavu – funkci. o Přírůstek je nasaditelný (což nemusí vždy znamenat spustitelný kód) o Je to cílový stav přírůstku. o Plánování přírůstku a jeho smysl. o Odhaduje náročnost story o Vychází z Fibonacciho posoupnosti (F(n+1=F(n)+(F(n-1)). o Obecně jde o relativní přiřazení náročnosti (např. 5 náročnější jak 3). doc. Ing. Radek Šilhavý, Ph.D. 87  Co je to SPRINT? o Základní iterace – trvající 2 až 3 týdny (max měsíc) o Fáze každého sprintu: o Plánování – Sprint Planning Meeting. o Denní plán (Daily Scrum). o Samotný vývoj. o Vyhodnocení (Sprint Review). o Retrospektiva (Sprint Retrospective). o Nemění se cíl sprintu během sprintu. o Nemění se složen týmu. o Sprint lze chápat jako projekt. doc. Ing. Radek Šilhavý, Ph.D. 88  Fáze Plánování o Odhaduje náročnost story. o Určuje co se má provést v rámci sprintu. o Otázky: o Jaký přírůstek bude dodán na konci sprintu? o Jakou práci je potřeba vykonat? o Vstupem do plánování je: o Backlog, dokončení sprint. o Počet položek ve sprintu určuje tým. o Tým definuje i cíl sprintu (Sprint Goal). o Proč se tento sprint realizuje – co bude hotovo. doc. Ing. Radek Šilhavý, Ph.D. 89  Fáze Plánování (b) o Druhá část – Jak bude práce provedena? o Návrh prací potřebných k přeměně vybraných story do přírůstku. o Plánovat dostatečný čas. o Scrum Master a vlastník produktu dostanou informace jak se bude pracovat. o Cíl Sprintu o Hranice z pohledu dosažení funkčnosti během sprintu. o Cílem může být i milník projektu. doc. Ing. Radek Šilhavý, Ph.D. 90  Význam Daily Scrum-u o Plán na 24 hodin. o Zpravidla ráno. o Kontrola minulých 24 hodin. o Odhad práce na den. o Co bylo, Co bude dokončeno? Jaké překážky máme? o Odpovědnost týmu, Scrum master jen pozorovatel. o Není jen o tom co je hotovo. Měl by vést k řešení a minimalizovat potřeby konzultací v rámci týmu. doc. Ing. Radek Šilhavý, Ph.D. 91  Sprint Review o Hodnocení přírůstku. o Případná adaptace produktového backlogu. o Vlastník rozhoduje co bylo a co nebylo dokončeno. o Tým diskutuje problémy a jak se jim vyhnout o Tým prezentuje přírůstek. o Výsledkem je případná revize backlogu. doc. Ing. Radek Šilhavý, Ph.D. 92  Fáze Retrospectiva o Kontrola jak probíhal sprint – lidé, procesy, nástroje. o Co fungovalo dobře a co ne. o Plán na zavedení vylepšení (jsou-li). o Nejde o produkt, ale o fungování SCRUM-u. doc. Ing. Radek Šilhavý, Ph.D. 93