Narozeniny ministra Adama Vojtěcha: Tvarohové knedlíky, porušená tradice a speciální překvapení od krásné manželky | ŽivotvČesku.cz\nAdam Vojtěch patří na poli české politické scény k výrazným osobnostem. Poté, co krátce před svými narozeninami 21. září 2020 v době druhé vlny koronaviru v Česku odstoupil z funkce šéfa rezortu zdravotnictví, rozhodl se více věnovat osobnímu životu, manželce Olze a v hlavě měl i plány na rozjezd hudebních projektů. V květnu však převzal post po Petru Arenbergerovi (62) znovu, ale své setrvání datuje ke konci voleb, kdy se chce z politiky stáhnout.\nS manželkou slaví v říjnu dvouleté výročí od pohádkové svatby, která se konala v kapli Korunování Panny Marie ve středočeských Niměřicích, ale také 35. narozeniny – připadají na 2. října.\n"Letos to vyšlo skvěle, protože narozeniny bude mít v sobotu, a tak je můžeme strávit v klidu a pohodě. Plány ale prozradit nemůžu, protože to opravdu bude celé překvapení. Obvyklé bývalo v minulých letech bohužel to, že jsme oslavu museli kvůli práci odložit, ale tentokrát tuhle smutnou tradici snad konečně porušíme," prozradila Olga Vojtěchová pro ŽivotvČesku.cz.\nKe každé oslavě by měl patřit přípitek a kromě dobrého jídla samozřejmě i v decentní míře alkohol. "Manžel je téměř abstinent, ale určitě můžu prozradit, ze jeho narozeninový den začne jeho nejoblíbenějším jídlem, kterým jsou tvarohové knedlíky," dodala sympatická blondýnka a osudová žena ministra zdravotnictví pro ŽivotvČesku.cz.


Stránka o seriálu Madam Secretary – 6. stránka – Bývalá analytička CIA zastává státní úřad\nTitulky k finále první série jsou hotové!\n12.7.2015 Valada06 Novinky, Titulky\nDnes vám přinášíme titulky k dvaadvacáté a zároveň finálové epizodě první série s názvem There But For The Grace Of God. Titulky pro vás připravili Honzajs000, Valada06 a cev. Sedí na verzi .x264-LOL. Stahovat je můžete zde. Elizabeth je poslána vyslechnout Juliet, ta všem zatvrzele odmítá cokoliv prozradit a řekne Bess, a Elizabeth se tak musí pokusit najít způsob, jak ji\nPromo k finálové epizodě první série\n5.7.2015 Valada06 Novinky\nJe to tady! Příští týden vám nabídneme titulky ke dvaadvacáté a závěrečné epizodě první série s názvem There But For The Grace Of God. Ti z vás, kdo již viděli epizodu minulou jistě vědí, že Elizabeth byla na konci této epizody pověřena vyslechnout Juliet, svou bývalou kolegyni a kamarádku ze CIA. V nadcházející epizodě uvidíme, zda se Elizabeth podaří nějaké\nTitulky k S01E21 dokončeny!\n5.7.2015 Valada06 Novinky, Titulky\nPřipravili jsme pro vás titulky k předposlední epizodě první série s názvem The Kill List. Titulky pro vás připravili Honzajs000, Valada06 a cev. Sedí na verzi HDTV.x264-LOL. Stahovat je můžete zde. Vyjednávání o vydání Juliet se stále nepohnula, ale poté, co se Juliet nabourá do webkamery v bytě jejího manžela, se ji NSA podaří zaměřit a prezident Dalton se\nUkázka z dvacáté první epizody\n1.7.2015 Valada06 Novinky\nPamatujete jak Juliet poslala Elizabeth v šestnáctém díle email, že se chce vrátit do Států? Ale od té doby jsme o Juliet neslyšeli, což konečně napraví další epizoda, ve které se opět vrátíme k hlavní zápletce celé první série, která se točí kolem atentátu na bývalého ministra zahraničí Marshe a plánování převratu v Íránu. Titulků k předposlední epizodě první\nTitulky k S01E20 hotovy\n30.6.2015 Valada06 Novinky, Titulky\nTitulky k před-předposlední epizodě seriálu Madam Secretary s názvem The Neccessary Art jsou hotovy! Připravili je pro vás Honzajs000, Valada06 a cev. Stahovat je můžete zde. NATO se chystá na lotyšskou hranici nasadit vojáky NATO jako reakci na kroky Ruska. Rusko na tuto akci reaguje vysláním své ponorky s průlomovou zakrývací technologií k břehům Aljašky. Henry se navíc chystá do\nRozhovor s Téou Leoni nejen o cenách Emmy\n28.6.2015 Valada06 Novinky\nČekání na vydání českých titulků si můžete zkrátit přečtením dalších z řady rozhovorů. Představitelka hlavní postavy seriálu Madam Secretary Téa Leoni totiž nedávno poskytla rozhovor serveru The WRAP a mluvila například o tom, které osobnosti světové politiky inspirovali její roli Elizabeth. Rozhovořila se také o případných nominacích na ceny Emmy. Rozhovor jsme pro vás samozřejmě přeložili. Rozhovor si v angličtině můžete\nPromo k S01E20\n25.6.2015 Valada06 Novinky\nMadam Secretary se v posledních dvou týdnech drží velmi aktuálních témat. V minulé epizodě jsme se zabývali řeckým dluhem a nakonec jsme se dočkali světové dluhové krize. Tento týden se zaměříme na novodobé vztahy Ruska a Ameriky, které dnešní politologové nazývají novou Studenou válkou. Povede se i tento „požár“ nakonec uhasit? Titulky k pořadí jíž dvacáté epizodě můžete očekávat již\nTitulky k S01E19 hotovy!\n20.6.2015 Valada06 Novinky, Titulky\nDnes vám trochu s předstihem přinášíme titulky k devatenácté epizodě první série s názvem Spartan Figures. Titulky pro vás připravili Honzajs000, Valada06 a cev a můžete je stahovat zde. Prezident Dalton spolu s Elizabeth úspěšně dojednává strategii, jak řešit řecký dluh, když už se schyluje k podpisu, objeví se bývalý ministr financí Max Quinn, jenž s prezidentovou současnou politikou nesouhlasí\nPromo na S01E19\n15.6.2015 Valada06 Novinky\nJiž v neděli můžete očekávat titulky k devatenácté epizodě první série s názvem Spartan Figures. V této epizodě se mimo jiné bude řešit velmi aktuální téma – řecký dluh. Řekové nejdřív kývnou Daltonovi a Elizabeth na dohodu, ale později se začnou cukat. Do konce série zbývají tak už pouhé tři epizody. Zůstaňte tedy s námi a navštěvujte náš web


Výběr vhodné metodiky vývoje softwaru pro společnost HOUR, spol. s r.o. - PDF\nDownload "Výběr vhodné metodiky vývoje softwaru pro společnost HOUR, spol. s r.o."\n1 Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Vyšší odborná škola informačních služeb v Praze Simona Dlugošová Výběr vhodné metodiky vývoje softwaru pro společnost HOUR, spol. s r.o. Bakalářská práce 2012\n3 Prohlášení Prohlašuji, že jsem bakalářskou práci na téma Výběr vhodné metodiky vývoje softwaru pro společnost HOUR, spol. s r.o. zpracovala samostatně a použila pouze zdrojů, které cituji a uvádím v seznamu použité literatury. V Praze dne 21. května Simona Dlugošová\n4 Poděkování Ráda bych poděkovala paní PhDr. Heleně Kučerové, za ochotu, trpělivost, věcné připomínky a cenné rady při zpracování této bakalářské práce. Dále děkuji panu Ing. Romanu Dufkovi, zaměstnanci spolčenosti HOUR, spol. s r.o. za odborné konzultace.\n5 Abstrakt Tématem této bakalářské práce je Výběr vhodné metodiky vývoje softwaru pro společnost Hour, spol. s r.o.. Hlavním úkolem práce je porovnání níže uvedených metodik za využití systému hodnocení a výběru metodik budování IS/ICT METES (Methodology Evaluation System), nalézt vhodnou metodiku pro vývoj softwaru pro plánovaný projekt Humanet. V rámci této bakalářské práce jsou porovnávány jak metodiky zaměřené na rigorózní vývoj, tak metodiky agilní. Mezi rigorózní metodiky jsou zařazeny Rational Unified Process (RUP) a Microsoft Solution Framework for CMMI Process Improvement (MSF CMMI), mezi agilní metodiky pak OpenUP, Scrum, Extrémní programování (XP) a Feature-Driven Development (FDD). Porovnání je provedeno na základě vymezených kritérií metodou METES. Pro stanovení důležitosti jednotlivých kritérií je použita Saatyho vícekriteriální metoda párového srovnávání. Na základě porovnání všech kritérií daných metodik a kritérií stanovených pro projekt Humanet, je navržena metodika, která nejlépe splňuje požadavky na něj kladené. Klíčová slova metodika, RUP, XP, FDD, Scrum, MSF, METES\n6 Abstract The topic of this bachelor thesis is The choice of the right software developing method for the company Hour, spol. s r. o.. The main part of the work is comparing of lower introduced methods with use of system of classification and pick the right method of building IS/ICT METES (Methodology Evaluation System), find the right method for developing the software already planned project Humanet. Within the frame of this thesis are compared methods focusing on regional development and also agile methods. Into rigorous methods are classed Rational Unified Process (RUP) a Microsoft Solution Framework for CMMI Process Improvement (MSF CMMI), into agile methods are classed OpenUp, Scrum, Extreme programming (XP) and FeatureDriven Development (FDD). The comparison is accomplished based on delineated criteria by method METES. For importance setting of each criterion is used Saaty s multicriteria method binate comparison. Based on the comparison of all criteria concrete methods and criterion for project Humanet is designed a method that fulfil most of asked requirement.\n7 Obsah 1 Úvod Cíl práce Hypotéza Metodologie práce Porovnání rigorózních a agilních metodik Rigorózní metodiky Agilní metodiky Porovnání rigorózních a agilních metodik Systém hodnocení a výběru metodik METES Charakteristika METES Způsob hodnocení kritérií Kritéria skupiny Produkt Důležitost produktu Délka projektu Stálost požadavků Znovupoužitelnost Velikost řešení Kritéria skupiny Lidé Zkušenost manažera projektu Kvalifikace členů týmů Motivace členů týmu Dostupnost uživatelů Velikost týmu Rozmístění Charakteristika projektu Vývoj softwarových aplikací ve společnosti HOUR, spol. s r.o Projekt Humanet\n8 5 Výběr vhodné metodiky Stanovení vah pro skupiny Produkt a Lidé Stanovení hodnot kritérií skupiny Produkt pro projekt Humanet Stanovení hodnot kritérií skupiny Lidé pro projekt Humanet Posouzení použitelnosti vybraných metodik Metodika Rational Unified Process (RUP) Charakteristika RUP Hodnocení kritérií skupin Produkt a Lidé Posouzení použitelnosti RUP pro projekt Humanet Metodika Microsoft Solution Framework (MSF) Charakteristika metodiky Hodnocení kritérií skupin Produkt a Lidé Posouzení použitelnosti metodiky MSF CMMI pro projekt Humanet Metodika OpenUP Charakteristika metodiky Hodnocení kritérií skupin Produkt a Lidé Posouzení použitelnosti metodiky OpenUP pro projekt Humanet Metodika Feature Driven Development (FDD) Charakteristika metodiky Hodnocení kritérií skupin Produkt a Lidé Posouzení použitelnosti metodiky FDD pro projekt Humanet Metodika Scrum Charakteristika metodiky Hodnocení skupin Produkt a Lidé Posouzení metodiky Scrum pro projekt Humanet Metodika Extrémní programování (XP) Charakteristika metodiky Hodnocení kritérií skupin Produkt a Lidé\n9 6.6.3 Posouzení metodiky XP pro projekt Humanet Závěr Seznamy a přílohy Seznam použité literatury Seznam obrázků Seznam grafů Seznam tabulek Přílohy\n10 1 Úvod 1.1 Cíl práce Hlavním cílem práce je provést výběr vhodné metodiky vývoje softwaru pro společnost HOUR, spol. s r.o. Potřebná analýza nejrozšířenějších rigorózních a agilních metodik je provedena na základě vícekriteriálního systému hodnocení a výběru metodik METES (Methodology Evaluation System). Společnost v současné době provádí veškerý vývoj softwaru na definované vnitropodnikové směrnici. Cílem analýzy metodik pomocí METES je nalézt co nejvhodnější metodiku vývoje pro plánovaný projekt Humanet. 1.2 Hypotéza Hlavním předpokladem je výběr některé z dnes velice rozšířených a oblíbených agilních metodik, konkrétně metodiky Scrum. Ta dokáže velice rychle reagovat na možné změny, které v rámci vývoje mohou vznikat. Předpokladem pro její zavedení je také vysoká odborná kvalifikace, jak manažera projektu, tak členů týmu, veškeré tyto podmínky plánovaný projekt splňuje. Navíc je zde také možnost podpory této metodiky pomocí nástrojů Visual Studio Team System, který je ve společnosti již pro podporu využíván. 1.3 Metodologie práce V úvodu práce jsem obecně charakterizovala rigorózní a agilní metodiky. Jsou zde definovány zásady, kterými se řídí a jaké jsou mezi nimi rozdíly. V další kapitole je charakterizován sám systém METES, jeho základní principy podle kterých pracuje a ze kterých vychází. Uvádím zde kritéria podle kterých jsou jak jednotlivé metodiky, tak projekt hodnoceny a také způsob jejich hodnocení. Čtvrtá kapitola je věnována samotnému současnému popisu vývoje softwarových aplikací ve společnosti Hour a základní charakteristice projektu Humanet. V následující kapitole se věnuji samotnému postupu výběru vhodné metodiky. V kapitole číslo šest jsou postupně charakterizovány všechny posuzované metodiky a zároveň je provedeno jejich hodnocení použitelností ve vztahu k projektu Humanet. Na závěr jsou tyto výsledky zanalyzovány a je vybrána metodika, která co nejvíce splňuje předpoklady a požadavky definované projektem. 10\n11 2 Porovnání rigorózních a agilních metodik Metodiky pro vývoj informačních systému se dají dělit různými způsoby. Nejčastější z nich je ale rozdělení do dvou základních kategorií a to na rigorózní a agilní. Obě tyto kategorie mají mnoho svých zástupců, které lze pro vývoj softwaru použít. Každý z těchto přístupů je však vhodný pro různé projekty a to v souvislosti rozdílných předpokladů pro zavedení, oblasti použití, jejich velikostí, stálostí požadavků apod. 2.1 Rigorózní metodiky Základním předpokladem rigorózních metodik, které bývají velice často také označovány jako těžké metodiky, je striktně propracovaný popiš řízení a plánování vývoje softwaru. Tyto metodiky přesně definují posloupnost činností, které musí být při vývoji uskutečněny. Jedná se o metodiky opírající se o velmi podrobnou dokumentaci a o to že, veškeré požadavky na software lze určit předem. Většina metodik spadajících do této kategorie se odvíjí z vodopádového modelu životního cyklu, který je zobrazen na obrázku č.2-1: Vodopádový model životního cyklu.  Obrázek 1-1 Vodopádový model životního cyklu Tento model životního cyklu je definován sedmi základními kroky neboli fázemi, kterými vývoj prochází. Nejprve jsou specifikovány požadavky na systém a software, dále je provedena podrobná analýza a následný návrh programu. Ten je pak implementován, testován a uveden do provozu. Základním rysem tohoto modelu je podmínka, že vstup z jedné fáze do druhé je možný, pouze pokud je fáze předcházející zcela dokončena.  11\n12 Jak je tedy zřejmé rigorózní metodiky není vhodné používat pro vývoj softwaru u projektů, u kterých se předpokládá během jeho vývoje poměrně velké množství změn, které by mohly nastat. To by mohlo vést k velice zdlouhavému a složitému procesu. Některé rigorózní metodiky jsou dnes již realizovány také iterativním, jednotlivé fáze vývoje jsou prováděny opakovaně, či inkrementálním způsobem, vývoj je prováděn na základě přírůstků. Mezi těžké metodiky lze zařadit postupy posuzování softwarových procesů podle Capability Maturity Model Integration (CMMI) Integrační model zralosti, nebo normu ISO/IEC a to z toho důvodu, že pohlížejí na procesy budování informačních systémů jako na definované procesy. [6, s. 64] Mezi nejznámější zástupce rigorózních metodik však patří Rational Unified Process (RUP), který je také kromě metodiky Microsoft Solution Framework for CMMI Process Improvement jednou z posuzovaných metodik pro projekt Humanet. 2.2 Agilní metodiky S vyvíjejícími se technologiemi a nástroji přestali být některé z rigorózních metodik použitelné. Rigorózní pojetí vývoje se díky předdefinovaným pravidlům nedokáže tak rychle přizpůsobovat narůstajícím a často se měnícím požadavkům zákazníků, jejich přirozeností je se jim bránit. K selhávání těžkých metodik také ve velkém přispívá jejich náročnost na modelování, vznik velkého množství nepotřebných meziproduktů, či nepřizpůsobivost změnám v kvalitativním způsobu vývoje. To dalo vzniknout novým metodikám vývoje, jedná se o tzv. agilní, neboli lehké metodiky. Jedná se o metodiky, které jsou iterativní. Což znamená, že jsou založeny na opakujících se procesech. Dokážou se přizpůsobovat změnám požadavků, snaží se o co nejrychlejší vývoj softwaru a kladou velký důraz na přímou komunikaci. Vývoj a postupné prosazování těchto metodik dal vzniknout v roce 2001 Manifestu agilního vývoje (Agile Manifesto), ten vymezuje čtyři základní pravidla agilních metodik a dalších 12 principů, podle kterých se řídí. Základní pravidla upřednostňují: individualitu a komunikaci před procesy a nástroji fungující software před vyčerpávající dokumentací spolupráci se zákazníkem před vyjednáváním o smluvních podmínkách reakce na změny před striktním dodržováním plánu  12\n13 Dvanáct principů agilních metodik:  Hlavní prioritou je vyhovět zákazníkovi za pomoci včasných a průběžných dodávek softwaru. Jsou vítány změny v požadavcích a to i v pozdějších fázích vývoje. Agilní procesy podporují změny, které by mohly vést ke zvýšení konkurenceschopnosti zákazníka. Fungující software je dodáván v pravidelných, krátkých časových úsecích několika týdnů, měsíců, popřípadě kratších. Lidé z byznysu i vývojáři musí denně spolupracovat a to po celou dobu projektu. Projekty jsou budovány motivovanými jedinci. Je jim poskytnuto takové pracovní prostředí a podpora, jakou potřebují. Zároveň je v ně kladena důvěra, za odvedení kvalitní práce. Nejúčinnější a nejefektivnější sdělování informací při vývoji je formou osobní komunikace. Hlavní mírou pokroku je fungující software. Agilní procesy podporují udržitelný vývoj. Sponzoři, vývojáři i uživatelé by měli být schopni udržovat spolu krok po neomezenou dobu. Agilní přístup je posilován za pomoci neustálého věnování pozornosti technické kvality a dobrým návrhem. Jednoduchost umění maximalizovat množství práce, která nemusí být provedena je základem. Nejlepší architektury, požadavky a návrhy vznikají v samostatně se organizujících týmech. Tým pravidelně uvažuje nad tím, jak být efektivnějším, na základě toho vylepší své postupy a přizpůsobí i své chování. Mezi nejznámější zástupce agilního přístupu patří metodiky Feature-Driven Development, Scrum, Extrémní programování a OpenUP. Všechny tyto uvedené metodiky jsou dále charakterizovány a hodnoceny ve vztahu k projektu Humanet. 2.3 Porovnání rigorózních a agilních metodik V tabulce 2-1 Porovnání rigorózních a agilních metodik je vybráno sedm základních rozdílů, které mezi těmito dvěma kategoriemi jsou. Jsou vybírané z přehledu, který uvádí Ph.D. Alena Buchalcevová ve své knize Metodiky budování informačních systémů. [6, s ] 13\n14 Posuzované hledisko změny rozsah řešení způsob řízení forma komunikace dokumentace způsob vývoje zákazník Rigorózní metodiky Agilní metodiky snaha minimalizace jsou vítány, možnost přehodnocování požadavků snaha zabudování budoucích pouze požadované funkce, požadavků požadavek minimalizace na základě nedůvěry, direktivní vůdcovství a spolupráce, je řízení a kontroly formováno na důvěře a respektu převážně písemná důraz na komunikaci tváří v tvář rozsáhlá dokumentace podstatná není dokumentace, ale pochopení píše vodopádový, případně přírůstkový vývoj s velmi krátkými iterativní, přírůstkový s dlouhými iteracemi iteracemi podílí se na projektu jeho přesun nositele řízení z týmu na v začátcích a na konci; zákazníka, je řídícím subjektem, zaměření vývoje je orientováno průběžně může měnit priority; více na jednotlivé procesy, než na nejvyšší prioritou je spokojenost výsledky pro zákazníka zákazníka Tabulka 1-1 Porovnání rigorózních a agilních metodik Cílem agilních metodik je v co nejrychlejším možném čase vytvořit produkt, který bude plně splňovat zákazníkovi požadavky. Agilní přístup je postaven na flexibilním a rychlém přizpůsobování změnám v požadavcích, které zákazník uvádí. Proto se předpokládá, že je zadavatel přímo součástí týmu vývojářů, nebo je alespoň k dispozici kdykoliv je zapotřebí. Díky tomu je na něj převáděna jistá míra zodpovědnosti. Pro agilní metodiky je také vhodnější práce v menších týmech přibližně do deseti vývojářů, využívány jsou jejich individuální znalosti a je tak také usnadněna přímá komunikace mezi jednotlivými členy. V současné době se ale jen velice těžko některé z předpokládaných postupů pro agilní vývoj dodržují, například každodenní přítomnost zákazníka je v řadě projektů přímo nemožná. Právě díky tomu, že se vývoj software řadí mezi rychle vyvíjející se odvětví, dochází tak i k přizpůsobování jednotlivých směrů pro vývoj metodik. Agilní přístupy se začínají v některých směrech formalizovat tak, aby bylo možné je použít i při větších projektech, které původně vůbec neodpovídají možnosti použití těchto 14\n15 metodik. Často tak můžeme slyšet o možnosti kombinací těchto lehkých metodik s metodikami těžkými. U rigorózních metodik pak naopak dochází k jejich odlehčování. 3 Systém hodnocení a výběru metodik METES Pro výběr správné metodiky vývoje softwaru, kterou by bylo vhodné aplikovat na konkrétní projekt, je mnoho různých cest, jak docílit potřebného řešení. Jednou z nich je i Systém pro hodnocení a výběr metodik budování IS/ICT METES (Methodology Evaluation System). Ten byl navržen paní doc. Ing. Alenou Buchalcevovou, Ph. D., která působí jako vedoucí sekce softwarového inženýrství na katedře informačních technologií Vysoké školy ekonomické v Praze. METES vychází převážně ze systému hodnocení a výběru metodik navrženého Davidem Heckselem. Původní Heckselův systém hodnocení obsahuje 62 atributů rozdělených do čtyř skupin, z toho 51 z nich je součástí tzv. Projektového kontextu, který je rozdělen do tří skupin - Lidé, Proces a Technologie, ty charakterizují daný projekt. Zbývajících 11 atributů je definováno jako kořenových. Na základě stanovení hodnot všech atributů je pak navržen Projektový model, který je dále porovnán s Modely metodik.  I přes velký počet atributů tento systém však už nezohledňuje kritéria, jako jsou lokalizace metodiky, její dostupnost, kvalifikace lidí apod., METES je tedy založen na základní struktuře Heckselova systému a doplněn o novou strukturu kritérií, jejichž počet je sice podstatně menší, ale některá z nich bývají často opomíjena i přes to, že mohou hrát při výběru významnou roli. 3.1 Charakteristika METES Systém spočívá převážně v hodnocení kritérií, která jsou rozdělena do čtyř základních skupin Produkt, Lidé, Proces a Podpora. Klíčová kritéria pro posuzování metodiky jsou obsažena ve skupinách Produkt a Lidé, ta hodnotí základní charakteristiky vyvíjeného produktu a lidí, kteří se na jeho tvorbě podílí. Kritéria skupin Proces a Podpora jsou pak dále zaměřena na zhodnocení procesů dané metodiky. Pro systém METES jsou ohodnocovány v současné době nejrozšířenější metodiky pro vývoj softwaru a to Rational Unified Process (RUP), OpenUP, Feature Driven Development (FDD), Scrum, Extreme Programming (XP) a Microsoft Solution Framework, konkrétně metodika CMMI Proces Improvement (MSF CMMI). Celá struktura hodnocení systému dle Ph. D. Aleny Buchalcevové je zobrazena na obrázku 3-1: Struktura systému hodnocení metodik METES. 15\n16 Obrázek 1-2Struktura systému hodnocení metodik METES [6, s. 95] 3.2 Způsob hodnocení kritérií Všechna kritéria jsou hodnocena pomocí číselné stupnice od nuly do pěti. Čím nižší hodnotou je kritérium ohodnoceno, tím menší je stupeň jeho splnění a naopak. Pro každé kritérium je konkrétně specifikována stupnice, kde je každý její bod detailněji popsán. U kritérií spadajících do skupin Produkt a Lidé jsou pro posuzování metodiky ještě definovány minimální, maximální a optimální hodnoty. Ty určují rozsah, podle kterého se usuzuje, zda je metodika ve vztahu k danému projektu použitelná. Uvedená kritéria stanovená pro porovnání jsou vymezena tak, jak je stanovila Ph.D. Alena Buchalcevová ve své knize Metodiky budování informačních systému, kde je podrobně popsán celý systém pro výběr vhodné metodiky na základě systému METES. Hodnocení kritérií základních skupin Produkt a Lidé je uvedeno v kapitolách 3.3 a 3.4. Doplňková kritéria, včetně stupnice ohodnocení jsou pak k nahlédnutí v příloze č.1 Doplňková kritéria skupin Proces a Podpora, a to z toho důvodu, že ne vždy je nezbytně nutné provádět jejich analýzu. Systém METES je modelem vícekriteriální analýzy variant a využívá pro hodnocení váhy kritérií. Váha kritéria je hodnota z intervalu <0,1>, která vyjadřuje relativní důležitost tohoto kritéria v porovnání s kritérii ostatními.[6, s. 114] K jednotlivým kritériím jsou tedy stanoveny váhy důležitosti, ty jsou pak dále využívány pro určení vážených absolutních hodnot vzdáleností od optimálních hodnot každé z hodnocených metodik. 16\n17 3.3 Kritéria skupiny Produkt Jak je již patrné z názvu skupiny, kritéria, která tato skupina obsahuje, mají za účel ohodnotit produkt, který bude vytvářen. V případě společnosti HOUR, spol. s r.o. se jedná o vývoj nových modulů. Jde zde o stanovení základní charakteristiky produktu - velikost, důležitost, požadavky Důležitost produktu První z klíčových kritérií rozlišující druh a důležitost produktu má za úkol sledovat především vliv systému z hlediska jeho poslání. Důležitým ukazatelem zde jsou také jeho možné negativní dopady v případě jeho nefunkčnosti. Hodnocení produktu je spjato s řízením kvality a formálností metodiky. Stupnice hodnocení: 0 jen pilotní projekt 1 doplňkový systém 2 systém podporující fungování organizace 3 systém kritický pro poslání (národní organizace) 4 systém kritický pro poslání (nadnárodní organizace) 5 systém, na kterém závisí životy lidí Délka projektu Toto kritérium má za úkol ohodnotit časový úsek, který je vymezen na základě počtu měsíců, po které se předpokládá, že bude projekt vytvářen. Vzhledem k závislosti společností na rychlosti vývoje a následného nasazení svých produktů vůči rozvíjející se konkurenci na trhu, je toto kritérium zařazeno opět mezi klíčové. Stupnice hodnocení: 0 do 1 měsíce 1 do 3 měsíců 2 do 6 měsíců 3 do 12 měsíců 4 do 24 měsíců 5 nad 24 měsíců Stálost požadavků Hraje významnou roli pro rozhodování mezi agilními a rigorózními metodikami. Definuje, zda před zahájením projektu možné předem pevně stanovit veškeré požadavky na něj a v jaké míře se dají obměňovat i v průběhu samotného vývoje 17\n18 Stupnice hodnocení: 0 požadavky není předem možné detailně stanovit 1 požadavky se více než z 50% mění 2 procento změn požadavků je cca 30% 3 požadavky lze definovat předem, mění se jen priority požadavků 4 požadavky lze definovat předem, mění se, ale snahou je změny potlačovat 5 požadavky lze definovat předem a nemění se Znovupoužitelnost Kritérium hodnotí požadavky na tvorbu prvků, které se budou moci dále používat nejen v rámci jednoho konkrétního projektu, ale i dalších různých, které firma plánuje. Na základě toho se pak dále rozlišuje, zda jsou vytvořené třídy těchto prvků používány pouze v jednom programovém prostředí, nebo je možno je aplikovat v programových prostředích různého charakteru. Toto kritérium opět hraje roli při výběru typu metodiky, znovupoužitelnost prvků je vyžadována především u metodik rigorózních, zatímco agilní se zaměřují na daný konkrétní problém a nezabývají se jejich budoucím využitím. Stupnice hodnocení: 0 cílem není znovupoužitelnost 1 snaha používat již hotové komponenty 2 snaha vytvářet znovupoužitelné třídy v rámci projektu 3 snaha vytvářet znovupoužitelné spustitelné komponenty v rámci projektu 4 snaha vytvářet znovupoužitelné spustitelné komponenty v rámci organizace 5 cílem je maximální znovupoužitelnost v rámci organizace Velikost řešení Pro posouzení tohoto kritéria bylo navrženo mnoho různých způsobů, prostřednictvím kterých se snažili jejich autoři vyjádřit velikost vytvářeného softwaru číselnou hodnotou. Metodika METES určuje velikost řešení na základě počtu případů užití, ten specifikuje strukturu systému z pohledu uživatele. Jedná se o další z kritérií ovlivňujících volbu mezi agilním a rigorózním vývojem. Stupnice hodnocení: 0 1 až až až až\n19 4 201 až a více 3.4 Kritéria skupiny Lidé Skupina zahrnuje kritéria, která mají za úkol blíže charakterizovat tým lidí, kteří se na vývoji systému podílí. Zaměřuje se převážně na zkušenosti členů týmu, jejich kvalifikaci, velikost a rozmístění Zkušenost manažera projektu Zkušenosti manažera projektu hrají velikou roli při samotném vývoji, jelikož se jedná o vedoucího celého týmu, je od něj závislých mnoho faktorů, které projekt ovlivňují a ve velkém na něm tak závisí i samotný úspěch projektu. Zkušenosti manažera jsou ohodnocovány z hlediska počtu let, ve kterých zastává tuto svou funkci. Stupnice hodnocení: 0 5 a více 1 4 až 5 let 2 3 až 4 roky 3 2 až 3 roky 4 1 až 2 roky 5 0 až 1 rok Kvalifikace členů týmů Předmětem hodnocení jsou zkušenosti a dovednosti jednotlivých členů týmů, tedy vyjma manažera. Je nutné, aby metodika pro vývoj softwaru byla přizpůsobena kvalifikaci členům týmu, např. pro agilní vývoj je nezbytné, aby byl tým sestaven z jedinců, kteří mají široké zaměření a neprošli jen úzkou specializací v oboru. Stupnice hodnocení: 0 více než 70% členů týmu je kvalifikovaných s širokým zaměřením 1 více než 70% členů týmu je kvalifikovaných, ale specializovaných 2 cca 50% členů týmu je málo kvalifikovaných 3 více než 60% členů týmu je málo kvalifikovaných 4 více než 70% členů týmu je málo kvalifikovaných 5 více než 80% členů týmu je málo kvalifikovaných 19\n20 3.4.3 Motivace členů týmu Kritérium se zabývá charakterovými vlastnostmi členů týmů z hlediska jejich morálních hodnot. Posuzováno je na základě míry motivace většiny členů, opět kromě manažera. U některých metodik je totiž vyžadováno, aby se členové organizovali sami. V těchto případech je více než nutné, aby byla splněna podmínka vysokých morálních hodnot jedinců tvořících tým. Stupnice hodnocení: 0 motivovaní jedinci vysokých morálních kvalit, sdílí znalosti, sami se organizují 1 aktivní, motivovaní jedinci, sdílí znalosti 2 plní zadané úkoly, sdílí znalosti 3 plní zadané úkoly, nesdílí znalosti 4 jedinci jsou špatně motivováni a snaží se vyhýbat úkolům, nesdílí znalosti 5 žádná motivace Dostupnost uživatelů Kritérium uvádějící jak moc je sám zákazník zapojen do projektu, což je spjato i s kritériem hodnotícím stálost požadavků. V případě, že je vyvíjen software, kde dochází k častým změnám, které jsou kladeny na jeho požadavky, by měl být zákazník pro řešitele, co nejvíce dostupný. U agilních metodik je téměř vyžadována jeho denní účast. Dostupnost uživatelů je třetím klíčovým kritériem, na kterém je závislá použitelnost vybíraných metodik. Stupnice hodnocení: 0 uživatel je součástí týmu, má odpovědnost za požadavky 1 uživatel je k dispozici denně 2 uživatel je k dispozici kdykoliv na vyžádání 3 uživatel je k dispozici na začátku, konci a v průběhu projektu, v předem určených milnících 4 uživatel je k dispozici jen na začátku a na konci projektu 5 uživatel není dostupný Velikost týmu Jednou z nejdůležitějších činností při práci na projektu je komunikace mezi členy týmu, kterou musí daná metodika řídit. Opět se tedy jedná o další z klíčových kritérií. Velikost týmu zahrnuje veškeré osoby podílející se ať už více, nebo méně na uskutečnění celé tvorby projektu a to včetně projektového manažera. 20\n21 Stupnice hodnocení: 0 1 až až až až až více než Rozmístění Zhodnocení rozmístění členů týmu. Poslední klíčové kritérium, na kterém vysoce závisí výběr metodiky. Některé z nich totiž vyžadují přímou, neboli osobní formu komunikace. Např. pro použití agilní metodiky pro vývoj softwaru se přímo předpokládá osobní forma komunikace. Vzhledem k velikosti týmu však není možné vždy těmto požadavkům dostát, proto se i tyto metodiky začaly v současnosti přizpůsobovat tak, aby mohl být použit i pro větší týmy. Stupnice hodnocení: 0 v jedné místnosti 1 v jedné budově 2 více míst v jednom městě 3 dvě místa v jedné zemi 4 více míst v jedné zemi 4 Charakteristika projektu 4.1 Vývoj softwarových aplikací ve společnosti HOUR, spol. s r.o. V současné době jsou ve firmě HOUR, spol. s r.o. veškeré procesy pro vývoj softwarových aplikací prováděny na základě vnitropodnikové směrnice. Ta definuje procesy, jako jsou: specifikace a sběr požadavků na vývoj SW, posouzení požadavků, prozkoumání požadavků, analýza, objednávka, realizace navrhovaného řešení, testování, 21\n22 ukončení vývoje, tvorba uživatelské dokumentace, implementace SW. Pro lepší sledování a řízení celého cyklu vývoje softwarových aplikací, je používáno vývojové prostředí Visual Studio 2010 s propojením na Team Foundation Server (TFS) společnosti Microsoft. To umožňuje udržovat zdrojový kód, správu testů a údaje o jednotlivých částech projektu na jednom místě za pomoci centrálního úložiště. Díky čemuž je i zjednodušena a zefektivněna komunikace jednotlivých týmů pracujících na vývoji. Team Foundation Server také zastřešuje nástroje pro reporting, které podávají detailní přehled o stavu projektu v reálném čase, dovolují plánování posloupnosti zpracovávání požadavků, správu projektů i portfolia. V tomto vývojovém prostředí lze zavést nástroje potřebné pro metodiky agilního vývoje softwaru.  Podrobnější popis činností a celkového vývoje softwarových aplikací společností HOUR, spol s r.o. je zachycen ve vývojovém diagramu, v příloze č.2 Vývojový diagram softwarových aplikací. 4.2 Projekt Humanet Společnost plánuje v časovém rozmezí dvanácti měsíců rozšířit nabídku jednoho ze stávajících produktů a to ekonomického a HR informačního systému Humanet. Informační systém Humanet je nabízen jako SaaS, který plně zastřešuje potřeby vedení a zpracování personální a účetní agendy s důrazem na řízení lidských zdrojů. Hlavní výhodou tohoto systému je, že je určen převážně pro nasazení v prostředí intranetu, internetu a mobilních zařízení. Systém je vybudován nad originální infrastrukturou společnosti HOUR, spol. s r.o. Jedná se o tzv. Network Application Framework. Tato infrastruktura se skládá z několika částí, které navzájem spolupracují a komunikují prostřednictvím TCP/IP protokolu. Prostřednictvím takto strukturovaného jádra aplikace je možné vytvářet aplikace ERP charakteru. Celá infrastruktura je vybudována nad technologií.net Framework společnosti Microsoft.  Vzhledem k vysoké poptávce po produktu a také díky stále vyšším nárokům uživatelů bude stávající systém rozšířen o tyto tři nové moduly: Časový manažer, který má za úkol správu docházky zaměstnanců v reálném čase (odpracovaná doba, čerpání dovolené, služební cesty, přerušení pracovní 22\n23 doby). Díky parametričnosti modulu, by mělo být možné jeho obsah přizpůsobovat na základě potřeb jednotlivých zákazníků. Dalším z požadavků na modul je podpora různých typů databází, jako jsou např. MySQL, Oracle, nebo Informix. Časový manažer bude propojen na již dnes velmi využívané snímače čipových karet a jeho správa zjednodušena i díky přístupnosti k němu přes webovou aplikaci. [11, s. 8-11] Příprava zaměstnanců, cílem modulu je zjednodušení řízení lidských zdrojů z hlediska jejich vzdělávání, správy, evidence a kontroly. Správa modulu je plánována na základě katalogového systému zadávání. Katalog je datový formulář, ve kterém jsou uvedeny veškeré vzdělávací aktivity. Na základě spolupráce společností Hour, spol. s r.o. a eduacation.sk, bude mít uživatel možnost vložení nabídek ve vzdělávacích službách, které jsou na portálu education.sk vedeny. Každému uživateli je v katalogu vytvářeno portfolio. Veškeré vzdělávací aktivity, ať se jedná o povinná školení či nepovinné vzdělávací kurzy, budou pro přehlednost vedeny v kalendáři, kde je možné je různě filtrovat právě na základě jejich důležitosti a druhu, ale i stavu v jakém se právě nachází (uskutečněné, probíhající, plánované). [11, s. 3-5] Controlling je modul, který slouží manažerům k usnadnění a koordinaci chodu společnosti. Modul má zastřešit takové zpracovávání dat, aby byl schopen poskytnout potřebné výstupy a to v podobě různých sestav grafů a tabulek. Všechny nástroje obsažené v modulu slouží k vylepšování firemních výsledků. Jedná se např. o nástroje pro reporting za jehož pomoci je možné sledování potřebných ukazatelů nejen v čase. Controlling má dále za cíl usnadnit tvorbu kalkulací a možných operativních analýz, to vše pro usnadnění sledování plánů podniku a případného odstraňování potencionálních rizik. [11, s ] 5 Výběr vhodné metodiky Pro výběr vhodné metodiky je vždy stanoven určitý postup. V případě systému hodnocení metodik METES jsou nejprve stanoveny váhy hodnocení pro kritéria základních skupin Produkt a Lidé, dále jsou kritéria těchto dvou skupin posuzována prostřednictvím definovaných stupnic hodnocení, které jsou podrobněji popsány v kapitolách č. 3.3 a 3.4 kritéria skupin Produkt a Lidé, a to ve vztahu k určitému projektu. Výsledkem jsou pak hodnoty, které má daný projekt splňovat. 23\n24 Dalším krokem je výběr metodik, které by bylo možno pro uskutečnění určitého projektu aplikovat. Velice důležitou roli při výběru hrají právě tato vybraná klíčová kritéria Důležitost produktu, Délka projektu, Dostupnost uživatelů, Velikost týmu a Rozmístění. Metodiky použitelné pro projekt jsou ty, jejichž klíčová kritéria projektu se nachází v intervalech vymezených jejich minimem a maximem. V případě, že výsledkem je větší množství než jedna použitelná metodika, jsou dále podrobněji analyzovány prostřednictvím výpočtu odchylek hodnot klíčových kritérií od optimálních hodnot posuzovaných metodik. Poté jsou stanoveny váhy doplňkových kritérií skupin Proces a Podpora a následně i posouzeny. [6, s. 117] V opačném případě, kdy všechny z posuzovaných metodik přesahují stanovené intervaly a nejsou tak vhodné pro použití v projektu, dochází k podrobné analýze kritérií, jejichž hodnoty se do stanovených intervalů nevešly a následně je vybrána metodika, jejíž překročení má co nejmenší dopad na daný projekt. Může však také nastat situace, že není vybrána žádná z hodnocených metodik. [6, s. 118] Celý postup výběru vhodné metodiky je znázorněn níže na obrázku 5-1 Konceptuálním modelu diagramu tříd. Obrázek 1-3 Konceptuální model výběru metodiky pro projekt [6, str. 97] 24\n25 5.1 Stanovení vah pro skupiny Produkt a Lidé Pro jasné vyjádření důležitosti jednotlivých kritérií jsou stanovovány hodnoty jejich vah. Čím vyšší hodnotu váhy kritérium má, tím je pro daný projekt důležitější. Posouzení důležitosti jednotlivých kritérií je možno provést dvěma způsoby a to buď za použití již stanovených vah, tak jak je přisoudila jednotlivým kritériím autorka metodiky METES, nebo je možno si stanovit váhy vlastní a to v závislosti na požadavcích a preferencích pro konkrétní projekt. Stanovení vah je možno provést na základě mnoha metod, které se používají právě pro vícekriteriální rozhodování. Mezi nejčastější z nich patří např. Fullerova, Bodovací či Saatyho metoda. Pro projekt Humanet jsem se rozhodla pro stanovení vah jemu odpovídajících a to za pomoci Saatyho kvantitativní metody párového srovnávání. Předpokladem této metody je, že jsou jednotlivé váhy posuzovány přímo na základě znalostí nějakého experta. Expertní zhodnocení, v případě projektu Humanet je provedeno Ing. Romanem Dufkem, vedoucím manažerem projektu. Je založeno na párovém porovnávání vybraných kritérií a určení preferencí. Pro zhodnocení páru kritérií se používá devíti bodová stupnice: 1 kritériím i a j je přisuzována stejná důležitost, jsou rovnocenná 3 slabě preferované kritérium i před j 5 silně preferované kritérium i před j 7 výrazně preferované kritérium i před j 9 absolutně preferované kritérium i před j  Body 2 (velmi slabě preferované kritérium i před j), 4 (mírně silně preferované kritérium i před j), 6 (velmi silně preferované kritérium i před j) a 8 (velmi výrazně preferované kritérium i před j) mohou být využity jako mezistupně pro přesnější zhodnocení, většinou se však nevyužívají. [18, s. 4-5] Preferenční hodnoty, které přisuzuje expert při hodnocení jednotlivých párů kritérií, jsou zaznamenávány do tzv. Saatyho matice S = (s ij ). Jedná se o čtvercovou matici typu n x n, která má na hlavní diagonále samé jedničky, to z toho důvodu, že každé kritérium je samo sobě rovnocenné. Hodnocení párů kritérií je prováděno pomocí základní stupnice, tedy v případě, že je i-tému 25\n26 a j-tému kritériu přisuzována stejná důležitost zapíše se do matice hodnota s ij = 1, pokud je i-té kritérium slabě preferováno před j-tým, zapíše se hodnota s ij = 3 apod. Jelikož je Saatyho matice reciproční tzn., že obsahuje převrácené hodnoty s ji =, zapíší se v případě preferencí j-tého kritéria převrácené hodnoty, např. j-té kritérium je silně preferováno před i-tým, s ij = 1 / 5.  Z jednotlivých prvků matice jsou tak zřejmé odhady podílů vah i-tého a j-tého kritéria. Pro samostatný výpočet vah je možno použít řadu postupů, jak dojít k potřebným výsledkům. Pro posouzení vah projektu Humanet, je pro co nejpřesnější výsledky použit normalizovaný geometrický průměr řádků. Pro každé i jsou spočteny hodnoty [17, s. 9]: Výpočty vektorů s a r jsou použity jako mezikroky pro výpočet geometrického průměru řádků. Po jejich určení se dále vypočte celková hodnota vektoru r, která je potřebná pro výpočet samotných vah. Vektor v, zde tedy představuje normalizovaný vektor vah, z čehož vyplívá, že součet všech vah posuzovaných kritérií je roven jedné. [17, s. 9] Přiřazení vah pro projekt Humanet, provedené panem Ing. Romanem Dufkem je uvedeno v tabulce č. 5.1 Stanovení vah kritérií skupin Produkt a Lidé. Zhodnoceno je zde 11 základních kritérií. Nejprve byly určeny preference kritérií nacházejících se pod hlavní diagonálou, na základě čehož pak došlo k doplnění odpovídajících převrácených hodnot. Stanovení vah kritérií skupin Produkt a Lidé Důležitost produktu Délka projektu Stálost požadavků 26 Znovupoužitelnost Velikost řešení Zkušenosti manažera projektu Kvalifikace členů týmu Motivace členů týmu Dostupnost uživatelů Velikost týmu Důležitost produktu ,265 Délka projektu 1/ /3 0 0,109 Stálost požadavků 1/5 1/5 1 1/ /3 1/3 1/5 1/3 1/3 0,024 Znovupoužitelnost 1/5 1/ /3 1/3 1/5 0,053 Velikost řešení 1/3 1/3 1 1/ /3 0,064 Zkušenost manažera projektu 1/7 1/ / /3 1/5 1/5 1/7 0,026 Kvalifikace členů týmu 1/9 1/7 3 1/3 1/3 1/3 1 1/5 1/5 1/5 1/7 0,020 Motivace členů týmu 1/9 1/7 3 1/3 1/ /7 1/7 1/7 0,030 Dostupnost uživatelů 1/ ,146 Velikost týmu 1/ / /5 1 1/5 0,085 Rozmístění 1/ ,179 Tabulka 1-2 Stanovení vah kritérií Produkt a Lidé Rozmístění Váhy 1,000\n27 Jak je již z tabulky zřejmé nejvyšší váhy a tedy důležitost je přidělena právě pěti klíčovým projektovým kritériím - Důležitost produktu, Rozmístění, Dostupnost uživatelů, Délka projektu a Velikost týmů. Mezi další znatelněji preferovaná kritéria poté spadají ještě Velikost řešení a Znovupoužitelnost. Zbývajícím kritériím je přisuzována přibližně stejná výška vah a výše preferencí je mezi nimi tak minimální. 5.2 Stanovení hodnot kritérií skupiny Produkt pro projekt Humanet Jelikož je produkt Humanet softwarem, který podporuje fungování organizace, odpovídá jeho ohodnocení kritéria Důležitost produktu stupeň číslo 2. Délka realizace projektu je vymezena časovým úsekem 12 měsíců, hodnocení kritéria Délka projektu je tedy rovno 3. Veškeré požadavky na projekt Humanet jsou předem definovány, avšak v průběhu vývoje může docházet ke změnám jejich priorit. Kritérium Stálost požadavků je hodnoceno stupněm číslo 3. V rámci řešení projektu je snahou vytvářet znovupoužitelné třídy pouze v rámci jednoho programového prostředí, hodnota kritéria Znovupoužitelnost je dána stupněm číslo 2. Projekt Humanet spadá do skupiny projektů vývoje softwaru a to z toho důvodu, že využívá více než 300 případů užití, kritérium Velikost řešení tak odpovídá hodnocení číslem Stanovení hodnot kritérií skupiny Lidé pro projekt Humanet Manažer projektu působí ve své funkci již více než 5 let, hodnocení Zkušenosti manažera tak odpovídá stupni číslo 0. Co se týká kritéria Kvalifikace členů týmů, ten je sestaven z jedinců, jejichž většina je kvalifikovaná, ale zaměřená na určitou specializaci, což odpovídá ohodnocení kritéria stupněm číslo 1. Tým je sestaven z motivovaných jedinců, komunikativních jedinců, kritérium Motivace členů týmu, je tak přiřazeno číslo ohodnocení 1. Protože je systém Humanet vyvíjen jako produkt, který je až následně nabízen cílovým zákazníkům na základě jejich jednotlivých a konkrétních požadavcích, je možné jej dále upravovat. Není uživatel přímo dostupný v průběhu vývoje projektu. Kritérium Dostupnost uživatelů tak splňuje kategorii hodnocenou číslem 5. V týmu se nachází 10 lidí včetně manažera projektu, hodnocení kritéria Velikosti týmu je rovno číslu 1. Někteří z členů týmu však působí i v zahraničí, což má za následek, že kritérium Rozmístění je hodnoceno stupněm 5. Celkové zhodnocení kritérií skupin Produkt a Lidé, provedeno na základě výběru stupně ohodnocení je pro názornost uvedeno v tabulce 5-2 Hodnocení kritérií Produkt a Lidé. 27\n28 Kritérium Projekt Humanet Důležitost projektu 2 Délka projektu 3 Stálost požadavků 3 Znovupoužitelnost 2 Velikost řešení 5 Zkušenosti manažera projektu 0 Kvalifikace členů týmu 1 Motivace členů týmu 1 Dostupnost uživatelů 5 Velikost týmu 1 Rozmístění 5 Tabulka 0-1 Hodnocení kritérií skupin Produkt a Lidé pro projekt Humanet 6 Posouzení použitelnosti vybraných metodik V této kapitole jsou charakterizovány a analyzovány veškeré metodiky, které jsou v rámci METES definovány. 6.1 Metodika Rational Unified Process (RUP) Metodika Rational Unified Process byla představena společností Rational v roce 1995 jako Rational Objectory Process. Jedná se o nejznámější rigorózní metodiku vůbec, v současné době je však ve velkém rozšiřována o agilní praktiky. Svému uplatnění se těší především ve velkých softwarových společnostech, o čemž také svědčí to, že v roce 2002 byla pak odkoupena od firmy Rational společností IBM, která ji nadále rozvíjí Charakteristika RUP Většinou je jí stále, i přes možnosti používat ji jako agilní metodiku, přisuzován přívlastek těžké, detailně propracované, robustní metodiky. Tato metodika plně pokrývá většinu projektových i technických procesů, stejně tak jako procesy týkající se implementace softwaru a jeho podpory. Jedná se o silně objektově orientovanou metodiku, která je úzce spjata s modelovacím jazykem UML, ve kterém jsou vytvářeny veškeré modely a Use case (případy užití). Jejím kladem může být právě její propracovanost, takže každý z členů týmu ví vždy, co má kde, kdy a jak udělat. Původně byla spíše vhodná pro větší, složitější a důležitější projekty, na kterých se podílely velké týmy, avšak díky jejímu vývoji nyní tvoří rámec, který je možno použít 28\n29 i pro projekty s menší důležitosti, tvořené menším počtem vývojářů. Je také podporována různými nástroji a šablonami. Tato metodika využívá iterativní model životního cyklu softwaru. Proces vývoje softwaru je možné zobrazit ve dvou základních dimenzích, jak je znázorněno na obrázku 6-1 Fáze a disciplíny RUP. Obrázek 6-1 Fáze a disciplíny RUP  Horizontální osa představuje dynamický pohled na proces, který je vyjádřen pomocí cyklu, fází, iterací a milníků. Vertikální osa reprezentuje statické hledisko procesu, popis činností, artefaktů, pracovníků a pracovních toků. [6, s. 122] Celý životní cyklus vývoje softwaru je prováděn ve čtyřech fázích: [2, s. 24] Fáze počáteční či zahajovací (Inception), Fáze elaborační, či projektovací (Elaboration), Fáze konstrukční, či realizační (Construction) a Fáze nasazení, neboli fáze předání. Počáteční fáze zabírá přibližně 10% celkové doby vývoje softwaru. V této fázi jsou převážně definovány veškeré požadavky na software, postupy a nástroje, které budou při řešení projektu využívány. Na základě toho se i vytváří předběžný model a plánují se iterace, které u metodiky RUP mívají delší časový interval. Součástí plánování je i hrubý odhad nákladů a také analýza možných rizik, které při vývoji mohou nastat. Celá zahajovací fáze nakonec závisí na tom, zda je možné projekt za daných požadavků, zdrojů a dostupných technologií realizovat. Po dokončení fáze první se vytváří návrh realizace, architektura celého projektu a vytváří se detailnější prototypy. Veškeré návrhy musí být schváleny zadavatelem, 29\n30 cílem této fáze je stanovit si přesný plán realizace, určit a vyvinout komponenty, které jsou nezbytné. Celá tato fáze zabírá kolem 30% určené pro projekt. Jak je již zřejmé realizační fáze zabírá nejvyšší časový úsek projektu a zabývá se samotnou realizací projektu, tedy vývoje softwaru. Metodika RUP se snaží o paralelní vývoj řízeny případy užití. V této fázi se kontroluje komplexnost celého systému, průběžně se testuje a kontroluje jeho kvalita. Realizační fáze končí právě dodáním první funkční verze softwaru. Fáze předání zahrnuje činnosti, jako jsou, předání finální verze produktu a to včetně celkové dokumentace a manuálů, instalace, zaškolení uživatelů, údržbu systému či poskytnutí help-desku. Celková doba této fáze tvoří, stejně jako fáze počáteční, přibližně 10% z celkového časového intervalu provedení projektu. Metodika Rational Unified Process podporuje v celém svém životním cyklu řízení kvality produktu, čímž se také snaží zamezit vzniku případných rizik, pomáhá jí k tomu šest základních praktik, kterými se řídí: [2, s ] iterativní vývoj správa a řízení požadavků použití komponentové architektury vizuální modelování softwaru průběžné zajišťování a ověřování kvality řízení změn Hodnocení kritérií skupin Produkt a Lidé Na základě propracovanosti této metodiky a jejích vyčerpávajících popisů veškerých činností a procesů, nejsou kladeny až tak vysoké nároky na zkušenosti manažera projektu, stejně tak ani na vysokou kvalifikaci členů týmů. Použití této metodiky je nejvhodnější pro projekty, které jsou vyvíjené v delším časovém úseku, tedy větší projekty, které však nekladou velké nároky na změny. Je vhodná i pro řešení projektů s omezeným přístupem uživatelů podílejících se na řešení. 30\n31 Graf 6-1 RUP - Kritéria Produkt a Lidé - min, max, opt Na grafu výše jsou zaneseny minimální, maximální a optimální hodnoty kritérií skupin Produkt a Lidé, tak jak je stanovila autorka pro posuzování systému metodik METES. Minimální hodnoty určují, za jakých minimálních podmínek lze metodiku ještě použít, naopak maxima určují hodnoty, které metodika překročit nemůže. Optimální hodnoty kritérií mapují, kdy je použití metodiky pro projekt nejvhodnější a její zavedení nejefektivnější Posouzení použitelnosti RUP pro projekt Humanet V následující tabulce jsou znázorněny veškeré hodnoty potřebné pro analýzu vhodnosti zavedení metodiky RUP pro projekt Humanet na základě hodnocení systému METES. Určení a způsob výpočtu vah je uveden výše v kapitole č Minima, maxima a optima stanovená pro danou metodiku, jsou uvedena tak, jak je definovala autorka systému METES Ph.D. Alena Buchalcevová. Pro hodnocení RUP je vybrána rozsáhlá, těžká verze Rational Unified Process\n32 RUP váhy min max opt projekt Humanet za hranicemi extrémů vzdálenost od optim. hodn. vážené abs. hodn. vzdáleností od optima Důležitost produktu 0, ,795 Délka projektu 0, ,109 Stálost požadavků 0, ,024 Znovupoužitelnost 0, ,053 Velikost řešení 0, ,000 Zkušenost manažera projektu 0, ,102 Kvalifikace členů týmu 0, ,078 Motivace členů týmu 0, ,090 Dostupnost uživatelů 0, ,146 Velikost týmu 0, ,340 Rozmístění 0, ,000 1,000 1,737 Tabulka 6-1 Posouzení použitelnosti metodiky RUP pro projekt Humanet Ohodnocení projektu Humanet je provedeno na základě charakteristik projektu a za pomoci pana Ing. Romana Dufka ze společnosti HOUR, spol. s r.o. Jednotlivé číselné hodnoty, které jsou u projektu uvedeny, jsou stanoveny dle toho, kterému stupni ohodnocení dané kritérium pro projekt přísluší. Ve sloupci označeném za hranicemi extrému jsou sledovány hodnoty, které se vychylují z intervalu minim a maxim ve kterých lze metodiku možno použít. Pokud se projekt Humanet plně vejde do tohoto intervalu je zde uvedena hodnota nuly, v případě, že do stanoveného intervalu nespadá je uvedeno, o kolik jej Humanet přesahuje. Pět projektově klíčových kritérií, které hrají v hodnocení zásadní roli je vyznačeno modře. Jak je tedy z tabulky 6-1 patrné, projekt Humanet v případě metodiky RUP přesahuje dvě z pěti klíčových projektových kritérií a to kritéria Dostupnost uživatelů, kde přesahuje maximální hodnotu ve které je metodika RUP použitelná a Velikost týmu, kde naopak dosahuje hodnoty nižší, než ve které lze metodiku zavést. Jelikož v hodnocení dochází k překročení, a to více než ve dvou, z projektových klíčových kritérií, znamená to, že je metodika Rational Unified Process pro projekt Humanet nepoužitelná. Dále jsou v tabulce ještě uvedeny vzdálenosti projektu Humanet od optimálních hodnot metodiky RUP ve kterých je její použití nejefektivnější. Hodnoty definující vzdálenosti od optima jsou poté ještě využity k výpočtu absolutních hodnot vzdáleností od optima, kde jsou jejich absolutní hodnoty vynásobeny váhami kritérií, celkový 32\n33 součet těchto hodnot pak udává o kolik, se celkově hodnoty kritérií projektu Humanet liší od optimálních hodnot metodiky RUP. Překročení intervalu hodnot, kdy je metodiku RUP možné použít, je lépe vidět z grafu níže, kde jsou porovnány minimální hodnoty, maximální hodnoty a hodnoty projektu stanovené pro projekt Humanet. Graf 6-2 Posouzení použitelnosti metodiky RUP pro projekt Humanet 6.2 Metodika Microsoft Solution Framework (MSF) Je metodika, která byla uveřejněna v roce 1993 společností Microsoft. Zahrnuje praktiky zabývající se vývojem softwaru. V mnoha případech bývá označována spíše pouze jako obecný metodický rámec, který má za úkol řízení procesů pří vývoji softwaru. [20, s. 1-4] Charakteristika metodiky Metodika MSF je ovlivněna myšlenkami extrémního programování a dělí se na dva metodické rámce a to MSF for Agile Software a MSF for CMMI Process Improvement. [4, s. 115] Metodika MSF for Agile Software je, jak je již patrné přímo z jejího názvu, metodikou zaměřenou na agilní vývoj softwaru a je tak vhodnější spíše pro menší projekty na kterých se podílí menší týmy. Zatímco MSF for CMMI Process Improvement je metodika, která je založena na o něco formálnějších postupech. CMMI je označení pro Capability Maturity Model Integration, tedy Integrační model zralosti. Jedná se o referenční model procesů a postupů, který zahrnuje doporučení na základě 33\n34 kterých, by se vývojářský tým měl řídit. Model zralosti obsahuje pět úrovní, MSF for CMMI Process Improvement odpovídá jejímu třetímu stupni a to zralosti definované. Definovaná úroveň zralosti říká, že je definován proces na úrovni organizace, který je popsán ve standardech, procedurách, nástrojích a metodách a institucionalizován, je definováno i přizpůsobování procesů podle typu projektu [6, s. 24] Obecný rámec definovaný metodikou Microsoft Solution Framework zastřešuje tři následující oblasti: Základní principy Týmový model Procesní model Základní principy definují veškeré zásady, které jsou společné pro všechny členy týmu podílející se na vývoji. Mezi nejzákladnější z nich bych zahrnula partnerství se zákazníkem, to má za cíl zabezpečit dobrou komunikaci mezi týmem a zákazníkem, postavenou na stanovení společných cílů. Dalším z důležitých principů je, aby byli zapojeni všichni členové týmu, kteří budou spolupracovat na uskutečnění definované vize, která je všem společná. Důraz je přitom kladen také na kvalitu vyvíjeného produktu a snahu rychlého přizpůsobení se vznikajícím změnám. Týmový model určuje organizovanost jednotlivých pracovníků a jimi prováděných činností. Jak je znázorněno na obrázku 6-2 skládá se tento model ze sedmi skupin, které jsou rozděleny na základě činností a zaměření, kterými se zabývají, ke každé skupině je určen i odpovědný pracovník, všichni členové týmu jsou si však rovni. Tyto skupiny je i možno buď různě rozšiřovat, nebo právě naopak zmenšovat dle potřeb konkrétního projektu. Obrázek 6-2 Týmový model MSF  34\n35 Každá role v týmu plní určité činnosti, jejichž výsledkem jsou pak pracovní produkty. Např. v rámci projektového řízení se jedná především o činnosti spojené se splněním veškerých požadavků zadaných zadavatelem. Veškerá práce, kterou jednotlivý členové týmu provádějí je pečlivě plánována a kontrolována za pomocí pracovních položek. V projektovém portálu se pak dále ještě generují reporty, které slouží k podpoře řízení celého projektu. Procesní model MSF je iterativní s opakujícími se krátkými vývojovými cykly, které na sebe navazují. Každý z tohoto cyklu je ukončen přidáním nebo pravou funkčnosti softwaru. Procesní model se dělí do pěti fází [20, s. 5-6] Tvorba vize dohodnutí společného cíle projektu, jeho základních vlastnostech a předběžném harmonogramu Plánování tvorba plánu jednotlivých iterací, tato fáze je ukončena po jejich veškeré definici Vývoj tvorba kódu, jeho testování, vytváření dokumentace Stabilizace testování a ověřování celkové kvality systému, kontrola možné implementace a splnění definovaných požadavků. Nasazení samotná implementace systému u zákazníka Veškeré fáze jsou znázorněny na obrázku 6-3 Procesním modelu MSF. Obrázek 6-3 Procesní model MSF V rámci MSF jsou zahrnuty tři disciplíny, které jsou spojeny s řízením projektu samotné řízení projektu, příprava týmu a risk management. MSF for CMMI pokrývá téměř všechny procesy podporující projekty na úrovni organizace, projektové procesy, technické procesy, procesy implementace software tak i procesy pro podporu softwaru. Jedná se další z těžkých metodik, která podrobně popisuje veškeré procesy a je založena na iterativním vývoji. 35\n36 6.2.2 Hodnocení kritérií skupin Produkt a Lidé Pro zhodnocení jak kritérií skupin Produkt a Lidé tak i pro posouzení použitelnost metodiky pro projekt Humanet je zvolena verze MSF for CMMI Processs Improvement a to verze 4.0. Tato metodika se řadí mezi těžší společně s metodikou RUP, detailně popisuje veškeré procesy související s životním cyklem produktu a je tedy spíše určena pro velké, důležité projekty, jejichž vývoj může trvat až 24 měsíců. Na těchto projektech se může i podílet více týmů, které se mohou nacházet i v různých zemích. Díky dobrému popisu jednotlivých procesů nejsou kladeny vysoké nároky na odbornou kvalifikaci manažera projektu, ani členy týmu. Požadavky na projekt lze definovat předem, i když se následně mohou z části měnit, například jejich priority, proto je zde přítomnost zadavatele důležitá hlavně na začátku a konci projektu. Metodika MSF CMMI se snaží vytvářet znovupoužitelné komponenty v rámci projektu, tato metodika je velice úzce spjata s Visual Studio Team System. V grafu 6-3 jsou zachycena optima, minima a maxima určená pro metodiku MSF CMMI. Jak je vidět většina optimálních hodnot se shoduje s maximálními hodnotami, ve kterých lze metodiku zavést. Graf 6-3 MSF CMMI - min, max, opt Posouzení použitelnosti metodiky MSF CMMI pro projekt Humanet Projekt Humanet se u metodiky MSF CMMI vejde do všech stanovených intervalů minimálních a maximálních hodnot až na jedno z klíčových kritérií a to Dostupnost uživatelů. Z hlediska systému METES je i tato metodika pro daný projekt 36\n37 nepoužitelná, protože je překročena hranice u jednoho z klíčových projektových kritérií. Další z jejich výhod je i úzká provázanost na Visual Studio Team System, které je ve společnosti HOUR, spol. s r.o. již zavedeno a členové týmu by se mu nemuseli nově učit. Co se týká optimálních hodnot, těch metodika dosahuje v kritériích Stálost požadavků, Velikost řešení a Rozmístění. MSF CMMI váhy min max opt projekt Humanet za hranicemi extrémů vzdálenost od optim. hodn. vážené abs. hodn. vzdáleností od optima Důležitost produktu 0, ,795 Délka projektu 0, ,109 Stálost požadavků 0, ,000 Znovupoužitelnost 0, ,053 Velikost řešení 0, ,000 Zkušenost manažera projektu 0, ,102 Kvalifikace členů týmu 0, ,078 Motivace členů týmu 0, ,090 Dostupnost uživatelů 0, ,146 Velikost týmu 0, ,340 Rozmístění 0, ,000 1,000 1,713 Tabulka 6-2 Posouzení použitelnosti metodiky MSF CMMI pro projekt Humanet Jak je z grafu vidět, metodika MSF CMMI přesahuje daný interval pouze jednou a to v maximu u kritéria Dostupnost uživatelů. Graf 6-4 Posouzení použitelnosti metodiky MSF CMMI pro projekt Humanet 37\n38 6.3 Metodika OpenUP Metodika OpenUP se řadí mezi relativně nové agilní metodiky. Vznikla v roce 2007 na základě odlehčení metodiky Unified Process a je dostupná pod Eclipse Public Process Charakteristika metodiky Jedná se o open-source metodiku, která využívá jako metodika RUP iteračního či inkrementálního modelu životního cyklu softwaru a stejně tak je postavena na případech užití a snaží se o co největší eliminaci případných rizik, které by mohly při vývoji vzniknout. OpenUP je postaven na čtyřech základních pravidlech, které uvádí Manifest agilního vývoje softwaru. Konkrétní pravidla metodiky OpenUP a principy manifestu jsou pro srovnání uvedeny v tabulce 6-3. Principy metodiky OpenUP Základní pravidla Manifestu agilního vývoje Spolupráce na společných zájmech a sdílení porozumění. Hodnocení konkurenčních priorit s cílem maximalizovat hodnoty pro zákazníka. Zaměření na architekturu a organizovaný vývoj s cílem minimalizace rizik Průběžné získávání zpětné vazby a zlepšování. Individualita a komunikaci je upřednostněna před procesy a nástroji. Spolupráce se zákazníkem je důležitější než vyjednávání o smluvních podmínkách. Fungující software má přednost před vyčerpávající dokumentací. Reakce na změny jsou vítány před striktním dodržováním plánu. Tabulka 6-3 Mapování principů OpenUP a Manifestu agilního vývoje [13, s. 4] Metodika OpenUP je označována jako minimálně dostatečná, což znamená, že i přes její kompletnost a rozsah se dá dále velice snadno rozšířit a přizpůsobit na základě požadavků, které jsou na vyvíjený produkt kladeny. Jejím základním rysem je oddělenost znovupoužitelného metodického obsahu a procesního obsahu, v tom jsou vybírány jednotlivé části z obsahu metodického, které jsou pak následně provázány v souvislosti s řízením daných postupů. [4, s. 117] METODICKÝ RÁMEC Metodický obsah produkty role úlohy návody Procesní obsah popis produktu popis rolí popis činností vzor schopností dodávka Obrázek 6-4 Metodický rámec 38\n39 Jak je vidět na obrázku 6-4 Metodický obsah zahrnuje definici produktů, rolí, úloh a návodů, procesní obsah pak určuje životní cyklus daného projektu a sleduje ho z časového hlediska. Metodický obsah je rozdělen do tří základních úrovní. V první úrovni je analyzována práce jednotlivců a to jak přispěli k postupu ve vývoji, tento pokrok je měřitelný za pomoci tzv. mikro-přírůstku. Druhá úroveň sleduje pokrok ve vývoji z hlediska celého týmu, ten je ohodnocovaný na základě týdenních iterací. Hlavním cílem této úrovně je testování softwaru a dokončení verze softwaru, který bude bez problému spustitelný. Třetí úrovní metodického obsahu je samotný životní cyklus projektu, ten je opět jako u metodiky RUP rozdělen do čtyř základních fází a to fáze zahájení, rozpracování, konstrukce a zavedení. Metodika definuje 3 základní prvky a to: Role - tým metodiky OpenUP se skládá ze sedmi základních rolí a to, projektového manažera, analytika, architekta, vývojáře, testera, zainteresované strany a kohokoliv. Všechny tyto role jsou na sobě vzájemně závislé a každá z nich má v rámci iterací dané úkoly, které musí splnit. Projektový manažer je jednou z klíčových rolí projektu, vytváří časový harmonogram, projektový a iterační plán z čehož vyplívá jeho celková zodpovědnost za projekt jako celek, včetně jeho úspěšného dokončení a předání finálního produktu zákazníkovi. Analytik má za úkol komunikovat se zainteresovanou stranou a stanovit rozsah vyvíjeného systému a určit veškeré požadavky na software, včetně jejich priorit. Architekt pak definuje veškeré artefakty a technické potřeby spojené s návrhem architektury projektu. Cílem vývojáře je rozvoj jednotlivých částí projektu, do jeho kompetencí spadají činnosti, jako jsou návrh systému a vytvoření jeho prvků, vytvoření skriptu a implementace produktu. Tester má za úkol otestování softwaru v průběhu celého vývoje jeho tvorby, má tak zaručit a zajistit jeho bezchybnou funkčnost. Zainteresovanou stranou v tom o případě rozumíme koncové uživatele, které mohou výsledek a průběh celého vývoje softwaru znatelně ovlivnit, na základě měnění svých požadavků. Jako kohokoliv označujeme osobu, která zadává žádosti pro uskutečnění změn v projektu, jelikož není tato osoba přímo identifikována, může jí být kdokoliv z členů týmů podílejícího se na projektu. Disciplína je postavena na vodopádovém modelu vývoje tzn., že veškeré skupiny úloh, které spolu určitým způsobem souvisí a jsou zahrnuty právě v rámci nějaké disciplíny, se pro lepší organizovanost řídí právě tímto modelem. 39\n40 OpenUP je rozdělen do těchto disciplín Požadavky, Architektura, Vývoj, Testování, Řízení projektu, Řízení konfigurací a změn. [6, s. 130] Úloha jedná se o činnost, která je vykonávána jednotlivými rolemi v týmu. Metodika OpenUP zahrnuje 18 definovaných úloh, v jejichž rámci jsou určovány pracovní produkty. [6, s. 130] Vybrané prvky z metodického obsahu se ukládají do tzv. vzorů schopností, které jsou součástí procesního obsahu. Tyto vzory slouží buď jako jednotlivé dílčí, v tomto případě popisují jednu konkrétní oblast z vývoje, jako je např. zahájení projektu, nebo jsou seskupeny a tvoří šablonové vzory. Výsledkem je kompletní procesní šablona iterací, kterou je možno opakovaně užívat dle potřeb. Celý vývoj metodiky OpenUp, je jak, již bylo řečeno, rozdělen do čtyř fází, které jsou znázorněny na obrázku 6-5. Obrázek 6-5 Proces metodiky OpenUP [13, s.7] V první fázi zahájení jsou určeny milníky životního cyklu objektu, po iteraci, či několika iteracích přechází do druhé fáze, kde je definována architektura vznikajícího produktu. Poté opět po určitém počtu iterací dochází do třetí fáze, ve které je ověřována schopnost provozu software. V závěru dochází k posledním nutným iteracím vyzkoušení softwaru a následnému zavedení produktu u zákazníka. Metodika OpenUP je vhodná spíše pro realizaci projektů v menších týmech, je však snadno rozšiřitelná a přizpůsobitelná. Co se týká hlediska pokrytí procesů, pokrývá tato metodika pouze částečně přibližně polovinu projektových procesů. Většina jejího zaměření je pak zahrnuta v procesech implementace softwaru a podpory softwaru Hodnocení kritérií skupin Produkt a Lidé Metodiku OpenUP je vhodné použít při krátkodobých projektech, které mají být realizované přibližně do šesti měsíců a u kterých se předpokládá vysoká proměnlivost požadavků v průběhu vývoje. Určená je tedy spíše pro projekty, které nemají životní důležitost a je řešena menšími týmy. Díky tomu, že se jedná o variantu open-source metodiky jsou k dispozici různé šablony, využívá tedy již hotových komponent, což 40\n41 ve výsledku neklade vysoké požadavky na zkušenosti a dovednosti vedoucího projektu, ani na vysokou kvalifikaci členů týmů či jejich morální motivovanost. Na grafu 6-5 jsou zachyceny minimální a maximální hodnoty, při kterých je možno OpenUP ještě použit. Současně jsou zde zaneseny optimální hodnoty, při jejichž splnění metodika plně zastoupí veškeré požadavky související s vývojem a zajistí tak kvalitní výsledný produkt. Graf 6-5 OpenUP min, max, opt Posouzení použitelnosti metodiky OpenUP pro projekt Humanet V tabulce níže máme opět uvedeny stanovené váhy důležitosti produkty, minima a maxima použitelnosti metodiky a její optimální hodnoty, které jsou pro posouzení použitelnosti metodiky OpenUP pro projekt Humanet nezbytné. Jak můžeme vidět, hodnocený projekt přesahuje tři z posuzovaných kritérií, přičemž dvě z nich jsou opět kritérii klíčovými pro projekt a to Dostupnost uživatelů a Rozmístění. Projekt Humanet je posuzován jako velký projekt, zatímco metodika OpenUP, jak již bylo zmíněno, je vhodná právě naopak pro projekty menší. Uživatel není v rámci projektu téměř dostupný, což není vzhledem k měnícím se požadavkům zcela úměrné, přesahuje projekt Humanet interval vymezený pro dostupnost uživatele. Díky tomu, že metodika OpenUP má být aplikována spíše v na menších projektech, pracuje na vývoji i menší množství lidé, jejichž rozmístění by mělo být ideálně v jedné místnosti. Posuzovaný projekt však splňuje naprosto opačné podmínky. 41\n42 OpenUP váhy min max opt projekt Humanet za hranicemi extrémů vzdálenost od optim. hodn. vážené abs. hodn. vzdáleností od optima Důležitost produktu 0, ,000 Délka projektu 0, ,109 Stálost požadavků 0, ,048 Znovupoužitelnost 0, ,000 Velikost řešení 0, ,193 Zkušenost manažera projektu 0, ,102 Kvalifikace členů týmu 0, ,078 Motivace členů týmu 0, ,090 Dostupnost uživatelů 0, ,291 Velikost týmu 0, ,085 Rozmístění 0, ,716 1,000 1,713 Tabulka 6-4 Posouzení použitelnosti metodiky OpenUP pro projekt Humanet Metodika OpenUP, přesahující opět dvě z pěti klíčových projektových kritérií, je stejně jako metodika RUP posouzena jako nepoužitelná pro projekt Humanet. Graf 6-6 Posouzení použitelnosti metodiky OpenUP pro projekt Humanet V grafu 6-6 jsou pro přehlednost znázorněny minimální a maximální hodnoty, ve kterých lze metodiku OpenUP aplikovat na projekt, aby měl předpoklady pro jeho úspěšné splnění. Jsou zde přehledněji zviditelněné hodnoty kritérií, ve kterých projekt Humanet dané intervaly přesahuje kritéria Velikost řešení, Dostupnost uživatelů a Rozmístnění. 42\n43 6.4 Metodika Feature Driven Development (FDD) Metodika Feature-Driven Development je zástupcem agilních metodik a to i přes to, že je o něco formálnější než běžné agilní metodiky jako je např. Extrémní programování. Tato metodika i přes veškeré agilní principy stále zdůrazňuje potřebu předchozího modelování. Feature-Driven Development vzniklo na konci 90. let 20. stolení a jejími autory jsou Jeff De Luca a Peter Coad Charakteristika metodiky FDD je založeno na krátkém iterativním vývoji a to většinou ve dvou-týdenním intervalu. V průběhu iterace dochází k návrhu a provedení tzv. užitných vlastností. Užitná vlastnost je důkazem funkčnosti produktu, jedná se o srozumitelný, měřitelný a realizovatelný důkaz, který má důležitou hodnotu pro zákazníka. [16, s ] Metodika si tedy potrpí na řízení kvality v průběhu celého vývoje softwaru. Snaží se o snížení rizik a nejistoty při vývoji. U zadavatelů projektů je tato metodika oblíbená díky průběžné dodávce nových verzí produktu, ten je tedy neustále informován jakým směrem se ubírá celý proces vývoje a v jaké fázi se právě nachází. Životní cyklus metodiky Featre Driven Development je rozdělen do pěti fází [6, s.138]: Tvorba celkového modelu Seznam užitné vlastnosti Plánování užitné vlastnosti Návrh užitné vlastnosti Realizace užitné vlastnosti Obrázek 6-6 Fáze životního cyklu FDD Výše na obrázku 6-6 je znázorněno pět fází vývoje, podle metodiky FDD. Jak je zřejmé ve všech fázích se metodika převážně věnuje právě specifikacím týkajících se užitných vlastností. Vynechává tak například některé fáze jako jsou u metodiky OpenUP, nebo RUP, fáze zabývající se dodáním produktu apod. První krok vývoje této metodiky začíná vypracováním modelu životního cyklu produktu. To je možné např. pomocí notace UML. Na základě případu užití, pak lze určit skupina nejzákladnějších vlastností, které musí software naplňovat. Budoucí uživatele při společné práci 43\n44 s vývojáři určí základní požadavky, které by měl systém splňovat. Výsledek celé této fáze může prezentován prostřednictvím diagramu tříd. Je tak vytvářen základní model celkové projektu, který je postupně doplňován o další požadavky. Ve druhé fázi dochází k vytvoření seznamu, jehož obsahem jsou, užitné vlastnosti, které jsou hodnoceny na základě určení jejích preferencí. Užitné vlastnosti jsou v tomto seznamu detailněji rozděleny do různých kategorií. Cílem třetí fáze je, rozplánovaní vývoje na základě seznamu vytvořeného v přecházející fázi. Na základě určených se sestaví pořadí, ve kterém budou jednotlivé vlastnosti zaváděny do systému. Čtvrtá fáze má za úkol, podrobné zpracování návrhu projektu na základě užitných vlastností, které jsou rozděleny mezi členy týmu podle toho, kdo za danou vlastnost zodpovídá. V závěrečné fázi realizace je vyvíjeny systém realizován a testován osobou zodpovědnou za určitou třídu. Praktiky FDD: [6, s ] Doménové objektové modelování model pro celkový rámec metodiky, který je pak dále rozvíjen na základě užitných vlastností. Vývoj dle užitných vlastností veškerý vývoj FDD je závislý na stanovených užitných požadavcích. Individuální vlastnictví tříd je prosazováno individuální vlastnictví kódu, každý z členů pracuje na jemu určené části. Díky tomu je viditelné, kdo zodpovídá za integritu dané části. Týmy použitelné pro vlastnosti každé užitné vlastnosti je přisouzen člen týmu, který zodpovídá za jeho správné zavedení. Jsou vytvářeny přímo týmy pro užitné vlastnosti, kde se seskupují vlastníci jednotlivých tříd. Inspekce dohlíží na to, aby byla kvalita vyvíjeného produktu co nejvyšší a to od návrhu až po samotný kód. Pravidelné buildy v pravidelných časových úsecích dochází k seskupení jednotlivých částí kódů, ty jsou pak posuzovány jako celek. Řízení konfigurací zdrojového kódu, specifikace požadavků, analýzy a testování. Reporting snaha o eliminaci počtu činností, které by souviseli se sběrem informací, v jakém stavu se vyvíjený projekt nachází. 44\n45 Metodika FDD pokrývá určitou podporu projektových procesů a dále je zaměřena spíše na podporu procesů implementace, jako jsou detailní návrh, konstrukce a integrace softwaru. Dále zastřešuje většinu procesů pro podporu vývoje softwaru Hodnocení kritérií skupin Produkt a Lidé Metodika FDD je hůře dostupná a není dodávána s nástroji pro správu, proto je zde nezbytné zastřešit před samotným vývojem modelování předem, což však také tato metodika vyžaduje a prosazuje. Díky tomu je možné tuto metodiku zavést i u projektů s vyšší důležitostí. Optimální doba stanovená pro uskutečnění projektu kolem šesti měsíců. Jelikož se jedná o agilní metodiku, není stanovení požadavků předem striktně dáno, v průběhu celého vývoje se mohou různě měnit s tím je však také spojena potřeba účasti zákazníka na projektu, není nutné, aby byla denní, ale jsou zde kladeny vyšší nároky z důvodů změn. Díky popisu procesů a dobrému řízení kvality produktu není kladen až tak velký důraz na odborné znalosti manažera projektu ani jednotlivé členy týmu. Velikost týmu je na střední úrovni, tedy projekt vedený pod metodikou FDD lze vyvíjet jak v menším, tak větším počtu jednotlivců, optimální hodnot se pohybuje přibližně kolem 15 lidí. Tým by měl být pohromadě, nejlépe na jednom místě. Na grafu níže jsou opět zachyceny optima, minim a maxim odpovídající metodiky Featrue-Driven Development. Tak jak jsou vymezeny pro hodnocení metodikou METES. Graf 6-7 FDD - min, max, opt 45\n46 6.4.3 Posouzení použitelnosti metodiky FDD pro projekt Humanet Metodika FDD je již třetí z posuzovaných metodik, která opět překračuje intervalové rozpětí metodiky FDD dané jejími minimálními a optimálními hodnotami. V tomto případě dochází k překročení kritéria Velikost řešení, projekt Humanet je totiž postaven na více než 300 případů užití, což řadí tento projekt do kategorie velkých projektů. Je vidět, že dochází k opětovnému překročení stejných klíčových projektových kritérií Dostupnost uživatelů a Rozmístění, avšak u metodiky OpenUP bylo toto překročení o jeden stupeň, v případě metodiky FDD se jedná o případ opačný, překračuje dané intervaly o celé 4 stupně. Veškeré tyto hodnoty posouzení jsou zaznamenány v tabulce níže. FDD váhy min max opt projekt Humanet za hranicemi extrémů vzdálenost od optim. hodn. vážené abs. hodn. vzdáleností od optima Důležitost produktu 0, ,265 Délka projektu 0, ,109 Stálost požadavků 0, ,048 Znovupoužitelnost 0, ,000 Velikost řešení 0, ,000 Zkušenost manažera projektu 0, ,077 Kvalifikace členů týmu 0, ,039 Motivace členů týmu 0, ,030 Dostupnost uživatelů 0, ,582 Velikost týmu 0, ,170 Rozmístění 0, ,716 1,000 2,036 Tabulka 6-5 Posouzení použitelnosti metodiky FDD pro projekt Humanet Na grafu posouzení použitelnosti metodiky Feature-Driven Development pro projekt Humanet jsou srovnány minimální a maximální hodnoty metodiky s hodnotami projektu Humanet. U kritérií Dostupnost uživatelů a Rozmístění jsou znatelné velké rozdíly mezi hodnotami definovanými pro projekt a hodnotami vymezeními optimem. 46\n47 Graf 6-8 Posouzení použitelnosti metodiky FDD pro projekt Humanet 6.5 Metodika Scrum Scrum je řazen mezi jednu z nejznámějších a nejpoužívanějších agilních metodik. Představena byla v roce 2002 a jejími autory jsou, Ken Schwabe, Jeff Stuherland a Mike Beedle Charakteristika metodiky Metodika Scrum se zabývá spíše komunikací mezi členy týmů snahou rychle a pružně reagovat na změny, než postupovat podle přesně definovaných procesů vývoje. Veškeré procesy jsou samo-organizovány. Scrum je metodika postavená na iteračním vývoji, snaží se dodávat fungující části aplikace v co nejkratším čase a na základě zpětné vazby u zákazníka aplikuje a upravuje vyvíjený software podle jeho nových požadavků. Obrázek 6-7 Scrum - popis procesů  47\n48 Metodika Scrum je rozdělena do tří základních fází. Celý její proces je zachycen na obrázku 6-7. První fázi můžeme označit jako plánovací. Tato fáze zahrnuje plánování postupných dodávek softwaru včetně jeho celkového prvotního návrhu. Nejdůležitější části je však definice zákazníkových požadavků na vyvíjený systém, včetně uvedení jejich priorit. Tyto požadavky se uvádějí ve formě tzv. User stories (požadavky mluvící řečí zákazníka) a jsou evidovány v nejdůležitějším dokumentu metodiky Scrum nazvaném, Product backlog. Veškeré položky, které tento dokument obsahuje, jsou neustále aktualizovány a udržovaný na jednom místě, díky tomu je zde lepší možnost sledování veškerých jejích změn a rychlé přizpůsobení. Druhou fází je samotný vývoj, ten je zaznamenáván v tzv. Sprintech, které se odehrávají v rozmezí jednoho týdne až třiceti dní. Na konci každého Sprintu, jeden, nebo více týmů představí výsledky, kterých dosáhli. V každé iteraci aktuálního Sprintu jsou zpracovávány požadavky, které byly definovány v Product backlogu pro daný časový úsek tzn., že v průběhu každého z nich je zpracovávána jen část z uvedených požadavků. Pro měření procesu definuje metodika Scrum Burn-down chart, ten umožňuje sledování již odvedené práce na produktu a usnadňuje určování množství práce, kterou je nezbytné udělat k dokončení ať už Sprintu či celého vyvíjeného produktu. Ukázka možného reportu Burn-down chartu je znázorněna na obrázku níže. Obrázek 6-8 Scrum - Burndown Report  Poslední fází metodiky je samotná dodávka, ke které dojde, pokud jsou již veškeré požadavky uvedené v Product backlogu zpracované a neobsahují již žádné nové. To má za následek ukončení cyklu Sprintů. Výsledný produkt je pak dále integrován a jsou testovány jednotlivé moduly, veškerá dokumentace k produktu se zpracovává až v této fázi. 48\na) Odborná úroveň b) Metodologie c) Rozpočet a náklady Vážené body kritéria c) Váha kritéria % Body od komise\nVODOVOD 2 Hodnocení nabídek Odborná úroveň Metodologie Rozpočet a náklady d) Nabídková cena č. nab Uchazeč kritéria kritéria kritéria Nab. cena v Kč bez DPH Nab. cena přepočtená na kritéria d) Body celkem\nVedení projektů, Odhadování, historie Agenda Docházka Pár slov o došlých specifikacích Vedení projektů Pár slov SW projektu na MFF Odhadování Historie projektů Dotazy Project management Co je to projekt?


neděle, října 31, 2010\nUdělala jsem si před časem radost a koupila si šitíčko z 30tých let minulého století. Jehly poznamenal zub času a jsou trochu orezlé a navlékáček zřejmě původní nebude. Šitíčko mi bude sloužit jako dekorace do šicího koutku a zůstane tak jak jsem ho koupila - jehly z něho používat nebudu. Pohled na něj mi připomíná časy "starých filmů pro pamětníky", na které jsem se kdysi ráda dívala.\npátek, října 22, 2010\nMám starší šicí stroj a kryt z umělé koženky se mi vůbec nelíbil a ani se nehodil do šicího koutku, který postupně vytvářím. Podle starého krytu jsem si udělala střih a ušila nový s fialkovým proužkem ze stejné látky, kterou mám na podsedáku na židli. Kapsičku jsem ozdobila vyšitým monogramem a kytičkou. Aby pěkně držel tvar celý jsem ho podšila vatelínem a rubová strana je z bílé látky ze starého povlečení. Dalo to sice trochu práce a přemýšlení, ale potah se mi povedl podle mých představ. Hezký víkend pro všechny přeje Jitka\nstředa, října 20, 2010\njsem chtěla navštívit už mnohokrát, ale když jsem projížděli kolem, měl už zavřeno anebo jsme spěchali. Konečně včera nastal den, kdy jsem mohla vstoupit dovnitř a obdivovat krásu starého nábytku, který tato firma vykupuje, opraví a dle přání zákazníka dostane výsledný vzhled. Já jsem tam byla jenom jako obdivovatelka, ale kdybych si měla vybrat ať už kredenc, vařenku, skříň, knihovnu či cokoliv jiného, tak bych opravdu nevěděla pro co se rozhodnout. V hale, kde jsme byli, je vystaveno cca 500 ks opraveného nábytku a venku pod velkou halou čeká dalších 2000 ks. Výběr je opravdu obrovský. Firma vyrábí i repliky nábytku dle vašeho přání a nebo vám váš starý nábytek upraví do podoby, kterou měl kdysi dávno. Tak trochu v hloubi duše uvažuji o tom, že bych si možná časem menší starou knihovnu nebo vitrínu domů pořídila. Za podívání stojí i jejich stránky www.antikjelinek.com a čeká tam na vás mnohem více, než jsem já vyfotila.\nneděle, října 17, 2010\nBabí léto se s námi minulý týden rozloučilo a alespoň se s vámi všemi podělím o několik vzpomínek na něj. Minulý víkend jsme jeli kolem Botanicusu v Ostré a na chvíli jsme se zastavili. Zahrady jsou zavřené a alespoň jsem si udělala malou radost v jejich obchůdku a vyfotila podzimní aranžmá před ním. Krásně zbarvené listy škumpy, bohyšky žloutnou a chystají se na zimu. Zahrádku zdobí několik posledních květin a borůvky v lese jsou opravdové říjnové a chutnaly báječně. Letos vysetá levandule má několik voňavých květů. Žluté kopretiny stále kvetou, ještě pár keříků mrazík nezdolal a jsou stále kouzelné. Celá zahrada je pocukrována barevným listím a ani se mi tu krásu nechce uklízet. Poslední fotka je ze zámeckého parku v Častolovicích, který jsme navštívili první podzimní den.\nstředa, října 13, 2010\nkterou jsem si koupila před rokem, aniž bych pro ni tehdy měla použití, se konečně dočkala a bude sloužit na uložení drobností potřebných k šití. Ozdobila jsem ji výšivkou a poprvé jsem vyšívala saténovou přízí DMC Satin barvičkou Light Lavender . Možná se s ní o trochu hůře vyšívá, protože neustálým protahováním se konce třepí, ale má nádherný třpytivý lesk a výšivka tak získá na kráse.\nUž dlouho před tím než jsme naší dcerce koupili novou postel jsem přemýšlela, jaký kapsář by se hodil a abych ho zvládla ušít. Jednou jsem na internetu uviděla fotku kapsáře, který byl ušitý ze starého povlečení. Moc se mi to líbilo, ale chybělo mi to hlavní - povlečení. Pravidelně jsem se dívala na internetu do mimibazaru, kde maminky nabízejí ledacos a jednou jsem měla štěstí a povlečení se mi podařilo koupit. Nejméně práce bylo s polštářem, který jsem zkrátila na potřebnou šířku. Povlečení jsem rozpárala na jednotlivé pásy. Na kapsář jsem použila horní a dolní motivy. Z prostředního největšího jsem ušila povlak na velký polštář a z jedné zbývající kytky jsem ušila dva malé polštářky. Chybí mi ještě přehoz na postel, který budu doufám šít v nejbližší době (nejhorší je asi začít a potom to jde samo).\npátek, října 08, 2010\nPardubice od včerejšího dne až do neděle žijí XVII. městskými slavnostmi s bohatým programem kulturním, sportovním i technickým. V neděli tyto slavnosti vyvrcholí 120. ročníkem Velké pardubické. My jsme si vybrali akci Oldtimer Corso Pardubice, což byl sraz historických vozidel přímo v srdci starých Pardubic na Pernštýnském náměstí. Počasí bylo nádherné, starých aut a motorek nepočítaně a návštěvníků ještě více. Bylo se na co koukat, všechno v plném lesku, některé dámy a pánové v historických oblecích a chvílemi jsem si připadala jako za starých časů. Moc se nám to líbilo a alespoň několika fotkami se s vámi podělím o atmosféru tohoto setkání.\núterý, října 05, 2010\nTyto dvě židle ještě pamatují smutné časy 2. světové války. Stávaly v kuchyni mých prarodičů v domku, ve kterém žije i dnes naše rodina. Dům je přestavěný a v jejich kuchyni máme koupelnu a šatnu. Jsou možná zajímavé tím, že je nevyrobil vyučený truhlář, ale strýček mého otce, který byl obyčejný zemědělec. Truhlařinu se naučil a přivydělával si výrobou drobného nábytku a dokonce dělal lavice do kostela. Dlouhá léta ležely zapomenuty na půdě a při přestavbě domu nám jedna z nich sloužila jako sedátko, stupátko, odkládátko. No prostě pomocník pro všechno a tak byla v daleko horším stavu než ta druhá. Ještě letos na jaře jsem ji používala při malování dětského pokoje a při tom se zrodil nápad, vrátit jim původní krásu jejich mládí z doby skoro před sedmdesáti lety. Po opálení a obroušení vypadaly mnohem lépe. Nakonec dostaly nový bílý kabátek a budou součástí našeho bydlení. Jedna bude v dětském pokoji a druhá u stolu se šicím strojem. Ušila jsem látkový sedák ve fialkové barvě a t


GA-DE vysoce krycí tekutý korektor na oční okolí 16 Ivory\nGA-DE vysoce krycí tekutý korektor na oční okolí 16 Ivory\nCena: 428.5 CK\nGA-DE vysoce krycí tekutý korektor na oční okolí 16 Ivory eshop >>\nMaybelline Fit Me! 15 korektor 6,8 ml\nKorektor Maybelline Fit Me Corrector.Jemný krémový korektor pro krytí nedokonalostí pleti. Výška: 115, Šířka: 14, Hloubka:14 Rozměry balení: 6ml Hrubá hmotnost: 16.. zjistit více >>\nKorektor Maybelline Fit Me Corrector dokonale zakryje nedokonalosti pleti. Gelová textura bez zbytečných vosků a olejů přirozeně kryje a přitom nechává kůži přirozeně dýchat. Překrývá nedokonalosti pleti včetně tmavých kruhů pod očima a osvětluje pokožku. Nezatěžuje ple.. zjistit více >>\nMatis Paris mandarinková pasta pro mastnou pleť Réponse Pureté 30 ml\nObsahuje čistící a vyrovnávací formuli na bázi aktivních ingrediencí a má nádhernou mandarinkovou vůni. Je k dispozici v důmyslné tubě, která umožňuje přesnou aplikaci. Díky tomu ji můžete mít vždy u sebe pro rychlé „opravy" drobných nedostatků, které jsou noční můrou.. zjistit více >>\nJediným tahem dodá vaší pleti oslňující rozjasnění! Lehce krycí korektor, zvýrazňovač a rozjasňovač v jednom - multifunkční pomocník dá okamžitě vyniknout těm oblastem vaší tváře, které chcete zvýraznit. Pigmenty odráženící světlo opticky redukují vzhled vrásek i t.. zjistit více >>


Po vypnutí displeje už nejde displej zapnout (Extensa 5220) - Forum NOTEBOOK.cz\nPo vypnutí displeje už nejde displej zapnout (Extensa 5220)\nRegistrován: 15 srp 2014 09:54\nPříspěvekod spoo » 15 srp 2014 10:22\nPo upgrade z W7 na W8.1 se mi teď často stává (dříve s W7 ne), že po vypnutí (jak je defaultně nastaveno v Možnosti napájení>Nastavení tématu>Vypínání displeje) se mi už displej nerozsvítí.\nDělá to i na externím monitoru.\nRežim spánku mám vypnutý, hybernaci odstraněnou (změna nepřinese zlepšení).\nPo vypnutí je vidět, že notebook maká, kontrolka disku poblikává, všechny kontrolky svítí.\nI po dlouhém čekání a po následných pokusech typu Ctrl+Alt+Del se displej nerozsvítí a nezbývá než vypnutí natvrdo. Pak obvykle následuje opakovaná modrá smrt a nezbývá než obnova z bitové kopie.\nSamozřejmě když nastavím aby se displej nevypínal a NB nešel nikdy do spánku, tak je vše OK. Jenže pro použití v noci vypnutí displeje nutně potřebuji. Zkusil jsem vypínat displej utilitkou třetí strany TurnOffLCDv101 http://www.redmondpie.com/turn-off-your ... one-click/ , ale problém je stejný - po vypnutí se displej nerozsvítí. Nejhorší je, že to nedělá vždycky, většinou však jo.\nPříspěvekod michalko58 » 15 srp 2014 12:14\nMne toto robil Aspire5720G s W7 32bit takmer vzdy (ale az ked bol displej dlhsie vypnuty) a robi mi to aj Aspire4830G s W7 64bit (menej casto). Modru smrt som vsak potom nikdy nemal.\nVzdy mi pomohlo zavriet ho (uspat) a znovu spustit.\nNeviem cim to moze byt. Asi je to daka "vlastnost" Aceru.\nPříspěvekod riki1 » 15 srp 2014 15:28\nA aka je vyhoda W8.1 oproti W7 ? Nechcem vyryvat, ale zaujima ma to. W8 alebo W8.1 som zatial videl len na obrazku a METRO sa mi nepaci uz ani tak.\nMicrosoft vacsinou vyrobi podareny OS a nasledne vzdy jeden nepodareny:\nMSDOS - podareny\nWIN 3 , WIN3.1 - nepodarok\nWIN 95,98 - podareny\nWIN ME - nepodarok\nWIN XP - podareny\nWIN VISTA - nepodarok\nW7 - podareny\nW8,W8.1 - ??????\n(NT a 2000 som neuviedol, lebo neboli univerzalne pouzitelne)\nPříspěvekod spoo » 15 srp 2014 23:33\nmichalko58: Uspat jsem ho taky zkoušel - nepomáhá, neusne. Ta modrá smrt je jen po vypnutí natvrdo, nic jiného se pak už nedá dělat. Ve W7 mi to nedělalo.\nriki1: podle mne je Win8.1 skvělá, jen jí zkrotit. Škoda, že mi na Extense blbne. Ta samá instalace na Compaq610 šlape bez závad.\nPříspěvekod Senik » 14 říj 2014 22:38\nTrochu oživím tohle téma, přítelkyni jsem koupil Acer Aspire V5-561G a všechno super, až na zmíněný problém s displayem. Jakmile se panel vypne, už nenajede. Nepomáhá ani zaklapnout víko a znovu otevřít.\nUž jsem úplně hotovej z všemožnýho googlení, zkusil jsem snad už všechno a nic nepomáhá... Neřešil někdo (a hlavně vyřešil) tenhle problém?\nPříspěvekod michalko58 » 15 říj 2014 07:29\nTak v poslednej dobe mi to zacalo robit castejsie aj na 4830TG - ak bude nejake riesenie sem s nim.\nPříspěvekod Senik » 18 říj 2014 16:20\nTak můj problém se vyřešil reinstalem Win 8.1 (že jich bylo) a na čistý systém jsem nainstaloval drivery přímo od Aceru pro obě grafiky. Mám pocit, že před tím jsem instaloval drivery ze stránek AMD a s nimi to blblo...\nPříspěvekod michalko58 » 02 lis 2014 11:38\nZistil som, ze pomoze odpojit napajanie a displej sa rozsvieti


Losinka - holiday resort - Poloha, Služby, Okolí\nČeské hory » Jeseníky » Ubytování » Rapotín » Losinka - holiday resort » Popis\nRekreační komplex Losinka se nachází v krásném přírodním prostředí, na úpatí Hrubého Jeseníku. Celý komplex se rozprostírá na okraji "vesnice roku Olomouckého kraje", mezi lesem a říčkou Losinkou, v bezprostřední blízkosti renesančního Zámku Velké Losiny a v blízkosti Termálních lázní Velké Losiny.\nRekreační komplex Losinka nabízí několik kategorií ubytování, ze kterých si vybere každý. Od milovníků kempování počínaje, až po komfortní ubytování v plně vybavených apartmánech konče. Areál resortu nabízí ideální zázemí pro relaxačně-regenerační pobyty, wellness pobyty a ubytování v rámci lázeňské léčby v sousedních Termálních lázních Velké Losiny. Wellness procedury poskytujeme v našem nově vybudovaném wellness studiu, přímo v areálu našeho resortu. Dále nabízíme velmi dobré zázemí pro školy v přírodě, školní výlety, školní lyžařské kurzy, rodinnou rekreaci, sportovní soustředění, firemní školení, svatby, promoce, ale i stravování při jednodenních zájezdech apod. Resort je otevřen celoročně.\nV okolí našeho resortu Losinka je nespočet značených turistických tras, které se dají libovolně kombinovat s vlakovou dopravou soukromé Železnice Desná ve směru na Kouty nad Desnou.\nVelké Losiny Šumperk Rozhledna Háj Nový Hrad Loučná nad Desnou Kompletní turistický průvodce Rapotín>>\nLosinka - holiday resort Rapotín Hlavní strana objektu\nLosinka - holiday resort Ceník ubytování a stravování


Řecko láka turisty na ostrovy bez covidu | Zprávy | Tiscali.cz\nAutor: Lukáš Strašík | Datum: 23. březen 2021 18:06\nŘecký ostrov Astypalaia | zdroj: Profmedia\nTuristika a cestovní ruch se podílejí asi na pětině řecké ekonomiky a v resortu pracuje asi pětina obyvatelstva. Pandemie koronaviru a s tím související pokles počtu přijíždějících turistů snížil loni řecké příjmy z cestovního ruchu na čtyři miliardy eur (105 miliard korun) z 18 miliard eur (472 miliard korun) v roce 2019. Řecká ekonomika celkově zaznamenala pokles o 8,2 procenta.\nZemi loni navštívilo jen 7,4 milionu zahraničních turistů, zatímco v roce 2019 to bylo 31,3 milionu. V případě německé a britské klientely, která tradičně patří k nejsilnějším, byl zaznamenán 62procentní, respektive 69procentní pokles.\nŘecko má kolem šesti tisícovek ostrovů, z toho je 117 obydlených a pouze 53 z nich má přes 1000 obyvatel. Po loňské katastrofální turistické sezoně nyní mohou právě ty malé doufat ve zlepšení – zvlášť když turistika tu pro místní představuje hlavní zdroj obživy.\nNa ostrovech s populací do tisíce lidí totiž neplatí systém očkování odstupňovaný podle věku či rizikových skupin, ale bude tu komplet proočkováno veškeré dospělé obyvatelstvo. Na některých ostrovech už mají v tomto ohledu hotovo, další přijdou na řadu v příštích týdnech.\nŘecká vláda odmítá nařčení, že jde o pouhý marketingový trik, jehož cílem je přilákat do země turisty. Důvod je prý čistě praktický, protože je drahé a neefektivní posílat na obtížněji přístupné ostrovy v několika vlnách zdravotnický personál, aby očkoval podle regulérního celostátního harmonogramu. Prostě se vezmou všichni najednou a hotovo.\nNapříklad na ostrově Astypalaia (jemuž se kvůli zvláštnímu tvaru říká egejský motýl) nebyl od začátku pandemie zaznamenán ani jeden případ nákazy a do konce dubna by tu podle plánu mělo být naočkováno veškeré místní obyvatelstvo. A úřady si samozřejmě pospíšily s tím, aby o tom, že na ostrovech nemají koronavirus, promptně informovaly celý svět.\nV desetimilionovém Řecku se koronavirem od začátku pandemie nakazilo něco přes 230 000 lidí, tedy zhruba šestkrát méně než ve stejně lidnatém Česku. Mrtvých země registruje necelých sedm a půl tisíce, v poslední době se ale potýká s nárůstem počtu nakažených.\nŘecko spolu s Rakouskem a některými dalšími zeměmi plánuje zavést vlastní osvědčení pro vstup na své území, a pokud by se unie neshodla na jednotném očkovacím certifikátu, mohou v letní sezóně platit v každé zemi jiné podmínky. Řecko už připravuje příslušné bilaterální dohody s Izraelem, Velkou Británií a Ruskem. Kromě toho budou mít zaměstnanci turistického sektoru od června přednost v pořadí vakcinace.\nSloganem letošní turistické kampaně je All you want is Greece. „Žádný obraz by nemohl lépe vyjádřit návrat k normálnímu turistickému ruchu než řecký úsměv, řecká krajina a řecká pohostinnost,“ prohlásil ministr pro cestovní ruch Charis Theocharis. „Dnes si k výhodám Řecka jako turistické destinace můžeme přičíst závazek nabídky a garance zdraví a bezpečnosti každého turisty.“\nOdlehlost a malá velikost, jež pro ostrovy dosud představovaly spíš nevýhodu, se tak najednou stávají velkou výhodou. Neboť je známo, že co je malé, to je hezké. A když to není hezké, aspoň toho není moc.\nŘecko zahraničí turistika a cestovní ruch Covid-19


Fotky veřejných domů jsou veřejné. Co je na tom divného? - Aktuálně.cz\nFotky veřejných domů jsou veřejné. Co je na tom divného?\n9. 7. 2015 14:30\nSvoboda panoramatu má být zachována a privatizace veřejného prostoru ve městech zastavena.\nTelevizní vysílač v Praze na Žižkově. Veřejně viditelný skoro odevšad, chráněn autorským právem. | Foto: ČTK\nV Evropském parlamentu se řešila takzvaná svoboda panoramatu. Respektive to, jestli si kdokoli může svobodně fotografovat z veřejného prostoru přístupný objekt a s onou fotografií pak svobodně nakládat. Piráti a spol. médiím před časem vnukli, že běží o to, zda si můžete fotit Karlův most a pak to dát na Facebook, čímž se problém posunul do úplně nesmyslné roviny. Ale začalo se o něm mluvit, což je důležité. Protože kromě velkých nesmyslů jde i o ty menší, ne tak sugestivní.\nPodstatou sporu je, jestli má mít architekt nebo majitel autorských práv k nějaké budově - ale třeba taky ke kašně v parku - nárok na „tantiémy“, pokud snímek oné stavby někdo využije ke komerčním účelům.\nJde o natolik neuchopitelnou materii, že je vůbec kupodivu, kdyby se jí někdo dokázal zmocnit právními předpisy. Vždyť i europoslanec Pavel Svoboda (KDU-ČSL), nejznámější odborník v této záležitosti, připouští, že „dosud není vymezena definice komerčního a nekomerčního užití.“ Takže o čem je tu řeč?\nAno, i v architektuře existují autorská práva, jakkoli budovy bývají kolektivním dílem a opisování je snazší. Veřejná architektura, chcete-li „veřejný dům“, je ale něco jiného než obraz v galerii. Byla „dána k dispozici“, vystavena veřejnému pohledu z veřejných pozemků, slouží veřejnosti a veřejnosti se týká, i když ji veřejnost přímo nepoužívá. Například tím, že před domem stojí kruhový objezd a za ním parkoviště, k domu vede MHD a podobně.\nCopyright se, marná sláva, musí přizpůsobit tomu, že taková budova je veřejná. Chtít po lidech, aby stavbu obcházeli a pozorovali, ale zároveň si dávali majzla na to, jestli ji fotí „privátně“, anebo už „komerčně“, je nepřijatelné. V Praze nejde jen o obligátní Tančící dům, ale třeba i zamýšlený „maršmeloun“ Na Františku. Představte si to – pokud vznikne, můžete se nad ním vztekat nebo usmívat, ale hlavně, pozor, fotit a zveřejňovat nekomerčně!\nA to ještě sedmdesát let po smrti architekta, jak předepisují autorská práva. Bude se po nás žádat, abychom při práci s fotkami zkoumali, zda je dotyčný po smrti 68, nebo už 72 let, takže šíření jeho díla je pod zákonem, nebo volné?\nKolik zajímavých budov z 20. století se stává obětí demolice bez ohledu na to, že sedmdesátiletá lhůta autorských práv pravděpodobně ještě neuplynula? Míříme snad k situaci, kdy se dům může zbourat, ale dokud stojí, nemůžete si ho komerčně vyfotografovat?\nV případě hotelu Thermal patří autorská práva architektům Machoninovým, ale práva na interiér vlastníkům. Z tohoto pohledu se může s budovou stát něco jiného zvenku a zevnitř, ostatně na úpravy interiéru už došlo. Totéž by platilo i pro komerční využití fotografií, jinak venku, jinak vevnitř. Ale jsme snad tohle povinni pokaždé vědět, studovat?\nNevím, jak to chodí s autorskými právy na kancelářské novostavby a jejich snímky. Co vím, je, že když jsem v kancelářské čtvrti v Praze-Michli před časem soukromě fotografoval, z jednoho takového sklopaneláku vylezla ochranka a začala mě vyhazovat, že tady se fotit nesmí a že tam nemám co pohledávat. Samozřejmě že jsem stál na veřejné ulici, na veřejném místě, nikde žádný nápis Soukromý pozemek, Vstup zakázán ani cedule s přeškrtnutým fotoaparátem, proč taky, nejsme ve vojenském prostoru. Jen na každém rohu bezpečnostní kamery a jinak pusto a prázdno.\nPrivatizace veřejného prostoru jako vyšitá. A taky nelegální. Zatím.\nTo je reálný stav. Cokoli, co by mohlo vést k jeho utužení, je špatně. Veřejná architektura, i ta soudobá, má zůstat veřejně přístupná a jakkoli „šiřitelná“. Není třeba pokoušet se to omezit nějakými krkolomnými pravidly, která by asi ovládalo a dokázalo využít jen pár vyvolených.\nkomentáře Názory.Aktuálně.cz Evropský parlament fotografie autorská práva tančící dům architektura