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

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

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.

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

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

Obsah 1 Úvod a cíl práce 1.1 Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Přehled literatury 2.1 Požadavky systému . . . . . . . . . . . 2.2 CASE nástroje . . . . . . . . . . . . . 2.2.1 Popis a historie . . . . . . . . . 2.2.2 Enterprise Architect . . . . . . 2.3 Procesní řízení a modelování . . . . . . 2.3.1 Podnikové procesy . . . . . . . 2.3.2 Business Process Reengineering 2.4 Objektový přístup . . . . . . . . . . . 2.4.1 Objekt . . . . . . . . . . . . . . 2.4.2 Třída . . . . . . . . . . . . . . . 2.5 Unifikovaný modelovací jazyk . . . . . 2.5.1 Popis a historie UML . . . . . . 2.5.2 Diagramy podnikových procesů 2.5.3 Diagramy případů užití . . . . . 2.5.4 Diagramy tříd . . . . . . . . . . 2.5.5 Diagramy aktivit . . . . . . . . 2.5.6 Sekvenční diagramy . . . . . . . 3 Vlastní řešení 3.1 Psychiatrická léčebna Brno . . . . . . 3.1.1 Historie . . . . . . . . . . . . 3.1.2 Popis a specializace . . . . . . 3.2 Analýza současného stavu . . . . . . 3.2.1 Úvod do problematiky rozpisů 3.2.2 Analýza podnikových procesů 3.2.3 Současné řešení procesů . . . 3.3 Návrh nového řešení . . . . . . . . . 3.3.1 Specifikace požadavků . . . . 3.3.2 Diagram případů užití . . . . 3.3.3 Diagram tříd . . . . . . . . . 3.3.4 Diagram aktivit . . . . . . . . 3.4 Implementace . . . . . . . . . . . . .

7 7 8

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

9 9 9 9 10 11 11 12 13 13 13 14 14 14 16 18 20 24

. . . . . . . . . . . . . . . . služeb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

26 26 26 26 27 27 29 30 32 32 34 49 51 53

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

4 Diskuse

62

5 Závěr

64

OBSAH

6 Literatura

6 65

1

ÚVOD A CíL PRÁCE

1 1.1

7

Úvod a cíl práce Ú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.

1.2

1.2

Cíl práce

8

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í.

2

PŘEHLED LITERATURY

2 2.1

9

Přehled literatury 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

2.2.1

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

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. 2.2.2

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 200 000 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ách1 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

http://www.sparxsystems.com

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 2.3.1

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ů.

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. 2.3.2

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)

2.4

Objektový přístup

2.4

13

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. 2.4.1

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) 2.4.2

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ě.

2.5

Unifikovaný modelovací jazyk

14

Obr. 4: Objektová třída a objekty (Kanisová, Müller, 2004, s. 51)

2.5 2.5.1

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í. 2.5.2

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í

2.5


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.

2.5


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)

2.5.3

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í

2.5


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)

2.5


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. 2.5.4

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.

2.5


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

2.5


20

5. Specializace – přesně opačný vztah jako generalizace. 2.5.5

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.

2.5


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.

2.5


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.

2.5


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.

2.5


2.5.6

24

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.

2.5


Obr. 16: Ukázka sekvenčního diagramu (Enterprise Architect User Guide, 2009)

25

3

VLASTNí ŘEŠENí

3 3.1 3.1.1

26

Vlastní řešení Psychiatrická léčebna Brno Historie

Psychiatrická léčebna v Brně-Černovicích byla založena v roce 1863. 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. 3.1.2

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

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 3.2.1

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.

3.2


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-

3.2


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. 3.2.2

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.

3.2


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. 3.2.3

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.

3.2


Obr. 17: Diagram podnikových procesů

31

3.3

Návrh nového řešení

3.3


3.3.1

Specifikace požadavků

32

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.

3.3


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 3.2.1 Ú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 3.2.1 Úvod do problematiky rozpisů služeb). Uživateli bude umožněno pro přechod k další

3.3


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í. 3.3.2

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

3.3


Obr. 18: Diagram případů užití

35

3.3


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í.

3.3

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 1 2

Role Administrátor Systém

3

Administrátor

4 5

Systém Administrátor

6

Systém

7

Administrátor

Akce Přihlásí se do systému. 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í. Zvolí podsekci Správa oddělení a v této podsekci zvolí možnost Nové oddělení. Zobrazí formulář pro přidání nového oddělení. Vyplní číslo, název a personální požadavky oddělení a stisknutím tlačítka údaje odešle. 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. Odhlásí se ze systému.

3.3

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 1 2


3

Administrátor

4 5 6 7

Systém Administrátor Systém Administrátor

8

Systém

9

Administrátor

Akce Přihlásí se do systému. 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í. Zvolí podsekci Správa oddělení a v této podsekci zvolí možnost Vypiš oddělení. Vypíše všechna vytvořená oddělení. Vybere oddělení, které chce upravit. Zobrazí formulář pro upravení oddělení. Upraví název a personální požadavky oddělení a stisknutím tlačítka údaje odešle. Zkontroluje správnost zadaných údajů. POKUD jsou údaje vyplněny špatně 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. Odhlásí se ze systému.

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.

3.3

39


Tab. 3: Scénář pro případ užití – Smazat oddělení Krok 1 2


3

Administrátor

4 5 6 7 8

Systém Administrátor Systém Administrátor Systém

9

Administrátor

Akce Přihlásí se do systému. 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í. Zvolí podsekci Správa oddělení a v této podsekci zvolí možnost Vypiš oddělení. Vypíše všechna vytvořená oddělení. Vybere oddělení, které chce smazat. Vyžádá potvrzení pro smazání oddělení. Potvrdí smazání oddělení 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. 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-

3.3

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 1 2


3

Administrátor

4 5

Systém Administrátor

6

Systém

7

Administrátor

Akce Přihlásí se do systému. 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ů. Zvolí podsekci Správa uživatelů a v této podsekci zvolí možnost Nový uživatel. Zobrazí formulář pro přidání nového uživatele. 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. 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. Odhlásí se ze systému.

3.3

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 1 2


3

Administrátor

4

Systém

5

Administrátor

6

Systém

Akce Zvolí možnost Vyhledat uživatele Vypíše formulář pro vyhledávání a pro řazení nalezených uživatelů. 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. Vyhledá v databázi všechny uživatele kteří odpovídají zadaným kritériím a vypíše je. Seřadí nalezené uživatele podle vybraných atributů a vybere hledaného uživatele. Zobrazí detailní informace vybraného uživatele a zobrazí tlačítko Smazat uživatele a Upravit údaje.

3.3

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 1 2


3 4 5 6 7 8

Administrátor Administrátor Administrátor Systém Administrátor Systém

9

Administrátor

Akce Přihlásí se do systému. 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ů. Zvolí podsekci Správa uživatelů. Vyhledá uživatele – viz případ užití Vyhledat uživatele. Zvolí možnost Smazat uživatele. Vyžádá si potvrzení pro smazání uživatele. Potvrdí smazání uživatele. V databázi uživateli nastaví atribut smazán. Informuje uživatele o úspěchu smazání. 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.

3.3

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 1 2


3 4 5 6 7 8

Administrátor Administrátor Administrátor Systém Administrátor Systém

9

Administrátor

Akce Přihlásí se do systému. 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ů. Zvolí podsekci Správa uživatelů. Vyhledá uživatele – viz případ užití Vyhledat uživatele. Zvolí možnost Upravit údaje. Zobrazí formulář pro změnu údajů uživatele. Změní požadované údaje uživatele a formulář odešle. 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. 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

3.3


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.

3.3

45


Tab. 8: Scénář pro případ užití – Vytvořit nový rozpis služeb Krok 1 2

Role Staniční sestra Systém

3 4

Staniční sestra Systém

5

Staniční sestra

6

Systém

7

Staniční sestra

8

Systém

9

Staniční sestra

10

Systém

11 12

Staniční sestra Systém

13

Staniční sestra

Akce Přihlásí se do systému. 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. Zvolí podsekci Nový rozpis služeb. 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í. Zvolí rok, měsíc a oddělení pro nový rozpis. Údaje odešle potvrzení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í. Vyplní speciální požadavky pracovníků oddělení a zvolí tlačítko Uložit. 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. Upraví vygenerovaný rozpis dle požadavků a zvolí tlačítko Uložit. 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. Zvolí možnost Uložit nový rozpis. Informuje uživatele o úspěchu uložení nového rozpisu do databáze a zobrazí možnost Vytisknout rozpis. Odhlásí se ze systému.

3.3

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 1 2

Role Staniční sestra Systém

3 4

Staniční sestra Staniční sestra

5 6 7 8

Staniční sestra Systém Staniční sestra Systém

9 10

Systém Staniční sestra

Akce Přihlásí se do systému. 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ů. Zvolí podsekci Výpis rozpisů. Vyhledá rozpis služeb – viz případ užití Vyhledat vytvořený rozpis. Zvolí možnost Upravit rozpis. Zobrazí tabulku s rozpisem služeb a souhrnem údajů. Upraví tabulku s rozpisem služeb a zvolí možnost Uložit. 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. Informuje uživatele o úspěchu změny databáze. Odhlásí se ze systému.

3.3

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 1 2

Role Pracovník Systém

3 3 4 5

Pracovník Systém Pracovník Systém

6

Pracovník

Akce Přihlásí se do systému. 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. Zvolí podsekci Zadat požadavky. Zobrazí tabulku s rozpisem služeb na příští měsíc. Zadá vlastní požadavky na rozpis a zvolí Uložit. Uloží požadavky do databáze a informuje uživatele o úspěchu uložení. 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

3.3

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 1

Role Systém

2 3

Uživatel Systém

4

Systém

5 6

Uživatel Systém

7

Systém

Akce POKUD uživatel nemá přiřazené oddělení POTOM zobrazí menu s výběrem oddělení JINAK pokračuje krokem 4. Vybere oddělení. POKUD vybrané oddělení nemá doposud žádné rozpisy služeb POTOM se vrátí ke kroku 1. Zobrazí menu s výběrem všech vytvořených rozpisů služeb pro jedno oddělení. Vybere rozpis služeb. 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. 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 1 2 3

Role Uživatel Uživatel Uživatel

4 5 6

Uživatel Systém Uživatel

Akce Přihlásí se do systému. Zvolí podsekci Výpis rozpisů. Vyhledá rozpis služeb – viz případ užití Vyhledat vytvořený rozpis. Zvolí možnost Vytisknout rozpis. Vytiskne rozpis služeb. Odhlásí se ze systému.

3.3

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 1 2 3 4 5

Role Uživatel Uživatel Systém Uživatel Systém

6 7

Systém Uživatel

3.3.3

Akce Přihlásí se do systému. Zvolí podsekci Změnit heslo. Zobrazí formulář pro změnu hesla. Vyplní staré heslo a dvakrát nové heslo. 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. Informuje uživatele o úspěchu změny hesla. 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.

3.3


Obr. 21: Diagram tříd

50

3.3


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. 3.3.4

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.

3.3


Obr. 22: Diagram aktivit – Vytvoření nového rozpisu

52

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 internetu2 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 http://sluzby.tecpa.cz

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.

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

3.4 Implementace

55

3.4

56

Implementace

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

3.4

57

Implementace

– Pracovníci v jednosměnném provozu počet dnů dovolené × 8 • Počet hodin pracovní neschopnosti – Pracovníci v třísměnném provozu počet dnů pracovní neschopnosti × 11,5 – Pracovníci v jednosměnném provozu 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 1. den 2. den všední všední všední víkend víkend všední všední svátek svátek všední víkend svátek svátek víkend víkend víkend svátek svátek

Rozdělení 1. den 2. den 6 hod. 5,5 hod. 5,5 hod. 6 hod. 6 hod. 5,5 hod. 5,5 hod. 6 hod. 6 hod. 5,5 hod. 5,5 hod. 6 hod. 6 hod. 5,5 hod. 6 hod. 5,5 hod. 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.

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

3.4 Implementace

58

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

3.4 Implementace

59

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

3.4 Implementace

60

3.4

Implementace

61

Z ukázky správy rozpisů v systému (Obr. 25) je patrné, že vytvořený rozpis služeb je po jeho úspěšném dokončení (nebo při jeho vyhledání) možné stisknutím tlačítka vytisknout. Systém umožňuje tisk rozpisu služeb (včetně tisku souhrnných údajů) do souboru formátu PDF. Pro implementaci tisku služeb do souborů formátu PDF jsem využil třídu FPDF, která využívá PHP knihovnu PDFLib. Tento formát je vhodný pro tisk zejména proto, že jeho podoba je nezávislá na použitém hardware i software. Soubor PDF vypadá po otevření na kterémkoliv počítači vždy stejně. Je tedy snadno přenositelný a vhodný pro budoucí tisk na tiskárně. Ukázka takto vytištěného rozpisu do formátu PDF je na Obr. 26 a ukázka vytištěných souhrnných údajů je na Obr. 27.

4

4

DISKUSE

62

Diskuse

Mnou navrhované řešení je určené přesně pro konkrétní skupinu uživatelů. Je velmi nepravděpodobné, že by byly podnikové procesy týkající se rozpisů služeb v jiném zdravotním zařízení podobné. Tento informační systém je určený pro správu rozpisů služeb v Psychiatrické léčebně v Brně. Tvorba těchto rozpisů pro jednotlivá oddělení léčebny je velice specifická. Personální rozdělení léčebny a kalkulace všech hodin rozpisu se mohou jen těžko shodovat s podobnými zařízeními. Hlavním důvodem proč jsem se rozhodl tento systém navrhnout je usnadnění a hlavně urychlení práce pracovníkům léčebny. Stávající řešení je zastaralé a neefektivní. Největší přínos bezesporu přinese staničním sestrám, které mají sestavování rozpisů služeb za úkol. Jak jsem se již zmínil, není to lehký úkol. Podstatným hodnocením každého systému je shrnutí jeho přínosů. Ukazatele přínosů můžeme klasifikovat z několika hledisek: (Rábová, 2008, s. 122) • Finanční a nefinanční. • Kvantitativní a kvalitativní. • Přímé a nepřímé • Krátkodobé a dlouhodobé. • Absolutní a relativní. Jedním z hlavních kvantifikovatelných přínosů systému je zajisté čas, který staniční sestry ušetří. Díky tomu, že stráví méně času tvorbou rozpisů služeb se mohou věnovat jiným důležitým povinnostem. Rozpis služeb navrhovaný za pomoci počítačové podpory je také vyrovnanější z hlediska odpracovaných hodin jednotlivých pracovníků. Staniční sestra může kdykoliv zjistit, který pracovník byl v minulém období zvýhodněn, a který byl naopak znevýhodněn. Na základě těchto informací může právě navrhovaný rozpis přizpůsobit. Největším z kvalitativních přínosů systému je zlepšení pracovního prostředí, které sebou systém bezesporu přináší. Pohodlnější a rychlejší vytváření rozpisů má mnoho pozitivních účinků. Staniční sestry mohou lépe vyhovět přáním a požadavkům pracovníků na rozpis. Všichni pracovníci si mohou kdykoliv a odkudkoliv, kde je přístupný internet zjistit své budoucí služby na oddělení. Automatické generování rozpisu služeb také pomáhá eliminovat časté opakování stejných kolegů při službě. Pokud nastane nějaká změna, která ovlivňuje již vytvořený rozpis, je jednoduché rozpis opravit a přepočítat. Po finanční stránce je vhodné zmínit zejména náklady spojené s vývojem a užíváním systému. Náklady na vývoj systému se dají vyčíslit jen podle času, který jsem strávil při návrhu a realizaci tohoto systému. Do nákladů tohoto typu by bylo možné zahrnout i energii a náklady na softwareové vybavení potřebné k návrhu a implementaci systému. Při návrhu jsem použil trial verzi CASE nástroje Enterprise Architect. A ostatní software, který jsem použil byl zcela bez licenčních poplatků. Uvedené náklady byly spojené s vývojem a pořízením informačního systému. Dalším typem nákladů jsou náklady nutné k zavedení systému do provozu a náklady nutné k samotnému provozu systému. Pro zavedení systému bude nutné hardwareové

4

DISKUSE

63

vybavení. Vzhledem k tomu, že léčebna je dnes již vybavena počítačovou sítí, tyto náklady nebudou hrát významnou roli. Dalšími náklady, které mohou vzniknout jsou náklady spojené se školením uživatelů systému. Uživatelské rozhraní je však navrženo tak, aby ho bez problémů mohl ovládat každý uživatel, který má základní povědomí o práci s internetovým prohlížečem. K provozu navrženého systému bude však nutný administrátor, který ho bude spravovat. Jeho úkolem bude především správa uživatelů systému. Psychiatrická léčebna již zaměstnává pracovníky, kteří jsou určeni pro správu sítě a softwareového vybavení léčebny. Předpokládám, že po zavedení systému do provozu nebude nutné měnit údaje v databázi přiliž často. Uvedení pracovníci léčebny by tedy pravděpodobně mohli plnit roli administrátorů systému.

5

5

ZÁVĚR

64

Závěr

Provedl jsem analýzu podnikových procesů Psychiatrické léčebny v Brně. Analýza byla zaměřena zejména na správu rozpisů služeb. Za tímto účelem jsem namodeloval všechny procesy, které souvisí s vytvářením nových rozpisů služeb. Při analýze stávajícího systému správy rozpisů služeb jsem zjistil množství nedostatků. Z těchto příčin jsem se rozhodl navrhnout nový informační systém, který bude správu rozpisů služeb řešit efektivnějším způsobem. Jedním z cílů této práce bylo namodelovat nový informační systém pro psychiatrickou léčebnu. Pro všechny modely, které popisují systém jak ze statické stránky, tak z dynamické stránky jsem použil modelovacího jazyka UML. Sestrojil jsem diagram případů užití a diagram tříd. Navrhl jsem aktéry, kteří budou v systému vystupovat a na základě nich potom navrhl uživatelské skupiny systému. Při spolupráci s personálem léčebny jsem navrhl všechny funkce, které bude informační systém podporovat. Komunikace s budoucími uživateli byla velice důležitá pro specifikaci požadavků na navrhovaný systém. Dalším stěžejním cílem této práce bylo navrhnout grafické uživatelské rozhraní. Tento cíl bylo nutné s ohledem na nepříliš velkou počítačovou gramotnost pracovníků léčebny provést především ve spolupráci s personálem. Domnívám se, že navržené uživatelské rozhraní je dostatečně příjemné a především intuitivní na ovládání. Při navrhování vzhledů rozpisů služeb jsem vycházel ze současné podoby těchto rozpisů. Pracovníci jsou na tento vzhled již zvyklí, jedná se zejména o písmena značící typ služby, která zůstala nezměněna. Dalším splněným cílem je realizace informačního systému. Podstatnou částí správy služeb je jejich generování podle zadaných požadavků. Tato část byla implementačně nejobtížnější. Při doplňování rozpisu službami je nutné zohlednit množství faktorů, které je nutné splnit. Všem faktorům ovlivňujícím přidělení služby pracovníkovi je nutné přiřadit váhy tak, aby bylo zřejmé, které faktory preferovat před ostatními. Výsledné rozdělení vah může zcela elementárně změnit výslednou podobu vygenerovaného rozpisu služeb. Najít rovnováhu mezi těmito váhami se ukázalo jako obtížný úkol. V průběhu realizace systému jsem však zjistil, že vyhovět všem požadavkům maximálně není možné. Když byl rozpis vyrovnaný na velikost přesčasů a zvýhodněných hodin pracovníků, nebyl splněn požadavek na střídání pracovníků ve službách. Nebo nezřídka nastala situace, že rozpis obsahoval chyby. Výsledné rozdělení vah je tedy kompromisem, který vyhovuje do jisté míry všem požadavkům. Závěrem bych chtěl podotknout, že v systému nejsou plně implementovány všechny funkce vycházející z modelovaných případů užití. Jedná se zejména o možnost pracovníků přes uživatelské rozhraní zadávat vlastní požadavky na rozpis. Dále by bylo vhodné v databázi ukládat údaje o tom, kdo vytvořil nebo upravil rozpis služeb a kdy tak učinil. To jsou jen některé uvedené příklady. Existuje množství nových funkcí a vylepšení stávajících funkcí, které by systém učinily užitečnějším. V budoucnu se jistě těmito zlepšeními budu zabývat.

6

6

LITERATURA

65

Literatura

Arlow, J., Neustadt, I. UML 2 a unifikovaný proces vývoje aplikací: objektově orientovaná analýza a návrh prakticky 2. vyd. Brno: Computer Press, 2007, 567 s. ISBN 978-80-251-1503-9. Kanisová, H., Müller, M. UML srozumitelně 1. vyd. Brno: Computer Press, 2004, 162 s. ISBN 80-251-0231-9. Rábová, I. a kolektiv Podniková architektura: strategický nástroj v rukou manažera 1. vyd. Brno: Tribun EU, 2008, 134 s. ISBN 978-80-7399-568-3. Rábová, I. Podnikové informační systémy a technologie jejich vývoje Brno: Knihovnicka.cz, 2008, ISBN 978-80-7399-599-7. Řepa, V. Podnikové procesy: Procesní řízení a modelování 2. vyd. Praha: Grada Publishing, 2007, 288 s. ISBN 978-80-247-2252-8. Sodomka, P. Informační systémy v podnikové praxi 1. vyd. Brno: Computer Press, 2006, 351 s. ISBN 80-251-1200-4. Sparx Systems UML Tutorial [online], Sparx Systems, [cit. 2010-5-16], URL: http://www.sparxsystems.com/uml-tutorial.html. Wikipedia CASE nástroje [online], Wikipedia.org, [cit. 2010-5-16], URL: http://cs.wikipedia.org/wiki/CASE nástroje. Wikipedia Objektové programování [online], Wikipedia.org, [cit. 2010-5-16], URL: http://cs.wikipedia.org/wiki/Objektově orientované programování.

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

Recommend Documents