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

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

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

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

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

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

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

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

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

Ú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

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

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

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

Ří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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Inovace výuky prostřednictvím ICT v SPŠ Zlín, CZ.1.07/1.5.00/34.0333 Vzdělávání v informačních a komunikačních technologií

Inovace výuky prostřednictvím ICT v SPŠ Zlín, CZ.1.07/1.5.00/34.0333 Vzdělávání v informačních a komunikačních technologií VY_32_INOVACE_33_02 Škola Název projektu, reg. č. Vzdělávací oblast Vzdělávací obor Tematický okruh Téma Tematická oblast Název Autor Vytvořeno, pro obor, ročník Anotace Přínos/cílové kompetence Střední

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

Softwarové inženýrství 01. doc. Ing. František Huňka, CSc.

Softwarové inženýrství 01. doc. Ing. František Huňka, CSc. Softwarové inženýrství 01 doc. Ing. František Huňka, CSc. Obsah kurzu Softwarové inženýrství obecně vodopádová model spirálový model RUP agilní metodiky vývoj řízený vlastnostmi (Feature Development Design)

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 Teorie vs. praxe o Jsou učebnicové poučky důležité?

Více

FORTANNS. havlicekv@fzp.czu.cz 22. února 2010

FORTANNS. havlicekv@fzp.czu.cz 22. února 2010 FORTANNS manuál Vojtěch Havlíček havlicekv@fzp.czu.cz 22. února 2010 1 Úvod Program FORTANNS je software určený k modelování časových řad. Kód programu má 1800 řádek a je napsán v programovacím jazyku

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

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

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

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

Měřící systém se vzdáleným přístupem. Databáze

Měřící systém se vzdáleným přístupem. Databáze ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE FAKULTA ELEKTROTECHNICKÁ KATEDRA MĚŘENÍ Měřící systém se vzdáleným přístupem Databáze Jiří Javůrek 2003/2005 0. Obsah 0. Obsah...1 1. Požadavky...2 2. Struktura databáze...2

Více

Informační systém pro centrální správu lokální sítě a služeb ISP

Informační systém pro centrální správu lokální sítě a služeb ISP MASARYKOVA UNIVERZITA Fakulta informatiky PV098 Řízení implementace IS semestrální práce Informační systém pro centrální správu lokální sítě a služeb ISP Jiří Kratochvíla, učo 207622, semestr 6, ročník

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

Projekt informačního systému pro Eklektik PRO S EK. Řešitel: Karolína Kučerová

Projekt informačního systému pro Eklektik PRO S EK. Řešitel: Karolína Kučerová Projekt informačního systému pro Eklektik PRO S EK Řešitel: ÚVODNÍ ZPRÁVA ZADÁNÍ PROJEKTU Zefektivnění komunikace ve firmě Eklektik, a to především v oblasti informací o klientech a o tištěných materiálech

Více

INFORMAČNÍ SYSTÉM VIDIUM A VYUŽITÍ MODERNÍCH TECHNOLOGIÍ

INFORMAČNÍ SYSTÉM VIDIUM A VYUŽITÍ MODERNÍCH TECHNOLOGIÍ INFORMAČNÍ SYSTÉM VIDIUM A VYUŽITÍ MODERNÍCH TECHNOLOGIÍ Michal Brožek, Dominik Svěch, Jaroslav Štefaník MEDIUM SOFT a.s., Cihelní 14, 702 00 Ostrava, ČR Abstrakt Neustále rostoucí význam sběru dat, možnost

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

Technická dokumentace

Technická dokumentace Příloha č.1 výzvy Technická dokumentace k veřejné zakázce malého rozsahu Obsah Technická dokumentace... 1 Předmět zadání k podání cenové nabídky:... 3 Dodávka a služby budou zahrnovat:... 3 Specifikace

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

Tvorba kurzu v LMS Moodle

Tvorba kurzu v LMS Moodle Tvorba kurzu v LMS Moodle Před počátkem práce na tvorbě základního kurzu znovu připomínám, že pro vytvoření kurzu musí být profil uživatele nastaven administrátorem systému minimálně na hodnotu tvůrce

Více

ZADÁVACÍ DOKUMENTACE Comenis 2.0

ZADÁVACÍ DOKUMENTACE Comenis 2.0 ZADÁVACÍ DOKUMENTACE Comenis 2.0 jako příloha Výzvy k podání nabídek v rámci projektu Distanční jazykové vzdělávání pomocí M-learningu CZ.1.07/3.2.10/04.0011 Akademie Jana Amose Komenského Jičín Název

Více

Zavedení a certifikace systému managementu kvality dle ČSN EN ISO 9001:2009

Zavedení a certifikace systému managementu kvality dle ČSN EN ISO 9001:2009 VÝZVA K PODÁNÍ NABÍDKY V RÁMCI ZADÁNÍ VEŘEJNÉ ZAKÁZKY MALÉHO ROZSAHU: č.9/2012/mrfp Zavedení a certifikace systému managementu kvality dle ČSN EN ISO 9001:2009 1. Základní údaje o zadavateli: Městský rozvojový

Více

45 Plánovací kalendář

45 Plánovací kalendář 45 Plánovací kalendář Modul Správa majetku slouží ke tvorbě obecných ročních plánů činností organizace. V rámci plánu je třeba definovat oblasti činností, tj. oblasti, ve kterých je možné plánovat. Každá

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

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

Zuzana Šochová 30.10.2008. MFF Modelování a realizace softwarových projektů

Zuzana Šochová 30.10.2008. MFF Modelování a realizace softwarových projektů Zuzana Šochová 30.10.2008 1 Metody řízení projektů Týmová spolupráce Agilní metody Scrum proces Backlog úloh a odhady Jak plánovat Tým a zákazník 2 Executive support User involvement Experienced project

Více

Příprava dat v softwaru Statistica

Příprava dat v softwaru Statistica Příprava dat v softwaru Statistica Software Statistica obsahuje pokročilé nástroje pro přípravu dat a tvorbu nových proměnných. Tyto funkcionality přinášejí značnou úsporu času při přípravě datového souboru,

Více

VÝZVA K PODÁNÍ NABÍDEK DO VÝBĚROVÉHO ŘÍZENÍ ZADÁVACÍ PODMÍNKY

VÝZVA K PODÁNÍ NABÍDEK DO VÝBĚROVÉHO ŘÍZENÍ ZADÁVACÍ PODMÍNKY VÝZVA K PODÁNÍ NABÍDEK DO VÝBĚROVÉHO ŘÍZENÍ ZADÁVACÍ PODMÍNKY Název zakázky Vývoj e-learningového kurzu 1. Identifikační údaje Zadavatel (název subjektu) ČD Cargo, a.s. Právní forma Akciová společnost

Více

Internetový obchod ES Pohoda Web Revolution

Internetový obchod ES Pohoda Web Revolution Internetový obchod ES Pohoda Web Revolution Uživatelský manuál propojení na ES Pohoda Verze 1.0 Web Revolution s.r.o. 2010 Internetový obchod ES Pohoda Uživatelský manuál na propojení na ES Pohoda Přehled

Více

Obsah. Předmluva...19. KAPITOLA 1 Úvod do programu Microsoft Dynamics NAV...23. KAPITOLA 2 Základy ovládání...33

Obsah. Předmluva...19. KAPITOLA 1 Úvod do programu Microsoft Dynamics NAV...23. KAPITOLA 2 Základy ovládání...33 Obsah Předmluva...19 Stručný úvod... 19 Cílová skupina... 20 Cvičení a řešení... 20 Poděkování... 21 Zpětná vazba od čtenářů... 21 Errata... 21 KAPITOLA 1 Úvod do programu Microsoft Dynamics NAV...23 Co

Více

INFORMAČNÍ SYSTÉMY (IS) Ing. Pavel Náplava Katedra počítačů K336, ČVUT FEL Praha 2004/2005

INFORMAČNÍ SYSTÉMY (IS) Ing. Pavel Náplava Katedra počítačů K336, ČVUT FEL Praha 2004/2005 INFORMAČNÍ SYSTÉMY (IS) Ing. Pavel Náplava Katedra počítačů K336, ČVUT FEL Praha 2004/2005 AGENDA definice IS, zavedení pojmů možnosti a rozdělení typická struktura technologie nasazení praktická ukázka

Více

DODATEČNÉ INFORMACE K ZADÁVACÍM PODMÍNKÁM č. 4

DODATEČNÉ INFORMACE K ZADÁVACÍM PODMÍNKÁM č. 4 DODATEČNÉ INFORMACE K ZADÁVACÍM PODMÍNKÁM č. 4 Zadavatel: Česká republika Ministerstvo životního prostředí Sídlo: Vršovická 1442/65, 100 10 Praha 10 IČO: 00164801 Jednající: Název veřejné zakázky: Ing.

Více

Marketingová komunikace. 2. a 3. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK3PH (vm3aph)

Marketingová komunikace. 2. a 3. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK3PH (vm3aph) Marketingová komunikace Kombinované studium Skupina N9KMK3PH (vm3aph) 2. a 3. soustředění Mgr. Pavel Vávra 9103@mail.vsfs.cz http://vavra.webzdarma.cz/home/index.htm Co nás čeká: 2. soustředění 16.1.2009

Více

Novell Identity Management. Jaromír Látal Datron, a.s.

Novell Identity Management. Jaromír Látal Datron, a.s. Novell Identity Management Jaromír Látal Datron, a.s. 19.4.2012 1 Identity management základní vlastnosti Jednoduché a rychlé poskytování uživatelských účtů Samoobslužné funkce pro uživatele Snadný návrh

Více

Gymnázium a Střední odborná škola, Rokycany, Mládežníků 1115

Gymnázium a Střední odborná škola, Rokycany, Mládežníků 1115 Gymnázium a Střední odborná škola, Rokycany, Mládežníků 1115 Číslo projektu: Číslo šablony: Název materiálu: Ročník: Identifikace materiálu: Jméno autora: Předmět: Tématický celek: Anotace: CZ.1.07/1.5.00/34.0410

Více

SOFTWAROVÉ INŽENÝRSTVÍ 1

SOFTWAROVÉ INŽENÝRSTVÍ 1 Metodický list č. 1 Název tématického celku: Úvod do softwarového inženýrství Základním cílem tohoto tematického celku je vysvětlení smyslu discipliny nazývané softwarové inženýrství. Tematický celek zahrnuje

Více

Student s Life. Návrhová dokumentace (Design) Lukáš Barák, Jakub Ječmínek, Jaroslav Brchel, Jiří Zmeškal 3.12.2010

Student s Life. Návrhová dokumentace (Design) Lukáš Barák, Jakub Ječmínek, Jaroslav Brchel, Jiří Zmeškal 3.12.2010 Student s Life Návrhová dokumentace (Design) Lukáš Barák, Jakub Ječmínek, Jaroslav Brchel, Jiří Zmeškal 3.12.2010 Model Specification Page: 2 Obsah Model architektury... 3 Návrhový model... 3 Bussines

Více

RDF DSPS ROZVOJ PORTÁLU

RDF DSPS ROZVOJ PORTÁLU RDF DSPS ROZVOJ PORTÁLU ČEZ Distribuce, a.s. HSI, spol. s r.o. Zbyněk Businský Miroslav Kaňka ZÁKAZNÍK A DODAVATEL ČEZ DISTRIBUCE, A.S. ČEZ distribuční síť Od r. 2012 implementován GEOPORTÁL (1. ETAPA),

Více

Obsah. 1.1 Práce se záznamy... 3 1.2 Stránka Dnes... 4. 2.1 Kontakt se zákazníkem... 5

Obsah. 1.1 Práce se záznamy... 3 1.2 Stránka Dnes... 4. 2.1 Kontakt se zákazníkem... 5 CRM SYSTÉM KORMORÁN UŽIVATELSKÁ PŘÍRUČKA Obsah 1 Základní práce se systémem 3 1.1 Práce se záznamy................................. 3 1.2 Stránka Dnes.................................... 4 1.3 Kalendář......................................

Více

BALISTICKÝ MĚŘICÍ SYSTÉM

BALISTICKÝ MĚŘICÍ SYSTÉM BALISTICKÝ MĚŘICÍ SYSTÉM UŽIVATELSKÁ PŘÍRUČKA Verze 2.3 2007 OBSAH 1. ÚVOD... 5 2. HLAVNÍ OKNO... 6 3. MENU... 7 3.1 Soubor... 7 3.2 Měření...11 3.3 Zařízení...16 3.4 Graf...17 3.5 Pohled...17 1. ÚVOD

Více

JRV.CZ s.r.o. Bulharská 4 612 00 Brno www.rosadata.cz. RosaData TM DEVELOPERSKÝ PROJEKT

JRV.CZ s.r.o. Bulharská 4 612 00 Brno www.rosadata.cz. RosaData TM DEVELOPERSKÝ PROJEKT RosaData TM DEVELOPERSKÝ PROJEKT OBSAH Úvod... 4 Developerský projekt... 5 Seznam developerských projektů... 5 Základní údaje... 6 Popis... 7 Technické detaily... 8 Reality... 11 Foto... 13 Obchodní případ...

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

Úvodní přednáška. Význam a historie PIS

Úvodní přednáška. Význam a historie PIS Úvodní přednáška Význam a historie PIS Systémy na podporu rozhodování Manažerský informační systém Manažerské rozhodování Srovnávání, vyhodnocování, kontrola INFORMACE ROZHODOVÁNÍ organizace Rozhodovacích

Více

Windows Server 2003 Active Directory

Windows Server 2003 Active Directory Windows Server 2003 Active Directory Active Directory ukládá informace o počítačích, uživatelích a ostatních objektech v síti. Zpřístupňuje tyto zdroje uživatelům. Poskytuje komplexní informace o organizaci,

Více

Katalog egon služeb verze: 0.01

Katalog egon služeb verze: 0.01 Katalog egon služeb verze: 0.01 Historie verzí Verze Datum Popis 0.01 20.7.2011 egon služby prototypu OBSAH 1 Úvod... 5 1.1 Členění dokumentu... 5 1.2 Třídy služeb... 5 1.3 SLA služeb... 6 1.3.1 SLA-01...

Více

SQL - trigger, Databázové modelování

SQL - trigger, Databázové modelování 6. přednáška z předmětu Datové struktury a databáze (DSD) Ústav nových technologií a aplikované informatiky Fakulta mechatroniky, informatiky a mezioborových studií Technická univerzita v Liberci jan.lisal@tul.cz

Více

Zátěžové testy aplikací

Zátěžové testy aplikací Zátěžové testy aplikací Obsah Zátěžové testy v životním cyklu vývoje software Kdy a proč provádět zátěžové testy Projekt zátěžového testu Fáze zátěžového testu Software pro zátěžové testy Zátěžové testy

Více

24-2-2 PROMĚNNÉ, KONSTANTY A DATOVÉ TYPY TEORIE DATUM VYTVOŘENÍ: 23.7.2013 KLÍČOVÁ AKTIVITA: 02 PROGRAMOVÁNÍ 2. ROČNÍK (PRG2) HODINOVÁ DOTACE: 1

24-2-2 PROMĚNNÉ, KONSTANTY A DATOVÉ TYPY TEORIE DATUM VYTVOŘENÍ: 23.7.2013 KLÍČOVÁ AKTIVITA: 02 PROGRAMOVÁNÍ 2. ROČNÍK (PRG2) HODINOVÁ DOTACE: 1 24-2-2 PROMĚNNÉ, KONSTANTY A DATOVÉ TYPY TEORIE AUTOR DOKUMENTU: MGR. MARTINA SUKOVÁ DATUM VYTVOŘENÍ: 23.7.2013 KLÍČOVÁ AKTIVITA: 02 UČIVO: STUDIJNÍ OBOR: PROGRAMOVÁNÍ 2. ROČNÍK (PRG2) INFORMAČNÍ TECHNOLOGIE

Více

Indexace pro souborová uložiště a Vyhledávací centrum

Indexace pro souborová uložiště a Vyhledávací centrum Indexace pro souborová uložiště a Vyhledávací centrum Obsah I. Úvod... 2 II. Cíl dokumentu... 2 III. Fáze projektu... 2 IV. Popis jednotlivých fází projektu... 2 1. Fáze 1. - Analýza... 2 2. Fáze 2. -

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

Zajištění kvality programového vybavení - testování

Zajištění kvality programového vybavení - testování Zajištění kvality programového vybavení - testování Základy testování Proč se to dělá? Kvalita software 100% testování není možné Různé pohledy: Vývojářské testování (testy komponent, integrační, systémové

Více

Jednotný NIS Prezentace k zahájení projektu pro Radu kraje Vysočina. Projektový manažer - Ing. Ivan Sokolov, Ph.D.

Jednotný NIS Prezentace k zahájení projektu pro Radu kraje Vysočina. Projektový manažer - Ing. Ivan Sokolov, Ph.D. Prezentace k zahájení projektu pro Radu kraje Vysočina Projektový manažer - Ing. Ivan Sokolov, Ph.D. Obsah Úvod Cíle projektu Rozsah projektu Projektové řízení základní východiska Základní organizační

Více

EXTRAKT z mezinárodní normy

EXTRAKT z mezinárodní normy EXTRAKT z mezinárodní normy Extrakt nenahrazuje samotnou technickou normu, je pouze informativním materiálem o normě ICS: 03.220.01; 35.240.60 Komunikační infrastruktura pro pozemní ISO 24101-2 mobilní

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

Elektronická podpora výuky předmětu Komprese dat

Elektronická podpora výuky předmětu Komprese dat Elektronická podpora výuky předmětu Komprese dat Vojtěch Ouška ouskav1@fel.cvut.cz 19. června 2006 Vojtěch Ouška Elektronická podpora výuky předmětu Komprese dat - 1 /15 Co je to SyVyKod? SyVyKod = Systém

Více

Versiondog 3.1.0 Lukáš Rejfek, Pantek (CS) s.r.o. 7/2014

Versiondog 3.1.0 Lukáš Rejfek, Pantek (CS) s.r.o. 7/2014 Versiondog 3.1.0 Lukáš Rejfek, Pantek (CS) s.r.o. 7/2014 Strana 2 Versiondog 3.1.0 Nová verze systému Versiondog 3.1.0 přináší oproti předchozí verzi 3.0.3 celou řadu nových funkčností. Zásadní změnou

Více

POKROČILÉ POUŽITÍ DATABÁZÍ

POKROČILÉ POUŽITÍ DATABÁZÍ POKROČILÉ POUŽITÍ DATABÁZÍ Barbora Tesařová Cíle kurzu Po ukončení tohoto kurzu budete schopni pochopit podstatu koncepce databází, navrhnout relační databázi s využitím pokročilých metod, navrhovat a

Více

Marketingová komunikace. 2. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK1aPH/N9KMK1bPH (um1a1ph/um1b1ph)

Marketingová komunikace. 2. soustředění. Mgr. Pavel Vávra 9103@mail.vsfs.cz. Kombinované studium Skupina N9KMK1aPH/N9KMK1bPH (um1a1ph/um1b1ph) Marketingová komunikace Kombinované studium Skupina N9KMK1aPH/N9KMK1bPH (um1a1ph/um1b1ph) 2. soustředění Mgr. Pavel Vávra 9103@mail.vsfs.cz http://vavra.webzdarma.cz/home/index.htm Minulé soustředění úvod

Více

Protokol o atestačním řízení

Protokol o atestačním řízení Atestační středisko: ADA, s. r. o. pověření k výkonu atestací MI ČR reg. č. 3 rozhodnutím č. j. 3/2001 A ze dne 11.10.2001, se sídlem Čermákova 28, 625 00 Brno adresa pro poštovní styk Sokolská 725, 664

Více

Microsoft SharePoint Portal Server 2003. Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR

Microsoft SharePoint Portal Server 2003. Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR Microsoft SharePoint Portal Server 2003 Zvýšená týmová produktivita a úspora času při správě dokumentů ve společnosti Makro Cash & Carry ČR Přehled Země: Česká republika Odvětví: Velkoobchod Profil zákazníka

Více

Rozvoj projektu PROXIO v roce 2009

Rozvoj projektu PROXIO v roce 2009 Rozvoj projektu PROXIO v roce 2009 Projektový záměr Magistrátu hlavního města Prahy Účel dokumentu: Rekapitulace činností 2008, plán činností 2009 předkládá Odbor informatiku MHMP, ing. Petr Kolbek, 31.12.2008

Více

Příloha č. 3 Smlouvy Součinnost stran při poskytování některých plnění

Příloha č. 3 Smlouvy Součinnost stran při poskytování některých plnění Příloha č. 3 Smlouvy Součinnost stran při poskytování některých plnění Nástroje pro poskytování součinnosti 1.1 Help desk Poskytovatel vytvoří a zajistí službu pro hlášení vad/požadavků/připomínek (dále

Více

SPECIFIKA CERTIFIKACE PODLE ČSN EN ISO 9001:2001 V ORGANIZACÍCH, KTERÉ SE ZABÝVAJÍ VÝVOJEM SOFTWARE

SPECIFIKA CERTIFIKACE PODLE ČSN EN ISO 9001:2001 V ORGANIZACÍCH, KTERÉ SE ZABÝVAJÍ VÝVOJEM SOFTWARE SPECIFIKA CERTIFIKACE PODLE ČSN EN ISO 9001:2001 V ORGANIZACÍCH, KTERÉ SE ZABÝVAJÍ VÝVOJEM SOFTWARE Václav Šebesta Ústav informatiky Akademie věd ČR, e-mail: vasek@cs.cas.cz Abstrakt Jestliže ještě před

Více

Integrovaný informační systém Státní pokladny (IISSP)

Integrovaný informační systém Státní pokladny (IISSP) Integrovaný informační systém Státní pokladny (IISSP) Metodika křížových kontrol - PAP Verze dokumentu: 1.6 (z 17.12. 2014) Strana: 1/10 Obsah 1. Popis křížových kontrol... 4 2. Termín spuštění KRK...

Více