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

„Software Development Life Cycle Model – framework that describes the activities performed at each stage of a software development project.“¹⁾

„Životní cyklus SW popisuje život SW od jeho návrhu, přes implementaci, až po jeho předání a údržbu.“²⁾

• 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

• 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

• 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%

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í

• 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)

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

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í

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.

• 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)

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

• 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)

• neformální specifikace
• formální specifikace
  • funkční požadavky
  • nefunkční požadavky
• uživatelský vzhled aplikace
• oponenturou je feasibility study (uskutečnitelnost)

• 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 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

• balíčky s kódem
• plán testování jednotek
• revize kódu jako oponentura, čtení, inspekce

• 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řejímací testování (akceptační testy)
• konečný systém a dokumentace
• předávací protokol

• chybové výstupy aplikace
• sběr uživatelských požadavků a postřehů

• 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í

• 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í

• 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

• 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ě.

• obsahují nástroje na podporu kódování, testování a údržby a reverzního inženýrství

• 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

1. Pre-CASE: plánování
2. Upper-CASE: specifikace požadavku
3. Middle-CASE: kooperace při návrhu
4. Lower-CASE: návrh a vývoj
5. Post-CASE: údržba, modifikace

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:

1. název projektu a identifikátor projektu
2. úvod - shrnutí úkolů v obecně srozumitelné rovině
3. vymezení uživatelů a způsobu využití produktu
4. perspektivy realizovaného systému (doba života,…)
5. způsob vedení dokumentace
6. zajištění spolupráce mezi dodavatelem a uživatelem
7. dokumenty odkazované v textu
8. použité zkratky a slovník
9. vazby na jiné projekty
10. požadavky na HW, efektivnost a spolehlivost
11. rozpis dat a funkcí - dekompozice systému
12. plán testů
13. vymezení obsahu dokumentace předávané uživateli
14. termíny realizace, plán realizace
15. ekonomické a organizační zajištění (odhad nákladů, řešitelský tým)
16. vymezení způsobu údržby a způsobu prodeje produktu dalším uživatelům

• 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)

1. 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.
2. Strukturované interview: interview, kde se postupně odpovídá na otázky dle předem připraveného dotazníku.
3. Dotazníky: rozesílají se, uživatelé vyplní sami. Levné, ale nezjistí se vše.
4. Studium dokumentů: používaných zákazníkem.
5. Pozorování chodu prací u zákazníka: drahé, zdlouhavé, ruší při práci.
6. Účast na pracovním procesu: totéž co výše, někdy se neodchytí výjimečné případy.
7. Analýza existujícího IS: nebezpečí převzetí chyb původního IS.
8. 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,…).

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

1. 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í.
2. Neúplný: modeluje pouze některé funkce.
3. Jiný kůň: téměř úplný, ale funguje na jiném HW nebo nad jiným základním SW
4. Hlemýžď: neefektivní, pomalý
5. Nepříjemný: má nepříjemné uživatelské rozhraní, je nestabilní
6. Lajdák: nereaguje správně na chyby v datech a chyby obsluhy

• 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ů.

• 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.

• kontrolní akce prováděné členy řešitelského týmu
• druhy oponentur se liší úrovní formalizace a počtem účastníků

• úč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

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

1. plánování (moderátor), příprava materiálů, výběr členů, termín,…
2. úvodní studium (účastnící se školí, stanoví se jim role)
3. příprava (materiály pár dní dopředu, studium materiálů)
4. inspekce (pod vedením moderátora, zjišťují se chyby)
5. vypracuje se zápis (data do DBS)
6. přepracování (oprava materiálů)
7. 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

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:

1. 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í, …
2. 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

• méně formální než inspekce, lze použít na větší celky

Etapy revize:

1. určí se moderátor, ten si vybere oponenty
2. každý oponent dostane k analýze určitou část oponovaného materiálu a snaží se nalézt problematická místa
3. 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)
4. 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í.

• 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é.

• PA102 Technologie informačních systémů I
• PA105 Technologie informačních systémů II
• PB007 Analýza a návrh systémů
• PA103 Objektové metody návrhu informačních systémů
• PA104 Vedení týmového projektu

1. Král, Jaroslav. 1998. Informacní systémy : specifikace, realizace, provoz. Veletiny: Science. ISBN: 80-86083-00-4.
2. Král, Jaroslav. 2008. PA102 Technologie informačních systémů I (přednášky). FI MU, Brno.
3. Král, Jaroslav. 2009. PA105 Technologie informačních systémů II (přednášky). FI MU, Brno.
4. 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).
5. 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).
6. 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).
7. Software Development Life Cycle (SDLC). Dostupné z PowerPoint – Powered by Google Docs (Jan. 2012).
8. Horačková, Lenka. Vypracované otázky k IS. Dostupné z http://fi.muny.cz/vypracovane-otazky-statnice-is.zip-594/ (Jan. 2012).
9. SZZ_Informacni_systemy_varianta_I.zip. FIMUNY. Dostupne z http://fi.muny.cz/szz-informacni-systemy-varianta-i.zip-1180/ (Jan. 2012).

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.

Ľ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.