Analýza a návrh systému pro podporu služby helpdesk pro oblast IT

M A S A RY K O VA U N IV E R Z ITA F A K U LTA I N F O R M AT IK Y

Analýza a návrh systému pro podporu služby helpdesk pro oblast IT

B AK A L Á Ř S K Á P R Á C E

Jiří Stránský

Brno, 2010

Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

Vedoucí práce: RNDr. Pavel Hajn

Poděkování Děkuji RNDr. Pavlu Hajnovi za vedení mé bakalářské práce a hodnotné připomínky k její podobě. Děkuji RNDr. Dušanu Kovářovi, Ph.D., jehož hodiny informatiky na gymnáziu mě utvrdily ve výběru oboru pro další studium.

Shrnutí Práce se zabývá službou helpdesk poskytovanou malým podnikem působícím v oblasti IT. Nejprve je provedena analýza požadavků podniku a zhodnocení existujícího softwaru pro podporu služby helpdesk. Následně je navržen systém, který splní cíle analýzy. Systém je implementován a přiložen k práci včetně zdrojového kódu. V závěru je provedena rozvaha, zda a proč by měl být vytvořený systém firmě prospěšný.

Klíčová slova Informační systém, helpdesk, analýza, návrh, Unified Process, UML, případy užití, analytické třídy

Obsah 1 Úvod........................................................................................................................................2 1.1 Poznámka k jazyku...........................................................................................................2 1.2 Použitá metodika..............................................................................................................2 2 Vize přínosu a analýza existujících řešení................................................................................4 2.1 Vize přínosu.....................................................................................................................4 2.2 Možnost použití existujícího systému..............................................................................5 3 Analýza požadavků..................................................................................................................8 3.1 Uživatelské role................................................................................................................8 3.2 Subsystém zákaznických požadavků................................................................................9 3.3 Subsystém technické dokumentace................................................................................11 3.4 Notifikace uživatelů.......................................................................................................12 3.5 Ostatní vlastnosti systému..............................................................................................13 4 Podrobná analýza...................................................................................................................15 4.1 Datový model.................................................................................................................15 4.2 Funkční model................................................................................................................18 5 Návrh.....................................................................................................................................21 5.1 Třívrstvá architektura.....................................................................................................21 5.2 Použité technologie a grafika.........................................................................................22 5.3 Vrstva aplikační logiky...................................................................................................23 5.4 Iterace.............................................................................................................................25 6 Závěr......................................................................................................................................27 6.1 Předpoklady naplnění vize.............................................................................................27 6.2 Možnosti dalšího rozvoje...............................................................................................28

1

Kapitola 1

Úvod

Budu vytvářet systém pro podporu služby helpdesk, zaměřený na společnosti působící v oblasti informačních technologií. Abych lépe pochopil, jaké funkce by měl mít pro uspokojení potřeb malé až střední firmy, rozhodl jsem se postavit jej přímo na míru společnosti Meridian ITS, s. r. o. Firma již na svých webových stránkách má část pojmenovanou „Helpdesk“ [Fil09], ale je tvořena pouze formulářem, který rozesílá e-mail určitým zaměstnancům. Manažer společnosti mi sdělil, že zákazníci formulář nevyužívají. Je zde prostor pro výrazná vylepšení.

1.1 Poznámka k jazyku Text práce je primárně v češtině. Všechny pojmy v analytické části práce jsou v češtině, protože musejí být konzultovány s českým zákazníkem. Názvy v návrhovém modelu (třídy, rozhraní, metody apod.) jsou v angličtině, protože návrhový model musí korespondovat se zdrojovým kódem, který je také anglicky. Psaní softwaru v angličtině považuji za dobrý zvyk, v případě nutnosti umožňuje široké vývojářské veřejnosti porozumět kódu, neomezuje se na česky mluvící populaci. Navíc všechny knihovny použité v aplikaci jsou také v angličtině a program pak při čtení působí ucelenějším dojmem. Rád bych zde ještě upozornil, že v textu se slovo požadavek vyskytuje ve dvou rozdílných významech: • ustálený termín softwarového inženýrství, označující požadavek zadávající firmy vzhledem k vývojáři, • termín používaný zadávající firmou, označující požadavek jejich zákazníka vzhledem k nim. Budu se snažit, aby z kontextu bylo vždy jasné, ve kterém významu je slovo požadavek použito.

1.2 Použitá metodika Jako základ postupů směřujících k vytvoření konečné aplikace použiji metodiku Unified Process a její vyjadřovací prostředek Unified Modelling Language1 [Arl07]. Metodika Unified 1 Dále budu používat zkratku UML.

2

Process definuje kostru vývojového procesu a určuje artefakty (dokumenty, zdroje apod., které slouží jako výstupy činností a vstupy jiných činností). Využiji toho, že metodika je do velké míry přizpůsobitelná – říká, že artefaktů je možné se vzdát nebo nadefinovat nové dle uvážení vývojářů, bude-li to ve prospěch projektu. Cílem není postupovat dle předem stanovených bodů, cílem je vytvořit systém, se kterým bude klient spokojen. Navzdory mému přizpůsobení metodiky bych se rád držel jejích tří základních axiomů: • vývoj řízený případy užití • zaměření a důraz na architekturu • iterativní implementace

3

Kapitola 2 Vize přínosu a analýza existujících řešení 2.1 Vize přínosu „Bez dobré definice problému se vám může snadno stát, že vynaložíte obrovské úsilí k řešení nesprávného problému. Cenou za neurčení problému bývá často obrovské množství promrhaného času a peněz. Navíc se vše násobí faktem, že jste vlastně problém vůbec nevyřešili.“ [McC05] Rozhodnutí o vytvoření systému pro službu helpdesk pramení z nespokojenosti manažerů se současným stavem vnitrofiremních procesů a mělo by vyústit v úsporu nákladů nebo zvýšení zisku. Zavedení nových pracovních postupů podpořených technologií by nemělo být samoúčelné, mělo by být podmíněno praktickým přínosem. Z konzultace s manažerem vyplynuly čtyři základní záměry, které by měl systém zrealizovat, aby byl prospěšný: 1) Vykazování provedené práce Má-li zákazník firmy Meridian technický problém, zatelefonuje a žádá o pomoc. Pokud se situace nevyřeší hovorem na dálku, vyjíždí k zákazníkovi technik, vyplňují se montážní nebo servisní listy a vše je v pořádku. Nedojde-li k výjezdu technika, čas strávený telefonováním uniká pozornosti. V současné době se práce vykazuje výhradně papírovou formou, což zaměstnanci může připadat pomalé a často se nechce obtěžovat s evidováním menších úkonů, jako je telefonická podpora, přestože hovor může trvat i přes 30 minut. Zaměstnanec takto „pracuje zdarma“ a firma přichází o nezanedbatelnou část zisku. Systém by měl umožnit co nejsnazší sledování telefonních hovorů, vzdálené podpory a podobných drobných prací. 2) Zviditelnění servisních úkonů ve firmě Evidence servisních úkonů musí probíhat nejen kvůli účtování nákladů, ale také pro organizační potřeby firmy. Zatím neexistuje centralizovaná forma sledování nevyřízených požadavků jednotlivých zákazníků, což způsobuje občasné zmatky. Například když technik vyjíždí k zákazníkovi upravit nastavení počítačové sítě, nevezme s sebou 4

hardware určený k dodání témuž zákazníkovi, protože o objednávce vůbec neví. Důsledkem je druhá, jinak zbytečná cesta, tedy přidané náklady za benzín a čas zaměstnance. Systém pro podporu služby helpdesk je ve své podstatě centralizovanou správou zákaznických požadavků, naskýtá se možnost výše uvedené nepříjemnosti zmírnit. 3) Jednoduchost pro zákazníky Snadné ovládání by mělo být samozřejmým cílem každého systému, ale v případě služby helpdesk je velmi důležité, lze jej pokládat za součást vize produktu. Většina uživatelů se nebude setkávat se systémem každý den; zákazník nesmí mít problém rychle se zorientovat v systému a zadat svou objednávku, přestože například potřebuje jen jednou za rok pravidelnou profylaxi počítačů. Bude potřeba intuitivní ovládání, aby uživatel netápal. Meridian by neměl ztrácet zakázky kvůli složitosti procesu zadávání požadavků, už má z minulosti špatnou zkušenost s adopcí aplikací, které měly složitější uživatelské rozhraní. Manažer mi požadavek jednoduchosti mnohokrát zdůrazňoval, v tomto ohledu tedy při výběru nebo tvorbě systému nebudu dělat žádné kompromisy. 4) Vedení technické dokumentace (Tato funkce není prioritní a manažer uvedl, že by nejraději systém uvedl do provozu nejprve bez ní a nechal ji dodělat později.) Firma potřebuje přehled o spravovaném zařízení a programovém vybavení zákazníka (stavu serverů a počítačů, instalovaného softwaru apod.). Jednomu zákazníkovi náleží jedna papírová složka s dokumentací, která může být pro zaměstnance v daném okamžiku fyzicky nedostupná. Jestliže se provedené změny nastavení nezapíší hned, většinou se už nezapisují vůbec. Systém bude dostupný přes internet odkudkoliv, lze vytvořit modul pro technickou dokumentaci a nahradit jím papírové složky.

2.2 Možnost použití existujícího systému Manažer hned zpočátku vyloučil komerční produkty z úvahy o použití existujících systémů. Pro tak malou firmu, jakou je Meridian, by koupě komerčního systému znamenala nepřiměřené investice, které by se jeho používáním dostatečně nenavracely zpět. Zbývá tedy použití produktů distribuovaných jako open source, a to dvěma možnými způsoby: použití neupraveného existujícího softwaru, nebo jeho rozšíření o novou funkcionalitu (pouze tak, aby nemusel být z velké části přepsán). V každém případě musí nasazený systém naplnit výše uvedenou vizi přínosu. V případě, že žádný produkt neshledám vhodným pro Meridian, vyvinu od základů nový systém pro podporu služby helpdesk.

2.2.1

OneOrZero Task Management and Helpdesk

OneOrZero Task Management and Helpdesk [One08] je postaven na PHP a MySQL a ve své 5

otevřené variantě je uvolněn pod licencí GNU GPL [GNU07a]. Je možné rozšířit právě otevřenou variantu systému, ale nevýhodou je, že ta se od roku 2008 dále nevyvíjí. Systém je velice pokročilý – jeho základem je správa a sledování práce, zákaznické požadavky přicházející přes službu helpdesk jsou jen podmnožinou oblasti zaměření. Systém umožňuje odhad času práce a zaznamenávání skutečného trvání činností, hledání v pracovních záznamech pomocí různých kritérií, konfigurovatelné upozorňování na události a obsahuje knowledge base. Se všemi výhodami bohužel souvisí také jeho hlavní nevýhoda – přílišná složitost. I přes to, že k samotnému designovému zpracování uživatelského rozhraní nemám žádné výrazné výtky, obávám se, že takto obsáhlý systém svou podstatou zahlcuje uživatele informacemi a možnostmi. Například při vytváření nového požadavku musí uživatel vyplnit osm kolonek, k nimž se dostane až po čtyřech kliknutích od příchodu do systému, což koliduje s vizí přínosu – s požadavkem na jednoduchost ovládání. U systému OneOrZero Task Management and Helpdesk vidím potenciál pro rozdělení do nezávislých subsystémů, operujících nad stejnou bází dat; pak by každý subsystém mohl mít uživatelské rozhraní, které by lépe odpovídalo cílové skupině uživatelů. Tento systém není vhodný pro Meridian, jednak kvůli ukončení prací na otevřené verzi, ale hlavně kvůli své složitosti. Manažer vyjádřil obavy, že donutit pracovníky k používání takto složitého systému by bylo obtížné a donutit k témuž zákazníky by bylo prakticky nemožné. Nicméně pro velkou a náročnou organizaci s technicky zdatnou skupinou zákazníků (např. webhostingovou společnost) může být komerční verze tohoto systému lákavá, a to hlavně díky své snaze kompletně postihnout veškerý firemní workflow uceleně, v rámci jediné aplikace.

2.2.2

Open Ticket Request System

Open Ticket Request System [OTR09] je zaměřený přímo a pouze na poskytování služby helpdesk a je uvolněn pod licencí GNU AGPL [GNU07b]. Kromě základních funkcí správy požadavků umí i provádět hromadné akce na skupinách požadavků, uzamykat požadavky a uspořádávat je do stromové struktury (jeden požadavek může obsahovat další podřízené požadavky). Každý zaměstnanec má vlastní ovládací panel, jehož obsah si může do určité míry nastavit. Systém obsahuje kalendář pro zobrazení plánované práce přihlášeného uživatele, ale je prakticky nepoužitelný kvůli špatné optimalizaci. Desetkrát jsem měřil v demonstrační aplikaci dobu od požadavku do zobrazení různých kalendářových stránek, vždy se nacházela mezi 10 a 18 sekundami, což je nemyslitelné pro reálné nasazení systému v prostředí desítek až stovek uživatelů. Dalším negativem jsou poněkud experimentálně a nepřirozeně působící části uživatelského rozhraní, které by mohly uživatele mást. Rozbalování položek hlavního menu je řešeno tak, že při prvním použití systému není poznat rozdíl mezi položkami nejvyšší úrovně a položkami vnořenými. Open Ticket Request System nepodporuje dokumentaci navázanou na zákazníky nebo srovnatelnou funkci. Celkově vzato, Open Ticket Request System je použitelným softwarem (vyjma kalendáře, který potřebuje výkonovou optimalizaci), ale pro nasazení v Meridianu nemá vhodné uživatelské rozhraní a chybí mu funkcionalita pro vedení technické dokumentace. Od stavby vlastního 6

řešení na bázi tohoto produktu navíc odrazuje fakt, že je naprogramován v jazyku Perl, který neovládám. Učit se další programovací jazyk kvůli práci na jediném projektu by bylo neekonomické rozhodnutí.

2.2.3

Coldbrew Helpdesk

Jsou k dispozici pouze snímky obrazovky [Pai08], zobrazující rozhraní systému Coldbrew Helpdesk, zdrojový kód není nikde dostupný. Projekt má repozitáře na Sourceforge [Pai09a] i na Google Code [Pai09b], ale oba jsou prázdné (k datu 1. 5. 2009). Býval uvolněn pod licencí GNU GPL [GNU07a] a postaven na PHP. Je hodný povšimnutí hlavně díky přehlednému uživatelskému rozhraní, které by mi mohlo být inspirací. Jako jednoznačná identifikace uživatele je použita e-mailová adresa, uživatel si tedy nemusí pamatovat přihlašovací jméno. Uvítací obrazovka pak obsahuje šest hlavních voleb, každá je uvedena velkým obrázkem a stručným popisem. Zákazník se tak k vyplňování nového požadavku dostane po dvou kliknutích (počítáno včetně přihlášení do systému). Hlavní menu je vertikální, rozbalovací, přirozeně řešené. Počet ovládacích prvků na stránce nepřesahuje únosnou mez.

2.2.4

Další systémy

Systém Triage [Phi09] je postaven na jazyku Java a uvolněn pod licencí GNU GPL [GNU07a], ale je teprve v počátcích vývoje, pro nasazení je nevhodný. Systém PHD Help Desk [Toz09] má nevzhledné uživatelské rozhraní a funkcionalitu, která se příliš neblíží vizi přínosu, jeho rozšíření by mohlo být nákladnější než postavit nový systém. Mezi otevřeným softwarem jsou ještě další systémy pro službu helpdesk, ale nepůsobí jako stabilní a udržované projekty, například nevykazují znaky aktivního vývoje v posledním roce.

2.2.5

Rozhodnutí o použití existujícího systému

Nepodařilo se mi mezi existujícími produkty nalézt takový, který by bylo možné přímo nasadit, nebo jej použít jako základ pro tvorbu vlastního řešení. Vytvoření nového produktu formou rozšíření stávajícího navíc nemusí být vždy výhodná – pro přidání nové funkcionality je nejdříve nutné seznámit se s jeho vnitřní stavbou, ale i poté existuje riziko, že vývoj nových částí bude trvat neúměrně dlouho v důsledku nevhodnosti softwaru pro daný druh rozšíření. Vzhledem k uvedeným skutečnostem budu vyvíjet vlastní řešení od základů.

7

Kapitola 3

Analýza požadavků

Vývoj na míru s sebou nese výhodu: Není třeba přizpůsobovat firmu softwaru, je možné přizpůsobit software firmě. To také znamená, že je nutné stanovit funkcionalitu vytvářeného softwaru. Požadavky závazně určí, co má systém umět. Je společnou odpovědností manažera a analytika dohodnout se na požadavcích tak, aby naplnily vizi přínosu. Právě specifikace požadavků tvoří pilíř kontraktu mezi oběma stranami. Specifikaci požadavků provedu pomocí strukturovaného textu a doplňujících UML diagramů případů užití2 [Arl07]. Častou součástí diagramu případů užití je tzv. scénář, tabulkový popis průběhu daného případu užití. Scénáře nepoužiji, jelikož se svou podstatou příliš nehodí do této práce, chování systému popíšu přirozeným jazykem. Účelem diagramů případů užití v této práci není podat vyčerpávající výčet všech akcí podporovaných systémem, ale spíše vyzdvihnout nejdůležitější funkce z pohledu uživatele, umožnit rychlou orientaci v požadavcích a pomoci uspořádat si myšlenky těm, kteří čtou specifikaci. Diagramy samy o sobě nejsou dostačující pro popis očekávaného chování systému. Analýza obsáhne i správu technické dokumentace, přestože ji chce manažer implementovat až po nasbírání zkušeností s provozem systému. Je nutné zjistit, co manažer od správy dokumentace očekává, aby bylo možné zajistit vytvoření systému, do kterého půjde taková funkcionalita později přidat.

3.1 Uživatelské role Systém rozliší pět základních uživatelských rolí. Zákazník je jedinou rolí nereprezentující zaměstnance Meridianu. Jeho hlavní úlohou je zadávat své požadavky a sledovat proces jejich řešení. Technik je osobou, která řeší požadavky zákazníků. Manažer má převážně řídící a sledovací funkci. Určuje řešitele požadavků a vidí statistiky spotřebovaných zdrojů, komunikuje jak se zákazníky, tak se zaměstnanci. Účetní také vidí statistiky spotřebovaných zdrojů, ale na rozdíl od manažera nevstupuje aktivně do procesu řešení požadavků. Když se v další specifikaci objeví slovo zaměstnanec, znamená to souhrnné označení pro technika, manažera a účetní. V UML diagramech také používám roli řešitel, která označuje manažera a technika; toto označení je použito pouze pro účel přehlednosti diagramu a nemá význam z implementačního hlediska. Speciální uživatelskou rolí je administrátor. Nezapojuje se do běžného používání 2 V anglickém originále „use case diagram“.

8

systému, pouze provádí jeho nastavení. Celou situaci nastiňuje obrázek 3.1. U každého uživatele se v systému bude evidovat e-mail, jméno, přijmení, titul před jménem, titul za jménem a kontaktní informace. E-mail bude plnit funkci přihlašovacího jména a musí tedy být pro každého uživatele jedinečný. Přihlášení bude umožněno i v perzistentním režimu tak, aby uživatel zůstal přihlášen i po zavření prohlížeče. Každý zákaznický účet ponese informaci o jméně společnosti, kterou daná osoba zastupuje. Pokud zákazník nezastupuje žádnou společnost, bude na místech v systému, kde by se v normálním případě vyskytlo jméno společnosti, vypisováno jméno osoby.

Obrázek 3.1: Vztahy dědičnosti mezi uživatelskými rolemi

3.2 Subsystém zákaznických požadavků Systém zajistí správu uživatelských požadavků. Diagram případů užití je na obrázku 3.2. Požadavek může být vložen buď přímo zákazníkem, nebo zaměstnancem (technikem, manažerem). V druhém jmenovaném případě je nutné explicitně zadat zákazníka, k němuž se bude požadavek vztahovat. Požadavek může být upravován zákazníkem, technikem a manažerem. Každý požadavek bude mít titulek, textový popis, kategorii, autora, aktuální stav a jedinečné identifikační číslo. Eviduje se datum vzniku, u vyřešených požadavků také datum vyřešení. Pro interní použití bude také možné stanovit prioritu požadavku a datum, do kdy má být požadavek vyřešen. Ke každému požadavku bude existovat diskuze pro komunikaci se zákazníkem (vlastníkem požadavku), interní diskuze a záznamy o spotřebách zdrojů. 9

Ihned po vytvoření je požadavek ve stavu nový. Buď je mu určen řešitel, čímž se požadavek otevře (stav otevřený), nebo může být manažerem zrušen (stav zrušený). Otevřený požadavek může technik nebo manažer uzavřít (stav uzavřený) a pouze manažer zrušit (stav zrušený). (Rozlišování mezi uzavřenými a zrušenými požadavky má význam v následném vyhodnocování – předpokládá se, že za zrušené požadavky firma nedostala zaplaceno, za uzavřené ano.) Nelze provádět úpravy uzavřených a zrušených požadavků ani s nimi souvisejících záznamů o spotřebě zdrojů. Pouze manažer může provést opětovné otevření uzavřeného nebo zrušeného požadavku. Požadavky budou mít řešitele a pozorovatele. Řešitel může být maximálně jeden, je jím osoba primárně zodpovědná za řešení požadavku a určuje jej manažer. Pozorovatelů může být libovolně mnoho a přihlašují/odhlašují se sami. Řešitelé a pozorovatelé budou informováni o nových událostech spojených s požadavkem. Každý zákazník bude povinně pozorovatelem svých vlastních požadavků. Zákazník na stránce požadavku uvidí, kdo je řešitelem, zaměstnanci dostanou přístup i k seznamu pozorovatelů. Systém umožní fulltextové hledání v požadavcích. Prohledávanými atributy budou název a popis. Hledání bude možné omezit na určitého zákazníka a také rozsahem pro datum vytvoření požadavku.

3.2.1

Diskuze k požadavku

Diskuze se zákazníkem se budou moci účastnit manažeři a technici. Interní diskuze bude přístupná pro čtení i přispívání všem zaměstnancům, ale žádnému zákazníkovi. K příspěvku se kromě textu uloží také autor, čas vložení a čas poslední úpravy, pokud nějaká proběhla. Příspěvky budou upravitelné autorem, odstranitelné autorem a manažerem.

3.2.2

Spotřeba zdrojů

Záznamy o spotřebě zdrojů budou moci zadávat všichni zaměstnanci. Každý záznam uchová spotřebované množství, druh zdroje, vkládajícího zaměstnance, čas vložení a čas poslední úpravy, pokud nějaká proběhla. Záznamy budou upravitelné autorem, odstranitelné autorem a manažerem. Statistikou spotřeby zdrojů se rozumí spotřebovaná sumární hodnota vybraného zdroje. Pro každé vyčíslení je třeba určit dvě hlediska: na koho se bude vztahovat a které hodnoty zahrnout. Vztahovat se může buď na zákazníka (jaké množství zdroje se spotřebovalo při práci pro něj), nebo na zaměstnance (jaké množství zdroje spotřeboval). Zahrnuté hodnoty lze omezit časovým rozpětím dvou dat nebo výběrem požadavku; použití alespoň jednoho omezení je nutné, použití obou zároveň je možné. Sledovatelné typy zdrojů (např. hodiny práce, minuty na telefonu, najeté kilometry) budou konfigurovatelné, platí však omezení, že spotřebované množství daného typu zdroje musí být vyjádřitelné racionálním číslem. Definici typu zdroje umožní administrátorské rozhraní, tvoří ji název a měrná jednotka.

10

Obrázek 3.2: Diagram případů užití pro subsystém zákaznických požadavků

3.3 Subsystém technické dokumentace Každému zákazníkovi bude náležet virtuální systém složek, podobný běžným souborovým systémům a přístupný pouze zaměstnancům přes rozhraní systému. Tento systém složek bude mít jednu kořenovou složku, v níž bude možné zakládat, rušit a přejmenovávat podsložky do libovolné úrovně zanoření. V každé složce, včetně kořenové, bude možné vytvářet, upravovat a rušit textové dokumenty. Úprava těchto dokumentů proběhne online prostřednictvím editoru typu WYSIWYG3, zabudovaného v systému. Právo na manipulaci s dokumenty budou mít 3 Zkratka pro „What You See Is What You Get“, uživatelsky pohodlný způsob úpravy dokumentů.

11

všichni zaměstnanci. Systém uchová alespoň posledních 10 revizí 4 dokumentu a umožní vrátit jeho stav zpět do libovolné z nich, aby se předešlo nevratným nežádoucím úpravám způsobeným omylem. Každý dokument se bude skládat z jména, textu a času poslední úpravy. U každé revize bude možné dosledovat autora a čas uložení. Systém umožní export dokumentů do formátu HTML. Diagram případů užití pro dokumentaci je na obrázku 3.3.

Obrázek 3.3: Diagram případů užití pro subsystém technické dokumentace

3.4 Notifikace uživatelů Systém bude informovat uživatele o nově nastalých událostech dvěma způsoby, které se navzájem doplňují. Prvním je osobní notifikační stránka, odkud vedou hypertextové odkazy přímo na místa vztahující se k jednotlivým událostem. Nelze předpokládat, že se budou všichni uživatelé – především zákazníci – do systému přihlašovat denně, je tedy nutné doručit informace o nastalé události druhým, spolehlivějším informačním kanálem: e-mailem. Diagram případů užití pro notifikace a další funkcionalitu systému je na obrázku 3.4.

3.4.1

Sledované události

Zde je výčet událostí, o kterých se může uživatel nechat informovat. Vždy je uveden popis a ve špičaté závorce pak uživatelské role, které jsou k události relevantní. Daná událost se pak v nastavení zobrazí pouze těm uživatelům, kteří budou vystupovat v jedné z vypsaných rolí. Uživatel si vybere události, o kterých chce být informován, pro každou z nich nastaví zvlášť zobrazení na notifikační stránce a odesílání e-mailem. • nový požadavek • nový příspěvek v diskuzi k požadavku, který sleduji/řeším 4 Stav dokumentu mezi jednotlivými úpravami.

12

• •

3.4.2

nový záznam spotřeby zdrojů <manažer, účetní> editace nebo smazání záznamu spotřeby zdrojů <manažer, účetní>

Notifikační stránka

Notifikační stránka zobrazí seznam nových událostí, o kterých si uživatel přeje být informován. Ke každé události bude zobrazen čas, krátký popis a relevantní hypertextový odkaz. Může také všechny události označit za přečtené. Jinak se událost označí za přečtenou zobrazením související stránky v systému, bez ohledu na to, jestli se na ni dostane přes odkaz na notifikační stránce, nebo jinak. Systém uchová pro každého uživatele minimálně dvouměsíční historii událostí, včetně přečtených.

3.4.3

Notifikace e-mailem

Notifikace e-mailem se odešle pro každou událost zvlášť. Bude obsahovat podobné informace jako notifikační stránka: krátký popis a hypertextový odkaz na relevantní místo v systému.

3.5 Ostatní vlastnosti systému Systém bude lokalizován do češtiny a angličtiny.

3.5.1

Správa uživatelských účtů

S účty zákazníků budou manipulovat technici a manažeři, s účty techniků a účetních budou manipulovat manažeři, s manažerskými účty bude manipulovat administrátor. Účty bude možno zablokovat, tedy zakázat uživateli přístup do systému; opět platí výše zmíněná omezení pro manipulaci.

3.5.2

Oznamovací oblast

Součástí uživatelského rozhraní bude oznamovací oblast, inspirovaná obdobnou vlastností různých operačních systémů. V oznamovací oblasti budou ikony umožňující uživatele na něco upozornit a kliknutím na ikonu provést nějakou akci. Jako základní funkce bude obsahovat ikonu pro odhlášení ze systému a ikonu informující o nepřečtené události, odkazující na notifikační stránku.

13

3.5.3

Administrátorská nastavení

Přes administrátorské rozhraní proběhne vytvoření kategorií určených pro rozčlenění požadavků a také nastavení typů zdrojů, jejichž spotřeba bude systémem sledována. Administrátor také nastaví systémové proměnné a kategorie pro členění požadavků.

Obrázek 3.4: Diagram případů užití pro ostatní části systému

14

Kapitola 4

Podrobná analýza

Na základě požadavků stanovených v předchozí kapitole rozpracuji podrobnější analýzu vyvíjeného systému. Bude se skládat ze dvou částí: • vytvoření datového modelu – nalezení analytických tříd a vztahů mezi nimi, • vytvoření funkčního modelu z pohledu orientovaného na uživatelské rozhraní.

4.1 Datový model Datový model vyjádřím diagramem analytických tříd. [Arl07] V oblasti objektově orientovaného softwaru, zejména pak v metodice Unified Process, nahrazuje tradičnější ER5 diagram. Pojmenované obdélníky reprezentují (entitní) třídy domény, čáry mezi nimi určují vazby (relace) mezi třídami. Na každé straně relace je vyznačena její kardinalita (se stejným významem jako crow's foot [Son95] notace diagramu ER). V případě, že význam relace není zřejmý, lze obě strany, případně relaci jako celek, opatřit poznámkou. Trojúhelníková šipka určuje relaci dědičnosti. [Arl07]

4.1.1

Popis tříd

Význam každé třídy nadefinuji vždy větou v pevně stanoveném tvaru: „Objektem typu je <definice>.“ Tento způsob je do značné míry inspirovaný přístupem metodiky HIT [Sta08], ale nesnažím se o její použití ve všech detailech. • Objektem typu Uživatel je každý člověk, který se může přihlásit do systému. • Objektem typu UživatelskáRole je každá role definovaná ve specifikaci požadavků, tj. manažer, technik, účetní, zákazník, administrátor. • Objektem typu Požadavek je každá zákazníkova žádost o službu, pomoc, opravu, nebo podobný zásah. • Objektem typu KategoriePožadavku je každá skupina určená pro roztřídění zákaznických požadavků, kterou stanovil administrátor systému. • Objektem typu UdálostPožadavku je buď diskuzní příspěvek, nebo spotřeba zdroje. • Objektem typu DiskuzníPříspěvek je každá textová zpráva v interní nebo veřejné diskuzi k požadavku. 5 Zkratka pro „entity-relationship“.

15

• • • • •

4.1.2

Objektem typu SpotřebaZdroje je každá událost, jejímž důsledkem je použití (tedy spotřeba určitého množství) sledovaného zdroje. Objektem typu TypZdroje je každý kvantitou měřitelný zdroj, jehož spotřeba je sledována systémem. Objektem typu DokSložka je každý adresář technické dokumentace k určitému zákazníkovi. Objektem typu DokSoubor je každý textový záznam technické dokumentace k určitému zákazníkovi. Objektem typu RevizeDokSouboru je každý stav textového záznamu technické dokumentace mezi jednotlivými úpravami.

Popis vazeb

Vazby z diagramu analytických tříd popíšu v návaznosti na jejich číslování. Výjimku tvoří relace dědičnosti, které se nepopisují, protože mají vždy význam „je podtypem“. [Arl07] (Číslování vazeb má prefix „r“ – podle slova relace, resp. relationship –, aby bylo při pohledu na diagram ihned viditelný rozdíl mezi identifikátorem a kardinalitou.) {r1} Uživatelská role, ve které vystupuje daný uživatel. {r2} Uživatel, který vlastní daný požadavek. {r3} Uživatelé, kteří sledují daný požadavek. {r4} Uživatel, který řeší daný požadavek. {r5} Kategorie, do které patří daný požadavek. {r6} Událost, která nastala u daného požadavku. {r7} Uživatel, který vytvořil danou událost. {r8} Typ zdroje, který byl spotřebován při dané spotřebě zdroje. {r9} Kořenová složka, která patří danému zákazníkovi. {r10} Složka, která je nadřazena dané složce. {r11} Složka, ve které se nachází daný soubor. {r12} Soubor, jehož stav v určitém okamžiku zachycuje daná revize.

16

Obrázek 4.1: Diagram analytických tříd

17

4.2 Funkční model Analýza požadavků určila, co bude systém umožňovat. Nyní je na místě analýzu rozšířit o funkční model – naplánovat, jak bude stanovených funkcí systému dosaženo. Funkční model rozpracuji z pohledu uživatelského rozhraní, protože funkční model je stále součástí analýzy, kterou musí být schopen pochopit i zákazník. Perspektiva uživatelského rozhraní vytříbí představu o systému, uzavře analýzu a vytvoří základ pro návrh systému. Rozhraní rozpracuji pouze do takové úrovně detailů, aby uvedené informace znamenaly přínos pro další fáze vývoje systému. Požadavkům na systém, jejichž způsob implementace je intuitivně zřejmý již z informací v kapitole 3, nebudu věnovat větší pozornost.

4.2.1

Uživatelé

Po přihlášení se uživateli zobrazí úvodní obrazovka s rychlými volbami, tj. grafikou podpořenými odkazy na nejčastější akce v systému – s ohledem na roli daného uživatele. Každý uživatel bude mít profilovou stránku s kontaktními informacemi. Profilové stránky zaměstnanců budou dostupné všem, profilové stránky zákazníků pouze zaměstnancům. Na více místech v systému se vyskytnou formuláře, kde bude zaměstnanec vybírat zákazníka pomocí textového pole. Tato textová pole budou mít funkci automatického doplňování – dohledání zákazníků dle jména firmy a příjmení osoby. Podobně budou fungovat textová pole pro výběr zaměstnance, která budou použita při výběru řešitele požadavku a ve statistikách spotřeb zdrojů. 4.2.1.1

Správa uživatelských účtů

Zaměstnanci si budou moci prohlédnout seznam všech uživatelů systému, k jejichž účtům mají právo úpravy. Nad seznamem se bude provádět blokování/odblokování jednotlivých účtů. Přes tuto stránku bude také dostupné vytvoření nového uživatelského účtu a úprava údajů existujících účtů. (Práva k operacím jsou určena v kapitole 3.)

4.2.2

Práce s požadavky

Práce s požadavky bude prováděna přes dva hlavní typy stránek: detaily a seznamy. Detail požadavku bude místem pro provádění operací a získávání informací, které se týkají jednoho konkrétního požadavku. Seznamy požadavků zprostředkují orientaci v množství požadavků a zajistí způsob, jak se dostat ke stránce s detailem. 4.2.2.1

Detail požadavku

Detail požadavku zobrazí údaje o požadavku (identifikační číslo, název, vlastník, popis, řešitel; zaměstnancům se zobrazí i pozorovatelé, priorita a datum požadovaného dokončení). K požadavku bude menu s podporovanými akcemi: editace požadavku, změna stavu, přihlášení se 18

k řešení, určení řešitele, zapnutí/vypnutí sledování, statistika spotřeb zdrojů (položky v menu se budou zobrazovat v závislosti na oprávněních uživatele). Na stránce požadavku bude panel, ve kterém se záložkami bude přepínat mezi diskuzí se zákazníkem, interní diskuzí a spotřebami zdrojů. Vkládání příspěvků a spotřeb zdrojů proběhne vyplněním potřebných údajů, uvedených v kapitole 3. 4.2.2.2

Seznamy požadavků

Zákazníkům systém poskytne tři seznamy požadavků: aktivní (tj. nové a otevřené) požadavky, hotové (uzavřené a zrušené) požadavky a výsledky hledání. Podporované možnosti hledání jsou rozebrány v kapitole 3. Zaměstnancům systém poskytne stejné seznamy jako zákazníkům a dva navíc: seznam otevřených požadavků, jejichž řešitelem je daný zaměstnanec, a seznam aktivních požadavků vybraného zákazníka. Všechny stránky se seznamy požadavků budou pro každý požadavek vypisovat zákazníkovi identifikační číslo, název a stav. Zaměstnancům se vypíše také vlastník požadavku, priorita a požadované datum ukončení. Seznam může být rozdělen na více stránek tak, aby počet položek na každé stránce nepřesáhl stanovenou hranici. Seznamy se implicitně seřadí sestupně dle data vytvoření požadavku. 4.2.2.3

Vytvoření požadavku

Na stránce vytvoření požadavku uživatel zadá název, popis a vybere kategorii. V případě, že požadavek vyplňuje zaměstnanec, zobrazí se také textové pole pro vyplnění zákazníka, jemuž nově vytvořený požadavek bude patřit, a další textová pole pro vyplnění interních údajů, specifikovaných v kapitole 3.

4.2.2.4

Statistika spotřeb zdrojů

Manažer a účetní budou mít k dispozici také stránku se statistikami spotřeb zdrojů. Statistika a možnosti zúžení výběru dat pro její zpracování jsou nadefinovány v kapitole 3.

4.2.3 4.2.3.1

Práce s dokumentací Navigace ve složkách

Do složek s dokumentací se zaměstnanec dostane těmito způsoby: výběrem zákazníka, hledáním a odkazem ze zákazníkova profilu do jeho kořenové složky. Výběr zákazníka bude proveden pomocí textového pole. Hledání proběhne nad názvy složek a dokumentů s možností omezení na jednoho zákazníka (opět pomocí textového pole). Ve složkách se bude zaměstnanec pohybovat pomocí odkazů (o úroveň níž a o úroveň výš). Na stránce s výpisem dané složky bude možné vytvořit, smazat a přejmenovat podsložku nebo dokument a přepnout na zobrazení, úpravu a seznam revizí dokumentu. 19

4.2.3.2

Úprava dokumentů

Dokument bude možné zobrazit v režimu pouze pro čtení, aby se předcházelo nechtěným změnám, a také v režimu úprav, kde bude moci uživatel měnit dokument formou WYSIWYG. Uložením provedených úprav se vytvoří nová revize dokumentu. Ke každému dokumentu bude stránka s historií – revizemi dokumentu. Revize bude zobrazena jako datum a čas uložení a jméno autora. U každé revize bude možnost prohlédnutí v režimu pouze pro čtení a možnost navrácení dokumentu do stavu dané revize. Navrácením se vytvoří nová revize dokumentu, samotné navrácení tedy bude zrušitelné dalším použitím funkce navrácení.

4.2.4

Administrační nastavení

Administrátor nadefinuje kategorie požadavků a zdroje, jejichž spotřeba bude systémem sledována. Ke každému zdroji zadá název a měrnou jednotku. Pro měrnou jednotku bude mít následující výběr: čas, jiná. V případě, že vybere volbu „jiná“, zadá název jednotky sám. V případě, že vybere volbu „čas“, bude se množství spotřebovaného zdroje zadávat v hodinách, minutách a sekundách. Přes rozhraní administrátora bude také probíhat nastavení systémových proměnných.

20

Kapitola 5

Návrh

Nejprve popíšu koncept třívrstvé architektury6, na jehož základu systém postavím, poté vyberu vhodné technologie pro realizaci a nakonec vytvořím návrhový model.

5.1 Třívrstvá architektura Třívrstvá architektura je přístupem k tvorbě systémů, při němž je systém dělen do tří striktně oddělených vrstev. Toto dělení může být pouze logické (vrstvy jsou umístěny na jednom serveru), nebo i fyzické (pak jsou vrstvy oddělené i hardwarově, proto je nutné, aby bylo dělení striktní). Profesionálních informačních zdrojů ohledně konceptu třívrstvé architektury je poskrovnu. Mezi důvěryhodnější patří např. The Linux Journal [Lin00] a Oracle [Ora06]. Prezentační vrstva7 je nejblíže k uživateli aplikace. Neobsahuje žádnou aplikační logiku, jejím úkolem je zprostředkovat komunikaci mezi uživatelem a jádrem systému. Přijímá od uživatele příkazy a zobrazuje data. Bývá tvořena různými způsoby, nejčastěji webovým rozhraním, případně aplikací spustitelnou na počítači uživatele. Vrstva aplikační logiky8 je mezi vrstvou prezentační a vrstvou perzistence dat. Obsahuje funkcionalitu, tvoří tedy jádro systému. Provádí prezentační vrstvou požadované operace nad daty a poskytuje jí data k zobrazení, přičemž stále hlídá, zda je uživatel systému oprávněn danou operaci provést, resp. daná data vidět. Některé systémy svou vrstvu logiky veřejně zpřístupňují přes rozhraní webových služeb, jako jsou SOAP9 nebo REST10, čímž umožňují jejich použití v dalších aplikacích. Vrstva perzistence dat11 se stará o trvalé uchování dat. Na žádost poskytuje data vrstvě aplikační logiky a zpětně od ní přijímá příkazy k úpravám. Typicky se jedná o ORM12 nebo sadu database access objektů, které zapouzdřují přístup k databázi, případně jiným zdrojům dat. Závislosti se tvoří jen mezi bezprostředně sousedícími vrstvami a jsou jednosměrné, jak 6 7 8 9 10 11 12

V originále „three-tier architecture“. V originále „presentation tier“. V originále „logic tier“, také „business tier“. Zkratka pro „Simple Object Access Protocol“. Zkratka pro „Representational State Transfer“. V originále „data tier“, také „persistence tier“. Zkratka pro „object-relational mapper“.

21

ukazuje obrázek 5.1. Tím jsou zajištěny následující výhody: • možnost vytvoření více prezentačních vrstev nad jednou vrstvou logiky, • vyměnitelnost jakékoli vrstvy nebo její části bez ovlivnění ostatních vrstev, • usnadnění transparentního škálování (především na vrstvě perzistence dat).

Obrázek 5.1: Schematické vyjádření třívrstvé architektury

5.2 Použité technologie a grafika Výběr správných technologií pro realizaci systému je velmi důležitý. Technologie určují možnosti a omezení architektury projektu, a tím také jeho dlouhodobou udržovatelnost. Mají vliv na rychlost a spolehlivost softwaru, tedy na jeho praktickou použitelnost. Použiji pouze technologie, které jsou dostupné zdarma a mají otevřený zdrojový kód. Hlavní důvod je úspora financí, ale osobně považuji mnoho otevřených technologií za lepší a vhodnější pro profesionální použití, než jejich uzavřené alternativy. Rozhodování je do velké míry subjektivní záležitostí vývojáře, protože objektivní porovnání technologií by bylo velice složité (pokud vůbec možné). Přesto věřím, že výběr byl proveden dobře a může sloužit jako inspirace pro podobné projekty.

5.2.1

Programovací jazyk

Od počátku jsem se rozhodoval pouze mezi jazyky PHP a Java, protože pouze s nimi mám dostatek zkušeností, abych je považoval za přípustné. Vybral jsem jazyk Java, protože není interpretovaný, existuje pro něj škála kvalitních softwarových rámců13 a připadá mi pro daný případ vhodnější. 13 Tento termín se často do češtiny nepřekládá (zejména v neformálních jazykových projevech) a nechává se v anglickém tvaru „framework“.

22

5.2.2

Softwarové rámce

Pro prezentační vrstvu chci použít nějaký komponentově orientovaný rámec. Jako nejrozšířenější volby se jeví rámce Java Server Faces 2 [Ora10a], Apache Wicket [Hil10] a Tapestry [Shi10]. Rámec Tapestry jsem vyloučil, protože je vyvíjen a spravován pouze jedním člověkem, což dostatečně nezaručuje dlouhou životnost projektu. Moje první volba vedla k rámci Java Server Faces 2, ale vývoj experimentální aplikace s jeho pomocí se ukázal jako pomalý a problémový, celkově mi jeho stavba připadala zbytečně složitá. Vybral jsem si tedy rámec Apache Wicket. Nevyžaduje vytváření speciálních konfiguračních souborů, vývojář si vystačí se znalostí jazyků Java a XHTML, ze zkoumaných prezentačních rámců je nejpohodlnější na použití. Pro vrstvu logiky a její propojení se zbytkem systému byly dva kandidátní rámce – Enterprise Java Beans [Ora10b] a Spring [Spr10]. Vhodností pro vytvářený systém se příliš neliší. Vybral jsem Spring, protože na rozdíl od Enterprise Java Beans nepotřebuje ke svému běhu prostředí Java Enterprise Edition, lze jej zprovoznit i na jednodušším serveru typu servlet container. Datová vrstva bude tvořena rámcem typu ORM (a databází). Rozhodoval jsem se, jestli použít přímo framework Hibernate [Kin10], nebo jej ještě obalit standardizovaným Java Persistence API [Ora10c]. Vybral jsem přímo Hibernate, protože prezentační vrstva a vrstva logiky nebudou implementovány za pomoci standardizovaných rámců, použití Java Persistence API pro vrstvu datovou by tedy nemělo smysl. Bezproblémovou přenositelnost – hlavní výhodu standardizovaných technologií – by to systému beztak nepřineslo.

5.2.3

Databáze

Z otevřených databází jsou často používané MySQL a PostgreSQL. Rozdíl mezi nimi je pro účel vytvářeného systému minimální, navíc díky rámci Hibernate by mělo být možné v případě potřeby databázi jednoduše vyměnit. Především z důvodu subjektivní preference použiji databázi PostgreSQL.

5.2.4

Grafika

Grafickou úpravu uživatelského rozhraní systému vytvořím sám. Z externích zdrojů použiji sadu ikon Bright Icon Set [Min08] a fotku klávesnice [Moh08], kterou upravím.

5.3 Vrstva aplikační logiky Možnosti práce se systémem jsou určeny možnostmi vrstvy aplikační logiky, protože zcela definuje funkcionalitu systému. Proto je vrstva aplikační logiky z návrhového hlediska nejzajímavější částí systému a stojí za podrobnější vysvětlení. Vrstva aplikační logiky je definována sadou nezávislých rozhraní. Každé rozhraní postihuje ucelenou část funkcionality systému. Ke každému rozhraní je vytvořena třída, která jej

23

implementuje. Systém zde využívá návrhový vzor jedináček14 [Gam95] ve spojení s návrhovým vzorem dependency injection [Fow04] (zde zajištěn rámcem Spring), aby vrstva aplikační logiky umožnila prezentační vrstvě čistý a snadný přístup k funkcionalitě systému. Vrstva aplikační logiky vytvářeného systému je definována následujícími rozhraními: •

EmailService Slouží ostatním částem aplikační logiky pro odesílání e-mailů uživatelům systému. Uplatňuje se při informování o událostech systému a při manipulaci s uživatelskými účty.

•

LoginService Řeší přihlašování a odhlašování uživatelů a informuje, zda je někdo přihlášen pro aktuální komunikaci mezi prezentační vrstvou a vrstvou logiky, případně kdo to je.

•

NotificationService Spravuje přečtené a nepřečtené události jednotlivých uživatelů, vytváří nové. Umožňuje nastavit, o jakých událostech si uživatelé přejí být informováni a jakým způsobem.

•

ResConStatsService Počítá statistiky spotřeb zdrojů.

•

ResourceConsumptionService Vytváří, upravuje a ruší spotřeby zdrojů a poskytuje k nim přístup.

•

ResourceTypeService Umožňuje administrátorovi definovat a spravovat typy zdrojů, jejichž spotřebu má systém sledovat. Poskytuje systému přístup k typům zdrojů.

•

TicketCategoryService Umožňuje administrátorovi definovat a spravovat kategorie pro požadavky zákazníků. Poskytuje systému přístup ke kategoriím.

•

TicketDiscussionService Vytváří a ruší veřejné i interní diskuzní příspěvky k požadavkům a poskytuje k diskuzím přístup.

•

TicketListingService Získává seznamy požadavků (aktivní/uzavřené, pro vlastníky, pro řešitele, všechny). Hledá požadavky dle zadaných kriterií.

14 V anglickém originále „singleton“.

24

•

TicketService Vytváří a upravuje požadavky, poskytuje k nim přístup, mění jejich stav a nastavuje řešitele. Přihlašuje a odhlašuje pozorovatele a získává seznam pozorovatelů požadavku.

•

UserAccountService Vytváří a upravuje uživatelské účty, resetuje hesla a zapíná/vypíná blokaci přístupu uživatelů.

•

UserService Poskytuje přístup k jednotlivým uživatelům (např. dle e-mailu pro účely přihlašování), vyhledává v uživatelích pro účely našeptávačů.

•

UserSettingService Zapisuje a čte uživatelská nastavení (např. preferovaný jazyk).

•

VariableService Zapisuje a čte systémové proměnné (např. titulek v hlavičce systému).

5.4 Iterace Tvorbu systému rozdělím na iterace. Na konci každé iterace by se systém měl nacházet v provozuschopném stavu a měl by nabízet ucelenou část své plánované funkcionality (vždy větší než v předcházející iteraci). Vývoj bude rozdělen na tyto iterace: 1) Základní provozuschopnost Cílem této iterace je umožnit přihlášení do systému, vytvářet a měnit požadavky a prohlédnout si jejich seznam. Bude implementován případ užití Vytvořit požadavek. 2) Diskuze, řešení, sledování, hledání Tato iterace vylepší seznamy požadavků, včetně seznamu vytvořeného hledáním. Bude přidáno sledování požadavků a vypisování pozorovatelů. Na stránce požadavku přibude veřejná a interní diskuze, bude možno požadavky řešit a měnit jejich stav. Budou implementovány případy užití Hledat požadavek, Diskutovat veřejně, Diskutovat interně, Řešit požadavek, Sledovat požadavek. 3) Administrace, spotřeby zdrojů Systém poskytne možnosti spojené se spotřebami zdrojů a bude vytvořena správa uživatelských účtů a všech systémových nastavení. Proběhne implementace případů užití Nastavit systém, Spravovat účty, Zadat spotřebu zdroje, Zobrazit statistiku spotřeb. 25

4) Notifikace Systém bude schopný informovat uživatele o událostech. Budou implementovány případy užití Nastavit notifikace, Prohlédnout notifikace, Přijmout notifikační e-mail.

26

Kapitola 6

Závěr

Byla provedena analýza požadavků na systém podpory služby helpdesk firmy Meridian ITS, s.r.o. Z existujících produktů nebyl žádný shledán vhodným, byl tedy navrhnut nový systém od základů a dle návrhu byl vytvořen.

6.1 Předpoklady naplnění vize Nyní je na místě zhodnotit, zda má vytvořený systém předpoklady naplnit vizi přínosu, která byla na počátku analýzy zformulována.

6.1.1

Snadné vykazování provedené práce

Vykazování práce je široce nastavitelné. Přes rozhraní administrátora lze definovat typy zdrojů, které jsou pro firmu natolik zajímavé, aby sledovala jejich spotřebu. Ke každému požadavku lze vložit údaje o spotřebovaných zdrojích. Účetní a manažeři mají přístup k sumárním údajům o spotřebovaných zdrojích. Výpočet sumárních údajů lze omezit na interval dat, požadavek, zaměstnance nebo zákazníka. Myslím si, že vykazování provedené práce (a obecně spotřebu sledovatelných zdrojů) systém řeší dobře. Po nasazení do ostrého provozu by se mohl například objevit další zajímavý způsob, jakým omezit výpočet sumárních údajů, ale už i jmenované možnosti systému znamenají velký posun oproti současnému stavu ve firmě.

6.1.2

Zviditelnění servisních úkonů ve firmě

Výrazným problémem podniku bylo, že neexistoval snadný způsob zjištění všech aktivních prací a objednávek pro daného zákazníka, což někdy způsobovalo zmatek. Systém obsahuje snadné hledání aktivních požadavků dle zákazníka na více místech: ze seznamu požadavků, z profilové stránky zákazníka, z detailu požadavku a přes speciální stránku dostupnou z hlavního menu. Za předpokladu, že zaměstnanci budou v systému poctivě evidovat úkony pro zákazníky, bude zmíněný problém vyřešen.

27

6.1.3

Jednoduchost pro zákazníky

Na usnadnění práce se systémem byl kladen důraz, obzvlášť z hlediska zákazníků. Jako jeden z hlavních cílů jsme spolu s manažerem ustanovili, aby systém svou složitostí neodradil zákazníky od vkládání požadavků. Vezmeme-li v úvahu využití funkce perzistentního přihlášení, zákazník se dostane k zadání nového požadavku jediným kliknutím na výrazný grafický odkaz. K vytvoření požadavku pak stačí vyplnit tři údaje. K seznamům svých nevyřešených a vyřešených požadavků se dostane též výrazným grafickým odkazem. Počet stránek přístupných zákazníkům byl zredukován na minimum. Dle mého názoru byl cíl jednoduchosti pro zákazníky splněn.

6.1.4

Vedení technické dokumentace

V aktuálním stavu systém vedení dokumentace nepodporuje, protože přáním manažera bylo implementaci odložit, než se systémem podnik nasbírá zkušenosti. Byla však provedena analýza požadavků na dokumentační část systému, včetně určení analytických tříd. Systém byl navržen s vědomím, že se v budoucnu vedení dokumentace přidá, tato změna tedy proběhne bez přepracování stávajících částí systému, které obvykle provází přidávání nových funkcí. [McC05]

6.2 Možnosti dalšího rozvoje Systém bude v blízké době nasazen ve firmě Meridian ITS, s.r.o. Po zavedení proběhne sbírání prvních zkušeností s provozem, které by mohlo vyústit v úpravy systému. Poté se pravděpodobně rozhodne o implementaci dokumentační části systému. V případě, že by systém měl mezi zaměstnanci a zákazníky úspěch, mohl by být rozšířen a upraven tak, aby podporoval data více firem, pak by mohl být poskytován jako služba i dalším podnikům15.

15 Jednalo by se tedy o obchodní model SaaS – Software as a Service.

28

Použité zdroje a literatura [Arl07]

Arlow, J., Neustadt, I.: UML 2 a unifikovaný proces vývoje aplikací. 1. vyd. Brno : Computer Press, 2007. 568 s. ISBN 978-80-251-1503-9.

[Fil09]

Filip, J.: Webové stránky Meridian ITS, s.r.o [online]. Meridian, ITS, s.r.o. [citováno 24. 4. 2009]. Dostupné z URL: .

[Fow04]

Fowler, M.: Inversion of Control Containers and the Dependency Injection pattern [online]. 23. 1. 2004 [citováno 14. 4. 2010]. Dostupné z URL: .

[Gam95]

Gamma, E. aj.: Návrh programů pomocí vzorů: stavební kameny objektově orientovaných programů. 1. vyd. Praha : Grada, 1995. 386 s. ISBN 80-247-03025.

[GNU07a] GNU. The GNU General Public License [online]. c2007 [citováno 1. 5. 2009]. Dostupné z URL: . [GNU07b] GNU. The GNU Affero General Public License [online]. c2007 [citováno 1. 5. 2009]. Dostupné z URL: . [Hil10]

Hillenius, E. et al.: Apache Wicket [online]. Apache Software Foundation. c2009 [citováno 13. 4. 2010]. Dostupné z URL: .

[Kin10]

King, G. et al.: Hibernate [online]. JBoss Community; Red Hat. c2010 [citováno 13. 4. 2010]. Dostupné z URL: .

[Lin00]

Ramirez, A. O.: Three-Tier Architecture [online]. The Linux Journal. 1. 7. 2000 [citováno 11. 4. 2010]. Dostupné z URL: .

[McC05]

McConnell, S.: Dokonalý kód: umění programování a techniky tvorby software. 1. vyd. Brno: Computer Press, 2005. 894 s. ISBN 80-251-0849-X.

[Min08]

Min, T.: Bright! - a free icon set [online]. 15. 5. 2008 [citováno 13. 4. 2010]. Dostupné z URL: .

[Moh08]

Mohan, M.: Keyboard (stock photo) [online]. 29. 6. 2008 [citováno 13. 4. 2010]. Dostupné z URL: .

[One08]

OneOrZero. OneOrZero Task Management and Helpdesk [online]. Verze 1.6.5.5. c2008 [citováno 1. 5. 2009]. Dostupné z URL: .

29

[Ora06]

Oracle. Understanding the Three-Tier Architecture [online]. c2006 [citováno 11. 4. 2010]. Dostupné z URL:

[Ora10a]

Oracle. Java Server Faces [online]. c2010 [citováno 13. 4. 2010]. Dostupné z URL:

[Ora10b]

Oracle. Enterprise Java Beans [online]. c2010 [citováno 13. 4. 2010]. Dostupné z URL: .

[Ora10c]

Oracle. Java Persistence API [online]. c2010 [citováno 13. 4. 2010]. Dostupné z URL: .

[Ora10d]

Oracle. MySQL [online]. c2010 [citováno 13. 4. 2010]. Dostupné z URL: .

[OTR09]

OTRS AG. Open Ticket Request System [online]. Verze 2.3.4. c2009 [citováno 1.5.2009]. Dostupné z URL: .

[Pai08]

Paige, J.: Version 1.0 – a set on Flickr [online]. Poslední aktualizace 11. 9. 2008 [citováno 1. 5. 2009]. Dostupné z URL: .

[Pai09a]

Paige, J.: ColdBrew Helpdesk, Get ColdBrew Helpdesk at SourceForge.net [online]. c2009 [citováno 1.5.2009]. Dostupné z URL: .

[Pai09b]

Paige, J.: coldbrew-helpdesk - Project Hosting on Google Code [online]. c2009 [citováno 1.5.2009]. Dostupné z URL: .

[Phi09]

Phillips, D.: triage - Project Hosting on Google Code [online]. c2009 [citováno 2.5.2009]. Dostupné z URL:

[Pos10]

PostgreSQL Global Development Group. PostgreSQL [online]. c2010 [citováno 13. 4. 2010]. Dostupné z URL: .

[Shi10]

Ship, H. L.: Apache Tapestry [online]. Apache Software Foundation. c2010 [citováno 13. 4. 2010]. Dostupné z URL:

[Son95]

Song, I.-Y., Evans, M., Park, E.K.: A Comparative Analysis of Entity-Relationship Diagrams. Journal of Computer and Software Engineering, 1995, vol. 3, no. 4, s. 427–459. Dostupné z URL: . 30

[Spr10]

SpringSource. Spring [online]. c2010 [citováno 13. 4. 2010]. Dostupné z URL:

[Sta08]

Staníček, Z.: Datové modelování metodou HIT [online]. 17. 9. 2008 [citováno 15. 4. 2010]. Dostupné z URL:

[Toz09]

Tozzo, J.: PHD Help Desk [online]. Verze 1.43. 30. 4. 2009 [citováno 2.5.2009]. Dostupné z URL: .

31