Vývoj informačního systému

Co se naučíš:

• Na jaké části a fáze lze vývoj informačního systému rozdělit?
• Jak postupovat, abychom vytvářený informační systém také zdárně dokončili?
• Jaké zásady se při vývoji informačních systémů vyplatí dodržovat?

Návrh průběhu hodiny a metodické poznámky

• Stručný průběh a poznámky
• Podrobný plán (příprava do hodiny)

Je nejvyšší čas se uceleně podívat na vývoj informačního systému. To je obor sám o sobě, takže se opět seznámíme jen s jednoduchými základy. I ty nám ušetří mnoho zbytečné práce.

Formulace zadání

Prvotní nápad

Na začátku většinou stojí nějaký námět. Ten se potom dále upravuje a vyvíjí, někdy až k nepoznání. Přesto je užitečným prvním krokem tento prvotní námět konkretizovat.

Příklad: Náměty

• Systém na evidenci zakoupených výrobků. Pomůže členům rodiny rychle zjistit, jestli je daný výrobek ještě v záruce, a kde jej případně nechat opravit.
• Systém pro omlouvání z tréninku a sledování docházky. Trenér nechce pořád zvedat telefony s omluvami hráčů a pak ještě zpětně počítat, kdo vlastně kolikrát přišel.
• Systém na zalívání pokojových rostlin, protože Karel není s to si zapamatovat, kterou je třeba zalívat jak často a jak hodně.

Než se tedy pustíte do vývoje informačního systému, odpovězte si jednou větou na otázky: Pro koho bude systém určený? Jak má být svým uživatelům užitečný, jakou jim přináší hodnotu?

Odpovědi si napište. Dokud je máte jen v hlavě, hrozí, že sami vlastně nevíte, o co se snažíte. To se pak ale těžko podaří.

Zjišťování potřeb

Úloha: Nakreslete kačenku!

Tahle aktivita funguje nejlépe ve větší skupině. Jeden ze skupiny má rád dejme tomu kačenky. Ostatní utvoří čtveřice a kačenky mu budou kreslit. Za každou kačenku dostanou odměnu: jeden, tři nebo pět žetonů. Která čtveřice dostane za pět minut nejvíce žetonů?

Nápověda

Nezobrazujte řešení níže, pokud kačenky kreslíte. Pokud za ně odměňujete, na “řešení” se podívejte.

Řešení

Jak kačenky hodnotit? Podle sebe. Určete si nějaká jednoduchá kritéria a přiřaďte jim hodnotu. Můžete např. vyplatit jeden žeton za jakoukoliv kačenku, dva přidat, pokud je vícebarevná, a další dva, když je kačka na obrázku čelem (nikoliv z boku). Nebo třeba když je hranatá, nebo oblá, vybarvené, oblečená, v letu, s úsměvem… je to na vás.

Preference nesdělujte, ale hodnoťte je konzistentně. Snažte se je vybrat tak jednoduché, aby se vyplatilo dělat hodnotné kačenky spíše, než dělat hodně kačenek za jediný žeton.

Kdo dostal nejvíce žetonů? Proč? Jaký postup se osvědčil? Za jaké kačenky bylo nejvíc žetonů? Kolik se povedlo nakreslit kačenek za jeden, za tři a za pět žetonů?

Někdo se na požadovanou formu kačenek prostě zeptá. Někdo ji odhalí pečlivým systematickým zkoušením. Někdo kreslí spoustu kačenek za málo žetonů.

Poučení je ale jasné: než se pustím do práce, pečlivě ověřím, že dělám opravdu to, co se po mě chce. Ve škole je to trochu nezvyklé, přeci plníme zadání. V životě se ale ukáže, že takové doptávání ušetří spoustu práce. Ještě spolehlivější je pak kombinace doptávání s testováním prototypů řešení. To, co uživatelé tvrdí, že chtějí, bývá totiž něco jiného, než co chtějí doopravdy. A to je ještě něco jiného, než co potřebují. Není až tak prospěšné poslouchat klienta na slovo, lepší je mu porozumět.

Na začátku každého projektu je proto potřeba jít za cílovou skupinou (uživateli), mluvit s nimi, ptát se jich, a poslouchat odpovědi. Jestli výsledek našeho úsilí nebude uživatelům nic přinášet, nebudou ho používat.

Úloha: Rozhovory s uživateli

Vezměte hotový námět a zjistěte, jak by si uživatelé vašeho systému potřebnou pomoc představovali. Není to žádná záhada, běžte se jich prostě zeptat. Pro skutečný projekt byste začali aspoň s pěti, pro nácvik jich stačí méně.

Připravte si otázky jako:

• Jak situaci řešíš teď?
• Co se ti na tom systému líbí?
• Co se ti na tom systému nelíbí?
• Co je nejpracnější, nejotravnější, nejrizikovější (např. že by bylo nutno začít znovu)? Které znalosti a dovednosti jsou potřeba ve kterém kroku postupu?
• Jaké používáš alternativní možnosti? Co je na nich lepší, co horší?
• Kdybys mohl na současném systému cokoliv změnit, co by to bylo? (I kdyby to mělo být vylepšení magické - zde se ještě neomezujeme technickými možnostmi! Uživatel je často ani nezná.)
• Jak poznáš, že vše dopadlo dobře? Na čem to záleží?

Vaším úkolem není mluvit a vysvětlovat váš námět. Naopak. Pozorně poslouchejte a snažte se potřebám uživatelů porozumět. Během průzkumu si dělejte poznámky, nebo ještě lépe, pokud uživatelé souhlasí, rozhovory si nahrajte. Ideální samozřejmě je, když můžete uživatele v odpovídající situaci přímo sledovat.

Z poznámek potom vyplynou společné motivy, na jejichž základě můžeme pokračovat.

Už z dřívějška víme, že co uživatelé říkají, je nutno ověřovat. Můžeme jim např. popsat několik nápadů, které by pomohly jejich potřeby řešit. Z jejich reakcí teprve poznáme, jestli jejich potřebám opravdu správně rozumíme.

Soupis funkcí

Na základě popisu potřeb uživatelů následně sestavujeme seznam funkcí systému. Ideálně samozřejmě ve spolupráci s uživateli. Zajístíme tak, že opravdu vymýšlíme to, co je potřeba. Stále ještě se zbytečně neomezujeme technickými možnostmi. V téhle fázi ani nemusí být zřejmé, jestli vystačíme s nástěnkou, tabulkou sdílenou v cloudu, nebo bude třeba vyvinout nějakou mobilní aplikaci.

Příklad:

„Když se nám doma nějaká věc pokazí, jen těžko vzpomínáme, jestli je ještě v záruce, a ještě obtížněji hledáme doklad o koupi. Leckdy se pak o reklamaci ani nepokusíme.“ Jaké funkce by mohl mít informační systém, který by tohle pomáhal řešit?

• Přidat do evidence nově koupenou věc.
• Mít možnost zjistit ke každému výrobku datum nákupu.
• Snadno hledat výrobky v seznamu - např. podle názvu, kategorie, fotky.
• Přidat ke koupenému výrobku fotku účtenky, aby ji nebylo potřeba hledat. Nebo tam přidat poznámku, kde účtenka je.
• Přidat ke koupenému výrobku poznámku, když se záruční doba liší (např. když je prodloužená).
• Zobrazit výrobky, které již v záruce nejsou, a není tedy potřeba dále skladovat účtenky.
• ...napadnou vás další?

Prioritizace požadavků

Z počátečních úvah vzejde zpravidla velké množství nesourodých požadavků. Kdyby se měly realizovat všechny, vzalo by nám to nejspíš příliš mnoho času a úsilí. Jak se rozhodnout, které funkce opravdu implementovat? Potřebujeme zohlednit různá hlediska a nezamotat se do nich.

Může nám pomoci tzv. Impact Effort Matrix. Je to metoda dostatečně systematická, aby byla přínosem. Ale zároveň není zbytečně složitá. Myšlenka je prostá: při rozhodování o tom, které funkce či požadavky skutečně realizovat, zvažujeme přínos (dopad) funkce proti úsilí (a obecněji libovolným dalším prostředkům), které bude třeba vynaložit. Když každé položce na našem seznamu přiřadíme numerickou hodnotu dopadu a úsilí, dovolí nám to vytvořit graf, ve kterém už uvidíme, jak se co vyplatí.

Další variace a podrobnosti

• Dobře si rozmyslete rozsah číselných hodnot, které budete uvažovat. Typicky se využívají hodnoty 1-10. Přestože jsou hodnoty odhadované, orientační, ujasněte si přinejmenším, co znamená „úsilí 10“ a ostatní mezní hodnoty.
• Přesnější obrázek nejspíš získáte, když se na hodnocení přínosu a nákladů bude podílet více lidí. Pro vizualizaci potom použijete např. průměr všech hodnot.
• Cílem je dostat lepší náhled na priority požadavků. Nemá smysl metodu uplatňovat absolutně, a např. se nikdy nepouštět do ničeho obtížného. Nemá ale smysl se do toho poštět dřív, než si na prototypu ověříme, že vůbec jdeme správným směrem.
• Uvedená metoda má, jako každá, své limity. Dosáhnete lepších výsledků, když jim budete rozumět.

Jaký je tedy postup?

1. Na začátku máme seznam požadavků k implementaci.
2. Každému požadavku přiřadíme číselnou hodnotu, která reprezentuje přínos (čím větší přínos, tím větší hodnota).
3. Každému požadavku přiřadíme číselnou hodnotu, která reprezentuje náklady (čím větší náklady, tím větší hodnota).
4. Požadavky vyneseme do grafu jako body, jejichž souřadnice odpovídají zvoleným hodnotám přínosu a nákladů.
5. Jako první pro realizaci zvolíme vše s vysokým přínosem a nízkými náklady, naopak požadavky s vysokými náklady a zanedbatelným přínosem pokud možno neimplementujeme vůbec.

Úloha: Zalívání květin

Ohodnoťte následující seznam požadavků na podporu zalévání pokojových květin podle dopadu na uživatele (impact) a potřebného úsilí (effort). Toto hodnocení potom použijte k rozhodnutí, které požadavky byste implementovali jako první.

	Požadavek	Přínos (1-10)	Úsilí (1-10)
1	Zobrazit, kdy je potřeba zalévat příště
2	Upozornit ráno, že daný den je potřeba zalívat	8	4
3	Zobrazit, které květiny je potřeba daný den zalít	8	5
4	Minimalizovat počet zalívání - když se dvě rostliny zalívají jen den od sebe, ať se zalívají společně
5	Zobrazit umístění rostlin k zalití	6	6
6	Evidovat, které rostliny byly právě zality
7	Zobrazit obrázek rostlin, abychom je při zalívání rozpoznali
8	Zabránit přelití dané rostliny	9	10
9	Zobrazit spotřebu vody za dané časové období	3	9
10	Přidat do systému novou rostlinu
11	Odebrat rostlinu ze systému
12	Změnit libovolná data k dané rostlině
13	Připomenout, že je potřeba naplnit konev, aby voda měla čas odstát	3	3

Ukázka možného umístění několika požadavků:

Berte v úvahu, že stejný požadavek je pro různé uživatele různě přínosný. Podobně pro různé tvůrce může stejný požadavek vyžadovat různé úsilí. Není tedy jedno správné řešení.

Výsledný seznam požadavků určuje, co bude náš systém umět. Ještě nevíme, jak to bude vypadat, ani jak to bude fungovat. Nejspíše existují různá řešení. Pokud ale splňují seznam požadavků, měla by všechna dělat totéž (byť třeba každé jiným způsobem).

Když už víme, co přesně má systém dělat (a proč), můžeme se pustit do rozmýšlení, jak na to.

Návrh

Teprve když víme proč něco vyrábíme a co to má umět, pouštíme se do dalších detailů. Děláme to předtím, než se pustíme do samotné realizace. Chceme mít totiž předem promyšlené, co vlastně budeme realizovat. I toto přemýšlení přitom můžeme strukturovat do menších celků. Vzájemně souvisí, ale je snazší o nich přemýšlet zvlášť.

Nejsrozumitelnější je uživatelské rozhraní. Tedy jak systém vypadá, jak s ním uživatelé pracují.

To je tedy systém „zvenku“.

„Vnitřní“ fungování můžeme rozlišit na dvě velké oblasti. Procesy popisují, jak v systému probíhají jednotlivé úkony (ať už vyvolané automaticky, nebo uživatelem - ty pak samozřejmě souvisí i s uživatelským rozhraním). Datový model pak popisuje samotná data: která vůbec systém ukládá, v jaké podobě, jaká pro ně platí pravidla a jak spolu souvisí. Všimněte si, jak v průběhu práce na systému pokrýváme všechny jeho součásti, jak jsme je už dříve identifikovali: data a jejich strukturu, procesy, uživatele - a když to máme promyšlené, můžeme se vrhnout na technickou realizaci.

Návrh uživatelského rozhraní

Jak bude váš systém vypadat? Jak jej budou uživatelé používat? Návrh uživatelského rozhraní úzce souvisí s použitelností. Myslete na to, že rozhraní není pro vás, ale pro uživatele. Připomeňte si proto, kdo vaši uživatelé jsou. Jaké mají zkušenosti s podobnými systémy a vůbec s technologiemi, jak jsou zvyklí pracovat, jakým se dorozumívají jazykem, jak rádi a snadno se učí nové věci? Jak jsou staří, v jakém žijí prostředí a podmínkách? Odpovědi na tyto otázky napoví, jaké uživatelské rozhraní navrhnout.

Stejně jako jinde, i zde platí, že první myšlenka nebývá nejlepší. Nestačí proto načrtnout jeden návrh, a ten potom implementovat. Lepších výsledků dosáhnete, když návrhů připravíte několik a prozkoumáte tak různé možnosti. Většinu zavrhnete možná ještě dřív, než je ukážete uživatelům. Prací na několika návrzích ale zvyšujete šanci, že mezi nimi bude aspoň jeden opravdu dobrý.

Přitom není nutné návrhy hned realizovat na počítači. Mnohdy opravdu stačí hrubé náčrtky na papír. I na těch už totiž lze zkoušet, nakolik jsou pro uživatele srozumitelné a použitelné. Podstatné je, aby byly návrhy a později prototypy uvěřitelné. Nemusí mít zdaleka všechny funkce hotového systému. Slouží k potvrzení, že jsme na správné cestě. Čím rychleji jsou návrhy či prototypy hotové, tím častěji je můžeme testovat, a tím spíše zůstaneme na správné cestě.

Úloha: Návrh rozhraní (evidence výpůjček)

Navrhnetě rozhraní pro systém na evidenci výpůjček. Má umožnit:

• Doplnit novou výpůjčku.
• Zaznamenat vrácení.
• Zobrazit všechny dosud nevrácené výpůjčky.
• Zobrazit všechny výpůjčky vybraného člověka.
• Zobrazit seznam lidí, kteří mají zpožděné výpůjčky, spolu s jejich kontaktními informacemi.

Data jsou uložena ve dvou tabulkách. V tabulce lidí jsou jména a kontaktní e-mail a telefon. V tabulce výpůjček je uvedeno:

• kdo si půjčil,
• co si půjčil,
• kdy si to půjčil,
• kdy to slíbil vrátit,
• kdy to opravdu vrátil.

Nová výpůjčka se zadává jako nový řádek tabulky. Musí existovat daný člověk, pokud není, je nutno ho nejprve do tabulky lidí zavést. Vrácení výpůjčky se realizuje doplněním data vrácení na řádek příslušné výpůjčky.

Návrh vnitřní logiky

Konečně se dostáváme k tomu, co informatiky často baví nejvíc: jak systém funguje uvnitř.

Příklad: Datový model pro evidenci zboží v záruce

Jaké údaje musí systém ukládat?

Zvažujeme, které potřebujeme nutně (ty ostatní pokud možno nesbíráme, uživatele to obtěžuje).

Potřebujeme datum nákupu? Na první pohled ano (nepotřebujeme ale přesný čas). Jak jej využijeme? Určíme podle něj, kdy záruka vyprší. Kromě případů prodloužené (nebo zkrácené) záruky. Možná tedy bude lepší evidovat ke každému zboží datum, kdy záruka vyprší.

Obdobnými úvahami shromáždíme postupně seznam všech zpracovávaných dat, jejich typů (texty, čísla, datumy...) a využití.

Když si nejsme jisti, můžeme fungování systému nasimulovat na papíře. Rychle se ukáže, jestli nám nějaká data nechybí.

Příklad výsledného seznamu:

# Název výrobku (typ dat: text)

1. Popis výrobku (text)
2. Fotka (obrázek)
3. Prodejce (text)
4. Datum vypršení záruky (datum)
5. Kontakt na prodejce, reklamační oddělení nebo servis (text)

Jak data rozdělit do tabulek?

Jednotlivé položky z předchozího koku budou typicky odpovídat sloupcům tabulky.

Řádky jsou skupinou hodnot, které reprezentují jeden konkrétní objekt. V jednoduchých případech řádky přímo odpovídají fyzickým objektům - lidem, zboží... Někdy jsou abstraktnější, a zachycují např. výpůjčky knih, objednávky, lajky.

Podstatná je zásada, že se struktura tabulek nemá měnit v důsledku běžného provozu systému. Nebudeme přidávat sloupce (natož tabulky), když přibude nový prodejce. Tabulky proto musí fungovat obecně. Když může něco přibýt (prodejce, zboží, přátelství na sociální síti...), měl by to být řádek tabulky.

V našem případě můžeme uvažovat tabulku výrobků a tabulku obchodů.

Jak tabulky propojit?

Tabulky v informačním systému zpravidla vzájemně souvisí.

Jejich provázáním předcházíme chybám, šetříme data a zpříjemňujeme si celou práci. Jednotlivé výrobky jsme koupili v různých obchodech. Jeden obchod má ale stále stejné kontaktní údaje. Nemá smysl je vypisovat ke každému výrobku zvlášť. Každý výrobek tedy bude mít záznam o tom, ze kterého je obchodu, a v tabulce obchodů v případě potřeby dohledáme další detaily k obchodu. Kromě propojení můžeme definovat další pravidla. Např. ukončení záruky by mělo být v budoucnosti. Systém pak může dodržení pravidel kontrolovat a předcházet tak dalším chybám.

Výsledek fáze návrhu je popis vnitřního fungování systému. Zejména u větších systémů, na kterých pracují celé týmy, musí být návrh velmi detailní. Mohou jej dostat k realizaci zcela jiní lidé (což je běžné - někdo dobře vymýšlí, někdo dotahuje, byla by škoda to nevyužít). Podle dobrého popisu ale vyvinou systém, který funguje zcela stejně.

Implementace

S hotovým návrhem se konečně můžeme pustit do tvorby systému jako takového. Soustavně při tom sledujeme zadání, abychom se od něj neodchýlili.

I implementace probíhá krok za krokem. To dává příležitost mezi jednotlivými kroky průběžně testovat.

Také už z fáze návrhu víte, že lze systém rozdělit na logické celky. Podle nich můžete rozdělit i práci na implementaci a zvlášť vyvíjet vnitřní logiku fongování, uživatelské rozhraní a vkládat samotná data.

Pro implementaci existují různě propracované metody, např. ze softwarového inženýrství. Jedna z nich využívá práci ve dvojici. Jeden pracuje s myší a klávesnicí, a druhý jej přitom rovnou kontroluje. Uhodnete, proč se takový přístup může vyplatit?

Úloha: Implementace struktury dat (evidence výpůjček)

Jednou ze vstupních informací pro implementaci je popis struktury dat. Naučte se podle podobných popisů vytvářet tabulky. Následující příklad je jednoduchý, jen se dvěma tabulkami. Není ani nutno kreslit nějaké schéma. Slouží ke sledování informací o tom, kdo si co vypůjčil. Systémy, které běžně používáte, mohou mít vzájemně provázaných tabulek desítky.

V tabulce Kontakty jsou:

1. Jméno (text),
2. E-mail (text),
3. Telefon (text).

V tabulce Výpůjčky je uvedeno:

1. Kdo: kdo si věc půjčil (jméno z tabulky s lidmi; předpokládá se, že jsou jména jedinečná),
2. Co: co si půjčil (text),
3. Půjčeno: kdy si to půjčil (datum),
4. Vrátí: kdy to slíbil vrátit (datum),
5. Vráceno: kdy to opravdu vrátil (datum nebo prázdná hodnota, pokud to ještě nevrátil).

Každá výpůjčka se zaznamená do nového řádku v tabulce Výpůjčky. Pokud si někdo půjčuje poprvé, uložíme si jeho kontaktní údaje do tabulky Kontakty. Vrácení se zaznamená vyplněním datumu do sloupce Vráceno. Přehled nevrácených půjček získáme filtrováním výpůjček s prázdnou hodnotou ve sloupci Vráceno. Z nich můžeme dále vyfiltrovat ty, které jsou zpožděné (datum ve sloupci Vrátí je už v minulosti).

Úloha: Implementace rozhraní (správce úkolů)

Jako příklad můžete zkusit implementovat jednoduchého rozhraní podle návrhu. Jde o správce úkolů na týmovém projektu. Je založen na jedné tabulce, která ale umožňuje různá zobrazení. Ta budou v oddělených sekcích:

• Sekce Nejbližší úkoly zobrazuje úkoly, jejichž termín je v příštích 7 dnech a nejsou hotové.
  • Zobrazuje všechny sloupce tabulky.
  • Úkoly řadí podle termínu (od nejbližšího).
  • Oranžově označuje úkoly, které jsou hotové z 25 {%} nebo méně.
  • Červeně označuje úkoly zpožděné.
  • Sloupec stav dokončení umožňuje nastavit posuvníkem hodnotu od 1 do 100.
• Kalendář zobrazuje termíny úkolů v kalendáři na jednotlivé měsíce.
• Úkoly podle lidí zobrazuje úkoly seskupené podle toho, kdo je má splnit.
  • Zobrazuje navíc sloupec s počtem zbývajících dnů do daného termínu.

Vyjděte z pracovní verze, která již obsahuje správně strukturovaná data.

Pravděpodobně zjistíte, že popis rozhraní není úplný. Co dalšího by bylo potřeba specifikovat?

Závěr

Výše popsanými fázemi práce nekončí. Systém je potřeba nasadit do provozu, udržovat jej, ladit a postupně dále vyvíjet (nebo časem nahradit dalším). Potřeby uživatelů se totiž vyvíjí.

Pro praxi také mějte na paměti, že jsme zde popsali vývojové fáze zjednodušené a idealizované. Ve skutečnosti se samozřejmě neubráníte přemýšlení „napřed“. Většina si např. uživatelské rozhraní budoucího systému představí dřív, než jsou vůbec známy a zpracovány potřeby uživatelů. Co hůř, někdy se ukáží přehlédnutí a chyby v již ukončených fázích, a pak je třeba se do nich i opakovaně vracet. Některé tyto potíže řeší pokročilejší vývojové metodiky systémového a softwarového inženýrství. I takto zjednodušené vývojové fáze nám ale pomáhají udržet si přehled o tom, na čem zrovna pracujeme, a vyhnout se tak mnoha příležitostem ke zbytečné práci. Přesnější vymezení dílčích úkolů také usnadní rozdělení úkolů a tím i spolupráci v týmu.

Shrnutí

• Postup tvorby informačního systému je vhodné předem naplánovat. Můžeme jej rozdělit např. na fáze:

• • zjišťování potřeb uživatelů,
  • rozhodnutí, co má řešení umět,
  • návrh
    • uživatelského rozhraní (jak to bude vypadat, jak se to bude chovat),
    • procesů (jakým postupem budou data zpracovávána),
    • datového modelu (jaká data se budou ukládat, v jaké struktuře),
  • implementace všech částí.
• Během vývoje nezapomínáme s pomocí uživatelů průběžně ověřovat, že jsme na správné cestě.