Vývojové nástroje a nástroje pro týmovou spolupráci formou ASP

Transkript

1 Vývojové nástroje a nástroje pro týmovou spolupráci formou ASP Petr Hamerník Katedra informačních technologií Vysoká škola ekonomická v Praze phamernik@volny.cz Abstrakt: Text se věnuje problematice vývojových nástrojů a jejich možnému provozu formou ASP. Na základě relevantních trendů v ICT ukazuje motivaci takového řešení. Hodnotí vhodnost a využitelnost vývojových nástrojů formou ASP z hlediska různých kritérií. Popisuje jednotlivé subjekty účastnící se ASP a jejich pohledy na problematiku vývojových nástrojů ASP. Mapuje aktuální situaci na trhu. Na závěr naznačuje celkové řešení ASP vývojového nástroje spolu s jeho přínosy a nedostatky. Klíčová slova: Vývojové nástroje, Application Services Providing, Open Source Software, outsourcing, týmová spolupráce Úvod Vývojové nástroje patří k nejdůležitějšímu softwarovému vybavení pro každou počítačovou platformu, ať už jde o hardwarovou architekturu (např. PC, PDA nebo mobilní telefony), operační systém (Linux, Windows, Mac OS X, atd.) nebo jakoukoli aplikační platformu (např. J2EE nebo.net). Užitek každé platformy se zvyšuje s množstvím a kvalitou programů pro ní vyvinutých. S lepšími nástroji jsou vývojáři produktivnější a vytvořený software dosahuje lepších kvalit. Kvalitu a dostupnost vývojových nástrojů můžeme tedy považovat za jednu z nejdůležitějších nepřímých síťových externalit k dané platformě. 1 Čím kvalitnější a dostupnější jsou nástroje, tím úspěšnější bude platforma. Tento text se věnuje vývojovým nástrojům z pohledu poměrně nové varianty outsourcingu IS/ICT outsourcingu formou ASP (Application service provider). ASP se začal objevovat v druhé polovině devadesátých let dvacátého století, ale mimo jiné díky kolapsu technologické bubliny na přelomu tisíciletí jeho popularita brzy klesla. V posledních letech se zdá, že model ASP dozrál a chytá druhý dech ([ASPNews, 2005a]). Druhá kapitola tohoto textu se snaží identifikovat ICT trendy, které vedou k domněnce, že vývojové nástroje mohou být provozovány modelem ASP: postupná integrace nástrojů, změny metod vývoje softwaru s významným podílem softwarově podporované týmové spolupráce a změny architektur systémů směrem k web-centric aplikacím. Třetí kapitola hodnotí možnosti uplatnění nástrojů formou ASP z hlediska různých kritérií. Čtvrtá kapitola vymezuje hlavní role v konceptu ASP vývojových nástrojů a sleduje pohledy každé z nich. Cílem páté části je zmapovat současné poznatky o problematice a aktuální stav na trhu co přináší akademický svět a co softwarový průmysl. 1 Síťové externality u softwaru jsou poměrně probádané téma. Více informací lze najít například v [Katz, Shapiro, 1985]. 52 SYSTÉMOVÁ INTEGRACE 3/2005

2 Vývojové nástroje a nástroje pro týmovou spolupráci formou ASP V poslední části jsou naznačeny vlastnosti ASP vývojového nástroje, popsány jeho přínosy a nedostatky. Na úvod je ještě potřeba vymezit následující pojmy: Web-enabled aplikace obvykle starší software, původně vyvíjený jako klasická desktopová aplikace, přizpůsobený pro použití přes webový prohlížeč. [Voříšek a kol., 2003, str ] Web-centric aplikace aplikace od počátku navrhované a vyvíjené jako vícevrstvé aplikace s tenkým klientem běžícím ve webovém prohlížeči. [Voříšek a kol., 2003, str. 169] 1. Trendy 1.1 Integrace nástrojů - IDEs Smyslem nástrojů pro vývoj softwaru je usnadňovat vývoj a zlepšovat produktivitu práce programátorů. Je tedy nutné, aby co nejlépe podporovaly vývoj aplikací odpovídajícím nejnovějším softwarovým trendům. Stejně jako jiné programy, byly samozřejmě i vývojové nástroje v každé době limitované momentálním výkonem počítačů. Vývojové nástroje vznikaly nejprve jako jednoúčelové programy spustitelné obvykle z příkazové řádky (compiler, editor, debugger, atd.). Časem docházelo k jejich integraci do prostředí IDE (Integrated development environment). Rostoucí výkony počítačů postupně umožňovaly zlepšování funkcionality prostředí IDE a integraci stále více nástrojů potřebných pro vývoj softwaru. S přechodem operačních systémů od textových ke grafickým rozhraním GUI (Graphical user interface), jako Windows nebo X Window, se ve většině IDE objevila podpora rychlého návrhu grafických aplikací (GUI builder). Se změnou architektury od decentralizovaného jednovrstvého softwaru pro PC k modelu klientserver a později k vícevrstvým architekturám přibývají další možnosti. Vývojové nástroje musí podporovat vývoj klientských i serverových částí aplikací postavených nad různými standardy. Jak přibývají nové technologie, formáty nebo protokoly, konkurující si IDE se předhánějí, které z nich nabídne podporu dříve. Složitost prostředí IDE tím samozřejmě roste. Dnešní dominantní nástroje jsou velmi komplexní aplikace a značné části jejich funkcionality využívá pouze omezené množství vývojářů. Podobný trend můžeme vidět u mnoha dalšího typového softwaru, například u kancelářských aplikací typu MS Word nebo Excel. Jen velmi málo koncových uživatelů využije veškerou jejich funkcionalitu. Podpora každé nové technologie je motivována snahou zrychlit a zautomatizovat opakující se činnosti programátorů, odstínit je od nepodstatných detailů nové technologie. Rostoucí poptávka po programátorech má za následek jejich klesající kvalifikaci. Moderní vývojové nástroje umožňují díky sofistikovaným podporám zapojení i těchto méně kvalifikovaných programátorů. Stejně jako jiné komplexní aplikace, také prostředí IDE byla nucena postupem času k přechodu na výrazně modulární architektury. Jednotlivé nezávislé moduly podporují vždy některou konkrétní technologii. Modularita IDE dovoluje nainstalovat do prostředí podporu jen pro potřebné technologie. SYSTÉMOVÁ INTEGRACE 3/

3 Petr Hamerník Díky nárůstu výkonu počítačů umožňují moderní IDE získávat a poskytovat programátorovi mnohem více informací o programu ze zdrojových kódů, dokumentace, ových archivů a dalších zdrojů. To dává možnost například dělat dříve nemyslitelný (nebo velice obtížný) refactoring softwaru. S použitím takové podpory je také orientace v neznámém kódu o mnoho snazší, čímž se dále významně přispívá ke zvyšování produktivity práce vývojářů. 1.2 Týmová spolupráce a vliv nových metod vývoje Software není ve většině případů dílem jednotlivců, ale týmu programátorů a dalších profesí. Také týmová spolupráce při vývoji softwaru prošla za poslední léta celou řadu změn. V softwarových týmech dochází k zapojování stále více profesí a větší specializaci jednotlivých rolí. S rostoucími nároky na uživatelská rozhraní programů je potřeba do týmů začleňovat grafiky a specialisty na uživatelská rozhraní (v závislosti na typu programu designéry uživatelských rozhraní, tvůrce ikon, specialisty na hudbu, animace, atd.). Do vývoje vícevrstvých aplikací je pak potřeba zapojit odborníky v oblasti instalace a správy webových, databázových a aplikačních serverů, administrátory síťové infrastruktury. I samotné kompilování a sestavování výsledného softwaru (tvorba různých jazykových verzí nebo verzí sestávajících z různých modulů) je dnes obvykle vyhrazeno speciální profesi nazývané release ingeneering. Objevují se také nové metodiky vývoje softwaru. Do poloviny devadesátých let byl obecně přijímaný názor J. P. Brookse [Brooks, 1995], že kvalitní software není možné vytvořit ve velkých týmech, natož týmech lidí, kteří společně nesdílí pracoviště. Open Source projekty Linux a Apache ukázaly, že tomu tak být nemusí. Konektivita zajištěná Internetem přinesla do vývoje softwaru nové metody. Ukázalo se, že nejen Katedrály 2, ale také Bazaary dokáží vyprodukovat konkurenceschopný software [Raymond, 2000]. Komunitní vývoj, jakým vznikají OSS projekty, založený na dobrovolné účasti jednotlivců, se jeví v posledních letech přínosný i pro mnoho softwarových firem. Důležité je nalézt vhodný obchodní model, jak s použitím OSS vývoje profitovat. Softwarová podpora týmové práce bývala často dříve omezena na společný systém pro správu verzí souborů (revision control system např. CVS 3 ) a některý ze systémů pro evidenci chyb (a samozřejmě ). Dnes je tato podpora týmové práce, díky rostoucímu výkonu počítačů a zlepšující se konektivitě, na mnohem lepší úrovni a dá se předpokládat, že tento trend bude pokračovat. Samozřejmě velká část této podpory není vázána pouze na vývoj softwaru, ale uplatňuje se v mnoha dalších oborech. Mezi hlavní trendy patří: Hlasové/Video konference Instant messaging postupně integrovaný do IDE; společná pracovní tabule, sdílený pohled na zdrojový kód s možností společné editace, společná schránka (clipboard), přes níž je možné na dálku vyměňovat části zdrojových 2 Pojmem Katedrála je označován proprietární vývoj softwaru obvyklý v softwarových firmách, naproti tomu Bazaar je způsob komunitního vývoje s dostupnými a volně šiřitelnými zdrojovými kódy používaný v Open Source SYSTÉMOVÁ INTEGRACE 3/2005

4 Vývojové nástroje a nástroje pro týmovou spolupráci formou ASP kódů (např. kódů metod nebo objektů) to vše například umožní uplatnění XP (Extreme Programming), kdy vývojáři mohou sedět na opačných stranách Země. Off-line komunikace - Diskusní fóra, budování společných znalostí a dokumentace například pomocí systému Wiki 4 Integrace jednotlivých systémů (správa verzí, diskusní fóra, evidence chyb, wiki, atd.) - např. vyhledání informací pro daný řádek kódu kdo a kdy jej změnil, jaký problém tím řešil, co bylo řečeno o tomto problému v diskusních fórech, sémantická analýza zdrojových kódů pro zjištění dopadů opravy, apod. Získávání informací o probíhajícím vývoji kontinuálně probíhající automatické testy softwaru (chybovost, výkon, paměťová náročnost, atd.) s okamžitým upozorněním na možné dopady (regrese) po integraci změny kódu; generování reportů o aktuálních změnách ve vyvíjeném softwaru, analýzy dopadů 1.3 Směrem k web-centric aplikacím Webově založené aplikace (web-centric) můžeme považovat za přirozené vyústění přechodu od decentralizovaných aplikací pro PC přes dvouvrstvé aplikace klientserver až k dnes nejběžnějším vícevrstvým architekturám. Za podstatné faktory ovlivňující přechod k tenkým klientům běžícím ve webovém prohlížeči můžeme považovat: Rozšíření typů koncových zařízení od prakticky monopolní kombinace PC MS Windows k dalším operačním systémům (např. Linux), mobilním telefonům, PDA, atd. Nulová potřeba správy (instalace, údržba,...) na koncových stanicích v případě použití webového prohlížeče Potřeba dostupnosti z libovolného místa z Internetu Stále více softwaru je dnes vyvíjeno jako web-centric, případně je přizpůsobováno jako web-enabled od již klasických jako nebo aplikací typu mobilní kancelář, až po komplexní aplikace jako CRM nebo ERP. Také ve vývoji softwaru a v nástrojích týmové spolupráce (z předchozí podkapitoly) můžeme pozorovat rostoucí podíl softwaru provozovaného ve webovém prohlížeči (např. Bugzilla, web rozhraní k CVS, Wiki a další systémy). 2. Nástroje jako služba 2.1 Motivace Současné vývojové nástroje jsou z velké části rozsáhlé jednovrstvé aplikace provozované na koncových stanicích. Pokud o nich chceme uvažovat jako o předmětu ASP, musíme si položit otázku, zda vůbec lze nástroje provozovat jako 4 SYSTÉMOVÁ INTEGRACE 3/

5 Petr Hamerník vícevrstvé web-centric aplikace. 5 Z trendů popsaných v předchozí kapitole vyplývá, že odpověď je zřejmě ano. Shrňme si hlavní argumenty: Centralizace vývoje softwaru všechny artefakty se přesouvají na jedno centrální místo (zdrojové kódy, správa chyb, diskusní fóra, projektové plány, sdílené knowledge base, atd.) Rostoucí podíl distribuovaných týmů kvůli podpoře týmové práce se změna architektury současných IDE na web-centric aplikace přímo nabízí. Integrace nástrojů pro vývoj softwaru do jednoho celku v současnosti stále převládá klientské IDE na koncové stanici, ale roste podíl web-centric nástrojů používaných při vývoji. Rostoucí velikosti prostředí IDE podpora stále více různých architektur/technologií, značná část není využívána a nebo jen příležitostně. Přesto je často nainstalována na všech koncových stanicích. Komplikovaná instalace a údržba infrastruktury pro vývoj a testování (webové, aplikační, databázové servery, sítě, zálohování, atd.) tím roste potřeba nových specializovaných rolí ve vývoji. Tyto zdroje by bylo možné sdílet. Rostoucí podíl web-centric aplikací díky zlepšující se konektivitě existuje stále více (i velice rozsáhlých) aplikací jako web-centric např. systémy CRM, ERP, kancelářské aplikace. Vývojové nástroje se od těchto příkladů neliší výrazně svým charakterem (komplexností, nutností rychlé odezvy, kvalitním uživatelským rozhraním, atd.). Nástroje pro vývoj softwaru tedy zřejmě bude možné provozovat jako web-centric aplikace. Jejich provoz jako ASP je dalším krokem. 2.2 Hodí se nástroje jako ASP? Na základě [Daylami at al, 2005], [Voříšek a kol., 2003, str ], [Voříšek, 2005] a [Voříšek, Feuerlicht, 2004] je možné identifikoval následující kritéria, zda je vývojové nástroje možné a vhodné provozovat formou ASP: Možnost provozu jako web-centric případně web-enabled: Z předchozího textu plyne, že mnohé z (částí) nástrojů jsou již dnes web-centric aplikace. Vzhledem k tomu, že jako web-centric lze provozovat i poměrně komplexní aplikace, neměl by být problém vytvořit tak celá vývojová prostředí. Malé nároky na customizaci pro jednotlivé uživatele: U žádné součásti ASP vývojového nástroje není potřeba výrazná customizace. Samotná dnešní prostředí IDE jsou typizovaný aplikační software, který nenabízí mnoho možností vlastních nastavení. Stejně tak se dá očekávat, že ani další součásti ASP nástroje (aplikační a databázové servery a další infrastruktura) nebudou vyžadovat speciální úpravy pro každého zákazníka. Možnost provozu 1:N: Ani zde není žádný důvod, proč by nástroje pro vývoj nebylo možné provozovat pro více klientů současně. Podmínkou je 5 Tenký klient ve webovém prohlížeči není sice striktní předpoklad ASP, ale jde o nejběžnější typ klienta. V roce 2002 měl webový prohlížeč 39% zastoupení mezi klientským softwarem [Voříšek a kol., 2003, str. 180]. Vzhledem k složitější instalaci a údržbě v případě jiných specializovaných klientů se dá předpokládat, že podíl webového prohlížeče jako klientského softwaru poroste. 56 SYSTÉMOVÁ INTEGRACE 3/2005

6 Vývojové nástroje a nástroje pro týmovou spolupráci formou ASP samozřejmě oddělený datový prostor pro jednotlivé zákazníky, jako je tomu u každého ASP softwaru. Snadná správa a údržba: Upgrady jednotlivých komponent by neměly být pro zákazníka příliš pozorovatelné, pokud tyto komponenty zachovávají zpětnou kompatibilitu. Samozřejmě při jejím porušení by neměl být problém převést automatizovaně všechna zákazníkova data na nový formát. Krátká doba odezvy: Při vhodně navrženém rozhraní je možné zvládnout i tento (kritický) faktor. Důležité při realizaci nástroje ASP je vhodné rozložení zpracování mezi tenkého klienta a vlastní aplikaci na serveru a minimalizaci přenosu dat. Ale i to lze dnes dosáhnout. Možnosti integrace: Integrace je dalším z klíčových faktorů nasazení softwaru jako ASP. Většinu jednotlivých web-centric nástrojů by mělo být možné relativně snadno propojit do integrovaného celku pomocí současných standardních protokolů (xml, web services), případně speciálních API jednotlivých komponent. Většina současných nástrojů provozovaných jako web-centric své API poskytuje. Za větší problém můžeme považovat snahu o případnou integraci s dalšími PC aplikacemi na straně klienta, ale zde záleží na konkrétním případu a možnostech. Granularita služeb, jejich definice, možnosti účtování: Lze očekávat výraznou modularitu vývojových nástrojů provozovaných formou ASP. Díky tomu by bylo možné prodávat zvlášť moduly pro jednotlivé technologie. Kromě toho již ze samotného charakteru ASP vyplývá možnost sledovat využití jednotlivých částí různými zákazníky a to otevírá mnoho možností, jak nástroje ASP zpoplatnit. Z porovnání kritérií plyne, že v principu by nic nemělo bránit nasazení vývojových nástrojů formou ASP. 3. Subjekty účastnící se ASP Podívejme se na nástroje z pohledu různých subjektů, účastnících se celého ASP. V jakémkoliv ASP najdeme mnoho rolí [Voříšek a kol., 2003, str ]. Pro účely této práce se ale budeme věnovat jen těm, které vykazují odlišnosti oproti jinému druhu softwaru provozovanému formou ASP. V tomto ohledu můžeme považovat za zajímavé pohledy: vývojářů, kteří jsou uživateli ASP vývojového nástroje poskytovatele/výrobce vývojového nástroje koncových zákazníků, tedy uživatelů koncové aplikace vyvinuté pomocí ASP nástroje 3.1 Pohled vývojářů (uživatelů ASP nástroje) Vývojáři (softwarové firmy) hrají v případě vývojových nástrojů ASP roli zákazníků uživatelů služby. Z trendů naznačených ve druhé kapitole je patrné, že rostoucí podíl při práci vývojářů zaujímají webové nástroje. Jejich výhodou je, že pracují přímo na místě, kde jsou příslušná data uložena tedy na serveru. To umožňuje mnohem efektivnější sdílení, vyhledávání a analýzy nad daty různých typů (zdrojové kódy, chyby, dokumentace, diskusní fóra) bez nutnosti mít všechna data lokálně. SYSTÉMOVÁ INTEGRACE 3/

7 Petr Hamerník Podpora vývojáře bude v tomto smyslu v budoucnu rozhodně na mnohem vyšší úrovni než je tomu dnes. Nástroje získají vyšší inteligenci, budou lépe rozumět sémantice kódu. Díky objemu dat velkých projektů bude do budoucna taková podpora možná díky web-centric vývojovým nástrojům. Vývojové nástroje ASP umožní také lepší spolupráci v rámci týmů. Zlepší se i komunikace s koncovým zákazníkem, pokud bude mít zákazník přístup do určitých částí vývojového nástroje. Softwarové firmy (vývojáři) používáním ASP vývojového nástroje outsourcují podpůrné informatické služby nezbytné pro vývoj softwaru. Významnou roli tedy bude také hrát jedna ze základních motivací pro používání jakékoholiv outsourcingu zaměření se na vlastní podnikatelskou činnost, což je v případě softwarových firem vývoj softwaru. Při rostoucí komplexnosti dnešních aplikací není přidaná hodnota softwarové firmy v tom, že umí nainstalovat síť, operační systémy a webové, databázové či aplikační servery. Podstatné je vyvinout software nad touto infrastrukturou. Při použitím ASP vývojového nástroje softwarové firmy nemusí zaměstnávat celou řadu odborníků na instalaci a provoz této infrastruktury. V současné době jsou koncové stanice programátorů asi těmi nejnáročnějšími, pokud jde o hardware (snad s výjimkou hráčů nejnovějších počítačových her). Zkompilovat a sestavit větší software je často dokonce záležitostí minut, během kterých je počítač maximálně vytížený. Nicméně, podíváme-li se ale na obvyklou práci programátorů, podstatnou část času tráví editací zdrojových kódů, případně dalších typů souborů. Po tuto dobu je počítač zase naopak téměř nevyužitý. Z pohledu softwarových firem by nástroje ASP a jimi umožněné sdílení výkonu vedly k výrazné efektivitě počítačových zdrojů. Celá řada dalších přínosů pro softwarové firmy je společná s pronájmem jakéhokoliv jiného softwaru formou ASP předvídatelnost nákladů, možnost vyzkoušení, rychlost využití a další. ASP nástroje by ale na druhé straně vedly ke komplikovanější práci vývojářů offline. Pro práci s takovým nástrojem je konektivita nezbytná. Technicky by asi bylo možné část dat uložit lokálně, ale práce bez připojení by byla zřejmě velice limitovaná. Tuto nevýhodu můžeme ale považovat za poměrně dočasnou, protože možnosti konektivity se v posledních letech razantně zlepšují. Mobilní komunikace v nedaleké budoucnosti pravděpodobně zcela odbourá tuto nevýhodu. 3.2 Pohled poskytovatele/výrobce nástrojů Výrobce nástrojů a jejich poskytovatel jsou sice dvě oddělené role, dá se ale očekávat jejich časté propojení. Každý výrobce nástrojů je bude chtít sám provozovat formou ASP, aby nepřicházel o část svých možných zisků. Naopak ASP provozovatel cizích nástrojů by byl proti jejich výrobci v podstatně slabší pozici, protože dobrá vazba přímo na tvůrce softwaru je velmi důležitá. Spojení role výrobce a poskytovatele nástroje přináší významné výhody firma bude vědět, jak je její nástroj využíván. Pomocí různých monitorovacích technik může zjišťovat slabá místa a chyby nástroje a velice rychle je napravovat. Výrobce softwaru se vlastně dostane přímo k uživateli a může lépe zjistit současné potřeby a směrovat další vývoj ASP nástrojů. 58 SYSTÉMOVÁ INTEGRACE 3/2005

8 Vývojové nástroje a nástroje pro týmovou spolupráci formou ASP Pro poskytovatele plynou z provozování nástrojů formou ASP další zřejmé výhody předvídatelné pravidelné výnosy, efektivní využití zdrojů, rozložení investice mezi mnoho zákazníků. Podstatná výhoda provozování nástrojů formou ASP vyplývá z toho, že vývojové nástroje slouží k tvorbě nového softwaru. Při vhodné obchodní strategii se dá očekávat, že poskytovatel nebude vydělávat jen na pronájmu samotných nástrojů, ale také na provozu vytvořených koncových aplikací. 3.3 Pohled koncových zákazníků Koncoví zákazníci mohou spatřovat výhodu ASP nástrojů v jejich charakteru webcentric aplikace. Webové nástroje mohou sloužit k mnohem lepší komunikaci mezi zákazníkem a vývojářem. Zákazník může dokonce přímo nástroj využívat k prototypování a tím i lepší specifikaci svých požadavků. Stejně tak může přístup k nástroji zlepšovat kontrolu již během vývoje objednané aplikace. Nevýhoda pro koncového zákazníka může vyplývat z jeho (pravděpodobně většímu) přivázání ke konkrétnímu poskytovateli ASP nástroje po dokončení vývoje objednané aplikace. 4. Aktuální stav V tuto chvíli neexistuje komplexní integrovaný webový vývojový nástroj takový, jak bylo naznačeno v předchozích částech tohoto textu. Současný výzkum a vývoj webových nástrojů (nejen formou ASP) a na trhu dostupná řešení pokrývají vždy jen dílčí oblasti problematiky. Každé takové řešení je orientované v závislosti na předchozí pozici a orientaci daného poskytovatele. Vzhledem k tomu, že k nástrojům ASP přistupují různí poskytovatelé z různých směrů, je tato kapitola rozdělená na několik částí. První část je věnována výzkumu v akademické sféře, druhá pronájmu cílové deployment infrastruktury formou ASP, třetí pak vlastní infrastrukturní podpoře vývoje (také formou ASP). Čtvrtá část popisuje začínající web-centric vývojové nástroje a poslední se věnuje přístupu výrobců hlavních nejvýznamnějších vývojových nástrojů IDE. 4.1 Výzkumné práce Díky výrazné komerční využitelnosti probíhá značná část výzkumu a vývoje nástrojů v komerční sféře. Přesto ale můžeme najít celou řadu souvisejících prací pocházejících ze sféry akademické. Ty potvrzují trendy popsané v úvodu tohoto textu. V posledních letech je velká část výzkumu zaměřena na metodiky vývoje softwaru, zejména Open Source modelu vývoje softwaru. Pozornost je věnována spolupráci v rámci rozsáhlých distribuovaných týmů (např. [Lerner, Tirole, 2002], [Bonaccorsi, 2002], [Cook at al, 2004]), kvalitě softwaru vyvíjeného modelem OSS ([Challet, Du, 2004]) a dalším vlastnostem modelu OSS. 6 Inovačním potenciálem on-line komunit (nejen při vývoji softwaru) se zabývá Füller ([Füller at al, 2004]). Trend směřující 6 Rozsáhlý seznam vědeckých prací věnovaných OSS je možné najít v archívu Massachusetts Institute of Technology: SYSTÉMOVÁ INTEGRACE 3/

9 Petr Hamerník k distribuovaným on-line týmům celkově zvyšuje potřebu web-centric podpory vývoje softwaru. Některé práce se věnují problému rozsahu současných nástrojů a integraci jednotlivých plug-in modulů. Yap a kol. například navrhují integraci pomocí webservices vyhledávání a propojování jádra vývojového nástroje s jednotlivými moduly [Yap at al, 2005]. Jde o určitou alternativu, ale v tomto případě se jedná jen o řešení dílčího problému. Integrace modulů pomocí složitých API stejně tato práce neřeší. 4.2 Development infrastruktura formou ASP S rozmachem OSS se před několika lety začaly objevovat poskytovatelé infrastrukturní podpory vývoje softwaru. Většinou nabízejí source control management systémy, evidence chyb, ové diskusní skupiny, prostor pro vlastní webové stránky projektu a datový prostor pro instalační soubory. Infrastruktura je obvykle zajištěna přímo Open Source softwarem (cvs, bugzilla, apache, atd.) případně nějakou jeho proprietární nadstavbou. Firmy poskytující tyto služby většinou nabízejí zdarma hostování OSS projektům. Zisky jsou generovány různými formami nadstandardních placených programů (lepší služby pro vývojáře s předplatným), ale také prodejem a podporou celé infrastruktury a technologie firmám. Mezi firmy poskytující tyto ASP služby patří SourceForge ( CollabNet ( CodeHaus ( a GForge ( Všichni poskytovatelé své služby postupně rozšiřují o různé nadstavby pro týmovou spolupráci, správu dokumentů a řízení projektů a další podporu. Na trhu existuje také celá řada nástrojů, které by bylo možné dále integrovat a dá se předpokládat, že k tomu výše uvedené firmy časem dospějí (Wiki, FishEye, Maven, atd.). Za poznámku ještě stojí také celá řada jednotlivých služeb nabízených firmou Google ( Někteří poskytovatelé ASP nabízejí pouze nástroje pro týmovou spolupráci, která není specializovaná pouze na vývoj softwaru například Vericenter (pronájem MSExchange nebo Lotus Notes Socialtext (komplexní nadstavba Wiki Backpack (také rozšířené Wiki Deployment infrastruktura formou ASP Na rozdíl od development infrastruktury se jedná o softwarové vybavení nutné pro běh výsledné klientské aplikace, a také její běh v testovacím režimu během vývoje. Bývá také označována jako Infrastructure ASP, případně Managed Hosting Provider. Tato infrastruktura zahrnuje webové, aplikační, databázové, zálohovací, naming a další servery nutné pro běh cílové aplikace. Pro účely tohoto textu není zajímavé, zda poskytovatel této infrastruktury dále pronajímá například hardware nebo jej zajišťuje vlastními silami (viz [Voříšek a kol., 2003, str ]). Je zřejmé, že tento segment byl z celkového konceptu ASP vývojového nástroje nejsnáze realizovatelný, proto ASP poskytovatelé této infrastruktury vznikali nejdříve. Trh se během let poměrně konsolidoval a akvizice probíhají dodnes. Z původních mnoha subjektů na trhu dnes zůstává okolo desítky významných ([ASPNews, 2005b]). 60 SYSTÉMOVÁ INTEGRACE 3/2005

10 Vývojové nástroje a nástroje pro týmovou spolupráci formou ASP Nabízené služby se opět liší, ale ty nejzákladnější zahrnují hosting aplikací s možnostmi škálovatelnosti, monitorováním výkonu. Někteří k tomuto hostingu přidávají více či méně sofistikovanou podporu vlastního deploymentu aplikace. Podle [IDC, 2005b] 7 můžeme mezi nejvýznamnější firmy v tomto segmentu řadit: IBM ([IBM, 2005]) USInternetworking ( NaviSite ( OpSource ( Jamcracker ( Oracle ( NetLedger ( 4.4 Web-centric vývojové nástroje Některé firmy začínají na trhu nabízet vývojové nástroje formou ASP. Někdy jde o různé jednoduché nadstavby nad jejich deployment infrastrukturou, které umožňují jednodušší testování a nasazení aplikace. Často jsou tato řešení zaměřena na neprogramátory pak se většinou jedná o nástroje na sestavování firemních webů z jednotlivých nabízených komponent (internetový obchod, atd.). Mezi tyto firmy patří: Akamai ( se svým EdgeComputing firma provozuje infrastrukturu a poskytuje některé nástroje pro jednoduchý deployment. Vytvořila například plug-in pro IBM WebSphere Studio [Akamai, 2003] Interland/Trellix ( nabízí tvorbu webu, psaní stránek, výběr designu, plnění daty, možnost sestavování z různých modulů (add-ons, např. podporu platebních karet, marketing, statistiky, atd.). NetLedger ( kromě řešení zmíněných v předchozí kapitole nabízí také podporu tvorby webu Site Builder.... a mnoho dalších menších poskytovatelů nástrojů pro tvorbu webů například HandzON ( - zaměřených především na malé firmy. I když se jedná vlastně o nástroje formou ASP, za výše uvedené služby není většinou účtováno, ale firmy svůj obchodní model zakládají na placeném hostingu vytvořených aplikací. 7 Řešení těchto firem jsou zařazena v této kapitole, protože poskytování infrastruktury pro deployment převládá v jejich portfoliu. Některé z firem také lehce zasahují do development infrastruktury popisované v předchozí části, případně provozují software, který připomíná vývojové nástrojů formou ASP (viz další podkapitola). SYSTÉMOVÁ INTEGRACE 3/

11 Petr Hamerník 4.5 Klasická IDE Nejvýznamnější výrobci vývojových prostředí IDE zvolili opačnou cestu než tvorbu a rozšiřování web-centric nástrojů. Jejich snahou je naopak všechny potřebné existující web-centric nástroje zaintegrovat do IDE. Všechny tyto firmy jdou cestou re-distribuce celé potřebné infrastruktury pro testování výsledné aplikace spolu s IDE. A tak na koncových stanicích vývojářů pak často běží webový, aplikační i databázový server. Proč se výrobci IDE vydali směrem rozsáhlých klientských aplikací a ne cestou web-centric architektury je způsobené kombinací mnoha důvodů. V první řadě jde o důsledek dlouholetého kontinuálního vývoje prostředí IDE jako rozsáhlých desktopových jednouživatelských aplikací. Přepsání do web-centric architektury by pro výrobce jistě znamenalo obrovské investice. Z tohoto hlediska je zřejmě výhodnější postupně integrovat podporu pro stávající web-centric nástroje do klientské aplikace. Díky komplexním uživatelským rozhraním a potřebě rychlé odezvy je rovněž složité upravit stávající IDE do podoby web-enabled aplikací. Dalším důvodem jsou současné limitace v kvalitě a možnostech uživatelských rozhraní poskytovaných ve webovém prohlížeči. Microsoft má mezi výrobci prostředí IDE asi nejucelenější nabídku pokrývající potřeby vývojářů. Ke svému rozsáhlému vývojovému prostředí.net Studiu nabízí servery pro podporu týmové práce (Team System). Také Borland nabízí podporu týmové spolupráce zahrnutou do svých nástrojů. Kromě toho se firma snaží prostřednictvím svého postavení na trhu nástrojů uplatnit i v oblasti hostingu výsledných aplikací. Ani další vývojové nástroje jako Eclipse nebo NetBeans nejsou výjimkou, pokud jde o integraci podpory týmové práce a propojení se stávajícími webovými nástroji. Z pohledu ASP nástrojů jdou tvůrci klasických prostředí IDE opačným směrem ne k web-centric aplikacím provozovaných formou pronájmu, ale směrem k obchodním modelům založeným na prodeji licencí. 5. Možné řešení 5.1 Návrh řešení Celková koncepce vývojového nástroje ASP vyplývá z předchozího textu. Vývojový nástroj ASP by byla webová aplikace poskytující podobné služby jako dnešní klasická vývojová prostředí IDE. Vývojový nástroj by pracoval nad úložištěm všech dat produkovaných celým týmem při vývoji (soubory, diskuse, dokumentace, atd.). Nástroj by zajišťoval většinu činností, které se dnes vykonávají na klientských stanicích (kompilace, sestavování serveru, deployment na testovací infrastrukturu, debugging, atd.), ale stejně tak činnosti, které dnes probíhají na vyhrazených serverech pro podporu týmové práce (source control management, správa chyb, automatické kompilace, automatické testy, generování reportů o procesu vývoje, a další činnosti). Celý vývojový nástroj může běžet na škálovatelné infrastruktuře, takže bude vždy reflektovat velikost týmu a jeho aktuální potřeby. Nejslabším místem pro použitelnost web-centric nástroje je zřejmě přenosová kapacita sítě mezi vývojáři a nástrojem (pravděpodobně tomu tak bude i v nejbližších letech). Proto je nutné během implementace takového nástroje 62 SYSTÉMOVÁ INTEGRACE 3/2005

12 Vývojové nástroje a nástroje pro týmovou spolupráci formou ASP vhodně rozdělit činnosti, zda mají blíže ke klientu nebo serveru. Část potřebuje okamžitou reakci na činnost uživatele (například syntax coloring) a ty by se měly vykonávat v klientské části aplikace. Druhá část naopak potřebuje přístup k velkému množství dat uložených na serveru a uživateli poskytuje pouze relativně malý výstup (např. refactoring). Ale i tato hranice se může časem posouvat, proto by nástroj měl být v této otázce flexibilní (při dostatečně rychlé síti může být časem i syntax coloring záležitostí serveru). Celý nástroj by měl být samozřejmě modulární s možností zapínání a vypínání některých částí a monitoringem jejich využití a to z důvodu jejich možného pronájmu formou ASP. Stejně tak by mělo být umožněno jednoduše volit mezi testovacím a deployment prostředím od jednotlivých výrobců infrastrukturního softwaru (např. aplikační servery). Kvůli integraci různých rolí ve vývoji bude nutností vytvářet a udržovat k zdrojovým datům také vhodná metadata. Vývojový nástroj by měl být zřejmě založený na MDA (Model Driven Architecture). 5.2 Možný obchodní model V celkovém konceptu vývojového nástroje formou ASP je více služeb, které mohou zajišťovat provozovateli vytváření zisku. Jejich vhodnou kombinací firma může sestavit nejlepší obchodní model, jak vývojový nástroj poskytovat. Mezi tyto služby patří: Pronájem vlastního vývojového nástroje rozděleného modulárně podle jednotlivých podporovaných technologií Správa všech dat při vývoji (zdrojové texty, dokumenty, y, příspěvky v diskusních skupinách, webové stránky, atd.) Knihovny a komponenty využitelné v cílové aplikaci (webový obchod, monitoring aplikace, adresáře, číselníky a další dílčí služby) Sdílení knowledge base mezi jednotlivými uživateli vývojového nástroje Vlastní provoz výsledné aplikace Případný export vygenerované aplikace pro nasazení na vlastní infrastruktuře zákazníka Podpora a služby při vývoji Nasazení a provoz celého nástroje uvnitř zákaznických firem Pro rozvoj a úspěch takového nástroje je nutné získat nadkritickou velikost komunity. Část služeb by bylo zřejmě výhodné poskytovat zdarma kvůli rozvoji této komunity. Z ní by se pak rekrutovali placení zákazníci. Velice žádoucí by v této souvislosti bylo některé vhodné části vytvářet modelem OSS kupříkladu sdílené moduly, z nichž by se výsledné aplikace sestavovaly, by se díky OSS vývoji snáze rozšířily a získaly vyšší kvalitu. I když to není striktní podmínkou, OSS by v celém nástroji měl hrát podstatnou roli. Celkový koncept ASP je založen na prodeji služeb a nikoliv licencí, což odpovídá principům OSS. Vhodným principem pro obchodní model ASP nástroje by bylo zpoplatnění služeb pro ty, kdo nepřispívají zpět do celého systému. Uživatel, který bude vyvíjet své aplikace modelem Open Source a bude tak zlepšovat kvalitu a množství znovu SYSTÉMOVÁ INTEGRACE 3/

13 Petr Hamerník použitelných komponent, bude moci nástroj využívat zdarma. Naproti tomu proprietární vývoj by byl zpoplatněn. Nejvýznamnější část zisků by byla generována vlastním provozem výsledných aplikací a prodejem služeb nad daným vývojovým nástrojem. Částečně rozporuplná může být otázka zpoplatnění výsledného exportu celé aplikace. Když zákazník odejde s výslednou aplikací, provozovatel bude přicházet o zisky z poskytování infrastruktury pro její provoz. Zpoplatnění takového exportu může ale do značné míry odrazovat od jakéhokoliv použití ASP nástroje. Zákazníky by měl spíše udržet fakt, že odchodem ztratí výhody integrace vývojového nástroje a vlastního nasazení aplikace a tím možnost rychlých vývojových cyklů při budoucích změnách v aplikaci. Zajímavý by mohl být i model propojování zákazníků a vývojářů kolem tohoto vývojového nástroje. Podobné služby za provizi poskytuje například firma Elance ( Důležitou součástí systému by pak bylo vzájemné hodnocení hodnocení vývojářů a zadavatelů zakázek. To by dále zvyšovalo celkovou hodnotu ASP nástroje. Zvolení vhodné kombinace placených a neplacených služeb je nejdůležitější rozhodnutí pro případného provozovatele vývojového nástroje formou ASP. 5.3 Přínosy nástrojů modelem ASP Přínosy nástrojů provozovaných formou ASP by se daly rozdělit do dvou kategorií. První jsou obecné výhody jakéhokoliv provozu aplikací formou ASP a některé již byly zmíněny ve čtvrté kapitole: nízké fixní náklady, předvídatelnost celkových nákladů, rychlost nasazení, pokles TCO, soustředění se na vlastní business firmy a lepší využití výpočetních zdrojů. Do druhé kategorie můžeme zahrnout výhody specifické pro vývojové nástroje. I ty je možné vyčíst z předchozího textu: Kvalitnější podpora týmové práce včetně lepší podpory spolupráce různých rolí ve vývoji (UI, vývojáři, zákazníci, atd.) Lepší integrace s existujícími webovými nástroji pro vývoj a týmovou spolupráci Efektivnější podpora komplexních úloh vyžadujících přístup k velkému množství dat (refactoring) Možnost práce z jakéhokoliv webového prohlížeče z různých platforem (notebook, PDA, mobil) Kvalitnější podpora vývoje moderních vícevrstvých aplikací (testování, debugging probíhá přímo v místě vývoje aplikace) Lepší možnosti integrace s dalšími nástroji (web services) 5.4 Nevýhody a rizika nástrojů modelem ASP Podívejme se na nevýhody a rizika, které nástroje formou ASP přinášejí oproti klasickým vývojovým nástrojům IDE. Mezi nejčastěji zmiňované nevýhody také patří rychlost odezvy. Tohoto tématu jsem se částečně dotkl již v kapitole 6.1. Rozdělení úloh mezi ty vykonávané na serveru a na klientu je zásadní otázka. Pro některé činnosti je ale těžké 64 SYSTÉMOVÁ INTEGRACE 3/2005

14 Vývojové nástroje a nástroje pro týmovou spolupráci formou ASP rozhodnout, do které skupiny patří. Například tzv. Code Completion nápověda možných metod daného objektu potom, co vývojář napíše jeho jméno se musí zčásti odehrávat v klientské části nástroje (parsování textu), ale zčásti na serveru (vyhledání platných možností pro daný kontext). Naštěstí nástroje by nebyly jediným softwarem, kde se tento problém objevuje. Tuto oblast například řeší technologie AJAX. 8 Dalším problémem je obava o data, která díky ASP nemá firma přímo pod kontrolou. Podíváme-li se podrobněji, vidíme dvě části tohoto problému. Za prvé obava o zabezpečení dat. Ta se s postupujícím časem snižuje, protože mnoho lidí si uvědomuje, že zabezpečení zálohování a jištění infrastruktury vlastními silami ve firmách není často na takové úrovni, jakou zajišťují specializované firmy. Druhá část je obava ze zneužití dat. Ta je ze zřejmých historických důvodů více rozšířena v zemích východní Evropy než v západní Evropě a USA. Je ale jasné, že i zde dochází k velkému posunu ve vnímání tohoto rizika. Jednotlivci dnes poměrně bez obav svěřují svá data fre ovým službám, používají soukromě web servery, využívají diáře, adresáře a další služby. Firmy jsou tvořeny jednotlivci a pokud ti ztrácí obavy ze zneužití svých dat, je pravděpodobné, že i firmy časem odbourají tuto (do jisté míry emotivně založenou) obavu. Vývojové nástroje patří v softwarových firmách k nejkritičtějšímu softwaru. To je také jedna z případných překážek rozvoje ASP nástrojů. Na druhou stranu, pokud firmy provozují CRM nebo ERP systémy touto formou, neměl by být do budoucna problém ani s vývojovými nástroji. Problémem může také být poměrně strohé uživatelské rozhraní webových aplikací. Tato nevýhoda se dá ale řešit například otevíráním speciálních oken (naprogramovaných v Javě) pro některé úlohy, využitím Appletů a dalšími možnostmi. Dá se také očekávat velký rozvoj v této oblasti, protože rostoucí počet webových aplikací vytváří poptávku po lepším rozhraní. Otázkou je, zda se podaří udržet v takovém vývoji vhodné standardy nebo zda nedojde k roztříštění na různé směry. Určité riziko pro přijetí takového nástroje je konzervativní přístup mnoha programátorů, pokud jde o používané nástroje. Mnozí rádi používají sofistikovaný textový editor (např. Emacs) a příkazovou řádku pro většinu akcí (kompilace, spouštění, deployment), na komplikovanější úlohy si píší vlastní skripty. Tito vývojáři často nevyužívají ani vývojových prostředí IDE. 6. Závěr Pokusil jsem se v tomto textu naznačit možnosti přechodu vývojových nástrojů na web-centric aplikace, což by později dovolilo jejich provoz formou ASP. Zhodnotil jsem přínosy a nevýhody takového řešení. Zdá se, že většina vyjmenovaných rizik a nevýhod má pouze dočasný charakter a výhody v budoucnosti převáží. Mnoho firem postupně také nabízí řešení, které se k tomuto cíli z různých stran přibližují. Poskytovatelé deployment infrastruktury se snaží zlepšovat nástroje pro nasazení klientských aplikací, z druhé strany poskytovatelé infrastruktury pro vývoj softwaru nabízejí čím dál tím lepší služby pro týmovou spolupráci a vývoj softwaru. 8 Ukázka dynamického doplňování textu během psaní je vidět na službě Google Suggest: SYSTÉMOVÁ INTEGRACE 3/

15 Petr Hamerník Ze třetího směru se současní výrobci vývojových prostředí IDE pokoušejí o co nejlepší integraci s uvedenými webovými službami. Současné trendy v ICT naznačují, že se software postupně přesouvá na servery, dá se proto očekávat, že i vývojové nástroje půjdou v tomto směru. Reference [Akamai, 2003] Akamai: Developing EdgeComputing Applications, 2003, [ASPNews, 2005a]: Chandrasekhar K.B.: Why SaaS Is Making a Comeback, Dostupné on-line: [ASPNews, 2005b]: ASPNews: April ASPnews Top 50, Dostupné on-line: [Bodoff at al, 2005] Bodoff D., Hung P., Ben-Menachem M.: Web Metadata Standards: Observations and Prescriptions, IEEE Software Publishing, IEEE Computer Society, 2005 [Bonaccorsi, 2002] Bonaccorsi A., Rossi C.: Why open source software can succeed, 2002, [Brooks, 1995] Brooks J.P.: The Mythical Man-Month, 1995, Anniversary Edition, Addison Wesley Longman, ISBN [Challet, Du, 2004] Challet D., Du Y.L.: Microscopic Model of Software Bug Dynamics: Closed Source Versus Open Source, 2004 [Cook at al, 2004] Cook C., Churcher N., Irwin W.: Towards Synchronous Collaborative Software Engineering, The 11th Asia-Pacific Software Engineering Conference (APSEC 04) [Daylami at al, 2005] Daylami N., Ryan T., Olfman L., Shayo C.: Determinants of Application Service Provider (ASP) Adoption as an Innovation, The 38th Hawaii International Conference on System Sciences 2005 [Fogel, 1999] Fogel K.: Open Source Development with CVS, Coriolis Open Press, 1999, ISBN [Füller at al, 2004] Füller J., Bartl M., Ernst H., Mühlbacher H.: Community Based Innovation - A Method to Utilize the Innovative Potential of Online Communities, The 37th Hawaii International Conference on System Sciences 2004 [IBM, 2005] IBM: On Demand Business, 1.ibm.com/services/us/igs/html/corio-landing.html?cntxt=a , 1.ibm.com/services/us/index.wss/offerfamily/aod/a [IDC, 2005a] IDC: 2005 Software as a Service Taxonomy and Research Guide, Industry Development and Models (Doc #33453 / Jun 2005), Dostupné on-line: [IDC, 2005b] IDC: U. S. Web Hosting Services 2004 Service Provider Shares, Competitive Analysis, 2005, [Interland, 2005] Interland: Site Builder, 2005, [Katz, Shapiro, 1985] Katz M. L., Shapiro C.: Network externalities, competition, and compatibility, American Economic Review 75, 1985, str [Lerner, Tirole, 2002] Lerner J., Tirole J.: Some Simple Economics of Open Source, The Journal of Industrial Economics, vol. 50, n. 2, 2002, str SYSTÉMOVÁ INTEGRACE 3/2005

16 Vývojové nástroje a nástroje pro týmovou spolupráci formou ASP [Raymond, 2000] Raymond, Eric S.: The Cathedral & the Bazaar, O'Reilly, 2000, [Voříšek a kol., 2003] Voříšek J., Pavelka J., Vít M.: Aplikační služby IS/ICT formou ASP - Proč a jak pronajímat informatické služby, Graga Publishing, Praha, 2003, ISBN [Voříšek, 2005] Voříšek J.: Trendy IS/ICT, na které musí uživatelé a dodavatelé reagovat, System Integration 2005, VŠE Praha, ISBN , str [Voříšek, Feuerlicht, 2004] Voříšek J., Feuerlicht G.: Pre-requisites for successful adoption of the ASP model by user organization [Yap at al, 2005] Yap N., Chiong H. C., Grundy J., Berrigan R.: Supporting dynamic software tool integration via web service-based components, Australian Software Engineering Conference (ASWEC 05), 2005 Summary: The text analyzes the development and collaborative tools from ASP point of view (Application Services Provider). It evaluates this possibility using the most important ASP criteria. The main roles are identified and described (tool vendor, ASP provider, developers and customers). A market analysis is also provided, and the overall concept is described along with an identification of advantages and risks. SYSTÉMOVÁ INTEGRACE 3/