686 lines
39 KiB
Markdown
686 lines
39 KiB
Markdown
|
Popište **smysl pyramidy vitality** a význam jejích **jednotlivých pater** (základní obrázek budete mít k dispozici)
|
|||
|
- popisuje budování firmy a její úspešné fungování
|
|||
|
1. **dynamika** - řízení změn a ovlivňování vývoje, vztahů
|
|||
|
2. **stabilita** - vyrovnávání se se změnami a potížemi
|
|||
|
3. **efektivita** - nízké náklady, pořádek v procesech, ...
|
|||
|
4. **užitečnost** - máme co nabídnout, víme komu a proč
|
|||
|
|
|||
|
Popište smysl **Maslowovy pyramidy potřeb** a význam jejích **jednotlivých pater** (základní obrázek budete mít k dispozici)
|
|||
|
- popisuje univerzální lidské potřeby
|
|||
|
1. **smysl** - seberealizace, osobní rozvoj, užitečnost pro jiné
|
|||
|
2. **výlučnost** - uznání ostatními, potřeba někam patřit a vynikat
|
|||
|
3. **příslušnost** - možnost počítat s tím, že někam patřím (rodina, škola, přátelé)
|
|||
|
4. **bezpečí** - zajištění základních potřeb na přežití do budoucna
|
|||
|
5. **přežití** - pokytí základních potřeb - metabolismus, reprodukce
|
|||
|
|
|||
|
Popište a vysvětlete základní schéma zajišťování **užitečnosti**: **Subjekty ‐> Potřeby ‐> Produkty**
|
|||
|
- **subjekty**
|
|||
|
- komu budeme užiteční? (majitelé, zákazníci, zaměstnanci)
|
|||
|
- **potřeby**
|
|||
|
- důležité je subjektivní vnímání vlastních potřeb
|
|||
|
- většina potřeb univerzální
|
|||
|
- **produkty**
|
|||
|
- jejich definice je v IT důležitá
|
|||
|
- dělení
|
|||
|
- pro majitele: prestiž, image
|
|||
|
- pro zákazníky: výrobky, služby
|
|||
|
- pro zaměstnance: mzdy, benefity
|
|||
|
|
|||
|
Popište a vysvětlete základní schéma zajišťování **efektivity**: **Procesy-> Zdroje-> Struktury**
|
|||
|
- **procesy**
|
|||
|
- opakovaně probíhající transformace vstupu na výstup
|
|||
|
- i malé zlepšení se významně projeví
|
|||
|
- **zdroje**
|
|||
|
- pro zajištění procesů, nespotřebávají se
|
|||
|
- dělení:
|
|||
|
- **tvrdé** - materiál, energie, informační systém
|
|||
|
- **lidské** - vlastnosti, schopnosti a postoje lidí
|
|||
|
- **specifické** - systém firemních myšlenek
|
|||
|
- **struktury**
|
|||
|
- odvozeny od procesů ve firmě
|
|||
|
- odpovědnost za běh procesů a kvalitu zdrojů
|
|||
|
- organizační struktura firmy (vedení, řízení, výkon)
|
|||
|
|
|||
|
Popište a vysvětlete princip **dvou nezbytných podmínek stability**: **cyklického řízení a podpory lidí**
|
|||
|
- **stabilita** - schopnost hledat rovnováhu (adaptovat se na změnu)
|
|||
|
- **cyklické řízení**
|
|||
|
- učení se z vlastních výsledků a zpětné vazby
|
|||
|
- zavedení nových prvků do řízení (stanovení cílů, vyhodnocení výsledků, korekce)
|
|||
|
- **podpora lidí**
|
|||
|
- cyklický model potřebuje podporu a pochopení od lidí
|
|||
|
- musí být srozumitelný a přijatelný pro většinu lidí
|
|||
|
- firma vedená
|
|||
|
- **lidmi** - nadřízení mají věci pod kontrolou
|
|||
|
- **myšlenkami** - lidé se méně obrací na nadřízené, řeší problémy podle firemních cílů a myšlenek
|
|||
|
|
|||
|
Popište a vysvětlete princip **dvou nezbytných podmínek dynamiky**: **proaktivního cyklického řízení a aktivity lidí**
|
|||
|
- firma je užitečná, efektivní a stabilní -> bere změny do své režie a ovlivňuje dynamiku vlastní i svého okolí
|
|||
|
- **proaktivní cyklické řízení** (tvrdá podmínka)
|
|||
|
- nekompromisní požadavek na změnu
|
|||
|
- schopnost odhadnout budoucí vývoj a rozhodovat se podle toho
|
|||
|
- učit sám sebe, procesy a systémy by měly být schopny se samy vylepšovat, systém zpětných vazeb
|
|||
|
- **aktivity lidí** (měkká podmínka)
|
|||
|
- podpora spontánní aktivity, tvůrčí práce a zapojení zaměstnanců do řešení problémů a rozhodování (za rozhodování je ale stále zodpovědný manažer)
|
|||
|
|
|||
|
Popište význam, důležitost a možnost **změny** následujících **lidských zdrojů**: **vlastností**, **schopností** a **postojů**
|
|||
|
- **vlastnosti**
|
|||
|
- zděděné rysy osobnosti člověka spojené s biologickou a psychickou podstatou
|
|||
|
- téměr nezměnitelné, člověka s určitými vlastnosti nelze vychovávat
|
|||
|
- spíše nedůležité (důležité např. pro rozdělení rolí v týmu)
|
|||
|
- **schopnosti**
|
|||
|
- znalosti (co teoreticky umíme), dovednosti (co prakticky umíme)
|
|||
|
- je to lidský potenciál, který se dá rozvíjet (snížení nároků, rozvíjení schopností)
|
|||
|
- nedůležité, dá se doučit
|
|||
|
- **postoje**
|
|||
|
- míra snahy a ochoty pracovat, loajalita a motivace daného člověka
|
|||
|
- důležité pro týmovou práci
|
|||
|
- v menší míře měnitelné (motivační programy)
|
|||
|
|
|||
|
Popište **princip soutěživého vztahového chování**; jakým způsobem dokážete **soutěž vyvolat**, či naopak **potlačit**
|
|||
|
- **soutěžení**
|
|||
|
- prospěch na úkor jiných
|
|||
|
- přirozená lidská potřeba zvítězit
|
|||
|
- dlouhodobě udržitelné mezi konkurenty
|
|||
|
- **vyvolání**
|
|||
|
- stejné úkoly pro všechny, relativní hodnocení
|
|||
|
- **potlačení**
|
|||
|
- nelze zcela potlačit, ale možné přesměrovat mimo skupinu (s jinou skupinou, mezi firmami)
|
|||
|
- rozdělením rolí v týmu, aby více lidí nedělalo na stejné věci
|
|||
|
|
|||
|
Popište **princip spolupráce**; jakým způsobem dokážete spolupráci **podpořit**
|
|||
|
- **spolupráce**
|
|||
|
- dlouhodobá žádoucí taktika vnitřních vztahů vůči vnějším subjektům, se kterými nejsme v přímé konkurenci
|
|||
|
- menší potenciál než soutěžení (spolupráce pouze, když je to výhodné)
|
|||
|
- **podpoření**
|
|||
|
- zadávání úkolů tak, že mohou uspět jedině dohromady (potřeba si pomáhat)
|
|||
|
- rozlišení rolí ve skupině a zvýšení závislosti mezi lidmi ve skupině
|
|||
|
- absolutní hodnocení, odměna pro všechny, kteří dosáhnou výsledku
|
|||
|
|
|||
|
Proč se zabýváme **požadavky na software**? **Pro koho** jsou sesbírané a zdokumentované požadavky na software **užitečné**?
|
|||
|
- **požadavek**
|
|||
|
- vlastnosti a parametry softwaru, které defunují jeho užitečnost pro zúčastněné
|
|||
|
- popis toho, co je potřeba implementovat, žádaných chování systému s jeho vlastnostmi a možných omezení procesu vývoje
|
|||
|
- **užitečné pro**
|
|||
|
- **zákazníky** - financují projekt a chtějí dostat systém, který pokryje jejich potřeby
|
|||
|
- **zaměstance** - definují požadavky, které se poté navrhují, implementují a udržují
|
|||
|
|
|||
|
Vysvětlete pojmy **podnikatelské** a **uživatelské požadavky**.
|
|||
|
- **podnikatelské požadavky**
|
|||
|
- formulují strategický rámec organizace (zákazníka) - proč organizace systém chce a čeho jeho zavedením dosáhne
|
|||
|
- často samostatný dokument (charta projektu) - popis vize a rozsahu projektu
|
|||
|
- **uživatelské požadavky**
|
|||
|
- popis cílů uživatelů a toho, co od systému očekávají (případy použití, scénáře)
|
|||
|
- procesy z pohledu managementu a vykonavatelů
|
|||
|
- mohou být v rozporu s podnikatelskými (poté komunikace o cílech a omezeních)
|
|||
|
|
|||
|
Vysvětlete pojmy **podnikatelská pravidla** a **parametrické (mimofunkční) požadavky**.
|
|||
|
- **podnikatelská pravidla**
|
|||
|
- firemní předpisy, státní nařízení, průmyslové standardy, ...
|
|||
|
- říkají, jaké postupy by měly být dodržovány
|
|||
|
- **parametrické požadavky**
|
|||
|
- požadavky, které nesouvisejí s funkcionalitou, ale mají na ní vliv
|
|||
|
- zaměřují se na výkon, spolehlivost a bezpečnost
|
|||
|
|
|||
|
Vysvětlete **význam podpisu dokumentu specifikace požadavků**.
|
|||
|
- stvrzuje nejlepší možnou závaznou dohodu v daném čase, ale umožňuje následné změny
|
|||
|
- potvrzení toho, že si obě strany specifikaci přečetli a rozumí ji
|
|||
|
|
|||
|
Uveďte alespoň **tři dobré zvyky**, které jste použili **při psaní specifikace požadavků** během vašeho týmového projektu. Vysvětlete význam těchto dobrých zvyků.
|
|||
|
- definice **vize** a **rozsahu** projektu - pochopení toho, co zadavatel chce, a jistota, že to stihneme vytvořit v učitém čase
|
|||
|
- pochopení prostředí
|
|||
|
- stanovení používaných **technologií** a podporovaných **zařízeních**
|
|||
|
- nakreslení **kontextového diagramu**
|
|||
|
- **verzování** specifikace požadavků (postupný vývoj SW)
|
|||
|
|
|||
|
Vysvětlete **pojem vize** a popište význam **uvedení vize** a **stanovení rozsahu** v dokumentu specifikace požadavků.
|
|||
|
- **vize**
|
|||
|
- společný směr všem investorům
|
|||
|
- k čemu software je a co by se z něj v budoucnu mělo stát, vize se mění poměrně zvolna, rozsah se v čase upravuje dle termínů, rozpočtu, kvality, …
|
|||
|
- **rozsah**
|
|||
|
- podmnožinou vize, řádně definuje, která část dlouhodobé vize bude zpracovávána aktuálním projektem
|
|||
|
- co projekt bude řešit a co už ne (rozsah zároveň definuje omezení)
|
|||
|
|
|||
|
Vysvětlete **princip a použití kontextového diagramu** a **diagramu případu užití** v rámci specifikace požadavků. Nakreslete jednoduché příkladové obrázky.
|
|||
|
- **kontextový diagram**
|
|||
|
- říká, jakým způsobem systém souvisí a komunikuje (přímo) s entitatmi okolo
|
|||
|
- používá se jako nástroj k pochopení prostředí
|
|||
|
- **diagram případů užití**
|
|||
|
- znázorňuje uživatelské požadavky a jak se systémem uživatelská role pracuje
|
|||
|
- využívá asociačních vazeb
|
|||
|
- používá se jako nástroj k popisu funkcionality systému
|
|||
|
|
|||
|
**Jakým způsobem získáte požadavky od uživatelů systému**? Uveďte základní praktiky.
|
|||
|
- najdeme všechny **třídy uživatelů systému** (dle používaných funkcí, frekvence používání, úkolů, …)
|
|||
|
- najdeme **zdroje uživatelských požadavků** (rozhovory s potenciálními uživateli, dokumentace popisující stávající nebo konkurenční systémy, chybová hlášení, sledování uživatelů při práci, …)
|
|||
|
- vybereme **zástupce jednotlivých uživatelských tříd** nebo účastníků a pracujeme s nimi
|
|||
|
- dohodneme se, kdo bude **rozhodovat o požadavcích** (řešení protichůdných požadavků uživatelů)
|
|||
|
- **zapojení uživatelů** je jediný způsob, jak se vyhnout rozdílům mezi očekáváním a skutečným systémem
|
|||
|
|
|||
|
Najděte problémy v následujícím zadání požadavku a opravte ho: „**Editor by měl okamžitě zobrazit/schovat všechny formátovací značky**.“
|
|||
|
- nejednoznačnost ve výrazu "**formátovací značky**" - není dostatečně specifický
|
|||
|
- nejasnost časové složky ve výrazu "**okamžitě**" - není dostatečně specifikován
|
|||
|
- oprava: "Editor musí poskytnout možnost zobrazení (nejpozději do 2s od interakce uživatele) nebo skrytí vybraného typu formátování - např. HTML značek, textových stylů."
|
|||
|
|
|||
|
Popište **smysl a náplň** čtyř základních aktivit při vývoji sw: **specifikace**, **vývoj**, **validace**, **evoluce**.
|
|||
|
- **specifikace**
|
|||
|
- definice SW produktu, vytvoření specifikace požadavků (víme co máme dělat)
|
|||
|
- náplň: vytvoření funkčních požadavků, diagramů
|
|||
|
- **vývoj**
|
|||
|
- vytváření SW produktu, který splňuje specifikaci
|
|||
|
- náplň: návrh a implementace funkcí
|
|||
|
- **validace**
|
|||
|
- ověření že produkt je správný, spolehlivý a funkční
|
|||
|
- náplň: různé testovací techniky, konzultace se zákazníkem
|
|||
|
- **evoluce**
|
|||
|
- přizpůsobení SW měnícím se požadavkům zákazníka + nabídka další funkčnosti
|
|||
|
- náplň: úpravy, rozšíření a zlepšování výkonu SW
|
|||
|
|
|||
|
Popište **vodopádový model vývoje sw**, uveďte jeho **výhody a nevýhody**.
|
|||
|
- vývoj rozdělen do několika definovaných fází
|
|||
|
- po splnění jedné fáze se fáze ukončí a přechází se na další fázi (chybí zpětné vazby)
|
|||
|
- **výhody**
|
|||
|
- přehledný a použitelný pro malé projekty
|
|||
|
- **nevýhody**
|
|||
|
- málo flexibilní, dlouhá prodleva mezi zadáním projektu a vytvořením systému
|
|||
|
- obtížné reakce na změny požadavků zákazníka
|
|||
|
- zákazník může na konci zjistit, že vytvořený produkt není to, co chtěl
|
|||
|
|
|||
|
Popište modely vývoje sw: **výzkumník** (evoluční prototypování) a **prototyp** (throw-away prototypování), uveďte **vhodnou oblast jejich použití**.
|
|||
|
- **evoluční model vývoje**
|
|||
|
- specifikace, vývoj a validace jsou smíšené
|
|||
|
- ze specifikace je velmi rychle vyvinut prvotní systém a ten je dále upravován na základě zákazníka
|
|||
|
- **výzkumník**
|
|||
|
- cílem je pracovat se zákazníkem na zajištění jeho požadavků
|
|||
|
- vývoj začíná dobře srozumitelnými částmi systému a vyvíjí se přidáváním nových vlastností navrhovaných zákazníkem, při vývoji se často vrací k předchozím etapám
|
|||
|
- oblast použití
|
|||
|
- inovativní projekty, kde nejsou přesně definované požadavky
|
|||
|
- **prototyp**
|
|||
|
- tvorba prototypu, který se pak zahodí
|
|||
|
- prototyp se zaměřuje na ty části požadavků zákazníka, kterým moc nerozumíme
|
|||
|
- prototyp je částečně zavedený produkt se všemi vnějšími rozhraní
|
|||
|
- oblast použití
|
|||
|
- v situacích, kdy je nutné rychlé získání zpětných vazeb od zákazníka
|
|||
|
- např. vývoj uživatelského rozhraní
|
|||
|
|
|||
|
Vysvětlete základní **principy iteračního a inkrementálního modelu** vývoje sw.
|
|||
|
- **iterační model**
|
|||
|
- vývoj probíhá ve více opakováních, kde každá iterace zdokonaluje SW
|
|||
|
- SW se s každou iterací postupně zlepšuje na základě získané zpětné vazby
|
|||
|
- možnost změny požadavků mezi iteracemi
|
|||
|
- pravidelná komunikace s klientem
|
|||
|
- **inkrementální model**
|
|||
|
- SW je vyvíjen a dodáván ve formě inkrementů, které přidávají nové funkcionality
|
|||
|
- každý inkrement je integrován s předchozími inkrementy a testován jako celek
|
|||
|
- funkcionality jsou přidávány na základě jejich důležitosti
|
|||
|
- každý inkrement je sám o sobě použitelný a přináší užitek zákazníkovi
|
|||
|
|
|||
|
Popište základní **principy**, **fáze** a **aktivity** metodiky **Rational Unified Proces** (RUP).
|
|||
|
- **principy**
|
|||
|
- iterační způsob vývoje SW, inkrementální rozšiřování
|
|||
|
- iterace končí vytvořením spustitelného systému
|
|||
|
- průběžné ověřování kvality (princip zpětné vazby), použití UML
|
|||
|
- **fáze**
|
|||
|
- **zahájení** - výsledkem vize koncového SW
|
|||
|
- **rozpracování** - výsledkem je specifikace požadavků a navržená architektura SW
|
|||
|
- **tvorba** - výsledkem je kompletně implementovaný a otestovaný SW
|
|||
|
- **předání** - výsledkem je předaný SW produkt
|
|||
|
- **aktivity**
|
|||
|
- byznys modelovaní, specifikace požadavků, analýza a návrh, implementace, testování, nasazení
|
|||
|
|
|||
|
Vysvětlete **zásadní rozdíly mezi agilním přístupem** k vývoji sw a **vodopádovým modelem**.
|
|||
|
- **agilní přístup**
|
|||
|
- iteratiní a inkrementální vývoj s krátkými iteracemi
|
|||
|
- komunikace mezi zákazníkem a vývojovým týmem
|
|||
|
- průběžné automatizované testování
|
|||
|
- **vodopádový model**
|
|||
|
- zastaralý, méně flexibilní, pomalejší
|
|||
|
- málo komunikace se zákazníkem
|
|||
|
|
|||
|
Vysvětlete **základní principy agilní metodiky vývoje**, vysvětlete **pojem SCRUM**.
|
|||
|
- **agilní metodiky**
|
|||
|
- metodiky odpovídají inkrementálnímu modelu
|
|||
|
- efektivnější možnost změny
|
|||
|
- přednost kladena na
|
|||
|
- individuality a interakce
|
|||
|
- spolupráci se zákazníkem
|
|||
|
- reakce na změny
|
|||
|
- **SCRUM**
|
|||
|
- princip agilní inkrementální metodiky vývoje
|
|||
|
- postavený na týmové spolupráci
|
|||
|
- získávání časté zpětné vazby
|
|||
|
- transparentní komunikace v rámci týmu, firmy i směrem k zákazníkovi
|
|||
|
|
|||
|
Jak byste **prakticky postupovali při zavádění modelu vývoje sw**?
|
|||
|
- důležité je určit pořadí kroků, abychom mohli vybrat model, který bude sedět na naše požadavky:
|
|||
|
- **vodopádový model**
|
|||
|
- základní model, konzistentní se strukturovaným programováním shora dolů
|
|||
|
- je vhodný, pokud jsou známe požadavky (platformy, překladače, ...)
|
|||
|
- **evoluční vývoj**
|
|||
|
- pokud části požadavků nejsou zřejmé, např.: uživatelské rozhraní (nevím, co chci, ale poznám to až to uvidím)
|
|||
|
- **kompletně orientovaný vývoj**
|
|||
|
- máme-li vhodné komponenty
|
|||
|
- **inkrementální vývoj**
|
|||
|
- potřebujeme omezit přepracování, dodáváme systém po částech
|
|||
|
|
|||
|
**Co je to projekt? Jaký je rozdíl mezi projektem a procesem?**
|
|||
|
- **projekt**
|
|||
|
- časově omezená pracovní činnost
|
|||
|
- dočasný, pevně stanovený začátek a konec, jednoznačný cíl
|
|||
|
- má zákazníka nebo zadavatele
|
|||
|
- **proces**
|
|||
|
- opakovaně probíhající transformace vstupu na výstup
|
|||
|
- skládá se z jasně stanovených posloupností aktivit
|
|||
|
- **rozdíly**
|
|||
|
- procesy jsou většinou dlouhodobé a opakující se, projekty jsou jednorázové
|
|||
|
- proces je vnitřní organizace firmy, o projektu ví spoustu lidí okolo
|
|||
|
- proces je přesně určen a stanoven, projekt se v průběhu práce mění a přepracovává
|
|||
|
|
|||
|
Co znamená **trojí (čtvero) omezení projektu**?
|
|||
|
- každý projekt je omezen - **rozsahem**, **časem**, **náklady** a někdy **kvalitou**
|
|||
|
- je vhodné nalézt rovnováhu mezi těmito omezeními
|
|||
|
- nutnost přijímat kompromisy
|
|||
|
- abychom splnili termín, musíme redukovat rozsah a snížit náklady
|
|||
|
|
|||
|
Vysvětlete pojmy **Ganttův diagram** a **struktura rozpisu prací (WBS)**. Uveďte ilustrační příklady.
|
|||
|
- **Ganttův diagram**
|
|||
|
- definuje, jaké jednotlivé činnosti se budou během projektu provádět
|
|||
|
- k činnostem definuje přesný časový interval doby trvání
|
|||
|
- udává návaznost jednotlivých činností na sebe
|
|||
|
- **Struktura rozpisu prací**
|
|||
|
- hierarchický rozklad cíle projektu na jednotlivé dodávané výsledky a postupně až na jednotlivé pracovní balíky
|
|||
|
|
|||
|
Popište **princip práce s repository** (**GIT**).
|
|||
|
- systém pro verzování projektu, možnost spolupráce více lidí na jednom projektu
|
|||
|
- možnost vytvářet větve (branch)
|
|||
|
- základní operace
|
|||
|
- **init** - založení repozitáře
|
|||
|
- **commit** - uložení změn do lokálního repozitáře
|
|||
|
- **pull** - stáhnutí vzdáleného repozitáře do lokálního
|
|||
|
- **push** - nahrání lokálního repozitáře do vzdáleného
|
|||
|
|
|||
|
Co je to **UML** a k čemu ho použiji?
|
|||
|
- Unified Modeling Language
|
|||
|
- otevřený a rozšířitelný standard pro vizuální modelování
|
|||
|
- možnost tvorby různých diagramů pro různé situace
|
|||
|
- modely v UML obsahují:
|
|||
|
- statickou strukturu (jaké objekty jsou důležité a jak spolu souvisí)
|
|||
|
- dynamické chování (vzájemná spolupráce objektů)
|
|||
|
- použití
|
|||
|
- modelování objektově orientovaných systémů
|
|||
|
- ke komunikaci mezi vývojáři a zákazníky
|
|||
|
|
|||
|
Vysvětlete základní **princip a použití UML diagramu případů užití**. Nakreslete příkladový obrázek.
|
|||
|
- znázorňuje uživatelský požadavek a jak se systémem uživatelská role pracuje
|
|||
|
- využívá asociačních vazeb
|
|||
|
- používá se jako nástroj k popisu funkcionality systému
|
|||
|
|
|||
|
Vysvětlete základní **princip a použití UML diagramu tříd**. Nakreslete příkladový obrázek.
|
|||
|
- popisuje statickou strukturu a vztahy mezi třídami
|
|||
|
- atributy, operace, třídy a jejich vztahy: dědičnost, závislost, asociace
|
|||
|
- slouží jako nástroj ke komunikaci mezi vývojáři, architekty
|
|||
|
- slouží k analýze systému
|
|||
|
|
|||
|
Vysvětlete základní **princip a použití UML stavového diagramu**. Nakreslete příkladový obrázek.
|
|||
|
- popisuje chování systému s ohledem na jeho různé stavy
|
|||
|
- zachycuje, jak se systém mění mezi různými stavy v reakci na události nebo akce
|
|||
|
- používá se k modelování chování SW systémů nebo hardwarových zařízení
|
|||
|
|
|||
|
Vysvětlete základní **princip a použití UML sekvenčního diagramu**. Nakreslete příkladový obrázek.
|
|||
|
- dynamický diagram
|
|||
|
- znázorňuje spolupráci instancí v čase
|
|||
|
- zachycuje, jak spolu objekty komunikují a jak si vyměňují zprávy
|
|||
|
- slouží ke znázornění scénářů
|
|||
|
- reprezentace systému
|
|||
|
- nepřerušovaná čára - zpráva (volání metody)
|
|||
|
- přerušovaná čára - návratová hodnota
|
|||
|
- svislý obdélník - instance existuje (pokud je tam přerušovaná zpráva, pak neexistuje)
|
|||
|
|
|||
|
Vysvětlete základní **princip a použití UML diagramu aktivit**. Nakreslete příkladový obrázek.
|
|||
|
- popisuje tok činností a chování systému
|
|||
|
- pomáhá k identifikaci problémových oblastí
|
|||
|
- používá se k analýze a plánování toku informací
|
|||
|
- reprezentace systému
|
|||
|
- uzly - různé činnosti
|
|||
|
- hrany - tok mezi činnostmi
|
|||
|
- rozhodovací body - podmínka
|
|||
|
- synchronizační body - čekání na splnění určitých podmínek
|
|||
|
|
|||
|
Vysvětlete základní **princip a použití** alespoň jednoho z následujících UML diagramů: **diagram nasazení, diagram komponent**. Nakreslete příkladový obrázek.
|
|||
|
- **diagram komponent**
|
|||
|
- statický diagram
|
|||
|
- komponenta zapouzdřuje implementaci a zveřejňuje množinu rozhraní
|
|||
|
- říká, jaké kompomenty v systému jsou
|
|||
|
- jak spolu interagují
|
|||
|
- jaká mají rozhraní a jak spolu souvisí
|
|||
|
- používá se při návrhu SW (oblast architektury)
|
|||
|
- pro identifikaci komponent systému, jejich funkcí, závislostí a rozhraní
|
|||
|
|
|||
|
Vysvětlete **pojem analytický model**, popište, jak vypadá **analytická třída**
|
|||
|
- **analytický model**
|
|||
|
- vždy v jazyku domény
|
|||
|
- zachycuje problém z určité perspektivy
|
|||
|
- obsahuje artefakty modelující problémovou doménu
|
|||
|
- vypráví příběh o požadovaném systému
|
|||
|
- **analytická třída**
|
|||
|
- obsahuje množinu hlavních kandidátů na atributy a množinu hlavních operací
|
|||
|
- z názvu je jasný její účel
|
|||
|
- modeluje jeden specifický element problémové domény
|
|||
|
- má málo vazeb na okolní třídy
|
|||
|
|
|||
|
Vysvětlete **pojmy asociace, spojení, závislost**.
|
|||
|
- asociace
|
|||
|
- vztah mezi dvěma nebo více objekty, který vyjadřuje, že tyto objekty spolu nějakým způsobem souvisí
|
|||
|
- spojení
|
|||
|
- vztah, kdy jeden objekt vlastní nebo obsahuje druhý objekt
|
|||
|
- závislost
|
|||
|
- vztah mezi dvěma objekty, který vyjadřuje, že jeden objekt potřebuje nebo je závislý na druhém objektu pro provedení určité operace
|
|||
|
|
|||
|
Vysvětlete **pojmy asociace, agregace, kompozice**.
|
|||
|
- asociace
|
|||
|
- vztah mezi dvěma nebo více objekty, který vyjadřuje, že tyto objekty spolu nějakým způsobem souvisí
|
|||
|
- nejvolnější vztah
|
|||
|
- obousměrná
|
|||
|
- agregace
|
|||
|
- vztah, kde jedna část může existovat nezávisle na celku
|
|||
|
- jednosměrná asociace
|
|||
|
- kompozice
|
|||
|
- vztah, kde je jeden objekt součástí druhého a nemůže bez něj existovat
|
|||
|
- nejsilnější vazba
|
|||
|
|
|||
|
Vysvětlete **rozdíl a návaznost** mezi **analýzou a návrhem softwaru**.
|
|||
|
- analýza říká, co máme dělat
|
|||
|
- porozumění požadavkům a potřebám uživatelů
|
|||
|
- prostředí, kde bude software nasazen
|
|||
|
- návrh říká, jak to máme dělat
|
|||
|
- proveden na základě požadavků zjištěných analýzou
|
|||
|
- návrch architektury a způsobu implementace funkcionality
|
|||
|
- analýza a návrh probíhají do jisté míry současně
|
|||
|
|
|||
|
Vysvětlete **pojem rozhraní**, jak **rozhodnete** ve fázi návrhu o **vhodnosti existence rozhraní**.
|
|||
|
- odděluje specifikaci od implementace
|
|||
|
- lze jej připojit ke třídám či komponentám
|
|||
|
- definuje služby které jsou nabízeny
|
|||
|
- zavedení
|
|||
|
- v případě, kdy máme více tříd s podobným účelem či rolí
|
|||
|
- když chceme rozvolnit asociační vazby
|
|||
|
|
|||
|
Vysvětlete **pojmy diagram datových toků** (DFD) a **model kontextu systému** (nakreslete obrázek).
|
|||
|
- diagram datových toků
|
|||
|
- jednoduché a intuitivní
|
|||
|
- říká, jakým způsobem data protékají v systému, kdo je zpracovává a jak to zpracování jde za sebou
|
|||
|
- model kontextu systému
|
|||
|
- hranice systému
|
|||
|
- říká, jakým způsobem systém souvisí a komunikuje (přímo) s entitatmi okolo
|
|||
|
- používá se jako nástroj k pochopení prostředí
|
|||
|
|
|||
|
Zhodnoťte **význam návrhu architektury sw systému** pro **úspěšnost výsledného sw systému**, popište, jak budete principiálně **postupovat při návrhu architektury**.
|
|||
|
- dobře navržená architektura je podmínkou pro včasné odladění a udržitelnost produktu
|
|||
|
- postup:
|
|||
|
- rozdělení systému do podsystémů
|
|||
|
- rozdělení vrstev a oddílů
|
|||
|
- návrh topologie systému
|
|||
|
- rozložení funkcionalit
|
|||
|
- výběr architektonických vzorů
|
|||
|
- definice rozhraní
|
|||
|
|
|||
|
Vysvětlete **pojem softwarová architektura**.
|
|||
|
- týká se základní struktury, organizace a návrhu softwarového systému
|
|||
|
- vytváří plán, který určuje, jak jsou komponenty systému propojeny, jak spolu komunikují, jak jsou organizovány a jak jsou zajištěné požadované funkce a vlastnosti systému
|
|||
|
+ správný návrh architektury je klíčový pro dosažení kvalitního SW, který je spolehlivý, rozšiřitelný, snadno udržovatelný a efektivně plní požadavky uživatelů
|
|||
|
|
|||
|
Vysvětlete **pojmy preskripitivní** a **deskriptivní architektura**.
|
|||
|
- **preskriptivní**
|
|||
|
- zachycuje designová rozhodnutí učiněná před vývojem systému
|
|||
|
- jedná se o zamýšlenou architekturu
|
|||
|
- **deskriptivní**
|
|||
|
- popisuje, jak byl systém postaven
|
|||
|
- jedná se o implementovanou architekturu
|
|||
|
|
|||
|
Vysvělete **pojmy komponenta** a **konektor**.
|
|||
|
- **komponenta**
|
|||
|
- nezávislá a znovupoužitelná část SW, má jasně definovanou funkčnost a rozhraní
|
|||
|
- možnost samostatného vývoje a testování, poskytují služby specifické pro aplikaci
|
|||
|
- **konektor**
|
|||
|
- prvek, který umožňuje komunikaci a interakci mezi různými komponentami
|
|||
|
- propojuje komonenty a umožňuje tok dat, obvykle jednoduchá volání metod
|
|||
|
|
|||
|
Popište architektonické styly **dataflow** a **blackboard** (tabule).
|
|||
|
- dataflow
|
|||
|
- tok dat mezi různými komponentami systému
|
|||
|
- komponenty zpracovávají data ihned, jedná se o posloupnost transformací
|
|||
|
- blackboard
|
|||
|
- společné úložiště, které je přístupné všem komponentám systému
|
|||
|
- centrální místo, kde komponenty přispívají svými znalostmi a zpracovávají uložené informace
|
|||
|
- každá komponenta může číst a zapisovat
|
|||
|
|
|||
|
Popište a vysvětlete **princip třívrstvé architektury**.
|
|||
|
- rozděluje aplikaci do 3 vrstev, kde každá vrstva má oddělený účel
|
|||
|
- **prezentační vrstva**
|
|||
|
- viditelná pro uživatele (např. uživatelské rozhraní - webové, mobilní, desktopové)
|
|||
|
- zajišťuje vstup požadavků a prezentaci výsledků
|
|||
|
- je závislá na platformě
|
|||
|
- **logická vrstvá**
|
|||
|
- logika a funkčnost aplikace, zajišťuje výpočty a operace nad daty
|
|||
|
- přijímá data z prezentační vrstvy, zpracovává je a předává je do datové vrstvy
|
|||
|
- **datová vrstva**
|
|||
|
- zajišťuje přístup k datům a jejich uložení, správnost, konzistenci, bezpečnost
|
|||
|
- komunikuje s databázemi, soubory nebo jinými datovými zdroji
|
|||
|
|
|||
|
Popište a vysvětlete princip **architektury MVC**. Nakreslete příkladový obrázek.
|
|||
|
- cílem je oddělit různé části aplikace a zlepšit modularitu, údržbu a rozšiřitelnost
|
|||
|
- skládá se ze tří hlavních komponent:
|
|||
|
- **model** - datová vrstva aplikace, obsahuje data a logiku, která s těmito daty pracuje
|
|||
|
- **view** - vizuální prezentace dat uživateli, zobrazuje přijatá data z modelu
|
|||
|
- **controller** - přijímá požadavky od uživatele a provádí potřebné akce
|
|||
|
|
|||
|
Vysvětlete pojmy **návrhový vzor**, **katalog návrhových vzorů**.
|
|||
|
- **návrhový vzor**
|
|||
|
- způsob řešení častých a opakujících se problémů při návrhu SW
|
|||
|
- poskytuje strukturu a pravidla pro návrh a implementaci systému
|
|||
|
- **katalog návrhových vzorů**
|
|||
|
- sbírka popsaných návrhových vzorů klasifikovaných podle účelu a chování
|
|||
|
- nejznámější katalog
|
|||
|
- Design Patterns: Elements of Reusable Object-Oriented Software
|
|||
|
|
|||
|
Popište **základní principy**, na kterých jsou založeny **návrhové vzory**.
|
|||
|
- dva pohledy:
|
|||
|
- klient-rozhraní: zaměřuje se na pohled klienta, implementace ho nezajímá
|
|||
|
- rozhraní-implementace: změnou implementace klient nebude nijak ovlivněn
|
|||
|
- polymorfismus - dědění společné funkcionality tříd od předků
|
|||
|
- abstraktní třída - společná funkcionalita a rozhraní pro konkrétní třídy
|
|||
|
- rozhraní - specifikují, jaké metody a operace třída musí implementovat
|
|||
|
|
|||
|
Vysvětlete **SOLID** (**Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, Inversion of Control/Dependency Injection**) principy v objektovém návrhu.
|
|||
|
- **SOLID** - pět základních principů objektově orientovaného návrhu.
|
|||
|
- **S** - **jediná zodpovědnost** = třída má pouze jednu specifikou úlohu nebo funkci
|
|||
|
- **O** - **otevřenost uzavřenost** = třídy jsou otevřené pro rozšíření a uzavřené pro modifikaci
|
|||
|
- **L** - **Liskov** = odvozené třídy jsou schopny plnit všechno to co jejich předci
|
|||
|
- **I** – **rozdělení rozhraní** = rozhraní je specifické pro jednotlivé uživatele
|
|||
|
- **D** – **invertování závislostí** = moduly závisí na abstrakcích, nikoli na konkrétních třídách
|
|||
|
|
|||
|
Vysvětlete principy **DRY** a **KISS** v souvislosti s návrhem software.
|
|||
|
- **DRY** - Don't Repeat Yourself
|
|||
|
- nemělo by docházet v duplikaci kódu nebo informací v systému
|
|||
|
- snižuje riziko chyb, jelikož změny se provádějí pouze na jednom místě
|
|||
|
- **KISS** - Keep It Simple, Stupid
|
|||
|
- návrh a implementace SW má být co nejjednodušší
|
|||
|
- podporuje jednoduchost a srozumitelnost kódu, což usnadňuje jeho čtení, údržbu a testování
|
|||
|
|
|||
|
Popište základní princip **návrhového vzoru Iterátor**. Nakreslete příkladový obrázek – **UML diagram struktury vzoru**.
|
|||
|
- **Iterátor**
|
|||
|
- slouží k procházení kolekcí, aniž bychom museli znát jejich interní strukturu
|
|||
|
- umožňuje měnit implementaci kolekce beze změn mimo kolekce
|
|||
|
|
|||
|
Popište **návrhový vzor Fasáda**. Nakreslete příkladový obrázek – **UML diagram struktury vzoru**.
|
|||
|
- **Fasáda**
|
|||
|
- strukturální vzor, který poskytuje jednotné rozhraní pro usnadnění a zjednodušení používání složitých systémů nebo podsystémů
|
|||
|
- slouží jako rozhraní mezi klientem a vnitřními komponentami systému, skrývá složitost a poskytuje zjednodušené rozhraní pro klienta
|
|||
|
|
|||
|
Popište základní princip **návrhového vzoru Stavitel** (Builder). Nakreslete příkladový obrázek – **UML diagram struktury vzoru**.
|
|||
|
- **Stavitel**
|
|||
|
- vzor je vytvořený s cílem oddělit proces tvorby komplexního objektu od jeho reprezentace
|
|||
|
- umožnuje postupné konstruování objektu krok za krokem
|
|||
|
|
|||
|
Popište základní princip **návrhového vzoru Tovární metoda**. Nakreslete příkladový obrázek – **UML diagram struktury vzoru**.
|
|||
|
- **Tovární metoda**
|
|||
|
- používá se pro zapouzdření složitější inicializace instance
|
|||
|
|
|||
|
Popište základní princip **návrhového vzoru Singleton**. Nakreslete příkladový obrázek – **UML diagram struktury vzoru**.
|
|||
|
- **Singleton**
|
|||
|
- třída má pouze jednu instanci, která je globálně získatelná
|
|||
|
- využívá se tovární metody
|
|||
|
|
|||
|
Popište základní princip **návrhového vzoru Skladba** (Composite). Nakreslete příkladový obrázek – **UML diagram struktury vzoru**.
|
|||
|
- **Skladba**
|
|||
|
- představuje řešení, jak uspořádat jednoduché objekty a z nich složené objekty tak, aby k oběma typům objektů bylo možné přistoupit jednotným způsobem
|
|||
|
- často využívá polymorfismus
|
|||
|
|
|||
|
Popište základní princip **návrhového vzoru Dekorátor** (Decorator). Nakreslete příkladový obrázek – **UML diagram struktury vzoru**.
|
|||
|
- **Dekorátor**
|
|||
|
- vytváří se za účelem změny instancí bez nutnosti vytvoření nových odvozených tříd, jelikož pouze dynamicky připojuje další funkčnosti k objektu
|
|||
|
- každá dodaná funkčnost je u dekorátoru implementována jako "ozdobení" jiného objektu
|
|||
|
- rozšiřuje objekt
|
|||
|
|
|||
|
Vysvětlete **princip oddělení zodpovědnosti** (separation of concern) v objektovém návrhu.
|
|||
|
- rozdělení systému na oddělené části, z nichž každá má jasně definovanou zodpovědnost
|
|||
|
- funkcionalitu tedy vykonává pouze ta část systému, která je k tomu určená
|
|||
|
- díky tomu snížíme závislost mezi jednotlivými částmi systému
|
|||
|
|
|||
|
Jaký je **smysl testování**? Do jaké míry je ekonomicky **rozumné testovat**?
|
|||
|
- smyslem je
|
|||
|
- zajištění kvality a spolehlivosti SW systémů
|
|||
|
- pomáhá nám odhalovat chyby, ověřit bezpečnost a správnost systému
|
|||
|
- testuje se protože
|
|||
|
- lidé dělají chyby
|
|||
|
- nalezení chyb dříve snižuje náklady
|
|||
|
- testujeme do té doby, dokud náklady na nalezení dalšího defektu nepřekročí náklady na ponechání daného defektu
|
|||
|
|
|||
|
Vysvětlete **pojmy black box a white-box testování**
|
|||
|
- **black box**
|
|||
|
- neznáme implementaci, známe vstupy a očekávané výstupy – pohled uživatele
|
|||
|
- též funkcionální testování
|
|||
|
- metoda simulující reálný způsob použití aplikace
|
|||
|
- výhoda: tester nemusí být programátor
|
|||
|
- **white box**
|
|||
|
- známe implementaci, zdrojový kód i strukturu - pohled programátora
|
|||
|
- též strukturální testování (souvisí s pokrytím kódu)
|
|||
|
- cílem je otestování vnitřní logiky systému a správnosti algoritmů
|
|||
|
|
|||
|
Vysvětlete **pojem akceptační testování**.
|
|||
|
- cílem je ověřit, zda systém splňuje předem stanovené požadavky a očekávání zákazníka nebo uživatele
|
|||
|
- zjišťuje, zda je systém připraven k nasazení do provozu a zda je schopný plnit požadované funkce v reálném prostředí
|
|||
|
- obsah testů by měl určit zadavatel
|
|||
|
|
|||
|
Vysvětlete a popište, jak probíhá **jednotkové testování**. Uveďte příklad.
|
|||
|
- testovaních jednoduchých komponent (tříd, metod)
|
|||
|
- první fáze testování, rychlé a méně nákladné
|
|||
|
- cílem je ověřit správnou funkčnost jednotlivých částí
|
|||
|
|
|||
|
Vysvětlete **pojmy A/B testování** a **zátěžové testování**.
|
|||
|
- **A/B testování**
|
|||
|
- metoda používaná k porovnávání dvou verzí produktu
|
|||
|
- uživatelé se náhodně rozdělí do dvou skupin a každé se zobrazují dvě různé varianty (A a B) a měří se, která verze vede k lepšímu výsledku
|
|||
|
- **zátěžové testy**
|
|||
|
- zjišťuje chování a výkon SW při vysokém počtu uživatelů nebo dotazů
|
|||
|
|
|||
|
Co jsou to **automatické testy**, jaký je jejich **význam**, jaké mají **výhody a nevýhody**?
|
|||
|
- **automatické testy**
|
|||
|
- navrženy tak aby se prováděly automaticky, bez zásahu testera
|
|||
|
- založeny na napsaných testovacích skriptech nebo scénářích
|
|||
|
- mohou být spouštěny opakovaně a systematicky, což usnadňuje kontrolu kvality a identifikaci chyb
|
|||
|
- **výhody**: rychlost, efektivita, úspora času a nákladů
|
|||
|
- **nevýhody**: náročná implementace, nelze otestovat vše, mohou generovat falešné výsledky
|
|||
|
|
|||
|
Co je to **code review**? Jak byste code review prováděli?
|
|||
|
- proces, ve kterém jiný člověk projde kód a vyhodnotí jeho kvalitu, správnost a dodržení určitých standardů
|
|||
|
- cílem je zlepšit kvalitu, čitelnost a udržitelnost kódu, odhalit a opravit chyby
|
|||
|
|
|||
|
Co popisuje **schéma tzv. agilních testovacích kvadrantů**?
|
|||
|
- pomáhá týmu testerů naplánovat, připravit a následně provádět testování
|
|||
|
1. **unit testy** - testování jednotlivých komponent
|
|||
|
2. **testy na úrovni služeb** - komunikace mezi komponentami
|
|||
|
3. **testy na uživatelské rozhraní** - fungování UI
|
|||
|
4. **testování výkonu, bezpečnosti a udržovatelnosti**
|
|||
|
|
|||
|
Vysvětlete **pojem dostupnost, lhůta plnění, základní doba služeb** v oblasti provozu informačního systému.
|
|||
|
- **dostupnost**
|
|||
|
- doba, kdy je garantována funkčnost IS (např. 95 %)
|
|||
|
- **lhůta plnění**
|
|||
|
- pro vykonávání stanovených činností (např. jak rychle musí být nahozen server po spadnutí)
|
|||
|
- **základní doba služeb**
|
|||
|
- doba, ve které jsou garance a lhůty plnění poskytovány (např. od 7:00 do 19:00)
|
|||
|
|
|||
|
Jak **zabezpečíte dodržování SLA** (service level agreement) v provozu informačních systémů?
|
|||
|
- pomocí smlouvy, které je podepsaná oběma stranami
|
|||
|
- definováním sankcí ve smlouvě
|
|||
|
- včasnou dohodou, pokud není možné dodržet parametry SLA
|
|||
|
|
|||
|
Vysvětlete **princip činnosti primární a sekundární podpory** v servisu informačních systémů.
|
|||
|
- **primární podpora**
|
|||
|
- jediné kontaktní místo pro pomoc uživatelům (hotline, helpdesk)
|
|||
|
- činnost zajišťují operátoři, sledování provozu, poskytnutí informací
|
|||
|
- poskytuje řešení známých problémů, používá známé postupy (odpověď obratem)
|
|||
|
- **sekundární podpora**
|
|||
|
- poskytuje řešení problémů, řešení nadstandardních provozních úloh
|
|||
|
- řešení změn a nových funkčností pouze v omezeném objemu
|
|||
|
- řeší případy, kde není řešení doposud známé, statistiky
|
|||
|
|
|||
|
Jaké je **základní pravidlo při řešení problémů** servisu informačních systémů?
|
|||
|
- nahlásit problém
|
|||
|
- umožnit uživateli pokračovat v práci jiným způsobem
|
|||
|
- najít náhradní funkční řešení
|
|||
|
- kategorie podle závažnosti a severity:
|
|||
|
- A (kritický problém)
|
|||
|
- problémy, které nelze odkládat a mají významný dopad na provoz systému
|
|||
|
- vyžadují okamžité řešení
|
|||
|
- B (vážný problém)
|
|||
|
- problémy mají významný dopad na provoz systému, ale je možné je obejít náhradním řešením
|
|||
|
- řešení v nejbližší době
|
|||
|
- C
|
|||
|
- problém, který nemá dopad na funkčnost, jejich řešení lze odložit
|
|||
|
|
|||
|
Jak vypadá **SLA (service level agreement)** v oblasti servisu IS?
|
|||
|
- definuje úroveň a kvalitu služeb jako parametry (pro porušení parametrů stanoveny sankce)
|
|||
|
- je smluvní dohodou mezi dodavatelem a odběratelem
|
|||
|
- stanovuje cenu rizika, základní doba služeb
|
|||
|
- lhůty plnění (pro zahájení řešení problému, snížení kategorie problému, odstranění problému)
|
|||
|
|
|||
|
Popište **princip dualismu autorského práva** – **právo majetkové** a **právo osobnostní**. Uveďte **dvě výjimky** (omezení) autorského práva.
|
|||
|
- **právo majetkové**
|
|||
|
- týká se ekonomických a materiálních práv spojených s autorským dílem
|
|||
|
- dává autorovi a držiteli autorských práv právo na kontrolu a využívání svého díla za účelem získání hospodářského prospěchu
|
|||
|
- je často převoditelné a může být předmětem obchodování
|
|||
|
- **právo osobnostní**
|
|||
|
- práva jsou nepřevoditelná a autor se nemůže těchto práv vzdát
|
|||
|
- práva jsou pevně spojena s osobnosơ autora a jsou chráněna i po jeho smrti
|
|||
|
- **výjimky**
|
|||
|
- k dílu vytvořeného z pracovněprávního vztahu má majetková práva zaměstnavatel
|
|||
|
- **školní dílo** = škola má nevýhradní licenci k užití (nesmí ho užít komerčně)
|
|||
|
|
|||
|
Jak můžete vy/firma dále **používat software vytvořený jako zaměstnanecké dílo**?
|
|||
|
- firma získává autorská práva k SW vytvořenému zaměstnancem
|
|||
|
- může jej upravovat, používat, prodávat a licencovat
|
|||
|
- zaměstnanec software nesmí SW dále používat pro své účely ani jej licencovat
|
|||
|
- může být uvedený jako autor a dílo může odvolat
|
|||
|
|
|||
|
Popište **základní typy licencování softwaru** a **základní obsah licenční smlouvy**.
|
|||
|
- **výhradní typ**
|
|||
|
- poskytovatel uděluje licenci uživateli právo užívat SW výhradně, to znamená že nemůže udělit žádné jiné třeơ straně ani jej sám využívat
|
|||
|
- **nevýhradní typ**
|
|||
|
- umožnuje poskytovateli SW nadále disponovat SW a udělat licence dalším
|
|||
|
- **obsah licenční smlouvy**
|
|||
|
- identifikace stran, specifikace SW, rozsah a způsob užití SW, doba trvání licence, odměna za licenci
|
|||
|
|
|||
|
Popište, jaká práva máte **vy a univerzita k softwaru**, který vytvoříte jako **školní dílo**.
|
|||
|
- **student** má právo na to být uznán jako tvůrce a má právo chránit dílo proti neoprávněným úpravám
|
|||
|
- **univerzita** má nevýhradní licenci pro nekomerční užití
|
|||
|
|
|||
|
Uveďte alespoň **dvě nařízení či směrnice z evropského digitálního balíčku** se stručným vysvětlením jejich významu.
|
|||
|
- **DMA** (Digital Markets Act)
|
|||
|
- cílí na velké online platformy, které mají velký vliv na trh
|
|||
|
- zavádí pravidla zabraňující zneužívání tržní síly daných platforem
|
|||
|
- usnadňuje vstup nových hráčů na trh a podporuje konkurenční prostředí
|
|||
|
- **GDPR** (General Data Protection Regulation)
|
|||
|
- stanovuje pravidla pro shromažďování, zpracování a uchovávání osobních údajů
|
|||
|
- umožňuje uživatelům právo být zapomenut (výmaz) nebo na opravu údajů
|