Bankovní institut vysoká škola Praha Katedra Informatiky a kvantitativních metod
Vývoj softwarového systému pro telesales Diplomová práce
Autor:
Bc. Jiří Vlasák
Vedoucí práce:
Ing. Vladimír Beneš, Ph.D.
Praha
Červen, 2015
Prohlášení Prohlašuji, ţe jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou pouţitou literaturu. Svým podpisem stvrzuji, ţe odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, ţe se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.
V Praze dne 28. června 2015
Jiří Vlasák
Poděkování Touto cestou bych chtěl poděkovat vedoucímu své práce Ing. Vladimíru Benešovi, Ph.D. za ochotný a velmi vstřícný přístup při vedení a za jeho cenné rady a připomínky.
Anotace Cílem této diplomové práce je navrhnout a implementovat informační systém (IS), který bude slouţit pro podporu telesales aktivit zákazníka – podnik nabízející sluţby komerčního call centra. Práce objasňuje teoretické souvislosti a zároveň popisuje praktická opatření a kroky, které byly provedeny v průběhu projektu. První část je věnována analýze poţadavků a technologických moţností. Druhá část se zabývá nastavením projektu, návrhem, implementrací a testováním informačního systému. Třetí část je věnována pilotnímu provozu. Čtvrtá část obsahuje vyhodnocení projektu. Klíčová slova: Informační systém, telesales, softwarový projekt, testování software
Annotation The main goal of this thesis is to design and implement an information system (IS) which will be used to support customer telesales activities – the company providing the commercial call center services. The document clarifies the theory of context and as well as it describes practical precautions and activities, which were done during the work on the project. The first part is focused on analysis of the requirements and the technology possibilities. The second part deals with the project setting, information system design, implementation and testing. The third part is dedicated to the pilot operation. In the forth part there is evaluation of the project. Keywords: Information system, telesales, software project, software testing
Obsah ÚVOD ............................................................................................................................................................... 6 CÍLE DIPLOMOVÉ PRÁCE ................................................................................................................................ 7 1
ANALÝZA POŽADAVKŮ A TECHNOLOGICKÝCH MOŽNOSTÍ ............................................. 8 1.1
POPIS SITUACE ..................................................................................................................................... 8
1.2
FUNKČNÍ POŢADAVKY ......................................................................................................................... 8
1.2.1
Volací karta ............................................................................................................................... 8
1.2.2
Seznamy ..................................................................................................................................... 9
1.2.3
Reporty .................................................................................................................................... 10
1.2.4
Zavádění kampaní a importy nových případů ......................................................................... 10
1.3
1.3.1
Snadná rozšiřitelnost ............................................................................................................... 11
1.3.2
Hardware, virtualizace serverů ............................................................................................... 11
1.3.3
Vysoká dostupnost (High availability) ..................................................................................... 11
1.3.4
Minimalizace výše nákladů za provoz systému ........................................................................ 11
1.3.5
Hotline, vzdálená podpora....................................................................................................... 11
1.3.6
Dokumentace ........................................................................................................................... 12
1.3.7
Jiné .......................................................................................................................................... 12
1.4
2
3
NEFUNKČNÍ POŢADAVKY ................................................................................................................... 11
TECHNOLOGICKÉ MOŢNOSTI .............................................................................................................. 12
1.4.1
Architektura systému ............................................................................................................... 12
1.4.2
Databázový engine .................................................................................................................. 13
1.4.3
Aplikační server, serverová aplikace ....................................................................................... 13
1.4.4
Klientská aplikace.................................................................................................................... 13
1.4.5
Reporting ................................................................................................................................. 14
PROJEKT ............................................................................................................................................ 15 2.1
PROJEKTOVÝ TÝM .............................................................................................................................. 15
2.2
METODIKA ......................................................................................................................................... 16
2.2.1
Metodika PRINCE2 ................................................................................................................. 17
2.2.2
Agilní metodiky, principy ......................................................................................................... 18
2.3
PREFEROVANÉ PRINCIPY PRO ŘÍZENÍ PROJEKTU ................................................................................. 19
2.4
PODPŮRNÉ NÁSTROJE ......................................................................................................................... 19
2.5
FORMULACE CÍLŮ PROJEKTU.............................................................................................................. 20
2.6
PROJEKTOVÝ SLOVNÍK ....................................................................................................................... 21
NÁVRH, IMPLEMENTACE A TESTOVÁNÍ ................................................................................. 22 3.1
PŘÍPADY UŢITÍ ................................................................................................................................... 22
3.2
WORKFLOW ....................................................................................................................................... 23
3.2.1
Odchozí hovor ......................................................................................................................... 24 4
3.2.2
Vyhledat a zpracovat úkol (workflow) ..................................................................................... 25
3.2.3
Zpracování příchozího hovoru ................................................................................................ 27
3.3
TESTOVACÍ PŘÍPADY .......................................................................................................................... 28
3.4
DATABÁZOVÝ ENGINE ....................................................................................................................... 32
3.5
DATABÁZE ......................................................................................................................................... 32
SERVEROVÁ APLIKACE ................................................................................................................................ 35 3.5.1
Běhové prostředí ...................................................................................................................... 35
3.5.2
Programovací jazyk serverové aplikace a použité frameworky ............................................... 35
3.6
4
5
KLIENTSKÁ APLIKACE........................................................................................................................ 36
3.6.1
Programovací jazyk klientské aplikace a použité frameworky ................................................ 36
3.6.2
Uživatelské rozhraní ................................................................................................................ 38
3.7
GENEROVÁNÍ A DISTRIBUCE REPORTŮ ............................................................................................... 42
3.8
NÁSTROJ PRO IMPORTY KLIENTSKÝCH DAT........................................................................................ 43
3.9
SESTAVOVÁNÍ SYSTÉMU .................................................................................................................... 44
3.10
NASAZOVÁNÍ SYSTÉMU ................................................................................................................. 46
3.11
TESTOVÁNÍ ................................................................................................................................... 46
3.11.1
Kategorizace testování ........................................................................................................ 47
3.11.2
Dimenze kvality ................................................................................................................... 50
3.11.3
Dokumenty pro proces testování ......................................................................................... 52
3.11.4
Testovací prostředí ............................................................................................................. 53
3.11.5
Testovací data ..................................................................................................................... 55
3.12
PROVOZ SYSTÉMU – DOHLEDOVÝ SYSTÉM .................................................................................... 57
3.13
PŘEDÁVÁNÍ, AKCEPTAČNÍ PROTOKOL ........................................................................................... 57
PILOTNÍ PROVOZ ............................................................................................................................ 58 4.1
PODMÍNKY PILOTNÍHO PROVOZU ....................................................................................................... 58
4.2
PŘÍPRAVA ZAVEDENÍ PRODUKTU DO PILOTNÍHO PROVOZU................................................................. 60
4.3
UVEDENÍ DO PROVOZU ....................................................................................................................... 60
4.4
NEDOSTATKY NALEZENÉ BĚHEM PILOTNÍHO PROVOZU ...................................................................... 60
VYHODNOCENÍ................................................................................................................................. 62 5.1
ZÁVĚRY A DOPORUČENÍ ..................................................................................................................... 63
SEZNAM POUŽITÉ LITERATURY ......................................................................................................... 64 SEZNAM OBRÁZKŮ ................................................................................................................................... 67 SEZNAM ZKRATEK ................................................................................................................................... 68 PŘÍLOHY ...................................................................................................................................................... 69 PŘÍLOHA 1 – LOGICKÝ DATOVÝ MODEL TELESALES SOFTWARE .................................................................. 70 PŘÍLOHA 2 – UKÁZKA TELESALES GUIDE PRO PRÁCI S PŘÍPADEM (TRANSFORMOVÁNO Z PDF) ................... 86 5
Úvod O úspěchu či neúspěchu softwarového projektu obvykle rozhodují tři kritéria – čas, kvalita a cena. Softwarové projekty jsou plné rizikových míst. I přesto, ţe kaţdý projekt je ze své podstaty jedinečný, mnohá rizika lze ale velmi dobře předvídat a volbou vhodných protiopatření je buď úplně „vymazat“ či alespoň znatelně sníţit (v odborné terminologii je spíše uţíván výraz „řídit rizika“). Předkládaná diplomová práce je zaměřena na problematiku vývoje a nasazení typového aplikačního softwaru (TASW) v podnikovém prostředí. Předmětem zájmu je komerční projekt dodávky softwarového systému pro podporu telesales call centra odběratele. Autor byl členem projektového týmu a na straně dodavatele se významně podílel na jeho přípravě a provedení. Protoţe tento projekt lze z hlediska časové dotace povaţovat za krátkodobý (dva měsíce), diplomová práce vychází nejen z materiálů sesbíraných před jeho zahájením a v jeho průběhu, ale i po jeho ukončení. Mnoho částí práce pak záměrně vyuţívá této časové retrospektivy a je sestaveno jako jakási konfrontace mělo/mohlo by být – bylo, kde jsou předloţeny konkrétní provedené postupy a kroky. Podmínky projektu byly značně omezující, především pak faktor času, kdy odběratel vyţadoval poměrně krátkou dodání softwarového produktu do pilotního provozu. Nedodrţení tohoto hlavního omezení by mělo fatální dopady na spolupráci s klienty odběratele a jeho celkovou úspěšnost.
6
Cíle diplomové práce Hlavním cílem této diplomové práce je vyvinout softwarový systém pro podporu telemarketingových a telesales aktivit. Navrhnout vertikálně i horizontálně škálovatelné a v krátkém čase nasaditelné řešení. Dílčími cíli jsou dále: V pilotním provozu ověřit ţivotaschopnost systému a navrhnout jeho případné úpravy Identifikovat hlavní rizika projektu, navrhnout způsob jejich eliminace či sníţení Konfrontovat v některých oblastech doporučené/obvyklé postupy s přijatými a zdůvodnit tyto volby Provést vymezení některých pojmů v oblasti vývoje TASW Seznámit s metodikami a nástroji pro řízení kvality softwaru
7
1 Analýza požadavků a technologických možností 1.1 Popis situace Vývojový tým byl osloven zákazníkem poptávajícím dodávku softwarového systému pro podporu činnosti menšího telemarketingového call centra. Součástí kontraktu mělo být i zajištění chodu systému a jeho údrţba systému. Kritickým faktorem byl především čas, kdy termín doručení byl v okamţiku uzavření dohody pouhé dva měsíce. Z toho vyplývá mnoho logických omezení projektu a také souběţně uzavřená dohoda s odběratelem a dalším rozšiřování systému po jeho prvotním nasazení. Je zřejmé
1.2 Funkční požadavky 1.2.1 Volací karta Výběr kampaně Kampaň ve vztahu ke klientovi je mnoţina dat (případů) převzatých od klienta, která je zpracovávána za pouţití jednotných pravidel. Kardinalita vztahu klient – kampaň je 1:n. Operátor má moţnost výběru jediné nebo vícero kampaní ze seznamu. Vybrané kampaně jsou následně jediným zdrojem případů pro práci operátora. Načíst případ (z fronty případů) Volbou načíst případ jsou zobrazeny atributy případu určené pro práci v kontextu „volací karta“. Tento krok je nezbytný pro zahájení práce na novém (přesněji dalším, můţe to být jiţ opakovaně zpracovávaný případ) případu operátorem. Upravit vybrané atributy případu Některé atributy případu jsou určeny k úpravám (typicky k doplnění chybějících údajů). Některé kampaně se vyznačují případy, které byly dodány s neúplnými informacemi. Jde především o kontaktní údaje. K doplnění těchto informací můţe dojít jak ze strany operátora (získává informace prostřednictvím tel. hovorů), tak i ze strany dalších systémů – databází, ať jiţ podnikových, tak i veřejných (např. rejstříky typu ARES). 8
Vytočit/zavěsit hovor V kontextu případu je moţné vyuţít více kontaktních tel. čísel. Systém umoţňuje pouţít minimálně tři, lépe n telefonních čísel, a to i včetně mezinárodních. Pouţití tel. čísel přímo určuje operátor, nedochází k automatickému spojování hovorů. Tato automatika pro telefonii bude předmětem zájmů budoucích verzí (upgrade funkcionality po pilotním provozu). Uložit výsledek hovoru Záznam operace sestává nejen z uloţení výsledku hovoru, ale i z určení následného kroku. Uloţené infromace by měly být z pohledu databázového maximálně normalizované tak, aby byly snadno později zpracovány automaty (ať jiţ algoritmy pouţitými přímo v aplikaci či souvisejícími reporty). Naplánovat událost/úkol (případně řadu událostí) Operátor dle situace má moţnost naplánovat 1-n dalších událostí. Pro kaţdou naplánovanou událost určí typ, termín, doplní další informace ve formě prostého textu.
1.2.2 Seznamy Přehled případu Klientská aplikace nabízí zobrazení přehledu případů ve formě seznamu umoţňujícím rychlé filtrování dle klíčových atributů. Nejméně je moţné filtrovat dle: Kontaktní osoba (jméno) Kontantní firma (název) Telefonní číslo Město Typ události (úkolu) Seznam dále umoţňuje stránkovat výsledky, pokud počet nalezených případů je větší neţ je moţné zobrazit na jediné stránce. Uţivatel má moţnost přecházet mezi jednotlivými stránkami. Přehled událostí/úkolů 9
Klientská aplikace nabízí zobrazení přehledu událostí (úkolů) ve formě seznamu umoţňujícím rychlé filtrování dle klíčových atributů. Nejméně je moţné filtrovat dle: Kontaktní osoba (jméno) Kontantní firma (název) Telefonní číslo Město Typ události (úkolu) Seznam dále umoţňuje stránkovat výsledky, pokud počet nalezených případů je větší neţ je moţné zobrazit na jediné stránce. Uţivatel má moţnost přecházet mezi jednotlivými stránkami.
1.2.3 Reporty Odběratelem nebyly detailně vymezeny podoby reportů, předpokladem jsou souhrnné denní, týdenní a měsíční reporty. Konkrétní rozsah a podoba reportů bude upřesněna těsně po spuštění pilotního provozu. Dodavatel jiţ pro spuštění nabídne dle vlastního uváţení tyto základní reporty: Přehled kampaní Přehled aktivity operátorů (primárně pro jejich fin. ohodnocení) Z hlediska distribuce reportů je poţadováno doručování pravidelných reportů emailem seznamu příjemců.
1.2.4 Zavádění kampaní a importy nových případů Zavedení nové kampaně můţe dle dohody zahrnovat i případně další poţadavky na funkcionalitu software. Dle moţností a důleţitosti a také v závislosti na tom zda bude existovat vhodný workaround, budou pro kaţdý takový poţadavek uzavřena dohoda o implementaci. Importy nových případů budou prováděny po tzv. balících s poţadavkem na doručení do 24 h (platí pro standardní import, kdy je dodrţena dohodnutá datová věta při předání k provedení importu).
10
1.3 Nefunkční požadavky 1.3.1 Snadná rozšiřitelnost Obecně často poţadovaná vlastnost softwarových systémů. Vzhledem k termínu doručení nebude mozne implementovat veškeré pro zákaznika potřebné funkce (které ani nemá v počátku projektu adekvátně rozmyšleny a tedy je není schopen dostatečně specifikovat).
1.3.2 Hardware, virtualizace serverů Veškeré servery budou provozovány jako virtual machine na platformě MS Hyper-V 2012. „Ţelezem“ bude Dell PowerEdge VRTX, zařízení integrující dva (aţ čtyři) blade servery Dell řady M5/M6, 1 Gb switche R1-2401 a diskového pole pro aţ 25 pevných disků.
1.3.3 Vysoká dostupnost (High availability) Zákazníkem je poţadována dostupnost systému min. 99,6% (celková za kalendářní rok). Tato míra dostupnosti je ale chápána jako cílová pro období po pilotním provozu. Pro období pilotního provozu bude sjednána zásadně niţší míra dostupnosti.
1.3.4 Minimalizace výše nákladů za provoz systému Tento poţadavek má signifikantní vliv na výběr pouţitých technologií a systémů. Spolu s limitujícím faktorem termínu doručení předurčuje jako vhodné kandidáty některé vývojářským týmem jiţ dříve pouţívané technologie či systémy.
1.3.5 Hotline, vzdálená podpora Zákazník očekává vysokou úroveň podpory s rozlišením na dobu pracovní a mimopracovní. Konkrétní podmínky budou pevně dohodnuty v okamţiku předání systému do pilotního provozu. Východiska: prac doba po-pá 8-18 h, max. reakční doba 30 min, mimo prac. dobu 6 h.
11
1.3.6 Dokumentace Zákazníkovi bude doručena uţivatelská dokumentace pro rychlé zaškolení operátorů. Preferovaná podoba je “guide” s převaţujícím obsahem náhledů (uţiv. rozhraní) a grafických značek. Náhled na výstřiţek Telesales Guide:
Obrázek 1.1: Telesales Guide – ukázka jednoho kroku pro práci s případem Zdroj: Materiály vývojového týmu
Ukázka jednoho z guide dokumentů v příloze.
1.3.7 Jiné Zákazník vlastní licenci MS SQL Server a tento server provozuje. Telesales systém by měl ideálně vyuţívat tento existující server. Nevylučuje moţnost vyuţití dalších db engine pro podpůrné systémy, ovšem bez dalších významných pořizovacích nákladů.
1.4 Technologické možnosti 1.4.1 Architektura systému I přes menší počáteční rozsah nasazení (z hlediska počtu operátorů, objemu dat) by zvolená architektura neměla být překáţkou budoucího nasazení v řádově náročnéjších podmínkách. Neuvaţujeme tedy variantu (y) dvouvrstvé klient-server architektury a přímo se zaměřujeme na třívrstvou architekturu databázový server – aplikační server klient. Stavíme i na zkušenostech vývojového týmu s vývojem a provozem podobných 12
systémů v heterogenním prostředí Windows-Linux a vývojový tým by tedy nemělo nic zásadního překvapit.
1.4.2 Databázový engine V otázce výběru vhodného db engine není příliš moţností na výběr. Vzhledem k poţadavku zákazníka jím byl určen jiţ provozovaný MS SQL Server 2014.
1.4.3 Aplikační server, serverová aplikace Jako klíčové technologie pro serverovou aplikaci se jeví Java EE, Spring, Hibernate, Maven. Logickým aplikačním serverem je dále Oracle GlassFish Server. Hlavními důvody jsou především zkušenost vývojového týmu s jejich vyuţitím. V okamţiku startu projektu vývojový tým spravuje cca 20 GlassFish serverů, některé z nich aţ 6 let (dříve byl vyuţíván především značně rošířený Tomcat).
1.4.4 Klientská aplikace V otázce volby technologií pro vytvoření klientské aplikace se nabízejí dvě zásadní moţnosti: 1) Vyuţít sadu technologií Adobe Flex, která není ţádnou novinkou a je na světě od 2004. Nabízí moţnost běhu v prostředí webového prohlíţeče, kdy běhovým prostředím je Adobe Flash Player (v případě Google Chrome embeddovaný plugin Pepper Flash). Tato technologie jiţ dnes není moţná příliš progresivní, máme s ní však dlouhodobé a poměrně dobré zkušenosti. 2) Vytvořit aplikaci pomocí MS .Net. V takovém případě preferujeme dále vyuţití WPF a dalších frameworků (MEF) a distribuci k uţivatelům pomocí technologie MS clickOnce. Tato volba by mohla přinést o něcoo lepší komfort uţivatelům. Zvaţujeme umístění byznys logiky aplikace, jak tlustý či tenký by ve výsledku mohl být klient. Je tloustnutí trochu nahrávají vstupní podmínky, předpokládáme nutnost doplňování (převáţně drobnější) funkcionality na koleně v extrémně krátkých intervalech.
13
1.4.5 Reporting V návaznosti na vyuţití MS SQL Server je dobrou moţností vyuţití MS SSRS – SQL Server Reporting Services, které jsou integrální částí tohoto serveru (pozor na edice z hlediska rozsahu podpory funkcionality SSRS!). Další moţností je známá technologie JasperReports (JasperReports Server) či vlastní řešení. Odběratel nemá ţádné vyhraněné poţadavky na způsob distribuce reportů.
14
2 Projekt Vývoj softwarového systému pro telesales nese znaky poměrně náročného projektu, především z důvodu několika zásadních omezení: Informace nezbytné k sestavení specifikace nejsou v době zahájení projektu v dostatečném rozsahu ani není jasný termín jejich pozdějšího doplnění. Je třeba uvaţovat i variantu, ţe tyto informace nebudou do zahájení pilotního provozu vůbec dodány Pevně definovaý termín (60 dní od zahájení – podpisu kontraktu), který i bez určení jednotlivých činností, úkolů a provedení důkladnějších odhadů se jeví jako velmi kritický Nejasný termín, kdy budou dodána byznys data – data získaná od klienta zákazníka, která mají být v první den pilotního provozu naimportována do systému a systém musí být pro jejich uţití odpovídajícím způsobem nakonfigurován. Především díky výše uvedeným limitům projektu je od první chvíle jasné, ţe za konkrétní situace, v souladu s podnikovým projektovým standardem (podniková pravidla pro provádění projektů, jejich financování, zajištění bezpečnosti dat atd.) bude vhodné a nutné směřovat k výraznému zjednodušení některých činností a tím přikoupit za cenu vyššího rizika více časového prostoru. Jako další vhodný krok se jeví sestavit projektový tým především ze lidí, jejichţ forma spolupráce je dlouhodobě ověřená na podobných projektech či činnostech. Uvedené problematice se podrobněji věnují následující kapitoly.
2.1 Projektový tým Vzhledem k zaměření projektu a předpokládaným činnostem je potřeba pokrýt na straně dodavatele následující specializace: Fyzické a virtuální servery, virtualizační platforma Operační systémy, prvotní konfigurace a správa Databázový engine 15
Databáze, datový model Programovací jazyky a související frameworky Systémy a nástroje pro reporting Dohledový systém(y) pro zajištění HA Testování Řízení projektu Míra participace jednotlivých členů projektového týmu na straně dodavatele bude odlišná – všichni tito zúčastnění budou zavázáni i dalšími pracovními povinnostmi nesouvisejícíc s tímto projektem. Také uplatnění některých specializací bude vůči jiným výrazně niţší. Velkou roli bude také hrát existence některých potřebných systémů (např. provozuschopná platforma pro virtualizaci serverů), tam tedy bude pořeba pouze zlomku času oproti situaci, kdy je třeba daný systém postavit „na zelené louce“. Součástí projektového týmu jsou samořejmě i další lidé ze strany odběratele, ať jiţ člověk odpovědný
2.2 Metodika Kaţdý projekt je specifický, tedy je určitě vhodné přizpůsobit metodiku pro řízení projektu daným specifickým podmínkám, omezením. Při volbě metodiky bylo přihlédnuto jak ke kvalifikaci, zkušenostím týmu z hlediska metodiky vedení projektů, tak i k omezujícím faktorům projektu (zde především kritický faktor termínu doručení produktu). Zvolená metodika tedy vychází z PRINCE2 a vyuţívá agilní metody pro řízení softwarového vývoje. Nejen díky zohlednění obecného trendu vyuţívat spíše agilní přístupy oproti klasickým („zapomenutý“ klasický vodopádový model či příliš svazující spirálový), ale i z důvodu osobních preferencí členů vývojového týmu (typický vývojář spíše radši programuje a experimentuje, neţ dokumentuje, detailně plánuje a tráví čas na poradách). Co vývojovému týmu přináší PRINCE2 či některé agilní metodiky? Hlavní faktory jsou více rozebrány v následujících kapitolách.
16
2.2.1 Metodika PRINCE2 PRINCE2 je především velmi silně orientován na produkt (to je v kontrastu s dalším známou metodikou - standardem PMBOK, kde je plánování zaměřeno spíše na náklady a čas), coţ právě v kontextu daného projektu má zásadní význam. Přehled klíčových principů metodiky PRINCE2 [12][4] 1) Zaměření se na produkt (focus on products) Co má být výstupem projektu a v jaké kvalitě? Ať jiţ jde o produkt, nebo sluţbu – metodika pomáhá realizovat jen takové kroky, které jednoznačně vedou k cíli projektu. 2) Učení se ze zkušeností (learn from experience) Metodika vám pomáhá stále se zlepšovat v dovednostech projektového řízení na základě uplatňování zkušeností z předešlých projektů. 3) Řízení dle výjímek (manage by exception) Definuje tolerance a povolené odchylky projektu od plánovaného cíle. V praxi vás tato zásada ochrání před nekvalitně realizovaným projektem. 4) Přizpůsobení se projektovému prostředí (tailored to suit the project environment) Pravděpodobně nejsilnější argument, proč vyuţívat flexibilní metodiku PRINCE2. Vyhovuje velkým i malým projektům, v různých prostředích, různé komplexnosti a důleţitosti. 5) Kontinuální obchodní zdůvodnění projektu (continued business justification) Kaţdý projekt řízený podle metodiky PRINCE2 má mít své opodstatnění v businessu. Pokud neexistuje opodstatnění, projekt je ukončen. 6) Řízení dle etap (manage by stages): Ţivotní cyklus projektu má své etapy. Metodika PRINCE2 nejlépe definuje jak projekt plánovat, monitorovat a kontrolovat na základě těchto etap. 7) Definice rolí a odpovědností (defined roles and responsibilities) Úspěch projektu závisí na tom, ţe kaţdý má jasno o své roli. Jedině tak můţete propojovat obchodní zájmy, cíle projektu s uţivateli, dodavateli a dalšími 17
zainteresovanými stranami. S metodikou PRINCE2 máte vţdy jasně definovanou organizační strukturu, role i odpovědnosti. Kromě jiţ zmíněných sedmi principů PRINCE2 operuje také se sedmi typy procesů a témat, kde opět pouze některé mají pro řešený projekt závaţnější význam (nebo je lze ve větší míře aplikovat/zohlednit).
2.2.2 Agilní metodiky, principy Tzv. agilní metodiky pro vývoj software jsou inovativní přístupy, které vychází z ortodoxního softwarového inţenýrství, na stranu druhou popírají některá dogmata v této oblasti. Cílem je pruţnější a efektivnější vývoj, minimalizovat riziko zadrhávání se v dílčích fázích vývoje, v co nejkratší době postupovat k cíli s ohledem na hlavní poţadavek vývoje – doručit fungující software, aplikace. Výrazným rozdílem mezi agilními a tradičními rigorózními metody jako jsou vodopádový či spirálový model, je v tom, ţe tyto narozdíl od rigorózních, které povaţují poţadavky za neměné, naopak změny poţadavků předpokládají [2]. Klíčové principy agilních metodik: inkrementální vývoj s co nejkratšími iteracemi přímá komunikace, nepřetrţitý kontakt se zadavatelem, časté - opakované testování, zdrojový kód jako spolehlivý nositel informace (potlačování dokumentačních činností) Logicky jsou agilní metodiky vhodné spíše pro projekty menšího rozsahu. Také s rostoucí velikostí vývojového týmu je jejich uplatnění náročnější. Nejznámější agilní metodiky: Extreme Programming, XP SCRUM Lean Development Feature-Driven Development, FDD Test-Driven Development, TDD Adaptive Software Development, ASD 18
2.3 Preferované principy pro řízení projektu Jak jiţ bylo zmíněno, vývojový tým má zkušenost s vyuţitím principů agilních metodik, a proto výsledná metodika obsahuje především prvky SCRUM a také KANBAN. I kdyţ princip těchto metodik je výrazně odlišný (zjednodušeně SCRUM = iterace, KANBAN = průtok), tak je počítáno s jakýmsi přepínáním mezi oběma přístupy ať jiţ pro celý projekt a tým, či pro vybrané celky (lidi). Meetingy Milníky
2.4 Podpůrné nástroje Pro řízení projektu byly pouţity především následující dva nástroje: OTRS1 pro evidenci stráveného času, problémů a chyb Devboard, jednoduchý nástroj zaloţený na projektu kanboard2. Tento nástroj tým zvolil právě s ohledem na snahu minimalizovat administrativu na únosnou míru vzhledem k časové dotaci projektu. Zároveň byla vyuţito propojení devboard a OTRS (automatizované přenášení vybraných informací do OTRS, které později slouţí i pro sestavování reportů provedených činností odběrateli). Jako další nástroje pro sdílení informací byly vyuţity wikipedie (dokuwiki) SVN pr osprávu zdrojových kódů dokumentové úloţiště (sdílené sloţky, Windows File server) Google Apps pro vzájemnou komunikaci (prezentace atp.)
1 2
OTRS – systém pro správu poţadavků (volněji přeloţeno), http://www.otrs.com Kanboard – jednoduchý nástroj pro vizualizaci úkolů, http://kanboard.net 19
2.5 Formulace cílů projektu Níţe uvedené cíle jsou povaţovány za klíčové cíle projektu a jejich nedodrţení bude znamenat jeho selhání: 1) V dohodnutý termín bude doručen produkt v rozsahu umožňující spuštění provozu. Funkcionalita produktu musí být minimálně v rozsahu, kdy lze některé chybějící funkce nahradit (dočasně) náhradním postupem (workaround) za předpokladu, ţe zvýšení nákladů na jejich pouţití nebudou v rozsahu, kdy by byla výrazně dotčena provozuschopnost call centra => faktor času potřebného pro provedení operace, ovlivnění souvisejících operací (např. díky zvýšení časové náročnosti pro konkrétní úkon prováděný všemi/mnoha operátory dojde k nemoţnosti generování reporů pro klienty v domluvených termínech). 2) Architektura systému a způsob implementace bude zohledňovat nutnost další rozvoje systému. Některé části systému související s uchováváním tzv. byznys informací budou připraveny na rošiřování v extrémně krátkých termínech. Typicky půjde o situaci, kdy klient předá novou dávku případů s dosud nepodporavanými typy informací. 3) V souladu s bodem 2 maximální snaha o normalizaci dat. Nerezignovat na příval nových typů informací a neukládat tyto infromace v nenormalizované podobě. Toto vede později k nutnosti parsovat data z těchto textových řetězců. Dalšími nevýhodami jsou např. nemoţnost validovat vstupní údaje jiţ během importu dat do datábází, nemoţnost vhodným způsobem provádět filtrování (výkonově nevýhodné filtrování pomocí klauzule LIKE) a nemoţnost zajištění plnohodnotné integrity dat. 8) Další cíle projektu: 1) Minimalizace nákladů na budoucí údržbu systému 2) Maximální využití používaných a nasazených technologií a postupů v jiných projektech. Výrazně sniţuje riziko nedodrţení termínu doručení produktu a také nákladů na budoucí údrţbu či rozvoj systému. Vzhledem k časové dotaci 20
bude riskantní bezpečně ověřit a pouţít technologie bez předchozích zkušeností. V případě, kdy se bude jevit jako ţádoucí pouţít technologie, se kterými členové týmu nebudou mít pdostatečné zkušenosti, můţe být vhodným krokem dodatečné rošíření projektového týmu o lidi s potřebnými zkušenostmi. 3) Striktní preference must have features. V návaznosti na klíčový cíl projektu č. 1 musí být jasně upřednostněna realizace úkolů pro doručení funkcionality, kterou nelze ani dočasně nahradit.
2.6 Projektový slovník Projektový slovník byl sestaven tak, aby obsahoval klíčové termíny pro snaţší dorozumění se nejen v rámci vývojového týmu, ale i pro komunikaci s odběratelem. Termín Kampaň Případ
Význam = client, významově smlouva = telecase, kontakt předaný objednatelem v rámci kampaně = telecase_package, skupina případů importovaná společně (nemusí Balík (případů) odpovídat skupině případů předaných společně objednatelem) pohled na data (část obrazovky, okna aplikace) potřebná pro provedení Volací karta úkolu operátorem Zákazník a údaje = oslovovaný subjekt (ososba/firma), kontaktní a jiné údaje oslovovaného subjektu zákazníka poţadovaná operace prováděná pro případ ať jiţ uţivatelem, tak i Úkol autonomním algoritmem je roven hodnotě jedné z poloţek číselníku, např. „Odeslat email“, Typ úkolu „Zavolat“ je roven hodnotě jedné z poloţek číselník, např. „Nezvedá telefon“, Výsledek úkolu „Nemá zájem“, „Odloţený hovor“ je roven hodnotě jedné z poloţek číselníku: Stav úkolu Vyřešený/Aktuální/Naplánovaný volací scénář - pro operátora Script
21
3 Návrh, implementace a testování 3.1 Případy užití Ve vymezeném rozsahu projektu uvaţujeme pouze následující typy uţivatelů: User (operátor) Team leader Administrator Samozřejmě jiţ nyní je jasné, ţe další role budou nutně vznikat po zahájení ostrého provozu společně s dalším rozšiřováním funkcionality systému, budou to např.: Reportér Importér (uţivatel odpovědný za kontrolu importovaných dat před jejich pouţitím)
22
Následující diagram se zaměřuje na dvě klíčové rolu: User a Team leader.
Obrázek 3.1: Use cases – User, Team leader Zdroj: Vlastní
3.2 Workflow V této kapitole jsou v návaznosti na případy uţití dále rozebrána některá konkrétní workflow. Tato workflow patří právě mezi ty, které nezbytně musí být doručeny pro pilotní provoz. Zároveň způsob jejich implementace bude mít velký dopad na efektivitu budoucích uţivatelů. Důraz při návrhu těchto workflow byl tedy kladen na maximální jednoduchost workflow, 23
minimalizaci počtu úkonů ze stranu uţivatele, dostatečnou míru abstrakce umoţňující pozdější řešení detailů, Níţe uvedené diagramy jednotlivých workflow byly vytvořeny pomocí Enterprise Architect.
3.2.1 Odchozí hovor Toto workflow bude uţivateli zřejmě zdaleka nejčastěji uţívaným v rámci celého systému. Jde vlastně o nosnou operaci v rámci níţ dochází ke kontaktu obou stran (nebo pokusu o kontakt). Samořejmě bude moţné zpracovat případ a iniciovat kontakt i jiným způsobem, ale to zde četnost těchto uţití očekávána řádově niţší.
Obrázek 3.2: Workflow 3 – Odchozí hovor Zdroj: Vlastní 24
Vybrané aktivity budou dále ještě více rozebrány, zde ale stojí za zmínku především aktivita „Získat případ“. Vlastní získání bude probíhat tak, ţe operátor poţádá o případ ke zpracování a systém na základě pravidel a dostupných dat sám rozhodne, který případ bude operátorovi předloţen. Klíčovými pro rozhodování (provádí algoritmus) bude: Vazba případ – operátor. Systém umoţňuje přidělovat případy jednotlivým operátorům. Toto je prováděno buď jiţ během importu nových dat klienta (v jehoţ průběhu jsou definovány případy jako entita), nebo dodatečně, ad-hoc. Preferována je první volba. V dalších fázích vývoje systému je uvaţováno i vytvoření samostatného nástroje pro správu případů ze strany uţivatelů. Existence naplánované aktivity (úkolu). Hovory i jiné úkoly prováděné v rámci případu mohou být naplánovany na konkrétní datum a čas. Algoritmus uvaţuje i typickou činnost operátora a typickou dobu práce s jedním případem, proto i zde můţe být případ s existujícím úkolem nabídnut ke zpracování s malým předstihem (maximálně v řádu jednotek minut). Toto platí i „z druhé strany“, kdy případ můţe být nabízen s malým zpoţděním (opět typicky několik aţ 15 min). Hodnoty pro velikost časové tolerance jsou přizpůsobitelné (v rámci systému, ne jednotlivě v rámci případů či balíků případů). Aktuální pracovní den a čas. Doba pro zpracování případů (přesněji pro provedení kontaktních operací jako jako jsou telefonické hovory) je přesně vymezena tak, aby ke kontaktům v souladu s dohodou s klienty (např. nechceme
lidem
volat
večer,
coţ
je
častý
nešvar
při
činnosti
telemarketingových firem). Pořadí (či id) případu. Tento atribut je doplňujícím činitelem pro určení případu ke zpracování (není-li rozhodnuto pomocí předchozích).
3.2.2 Vyhledat a zpracovat úkol (workflow) V některých situacích můţe být vhodné umoţnit uţivateli vyhledat a zpracovat konkrétní případ. Iniciace (výběr případu) je tedy více na uţivateli, který pomocí nabízeného filtru provede výběr jednoho či více případů, a ty pak jedotlivě zpracuje (bez pouţití fce „Získat případ (z fronty)“). Poslední část zpracování případu (Vytočit 25
hovor či provést jinou operaci, zaznamenat výsledek a určit další krok) je jiţ shodná s předchozím workflow.
Obrázek 3.3: Workflow 1 – Vyhledat a zpracovat úkol (zavolat) Zdroj: Vlastní
Funkcionalita pro vyhledání, tedy nabízené parametry filtru, musí být dostatečné pro (základní práci) vyhledání případu. Jelikoţ je tento postup očekáván jako výrazně méně často pouţívaný, v první fázi se jako dostatečné jeví tyto parametry: Kontaktní osoba – jméno, příjmení Kontaktní firma – název Město Typ úkolu
26
Komentář k parametrům filtru: Nabídnout optimální parametry filtru je obecně často boj mezi na jedné straně úplností – maximálními moţnostmi filtru, a na druhé straně jednoduchou pouţitelností pro uţivatele. S rostoucí komplexností vyhledávaných entit a mnoţství jejich vzájemných vazeb je třeba často volit určitá, i zásadní zjednodušení. Zde bude např. uţito fulltextové vyhledávání, které na jedné straně zvyšuje poţadavky na výkon systému či prodluţuje čas zpracování poţadavku, na druhé straně je pro uţivatele komfortnější. Je nutné také neopomenou zvýšenou nejednoznačnost výsledku, jelikoţ nelze jednoznačně určit, jaký textový řetězec v konkrétním atributu entity hledáme. Níţe je připojen náhled jednoduchého filtru aplikace Telesales Client pro vyhledání případů pomocí klíčových parametrů:
Obrázek 3.4: Telesales Client – Filtr pro vyhledávání případů Zdroj: Vlastní
3.2.3 Zpracování příchozího hovoru Zpracování příchozího hovoru bude z hlediska četnosti uţití nezanedbatelným workflow. Stejně jako u předchozího workflow zde je klíčovou aktivitou vyhledání případu. Po vyhledání a otevření (přesněji zobrazení, nezaměňovat se stavem případu) budou prováděny další potřebné kroky v kontextu konkrétního případu.
27
Obrázek 3.5: Workflow 2 – Zpracování příchozího hovoru Zdroj: Vlastní
3.3 Testovací případy Jiţ v počátku by měly být s ohledem na očekávanou funkcionalitu navrţeny vhodné testovací scénáře. Především v pojetí agilních metodik vývoje software podstatnou roli zastává sám vývojář, který velice dobře rozumí vyvíjené funkcionalitě/celku a měl by být schopen navrhnout vhodné testovací případy. V závislosti na zkušenosti dotčených autorů vytvářených algoritmů a jejich testerů je moţné odpovědnosti za podobu těchto 28
testovacích případů různě přesouvat. Testování jako takové je pro vývoj a hlavně následné doručení software nezbytné bez ohledu na jeho formu a rozsah. S ambicí důsledně testovat přichází nutnost odpovídající přípravy na tuto činnost. Ta typicky zahrnuje sestavení plánu testování (test plan), určení objektu(ů) a rozsahu testování, nechybí ani popis prostředí pro testování (test design, test spec, test case, ..). Pro daný projekt se neobejdeme bez určení všch náleţitostí pro provedení testování, ovšem formální stránka bude velice zjednodušena. Předpokládáme vytvoření testovacího prostředí z velké části odpovídající budoucímu nasazení. U testovacích dat se vzhledem k chybějícím informacím od zadavatele dá očekávat pouze jakási podobnost. Nosné atributy testovacích dat ale budou plně odpovídající. Protoţe projekt vyuţívá principy agilních metodik pro vývoj software, nelze termíny testování s větším časovým předstihem pevně určit. Níţe jsou připojeny vybrané stěţejní testovací případy: TC01 - spuštění aplikace 1) Spustit aplikaci | zobrazeno okno pro přihlášení 2) uţivatel: demo heslo: demo Server: „Telesales aplikační T server“→ Login| zobrazena hlavní obrazovka (není aktivní „pohled“)
TC02 - Odchozí hovor a záznam výsledku úkolu 1) TC01 2) menu → „Volací karta“, získat případ, který má jediný aktuální úkol „Zavolat“ (ţádný naplánovaný) 3) vloţit: a. Výsledek úkolu = „Ţádost o informace“ b. Typ nového úkolu = „Odeslat email“
29
c. Datum r. = výchozí (D+1) d. Popis nového úkolu: „odeslat email“ 4) Uloţit | V seznamu úkolů: nejnovější „vyřešený“ úkol = „Zavolat“, aktuální úkol = „Odeslat email“, Datum zap. = D+1, Popis: „odeslat email“
TC03 - Odchozí hovor a záznam výsledku úkolu + další naplánovaný úkol 5) TC01 6) menu → „Volací karta“, získat případ, který má jediný aktuální úkol „Zavolat“ (ţádný naplánovaný) 7) vloţit: 8) Výsledek úkolu = „Ţádost o informace“ 9) Typ nového úkolu = „Odeslat email“ 10) Datum r. = výchozí (D+1) 11) Popis nového úkolu: „odeslat email“ 12) Vytvořit plánovaný úkol = ano 13) Typ plánovaného úkolu = „Zavolat“ 14) Datum r. = výchozí (D+2) 15) Popis plánovaného úkolu: „Zavolat“
30
16) Uloţit | V seznamu úkolů: nejnovější „vyřešený“ úkol = „Zavolat“, aktuální úkol = „Odeslat email“, Datum zap. = D+1, Popis : „odeslat email“, plánovaný úkol = „Zavolat“, Datum zap. = D+2, Popis : „Zavolat“
Doplnění testovacích případů v anglickém jazyce (zdroj: původní materiály vývojového týmu).
Identification: TC1 Name: Simple calling process with success Primary actor: Operator Ouptut: Telecase is set with task Agreement Operator starts the application and selects Telecase. Application should provide next item in queue and operator validates data. After the simulated call he selects the result of agreement as „Agreement“ and selects next task to be Agreement with commentary. Identification: TC2 Name: Calling process with unsuccessful call Primary actor: Operator Ouptut: Telecase is set with task Call Operator starts the application and selects Telecase. Application should provide next item in queue and operator validates data. After the simulated call which was unsuccessful he selects the result of agreement as „Call“ and selects next task to be Call with future date and commentary. Identification: TC3 Name: Finding telecase by input data Primary actor: Operator Ouptut: Telecase is found Operator starts the application and selects Telecase List. In the filter the operator fills in the requested filtering data. 31
The operator then submits the filter and application should provide him relevant feedback.
Uvedené testovací případy byly v průběhu vývoje dále doplňovány tak, aby zohlednili aktuální funkcionalitu (reakce na změny v průběhu vývoje vyplývající z neúplné specifikace funkcionality).
3.4 Databázový engine Vzhledem k jasnému vymezení na úrovni poţadavku odběratele (kapitola 1.3.7) bude pro provozování klíčových databází systému (tedy obsahujících byznys data) pouţit stávající MS SQL Server 2014. Tento server bude také zajišťovat generování a distribuci uţivateslkých reportů (SSRS). Pro další databáze např. dohledového systému bude moţné vyuţít i jiné platformy (např. MySQL), v kontextu nákladů jsou uvaţovány open-source či free verze databázových enginů.
3.5 Databáze Časová dotace pro vytvoření koceptuálního modelu byla vzhledem k časovému limitu projektu a především vzhledem v tomu, ţe vývojový tým záměrně pouţil zjednodušený koncept jiného systému, s jehoţ vývojem měl dlouholeté zkušenosti, výrazně sníţena. Níţe je uveden první podoba konceptuálního modelu, se kterou tým pracoval v počátku projektu. Pro sestavení modelu byl pouţit lineární textový zápis: client (client_id, name, ico, description, state, street, city, zip, insert_user, insert_date) telecase_package (telecase_package_id, client_id, ref_number, description, state, insert_user, insert_date) client_has_case_package (client, telecase_package , client_id, client_id) telecase
(telecase_id,
telecase_package_id,
ref_number,
company_name, ico, dic, phone, mobil, email, www, street ,
client_ref_number,
city,
zip,
district,
person_name, post, state, description, actual_task_id, insert_user, insert_date) telecase_package_has_cases
(telecase_package,
telecase_package_id) 32
telecase,
telecase_package_id,
Dále byly pouţity diagramy aktivit v kombinaci s vybranými atributami některých klíčových entit a číselníky hodnot, coţ mělo pomoci i k vhodnému návrhu těchto číselníků.
Obrázek 3.6: Diagram aktivit 1 – práce s případem Zdroj: Vlastní
33
Obrázek 3.7: Diagram aktivit 2 – práce s případem Zdroj: Vlastní
Náhled na logický datový model je k dispozici v příloze 1. Pro jeho sestavení byl vyuţit Enterprise Architect. SQL skripty pro definici databáze byly vytvářeny pomocí EA a právě tohoto logického modelu. Jak dokumenntace (EA zdrojové soubory), tak i výsledné SQL skripty byly uchovávány v repozitáři zdrojových kódů. V případě změn datového modelu byla prefererovanou cestou nejdříve úprava EA logického modelu, export (a zaverzování) SQL skriptů a poté nasazení změn pomocí Jenkins. V pozdějších fázích vývoje bylo někdy obtíţné tento postup dorţet (nové nasazení znamenalo mohlo ovlivnit jiné činnosti, vyšší časovou náročnost), proto byl aplikován postup „z druhé strany“ – manuální provedení změny definice a následně úprava EA log. modelu. V takovém případě existovalo vyšší riziko vad SQL skriptů, které byly ověřeny aţ při příštím úplném nasazení systému (byly poprvé pouţity SQL skripty generované na základě EA log. modelu). Je moţné konstatovat, ţe v průběhu projektu došlo několikrát, 34
ale pouze k pouze menším závadám, které byly odhaleny právě při nasazení celého systému.
Serverová aplikace 3.5.1 Běhové prostředí Volba běhového prostředí serverové aplikační vrstvy bude poměrně jednoduchá. Vzhledem k dlouhodobým zkušenostem vývojového týmu s provozem mnoha instancí Oracle GlassFish Server (několik desítek serverů v 10 zemích) zde nebude vhodné utrácet čas hledáním alternativ. GlassFish je aplikační server, původně vyvíjený společností Sun Microsystems, momentálně jej zaštituje společnost Oracle Corporation. Je k dispozici jako opensource. Program je poskytovaný cestou dvou typů licence: Common Development and Distribution License (CDDL) GNU General Public License (GPL). GlassFish je referenční implementace aplikačního serveru, tedy je k dispozici jako modelové řešení. V současnosti je podporována verze Java EE 7. [9] Z pohledu HA (High Availability) je moţné také vytvořit z několika serverů GlassFish cluster. Aplikační server bude provozován za pomoci operačního systému Ubuntu (LTS v aktuální verzi).
3.5.2 Programovací jazyk serverové aplikace a použité frameworky Volba platformy pro vývoj serverové aplikace je další poměrně jednoduchá otázka. Vzhledem ke zkušenostem vývojového týmu je jednoznačně vhodné vyuţít platformu Java EE. Pro objektově-relační mapování a propojení databázových objektů s aplikací bude vyuţit Hibernate ORM Framework [15].
Integrace tohoto frameworku zajistí
výrazně efektivnější práci s databázovými objekty.
35
Dalším významným frameworkem, který bude vyuţit, je Spring Framework. Spring je modulární framework, který umoţňuje vyuţít pouze danou část v kontextu řešeného problému. Účelem je výrazné zjednodušení návrhu enterprise aplikací na platformě Java. Umoţňuje se vývojářům zaměřit na architekturu aplikace namísto na technologie [16]. Vývojové prostředí je spíše volbou konkrétního vývojáře, kdy vhledem k dlouhodobému vyuţívání Netbeans IDE nebude opět důvod toto měnit. Netbeans IDE obsahuje sadu nezbytných vývojářských nástrojů, šablon, usnadňuje práci s repozitáři zdrojových kódů, testování, aktualizace balíčků ad. [17]
3.6 Klientská aplikace V souladu se zvolenou architekturou systému (třívrstvá: db – server - klient) by klientská aplikace měla komunikovat pomocí rozhraní poskytované serverovou aplikací. Tedy v ţádném případě nebude přímo přistupovat do (MS SQL) databáze. Rozsah logiky implementované v klientské aplikaci bude významný, zjednodušeně řečeno půjde o polotučný klient. Klientská aplikace nebude řešit práci s frontou případů, ale na druhou stranu implementuje pravidla a omezení pro jednotlivé workflow. Příkladem můţe být očekávaná komplexnost záznamu výsledku hovoru a naplánování další operace. Zde by bylo moţné toto řešit také na straně serveru (serverové aplikace), ale při větší komplexitě by toto mohlo vyţadovat výrazně větší náročnost pro komunikaci
klient-server
s neţádoucím
dopadem
na
uţivatele
(čas,
odezvy
uţivatelského rozhraní).
3.6.1 Programovací jazyk klientské aplikace a použité frameworky Volba platformy pro vývoj klientské aplikace není jednoduchá. Vývojový tým má zkušenost s vytvářením frontend aplikací pomocí C#, Adobe Flex (běhovým prostředím je internetový prohlíţeč s FlashPlayer pluginem), Java (SE). Do tohoto výčtu byly zahrnuty pouze platformy odpovídající současné strategii týmu při vývoji nových aplikací.
36
Níţe přehled hlavních kritérií pro rozhodování o výběru platformy pro vytvoření Telesales Client.
Zvaţované moţnosti
C#
Adobe Flex
Java SE
SOAP
SOAP, AMF
REST (JSON)
ClickOnce [19]
Internetový prohlíţeč
ftp
výborné
problematické,
problematické,
obtíţná
obtíţná
zastupitelnost
zastupitelnost
dobré
dobré
komunikace klient-server
Distribuce klienta směrem k uţivateli
Kapacitní zajištění (vývojáři)
Kvalitativní zajištění
výborné
(vývojáři)
Obrázek 3.8: Telesales Client – hlavní kritéria pro volbu platformy Zdroj: Vlastní
37
Ukázka části API serverové aplikace – zde pro klienty komunikující pomocí SOAP:
3.6.2 Uživatelské rozhraní Uţivatelské rozhraní je pro uţivatele vţdy to podstatné. Často teprve aţ poté, co mají moţnost prohlédnout si „obrazovky“ systému, ohmatat si funcionalitu, teprve tehdy jsou schopni poskytnout vývojářům odpovídající feedback. Snahou vývojového týmu by tedy mělo být prezentovat podobu uţivatelského rozhraní spolu s popisem funkcionality co nejdříve. Můţe to znamenat znatelnou úsporu nákladů, eliminaci nedorozumění mezi uţivatelem a vývojářem. Vizualizace usnadňuje i vzájemnou komunikaci mezi spolupracujícími vývojáři.
38
Pro jednoduchý design uţivatelského prostředí existuje mnoho nástrojů (vč. tzv free či opensource). Vývojový tým si pro tyto účely oblíbil nenáročnou open-source aplikaci Pencil (http://pencil.evolus.vn/). Níţe připojeny náhledy na prvni návrhy uţivatelského prostředí pro vyjasnění funkcionality aplikace.
Obrázek 3.9: Telesales Client – návrh uţivatelského rozhraní zákl. obrazovky Zdroj: Vlastní
39
Obrázek 3.10: Telesales Client – návrh uţivatelského rozhraní pro výsledky vyhledávání Zdroj: Vlastní
S vědomím vlivu uţivatelského rozhraní na „vztah“ uţivatele k systému, efektivitě jeho práce, věnoval tým podstatnou část času návrhu klíčových obrazovek. Např. uţiv. rozhraní pro práci s konkrétním případem bylo několikrát zásadně přepracováno (zčásti i díky změnám struktury dat a potřeby reagovat informace, které bylo potřeba nově zobrazovat uţivateli). 40
Přestoţe systém byl vyvíjen pro zákazníka ze Slovenska, od počátku byla implementována podpora i pro angličtinu a ruštinu. To z důvodu, ţe náročnost byla rel. nízká a jiţ v počátku byl systém navrhován jako poměrně flexibilní a dobře pouţitelný i pro jiné zákazníky.
Obrázek 3.11: Telesales Client – od počátku byla implementována podpora pro více jazyků Zdroj: Vlastní
Okno detailu případu prošlo mnoha změnami, níţe poslední verze. Pro lepší orientaci uţivatele pouţito grafické odlišení jednotlivých oblastí: oblast pro výběr balíků případu oblast se základními informacemi o případu (v levé části, součástí také prvek typu seznam pro další atributy případu). V náhledu viditelná jedna ze slabin návrhu – nedostatečně normalizovaná data (telefon 1-3). Vhodná podoba modelu by volila definovat entitu telefon a kardinalitu vztahu 1..n. toto byl jeden z kompromisů akceptovaných vývojovým týmem. ikony pro nejvíce pouţívané operace (pro záznam výsledku do historie případu a naplánování dalšího kroku - úkolu) oblast pro záznam provedené operace (sestává ze dvou kroků: záznnam výsledku + naplánování dalšího kroku) oblast pro naplánování více úkolů do budoucna (jeden další úkol je vţdy povinný, viz předchozí bod) výčet událostí – historie případu 41
oblast pro výběr dalších operací s případem
Obrázek 3.12: Telesales Client – okno detailu případu (konečná podoba) Zdroj: Vlastní
Při hledání optimálního rozloţení bylo vycházeno i z doporučení dle [1].
3.7 Generování a distribuce reportů Zajištění generování uţivatelských reportů nebylo pro projekt prioritním úkolem. S vědomím toho, ţe některé reporty bude moţné generovat ad-hoc (uţivatel předá jako servisní poţadavek), byly klíčové reporty připravovány aţ během pilotního provozu. Pro tyto účely byly vyuţity SSRS3 a nástroj Report Builder (pro definici reportů). Distribuční kanály byly pouţity dva:
3
SQL Server Reporting Services, serverová technologie od společnosti Microsoft pro zajištění generování reportů. 42
Email – byly definovány distribuční skupiny a/nebo pro některé reporty pouţity emailové adresy konkrétních příjemců Webové rozhraní – uţivatel přistupuje k webovému rozhraní SQL serveru Typickými reporty byly statistiky provedených operací, případů a jejich stavů atp. Pouţitým formátem byl pdf a xls (pro rozsáhlejší seznamy nebo pro data, se kterými chtěli uţivatelé dále pracovat pomoci MS Excel).
Obrázek 3.13: Telesales Client – Přehled otevřených případů (report) vytvořený pomocí SSRS (náhled přes webový prohlíţeč) Zdroj: Vlastní
3.8 Nástroj pro importy klientských dat Hlavním úkolem je zajistit import dat předávaných klienty zákazníka do systému. Kritickými faktory jsou: Čas provedení importu Schopnost reakce na změny formátu dat Klientskými daty jsou míněny především balíky případů, v dalším období po spuštění pak také importy dodatečných informací k jiţ existujícím příopadům (případně změny jiţ dříve importovaných informací). Jako nosnou technologii pro provádění importů vybral vývojový tým MS SQL Server Integration Services [23]. Vyuţití SSIS je výhodné právě v případě výstavby výkonných 43
řešení podporujících ETL procesy (extraction, transformation, loading). V případě projektu Telesales softwware půjde o provádění opakovaných importů, kdy zdrojem jsou data uloţená v souborech (např. csv, xls, ..). SSIS umoţňuje psát zdrojový kód pomocí C#, díky čemuţ jsou k dispozici další moţnosti oproti vyuţití pouhého T-SQL.
3.9 Sestavování systému Sestavení systému je proces, který zahrnuje především transformaci zdrojového kódu do spustitelného binárního kódu (sestavení software). Součástí sestavení ale mohou být operace vedoucí např. k finální kompletaci dokumentace ze zdojových souborů a další podobné operace. Pro optimální sestavování systému je třeba zohlednit/sledovat především: Sledovat minimalizaci vstupu vývojáře – automatizace Efektivitu procesu – ideálně kaţdý zdrojový soubor zpracovat pouze jedinkrát (sestavit modul jedinkrát a následně opakovaně vyuţít) Sestavovat systém tak často, jak je moţné (můţe vést k včasnému odhalení problémů) Sestavovat celý systém (ne pouze moduly či části) Umoţnit jednoduché pouţití Typické problémy při sestavování (konfiguraci sestavovacích skriptů - postupů) je nevhodné pořadí sestavení (modulů či mezivýsledků, např. „object“ souborů). Pomocí build tools lze běţně zajistit také generování balíčků pro distribuci, generování dokumentace, a spouštění testů. Níţe následuje výčet technologií/frameworků/nástrojů pouţitých pro sestavování Telesales software: Jenkins – rozsáhlý open-source server pro průběţnou integraci [25] Apache Ant – knihovna v jazyce java a nástroj pro řízení sestavování, umoţňuje automatizaci kompilace, testování a generování výsledných balíčků [26]. Je také výchozím nástrojem pro sestavování v Netbeans IDE, alternativou k nástrojům jako Maven či Make. 44
MS Build – systém pro sestavování spustitelných souborů v rámci prostředí MS Visual Studio SQLCMD a OSQL - utility pro spouštění Transact-SQL příkazů či skriptů Jak probíhalo sestavení Telesales software: Celé sestavení bylo zajištěno pomocí Jenkins jobů (jeden vrcholový řídící job a další pro jednotlivé části). Výsledek provádění jobů byl vyhodnocován, na úrovni Jenkins jobu byly testovány návratové hodnoty doručované z podřízených jobů či dávkových souborů. Systém byl sestaven na základě tří kroků: 1) Příprava databáze (databáze byla pouze nasazována formou spouštění T-SQL skriptů pomocí utilit SQLCMD a OSQL) 2) Sestavení serverové aplikace (v jazyce java) pomocí Apache Ant 3) Sestavení frontend aplikace Telesales Client (C#) Ukázka skriptu pro řízení sestavení: def jobs_names = ["TelesalesBackend (build)", "TelesalesClient (build)"]
def version = "SK_R"
def general_build_result = SUCCESS def single_build_result
for (job_name in jobs_names) { //out.println job_name ignore(UNSTABLE)
{
single_build_result
=
build(job_name,
VERSION_TO_BUILD: version) } general_build_result
=
general_build_result.combine(single_build_result.build.getResult()) }
45
//out.println general_build_result build.setResult(general_build_result)
Komentář: logika pro sestavení byla umístěna v dalších dávkových souborech, v této konkrétní ukázce záměrně chybí sestavení databáze. Nasazení databází prováděné pomocí T-SQL skriptů bylo provedeno pouze jako součást nasazení (Jenkins „deploy“ jobů). Změnové T-SQL skripty byly ve fází vývoje na testovacím prostředí aplikovány manuálně (po spuštění pilotního provozu jiţ autoomaticky jako součást Jenkins jobu). Náhled řídící obrazovky Jenkins:
Obrázek 3.14: Sestavení a nasazení Telesales software - Jenkins řídící obrazovka Zdroj: Vlastní
3.10 Nasazování systému Pro nasazování systému platí jiţ uvedené v předchozí kapitole. Nosným nástrojem byl Jenkins. Na rozdíl od sestavování systému, kde byl umoţňen přístup více členům týmu, byly pro moţnost sestavování pouţity větší restrikce.
3.11 Testování Testování software je dnes poměrně široká disciplína, kterou se zabývá mnoho specialistů a softwarovým vývojářům (autor chápe i čisté testery specialisty jako vývojáře, kteří se přímo podílejí na vytváření produktu) je k dispozici velká nabídka odborné literatury, a dalších online zdrojů informací. Přístupy k testování software se 46
liší jak z hlediska metodiky, tak i rozsahu. Mnoho vývojářů inklinuje spíše k menšímu rozsahu testování (ano, návrhy testovacích scénářů, kritérií jiţ není tou kreativní činností). V případě nevhodně navrţených procesů pro zajištění testování či při nevhodném pouţití testovacích nástrojů můţe náročnost vlastního provádění testování výrazně vzrůstat. Je moţné vzpomenout paralelu ohledně úspěšnosti projektů, kdy jejich transparentnost, vysoká přizpůsobivost okolním podmínkám, časté inspekce stavu výrazně zvyšují šance na dosaţení plánovaných cílů. Stejně tak příliš ambiciózní cíle testování mohou znamenat postupné opouštění i z důvodu nedostatečných kapacit na jeho zajištění. Pro mnoho vývojových týmu je jedním ze zaklínadel např. tzv. code coverage, tedy míra pokrytí zdrojových kódu z hlediska existence příslušných testovacích rutin. Míra pokrytí je pak typicky sledována na základě více kritérií [22]: Pokrytí řádků kódu (statement/line coverage) Pokrytí hran (desicion/branch coverage) Pokrytí podmínek (condition coverage) Pokrytí cest (path coverage) Postupem času vznikaly a vznikají další metriky pro pokrytí zdrojového kódu, např.: Pokrytí funkcí (function coverage) Pokrytí relačních operátorů (relation operators coverage) Pokrytí cyklů (loop coverage) a další Přesně určená míra pokrytí bývá často jedním z interních limitů vývojových týmů pro uvolnění software (typicky jednotlivých celků) k dalšímu manuálnímu testování či vůbec směrem k jeho uţivatelům.
3.11.1 Kategorizace testování V závislosti na pohledu je moţné testování různýmm ppůsobem kategorizovat. Testování lze dle [6] rozdělit na statické a dynamické, kdy statickým testováním rozumíme analýzu zdrojového kódu a dokumentace bez vlastního provádění algoritmů, dynamickým pak analýzu aplikací, kdy jsou tyto spouštěny. Statické testování je
47
prováděno také typicky jiţ vývojářem v okamţiku vzniku algoritmu (testování jeho jednotlivých částí). V projektu Telesales software bylo vyuţíváno jak statického, tak i dynamického testování. Za statické testování je pak moţné povaţovat i prováděné přezkoumání změn zdrojového kódu (Code Review4) před jeho uloţením do sdíleného repozitáře zdrojových kódů (zde SVN). Tuto techniku vývojový tým vyuţívě běţně jako standardní součást softwarového vývoje. Z pohledu interakce testera lze testování (dynamické) rozdělit na manuální a automatizované. Během manuálního testování tester postupuje především dle testovacího případu (test case), sám pak provádí vyhodnocení jednotlivých kroků i celého testu. Doménou manuálního testování je především simulace uţití aplikace uţivatelem. I pro testování grafického (uţivatelského) rozhraní v současnosti existují nástroje, které umoţňují často dosáhnout vyšší míry automatizace provádění testů a tedy obecně ve výsledku vyšší spolehlivost a niţších nákladů. Příkladem můţe být Selenium IDE [21] často vyuţívaný pro testování uţivatelského rozhraní webových aplikací. Jde v podstatě o nástroj, který umoţní zaznamenat kroky uţivatele při pouţití aplikace a výsledky (stav grafických prvků) a poté je automaticky opakovat a provést srovnání se zaznamenými výsledky (pro úspěšnost testu je očekávána shoda). V průběhu projektu bylo prováděno automatické i manuální testování. V souvislosti s automatickým testováním byly prováděný především jednotkové a funkční testy, kdy k tomuto účelu byly vyuţívány příslušné frameworky pro platformu java a C#5. Pro manuální testy byly sestaveny testovací případy (kap. 3.3). Logicky v počátku vývoje byly uplatňovány spíše automatické testy (jednotkové -> funkční) a teprve s odstupem jak vznikala funkcionalita a bylo moţné si na produkt „sáhnout“, teprve přišly na řadu komplexnější (automatické funkční i manuální) testy. Manuální komplexní testy byly prováděny termonech domluvených v rámci status meetingů v okamţiku, kdy byla dokončena a připravena nová funkcionalita systému.
4
CR – Code Review, vývojáři často pouţívaná technika pomáhající zvyšovat kvalitu kódu. Vedlejším, ale podstatným přínosem je také předávání znalostí mezi vývojáři. Autor zkoumaných změn tyto prezentuje a případně obhajuje potenciálně slabá místa (reaguje na dotazy vývojáře provádějícího review). 5 Pro automatizované testování byly vyuţity např. frameworky JUnit pro platformu java (http://junit.org/) a Unit Test pro C# (https://msdn.microsoft.com/en-us/library/dd264975.aspx). Pro funkční testování frontendové aplikace pak např. specflow (http://www.specflow.org/) 48
Z pohledu znalosti testera o objektu testování lze dále odlišit Testování bílé skříňky (White box testing). Tester má dostupné veškeré informace včetně zdrojových kódů. Má díky tomu moţnost testovat všechny průchody kódem, vystavit testované algoritmy většímu stressu – např. zadávat neočekávané vstupní hodnoty či volit nečekané kombinace. Testování černé skříňky (Black box testing). Tester nahlíţí na testovaný objekt jako najakousi černou skříňku bez znalosti jejího obsahu. Sleduje, jaké výstupy jsou navraceny v reakci na jeho vstupy. Testování šedé skříňky (Grey box testing). Jde o kombinaci obou předchozích. Tester nemá k dispozici veškeré informace, zdrojový kód, ale můţe po předávání vstupů ověřovat chování např. přímo pomocí sledování změn dat (přístup do databáze přímo či zprostředkovaně pomocí jiných nástrojů/systémů).
Typicky
má
dále
k dispozici
např.
(interní,
neuţivatelskou) dokumentaci jako UML diagramy popisující architekturu (strukturní diagramy, structural diagrams) či chování (diagramy chovaní, behavioral diagrams), případně diagramy interakce (interaction diagram) daného software [27] [28]. Vývojovým týmem byly široce vyuţívány všechny uvedené kategorie testování. Testování černé skříňky se částečně účastnili i budoucí uţivatele systému, které umoţnilo: 1) Připravit budoucí uţivatele a seznámit je nenásilnou formou s produktem ještě před vlastním oficiálním předáním. Uţivatelé měli k dispozici dokumentaci ve formě „quick guide“, tedy uţivatelského manuálu rozčleněného na oblasti, kde z hlediska formy silně převládají grafické prvky a rozsah textových infromací je minimální. Před zahájením testování byli tito budoucí uţivatelé také v nezbytné míře zaškoleni formou prezentace (videokonference za vyuţití připojení k uţivatelově prac. stanici a předvedení základní operací v frontend aplikaci). 2) Získat co nejdříve informace od budoucích uţivatelů pomocí této zpětné vazby. Ideálně jiţ v okamţiku, kdy je připravena jakákoliv pouţitelná část systému – z pohledu uţivatele a moţnosti provést konkrétní uţivatelské operace, je, 49
v souladu s agilním přístupem k vývoji software6, vhodné získat první připomínky
uţivatelů.
Často
to
znamená
podstatnou
úsporu
času:
nepokračujeme „slepou“ cestou, okamţitě reagujeme vhodnými úpravami. Získané podněty z testování budoucími uţivateli byly vţdy bezprostředně vývojovým týmem zpracovány (roztřidění připomínek, určení typu – incident, RfC dle ITIL7, určení prioreity a vazeb na další úkoly či chyby). Jedním z cílů pro řízení projektu bylo i udrţení přiměřeného počtu otevřených úkolů (chyb). Byly prováděny integrační testy za vyuţití dříve zmíněného nástroje Jenkins [25]. Načasování provádění integračních testů se měnilo v průběhu času: zpočátku byla frekvence velice nízká (nebylo mnoho co integrovat), později především s blíţícími se milníky (ať jiţ plně interními nebo ty, které se vztahovaly k prezentacím, komunikaci se zákazníkem, budoucími uţivateli). Akceptační testování, tedy testování na základě akceptačních kritérií, bylo prováděno s aţ s malým odstupem před ukončením první vývojové fáze před předáním do pilotního provozu. Samozřejmě bylo nutné kalkulovat s rizikem velkých neshod po provedeních těchto testů, ale díky kritickému nedostaktu potřebného času toto bylo jedním z akceptovaných rizik projektu.
3.11.2 Dimenze kvality Při posouzení produktu či jeho částí je moţné vyuţít některou z metodik jako jsou např. FURPS(+)8 nebo MDIS [29]. Principem je podívat se na software z různých hledisek, v rámci FURPS to jsou např.:
6
Jednotlivci a interakce před procesy a nástroji.. Nejúčinnějším a nejefektnějším způsobem sdělování informací vývojovému týmu z vnějšku i uvnitř něj je osobní konverzace (Agilní Manifest http://www.agilemanifesto.org/) 7 Information Technology Infrastructure Library (ITIL) je soubor praxí prověřených konceptů a postupů, které umoţňují lépe plánovat, vyuţívat a zkvalitňovat vyuţití informačních technologií (IT), a to jak ze strany dodavatelů IT sluţeb, tak i z pohledu zákazníků (zdroj: https://cs.wikipedia.org/wiki/Information_Technology_Infrastructure_Library) 8
Autorem metody FURPS je Hewlett-Packard, tat ospolečnost ji vyvinula z důvodu potřeby systematicky ověřovat kvalitu software. Název vychází z jednolivých dimenzí: Functionality, Usability, Reliability, Performace a Supportability 50
Funkcionalita. Jakým způsobem software podporuje byznys procesy, v jaké míře splňuje poţadavky uţivatelů? Pouţitelnost. Jakou „námahu“ musí vynaloţit uţivatel při pouţívání daného software? Jsou hodnoceny i další aspekty jako dojem uţivatele. Spolehlivost. Sledována je četnost chyb, jejich závaţnost (v případě SaS9 to můţe být např. i doba reakcí při řešení servis poţadavků). Mohou být sledovány i další parametry spolehlivosti jako schopnost obnovy po výpadku (mnoho zákazníků vyţaduje tzv vysokou dostupnost systému – HA, kdy v případě selhání systému zajišťujje sluţbu „náhradní“ systém, v případě selhání serveru náhradní server) Výkon. Typicky jsou sledovány odezvy systému, je monitorován síťový provoz, počty dotazů (do databází či aplikační serverů) atd. Udrţovatelnost. Hodnotí se úroveň podpory software, schopnosti např. udrţovat systém kompatibilní se současnými technologiemi v návaznosti na nutnost interakce s dalšími systémy (např. veřejné rejstříky a podpora protokolů či formátů pro výměnu dat) Podle MDIS [29] je „kaţdý projekt natolik specifický (svým obsahem, rozsahem, dobou řešení, prioritami, znalostmi uţivatelů a řešitelů, pouţívanými technologiemi a dalšími charakteristikami), ţe univerzální detailní návod postupu v jednotlivých krocích projektu můţe řešitele svést z cesty racionálního uvaţování a k hledání a pouţívání analogií i tam, kde nejsou“. Jiţ při prvních úvahách a při sestavování plánu, priorit bylo vývojovému týmu jasné, ţe díky jasně danýmn omezením bude nutné hledat mnoho kompromisů. Cílem bylo najít takový mix kompromisů, který umoţní pilotní provoz systému za pro odběratele stále ještě přijatelných podmínek. Součástí dohody byla např. akceptace výrazně delších časů pro provedení servisních úkonů (importy klientských dat)
9
SaS – Software as Service. Software není dodáván jako tzv. krabicové řešení, ale součástí dodávky jsou i poskytované další sluţby (např. pravidelné úkony provádění pracovníky dodavatele). 51
akceptace chybových stavů za předpokladu, ţe bude k dispozici vhodný náhradní postup. V tomto případě bylo zvaţováno i nahrazení některých nepouţitelných funkcí systému časově výrazně náročnějším manuálním postupem akceptace niţší neţ cílové dostupnosti systému jako celku (sníţení aţ o jednotky procent). Sníţení úrovně dostupnosti mohlo být zapříčiněno např. nutností odstávek systému z důvodu nasazování opravných balíčků nebo adhoc zásahů do databáze. S otázkou sníţení dostupnosti systému souvisí i jiţ zdříve zmíněná konfigura prostředí. Chybějící třetí prostředí (nebylo uvaţováno samostatné testovací a produkční prostředí) v okamţiku spuštění pilotního provozu mholo být zásadní komplikací, protoţe by nebylo moţné současně vyvíjet a testovat software před nasazením opravného balíčku. Retrospektivně lze konstatovat, ţe k závaţné komplikace právě během tohoto kritického časového úseku nedošlo. V případě vzniku fatálního problému lze odhadnout, ţe důsledkem by mohla být úplná odstávka systému aţ v řádu desítek hodin.
3.11.3 Dokumenty pro proces testování Dle standardu IEEE 829 existuje osm dokumentů vyuţitelných pro proces testování software. Standard ale zároveň nevyţaduje vyuţití všech těchto dokumentů. Test plan Test design specification Test case specification Test procedure: popisuje spouštění testů Test item transmittal report Test log Test incident report Test summary report Pro testování Telesales software byly pouţity tyto dokumenty: Test plan, Test design specification, Test case specification. Reporty byly nahrazeny pouhou evidencí 52
nalezených chyb a problémů v bugtrackovacím systému (OTRS) a častými revizemi za účasti celého nebo vetšiny vývojového týmu (aţ na výjimky byly součástí status meeetingů). Pro zjišťování aktuálního stavu z hlediska evidence chyb byly dále dle potřeby generovány OTRS reporty. V souladu s agilním manifestem a realitou silně omezeného mnoţství času byl i rozsah testů výrazně redukován. Také časování testů bylo směřováno k minimalizaci jejich provádění – typicky finální otestování konkrétního funkčního celku bylo prováděno co nejpozději tak, aby na jedné straně tento přístup nebrzdil další vývoj, ale aby v případě změn a potřeby „na poslední chvíli“ provést korekce funkcionality, nebylo nutné testy opakovat.
3.11.4 Testovací prostředí Otázka přípravy prostředí pro vývoj, testování i vlastní pilotní ostrý běh systému byla jedním z prvních bodů v okamţiku počátku projektu. Tým hledal co nejefektivnější cestu pro nastavení prostředí po dobu vývoje první verze systému, jeho nasazení a provoz po dobu prvních několika málo týdnů. Součástí těchto úvah byla moţnost následného rozšíření prostředí – po prvních několika dnech provozu za předpokladu, ţe nebude nutné regovat na kritické poţadavky a zbyd dostatek prostoru. Typická konfigurace dle základního členění rozlišuje Vývojové Testovací Produkční Existují pádné důvody pro jasné odlišení těchto prostředí, zejména pak Riziko ztráty (odcizení) dat Riziko nedostupnosti – např. změny konfigurace serverových částí systému mohou ovlivnit nejen vývojové a testovací, ale i produkční systémy Riziko záměny dat – je-li moţné propojení databází produkčních s vývojovými či testovacími, můţe dojít k chybnému směrování poţadavku Ve fázi před nasazením telesales software pro pilotní provoz bylo vyuţíváno pouze prostředí vývojové a testovací. Právě pro sníţení nákladů na přípravu a údrţbu těchto prostředí bylo od počátku rozhodnuto, ţe testovací prostředí bude nastaveno dle cílových
poţadavku
na
produkční
prostředí.
Tedy
např.
umístění
serverů
v infrastruktuře bylo tomuto jiţ od počátku přizpůsobeno (síťová konfigurace, propojení 53
s dalšími systémy zákazníka). Tento přístup tedy umoţnil pouţít pouze dvě oddělená prostředí, pro vývoj a pro testování – později produkční běh systému. Testovací prostředí sestávalo celkem ze 3 virtuálních serverů: 1) Databázový server – MS Windows Server 2012 + MS SQL Server 2014 2) Aplikační server – Ubuntu 14.04 (LTS) – Oracle GlassFish Server 4 3) MS IIS server – tento server pouze zajišťoval staţení frontend aplikace pomocí technologie MS ClickOnce [19] Všechny výše uvedené virtální servery byly provozovány pomocí technologie pro virtualizaci od společnosti Microsoft – Hyper-V a fyzicky zajišťované pomocí Dell PowerEdge VRTX10.
10
Řešení od společnosti Dell pro vzdálené pobočky a malé kanceláře integrující aţ čtyři blade servery, sdílené úloţiště a síťové zařízaní s aţ osmi 1Gb porty. Informace výrobce: http://www.dell.com/us/business/p/poweredge-vrtx/pd 54
3.11.5 Testovací data Otázka přípravy testovacích dat byla jedním z kritických faktorů. Pokud by vývojový tým obdrţel vzorek dat v okamţiku zahájení nebo těsně po zahájení projektu, bylo by to velkou výhodou. Od začátku bylo ale jasné (odběratel uvedl jiţ v počátku jako nepravděpodobné získat vzorová data od klienta dříve neţ cca dva týdny před spuštěním pilotního provozu), ţe právě toto bude dalším omezením projektu. Bylo tedy nutné pečlivě zváţit, v jakém minimálním rozsahu je nutné zajistit testovací data – z hlediska struktury, mnoţství (počet instací jednotlivých entitních typů) nebylo příliš významné. Hlavní omezení a rizika především v počátku projektu týkající se testovacích dat: Neznalost konečné struktury dat dodané klienty Moţné důsledky: Neodpovídající struktura databáze Neodpovídající ETL proces a následně nepředvídatelná doba provedení prvních importů klientských dat (nutnost upravit algoritmy na straně importních nástrojů) Nekompatibilní backend (nové neznámé entity nebo jejich atributy, chybějící logika pro zajištění integrity systému) Nedostatečná funkcionalita aplikace. Příklad: nový typ dat poţaduje zpřístupnit odlišným způsobem, uţivatelské rohraní není na toto připraveno Protiopatření: 1) Zavedení „univerzálních entit“ s názvem „atribut“ (např. telecase_attribute) pro uloţení více týpů informací. Zároveň zajistit integritu dat pomocí číselníku typů atributu. V případě potřeby importovat do systému nový typ informace váţící se k případu, je pak pouze rozšířen příslušný číselník typů a proveden import. Na strane importních nástrojů není třeba ţádné změny („umí“ pracovat s atributy pomocí číselníku, nerozlišuje konkrétní typ atributu). 2) V uţivatelském rozhraní pouţít pro zobrazení některých informací prvky typu „seznam“. Např. zmíněné atributy zobrazovat v takovýchto prvcích. Pro uţivatelský komfort je nutné zváţit očekávané mnoţství atributů a typů atributů 55
u jednotlivých případů a dle toho prvky vhodně přizpůsobit (pro očekávané větší mnoţství např. umoţnit dynamickou změnu velikosti těchto prvků).
Obrázek 3.15: Ukázka jedné z prvních verzí testovacích dat Zdroj: Vlastní
Nedostatečná specifikace požadované funkcionality ve vztahu k datům Moţné důsledky: Neodpovídající struktura databáze Neodpovídající backendová i frontendová aplikace Protiopatření: 1) Odhad moţné funkcionality ve vztahu k datům a vlastní návrh jejich struktury umoţňující minimalizovat rozsah potřebných budoucích změn Komentář: Váţnost důsledků je v přímé závislosti na míře odlišnosti navrţené a poţadované funkcionality a zároveň na míře adaptability architektury navrţeného systému.
56
3.12 Provoz systému – dohledový systém Pro zajištění dostupnosti systému byl zvolen Nagios11. Pro kontrolu serverů Telesales systému byly pouţity aktivní i pasivní kontroly (výběr): Ping pro kontrolu odezvy některých serverů Kontrola sluţeb na úrovni OS (např. SQL server) Aktivita CPU Dostupná kapacita diskových oddílů Vyuţití RAM
3.13 Předávání, akceptační protokol Před předáním do pilotního provozu byly ze strany vývojového týmu provedeny akceptační testy. Následně byl proveden podobný test i za účasti odběratele, kde byla ověřena shoda pro jednotlivá akceptační kritéria. Následným zápisem bylo předání formálně dokončeno.
11
Nagios – rozšířený monitorovací systém pro dohled nad IT infrastrukturou. Dodávaný také jako opensource, https://www.nagios.org 57
4 Pilotní provoz Jak jiţ bylo zmíněno, hlavním omezením projektu byl pevně stanovený termín doručení pouţitelného softwarového produktu a zajištění návazných sluţeb (produkt byl doručen formou SaS12). Aby bylo moţné zajistit splnění této kritické podmínky, bylo odd počátku hledáno tzv good enough13 řešení. Logicky to znamenalo velké rezervy pro budoucí rozšiřování produktu. Jedním z důslkedků byla i nutnost zajistit větší objem IT sluţeb spojených s produktem v čase po jeho zavedení.
4.1 Podmínky pilotního provozu Pro pilotní provoz byly určeny následující podmínky: Časové určení pilotního provozu Jiţ počátku byl stanoven termín dokončení a předání produktu ve formě max. doby pro doručení od podpisu kontraktu. Termín pro předání produktu byl určen takto: Den podpisu kontraktu s dodavatelem (dále pouze jako D) + 60 dní. Byl dohodnut pilotní provoz o délce 30 dní navazujících na doručení produktu. Protoţe ale nebyl jasný termín dodání klientských dat a tedy nebylo moţné fakticky určit počátek provozu, bylo počáteční datum pilotního provouz určeno dokončením prvního importu klientských dat. Počet klientů Předpokládaný počet klientů: 1. V případě většího mnoţství klientů v období pilotního provozu (odběratel vedl v té době obchodní jednání s dalšími potenciálními klienty) budou přehodnoceny podmínky pro pilotní provoz (zmírněny nároky odběratele).
12
SaS – Software as Service. Software není dodáván jako tzv. krabicové řešení, ale součástí dodávky jsou i poskytované další sluţby (např. pravidelné úkony provádění pracovníky dodavatele). 13 V oblasti vývoje software hojnně uţívané pravidlo, kdy je hledáno dostatečně dobré řešení 58
Počet balíků případů a případů v balících Pro období pilotu bylo dohodnuto maximální mnoţství balíků – 4. Mnoţství případů v kaţdém balíku pak v řádech tisíců. Frekvence importů klientských dat Doručování klientských dat pro import bylo očekáváno nepravidelné, minimální odstup mezi balíky pak jeden den. Doba provádění importů Doba provádění importu lientských dat silně závisí na jejich struktuře (odpovídá dohodnutému formátu?) a také na mnoţství (v rámci ETL procesů dochází i k časově náročným operacím a propojování s dalšími, i externími, systémy). Četnost ad-hoc požadavků na úpravy dat (ze strany IT) Zde je nutné odlišit předání poţadavku a garanci reakce-provedení. Jelikoţ bez předchozí specifikace poţadavku nelze obecně garantovat max. dobu provedení, byla pouze deklarována připravenost zpracovat jednotky poţadavku týdně během pilotního provozu. Teprve u opakujících se poţadavků, které lze určit jako servisní, lze garantovat dobu realizace (SLA). Počet uživatelů Pro pilotní provoz bylo dohodnuto zapojení pěti uţivatelů (3x operátor, 2x management). Minimální dostupnost systému 90% v pracovní době: po-pá 8:00 – 18:00
Další podmínky také vyplývají z nefunkčních poţadavků uvedených v kap. 1.3 (hotline, dokumentace).
59
4.2 Příprava zavedení produktu do pilotního provozu Prvním důleţitým krokem bylo provedení změny statusu testovacího prostředí na produkční. Jak bylo více jiř rozebráno v kap. 3.11.4, počet prostředí byl kvůli značné časové limitaci omezen na pouhá dvě, kdy testovací bylo připraveno v okamţiku nasazení plnit (pouze) roli produkčního. Vlastní testovací pak mělo být připraveno aţ v době pilotního provozu. Proto byly provedeny pouze drobné změny konfigurace (většina byla od počátku konfigurována jiţ jako produkční, vč. propojení s některými dalšími systémy odběratele). Protoţe spolupráce s budoucími uţivateli byla započata jiţ ve fázi vývoje systému, byla ověřena úroveň znalostí ssytému ze strany jejich budoucích uţivatelů, a v některých oblastech proběhlo doškolení. Posledním krokem bylo nové zavedení systému po jeho úplném „resetu“ a provedení posledních manuálních testů.
4.3 Uvedení do provozu Informační systém pro podporu telesales aktivit odběratele byl s výjimkou vlastních „ostrých“ byznys dat připraven ke spuštění dva dny před dohodnutým termínem. Poslední podmínka pro spuštění ale v tuto chvíli ještě splněna nebyla, vývojový tým čekal na dodávku klientských dat pro provedení importu dalších 5 dní. Tato doba byla vyuţita pro optimalizace systému. Po předání klientských dat se i přesto, ţe přesná struktura těchto dat nebyla předem známá, podařilo dokončit import do 48 h a následně zahájit ostrý provoz.
4.4 Nedostatky nalezené během pilotního provozu V průběhu pilotního provozu docházelo i k situacím - neshodám, na které bylo nutno ze strany vývojového (přesnějí podpůrného IT) týmu reagovat. Naprostou většinu se dařilo řešit snadno, kdy příčina byla např. v neúplném pochopení funkcionality ze strany uţivatele. Dostačovalo tedy v těchto případech pouze znovu proškolit uţivatele. Byly-li shledány
60
závaţnější nedostatky v pochopení funkcionality, dodavatel přistoupil k preventivním školením všech uţivatelů. drobných závadách na straně klientských dat - např. chybějící a zároveň nezbytné údaje. Zde je nutno podotknout, ţe nebylo moţné z důvodu chybějících infromací (dodaná specifikace) vţdy navrhnout a implementovat integritní omezení tak, aby k těmto situacím nedocházelo. Proto vývojový tým implementoval některá integritní omezení teprve aţ v reakci na vzniklé incidenty. v chybné implementaci na straně backendu i frontendu, která povětšinou byla důsledkem chybějících vzorových dat nebo nedostatečné specifikace. Nebyl evidován ale ani jediný váţný nedostatek tohoto typu. chybějící zásadní funkcionalitě, která nebyla předem specifikována. Toto je realistická stránka softwarového vývoje, předem dostatečně specifikovat funkcionalitu je vţdy jedna z hlavních výzev softwarových projektů.
61
5 Vyhodnocení Hlavním cílem této diplomové práce bylo vyvinout softwarový systém pro podporu telemarketingových a telesales aktivit. Navrhnout vertikálně i horizontálně škálovatelné a v krátkém čase nasaditelné řešení. Uzavření kontraktu na vytvoření, implementaci a provoz informačního sytému „Telesales software“ pro odběratele provozujícího call centrum v Slovenské republice bylo pro dodavatelskou stranu a především vývojový tým počátkem velmi náročného projektu. Jiţ v počátku, ještě před podpisem kontraktu, bylo díky hlavnímu omezení – pevnému a blízkému termínu doručení produktu jasné, ţe bude třeba hledat mnoho kompromisních řešení, minimalizovat rozsah vývoje a návazných činností a vše soustředit na jediné – doručit odběrateli dostatečně funkční produkt v daný termín. Tomuto bylo podřízeno vše, od výběru metodiky pro řízení projektu (agilní vývoj), vyuţití minimalistických podpůrných nástrojů a postupů poskytující stále dostatečně dobré sluţby pro daný účel, po naprostou preferenci architektury systému umoţňující snadné pozdější rozšiřování (poţadavek na vertikální a horizontální škálovatelnost). Právě vertikální škálovatelnost byla pro vývojový tým trochu oříšek, v některých ohledech nepanovala jednota a některé podstatné změny byly provedeny aţ po konfrontaci se změnami přicházející od klienta. Toto byla zřejmě jedna z konkrétních slabin, kdy např. v okamţiku dodání dat v nečekaném formátu (příliš odlišný od očekávání) bylo nutné provést větší změny v serverové aplikaci v pozdní fázi projektu. Správnou reakcí bylo zavedení atributů případu a příslušného číselníku (viz kap. 3.11.5, Zavedení „univerzálních entit“ s názvem „atribut“) a odpovídajících úprav v uţivatelském rozhraní. Z hlediska pouţitelnosti aplikace pro uţivatele nevznikly v průběhu pilotního provozu a jiţ při prvním seznámení uţivatelů s aplikací (ještě před pilotem) zásadní problémy. Byla ale drobně upravena terminologie tak, aby některé termíny byly pro uţivatele srozumitelnější. Také bylo několikrát upraveno ovládání aplikace v části detailu případu. Zde zřejmě docházelo k největším potíţím s porozuměním uţivatelů. V pozdních fázích vývoje (některé méně rizikové i těsně před nasazením do pilotního provozu) byly provedeny vizuální změny okna detailu případu, rozčlenění na logické oblasti tak, aby jejich rozmístění podporovalo typické flow (přečíst informace -> provést akci -> zaznamenat výsledek). 62
5.1 Závěry a doporučení Jak vyplývá jiţ z Vyhodnocení, bylo dosaţeno hlavního i dalších dílčích cílů práce. V průběhu projektu bylo sice nutné reagovat na některé komplikace, ale tyto se podařilo úspěšně vyřešit bez ohroţení hlavního cíle. Vertikální škálovatelnost se ukázala jako kritickým místem návrhu, aţ se zpoţděním v pozdní fázi projektu a po konfrontaci se změnami přicházející od klienta byly provedeny potřebné úpravy. Toto opatření ale bylo určitě moţné navrhnout jiţ před vlastní implementací právě s ohledem na neúpnou specifikaci (zde formát klientských dat). Při pohledu zpět se jeví jako vhodné zváţit rozhodnutí omezit počet prostředí na pouhá dvě, coţ se projevilo nekomfortem a nemoţností v pozdní fázi projektu optimálně časovat některé činnosti. Jako optimální lze tedy doporučit tři prostředí (produkční, testovací a vývojové). Rozhodnutí připravit systém na podporu dalších jazyků se ukázalo jako správné. V současnosti je Telesales software v ruské jazykové mutaci (a po drobném přizpůsobení) vyuţíván také zákaznikem na Ukrajině. Projektový tým byl od počátku sestaven pouze z poměrně zkušených lidí a s ohledem na jejich kvalifikaci v souvislosti s uvaţovanými technologiemi. Autor této práce je přesvědčen, ţe vhodné sestavení řešitelského týmu a především vlastní motivace jeho členů je vţdy klíčovým faktorem úspěšnosti (nejen) softwarových projektů.
63
Seznam použité literatury [1] SANTLEROVÁ, Květoslava. Telemarketing v praxi, 2. aktualizované a rozšířené vydání. Praha. Grada Publishing, a.s., 2011. 224 s. ISBN 978-80-247-3928-1 [2] KADLEC, Václav. Agilní programování-metodiky efektivního vývoje softwaru. Brno. Computer Press, 2004. 278 s. ISBN 80-251-0342-0 [3] MARTIN, Robert. Agile Principles, Patterns, and Practices in C#. Bergen, NJ. Prentice Hall, 2006.768 s. ISBN 0-13-185725-8 [4] AXELOS. MANAGING SUCCESSFUL PROJECTS WITH PRINCE2. London. The Stationery Office, 2009. 342s. ISBN 0-11-331059-5 [5] VOŘÍŠEK, J.: Strategické řízení informačního systému a systémová integrace. Management Press, Praha, 2002, ISBN 80-85943-40-9 [6] PATTON, R. Testování softwaru. Computer Press, Praha, 2002. 314 s. ISBN 807226-636-5 [7] MS SQL Server 2014. https://msdn.microsoft.com. [Online] © 2015 Microsoft [Citace: 15. 2. 2015.] https://msdn.microsoft.com/enus/library/ff928359%28v=sql.10%29.aspx. [8] Visual C#. https://msdn.microsoft.com. [Online] © 2015 Microsoft, Inc. [Citace: 24. 2 2015.] https://msdn.microsoft.com/en-us/library/kx37x362.aspx. [9] Java Platform, Enterprise Edition (Java EE) 7. http://docs.oracle.com. [Online] © 2015 Oracle and/or its affiliates [Citace: 24. 2 2015.] http://docs.oracle.com/javaee/7/index.html. [10] Oracle GlassFish Server Online Documentation Library. http://docs.oracle.com. [Online] © 2015 Oracle and/or its affiliates [Citace: 30. 2 2015.] http://docs.oracle.com/cd/E26576_01/. [11] Internet Information Services Development. https://msdn.microsoft.com. [Online] © 2015 Microsoft, Inc. [Citace: 10. 3 2015.] https://msdn.microsoft.com/en-us/library/ms692515%28v=vs.90%29.aspx. [12] PRINCE2 řízení projektů. http://www.prince2.cz. [Online] © 2015 TAYLLOR&COX [Citace: 17. 4 2015.] http://www.prince2.cz/co-je-prince2.
64
[13] Aliance pro agilní vývoje software, http://www.agilealliance.org [Online] © 2015 The Agile Alliance [Citace: 17. 4 2015.] http://www.agilealliance.org/resources/. [14] Manifesto for Agile Software Development. http://www.agilemanifesto.org [Online] © 2015 [Citace: 17. 4 2015.] http://www.agilemanifesto.org. [15] Hibernate ORM documentation. http://hibernate.org/orm/documentation/. [Online] © 2015 Hibernate [Citace: 14. 4. 2015.] http://hibernate.org/orm/documentation/. [16] Sprinf Framework. http://projects.spring.io/spring-framework/. [Online] © 2015 Pivotal Software, Inc. [Citace: 14. 4. 2015.] http://projects.spring.io/springframework/. [17] Netbeans. https://netbeans.org. [Online] © 2015 NetBeans Community [Citace: 14. 4. 2015.] https://netbeans.org. [18] MS Visual Studio 2013. https://msdn.microsoft.com. [Online] © 2015 Microsoft, Inc. [Citace: 14. 4. 2015.] https://msdn.microsoft.com/library/dd831853.aspx. [19] MS ClickOnce. https://msdn.microsoft.com. [Online] © 2015 Microsoft, Inc. [Citace: 14. 4. 2015.] https://msdn.microsoft.com/enus/library/142dbbz4%28v=vs.90%29.aspx. [20] BUCHALCEVOVÁ, Alena, KUČERA, Jan. Hodnocení metodik vývoje informačních systémů z pohledu testování. Systémová integrace, 2008, roč. 15, č. 2, s. 42–54. ISSN 1210-9479 [21] Selenium IDE. http://www.seleniumhq.org. [Online] © 2015 Selenium Project [Citace: 18. 4. 2015.] http://www.seleniumhq.org/docs/. [22] HAVLÍČKOVÁ, Anna. Problémy s pokrytím kódu [online]. 2008 [Citace 19. 4. 2015]. http://testovanisoftwaru.blogspot.cz/2009/10/problemy-s-pokrytimkodu.html [23] MS SQL Server Integration Services. https://msdn.microsoft.com. [Online] © 2015 Microsoft, Inc. [Citace: 14. 4. 2015.] https://msdn.microsoft.com/enus/library/ms141026%28v=sql.120%29.aspx.
65
[24] MS SQL Server Reporting Services. https://msdn.microsoft.com. [Online] © 2015 Microsoft, Inc. [Citace: 14. 4. 2015.] https://msdn.microsoft.com/enus/library/ms159106%28v=sql.120%29.aspx. [25] Jenkins. https://jenkins-ci.org. [Online] © 2015 Jenkins CI [Citace: 14. 4. 2015.] https://jenkins-ci.org/. [26] The Apache Ant Project. http://ant.apache.org [Online] © 2015 The Apache Softwarre Foundation [Citace: 14. 4. 2015.] http://ant.apache.org. [27] SPARX UML 2 Tutorial. http://www.sparxsystems.com [Online] © 2015 The Sparx Systems Pty, Ltd. [Citace: 10. 4. 2015.] http://www.sparxsystems.com/resources/uml2_tutorial/index.html. [28] OMG, Object Management Group. http://www.uml.org [Online] © 2015 The Object Management Group, Inc. [Citace: 10. 4. 2015.] http://www.uml.org. [29] VOŘÍŠEK, J. Strategické řízení informačního systému a systémová integrace. Praha. Management Press, 2002. ISBN 80-85943-40-9.
66
Seznam obrázků Obrázek 1.1: Telesales Guide – ukázka jednoho kroku pro práci s případem .................... 12 Obrázek 3.1: Use cases – User, Team leader ...................................................................... 23 Obrázek 3.2: Workflow 3 – Odchozí hovor ....................................................................... 24 Obrázek 3.3: Workflow 1 – Vyhledat a zpracovat úkol (zavolat) ....................................... 26 Obrázek 3.4: Telesales Client – Filtr pro vyhledávání případů ........................................... 27 Obrázek 3.5: Workflow 2 – Zpracování příchozího hovoru ............................................... 28 Obrázek 3.6: Diagram aktivit 1 – práce s případem ............................................................ 33 Obrázek 3.7: Diagram aktivit 2 – práce s případem ............................................................ 34 Obrázek 3.8: Telesales Client – hlavní kritéria pro volbu platformy .................................. 37 Obrázek 3.9: Telesales Client – návrh uţivatelského rozhraní zákl. obrazovky ................. 39 Obrázek 3.10: Telesales Client – návrh uţivatelského rozhraní pro výsledky vyhledávání ......... 40 Obrázek 3.11: Telesales Client – od počátku byla implementována podpora pro více jazyků ..... 41 Obrázek 3.12: Telesales Client – okno detailu případu (konečná podoba) ......................... 42 Obrázek 3.13: Telesales Client – Přehled otevřených případů (report) vytvořený pomocí SSRS (náhled přes webový prohlíţeč) ........................................................................ 43 Obrázek 3.14: Sestavení a nasazení Telesales software - Jenkins řídící obrazovka............ 46 Obrázek 3.15: Ukázka jedné z prvních verzí testovacích dat .............................................. 56
67
Seznam zkratek EA
(Sparx) Enterprise Architect
HA
High Availability
ITIL
Information Technology Infrastructure Library
SaS
Software as Service
SOAP
Simple Object Access Protocol, je protokolem pro výměnu zpráv zaloţených na XML přes síť, hlavně pomocí HTTP
SSIS
(Microsoft) SQL Server Integration Services
SSRS
(Microsoft) SQL Server Reporting Services
TASW
Typový aplikační softwaru
UML
Unified Modeling Language
68
Přílohy Příloha 1
Logický datový model Telesales software
Příloha 2
Ukázka Telesales Guide pro práci s případem
69
Příloha 1 – Logický datový model Telesales software client Database: Detail: Notes:
SQL Server 2008, Stereotype: «table», Package: ERD Created on 8/26/2014. Last modified on 7/18/2015.
Columns PK Name True client_id False name False ico False description False state False street False city False zip False insert_user
Type int nvarchar char nvarchar tinyint nvarchar nvarchar nvarchar nvarchar
Not Null True True False False True False False False True
Unique False False False False False False False False False
False
datetime
True
False
insert_date
Constraints Name Type FK_client_client_state_librar Public y PK_client Public Relationships Columns (client_id = client_id) (state = general_state_library_id)
Len
Prec Scale Init
500 8 1000 0 0 255 255 10 50
Columns state
0
Notes
0
user_n ame() getdate ()
Initial Code
Notes
client_id
Association 0..* telecase_package.FK_telecase_package_client 1 client.PK_client 0..* client.FK_client_client_state_library 1 general_state_library.PK_general_state_library
Notes
telecase_package Database: Detail: Notes:
SQL Server 2008, Stereotype: «table», Package: ERD Created on 8/26/2014. Last modified on 9/19/2014.
Columns PK Name True telecase_package_id False client_id False ref_number False description False state False insert_user
Type int int int nvarchar tinyint nvarchar
Not Null True True True False True True
Unique False False True False False False
False
datetime
True
False
insert_date
Constraints Name
Type
Columns 70
Len
Prec Scale Init
0
0
0
1000 0 0 50
0
Initial Code
Notes
0 user_n ame() getdate () Notes
Name FK_telecase_package_client
Type Public
Columns client_id
FK_telecase_package_genera Public l_state_library PK_telecase_package Public
state
UQ_telecase_package_ref_nu Public mber
ref_number
Relationships Columns (client_id = client_id) (telecase_package_id = telecase_package_id) (state = general_state_library_id)
Initial Code
Notes
telecase_package_id
Association Notes 0..* telecase_package.FK_telecase_package_client 1 client.PK_client 0..* telecase.FK_telecase_telecase_package 1 telecase_package.PK_telecase_package 0..* telecase_package.FK_telecase_package_general_state _library 1 general_state_library.PK_general_state_library
telecase Database: Detail: Notes:
SQL Server 2008, Stereotype: «table», Package: ERD Created on 8/26/2014. Last modified on 9/19/2014.
Columns PK Name True telecase_id False telecase_package_id False ref_number False client_ref_number False company_name False ico False dic False phone False mobil False email False www False street False city False zip False district False person_name False post False state False description False actual_task_id False insert_user
Type int int bigint nvarchar nvarchar nchar nvarchar nvarchar nvarchar nvarchar nvarchar nvarchar nvarchar nchar nvarchar nvarchar nvarchar tinyint nvarchar int nvarchar
Not Null True True False False True False False False False False False False False False False False False True False False True
Unique False False False False False False False False False False False False False False False False False False False False False
False
datetime
True
False
insert_date
Constraints Name FK_telecase_task
Type Public
FK_telecase_telecase_packag Public
Len
50 255 8 20 20 20 255 255 255 255 5 255 255 255 0 0 1000
0
50
Columns actual_task_id telecase_package_id 71
Prec Scale Init
Notes
0 user_n ame() getdate ()
Initial Code
Notes
Name e PK_telecase
Type
Columns
Public
telecase_id
FK_telecase_telecase_state_li Public brary Relationships Columns (telecase_package_id = telecase_package_id) (telecase_id = telecase_id) (state = telecase_state_library_id) (actual_task_id = task_id) (telecase_id = telecase_id)
Initial Code
Notes
state
Association 0..* telecase.FK_telecase_telecase_package 1 telecase_package.PK_telecase_package 0..* task.FK_task_telecase 1 telecase.PK_telecase 0..* telecase.FK_telecase_telecase_state_library 1 telecase_state_library.PK_telecase_state_library 0..* telecase.FK_telecase_task 1 task.PK_task 0..* telecase_attribute.FK_telecase_attribute_telecase 1 telecase.PK_telecase
Notes
[user] Database: Detail: Notes:
SQL Server 2008, Stereotype: «table», Package: ERD Created on 8/26/2014. Last modified on 9/19/2014.
Columns PK Name True user_id False user_name False firstname False lastname False phone False password False account_expired False account_locked False credentials_expired False account_enabled False type False state False insert_user
Type int varchar nvarchar nvarchar varchar varchar bit bit bit bit tinyint tinyint nvarchar
Not Null True True False False False False True True True True True True True
Unique False False False False False False False False False False False False False
False
datetime
True
False
insert_date
Constraints Name Type FK_user_general_state_librar Public y PK_user Public FK_user_user_type_library Relationships Columns (state = general_state_library_id) (user_id = user_id)
Public
Columns state
Len
Prec Scale Init
Notes
50 50 50 20 50 0 0 0 0 0 50
0
0
0 user_n ame() getdate ()
Initial Code
Notes
user_id type
Association 0..* [user].FK_user_general_state_library 1 general_state_library.PK_general_state_library 0..* user_x_role.FK_user_x_role_user 72
Notes
Columns
Association 1 [user].PK_user
(type = user_type_library_id) (user_id = user_id)
0..* 1 1 1
Notes
[user].FK_user_user_type_library user_type_library.PK_user_type_library task.FK_task_user [user].PK_user
task Database: Detail: Notes:
SQL Server 2008, Stereotype: «table», Package: ERD Created on 8/26/2014. Last modified on 9/19/2014.
Columns PK Name True task_id False telecase_id False user_id False type False operation False state False description False execution_date False previous_task_id False insert_user
Type int int int tinyint tinyint tinyint nvarchar datetime int nvarchar
Not Null True True True True True True False False False True
Unique False False False False False False False False False False
False
datetime
True
False
insert_date
Constraints Name Type FK_task_task_operation_libr Public ary FK_task_task_state_library Public
Len
0 0 0 0 0 0 1000
Columns operation
type
FK_task_telecase
Public
telecase_id
FK_task_user
Public
user_id
PK_task
Public
task_id
FK_previous_task_task
Public
previous_task_id
(type = task_type_library_id) (operation = task_operation_library_id) (previous_task_id = task_id)
Notes
0
user_n ame() getdate () Initial Code
Notes
state
Public
(state = task_state_library_id)
0 0 0
50
FK_task_task_type_library
Relationships Columns (telecase_id = telecase_id)
Prec Scale Init
Association 0..* task.FK_task_telecase 1 telecase.PK_telecase 0..* task.FK_task_task_state_library 1 task_state_library.PK_task_state_library 0..* task.FK_task_task_type_library 1 task_type_library.PK_task_type_library 0..* task.FK_task_task_operation_library 1 task_operation_library.PK_task_operation_library 0..* task.FK_previous_task_task 1 task.PK_task 73
Notes
Columns (actual_task_id = task_id) (user_id = user_id)
Association 0..* telecase.FK_telecase_task 1 task.PK_task 1 task.FK_task_user 1 [user].PK_user
Notes
general_state_library Database: Detail: Notes:
SQL Server 2008, Stereotype: «table», Package: ERD Created on 8/26/2014. Last modified on 9/19/2014.
Columns PK Name True general_state_librar y_id False name False description False state False insert_user False
insert_date
Type tinyint
Not Null Unique Len True True
nvarchar nvarchar tinyint nvarchar
True False True True
False False False False
datetime
True
False
Constraints Name Type UQ_general_state_library_ge Public neral_state_library_id PK_general_state_library
Relationships Columns (state = general_state_library_id) (state = general_state_library_id) (state = general_state_library_id) (state = general_state_library_id) (state = general_state_library_id) (state = general_state_library_id) (state = general_state_library_id) (state = general_state_library_id)
Public
Prec Scale Init
Notes
50 255 0 user_n ame() getdate ()
50
Columns general_state_librar y_id
Initial Code
Notes
general_state_librar y_id
Association Notes 0..* client.FK_client_client_state_library 1 general_state_library.PK_general_state_library 0..* telecase_package.FK_telecase_package_general_state _library 1 general_state_library.PK_general_state_library 0..* [user].FK_user_general_state_library 1 general_state_library.PK_general_state_library 0..* role.FK_role_general_state_library 1 general_state_library.PK_general_state_library 0..* user_x_role.FK_user_x_role_general_state_library 1 general_state_library.PK_general_state_library 0..* task_state_library.FK_task_state_library_general_stat e_library 1 general_state_library.PK_general_state_library 0..* task_type_library.FK_task_type_library_general_state _library 1 general_state_library.PK_general_state_library 0..* task_operation_library.FK_task_operation_library_ge neral_state_library 1 general_state_library.PK_general_state_library 74
Columns (state = general_state_library_id) (state = general_state_library_id) (state = general_state_library_id) (state = general_state_library_id) (state = general_state_library_id) (state = general_state_library_id) (state = general_state_library_id) (state = general_state_library_id) (state = general_state_library_id)
Association Notes 0..* user_type_library.FK_user_type_library_general_state _library 1 general_state_library.PK_general_state_library 0..* task_operation_x_user_type.FK_task_operation_x_us er_type_general_state_lib... 1 general_state_library.PK_general_state_library 0..* operation_direction_type_library.FK_operation_direct ion_type_library_general_sta... 1 general_state_library.PK_general_state_library 0..* task_operation_x_state.FK_task_operation_x_state_ge neral_state_library 1 general_state_library.PK_general_state_library 0..* telecase_attribute.FK_telecase_attribute_general_state _library 1 general_state_library.PK_general_state_library 0..* data_type_library.FK_data_type_library_general_state _library 1 general_state_library.PK_general_state_library 0..* telecase_attribute_group_library.FK_telecase_attribut e_group_library_general_sta... 1 general_state_library.PK_general_state_library 0..* telecase_state_library.FK_telecase_state_library_gene ral_state_library 1 general_state_library.PK_general_state_library 0..* telecase_attribute_type_library.FK_telecase_attribute_ type_library_general_stat... 1 general_state_library.PK_general_state_library
telecase_state_library Database: Detail: Notes:
SQL Server 2008, Stereotype: «table», Package: ERD Created on 8/26/2014. Last modified on 9/19/2014.
Columns PK Name True telecase_state_librar y_id False name False description False state False insert_user False
insert_date
Type tinyint
Not Null Unique Len True True
nvarchar nvarchar tinyint nvarchar
True False True True
False False False False
datetime
True
False
Constraints Name Type FK_telecase_state_library_ge Public neral_state_library
Columns state 75
50 255 0 50
Prec Scale Init
0
0
Initial Code
Notes
0 user_n ame() getdate () Notes
Name Type UQ_telecase_state_library_te Public lecase_state_library_id
Columns Initial Code telecase_state_librar y_id
PK_telecase_state_library
telecase_state_librar y_id
Relationships Columns (state = telecase_state_library_id) (telecase_state = telecase_state_library_id) (state = general_state_library_id)
Public
Notes
Association Notes 0..* telecase.FK_telecase_telecase_state_library 1 telecase_state_library.PK_telecase_state_library 0..* task_state_library.FK_task_state_library_telecase_stat e_library 1 telecase_state_library.PK_telecase_state_library 0..* telecase_state_library.FK_telecase_state_library_gene ral_state_library 1 general_state_library.PK_general_state_library
task_state_library Database: Detail: Notes:
SQL Server 2008, Stereotype: «table», Package: ERD Created on 8/26/2014. Last modified on 9/19/2014.
Columns PK Name True task_state_library_id False name False description False state False telecase_state False insert_user
Type tinyint nvarchar nvarchar tinyint tinyint nvarchar
Not Null True True False True True True
Unique True False False False False False
False
datetime
True
False
insert_date
Constraints Name FK_task_state_library_gener al_state_library FK_task_state_library_teleca se_state_library UQ_task_state_library_task_ state_library_id PK_task_state_library Relationships Columns (state = task_state_library_id) (state = general_state_library_id) (telecase_state =
Len
Prec Scale Init
50 255 0
0
0
50
Type Public
Columns state
Public
telecase_state
Public
task_state_library_id
Public
task_state_library_id
Notes
0 user_n ame() getdate ()
Initial Code
Notes
Association Notes 0..* task.FK_task_task_state_library 1 task_state_library.PK_task_state_library 0..* task_state_library.FK_task_state_library_general_stat e_library 1 general_state_library.PK_general_state_library 0..* 76
Columns telecase_state_library_id) (task_state_library_id = task_state_library_id)
Association Notes task_state_library.FK_task_state_library_telecase_stat e_library 1 telecase_state_library.PK_telecase_state_library 0..* task_operation_x_state.FK_task_operation_x_state_ta sk_state_library 1 task_state_library.PK_task_state_library
role Database: Detail: Notes:
SQL Server 2008, Stereotype: «table», Package: ERD Created on 8/26/2014. Last modified on 9/19/2014.
Columns PK Name True role_id False name False description False state False insert_user
Type int varchar nvarchar tinyint nvarchar
Not Null True True False True True
Unique False False False False False
False
datetime
True
False
insert_date
Constraints Name Type FK_role_general_state_librar Public y PK_role Public Relationships Columns (state = general_state_library_id) (role_id = role_id)
Len
Prec Scale Init
50 1000 0 0 50
Columns state
0
Notes
0 user_n ame() getdate ()
Initial Code
Notes
role_id
Association 0..* role.FK_role_general_state_library 1 general_state_library.PK_general_state_library 0..* user_x_role.FK_user_x_role_role 1 role.PK_role
Notes
user_x_role Database: Detail: Notes:
SQL Server 2008, Stereotype: «table», Package: ERD Created on 8/26/2014. Last modified on 9/19/2014.
Columns PK Name True user_x_role_id False user_id False role_id False state False insert_user
Type int int int tinyint nvarchar
Not Null True True True True True
Unique Len False False False False 0 False 50
False
datetime
True
False
insert_date
Constraints Name Type FK_user_x_role_general_stat Public
Columns state 77
Prec Scale Init
0
0
Initial Code
Notes
0 user_n ame() getdate () Notes
Name e_library FK_user_x_role_role
Type
Columns
Public
role_id
FK_user_x_role_user
Public
user_id
PK_user_x_role
Public
user_x_role_id
Relationships Columns (state = general_state_library_id) (user_id = user_id) (role_id = role_id)
Initial Code
Notes
Association 0..* user_x_role.FK_user_x_role_general_state_library 1 general_state_library.PK_general_state_library 0..* user_x_role.FK_user_x_role_user 1 [user].PK_user 0..* user_x_role.FK_user_x_role_role 1 role.PK_role
Notes
task_type_library Database: Detail: Notes:
SQL Server 2008, Stereotype: «table», Package: ERD Created on 8/26/2014. Last modified on 9/19/2014.
Columns PK Name True task_type_library_id False name False description False state False insert_user
Type tinyint nvarchar nvarchar tinyint nvarchar
Not Null True True False True True
Unique True False False False False
False
datetime
True
False
insert_date
Constraints Name FK_task_type_library_genera l_state_library UQ_task_type_library_task_t ype_library_id PK_task_type_library Relationships Columns (type = task_type_library_id) (state = general_state_library_id)
Len 50 255 0 50
Type Public
Columns state
Public
task_type_library_id
Public
task_type_library_id
Prec Scale Init
0
Initial Code
0 user_n ame() getdate () Notes
Association Notes 0..* task.FK_task_task_type_library 1 task_type_library.PK_task_type_library 0..* task_type_library.FK_task_type_library_general_state _library 1 general_state_library.PK_general_state_library
task_operation_library Database: Detail: Notes:
0
Notes
SQL Server 2008, Stereotype: «table», Package: ERD Created on 8/26/2014. Last modified on 9/19/2014.
Columns 78
PK True
Type tinyint
Not Null Unique Len True True
False False False False False False
Name task_operation_libra ry_id name description state direction user_type insert_user
nvarchar nvarchar tinyint tinyint tinyint nvarchar
True False True True True True
False False False False False False
False
insert_date
datetime
True
False
Constraints Name FK_task_operation_library_g eneral_state_library FK_task_operation_library_o peration_direction_type_libra ry FK_task_operation_library_u ser_type_library UQ_task_operation_library_t ask_operation_library_id PK_task_operation_library
50 255 0
Prec Scale Init
0
0
50
Type Public
Columns state
Public
direction
Public
user_type
Public
task_operation_libra ry_id
Public
task_operation_libra ry_id
Notes
0 user_n ame() getdate ()
Initial Code
Relationships Columns (operation = task_operation_library_id) (state = general_state_library_id)
Notes
Association Notes 0..* task.FK_task_task_operation_library 1 task_operation_library.PK_task_operation_library 0..* task_operation_library.FK_task_operation_library_ge neral_state_library 1 general_state_library.PK_general_state_library (task_operation_library_id = 0..* task_operation_library_id) task_operation_x_user_type.FK_task_operation_x_us er_type_task_operation_li... 1 task_operation_library.PK_task_operation_library (direction = 0..* operation_direction_type_libra task_operation_library.FK_task_operation_library_op ry_id) eration_direction_t... 1 operation_direction_type_library.PK_operation_direct ion_type_library (task_operation_library_id = 0..* task_operation_library_id) task_operation_x_state.FK_task_operation_x_state_ta sk_operation_library 1 task_operation_library.PK_task_operation_library (user_type = 0..* user_type_library_id) task_operation_library.FK_task_operation_library_us er_type_library 1 user_type_library.PK_user_type_library
user_type_library Database:
SQL Server 2008, Stereotype: «table», Package: ERD 79
Detail: Notes:
Created on 8/29/2014. Last modified on 9/19/2014.
Columns PK Name True user_type_library_id False name False description False state False insert_user
Type tinyint nvarchar nvarchar tinyint nvarchar
Not Null True True False True True
Unique True False False False False
False
datetime
True
False
insert_date
Constraints Name FK_user_type_library_genera l_state_library UQ_user_type_library_user_t ype_library_id PK_user_type_library Relationships Columns (type = user_type_library_id) (state = general_state_library_id) (user_type_library_id = user_type_library_id) (user_type = user_type_library_id)
Len 50 255 0 50
Type Public
Columns state
Public
user_type_library_id
Public
user_type_library_id
Prec Scale Init
0
0
Notes
0 user_n ame() getdate ()
Initial Code
Notes
Association Notes 0..* [user].FK_user_user_type_library 1 user_type_library.PK_user_type_library 0..* user_type_library.FK_user_type_library_general_state _library 1 general_state_library.PK_general_state_library 0..* task_operation_x_user_type.FK_task_operation_x_us er_type_user_type_library 1 user_type_library.PK_user_type_library 0..* task_operation_library.FK_task_operation_library_us er_type_library 1 user_type_library.PK_user_type_library
operation_direction_type_library Database: Detail: Notes:
SQL Server 2008, Stereotype: «table», Package: ERD Created on 8/29/2014. Last modified on 9/19/2014.
Columns PK Name True operation_direction_ type_library_id False name False description False state False insert_user False
insert_date
Type tinyint
Not Null Unique Len True True
nvarchar nvarchar tinyint nvarchar
True False True True
False False False False
datetime
True
False
Constraints 80
50 255 0 50
Prec Scale Init
0
0
0 user_n ame() getdate ()
Notes
Name FK_operation_direction_type _library_general_state_librar y UQ_operation_direction_type _library_operation_direction_ type_library_id PK_operation_direction_type _library
Type Public
Columns state
Initial Code
Public
operation_direction_ type_library_id
Public
operation_direction_ type_library_id
Notes
Relationships Columns (state = general_state_library_id)
Association Notes 0..* operation_direction_type_library.FK_operation_direct ion_type_library_general_sta... 1 general_state_library.PK_general_state_library (direction = 0..* operation_direction_type_libra task_operation_library.FK_task_operation_library_op ry_id) eration_direction_t... 1 operation_direction_type_library.PK_operation_direct ion_type_library
task_operation_x_state Database: Detail: Notes:
SQL Server 2008, Stereotype: «table», Package: ERD Created on 8/29/2014. Last modified on 9/19/2014.
Columns PK Name True task_operation_x_st ate_id False task_operation_libra ry_id False task_state_library_id False state False insert_user False
insert_date
Type int
Not Null Unique Len True False
tinyint
True
False
tinyint tinyint nvarchar
True True True
False False False
datetime
True
False
Constraints Name Type FK_task_operation_x_state_g Public eneral_state_library FK_task_operation_x_state_t Public ask_operation_library FK_task_operation_x_state_t Public ask_state_library PK_task_operation_x_state Public
Relationships Columns (task_operation_library_id =
Prec Scale Init
0 user_n ame() getdate ()
50
Columns state
Notes
Initial Code
Notes
task_operation_libra ry_id task_state_library_id task_operation_x_st ate_id
Association 0..*
Notes
81
Columns task_operation_library_id) (task_state_library_id = task_state_library_id) (state = general_state_library_id)
Association Notes task_operation_x_state.FK_task_operation_x_state_ta sk_operation_library 1 task_operation_library.PK_task_operation_library 0..* task_operation_x_state.FK_task_operation_x_state_ta sk_state_library 1 task_state_library.PK_task_state_library 0..* task_operation_x_state.FK_task_operation_x_state_ge neral_state_library 1 general_state_library.PK_general_state_library
telecase_attribute Database: Detail: Notes:
SQL Server 2008, Stereotype: «table», Package: ERD Created on 9/18/2014. Last modified on 9/19/2014.
Columns PK Name True telecase_attribute_id False telecase_id False type False value False type_size False description False state False insert_user
Type int int tinyint nvarchar tinyint nvarchar tinyint nvarchar
Not Null True True True True False False False True
Unique False False False False False False False False
False
datetime
True
False
insert_date
Constraints Name FK_telecase_attribute_genera l_state_library FK_telecase_attribute_telecas e FK_telecase_attribute_telecas e_attribute_type_library PK_telecase_attribute
Len
Notes
255 255 0 user_n ame() getdate ()
50
Type Public
Columns state
Public
telecase_id
Public
type
Public
telecase_attribute_id
Relationships Columns (telecase_id = telecase_id)
Prec Scale Init
Initial Code
Notes
Association Notes 0..* telecase_attribute.FK_telecase_attribute_telecase 1 telecase.PK_telecase (state = 0..* general_state_library_id) telecase_attribute.FK_telecase_attribute_general_state _library 1 general_state_library.PK_general_state_library (type = 0..* telecase_attribute_type_library telecase_attribute.FK_telecase_attribute_telecase_attri _id) bute_type_l... 1 telecase_attribute_type_library.PK_telecase_attribute_ type_library
telecase_attribute_type_library 82
Database: Detail: Notes:
SQL Server 2008, Stereotype: «table», Package: ERD Created on 9/18/2014. Last modified on 9/19/2014.
Columns PK Name True telecase_attribute_ty pe_library_id False name False description False state False attribute_group False attribute_group_ord er False data_type False insert_user False
insert_date
Constraints Name FK_telecase_attribute_type_l ibrary_data_type_library FK_telecase_attribute_type_l ibrary_general_state_library FK_telecase_attribute_type_l ibrary_telecase_attribute_gro up_library PK_telecase_attribute_type_l ibrary
Type tinyint
Not Null Unique Len True False
nvarchar nvarchar tinyint tinyint tinyint
True False True False False
False False False False False
tinyint nvarchar
True True
False False
datetime
True
False
Prec Scale Init
Notes
50 255 0
50
Type Public
Columns data_type
Public
state
Public
attribute_group
Public
telecase_attribute_ty pe_library_id
user_n ame() getdate () Initial Code
Relationships Columns (data_type = data_type_library_id)
Notes
Association Notes 0..* telecase_attribute_type_library.FK_telecase_attribute_ type_library_data_type_li... 1 data_type_library.PK_data_type_library (attribute_group = 0..* telecase_attribute_group_libra telecase_attribute_type_library.FK_telecase_attribute_ ry_id) type_library_telecase_att... 1 telecase_attribute_group_library.PK_telecase_attribut e_group_library (state = 0..* general_state_library_id) telecase_attribute_type_library.FK_telecase_attribute_ type_library_general_stat... 1 general_state_library.PK_general_state_library (type = 0..* telecase_attribute_type_library telecase_attribute.FK_telecase_attribute_telecase_attri _id) bute_type_l... 1 telecase_attribute_type_library.PK_telecase_attribute_ type_library
data_type_library Database: Detail:
SQL Server 2008, Stereotype: «table», Package: ERD Created on 9/18/2014. Last modified on 9/19/2014. 83
Notes: Columns PK Name True data_type_library_id False name False description False state False insert_user
Type tinyint nvarchar nvarchar tinyint nvarchar
Not Null True True False True True
Unique False False False False False
False
datetime
True
False
insert_date
Constraints Name Type FK_data_type_library_genera Public l_state_library PK_data_type_library Public Relationships Columns (data_type = data_type_library_id) (state = general_state_library_id)
Len
Prec Scale Init
Notes
50 255 0 user_n ame() getdate ()
50
Columns state
Initial Code
Notes
data_type_library_id
Association Notes 0..* telecase_attribute_type_library.FK_telecase_attribute_ type_library_data_type_li... 1 data_type_library.PK_data_type_library 0..* data_type_library.FK_data_type_library_general_state _library 1 general_state_library.PK_general_state_library
telecase_attribute_group_library Database: Detail: Notes:
SQL Server 2008, Stereotype: «table», Package: ERD Created on 9/18/2014. Last modified on 9/19/2014.
Columns PK Name True telecase_attribute_gr oup_library_id False name False description False state False insert_user False
insert_date
Type tinyint
Not Null Unique Len True False
nvarchar nvarchar tinyint nvarchar
True False True True
False False False False
datetime
True
False
Constraints Name Type FK_telecase_attribute_group Public _library_general_state_librar y PK_telecase_attribute_group Public _library
0 user_n ame() getdate ()
50
telecase_attribute_gr oup_library_id
84
Notes
255 255
Columns state
Relationships
Prec Scale Init
Initial Code
Notes
Columns Association Notes (attribute_group = 0..* telecase_attribute_group_libra telecase_attribute_type_library.FK_telecase_attribute_ ry_id) type_library_telecase_att... 1 telecase_attribute_group_library.PK_telecase_attribut e_group_library (state = 0..* general_state_library_id) telecase_attribute_group_library.FK_telecase_attribut e_group_library_general_sta... 1 general_state_library.PK_general_state_library
85
Příloha 2 – Ukázka Telesales Guide pro práci s případem (transformováno z pdf)
86
87
88
