Správa IT služeb a řízení životního cyklu softwarových aplikací

Transkript

1 Správa IT služeb a řízení životního cyklu softwarových aplikací

2 Obsah 1. Úvod 2 2. Řízení a správa IT služeb v oblasti softwaru 3 Základní rámce pro provozování a tvorbu softwarových aplikací v podnikovém IT prostředí: Microsoft Operation Framework a Microsoft Solution Framework 3. Microsoft Solution Framework (MSF) 4 Přizpůsobte si metodiku projektu na míru 3.1. Základní principy MSF Týmový model MSF Procesní model 6 4. Microsoft Visual Studio Team System 8 Visual Studio Team System (VSTS) jednotná a komplexní infrastruktura pro návrh, tvorbu, testování a nasazování softwarových aplikací 4.1. Jak začít s projektem metodiky, MSF Agile a MSF CMMI Architektura, od modelu k nasazení Prevence chyb je mnohem levnější než jejich pozdější odstranění Nezapomeňte na databáze, jsou téměř v každém projektu Mnoho rozměrů zdraví projektu Sledování ukazatelů kvality A co na to auditor? Nadstavby a partnerská řešení využívající VSTS Úvod Informační technologie se vyvíjejí neobyčejně rychle a jejich správné využití zajišťuje výraznou konkurenční výhodu téměř ve všech oblastech podnikání. To je jeden z hlavních důvodů proč výrazně vzrostl význam IT služeb nejen ve velkých ale i v malých společnostech. V posledních letech jsou celkové firemní procesy čím dál tím více závislé na informačních a komunikačních technologiích (ICT). Tím zároveň roste zátěž IT oddělení, případně externí organizace zajišťující chod IT. S důležitostí a rostoucím vlivem IT jsou však spojeny zvyšující se nároky na poskytování kvalitních IT služeb nejen uvnitř organizace, ale často i ve vztahu k zákazníkům nebo partnerům. Ve většině IT projektů, které nebyly dokončeny úspěšně, neselhala technologie nýbrž procesy nebo lidé. Technologie je pouhým prostředkem k uskutečnění kvalitativních změn. Rozdělme si ji na tři základní skupiny, hardware, software a komunikace, a podívejme se na to, jak která z nich, s pomocí správného řízení, dokáže ovlivňovat podnikové procesy. Velmi rychle zjistíme, že jedna oblast vyčnívá. Z hardwarových a částečně i komunikačních (internet atd.) částí se stává obyčejné mrtvé zboží, které nepřináší žádnou konkurenční výhodu. Málokdo se dnes stará o to jaký server je nejvýkonnější a internetové připojení nejrychlejší. HW zařízení i komunikační spojení začínají být levné, dostupné komukoli s velmi dobrým servisem, oboje většinou zajišťované externími dodavateli. Tyto komodity se stávají čím dál častěji pouhou nutnou obálkou třetí skupině, software. Software a jeho optimální zapojení se do všech procesů v organizaci, jeho schopnost spolehlivě, rychle a pružně reagovat na změnu vnějších vlivů a požadavků zákazníka je to, co dokáže dnešní moderní organizaci posunout před své konkurenty. Na následujících stránkách naleznete několik pohledů a názorů, jak správně navrhovat, tvořit a nasazovat moderní softwarové aplikace. Využití Microsoft Solution Framework pro řízení a správu našeho projektu společně s implementací Agile Development metodiky v rámci produktové řady Visual Studio Team System nám umožnilo maximální zrychlení vývoje projektu spolu s vysokou efektivitou správy příspěvků. Díky tomu jsme dosáhli více než trojnásobného zvýšení produktivity vývoje oproti výchozím předpokladům. Ing. Jaroslav Veselý, vedoucí projektu Money S5 Nasazení Microsoft Team Foundation serveru mi umožňilo díky nástrojům pro efektivnější správu projektu a dobré podpoře pro delegování vybraných činností se zapojit do řízení více projektů a věnovat se i obchodním aktivitám. Ing. Jaroslav Jindřich, Software Consultant, Team Leader, Logos a.s.

3 2. Řízení a správa IT služeb v oblasti softwaru Základní rámce pro provozování a tvorbu softwarových aplikací v podnikovém IT prostředí: Microsoft Operation Framework a Microsoft Solution Framework Celosvětově uznávaný konzistentní a procesně orientovaný rámec zkušeností a praktik pro oblast IT Service Managementu ITIL (Information Technology Infrastructure Library), společně s mnoha stávajícími zkušenostmi, byl pro společnost Microsoft základem pro praktickou implementaci, která byla formalizována v roce 1999 pod názvem Microsoft Operation Framework (MOF). Velmi důkladně propracovaná část konkrétních praktik a návodů zabývající se tvorbou softwaru byla uveřejněna již v roce 1993 pod názvem Microsoft Solution Framework (MSF) a vychází ze zkušeností samotné společnosti Microsoft, konzultantů společnosti Microsoft a mnoha tisíc partnerských firem tvořících softwarové aplikace. Na rozdíl od obecných popisných schémat ITIL, kde se dozvíte KTERÉ procesy mají být implementovány (nemusí být ani z oblasti IT), jsou MOF/ MSF metodiky řízení založené na konkrétních doporučeních, a již říkají JAK konkrétně, v oblasti IT, mají být procesy implementovány a řízeny. Obě metodiky jsou úzce spjaty se softwarovými aplikacemi, ale zejména MOF najde uplatnění i v ostatních segmentech podnikové infrastruktury. Nejedná se tedy o náhradu ITIL, ale o konkrétní implementaci pro organizace využívající softwarové IT řešení převážně na platformě Microsoft. Metodiky MOF i MSF obecně vycházejí z vize neustálého koloběhu zlepšování IT služeb a schopností plnit aktivně aktuální požadavky, která je označována jako IT life cycle Životní cyklus IT služeb a projektů. Dle tohoto pohledu je IT organizace ideálně ve stavu neustálého vylepšování svých služeb projektů a produktů. Pro podporu a dosažení kontinuálního rozvoje poskytují metodiky, procesně orientované návody, nástroje a příklady s vazbou na konkrétní pracovníky v jednotlivých týmech. Kombinací Microsoft Operation Frameworku a Microsoft Solutions Frameworku jsou schopny organizace implementovat jednotný, ucelený rámec pro správu jejich IT infrastruktury a to od plánování a tvorby řešení, přes jejich nasazení a provozování až pro podporu. I když lze oba rámce zcela Životní oddělit, jsou MSF a MOF cyklus vytvořeny tak, aby IT navzájem služeb vhodně spolupracovaly a projektů a doplňovaly se. Obchodní požadavky Tvorba Microsoft Solutions Framework Plánování Společné oblasti & sdílení odpovědnosti Nasazení Microsoft Operations Framework Provoz Dodávka služeb Životní cyklus IT služeb a projektů a pozice Microsoft Operation Framework a Microsoft Solution Framework. Obrázek 1 Životní cyklus IT služeb a projektů a pozice Microsoft Operation Framework Na následujících stránkách se zaměříme na část Microsoft Solution Framework, který se v poslední době velmi rychle rozvíjí v důsledku vstupu nové produktové a řady Microsoft Visual Studio Solution Team System framework. společnosti Microsoft do oblasti nástrojů pro řízení životního cyklu aplikací Application Lifecycle Management (ALM). 3

4 3. Microsoft Solution Framework (MSF) Přizpůsobte si metodiku projektu na míru Microsoft Solution Framework je obecný rámec (metamodel) pro řízení procesů při tvorbě softwarových aplikací založený na zkušenostech různých softwarových firem. Na rozdíl od mnoha popisných metamodelů se však každá konkrétní implementace MSF již nedívá na vývoj software a jeho životní cyklus z hlediska vnějšího pozorovatele, ale z aktivního hlediska účastníků všech procesů, kroků jejich činností, aktivit vedoucí k finálnímu produktu. Microsoft Solution Framework i konkrétní metodiky dodávané společností Microsoft a dalšími partnery umožňují organizacím tvořit si vlastní implementace nebo upravovat stávající metodiky. Filozofie MSF však vychází z určitých předpokladů a tak mějme na paměti, že i implementované metodiky musí vyznávat podobný obecný názor na řízení projektů. Při pohledu na svět projektů se setkáváme se dvěma rozdílnými přístupy, které lze volně označit za úkolocentrický a hodnotocentrický. MSF vyznává hodnotocentrický přístup. Úkolocentrický Hodnotocentrický Zbývající práce Plán Úkol 1 Úkol 2 Úkol 3 Úkol Hodnota Základní rozdíl mezi úkolocentrickým a hodnotocentrickým přístupem spočívá ve výchozím měřítku. Úkolocentrický přístup považuje projekt za pevný seznam úkolů jisté ceny, které je třeba dokončit, a výdaje měří podle těchto úkolů. Hodnotocentrický přístup měří hodnotu, která je ázek 1.2 Základní rozdíl mezi úkolocentrickým a hodnotocentrickým přístupem spočívá ve výchozím měřítku. v jednotlivých okamžicích dodávána, a na vstupy nenahlíží jako na pevnou zásobu, ale jako na proměnlivé toky. Úkolocentrický přístup považuje projekt za pevný seznam úkolů jisté ceny, které je třeba dokončit, a výdaje měří podle těchto úkolů. Hodnotocentrický přístup měří hodnotu, která je v jednotlivých okamžicích dodávána, a na vstupy nenahlíží jako na pevnou zásobu, ale jako na proměnlivé toky. Obecný rámec MSF volně definuje tři hlavní oblasti, které pak konkrétní metodika použitá při tvorbě aplikace může svým specifickým způsobem naplňovat a jsou to: Základní principy Týmový model Procesní model 3.1. Základní principy MSF Principy MSF 4.0 vyjadřují hodnoty a standardy, které jsou společné všem ostatním atributům rámce. Tyto principy jsou společné pro všechny role účastníků softwarového projektu. Společně vyjadřují filozofii MSF a formují základní, jednotný a srozumitelný přístup, jak řídit týmy i procesy: Partnerství se zákazníkem Nejlepší řešení vznikají, když se vývojové týmy spojí se zákazníky a vytvoří tvůrčí vztah založený na společných cílech. Otevřená komunikace Pro maximální efektivitu práce je potřeba mít neustálý přístup k informacím, které jsou aktivně sdílené. Pracovat na společné vizi Mít dlouhodobě konzistentní vizi odstraňuje nejistotu a inspiruje tým v růstu k vyšším cílům. Zapojení členů týmu V efektivním týmu jsou všichni členové schopni plnit svá předsevzetí a cítí jistotu, že ostatní udělají to samé. Jasná zodpovědnost Chybějící definice zodpovědnosti často mají za následek duplikovanou práci nebo chybějící výsledky. Soustředění se na obchodní hodnotu Technologické projekty nejsou dodávány jenom pro technologii, ale musí dodat i viditelnou obchodní hodnotu. 4

5 Adaptace na změny Čím více se organizace soustředí na reálný obchodní dopad technologických investicí, tím dále se dostává na nová území podnikání. Ty mohou skrývat velké možnosti, ale jsou nejistá a měnící se jako objevování a experimentování samo o sobě. Předstírat nebo požadovat jistoty by bylo přinejmenším nerealistické a pravděpodobně i nefunkční. Investovat do kvality Investice do kvality je investicí do lidí, procesů a nástrojů. Úspěšné řízení kvality zahrnuje včlenění vnímání kvality do základní kultury organizace. Učit se ze zkušeností Najít si čas na učení v rámci napjatých termínů a s omezenými zdroji je obtížné jak pro tým, tak pro zadavatele. Nicméně zanedbání poučení se ze zkušeností implikuje, že budeme opakovat chyby a jejich následky. Vždy vytvářet produkt, který je možno dodat a nasadit Tým by měl dodávat produkt nejvyšší kvality i v procesu změn. Každá změna by měla být provedena v kontextu představy, že produkt může být kdykoliv dodán a nasazen Týmový model MSF Týmový Model Microsoft Solution Framework popisuje přístup jak organizovat pracovníky a jejich aktivity s cílem vytvořit a dodat a úspěšný projekt. Model je založen na následujících principech: Tým rovnocenných kolegů Každý v týmu má část odpovědnosti za výsledek projektu. Každá role odpovídá za kvalitu celkového řešení. Skupiny zájmu Týmový model je rozdělen do sedmi rovnocenných skupin, podle toho jaké mají lidé cíle, pravomoci dané jejich funkcí a schopnosti konstruktivně ovlivnit konkrétní oblast. Pružnost Zavedené skupiny mohou být kombinovány do menších nebo jindy rozšiřovány a to v závislosti na velikosti projektu, počtu lidských zdrojů nebo použité metodice. Projektový manager Řízení projektu Architekt Architektura Produktový manager Vedení produktu Analytik Uživatelské zkušenosti Tým Vývojář Vývoj Tester Testování Týmový model MSF. Vydávání a nasazení Release manager Microsoft Solutions Framework zavádí model týmu rovnocenných kolegů, rozdělených na sedm úhlů pohledu, které musí být v úspěšném projektu zastoupeny. Implementace odlišných metodik specifikují různý počet oblastí. Např. MSF for CMMI Process Improvement těchto sedm oblastí rozděluje na osmnáct, zatímco MSF for Agile Software Development vystačí se šesti a jiné implementace např. Extreme Programming jsou připraveny snížit jejich počet třeba i na tři. Projektové řízení Středem pozornosti projektového řízení je dosáhnout dodávku řešení v rámci omezení daných projektem. Tato skupina zajišťuje, že bude dodáno správné řešení v odpovídající době, a že v průběhu projektu budou pochopeny, zvládnuty a splněny všechny požadavky zadavatelů. Architektura Zahrnuje služby, technologie a standardy, se kterými bude řešení spolupracovat, infrastrukturu, v níž bude nasazeno, jeho místo v podnikatelské činnosti nebo rodině produktů a jeho plány pro budoucí verze. Skupina architektury musí zajistit, že vyvinuté řešení splňuje všechny požadavky na kvalitu i podnikatelské cíle a je z dlouhodobého hlediska životaschopné.

6 Vývoj Vývojáři vedle toho, že jsou hlavními budovateli řešení, zodpovídají za promyšlená technická rozhodnutí, čistý návrh, dobré odhady vertikální struktury a kvalitní, udržovatelný kód a unit testy. Testování Testy předvídají, hledají a oznamují jakékoliv problémy, které mohou v očích zákazníků nebo uživatelů snížit kvalitu řešení. Vydávání a nasazení (Release management) Tato skupina zajišťuje včasnou připravenost a slučitelnost infrastruktury s řešením. Chápání uživatelských zkušeností Skupina musí chápat prostředí uživatelů jako celek, rozpoznat všechny detaily potřeb a požadavků koncových uživatelů a zajistit, aby si celý tým uvědomil význam použitelnosti z pohledu koncových uživatelů. Produktové (obchodní) vedení Musí pochopit a zajistit úspěch z pohledu zákazníka, zadavatele, který řešení požaduje. Komunikuje a předává týmu jeho obchodní vizi a dohlíží na ekonomickou spokojenost zákazníka Procesní model Procesní model Microsoft Solution Framework můžeme popsat jako iterativní spirálový model obsahující vícenásobné série krátkých vývojových cyklů navazujících na sebe. Poznámka: Iterativní vývoj vznikl jako lék na lineární vodopádový vývoj. Základní chybou vodopádového modelu je předpoklad, že projekt projde celým procesem jen jednou, že architektura je vynikající a snadno použitelná, návrh implementace je bezproblémový, realizace je po otestování neměnná a požadavky uživatelů stálé. Jinak řečeno předpokládá, že chyby se budou týkat pouze realizace a jejich oprava tedy může být snadno zahrnuta do testování komponent a systému. Pro iterativní vývoj mluví řada velmi příjemných důvodů, od řízení rizik až po motivaci týmu vidící fungující, byť předběžnou, verzi programu. Iterativnost je vhodná pro všechny projekty... a pro ty s vysokými riziky je nevyhnutelná. Iterativní vývoj v praxi vyžaduje, aby tým i jeho manažer měli přesný přehled o veškeré práci, kterou je nutné udělat, aby ji mohli mezi jednotlivými krátkými iteracemi (průchody) často sledovat a měnit její priority. Tyto časté aktualizace vyžadují přehledný systém, nejlépe doplněný automatickým sběrem dat. Procesní model MSF Fáze nasazování Nasazení dokončeno Fáze ujasnění představ Funkčnost Iterovaná vydání Verze 1 Verze 2 Verze 3 Připravenost k nasazení schválena Představy jsou jasné Čas Fáze stabilizace Fáze plánování Vývoj hotový Fáze vývoje Plány projektu schváleny Procesní model MSF, iterace a postupné přidávání funkčnosti a hodnoty verzí. Nápady, představy a vize V této části se formuje společná vize všech zúčastněných jako jasný cíl projektu, podmínky jeho uskutečnění a také důvod, proč na něm začít pracovat. Tým bez těchto základních mantinelů nemá moc šancí projekt úspěšně dokončit. Shromažďují se a analyzují základní obchodní požadavky, které budou laděny v dalších iteracích průchodech. Část končí dohodou projektového týmu se zákazníkem o celkovém (nebo dalším) směru projektu, základních vlastnostech a obecném harmonogramu.

7 Plán Zde se tvoří plán iterací projektu. Je založen na scénářích a úrovni požadovaných služeb, při zachování návazností jednotlivých iterací s ohledem na důležitost a jejich pracnost. Zná-li tým co má dělat, může vedoucí projektu vytvořit vhodné iterace na základě náročnosti vývoje, testování nebo oprav chyb. Část končí, pokud tým odsouhlasí plán práce, která má být odvedena v následující fázi. Vývoj, vytváření V části vývoje a tvorby se mění myšlenky v program, vývojáři produkují strukturovaný kód a zároveň provádějí základní unit testing pro zajištění kvality kódu. Vývojáři programují postupným, iterativním a komponentovým způsobem a stejně tak implementují požadované scénáře. Dle použité metodiky a domluvy musí vývojový tým tvořit zároveň odpovídající dokumentaci. Stabilizace Ve stabilizační části testeři ladí aktuálně implementované části řešení. Spouštějí odpovídající testy a ověřují kvalitu systému. Kontrolují celkovou implementaci, její kvalitu a splněné požadavky. Kontrolují odstranění chyb a oznamují nalezené chyby. Jsou-li všechny požadavky splněny, systém je stabilní, může projekt pokračovat do další fáze. Nasazení Jsou-li implementovány a otestovány požadované vlastnosti a systém odpovídá zadání, může být připravován pro nasazení u zákazníka. Dříve však je třeba připravit a otestovat instalace v odpovídajícím infrastrukturním prostředí, kompletovat dokumentaci a ujistit se že hodnoty požadované zákazníkem jsou splněny. Provoz a údržba systému se pak můžeme řešit pomocí MOF. Pokračování a nová verze Část zahrnuje všechny aktivity, které jsou nezbytné, pokud počítáme s další verzí systému. (Což je prakticky vždy.) Jsou nastavena nová měřítka představ, co by měl systém zvládat, zavedeny nové požadavky na kvalitu produktu či dokumentace. Vše co je zaznamenáno slouží ke zlepšení vývoje nové generace systému. Celý tým dokáže opět velmi jednoduše nastartovat koloběh iterací a začít práci na inovaci produktu. Průchody Nasazení Nasazení dokončeno (Můžeme zdroje věnované projektu přesunout jinam?) Vytváření Stabilizace Připravenost k nasazení schválena (Je produkt stabilní natolik, aby mohl být nasazen? Nebo bude dost stabilní v blízké budoucnosti?) Rozsah hotový (Pokryli jsme rozsah, který jsme stanovili v obchodní vizi a vizi produktu?) Plán Plány projektu schváleny (Zvládneme to v tom správném čase a rozpočtu? Je to z obchodního hlediska odůvodněno?) Znalosti Vize Vize/rozsah odsouhlaseny (Děláme tu správnou věc?) Vedení Provoz, operativa Průběžné činnosti Čas Ukázka jednotlivých procesních fází v rámci metodiky MSF for CMMI Process Improvement.

8 4. Microsoft Visual Studio Team System Visual Studio Team System (VSTS) jednotná a komplexní infrastruktura pro návrh, tvorbu, testování a nasazování softwarových aplikací. Společnost Microsoft nabízela pro vývojové týmy mnoho let základní vývojové prostředí typu Visual Basic, C++, Visual Studio, případně SourceSafe na správu verzí a zdrojových kódů. Ostatní produkty pro podporu životního cyklu aplikací dodávali partneři nebo si je dělali vývojáři sami. S problémem nekonzistentního, případně velmi drahého prostředí se pak setkávali všichni. Interně se ve společnosti Microsoft používal již dlouhou dobu propracovaný, ověřený, i když technologicky poněkud zastaralý systém. Ten, společně s požadavkem zákazníků na ucelený, konzistentní balík využívající jednotné repository veškerých metadat s volně implementovatelnou metodikou vývoje a otevřeným API pro přístup z jiných aplikací, byl základem pro vznik nové produktové řady Visual Studio Team System. Produkty Visual Studio Team System slouží pro podporu celého životního cyklu vývoje softwarových aplikací od návrhu specifikace až po uvedení do provozu. Při vývoji v týmu pomohou zvýšit produktivitu (a tím snížit náklady) a zvýšit předvídatelnost (a tím snížit rizika) při tvorbě a dodání softwarových aplikací. Jádrem řešení je serverová část (Visual Studio Team Foundation Server), která se skládá z několika bloků. Dá se popsat jako aplikace podporující workflow procesy, s OLTP databází veškerých změn zdrojových kódů a projektových metadat, s využitím vícerozměrného (OLAP) zpracování i následného reportování (Reporting Services) a možností sdílet informace na projektovém portálu (SharePoint Server). Veškeré rozhraní je zdokumentováno pomocí SDK a partneři dodávající nadstavby, doplňky či přímo celé své vlastní vývojové IDE se tak mohou libovolně napojovat. Pro konkrétní role jsou dodávány specializované vývojové produkty, nebo rozšíření pro externí aplikace typu Microsoft Project či Microsoft Excel. Visual Studio Team System Business procesy a analýza Visual Software Architect Studio Partners Team Software Developer Team Suite Explorer Database Professional Otevřené API, Web klienti a XML Webové služby Provoz a podpora Project Manager Team Portal Paterns and Practices Change Management Project Management Team Foundation Version Control Software Tester Reporting Server Solutions Framework Microsoft IDE prostředí a produkty partnerů Vazby a návaznosti produktové řady Visual Studio Team System Jak začít s projektem metodiky, MSF Agile a MSF CMMI Visual Studio Team System (VSTS) využívá tzv. hotové implementační šablony či vzory (process template), pomocí nichž definuje počáteční nastavení projektu včetně metodiky. Tuto počáteční konfiguraci lze vytvářet zcela na zelené louce nebo upravovat již nabízené. VSTS umožňuje při tvorbě nového projektu si velmi jednoduše vybrat vhodnou z více šablon, (pro jeden projekt je vhodná metodika SCRUM, jiný třeba CMMI) a nastavit prostředí dle vybrané metodiky. 8

9 V aktuálně dodávané produktové řadě vývojového prostředí Microsoft Visual Studio Team System (VSTS) jsou poskytovány dva konkrétní návody resp. hotové implementační šablony konkrétních metodik. Jedna je založená na principech Agile Development druhá na CMMI. Otevřená specifikace MSF a TFS umožňuje partnerům dodávat i další metodiky, např RUP, SCRUM, XP (Extremme Programming) atd. Více informací naleznete na adrese Procesní šablona obsahuje základní komponenty jako strukturu projektu, skupiny a práva, projektový portál, řízení zdrojového kódu, reporty. Dále se zde setkáváme s pojmy Workstream a Work item vycházejícími s vazby Týmového a Procesního modelu na technologickou strukturu databázového vícerozměrného prostředí, v němž tým navzájem spolupracuje. Workstrem (Pracovní postup) je skupina pevně definovaných aktivit, které na sebe logicky a přirozeně navazují a většinou jsou propojeny s konkrétními týmovými rolemi. V rámci MSF Agile je jeden Postup přiřazený roli vývojáře označen Oprava chyby, jiný Postup přiřazený jiné roli a to testerovi je Uzavření chyby. Chyba samotná je pak označována jako Work Item (pracovní položka) základní jednotka průhledného společného úkolníku, na kterou jsou vázány všechny stavy v projektu a sleduje se její kompletní historie. Např. MSF for CMMI těchto pracovních položek definuje sedm, MSF Agile pět. Visual Studio 2005 Team System Konkrétní metodika Popisný model Inform. Procesní šablona MSF for Agile Software Development Kopie a změna Procesní šablona Upravený Agile proces MSF 4.0 Metamodel Inform. Procesní šablona MSF for CMMI Process Improvement Kopie a změna Procesní šablona Upravený CMMI proces Procesní šablona Jiné metodiky Na obrázku je vidět vztah obecného popisného MSF metamodelu a konkrétních implementací metodik dodávaných v rámci produktů Visual Studio Team System. MSF for Agile Software Development Metodika MSF for Agile Software Development vychází z agilního pojetí vývoje. (Více se dozvíte na stránkách Soustředí se na rychlost a flexibilitu vývoje, nicméně zachovává nezbytnou míru dokumentace a definice procesů. Vyznává iterativní postup založený na scénářích, pracuje s požadavky na kvalitu a riziky. Postup projektu je definován úspěšností testů a dalšími objektivními metrikami. Ukázka hotových procesních šablon, které jsou součástí dodávky produktů řady Microsoft Visual Studio Team System.

10 MSF for CMMI Process Improvement Metodika CMMI (The Capability Maturity Model Integration) byla vyvinuta v The Software Engineering Institute s (SEI). Jedná se o soubor pravidel, požadavků a doporučení, které mají splňovat firemní procesy a oto, co je třeba dodržovat, aby procesy vývoje byly efektivní, účinné a spolehlivé. Důležitou charakteristikou modelu, která jej odlišuje od norem primárně zaměřených na procesy a kvalitu výroby je právě zaměření na procesy vývoje. Cílem je dosáhnout kvality a spolehlivosti výsledků za pomoci kontinuálního vylepšování a sledování parametrů. Celý teoretický model CMMI je rozdělen do pěti úrovní. Oproti certifikaci dle relativně černobílého pohledu často vyžadovaných norem ISO 9 001:2 000 je model CMMI u nás málo známý. V zahraničí je potvrzení o 3. úrovni CMMI mnohem významnějším kritériem posuzování kvality softwarové firmy než vlastnictví certifikátu podle normy ISO 9001:2000. Obě normy jsou si přesto velmi blízké a splněním požadavků modelu CMMI úrovně 3 je firma krůček od splnění normy ISO 9001:2000. Implemetace MSF for CMMI Process Improvement v rámci Visual Studio Team System si klade za cíl dosáhnout třetí úrovně (CMMI level 3) zmíněné teorie s minimální byrokracií a co nejmenší množinou dokumentace Architektura, od modelu k nasazení Podstatou činnosti téměř každého návrhu informačního systému je transformace informací vnějšího světa na data, proces, který můžeme na různých úrovních modelovat. V praxi se bohužel neustále opakují situace, kdy jsou pomocí specializovaných CASE nástrojů modelovány požadavky zákazníků i obchodní logika aplikace, jenž jsou v praxi dále využity pouze pro počáteční design a vygenerování úvodních stohů detailní dokumentace. Obojí se časem stane neaktuální a jejich další udržování je dražší než vývoj. Celá koncepce modelování ve Visual Studio Team System je naopak postavena na přesvědčení, že model musí být základním stavebním kamenem, který je však živý, aktuální, schopný neustálé dekompozice a musí být propojen s kódem ve všech fázích životního cyklu aplikace až k nasazení do provozu. Tento pohled na vývoj s sebou však nese menší orientaci na abstraktní konceptuální modelování. Lze říci, že modelování ve VSTS se soustředí více na vytvoření Živé předlohy fungování, než detailního popisu systému. Visual Studio Team System pracuje s pojmem System Definition Model (SDM), který propojuje jednotlivé části návrhu, tvorby a nasazení distribuovaných aplikací s ohledem na softwarové části včetně infrastruktury, tak i na HW zařízení. Jako popisný jazyk je použit DSL, Domain-Specific Language. Visual Studio Team System for Software Architects pak nabízí k podpoře modelování visuální modelovací nástroje jako Application Designer, System Designer, Logical Datacenter Designer a Deployment Designer. Pro objektové modelování již na úrovni tříd je dodáván ve všech vyšších verzích Visual Studia Class Designer. Tři fáze modelování distribuovaných aplikací 1. Vytvoření definice systému 2. Automatická alokace zdrojů, případně konfigurace podle definice 3. Funkcionalita systému v jeho životním cyklu 4.3. Prevence chyb je mnohem levnější než jejich pozdější odstranění Hodnotocentrický přístup používaný ve VSTS měří jen ty výsledky, které ocení jako hodnotné zákazník. Více než cokoli jiného to znamená dodat fungující kód v kvalitě přiměřené pro zákazníka. Všichni víme, že dodat dobrý kód včas je mnohem levnější, než odstraňovat chyby později. Ale teprve v posledních deseti letech se techniky posunuly od představ typu kompletní kód, kde se odstraňování chyb považuje za činnost, kterou lze odkládat na později, k vývoji řízenému testy, kdy se soustřeďujeme na prevenci chyb, přičemž v okamžiku zanesení změn musí testy úspěšně projít. 10

11 Pro každou profesionální softwarovou aplikaci existuje nekonečně mnoho možných testů. Z toho plyne, že většina organizací vývoje softwaru a IT věnuje signifikantní objem prostředků ze svého rozpočtu na testování, ať už se děje doma nebo prostřednictvím outsourcingu. Testovací činnosti mají dva obecné účely: Podporovat vývojové činnosti vývojářů aby psali dobrý kód. Dodržet požadavky zákazníků a slíbené vlastnosti řešení, což mají na starosti testeři. Vývojář musí být obecně schopen dodat rychle kvalitní kód, který dělá přesně to, co je požadováno, je opakovatelně použitelný, popsaný a pokud možno i zdokumentovaný. K tomu všemu pomáhají různé nástroje pro profiling, optimalizaci kódu jakož i nástroje pro statickou analýzu, unit testy nebo grafické znázornění pokrytí kódu testy Pokrytí vývojářova kódu unit testy je znázorněno graficky i numericky. Testeři návrhují co, kdy a jak testovat. Přípravují testy a zajišťují jejich provoz. K tomu mají možnost využívat Ruční testy, Automatizované scénáře nebo Zátěžové testování. Při své práci by se měl tester ve Visual Studiu řídit těmito pravidly: Testování by mělo být optimalizované tak, aby našlo důležité problémy rychle, ne se pokoušet najít všechny problémy se stejnou naléhavostí. Testovací strategie by měla soustředit většinu úsilí na oblasti s potenciálním technickým rizikem, přesto by jisté úsilí mělo být také věnováno oblastem s nízkým rizikem, už jen pro případ, že by byla analýza rizik špatná. Testovací strategie by měla být rozmanitá co se týče testovacích technik a perspektiv. Metody vyhodnocující pokrytí testu by měly brát v úvahu rozměr strukturální, funkční, datový, platformový, operační a specifických požadavků odběratele. Typický výstup Zátěžového testování aplikace. 11

12 4.4. Nezapomeňte na databáze, jsou téměř v každém projektu Mnoho vývojových týmů tvoří aplikace s použitím různorodých nástrojů na podporu jejich životního cyklu. Dokonale dodají dokumentaci, zdrojové kódy i jejich změny ale provázání na odpovídající změnové stavy datových struktur, uložených procedur, zaznamenané testy a další detaily týkající se databázové části chybí nebo jsou špatně dohledatelné. Odpovědí může být speciální týmová edice vývojového produktu určeného pro databázového vývojáře, v případě Visual Studia Team Edition for Database Professionals. Jejím cílem je umožnit plnohodnotné začlenění vývojářů pracujících s databázemi (Microsoft SQL Server) do celého procesu správy životního cyklu aplikace. Základem je speciální typ projektu Databázový projekt a jeho uložení do sdíleného verzovaného úložiště v Team Foundation Serveru. Zde můžete změny asociovat s jejich důvodem např. chybou, kterou opravujete, úlohou, kterou plníte apod. Při vývoji aplikace se pak můžete setkat s mnoha úkoly, které se ve světě databází nemusejí snadno řešit. Jedná se o generování dat, porovnávání schémat nebo dat, testování či refaktoring potřebu přejmenovat některé databázové atributy včetně propagace změny ve všech uložených procedurách, trigerech, ale i testech nebo konfiguračních souborech. Visual Studio Team Edition for Database Professionals obsahuje nástroje plnící všechny podobné požadavky a přináší zajímavé možnosti pro změnové řízení, testování a nasazení databázových projektů. Databázový projekt Visual Studia a formulář Rename Refactoring Mnoho rozměrů zdraví projektu Proč serverová část Visual Studio Team Foundation Server obsahuje také OLAP Server a Reporting Server? Zkuste chvilku popřemýšlet o nejobvyklejších reportech, které při sledování svého projektu používáte. Obvykle byste mezi nimi našli: Čas strávený nad úkoly (nejlépe plánovanými i neplánovanými). Počet chyb (nejlépe i s poměry nalezených a opravených). Dokončené úkoly projektu, oznamované jednotlivými pracovníky (nejlépe měřené podle scénáře, vlastností, požadavků na kvalitu nebo jiných, pro zákazníka uchopitelných, jednotek). Využití zdrojů, včetně lidských, obvykle vedené účetním způsobem. Položky bývají obvykle měřeny samostatně. Softwarové projekty však mají ještě mnoho dalších ovlivňujících se stránek a každá z nich může být důležitá. Když je budete sledovat, získáte příležitost brzy odhalit výjimky a slabá místa, která vyžadují úpravy směru. Vícerozměrnost vám přitom pomáhá zaručit, že metriky jako celek vypovídají detailně, smysluplně a dokážete v nich nalézt důležité závislosti. 12

13 Proces Zdrojový kód Test Metrika Pracovní položky Portál Datový sklad metrik Reporty Obrázek 1.11 Sklad metrik sbírá data o všech činnostech prováděných s projektem a na jejich základě Vícerozměrné vytváří zprávy, které metriky různé zdroje projektu a druhy dat a uvádějí portál do vzájemných s reportingem. souvislostí. Na rozdíl od mnoha starších modelů projektu, kde sběr metrik projektu probíhá izolovaně, Visual Studio Team System kombinuje metriky v datovém skladu metrik pomocí společné sady analytických kostek a společných reportů pro více rozměrů. Kdykoli je možné získat kompletní přehled o veškerém dění v rámci projektu a analyzovat směr postupu. Možnost vidět více druhů údajů o projektu současně je přímou výhodou skladu metrik, který sbírá informace o denní činnosti a uvádí je ve vzájemnou souvislost. Tímto způsobem můžete dosáhnout průhlednosti nutné pro nejpřísnější výkazy, aniž byste přitom museli obětovat agilní způsob práce. Navíc můžete sledovat i projekty vzdálené, nebo dokonce i projekty zadané partnerským subjektům, a to stejně, jakoby se jednalo o projekty místní. VSTS pracuje s myšlenkou průhledného společného úkolníku pro veškerou plánovanou, aktivní a hotovou práci týmu, včetně historie většiny provedených akcí a rozhodnutí, které se této práce týkají. Těmto jednotkám se říká pracovní položky (work items), umožňují uživateli prohlížet si je a upravovat je v databázovém pohledu ve Visual Studiu. Microsoft Excel a Microsoft Project a zajišťuje jejich neustálou synchronizaci se společnou databází. Proces Zdrojový kód Test Metrika Pracovní položky Portál Excel Project Klient Team Foundation Visual Studio Pracovní položky Scénář Požadavek na kvalitu Vývojářský úkol Úkol pro testování Chyba Riziko Obrázek 1.6 VSTS tím, že spojuje zdrojový kód, testování, pracovní položky a metriky dohromady, režíruje Nejnižší a diriguje obecná celý proces. úroveň Pracovní detailu položky zahrnují je vázaná vše, co je třeba na u pracovní projektu sledovat, položky. například scénáře, požadavky na kvalitu služby, vývojářské úkoly, úkoly pro testování, chyby a rizika. Můžete si je prohlížet a upravovat je v Team Exploreru, Visual Studiu, Microsoft Excelu nebo Microsoft Projectu. 13

14 4.6. Sledování ukazatelů kvality Na kvalitu je třeba nahlížet z mnoha směrů. Následující graf spojuje výsledky testů, pokrytí kódu testy, množství změn v kódu a chyby, abyste mohli sledovat několik aspektů současně. Příklad ukazatele kvality. Podobné reporty jsou dostupné na projektovém portálu. Sloupce ukazují kolik testů bylo spuštěno a kolik z nich vrátilo výsledky Pass (Úspěch), Fail (Neúspěch) a Inconclusive (Nelze rozhodnout). První řada bodů představuje pokrytí kódu (Code Coverage), které tyto testy dosahují. Za normálních okolností by se s tím, jak se zvyšuje počet spouštěných testů, mělo zvyšovat i pokrytí kódu. Jestliže ale spouštění testů a jejich úspěšnost narůstají, aniž by se odpovídajícím způsobem zvýšilo pokrytí kódu, může to značit, že jsou některé inkrementální testy nadbytečné. Druhá řada bodů reprezentuje množství změn v kódu (Code Churn), což je počet přidaných a změněných řádků v testovaném kódu. S vysokým objemem změn pochopitelně souvisí i riziko, že se spolu se změnou do kódu dostane i chyba. U bezchybně refaktorizovaných projektů můžete vidět změny kódu, které nijak neovlivňují pokrytí kódu nebo úspěšnost testů. Vysoký objem změn jinak může znamenat klesající pokrytí a potřebu přepsat testy. Třetí řadou je počet aktivních chyb (Active Bugs). Je zřejmé, že by měla existovat souvislost mezi počtem aktivních chyb a počtem neúspěšných testů. Jestliže počet aktivních chyb roste a vaše testy neukazují odpovídající neúspěchy, pravděpodobně nezkoušejí tutéž funkčnost ve stejném kontextu, ve kterém jsou chyby ohlašovány. Podobně, když množství aktivních chyb klesá a úspěšnost testů se nezvyšuje, může vám hrozit nárůst počtu opětovně otevíraných chyb. Jednotlivé řady jsou zobrazeny v různém měřítku, aby byl graf na svislé ose čitelný A co na to auditor? Softwarové týmy se nyní běžně setkávají s požadavky regulátorů. Například v USA musejí všechny finanční systémy veřejně obchodovatelných společností podle Sorbanesova-Oxleyho zákona z roku 2002 procházet audity. Pro tvůrce software to znamená, že musejí mít efektivní procesy a nástroje pro správu a kontrolu veškerých svých činností. VSTS automaticky eviduje všechny změny pracovních položek, automaticky je propojuje se všemi změnami ve zdrojovém kódu a v testech. První krok správným směrem je tudíž vhodně zvolená metodika v prostředí Visual Studio Team System a nastavení vhodných politik kontroly kódu, nejlépe již při vložení do systému Jestliže se vás audity týkají, měli byste vynutit spojení zanášených změn s pracovními položkami, aby byly změny ve zdrojovém kódu spojeny se změnami pracovních položek. Pro vývojáře to pouze znamená zaškrtnout při zanesení změny jedno políčko. Když toto pravidlo zavedete, a vývojář na to zapomene, bude upozorněn a odpovídajícímu členovi týmu bude doručeno em upozornění také. Je možné zavést i restriktivnější způsob, kdy kontrolu celého vkládaného kódu musí provést jiný vývojář. Pro striktní kontrolu při převodu finálního řešení na produkční prostředí zase použijete pokročilé funkce branch/merge práce s větvemi zdrojového kódu. 14

15 Visual Studio Team Foundation Server ukládá všechny historické údaje v úložišti, které splňuje veškeré podmínky auditovatelnosti. Záznamy a zdrojové kódy nelze uživatelsky fyzicky vymazat a lze dohledat přesnou časovou historii změn, požadavků nebo i nejmenších poznámek vložených do systému Nadstavby a partnerská řešení využívající VSTS Jednotné prostředí produktů Visual Studio Team Systém s otevřeným API a dostupným SDK přímo pobízí partnerské firmy k tomu, aby tvořili nadstavby pro VSTS nebo propojovali své vlastní prostředí se serverovou infrastrukturou. Microsoft dodává klientské řešení pro starší vývojové prostředí Visual Studia ale např. i FoxPro, stejně jako pro Excel a MS Project. Mnoho partnerských firem jako např. Compuware, Serena, Borland a další propojují své produkty nebo tvoří speciální nadstavby. Aplikace využívající jednotné serverové prostředí nemusí být určeny pro vývoj aplikací na platformě OS Windows a také zde nemusí být provozovány. Ukázka IDE prostředí Eclipse pro vývoj Java aplikací, doplněný o nástroje ty Teamprise, přistupující přímo k Microsoft Visual Studio 2005 Team Foundation Serveru. Umožňují vývojovým týmům řídit projekty, pracovat se zdrojovými kódy, sledovat stav pracovních položek či využívat reportovacích služeb jednotné serverové infrastruktury VSTS a přitom pracovat na platformě Linux nebo Mac OS X. 15

16 Kde naleznete více informací Pokud hledáte další informace o problematice podpory životního cyklu IT řešení založených na technologiích společnosti Microsoft, nepřehlédněte následující webové odkazy: Homepage Microsoft Operation Framework Homepage Microsoft Solution Framework Homepage Microsoft Visual Studio Team System Specializovaný web, který se věnuje produktové řadě Visual Studio 2005 Team System. Naleznete zde veškeré podstatné informace. Abychom vám ušetřili práci, nabízíme zde k vyzkoušení i hostovaný Visual Studio Team Foundation Server, kde vám vytvoříme účet a vzorový projekt. K dispozici je též ke stažení český návod k vyzkoušení. Pokud vás produkty řady Visual Studio Team System zaujaly a myslíte, že se vám investice do jejich nákupu a používání může vrátit, zjistíte zde i podrobné údaje o cenách a licencování. Lokální web pro vývojáře, odkud lze stáhnout mnoho multimediálních návodů, elektronických knih a jiných materálů v češtině. Vydavatelství Zoner Press vydává překlad publikace Software Engineering with Microsoft Visual Studio Team System (288 str., Addison-Wesley, 2006). Publikaci je možno zakoupit také na internetových stránkách vydavatelství Předplatitelé MSDN mohou uplatnit 20% slevu z plné ceny 300 Kč Microsoft Corporation. Všechny názvy výrobků, jména autorů a vydavatelů, loga, značky, obchodní známky, obrázky a s nimi související zobrazení mohou být obchodními značkami a známkami jednotlivých vlastníků. SPOLEČNOST MICROSOFT NEPOSKYTUJE ŽÁDNÉ ZÁRUKY, VÝSLOVNĚ UVEDENÉ, PŘEDPOKLÁDANÉ NEBO ZÁKONNÉ, NA INFORMACE UVEDENÉ V TOMTO DOKUMENTU.