Vývoj fakturační softwarové aplikace pro obchodníka s elektřinou

Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Vyšší odborná škola informačních služeb v Praze Martin Skatula Vývoj fakturační softwarové aplikace pro obchodníka s elektřinou Bakalářská práce 2010

Zadávací list

Prohlášení: Prohlašuji, že jsem bakalářskou práci na téma Vývoj fakturační softwarové aplikace pro obchodníka s elektřinou zpracoval samostatně a použil pouze zdrojů, které cituji a uvádím v seznamu použité literatury. V Praze dne 20. 12. 2010... Podpis studenta

Poděkování Děkuji svému vedoucímu bakalářské práce RNDr. Juliu Janovskému za pomoc při tvorbě této práce.

Anotace Cílem této bakalářské práce je zpracování průběhu návrhu, implementace a testování nové funkce do stávající fakturační aplikace. Práce obsahuje postup, který je znázorněn na ukázkovém příkladu změny data splatnosti faktury. V teoretické části jsou popsány rigorózní a agilní metodiky vývoje softwaru. Praktickou část tvoří základní popis aplikace a postup zpracování změny aplikace včetně zdrojového kódu. Výsledkem práce je funkční změna aplikace ve výpočtu data splatnosti. Annotation The aim of this bachelors work is to work up the process of the design, implementation and testing of the new function into already existing invoicing application. The work consists of the procedure which is demonstrated on the example of maturity date change of the invoice. Rigorous and agile methods of software development are described in the theoretical part. The practical part consists of the basic description of application and the procedure of processing the change of this application including the source code. The outcome of this work is the functional change of application in the way how the application calculates the maturity date of the invoice.

Obsah 1. Úvod... 8 Teoretická část... 9 2. Softwarový proces... 10 2.1. Modely softwarového procesu... 10 2.1.1. Vodopádový model... 10 2.1.1.1. Roycův konečný model... 11 2.1.1.2. Sašimi model... 13 2.1.2. Rational Unified Process... 13 2.1.3. Extrémní programování... 16 2.1.4. Feature driven development... 19 Společnost ALPIQ ENERGY SE... 22 3. O systému... 23 3.1. Invoicing Client... 23 3.1.1. Definice pojmů... 23 3.1.2. Základní datový model... 24 3.1.2.1. Tabulka C_Customer... 24 3.1.2.2. Tabulka CO_Contract... 25 3.1.2.3. Tabulka IGH_InvoicingGroupHeader... 26 3.1.3. Datový model fakturace... 27 3.1.3.1. Fakturace velkoobchodu (wholesale)... 28 3.1.3.2. Fakturace maloobchodu (Retail)... 30 Praktická část... 31 4. Specifikace požadavků... 32 4.1. Zadání... 32 4.1.1. Funkcionalita... 32 5. Analýza... 33 5.1. Analýza současného stavu... 33 5.1.1. Datový model... 33 5.1.2. Výpočet data splatnosti... 33 5.2. Analýza zadání... 34 6. Návrh řešení... 35 6.1. Návrh realizace... 35 6

6.1.1. Definice parametrů... 35 6.1.2. Příklad... 36 6.1.3. Technický postup... 36 6.1.3.1. Datový model... 37 6.1.3.2. Pravidla výpočtu... 37 6.1.3.2.1. Pohyblivý... 37 6.1.3.2.2. Fixní (FixedDueDate)... 38 6.2. Schválení návrhu... 38 7. Implementace... 39 7.1. Datová vrstva... 39 7.1.1. Tabulky... 39 7.1.2. Uložené procedury... 40 7.2. Aplikační vrstva... 42 7.2.1. Kódování... 43 7.2.1.1. Konstruktor... 43 7.2.1.2. Metody... 43 8. Testování... 47 8.1. Příprava testovacího serveru... 47 8.1.1. Přenos databáze... 47 8.1.2. Přenos změn... 47 8.1.3. Naplnění nově vytvořených tabulek... 47 8.2. NUnit (regresní) testy... 48 8.2.1. Výsledky regresních testů... 49 8.3. Akceptační testy... 50 9. Produkční verze... 51 9.1. Přenos databáze... 51 9.2. Instalace... 51 9.3. Dokumentace... 51 9.4. Předání aplikace... 51 10. Závěr... 52 11. Seznam použitých zdrojů... 53 12. Seznam použitých zkratek... 54 7

1. Úvod Hlavním cílem bakalářské práce Vývoj fakturační softwarové aplikace pro obchodníka s elektřinou je zpracovaní řešení změny fakturační aplikace společnosti ALPIQ ENERGY SE, aby vyhovovalo zadaným požadavkům. Práce obsahuje tři části. První část teoretická, se zaměřuje na čtyři zástupce metodik vývoje tak, jak byla svými tvůrci popsána. Každé z těchto metod je věnována samostatná kapitola. Druhá část se věnuje přestavení společnosti ALPIQ ENERGY SE a základním popisu fakturační aplikace. Třetí část praktická, se zabývá samotným vývojem změny v aplikaci. Popisuje reálné řešení problému v šesti kapitolách, kde je čtenář seznámen se zadáním, návrhem, implementací a testováním provedených změn. Pro splnění cíle bylo nutné využít poznatků z objektově orientovaného programování a ze znalostí jazyka SQL. 8

Část I Teoretická část 9

2. Softwarový proces Softwarovým procesem rozumíme po částech uspořádanou množinu kroků směřujících k vytvoření nebo úpravě softwarového díla. 2.1. Modely softwarového procesu Za desítky let vývoje softwarových systémů se objevila celá řada modelů určujících, jak by měl takový softwarový proces vypadat. Dodnes však neexistuje detailně a přesně definovaná podoba softwarového procesu, který by mohl být přijat jako referenční. Přesto lze konstatovat, že základem téměř všech modelů se stal tzv. vodopádový model, který je možno v různých modifikacích a rozšíření nalézt ve většině současných přístupů. [1, s. 8 9] 2.1.1. Vodopádový model Jako první tento model představil Winston W. Royce (1925 1995); paradoxně se však jednalo o příklad chybného vývojového modelu. Původně chtěl představit dokonalejší iterační model a poukázat na chyby vodopádu. Vodopádový model se tak stal jedním ze základních modelů používaných pro vývoj softwaru, který využívá přímý postup bez možnosti vracet se, modifikovat předchozí části nebo nechávat tyto části otevřené pro pozdější doplnění. Winston W. Royce popsal životní cyklus softwarového díla jako sedm oddělených, samostatných, na sebe navazujících částí, viz obrázek 2.1.1 1. Obrázek 2.1.1 1: Vodopádový model 10

Základní části modelu jsou: systémové a softwarové požadavky, analýza a návrh softwarového systému, implementace a testování včetně udržování vytvořeného produktu. Princip vodopádu spočívá v návaznosti činností, které mohou započít až po skončení činnosti předchozí. Znamená to tedy, že uzavřenou část nelze později modifikovat a není ani umožněna práce na dvou částech najednou. [2, s. 1 2] Existuje zjednodušená forma modelu, která rozděluje cyklus na čtyři základní fáze, viz obrázek 2.1.1 2. Nejčastěji se tato forma využívá u menších projektů, kde nemá význam oddělovat specifikaci od analýzy. Obrázek 2.1.1 2: Vodopádový model Hlavní podstata vodopádového modelu spočívá především v jeho jednoduchosti. Po prvotním seznámení se s obrázkem a pochopením jeho základních vlastností, je ihned pochopena jeho funkčnost, která funguje i v jeho použití. Proto je vodopád často používán jako základní model k vysvětlování problému metodik. Z důvodu chybějící zpětné vazby s sebou model přináší řadu nedostatků, kterými jsou zejména: Dlouhá prodleva mezi zadáním projektu a vytvořením spustitelné verze systému. Výsledek je závislý na úplnosti a přesnosti zadání požadavků na výsledný produkt. Před dokončením výsledného softwarového systému nelze odhalit kvalitu produktu. [1, s. 9 10] Odstranění těchto zásadních nedostatků vedlo ke vzniku mnoha modifikací základního vodopádového modelu. Takovou modifikací je například původní Royceův iterační model. [3] 2.1.1.1. Roycův konečný model Winston W. Royce ve své modifikaci usiluje o zavedení neexistující zpětné vazby mezi jednotlivými fázemi, viz obrázek 2.1.1.1 1. Dále zavádí zpětnou vazbu z návrhu do požadavků na software a z testování do návrhu, které jsou znázorněné na obrázku 2.1.1.1 2. Zdůvodněním je jednoduchost obou fází a minimální dopad na zbylé fáze. [2, s. 2 3] 11

Obrázek 2.1.1.1 1: Zpětná vazba v Royceově modelu 1 Obrázek 2.1.1.1 2: Zpětná vazba v Royceově modelu 2 12

2.1.1.2. Sašimi model Další modifikaci vodopádového modelu zastupuje sašimi model přestavený Peterem DeGracem. Podstata spočívá v překrývání jednotlivých fází, viz obrázek 2.1.1.2 1. Na rozdíl od původního modelu, který vyžaduje ukončování fází před započetím nové fáze, sašimi modifikace striktně ruší oddělování fází. Tak například fáze návrhu a implementace se mohou překrývat, takže implementační problémy mohou být objeveny během fáze návrhu, jakož i během fáze implementace vývojového procesu. Velikost překrytí není v šasimi modelu definována. Může tedy nastat situace, kdy bude souběžně probíhat více fází, nebo, v případě malého překrytí, se může model blížit původnímu vodopádu, kdy současně probíhá pouze jedna fáze. Nevýhodou sašimi modifikace je vytváření méně zřetelných hranic mezi jednotlivými fázemi a neschopnost určení fáze, ve které se projekt právě nachází. [3] Obrázek 2.1.1.2 1: Překrývání v sašimi modelu 2.1.2. Rational Unified Process Proces Rational Unified Process (RUP) je rigorózní metodika vývoje softwaru, která vznikla spoluprací řady velkých firem se společností Rational. Proces RUP definuje přístup k přiřazování úkolů a zodpovědnosti v organizacích zabývajících se vývojem softwaru. Jeho cílem je zajištění vysoké kvality vytvořeného produktu v daném časovém rozsahu a zadaném rozpočtu. Metodika klade největší důraz na iterační vývojový cyklus, vizuální modelování a častou komunikaci se zákazníkem. Základní princip spočívá v dodržení sady těchto šesti bodů používaných při vývoji softwaru: Iterativní vývoj softwaru (Develop Software Iteratively) Pokud se týká rozsáhlého softwarového produktu, není v současné době možné nejprve celý problém nejprve přesně definovat, poté navrhnout jeho řešení, následně veškeré zadání implementovat a na závěr vše otestovat a nasadit. Jediným možným řešením je tak přistupovat k jednotlivým problémům v iteracích. To spočívá v rozdělení celého projektu na čtyři fáze, z nichž se každá skládá z několika iterací podobných klasickému vodopádovému modelu, viz obrázek 2.1.2 1. Výsledkem každé iterace je spustitelný software. [1, s. 10 11] 13

Obrázek 2.1.2 1: Iterativní vývoj softwaru V rámci každé iterace probíhají činnosti vázané na byznys modelování, následují specifikace požadavků, analýza a návrh, implementace, testování a nasazení (instalace). Snadná správa požadavků (Manage Requirements) U vodopádového přístupu se nepřipouští změna požadavků v průběhu projektu. Naproti tomu RUP jasně definuje koncepci, která spočívá ve stálém kontaktu zadavatele s vývojovým týmem, umožňující průběžné úpravy požadavků v projektu. Využití existujících komponent (Use Component Based Architectures) RUP stanovuje systematický přístup k definování architektury systému s použitím nových a existujících komponent. Komponentou se v tomto kontextu označují netriviální části systému zajišťující funkcionalitu. Projekt tak lze snáze rozdělit mezi několik vývojářských týmů a umožňuje postupnou tvorbu systému. Rational Unified Process podporuje standardní komponentové infrastruktury COM a CORBA. Důraz na vizualizaci vyvíjeného softwaru (Visually Model Software) Moderní nástroje poskytují vhodné grafické znázornění systému, které zpřehledňují návrh a udržují tak konzistenci mezi modelem a vlastní implementací. Základem pro vizualizaci modelů je jazyk UML. Průběžné testování produktu (Verify Software Quality). Pro zajištění požadované kvality jsou v RUP kladeny velké nároky na spolehlivost, funkčnost a výkon aplikace. Nástrojem k dodržení těchto kritérií je průběžné testování. Testování tak stojí v hlavní linii vývoje produktu, které je realizováno speciální skupinou. Snadné řízení změn (Control Changes to Software) Možnost provádění změn v pozdějších fázích vývoje s sebou přináší řadu problémů v řízení a dokumentaci projektu. RUP těmto problémům předchází pomocí verzování softwaru. Jedná se o vytvoření složky (repozitáře), do které každý programátor zaznamenává a současně zdokumentovává každou změnu ve zdrojovém kódu. Výsledkem je velmi kvalitní a podrobný popis iterací vývoje aplikace se snadným zpětným vrácením změn. [4, s. 3 4] Proces tak lze popsat ve dvou dimenzích, které odpovídají osám na obrázku. 14

Obrázek 2.1.2 2: Fáze a disciplíny RUP Horizontální osa představuje dynamický pohled na proces, který je vyjádřen pomocí cyklů, fází, iterací a milníků. Vertikální osa reprezentuje statické hledisko procesu, popis činností, artefaktů, pracovníků a pracovních postupů. Na obrázku je na vertikální ose znázorněno 9 tzv. disciplín, které představují logické seskupení činností. Graf ukazuje podíl jednotlivých disciplín v různých fázích projektu. [5, s. 122] Životní cyklus softwaru je rozdělen na cykly, přičemž předmětem každého cyklu je nová verze produktu. Cyklus lze v RUP rozdělit do čtyř po sobě jdoucích fází, z nichž každá je zakončena tzv. milníkem. Po dokončení každé fáze se posuzuje, zda byly splněny požadované cíle. Další postup projektu je možné zahájit pouze v případě splnění všech požadovaných kritérií kladených na tu kterou jednotlivou fázi. Průběh jednotlivých fází je následující: Zahajovací fáze (Inception) Během této fáze se vymezí projekt, na jehož základě se definují cíle a způsob, kterým bude celý systém vyvíjen a implementován. Elaborační fáze (Elaboration) Fáze věnovaná podrobné definici architektury systému, specifikaci požadavků, stručného plánu iterací a definici komponent, které je třeba vyvinout pro opakované použití. Konstrukční fáze (Construction) Předposlední fáze je zaměřena na dokončení návrhu, realizace a testování první funkční verze systému. Fáze nasazení (transition) Hlavním účelem této fáze je zajištění finální verze systému koncovým uživatelům. V jejím průběhu se provádí beta testování, zapracovávají se drobné úpravy na základě připomínek uživatelů a dokončují se úpravy odložených funkcí. Součástí je i školení uživatelů, předání dokumentace a vytvoření podpory systému. V této fázi by již nemělo docházet k žádným zásadním změnám funkcionality softwaru. Připomínky 15

zadavatele by se měly týkat pouze instalace, konfigurace a odlaďování drobných chyb zjištěných při testovacím provozu. [4, s. 5 9] V průběhu všech fázi projektu probíhají opakovaně následující disciplíny: Byznys modelování (Business modeling) Zahrnuje tvorbu podnikového modelu a podnikových procesů. Specifikace požadavků (Requirements) Úspěch projektu závisí na splnění požadavků (kritérií). Je proto třeba požadavky evidovat a dokumentovat pro případné změny. Analýza a návrh (Analysis & Design) Disciplína, která definuje architekturu systému včetně členění komponent. Implementace (Implementation) Úkolem implementace je převést návrh modelu do spustitelné podoby, tj. vytvoření komponent a spustitelného programu. Testování (Test) Slouží k ověření funkčnosti implementovaných komponent. Nasazení (Deployment) Disciplína pro předání softwaru koncovým uživatelům. Řízení změn a konfigurací (Configuration and Change Management) Disciplína sloužící pro řízení verzování softwaru a koordinaci implementace změn. Projektové řízení (Project Management) Pro plánování a koordinaci prací na projektu slouží projektové řízení. Současně tato disciplína zajišťuje potřebné personální a materiální zdroje. Prostředí (Environment) Disciplína pro stanovení pravidel jednotlivých činností a příslušných nástrojů. [5, s. 121 123] 2.1.3. Extrémní programování Mezi nejznámější a nejpoužívanější zástupce agilní 1 metodiky vývoje softwaru patří Extrémní programování (XP). Vytvořila ji skupina odborníků okolo Kenta Becka v roce 1996. XP předepisuje všem účastníkům vývoje činnosti, vycházející z běžných principů a postupů vývoje softwaru, které jsou dovedeny do extrémů. Metoda je založena na velmi krátkých iteracích, jež jsou zachyceny na obrázku 2.1.3 1 a dále popsány. [6, s. 10 13] Základní aktivity XP jsou velmi podobné předešlým popsaným modelům. Patří mezi ně: plánování, návrh, programování, testování. 1 Metodiky, které umožňují vytvořit řešení velmi rychle a pružně je přizpůsobovat měnícím se požadavkům. 16

Obrázek 2.1.3 1: Praktiky XP XP zavádí 13 základních a jednoduchých postupů. Tým jako celek (Whole Team) Zákazník je základem týmu složeného z manažerů, programátorů a testerů, který stanovuje základní specifikace projektu. Plánovací hra (Planning Game) Plánování v XP je dialog mezi manažery a programátory, při němž se řeší tyto okruhy problémů: zadání požadavků zákazníka, určení priorit jednotlivých požadavků a určení důležitých termínů. Každý požadavek se definuje jako tzv. uživatelský příběh (user story). Při plánovací hře zákazník pouze určuje hrubý plán projektu, který je zpřesňován po každé iteraci. Malá verze (Small Releases) Výsledkem každé iterace je funkční verze projektu s implementovanými požadavky zákazníka. Nové verze jsou uvolňovány do provozu tak často, jak je to jen možné. Nejsou tedy výjimkou denní či týdenní změny verzí, které přinášejí programátorům velmi rychlou zpětnou vazbu. Zákaznické testy (Customer Tests) Úspěšnost implementovaných požadavků ověřuje zákazník pomocí akceptačních testů, které sám specifikuje, a které vycházejí z uživatelských příběhů. Jejich používáním dokáže zákazník jasně definovat problém a předat ho programátorům. Metafora (Metaphor) Pro komunikaci v týmu existuje pomůcka nazvaná metafora. Metafora poskytuje 17

systém jmen a popisů architektury systému. Pomáhá pochopit prvky systému a vztahy mezi nimi v jazyce, kterému rozumí zákazník i programátor. Nepřetržitá integrace (Continuous Integration) Do funkčního systému se změny integrují několikrát denně. Jakmile je kód hotový, okamžitě proběhnou testy, které prověří funkčnost změny. Společné vlastnictví kódu (Collective Ownership). Žádná část projektu nemá svého vlastníka. Každý programátor má přístup ke kódu a může tak kdykoliv provést jeho změnu, refaktoraci či přidat testy. Tato praktika je základem pro párové programování a testy. Standardy pro psaní zdrojového kódu (Coding Standard) Pro psaní zdrojového kódu jsou vytvořeny konvence, které umožňují komunikaci prostřednictvím zdrojového kódu, udržují konzistentnost kódu a umožňují snadnou refaktorizaci. Jedná se zejména o sjednocené odsazování, pojmenovávání či psaní komentářů. Cílem je, aby v projektu nebylo poznat, který programátor určitou část napsal. Dodržování tohoto principu je nutným předpokladem pro praktiky párového programování a společného vlastnictví kódu. Udržitelný vývoj (Sustainable Pace) XP prosazuje názor, že unavení programátoři dělají více chyb, odvádí méně práce a produkují špatný kód. Proto XP stanovuje týdenní pracovní dobu s přesčasy trvající maximálně 1 týden. Metodologie XP výslovně přesčasy nezakazuje, v praxi jsou však využívány pouze v případě nutných rychlých zásahů. Jednoduchý návrh (Simple Design) XP prosazuje jednoduché návrhy, které řeší aktuální požadavky a které nelze dále zjednodušit. Budoucnost požadavku není v návrhu zahrnuta, řeší se jen to, co je požadováno. Párové programování (Pair Programming) U jednoho počítače pracují, společně při programování, dva programátoři. Zatímco první programátor píše kód, druhý vymýšlí testy k aktuálnímu kódu, radí a opravuje píšícího programátora nebo přemýšlí o refaktoringu. Páry si své role vyměňují a proces opakují. Páry v průběhu dne nejsou stálé, mohou se měnit i několikrát denně. Tento postup je velice efektivní, podněcuje komunikaci, sdílí a přenáší znalosti a zajišťuje dodržování praktik XP. Refaktorizace (Refactoring) Proces refaktorizace provádí změnu v projektu tak, že vylepší jeho strukturu a zároveň nezmění funkčnost softwarového systému. Jeho cílem je zjednodušení a zpřehlednění projektu. Společné vlastnictví umožňuje programátorům vylepšit jakýkoli kód při zachování srozumitelnosti nově refaktorovaného kódu. Tím je zároveň zajištěna zvyšující se kvalita projektu. Postup refaktorizace je zcela bezpečný, neboť je zajištěn vytvořenou sadou testů. Vývoj řízený testy (Test Driven Development) Princip vývoje řízeného testy (TDD) spočívá v tom, že se před začátkem implementace kódu nejdříve napíše jednotkový test (unit test) a až poté samotný kód. TDD se v XP hojně využívá k regresnímu testování a refaktorizace. Nové verze projektu vždy musí úspěšně projít všemi jednotkovými testy. Celý cyklus je znázorněn v diagramu aktivit na obrázku 2.1.3 2. [5, s. 148 152] [6, s. 52 64] [7] 18

Obrázek 2.1.3 2: Vývoj řízený testy 2.1.4. Feature driven development Druhou a zároveň poslední agilní metodikou, kterou představím, je Feature driven development (FDD). Tuto metodiku poprvé použil Jeff De Luca v roce 1997 a detailně ji popsal v roce 2002. FDD je zaměřená na užitné vlastnosti (feature) vyvíjeného systému, které se zakládají na iterativním a inkrementálním základu. Výsledkem je pro zákazníka srozumitelný, měřitelný a realizovaný užitek. Cílem tedy není splnění předepsaného procesu, ale vytvoření kvalitního a fungujícího produktu splňujícího požadavky zákazníka. [8, s. 51] Podobně jako u předešlých metodik vývoje softwaru, je FDD postaveno na skupině praktik a osvědčených postupů. Metodika nevyžaduje přijmout všechny praktiky naráz, pouze doporučuje jejich správnou kombinaci. Doménové objektové modelování (Domain Objec Modeling). Model využívá objektové modelování domény, tedy oblast, do které se následně zasazuje funkcionalita jednotlivých užitných vlastností. Pro zachycení důležitých typů objektů, jejich chování a vzájemných vztahů, model využívá především diagram tříd doplněných sekvenčními diagramy. Vývoj podle užitných vlastností (Developing by Feature) Vývoj je veden ve formě užitných vlastností (features) malých funkcí, které řídí další vývoj softwaru a mají hodnotu pro zákazníka. Individuální vlastnictví tříd (Individual Class Ownership) Na rozdíl od XP jsou jednotlivé části kódu (třídy) vlastněny programátorem, který má plnou odpovědnost za jejich implementaci, testování a integritu. Výhodou je snadná 19

dohledatelnost autora, jenž kódu rozumí. Tím jsou snadněji a hlavně rychleji vyřešitelné jakékoli úpravy. Týmy pro užitné vlastnosti (Feature Teams) Každou implementovanou užitnou vlastnostnost spravuje dílčí tým, který dočasně sdružuje vlastníky tříd, potřebné pro implementaci užitné vlastnosti. Týmy pro užitné vlastnosti vybírá hlavní programátor podle konkrétní funkcionality; z toho důvodu může být jedna osoba členem více týmů. Inspekce (Inspections) Během vývoje jsou naplánovány časté inspekce kvality návrhu a kódu. Důvodem je odstranění chyb, které během vývoje vznikají. Pravidelné buildy (Regular Builds) Pravidelná integrace všech hotových užitných vlastností a spuštění automatických testů, zaručují funkčnost celého projektu. Řízení konfigurací (Configuration Management) Sledování průběhu zdrojového kódu zaručuje možnost kdykoliv se vrátit k fungující části systému. Reporting/viditelnost výsledků (Reporting/Visibility of Results) Lepší plánování a organizace vývoje přispívají k minimalizaci a automatizaci sběru informací. To umožňuje kdykoliv sledovat, v jakém stavu se projekt nachází. FDD se skládá z pěti procesů, které umožňují vývojářům pracovat na potřebných částech projektu. Proces 1 Vypracování celkového modelu Při tomto procesu dochází k tvorbě hrubého modelu celé domény. Během něj spolupracují členové vývojového týmu s uživateli pod vedením hlavního architekta. Celý proces začíná uživatelskou prezentací úvodní představy systému, následuje vytvoření kostry modelu, která se dále podrobně specifikuje. Z výsledků se vybírá nejlepší řešení, jež se doplní o postřehy z ostatních řešení, ze kterého vznikne celkový model. Proces 2 Sestavení seznamu užitných vlastností Tento proces definuje seznam užitných vlastností vyvíjeného systému. Proces 3 Plánování užitné vlastnosti Pro plánování a realizaci seznamu užitných vlastností je vytvořen tým, který určí pořadí vývoje užitných vlastností. Proces 4 Návrh užitné vlastnosti Hlavní programátor určí třídy, kterých se užitná vlastnost týká a z příslušných vlastníků kódu vytvoří tým, který vypracuje návrh. Proces 5 Realizace užitné vlastnosti Poslední část obsahuje implementaci navržených tříd z předchozího procesu, která je každým vlastníkem otestovaná jednotkovými testy. 20

Obrázek 2.1.4 1: Procesy FDD První tři procesy jsou společné pro celý projekt; během nich se vytvoří celkový model a plán vytvořeného seznamu užitných vlastností. Následují dva procesy, které se střídavě opakují. V každé iteraci je od jednotlivých vlastníků tříd implementována požadovaná užitná vlastnost. [5, s. 135 138] 21

Část II Společnost ALPIQ ENERGY SE 22

3. O systému Informační systém společnosti ALPIQ ENERGY SE, která se zabývá obchodováním s elektřinou (výroba, nákup, prodej), se skládá z několika částí. Jde především o část plánovací, obchodní, fakturační a účetní. Každá část využívá jiné softwarové aplikace, vyvíjené různými společnostmi, které sbírají, udržují a zpracovávají data. Ve své bakalářské práci se zaměřím na vývojový model fakturačního softwaru, jenž je interně nazýván Invoicing Client. 3.1. Invoicing Client Invoicing Client (IC) je interní fakturační software vyvíjený společností ALPIQ ENERGY SE, který zajišťuje zpracování konečného vyúčtování dodané a prodané elektřiny. V současné době se software převážně využívá pro: fakturaci smluvených energetických profilů velkoobchodních (wholesale) zákazníků, fakturaci spotřebované energie maloobchodních (retail) zákazníků. Mimo jiné jsou v IC zabudované moduly pro: import příchozích faktur, export faktur do účetního softwaru SAP, import měřených spotřeb jednotlivých zákazníků, import predikčních profilů a jejich oceňování, kontrolu konzistence dat. Rozsah aplikace je nad rámec možností jedné osoby, tudíž celý proces vývoje obstarává tým lidí. Ten se skládá ze čtyř členů: projektového manažera, dvou vývojářů a testera. Je použita architektura klient server ve formě tzv. tlustého klienta. IC je napsán v jazyce C# a pro tvorbu využívá Microsoft Visual Studio 2008. Software je možné spustit pod systémem Microsoft Windows XP. Data jsou uložena na databázovém serveru se systémem Microsoft SQL Server 2003. Většina výpočtů probíhá v klientovi, server je využíván pouze jako centrální prvek uložených dat. Pro zpracování požadavků je využíván sašimi modifikace vodopádového modelu s použitím TDD principu v testovací fázi projektu. V současné chvíli se IC využívá na fakturaci tří entit české (CZ), polské (PL) a maďarské (HU). 3.1.1. Definice pojmů zákazník: smluvní partner, kontrakt: smlouva o sjednaném obchodu se zákazníkem, odběrné místo: místo napojení zákazníka na síť elektrické energie, energetický profil: množství energie nakoupené zákazníkem pro určité období, wholesale: velkoobchodní zákazník nakupující energetické profily, retail: maloobchodní zákazník vlastnící odběrné místo, fakturační skupina: skupina odběrných míst či energetických profilů, jejichž vyúčtování služeb je zákazníkovi vystaveno na jedné faktuře, servis: služba objevující se na vystavené faktuře, 23

counterparty: protistrana; interní označení zákazníka jednoznačným názvem (většinou zkratka názvu společnosti + řetězec _p ), energetická burza: místo prodeje a nákupu elektřiny, směr dodávky: odlišení nákupu a prodeje z pohledu ALPIQu. 3.1.2. Základní datový model Obrázek 3.1.2 1: Základní datový model IC Datový model IC je složen ze tří hlavních tabulek. C_Customer, CO_Contract a IGH_InvoicingGroupHeader (IGH). Tabulky CO_Contract a IGH_InvoicingGroupHeader jsou propojeny přes primární klíč tabulky C_Customer, tj. sloupce C_Id. Všechny názvy tabulek a sloupců jsou v korporátním jazyce společnosti angličtině. Nyní detailněji pohovořím o každé tabulce. 3.1.2.1. Tabulka C_Customer Obrázek 3.1.2.1 1: Tabulka C_Customer 24

Tabulka C_Customer slouží pro evidenci obchodních partnerů (zákazníků). Nejdůležitějšími sloupci pro fakturaci jsou: C_Id [int], tj. primární klíč tabulky a zároveň identifikátor zákazníka. C_ValidFrom [datetime] a C_ValidTo [datetime] určují platnost zákazníka. C_Cpty [varchar(50)] identifikuje counterparty. C_Option [int] určuje, zda se jedná o velkoobchodního nebo maloobchodního zákazníka. 3.1.2.2. Tabulka CO_Contract Obrázek 3.1.2.2 1: Tabulka CO_Contract Slouží pro úschovu sjednaných kontraktů s daným zákazníkem. Důležitost tabulky se postupem času snižuje. V důsledku potřeby různého nastavení fakturačních skupin 2 pod jedním kontraktem, jsou potřebné sloupce přemisťovány do tabulky IGH_InvoicingGroupHeader. 2 Vystavují se 2 a více faktur pro stejného zákazníka. 25

3.1.2.3. Tabulka IGH_InvoicingGroupHeader Obrázek 3.1.2.3 1: Tabulka IGH_InvoicingGroupHeader Výše uvedená tabulka patří při fakturaci mezi klíčové a slouží k uložení nastavení fakturačních skupin pro jednotlivé zákazníky. Přes cizí klíče jsou na tuto tabulku navázány např.: vytvořené faktury, servisy (jednotlivé řádky faktury), zálohové platby či odběrná místa (OPM). Mezi nejdůležitější sloupce pak patří: IGH_Id [int], tj. primární klíč tabulky a zároveň identifikátor fakturační skupiny. IGH_SC_Id [int] určuje, pod jakou entitou je daný záznam fakturován. IGH_CU_Id [int] definuje, v jaké měně bude vytvořena výsledná faktura. IGH_Periodicity [tinyint] zaznamenává, jak často se na fakturační skupinu vystavuje faktura v měsíčním období. IGH_CAH_Id [int] odkazuje na číselník typu kalendáře. IGH_RoundInvoice [tinyint] popisuje, na kolik desetinných míst má být faktura zaokrouhlována. IGH_InvoiceMaturityDays [smallint] určuje počet dní. 26

IGH_FirstPossibleDueDate [smallint] identifikuje první možný den data splatnosti faktury. IGH_InvoiceCalculationOption [int] na základě bitového součtu definuje možnosti výpočtu. Přes formulář v IC lze pomocí RadioButton prvků nastavit: Tabulka 3.1.2.3 1: Možnosti nastavení sloupce IGH_InvoiceCalculationOption Bit True False 1 Exchange rate in the last day of Exchange rate in invoice day period 2 InvoiceDutyDay based on working day InvoiceDutyDay based on calendar day 4 Use scheduled profile Use measured profile 8 Tax date = invoice date Tax date = end of invoice period 16 Tax date = due date Tax date = above 32 kwh MWh (stored quantity is divided by 1000) 64 Total prepayment (sum of amount) Normal prepayment 128 ER in the penultimate wednesday in ER according to first line the month 256 Due date based on end of invoice Due date based on invoice date period 512 Due date at the last day of invoice Due date according to line above period + 1 m. 1028 Due date at the first day of invoice Due date according to line above period 2048 Use bonus scheduled profile Use above selected profile Z této tabulky se mimo jiné vybírají podklady pro zobrazení tištěné faktury. Patří mezi ně: adresa (IGH_InvoicingAddress [nvarchar(255)]), IČO (IGH_INO [varchar(50)]), DIČ (IGH_VatId [char(30)]), telefonní číslo (IGH_Phone [varchar(30)]) a Fax (IGH_Fax [varchar(30)]). 3.1.3. Datový model fakturace V současné chvíli existují dva způsoby fakturace. Datové modely se od sebe liší tím, odkud energie pochází, zda ze spotřeby či z prodeje na burze. 27