Gyors alkalmazásfejlesztés kezdőknek

Mi az a gyors alkalmazásfejlesztés (rapid application development; RAD)?

Az 1970-es években kigondolt, de hivatalosan James Martin által 1991-ben bevezetett gyors alkalmazásfejlesztés (rapid application development; RAD) egy olyan módszertan, amely az alkalmazások gyors fejlesztésére összpontosít a gyakori iterációk és jóváhagyások révén, folyamatos ügyfél-visszajelzés mellett. Az agilis és gyors prototípus-kiadások előnyben részesítésével a RAD az egyéni alkalmazások és egyéb elemek fejlesztése során a szoftverek használhatóságát, a felhasználói visszajelzéseket és a gyors leadást helyezi előtérbe. A gyorsabb és ügyesebb szoftverfejlesztést lehetővé tevő RAD egyre népszerűbbé válik.

A RAD módszertan főbb előnyei:

• Csökkentett fejlesztési idő és gyorsabb leadás.
• Fokozott rugalmasság és alkalmazkodóképesség.
• Jobb kockázatkezelés.
• Kevesebb manuális kódolás és rövidebb tesztelési idő.
• Folyamatos, releváns és valós idejű felhasználói visszajelzések.

Agilis, vízesés, és RAD fejlesztési módszerek

A szoftverfejlesztésnek két fő módszertana van: az agilis és a vízesés. A vízesés a hagyományos szoftverfejlesztési módszer, amely egy, az ügyfél végső jóváhagyásától nagy mértékben függő szigorú lineáris folyamatra összpontosít. Az ilyen fejlesztések hónapokig tarthatnak anélkül, hogy az ügyfelek látnák a végterméket, ami sok problémát okoz a frissített követelmények vagy a projektet érintő további visszajelzések esetén. Nehéz lehet megváltoztatni a szoftver alapvető funkcióit és szolgáltatásait.

Az agilis az egyik legelterjedtebb módszer, amelyet a hagyományosan strukturált menedzsmenttechnikák korlátaira válaszul hoztak létre. A RAD az agilis módszertanok egyik típusa, amely valós idejű eredményeket kínál, és jól működik, amikor egy termék gyors leszállítása, illetve funkciók szükség szerint történő frissítése a cél. Bár a hangsúly a sebességen van, ez mégsem egy adott időkereten alapul. Ami a RAD-folyamatot egyedülállóvá teszi, az a folyamatvezéreltség, valamint a prototípusok tesztelésére és a gyors változtatásokra való összpontosítás, hogy rövidebb idő alatt leadható legyen egy jól körülhatárolt termék.

Bár a RAD és az agilis hasonló lépésekkel rendelkezik, a RAD a prototípusokra összpontosít, míg az agilis a projekteket funkciókra bontja, melyek leszállítása a fejlesztési ciklus alatt különböző sprintekben történik meg.

A gyors alkalmazásfejlesztés lépései

A RAD esetén négy meghatározott lépésre van szükség a projekt befejezéséhez. A RAD célja a tervezési idő csökkentése, valamint a termék felépítésére és fejlesztésére való összpontosítás. Tehát még ha meg is kell ismételni néhány lépést, ez olyan terméket eredményez, amire mind a csapata, mind a résztvevők büszkék lehetnek.

1. Projektkövetelmények meghatározása. Ilyenkor minden érintett – Ön, a fejlesztők, a szoftverfelhasználók és az érdekelt felek – közösen meghatározza, kutatómunkával alátámasztja és véglegesíti a projekt hatókörét és követelményeit, például a célokat, az elvárásokat, az ütemterveket és a költségvetést. Egy kick-off értekezlet vagy egy kreatív ismertető keretében a résztvevők felvázolják a víziójukat, az informatikai döntéshozók és a fejlesztők pedig segítenek véglegesíteni az összes ilyen követelményt. A RAD-módszer egyik előnye, hogy a követelmények meghatározása után is könnyedén változtatni lehet a megközelítésen a fejlesztési ciklus bármely pontján.
2. Prototípusok készítése. Ezután a csapat elkezdi felépíteni a modelleket és a prototípusokat. A cél az, hogy gyorsan előállítsunk egy olyan működő modellt, amelyet bemutathatunk a résztvevőknek. A fejlesztők és a tervezők együtt dolgoznak annak érdekében, hogy megfeleljenek a résztvevők céljainak és követelményeinek. A prototípusgyártás korai szakaszaiban a fejlesztőknek lehetőségük van olyan megkerülő megoldások létrehozására, amelyek működő termékhez vezetnek, a minőség feláldozása nélkül. Mivel a csapat egy működő terméket épít, itt kulcsfontosságú szerepet játszik a felhasználói élmény, a tesztelés és a visszajelzés.
   
   A folyamatos visszajelzések segítenek abban, hogy a csapat egy élő rendszeren belül dolgozzon, nem pedig egy absztrakt dizájnon belül. Az átmeneti problémákon és a hibákon való folyamatos munkának köszönhetően korrigálni lehet a folyamatot, hogy mindenképp teljesüljenek a követelmények, és működő modell jöjjön létre. Ez azt is jelenti, hogy a hibákat még a folyamat korábbi részeiben megtalálják és elhárítják, ami segít abban, hogy tartható maradjon a résztvevők ütemterve, valamint elősegíti, hogy a projekt jobban strukturált legyen a jövőbeli tervezési bővítések befogadásához.
3. Felépítés, tesztelés és visszajelzések beépítése. A működő prototípus birtokában itt az ideje, hogy működőképes modellé alakítsuk azt. A fejlesztők visszajelzést gyűjtenek a felhasználóktól, és felépítik a terméket. Mindenképp implementálja az alkalmazásfejlesztő szoftvert a folyamatba, hogy az ötlete megelevenedhessen. Az alkalmazáskódolással, a rendszerteszteléssel és az egységintegrációval a prototípus- és bétarendszerek működő modellé alakulnak. Mivel a csapatok kevés kódolást igénylő, gyors alkalmazásfejlesztési eszközöket használnak, gyorsan kezelhetők a változások.
   
   A szoftvereket és alkalmazásokat alaposan tesztelik, és a résztvevők a problémák felfedezése után változtatásokat vagy új ötleteket javasolhatnak. Elvileg nem kell sok hibára számítani, ugyanis a RAD előnye, hogy a legtöbb hibát valós időben láthatja a prototípusfázis során, melyekre azonnal reagálni lehet. Ha a résztvevők elégedettek, akkor befejezhető a termék.
4. Véglegesítés és implementálás. A végső szakaszban elkészül a végtermék optimalizált változata, amely stabil, és könnyen karbantartható a hosszú élettartam érdekében. A jellemzőket, a funkciókat és az esztétikai kérdéseket a résztvevőkkel véglegesítjük. Az éles üzemi környezetbe való áthelyezés után a felhasználók teljes körű tesztelést vagy képzést végezhetnek. A termék ekkor készen áll arra, hogy bemutassák a résztvevőknek!

Érdemes-e RAD eszközöket használni a következő projektjéhez?

Úgy tűnhet, hogy a RAD minden projekthez passzol, azonban nem megoldás mindenre. Annak érdekében, hogy hatékony RAD módszertant valósítson meg a következő projektjéhez, meg kell győződnie arról, hogy bizonyos szempontok teljesülnek-e az indulás előtt. Bár a RAD egy agilis módszer, amely javíthatja a szoftverfejlesztési folyamatot, bizonyos üzleti követelményeknek meg kell felelni annak érdekében, hogy a működő terméket a lehető leggyorsabban leszállítsa.

A következő kérdések segítségével eldöntheti, hogy a RAD beválhat-e a következő projektjéhez:

• Hajlandóak lesznek-e az érdekelt felek követni a RAD megközelítését? Könnyen elérhetők, és készek részletes visszajelzést adni?
• Ki lehet-e fejleszteni a terméket két-három hónapon belül?
• A fejlesztőkből, programozókból és tervezőkből álló csapata elég tapasztalt ahhoz, hogy időben leszállítsa a terméket?
• Alacsony a technikai kockázat szintje?
• Rendelkezik a RAD megvalósításához szükséges eszközökkel, szoftverekkel és technológiával?

Ha mind az öt kérdésre „igen” a válasz, akkor a RAD módszertan segítségével sikeresen létrehozhat egy új terméket.