Masarykova univerzita

Transkript

1 Masarykova univerzita Fakulta informatiky Informační systém pro řízení zakázek malých a středních firem Bakalářská práce Jiří Forman Brno 2012

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

3 Poděkování Děkuji mému vedoucímu práce RNDr. Jaroslavu Ráčkovi, Ph.D. za odborné vedení v průběhu psaní této práce. V neposlední řadě děkuji mojí přítelkyni, rodině a kamarádům za podporu při studiu a rady při psaní práce.

4 Shrnutí Bakalářská práce se ve své úvodní části zabývá shrnutím vlastností malých a středních výrobních firem (SME) a jejich specifikacemi z pohledu procesů vztahujících se k průběhu zpracování zakázek. Následně se zaměřuje na analýzu stávajícího systému a návrh systému nového z pohledu procesního i datového. V poslední fázi je zpracována projektová dokumentace pro vývoj nového systému.

5 Klíčová slova evidenční systém, správa zakázek, BPMN, BPD, případy užití, diagram tříd, projektová dokumentace, PERT, rizika, Ganttův diagram, COCOMO

6 Obsah 1 ÚVOD CÍL PRÁCE CHARAKTERISTIKA SME SPECIFIKACE PROCESŮ SME ZPĚTNÁ ANALÝZA STÁVAJÍCÍHO SYSTÉMU BUSINESS PROCESS MODELING NOTATION (BPMN) ELEMENTY V BPMN Tokové objekty Spojovací objekty Plavecké dráhy BPD DIAGRAMY Business to business diagram (B2B) Diagram výroby SROVNÁVACÍ TABULKY FUNKCIONALIT NÁVRH NOVÉHO SYSTÉMU DIAGRAMY PŘÍPADŮ UŽITÍ (USE CASE) DIAGRAMY UŽITÍ NOVÉHO SYSTÉMU Aktéři IS PTv Diagramy případů užití IS PTv BPD DIAGRAMY B2B diagram Zpracování objednávky Evidence výroby Expedice Fakturace DATOVÝ NÁVRH Analytické třídy Hledání analytických tříd... 37

7 5 PROJEKTOVÁ DOKUMENTACE POPIS PROJEKTU ZDROJE Potřebné dovednosti TYP ŘÍDÍCÍHO PROBLÉMU Návrhový problém Inkrementální životní cyklus PLÁNY Ganttův diagram WBS (Work breakdown structure) diagram ODHAD DOBY PROJEKTU PERT Odhad ceny projektu INKREMENTY RIZIKA Rizika pro IS PTv TESTOVACÍ PLÁN ZÁVĚR LITERATURA SEZNAM OBRÁZKŮ PŘÍLOHY OBSAH PŘILOŽENÉHO CD... 58

8 1 ÚVOD V dnešní době se s informačními technologiemi setkáváme v každém odvětví lidské činnosti. Ve výrobních firmách může dobře aplikovaný software nejen ušetřit velké množství nákladů, ale dokonce i kompletně nahradit některé lidské činnosti. Možnost důsledné automatizované evidence průběhu realizace jednotlivých zakázek může v důsledku výrazně ovlivnit hospodaření firem a snížit celkové náklady. Aplikace Evidenční systém Pracant od společnosti Agerit s.r.o. se zabývá evidencí průběhu zakázek v malých a středních výrobních firmách, kde pomáhá vedení firmy odbourávat náklady a zbytečnou administrativu. Tento systém se však po 6 letech postupného vývoje od první nasazené verze dostává do stádia, kdy již není reálně možné přidávat zákazníky požadovanou funkcionalitu bez negativního ovlivnění té stávající. Na vině je především špatný počáteční návrh a naprosto neexistující jednotná struktura programu z hlediska kódu, způsobená částečně i častým střídáním členů vývojového týmu. Ve firmě Agerit s.r.o. jsem působil na pozici technické podpory a testera. Vzhledem k aktuálnímu stavu systému je naplánován vývoj nové verze. 1.1 Cíl práce Cílem této práce je analýza stávajícího systému a následný návrh systému nového spolu s přípravou projektové dokumentace. V rámci návrhu nového systému je nutné zohlednění rozdílných požadavky zákazníků v současné době a pokročilejší technologické možnosti, jako je možnost využití mobilních aplikací jako forma tenkého klienta. 8

9 2 CHARAKTERISTIKA SME 1 Cílovou skupinou pro systém Pracant jsou především malé a střední podniky. Nejlevnější varianta systému pak cílí i na mikro podniky. Mikro podniky jsou podniky s počtem zaměstnanců do 10 a součtu aktiv a obratu nepřesahující částku 50 miliónů Kč. Malé podniky jsou podniky s počtem zaměstnanců do 50 a součtu aktiv a obratu nepřesahující částku 250 miliónů Kč. Střední podniky jsou podniky s počtem zaměstnanců do 250 a obratem do 1,25 miliardy Kč. Komplexně v rámci struktury podnikání zastávají SME drtivou většinu. V EU operuje cca 23 miliónů SME, které představují cca 99% všech podniků EU. Tyto podniky mají mnohé výhody. Vyjma těch společenských je to například flexibilita, možnost se pohotově přizpůsobovat aktuální poptávce či angažování v okrajových oblastech trhu, které jsou pro velké podniky nezajímavé. Nevýhodou SME je pak nízká ekonomická síla a s tím související vyloučení z podnikání s nutnými velkými investicemi. Nemožnost běžného zaměstnání špičkových odborníků a dále pak neschopnost kvalitního monitorování vlastních výrobních procesů a využívání aktuálních technologií. [1] 2.1 Specifikace procesů SME Především nevýhody dělají z těchto podniků ideální cílovou skupinu pro systém Pracant. V době, kdy se systém začal vyvíjet (rok 2005) byla situace na trhu malých a středních podnikatelů s ohledem na využívání evidenčních systémů příznivá pro vstup nového produktu. 1 Small medium enterprises Malé a střední podniky 9

10 Za uplynulých 7 let se situace z hlediska využívání evidenčního software dramaticky zlepšila, nicméně trvající finanční krize se podepsala na útlumu celého výrobního odvětví. Z řad větších zákazníků zanikly prakticky veškeré podniky bez vazeb na automobilový průmysl. Z opačného spektra velikosti zákazníků, kde se vyskytují především dřevozpracující podniky, jich na trhu zůstalo jen několik nejsilnějších. Problémem SME je především absence jakéhokoliv pokročilejšího systému starajícího se o firemní procesy. Malé firmy o několika zaměstnancích řeší veškerou evidenci v papírové podobě, maximálně se zapojením tabulkového editoru. Klíčové body v rámci firemního procesu jsou mnohdy závislé na jedné osobě a v případě jejího onemocnění či opuštění firmy hrozí naprosté ochromení pracovního procesu či minimálně jeho výrazné zpomalení. [1] Situaci v těchto firmách můžeme shrnout do několika bodů: - Veškeré firemní know-how v rukou majitele či nejbližších spolupracovníků - Nedostatečná či neexistující dokumentace firemních procesů a z toho vyplívající nutnost pečlivého vytvoření této dokumentace při zavádění nového systému od začátku - Závislost jednotlivých procesů na konkrétních osobách - Nedostatečné delegování pracovních povinností na zaměstnance pravděpodobné zahlcení majitele či užšího vedení firmy Těchto bodů jsem si v průběhu práce na původním systému a jeho zavádění ke konkrétním zákazníkům všiml mnohokráte. Aktuální systém odbourává velké množství uživatelských zásahů, nutí vedení firmy k vytvoření šablon na jednotlivé procesy u konkrétních zakázek (s výjimkou atypických zakázek) a částečně tak přebírá správu firemních procesů do své režie. Nicméně stále je nutná velká část uživatelského zásahu pro plnou funkčnost. Do nového systému jsem tak navrhl změny, které směřují k daleko vyšší integraci systému do firemních procesů. 10

11 3 ZPĚTNÁ ANALÝZA STÁVAJÍCÍHO SYSTÉMU Pro analýzu stávajícího systému bylo nejvhodnější využití procesní notace, která mně dopomohla odhalit ty části systému Pracant, které jsou spravovány systémem v rámci procesu zpracování zakázky. Z možných alternativ pro modelování procesů se nabízí využití starších diagramů datových toků (DFD diagramy) či objektově orientovaný diagram aktivit spadající pod metodiku UML. [2] [3] Pro procesní analýzu v tomto případě jsem si nicméně zvolil BPM notaci, která nabízí z mého pohledu velmi dobrou možnost zobrazení procesů v podobě, které jsou snadno čitelné i pro běžného čtenáře. [4] 3.1 Business Process Modeling Notation (BPMN) Standard BPMN 1.0 vydán v roce 2004 organizací Business Process Management Initiative (BPMI) si klade za cíl přehledné a snadno pochopitelné znázornění jednotlivých firemních procesů včetně jejich účastníků. BPMN definuje Business Process Diagram (BPD), který tyto procesy graficky znázorňuje. V roce 2011 byla vydána oficiální verze 2.0 pod hlavičkou organizace Object Management Group (OMG) rozšiřující tuto notaci o další elementy. 3.2 Elementy v BPMN Elementy v BPD diagramech jsou navrženy pro co nejlehčí srozumitelnost jak z hlediska analytika, tak z hlediska firemního uživatele. Dělí se na tyto kategorie: - Tokové objekty - Spojovací objekty - Plavecké dráhy - Artefakty 11

12 Artefakty slouží pro přidání dodatečných informací k objektům a nejsou pro plné pokrytí procesů nutné Tokové objekty Základními prvky BPD jsou tokové objekty, které identifikují jednotlivé činnosti v procesu. Těmito objekty jsou: - Událost (Event) - Aktivita (Activity) - Brána (Gateway) Událost Událost je znázorněna pomocí kruhu a značí určitou událost v rámci procesu. Rozlišujeme tři druhy událostí a to počáteční, střední a koncovou. Pro všechny druhy událostí platí označení v podobě kruhu, v rámci něhož mohou být znázorněny značky příčin události. Aktivita Aktivita je znázorněna obdélníky se zaoblenými rohy. Představuje práci v rámci procesu. Dělí se na procesy a podprocesy. Opět mohou obsahovat dodatečné grafické informace o povaze aktivity. Brány Brány jsou znázorněny pomocí diamantu a slouží pro rozdělení a případné sloučení procesního toku. Ve středu diamantu se nachází značky, které upřesňují, o jaký typ větvení či spojení se jedná. 12

13 Obrázek č. 1 BPMN Elementy (Události, Aktivity, Brány) Spojovací objekty Spojovací objekty propojují jednotlivé elementy diagramu a tvoří tak strukturu samotného procesu. Základní tři typy těchto objektů jsou: Sekvenční tok (Sequence Flow) Tok zpráv (Message flow) Asociace (Association) Sekvenční tok znázorňuje směrování procesu v diagramu a je znázorněn tučnou čarou s plnou šipkou. Tok zpráv znázorňuje výměnu zpráv mezi jednotlivými účastníky procesu a znázorňuje se pomocí přerušované čáry s prázdnou šipkou. Asociace se využívá pro přidružení dodatečných informací k jednotlivým objektům a znázorňuje se tečkovanou čarou. Obrázek č. 2 Spojovací objekty (Sekvenční tok, Tok zpráv, Asociace) 13

14 3.2.3 Plavecké dráhy Plavecké dráhy v rámci BPD slouží pro znázornění rozdílných funkcí a zodpovědností účastníků procesu. Plavecké dráhy dělíme na: - Bazén (Pool) - Dráhy (Lane) Bazén slouží pro grafické oddělení rozdílných množin aktivit a pro znázornění jednotlivých účastníků procesu. Dráha je podmnožinou bazénu. Využívají se pro podrobnější organizaci jednotlivých činností v diagramu. [4] [5] [6] Obrázek č. 3 Plavecké dráhy (Bazén, Dráha) 14

15 3.3 BPD diagramy Business to business diagram (B2B) Za pomocí BPD jsem namodeloval proces zpracování zakázky do takové míry, která pokrývá stávající systém. Pro namodelování jsem využil 5 diagramů. Základní z nich se nazývá B2B (Business to Business) a znázorňuje shrnutí procesu z pohledu hlavních zúčastněných subjektů. V tomto případě firmy a zákazníka. Na straně zákazníka neznáme jeho interní procesy, které se odehrávají mezi aktivitami, v rámci nichž komunikuje se systémem, proto se na B2B diagramu znázorňují výhradně činnosti, které komunikují se systémem. Na tomto diagramu je patrné rozdělení procesu na straně systému do čtyř hlavních modulů: - Zpracování objednávky - Výroba - Expedice - Fakturace 15

16 Obrázek č. 4 B2B diagram aktuálního systému 16

17 Proces začíná odesláním objednávky ze strany zákazníka. Po zpracování objednávky dochází k jejímu přijetí a odeslání cenové nabídky či odmítnutí objednávky. Následuje výrobní proces, který je níže popsán detailněji. Posledními částmi procesu jsou pak expedice a fakturace. V rámci dílčích diagramů se setkáváme s účastníky procesu zákazník, management firmy, vedoucí výroby, skladník, dělník, učtárna. První jmenovaný je na těchto dílčích diagramech zastoupen jen jako prázdný bazén přijímající a odesílající zprávy hlavnímu procesnímu bazénu a elementům v něm. S rozdělením, které se vyskytuje na dílčích diagramech, se setkáme i v další části práce. Zvolil jsem jej jako základní rozdělení modulů pro návrh nového systému Diagram výroby Vzhledem k tomu, že největší předností aktuální verze systému je evidence výroby, je tento diagram nejrozsáhlejší částí. Proces v něm znázorněný je aktivován s přijetím pokynu k výrobě. Vedoucí výroby spolu s daty systému sestaví návrh pracovního procesu což je seznam úkonů, které je nutno na konkrétní zakázce vykonat v rámci výroby pro její dokončení. K tomuto procesu vytvoří v systému seznam předpokládaného materiálu. Seznam předpokládaného materiálu je doručen skladníkovi, který materiál připraví pro vydání na zakázku. Souvisle s touto aktivitou je předán návrh pracovního procesu příslušnému dělníkovi, který po jeho obdržení vyzvedává již nachystaný materiál potřebný na zakázku ze skladu. V tomto bodě se přechází k samotné výrobě, kterou si dělník eviduje s pomocí sběrných terminálů. Vedoucí výroby může zasáhnout do průběhu výroby změnou pracovního procesu. Ve chvíli dokončení prací na zakázce a jejich kontrole vedoucím výroby je možné výrobek připravit k expedici. V případě, že se jedná o zakázku s více dílčími zakázkami, proces se opakuje. Pokud se jedná o jednotlivou zakázku, výrobek se podstupuje ke kompletaci, čímž proces výroby končí. Zbývající diagramy jsou přiloženy v elektronické příloze práce ve složce Zpětná analýza. 17

18 Obrázek č. 5 Diagram výroby aktuálního systému 18

19 3.4 Srovnávací tabulky funkcionalit Na základě BPD diagramů lze snadno odhadnou rozsah funkcionalit, které pokrývá aktuální systém. S jejich pomocí a s přihlédnutím na požadavky aktuálních zákazníků jsem sestavil tabulky funkcionalit. Jednotlivé tabulky jsou přiloženy v elektronické příloze ve složce Zpětná analýza. Obrázek č. 6 Ukázka tabulky funkcionalit modulu Fakturace pro jednoho účastníka Tabulky mně umožnily přehledným způsobem vedle sebe postavit funkcionalitu stávajícího systému a navrhnout funkcionalitu systému nového. Z přiložených tabulek, je jasně zřejmý důraz na zapojení lidské činnosti do procesu. S ohledem na co největší míru automatizace jsem navrhnul rozšíření funkcionality do nového systému. Stávající funkcionalita je však osvědčená a její základy se nijak měnit nebudou i s ohledem na možnost plynulého přechodu mezi verzemi systému u některých vybraných zákazníků. Rozsah navržených změn a vylepšení týkajících se každého jednotlivého modulu je obsáhlý. V případě jejich implementace bude na zvážení vývojového týmu, kterou funkcionalitu implementovat a kterou případně vynechat. 19

20 4 NÁVRH NOVÉHO SYSTÉMU Návrh datových a procesních struktur nového systému je možno provést mnoha způsoby. Vzhledem k využití BPM notace ve zpětné analýze je vhodné její opětovné využití pro znázornění procesů nového systému. Vzhledem k ponechání úvodní struktury softwaru lze pak snadno identifikovat rozdíly mezi stávající verzí a novým systémem. 4.1 Diagramy případů užití (Use Case) Diagramy případů užití slouží jako doplňkový nástroj pro upřesnění požadavků a funkcí budoucího software. V průběhu jejich modelování je především nutné nalezení a upřesnění hranic systému, specifikování aktérů a identifikování potřebných případů užití. [3] [7] Hranice systému Při návrhu softwaru je nezbytné určení jeho hranic. To znamená, že je třeba co nejpřesněji vymezit, jakou funkcionalitu bude daný software obstarávat a která již bude mimo něj. V diagramu jsou hranice vymezeny rámečkem s názvem software (v našem případě s názvem konkrétního modulu systému). Aktéři Aktér značí externí entitu, která užívá daný systém. Specifikuje její konkrétní roli v průběhu využívání systému. Aktérem může být fyzická osoba, ale také například jiný systém či organizace. Na obrázku č. 7 je zobrazena nejčastější grafická podoba aktéra. Alternativně může být zobrazen pomocí obdélníku s popisem uvnitř. 20

21 Případ užití Případy užití jsou specifikace posloupnosti činností, které systém či jeho část vykoná v průběhu interakce s aktérem. Případy užití jsou vždy iniciovány aktérem a jsou popsány z pohledu aktéra. Obrázek č. 7 Nejčastější znázornění aktéra a případu užití 4.2 Diagramy užití nového systému Pro souhrn funkcí jednotlivých modulů využijeme diagramů případů užití. V tomto konkrétním případě mně diagramy dopomohly k identifikaci aktérů a ujasnění funkcionalit, ke kterým budou potřebovat interakci se systémem. Vzhledem k faktu, že systém je navrhnut (jak je dále vidět na BPD diagramech) s ohledem na zastání co největšího množství činností automaticky, obsahují tyto diagramy jen malou část funkcionalit Aktéři IS PTv2 2 - Management firmy představuje vedení firmy, obstarávající především exekutivní činnosti, které systém nemůže rozhodnout sám či je mu rozhodnutí zakázáno na základě nesplnění potřebných podmínek. - Tenký klient externí přístup do systému sloužící především pro zobrazení stavu jednotlivých aktivit. Implementace plánována až po dokončení vývojové systému a provedení zkušebního nasazení u zákazníka. 2 IS PTv2 pracovní označení nové verze systému Pracant 21

22 - Zákazník v rámci interakcí se systémem je schopen především zadat objednávku a potvrdit platbu. Z dalších akcií se jedná většinově o přijímání informací. - Dodavatel materiálu externí systém, poskytuje systému informaci o nabídce materiálu - Vedoucí výroby v rámci modulu výroby nejdůležitější aktér s možností editace seznamu úkonů a materiálu. Dále má především funkci kontroly procesu výroby - Skladník přijmutí předpokladů materiálu od systému a celková evidence materiálu. V rámci expedice poté eviduje pohyb zásilky - Dělník přijmutí seznamu úkonů a následná evidence práce - Přepravní služba podobná funkce jako Dodavatel materiálu předává systému informace o pohybu zásilky, který je následně zprostředkovává zákazníkovi Diagramy případů užití IS PTv2 Na následujících stranách jsou znázorněny diagramy užití pro jednotlivé moduly systému. Případy užití v rámci administrace uživatelů není pro přehlednost na diagramech modelována. Ukázka případů užití - Přihlásit do systému umožňuje přihlášení do systému v rámci kterého se provádí ověření uživatelských oprávnění - Zamítnout seznam úkonů umožňuje vedoucímu výroby zamítnutí seznamu úkonu s následným vyžádáním vložení změn do návrhu tohoto seznamu (případ užití Upravit úkony) - Zkontrolovat fakturu umožňuje managementu firmy kontrolu faktury, v případě nutnosti její přepracování a uložení do systému - Zbývající případy užití jsou popsány v přiložené elektronické příloze ve složce Návrh nového systému. 22

23 Diagram případů užití: Zpracování objednávky Obrázek č. 8 Diagram případu užití: Zpracování objednávky Diagram případů užití: Evidence výroby Obrázek č. 9 Diagram případů užití: Evidence výroby 23

24 Diagram případů užití: Expedice Obrázek č. 10 Diagram případů užití: Expedice Diagram případů užití: Fakturace Obrázek č. 11 Diagram případů užití: Fakturace 24

25 4.3 BPD diagramy Oproti zpětné analýze, která nám má dát především představu o průběhu procesů v rámci firmy je návrh nové verze systému nutné provést v případě nutnosti do nižší úrovně dekompozice. BPD diagramy však nabízejí daleko vyšší úroveň čitelnosti pro běžného uživatele i při vyšší složitosti. Je proto možné znázornit v rámci jednoho diagramu více funkcionality při zachování jeho čitelnosti. V tomto směru jsou DFD diagramy, které bychom využili v případě modelování procesů a dat nového systému skrze strukturovanou analýzu daleko méně přehledné. [2] Pro názornou demonstraci jsem provedl procesní část návrhu i skrze DFD. V průběhu vytváření BPD diagramů byly procesy vyznačené v DFD diagramech značně optimalizovány. DFD diagramy v příloze této práce slouží spíše jako optické srovnání čitelnosti obou druhů diagramů. Textový popis k tomuto postupu je v přiložené elektronické příloze ve složce Návrh nového systému B2B diagram Na diagramu B2B vystupuje tentokráte již v komunikaci se zákazníkem čistě systém. Tento některé zprávy zasílá či přijímá automaticky, jiné na pokyn některého z účastníků výrobního procesu. B2B diagram je velmi podobný B2B diagramu ze zpětné analýzy původního systému. To je způsobeno tím, že nová verze systému byla navrhována i s přihlédnutím na fakt, že bude nasazena ke stávajícím zákazníkům. Výraznější změny ve struktuře komunikace dodavatele a poskytovatele by mohla tyto zákazníky odradit od koupě nové verze systému. 25

26 Obrázek č. 12 B2B diagram IS PTv2 26

27 4.3.2 Zpracování objednávky Proces zpracování objednávky byl z velké části zautomatizován a po nastavení základních hranic pro zamítnutí či potvrzení objednávky, by měl být schopen obstarat veškeré procesy nutné pro její zpracování, bez zásahu lidského faktoru. Ten je zapojen až ve chvíli, kdy proces vybočí z předem stanovených podmínek. Proces je započat přijetím objednávky od zákazníka, která je zadána do systému. Následně je spuštěno trojité zhodnocení objednávky. Z hlediska zákazníka jsou doplněny jeho údaje z registru ARES 3 a zkontrolován jeho případný výskyt na interním registru dlužníků. Z hlediska obsahu objednávky je porovnán její obsah s historií předchozích zakázek a na základě těchto dat jsou vyhodnoceny předpoklady pro potřebné lidské a materiální zdroje. Zde se proces opět rozdvojuje a dochází ke zbylým dvěma zhodnocením. Tyto jsou dále dekomponovány a budou blíže popsány později. Po dokončení ověření je proces sjednocen. Na základě výsledků trojice vyhodnocovacích procesů je doporučeno přijmutí či zamítnutí objednávky. Na tomto místě je kontrolována uživatelsky zvolená sada podmínek. V případě jejich splnění je objednávka v pozitivním případě podstoupena k sestavení a odeslání cenové nabídky zákazníkovi. V případě potvrzení cenové nabídky je případně doobjednán chybějící materiál a objednávka podstoupena do výroby. V záporném případě, tedy doporučení zamítnutí objednávky a splnění podmínek pro automatické zamítnutí je zákazník informován o zamítnutí. Následně je objednávka v systému zrušena a veškeré plány a blokace materiálních a lidských zdrojů jsou taktéž zamítnuty. 3 Administrativní registr ekonomických subjektů 27

28 K zapojení lidského účastníka na straně systému dochází v případě nesplnění některé z podmínek pro automatické přijmutí či zamítnutí. V tomto případě je zhodnocení podstoupeno managementu firmy, který dá pokyn k zamítnutí objednávky či k sestavení cenové nabídky. K dalšímu zapojení dalšího účastníka dochází v případě neakceptování cenové nabídky ze strany zákazníka. Management firmy v tomto bodu může cenovou nabídku přepracovat či zamítnout. 28

29 Obrázek č. 13 B2D diagram Zpracování objednávky IS PTv2 29

30 Zhodnocení pracovních kapacit Dílčí proces zhodnocení pracovních kapacit přebírá informace o objednávce a dle vyhodnocení historie zakázek kontroluje dostupné kapacity zdrojů. V případě jejich dostatku zaplánuje jejich využití. V případě nedostatku odesílá zamítnutí. Na rozdíl od nedostatku případného materiálu, je tato podmínka směrodatná a objednávka je tak zamítnuta, není-li uvedeno v následných uživatelských podmínkách uvedeno jinak. V rámci tohoto procesu je nutné připravení vstupů a výstupů pro následnou implementaci tenkého klienta. Ten v tomto procesu má možnost kontroly stavu a plánu kapacit a dále provést změnu v plánu. Obrázek č. 14 B2D diagram Zhodnocení pracovních kapacit IS PTv2 30

31 Zhodnocení skladových zásob V procesu zhodnocení skladových zásob dochází po přijetí informace z historie zakázek k vyhodnocení dostupného materiálu a sestavení seznamu potřebného materiálu. Pro případný chybějící materiál je seznamu dodavatelů zaslán požadavek na cenovou nabídku tohoto materiálu. Kompletní předpokládaný materiál je následně zablokován. Tenký klient 4 může v tomto případě schopen přístupu k evidenci materiálu. Obrázek č. 15 B2D diagram Zhodnocení skladových zá sob IS PTv2 4 Například mobilní aplikace plně závislá na systému sloužící především k zobrazování informací ze systému 31

32 4.3.3 Evidence výroby Proces evidence výroby je hlavní částí původního systému. Váha na tento modul zůstává ponechána, avšak je prakticky nemožné automatizovat většinu procesu ze strany systému a ani to není žádané. V tomto diagramu je tak zachycena interakce jednotlivých účastníků se systémem daleko častěji než v případě téměř plně automatizovaného zpracování objednávky. Proces začíná přijetím zpracované objednávky. Nejdříve je systémem sestaven seznam pracovních úkonů a seznam potřebného materiálu. Tyto jsou předány vedoucímu výroby pro kontrolu. V případě nutných změn je vedoucí výroby zadává do systému, který vyhodnotí možnost změn. V případě úkonů kontroluje volnost kapacit zdrojů a v případě materiálů je systém schopen automaticky objednat chybějící materiál. Po provedení kontrol je seznam materiálu zaslán skladníkovi, který připraví materiál pro vydání do výroby. Současně s tímto je odeslán seznam úkonů dělníkovi, který si po jeho přijetí převezme materiál ze skladu. Po započetí práce na zakázce si tuto práci dělník eviduje pomocí sběrných terminálů, které předávají tuto informaci systému. Po dokončení práce na zakázce je vyhodnocena docházka zaměstnanců na základě vykázané práce a zakázka je předána vedoucímu výroby pro finální kontrolu. V případě zamítnutí stavu zakázky je proces opakován od návrhu seznamu úkonů. V případě schválení je zkontrolována existence zakázky s více podzakázkami. V případě zjištění, že se jedná o takovouto zakázku se proces opakuje na další podzakázce. V případě zamítnutí je podstoupena skladníkovi ke kompletaci. Tímto proces výroby končí. 32

33 Obrázek č. 16 B2D diagram Evidence výroby IS PTv2 33

34 4.3.4 Expedice Proces v rámci modulu expedice je aktivován kompletací a následným ukončením výroby. Systém automaticky objednává přepravu výrobku a po obdržení sledovacího čísla a potvrzení přepravy předává pokyn skladníkovi k expedici. Po připravení výrobku k expedici je výrobek expedován. Zároveň je předána informace o sledovacím čísle a odeslání zákazníkovi. Následovně je prováděna kontrola doručení výrobku. Informaci o stavu zásilky systém zprostředkovává v případě dotazu i zákazníkovi. Obrázek č. 17 B2D diagram Expedice IS PTv2 34

35 4.3.5 Fakturace Po expedici výrobku jsou systémem vyhodnoceny náklady a vystavena faktura. Tato je podstoupena ke kontrole managementu firmy. V případě jejího schválení systém automaticky fakturu odesílá zákazníkovi. Po vypršení data splatnosti systém kontroluje stav bankovního účtu. V případě neobdržení platby je zákazníkovi automaticky vystavena a zaslána upomínka a kontrola platby se po třech dnech opakuje. Po obdržení platby dochází k jejímu automatickému zaúčtování a následnému vyhodnocení zakázky z pohledu materiálu a zdrojů. Prostřednictvím tenkého klienta lze v tomto případě monitorovat stav platby. 35

36 Obrázek č. 18 B2D diagram Fakturace IS PTv2 36

37 4.4 Datový návrh Návrh datového modelu pomáhá k utvoření představy, jakým způsobem budou v rámci budoucího systému proudit jednotlivé datové pakety. Pro vyjádření základních vazeb využiji diagram analytických tříd, který v oblasti objektově orientovaného návrhu nahrazuje klasický ERD diagram. Grafické znázornění obsahuje obdélník, reprezentující třídy (entity) analyzované domény, čáry mezi nimi jsou poté vazbami (relacemi). Čáry mohou být doplněny na obou koncích označením kardinality. Tato je značena pomocí číselných hodnot. Její význam je však stejný jako u grafického vyjádření na ERD diagramu. Šipka zakončená trojúhelníkem poté značí relaci dědičnosti Analytické třídy Analytická třída znázorňuje pojmy skutečného světa s vysokou úrovní abstrakce. Hlavním cílem těchto tříd je zachycení podstatné myšlenky. Samotný detailní implementační návrh tříd, ze kterého je možné vygenerovat velkou část funkčního kódu systému, se ponechává na pozdější fázi do návrhového diagramu. Jednotlivé atributy tříd a jejich činnosti se do diagramu mohou přidat při následném rozpracování analytického diagramu či v rámci sestavování diagramu návrhového Hledání analytických tříd Správná identifikace analytických tříd je velmi obtížný proces. Existuje několik metod, které mohou pomoci ve správné identifikaci konkrétních tříd. Přesný algoritmus jak provést tuto činnost s absolutní přesností však neexistuje. Pro odhalení těchto základních tříd jsem využil především metodu Proces analýzy podstatných jmen a sloves. V rámci tohoto postupu jsem zanalyzoval veškeré dostupné informace, které o systému mám k dispozici. Především jsem vycházel z již sestrojeného procesního modelu a případů užití. Po identifikaci zmíněných slov či slovních spojení jsem provedl 37

38 jejich setřídění na potenciální třídy, atributy a vlastnosti a odstranil synonyma. Z těchto prvků jsem následně sestavil navazujícím postupem po směru procesu v procesním modelu analytický model tříd. [3] Obrázek č. 19 Analytický diagram tříd IS PTv2 38

39 5 PROJEKTOVÁ DOKUMENTACE 5.1 Popis projektu Na základě zkušeností s vývojem aktuálního informačního systému starajícího se o správu zakázek u středních a malých výrobních firem, bude vyvinut nový systém odpovídající požadavkům moderní doby. Nad rámec aktuálního projektu je nutné připravení vstupních a výstupních bodů pro dodatečnou implementaci ovládání skrze webové rozhraní či mobilního tenkého klienta. Technologie, na které bude projekt postaven, není prozatím určena. 5.2 Zdroje Vývoj je naplánován pro deseti členný tým, který bude v jeho maximálním počtu využit především v průběhu implementaci jednotlivých inkrementů. V průběhu analýzy předchozího systému a návrhu systému nového jsou potřební především analytici a hlavní tester. Naopak v poslední třetině projektu je využit především QA tým skládající se z testerů a analytici pro následné předání. Tři z pěti programátorů již v tuto chvíli mohou býti alokování na jiném projektu Potřebné dovednosti Vzhledem k možnosti využití grafického vzhledu předchozí verze aplikace s drobnými úpravami není na hlavní část projektu nutný grafik. Konkrétní technologie, na které se bude projekt Nutné dovednosti zdrojů pro projekt: - Programátor (technologie prozatím neurčena) - Tester - Analytik 39

40 5.3 Typ řídícího problému V průběhu návrhu softwarového projektu rozlišujeme několik druhů řídících problémů SW projektů, dle kterých se dá poté určit, který model životního cyklu vývoje SW je vhodné zvolit pro daný projekt. [7] [8] [9] Typ problému identifikujeme pomocí určení úrovní jistot, které v projektu máme. Jistota produktu - jsou uživatelské požadavky jasně specifikovány? - jak jsou tyto požadavky zranitelné? Jistota procesu - máme možnost přesměrování vývojového procesu? - jaká je úroveň měřitelnosti procesu? - jaká je míra použití nových, neznámých technologií? - známe důsledky řídících akcí? Jistota zdrojů - máme k dispozici potřebné kvalifikované pracovníky? Realizační Alokační Návrhový Výzkumný Jistota produktu vysoká vysoká vysoká nízká Jistota procesu vysoká vysoká nízká nízká Jistota zdrojů vysoká nízká nízká nízká Tabulka č. 1 zvolení řídícího problému 40

41 5.3.1 Návrhový problém Vzhledem k faktu, že projekt je pokračováním již vyvinutého software, je jistota produktu vysoká. Prozatímní nerozhodnost managementu firmy z hlediska použití technologie však snižuje jistotu procesu na nízkou. Stejně tak nutnost rozšíření vývojového týmu o nové zaměstnance snižuje jistotu zdrojů na nízkou. Z tohoto zhodnocení nám vyplívá, že se jedná o návrhový problém. Tento se vyznačuje především nutností pečlivé analýzy projektu, důsledného rozvržení zdrojů na jednotlivé pozice, nutností měření postupu a využitím inkrementálního životního cyklu Inkrementální životní cyklus Obrázek č. 20 Inkrementální životní cyklus [7] Inkrementální životní cyklus značí rozdělení vývoje projektu na samostatné inkrementy (moduly). V rámci těchto modulů je částečně využito vodopádového cyklu. Po dokončení posledního vývojového inkrementu jsou moduly testovány s ohledem na vzájemnou spolupráci. 41

42 5.4 Plány Plán projektu a na něj navázaný odhad času či ceny projektu jsou založeny na mé krátké zkušenosti s údržbou a vývojem aktuální verze systému, o kterém bakalářská práce pojednává. Vzhledem k mé nezkušenosti a rané fázi projektu mohou být odhady těchto hodnot poněkud vzdáleny těm reálným Ganttův diagram Ganttův diagram je pruhový diagram využívající se ve své upravené verzi pro grafické znázornění plánu projektu v čase. V původní verzi nebylo možné zobrazení vztahů mezi činnostmi. V moderních softwarových nástrojích pro jeho návrh (v této práci využit MS Project 2010) je modelován současně spolu s diagramem WBS (Work Breakdown Structure), jak je viditelné na obrázku č. 21 ze software MS Project Obrázek č. 21 WBS diagram (vlevo), Ganttův diagram (vpravo) Výhodou Ganttova diagramu je srozumitelnost a snadná čitelnosti pro široký okruh lidí. U větších projektů, u kterých se diagram nevejde na jeden list A4 (ekvivalent aktivit v projektu) tato výhoda odpadá a diagram se stává téměř nečitelným. 42

43 Obrázek č. 22 Ganttův diagram IS PTv WBS (Work breakdown structure) diagram WBS diagram slouží v rámci řízení projektů pro dekompozici projektu na menší komponenty. Jednotlivým komponentům se pro kontrolu komplexnosti projektu může přiřadit procentuální hodnota jejich rozsahu v projektu. Součet těchto komponent poté musí dát 100%. Skrze diagram nemusí nutně být zobrazeny jen činnosti na projektu. Ekvivalentním způsobem lze zobrazit i například dekompozici produktu na součástky či zaměstnaneckou strukturu ve firmě. Obrázek č. 23 Schéma struktury projektu součást Ganttova diagramu v MS Project 43

44 Obrázek č. 24 WBS diagram IS PTv2 44

45 5.5 Odhad doby projektu PERT Metoda PERT (Project Evaluation and Review Technique) se využívá pro přesnější odhad doby trvání projektu. Je založen na 3 odhadech: - optimistický - nejpravděpodobnější - pesimistický Výpočet Výpočet je založen na váženém průměru jednotlivých hodnot. Výpočet času pro jednotlivý úkon je tedy: - OO = optimistický odhad - NO = nejpravděpodobnější odhad - PO = pesimistický odhad Výpočet pro celý projekt je pak sumou výpočtů pro všechny aktivity. [10] Váhy Váhy pro jednotlivé odhady nastavujeme dle našeho odhadu pravděpodobného scénáře projektu. Součet váh musí být vždy 6. Myslíme-li si, že projekt bude spíše problematický, nastavíme váhu 1 na vyšší hodnotu (např. 4,1,1 pro velmi pesimistický odhad). Základní nastavení v MS Project, skrze který jsem PERT pro tento projekt počítal, je 1,4,1. Váhy pro výpočet PERT nad IS PTv2 projektem jsem z důvodu nejistoty procesů a zdrojů nastavil na 1,2,3. 45

46 PERT pro IS PTv2 Dle původního odhadu, který jsem provedl, byl projekt naplánován na 122 dní. Tento údaj jsem využil i jako nejpravděpodobnější variantu pro výpočet PERT. Do optimistického odhadu jsem promítnul zkrácení doby jednotlivých aktivit a především zrušení druhé části implementace a jednotkového testování ve vývojových inkrementech. V pesimistickém odhadu jsem naopak tyto doby značně prodloužil. Optimistický odhad Nejpravděpodobnější odhad Pesimistický ohad PERT Doba projektu 62 dní 122 dní 217 dní 158,83 dní Tabulka č. 2 Ukázka jednotlivých časových odhadů Tabulka č.2 ukazuje, že při výpočtu skrze PERT se odhadovaná doba projektu prodloužila téměř o měsíc. Hodnota 158,83 dní nám dává při vytížení zhruba 4 zdrojů denně výsledek 635 člověkodnů (man-day) respektive 32 člověko-měsíců. Tyto hodnoty jsou velmi často využívány v rámci plánování aktivit a vytváření časových a finančních odhadů. 1 člověko-den vyjadřuje práci, kterou vykonná jeden člověk za jeden pracovní den. Veškerá data zdrojů, Ganntova diagramu (včetně PERT odhadu) jsou přiložena k práci v elektronické příloze ve složce Projektová dokumentace. 46

47 CPM Další metodou pro přesnější odhad doby je algoritmus CPM (Critical path method). Jedná se o výpočet kritické cesty v projektu. [10] Odhad ceny projektu V rané fázi projektu bez finálně specifikované technologie, která bude využita a především bez potřebné zkušenosti analytika z předchozích projektů, je reálný odhad ceny velmi obtížný. Odhad pro tento projekt jsem provedl pomocí dvou metod. Jednou z nich je využití hodinového odhadu vypočítaného skrze PERT a další metodou je odhad pomocí funkčních bodů. Ty je možné následně využit při výpočtu skrze metodiku COCOMO [11]. Odhad ceny s pomocí hodnoty času PERT MS Project dokáže skrze přiřazení zdrojů k aktivitám a nastavení jejich ceny vypočítat odhadovanou cenu zdrojů na projektu vynásobením počtu jejich naplánovaných hodin s hodinovou mzdou. Mzda zadávaná do MS Project vyjadřuje náklady za celý projekt (včetně režií, nikoli jen plat za zaměstnance). Odhad ceny za projekt pro dobu odhadlou skrze PERT je Kč. Tato částka reflektuje dobu projektu 158,83 dní s ohadem průměru aktivních 4 osob za den (jednotlivé pozice v rámci projektu nejsou s vyjimkou hlavního analytika využity po celou dobu projektu). Odhady v takto raném období projektu bez specifikované technologie, známých zdrojů a dalších informací se mohou až několikanásobně lišit od reality. 47

48 Odhad s pomocí uřčení množství funkčních bodů Odhad s pomocí funkčních bodů je založen na normalizování metriky ohodnocení softwarového projektu dle pevně stanovených kritérií. Předmětem ohodnocení v tomto případě není technická část projektu (nezkoumá se kód samotný či zvolený programovací jazyk), ale část aplikační. Měří se vstupy, výstupy, dotazy, vnitřní paměti a vnější paměti. Princip odhadu: velikost projektu X složitost X rizikové faktory = odhad [12] Po ohodnocení jednotlivých parametrů potřebných pro dosazení do zmíněné rovnice jsem došel k hodnotě 630 funkčních bodů pro navrženou aplikaci [12] [13]. Po vložení této hodnoty do výpočtu COCOMO II 5 a nastavení jednotlivých parametrů dle předpokládaných hodnot projektu byla vypočítaná hodnota 109,7 člověko-měsíců. Zobrazení nastavení výpočtu COCOMO II je přiloženo v příslušné sekci elektronické přílohy. Tato hodnota se velmi vzdaluje odhadu provedeném v MS Project. Jak bylo uvedeno, rané odhady se mohou v rámci ceny i odhadovaného času lišit od reality až v rozmezí čtyřnásobku oběma směry. Jsem nicméně přesvědčen, že pro projekt tohoto rozsahu je mnou navržená délka projektu (tedy zhruba 8 pracovních měsíců) reálná. 5.6 Inkrementy Jak je vidět z Ganttova diagramu a WBS diagramu na předchozích stranách, rozdělil jsem projekt na 6 inkrementů. Z těchto inkrementů jsou reálné vývojové inkrementy 4. Tyto odpovídají modulární struktuře programu inkrementy Modul objednávky, Modul výroba, Modul expedice, Modul fakturace. 5 Online kalkulačka na adrese: 48

49 V rámci jednotlivých vývojových inkrementů se posloupnost činností opakuje. Nejdříve se specifikuje přesný postup daného inkrementu. Následně se přistoupí k samotné implementaci, doplněné jednotkovým testováním. V ideálním případě následují přímo inkrementační integrační testy a týmový feedback, v opačném případě se opakuje aktivita implementace a jednotkové testování. Modul úvodní studie obsahuje, jak z názvu vyplývá, studii stávajícího systému a návrh systému nového, ale také alokaci lidských zdrojů s následným školením zaměstnanců či sestavení testovacího plánu. Inkrement Finální fáze se skládá ze tří částí. 1. fáze obsahuje celkové integrační testy všech modulů, následují validační testy a zkušební zavedení programu u zákazníka. 2.fáze obsahuje především akceptační testy ve spolupráci s konkrétním zákazníkem na jeho pracovišti. Následně je provedena série testů dle testovacího plánu, doplněna o implementaci oprav případných chyb či navržených změn. Po dokončení zaváděcí a testovací části je projekt připraven k předání zákazníkovi. Následná implementace webového rozhraní systému a mobilního tenkého klienta není předmětem této analýzy ani projektové dokumentace. 5.7 Rizika Riziko překročení rozpočtu či dokonce krach celého projektu je při vývoji softwarových aplikací velmi vysoké. Toto riziko je určováno mnoha faktory. Významnou roli hraje lidský faktor. Nezkušený analytik může navrhnout nereálnou analýzu projektu a způsobit krach v jeho počátcích. Klíčový programátor s nedostatkem zkušenosti v potřebné technologii zase může způsobit značné zpomalení projektu a jeho prodražení v jeho průběhu. Ekvivalentním způsobem mohou projekt postihnout chyby kterékoliv klíčové osoby projektu či klíčových osob ze zadávající strany. Lidský faktor však není jediný potenciální problém pro softwarové projekty. 49

50 Analýzou rizik je možné těmto problémům předcházet. Je na volbě každého manažera projektu, jestli investuje finance do předcházení rizik. Toto se vyplatí především u velkých projektů s vysokou úrovní požadované spolehlivosti a kvality produktu. Z hlediska financí se kontrola rizik promítne do projektu následovně. Pro každé indentifikované či předpokládané riziko se stanoví konkrétní technika pro jeho řízení. Následně se odhadne pravděpodobnost chyby a škoda, která by byla projektu způsobena při jejím výskytu. Dále se určí cena řízení daného rizika. Z těchto čísel poté manažer daného projektu může odhadnout, vyplatí-li se riziko řídit a nebo jej ponechat bez řešení. Řízení určitého rizika by mělo vyústit ve snížení šance na jeho výskyt na nízkou úroveň, neznamená to nutně jeho naprosté vymýcení Rizika pro IS PTv2 Zmínění rizika jsou zmíněna dle rozdělení fází vývoje v rámci projektu IS PTv2. Cenové odhady byly sestaveny na základě časového odhadu z Ganttova diagramu po provedení PERT. Následuje ukázka několika rizik a jejich řízení. Úvodní studie Chybné specifikace požadavků - PST 6 výskytu: 0,05 (specifikace pro nový projekt vychází z jeho předchozí verze a požadavků konkrétních zákazníků, proto je nízká pravděpodobnost výskytu) - Cena úkonu bez řízení rizik: Kč - Řízení rizika: konzultace se stávajícími zákazníky, ověření využitelnosti navržených změn pomocí dotazníků u zákazníků, vyhodnocení získaných dat - Důsledek řízení rizika: 6 zkratka pro pravděpodobnost 50

51 o Prodloužení úvodní studie na dvojnásobný čas o Snížení PST rizika: 0,01 o Zvýšení ceny dané aktivity o Kč. - Hrozba ztráty při výskytu bez řízení: 0 plná cena projektu, dle doby projevení chyby - Hrozba ztráty při výskytu s řízením: Kč plná cena projektu. Vývojové inkrementy Opakující se kritické chyby v základních funkcionalitách - PST výskytu: 0,2 (Najmutí jednotlivci jsou zkušení, nicméně jako celek spolu mohou mít především v počátku projektu problém spolupracovat. To může mít za následek způsobení problémů například při synchronizaci kódu. - Cena úkonu bez řízení rizik 7 : Kč - Řízení rizika: přijmutí dalšího programátora se zkušeností vedení projektu nad využitou platformou - Důsledek řízení rizik: o Urychlení vývoje, s tím spojené snížení nákladů na projekt o Zvýšení ceny dané aktivity: Kč, snížení ceny projektu na základě snížení času přibližné vyrovnání nákladů o Snížení PST rizika: 0,03 - Hrozba ztráty při výskytu bez řízení: 0 plná cena projektu - Hrozba ztráty při výskytu s řízením: 0 plná cena projektu - V případě, že není omezení např. prostorové, je vhodné toto řízení rizika aplikovat ihned se začátkem náboru lidských zdrojů 7 součet jednotlivých implementačních částí všech čtyř vývojových inkrementů 51

52 Finální fáze Neakceptování předání software v důsledku nenaplnění veškerých zákazníckých požadavků - PST výskytu: 0,05 (viz zdůvodnění rizika Chybné specifikace požadavků) - Cena úkonu bez řízení rizik 8 : Kč - Řízení rizika: Důkladnější akceptační testy, posílení týmu přítomného při akceptačních testech o jednoho programátora - Důsledek řízení rizik: o Vytvoření podrobné dokumentace z akceptačních testů, dodatečná kontrola splnění veškerých požadovaných kroků testování o Zvýšení ceny dané aktivity: Kč o Snížení PST rizika: 0,01 - Hrozba ztráty při výskytu bez řízení: Kč plná cena projektu - Hrozba ztráty při výskytu s řízením: Kč plná cena projektu 5.8 Testovací plán Testovací plán je nezbytnou součástí každé dokumentace k větším projektům. Obsahuje podrobný popis procesu testování v průběhu vývoje aplikace. Je rozdělen na několik částí: - Cíl testování - Podmínky a možná omezení testování - Specifikace testovaného objektu - Testovací strategie - Zdroje pro testování - Harmonogram testování [15] 8 Počítán jen úkon předání projektu 52

53 Vyhotovený testovací plán je součástí elektronické přílohy ve složce Projektová dokumentace. 6 ZÁVĚR Analýza reálného systému a následný návrh nové verze se v průběhu psaní ukázaly jako velmi náročná problematika, vyžadující velké množství dodatečného studia nad rámec látky vyučované v rámci bakalářského studia. Cílem práce byla zpětná analýza aktuální verze systému s následným navrhnutím nových funkcionalit, zaznamenáním těchto změn do nového datového a procesního návrhu systému a následně vytvoření základů projektové dokumentace. Vytvoření zpětné analýzy systému nebylo z pohledu zkušeného uživatele systému příliš složité. Dopomohlo odhalit několik mezer v aktuálním procesu zpracování zakázek, o který se systém především stará. Navržení nové verze systému již představovalo výraznou výzvu, vzhledem k potenciální nutnosti využití tohoto návrhu při reálném vývoji. Bakalářská práce obsahuje detailní pohled na navržené procesy v rámci nového systému. Vzhledem k využití stejné procesní notace jako při zpětné analýze je možné tyto procesy reálně srovnávat mezi sebou a identifikovat navržené změny. Datový návrh pomocí diagramů tříd již představuje blízký pohled na samotnou funkcionalitu systému a s určitou mírou optimalizace s ohledem na zvolenou technologii bude spolu s procesními diagramy sloužit jako konkrétní zadání pro programátory. Poslední část tedy navrhnutí projektové dokumentace představovalo z hlediska využitelnosti největší výzvu. Nedostatek zkušeností s reálným vývojem představoval při návrhu největší problém, se kterým jsem se potýkal. 53

54 Věřím, že práce či alespoň některé její části budou v budoucnu využity v rámci reálného vývoje. V případě, že by se vývoj nové verze aplikace opravdu zrealizoval, nabízí se možnost pokračování této práce v podobě zhodnocení reálného průběhu vývoje oproti výsledkům a návrhům, které jsou prezentovány v této bakalářské práci. 54

55 7 LITERATURA 1. Havlíček, K., Kašík, M. Marketingové řízení malých a středních podniků. Praha : Management Press, ISBN Ráček, J. Strukturovaná analýza systémů. Brno : Masarykova univerzita, ISBN Arlow, J., Neustadt, I. UML 2 a unifikovaný proces vývoje aplikací. Brno : Computer Press, a.s., ISBN Object Management Group. Business Proces Model and Notation (BPMN), Version 2.0. [Online] < 5. Ráček, J. Business Process Modeling Notation. Studijní materiály předmětu PV165, Procesní řízení. [Online] < 6. White, S. Introduction to BPMN. [Online] < 7. Fiala, J., Ministr, J. Průvodce analýzou a modelováním procesů. Ostrava : Vysoká škola báňská - Technická univerzita, ISBN Ráček, J., Sochor, J. Úvod do projektového řízení, plánování projektu. Studijní materiály předmětu PA104 - Vedení týmového projektu. [Online] < 9. Fiala, P. Řízení projektů, 1.vyd. Praha : Vysoká škola ekonomická, ISBN Fischer, L. Workflow handbook 2004: published in association with workflow management coalition. místo neznámé : Lighthouse Point: Future Strategies, ISBN Ráček, J., Sochor, J. Plánovací a odhadovací nástroje. Studijní mateirály předmětu PA104 - Vedení týmového projektu. [Online] < 55

56 12. Ráček, J., Sochor, J. Odhadování ceny SW - COCOMO 2. Studijní materiály předmětu PA104 - Vedení týmového projektu. [Online] < 13. Ráček, J., Sochor, J.. Funkční body. Studijní materiály předmětu PA104 - Vedení týmového projektu. [Online] < 14. Alexander, A. How to determinate your software application size using Function point analysis. [Online] < 15. Patton, R. Testování softwaru. Praha : Computer Press a.s., ISBN

57 8 SEZNAM OBRÁZKŮ Obrázek č. 1 BPMN Elementy (Události, Aktivity, Brány) Obrázek č. 2 Spojovací objekty (Sekvenční tok, Tok zpráv, Asociace) Obrázek č. 3 Plavecké dráhy (Bazén, Dráha) Obrázek č. 4 B2B diagram aktuálního systému Obrázek č. 5 Diagram výroby aktuálního systému Obrázek č. 6 Ukázka tabulky funkcionalit modulu Fakturace pro jednoho účastníka Obrázek č. 7 Nejčastější znázornění aktéra a případu užití Obrázek č. 8 Diagram případu užití: Zpracování objednávky Obrázek č. 9 Diagram případů užití: Evidence výroby Obrázek č. 10 Diagram případů užití: Expedice Obrázek č. 11 Diagram případů užití: Fakturace Obrázek č. 12 B2B diagram IS PTv Obrázek č. 13 B2D diagram Zpracování objednávky IS PTv Obrázek č. 14 B2D diagram Zhodnocení pracovních kapacit IS PTv Obrázek č. 15 B2D diagram Zhodnocení skladových zá sob IS PTv Obrázek č. 16 B2D diagram Evidence výroby IS PTv Obrázek č. 17 B2D diagram Expedice IS PTv Obrázek č. 18 B2D diagram Fakturace IS PTv Obrázek č. 19 Analytický diagram tříd IS PTv Obrázek č. 20 Inkrementální životní cyklus [7] Obrázek č. 21 WBS diagram (vlevo), Ganttův diagram (vpravo) Obrázek č. 22 Ganttův diagram IS PTv Obrázek č. 23 Schéma struktury projektu součást Ganttova diagramu v MS Project. 43 Obrázek č. 24 WBS diagram IS PTv