Modelování podnikových procesů a inovace informačního systému zdravotnického zařízení

Transkript

1 Mendelova univerzita v Brně Provozně ekonomická fakulta Modelování podnikových procesů a inovace informačního systému zdravotnického zařízení Diplomová práce Vedoucí práce doc. Ing. Ivana Rábová, Ph.D. Bc. Lukáš Palupa Brno 2010

2 Mé poděkování patří především doc. Ing. Ivaně Rábové, Ph.D. za velmi cenné rady, připomínky a odbornou pomoc při vedení této práce. Dále bych chtěl poděkovat pracovníkům Psychiatrické léčebny v Brně-Černovicích, kteří mi byli ochotni při psaní této práce poskytnout veškeré užitečné informace.

3 Prohlašuji, že jsem tuto práci vypracoval samostatně pod odborným vedením doc. Ing. Ivany Rábové, Ph.D. a v seznamu literatury jsem uvedl veškeré použité literární a odborné zdroje. místo a datum prohlášení

4 4 Abstract Palupa, L. Business process modeling of medical facility and inovation of information system. Diploma thesis. Brno, 2010 The theme of this thesis is to analyze existing business processes of medical facility. Based on this analysis is designed and implemented a new information system. For modeling of the proposed solution is used UML. The resulting goal is a functioning system for management of duties scheduling in psychiatric hospital. Abstrakt Palupa, L. Modelování podnikových procesů a inovace informačního systému zdravotnického zařízení. Diplomová práce. Brno, 2010 Tématem této diplomové práce je analýza stávajících podnikových procesů zdravotnického zařízení. Na základě této analýzi je navržen a realizován nový informační systém. K modelování navrženého řešení je využit jazyk UML. Výsledným cílem práce je fungující informační systém pro správu rozpisů služeb pracovníků psychiatrické léčebny.

5 OBSAH 5 Obsah 1 Úvod a cíl práce Úvod Cíl práce Přehled literatury Požadavky systému CASE nástroje Popis a historie Enterprise Architect Procesní řízení a modelování Podnikové procesy Business Process Reengineering Objektový přístup Objekt Třída Unifikovaný modelovací jazyk Popis a historie UML Diagramy podnikových procesů Diagramy případů užití Diagramy tříd Diagramy aktivit Sekvenční diagramy Vlastní řešení Psychiatrická léčebna Brno Historie Popis a specializace Analýza současného stavu Úvod do problematiky rozpisů služeb Analýza podnikových procesů Současné řešení procesů Návrh nového řešení Specifikace požadavků Diagram případů užití Diagram tříd Diagram aktivit Implementace Diskuse 62 5 Závěr 64

6 OBSAH 6 6 Literatura 65

7 1 ÚVOD A CíL PRÁCE 7 1 Úvod a cíl práce 1.1 Úvod Informační technologie a systémy jsou nedílnou součástí dnešní lidské společnosti. Lidé s nimi přichází do styku doslova na každém kroku a mnohdy si už bez nich život jen těžko představují. Množství a dostupnost informací, kterými jsou dnes lidé denně obklopeni představují množství výhod a ulehčení starostí běžného života. Internet dnes již pronikl skoro do každé domácnosti a mnoho lidí si dnes život bez internetu a věcí s ním spojených jen těžko dokáže představit. Tento trend však přináší také negativní dopady v podobě získávání nechtěných a nevyžádaných informací. Veliký nárůst ve využívání informačních systémů a technologií nastal také ve firemním sektoru. Přineslo to veliké výhody v úspoře pracovního času a také v neposlední řade došlo k úspoře financí. Informační systémy dnes zavádí i mnoho malých podniků, které mají možnost žádat o dotace a jsou pro ně tedy dostupnější. Počítačová podpora v řízení podniku je velikou výhodou jak pro management tak pro pracovníky. Výjimkou není ani sektor zdravotnictví. Pro nemocnice a jiná zdravotní zařízení, která pečují o hospitalizované pacienty je dnes již chod bez spolehlivého informačního systému takřka nemyslitelný. Informační systémy tohoto typu jsou většinou zaměřeny na uchovávání a správu informací o pacientech. Každá firma má svoji podnikovou kulturu a zvyklosti. Zavádění nového informačního systému může sklízet od zaměstnanců, kteří zaváděný systém mají začít používat negativní ohlasy. Může to být z mnoha důvodů. Nejčastějším důvodem je však neochota ke změně dělat něco jiným způsobem než jsou zaměstnanci zvyklí. Dalším možným důvodem je (zejména u pracovníků starší generace) počítačová negramotnost. Se zavedením nového informačního systému může docházet i ke změně podnikových procesů firmy a tedy může dojít k nepotřebnosti některých zaměstnaneckých pozic. To jsou všechno negativní dopady zavádění systému, které by však neměli převyšovat pozitivní dopady, které nový informační systém přinese. Jednou z nejdůležitějších činností před rozhodnutím zda pořídit nový informační systém (nebo upravit či aktualizovat stávající) je modelování současného stavu a stavu po zavedení systému. Model je zjednodušení reality. Díky modelování jsme schopni prvky reálného světa a jejich vazby převést do modelu, který zachová pouze podstatné prvky zkoumaného systému. Modelováním jsme schopni určit zda realizace změn, které se chystáme provést přinese požadovaný užitek. Modelováním je také možné zjistit jestli je implementace změn vůbec možná. Je tedy na managementu společnosti aby zvážil investici do systémové podpory řízení a chodu podniku. Modelování je jedna z možností, které mu rozhodování mohou usnadnit.

8 1.2 Cíl práce Cíl práce Téma, kterým jsem se rozhodl zabývat v této diplomové práci je mi blízké. Vím jak je složité a nepříjemné být vedoucím pracovníkem na zdravotnickém oddělení, protože jsem při psaní této práce s jedním spolupracoval. Konkrétně se jedná o staniční sestru pracující v psychiatrické léčebně v Brně-Černovicích. Práce staniční sestry obnáší mnoho zodpovědnosti a nepříjemných povinností. Jednou z těchto nepříjemných povinností je sestavování měsíčního rozpisu služeb pro pracovníky na přiřazeném oddělení. Právě z toho důvodu abych tuto práci ulehčil a zjednodušil (zejména po časové stránce) jsem si zvolil toto téma pro mou diplomovou práci. Cílem této práce je analyzovat současný stav v psychiatrické léčebně. Provést modelování podnikových procesů odpovídajících současnému stavu ve správě léčebny. Dále potom vyhodnotit, zda je současný stav vyhovující a zda systém, který je zavedený odpovídá požadavkům pracovníků a to zejména vedoucím pracovníkům. Tito pracovníci s ním přicházejí do styku denně a proto je jistě žádoucí, aby byl uživatelsky nenáročný a splňoval požadavky personálu léčebny. Analýza současného stavu bude podpořena modelem podnikových procesů. Návrh a spravování měsíčních rozpisů služeb nejsou v současném systémovém vybavení léčebny podporovány. Dalším cílem této práce je tedy navrhnout řešení problému měsíčních rozpisů služeb pro jednotlivá oddělení léčebny. Návrh bude zahrnovat modelování prostřednictvím jazyka UML s využitím CASE nástroje Enterprise Architect společnosti Sparx Systems. Dalším cílem je implementace navrženého řešení. S ohledem na počítačovou gramotnost personálu léčebny bude implementace provedena tak, aby měla jednoduché a intuitivní ovládání. To zahrnuje příjemné grafické uživatelské rozhraní, které nebude obsahovat příliš mnoho nastavení a možností pro obyčejného uživatele. Finální verze navrženého rozpisu by se neměla příliš lišit od rozpisu na který je personál léčebny zvyklý již několik let. Systém bude dostupný z internetu a ovládaný prostřednictvím internetového prohlížeče. K implementaci systému bude použit skriptovací jazyk PHP a pro uložení dat bude použit databázový systém MySQL. V závěru práce bude provedena ekonomická analýza navrženého řešení.

9 2 PŘEHLED LITERATURY 9 2 Přehled literatury 2.1 Požadavky systému Správný popis požadavků je jednou z nejdůležitějších částí navrhování a vývoje informačního systému. Tato část vývoje informačního systému by měla předcházet každému úspěšnému projektu. Bez specifikace požadavků budoucích uživatelů systému jen těžko dosáhneme správné funkčnosti, která se od systému po jeho implementaci očekává. Přičemž je třeba dbát na to, aby požadavky říkaly co bude systém nabízet a ne jak to zařídí. Správná specifikace požadavků může mít zásadní vliv na budoucí úspěch celého projektu. Jedním z klíčových prvků vývoje informačního systému je spolupráce při jeho navrhování s budoucími uživateli. Tito budoucí uživatelé systému však mohou mít různé požadavky na funkce systému, někdy mohou být dokonce současně nesplnitelné. Z těchto poznatků vyplývá, že by do specifikace požadavků měly být zapojeny všechny budoucí uživatelské skupiny. Získávání takovýchto informací nemusí být vždy úplně snadnou záležitostí. Jak bylo uvedeno výše, budoucí uživatelé mohou mít různé představy o funkcích systému. To však není jediné úskalí specifikace požadavků. Dalším problémem při sestavování požadavků může být ten, že uživatelé nemají systémové vzdělání a jejich požadavky nejsou realizovatelné. Do svízelné situace je možné se dostat i v případě, že uživatel neumí formulovat co přesně od systému očekává. Těchto problémů může nastat více a jejich vyřešení zásadně ovlivní budoucí podobu systému a v neposlední řadě spokojenost uživatele se systémem. Aktivity spojené s požadavky jsou doporučeny provádět v této posloupnosti: (Kanisová, Müller, 2004, s. 19) identifikace funkčních požadavků identifikace nefunkčních požadavků identifikace případů užití a jejich navázání k funkčním požadavkům promítnutí nefunkčních požadavků do technické architektury systému Zejména provázání funkčních požadavků a případů užití má kontrolní funkci, neboť při navazování relací je možné zjistit, že požadavky obsahují něco, co není posud rozpracováno v případech užití nebo obráceně. Je nutné podotknout, že navázání relací mezi požadavky a případy užití nemusí být právě snadnou záležitostí vzhledem ke komplikovaným vztahům mezi nimi. Tuto práci však velmi usnadňuje CASE nástroj. 2.2 CASE nástroje Popis a historie K vývoji prvních CASE nástrojů dochází v 70. letech minulého století. Tyto první CASE nástroje byly typu Lower Case. Byly zaměřeny především na to aby byly schopny generovat zdrojový kód přímo z navrženého modelu. V 80. letech vznikly

10 2.2 CASE nástroje 10 první CASE nástroje s interaktivním grafickým uživatelským rozhraním. Tyto nástroje začaly být komplexnější a začaly upřednostňovat navrhování systému před generováním zdrojového kódu. V 90. letech, kdy začal vznikat modelovací jazyk UML se začaly objektově orientované CASE nástroje ubírat tímto směrem. V dnešní době se již CASE nástroje využívají v řízení celého životního cyklu vyvíjené aplikace. Dnes podpora CASE nástrojů sahá dokonce do řízení celých projektů. Umožňují na základě modelovaného datového modelu přímo generovat kód pro podporované databázové systémy. Podporují širokou škálu modelů s kterými lze provádět forward nebo reverse engineering. Podporují týmovou práci více analytiků a designérů na jednom projektu. Podstatnou funkcí CASE nástrojů je podpora pro vytváření kvalitní dokumentace projektu. CASE nástroje (z angl. Computer Aided Software Engineering) jsou nástroje pro počítačovou podporu navrhování a analýzy aplikací. V dnešní době je drtivá většina velkých projektů zabývajících se vývojem informačních systémů tvořena objektově orientovaným způsobem (vizčást Objektový přístup). K modelování takto velikých projektů je zapotřebí komplexní nástroj, který je pro tento účel určený. Dnešním zaběhnutým standardem pro objektové modelování je jazyk UML (bližší seznámení v části Unifikovaný modelovací jazyk). Všechny dnes využívané objektové CASE nástroje jsou založeny na modelovacím jazyce UML. Druhy CASE nástrojů podle životního cyklu. (Wikipedia CASE nástroje, 2009) Pre CASE určeny pro globální strategii. Upper CASE určeny pro fázi dokumentace, popisu procesů organizace a celkové její analýzy. Middle CASE určeny pro tvorbu globálního a detailního návrhu informačního systému. Lower CASE určeny pro tvorbu kódu a implementace. Post CASE podporují zavedení a testování systému Enterprise Architect CASE nástroj Enterprise Architect je vyvíjený společností Sparx Systems sídlící v Austrálii. Společnost byla založena roku 1996 Geoffrey Sparksem. V současné době má společnost Sparx Systems na svůj produkt Enterprise Architect prodaných přes licencí po celém světě. Nejnovější verzí je dnes Enterprise Architect 8. Pro podporu svých zákazníků má společnost na svých internetových stránkách 1 zřízeno diskusní fórum. Menším záporem pro tento produkt je to, že prozatím není dostupná česká lokalizace. Enterpise Architect vychází plně z modelovacího jazyka UML (konkrétně nejnovější verze UML 2.1). Je tedy čistě objektově zaměřeným CASE nástrojem. Tento CASE nástroj plně podporuje vývoj systému v celém jeho životním cyklu. Další funkcí nástroje je generování zdrojového kódu včetně tzv. reverse engineeringu do 1

11 2.3 Procesní řízení a modelování 11 mnoha programovacích jazyků. Podporuje vytváření dokumentace do různých formátů (např. html, rtf,... ). Funkce které jsou pro modelování dostupné závisí na edici Enterprise Architectu. V současné době jsou dostupné tyto edice produktu: Ultimate Systems Engineering Business & Software Engineering Corporate Professional Desktop Pro úplnost bych dodal, že je z internetových stránek společnosti možné bezplatně stáhnout zkušební 30-ti denní verzi produktu Enterprise Architect. 2.3 Procesní řízení a modelování Podnikové procesy Podnikový proces je souhrnem činností transformujících souhrn vstupů do skupiny výstupů (zboží nebo služeb) pro jiné lidi nebo procesy, používajíce k tomu lidí a nástroje. (Řepa, 2007, s. 15) Podnikový proces si lze znázornit pomocí grafických symbolů vizobr. 1. Účelem tohoto modelu je definovat vstupy procesu a jejich zdroj, proces samotný a zákazníka i s ním spojené výstupy. Rovněž je zde vidět důležitá zpětná vazba od zákazníka. Obr. 1: Základní schéma podnikového procesu (Řepa, 2007, s. 15) Důležitým faktorem, který hraje roli při konkurenční soutěži firem na trhu jsou podnikové procesy společnosti. Aby mohla firma obstát v konkurenčním souboji na trhu je nezbytné, aby služby které poskytuje vyhovovaly zákazníkům. Pokud tomu tak není nastává potřeba zlepšování podnikových procesů. Zákazník má v tržním prostředí vždy možnost se obrátit na konkurenční firmu, to nutí společnosti své podnikové procesy neustále zlepšovat. V zásadě existují dva způsoby zlepšování podnikových procesů. Jedním z nich je Business Process Reengineering celková a úplná změna podnikových procesů.

12 2.3 Procesní řízení a modelování 12 Tato možnost bude detailněji popsána dále. Druhým způsobem je průběžné zlepšování podnikových procesů. Průběžným zlepšováním podnikových procesů dochází k neustálému zlepšování procesů v průběhu času. Tento způsob zlepšování podnikových procesů je vhodný k dosažení evolučního přírustkového zlepšení. (Řepa, 2007, s. 16) Základní kroky průběžného zlepšování procesu jsou výstižně shrnuty na Obr. 2. Obr. 2: Průběžné zlepšování procesu (Řepa, 2007, s. 16) Pokud ovšem společnost nepotřebuje podnikové procesy změnit jen v menším měřítku je tento způsob zlepšování procesů neefektivní a vede spíše ke zhoršení situace. Konkurence na trhu si v mnoha případech vyžádá radikální změnu podnikových procesů. Tento způsob zahrnuje kompletní změnu podnikových procesů a nahrazení procesy jinými a nazývá se Business Process Reengineering Business Process Reengineering Business Process Reengineering je zcela jiným přístupem, než průběžné zlepšování procesů. Ve své extrémní podobě Business Process Reengineering předpokládá, že stávající podnikový proces (procesy) je zcela nevyhovující nefunguje, je špatný, je třeba jej z podstaty změnit, od počátku. (Řepa, 2007, s. 16) Jednou z nejpodstatnějších výhod renegineeringu je ta, že je možné procesy vytvářet úplně nové a ne je pouze přeměňovat nebo upravovat. Takto vytvářené procesy mohou být přímo zacíleny na to co si zákazník přeje a tímto je možné co nejvíce dosáhnout spokojenosti zákazníků. Spokojenost zákazníků však není jediným aspektem, který by měl rozhodovat o úplném reengineeringu. Neméně důležité aspekty jsou cena a náročnost nového řešení. V některých případech nejsou takto radikální kroky nutné a stačí pouze upravit stávající procesy. Základní kroky průběhu reengineeringu procesů jsou ilustrovány na Obr. 3. Obr. 3: Model zásadního reengineerngu (Řepa, 2007, s. 17)

13 2.4 Objektový přístup Objektový přístup V dřívější době byl hlavním přístupem pro vývoj programovacího kódu strukturovaný přístup. Tato metoda vývoje kódu byla řešena shora dolů. Tento aspekt přinášel u menších projektů přehlednost zdrojového kódu a při využívání funkcí bylo možné dosáhnout i jisté znovupoužitelnosti části kódu. Strukturovaný přístup se však u větších projektů ukázal jako nevyhovující. Se složitějším projektem prudce narůstá nepřehlednost zdrojového kódu a manipulace se stejnými daty systému je realizována na mnoha místech kódu. Z výše uvedených důvodů se začal používat objektově orientovaný přístup, který problémy strukturovaně orientovaného přístupu eliminuje. Při používání objektového přístupu se značně zvyšuje znovupoužitelnost částí systému nebo dokonce jeho celku. Tento postup umožňuje vytvářet systémy, které jsou ze stabilnějších celků (objektů) nežli jsou klasické funkce ve strukturovaných jazycích. Případné problémy nebo změny v aplikacích se podstatně lépe řeší v objektových systémech, protože každý objekt nese svou odpovědnost za určitou problematiku, a proto není třeba změny provádět na mnoha místech aplikace. (Kanisová, Müller, 2004, s. 50) Další velikou výhodou objektového přístupu je jeho modelování prostřednictvím jazyka UML Objekt Objekt je seskupením dat a funkcionality, které jsou spolu spojeny za účelem plnění soudržné množiny zodpovědností. (Kanisová, Müller, 2004, s. 50) Objekty systému jsou založeny na abstrakci prvků reálného světa. Tak jako prvky reálného světa, mají objekty své vlastnosti a chování. V objektovém přístupu vlastnosti představují atributy objektu a chování je determinováno metodami objektu. Charakteristika objektu je taková, že uživatel objektu nevidí do nitra objektu, ale zajímají ho pouze informace, které poskytuje okolí. U objektů je možné definovat tři základní vlastnosti. Zapouzdření s objektem je možné pracovat jen prostřednictvím jeho vlastního rozhraní (metod objektu). Dědičnost představuje vztah dvou objektů. Tento vztah říká, že jeden objekt dědí všechny metody a atributy jiného objektu. Polymorfismus pokud několik objektů poskytuje stejné rozhraní, pracuje se s nimi stejným způsobem, ale jejich konkrétní chování se liší podle implementace. (Wikipedia Objektově orientované programování, 2010) Třída Třída v sobě zahrnuje jednotlivé objekty. Třída pouze definuje metody a atributy jednotlivých objektů. Až při vytváření těchto objektů jsou jim přiřazovány skutečné hodnoty. Třída objektů je tedy pouze šablonou jednotlivých objektů. Vztah mezi objekty a třídou znázorňuje Obr. 4 na další straně.

14 2.5 Unifikovaný modelovací jazyk 14 Obr. 4: Objektová třída a objekty (Kanisová, Müller, 2004, s. 51) 2.5 Unifikovaný modelovací jazyk Popis a historie UML Jazyk UML (Unified Modeling Language) je nástroj, který umožňuje efektivně modelovat systémy objektově orientovaným způsobem. Modelovací jazyk UML je souhrnem především grafických notací k vyjádření analytických a návrhových modelů. UML je jazyk, který umožňuje modelovat jednoduché i složité aplikace pomocí formální syntaxe, a proto můžete výsledky své práce sdílet s ostatními návrháři. Vybrané modely jsou pochopitelné i pro zadavatele aplikace a umožní kvalitní vyjasnění požadavků na vytvářený systém. Žádný diagram nezachycuje navrhovaný systém jako celek, ale soustředí se vždy právě na jeden pohled na vyvíjený celek. (Kanisová, Müller, 2004, s. 13) Jazyka UML začal být vyvíjen v roce 1994 pracovníky společnosti Rational Software Gradym Boochem a Jimem Rambaughem. V této době se oba zmínění analytici zabývali metodou Object Modeling Technique. O rok později příchodem Ivara Jacobsona do společnosti Rational Rose byla podpořena koncepce zabývající se objektovým modelováním. Ivar Jacobson se v té době zabýval metodikou Object Oriented Software Engineering. Výsledkem práce těchto tří pracovníků firmy Rational Rose začal postupně sjednocováním různých nekompatibilních metodik vznikat základ jazyka UML. V roce 1997 spatřil světlo světa modelovací jazyk UML ve své první verzi 1.1 a byl přijat jako standard. Postupem času se jazyk rozvíjel a upřesňoval až do současné verze UML 2.1, která přináší zejména upřesnění modelovacích možností Diagramy podnikových procesů Modelování podnikových procesů je jednou z nejdůležitějších částí každého projektu. Je vhodné před samotným modelováním případů užití začít s popisem podnikových procesů modelované společnosti. Diagram podnikových procesů (Business Process Model) a vůbec procesní analýza může být užitečná při odhalení některých funkcí

15 2.5 Unifikovaný modelovací jazyk 15 modelovaného systému, které jsou zpočátku skryty. Pokud procesní modelování vynecháte a začnete ihned UML technikou modelování případů užití, vystavujete se riziku, že budete pouze sestavovat model případů užití ze seznamu požadavků a nebudete jej vhodným způsobem za účasti zákazníka usměrňovat. (Kanisová, Müller, 2004, s. 26) Je nutno podotknout, že metodika modelování podnikových procesů není přímo ve standardu modelovacího jazyka UML. Procesní analýza je však důležitou částí tvorby systému a je velmi často využívána. Existuje řada přístupů k modelování podnikových procesů. Jedním z nejpoužívanějších přístupů pro modelování v jazyce UML je přístup H. Erikssona. Řepa (2007, s. 149) uvádí čtyři základní pohledy na organizaci podle profilu H. Erikssona. Strategický pohled (vizorganizace) zahrnuje klíčové pojmy hodnoty firmy a její strategické cíle. Zaměřuje se na hlavní problémy a úmysly, které mají být procesní změnou řešeny. Procesní pohled zahrnuje podnikové procesy, činnosti v organizaci a hodnoty, které tyto aktivity vytvářejí. Popisuje vzájemnou spolupráci procesů a využívání zdrojů za účelem dosažení strategických cílů definovaných ve vizorganizace. Strukturní pohled (Struktura organizace) zahrnuje zdroje organizace jako jsou organizační jednotky, produkty, dokumenty, informace, znalosti atd. Chování organizace zahrnuje jak vnitřní chování, tak interakci jednotlivých prvků organizace (zdroje a procesy). Jedním nejdůležitějších cílů analýzy interakcí je přiřazení odpovědnosti za jednotlivé zdroje. Erikssonův přístup je nejenom rozšířením UML, ale do značné míry i plnohodnotnou metodou modelování procesů určuje sadu modelů a diagramů, postavených vesměs na standardních diagramech UML. (Řepa, 2007, s. 150) Je vhodným prostředkem pro modelování fáze systému před vývojem. Je tedy modelem, který nám vhodně popíše komplexně celou organizaci pro kterou bude informační systém vyvíjen. Diagram podnikových procesů typicky definuje následující elementy: (Enterprise Architect User Guide, 2009) cíl nebo důvod procesu specifické vstupy specifické výstupy spotřebované zdroje aktivity, které jsou vykonávány v určitém pořadí události, které řídí proces V diagramech podnikových procesů se mohou u vazeb vyskytovat následující stereotypy. Input značí, že objekt, který do procesu vstupuje je zdroj, který je při zpracování v procesu spotřebován.

16 2.5 Unifikovaný modelovací jazyk 16 Supply informace nebo objekt vstupující do procesu není přímo použit, je to jen jakýsi příklad nebo šablona. Goal určuje cíl procesu. Ukázka všech elementů diagramu podnikových procesů včetně stereotypů vazeb je ilustrována na Obr. 5. Obr. 5: Elementy diagramu podnikových procesů (Enterprise Architect User Guide, 2009) Diagramy případů užití Diagramy případů užití (Use Case diagramy) slouží k modelování interakce uživatele se systémem. Základní prvky diagramu případů užití jsou následující. Případy užití zachycují přesně funkčnost, která bude budoucím informačním systémem pokryta a vymezují tak jednoznačně rozsah prací. Každý případ užití popisuje jeden ze způsobů použití systému, popisuje tedy jeho požadovanou funkčnost. (Kanisová, Müller, 2004, s. 33) Aktéři představují budoucí uživatele systému, který modelujeme. Každý aktér má svoji stanovenou roli ve které bude komunikovat se systémem. Roli aktéra může plnit i jiný systém. Znázornění prvků v modelu ilustruje Obr. 6, kde Aktér plní uživatelskou roli směrem k případu užití. Aktéři tedy provádí případy užití. V této souvislosti je třeba zmínit, že jeden aktér může provádět více případů užití. A v opačném směru může více aktérů provádět jeden případ užití. Obr. 6: Ukázka aktéra a případu užití

17 2.5 Unifikovaný modelovací jazyk 17 Jak bylo uvedeno výše, případ užití představuje funkčnost systému. Případ užití nepřestavuje nic jiného než určitý scénář popisující jednotlivé kroky interakce s aktérem. Hlavním nástrojem jak popsat případ užití je jeho scénář, dále jsou pro popis případu užití určeny některé diagramy, které budou popsány dále. Přesněji řečeno se nejedná o scénář, ale o sadu scénářů. Případ užití může mít také alternativní scénáře a odkazy na jiné scénáře. Zpravidla také případy užití alternativní scénáře mají. Při vytváření komplikovanějších scénářů je však třeba si uvědomit, že scénáře mají být transparentní a přehledné. Součástí pravidel mohou být také sjednané konstrukce v podobě jakéhosi metajazyka, které stručně a srozumitelně vyjadřují větvení podmínek, jako např. KDYŽ POTOM JINAK, případně vyjadřují opakování skupiny činností ve scénáři, dokud je splněna nějaká podmínka, např. PRO podmínka... (Kanisová, Müller, 2004, s. 37) V diagramech případů užití neexistují pouze vztahy aktér případ užití. Jazyk UML umožňuje i vztahy mezi dvěma případy užití. Tyto vztahy mohou být následujících typů: relace include generalizace případů užití relace extend Obr. 7: Relace typu include a extend (Kanisová, Müller, 2004, s. 43) Generalizace nebo-li zobecnění případů užití umožňuje chování více případů užití převést do rodičovského případu užití. Tento vztah se však v praxi příliš nepoužívá, protože způsobuje nepřehlednost diagramu případů užití. Zhoršuje také způsob chápání takto generalizovaných případů užití. Vazba include se v diagramu případů užití používá tam, kde se vyskytuje podobná nebo stejná část scénáře a opakuje se v jiných scénářích. Vazba typu extend přidává rozšiřující nové doplňkové chování do základního případu užití. Podstatným rozdílem oproti relaci typu include však je, že základní případ užití je sám o sobě zcela soběstačný. (Kanisová, Müller, 2004, s. 43)

18 2.5 Unifikovaný modelovací jazyk 18 Ukázka použití relací extend a include je na Obr. 7. V této situaci je vazba include použita protože v budoucím systému bude možné přidat nový spotřebič samostatně bez použití případu užití Přidat nového výrobce. Přidat nový stát ovšem nepůjde bez předchozího spuštění případu užití Přidat nového výrobce Diagramy tříd Diagram tříd je základním modelem vyjadřujícím strukturu a vztahy mezi objektovými třídami navrhovaného informačního systému. Tento diagram je modelem statické části systému. Je v úzké souvislosti s datovou stránkou informačního systému. Po modelování diagramu tříd je možné jednotlivé třídy převést do datové struktury navrhovaného informačního systému v podobě entitně relačního diagramu. Podle Kanisové a Müllera (2004, s 51) je struktura tříd založena na dvou principech, na zodpovědnosti třídy a na zapouzdření třídy. Zodpovědnost třídy je jedním z klíčových faktorů objektově orientované analýzy a návrhu a znamená, že námi definovaný objekt nese zodpovědnost za danou problematiku a žádný jiný objekt se nesmí plést do této zodpovědnosti. Jak již bylo zmíněno, objekty (respektive třídy) mají své atributy a metody. Atributy tříd jsou nositeli informací o objektu. Mají své jméno a stanovený obor přípustných hodnot, kterých mohou nabývat. Bývají používány formáty, které jsou běžné v programovacích jazycích (např. integer, boolean, date, string,... ). Atributy jsou rozděleny také podle své viditelnosti okolními objekty. Rozdělení viditelnosti objektů podle Kanisové a Müllera (2004, s 51) v jazyce UML. Public veřejný přístup: kterýkoliv element systému může k těmto atributům přistupovat. Private soukromý přístup: k atributům mají přístup pouze operace implementované v dané třídě. Protected chráněný přístup: k atributům mají přístup pouze operace implementované v dané třídě a v potomcích třídy. Zatímco atributy třídy definují statickou část objektu, operace definují dynamickou část objektu jeho chování. Operace tříd nebo-li metody jsou také definovány svým jménem. Dále mohou mít definovány vstupní parametry (včetně hodnot kterých mohou nabývat) a návratovou hodnotu. V diagramu tříd mohou být modelovány následující vazby tříd. 1. Asociace obousměrná vazba, pokud není explicitně definovaná jako jednosměrná. Tato vazba představuje vztah jedné třídy s druhou třídou. Tyto vztahy v diagramu tříd mohou mít také volitelnou násobnost.

19 2.5 Unifikovaný modelovací jazyk 19 Obr. 8: Vztah typu asociace 2. Agregace typ vazby, který říká, že jedna třída je částí druhé třídy. U agregace má jeden objekt významnější roli než druhý objekt. Významnější objekt může mít přístup k metodám a atributům toho druhého objektu. Obr. 9: Vztah typu agregace 3. Kompozice silnější forma agregace. Nachází užití v případech, kdy třída, která je částí jiné třídy nemůže bez své nadřazené třídy existovat. Obr. 10: Vztah typu kompozice 4. Generalizace představuje dědění tříd. Používá se pokud třída nebo více tříd obsahuje prvky jiné třídy. Jedná se tedy o to, že potomek dědí vlastnosti předka. Obr. 11: Vztah typu generalizace

20 2.5 Unifikovaný modelovací jazyk Specializace přesně opačný vztah jako generalizace Diagramy aktivit Diagramy aktivit slouží k modelování chování jednoho objektu za případu, že jeho chování prochází více vlákny. Diagram aktivit (Acticity diagram) zobrazuje sekvenci aktivit, které podporují jak sekvenční tak paralelní chování (Kanisová, Müller, 2004, s. 91). U těchto diagramů je vhodné dodržovat jejich jednoduchost a přehlednost. Je tomu tak zejména protože mají vysvětlit chování části systému tak, aby jim byli schopni porozumět i lidé pracující ve společnosti, pro kterou je systém vyvíjen. Diagramy aktivit jsou schopny zachytit paralelní chování procesů. Tento fakt je jejich velikým přínosem pro modelování chování systému. Jejich použitelnost je zejména tam, kde chceme vyjádřit chování objektů, které v procesním modelování mají paralelní vlákna. Neměly by ovšem být používány pro modelování chování více objektů zároveň nebo chování objektů v průběhu jejich životního cyklu. Pro tento účel jsou určeny jiné diagramy jazyka UML. Kanisová a Müller (2004, s 91) rozdělují základní symboly diagramů aktivit následovně: 1. Akce elementární, dále nedělitelná jednotka. Za aktivitu je možné považovat stav dělání čehokoliv. Aktivitu nelze přerušit jednou zahájená aktivita musí být dokončena. Mají jeden vstupní a jeden výstupní přechod. Aktivita je v diagramu znázorněna obdélníkem se zaoblenými rohy. Speciálními druhy aktivit jsou zahájení a ukončení diagramu aktivit. Ukázka symbolů pro aktivity vyskytující se v diagramu aktivit je na Obr. 12. Obr. 12: Symboly pro aktivity 2. Přechody mezi jednotlivými stavy dochází k přechodům. Tyto přechody nastávají automaticky bezprostředně po ukončení akce. Symbolem pro přechod je šipka od jednoho stavu k druhému.

21 2.5 Unifikovaný modelovací jazyk 21 Obr. 13: Hodnocení přechodů 3. Hodnocení přechodů představuje logickou podmínku, která podmiňuje vstupující přechod. Hodnocení přechodů (někdy se používá výraz rozhodnutí ) je podstatným prvkem diagramu aktivit. Umožňuje do diagramů aktivit zakomponovat základní rozhodovací prvek, s kterým se můžeme setkat při psaní zdrojových kódů aplikací. Do hodnocení vstupuje jeden přechod a vystupuje z něj více přechodů. Každý vystupující přechod má stanovenou podmínku. Symbol hodnocení (kosočtverec) je používán i pro sloužení více přechodů do jednoho. Ukázka jednoduchého diagramu s použitím hodnocení přechodu je na Obr. 13.

22 2.5 Unifikovaný modelovací jazyk 22 Obr. 14: Rozvětvení přechodů (Kanisová, Müller, 2004, s. 95) 4. Rozvětvení umožňuje modelovat paralelní chování. Při větvení v diagramu aktivit dochází k rozvětvení přechodu na několik paralelně běžících vláken, která jsou vzápětí opět spojena. Při modelování paralelních přechodů se pro rozvětvení a opětovné spojení používá stejného symbolu (horizontální čára). V okamžiku aktivace vstupního přechodu jsou aktivovány všechny výstupní přechody rozvětvení. Ukázka jednoduchého diagramu se souběžnými vlákny je na Obr. 14.

23 2.5 Unifikovaný modelovací jazyk 23 Obr. 15: Plavecké dráhy (Kanisová, Müller, 2004, s. 96) 5. Plavecké dráhy umožňují jednotlivým aktivitám v diagramu přiřadit objekty, které tyto aktivity provádí. Pro efektivní znázornění plaveckých drah v diagramu aktivit je nutné aktivity upravit do vertikálních pruhů, které představují ony plavecké dráhy. Tyto dráhy jsou v diagramu odděleny svislými pruhy. Každá dráha potom představuje množinu aktivit, které jsou přiřazeny jednomu objektu modelovaného systému. Ukázka použití plaveckých drah je na Obr. 15.

24 2.5 Unifikovaný modelovací jazyk Sekvenční diagramy Sekvenční diagramy se řadí pod skupinu modelů, které se zabývají interakcí objektů. Sekvenční diagramy spadají pod dynamickou část systému. Modelují tedy chování navrhovaného informačního systému. S touto problematikou systému úzce souvisejí případy užití. Sekvenční diagramy jsou v podstatě namodelované scénáře jednotlivých případů užití. V těchto diagramech modelujeme aktéry (které známe z diagramů případů užití) a jejich interakci se systémem. Z každého objektu v diagramu vede svislá čára, představující život objektu v daném případu užití. Této čáře se proto říká čára života objektu. Zprávy mezi objekty a aktéry v systému jsou zobrazovány čárou zakončenou plnou šipkou. Zprávy začínají a končí na čáře života objektů v modelu. Sekvenční diagramy mohou obsahovat také znázornění navrácení aktivity původně volajícímu objektu. Tento návrat bývá znázorněn přerušovanou čárou. Takovéto návraty však bývají v modelu využívány zřídka, protože způsobují nepřehlednost modelu. Další nepříliš využívanou komponentou sekvenčních diagramů je symbol pro zrušení objektu. V těchto diagramech je také možné využít zobrazení paralelních zpráv, které se značí poloviční šipkou. Doporučenou technikou při modelování sekvenčních diagramů je využívání popisků jednotlivých akcí v diagramu. Tato metoda napomáhá pochopení chování sekvenčního diagramu. Je užitečná zejména pokud je diagram v určitých místech ne zcela jednoznačný. Při popisech chování diagramu je možno využít i větvení, cykly a podobné konstrukty známé při programování. Jednou z nejtěžších věcí při porozumění objektově orientovanému programu je pochopení celkového toku řízení. Dobrý návrh respektuje rovnoměrně distribuovanou inteligenci systému v podobě množství relativně jednoduchých metod v rozdílných třídách. Bývá zpravidla složité zachytit celkovou sekvenci chování. Sekvenční diagramy jsou rozhodně nástrojem, který vám pomůže tyto sekvence nalézt. (Kanisová, Müller, 2004, s. 65) Následující obrázek demonstruje některé prvky sekvenčního diagramu. Jedná se o příklad internetového obchodu obsluhovaného zákazníkem.

25 2.5 Unifikovaný modelovací jazyk 25 Obr. 16: Ukázka sekvenčního diagramu (Enterprise Architect User Guide, 2009)

26 3 VLASTNí ŘEŠENí 26 3 Vlastní řešení 3.1 Psychiatrická léčebna Brno Historie Psychiatrická léčebna v Brně-Černovicích byla založena v roce Založení této léčebny mělo z historického hlediska významný vliv na rozvoj ústavní psychiatrie na našem území. Bylo to první zařízení svého druhu na Moravě. Zařízení léčebny a používané metody léčby byly na svou dobu velice moderní. Z těchto důvodů se Brněnská psychiatrická léčebna stala vzorem pro budování podobných zařízení na území tehdejšího Rakousko-Uherska, kterého jsme byli součástí. Založení léčebny mělo veliký význam, protože poprvé v historii bylo duševně nemocným na Moravě umožněno dostat patřičnou lékařskou péči specializovaných pracovníků. Léčebné metody v celé Evropě procházely v průběhu let významným vývojem. Pokrok v léčebných metodách prošel různými vývojovými etapami, které se nevyhnuli ani Psychiatrické léčebně v Brně. Metodika léčby pacientů se měnila a přibývalo různých nových specializovaných pracovišť. Byly objevovány stále nové diagnózy, pro jejichž léčbu bylo třeba vytvořit odpovídající léčebné prostředí. Z původně koridovaných staveb postupně začaly vznikat pavilony, jejichž kapacita se postupně zvyšovala z počátečních 330 pacientů až na 1300, aby se ustálila na současných 830 lůžkách Popis a specializace Psychiatrická léčebna v Brně je odborným léčebným ústavem. Je řízena Ministerstvem zdravotnictví, které je jejím zřizovatelem. Finanční prostředky pro svoji činnost získává z úhrad za poskytnutou zdravotní péči od zdravotních pojišťoven, zřizovatele, Krajského úřadu Jihomoravského kraje, Magistrátu města Brna, občanů a právnických osob, z jiných příspěvků, darů a vlastní činnosti. Léčebna má v současnosti kapacitu 830 hospitalizovaných pacientů o které se stará zhruba 650 pracovníků. Podle závazného opatření Ministerstva zdravotnictví o stanovení spádových území psychiatrických léčeben poskytuje léčebna: komplexní psychiatrickou lůžkovou péči obyvatelstvu spádového území lůžkovou psychiatrickou péči dospělým nemocným se všemi druhy psychických poruch ústavní ochrannou léčbu sexuologickou, psychiatrickou, protitoxikomanickou a protialkoholní včetně kombinovaných druhů ambulantní péči v oborech psychiatrie, neurologie, interna, psychoterapie, AT konziliární služby v oborech dermatovenerologie, chirurgie, gynekologie, TRN, ORL, oftalmologie, sexuologie, ortopedie a pedopsychiatrie Psychiatrická léčebna taktéž poskytuje zdravotní péči v oborech: klinická biochemie a hematologie

27 3.2 Analýza současného stavu 27 radiodiagnostika praktické lékařství pro dospělé a závodní preventivní péči stomatologie vnitřní lékařství TBC a respirační nemoci psychiatrická rehabilitace psychiatrické denní sanatorium kluby nemocných Mezi další činnosti na úseku zdravotní péče patří provozování dopravní zdravotní služby, protialkoholní záchytné stanice a ústavní lékárny. 3.2 Analýza současného stavu Úvod do problematiky rozpisů služeb Informační systém je určen pro zjednodušení a zrychlení práce zaměstnancům psychiatrické léčebny. Tento systém je určen pro navrhování a správu rozpisů služeb pracovníkům na jednotlivých odděleních léčebny. V této léčebně je několik desítek oddělení, které se liší svým zaměřením léčby pacientů a mají proto různá personální obsazení. Personál většiny oddělení sestává z ošetřovatelů, zdravotních sester a jedné staniční sestry. Hlavní sestra má na starosti několik oddělení a stará se o personální otázky. Na oddělení bývají podle typu a zaměření péče o pacienty dále ošetřující lékaři a psychologové. Pracovníci na odděleních, kterých se týká rozpis služeb jsou zdravotní sestry, ošetřovatelé a staniční sestra. Zdravotní sestry a ošetřovatelé pracují v jednosměnném nebo třísměnném provozu v závislosti na druhu oddělení. Protože jsou oddělení různě velká, jsou různé i požadavky na personální obsazení pro denní službu a noční službu v třísměnném provozu. Pracovník jednosměnného provozu pracuje od 6: 00 do 14: 30 každý všední den. Ve třísměnném provozu se pracovníci střídají v intervalech od 6: 00 do 18: 00 (denní služba) a od 18: 00 do 6: 00 (noční služba). Staniční sestra je zodpovědná za vytvoření rozpisu služeb pro pracovníky na svém oddělení. Její povinností je vytvořit rozpis služeb, který bude vyvážený z hlediska množství odpracovaných hodin v normálním provozu a také ve zvýhodněných dnech jako jsou víkendy a svátky. Musí přitom dbát na požadavky pracovníků na dovolenou a jejich případnou pracovní neschopnost. Při vytváření rozpisu služeb je zapotřebí dbát i ostatních faktorů. Faktory ovlivňující rozpis služeb. Požadavky pracovníků. Množství odpracovaných hodin vzhledem k normě. Množství odpracovaných hodin o víkendu, svátcích a nočních službách, které jsou finančně lépe ohodnoceny. Poměr denních služeb a nočních by měl být u všech pracovníků vyvážený. Pracovníci, kteří mají v jeden den stejnou službu by měli být obměňováni tak, aby příští službu měli s někým jiným.

28 3.2 Analýza současného stavu 28 V jednom týdnu by měl mít pracovník alespoň 3 služby. Služby by měly být rozloženy rovnoměrně po celém měsíci. Je v zájmu staniční sestry, aby pracovníci na oddělení byli co možná nejvíce spokojení a věnovali se zodpovědně své práci. Důležitým aspektem, který spokojenost pracovníků na oddělení ovlivňuje je jejich rozpis služeb. Staniční sestra by měla vyhovět požadavkům pracovníků na rozpis v co největší míře. Pokud nastane situace, že některému vyhoví a některému naopak ne, je pro dobrou atmosféru mezi pracovníky vhodné vysvětlit důvod. Pracovníkovi, kterému nebylo vyhověno je vhodné vyhovět příští měsíc. Zaměstnanci léčebny jsou peněžně ohodnoceni podle počtu odpracovaných hodin. Pracovníci v třísměnném provozu si proto v rozpisu služeb ověřují, zda nejsou ve srovnání s ostatními pracovníky na oddělení znevýhodněni. Největší důraz je kladen na hodiny odpracované ve finančně lépe ohodnocených dobách. Nejlépe ohodnocené jsou služby v den, který je státní svátek, následuje služba o víkendu a nejméně ohodnocený je všední den. Noční služba je také lépe ohodnocena než denní služba. Lépe ohodnocené odpracované hodiny jsou proto pracovníky přirozeně preferovány. Samostatnou kapitolou jsou noční služby. Noční služba je rozdělena a započtena do dvou dnů. Noční služba má 12 hodin, ale z toho je půl hodiny neplacené přestávky, která se do souhrnu nezapočítává. Službu je možné rozdělit pouze po 30 minutách. Z toho vyplývá, že je rozdělena na 6 hodin a 5,5 hodiny. Pracovník samozřejmě upřednostňuje mít započítáno 6 hodin v den, který je lépe ohodnocený a 5,5 hodiny v hůře ohodnocený den. Při vytváření nového rozpisu služeb je nutné přičíst zbytek nožní služby z minulého měsíce. Oddělení můžou mít různou kapacitu pacientů. Od kapacity pacientů a náročnosti péče o ně se odvíjí množství zdravotních sester a ošetřovatelů, kteří souběžně vykonávají službu. Na některých odděleních může být požadavek na jednu zdravotní sestru na den, na jiných odděleních může být požadavek vyšší. Stejná situace je u ošetřovatelů pracujících v třísměnném provozu. Pro dobré pracovní vztahy mezi zaměstnanci na oddělení je žádoucí, aby se ve službách střídali tak, že se jejich kolegové nebudou stále opakovat. Jinými slovy, pokud bude sestra vykonávat službu s určitou sestrou nebo ošetřovatelem, příští službu by měla vykonávat s jinou sestrou nebo ošetřovatelem. Pokud by se ve službě příliš často opakovali stejní lidé bez obměny mohla by vznikat mezi pracovníky tzv. ponorková nemoc. A nebo by naopak mohlo v kolektivu vznikat nechtěné rozdělení pracovníků do týmů na úkor ostatních pracovníků a pacientů. Oba tyto jevy jsou nežádoucí a při vytváření nového rozpisu služeb je třeba je zohlednit. Pracovníci na oddělení by měli mít v průběhu měsíce, pro který je rozpis vytvářen služby rovnoměrně rozloženy. Je nežádoucí aby docházelo k případům, že pracovník má v jednom týdnu např. 5 služeb a v dalším pouze 2. Ideální rozložení je takové, ve kterém jsou pro každý týden rozpisu pracovníkovi přiděleny alespoň 3 služby. V rozpisu služeb mohou také nastat chyby, kterých je nutné se vyvarovat. Tyto chyby mohou být dvou typů. Jedním z nich jsou chyby, které jsou nepřípustné a vy-

29 3.2 Analýza současného stavu 29 cházejí přímo ze Zákoníku práce. Pokud rozpis služeb obsahuje tyto chyby, není možné ho použít pro stanovení služeb pracovníků. Chyby, které mohou v rozpisu nastat jsou následující. 1. Následují po sobě tři služby stejného typu. 2. Následuje denní služba ihned po noční. 3. Na pracovišti není stanovený počet pracovníků. Zatímco první dvě chyby není možné při vytváření rozpisu tolerovat, protože nejsou v souladu se zákonem, třetí chyba v rozpisu je za určitých podmínek akceptovatelná. Při vytváření rozpisu pro oddělení může nastat situace, kdy je nedostatek personálu. Jestliže nastane takováto situace, je možné místo služby určené pro ošetřovatele přiřadit službu zdravotní sestře. Službu může v nouzovém případě vykonat i zdravotní sestra pracující za normálních okolností v jednosměnném provozu nebo staniční sestra. Za normálních okolností je však nesprávný počet jednotlivých pracovníků vykonávajících službu na oddělení považován za chybu Analýza podnikových procesů Pro komplexní objasnění všech podnikových procesů, které jsou podstatné pro vytváření rozpisů služeb pro jednotlivá oddělení jsem zvolil diagram podnikových procesů (Obr. 17). Pro jeho modelování jsem použil rozšíření jazyka UML podle H. Erikssona. Jednotlivé pracovníky léčebny představují aktéři v modelu. Souhrn procesů determinujících vytváření nového rozpisu pro jedno oddělení začíná přijmutím pacientů pro toto oddělení. Pacient může přijít dobrovolně nebo být eskortován na příjmové oddělení léčebny. Zdravotní sestra, která má službu na příjmovém oddělení od Pacienta zjistí všechny základní údaje (jméno, bydliště, minulou hospitalizaci,... ). Údaje jsou zapsány do Karty pacienta. Následně je Pacient odborně vyšetřen Doktorem vykonávajícím službu na příjmovém oddělení. Pacientovi je na základě vyšetření Doktorem stanovena diagnóza a zapsána do Karty pacienta. Karta pacienta tedy obsahuje všechny důležité údaje, které je nutné o pacientovi uchovávat. Doktor na základě zjištěných informací určí, které Oddělení, je pro Pacienta vhodné. Zdravotní sestra na příjmu zjistí, zda je na Oddělení volné lůžko. Pokud je volné lůžko Pacient je přiřazen pod stanovené Oddělení. Na základě průměrného počtu Pacientů a složitosti péče o ně Hlavní sestra určí Personální požadavky jednotlivých oddělení. V této fázi je pro každé oddělení určeno kolik zdravotních sester a ošetřovatelů je nutných pro úspěšný chod oddělení. Pro účely systému je Oddělení a jeho kapacita vytvořena Administrátorem. Jednotlivá Oddělení jsou personálem vyplněná následovně. Do léčebny jsou přijati Pracovníci na základě Personálních požadavků oddělení, které stanovila Hlavní sestra. Ti při přijímání do zaměstnání vyplní své Základní údaje (jméno, praxi, vzdělání,... ). Tyto údaje jsou hlavním faktorem rozhodujícím o jejich následovném umístění na specializovaná oddělení. Na základě Personálních požadavků oddělení a Základních údajů pracovníků přiřadí Hlavní sestra jednotlivé Pracovníky na vhodná Oddělení. Pracovníci potom na těchto odděleních mohou vykonávat služby.

30 3.2 Analýza současného stavu 30 Vždy v polovině měsíce vzniká Požadavek na nový rozpis služeb pro příští měsíc. Nový rozpis služeb je tedy nutné vytvářet dostatečně dopředu, aby měli pracovníci, kterých se rozpis týká včasný přehled o službách v příštím měsíci. Proces vytváření Nového rozpisu služeb začíná vložením Osobních požadavků pro nový rozpis pracovníků (dovolená, volno, návrhy na služby,... ). Staniční sestra požadavky pracovníků vyhodnotí a na základě nich vytvoří Nový rozpis služeb pro vlastní oddělení. Je plně v kompetencích Staniční sestry požadavkům pracovníků vyhovět, či nikoliv. Po úspěšném vytvoření si mají možnost všichni pracovníci oddělení Rozpis služeb oproštěný od chyb a nedostatků Vytisknout Současné řešení procesů Procesy spadající pod správu pacientů, oddělení a pracovníků jsou v léčebně řešeny interním informačním systémem. Správa rozpisů služeb však řešena informačním systémem není. V dalším průběhu práce již nebudu správu pacientů zahrnovat do mnou navrhovaného systému. Správa oddělení, pracovníků a pacientů je vyhovujícím způsobem v systému léčebny již zahrnuta. Do diagramu podnikových procesů jsem tyto části zahrnul, abych demonstroval současný stav v léčebně. Správa rozpisů služeb (hlavně část jeho vytváření) je složitým procesem, který je bez počítačové podpory pro staniční sestru skutečně náročný. V současné době většina staničních sester léčebny tento problém řeší prostřednictvím papíru a tužky. Pro oddělení, které je větší a slouží na něm větší počet pracovníků, je vytváření rozpisu opravdu dlouhou a nepříjemnou událostí, která se opakuje každý měsíc. Problémů však ještě přibývá v případě, že je rozpis hotový a v průběhu měsíce některý pracovník onemocní. Pokud nastane tato situace, je nutné rozpis celý přepracovat a složitě přepočítat.

31 3.2 Analýza současného stavu 31 Obr. 17: Diagram podnikových procesů

32 3.3 Návrh nového řešení Návrh nového řešení Specifikace požadavků Jak jsem již uvedl v teoretické části této práce, specifikace požadavků navrhovaného systému je jednou z nejdůležitějších částí vývoje. V této části vývoje jsou jasně určeny funkce a vlastnosti, které by měl budoucí systém podporovat. Správným specifikováním požadavků na systém je možné předejít mnoha budoucím chybám, které by negativně ovlivnily budoucí chod systému. Specifikace je v podstatě požadavek budoucího uživatele systému. Tyto požadavky je však třeba rozdělit do dvou skupin. Funkční požadavky jsou ty, které specifikují budoucí funkčnost systému. Nefunkční požadavky jsou ty, které specifikují jisté vlastnosti systému, případně podmínky omezující fungování systému. Dále se budu zabývat funkční specifikací. Správa uživatelů Správa uživatelů systému bude přístupná pouze uživateli s právy administrátora systému. Uživatele systému bude možné vyhledávat a vyhledané uživatele řadit podle různých kritérií. Administrátor bude mít ve správě uživatelů možnost všechny údaje již založených uživatelů měnit a nebo uživatele zcela smazat. Další funkcí administrátora bude nové uživatele zakládat. Nově zakládanému uživateli administrátor vyplní jeho jméno, příjmení a číslo pracovníka, které je již v léčebně zavedeno. Při zakládání uživatele mu musí být přiřazena uživatelská skupina, která určuje uživatelská práva v systému. Podle přiřazených uživatelských práv budou uživateli dostupné funkce systému. Rozdělení do uživatelských skupin dále determinuje i pracovní zaměření uživatele, které má význam pro vytváření rozpisů. Uživatelské skupiny se budou dělit na: administrátor staniční sestra zdravotní sestra v třísměnném provozu ošetřovatel v třísměnném provozu zdravotní sestra v jednosměnném provozu ošetřovatel v jednosměnném provozu Další podstatné údaje při zakládání uživatele jsou přihlašovací jméno a heslo do systému. Přihlašovací jméno a heslo uživatele bude možné nechat automaticky vygenerovat systémem. Další možností při zakládání nového uživatele je volba oddělení pod které bude spadat. Systém pude podporovat možnost uživateli oddělení nepřidělit. Pro uživatele, kteří budou přiděleni do oddělení bude možné vytvářet rozpis služeb. Správa oddělení Správa oddělení léčebny bude přístupná pouze uživateli s právy administrátora systému. Administrátor bude mít možnost založit v systému nové oddělení. Při zakládání oddělení vyplní jeho název a číslo oddělení, které představuje číslo budovy v areálu léčebny. Zakládanému oddělení bude nutné stanovit personální požadavky.

33 3.3 Návrh nového řešení 33 Požadavky budou určeny počtem zdravotních sester a ošetřovatelů, kteří jsou denně zapotřebí na oddělení. A dále počtem zdravotních sester a ošetřovatelů, kteří jsou zapotřebí při noční službě na oddělení. Další funkcí dostupné uživateli s uživatelskými právy administrátora bude možnost všechny oddělení souhrnně vypsat. U již založeného oddělení bude moci administrátor systému změnit údaje nebo oddělení zcela smazat. Vytvoření nového rozpisu služeb Tvorba nového rozpisu služeb bude dostupná uživateli s právy administrátora pro všechna oddělení a uživateli s právy staniční sestry pro oddělení, ke kterému je přiřazena. Tvorba nového rozpisu se skládá ze čtyř částí. 1. Zadání základních požadavků v této části uživatel zadá rok a měsíc, pro který bude nový rozpis služeb vytvářen. Uživatel s právy administrátora také zadá číslo oddělení, pro které bude nový rozpis služeb vytvářet. Pokud je pro zadané oddělení a měsíc v roce již rozpis služeb vytvořen, bude uživatel upozorněn a nebude moci pokračovat v další části vytváření rozpisu. 2. Speciální požadavky na rozpis požadavky všech pracovníků a staniční sestry na oddělení, pro které je rozpis vytvářen. Požadavky se tykají především volných dnů, dovolené a pracovní neschopnosti. V této části vytváření nového rozpisu bude možné kdykoliv přepočítat souhrnné údaje týkající se jednotlivých pracovníků. Vypočítávané souhrnné údaje jsou: pracovní norma počet hodin v běžném provozu odpracovaný přesčas počet hodin odpracovaných v noci počet hodin odpracovaných o víkendu počet hodin odpracovaných o státním svátku počet hodin dovolené počet hodin pracovní neschopnosti Do souhrnu budou započítávány i hodiny, které přesahují z noční služby na konci minulého měsíce. Výpočet souhrnných údajů se liší pro pracovníky v třísměnném a jednosměnném provozu. Pokud nově vytvářený rozpis služeb v této fázi obsahuje, chyby systém na ně upozorní a vypíše je (vizčást Úvod do problematiky rozpisů služeb). Protože v této části bude rozpis služeb zajisté obsahovat množství chyb v personálním obsazení, bude umožněno tyto chyby nevypisovat. 3. Úprava rozpisu při přechodu do této části bude podle zadaných kriterií rozpis automaticky doplněn chybějícími službami v rozpisu. Budou vypočítány souhrnné údaje a zjištěny chyby. Uživateli bude umožněno v této části rozpis služeb upravit podle vlastních požadavků. V této části vytváření nového rozpisu bude možné kdykoliv přepočítat souhrnné údaje týkající se jednotlivých pracovníků. Při přepočítání služeb bude uživatel informován o chybách v rozpisu. Chyby, které mohou nastat jsou dvojího typu (vizčást Úvod do problematiky rozpisů služeb). Uživateli bude umožněno pro přechod k další

34 3.3 Návrh nového řešení 34 části ignorovat chyby personálního obsazení. Pokud však bude rozpis služeb obsahovat jiné chyby, systém neumožní přejít do další části vytváření rozpisu. 4. Dokončení rozpisu uživateli budou v této části zobrazena finální verze rozpisu služeb a všechny souhrnné údaje. Uživatel bude moci nový rozpis uložit do databáze a bude informován o úspěchu tohoto uložení. Uložený rozpis bude možné vytisknout. Při každém kroku vytváření nového rozpisu bude uživateli umožněno se vrátit k jakémukoliv předešlému kroku. Uživatel bude v každé části dostatečně informován o průběhu a chybách vytváření nového rozpisu. Správa hotových rozpisů Tato funkce systému bude přístupná, kterémukoliv oprávněnému uživateli systému. Pracovníci, kteří budou přiřazeni do některého založeného oddělení v systému, budou moci vyhledávat služby spadající pod jejich oddělení. Uživatel s právy administrátora bude moci vyhledávat služby všech oddělení v systému. Služby budou vyhledávány prostřednictví měsíce a roku, pro který byl rozpis vytvořen. Administrátor při vyhledávání navíc zadá oddělení, pro které rozpis služeb vyhledává. Po úspěšném vyhledání hotového rozpisu služeb bude mít běžný uživatel možnost rozpis vytisknout. Administrátor a staniční sestra budou mít dále možnost vyhledaný rozpis služeb upravit. Upravený rozpis půjde uložit pouze v případě, že neobsahuje chyby. Chyby personálního obsazení může obsahovat pouze v případě, že byla uživatelem zvolena možnost tyto chyby při ukládání ignorovat. Změna přihlašovacího hesla Funkce umožňující změnu přihlašovacího hesla bude přístupná kterémukoliv oprávněnému uživateli systému. Uživatel zadá své stávající heslo a dvakrát nové heslo. Po odeslání bude informován o úspěchu změny přihlašovacího hesla. Specifikace nefunkčních požadavků V této části jsou uvedeny hlavní omezení systému a jeho vlastností. Údaje uživatelů budou bezpečnostně zajištěny. Především uživatelské heslo bude v databázi uloženo za použití hashovací funkce. Uživatelé nebudou mít přístup k funkcím, které jim nejsou přímo určené. Uživatelské rozhraní bude intuitivní a jednoduché na ovládání Diagram případů užití Diagram případů užití slouží k popisu dynamické části navrhovaného informačního systému. Kromě případů užití zobrazuje aktéry, kteří případy užití používají. Jak jsem již upřesnil výše, v mém navrhovaném řešení budu abstrahovat od části systému, která by řešila správu pacientů. Vzhledem k tomuto faktu diagram užití nezahrnuje některé aktéry použité v diagramu podnikových procesů. Výsledný diagram případů užití zahrnuje jen podnikové procesy týkající se správy pracovníků, správy oddělení a správy rozpisů služeb. Diagram případů užití znázorněný na Obr. 18 ilustruje případy užití týkající se pouze těchto podnikových

35 3.3 Návrh nového řešení 35 Obr. 18: Diagram případů užití

36 3.3 Návrh nového řešení 36 procesů. Jednotliví aktéři mají přesně stanovené funkce, které mohou v systému provádět. Dále je uveden popis aktérů systému. Administrátor pracovník léčebny určený pro správu informačního systému. Má v informačním systému práva pro používání téměř všech funkcí tykajících se správy systému. Je jediným uživatelem systému, který může používat funkce systému týkající se správy uživatelů a oddělení. Staniční sestra vedoucí sestra na přiřazeném oddělení. Pracovní náplní staniční sestry je zajistit materiální i personální vybavenost celého oddělení. Stará se o bezproblémový chod oddělení. Je pracovníkem zodpovědným za správu rozpisů služeb pro oddělení, na kterém pracuje. Staniční sestra rozhoduje o tom jestli bude vyhověno požadavkům ostatních pracovníků na rozpis služeb. Pracovník zahrnuje ostatní pracovníky na oddělení. Jedná se o zdravotní sestry a ošetřovatele pracující v jednosměnném i třísměnném provozu. Jsou to pracovníci, kteří jediní chodí na noční služby. Zadávají své osobní požadavky na nový rozpis služeb pro oddělení, na kterém pracují. V následující části této práce se zaměřím na popis jednotlivých případů užití z diagramu. K popisu případů užití využiji především scénářů, které dostatečně detailně popisují jejich funkční část. U některých případů užití jsem shledal vhodným doplnění těchto scénářů o sekvenční diagramy. V systému vystupují jen tři aktéři a poměrně malé množství objektů. Modelování sekvenčních diagramů by tedy bylo pro některé případy užití nadbytečné. Scénář je vykonáván v posloupnosti kroků, které jsou ve scénáři očíslovány. V každém ze scénářů případů užití vystupují aktéři vůči systému v rolích. Systém vystupuje vůči aktérům také v určité roli. V části scénáře pojmenované jako akce je popis činností, které jsou uživatelem nebo systémem vykonávány. Pro popis některých akcí jsem použil logických spojek a cyklů, které výstižně napomáhají k pochopení významu akce. K popisu funkčnosti případů užití jsem využil sekvenční diagramy pouze dvakrát. A to u vytváření nového rozpisu a u změny již hotového a uloženého rozpisu. U ostatních případů užití je plně dostačující popis v podobě scénáře. Většina případů užití prochází jen několika kroky a je tedy dostatečně přehledná i bez modelování sekvenčních diagramů. Případy užití prochází jen několika kroky, některé kroky budou však implementačně velmi náročné (např. doplnění nového rozpisu službami). Vytvořit nové oddělení Tento případ užití smí v systému využívat pouze uživatel s administrátorskými právy. Vytvoření oddělení v systému je jednou z prvních operací, které administrátor provede. Bez vytvoření oddělení by nebylo možné přiřazovat pracovníky při jejich vytváření do jednotlivých oddělení. A tedy pro ně v budoucnu vytvářet rozpisy služeb. Pro vytvoření nového oddělení se musí administrátor nejdříve přihlásit do systému. Po přihlášení administrátor vyplní údaje nového oddělení a nové oddělení vytvoří. Nejdůležitějšími údaji jsou číslo oddělení a personální požadavky oddělení.

37 3.3 Návrh nového řešení 37 Číslo oddělení (stejně jako jeho název) administrátor převezme z již fungujícího interního informačního systému léčebny. Personální požadavky oddělení jsou zjištěny od hlavní sestry (není v systému zahrnuta), která je konzultuje se staniční sestrou. Staniční sestra má o svém oddělení větší přehled než hlavní sestra, která je vedoucím pracovníkem pro více oddělení najednou. Staniční sestra však podává požadavky na personální změny hlavní sestře. Podle zadaných personálních požadavků je v budoucnu sestavován nový rozpis služeb. Personální požadavky oddělení představují počty jednotlivých pracovníků, kteří budou vykonávat služby v třísměnném a jednosměnném provozu na stanoveném oddělení. Administrátor při vytváření oddělení zadá počet zdravotních sester a ošetřovatelů, kteří jsou denně zapotřebí na oddělení pro noční službu. Administrátor také zadá počty ošetřovatelů a zdravotních sester potřebných každý den pro denní službu. Personální požadavky pro denní služby a noční služby na stejném oddělení se mohou lišit podle zaměření oddělení. Uvedené požadavky se mohou pro každé oddělení lišit. Oddělení mají různou lůžkovou kapacitu a z té přímo vyplývá personální obsazení oddělení. Péče o pacienty není také na různých odděleních stejně náročná. Příkladem mohou být oddělení pro ochrannou léčbu a geriatrické oddělení. Na oddělení pro ochrannou léčbu je zapotřebí pro každou službu pouze jedna zdravotní sestra a ošetřovatel. Na oddělení geriatrickém, kde je péče o pacienty individuální a náročná je zapotřebí pro každou službu mnohem větší počet zdravotních sester a ošetřovatelů. Tab. 1: Scénář pro případ užití Vytvořit nové oddělení Krok Role Akce 1 Administrátor Přihlásí se do systému. 2 Systém POKUD byl uživatel úspěšné přihlášen s uživatelskými právy Administrátora POTOM zobrazí tlačítko Správa oddělení. 3 Administrátor Zvolí podsekci Správa oddělení a v této podsekci zvolí možnost Nové oddělení. 4 Systém Zobrazí formulář pro přidání nového oddělení. 5 Administrátor Vyplní číslo, název a personální požadavky oddělení a stisknutím tlačítka údaje odešle. 6 Systém Zkontroluje správnost zadaných údajů. POKUD jsou údaje vyplněny špatně NEBO oddělení se zadaným číslem již existuje POTOM nové oddělení neuloží, upozorní uživatele na chyby a vrátí se ke kroku 5 JINAK uloží nové oddělení do databáze a informuje o tom uživatele. 7 Administrátor Odhlásí se ze systému.

38 3.3 Návrh nového řešení 38 Upravit údaje oddělení Tento případ užití smí v systému využívat pouze uživatel s administrátorskými právy. Údaje, které je možné u oddělení měnit jsou pouze název a personální požadavky. Tyto údaje oddělení jsou totožné jako při vytváření nového oddělení a platí pro ně tedy stejná pravidla. Není příliš předpokládáno, že budou údaje jako název a číslo do budoucna měněny. Proto lze měnit pouze název. Atribut vytvořeného oddělení, který se pravděpodobně bude v budoucnu měnit jsou personální požadavky oddělení. Takto bude v budoucnu možné snižovat nebo zvyšovat kapacitu oddělení. Podle upravených personálních požadavků půjde vytvářet nový rozpis služeb s jinými parametry. Tab. 2: Scénář pro případ užití Upravit údaje oddělení Krok Role Akce 1 Administrátor Přihlásí se do systému. 2 Systém POKUD byl uživatel úspěšné přihlášen s uživatelskými právy Administrátora POTOM zobrazí tlačítko Správa oddělení. 3 Administrátor Zvolí podsekci Správa oddělení a v této podsekci zvolí možnost Vypiš oddělení. 4 Systém Vypíše všechna vytvořená oddělení. 5 Administrátor Vybere oddělení, které chce upravit. 6 Systém Zobrazí formulář pro upravení oddělení. 7 Administrátor Upraví název a personální požadavky oddělení a stisknutím tlačítka údaje odešle. 8 Systém Zkontroluje správnost zadaných údajů. POKUD jsou údaje vyplněny špatně 9 Administrátor Odhlásí se ze systému. POTOM údaje oddělení nezmění, upozorní uživatele na chyby a vrátí se ke kroku 6 JINAK údaje oddělení změní v databázi a informuje o tom uživatele. Smazat oddělení Tento případ užití smí v systému využívat pouze uživatel s administrátorskými právy. Do budoucna není příliš předpokládáno, že bude administrátor využívat tuto funkci systému. V léčebně jsou oddělení stejná už několik let a oddělení jsou zakládána spíše nová než rušena stávající. Vzhledem k tomuto faktu je nepravděpodobné, že by byla oddělení mazána, ale systém umožňuje tuto funkci použít v případě nějaké administrátorské chyby. S větší pravděpodobností budou v budoucnu u oddělení upravovány některé údaje.

39 3.3 Návrh nového řešení 39 Tab. 3: Scénář pro případ užití Smazat oddělení Krok Role Akce 1 Administrátor Přihlásí se do systému. 2 Systém POKUD byl uživatel úspěšné přihlášen s uživatelskými právy Administrátora POTOM zobrazí tlačítko Správa oddělení. 3 Administrátor Zvolí podsekci Správa oddělení a v této podsekci zvolí možnost Vypiš oddělení. 4 Systém Vypíše všechna vytvořená oddělení. 5 Administrátor Vybere oddělení, které chce smazat. 6 Systém Vyžádá potvrzení pro smazání oddělení. 7 Administrátor Potvrdí smazání oddělení 8 Systém Smaže oddělení z databáze a uživatelům z tohoto oddělení nastaví žádné oddělení. O úspěchu smazání informuje Administrátora. 9 Administrátor Odhlásí se ze systému. Vytvořit nového uživatele Tento případ užití smí v systému využívat pouze uživatel s administrátorskými právy. Vytváření nových uživatelů by mělo následovat až po založení všech oddělení léčebny v systému. Při vytváření nových uživatelů jim potom bude moci přímo přiřadit oddělení, na kterém pracují. A později pro ně vytvářet rozpisy služeb. Při vytváření nového uživatele systému je však možné mu nepřiřadit oddělení. Je tomu tak z důvodu, že někteří uživatelé v budoucnu do žádného oddělení nemusí patřit (např. administrátor systému). Nebude tedy pro ně potřeba vytvářet rozpis služeb. Při zakládání nového uživatele systému je důležité vyplnit jméno a příjmení pracovníka. Bez zadání těchto údajů není možné nového uživatele vytvořit. Podstatným údajem uživatele je zaměstnanecké číslo. Všichni pracovníci v léčebně mají již přidělena svá jedinečná čísla. Je tedy vhodné tyto čísla využít jako jedinečného poznávacího prvku zaměstnance v systému (primárního klíče v databázi). Dalšími důležitými údaji při vytváření uživatele jsou uživatelské jméno a heslo. Pro co největší zrychlení a zpohodlnění vytváření nového uživatele bude systém umožňovat každému pracovníkovi vygenerovat unikátní uživatelské jméno z jeho příjmení. Avšak administrátor bude moci toto jméno zadat i manuálně podle vlastního uvážení. Další funkcí, která bude administrátorovi zrychlovat vytváření nového uživatele bude přiřazení každému pracovníkovi jako uživatelské heslo jeho zaměstnanecké číslo. Každý pracovník si potom bude moci po přihlášení do systému toto heslo změnit. Zadat heslo bude samozřejmě možné i manuálně. Jedním z nejpodstatnějších údajů, které administrátor při vytváření uživatele vyplní jsou jeho uživatelské práva. Uživatelská práva budou přímo ovlivňovat, které funkce systému budou uživateli dostupné. výběr těchto práv však neslouží pouze k uvedenému účelu. Jsou rozdělena do skupin i podle pracovního zaměření uživa-

40 3.3 Návrh nového řešení 40 telů. Jsou tedy výchozím rozdělením pro vytváření nových rozpisů služeb. Pracovní skupiny jsou následující: administrátor staniční sestra zdravotní sestra v třísměnném provozu ošetřovatel v třísměnném provozu zdravotní sestra v jednosměnném provozu ošetřovatel v jednosměnném provozu Tab. 4: Scénář pro případ užití Vytvořit nového uživatele Krok Role Akce 1 Administrátor Přihlásí se do systému. 2 Systém POKUD byl uživatel úspěšné přihlášen s uživatelskými právy Administrátora POTOM zobrazí tlačítko Správa uživatelů. 3 Administrátor Zvolí podsekci Správa uživatelů a v této podsekci zvolí možnost Nový uživatel. 4 Systém Zobrazí formulář pro přidání nového uživatele. 5 Administrátor Vyplní jméno, příjmení, číslo zaměstnance. Dále zvolí typ uživatele a oddělení ke kterému bude přiřazen. JESTLIŽE u přihlašovacího jména nezvolí možnost Automaticky vygenerovat POTOM vyplní přihlašovací jméno uživatele. JESTLIŽE u hesla nezvolí možnost Automatické POTOM vyplní dvakrát heslo uživatele. Odešle údaje stisknutím tlačítka Vytvořit uživatele. 6 Systém Zkontroluje správnost zadaných údajů. POKUD jsou údaje vyplněny špatně NEBO uživatel se zadaným číslem zaměstnance již existuje NEBO přihlašovací jméno již existuje NEBO zadaná hesla nejsou stejná POTOM nového uživatele nevytvoří, upozorní uživatele na chyby které tomu brání a vrátí se ke kroku 4 JINAK uloží uživatele do databáze a informuje o tom uživatele. 7 Administrátor Odhlásí se ze systému.

41 3.3 Návrh nového řešení 41 Vyhledat uživatele Tento případ užití smí v systému využívat pouze uživatel s administrátorskými právy. Vyhledávání uživatelů v systému vytvořeném pro správu tak velkého množství pracovníků je nutností. Psychiatrická léčebna v Brně zaměstnává v současné době zhruba 650 pracovníků. Bez efektivního vyhledávání by bylo obtížné provádět správu takového množství uživatelů v systému. Vyhledávání uživatelů systému bude navrženo tak, aby bylo možné vyhledané pracovníky přehledně řadit a filtrovat. Při takovémto vyhledávání je nutné zvolit veliké množství parametrů, které výsledné vyhledávání ovlivní. Pracovníky bude možné vyhledávat podle následujících kriterií: příjmení jméno uživatelské jméno zaměstnanecké číslo uživatelská skupina oddělení Vyhledané uživatele je zapotřebí také vhodně seřadit. V případě nalezení většího počtu uživatelů může seřazení podle různých kriterií vyhledávání velice zjednodušit. Základem efektivního vyhledávání je vyhledané jednotky zobrazovat pouze po určitém počtu vyhledaných údajů s možností přejití na další skupinu. Vyhledané údaje bude možné řadit podle následujících kriterií: příjmení uživatelské jméno zaměstnanecké číslo uživatelská skupina oddělení Tab. 5: Scénář pro případ užití Vyhledat uživatele Krok Role Akce 1 Administrátor Zvolí možnost Vyhledat uživatele 2 Systém Vypíše formulář pro vyhledávání a pro řazení nalezených uživatelů. 3 Administrátor Zadá jméno, příjmení, uživatelské jméno a číslo. Dále zvolí oddělení a zaměstnání pro vyhledávání. Volbu potvrdí tlačítkem Vyhledat. 4 Systém Vyhledá v databázi všechny uživatele kteří odpovídají zadaným kritériím a vypíše je. 5 Administrátor Seřadí nalezené uživatele podle vybraných atributů a vybere hledaného uživatele. 6 Systém Zobrazí detailní informace vybraného uživatele a zobrazí tlačítko Smazat uživatele a Upravit údaje.

42 3.3 Návrh nového řešení 42 Smazat uživatele Tento případ užití smí v systému využívat pouze uživatel s administrátorskými právy. Před smazáním uživatele je nezbytné ho nejprve vyhledat (viz případ užití Vyhledat uživatele). Tato funkce je vhodná pro smazání pracovníka při jeho propuštění z léčebny. Smazáním je také možné odstranit administrátorské chyby při vytváření nových uživatelů systému. Pro smazaného uživatele nebude možné vytvářet rozpisy služeb. Tab. 6: Scénář pro případ užití Smazat uživatele Krok Role Akce 1 Administrátor Přihlásí se do systému. 2 Systém POKUD byl uživatel úspěšné přihlášen s uživatelskými právy Administrátora POTOM zobrazí tlačítko Správa uživatelů. 3 Administrátor Zvolí podsekci Správa uživatelů. 4 Administrátor Vyhledá uživatele viz případ užití Vyhledat uživatele. 5 Administrátor Zvolí možnost Smazat uživatele. 6 Systém Vyžádá si potvrzení pro smazání uživatele. 7 Administrátor Potvrdí smazání uživatele. 8 Systém V databázi uživateli nastaví atribut smazán. Informuje uživatele o úspěchu smazání. 9 Administrátor Odhlásí se ze systému. Upravit údaje uživatele Tento případ užití smí v systému využívat pouze uživatel s administrátorskými právy. Údaje uživatele, které může administrátor upravovat jsou stejné, jako údaje při jeho vytváření. Před upravením údajů uživatele je ho nejdříve nutné vyhledat (viz případ užití Vyhledat uživatele). Nejvíce využití tato funkce systému nalezne při přeložení pracovníků na jiné oddělení nebo při změně zapomenutého uživatelského hesla. V léčebně dochází často ke změnám personálu na jednotlivých odděleních. Pracovníci bývají vyměňováni mezi odděleními jeden za druhého velice často. Dochází k tomu ve většině případů pokud některý pracovník dlouhodobě onemocní a nemůže nastoupit do práce. V takovémto případě (kdy se pracovník v budoucnu vrátí) není nutné nabírat nové pracovníky do léčebny. Takováto absence jednoho pracovníka na oddělení bývá zpravidla řešena dočasným přeřazením pracovníka z jiného oddělení. Některé oddělení mívají takový stav pracovníků, že jsou schopny fungovat přesně s tímto počtem. Některé oddělení však mohou krátkodobou absenci jednoho pracovníka přestát bez obtíží (zpravidla větší oddělení s mnoha pracovníky). Takováto oddělení bývají zpravidla zdrojem zaskakujících pracovníků. V některých případech však může nastat situace, že se už delší dobu chybějící pracovník nevrátí zpět. V tomto případě je pracovník, který ho nahradil většinou přidělen na oddělení nastálo.

43 3.3 Návrh nového řešení 43 K výměně pracovníků mezi odděleními nedochází však jen z důvodu nemoci. K výměně dochází i z jiných důvodů. Pracovníci bývají přeřazeni na jiné oddělení i kvůli jejich specializaci. Výjimkou nejsou ani kázeňské přestupky na oddělení. Takovýto pracovník může být přeřazen na jiné oddělení (pokud není rovnou propuštěn). Tab. 7: Scénář pro případ užití Upravit údaje uživatele Krok Role Akce 1 Administrátor Přihlásí se do systému. 2 Systém POKUD byl uživatel úspěšné přihlášen s uživatelskými právy Administrátora POTOM zobrazí tlačítko Správa uživatelů. 3 Administrátor Zvolí podsekci Správa uživatelů. 4 Administrátor Vyhledá uživatele viz případ užití Vyhledat uživatele. 5 Administrátor Zvolí možnost Upravit údaje. 6 Systém Zobrazí formulář pro změnu údajů uživatele. 7 Administrátor Změní požadované údaje uživatele a formulář odešle. 8 Systém Zkontroluje správnost údajů. POKUD jsou údaje vyplněny špatně NEBO zadané přihlašovací jméno již existuje NEBO uživatel se zadaným číslem zaměstnance již existuje NEBO zadaná nová hesla nejsou stejná POTOM údaje uživatele nezmění, upozorní uživatele na chyby které tomu brání a vrátí se ke kroku 7 JINAK změní údaje uživatele v databázi a informuje o tom uživatele. 9 Administrátor Odhlásí se ze systému. Vytvořit nový rozpis služeb Tento případ užití smí v systému využívat uživatel s administrátorskými právy a uživatel s právy staniční sestry. Administrátor má tyto práva přidělena jen pro případ nouzového použití. Není předpokládáno, že administrátor bude jakkoliv zasahovat do správy rozpisů služeb. Dále v práci budu tedy jako uživatele vytvářejícího nový rozpis uvažovat pouze staniční sestru. Staniční sestra je omezena vytvářením rozpisu pouze pro oddělení, kterému je přiřazena. Rozpis služeb je vytvářen na jeden měsíc. Nový rozpis služeb na příští měsíc je nezbytné vytvořit nejpozději do poloviny současného měsíce. Rozpis služeb je vytvářen s takovým předstihem z toho důvodu, aby měli pracovníci včasný přehled o budoucím pracovním nasazení. Mohou si tak pohodlně naplánovat mimopracovní aktivity na celý příští měsíc. Zároveň je dostatečný prostor po zveřejnění rozpisu pracovníkům oddělení na jejich připomínky a případnou úpravu tohoto rozpisu před jeho plněním. Při vytváření nového rozpisu služeb musí staniční sestra zvážit požadavky pracovníků na rozpis (viz případ užití Zadat vlastní požadavky na nový rozpis). Tyto

44 3.3 Návrh nového řešení 44 Obr. 19: Sekvenční diagram Vytvoření nového rozpisu požadavky musejí pracovníci, kterých se rozpis týká zadat do poloviny již zmiňovaného měsíce. Požadavkům pracovníků po jejich zvážení staniční sestra může a nebo nemusí vyhovět. Požadavky mohou být u více pracovníků stejné až do té míry, že rozpis služeb nebude možný vůbec sestavit. V takovém případě je pouze na staniční sestře kterému pracovníkovi vyhoví a kterému ne. Je však v zájmu staniční sestry aby požadavkům pracovníků vyhověla co nejvíce spravedlivě. Nově vytvořený rozpis by měl být ke všem pracovníkům oddělení spravedlivý. To znamená, že pracovníci by měli mít rovnoměrně rozdělené finančně zvýhodněné služby. Práce v některé dny je finančně lépe ohodnocena než v jiné dny (vizčást Úvod do problematiky rozpisů služeb). Pokud je některý pracovník znevýhodněn v tomto rozpisu služeb, měl by být zvýhodněn v tom příštím. Pracovníci by měli mít i podobný počet běžných hodin a z toho vyplívajících přesčasů. Důležitou částí vytváření nového rozpisu je jeho doplnění systémem. Při této části vytváření rozpisu systém doplní všechny chybějící služby pracovníků. V této fázi je zapotřebí zohlednit množství důležitých preferencí rozpisu a chyb, které mohou nastat. Výsledně doplněný rozpis musí být přepočítán. Jsou sečteny všechny hodiny služeb, dovolené, pracovní neschopnosti, atd. Na základě těchto součtů je teprve staniční sestra schopna doplněný rozpis upravit podle vlastních požadavků. Teprve po této fázi může být v systému nový rozpis uložen a poté je možné ho vytisknout.

45 3.3 Návrh nového řešení 45 Tab. 8: Scénář pro případ užití Vytvořit nový rozpis služeb Krok Role Akce 1 Staniční sestra Přihlásí se do systému. 2 Systém POKUD byl uživatel úspěšné přihlášen s uživatelskými právy Administrátora NEBO Staniční sestry POTOM zobrazí tlačítko Nový rozpis služeb. 3 Staniční sestra Zvolí podsekci Nový rozpis služeb. 4 Systém Zobrazí formulář pro výběr měsíce a roku pro který bude nový rozpis vytvářen. POKUD nemá uživatel přiřazeno oddělení POTOM systém zobrazí menu pro výběr dostupných oddělení. 5 Staniční sestra Zvolí rok, měsíc a oddělení pro nový rozpis. Údaje odešle potvrzením. 6 Systém POKUD pro zadaný měsíc na zadaném oddělení již rozpis existuje POTOM upozorní uživatele na existenci rozpisu a vrátí se ke kroku 4 JINAK zobrazí tabulku pro zadání speciálních požadavků pracovníků oddělení. 7 Staniční sestra Vyplní speciální požadavky pracovníků oddělení a zvolí tlačítko Uložit. 8 Systém Doplní tabulku rozpisu chybějícími službami v rozpisu, spočítá souhrnné údaje nového rozpisu a zjistí chyby v rozpisu, o souhrnných údajích a chybách informuje uživatele. 9 Staniční sestra Upraví vygenerovaný rozpis dle požadavků a zvolí tlačítko Uložit. 10 Systém Spočítá souhrnné údaje nového rozpisu a zjistí chyby v rozpisu, o souhrnných údajích a chybách informuje uživatele. POKUD uživatel nezvolil možnost Při ukládání ignorovat chyby personálního obsazení A ZÁROVEŇ rozpis obsahuje personální chyby NEBO rozpis obsahuje jiné chyby POTOM se vrátí ke kroku 8 JINAK zobrazí výsledný rozpis s možností uložení do databáze. 11 Staniční sestra Zvolí možnost Uložit nový rozpis. 12 Systém Informuje uživatele o úspěchu uložení nového rozpisu do databáze a zobrazí možnost Vytisknout rozpis. 13 Staniční sestra Odhlásí se ze systému.

46 3.3 Návrh nového řešení 46 Upravit vytvořený rozpis služeb Tento případ užití smí v systému využívat uživatel s administrátorskými právy a uživatel s právy staniční sestry. Stejně jako v případě vytvoření nového rozpisu má administrátor tyto práva přidělena jen pro případ nouzového použití. Není předpokládáno, že administrátor bude jakkoliv zasahovat do správy rozpisů služeb. Situace při které bude zapotřebí změnit rozpis služeb nastane s největší pravděpodobností v případě, že některý z pracovníků v průběhu měsíce onemocní. V tomto případě bude nutné služby, které měl pracovník sloužit přidělit někomu jinému. Staniční sestra zároveň dotyčnému do rozpisu služeb zapíše pracovní neschopnost. Postup úpravy vytvořeného rozpisu je podobný jako při vytváření nového rozpisu. Uživatel systému, který rozpis upravuje bude mít k dispozici možnost automatického doplnění rozpisu chybějícími službami. Rozpis služeb bude možné kdykoliv při jeho úpravě přepočítat a vypočítané hodnoty pro jednotlivé pracovníky přehledně vypsat. Systém také bude při přepočítání zjišťovat chyby v rozpisu a upozorňovat na ně uživatele. Před samotnou změnou rozpisu bude nutné jej v databázi vyhledat (viz případ užití Vyhledat vytvořený rozpis služeb). Tak jako při vytváření nového rozpisu bude možné provedené změny uložit i za předpokladu chyb v personálním obsazení. Aby mohl být uložený rozpis změněn v databázi s chybami v personálním obsazení pro jednotlivé dny, bude nutné aby tuto možnost uživatel zvolil. Tab. 9: Scénář pro případ užití Upravit vytvořený rozpis služeb Krok Role Akce 1 Staniční sestra Přihlásí se do systému. 2 Systém POKUD byl uživatel úspěšné přihlášen s uživatelskými právy Administrátora NEBO Staniční sestry POTOM zobrazí tlačítko Výpis rozpisů. 3 Staniční sestra Zvolí podsekci Výpis rozpisů. 4 Staniční sestra Vyhledá rozpis služeb viz případ užití Vyhledat vytvořený rozpis. 5 Staniční sestra Zvolí možnost Upravit rozpis. 6 Systém Zobrazí tabulku s rozpisem služeb a souhrnem údajů. 7 Staniční sestra Upraví tabulku s rozpisem služeb a zvolí možnost Uložit. 8 Systém Spočítá souhrnné údaje rozpisu a zjistí chyby v rozpisu, o souhrnných údajích a chybách informuje uživatele. POKUD uživatel nezvolil možnost Při ukládání ignorovat chyby personálního obsazení A ZÁROVEŇ rozpis obsahuje personální chyby NEBO rozpis obsahuje jiné chyby POTOM se vrátí ke kroku 6 JINAK změní rozpis v databázi. 9 Systém Informuje uživatele o úspěchu změny databáze. 10 Staniční sestra Odhlásí se ze systému.

47 3.3 Návrh nového řešení 47 Obr. 20: Sekvenční diagram Upravení rozpisu služeb Zadat vlastní požadavky na nový rozpis Tento případ užití budou v systému využívat uživatelé, které představuje aktér Pracovník. Mezi tyto uživatele se řadí všechny zdravotní sestry a ošetřovatelé pracující v jednosměnném i třísměnném provozu. Pracovníci prostřednictvím tohoto případu užití sdělí staniční sestře své požadavky na rozpis pro příští měsíc. Požadavky mohou být na volný den, denní službu, noční službu a dovolenou. Tab. 10: Scénář pro případ užití Zadat vlastní požadavky na nový rozpis Krok Role Akce 1 Pracovník Přihlásí se do systému. 2 Systém POKUD byl uživatel úspěšné přihlášen s uživatelskými právy Ošetřovatele NEBO Zdravotní sestry POTOM zobrazí tlačítko Zadat požadavky. 3 Pracovník Zvolí podsekci Zadat požadavky. 3 Systém Zobrazí tabulku s rozpisem služeb na příští měsíc. 4 Pracovník Zadá vlastní požadavky na rozpis a zvolí Uložit. 5 Systém Uloží požadavky do databáze a informuje uživatele o úspěchu uložení. 6 Pracovník Odhlásí se ze systému. Vyhledat vytvořený rozpis služeb Vyhledávat vytvořené rozpisy budou všichni uživatelé systému. Vyhledání rozpisu bude nutné pro jeho úpravu (vizpřípad užití Upravit vytvořený rozpis služeb) a pro

48 3.3 Návrh nového řešení 48 jeho tisk (vizpřípad užití Vytisknout vytvořený rozpis služeb). Všem uživatelům, kteří jsou přiřazeni k oddělení bude umožněno vyhledávat a prohlížet vytvořené rozpisy služeb aby mohli kdykoliv zjistit kdy mají v budoucnu službu. Tab. 11: Scénář pro případ užití Vyhledat vytvořený rozpis služeb Krok Role Akce 1 Systém POKUD uživatel nemá přiřazené oddělení 2 Uživatel Vybere oddělení. POTOM zobrazí menu s výběrem oddělení JINAK pokračuje krokem 4. 3 Systém POKUD vybrané oddělení nemá doposud žádné rozpisy služeb POTOM se vrátí ke kroku 1. 4 Systém Zobrazí menu s výběrem všech vytvořených rozpisů služeb pro jedno oddělení. 5 Uživatel Vybere rozpis služeb. 6 Systém Načte z databáze údaje vybraného rozpisu, spočítá souhrnné údaje rozpisu a zjistí chyby v rozpisu, o souhrnných údajích a chybách informuje uživatele. Zobrazí tabulku s rozpisem. 7 Systém POKUD byl uživatel úspěšné přihlášen s uživatelskými právy Administrátora NEBO Staniční sestry POTOM zobrazí tlačítko Úprava rozpisu. Vytisknout vytvořený rozpis služeb Tento případ užití bude moci v systému používat každý oprávněný uživatel systému. Všichni uživatelé systému, kteří nemají administrátorská uživatelská práva budou omezeni na tisk rozpisu pouze pro oddělení, kterému jsou přiřazeni. Před samotným vytisknutím rozpisu bude nutné jej v databázi vyhledat (viz případ užití Vyhledat vytvořený rozpis služeb). Tento případ užití je velice důležitý a bude využívaný velice často všemi pracovníky léčebny. Tab. 12: Scénář pro případ užití Vytisknout vytvořený rozpis služeb Krok Role Akce 1 Uživatel Přihlásí se do systému. 2 Uživatel Zvolí podsekci Výpis rozpisů. 3 Uživatel Vyhledá rozpis služeb viz případ užití Vyhledat vytvořený rozpis. 4 Uživatel Zvolí možnost Vytisknout rozpis. 5 Systém Vytiskne rozpis služeb. 6 Uživatel Odhlásí se ze systému.

49 3.3 Návrh nového řešení 49 Změnit uživatelské heslo Tento případ užití bude moci v systému používat každý oprávněný uživatel systému. Všichni uživatelé systému, kteří se úspěšně přihlásí do systému prostřednictvím svého uživatelského jména a hesla budou moci si změnit stávající uživatelské heslo za nové. Tato funkce je základní uživatelskou funkcí každého systému. Uživatelské heslo je z důvodu bezpečnosti vhodné jednou za čas obměňovat. Novým uživatelům většinou při jejich vytváření bude přiděleno jako heslo jejich zaměstnanecké číslo. Změna takového hesla za vlastní hned po prvním přihlášení je z hlediska bezpečnosti velice důležitá. Tab. 13: Scénář pro případ užití Změnit uživatelské heslo Krok Role Akce 1 Uživatel Přihlásí se do systému. 2 Uživatel Zvolí podsekci Změnit heslo. 3 Systém Zobrazí formulář pro změnu hesla. 4 Uživatel Vyplní staré heslo a dvakrát nové heslo. 5 Systém Ověří správnost starého hesla a zkontroluje správnou délku a totožnost nových zadaných hesel. POKUD jsou hesla zadaná správně POTOM uloží nové heslo do databáze JINAK informuje uživatele o chybě a se vrátí ke kroku 3. 6 Systém Informuje uživatele o úspěchu změny hesla. 7 Uživatel Odhlásí se ze systému Diagram tříd Diagram tříd modeluje strukturu a vztahy mezi třídami navrhovaného systému. Diagram tříd představuje statický pohled na informační systém. V diagramu tříd informačního systému pro rozpis služeb v psychiatrické léčebně jsou zobrazeny všechny třídy objektů vyskytující se v systému. Všechny třídy objektů jsou obrazem reálných subjektů, které jsou podstatné pro vytváření a správu rozpisů služeb. Diagram tříd navrhovaného informačního systému je znázorněn na Obr. 21. Třída Pracovník je tvořena generalizací všech typů pracovníků, kteří v systému vystupují. Obsahuje metody a atributy, které jsou společné pro všechny pracovníky. Pracovník může být typu Staniční sestra, Pracovník ve směnách a Administrátor. Staniční sestra je vedoucím pracovníkem pro oddělení a vytváří i upravuje Rozpis služeb. Pracovník ve směnách zahrnuje všechny zdravotní sestry a ošetřovatele pracující v jednosměnném i třísměnném provozu. Mohou zadávat pro Rozpis služeb své vlastní požadavky. Administrátor je pracovníkem léčebny, který se stará o chod systému. Vytváří nové Pracovníky v systému a upravuje jejich údaje. Administrátor provádí také správu Oddělení v systému.

50 3.3 Návrh nového řešení 50 Obr. 21: Diagram tříd

51 3.3 Návrh nového řešení 51 Třída Oddělení je obrazem reálného oddělení psychiatrické léčebny. Má své jméno a číslo oddělení. Důležitým atributem třídy Oddělení jsou personální požadavky. Podle těchto požadavků jsou dále vytvářeny Rozpisy služeb pro každé oddělení. Každý Pracovník pro kterého je vytvářen nový Rozpis služeb musí být přiřazen do některého Oddělení. Ne každý Pracovník však musí být přiřazen do Oddělení (např administrátor, nově přijatý pracovník). Z tohoto důvodu je mezi uvedenými dvěma třídami použit vztah agregace. Další třídou v diagramu je Rozpis služeb. Tento objekt vytváří Staniční sestra pro Oddělení, na kterém pracuje a ve výjimečných případech i Administrátor systému. Každý Rozpis služeb musí být vytvořený pro jedno Oddělení léčebny, proto je použit vztah kompozice. Rozpis služeb se skládá z jednotlivých Služeb, které jsou určeny právě jednomu Pracovníkovi. Služba musí být určena pro jeden Rozpis služeb a jednoho Pracovníka. Bez nich by nemohla existovat, proto je v obou případech použit vztah kompozice Diagram aktivit Jak jsem již uvedl v přehledu literatury této práce, hlavním úkolem diagramů aktivit je modelovat chování jednoho objektu při průchodu více případy užití. Největší výhodou těchto diagramů je to, že umožňují sledovat chování objektu mezi více paralelními vlákny. Tento diagram zachycuje všechny po sobě následující aktivity při využití podmínek v podobě větvení. Diagram aktivit ilustrující proces vytváření nového rozpisu služeb je zobrazen na Obr. 22. Případ užití pro vytvoření nového rozpisu byl již popsán scénářem a sekvenčním diagramem v části práce Diagram případů užití. Tento pohled na vytváření rozpisu služeb je však přímočarý a nezobrazuje alternativní chování objektu při použití podmínek. Diagram aktivit představuje ucelený přehled všech aktivit nutných pro vytvoření nového rozpisu. Zahrnuje i aktivity dostupné použitím jiných případů užití v podobě alternativních scénářů. Důležitou částí diagramu je vyhodnocení požadavků pracovníků a zadání vlastních požadavků na vytvářený rozpis. Staniční sestra tak zadá všechny potřebné požadavky ve formě služeb a dalších požadavků jako jsou dovolené, pracovní neschopnost a volné dny. Systém poté přepočítá všechny souhrnné údaje a zjistí zároveň případné chyby v rozpisu. Pokud rozpis obsahuje chyby, musí staniční sestra přehodnotit některé požadavky na rozpis. Další podstatnou částí diagramu je automatické doplnění rozpisu služeb chybějícími službami. To je další situace, kdy se můžou v rozpisu objevit chyby. Může nastat situace, že oddělení nemá dostatek personálu na to, aby splnil personální požadavky na rozpis. Další případem, který může nastat po automatickém doplnění jsou chyby způsobené špatným zadáním požadavků na rozpis. V obou případech musí staniční sestra přehodnotit požadavky a upravit je.

52 3.3 Návrh nového řešení 52 Obr. 22: Diagram aktivit Vytvoření nového rozpisu

53 3.4 Implementace 53 Může nastat situace, že je nedostatek volných ošetřovatelů pro službu v určitý den. Může se tak stát z důvodu pracovní neschopnosti jednoho nebo více ošetřovatelů. V tomto případě je možné ošetřovatele ve službě nahradit zdravotní sestrou. Bude tedy v jeden den sloužit o jednu zdravotní sestru více a o jednoho ošetřovatele méně. Systém za normálních okolností situaci vyhodnotí jako chybu v personálním obsazení. Staniční sestra však může v systému nastavit možnost aby tuto situaci nevyhodnocoval jako chybovou. Rozpis služeb půjde v tomto případě i přes tuto chybu úspěšně dokončit. 3.4 Implementace Analýzou současného stavu v léčebně jsem dospěl k názoru, že správa rozpisů služeb je nevyhovující. Z toho důvodu jsem provedl návrh pro vývoj budoucího systému. Provedl jsem návrh statické i dynamické části systému. Prostřednictvím jazyka UML jsem namodeloval systém, který splňuje funkční i nefunkční požadavky na systém. V této části práce se budu zabývat některými části implementace systému. Datová struktura systému je tvořena databázovým systémem MySQL. Návrh datových prvků vychází plně z navrženého diagramu tříd. Datová struktura je ilustrována v podobě entitně relačního diagramu (ERD) na Obr. 23. Přičemž entity tohoto diagramu vycházejí z návrhu objektových tříd. U každého atributu entity je v ERD uveden její datový typ. Tento datový typ představuje obor hodnot, kterých může atribut nabývat. Podtržené atributy diagramu představují primární klíče entity. Heslo je v databázi uložené za použití hashovací funkce. Konkrétně jsem použil hashovací algoritmus MD5. Při zapomenutí hesla uživatelem tedy nejde heslo zjistit z databáze zpět. Pokud nastane tato situace, je nutné aby administrátor uživateli přidělil heslo nové, které si však může uživatel po úspěšném přihlášení změnit na své vlastní. Jak jsem uvedl v cíli práce informační systém bude intuitivní a jednoduchý na ovládání. Dále bude přístupný z internetu 2 pro jeho lepší dostupnost nejen z léčebny, ale i z okolních míst. Pracovníci tak budou moci z domova zjistit svůj vlastní pracovní plán na celý příští měsíc. V souvislosti s těmito požadavky jsem navrhl grafické uživatelské rozhraní systému. Aby mohl být systém dostupný přes internetový prohlížeč, jeho grafické uživatelské rozhraní je tvořeno HTML kódem. HTML kódem je však tvořen jen seznam prvků a jejich stylů. Konečná grafická podoba rozhraní je určena použitím kaskádových stylů. V případě, že v budoucnu vznikne požadavek na změnu vzhledu, bude změna grafického rozhraní umožněna zcela jednoduše změnou příslušných stylů. Nebude tedy zapotřebí měnit HTML kód. Vzhled systému je optimalizován pro internetový prohlížeč Mozilla Firefox. Jeho bezproblémový chod je však zajištěn pro většinu používaných internetových prohlížečů. Zdrojový kód funkční části systému je napsán ve skriptovacím jazyce PHP. Protože celá analýza i navrhované řešení jsou modelovány objektovým způsobem, je 2 V současné době je systém dostupný na internetové adrese

54 3.4 Implementace 54 Obr. 23: Entitně Relační Diagram i realizace systému provedena objektovým způsobem. Skriptovací jazyk PHP plně podporuje objektově zaměřené programování. Při samotné realizaci však bylo zapotřebí použít více objektů než bylo modelováno při návrhu systému. Více objektových tříd zdrojový kód obsahuje především, protože v návrhu nejsou zahrnuty podstatné části systému jako jsou grafické uživatelské rozhraní, informační vypisování aktuálního data, přihlašování do systému, atd. Modelování těchto prků by nepřineslo užitek, naopak by diagramy činily více nepřehlednými. Podstatnou částí systému je správa uživatelů. Jak jsem se již zmínil dříve, léčebna zaměstnává mnoho pracovníků. Systém umožňuje vytvářet nové uživatele a údaje již vytvořených uživatelů také upravovat. Systém automaticky kontroluje zda jsou údaje ve formuláři pro vytvoření nebo úpravu uživatele vyplněné správně. Při zakládání nového uživatele je možné nechat vygenerovat jeho přihlašovací jméno systémem. Toto jméno je tvořené z prvních šesti písmen příjmení uživatele před které je vloženo písmeno x. Pokud již uživatel s takovýmto přihlašovacím jménem v systému existuje, systém za vytvořené přihlašovací jméno přidá číslo. Toto číslo se zvyšující počtem uživatelů se stejným přihlašovacím jménem narůstá a začíná na čísle 0.

55 3.4 Implementace 55 Obr. 24: Ukázka vyhledávání uživatelů systému

56 3.4 Implementace 56 Správa takového množství pracovníků užívajících systém by byla velice obtížná bez efektivního vyhledávání v uživatelích systému. Při vyhledávání je umožněno zadávat několik parametrů usnadňujících vyhledání uživatele systému. Vyhledané uživatele je možné řadit podle různých kriterií. Více vyhledaných uživatelů je možné vypisovat po zadaných počtech na jednu stránku. Přičemž pokud některé vyhledávací parametry zůstanou nevyplněné, systém je při vyhledávání nezohledňuje. Ukázka vyhledávání v systému je na Obr. 24. Algoritmizačně nejsložitější částí systému je správa rozpisů služeb. Rozpisy služeb systém umožňuje vytvářet, již hotové a uložené rozpisy upravovat a tisknout. Při úpravě a vytváření rozpisů systém umožňuje rozpis služeb kdykoliv přepočítat. Při tomto úkonu jsou zjištěny v rozpisu chyby (viz část Úvod do problematiky rozpisů služeb). Vypočítávání souhrnných údajů rozpisu je důležitou částí. Staniční sestru, která rozpis vytváří informuje o všech důležitých součtech hodin pracovníků oddělení. V následující části jsou uvedeny souhrnné údaje, které jsou vypočítávány pro pracovníky včetně postupu jejich výpočtu. Pracovní norma Pracovníci v třísměnném provozu (počet pracovních dnů 7,5) (dovolená + pracovní neschopnost) Pracovníci v jednosměnném provozu (počet pracovních dnů 8) (dovolená + pracovní neschopnost) Počet odpracovaných hodin v běžném provozu Výpočet je stejný pro všechny pracovníky. Jsou sečteny všechny odpracované hodiny v měsíci pro který je vytvářen rozpis. Je přičten zbytek noční služby z minulého měsíce Přesčas počet odpracovaných hodin pracovní norma Počet hodin v noční službě počet nočních služeb 7,5 Počet odpracovaných hodin ve státní svátek Výpočet je stejný pro všechny pracovníky. Jsou sečteny všechny odpracované hodiny ve státní svátek. Počet odpracovaných hodin o víkendu Výpočet je stejný pro všechny pracovníky. Jsou sečteny všechny odpracované hodiny o víkendu. Počet hodin dovolené Pracovníci v třísměnném provozu počet dnů dovolené 11,5

57 3.4 Implementace 57 Pracovníci v jednosměnném provozu Počet hodin pracovní neschopnosti Pracovníci v třísměnném provozu Pracovníci v jednosměnném provozu počet dnů dovolené 8 počet dnů pracovní neschopnosti 11,5 počet dnů pracovní neschopnosti 8 Každá noční a denní služba trvá 12 hodin. Pracovníkům je však započítáno jen 11,5 hodiny. Je tomu tak z důvodu neplacené přestávky která trvá 30 minut. Noční služba je rozdělena do dvou dnů, a proto je nutné rozdělit i hodiny této služby mezi dva dny. Služby je však možné dělit pouze po půl hodinách. Není jiného východiska než nožní službu rozdělit na 6 hodin a 5,5 hodiny. Větší část noční služby musí být započtena do dne, který je lépe finančně ohodnocen. Nejlépe ohodnoceny jsou hodiny odpracované o státním svátku, druhým v pořadí je víkend a všední den je ohodnocen nejhůře. Státní svátek však může být i o víkendu. To rozdělení noční služby do jisté míry komplikuje. Rozdělení noční služby zahrnující všechny situace, které mohou nastat popisuje následující tabulka. Tab. 14: Rozdělení noční služby Den služby Rozdělení 1. den 2. den 1. den 2. den všední všední 6 hod. 5,5 hod. všední víkend 5,5 hod. 6 hod. víkend všední 6 hod. 5,5 hod. všední svátek 5,5 hod. 6 hod. svátek všední 6 hod. 5,5 hod. víkend svátek 5,5 hod. 6 hod. svátek víkend 6 hod. 5,5 hod. víkend víkend 6 hod. 5,5 hod. svátek svátek 6 hod. 5,5 hod. Podle takto vypočtených údajů se staniční sestra (při automatickém doplňování systém) rozhoduje při o přidělení služby pracovníkovi. Jak jsem se již zmínil rozpis služeb musí být vyvážený. To znamená spravedlivý ke každému pracovníkovi. Při přidělování služeb pracovníkům je zapotřebí dbát na to aby měli v souhrnu u všech důležitých položek co nejvíce podobných hodnot. Důležité je dbát zejména na počty hodin přesčasu, nočních služeb, služeb o víkendu a ve státní svátek. Ukázka takto navrženého rozpisu v systému je na Obr. 25.

58 3.4 Implementace 58 Obr. 25: Ukázka úpravy hotového rozpisu služeb vytvořeného v systému

59 3.4 Implementace 59 Obr. 26: Ukázka rozpisu služeb vytištěného do formátu PDF

60 3.4 Implementace 60 Obr. 27: Ukázka souhrnu vypočtených údajů z rozpisu služeb vytištěného do formátu PDF