====== N-INS 1.1 První otázka (první část) ======

====== Zadání ======
Modely životního cyklu SW. Návaznosti a produkty jednotlivých etap. Aplikace CASE v životním cyklu. Specifikace požadavků. Prototypy a oponentury.

====== Vypracování ======

===== Modely životního cyklu SW =====
<box orange left | Upřesnení zdrojů:>**Lit. 1** Kniha IS (str. 97-102), **Lit. 3** TIS II (7. přednáška), **Lit. 4** ANANAS (1. a 16. přednáška), **Lit. 6** OMNIS (1. přednáška), **Lit. 7** SDCL, **Lit.8** Vypracované otázky k IS.</box>
==== Definice ====
"**Software Development Life Cycle Model** -- framework that describes the activities performed at each stage of a software development project."((Lit. 7, sld. 4))

"**Životní cyklus SW** popisuje život SW od jeho návrhu, přes implementaci, až po jeho předání a údržbu."((Lit. 6, první přednáška))

==== Jednotlivé etapy ====
  * Specifikace cílu, vize, plánování
  * Specifikace požadavků
  * Návrh
  * Implementace
  * Testování
  * Evaluace
  * Předání a nasazení
  * Provoz a údržba
{{:mgr-szz:in-ins:1_software_lifecycle.jpg?300|Fázy životního cyklu SW}}

==== Vodopád ====
  * jeden z nejstarších modelů vývoje SW 
  * po úplném dokončení jedné etapy je její výsledek předán jako vstup pro další etapu -- k zakončené etapě není nutné se vracet
  * začnu-li padat, nezastavím se dříve, než se rozbiji o kámen zvaný předvedení
  * problémy s cenou v případě nezdaru v některé z pozdějších etap
  * existují však variace nebo vylepšení tohto modelu

{{:mgr-szz:in-ins:1_vodopad.png?300|}}

<box 30% green left | Výhody:>
  * jednoduchý k porozumění a k použití
  * poskytuje jasnou strukturu pro méně zkušený tým
</box><box 30% left red | Nevýhody:>
  * požadavky na systém musí být dopředu známé
  * málo flexibilní
  * může dávat mylní dojem progresu
  * chyby, ke kterým je potřeba se vracet – zvyšují se náklady
  * slabá kontrola uživatelem - systém vidí až na konci (může být pozdě)
</box><box 30% left | Použití:>
  * požadavky na systém jsou dobře známé
  * definice produktu je stabilní
  * dokonalé pochopení technologií
  * nová verze existujícího produktu
</box>

==== V-Shaped model ====
  * upravená varianta vodopádu, která zdůrazňuje verifikaci (studie proveditelnosti, revize, inspekce,...) a validaci (testování)
  * testování produktu je plánováno paralelně s jednotlivými fázemi vývoje
  * jenom validace nestačí
  * účinnost odhalení chyb se zvyšuje verifikací -- může být až 80%

{{:mgr-szz:in-ins:1_v-shaped.png?300|}}

<box 30% green left | Výhody:>
  * jasné a jednoduché použití 
  * důraz na naplánovaní verifikace a validace je kladený už na začátku vývoje
  * každý výstup z fáze musí být prověřený
  * projektový manažment může sledovat progres po jednotlivých milnících
</box><box 30% left red | Nevýhody:>
  * souběžné události se nedělají lehko
  * dynamické změny v požadavcích se nedělají lehko
  * neobsahuje analýzy rizik
</box><box 30% left | Použití:>
  * pro vývoj systému, který vyžaduje vyšší spolehlivost
  * požadavky na systém jsou dobře známé
  * řešení a technologie jsou dobře známé
</box>

==== Prototypování ====
**Prototyp** -- částečně funkční model systému, který realizuje nebo simuluje některé vlastnosti systému.
  * vývojáři vytvoří prototyp v průběhu fáze specifikace požadavků (analýzy)
  * tvorba prototypů probíhá za účelem získávání poznatků
  * prototyp se prezentuje koncovým uživatelům, dává zpětnou vazbu vývojářům
  * prototypy se pak případně vylepšují, použijí nebo zahodí

{{:mgr-szz:in-ins:1_prototyping.png?600|}}

<box 30% green left | Výhody:>
  * zákazník "vidí" požadavky na systém
  * vývojáři se učí od zákazníků (komunikace nad doménou)
  * více se upřesňuje koncový produkt
  * umožňuje větší flexibilitu návrhu a vývoje
  * protypy stimulují uvědomování si potřebné přídavné funkcionality
</box><box 30% left red | Nevýhody:>
  * tendence sklouznout k vývoji “code-and-fix”
  * špatná reputace za “quick-and-dirty” methods
  * je nutné stanovit hranici pro vytváření prototypů, aby se nevytvářely donekonečna (scope creep)
</box><box 30% left | Použití:>
  * spíše pro menší systémy
  * když jsou nepřesně formulovány, případně měnící se požadavky na systém, nebo požadavky musí být objasněny
  * vývoj uživatelského rozhraní
  * pro případ rychlé demonstrace systému
  * nový, originální návrh
  * vhodné pro OO analýzu a návrh
</box>

==== 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
  * stanoví se cíle a výchozí analýza požadavků a návrh architektury
  * výchozí prototyp a jeho předvedení -> plán vývoje prototypu -> provede se analýza alternativ a rizik
  * několikanásobně se provede životní cyklus prototypu
  * poslední prototyp se nazývá operační -> po něm následuje zbytek vodopádu (návrh, kódování, testování, předání, údržba)

{{:mgr-szz:in-ins:1_spiral.jpg|}}

<box 30% green left | Výhody:>
  * zahrnuje analýzu rizik
  * uživatel (zákazník) brzo vidí systém v podobe prototypu
  * hodně rizikové funkce se vytvářejí jako první
  * návrh nemusí být úplně perfektní
  * zákazníci jsou lépe provázaní s každou fází životního cyklu
  * včasný a častý feedback od zákazníků 
  * lepší odhad kumulativních nákladů
</box><box 30% left red | Nevýhody:>
  * čas strávený nad vyhodnocováním rizik u projektů s malými nebo nízkymi riziky 
  * celkově může být hodně náročné na čas
  * spirála by mohla končit v nekonečně :)
  * může být obtížné definovat konkrétní a ověřitelné mílníky
</box><box 30% left | Použití:>
  * pro vývoj od počátku
  * vhodné pro velké systémy
  * vhodné pro IS, kde je známá míra nejistoty ve stanovení požadavků (uživatelé jsi nejsou jistí potřebami)
  * když je vyhodnocení nákladů a rizik důležité
  * pro středně až vysoko rizikové projekty
</box>
==== Výzkumník ====
**Analyzuj a navrhni systém → Implementuj systém → Používej systém → Pokud vyhovuje, předej systém. Pokud ne, vrať se k nové implementaci.**
  * je to experimentování, u kterého často netušíme, jak dopadne
  * v průběhu vývoje se řešitelé při získávání poznatků a zkušeností často vracejí k již přežitým etapám

<box 30% left red | Nevýhody:>
  * práce se obtížně řídí a plánuje
  * často dochází k překročení stanovených finančních i časových limitů
  * má problémy s dokumentací (neexistující či neplatná)
  * 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 (nenahraditelnost řešitelů)
</box><box 30% left | Použití:>
  * tento model je vhodný řekněme pro programování věcí, které řešitelé neznají, pro experimentální projekty
</box>

==== Iteratívní vývoj ====
**Iterativně = „předělávat“**
  * celý projekt se vyvíjí v několika iteracích
  * iterace směřují k postupnému vylepšení, zpřesnění, dodělání nebo opravení části systému
  * výsledkem každého cyklu je větší a lépe fungující část cílového systému
  * každá iterace obsahuje analýzu, návrh, testování apod. (tj. miniaturní vodopád),ale s různou intenzitou, např.:
    * v první iteraci provést celkovou analýzu požadavků a obrysový plán vývoje, více rozpracovat jádro systému, implementovat základní testovací třídy
    * v druhé iteraci podrobně rozpracovat důležité části systému, rozmodelovat je a částečně implementovat
    * ve třetí iteraci podrobně rozpracovat méně podstatné části systému, doimplementovat věci z předchozí iterace
  * vývoj typu vodopád je tedy iterativní vývoj s jedinou iterací

{{:mgr-szz:in-ins:1_iterative.jpg?300|}}

<box 30% green left | Výhody:>
  * rychlejší (dílčí) výsledky (umožňuje dříve dospět k SW (po částech))
  * rychlejší odhalení chyb
  * lze vyvíjet i v menším týmu
  * snadněji se integrují produkty třetích stran a existující aplikace 
</box><box 30% left red | Nevýhody:>
  * celý systém je hotový až za delší dobu
  * obtížně se zkracují termíny realizace
  * u některých systémů je obtížné použítí
  * nutnost předělávat kód (není tak velká nevýhoda -- je lepší špatný kód přepsat, než ho nějak obcházet)
</box>

==== Inkrementální vývoj ====
**Inkrementálně = „přidávat k“**
  * uplatňuje se zejména u větších projektů a/nebo v agilním vývoji
  * jednotlivé části systému (přírůstky, inkrementy) vytváříme „nezávisle“ na zbytku a pak integrujeme
  * vývoj jednotlivých přírůstků může probíhat iterativně, vodopádem, XP,... -- nejčastěji se používá iterativní vývoj přírůstků
  * vývoj typu vodopád je tedy inkrementální vývoj s jediným přírůstkem představujícím celý systém.

{{:mgr-szz:in-ins:1_incremental.png|}}

<box 30% green left | Výhody:>
  * ve více týmech (možný paralelní vývoj)
  * integrace existujících aplikací a aplikací třetích stran
  * samotné přírustky lze realizovat různymi metodami
  * snadno lze modifikovat, modernizovat
</box><box 30% left red | Nevýhody:>
  * vyžaduje dobré plánování a návrh
  * vyžaduje dřívější definici kompletního a plně funkčního systému, aby se definovaly inkrementy
  * vyžaduje dobře zadefinovat rozhraní modulů
</box><box 30% left | Použití:>
  * projekty, které mají dlouhý plán vývoje
  * iterativní a inkrementální vývoj používejte pouze pro projekty, se kterými chcete uspět :-) -- Martin Fowler: UML Distilled
</box>

==== RUP ====
  * není jeden konkrétní ustálený proces, ale spíše framework určený k tomu, aby ho organizace implementovala a upravila dle svých potřeb a specifik
  * aplikuje iterativně-inkrementální vývoj
  * výrobek prochází přes čtyři základní fáze:
    * Zahájení (Inception): potvrzení konceptu, proveditelnost, cíle
    * Rozpracování (Elaboration): detailní požadavky, scénáře použití, architektura, komponenty, vzory interakce na vysoké úrovni
    * Konstrukce (Construction): zdokonalení architektury, implementační iterace řízené rizikem
    * Předání (Transition): uživatelské přijetí, ...
  * každá fáze může být dále rozdělena do různých iterací (cyklů)
  * každá iterace (cyklus) obsahuje analýzu, návrh, implementační aktivity a produkuje novou verzi systému – release (inkrement)

{{:mgr-szz:in-ins:1_rup.jpg|}}

==== Agilní metodiky ====
**Manifesto of Agile Software Development** [[http://agileManifesto.org]]
  * metody zaměřené více na lidi – určujícím faktorem v úspěchu projektu je kvalita lidí pracujících na projektu a jejich spolupráce
  * často iterativní nebo inkrementální vývoj s krátkými iteracemi (jeden měsíc a méně)
  * malé ale výkonné týmy (dvojice)
  * vhodné pro malé a nekritické aplikace
  * malý důraz na dokumentaci
  * snaží se o dodržení rozpočtu a harmonogramu tím, že umožňuje změny funkcionality
  * zapojení zákazníka do vývoje (zákazník se účastní sestavování návrhu a testů, ideálně je součástí vývojového týmu)
  * individuality a interakce mají přednost před nástroji a procesy 
  * fungující software má přednost před obsáhlou dokumentací
  * spolupráce se zákazníkem má přednost před sjednáváním smluv
  * reakce na změnu má přednost před plněním plánu

{{:mgr-szz:in-ins:1_agile.png?400|}}

<box 30% left | Konkrétní metodiky:>
  * Adaptive Software Development (ASD) 
  * Feature Driven Development (FDD) 
  * Crystal Clear 
  * Dynamic Software Development Method (DSDM) 
  * Rapid Application Development (RAD)
  * Scrum 
  * Extreme Programming (XP)
  * Test-Driven Development (TDD)
</box>

===== Návaznosti a produkty jednotlivých etap =====
<box orange left | Upřesnení zdrojů:>**Lit. 1** Kniha IS (str. 84-86), **Lit. 4** ANANAS (1. přednáška), **Lit. 9** Analyza a navrh IS.mm (Navaznosti a produkty jednotlivych etap).</box>
==== Návaznosti ====
  * každá etapa je ukončena vnitřní oponenturou
  * problém v etapě znamená vracet se k některé z předchozích etap
  * každá etapa má své dokumenty (dokumentace se buduje během celého ŽC)
  * ideálně se nezabývat nižšími etapami při projednávání vyšší
  * vystopovatelnost požadavků !!! (CMM)

==== Produkty jednotlivých etap ====
=== Specifikace požadavků ===
  * neformální specifikace
  * formální specifikace
    * funkční požadavky
    * nefunkční požadavky
  * uživatelský vzhled aplikace
  * oponenturou je feasibility study (uskutečnitelnost)
=== Specifikace systému ===
  * High Level Design dokument
    * analýza funkčních požadavků
      * diagramy použití
      * analytický diagram tříd
      * základní sekvenční diagramy
      * základní komunikační diagramy
    * analýza nefunkčních požadavků
      * varianty architektury běhového prostředí
      * deployment diagramy
    * hlavní rizika projektu
  * předběžný projektový plán
    * základní milestony
    * termíny
    * základní cena
    * time-material vs fixed-priced
  * plán testování
  * návrh uživatelského manuálu
  * oponentura je revize zákazníka + vnitřní oponentura
=== Návrh ===
  * návrh architektury
    * specifikace architektury
    * plán testování systému
  * návrh rozhraní
    * specifikace rozhraní
    * plán integračních testů   
  * podrobný návrh
    * specifikace návrhu (detailní návrhový class diagram, sequence diagramy, přesný deployment diagram)
    * plán testování jednotek 
  * běhová dokumentace
    * popis běhového/vývojového/testovacího prostředí
    * plán obnovy po výpadku
    * instalační skripty
    * upgrade skripty
  * uživatelská dokumentace
    * uživatelská příručka
    * instalační příručka
    * běhová příručka
    * tutoriály 
  * oponentura je informace zákazníka + vnitřní oponentura
=== Implementace ===
  * balíčky s kódem
  * plán testování jednotek
  * revize kódu jako oponentura, čtení, inspekce
=== Testování ===
  * testovací scénaře
  * konečný uživatelský manuál
  * záznamy o provedených testech a výsledky 
    * protokol o testování jednotek
    * protokol o testování modulů 
    * protokol integračních testů
    * protokol testování sytému
=== Předávání systému ===
  * přejímací testování (akceptační testy)
  * konečný systém a dokumentace
  * předávací protokol
=== Provoz a údržba ===
  * chybové výstupy aplikace
  * sběr uživatelských požadavků a postřehů

===== Aplikace CASE v životním cyklu =====
<box orange left | Upřesnení zdrojů:>**Lit. 1** Kniha IS (str. 297-300), **Lit. 8** Vypracované otázky k IS, **Lit. 9** Analyza a navrh IS.mm (Aplikace CASE v zivotnim cyklu).</box>
=== Computer Aided Software Engineering (CASE)===

=== Z hlediska životního cyklu SW se nástroje CASE dělí do následujících skupin: ===

==== 1. Horní (upper) CASE ====
  * **použití pro specifikaci cílů, počáteční fáze specifikace požadavků, řízení projektu**
  * **hlavním cílem je porozumění a specifikace systému jako celku** (analýza organizace, v níž se má systém používat, zobrazení procesů v organizaci, definice klíčových informačních toků, atp.)
  * patří sem i nástroje pro plánování a vedení projektů, procesní inženýrství
=== Hlavní nástroje ===
  * decision trees, decision tables
  * diagramy toků dat a jejich varianty
  * ER diagramy bez podrobné specifikace všech atributů
  * prostředky pro řízení projektů (napr. JIRA, Microsoft Project)
  * dokumentografické systémy
  * popis základních vlastností systému prostředky OO modelování

==== 2. Střední (middle) CASE ====
  * **použití pro podrobné specifikace požadavků, návrh systému, dokumentace a vizualizace systému**
  * **hlavní cíle: formalizace specifikace a návrhu s cílem usnadnění změn a snažší komunikace se zákazníky, vytvoření modelů usnadňujících, případně umožňujících generaci návrhu**
  * je jádrem komerčně dodávaných CASE systémů
  * především u větších firem
  * zahrnují prostředky pro podrobnou specifikaci požadavků a návrh systému
  * nejúspěšnější, neboť pokrývá činnosti, které nejsou předmětem činnosti konzultačních firem, a firem zabývajících se tvorbou modelů podniků a řízením projektů
  * nejsou dosud ve větší míre integrovány do moderních prostředí pro vývoj SW
=== Hlavní nástroje ===
  * diagramy toků dat včetně možnosti podrobnějšího popisu procesů, dat. úložišť a datových toků 
  * ER diagramy s možností detailní specifikace atributů
  * pro objektovou metodologii diagramy OO technik – diagramy tříd a jejich vztahů, diagramy instancí, přechodové dia., atp.
  * systém správy dokumentů a správy konfigurace
  * systémy vyhodnocování metrik souvisejících s návrhem systému a specifikacemi požadavků
  * vývoj prototypů, většinou potěmkinovských, návrh rozhraní, generátory obrazovek a sestav
  * generátory definic dat. Někdy pouze kostry definic, někdy se doplňují ručně.
==== 3. Dolní (lower) CASE ====
  * **obsahují nástroje na podporu kódování, testování a údržby a reverzního inženýrství**
=== Hlavní nástroje ===
  * vývojové prostredie (IDE)
  * generátory kódu
  * prostředky reverse engineering. Nástroje umožňující rekonstrukci dokumentace z existujícího SW nebo alespoň detekci míst, kde již existující dokumentace neodpovídá aktuálnímu stavu.
  * prostředky sledování a vyhodnocování metrik kódu
  * prostředky a nástroje plánování a zajišťování kvality SW (sběr info o průběhu testování, řízení testování, sběr a vyhodnocení dat, inspekcí a výsledků testů, pravidla přijímání prvků konfigurace, podpora plánování opatření na zajišťování kvality)
  * správa konfigurace
  * prostředky sledování a vyhodnocování práce systému

==== Aktuálnější dělení ====
  - Pre-CASE: plánování
  - Upper-CASE: specifikace požadavku
  - Middle-CASE: kooperace při návrhu
  - Lower-CASE: návrh a vývoj
  - Post-CASE: údržba, modifikace

===== Specifikace požadavků =====
<box orange left | Upřesnení zdrojů:>**Lit. 1** Kniha IS (str. 83, 87-95), **Lit. 3** TIS II (5. přednáška), **Lit. 4** ANANAS (2. přednáška), **Lit. 8** Vypracované otázky k IS, **Lit. 9** Analyza a navrh IS (Specifikace pozadavku).</box>
==== Specifikace požadavků ====
Požiadavky rozdeľujeme na **funkčné** (funkcionalita) a **nefunkčné** (napr. výkon, bezpečnosť). Výsledkom špecifikácie je tzv. feasibility study (štúdium uskutočniteľnosti -- vyhodnotenie z ekonomického hľadiska, právneho hľadiska, schopnosti tímu a pod.).

Analýza představuje studium problému před tím, než podnikneme nějaké akce směřující k jeho řešení.
Předmět analýzy:
  * Existující systém, jehož struktura a funkce nejsou zřejmé zákazníkovi ani řešiteli, případně zákazník neumí strukturu chování systému řešiteli vysvětlit.
  * Neexistující systém, o němž má zákazník nepříliš přesnou představu a neumí požadované funkce řešiteli vysvětlit.
Výsledkem analýzy je specifikace systému.

Specifikace požadavků je součástí analýzy. Vychází z dokumentu "Stanovení cílů" (z fáze stanovení vizí). Obsahuje cíl řešení, požadovaný výsledek. Je základem a úzkým místem každého systému. Cílový stav je dokumentovaný tak, aby bylo možné posoudit, zda implementace uvedeného stavu dosáhla. Dokument Specifikace požadavků je závazným podkladem pro návrh a realizaci systému. Může být formální i neformální.

Má obvykle následující strukturu:
  - název projektu a identifikátor projektu
  - úvod - shrnutí úkolů v obecně srozumitelné rovině
  - vymezení uživatelů a způsobu využití produktu
  - perspektivy realizovaného systému (doba života,...)
  - způsob vedení dokumentace
  - zajištění spolupráce mezi dodavatelem a uživatelem
  - dokumenty odkazované v textu
  - použité zkratky a slovník
  - vazby na jiné projekty
  - požadavky na HW, efektivnost a spolehlivost
  - rozpis dat a funkcí - dekompozice systému
  - plán testů
  - vymezení obsahu dokumentace předávané uživateli
  - termíny realizace, plán realizace
  - ekonomické a organizační zajištění (odhad nákladů, řešitelský tým)
  - vymezení způsobu údržby a způsobu prodeje produktu dalším uživatelům
<note important>
**Základní vlastnosti specifikace požadavků**: úplnost, ověřitelnost, bezespornost, konzistentnost, modifikovatelnost, srozumitelnost, vystopovatelnost (každý požadavek má své důvody), použitelnost i během provozu systému, stabilnost (aby se požadavky neměnily příliš).
</note>

==== Techniky zjišťování požadavků ====
=== Sběr dat obecně ===
  * cizí firma
    * výhoda odstupu
    * drahé
  * samotná firma
    * nemusí podchytit všechny procesy (některé intuitivní)
    * levné
  * řešitelská skupina zahrnující oba (doporučuje se)
=== Jednotlivé techniky ===
  - **Interview:** dobře připravený pohovor o tom, co pracovník uživatele dělá, co by mohl IS zlepšit či přinést. Může být i skupinové. Existence moderátora a zapisovatele.
  - **Strukturované interview:** interview, kde se postupně odpovídá na otázky dle předem připraveného dotazníku.
  - **Dotazníky:** rozesílají se, uživatelé vyplní sami. Levné, ale nezjistí se vše.
  - **Studium dokumentů:** používaných zákazníkem.
  - **Pozorování chodu prací u zákazníka:** drahé, zdlouhavé, ruší při práci.
  - **Účast na pracovním procesu:** totéž co výše, někdy se neodchytí výjimečné případy.
  - **Analýza existujícího IS:** nebezpečí převzetí chyb původního IS.
  - **Společný vývoj požadavků:** formulace požadavků skupinou pracovníků uživatele a konzultantů dodavatele IS.
    * **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í. Členění: úvod, řada kratších vystoupení –- presentací výsledků s diskusí, shrnutí a závěr.
    * **Oponentury:** nejefektivnější detekce anomálií, snížení rizika neúspěchu. Pracné, detekuji, ale nemám opravovat (revize, inspekce,...).

===== Prototypy a oponentury =====
<box orange left | Upřesnení zdrojů:>**Lit. 1** Kniha IS (str. 97-98, 103-111), **Lit. 3** TIS II (5. přednáška), **Lit. 4** ANANAS (8. přednáška), **Lit. 8** Vypracované otázky k IS, **Lit. 9** Analyza a navrh IS (Prototypy a oponentury).</box>
==== 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

==== Oponentury ====
  * nejefektivnější detekce anomálií
  * snížení rizika neúspěchu
  * pracné

Napr. specifikace požadavků by měla být zakončena oponenturou. Kontroluje se splnitelnost požadavků, dodržení záměrů cílů projektu, návrh a zhodnocení plánu
dalšího postupu, správnost požadavků, bezespornost, atd. Výstupní dokument je Feasibility study = studie splnitelnosti. Její součástí mohou být výstupy částí vnitřních oponentur. Nejpozději se vypracovává před zahájením kódování, nejdříve však po dokončení spec. požadavků.
{{:mgr-szz:in-ins:1_v-shaped.png?300|}}

=== Dělení ===
  * **vnitřní -- dohled**: kontrolní činnosti prováděná vedením firmy formou kontrolních dnů. Prověrka skutečností důležitých z manažerského hlediska.
  * **vnější -- audit**: varianta porady, která prověřuje dodržování podmínek smlouvy, funkce systému, 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ů. Dohled je prováděný nezávislou organizací. Provádí auditor.

=== Vnitřní oponentury ===
  * kontrolní akce prováděné členy řešitelského týmu
  * druhy oponentur se liší úrovní formalizace a počtem účastníků
== Společné rysy ==
  * účastní se řešitelé, možno i spoluřešitelé ze strany budoucích uživatel
  * cílem je detekce chyb, chyby se neodstraňují, jen zaznamenávají
  * detekce chyb nesmí být důvodem postihu jejich původců
  * neměly by trvat déle než 2 hodiny
== Inspekce ==
  * oponentury prováděné podle přesných pravidel v 1 nebo více fázích ve skupině

**Jednofázové inspekce**
  * tým (3-6 lidí), vedoucí (moderátor), 1-3 oponenti, předčitatel a zapisovatel
  * pročítá se specifikace části nebo dokument nebo program, ostatní hledají chyby
  * materiály mají několik dní předem, o problémech se dělá zápis
  * méně než 2 hodiny, řídí moderátor, nemá se toho účastnit vedení
  * problémy se neřeší, jen detekují (výjimka - uživatelská dokumentace)
  * inspekce od celku k částem
  * odhalení až 80 % chyb
**Etapy jednofázové inspekce:**
  - plánování (moderátor), příprava materiálů, výběr členů, termín,...
  - úvodní studium (účastnící se školí, stanoví se jim role)
  - příprava (materiály pár dní dopředu, studium materiálů)
  - inspekce (pod vedením moderátora, zjišťují se chyby)
  - vypracuje se zápis (data do DBS)
  - přepracování (oprava materiálů)
  - kontrola (kontrola, zda byly chyby opraveny)
**Aktivní inspekce = metoda “zasetých chyb”, sleduje kvalitu inspekce**
  * vhodné pro kontrolu programů a návrh dat
  * zjišťuje se, kolik bylo nalezeno zasetých chyb a skutečných chyb
<m>c/C=z/Z</m>
c ... počet nalezených chyb
C ... celkový počet dosud neznámých chyb
z ... počet nalezených zasetých chyb
Z ... celkový počet zasetých chyb

**Vícefázové inspekce**
  * některé činnosti se při inspekci provádějí separátně
**Etapy vícefázové inspekce:**
  - provádějí jednotlivci: kontroly formálních vlastností (ty lze provést v principu i počítačem) Například se kontroluje celková struktura dokumentu, mnemotechnika zkratek, identifikátorů, index a úplnost odkazů, programovací standardy, typ org. rozložení, ...
  - skupinové inspekce:
    * oponenti dostanou materiály předem spolu s kontrolními otázkami jak co funguje
    * oponenti individuálně pročítají program či dokument a řídí se seznamem otázek a pokyny, co mají sledovat
    * ve skupině se výsledky z výše uvedených bodů jednotlivých respondentů porovnávají, zjistí se nejasnosti
    * provede se oponentura
    * vše se zanese do zápisu
== Revize ==
  * méně formální než inspekce, lze použít na větší celky
**Etapy revize:**
  - určí se moderátor, ten si vybere oponenty
  - každý oponent dostane k analýze určitou část oponovaného materiálu a snaží se nalézt problematická místa
  - provede se vlastní revize (stručně se specifikuje úkol, uvedou se a prodiskutují zjištěné nedostatky, zhodnocení dodržení plánu práce, lze vypracovat i doporučení, zhodnocení kvality materiálu)
  - výstupem revize je souhrnné hodnocení s přílohami obsahující seznam problémů
**Výhody:** větší flexibilita, možnost oponovat rozsáhlejší materiály, menší nároky na kvalitu členů oponentského týmu.
**Nevýhody:** menší účinnost, menší možnosti měření kvality provedení.
== Další techniky oponentur ==
  * **Ve dvojicích:** dvojice (extrémní programování), vedoucí týmu vs. jeho zástupce. Jeden vymýšlí a píše a druhý kontroluje. Je to efektivní, zlepšují se znalosti, možnost převzetí.
  * **Procházení nebo strukturované procházení:** dvojice až trojice, jeden vysvětluje ostatním, často sám je schopen pak chybu odhalit. Podmínkou je dobrý vztah mezi členy, vysoké pracovní nasazení.
  * **Simulace textů (čtení kódu):** u programů se simuluje chování programů; prevence, obtíže detekce defektů, dnes již částečně řeší ladící programy, ale neřeší vše.
  * **Cleanroom:** formalizovaná metoda, zahrnuje formální důkazy správnosti, při vývoji IS ne příliš efektivní, lépe tam, kde netřeba úzce jednat se zadavateli.
  * **Týdenní posezení u kafe:** pravidelné schůzky, neformální diskuse, podpora dobrých vztahů, odchycení vznikajících problémů.
  * **Oponentury zdrojových textů programů:**
    * shora/zdola/efektivně
    * systém je hierarchie daná vztahem A potřebuje B: A -> B
    * pokud je dobře navržen, bývá to hierarchický strom
    * lze se rozhodnout, že začneme od A po směru šipek (shora od kořene), vč. potomky (do šířky) nebo
    * zdola od listů (raději do šířky) nebo
    * selektivně shora/zdola se snažíme co nejdříve dostat k oponentuře problematických komponent

**Ne/výhody:**
  * shora: oponují/testují v prostředí, které se bude skutečně používat, ale menší obecnost
  * zdola: větší pracnost, obecnost, náročnost na data a předpoklady.
**U oponentur lépe postupovat shora, u testů to není tak jednoznačné.**

====== Předměty ======
  * [[https://is.muni.cz/auth/predmet/fi/podzim2011/PA102|PA102 Technologie informačních systémů I]]
  * [[https://is.muni.cz/auth/predmet/fi/jaro2011/PA105|PA105 Technologie informačních systémů II]]
  * [[https://is.muni.cz/auth/predmet/fi/podzim2011/PB007|PB007 Analýza a návrh systémů]]
  * [[https://is.muni.cz/auth/predmet/fi/jaro2011/PA103|PA103 Objektové metody návrhu informačních systémů]]
  * [[https://is.muni.cz/auth/predmet/fi/jaro2011/PA104|PA104 Vedení týmového projektu]]


====== Použitá literatura ======
  - Král, Jaroslav. 1998. Informacní systémy : specifikace, realizace, provoz. Veletiny: Science. ISBN: 80-86083-00-4.
  - Král, Jaroslav. 2008. PA102 Technologie informačních systémů I (přednášky). FI MU, Brno.
  - Král, Jaroslav. 2009. PA105 Technologie informačních systémů II (přednášky). FI MU, Brno.
  - Ráček, Jaroslav. 2011a. PB007 Analýza a návrh systémů (přednášky). FI MU, Brno. Dostupné z [[http://is.muni.cz/el/1433/podzim2011/PB007/um/27384117/]] (Jan. 2012).
  - Ráček, Jaroslav. 2011b. PA104 Vedení týmového projektu (přednášky). FI MU, Brno. Dostupné z [[http://is.muni.cz/el/1433/jaro2011/PA104/um/22859873/]] (Jan. 2012).
  - Ošlejšek, Radek. 2011. PA103 Objektové metody návrhu informačních systémů (přednášky). FI MU, Brno. Dostupné z [[https://is.muni.cz/auth/el/1433/jaro2011/PA103/um/prez/]] (Jan. 2012).
  - Software Development Life Cycle (SDLC). Dostupné z [[https://docs.google.com/viewer?a=v&q=cache:bfhOl8jp1S8J:condor.depaul.edu/~jpetlick/extra/394/Session2.ppt+&hl=en&pid=bl&srcid=ADGEEShCfW0_MLC4wRbczfUxrndHTkbwguF9fZuaUCe0RDyOCWyO2PTmaPhHnZ4jRhZZ75maVO_7gVAD2ex5-QIhrj1683hMefBNkak7FkQJCAwd-i0-_aQfEVEEKP177h4mmkvMMWJ7&sig=AHIEtbRhMlZ-TUyioKEhLQQxXk1WoSJXWA&pli=1|PowerPoint – Powered by Google Docs]] (Jan. 2012).
  - Horačková, Lenka. Vypracované otázky k IS. Dostupné z [[http://fi.muny.cz/vypracovane-otazky-statnice-is.zip-594/]] (Jan. 2012).
  - SZZ_Informacni_systemy_varianta_I.zip. FIMUNY. Dostupne z [[http://fi.muny.cz/szz-informacni-systemy-varianta-i.zip-1180/]] (Jan. 2012).

====== Přílohy ======
{{:mgr-szz:in-ins:1a.pdf|}} -- rozšíření některých témat a soukromé zpracování, vycházelo se z této wiki na přelomu roku 2013/2014. Nekonzultováno s kantory. 

====== Vypracoval ======
Ľuboš Kohút, [[https://is.muni.cz/auth/osoba/172607]], 172607@mail.muni.cz 
Aktuální stav: hotovo

Ospravedlňujem sa za moje prípadné preklepy a chyby v češtine. 

~~DISCUSSION~~