Příloha č. 1. - Detailní specifikace zakázky pro část A) Vytvoření a dodávka modulů a frameworku pro IS 1. Obecná specifikace Předmětem části A) veřejné zakázky je vytvoření - naprogramování specifického softwaru frameworku včetně souvisejících modulů a procedur pro systém zadavatele, dle této technické specifikace. Cílem zadavatele je vytvořit komplexní informační systém pro školy a vzdělávací instituce, jehož cílem bude naplnit očekávání zákazníků po tomto druhu systému jako po maximálně komplexním řešení informačně vzdělávacího IS, který obsahuje funkční nástroje, počínaje agendou, přes školní administrativu, až po prodej a správu výukových celků a titulů poskytovaných od externích producentů (nejedná se o e-learning). Samotným systémem se rozumí informační systém určený pro oblast vzdělávání a školství budovaný zadavatelem. Uvedený systém slouží pro potřeby základních, středních a vyšších odborných škol a školících center. Frameworkem se pro tento projekt rozumí programové jádro systému, složené z procedur a funkcí, které bude sloužit jako základ pro další vývoj systému zadavatelem. Souvisejícími moduly se pro tento projekt rozumí obslužné rutiny a procedury, plnící specifické funkce, jež budou vývojáři systému dále využívány.
2. Základní architektura systému Systém je online aplikací, která běží na bázi klient - server a ke které koncoví uživatelé přistupují pomocí sítě internet, prostřednictvím internetového prohlížeče. Celý systém bude zpracován a dodán tak, aby byl integrovatelný do stávající technologické i softwarové architektury zadavatele a byl s nimi kompatibilní. Zadavatel má na serverové straně následující technologie: operační systém serverů Linux Gentoo, databázový systém PostgreSQL, frond-endový systém Apache, skriptovací programovací jazyk PHP. Zadavatel preferuje, aby technologie, které budou použity k tvorbě systému a veškerá serverová řešení, byla maximálně postavena na OpenSource systémech, tj. OpenSource programovacích nástrojích, operačních systémech apod. Nejedná se však o podmínku dodávky. Na straně klienta je možné využít technologie Ajax, Javascriptu, HTML5 a jiné moderní prvky internetových stránek, jež standardně podporují internetové prohlížeče. Zadavatel požaduje, aby případné výstupy pro uživatele neobsahovaly technologie a odkazy na technologie, vyžadující pro svůj chod instalaci dodatečných modulů do internetových
1 / 33
prohlížečů, nad rámec standardních instalací internetových prohlížečů (např. Silverlight, Java apod.). Jediným povoleným dodatečným modulem pro instalaci do prohlížeče na straně klienta je Adobe Flash Player, bude-li to návrh dodavatele vyžadovat. Celá aplikace bude vyvinuta jako online řešení s ovládáním výhradně ve webovém rozhraní, pracující garantovaně v internetových prohlížečích Mozilla Firefox, Internet Explorer, Opera a Google Chrome - vše testováno v nejnovějších verzích uvedených prohlížečů k datu předání díla a i ve verzích o jednu nižší, než je verze nejnovější, z uvedených prohlížečů. Zadavatel disponuje hardwarovými serverovými technologiemi, jež nejsou součástí dodávky. Hardwarové zrcadlení disků, replikace dat apod. jsou zajištěny na straně zadavatele. Softwarové replikace dat a databází v rámci systému, budou-li s ohledem na technické podmínky nutné, jsou předmětem zakázky. Za předpokladu, že nástroje použité pro tvorbu systému budou komerční, externě nakupované formou subdodávek, bude cena za licence a pořízení těchto nástrojů či serverové licence a všechny související náklady na pořízení veškerého souvisejícího softwaru, součástí nabídkové ceny a to tak, aby po dobu nejméně tří let nemusel zadavatel vynaložit nad rámec této zakázky další prostředky na nákup softwaru od třetích stran. Zadavatel bezpodmínečně požaduje, aby celý systém s výjimkou subdodavatelských či komerčních modulů a procedur byl dodavatelem dodán formou zdrojových kódů a po předání běžel na serverech zadavatele. Není přípustná možnost, kdy jakákoliv část systému bude volat procedury nebo se jinak odkazovat na zdroje či nástroje mimo servery zadavatele s výjimkou služeb a procedur, které jinak objektivně volat a technicky řešit nelze. Zadavatel nepřipouští řešení jakékoliv části uživatelského rozhraní formou desktopové aplikace.
Základní struktura systému Systém je koncipován jako modulární. Základní stavební jednotkou systému je uživatel na straně jedné a funkční celky (moduly) na straně druhé. Uživatel pak dle svých oprávnění a rolí má možnost využívat jednotlivé funkční celky. Propojení uživatelů a funkčních celků zajišťuje databáze, kde každý uživatel nese data napříč jednotlivými moduly. Ve spojení uživatel - modul jsou pak uložena navazující data. Systém musí umět pracovat s daty v jednotlivých modulech samostatně a dále musí umět poskytovat sumární informace, tiskové sestavy a komplexní přehledy oprávněným uživatelům. Součástí zakázky je i návrh struktury databáze systému vč. tabulek, rozložení a typy polí apod. tak, aby databáze byla schopna zvládnout stanovené zatížení. Seznam modulů systému:
Agenda o Správa uživatelů o Hodnocení
2 / 33
o Třídní kniha o Docházka o Rozvrh hodin Centrální databáze Spisová služba Matrika Přijímací a závěrečné výstupy Tiskové výstupy a exporty Půjčovní systém Komunikace o Systém vývěsek o Integrovaný e-mail o SMS komunikace o Notifikace Výuka o Zkušební plány o E-learning o Testy a testování o Úkoly Technické nástroje a interní funkcionalita o Konektory do externích aplikací o Rozhraní pro platební brány o Konektory do SMS bran o Správa licencí o Interní administrační rozhraní
3. Správa uživatelů Uživatel je základní jednotkou systému. Dle svých oprávnění a rolí má možnost využívat jednotlivé funkční celky. Uživatelé mohou nést následující roli:
Žák - uživatel s omezeným oprávněním, má právo především číst data z databází, má právo zapisovat do modulu výuky a všech jejich submodulů, dle nastavených oprávnění a restrikcí zejména souvztažných vzhledem k vlastní osobě. Rodič - uživatel s omezeným oprávněním, zcela konkrétně navázaný na uživatele typu žák. Má právo především číst data z databází, nemá prakticky žádná jiná práva s výjimkou zápisu do modulu docházka, dle nastavených oprávnění a restrikcí souvztažných k osobě spárovaného uživatele typu žák. Učitel - uživatel s poměrně vysokým oprávněním. Má právo zapisovat do většiny modulů v rámci svých oprávnění. Speciální pracovník - uživatel s možností nastavení oprávnění zcela individuálně. Administrátor - uživatel s neomezeným oprávněním a přístupem.
Uživatelé se do systému přihlašují prostřednictvím jedinečného uživatelského jména a hesla.
3 / 33
Kromě jedinečného uživatelského jména a hesla bude systém umožňovat přihlašování formou ověřených aliasů, prostřednictvím služeb Microsoft LiveID, facebook a
4. Agenda Agendou se rozumí především správa základních objektů. Prostřednictvím administračního modulu je nutné zajistit vytváření, editaci a mazání těchto typů objektů. Objekt uživatele typu žák s možností nastavení ze strany uživatele:
relační vazbu skupiny, do které patří relační vazbu třídy, do které patří veškeré osobní údaje dle seznamu položek: o Jméno (text) o Příjmení (text) o Rodné číslo (číslo) o Místo narození (seznam z číselníku) o Stát narození (seznam z číselníku) o Zdravotní pojišťovna (seznam z číselníku) o Číslo smlouvy o Kvalifikátor státního občanství (seznam z číselníku) o Státní občanství (seznam z číselníku) o Bydliště - ulice (text) o Bydliště - PSČ (seznam z číselníku) o Bydliště - Obec (seznam z číselníku) o Bydliště - Okres (seznam z číselníku) o Doručovací - ulice (text) o Doručovací - PSČ (seznam z číselníku) o Doručovací - Obec (seznam z číselníku) o Doručovací - Okres (seznam z číselníku) o Schopnosti (text) o Fotografie (data) o Dojíždí denně (příznak A/N) o Telefon (text) o Mobilní telefon (text) o Fax (text) o E-mail (text) o Notifikace 1 (příznak A/N) o Notifikace 2 (příznak A/N) o Notifikace 3 (příznak A/N) o Notifikace 4 (příznak A/N) o Notifikace 5 (příznak A/N) o Notifikace 6 (příznak A/N) o Notifikace 7 (příznak A/N) o Notifikace 8 (příznak A/N) o Notifikace 9 (příznak A/N) o Notifikace 10 (příznak A/N) 4 / 33
o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o
Předchozí vzdělávání (seznam z číselníku) Počet let splněné povinné školní docházky (číslo) Ročník, ve kterém se žák vzdělává (číslo) Název vzdělávací instituce, kam žák přechází (text) IZO vzdělávací instituce, kam žák přechází (text) Ulice a č.p vzdělávací instituce, kam žák přechází (text) Město vzdělávací instituce, kam žák přechází (text) PSČ vzdělávací instituce, kam žák přechází (text) Číslo v třídním výkazu (číslo) Datum zahájení docházky do ZŠ (datum) Kód zahájení docházky do ZŠ (seznam z číselníku) Datum ukončení docházky do ZŠ (datum) Kód ukončení docházky do ZŠ (seznam z číselníku) Příznak vzdělávání, opakování ročníku (seznam z číselníku) Způsob plnění povinné školní docházky (seznam z číselníku) Vyučovací jazyk třídy (seznam z číselníku) Kód 1. cizího jazyka, kterému se žák učí (seznam z číselníku) Příznak, zda jde o výuku jazyka jako povinného, volitelného nebo nepovinného předmětu (seznam z číselníku) Kód 2. cizího jazyka, kterému se žák učí (seznam z číselníku) Příznak, zda jde o výuku jazyka jako povinného, volitelného nebo nepovinného předmětu (seznam z číselníku) Kód 3. cizího jazyka, kterému se žák učí (seznam z číselníku) Příznak, zda jde o výuku jazyka jako povinného, volitelného nebo nepovinného předmětu (seznam z číselníku) Kód 4. cizího jazyka, kterému se žák učí (seznam z číselníku) Příznak, zda jde o výuku jazyka jako povinného, volitelného nebo nepovinného předmětu (seznam z číselníku) První cizí jazyk, v němž se vyučují předměty (seznam z číselníku) Počet předmětů, které se vyučují prvním cizím jazykem (číslo) Počet hodin vyučovaných v prvním cizím jazyce (číslo) Druhý cizí jazyk, v němž se vyučují předměty (seznam z číselníku) Počet předmětů, které se vyučují druhým cizím jazykem (číslo) Počet hodin vyučovaných v druhém cizím jazyce (číslo) Počet vyučovaných volitelných předmětů (číslo) Počet vyučovaných nepovinných předmětů (číslo) Individuální vzdělávací plán IVP (seznam z číselníku) Rozšíření pro mimořádně nadaného žáka (text) Kód oboru RVP (seznam z číselníku) Délka vzdělávacího programu (číslo) Příznak vzdělávání ve druhém hlavním oboru (seznam z číselníku) Zaměření (seznam z číselníku) Školní vzdělávací program (text) Doložka o získání stupně základního vzdělání (text) Druh prvního zdravotního postižení (seznam z číselníku) Druh dalšího zdravotního postižení (seznam z číselníku)
5 / 33
o o o o o o o o o o o o
Souběžné postižení více vadami (příznak A/N) Financování žáka - požadavek na zvýšené výdaje pro žáka (příznak A/N) Zdravotní způsobilost ke vzdělávání (příznak A/N) Typ a popis postižení (text) Zdravotní znevýhodnění (příznak A/N) Informace o zdravotního znevýhodnění (text) Sociální znevýhodnění (příznak A/N) Informace o sociálním znevýhodnění (text) Odborná praxe (text) Vedení praxe (text) Kontrolní rozlišení, zda jde o větu o absolventovi školy, o žákovi či žákovi, který odešel na jinou školu (seznam z číselníku) Výstupní hodnocení (text)
Přičemž veškeré uživatelské změny uvedených položek, tj. vkládání, editace a výmaz jakéhokoliv záznamu každé z položky, musí být evidovány datem a časem změny a zaznamenány v historii objektu. Tato skutečnost je strategická pro tvorbu modulu Matrika viz dále v textu. Objekt uživatele typu rodič s možností nastavení ze strany uživatele:
relační vazbu k žákovi, ke kterému se váže osobní údaje dle seznamu položek: o Jméno (text) o Příjmení (text) o Kvalifikátor státního občanství (seznam z číselníku) o Státní občanství (seznam z číselníku) o Bydliště - ulice (text) o Bydliště - PSČ (seznam z číselníku) o Bydliště - Obec (seznam z číselníku) o Bydliště - Okres (seznam z číselníku) o Doručovací - ulice (text) o Doručovací - PSČ (seznam z číselníku) o Doručovací - Obec (seznam z číselníku) o Doručovací - Okres (seznam z číselníku) o Fotografie (data) o Telefon (text) o Mobilní telefon (text) o Fax (text) o E-mail (text) o Notifikace 1 (příznak A/N) o Notifikace 2 (příznak A/N) o Notifikace 3 (příznak A/N) o Notifikace 4 (příznak A/N) o Notifikace 5 (příznak A/N)
6 / 33
Objekt uživatele typu učitel s možností nastavení ze strany uživatele:
relační vazbu ke třídě, kde je třídním učitelem relační vazbu k předmětům, které vyučuje relační vazbu ke třídě, ve které může modifikovat osobní údaje žáků relační vazbu ke skupině, ve které může měnit absenci relační vazbu ke skupině, kde je třídním učitelem relační vazbu ke skupině, ve které může modifikovat osobní údaje žáků relační vazbu ke skupině, ve které může měnit absenci osobní údaje dle seznamu položek: o Jméno (text) o Příjmení (text) o Titul (text) o Aprobace (text) o Kvalifikátor státního občanství (seznam z číselníku) o Státní občanství (seznam z číselníku) o Datum narození (datum) o Datum nástupu na školu (datum) o Datum odchodu ze školy (datum) o Pracovněprávní poměr (text) o Poznámka (text) o Bydliště - ulice (text) o Bydliště - PSČ (seznam z číselníku) o Bydliště - Obec (seznam z číselníku) o Bydliště - Okres (seznam z číselníku) o Doručovací - ulice (text) o Doručovací - PSČ (seznam z číselníku) o Doručovací - Obec (seznam z číselníku) o Doručovací - Okres (seznam z číselníku) o Fotografie (data) o Telefon (text) o Mobilní telefon (text) o Fax (text) o E-mail (text) o Notifikace 1 (příznak A/N) o Notifikace 2 (příznak A/N) o Notifikace 3 (příznak A/N) o Notifikace 4 (příznak A/N) o Notifikace 5 (příznak A/N) Nastavení přístupových práv o Má oprávnění správce? (příznak A/N) o Je povoleno se přihlásit? (příznak A/N) o Povoleno modifikovat jiné učitele? (příznak A/N) o Má právo mazat hodnocení a výchovná opatření, ke kterým má právo přístupu? (příznak A/N) o Má právo měnit rozvrh hodin? (příznak A/N)
7 / 33
o o o o o o o o o
Má právo zadávat a měnit suplování? (příznak A/N) Má právo zadávat a měnit tématické plány v předmětech, které učí? (příznak A/N) Má právo číst schránku důvěry? (příznak A/N) Má právo prohlížet archiv a přerušená studia? (příznak A/N) Má právo pracovat s maturitami a závěrečnými zkouškami? (příznak A/N) Má právo spravovat místnosti chatu? (příznak A/N) Má právo spravovat přijímací řízení? (příznak A/N) Má právo spravovat konfigurace tiskových sestav pro tisk vysvědčení (příznak A/N) Má právo spravovat veškerý obsah spisové služby? (příznak A/N)
Pozn: jednotlivé seznamy pro číselníky budou vítěznému dodavateli dodány v elektronické podobě. V následujících kapitolách je postižena specifikace jednotlivých funkcí systému
5. Hodnocení Celý systém bude disponovat modulem hodnocení. Jedná se o schopnost systému evidovat u každého žáka hodnocení různými formami, zohledňující veškeré možné související informace s každým uděleným hodnocením. Systém bude obsahovat hodnocení:
Běžnou škálou číselných známek v intervalu 1 - 5 včetně Bodovou škálou bez omezení maximální hodnoty formou celého čísla v intervalu 0 x, kde X je 999 999. Procentním hodnocením formou celého čísla v intervalu 0 - 100 včetně Slovním hodnocením formou "memo" textu v rozsahu 0 - 5 000 znaků.
U každého hodnocení každým z uvedených způsobů hodnocení bude dále evidováno:
Žák, který hodnocení získal (relace na objekt žáka) Učitel, který hodnocení udělil (relace na objekt učitele) Předmět (relace na seznam předmětů) Datum zadání hodnocení do systému Datum, ke kterému se hodnocení vážě Období (pololetí) Váha hodnocení (celé číslo v intervalu 0 - 100) Relace na seznam položek "za co hodnocení" (uživatelsky definovatelný seznam) Relace na seznam položek "tematický okruh" (uživatelsky definovatelný seznam) Stručný komentář
Přičemž platí následující podmínky a pravidla. Jednotlivá pravidla se sčítají:
Každý učitel může udělit hodnocení pouze v takové množině třídy žáků, ke které má oprávnění (ve které vyučuje)
8 / 33
Každý učitel může udělit hodnocení pouze z takového předmětu množiny předmětů, ke které má oprávnění (které předměty vyučuje) Každý žák může vidět pouze hodnocení, která se vztahují k jeho objektu
Modul bude z technologického hlediska:
Připraven na vstup hodnocení automatizovaně z jiných modulů Připraven pro generování komplexních sestav pro tisk Hodnocení bude možné zadávat individuálně, hromadně, automatizovaně apod. Budou existovat formuláře a obrazovky o pro vstup hodnocení jednotlivě, pro vstup hodnocení hromadně, pro zobrazení hodnocení různými pohledy včetně výpočtu statistik hodnocení, kde tyto statistiky
Kromě hodnocení dle výše uvedených parametrů bude modul obsahovat rovněž tzv. průběžné hodnocení, na které se vztahují všechny výše uvedená pravidla a podmínky. Kromě hodnocení dle výše uvedených parametrů bude modul obsahovat rovněž tzv. hodnocení na vysvědčení, na které se vztahují všechny výše uvedená pravidla a podmínky. Součástí modulu hodnocení je rovněž evidence dalších cca 20 položek, vztahujících se ke každému žákovi a každému jednomu pololetí. Jedná se o výchovná opatření, poznámky, pochvaly apod., bez vazby na další moduly.
6. Rozvrh hodin Rozvrhem hodin se rozumí komplexní plán rozložení předmětů pro každý den a v rámci dne pro každou hodinu, z nichž je sestavena výuka. Přitom rozvrh respektuje veškeré související vazby a jejich podmínky. Tedy každá hodina (položka) v matici rozvrhu je tvořena:
Hodinou, tj. specifikací času a pořadí ve dni (např. 5 hodina začínající ve 13,20) Třídou nebo skupinou ze seznamu tříd nebo skupin Předmětem vybraným ze seznamu předmětů Učitelem, který ji v daném čase vyučuje, vybraným ze seznamu učitelů Učebnou, ve které se hodina nachází, vybranou ze seznamu učeben
Základními vstupními údaji přitom budou:
Celkový počet hodin na učitele Počet hodin na učitele a předmět Počet hodin daného předmětu na třídu a týden event. měsíc Orientační rozsah celkového počtu hodin na třídu a den Event. další podmínky dle požadavků uživatele
Přitom rozvrh hodin musí respektovat tyto logické podmínky:
9 / 33
Nesmí kolidovat celkový počet hodin na den a na třídu Jeden učitel nesmí mít ve stejnou dobu přirazenu více jak jednu hodinu Předmět, učitel a učebna musí být celkově v souladu s nastavením práv. Tj. nelze, aby např. třídě, která vůbec nemá právo na předmět Biologie, šla Biologie nastavit. Stejně tak není možné, aby např. bylo možné nastavit učitele biologie pro tuto třídu, pokud v dané třídě nemá daný učitel vůbec vyučovat. V jedné učebně nesmí být ve stejnou dobu více jak jedna výuka (třída) Jednomu učiteli nesmí být za časovou jednotku jednoho měsíce přiděleno více jak X hodin celkového smluvního úvazku počtu hodin (jež je zadanou konstantou) Musí být vyčerpán počet hodin daného předmětu dle hodinové dotace za stanovenou časovou jednotku. Musí být možné provést a nadefinovat rozvrh hodin s vícetýdenním režimem, při dodržení všech zde uvedených podmínek (například sudý / lichý apod.).
Z pohledu speciálních funkcí pak:
Modul musí splňovat možnost existence tzv. dělených hodin. Jedná se o hodiny, kde jedna třída je rozdělena na 2 - X skupin, přičemž každá skupina má zvláštní požadavky na úpravu rozvrhu. Typicky například u hodiny jazyků se třída rozdělí na polovinu žáků pro jazyk angličtina a polovinu žáků na jazyk němčina. Modul musí najít pro polovinu žáků dle nastavených práv vhodného volného vyučujícího, volnou učebnu apod. Stejně tak pro druhou polovinu třídy v této jedné hodině. To vše při zachování akceptace všech zde uvedených podmínek. Modul musí umožnit tzv. suplování. Tj. uživatelský vstup do rozvrhu s možností vkladu dočasných změn, přičemž jakákoliv změna musí být kontrolována na dodržení logických podmínek. Tj. například pokud absentuje učitel biologie, je nutné jej nahradit jiným učitelem biologie (pokud existuje), a to takovým, který má v danou hodinu volno. A nebo je např. nutné uspořádat rozvrh tak, aby byl daný předmět nahrazen jiným předmětem, za předpokladu, že je pro něj vhodný volný vyučující, dále volná učebna (např. nebude již obsazena tělocvična) a že takový předmět má daná třída v rámci běžné výuky.
Rozvrh hodin dále musí respektovat tyto uživatelské požadavky:
Každá třída musí mít hodiny od první do x-té souvisle ideálně tak, aby mezi nimi nevznikaly mezery (volné hodiny, nebude-li to vyžadovaným požadavkem). Rozložení hodin bude dle nastavení provedeno tak, aby se hodiny stejného předmětu v rámci jedné třídy a jednoho dne neopakovaly. Tj. aby v jeden den nemohla třída např. vyčerpat 5 hodin jednoho předmětu.
Cílem zakázky je vytvořit algoritmus, který postihne všechny uvedené podmínky. Do modulu rozvrhu hodin se bude moci přistupovat z pohledů:
Pohled přes třídu - zobrazí se běžná podoba rozvrhu Pohled přes učitele - zobrazí se rozvrh hodin učitele, tj. kde a co učí Pohled přes učebnu - zobrazí se rozvrh využití učebny, tj. kdy a kým a jakým předmětem je obsazena
10 / 33
Přitom v každém pohledu bude rozvrh moci být uživatelsky modifikovatelný. To znamená, že v náhledu rozvrhu v jednom z uvedených pohledů bude možné dynamicky provést změnu (například záměnu předmětů) a modul musí v relativně krátkém čase provést kontrolu všech podmínek a kolizí, a v případě kolize jakékoliv z podmínek, musí o tomto informovat uživatele. Upozornění: Jakákoliv změna rozvrhu (včetně suplování) musí být uložena s udáním data a času (resp. rozsahu platnosti změny), z důvodu navazujících evidencí a jejich dat, jež je potřebné vyhodnocovat zpětně v čase (zejména docházky a třídní knihy).
7. Docházka Modul eviduje přítomnost nebo nepřítomnost žáka v dané hodině v rámci nastaveného rozvrhu. Stav docházky může být:
nezadáno přítomen nepřítomen, tento stav dále může být o omluven o omluven rodičem o neomluven
Pro zadávání docházky bude existovat samostatný vstupní formulář. Dále bude možné docházku zadávat v modulu třídní knihy. Docházka bude evidována na úroveň každé jednotlivé hodiny. Pozor: Modul musí ukládat a brát v úvahu změnu rozvrhu v čase. Vzhledem k tomu, že se data docházky musí ukládat zpětně, a docházka je přímo založena na rozvrhu a případném suplování (tedy dočasných změn rozvrhu) je třeba počítat s tím, že jakákoliv změna rozvrhu musí být uložena pro správnou evidenci docházky. Výchozí stav docházky je nezadáno. Dle volby učitele se docházka mění na stav přítomen nebo na stav nepřítomen. Pokud je nastaven stav přítomen, pak lze docházku v danou hodinu považovat za uzavřenou a nemá již další stavy. Pokud je stav docházky označen jako nepřítomen, pak je dále nutné očekávat stavy omluven, omluven rodičem nebo neomluven. Do stavu omluven má právo každou hodinu individuálně změnit oprávněný uživatel typu učitel, s právy pro změnu docházky v dané třídě. Omluva docházky V okamžiku, kdy je docházka nastavena na stav nepřítomen, vidí tuto hodinu v tomto stavu i uživatel typu rodič. Tento uživatel má právo pod svým uživatelským účtem docházku pro každou jednu nepřítomnou hodinu individuálně změnit na stav omluven rodičem. Stav omluven rodičem pak má možnost uživatel s právem učitele změnit na stav omluven, a to je již konečný stav hodiny v rámci systému.
11 / 33
Celý modul docházka a struktura databází v něm, budou připraveny pro hromadný export dat a pro kumulační tiskové sestavy.
8. Třídní kniha Modul třídní knihy je denním záznamem o práci a činnosti každé třídy a každého jednoho žáka takové třídy. Technicky se jedná o matici, která postihuje činnosti až na úrovni každé jedné hodiny u každého jednoho žáka pro každou jednu třídu. Třídní kniha je modul přímo vycházející a závislý na objektech: žáci, rozvrh hodin, docházka, absence. Tyto moduly a data z nich třídní kniha kumuluje do jediného výstupu (jež zároveň slouží i jako vstupní formulář) a využívá pro zápis dat do ní a dále pro tiskové sestavy a výstupy z ní. Přesný algoritmus díky relativní složitosti a specifické logice bude dodán vítěznému dodavateli po zahájení realizace zakázky. Samotná třídní kniha nad rámec uvedených databází a modulů disponuje dále těmito položkami:
Hodina (číslo z číselníku rozvrhu, dynamicky navázáno na aktuální rozvrh včetně aktuálního suplování) Předmět (hodnota z číselníku rozvrhu, dynamicky navázáno na aktuální rozvrh včetně aktuálního suplování) Počet odučených hodin (číslo) Datum (datum) Probrané učivo (text) Pořádková služba (výběr z databáze žáků) Poučení, akce a dalších cca 20 položek typu text
Uživatelsky základním rozhraním třídní knihy je formulář, který zobrazuje oprávněnému učiteli aktuální hodinu formou seznamu žáků, kde jsou zobrazeny navazující položky absence, předmět, apod. v dané hodině. Veškerá zobrazovaná data plně v reálném čase korespondují s daty v souvisejících agendách a uživatel v rámci nich vyplňuje podle nastavených oprávnění pouze výše uvedené položky (pro každou hodinu individuálně). Poznámka: Podobně jako u některých ostatních modulů je nezbytné, aby modul ukládal a bral v úvahu změnu dat v třídní knize v čase. Celý modul a struktura databází v něm, budou připraveny pro hromadný export dat a pro kumulační tiskové sestavy.
9. Centrální databáze Je modul, který slouží jako vzdálený logický disk pro každého uživatele systému. Předmětem zakázky je vybudovat rozhraní, které bude svými vlastnostmi připomínat program Průzkumník v operačním systému Windows. Bude se jednat o strukturu složek, podsložek a koncových souborů. Přitom zásadní bude skutečnost, že v rámci systému se bude jednat o jednotné datové úložiště pro celou organizaci s přidělenými přístupovými právy pro každého jednoho uživatele, nebo skupinu uživatelů, nebo třídu jako celek.
12 / 33
Koncový uživatel pak bude moci strukturou složek procházet a provádět standardní operace. Tj. zejména otvírat adresáře a podadresáře, stahovat soubory, ke kterým bude mít přístup, nahrávat soubory do adresářů, ke kterým bude mít právo zápisu, provádět další případné operace, bude-li na to mít právo (přejmenování, mazání apod.). Požadavky na funkčnost modulu:
Schopnost vytvářet a uchovat z pohledu uživatele stromovou strukturu adresářů, podadresářů a souborů libovolného typu s omezením maximální velikosti. Schopnost tuto stromovou strukturu větvit minimálně do úrovně 255 podadresářů, od hlavního adresáře. Schopnost s touto stromovou strukturou manipulovat podobně jako se stromovou strukturou na disku počítače, s přihlédnutím k možnostem webového prostředí, zejména ale: o umožnit vkládat do stromu libovolné soubory, adresáře a podadresáře o umožnit mazat libovolný soubor a nebo adresář - v takovém případě pak smazat i jeho podadresáře o umožnit přemístit soubor a nebo adresář do jiného adresáře, včetně veškerého obsahu se zachováním stromu o přejmenovávat objekty Schopnost nastavit přístupová práva takto: o Na každý adresář mít možnost nastavit práva na čtení a nebo čtení a zápis pro vybraného konkrétního uživatele bez ohledu na jeho typ, nebo skupinu uživatelů nebo jednu celou třídu včetně všech objektů které obsahuje. Tato práva nechť jsou nastavena včetně všech podadresářů daného adresáře (schopnost dědění práv). Schopnost zaznamenávat počet stažení každého souboru.
Pro nahrávání dat (upload) ze strany uživatelů bude vzhledem k výše definované podmínce systému jako online aplikace v internetovém prohlížeči, nutné, aby byl vytvořen zvláštní "uploader", obsahující tyto vlastnosti:
Uploader bude umožňovat při vkládání souborů vybrat více jak jeden soubor pro jednorázový upload. Po zahájení uploadu poběží proces uploadu paralelně např. jako pop-up okno nebo vrstva na pozadí, tak, aby upload jako takový po celou svoji dobu činnosti nebrzdil práci uživatele se systémem (resp. aby čas potřebný pro upload nezamezil práci se systémem). Upload bude obsahovat grafický ukazatel činnosti, zobrazující: o Název souboru, který se právě uploaduje o Grafický ukazatel průběhu uploadu o Číselné znázornění velikosti a stavu uploadu formou hodnoty velikosti přenesených dat a nebo procent. Uploader bude kontrolovat před zahájením nahrání souboru na server jeho velikost a soubory větší než x MB na server odmítne nahrát. Hodnota x bude upřesněna zadavatelem. Tím bude zajištěno, že na server nebude možné principiálně nahrávat data, resp. soubory o velikosti větší než x.
13 / 33
10. Spisová služba Modul je určen pro vedení spisové služby a pro oběh dokumentů vzdělávací organizace. Základem modulu pro vedení spisové služby je spis. Spis pak jako objekt obsahující nosné informace má vlastní životní cyklus. Od jeho založení (vznik), přes přeposlání dalším kompetentním osobám, až po jeho archivaci dle přísl. zákonů. Spis je složen z:
Typ spisu (seznam z číselníku) Stav spisu (seznam z číselníku) Informace o odesilateli (dynamická proměnná) Datum odeslání (datum) Číslo jednací (číslo) Spisová značka (text) Informace o příjemci (text) Datum přijetí (datum) Číslo jednací (text) Informace o obsahu (text) Řešitel (seznam z číselníku) Komunikační kanál (seznam z číselníku) Doporučené (příznak A/N) Do vlastních rukou (příznak A/N) K rukám (text) Předmět (text) Stručný komentář (text) Vlastní obsah spisu - datový obsah v podobě seznamu datových souborů
Životní cyklus spisu je zahájen okamžikem jeho vzniku. Spisem se přitom rozumí spis přijatý i spis odeslaný. Každý spis může vytvořit oprávněný uživatel. Oprávněný uživatel má rovněž právo spis postoupit jinému oprávněnému uživateli, má možnost nastavit jeho parametry a zatřídit jej v rámci jeho položek. Během cyklu spisu tento mění své stavy až do stavu "archivován", kdy je spis trvale uložen po dobu zákonem stanovené skartační lhůty v archivu spisů. Pro evidenci spisů jsou v rámci tohoto modulu strategické vlastní datové přílohy, tvořící vlastní obsah spisu. Datovými přílohami se rozumí jeden až X souborů (teoreticky neomezené množství, prakticky omezeno na 300 souborů), které mohou být libovolného typu a velikosti do 50 MB každého jednoho souboru. U nově vytvářených spisů bude modul obsahovat nástroj pro nahrávání souborů - uploader. Uploader bude pracovat jako online aplikace v internetovém prohlížeči. Bude obsahovat tyto vlastnosti:
Uploader bude umožňovat při vkládání souborů vybrat více jak jeden soubor pro jednorázový upload.
14 / 33
Po zahájení uploadu poběží proces uploadu paralelně např. jako pop-up okno nebo vrstva na pozadí, tak, aby upload jako takový po celou svoji dobu činnosti nebrzdil práci uživatele se systémem (resp. aby čas potřebný pro upload nezamezil práci se systémem). Upload bude obsahovat grafický ukazatel činnosti, zobrazující: o Název souboru, který se právě uploaduje o Grafický ukazatel průběhu uploadu o Číselné znázornění velikosti a stavu uploadu formou hodnoty velikosti přenesených dat a nebo procent. Uploader bude kontrolovat před zahájením nahrání souboru na server jeho velikost a soubory větší než x MB na server odmítne nahrát. Hodnota x bude upřesněna zadavatelem. Tím bude zajištěno, že na server nebude možné principiálně nahrávat data, resp. soubory o velikosti větší než x.
U typu spisu přijatého bude systém importovat vlastní obsah i definované proměnné z externích aplikací, zejména ze systému datových schránek. V rámci modulu spisové služby je nutné řešit napojení na systém datových schránek (ISDS) a schopnost s tímto systémem pracovat. Principiálně se jedná o schopnost přihlásit se do ISDS a stáhnout přijaté zprávy včetně obsahu na straně přijatých spisů. Stejně tak na straně odeslaných spisů schopnost přihlásit se do ISDS, exportovat všechna povinná pole a korektně odeslat datovou zprávu zamýšlenému příjemci, včetně verifikace úspěšného odeslání. Detailní informace o systému datových schránek, jako externí spolupracující aplikaci nabízí webová adresa: http://www.datoveschranky.info/cz/metodicke-postupy/pro-dodavateleaplikaci-tretich-stran-id34706/ Stručná elementární charakteristika systému datových schránek, jako výňatek z provozního řádu ISDS: Datovou zprávu tvoří obálka a obsah zprávy. Systém ISDS umožňuje získání datové zprávy označené elektronickou značkou ministerstva založené na kvalifikovaném systémovém certifikátu (viz dokumentace webových služeb ISDS v příloze - operace SignedMessageDownload). Pokud uživatel v prostředí klientského portálu ISDS ukládá datovou zprávu do souboru, zpráva se ukládá v tomto tvaru. Obsahem zprávy může být jedna či více příloh v počítačovém formátu uvedeném v Příloze 3 vyhlášky č. 194/2009 Sb. Provozovatel má právo nepřijmout k odeslání datovou zprávu obsahující škodlivý kód. Vyhláška č. 194/2009 Sb. o stanovení podrobností užívání a provozování informačního systému datových schránek upravuje pouze přípustné formáty příloh datové zprávy dodávané do datové schránky. Datovou zprávou se dle § 19 Zákona rozumí dokument orgánů veřejné moci a úkon prováděný vůči orgánu veřejné moci prostřednictvím datové schránky. Zákon č.300/2008 Sb. a související právní předpisy umožňují a v některých případech dokonce přímo ukládají, aby tyto datové zprávy byly elektronicky podepsány a bylo k nim připojeno časové razítko. Proto správce rozhodl, aby Informační systém datových
15 / 33
schránek umožňoval kromě doručování vlastních dokumentů i doručování elektronických podpisů a časových razítek v běžně rozšířených formátech.
CER, CRT, DER, PK7 - formáty certifikátů dle standardu X.509 P7B, P7C, P7F, P7M, P7S - formáty certifikátů a elektronických podpisů dle PKCS#7 TST, TSR - formáty pro elektronické razítko
Omezení velikosti DS: ISDS umožňuje odeslat pouze datovou zprávu s přílohami, jejichž celková velikost bude maximálně 10 MB. Hromadná datová zpráva: Pokud uživatel odesílá prostřednictvím klientského rozhraní datovou zprávu na více příjemců, použije se funkce hromadného zasílání datových zpráv. Způsob odesílání datové zprávy na více příjemců s pomocí technického prostředku (aplikace) se může lišit v závislosti na způsobu implementace jednotlivých dodavatelů těchto aplikací. Jedna hromadná zpráva může mít maximálně 50 adresátů. Doba uchovávání DS: ISDS uchová datovou zprávu po dobu 90ti dnů od okamžiku, kdy se do datové schránky přihlásila osoba, která má s ohledem na rozsah svých oprávnění přístup k dokumentu v datové zprávě obsaženém. Datovou zprávu doručenou fikcí uchovává ISDS po neomezenou dobu. Provozovatel má právo takové zprávy po 90ti dnech od fikce doručení přemístit do off-line datového úložiště, ze kterého lze zprávu na žádost příjemce zprávy vrátit zpět do jeho datové schránky. ISDS umožňuje napojení aplikací třetích stran, jako jsou například Agendové informační systémy orgánů veřejné moci, spisové služby orgánů veřejné moci, ERP systémů nebo DMS systémů komerčních organizací a podobně, pomocí Webových služeb. Tyto služby jsou definované na stránce http://www.datoveschranky.info/cz/metodicke-postupy/pro-dodavateleaplikaci-tretich-stran-id34706/ Webové služby manipulující s datovými zprávami pro použití v externích agendách (včetně elektronických spisových služeb): V dm_operations jsou definovány následující webové služby:
vytvoření a odeslání nové zprávy – CreateMessage vytvoření a odeslání hromadné zprávy – CreateMultipleMessage stažení došlé zprávy – MessageDownload stažení došlé zprávy s podpisem značkou MV – SignedMessageDownload stažení odeslané zprávy s podpisem MV – SignedSentMessageDownload ověření uložené datové zprávy – AuthenticateMessage prázdná operace pro navazování nebo udržování spojení – DummyOperation přepodepsání zprávy, dodejky či doručenky – Re-signISDSDocument.
V dm_info jsou definovány následující webové služby:
ověření neporušení datové zprávy – VerifyMessage stažení obálky došlé zprávy – MessageEnvelopeDownload označení zprávy jako „Přečtená“ – MarkMessageAsDownloaded 16 / 33
stažení informace o dodání a doručování zprávy – GetDeliveryInfo stažení informace o dodání a doručování zprávy, s podpisem značkou MV – GetSignedDeliveryInfo stažení seznamu došlých zpráv – GetListOfReceivedMessages stažení seznamu odeslaných zpráv – GetListOfSentMessages doručení poštovní datové zprávy – ConfirmDelivery stažení seznamu zpráv, u kterých došlo ke změně stavu – GetMessageStateChanges zjištění identifikace odesílatele zprávy - GetMessageAuthor smazání dlouhodbě uložené DZ (trezorové) - EraseMessage
Všechny tyto webové služby s výjimkou CreateMessage, CreateMultipleMessage, MarkMessageAsDownloaded, VerifyMessage, AutenticateMessage a ResignISDSDocument způsobují přihlášení do datové schránky majitele a doručování zpráv ve smyslu § 17 odst. 3 Zákona.
11. Matrika Systém bude umět kompletně evidovat, spravovat a následně exportovat data dle vyhlášky č. 364/2005 Sb., o vedení dokumentace škol a školských zařízení a školní matriky a o předávání údajů z dokumentace škol a školských zařízení a ze školní matriky (vyhláška o dokumentaci škol a školských zařízení). Jedná se o evidování, sběr, strojové zpracování a následný export dat o žácích, včetně vypočítaných souvislostí, a to v čase. Konkrétně se jedná o uchovávání asi cca 80 základních ukazatelů a informací o každém žákovi, z nichž některé jsou přímo evidované v databázi, jiné jsou definovaným algoritmem vypočítány, a to s ohledem na datum a čas změny každého údaje. Z toho důvodu je nutné každou informaci o objektu typu žák evidovat nejen jako prostý údaj v databázi, ale u každé změny každého údaje je nutné evidovat i změnu samotnou. Nejvýznamnějším předmětem řešení u tohoto modulu je export dat. Exportem dat se rozumí export datového XML souboru, který bude o každém objektu typu žák extrahovat vybrané údaje, jež budou předem buď přímo převzaty z databáze a nebo budou při exportu dat počítány na základě předem daných algoritmů viz vyhláška výše. Soubor s exportem pak musí být navržen tak, aby prošel validátorem na straně MŠMT. Z pohledu modulu bude nutné každou datovou větu zkontrolovat na cca 40 logických podmínek. Pokud věta nebude vyhovovat některé z podmínek, nebo kombinaci podmínek apod., bude o tomto proveden výstup formou exportního souboru se sdělením chyby a doporučením opravy pro uživatele. V korektním případě je výstupem modulu validní XML soubor ke stažení uživatelem, připravený pro další import na MŠMT. Komplexní popis uchovávaných dat, strukturu XML souborů, včetně logických podmínek, apod., obsahuje veřejně dostupná vyhláška viz výše včetně připojených prováděcích předpisů a jejich příloh.
17 / 33
12. Přijímací a závěrečné výstupy Modul pro definici přijímacích řízení slouží pro evidenci a správu přijímacího řízení. Základní jednotkou je jedno tzv. přijímací řízení. Systém umožní vytvořit libovolný počet přijímacích řízení. Princip modulu spočívá v tom, že do každého uživatelsky vytvořeného přijímacího řízení budou vložena kritéria (jejich libovolný počet) a jejich hraniční hodnoty (například za kritérium lze považovat "test" a za jeho hraniční hodnotu lze považovat dosažení X bodů). Do každého řízení pak bude moci být vložen libovolný počet uchazečů a ke každému uchazeči budou ze strany uživatele vyplněna kritéria. Celé jedno přijímací řízení bude mít nastaveny uživatelem dynamicky definovatelné podmínky přijatelnosti uchazečů a počet možných přijatelných uchazečů. Na základě těchto hodnot systém vyhodnotí přijaté a nepřijaté uchazeče. Vyhodnocení pak bude exportovatelné jak datově v elektronické podobě (ve formátu CSV), tak i jako připravené soubory pro následný tisk (PDF).
13. Tiskové výstupy a exporty Strategickou funkčností v rámci návrhu celého systému jsou datové a tiskové výstupy. Datové a tiskové výstupy lze rozdělit na dvě velké skupiny: 1) Výstupy v rámci výpisů napříč systémem 2) Agenda připravených tiskových výstupů
13.1. Výstupy v rámci výpisů napříč systémem Obecně bude v celém systému engine pro zobrazování výpisů dat navržen tak, aby byla možnost výstupů integrována do prakticky jakékoliv sloupcové sestavy dat, zobrazené na jakékoliv stránce s výpisem dat směrem k uživateli. Tedy v každém generovaném výpise seznamu položek bude nástroj, který dokáže tento seznam exportovat do datové podoby a dále do podoby tisknutelné sestavy. Datové výstupy Datovým výstupem zobrazené sestavy se rozumí možnost exportu dat a jejich uživatelsky přijatelné stažení v těchto formátech:
CSV XLS
Přičemž pokud bude zobrazený výstup daného výpisu stránkovaný s ohledem na uživatelskou přívětivost, pak datové výstupy budou postihovat komplexní výstup, bez ohledu na stránkování. Tiskové výstupy Tiskovým výstupem zobrazené sestavy se rozumí možnost exportu dat v grafické podobě do souboru tak, aby výstup byl po stažení souboru připraven pro okamžitý tisk bez nutnosti
18 / 33
dalších úprav v navazujícím softwaru. Z toho důvodu zadavatel preferuje obecně uznávaný formát souboru PDF.
PDF
Přičemž pokud bude zobrazený výstup daného výpisu stránkovaný s ohledem na uživatelskou přívětivost, pak tiskové výstupy budou postihovat komplexní výstup, bez ohledu na stránkování.
13.2. Agenda připravených tiskových výstupů Kromě uvedené možnosti exportu výpisů bude systém obsahovat 120 uživatelsky modifikovatelných tiskových sestav generovaných do formátu PDF, připravených dle zadaného vzoru a specifikace. Tiskovou sestavou se zde rozumí uživatelsky modifikovatelné datové matice vybrané z předpřipravených datových struktur, kde uživatel zvolí vybrané položky databáze a související vzorce, z nichž bude sestava vypočítána. Například předpřipravenou tiskovou sestavou bude výpis hodnocení žáků. Tedy sestava bude vytvořena tak, že bude patrné s jakými daty se bude pracovat, ale konkrétní podoba sestavy v její finální verzi bude již na definici uživatele. Uživatel si bude moci sám zvolit např. pohledy na vlastní definované třídy a bude si moci v rámci určitých mantinelů zvolit, jaké vzorce pro sumární zobrazení výsledků budou použity (např. průměry, medián, sumy apod). Z uvedeného plyne, že pro dosažení cíle tohoto modulu je nutné vytvoření takového pomocného obecného nástroje, kterým bude ze systémového hlediska možné tiskové sestavy předpřipravit (vydefinovat databáze, jejich položky, struktury sestav apod.) a z uživatelského hlediska pak každou tiskovou sestavu dodefinovat uživatelsky (sumarizační vzorce, podmínky pro zobrazení dat v sestavě apod.). Přičemž z pohledu uživatelské definovatelnosti tiskové sestavy bude každá sestava dle jejich datových struktur a možností umožňovat:
Nastavit pro každý datový prvek sestavy uživatelsky definovatelnou podmínku a podmíněné omezení. A to jak na datové prvky typu text, tak na datové prvky typu číslo, datum apod.. (například pokud předmětem sestavy bude seznam žáků, pak v sestavě bude možné uživatelsky nastavit podmínku na výběr příjmení začínajícího na X, obsahujících řetězec Y apod.) Nastavit závěrečné funkce (suma, průměr apod. viz níže) U sestav, kde to bude možné, nastavit definici vlastního uživatelsky definovaného sloupce, formou vzorce v rozsahu funkcí uvedených níže.
Hovoříme li o užití vzorců v uživatelsky definovatelných položkách a sloupcích, rozumí se tím užití základní vzorců a základních operátorů ve vzorcích. Tedy funkce +, -, x, /, suma, průměr, medián, počet. Pozor, je nutné brát v úvahu, že každá sestava je sestavou tiskovou. Tedy výstupem sestavy bude primárně formát PDF ke stažení, v grafické podobě, určený k následnému vytištění. V rámci modulu je tedy nutné vyvinout vlastní nebo implementovat externí engine, který
19 / 33
umožní systémově pracovat s PDF a generovat data do PDF, a to včetně doprovodné grafiky (čáry, křivky, vybarvené plochy, obrázky apod.). Z celkových 120 sestav bude 55 tiskových sestav výrazně grafických. Grafickou tiskovou sestavou se rozumí sestava ve formátu PDF, která bude provedena dle grafického vzoru (šablony). Typickým grafickým vzorem s typickou náročností je například formulář vysvědčení, formulář třídní knihy, apod., resp. jedná se o formulář s množstvím čar a křivek. Systém bude umět takový formulář v rámci PDF vykreslit a data do něj (do jednotlivých položek) vygenerovat a pozičně umístit. Samotné konkrétní specifikace a podobu tiskových sestav bude možné dodat až po doladění datových modelů databází s vybraným uchazečem.
14. Půjčovní systém Modul výpůjčního systému slouží pro evidenci předmětů určených pro výpůjčku, jejich správu a kontrolu v rámci organizace. Funkčnost modulu spočívá v evidenci předmětů určených pro výpůjčku (např. kniha, lyže, notebook, DVD apod.) na straně jedné a v evidenci toků půjčení předmětu na straně druhé. Životní cyklus předmětu pro výpůjčku je: 1. 2. 3. 4. 5. 6.
Založení karty předmětu pro výpůjčku. Definice parametrů předmětu pro výpůjčku. Zařazení předmětu pro výpůjčku do systému pro půjčování. Proces půjčení Proces vrácení Vyřazení předmětu z výpůjčního systému po době životnosti předmětu.
Aby bylo možné celý proces půjčení předmětu realizovat, je nutné vytvořit související agendy.
Agenda pro správu předmětů Agenda pro správu kategorií Agenda pro správu typů předmětů Agenda pro vlastní půjčování
Přičemž Agenda pro správu kategorií a Agenda pro správu typů předmětů budou prostými agendami, složenými s jednopoložkového číselníku, který bude jednoduchým uživatelským formulářem editován, vytvářen a mazán. Agenda pro správu předmětů se bude sestávat z položkového seznamu předmětů, s možností vytváření, editace a mazání jednotlivých předmětů. Definice karty předmětu určeného pro výpůjčku:
Evidenční číslo (číslo) Typ předmětu (seznam z číselníku) Název předmětu (text) Podnázev předmětu (text) Rozměry, formát (text)
20 / 33
Další technické parametry (text) Autor předmětu (text) Dodavatel, vydavatel (text) Kategorie (seznam z číselníku) Popis předmětu (text) EAN předmětu (číslo) Fotografie 1 předmětu (data foto) Fotografie 2 předmětu (data foto) Fotografie 3 předmětu (data foto) Počet kusů (číslo) Nákupní cena (číslo) Udaná cena - hodnota předmětu (číslo) Cena za výpůjčku (číslo) Přednastavený počet dní zápůjčky (číslo) Zveřejněno pro výpůjčku (ano / ne)
Do prostředí modulu budou mít přístup uživatelé typu žák, kteří budou hlavním skupinou uživatelů, provádějící výpůjčky. Dále do systému budou mít přístup uživatelé typu učitel s právy pro správu výpůjčního systému, kteří budou moci zasahovat do procesu výpůjček a budou moci administrovat agendy související s výpůjčkami. Z pohledu uživatele bude systém nabízet předměty pro výpůjčku formou prostého seznamu předmětů. U každého předmětu bude uvedena cena za výpůjčku, počet volných kusů daného předmětu aktuálně dostupného k vypůjčení, a po klepnutí na detail předmětu i veškeré související detailní informace viz. definice karty předmětu. Za předpokladu, že nebude volný žádný kus daného předmětu k výpůjčce, systém zobrazí předpokládané datum dostupnosti tohoto předmětu, vygenerované na základě data výpůjčky + hodnoty počtu dnů předpokládané zápůjčky. Základní specifikace pravidel modulu výpůjčky:
Každý předmět výpůjčky se v systému objeví v okamžiku zveřejnění předmětu pro výpůjčku. Každý předmět výpůjčky je možné půjčovat až do vyčerpání celkového počtu kusů předmětu výpůjčky. Současně tak jeden předmět, existuje-li v X kopiích, může být vypůjčen X krát. Uživatel typu žák má právo dostupný předmět pro výpůjčku zarezervovat na stanovenou dobu, čímž se daný předmět sníží o daný kus jako dostupný pro ostatní uživatele. Uživatel typu žák má právo rezervaci zrušit, čímž se daný předmět opět v adekvátním počtu kusů uvolní pro další rezervaci. V případě, že je daný předmět výpůjčky na nule a tedy nedostupný, má právo si uživatel typu žák zarezervovat předmět tzv. napřed, tj. tento se po rezervaci stane nedostupný na dobu o další počet dní delší (definovanou hodnotou Přednastavený počet dní předpokládané zápůjčky), než je doba původního vrácení před uskutečněnou touto rezervací.
21 / 33
Modul bude v každém okamžiku umět generovat související sestavy:
Seznam předmětů v aktuální výpůjčce Seznam rezervací Seznam osob meškajících s vrácením předmětu po termínu Seznam předmětů po termínu vrácení
15. Komunikace Komunikační modul tvoří strategickou část celého systému. Komunikační modul bude provázán prakticky se všemi ostatními moduly, bude z nich extrahovat vybraná data a předávat je dle konkrétních podmínek do komunikačních kanálů směrem ke koncovým uživatelům. Celý systém komunikace tak bude obsahovat několik úrovní komunikace a s tím souvisejících několik submodulů:
Systém vývěsek Integrovaný e-mail SMS komunikace Notifikace
Základní jednotkou pro každý submodul v rámci modulu Komunikace je zpráva. Zpráva je iniciovaná buď uživatelem a nebo automaticky vyvolaná některou událostí. Způsob zpracování zprávy je v každém submodulu odlišný.
Systém vývěsek Jedná se o submodul, kde iniciátorem zprávy je uživatel. Vývěskou se rozumí centrální informační nástěnka organizace, ke které mají přístup všichni uživatelé všech typů a která shromažďuje sdělení a informace od oprávněných uživatelů, typicky uživatelů typu učitel. Zpráva je iniciována prostřednictvím uživatelského formuláře. Zpráva vývěsky má následující strukturu:
Priorita zprávy (číslo v intervalu 1-5) Předmět zprávy (text) Tělo zprávy (text) Seznam příjemců zprávy (definice z číselníku seznamu uživatelů) Datum odeslání zprávy (datum)
Výstup zprávy je zobrazen na hlavní stránce každého uživatele po přihlášení. Zpráva je dále distribuována prostřednictvím komunikačních kanálů dle platného nastavení. Integrovaný e-mail Součástí zakázky je integrace e-mailového systému. Každý uživatel systému, bude mít k dispozici e-mailovou schránku, která se bude automaticky vytvářet při založení uživatele a bude se rušit v okamžiku zrušení uživatele.
22 / 33
Schránku budou mít uživatelé všech typů (žák, učitel apod..). Systém tak musí být navržen tak, aby počítal se zvládnutím řádově stovek tisíc e-mailových schránek. Na straně serveru je zadavatel připraven k instalaci dodavatelem dodaného e-mailovacího serveru pro takovou platformu, jakou si dodavatel zvolí s ohledem na serverové technologie viz ostatní kapitoly tohoto dokumentu. Tento e-mailový server, bude-li na platformě placených systémů třetích stran, bude součástí ceny zakázky včetně souvisejících produktů a služeb. Přístup k e-mailu bude probíhat primárně prostřednictvím integrovaného webového emailového klienta, jehož dodávka je součástí zakázky, sekundárně bude systém umožňovat práci s e-maily pomocí protokolů IMAP a POP3. Zadavatel umožňuje integraci webového klienta třetích stran do systému za předpokladu, že tento bude funkčně a vizuálně integrován do rozhraní systému tak, aby z uživatelského pohledu byl vstup do e-mailu hladký a bezproblémový. Zadavatel rovněž požaduje, aby přístup k informacím o nových e-mailech a notifikace nových e-mailů uživatelů, umožňovaly procedury dodaného modulu, zcela bez nutnosti spuštění webového klienta. Tzn. modul musí v rámci dodaného e-mailového serveru umět komunikovat prostřednictvím standardních protokolů s tímto serverem. Požadavky na e-mailový systém (i v rámci webového klienta):
Dynamicky vytvářet a rušit e-mailové schránky Schopnost přijímat zprávy do e-mailových schránek Schopnost vytváření nových emailových zpráv, včetně příloh apod. dle standardní specifikace e-mailu (odesílatel, příjemce, předmět zprávy, tělo zprávy, přílohy) Programová podpora protokolů IMAP a POP3. Integrace vyvinutého webového klienta nebo integrace existujícího webového klienta třetích stran. Notifikace nových e-mailů ze strany systému bez nutnosti otevření e-mailového klienta.
Přičemž funkčnost e-mailu a všech s ním spojených procedur bude odpovídat standardní specifikaci e-mailové komunikace (pole hlavičky, schopnost nést tělo i přílohy apod.). Do e-mailového klienta bude nad rámec klasického e-mailu integrován interní dynamicky generovaný adresář a schopnost procházení adresářem uživatelů systému. Tento interní adresář bude generován zcela dynamicky a bude obsahovat v každém okamžiku aktuální seznam všech uživatelů systému, dělený do skupin a tříd dle typů objektů viz tato dokumentace. Jednorázově tak například bude možné zaslat e-mail všem rodičům, všem uživatelům třídy X apod. aniž by je bylo nutné obtížně vyhledávat. E-mailing V souvislosti s e-mailovým klientem bude systém umožňovat rozesílku automatizovaných emailových zpráv notifikačního a informačního charakteru. E-mailové zprávy se odesílají automaticky prostřednictvím e-mailového serveru. Princip zasílání automatizovaných e-mailových zpráv bude takový, že systém bude generovat frontu e-mailů dle nastavených pravidel a tuto frontu bude postupně odesílat e-mailový server.
23 / 33
Iniciátorem vzniku automatizovaných e-mailových zpráv jsou výhradně automatizované skripty na základě akcí jednotlivých modulů. Například vznik nové známky u žáka = e-mail odeslaný rodiči, nová zpráva vývěsky = e-mail určenému uživateli apod. Seznam akcí, jež budou generovat e-mailové zprávy obsahuje text Notifikace viz níže. SMS komunikace Jedním z komunikačních kanálů systému bude SMS zpráva. SMS zprávy se odesílají automaticky prostřednictvím mobilního operátora, od jehož prostředí zadavatel poskytne implementační dokumentaci. Princip zasílání SMS zpráv bude takový, že systém bude generovat frontu SMS dle nastavených pravidel a tuto frontu bude postupně odesílat do externího prostředí smluvního partnera - mobilního operátora. Veškeré parametry se předávají API pomocí HTTPS metodou GET (přímo v URL adrese). Ukázka URL pro volání oddeslání SMS pomocí API: https://adresa_bude_dodana.cz?uid=XXXX&password=XXXX&number=%2B420123456789 &text=text+sms+zpravy Iniciátorem vzniku SMS zpráv jsou výhradně automatizované skripty na základě akcí jednotlivých modulů. Například vznik nové známky u žáka = SMS odeslaná rodiči, nová zpráva vývěsky = SMS určenému uživateli apod. Seznam akcí, jež budou generovat SMS zprávy obsahuje text Notifikace viz níže. Zadavatel požaduje řešení pouze odeslaných SMS zpráv. Tato zakázka neobsahuje příjem a zpracování přijatých SMS zpráv. Tato zakázka neobsahuje potřebu uzavření smlouvy s mobilním operátorem o odesílání SMS zpráv. Zadavatel dodá vítězi výběrového řízení specifikaci hotového rozhraní na straně mobilního operátora, pro příjem SMS zpráv směrem k vlastníkům mobilních telefonů. Platby za SMS zprávy hradí mobilnímu operátorovi zadavatel. Notifikace Modul notifikace je interním modulem, jež spravuje a nastavuje notifikační procedury v rámci celého systému. Modul postihuje všechny ostatní moduly celého systému a dle níže uvedené tabulky generuje notifikační události v podobě informačních e-mailů, SMS zpráv apod. Každý uživatel má právo nastavit si v rámci svého uživatelského účtu, zda a jakým způsobem bude přijímat notifikační informace. Následující tabulka zobrazuje potřeby notifikace u konkrétních modulů. U modulu, kde je potřeba notifikace je uveden symbol "A". Agenda Správa uživatelů Hodnocení Třídní kniha Docházka
24 / 33
E-mail
SMS
A
A
A
A
Rozvrh hodin Centrální databáze Spisová služba Matrika Přijímací a závěrečné výstupy Tiskové výstupy a exporty Půjčovní systém Komunikace Systém vývěsek Integrovaný e-mail Výuka Zkušební plány E-learning Testy a testování Úkoly Technické nástroje a interní funkcionalita Konektory do externích aplikací Rozhraní pro platební brány Konektory do SMS bran Správa licencí Interní administrační rozhraní
A
A
A A A A A A A A A
A A A A A A A A A
16. Výuka Z pohledu plnění předmětu zakázky bude vývoj dodavatele zaměřen mimo jiné na funkce určené pro správu a distribuci elektronického obsahu, zejména výukových materiálů a učebnic a na výukový software na bázi e-leaningu. Tím ale není myšlen pouze zcela klasický e-learning, ale mimo jiné i systém pro tvorbu interaktivních učebnic s návazností na výstupy pro elektronické tabule a mobilní platformy (tablety, chytré telefony apod.). Předmětem zakázky je dodávka - vytvoření a naprogramování specifického modulu pro tvorbu a správu výukového datového obsahu. Datovým obsahem se zde rozumí větší strukturované celky dat, např. e-learningové celky, elektronické knihy, e-knihy do hardwarových čteček, multimediální e-learningové kurzy, videopořady, audiopořady, vzdělávací kurzy, výukové materiály pro školy a školicí střediska apod. Systém by měl umět se všemi těmito druhy médií pracovat, zpracovávat je, ale rovněž nabízet v interním seznamu výukových materiálů. Principiálně se tedy jedná o subsystém, který bude datový strukturovaný obsah umět nejen vlastními prostředky vytvářet, ale také shromažďovat podle řady kritérií, zobrazovat a nabízet ke stažení. Celý systém bude umět data v systému obsahově strukturovat do jednotlivých celků dle typu cílové skupiny a kategorií. Součástí systému budou nástroje, pomocí kterých bude možné obsah pohodlně upravovat a vytvářet. Uživatel systému bude mít současně možnost tento vlastní obsah podle svého uvážení buď neomezeně zveřejnit, anebo kontrolovaně svůj obsah šířit definované cílové skupině uživatelů. Kontrolovaným šířením obsahu se rozumí zpřístupnění obsahu omezené a předem konkrétně definované skupině uživatelů (např. vybraná třída).
25 / 33
16.1. E-learning E-learningová aplikace bude umět vytvořit ve speciálním editoru strukturovaný datový obsah. Datový obsah bude moci být složen z textu a multimediálních audiovizuálních prvků (obrázky, zvuky, hudba, video, hypertextové odkazy, flash objekty apod.) strukturovaný do kapitol a podkapitol. Tento druh obsahu je limitován prakticky jen možnostmi XHTML, tj. principiálně lze dosáhnout jakéhokoliv obsahu, jež lze umístit na internetové stránky. Součástí tohoto modulu proto budou nástroje, pomocí kterých bude možné zmíněný datový obsah pohodlně upravovat a vytvářet. Uživatel systému bude mít současně možnost tento vlastní datový obsah podle svého uvážení buď neomezeně zveřejnit a nebo na něj kontrolovaně aplikovat přístupová práva, vycházející ze skupin a struktury uživatelů hlavního modulu systému. Integrace e-learningové aplikace se samotným systémem poskytne učitelům i administrátorům dokonale efektivní správu e-learningového obsahu. Požadavky na editační nástroj vlastního obsahu: Systém bude disponovat multimediálním WYSIWYG HTML editorem, pomocí kterého bude možné uživatelsky datový obsah vytvořit. Tento editor bude umět:
editovat prostý text formátovat text - velikosti a druhy písma, barvy písma, základní řezy apod. vkládat do textu tabulky a formátovat je vkládat do dokumentu obrázky minimálně základních formátů JPG, GIF a PNG a následně měnit jejich velikost, nastavovat u nich obtékání, zarovnání a zarovnání a pozici vůči textu vkládat do dokumentu přímo ze serveru uložené videosekvence formátů mp4, wmv, avi a tyto následně streamovat v rámci článku, vytvořeného editorem. Přičemž rozměry výřezu videosekvence by měly být nastavitelné přímo v editoru a zároveň bude možné použít celoobrazovkový mód. U takto vložených videí bude kromě streamování zajištěna i ochrana proti nelegálnímu kopírování (stahování) viz sekce upřesnění specifikace pro vkládání videa. vkládat do dokumentu přímo ze serveru uložené audionahrávky formátů mp3, wma, wav a tyto následně streamovat v rámci článku, vytvořeného editorem. Přičemž přehrávačem zde bude z uživatelského hlediska lišta podobná liště pro přehrávání videa bez náhledová okna pro zobrazení videa. vkládat do dokumentu hypertextové odkazy na externí stránky vkládat do dokumentu hypertextové odkazy na interní kapitoly ostatních částí téhož obsahu vkládat do dokumentu hypertextové odkazy na interní soubory ke stažení vkládat do dokumentu přímo na serveru uložené soubory formou tzv. živých náhledů. Živým náhledem se rozumí takové formy náhledu či prohlížečky obsahu, ve které se přímo na webové stránce uživateli zobrazí obsah souboru a uživatel si tak pro prohlédnutí souboru nemusí soubor stáhnout. Živé náhledy se týkají dokumentů ve formátech PDF a DOC. Systém musí data z těchto formátů v rámci
26 / 33
interních procedur takto převést do formátu čitelném a zobrazitelném v prohlížečce přímo z webové stránky. vkládat do dokumentu objekty typu Flash (zejména swf), pokud tyto nebudou vyžadovat napojení na související vstupní/výstupní data (typicky aktivní banner interagující na akci myši uživatele, bez dalších vstupů/výstupů).
Upřesnění specifikace pro vkládání videa: Systém bude jako jeden z typů datového obsahu umožňovat vkládat a následně přehrávat (streamovat) videosekvence formátů mp4, wmv a avi. Z pohledu videosekvencí systém bude umět: a) vkládat do systému videosekvence ve formátech minimálně mp4, wmv a avi. b) plnohodnotně streamovat vložené videosekvence směrem k příjemci obsahu, a to tak, že stream bude umět: i. Seekování, tj. dynamický posun klepnutím myší na jakoukoliv část v posuvníku označujícím délku videa, a to bez předchozího čekání uživatele na načtení celého videa. Nepřípustná je varianta, kdy je video uloženo na serveru ve formě souboru a přehrávač se po klepnutí na něj uživatelem "pouze" odkáže a začne video načítat od začátku bez možnosti skutečného streamingu. ii. Multibitrate, tj. každé video bude po uložení přepočítáno v minimálně třech kvalitách komprese (např. úrovních rozlišení) pro nejméně tři potenciální rychlosti linky koncového uživatele. iii. Multibitrate bude dynamický. Dynamickým bitratem se rozumí skutečnost, že systém sám bude kontrolovat rychlost linky uživatele a podle toho mu optimalizuje a pošle odpovídající kvalitu daného videa, s tím, že změnu kvality videa bude měnit průběžně s kolísající úrovní linky i v průběhu přehrávání. iv. Možnost přepnutí zobrazení videa do celoobrazovkového režimu a zpět, a to i v průběhu přehrávání v. Možnost regulace hlasitosti běžným posuvníkem. c) video bude chráněno proti neoprávněnému stažení na straně klienta. K ochraně bude použit dle volby uchazeče buď externě zakoupený k tomu určený serverový nástroj, jež bude součástí dodávky včetně veškerého potřebného příslušenství a souvisejících služeb, a nebo uchazečem vlastní vyvinutý nástroj splňující tuto podmínku. Princip zabezpečení bude řešen tak, aby video nebylo možné stáhnout nástroji pro detekci fyzického zdroje (URL adresy) videa a provést tak jeho následné stažení. d) celý systém bude navržen tak, aby byl zobrazitelný ve webovém prohlížeči, povolena je podmínka pro uživatele v instalaci Flash přehrávače e) celý systém bude navržen tak, aby byl dimenzován na streamování 500 současně spuštěných videí ze strany zákazníka POZOR! Zadavatel upozorňuje na striktní požadavek, že veškerá externí vložená média, tj. obrázky, video, hudba apod. vložená do systému přes uživatelské rozhraní, nebudou odkazovat na externí datová úložiště (např. youtube.com apod.), ale budou integrovány uvnitř systému. Tzn. uchazeč kompletně řeší problematiku ukládání multimediálního 27 / 33
obsahu, streamování audia a videa včetně veškerých souvisejících služeb a technologií a to včetně případných technologií třetích stran. Pokud přitom bude nutné zakoupit technologii třetí strany, je cena za nákup této technologie zahrnuta v ceně zakázky. V rámci nástroje pro tvorbu multimediálního datového obsahu bude i tzv. správce stromové struktury, pomocí kterého bude možné vytvářet kapitoly (složky) a podkapitoly (konečné multimediální objekty) datového obsahu. Tento nástroj bude umožňovat:
Dynamicky vytvářet z webového uživatelského rozhraní složku s minimálním počtem 10 podsložek a teoreticky neomezeným počtem koncových objektů multimediálního charakteru v každé složce Vytvářet koncové objekty (nosiče obsahu) Bude mít schopnost přesouvat mezi sebou v rámci stromu koncové objekty (v rámci vytvořených složek a podsložek), a to metodou drag and drop pomocí myši. Tato funkce bude vytvořena v rámci webového rozhraní (ideálně vytvořená v Javascriptu).
16.2. Testování Součástí modulu výuky je submodul pro vytváření a provádění testů. Princip modulu je založen na tom, že uživatel typu učitel vytvoří test, zadá ho definované skupině uživatelů typu žák a ti jej zpracují. Vyplněný výsledek testu se vrátí učiteli k hodnocení. Test je buď automaticky, poloautomaticky nebo zcela manuálně vyhodnocen a hodnocení je následně přeneseno do modulu hodnocení. Vytvoření testu Nástroj pro uživatelské vytváření testu bude umožňovat jednu otázku po druhé postupně vytvářet a zařadit ji do jednoho testu jako celku. Systém pro tvorbu testů bude umět pracovat s těmito typy otázek:
uzavřené otázky, otevřené otázky, otázky výběrové s jednou možností odpovědi, otázky výběrové s X možností odpovědi, doplňovačky, poziční grafické otázky s možností odpovědi klepnutím na pozici v obrázku.
V submodulu testů budou platit tato pravidla a podmínky:
V rámci jednoho testu lze libovolně kombinovat typy otázek. Při zadávání (vytváření otázek) bude u uzavřených nebo jednoznačně zodpověditelných otázkách možné zadat i správnou odpověď pro potřeby automatického hodnocení. Při zadávání (vytváření otázek) bude u všech otázek možné zadat: o počet bodů za správně zodpovězenou otázku
28 / 33
o počet bodů (i záporných) za špatně zodpovězenou otázku o počet bodů za nezodpovězenou otázku Pro test jako celek bude možné vytvořit bodovou hodnotící tabulku, kde v jednom sloupci budou definovány bodové rozsahy, a v dalším sloupci bude každému bodovému rozsahu definováno odpovídající hodnocení. Tato hodnotící tabulka bude sloužit pro automatické vyhodnocení testu. Jeden test může mít libovolný počet otázek. Každý test může být časově omezen. V případě aplikace časového omezení bude zkoušenému viditelně odpočítáván čas zbývající do konce testu.
Na základě tvůrcem testu definovatelného algoritmu pak může proběhnout zcela automatické nebo poloautomatické vyhodnocení testu. Životní cyklus testu 1. Autor testu vytvoří test: a. Vytvoří otázky. b. Každé otázce se nadefinují správné odpovědi (ty samozřejmě testovaní neuvidí). c. Každé otázce se přiřadí počet bodů za správnou a špatnou odpověď. 2. Autor testu nastaví hodnotící tabulku - bodové rozsahy a hodnocení odpovídající každému bodovému rozsahu. 3. Autor testu nastaví další parametry testu. Tj. zda test bude časově omezen apod. 4. Autor testu zadá test vybrané skupině uživatelů (jednotlivcům, vybraným třídám, apod.). 5. Uživatelé (typicky žáci) vypracují test a odešlou jej k hodnocení. 6. Autor testu vidí seznam odevzdaných testů a může je hodnotit. 7. Hodnocení testu může proběhnout: a. Za předpokladu, že jsou všechny otázky uzavřené, tj. neexistuje žádná otevřená (tedy potenciálně sporná odpověď), automaticky dle nastavených bodových škal. b. Poloautomaticky, kdy část otázek, které je možné ohodnotit automaticky jsou ohodnoceny systémem a část otázek (zejména otevřené) jsou ohodnoceny manuálně - u každé jedné otázky je jim nastaveno zda jsou zodpovězeny dobře či špatně. Systém pak na základě dodatečného manuálního hodnocení každé jedné otázky sám vyhodnotí dle celkové bodové škály testu test jako celek. c. Zcela manuálně, kdy autor testu bez ohledu na bodové škály a bez ohledu na to zda test obsahuje automaticky hodnotitelné otázky, test jako celek ohodnotí manuálně bez vztahu k bodovým škalám. 8. Hodnocení je přeneseno do modulu hodnocení. 9. Vyhodnocený test má možnost vidět kdykoliv v budoucnu do okamžiku jeho smazání nejen autor testu, ale i testovaný, který jej zpracovával. Poznámka: po smazání testu je nutné zachovat všechny navazující souvztažnosti, zejména hodnocení, přenesené do modulu hodnocení.
29 / 33
17. Technické nástroje a interní funkcionalita Pro chod jednotlivých modulů systému bude nutné vytvořit řadu interních procedur, funkcionalit, submodulů, apod. Řada z nich plyne z popisu jednotlivých modulů. Souhrnně je popisujeme zde. Konektory do externích aplikací Konektory do externích aplikací se rozumí výstupy do formátů pro potřeby externích agend a modulů. Konkrétně se jedná o cca 5 exportů dle zadaných struktur do formátu souboru XML. Rozhraní pro platební brány Předmětem zakázky bude v souvislosti s dobíjením připravovaných služeb (jež nejsou součástí zakázky), implementace platebních bran třetích stran. Prostřednictvím platebních bran bude možné v ármci systému provádět výběr finančních prostředků na účet zadavatele elektronickou formou. Jedná se konkrétně o implementaci platební brány pro dva platební systém - PayPal a implementaci platební brány PayU. Technologické informace o implementaci jsou k dispozici na webových stránkách zmíněných poskytovatelů služeb. Systém bude umožňovat přijímat platby formou: a) offline - převodem z bankovního účtu b) online - platebními kartami VISA, EC/MC a dalšími online nástroji dle dispozic platebního operátora Platební brána musí v případě online platební metody v reálném čase (s ohledem na sekundové prodlevy platebních bran externích partnerů) vyhodnotit přijatou platbu a v návaznosti na to pak bezprostředně oprávněnému kupujícímu vydat požadovanou službu (min. verifikaci o provedení transakce). Konektory do SMS bran Součástí systému je zhotovení konektoru do SMS brány mobilního operátora. Tuto problematiku kompletně popisuje kapitola Komunikace, odstavec SMS komunikace. Správa licencí a interní administrační rozhraní Součástí systému bude subsystém pro správu licencí a jednoduché administrační rozhraní. Prostřednictvím tohoto systému bude možné mimo jiné:
sledovat, shromažďovat a odbavovat nákup licencí pro využívání systému od zákazníků, sledovat statistiky přihlášení uživatelů včetně různých pohledů sledovat statistiky využívanosti jednotlivých modulů mít možnost provádět základní správu základních parametrů uživatelů v rámci hotline pomoci (změna hesla uživatelům, odblokovat zablokované přihlášení apod.) + cca 10 dalších operací obdobného typu.
30 / 33
Vzhledem k tomu, že tento modul bude svými částmi prakticky nedílně inetgrován do jednotlivých výše zmíněných modulů, bude jeho přesná podoba dojednána s vítězným uchazečem v průběhu realizace zakázky. Tento modul nebude obsahovat další procedury nad rámec popsané funkcionality.
18. Grafika systému Součástí zakázky bude vytvoření grafiky a grafického rozhraní dodavatelem projektu a jeho klíčových profilových stránek, ze kterých pak bude grafika multiplikovaná s ohledem na související vazby na sekundární stránky. Dodavatel přitom vyjde ze základní grafické studie, kterou předá dodavateli k dispozici. Grafika bude při plnění zakázky po předložení návrhu odsouhlasena zadavatelem. Dodávka grafiky systému a grafických prací je součástí ceny dodávky. Zadavatel nepožaduje, aby grafika nebo její náhled byl dodán už do výběrového řízení, nicméně uchazeč bude s grafickými pracemi ve své kalkulaci počítat v orientačním rozsahu cca 200 hodin. Díky současné penetraci dostatečně rychlého připojení k internetu je možné využít moderní grafické prvky s nižší mírou důrazu na datovou náročnost za každou cenu. Grafika a vůbec rozložení ovládacích prvků musí být provedeno s ohledem na moderní trendy a pravidla uživatelské přístupnosti. Důraz bude rovněž kladen na metodu práce přímo s objekty. Systém zavede ve větší míře metodu přístupu k datům a práci s jednotlivými datovými prvky jako s přímými objekty. Například práce s uživatelem nebude vyžadovat například klepnutí na nabídku Administrace - dále na nabídku Uživatelé a dále na nabídku Vlastnosti uživatele, ale přímo ve výpisu a seznamu uživatelů budou operační tlačítka u každého uživatele, která umožní veškerou práci s daným objektem - intuitivně. Tyto a další moderní metody budou prolínat celým systémem.
19. Provozní kapacity a parametry systému Z pohledu navržené architektury, rozložení databází apod. bude systém připraven na tuto zátěž:
2 000 uživatelů přihlášených současně 80 SQL dotazů za vteřinu Hraniční maximální odezva na dotaz: 3 sec. Předpokládaná velikost databáze: 400 GB
Pozor. Součástí dodávky není hardwarové řešení. Celý systém musí být navržen tak, aby byl implementovatelný na existujícím hardwarovém řešení zadavatele. Z uvedeného je zřejmé a zadavatel si uvědomuje, že výkonové hodnoty ovlivňuje mimo jiné do určité míry i výkon hardwaru zadavatele a tedy že odpovědnost za překročení mezních hodnot nelze absolutně přenést na dodavatele. Nicméně návrh struktury databází a návrh SQL dotazů včetně indexace výrazně ovlivňuje rychlost zpracování dotazů. Podle interního auditu zadavatele lze veškeré výše uvedené moduly vyvinout tak, aby při správné optimalizaci kódu byly tyto hodnoty spolehlivě dodrženy na uváděném disponibilním hardwaru zadavatele.
31 / 33
Hardwarové parametry a vyhrazené kapacity zadavatele pro tento projekt jsou následující (bez jakékoliv redundance, bere se k dispozici 100% uváděných kapacity):
Servery HP ProLiant Procesory k dispozici: 18 jader AMD Opteron 6174 2,2 GHz / jádro 32 GB RAM pro celou farmu Disková kapacita 2,5 TB storage HDD SAS 15 000 ot. Vysokorychlostní konektivita do internetu, port. 1Gbps
Servery jsou technicky k dispozici v rámci jednoho výkonového celku ve virtualizované podobě prostřednictvím nástroje VMWARE. Tj. rozdělení výkonových kapacit a přesné nastavení hardwarových zdrojů na jednotlivé služby systému či případně na virtuální servery, lze pohodlně provést na SW úrovni dle požadavků dodavatele s ohledem na možnosti zadavatele. Zadavatel poskytuje pro řešení zakázky, zejména s ohledem na nastavení serverů, součinnost svých odborných pracovníků.
20. Vymezení rozsahu této technické specifikace Tato technická specifikace slouží pro vymezení rozsahu zakázky zadavatelem a pro získání představy uchazeče o objemu a rozsahu zakázky a jejich jednotlivých částech. Každý jednotlivý modul a část zakázky bude vítěznému uchazeči technicky dále detailněji upřesněna. Uchazeč v důsledku detailního technického upřesnění nemusí očekávat zásadní změnu náročnosti jednotlivých částí zakázky v žádném směru.
21. Předmětem zakázky není Předmětem zakázky a součástí dodávky není:
dodávka hardwaru a hardwarových technologií dodávka zálohovacích systémů databází a diskových polí konektivita serverů k internetu, umístění serverů v housingovém centru
22. Rozsah, úroveň a intenzita poskytovaných služeb, a záruky Veškeré specifikace úrovně a rozsahu poskytovaných služeb definuje Smlouva o dílo, jež je přílohou Zadávací dokumentace.
23. Ceník služeb dodavatele Uchazeč poskytne či uvede kopii ceníku svých služeb. Jedná se zejména o:
32 / 33
Cenu za jednu hodinu či jinou jednotkovou cenu dle zvyklostí uchazeče, práce programátora na systému nad rámec této zakázky Cenu za jednu hodinu či jinou jednotkovou cenu dle zvyklostí uchazeče, technické či implementační podpory na systému nad rámec této zakázky Cenu za jednu hodinu či jinou jednotkovou cenu dle zvyklostí uchazeče, grafika a grafických prací nad rámec této zakázky
24. Dodávka díla Finální verze díla bude dodána v elektronické podobě následovně.
Od všech původních autorských součástí díla budou dodány kompletní zdrojové kódy, včetně všech souvisejících knihoven, modulů, navazujících modulů a softwarů. Od všech nepůvodních, externích či subdodávkou pořízených hotových softwarových prvků budou dodány licenční oprávnění nebo licenční listy, opravňující zadavatele nakládat a legálně užívat tyto části softwaru trvale bez omezení času. Od všech původních autorských součástí díla budou dodány kompletní dokumentace na úrovni dokumentace programátora kódu. Tuto podmínku lze částečně splnit dodávkou dostatečně okomentovaného kódu přímo uvnitř kódu tak, aby zadavatel zdrojovému kódu mohl bezpochyby porozumět a zorientovat se v něm. Dílo bude v rámci dodávky dodavatelem nainstalováno a zprovozněno na hardware dodavatele v místě serverovny dodavatele (Prostějov, Brno).
25. Vyplnění technického popisu Jedním z hodnotících kritérií zakázky je kvalitativní posouzení technického řešení nabídky. Uchazeč za tímto účelem dodá vyplněný dokument "Technický popis - část A)" jež tvoří přílohu zadávací dokumentace.
33 / 33
