**2**

SDLC (sw dev lifecycle)
* zkoumání potřeb
* specifikace požadavků
* design, vývoj, testování
* nasazení, integrace
* support
* vyhodnocení

process activities
* požadavky
* analýza/návrh
* implementace, testing
* supporting (podpůrné)
  * management
  * prostředí (environment)
  * deployment (nasazení)

requirements engineering (EASV-E dropping) [SRS - software requirements specification]
* proces SI, který zahrnuje všechny aktivity týkající se návrhu, dokumentování a udržování souboru požadavků na počítačový systém
  * elicitation - schůzky, pozorování uživatelů
  * analysis - přemýšlení, debaty, poznámky
  * specification - dekompozice, psaní v notaci
  * verification - schůzky, čtení textu, wireframy, bitva
* specifikace požadavků je potřeba pro techniky (aby věděli co dělat), sepsání smlouvy (co je předmětem) a též nedílná součást dokumentace
* od požadavků se odvíjí cena

rozsah prací (scope) - *všechny závazky*
* funkce, features, integrace s ostatními systémy
* výkonnost, bezpečnost
* zákazník (chce všechno co není explicitně NE) x dodavatel (dělá jenom ANO) => konflikt

typy požadavků
* vždy se ptám stakeholderů - zainteresovaných osob
  * funkcionální požadavky
  * požadavky na rozhraní
    * UI, UX, software, hardware, komunikační, ...
  * nefunkční požadavky
    * výkon, bezpečnost, škálovatelnost, dostupnost, ...
  * další
    * lokalizace, legislativa

požadavky na požadavky
* srozumitelné
* jednoznačné
* kompletní
* nevylučují se navzájem
* dle priority
* lze je ověřit

forma specifikace
* strukturovaný dokument doplněný o modely, obrázky, diagramy
* v CASE nástroji (EA)
* nebo katalog požadavků

modelování
* model GUI (wireframe)
  * jednoduché na pochopení
  * dílčí verifikace specifikace požadavků zákazníkem
* UML
  * prostřeedek k reprezentaci SW na úrovni analýzy, návrhu a částečně realizace
  * nutné znát u zákazníka
* use cases
  * scénáře, dobré jako doplněk

dokumentace
* měla by být aktualizovaná a přesná => drahá záležitost
* možnost trasovat změny (EA - SVN)
* UML diagramy se užívají protože omezuje blbosti (papír snese všechno)
  * nepojmou zadání, požadavky, big picture, souvislosti
  * obchodní požadavek není cíl
    * je to první úroveň fixace scope, cesta ke správnému řešení

**3**

Rational Unified Process IECT
* iterační proces vývoje software
* symbolizován grafem, který ukazuje 6 technických (+ 3 netech) disciplín a podíl na práci v závislosti na čase
1. inception
  * LCO - ujasněny požadavky zákazníka, odsouhlasen rozsah, cena, harmonogram projektu
    * identifikována rizika, stanovena mitigační (zmírňující) strategie
2. elaboration
  * LCA - víme jak to, co zákazník požaduje, budeme vytvářet, detailní kontrola výběru architektury
    * stanoven iterační plán pro další fázi, testovací přístupy
    * řešení hlavních rizik
3. construction
  * IOC - konec konstrukce, systém je funkční a prošel alfa testem
    * poskytneme systém zákazníkovi, je sepsána uživatelská příručka
4. transition

software architecture
* realizace nefunkčních požadavků
  * programovací paradigmata, ...
* MVC
  * model - spravuje data, logiku, pravidla
  * view - poskytuje / vykresluje data uživateli
  * controller - přijímá vstup a převádí jej na příkazy pro model/view
* pipes and filters
  * pipe - konektor, převádí data mezi filtery
  * filter - filtruje data (X vstupů, Y výstupů)
  * př. unixové programy, kompilátory
* big ball of mud
  * neexistující architektura, spaghetti code
* event driven

software design
* relizace funkčních požadavků
  * design patterns, refactoring

framework
* znovupoužitelný návrh pro SW systém, diktuje architekturu systému
* určuje jak dekomponovat systém a jak budou jednotlivé části komunikovat
  * frozen spots - neměnné části
  * hot spots - zajišťují rozšiřitelnost (abstraktní třídy)
* vs library
  * inversion of control
  * rozšiřitelnost
  * nemodifikovatelnost

integrace
* file transfer
  * soubory jsou univerzální, aplikace nezávislé
  * problematický formát, out of sync
* shared database
  * odpadají problémy se synchronizací
  * nutno vytvořit univerzální schéma, bottleneck
* remote procedure call
  * aplikace vlastní data, ostatní se dotazují
  * výkonový rozdíl mezi lokálním a vzdáleným voláním, silné vazby
* messaging
  * když se něco stane, tak to pošli
  * mnoho malých paketů

**4**

self-documenting code
* sebelepší kód nenahrazuje dokumentaci
* problémy - význam big picture, conditions

**5**

software testing
* zkoušení / simulace provozu SW
* analýza s cílem najít chyby

testing objectives
* mají za cíl najít chyby v požadavcích, designu, docs, kódu co nejdřív
* test oracle - mechanismus pro určení zda SW prošel daným testem
* test case - množina podmínek, za kterých se určí zda systém funguje nebo ne
* test plan - strategie testů, co a jak testovat, odpovědnost

typy testů
* co testujeme za konfigurační jednotku
  * unit testy
  * integrační testy
  * systémové testy
  * akceptační testy
* jaký aspekt testujeme
  * funkční, výkonnostní, bezpečnostní, ...
* s jakým cílem testujeme
  * regresní testy
  * kvalifikační testy

timeline testů
* při commitu na VCS -> rychlé testy
* při tvoření buildu na CI -> všechny automatické testy
* na testovací platformě -> výkonové a jiné nefunkční testy, manuální testy
* při dodávce -> kvalifikační testy

pozitivní test
* funguje co fungovat má

negativní test
* nefunguje co fungovat nemá
* zkouší se i edge cases

black box
* testujeme oproti rozhraní
* obecnější, není nutné často upravovat

white box
* strukturální testy
* přihlížíme k implementaci

partitioning
* rozdělení testů do tříd ekvivalence
* provádění různých testů ze stejné třídy ekvivalence je redundantní
  * vybírá se nejvhodnější reprezentant skupiny (nejv. pravděpodobnost odhalení chyby)

testovací techniky
* definují, které testy jsou zajímavé
* př. user, risk-based
  * function testing - izolované testování každé funkce
  * specification-based testing - test software proti každému tvrzení v docs
  * risk based testing - problémy hledat u věcí dělaných na poslední chvíli, nových a komplexních funkcí, nejasnostech, ...
  * scenario testing - jede se podle scénáře, jak by uživatel mohl používat program
  * user testing - testy dělají samotný uživatelé

požadavky na testy
* pomoct učinit ship/no-ship rozhodnutí
* najít důležité bugy
* ověřit interoperabilitu s jinými produkty
* minimalizovat náklady na technickou podporu
* změřit kvalitu

kdy testovat
* příliš brzo -> zbytečná ztráta času, nestabilní software
* příliš pozdě -> deadliny, odfláknutí testů

bugtracking
* evidence všech issues
* tickety musí obsahovat info, jak issue nasimulovat

rozsah testování
* výsledky - našli jsem X chyb
* produkt - otestovali jsme Y% řádků kódu
* kvalita testování - beta testeři našli Z chyb, failujou nám regresní testy
* projektová historie - v této fázi máme otevřeno W issues, u minulého projektu to bylo podobně
* nejlepší je kombinace více metrik

automatické testování
* stejná data, stejný test lze spustit na více konfiguracích
* mají smysl typicky v budoucnu (ROI)
* užití u CI, konfiguračních testů, přípravě testovacího prostředí

**6**

dokumentace
* abychom něco nezapomněli
* komunikační prostředek
* zdroj do budoucna, pro uživatele a administrátory, údržbu
  * dokumenty procesu - popis procesu vývoje a údržby SW (plány, odhady, reporty)
  * dokumenty produktu
    * uživatelská dokumentace - seznam funkcí, screenshoty (za ručičku), pro adminy i BFU
    * systémová dokumentace - requirements, architektura, reporty z testů, known bugs, závislosti
* je nutné ji udržovat konzistentní

quality assurance
* množina aktivit, cílem je zajistit kvalitu produktu systematickým a věrohodným způsobem
* uvažujeme na všech úrovních, od organizace až po jednotlivce
* testování
  * statické vs dynamické
* přezkoumání
  * projektu, kódu, nabídky

kvalita
* mít spokojeného zákazníka

**7**

softwarový produkt
* úplný soubor počítačových programů, dokumentace a dat, určený pro dodání uživateli

softwarová položka
* jakákoliv identifikovatelná položka sw produktu

konfigurační řízení
* zajištění plného řízení konfigurace sw produktu a související dokumentace v průběhu lifecycle
* cíl - zajistit řád a pořádek v konfiguraci sw produktu
  * evidence všech částí sw produktu
  * identifikace všech částí sw produktu i celku
  * provádění změn nad sw produktem daný sw nepoškodí
  * možnost získat přehled o stavu konfigurace

plán konfiguračního řízení
* introduction - účel, rozsah, způsob a podmínky použití
* SCM (sw config. management) management - organizace, odpovědnosti, autority, politiky, procedury
* SCM activities - řízení verzí a změn
* SCM schedules - koordinace s dalšími projektovými aktivitami
* SCM resources - nástroje, způsob použití, hardware a lidské zdroje (HR)
* SCMP (plan) maintenance

změnové řízení
* řízení rozsahu nad rámec původně domluveného rozsahu

version control
* umožňuje práci na více verzích současně a ve více lidech
* návrat k předešlé verzi
  * centrální VCS
    * centralizované repo, lokální kopie
    * všechno jde do master branch
    * důraz na synchronizaci, tracking, zálohování
  * distribuovaný VCS
    * každý má své vlastní repo
    * důraz je kladen na sdílení změn

patch
* oprava buildu
* branch, oprava, merge do masteru

**8**

nutné dovednosti
* vyrobit a nainstalovat dodávku
* připravit ji pro instalaci zákazníkem
* dodat systém jako celek
* dokázat rychle a levně opravit drobnost
* poradit si s různými typy prostředí (db server, os,...)

**9**

maintenance
* typy
  * corrective - oprava nalezené chyby
  * preventive - prava latentních chyby
  * adaptive - příspůsobení měnícímu se prostředí
  * perfective - zvyšování výkonu, udržovatelnosti
* nutno respektovat architekturu, nezavádět nové koncepty!
* problém s obměnou dev týmu, závislost na konkrétních osobách, knowhow
* měla by být efektivní a předvídatelná

miniwaterfall
* typický lifecycle u údržby
* požadavek - identifikace - analýza - design - implementace - systémové testy - akceptační testy - deployment

vývojové prostředí
* mělo by se podobat produkci
* CI / smoke testing (zběžný test kontrolující základní funkcionalitu, zda je sw připraven na další testy [aka jestli nehoří :)])
* v produkci se opravují kritické chyby, všechno ostatní jde mimo a pak prochází akceptací

**10**

komunikace se zákazníkem
* ukazovat stav
* sdělovat rizika
* řešit sporné části

projekťák
* musí umět vytvořit a udržovat plán s výhledem do budoucna
* musí mít jasno (a měřit)
  * termíny
  * závazky (first-party i third-party)
  * rizika
  * současný stav řešení
* musí umět efektivně rozdělovat práci (aby lidi věděli co dělat)
* musí často komunikovat se zákazníkem ohledně stavu
* interní reporting (technický i cashflow)
* zodpovědnosti
  * scope projektu
  * time management
  * effort (team)
  * quality (chyby v kódu, refactoring obfuskací)

**11**

odhady
* je nutné provést dekompozici projektu
  * dle počtu řádků
  * dle GUI obrazovek
  * dle use cases
  * dle požadavků
  * dle změnových řízení
* alternativa: dle předešlého projektu

historie projektu
* jedná se zejména o investici do budoucna - schopnost odhadovat
  * manhours, kalendářní čas, velikost týmu
  * pracnost jednotlivých typů činností
  * počty (obrazovky, tabulky)
  * charakteristika systému
  * problémy, rizika
  * vše dalšího co se může časem hodit

měřící metriky
* time - kalendářní čas
* size - rozsah
* effort - pracnost
* quality - jakost
* vhodné pro historii projektu (časové odhady, tvorba nabídky)

**12**

softwarový process
* množina aktivit potřebých k vývoji software
* obsahuje
  * specifikace - co bude systém dělat
  * architektura - z jakých kostek bude postaven
  * implementace
  * validace - ověření jestli dělá to co má
  * další rozvoj - dodatečná úprava systému
* plan-driven (plánování hodně dopředu)
* agilní (plánování po malých částech, snadná změna kurzu)

model sw procesu
* popis procesu z určité perspektivy
* waterfall
  * oddělené fáze
  * req analysis - design - coding - testing - maintenance
  * + predikovatelný (vím kdy co dostanu), jasný plán, snadná koordinace, prostor pro QA, docs
  * - nutno mít vše rozvrhnuto už na začátku, pomalé reakce a dodávka
* iterativní
  * několik verzí systému
  * jednotlivé verze se dělají waterfallem
  * + prototypy, rychlejší reakce na změny (zbytek stejný jako u vodopádu +/-)
  * - docs nutné udržovat u každé verze zvlášť
* scrum / agile
  * kašle na dokumentaci (jede příliš rychle), agilně reaguje na změny
  * náklady na změny nízké
  * - vím co dostanu jenom v rámci sprintu (krátké období)
  * - riziko zanesení problému v každém sprintu
  * - riziko nekvalitní práce (není prostor na QA)
  * - zákazník se musí podílet na projektu po celou dobu
  * - nejsou známy dopředu požadavky

co použít
* na velké systémy - iterativní
* na malé systémy, housebreeding, popř. části projektu - agilní
* agilní není synonymum pro chaos!