A gyors alkalmazásfejlesztés (RAD, Rapid application development) egy általános szoftverfejlesztési elv. James Martin dolgozta ki az 1980-as években. A módszertan elemei: ciklikus fejlesztés, működő prototípusok létrehozása, és a szoftverfejlesztést támogató számítógépes programok, például integrált fejlesztői környezetek használata. Előnyeként az alkalmazások elkészítésének egyszerűbbé válását és lerövidült munkaidejét nevezik meg, amelyhez hozzátartozik a kezelőfelület felhasználóbarát, uniformizált megjelenése (lásd Microsoft Windows). Bírálói viszont a feladathoz való igazodás, a felhasználói kívánalmak pontos figyelembe vétele, a futtatható program mérete és sebessége terén mutatott hiányosságokra mutatnak rá.

A gyors alkalmazásfejlesztés válaszként szolgált az 1970-es és 1980-as években kidolgozott tervvezérelt vízesési folyamatokra, mint ahogy a strukturált rendszerek elemzési és tervezési módszerére (SSADM). Ezeknek a módszereknek az egyik problémája az, hogy tradicionális mérnöki modelleken alapultak, amelyeket például hidak és épületek tervezésére és építésére használtak. Viszont a szoftver természetéből adódóan egy eltérő mű. A szoftver radikálisan megváltoztathatja a probléma megoldásához használt teljes folyamatot. Ennek eredményeként a fejlesztési folyamat során szerzett tudás visszatérhet a követelményekhez és a megoldás kialakításához. A tervközpontú megközelítések megkísérlik mereven meghatározni a követelményeket, a megoldást és a megvalósítási tervet, és rendelkeznek olyan folyamattal, amely elriasztja a változásokat. A RAD megközelítések viszont felismerik, hogy a szoftverfejlesztés tudás intenzív folyamat, és rugalmas folyamatokat biztosít, amelyek elősegítik a projekt során szerzett ismeretek kihasználását a megoldás fejlesztése vagy adaptálása érdekében.

Az első ilyen RAD alternatívát Barry Boehm fejlesztette ki, és spirális modellként ismerték. A Boehm és más későbbi RAD megközelítések hangsúlyozták a prototípusok kidolgozását, a szigorú tervezési előírások helyett.

A prototípusoknak számos előnye volt a hagyományos előírásokkal szemben:

• Kockázatcsökkentés. A prototípus a rendszer legnehezebb potenciális részeit tesztelheti az életciklus elején. Ez értékes információt nyújthat a terv megvalósíthatóságáról, és megakadályozhatja a csapatot olyan megoldások megvalósításban, amelyek végrehajtása túl összetettnek vagy időigényesnek bizonyul. Ez azért hasznos mert a problémákat az életciklusban korábban találja meg, nem pedig később, ez a RAD megközelítés egyik fő előnye volt. Minél korábban lehet egy problémát megtalálni, annál olcsóbban kezelhető.
• A felhasználók jobban használják, mint a specifikációk kidolgozása esetén. A vízesés modellben a felhasználó gyakran hagytak ki követelményeket, de amikor egy implementált rendszerrel mutatták be, hirtelen rájöttek, hogy egy adott tervnek hiányzik néhány kritikus tulajdonsága vagy túl összetett. Általában a legtöbb felhasználó sokkal hasznosabb visszajelzést ad, mikor megtapasztalja a futó rendszer prototípusát, ahelyett, hogy elvontan meghatározná, hogy a rendszernek milyennek kellene lennie.
• A prototípusok felhasználhatóak és késztermékké fejlődhetnek. Az egyik megközelítés, amelyet néhány RAD módszernél alkalmaztak, a rendszer prototípusok sorozatának felépítése volt, amelyek minimális funkcionalitástól mérsékelten hasznossá váltak a végleges komplett rendszerig. Ennek előnye a két előző mellett, hogy a felhasználók sokkal korábban megszerezhetik hasznos üzleti funkcióikat a folyamat során.

Barry Boehm és mások gondolataival kezdve, James Martin az 1980-as években az IBM-nél kifejlesztette a gyors alkalmazásfejlesztési megközelítést, és végül formalizálta egy, a Rapid Application Development című 1991-es könyv kiadásával. Ez az IT szakemberek körében némi zavart okozott a RAD kifejezés alatt. Fontos különbséget tenni a RAD mint a vízesés modell általános alternatívája és a RAD, mint Martin által létrehozott speciális módszer között. A Martin módszerét tudás intenzív és felhasználói felület-intenzív üzleti rendszerekhez igazították.

Ezeket az ötleteket tovább fejlesztették és továbbjavították a RAD úttörői, például James Kerr és Richard Hunter, akik együtt írták a témával foglalkozó alapvető könyvet az Inside RAD-ot, amely egy RAD projektmenedzser útját követi, amikor vezette és finomította a RAD módszertant valós időben egy tényleges RAD projektnél. Ezek a szakemberek és azok, akik hasonlóak voltak, segítették a RAD népszerűségének elnyerését mint egy hagyományos rendszer projekt életciklus-megközelítés alternatívájaként.

A RAD megközelítés kiforrni látszott az üzleti átalakítás iránti érdeklődés csúcsának idején is. Az üzleti folyamatok újratervezésének célja az alapvető üzleti folyamatok, például az értékesítés és az ügyfélszolgálat radikális átgondolása az információs technológia új képességeinek szem előtt tartva. A RAD gyakran nélkülözhetetlen része volt a nagyobb üzleti tervezési programoknak. A RAD gyors prototípus-megközelítése kulcsfontosságú eszköz volt, amely segítette a felhasználókat és az elemzőket, hogy „gondolkodjanak a dobozból” az innovatív módszerekről, amelyekkel a technológia radikálisan feltalálhatja az alapvető üzleti folyamatokat.

James Martin-féle RAD megközelítés négy különálló szakaszra osztja:

1. Követelmények tervezési fázisa - a rendszer-fejlesztési életciklus (Systems Development Life Cycle - SDLC) rendszer tervezési és elemzési fázisának elemeit egyesíti. A felhasználók, a vezetők és az informatikai alkalmazottak megvitatják és megegyeznek az üzleti igényekről, a projekt terjedelméről, a korlátozásokról és a rendszer követelményekről. Akkor ér véget, amikor a csapat megállapodik a kulcskérdésekben, és megkapja a menedzsment engedélyét a folytatáshoz.
2. Felhasználói tervezési szakasz - ebben a fázisban a felhasználók kölcsönhatásba lépnek a rendszerelemzőkkel és modelleket és prototípusokat dolgoznak ki, amelyek az összes rendszer-folyamatot, bemenetet és kimenetet képviselik. A RAD csoportok vagy alcsoportok általában a Joint Application Development (JAD) technikák és a CASE eszközök kombinációját használják a felhasználói igények működő modellekké történő átalakításához. A felhasználói tervezés folyamatos interaktív folyamat, amely lehetővé teszi a felhasználók számára, hogy megértsék, módosítsák és végül jóváhagyják a rendszer működési modelljét, amely megfelel az igényeiknek.
3. Építési szakasz - az SDLC-hez hasonló program- és alkalmazásfejlesztési feladatra összpontosít. A RAD-ban azonban a felhasználók továbbra is részt vesznek, és továbbra is javasolhatnak változtatásokat vagy fejlesztéseket a tényleges képernyők vagy jelentések kidolgozásakor. Feladatai a programozás és az alkalmazásfejlesztés, a kódolás, az egységintegráció és a rendszer tesztelése.
4. Átváltási szakasz - hasonlít az SDLC végrehajtási szakaszának utolsó feladataira, beleértve az adatok konvertálását, tesztelését, az új rendszerre való átállást és a felhasználói képzést. A hagyományos módszerekkel összehasonlítva az egész folyamat tömörítve van. Ennek eredményeként az új rendszert sokkal hamarabb felépítik, szállítják és üzembe helyezik.

A modern információs technológiai környezetben sok rendszert építenek be bizonyos fokú gyors alkalmazásfejlesztéssel (nem feltétlenül a James Martin megközelítéssel). A Martin módszerén kívül az agilis módszereket és a Rational Unified Process rendszert gyakran használják a RAD fejlesztéséhez.

A RAD előnyei a következők:

• Jobb minőség. Azáltal, hogy a felhasználók interakcióba lépnek a fejlődő prototípusokkal, ezzel a RAD-projekt üzleti funkciói gyakran sokkal magasabbak lehetnek, mint a vízesés-modellel. A szoftver felhasználhatóbb lehet, és nagyobb esélye van arra, hogy az üzleti problémákra összpontosítson, amelyek kritikusak a végfelhasználók számára, ahelyett, hogy a fejlesztőket érintő problémákkal foglalkoznának. Habár ez kizárja az egyéb kategóriákat, amiket általában úgy ismerünk, mint a nem funkcionális követelmények, ideértve a biztonságot és a hordozhatóságot.
• Kockázat-ellenőrzés. Bár a RAD-ról szóló szakirodalom nagy része a sebességre és a felhasználók bevonására összpontosít, a RAD helyesen elkészített kritikus tulajdonsága a kockázatcsökkentés. Érdemes emlékezni arra, hogy Boehm kezdetben a spirális modellt kockázatalapú megközelítésként jellemezte. A RAD-megközelítés már a korai szakaszban a fő kockázati tényezőkre összpontosíthat, és a folyamat korai szakaszában összegyűjtött empirikus bizonyítékok alapján hozzáigazíthatja azokat. Például, a rendszer néhány legösszetettebb részének prototípus-készítésének bonyolultsága.
• További projektek időben és költségvetésen belül fejeződtek be. A növekményes egységek fejlesztésére összpontosítva csökken a katasztrófaesemények esélye, amelyek nagy vízesés-projektet vezettek be. A vízesés modellben általában hat hónapos vagy annál hosszabb elemzés és fejlesztés után valósult meg, amely az egész rendszer radikális átgondolását tette szükségessé. A RAD használatával ez a fajta információ felfedezhető és a folyamat korábbi szakaszai szerint reagálható.

A RAD hátrányai a következők:

• Az új megközelítés kockázata. A legtöbb IT-üzlet számára a RAD új megközelítés volt, amely a tapasztalt szakembereket arra kötelezte, hogy gondolják át a munkájuk végzésének a módját. Az emberek gyakorlatilag mindig idegenkednek a változásoktól, és az új eszközökkel vagy módszerekkel elvégzett projektek a legtöbbször első alkalommal el buknak, egyszerűen azért, mert a csapatnak új módszert kell megtanulnia.
• A hangsúly hiánya a nem funkcionális követelmények esetében, amely gyakran nem látható a végfelhasználók esetében a normális működésközben.
• A szűkös erőforrások időigénye. Az egyik dolog, ami szinte minden RAD megközelítésnél közös, az, hogy a felhasználók és a fejlesztők között a teljes életciklus során sokkal több kölcsönhatás zajlik. A vízesés modellben a felhasználók meghatározzák a követelményeket, majd többnyire eltűnnek, amíg a fejlesztők létrehozzák a rendszert. A RAD-ban a felhasználók a kezdetektől kezdve és gyakorlatilag a teljes projektben vesznek részt. Ez megköveteli, hogy az üzleti vállalkozás hajlandó befektetni az alkalmazástartomány-szakértők idejét. A paradoxon az, hogy minél jobban ismeri a szakértőt, minél jobban ismeri a domainjét, annál többre van szükségük az üzleti vállalkozás tényleges irányításához, és nehéz lehet meggyőzni a felügyelőket idejük befektetéséről. Ilyen kötelezettségvállalások nélkül a RAD projektek nem lesznek sikeresek.
• Kevesebb irányítás. A RAD egyik előnye, hogy rugalmas, alkalmazkodó folyamatot biztosít. Az ideális az, ha gyorsan képes alkalmazkodni mind a problémákhoz, mind a lehetőségekhez. Elkerülhetetlen a kompromisszum a rugalmasság és az ellenőrzés között, egyikük kevesebbet jelent a másiknak. Ha egy projekt (például életkritikus szoftver) az agilitást meghaladó értékeket irányít, akkor a RAD nem megfelelő.
• Rossz kialakítás. A prototípusokra való összpontosítás bizonyos esetekben túlságosan elfordulhat, és így egy "hack and test" módszert eredményezhet, ahol a fejlesztők folyamatosan kisebb változtatásokat hajtanak végre az egyes alkotóelemeken, és figyelmen kívül hagyják a rendszer felépítésével kapcsolatos kérdéseket, amelyek jobb általános tervezést eredményezhetnének. Ez különösen olyan metodikák számára jelent problémát, mint például Martin megközelítése, amelyek nagyon koncentrálnak a rendszer felhasználói felületére.
• A skálázhatóság hiánya. Az RAD általában a kis és közepes méretű projektcsoportokra összpontosít. A fentiekben említett egyéb kérdések (kevésbé tervezés és vezérlés) különleges kihívásokat jelentenek, ha nagyon nagy léptékű rendszereknél RAD megközelítést alkalmaznak.

Ez a szócikk részben vagy egészben a Rapid application development című angol Wikipédia-szócikk fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.

• James Martin: Rapid Application Development, Macmillan Coll Div, ISBN 0-023-76775-8

• NConstruct honlap (Windows & Web RAD tool)