Rozdíly

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

Odkaz na výstup diff

Obě strany předchozí revize Předchozí verze
Následující verze
Předchozí verze
mgr-szz:in-gra:21-gra [2018/01/29 23:51]
roozi
mgr-szz:in-gra:21-gra [2020/04/12 16:56] (aktuální)
Řádek 1: Řádek 1:
 ====== Zadání ====== ====== Zadání ======
-Proces vývoje SW. Metodika Unified Process. Agilní vývoj SW. Fáze testování a typy testů. Softwarové metriky, refaktoring kódu. Kvalita softwaru. Odhadování nákladů a času vývoje SW. Údržba a znovupoužitelnost. 
  
-[[https://​docs.google.com/​document/​d/​1JVC34-jBqK-hnyxty9YNelID_LChUsvREdgS9NaEjvI|Zpracovaná otázka na 60 stran]]+  * Proces vývoje SW. 
 +  * Metodika Unified Process. 
 +  * Agilní vývoj SW. 
 +  * Fáze testování a typy testů. 
 +  * Softwarové metriky, refaktoring kódu. Kvalita softwaru. 
 +  * Odhadování nákladů a času vývoje SW. 
 +  * Údržba a znovupoužitelnost. 
 + 
    
 ====== Proces vývoje SW ====== ====== Proces vývoje SW ======
-**Fáze životního cyklu SW** + 
-  * Specifikace - dokument specifikace ​požadavků ​na software +<box 90% red|Proces vývoje SW> 
-    ​- Požadované vlastnosti dokumentu +Proces při němž: 
-      - Jednoznačtnost +  ​* **uživatelovi potřeby** 
-      - Úplnost +    * ⬇ transformovány na 
-      - Verifikovatelnost +  * **požadavky ​na software** 
-      - Konzistence +    ​* ⬇ transformovány na 
-      - Modifikovatelnost +  * **návrh** 
-      - Tracovaltelnost +    * ⬇ implementován jako 
-  * Vývoj +  * **kód** 
-    - Návrh +    * ⬇ testován, dokumentován a certifikován pro 
-    - Implementace +  * **operační použití** 
-  * Validace +</​box>​ 
-  * Evoluce + 
-    - Nasazeni + 
-    - Vlastni evoluce +Základní aktivity při vývoji SW: 
-    - Servisovani +  * **Specifikace** 
-    - Phase-out (dožívání)+    * Je třeba definovat funkcionalitu SW a operační omezení. 
 +  ​* **Vývoj** 
 +    ​* Je třeba vytvořit SW, který splňuje požadavky kladené ve specifikaci. 
 +      ​- Návrh 
 +      - Implementace 
 +  ​* **Validace** 
 +    * SW musí být validován („kolaudován“),​ aby bylo potvrzeno, že řeší právě to, co požaduje uživatel. 
 +  ​* **Evoluce** 
 +    ​* SW musí být dále rozvíjen, aby vyhověl měnícím se požadavkům zákazníka. 
 +      ​- Nasazeni 
 +      - Vlastni evoluce 
 +      - Servisovani 
 +      - Phase-out (dožívání) 
  
 **Modely životního cyklu** **Modely životního cyklu**
   * Vodopád   * Vodopád
-  * Inkrementální model 
   * Prototypování   * Prototypování
   * Výzkumník   * Výzkumník
   * Spirálový model   * Spirálový model
  
-**Lehmanovy zákony**+===== OO modely =====
  
-Zákony se zabývají ​fází ​evoluce, popisují rovnováhu mezi novými požadavky a údržbou na straně jedné a zvyšující se složitostí, snižující ​se “business value” na straně druhé.+  * **Vodopád** 
 +    * celý projekt rozdělen do fází ​(trvající řádově měsíce):​ 
 +      - analýza 
 +      - návrh 
 +      - implementace 
 +      - integrace 
 +      - verifikace 
 +      - nasazení 
 +      - údržba 
 +    * chyba vede k návratu k předešlým fázím 
 +      * ➖ odhalení chyby je čím dále dražší 
 +    * ➖ těžké odhadnout ukončení fáze 
 +    * testování neprobíhá současně s vývojem 
 +      * ➖ chyby jsou odhalovány pozdě kvůli  
 +  * **Iterativní** 
 +    * celý projekt vyvíjen v několika iteracích 
 +      * každá iterace obsahuje fáze jako u vodopádu (ale můžse lišit intenzita) 
 +      * ➕ rychlejší zpětná vazba od zákazníka 
 +      * ➕ částečné řešení dříve 
 +  * **Inkrementální** 
 +    * jednotlivé části projektu vyvíjeny nezávisle a následně integrovány. 
 +    * samotné část mohou být vyvíjeny další metodikou (vodopád, iterativně,​ XP,...) 
 +    * ➕ vždy je výsledkem iterace použitelný produkt ​
  
-**Zákon trvalé proměny** 
- ​Systém používaný v reálném prostředí se neustále mění, dokud není levnější systém restrukturalizovat nebo nahradit zcela novou verzí. 
-**Zákon rostoucí složitosti** 
-Při evolučních změnách je program stále méně strukturovaný a vzrůstá jeho vnitřní složitost. Odstranění složitosti vyžaduje dodatečné úsilí. 
-**Zákon vývoje programu** 
-Rychlost globálních změn atributů systému se může jevit v omezeném časovém intervalu jako náhodná. V dlouhodobém pohledu se však jedná o seberegulující proces, který lze statisticky sledovat a předvídat. 
-**Zákon invariantní spotřeby práce** 
-Celkový pokrok při vývoji projektů je statisticky invariantní. Jinak řečeno, rychlost vývoje programu je přibližně konstantní a  nekoreluje s vynaloženými prostředky 
-**Zákon omezené velikosti přírůstku** 
-Systém určuje přípustnou velikost přírůstku v nových verzích. Pokud je limita překročena,​ objeví se závažné problémy týkající se kvality a použitelnosti systému. 
  
-**Brooksův zákon** +<box 90% blue|Metodika Unified Process>
-Týká se začlenění nového člena týmu do zpožděného projektu (ten, který s ním neměl zatím žádný styk :D). Zákon říká, že “Přidání řešitelské kapacity u opožděného projektu může zvětšit jeho zpoždění (náklady na začlenění nového pracovníka do týmu jsou zpravidla větší, než jeho přínos)”.+
  
-====== Metodika Unified Process ====== +  * Generická procesně orientovaná metodika postavená nad UML
-UP je generický proces pro UML specifikaci ​(postup vývoje určující jaké UML diagramy použít). +    * Definuje KDO dělá KDY, CO a JAK toho má dosáhnout. 
 +    * **iterativní a inkrementální** 
 +      * Každou iteraci lze chápat jako mini-projekt ​(fáze: Plánování,​ Analýza a návrh, Implementace,​ Integrace a testování) 
 +    * **use-case driven** 
 +      * Hlavní pohled udává Use Case diagram, snažíme se vždy dokončit jeden případ užití a pak pokračujeme dále. 
 +    * **architecture-centric** 
 +      * Jasně udává, že volba a vybudování dobré architektury systému je hlavním cílem projektového týmu. 
 +    * **Řízení rizik** 
 +      * Vyžaduje, aby se projektový tým zaměřil na řešení nejvážnějších rizik v rané fázi životního cyklu projektu (největší rizika jsou vždy řešena jako první).
  
-Diagramy ​UP dělí na ty, které ukazují statickou strukturu (Diagram tříd, Use Case diagram, Diagram objektů, Diagram komponent, Diagram nasazení) ​dynamickou strukturu (Diagram aktivitDiagram komunikaceStavový diagram, Sekvenční diagram).+  * Fáze v UP
 +    * **Inception** 
 +      * Definuje oblast projektu ​business využití. 
 +    * **Elaboration** 
 +      * plán projektuspecifická funkcionalitazákladní architektura 
 +    * **Construction** 
 +      * tvorba produktu 
 +    * **Transition** 
 +      * předání produktu zákazníkovi
  
-**Hlavní rysy UP:**\\ +  ​Každá fáze má několik iterací s jasným plánem a výstupem. 
-**Iterace a inkrementy** Hlavní pohled udává Use Case diagram, ​snažíme se vždy dokončit jeden případ užití a pak pokračujeme dále. Každou iteraci lze chápat jako mini-projekt (fáze: PlánováníAnalýza a návrhImplementaceIntegrace a testování).\\ +    ​Obsahují "​workflows",​ různě zastoupené během celého vývoje. 
-**Soustředění se na architekturu** UP jasně udáváže volba a vybudování dobré architektury systému je hlavním cílem projektového týmu. +      ​requirements 
-**Řízení rizik** Unified Process také vyžaduje, aby se projektový tým zaměřil ​na řešení nejvážnějších rizik rané fázi životního cyklu projektu (největší rizika jsou vždy řešena jako první).+        ​Use Case model: use-case, sequence diagram 
 +      analysis 
 +        ​Analysis model: class/​object diagram 
 +      ​design 
 +        ​Design model: class/​object ​diagram, ​sequencestateactivity diagram 
 +        * Deployment model: deploymentsequence diagram 
 +      implementation 
 +        ​Implementation model: componentsequence diagram 
 +      test 
 +        ​Test model: odkaz na všechny odpovídající modely a diagramy 
 +      * Use-case spojuje workflows dohromady.
  
 {{:​mgr-szz:​in-gra:​up_phases.png?​600|}} {{:​mgr-szz:​in-gra:​up_phases.png?​600|}}
  
-**Vazba mezi fází UP a UML diagramy**\\ +</​box>​
-**Inception:​** Use Case diagram, Diagram aktivit, Diagram komunikace, Stavový diagram, Sekvenční diagram +
-**Elaboration:​** Diagram tříd, Diagram aktivit, Diagram komunikace, Stavový diagram, Sekvenční diagram +
-**Construction:​** Diagram nasazení, Diagram komponent. Sekvenční diagram, ale pozor UML neřeší testování,​ dává pohled na systém (test není součástí výsledného SW) +
-**Transition:​** Žádné UML diagramy už se nepoužívají.+
  
-**Metodika Rational Unified Process (RUP)**\\ +<box 90% blue|Metodika Rational Unified Process (RUP)
-Metodika RUP je komerční ​verzí ​metodiky UP. V podstatě se dá říci, že obě metodiky jsou postaveny ​na stejném základu ​a liší se pouze v tom, že v mnoha případech je metodika ​RUP propracována více do detailů a v některých případech se nepatrně liší s syntaxí.+  ​* komerční ​implementace ​metodiky UP od IBM 
 +  * RUP i UP stojí ​na stejném základu 
 +  * RUP mírně detailnější než UP 
 +  * drobné odlišnosti v syntaxi 
 +</​box>​
  
 ====== Agilní vývoj SW ====== ====== Agilní vývoj SW ======
-Umožňují rychlý vývoj a zároveň dokáží reagovat na změnu požadavků v průběhu vývojového cyklu. + 
-**Princip agilního vývoje**\\ +  * Metodika zaměřená na lidi. 
-**Individuality a interakce mají přednost před procesy a nástroji:​** Dělejme to iterativně,​ komunikujme se zákazníkem a ověřujme (hodně o spirálách). ​ +  * Umožňují rychlý vývoj a zároveň dokáží reagovat na změnu požadavků v průběhu vývojového cyklu. 
-**Fungující software má přednost před obsáhlou dokumentací (nejvýznamnější bod):** Dokumentují méně (čím agilnější tím více dá na slovo zákazníka),​ protože dochází peníze (dokumentuje se především na konci). +  velmi krátké iterace 
-**Spolupráce se zákazníkem má přednost před sjednáváním smluv**\\ +  UML pouze jako komplement 
-**Reakce na změnu má přednost před (striktním) plněním plánu**+  malé fungující týmy 
 +  zákazník zapojen do vývoje 
  
 **Agilní metodiky**\\ **Agilní metodiky**\\
Řádek 84: Řádek 142:
   * Test-Driven Development (TDD)   * Test-Driven Development (TDD)
  
 +<box 90% orange|Manifesto of Agile Software Development>​
 +http://​agileManifesto.org
 +  * Individuality and interactions over processes and tools.
 +  * Working software over comprehensive documentation.
 +  * Customer collaboration over contract negotiation.
 +  * Responding to change over following a plan.
 +</​box>​
 +
 +Rozdíl oproti Model-Driven Engineering (MDE):
 +  * MDE:
 +    * pevná funkcionalita
 +    * variabilní čas a zdroje
 +  * Agile:
 +    * pevný čas a zdroje
 +    * variabilní funkcionalita
  
 ====== Fáze testování a typy testů ====== ====== Fáze testování a typy testů ======
-Proces spuštění (části) programu s cílem nalézt chyby. Nemůže ukázat nepřítomnost defektů, může pouze ukázat, že v softwaru jsou chyby. Testování také ukazuje funkce a výkon. ​A je také ukazatelem ​kvality software.Testování je destruktivní činnost, není vhodné, aby vývojář a tester byla ta samá osoba.+ 
 +<box 90% red> 
 +Proces spuštění (části) programu s cílem nalézt chyby. 
 +</​box>​ 
 + 
 +  * Nemůže ukázat nepřítomnost defektů, může pouze ukázat, že v softwaru jsou chyby. 
 +  * Testování také ukazuje funkce a výkon. 
 +  * Ukazatelem ​kvality software. 
 +  * //Testování je destruktivní činnost, není vhodné, aby vývojář a tester byla ta samá osoba.// 
   * Verifikace - test proti vnitřní činnosti (unit testy)   * Verifikace - test proti vnitřní činnosti (unit testy)
 +    * “Dělat věci správně”
   * Validace - test proti specifikaci   * Validace - test proti specifikaci
 +    * “Dělat správné věci”
  
-BlackBox vs. WhiteBox (vidím/​nevidím do struktury programu) 
  
-**Typy testů** +<box 90% orange|Myers,1979> 
-  * **Unit testy** - hledají defekty uvnitř softwarových komponent a verifikují fungování softwarových komponent (např. modulůprogramů, objektů, tříd, atd.), které jsou testovatelné samostatně. +Test je úspěšný, pokud zjistí přítomnost jedné ​či více chyb programu
-  * **Assembly testy** - mají za úkol ověřit, že jednotlivé ​části kódu, testované ​rámci unit testů, spolu fungují+</box>
-  * **Integrační testy** - Integrační testování testuje rozhraní mezi komponentami,​ interakce s různými částmi systému jako jsou operační systém, souborový systém, hardware anebo rozhraní mezi systémy. +
-  * **Systémové testy** - Systémové testování se zabývá chováním celého systému/produktu, jak byl definován rozsahem vyvíjeného projektu nebo programu. Měly by pokrýt jak funkční tak nefunkční požadavky. +
-  * **Akceptační testy** - jsou hlavní částí testování z pohledu dodávky aplikace zákazníkovi.+
  
-**Další testy** 
-  * **Funkční testy** – slouží k nalezení rozdílů mezi aktuální aplikací proti funkční specifikaci (funkční požadavky) 
-  * **Nefunkční testy** - zahrnují testování výkonu, zátěžové testování,​ stres testování,​ testování použitelnosti,​ testování udržovatelnosti,​ testování spolehlivosti a testování přenositelnosti. Je testováním toho, “jak“ systém pracuje (jako celek). 
-  * **Statické testy** – provádí manuální prozkoumání (revidování) a automatizovanou analýzu (statickou analýzu) kódu nebo jiné projektové dokumentace (uživ.příručky,​ apod.) 
-  * **Dynamické testy** - znamenají provádění testování na již běžící systému, aplikaci 
-  * **Regresní testy** - testy na ověření stávající funkcionality (provádí se po opravení chyb či novem release) 
-  * **Progresní testy** - testy na ověření nové funkcionality 
-  * **Smoke test** - je krátký test, který slouží jako ověření, že vyvíjená aplikace je "​způsobilá"​ pro další fázi testování. 
  
  
 +  * **úplné testy**
 +    * prochází všechny logické cesty
 +    * není realizovatelné
 +  * **selektivní testování**
 +    * testujeme důležité logické cesty a cykly
 +    * validuje rozhraní a vytváří důvěru ve vnitřní činnost
 +  * **dynamické testování**
 +    * vzorkování -- provedení programu s předem určenými vstupy a porovnání s očekávanými výsledky
 +  * **BlackBox vs. WhiteBox**
 +    * vidím/​nevidím do struktury programu
  
-====== Softwarové metriky, refaktoring kódu ====== 
-Softwarová metrika je nějaký údaj (měření, atribut softwaru), který lze nakonec převést na číselné hodnocení. ​ 
-**Metrika**\\ 
-**Kvantitativní** (číselně vyjádřená) míra, tj. ukazatel do jaké míry se nějaký atribut vyskytuje v systému, komponentě nebo procesu nebo **kvalitativní** charakter, tj. nečíselné vyjádření.\\ 
-Dělíme na:\\ 
-  * **Produktové**:​ zdrojový kód, dokumentace,​ cyklomatická složitost (počet cest programem), počty funkčních bodů 
-  * **Procesní**:​ činnosti spojené s vývojem, doba strávená na jednotlivých úlohách, původní odhad a skutečná reálná doba 
-  * **Metriky zdrojů**: HW, lidé, čas, nemocnost, výkonnost\\ 
-nebo na 
-  * **Implicitní (in proces)** – zjistitelné pouze během vývoje 
-  * **Explicitní (after proces)** – zjistí se kdykoliv i po skončení vývoje (z artefaktů produktů systému) 
  
-**Velikostně orientované metriky** +===== Typy testů =====
-Lines Of Code (LOC), 1000 Lines Of Code (KLOC), počet chyb/KLOC, počet defektů/KLOC, cena/LOC, velikost dokumentace/​KLOC+
  
-**Funkčně orientované metriky** +  ​* **Unit testy** 
-počet uživatelských vstupů, počet už. výstupů, počet dotazů, počet souborů, počet spojení s jinými systémy+    * hledají defekty uvnitř softwarových komponent a verifikují fungování softwarových komponent (např. modulů, programů, objektů, tříd, atd.), které jsou testovatelné samostatně. 
 +  * **Integrační testy** 
 +    * testuje rozhraní mezi komponentami,​ interakce s různými částmi systému jako jsou operační systémsouborový systém, hardware anebo rozhraní mezi systémy. 
 +  * **Systémové testy** 
 +    * Systémové testování se zabývá chováním celého systému/​produktu,​ jak byl definován rozsahem vyvíjeného projektu nebo programu. 
 +    * Měly by pokrýt jak funkční tak nefunkční ​požadavky. 
 +  * **Akceptační testy** 
 +    * Hlavní částí testování z pohledu dodávky aplikace zákazníkovi.
  
-**Metriky složitosti**\\ +**Další testy:** 
-**Halsteadova ​metrika**+ 
 +  * **Funkční testy** 
 +    * slouží k nalezení rozdílů mezi aktuální aplikací proti funkční specifikaci (funkční požadavky) 
 +  * **Nefunkční testy**  
 +    Zahrnují testování výkonu, zátěžové testování,​ stres testování,​ testování použitelnosti,​ testování udržovatelnosti,​ testování spolehlivosti a testování přenositelnosti. 
 +    ​Je testováním toho, “jak“ systém pracuje (jako celek). 
 +  * **Statické testy** 
 +    * Provádí manuální prozkoumání (revidování) a automatizovanou analýzu (statickou analýzu) kódu nebo jiné projektové dokumentace (uživ.příručky,​ apod.) 
 +  * **Dynamické testy** 
 +    * Znamenají provádění testování na již běžící systému, aplikaci 
 +  * **Regresní testy** 
 +    * Testy na ověření stávající funkcionality (provádí se po opravení chyb či novem release) 
 +  * **Progresní testy** 
 +    * Testy na ověření nové funkcionality 
 +  * **Smoke test** 
 +    * Je krátký test, který slouží jako ověření, že vyvíjená aplikace je "​způsobilá"​ pro další fázi testování. 
 +  * **Assembly testy** 
 +    * Mají za úkol ověřit, že jednotlivé části kódu, testované v rámci unit testů, spolu fungují. 
 + 
 + 
 +====== Softwarové metriky ====== 
 + 
 +<box 90% red|Softwarová ​metrika
 +Údaj (měření, atribut softwaru), který lze nakonec převést na číselné hodnocení. 
 +</​box>​ 
 + 
 +  ​* **kvantitativní** (číselně vyjádřená) míra, tj. ukazatel do jaké míry se nějaký atribut vyskytuje v systému, komponentě nebo procesu 
 +  * **kvalitativní** charakter, tj. nečíselné vyjádření 
 + 
 +Dělíme na: 
 +  * **Produktové** 
 +    * zdrojový kód, dokumentace,​ cyklomatická složitost (počet cest programem), počty funkčních bodů 
 +  * **Procesní** 
 +    * činnosti spojené s vývojem, doba strávená na jednotlivých úlohách, původní odhad a skutečná reálná doba 
 +  * **Metriky zdrojů** 
 +    * HW, lidé, čas, nemocnost, výkonnost 
 + 
 +  * **Implicitní (in proces)** 
 +    * zjistitelné pouze během vývoje 
 +  * **Explicitní (after proces)** 
 +    * zjistí se kdykoliv i po skončení vývoje (z artefaktů produktů systému) 
 + 
 +<box 90% blue|Velikostně orientované metriky>​ 
 +  * Lines Of Code (LOC), 1000 Lines Of Code (KLOC) 
 +  * počet chyb/KLOC 
 +  * počet defektů/​KLOC 
 +  * cena/LOC 
 +  * velikost dokumentace/​KLOC 
 +</​box>​ 
 + 
 +<box 90% blue|Funkčně orientované metriky>​ 
 +  * počet uživatelských vstupů 
 +  * počet už. výstupů 
 +  * počet dotazů 
 +  * počet souborů 
 +  * počet spojení s jinými systémy 
 +</​box>​ 
 + 
 + 
 +===== Metriky složitosti ===== 
 + 
 +<box 90% blue|Halsteadova metrika>
 Program je věta, která vznikla na určité slovní zásobě. Na základě poměru délky věty (programu) a velikosti slovní zásoby (počet operátorů a operandů) získáme složitost. Program je věta, která vznikla na určité slovní zásobě. Na základě poměru délky věty (programu) a velikosti slovní zásoby (počet operátorů a operandů) získáme složitost.
 +</​box>​
  
-**McCabe odhad složitosti**\\ +<box 90% blue|McCabe odhad složitosti> 
-Vnímá program jako graf. Dochází k výpočtu cyklomatické složitosti: ​//Kolik je možných průchodů grafem nebo kolik je tam nezávislých větví//. Funguje také jako indikátor spolehlivosti. Pokud V(G) je větší než 10 má velký chybový potenciál a zle se testuje. V(G) je v podstatě počet uzavřených oblastí v rovinném grafu.+Vnímá program jako graf. Dochází k výpočtu ​**cyklomatické složitosti**: 
 +  * Kolik je možných průchodů grafem nebo kolik je tam nezávislých větví.
  
-**McClure odhad složitost**\\+Funguje také jako indikátor spolehlivosti. 
 +  ​Pokud V(G) je větší než 10 má velký chybový potenciál a zle se testuje. 
 +  ​V(G) je v podstatě počet uzavřených oblastí v rovinném grafu. 
 +</​box>​ 
 + 
 +<box 90% blue|McClure odhad složitost>
 Také založen na cyklomatické složitosti. Odvozeno od počtu větvení (C) a počtu řídících proměnných (V), především zohledňuje složitost podmínek tj. samotných uzlů! \\ Také založen na cyklomatické složitosti. Odvozeno od počtu větvení (C) a počtu řídících proměnných (V), především zohledňuje složitost podmínek tj. samotných uzlů! \\
   * <​math>​C + V</​math>​   * <​math>​C + V</​math>​
 +</​box>​
 +
  
 ====== Odhadování nákladů a času vývoje SW ====== ====== Odhadování nákladů a času vývoje SW ======
 +
 Při odhadování se reflektuje: ​ Při odhadování se reflektuje: ​
   * Minulý podobný projekt (velmi dobrý výchozí bod)   * Minulý podobný projekt (velmi dobrý výchozí bod)
Řádek 146: Řádek 294:
   * Odhad se zpožděním (nutný určitý buffer, pokud by se něco pokazilo)   * Odhad se zpožděním (nutný určitý buffer, pokud by se něco pokazilo)
  
-2 základní techniky: **zhora-dolu** nebo **zdola-nahoru** +<box 90% red|Funkční bod>
- +
-**Funkční bod**\\+
 Metrika, říkající kolik toho funkční jednotka umí. Měří aplikační oblast, nezkoumá technickou oblast. Metrika, říkající kolik toho funkční jednotka umí. Měří aplikační oblast, nezkoumá technickou oblast.
 +</​box>​
  
-**Putnam**+<box 90% blue|Putnam>
 T - usílí (člověkodny) T - usílí (člověkodny)
 D - doba řešení D - doba řešení
Řádek 157: Řádek 304:
 N - Délka programu N - Délka programu
 <​math>​N = c * T^{1/3} * D*^{4/​3}</​math>​ <​math>​N = c * T^{1/3} * D*^{4/​3}</​math>​
 +</​box>​
  
-**Cocomo (COnstructive COst MOdel)**\\ + 
-Odhadování pracnosti shora-dolů. Vychází z Putnama a odhadu délky programů KSLOC, zdroj empirických dat je větší počet předchozích projektů a pozorování.\\ +<box 90% blue|Cocomo (COnstructive COst MOdel)> 
-Model esnot výpočtu\\ +  ​* ​Odhadování pracnosti shora-dolů. 
-Mód (jak je projekt obtížný) ​- určující koeficient\\+  * Vychází z Putnama a odhadu délky programů KSLOC
 +  * Zdroj empirických dat je větší počet předchozích projektů a pozorování. 
 + 
 +  * **Model** (esnost ​výpočtu) 
 +    * základní (hrubý odhad) 
 +    * střední 
 +    * pokročilý (bere v potaz etapu vývoje) 
 + 
 +  * **Mód** (jak je projekt obtížný) 
 +    * organický (jednodušší,​ dobře řešitelné projekty menšího rozsahu) 
 +    * bezprostřední (středně obtížné projekty) 
 +    * vázaný (rozsáhlé projekty s vysokými nároky na řízení)
  
 <​math>​E = a * F * (KLOC)^b</​math>​\\ <​math>​E = a * F * (KLOC)^b</​math>​\\
 <​math>​T = c* E^d</​math>​\\ <​math>​T = c* E^d</​math>​\\
-a,b,c,d - parametry volené podle úrovně modelu a módu\\ 
-T - doba řešení\\ 
-E = úsilí\\ 
-F = korekční faktor, ekvivalence s „c“ v Putnamovi tedy produktivita\\ 
  
-**Cocomo II**\\ +  ​a,b,c,d - parametry volené podle úrovně modelu a módu 
-Nemá smysl dělat přesné výpočty na začátku projektu -> korekční faktor vždy 1 a základní model. Důvod změny? Nové SW procesynové jevy měřenínové možnosti jako znovupoužití SW+  ​T - doba řešení 
 +  ​E = úsilí 
 +  ​F = korekční faktor, ekvivalence s „c“ v Putnamovi tedy produktivita 
 +</​box>​ 
 + 
 + 
 +<box 90% blue|Cocomo II> 
 +Nemá smysl dělat přesné výpočty na začátku projektu -> korekční faktor vždy 1 a základní model. 
 + 
 + 
 +Důvod změny
 +  * nové SW procesy 
 +  * nové jevy měření 
 +  * nové možnosti jako znovupoužití SW 
 + 
 +3 různé modely: 
 +  * **ACM (Aplication Composition Model)** 
 +    * pro projekty s použitím moderních nástrojů a GUI 
 +  * **EDM (Early Design Model)** 
 +    * pro hrubé odhady v úvodních etapách, kdy se architektura vyvíjí 
 +  * **PAM (Post Architecture Model)** 
 +    * pro odhady poté, co byla specifikována architektura 
 + 
 +</​box>​
  
 ====== Kvalita softwaru ====== ====== Kvalita softwaru ======
-**Obecný model kvality (Quality model)**\\ 
-**Operation:​** Dělá to, to co má? Týká se splnění specifikace,​ standardů a uživatelského očekávání. -- Pohled uživatele 
-**Revision:​** Je dobře navržený? (dobře testovatelný,​ rozšiřitelný apod.) Týká se vývoje. -- Pohled vývojářů 
-**Transition:​** Je dobře nasaditelný?​ (přenositelnost,​ nezávislost na HW, pohodlná instalace) -- Celkový pohled obou stran 
  
-**Kvalita dle IEEE**\\+  ​Kvalitativní atributy souvisí převážně s non-funkčními požadavky. 
 +    ​Performance (výkon) 
 +    * Reliability (spolehlivost) 
 +    * Security (bezpečnost) 
 +    * Scalability (škálovatelnost) 
 +    * Maintainability (udržovatelnost) 
 + 
 +  * Techniky hodnocení kvality 
 +    * monitoring a testování 
 +      * verifikace kvality existujícího systému 
 +    * predikce na základě modelu 
 +      * odhad kvality systému ve vývoji 
 +    * formální verifikace 
 +      * verifikace formulovaných tvrzení o systému 
 + 
 + 
 + 
 + 
 +**Obecný model kvality (Quality model)** 
 +  * **Operation:​** 
 +    * Dělá to, to co má? Týká se splnění specifikace,​ standardů a uživatelského očekávání. 
 +    * pohled uživatele 
 +  * **Revision:​** 
 +    * Je dobře navržený? (dobře testovatelný,​ rozšiřitelný apod.) 
 +    * Týká se vývoje. 
 +    * Pohled vývojářů 
 +  * **Transition:​** 
 +    * Je dobře nasaditelný?​ (přenositelnost,​ nezávislost na HW, pohodlná instalace) 
 +    * Celkový pohled obou stran 
 + 
 +<box 90% red|Kvalita dle IEEE>
 Stupeň, do jaké míry systém, komponenta nebo proces splňuje specifikované požadavky. (spíše u SW na zakázku) Stupeň, do jaké míry systém, komponenta nebo proces splňuje specifikované požadavky. (spíše u SW na zakázku)
 Stupeň, do jaké míry systém, komponenta nebo proces splňuje zákazníkovy nebo uživatelovy potřeby nebo jeho očekávání. (spíše u krabicového SW) Stupeň, do jaké míry systém, komponenta nebo proces splňuje zákazníkovy nebo uživatelovy potřeby nebo jeho očekávání. (spíše u krabicového SW)
 +</​box>​
  
-**Techniky zajištění kvality software**\\ +===== Techniky zajištění kvality software ​===== 
-Obecně lze mluvit o testování,​ validaci a verifikaci produktu. Validací se rozumí otázka, zda jsme vytvořili správný produkt tj. jestli produkt odpovídá potřebám uživatele. Verifikací se rozumí, zda jsme produkt vytvořili správně tj. zda produkt odpovídá specifikaci. Testováním se pak pokoušíme zmíněné předchozí dokázat pro omezenou sadu příkladů.\\+ 
 +  * Obecně lze mluvit o testování,​ validaci a verifikaci produktu. 
 +  * Validací se rozumí otázka, zda jsme vytvořili správný produkt tj. jestli produkt odpovídá potřebám uživatele. 
 +  * Verifikací se rozumí, zda jsme produkt vytvořili správně tj. zda produkt odpovídá specifikaci. 
 +  * Testováním se pak pokoušíme zmíněné předchozí dokázat pro omezenou sadu příkladů.
   * Inspekce, recenze   * Inspekce, recenze
   * Testování   * Testování
Řádek 190: Řádek 399:
   * Standardy a procedury   * Standardy a procedury
  
-====== Údržba a znovupoužitelnost ​(+refaktoring) ​======+====== Údržba a znovupoužitelnost + Refaktoring ​====== 
 Velmi nákladná v čase, finance odpovídají tomu jak dlouho ho chceme udržet. Náklady jsou 2x -100x větší než na vývoj. Na údržbu se mělo myslet již při vývoji. Velmi nákladná v čase, finance odpovídají tomu jak dlouho ho chceme udržet. Náklady jsou 2x -100x větší než na vývoj. Na údržbu se mělo myslet již při vývoji.
  
Řádek 197: Řádek 407:
   * Přidat nebo měnit systémovou funkcionalitu -> každá implementace degraduje kvalitu systému   * Přidat nebo měnit systémovou funkcionalitu -> každá implementace degraduje kvalitu systému
  
-**Systémový re-engineering**\\+===== Systémový re-engineering ​===== 
 Znovu napsání celé části systému bez účelu změnit její funkcionalitu,​ když subsystémy vyššího systému vyžadují častou údržbu. Cílem je vytvoření nového systému, který by se lépe udržoval (i snížení ceny za údržbu). Znovu napsání celé části systému bez účelu změnit její funkcionalitu,​ když subsystémy vyššího systému vyžadují častou údržbu. Cílem je vytvoření nového systému, který by se lépe udržoval (i snížení ceny za údržbu).
  
-**Refactoring**\\+===== Refactoring ​===== 
 Refactoring je kontinuální proces vylepšení skrze vývojový a evoluční proces. Jeho záměrem je vyhnout se degradaci struktury a kódu, která zvyšuje cenu za údržbu. Refactoring je kontinuální proces vylepšení skrze vývojový a evoluční proces. Jeho záměrem je vyhnout se degradaci struktury a kódu, která zvyšuje cenu za údržbu.
  
Řádek 214: Řádek 426:
  
  
-**Znovupoužitelnost**\\+===== Znovupoužitelnost ​===== 
 Hlavní výhodou je několikanásobné finanční ohodnocení jednou vyvinuté komponenty. Hlavní výhodou je několikanásobné finanční ohodnocení jednou vyvinuté komponenty.
  
Řádek 223: Řádek 436:
   * Systém (The system level): celý systém a různé platformy   * Systém (The system level): celý systém a různé platformy
  
-**Reuse-Oriented software engineering**\\ +<box 90% blue|Reuse-Oriented software engineering> 
-Model vývoje SW, založen na systematickém znovuužití,​ kde jsou systémy integrovány z existujících komponent (commercial-off-the-shelf = COTS). Zbylou funkcionalitu (kterou ještě nemáme) doprogramujme,​ především proxy, adaptéry a GUI. Jedná se o standardní budování business systémů.+Model vývoje SW, založen na systematickém znovuužití,​ kde jsou systémy integrovány z existujících komponent (commercial-off-the-shelf = COTS)
  
 +  * Zbylou funkcionalitu (kterou ještě nemáme) doprogramujme,​ především proxy, adaptéry a GUI.
 +  * Jedná se o standardní budování business systémů.
 +</​box>​
  
 +
 +<box 90% orange|Lehmanovy zákony>
 +
 +Zákony se zabývají fází evoluce, popisují rovnováhu mezi novými požadavky a údržbou na straně jedné a zvyšující se složitostí,​ snižující se “business value” na straně druhé.
 +
 +  * **Zákon trvalé proměny**
 +    * Systém používaný v reálném prostředí se neustále mění, dokud není levnější systém restrukturalizovat nebo nahradit zcela novou verzí.
 +  * **Zákon rostoucí složitosti**
 +    * Při evolučních změnách je program stále méně strukturovaný a vzrůstá jeho vnitřní složitost.
 +    * Odstranění složitosti vyžaduje dodatečné úsilí.
 +  * **Zákon vývoje programu**
 +    * Rychlost globálních změn atributů systému se může jevit v omezeném časovém intervalu jako náhodná.
 +    * V dlouhodobém pohledu se však jedná o seberegulující proces, který lze statisticky sledovat a předvídat.
 +  * **Zákon invariantní spotřeby práce**
 +    * Celkový pokrok při vývoji projektů je statisticky invariantní.
 +    * Jinak řečeno, rychlost vývoje programu je přibližně konstantní a  nekoreluje s vynaloženými prostředky
 +  * **Zákon omezené velikosti přírůstku**
 +    * Systém určuje přípustnou velikost přírůstku v nových verzích.
 +    * Pokud je limita překročena,​ objeví se závažné problémy týkající se kvality a použitelnosti systému.
 +</​box>​
 +
 +<box 90% orange|Brooksův zákon>
 +Týká se začlenění nového člena týmu do zpožděného projektu (ten, který s ním neměl zatím žádný styk :D). Zákon říká, že “Přidání řešitelské kapacity u opožděného projektu může zvětšit jeho zpoždění (náklady na začlenění nového pracovníka do týmu jsou zpravidla větší, než jeho přínos)”.
 +</​box>​
  
 ====== Zdroje ====== ====== Zdroje ======
  
-Velká většina z https://​docs.google.com/​document/​d/​1JVC34-jBqK-hnyxty9YNelID_LChUsvREdgS9NaEjvI+  * slidy pa103 
 +  * slidy pa017 
 +  * https://​docs.google.com/​document/​d/​1JVC34-jBqK-hnyxty9YNelID_LChUsvREdgS9NaEjvI 
mgr-szz/in-gra/21-gra.txt · Poslední úprava: 2020/04/12 16:56 (upraveno mimo DokuWiki)
Nahoru
CC Attribution-Noncommercial-Share Alike 4.0 International
chimeric.de = chi`s home Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0