VÝVOJ SOFTWARE Flashcards
Kartičky kopírují otázky ke státnicím
Požadavky na SW: uživatelské, systémové, parametrické, scénáře a případy užití, kvalitativní parametry z pohledu uživatele a vývojáře
- důležitý krok při vývoje softwaru
- popisují, co by se mělo implementovat
- fáze a vývoj požadavků: sběr -> analýza -> specifikace -> kontrola
Uživatelské pož:
- uživatelem, či zadavatelem projektu
- neformálně, často v přirozeném jazyku
- co má systém dělat z pohledu koncového uživatele
- př. vyhledávat v záznamech podle názvu
Systémové pož:
- technická specifikace - popis funkčnosti a chování, detailní popis funkcí, které má systém vykonávat
- požadavky na: HW/SW, bezpečnost, výkon
Parametrické pož:
- kvantitativní požadavky, které lze měřit a ověřit
- vztahuje se k rychlosti odezvy, kapacitě paměti, počtu uživatelů
- př. rychlost odezvy pod 2 sekundy při zátěži 1000 současných uživatelů
Scénáře užití:
- popis konkrétního způsobu, jak uživatel interaguje se systémem v reálném světě
- často se používá vývojový diagram
- graficky znázorňuje krok za krokem aktivitu uživatele se systémem při nějaké konkrétní činnosti
- příkazy, podmínky, počáteční hodnoty a konec
- př.: kontrola připojení (svítí kontrolka? připojeno? připojit / vyměnit)
- pozor na příliš složité diagramy
Případy užití, use cases:
- use case diagram - formálnější, znázorňuje aktéry a jejich možné využití systému a odhaluje hranici mezi aktéry a reálným světem
- vazby mezi aktéry a případy užití, (include, extends)
- př. restaurace - zákazník, číšník kuchař - objednávka, jezení jídla, vaření, placení…
Kvalitativní parametry z pohledu uživatele a vývojáře
Uživatel - DEFIKSOP - dostupnost, efektivita, flexibilita, integrita, kompatibilita, spolehlivost, odolnost, použitelnost
Vývojář - UPZT - udržitelnost, přenositelnost, znovupoužitelnost, testovatelnost
Rizika - nejednoznačné požadavky, rychlý nárůst, málo feedbacku, špatné odhady
Důležité vlastnosti požadavků - ÚSPPOJ - úplnost, správnost, proveditelnost, prioritizace, ověřitelnost, jednoznačnost
Metodiky vývoje software, model vodopád, agilní přístup
Metodiky vývoje - soubor praktik a nástrojů pokrývající celý proces vývoje softwaru
2 hlavní dělení:
- tradiční
- agilní
Vodopádový model - tradiční metodika, sekvenční proces, jasně dané fáze
- sběr požadavků → návrh → implementace → testování → nasazení → údržba
(+) - jednoduchá struktura, jasně dané fáze
- podrobná dokumentace, usnadňuje kontrolu chyb
- vhodné pro projekty s jasně danými požadavky
- usnadňuje plánování
( – ) - není flexibilní, nemožná reakce na změny během vývoje
- nevhodné pro měnící se požadavky
- chyby se objeví až při testování
- dlouhá doba od zadání projektu po předání zákazníkovi
Spirálový model - vychází z vodopádu a kombinuje výhody sekvenčního a iterativního procesu
- 4 hlavní fáze, které se iterují, v každé iteraci se přidává nová funkcionalita
- plánování
- návrh
- vývoj
- vyhodnocení
(+) - umožňuje reakci na změny
- důraz na vyhodnocování rizik díky opakovanému plánování a vyhodnocování
- vhodné pro složitější a dlouhodobé projekty
( – ) - vyžaduje zkušený tým
- obtížné plánování, protože oproti vodopádu nemáme dopředu jasně definovaný celý postup
- vyšší náklady a časová náročnost
Agilní metody
- interakce jednotlivců > procesy a nástroje
- fungující software > obsáhlá dokumentace
- spolupráce se zákazníkem > smlouvy
- flexibilita a reakce na změny > dodržování plánů
Příklady:
SCRUM - organizace práce do 1-4 týdenních krátkých sprintů
- denní standup meetingy, retrospektiva, prioritizace
KANBAN - rozdělení práce a vizualizace v tzv kanban boardu (todo, doing, done)
- důraz na kontinuální tok práce, omezení rozpracování více činností naráz
Extreme programming - párové programování, testování, rychlé iterace
(+) - flexibilita, časté feedbacky zákazníka snižují riziko
- časté dodávání částí softwaru
- vyšší spolupráce tým - zákazník
( – ) - vyžaduje aktivní zapojení zákazníka
- s nezkušeným týmem může být chaotické
- nevhodné pro velké, či distribuované týmy
Testování SW, chyba vs vlastnost
Testování SW - proces ověřování a kontrola funkcionality systému a splňění požadavků
- cílem je detekovat chyby a ověřit kvalitu před předáním uživateli
Typy testování:
Podle úrovně:
- jednotkové testy - testování jednotl. komponent a modulů
- integrační testy - kompatibilita mezi ostatními moduly
- systémové testy - test celého systému
- akceptační testy - zda sw splňuje požadavky
Podle přístupu:
White-box - testování se znalostí interní implementace a kódu
Black-box - bez znalosti
Gray - kombinace
Podle dat:
- Test funkčnosti - zda funkce vrací korektní výsledky (kalkulačka 2+2=4)
- Edge cases - mezní či extrémní, neběžné hodnoty (faktoriál 0 či 1000)
- Nekorektní data - jak sw reaguje na nesprávný formát dat, či nespr hodnotu (text do číselného pole)
Repeat - časté opekované testování, zda změna kódu nezpůsobila chybu
Stress - extrémní zátěž systému
Load - kontrola při běžné zátěži
Konfigurační - testování různých konfig podmínek, různý HW, OS
Chyba - nesoulad mezi očekáváním a reálným chováním systému
Vlastnost - záměrná, navržená funkcionalita implementovaná záměrně
CH
Vznik - nesprávná implementace
Očekávání - nesplňuje očekávání uživ
Řešení - oprava
Příklad - nesprávný výsledek výpočtu
VL
Vznik - záměrná implementace na zákl. návrhu
Očekávání - splňuje, ale zákazník nemusí reagovat pozitivně
Řešení - přehodnocení návrhu, revize řešení
Příklad - zbytečná, nebo matoucí funkce
Klasifikace chyb
Vážnost
1) Pád systému, ztráta dat, prolomení bezpečnosti
2) Chybné výsledky, ztráta funkcionality
3) Překlepy, grafické chyby
Priorita
- kritická - oprava ihned
- normální - oprava před nasazením
- nízká - oprava, pokud zbyde čas
Proč v praxi není možné opravit všechny chyby? - omezené zdroje (lidské, časové, finanční)
V-model, axiomy a typy testování, automatické testování a sestavení (vč. nástrojů) - výhody a nevýhody
V-model - verification and validation - rozšíření vodopádového modelu
- klade důraz na testování každé fáze vývoje
Požadavky, analýza ——————— Akceptační testy
Specifikace ———– Systémové, funkční testy
Detailní návrh architektury sys —– Integrační testy
Návrh modulů a implementace – Unit testy
Axiomy:
1. Testování dokáže odhalit pouze přítomnost chyby, nikoli nepřítomnost
2. Exhaustní testování není možné (nelze otestovat všechny kombinace scénářů)
3. Včas nalezená chyba snižuje náklady na její opravení
4. Paretovo pravidlo 80% chyb pochází z 20% části systému
5. Testy je potřeba revidovat a aktualizovat, reflektovat změny systému
Automatické testování
Selenium - web
Pytest - python
JUnit - java
Appium - mobile
Automatické testy testují software automaticky předdefinovanými testy bez lidského zásahu.
(+) rychlé, konzistentní, snížení lidské chyby
(–) počáteční náklady, časově náročné
omezené pokrytí explorativních testů
pravidelná údržba nutná
Automatické sestavení
Jenkins, Azure DevOps, GitHub CI/CD …
Automatizuje sestavování softwaru a často i samotných testů.
(+) rychlost dodání
(–) potřeba znalosti navíc, technická náročnost
časově náročná počáteční konfigurace
komplexní údržba
při změně prog. jazyku či frameworku nutno aktualizovat nástroje
Prototypy
- proces tvorby modelu, či návrhu SW systému, jako náhled konečného produktu
- umožňuje vývojářům i uživatelům ověřit požadavky, design a funkcionalitu před zahájením plnohodnotného vývoje
Typy prototypů:
- Papírový - rychlý, levný, vhodný pro počáteční vývoj
- Funkční, klikací - částečně interaktivní
- Explorativní - zkoumání nápadů
- Throw-away - po použití vyřazen
- Evoluční - postupně vyvýjen v konečný produkt
- High-fidelity prototyp - téměř hotový prototyp, k prezentaci
Postup prototypování:
- Analýza požadavků
- Návrh prototypu
- Testování - feedback vývojářů či uživatele
- Úpravy na základě feedbacku
- Rozhodnutí - vyřadit prototyp či použít jako základ produktu
(+) usnadnění komunikace se zákazníkem
rychlejší nalezení chyb či nedorozumnění
snížení rizika - ověření, zda uživatelovy požadavky jsou proveditelné v reálném světě
(–) časová náročnost
očekávání uživatele - může mít pocit, že už je hotovo
pokud bude prototyp použit jako základ násl. vývoje, hrozí, že v něm budou chyby, pokud byl narychlo “splácán”
Nástroje:
Balsamiq - rychlé náčrty UI
Figma, Adobe XD - design UI
Axure, InVision - interaktivní prototypy
Projektový management, projekt vs. operativní činnost, dimenze projektu
Proces řízení, plánování a kontroly zdrojů a činností za účelem dokončení projektu v rámci stanovených požadavků - časových, finančních, kvalitativních.
Klíčové oblasti project managementu:
Časové - hlídat harmonogramy a termíny
Rozsah - co se má udělat
Finanční - dodržet daný rozpočet a výdaje
Komunikace - mezi členy týmu či dalších zúčastněných stran
Kvalita - dohlížet na kvalitu
- Projekt - jedinečný (vývoj nové aplikace), časově omezený, dynamický, za dosažením určitého cíle
- Operační činnost - standardizovaná/rutinní činnost, opakovaně prováděná za účelem efektivity či produktivity
Fáze projektu - zahájení, plánování, realizace, kontrola, ukončení
(start-prk-konec)
Dimenze projektu - projektový trojúhelník
3 hl. dimenze - čas, zdroje, rozsah
Trojúhelník znázorňuje propojení těchto veličin a změna v jedné nevyhnutelně veze ke změně aspoň jedné další. Uprostřed se většinou udává kvalita, jelikož nepoměr v rovnováze veličin má vliv na kvalitu produktu.
Př. 3 členný tým pracuje na projektu a jeden je převeden na jiný projekt. Buď vyrovnáme ztrátu v lidských zdrojích přesčasem, nebo prodloužíme čas, nebo vyjednáme snížení rozsahu projektu, abychom se do daného času vešli. Bohužel se v praxi často stává, že aby se vyhnulo zklamání zákazníka, vede to k nucenému a v nejhorším i neplacenému přesčasu. Crunch time
Gantův diagram
Diagram znázorňující úkoly a podúkoly na časové ose.
Úkoly jako vodorovné pruhy.
Start-to-Start, Start-to-Finish
WBS - Work Breakdown Structure
Rozdělení projektu do hlavních činností a podúkolů
WBS, úkoly, vazby, CPM, Ganntův diagram, plánování zdrojů
Work breakdown structure
- hierarchický rozpis projektu na menší celky, které jsou lépe proveditelné a pochopitelné
- detailní rozpracování úkolů, pomáhá identifikovat a definovat posloupnost činností, důležitých k dosažení cíle projektu, předat zodpovědnost, znázornit vztahy
(+) zvyšuje přehlednost, pochopitelnost, snížení rizika, že se na něco zapomene
- Dělení na: hlavní úkoly, podúkoly, jednotlivé činnosti
Úkoly - tasks
- konkrétní činnosti potřebné provést k dosažení cíle
Vlastnosti: Jednoduchost, měřitelnost, časová omezenost
Vazby - znázorňují, jak na sebe jednotlivé úkoly navazují
FS - finish to start - jeden úkol musí skončit, aby bylo možné začít nový
FF - oba úkoly skončí současně
SS - úkoly začnou současně
SF - jeden úkol musí začít, aby bylo možné druhý ukončit
CPM - critical path method
- identifikuje nejdelší posloupnost klíčových úkolů k dokončení projektu včas
- kritická cesta - nejdelší cesta bez časové rezervy - zpoždění na této cestě zpožďuje celý projekt
Použití - identifikace všech úkolů a vazeb
- odhad termínu úkolů
- výpočet kritické cesty
Ganntův diagram - znázorňuje harmonogram, úkoly a jejich vztahy na časové ose
- úkol zn. jako vodorovný pruh posazený na časové ose relativně k ostatním
- pro sledování závislostí a termínů
(+) intuitivní, identifikuje zpoždění
Plánování zdrojů
- zahrnuje kontrolu a řízení zdrojů k dokončení projektu
Zdroje mohou být:
- lidské - tým vývojářů s dovednostmi
- finanční - rozpočet a náklady
- materiální - nástroje a programy, hw, sw
Kroky plánování zdrojů:
- identifikace potřebných zdrojů
- přiřazení potřebných zdrojů
- optimalizace
