ICT (Vazba na nástroje řízení projektů, trendy a možnosti)

Použití CASE pro řízení projektů IS/ICT (Vazba na nástroje řízení projektů, trendy a možnosti)

ZS 2007

Autoři: Jiří Grégr Jakub Karlec Vít Pelikán Jan Rataj Pavel Toufar

Použití CASE pro řízení projektů IS/ICT

ZS 2007

Obsah 1

2

3

4

5

Úvod ................................................................................................................................... 3 1.1 Nejdůležitější pojmy .................................................................................................. 3 1.1.1 Projekt ................................................................................................................ 3 1.1.2 Projekt IS/ICT .................................................................................................... 3 1.1.3 Řízení projektů ................................................................................................... 4 1.1.4 CASE nástroje (Computer Aided Software Engineering).................................. 4 1.2 CASE ve vývoji.......................................................................................................... 4 1.2.1 Druhy CASE nástrojů......................................................................................... 4 1.2.2 Komponenty CASE systémů.............................................................................. 5 1.2.3 Požadavky na CASE systémy ............................................................................ 5 Ostatní CASE nástroje ....................................................................................................... 6 2.1 In-Step ........................................................................................................................ 6 2.1.1 in-Step CoreProcess Edition............................................................................... 6 2.1.2 in-Step PRINCE2 Edition .................................................................................. 7 2.1.3 Metodika Prince2 ............................................................................................... 8 2.2 Process Director (LBMS)........................................................................................... 9 2.2.1 Moduly Process Director.................................................................................... 9 2.2.2 Metodika LBMS Project Management ............................................................ 10 2.3 Rational (IBM) ......................................................................................................... 11 2.3.1 IBM Rational Suite........................................................................................... 11 2.3.2 Rational Team Unifying Platform.................................................................... 11 2.3.3 IBM Rational Method Composer..................................................................... 11 2.3.4 IBM Rational Project Console ......................................................................... 12 2.3.5 IBM Rational SoDA......................................................................................... 12 2.3.6 Metodika Rational Unified Process.................................................................. 12 2.4 Portfolio produktů společnosti Borland ................................................................... 12 2.4.1 Borland Tempo................................................................................................. 12 2.4.2 Borland StarTeam ............................................................................................ 13 2.4.3 Borland Core SDP............................................................................................ 13 2.4.4 All Fusion Process Management Suite............................................................. 13 Informace o produktu Enterprise Architect 7.0................................................................ 14 3.1 Stránky výrobce – firmy Sparx Systems .................................................................. 14 3.2 Případová studie ....................................................................................................... 15 Zhodnocení práce s nástrojem Enterprise Architect 7.0 .................................................. 15 4.1 Přehled...................................................................................................................... 15 4.2 Resource management – řízení zdrojů ..................................................................... 15 4.2.1 Přiřazení zdrojů ................................................................................................ 15 4.2.2 Správa rizik, metrik a práce.............................................................................. 16 4.3 Maintenance – Údržba ............................................................................................. 16 4.4 1.4 Seznam úkolů projektu....................................................................................... 17 4.5 Terminologický slovník projektu ............................................................................. 18 4.6 Metriky a odhady ..................................................................................................... 18 4.6.1 Odhad velikosti projektu .................................................................................. 19 4.7 Testování .................................................................................................................. 20 4.8 Řízení změn a poruch ............................................................................................... 21 4.9 Problémy projektu a modelů .................................................................................... 22 4.10 Hodnocení nástroje Enterprise Architect ................................................................. 22 Zdroje ............................................................................................................................... 23

2


ZS 2007

1 Úvod V dnešní době se mnoho podniků dostává do situace, kdy musí řídit více projektů současně. K dosažení cílů firmy je vhodné a ekonomicky efektivní projekty řídit pomocí nástroje, který projektovým manažerům usnadňuje práci a pomáhá odhalovat chyby, které vznikají v průběhu projektů. Správné využití takových nástrojů v kombinaci se zkušenostmi manažera a dodržováním uznávaných metodik, lze dosáhnout výsledků, které by byly bez takových nástrojů jen stěží dosažitelné. CASE nástroje se obecně zaměřují na návrh, vývoj a údržbu SW, ale mohou obsahovat i další podpůrné nástroje zaměřené na související činnosti, jakými jsou např. řízení projektů. Cílem této práce je definovat stěžejní pojmy pro oblast řízení projektů a CASE nástroje, v další fázi budou vyzdviženy novinky a hlavní změny, které se objevily na trhu CASE nástrojů od doby, kdy byly naposled tyto nástroje analyzovány. Předposledním důležitým bodem bude zhodnocení práce s nástrojem Enterprise Architect (EA). Důvod pro volbu EA je zcela zřejmý – předcházející práce EA zmiňovaly, ale v žádné z nich nebyl popsán detailněji. My se proto pokusíme zjistit, zda nemá EA některou funkcionalitu, která by EA dokázala povýšit na plnohodnotného konkurenta jiných nástrojů, které Project Management běžně podporují. Jsme si vědomi, že EA není primárně určen pro řízení projektů, avšak toto chceme ověřit analýzou funkcionality pro projektové řízení. V závěru práce se také dočtete o případové studii a dalších zdrojích poukazující na EA.

1.1 Nejdůležitější pojmy Pro lepší pochopení této práce se pokusíme nejprve popsat jednotlivé pojmy, o kterých se budeme zmiňovat. Zároveň nastíníme, jakým způsobem pomáhají nástroje CASE při řízení projektů, jaký je jejich největší přínos a co by dobré CASE nástroje měli umět, aby splňovali náročné požadavky při vývoji moderních projektů IS/ICT

1.1.1 Projekt Řízená skupina činností vyvolaná za účelem dosažení předem určených cílů v daných termínech, ceně a s přidělenými zdroji. Mezi jeho základní vlastnosti patří: • • • • •

Unikátnost. Neopakovatelnost projektu je dána množinou charakteristických rysů a podmínek, ve kterých je projekt realizován. Přesné určení cílů a výstupů projektu. Dané termíny (realizace projektu ve stanoveném čase). Daná cena a omezené zdroje. Interdisciplinární charakter a dynamické projektové týmy složené z pracovníků, z nichž se řada na projektu podílí jen částí své kapacity a kromě práce na projektech musí plnit i své běžné úkoly.

1.1.2 Projekt IS/ICT Řízená skupina činností vyvolaná za účelem pořízení nebo adaptace (změny) IS/ICT, směřující k dosažení předem určených cílů. Projekt končí předáním produktů do užívání.

3


ZS 2007

1.1.3 Řízení projektů Plánování, organizování a vedení činností a zdrojů za účelem dosažení definovaných cílů. Nejčastěji se potýká s časovými a finančními omezeními a s omezeními zdrojů. Mezi hlavní činnosti řízení projektů patří zejména plánování, organizování, delegování, motivování, řízení času, zdrojů, financí a nákladů, komunikace, kvality, řízení změn, rizik a rezerv a dále hodnocení a kontrolování.

1.1.4 CASE nástroje (Computer Aided Software Engineering) Skupina nástrojů zaměřených na podporu vývoje informačních systémů. Jedná se o sadu nástrojů podporujících určité fáze vývoje, především pak analýzu a návrh. Jednotlivé nástroje CASE vycházejí z konkrétní metodologie a formou diagramů umožňující materializovat představu o zpracovávaném problému. Nejčastěji jsou nástroje CASE používány pro datové a funkční modelování.

1.2 CASE ve vývoji Jednou z nejdůležitějších vlastností CASE nástrojů je zajištění souvislostí, které člověk neumí mentálně pojmout. Samotné použití CASE nám ale nezaručí bezchybný a rychlý vývoj aplikace nebo systému. Stále je nutné mít na paměti, že se jedná pouze o jednu částečku zapadající do mozaiky vývoje, kde nezbytné je také řízení projektu, zavedení a plnění metodiky, využití odborníků na jednotlivé oblasti (analytik, návrhář, programátor, tester), použití a vyhodnocení metrik apod.

1.2.1 Druhy CASE nástrojů V dnešní době již existuje na trhu obrovské množství CASE nástrojů. Je to dáno nejen podporovanou metodikou různých společností, ale také tím, v jaké fázi vývoje je nástroj používán. CASE nástroje se využívají ve fázích specifikace požadavků, analýzy, návrhu, kódování a údržby. Podle životního cyklu vývoje software lze CASE nástroje rozdělit do následujících skupin: • •

• •

•

Pre CASE – podporují tvorbu globální strategie. Upper CASE – podporují plánování, specifikaci požadavků, modelování organizace podniku a globální analýzu IS. Hlavním úkolem nástroje je analýza organizace, zachycení procesů v organizaci, definice klíčových informačních toků a dokumentace zjištěných požadavků. Middle CASE – podporují podrobnou specifikaci požadavků a vlastní návrh systému. Tato třída CASE nástrojů je nejúspěšnější. Používají se pro podrobnou specifikaci požadavků, návrh systému, dokumentaci a vizualizaci systému. Dále CASE nástroje této kategorie obsahují systém správy dokumentů a konfigurace, systém pro vyhodnocování metrik, vývoj prototypů, návrh rozhraní. Mohou obsahovat také generátory obrazovkových formulářů a tiskových sestav a také generátory (kostry) definic dat. Tento druh CASE je jádrem komerčně dodávaných CASE systémů. Lower CASE – obsahují nástroje pro podporu kódování, testování, údržby a reverzního inženýrství. Integrovány jsou nástroje, jako jsou generátory kódu (mohou generovat jen kostru nebo až 75 procent výsledného kódu, kde programátor doplňuje většinou jen detaily). Dále pak jde o prostředky pro reverse engineering (rekonstrukce dokumentace a modelů z existujícího SW), prostředky pro sledování a vyhodnocení metrik, prostředky plánování a zjištění kvality SW (sběr informací o průběhu

4


•

ZS 2007

testování, vyhodnocení výsledků testů, řízení testování), pro správu konfigurace, prostředky sledování a vyhodnocování práce systému. Post CASE – podporuje organizační činnosti (zavedení, údržbu a rozvoj IS).

1.2.2 Komponenty CASE systémů Z toho, jaké jsou obecné funkce, vlastnosti CASE nástrojů a požadavky na ně vyplývá také to, z jakých komponent se tyto systémy skládají. Mezi důležité funkce a vlastnosti CASE patří: • • • • • • •

Konzistentní grafické ovládací prostředí (podle zásad tvorby GUI) – jednotný vzhled obrazovek, popisků, tlačítek, jednotné ovládání, použití symbolických ikon apod. Centrální databáze pro uchování informací o všech objektech IS (tímto způsobem se zaručí, že informace je použitelná v libovolném dalším kroku projektování) Prostředky verifikace konzistentnosti dat a podpora normalizace dat Textový editor pro popis jednotlivých objektů – pro účely technické a uživatelské dokumentace systému, možnost jejího přímého generování ze systému Možnost rychlého návrhu uživatelských obrazovek včetně simulace vstupů a výstupů (je vyžadováno pro prototyping) Generátor zdrojových programů (pro případy častého znovupoužití daného kódu) Export / import dat – pro práci s modely a dokumentací, které byly vytvořeny v jiných programech nebo jsou v jiných programech dále využívány a zpracovávány

1.2.3 Požadavky na CASE systémy Neměli bychom zapomínat, že CASE není samo o sobě metodologií, ale používá již zavedené metodologie. Nástroj CASE není ani náhradou programovacích jazyků (může generovat části kódu, ale programovací jazyky nenahrazuje). Užívání CASE automaticky nezlepší práci vedoucích pracovníků podniku nebo specialistů pro IT, CASE je nástroj, který může zlepšit produktivitu práce. Při volbě moderního CASE nástroje je třeba brát v úvahu několik kritérií. První kritérium se netýká samotného nástroje, ale spíše toho, že musí být vytvořeno povědomí pracovníků o použité metodice a také zvládnuta oblast řízení projektů. Nástroj CASE by měl zahrnovat mj. možnost procesního modelování. Výstupy CASE by měly umožňovat spolupráci s vývojovými prostředími a různými databázovými platformami. Nástroj CASE by měl podporovat moderní architektury včetně vícevrstvých. Měl by také podporovat komponentové a distribuované aplikace či aplikace založená na webových službách. Měl by také splňovat obecné podmínky otevřenosti, nezávislosti na hardware a výhodná je také podpora ze strany dodavatele. Pro standardní ohodnocení CASE nástroje lze využít normu IEEE, která uvádí několik desítek kritérií. Součástí hodnocení CASE je také kvalita podpory určité metodiky. Některé nástroje podporují strukturované i objektově orientované metodiky, většinou však buď strukturované (CASE 40 – Yourdan) nebo objektově orientované (Rational Rose – RUP). Pokud je již v organizaci zavedená nějaká metodika, pak námi vybíraný CASE nástroj by měl tuto metodiku podporovat. Vybraný CASE systém musí umožňovat podporu požadavků na modelování v reálném čase, modelování pomocí grafických nástrojů, správu konfigurací a verzí, správu projektu a pokud možno také správu dokumentů. Ve stručnosti by se hlavní požadavky na CASE dali shrnout v několika bodech:

5


ZS 2007

• Maximální jednoduchost a efektivita vývoje • Podpora objektového přístupu • Znovuvyužitelnost komponent • Podpora internetových a databázových technologií • Vývoj produktu nekončí jeho prodejem • Podpora týmového vývoje Produktivita dosažená pomocí CASE není okamžitě zřejmá – na počátku je nutné vykonat velmi mnoho práce, která není dlouho vidět. Užívání CASE nezaručí konzistenci výstupů. Když se dá stejný CASE dvěma systémovým analytikům, mohou dospět k dvěma trochu jiným výsledkům, ale ty závisí především na jejich přístupu, znalostech a postupech.

2 Ostatní CASE nástroje 2.1 In-Step In-Step je systém vyvinutý německou společností microTOOL GmbH. První verze tohoto software spatřila světlo světa v roce 1996. V současné době je tento nástroj vyvíjen a nabízen ve 2 funkčních modifikacích: • •

in-Step CoreProcess Edition in-Step PRINCE2 Edition

2.1.1 in-Step CoreProcess Edition Z původního názvu Project Management Edition byl učiněn posun k názvu in-Step CoreProcess Edition dle autorů díky rozšířené funkcionalitě, která přesahuje pouhé řízení projektů. Ta nyní zahrnuje všechny podstatné core procesy projektového vývoje: • • • • • • • • •

Řízení a plánování projektů – strukturování projektů do fází, iterací, aktivit a milníků. Software disponuje celou řadou předdefinovaných šablon. Řízení požadavků – možnost hierarchického strukturování Řízení změn Risk management Řízení kvality Procesní řízení Verzování projektu s automatickou aktualizací projektové historie Řízení a plánování zdrojů Proces akceptace a předání výsledků projektu

6


ZS 2007

Obrázek 1: Základní strukturování projektu ve fázi plánování in-Step CoreProcess Edition

Obrázek 2: Specifikace požadavků in-Step CoreProcess Edition

2.1.2 in-Step PRINCE2 Edition součástí této verze je implementovaná metodika PRINCE2 (viz. dále). Jaké jsou hlavní přínosy tohoto přístupu? Metodika PRINCE2 stanoví základní chronologické pořadí procesů a činností. Ty jsou zapracovány jako aktivity v in-Stepu a slouží jako šablony pro reálné aktivity z oblasti projektového řízení. PRINCE2 také specificky stanovuje a přiřazuje uživatelské role jednotlivým fázím projektu.

7


ZS 2007

Obrázek 3: Projektové řízení v in-Stepu: V každém okamžiku lze sledovat aktuality v projektu. Možnost uživatelů sledovat změny v lokální síti nebo na internetu

2.1.3 Metodika Prince2 PRojects IN a Controlled Environment) je metodika procesního managementu původem z VB (byla vyvinuta cca před 16 lety). Dnes tato metoda představuje velmi flexibilní a široce použitelný přístup, který se stal de facto standardem daleko za hranicemi Velké Británie. Základní body metodiky PRINCE2: • • • • • •

každý projekt má své komerční využití. Tedy je primárně určen pro řízení komerčních projektů v byznys oblasti zajišťuje organizační strukturu pro celý projektový tým jasně definuje oblasti odpovědnosti pro zákazníky a dodavatele v rámci projektové organizace Cíle a povolené odchylky jsou nastaveny prostřednictvím projektových parametrů. Jakékoliv překročení tolerančních limitů je okamžitě systémem detekováno a předáno k nápravě Větší důraz na výsledek než na procesy Strukturace projektu do stages

Pokud jde o kvalitu implementace metodiky PRINCE2 lze ji zhodnotit jako poměrně precizní. Přesto lze spatřit několik odchylek ( většinou v pozitivním smyslu ) zejména v oblasti: • • •

procesy SU (Starting Up), IP (Initiating) a CP (closing) se již dále v in-Stepu nerozpadají, neboť veškeré subaktivity jsou vykonávány pouze jednou osobou a to projektovým manažerem Issue management, risk management a lessons learned jsou příklady konceptů z PRINCE2, v in-Stepu jsou reprezentovány aktivitami neboli procesy zejména co se týče typů obchodních případů. Popisy typů jsou v in-Stepu uloženy pod položkou Specialist Products, nikoliv pod položkou Stage Plan, jak je psáno v PRINCE2 manuálu. In-Step nemá implementovány všechny typy obchodních případů definovaných v PRINCE2, ale obsahuje strukturované šablony pro každý typ. Tyto šablony, stejně jako všechny ostatní výsledky projektů, jsou ukládány ve všech svých verzích. Kdykoliv tedy bude třeba založit určitý konkrétní typ, který již byl založen, použije se příslušná šablona

8


ZS 2007

Obrázek 4: Plánování party dle metodiky PRINCE2 - rozdělení do stages

Výhodou In-Stepu je jeho do značné míry otevřená architektura díky níž lze celou řadu funkcionalit doprogramovat nebo stáhnout příslušné moduly z internetu. Další a možná největší výhodou softwaru in-Step je fakt, že základní verze obou modifikací (Personal Edition) jsou na stránkách společnosti MicroTool ke stažení zdarma a navíc časově neomezené!. Užití je omezeno na 1 pracovní stanici a 1 uživatele. Další podmínkou je přítomnost všech projektových dat na stejné stanici, na které byl software nainstalován (nelze je tedy síťově sdílet). Ale jinak nelze než takovýto přístup společnosti MicroTool ocenit.

2.2 Process Director (LBMS) Od doby posledního zpracování seminární práce na toto téma jsem nezaznamenal žádný výraznější vývojový posun, pokusím se jen stručně shrnout starší poznatky. Process Director je určen pro snadný a efektivní popis firemních procesů. Nástroj umožňuje snadno řídit procesy projektového charakteru v rámci týmu obousměrnou synchronizací s plánovačem MS Project a zároveň shromažďovat informace o skutečném průběhu projektů. Na základě takto získané zpětné vazby Process Director usnadňuje optimalizaci procesů. Process Director tedy pomáhá lépe definovat a řídit životní cyklus softwaru. Využívat ho můžou všichni od metodiků (definice procesních šablon), přes vedoucí projektů (zahájení projektů s aplikací předdefinovaných procesů; efektivní použití best practices na každém projektu; sledování a zaznamenávání metrik ze skutečného průběhu projektu) až po členy projektových týmů (pochopení procesů aktivit a úkolů, které mají vykonat; pro práci na úkolech strukturovaným a řízeným způsobem) Nástroj tedy slouží zejména k úpravám stávajících metodik (projektových postupů z oblasti IT) společnosti LBMS. Nástroj ukládá veškeré informace do XML repository, pro přístup k nim je pak využíván standardní internetový prohlížeč (obdobně jako k původním metodikám ve formátu HTML). U poslední verze nástroje je možné používat repository založenou na SQL Serveru 2005. Společně s nástrojem jsou dodávány projektové postupy pro komponentový vývoj aplikací.

2.2.1 Moduly Process Director Process Director obsahuje následující moduly pro jednotlivé členy týmu: • •

Knihovna metodik a osvědčený praktik - jedná se především o metodiku LBMS Development Method Process Studio - nástroj určený pro metodika umožňující tvorbu nových a modifikaci existujících postupů a metodik

9

Použití CASE pro řízení projektů IS/ICT • • •

ZS 2007

Process Browser - nástroj určený pro členy týmu umožňující interaktivní prohlížení metodik a projektů Process Workshop - nástroj určený pro vedoucí projektů umožňující vytvoření projektů na základě metodik, synchronizaci s harmonogramem v Microsoft Project a zadávání úkolů jednotlivým členům týmu Head-Up Display - nástroj pro členy týmu sloužící pro přebírání úkolů od vedoucího projektu a indikaci stavu práce a plnění těchto úkolů

Obrázek 5: Moduly Process Directoru

I zde tedy zůstalo vše při starém a dostupné jsou tedy pořád ty stejné moduly. Pro jejich bližší popis si dovoluji odkázat na stránky společnosti LBMS.

2.2.2 Metodika LBMS Project Management Vzhledem k tomu, že v seminárních pracích svých předchůdců jsem ve valné většině spatřoval především popis metodiky LBMS Development Method, která dle mého názoru souvisí více s vývojem SW než s projektovým řízením jako takovým, rozhodl jsem se nyní věnovat více prostoru této metodice. LBMS Project Management je metodika řízení projektů ve všech jeho etapách, jak to sami autoři na svém webu konstatují. Čerpá ze znalostní základny Project Management Body of Knowledge (PMBoK), jenž vydal Project Management Institute a samozřejmě z nezbytných zkušeností firmy LBMS s řízením projektů. Metodiky obsahuje jednoduché definice projektových činností, které pokrývají všechny fáze životního cyklu projektu (předprojektové fáze inicializace až po realizaci). Pro jednotlivé činnosti řízení projektu metodika obsahuje: • stručný popis cílů činnosti (check list); • podrobný popis činnosti; • seznam případných činností nižší úrovně; • vstupní produkty činnosti; • výstupní produkty činnosti včetně odkazu na jejich vzorové šablony; • techniky a nástroje, pomocí kterých se činnost realizuje; • odkazy na odpovídající procesy znalostní základny PMBoK. Mezi hlavní přínosy implementace metodiky LBMS Project Management patří: • • • • •

existence jednoznačných a transparentních pravidel činností od formulace projektu až po jeho uzavření; definice projektových šablon pro typické projekty organizace; zjednodušená tvorba harmonogramů; možnost údržby a rozvoje metodiky dle požadavků organizace; uchování zkušeností a poučení z dokončených projektů a jejich využití v příštích projektech.

10


ZS 2007

Metodika je dodávána standardně ve formátu HTML, který lze s výhodou umístit na intranet organizace a zajistit tak její snadnou dostupnost pro všechny členy projektových týmů. Navázané vzorové dokumenty jsou ve formátu Microsoft Word. Metodika je dodávána ve 2 nadstavbových verzích : • LBMS Advanced Project Management • LBMS Enterprise Project Management Tyto verze oproti verzi základní obsahují větší podporu ze strany LBMS ve fázi implementace metodiky. Spojení Process Directoru a metodiky LBMS Project Management je do jisté míry předvídáno. Autoři SW předpokládají využití Process Directoru pro plnohodnotnou údržbu metodiky, definování projektových postupů pro typické projekty organizace atd. Z informací na stránkách společnosti LBMS vyplývá možnost stažení softwaru. Požadavek je posuzován individuálně na základě specifikací ve vyplněném formuláři. Neměl jsem možnost si tuto domněnku ověřit, ale myslím, že pro studijní využití by byla společnost LBMS ochotna poskytnout software zdarma. Zde se omezím jen na stručné vyjmenování dle aktuálního stavu:

2.3 Rational (IBM) Na tomto poli se od data sepsání minulé práce (jaro 2007) také mnoho nového neurodilo. Rodina produktů IBM Rational zůstává nadále velice široká.

2.3.1 IBM Rational Suite Poskytuje plnou podporu pro projekt (životní cyklus) vývoje aplikace - analýzu, vývoj a testování, to vše za podpory týmové práce. Propojuje modelovací nástroj s řízením projektu vývoje. Obsahuje: • • •

IBM Rational Team Unifying Platform IBM Rational PurifyPlus for Windows – testování běhu aplikací IBM Rational Rose Enterprise – CASE modelovací nástroj podporující UML a řadu vývojových prostředí • IBM Rational Robot – testování aplikaci Centrem zájmu zde bude s ohledem na řízení projektů IBM Rational Team Unifying Platform a jeho součásti IBM Rational Method Composer, postavené na Rational Unified Process (RUP) a IBM Rational ProjectConsole.

2.3.2 Rational Team Unifying Platform Jeho hlavní součásti s ohledem na řízení projektů jsou IBM Rational Method Composer, IBM Rational Project Console a IBM Rational SoDA

2.3.3 IBM Rational Method Composer RMC slouží pro sestavování, plánová a zejména správu projektů (nebo metod pokud použijeme terminologii IBM). Běží na opensource technologii Eclipse. Jejím základem je metodika RUP, kterou lze právě zde přizpůsobovat konkrétnímu projektu. Takto přizpůsobené procesy lze exportovat do aplikace IBM Rational Portfolio Manager a tam tento na míru šitý projekt spravovat. Samozřejmostí jsou přednastavené „balíčky“ dle charakteru projektu (malý/velký apod.) či oblastí zájmu

11


ZS 2007

2.3.4 IBM Rational Project Console Produkt Rational ProjectConsole poskytuje vedoucím i členům týmu přístup ke kompletním informacím o projektu, a to prostřednictvím jednotného rozhraní webových stránek.

2.3.5 IBM Rational SoDA Automatizuje projektovou dokumentaci k softwaru v rámci celého životního cyklu projektu.

2.3.6 Metodika Rational Unified Process Jde o soubor tzv. „best practices“, podobně jako např. COBIT. Zaměřuje se ale pouze na oblast návrhu, vývoje a nasazení podnikových informačních systémů. Osvědčené praktiky přináší RUP ve formě do detailů popsaných procesů. Nasazení RUP probíhá pomocí softwarových nástrojů pro projektové řízení a plánování (Rational Method Composer). Přidělený projektový manažer sestaví nový proces, přičemž využívá buď komponenty nebo celé standardní procesy z RUP. Po sestavení procesu provede softwarově jeho předběžné naplánování, a to včetně milníků, potřebných zdrojů a tak podobně. Tolik velice stručně k produktům rodiny Rational, jejichž bližší popis je k dispozici na stránkách IBM.

2.4 Portfolio produktů společnosti Borland Společnost Borland se prezentuje svou schopností pokrýt celý životní cyklus softwarového vývoje a potažmo projektu svými aplikačními nástroji. Rozpětí sahá od projektového plánování (Borland Tempo – viz dále), přes definici návrh a vývoj (Caliber,Together,JBuilder) až po řízení včetně kvality (Star Team a Silk a Core SDP). Přímý vztah k řízení projektů má zejména Tempo a StarTeam a částečně i Core SDP.

2.4.1 Borland Tempo Borland Tempo obsahuje systém podnikového řízení projektů v oblasti IT, který podporuje účinné a koordinované provádění více vzájemně závislých programů a projektů.

Obrázek 6: Borland Tempo - Rozpis prací na projektu

Systém by měl dle specifikací výrobce pokrývat následující funkční oblasti: •

Řízení programů Tempo obsahuje všechny nástroje nezbytné k tomu, aby bylo možno projekty řídit současně jak na úrovni programu, tak na úrovni projektů. Řízení programu umožňuje seskupovat IT projekty a skládat je do programů pomocí stanovených metod jak pro vedoucí výrobních programů, tak pro manažery projektů. • Projektové plánování

12


ZS 2007

Hierarchická skladba rozpisu prací na základě úloh z hlediska projektového plánování na vhodné úrovni podrobností. Schopnosti systému zahrnují automatické termínové plánování na základě závislostí, šablony úloh, dávkové změny úloh a integraci řízení zdrojů s produktem Microsoft Project. • Sledování projektů Jakmile se projekty rozběhnou, systém poskytuje mechanismy sledování postupu prací a jejich řízení. Tyto schopnosti obsahují automaticky spouštěné výzvy k podávání hlášení o postupu prací, výstražná hlášení o vypršení úloh, oznámení členům týmu a automaticky vypočtené "zdraví" úloh, a to na základě projektových termínovaných specifikací týkajících se rozsahu, nákladů a časového harmonogramu.

2.4.2 Borland StarTeam Software aktuálně nabízený ve verzi 2005 je určen pro správu konfigurací a změn software navržených tak, aby splňovaly potřeby všech vývojových týmů bez ohledu na velikost, geografické rozmístění a styl práce. Dodáván je ve verzích Standard, Enterprise a Enterprise Advantage

2.4.3 Borland Core SDP Borland Core SDP je součástí vize SDO (Software Delivery Optimization - optimalizace dodávaní software) a nabízí integrovanou platformu pro řízení životního cyklu aplikací, která je diferencována podle jednotlivých rolí účastníků vývojového procesu a umožňuje dodržovat stanovené procesy v organizacích. Role stanovené v rámci Core SDP jsou: • • • •

Core Analyst Core Architekt Core Developer Core Tester

Obrázek 7: ALM v Borland Core SDP

2.4.4 All Fusion Process Management Suite Zde se od data sepsání poslední seminárky odehrála poměrně výrazná změna. Balík společnosti CA AllFusion Process Management Suite přestala tato společnost nabízet. Jediná 13


ZS 2007

zmínka, kterou jsem objevil byla v sekci technické podpory pro stávající zákazníky. Při projití celého portfolia produktů společnosti CA se mi nepodařilo vypátrat osud tohoto balíku včetně všech jeho součástí. Možné téma pro další semestrální práci?

3 Informace o produktu Enterprise Architect 7.0 Enterprise Architect 7.0 je nástroj firmy Sparx Systems pro vývoj a údržbu SW umožňující modelovat podle standardu UML 2.1. Poskytuje dobrou vizualizaci a funkce pro spolupráci větších týmů. V médiích je vyzdvihována především vysoká intuitivnost ovládání. Cena EA je závislá na zakoupené licenci a pohybuje se od 135$ /lic. po 335$ /lic. • Corporate Edition Floating License • Corporate Edition • Professional Edition • Desktop Edition Velice dobrá je uživatelská podpora formou emailu, diskusních fór, ale především možností konzultací a školením, které pro Českou republiku zajišťuje firma Ability Development (www.abilitydev.com)

3.1 Stránky výrobce – firmy Sparx Systems Nejdůležitější zdroj informací představují stránky výrobce, firmy Sparx Systems. Zde se dá najít o produktu snad naprosto všechno. Stránka je pochopitelně v angličtině. Nalezneme zde možnost zakoupení produktu, zjištění novinek, případová studie, diskusní fórum a mnohé další možnosti. Webová adresa je: http://www.sparxsystems.com/.

Obrázek 8: Webové stránky společnosti Sparx Systems

14


ZS 2007

3.2 Případová studie Na webových stránkách společnosti SPRAX se nachází případová studie o využití Enterprise Architectu. Studie se zabývá vytvořením systému GeoSciML (GeoScience Markup Language). Jde o systém sloužící k reprezentaci, sdílení a výměně geografických dat a informací mezi organizacemi používající různé databáze a software. Jeho vývoj byl úspěšný také právě díky nástroji Enterprise Architect. Prvním krokem bylo zvolit vhodný nástroj pro vývoj systému. Byl zvolen právě Enterprise Architect, neboť nejlépe vyhovoval potřebám modelování v daném projektu. Umožňoval sdílení modelů a spolupráci lidí na projektu. Díky dobře nastavenému konfiguračnímu managementu lze EA přizpůsobit pro různá prostředí a tak je možné, aby na stejném projektu mohli pracovat lidé z různých oblastí a časových pásem. Studie je k dispozici na http://www.sparxsystems.com/downloads/pdf/GeoSciMLEACaseStudy.pdf

4 Zhodnocení práce s nástrojem Enterprise Architect 7.0 4.1 Přehled Pokud v Enterprise Architectu vytváříme modely, můžeme u těchto modelů také využít možnost projektového řízení, které Enteprise Architect podporuje. Model se tak vlastně stává projektem a jednotlivé prvky modelu/projektu lze řídit pomocí nástrojů projektového řízení Enterprise Architectu. Projektoví manažeři mohou Enterprise Architect používat k odhadu velikosti projektu, měření rizik a pracnosti a k přiřazování zdrojů činnostem. Enterprise Architect také poskytuje podporu pro změnové řízení a údržbu. V následujícíh kapitolách bude uveden přehled základní funkcionality, kterou Enterprise Architect nabízí pro podporu řízení projektů.

4.2 Resource management – řízení zdrojů Řízení zdrojů v Enterprise Architectu umožňuje definici pracovníků projektu. Pracovníkům projektu je možné přiřazovat pracovní role a dále úkoly, které pracovníci v rámci projektu plní. Enteprpise Architect dále umožňuje sledovat práci, kterou pracovníci na projektu odvedou (sledování času, který na projektu stráví) a odhadovat zbývající pracnost.

4.2.1 Přiřazení zdrojů Pokud máme definovány prvky modelu, můžeme jim přiřadit zdroje a specifikovat úkoly, které na projektu plní.

15


ZS 2007

Obrázek 9: Přiřazení činnosti zdroji

Při přiřazení zdroje k projektu je mimo jiné možné sledovat následující hodnoty: • Očekávaná pracnost • Skutečná pracnost • Začátek a konec úkolu • Míra (procento) dokončení úkolu Ze zadaných položek můžeme následně generovat reporty. Reporty lze různě upravovat. Můžeme například vytvořit report pro konkrétní prvky projektu, jednotlivé zaměstnance (zdroje) nebo pro konkrétní datum.

Obrázek 10: Tvorba reportů pro zdroje

4.2.2 Správa rizik, metrik a práce Jednotlivým prvkům projektu je také možné přiřadit rizika a metriky a dále můžeme sledovat práci na této části projektu. V případě sledované práce, se jedná o práci, která není zachycena v rámci přiřazení pracovníků na prvek projektu. V rámci správy projektu můžeme definovat rizika a metriky, které následně můžeme přiřazovat všem prvkům projektu. Enterprise Architect ve verzi 7.0 nepodporuje tvorbu detailních reportů nad riziky a metrikami, ale lze k tomu využít externí nástroje.

4.3 Maintenance – Údržba Enterprise Architect poskytuje nástroje pomocí kterých je možné spravovat a udržovat vytvořený model a jeho prvky. Tato kapitola se zabývá pouze správu jednotlivých prvků projektu, nikoli projektu jako celku. Pro konkrétní prvky modelu jsou v rámci údržby možné následující události: • •

Defekty Změny

16

Použití CASE pro řízení projektů IS/ICT • •

ZS 2007

Problémy Úkoly

Defekt je chyba v prvku modelu. Znamená, že prvek nesplňuje požadavky, které jsou na něj kladeny. Změny jsou definovány jako změny v požadavcích na vlastnosti prvku. Změna vyžaduje následnou akci v podobě předělání konkrétního prvku projektu tak, aby splňoval nové požadavky. Problém (issue) je faktor nebo riziko, které může ovlivnit projekt, respektive konkrétní prvek modelu. Úkoly pak slouží k zaznamenávání práce, která je v rámci údržby na prvcích projektu prováděna. Může se jednat například o práci vyvolanou změnou požadavků na prvek, nebo práci na odstranění defektu.

Obrázek 11: Panel pro údržbu prvků projektu

Celý proces údržby je možné zahrnout i do projektové dokumentace, kterou Enterprise Architect generuje. Proces údržby je taktéž možné zahrnout do zobrazení modelů, takže například u class diagramu se u jednotlivých tříd mohou zobrazovat krom atributů a funkcí také poznámky k údržbě.

4.4 1.4

Seznam úkolů projektu

Tato funkcionalita Enterprise Architactu slouží k zaznamenávání úkolů, které nejsou zachyceny jinde v projektu, nebo v jednotlivých částech modelu. Můžeme zde zaznamenávat například pracovní schůzky, meetingy a porady, které se k projektu vztahují. Nebo zde můžeme zaznamenávat nové požadavky na projekt a části modelu.

Obrázek 12: Přehled úkolů projektu

U jednotlivých úkolů specifikujeme název a popis úkolu. Majitele požadavku (tvůrce úkolu), osobu zodpovědnou za splnění úkolu, stav úkolu a procento jeho zapracování, prioritu atd. Seznam úkolů projektu se vztahuje k celému projektu, nikoli k jeho konkrétním prvkům (jako tomu bylo například v údržbě).

17


ZS 2007

4.5 Terminologický slovník projektu Terminologický slovník slouží k vytvoření seznamu výrazů, které se v projektu objevují a jejich vysvětlení. Hlavní výhodou je, že slovník lze exportovat jednak samostatně a jednak jako součást dokumentace projektu. Sparx Systems doporučují slovník přikládat k seznamu požadavků na projekt nebo k funkční specifikaci.

Obrázek 13: Slovník projektu

4.6 Metriky a odhady Odhad projektu je proces, kterým zjišťujeme, kolik času a úsilí je zapotřebí k dosažení řešení projektu. EA obsahuje metriky užití jako prostředek k hrubému měření komplexnosti systému a ke zjištění, kolik úsilí je ještě třeba vynaložit k implementaci modelu a lze tak snadno vytvořit časové měřítko. K tomu, aby bylo možné provádět přesné odhady, se provádí kalibrace, kterou je možno rozdělit do několika skupin podle faktorů: • •

ovlivňující technickou komplexnost ovlivňující komplexnost prostředí

Po zadání všech potřebných údajů už lze odhadovat pracnost projektu. V dialogovém okně Faktory technické komplexnosti lze přidávat a odebírat jednotlivé faktory. Okno obsahuje seznam většiny faktorů, které je důležité v tomto směru sledovat. Obrázek 1 ukazuje zmíněné dialogové okno včetně vah přidělených každému typu faktoru a hodnoty, které říkají, jaký vliv má položka na projekt.

18


ZS 2007

Obrázek 14: Dialogové okno Faktory technické komplexnosti

Stejným způsobem lze přistupovat k nastavení faktorů zabývající se prostředím projektů. Dialogové okno, váhy i hodnoty se nastavují stejným způsobem, pouze se liší seznam faktorů.

4.6.1 Odhad velikosti projektu EA využívá jednoduchou techniku odhadu z Use Case modelu. Nástroj lze používat až po zadání parametrů z několika dokončených projektů. Výchozí hodnoty jsou z počátku zavádějící a je třeba program nejdříve přizpůsobit. Obrázek 14 ukazuje dialog Use Case pro nastavení faktorů k odhadu velikosti projektu.

19


ZS 2007

Obrázek 15

4.7 Testování EA umožňuje vytvářet skripty pro testování. Obvykle se vytvářejí „unit“ testy pro elementy, které jsou ve vývoji jako např. třídy nebo komponenty. „Integration“ testy slouží k ověření, zda funguje vzájemné propojení komponentů. Pomocí „System“ testů zjišťujeme zda systém jako celek splňuje business požadavky. „Acceptance“ testy testují uspokojení uživatelů. Posledním testem z řady je „scenario“ test - slouží k ověření funkcionality aplikací. Okno testování zajišťuje pohodlnou administraci testů. Seznam testů se zobrazuje do okna viz. obrázek 15.

Obrázek 16

Detaily testů se pak upravují v okně na obr. 16.

20


ZS 2007

Obrázek 17

Velice pohodlné je v EA generování dokumentace a výsledků testů. EA podporuje formát výstupu RTF.

4.8 Řízení změn a poruch Na úvod definuji změny a poruchy, což jsou strukturované poznámky, přičemž v EA změnami rozumíme změny požadavků na systém. Poruchy jsou pak selhání prvků, které mají za následek nesplnění požadavků projektu. Změny a poruchy lze v EA vyjadřovat pomocí UML diagramů a jsou spojeny vazbou „realizace“, „závislost“, „agregace“ a dalšími vztahy tak, aby byly zachyceny vzájemné závislosti. K řešení změn a poruch se využívá dialogu, kde je možné tyto přiřazovat příslušným lidem (viz obr. 17).

Obrázek 18

21


ZS 2007

4.9 Problémy projektu a modelů Jakékoliv problémy, které vzniknou v průběhu projektu mohou být a měly by být zaznamenávány včetně popisu, data, odpovědné osoby a stavu, ve kterém se nacházejí. Stejně jako v jiných modulech EA lze generovat dokumentaci ve formátu RTF. Dialogové okno je zobrazeno na obr. 18.

Obrázek 19

4.10 Hodnocení nástroje Enterprise Architect S produktem se pracuje poměrně intuitivně. Navíc je přiložena velmi kvalitní nápověda, která je k dispozici hned v několika formátech (html, pdf nebo tradiční windows help). Hlavní zaměření Enterprise Architectu směřuje k modelování. Funkcionalita pro podporu projektového řízení je doplňková a tudíž neposkytuje tak rozsáhlé možnosti, jako specializované produkty pro řízení projektů typu Microsoft Project. Na druhou stranu funkcionalita obsažená v Enterprise Architectu postačuje pro běžné operativní řízení projektů. Poskytuje základní funkce jako je sledování činností a zdrojů projektu nebo měření a odhad pracnosti projektu a tudíž dob trvání. Co lze Enteprise Architectu vytknou jsou drobnosti v uživatelském rozhraní a chybějící Gantovy diagramy. Zejména občas poněkud nestandardní chování. Například obrazovka na otevírání projektů může některé uživatele mást. Nicméně zvyknout si na tyto drobné zvláštnosti nebude uživatelům, kteří s tímto nástrojem budou trávit desítky hodin práce, činit problém. Při výběru nástrojů, které plní stejnou funkci jako Enterprise Architect budou rozhodující spíše modelovací možnosti, které jsme v této práci nehodnotili. Z hlediska podpory řízení projektů je však Enterprise Architect na slabší úrovni.

22


ZS 2007

5 Zdroje [1] EA Version 7.0 User Guide [online]. Sparx Systems, c1998-2007 [cit. 2007-12-15]. Dostupný z WWW: . [2] Product List [online]. c2007 [cit. .

2007-12-12].

Dostupný

z

WWW:

[3] CASE a zbytek světa [online]. Databázový svět, c2004 [cit. 2007-11-30]. Dostupný z WWW: . [4] Process Director [online]. LBMS, c2002-2007 [cit. 2007-12-10]. Dostupný z WWW: . [5] Zrychlujeme životní cyklus aplikací [online]. Borland Software Corporation, c1994-2005 [cit. 2007-12-09]. Dostupný z WWW: . [6] In-Step – die Software für prozessbasiertes Projektmanagement in der System- und Softwareentwicklung [online]. Berlin : MicroTOOL GmbH, c2001-2007 , 27. November 2007 Dostupný z WWW: [cit. 2007-11-29]. Text v němčině. . [7] Case Study : Developing the GeoSciML interoperability standard with Enterprise Architect [online]. Sparx Systems, c2007 [cit. 2007-12-10]. Dostupný z WWW: .

23

ICT (Vazba na nástroje řízení projektů, trendy a možnosti)

Recommend Documents