Advertisement
Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- **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!
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement