Rozdíly

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

--- mgr-szz:in-gra:21-gra [2018/01/29 23:13]
roozi
+++ mgr-szz:in-gra:21-gra [2020/04/12 16:56]
@@ Řádek 1: / Řádek 1: @@
-====== 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 ======
-**Fáze životního cyklu SW**
-  * Specifikace - dokument specifikace požadavků na software
-    - Požadované vlastnosti dokumentu
-      - Jednoznačtnost
-      - Úplnost
-      - Verifikovatelnost
-      - Konzistence
-      - Modifikovatelnost
-      - Tracovaltelnost
-  * Vývoj
-    - Návrh
-    - Implementace
-  * Validace
-  * Evoluce
-    - Nasazeni
-    - Vlastni evoluce
-    - Servisovani
-    - Phase-out (dožívání)
-**Modely životního cyklu**
-  * Vodopád
-  * Inkrementální model
-  * Prototypování
-  * Výzkumník
-  * Spirálový model
-**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.
-**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)”.
-====== Metodika Unified Process ======
-UP je generický proces pro UML specifikaci (postup vývoje určující jaké UML diagramy použít).
-Diagramy UP dělí na ty, které ukazují statickou strukturu (Diagram tříd, Use Case diagram, Diagram objektů, Diagram komponent, Diagram nasazení) a dynamickou strukturu (Diagram aktivit, Diagram komunikace, Stavový diagram, Sekvenční diagram).
-**Hlavní rysy UP:**\\
-**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ávrh, Implementace, Integrace a testování).\\
-**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.
-**Řízení rizik** Unified Process také 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í).
-{{:mgr-szz:in-gra:up_phases.png?600|}}
-**Vazba mezi fází UP a UML diagramy**\\
-**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)**\\
-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í.
-====== 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**\\
-**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).
-**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).
-**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 (striktním) plněním plánu**
-**Agilní metodiky**\\
-  * Extreme programming (XP)
-  * Feature-Driven Development (FDD)
-  * SCRUM Process Development
-  * Test-Driven Development (TDD)
-====== Fáze testování a typy testů ======
-Proces spuštění (části) programu s cílem nalézt chyby.
-====== 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**
-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**
-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
-**Metriky složitosti**\\
-**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.
-**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.
-**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ů! \\
-  * <math>C + V</math>
-====== Odhadování nákladů a času vývoje SW ======
-Při odhadování se reflektuje:
-  * Minulý podobný projekt (velmi dobrý výchozí bod)
-  * Použití dekompoziční techniky
-  * Použití empirických modelů
-  * Odhad se zpožděním (nutný určitý buffer, pokud by se něco pokazilo)
-základní techniky: **zhora-dolu** nebo **zdola-nahoru**
-**Funkční bod**\\
-Metrika, říkající kolik toho funkční jednotka umí. Měří aplikační oblast, nezkoumá technickou oblast.
-**Putnam**
-T - usílí (člověkodny)
-D - doba řešení
-c - hodnota podle předchozích projektů
-N - Délka programu
-<math>N = c * T^{1/3} * D*^{4/3}</math>
-**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í.\\
-Model - přesnot výpočtu\\
-Mód (jak je projekt obtížný) - určující koeficient\\
-<math>E = a * F * (KLOC)^b</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**\\
-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.
-====== 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**\\
-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)
-**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ů.\\
-  * Inspekce, recenze
-  * Testování
-  * Měření
-  * Standardy a procedury

mgr-szz/in-gra/21-gra.txt · Poslední úprava: 2020/04/12 16:56 (upraveno mimo DokuWiki)

Nahoru