BUSINESS ANALÝZA DLE METODIKY RUP A JEJÍ PODPORA V NÁSTROJI ENTERPRISE ARCHITECT

MENDELOVA ZEMĚDĚLSKÁ A LESNICKÁ UNIVERZITA V BRNĚ Provozně ekonomická fakulta

BUSINESS ANALÝZA DLE METODIKY RUP A JEJÍ PODPORA V NÁSTROJI ENTERPRISE ARCHITECT BAKALÁŘSKÁ PRÁCE

Vedoucí práce: Ing. František Dařena Ph.D.

Vypracoval: Vít Néma

BRNO 2008

PROHLÁŠENÍ Prohlašuji, že jsem bakalářskou práci na téma „Business analýza dle metodiky RUP a její podpora v nástroji Enterprise Architect“ vypracoval samostatně a použil pouze pramenů, které cituji a uvádím v přiloženém seznamu literatury.

Bakalářská práce je školním dílem a může být použita ke komerčním účelům jen se souhlasem vedoucího diplomové práce.

Dne

25.5.2005

Podpis studenta……………………….

-2-

ABSTRAKT Práce se zabývá popisem analytické fáze v procesu vývoje software a jejím praktickým využitím v iterativní metodice, za kterou je považován Rational Unified Process (RUP). Je zde rozpracována zejména oblast datového modelování a procesní analýzy, která je však usazena do širokého kontextu metodiky RUP. Součástí práce je také vytvoření části procesní analýzy a doménového modelu za pomocí nástroje Enterprise Architect.

ABSTRACT This document describes business analytic phase of software development process, according RUP. Main emphasis lays on data and process modeling which is covered with the whole context of RUP methodology. The component part of this document is also domain model and business process model. All models are created with the data modeling tool Enterprise Architect.

-3-

OBSAH 1 Úvod, cíl práce ........................................................................................................................ - 8 1.1 Úvod....................................................................................................................................... - 8 1.2 Cíl práce................................................................................................................................ - 8 2 Metodika RUP ........................................................................................................................... - 9 2.1 Historické milníky vzniku metodiky RUP .............................................................................. - 9 2.2 Co lze u RUP využít? ........................................................................................................... - 10 2.3 RUP, jeho modifikace a podpůrné nástroje.................................................................... - 13 2.4 Fáze Rupu – životní cyklus.................................................................................................. - 14 2.4.1 Příprava projektu............................................................................................................ - 14 2.4.2 Zahájení ........................................................................................................................... - 16 2.4.3 Příprava............................................................................................................................ - 16 2.4.4 Konstrukce ....................................................................................................................... - 17 2.4.5 Předání............................................................................................................................. - 18 2.5 Hlavní disciplíny RUP........................................................................................................... - 18 2.5.1 Tvorba podnikového modelu...................................................................................... - 19 2.5.2 Správa požadavků ........................................................................................................ - 19 2.5.3 Analýza a návrh ............................................................................................................. - 20 2.5.4 Implementace................................................................................................................ - 20 2.5.5 Testování .......................................................................................................................... - 21 2.5.6 Nasazení .......................................................................................................................... - 22 2.6 Podpůrné disciplíny RUP .................................................................................................... - 23 2.6.1 Řízení projektu................................................................................................................. - 23 2.6.2 Řízení změn a konfigurace ........................................................................................... - 23 2.6.3 Správa prostředí ............................................................................................................. - 24 2.7 Šest praktik .......................................................................................................................... - 24 2.7.1 Vizuální modelování. ..................................................................................................... - 24 2.7.2 Správa a řízení požadavků........................................................................................... - 25 2.7.3 Komponentová architektura....................................................................................... - 25 2.7.4 Iterativní vývoj................................................................................................................. - 25 2.7.5 Řízení změn...................................................................................................................... - 25 2.7.6 Průběžné ověřování kvality.......................................................................................... - 26 3 Business analýza.................................................................................................................... - 27 3.1 RUP Business analýza ......................................................................................................... - 27 3.1.1 Podniková strategie ...................................................................................................... - 30 3.1.2 Procesní model............................................................................................................... - 30 3.1.3 Automatizace................................................................................................................. - 33 3.1.4 Doménový model.......................................................................................................... - 33 3.1.5 Model organizační struktury......................................................................................... - 34 3.2 Rozbor vstupních požadavků a výběr vhodných komponent .................................... - 34 3.2.1 Popis tvorby a prvků použitých v analýze................................................................. - 34 4 Business analýza – praktická část....................................................................................... - 41 4.1 Zadání.................................................................................................................................. - 41 4.2 Vypracování analýzy - proces poskytování úvěrů (úroveň 1)...................................... - 42 4.2.1 Hlavní rozdělení procesů .............................................................................................. - 42 4.3 Proces poskytování úvěrů (úroveň 2) .............................................................................. - 42 4.3.1 Vyhledání produktu....................................................................................................... - 42 4.3.2 Vyplnění žádanky .......................................................................................................... - 43 4.3.3 Schválení žádosti - scoring ........................................................................................... - 44 4.3.4 Dokončení smlouvy s klientem .................................................................................... - 45 4.3.5 Vytvoření soupisů ........................................................................................................... - 46 4.3.6 Zpracování smluv na Guarantee company ............................................................ - 47 4.3.7 Zpracování smluv na HCI ............................................................................................. - 48 4.3.8 Zpracování smluv v Bance........................................................................................... - 49 4.3.9 Kompletace smluv......................................................................................................... - 50 -

-4-

4.3.10 Pohyb originálu .......................................................................................................... - 51 4.3.11 Komunikace s bankou.............................................................................................. - 52 4.3.12 Příprava bankovních účtů ....................................................................................... - 53 4.3.13 Pay In ........................................................................................................................... - 54 4.3.13.1 HCI zkontroloval splátkový kalendář (úroveň 3) .................................................... - 55 4.3.14 Provedení plateb obchodníkovi ............................................................................ - 56 4.3.15 Předčasné splacení .................................................................................................. - 57 5 Diskuse a závěr ...................................................................................................................... - 58 Seznam použité literatury .............................................................................................................. - 60 -

-5-

POUŽITÉ TERMÍNY RUP(Rational Unified process)

Procesní rámec a metodika vývoje software. Dále pouze RUP.

Rational Objectory process

Je

metodika

vývoje

software

založená

plně

na principech UML. Datové modelování

Technika využívající nástroje popisující data cílového systému

za

účelem

jeho

zkoumání

před

jeho

vytvořením. Business modelování

Business modelování je množina metod, přístupů a nástrojů

používaných

ke

specifikaci

a analýze

řízením

a správou

podnikových (business) procesů. Configuration managementu

Disciplína,

která

se

zabývá

konfiguračních položek. Tedy prvků, které mohou být popsány vlastnostmi a jsou součástí informačního systému. Use Case

Případ užití, popis části funkcionality informačního systému.

UML(Unified Modeling Language) Pilotní verze aplikace

Je jazyk, který umožňuje modelovat jednoduché i složité aplikace pomocí stejné formální syntaxe. Verze aplikace, která je určena k testování koncovými uživateli.

Inkrementální

Přírůstkový, postupný.

Risk management

Je manažerskou činností, která zahrnuje a integruje rozpoznání rizika, ohodnocení rizika, vyvíjení strategií k řízení

rizika

a zmírnění

manažerských prostředků.

-6-

rizika

používáním

IBM Rational Method Composer

Je nástroj založený na platformě Eclipse, který umožní velmi

jednoduše

vytvářet,

upravovat

a využívat

existující procesy, tyto procesy publikovat a ve spolupráci s dalšími nástroji i automatizovat. AUP(Agile Unified Process)

Zjednodušená varianta RUP.

EUP(Enterprise Unified

Je rozšířená verze RUP.

Prosess) Stakeholder

Je jakákoliv osoba, která může jakkoliv ovlivnit obchodní

proces

(ředitel,

manažer,

dodavatel,

odběratel, účetní, zákazník,…,…). ROI(Return Of Investment)

Je zkratka z anglického Return On Investments, tedy návratnost investic.

Enterprise Architect

Nástroj vyvinutý společností Sparg Systems určený pro datové modelování.

-7-

Úvod, cíl práce

1

ÚVOD, CÍL PRÁCE

1.1 Úvod Dnešní společnost ve vyspělých zemích se nachází v informačním věku. Mnoho podniků využívá informační systémy, jako podpůrný nástroj svých obchodních aktivit. Některé mají své aktivity na informačních technologiích přímo založeny. Robustnost a složitost těchto systémů se stále zvětšuje. Stoupá také množství pracovníků, kteří jsou zapojeni do vývoje informačního systému, roste více používaných technologií. S náročnějšími systémy jsou nasazovány různé metodiky vývoje software, které tento proces ulehčují. Jednou, z kladně vnímaných a univerzálních, je také metodika RUP. Není pouze metodikou, ale především procesním rámcem. Zachycuje vazby mezi hlavními, řídícími a podpůrnými procesy. Firma, ve které nově pracuji jako analytik, tuto metodiku využívá. Disciplína Business analýzy, dle RUP, nebyla zatím u mnoha projektů aplikována, přestože by pro ně mohla být přínosem. V nedávné době jsem byl přiřazen na rozsáhlý projekt, kde byl použit tento procesní rámec. Hlavním důvodem ke zpracování tohoto tématu byla potřeba vytvoření analýzy, pro snazší komunikaci se zákazníkem. Dalším důvodkem vzniku byla plánovaná optimalizace stávajících procesů, při které měla být tato analýza také použita.

1.2 Cíl práce Cílem práce je tedy vyhotovení Business analýzy, která bude vytvořena dle principů metodiky RUP a založena na obecných zásadách business modelování. Bude popisovat reálné procesy konkrétního zákazníka, který působí na českém trhu v oblasti úvěrových produktů. Procesní analýza, jako nejzákladnější prvek Business analýzy [Per Kroll, Philippe Kruchten, 2003] a logický popis entit v podobě doménového modelu budou tvořit hlavní části této analýzy. Tyto dva prvky nejlépe popisují funkční a statickou strukturu popisované reality. Jedním, ze smyslů práce je také ukázat velikou důležitost analytické fáze v procesu vývoje software a její praktické využití v iterativních metodikách, za kterou je považována i RUP. Součástí je také popsání principů této metodiky. Je velmi obtížné vyhotovit a publikovat analytické modely bez silného nástroje, který by s vytvářením výstupů pomohl. Pro komunikaci se zákazníkem je také nezbytné, aby výstupy byly dobře čitelné a zákazník jim rozuměl. Celá analýza bude vytvořena za pomoci nástroje datového modelování, Enterprise Architect, od společnosti Sparx Systems. -8-

Metodika RUP

2

METODIKA RUP

2.1 Historické milníky vzniku metodiky RUP V celé práci vycházím z metodiky RUP, a proto zde nastíním její vývoj. Tento propracovaný procesní rámec nevznikl najednou. Předcházely mu roky sbírání poznatků a také postupný proces zdokonalování. Odráží zkušenosti mnoha odborníků a společností. Dnes tvoří aktivum mezinárodní společnosti IBM. Pokud půjdeme v čase zpět, zjistíme, že RUP (Rational Unified Process) je přímým nástupcem Rational Objectory Process. RUP na sebe však časem nabaloval mnohé jiné metodiky a disciplíny a proto je mnohem obsáhlejší. Z těch, které jsou v metodice RUP navíc zahrnuty, mohu jmenovat tvorbu Use Case, business analýzu, projektový management a Configuration management. [Kruchten,1999] V roce 1997 byla spojena společnost Rational Software a Pure-Atria a tím bylo zajištěno, že výše uvedené disciplíny byly převedeny pod metodiku RUP. V průběhu dalších let docházelo k dalším fůzím společnosti Rational s jinými a vždy to mělo dopad na rozšíření metodiky o nové disciplíny a poznatky, které přišli z nově připojených společností. Například od společnosti Objectory AB, byla převzata procesní struktura a klíčové pojetí Use Case a vše bylo zahrnuto do nové varianty metodiky. V této verzi se také objevuje oblast sběru požadavků, která byla převzata ze společnosti Requisite, Inc. Další mohu jmenovat společnost SQA, Inc., od které byl převzat detailní proces testování. Všechny výše zmíněné společnosti se spojili s Rational Software. V roce 2003 byla koupena gigantem na trhu informačních technologií, společností IBM. [Kruchten, 1999] Rád bych uvedl zajímavou skutečnost, že Rational Software byla první společností, která používala tehdy nově vytvořený jazyk UML (Unified Modeling Language), který se stal téměř univerzálním jazykem pro oblast datového modelování. Pokud se vrátíme na samý počátek vzniku RUP, zjistíme, že Objectory Process byl vytvořen ve Švédsku v roce 1987 Ivarem Jacobsonem. Byl výsledkem zkušeností jeho práce v telefonní společnosti Ericsson a vytvořen spojením objektově orientovaných modelovacích metod s metodou tvorby a použití Use Case. Tento koncept vývoje software si velmi rychle získal uznání v softwarovém průmyslu a byl přijat a integrován mnoha společnostmi na celém světě. Dnes je považován za jeden ze standardů. [Jacobson, 1999]

-9-

Metodika RUP IBM Rational Unified process

2003

Rational Unified process 2000

2000

Web Based development

Rational Unified process 5.5

1999

Busuness Engenieering Data modeling

1998

Rational Unified process 5.0

1997

Rational Objectory process 4.1

Configuration a Change Management UI DESIGN

OMT

Rational Objectory process 4.0

1996

1995

SQA

Rational Approach

UML

Objectory Porcess

Obr č.1-1. - Vývoj Rational Unified Process [Jacobson, 1999]

2.2 Co lze u RUP využít? Pokud budete pracovat ve společnosti, která vyvíjí aplikace založené na jedné platformě a počet programátorů nepřesáhne 15, nemusíte, zajisté, žádnou metodiku využívat. Jiná je však situace, kdy budete vyvíjet aplikace pro významné společnosti, vývojový tým se rozroste a vývoj již bude těžko zvladatelný. Bez nějaké propracované metodiky nebude využití lidských zdrojů efektivní. U velkých zákazníků se navíc musíte zaručit postupováním dle standardních metodik, jinak nejste konkurenceschopní.

- 10 -

Metodika RUP RUP se stal faktickým průmyslovým standardem pro proces vývoje software. Metodika je tak obsáhlá, že ji drtivá většina firem, které se zabývají vývojem software, nemůže využít v celé její šíři. Jak jsem již uvedl, je založena na nejlepších praktikách, které byly sbírány mnoho let a obsahují zkušenosti z velkého počtu projektů. Od svého vzniku byla tato metodika úspěšně aplikována v mnoha organizacích na většině vývojových platformách, které se dnes používají. Společnost Logos, ve které pracuji, tuto metodiku také úspěšně využívá. RUP jako procesní rámec vývoje software může být přizpůsoben tak, aby vyhovoval specifickým potřebám každé společnosti a každého projektu. Tuto metodiku není nutné využívat jako celek. Lze z ní vyjmout pouze oblasti, které jsou vhodné u daného projektu použít. Je velmi univerzální. Pokud přijdete na oblast, která není v metodice popsána, zpracujete chybějící proces tak, aby zapadal do procesního rámce RUP, a již jej můžete sdílet s jinými společnostmi, jako součást metodiky RUP a nadále jej využívat. Tento rys je zřejmý z procesu vývoje, jak je uveden v kapitole 2.1. Do původního procesního rámce byly přidávány různé technologie a oblasti podle definovaných pravidel. Z tohoto ovšem vyplývá, že existuje více verzí metodiky RUP. Všechny však mají společný základ. [Bergstrom, Stefan, Raberg, Lotta, 2004] Klasické metodiky používaly tzv. vodopádový přístup. Nejprve se vytvořilo celé zadání, poté se vyhotovila analýza. Po kompletní analýze následoval vývoj a nakonec se celý proces ukončil testováním a předáním aplikace do provozu. Ukazovalo se, že mnoho projektů však nebylo úspěšných. To mělo více důvodů. Například projekt trval tak dlouho, že při předání do provozu byl již poplatný době. Zákazník dostal do rukou aplikaci, která byla vyvíjena dlouhou dobu, což bylo nákladné, a on až po dlouhé době zjistil, že výsledná aplikace nesplňuje očekávání a je pro něj již nevyužitelná. Vše bylo způsobeno změnou okolních podmínek, což nelze ovlivnit. Tyto problémy byly odstraněny iterativním a inkrementálním přístupem, který také využívá RUP. Tento přístup má několik výhod, které bych rád uvedl.

- 11 -

Metodika RUP [Ambler, Nalbone, Vizdos, 2005]

Zvýšená kontrola ze strany zadavatele. Zadavatel má v rané fázi tvorby software možnost zkontrolovat, zda dosavadní práce na aplikaci splňuje očekávání. Po každé iteraci následuje zhodnocení stavu a po každé fázi jsou hodnocena předem definovaná akceptační kritéria. V případě neočekávaných výsledků, může být změněno zadání s relativně malými náklady. V každé iteraci se dále zjišťuje, zda dosavadní produkt splňuje předpoklady a očekávání a v případě, že nikoliv, jsou nové iterace přeplánovány tak, aby výsledný produkt již splnil představy Zadavatele.

Investoři dostávají pravidelnou zpětnou vazbu. Iterativní metoda umožňuje investorům vidět a komentovat částečně vyvinutý software velmi brzy po zahájení vývojových prací a tím se ujistit, že dostanou produkt, který skutečně požadují. V případě vodopádového přístupu by výsledný produkt viděli až po závěrečném testování a případnou změnu by nebylo již možné zapracovat. V iterativním přístupu mohou investoři zasáhnout v rané fázi vývoje Software do tohoto procesu a popřípadě opět změnit „kurz“ bez pozdějších zbytečných nákladů navíc, jak by tomu bylo opět u vodopádového přístupu.

Zkvalitnění risk managementu. Inkrementální přístup umožňuje rozpoznat rizika dříve, protože si může Zákazník produkt dříve vyzkoušet. Na otázku, zda produkt splňuje požadavky, si opět můžeme odpovědět v jedné z prvních iterací. Oblast vývoje software je velmi dynamický obor a nezřídka se stává, že v době uvedení produktu na trh je již překonán konkurencí.

Implementují se aktuální požadavky. Změna je u velkých a dlouhých projektů nevyhnutelná. Čekat, že jednou definované požadavky budou stejně vyhovovat i na konci projektu je milné a nerealistické. Je velmi těžké navrhnout celou aplikaci, poté ji naprogramovat tak, aby vyhovovala, v době dokončení, představě zadavatele. Ta se v čase mění. Pokud je vyvíjen systém v menších iteracích, můžeme reagovat na aktuální, měnící se potřeby zadavatele. Místo toho, abychom reagovaly na potřeby, které byly zdokumentovány měsíce a roky dopředu. Další výhodou u měnících se požadavků uvnitř iterací je, že je snadnější se jimi zabývat, protože rozsah požadavků pro každou iteraci je menší.

- 12 -

Metodika RUP

Ověření funkčnosti navržené architektury. Jedním z cílů fáze Elaborace, jak o ni budu pojednávat později, je ujištění, že navržená architektura systému pracuje správně. Architektura, jež je vytvořená na papíře, pracuje vždy bezchybně. V praxi se pak ukáže, že nefunguje přesně dle požadavků nebo nefunguje vůbec. Vyvinutím kostry systému během fáze Elaborace, snížíte významně technická rizika vašeho projektu. Iteračním způsobem vývoje software můžete pravidelně zjišťovat, zda architektura a design systému vyhovuje stále potřebám zadavatele.

Zaměření programátora na vývoj.

Pokud je RUP používán účinně,

programátoři brzy zjistí, že nemusí utrácet čas opakovaným modelováním, přepisováním dokumentace a čekáním na úplné zadání. Místo toho se mohou věnovat v jednotlivých iteracích psaní kódu. Mnohdy se s tradičními přístupy stávalo, že vývojář ani po mnoha měsících nenapsal jediný řádek kódu. Stále upřesňoval analýzu dle měnícího se okolí. To ho samozřejmě demotivovalo.

2.3 RUP, jeho modifikace a podpůrné nástroje RUP není pouze procesem vývoje systémů, ale také rámec pro procesní vývoj systémů. Toto znamená, že je to samostatná struktura, ze které je tento proces vytvořen. Jinak řečeno, je celý definován sám ze sebe. Lze také upravit a přizpůsobit podle potřeb každého projektu. [Rational Method Composer, 2006] Společnost IBM se nadále podílí na vývoji RUP. Investuje do tohoto produktu nemalé prostředky. Neustále jej rozšiřuje a zpřesňuje. Jak již jsem uvedl výše. RUP je velmi obsáhlým zdrojem informací, šablon, postupů, metod, atp. Obsahuje role včetně jejich popisu, směrnice i popis aktivit. Všechny tyto dokumenty jsou konzistentní a vzájemně propojené. Ve zkratce je to velmi obsáhlý zdroj „Know-How“ z oblasti vývoje software. Další výhodou RUP je jeho velká oblíbenost v IT průmyslu. Mnoho lidí jej zná a používá ho. Pro ty, kteří se s metodikou RUP chtějí teprve seznámit, je to snadnější, protože existují dostupné zdroje, které jsou však velmi drahé. Jak lze očekávat společnost IBM podporuje a vyvíjí také nástroje pro implementaci RUP. Jmenovat mohu například „RMC“ (Rational Method Composer) nebo „Eclipse Process Framework“. Tyto nástroje, právě proto, že je RUP tak obsáhlý, pomáhají využít jeho potenciál. - 13 -

Metodika RUP Dnes existují dvě veřejně publikované modifikace metodiky RUP. Jsou to AUP (The Agile Unified Process) a EUP (The Enterprise Unified Process). [Ambler, Nalbone, Vizdos, 2005] EUP je globální metodikou, je tedy zaměřena na budování informačního systému na úrovni celé organizace, což umožňuje postihnout takové procesy jako řízení portfolia projektů, znovu-použitelnosti na úrovni celé organizace, vytváření globální architektury apod. Rozšiřuje metodiku RUP ve dvou směrech. První směr, jak jsem již uvedl, představuje rozšíření na úroveň celé organizace. Definuje také novou disciplínu – Infrastructure Management, která zahrnuje procesy realizované pomocí projektového řízení. Druhý směr rozšíření metodiky RUP, představuje připojení fází Production, jejíž náplní je provoz a údržba systému a Retirement, která popisuje činnosti nutné při odstranění produktu z provozu. EUP, stejně jako RUP, zůstává zaměřen pouze na objektově orientovaný vývoj. AUP - je zjednodušená verze RUP.

Popisuje jednoduchý a snadný postup, při vývoji

software, za pomocí agilních technik. Jsou jimi například TDD(Test Driven Development, AMDD(Agile Model Driven Development), ACM(Agile Change Management). [Ambler, Nalbone, Vizdos, 2005]

2.4 Fáze Rupu – životní cyklus V této kapitole stručně shrnu jednotlivé fáze životního cyklu vývoje software. 2.4.1 Příprava projektu Před každým projektem je důležité se na něj připravit. V této fázi se budu zabývat aktivitami, které jsou důležité ještě před zahájením projektu. Mezi ty hlavní můžeme zahrnout:

Modelování podnikové architektury. Je nutné analyzovat a popsat stávající podnikovou architekturu informačních systémů. Tento krok je důležitý při případném propojování budoucí architektury se stávající podnikovou.

Vytvoření Podnikového Business modelu.

Vytvoření modelu je důležité

především při formulování obsahu projektu. Podrobněji se tímto tématem zabývám níže v kapitole 3, Business analýza.

Plánování portfolia. Tato aktivita zahrnuje identifikaci potenciálních propojených projektů a určení zdrojů a prostředků, které každý projekt může využít.

- 14 -

Metodika RUP

Identifikace aktiv, která lze využít také u jiných projektů.

Ideálně by

projektové týmy měly umět nahlížet do ostatních projektů a opětovně využívat již získaná aktiva.

Přiřazení lidských zdrojů. Někdy je potřeba některé pracovníky před začátkem projektu najmout, zaměstnat nebo proškolit.

Obr č.1-2. Fáze a disciplíny RUP[Rational Method Composer, 2006]

- 15 -

Metodika RUP

2.4.2 Zahájení Primárním cílem fáze zahájení je dosažení shody s investorem s ohledem na cíle projektu a dohodnutí finančních a jiných nákladů. K tomu, aby bylo možno dosáhnout shody, musí být vytvořen velmi kvalitní model požadavků, který ohraničí rozsah projektu. Velmi často se v této fázi vytváří Business analýza, která popisuje budoucí, cílový stav, jak o tom pojednávám v kapitole 3. U některých projektů je dobré vytvořit též prototyp uživatelského rozhranní. V této fázi je dále potřeba nainstalovat vývojové prostředí, vybrat a upravit procesy RUP tak, aby vyhovovaly zvolenému vývojovému týmu a projektu. Je dále vytvořen podrobný plán projektu. Fáze zahájení je ukončena milníkem, který se nazývá LCO (Lifecycle Objectives), kde Investoři zhodnotí dosavadní stav projektu. Musí se dohodnout především na:

rozsahu projektu,

základních požadavcích systému. Bez velké míry detailu.

Reálném vývojovém plánu,

rizicích, která budou přiměřeně řízena,

dalším pokračování projektu. Smysl vzniku aplikace dále trvá.

Procesu vývoje, který je přiměřeně přizpůsoben danému projektu. [Rational Method Composer, 2006]

2.4.3 Příprava Důležitým cílem fáze Přípravy je upřesnění požadavků. Jsou rozpracovávány s vyšší mírou detailu a je zde nastíněna architektura systému. Během této fáze jsou požadavky převedeny do podoby konkrétnější formy systémových Use-Case a doplňkových požadavků. Jsou to například business pravidla a specifické technické požadavky. Zdůrazňuji, že požadavky jsou zde dopracovány pouze do takové míry detailu, aby to postačovalo na vypracování celkového návrhu architektury systému. Hlavním požadavkem na tuto fázi je tedy navržení architektury. Má za úkol odpovědět na otázku, zda je systém zhotovitelný v mezích nákladů, které byly stanoveny. Jsou definována a ohodnocena všechna rizika, která vyplývají z návrhu architektury. Tyto rizika mohou mít několik důsledků: nalezení podobného systému, vytvoření samostatného testovacího prostředí, vytvoření pracovního prototypu systému. Návrh architektury nového systému by měl být v souladu s dosavadní architekturou v podniku.

- 16 -

Metodika RUP Během fáze Přípravy se vývojový tým také připravuje na etapu Konstrukce. Vytváří plány a připravuje zdroje. Fáze Přípravy je ukončena milníkem, který se nazývá LCO (lifecycle Objectives). Zadavatelé a dodavatelé řešení v něm zhodnotí dosavadní stav projektu. Musí se shodnout především na těchto bodech.

Existuje stabilní vize. Vize projektu je stabilizována a je reálná.

Stabilita

požadavků.

Všechny

důležité

požadavky

na

systém

jsou

„Stakeholderům“ jasné a souhlasí s nimi. Tyto požadavky se však mohou v budoucích fázích ještě rozvinout, nebo částečně pozměnit.

Stabilita architektury. Je jasné, jak je navržena architektura, že je navržena stabilně a splňuje definované požadavky. Jsou známá a ohodnocená rizika. Byl popřípadě vytvořen prototyp.

Rizika jsou přijata. Všechna významná rizika byla nalezena, ohodnocena. Dále je zajištěno, že jsou zdokumentována a jsou přijatelná pro zvolenou strategii.

Akceptovatelná cena. Současné výdaje jsou přijatelné a rozumné. Jsou vytvořeny budoucí odhady nákladů a plány výdajů.

Šance uspět. Investoři jsou přesvědčeni, že zvolené cíle jsou měřitelné, reálné, přínosné pro podnikání a mohou být dosaženy dle definovaných plánů a s navrženou architekturou.

Plán projektu. Existuje plán projektu na další fázi.

V případě, že se Zadavatelé shodnou na výše uvedených bodech, může se projekt překlopit do etapy vývoje. Jestliže projekt nesplňuje aspoň jeden z výše uvedených bodů, musí být doplněn, směr projektu upraven, nebo projekt zrušen. [Rational Method Composer, 2006] 2.4.4 Konstrukce Hlavní smysl etapy Konstrukce je dotažení vývoje systému do bodu, kdy je připraven k nasazení u zákazníka. Důraz je posunut na ukončení specifikace požadavků, jejich analýzu a návrh jejich řešení. V této fázi dále dochází k vývoji a testování software. Pokud je to vhodné, doporučuje se v této fázi nasadit první prototyp aplikace a získat zpětnou reakci od uživatelů. Před úplným ukončením této fáze je nutné opět vytvořit a schválit dokument, ve kterém opět investoři zhodnotí stav projektu. Jmenuje se Initial Operational Capability (IOC) a jeho součástí je souhlas investorů s: - 17 -

Metodika RUP

vyvinutým

software

a doprovodnou

dokumentací,

která

je

kompletní

a připravena,

se skutečností, že uživatelé jsou připraveni na nasazení systému,

riziky, která jsou přijatelně řízena,

dosavadními výdaji, které jsou stále přijatelné a vyvážené a odhady se shodují s realitou,

plány na další fázi projektu. [Rational Method Composer, 2006]

2.4.5 Předání Fáze Předání se zaměřuje na uvedení systému do produkce a na jeho konečné předání Zadavateli. V této fázi probíhá intenzivní testování kvality. Jednak stranou dodavatele řešení a dále stranou zadavatele. Intenzivně se opravují chyby a dochází k ladění systému. V této fázi dochází ke školení koncových uživatelů a pracovníků, kteří pracují na podpoře a provozu produktu. Předtím, než je ukončena fáze předání, musí být investory odsouhlasen dokument s názvem PR (Product Release). V tomto dokumentu jsou zakotveny tyto body:

Systém, včetně dokumentace je připraven k nasazení a převzetí zadavatelem, pracovníci jsou proškoleni.

Dosavadní výdaje jsou přijatelné a podle plánu a existuje přijatelná kalkulace nákladů na další etapy.

Systém je provozuschopný

Systém lze spravovat s obvyklými náklady. [Rational Method Composer, 2006]

2.5 Hlavní disciplíny RUP Jak již je patrné z hlavního diagramu metodiky RUP, vedle vývojového cyklu jsou definovány jednotlivé disciplíny, které jsou, jinou měrou, zastoupeny ve všech fázích cyklu. Níže se s nimi seznámíme podrobněji.

- 18 -

Metodika RUP 2.5.1 Tvorba podnikového modelu Cílem této disciplíny je porozumět, jak funguje daná organizace, jaké jsou vazby této organizace na okolí. Jaké jsou činnosti, které zastává a jejich vazby na informační systém, který má být vyvinut. Cílem je pracovat v těsném kontaktu se zadavatelem, který je schopen předat podrobné informace potřebné pro vytvoření Business modelu podniku. Podrobněji je tato problematika popsána v kapitole 3., Business analýza. Níže uvádím výčet nejčastějších činností, které se objevují v této disciplíně.

Zhodnocení aktuálního stavu organizace.

Zkoumání aktuálních obchodních procesů, příležitostí pro podnik, rolí a požadavků.

Definování a zhodnocení potenciálních strategií a cílů a vizí.

Vytvoření potřebných modelů (především procesní a doménový), které odráží činnosti podnikání. [Bergstrom, Stefan, Raberg, Lotta, 2004]

2.5.2 Správa požadavků Cílem této disciplíny je vytvořit dokument s požadavky a shodnout se s investorem na obsahu a rozsahu toho, co je poptáváno. Tento dokument je využíván analytiky, návrháři a programátory, kteří dle něho vytváří systém. Testeři dle požadavků systém testují. Vedoucí projektu, dle požadavků, řídí a plánují projekt. Činnosti, které jsou zastoupeny v této disciplíně, zahrnují především:

Porozumění požadavkům zadavatele na systém. Velmi často je potřebný velmi blízký a častý kontakt Dodavatele se „Stakeholdery“.

Stanovení rozsahu systému.

Prozkoumání obchodních pravidel, uživatelského rozhraní, a technických požadavků. Velmi důležité je zdokumentování požadavků a jejich analýza prostřednictvím modelovacích technik.

- 19 -

Metodika RUP Tato disciplína poskytuje podklady pro vytvoření obsahu jednotlivých iterací, odhadu ceny a času potřebného na vývoj systému. Je zapotřebí nejprve identifikovat všechny osoby a zákazníky, které mají relevantní informace a tyto informace získat. Je velmi důležité rozpoznat rozdíl mezi požadavkem a potřebou uživatele. Ti nejsou většinou schopni popsat své potřeby, ale zaměřují se pouze na požadavky. Závisí na zkušenostech analytika, jak dokáže odhalit skutečné potřeby uživatelů a investorů. [Bergstrom, Stefan, Raberg, Lotta, 2004] 2.5.3 Analýza a návrh V této disciplíně se především analyzují požadavky na systém a navrhuje řešení, které by realizovalo požadavky. V úvahu se musí vzít různá omezení, směrnice a standardy. Účelem této disciplíny je přetvoření požadavků na funkční systém a definice dobře fungující architektury. Dále je to přizpůsobení návrhu systému tak, aby vyhovoval prostředí realizace. Velký důraz je kladen na optimalizaci systému. Architekt systému musí navrhnout a definovat jak bude vypadat a fungovat celková infrastruktura, sítě, jak bude systém nakonfigurován, jak bude celý systém infrastruktury monitorován a spravován. Architekt musí vzít také v úvahu například referenční architektury nebo technické požadavky a směrnice. Činnosti této disciplíny zahrnují:

definici prvků architektury,

porozumění požadavkům na systém,

definici návrhu architektury,

porozumění omezením, která ovlivňují systém,

nákup, instalaci nebo konfiguraci služeb, síťových prvků, sítí, uživatelského rozhraní, databází, atd. [Bergstrom, Stefan, Raberg, Lotta, 2004]

2.5.4 Implementace Cílem je úspěšně transformovat návrh do spustitelného kódu a provést úspěšné testování. Primární aktivity zahrnují tyto činnosti:

Porozumět architektuře a návrhu systému.

Psát zdrojový kód. - 20 -

Metodika RUP

Vytvářet komponenty, služby a moduly systému.

Vytvářet testovací scénáře a psát testovací skripty.

Vytvářet softwarové spustitelné balíčky.

Účelem je, aby existovaly otestované spustitelné části, jako jsou spustitelné programy, binární soubory, zdrojové soubory a jiné a aby byly tyto komponenty začleněny do spustitelného systému. [Bergstrom, Stefan, Raberg, Lotta, 2004] 2.5.5 Testování Testování je objektivním hodnocením, které popisuje kvalitu systému. Má za úkol najít vady v aplikaci, potvrdit, že systém pracuje podle požadavků a podle návrhu. Týmy, které se zabývají kvalitou, jsou většinou organizačně odděleny od vývojového týmu. To je z důvodu udržení objektivity testerů. Hlavními činnostmi jsou:

Definice testovacích plánů.

Vytvoření testovacích skriptů.

Řízení testování.

Vykonávání testů.

Vyhodnocování a reportování výsledků. [Bergstrom, Stefan, Raberg, Lotta, 2004]

Tato disciplína je brána tak, že poskytuje službu ostatním disciplínám a je na nich nezávislá. Hlavními cíly testování je zhodnotit kvalitu produktu. K tomu je zapotřebí najít a zdokumentovat vady v systému. Těch může být velké množství druhů a mohou se objevit pouze, pokud nastanou určité okolnosti. Přijít na všechny okolnosti, které podmiňují vznik chyby, je náročný úkol. Úkolem testera je také být rádcem a pomocníkem při definici kvality systému, potvrzení, či vyvrácení předpokladů učiněných ve fázi návrhu. Nebo potvrzení, že požadavky jsou realizovány přiměřeně. Informace předložené v různých průzkumech a esejích říkají, že náklady na testování softwaru se pohybují od 30 do 50 procent nákladů na jeho vývoj. [Ambler, Nalbone, Vizdos, 2005] Většina lidí se přesto domnívá, software není dostatečně testován před předáním do provozu.

- 21 -

Metodika RUP Tato skutečnost je zakořeněna v několika klíčových záležitostech. Testování je velmi obtížná disciplína. Někdy jde pouze se štěstím přijít na všechny způsoby, jakým bude uživatel s programem pracovat. Exaktně nelze všechny způsoby vypočítat. Typické testování je prováděno bez jasné metodologie. Úspěch je řízen kvalitou jednotlivých testerů. Nástroje, které mají urychlit a podpořit testování nejsou dostatečně využívány. Tento fakt dělá testování namáhavé. Bez automatizace a podpůrných testovacích nástrojů se velké systémy řídí jen obtížně. Složitost softwaru dělat z kompletního testování nemožný cíl. RUP v tomto může, od verze 4.1, velmi pomoci. Vysoce kvalitní software je nezbytný například pro oblast kontroly leteckého provozu, řízení raket nebo lékařských systémů. Kritičnost typického informačního systému nemusí být na první pohled zřejmá. Dopad chyby však může mít za následek značné finanční ztráty. V dnešní době se zvyšují požadavky na dodávku služeb. Velmi častá je dodávka přes internet. Velké množství informačních systémů je považováno za „mission-critical“. Ve chvíli, kdy nemohou uživatelé využít plně funkcionalitu tohoto systému, dochází k obrovským finančním ztrátám. Příkladem může být internetový obchod. Nepřetržitá kontrola kvality a její brzké zahájení v cyklu vývoje Software má za následek možné snížení konečné ceny a hlavně buduje dobrou pověst o systému a tím zvyšuje konkurenční výhodu. 2.5.6 Nasazení Cílem je naplánovat dodávku systému a naplánovat zpřístupnění systému koncovým uživatelům a vše také realizovat. Klíčové aktivity jsou:

Vytvoření plánu nasazení systému do provozu.

Vytvoření podkladů pro pracovníky podpory a provozu produktu.

Vytvoření instalačních balíčků

Organizování tzv. Alpha/Beta/pilotního testování.

Publikování software.

Zaškolení koncových uživatelů.

Řízení akceptačních testů.

V metodice Rup jsou popsány tři způsoby publikace produktu. Jsou to:

klasická instalace produktu na místě,

nabídka komprimované verze produktu a - 22 -

Metodika RUP

instalace dostupná přes internet. [Bergstrom, Stefan, Raberg, Lotta, 2004]

2.6 Podpůrné disciplíny RUP 2.6.1 Řízení projektu Cílem je řízení a usměrňování aktivit, které se vyskytují v průběhu projektu. Tato disciplína zahrnuje řízení rizik, řízení lidských zdrojů (přiřazení úkolů, sledování vývoje projektu, atd.) a koordinace činností s okolím tak, aby bylo zajištěno, že bude projekt dokončen včas a za předem definovanou cenu nebo levněji. Je zde využit tzv. projektový „troj-imperativ“. To znamená, že je projekt ovlivněn lidskými zdroji, finančními prostředky a časem. Pokud ubereme u projektu jeden zdroj, znamená to, že musíme přidat další, abychom splnili požadavky na projekt, nebo se musí realizace projektu posunout v čase dozadu. Klíčové aktivity jsou:

Zahájení nového projektu.

Řízení lidí, kteří jsou zapojeni do projektu.

Zlepšení vazeb s externími týmy a zdroji.

Management rizik.

Odhady a plánování.

Řízení iterací.

Uzavírání jednotlivých fází a projektů. [Rational Method Composer, 2006]

2.6.2 Řízení změn a konfigurace Cílem je řídit požadavky na změny v rámci projektu. Říká se, že jediná jistota v projektu je, že nastane nějaká změna. Tato disciplína nemá za cíl pouze určovat a monitorovat jednotlivé verze softwaru, ale především řídit, schvalovat a kontrolovat jednotlivé změny a jejich dopady na systém. Mezi hlavní aktivity patří:

Řízení změnových požadavků.

Plánování konfiguračních kontrol.

Nastavení procesu změn požadavků.

Monitorování a reportování o stavu konfigurace. - 23 -

Metodika RUP

Změna a instalace konfiguračních položek.

Řízení nasazení balíčků (release).

2.6.3 Správa prostředí Hlavním cílem je naplánování nasazení a zprovoznění systému tak, aby byl plně přístupný pro koncové uživatele. Aktivity jsou:

Plánovaní strategie nasazení

Vytvoření dokumentace potřebné pro nasazení

Vytvoření instalačních balíčků

Organizování alfa/beta/pilot testování

Publikovat software

Zaškolení koncových uživatelů

Řízení akceptačních testů [Rational Method Composer, 2006]

2.7 Šest praktik Metodika RUP definuje 6 základních obecných praktik, které se používají při vývoji software. Vedou k jednoduššímu řízení kvality a k dosažení lepších výsledků. 2.7.1 Vizuální modelování. Grafické znázornění systému a jeho chování, zpřehledňuje návrh a umožňuje udržet konzistenci mezi modelem a vlastní implementací. Používá se standardní modelovací jazyk (UML). Napomáhá zjednodušení komunikace uvnitř týmu, zlepšení konzistence projektu, zvýšení pravděpodobnosti správného uchopení systému. Při modelování systému jsou používány aplikace, které převedou model na spustitelný kód. Je to například Rational Rose nebo Power Designer. [IBM Software development Conference, 2006]

- 24 -

Metodika RUP 2.7.2 Správa a řízení požadavků Každý projekt, zaměřený na vývoj software, má množství různých „Stakeholderů“ – koncové uživatele, management obchodu, systémové inženýry, kteří mají na starost provoz systému, externí zákazníky, atd. Každý z nich má rozdílné očekávání od budoucího systému a jiné potřeby a priority. Jedna z nejtěžších činností je vyvážení priorit požadavků. U projektů, kde se investoři aktivně podílí na definici požadavků na koncový produkt, dochází mnohem častěji k naplnění skutečných cílů investorů. 2.7.3 Komponentová architektura Rup podporuje komponentové architektury typu CORBA a COM. Je-li vyvíjený systém otevřený k použití jiných komponent, může být vývoj efektivnější. Znovupoužití hotové komponenty znamená podstatnou úsporu zdrojů. RUP poskytuje metodickou, systematickou cestu návrhu, vývoje a ověření správnosti architektury. Nabízí šablony, architektonické styly a pravidla designu. [IBM Software development Conference, 2006] 2.7.4 Iterativní vývoj. Hlavní myšlenkou je, že se snažíte vyvíjet Software v iteracích. U rozsáhlých systémů není již možné na začátku přesně definovat celý problém, navrhnout řešení, provést implementaci a až na závěr celý systém otestovat. Iterativní vývoj má za důsledek intenzivnější zpětnou vazbu s investorem a funkční software v rané fázi projektu. Investor si tak může velmi rychle “osahat ” systém a poskytnout velmi rychle a pravidelně zpětnou vazbu. Tato praktika spočívá v rozdělení celého projektu na čtyři fáze, z nichž každá se skládá z několika iterací. Výsledkem každé této iterace je spustitelná verze software. Další výhodou je, že se vyvíjí menší části systému. Dále se v brzké fázi projektu může vyzkoušet jak je navržena architektura systému a zda pracuje dle požadavků a předpokladů. [IBM Software development Conference, 2006] 2.7.5 Řízení změn Říká se, že pokud se naučíme řídit změnu, je každá změna pro nás přijatelná a že jediná jistota u projektu je, že přijde změna. V této praktice je popsáno, jak se efektivně připravit na změnu a uřídit ji. [IBM Software development Conference, 2006]

- 25 -

Metodika RUP 2.7.6

Průběžné ověřování kvality

Ve vývojových firmách je většinou vyčleněn tým, který zajišťuje dodržování kvality produktu. Softwarový produkt lze předat do provozu pouze v případě, že splňuje požadovaná kvalitativní kritéria. Mezi ty hlavní patří spolehlivost, funkcionalita a výkon. Tento tým, za pomocí testování ověřuje, zda má produkt požadovanou kvalitu. [IBM Software development Conference, 2006]

- 26 -

Business analýza

3

BUSINESS ANALÝZA

Hlavním cílem analýzy je porozumění hlavním problémům organizace a nalezení možností, jak zvýšit její obchodní potenciál. Mnoho různých lidí spojených s organizací i dodavatel software potřebují porozumět, jak podnik funguje. Všichni tito lidé mají různé zájmy a pracují v různých podmínkách a mají jiný pohled na jednotlivé činnosti podniku. Úkolem business analýzy je namodelovat jednoduše, tak aby to pochopil každý, realitu. Správný business model musí podporovat různé úrovně zobrazení, různé pohledy na danou věc. Pokud drtivá většina zainteresovaných lidí není schopna porozumět modelu, není splněn hlavní cíl business modelu. Tedy, aby mu každý porozuměl. Na základě modelu by měli být schopni investoři učinit rozhodnutí. Model by měl poskytovat pravdivé informace o současném stavu nebo o stavu cílovém. Informace zobrazené v modelu musí být správné, aktuální, úplné a relevantní. Business modely poskytují statický pohled na strukturu a dynamický pohled na procesy.

3.1 RUP Business analýza V RUP se používají dva základní prvky pro business modelování. Prvním je Use-Case model a druhým je analytický model. Business Use-Case Model je založen na pohledu externích aktérů a jejich spolupráci s podnikem. Tento model je složen z Use-Case (případů užití) a aktérů. Dále může obsahovat diagram aktivit, který modeluje a upřesňuje procesy na pozadí Use-Case. Tento diagram podrobně popisuje aktivity, jak následují postupně za sebou a je zde zobrazena vzájemná interakce mezi uživateli. [Ambler, Nalbone, Vizdos, 2005] Analytický model, který byl dříve znám jako Business Object Model, je založen na popisu aktérů uvnitř organizace a jejich činností. Tyto činnosti jsou popsány sekvenčním diagramem a diagramem tříd. Na následujícím obrázku je vidět, jaká je abstrakce u jednotlivých prvků Business modelování a jaké prvky ovlivňují které.

- 27 -

Business analýza

Obr č1-.3, Prvky Business modelování [Ambler, Nalbone, Vizdos, 2005]

Pro mnoho lidí, kteří pracují v oboru IT, není jednoduché vstřebat syntaxi, která je uvedena v metodice RUP. Mnohem častěji se používá takzvaná BPMN (Business Process Modeling Notification). Tato syntaxe určená pro business modelování se stala standardem a mnoho analytiků využívá raději tuto. V metodice RUP je tato notifikace plně podporována a doporučena. Mnoho analytiků využívá i jiné metodiky, které popisují business modelování. Jednou z takových je EBM (Enterprise Business Modeling). Je jednodušší, flexibilnější, než RUP. Je popsána v metodice EUP (Enterprise Unified Process), kterou jsem již popisoval výše. Pro zopakování uvedu, že je modifikací metodiky RUP, vychází z jejího rámce, který doplňuje. Obsahuje samozřejmě stejné prvky, které se objevují v metodice RUP. Pokud však vytvoříte analýzu dle metodiky RUP, nejste schopni zachytit všechny důležité vazby. V RUP rovněž existuje omezení, kdy nejste schopni sdílet informace mezi různými projekty. Tento nedostatek odstraňuje právě EBM. Velmi oceněnou výhodou může také být, že využívá syntaxi BPMN, která je velmi rozšířena a téměř každý analytik ji ovládá. Budu tedy nadále vycházet z disciplíny (EUP) Enterprise Busines Modeling, protože obsahuje téměř většinu toho, co metodika RUP a přidává ještě některé prvky navíc. Pro úspěch projektu je disciplína business analýzy důležitá hned z několika důvodů. Velmi stručně se je pokusím nastínit.

Pomáhá usnadnit pochopení činností podniku a oblastí, ve kterých se podnik angažuje a podniká.

Identifikuje a přehledně zobrazí podnikové procesy. Jejich analýza může vést ke značným úsporám prostřednictvím cílené automatizace nebo rozsáhlého procesního re-engineeringu.

Pomáhá identifikovat oblasti obchodu, které jsou výhodné pro podnikové investice, nebo může odhalit oblasti, které jsou pro organizaci rizikové.

- 28 -

Business analýza

Analýza, také, poskytuje důležité informace projektovým týmům, které mohou díky ní ohraničit rozsah projektu. Dále mohou určit, jak významnou část aktivit podniku ovlivňuje daný projekt. [Ambler, Nalbone, Vizdos, 2005]

Popis modelu by měl začít celkovým pohledem na obchod. To však neznamená, že budeme pokaždé modelovat všechny obchodní aktivity. Například se můžeme rozhodnout, že budete ignorovat účetní strukturu organizace, protože je stabilní a popis všech procesů by přesáhl stanovený rozsah projektu. Cílem by ale mělo být zachycení všech důležitých skutečností. Často se můžeme opřít pouze o vyspělost a zkušenosti analytického týmu. Při určování, co a do jaké hloubky zobrazit v modelu, nám nepomůže žádná metodika. Model by měl být víceúrovňový. Každá úroveň by měla mít jinou míru detailu. Tato míra by měla být konstantní na všech úrovních. Každý model je pak určen, dle potřeby, jinému cílovému uživateli. Jinou část modelu předložíme managementu a jinou pošleme do IT oddělení. Příliš technickému popisu by management vůbec nerozuměl. Naopak v IT oddělení by určitě neocenili málo podrobný proces komunikace s klienty. Je velmi důležité zvolit potřebnou šíři a hloubku detailu, který je potřebný, žádoucí a nákladově únosný. Informace uvedené v modelu by měly být v čase relativně stabilní. Určit jaké informace zobrazit není jednoduché. Například v bankovnictví je potřeba poskytování úvěrů velmi stará. Avšak finanční produkty, které využívají nějakou formu úvěru, se mění téměř každý měsíc. Ty nebudeme uvádět v modelu. Informace, které mají větší míru abstrakce, jsou stabilní, zatímco detaily jsou velmi dynamické. Výsledkem tohoto procesu je podnikový model, který se skládá z uspořádaných, menších celků, které všechny popisují podnik, ale každý z jiné strany nebo jiným způsobem. V Business analýze lze použít tyto prvky:

popis podnikových pravidel,

procesní model,

doménový model,

popis cílu,

popis vizí podniku,

organizační model podniku [Ambler, Nalbone, Vizdos, 2005]

- 29 -

Business analýza Kritický faktor úspěchu je založen na šikovnosti analytika. Ten musí vytvořit seznam všech důležitých aktérů. Většinou jsou to ředitel IT, ředitel obchodu, dodavatelé, zákazníci, experti z daného oboru a mnoho dalších. V praxi se ukazuje, že by měli být velmi aktivně zapojeni do tvorby analýzy a do tvorby podnikového procesu. Tím se zajistí jeho správnost a úplnost. Na oplátku se mohou přiučit některým analytickým technikám a později je používat. Nástroje, které jsou pro analýzu potřeba, jsou tužka, papír, textový editor tabulkový editor, popřípadě modelovací nástroj. Dále pak je nezbytné mít znalost jazyka UML nebo notifikace BPMN. 3.1.1 Podniková strategie Velmi důležitým prvkem, při vytváření business analýzy, je celková obchodní strategie. Je vodítkem při všech aktivitách, které jsou spojeny s Business modelováním. Při jejím vytváření je důležitá velmi těsná spolupráce, jak uvádím výše. Tato strategie musí vzejít z obchodních aktivit a z primárního cíle podniku a musí být odsouhlasena všemi důležitými útvary podniku. Rozhodně nemůže být považována pouze za IT strategii. Popisuje hlavní obchodní aktivity, IT strategie je vždy pouze podpůrná pro strategii obchodní. Analytici mají za úkol definovat cíle, úkoly a vize podniku, pokud je již podnik nemá definované. Možností, jak potřebné informace získat od zákazníka, je více. Sjednat si formální jednání s investory, domluvit si méně formální schůzku nebo se potkat jednotlivě se všemi důležitými Stakeholdery. Cíle a úkoly jsou většinou definovány krátkou větou, nebo souvětím. Například: „Zvýšit počet zákazníků pro daný produkt o 7% v následujícím čtvrtletí.“ Vize je většinou formulována více větami. Například: „Dostat se v následujícím roce mezi desítku nejvýznamnějších finanční ch institucí v ČR, která nabízí stavební spoření.“ Je důležité vizi dobře popsat. Pokud není vize popsána tak, aby byla měřitelná, nikdy nevíte, zda ji naplňujete. Pokud nevíte, kam jdete, nikdy se tam nedostanete. [Ambler, Nalbone, Vizdos, 2005] 3.1.2 Procesní model Popisování obchodních procesů je nejzákladnější a nejdůležitější disciplínou v Business modelování. Vytvořením procesního modelu si odpovídáme na otázku JAK, jakými funkcemi se dostaneme k cíli. Zohledňuje vizi a poslání. Business procesem rozumíme strukturovaně uspořádané informace o všem, co se týká fungování společnosti, tzn. o procesech, organizačních strukturách, o struktuře produktů a služeb, o strukturách dokumentace, informace strategického charakteru struktura cílů společnosti ve vazbě na procesy. - 30 -

Business analýza Procesní model by měl zahrnovat tyto oblasti: [Ambler, Nalbone, Vizdos, 2005] 3.1.2.1 Popis vnějšího prostředí Dříve než můžete účinně popsat obchodní proces, potřebujete porozumět prostředí, ve kterém se pohybujete. Musíte poznat zákazníky, jejich potřeby. Dále musíte poznat dodavatele, partnery. Důležitou částí okolí je konkurence. Také tu musíte poznat, abyste mohli navrhnout lepší proces, než má ona a Váš zákazník byl spokojený. Musíte tedy: Porozumět prostředí, do kterého je informační systém zasazován. Porozumět aktuálním problémům, potřebám organizace a identifikovat příležitosti ke zlepšení. Sjednotit pohled zúčastněných stran. Vymezit rozsah řešení a identifikovat požadavky na systém. 3.1.2.2 Kritická obchodní pravidla Ve chvíli, kdy pochopíte obchodní procesy v organizaci, jste schopni popsat obchodní pravidla v organizaci. Cílem je se zaměřit na hlavní myšlenku. Touto myšlenkou může být například to, že banka bude účtovat měsíční poplatek za vedení účtu. Zde nepotřebujete přesně popsat, jakým způsobem se poplatek bude vybírat. Podniková obchodní pravidla by měla být nadčasová a měla by platit i v blízké budoucnosti. 3.1.2.3 Obchodní proces Obchodním procesem rozumíme množinu aktivit, které z jednoho či více vstupů vytvářejí výstup, který přináší nějakou hodnotu. Například naplňujeme cíl organizace. Často se skládá z pod-procesů nebo z elementárních procesů či aktivit. Elementární proces je nedělitelný. Někdy se znázorňuje odlišným grafickým prvkem. Vstupem mohou být zdroje nebo informace. Informace jsou používány pro správné provedení požadovaných aktivit. Informace, na rozdíl od zdrojů, nejsou procesem konzumovány a mohou být použity ve více instancích procesu. Informace mohou pocházet z externích systémů, jiných procesů, od zákazníků či zaměstnanců. Zdroje jsou vstupem do procesu a na rozdíl od informací dochází v procesu k jejich „zkonzumování“.

- 31 -

Business analýza Proces generuje výstupy, které jsou požadovány businessem (zákazníkem procesu). Může jím být objekt (logický nebo fyzický – například objednávka, smlouva apod.), transformace vstupů do jiné podoby nebo rozhodnutí například uzavření smlouvy, zpracování objednávky apod. Výstup z procesu může vstupovat do dalších procesů jako vstup nebo může být událostí spouštějící jiný proces. Události jsou vnějším podnětem (signálem), ovlivňujícím proces. Pro každý proces musí být definována alespoň jedna událost, která způsobí spuštění procesu. K události je vhodné definovat, kdo a jak ji vyvolává. Události, které jsou zachytávány v průběhu procesu, se obvykle kreslí až v diagramu, popisujícím pracovní tok procesů. Jak vytvořit procesní diagram? 1. Krok: Vytipování procesů v organizaci Najít klíčové zákazníky a produkty => které procesy se jich týkají (od přihlášky k přijetí, od registrace na kurs k jeho absolvování apod.). Výsledkem je seznam procesů. 2. Krok: Popis průběhu procesu (model) Popsat proces na takové úrovni podrobnosti, která umožní zachytit podstatu procesu a nalézt možné příčiny problémů, úzká místa, duplicitní činnosti apod. 3. Krok: Popis jednotlivých procesů Pro každý proces uvést popis, cíl, vstupy, výstup 4. Krok: Průběžná kontrola konzistence s ostatními modely Pokud například vznikají souběžně další modely (např. doménový model), je nutné se k tomuto kroku vrátit při modelování ostatních dimenzí a zkontrolovat celkovou konzistenci všech modelů.

Procesní diagram se skládá z procesní hierarchie, která slouží ke zmapování a dekompozici firemních procesů, z pod-procesů nebo z elementárních procesů. A dále z procesních řetězců, které slouží ke znázornění posloupnosti procesů a jejich propojení. Obvykle se modelují „zleva doprava“.

- 32 -

Business analýza 3.1.3 Automatizace Pokud budeme brát proces automatizace jako klíčovou součást obchodních podnikových procesů, můžeme si říci, že IT oddělení v takové organizaci podporuje hlavní předmět podnikání organizace. Snahy IT oddělení lze poté zařadit do kontextu celkové organizace. IT technologie nebudou používány pro ně samotné, ale protože podporují obchodní aktivity. Některé procesy budou plně automatizované, některé budou prováděny ručně, ale drtivá většina procesů bude ležet někde mezi těmito dvěma okrajovými. Identifikovat potenciální úspěšné cesty pro podnik a realizovat obchodní procesy je umění. Pokud by nebylo uměním, každé knihkupectví by bylo stejně velké a úspěšné, jako Amazon.Com. Hlavní otázkou je, jaké procesy budeme automatizovat a jaké nikoliv. Rozdělit správně automatizované a neautomatizované procesy, umí pouze lidé, kteří v oboru již velmi dlouho pracují. Jinak budete postupovat iteracemi a budete se blížit k optimu velmi pozvolna. Pomoci v rozhodování pomůže určení finanční návratnosti. K tomuto lze použít například ROI. Další radou může být automatizace často se opakujících úkolů. Ne všechny opakující se činnosti můžeme automatizovat. Informační systémy zatím neumí vyhodnotit informace stejně jako člověk. Chybí jim například sociální faktor. [Larman, 2004] 3.1.4 Doménový model Důležitá část popisu obchodního modelu je vytvoření modelu pojmů. Cílem je pochopit realitu, pojmy používané zákazníkem. Modeluje statickou strukturu obchodních činností. Je vyjádřen typem objektu (třídou nebo entitou) reálného světa a jejich základní a podstatnou vazbou. Tento model je cenným vstupem do porozumění organizace. Nemusí být příliš detailní. Vytvoření tohoto modelu je stejně důležité, jako sběr požadavků, či vytvoření procesního modelu. V obou případech podnikový doménový model poskytuje základ, od kterého se lze odpíchnout při vytváření diagramů. Spolu s Doménovým modelem by měl vzniknout i jednotný pojmový slovník. Projektové týmy jej poté mohou používat a nemusí opětovně definovat pojmy, jako je například „Zákazník“. Tento slovník je cenným zdrojem pojmů uvnitř organizace. Jeho používání nebude vést ke špatným předpokladům a nesprávným údajům. Cílem je vytvořit doménový model, který je napsán tak obecně, že se v čase téměř nemění a přesto obsahuje všechny důležité entity. [Flower, 2003]

- 33 -

Business analýza 3.1.5 Model organizační struktury Organizační struktura podniku obsahuje statická data. Mnoho lidí si myslí, že model organizace je pouze načrtnutí diagramu pracovních pozic. Tento diagram je pouze součástí modelu organizační struktury. Dále však musíme přidat informaci o organizačních jednotkách (týmech, skupinách, divizích). Zapotřebí je popsat hlavní pozice, které mají přímý vliv na chod organizace a zejména na obchodní aktivity a vyznačení vazeb a závislostí mezi nimi.

3.2 Rozbor vstupních požadavků a výběr vhodných komponent U tohoto úkolu jsem stál před požadavkem zadavatele, že chce business analýzu postavenou na standardu BPMN. RUP, jak jsem psal výše, tuto syntaxi plně podporuje. Zákazník si vytvořil organizační model, definoval si vize, cíle a obchodní pravidla a mým úkolem bylo vytvoření doménového modelu a procesního modelu. Po dohodě se zákazníkem jsem doménový model rozdělil dle jednotlivých procesů. Vznikly tak samostatné entitní diagramy, které se váží ke konkrétnímu procesu. Bylo tedy jasné, jaké použít metodiky, dalším krokem bylo vybrat nástroj pro ulehčení tvorby modelů. V úvahu připadaly 3 nástroje. Visio od společnosti Microsoft, Enterprise Architekt od společnosti Sparx Systems a Aris od firmy IDS-Scheer. Zákazník měl zkušenosti s Enterprise Architektem a proto byl zvolen ten. 3.2.1 Popis tvorby a prvků použitých v analýze Při analýze jsou použity 3 úrovně detailů. První úroveň je konceptuálním pohledem na celou problematiku poskytování úvěrů. Ve druhé úrovni jsou řešeny jednotlivé řešené oblasti. Jsou zde použity 3 základní typy diagramů (Hierarchický rozpad, posloupnost procesů a entitní diagram). Podle vhodnosti je použit jeden nebo více diagramů současně.

- 34 -

Business analýza 3.2.1.1 První úroveň zobrazení analysis Business Process Model Zákazník si vybere zboží

«BusinessProces... Vyhledání produktu

«BusinessProces... Vyplnění žádanky

«BusinessProces... Schv álení žádosti

«BusinessProces... Vytv oření soupisů

«BusinessProces... Dokončení smlouv y s klientem

«BusinessProces... Kompletace smluv

«BusinessProces... Vymáhání pohledáv ek "Rozysk"

Start

«BusinessProces... Vytv oření boxů Komunikace s bankou

End

«Lane»

Pohyb originálu

Administrace platebních účtů

«BusinessProce... Správ a osob

«BusinessProce... Správ a produktů Schv alov ací proces

«BusinessProce... Autorizace uživ atele

«BusinessProce... KLientské centrum

«BusinessProce... Správ a prodej ců

«BusinessProce... Správ a číselníků Main

«BusinessProce... Autentizace uživ

Stavy smluv

Obr. č1-.4. První úroveň zobrazení modelu

Popis prvků analysis Business Proce...

Tato ikona zobrazuje business proces. Ležatá osmička «BusinessProces... Vyplnění žádanky

v pravém dolním rohu zobrazuje, že je složený z podprocesů.

analy...

Tato ikona zobrazuje start sekvence procesů. Start

analy...

Tato ikona zobrazuje konec sekvence procesů. End

Popis diagramu Tento typ diagramu zobrazuje business procesy v pořadí, v jakém následují po sobě. Znázorňuje tedy časovou posloupnost. Ležatá osmička v pravém dolním rohu ikony procesu zobrazuje, že ho můžete otevřít. Tím se zobrazí detail procesu.

- 35 -

Business analýza Rozpad obchodních procesů na procesy a aktivity. analysis Business Process Model

«BusinessP... Busines proces

Proces1

Aktivita1

Proces2

Aktivita2

Aktivita3

Obr. č.1-5.Hierarchickýrozpad modelu

Zde je názorně vidět, že proces se rozpadá na procesy a ty se dále rozpadají na aktivity.

- 36 -

Business analýza 3.2.1.2 Druhá úroveň zobrazení – hierarchický rozpad BPMN Prov edení plateb obchodníkov i «Group» Pay Out platby obchodníkovi Pay Out platby obchodníkov i

Smlouva je ve stavu "Aktivní"

Výběr odchozích plateb

Export odchozích plateb

Správ a bankov ních příkazů

Platba bude proplacena

Odeslání exportov aných plateb do banky

Správ a bankov ních účtů

Obr. č1-6.Druhá úroveň zobrazení modelu

Popis prvků act Komunikace s bankou Úvěr je řádně splacen


Platba bude proplacena

Tato ikona zobrazuje proces. Je zde ukázána i událost, která proces spouští a dále ta, která

Pay Out platby obchodníkov i

z procesu vychází. Událost výchozí může být zároveň pro jiný proces událostí vstupní.

BPMN Dokončen... «resource» Smlouv a

Vsup nebo výstup do/z procesu v podobě zdroje.

BPMN Prov edení pl...


Aktivita, která se provádí v rámci procesu.

- 37 -

Business analýza Popis diagramu Tento typ diagramu zobrazuje hierarchický rozpad procesu na jednotlivé pod-procesy. Názorně zobrazuje všechny procesy, které je potřeba pro danou oblast řešit. 3.2.1.3 Druhá úroveň zobrazení – posloupnost procesů BPMN Prov edení plateb obchodníkov i Pay Out - Activity diagram



Zj ištění atributů platby

Start

Seskupení smluv dle prodej ců

Vytv oření seskupených platebních příkazů

Odeslání exportov aných plateb do banky End

Obr. č.1-7. Posloupnost procesů modelu

Popis diagramu Tento typ diagramu zobrazuje posloupnost procesu, jak po sobě následují. Názorně ukazuje vybrané procesy, které je potřeba pro danou oblast řešit a zobrazení návazností je pro pochopení důležité.

- 38 -

Business analýza 3.2.1.4 Druhá úroveň zobrazení – doménový model BPMN Kompletace smluv Kompletace smluv - domain model

Kompletace

Se vytváří při 1..*

Komplet smluv 1..*

1..*

(from Domain Objects)

Banka

Obdrží


1..* (from Domain Objects)

Vzniká při

1..* Splátkov ý kalendář

Smlouv a Obsahuje



Obr. č1-8. Doménový model

Popis prvků BPMN Prov edení plat...

Tato ikona zobrazuje entitu (objekt) a její vazby na Účet

ostatní entity, které jsou důležité pro pochopení dané (from Domain Objects)

problematiky

Popis diagramu Entitní diagram zobrazuje entity a vazby mezi nimi. Jsou zde, také, zobrazeny informace o možném množství okolních entit (1, 1..*, 0..1,…) a jejich podřízenosti.

- 39 -

Business analýza 3.2.1.5 Třetí úroveň zobrazení Popis diagramu Na třetí úrovni detailu je používán diagram aktivit. Jsou zde zobrazeny aktivity, jak následují v posloupnosti za sebou. Popisované aktivity mohou být již velmi detailní. act HCI zkontrolov al splátkov ý kalendář «Group» Proces flow

Start

Import souborů z Banky IMPFILE

Čtení hlav iček IMPFLEPAY

Čtení a párov ání plateb IMPPAYBANK

Rozdělení plateb na j ednotliv é produkty, splátky, smlouv y PAYIN

Kontrola plateb a splátkov ého kalendáře PAYINSTALMENT

End

Obr. č.1-9. Diagram aktivit

- 40 -

Business analýza – praktická část Entitní model analysis Business Process Model

Automobil

Díl

se skládá z 1

1..*

1

Má

0..* Záv ada

Porouchaný díl

Souvisí s 1..*

Dobrý díl

1..*

Obr. č.1-10.Příklad-entitní model

4

BUSINESS ANALÝZA – PRAKTICKÁ ČÁST

4.1 Zadání Společnost, která působí v České republice, uvedla na trh v minulosti úvěrový produkt. Tento produkt umožnění klientovi, přímo v obchodě, sjednat úvěrovou smlouvu s touto společností a klient si ihned může odvést domu výrobek, který se mu líbí. V následujícím měsíci začíná klient společnosti splácet úvěr. Tato společnost si nechala vyvinout informační systém, který umožňuje spravovat klienty, úvěry, úvěrové smlouvy, dlužníky, spočítá bonitu klienta. Dále je v systému řešen například schvalovací proces a proces komunikace s bankou. Tento systém byl na českém trhu úspěšně provozován několik let. V současné době se společnost rozhodla uvést podobný produkt na čínském a ruském trhu. Společnost, ve které pracuji, vyvíjí tento informační systém právě pro čínský trh. Je vyvíjen právě podle metodiky RUP. Mým úkolem bylo vypracování business analýzy, která popíše cílový stav procesů v Číně. Analytici zadavatele měli požadavek, aby byla analýza vytvořena dle metodiky RUP, ale psána v notaci BPMN. Notace, přesně dle RUP, byla pro ně nepřehledná. Byla tedy, zvolena modifikace metodika RUP, která využívá některé komponenty z EBM (Enterprise Business Modeling). Podklady k analýze a informace jsem získával z dostupné dokumentace a pomocí interview s klíčovými Stakeholdery. Ty mi určil zadavatel. Součástí analýzy, odevzdané zákazníkovi, je také model v elektronické podobě ve formátu HTML. - 41 -

Business analýza – praktická část

4.2

Vypracování analýzy - proces poskytování úvěrů (úroveň 1)

4.2.1 Hlavní rozdělení procesů analysis Analýza HCI Name: Package: Version: Author:

Analýza HCI Business Process Model_HCI_Cina 1.1 Nema

Start «BusinessProces... Vyhledání produktu

«BusinessProces... Vyplnění žádanky




«BusinessProces... Kompletace smluv

«BusinessProces... Vymáhání pohledáv ek "Rozysk"

«Pool»

Bussiness procesy

End Zákazník si vybere zboží

Komunikace s bankou

Úvěr je splacen

«BusinessProces... Zpracov ání soupisů na Guarantee company

«BusinessProces... Zpracov ání smluv v Bance

«BusinessProces... Zpracov ání smluv na HCI

«Lane»

Administrační procesy

«Pool»

Příklad použití prvků

Pohyb originálu

«BusinessProce... Správ a účtů zákazníků

«BusinessProce... Administrace platebních účtů HCI

«BusinessProce... Správ a osob

«BusinessProce... Správ a produktů

«BusinessProce... Správ a Product Setu

«BusinessProce... Správ a smluv s Bankou a GC

«BusinessProce... Správ a prodejen

«BusinessProce... Správ a prodej ců

«BusinessProce... Správ a bank

«BusinessProce... Správ a uživ atelů

Příklad

Obr. 1 Hlavní rozdělení procesů

4.3 Proces poskytování úvěrů (úroveň 2) 4.3.1 Vyhledání produktu BPMN Vyhledání produktu «Group» Vyhledání produktu Zákazník si vybral zboží

Vyhledání produktu - domain model

Je vybrán produkt pro zákazníka

«BusinessProce... Vyhledání produktu

Obchodník

Produkt set

Zvolí 1

0..1

(from Domain Objects) 1 1 Zvolí

(from Domain Objects) Vybere

1..*

1..*

Parametr Vybrání setu produktů

Identifikace zákazníka

Definice v stupních parametrů pro v yhledání produktu

Prohlížení detailu produktu

Produkt

Má 1 1


(from Domain Objects) 1 Je financováno

1..* Zákazník

Vyhledání produktu

1 (from Domain Objects)

Obr. 2 Vyhledání produktu

- 42 -

Zboží

Kupuje 1..*


Business analýza – praktická část Tab.1 Proces vyhledání produktu Vymezení pojmů Produkt-produktem se rozumí typ úvěru, který je připraven pro zákazníka. Vstupy procesu Vstupem pro tento proces je rozhodnutí zákazníka, že bude financovat zboží produktem od HCI. Popis procesu V tomto procesu je potřeba nejdříve identifikovat zákazníka, zda již nemá nějaký produkt od HCI zajištěn. Dále je možné vybrat ze setu produktů nějaký, který je vhodný. Set produktů nemusí být vybrán. Po zadání potřebných údajů se vybere vhodný produkt, u nějž si můžeme zobrazit podrobnosti a způsob výpočtu. Výstupy procesu Je vybrán produkt, kterým bude zákazník financovat své zboží.

4.3.2 Vyplnění žádanky BPMN Vyplnění žádanky «Group» Vyplnění žádanky

Vyplnění žádanky Žádanka

Je vybrán produkt, kterým chce zákazník financovat zboží

«resource» Vyplněný formulář žádanky Vyplnění žádanky

(from Domain1 Objects) Vyplní

Žádanka je vyplněna a odeslána

1 Obchodník

Poskytne informace 1


Zákazník


Vyplnění žádanky

Obr. 3 Vyplnění žádanky

Tab.2 Proces Vyplnění žádanky Vymezení pojmů Žádankou se rozumí formulář, který vyplní obchodník. Jsou zde uvedeny informace od zákazníka. Vstupy procesu Byl vybrán produkt, kterým bude zákazník financovat své zboží. Popis procesu Zde je obchodníkem vyplněn formulář s údaji o zákazníkovi, který se rozhodl financovat zboží produktem od HCI. Výstupy procesu Žádanka je vyplněna.

- 43 -

Business analýza – praktická část 4.3.3 Schválení žádosti - scoring BPMN Schv álení žádosti - scoring «Group» Schválení žádosti - aktivity diagram

«Group» Schválení žádosti

Existuje vyplněná žádanka


Schválení žádosti - domain model

Žádost

Zpracovaná sm louva(schválená, zam ítnutá, zamítnutá s alternativou)

Start

1

1


Prov edení tv rdých kontrol

Schv álení žádosti

Obsahuje

(from Domain Objects) Obsahuje

Obsahuj e

1..*

Posouzení smlouv y

Prov edení tv rdých kontrol

Schv álení smlouv y s asistencí

Automatické schv álení smlouv y

Proběhne aktivita scoringu autom aticky?

37

Aktiv ita

Tv rdá kontrola



Ne Ano Schválení žádosti Prov edení aktiv ity, která proběhne automaticky

Iniciace aktiv ity, kde j e potřebný zásah uživ atele

Operace prov edená uživ atelem

1..*

0..*

Automatická aktiv ita


Aktiv ita, která proběhne s asistencí uživ atele 0..* (from Domain Objects)

Uživ atel

Provádí 1..*


Prošli jsme všechny definované aktivity? Ne

Sml ouva je zamítnuta s alternativou

Ano Zobrazení v ýsledku schv alov ání

Sml ouva je schválena

Sml ouva je zam ítnuta

End

Obr. 4 Proces schválení žádosti

Tab.3 Proces schválení žádosti Vymezení pojmů Scoring - proces ověřování údajů ze žádanky. Vstupy procesu Žádanka je vyplněna a v systému jsou uloženy informace. Popis procesu Proces scoringu žádosti se skládá ze tří částí. V první jsou provedeny tzv. „Tvrdé kontroly“. Tyto kontroly musí být všechny splněny. V další části se provádí automatické schválení. Provedou se předem definované aktivity, které prověřují v jednotlivých krocích zákazníka. U některých kontrol (aktivit) je potřeba zásahu uživatele. Ten provede určitou operaci mimo systém a výsledek zapíše do aplikace. Workflow se upravuje vždy podle poslední doběhnuté aktivity. Výstupy procesu Žádost je zpracovaná. Možné výsledky jsou: schválená, zamítnutá, zamítnutá s alternativou.

- 44 -


4.3.4 Dokončení smlouvy s klientem BPMN Dokončení smlouv y s klientem «Group» Dokončení smlouvy s klientem Smlouva je zamítnuta s alternativou

Dokončení smlouvy s klientem - domain model Vytisknutá a odsouhlasená smlouva


«resource» Smlouv a

Smlouva je schválena

Tiskne Smlouv a

1

1

Obchodník

Kontroluje 1 (from Domain Objects) 1


Kontroluje «resource» Decision statement

1 Zákazník

Kontrola smlouv y a j ej í podpis

Tisk smluv a příloh (from Domain Objects)

Dokončení smlouvy s klientem

Obr. 5 Dokončení smlouvy s klientem

Tab.4 Proces dokončení smlouvy s klientem Vymezení pojmů Decision Statement - dokument, který obsahuje výsledky scoringu. Vstupy procesu Smlouva je schválená. Smlouva je zamítnutá s alternativou. Popis procesu V tomto procesu dochází ke konečné kontrole smlouvy se zákazníkem, k tisku a podpisu smluv. Dále dochází k tisku Decision State. Výstupy procesu Vytištěná a podepsaná smlouva, vytištěný Decision statement.

- 45 -


4.3.5 Vytvoření soupisů BPMN Vytv oření soupisů «Group» Vytvoření soupisů

Podepsaná smlouva

Vytváření soupisů - domain model Soupisy jsou odeslány do "Guarantee company"


Uživ atel

(from Domain 1..* Objects) Spravuje «resource» Prův odka

1..* Soupis

Guarantee company

Obdrží 1..*



1 Vytv oření soupisů

Správ a soupisů

Kontrola soupisů

Tisk prův odky a odeslání soupisů na Guarantee Company

1..* Smlouv a


Vytvoření soupisů

Obr. 6 Vytvoření soupisů

Tab.5 Proces Vytvoření soupisů Vymezení pojmů Guarantee Company (GC) - Guarantee company (GC) - Instituce, která kontroluje v Číně smlouvy. Každý obchodník je k nějaké GC přiřazen. Vstupy procesu Smlouva je podepsaná. Popis procesu V tomto procesu jsou vytvářeny soupisy, které jsou posílány na Guarantee Company. Jsou vytvořeny každý večer, poté obchodník zkontroluje a zaškrtne, že jsou přiloženy všechny potřebné dokumenty, vytiskne průvodku a vše pošle na GC. Poté, co GC potvrdí registraci, je možné smlouvy proplatit obchodníkovi. Smlouvy, které obchodník nezpracuje a neodešle do GC, jsou automaticky po 30 dnech stornovány. Výstupy procesu Soupisy jsou odeslány do Guarantee Company a potvrzeny.

- 46 -


4.3.6 Zpracování smluv na Guarantee company act Zpracov ání smluv na Guarantee company Zpracování soupisů na GC

«BusinessProcess» Zpracov ání soupisů na Guarantee company

Příjem soupisů na GC

Příj em Soupisů

Kontrola soupisů

Odeslání Soupisů na HCI

Odeslání soupisů na HCI

Obr. 7 Zpracování smluv v GC

Tab.6 Proces zpracování smluv v GC Vymezení pojmů Guarantee company (GC) - Instituce, která kontroluje v Číně smlouvy. Každý obchodník je k nějaké GC přiřazen. Vstupy procesu Příjem soupisů na GC. Popis procesu V tomto procesu jsou soupisy doručeny do GC. Zde se překontroluje formální správnost soupisů a smluv a úplnost. Poté se vše odesílá na HCI. Výstupy procesu Soubory smluv jsou odeslány na HCI a potvrzeny.

- 47 -


4.3.7 Zpracování smluv na HCI act Zpracov ání smluv na HCI Zpracování soupisů na GC

«BusinessProcess» Zpracov ání smluv na HCI

Příjem soupisů na HCI

Příj em souborů smluv

Kontrola souborů smluv

Vytv oření boxů

Odeslání boxů do Banky

Odeslání boxů do Banky

Vytvoření boxů

Obr. 8 Zpracování smluv na HCI

Tab.7 Proces zpracování smluv v HCI Vymezení pojmů HCI – (Vymazáno) Vstupy procesu Příjem souborů smluv na HCI. Popis procesu V tomto procesu jsou soubory smluv doručeny na HCI. Zde se překontroluje formální správnost soupisů a smluv a úplnost. Poté se ze smluv vytvoří "Boxy" a vše se odešle do Banky. Výstupy procesu Boxy jsou odeslány do Banky.

- 48 -


4.3.8 Zpracování smluv v Bance act Zpracov ání smluv v Bance Zpracování smluv v Bance

«BusinessProcess» Zpracov ání smluv v Bance

Příjem boxu v Bance

Příj em boxů

Údaje z boxů jsou správné

Kontrola souborů smluv boxů

Obr. 9 Zpracování smluv v Bance

Tab.8 Proces zpracování smluv v Bance Vymezení pojmů Boxy - balíky smluv Vstupy procesu Příjem boxů do Banky Popis procesu V tomto procesu jsou boxy doručeny do Banky. Zde se překontroluje formální správnost úplnost boxů a smluv. Výstupy procesu Potvrzení, že údaje z boxů jsou správné.

- 49 -


4.3.9 Kompletace smluv BPMN Kompletace smluv «Group» Kompletace smluv

Soupis z Guarantee Company je potvrzen ke kompletaci

Kompletace

Kompletace smluv - domain model

Kompletace smluv Vznikly předpisy pro platby obchodníkovi

Kompletace

Smlouva je připravena k "registraci"


Komplet smluv

Banka

Obdrží 1..*



Vzniká při

Splátkový kalendář je vytvořen

1..*

Smlouva se dostala do stavu "Aktivní"

Splátkov ý kalendář

Smlouv a Obsahuje


Jednotliv é zpracov ání smluv

Se vytváří při 1..* 1..*


Dáv kov é zpracov ání smluv

Obr. 10 Kompletace smluv

Tab.9 Proces kompletace smluv Vymezení pojmů Splátkový kalendář - přesné termíny a částky, jak bude zákazník splácet úvěr. Vstupy procesu Soupis z Guarantee Company je potvrzen ke kompletaci. Popis procesu Zde se provádí kontrola vyplněných údajů ve smlouvě. Smlouva se dostane do stavu aktivní, dále se vygeneruje splátkový kalendář. Od této chvíle mohou vzniknout předpisy pro banku pro zaplacení plateb obchodníkovi. Dále se generují úkoly pro operátory. Např. Welcome call. Výstupy procesu Vznikly předpisy pro platby obchodníkovi; Smlouva je připravena k "registraci"; Splátkový kalendář je vytvořen; Smlouva se dostala do stavu "Aktivní".

- 50 -


4.3.10 Pohyb originálu act Pohyb originálu Pohyb originálu - domain model

Soupisy elektronicky Papírové soupisy

Boxy smluv

Obchodník

Guarantee company



HomeCreditInt

Banka



Papírové smlouvy

Pohyb originálu

Obr. 11 Pohyb originálu

Tab.10 Proces pohyb originálu Vymezení pojmů Guarantee company (GC) - Instituce, která kontroluje v Číně smlouvy. Každý obchodník je k nějaké GC přiřazen. Place Mark - údaj, kde se smlouva (smlouvy) právě nachází. Je zaznamenána také historie. Quality Mark - údaj, o kvalitě papírové smlouvy (smluv). Je zaznamenána také historie. Možná známka 13. Vstupy procesu Smlouva Popis procesu Zde je znázorněn tzv. Pohyb originálu. Obchodník vytváří každý večer soupisy smluv a ty posílá v papírové formě i elektronicky na GC, ke které náleží. Ta soupisy zkontroluje a zašle je na HCI. Zde je opět zkontrolují a zašlou v Boxech do Banky. Výstupy procesu Schválená smlouva všemi subjekty.

- 51 -


4.3.11 Komunikace s bankou act Komunikace s bankou Komunikace s bankou «resource» HCI má Seznam čísel karet přiřazena čísla od Banky

Přiřazení čísel karet

HCI má přiřazena čísla od Banky

Komunikace s bankou «resource» Seznam v ytv ořených účtů

Příprav a bankov ních účtů

HCI potřebuje přiřadit čísla karet od Banky

Bankovní účty jsou vytvořeny

Bankovní účty jsou vytvořeny

Kompletace

Úvěr je řádně splacen

Pay In Smlouva se dostala do stavu "Aktivní"

Úvěr bude splacen předčasně


Úvěr bude splacen předčasně

Předčasné splacení Úvěr je splacen

Úvěr je potřeba vymáhat


Platba bude proplacena obchodníkovi

Obr. 12 Komunikace s bankou

Tab.11 Proces komunikace s bankou Vstupy procesu Smlouva se dostala do stavu "Aktivní"; HCI potřebuje přiřadit čísla karet od Banky. Popis procesu Tento proces v sobě zahrnuje 5 hlavních pod-procesů, které spojuje komunikace s bankou. Jde o tyto: Přiřazení čísel karet - Zde se popisuje proces přiřazování karet společnosti HCI, která je později použije u vytváření účtů pro zákazníky. Příprava bankovních účtů - v tomto procesu je řešeno vytváření bankovních účtu pro zákazníky. Pay out - tento proces řeší oblast zaplacení obchodníkovi za zboží. Pay in - tento proces řeší oblast splácení úvěru zákazníkem. Předčasné splacení úvěru zákazníkem - zákazník si určí, že chce svůj dluh vůči HCI předčasně splatit. Jakým způsobem je vše řešeno, je uvedeno v tomto procesu. Výstupy procesu Úvěr se zákazníkovi nepodařilo splatit; úvěr je řádně splacen; úvěr je předčasně splacen.

- 52 -


4.3.12 Příprava bankovních účtů act Příprav a bankov ních účtů Příprava bankovních úč tů HomeCreditInt požádal o v ytv oření účtu

Banka v ytv ořila účet

Banka zaslala informace o v ytv ořených účtech

Start

End

Příprava bankovních účtů

Obr.: 13 Příprava bankovních účtů

Tab.12 Proces přípravy bankovních účtů Vstupy procesu Smlouva se dostala do stavu “aktivní“. Popis procesu Při tomto procesu pošle HCI požadavek bance, aby vytvořila účty pro zákazníky, kteří na tyto účty budou splácet úvěr. Banka zpět potvrdí vytvoření účtů. Výstupy procesu Bankovní účty jsou vytvořeny.

- 53 -


4.3.13 Pay In BPMN Pay In «Group» Pay IN

Pay in - State diagram

Start

Úvěr bude spl acen předčasně Pay In


Úvěr je řádně splacen Úvěr je potřeba vymáhat

Vyhledáv ání v importech

Párov ání plateb

Stornov ání platby

Odpárov ání plateb

Zákazník zaplatí platebním příkazem splátku na účet

Párov ání plateb

Banka pošle na účet HC peníze

Import souborů

Je úvěr řádně splacen?

Vymáhání

«Group» Domain model Úvěr je řádně splacen Splátkov ý kalendář

Je kontrolován


HomeCreditInt

(from Domain Objects) Požádá o

Inkaso

Na

(from Domain Objects) Vydá

Pay In

Účet

(from Domain Objects) Vytvoří

Přijde na

Banka

Platební příkaz


(from Domain Objects) Posílá

Zákazník


Obr. 14 Pay In

Tab.13 Proces Pay In Vstupy procesu Smlouva je ve stavu "aktivní". Popis procesu Zde je řešeno splácení úvěru zákazníka, import souborů z Banky, jejich správné napárování na splátkový kalendář zákazníka. Dále případné odpárování plateb. Výstupy procesu Úvěr je řádně splacen, úvěr je předčasně splacen, úvěr je potřeba vymáhat.

- 54 -


4.3.13.1

HCI zkontroloval splátkový kalendář (úroveň 3) act HCI zkontrolov al splátkov ý kalendář «Group» Proces flow

Párován plateb

Start

Import souborů z Banky

Čtení hlav iček

Čtení a párov ání plateb

Rozdělení plateb na j ednotliv é produkty, splátky, smlouv y

Kontrola plateb a splátkov ého kalendáře

End

Obr. 15 Kontrola splátkových kalendářů

Tab.14 Proces kontrola splátkových kalendářů Vymezení pojmů Párování plateb - proces, při kterém se porovnají platby zaplacené zákazníkem a platby, které měl zaplatit dle naplánovaného splátkového kalendáře. Vstupy procesu Jsou vytvořeny bankovní účty pro zákazníka; zákazník poslal splátku úvěru. Popis procesu V tomto procesu je řešena splátka, která byla strhnuta zákazníkovi z účtu a následné napárování platby k jednotlivé smlouvě. Výstupy procesu Úvěr je řádně splacen; Úvěr se zákazníkovi nepodařilo splatit.

- 55 -

Business analýza – praktická část 4.3.14 Provedení plateb obchodníkovi BPMN Prov edení plateb obchodníkov i «Group» Pay Out - domain model

«Group» Pay Out platby obchodníkovi Smlouva je ve stavu "Aktivní"


Produkt set

Platba bude proplacena obchodníkovi

Guarantee company

Urč í 1..*

1


Banka

Urč í 1

1..* (from Domain1Objects)


Poskytuje

1..*

1..* Produkt Výběr odchozích plateb


Správ a bankov ních příkazů

Platba

Je použit u 1

1..* Odeslání exportov aných plateb do banky

Správ a bankov ních účtů

1..*


Je splacena na 0..1

(from Domain1..* Objects)

Odvádí

Účet 1 (from Domain 1Objects) Vlastní

1

1

HomeCreditInt

Soupis plateb

Obchodník




Pay Out - Activity diagram



Zj ištění atributů platby

Seskupení smluv dle prodej ců

Start

Vytv oření seskupených platebních příkazů

Odeslání exportov aných plateb do banky End

Provedení plateb obchodníkovi

Obr.: 16 Platby obchodníkovi

Tab.15 Proces platby obchodníkovi Vstupy procesu Smlouva je ve stavu “aktivní“. Popis procesu Zde jsou řešeny platby obchodníku. Tedy platby za zboží, které bylo prodáno zákazníkovi a obchodník za něj ještě nemá zaplaceno. V tomto procesu jsou vybrány částky ze smluv, které mají být proplaceny. Ty jsou následně seskupeny dle obchodníků a poslány na účty obchodníků. Výstupy procesu Platba obchodníkovi bude proplacena.

- 56 -


4.3.15 Předčasné splacení act Předčasné splacení Early payment

Timetable for repayment rebuilding

Requirement for Early payment

A loan is paid back

Splatil Customer w ant to send early payment

Has customer paid back remaining debit?

Nesplatil Paying off the part of the debt

A loan is not paid back

Early payment

Obr. 17 Předčasné splacení

Tab.16 Proces předčasné splacení Vstupy procesu Požadavek na předčasné splacení Popis procesu Nejdříve požádá zákazník o předčasné splacení, pokud má na účtu dostatečné množství peněz, je přegenerován splátkový kalendář a zaplacena zbývající část úvěru. Pokud není na účtu dostatečné množství peněz, jsou spláceny postupně částky podle původního splátkového kalendáře. Podle množství peněz na účtu. Výstupy procesu Úvěr je splacen; Úvěr není celý splacen.

- 57 -

Diskuse a závěr

5

DISKUSE A ZÁVĚR

Byla vytvořena analýza podle metodiky RUP. Obsahuje seznam procesů, jejich rozpad na sub-procesy a jednotlivé aktivity. Z analýzy je patrné, jaké činnosti musí být provedeny, aby si mohl zákazník odnést z obchodu požadovaný výrobek a nemusel mít dostatek finančních prostředků. Dále je zde popsáno, jak se úvěr schvaluje, splácí atp. Tuto analýzu mohou využít pracovníci zákazníka i pracovníci dodavatele řešení. Je vhodná zejména k seznámení všech pracovníků, kteří jsou na projekt nově přiřazeni, a potřebují se seznámit se všemi procesy. Před tím, než existovala tato analýza, bylo zaškolení nových pracovníků velmi náročné na čas i zdroje a často bylo neúplné. Tato analýza urychlila proces zaškolování z 5 dnů na 0,5 dne. Analýza je také vhodná pro urychlení práce programátorů a testerů, kteří vidí proces poskytování úvěrů celý a mohou lépe předvídat dopady svých činností. Další přínos vidím v tom, že je vypracována na základě stejné metodiky, kterou využívají. V práci jsou popsány charakteristické znaky metodiky RUP a zejména Business analýzy. Dále jsou popsány jednotlivé disciplíny a principy. Čtenář si tak může vytvořit celkový obrázek o této metodice. V druhé části práce je podrobněji rozebrána disciplína Business analýzy. Popsány jsou opět nástroje, činnosti a důvody k jejich použití. V poslední části práce jsou vytvořeny analytické modely, které vychází z teoretické části práce a z předem definovaných kritérií. Nedostatek vidím v oblasti generování modelů do obvyklých dokumentových formátů. Na výběr máme výstup v podobě HTML, nebo v podobě RTF. Zaměřil jsem se na RTF formát, protože je lehce dostupný zákazníkovi. Do analýzy bylo potřeba přidat různé popisky a poznámky. Tato funkcionalita není v Enterprise Architekt umožněna. Popisy procesů jsem musel proto vložit do samostatných dokumentů, které je potřeba „přilepit“ do jednotlivých procesů. Z důvodu přesnějšího formátování textu jsem veškerý text přidal do tabulek. Analýza je tak složena z obrázků a tabulek. Nevýhodou je generování obrázků, které mají malou velikost, a nemusí tak být pro lidi se špatným zrakem plně čitelné. Tento nedostatek může být kompenzován tím, že zákazník dostane analýzu také v HTML formátu.

- 58 -

Diskuse a závěr

Hlavní cíl práce, vytvoření a vygenerování analýzy, byl splněn. Závisí na posouzení každého, zda jsou pro něj modely přehledné a srozumitelné. V modelu jsou použity zkušenosti, které jsem za léta praxe nastřádal v oblasti datového modelování. Dále jsou zde použity poznatky z oblastí ekonomických, finančních a bankovních. Nástroj Enterprise Architekt také umožnil vytvoření modelu, který odpovídal požadavkům zákazníka a byl pro něj přínosem.

- 59 -

Seznam použité literatury

SEZNAM POUŽITÉ LITERATURY [1.] Ivar Jacobson, Grady Booch, and James Rumbaugh, THE UNIFIED SOFTWARE DEVELOPMENT PROCESS, Boston, Addison-Wesley, 1999, 465s, ISBN 0-201-57169-2 [2.] Per Kroll, Philippe Kruchten, THE RATIONAL UNIFIED PROCESS MADE EASY: A PRACTITIONER’S GUIDE TO THE RUP, 1, Boston, Addison-Wesley, 2003, 464 s, ISBN 0-321-16609-4 [3.] Philippe Kruchten, THE RATIONAL UNIFIED PROCESS AN INTRODUCTION SECOND EDITION, 2, Boston, Addison-Wesley, 1999, 336 s, ISBN: 0-321-19770-4 [4.]Ambler, S.W., Nalbone, J., and Vizdos, M., THE ENTERPRISE UNIFIED PROCESS: EXTENDING THE RATIONAL UNIFIED PROCESS, 2005 [5.] Bergstrom, Stefan, Raberg, Lotta, ADOPTING THE RATIONAL UNIFIED PROCESS: SUCCESS WITH THE RUP, Boston, Addison-Wesley, 2004, 272s, ISBN 0-321-20294-5 [6.] Larman, Craig, AGILE AND ITERATIVE DEVELOPMENT: A MANAGER'S GUIDE, Boston, Addison-Wesley, 2004, 368s, ISBN 0-13-111155-8 [7.] M. Fowler, UML DISTILLED THIRD EDITION A BRIEF GUIDE TO THE STANDARD OBJECT MODELING LANGUAGE, Boston, Addison-Wesley, 2003, 175s, ISBN 0-321-19368-7 [8.] Rational Method Composer v.7.0.1. English – CD, verze 2006-0717, 1 disc [9.] Matering UML with Enterprise Architect and the ICONIX Process – CD [10.] 2006 IBM Software development Conference, June 4-8, 2006, Walt Disney World Swan and Dolphin Resort. Orlando, Florida, 6 Disc

- 60 -

BUSINESS ANALÝZA DLE METODIKY RUP A JEJÍ PODPORA V NÁSTROJI ENTERPRISE ARCHITECT

Recommend Documents