telekomunikační firmy

České vysoké učení technické v Praze Fakulta elektrotechnická Diplomová práce Fakturační a evidenční systém malé telekomunikační firmy Vojtěch Brom Vedoucí práce: Ing. Martin Bloch, CSc. Studijní program: Elektrotechnika a informatika, dobíhající magisterský Obor: Informatika a výpočetní technika Leden 2007 prosinec 2006

ii

Poděkování Na tomto místě bych rád vyjádřil své poděkování všem, bez kterých by tato práce nemohla vzniknout. V první řadě děkuji své rodině za poskytnuté zázemí a obrovskou podporu při studiu a psaní této práce, zejména pak své mamince, která celý text pečlivě přečetla a byla mi největší oporou. Dále děkuji Ing. Martinu Blochovi, CSc., vedoucímu této práce, za jeho optimistický přístup k věci a cenné rady. V neposlední řadě děkuji za podporu a podnětné připomínky svým přátelům. iii

iv

Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti použití tohoto školního díla ve smyslu 60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Praze dne 10.2. 2007........................ v

vi

Abstract This diploma thesis deals with the creation of Customer Relationship Management system for a small telecommunications company BCH TeleCommunications Inc. The goal is to design and to create user friendly application, which will simplify the client directory administration and invoicing for the customers. The whole thesis can be divided into several parts. First two parts deal with a general definition of the assignment itself with the summary of system requirements and a selection of suitable methodology for analysis and design. Following is the detailed requirements analysis and part of the system design. Next part is devoted to the description of system implementation and implementation supporting tools. At the end the thesis focuses on discussion about testing and the last part encompasses an evaluation of achieved results. Abstrakt Tato diplomová práce se zabývá tvorbou evidenčního a fakturačního systému pro malou telekomunikační společnost BCH TeleCommunications s.r.o. Cílem je navržení a vytvoření přehledné aplikace, která společnosti usnadní především vedení zákaznické agendy a vystavování faktur pro zákazníky. Práci lze rozdělit do několika hlavních částí. První dvě části se zabývají obecnou definicí vlastního zadání s nástinem požadavků na systém a výběrem vhodné metodiky pro analýzu a návrh. Následuje podrobná analýza požadavků a část návrhu aplikace. Další část se věnuje popisu vlastní implementace a použitých implementačních nástrojů. Na konci se práce zaměřuje na diskusi o testování a v poslední části je obsaženo zhodnocení dosažených výsledků. vii

viii

OBSAH 1 ÚVOD 1 2 POUŽITÉ TECHNOLOGIE A METODIKY 1 2.1 DOSTUPNÉ METODIKY (A TECHNOLOGIE) 1 2.1.1 CO JE METODIKA A CO TECHNOLOGIE 1 2.1.2 STRUČNÝ PŘEHLED 2 2.2 POUŽITÉ METODIKY (A TECHNOLOGIE) 3 2.2.1 UML 3 2.2.1.1 Použité a dostupné diagramy UML 4 2.2.2 ER MODELOVÁNÍ 4 3 ÚVODNÍ STUDIE 5 3.1 RÁMCOVÝ PLÁN PROJEKTU 5 3.2 DEKLARACE ZÁMĚRU 6 3.2.1 HLAVNÍ RYSY APLIKACE 6 3.3 ODBORNÝ ČLÁNEK 6 3.4 DIAGRAM KONTEXTU 9 3.4.1 BLIŽŠÍ SPECIFIKACE KONTEXTU 9 3.5 PŘÍPADY UŽITÍ 10 3.5.1 DIAGRAMY PŘÍPADŮ UŽITÍ 10 3.5.1.1 Výchozí Use Case diagram 10 3.5.1.2 Use Case diagramy většího detailu 11 3.5.2 TEXTOVÁ SPECIFIKACE NĚKTERÝCH PŘÍPADŮ UŽITÍ 13 3.6 STANOVENÍ DOSAŽITELNÝCH CÍLŮ VLASTNÍ DIPLOMOVÉ PRÁCE 15 4 ANALÝZA 17 4.1 SLOVNÍČEK POUŽÍVANÝCH POJMŮ A ZKRATEK 17 4.2 SOUČASNÉ FAKTURAČNÍ ŘEŠENÍ 18 4.2.1 STRUČNÁ CHARAKTERISTIKA 18 4.2.2 MIGRACE STÁVAJÍCÍCH DAT 18 4.3 PODROBNÝ KATALOG POŽADAVKŮ A BLIŽŠÍ SPECIFIKACE 18 4.3.1 POŽADAVKY NA HW A SW 18 4.3.2 POŽADAVKY NA VYTVÁŘENÝ SOFTWARE 18 4.3.2.1 Serverová část 18 4.3.2.1.1 Informace uchovávané o zákaznících 19 4.3.2.1.2 Informace evidované k fakturám 20 4.3.2.1.3 Informace sazebníků 20 4.3.2.1.4 Informace o klientských číslech a o všech provedených hovorech 21 4.3.2.1.5 Systémové informace 21 4.3.2.1.6 Informace o CDR projektech 22 4.3.2.2 Klientská část 22 ix

4.3.2.2.1 Správa klientské databáze 22 4.3.2.2.2 Import dat 22 4.3.2.2.3 Zakládání a rušení CDR projektů 23 4.3.2.2.4 Vytváření detailních výpisů hovorů (v rámci projektu) 23 4.3.2.2.5 Označování duplicitních a překrývajících se hovorů ve výpisu hovorů 23 4.3.2.2.6 Vytváření faktur a zpracování plateb (v rámci projektu) 23 4.3.2.2.7 Vytváření reportů (v rámci projektu) 24 4.3.2.2.8 Export do XLS 24 4.3.2.2.9 Tisk 24 4.3.2.2.10 Zasílání emailů 25 4.3.2.2.11 Zaznamenávání změn 25 4.3.2.2.12 Podpora více jazyků uživatelského rozhraní 25 4.4 DATOVÁ ANALÝZA 26 4.4.1 ER DIAGRAM 26 4.4.2 POPIS REPREZENTACE DAT 27 4.4.2.1 Entita zakaznik 27 4.4.2.2 Entita adresa 27 4.4.2.3 Entita CDR_projekt 28 4.4.2.4 Entita CLI 28 4.4.2.5 Entita CLI_skupina 28 4.4.2.6 Entita druh_platby 28 4.4.2.7 Entita email 28 4.4.2.8 Entita fakturace_poradnik 28 4.4.2.9 Entita faktura 29 4.4.2.10 Entita hovor 29 4.4.2.11 Entita kontaktni_osoba 29 4.4.2.12 Entita kreditni_karta 29 4.4.2.13 Entita problemova_hlaseni_cli 30 4.4.2.14 Entita problemove_hlaseni 30 4.4.2.15 Entita sazba 30 4.4.2.16 Entita sazebnik 30 4.4.2.17 Entita servis_info 30 4.4.2.18 Entita system_log_uzivatel 31 4.4.2.19 Entita system_log_zmena 31 4.4.2.20 Entita system_uzivatel 31 4.4.2.21 Entita system_uzivatel_nastaveni 31 4.4.2.22 Entita technicky_partner 31 4.4.2.23 Entita telefon 32 4.4.2.24 Entita typ_karty 32 4.4.2.25 Entita typ_zakaznika 32 4.4.3 HODNOTY DAT A RELACE 32 4.4.3.1 Hodnoty dat 32 4.4.3.2 Relace 33 4.5 MODELOVÁNÍ DYNAMICKÉHO CHOVÁNÍ NĚKTERÝCH ČÁSTÍ SYSTÉMU 33 4.5.1 MODELOVÁNÍ PROCESU VYTVOŘENÍ CDR PROJEKTU 33 4.5.2 MODELOVÁNÍ PROCESU VYTVOŘENÍ CDR VÝPISŮ 35 4.5.2.1 Detekce duplicitních a překrývajících se hovorů 35 4.5.3 MODELOVÁNÍ PROCESU VYTVOŘENÍ FAKTUR 36 4.6 DIAGRAMY AKTIVIT PRO PROVÁDĚNÍ NĚKTERÝCH OPERACÍ 37 x

4.6.1 OPERACE VYMAZÁNÍ (CDR PROJEKTU) 38 4.6.2 ZASLÁNÍ EMAILU 38 4.7 ZÁVĚREM K ANALÝZE 39 5 NÁVRH 41 5.1 NÁVRH ČLENĚNÍ SYSTÉMU A POPIS KOMPONENT 41 5.1.1 NÁVRH KOMPONENT (BALÍČKŮ) 41 5.1.2 POPIS ZÁKLADNÍHO NÁVRHU JEDNOTLIVÝCH KOMPONENT (BALÍČKŮ) 42 5.1.2.1 Komponenta dbaccess 42 5.1.2.1.1 Dílčí komponenta pro logování změn datachanges 42 5.1.2.2 Komponenta entities 43 5.1.2.2.1 Reprezentace relací mezi entitními objekty 43 5.1.2.2.2 Ukládání, mazání a update dat entitních objektů 43 5.1.2.3 Komponenta emailing 44 5.1.2.4 Komponenta exceptions 45 5.1.2.5 Komponenta input 45 5.1.2.6 Komponenta printing 46 5.1.2.7 Komponenta xls 46 5.1.2.8 Komponenty tools, ApplicationStatus, Main a Login 47 5.2 NÁVRH GRAFICKÉHO UŽIVATELSKÉ ROZHRANÍ 47 5.2.1 STRUČNÝ POPIS DÍLČÍCH ČÁSTÍ KOMPONENTY GUI 48 5.2.1.1 Hlavní okno třída MainFrame 48 5.2.1.1.1 Panely hlavního okna balík panels 48 5.2.1.2 Datové modely komponenta models 49 5.2.1.3 Dialogy a jednoduché zprávy balíky dialogs a messages 49 5.2.1.4 Okno zákazníka třída CustomerFrame 50 5.2.1.5 Programová správa grafického rozhraní třída GUIStatus 50 5.2.1.6 Podpora vícejazyčného GUI 50 5.2.1.7 Měření průběhu dlouhých činností balík progressmeasuring 51 5.2.2 NÁVRH INTERAKCE UŽIVATELE A GUI 52 5.3 AKCEPTAČNÍ TESTY A TESTY POUŽITELNOSTI 53 5.3.1 NÁVRH AKCEPTAČNÍCH TESTŮ PRO HLAVNÍ FUNKCE 54 5.3.2 TESTOVÁNÍ POUŽITELNOSTI 54 6 IMPLEMENTACE 55 6.1 POUŽITÉ TECHNOLOGIE A NÁSTROJE 55 6.1.1 VOLBA TECHNOLOGIÍ 55 6.1.2 VOLBA NÁSTROJŮ 55 6.1.3 STRUČNÝ PŘEHLED POUŽITÝCH NESTANDARDNÍCH KNIHOVEN A NÁSTROJŮ 55 6.1.3.1 Knihovny pro práci s XLS formátem 56 6.1.3.2 Knihovny pro podporu elektronické pošty 56 6.1.3.3 Knihovny a nástroje pro podporu tisku 56 6.2 POPIS VLASTNÍ IMPLEMENTACE 57 6.2.1 PRAVIDLA A KONVENCE PŘI PSANÍ KÓDU 57 6.2.2 STRUČNÝ POPIS IMPLEMENTACE ZAJÍMAVÝCH ČÁSTÍ SYSTÉMU 58 6.2.2.1 Podpora práce s formátem XLS 58 xi

6.2.2.1.1 Export dat užitím XLS šablony a knihovny jxls 58 6.2.2.1.2 Načtení hodnoty buňky z XLS souboru pomocí knihovny Java Excel API 59 6.2.2.2 Podpora zasílání emailů 59 6.2.2.3 Podpora tisku a exportu do různých formátů 60 6.2.3 NALEZENÉ CHYBY V IMPLEMENTACI JAVY 61 6.2.3.1 Memory Leak v aplikacích založených na SWING v prostředí Windows 61 6.2.3.1.1 Stručný popis chyby 61 6.2.3.1.2 Postup vedoucí k odhalení chyby 62 6.2.3.1.3 Proprietální řešení chyby 62 6.2.3.2 Drobná chyba při používání komponenty SWINGu JDialog 63 6.2.4 PŘEHLED IMPLEMENTOVANÝCH ČÁSTÍ A ROZSAHU IMPLEMENTACE 63 6.3 INSTALAČNÍ PŘÍRUČKA 64 6.3.1 INSTALACE SERVEROVÉ ČÁSTI A VYTVOŘENÍ SCHÉMATU 64 6.3.1.1 Instalace a konfigurace MySQL 64 6.3.1.2 Vytvoření databázového schématu 65 6.3.2 INSTALACE KLIENTA 65 7 TESTOVÁNÍ 67 7.1 JEDNOTKOVÉ TESTY 67 7.2 INTEGRAČNÍ TESTY 67 7.3 TESTY GUI 68 7.4 VALIDAČNÍ A SYSTÉMOVÉ TESTY, AKCEPTACE A TESTY POUŽITELNOSTI 69 8 ZÁVĚR 71 8.1 ZHODNOCENÍ VÝBĚRU POUŽITÝCH TECHNOLOGIÍ A NÁSTROJŮ 71 8.2 ZHODNOCENÍ DOSAŽENÝCH VÝSLEDKŮ 71 8.3 DOPORUČENÍ PRO DALŠÍ POKRAČOVÁNI PROJEKTU 72 9 POUŽITÉ ZDROJE 73 9.1 LITERATURA A SLIDY 73 9.2 INTERNETOVÉ ODKAZY 74 10 SEZNAM ILUSTRACÍ, TABULEK A PŘÍLOH 75 10.1 SEZNAM ILUSTRACÍ 75 10.2 SEZNAM TABULEK 76 10.3 SEZNAM PŘÍLOH 76 xii

xiii

xiv

Kapitola 1. Úvod 1 1 Úvod Při studiu ČVUT jsem se od začátku snažil směrovat mé zaměření k informačním technologiím a oboru softwarového inženýrství. V průběhu času jsem začal pracovat na pozici intranetového vývojáře v malém týmu. S metodami a postupy návrhu a vývoje software, které jsou vyučovány na katedře počítačů, jsem se však v praxi neseznámil. Vývoj probíhal spíše stylem extrémního programování. V období výběru tématu diplomové práce se mi naskytla příležitost tvorby aplikace pro malou telekomunikační společnost. Software by měl sloužit zejména pro evidenci zákazníků, jejich hovorů a pro vytváření faktur a výpisů s hovory pro zákazníky. Napadlo mne, že by to byla ideální příležitost, jak si v praxi vyzkoušet vývojový cyklus softwarového inženýrství. Po konzultaci s mým vedoucím diplomové práce, který mi maximálně vyšel vstříc a neměl žádné námitky ani ke změně z původního tématu, ani k rozsahu a složitosti této aplikace a po odsouhlasení tématu vedoucím katedry, jsem se rozhodl pojmout tvorbu aplikace jako svou diplomovou práci. Aplikaci jsem nazval CRM & billing system (CRM z Customer Relationship Management). 2 Použité technologie a metodiky V této části textu se budu věnovat stručnému přehledu metodik a technologií, které jsou používány k podpoře analýzy a návrhu informačních systémů. Diskuze o zvolených implementačních technologiích a použitých nástrojích bude uvedena v další, implementační části práce. 2.1 Dostupné metodiky (a technologie) 2.1.1 Co je metodika a co technologie V současné době je k dispozici mnoho více čí méně používaných metodik a technologií, které slouží k podpoře tvorby specifikace, analýzy a návrhu informačních systémů (dále jen IS). Metodikou je míněna definice metod či technik včetně jejich vzájemných vztahů a návazností, které se k tvorbě IS používají. Můžeme také říci, že metodika je nauka o určitých postupech. Slovem technologie označujeme nějaký nástroj (v našich souvislostech většinou nějaký grafický jazyk), který daná metodika používá. Ve většině případů je však obojí skryto za termínem metodika. Typickým sloučením výše uvedených dvou termínů je metodika OMT (Object Modeling Technique) od J. Rumbaugha. Obsahuje jak definici vývojových etap (z nichž hlavní jsou analýza, návrh a implementace) a používaných modelů (objektový, dynamický a funkční) jakožto samotné metodiky, tak definici technologie, kterou zde tvoří bližší popis používaných modelů spolu se způsoby jejich modelování a syntaxí užívaných diagramů. Oproti této metodice dnes velmi známy jazyk pro vizualizaci, specifikaci, navrhování a dokumentaci programových systému UML (Unified Modeling Language) představuje pouze nástroj, čili technologii pro modelování. V další části této kapitoly již budu používat pouze termín

2 Kapitola 2. Použité technologie a metodiky metodika, neboť i v odborné literatuře, která se věnuje tomuto tématu, se pojmy technologie a metodika v souvislostech analýzy a návrhu vzájemně překrývají. 2.1.2 Stručný přehled Metodiky používané pro analýzu (a následný návrh) můžeme obecně rozdělit na datové, strukturované, objektové, založené na UML a post-uml. Datová analýza označuje ve většině případů proces návrhu vhodného uložení dat. Pokud zůstaneme u ještě stále nejpoužívanějších relačních databází, je tím míněna definice tabulek a jejich položek včetně vztahů mezi nimi. V souvislosti s relačními databázemi je dnes velmi používáno ER modelování s jeho ER diagramy. V objektové metodice koresponduje s ER diagramem diagram tříd. Strukturované metodiky analýzy zahrnují více modelů (datový a více funkčních). Patří mezi ně známá metoda SSADM (The Structured System Analysis and Method), jejíž postup vývoje odpovídá standardnímu životnímu cyklu softwarového díla nebo velmi podobnému cyklu vodopád. Jako další s velmi podobnými vlastnostmi lze jmenovat metodiku Modern Structured Analysis od E. Yourdona. Nevýhodou strukturovaných metodik je fakt, že ukončení jedné fáze vývoje tvoří vstupní bod do fáze další. Pokud se toto dodržuje důsledně a v počátečních fázích nastane nějaká chyba, stojí její následná oprava hodně úsilí a prostředků. Nespornou výhodou je však dokumentace všech vývojových etap a s tím související možnost určení v jaké fázi se projekt nalézá. Postupy typu vodopád se dnes často kombinují s častým jednotkovým testováním a objektovým přístupem. Počátek analýzy pomocí objektové metodiky sahá na začátek 90tých let minulého století. S rozvojem objektového programování přichází metodiky jako OOA/OOD (Object-Oriented Analysis/Object-Oriented Design) od pánů Coada a Yourdona, které vyzdvihují modelování reálného světa na základě objektů (každé podstatné jméno je vlastně objekt) a jejich chování (metody objektu). Z dalších můžeme jmenovat OMT (Object-Oriented Modeling) od J. Rumbaugha, nebo metody pánů Boocha nebo Jacobsona. Objektově orientované metodologie kladou oproti strukturovaným důraz na souhru a komunikaci mezi jednotlivými úseky vývoje systému. Mezi metodiky založené čistě na jazyce UML patří UP (Unified Process) a URP (Unified Rational Process), který z něj vychází. Tyto metodiky jsou inkrementální a iterativní. To si můžeme představit jako několikanásobné opakování životního cyklu vodopád na jednotlivé části vývoje systému. Metodiky nazvané post-uml přicházejií s hodně odlišným přístupem k vývoji softwaru. Jejich stavební kameny tvoří prototypování a silné testování nejen výsledného systému nebo jeho částí, ale i všech malých jednotek. Vývoj pak probíhá tak, že se vytvoří nejprve hrubý prototyp, který je předložen zákazníkovi a dle jeho požadavků se upravuje, vylepšuje a opatřuje novými vlastnostmi.

Kapitola 2. Použité technologie a metodiky 3 2.2 Použité metodiky (a technologie) Při analýze a návrhu mé aplikace jsem se nedržel striktně žádné z výše uvedených metodik. Podle mého názoru nemá přesné dodržování jednotlivých kroků některé metodiky, v případě méně rozsáhlého systému (na kterém pracuje navíc jen jeden vývojář), přílišný smysl a podle některých autorů může být toto i u velkých projektů zhoubným faktorem. Metodika UP (URP) popisuje kompletní postup objektově orientované analýzy, návrhu a tvorby software, který je dle mého názoru správný (pominu-li post-uml metody, které můžeme těžko srovnávat s klasickými metodikami), nicméně tvorba veškeré definované dokumentace by byla časově velmi náročná a v mém případě zbytečná. Zvolil jsem tedy postup, který odpovídá klasickému vývojovému cyklu IS a byl přednášen v předmětech softwarového inženýrství (dále jen SI) v kombinaci s iterativní metodou, která je dnes víceméně běžná. Jedná se tedy o strukturovanou metodu (úvodní studie, analýza, návrh, implementace, testování a instalace), která je podpořena modelovacími technikami z jiných metodik a doplněna o iterativní způsob vlastní realizace cílového systému. Iterativním způsobem realizace rozumím to, že výsledný stabilní systém vznikne v rámci několika verzí. První, alfa verze systému bude výchozí pro další a její vytvoření jsem si stanovil za cíl této práce. Rozdíl tohoto postupu od klasické iterativní metody je v tom, že požadavky na systém jsou již předem známy (strukturovaná část), ale alfa verze je nemusí implementovat úplně všechny (měla by implementovat stěžejní části aplikace a být připravena na jednoduché napojení dalších částí). U klasického iterativního postupu vznikají nové požadavky v průběhu vývoje, což podle mého názoru u aplikace opírající se o strukturu databáze není šťastný způsob. Sled jednotlivých fází strukturované části vývoje IS je prakticky totožný s metodikou Modern Structured Analysis od E.Yourdona. Použité techniky jsou však jiné. Jako hlavní modelovací nástroj jsem použil jazyk UML. V úvodní studii jsem si pro kontextový diagram propůjčil DFD (Data Flow Diagram) z OOA/OOD od výše zmíněného E. Yourdona a pro databázové modelování metodu ERM (Entity Relationship Modeling) a její ER diagram. 2.2.1 UML UML je v softwarovém inženýrství univerzální grafický jazyk pro vizualizaci, specifikaci, navrhování a dokumentaci programových systémů. Nabízí standardní způsob zápisu, jak návrhů systému včetně konceptuálních prvků jako jsou business procesy a systémové funkce, tak konkrétních prvků jako jsou příkazy programovacího jazyka, databázová schémata a znovupoužitelné programové komponenty. UML podporuje objektově orientovaný přístup k analýze, návrhu a popisu programových systémů. Neobsahuje však způsob, jak se má používat, ani neobsahuje metodiku(y), jak analyzovat, specifikovat či navrhovat programové systémy. Důvodem mého výběru UML jakožto hlavní technologie použité pro analýzu a návrh je právě výše uvedený fakt, že podporuje objektový přístup, nicméně je univerzální a nepředepisuje žádnou metodiku. Můžeme ho tedy používat dle vlastního uvážení pro modelování prakticky čehokoliv. Dalším důvodem mého výběru je předešlá praxe s tímto nástrojem z předmětů SI.

4 Kapitola 2. Použité technologie a metodiky 2.2.1.1 Použité a dostupné diagramy UML Při analýze a návrhu jsem samozřejmě nepoužil všechny dostupné prostředky tohoto jazyka. Pro mou potřebu bohatě stačily jen některé prvky, zejména pak stavové diagramy, diagramy aktivit a užití. Následuje přehled dostupných diagramů včetně jejich rozčlenění do skupin: strukturní diagramy o diagram tříd (class diagram) o diagram komponent (component diagram) o diagramy vlastní struktury (composite structure diagram) o diagram nasazení (deployment diagram) o diagram balíčků (package diagram) o diagram objektů (object diagram), též se nazývá diagram instancí diagramy chování o diagram aktivit (activity diagram) o diagram užití (use case diagram) o stavový diagram (state machine diagram) diagramy interakce o sekvenční diagram (sequence diagram) o diagram komunikace (communication diagram, dříve collaboration diagram) o diagram časování (timing diagram) 2.2.2 ER modelování Pro datovou analýzu a s ní spjatý návrh struktury databáze jsem si vybral metodu ER. Podle mého názoru věrně vystihuje fyzickou situaci uvnitř relačního SŘBD (Systém Řízení Báze Dat) a mám s touto metodou poměrně dobré zkušenosti. Datovou analýzu jsem pak složil ze dvou hlavních částí. Ze samotného ER diagramu a z popisu reprezentace dat s bližší specifikací identifikátorů ukládaných dat a jejich typů.

Kapitola 3. Úvodní studie 5 3 Úvodní studie 3.1 Rámcový plán projektu Celý projekt můžeme rozdělit do pěti hlavních částí. Mezi nimi může vést velmi tenká hranice a zejména části úvodní studie a analýzy mnoho autorů nedělí stejně nebo je naopak slučují do části jedné analytické. Mé rozdělení je následující: Úvodní studie vytyčení cílů a hrubá definice požadavků na budoucí software stanovení hranic systému a případů užití Analýza podrobné stanovení požadavků na systém datová analýza (návrh databázové struktury a reprezentace dat) modelování některých částí systému (stavové diagramy/diagramy aktivit) Návrh návrh vlastních tříd systému (členění systému, komponenty) návrh uživatelského rozhraní definice akceptačních tesů a testů použitelnosti Implementace alfa verze vlastní implementace včetně jednotkového testování integrace modulů včetně integračního testování (korektnost spolupráce modulů) tvorba instalační sady Testování a instalace alfa verze tvorba instalační příručky instalace u zákazníka validační a systémové testování Iterativní dokončení vývoje na základě alfa verze V této části projektu se začne vývoj ubírat směrem spíše extrémního programování, testování bude probíhat v prostředí provozu a hlášené chyby (se kterými se samozřejmě počítá) budou postupně odstraňovány. Dále budou doimplementovány dosud nerealizované funkčnosti (se kterými však bude od začátku počítáno). Tato část bude probíhat až po skončení práce na tomto textu.

6 Kapitola 3. Úvodní studie 3.2 Deklarace záměru Cílem práce je navrhnout a implementovat softwarový produkt, který bude programovým řešením fakturačního a evidenčního systému malé telekomunikační společnosti BCH. Aplikace by měla usnadnit celkový přehled a orientaci v zákaznické databázi společnosti a to zejména pomocí její snadné editace a filtrování výpisů podle různých kritérií. Dále bude podporovat vytváření detailních výpisů hovorů, tvorbu faktur, seznamů kreditních karet a dalších materiálů. Export informací do XLS formátu a jejich tisk by měly rovněž zefektivnit další zpracování informací. Tvorba reportů s výnosy a náklady za dané období (statistických přehledů) a evidování činnosti jednotlivých uživatelů systému by mohla být výhodná pro vedení společnosti. 3.2.1 Hlavní rysy aplikace import vstupního, textového souboru s výpisy hovorů za dané období a jeho uložení do databáze (soubor poskytuje provider hovorů) import různých verzí sazebníku a jejich uložení v databázi (CSV formát) evidence zákazníků společnosti tvorba detailních výpisů hovorů k danému číslu tvorba faktur pro zákazníky na základě výpisů a sazebníků a jejich evidence podpora exportu do formátu XLS, tisku a zasílání emailů evidování činnosti uživatelů Systém bude navržen s ohledem na maximální spolehlivost a další rozšiřitelnost. Přesto, že je primárně určen pro běh na platformě Windows, bude díky zvolené implementační technologii Java multiplatformní. 3.3 Odborný článek Hlavní motivací projektu CRM & billing system je požadavek malé telekomunikační společnosti na vytvoření aplikace pro evidenci zákaznické agendy a tvorbu fakturací s výpisy hovorů za dané fakturační období. Aplikace by měla usnadnit orientaci v zákaznické databázi a zautomatizovat proces vystavování faktur a tvorby zmiňovaných výpisů hovorů. Systém se bude skládat ze dvou částí. První část, která bude tvořit jakési datové základy celého systému, bude reprezentována relačním databázovým systémem. Systém řízení báze dat (dále jen SŘBD) se bude starat o korektní uložení všech informací, které má aplikace uchovávat a bude nainstalován na serveru, nebo nějaké permanentně běžící stanici, která se tímto stane databázovým serverem. Existuje mnoho SŘBD, ale naše aplikace bude vystavěna na software MySQL 5.0 Community Edition (dále jen MySQL). Je to spolehlivý, léty a uživateli prověřený databázový server a existuje k němu veškerá potřebná dokumentace a spousta nástrojů, které jsou jako samotné MySQL zdarma k dispozici. Druhá část systému bude tvořena klientskou stranou aplikace. Z pohledu uživatele bude tvořit vlastně celý program, neboť komunikace klientské a serverové části bude probíhat zcela transparentně.

Kapitola 3. Úvodní studie 7 Ponechme nyní stranou členění systému a role jeho jednotlivých částí a berme ho jako jednu kompaktní aplikaci. Tato aplikace bude zajišťovat několik funkcí. Jednak funkci CRM (Customer Relationship Management), neboli funkci zákaznického adresáře, který mimo kontaktních údajů udržuje i další informace spjaté se zákazníkem (například evidování plateb nebo vystavených faktur). Dalšími funkcemi aplikace budou: vystavování faktur za provedené hovory, vystavování detailních výpisů hovorů, tvorba reportů prezentujících shrnutí výnosů a nákladů společnosti k danému období, spravování ceníků hovorů, podpora tisku, exportu do a importu z XLS formátu a zasílání emailů. Dále bude systém podporovat evidenci plateb jednotlivých zákazníků (včetně přehledu neplatičů), přípravu obálkových štítků pro tisk a v neposlední řadě také logování činnosti uživatelů systému a částečnou integraci s klientským desktopem (používání výchozího poštovního klienta, aplikace dávkového tisku, ). K zákazníkům bude systém uchovávat jak základní kontaktní informace jako jsou jméno, příjmení, adresa a kontaktní telefon, tak adresy kontaktních osob (neboť zákazníkem nemusí být jen samotná fyzická osoba ale i společnost), informace o zákaznických číslech, platbách a tvořených fakturách. Dále se budou evidovat záznamy o zákaznickém servisu a problémových hlášeních a jiné podstatné informace. Co se týče ceníků hovorů. Systém jich bude moci evidovat libovolné množství. Zdrojem dat ceníků budou textové soubory pevného formátu. Soubor bude obsahovat vždy destinaci a sazbu. Aplikační rozhraní umožní jednoduchý import ceníku do systému včetně jeho pojmenování a záznamu data importu. Data o provedených hovorech jednotlivými zákazníky zasílá zprostředkovatel hovorů v textovém souboru pevně daného formátu. Tyto soubory jsou dvojího druhu, bez ohledu na význam jmen (v tomto kontextu není význam podstatný) jeden je pro CS/CPS zákazníky a druhý pro 800 zákazníky. Informace obsažené v souborech jsou stejné, nicméně formát se liší. Aplikace bude podporovat oba vstupní formáty. Importem dat s výpisy hovorů vznikne nový projekt. Vytváření faktur, detailních výpisů hovorů a reportů s přehledem výnosů a nákladů bude vždy probíhat v rámci nějakého projektu. Dá se říci, že jeden vstupní soubor bude tvořit jeden projekt a jeden projekt bude tvořit jedno fakturační období pro danou skupinu zákazníků. K projektům se bude možno vracet, což zajistí jejich ukládání do databáze (ostatně jako kterékoliv jiné persistentní datové části s výjimkou některých nastavení). Vytvoření detailního výpisu hovorů se bude provádět automaticky po založení projektu. Zobrazí se přehled všech čísel, ze kterých bylo v rámci daného projektu voláno. Ke každému číslu systém přiřadí jméno zákazníka a název sazebníku, dle kterého jsou danému číslu účtovány ceny za provedené hovory. Tento přehled bude umožňovat detailní náhled na libovolné číslo, který zobrazí seznam všech realizovaných hovorů z daného čísla s informací o jejich délkách, tarifu, celkové ceně a dalších podstatných atributech. Pokud bude nalezeno číslo, které nevlastní žádný evidovaný klient, zobrazí se varovné hlášení. Stejně tak zobrazí program varování, pokud bude nalezena destinace volání, ke které neexistuje v používaném ceníku sazba (neboli destinace se v ceníku nevyskytuje). Výpis hovorů (k danému číslu) půjde exportovat do souboru formátu MS Excel (XLS). Vzhled listů v souboru bude určovat šablona.

8 Kapitola 3. Úvodní studie Pro vystavení faktury budou používány informace ze zákaznického adresáře (zejména pak kontaktní informace a typ platby) a z projektu, v jehož rámci bude faktura vystavována. Aplikace bude muset nejprve vystavit výpisy hovorů ke každému zákaznickému číslu a exportovat je do formátu XLS. Každý výpis bude obsahovat celkovou účtovanou cenu za dané číslo. Tyto výpisy projdou manuální kontrolou zaměstnanci společnosti, která bude provedena v MS Excel. Po kontrole dojde k zpětnému importu výsledných cen (za jednotlivá čísla) ze souborů s výpisy ve formátu XLS do systému. Pomocí těchto cen program poté vystaví zákazníkům faktury. Částka na faktuře bude sumou za všechna klientská čísla. Primárním fyzickým cílem faktury bude soubor XLS, jehož vzhled se bude (stejně jako u výpisu hovorů) řídit šablonami. Vystavování faktur by šlo samozřejmě více zautomatizovat, nicméně uvedený postup je specielním přáním společnosti BCH. Další zajímavou vlastností vytvářeného software by měla být možnost zasílání emailu přímo z aplikačního rozhraní. Systém by měl podporovat zasílání hromadných zpráv skupinám zákazníků, které bude možné vybírat ručně nebo dle určitých kritérií (zejména dle typu zákazníka). Systém by měl rovněž podporovat užití výchozího poštovního programu pracovní stanice. Tisk obálkových štítků a složenek by měl rovněž ulehčovat práci. V systému se budou vyskytovat dva typy uživatelů. Privilegovaný a normální. Jediný rozdíl mezi nimi bude ten, že privilegovaný uživatel bude moci zakládat uživatelské účty. Každý, kdo bude se systémem pracovat, se bude muset nejprve přihlásit svým uživatelským jménem a heslem. Tento mechanismus poslouží primárně k evidování činnosti uživatelů (v tomto kontextu zaměstnanců). Vedlejším, ale neméně podstatným účelem bude zamezení škody, která by mohla vzniknout při přístupu nezasvěceným uživatelem. Ke každému uživateli bude systém evidovat jeho soukromé nastavení, zejména pak systémové cesty k adresářům zdrojů a cílu dat a nastavení jména a zpětné adresy elektronické pošty. Nastavení bude vztaženo vždy k uživateli a pracovní stanici. Poslední uložené nastavení bude rovněž zálohováno v databázi. V důsledku to znamená, že ke každému uživateli bude po přihlášení do systému načteno jeho nastavení pro klientskou stanici u které se právě nachází. Pokud na disku stanice nebude nalezeno jeho uložené nastavení, vytvoří se nové na základě dat načtených z databáze (nastavení, které uložil z nějaké stanice naposledy nebo prázdné nastavení). Každý uživatel bude mít možnost měnit si své vlastní heslo, privilegovaný pak měnit všechna hesla. Co se týče zabezpečení ukládaných dat ve smyslu zálohování databáze to systém řešit nebude. Přenechá toto specifikum správci serveru, na kterém poběží používaný SŘBD. Vzhledem k charakteru výše zmíněného MySQL postačí pouze pravidelná a kompletní záloha adresáře, kde budou nainstalované datové soubory serveru. Implementace databáze, jakožto oddělené časti systému, přináší několik výhod. Jednou z nich je jednoduchá přenositelnost dat do libovolného jiného prostředí (například při změně SŘBD může zůstat stávající klientská aplikace nebo naopak při změně klientské aplikace budou všechna data nadále k použití). Uvažovali-li bychom do budoucna, bylo by možné vytvořit např. internetovou aplikaci, kde by si mohli uživatele prohlížet informace o svých provedených hovorech, jejich cenách, atp. a měnit kontaktní informace na sebe a kontaktní

Kapitola 3. Úvodní studie 9 osoby. Dále by bylo možné zařídit přístup k této databázi z libovolného místa s přístupem na www a tím umožnit práci i z jiných lokací než z kanceláře společnosti. 3.4 Diagram kontextu 3.4.1 Bližší specifikace kontextu Ilustrace 3.1 - Kontextový diagram 1.a) plnění zákaznické databáze, zakládání a rušení projektů, tvorba faktur, výpisu a reportů, zasílání emailů, tisk, exportování do XLS,PDF, HTML,RTF, import z XLS, změna hesla, změna nastavení, ostatní nutné vstupy pro práci se systémem 1.b) zobrazování přehledů uživatelů a čísel, informace o fakturách, informace o výsledcích exportu do XLS, importu z XLS a zasílání emailu, přehledy neplatičů, zobrazování průběhu delších činností systému, ostatní reakce na práci uživatele 2.a) jako 1.a + správa uživatelských účtů systému 2.b) jako 1.b + zobrazování historie kteréhokoliv uživatele 3.a) potvrzení platnosti kreditních karet, potvrzení plateb (do systému zanese uživatel) 3.b) odeslání faxu s výpisem kreditních karet pro jejich validaci (fyzicky uživatelem)

10 Kapitola 3. Úvodní studie 3.5 Případy užití Níže uvedené případy užití (Use Cases) vznikaly postupně v rámci několika sezení se zákazníkem. Při jejich vytváření jsem postupoval metodou shora dolů, tedy nejprve jsem se snažil vyhledat nejobecnější případy, které jsem po diskusi vždy rozvinul do podrobnějších diagramů. Jak se později ukázalo, byl tento způsob výhodný, neboť sám zákazník si při komunikaci uvědomil spoustu aspektů, které by ho při pouhém vytváření výčtu požadavků na systém vůbec nenapadly. 3.5.1 Diagramy případů užití 3.5.1.1 Výchozí Use Case diagram Ilustrace 3.2 - Use case diagram nejvyšší úrovně Na obrázku 3.2 je zobrazen use case diagram nejvyšší úrovně, tedy nejnižšího detailu rozpracování. Diagram by měl být věrnou grafickou kopií odborného článku s vynechanými detaily. Levá část zobrazuje funkčnosti systému, které by měla obsahovat první alfa verze, určená k nasazení a testování u zákazníka. Pravá část diagramu (tedy funkčnosti přístupné pouze privilegovanému uživateli) není pro společnost BCH významná a bude v alfa verzi pouze připravena (kompletní podpora v databázi, ale jen částečná na klientské straně).

Kapitola 3. Úvodní studie 11 3.5.1.2 Use Case diagramy většího detailu Na následujících několika ilustracích jsou k vidění podrobněji rozpracované případy užití z ilustrace 3.2. Diagramy budou sloužit jako výchozí body pro pozdější implementaci jednotlivých funkčností cílové aplikace. Měly by graficky znázorňovat jednotlivé uživatelské požadavky na systém a dokumentovat tak hrubé chování aplikace. Use Case diagramy budou později zároveň oporou pro akceptační testování. Nebude totiž možnost pro napadení aplikace z hlediska chybějící klíčové funkčnosti, pokud tato nebude uvedena v nějakém z případů užití. Samozřejmě s ohledem na hrubý detail diagramů ve vztahu ke všem implementovaným podpůrným funkčnostem nutných pro korektní fungování klíčových funkčností, jež jsou vyjádřeny právě všemi případy užití. Ilustrace 3.3 - Větší detail případů užití Spravovat CDR projekty, Spravovat sazebníky a Spravovat klienty

12 Kapitola 3. Úvodní studie Ilustrace 3.4 - Větší detail případů užití Vytvářet výstupy, Tisknout a exportovat, Zasílat emaily a Spravovat uživatelské nastavení

Kapitola 3. Úvodní studie 13 Ilustrace 3.5 - Větší detail případů užití Spravovat uživatele 3.5.2 Textová specifikace některých případů užití Diagramy případů užití slouží primárně k určení aktérů a vymezení hranic systému. Přestože se jedná již o podrobnější analýzu, ponechávám i tuto část v úvodní studii, protože dle mého názoru diagramy případů užití dokreslují celkovou hrubou představu o fungování systému, což do úvodní studie nepochybně patří. Následuje textová specifikace některých případů užití. U všech se předpokládá, že je do systému přihlášen uživatel s příslušným oprávněním (tedy účastníkem případů je uživatel a vstupní podmínkou je přihlášení do systému). Alternativou k textové specifikaci mohou být diagramy aktivit, textová specifikace mi však přijde v tomto případě výhodnější. Založit projekt ID: UC-ZalozitProjekt ID: UC-SmazatProjekt Tok událostí: 1. Uživatel zvolí příkaz pro založení nového projektu. 2. Systém zobrazí formulářový dialog pro založení projektu. 3. Uživatel vyplní formulář. 3.1. zahrnout (UC-VybratVstupniSoubor) 4. Systém načte soubor a zkontroluje konzistenci dat (v klientské databázi jsou všechna čísla, která jsou ve vstupním souboru). 4.1. Systém dovolí uložit jen konzistentní data a v případě nutnosti zobrazí dialog. 5. IF(zobrazen dialog v 4.1) IF(uživatel zvolí uložit) 6 ELSE IF (uživatel zvolí vybrat nový zdroj) 4 ELSE IF (uživatel zvolí konec) BREAK 6. Systém uloží všechna konzistentní data a do logu uloží informaci o vytvoření nového projektu. Smazat projekt Tok událostí: 1. Uživatel vyvolá volbu pro přehled projektů. 2. Systém zobrazí dostupné projekty a nabídku akcí. 3. Uživatel vybere projekt a zvolí akci smazat. 4. Systém si vyžádá potvrzení ke smazání. 5. IF(uživatel zvolí v 4 ANO) 5.1. Systém smaže projekt a všechna s ním související data (všechny hovory provedené v rámci projektu a vytvořené faktury za dané hovory) 5.2. Systém uloží do logu záznam o vymazání příslušného projektu Textová specifikace případů užití 1 Založit projekt a Smazat projekt

14 Kapitola 3. Úvodní studie Vybrat vstupní soubor ID: UC-VybratVstupniSoubor ID: UC-ZalozitSazebnik Tok událostí: 1. Uživatel zadá volbu pro výběr vstupního souboru. 2. Systém zobrazí příslušný dialog. 3. Uživatel vybere soubor a potvrdí výběr. 4. Systém předá výběr nadřazené komponentě. Založit sazebník Tok událostí: 1. Uživatel zadá příkaz pro založení nového sazebníku. 2. Systém zobrazí formulářový dialog. 3. Uživatel vyplní údaje. 3.1. zahrnout (UC-VybratVstupníSoubor) 4. Systém načte vstupní soubor a pokud bude bez chyb uloží ho do databáze a zobrazí sazebník v tabulce. Textová specifikace případů užití 2 - Vybrat vstupní soubor a Založit sazebník Editovat klienta Spravovat kontaktní osoby ID: UC-EditovatKlienta ID: UC-SpravovatKontaktniOsoby Tok událostí: 1. Uživatel zadá příkaz pro editování klienta (poklepání na stávajícího nebo vytvoření nového) 2. Systém zobrazí formulář pro editaci uživatelských atributů. 2.1. zahrnout (UC-SpravovatKontaktniOsoby) 3. Uživatel provede potřebné změny 4. IF(uživatel zvolí uložit) 4.1. Systém uloží všechny změny provedené ve všech atributech a zároveň uloží záznam o provedených změnách do logu (kdo a jakou změnu vytvořil). 5. IF(uživatel zavře dialog) 5.1. Systém z kontroluje, jestli byly provedeny nějaké změny, když ano zobrazí dialog pro uložení. 5.1.1. IF(uložit ANO) 3.1 Tok událostí: 1. Uživatel zadá příkaz k editaci nebo vytvoření kontaktní osoby. 2. Systém zobrazí dialog s přehledem kontaktních osob daného zákazníka a jejich vlastnostmi. 3. Uživatel upraví nebo vyplní formulář. 4. IF(uživatel zavře dialog) informace budou zahozeny 4.1. ELSE IF(uživatel potvrdí OK) systém uloží všechny informace z formuláře a zaeviduje všechny změny do logu Textová specifikace případů užití 3 - Editovat klienta a Spravovat kontaktní osoby Vytvářet faktury Vytvářet seznam kreditních karet ID: UC-VytvaretFaktury ID: UC-SeznamKreditnichKaret Tok událostí: 1. Uživatel zadá příkaz pro vytvoření faktur. 2. Systém zobrazí dialog pro vytvoření faktur. 3. Uživatel vyplní všechny požadované údaje. Zejména pak cesty k souborům s výpisy hovorů v XLS, které budou obsahovat konečné ceny za číslo. 4. Systém importuje ze zadaných souborů klientské telefonní číslo a cenu za provedené hovory. 4.1. Systém přiřadí importované údaje k zákazníkům a vytvoří datový model faktur ke každému zákazníkovi jedna faktura s výslednou cenou za všechna jeho telefonní čísla. 4.2. Systém exportuje datové modely faktur do formátu XLS do uživatelem zadané složky. 5. IF(uživatel zvolil uložení faktur do databáze) systém uloží data faktur do databáze (přiřadí fakturu ke zvolenému projektu a k danému klientovi). Tok událostí: 1. Uživatel zadá příkaz pro vytvoření seznamu kreditních karet pro ověření bankou. 2. Systém vyhledá v rámci aktivního projektu klienty,kteří mají nastavený typ platby kreditní kartou a mají vytvořenou fakturu. 3. Systém vytvoří a zobrazí náhled na seznam kreditních karet s částkami k úhradě. 4. Uživatel zvolí požadovanou akci (tisk nebo export) nebo dialog zavře. 4.1. IF(uživatel zvolí tisk) systém zobrazí standardní tiskový dialog a po potvrzení provede tisk. 4.2. ELSE IF (uživatel zvolí export) systém zobrazí dialog pro zvolení cíle exportu a po potvrzení provede export Vstupní podmínka: Otevřený nějaký projekt Textová specifikace případů užití 4 - Vytvářet faktury a Vytvářet seznam kreditních karet

Kapitola 3. Úvodní studie 15 Zasílat emaily ID: UC-ZasilatEmaily ID: UC-VybratPrijemce Vybrat příjemce Tok událostí: Tok událostí: 1. Uživatel zadá příkaz pro zaslání emailu. 1. Systém zobrazí dialog s přehledem klientů a 2. Systém zobrazí nové okno integrovaného SMTP kontaktních osob, kterým je možné zaslat email. klienta. 2. Uživatel provede výběr (ručně nebo pomocí filtrů). 3. Uživatel zvolí akci. 3. Po potvrzení systém předá seznam cílových adres 3.1. IF(uživatel zvolí výběr příjemců) zahrnout nadřazené komponentě (internímu klientovi nebo (UC-VybratPrijemce) výchozí poštovní aplikaci). 3.2. IF(uživatel zvolí výběr příloh) zahrnout (UC-VybratPrilohy) 3.3. IF(uživatel zvolí použití výchozí aplikace) zahrnout (UC-PouzitVychoziEAplikaci) 4. Po potvrzení systém odešle email. - Zahrnuté případy UC-VybratPrilohy a UC-PouzitVychoziAplikaci nemá význam rozepisovat. Textová specifikace případů užití 5 - Zasílat emaily a Vybrat příjemce 3.6 Stanovení dosažitelných cílů vlastní diplomové práce Každému projektu a jeho části, by se měly na počátku stanovit reálně dosažitelné cíle. Jinak by tomu nemělo být ani u diplomové práce. První z cílů této práce (analýza potřeb) je zhotovení úvodní studie a analytické dokumentace k celému projektu (úvodní studie je již hotová). Jedná se tedy o jasné vymezení hranic systému a podrobné zjištění všech požadavků na cílový systém. Druhým cílem je provedení návrhu struktury systému s ohledem na možnost co nejméně komplikovaného dalšího rozšíření na základě vytvořené analytické dokumentace. V realizační části práce bych rád implementoval první verzi systému, která by měla obsahovat kompletně odladěnou serverovou část, tedy databázi, podporující všechny definované požadavky na systém a alfa verzi klientské části aplikace, jež by měla implementovat stěžejní části cílové aplikace - tedy pro uživatele transparentní jádro komunikující s databází a připravenou podporu všech významných rysů projektu (Vlastní logika firemního procesu, tedy počítání výsledných fakturovaných cen, tvorba reportů, faktur a výpisů hovorů. Dále pak metody pro tisk, zasílání emailů, export a import z XLS formátu a logování uživatelských činností.). Do uživatelského rozhraní (dále GUI), které znamená pro uživatele vlastní program, bych rád napojil implementaci nejvíce žádaných požadavků na cílový systém (což by měla být pouhá kombinace prvků z transparentního jádra aplikace a prvků GUI). Dalším cílem práce je vytvoření instalačního balíčku z celé aplikace, který ještě před odevzdáním tohoto textu nainstaluji u zákazníka a tím odstartuji druhou polovinu celkového projektu testování a opravování vzniklých chyb a dokončení implementace méně náročných prvků systému, což by podle mého odhadu mělo být pouze dodělání GUI ve smyslu implementace metod akčních prvků rozhraní za použití již implementovaných složitějších funkčností.

16 Kapitola 3. Úvodní studie

Kapitola 4. Analýza 17 4 Analýza V této části textu budou zformulovány analyzované potřeby společnosti BCH a to ve formě podrobného katalogu požadavků. Z katalogu požadavků dále vyplývá model databáze, který je velmi podstatný pro korektní funkčnost celého systému. Na tomto místě bych se rovněž rád zmínil o procesu získávání informací od zákazníka. V teorii SI je tradováno, že tato úloha patří k jedné z nejpodstatnějších a nejtěžších v celém průběhu analýzy. Tento fakt mohu jen potvrdit. Osobně jsem absolvoval několik jednání, jejichž hlavní náplní bylo získání odpovědí na mé dotazy. Přestože se některé mé otázky neměnily, odpovědi na ně byly pokaždé o něco jiné. Iterativním způsobem došlo nakonec k určité shodě, jejíž výsledky jsou uvedeny dále. 4.1 Slovníček používaných pojmů a zkratek BCH 800 vstup BDE CDR CDR projekt CLI CLI skupina CPS CRM CS CS/CPS vstup CVC DIČ DRM GPL IČ JRE MDB OpenSource Report SŘBD klientská společnost jeden ze dvou typů vstupního souboru s informacemi o provedených hovorech od poskytovatele, sloupce v něm jsou odděleny tabulátorem Borland Database Engine (softwarový nástroj, který používají aplikace psané v Delphi pro práci s datovými zdroji) detailní výpis hovorů k jednomu CLI celek, obsahující všechny CDR výpisy a jiné informace za jedno fakturační období a danou skupinu zákazníků; skupina zákazníků je určena typem vstupního souboru (800 nebo CS/CPS) jedno zákaznické číslo klientská čísla se mohou sdružovat do skupin (například jeden klient může mít více poboček, každá pobočka je pak jedna CLI skupina) typ služby, kde předvolbu vytáčí operátor Customer Relationship Management (software pro správu zákaznické databáze) typ služby, kde předvolbu vytáčí zákazník jeden ze dvou typů vstupního souboru s informacemi o provedených hovorech od poskytovatele, sloupce v něm jsou odděleny středníkem verifikační kód platební karty identifikační číslo plátce daně dceřiná společnost společnosti BCH General Public Licence (typ licence) identifikační číslo Java Runtime Enviroment (software, který umožňuje běh aplikací napsaných v jazyce Java) typ databázových souborů MS Access software s volně dostupným zdrojovým kódem dokument s rozepsaný předběžnými výnosy a náklady za daný CDR projekt Systém Řízení Báze Dat (neboli databázový server ve smyslu software) Tabulka 4.1 Slovníček pojmů a zkratek

18 Kapitola 4. Analýza 4.2 Současné fakturační řešení 4.2.1 Stručná charakteristika Aplikace, kterou společnost BCH používá v současné době není zcela funkční, je napsána v Delphi a neexistují k ní zdrojové kódy. Databáze využívá datových souborů MDB, ke kterým přistupuje pomocí BDE a neumožňuje evidovat všechny požadované informace. Funkčnosti aplikace obsahují chyby, které náhodně způsobují neuložení zadaných údajů nebo pád celé aplikace. Korektně funguje export do XLS, pomocí něhož jsou vytvářeny faktury a výpisy hovorů, které jsou rovněž správné. Aplikace nepodporuje tisk ani zasílání emailů a ve vytvořených reportech se vyskytují chyby. 4.2.2 Migrace stávajících dat Jak jsem se již zmínil, data jsou ukládána do prostředí MS Access. Data projektů a informace o nich se ukládají do binárních souborů neznámého formátu a jejich migrace je prakticky nemožná, nicméně není vůbec nutná. To se nedá říci o zákaznických datech. Jejich migrace se bude řešit skrze různá proprietální řešení. V úvahu by zde přicházela dvě možná řešení. První z nich je připojení se ke stávající MDB databázi za pomocí ODBC rozhraní a vyřešit migraci přímo z aplikace nebo pomocí podpůrného modulu. Druhým způsobem by pak byl nejspíše export stávajících dat do CSV souboru a vytvoření skriptu, který soubor načte a uloží do nové databáze. Problematikou přenosu se v této práci zabývat nebudu, bude řešena až po nasazení aplikace, důkladném otestování a opravení chyb. 4.3 Podrobný katalog požadavků a bližší specifikace 4.3.1 Požadavky na HW a SW Co se týče potřebného HW, společnost BCH má vlastní, výkonnostně postačující stanice, na nichž je nainstalován operační systém platformy Windows NT 5.x. (XP). Jako minimální velikost operační paměti doporučuji 512 MB (vzhledem k nutnosti spouštění JRE a vytváření náhledů na tisk, které mohou zabírat poměrně velkou paměťovou kapacitu). Na serverové straně aplikace poběží systém řízení báze dat MySQL 5.0 Community Edition. Tento software je dostupný pod licencí GPL, tedy zcela zdarma. Je léty prověřený uživateli a vzhledem k tomu, že se jedná o OpenSource projekt, je stále vyvíjen a zlepšován. Poslední stabilní verze je 5.0. Nároky na HW jsou zde minimální, vzhledem k tomu, že na serveru nebude běžet jen tento SŘBD, doporučuji alespoň PIII-660MHz s 512 MB RAM. 4.3.2 Požadavky na vytvářený software 4.3.2.1 Serverová část Serverová část aplikace bude tvořit jádro celého systému. Bude se opírat o databázový systém MySQL, jež bude uchovávat veškerá data se kterými bude manipulováno. Evidované informace jsou uvedeny níže. V závorkách jsou poznámky upřesňující danou položku nebo významnější implementační detail.

Kapitola 4. Analýza 19 4.3.2.1.1 Informace uchovávané o zákaznících obecné název společnosti (možnost uchování dvou názvů) jméno kontaktní osoby (společnost) (možnost více osob) příjmení, jméno a titul (osoba) IČ, DIČ adresy fakturační a korespondenční adresa - ulice, číslo popisné, PSČ, město, stát kontaktní osoby telefon mobilní telefon (možno i více) fax email (možno i více) - použít email k zasílání CDR? www druh platby bankovním převodem kreditní kartou složenkou inkasem hotově a jinak typ zákazníka (možnost editovat typy) typ vyúčtování na BCH na DRM poznámky kreditní karta typ karty (možnost editovat typy) číslo karty CVC platnost do (upozorňování před vypršením) poznámky nastavení pro výpisy hovorů (CDR) zasílat CDR emailem? (checkbox) seznam emailových adres pro zasílání (určeno z kontaktních osob) seznam telefonních čísel zákazníka (CLI) CLI skupiny vystavené faktury a jejich nastavení typ faktury, která se vystavuje inkaso kreditní karta převod složenka cash

20 Kapitola 4. Analýza seznam vystavených faktur (možnost nahlédnout na detaily) zasílat faktury emailem? (checkbox) problémová hlášení datum nahlášení (resp. vytvoření záznamu) zaměstnanec BCH, který hlášení zaevidoval datum uzavření řešení problému zaměstnanec BCH, který hlášení uzavřel název klienta (z db) kontaktovat do kontaktovat na číslo problém problémová čísla (CLI) popis problému technický partner jméno technického partnera (název firmy) kontaktní informace číslo poznámky k výsledku řešení zákaznický servis datum kontaktování BCH zákazníkem důvod volání sdělení 4.3.2.1.2 Informace evidované k fakturám datum vystavení datum splatnosti variabilní symbol číslo má tvar <ROK>00<CISLO_FAKTURY> CISLO_FAKTURY je pro první fakturu v každém novém roce 1 ROK se vztahuje k fakturačnímu období a ne k roku, kdy je faktura vystavena datum uhrazení uhrazeno?(checkbox) částka částka v USD 4.3.2.1.3 Informace sazebníků jméno sazebníku verze sazebníku datum jeho importu do systému samotné informace o sazbách destinace X sazba

Kapitola 4. Analýza 21 4.3.2.1.4 Informace o klientských číslech a o všech provedených hovorech Data z této části databáze budou sloužit k vytváření vlastních výpisů a fakturací. Prakticky se jedná o seznam všech poskytovaných telefonních čísel a o informace ze vstupních souborů s výpisy hovorů. informace k číslu (CLI) číslo (CLI) typ služby CS (nutno vytáčet předvolbu) CPS (předvolbu vytáčí operátor) typ čísla pevná linka fax mobilní vlastník (klient) CLI skupina informace o hovorech (v závorkách jsou uvedeny odpovídající názvy ze vstupního souboru s výpisem) klientské číslo CLI (ORIGINAL NUMBER) volané číslo (DESTINATION NUMBER) datum (DATE) čas (TIME) délka trvání hovoru (DURATION) cena jedné minuty hovoru (RATE) cena hovoru, naúčtovaná poskytovatelem (AMOUNT) účtovací měna (CURRENCY) pásmo (špička, mimo špičku) (Period) destinace volání (DESTINATION) mezinárodní destinace (INTERNATIONAL DESTINATION) 4.3.2.1.5 Systémové informace uživatelé jméno příjmení email telefon uživatelské jméno uživatelské heslo oprávnění logování přístupů uživatelů datum a čas přihlášení do systému (2 měsíce zpět) datum a čas odhlášení ze systému (2 měsíce zpět)