O JEDNÉ ČASTÉ CHYBĚ PŘI ROZKLADU PROCESŮ PODNIKU ANEB KDY MÁME UKONČIT ROZKLAD PROCESŮ PODNIKU?

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

Download "O JEDNÉ ČASTÉ CHYBĚ PŘI ROZKLADU PROCESŮ PODNIKU ANEB KDY MÁME UKONČIT ROZKLAD PROCESŮ PODNIKU?"

Transkript

1 O JEDNÉ ČASTÉ CHYBĚ PŘI ROZKLADU PROCESŮ PODNIKU ANEB KDY MÁME UKONČIT ROZKLAD PROCESŮ PODNIKU? RNDr. Ilja Kraval, říjen AKTÉROVÁ ŠKOLA Jak známo, informační systémy obsahují řádově stovky až tisíce případů užití. Z toho důvodu při tvorbě Use Case Diagramu musí analytik řešit tyto zásadní otázky: Jak tyto případy užití nalézat systematicky? Jak postupovat, abychom nějaký neopomněli? Existuje jedna klasická metodika vyhledávání případů užití, nazvěme ji pracovně aktérová škola, která byla preferovaná hlavně v období zrodu UML,tj. ve druhé polovině 90.let minulého století. Aktérová škola přistupuje k řešení problému nalézání případů užití pomocí jednoduchého pravidla: Najdi nejprve prvky z okolí systému (tzv. aktéry neboli prvky typu Actor), které budou potřebovat systém, případně najdi ty prvky z okolí, které budou komunikovat se systémem, resp. ty prvky z okolí, kterým bude systém předávat informace. Až nějaký takový prvek (neboli prvek typu Actor) z okolí najdeš, zeptej se, proč a nač aktér tento systém potřebuje, resp. jak jej použije, resp. jak komunikuje. Tímto najdeš případy užití. Bohužel tato metodika se ukázala jako nikoliv stoprocentně účinná. Mnohdy vede ke zdlouhavým a zbytečným diskusím nad názvy aktérů. Navíc díky soustředění se na aktéry spousta případů užití zůstane nepovšimnuta. Mnohdy dojde k chybnému určení počtu aktérů, které komunikují s daným případem užití, tj. nastává chybný jev, kdy počet logických rozhraní nesedí s počtem aktérů u daného případu užití. Je třeba podotknout, že aktérová škola se vcelku dobře osvědčila u technologických systémů (jako je například hlásič požáru, řídící modul výtahů v mrakodrapu, komunikační modul apod.). Jedná se o systémy s nikoliv složitými procesy v okolí a s relativně malým počtem případů užití (řádově desítky). Tyto systémy nebývají většinou složité procesně, ale po technologické stránce (například je k dispozici málo fyzické paměti nebo aplikace musí pracovat ve vícero vláknech, zpracovávat signály apod.). U těchto systémů odpadá i velmi nepříjemná diskuse ohledně pojmenování aktérů, protože s výjimkou nějaké nepodstatné

2 strana 2 živé obsluhy ( ) jsou aktéry u technologického systému většinou externí software nebo hardware se specifickým rozhraním, které lze snadno pojmenovat. U informačních systémů, které jsou charakteristické právě vysokým stupněm složitosti chodu procesů okolo systému, však aktérová škola není stoprocentní a selhává. Je třeba podotknout, že i přes toto selhání stoprocentnosti není tato škola úplně zatracena jako nesmyslná. Stává se rozumným podpůrným (a tedy dodatečným doplňkovým) postupem u jiné školy, kterou budeme nazývat jako procesní škola (viz dále). Aktérová škola není plně zavržena a je využita v tom smyslu, že lepší procesní školu doplní svými již zmíněnými otázkami (tj. kdo použije systém? ). Navíc mnohdy získáme od zákazníka dokumenty, ve kterých se to hemží rolemi v podniku, jako jsou ředitel, manažer, obchodník, realitní makléř apod. Tyto role se stávají vstupními parametry zmíněných otázek kdo a proč používá systém?. Musíme však být u tohoto postupu s aktéry opatrní na jednu záludnost: Některé případy užití bývají shodné pro několik rolí v podniku, jinak řečeno mnohdy dva nalezené případy užití nakonec splývají v jeden případ užití pro dvě a více různých rolí v podniku. I když se jedná o jeden případ užití, je pak tendence hovořit o dvou případech pro dva aktéry. Anebo se v tomto případě provede jiný druh hrubé chyby: Určí se pro několik rolí v podniku správně jeden splývající případ užití, ale namalují se k němu dva a více aktérů, i když případ užití má pouze jednoho aktéra, což je opravdu hrubá chyba v modelu případu užití. Nakonec ještě jedna poznámka: Existuje typ softwaru, kde nemusíme používat žádnou zvláštní školu pro vyhledávání případů užití a vystačíme si pouze s dobrým logickým členěním případů užití do prvků typu Package, což u tohoto software dostačuje a samo o sobě vede k systematičnosti. Jedná se software typu desktop aplikace, jako je například editor, tabulkový procesor (Word, Excel apod.) s jedním uživatelem. Poznámka: Existuje veřejný projekt UML Open Source, kde si můžete prohlédnout UML model (případně i spolupracovat), blíže viz tato stránka. PROCESNÍ ŠKOLA Pro systematické vyhledávání případů užití se do popředí se v posledních letech dostala více škola tzv. procesního modelování (zkratka BPM = Business Process Modeling) ve svých různých klonech a variantách, např. BPMN, Eriksson-Penker aj. Podstata procesní školy pro vyhledávání případů užití je sice podobná, ale trochu jiná, než u aktérové školy. Její návod zní velmi podobně: Najdi všechny činnosti neboli procesy strana 2

3 strana 3 podniku v okolí takové, které vedou k použití systému, následně tak najdeš případy užití vyvolané z těchto procesů podniku. Jak vidět, základní otázkou není kdo použije systém, ale co se děje okolo systému takového, že se použije systém. Tato škola má jednu velkou výhodu zejména pro zákazníka: Nemusí pracně přemýšlet nad tím, Kdo bude používat systém, ale otázka zní jednodušeji: Jak to děláte? Například pokud se budeme věnovat agendě zpracování úvěrů v bance, budeme si odpovídat na dotaz Jak chodí úvěry a nikoliv Kdo s nimi pracuje. Jak vidět, první otázka je pro vyhledávání případů užití mnohem cílevědomější! Jak však bylo řečeno, procesní škola může být doplněna také navíc otázkou z aktérové školy ve smyslu kdo potřebuje systém, ale to slouží spíše pro kontrolu a revizi již nalezených případů užití při již nalezených procesech (například a co uklízečka, ta nebude pracovat s agendou úvěrů? ). Procesní škola nalézání případů užití má několik nesporných výhod: umožňuje popsat chod procesů (například jak chodí úvěry ) umožňuje systematický rozklad procesů a tím dát řád mezi případy užití zákazníkovi je tato škola velmi dobře srozumitelná, zákazníkem bývají modely procesů podniku s případy užití přímo vyžadovány jako součást projektové dokumentace Nakonec ještě jedna důležitá poznámka: Jak vyplývá z účelu zavedení procesní školy, tedy k čemu vlastně slouží (nezapomeňme, že hledáme případy užití informačního systému!), tak je potom zřejmé, že procesní model popisuje chod podniku s novým vyvíjeným systémem a nikoliv chod podniku dnešní ještě bez navrhovaného systému. Velmi častou otázkou při školeních bývá dotaz: A máme modelovat i současný stav nebo ne? Odpověď z praxe je opravdu čistě praktická: Pokud se po vás současný model podniku vyžaduje (a zákazník jej zaplatí), pak jej musíte vyhotovit, tj. model současného chodu podniku se stává součástí dokumentace projektu stejně jako chod procesů s novým systémem. Pokud se výstupy současného stavu podniku přímo nevyžadují a nemusíte odevzdávat formalizovaný model současného stavu, pak to ještě neznamená, že se mu nebudete věnovat! Je vhodné si se zákazníkem pohovořit o současném stavu, tedy o současném chodu podniku se současným informačním systémem, a tyto poznatky si nějak zapsat jako cenný zdroj informace. Pokud se však nevyžaduje výstup, nemusíte být však při zápisu až tak formální (například nemusíte malovat diagramy), stačí pouze textový tvar zápisu. Pokud se i tak vedoucí projektu rozhodne, že součástí projektu bude procesní model stávajícího stavu, aniž by to zákazník požadoval, jedná se v tom případě o ekonomickou stránku a možnosti zdrojů projektu (tj. o otázku, kdo to zaplatí a kdo to udělá). strana 3

4 strana 4 ROZKLAD PROCESŮ Je zřejmé, že pokud nalezneme pro každý případ užití jeden proces podniku, ze kterého dojde k použití systému, tak logicky vzato najdeme tolik procesů, kolik je případů užití, což je samozřejmě opět velké množství. Velkou výhodou procesní školy je systematičnost daná možností rozkladu procesů a to nám umožňuje následně uspořádat systematicky i případy užití. Základní myšlenka je jednoduchá: Procesy (neboli prvky typu Activity v UML se stereotypem <<business process>>) umějí tak zvaný rozklad procesů neboli aktivit. Znamená to, že v rozkladu procesů existují vyšší procesy, které se skládají z nižších procesů. Laik rozumí tomuto skládání (nebo naopak rozkladu směrem dolů) procesů velmi dobře a intuitivně jej chápe opravdu správně. Například když se bavíme se zákazníkem o tom, jak vypadá proces podniku Fakturace v podniku, bude pro něj opravdu srozumitelná tato jednoduchá věta: Proces Fakturace se skládá z procesů Založení faktury, Editace faktury, Odsouhlasení faktury atd. Všimněme si, že vyšší proces Fakturace je v tomto případě složen z nižších procesů Založení faktury, Editace faktury, Odsouhlasení faktury atd. Díky této vlastnosti procesů skládat se můžeme zavést systematičnost rozkladu všech procesů podniku. Zavedeme vrchní top proces a dáme mu název IS. Chápeme jej jako proces podniku zahrnující všechny procesy podniku podporované IS. Následuje rozklad odshora dolů na první úrovni rozložíme proces ještě dost nahrubo (například Evidence subjektů, Účetnictví, Skladové hospodářství atd.). Další rozklad zjemní další procesy atd. Takovouto dekompozici odshora dolů můžeme chápat jako rozdělení na oblasti řešení daného IS podobně jako zoom u lupy: Nejprve vidíme oblasti řešení nahrubo a postupně pohled zjemňujeme. Tento rozklad procesů nebo také oblastí řešení znázorníme graficky, přičemž pro zákazníka je nejlépe odevzdat jej ve formě stromu a nazvat jej oblasti řešení IS. Asi není třeba zdůrazňovat, že zákazník tento strom vidí velice rád, protože mu dává dobrý přehled o funkcionalitách IS, a to opravdu velmi přehledně a názorně. Poznámka: Zde poskytujeme pouze zkrácený popis celé problematiky za účelem tohoto článku, procesnímu modelování a práci s případy užití je ve Školení OOP a UML věnováno celé jedno odpoledne včetně doporučených postupů v EA, tipů, triků a rad... strana 4

5 strana 5 UKONČENÍ ROZKLADU PROCESŮ Velkou výhodou rozkladu je mimo jiné to, že procesy lze dolů libovolně rozkládat a to stále níže a níže... To je sice pěkné, ale kde máme tento postup korektně a správně ukončit? Jak poznáme, že jsme na konci rozkladu? V praxi a také při cvičeních na školeních jsem velmi často narazil na chybně vytvořený rozklad. Nejčastější chybou je neukončení rozkladu procesů podniku v ten moment, kde je třeba jej bezpodmínečně ukončit. Pokračování rozkladu procesů podniku za tento správný bod je totiž nejenom hrubou chybou, ale navíc totálně zmate zákazníka a také vývojáře! Abychom správně pochopili, kde nastal kýžený bod ukončení rozkladu procesů podniku, musíme se si nejprve odpovědět na otázku, proč vlastně hledáme procesy a proč provádíme rozklad procesů. Cíl je jasný: Hledáme případy užití a na to musíme mít fokus. Znamená to, že v okamžiku, kdy nalezneme proces podniku spouštějící případ užití, tak rozklad povinně končíme. Ano, to zní sice jednoduše, ale v praxi se to hůře hledá! Z toho důvodu, tj. abychom pochopili, kde končí rozklad, je třeba si opravdu velmi jasně vysvětlit, jak tento bod přesně vypadá, a potom jej můžeme opravdu přesně určit. Jak má tedy vypadat proces, který se již dále nedělí na sub-procesy, jak jej bezpečně poznáme? Je to takový proces, který spouští případ užití, tj. přímo v něm, v jeho scénáři se o tomto případu užití hovoří, že se daný případ užití použije, nebo jinak řečeno případ užití se zavolá a spustí. Znamená to, že logický scénář procesu podniku, který se dále nedělí, má toto schéma: Něco se děje venku, bla bla atd...., a dále se použije případ užití XY.... Toto schéma logiky scénáře chodu venku je signálem k ukončení rozkladu! Poznámka: Pokud najdeme v jednom procesu více zavolání případů užití, tak doporučuji tento proces ještě jednou rozložit tak, aby každý proces spouštěl právě jeden případ užití. Je to pouze postup pro lepší systematický přehled. Mnohdy pak bývají proces venku pouze malou obálkou zavolání případu užití, například obsluha potřebuje zaevidovat novou fyzickou osobu v systému apod. Je dobré si představit, že případ užití vypadá jako tlačítko na systému, které se nabízí ven k použití. Nápis na tomto tlačítku odpovídá vnějšímu pohledu na prvek v objektovém paradigmatu. Vnější proces venku provádí nějakou činnost, poté děj přistoupí k tomuto tlačítku a to se stiskne. Tam končí popis procesů, protože další rozklad by vedl k popisu chování systému a to je vnitřek (vnitřní pohled) na případ užití, neboli implementace jeho služby užitek případu užití. V tomto bodě tedy rozklad končíme. Této představě odpovídá následující obrázek: strana 5

6 strana 6 Schéma konce rozkladu procesů Koncový dále nedělený proces podniku X Use Case Y scénář procesu a použije se UC Y scénář případu užití Daná situace je velmi podobná popisu chodu funkcí. Představme si, že máme popsat chod funkce F1, která uvnitř sebe volá funkci F2. Začneme popisovat chod funkce F1 až dospějeme k bodu zavolání funkce F2. Popis chodu funkce F1 zde zastavíme (uvnitř funkce F1 nebudeme přece popisovat chod funkce F2, která je volána) a prostě napíšeme a zavolá se F2. Další popis chodu umístíme do funkce F2. A nyní si tento příklad převedeme na situaci procesu posledního procesu rozkladu (viz předešlý obrázek): Funkce F1 odpovídá procesu podniku X, funkce F2 odpovídá případu užití Y. Pokud bychom popisovali chod procesu na straně procesu (další rozklad) i v rámci zavolání případu užití, dopustili bychom se stejné chyby, jako kdybychom v chodu funkce F1 popisovali chod funkce F2. Tok děje u koncového procesu je tedy tento: Něco se děje venku, což popíšeme. V rámci tohoto děje se spustí případ užití. Popíšeme dále děj uvnitř případu užití. Vnější popis končí na stisknutí (zavolání, použití) případu užití informačního systému. Jako příklad hrubé chyby bych uvedl následující rozklad: Rozkladem procesů autor dospěl až k procesu Příjem konečné faktury k proplacení do podniku (úmyslně jsem tento proces podniku nazval dlouhým názvem, aby bylo patrné, co se v něm děje). Při určení chodu tohoto procesu měl autor správně zavolat případ užití Založení nové došlé konečné faktury v systému a scénář procesu mohl v té chvíli vypadat velmi jednoduše: strana 6

7 strana 7 Do podniku došla (například poštou) nová konečná faktura k proplacení od obchodního partnera. Obsluha tuto fakturu zadá do systému, viz případ užití Založení nové došlé konečné faktury v systému. Namísto toho autor chybně pokračuje v rozkladu na straně procesů, a vychází mu proto chybně rozklad na další sub-procesy procesu Příjem konečné faktury k proplacení a to ještě na straně BPM, tj. procesy jako Založení hlavičky faktury, Založení řádků atd. Samozřejmě, že to je špatně... V tomto případě je oprava chyby jednoduchá: Uvedený popis rozkladu za požadovaným bodem se přemístí z prostoru BPM do prostoru za hranice případu užití, tj. dovnitř systému, protože se jedná o jeho řešení (co dělá systém) a problém je vyřešen. Není bez zajímavosti, že pokud autor použije pro popis vnitřku chodu opět Activity diagram namísto slovního scénáře, tak potom vzniknou v projektu dva Activity diagramy: Jeden popisuje chod procesu podniku (mají stereotyp <<business process>). Jeho rozklad končí povinně spuštěním případu užití. Druhý Activity diagram popisuje vnitřek případu užití ( je jich tolik, kolik je případů užití a prvky typu Activity nemají stereotyp <<business process>>), ten začíná svůj chod právě spuštěním případu užití. Pozor, tyto dva diagramy nepatří do jednoho diagramu a tedy do jednoho rozkladu! Jsou to dva diagramy ve dvou oddělených prostorech. Jeden je venku a jeho pohled na systém končí spuštěním případu užití, druhý je uvnitř a popisuje, jak se chová případ užití uvnitř po spuštění! Oba diagramy propojuje bod spuštění případu užití. ZÁVĚR Při rozkladu procesů končíme rozklad okamžikem spuštění případu užití. Až v tomto případu užití (v jeho vnitřku) potom popisujeme další pokračující chod děje (buď slovním scénářem anebo pomocí Activity diagramu), tj. chod procesů na straně BPM již dále nedělíme. Až ve vnitřku případu užití popisujeme, co se děje jako implementaci logiky případu užití (tj. nikoliv na straně procesů podniku). Diskuse k článku viz Fórum Serveru objektových technologií. Konec článku strana 7

ROZDÍL MEZI VZTAHEM EXTEND A INCLUDE V USE CASE DIAGRAMECH

ROZDÍL MEZI VZTAHEM EXTEND A INCLUDE V USE CASE DIAGRAMECH ROZDÍL MEZI VZTAHEM EXTEND A INCLUDE V USE CASE DIAGRAMECH 3. část RNDr. Ilja Kraval, srpen 2009 http://www.objects.cz ÚVOD Tento článek je pokračováním předešlých článků. Článek vysvětluje použití vztahu

Více

Šumperský efekt rozmnožení případů užití

Šumperský efekt rozmnožení případů užití Šumperský efekt rozmnožení případů užití Ilja Kraval, 2007 http://www.objects.cz Článek pojednává o jednom velmi nepříjemném efektu bobtnání projektu. 1. Odhad velikosti a rozsahu informačního systému

Více

NAUČTE SE MALOVAT SI INSTANCE!

NAUČTE SE MALOVAT SI INSTANCE! NAUČTE SE MALOVAT SI INSTANCE! část 2. RNDr. Ilja Kraval, září 2009 http://www.objects.cz ÚVOD V předešlém článku jsme otevřeli jeden ze základních problémů, který musí analytik řešit: Jak vypadá skladba

Více

Druhá část odpovědi na mail ohledně zpracování případů užití

Druhá část odpovědi na mail ohledně zpracování případů užití Druhá část odpovědi na mail ohledně zpracování případů užití Autor RNDr. Ilja Kraval leden 2008 www.objects.cz Úvod Tento článek navazuje jako pokračování na článek předešlý. Minule jsme si vysvětlili,

Více

Úvod do principů objektově orientovaného programování

Úvod do principů objektově orientovaného programování OBSAH DISTANČNÍHO E-LEARNINGOVÉHO KURZU PROFESNÍ RŮST ANALYTIKA OD ZÁKLADŮ (BASE) ÚVOD DO TECHNOLOGIÍ INFORMAČNÍCH SYSTÉMŮ Jak funguje počítač na základní úrovni Základy HTML Skripty ve webovských technologiích

Více

S KONFIGURACÍ POVOLENÝCH KOMBINACÍ DĚDICŮ

S KONFIGURACÍ POVOLENÝCH KOMBINACÍ DĚDICŮ VZOR HETEROGENNÍ SEZNAM S KONFIGURACÍ POVOLENÝCH KOMBINACÍ DĚDICŮ RNDr. Ilja Kraval, září 2008 http://www.objects.cz ÚVOD Jak známo, v CLASS DIAGRAMU se dělí vztahy do dvou základních typů: Buď se jedná

Více

Čtvrtá část odpovědi aneb jak je to vlastně s interakcí <>

Čtvrtá část odpovědi aneb jak je to vlastně s interakcí <<include>> Čtvrtá část odpovědi aneb jak je to vlastně s interakcí autor RNDr. Ilja Kraval leden 2008 www.objects.cz Úvod Tento článek navazuje jako pokračování na články předešlé. Minule jsme si zde

Více

JEDNODUCHÁ A PRAKTICKÁ METODA ODHADU PRACNOSTI PROJEKTU (S UTILITOU KE STAŽENÍ ZDARMA)

JEDNODUCHÁ A PRAKTICKÁ METODA ODHADU PRACNOSTI PROJEKTU (S UTILITOU KE STAŽENÍ ZDARMA) JEDNODUCHÁ A PRAKTICKÁ METODA ODHADU PRACNOSTI PROJEKTU (S UTILITOU KE STAŽENÍ ZDARMA) 2. část autor: RNDr. Ilja Kraval, červenec 2010 http://www.objects.cz ÚVOD V minulém článku bylo pojednáno o složitosti

Více

Odpověď na dotaz ohledně asociační třídy v modelu měření

Odpověď na dotaz ohledně asociační třídy v modelu měření Odpověď na dotaz ohledně asociační třídy v modelu Část 4. Tento článek navazuje na předešlé články jako jejich pokračování autor RNDr. Ilja Kraval, http://www.objects.cz září 2007 firma Object Consulting

Více

O JEDNÉ ZÁLUDNOSTI INTERAKCE «INCLUDE» V MODELU PŘÍPADŮ UŽITÍ

O JEDNÉ ZÁLUDNOSTI INTERAKCE «INCLUDE» V MODELU PŘÍPADŮ UŽITÍ O JEDNÉ ZÁLUDNOSTI INTERAKCE «INCLUDE» V MODELU PŘÍPADŮ UŽITÍ 2. část RNDr. Ilja Kraval, květen 2010 http://www.objects.cz ÚVOD V předešlém článku jsme nastínili problém, který vzniká v souvislosti s hledáním

Více

Proč je analytický model IS nutným předpokladem pro zabránění tvorbě molochálních systémů

Proč je analytický model IS nutným předpokladem pro zabránění tvorbě molochálních systémů Proč je analytický model IS nutným předpokladem pro zabránění tvorbě molochálních systémů Část 1 autor RNDr. Ilja Kraval, http://www.objects.cz březen 2007 firma Object Consulting s.r.o. Úvod V reakci

Více

JE TŘEBA DBÁT NA ANONYMITU KLIENTA NEBO NE?

JE TŘEBA DBÁT NA ANONYMITU KLIENTA NEBO NE? JE TŘEBA DBÁT NA ANONYMITU KLIENTA NEBO NE? RNDr. Ilja Kraval, říjen 2008 http://www.objects.cz ÚVOD Začnu jedním zajímavým postřehem: Na našich školeních OOP a UML existují určitá témata, která při jejich

Více

Problémové domény a jejich charakteristiky

Problémové domény a jejich charakteristiky Milan Mišovič (ČVUT FIT) Pokročilé informační systémy MI-PIS, 2011, Přednáška 02 1/16 Problémové domény a jejich charakteristiky Prof. RNDr. Milan Mišovič, CSc. Katedra softwarového inženýrství Fakulta

Více

Případy užití (use case) Projektování SW systémů

Případy užití (use case) Projektování SW systémů Univerzita Pardubice Fakulta elektrotechniky a informatiky Případy užití (use case) Projektování SW systémů Matěj Trakal Poslední úprava: 24. ledna 2012, 17:06 INPSW 2011 (Šimerda) OBSAH Obsah 1 Co jsou

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

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

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

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

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

Základní informace. Modelování. Notace

Základní informace. Modelování. Notace Základní informace BPMS = business process management systems - systémy pro modelování a optimalizace business procesů uvnitř organizace BPMN = business process modeling notation - součást BPMS, notace

Více

PŘEHLED FUNKCÍ PROGRAMU KROK ZA KROKEM

PŘEHLED FUNKCÍ PROGRAMU KROK ZA KROKEM PŘEHLED FUNKCÍ PROGRAMU KROK ZA KROKEM Základní informace: Program byl konstruován především pro komplexní zpracování zakázek ve společnosti. Je postaven obecně, specializované funkce byly však přizpůsobeny

Více

Vyhrávejte bez boje nad legislativními změnami

Vyhrávejte bez boje nad legislativními změnami Vyhrávejte bez boje nad legislativními změnami Pro většinu organizací znamená legislativní změna nekonečné hodiny jednoho nešťastníka strávené nad novým textem - studuje rozdíly, novinky, aktualizace postupů.

Více

Manuál k ovládání aplikace INFOwin.

Manuál k ovládání aplikace INFOwin. Manuál k ovládání aplikace INFOwin. Základní práce s formuláři je ve všech modulech totožná. Vybereme tedy například formulář Pokladní kniha korunová na kterém si funkce ukážeme. Po zápisech se lze pohybovat

Více

2. Modelovací jazyk UML 2.1 Struktura UML 2.1.1 Diagram tříd 2.1.1.1 Asociace 2.1.2 OCL. 3. Smalltalk 3.1 Jazyk 3.1.1 Pojmenování

2. Modelovací jazyk UML 2.1 Struktura UML 2.1.1 Diagram tříd 2.1.1.1 Asociace 2.1.2 OCL. 3. Smalltalk 3.1 Jazyk 3.1.1 Pojmenování 1. Teoretické základy modelování na počítačích 1.1 Lambda-kalkul 1.1.1 Formální zápis, beta-redukce, alfa-konverze 1.1.2 Lambda-výraz jako data 1.1.3 Příklad alfa-konverze 1.1.4 Eta-redukce 1.2 Základy

Více

Analýza a návrh webových aplikací I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W

Analýza a návrh webových aplikací I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Analýza a návrh webových aplikací I N G. M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Osnova dnešní přednášky Proč tento předmět vlastně existuje? Proč nestačí standardní metodiky SI? Co standardním

Více

Jedna z velmi častých a závažných chyb při návrhu IS aneb jak vznikají tzv. molochální systémy

Jedna z velmi častých a závažných chyb při návrhu IS aneb jak vznikají tzv. molochální systémy Jedna z velmi častých a závažných chyb při návrhu IS aneb jak vznikají tzv. molochální systémy Část druhá autor RNDr. Ilja Kraval, http://www.objects.cz červenec 2006 (pozn.: článek navazuje na první část

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

Uživatelská příručka

Uživatelská příručka www.rexcontrols.cz www.contlab.eu www.pidlab.com Ovladač systému REX pro 1-Wire (modul OwsDrv) Uživatelská příručka REX Controls s.r.o. Verze 2.10.7 (revize 2) Plzeň 16.12.2015 Obsah 1 Ovladač OwsDrv a

Více

OPS Paralelní systémy, seznam pojmů, klasifikace

OPS Paralelní systémy, seznam pojmů, klasifikace Moorův zákon (polovina 60. let) : Výpočetní výkon a počet tranzistorů na jeden CPU chip integrovaného obvodu mikroprocesoru se každý jeden až dva roky zdvojnásobí; cena se zmenší na polovinu. Paralelismus

Více

Modelování procesů (2) 23.3.2009 Procesní řízení 1

Modelování procesů (2) 23.3.2009 Procesní řízení 1 Modelování procesů (2) 23.3.2009 Procesní řízení 1 Seznam notací Síťové diagramy Notace WfMC Notace Workflow Together Editor Aktivity diagram (UML) FirsStep Designer Procesní mapa Select Prespective (procesní

Více

01. HODINA. 1.1 Spuštění programu VB 2010. 1.2 Prvky integrovaného vývojového prostředí. - pomocí ikony, z menu Start.

01. HODINA. 1.1 Spuštění programu VB 2010. 1.2 Prvky integrovaného vývojového prostředí. - pomocí ikony, z menu Start. 01. HODINA 1.1 Spuštění programu VB 2010 - pomocí ikony, z menu Start. - po spuštění si můžeme vybrat, zda chceme vytvořit nový Projekt a jaký nebo zda chceme otevřít již existující Projekt. 1.2 Prvky

Více

Modul Intrastat. www.money.cz

Modul Intrastat. www.money.cz Modul Intrastat www.money.cz 2 Money S5 Intrastat Co je Intrastat Intrastat je statistika obchodu se zbožím mezi Českou republikou a ostatními členskými státy Evropské unie. Informace lze najít na www.czso.cz,

Více

JčU - Cvičení z matematiky pro zemědělské obory (doc. RNDr. Nýdl, CSc & spol.) Minitest MT4

JčU - Cvičení z matematiky pro zemědělské obory (doc. RNDr. Nýdl, CSc & spol.) Minitest MT4 ŘEŠENÍ MINITESTŮ JčU - Cvičení z matematiky pro zemědělské obory (doc. RNDr. Nýdl, CSc & spol.) Minitest MT4. Z daných tří soustav rovnic o neznámých x, x vyberte právě všechny ty, které jsou regulární.

Více

Unifikovaný modelovací jazyk UML

Unifikovaný modelovací jazyk UML Unifikovaný modelovací jazyk UML Karel Richta katedra počíta tačů FEL ČVUT Praha richta@fel fel.cvut.czcz Motto: Komunikačním m prostředkem informační komunity se postupem času stala angličtina. Chcete-li

Více

TAOS321. Administrace. příručka správce systému. informační terminál systému JSVV

TAOS321. Administrace. příručka správce systému. informační terminál systému JSVV TAOS321 informační terminál systému JSVV Administrace příručka správce systému Text odpovídá verzi firmware: TAOS321 1.0 2014, Technologie 2000 spol. s r.o. Jablonec nad Nisou TAOS321 informační terminál

Více

VYHLEDÁVÁNÍ PRVKŮ ACTOR A PROCESNÍ MODELOVÁNÍ

VYHLEDÁVÁNÍ PRVKŮ ACTOR A PROCESNÍ MODELOVÁNÍ VYHLEDÁVÁNÍ PRVKŮ ACTOR A PROCESNÍ MODELOVÁNÍ Část 2 Tento článek je pokračováním předešlého článku RNDr. Ilja Kraval, duben 2009 http://www.objects.cz ÚVOD V předešlém článku jsme se seznámili s použitím

Více

Allegro účetnictví. Schéma účetního modulu. Podstatné vlastnosti. Allegro Business Solution Účetnictví

Allegro účetnictví. Schéma účetního modulu. Podstatné vlastnosti. Allegro Business Solution Účetnictví Allegro účetnictví Obsahuje zákonem vyžadované agendy podvojného účetnictví a tvoří jádro celého systému. Standardní bloky zahrnují účetní knihu, faktury přijaté a vydané, banky, pokladny a přiznání DPH.

Více

Start Trh Spotřebitel Nápad Koncept Hodnocení. Kdo jsou cíloví spotřebitelé konceptu?

Start Trh Spotřebitel Nápad Koncept Hodnocení. Kdo jsou cíloví spotřebitelé konceptu? Spotřebitel Start Trh Spotřebitel Nápad Koncept Hodnocení Kdo jsou cíloví spotřebitelé konceptu? Specifikujte např. 3-5 různých skupin spotřebitelů pro Váš koncept a rozpracujte popis typického zástupce

Více

D1 Trvalá organizace

D1 Trvalá organizace Projektový manažer 250+ Kariéra projektového manažera začíná u nás! D Útvarové a procesní řízení D1 Trvalá organizace Toto téma obsahuje informace o trvalé organizaci, jejích základních principech a prostředí.

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

Typy souborů ve STATISTICA. Tento článek poslouží jako přehled hlavních typů souborů v programu

Typy souborů ve STATISTICA. Tento článek poslouží jako přehled hlavních typů souborů v programu StatSoft Typy souborů ve STATISTICA Tento článek poslouží jako přehled hlavních typů souborů v programu STATISTICA, ukáže Vám jejich možnosti a tím Vám dovolí využívat program efektivněji. Jistě jste již

Více

Testování operačního systému Windows Phone 8

Testování operačního systému Windows Phone 8 Testování operačního systému Windows Phone 8 Semestrální práce A2 v rámci předmětu A4B39TUR Muška Adam ČVUT FEL STM 0 Obsah 1. Popis přístroje... 2 2. Popis cílové skupiny... 2 3. Přehled případů užití...

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

WinFAS. informace. Doprovodná příručka ke školení Základy ovládání IS WinFAS

WinFAS. informace. Doprovodná příručka ke školení Základy ovládání IS WinFAS informace Doprovodná příručka ke školení Základy ovládání IS verze z 30.3.2005 se skládá z modulů které se dále člení. Modulem chápeme skupinu číselníků, aplikací a sestav, které slouží ke správě určité

Více

Questionnaire příručka uživatele

Questionnaire příručka uživatele Questionnaire příručka uživatele Obsah: K čemu aplikace slouží? Popis funkcí Návod k použití o Úvodní dialogové okno o Pro respondenty o Pro administrátory K čemu aplikace slouží? Program questionnaire

Více

OOT Objektově orientované technologie

OOT Objektově orientované technologie OOT Objektově orientované technologie Požadavky a případy užití Daniela Szturcová, Pavel Děrgel Institut geoinformatiky, HGF Osnova Systém Uživatelé Případy užití Vazby (asociace, generalizace, include

Více

8.2 Používání a tvorba databází

8.2 Používání a tvorba databází 8.2 Používání a tvorba databází Slide 1 8.2.1 Základní pojmy z oblasti relačních databází Slide 2 Databáze ~ Evidence lidí peněz věcí... výběry, výpisy, početní úkony Slide 3 Pojmy tabulka, pole, záznam

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_31_02 Škola Střední průmyslová škola Zlín 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 Inovace výuky

Více

Allegro fakturace. Schéma fakturačního modulu. Podstatné vlastnosti. Allegro Business Solution Fakturace

Allegro fakturace. Schéma fakturačního modulu. Podstatné vlastnosti. Allegro Business Solution Fakturace Allegro fakturace Obsahuje evidenci faktur vydaných i přijatých a stejně tak zálohových faktur vydaných i přijatých. Ačkoli je modul z praktických důvodů veden jako samostatný celek, jeho úzká provázanost

Více

Operační systém. Mgr. Renáta Rellová. Výukový materiál zpracován v rámci projektu EU peníze školám

Operační systém. Mgr. Renáta Rellová. Výukový materiál zpracován v rámci projektu EU peníze školám Operační systém Mgr. Renáta Rellová Výukový materiál zpracován v rámci projektu EU peníze školám Autorem materiálu a všech jeho částí, není-li uvedeno jinak, je Mgr. Renáta Rellová. Dostupné z Metodického

Více

32 APZ Nabídky. Popis modulu

32 APZ Nabídky. Popis modulu 32 APZ Nabídky Uživatelský modul APZ Nabídky náleží k modulům řešícím agendu agentury podporovaného zaměstnávání se zaměřením na osoby se zdravotním postižením. Modul umožňuje evidenci pracovních nabídek

Více

Vztah typu Extend v UML a jeho zvláštnosti

Vztah typu Extend v UML a jeho zvláštnosti Vztah typu Extend v UML a jeho zvláštnosti RNDr. Ilja Kraval 2007 Object Consulting s.r.o. http://www.objects.cz objects@objects.cz Do diskusního fóra na Pandoře (http://pandora.idnes.cz/conference/objcon/)

Více

Rady pro tvorbu USE CASE MODELU, rada první: Jak pracovat s pojmy ve scénářích UC

Rady pro tvorbu USE CASE MODELU, rada první: Jak pracovat s pojmy ve scénářích UC Rady pro tvorbu USE CASE MODELU, rada první: Jak pracovat s pojmy ve scénářích UC Úvod Před nedávnem jsem obdržel trochu delší mail tohoto znění: Dobrý den pane Kravale, před časem jsem absolvoval vaše

Více

Manuál QPos Pokladna V1.18.1

Manuál QPos Pokladna V1.18.1 Manuál QPos Pokladna V1.18.1 OBSAH Obsah 1. QPOS dotyková pokladna... 3 2. Jak číst tento manuál... 4 2.1. Čím začít?... 4 2.2. Členění kapitol... 4 2.3. Speciální text... 4 3. První spuštění... 5 3.1.

Více

Kurz Postupy návrhu IS pomocí UML a OOP (5 dnů, in-house)

Kurz Postupy návrhu IS pomocí UML a OOP (5 dnů, in-house) Kurz Postupy návrhu IS pomocí UML a OOP (5 dnů, in-house) přednáší RNDr. Ilja Kraval pořádá firma OBJECT CONSULTING Obsah: Kurz Efektivní postupy návrhu IS pomocí UML a OOP (5 dnů, in-house)... 1 1. Jak

Více

OBSAH. 48 Příručka ON-LINE KUPEG úvěrová pojišťovna, a.s. www.kupeg.cz

OBSAH. 48 Příručka ON-LINE KUPEG úvěrová pojišťovna, a.s. www.kupeg.cz DODATEK č. 1 20.1.2012 OBSAH OBSAH... 48 C. PRÁCE SE SYSTÉMEM... 49 C.1 ÚVODNÍ OBRAZOVKA PO PŘIHLÁŠENÍ... 49 C.2 NASTAVENÍ VLASTNÍCH ÚDAJŮ... 50 a. Nastavení Uživatele... 50 b. Nastavení Systému... 51

Více

StatSoft Jak vyzrát na datum

StatSoft Jak vyzrát na datum StatSoft Jak vyzrát na datum Tento článek se věnuje podrobně možnostem práce s proměnnými, které jsou ve formě datumu. A že jich není málo. Pokud potřebujete pracovat s datumem, pak se Vám bude tento článek

Více

JRV.CZ s.r.o. Bulharská 4 612 00 Brno www.rosadata.cz. RosaData. Pohledávky

JRV.CZ s.r.o. Bulharská 4 612 00 Brno www.rosadata.cz. RosaData. Pohledávky RosaData Pohledávky OBSAH Úvod... 3 Popis procesu... 3 Přehled pohledávek a závazků... 5 Nové vymáhání... 6 Akce vymáhání... 9 Přehled vymáhání... 10 Nastavení... 12 Procesy vymáhání... 12 Typ vymáhání...

Více

3.5.2007-9.5.2007. Jazykové okénko... 7.5.2007 ČT 1 str. 1 07:50 Rubrika dne - Ostrava

3.5.2007-9.5.2007. Jazykové okénko... 7.5.2007 ČT 1 str. 1 07:50 Rubrika dne - Ostrava 3.5.2007-9.5.2007 Jazykové okénko... Jazykové okénko Tak a zatímco já jsem vás vítal u obrazovek, tak mě tady sledovala, čekala, až domluvím, paní Eva Jandová, vedoucí Katedry českého jazyka z Ostravské

Více

Vlákno (anglicky: thread) v informatice označuje vlákno výpočtu neboli samostatný výpočetní tok, tedy posloupnost po sobě jdoucích operací.

Vlákno (anglicky: thread) v informatice označuje vlákno výpočtu neboli samostatný výpočetní tok, tedy posloupnost po sobě jdoucích operací. Trochu teorie Vlákno (anglicky: thread) v informatice označuje vlákno výpočtu neboli samostatný výpočetní tok, tedy posloupnost po sobě jdoucích operací. Každá spuštěná aplikace má alespoň jeden proces

Více

OOT Objektově orientované technologie

OOT Objektově orientované technologie OOT Objektově orientované technologie Požadavky a případy užití Daniela Szturcová Institut geoinformatiky, HGF Osnova Systém Uživatelé Případy užití Vazby (asociace, generalizace, include a extend) Shrnutí

Více

UML. Unified Modeling Language. Součásti UML

UML. Unified Modeling Language. Součásti UML UML Unified Modeling Language 1995 počátek 1997 verze 1.0 leden dnes verze 2.0 (vývoj stále nedokončen) Standardní notace OMG podpora velkých firem (Microsoft, IBM, Oracle, HP ) popisuje struktury popisuje

Více

Nutnost použití vzoru OBSERVER pro zamezení nepříjemných efektů zpětných funkcionálních vazeb mezi objekty

Nutnost použití vzoru OBSERVER pro zamezení nepříjemných efektů zpětných funkcionálních vazeb mezi objekty Nutnost použití vzoru OBSERVER pro zamezení nepříjemných efektů zpětných funkcionálních vazeb mezi objekty autor RNDr. Ilja Kraval, http://www.objects.cz únor 2007 firma Object Consulting s.r.o. Úvod V

Více

Metodická pomůcka pro specifikaci dočasných opatření. doc. Ing. Pavel Šenovský, Ph.D. Ing. Pavlína Ježková

Metodická pomůcka pro specifikaci dočasných opatření. doc. Ing. Pavel Šenovský, Ph.D. Ing. Pavlína Ježková Metodická pomůcka pro specifikaci dočasných opatření doc. Ing. Pavel Šenovský, Ph.D. Ing. Pavlína Ježková Vysoká škola báňská Technická univerzita Ostrava, Fakulta bezpečnostního inženýrství Ostrava 2013

Více

Databázové patterny. MI-DSP 2013/14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu

Databázové patterny. MI-DSP 2013/14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu Databázové patterny MI-DSP 2013/14 RNDr. Ondřej Zýka, ondrej.zyka@profinit.eu Obsah o Co je databázový pattern o Pattern: Přiřazení rolí o Pattern: Klasifikace Databázové patterny o Odzkoušené a doporučené

Více

Komputerizace problémových domén

Komputerizace problémových domén Milan Mišovič (ČVUT FIT) Pokročilé informační systémy MI-PIS, 2011, Přednáška 03 1/19 Komputerizace problémových domén Prof. RNDr. Milan Mišovič, CSc. Katedra softwarového inženýrství Fakulta informačních

Více

Rizikové procesy. 1. Spuštění modulu Rizikové procesy. 2. Popis prostředí a ovládacích prvků modulu Rizikové procesy

Rizikové procesy. 1. Spuštění modulu Rizikové procesy. 2. Popis prostředí a ovládacích prvků modulu Rizikové procesy Rizikové procesy Modul slouží k evidenci rizik a zpracovávání mapy rizik za jednotlivé součásti a VUT. Přístupová práva k tomuto modulu mohou získat manažeři rizik a výbor pro řízení rizik. 1. Spuštění

Více

Zápis klasifikace pro učitele teoretické výuky

Zápis klasifikace pro učitele teoretické výuky Evropský sociální fond Střední škola umělecká a řemeslná "Praha a EU: Investujeme do vaší budoucnosti" Projekt IMPLEMENTACE ŠVP Zápis klasifikace pro učitele teoretické výuky Tento tematický plán je pro

Více

9. Může dojít k situaci, že ZP je nutno aktualizovat (změna vzhledu, změna příjmení, změna -1- dále ZP).

9. Může dojít k situaci, že ZP je nutno aktualizovat (změna vzhledu, změna příjmení, změna -1- dále ZP). 1 Popis ucelené problémové domény Následující komplexní příklad se týká domény soukromých zbraní v ČR (SSZ v ČR) Ukážeme nejdříve její obecný popis, ale nebudeme se přísně držet současně platného zákona

Více

Problém identity instancí asociačních tříd

Problém identity instancí asociačních tříd Problém identity instancí asociačních tříd Autor RNDr. Ilja Kraval Ve školeních a také následně po jejich ukončení se stále častěji objevují dotazy, které se týkají tzv. identity instancí asociační třídy.

Více

Informace a znalosti v organizaci

Informace a znalosti v organizaci Informace a znalosti v organizaci Vladimíra Zádová Postavení informací a znalostí z hlediska úspěšnosti firmy Vnitřní faktory Rámec 7S faktorů úspěchu firmy [ Mc Kinsey ] Struktura Strategie Systémy Spolupracovníci

Více

Vzorce. StatSoft. Vzorce. Kde všude se dá zadat vzorec

Vzorce. StatSoft. Vzorce. Kde všude se dá zadat vzorec StatSoft Vzorce Jistě se Vám již stalo, že data, která máte přímo k dispozici, sama o sobě nestačí potřebujete je nějak upravit, vypočítat z nich nějaké další proměnné, provést nějaké transformace, Jinak

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

Vlastnosti dokumentu/stránky

Vlastnosti dokumentu/stránky Vlastnosti dokumentu/stránky Formát stránky papíru pro tisk V záložce Rozložení stránky na pásu karet najdeme vše potřebné pro přípravu dokumentu před tiskem. 1) Záložka Rozložení stránky 2) Změna Orientace

Více

( ) Jako základ mocnin nemusíme používat jen 10. Pokud není jasné, že číslo je uvedeno v desítkové soustavě, píšeme jej takto: ( 12054 ) 10

( ) Jako základ mocnin nemusíme používat jen 10. Pokud není jasné, že číslo je uvedeno v desítkové soustavě, píšeme jej takto: ( 12054 ) 10 .. Číselné soustavy I Předpoklady: základní početní operace Pedagogická poznámka: Tato a následující hodina není součástí klasické gymnaziální sady. Upřímně řečeno nevím proč. Jednak se všichni studenti

Více

WinFAS. 3 účto. Praktický úvod do WinFASu Banka

WinFAS. 3 účto. Praktický úvod do WinFASu Banka 3 účto Praktický úvod do u Banka verze z 30.3.2005 Zadání Teorie - Rozdíly FAS a - vytvoření příkazu se dělí na dvě části - vytvoření předvýběru - vyhotovení a odeslání příkazu - práce s výpisem se dělí

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

Další servery s elektronickým obsahem

Další servery s elektronickým obsahem Právní upozornění Všechna práva vyhrazena. Žádná část této tištěné či elektronické knihy nesmí být reprodukována a šířena v papírové, elektronické či jiné podobě bez předchozího písemného souhlasu nakladatele.

Více

Dominik Vymětal. Informační technologie pro praxi 2009, Ostrava 1.-2.10.2009 1

Dominik Vymětal. Informační technologie pro praxi 2009, Ostrava 1.-2.10.2009 1 Dominik Vymětal 2009, Ostrava 1.-2.10.2009 1 Procesní model Výhody Orientace na konkrétní činnosti a možnost reengineeringu Nevýhody Malá orientace na průřezové nebo opakované činnosti Modely na základě

Více

Návrh a management projektu. Řízení a koordinace projektu

Návrh a management projektu. Řízení a koordinace projektu Návrh a management projektu Řízení a koordinace projektu ČVUT FAKULTA BIOMEDICÍNSKÉHO INŽENÝRSTVÍ strana 1 Ing. Vladimír Jurka 2013 Program přednášky Komunikační nástroje Dokumenty řízení projektu Řízení

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

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

Start Trh Spotřebitel Nápad Koncept Hodnocení. Kdo jsou cíloví spotřebitelé konceptu?

Start Trh Spotřebitel Nápad Koncept Hodnocení. Kdo jsou cíloví spotřebitelé konceptu? Spotřebitel Kdo jsou cíloví spotřebitelé konceptu? Specifikujte např. 3-5 různých skupin spotřebitelů pro Váš koncept a rozpracujte popis typického zástupce v každé skupině. Příklad níže. Spotřebitelský

Více

Řízení IT v PRE. Velmi stručné teze

Řízení IT v PRE. Velmi stručné teze Řízení IT v PRE Velmi stručné teze M. Hübner J. Kalousek listopad 2013 Jak představit řízení IT v PRE? představit prakticky využívané principy postřehy a útržky z našeho systému proto budou teze, úspěšné

Více

Jazyk UML - přehled. diagram hierarchie procesů. IS firmy. podpora řízení. evidence zaměstnanců. pokladny. výroba. diagram procesních vláken

Jazyk UML - přehled. diagram hierarchie procesů. IS firmy. podpora řízení. evidence zaměstnanců. pokladny. výroba. diagram procesních vláken Jazyk UML - přehled Unified Modeling Language jazyk pro popis objektově orientované analýzy a návrhu aplikací slouží k vzájemné komunikaci mezi zadavatelem a návrhářem systému má několik částí, není nutné

Více

2.7.6 Rovnice vyšších řádů

2.7.6 Rovnice vyšších řádů 6 Rovnice vyšších řádů Předpoklady: 50, 05 Pedagogická poznámka: Pokud mám jenom trochu čas probírám látku této hodiny ve dvou vyučovacích hodinách V první probíráme separaci kořenů, v druhé pak snížení

Více

Jak vytvořit sestavy na míru v registru zvířat (IZR)

Jak vytvořit sestavy na míru v registru zvířat (IZR) Jak vytvořit sestavy na míru v registru zvířat (IZR) Obsah Jak vytvořit sestavy na míru v registru zvířat (IZR)... 1 1. Úvod... 1 2. Sestavy v MS Excel... 2 2.1. Volba sloupců sestavy... 2 2.2. Volba řádků

Více

Zapnutí a vypnutí počítače

Zapnutí a vypnutí počítače Zapnutí a vypnutí počítače Popiš běžné součásti počítače Napiš co ti u tohoto počítače chybí? Spoj každý pojem se správnou odpovědí: Procesor Modem Program Paměť Disk Monitor Grafická karta Zvuková karta

Více

Návod pro vyplnění elektronické žádosti o poskytnutí podpory

Návod pro vyplnění elektronické žádosti o poskytnutí podpory Návod pro vyplnění elektronické žádosti o poskytnutí podpory Tento návod slouží pro správné vyplnění formuláře žádosti o poskytnutí podpory pro podprogram (PF01-10) vodohospodářská infrastruktura v obcích

Více

NP-úplnost problému SAT

NP-úplnost problému SAT Problém SAT je definován následovně: SAT(splnitelnost booleovských formulí) Vstup: Booleovská formule ϕ. Otázka: Je ϕ splnitelná? Příklad: Formule ϕ 1 =x 1 ( x 2 x 3 )jesplnitelná: např.přiohodnocení ν,kde[x

Více

Přednáška. Sběr požadavků na SW s použitím metody C.C a nástroje Craft.CASE. e-fractal, s.r.o.

Přednáška. Sběr požadavků na SW s použitím metody C.C a nástroje Craft.CASE. e-fractal, s.r.o. Přednáška Sběr požadavků na SW s použitím metody C.C a nástroje Craft.CASE e-fractal, s.r.o. Úvod Agenda Motivace proč modelovat procesy Stručný úvod do metody C.C Příklad Motivace proč modelovat procesy

Více

Nyní využijeme slovník Laplaceovy transformace pro derivaci a přímé hodnoty a dostaneme běžnou algebraickou rovnici. ! 2 "

Nyní využijeme slovník Laplaceovy transformace pro derivaci a přímé hodnoty a dostaneme běžnou algebraickou rovnici. ! 2 ŘEŠENÉ PŘÍKLADY Z MB ČÁST Příklad Nalezněte pomocí Laplaceovy transformace řešení dané Cauchyho úlohy lineární diferenciální rovnice prvního řádu s konstantními koeficienty v intervalu 0,, které vyhovuje

Více

Opravy a prodej. Uživatelská příručka. Milan Hradecký.

Opravy a prodej. Uživatelská příručka. Milan Hradecký. Opravy a prodej Uživatelská příručka Milan Hradecký. 2 1. ÚVOD : Program slouží k evidenci dílenských oprav, k prodeji náhradních dílů a k fakturaci. Pracuje v prostředí WINDOWS 95 až WINDOWS XP. K rychlému

Více

B2 Organizace jako systém

B2 Organizace jako systém Projektový manažer 250+ Kariéra projektového manažera začíná u nás! B Strategické řízení organizace B2 Organizace jako systém Toto téma obsahuje informace o způsobech a přístupech k řízení organizace jako

Více

Business Intelligence

Business Intelligence Business Intelligence Josef Mlnařík ISSS Hradec Králové 7.4.2008 Obsah Co je Oracle Business Intelligence? Definice, Od dat k informacím, Nástroj pro operativní řízení, Integrace informací, Jednotná platforma

Více

http://www.autodeskclub.cz/club/articleforprinting.aspx?article=676592d8-f86...

http://www.autodeskclub.cz/club/articleforprinting.aspx?article=676592d8-f86... Stránka č. 1 z 6 Tvorba sestav a jejich modifikace (4.7. 2008 Fořt Petr ) Dnešní článek věnujeme metodice tvorby sestav. Pokusíme se najít nejdůležitější podmínky, které jsou pro tvorbu sestav kritické

Více

RPDP v DUEL 8. Režim přenesení daňové povinnosti v programu DUEL verze 8.0

RPDP v DUEL 8. Režim přenesení daňové povinnosti v programu DUEL verze 8.0 RPDP v DUEL 8 Režim přenesení daňové povinnosti v programu DUEL verze 8.0 1. Nastavení potřebných parametrů účtované firmy Agenda: Parametry firmy (Ctrl+H / Parametry firmy) Záložka Parametry firmy: hlavička

Více

Projekt Akademie. Robert Mařík

Projekt Akademie. Robert Mařík Projekt Akademie Setkání řešitelského týmu 12.9.2013 Klíčová aktivita 5 Robert Mařík Obsah Obsah klíčové aktivity (web) Stav v září 2013 Filozofie webu Co a jak musím nastavit v předmětech, kde jsem lektorem

Více