Rapid Application Development

Rapid application development (RAD) je moderním přístupem k vývoji aplikací, který podobně jako agilní metodiky reaguje na rigidnost klasického vodopádového modelu. Zdůrazňuje potřebu přizpůsobení požadavků jako reakci na nové skutečnosti, které se přirozeně objevují až v průběhu projektu. Inkrementální přístup k vývoji brání katastrofickým selháním, kdy po několika měsících či dokonce letech analýz a příprav jsou odhaleny zásadní problémy, které nikomu dosud nepřišly na mysl. Při RAD se uživatelé setkávají s podobou cílového řešení od samého počátku,[1] protože používá prototypy. Zpětná vazba od uživatelů zkoušejících prototypy vede ke korekci požadavků a návrhu systému již v raných fázích vývoje.[2]

RAD přístup je používán na software, který rychlý vývoj aplikací umožňuje. Tento software je platformou, kterou pak organizace používá k vývoji funkcionalit, které nespadají pod jiné komponenty podnikové architektury jako např. ERP nebo by vývoj na nich byl náročný. RAD platformu je vhodné použít pro náhradu různých drobných nebo zastaralých aplikací. RAD platforma v takovém případě velmi efektivně řeší jednotné uživatelské prostředí, snižuje heterogenitu prostředí, adekvátní řízení přístupových oprávnění, centralizaci a opakované využití dat či audit trail. Minimalizujeme také řadu rizik jako je např. kompatibilita a podpora původních aplikací. Software, který lze použít jako RAD platformu, si firma často nejprve pořizuje pro řešení specifické oblasti – např. pro oblast CRM, pro řízení procesů a projektů, ITIL procesy a help desk.

Výhody RAD

  • Vyšší kvalita. Uživatelé používají prototypy, které v rámci projektu vznikají již od rané fáze. Důraz je kladen na uživatele a jeho potřeby, ne technické aspekty software. Funkcionalita software proto bude odpovídat business požadavkům spíše než v případě vodopádového přístupu.
  • Řízení rizik. Kromě rychlosti a zapojení uživatelů se RAD soustředí na eliminaci rizik. Zpětná vazba získaná z prototypů umožní včas identifikovat kritické oblasti, které vyžadují pozornost.
  • Projekty jsou dokončované včas a v rámci rozpočtu. Inkrementální vývoj snižuje pravděpodobnost zásadních problémů, které ve vodopádovém přístupu byly identifikovány až ke konci projektu a vedly k celkovému selhání projektu. Zatímco vodopádový přístup po měsících vývoje zjišťuje závažný problém a začíná opět s analýzou, RAD se o problému dozví již v počátcích vývoje díky prototypům.

Nevýhody RAD

  • Vyžaduje mnohem vyšší zapojení businessu. Ve vodopádovém přístupu business uživatelé zpracovávají požadavky a tím jejich zapojení na projektu do značné míry končí. Dalším krokem je vývoj, jehož se neúčastní. U RAD jsou zapojeni stále, s čímž musí počítat.
  • Nižší míra řízení. Flexibilita RAD vede do určité míry ke ztrátě kontroly typické pro rigidní přístupy. U projektů, kde kontrola je kritickou potřebou, RAD není vhodným přístupem.
  • Nedostatky v návrhu. Důraz na prototypy může vést k neustálým drobným změnám a podcenění architektury, kterou by řešení mělo disponovat
  • Nižší míra škálovatelnosti. RAD se většinou zaměřuje na menší a středně velké projekty. Výše uvedené problémy se projeví spíše u velkých projektů, které aplikují RAD.

Odkazy

Reference

  1. ↑ BOEHM, Barry. A Spiral Model of Software Development. IEEE Computer. May 1988. Dostupné v archivu pořízeném dne 2018-03-29. (anglicky)  Archivovaná kopie. www.dimap.ufrn.br [online]. [cit. 2018-01-09]. Dostupné v archivu pořízeném z originálu dne 2018-03-29. 
  2. ↑ BROOKS, Fred. No Silver Bullet Essence and Accidents of Software Engineering. Redakce Kugler H.J.. [s.l.]: Elsevier Science Publishers B.V (North-Holland), 1986. (Information Processing '86). Dostupné online. ISBN 0-444-70077-3. (anglicky) 

Související články

Externí odkazy