Objektová procesní analýza a inovace informačního systému v podniku Kentico Software s. r. o

Mendelova zemědělská a lesnická univerzita v Brně Provozně ekonomická fakulta

Objektová procesní analýza a inovace informačního systému v podniku Kentico Software s. r. o. Diplomová práce

Vedoucí práce: doc. Ing. Ivana Rábová, Ph.D.

Bc. Ondřej Vasil

Brno 2009

Na tomto místě bych rád poděkoval vedoucí diplomové práce paní doc. Ing. Ivaně Rábové, Ph.D. za její cenné rady a připomínky v průběhu zpracování diplomové práce. Také děkuji panu doc. Ing. Dr. Jiřímu Rybičkovi za poskytnutý styl pro sazbu diplomových prací v systému LATEX.

Zadání

Prohlašuji, že jsem tuto práci vytvořil samostatně za pomoci metodických pokynů vedoucí diplomové práce a s použitím zdrojů, softwaru a dalších podkladů uvedených v diplomové práci.

V Brně dne 22. 5. 2009

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

6

Abstract Vasil, O. The object-oriented process analysis and information system innovation in Kentico Software. Diploma thesis, Brno 2009. The diploma thesis focuses on process analysis in Kentico Software. At the beginning, the business process analysis is made up and Use Case analysis is accomplished. Information system innovation is shown based on the analyses above by creating library administration application. There are presented the most important UML schemes for chosen processes within the library administration model. The alternative solution is compared and the economical review is made at the end.

Abstrakt Vasil, O. Objektová procesní analýza a inovace informačního systému v podniku Kentico Software s. r. o. Diplomová práce, Brno 2009. Diplomová práce se zaměřuje na procesní analýzu ve firmě Kentico Software s. r. o. Je zpracována analýza podnikových procesů a ukázána Use Case analýza. Na jejich základě je provedena inovace informačního systému vytvořením aplikace pro knihovní administrativu. Pro vybrané procesy jsou sestaveny nejdůležitější UML diagramy. Závěr práce stručně hodnotí alternativní řešení a je provedeno ekonomické hodnocení.

7

OBSAH

Obsah 1 Úvod a cíl práce 1.1 Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Přehled literatury 2.1 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Historie UML . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Metodika UP . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Metodika Select Perspective . . . . . . . . . . . . . . . . . . 2.5 Diagramy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.1 Diagram tříd - Class diagram . . . . . . . . . . . . . 2.5.2 Diagram případů užití - Use Case diagram . . . . . . 2.5.3 Sekvenční diagram - Sequence diagram . . . . . . . . 2.5.4 Komunikační diagram - Communication diagram . . 2.5.5 Diagram aktivit - Activity diagram . . . . . . . . . . 2.5.6 Stavový diagram - State diagram . . . . . . . . . . . 2.5.7 Entitně-relační diagram - Entity-relationship diagram 2.5.8 Model podnikových procesů - Business process model 2.6 CASE nástroje - Enterprise Architect . . . . . . . . . . . . . 2.7 Použité technologie . . . . . . . . . . . . . . . . . . . . . . . 2.8 Ekonomická efektivnost zavedení IS . . . . . . . . . . . . . . 3 Analyzovaná firma 3.1 Předmět podnikání . . . . 3.2 Vize, poslání, produkt a cíl 3.3 CMS . . . . . . . . . . . . 3.3.1 Kentico CMS . . . 3.4 Organizační struktura . . 3.5 Současný stav IS . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

4 Vlastní práce 4.1 Byznys modelování současného stavu . . . . . . . . . . . . . 4.1.1 Základní pohled procesu vývoje produktu . . . . . . 4.1.2 Příprava a plánování nové verze . . . . . . . . . . . . 4.1.3 Implementace modulu . . . . . . . . . . . . . . . . . 4.1.4 Kontrola projektu . . . . . . . . . . . . . . . . . . . . 4.1.5 Vypuštění nové verze . . . . . . . . . . . . . . . . . . 4.2 Use Case model současných podnikových procesů . . . . . . 4.2.1 Náprava defektu . . . . . . . . . . . . . . . . . . . . 4.3 Zlepšení části podnikového procesu - knihovní administrativa 4.4 BPM - knihovní administrativa . . . . . . . . . . . . . . . . 4.5 Use Case - knihovní administrativa . . . . . . . . . . . . . .

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

. . . . . .

. . . . . . . . . . .

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

. . . . . .

. . . . . . . . . . .

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

. . . . . .

. . . . . . . . . . .

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

. . . . . .

. . . . . . . . . . .

9 9 9

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

11 11 11 12 13 13 14 16 18 19 20 21 22 23 24 25 26

. . . . . .

28 28 29 29 29 30 33

. . . . . . . . . . .

34 34 34 37 38 42 42 44 44 47 47 48

8

OBSAH

4.5.1 Use Case - rezervace knihy . . . . 4.6 Sekvenční diagram - rezervace knihy . . 4.7 Diagram tříd - knihovní administrativa . 4.8 Diagram aktivit - rezervace knihy . . . . 4.9 Stavový diagram - třída kniha . . . . . . 4.10 ERD diagram - knihovní administrativa 4.11 Funkce systému . . . . . . . . . . . . . . 4.12 Vylepšení systému knihovny . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

48 51 52 54 55 56 58 60

5 Ekonomické hodnocení navrženého řešení 61 5.1 Alternativní řešení . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 6 Závěr

62

7 Literatura

63

Přílohy

65

A Slovníček pojmů

66

1

ÚVOD A CÍL PRÁCE

1 1.1

9

Úvod a cíl práce Úvod

Podnikový informační systém ovlivňuje samotné základy fungování společnosti, která jej využívá. Informační systém je doslova páteří firmy, bez které si nelze samotnou existenci vůbec představit. Proto je důležité se o něj starat a pečovat o jeho správný vývoj. Zlepšování podnikových procesů je dnes nezbytností pro udržení firmy na konkurencí přeplněném trhu. Takové procesní změny dokonce vyvolávají samotní zákazníci. Ti totiž žádají stále lepší produkty a pokud je nedostanou, mají možnost se obrátit na další konkurenční firmy. Nejinak je tomu v IT odvětví, ve kterém se mnou modelovaná firma Kentico Software s. r. o pohybuje. I její informační systém musí reflektovat všechny podnikové procesy tak, aby byl vývoj samotného produktu co nejefektivnější. Firma má velikou výhodu v tom, že její hlavní výrobek lze po sérii adekvátních úprav s výhodou použít i jako samostatný informační systém. Nemá tedy dodatečné náklady na nákup a správu zvláštního software, který by zajišťoval informační systém. Díky dnes velmi populárním analytickým nástrojům lze podnikové procesy velmi dobře popsat a pochopit jejich vzájemnou provázanost. Jedná se především o nástroje typu Computer Aided Software Engineering (CASE), což v překladu znamená počítačem podporované softwarové (systémové) inženýrství nebo–li vývoj software s využitím počítačové podpory. CASE nástroje jsou nástroje, které primárně umožňují: modelování IT systému pomocí diagramů (člověk lépe chápe obrázek než složitě psané slovo), generování zdrojového kódu z modelu (usnadňuje práci programátorům), zpětné vytvoření modelu podle existujícího zdrojového kódu (reverse engeneering), synchronizaci modelu a zdrojového kódu či dokonce vytvoření dokumentace z modelu. Úspěch využití CASE nástrojů záleží mimo jiné na vybrané metodice a způsobu zpracování informací a jejich interpretaci.

1.2

Cíl práce

Cílem této práce je analyzovat firemní procesy v reálném podniku (Kentico Software s. r. o.) a provést inovaci části informačního systému. Pro analýzu procesů budu využívat nejdůležitějších diagramů modelovacího jazyka UML spolu s jeho rozšířením pro byznys modelování podnikových procesů. Výslednou analýzu využiji jako podklad pro návrh a realizaci betaverze aplikace knihovní administrativy, která by měla zefektivnit úkony spojené s fungováním knihovny. Tato aplikace bude mít podobu plně integrovaného modulu v rámci existujícího informačního systému. Jako nástroj prezentace návrhu bude sloužit programový prostředek Enterprise Architect od společnosti Sparx System. Aplikace bude vytvořena s použitím objektového programovacího jazyka C# v prostředí ASP.NET a relační databáze MSSQL. Provedené řešení bude následně srovnáno s typově podobným řešením a provedeno

1.2

Cíl práce

10

ekonomické hodnocení projektu. Součástí práce je též přehled literatury, která se touto tématikou zabývá, jakož i popis použitých technologií.

2

PŘEHLED LITERATURY

2

11

Přehled literatury

2.1

UML

Modelovací jazyk UML1 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í stejné formální syntaxe. Tím umožňuje výsledky 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ů uživatelů 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ý systém. UML je také jazyk pro vizualizaci, specifikaci, stavbu a dokumentaci softwarových systémů. (Kanisová, Müller, 2006) Jazyk UML je univerzální jazyk pro vizuální modelování systémů. Byl navržen proto, aby spojil nejlepší postupy modelovacích technik a softwarového inženýrství. Je navržen tak, aby jej mohly implementovat všechny nástroje CASE2 . Diagramy vytvořené v jazyku UML jsou srozumitelné pro lidi, ale navíc je mohou snadno interpretovat i programy CASE. Jak zdůrazňuje Arlow a Neustadt (Arlow, Neustadt, 2007, strana 28) je nesmírně důležité uvědomit si, že jazyk UML nenabízí žádný druh metodiky modelování. Samotný jazyk UML však poskytuje pouze vizuální syntaxi, kterou můžeme využít při sestavování svých modelů. Jazyk UML není vázán na žádnou specifickou metodiku nebo životní cyklus. Lze jej použít společně se všemi existujícími metodami.

2.2

Historie UML

Historie jazyka UML je velice spletitá a v jeho počátcích trochu chaotická. Existovala spousta jazyků pro vizuální modelování a metodiky. Pokusím se zde uvést ty nejdůležitější mezníky jeho vývoje. Modelovací jazyk UML je výsledkem snažení analytiků a designerů, kteří v průběhu 80. a 90. let vytvářeli metody umožňující popsat objektově orientovanou analýzu a návrh. V polovině 90.˙let byly velmi rozšířené metody OMT3 , jejich autory byli Booch a Rumbaugh, a dále metodika Ivara Jacobsona - Objectory. (Kanisová, Müller, 2006) V roce 1995 byly zahájeny práce na sjednocení různých metod a syntaxí pro modelování pod záštitou firmy Rational. Výsledkem tohoto snažení bylo v roce 1997 vytvoření první verze modelovacího jazyka UML. (Kanisová, Müller, 2006) V dalších letech se díky sdružení OMG4 podařilo vytvořit specifikaci RFP5 , která sloužila k standardizaci objektově orientovaného modelování a následný rok 1

UML – Unified Modeling Language - unifikovaný modelovací jazyk CASE – Computer-Aided Software/System Engineering 3 OMT – Object Modeling Technique 4 OMG – Object Management Group 5 RFP – Request For Proposal 2

2.3

Metodika UP

12

1997 se stává důležitým mezníkem, kdy bylo UML přijato jako průmyslový standard objektově orientovaného jazyka pro vizuální modelování. V roce 2005 vznikla specifikace jazyka UML 2. V jazyce UML 2 bylo zavedeno mnoho nových prvků vizuální syntaxe. Některé z nich nahrazují a objasňují existencí syntaxi verzí UML 1.x. Jiné jsou úplně nové a ztělesňují novou sémantiku přidanou k jazyku. (Arlow, Neustadt, 2007, strana 30)

2.3

Metodika UP

Proces vývoje softwaru známý rovněž jako metodika tvorby softwarového vybavení6 definuje při vývoji softwaru otázky kdo, co, kdy a jak. Projekt UML vznikl z potřeby nabídnout jak vizuální jazyk, tak proces tvorby softwarového vybavení. To, co známe dnes pod pojmem UML, je jazykovou částí projektu, metodika Unified Process je částí procesní. Narozdíl však od jazyka UML není metodika UP standardem organizace OMG. Tato metodika je založena na metodách Ericsson7 , Rational8 a na dalších zdrojích vycházejících z nejlepších postupů. (Arlow, Neustadt, 2007, strana 53) Důležité je pochopit, že metodika UP je založena na iterativním a přírůstkovém procesu. Celý velký projekt se rozdělí na menší části, které jsou jednodušší na správu a je pak pravděpodobnější úspěšné dokončení. Arlow (Arlow, Neustadt, 2007, strana 60) uvádí pro takovou podčást označení „miniprojektÿ. Každý z „miniprojektůÿ je považován za iteraci. Ta obsahuje prvky softwarového produktu jako: Plánování, analýzu a návrh, implementaci, integraci a testování interní nebo externí uvedení. Konkrétně pro metodiku UP jsou v každé iteraci definovány následující pracovní postupy: • Požadavky - Zachycují to, co by měl systém dělat. • Analýza - Vybroušení požadavků a jejich strukturování. • Návrh - Realizace požadavků v architektuře systému. • Implementace - Tvorba softwaru. • Testování - Ověření, zda implementace funguje tak, jak se od ní očekává. (Arlow, Neustadt, 2007, strana 60) Metodika UP se tedy skládá ze čtyř po sobě jdoucích fází, z nichž každá končí hlavním milníkem. Důležité je, že v každé fázi probíhá iterace s tím, že se mění objem prací vykonávaných v každém z pěti pracovních postupů. Viz obrázek 1. 6

SEP – Software Engineering Process Ericsson approach, 1967 8 Rational Objectory Process, 1996 – 1997 7

2.4

Metodika Select Perspective

13

Obr. 1: Struktura metodiky UP, zdroj: Arlow, Neustadt, 2007, strana 62 Pozn.: R - Requirements, A - Analysis, D - Design, I – Implementation, T - Testing

2.4

Metodika Select Perspective

Metodika Select Perspective je objektově orientovaná metodika vytvořená Stuartem Frostem a Paulem Allenem z firmy SELECT Software Tools. Vychází z kombinace Objektově orientovaných technik modelování (OMT) Jamese Rumbaugha a Objektově orientovaného softwarového inženýrství (OOSE) Ivara Jacobsona. Select Perspective zahrnuje kromě UML i modelování firemních procesů a datové modelování. Projekt návrhu informačního systému obsahuje tři základní fáze, a to uspořádání (Align), architektury (Architect) a sestavení (Assemble). V každé fázi je vytvořeno několik přírůstků (částí návrhu, které produkují nějaký viditelný výsledek). Fáze uspořádání zabezpečuje dodržení byznys požadavků na systém. Fáze architektury vytváří komponentově orientovanou architekturu. Fáze sestavení dodává řešení složením vývojových částí a komponent. Cílem fáze uspořádání je propojit byznys procesy a programové řešení. Tato fáze obsahuje tyto hlavní aktivity. Musí být provedena analýza byznys procesů díky níž mohou být identifikovány důležité systémové funkce (Use Case). Dále se provádí základní rozhodnutí o architektuře systému (např. o komponentách technické infrastruktury). Je zde také vhodné rozdělit pole aplikace na funkcionální segmenty (komponenty), které pak mohou byt vyvíjeny paralelně. Ve fázi architektury je hlouběji rozpracovaná architektura byznys procesů a technická architektura. Fáze sestavení se detailněji zabývá designem, vývojem a nasazením aplikace. Pro kompletaci a správu komponent se využívá model „vytvořit-spravovat-užívatÿ. (Objektová analýza, návrh a programování, 2005)

2.5

Diagramy

Jazyk UML se skládá z mnoha grafických prvků, které se dají vzájemně kombinovat do podoby diagramů. Účelem diagramů je představit několik pohledů na systém. Tato skupina pohledů se nazývá model. Model jazyka UML popisuje, co má systém dělat. Neříká nám však, jak systém implementovat. (Schmuller, 2001, strana 16)

2.5

Diagramy

14

Ve všech nástrojích CASE založených na jazyku UML jsou každý nově vytvořený předmět nebo nově vytvořená relace automaticky přidávány do vznikajícího modelu. Diagramy jsou okna nebo pohledy na model. Diagram není model! Celkem existuje třináct různých typů diagramů UML. (Arlow, Neustadt, 2007, strana 37)

Obr. 2: Rozdělení diagramů, zdroj: Arlow, Neustadt, 2007, strana 37

Uvedené diagramy je možné rozdělit na ty, které modelují statickou strukturu systému (kde jsou zachyceny předměty a strukturní asociace mezi předměty) a na ty, které modelují dynamickou strukturu (kde je zachycen způsob, jímž na sebe tyto předměty působí). Podrobné rozdělení je znázorněno na obrázku 2. Systém je možné namodelovat za použití různých diagramů, které jazyk UML nabízí. Pro modelování podnikového systému v této práci jsem použil následujících diagramů: diagram podnikových procesů9 , Use Case diagram10 , diagram tříd, sekvenční diagram, diagram aktivit, stavový diagram a ERD diagram. 2.5.1

Diagram tříd - Class diagram

Řepa označuje diagram tříd jako interní model a definuje ho následovně – Diagram tříd je základním diagramem UML, slouží popisu a klasifikaci tříd objektů a jejich vzájemných vztahů. (Řepa, 2007, strana 148) Diagramy tříd poskytují modelářům tři důležité objektově orientované konstrukce: strukturu dědičnosti, strukturu asociací a vztah mezi celkem a částmi. (Page-Jones, 2001, stana 100) Kanisová definuje diagram tříd poměrně detailněji - Diagramy tříd zobrazují statickou stránku systému, především vztahy mezi třídami. Vztahy, které jednotlivé třídy navzájem pojí, jsou asociace, agregace, kompozice a specializace/generalizace. Podřízenost jednoho objektu vůči druhému je v analýze chápána dvojím způsobem, buď jako agregace, nebo jako kompozice. (Kanisová, Müller, 2006, stana 55) 9 10

Též označovaný zkráceně BPM – Business Process Model Dále uváděn pod jedním z označení - buď diagram přípaů užití nebo Use Case diagram.

2.5

Diagramy

15

Arlow pak vysvětluje, jak vypadá analytická třída - analytické třídy: • Reprezentují křehkou abstrakci problémové domény. • Měly by mapovat pojmy skutečného světa. Nejdůležitějším aspektem analytické třídy je skutečnost, že by měla jednoznačně mapovat určitý pojem skutečného obchodního světa, jako je třeba „zákazníkÿ, „produktÿ nebo „účetÿ. (Arlow, Neustadt, 2007, strana 173) Na začátku projektu při analytické činnosti (při sestavování diagramu tříd) hledáme objekty v problémové oblasti. Třídy objektů pak představují zobecnění reálných objektů modelovaných v zájmové oblasti. Každý objekt poskytuje služby prostřednictvím svých operací. Minimální podoba analytické třídy se skládá z následujících součástí: Název Obsahuje název třídy, který je povinný. Atributy Atribut jakožto nositel informací o objektu je definován svým jménem, formátem a viditelností. Název atributu jednoznačně pojmenovává danou vlastnost objektu. Dále pak definujeme formát atributu. Při modelování analytického návrhu máme většinou k dispozici formáty běžně používané v objektových vývojových prostředích (např. integer, long, array, boolean atd.). Poslední charakteristikou atributů objektové třídy je jejich viditelnost. V UML rozlišujeme tyto základní typy: 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í pouze přístup 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 jejích potomcích. Operace Nedílnou součástí struktury objektu je jeho chování, které je definováno operacemi. Některé z těchto operací poskytují rozhraní ostatním objektům, které požadují služby tohoto objektu. Operace, stejně jako atributy, mají svou charakteristiku. Ta je dána jejich názvem seznamem parametrů a návratovými hodnotami. Stereotypy Stereotypy jsou založeny na existujících elementech jazyka UML a upravují jejich význam. Každý stereotyp se vytváří přidáním dvojice lomených závorek s názvem stereotypu k původnímu elementu – «Název sterotypu». Mohou být zobrazeny, pokud vylepšují model. (Kanisová, Müller, 2006, strana 56) Stereotyp je meta-třídou UML, pomocí níž lze definovat virtuální podtřídy standardních meta-tříd UML s novými meta-atributy a přidaným významem. Stereotypy tak umožňují zavádět nové typy elementů modelu. Lze si tak vytvořit nový stereotyp a ten pak přiřadit k vybranému elementu modelu. Každý stereotyp definuje

2.5

Diagramy

16

určitou množinu vlastností, které bude mít element daného stereotypu a pravidla, která musí element držet. (Řepa, 2007, strana 145) 2.5.2

Diagram případů užití - Use Case diagram

Schmuller (Schmuller, 2001, strana 18) definuje případ užití (Use Case) následovně – případ užití je popis chování systému z pohledu uživatele. Pro vývojáře systému je to cenný nástroj: je to osvědčený způsob shromáždění údajů o požadavcích systému z hlediska uživatele. Obzvláště důležité je to v případě, kdy je nutné vytvořit systém, který by mohli používat normální lidé (nejenom počítačoví maniaci). Přesněji popisuje Use Case diagram Řepa - Diagram Use Case, původně v UML určený ke specifikaci funkčních požadavků a uživatelského rozhraní informačního systému, je chápán jako model, popisující podnikové procesy a jejich interakce s aktéry. Tento model je označován jako tzv. Externí model, sloužící popisu vztahů organizace s okolím. (Řepa, 2007, strana 147) Sestavení seznamu případů užití je jedním z hlavních cílů systémové analýzy. S takovým seznamem je poté možné dále pracovat a využívat ho např. ke katalogizování, je možné se na něj odkázat. Díky němu je možné systém popsat tak, jak ho vidí uživatel. Jak uvádí autor Arlow, modelování případů užití se skládá z následujících aktivit: • Nalezení hranic systému. • Vyhledání aktérů. • Nalezení případů užití. • Opakování uvedeného postupu, dokud nedojde k ustálení případů užití, aktérů a hranic systému. (Arlow, Neustadt, 2007, strana 91) Po provedení výše uvedených aktivit získáme sestavený model případu užití, který obsahuje následující komponenty: • hranice systému, • aktéry, • případy užití, • relace • a volitelně slovníček pojmů11 Hranice systému První věcí, kterou musíte udělat, přemýšlíte-li o tvorbě softwarového systému, je stanovení jeho hranic. Jinými slovy to znamená, že musíte určit, co je součástí systému a co naopak není jeho součástí. Stanovení hranic systému má obrovský dopad na funkční požadavky (a leckdy i na požadavky nefunkční). (Arlow, Neustadt, 2007, strana 92) 11

Pro praktickou část byl sestaven slovníček pojmů – viz přílohu A.

2.5

Diagramy

17

Obecně lze pod pojmem okolí systému (subjekt12 ) rozumět uživatele, procesy a vztahy, jež sice systém ovlivňují, ale nejsou jeho přímou součástí. Aktéři Pod pojmem aktor je důležité přestavit si roli, kterou může v systému hrát mnoho osob nebo jiný systém. Aktorem není nikdy konkrétní osoba. Jedna konkrétní osoba může v průběhu práce vystupovat ve více rolích. Cockburn aktéry rozděluje podrobněji. Podle něj aktéry mohou být: • účastníci systému, • primární aktéři případu užití, • sám vyvíjený systém, • pomocní aktéři případu užití, • interní aktéři - komponenty systému. (Cockburn, 2005, strana 64) Aktér specifikuje roli, kterou určitá externí entita přijímá v okamžiku, kdy začíná daný systém bezprostředně používat. Může vyjadřovat roli uživatele, roli dalšího systému, který se dotýká hranic vašeho systému. V UML 2 mohou aktéři zastupovat jiné subjekty, což umožňuje propojit různé modely případů užití. Aktéři jsou vůči systému externími entitami. (Arlow, Neustadt, 2007, strana 93) V rámci firemních procesů vystupuje řada firemních aktérů. Ne každý z nich ale komunikuje s daným informačním systémem. Pod pojmem aktér budeme rozumět roli, ve které vystupuje uživatel v rámci své komunikace se systémem. (Kanisová, Müller, 2006, strana 37) V této souvislosti je zajímavou skutečností fakt, že pokud je potřeba modelovat něco, co se systému stane v určitém časovém bodě, je možno zavést jako aktéra čas. Zároveň je ale potřeba, aby tato událost nebyla způsobena žádným jiným aktérem. Případy užití (Use Case) Velmi hezky popisuje případ užití Cockburn - Případ užití představuje dohodu mezi účastníky a uživateli systému o chování systému. Případ užití popisuje chování systému za různých situací ve formě reakcí systému na požadavky jednoho z uživatelů systému, nazývaného primární aktér. Primární aktér vyvolává v rámci případu užití interakci se systémem za účelem dosažení určitého cíle. Systém odpovídá způsobem, při němž chrání zájmy všech uživatelů. V závislosti na zvláštních požadavcích a podmínkách doprovázejících původní požadavek se mohou objevit odlišné způsoby chování, neboli scénáře. Případy užití sdružují tyto rozdílné scénáře v jeden celek. (Cockburn, 2005, strana 19) Arlow pro případy užití udává 2 důležité zásady: • Případy užití jsou vždy iniciovány aktérem. • Případy užití jsou vždy napsány z pohledu aktéra. 12

UML 2 označuje nově hranice systému jako subjekt.

2.5

Diagramy

18

(Arlow, Neustadt, 2007, strana 95) Pro popis a definici případu užití považuje Kanisová za nutné definovat nejprve pojem scénář případu užití. Scénář je sekvence kroků popisujících interakci mezi aktérem a systémem. Poté je možné definovat případ užití jako sadu scénářů, které spojuje dohromady společný cíl. V praxi bývá téměř pravidlem, že případ užití má základní scénář typu „všechno jde hladceÿ a řadu alternativních scénářů, které představují postup při zjištění různých chyb, mimořádných stavů a z nich odvozených větví průchodu. (Kanisová, Müller, 2006, strany 39 a 41) Toto všechno směřuje k ulehčení práce při komunikaci s uživateli systému. Případy užití nám zjednoduší pochopení jejich potřeb a tak nám umožní přesnější namodelování systému. Relace V diagramu případů užití se kromě vztahů mezi případy užití a aktéry setkáváme ještě s dalšími důležitými vztahy: • Relace «include» – objevuje se tam, kde existuje podobná nebo stejná část sekvence scénáře opakující se ve více případech užití. • Relace «extend» – tímto typem relace přidává rozšiřující případ užití nové, doplňkové chování do základního případu užití. Základní případ užití je sám o sobě zcela soběstačný. • Generalizace případů užití - umožňuje převést chování společné pro více případů užití do rodičovského případu užití (Kanisová ovšem tuto techniku příliš nedoporučuje kvůli následné nepřehlednosti). (Kanisová, Müller, 2006, strany 45 a 46) Arlow popisuje výše uvedené relace podobně. Avšak dodává – Obecně platí, že byste měli všechny modely udržovat co nejjednodušší. Uvedené relace používejte s rozvahou a jedině tam, kde zlepšují celkovou srozumitelnost modelu případu užití. Klíčová slova «include» a «extend» vás mohou snadno smést „přes palubuÿ. (Arlow, Neustadt, 2007, strana 116) Slovníček pojmů Slovníček pojmů je velice důležitou součástí modelování systému. Díky němu je možné se při práci s kolegy a též uživateli samotnými ujednotit na použitém názvosloví. Slovníček pojmů poskytuje lexikon klíčových obchodních termínů a definicí. Jednotlivým položkám v tomto slovníku by měli rozumět všichni, kdo se na projektu určitým způsobem podílejí - včetně uživatelů. (Arlow, Neustadt, 2007, strana 97) 2.5.3

Sekvenční diagram - Sequence diagram

Sekvenční diagram lze v literatuře najít též jako diagram posloupnosti. Oproti statickým diagramům se sekvenční diagramy nezabývají pouze jediným objektem a změ-

2.5

Diagramy

19

nami, kterými tento objekt prochází. Je tedy možné popsat to, jak objekt spolupracuje a komunikuje s jinými objekty ve svém okolí. Patří mezi diagramy interakce objektů. Sekvenční diagram je typ diagramu interakce objektů, který zdůrazňuje časovou posloupnost vztahů mezi statickými objekty. S pomocí sekvenčního diagramu dokáži ihned určit, co kdo komu říká a kdy. (Page-Jones, 2001, strana 130) Arlow vysvětluje funkci sekvenčních diagramů následovně: Sekvenční diagramy zdůrazňují časově orientovanou posloupnost zpráv předávaných mezi objekty. Uživatelé většinou lépe a rychleji porozumí sekvenčním diagramům než diagramům komunikačním, protože jsou přehlednější. Sekvenční diagramy znázorňují interakce mezi čárami života jako časově uspořádanou posloupnost událostí. (Arlow, Neustadt, 2007, strana 253) Schmuller popisuje, jak tento diagram vypadá: Diagram sekvencí se skládá z objektů zakreslených běžným způsobem (jako obdélníčky s podtrženým jménem), ze zpráv zakreslených jako plné šipky a z času, který je znázorněn vertikálním postupem v diagramu. Objekty se umisťují do horní části diagramu a zakreslují se vedle sebe zleva doprava. Je vhodné je seřadit tak, aby byl výsledný diagram na pohled co nejjednodušší. Směrem dolů od každého objektu míří přerušovaná čára, která se nazývá životočára. Podél životočáry je položen úzký obdélníček nazývaný aktivace. Délka obdélníku naznačuje, jak dlouho aktivace trvá. (Schmuller, 2001, strana 100) Sekvenční diagramy umožňují rovněž znázornění vazeb mezi modelovanými případy užití, tedy vazeb typu «include» nebo «extend». Na diagramech se k tomu používá symbol sondy. Sonda představuje odkaz na jiný případ užití, pro který může být zpracován vlastní sekvenční diagram. (Kanisová, Müller, 2006, strana 70) 2.5.4

Komunikační diagram - Communication diagram

Ve starší verzi UML 1 je uváděn tento diagram pod názvem diagram spolupráce (Collaboration diagram). Od verze jazyka UML 2 se již nazývá komunikační diagram. Tento diagram se podobá předešlému sekvenčnímu diagramu. Patří rovněž do skupiny diagramů interakce objektů. Umí tedy zobrazit interakce mezi objekty avšak lehce odlišně. Proto se doporučuje používat ho spolu se sekvenčním diagramem. Zobrazuje jednotlivé objekty spolu se zprávami, které zasílají ostatním objektům. Zmíněné dva typy diagramů jsou podobné, dokonce jsou významově ekvivalentní. To znamená, že obsahují stejné informace a je možné převést diagram sekvencí na odpovídající diagram spolupráce13 a zase nazpátek. Zatímco diagram sekvencí klade při zobrazení důraz především na pořadí jednotlivých událostí, diagram spolupráce zdůrazňuje spíše kontext a uspořádání spolupracujících objektů. Rozdíl lze charakterizovat ještě jinak: Diagram sekvencí popisuje, co se děje v čase, zatímco diagram spolupráce popisuje, co se děje v prostoru. (Schmuller, 2001, strana 113) 13

Resp. komunikační diagram ve verzi UML 2. Platí i pro všechny další výskyty.

2.5

Diagramy

20

Page-Jones popisuje komunikační diagram následovně: Diagram spolupráce14 má tendenci nabývat volnější a flexibilnější formy v tom, jak se kreslí. Rovněž dává stejnou váhu statickým vztahům mezi objekty a dynamickým posíláním zpráv mezi objekty. Diagram posloupnosti je na druhou stranu těsněji organizován a zdůrazňuje časovou sekvenci. (Page-Jones, 2001, strana 123) Jak tento diagram vypadá ve verzi UML 2 se dovídáme v Arlowi, který popisuje komunikační diagram pouze jako podmnožinu sekvenčních diagramů a říká, že tento diagram zdůrazňuje strukturální vztahy mezi objekty. (Arlow, Neustadt, 2007, strana 253) Dále Arlow říká: Komunikační diagramy zdůrazňují strukturální aspekty interakce - způsob spojení životních čar. V UML 2 jsou ve srovnání se sekvenčními diagramy sémanticky poměrně slabé. (Arlow, Neustadt, 2007, strana 267) Porovnání sekvenčních a komunikačních diagramů Kanisová poměrně hezky shrnuje rozdíly obou výše zmíněných diagramů - sekvenčního diagramu a diagramu komunikace - Z praktických zkušeností můžeme doporučit spíše sekvenční diagramy, neboť oceňujeme jejich přehlednost v sekvenci zpracování. Je na nich velmi dobře vidět pořadí probíhání akcí a umožňují zapisovat k jednotlivým krokům slovní popis korespondující se scénářem daného případu užití. (Kanisová, Müller, 2006, strana 75) Vychází při tom z předpokladu, že oba diagramy popisují stejný případ užití. Popis diagramu zde uvádím pouze pro ilustraci. Na radu Kanisové se budu věnovat jen sestavení sekvenčního diagramu. 2.5.5

Diagram aktivit - Activity diagram

Diagram aktivit slouží k modelování podnikových (business) procesů nebo dynamické části modelu (například výpočetní algoritmy). Mohou být „autonomníÿ a reprezentovat proces nebo chování operace. Jednotlivé operace mohou být odděleny horizontálně nebo vertikálně. (Objecteering, 2008) Arlow připodobňuje tento diagram k vývojovým diagramům – Diagramy aktivit jsou „objektově orientovanými vývojovými diagramyÿ. Díky nim lze procesy modelovat jako aktivitu, která se skládá z kolekce uzlů spojených hranami. Ve specifikaci UML 2 mají diagramy aktivit úplně novou sémantiku založenou na Petriho sítích. Existují dvě základní výhody: • Formalismus Petriho sítí nabízí větší přizpůsobivost při modelování různých typů cest. • Nyní lze v jazyce UML zřetelně odlišit diagramy aktivit od stavových automatů. (Arlow, Neustadt, 2007, strana 286) 14

Opět čti a mysli komunikační diagram.

2.5

Diagramy

21

Oddíly v activity diagramu mohou obsahovat své okraje, „plavecké dráhyÿ15 mohou být v případě, že je jejich popis příliš nešikovný, obsahovat dodatečné popisy, oddíly mohou být hierarchicky nebo multidimenzionálně řazeny. (Jan [Zubíček.eu], 2006) Vrana konstatuje, že se diagram aktivit podobá stavovému diagramu, a co je zajímavé, že nahrazuje diagram datových toků - Do jisté míry připomínají variantu stavových diagramů, kde můžeme navíc modelovat tzv. aktivity. Aktivita je synchronní - následný přechod k další aktivitě je vyvolán dokončením aktivity, zatímco ve stavu se čeká na vnější událost. Používají se pro dokumentaci případu užití (jako tzv. workflow). Nahrazují do určité míry v UML neexistující diagramy datových toků. Proti stavovým diagramům mohou navíc kromě akcí obsahovat ještě symbol „rozhodnutíÿ, kde je výběr přechodu vázán na přidruženou podmínku. (Vrana, Richta, 2005) Kanisová vyjmenovává jednotlivé elementy diagramu aktivit - Na diagramech aktivit se setkáte s těmito symboly: • Akce - Jádrem diagramů aktivit jsou stavy akcí nebo také aktivity. Za aktivitu přitom považujeme stav dělání čehokoliv. Stav akce je dále nedělitelnou jednotkou diagramu aktivit. • 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 ke druhému. • Hodnocení přechodů - Dalším důležitým elementem diagramů aktivit je hodnocení přechodu, pomocí kterého můžeme přerušit lineární zpracování. Termín „hodnocení přechoduÿ se zde používá pro vyjádření logické podmínky, která podmiňuje konkrétní přechod. • Rozvětvení - Nebo též rozcestí je právě tím prvkem diagramů aktivit, který umožňuje modelovat paralelní chování. Přitom dochází k rozvětvení přechodu na několik paralelně běžících vláken, které se následně opět spojí. • Plavecké dráhy - Diagramy aktivit až dosud modelovaly chování procesů, ale nevypovídaly nic o tom, kdo provádí jednotlivé aktivity. Pro modelování problémové oblasti to znamená, že diagramy aktivit nijak nespecifikují, kdo - jaká osoba nebo jaké oddělení - je zodpovědný za konkrétní aktivity. Abyste mohli použít plavecké dráhy, musíte upravit vaše diagramy aktivit do vertikálních pruhů vzájemně oddělených čarami. Každá taková dráha potom reprezentuje zodpovědnost konkrétní třídy, oddělení nebo osoby. (Kanisová, Müller, 2006, strany 95 – 100) 2.5.6

Stavový diagram - State diagram

Velmi pěkně definuje stavový diagram Schmuller - Jednou z možností, jak popsat systémové změny, je prohlásit, že jeho jednotlivé objekty mění v čase svůj stav. Tato změna stavu je reakcí na události či na prostý fakt, že čas ubíhá. Všechny tyto změny lze popsat tzv. stavovým diagramem. Stavový diagram dokáže reprezentovat 15

Swimlane – obdélníkové oddíly v activity diagramu

2.5

Diagramy

22

všechny stavy, do nichž se objekt může dostat, a také podmínky přechodů mezi jednotlivými stavy. Stejně tak je možné zadat počáteční a koncový stav každého objektu. (Schmuller, 2001, strana 89) Stavový diagram lze použít pro popis dynamiky objektu, pokud má tento objekt dynamické chování. Každý objekt, který se může nacházet v různých stavech, by měl mít svůj stavový model. Stavové diagramy lze dále použít pro popis metody třídy, pokud známe algoritmus, kterým má být realizována. Často se stavové diagramy používají pro popis protokolu o komunikaci s jiným systémem či objektem. (Vrana, Richta, 2005, strana 101) Základem stavových diagramů jsou tedy stavy objektů, které se mění v čase. Ty popisuje Kanisová - Stav objektu můžeme charakterizovat tak, že se jedná o konkrétní situaci, která nastala za doby života objektu. Tato situace je dále charakterizována tak, že během ní objekt vyhovuje nějaké podmínce, realizuje konkrétní operaci nebo třeba jen čeká na příchod události - stimulu. Tímto stimulem bývá událost, ale může to být rovněž požadavek na operaci. Objekt v průběhu svého života mění stav. Stav objektu je dán hodnotami atributů objektu, aktuálními spojeními s ostatními objekty a právě prováděnou operací. (Kanisová, Müller, 2006, strana 87) Arlow k základním prvkům stavových diagramů přidává kromě stavu ještě událost - „specifikaciÿ určitého výskytu něčeho v čase a prostoru. A dále Přechod - posun z jednoho stavu do jiného v důsledku nějaké události. (Arlow, Neustadt, 2007, strana 428) Symbolika stavového diagramu je velice jednoduchá. Stav je znázorněn jako obdélník se zakulacenými rohy (může být rozdělen na tři části: název, stavové proměnné, činnosti). Přechod mezi stavy symbolizuje plná šipka. Plný kroužek pak značí počátek a druhý kroužek s bílým okrajem představuje konec. Stav může dále obsahovat akce a aktivity. Přitom za akci považujeme nepřerušitelný rychle probíhající proces, zatímco aktivita je přerušitelný, jistou dobu trvající proces. Kanisová popisuje jak lze stav zachytit pomocí diagramu - Každý stav má dvě implicitní akce - vstupní a výstupní, které jsou svázány s událostmi entry a exit. Událost entry proběhne automaticky jako první při přechodu do daného stavu objektu a zároveň spustí asociovanou vstupní akci. Analogicky událost exit je poslední událostí daného stavu objektu a opět spouští asociovanou výstupní akci. (Kanisová, Müller, 2006, strana 87) 2.5.7

Entitně-relační diagram - Entity-relationship diagram

Objektové databáze jsou v současnosti ještě „v plenkáchÿ. Jejich rozmachu brání hlavně kvalita současných relačních databází a jistá uživatelská věrnost k zaběhlým dobře fungujícím relačním modelům datového modelování. Proto je nutné se takovýmto datovým entitně-relačním modelem zabývat a pracovat s ním. Jak uvádí Kanisová metodiky rozdělují datový pohled na logický a fyzický datový model.

2.5

Diagramy

23

Logický model Logický datový model je nezávislý na implementaci, není tedy třeba v této fázi analýzy brát v úvahu cílové prostředí, tj. konkrétní typ relační databáze. Pro logický model jsou charakteristické následující pojmy: 1. Entita - Reprezentuje určitý typ objektů. Objekt je nějaká existující realita o které jsou zaznamenávány charakteristické údaje (atributy). Stejné typy entit tvoří třídu datových entit. Název je tvořen podstatným jménem v jednotném čísle. V podstatě můžeme říct, že entita je v logickém návrhu to, co ve fyzickém návrhu relační tabulka. 2. Atribut - Je údaj charakterizující entitu. Jak entity, tak i vztahy mohou obsahovat atributy. Atributy se zobrazují jako elipsy propojené čarou s jejich vlastnící entitou. Každá entita musí mít nejméně tolik atributů, aby byla za všech okolností jednoznačně identifikovatelná. Atribut se jeví ve fyzickém návrhu jako sloupec tabulky. 3. Vazby – Představují logické vztahy mezi entitami, vyjadřuje se slovesem. Důležité je i stanovení charakteru vazby (kardinalitu). Kardinalita popisuje vztah mezi výskyty záznamů svázaných entit. Může být následující: 1:1, 1:N, M:N. 4. Klíče - Každá entita má své atributy. Jeden nebo více atributů má význačnější úlohu než ostatní atributy. Takovému atributu se říká klíč. Rozlišujeme různé typy klíčů: primární (Primary key), alternativní (Alternative key) a cizí klíč (Foreign key). (Kanisová, Müller, 2006, strana 104 – 107) Fyzický model Fyzický model zohledňuje zvolenou relační databázi. Pro něj jsou důležité následující pojmy: 1. Databáze - Je organizovaná struktura dat uspořádaná do tabulek. 2. Tabulka - Je datová struktura organizovaná do řádků a sloupců. Je to vlastně dvourozměrná matice s pojmenovanými sloupci a řádky obsahující vlastní data. 3. Řádek - Nese danou informaci o jednom výskytu entity uloženou v databázi. 4. Sloupec - Je totéž, co v logickém návrhu atribut, představuje druh atomické informace. 2.5.8

Model podnikových procesů - Business process model

Jedním z nejpoužívanějších profilů UML pro potřebu modelování podnikových procesů je profil H. Erikssona. Tento profil je založen na čtyřech základních pohledech na organizaci: • Strategický pohled (vize organizace) - 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.

2.6

CASE nástroje - Enterprise Architect

24

• 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 vizi organizace. • Strukturní pohled - 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 z nejdůležitějších cílů analýzy interakcí je přiřazení odpovědnosti za jednotlivé zdroje. (Řepa, 2007, strany 149) Úroveň detailu každého pohledu zahrnutá v modelu a textovém dokumentu včetně definicí je závislá na jeho účelu. Jestliže model obsahuje vysokou míru abstrakce pohledu, jsou popisy obecnější, některé informace nejsou na první pohled viditelné, naopak v případě velmi komplexního a vysoce detailního popisu může vzniknout těžko pochopitelný a nepružný model. Stanovení základního využití architektury je tedy stěžejní pro rozhodnutí o přiměřené hladině detailu každého pohledu. (Rábová, 2008, strana 52) Eriksson se dále vysvětluje důvod vzniku UML rozšíření známého jako ErikssonPenker Business Extension - Je důležité si uvědomit, že UML bylo původně vytvořené za účelem modelování softwarové architektury a přestože existují podobnosti mezi softwarovým a podnikovým systém, jsou tu i odlišnosti. Podnikové systémy mají mnoho jedinečných vzorů, které není možné zachytit programovým kódem. Mohou to být lidé pracující v podniku, rukodělná výroba, pravidla a cíle, které určují podnikový proces. A jelikož UML bylo původně navrženo k popisu softwarového systému, muselo být rozšířeno, aby jednodušeji identifikovalo a vykreslilo důležité aspekty procesů, cílu, zdrojů a pravidel podnikového systému. (Eriksson, Penker, 2000)

2.6

CASE nástroje - Enterprise Architect

Zkratka CASE je označením pro Computer Aided Software Engineering nebo také Computer Aided Systems Engineering. CASE nástroje jsou nástroje, které primárně umožňují: modelování IT systému pomocí diagramů (člověk lépe chápe obrázek než složitě psané slovo), generování zdrojového kódu z modelu (usnadňuje práci programátorům), zpětné vytvoření modelu podle existujícího zdrojového kódu (Reverse engineering), synchronizaci modelu a zdrojového kódu, vytvoření dokumentace z modelu. CASE nástroje jsou postaveny tak, aby podporovaly týmovou práci při vývoji systému, zajišťují sdílení rozpracovaných fragmentů, správu vývoje, sledují konzistenci modelu systému, automatizují některé procesy, hlídají dodržování zvolené metodiky, některé umožňují řízení celého životního cyklu aplikací. (Barclay, Padusenko, 2001)

2.7

Použité technologie

25

Při modelování rozsáhlého systému v jazyce UML je tedy nezbytné využít nějakého CASE nástroje. Pro svoji práci jsem si vybral software Enterprise Architect 7.1. Ten představuje silný nástroj pro UML modelování a analýzu pokrývající vývoj software od počátečního získávání informací, přes analytické fáze, tvorbu modelů po testování a údržbu. Jeho nespornou výhodou je, že podporuje všech 13 diagramů definovaných jazykem UML 2.

2.7

Použité technologie

XHTML XHTML16 je značkovací jazyk pro tvorbu hypertextových dokumentů v prostředí WWW vyvinutý W3C. Původně se předpokládalo, že se stane nástupcem jazyka HTML, jehož vývoj byl verzí 4.01 ukončen. V roce 2007 však došlo k založení pracovní skupiny, která má za cíl vytvořit novou verzi HTML, která ponese označení HTML 5 a její XML variantu XHTML 5. Vedle toho paralelně pokračuje i vývoj XHTML 2.0. (Wikipedia – HTML, 2009) CSS CSS je zkratka pro anglický název Cascading Style Sheets, česky tabulky kaskádových stylů. Je to jazyk pro popis způsobu zobrazení stránek napsaných v jazycích HTML, XHTML nebo XML. Jazyk byl navržen standardizační organizací W3C, autorem prvotního návrhu byl Hakon Wium Lie. Byly vydány zatím dvě úrovně specifikace CSS1 a CSS2, dokončuje se revize CSS 2.1 a pracuje se na verzi CSS3. Hlavním smyslem je umožnit návrhářům oddělit vzhled dokumentu od jeho struktury a obsahu. (Wikipedia – CSS, 2009) ASP.NET ASP.NET je součást .NET Frameworku firmy Microsoft pro tvorbu webových aplikací a služeb. Ačkoliv název ASP.NET je odvozen od starší technologie pro vývoj webů ASP, obě technologie jsou velmi odlišné. ASP.NET je založen na CLR17 , který je sdílen všemi aplikacemi postavenými na .NET Frameworku. Programátoři tak mohou realizovat své projekty v jakémkoliv jazyce podporujícím CLR, např. Visual Basic.NET, C#, ale i mutace Perlu, Pythonu a další. Aplikace založené na ASP.NET jsou také rychlejší, neboť jsou předkompilovány do jednoho či několika málo DLL18 souborů, na rozdíl od ryze skriptovacích jazyků, kde jsou stránky při každém přístupu znovu a znovu parsovány. (Wikipedia – ASP.NET, 2009)

16

XHTML – Zkratka anglického eXtensible Hypertext Markup Language CLR – Common Language Runtime 18 DLL – Dynamic Linking Library 17

2.8

Ekonomická efektivnost zavedení IS

26

C# C# je vysoce úrovňový objektově orientovaný programovací jazyk vyvinutý firmou Microsoft zároveň s platformou .NET Framework, později schválený standardizačními komisemi ECMA19 a ISO20 . Microsoft založil C# na jazycích C++ a Java (a je tedy nepřímým potomkem jazyka C, ze kterého čerpá syntaxi). C# lze využít k tvorbě databázových programů, webových aplikací a stránek, webových služeb, formulářových aplikací ve Windows, softwaru pro mobilní zařízení (PDA a mobilní telefony) atd. (Wikipedia – C#, 2009) MSSQL Systém řízení báze dat MS SQL Server je natolik robustní a spolehlivý, že tvoří databázovou vrstvu aplikací podnikových informačních systémů strategického významu. Jeho nasazení jako databáze pro interaktivní internetové aplikace je také běžné. Výhodu, že MS SQL obslouží21 bez problému provozní informační systém firmy i její interaktivní webovou prezentaci, lze spatřovat v jednoduchém propojení těchto aplikací, a z toho plynoucí výhodu pro elektronické obchodování. (Interval, 2002)

2.8


Analýza efektivnosti je poměrně náročná a můžeme ji vyjadřovat několika způsoby, jež charakterizují: • výstupy z určitého procesu (hrubý odbyt, výroba zboží apod.), • rozdíly mezi výstupy a vstupy určitého procesu, • relace výstupů ke vstupům určitého procesu, • relace rozdílů výstupů a vstupů určitého procesu ke vstupům do tohoto procesu. V praxi se výše uvedené formy vyjádření efektivity často kombinují. Pro určování efektivnosti se využívá celá soustava konkrétních kritérií a ukazatelů, což vede k otázce určení hlavního souhrnného kritéria, které by celá soustava měla odrážet a vyjadřovat. Efektivnost se bude určovat při zavádění nové filozofie i při převodu některých subsystémů na nový způsob zpracování. Jedná se o to, aby i po určité době bylo možno kontrolovat, do jaké míry se splnily předpoklady, s nimiž se v přípravných pracích počítalo. Pro určování efektivnosti zavádění automatizačních prostředků se používají základní a doplňkové ukazatele. Základními ukazateli jsou náklady a výnosy, z nichž se další ukazatele odvozují. Vychází se nejčastěji ze srovnávací metody, přičemž se navzájem srovnávají různé varianty řešení. Metodické pokyny určování ekonomické efektivnosti informačního systému vycházejí z principu zjišťování a porovnávání nákladů a přínosů, které jsou s tvorbou 19

ECMA – European Computer Manufacturers Association ISO – International Organization for Standardization 21 Anglicky: to serve – obsluhovat, proto server – obsluha 20

2.8


27

automatizovaného informačního systému spojeny. Mezi nejzávažnější přínosy, určující ekonomickou efektivnost patří: • růst objemu výroby na základě intenzifikace a optimalizace výrobního programu, zvýšení rytmičnosti práce, lepší využití fondů, • zvýšení úrovně a operativnosti řízení účelným a včasným sběrem informací o průběhu plnění plánu a jejich rozboru pro manažery, • zvýšení produktivity práce v důsledku snížení prostojů, • přijetí včasných opatření, která zamezí narušování plánu plnění úkolů apod. Další přínosy lze shrnout do skupin: oblast zásobování a odbyt, finanční hospodářská činnost, plánování, administrativa a řízení. (Pezlar, Rybička, 2002)

3

ANALYZOVANÁ FIRMA

3 3.1

28

Analyzovaná firma Předmět podnikání

Firma Kentico Software s. r. o. (dále jen Kentico) založená v roce 2004 Ing. Petrem Palasem, se zabývá zejména vývojem Content Management Systému (viz sekci 3.3) pro vývojáře v prostředí ASP.NET – Kentico CMS for ASP.NET (dále jen Kentico CMS), ale i softwaru pro porovnávání databází – Kentico Compare SQL a synchronizaci serverů – Kentico Server Sync. Firma jež byla založena ve skromných podmínkách, dnes sídlí na ulici Křižíkova v Brně a čítá již více než 41 zaměstnanců a řadí se mezi přední světové firmy v rámci svého oboru. Cílem firmy je dodávat svým zákazníkům kvalitní a stabilní systém, jehož stále se zdokonalující vlastnosti a nové moduly přinesou jeho uživatelům, tedy převážně vývojářům, zjednodušení jejich práce, nové technické možnosti a úsporu času při vývoji sofistikovaných webových systémů. V roce 2008 bylo Kentico Software vyhlášeno nejrychleji rostoucí českou firmou v žebříčku FAST 50 Rising Stars vyhlašovaném společností Deloitte a to díky jejímů 553% růstu v průběhu posledních tří let. Tržní orientace Pouze zhruba 1% obratu firmy se uskutečňuje v rámci trhu ČR, produkce firmy se uplatňuje převážně v anglofonních Zemích - zejména pak v USA a Velké Británii, výjimkou však nejsou i státy jako Spojené Arabské Emiráty, Nový Zéland, Izrael nebo Indie. Momentálně na redakčním systému Kentico CMS funguje více než 2000 webových portálů v 74 zemích světa. Veškerá komunikace se zákazníky tedy nutně musí probíhat v angličtině. Tomu je podřízena i vnitro-firemní komunikace, která ovšem není tak striktní (alespoň co se verbálního projevu týče). Nicméně všechny důležité dokumenty týkající se fungování firmy, její struktury a vnitřních nařízení jsou pořizovány v angličtině. Je to důležitý krok pro budoucí růst firmy, díky němuž je možné velice rychle zaškolit nového zaměstnance i v případě, že nemluví česky. Z tohoto důvodu bude v dalším textu použito názvosloví diagramů v angličtině kvůli budoucí použitelnosti modelovaných firemních procesů. Také musíme vzít v úvahu fakt, že některé anglické pojmy již čeština přebrala a překladem by se ztratil či posunul význam odborných termínů. Nicméně jednotlivé popisy chování a struktur budou uvedeny v češtině.

3.2

Vize, poslání, produkt a cíl

3.2

29

Vize, poslání, produkt a cíl

Vize Firma složená z profesionálních zaměstnanců, která pomáhá zákazníkům vytvářet pokročilá a kvalitní řešení pro webové prezentace, social networking, Intranet a týmovou spolupráci. Poslání Pomáháme zákazníkům vytvářet, spravovat a rozvíjet pokročilá a kvalitní řešení pro webové prezentace, social networking, Intranet a týmovou spolupráci. Přispíváme k růstu našich zákazníků a partnerů. Podporujeme profesní a osobní růst našich zaměstnanců. Produkt Kvalitní, včas vydaný, prodaný a zaplacený, plně funkční software, který odpovídá specifikaci vycházející z požadavků zákazníků, s rychlou a přesnou zákaznickou podporou. Cíl Chceme být globální jedničkou na trhu komplexních CMS systémů na platformě .NET v segmentu malých a středních firem v cenovém rozmezí 1000 až 10000 dolarů do konce roku 2010. Chceme rozvinout partnerskou síť na 2000 aktivních partnerů do konce roku 2010. Chceme vytvořit profesionální, motivovaný tým s nadstandardním ohodnocením do konce roku 2009.

3.3

CMS

Redakční systém neboli Content Management System, tedy CMS, je všeobecný software na správu obsahu. Ten se může skládat z textů, obrázků a jiných mediálních elektronických souborů. Účelem CMS systému je přehledně spravovat obsah různého druhu a umožnit většímu počtu osob přístup k jistým materiálům. Toto značně ulehčuje komunikaci, zvláště ve firmách. Redakční systém je vhodný pro všechny správce a majitele webů, na kterých je nutné často aktualizovat obsah. Všechny webové portály a elektronické obchody využívají nějaký CMS systém. V dnešní době je však stránka s CMS systémem finančně dostupná i pro malé podnikatele a jednotlivce. Tímto způsobem je možno ušetřit na nákladných aktualizacích. 3.3.1

Kentico CMS

Kentico CMS je nyní možné získat ve verzi 4.0, která nabízí kompletní nástroje a možnosti pro tvorbu webových stránek ať už jde o velké weby společností, komunitní weby či osobní stránky, e-shopy, ale i intranet nebo běžnou týmovou spolupráci.

3.4

Organizační struktura

30

Vývoj nových verzí produktu Kentico CMS aktivně sleduje trendy v oblasti internetových technologií a potřeby svých zákazníků. Zatímco původní verze produktu Kentico CMS pokrývala potřeby robustního redakčního systému, součastné verze jdou daleko za jeho obzor - jejich součástí jsou moduly řešící internetový obchod, uživatelské blogy, webfarmy, sociální sítě ale i nástroje internetového marketingu jako je sledování úspěšnosti reklamních kampaní včetně konverzního poměru zákazníků.

3.4


Firma Kentico se řadí mezi malé až střední firmy operující na trhu CMS systémů. Většina zaměstnanců se podílí na vývoji produktů firmy, další skupiny zaměstnanců tvoří web designéři, testeři, obchodníci a pracovníci technické podpory. Jednotliví pracovníci jsou rozděleni zcela transparentně v rámci jednotlivých klobouků22 . Role každého zaměstnance je předem daná, ale díky pružnému vedení je možné zaměstnance přeřadit na jinou pozici, respektive zaměstnanci pozici přidat. Z toho vyplývá, že jeden zaměstnanec může zastávat více pracovních pozic (klobouků) najednou. Rozdělení podle divizí Firma Kentico je rozdělena celkem do 9 divizí. Pro činnost firmy je důležité ji rozdělit na části, tedy divize a do nich systematicky přidělit zaměstnance s jejich rolemi a přesně pro ně definovat klobouky. Takový postup by měl zajistit: • Každý ví, co má přesně dělat. • Zvýšení produktivity pracovníků. • Usnadnění zaškolení nových zaměstnanců. Na obrázku 3 a 4 jsou přehledně zobrazeny všechny zaměstnanecké role, tak jak jsou zařazeny do jednotlivých divizí. Tyto jsou ve skutečnosti detailně popsány a jejich klobouky patřičně zdokumentovány. Dokumentace pracovních klobouků probíhá neustále a je zapotřebí soustavné aktualizace. Ucelenou představu lze získat dále v diagramech jednotlivých podnikových procesů. 22 Soubor informací, které obsahují popis pozice ve firmě, manuály k této pozici, checklisty a veškeré související studijní materiály.

3.4


Obr. 3: Organizační struktura – role v jednotlivých divizích (horní část)

31

3.4


Obr. 4: Organizační struktura – role v jednotlivých divizích (spodní část)

32

3.5

3.5

Současný stav IS

33

Současný stav IS

Současný informační systém je založen na běžné verzi vlastního produktu Kentico CMS 3.1 s tím, že jsou k němu přidány speciální uživatelské prvky23 , které pokrývají specifické funkce jako vytváření a sledování statistik, evidence docházky a dovolených, plánování zdrojů atd. To v praxi znamená nutnost přepsání všech takových prvků při případné aktualizaci na nejnovější verzi produktu a proto se zůstává u poslední dobře fungující verze. K informačnímu systému je připojen dříve vyvinutý CRM24 systém, který zahrnuje moduly pro správu zákaznických kontaktů, správu testování a plánování projektu a navíc plní funkci Ticket systému25 . V současné době jsou tyto dva systémy propojeny společnou bází dat, nicméně využívají jiné GUI26 . Pro vydání nové verze Kentico CMS se počítá se zabudováním nových funkcí intranetu, čímž by se měly rozdíly eliminovat a být jedním kompaktním systémem.

23

Anglicky nazývané Custom controls. CRM - Customer Relationship Management - systém pro řízení vztahů se zákazníky. 25 Ticket system - systém pro správu e-mailových dotazů zákazníků technickou podporou firmy 26 GUI - Graphic User Interface - grafické uživatelské rozhraní 24

4

VLASTNÍ PRÁCE

4

34

Vlastní práce

Při objektové procesní analýze podnikových procesů a inovaci současného informačního systému jsem vycházel z metodiky UP. Ovšem vzhledem k možnostem daným rozsahem práce jsem musel některé kroky vynechat a jiné přizpůsobit. Je tedy zřejmé, že jsem se touto metodikou nechal výrazně ovlivnit, avšak v konečném důsledku plynula jakoby v pozadí. To se týká především analýzy a návrhu, kdy tyto kroky mnohdy splývaly. Také iteraci nebylo možné plnohodnotně využít apod. S výhodou jsem tedy tuto metodiku spojil s některými kroky metodiky Select perspective, čímž bylo dosaženo optimálních výsledků. Všechny následující návrhy byly vytvořeny v modelovacím Case nástroji Enterprise Architect 7.1.

4.1

Byznys modelování současného stavu

Pro byznys model vývoje nové verze produktu budu používat relativně vysokou úroveň abstrakce. To proto, že má sloužit především k revizi stavu, který byl nedávno nastaven. Může být též východiskem pro organizační změny, reengineeringu a inovacím. V první části procesní analýzy se zaměřím na stěžejní podnikový proces, na kterém firma stojí a padá. Je jím proces tvorby nové verze produktu Kentico CMS. Pro názorné představení jednotlivých částí procesu poslouží nejprve diagram podnikových procesů BPM, a následně je pro popis chování odvozen diagram Use Case. Model, zachycen na obrázcích 5, 6, 7 a 8, je navržen tak, aby znázorňoval určitou časovou následnost jednotlivých procesů. K zpřehlednění jsou rovněž v detailních pohledech přidána pořadová čísla procesů, tak jak na sebe navazují. 4.1.1

Základní pohled procesu vývoje produktu

Základní přehlednou kostru procesu tvorby nového produktu poskytuje obrázek 5. Prvotním impulzem pro nastartování procesu je tlak ze strany zákazníků, kteří mají požadavky na novou verzi. Rovněž by se dalo říci, že z ekonomického hlediska je podobně silným impulzem dokončení předešlé verze produktu Kentico CMS, ale ta by sama o sobě nic neznamenala bez poptávky po lepší funkcionalitě produktu. Platí to ale i obráceně - bez potřeby nové verze ze strany zákazníků by nebyl důvod tvořit nový produkt. Celý proces je rozdělen do čtyř základních bloků: 1. příprava a plánování nové verze (Preparing and planninng new version) 2. implementace modulu (Module implementation) 3. kontrola projektu (Review of solution) 4. vypuštění nové verze (New version release) Než je možné začít vyvíjet novou verzi je nutné vzít do úvahy, co vlastně zákazníci

4.1


35

chtějí a potřebují. K dispozici jsou nejrůznější analytické dokumenty v čele s požadavky zákazníků. Přijmou se nejdůležitější a hlavně v daném čase splnitelné požadavky a podle nich se vytvoří projektový plán (Project plan). Zároveň je potřeba, aby měli vývojáři na čem vyvíjet, tedy mít připravený nový projekt (Solution)27 , databázi atd. Projektový plán spolu s novým fungujícím vývojovým projektem jsou výstupy procesu přípravy a plánování nové verze. Tím byl splněn cíl. Vývoj každého jednotlivého modulu je druhým samostatným celkem. Zahrnuje široké spektrum procesů, které budou popsány dále. Nicméně na konci by měl vzniknout modul, odpovídající specifikaci a řádně zdokumentován. Když jsou všechny plánované moduly implementovány, je čas na finální kontrolu a testování výsledného téměř definitivního projektu (Release Candidate)28 buildu29 . Po řádném otestování vznikne verze připravená do výroby (Ready To Manufacture)30 , která se předá k oficiálnímu vydání zákazníkům. V procesu vypuštění nové verze se především zaškolují zaměstnanci do novinek v nové verzi (Training), tak aby byli schopni perfektně spolupracovat se zákazníky. Posledními kroky jsou pak procesy vydání verze (Publishing) a propagace (Promotion), díky kterým se o nové verzi dozvědí sami zákazníci. Konečným produktem se tedy stává vypuštěná kvalitní verze nového produktu Kentico CMS. Je vhodné si zde povšimnout, že do tohoto podnikového procesu zasahuje 5 z devíti divizí, což ovšem představuje všech 41 zaměstnanců. I to je důvod, proč jsem si pro modelování vybral právě tento proces. V dalších částech budou tyto procesy rozebrány detailněji. 27

Kentico CMS solution – seskupení Visual Studio projektů, které tvoří aplikaci Kentico CMS. Toto seskupení lze otevřít ve Visual Studiu tím, že otevřeme soubor s příponou .sln. Kompilací celého solution lze dostat funkční podobu Kentico CMS. 28 Release Candidate – RC – kompletní build Kentico CMS připravený na finální testování. 29 Build – Kentico CMS zkompilované do podoby setupu. 30 RTM – Ready To Manufacture – build Kentico CMS určený pro release. Původní význam slova byl „připravený pro výrobu instalačních médiíÿ – proto „to manufactureÿ

4.1


Obr. 5: BPM diagram – základní pohled

36

4.1


4.1.2

37

Příprava a plánování nové verze

Příprava a plánování nové verze je podrobně znázorněna na obrázku 6. Jak již bylo řečeno, prvotním impulsem je jak dokončení stávající verze, tak potřeba zákazníků po nových funkcích. Tyto zákaznické požadavky (Requirements) jsou vstupem procesu nazvaného schvalování marketingových požadavků (Approving marketing requirements). Ne všechny požadavky zákazníků mají reálný podtext a není možné je do nové verze zakomponovat (ať už z časového, technického či jiného hlediska). Marketing manager projedná s CTO31 požadavky, možné zdroje a čas. Tím by se mělo dospět ke schváleným požadavkům na novou verzi (Approved requirements). Schválené požadavky jsou použity ve fázi schvalování analýzy a specifikací (Approving analysis and specification). Je uspořádána schůze, kde si CTO vyžádá vypracování analýzy od analytika (Software architect) a projednává možnosti a specifikace s technickými vedoucími (Technical leader). Analytik vytvoří analýzu, která je schválena CTO (Approved analysis). Jakmile je analýza schválena, může proběhnout schůzka pro plánování projektu (Project planning), kde se všichni účastníci domluví na časových možnostech, nástinu rozvrhu a na dostupných zdrojích. CTO poté připraví přesný plán a přidělí k němu pracovníky. Tedy vznikne projektový plán (Project Plan). Přípravná fáze je skoro u konce. Vše je naplánované, nicméně je ještě potřeba připravit podmínky pro vývojáře, aby mohli mít jakési centrální úložiště svého kódu - vytvořit nový vývojový projekt (Solution), adekvátně pojmenovanou a připravenou databázi, skripty, kódy a data. Tyto kroky provádí buildmaster v procesu přípravy vývojového projektu (Preparing new solution), který dostane od CTO pokyny s číslem verze (Version number), která se bude vyvíjet. Jakmile vše připraví, pošle informaci vývojářům, kteří si upraví vše potřebné na svém počítači. Na obrázku 6 je zobrazen ještě další proces, kterým je knihovní administrativa (Library administration). Jedná se o proces, který umožňuje využít knižních zdrojů (Book) pracovníky, kteří tak získají potřebné znalosti pro vývoj nového produktu (Prepared employee with necessary knowledge). Důležitou skutečností je, že tento proces je možné najít v kterékoliv fázi vývoje a může být tedy využit jakýmkoli jiným procesem. V části 4.3 je dále tento proces popsán detailněji dalšími diagramy. Byl pro něj připraven návrh aplikace. Více o ní se lze dozvědět v části 4.11. 31

CTO - Chief technical officer - dále bude uváděn pouze pod zkratkou.

4.1


38

Obr. 6: BPM diagram - příprava a plánování nové verze

4.1.3

Implementace modulu

V této fázi je stěžejním procesem implementace (Implementation). Viz obrázek 7. Tento proces vystihuje tvorbu nové funkcionality na připraveném pracovním projektu a databázi podle předem naplánovaného projektového plánu. CTO, technický vedoucí nebo manager webového vývoje (Web development manager) vytvoří v systému novou funkcionalitu, kterou pak přiřadí příslušnému vývojáři. Ten má za úkol ji vytvořit. Když je hotová, sám ji zběžně otestuje. V případě, že není potřeba schválení nadřízeným, je funkcionalita připravena k testování. Pokud je však zapotřebí vyrobenou funkcionalitu schválit nadřízeným, je tento povinen zkontrolovat kód a funkčnost. Když je vše v pořádku, je funkcionalita připravena k testování. Jestliže je něco v nepořádku, je možné ji označit, že byl nalezen defekt nebo na ní dále pracovat a upravit další specifikace. Nyní je ještě zapotřebí připojit zprávu pro testery, aby

4.1


39

věděli, jak funkcionalitu otestovat. Následuje samotné testování. Je možné, že tester najde defekt a přiřadí funkcionalitu odpovědnému vývojáři k opravení. Musí samozřejmě popsat, jak chybu nasimulovat. Jakmile vývojář defekt opraví, přistupuje se opět k testování. Nakonec, pokud je funkcionalita bez chyb, je jí přidán příznak, že je hotova. K výše popsanému procesu implementace jsou připojeny další, řekněme podpůrné, procesy. Bez nich by se implementace neobešla, resp. nebyl by vyroben kvalitní a odladěný produkt, jak to cíl procesu vývoje zdůrazňuje. Jejich pořadí a návaznost není většinou přesně daná. Proces náprava defektu32 (Defect fixing) probíhá následovně: Tester nebo vývojář vytvoří defekt (ve smyslu vytvoření záznamu o něm) a přiřadí ho technickému vedoucímu, který je za danou oblast zodpovědný. Ten dále přiřadí svému vývojáři tento defekt na opravení. Jakmile vývojář defekt opraví a otestuje funkcionalitu je označen a připraven k testování. Tester tento defekt na funkcionalitě otestuje kompletně a pokud je vše v pořádku, označí funkcionalitu jako opravenou (Fixed defect). Náprava chyby33 (Bug fixing) je dalším podpůrným procesem při vývoji nové verze. Pracovník technické podpory, tester nebo vývojář vytvoří záznam o nalezené chybě. Dále proces probíhá obdobně jako náprava defektu jenom s tím rozdílem, že je veden záznam o chybě a na konci je vyprodukována opravená chyba (Fixed bug). Dalším procesem je tvorba ukázkových webových stránek (Sample site making). Ten začíná u CTO, který zadá požadavek na tvorbu ukázkových webových stránek pro managera webového vývoje a poskytne mu k tomu veškeré potřebné materiály. Manager webového vývoje dá pokyn designérovy k vytvoření návrhu designu a následně, je-li vytvořen, je nutné, aby byl schválen nejprve managerem webového vývoje a následně i CTO. Na základě návrhu jsou vytvořeny webovými vývojáři ukázkové webové stránky ukazující nové funkcionality. Ty musí být samozřejmě managerem webového vývoje a CTO schváleny. Následně je dána žádost o vytvoření dokumentace document writerem, která je opět těmi samými pracovníky schválena. Posledním krokem je otestování nově vytvořených webových stránek, který je obdobný, jako při testování chyb a defektů. Výsledkem jsou funkční a zdokumentované webové stránky. Tvorba designu funkcionality (Design implementation) spočívá v tom, že CTO nebo technický vedoucí podá žádost na vytvoření nového designu, který je designéry vytvořen. Opět je zadavatelem zkontrolován. Dokumentace modulu (Module documentation) - pokud technický vedoucí požaduje napsání dokumentace k modulu, dá žádost k document writerovi, který se postará o napsání příslušného popisu. Pokud potřebuje bližší specifikaci k určité funkcionalitě, domluví si schůzku s autorem funkcionality. Ten nakonec vytvořenou dokumentaci schválí. 32 Anglicky Defect - jedná se o chybu v aplikaci nalezenou během vývoje, tedy před vydáním finální verze 33 Anglicky Bug - je chyba v aplikaci nalezená zákazníkem nebo naším zaměstnancem ve finální, vydané verzi.

4.1


40

Pokud technický vedoucí požaduje testování, proběhne proces testování modulu (Module testing). Je vyzván manažer kvality (QA manager), který přiřadí testování dostupným testerem. Ten postupuje podle testovacího protokolu (up-to-date test suite) do té doby než jsou jemu přiřazené funkcionality v modulu otestovány a modul je v konečném stavu (Module tested). Proces lokalizace (Module localization) je nezávislým procesem, který může být spuštěn kdykoliv během implementace. V nové verzi mohou existovat texty, které je nutné přeložit do cizích jazyků. Proto pokud je potřeba překlad, CTO podá požadavek a manažer lokalizací (Localization manager) připraví soubory pro překlad. Ty jsou poslány lokalizačnímu partnerovi, který je přeloží a pošle nazpět. Manažer lokalizací požádá manažera kvality o jednoduché otestování a pokud vše souhlasí jsou lokalizační řetězce přidány do projektu. Završující proces v této fázi je kontrola modulu (Review of single module), kdy jsou všechny funkcionality modulu dokončeny a připraveny. Technický vedoucí zreviduje kód jednotlivých funkcionalit modulu, zkontroluje, jestli není potřeba ještě něco otestovat a navíc zkontroluje, jestli je jeho dokumentace aktuální a úplná. Pokud je vše v pořádku, je možné prohlásit modul za hotový, odpovídající specifikaci a patřičně zdokumentovaný (Module following specification with its documentation).

4.1


Obr. 7: BPM diagram – implementace modulu

41

4.1


4.1.4

42

Kontrola projektu

Revizi projektu (Solution review) ukazuje obrázek 8. Samotný proces kontroly projektu vypadá tak, že techničtí vedoucí předají hotové a zdokumentované moduly CTO. Ten zkontroluje, zda odpovídají požadavkům, jsou plně implementovány a zdokumentovány. Pokud ano je projekt schválen (Approved solution). Při procesu zkompilování konečného projektu (Build solution) dává CTO požadavek na buildmastera, který toto vytvoří a zkontroluje téměř definitivní zkompilvaný projekt (Release candidate build). Proces testování výsledného téměř definitivního projektu (RC testing) probíhá tak, že všichni testeři ještě jednou testují všechny nové funkce a hledají defekty, které jsou příslušnými vývojáři opravovány v procesu popsaném výše tak, aby mohla být vydána „téměřÿ bezchybná verze, která je prohlášena za připravenou ke zpracování (Ready-to-manufacture – RTM version).

Obr. 8: BPM diagram – kontrola projektu

4.1.5

Vypuštění nové verze

Celý proces je ukázán na obrázku 9. Ve fázi vypuštění nové verze (New version release) je k dispozici verze připravená ke zpracování, která je v procesu dokončení úkonů s verzí připravenou ke zpracování (RTM version finishing) díky CTO nahrána na

4.1


43

příslušná sdílená místa spolu s dokumentací a aktualizačními procedurami. Zároveň se také CTO postará, aby byl aktualizován Virtual lab34 . Poté co CTO vše připraví je ta pravá chvíle pro manažera vztahů se zákazníky (PR manager), aby publikoval novou verzi (Publishing) na webovém portálu firmy (New version published on web site). Zároveň vedoucí prodeje posílá zdrojový kód zákazníkům, kteří mají adekvátní licenci. Také pokud se jedná o vydání hlavní verze zajišťuje rozesílání nových sériových klíčů pro případnou aktualizaci na novou verzi (Source code or serial numbers sent to the customers). Dalším úkolem je též informovat distributory o nové verzi (Updates sent to the distributors). Jakmile je hotová verze připravená ke zpracování jsou zahájena školení na nové funkcionality (Training) pro pracovníky oddělní prodeje (Sales department), oddělení technické podpory (Customer care) a oddělení vztahů se zákazníky (Public relations). Jedním z posledních kroků v procesu vývoje nové verze je propagace (Promotion) nové verze, kdy manažer oddělení vztahů se zákazníky musí upravit a rozeslat oznámení o nové verzi, zaregistrovat novou verzi do katalogů na Internetu a rozeslat e-mailový leták všem stávajícím zákazníkům a uživatelům, kteří si ho vyžádali.

Obr. 9: BPM diagram - vypuštění nové verze 34

On-line server, na kterém si mohou uživatelé zadarmo Kentico CMS vyzkoušet.

4.2

Use Case model současných podnikových procesů

4.2

44


Na obrázku 10 je znázorněn celkový náhled na případy užití vznikající v celém procesu vývoje nové verze produktu Kentico CMS. Znázorňuje hlavní procesy ve zmíněném procesu a dále představuje aktory vstupující do vzájemných interakcí. Pro přehlednost byli aktéři sloučeni do jednotlivých divizí tak, jak vystupují v příslušném případu užití. U procesu knihovní administrativa (Library administration) bylo využito zobecnění aktéra, kdy všechny zaměstnance ve firmě zastupuje jeden zaměstnanec (Employee). Náhled na Use Case byl odvozen z předešlého modelu podnikových procesů. Z hlediska rozsahu této diplomové práce zde není nemožné uvést všechny detailní případy užití. Nicméně jako ilustraci popíši jeden z těchto případů užití Náprava defektu (Defect fixing). 4.2.1

Náprava defektu

Diagram případu užití náprava defektu (Defect fixing) je zobrazen na obrázku 11. Jedná se o dílčí proces, proto není příliš složitý, ale pro ilustraci bude stačit. Při modelování vycházím z faktu, že je velice důležité vytvářet analytické diagramy tak, aby modelovaným skutečnostem všichni zúčastnění porozuměli. Hlavními aktéry jsou vývojář (Developer), tester (Tester) a technický vedoucí (Technical leader). V případě, že vývojář nebo tester zjistí defekt vytvoří pro něj záznam, který je nutno opatřit detaily. Tento defekt přiřadí technickému vedoucímu, který se postará o přidělení defektu příslušnému zodpovědnému vývojáři. Vývojář nastaví status na „Defekt je právě napravovánÿ. Poté co jej opraví, otestuje defekt ve svém projektu a nastaví status „Defekt napravenÿ. Jakmile ho otestuje ve sdíleném projektu změní jeho status na „Připraven na testováníÿ. Tester otestuje napravený defekt a jestliže je vše v pořádku změní status na „Připraveno k uzavřeníÿ. Pokud ne, nastaví status opět na „Defekt nalezenÿ a celá procedura se opakuje. Na konci případu užití je defekt napraven. Pro názornost je v tabulce 1 uveden i jeho scénář (anglicky).

4.2


Obr. 10: Use Case diagram - celkový Use Case pohled na proces vývoje

45

4.2


46

Obr. 11: Use Case diagram - náprava defektu Tab. 1: Use Case scénář - náprava defektu

Use Case: Defect fixing Short description: When some defect is found it is necessary to fix it. Primary actors: Technical leader, Tester, Developer. Secondary actors: none. Input conditions: 1. Tester or Developer finds a defect. Primary scenario: 1. 2. 3. 4. 5.

Tester or Developer creates a defect and assigns it to the responsible TL. Technical leader assigns the defect to the Developer. Defect fixing by the Developer. Developer sets the defect to „Defect is being fixedÿ. Developer fixes the defect, tests the defect in the Solution and sets the defect to „Defect fixedÿ. 6. Developer tests the fixed defect in the build and sets the defect to „Ready for testingÿ. 7. Tester tests the fixed defect and if the defect is fixed correctly, he sets the status to „Ready for closeÿ, otherwise, he sets the status to „Defect foundÿ and adds instructions for developer (the process goes to point 3). Output conditions: 1. Defect is fixed.

4.3

Zlepšení části podnikového procesu - knihovní administrativa

4.3

47

Zlepšení části podnikového procesu - knihovní administrativa

Zlepšení části podnikového procesu vnitro podnikové knihovny vychází z provedené analýzy současného stavu informačního systému a základního procesu vývoje produktu. Pro zlepšení podnikové knihovny mě přiměla nedostatečná elektronická podpora pro činnosti týkající se knihovnické oblasti. Pro práci v oblasti informačních zdrojů je velice nutná neustálá aktualizace znalostí a vědomostí, které je možné nabýt v knihách. Ve firmě Kentico jsou nové knihy pravidelně kupovány a aktualizovány, horší je to již s jejich správou. Proto jsem se rozhodl situaci zlepšit a umožnit tak zaměstnancům knihy vypůjčovat, v případě nedostupnosti rezervovat a sledovat jejich knihovnické transakce. Důležitým aspektem při vývoji knihovního systému byla nutnost integrace tohoto řešení do stávající struktury intranetu. Návrh zlepšení vnitropodnikové knihovny je rozdělen do několika částí, které společně popisují základní procesy a struktury systému a poskytují tak analytický pohled na tento knihovní systém. Základem je model podnikových procesů, který názorně představuje živé části systému. Dalším modelem bude diagram případů užití, jež podává představu o chování a jeho reakce na vnější podněty. K němu uvedu ilustrativní scénáře. Následovat bude diagram aktivit, sekvenční diagram, diagram stavů. Pro popis statické struktury bude vykreslen diagram tříd a ERD diagram.

4.4

BPM - knihovní administrativa

V procesu knihovní administrativa (Library administration) vystupují tři hlavní aktéři: zaměstnanec (Employee), asistentka (Office assistent) a čas (Time). Zaměstnanec je v tomto případě zobecněním všech ostatních rolí. Tento proces je zobrazen na obrázcích 12 a 13. Nejprve je nutné, aby byla kniha asistentkou přidána (Add new book), poté může být upravena (Modify book), případně smazána (Remove book) ze systému. V každém případě je nutné, aby kdokoli, kdo chce pracovat s knihovnou, byl přihlášený do systému (Login to intranet). Libovolný zaměstnanec může v knihovně hledat knihy (Book searching) a zjišťovat, jestli je dostupná či nikoli. V případě, že ho kniha zaujme, zobrazí si její detail, kde jsou mu vypsány podrobnosti o stavu knihy, dále kolik je dostupných kusů, kolik jich je celkem, kdo má knihu půjčenou případně reservovanou. Pokud není kniha dostupná, je možné knihu rezervovat (Book reservation). Jakmile je kniha vrácena resp. je zrušena rezervace (Cancel reservation) a zaměstnanec bude první ve frontě rezervací, je mu poslán oznamovací e-mail, že si může knihu vypůjčit. Pokud tak neučiní během stanoveného počtu dní, je automaticky rezervace zrušena a příležitost vypůjčit knihu dostane druhý, který je na řadě. Děje se tak na základě kontroly plánovačem35 , který prochází rezervace každý den (Check reservation term). 35

Anglicky Scheduler

4.5

Use Case - knihovní administrativa

48

Pokud zaměstnanec zjistí, že je kniha k dispozici, jde knihu najít fyzicky v knihovně a zanese jí asistentce. Ta se postará o vyplnění půjčovní lístku knihy a poté zaměstnanci knihu vypůjčí (Borrow book). Jakmile se zaměstnanec rozhodne knihu vrátit přijde s knihou za asistentkou, ta ji zkontroluje, vyplní půjčovní lístek a knihu vrátí (Return book). V tomto momentu je dobré zmínit, že po dohodě s vedoucími jsme se shodli na tom, že nebude nutné vypracovávat kontrolu délky výpůjční doby. Hlavním důvodem byly především zvýšené administrativní nároky takového řešení, kdy by se asistentka musela starat o dodržování lhůt, resp. o sankce při jejich překročení, v nejhorším případě o vymáhání knihy. Jelikož má firma prozatím relativně malý počet zaměstnanců je taková správa bez výpůjční lhůty poměrně snadná. V případě potřeby však není problém v budoucnu funkcionalitu přidat.

4.5


Use Case procesu knihovní administrativy (Library administration) byl odvozen z procesního modelu, kdy byly přebrány základní procesy ke kterým bylo nutno přidat doplňující případy užití. Znázorněn je na obrázku 15. Podobně jako v modelu BPM zde vystupují tři aktéři zaměstnanec, asistent a čas. Pro názornost uvedu náhled do jednoho konkrétního případu užití - rezervace knihy (Book reservation). Jeho popis je v podkapitole 4.5.1. 4.5.1

Use Case - rezervace knihy

Na obrázku 14 je vidět poměrně triviální, přesto stěžejní případ užití pro rezervaci knihy. Jako aktor vystupuje zaměstnanec (Employee), tedy zaměstnanec s jakoukoli rolí. Vidíme, že pokud je zaměstnanec přihlášen, je mu zobrazen seznam knih. Při požadavku na rychlé nalezení konkrétní knihy může použít vyhledávání. Rezervovat knihu je možné po zobrazení detailu knihy. Ihned je zaměstnanci odeslán oznamovací e-mail o rezervaci. Tato rezervovaná kniha se mu objeví v seznamu jeho rezervovaných knih. Scénář procesu rezervace knihy je přidán v tabulce č. 2 (anglicky). Další případy užití by ukázaly, jakým způsobem probíhají ostatní činnosti jako rušení rezervace a především samotné půjčení a vracení knihy. Z rozsahových důvodů je však není možné uvést.

4.5


Obr. 12: BPM diagram - knihovní administrativa 1/2

49

4.5


Obr. 13: BPM diagram - knihovní administrativa 2/2

Obr. 14: Use Case diagram - rezervace knihy

50

4.6

Sekvenční diagram - rezervace knihy

51

Obr. 15: Use Case diagram - knihovní administrativa

4.6

Sekvenční diagram - rezervace knihy

Model Use Case je vhodné doplnit o patřičný sekvenční diagram, který ukazuje jak jdou jednotlivé kroky po sobě. Navíc lze z diagramu vyčíst jak si jednotlivé objekty mezi sebou předávají zprávy. Na obrázku 16 je zobrazen takový sekvenční diagram upřesňující sekvenci úkonů při rezervování knihy (Book reservation). Zde je potřeba si uvědomit, že kniha jako taková je obecný dokument v Kentico CMS, který je založen na typu dokumentu36 . Proto při zobrazení knihy, potažmo jejím rezervování je nutno pracovat jak s dokumentem samotným, tak s tabulkou, ve které jsou uloženy detaily knihy. Nicméně tyto úkony nemusí zaměstnance zajímat, což je též vyznačeno v sekvenčním diagramu. To co zaměstnanec dostane, je v rozhraní (Interface). A opět knihu si může ručně nalézt v seznamu knih, nebo si ji vyhledat pomocí vyhledávání. U knihy se mu zobrazí zda je dostupná spolu 36

Anglicky Document type

4.7

Diagram tříd - knihovní administrativa

52

Tab. 2: Use Case scénář - rezervace knihy

Use Case: Book reservation Short description: Employee wants to reserve book. Primary actors: Employee. Secondary actors: none. Input conditions: 1. Employee is logged in. 2. Emloyee doesn’t have reserved the book. 3. Emloyee doesn’t have borrowed the book. 4. Book is not available. Primary scenario: 1. 2. 3. 4. 5.

He enters the library system. He can locate desired book within book list or he can search for it. Appropriate book detail is showed. He checks book status. If book is unavailable he can reserve it by pushing ’Reserve button’.

Output conditions: 1. Employee has reserved his book. 2. Notification e-mail is sent to his e-mail. s dalšími detaily a podle toho bude schopný si knihu rezervovat. V takovém případě je mu poslán oznamovací e-mail a rezervace je zobrazena v jeho seznamu rezervací.

4.7


Na základě provedeného návrhu modelu podnikových procesů knihovní administrativy (Library administration) a případu užití je nyní možné sestavit diagram tříd. Již výše jsem uváděl, že tento projekt knihovny má hlavní specifikum v tom, že je nutné ho zaintegrovat do již fungujícího systému. Ten je založen na vlastním produktu Kentico CMS, který nutno říci, je v nynější podobě poměrně rozsáhlý. Z toho vyplývá nejen to, že struktura některých tříd a objektů je předem daná a je nutno z ní vycházet, ale hlavně že většinu operací a atributů ve svém projektu nevyužiji. Tato skutečnost je naznačena třemi tečkami u příslušných tříd. Diagram tříd pro knihovní systém je znázorněn na obrázku 17. Každá přidaná kniha je ve své podstatě obecný dokument (Document) v rámci systému Kentico CMS, jehož datovou strukturu udává dokumentový typ kniha (Book). Aby systém věděl, kde se ve stromové struktuře stránek dokument na-

4.7


53

lézá, je zapotřebí vést záznam ve třídě strom (Tree). Dokumentový typ je vázán přes třídu (Class) se stromem. O to co je po načtení příslušné stránky zobrazeno se stará příslušná šablona stránky (PageTemplate) obsahující potřebné prvky stránek. O nejdůležitější knihovní funkce se starají třídy vypůjčené (Borrowed) a rezervované (Reserved). Ty spojují knihu se zaměstnancem (Employee) a jednoznačně tak definují výpůjčku, respektive rezervaci. Každý zaměstnanec je pak rozlišován podle své role (Role), která je s ním svázána vazební třídou (UserRole). Podle této role se pak usuzuje, na které operace má či nemá právo.

Obr. 16: Sekvenční diagram - rezervace knihy

4.8

Diagram aktivit - rezervace knihy

54

Obr. 17: Diagram tříd - knihovní administrativa

4.8

Diagram aktivit - rezervace knihy

V této kapitole je ukázán proces rezervace knihy (Book reservation) v diagramu aktivit. Na obrázku 18 je tento proces zobrazen v kontextu s ostatními procesy, které může vykonávat zaměstnanec (Employee). Přestože by z metodického hlediska a rovněž z důvodu přehlednosti bylo vhodné zkonstruovat diagram aktivit pro každý případ užití zvlášť, není možné tyto jednotlivé diagramy kvůli stanovenému rozsahu práce uvést. Jednotlivé uzly týkající se rezervace knihy jsou tedy zvýrazněny oranžovou barvou. Popis procesu je obdobný jako u výše popsaných diagramů. Jenom s malou úpravou, kdy jsem z důvodu přehlednosti zahrnul do procesu Book searching zobrazení seznamu knih (ať už je uživatel nalezl manuálně nebo získal pomocí vyhledávání). Zajímavé jsou ale i další větve pro půjčování knihy, vracení či rušení rezervace. Přehledně je naznačeno, že uživatel může v systému požadovat i jiné operace jako kontrolovat svoje rezervace (Check my reservations list), kontrolovat své aktuálně vypůjčené knihy (Check my borrowed books), kontrolovat svoje předešlé výpůjčky

4.9

Stavový diagram - třída kniha

55

(Check my previously borrowed books), kontrolovat, kdo má knihu půjčenou (Check who has borrowed book) či rezervovanou (Check who has borrowed book).

Obr. 18: Diagram aktivit - pohled zaměstnance – rezervace knihy

4.9

Stavový diagram - třída kniha

Pro stavový diagram jsem si určil klíčovou třídu knihu (Book), která je vzhledem k povaze a zaměření projektu nejvíce určující. Tato třída je též jednoznačně nejaktivnější. Změna stavu knihy je důležitá nejen pro zaměstnance, aby věděl, co může

4.10

ERD diagram - knihovní administrativa

56

s knihou provádět za operace, ale je to nutné i z technického hlediska, aby se zobrazovaly vždy jen relevantní informace. Diagram je zobrazen v obrázku 19. Základní dva stavy knihy jsou dostupná (Available) a nedostupná (Unavailable). Dále se u jednotlivých stavů rozlišuje, zda jsou jenom vypůjčené (Borrowed), nebo jenom rezervované (Reserved), případně jestli jsou i vypůjčené i rezervované (Borrowed and Reserved) nebo ani jedno dohromady. Pro detailnější rozlišení lze třídu kniha rozdělit do dalších stavů podle toho, jestli má knihu půjčenou aktuální zaměstnanec. Na obrázku 19 lze vidět, jak se mění stav knihy při půjčování, vracení, rezervaci a rušení rezervace, kdy jsou pro každou akci uvedena pravidla, kterých splněním se do cílového stavu přejde.

Obr. 19: Stavový diagram - pro třídu kniha

4.10


Před implementací knihovního systému bylo nutné vytvořit datový model systému. Ten vychází z navrženého modelu tříd. Použité entity s příslušnými relacemi jsou zobrazeny na obrázku 20. Následuje výčet a popis entit.

4.10


57

CMS Class – Je spojena přes sloupec ClassTableName s adekvátním typem dokumentu z jeho tabulky. V tomto případě jede o tabulku custom book. custom book – Tabulka určená typem dokumentu. Obsahuje data knihy. CMS Tree – Obsahuje záznam o příslušné třídě v sloupci NodeClassID, kterým je spojena s tabulkou CMS Class. CMS Document – Jeho umístění je určeno spojením s tabulkou CMS Tree přes sloupec DocumentNodeID. Ve sloupci DocumentForeignKeyValue je odkazováno na příslušný typ dokumentu, kterým je tvořen. Díky DocumentcreatedByUserID a DocumentModifiedByUserID je možné přiřadit dokumentu uživatele. CMS PageTemplate – Každý dokument je založen na určité šabloně stránky. Na tu se odkazuje pomocí DocumumentPageTemplateID. View CMS Tree Joined – Jedná se o pohled, který sdružuje všechny informace o dokumentu. Z něj čerpají standardní .NET kontroly. CMS User – Uchovává informace o uživateli. Může figurovat ve více rolích. CMS Role – V rámci jedné role může vystupovat více uživatelů. Na základě role (a příslušných oprávnění pro ni) je určováno, co může uživatel v systému vykonávat za operace. CMS UserRole – Jedná se o spojovací tabulku pro uživatele příslušejícího do některé z rolí.

4.11

Funkce systému

58

Obr. 20: ERD diagram - knihovní administrativa

4.11

Funkce systému

Na základě všech výše uvedených diagramů - tedy diagramu podnikových procesů, Use Case diagramu, sekvenčního diagramu, diagramu tříd, diagramu aktivit, stavového diagramu a ERD diagramu byla vypracována knihovní aplikace, která vystupuje jako proces knihovní administrativa. Jako hlavní cíl si klade přehledné zjednodušení knihovní administrativy a zvýšení komfortu pro jak asistenta, který se o knihy stará, tak hlavně pro samotné zaměstnance. Asistent může knihy do systému přiřazovat do různých kategorií (podle toho kam ve stromové struktuře knihu

4.11

Funkce systému

59

umístí) a zároveň s nimi může dle libosti manipulovat pomocí CMS Desku . Tedy jsou-li přítomny knihy, může zaměstnanec po přihlášení vstoupit do knihovny. Zde hned vidí na pravých bočních lištách, které knihy má vypůjčené, které rezervované a které měl v minulosti vypůjčené. Odtud může přímo najet na knihu ze seznamu knih (lze upřesnit kategoriemi), nebo si požadovanou knihu vyhledat – přidán byl ajaxový vyhledávací našeptávač, který vyhledávání výrazně ulehčuje. Viz obrázek 21.

Obr. 21: Náhled na knihovní aplikaci - seznam knih

Po zobrazení detailu knihy jsou vypsány údaje o knize, kdo má knihu půjčenou a kdo rezervovanou. Důležité je zjištění stavu knihy pro aktuálního uživatele, podle čehož je pak odvozováno, které operace mu budou nabídnuty. Zaměstnanec má právo pouze knihy rezervovat resp. rušit rezervace. Pokud se jedná o asistenta, který je oprávněn knihy půjčovat a vracet, dostává možnost navíc zvolit určitého zaměstnance. Výpis zaměstnanců je závislý od toho, jestli je např. kniha rezervovaná potom může při půjčování knihy vybírat jenom z těch, kteří ji mají rezervovanou. Při vracení se pak výběr omezuje pouze na ty, kteří mají knihu půjčenou. Toto výrazně ulehčuje asistentovi práci při hledání adekvátních zaměstnanců. Nástin takového vracení knihy je na obrázku 22. Jakmile si zaměstnanec knihu rezervuje, přidá se do fronty čekatelů. Ta je každý den automaticky kontrolována pomocí plánovače. V případě, že je kniha vrácena či zrušena rezervace, čímž se stane kniha dostupnou, je automaticky urgován první kdo si knihu rezervoval. Ten by si měl knihu během stanoveného počtu dní přijít vypůjčit. Pokud tak neučiní, je díky plánovači rezervace zrušena a je poslán informační e-mail dalšímu zájemci v pořadí. Díky tomu se zamezí situacím, kdy si někdo knihu rezervuje, nevyzvedne a tím blokuje všechny ostatní zájemce o knihu. To, že není takový zaměstnanec poslán na konec fronty, ale jeho rezervace je automaticky

4.12

Vylepšení systému knihovny

60

zrušena, zabraňuje vzniku situace, kdy by byl ve frontě sám (zacyklil by se a mohl by tak knihu blokovat donekonečna). U všech hlavních činností, tedy půjčování, vracení, rezervace knih a rušení rezervace je samozřejmostí rozeslání oznamovacího e-mailu příslušnému zaměstnanci.

Obr. 22: Náhled na knihovní aplikaci - detail knihy

4.12

Vylepšení systému knihovny

Knihovní systém je zatím pouze ve fázi beta verze. Prostor tedy na další vylepšení stále zůstává. Největší otázkou v tomto okamžiku zůstává, zda a případně kdy bude zaveden systém kontroly výpůjční lhůty. Po konzultacích s vybranými pracovníky jsme dospěli k závěru, že prozatím není tato funkcionalita potřebná, ba dokonce by mohla být kontraproduktivní. Zaměstnanci by mohli být stresováni danou lhůtou pro vypůjčení a nemuseli by stihnout vše nastudovat. Nehledě na to, že si příliš neumím představit jaké by se musely nastavit sankce pro překročení výpůjční lhůty a jak by se v praxi vymáhaly. Myslím si, že v případě malého počtu zaměstnanců, kterým firma Kentico momentálně disponuje, prozatím funkcionalita kontroly výpůjční lhůty chybět nebude. Nicméně stávající návrh ji modeluje a umožňuje poměrně snadnou implementaci řešení pro širší správu výpůjček. Další možnost pro zlepšení představuje administrativní část, u které by bylo vhodné vylepšit použitelnost samotných intranetových stránek tak, aby měl asistent pracující s knihami co nejvíce usnadněnou práci při půjčování a vracení knih. Pokud jde o možnosti zlepšení systému do budoucna, vidím jako velice zajímavou možnost napojení čtečky čárových kódů k systému. Ta by mohla mít případně uplatnění i v jiných firemních procesech jako je například inventarizace majetku.

5

EKONOMICKÉ HODNOCENÍ NAVRŽENÉHO ŘEŠENÍ

5

61

Ekonomické hodnocení navrženého řešení

Ekonomické hodnocení efektivnosti přestavuje poměrně složitý proces sledování daných kritérií a ukazatelů. Důležité je zvolit si hlavní souhrnné kritérium. Zjišťujeme a porovnáváme náklady a přínosy, které jsou s tvorbou spojeny. Jako nejzávažnější přínosy, určující ekonomickou efektivnost se jeví převážně zvýšení produktivity práce v důsledku vyšší transparentnosti knihovního systému a celkově zvýšení odborných znalostí zaměstnanců. Je důležité si uvědomit, že produktem firmy Kentico je redakční systém, který je možné upravit do podoby vlastního informačního systému. Tento přístup je ve firmě preferován a implementován a odpadá tak nutnost nákupu jakéhokoli konkurenčního řešení. Tím se nám náklady na údržbu a tvorbu nových funkcionalit snížily pouze na mzdové náklady jednotlivých vývojářů firmy. Při opačném pohledu na věc mohou být kterékoli takto naprogramované funkcionality použity v oficiálně vydávaném produktu Kentico CMS, což následně zvyšuje mezní užitek zákazníků. V případě mnou navržené beta verze knihovní administrativy se tedy náklady rovnají jednoduše vyčíslitelným osobním mzdovým nákladům vývojáře. Ty jsou na druhé straně vyváženy nepříliš snadno vypočitatelnými a prokazatelnými přínosy jako zvýšení produktivity práce, zvýšení odborné znalosti zaměstnanců a též vyšší spokojenosti při procesu rezervace a půjčování knih.

5.1

Alternativní řešení

Pro úplnost uvádím srovnání s alternativním řešením. Jednoznačně nejrozšířenějším knihovním systémem je systém Clavius. Tento systém je velice rozsáhlý a jeho moduly do značné míry převyšují momentální potřeby firemní knihovny. Výhodou je, že se dají koupit jednotlivé potřebné moduly zvlášť. Aby tedy naplňoval specifika nastavené navrženým knihovním řešením - katalogizace, vypůjčování a vyhledávání - je nutné zakoupit příslušné 3 moduly v celkové ceně 32 130 Kč. K této sumě je třeba připočíst 80% navýšení pokud bychom přemýšleli o serverové verzi produktu. I přes předpoklad integrace systému na některý ze stávajících serverů, s použitím stávající licence pro MSSQL databázi, se nevyhneme dalšímu zvýšení nákladů o mzdové náklady systémového integrátora. Z obtížně vyčíslitelných nákladů je nutné ještě připočítat jistou míru nesourodosti se stávajícím informačním systémem a duplicitní správu uživatelů.

6

6

ZÁVĚR

62

Závěr

Zvyšující se nároky na informační systém jsou zapříčiněny rostoucími nároky na kvalitní, plně funkční produkty, které jsou včas dodané a zaplacené, a které odpovídají specifikaci a vychází ze zákaznických požadavků. Cílem této práce bylo analyzovat firemní procesy v podniku a provést inovaci části informačního systému. Na základě teoretických poznatků shrnutých v první části diplomové práce se podařilo namodelovat základní procesy vývoje produktu Kentico CMS, které jsou natolik komplexní, že se na nich podílí všichni zaměstnanci firmy. Byl vypracován diagram podnikových procesů, z kterého byly odvozeny jednotlivé případy užití zakreslené v Use Case digramu. Do tohoto modelu byl zapracován inovativní proces knihovní administrativa, který byl dále rozvinut a byla pro něj vytvořena aplikace. Tato aplikace se opírá o analytický návrh pomocí dílčích diagramů podnikových procesů, Use Case, sekvenčního diagramu, diagramu aktivit a stavového diagramu popisující chování systému. Pro popis statické části byl použit diagram tříd a ERD diagram. Stávající informační systém je založen na vlastním produktu Kentico CMS s tím, že pro některé činnosti jako např. testování nebo plánování projektu je využíváno již dříve vyvinutého samostatného CRM modulu. Nová verze produktu by měla být zaměřena na integraci intranetových funkcí, čímž by se tyto části spojily v jednotný celek. Takové řešení by bylo pro firmu velikou výhodou, jelikož současně při vývoji nového komerčního produktu mohou tento využívat i pro interní potřeby informačního systému a těžit tak z nejnovějších funkcionalit. Při vývoji knihovní aplikace byl kladen důraz na hledisko maximální integrace se stávajícím informačním systémem. Proto bylo využito možností, které Kentico CMS nabízí. S výhodou byly využity některé třídy a jejich operace tak, aby se nevytvářely redundantní a dále nepoužitelné varianty. Aplikace je prozatím v beta verzi, což znamená nutnost praktické integrace do systému a testování v ostrém provozu. Otázkou zůstává implementace kontroly výpůjční lhůty, která však v současném stádiu vývoje firmy nemá opodstatnění. Přesto však není dále vyloučena. Práce by se měla stát podpůrným dokumentem pro zavádění systému managementu jakosti vycházející z normy ISO 9001:2000. Modelování podnikové architektury přispívá ke splnění požadavků této normy zejména v oblasti procesů a zdrojů, které jsou kritické pro kvalitu produktu a služeb podniku. Tento systém garance kvality je pro podnik velkou výhodou zejména v oblasti konkurenceschopnosti.

7

7

LITERATURA

63

Literatura

Arlow, J., Neustadt, I. UML 2 a unifikovaný proces vývoje aplikací 2. vyd. Brno: Computer Press, a. s., 2007, 567 s. ISBN 80-251-1503-9. Barclay, S., Padusenko, S. Faculty of Education – Computer Science – Case Tools [online]. Poslední aktualizace: 11. 1. 2001 [cit. 29. 4. 2009]. Dostupné na World Wide Web: http://educ.queensu.ca/ compsci/units/casetools.html. Cockburn, A. Use Cases - Jak efektivně modelovat aplikace 1. vyd. Brno: CP Books, a. s., 2005, 261 s. ISBN 80-251-0721-3. Eriksson, H., Penker, M. Business Modeling With UML 1. vyd. New York: John Wiley & sons, 2000, 480 s. ISBN 0-471-29551-8. Interval Sblížení s Microsoft SQL Server [online]. Poslední aktualizace: 12. 4. 2002 [cit. 1. 4. 2009]. Dostupné na World Wide Web: http://interval.cz/clanky/sblizeni-s-microsoft-sql-server/. Kanisová, H., Müller, M. UML srozumitelně 2. vyd. Brno: Computer Press, a. s., 2006, 176 s. ISBN 80-251-1083-4. Objektová analýza, návrh a programování Select Perspective [online]. Poslední aktualizace: 16. 6. 2005 [cit. 3. 4. 2009]. Dostupné na World Wide Web: http://objekty.vse.cz/Objekty/MetodikyANotace-Select. Objecteering Objecteering empowers UML2 - Examples - Activity diagrams [online]. Poslední aktualizace: 3. 8. 2008 [cit. 31. 3. 2009]. Dostupné na World Wide Web: http://www.objecteering.com/diagrams activity.php. Page-Jones, M. Základy objektově orientovaného návrhu v UML 1. vyd. Praha: Grada Publishing, a. s., 2001, 368 s. ISBN 80-247-0210-X. Pezlar, Z., Rybička, J. Informatika pro ekonomy 1. vyd. Brno: Konvoj, spol. s r. o., 2002, 70 s. ISBN 80-7302-017-3. Rábová, I. a kol. Podniková architektura - strategický nástroj v rukou manažera 1. vyd. Brno: Tribun EU s. r. o., 2008, 131 s. ISBN 80-7399-568-3. Rumbaugh, J., Jacobson, I., Booch, G. The Unified Modeling Language Reference Manual : The Second Edition. 2. vyd. Boston: Addison Wesley Professional, 2007, 752 s. ISBN 0-321-24562-8. Řepa, V. Podnikové procesy - Procesní řízení a modelování 2. vyd. Praha: Grada Publishing, a. s., 2007, 288 s. ISBN 80-247-2252-8. Schmuller, J. Myslíme v jazyku UML 1. vyd. Praha: Grada Publishing, a. s., 2001, 361 s. ISBN 80-247-0029-8. Sodomka, P. Informační systémy v podnikové praxi 1. vyd. Brno: Computer Press, a. s., 2006, 351 s. ISBN 80-251-1200-4. Vrána, I., Richta, K. Zásady a postupy zavádění podnikových informačních systémů 1. vyd. Praha: Grada Publishing, a. s., 2005, 187 s. ISBN 80-247-1103-6. Jan [Zubíček.eu] Novinky ve specifikaci UML 2 [online]. Poslední aktualizace: 3. 6. 2006 [cit. 30. 3. 2009]. Dostupné na World Wide Web: http://zubicek.eu/?s=novinky.

7

LITERATURA

64

Wikipedia ASP.NET [online]. Poslední aktualizace: 11. 3. 2009 [cit. 1. 4. 2009]. Dostupné na World Wide Web: http://cs.wikipedia.org/wiki/ASP.NET. Wikipedia C# [online]. Poslední aktualizace: 22. 5. 2009 [cit. 1. 4. 2009]. Dostupné na World Wide Web: http://cs.wikipedia.org/wiki/C Sharp. Wikipedia Cascading Style Sheets [online]. Poslední aktualizace: 31. 3. 2009 [cit. 1. 4. 2009]. Dostupné na World Wide Web: http://cs.wikipedia.org/wiki/Cascading Style Sheets. Wikipedia Extensible HyperText Markup Language [online]. Poslední aktualizace: 15. 3. 2009 [cit. 1. 4. 2009]. Dostupné na World Wide Web: http://cs.wikipedia.org/wiki/XHTML.

Přílohy

A

A

SLOVNÍČEK POJMŮ

66

Slovníček pojmů

Activity diagram – Diagram pro popis aktivit a akcí vykonávaných v systému nebo procesu. Aktor – Externí objekt, který je v interakci se systémem. Z Use Case lze chápat aktora jako roli hranou člověkem v systému. BPM – Business Process Model, popisuje podnikové procesy, které reprezentují aktivity a hodnoty vytvářené v podniku. Build – Kentico CMS zkompilované do podoby setupu. Business process – Vyjádření skupiny aktivit, které při správném provedení vedou k naplnění explicitně vymezeného cíle. Bug – Chyba v aplikaci nalezená zákazníkem nebo zaměstnancem ve finální, vydané verzi. Class diagram – Slouží pro popis struktur, které jsou vytvářeny z tříd a vztahů mezi nimi. Třídy vyjadřují objekty jako informace, produkty, dokumenty nebo struktury. CMS – Content Management System – systém pro správu obsahu. Obecný název pro aplikace jako je Kentico CMS. CRM – Customer Relationship Management – Systém pro správu vztahů se zákazníky. Defect – Chyba v aplikaci nalezená během vývoje, tedy před vydáním finální verze. ERD diagram – Entity-relationship diagram zobrazuje množiny entity a vztahů mezi nimi. Feature – nová vlastnost nebo úprava existující vlastnosti. Klobouk – soubor informací, které obsahují popis pozice ve firmě, manuály k této pozici, checklisty a veškeré související studijní materiály. Release Candidate – RC – kompletní build Kentico CMS připravený na finální testování. Po otestování se z Release Candidate stává RTM verze.

A

SLOVNÍČEK POJMŮ

67

Requirement – požadavek uživatelů Kentico CMS na změnu nebo novou funkcionalitu. RTM – Ready to Manifacture – build Kentico CMS určený pro vypuštění. Sequence diagram – Diagram popisující jednu nebo více sekvencí zpráv procházející množinou objektů. State diagram – Diagram popisující stavy třídy nebo systému. UML – Unified Modeling Language – standard pro vizuální objektově orientované modelování. Use Case diagram – Diagram popisující jak může být používán systém (z pohledu určitého aktora).

Objektová procesní analýza a inovace informačního systému v podniku Kentico Software s. r. o

Recommend Documents