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 22:32]
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)
-====== 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**\\
-  * 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