====== N-AP1 ====== ====== Zadání ====== Základní schéma životního cyklu software. Pracnost jednotlivých etap. Techniky specifikace požadavků. Varianty životního cyklu. SW prototypy. Strukturovaný vývoj. ====== Základní schéma životního cyklu software ====== **Software** je souhrn počítačových programů, dat a dokumentace, který náleží k provozu počítačového systému. Počátek jeho životního cyklu začíná nápadem na to začít vymýšlet nějaký software a končí v okamžiku kdy jej poslední člověk přestane používat. Mezitím lze jeho životní cyklus popsat zhruba takto: * **Specifikace požadavků**: zadání problému, který bude software řešit, návrh jak bude software komunikovat atd. Specifikace by se měla také otestovat. * **Analýza**: vytvoří se logický návrh systému (koncept), zpravidla se zaznamená pomocí nějakých grafických technik * **Návrh**: rozklad na podproblémy, určí se kdo a co má udělat. * **Implementace**: návrh algoritmů, programování * **Testování**: validace produktu proti specifikaci * **Provoz a údržba produktu**: údržba verzí, opravy chyb * **Stažení systém z užívání** V každé fázi by mělo probíhat ověřování a testování SW: * **Validace**: ověření splnění funkčních požadavků * **Verifikace**: ověření dodržení specifikace * **Testování**: nalezení chyb * **Ladění**: odstranění chyb ====== Pracnost jednotlivých etap ====== Obecně nejpracnější činností je vytváření dokumentace a odstraňování defektů v programech. U velkých systémů zabere 90% času odstraňování problémů. Obecně platí, že ve zmíněném životním cyklu je velmi obtížné vracet se o více než jeden krok zpět. Tj. opravovat chybu ve specifikaci až když je projekt předaný je velmi obtížné. Jako další pohled se často uvádí fakt, že největší část //vývoje software// zabere jeho údržba -- tj. následný provoz, aktualizace atd. ====== Techniky specifikace požadavků ====== Ideální specifikace požadavků systému by měla být naprosto pevná, přesná, úplná a bezesporná. Specifikace vzniká v několika krocích, kde na začátku vznikne neformální specifikace požadavků – odborný článek, která obsahuje prvotní nápad co by systém měl dělat. Na základě ní vytvoří dodavatel funkční specifikaci, která je už mnohem přesnější a zpravidla využívá některých metod formální specifikace. Týká se hlavně toho jak bude systém pracovat navenek, ne jak bude vypadat uvnitř. Bývá také součástí kontraktu mezi dodavatelem software a zákazníkem. Pro fungování vnitřní části systému lze pak případně vytvořit tzv. návrh implementace. Může obsahovat soubory use case diagramů, které jsou známy jako funkční požadavky, zachycující všechny možné interakce uživatele se systémem. Součástí mohou být i požadavky nesouvisející přímo s funkcí software tzv. nefunkční požadavky. Mohou to být např. požadavky na rychlost software, předepsaná metodika vývoje, legislativa, množství peněz na vývoj atd. Specifikaci si tak můžeme představit jako dokument, který obsahuje všechny uživatelovy požadavky na systém ve strukturované a srozumitelné formě. Tento dokument je závazným podkladem pro návrh a realizaci systému. {{:mgr-szz:ap-ap:specifikace.png|}} ● **Interview**: hlavní prostředek získávání požadavků, dobře připravený pohovor o tom, co uživatel dělá, co by mohl IS zlepšit či přinést, varianta porady, kde se jedna skupina převážně ptá a druhá odpovídá ● **Strukturované interview**: interview, kde se postupně odpovídá na otázky podle předem připraveného dotazníku ● **Dotazník**: podobné strukturovanému interview -- pouze dostane na stůl a nikdo mu s tím neradí. Výhoda: pro rychlé zjištění relativně jednoduchých informací, levné. ● **Studium dokumentu** (a existujícího IS): výhoda: vzor řešení (např. obrazovek) + levné, nevýhoda: nebezpečí opakování chyb ● **Účast/sledování prac. procesu**: výhoda: nezprostředkovaná informace, nevýhoda: výběrové efekty (nezachytí se činnosti vyskytované zřídka), velmi drahé, ruší to ● **Brainstorming**: Neformální porada s cílem najít nová řešení, vize a myšlenky, okamžité nápady se hned zapisují na flipcharty a obvykle neformálně hodnotí, i bláznivé nápady se nezatracují a zapisují, vyhodnocení a koordinace nápadů již nebývá součástí porady ● **Workshop**: Pro hodnocení a kontrolu průběhu prací, získání přehledu o stavu prací ● **Oponentury**: nejefektivnější detekce anomálií, snížení rizika neúspěchu ale pracné, detekuji ale nemám opravovat * **Revize**: Verifikace většího celku formou blízkou oponentuře v běžném smyslu. Používá se i u feasibility study (studie uskutečnitelnosti) * **Inspekce (vnitřní)**: Přísně formalizované oponentní řízení pro menší dokumenty s řadou činností a rolí. * **Audit (vnější)**: Varianta porady, kdy se má zjistit, zda se řešení (ekonomicky) neodchyluje od plánu a zda je naděje na dosažení cílů co do obsahu i termínů ====== Varianty životního cyklu ====== ===== Model vodopád ===== {{:mgr-szz:ap-ap:modelvodopad.png|}} Je jedním z klasických způsobů vývoje software, skládající se z jednotlivých etap, které na sebe navazují a mohou se i překrývat. Dobře se řídí, ovšem obtížně se vyrovnáva s chybami vnesenými do procesu na začátku. Dá se přirovnat ke stavbě budovy. Skládá se z navazujících činností: * **Specifikace požadavků** (architekti) - studie proveditelnosti, obrysové požadavky, funkční specifikace * **Analýza a návrh software** (projektanti) - specifikace architektury a rozhraní, specifikace návrhu * **Implementace** (stavební pracovníci) * **Testování** (kolaudátoři) - protokoly o testování jednotek, modulů, integrační testy, testování systému * **Provoz a údržba** (údržbáři) - konečný systém a dokumentace Jedním ze zásadních problémů tohoto přístupu je, že zákazník vidí svůj software až na konci procesu, což je problém v okamžiku, kdy na začátku procesu vlastně ani neví co chce. Tento model se hodí pro oblasti, které řešitelský tým dobře ovládá. Jsou vyžadování talentovaní pracovníci. Jakékoliv změny poškozují strukturu a jejich následky jsou nákladné na opravu a rostou společně s etapami. Proces není viditelný a manažér potřebuje pravidelné výstupy (dokumenty), aby ho mohl řídit. Existuji různé verze modelu vodopádu, které umožňují se u některých kroků vracet zpět. Teoreticky je možné se po všech krocích pohybovat oběma směry, avšak vždy při pohybu zpět je situace nákladná a složitá, především u vracení se o více kroků. ===== Model výzkumník ===== Tento model je vhodný řekněme pro programování věcí, které řešitelé neznají. Skládá z operací: {{:mgr-szz:ap-ap:modelvyzkumnik.png|}} Tento systém práce se obtížně řídí a plánuje, má problémy s dokumentací a zpravidla do vývoje vidí jen jeden výzkumník nebo výzkumný tým a jejich rozpad či odchod pracovníka znamená ukončení projektu. Je to experimentování a výsledek je nejistý. ===== Model prototypování ===== Tato metoda se snaží překonat problémy spočívající v nepřesně formulovaných, případně měnících se požadavcích na systém. Spočívá ve vytváření tzv. protopypů, což jsou částečné implementace výsledného produktu se všemi rozhraními, které pak potenciální uživatelé testují. Prototypy se pak případně vylepšují, použijí nebo zahodí. Nejedná se o metodiku s kompletním přístupem k vývoji, ale spíše k jednotlivým částem jiných metodik (spirála, Rad, atd.). Opět existuje mnoho podob prototypování, základní myšlenka je však v opakovaném vytváření a hodnocení (analýze) prototypů. Používá se obvykle u menších systémů a zpravidla je nutné stanovit hranici pro vytváření prototypů, aby se nevytvářely donekonečna. {{:mgr-szz:ap-ap:prototyping.png|}} ===== Inkrementální (přírůstkový) přístup ===== Inkrementální přístup je vhodný pro kombinaci sekvenčních a iteračních metodik softwarového vývoje. Cílem je omezit projektová rizika rozdělením projektu na menší segmenty a zjednodušuje možnost zavedení změn během procesu vývoje. Základní principy inkrementálního přístupu: * Jsou prováděny série malých vodopádů, kde každý vodopád je prováděn pro malou část systému a je dokončen před pokračováním na další přírůstek, nebo * obecné požadavky jsou definovány dříve než se přikročí k evolučnímu vývoji pomocí malých vodopádů pro jednotlivé přírůstky systému, nebo * Prvotní koncept, analýza požadavků, design architektury a systémové jádro jsou definovány vodopádovým přístupem, následuje iterativní prototypový přístup, který vrcholí instalací konečného prototypu jako funkčního systému. ===== Spirálový model ===== Vytvořený hlavně za účelem minimalizace rizik při postupu pomocí vodopádu. Jednotlivé kroky se ve spirále opakují se stále vyšším a vyšším stupněm zvládnutí problematiky. Spirála většinou začíná analýzou rizik, dále se rozvíjí prototyp a zakončuje se kontrolou výsledků a testováním. {{:mgr-szz:ap-ap:spiral_model_boehm_1988_.svg.png|}} Během každého cyklu spirály jsou spouštěny čtyři základní fáze (kvadranty): - Plánování – plán pro příští iteraci - Vyhodnocení – vyhodnocení alternativ, identifikace a řešení rizik - Vývoj – vývoj produktu a kontrola očekávaných výsledků - Analýza – stanovení cílů, alternativ a rozsahu iterace Cyklus může začít prvním nebo i druhým krokem. ===== Další modely vývoje softwaru ===== Strukturované programovvání SSADM (Structured Systems Analysis and Design Methodology) Objektově orientované programování/design (OOP/OOD) Unified Process (UP) - založen na UML RUP (Rational Unified Process) - aplikace UP AUP (Agile Unified Process) Extrémní programování Agilní programování ====== SW prototypy ====== **SW prototyp = částečně funkční model systému, který realizuje či simuluje některé vlastnosti systému.** Prototypování umožňuje odhalit nedostatky již v začátku projektu. Prototyp není určen k cílovému řešení, pouze k ověření specifikace funkcí, zpřesnění požadavků. Bohužel zřídka otestuje vlastnosti, jež se ukážou až v provozu. Důvody pro vytvoření prototypů: * ověření správnosti a úplnosti specifikace požadavků * ověření správnosti a úplnosti funkcí a návrhu struktury systému * předběžný odhad nákladů a rizik realizace Výhody: ověření správnosti, lepší konzultace se zákazníkem a odhady pracnosti, brzo máme něco v ruce. Nevýhody: větší pracnost, ne vždy odhalí funkční chyby === Typy prototypů === - Potěmkin: model cílového systému, který simuluje uživatelské rozhraní, tedy obrazovky dialogů a tvar tiskových sestav. Výkonná část systému téměř, čí úplně chybí. - Neúplný: modeluje pouze některé funkce. - Jiný kůň: téměř úplný, ale funguje na jiném HW nebo nad jiným základním SW - Hlemýžď: neefektivní, pomalý - Nepříjemný: má nepříjemné uživatelské rozhraní, je nestabilní - Lajdák: nereaguje správně na chyby v datech a chyby obsluhy ====== Strukturovaný vývoj ====== Strukturovaný vývoj je založený na strukturované analýze, což je druhá část vývoje projektu. První část vývoje je soubor uživatelských požadavků na systém. Strukturované metody: * Rozdělují problémy na menší, dobře definovatelné aktivity a určují posloupnosti a interakce těchto aktivit. * Používají diagramy a další modelovací techniky k vytvoření specifikace, které rozumí uživatelé i návrháři systému. **Strukturovaná analýza a specifikace systému (SASS)** DeMarco a jeho 4 modely: - Studie stávajícího fyzického systému - Odvození logického ekvivalentu stávajícího systému - Odvození nového logického systému - Odvození nového fyzického systému Pro modelování systému používá metodika strukturované analýzy tyto nástroje: * DFD (dataflow diagram) - procesy, datové paměti, data vstupující do procesů, transformovaná data vystupující z procesů a terminátory. DFD mohou být na úrovni procesů dekomponované na vlastní DFD. * Datový slovník * Strukturovanou angličtinu * Rozhodovací tabulky procesů * Rozhodovací stromy Později přišli jiní pánové (Gane, Sarson) s vylepšením této metody s názvem Logické modelování. Vývoj při něm probíhá takto: (DFD, Pameti, ERD, Vazby, Prekresleni, Jednotky, Popis) - Vytvoření prvotního systémového DFD - zahrnuje procesy, datové toky, paměti a vnější entity. Vymezí hranice systému, vnější entity a datové toky na hranici systému. Ukáže uložená data a transformující procesy. Měl by být srozumitelný i zákazníkovi. - Načrtnutí datového modelu - Vytvoří se seznamy všech datových paměti, které ponesou jména objektů, které se uchovávají. Sledují se data, která do systému vstupují zvenčí až doputují do datových pamětí. - Analýza entita a jejich vztahů(logický datový model) - Vyhledáváme objekty – entity a hledáme mezi nimi vztahy. Vytváříme ERD. - Vytvoříme ERD v normalizovaném tvaru. Normalizovaných tvarů je větší množství. Neměly by tam být vazby M:N, dále by každá tabulka měla mít jeden klíč a všechny položky by měly záviset na klíči. - Překreslení DFD tak, aby reflektoval změny provedené v ERD. - Z procesů a dat vytvoř procedurální jednotky, které lze samostatně provozovat a naprogramovat – tj. rozdělit práci programátorům. - Specifikuj detaily každé jednotky např. DFD jednotky, popis ve strukturované angličtině, příklad výstupů atd. {{:mgr-szz:ap-ap:sass.png|}} ====== Předměty ====== PB007 Analýza a návrh systémů ====== Vypracoval ====== Marek Menšík UČO 255679 Nevím přesně, kdo otázky zpracoval přede mnou, pouze jsem je sem umístil, doplnil chybějící věci a opravil nepřesnosti. Připomínám, že věci zde uvedené nemusí být korektní a zatím neprošly kontrolou žádného z profesorů. Z mé strany je tato otázka dokončena a případné chybějící věci a chyby mě můžete napsat na UČO mail nebo se registrujte a upravte je sami. ====== Použitá literatura a weby ====== Skripta předmětu PB007 http://users.csc.calpoly.edu/~jdalbey/308/Lectures/SoftwareProcessModels.html http://statnice.dqd.cz/mgr-szz:in-ins:1.1-ins Pekny material Strukturovane analyzy: http://www.fit.vutbr.cz/study/courses/PPS/public/pdf/9_stran.pdf ~~DISCUSSION~~