RAD-malli ohjelmistotekniikassa: Kaavio ja vaiheet
Lucas Bennett
⚡ Älykäs yhteenveto
RAD-malli ohjelmistotekniikassa eli nopeassa sovelluskehityksessä on prototyyppiping-pohjainen prosessi, joka asettaa nopean toimituksen etusijalle suunnittelun sijaan. Se rakentaa ohjelmistoa viiden vaiheen kautta, liiketoimintamallinnuksesta testaukseen ja käyttöönottoon.
Mikä on RAD-malli?
RAD malli eli nopea sovelluskehitysmalli on prototyyppiin perustuva ohjelmistokehitysprosessi.ping ilman erityistä suunnittelua. RAD-malli kiinnittää vähemmän huomiota suunnitteluun ja antaa enemmän painoarvoa kehitystehtäville tavoitteenaan toimittaa ohjelmisto lyhyessä ajassa.
SDLC RAD -mallinnuksessa on seuraavat vaiheet:
- Liiketoiminnan mallinnus
- Tietomallinnus
- Prosessin mallinnus
- Sovellusten sukupolvi
- Testaus ja liikevaihto
Alla oleva RAD-mallikaavio näyttää, miten nämä vaiheet kytkeytyvät toisiinsa:
Se keskittyy tiedon syöte-tuotoslähteeseen ja -kohteeseen. Se korostaa projektien toimittamista pienissä osissa; suuremmat projektit jaetaan sarjaan pienempiä projekteja. RAD-mallinnuksen pääpiirteitä ovat mallien, työkalujen, prosessien ja koodin uudelleenkäyttö, kuten alla on esitetty:
RAD-mallin eri vaiheet
Nopean sovelluskehityksen mallissa on viisi päävaihetta:
| RAD-mallin vaiheet | RAD-mallinnuksessa suoritetut toiminnot |
|---|---|
| Liiketoiminnan mallinnus | Tuote on suunniteltu eri liiketoimintakanavien välisen tiedonkulun ja jakelun perusteella. |
| Tietomallinnus | Liiketoiminnan mallintamisesta kerätty tieto jalostetaan joukoksi tietoobjekteja, jotka ovat liiketoiminnan kannalta tärkeitä |
| Prosessin mallinnus | Tietomallinnusvaiheessa ilmoitetut dataobjektit muunnetaan liiketoimintatoiminnon toteuttamiseen tarvittavan tiedonkulun saavuttamiseksi. |
| Sovellusten sukupolvi | Automatisoidut työkalut muuntavat prosessi- ja datamallit prototyypeiksi ohjelmiston rakentamisen aikana |
| Testaus ja liikevaihto | Prototyypit testataan yksittäin jokaisen iteraation aikana, mikä lyhentää RAD-testauksen kokonaisaikaa. |
Milloin RAD-metodologiaa käytetään?
- Kun järjestelmä on valmistettava lyhyessä ajassa (2-3 kuukautta)
- Kun vaatimukset ovat tiedossa
- Kun käyttäjä on mukana koko elinkaaren ajan
- Kun tekninen riski on pienempi
- Kun on tarve luoda järjestelmä, joka voidaan moduloida 2-3 kuukaudessa
- Kun budjetti on riittävän suuri, jotta suunnittelijoille jää varaa mallinnukseen ja automatisoitujen koodinluontityökalujen kustannuksiin
Nopean sovelluskehityksen edut ja haitat
Kuten missä tahansa SDLC-lähestymistavassa, RAD:ssa on kompromisseja:
| RAD-mallin edut | RAD-mallin haitat |
|---|---|
| Joustava ja mukautuva muutoksiin | Sitä ei voi käyttää pienempiin projekteihin |
| Siitä on hyötyä, kun haluat pienentää projektin kokonaisriskiä | Kaikki sovellukset eivät ole yhteensopivia RAD:n kanssa |
| Tuotokset on helpompi siirtää, koska skriptit, korkean tason vatsalihaksettracja käytetään välikoodeja | Kun tekninen riski on suuri, se ei sovellu |
| Code generaattorit ja koodin uudelleenkäyttö vähentävät manuaalista koodausta | Jos kehittäjät eivät ole sitoutuneet toimittamaan ohjelmistoja ajoissa, RAD-projektit voivat epäonnistua |
| Sen prototyyppiping luonto tarkoittaa vähemmän vikojen mahdollisuutta | Aikataulun muutos siirtää ominaisuuksia myöhempään versioon julkaisun nopeamman valmistumisen varmistamiseksi, mikä vähentää ominaisuuksien määrää. |
| Jokainen RAD-vaihe tarjoaa asiakkaalle korkeimman prioriteetin toiminnallisuuden | Skaalautuvuus kärsii, koska RAD-kehitetty sovellus alkaa prototyyppinä ja kehittyy valmiiksi sovellukseksi |
| Vähemmällä henkilöstömäärällä tuottavuutta voidaan lisätä lyhyessä ajassa | Edistyminen ja ongelmat ovat vaikeita trackoska ei ole dokumentaatiota siitä, mitä on tehty |
RAD-malli vs. ketterä vs. vesiputousmalli
Aloittelijat sekoittavat usein RAD-menetelmät ketteriin ja vesiputousmenetelmään. Kolme SDLC-lähestymistapaa tasapainottavat nopeutta, suunnittelua ja joustavuutta eri tavoin:
| Aspect | RAD malli | Ketterä | Vesiputous |
|---|---|---|---|
| Ydinlähestymistapa | Prototyping koodin uudelleenkäytön avulla | Iteratiiviset sprintit palautteen avulla | Lineaariset peräkkäiset vaiheet |
| Suunnittelu | Minimaalinen etukäteissuunnittelu | Adaptiivinen suunnittelu sprinttiä kohden | Yksityiskohtainen etukäteissuunnittelu |
| Parhaiten sopiva | Modulaariset järjestelmät tiukoilla aikatauluilla | Kehittyvät vaatimukset | Vakaat, hyvin määritellyt vaatimukset |
