Spolupráce metodik ITIL a RUP Jan Jelínek
Obsah Úvod...3 Seznámení se s metodikami ITIL a (R)UP...4 Metodika ITIL (IT infrastructure Library)...4 Service Design...5 Service Operation...5 Ostatní nástroje ITILu...6 Konfigurační databáze (CMDB Configuration Management Database)...6 Change Control Board (CCB)...7 Metodika (R)UP ((Rational) Unified Process)...8 Rozdíl mezi RUP a UP...8 Popis vývoje podle metodiky RUP...8 RUP a UML2...10 Případy spolupráce metodik RUP a ITIL...11 Životní cyklus Service Managementu inspirovaný RUPem...11 Konfigurační databáze (CMDB) ve spolupráci s UML2...12 Užití metodiky RUP v Change Managementu a Problem Managementu...12 Vývojový tým a Application Managament...13 Nasazení ITILu...14 Malá společnost do 25-ti zaměstnanců...14 Středně velká společnost do 200 zaměstnanců...15 Velká společnost nad 200 zaměstnanců...17 Závěr...18 Zdroje:...19 Použitá literatura...19 Použité obrázky...19
Úvod Účelem této práce je najití možností spolupráce a propojení metodik ITIL a (R)UP. Obě metodiky jsou zaměřeny ať už na vývoj nebo na správu SW. Ikdyž se na první pohled zdá, že se nepropojují (všeobecné mínění praví o tom, že metodika (R)UP se věnuje pouze návrhu SW a ITIL zajišťuje správu SW vyjímaje návrhu). Pravdou však je, že se obě metodiky v několika případech prolínají nebo podporují. A právě na tyto případy se zaměří tato práce. První část poslouží jako úvod do obou metodik. V druhá část se bude věnovat jednotlivým případům spolupráce.
Seznámení se s metodikami ITIL a (R)UP Metodika ITIL (IT infrastructure Library) Metodika ITIL prodělala v posledních letech velice dramatický vývoj (který pro nás není zas tak zajímavý) zakončený vydáním třetí verze V3. Zde nastal obrovský posun od zkostnatělé metodiky řešící osamocené celky řízení k téměř komplexnímu řešení celého životního cyklu služeb v IT, který je popsán na Obrázku 1. Jednou z nejdůležitějších věcí při správě IT je řízení, produkování a distribuování informací. Hlavní myšlenkou metodiky ITIL je navržení struktury toku informací (potažmo práce) za účelem maximálního zefektivnění práce a zkvalitnění služeb zákazníkovi. Obrázek 1: Životní cyklus služeb. Použito z An Introductory Overview of ITIL V3
Jedním z nejdůležitějších pojmů v ITILu je Service Management (řízení služeb). Řízení služeb je velice důležité pokud zákazníkovi nedodáváte pouze produkt (např. webová prezentace). Pokud zákazníkovy dodáváte službu jedná se nejen o vývoj, ale také o zprávu a podporu. V některých případech se jedná o dodání kompletního HW a SW řešení společně s podporou (v tomto případě se podporou nemíní jen HotLine). ITIL nám pomáhá jak služby formulovat, navrhovat, provozovat a zdokonalovat. Pro tuto práci budou nejdůležitější dvě části ITILu. První bude Service Design (návrh služby) a druhou Service Operation (provoz služby). Tyto dvě části (společně s Service Transition) tvoří jádro celého ITILu. Service Design Zde ITIL definuje nástroje na návrh služeb: Service Level Management řeší smluvní ujednání se zákazníkem, výstupem SLM jsou Service Level Agreements (SLA), o kterých se zde ještě zmíníme Capacity Management zajišťuje IT kapacity pro projekt Avialability Management zajišťuje a řídí zdroje potřebné pro jednotlivé části projektu nebo pro celý projekt ITIL definuje několik dalších nástrojů pro návrh služeb, ale většinou pro nás nejsou tak důležité. Důležité je však si uvědomit, že v této části vzniká definice služby a její návrh. Velice důležité také je že v této fázi je při návrhu SW (jakožto jedné z možných částí služby) používána metodika (R)UP. Service Operation Hlavním cílem této části správy služby je dostání všem smluvním dohodám o správě a podpoře služby. Tato část je jednou z na organizaci nejnáročnějších a také nejopomíjenějších částí celého procesu správy služeb. ITIL zde definuje několik nástrojů řízení, které dohromady vytvářejí strukturu potřebnou pro spravování služeb. Service Desk jedná se útvar (oddělení, jednotlivec), který má na starosti kontakt se zákazníkem (povětšinou s uživateli). Slouží jako sběrna incidentů a požadavků na změnu. Incident Management zajišťuje co možná nejrychlejší řešení incidentů (Incident je neplánované narušení nebo snížení kvality služby). Problem Management - zajišťuje co možná nejrychlejší řešení problémů (Problém je
specifickou částí incidentu). Technical Management zahrnuje všechny technické pracovníky působící na projektu v oblasti implementace Application Management zahrnuje všechny pracovníky podílejí se na provozu aplikace. Na rozdíl od Technichical Managementu je Application Management zaměřený na pracovníky spravující spíše software než infrastrukturu. Pracovníci také velice často jsou těmi, kteří se podíleli na vývoji softwaru samotného. V této práci se budeme věnovat Application Managementu ještě jednou, jelikož je to jedna z částí, která velice souvisí s metodikou (R)UP. Ostatní nástroje ITILu Tyto nástroje jsou většinou užívány při provozování služeb, ale vyskytují se i v jiných částech životního cyklu. Jsou to většinou nástroje přímo napojené na software. Jedná se především o Change a Release Management. Change Management je zodpovědný za veškeré změny ve službě. Úzce spolupracuje s Release Managementem, Avialability Managementem a konfigurační databází. Change Managemet Release Management Availability Management Knfigurační databáze Release Management zajišťuje vydávání nových verzí SW nebo HW Konf igurační databáze (CMDB Conf iguration Management Database) CMDB je databáze všech položek (CI configuration item), nastavení a architektury služby. Konfigurační databáze je vedena z důvodu rychlého dohledání nastavení služby. S konfigurační databází komunikují téměř všechny složky a nástroje ITILu. Jsou zde uložena všechna data o službě od SLA až po release notes (poznámky k vydání nové verze). Z našeho pohledu spolupráce ITILu s (R)UPem je konfigurační databáze jedním z nejzajímavějších
nástrojů, jelikož v mnoha ohledech probíhá propojení ITILu s (R)UPem právě přes konfigurační databázi. Change Control Board (CCB) Change Control Board je jednotka (oddělení nebo jednotlivec), která má za úkol sledování změn v dané službě. Dále se stará (což je jeho nejčastější prací při provozu služby) o specifikování vzniklých problémů. K tomu u slouží data z konfigurační databáze.
Metodika (R)UP ((Rational) Unified Process) Unified Process neboli unifikovaný proces vývoje aplikací. Asi každý kdo se setkal s vývojem nějaké aplikace, třebas i malé, zjistil že proces vývoje má nějaký životní cyklus. Tento cyklus většinou začíná tím, že zjišťujeme co vlastně má aplikace dělat a končí nasazením aplikace do provozu. Metodika (R)UP nám slouží k tomu aby nám do vývoje přinesla řád a pořádek. Rozdíl mezi RUP a UP Pokud by se to mělo vyjádřit velice stručně, tak metodika RUP je komerční verzí metodiky UP. Metodika RUP (Rational Unified Process) je uváděna na trh společností IBM (ta v roce 2003 koupila společnost Rational). V podstatě se dá říci, že obě metodiky jsou postaveny na stejném základu a liší se pouze v tom, že v mnoha případech je metodika RUP propracována více do detailů a v některých případech se nepatrně liší s syntaxi. Dále v této práci budeme pracovat s metodikou RUP jelikož její obsáhlejší definice nám lépe poslouží k demonstrování případů spolupráce s ITILem. Popis vývoje podle metodiky RUP Metodika (R)UP je řazena do metodik iterativních přírůstkových, což v praxi znamená, že práce na vývoji softwaru je měřena přírůstky. Každý přírůstek, neboli fáze, je definován takzvanými milníky, které říkají, co všechno se musí splnit, aby byl daný inkrement dokončen. Což v praxi přináší ne moc viditelnou, ale přesto výraznou revoluci ve vývoji aplikací, jelikož při vývoji se nesoustředíte na celkový výsledek, ale na dosažení daného milníku. Což ve výsledku umožňuj jednoduchou separaci práce a velké zkvalitnění. Ve výsledku se zjednodušeně řečeno obě metodiky snaží popsat kdo, co, jak? Což se u dané problematiky dá brát jako stěžejní záležitost. Na obrázku 2 je vidět jak je do celého procesu vývoje začleněn Change & Confuguration Management (R)UP rozděluje proces vývoje aplikace do 4-ti fází: 1. Zahájení (inception) v této fázi se zpracovávají první požadavky na aplikaci. Vysledovávají se zde podmínky proveditelnosti. Zde se řeší základní prvky obchodního případu, kde se demonstruje zda li je aplikace přínosná. Ve výsledku by měla fáze Zahájení následné výstupy: Dokument vize a rozsahu
Rozpracování případů užití (10-20%) Rozpracovaný slovník (slovník slouží k vysvětlení základních pojmů užívaných v podnikovém žargonu) Rozpracované obchodní případy Zpracovaný odhad rizik Plán projektu ukazující fáze a přírůstky Prototyp (pokud je třeba) 2. Rozpracování (elaboration) V této fázi se zaměřujeme především na zpřesnění požadavků na aplikaci. Dalším výrazným výstupem z této fáze by měl být první spustitelný základ. Výstupy: První spustitelný základ nebo propracovaný prototyp Případy užití (use case model) 80-100% Zpracované funkční i nefunkční požadavky na systém Popis architektury aplikace Revize seznamu rizik Vývojový plán na celý projekt Předběžný uživatelský manuál 3. Konstrukce (construction) Zde je na řadě konstrukce samotné aplikace. K tomu je zapotřebí plné zpracování návrhu aplikace. Výstupy: Kompletní analytický model Kompletní návrh model UML Aplikace integrovaná na odpovídající platformě Uživatelský manuál Testovací sada Poznámky k prvnímu vydání 4. Zavedení (transition) Milníkem této fáze by mělo být plné nasazení aplikace do provozu po provedení testů. Výstupy: Aplikace
Plán uživatelské podpory Aktualizované příručky Obrázek 2: Zobrazení rozmístění prací do jednotlivých fází, Rational Unified Process, Rational Software White Paper RUP a UML2 Metodika RUP používá jako vyjádření popisu kdo, co, jak modelovací jazyk UML2 (unified modeling language). Tímto jazykem se pomocí obrázků zakresluje celá struktura aplikace. UML přesně koresponduje s postupem RUP. My se tímto jazykem do hloubky zabývat nebudeme, ale je zde nutno vypíchnout jednu důležitou věc. Tou je, že modelování aplikací pomocí jazyka UML2 má své výstupy (povětšinou jsou to diagramy, které se dělí na statické a dynamické). Tyto výstupy se nazývají artefakty. Těmito artefakty mohou být také kódy, které již většina CASE nástrojů umí vygenerovat z diagramů (kombinace diagramu tříd a sekvenčních diagramů).
Případy spolupráce metodik RUP a ITIL V této kapitole se zaměříme na konkrétní případy spolupráce těchto dvou metodik. Nabízí se nám 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 1 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 1. RUP ITIL V3 Zahájení Dokument vize a rozsahu Service Identifikace požadavků Případy užití (20%) Strategy Zdroje a napojení Slovník projektu Právní ujednání Počáteční plán projektu Strategie Obchodní případ Odhad rizik Prototyp Rozpraco- První spustitelný základních Service Balíčky modelů služeb vání Model UML Design Standardy Popis architektury aplikace Architektura Vývojový plán projektu Modelová řešení Předběžný uživatelský manuál Konstrukce Spustitelný software Service Aktualizované balíčky modelů služeb Testovací sada Transition Testovací řešení Uživatelské příručky Plány nasazení Zavedení Aplikace Uživatelské příručky Plán podpory Service Operation Tabulka 1: Srovnání životních cyklů metodiky ITIL V3 a RUP Provozní plány Provoz služeb
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. Konf igurační databáze (CMDB) ve spolupráci s UML2 Jak již bylo napsáno 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 Cange Control Boardem ke specifikování vzniklých incidentů. Užití metodiky RUP v Change Managementu a Problem Managementu Metodika RUP nám jeiž 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. Obrázek 3 popisuje ž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). Tento proces popisuje Obrázek 2. Obrázek 3: Životní cyklus incidentu 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.
Nasazení ITILu V této kapitole se budeme zabývat nasazením ITILu. Budeme vycházet z předpokladu, že nasazujeme ITIL do společnosti, která při vývoji aplikací používá metodiku RUP. Budeme si modelovat tři různé situace nasazení na třech různě velkých společnostech. Míra nasazení a prostoupení ITILem se totiž u společností liší a většinou je závislá na velikosti společnosti. Malá společnost do 25-ti zaměstnanců U menší společnosti je nejlepší vycházet ze rčení nebrat dělo na komára. U malé společnosti, která využívá k vývoji aplikací metodiku RUP podpořenou jazykem UML je vhodné nasazení dvou základních pilířů ITILu. Těmi jsou Konfigurační databáze a Problem Management. Bohužel v této době zatím nejsou na trhu téměř žádné kvalitní aplikace nebo nástroje podporující nasazení pouze některých částí ITILu, které by neznamenali pro malou společnost velký peněžní náklad. Pro malou společnost je nejvhodnější, když si nějakou malou aplikaci vytvoří sama. Může se jednat o aplikaci fungující na webových principech vytvořenou pomocí jazyků MySQL, (X)HTML, CSS. Co se týče Konfigurační databáze, tak zde bude postačovat správa CIs (Configuration Items konfigurační jednotky/položky). Jedná se o poměrně jednoduchý záznam, který bude obsahovat id, název, popis, kategorii (například HW, zdrojový kód, artefakty UML, atd..) a přílohy. V tomto případě jednodušší pojetí umožňuje jednodušší udržení aktuálních dat. Aplikace zabývající se Problem Managementem by měla být úzce propojená s konfigurační databází. Zde je nutné vytvořit záznam o Problému (např. id, název, popis, stav, priorita, příloha, reference na CIs), životní cyklus Problému (např. nový, v řešení, vyřešen) a uživatelé, kteří budou s tímto Problémem přicházet do styku (např. service desk, vývoj, tester). Provázanost záznamu o problému s konfigurační databází napomáhá k lokalizování problému (přiřazení dané Položky k Problému). A naopak slouží jako zpětná vazba při pohledu z konfigurační databáze. Je zde vysledovatelné na jaké z Položek se událo nejvíce Problémů a z jakých důvodů byla Položka aktualizována. Výhody nasazení: zpřehlednění toku informací, práce a dat ve společnosti v návaznosti na danou aplikaci zefektivnění práce zlepšení dohledatelnosti informací o projektu či aplikaci
snížení rizik Nevýhody nasazení: je třeba uvolnit pracovníky na vývoj aplikace, kteří nebudou moci pracovat na svých projektech vývoj aplikace je nákladný v některých případech dochází k reorganizaci firemní struktury Středně velká společnost do 200 zaměstnanců U středně velké společnosti se už dá uvažovat o plném nasazení ITILu. Toto nasazení by se dalo rozdělit do čtyrech částí. První částí by bylo uzpůsobení firemní struktury požadavkům ITILu, druhou by bylo vytvoření konfigurační databáze, třetí částí by bylo nasazení interního informačního systému pro správu toku dat, práce a informací, čtvrtou by pak bylo zaškolení pracovníků. Firemní struktura ITIL celkem přesně definuje firemní strukturu za účelem opravdu bezpečného a efektivního toku práce a informací ve společnosti. Při rozhodování o změně firemní struktury bude záležet na míře nasazení ITILu. Jiné to bude, když bude mít společnost 50 zaměstnanců a jiné to bude když jich bude mít 200. Ovšem v obou případech je tato struktura nutná. V mnoha případech bude jeden článek ITILu zastávat pouze jeden zaměstnanec. Ale na druhou stranu vzniknou útvary, které jich budou čítat několik. U každého útvaru (tím například bude Service Desk) je potřeba perfektní definice práce. Pokud společnost využívá při vývoji praktiky metodiky RUP, bude tato reorganizace jednodušší, jelikož se budou přeorganizovávat jen jednotky zaměřené na zprávu poskytovaných služeb (HW, SW, celého řešení). Na Obrázku 4 je vidět modelová struktura společnosti dle ITILu. Vytvoření konfigurační databáze a nasazení interního informačního systému V případě středně velké společnosti máme při implementaci ITILu dvě možnosti. První možností je vytvoření vlastního informačního systému vlastní společností tak jak tomu bylo u menší společnosti. Jednalo by se samozřejmě o podrobnější a složitější aplikaci než v předchozím případě. Také by do ní vstupovalo daleko více uživatelů. Druhou možností je využití komerčních řešení v podobě různých aplikací. A to ať už navržených přímo na správu určité části ITILu nebo na celou činnost společnosti. Jednou z variant by bylo
například použití softwaru IBM Rational ClearQuest, který nabízí plnohodnotné schema pro kontrolu toku práce a informací při správě služby (SW, HW, řešení). Toto schema bylo přímo navrženo pro správu služeb v IT s ohledem na spolupráci s metodikou RUP. Životní cyklus Incidentu a Problému vychází přímo z metodiky RUP. Jinou možností je nasazení řešení od společnosti Ifra, která nabízí kompletní řešení pro pro práci s metodikou ITIL podporovanou metodikou RUP. Jedná se o plně webové řešení. U všech případů komerčních SW je obrovskou výhodou, že si nejen kupujete samotný SW, ale také know-how, které tyto SW obsahují. Jedná ve o prověřené SW, které bylo vyvíjeno a zlepšováno po nějakou dobu. Obrázek 4: ukázka organizační struktury ITILu, ITIL organisation structure, CEC Europe Zaškolení personálu Ve středně velké společnosti, která implementuje ITIL by měli být proškoleni všichni pracovníci na vedoucích pozicích. Jedná se o plnou znalost metodik RUP (především u vývoje) a ITIL (zde se
jedná o všechny vedoucí pracovníky). Všechen personál by pak měl býct perfektně proškolen v zacházení s interním informačním systémem. Výhody, nevýhody Výhody: Takováto společnost ještě více potřebuje efektivní organizaci práce Rapidní snížení rizik Transparentnější struktura společnosti Nevýhody: Nasazení informačního systému je velice nákladné Proškolení lidí je velice nákladné Reorganizace společnosti vyžaduje důkladnou přípravu V některých ohledech může přechod na organizační strukturu ITILu vyžadovat nárůst pracovníků Velká společnost nad 200 zaměstnanců U těchto společností bývá nasazení ITILu i jakýchkoli jiných metodik během na dlouho trať. Opět je zde veliká výhoda, pokud již společnost ve svých vývojových odděleních používá metodiku RUP pro vývoj SW. Proces reorganizace u takovýchto společností většinou trvá i řadu měsíců nebo let. Jelikož nelze omezit na nějaký čas chod společnosti a začít se zabývat nasazováním metodik. Co se týče informačního systému, zde většinou metodika ITIL i RUP jsou pevně zabudovány do interních celopodnikových systémů, ale není vyjímkou, kdy se využívá nástrojů jako tomu bylo v případě středně velké společnosti. U těchto společností se musí dbát perfektní důraz na organizační strukturu (Obrázek 4). Jelikož u takto velkých společností daleko více záleží na transparentnosti struktury.
Závěr Zde jsme si ukázali několik příkladů, kdy dvě na první pohled rozdílné metodiky spolupracují nebo se doplňují. Jedním z nejklasičtějších příkladů spolupráce ITILu a RUPu je konfigurační databáze, kde ITIL říká jakou by tato databáze měla mít podobu a právě RUP nebo spíše artefakty jazyka UML2 jí naplňují. Dalším případem je implementace metodiky RUP do Change a Problem Managementu. Faktem je, že ITIL nabádá aby každý problém nebo změna byly řízeny jako projekt. A právě v těchto případech se využívá metodika RUP. Spolupráce těchto dvou metodik, zvláště pak nová verze ITIL V3 je velkým důkazem toho, že aplikace nejsou už jen produkty a že už nestačí je jen navrhnout a vyslat do světa, ale že aplikace čím dál více jsou služby, které je potřeba řídit. Dalším faktem je, že pokud budeme implementovat ITIL do jakékoli společnosti, tak pro nás bude jednoduší, když tato společnost bude využívat metodiku RUP, kterou, jak jsme si ukázali, při mnoha případech ITIL využívá. Klasickým případem je pak spravování služby.
Zdroje: Použitá literatura An Introductory Overview of ITIL V3, Best Management Practice Rational Unified Process, Rational Software White Paper http://www.best-management-practice.com/ http://www.itil-officialsite.com/ ITIL organisation structure, CEC Europe http://www.infra-corp.com/ Použité obrázky Obrázek 1: Životní cyklus služeb. Použito z An Introductory Overview of ITIL V3 Obrázek 2: Zobrazení rozmístění prací do jednotlivých fází, Rational Unified Process, Rational Software White Paper Obrázek 3: Životní cyklus incidentu Obrázek 4: ukázka organizační struktury ITILu, ITIL organisation structure, CEC Europe