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.

Zpracovaná otázka na 60 stran

Fáze životního cyklu SW

• Specifikace - dokument specifikace požadavků na software
  1. Požadované vlastnosti dokumentu
     1. Jednoznačtnost
     2. Úplnost
     3. Verifikovatelnost
     4. Konzistence
     5. Modifikovatelnost
     6. Tracovaltelnost
• Vývoj
  1. Návrh
  2. Implementace
• Validace
• Evoluce
  1. Nasazeni
  2. Vlastni evoluce
  3. Servisovani
  4. 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)”.

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í).