Případy spolupráce metodik RUP a ITIL
Již dlouho jsem byl konfrontován názory, že ITIL se v praxi bije s jinými metodikami. A jelikž tento názor nezastávám, tak jsem svou semestrální práci zaměřil na případy spolupráce ITILu s RUPem. Hned z počátku se nám nabízí krásné srovnání vývoje metodik v čase, které je důkazem, že tyto dvě metodiky by měli spolupracovat a navzájem se doplňovat. Obrovský krok byl udělán ze strany vývojářů metodiky ITIL vydáním třetí verze V3.
Životní cyklus Service Managementu inspirovaný RUPem
Již z předchozích verzí ITILu se nabízí myšlenka, že ITIL a RUP by měli společně v některých případech spolupracovat nebo se doplňovat. Nikdy si ale tyto metodiky nebyly tak blízko, jako teď při vydání ITILu V3. Na obrázku je zachycený životní cyklus Řízení služeb (SM). Ten jednoznačně vychází z životního cyklu RUPu. Jsou zde dokonce náznaky inkrementačního (přírůstkového) procesu, který je popsán v tabulce.
Metodika ITIL V3 ještě popisuje další krok a tím je Neustálé zlepšování služeb směrem k zákazníkovi.
Konfigurační databáze (CMDB) ve spolupráci s UML2
Konfigurační databáze slouží k uchování všech dat a informací, které se vztahují k dané službě. V praxi, hlavně při práci na velkých projektech je velice těžké udržovat CMDB stále aktualizovanou. K tomu nám zde pomáhá nástroj ITILu zvaný Configuration Management.
Konfigurační databáze je jedním z hlavních demonstrativních propojení ITILu a RUPu (a jeho nástroje na modelování aplikací UML2). Propojení je v celku jednoduché. ITIL popisuje jak taková konfigurační databáze má vypadat, co má být její náplní a jak mají být zde data aktualizována. K tomu slouží umiňovaný Configuration Management. RUP dodává náplň této databáze. Tou jsou artefakty jazyka UML2 (dokumenty, diagramy, kódy, aplikace).
Při správném vedení a aktualizování konfigurační databáze se získává perfektní přehled nad danou službou. Slouží jako zdroj všech informací pro danou službu. Následně je využívána Change Control Boardem ke specifikování vzniklých incidentů.
Užití metodiky RUP v Change Managementu a Problem Managementu
Metodika RUP nám již bohužel neříká nic o tom jak následně provozovat aplikace. Tímto problémem se naopak poměrně do hloubky zabývá ITIL. Po vydání první verze aplikace nastává fáze provozu aplikace. Při provozu je nutné garantovat podporu, která by měla mít určitou strukturu (pokud se jedná o velkou aplikaci, kterou užívá několik stovek uživatelů, pak by ta struktura měla být velice precizně propracovaná). Bude totiž velice často docházet z nahlášení defektů ze strany uživatelů.
K zachycení těchto hlášení o nefunkčnosti nebo snížení funkčnosti slouží Service Desk. Ten dále předává incident ke specifikování do Cange Control Boardu. Tam dochází ke specifikaci incidentu a jeho rozpadu na určité problémy. Každý problém je následně řešen jako malý projekt. A zde jsou využívána metodika RUP pro řešení těchto problémů. Velice zestručněně (dle závažnosti problému) prochází problém všemi fázemi, o kterých mluví RUP. Na obrázku je popsán životní cyklus incidentu.
Stejně tak je tomu u Change Managementu. Postupem času bude vyžadována, ať už ze strany zákazníka nebo ze strany poskytovatele služby, určitá aktualizace v podobě změnění nebo přidání některých funkcí do aplikace. Může se také stát že bude vyžadována změna v architektuře služby (aplikace). Pak se Change Management při aktualizování jednotlivých částí aplikace řídí metodikou RUP a přistupuje ke každé jednotlivé části jako k projektu (zde samozřejmě opět záleží na velikosti a závažnosti každé jednotky).
Vývojový tým a Application Managament
Application Management je jednou z nejdynamičtěji se rozšiřující se částí celého frameworku ITIL. Application Management sleduje aplikace od jejich počátku až po jejich provoz a aktualizace. Jedná se o velice efektivní správu aplikací, kde vývoj a následné čerpání informací vycházejí právě z RUPu. Plné popsání funkcí Application Managementu však přesahuje tuto práci.
Závěr
Tento článek je pouze výsledkem mého bádání. Pokud by měl někdo zájem o přečtení celé práce (kde jsou navíc blíže popsány obě metodiky) můžete si jej stáhnout ZDE.
Zdroje
-
Související články na blogu jelinek
-
Nasazení ITILu 29. 2. 2008 16:36
-
Metodika ITIL: vstříc lepším zítřkům 6. 12. 2007 19:51
-
-
Související články na ostatních blozích
-
Co je špatně na Androidu? 28. 12. 2013 12:34
-
Ubuntu 13.04 Raring Ringtail 23. 3. 2013 18:48
-
Microsoft Most Voluable Professional (MVP) - stante sa trotlom diskusných skupín 27. 10. 2011 15:30
-
Windows Phone 7 - liga zúfalcov 19. 2. 2011 20:36
-
Variabilita - problém čítačiek elektronických kníh 16. 2. 2011 17:10
-
Jakub Nešetřil: Hackathon doporučuji nejen programátorům, ale i firmám a univerzitám 9. 11. 2010 9:09
-
-
dvh (neregistrovaný)
- Velmi zly uvod clanku. Clovek musi precitat cely clanok aby vedel o com to je. To je zle. Stacilo by pri prvom spomenuti skratky ITIL do zatvoky uviest: ITIL (sada konceptov a postupov na ...)
- suhlasim [1], je to cisty bullshit, k dokonalosti clanku chybaju uz len predtlacene karty na bullshit bingo
-
Samuel BWPOW Kupka (neregistrovaný)
[2] Presne to iste mi napadlo pri citani :) Idealny material pre bullshit bingo. (Raz sme ho skusali na prednaske cloveka z HR a ten blazon, co vyhral, to dokonca vykrikol nahlas. U vedenia sa to zial nestretlo s pochopenim.)
[4] Nie je to celkom tak. Su rozne mechanizmy a zalezi len na spolocnosti, ci viac investuje do schopnych ludi alebo moneyzerov. Ak existuje dobry a stabilny team starajuci sa o infrastrukturu (alebo o rozvoj projektov - vyberte si sferu IT podla chuti), tak postacia aj velmi jednoduche mechanizmy na to, aby cely system fungoval velmi efektivne a presne.
-
oja (neregistrovaný)
Dik, pro mne clanek informacni hodnotu ma.
Jinak jsem nazoru, ze kazda metodika je o lidech, kteri ji zavadeji a kteri ji pouzivaji. Pokud jednaji v souladu, ma to prinos, jinak je to hruza.
Ale spolehat se na tym chytrych lidi, kteri vedi co maji delat a nepotrebuji pravidla je jeste vetsi hruza. Uz jsem to zazil mnohokrat a dnes jsem vdecny i za jakz takz fungujici procesy(buzeraci) nez za uplne bezvladi. -
mmm (neregistrovaný)
[5] NESMYSL. To si dovede dohodnout par lidi. Ale takoveto nastroje je nezbyten pouzit kdyz chceste aby se dohodlo vic lidi. Exituje poucka, ze kdyz si ti lide nemuzou sednout u kafe a vysvetlit si jak to myslej, tak se to holt musi nejakejma formalnima nastrojema popsat. 500 lidi si ke kafi nesedne. Stejne tak kdyz se vam na to ta vase dobre sehrana parta vykasle a zanecha po sobe nejake hucici stroje a par disket piktogramy pripominajiciho zdrojoveho kodu, tak ti co prijdou po nich mohou zacit stavet na zelene louce. Jak s organizaci procesu, tak ve vyvoji sfotware. Mam s tim sve zkusenosti.
-
Palo (neregistrovaný)
[9] samozrejme. Chlapec si mysli ze velka firma je 20 ITckarov. Keby videl dislokacne umiestnene servre, 5 roznych OS, 15 backendovych systemov, 4 testovacie prostredia, zalohy, archivy, security, reporty, uzavierky, 24 hodinovu prevadzku, ... . A do toho kazdodenne valiace sa zmeny, SW, konfiguracie a cele to udrziavat s dostupnostou 99.9%, to iste zvladnete jeden dobry a stabilny team velmi jednoduchymi mechanizmami.
Chalan pozral vela vtipnej kase :-). -
jelinek (neregistrovaný)
[9], [10],
bohužel je někdy těžké vyhlédnout za okraj pískoviště a vidět svět správně
(tímhle nemyslím nic urážlivě ani arogantně - jen metafora)říkám to tu pokaždé. prostě některé věci bez pořádku nejdou řešit. ale stále se najdou lidé, kteří nedokážou pochopit, že když je na nějakou službu (správa HW nebo SW nebo dokonce obojího) denně nahlášeno okolo 30-70 requestů (incidentů, požadavků na změnu, atd.) na jedno řešení. A co když jich pak je 5. Velice bych pak chtěl vidět sehraný team (který ještě do všeho bude bude jiný SW (nebo HW řešení) vyvíjet).
good luck
-
Piko (neregistrovaný)
moja skusenost je, ze vacsinou sa tymito vecami (=metodiky, ...) zaoberaju ludia, ktori nemaju dostatocne kvalitny background v IT. A tak sa daju na tzv. "menezment procesov a projektov". Zial ani v tejto oblasti sa nestanu ziadnymi "hviezdami" a tak team, ktory takto riadia (a cely SW vyvoj, ktory takto riadia) ide od buka do buka. Jedine pozitivum je to ze z tychto ludi uz nie su vyvojari, systemaci, analytici, testeri ale "menezeri" (a to uz je ine kafe!)
