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

Rozměr: px
Začít zobrazení ze stránky:

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

Transkript

1 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

2 Zadávací list

3 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 Podpis studenta

4 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.

5 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.

6 Obsah 1. Úvod... 8 Teoretická část Softwarový proces Modely softwarového procesu Vodopádový model Roycův konečný model Sašimi model Rational Unified Process Extrémní programování Feature driven development Společnost ALPIQ ENERGY SE O systému Invoicing Client Definice pojmů Základní datový model Tabulka C_Customer Tabulka CO_Contract Tabulka IGH_InvoicingGroupHeader Datový model fakturace Fakturace velkoobchodu (wholesale) Fakturace maloobchodu (Retail) Praktická část Specifikace požadavků Zadání Funkcionalita Analýza Analýza současného stavu Datový model Výpočet data splatnosti Analýza zadání Návrh řešení Návrh realizace

7 Definice parametrů Příklad Technický postup Datový model Pravidla výpočtu Pohyblivý Fixní (FixedDueDate) Schválení návrhu Implementace Datová vrstva Tabulky Uložené procedury Aplikační vrstva Kódování Konstruktor Metody Testování Příprava testovacího serveru Přenos databáze Přenos změn Naplnění nově vytvořených tabulek NUnit (regresní) testy Výsledky regresních testů Akceptační testy Produkční verze Přenos databáze Instalace Dokumentace Předání aplikace Závěr Seznam použitých zdrojů Seznam použitých zkratek

8 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

9 Část I Teoretická část 9

10 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 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] Vodopádový model Jako první tento model představil Winston W. Royce ( ); 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 Obrázek : Vodopádový model 10

11 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 Nejčastěji se tato forma využívá u menších projektů, kde nemá význam oddělovat specifikaci od analýzy. Obrázek : 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] 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 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 Zdůvodněním je jednoduchost obou fází a minimální dopad na zbylé fáze. [2, s. 2 3] 11

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

13 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 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 : Překrývání v sašimi modelu 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 Výsledkem každé iterace je spustitelný software. [1, s ] 13

14 Obrázek : 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

15 Obrázek : 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

16 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 ] 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 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 a dále popsány. [6, s ] 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

17 Obrázek : 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

18 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 [5, s ] [6, s ] [7] 18

19 Obrázek : Vývoj řízený testy 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 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

20 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

21 Obrázek : 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 ] 21

22 Část II Společnost ALPIQ ENERGY SE 22

23 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 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 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 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) 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

24 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 Základní datový model Obrázek : 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 Tabulka C_Customer Obrázek : Tabulka C_Customer 24

25 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 Tabulka CO_Contract Obrázek : 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

26 Tabulka IGH_InvoicingGroupHeader Obrázek : 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

27 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 : 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 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)]) 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

Návrh softwarových systémů - úvod, motivace

Návrh softwarových systémů - úvod, motivace Návrh softwarových systémů - úvod, motivace Jiří Šebek, Martin Tomášek Návrh softwarových systémů (B6B36NSS) Obsah Motivace Integrace s ostatními obory SI Kdo / co ovlivňuje cílový SW Modely, metodiky

Více

Návrh softwarových systém. Návrh softwarových systémů

Návrh softwarových systém. Návrh softwarových systémů Návrh softwarových systém ů - úvod, motivace Jiří Šebek Návrh softwarových systémů (B6B36NSS) Obsah Motivace Integrace s ostatními obory SI Modely, metodiky SI Verzování SW 2 Úvod Motivace SI Velké projekty

Více

Vývoj řízený testy Test Driven Development

Vývoj řízený testy Test Driven Development Vývoj řízený testy Test Driven Development Richard Salač, Ondřej Lanč Fakulta jaderná a fyzikálně inženýrská České vysoké učení technické v Praze 23. - 30. 10. 2012 Obsah 1 Testování 2 Klasický přístup

Více

Testování software. Jaroslav Žáček

Testování software. Jaroslav Žáček Testování software Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Testování Obsáhlá disciplína, existuje spoustu pohledů Problém při nastavení míry kvality Kvalita: Schopnost objektu být

Více

Vývoj informačních systémů. Přehled témat a úkolů

Vývoj informačních systémů. Přehled témat a úkolů Vývoj informačních systémů Přehled témat a úkolů Organizace výuky doc. Mgr. Miloš Kudělka, Ph.D. EA 439, +420 597 325 877 homel.vsb.cz/~kud007 milos.kudelka@vsb.cz Přednáška Znalosti Schopnosti Cvičení

Více

Metodika analýzy. Příloha č. 1

Metodika analýzy. Příloha č. 1 Metodika analýzy Příloha č. 1 Příloha č. 1 1 Účel dokumentu Dokument popisuje závaznou metodiku systémové analýzy, je upraven na míru pro prostředí Podniku. Dokument je provázán s Podnikovou analýzou,

Více

X36SIN: Softwarové inženýrství. Životní cyklus a plánování

X36SIN: Softwarové inženýrství. Životní cyklus a plánování X36SIN: Softwarové inženýrství Životní cyklus a plánování 1 Kontext Minule jsme si řekli, co to je deklarace záměru, odborný článek, katalog požadavků, seznam aktérů a seznam událostí. Seznam aktérů a

Více

ÚVOD DO SOFTWAROVÉHO INŽENÝRSTVÍ

ÚVOD DO SOFTWAROVÉHO INŽENÝRSTVÍ ÚVOD DO SOFTWAROVÉHO INŽENÝRSTVÍ Předmětem softwarového inženýrství jsou metodiky pro řízení vývoje softwaru. Proč potřebujeme tyto metodiky? Čím je vývoje softwaru specifický oproti jiným odvětvím? SOFTWAROVÉ

Více

Agilní metodiky vývoje softwaru

Agilní metodiky vývoje softwaru vývoje softwaru : důraz na průběžnou komunikaci mezi vývojovým týmem a zákazníkem důraz na tvorbu kvalitního kódu a funkcí, které mají přímou obchodní hodnotu pro zákazníka týmovou spolupráci a samoorganizaci

Více

Obsah. Zpracoval:

Obsah. Zpracoval: Zpracoval: houzvjir@fel.cvut.cz 03. Modelem řízený vývoj. Doménový (business), konceptuální (analytický) a logický (návrhový) model. Vize projektu. (A7B36SIN) Obsah Modelem řízený vývoj... 2 Cíl MDD, proč

Více

Vývoj informačních systémů. Přehled témat a úkolů

Vývoj informačních systémů. Přehled témat a úkolů Vývoj informačních systémů Přehled témat a úkolů Organizace výuky doc. Mgr. Miloš Kudělka, Ph.D. EA 439, +420 597 325 877 homel.vsb.cz/~kud007 milos.kudelka@vsb.cz Přednáška Teorie Praxe Cvičení Diskuze

Více

Ročníkový projekt. Jaroslav Žáček jaroslav.zacek@osu.cz

Ročníkový projekt. Jaroslav Žáček jaroslav.zacek@osu.cz Ročníkový projekt Jaroslav Žáček jaroslav.zacek@osu.cz Cíle předmětů Vytvoření fungující aplikace, která splňuje definované požadavky Vyzkoušet si celý životní cyklus projektu - specifikace zadání, formování

Více

Analýza a Návrh. Analýza

Analýza a Návrh. Analýza Analysis & Design Návrh nebo Design? Design = návrh Není vytváření použitelného uživatelského prostředí (pouze malinká podmnožina celého návrhu) Často takto omezeně chápáno studenty nedokáží si představit,

Více

Návrh IS - UML. Jaroslav Žáček

Návrh IS - UML. Jaroslav Žáček Návrh IS - UML Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ UML UML není metodikou ani programovacím jazykem, je to pouze vizuální modelovací nastroj pro objektově orientované systémy.

Více

MST - sběr dat pomocí mobilních terminálů on-line/off-line

MST - sběr dat pomocí mobilních terminálů on-line/off-line MST - sběr dat pomocí mobilních terminálů on-line/off-line Stručný přehled název: MST, software pro sběr dat mobilními terminály ve skladu (příjem, výdej, inventura) autor aplikace: FASK, spol. s r.o.,

Více

Návrh IS - UML. Jaroslav Žáček

Návrh IS - UML. Jaroslav Žáček Návrh IS - UML Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Trochu historie neuškodí Do roku 1994 chaos ve světě objektově orientovaných metod (několik jazyků pro vizuální modelování,

Více

KATALOG SLUŽEB NÁSLEDNÉ PODPORY

KATALOG SLUŽEB NÁSLEDNÉ PODPORY KATALOG SLUŽEB NÁSLEDNÉ PODPORY Společnost WEBCOM a. s. Vám nabízí kompletní pokrytí Vašich požadavků na zajištění služeb technické podpory Microsoft Dynamics přesně podle Vašich potřeb a v požadovaném

Více

SOFTWAROVÉ INŽENÝRSTVÍ Řízení IT projektů

SOFTWAROVÉ INŽENÝRSTVÍ Řízení IT projektů SOFTWAROVÉ INŽENÝRSTVÍ Řízení IT projektů Ing. Ondřej Macek 2013/14 ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE Historie 2 Jak vypadal vývoj SW? - Bylo třeba specifikovat zadání, to se naprogramovalo a pak se

Více

UML a jeho použití v procesu vývoje. Jaroslav Žáček jaroslav.zacek@osu.cz

UML a jeho použití v procesu vývoje. Jaroslav Žáček jaroslav.zacek@osu.cz UML a jeho použití v procesu vývoje Jaroslav Žáček jaroslav.zacek@osu.cz Různé pohledy na modelování Různé pohledy na modelování Unified Modeling Language UML není metodikou ani programovacím jazykem,

Více

PŘÍLOHA C Požadavky na Dokumentaci

PŘÍLOHA C Požadavky na Dokumentaci PŘÍLOHA C Požadavky na Dokumentaci Příloha C Požadavky na Dokumentaci Stránka 1 z 5 1. Obecné požadavky Dodavatel dokumentaci zpracuje a bude dokumentaci v celém rozsahu průběžně aktualizovat při každé

Více

TÉMATICKÝ OKRUH Softwarové inženýrství

TÉMATICKÝ OKRUH Softwarové inženýrství TÉMATICKÝ OKRUH Softwarové inženýrství Číslo otázky : 24. Otázka : Implementační fáze. Postupy při specifikaci organizace softwarových komponent pomocí UML. Mapování modelů na struktury programovacího

Více

Řízení reálných projektů, agilní metodiky

Řízení reálných projektů, agilní metodiky Agent Technology Group Katedra kybernetiky Fakulta elektrotechnická - České vysoké učení technické Praha, 2009 Osnova Lze vyvíjet software bez metodiky? - bohužel ano menší komerční firmy (zejména vývoj

Více

Základy analýzy. autor. Jan Novotný http://blog.novoj.net/ 15. února 2007

Základy analýzy. autor. Jan Novotný http://blog.novoj.net/ 15. února 2007 Základy analýzy autor Jan Novotný http://blog.novoj.net/ 15. února 2007 V prezentaci jsou použity diagramy z: Wikipedia, Sparx UML Tutorial, Argo UML Metodiky vývoje Různé metodiky vývoje vazba na fáze

Více

POČÍTAČE A PROGRAMOVÁNÍ

POČÍTAČE A PROGRAMOVÁNÍ POČÍTAČE A PROGRAMOVÁNÍ Moderní metody vývoje softwaru, Demontrační příklad piškvorky Miroslav Vavroušek PPI 09 V1.0 Opakovaní z minulé přednášky Vícerozměrná statická a dynamická pole Pole polí Datový

Více

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím

GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER. váš partner na cestě od dat k informacím GTL GENERATOR NÁSTROJ PRO GENEROVÁNÍ OBJEKTŮ OBJEKTY PRO INFORMATICA POWERCENTER váš partner na cestě od dat k informacím globtech spol. s r.o. karlovo náměstí 17 c, praha 2 tel.: +420 221 986 390 info@globtech.cz

Více

PRODEJ Prodej je pochopitelně základní funkcí pokladního systému. Systému MERCATOR umožňuje prodej realizovat ve 3 režimech:

PRODEJ Prodej je pochopitelně základní funkcí pokladního systému. Systému MERCATOR umožňuje prodej realizovat ve 3 režimech: MERCATOR Moderní pokladní systém od společnosti SICONET a.s. Co je MERCATOR MERCATOR je PC pokladní systém určený především maloobchodním a velkoobchodním prodejnám společností, jejichž podnikovým systémem

Více

Proces vývoje HRIS Vema (Human Resources Information System) Jaroslav Šmarda

Proces vývoje HRIS Vema (Human Resources Information System) Jaroslav Šmarda Proces vývoje HRIS Vema (Human Resources Information System) Jaroslav Šmarda Proces vývoje HRIS Vema Vlastnosti HRIS (Human Resources Information System) HRIS Vema Proces vývoje HRIS Vema Vema, a. s. Přední

Více

2. Začlenění HCI do životního cyklu software

2. Začlenění HCI do životního cyklu software Jan Schmidt 2011 Katedra číslicového návrhu Fakulta informačních technologií České vysoké učení technické v Praze Zimní semestr 2011/12 EVROPSKÝ SOCIÁLNÍ FOND PRAHA & EU: INVESTUJENE DO VAŠÍ BUDOUCNOSTI

Více

Prezentace CRMplus. Téma: CRMplus jako nástroj pro kontrolu a vyhodnocení rozpracovanosti dílů na zakázkách

Prezentace CRMplus. Téma: CRMplus jako nástroj pro kontrolu a vyhodnocení rozpracovanosti dílů na zakázkách Prezentace CRMplus Téma: CRMplus jako nástroj pro kontrolu a vyhodnocení rozpracovanosti dílů na zakázkách Obsah prezentace Představení společnosti Technodat Develop, s.r.o. CRMplus základní charakteristika

Více

Manažerská informatika - projektové řízení

Manažerská informatika - projektové řízení VŠE, fakulta Podnikohospodářská Manažerská informatika - projektové řízení Projekt implementace informačního systému Jiří Mikloš 2009 Obsah Obsah Obsah... 2 Úvod... 3 Zadání... 4 Projektový postup... 5

Více

XINF1. Jaroslav Žáček jaroslav.zacek@osu.cz

XINF1. Jaroslav Žáček jaroslav.zacek@osu.cz XINF1 Jaroslav Žáček jaroslav.zacek@osu.cz Tutoriály 24.10. - 3h 6.11. - 2,2h 27.11. - 1,5h Tutoriály budeme věnovat nejen teorii, ale také cvičení a workshopům. Přečtěte si skripta dříve, než týden před

Více

Vývoj informačních systémů. Jak vyvíjet v týmu

Vývoj informačních systémů. Jak vyvíjet v týmu Vývoj informačních systémů Jak vyvíjet v týmu Co je potřeba a co je podstatné? Lidé a jejich spolupráce Plány, pravidla, procesy, řízení Dokumentace Techniky a technologie Dlouhý čas Cílem je produkt (software)

Více

ČMSS: CRM systém pro efektivní práci s klienty

ČMSS: CRM systém pro efektivní práci s klienty Případová studie ČMSS: CRM systém pro efektivní práci s klienty Jak jsme společnosti ČMSS dodali moderní řešení pro řízení vztahů s klienty ČMSS: CRM systém pro efektivní práci s klienty Kvalitní poskytování

Více

METODIKA FEATURE-DRIVEN DEVELOPMENT NEOPOUŠTÍ MODELOVÁNÍ A PROCESY, A PŘESTO PŘINÁŠÍ VÝHODY AGILNÍHO VÝVOJE ing. Alena Buchalcevová, Ph.

METODIKA FEATURE-DRIVEN DEVELOPMENT NEOPOUŠTÍ MODELOVÁNÍ A PROCESY, A PŘESTO PŘINÁŠÍ VÝHODY AGILNÍHO VÝVOJE ing. Alena Buchalcevová, Ph. METODIKA FEATURE-DRIVEN DEVELOPMENT NEOPOUŠTÍ MODELOVÁNÍ A PROCESY, A PŘESTO PŘINÁŠÍ VÝHODY AGILNÍHO VÝVOJE ing. Alena Buchalcevová, Ph.D Katedra informačních technologií VŠE Praha nám. W.Churchilla 4,

Více

14.4.2010. Obsah přednášky 7. Základy programování (IZAPR) Přednáška 7. Parametry metod. Parametry, argumenty. Parametry metod.

14.4.2010. Obsah přednášky 7. Základy programování (IZAPR) Přednáška 7. Parametry metod. Parametry, argumenty. Parametry metod. Základy programování (IZAPR) Přednáška 7 Ing. Michael Bažant, Ph.D. Katedra softwarových technologií Kancelář č. 229, Náměstí Čs. legií Michael.Bazant@upce.cz Obsah přednášky 7 Parametry metod, předávání

Více

SQL Server Data Tools (SSDT) RNDr. David Gešvindr MVP: Azure MCSE: Data Platform MCSD: Windows Store

SQL Server Data Tools (SSDT) RNDr. David Gešvindr MVP: Azure MCSE: Data Platform MCSD: Windows Store SQL Server Data Tools (SSDT) RNDr. David Gešvindr MVP: Azure MCSE: Data Platform MCSD: Windows Store MCT david@wug.cz @gesvindr Osnova 1. Představení nástroje SQL Server Data Tools 2. Vývoj databáze přímo

Více

Principy UML. Clear View Training 2005 v2.2 1

Principy UML. Clear View Training 2005 v2.2 1 Principy UML Clear View Training 2005 v2.2 1 1.2 Co je touml? Unified Modelling Language (UML) je univerzálníjazyk pro vizuální modelování systémů Podporuje všechny životní cykly Mohou jej implementovat

Více

Úvod do databázových systémů

Úvod do databázových systémů Vysoká škola báňská Technická univerzita Ostrava Fakulta elektrotechniky a informatiky Úvod do databázových systémů Cvičení 8 Ing. Petr Lukáš petr.lukas@vsb.cz Ostrava, 2014 Opakování Entita Entitní typ

Více

Reporting. Ukazatele je možno definovat nad libovolnou tabulkou Helios Orange, která je zapsána v nadstavbě firmy SAPERTA v souboru tabulek:

Reporting. Ukazatele je možno definovat nad libovolnou tabulkou Helios Orange, která je zapsána v nadstavbě firmy SAPERTA v souboru tabulek: Finanční analýza Pojem finanční analýza Finanční analýza umožňuje načítat data podle dimenzí a tyto součty dlouhodobě vyhodnocovat. Pojem finanční analýza není nejpřesnější, protože ukazatele mohou být

Více

Informační systémy 2008/2009. Radim Farana. Obsah. Nástroje business modelování. Business modelling, základní nástroje a metody business modelování.

Informační systémy 2008/2009. Radim Farana. Obsah. Nástroje business modelování. Business modelling, základní nástroje a metody business modelování. 3 Vysoká škola báňská Technická univerzita Ostrava Fakulta strojní, Katedra automatizační techniky a řízení 2008/2009 Radim Farana 1 Obsah Business modelling, základní nástroje a metody business modelování.

Více

Úprava naměřených stavů

Úprava naměřených stavů Návod na používání autorizovaného software Úprava naměřených stavů V Ústí nad Labem 8. 10. 2010 Vytvořil: doc. Ing., Ph.D. Návod pro úpravu stavů_v1 1 z 9 8.10.2010 Obsah 1Úvod...3 2Instalace...4 3Spuštění

Více

SOFTWAROVÉ INŽENÝRSTVÍ Řízení IT projektů

SOFTWAROVÉ INŽENÝRSTVÍ Řízení IT projektů SOFTWAROVÉ INŽENÝRSTVÍ Řízení IT projektů Ing. Ondřej Macek 2013/14 ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE Historie 2 Jak vypadal vývoj SW? - Bylo třeba specifikovat zadání, to se naprogramovalo a pak se

Více

Allegro obchodní doklady

Allegro obchodní doklady Allegro obchodní doklady Modul obchodních dokladů nabízí vše, co je zapotřebí pro obchodování menších a středních firem. K dispozici je evidence nákupu a objednávek materiálu, systém pokrývá celý prodejní

Více

Lekce 9 - Migrace dat

Lekce 9 - Migrace dat Lekce 9 - Migrace dat 1 Cíle lekce...1 2 Co je migrace dat?...1 3 Cíle migrace dat...1 4 Parametry migrace dat...1 5 Procesy migrace dat...2 6 Projekt migrace dat...3 7 Zařazení projektu migrace do projektu

Více

Příloha 1 Specifikace předmětu plnění

Příloha 1 Specifikace předmětu plnění Příloha 1 Specifikace předmětu plnění Centrální zpracování Etapa V Tvorba kontrolních výstupů 1 Obsah ETAPA V - TVORBA KONTROLNÍCH VÝSTUPŮ PRO VPO... 3 1.1. Koncepční shrnutí... 3 1.2. Obsahová náplň etapy

Více

Agile Software Development

Agile Software Development Agile Software Development Agile Software Development Jiri Fabian www.jirifabian.net O čem to bude O metodologiích RUP Agile XP Scrum Co je softwarový vývoj Umění? Manufaktura? Modelování? Co je softwarový

Více

1. Integrační koncept

1. Integrační koncept Příloha č. 2: Technický popis integrace 1. Integrační koncept Z hlediska koncepčního budování Smart Administration na Magistrátu města Mostu je možno hovořit o potřebě integrace tří úrovní systémové architektury

Více

Databáze pro evidenci výrobků

Databáze pro evidenci výrobků Databáze pro evidenci výrobků Databáze ve formátu Microsoft Access je součástí systému, který řídí automatizovanou výrobní linku. Tabulka tblcharge obsahuje data o výrobcích a je plněna automaticky řídicím

Více

VYSOKÁ ŠKOLA BÁŇSKÁ TECHNICKÁ UNIVERZITA OSTRAVA

VYSOKÁ ŠKOLA BÁŇSKÁ TECHNICKÁ UNIVERZITA OSTRAVA VYSOKÁ ŠKOLA BÁŇSKÁ TECHNICKÁ UNIVERZITA OSTRAVA INFORMAČNÍ SYSTÉMY A DATOVÉ SKLADY Autosalón (semestrální projekt) ZS 2011-2012 Analýza Implementace Číslo skupiny: 2 Členové skupiny: Jmeno,příjmení,login

Více

Leady & MERK Integrace Microsoft Dynamics CRM s aplikacemi Leady a MERK

Leady & MERK Integrace Microsoft Dynamics CRM s aplikacemi Leady a MERK Integrace Microsoft Dynamics CRM s aplikacemi Leady a MERK Strana 1 z 12 Obsah 1. Leady... 3 a. Shrnutí... 3 b. Popis modulu... 3 c. Technické podrobnosti o modulu... 5 2. MERK... 6 a. Shrnutí... 6 b.

Více

5a. Makra Visual Basic pro Microsoft Escel. Vytvořil Institut biostatistiky a analýz, Masarykova univerzita J. Kalina

5a. Makra Visual Basic pro Microsoft Escel. Vytvořil Institut biostatistiky a analýz, Masarykova univerzita J. Kalina 5a. Makra Visual Basic pro Microsoft Escel Vytvořil Institut biostatistiky a analýz, Masarykova univerzita J. Kalina Cyklické odkazy a iterativní výpočty Zde bude stránka o cyklických odkazech a iteracích.

Více

Databáze MS-Access. Obsah. Co je to databáze? Doc. Ing. Radim Farana, CSc. Ing. Jolana Škutová

Databáze MS-Access. Obsah. Co je to databáze? Doc. Ing. Radim Farana, CSc. Ing. Jolana Škutová Databáze MS-Access Doc. Ing. Radim Farana, CSc. Ing. Jolana Škutová Obsah Principy a možnosti databází. Uložení dat v databázi, formáty dat, pole, záznamy, tabulky, vazby mezi záznamy. Objekty databáze

Více

DUM 12 téma: Příkazy pro tvorbu databáze

DUM 12 téma: Příkazy pro tvorbu databáze DUM 12 téma: Příkazy pro tvorbu databáze ze sady: 3 tematický okruh sady: III. Databáze ze šablony: 7 Kancelářský software určeno pro: 4. ročník vzdělávací obor: 18-20-M/01 Informační technologie vzdělávací

Více

Analýza a design na reálném projektu. Richard Michalský

Analýza a design na reálném projektu. Richard Michalský Analýza a design na reálném projektu Richard Michalský Agenda o Role analytika o Dokumentace (analytická) o Sběr a analýza požadavků o Fixace rozsahu Role analytika o Tvůrce požadavků o Zákazník zná své

Více

Seminární práce Vývoj informačního systému. Manažerská informatika 2 Ing. Miroslav Lorenc

Seminární práce Vývoj informačního systému. Manažerská informatika 2 Ing. Miroslav Lorenc Seminární práce Vývoj informačního systému Manažerská informatika 2 Ing. Miroslav Lorenc Vypracoval: Jan Vít (xvitj17) LS 2007/2008 1. ÚVOD...3 1.1. POPIS PROJEKTU...3 2. OBSAH PROJEKTU...3 2.1. SEZNAM

Více

TÉMATICKÝ OKRUH Softwarové inženýrství

TÉMATICKÝ OKRUH Softwarové inženýrství TÉMATICKÝ OKRUH Softwarové inženýrství Číslo otázky : 21. Otázka : Softwarový process. Jeho definice, modely a vyspělostní úrovně. Standardizovaný přístup pomocí RUP (Rational Unified Process). Obsah :

Více

MBI - technologická realizace modelu

MBI - technologická realizace modelu MBI - technologická realizace modelu 22.1.2015 MBI, Management byznys informatiky Snímek 1 Agenda Technická realizace portálu MBI. Cíle a principy technického řešení. 1.Obsah portálu - objekty v hierarchiích,

Více

Relační DB struktury sloužící k optimalizaci dotazů - indexy, clustery, indexem organizované tabulky

Relační DB struktury sloužící k optimalizaci dotazů - indexy, clustery, indexem organizované tabulky Otázka 20 A7B36DBS Zadání... 1 Slovníček pojmů... 1 Relační DB struktury sloužící k optimalizaci dotazů - indexy, clustery, indexem organizované tabulky... 1 Zadání Relační DB struktury sloužící k optimalizaci

Více

UDS for ELO. Univerzální datové rozhraní. >> UDS - Universal Data Source

UDS for ELO. Univerzální datové rozhraní. >> UDS - Universal Data Source Univerzální datové rozhraní UDS for ELO UDS pro ELO je univerzální datové rozhraní, schopné napojit systém pro archivaci a správu dokumentů ELO na libovolný datový zdroj a to bez nutnosti programování.

Více

Základy programovaní 3 - Java. Unit testy. Petr Krajča. Katedra informatiky Univerzita Palackého v Olomouci. 26.,27.

Základy programovaní 3 - Java. Unit testy. Petr Krajča. Katedra informatiky Univerzita Palackého v Olomouci. 26.,27. Základy programovaní 3 - Java Unit testy Petr Krajča Katedra informatiky Univerzita Palackého v Olomouci 26.,27. listopad, 2014 Petr Krajča (UP) Unit testy 26.,27. listopad, 2014 1 / 14 Testování zásadní

Více

Databáze I. Přednáška 4

Databáze I. Přednáška 4 Databáze I Přednáška 4 Definice dat v SQL Definice tabulek CREATE TABLE jméno_tab (jm_atributu typ [integr. omez.], jm_atributu typ [integr. omez.], ); integritní omezení lze dodefinovat později Definice

Více

Objektová tvorba SW, Analýza požadavků 2006 UOMO 53

Objektová tvorba SW, Analýza požadavků 2006 UOMO 53 Objektová tvorba SW, Analýza požadavků 2006 UOMO 53 Osnova Základní principy tvorby SW Fáze tvorby SW v předmětu UOMO Analýza požadavků Modelování typových úloh 2006 UOMO 54 Tvorba SW Dříve umění vyvolených

Více

VYSOKÁ ŠKOLA BÁŇSKÁ TECHNICKÁ UNIVERZITA OSTRAVA FAKULTA STROJNÍ DATABÁZOVÉ SYSTÉMY ARCHITEKTURA DATABÁZOVÝCH SYSTÉMŮ. Ing. Lukáš OTTE, Ph.D.

VYSOKÁ ŠKOLA BÁŇSKÁ TECHNICKÁ UNIVERZITA OSTRAVA FAKULTA STROJNÍ DATABÁZOVÉ SYSTÉMY ARCHITEKTURA DATABÁZOVÝCH SYSTÉMŮ. Ing. Lukáš OTTE, Ph.D. VYSOKÁ ŠKOLA BÁŇSKÁ TECHNICKÁ UNIVERZITA OSTRAVA FAKULTA STROJNÍ DATABÁZOVÉ SYSTÉMY ARCHITEKTURA DATABÁZOVÝCH SYSTÉMŮ Ing. Lukáš OTTE, Ph.D. Ostrava 2013 Tento studijní materiál vznikl za finanční podpory

Více

Vývoj informačních systémů. Obecně o IS

Vývoj informačních systémů. Obecně o IS Vývoj informačních systémů Obecně o IS Informační systém Informační systém je propojení informačních technologií a lidských aktivit směřující k zajištění podpory procesů v organizaci. V širším slova smyslu

Více

EKONOMICKÝ A LOGISTICKÝ SOFTWARE. Luhačovice 24.10.2013

EKONOMICKÝ A LOGISTICKÝ SOFTWARE. Luhačovice 24.10.2013 EKONOMICKÝ A LOGISTICKÝ SOFTWARE Luhačovice 24.10.2013 CRM řízení vztahů se zákazníky CRM - je zkratka z anglického Customer Relationship Management a označují se tak systémy pro řízení vztahů se zákazníky.crm

Více

Více než 60 novinek, změn a vylepšení

Více než 60 novinek, změn a vylepšení Více než 60 novinek, změn a vylepšení Nová řada programu 2HCS Fakturace Vám nabízí více než 60 novinek, změn a vylepšených funkcí. Zde je jejich seznam, pro Vaši lepší orientaci rozdělený podle jednotlivých

Více

2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena.

2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena. 2015 GEOVAP, spol. s r. o. Všechna práva vyhrazena. GEOVAP, spol. s r. o. Čechovo nábřeží 1790 530 03 Pardubice Česká republika +420 466 024 618 http://www.geovap.cz V dokumentu použité názvy programových

Více

Pokročilé typové úlohy a scénáře 2006 UOMO 71

Pokročilé typové úlohy a scénáře 2006 UOMO 71 Pokročilé typové úlohy a scénáře 2006 UOMO 71 Osnova Interní model typové úlohy Vazby include a extend Provázanost typových úloh na firemní procesy a objekty Nejčastější chyby 2006 UOMO 72 Interní model

Více

Ročníkový projekt. Jaroslav Žáček

Ročníkový projekt. Jaroslav Žáček Ročníkový projekt Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/infs1/ Cíle předmětů Vytvoření fungující aplikace, která splňuje definované požadavky Vyzkoušet si celý životní cyklus projektu

Více

Softwarový proces Martin Hlavatý 4. říjen 2018

Softwarový proces Martin Hlavatý 4. říjen 2018 Softwarový proces Martin Hlavatý 4. říjen 2018 Úvod Základní pojmy Softwarový proces / Model životního cyklu vývoje software (SDLC, Software Development Lifecycle) Množina aktivit nutných k tomu, aby software

Více

Návrh a tvorba WWW stránek 1/14. PHP a databáze

Návrh a tvorba WWW stránek 1/14. PHP a databáze Návrh a tvorba WWW stránek 1/14 PHP a databáze nejčastěji MySQL součástí balíčků PHP navíc podporuje standard ODBC PHP nemá žádné šablony pro práci s databází princip práce s databází je stále stejný opakované

Více

Manuál k programu RIZIKA

Manuál k programu RIZIKA Manuál k programu RIZIKA nástroj k efektivnímu vyhledávání a řízení pracovních rizik Program RIZIKA Program RIZIKA jsou víceuživatelskou aplikací s možností nastavení uživatelských práv pro jednotlivé

Více

7 Jazyk UML (Unified Modeling Language)

7 Jazyk UML (Unified Modeling Language) 7 Jazyk UML (Unified Modeling Language) 7.1 Základní charakteristika jazyka Motivace - vznik řady OO metod a metodologií (konec 80. let a první polovina 90.let) podobné notace vyjadřující totéž, komplikující

Více

1 Strukturované programování

1 Strukturované programování Projekt OP VK Inovace studijních oborů zajišťovaných katedrami PřF UHK Registrační číslo: CZ.1.07/2.2.00/28.0118 1 Cíl Seznámení s principy strukturovaného programování, s blokovou strukturou programů,

Více

EXTRAKT z technické normy ISO

EXTRAKT z technické normy ISO EXTRAKT z technické normy ISO Extrakt nenahrazuje samotnou technickou normu, je pouze informativním materiálem o normě. Inteligentní dopravní systémy Kooperativní ITS Zkušební architektura ISO/TS 20026

Více

8 Přehled OO metodik (metod, metodologií)

8 Přehled OO metodik (metod, metodologií) 8 Přehled OO metodik (metod, metodologií) 8.1 OO metodiky konce 80. a začátku 90.let - všechny populární OO metodiky předpokládají, že: a) zadavatel má jasný názor na svoje požadavky, b) zadavatel a vývojáři

Více

Roční periodická zpráva projektu

Roční periodická zpráva projektu WAK-1F44C-2005-2 WAK System Název projektu: Automatizovaná výměna dat mezi informačními systémy krizového řízení v dopravě s jednotným univerzálním a implementovaným rozhraním založeným na standardu webových

Více

7.6 Další diagramy UML

7.6 Další diagramy UML 7.6 Další diagramy UML 7.6.1 Moduly (balíčky - package) a kolaborace (collaboration) Jak rozložit rozsáhlý systém na menší? - seskupování tříd (prvků modelu) do jednotek vyšší úrovně (package v UML). UI

Více

Odbor informatiky a provozu informačních technologií

Odbor informatiky a provozu informačních technologií POLICEJNÍ PREZIDIUM ČR Odbor informatiky a provozu informačních technologií Příloha č. 1 a) název zakázky, Technická podpora software pro systém NS-VIS a VISMAIL b) předmět a rozsah plnění veřejné zakázky

Více

8 Přehled OO metodik (metod, metodologií)

8 Přehled OO metodik (metod, metodologií) 8 Přehled OO metodik (metod, metodologií) 8.1 OO metodiky konce 80. a začátku 90.let - všechny populární OO metodiky předpokládají, že: a) zadavatel jasný názor na svoje požadavky, b) zadavatel a vývojáři

Více

Národní šetření výsledků žáků v počátečním vzdělávání

Národní šetření výsledků žáků v počátečním vzdělávání Projekt NIQES Národní šetření žáků v počátečním vzdělávání Národní šetření výsledků žáků v počátečním vzdělávání Druhá celoplošná generální zkouška Název souboru: CP2-Procesy_přípravy_a_realizace_V3.doc

Více

Příloha č. 1 Verze IS esyco business

Příloha č. 1 Verze IS esyco business Příloha č. 1 Verze IS esyco business 1.10.1.1. Nasazení nové verze IS esyco business 1.10.1.1. proběhne u zákazníků postupně od 23. 4. 2018. V rámci nasazování verze budete kontaktováni konzultantem společnosti

Více

Specifikace požadavků. POHODA Web Interface. Verze 1.0. Datum: Autor: Ondřej Šrámek

Specifikace požadavků. POHODA Web Interface. Verze 1.0. Datum: Autor: Ondřej Šrámek Specifikace požadavků POHODA Web Interface Verze 1.0 Datum: 29.12. 2008 Autor: Ondřej Šrámek Copyright 1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document. Strana

Více

TREND 07-201 POPIS ODPOVĚDNOSTI PRACOVNÍKA MANAŽER VÝVOJE

TREND 07-201 POPIS ODPOVĚDNOSTI PRACOVNÍKA MANAŽER VÝVOJE Tel. +420 543426329 TREND 07-201 POPIS ODPOVĚDNOSTI PRACOVNÍKA MANAŽER VÝVOJE Autor: Vít Chvál Verze dokumentu: 1.0 Datum poslední změny: 18.2.2013 Obsah: 1 Pracovník 3 2 Pracovní činnosti (Náplň práce)

Více

E-mailové kampaně. 2013 Byznys CRM s.r.o.

E-mailové kampaně. 2013 Byznys CRM s.r.o. E-mailové kampaně 2013 Byznys CRM s.r.o. Zákazník: Dne: 31. 5. 2015 Vytvořil: Pavel Šlesingr Schválil: Petr Hampejs Verze: 5.0 Emailové kampaně v CRM 2011 Strana 2 z 15 Obsah Obsah... 3 1. Popis... 4 1.1.

Více

RUP - Disciplíny. Jaroslav Žáček jaroslav.zacek@osu.cz

RUP - Disciplíny. Jaroslav Žáček jaroslav.zacek@osu.cz RUP - Disciplíny Jaroslav Žáček jaroslav.zacek@osu.cz Disciplíny Množství disciplíny v dané iteraci Disciplíny podle RUP Šest základních: Business modeling - pro pochopení problémové domény Requirements

Více

Pravidla a plánování

Pravidla a plánování Administrátorský manuál TTC TELEKOMUNIKACE, s.r.o. Třebohostická 987/5 100 00 Praha 10 tel.: 234 052 111 fax.: 234 052 999 e-mail: ttc@ttc.cz http://www.ttc-telekomunikace.cz Datum vydání: 7. května 2013

Více

Evidence požadavků uživatelů bytů a nebytových prostor

Evidence požadavků uživatelů bytů a nebytových prostor Evidence požadavků uživatelů bytů a nebytových prostor Úvod Pro zjednodušení a zprůhlednění Vaší komunikace se správní firmou (dále jen SF ), která má na starost objekt, v němž se nachází bytový či nebytový

Více

7 Jazyk UML (Unified Modeling Language)

7 Jazyk UML (Unified Modeling Language) 7 Jazyk UML (Unified Modeling Language) 7.1 Základní charakteristika jazyka Motivace - vznik řady OO metod a metodologií (konec 80. let a první polovina 90.let) podobné notace vyjadřující totéž, komplikující

Více

plussystem Příručka k instalaci systému

plussystem Příručka k instalaci systému plussystem Příručka k instalaci systému Tato příručka je určena zejména prodejcům systému a případně koncovým uživatelům. Poskytuje návod, jak provést potřebná nastavení komponent. ITFutuRe s.r.o. 26.2.2015

Více

Zabezpečení proti SQL injection

Zabezpečení proti SQL injection Zabezpečení proti SQL injection ESO9 intranet a.s. Zpracoval: Tomáš Urych U Mlýna 2305/22, 141 Praha 4 Záběhlice Dne: 19.9.2012 tel.: +420 585 203 370-2 e-mail: info@eso9.cz Revize: Urych Tomáš www.eso9.cz

Více

SEMESTRÁLNÍ PROJEKT Y38PRO

SEMESTRÁLNÍ PROJEKT Y38PRO SEMESTRÁLNÍ PROJEKT Y38PRO Závěrečná zpráva Jiří Pomije Cíl projektu Propojení regulátoru s PC a vytvoření knihovny funkcí pro práci s regulátorem TLK43. Regulátor TLK43 je mikroprocesorový regulátor s

Více

Jak používat statistiky položkové v systému WinShop Std.

Jak používat statistiky položkové v systému WinShop Std. Jak používat statistiky položkové v systému WinShop Std. Systém WinShop Std. využívá k zápisům jednotlivých realizovaných pohybů (příjem zboží, dodací listy, výdejky, převodky, prodej zboží na pokladně..)

Více

Primární klíč (Primary Key - PK) Je právě jedna množina atributů patřící jednomu z kandidátů primárního klíče.

Primární klíč (Primary Key - PK) Je právě jedna množina atributů patřící jednomu z kandidátů primárního klíče. Primární a cizí klíč Kandidát primárního klíče (KPK) Je taková množina atributů, která splňuje podmínky: Unikátnosti Minimálnosti (neredukovatelnosti) Primární klíč (Primary Key - PK) Je právě jedna množina

Více

Michal Oškera (50854)

Michal Oškera (50854) PV098 - Řízení SW projektů semestrální práce Michal Oškera (50854) 19. listopadu 2003 Obsah 1 Úvod 2 2 Plán projektu 3 2.1 Plán CO.............................. 3 2.2 Plán JAK.............................

Více

QAD CRM. Vladimír Bartoš. konzultant

QAD CRM. Vladimír Bartoš. konzultant QAD CRM Vladimír Bartoš konzultant Integrace QAD CRM QAD EA Artikly Adresy Nabídky Prodejní objednávky Instalovaná báze Servisní volání Servisní kontrakty Servisní nabídky Nabídky volání Měny Uživatelé

Více

Nový způsob práce s průběžnou klasifikací lze nastavit pouze tehdy, je-li průběžná klasifikace v evidenčním pololetí a školním roce prázdná.

Nový způsob práce s průběžnou klasifikací lze nastavit pouze tehdy, je-li průběžná klasifikace v evidenčním pololetí a školním roce prázdná. Průběžná klasifikace Nová verze modulu Klasifikace žáků přináší novinky především v práci s průběžnou klasifikací. Pro zadání průběžné klasifikace ve třídě doposud existovaly 3 funkce Průběžná klasifikace,

Více

CASE nástroje. Jaroslav Žáček

CASE nástroje. Jaroslav Žáček CASE nástroje Jaroslav Žáček jaroslav.zacek@osu.cz http://www1.osu.cz/~zacek/ Co znamená CASE? A CASE tool is a computer-based product aimed at supporting one or more software engineering activities within

Více

Obsah SLEDOVÁNÍ PRÁCE... 4

Obsah SLEDOVÁNÍ PRÁCE... 4 Co je nového Obsah SLEDOVÁNÍ PRÁCE...... 4 Konfigurace souboru... 5 Globální konfigurace... 6 Soubory... 6 Projekty... 6 Uživatelské rozhraní... 7 Synchronizace... 7 Typ serveru... 8 Test připojení...

Více

End-to-end testování. 26. dubna Bořek Zelinka

End-to-end testování. 26. dubna Bořek Zelinka End-to-end testování 26. dubna 2013 Bořek Zelinka Bořek Zelinka Unicorn Systems, Test architekt Unicorn, 2004 Testování Quality Assurance ČVUT, Fakulta stavební, 2004 2 Agenda Princip end-to-end testů

Více