INFORMAN SYSTM KOLN INFORMAN SYSTMY DEFINICE koln informan

INFORMAČNÍ SYSTÉM ŠKOLNÍ INFORMAČNÍ SYSTÉMY

DEFINICE • Školní informační systém je soubor lidí, metod a technických prostředků, zajišťujících sběr, uchování, analýzu a prezentaci dat určených pro poskytování informací v oblasti vzdělávání. • Umožňují výrazně zefektivnit fungování celé vzdělávací instituce. • V současnosti se již nejedná o izolované aplikace, ale o robustní a komplexní (modulární) systémy, které jsou navzájem kompatibilní.

POŽADAVKY • Školní informační systém by měl současně zahrnovat evidenci žáků (tzv. školní matrika) a zaměstnanců, evidenci klasifikace, tisk vysvědčení a třídních výkazů, grafické zpracování prospěchu, přípravu úvazků, sestavení rozvrhu hodin, plánování akcí školy, suplování, inventarizaci majetku, rozpočet školy, evidenci knih v knihovně a jejich půjčování, tvorbu tematických plánů atd.

OBECNÉ SCHÉMA

MOŽNÁ ROZDĚLENÍ

NAJDĚTE A ODPOVĚZTE Modulární uspořádání systému – v čem spočívá jeho výhoda? Nabídka Školních IS … Open Source? ? Nejčastější Moduly …

VÁŠ SAMOSTATNÝ ÚKOL • Porovnejte nabídku aspoň 4 vybraných školních IS a navrhněte dle Vašich preferencí ten nejvýhodnější. • Nabídku zpracujte vizuálně, např. pomocí Power. Pointu. • Bude obsahovat stanovená kritéria srovnání – např. Porovnání cen, modulů, požadavků na HW, podporu atd. • Výsledek mi zašlete na email: jan. kubricky@upol. cz do 10. 3. 2021

DALŠÍ POKRAČOVÁNÍ • Další část prezentace je určena pro synchronní výuku a můžete ji nyní přeskočit…

PŘEDPOKLADY NÁVRHU - VLASTNÍ ŠKOLNÍ IS • Aktuální stav, Potřeby, Možnosti • Technické zázemí • Investice • Životní cyklus informačního systému: • Plánování • Sběr a analýza požadavků • Návrh (včetně návrhu databáze) • Vytvoření prototypu • Implementace • Testování • Konverze a provozní údržba

ŽIVOTNÍ CYKLUS VÝVOJE INFORMAČNÍHO SYSTÉMU • Je složen z fází: • Plánování • Sběr a analýza požadavků • Návrh (včetně návrhu databáze) • Vytvoření prototypu • Implementace • Testování • Provozní údržba

PROJEKT • Zadavatelé (Stakeholders) • Vlastník produktu (Product Owner – PO) • Vývojový tým (Agile team) • Team leader • SCRUM master - SM

PLÁNOVÁNÍ • Začínáme definicí produktu (aplikace). • Přesouváme se k hlavním částem. • Vymezíme malé jednotlivé kroky, které proměníme v akce na nichž můžeme začít pracovat. • Řešení těchto akcí nám umožní vytvoření zadaného produktu.

DEFINOVÁNÍ CÍLŮ APLIKACE • Abychom mohli definovat cíle aplikace, budeme postupovat od obecných cílů zpět směrem ke konkrétním akcím, na kterých lze pracovat. • Na konci bychom měli mít seznam akcí, které můžeme podniknout, abychom zahájili cestu vytváření aplikace. Výchozí určení aplikace - např. : • Modul IS pro online testy

VÝCHOZÍ URČENÍ ROZDĚLÍME NA HLAVNÍ CÍLE • Spravovat testy • … • Notifikace uživateli • Zobrazit test uživateli • … • Vyhodnocovat testy • …

KONKRETIZACE HLAVNÍCH CÍLŮ NA KROKY • Abychom mohli přejít od plánování k návrhu je potřeba jednotlivé hlavní cíle udělat tzv. činitelné – tedy převést na malé kroky. • Hlavní cíl: Zobrazit test uživateli • Zobrazit název, popis, časovou dotaci • Zobrazit testové otázky a testové odpovědi • Zobrazit odpočet zbývajícího času

Vyjádření kroku jednou větou, formou KDO, CO a PROČ • KDO – pro koho story dělám STORY • CO – co je obsahem story • PROČ – proč story dělám • Příklad: Jako uživatel, chci mít možnost obnovit si heslo, protože ho po čase zapomenu. • Story je vhodné rozdělit po uživatelských vlastnostech na user story. • Po přečtení všech story, by si člověk měl udělat o produktu jasnou představu. • Story pointy – hodnoty určující složitost story ve vzájemném porovnání. • Stupnice: • Číselné • Jiné: např. S, M, L, XL, …

EPIC STORY • Logické seskupení více story. • Více méně koresponduje s hlavními cíli, ale může vznikat i samostatně a následně se rozdělí na story. Příklad: • Zobrazení testu uživateli.

• Představují vývojové úkoly k dosažení jednotlivých story. • Obecně ne více než jednodenní úkoly. TASKY • Na základě tasků, můžeme vytvořit odhad času pro jednotlivé story. Příklad STORY: Jako uživatel, chci mít možnost obnovit si heslo, protože ho po čase zapomenu. • Tasky: • Design formuláře pro obnovení hesla. • Implementace do HTML a CSS. • Validace zadaného loginu/emailu. • Vyhledání uživatele podle loginu v databázi. • Zaslání hesla na email uživatele. • Ošetření chybových stavů. • Neexistující uživatel. • Nedoručení emailu. • Přesměrování na cílovou stránku.

BACKLOG • Jednorozměrný seřazený seznam všech story. • O každých dvou story lze říci, která má větší prioritu. • Story řadí PO na základě produktové priority, jejich ohodnocení a rychlosti týmu.

SPRINT (ITERACE) KRÁTKÝ ČASOVÝ ÚSEK, KDY TÝM PRACUJE NA STANOVENÉM MNOŽSTVÍ STORY A JEJICH TASKŮ.

• Společná aktivita celého týmu. • Výběr položek: PO – SM – Team. • 2 základní otázky: PLÁNOVÁNÍ SPRINTU 1. Jaká práce se vytvoří? 2. Jak bude práce označena za hotovou? • Stavy tasků: • Nevyřízen (To. Do) • Probíhá (In Progress) • Hotovo (Done) • Po dokončení sprintu probíhá předvedení výsledků zúčastněným. • Předem určená doba sprintu – např. týden.

SCRUMBOARD • Tabule s přehledem aktuální činnosti ve sprintu. • Řádek určuje story a obsahuje jednotlivé tasky. • Sloupec určuje stav. • Postupuje od prioritních story (ty nahoře) • Ideální varianta nástěnná tabule a sdílené aplikace.

VYTVOŘTE SI VÁŠ SCRUMBOARD • Váš team si sám vybere variantu podle preferencí. • Existují free online tools, zkuste najít ten Váš. • Například nástroj TRELLO.

SCHŮZKY Estimation – hrubé ohodnocení story Grooming – přesnější ohodnocení story Zavazování – naplánování story do sprintu Analýza – technické rozpracování nového sprintu Standup – každodenní informativní schůzka Review – předvedení novinek zákazníkovi Retrospektiva – zhodnocení spolupráce

ESTIMATION • Hrubé porovnání velkého balíku story. • Každé story jsou přiřazeny story pointy. • Jde o hrubý odhad, aby PO dostal představu o plánu. • Nepravidelná

GROOMING • Nejdůležitější schůzka procesu plánování. • PO přednese jednotlivé story. • Tým položí otázky k ujasnění zadání. • Pokud je nutné, tým na tomto základě tvoří user stories. • Pravidelná

ZAVAZOVÁNÍ A ANALÝZA • PO předkládá požadované story, které by chtěl v dalším sprintu vykonat. • Tým vyhodnocuje proveditelnost. • Vývojový tým (už bez PO) se domluví na technických detailech implementace. • Vývojový tým si rozdělí jednotlivé úlohy. • Začátek sprintu

• Každodenní schůzka k pravidelné informovanosti celého týmu. • Neměla by trvat dlouho a proto se stojí. STANDUP • Každý by měl: • Říct na čem pracoval od minulého standupu • Říct na čem bude pracovat nyní • Pokud má problém, požádat o pomoc • Pomoci ostatním, pokud mají problém

REVIEW • Předvedení nově implementovaných story zákazníkovi. • Předvádí se jen hotové story. • Tolerovány jsou jen drobné bugy. • Na konci sprintu

RETROSPEKTIVA • Nejdůležitější schůzka vzhledem k fungování týmu. • Prostor pro tým, aby si řekl: • Co se povedlo • Co by chtělo zlepšit • Na konci sprintu