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 21:24] 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ý pro | ||
- | ces 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) | ||
- | |||
- | 2 základní techniky: **zhora-dolu** nebo **zdola-nahoru** | ||