RAD (programmering)

RAD (från engelska  rapid application development  - rapid application development) - konceptet att organisera den tekniska processen för att utveckla mjukvaruprodukter , fokuserat på snabbast möjliga resultat inför svåra tids- och budgetbegränsningar och vagt definierade produktkrav. Effekten av att påskynda utvecklingen uppnås genom att använda lämpliga tekniska medel och kontinuerligt, parallellt med utvecklingens framsteg, förtydligande av krav och utvärdering av aktuella resultat med inblandning av kunden. RAD skapades i slutet av 1980-talet som ett alternativ till de tidigare vattenfalls- och iterativa modellerna. Sedan slutet av 1900-talet har RAD blivit utbredd.

Samma term används för mjukvaruverktyg för snabb prototypframställning och mjukvaruutveckling. Typiska egenskaper hos sådana verktyg är maximal automatisering av rutinoperationer och den utbredda användningen av visuell programmering .

Historik

Skapandet av RAD-konceptet var resultatet av en kombination av ett antal faktorer.

Grundaren av RAD är IBM- medarbetaren James Martin, som på 1980 -talet formulerade de grundläggande principerna för RAD, baserat på Barry Boyms och Scott Schultz idéer. Och 1991 publicerade Martin en berömd bok, där han detaljerade begreppet RAD och möjligheterna för dess tillämpning. RAD håller nu på att bli det accepterade ramverket för att skapa verktyg för mjukvaruutveckling .

Utnämning

RAD förutsätter att mjukvaruutvecklingen utförs av ett litet team av utvecklare under en period av cirka tre till fyra månader med hjälp av inkrementell prototypframställning med hjälp av visuella modellerings- och utvecklingsverktyg. RAD-tekniken ger kunden ett aktivt engagemang i de tidiga stadierna - en undersökning av organisationen, utveckling av krav på systemet. Den sista av dessa egenskaper innebär full uppfyllelse av kundens krav, både funktionella och icke-funktionella, med hänsyn till deras eventuella förändringar under utvecklingen av systemet, samt att erhålla högkvalitativ dokumentation som säkerställer enkel drift och underhåll av systemet. Det innebär att merkostnaderna för support direkt efter leverans blir betydligt mindre. Således reduceras den totala tiden från utvecklingsstart till att en acceptabel produkt erhålls avsevärt med denna metod.

Applikation

RAD-teknik är inte universell, det är tillrådligt att använda den endast om projektet uppfyller alla eller några av villkoren:

  1. Kort tid. Det krävs att så snabbt som möjligt skapa ett system som uppfyller dagens krav. Ökningen i termer skapar en hög sannolikhet för en så betydande förändring av de grundläggande bestämmelserna som styr automatiserade aktiviteter att systemet kommer att bli moraliskt föråldrat redan innan designen är färdig.
  2. Otydligt definierade och/eller förändrade krav under utveckling. Kunden har en mycket grov uppfattning om arbetet med den framtida mjukvaruprodukten och kan inte tydligt formulera alla krav på programvaran. Kraven kanske inte definieras i början av projektet, eller så kan de ändras när projektet fortskrider.
  3. Begränsad budget med kundens vilja att delta i utvecklingen. Kunden har inte pengarna att betala för arbetet i ett stort team av designers och utvecklare under lång tid, men det finns en vilja att tilldela specialister för konstant direkt deltagande i utvecklingen och bedömningen av dess nuvarande tillstånd.
  4. Små volymer eller möjligheten att dela upp projektet i funktionella komponenter. Om det tänkta systemet är stort behöver det kunna brytas ner i mindre bitar, var och en med tydlig funktionalitet och minimalt beroende av de andra. De kan utfärdas sekventiellt eller parallellt (i det senare fallet är flera RAD-grupper involverade).
  5. Det grafiska användargränssnittet  är den viktigaste eller en av de viktigaste komponenterna i systemet. Det är i skapandet av gränssnittet som RAD-tekniken ger de största fördelarna, eftersom gränssnittet demonstreras direkt på prototypen och ganska snart efter projektets start. Det är till och med möjligt att direkt involvera kundens representant i utformningen av gränssnittet i den visuella editorn. Detta tillvägagångssätt undviker den typiska situationen när det gränssnitt som beskrivs av användaren i kraven (som regel utan att ta hänsyn till tekniska begränsningar) beter sig i praktiken helt annorlunda än vad användaren förväntade sig, även om systemet formellt sett helt uppfyller de dokumenterade kraven.
  6. Låg beräkningskomplexitet. Databehandling i ett projekt handlar om en kombination av typiska operationer, varav alla eller de flesta redan är implementerade i form av tillgängliga bibliotek. Ursprungliga databehandlingsalgoritmer krävs antingen inte alls, eller så är de ganska enkla och kan implementeras snabbt och utan större svårighet.

Om kraven på systemet är tydligt definierade och inte kan ändras, krävs inte involvering av kunden i utvecklingsprocessen och den traditionella hierarkiska utvecklingen ( kaskadmetoden ) kan bli mer effektiv. RAD ger inte heller praktiskt taget några fördelar i projekt, vars huvudsakliga komplexitet bestäms av behovet av att implementera komplexa, icke-standardiserade databehandlingsalgoritmer, och användargränssnittet är antingen frånvarande som sådant eller mycket enkelt och helt standard.

Grundläggande principer

Principerna för RAD-teknik syftar till att tillhandahålla dess tre huvudsakliga fördelar - hög utvecklingshastighet, låg kostnad och hög kvalitet. Att få till en mjukvaruprodukt av hög kvalitet är mycket svårt, och en av huvudorsakerna till de svårigheter som uppstår är att utvecklaren och kunden ser ämnet utveckling (mjukvara) på olika sätt.

Principerna för RAD gäller inte bara för implementering, utan också för alla stadier av livscykeln, i synnerhet för stadiet av organisationsundersökning, kravuppbyggnad, analys och design.

Utvecklingsfaser

  1. Planering  är en uppsättning krav som erhålls från systemplanering och analys av livscykelutvecklingsproceduren (SDLC). I detta skede diskuterar användare, chefer och IT-specialister projektets mål, dess omfattning, systemkrav samt de svårigheter som kan uppstå under utvecklingen. Fasen avslutas med att RAD-gruppen kommer överens om centrala punkter och får tillstånd från projektledarna att fortsätta.
  2. Användardesign  - Under denna fas interagerar användare med systemanalytiker för att utveckla modeller och prototyper som inkluderar alla nödvändiga systemfunktioner. För att översätta användarprototyper till arbetsmodeller använder RAD-teamet vanligtvis tekniker för gemensam applikationsutveckling (JAD) och CASE- verktyg. Användardesign visar sig vara en lång interaktiv process som låter användare förstå, modifiera och i slutändan välja en fungerande modell som uppfyller deras krav.
  3. Design  är det stadium där huvuduppgiften är att utveckla program och applikationer. Liknar "implementeringsstadiet" i SDLC. I RAD fortsätter dock användarna att delta och kan fortfarande föreslå förändringar eller förbättringar i form av rapporter de tagit fram. Deras uppgifter inkluderar programmering och applikationsutveckling, kodning, modulintegration och systemtestning.
  4. Switching  - inkluderar datakonverteringsoperationer, testning, övergång till ett nytt system och användarutbildning. I sina uppgifter liknar den slutskedet av SDLC. Jämfört med traditionella mjukvaruutvecklingsmetoder är hela processen komprimerad i tid. Som ett resultat av detta byggs det nya systemet snabbare, levereras till kunden och installeras på arbetsplatsen.

Fördelar

Rapid Application Development (RAD) -teknik låter dig tillhandahålla:

Se även