1. Požadavky kladené na informační systém pro Dům dětí a mládeže

Vytvoření informačního systému (IS) pro malou organizaci je vždycky problém, zvláště, pokud nedisponuje příliš velkými finančními prostředky. Touto malou příspěvkovou organizací je JUNIOR – Dům dětí a mládeže Brno, Dornych 2 (DDM), jehož zřizovatelem je Jihomoravský krajský úřad a pro který byl popisovaný IS navržen, realizován a je v současnosti provozován. Zvláštností provozovatele je jeho teritoriální rozčlenění po městě Brně, tj. existence poboček, od sebe dosti vzdálených a proto mezi základní požadavky právě patří možnosti přístupu k IS přes internet.

Shrneme-li základní požadavky, které si uživatel na budoucí IS stanovil, lze je sestavit do následujících bodů:

• Jednoduchá obsluha – uživatelská přítulnost aplikace.
• Dostatečné zabezpečení údajů – např. šifrováním vybraných údajů.
• Vysoká spolehlivost systému – daná výběrem vhodného databázovým systémem.
• Dostatečná kapacita pro datové soubory.
• Síťový přístup – jako zásadní podmínka z důvodu různé dislokace poboček DDM.
• Využití dat ze stávajícího IS – urychlí přechod ze stávajícího a nevyhovujícího IS.
• Rozšiřování systému v budoucnosti – tedy modulová struktura aplikace.

Na základě uvedených vstupních požadavků byl provozovateli nabídnut vývoj IS v databázovém vývojovém systému Visual FoxPro v nejnovější verzi 9.0., který byl na český trh uveden v lednu roku 2005, tedy přesně v době počátcích vývoje IS. Visual FoxPro plně podporuje firma Microsoft, je tedy provozovatelný v operačních systémech od verze Windows 2000 (omezeně od verze Windows 98) včetně serverových aplikací a je pro uživatele (tedy Run Time Modul) lokalizován do češtiny.

2. Struktura programu a popis funkce modulů

Při návrhu základní struktury aplikace se vždy vychází z požadavků na ni kladených, ani při návrhu struktury IS pro DDM tomu není jinak. Základní podmínka vývoje programového vybavení pro systémy pracující v multitaskingu je modularita programu. Bez vhodného strukturování se pak údržba aplikace stává nepřehlednou a složitou. V případě IS pro DDM lze modularitu ještě více podtrhnout následujícími body:

• Přehlednost při vývoji i při obsluze.
• Jednoznačné oddělení datových struktur od programu.
• Spolehlivé a automatické zálohování dat.
• Snadná udržovatelnost programového vybavení.
• Dálková správa programového vybavení přes internet a vzdálenou plochu.

Na obrázku obr. 1 je zobrazeno ideové schéma struktury IS pro DDM a modulová skladba je z něj více než patrná. Mimo jádra programu je IS sestaven z 8 modulů (dílčích programových celků), jejichž stručný popis je uveden dále.

2.1. Jádro aplikace – hlavní program

Hlavní program spojuje všechny moduly do jedné aplikace a zajišťuje homogenitu systému. Mimo přípravy prostředí, zajišťuje přístup k jednotlivým nabídkám v menu podle individuálních práv přístupu každého uživatele.

2.2. Modul přístupových práv k funkcím programu

Modul definující přístupová práva každému uživateli určuje, ke kterým funkcím, resp. modulům bude mít přihlášený uživatel právo přístupu a to ještě v jaké podobě (jen čtení nebo plná modifikace). Pro správce IS byla vytvořena "maketa" menu aplikace s tím, že pouhým kliknutím na každý řádek menu definuje právo přístupu k uvedené funkci tzv. svislá architektura. Pro definování práv pro čtení resp. i zápis je vytvořená běžná tabulka, v níž jsou tato práva jednoznačně přiřknuta každému uživateli, tzv. vodorovná architektura. Protože se zde ukládají choulostivější údaje, byl přístup chráněn šifrovaným heslem.

2.3. Modul evidence provozu IS

Modul evidence provozu IS včetně evidence vzniku programových poruch – tento modul, resp. jeho funkce byly na počátku vývoje programu zavedeny především z hlediska odchytávání možných programových chyb a tím pádem lepší možnosti finálního ladění aplikace. Následně byla tato funkce rozšířena o evidenci přihlášených uživatelů a jejich činnosti v programu. V podstatě jde o zápis informace o spuštění určité funkce v programu (obecně okna) do zvláštní databáze a následně i zápis ukončení práce v této části programu – okně. S odstupem času se ukázala tato funkce za nesmírně výhodnou a to nejen z hlediska údržby aplikace jako takové, ale také z hlediska dostatečného argumentu pro obsluhu, pokud měla připomínky na nefunkčnost některého z modulů.

2.4. Modul evidence ZÚ (Zájmových útvarů) a jejich členů

Modul evidence ZÚ – tedy v podstatě evidence kroužků a kurzů pořádaných DDM umožňuje evidovat veškeré ZÚ odděleně podle poboček, ale také podle dne konání, eviduje zapsané členy těchto ZÚ a spojení na ně. Součástí evidence jsou také platby za činnost v těchto kroužcích s možností volby různých "rozsahů" platby od jednorázových po měsíční pololetní a roční. Modul tedy spolupracuje s modulem evidence plateb. Chráněné údaje, tedy především rodné číslo, jsou v databázích šifrované.

2.5. Modul evidence akcí pořádaných provozovatelem

Modul umožňuje evidovat všechny akce, které DDM pořádá rozčleněných do 9 typů (podle požadavků MŠMT). Pořádané akce jsou zveřejněny na webu bezprostředně po zadání akce do IS, evidují se údaje o počtu účastníků na akci, doby konání akce, kdo ze zaměstnanců se na pořádání akce podílí a následně i vyhodnocení akce z několika hledisek, opět včetně hodnocení akce pro širokou veřejnost tedy zveřejňované na webu.

2.6. Modul evidence táborů a účastníků

Modul eviduje pořádané tábory podle ročních období a poboček, eviduje táborníky, jejich osobní údaje (chráněné opět v šifrované podobě), jejich platby (ve spojení s modulem plateb). Samozřejmostí je spojení na rodiče apod.

2.7. Modul evidence zaměstnanců – personalistika

Tento, poměrně rozsáhlý modul, eviduje veškeré interní i externí zaměstnance DDM. Jejich pracovní smlouvy i smlouvy o provedení práce či o pracovní činnosti. Veškeré formuláře při nástupu do zaměstnaneckého poměru, vybírané podle typu nového zaměstnance a pracovního poměru. Zaměstnanci jsou v evidenci přiřazeni na pobočky nebo hlavní pracoviště a následně se k nim evidují pracovní výkazy pro realizaci platových příkazů. Složitost pracovněprávních vztahů si vynutila možnost velmi různorodě definovat pracovní zařazení – hlavní a vedlejší (nyní druhý) pracovní poměr a oba typy dohod, s možností vedení pracovních výkazů na různých pracovištích a nastavení různých týdenních úvazků.

2.8. Modul evidence plateb

Tento modul eviduje veškeré platby, které v souvislosti s evidovanými aktivitami přichází na DDM a to jak v případě hotovostních plateb na jednotlivých pobočkách, tak i bezhotovostních plateb realizovaných přes bankovní sektor a zjišťovaných v denních výpisech z banky ve formátu BEST. Získané položky plateb se následně párují s plátci podle jednoznačného variabilního symbolu platby. Algoritmy pro párování plateb dokáží rozpoznat správné platby a přiřadit je k plátcům, komplikací při tomto párování je skutečnost, že v průběhu roku může plátce realizovat hned několik plateb pod stejným variabilním symbolem, neboť může platit např. v ZÚ měsíční, pololetní či roční platby, může provádět doplatky za "zůstatek" určitého pololetí a pro bezhotovostní platby byla realizována i možnost jedné platby pro více plátců (rodič platí za dva či tři kroužky či za sourozence pouze jednou platbou). Systém ale dokáže také rozpoznat i chybové platby, tedy platby, pro které neexistuje plátce, resp. platby, které neodpovídají správné výši poplatku. Tyto případy pak obsluha musí "dopárovat" či opravit. Také lidská chyba při zápisu do IS, resp. při bezhotovostních platbách se silně podílí na komplikacích, které se objevují při párování plateb.

2.9. Modul statistiky a exportu dat pro webovskou aplikaci DDM

Uvedený modul umožňuje vyhledávání členů ZÚ, táborníků podle příjmení nebo variabilního sysmbolu a u zaměstnanců vyhledávání podle příjmení. U vyhledaného člena ZÚ či táborníka umožňuje zobrazit příslušnost k ZÚ resp. táboru. Zobrazované údaje jsou však fitrovány a zobrazení se řídí právy přístupu k povoleným informacím. Pro potřebu zatraktivnit nabídku zajmové činnosti jsou informace o náplni ZÚ a táborů zvěřejněny na webu ve vlastní aplikaci, do níž jsou aktuální informace s IS pravidelně exportovány.

3. Provozní nasazení a zkušenosti s provozem

Základní vývoj aplikace probíhal zhruba 4 měsíce a po nainstalování první verze na server provozovatele probíhal omezený testovací provoz s omezeným počtem poučených uživatelů přibližně 2 měsíce. Od 1. 9. 2005 je IS v ostrém provozu, kdy se na server v průběhu dne připojuje kolem 30 uživatelů. Díky dvěma pomocným databázím (logovacím a chybovým) je pro progrmátora a také pro správce IS kdykoliv přístupná informace o aktuálním stavu systému. Programátor informace využívá k dolaďování funkcí programu a odstraňování případných chyb v programu a správce pak má neustále přehled kdo a jak dlouho pracuje v kterém modulu, což v minulosti přineslo (jak již bylo zmíněno) jasno do problémů s argumenty méně schopné obsluhy.

V nočních hodinách je na serveru spouštěna samostatná aplikace, která slouží k údržbě a zálohování databázových struktur, obnově indexových souborů a exportu aktuálních informací pro webovskou aplikaci. Zálohovaná data se pak přesouvají na jiný – pomocný server. Z denně zálohovaných dat je možné provést jednorázové statistiky nárůstu členské základny v ZÚ v období zápisu do těchto ZÚ, případně k provedení statistiky nárůstu plateb za ZÚ a tábory.

Soubory knihoven Visual FoxPro (Run Time Modul) jsou volně šiřitelné s aplikací, proto vznikla mezi programátorem a provozovatelem smlouva o dílo, která pokrývá multilicenční požadavky provozování IS na serveru provozovatele. Součástí této smlouvy pak byla i doložka o realizaci potřebných UpGrade programu podle okamžitých a provozních potřeb provozovatele. Po zprovoznění aplikace a jejím provozním nasazení byla podepsána jiná smlouva o servisu IS, přičemž jsou v ní zakotveny jak požadavky provozovatele na údržbu IS, tak i forma jakou budou předávány požadavky na rozšiřování případně doplňování nových funkcí v IS.

Příspěvek recenzovali:

• Milena Tvrdíková, předsedkyně Moravskoslezské sekce ČSSI,
• Ján Hudec, prezident SSSI.

20.03.2007 - Rudolf Jalovecký - četlo 23358 čtenářů.

Tento článek ješte není ohodnocen.

Hodnocení článku: nejlepší [ 1 | 2 | 3 | 4 | 5 ] nejhorší

Diskusní fórum ke článku
Jméno
E-mail
Opište kód :
Text *)