SEP

Question 1

Agilní metodika vývoje

Answer 1

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

Question 2

Waterfall

Answer 2

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

Question 3

Iterativní

Answer 3

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

Question 4

Co je základní koncept Software Process Improvement (SPI)?

Answer 4

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.

Question 5

Co je PDCA model? (Demingův cyklus)

Answer 5

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ů.

Question 6

Jaké jsou základní přístupy k Software Process Improvement (SPI)?

Answer 6

1. Systematický, dlouhodobý přístup
   – Preskriptivní (ISO, CMM, CMMI)
   – Induktivní (SEL/NASA)

Question 7

Co jsou preskriptivní přístupy k SPI?

Answer 7

Přístupy, které vycházejí z předpokladu, že správné praktiky vývoje softwaru jsou známé, a tyto postupy předepisují

Question 8

Co jsou induktivní přístupy k SPI?

Answer 8

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

Question 9

Co je CMM (Capability Maturity Model)?

Answer 9

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í)

Question 10

Co je CMMI a jak se liší od staršího CMM? (Capability Maturity Model Integration)

Answer 10

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

Question 11

Jaká je základní premisa přístupu SEL (Software Engineering Laboratory) / NASA?

Answer 11

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ů

Question 12

Co jsou SPMN Best Practices?

Answer 12

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’

Question 13

Co je rozdíl mezi RFI a RFP?

Answer 13

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

Question 14

Jaké jsou různé módy spolupráce v rámci projektů a jejich charakteristiky?

Answer 14

1. 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.
2. 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.
3. 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.

Question 15

Jaký je rozdíl mezi odhadem, závaznou pracností a cenou?

Answer 15

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é.

Question 16

Jaké metody odhadu se používají a co je kužel nejistoty?

Answer 16

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)

Question 17

Proč je nutná revize odhadů a co obsahují checklisty?

Answer 17

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ů.

Question 18

Proč je důležité Requirements Engineering?

Answer 18

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.

Question 19

Co jsou požadavky v obecném smyslu?

Answer 19

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.

Question 20

Jak jsou definovány požadavky v IT?

Answer 20

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.

Question 21

Co zahrnuje věcný obsah IT požadavku?

Answer 21

• 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.

Question 22

Jaké typy požadavků existují?

Answer 22

1. Byznysové požadavky (Business requirements) – Pohled zadavatele nebo organizace, zaměřené na vysokou úroveň cílů a obchodní potřeby.
   
   2. Uživatelské požadavky (User requirements) – Pohled budoucího uživatele, zaměřené na funkčnost a uživatelský zážitek.
   3. 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.

Question 23

Co jsou byznysové požadavky a jaký je jejich fokus?

Answer 23

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í.

Question 24

Co jsou uživatelské požadavky a jaký je jejich fokus?

Answer 24

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ů.

Question 25

Co jsou systémové požadavky a jaký je jejich fokus?

Answer 25

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.

Question 26

Jaké je zaměření požadavků? Uveď příklady.

Answer 26

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.

Question 27

Jaká je míra očekávání od požadavku? Uveď příklady.

Answer 27

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.

Question 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

Answer 28

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ý?

Question 29

Jaký je kontext, vstupy a výstupy v Requirements Engineering?

Answer 29

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.

Question 30

Jaké jsou fáze procesu Requirements Engineering?

Answer 30

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.

Question 31

Co je to projekt a jak se liší od procesu?

Answer 31

• 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.

Question 32

Co jsou metodiky pro projektové řízení a jaké jsou příklady tradičních a agilních metodik?

Answer 32

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.

Question 33

Jaký je rozdíl mezi software architekturou a software designem?

Answer 33

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.

Question 34

Jaké jsou základy dobrého objektově orientovaného návrhu?

Answer 34

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

Question 35

Jaké jsou cíle testování v softwarovém vývoji?

Answer 35

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.

Question 36

Jaký je rozdíl mezi statickým a dynamickým testováním?

Answer 36

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.

Question 37

Jaké jsou typy testů a co testují?

Answer 37

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ů.

Question 38

Funkční testy

Answer 38

• 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.

Question 39

Nefunkční testy

Answer 39

• 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.

Question 40

Jaký je rozdíl mezi black box a white box testováním?

Answer 40

• 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.

Question 41

Jaký je hlavní účel dokumentace ve vývoji software?

Answer 41

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.

Question 42

Co je hlavní výhodou používání modelů a diagramů v dokumentaci?

Answer 42

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.

Question 43

Jaký je význam verzování dokumentace a jak se to provádí?

Answer 43

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ů.

Question 44

Co musí být provedeno, než se změna dostane do produkce?

Answer 44

• Implementace, testování a akceptace, nasazení do produkce.

Question 45

Jaké typy prostředí existují?

Answer 45

• Vývojové, testovací, integrační, akceptační, předprodukční a produkční prostředí.

Question 46

Jaké problémy mohou vzniknout při nasazování systému do různých prostředí?

Answer 46

• 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.

Question 47

Cíle release managementu
Jaké jsou hlavní cíle při správě vydání?

Answer 47

• Vyrobit, otestovat, popsat postup instalace, nasadit, migrovat data a zajistit správné fungování systému.

Question 48

Co je to release, build, oprava buildu a instalační set?

Answer 48

• Release = verze aplikace, build = proces sestavení, oprava buildu = patch, instalační set = balíček pro nasazení aplikace.

Question 49

Proč nelze vše dělat ručně při sestavování a nasazování aplikace?

Answer 49

• 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.

Question 50

Co znamená DevOps?

Answer 50

• 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í.

Question 51

Co zahrnuje DevOps cyklus?

Answer 51

• Build, test, release, deployment, monitoring, a integrace, vše s maximální automatizací.

Question 52

Postupná změna v architektuře
Co je to “Strangler Pattern”?

Answer 52

• Technika pro postupné přechody mezi starým a novým systémem, kde nový systém postupně nahrazuje starý.

Question 53

Jaký je princip bezodstávkového nasazování?

Answer 53

• Aplikace je nasazena bez výpadku služby pomocí pokročilé automatizace a „one-click deployment“.

Question 54

Co je to Chaos Monkey a jak souvisí s DevOps?

Answer 54

• 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.

Question 55

Co je Continuous Integration (CI)?

Answer 55

• 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.

Question 56

Co je Continuous Delivery (CD)?

Answer 56

• 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.

Question 57

Co je Continuous Deployment (CD)?

Answer 57

• 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.

Question 58

Co znamená údržba?

Answer 58

Údržba zahrnuje:
* Udržení systému v provozu.
* Opravu chyb.
* Další rozvoj a adaptaci systému na změny.

Question 59

Jaké jsou typy údržby dle ISO/IEC 14764?

Answer 59

• 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).

Question 60

Co je technická podpora a jaké má úrovně?

Answer 60

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.“

Question 61

Co je SLA a jaké parametry garantuje?

Answer 61

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.

Question 62

Co obsahuje rámcová smlouva?

Answer 62

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í.

Question 63

Co je chyba a co se za ni nepovažuje?

Answer 63

• 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.

Question 64

Jaké jsou klíčové principy údržby?

Answer 64

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.

Question 65

Jaký je rozdíl mezi Team Leaderem (TL) a Project Managerem (PM)?

Answer 65

• 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.

Question 66

Jaké schopnosti musí mít dobrý TL?

Answer 66

• 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ů.

Question 67

Co je Work Breakdown Structure (WBS)?

Answer 67

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í.

Question 68

Jaké jsou základní pravidla tvorby WBS?

Answer 68

• 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í.

Question 69

Co znamená Earned Value v projektovém řízení?

Answer 69

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.

Question 70

Co je to Change Request (CR) a jak se řeší?

Answer 70

• 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.

Question 71

Co je Velocity v agilním vývoji?

Answer 71

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.

Question 72

Co je dobrý Team Leader?

Answer 72

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.

Question 73

Co zahrnuje proces získávání projektu?

Answer 73

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ů.

Question 74

Jaké kapitoly by měla obsahovat nabídka?

Answer 74

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.

Question 75

Co jsou funkční požadavky?

Answer 75

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.”

Question 76

Co jsou nefunkční požadavky?

Answer 76

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.”

Question 77

Na co si dát pozor při specifikaci datových vstupů?

Answer 77

• 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“.

Question 78

Jaké otázky řeší návrh rozhraní systému?

Answer 78

• Timeouty spojení
  
  • Návratové kódy
  • Zabezpečení dat
    Příklad: API pro piloty vrací kód 200 (úspěch) nebo 404 (pilot nenalezen).

Question 79

Co je specifikace?

Answer 79

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.