Jihočeská univerzita v Českých Budějovicích Přírodovědecká fakulta Ústav aplikované informatiky
Databáze kontaktů s klienty – TyfloData Závěrečná zpráva – IS projekt (UAI/601)
Bc. Tomáš Průcha Bc. Eva Adámková Bc. Vojtěch Novotný
České Budějovice 2015
Obsah 1
Zadání IS projektu ............................................................................................................... 3
2
Hardware a Software ........................................................................................................... 5
3
Model a databáze................................................................................................................. 5
4
Frontend .............................................................................................................................. 8 4.1
Menu ............................................................................................................................ 9
4.2
Intervence .................................................................................................................. 10
4.3
Klient ......................................................................................................................... 12
4.4
Restringovaná participace, pozice, služby ................................................................. 12
4.5
Přihlašovací údaje ...................................................................................................... 13
5
Backend ............................................................................................................................. 13 5.1
Vývoj ......................................................................................................................... 13
5.2
Testování.................................................................................................................... 14
5.3
Nástroje použité pro vývoj......................................................................................... 14
6
Změny oproti původnímu zadání ...................................................................................... 15
7
Dokumentace..................................................................................................................... 15
8
Testování a problémy ........................................................................................................ 15
9
Možná vylepšení do budoucna .......................................................................................... 16
10
Závěr .............................................................................................................................. 16
11
Přílohy ........................................................................................................................... 17
11.1
Uživatelská dokumentace .......................................................................................... 17
11.2
Feedback .................................................................................................................... 21
2
1 1) Název projektu Databáze kontaktů s uživateli - TyfloData 2) Složení řešitelského týmu Bc. Tomáš Průcha, Bc. Eva Adámková, Bc. Vojtěch Novotný 3) Projekt řešen pro společnost Tyflokabinet České Budějovice, o.p.s. Roudenská 485/18, České Budějovice 7, 370 01 4) Vymezení rolí v týmu Bc. Tomáš Průcha – kontakt se zadavatelem, nasazení LAMP u zadavatele, návrh databáze Bc. Eva Adámková – grafika, dokumentace Bc. Vojtěch Novotný – aplikační logika 5) Formulace problému V současné době je řešena „databáze“ uživatelů ve společnosti Tyflokabinet o.p.s. Excelovskou tabulkou, kterou spravuje pouze ředitel společnosti. Nyní je potřeba nahradit současné řešení víceuživatelskou databází. 6) Cíle projektu Cílem projektu je nahradit jednouživatelskou tabulku víceuživatelskou databází typu klientserver. Databáze musí splňovat všechny možnosti tabulky, tedy vkládání/mazání/úpravu/výpis uživatelů, zaměstnanců, služeb a intervencí. Vlastnosti aplikace: - použitelnost uživateli se zrakovou vadou - dle města nabídnout odpovídající PSČ - přepínač, který určuje, zda je vedena i složka s písemnou dokumentací - při přidávání nového klienta zkontrolovat duplicity jmen a vypsat identifikační číslo klienta - export zobrazených dat - USR log - u intervencí nabízet aktuální datum v kalendáři - reporty (co, kdy, kdo, s kým, jak dlouho,…) 7) Časový harmonogram prací - Začátek prací říjen 2014 - Nasazení aplikace v průběhu roku 2015 - Prezentace LS 2015 3
8) Předpokládané (či již použité) technologie Linux (Debian), Apache, MySQL, PHP, HTML, CSS, JavaScript 9) Prezentace a obhajoba LS 2015
4
2 Hostitelský počítač byl složen z vyřazených počítačů zákazníka v konfigurace 80 GB pevný disk, 1 GB RAM, procesor AMD, 2-jádrový o frekvenci 1,2 GHz. Tato nepříliš výkonná sestava je dostatečná pro použité softwarové vybavení. Veškerý nasazený software je volně licencován a zcela zdarma. Operační systém byl po diskuzi zvolen Debian verze 8 stable s grafickým rozhraním KDE. Webový server byl nainstalován Apache verze 2, databázový server MySQL verze 5 a PHP také ve verzi 5. Dále pro usnadnění práce s databází byla nainstalována aplikace phpMyAdmin. Za účelem testování byly doinstalovány webové prohlížeče. K defaultnímu prohlížeči Konqueror přibily Iceweasel (Firefox) a Chromium (Chrome). Na závěr pak nástroj pro ověření, že aplikace je použitelná nevidomými uživateli, NonVisual Desktop Access (NVDA). Na osobních počítačích s Windows byly pro tyto účely použity nástroje JAWS a licencované screen readery. Databázový server a aplikace phpMyAdmin zároveň slouží k monitoringu a logování úkonů prováděných nad databází, které byli součástí požadavků v zadání. Obdobně je řešeno zálohování dat, které je vyžadováno kvůli auditům z úřadů. Roční záloha dat se provádí pomocí SQL dump v administraci databáze. Díky tomu není třeba tuto funkcionalitu opět implementovat do samotného informačního systému TyfloData.
3 Níže uvedené schéma je třetí, finální verze, které je aktuálně platné a nasazené u zákazníka. Vazby mezi tabulkami jsou následující: pracovnik 1:1 login – každý pracovník musí mít unikátní login pracovnik N:1 pozice – každý pracovník systémově, platově i oficiálně zastává pouze jednu pozici. To že se v této malé společnosti pracující flexibilně doplňují, zastupují a vypomáhají, se zde úmyslně nebere v potaz pracovnik 1:N klient – každý klient má přiřazeného klíčového pracovníka, který se primárně stará o agentu spjatou s klientem pracovnik 1:N intervence – v této společnosti jsou ze zdravotních důvodů veškeré intervence individualizované. Každé intervence se tak vždy účastní pouze jeden pracovník intervence N:1 klient – obdoba předchozího odůvodnění. Každé jednotlivé intervence se účastní pouze jeden klient. intervence N:1 sluzba – každá intervence se týká pouze jedné služby. Pokud se schůzka skládá z více úkonů (služeb), je tato schůzka rozdělena na více intervencí 5
klient 1:1 adresa – z důvodu předejití možným chybám, které by mohli vzniknout např. při stejném bydlišti více klientů a následném úmrtí či přestěhování jednoho z nich, jsou adresy přiřazeny klientům unikátně. Každý klient má svou vlastní adresu klient N:1 restringovana_participace – na první pohled se tato vazba jeví jako N:N. Klient může být seniorem a zároveň trpět zrakovým znevýhodněním. V praxi ale při žádosti o grant za vykonané služby s takovýmto klientem lze uplatnit pouze jedno jeho „znevýhodnění“. Tudíž se vždy vybírá ta horší vlastnost, na kterou jsou vypláceny vyšší peníze. V tomto případě by tak tento klient měl uvedeno v tabulce restringované participace pouze zrakové znevýhodnění. Fakt, že je dotyčný senior, by byl uveden v poznámce a dále v osobní složce klienta.
Obrázek 1: Databázový model
Z výše uvedeného popisu je zřejmé, proč je databázové schéma takto jednoduché. Z podstaty způsobu fungování společnosti a legislativy upravující sociální služby se zde prakticky nevyskytují vazby typu N:N a tak nebylo potřeba takové vazby rozmělňovat na vazby 1:N, případně 1:1. To mělo za následek usnadnění práce, neboť se velice přívětivě tvoří SQL příkazy. Intervence, kterých se účastní naráz více klientů a pracovníků, např. muzikoterapie, výlety atp., jsou jednak velice ojedinělé, průměrně tak jedna za měsíc a za druhé se finančně 6
vykazují jiným způsobem. Nejedná se o státem registrovanou sociální službu, tudíž na ně nelze žádat o veřejné finance, a tudíž ani do tohoto systému svou povahou nepatří. Tabulka restringovaná participace nabývá hodnot: Zrakové znevýhodnění (Z), Kombinované znevýhodnění (K), Senior (S), Zdravotní znevýhodnění (A), Jiné znevýhodnění (J), Rodič/zákonný zástupce (R), Ostatní osoby (O). Tabulka služba nabývá hodnot: Sociální poradenství (SP), Sociální rehabilitace (SR), Průvodcovská a předčitatelská služba (PPS), Telefonická konzultace (TK), Doučování (Aj). Tabulka pozice nabývá hodnot: Sociální pracovník/ce (SP), Fundraiser (FR), Ředitel (CEO), IT pracovník (ICT). Ostatní tabulky, tj. klient, adresa, pracovník, login a intervence obsahují osobní údaje a v případě klientů pak dokonce citlivé osobní údaje a ze zákonů o ochraně osobních údajů a o sociálních službách nejsme k jejich přístupu oprávněnými osobami. Vývoj a testování tak probíhalo pouze na testovacích vzorcích. Ředitel společnosti a administrátor IS v jedné osobě byl navíc obeznámen s aplikací PHPMyAdmin a byl proškolen o jejím používání a jejími možnostmi. Do aplikace mu byly sděleny přihlašovací údaje administrátora (root).
7
4 Vzhledem k tomu, že program bude často obsluhován lidmi se zrakovým postižením, zaměřili jsme se na také na přístupnost. Zvolili jsme výrazné, barevné a kontrastní prvky, které uživatelům zjednoduší jejich práci. K vytvoření vzhledu byla využita technologie Bootstrap ver.3. První stránka, která se uživateli zobrazí, je stránka pro přihlášení:
Obrázek 2: Přihlašovací stránka Po úspěšném přihlášení se uživateli zobrazí hlavní stránka:
Obrázek 3: Úvodní obrazovka IS Uživatel má jasně rozdělené oblasti pro práci s intervencemi, klientem, pracovníkem, nebo s dalšími prvky.
8
4.1 Menu V orientaci uživatelům dopomáhá responzivní menu:
Obrázek 4: Menu
Obrázek 5: Responzivní menu
9
4.2 Intervence V následujících obrázcích si můžete prohlédnout náhledy na práci s intervencemi. Klient si může zvolit výpis intervencí týkající se klienta, pracovníka, nebo konkrétního klienta, který spolupracoval s konkrétním pracovníkem:
Obrázek 6: Přidat intervenci
10
Obrázek 7: Zobrazot intervenci (filtrování)
Obrázek 8: Vyfiltrované intervence Intervence je možné vyexportovat do xls. Po kliknutí na „Exportovat“ v obrázku Obrázek 9: Intervence – cesta k exportu se uživateli zobrazí obdobné formuláře jako u zobrazení. Stisknutí tlačítka „Vygeneruj“ způsobí export vybraných intervencí do xls formátu.
Obrázek 9: Intervence – cesta k exportu
11
4.3 Klient Klient a pracovník mají obdobný design jako položka intervence.
Obrázek 10: Klient
4.4 Restringovaná participace, pozice, služby Restringovanou participaci, pozici, nebo službu je možné přidat, či odebrat:
Obrázek 11: Pozice
12
4.5 Přihlašovací údaje Jedná se o stránku, která uživateli umožňuje snadnou práci s přihlašovacími údaji.
Obrázek 12: Přihlašovací údaje
5 5.1 Vývoj Prvotní vývoj probíhal na základě rozhovorů se zákazníkem, podle jeho požadavků byla navržena struktura aplikace, která byla později doplňována o funkční prvky. Zabezpečení aplikace byla jednou z prvních důležitých častí. Jelikož server bude přístupný pouze v lokální síti, do které mají přístup pouze zařízení organizace. K serveru je omezen i fyzický přístup. K zařízením mají přístup pouze zaměstnanci organizace. Díky těmto podmínkám je dostatečné zabezpečení na základní úrovni. Zaměstnanci se do aplikace přihlašují pomocí jména a hesla uloženého v databázi aplikace. Každý zaměstnanec má své vlastní přihlašovací údaje. Vstupní formulář pro zadávání jména a hesla je ošetřen proti XSS útokům pomocí funkce htmlspecialchars(). Dalším bezpečnostním prvkem je využití SESSIONs. Při zadání platných přihlašovacích údajů vznikne SESSION, díky ní je možné přistupovat k ostatním částím aplikace. Pokud by došlo k pokusu o přístup rovnou k části aplikace přes URL adresu bez předchozího získání SESSION, dojde k přesměrování na přihlašovací formulář. Další částí bylo vyřešení zadávání dat, bylo nutné zajistit uživatelský komfort a zároveň zajistit vkládání správných dat. Toto bylo zajištěno zadáváním dat pomocí předdefinovaných hodnot, ze kterých si uživatel pouze vybere. Toto řešení bylo použito všude tam, kde to bylo možné. Při vkládání klientů bylo nutné zajistit, aby byla klientovi přidělena správná adresa. Ovšem přidělování adresy pomocí ID, by bylo pro uživatele velmi nepřehledné a nepohodlné. Proto při přidávání klienta dojde rovnou i k přidání adresy, avšak uživatel to zaznamená jako jednu 13
akci. Je to zajištěno tím, že nejdřív dojde k vložení adresy, která dostane přiděleno ID, toto ID je poté přiřazeno klientovi. Tento problém nastává také při úpravě dat o klientovi. Proto při úpravě klienta dojde k vložení adresy, i když je adresa stejná jako předchozí a změní se ID adresy klienta. Dále bylo nutné zajistit export dat do souboru. To bylo jedním ze základních požadavků zákazníka na aplikaci. Zvolen byl export do formátu .xls (MS EXCEL). Název vygenerovaného souboru obsahuje čas a datum vygenerování reportu. Data vrácena SQL dotazem jsou vložena do tabulky, kde indexy tabulky jsou pojmenovány podle jmen atributů z databáze. Poté jsou do první řádky dokumentu názvy sloupců a následně jsou vkládána data z výpisu. Každá hodnota je vložena do vlastní buňky v dokumentu. Díky tomuto řešení lze na data později možné aplikovat různé funkce obsažené v MS EXCEL.
5.2 Testování Testování probíhá ve dvou fázích. V první fázi vývoje probíhalo testování pouze lokálně pomocí localhost serveru. Tímto testováním byla ověřována správná funkčnost skriptů. Bylo nutné ověřit, zda jsou všechny SQL příkazy plně a správně funkční. Ověření funkčnosti zabezpečení, a zda jsou všechny parametry předávány správně. Při této fázi byla zajištěna správnost logické funkčnosti aplikace. Druhá fáze testování se týká uživatelských zkušeností. Aplikace je používána v ostrém provozu a pomocí připomínek a požadavků od uživatelů bude řízen další vývoj aplikace. Tímto je zajištěno udržení a zlepšování uživatelského komfortu. Tento systém testování zefektivní další vývoj aplikace. Na základě feedbacku od uživatelů budou běžným zaměstnancům omezena uživatelská oprávnění. Feedback je důležitý, aby bylo jasno, co vše je možné běžným uživatelům skrýt, nebo omezit. Pro tyto omezení už je v aplikaci připraveno řešení, které využívá SESSION
5.3 Nástroje použité pro vývoj PSPad Editor MySQL Workbench 6.3 CE VertrigoServ Opera beta
14
6 Z četných diskusí se zadavatelem došlo k mnohým úpravám oproti původnímu zadání IS projektu. Zde jsou některé z nich: Dle města nabídnout odpovídající PSČ – náročnost implementace nereflektuje funkční přínos Přepínač, který určuje, zda je vedena i složka s písemnou dokumentací – v současné době je stále vždy vedena i papírová složka a to i u nových klientů. Momentálně se ani do budoucna nejeví, že by mělo dojít ke změně této skutečnosti Při přidávání nového klienta kontrolovat duplicity jmen a vypsat ID klienta – z kontroly papírové kartotéky vyplynulo, že duplicity jmen jsou tak vzácné, že by tato funkcionalita nebyla téměř využita Operační systém Debian místo OS Fedora – pro serverovou stanici byla zvolena konzervativní stable distribuce Debian místo spíše testovací distribuce Fedora, která je vhodná pro osobní stanice Díky konzultacím a odsouhlasení zadavatelem lze konstatovat, že změny jsou změny k lepšímu, neboť nyní nedůležité vlastnosti IS byli vypuštěny a úsilí tak mohlo být věnováno tam, kde ho bylo skutečně potřeba. Výsledný produkt je tedy skutečně ten, který splňuje to, co zadavatel potřebuje.
7 Pro koncové uživatele byla vytvořena uživatelská dokumentace (viz Příloha), která má za cíl napomoci se v systému orientovat.
8 Během vývoje a testování se narazilo na řadu problémů. Za vyzdvihnutí stojí následující: Sjednocení kódování v IS a databázi – při testování opakovaně docházelo k problémům s „rozsypaným čajem“. A to v obou směrech, tedy při získávání dat s diakritikou z databáze i při nahrávání údajů s diakritikou do databáze. Grafický design vhodný pro zrakově indisponované uživatele – zrakově znevýhodnění nejsou v organizaci pouze klienti, ale i zaměstnanci a tedy i uživatelé IS. Uživatelské rozraní tak muselo být tvořeno s ohledem na takovéto uživatele. Tzn. veškerý obsah musí být v textové podobě. A naopak grafickému, bitmapovému obsahu se co nejvíce vyvarovat. Před vzhledem upřednostňovat funkčnost a držet se pravidla, že méně je více.
15
Časové a datumové formáty v IS a v DB – pro správnou funkčnost IS je potřeba dodržovat jednotné časové a datumové formáty, kterým databáze rozumí. Ošetřeno to bylo užíváním vhodného aplikačního vybavení a proškolením uživatelů.
9 V případě, že si vytvořený IS získá oblibu, bude se s jeho vývojem pokračovat. Implementovat se mohou výše zmíněné funkcionality, které jsou v současné době oprávněně „odstavené na druhou kolej“. Dále pak jsou potřeba naimplementovat oprávnění. U zadavatele se teprve formují pravidla pro různé uživatele. Nynější stav, kdy nejsou rozlišené úrovně rolí a oprávnění, je neuspokojivý. Vzdálená správa, šifrování a obecně zvýšení kvality zabezpečení IS jsou vylepšení, která by si v budoucnu zasloužila svou pozornost.
10 Koncoví uživatelé IS, včetně těch, kteří k užívání IS musí využívat kompenzačních pomůcek, byli proškoleni v sídle organizace. Ředitel společnosti byl navíc seznámen se strukturou aplikace, softwarovým vybavením a byly mu sděleny i administrátorské údaje do jednotlivých softwarových částí serveru. I přesto, že IS TyfloData nebyl honorován, je výsledný produkt v praxi užitečný, jak ostatně dokládá zpětná vazba od ředitele společnosti. Viz přílohu.
16
11 11.1 Uživatelská dokumentace Tato uživatelská dokumentace popisuje informační systém, všechny jeho vlastnosti, parametry, způsoby používání a procesy v něm fungující. Příručka je určena administrátorům IS.
Registrace uživatelů Uživatelské účty Pro plnohodnotnou práci v informačním systému je nezbytné mít svůj vlastní uživatelský účet, se kterým se do IS bude uživatel přihlašovat (používat dvojici jméno-heslo). Pokud uživatel zatím účet nemá, požádá uživatele s existujícím účtem, aby mu účet vytvořil. Podobný postup se aplikuje v případě, že uživatel zapomněl heslo. Přihlášení uživatele Při spuštění aplikace se uživateli zobrazí přihlašovací okno, viz Obrázek 13: Přihlašovací okno.
Obrázek 13: Přihlašovací okno Po zadání správného přihlašovacího jména a hesla se uživateli zobrazí úvodní stránka, viz Obrázek 14: Úvodní stránka.
17
Obrázek 14: Úvodní stránka Pro práci s uživatelskými účty klikne uživatel na tlačítko přihlásit na úvodní stránce. V rozbalovacím menu v horní liště je tato možnost skryta pod „LOG IN/OUT“.
Obrázek 15: LOG IN/OUT Kliknutím na panáčka vpravo nahoře se uživatel vrátí na hlavní stránku.
Obrázek 16: Návrat na hlavní stránku
Práce s uživatelskými účty Podle potřeby můžeme přidávat, měnit a odebírat přihlašovací údaje. V případě přidávání vyplníme pole jméno a heslo pod nadpisem „Přidat přihlašovací údaje“. Poté klikneme na tlačítko přidat a nový uživatel je vytvořen. V případě změny hesla vybereme jméno uživatele, jemuž chceme heslo měnit. Následně vyplníme kolonku heslo novým heslem pro daného uživatele. Tlačítko změnit heslo změní. Přihlašovací údaje lze i odebírat. V tomto případě doporučujeme opatrnost, abyste neodebrali přihlašovací údaje někomu, kdo je bude potřebovat. 18
Obrázek 17: Přihlašovací údaje
19
Funkčnost Úvodní strana (viz Obrázek 14: Úvodní stránka) uživateli zobrazuje všechny položky, se kterými může pracovat, a jejich strukturu. Vzhledem k tomu, že funkčnost položek Intervence, Klient a Pracovník je obdobná, ukážeme si ji na položce Intervence.
Intervence Při kliknutí na intervenci se uživateli zobrazí nabídka, co může s intervencemi dělat (viz Obrázek 18: Intervence). Intervence tedy můžeme přidávat, zobrazit a exportovat.
Obrázek 18: Intervence Přidat Intervence přidáváme pomocí formuláře:
Obrázek 19: Přidat intervenci Vybereme klienta a pracovníka, kterých se daná intervence bude týkat. Následně zvolíme službu, vyplníme místo a v kalendáři vybereme datum. Doplníme časy začátku a konce intervence a pomocí tlačítka „Přidat“ intervenci uložíme do databáze. Zobrazit Pokud chceme zobrazit intervence, můžeme zobrazit všechny tím, že nevyplníme políčka. Pokud máme zájem o údaje ke konkrétní intervenci, vyplníme nám známé údaje ve formuláři. Můžeme hledat 20
intervence pro klienta a pracovníka, samotného klienta (nezávisle na pracovníkovi) a pracovníka (nezávisle na klientovi). Exportovat Pro export se uživateli zobrazí obdobný formulář.
Ostatní funkčnost Údaje o klientech a pracovnících mohou být navíc upravovány, tj. možnost „Upravit“, nebo mazány, tj. možnost „Odstranit“. Na rozdíl od funkčnosti intervencí, možnost exportu nebyla implementována.
Obrázek 20: Mazání klienta Registrovanou participaci, pozici (pracovní pozice) a službu lze v systému přidat, nebo smazat.
Obrázek 21: Pracovní pozice Po kliknutí na tlačítko odhlásit je uživatel odhlášen ze systému. Zobrazí se přihlašovací stránka.
11.2 Feedback 21
22
