Rozdíly

Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.

Odkaz na výstup diff

temata:30-zivotni_cyklus_softwaru:main [2016/06/06 14:38]
xpavel27 [Specifikace požadavků]
temata:30-zivotni_cyklus_softwaru:main [2016/06/06 14:45] (aktuální)
xpavel27 [Modely]
Řádek 121: Řádek 121:
   * **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   * 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 132: Řá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 142: Řádek 146:
     - __požadavky na rozhraní__ - komunikace se systémem     - __požadavky na rozhraní__ - komunikace se systémem
     - __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 ==
 +
 +  * **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
 +
  
  
Řádek 224: Řá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 311: Řádek 376:
  
  
- 
-==== 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 
  
  
temata/30-zivotni_cyklus_softwaru/main.1465216686.txt.gz · Poslední úprava: 2016/06/06 14:38 autor: xpavel27
Recent changes RSS feed Debian Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki