SEP Flashcards
1
Q
Agilní metodika vývoje
A
Iterativní a flexibilní přístup k vývoji softwaru, zaměřený na rychlé dodávky funkčních částí, průběžnou spolupráci s klientem a schopnost reagovat na změny požadavků
SCRUM
2
Q
Waterfall
A
Sekvenční model vývoje softwaru, kde fáze (analýza, návrh, implementace, testování, údržba) probíhají postupně, bez návratu k předchozím krokům
3
Q
Iterativní
A
Metodika vývoje softwaru, kde se projekt realizuje v opakujících se cyklech (iteracích), přičemž každá iterace zahrnuje analýzu, návrh, implementaci a testování, což umožňuje průběžné zlepšování a přizpůsobení produktu
4
Q
Co je základní koncept Software Process Improvement (SPI)?
A
Zlepšování procesů vývoje softwaru za účelem zvýšení kvality, produktivity a adaptability. Zaměřuje se na identifikaci slabých míst a implementaci změn pro efektivnější vývoj.
5
Q
Co je PDCA model? (Demingův cyklus)
A
Metodika zlepšování procesů, založená na cyklu čtyř kroků: Plan (naplánuj), Do (proveď), Check (ověř), Act (jednej). Používá se k postupnému a opakovanému zlepšování procesů.
6
Q
Jaké jsou základní přístupy k Software Process Improvement (SPI)?
A
- Systematický, dlouhodobý přístup
– Preskriptivní (ISO, CMM, CMMI)
– Induktivní (SEL/NASA)
7
Q
Co jsou preskriptivní přístupy k SPI?
A
Přístupy, které vycházejí z předpokladu, že správné praktiky vývoje softwaru jsou známé, a tyto postupy předepisují
8
Q
Co jsou induktivní přístupy k SPI?
A
Přístupy, které vycházejí z předpokladu, že zlepšovat se má to, co odpovídá aktuálnímu stavu, cílům a problémům konkrétní organizace
9
Q
Co je CMM (Capability Maturity Model)?
A
Model pro hodnocení a zlepšování procesů vývoje softwaru. Rozděluje procesy do pěti úrovní zralosti:
1. Počáteční (chaotický, ad-hoc)
2. Opakovatelný (základní projektový management)
3. Definovaný (standardizované procesy)
4. Řízený (kvantitativní měření a kontrola)
5. Optimalizující (neustálé zlepšování)
10
Q
Co je CMMI a jak se liší od staršího CMM? (Capability Maturity Model Integration)
A
CMMI je nástupce CMM, který slouží k hodnocení a zlepšování procesů organizace. Má 5 úrovní zralosti a 22 klíčových procesních oblastí (KPA).
Existují dva hlavní přístupy:
* Staged (po jednotlivých úrovních)
* Continuous (zaměřený na zlepšování jednotlivých oblastí)
CMMI obsahuje 3 modely:
1. Development – pro vývoj softwaru 2. Acquisition – pro akvizici produktů a služeb 3. Services – pro poskytování služeb
11
Q
Jaká je základní premisa přístupu SEL (Software Engineering Laboratory) / NASA?
A
Vývojová organizace musí své úsilí o zkvalitňování zaměřovat na:
1. Zamezení opakování minulých problémů.
2. Opakování minulých úspěchů
12
Q
Co jsou SPMN Best Practices?
A
SPMN (Software Process Management Network) Best Practices jsou osvědčené strategie, techniky a praktiky reagující na problémy spojené se zvládáním velkých softwarových projektů. Jsou přímo použitelné a zaměřují se na zlepšení procesů a řízení v rámci vývoje softwaru. Pro přístup k detailním materiálům je nutná registrace k ‘SPMN books’
13
Q
Co je rozdíl mezi RFI a RFP?
A
RFI (Request for Information) a RFP (Request for Proposal) jsou dokumenty, které podává zákazník:
* RFI (Request for Information): Zákazník žádá o základní informace o dostupných řešeních a dodavatelích, aby získal přehled o možnostech na trhu.
* RFP (Request for Proposal): Zákazník požaduje konkrétní nabídky od dodavatelů, kteří musí reagovat s podrobnými návrhy řešení, cenami a podmínkami.
RFI je tedy předchůdce RFP a slouží k získání informací, zatímco RFP se zaměřuje na získání konkrétních nabídek
14
Q
Jaké jsou různé módy spolupráce v rámci projektů a jejich charakteristiky?
A
- Fix Time Fix Price – Stanovení pevného času a ceny na základě specifikovaného rozsahu projektu. Případné změny mohou vést k dodatečným nákladům.
- Time & Material – Platba na základě skutečně stráveného času a použitých materiálů. Tento model je flexibilní a vhodný pro projekty s nejasně definovaným rozsahem.
- Success Fee – Odměna je založena na dosažení specifických úspěchů nebo výsledků projektu. Tento model je často spojen s výkonovými bonusy.
15
Q
Jaký je rozdíl mezi odhadem, závaznou pracností a cenou?
A
Odhad je předpokládaná hodnota pro čas, náklady nebo rozsah, zatímco závazná pracnost a cena jsou konkrétní hodnoty stanovené pro realizaci projektu. Odhad může být upravován během projektu, zatímco závazné hodnoty jsou pevně stanovené.
16
Q
Jaké metody odhadu se používají a co je kužel nejistoty?
A
Mezi metody odhadu patří zkušenostní metody, analýza historických dat a odborné posudky. Kužel nejistoty znázorňuje, jak se zúžuje rozsah nejistoty v odhadu, jakmile projekt postupuje a získává více informací. (0.25 - 4 az 1)
17
Q
Proč je nutná revize odhadů a co obsahují checklisty?
A
Revize odhadů je nutná k jejich aktualizaci podle aktuálního stavu projektu. Checklisty pomáhají zajistit, že všechny aspekty odhadu byly správně zváženy, což zvyšuje přesnost a konzistenci odhadů.
18
Q
Proč je důležité Requirements Engineering?
A
Requirements Engineering je proces, který zahrnuje všechny činnosti spojené s objevováním, dokumentováním a udržováním požadavků na počítačový systém. Tento proces je klíčový pro zajištění, že systém bude vyvíjen podle správných, dobře definovaných a sledovatelných požadavků, což vede k úspěšnému a efektivnímu vývoji softwaru. Definuje rozsah dodávky a funguje jako kontrakt mezi zúčastněnými stranami, což je důležité pro správnou realizaci projektu a zajištění jeho úspěchu.
19
Q
Co jsou požadavky v obecném smyslu?
A
Požadavky jsou písemné výrazy, které specifikují:
* Schopnosti potřebné k vyřešení problému nebo dosažení cíle.
* Podmínky pro dodaný systém, službu, produkt nebo proces.
* Omezení na systém, službu, produkt nebo proces.
20
Q
Jak jsou definovány požadavky v IT?
A
Požadavky v IT jsou specifikace toho, co by mělo být implementováno. Jsou to popisy toho, jak by měl systém fungovat nebo jakou vlastnost či atribut by měl mít. Mohou také představovat omezení na vývojový proces systému.
21
Q
Co zahrnuje věcný obsah IT požadavku?
A
- Capabilities (Schopnosti): Schopnosti, které systém nebo uživatel musí mít.
Příklad: Systém musí být schopen generovat reporty v PDF formátu.- Conditions (Podmínky): Podmínky, za kterých musí být akce provedena.
Příklad: Uživatel musí být přihlášen do systému, aby mohl vytvořit nový účet. - Constraints (Omezení): Omezení, která musí být dodržena během implementace.
Příklad: Aplikace musí fungovat na operačním systému Windows 10 a novějších verzích.
- Conditions (Podmínky): Podmínky, za kterých musí být akce provedena.
22
Q
Jaké typy požadavků existují?
A
- Byznysové požadavky (Business requirements) – Pohled zadavatele nebo organizace, zaměřené na vysokou úroveň cílů a obchodní potřeby.
- Uživatelské požadavky (User requirements) – Pohled budoucího uživatele, zaměřené na funkčnost a uživatelský zážitek.
- Systémové požadavky (System requirements) – Technické požadavky, které definují, jak bude systém realizován, včetně návrhu řešení a vývojové platformy.
23
Q
Co jsou byznysové požadavky a jaký je jejich fokus?
A
Byznysové požadavky jsou požadavky z pohledu zadavatele nebo organizace, které se zaměřují na vysokou úroveň cíle projektu. Tyto požadavky definují, jaký problém má systém vyřešit nebo jaký obchodní cíl má být dosažen, aniž by se zabývaly detaily technické realizace.
Příklad: Systém musí zlepšit správu zákaznických dat a zjednodušit proces fakturace pro zvýšení efektivity obchodních operací.
24
Q
Co jsou uživatelské požadavky a jaký je jejich fokus?
A
Uživatelské požadavky jsou požadavky z pohledu budoucího uživatele systému. Zaměřují se na to, co by uživatel od systému očekával a jaký zážitek by měl mít při jeho používání. Tyto požadavky obvykle popisují funkčnost, která je pro uživatele důležitá.
Příklad: Uživatel musí mít možnost snadno upravit osobní údaje ve svém profilu a změnit heslo během několika kroků.
25
Co jsou systémové požadavky a jaký je jejich fokus?
Systémové požadavky se zaměřují na detaily technické realizace systému. Jsou to požadavky, které definují, jaký bude návrh řešení, jaká vývojová platforma bude použita a jaké technické vlastnosti musí systém splňovat, aby správně fungoval.
Příklad: Systém musí být postaven na platformě Java 11 a používat databázi PostgreSQL pro ukládání uživatelských dat.
26
Jaké je zaměření požadavků? Uveď příklady.
1. Funkční požadavky (Functional requirements) – Zaměřují se na schopnosti, podmínky a omezení systému.
Příklad: Systém musí umožnit uživatelům registraci a přihlášení pomocí e-mailu a hesla.
2. Nefunkční požadavky (Non-functional requirements) – Zaměřují se na podmínky a omezení týkající se vlastností systému.
Příklad: Systém musí mít dostupnost 99,9% během roku.
Příklad: Aplikace musí být schopná zpracovat 1000 požadavků za sekundu.
27
Jaká je míra očekávání od požadavku? Uveď příklady.
1. Běžné požadavky (Normal requirements) – Požadavek by měl být splněn tak, jak byl specifikován.
Příklad: Systém musí umožnit uživatelům změnit své heslo.
2. Nevídané požadavky (Exciting requirements) – Požadavek je splněn pouze výjimečně, ale jeho splnění je vnímáno jako velmi pozitivní.
Příklad: Aplikace může nabídnout personalizované doporučení na základě chování uživatele.
3. Samozřejmé požadavky (Expected requirements) – Požadavek se předpokládá jako automatický, jeho nesplnění je považováno za velmi negativní.
Příklad: Uživatelé musí být schopni se přihlásit do systému pomocí platného uživatelského jména a hesla.
4. Zbytečné požadavky (Indifferent requirements) – Požadavky, kterými se není nutné zabývat, nemají vliv na projekt.
Příklad: Možnost změnit barvu písma v uživatelském rozhraní na nepodstatné barvy.
28
Jaký typ požadavku odpovídá těmto příkladům?
Pobočka sama rozhodne o komunikačním kanálu s klientem
Systém musí oddělovat obchodní činnosti od pracovních pozic
Systém musí být dispozici v režimu 24x7
Uživatel otevře obrazovku“Vyhledání odběratele”
Uživatel musí zadat IČO nebo část názvu a myší stiskne tlačítko “Hledat”
Front-end systému musí mít responzivní design
Povinná pole musí být viditelně označena
Byznysový / funkční / běžný
Byznysový / funkční / běžný? nevídaný? samozřejmý?
Byznysový / nefunkční / běžný? nevídaný?
Uživatelský / funkční / běžný
Uživatelský / funkční / běžný
Uživatelský / nefunkční / běžný? nevídaný? samozřejmý?
Uživatelský / nefunkční / běžný? nevídaný?
29
Jaký je kontext, vstupy a výstupy v Requirements Engineering?
1. Kontext – Celkový obraz projektu, který zahrnuje:
* What & Why – Co má být vytvořeno a proč (např. zrušit X% aplikací, snížit náklady).
* Who – Kdo je zadavatelem a zainteresován (stakeholdeři, zadavatel, manažer).
* Where & When – Projektová omezení, standardy, termíny a metodologie.
2. Vstupy – Co je třeba pro začátek procesu:
* Zadání a vymezení rozsahu – Určuje, co bude součástí specifikace.
* Obchodní požadavky – Neformální nebo formální dokumenty (např. Business Requirements Document, BRD).
* Zadávací dokumentace – Obsahuje byznysové požadavky a kontextové informace.
3. Výstupy – Co je výstupem procesu:
* Specifikace uživatelských požadavků – Dokumentace, která je uživatelsky srozumitelná a detailně popisuje požadavky.
* Seznam nefunkčních požadavků – Obsahuje výkonnostní a bezpečnostní aspekty.
* Model systému – Vizualizace návrhu, např. mockupy.
30
Jaké jsou fáze procesu Requirements Engineering?
1. Elicitation (Zjišťování) – Shromažďování informací a získávání požadavků od stakeholderů a dalších zdrojů.
2. Analysis (Analýza) – Systematické zkoumání, co je skutečně potřeba, a vytvoření jasného obrazu požadavků.
3. Specification (Specifikace) – Dokumentace “real requirements” ve formátu, který odpovídá danému kontextu a požadavkům.
4. Verification / Validation (Ověření / Validace) – Ověření, zda specifikované požadavky jsou věcně a formálně správné, a zda odpovídají očekáváním.
31
Co je to projekt a jak se liší od procesu?
* Definice projektu (dle Prince2): Projekt je dočasná organizace vytvořená za účelem dodání jednoho nebo více obchodních produktů podle dohodnutého obchodního případu (Business Case).
* Projekt x Proces:
* Projekt je unikátní, dočasný a měnící se úkol, který má konkrétní cíl a vyžaduje specifické zdroje.
* Proces je opakující se a stabilní soubor činností zaměřený na dosažení opakovatelných výsledků.
Charakteristiky projektu:
* Mění se – Projekt přináší změny v organizaci nebo ve světě.
* Je dočasný – Má jasně definovaný začátek a konec.
* Unikátní – Každý projekt je specifický a odlišný od ostatních.
* Obsahuje velkou míru nejistoty – Je spojen s riziky a nejasnostmi, které je nutné řídit.
32
Co jsou metodiky pro projektové řízení a jaké jsou příklady tradičních a agilních metodik?
1. Tradiční / Sekvenční metodiky – Tyto metodiky sledují předem stanovený plán a postupný proces:
* Waterfall – Sekvenční metodika, kde každý krok projektu (analýza, návrh, implementace) je dokončen, než přejdete na další fázi.
Příklad: Vývoj softwaru, kde analýza požadavků je dokončena, než začnete s návrhem.
* Critical Path Method (CPM) – Technika pro identifikaci nejdůležitějších aktivit v projektu a jejich časových závislostí, což umožňuje minimalizovat dobu trvání projektu.
Příklad: Stavba budovy, kde každá fáze je závislá na dokončení předchozí.
* Critical Chain Project Management (CCPM) – Verze CPM, která bere v úvahu omezení zdrojů a zamezuje časovým zdržením tím, že přidává ochranné zásoby.
Příklad: Výroba výrobního zařízení, kde je nutné řídit nejen čas, ale i dostupnost materiálů a pracovní síly.
* PMI / PMBOK – Sada standardů a best practices pro řízení projektů, která poskytuje návod na plánování, vykonávání a kontrolu projektů.
Příklad: Standardy pro řízení rozsáhlých infrastrukturních projektů.
2. Agilní metodiky – Flexibilní přístupy zaměřující se na iterativní vývoj a adaptabilitu:
* Pure Agile – Metodika, která se soustředí na flexibilitu, iterace a rychlou reakci na změny.
Příklad: Rychlý vývoj mobilní aplikace, kde se funkce přidávají v krátkých iteracích.
* Scrum – Agilní rámec pro řízení projektů, který zahrnuje pravidelné sprinty a denní stand-upy pro udržení tempa vývoje.
Příklad: Vývoj webové platformy, kde se práce rozdělí do dvoutýdenních sprintů.
* Kanban – Vizualizace práce pomocí tabule, která pomáhá týmům optimalizovat tok práce a zlepšit efektivitu.
Příklad: Správa IT tiketů, kde úkoly plynule přecházejí mezi různými fázemi.
* Extreme Programming (XP) – Agilní metodika, která klade důraz na technické aspekty, jako je párové programování a neustálé testování.
Příklad: Vývoj vysoce spolehlivého softwaru pro zdravotnické zařízení.
* Adaptive Project Framework (APF) – Flexibilní přístup k projektům, který se soustředí na neustálé přizpůsobování se změnám a novým informacím.
Příklad: Vývoj prototypu nové technologie, kde se pravidelně mění směr podle testování.
* SAFe (Scaled Agile Framework) – Rámec pro implementaci agility na podnikové úrovni, který koordinuje více týmů a projektů.
Příklad: Velký podnik implementující agilní metody napříč několika odděleními.
* Nexus – Rámec, který staví na Scrum metodice, ale umožňuje efektivní spolupráci mezi více týmy, které pracují na stejném projektu.
Příklad: Vývoj komplexního softwaru s několika týmy, které pracují na různých modulech.
33
Jaký je rozdíl mezi software architekturou a software designem?
1. Software architecture (Architektura softwaru):
* Realizace nefunkčních požadavků.
* Zaměřuje se na strategický design, který zahrnuje rozhodování o celkové struktuře systému, výběru programovacích paradigmat, architektonických stylech, principech a standardech.
* Příklad: Rozhodnutí, zda systém bude postaven na mikroservisní architektuře nebo monolitické struktuře.
2. Software design (Design softwaru):
* Realizace funkčních požadavků.
* Zaměřuje se na taktický design, který zahrnuje konkrétní implementaci funkčních požadavků pomocí design patterns, programovacích idiomů, refaktoringu a optimalizace kódu.
* Příklad: Použití design patternu jako je Singleton nebo Factory pro řešení konkrétních problémů v kódu.
34
Jaké jsou základy dobrého objektově orientovaného návrhu?
1. Decomposition (Decompozice):
* Definice: Rozdělení složitého systému na menší, snadno spravovatelné části.
* Příklad: Rozdělení aplikace pro správu knihovny na třídy jako Kniha, Čtenář, Výpůjčka.
2. Abstraction (Abstrakce):
* Definice: Skrytí složitosti a zobrazení pouze nezbytných informací pro uživatele objektu.
* Příklad: Třída Auto může mít metody jako start() a stop(), aniž by uživatel musel vědět, jak funguje motor.
3. High cohesion (Vysoká kohezivita):
* Definice: Třídy nebo moduly by měly mít úzce související funkce, které spolu pracují na konkrétním úkolu.
* Příklad: Třída, která se stará o výpočet mzdy, by měla obsahovat pouze metody související s výpočtem a správou mezd.
4. Loose coupling (Volné propojení):
* Definice: Třídy by měly mít co nejmenší závislost na ostatních třídách.
* Příklad: Místo přímé komunikace mezi dvěma třídami použijeme rozhraní nebo události, což minimalizuje jejich vzájemnou závislost.
5. Encapsulation (Kapsulace):
* Definice: Skrývání interního stavu objektu a umožnění přístupu k němu pouze prostřednictvím veřejně definovaných metod.
* Příklad: Třída BankovníÚčet může mít soukromou proměnnou pro zůstatek, ale metody pro vklad a výběr umožní změnit
35
Jaké jsou cíle testování v softwarovém vývoji?
1. Ověření splnění všech requirementů:
Testování slouží k ověření, že software splňuje všechny požadavky definované v dokumentaci.
2. Ustanovení důvěry v software:
Cílem je zajistit, že software dělá to, co má, a nedělá to, co nemá, čímž se zvyšuje důvěra v jeho funkčnost.
3. Analýza software pro nalezení chyb:
Testování pomáhá identifikovat chyby a problémy před tím, než software bude uveden do produkce.
4. Reportování o stavu testovaného produktu:
Cílem je průběžně informovat o stavu testování, rizicích a vývoji vzhledem k termínům a případným problémům.
5. Ohodnocení requirementů a pracovních produktů:
Testování hodnotí, jak dobře byly splněny požadavky a jak kvalitní jsou výsledné produkty, což může být různé podle konkrétního projektu.
36
Jaký je rozdíl mezi statickým a dynamickým testováním?
1. Dynamické testování:
* Definice: Spočívá ve spouštění softwaru za účelem ověření jeho kvality. Testování probíhá během běhu aplikace a zaměřuje se na ověření funkčnosti a výkonnosti.
* Kdy probíhá: Provádí se až na konci vývojového cyklu, když je software dokončen.
* Příklad: Testování správnosti funkce aplikace nebo její výkonnosti při zátěžovém testu.
2. Statické testování:
* Definice: Zaměřuje se na revize a kontroly, které nevyžadují spuštění kódu. Zahrnuje analýzu dokumentace a kódu, aby se identifikovaly potenciální problémy nebo nesoulady.
* Co lze zjistit:
* Revize zadání a validace analýzy nebo specifikace
* Revize technického designu
* Revize vývoje a kódu
* Revize testovací analýzy
* Příklad: Kontrola dokumentace, revize návrhu softwaru nebo kódu, zda odpovídá specifikaci.
37
Jaké jsou typy testů a co testují?
1. Funkční testy:
* Co testují: Ověřují, zda systém dělá to, co by měl, podle specifikace a požadavků.
* Příklad testů:
* Systémové testy: Ověření, že celý systém funguje podle zadání.
* Akceptační testy: Testování, zda systém splňuje požadavky zákazníka nebo uživatele.
* Regresní testy: Ověření, že nově implementované změny neovlivnily již fungující části systému.
2. Nefunkční testy:
* Co testují: Hodnotí, jak se systém chová v různých situacích a jaké má vlastnosti mimo jeho funkčnost.
* Příklad testů:
* Testy použitelnosti: Ověření, zda je systém snadno použitelný pro uživatele.
* Bezpečnostní testy: Ověření, jak systém odolává hrozbám a útokům.
* Výkonnostní testy: Ověření, jak systém reaguje pod zátěží, jak zvládá velké množství dat nebo uživatelů.
38
Funkční testy
* Smoke test: Ověření, že aplikace je rámcově funkční. Zaměřuje se na hlavní funkce. Může být automatizováno.
* Sanity test: Ověřuje, že nové funkce nebo opravy fungují dostatečně pro pokračování testování. Může být automatizováno. Používá se při předávce vývojem do testování.
* Systémový test (Systémový integrační test): Ověřování funkčnosti programu jako celku, včetně integračních testů mezi systémy.
* Akceptační test: Test prováděný zadavatelem, zda systém funguje podle jeho představ.
39
Nefunkční testy
* Performance test (výkonový): Ověřuje, že systém zvládá požadovaný počet uživatelů a že výpočty trvají požadovaný čas. Používají se automatické nástroje jako JMeter.
* Stress test: Ověřuje robustnost systému vůči vyčerpání zdrojů, například paměti nebo diskového prostoru, a správnost ošetření chybových stavů.
* Penetrační test: Ověřuje bezpečnost systému vůči hackerským útokům.
40
Jaký je rozdíl mezi black box a white box testováním?
* Black box: Testujeme podle rozhraní, nezajímá nás implementace. Je robustnější a techniky vycházejí z uživatelských požadavků (dokumentace, use cases).
* White box: Testujeme se znalostí implementace, důkladnost testování je měřena strukturálním pokrytím. Je křehčí, protože změna implementace může testy rozbít.
41
Jaký je hlavní účel dokumentace ve vývoji software?
Dokumentace slouží k uchovávání informací, komunikaci mezi týmem a externími partnery, a zajištění budoucí údržby systému. Pomáhá uchovávat záznamy o domluvách a dohodách a slouží jako zdroj informací pro uživatele a administrátory systému.
42
Co je hlavní výhodou používání modelů a diagramů v dokumentaci?
Modely a diagramy umožňují efektivněji vyjádřit složité informace, které by bylo obtížné popsat textově. “Jeden obrázek za tisíc slov” pomáhá lépe porozumět chování systému.
43
Jaký je význam verzování dokumentace a jak se to provádí?
Verzování dokumentace pomáhá sledovat změny a zajistit, že používáme správnou verzi dokumentu. Používají se nástroje jako Git, SVN nebo Mercurial, které umožňují identifikaci a správu verzí souborů.
44
Co musí být provedeno, než se změna dostane do produkce?
* Implementace, testování a akceptace, nasazení do produkce.
45
Jaké typy prostředí existují?
* Vývojové, testovací, integrační, akceptační, předprodukční a produkční prostředí.
46
Jaké problémy mohou vzniknout při nasazování systému do různých prostředí?
* Integrace mezi aplikacemi, rozdílné vývojové cykly, zpoždění v dodávkách, různé verze na akceptačním prostředí a produkci.
47
Cíle release managementu
Jaké jsou hlavní cíle při správě vydání?
* Vyrobit, otestovat, popsat postup instalace, nasadit, migrovat data a zajistit správné fungování systému.
48
Co je to release, build, oprava buildu a instalační set?
* Release = verze aplikace, build = proces sestavení, oprava buildu = patch, instalační set = balíček pro nasazení aplikace.
49
Proč nelze vše dělat ručně při sestavování a nasazování aplikace?
* Ruční procesy jsou náchylné k chybám a nemohou se měřit s automatizovanými procesy, které přinášejí rychlost, opakovatelnost a bezpečnost.
50
Co znamená DevOps?
* DevOps je vývojový cyklus zaměřený na automatizaci každého kroku (build, test, release), s cílem zrychlit zpětnou vazbu a snížit chyby.
* „If you build it, you run it“ – tým by měl mít dovednosti k řešení všech fází vývoje, testování a nasazování.
51
Co zahrnuje DevOps cyklus?
* Build, test, release, deployment, monitoring, a integrace, vše s maximální automatizací.
52
Postupná změna v architektuře
Co je to “Strangler Pattern”?
* Technika pro postupné přechody mezi starým a novým systémem, kde nový systém postupně nahrazuje starý.
53
Jaký je princip bezodstávkového nasazování?
* Aplikace je nasazena bez výpadku služby pomocí pokročilé automatizace a „one-click deployment“.
54
Co je to Chaos Monkey a jak souvisí s DevOps?
* Nástroj pro testování odolnosti systémů tím, že náhodně způsobí výpadky služeb. Pomáhá připravit systémy na nečekané chyby a výpadky.
55
Co je Continuous Integration (CI)?
* Continuous Integration (CI) je proces, při kterém jsou změny kódu pravidelně integrovány do hlavní větve (master) projektu. Tento proces zahrnuje automatické sestavení a testování kódu, aby se zjistilo, zda nově přidaný kód neporušuje existující funkcionalitu.
* Cílem CI je rychle detekovat chyby a problémy, což usnadňuje jejich opravu.
56
Co je Continuous Delivery (CD)?
* Continuous Delivery (CD) je proces, při kterém je aplikace po úspěšném provedení automatizovaných testů a sestavení připravena k nasazení do produkce.
* Aplikace je vždy v „nasaditelném“ stavu, což znamená, že tým může kdykoli nasadit nové verze na produkční prostředí, aniž by bylo nutné provádět složité přípravy nebo manuální kroky.
* CD zahrnuje krok, kdy je kód připraven pro nasazení, ale nasazení do produkce může být provedeno manuálně nebo automaticky podle potřeby.
57
Co je Continuous Deployment (CD)?
* Continuous Deployment (CD) jde o krok dál než Continuous Delivery. Při Continuous Deployment je každý změněný kód, který prošel automatickými testy, automaticky nasazen na produkční prostředí.
* Tento proces eliminuje potřebu manuálního schvalování a umožňuje rychlé a časté nasazování nových funkcí a oprav do produkce.
* Continuous Deployment je ideální pro týmy, které chtějí minimalizovat zpoždění mezi vývojem a nasazením a maximálně využít automatizace.
58
Co znamená údržba?
Údržba zahrnuje:
* Udržení systému v provozu.
* Opravu chyb.
* Další rozvoj a adaptaci systému na změny.
59
Jaké jsou typy údržby dle ISO/IEC 14764?
* Corrective: Oprava nalezených chyb.
* Perfective: Zlepšení výkonu nebo udržovatelnosti.
* Adaptive: Přizpůsobení systému změně prostředí.
* Preventive: Detekce a oprava latentních chyb.
* Příklad: Přidání funkcionality pro lepší výkon (Perfective) nebo oprava chyby, která způsobuje havárii (Corrective).
60
Co je technická podpora a jaké má úrovně?
Technická podpora řeší chyby a pomáhá uživatelům. Má tři úrovně:
* L1: První kontakt, příjem hlášení.
* L2: Základní incidenty (restart komponenty).
* L3: Expertní podpora (vývojáři).
* Příklad: L1: „Jak obnovit zapomenuté heslo?“ L3: „Oprava kritické chyby databáze.“
61
Co je SLA a jaké parametry garantuje?
SLA (Service Level Agreement) definuje garantované služby a parametry, například:
* Dostupnost systému.
* Reakční dobu na incident.
* Čas na opravu chyby (fix-time).
Příklad: SLA stanovuje, že kritická chyba musí být opravena do 4 hodin.
62
Co obsahuje rámcová smlouva?
Rámcová smlouva stanovuje závazky dodavatele, jako je oprava chyb, vývoj nových funkcí nebo pohotovostní služby.
* Příklad: Oprava chyby s prioritou 1 do jedné hodiny od nahlášení.
63
Co je chyba a co se za ni nepovažuje?
* Chyba: Rozdíl oproti specifikaci, havárie systému, ztráta dat.
* Nechyba: Nespolupráce s nepodporovaným softwarem třetích stran.
* Příklad: Pokud systém nepodporuje starší prohlížeč, který není uveden ve specifikaci, není to chyba.
64
Jaké jsou klíčové principy údržby?
Dodržování principů softwarového inženýrství, zajištění akceschopného týmu, poskytování technické podpory a dodržování SLA.
* Příklad: Zajištění průběžného školení týmu pro práci s novými technologiemi.
65
Jaký je rozdíl mezi Team Leaderem (TL) a Project Managerem (PM)?
* PM: Zaměřuje se na strategickou a taktickou úroveň řízení projektu.
* TL: Zajišťuje operativní řízení týmu, propojuje technické detaily a manažerské úkoly.
* Příklad: PM plánuje rozpočet a termíny projektu, zatímco TL pomáhá vývojářům řešit technické problémy.
66
Jaké schopnosti musí mít dobrý TL?
* Kombinace technických a manažerských dovedností.
* Detailní znalost domény projektu.
* Schopnost jít do technických detailů i udržet nadhled.
* Komunikační dovednosti, delegování a řešení konfliktů.
* Příklad: TL by měl umět poradit s kódem a současně motivovat tým ke splnění cílů.
67
Co je Work Breakdown Structure (WBS)?
Hierarchická dekompozice cíle projektu, která odpovídá na otázku „co“ se má udělat, nikoliv „jak“.
* Příklad: Projekt na vývoj aplikace se rozloží na úlohy jako analýza, vývoj, testování.
68
Jaké jsou základní pravidla tvorby WBS?
* Pravidlo 100 %: Pokrýt všechny úkoly.
* Nepřekrývání úloh.
* Detailní úlohy nesmí přesáhnout časový limit (např. 40 hodin).
* Příklad: Úloha „Testování“ se rozdělí na „Test funkčnosti“ a „Regresní testování“, aby se zajistilo 100% pokrytí.
69
Co znamená Earned Value v projektovém řízení?
Metoda pro sledování pokroku projektu na základě plánovaných a skutečných hodnot (čas, náklady).
* Příklad: Úloha s odhadem 10 MDs byla dokončena za 8 MDs → Earned Value pomáhá odhadnout další průběh projektu.
70
Co je to Change Request (CR) a jak se řeší?
* CR je žádost o změnu v projektu, která může ovlivnit cenu, termín nebo rozsah.
* Řeší se v rámci Change Management Process (např. dokumentace dopadu změny na harmonogram).
* Příklad: Zákazník požaduje přidání nové funkce → CR posuzuje její vliv na rozpočet a termín.
71
Co je Velocity v agilním vývoji?
Metrika vyjadřující množství práce, kterou tým dokončí v jedné iteraci (měřeno ve story points, hodinách, apod.).
* Příklad: Tým má Velocity 30 SP za sprint → plánuje úlohy do sprintu na základě této kapacity.
72
Co je dobrý Team Leader?
Osoba, která jde týmu příkladem, rozumí technickým i manažerským požadavkům a udržuje tým v dobré pracovní kondici.
* Příklad: TL motivuje tým, řeší technické problémy a podporuje hladký průběh projektu.
73
Co zahrnuje proces získávání projektu?
Proces zahrnuje následující kroky:
* RFI: Zadavatel získává informace od dodavatelů.
* RFP: Zadavatel specifikuje požadavky na projekt.
* Nabídka: Dodavatel navrhuje řešení a cenu.
* Smlouva: Dohoda o podmínkách projektu.
Příklad: Zadavatel požádá dodavatele o návrh řešení systému evidence letů.
74
Jaké kapitoly by měla obsahovat nabídka?
Kapitoly nabídky:
1. Manažerské shrnutí
2. Představení dodavatele
3. Návrh řešení (funkční a nefunkční požadavky, architektura)
4. Organizace projektu (tým, rizika, plán)
5. Předpoklady a okrajové podmínky
6. Cena
Příklad: Funkční požadavky obsahují seznam funkcí systému, jako je evidence letů nebo generování statistik.
75
Co jsou funkční požadavky?
Specifikace toho, co systém musí dělat – jeho chování.
Příklad: “Systém umožňuje evidovat lety motorových a bezmotorových letadel.”
76
Co jsou nefunkční požadavky?
Požadavky na výkonnost, bezpečnost, lokalizaci nebo technické specifikace.
Příklad: “Systém bude dostupný jako webová aplikace s odezvou do 2 sekund.”
77
Na co si dát pozor při specifikaci datových vstupů?
* Povinnost vyplnění
* Ověřování vstupů (validace na klientovi i serveru)
* Chybové hlášky
Příklad: E-mail musí obsahovat „@“, jinak zobrazit hlášku „Neplatný formát e-mailu“.
78
Jaké otázky řeší návrh rozhraní systému?
* Timeouty spojení
* Návratové kódy
* Zabezpečení dat
Příklad: API pro piloty vrací kód 200 (úspěch) nebo 404 (pilot nenalezen).
79
Co je specifikace?
Specifikace je přesný a detailní popis požadavků, které musí projekt, aplikace nebo systém splňovat. V kontextu, který zmiňuješ, se specifikace týká toho, co má aplikace “Flight Log” umět, jaké funkce má obsahovat, jaké technologie se mají použít, a jak má být implementována.
