SI2 - výpisky ke zkoušce

SI2.md

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)
    • plány - zdroj know-how
    • odhady - přehled používání prostředků během vývoje, dobré vědět do budoucna
    • pracovní dokumenty - většinou zbytečné uchovávat
  • 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!