OBSAH WEBU
ČTĚTE!
Rozdíly
Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.
|
temata:30-zivotni_cyklus_softwaru:main [2011/03/16 16:46] george [Potvrzení] |
temata:30-zivotni_cyklus_softwaru:main [2016/06/06 14:45] (aktuální) xpavel27 [Modely] |
||
|---|---|---|---|
| Řádek 1: | Řádek 1: | ||
| + | ~~ODT~~ | ||
| + | |||
| ====== 30 - Životní cyklus softwaru ====== | ====== 30 - Životní cyklus softwaru ====== | ||
| Řádek 110: | Řádek 112: | ||
| === 1. Analýza a specifikace požadavků === | === 1. Analýza a specifikace požadavků === | ||
| - | * zabýváme se požadavky zákazníka => analyzujeme je => snažíme se co nejvíc pochopit zákazníka | + | * zabýváme se požadavky zákazníka => __prohlášení o cílech__ (co má systém umět, ne jak) => analyzujeme je => snažíme se co nejvíc pochopit zákazníka |
| * pozornost bychom měli věnovat především požadavkům, nikoli realizaci | * pozornost bychom měli věnovat především požadavkům, nikoli realizaci | ||
| * součástí je __studie vhodnosti__ - říká nám, zda má smysl se do projektu pouštět | * součástí je __studie vhodnosti__ - říká nám, zda má smysl se do projektu pouštět | ||
| Řádek 117: | Řádek 119: | ||
| * testy, na jejichž základě zákazník software převezme – akceptuje | * testy, na jejichž základě zákazník software převezme – akceptuje | ||
| * záruka při problémech při přebírání | * záruka při problémech při přebírání | ||
| + | * **výstupem tedy je prohlášení o cílech, studie vhodnosti a plán akceptačního testování** | ||
| - | === 2. Architektonický návrh === | + | == Analyza == |
| - | * slouží k ujasnění koncepce systému a k jeho dekompozici | + | |
| - | * vymezení funkcionality jednotlivých podsystémů | + | |
| - | * definování vztahů mezi podsystémy | + | |
| - | * zde je výstupem **plán testování celého systému** | + | |
| - | * naplánování postupu nasazení do provozu => je lepší to udělat již v této etapě, jelikož programátoři mají v hlavě informace nutné k jeho vytvoření z minulé etapy + je lepší, když už je dopředu daná určitá představa, která bude dále sloužit k odhalování problémů | + | |
| - | + | ||
| - | === 3. Podrobný návrh === | + | |
| - | * podrobná specifikace softwarových součástí | + | |
| - | * stanovení fyzické struktury dat a způsoby ošetřování neočekávaných a chybových stavů | + | |
| - | * návrh testů jednotlivých součástí včetně testovacích dat | + | |
| - | + | ||
| - | === 4. Implementace a testování součástí === | + | |
| - | * implementace jednotlivých částí | + | |
| - | * vypracování dokumentace | + | |
| - | * testování jednotlivých částí | + | |
| - | + | ||
| - | === 5. Integrace a testování systému === | + | |
| - | * spojení do jednoho celku | + | |
| - | * probíhá testování celku => odhalují se chyby spojené s integrací => případné opravování a návrat k předchozí části | + | |
| - | + | ||
| - | === 6. Akceptační testování a instalace === | + | |
| - | * otestování systému uživatelem | + | |
| - | * zákazník software převezme, případně je převzetí odloženo (po objevení závažných nedostatků) do doby napravení problémů | + | |
| - | * zde se ocení pečlivost 1. etapy | + | |
| - | * tato etapa záleží na typu softwaru (u generického zákazník může koupit software ještě před vyzkoušením, případně existují trial verze, atd...) | + | |
| - | * rozhoduje o úspěchu či neúspěchu | + | |
| - | + | ||
| - | === 7. Provoz a údržba === | + | |
| - | * vyžaduje průběžné řešení problémů a chyb, které se objevují až za běhu | + | |
| - | * tato etapa zabírá největší času a úsilí (ve skriptech uvedeno 67%) => peněz => je proto velmi důležité věnovat pozornost prvním etapám | + | |
| - | + | ||
| - | ==== Modely životního cyklu softwaru ==== | + | |
| - | + | ||
| - | * u každého projektu se jednotlivé uspořádání etap může lišit => společné rysy je možné popsat modely životního cyklu softwaru | + | |
| - | * definují jednotlivé etapy, a jejich časovou následnost | + | |
| - | * nedefinují délku trvání etap ani jejich rozsah | + | |
| - | + | ||
| - | === Vodopádový model === | + | |
| - | + | ||
| - | * jednotlivé etapy jsou řazeny za sebou | + | |
| - | * následující etapa začíná po ukončení předchozí (tak, jak jsou seřazeny v [[#Etapy životního cyklu softwaru|sekci o etapách]]) | + | |
| - | * pokud zákazník nestanoví všechny požadavky a zjistí se to až při posledních etapách, je třeba se vrátit prakticky na začátek a upravit návrh, jelikož se s tím v životním cyklu nepočítalo | + | |
| - | * neodpovídá vývoji reálných projektů, je ale lepší jak //neřízený chaos// | + | |
| - | + | ||
| - | {{:temata:30-zivotni_cyklus_softwaru:vodopadovy_model.jpeg?400|Vodopádový model životního cyklu softwaru}} | + | |
| - | + | ||
| - | === Iterativní model === | + | |
| - | + | ||
| - | * snaží se odstranit hlavní problém vodopádového modelu => proces vývoje je rozdělen do iterací, kde každá iterace je instance vodopádového modelu | + | |
| - | * po každé iteraci je k dispozici spustitelná verze s neúplnou funkcionalitou => pomůže upřesnit požadavky na software | + | |
| - | * rozdělení do iterací vede k horšímu návrhu struktury systému | + | |
| - | + | ||
| - | {{:temata:30-zivotni_cyklus_softwaru:iterativni_model.jpeg?400|Iterativní model životního cyklu softwaru}} | + | |
| - | + | ||
| - | === Inkrementální model === | + | |
| - | + | ||
| - | * podobný iterativnímu modelu | + | |
| - | * projekt je odevzdáván uživateli po částech | + | |
| - | * pozdější upřesnění požadavků může mít negativní vliv jako u vodopádového modelu | + | |
| - | + | ||
| - | === Spirálový model === | + | |
| - | * zavádí do vývoje __prototypování__ a klade značný důraz na analýzu rizik | + | |
| - | * jednotlivé etapy vývoje se opakují vždy na vyšším stupni zvládnuté problematiky => podobné jako u iterativního s tím rozdílem, že výsledkem jedné iterace není software s omezenou funkcionalitou, ale **prototyp** => po použití se zahodí a začne se vytvářet nová verze | + | |
| - | * spustitelné verze existují od začátku, takže se lépe odhalují chyby spojené s provozem | + | |
| - | * je náročný na řízení | + | |
| - | + | ||
| - | {{:temata:30-zivotni_cyklus_softwaru:spiralovy_model.jpeg?400|Spirálový model životního cyklu softwaru}} | + | |
| - | + | ||
| - | === Rational Unified Process === | + | |
| - | * na rozdíl od předchozích modelů není pouze konceptem, ale je použitelný na řízení reálných softwarových projektů | + | |
| - | * výsledkem výzkumu řady velkých firem koordinovaný firmou Rational | + | |
| - | * je založen na vývoji softwarového produktu iteračním způsobem (po každé iteraci je k dispozici spustitelný kód) | + | |
| - | * klade důraz na | + | |
| - | - vizualizaci softwarového systému (pomocí jazyka [[temata:31-uml:main|UML – Unified Modelling Language]]) | + | |
| - | - průběžnou kontrolu kvality produktu | + | |
| - | - řízení změn | + | |
| - | - využívání existujících komponent | + | |
| - | + | ||
| - | {{:temata:30-zivotni_cyklus_softwaru:rup.jpeg?400|Rational Unified Process}} | + | |
| - | + | ||
| - | === Agilní metodologie === | + | |
| - | * metodologie založené na klasických modelech životního cyklu softwaru se vyvíjely dlouhou dobu a postupem času zmohutněly => při tvorbě menších projektů spíše kvalitu výsledného produktu snížily => prodražování bez efektu => vývoj agilních metodologií | + | |
| - | * klade hlavní důraz na člověka jako určující faktor pro kvalitu výsledného produktu | + | |
| - | + | ||
| - | ===== Analýza a specifikace požadavků ===== | + | |
| * velmi důležitá etapa => čas strávený v této etapě se pak odrazí v dalších etapách => odhalení chyb v pozdějších etapách stojí více času a peněz | * velmi důležitá etapa => čas strávený v této etapě se pak odrazí v dalších etapách => odhalení chyb v pozdějších etapách stojí více času a peněz | ||
| * důraz je kladen především na požadavky, nikoli na implementaci | * důraz je kladen především na požadavky, nikoli na implementaci | ||
| Řádek 215: | Řádek 132: | ||
| - naplánovat akceptačního testování | - naplánovat akceptačního testování | ||
| - | ==== Typy požadavků ==== | + | - **strukturovaná analýza** - chápe systém jako kolekci funkcí (procesů) operujících nad daty, tj. pracujeme (navrhujeme) strukturu dat a funkce pracující s těmito daty |
| + | - **objektová analýza** - chápe systém jako kolekci vzájemně komunikujících objektů, tj. data a funkce pracující s těmito daty jsou spolu svázány | ||
| + | == Typy požadavků == | ||
| * mohou být různorodé, nemusí vždy souviset pouze s tím, co je nutné naprogramovat | * mohou být různorodé, nemusí vždy souviset pouze s tím, co je nutné naprogramovat | ||
| * důležitá vlastnost požadavků je __měřitelnost__ (pouze u měřitelných požadavků jsme schopni určit, zda je aplikace splňuje) | * důležitá vlastnost požadavků je __měřitelnost__ (pouze u měřitelných požadavků jsme schopni určit, zda je aplikace splňuje) | ||
| Řádek 227: | Řádek 147: | ||
| - __externí požadavky__ - požadavky vyplývající s charakteru aplikace (např. legislativní požadavky) | - __externí požadavky__ - požadavky vyplývající s charakteru aplikace (např. legislativní požadavky) | ||
| - | ==== Specifikace požadavků ==== | ||
| - | <note tip>__//špatná specifikace požadavků = špatný výsledek práce//__</note> | + | == Specifikace == |
| * **metody získávání požadavků** | * **metody získávání požadavků** | ||
| Řádek 264: | Řádek 183: | ||
| - relace ''<<extend>>'' - nějaký úkon v sobě zahrnuje nepovinně jiný (vrácení knihy => <<extend>>) | - relace ''<<extend>>'' - nějaký úkon v sobě zahrnuje nepovinně jiný (vrácení knihy => <<extend>>) | ||
| * __slovníky pojmů__ | * __slovníky pojmů__ | ||
| - | |||
| - | <note tip>**Toto téma značně zasahuje do [[temata:31-uml:main|UML]]**</note> | ||
| * **prostředky pro analýzu v RUP:** | * **prostředky pro analýzu v RUP:** | ||
| Řádek 275: | Řádek 192: | ||
| - __[[http://mpavus.wz.cz/uml/uml-b-activity-3-2-3.php|diagramy aktivit]]__ | - __[[http://mpavus.wz.cz/uml/uml-b-activity-3-2-3.php|diagramy aktivit]]__ | ||
| - | ==== Strukturovaná analýza ==== | + | == Modely == |
| - | + | ||
| - | <note> | + | |
| - | - **strukturovaná analýza** - chápe systém jako kolekci funkcí (procesů) operujících nad daty, tj. pracujeme (navrhujeme) strukturu dat a funkce pracující s těmito daty | + | |
| - | - **objektová analýza** - chápe systém jako kolekci vzájemně komunikujících objektů, tj. data a funkce pracující s těmito daty jsou spolu svázány | + | |
| - | </note> | + | |
| - | + | ||
| - | * **základní modely:** | + | |
| - __funkční modelování__ | - __funkční modelování__ | ||
| * ukazuje: | * ukazuje: | ||
| Řádek 298: | Řádek 208: | ||
| * stavový diagram, který zachycuje stavy, ve kterých se systém (či jeho část) může nacházet | * stavový diagram, který zachycuje stavy, ve kterých se systém (či jeho část) může nacházet | ||
| - | ===== Návrh ===== | + | |
| + | |||
| + | === 2. Architektonický návrh === | ||
| + | * slouží k ujasnění koncepce systému a k jeho dekompozici | ||
| + | * vymezení funkcionality jednotlivých podsystémů | ||
| + | * definování vztahů mezi podsystémy | ||
| + | * naplánování postupu nasazení do provozu => je lepší to udělat již v této etapě, jelikož programátoři mají v hlavě informace nutné k jeho vytvoření z minulé etapy + je lepší, když už je dopředu daná určitá představa, která bude dále sloužit k odhalování problémů | ||
| + | * **zde je výstupem specifikační dokument a plán testování celého systému** | ||
| * dobrý návrh je podmínkou úspěšné tvorby softwaru a minimalizuje náklady spojené s implementací a posléze i údržbou softwarového produktu | * dobrý návrh je podmínkou úspěšné tvorby softwaru a minimalizuje náklady spojené s implementací a posléze i údržbou softwarového produktu | ||
| * **výstupem etapy jsou většinou tyto diagramy:** | * **výstupem etapy jsou většinou tyto diagramy:** | ||
| Řádek 312: | Řádek 230: | ||
| * odděluje specifikaci funkčnosti od její implementace | * odděluje specifikaci funkčnosti od její implementace | ||
| - | ===== Implementace a testování ===== | + | |
| + | |||
| + | === 3. Podrobný návrh === | ||
| + | * podrobná specifikace softwarových součástí | ||
| + | * stanovení fyzické struktury dat a způsoby ošetřování neočekávaných a chybových stavů | ||
| + | * návrh testů jednotlivých součástí včetně testovacích dat | ||
| + | * **zde je výstupem návrhový dokument** | ||
| + | |||
| + | === 4. Implementace a testování součástí === | ||
| + | * implementace jednotlivých částí | ||
| + | * vypracování dokumentace | ||
| + | * testování jednotlivých částí | ||
| + | * **zde jsou výsledkem naimplementované jednotlivé části** | ||
| * //implementace softwaru je transformace návrhu jednotlivých modulů a jejich vzájemných vazeb do programové realizace// | * //implementace softwaru je transformace návrhu jednotlivých modulů a jejich vzájemných vazeb do programové realizace// | ||
| * **úkony před implementací:** | * **úkony před implementací:** | ||
| Řádek 327: | Řádek 258: | ||
| - //dynamické = testování:// - výsledky se odvozují na základě běhu programu (výstupů) | - //dynamické = testování:// - výsledky se odvozují na základě běhu programu (výstupů) | ||
| - | {{:temata:30-zivotni_cyklus_softwaru:overovani.jpeg?600|Statické a dynamické ověřování}} | + | {{:temata:30-zivotni_cyklus_softwaru:overovani.jpeg?400|Statické a dynamické ověřování}} |
| * **testování** | * **testování** | ||
| Řádek 337: | Řádek 268: | ||
| * __typy:__ | * __typy:__ | ||
| - náhodné - generátor pseudonáhodných čísel | - náhodné - generátor pseudonáhodných čísel | ||
| - | - funkcionální - vychází pouze ze specifikace a neuvažuje se vnitřní struktura programu | + | - funkcionální - vychází pouze ze specifikace a neuvažuje se vnitřní struktura programu - //metoda černé skříňky// |
| - strukturální - vychází z vnitřní struktury programu - //metoda bíle skříňky// | - strukturální - vychází z vnitřní struktury programu - //metoda bíle skříňky// | ||
| * test, co neodhalí chybu chování systému, je neúspěšný | * test, co neodhalí chybu chování systému, je neúspěšný | ||
| - | {{:temata:30-zivotni_cyklus_softwaru:testovani.jpeg?600|Proces testování}} | + | {{:temata:30-zivotni_cyklus_softwaru:testovani.jpeg?400|Proces testování }} |
| + | |||
| + | |||
| + | === 5. Integrace a testování systému === | ||
| + | * spojení do jednoho celku | ||
| + | * probíhá testování celku => odhalují se chyby spojené s integrací => případné opravování a návrat k předchozí části | ||
| + | * **zde je výsledkem celkový systém** | ||
| + | |||
| + | === 6. Akceptační testování a instalace === | ||
| + | * otestování systému uživatelem | ||
| + | * zákazník software převezme, případně je převzetí odloženo (po objevení závažných nedostatků) do doby napravení problémů | ||
| + | * zde se ocení pečlivost 1. etapy | ||
| + | * tato etapa záleží na typu softwaru (u generického zákazník může koupit software ještě před vyzkoušením, případně existují trial verze, atd...) | ||
| + | * rozhoduje o úspěchu či neúspěchu | ||
| + | |||
| + | === 7. Provoz a údržba === | ||
| + | * vyžaduje průběžné řešení problémů a chyb, které se objevují až za běhu | ||
| + | * tato etapa zabírá největší času a úsilí (ve skriptech uvedeno 67%) => peněz => je proto velmi důležité věnovat pozornost prvním etapám | ||
| + | ==== Modely životního cyklu softwaru ==== | ||
| + | |||
| + | * u každého projektu se jednotlivé uspořádání etap může lišit => společné rysy je možné popsat modely životního cyklu softwaru | ||
| + | * definují jednotlivé etapy, a jejich časovou následnost | ||
| + | * nedefinují délku trvání etap ani jejich rozsah | ||
| + | |||
| + | === Vodopádový model === | ||
| + | |||
| + | * jednotlivé etapy jsou řazeny za sebou | ||
| + | * následující etapa začíná po ukončení předchozí (tak, jak jsou seřazeny v [[#Etapy životního cyklu softwaru|sekci o etapách]]) | ||
| + | * pokud zákazník nestanoví všechny požadavky a zjistí se to až při posledních etapách, je třeba se vrátit prakticky na začátek a upravit návrh, jelikož se s tím v životním cyklu nepočítalo | ||
| + | * neodpovídá vývoji reálných projektů, je ale lepší jak //neřízený chaos// | ||
| + | |||
| + | {{:temata:30-zivotni_cyklus_softwaru:vodopadovy_model.jpeg?400|Vodopádový model životního cyklu softwaru}} | ||
| + | |||
| + | === Iterativní model === | ||
| + | |||
| + | * snaží se odstranit hlavní problém vodopádového modelu => proces vývoje je rozdělen do iterací, kde každá iterace je instance vodopádového modelu | ||
| + | * po každé iteraci je k dispozici spustitelná verze s neúplnou funkcionalitou => pomůže upřesnit požadavky na software | ||
| + | * rozdělení do iterací vede k horšímu návrhu struktury systému | ||
| + | |||
| + | {{:temata:30-zivotni_cyklus_softwaru:iterativni_model.jpeg?400|Iterativní model životního cyklu softwaru}} | ||
| + | |||
| + | === Inkrementální model === | ||
| + | |||
| + | * podobný iterativnímu modelu | ||
| + | * projekt je odevzdáván uživateli po částech | ||
| + | * pozdější upřesnění požadavků může mít negativní vliv jako u vodopádového modelu | ||
| + | |||
| + | === Spirálový model === | ||
| + | * zavádí do vývoje __prototypování__ a klade značný důraz na analýzu rizik | ||
| + | * jednotlivé etapy vývoje se opakují vždy na vyšším stupni zvládnuté problematiky => podobné jako u iterativního s tím rozdílem, že výsledkem jedné iterace není software s omezenou funkcionalitou, ale **prototyp** => po použití se zahodí a začne se vytvářet nová verze | ||
| + | * spustitelné verze existují od začátku, takže se lépe odhalují chyby spojené s provozem | ||
| + | * je náročný na řízení | ||
| + | |||
| + | {{:temata:30-zivotni_cyklus_softwaru:spiralovy_model.jpeg?400|Spirálový model životního cyklu softwaru}} | ||
| + | |||
| + | === Vmodel === | ||
| + | {{:temata:30-zivotni_cyklus_softwaru:Vmodel.jpg?400}} | ||
| + | |||
| + | === Rational Unified Process === | ||
| + | * na rozdíl od předchozích modelů není pouze konceptem, ale je použitelný na řízení reálných softwarových projektů | ||
| + | * výsledkem výzkumu řady velkých firem koordinovaný firmou Rational | ||
| + | * je založen na vývoji softwarového produktu iteračním způsobem (po každé iteraci je k dispozici spustitelný kód) | ||
| + | * klade důraz na | ||
| + | - vizualizaci softwarového systému (pomocí jazyka [[temata:31-uml:main|UML – Unified Modelling Language]]) | ||
| + | - průběžnou kontrolu kvality produktu | ||
| + | - řízení změn | ||
| + | - využívání existujících komponent | ||
| + | |||
| + | {{:temata:30-zivotni_cyklus_softwaru:rup.jpeg?400|Rational Unified Process}} | ||
| + | |||
| + | === Agilní metodologie === | ||
| + | * metodologie založené na klasických modelech životního cyklu softwaru se vyvíjely dlouhou dobu a postupem času zmohutněly => při tvorbě menších projektů spíše kvalitu výsledného produktu snížily => prodražování bez efektu => vývoj agilních metodologií | ||
| + | * klade hlavní důraz na člověka jako určující faktor pro kvalitu výsledného produktu | ||
| + | |||
| + | * **Extrémní programování (XP)** | ||
| + | * propaguje časté dodávky software v krátkých vývojových cyklech | ||
| + | * programovat jen to, co je v danou chvíli nezbytné, jednoduchý a jasný kód | ||
| + | * společné vlastnictví kódu a neustálý refaktoring | ||
| + | * Vývojáři by měli počítat se změnami požadavků v průběhu času | ||
| + | * Důležitá je častá komunikace se zákazníkem i mezi programátory. | ||
| + | |||
| + | * ** Scrum ** | ||
| + | * Klíčovou částí metodiky jsou každodenní krátká setkání týmu, nazývaná scrum | ||
| + | * Každý člen zde referuje o své činnosti z minulého dne, o tom, co bude dělat dnes, a na jaké problémy narazil. | ||
| + | * Metodika prosazuje iterativní vývoj. Období iterace se nazývá Sprint a trvá 2-4 týdny. | ||
| + | * Výsledkem Sprintu je demo vzniklých úprav, které je předvedeno zákazníkovi | ||
| + | * Ten poskytne zpětnou vazbu, což umožňuje rychle reagovat na změny v požadavcích | ||
| + | * Product Owner má za úkol komunikovat se zákazníkem. | ||
| + | * Správné fungování vývojového týmu zajišťuje Scrum Master | ||
| + | * Člen vývojového týmu se nazývá Scrum Team Member | ||
| + | |||
| + | * **Vývoj řízený vlastnostmi (FDD – Feature Driven Development)** | ||
| + | * FDD začíná vytvořením doménového modelu popisujícího celý systém | ||
| + | * Ten se převede do seznamu vlastností (elementární funkcionality, které přináší hodnotu uživateli) | ||
| + | * Během každé iterace se implementují konkrétní užitné vlastnosti systému. | ||
| + | * Zákazník průběžně dostává mezivýsledky a nové verze produktu. | ||
| + | * Na rozdíl od XP nebo SCRUM je jednotlivým programátorům práce přidělena – nevybírají si ji sami. | ||
| + | |||
| + | * **Vývoj řízený testy (TDD – Test Driven Development)** | ||
| + | * TDD navrhuje psaní testů před samotným kódem a následně naprogramovat samotný kód. | ||
| + | * Implementuje se přesně takové množství kódu, jaké dokáže projít testem | ||
| + | |||
| + | |||
| + | |||
| ===== Zdroj ===== | ===== Zdroj ===== | ||
