Povinná struktura/osnova projektu SNT

Povinná osnova dokumentace (technické zprávy)

• Úvod - zasvěcení do problému, citace nejdůležitějších zdrojů, motivace pro předkládanou práci
• Soupis relevantních faktů a zkoumané problematice, který MUSÍ být podložen citacemi na literaturu (již jednou recenzovaná/ověřená fakta)
• Abstraktní koncepce vaší práce - matematicky/algoritmicky popsaná myšlenka vaší práce
• Popis implementace práce - technický a konkrétní popis díla
• Experimentální fáze - cíl experimentů, průběh experimentů a vyhodnocení epxerimentů
• Závěr - konstatování dosažených výsledků

• Úvod
  • úvod musí vysvětlit, proč se celá práce dělá a proč má uživatel výsledků váš dokument číst. Případně, co se při čtení dozví. (Např. v této práci je řešena implementace ..., která bude použita pro sestavení modelu ... Na základě modelu a simulačních experimentů bude ukázáno chování systému ... v podmínkách ... Smyslem experimentů je demonstrovat, že pokud by ..., pak by ...). Poznámka: u vyžádaných zpráv se může uvést, že zpráva vznikla na základě požadavku ... (u školní práce takto zdůvod'novat projekt ovšem nelze, že).
  • je velmi praktické zdůvodnit, v čem je práce náročná a proto přínos autora nepopiratelný (např. pro zpracování modelu bylo nutno nastudovat ..., zpracovat, ... model je ve svém oboru zajímavý/ojedinělý v ...)
  • kdo se na práci podílel jako autor, odborný konzultant, dodavatel odborných faktů, ...
  • v jakém prostředí a za jakých podmínek probíhalo experimentální ověřování validity modelu

• Rozbor tématu a použitých metod/technologií (Relevantní fakta o problematice)
  • shrnutí všech podstatných faktů, které se týkají zkoumaného systému (co možná nejvěcnějším a technickým (ideálně formálně matematickým) přístupem, žádné literární příběhy). Podstatná fakta o systému musí být zdůvodněna a podepřena důvěryhodným zdrojem (vědecký článek, kniha, osobní měření a zjišťování). Pokud budete tvrdit, že ovce na pastvě sežere dvě kila trávy za den, musí existovat jiný (důvěryhodný) zdroj, který to potvrdí. Toto shrnutí určuje míru důvěryhodnosti vašeho modelu (nikdo nechce výsledky z nedůvěryhodného modelu).
  • popis použitých postupů pro vytvoření modelu a zdůvodnění, proč jsou pro zadaný problém vhodné. Zdůvodnění může být podpořeno ukázáním alternativního přístupu a srovnáním s tím vaším.
  • popis původu použitých metod/technologií (odkud byly získány (odkazy), zda-li jsou vytvořeny autorem)
  • Velmi důležité, povinné, kontrolované a hodnocené: na každém místě v textu, kde se poprvé objeví pojem z předmětu IMS a SNT bude v závorce uveden odkaz na předmět a číslo slajdu, na kterém je pojem definován. Pokud bude významný pojem z předmětů IMS, SNT takto nedokumentován v textu a zjevně bude používán nevhodným nebo nepřesným způsobem, bude tento fakt hodnocen bodovou ztrátou.
    • Tento požadavek je míněn s naprostou vážností. Cílem je vyhnout se studentské tvůrčí činnosti ve vysvětlování známých pojmů, což mnohdy vede k naprostým bludům, ztrátě bodů a zápočtů. Pokud student pojem cituje korektně a přesto nekorektně používá, bude to hodnoceno dvojnásobnou bodovou ztrátou.

• Koncepce modelu nebo simulátoru
  • Konceptuální model - předpokládáme, že model bude obsahovat fakta z "Rozboru tématu". Pokud jsou některá vyřazena nebo modifikována, je nuto to zde zdůvodnit.
  • Cílem konceptuálního (abstraktního) modelu je formalizovat relevantní fakta o modelovaném systému a jejich vazby. Podle koncept. modelu by měl být každý schopen sestavit simulační model.
  • Pokud píšete o implementace metody/simulátoru, pak zde musí být abstraktně rozebrána podstata a činnost metody/simulátoru.
  • Způsob vyjádření konc. modelu musí být zdůvodněno.
  • Formy konceptuálního modelu (důraz je kladen na srozumitelnost sdělení):
    • obrázek/náčrt/schéma/mapa (možno čitelně rukou)
    • matematické rovnice - u některých témat (např. se spojitými prvky, optimalizace, ...) naprosto nezbytné. Dobré je chápat, že veličiny (fyzikální, technické, ekonomické) mají jednotky, bez kterých údaj nedává smysl.
    • stavový diagram (konečný automat) nebo Petriho síť - spíše na abstraktní úrovni. Petriho síť nemá zobrazovat výpočty a přílišné detaily. Pokud se pohodlně nevejde na obrazovku, je nepoužitelná. Možno rozdělit na bloky se zajímavými detaily a prezentovat odděleně abstraktní celek a podrobně specifikované bloky (hierarchický přístup).

• Architektura simulačního modelu/simulátoru
  • Tato kapitola má různou důležitost pro různé typy zadání.
  • Minimálně je nutno ukázat mapování abstraktního (koncept.) modelu do simulačního (resp. simulátoru). Např. které třídy odpovídají kterým procesům/veličinám a podobně.
  • Zde můžete využít zajímavého prvku ve vašem simulačním modelu a tady ho "prodat".

• Podstata simulačních experimentů a jejich průběh
  • Zopakovat/shrnout co přesně chcete zjistit experimentováním a proč k tomu potřebujete model. Pokud experimentování nemá cíl, je celý projekt špatně.
  • Naznačit postup experimentování – jakým způsobem hodláte prostřednictvím experimentů dojít ke svému cíli (v některých situacích je přípustné "to zkoušet tak dlouho až to vyjde", ale i ty musí mít nějaký organizovaný postup).
  • Dokumentace jednotlivých experimentů - souhrn vstupních podmínek a podmínek běhu simulace, komentovaný výpis výsledků, závěr experimentu a plán pro další experiment (např. v experimentu 341. jsem nastavil vstup x na hodnotu X, která je typická pro ... a vstup y na Y, protože chci zjistit chování systému v prostředi ... Po zkončení běhu simulace byly získány tyto výsledky ..., kde je nejzajímavější hodnota sledovaných veličin a,b,c které se chovaly podle předpokladu a veličin d,e,f které ne. Lze z toho usoudit, že v modelu není správně implementováno chování v podmínkách ... a proto v následujících experimentech budu vycházet z modifikovaného modelu verze ... Nebo výsledky ukazují, že systém v těchto podmínkách vykazuje značnou citlivost na parametr x ... a proto bude dobré v dalších experimentech přesně prověřit chování systému na parametr x v intervalu hodnot ... až ...)
  • Závěry experimentů – bylo provedeno N experimentů v těchto situacích ... V průběhu experimentování byla odstraněna ... chyba v modelu. Z experimentů lze odvodit chování systémů s dostatečnou věrohodností a experimentální prověřování těchto ... situací již napřinese další výsledky, neboť ...

• Shrnutí simulačních experimentů a závěr
  • Závěrem dokumentace se rozumí zhodnocení simulační studie a zhodnocení experimentů (např. Z výsledků experimentů vyplývá, že ... při předpokladu, že ... Validita modelu byla ověřena ... V rámci projektu vznikl nástroj ..., který vychází z ... a byl implementován v ...).
  • do závěru se nehodí psát poznámky osobního charakteru (např. práce na projektu mě bavila/nebavila, ...). Technická zpráva není osobní příběh autora.
  • absolutně nikoho nezajímá, kolik úsilí jste projektu věnovali, důležitá je pouze kvalita zpracování simulátoru/modelu a obsažnost simulační studie (rozhodně ne např.: projekt jsem dělal ... hodin, což je víc než zadání předpokládalo. Program má ... řádků kódu). Pokud zdůrazňujete, že jste práci dělali významně déle než se čekalo, pak tím pouze demonstrujete vlastní neschopnost.
  • do závěru se velmi nehodí psát "auto-zhodnocení" kvality práce, to je výhradně na recenzentovi/hodnotiteli (např. v projektu jsem zcela splnil zadání a domnívám se, že můj model je bezchybný a výsledky taktéž). Statisticky častý je pravý opak autorova auto-zhodnocení.

Obecné poznámky

• v dokumentaci neocením "úvodní stránku s logem fakulty" a obsah. Obvzláště obsah jako jedna stránka u čtyř-pěti stránkového dokumentu působí směšně.
• grafy mají své náležitosti - identifikační název grafu (případně jeho číslo), cejchované osy s názvem veličiny na dané ose (včetně její jednotky). V případě grafu kombinujícího více jevů i legenda dokumentující grafické vyjádření jevů v grafu.
• veškeré tabulky a grafy musí být komentovány v textu - čtenáři musí řečeno, co v tom grafu uvidí a čeho si má všimnout.