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 [2016/05/27 15:18] xpavel27 [Modely životního cyklu softwaru] |
temata:30-zivotni_cyklus_softwaru:main [2016/06/06 14:45] (aktuální) xpavel27 [Modely] |
||
|---|---|---|---|
| Řádek 120: | Řádek 120: | ||
| * 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í** | * **výstupem tedy je prohlášení o cílech, studie vhodnosti a plán akceptačního testování** | ||
| + | |||
| + | == Analyza == | ||
| + | * 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 | ||
| + | * **smyslem této etapy je především** | ||
| + | - získat, analyzovat a definovat požadavky | ||
| + | - transformovat neformální požadavky uživatele do strukturovaného popisu požadavků | ||
| + | - provést studii vhodnosti, identifikovat a analyzovat rizik | ||
| + | * musíme mít na zřeteli i způsob řešení => jeden projekt může mít více alternativ řešení | ||
| + | * náš projekt bude používat více uživatelů, kde každý může mít jiný názor na uživatelské rozhraní | ||
| + | - naplánovat akceptačního testování | ||
| + | |||
| + | - **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 | ||
| + | * 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) | ||
| + | * **jednotlivé kategorie požadavků:** | ||
| + | - __funkcionální požadavky__ - co má projekt dělat | ||
| + | - __požadavky na provoz systému__ - podmínky za jakých bude systém pracovat | ||
| + | - __požadavky na výsledný systém__ - podmínky pro vývoj a nasazení - počítačové vybavení, programové vybavení, spolehlivost, odolnost vůči chybám | ||
| + | - __požadavky na vývojový proces__ - požadavky zákazníka na dodržování norem během vývoje a předání systému | ||
| + | - __požadavky na rozhraní__ - komunikace se systémem | ||
| + | - __externí požadavky__ - požadavky vyplývající s charakteru aplikace (např. legislativní požadavky) | ||
| + | |||
| + | |||
| + | == Specifikace == | ||
| + | |||
| + | * **metody získávání požadavků** | ||
| + | * interview | ||
| + | * dotazníky | ||
| + | * studium dokumentů | ||
| + | * pozorování prací u zákazníka | ||
| + | * přímá účast na pracích zákazníka | ||
| + | * analýza existujícího softwarového systému | ||
| + | * **problémy při získávání informací** | ||
| + | * problémy plynoucí z použití přirozeného jazyka (vyřazení, deformace, zkreslení, zobecnění) | ||
| + | * zákazník nemá přesnou představu | ||
| + | * zákazník se neorientuje v problematice softwaru a vývojář se neorientuje v problematice zákazníka | ||
| + | * rozhodování, jaké požadavky už nezačleňovat do specifikace | ||
| + | * **kroky při specifikaci požadavků** | ||
| + | * studie vhodnosti - prvotní odhad, zda jsme schopni zvládnout práci (čas, cena, rozsah) | ||
| + | * analýza požadavků - zkoumání požadavků zákazníka | ||
| + | * definování požadavků - transformace analyzovaných informací do textové podoby pro zákazníka a uživatele | ||
| + | * specifikace požadavků - transformace analyzovaných získaných informací do formální podoby pro vývojáře | ||
| + | * specifikace softwaru | ||
| + | * **prostředky pro specifikaci požadavků v RUP** | ||
| + | * __diagramy případů užití (Use cases)__ | ||
| + | * součástí UML | ||
| + | * definují se účastníci systému a jejich role | ||
| + | * __detaily případů užití__ | ||
| + | * podrobnější popis use case diagramů | ||
| + | * znázorněno tabulkou | ||
| + | * možnosti definování alternativních kroků (co se stane, když ...) | ||
| + | * __specifikace (strukturovaný text)__ | ||
| + | * rozšíření use case diagramů o pokročilé techniky zlepšující přehlednost | ||
| + | - zobecnění účastníka - generalizace/specializace účastníků | ||
| + | - zobecnění případů užití - generalizace/specializace rolí (úkonů) účastníků | ||
| + | - relace ''<<include>>'' - nějaký úkon v sobě zahrnuje jiný (změna položky => <<include>> => vyhledání položky) | ||
| + | - relace ''<<extend>>'' - nějaký úkon v sobě zahrnuje nepovinně jiný (vrácení knihy => <<extend>>) | ||
| + | * __slovníky pojmů__ | ||
| + | |||
| + | * **prostředky pro analýzu v RUP:** | ||
| + | - __[[http://mpavus.wz.cz/uml/uml-s-class-3-3-1.php|analytické třídy]]__ - mapují pojmy problémové domény na abstraktní entity modelu – třídy | ||
| + | - __objektové diagramy__ - zachycují konkrétní instance tříd a jejich vazby v určitém čase či podmínce | ||
| + | - __analytické balíčky__ - seskupují sémanticky související elementy a definují hranice tohoto seskupení | ||
| + | - __[[http://mpavus.wz.cz/uml/uml-b-intover-3-2-6.php|diagramy interakce]]__ - reprezentují vztahy mezi objekty | ||
| + | - __[[http://mpavus.wz.cz/uml/uml-b-sequence-3-2-4.php|sekvenční diagramy]]__ - reprezentují časově orientovanou posloupnost předávání zpráv mezi objekty | ||
| + | - __[[http://mpavus.wz.cz/uml/uml-b-activity-3-2-3.php|diagramy aktivit]]__ | ||
| + | |||
| + | == Modely == | ||
| + | - __funkční modelování__ | ||
| + | * ukazuje: | ||
| + | * funkce systému | ||
| + | * toky dat mezi systémem a okolím | ||
| + | * toky dat mezi funkcemi systému | ||
| + | * data ukládaná v systému | ||
| + | * základním modelem je [[http://en.wikipedia.org/wiki/Data_Flow_Diagram|DFD - Data Flow Diagram]] | ||
| + | - __datové modelování__ | ||
| + | * ukazuje entity aplikační domény zpracovávané systémem a statické vztahy mezi nimi (typicky perzistentní data ukládaná v databázi) | ||
| + | * typickým modelem je diagram vztahů a entit: [[http://en.wikipedia.org/wiki/Entity_Relationship_Diagram|ERD - Entity Relationship Diagram]] | ||
| + | - __datový slovník__ | ||
| + | * obsahuje specifikace prvků modelů, notace pro specifikaci informačního obsahu prvků DFD a ERD | ||
| + | - __modelování dynamického chování__ | ||
| + | * stavový diagram, který zachycuje stavy, ve kterých se systém (či jeho část) může nacházet | ||
| + | |||
| + | |||
| === 2. Architektonický návrh === | === 2. Architektonický návrh === | ||
| Řádek 127: | Řádek 216: | ||
| * 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ů | * 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** | * **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 | ||
| + | * **výstupem etapy jsou většinou tyto diagramy:** | ||
| + | - __doplněné (upřesněné) analytické diagramy__ - diagramy interakce | ||
| + | - __diagramy upřesňující vybrané analytické diagramy__ | ||
| + | * __návrhové třídy__ | ||
| + | * vycházejí z analytických tříd | ||
| + | * doplňují implementačně důležité vlastnosti (proměnné, metody) | ||
| + | * lze je přímo implementovat | ||
| + | * __návrhové podsystémy__ | ||
| + | * __[[http://mpavus.wz.cz/uml/uml-b-state-3-2-2.php|stavové diagramy]]__ | ||
| + | * __rozhraní__ | ||
| + | * odděluje specifikaci funkčnosti od její implementace | ||
| + | |||
| + | |||
| === 3. Podrobný návrh === | === 3. Podrobný návrh === | ||
| Řádek 139: | Řádek 243: | ||
| * testování jednotlivých částí | * testování jednotlivých částí | ||
| * **zde jsou výsledkem naimplementované jednotlivé části** | * **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// | ||
| + | * **úkony před implementací:** | ||
| + | * výběr implementačního jazyka | ||
| + | * strategie implementace | ||
| + | - //zdola-nahoru// - od nejnižší úrovně po největší celky (moduly nižší úrovně lze dále použít ve vyšších úrovních **x** chyby v logice se projeví až při integrování modulů) | ||
| + | - //shora-dolů// - (systém lze brzy demonstrovat a nejzávažnější chyby jsou odhaleny včas **x** logika systému se ověřuje několikrát, pro testování jsou třeba speciální moduly, které simulují práci podsystému) | ||
| + | * **validace a verifikace programu:** | ||
| + | * __validace__ - ověření, že vyvíjený software splňuje potřeby uživatele | ||
| + | * __verifikace__ - ověření, zda software vyhovuje specifikaci | ||
| + | * __ověřujeme různé vlastnosti:__ správnost, spolehlivost, efektivnost či bezpečnost | ||
| + | * __typy ověřování:__ | ||
| + | - //statické:// - nevyžaduje běh programu (libovolná etapa vývoje) | ||
| + | - //dynamické = testování:// - výsledky se odvozují na základě běhu programu (výstupů) | ||
| + | |||
| + | {{:temata:30-zivotni_cyklus_softwaru:overovani.jpeg?400|Statické a dynamické ověřování}} | ||
| + | |||
| + | * **testování** | ||
| + | * odhalování chyb během vývoje | ||
| + | * důležité volit dobré vstupy | ||
| + | * __testovací kritérium:__ | ||
| + | - spolehlivé - nezáleží, jakou množinu vstupů vezmeme, vždy dostaneme stejný výsledek | ||
| + | - platné - když pro každou chybu v programu existuje množina testovacích vstupů, která splňuje toto kritérium a která chybu odhalí | ||
| + | * __typy:__ | ||
| + | - náhodné - generátor pseudonáhodných čísel | ||
| + | - 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// | ||
| + | * test, co neodhalí chybu chování systému, je neúspěšný | ||
| + | |||
| + | {{:temata:30-zivotni_cyklus_softwaru:testovani.jpeg?400|Proces testování }} | ||
| + | |||
| === 5. Integrace a testování systému === | === 5. Integrace a testování systému === | ||
| Řádek 155: | Řádek 290: | ||
| * vyžaduje průběžné řešení problémů a chyb, které se objevují až za běhu | * 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 | * 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 ==== | ==== Modely životního cyklu softwaru ==== | ||
| Řádek 240: | Řádek 374: | ||
| * Implementuje se přesně takové množství kódu, jaké dokáže projít testem | * Implementuje se přesně takové množství kódu, jaké dokáže projít testem | ||
| - | ===== 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 | ||
| - | * důraz je kladen především na požadavky, nikoli na implementaci | ||
| - | * **smyslem této etapy je především** | ||
| - | - získat, analyzovat a definovat požadavky | ||
| - | - transformovat neformální požadavky uživatele do strukturovaného popisu požadavků | ||
| - | - provést studii vhodnosti, identifikovat a analyzovat rizik | ||
| - | * musíme mít na zřeteli i způsob řešení => jeden projekt může mít více alternativ řešení | ||
| - | * náš projekt bude používat více uživatelů, kde každý může mít jiný názor na uživatelské rozhraní | ||
| - | - naplánovat akceptačního testování | ||
| - | ==== Typy požadavků ==== | ||
| - | |||
| - | * 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) | ||
| - | * **jednotlivé kategorie požadavků:** | ||
| - | - __funkcionální požadavky__ - co má projekt dělat | ||
| - | - __požadavky na provoz systému__ - podmínky za jakých bude systém pracovat | ||
| - | - __požadavky na výsledný systém__ - podmínky pro vývoj a nasazení - počítačové vybavení, programové vybavení, spolehlivost, odolnost vůči chybám | ||
| - | - __požadavky na vývojový proces__ - požadavky zákazníka na dodržování norem během vývoje a předání systému | ||
| - | - __požadavky na rozhraní__ - komunikace se systémem | ||
| - | - __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> | ||
| - | |||
| - | * **metody získávání požadavků** | ||
| - | * interview | ||
| - | * dotazníky | ||
| - | * studium dokumentů | ||
| - | * pozorování prací u zákazníka | ||
| - | * přímá účast na pracích zákazníka | ||
| - | * analýza existujícího softwarového systému | ||
| - | * **problémy při získávání informací** | ||
| - | * problémy plynoucí z použití přirozeného jazyka (vyřazení, deformace, zkreslení, zobecnění) | ||
| - | * zákazník nemá přesnou představu | ||
| - | * zákazník se neorientuje v problematice softwaru a vývojář se neorientuje v problematice zákazníka | ||
| - | * rozhodování, jaké požadavky už nezačleňovat do specifikace | ||
| - | * **kroky při specifikaci požadavků** | ||
| - | * studie vhodnosti - prvotní odhad, zda jsme schopni zvládnout práci (čas, cena, rozsah) | ||
| - | * analýza požadavků - zkoumání požadavků zákazníka | ||
| - | * definování požadavků - transformace analyzovaných informací do textové podoby pro zákazníka a uživatele | ||
| - | * specifikace požadavků - transformace analyzovaných získaných informací do formální podoby pro vývojáře | ||
| - | * specifikace softwaru | ||
| - | * **prostředky pro specifikaci požadavků v RUP** | ||
| - | * __diagramy případů užití (Use cases)__ | ||
| - | * součástí UML | ||
| - | * definují se účastníci systému a jejich role | ||
| - | * __detaily případů užití__ | ||
| - | * podrobnější popis use case diagramů | ||
| - | * znázorněno tabulkou | ||
| - | * možnosti definování alternativních kroků (co se stane, když ...) | ||
| - | * __specifikace (strukturovaný text)__ | ||
| - | * rozšíření use case diagramů o pokročilé techniky zlepšující přehlednost | ||
| - | - zobecnění účastníka - generalizace/specializace účastníků | ||
| - | - zobecnění případů užití - generalizace/specializace rolí (úkonů) účastníků | ||
| - | - relace ''<<include>>'' - nějaký úkon v sobě zahrnuje jiný (změna položky => <<include>> => vyhledání položky) | ||
| - | - relace ''<<extend>>'' - nějaký úkon v sobě zahrnuje nepovinně jiný (vrácení knihy => <<extend>>) | ||
| - | * __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:** | ||
| - | - __[[http://mpavus.wz.cz/uml/uml-s-class-3-3-1.php|analytické třídy]]__ - mapují pojmy problémové domény na abstraktní entity modelu – třídy | ||
| - | - __objektové diagramy__ - zachycují konkrétní instance tříd a jejich vazby v určitém čase či podmínce | ||
| - | - __analytické balíčky__ - seskupují sémanticky související elementy a definují hranice tohoto seskupení | ||
| - | - __[[http://mpavus.wz.cz/uml/uml-b-intover-3-2-6.php|diagramy interakce]]__ - reprezentují vztahy mezi objekty | ||
| - | - __[[http://mpavus.wz.cz/uml/uml-b-sequence-3-2-4.php|sekvenční diagramy]]__ - reprezentují časově orientovanou posloupnost předávání zpráv mezi objekty | ||
| - | - __[[http://mpavus.wz.cz/uml/uml-b-activity-3-2-3.php|diagramy aktivit]]__ | ||
| - | |||
| - | ==== Strukturovaná analýza ==== | ||
| - | |||
| - | <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í__ | ||
| - | * ukazuje: | ||
| - | * funkce systému | ||
| - | * toky dat mezi systémem a okolím | ||
| - | * toky dat mezi funkcemi systému | ||
| - | * data ukládaná v systému | ||
| - | * základním modelem je [[http://en.wikipedia.org/wiki/Data_Flow_Diagram|DFD - Data Flow Diagram]] | ||
| - | - __datové modelování__ | ||
| - | * ukazuje entity aplikační domény zpracovávané systémem a statické vztahy mezi nimi (typicky perzistentní data ukládaná v databázi) | ||
| - | * typickým modelem je diagram vztahů a entit: [[http://en.wikipedia.org/wiki/Entity_Relationship_Diagram|ERD - Entity Relationship Diagram]] | ||
| - | - __datový slovník__ | ||
| - | * obsahuje specifikace prvků modelů, notace pro specifikaci informačního obsahu prvků DFD a ERD | ||
| - | - __modelování dynamického chování__ | ||
| - | * stavový diagram, který zachycuje stavy, ve kterých se systém (či jeho část) může nacházet | ||
| - | |||
| - | ===== Návrh ===== | ||
| - | * 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:** | ||
| - | - __doplněné (upřesněné) analytické diagramy__ - diagramy interakce | ||
| - | - __diagramy upřesňující vybrané analytické diagramy__ | ||
| - | * __návrhové třídy__ | ||
| - | * vycházejí z analytických tříd | ||
| - | * doplňují implementačně důležité vlastnosti (proměnné, metody) | ||
| - | * lze je přímo implementovat | ||
| - | * __návrhové podsystémy__ | ||
| - | * __[[http://mpavus.wz.cz/uml/uml-b-state-3-2-2.php|stavové diagramy]]__ | ||
| - | * __rozhraní__ | ||
| - | * odděluje specifikaci funkčnosti od její implementace | ||
| - | |||
| - | ===== Implementace a testování ===== | ||
| - | * //implementace softwaru je transformace návrhu jednotlivých modulů a jejich vzájemných vazeb do programové realizace// | ||
| - | * **úkony před implementací:** | ||
| - | * výběr implementačního jazyka | ||
| - | * strategie implementace | ||
| - | - //zdola-nahoru// - od nejnižší úrovně po největší celky (moduly nižší úrovně lze dále použít ve vyšších úrovních **x** chyby v logice se projeví až při integrování modulů) | ||
| - | - //shora-dolů// - (systém lze brzy demonstrovat a nejzávažnější chyby jsou odhaleny včas **x** logika systému se ověřuje několikrát, pro testování jsou třeba speciální moduly, které simulují práci podsystému) | ||
| - | * **validace a verifikace programu:** | ||
| - | * __validace__ - ověření, že vyvíjený software splňuje potřeby uživatele | ||
| - | * __verifikace__ - ověření, zda software vyhovuje specifikaci | ||
| - | * __ověřujeme různé vlastnosti:__ správnost, spolehlivost, efektivnost či bezpečnost | ||
| - | * __typy ověřování:__ | ||
| - | - //statické:// - nevyžaduje běh programu (libovolná etapa vývoje) | ||
| - | - //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í}} | ||
| - | |||
| - | * **testování** | ||
| - | * odhalování chyb během vývoje | ||
| - | * důležité volit dobré vstupy | ||
| - | * __testovací kritérium:__ | ||
| - | - spolehlivé - nezáleží, jakou množinu vstupů vezmeme, vždy dostaneme stejný výsledek | ||
| - | - platné - když pro každou chybu v programu existuje množina testovacích vstupů, která splňuje toto kritérium a která chybu odhalí | ||
| - | * __typy:__ | ||
| - | - náhodné - generátor pseudonáhodných čísel | ||
| - | - 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// | ||
| - | * test, co neodhalí chybu chování systému, je neúspěšný | ||
| - | {{:temata:30-zivotni_cyklus_softwaru:testovani.jpeg?600|Proces testování}} | ||
| ===== Zdroj ===== | ===== Zdroj ===== | ||
