|
|
|
|
@ -1,3 +1,56 @@
|
|
|
|
|
<!---
|
|
|
|
|
Notes:
|
|
|
|
|
|
|
|
|
|
* Dvoustrankovy uvod - co by to melo umet
|
|
|
|
|
* Analýza - co se rozhodneme delat, jak by se to dalo delat, pridelit dulezitost
|
|
|
|
|
- pak se da odkazat na to, proc jsme co nestihli, zahrnout i advanced featury
|
|
|
|
|
- odkazovat se u featur, ze to je v planu v pristich verzi - co je dulezite
|
|
|
|
|
a co ne!! Zduvodnit tim, jakou podmnozinu featur nechat, snaze se pak bude
|
|
|
|
|
popisovat architektura
|
|
|
|
|
* V analyze vysvetlit architekturu
|
|
|
|
|
* Related works nechat jako samostatnou kapitolu
|
|
|
|
|
* Poradi - pozadavky -> related works -> analyza
|
|
|
|
|
* Provazani komponent musi rozumet administrator a tvurce ulohy - obecna
|
|
|
|
|
kapitola v analyze - puvodni kapitola o analyze byla povedena, jen se tam
|
|
|
|
|
micha seznam zprav nebo co - to nezajima vsechny
|
|
|
|
|
* Po obecnym uvodu - rozdelit podle potencialniho ctenare - uzivatel ucitel, pak
|
|
|
|
|
uzivatel admin
|
|
|
|
|
* Instalacni dokumentace stranou, jako posledni
|
|
|
|
|
* Uzivatelaka dokumentace - admin: popis prav, autor uloh: nejobsahlejsi, format
|
|
|
|
|
skriptu - ale formulovat tak, ze bude popis na co kde kliknout, jazyk popsat
|
|
|
|
|
separatne - v budoucnu to bude irelevantni, je potreba daleko hloubeji - je
|
|
|
|
|
treba popsat detailne co eelaji, i treba relativni/absolutni adresy, makra,
|
|
|
|
|
kde vidi prekladac knihovny a headery... - kapitola na konci
|
|
|
|
|
* Uzivatelska dokumentace pro studenta: vysvetleni
|
|
|
|
|
* Jak se boduje uloha - tezko rict, kam to patri - nekde na zacatku? Ale zajima
|
|
|
|
|
to vsechny role, ucitel musi vedet, jak to nakonfigurovat - zminit treba i jak
|
|
|
|
|
bodovat podle casu a pameti (v analyze nebo v uvodu) - vice vystupu od judge,
|
|
|
|
|
interpolace bodu podle vyuziti pameti... je to spis mimo uživatelskou
|
|
|
|
|
* Nepsat kde na jake tlacitko kliknout
|
|
|
|
|
* Tutorialy - scenare, co udelat kdyz chci neco, vzorove pruchody
|
|
|
|
|
* U formularu je nejlepsi kdyz zadna dokumentace neni, doplnit popisky k polim
|
|
|
|
|
formularu
|
|
|
|
|
* V dokumentaci popsat konfigy nekde separatne - skore, yaml - referencni
|
|
|
|
|
dokumentace
|
|
|
|
|
* Urcite ne FAQ, vic strukturovane
|
|
|
|
|
* Instalaci dohromady na konec
|
|
|
|
|
* Programatorska dokumentace - "nejmene ctenaru" - neco uz tam mame, neni to
|
|
|
|
|
treba davat do tistene dokumentace - do tistene dokumentace dat odkaz na wiki,
|
|
|
|
|
neco v tistene ale byt musi - jaky jazyk, designové rozhodnutí - zdůvodnění
|
|
|
|
|
nedávat do úvodní analýzy - k referencnim dokumentacim udelat uvod - "restove
|
|
|
|
|
API jsme pojali timto zpusobem, deli se to na tyto skupiny, ..."
|
|
|
|
|
* Co zvolena architektura znamena, neco to ma dat i uzivateli, ktery
|
|
|
|
|
architekturu nezna, kde je drzenej stav
|
|
|
|
|
* Z dokumentace musi byt patrne, co dela knihovna a co se musi udelat rucne -
|
|
|
|
|
kolik je to prace - psat to vic pro uzivatele, ktery zna technologie, nezna
|
|
|
|
|
knihovny
|
|
|
|
|
* Mit soucit s tema, ktery to toho tolik neznaji - jak technologie, tak
|
|
|
|
|
architekturu a system CodExu
|
|
|
|
|
* Nesedi cisla stranek
|
|
|
|
|
* Stazeni ZIPu s vystupy Backendu - roztridit na verejne a tajne, verejne i pro
|
|
|
|
|
studenta
|
|
|
|
|
-->
|
|
|
|
|
|
|
|
|
|
Introduction
|
|
|
|
|
============
|
|
|
|
|
|
|
|
|
|
|
Petr Stefan
8 years ago