RAD (programozás)

RAD (az angol  rapid application development – ​​rapid application development szóból) – a szoftvertermékek  fejlesztésének technológiai folyamatának megszervezésének koncepciója , amely a lehető leggyorsabb eredmények elérésére irányul a súlyos idő- és költségvetési korlátokkal és homályosan meghatározott termékkövetelményekkel szemben. A fejlesztést gyorsító hatás megfelelő technikai eszközök igénybevételével és a fejlesztés előrehaladásával párhuzamosan, a követelmények pontosításával, az aktuális eredmények értékelésével, a megrendelő bevonásával valósul meg. A RAD-ot az 1980-as évek végén hozták létre a korábbi vízesés és iteratív modellek alternatívájaként . A 20. század vége óta a RAD széles körben elterjedt.

Ugyanezt a kifejezést használják a gyors prototípuskészítéshez és szoftverfejlesztéshez szükséges szoftvereszközökre. Az ilyen eszközök jellemző tulajdonságai a rutinműveletek maximális automatizálása és a vizuális programozás széles körű alkalmazása .

Történelem

A RAD koncepció megalkotása számos tényező kombinációjának eredménye volt.

• Elégedetlenség az 1970 -es évek és az 1980 -as évek eleji szoftverfejlesztési módszerekkel , mint például a Waterfall modellel .  A „vas” műszaki rendszerek tervezési módszereivel analóg módon kifejlesztve biztosítják a követelmények szakaszos kialakítását, a dokumentációt, a tervezést és a megvalósítást. Következetes alkalmazásuk a programkészítés olyan lassú folyamatához vezet, hogy gyakran még a programmal szemben támasztott alapvető követelményeknek is van ideje változtatni a fejlesztés befejezése előtt.
• Annak tudatosítása, hogy a szoftvertermékfejlesztés eltér a hagyományos mérnöki tevékenységtől, ami abban áll, hogy a fejlesztési alany sokkal nagyobb rendelkezésre áll a komplex, ismételt módosításokhoz.
• Hardverkapacitások és szoftverfejlesztő eszközök megjelenése, amelyek lehetővé teszik a szoftverrendszerek és alkatrészeik működőképes prototípusainak gyors létrehozását és a dokumentációk automatizálását. Ezekkel az eszközökkel a rendszer részletes tervezésének és gondos előzetes dokumentálásának alternatívája a prototípus gyors elkészítése vagy módosítása, valamint annak megrendelő általi közvetlen értékelése.
• Sikeres rendszerfejlesztési tapasztalat egy kis összetartó fejlesztői csapat munkája alapján, akik közvetlenül érintkeznek egymással és az ügyfél képviselőjével.

A RAD alapítója James Martin, az IBM alkalmazottja , aki az 1980 -as években Barry Boym és Scott Schultz ötletei alapján fogalmazta meg a RAD alapelveit. 1991 - ben pedig Martin kiadott egy híres könyvet, amelyben részletezte a RAD fogalmát és alkalmazási lehetőségeit. A RAD mára a szoftverfejlesztő eszközök létrehozásának elfogadott keretévé válik .

Időpont

A RAD azt feltételezi, hogy a szoftverfejlesztést egy kis fejlesztői csapat végzi körülbelül három-négy hónapon keresztül , vizuális modellezési és fejlesztői eszközöket használó növekményes prototípusok segítségével . A RAD technológia biztosítja az ügyfél aktív bevonását a korai szakaszban - a szervezet felmérése, a rendszer követelményeinek kialakítása. Ezen tulajdonságok közül az utolsó magában foglalja a megrendelő funkcionális és nem funkcionális követelményeinek maradéktalan teljesítését, figyelembe véve azok esetleges változásait a rendszer fejlesztése során, valamint a magas színvonalú dokumentáció megszerzését, amely biztosítja az egyszerű kezelést és karbantartást. a rendszer. Ez azt jelenti, hogy a szállítás utáni támogatás többletköltségei lényegesen alacsonyabbak lesznek. Így ezzel a módszerrel jelentősen lecsökken a fejlesztés kezdetétől az elfogadható termék megszerzéséig tartó teljes idő.

Alkalmazás

A RAD technológia nem univerzális, csak akkor célszerű használni, ha a projekt valamennyi vagy néhány feltételnek megfelel:

1. Rövid idő. Olyan rendszert kell a lehető leggyorsabban létrehozni, amely megfelel a mai kor követelményeinek. A kifejezések növekedése nagy valószínűséggel olyan jelentős változást hoz az automatizált tevékenységeket szabályozó alapvető rendelkezésekben, hogy a rendszer már a tervezés befejezése előtt erkölcsileg elavulttá válik.
2. Nem egyértelműen meghatározott és/vagy változó követelmények a fejlesztés során. Az ügyfélnek nagyon hozzávetőleges elképzelése van a jövőbeli szoftvertermék munkájáról, és nem tudja egyértelműen megfogalmazni a szoftverrel szemben támasztott összes követelményt. Előfordulhat, hogy a követelményeket nem határozzák meg a projekt elején, vagy a projekt előrehaladtával változhatnak.
3. Korlátozott költségvetés, az ügyfél hajlandóságával részt venni a fejlesztésben. A megrendelőnek nincs pénze hosszú ideig kifizetni a tervezőkből és fejlesztőkből álló nagy csapat munkáját, de hajlandó a szakembereket állandó közvetlen részvételre a fejlesztésben és jelenlegi állapotának felmérésében.
4. Kis mennyiségek vagy a projekt funkcionális komponensekre való felosztása. Ha a tervezett rendszer nagy, akkor azt kisebb darabokra kell bontani, amelyek mindegyike egyértelmű funkcionalitással és minimális függőséggel rendelkezik a többitől. Kiadhatók egymás után vagy párhuzamosan (utóbbi esetben több RAD csoport is érintett).
5. A grafikus felhasználói felület  a rendszer legfontosabb vagy egyik legfontosabb összetevője. A RAD technológia az interfész létrehozásában nyújtja a legnagyobb előnyöket, mivel az interfész közvetlenül a prototípuson, és meglehetősen hamar a projekt kezdete után kerül bemutatásra. A vizuális szerkesztőben akár közvetlenül is bevonható az ügyfél képviselője a felület kialakításába. Ezzel a megközelítéssel elkerülhető az a tipikus helyzet, amikor a felhasználó által a követelményekben leírt interfész (általában a technológiai korlátok figyelembevétele nélkül) a gyakorlatban teljesen másként viselkedik, mint amit a felhasználó elvárt, holott a rendszer formailag maradéktalanul megfelel a dokumentált követelményeknek.
6. Alacsony számítási komplexitás. Az adatfeldolgozás egy projektben tipikus műveletek kombinációjára vezethető vissza, amelyek mindegyike vagy többsége már elérhető elérhető könyvtárak formájában van megvalósítva. Az eredeti adatfeldolgozó algoritmusok vagy egyáltalán nem szükségesek, vagy meglehetősen egyszerűek, és gyorsan és különösebb nehézség nélkül megvalósíthatók.

Ha a rendszerrel szemben támasztott követelmények egyértelműen meghatározottak és nem változtathatók meg, akkor nem szükséges a megrendelő bevonása a fejlesztési folyamatba, és a hagyományos hierarchikus fejlesztés ( kaszkád módszer ) hatékonyabb lehet. Ezenkívül a RAD gyakorlatilag semmilyen előnyt nem nyújt azokban a projektekben, amelyek fő összetettségét az összetett, nem szabványos adatfeldolgozási algoritmusok megvalósításának szükségessége határozza meg, és a felhasználói felület vagy hiányzik, vagy nagyon egyszerű és teljesen szabványos.

Alapelvek

A RAD technológia alapelvei a három fő előny biztosítására irányulnak - nagy fejlesztési sebesség, alacsony költség és kiváló minőség. Kiváló minőségű szoftverterméket elérni nagyon nehéz, a felmerülő nehézségek egyik fő oka az, hogy a fejlesztő és a megrendelő eltérően látja a fejlesztés tárgyát (szoftvert).

• Az eszköztárnak a fejlesztési idő minimalizálására kell törekednie.
• Prototípus készítése a vásárlói igények tisztázására.
• Fejlesztési ciklus: a termék minden új verziója az előző verzió munkájának ügyfél általi értékelésén alapul.
• A verziófejlesztési idő minimalizálása kész modulok átvitelével és funkcionalitással az új verzióhoz.
• A fejlesztőcsapatnak szorosan együtt kell működnie, minden tagnak hajlandónak kell lennie többszörös felelősségvállalásra.
• A projektmenedzsmentnek minimálisra kell csökkentenie a fejlesztési ciklus időtartamát.

A RAD alapelvei nemcsak a megvalósításra vonatkoznak, hanem az életciklus minden szakaszára, különösen a szervezet felmérésére, a követelmények kialakítására, elemzésére és tervezésére.

Fejlesztési fázisok

1. A tervezés  a rendszertervezésből és az életciklus-fejlesztési eljárás (SDLC) elemzéséből származó követelmények összessége. Ebben a szakaszban a felhasználók, vezetők és informatikusok megbeszélik a projekt céljait, terjedelmét, rendszerkövetelményeit, valamint a fejlesztés során felmerülő nehézségeket. A szakasz azzal ér véget, hogy a RAD-csoport megállapodik a kulcsfontosságú pontokban, és engedélyt kap a projektvezetőktől a folytatáshoz.
2. Felhasználói tervezés  – Ebben a fázisban a felhasználók a rendszerelemzőkkel együttműködve olyan modelleket és prototípusokat dolgoznak ki, amelyek tartalmazzák az összes szükséges rendszerfunkciót. A felhasználói prototípusok működő modellekké alakításához a RAD-csapat jellemzően közös alkalmazásfejlesztési (JAD) technikákat és CASE - eszközöket használ. A felhasználói tervezés egy hosszú interaktív folyamatnak bizonyul, amely lehetővé teszi a felhasználók számára, hogy megértsék, módosítsák és végül kiválaszthassák a követelményeiknek megfelelő működő modellt.
3. A tervezés  az a szakasz, amelyben a fő feladat a programok és alkalmazások fejlesztése. Hasonló az SDLC „végrehajtási” szakaszához. 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 az általuk kidolgozott jelentések formájában. Feladataik közé tartozik a programozás és alkalmazásfejlesztés, a kódolás, a modulintegráció és a rendszertesztelés.
4. Váltás  – magában foglalja az adatátalakítási műveleteket, a tesztelést, az új rendszerre való átállást és a felhasználói oktatást. Feladataiban az SDLC végső szakaszához hasonlít. A hagyományos szoftverfejlesztési módszerekhez képest a teljes folyamat időben tömörített. Ennek eredményeként az új rendszer gyorsabban felépül, a vevőhöz kerül, és a munkahelyen is beépül.

Előnyök

A Rapid Application Development (RAD) technológia lehetővé teszi a következőket:

• a szoftvertermék piacra jutásának sebessége;
• a felhasználónak megfelelő felület;
• a projekt könnyű adaptálhatósága a változó követelményekhez;
• a rendszer funkcionalitásának egyszerű fejlesztése.

Lásd még

• vizuális programozás
• Gyors prototípuskészítés