- Stahuj zápisky z přednášek a ostatní studijní materiály
- Zapisuj si jen kvalitní vyučující (obsáhlá databáze referencí)
- Nastav si své předměty a buď stále v obraze
- Zapoj se svojí aktivitou do soutěže o ceny
- Založ si svůj profil, aby tě tví spolužáci mohli najít
- Najdi své přátele podle místa kde bydlíš nebo školy kterou studuješ
- Diskutuj ve skupinách o tématech, které tě zajímají
Studijní materiály
Hromadně přidat materiály
Otázky statnice_mgr_nav_apl_vseobecna_12_otazek
SZMAP - Státní zkouška (magisterský studijní program Aplikovaná informatika)
Hodnocení materiálu:
Zjednodušená ukázka:
Stáhnout celý tento materiál1. Základní schéma životního cyklu software. Pracnost jednotlivých etap.
Techniky specifikace požadavků. Varianty životního cyklu. SW prototypy.
Strukturovaný vývoj. SW metriky a jejich využití. Techniky odhadu
pracnosti a doby řešení. Funkční body. COCOMO. Kvalita SW,
techniky zajitění kvality, ISO 9000.
Základní schéma životního cyklu software
Software je souhrn počítačových programů,dat a dokumentace, který náleží k provozu počítačového systému.
Počátek jeho životního cyklu začíná nápadem na to začít vymýšlet nějaký software a končí v okamžiku kdy jej poslední člověk přestane používat.
Mezitím lze jeho životní cyklus popsat zhruba takto:
Specifikace problému: zadání problému, který bude software řešit, návrh jak bude software komunikovat atd. Specifikace by se měla také otestovat.
Analýza: vytvoří se logický návrh systému, zpravidla se zaznamená pomocí nějakých grafických technik
Návrh: rozklad na podproblémy, určí se kdo a co má udělat.
Implementace: návrh algoritmů, programování
Testování: validace produktu proti specifikaci
Provoz a údržba produktu: údržba verzí, opravy chyb
Pracnost jednotlivých etap
Obecně nejpracnější činností je vytváření dokumentace a odstraňování defektů v programech.
U velkých systémů zabere 90% času odstraňování problémů.
Obecně platí, že ve zmíněném životním cyklu je velmi obtížné vracet se ob více než jeden krok zpět. Tj. opravovat chybu ve specifikaci až když je projekt předaný je velmi obtížné.
Techniky specifikace požadavků
Ideální specifikace požadavků by měla být naprosto pevná, přesná, úplná a bezesporná.
Specifikace vzniká v několika krocích, kde na začátku vznikne neformální specifikace požadavků – odborný článek, která obsahuje prvotní nápad co by systém měl dělat. Na základě ní vytvoří dodavatel funkční specifikaci, která je už mnohem přesnější a zpravidla využívá některých metod formální specifikace. Týká se hlavně toho jak bude systém pracovat navenek, ne jak bude vypadat uvnitř. Bývá také součástí kontraktu mezi dodavatelem software a zákazníkem. Pro fungování vnitřní části systému lze pak případně vytvořit tzv. návrh implementace.
Součástí specifikace požadavků mohou být i požadavky nesouvisející přímo s funkcí software tzv. nefunkční požadavky. Mohou to být např. požadavky na rychlost software, předepsaná metodika vývoje, legislativa, množství peněz na vývoj atd.
Varianty životního cyklu
Model vodopád
Je jedním z klasických způsobů vývoje software, skládající se z jednotlivých etap, které
na sebe navazují. Dobře se řídí, ovšem obtížně se vyrovnáva s chybami vnesenými do procesu na začátku. Skládá se z navazujících činností:
Specifikace požadavků
Analýza a návrh software
Implementace
Testování
Provoz a údržba
Jedním ze zásadních problémů tohoto přístupu je, že zákazník vidí svůj software až na konci procesu, což je problém v okamžiku, kdy na začátku procesu vlastně ani neví co chce.
Tento model se hodí pro oblasti, které řešitelský tým dobře ovládá.
Model výzkumník
Tento model je vhodný řekněme pro programování věcí, které řešitelé neznají. Skládá z operací:
Vytvoř systém → Implementuj systém → Používej systém.
→ Pokud vyhovuje předej systém. Pokud ne, vrať se na začátek.
Tento systém práce se obtížně řídí a plánuje, má problémy s dokumentací a zpravidla do vývoje vidí jen jeden výzkumník nebo výzkumný tým a jejich rozpad či odchod pracovníka znamená ukončení projektu.
Prototypování
Tato metoda se snaží překonat problémy spočívající v nepřesně formulované případně měnící se požadavky na systém. Spočívá ve vytváření tzv. protopypů, což jsou částečné implementace výsledného produktu se všemi rozhraními, které pak potenciální uživatelé testují. Prototypy se pak případně vylepšují, použijí nebo zahodí.
Prototypování se obvykle použitvá jen u menších systémů a zpravidla je nutné stanovit hranici pro vytváření protoypů, aby se nevytvářely donekonečna.
Spirálový model
Vytvořený hlavně za účelem minimalizace rizik při postupu pomocí vodopádu. Jednotlivé kroky se ve spirále opakují se stále vyšším a vyšším stupněm zvládnutí problematiky. Spirála většinou začíná analýzou rizik, dále se rozvíjí prototyp a zakončuje se kontrolou výsledků a testováním.
SW prototypy
viz. Prototypování
Strukturovaný vývoj
Strukturovaný vývoj je založený na strukturované analýze, což je druhá část vývoje projektu. První část vývoje je soubor uživatelských požadavků na systém. Původně s ní přišel pan DeMarco. Základním cílem bylo:
Rozdělení problémů na menší, dobře definovatelné aktivity a určují posloupnosti a interakce těchto aktivit.
Používajjí diagramy a další techniky k vytvoření specifikace, které rozumí uživatelé i návrháři systému.
Strukturovaná analýzva používá
DFD
Datový slovník
Strukturovanou angličtinu
Rozhodovací tabulky procesů
Rozhodovací stromy
DFD – dataflow diagram se myslí procesy, datové paměti, data vstupující do procesů, transformovaná data vystupující z procesů a terminátoři. DFD mohou být na úrovni procesů dekomponované na vlastní DFD.
Později přišli jiní pánové s vylepšením této metody s názvem Logické modelování. Vývoj při něm probíhá takto:
(DFD, Pameti, ERD, Vazby, Prekresleni, Jednotky, Popis)
Vytvoří se systémový DFD, který zahrne procesy, datové toky, paměti a vnější entity. Vymezí hranice systému, vnější entity a datové toky na hranici systému. Ukáže uložená data a transformující procesy. Měl by být srozumitelný i zákazníkovi.
Načrtnutí datového modelu. Vytvoří se seznamy všech datových paměti, které ponesou jména objektů, které se uchovávají. Sledují se data, která do systému vstupují zvenčí až doputují do datových pamětí.
Analýza entita a vztahů. Vyhledáváme objekty – entity a hledáme mezi nimi vztahy. Vytváříme ERD.
Vytvoříme ERD v normalizovaném tvaru. Normalizovaných tvarů je větší množství. Neměly by tam být vazby M:N, dále by každá tabulka měla mít jeden klíč a všechny položky by měly záviset na klíči.
Překreslení DFD tak, aby reflektoval změny provedené v ERD.
Z procesů a dat vytvoř procedurální jednotky, které lze samostatně provozovat a naprogramovat – tj. rozdělit práci programátorům.
Specifikuj detaily každé jednotky např. DFD jednotky, popis ve strukturované angličtině, příklad výstupů atd.
SW metriky a jejich využití
(Produkt, Proces, Zdroj)
SW metriky jsou meření některých z vlastností jaký má software. Klasifikují se podle:
Metriky produktu – explicitní výsledky vývoje SW, kód, dokumentace ...
Metriky procesu – činnost spojené s vývojem SW
Metriky zdrojů – hardware, čas, lidé.
Příkladem může být tzv. Halsteadtova metrika, která je založena na teorii informací.
Funkční body
Je to metodika pro měření velikosti informačního systému. Počítají se funkce (činnosti) software a na základě jejich váženého součtu se provede odhad. Počítá se například:
(Vstupy, výstupy, dotazy, soubory)
Počet vnějších vstupů a výstupů.
Počet vnějších dotazů.
Počet interních souborů
Počet externích souborů.
Výsledek se zanese do formuláře FP, který se pak znásobí koeficientem složitosti. Výsledkem je odhad práce, času a velikosti.
(Práce, čas, velikost)
Cocomo
(Typ projektu, počet řádků kódu)
Constructive cost model – založen na souboru významných veličin, které ovlivňujíc cenu a dobu řešení projektu. Výstupem je počet člověkoměsíců. Existuje základní a rozšířené COCOMO. Základní COCOMO používá rozdělení projektů na tři typy jednoduché, středně složité a složité. Pak používá metriku počet řádků kódu a na základě určení typu projektu z této metriky pomocí různých vzorečků odvozuje potřebný počet programátorů a dobu vývoje v měsících.
Kvalita SW, techniky zajitění kvality, ISO 9000
Kvalita SW
Kvalita je dodržení explicitně stanovených funkčních a výkonových požadavků, dodržení standardů a charakteristik, které očekáváme od vyrobeného software.
Kvalitu lze měřit:
Přímo – např. počet chyb ve vztahu k počtu řádků kódu.
Nepřímo – použitelnost, udržovatelnost software.
Největším zdrojem defektů bývají samotné požadavky na systém.
Nejdráž se defekty odstraňují poté co je systém nasazen do provozu.
Techniky zajištění kvality
Jedná se o soubor technik patřící do společného řekněme oboru SQA – software quality assurance.
Obecně lze mluvit o testování, validaci a verifikaci produktu. Validací se rozumí otázka, zda jsme vytvořili správný produkt tj. jestli produkt odpovídá potřebám uživatele. Verifikací se rozumí, zda jsme produkt vytvořili správně tj. zda produkt odpovídá specifikaci.
Testováním se pak pokoušíme zmíněné předchozí dokázat pro omezenou sadu příkladů.
Obecně se pak za úspěšný považuje takový test, který odhalí nějakou chybu.
Testovat lze různými způsoby např.
Testování podle vstupních dat – vstupní data se rozdělí do vhodných tříd a produkt se otestuje.
Testování podle struktury programu – zde se snažíme o to, aby program prošel všemi možnými větvemi.
Jinou možností jsou inspekce produktu, která spočívá v dialogu mezi inspektory a autory, kde se kladou otázky nad produktem a specifikací s cílem nálezt případné chyby. Základem je nový pohled na projekt.
Pro určité omezené oblasti lze použít i matematické důkazy správnosti programů.
ISO 9000
Obecně standardy rodiny ISO 900x se zaobírají systémem kvality při návrhu, vývoji, výrobě a servisu. Konkrétně ISO 9000 je doporučení jak aplikovat ISO 9001 při vývoji software. Samotný standard se postupně vyvíjel.
V první verzi z roku 1987 se orientoval zejména na dodržování pracovních postupů.
V druhé verzi z roku 1994 pak zejména na zajištění kvality a opět na držení se řádně dokumentovaných pracovních postupů.
Ve třetí verzi z roku 2000 se standard zaměřil zejména na process managment a jeho efektivnost.
10. Rekurzivní a rekurzivně spočetné jazyky. Turingovy stroje. Pojem nerozhodnutelnosti
Rekurzivní a rekurzivně spočetné jazyky
Jazyk L z množiny Σ* se nazývá:
rekuzivně spočetný (RE) – právě tehdy, když L = L(M) pro nějaký Turingův stroj M.
rekurzivní (REC) – právě tehdy když L = L(M) pro nějaký úplný Turingův stroj M.
Ke každému rekurzivnímu jazyku L existuje Turingův stroj, který jej rozhoduje tj. výpočet je na každém vstupním slovu konečný.
Rekursivně spočetný jazyk splňuje pouze slabší podmínku, musí pro něj existovat TS, který slova z jazyka akceptuje, ale na slova, která z jazyka nejsou buď zamítá nebo cyklí (nekonečný výpočet).
Vlastnosti rekurzivních a rekurzivně spočetných jazyků
Třídy rekurzivních a rekurzivně spočetných jazyků jsou uzavřený na operace sjednocení, průnik, zřetězení a iteraci.
Třída rekurznivních jazyků je uzavřena proti doplňku.
Postova věta: Pokud jsou jazyk L a jeho komplement CO – L rekurzivně spočetné, pak jsou rekuzivní.
Pojem nerozhodnutelnosti
Problém určení, zda daný řetězec má vlastnost P je:
rozhodnutelný – právě, když množina řetězců majících vlastnost P je rekurzivní, tj. existuje TS M, který každý řetězec s vlastností P, akceptuje a každý řetězec, který vlastnost P nemá, zamítá.
nerozhodnutelný – právě když není rozhodnutelný
částečně rozhodnutelný – právě když množina všech řetězů majících vlastnost P, je rekursivně spočetná, tj. existuje TS M, který akceptuje každý řetězec mající vlastnost P, ale zamítá nebo cyklí na řetězci tuto vlastnost nemajícím.
Mezi vlastnostmi rekurzivnost jazyka, rekurzivní spočetnost jazyka a rozhodnutelnostmi problémů je zřejmá ekvivalence.
Turingovy stroje
Turingův stroj byl vytvořen za účelem rozlišení co je a není vyčíslitelné tj. co lze nebo nelze efektivně spočítat.
Turingův stroj má:
konečnou množinu stavů Q
pásku, rozdělenou na jednotlivá políčka, hlavu, která se může po pásce pohybovat a číst a zapisovat symboly
pracovní (páskové) symboly jež se zapisují na pásku
počáteční symbol pásky (
speciální symboly pro prázdná políčka pásky
Výpočet začíná s hlavou na počátečním symbolu ve stavu q0. Stroj v závislosti na aktuálně snímaném symbolu a stavu může změnit svůj stav, zapsat na pásku symbol a posunout se doprava či doleva. Tato funkce je předepsána tzv. přechodovou funkcí. Stroj akceptuje pokud se ocitne ve stavu qaccept nebo zamítá pokud se ocitne ve stavu qreject. Na některých vstupech může stroj pracovat někonečně dlouho, říkáme, že cyklí.
Formálně je TS devítice, kde:
Q – konečná množina stavů
Σ – konečná množina vstupních symbolů
Γ – konečná množina páskových symbolů
( - levá koncová značka
symbol pro prázdné políčko
přechodová funkce (Q x Γ) → Q x Γ x {Left, Right}
počáteční stav
akceptující stav
zamítající stav
Levá koncová značka není nikdy přepsána a TS se nikdy nepřesune vlevo od levé koncové značky.
11. Postův korespondenční problém. Redukce. Algoritmicky nerozhodnutelné problémy z teorie jazyků.
Algoritmicky nerozhodnutelné problémy
Nerozhodnutelnost nějakého problému znamená, že neexistuje algoritmus schopný tento problém řešit.
Definicí pojmu algoritmus se zabývá tzv. Churchova teze, která říká:
Každý proces, který lze intuitivně nazvat algoritmem lze simulovat na Turingově stroji.
I když jde jenom o tezi, podporují její platnost následující argumenty:
Všechny ostatní matematické formalismy jsou ekvivalentní co do výpočetní síly TS.
Všechna možná rozšíření TS nemají vliv na výpočetní sílu.
Není algoritmus, který by nešlo simulovat na TS.
Pro důkaz, že nějaký problém není algoritmicky řešitelný lze použít dvě matematické metody metody diagonalizace a redukce.
Tyto postupy využívají schopnost TS simulovat práci jiného TS a to tak, ze TS a nějaké jeho vstupní slovo je zakódováno do formy vstupu a následně je jeho práce simulována.
Příklady algoritmicky nerozhodnutelných problémů:
Pro daný program a specifikaci co má provádět verifikovat, co program provádí. Tento úkol bychom chtěli automatizovat. Tento typ problémů není obecně rozhodnutelný tj. řešitelný počítačem.
Tento problém lze přeformulovat tak, že máme daný nějaký TS M, a slovo w zjistit zda M slovo akceptuje nebo nekceptuje (nebo cyklí).
Tento problém se také nazýva problémem příslušnosti. Pro daný TS M a slovo w chceme určit, zda slovo w buď přísluší nebo nepřísluší do jazyka L(M).
PP = { # | stroj M akceptuje w }
Tento problém je částečně rozhodnutelný, ale není rozhodnutelný.
Důkaz částečné nerozhodnutelnosti se podá snadno sestrojením univerzálního TS, který na vstup dostane řetězec #. K důkazu nerozhodnutelnost, lze použít například Cantorovu diagonalizační metodu.
Redukce
Příklad redukce
Problém zastavení. Pro libovolný daný TS M a libovolné slovo w určit zda výpočet M na w je konečný či nikoliv. Tento problém je jen částečně rozhodnutelný.
PZ = { # | výpočet M na w je konečný }
Důkaz nerozhodnutelnosti je podán tzv. redukcí.
Předpokládejme, že problém je rozhodnutelný, pak existuje úplný TS M akceptující PZ. Redukce spočívá ukázání, že s takovým strojem lze sestrojit i úplný TS N akceptující jazyk PP (Problém příslušnosti).
Důkaz se provede sporem. Předpokládejme, že existuje úplný TS T, akceptující PZ. Pokud by takový stroj existoval, bylo by možné s jeho pomocí sestrojit úplný TS N akceptující jazyk PP. Jelikož PP není rekuzivní, dojdeme ke sporu.
Stroj N by pracoval takto:
Simuloval by výpočet stroje T na vstupu #.
Pokud by stroj akceptoval, pak by byl výpočet konečný (varianta cyklení je vypuštěna) a stroj ma pak může rovnou simulovat výpočet stroje M na w. Akceptuje jen pokud N akceptuje.
Pokud by stroj nekceptoval #, pak víme, že i výpočet M na w cyklil, a stačí zamítnout.
Stroj N je úplný, protože jsou simulovány jen konečné výpočty, cyklení je úplně odstraněno.
Definice redukce
Nechť A a B jsou jazyky s nějakými i různými i prázdnými abecedami. Redukce jazyka A na jazyk B je rekursivní funkce z jedné abecedy do druhé, která všem slovům z první abecedy přiřazuje slova z abecedy druhé a naopak.
Vlastnosti redukce:
Existence úplného Turingova stroje, který pro každé slovo z první abecedy vypočte jeho obraz v druhé abecedě.
Redukce zachovává příslušnost do jazyka. Slovo z prního jazyka se zobrazí jako slovo z druhého jazyka. Slovo mimo první jazyk se zobrazí jako slovo mimo druhý jazyk.
Není-li první jazyk rekurzivně spočetný, pak ani druhý jazyk není rekurzivně spočetný.
Není-li první jazyk rekurzivní, pak ani druhý jazyk není rekurzivní.
Rozhodnutelné problémy
Pro daný TS M rozhodnout zda má:
Pro dané slovo w rozhodnout, že výpočet stroje M nad vstupním slovem w, je delší než nějaké X.
Semirozhodnutelné problémy
Pro daný TS M rozhodnout zda má:
jazyk L(M) je neprázdný
jazyk L(M) obsahuje alespoň nějakých X slov.
Nerozhodnutelné problémy
Pro daný TS M rozhodnout zda má:
jazyk L(M) je prázdný
jazyk L(M) obsahuje nanejvýš nějakých X slov
jazyk L(M) je konečný
jazyk L(M) = R pro nějaký regulární jazyk R
jazyk L(M) je regulární
jazyk L(M) je rekurzivní
Postův korespondenční problém
Je to nerozhodnutelný problém, který vymyslel pan Emil Post v roce 1946.
Definice
Jsou dány dva konečné seznamy slov u1,...,un a v1,...,vn nad stejnou abecedou, přičemž seznamy mají alespoň dva symboly. Řešením problému je sekvence indexů i1,...,ik, kde 1≤ij≤n, taková, že u1,...,un = v1,...,vn.
Příklad problému
Je dána tabulka:
u1
u2
aa
b
,
v1
v2
ab
a
Řešením problému je sekvence 1, 2 neboť:
u1u2 = aa + b = ab+ a = v1v2
12. Jednoprocesorové počítače, počítače s menším počtem procesorů, masivně
paralelní počítače; distribuované systémy. Sdílená, distribuovaná a distribuovaná
sdílená paměť; další alternativy. Masivně paralelní systémy, paralelní algoritmy, „jemný paralelismus. Distribuované systémy, dekompozice úloh, „hrubý paralelismus.
Jednoprocesorové počítače
Když se začaly vyvíjet počítače, bývaly doby, kdy paměť byla malá a drahá a přistupy do paměti obzvlášť pomalé. Programy musely být pokud možnost malé a byla snaha udělat většinu práce pomocí procesoru a jeho instrukcí. Instrukce byly složité mohly provádět několik operací zaráz, například vzít číslo z paměti, přičíst k registru a uložit do paměti – to vše v jedné instrukci. Velikost programu byla ale malá a na procesor se dal přímo napasovat programovací jazyk.
Také nebyly dostatečně vyvinuté kompilátory.
Jak postupně instrukce rostly a stávaly se složitějšími, bylo nutné je začít rozkládat na jednodušší instrukce a vnikl tzv. mikrokód, který představuje v podstatě emulaci složitých instrukcí na úrovni procesoru. Přeprogramováním mikrokódu v procesoru mohl vzniknout
procesor s jinými vlastnostmi. Takto fungoval např. IBM 360.
Tento přístup pak začal přinášet obtíže při požadavcích na vyšší výkon.
Proto se v polovině 60. let objevil opačný přístup tzv. RISC, který stavěl na malé sadě co nejjednodušších instrukcí, ale rychle prováděných. Zavedení RISC procesorů pomohl zejména:
Rozvoj optimalizujících překladačů – nebylo nutné programovat ve strojovém kódu či assembleru.
Zlevnění pamětí – tj. velikost programů začala být méně podstatná.
Vlastnosti RISC:
Instrukce jednotné délky – pro co nejrychlější zpracování
Malý počet instrukcí – jen ty skutečně potřebné.
Dostatek registrů
Jednotné kódování instrukcí
Load/Store architektura – dvě instrukce pro práci s pamětí, nic víc.
RISC samozřejmě nebyla jediná myšlenka na zvyšování výkonu procesorů. V 80. letech se začalo přemýšlet nad tím jak zvýšit výkon procesoru i jinak než jen zvýšením taktu. Jednou z myšlenek bylo rozbít instrukce na malé součásti, které by se zpracovávaly paralelně v pipeline.
Běžný rozklad mohl vypadat takto:
Fetch instrukce
Decode instrukce
Fetch operandů
Execute
Write Back
přičemž jednotlivé instrukce jsou zpracovány paralelně s posunem o jednu část. Tím se procesor využil daleko efektivněji.
Jedním z dalších napadů byla superskalární architektura, která spouští více instrukcí na redundantních výpočetních jednotkách v procesoru. S tímto nápadem poprvé přišel pan Cray v roce 1965. Drobným problémem této architektury jsou závislosti mezi instrukcem
Vloženo: 26.04.2009
Velikost: 244,76 kB
Komentáře
Tento materiál neobsahuje žádné komentáře.
Mohlo by tě zajímat:
Reference vyučujících předmětu SZMAP - Státní zkouška (magisterský studijní program Aplikovaná informatika)Podobné materiály
- IA008 - Computational Logic - Otazky_jaro2008
- PA103 - Objektové metody návrhu informačních systémů - Vypracované otázky zkouska
- PA105 - Technologie informačních systémů II - Otazky-zpracovane
- PA151 - Soudobé počítačové sítě - Vypracovane_otazky
- PA159 - Počítačové sítě a jejich aplikace I - Otazky_vypracovane
- PB001 - Úvod do informačních technologií - Vypracovane_otazky
- PB001 - Úvod do informačních technologií - Úvod_do_IT_vypracovane_otazky
- PB009 - Základy počítačové grafiky - Otazky_jaro_2006
- PB009 - Základy počítačové grafiky - Vypracovane_otazky
- PB029 - Elektronická příprava dokumentů - Zkusebni otazky
- PB114 - Datové modelování I - Teoretické otázky
- PB152 - Operační systémy - Otazky_komplet
- PB156 - Počítačové sítě - Otazky_site
- PB156 - Počítačové sítě - Vypracovane_otazky
- PV017 - Bezpečnost informačních technologií - Vypracované otázky
- PV019 - Geografické informační systémy I - Vypracovane_otazky
- PV062 - Organizace souborů - Otazky
- PV062 - Organizace souborů - Otazky_and_Odpovedi
- PV112 - Programování grafických aplikací - Otázky
- PV112 - Programování grafických aplikací - Vypracované otázky
- PV157 - Autentizace a řízení přístupu - Vypracovane-otazky.
- PV182 - Komunikace člověka s počítačem - Vypracovane-otazky_podzim2008
- PV183 - Technologie počítačových sítí - Otazky-vypracovane
- PV203 - IT Services Management - Otazky_2008
- SZBAP - Státní zkouška (bakalářský studijní program Aplikovaná informatika) - Statnice- otazky-jaro-2006
- SZMAP - Státní zkouška (magisterský studijní program Aplikovaná informatika) - Otazky_jaro2006
- SZMAP - Státní zkouška (magisterský studijní program Aplikovaná informatika) - Vypracovane_otazky_statnice_IS
- PB007 - Analýza a návrh systémů - Otazky_ke_zkousce_2002
- PV123 - Základy vizuální komunikace - Otazky
- PV123 - Základy vizuální komunikace - Otazky_2
- IA062 - Randomized Algorithms and Computations - Zkouškoové otazky_04_06_2008
- IA062 - Randomized Algorithms and Computations - Zkouškové otázky 13_06_2007
- IA062 - Randomized Algorithms and Computations - Zkouškové otázky 2007
- IA062 - Randomized Algorithms and Computations - Zkouškové otázky 24.5.2006
- IA062 - Randomized Algorithms and Computations - Zkouškové otázky 31.5.2006
- IA062 - Randomized Algorithms and Computations - Zkouškové otázky a 31.5.2006
- IA157 - Logická analýza přirozeného jazyka II - Testové otazky_2007
- IV054 - Kódování, kryptografie a kryptografické protokoly - Zkouska 10_1_2003_zk_4_otazky
- PB114 - Datové modelování I - Teoreticke_otazky_doplneni_12_6_2007
- PB154 - Základy databázových systémů - Zkouška otazky_z_pisomiek
- PB151 - Výpočetní systémy - Otazky
- PB151 - Výpočetní systémy - Otazky_a_odpovedi
- PV005 - Služby počítačových sítí - Vypracované otazky
- PA103 - Objektové metody návrhu informačních systémů - Vypracované otázky ze všech zkoušek
Copyright 2024 unium.cz