Brzi razvoj aplikacija. RAD metodologija - Rapid Application Development

Jedan od mogućih pristupa razvoju softvera u okviru spiralnog modela životnog ciklusa je onaj primljen u u posljednje vrijemeširoka uporaba RAD (Rapid Application Development) metodologije. Ovaj izraz obično se odnosi na proces razvoja softvera koji sadrži 3 elementa:

    mali tim programera (od 2 do 10 ljudi);

    kratak, ali pažljivo razrađen raspored proizvodnje (od 2 do 6 mjeseci);

    ponavljajući ciklus u kojem programeri, kako aplikacija počinje poprimati oblik, zahtijevaju i implementiraju zahtjevi proizvoda dobiven kroz interakciju s kupcem.

Razvojni tim trebao bi biti skupina stručnjaka s iskustvom u analizi, dizajnu, generiranju koda i testiranju softvera korištenjem CASE alata. Članovi tima također moraju biti sposobni prevesti prijedloge krajnjih korisnika u radne prototipove.

Životni ciklus softvera prema RAD metodologiji sastoji se od četiri faze:

    analiza zahtjeva i faza planiranja;

    faza projektiranja;

    faza izgradnje;

    faza implementacije.

U fazi analize i planiranja zahtjeva korisnici sustava određuju funkcije koje on mora obavljati, identificiraju one najvišeg prioriteta koje je potrebno prvo razraditi te opisuju informacijske potrebe. Definiranje zahtjeva uglavnom provode korisnici pod vodstvom specijaliziranih programera. Opseg projekta je ograničen, a određen je vremenski okvir za svaku od sljedećih faza. Osim toga, utvrđuje se i sama mogućnost provedbe ovog projekta unutar utvrđenih ograničenja financiranja, na zadanom hardveru i sl. Rezultat ove faze trebao bi biti popis i prioritet funkcija budućeg IS-a, preliminarni funkcionalni i informacijski modeli IS-a.

Tijekom faze projektiranja, neki korisnici sudjeluju u tehničkom dizajnu sustava pod vodstvom specijaliziranih programera. CASE alati koriste se za brzu izradu radnih prototipova aplikacija. Korisnici u izravnoj interakciji s njima pojašnjavaju i dopunjuju zahtjeve sustava koji nisu identificirani u prethodnoj fazi. O procesima sustava raspravlja se detaljnije. Funkcionalni model se analizira i po potrebi prilagođava. Svaki proces se detaljno razmatra. Po potrebi se za svaki elementarni proces izrađuje djelomični prototip: zaslon, dijalog, izvješće koje otklanja nejasnoće ili dvosmislenosti. Utvrđuju se uvjeti za ograničenje pristupa podacima. U istoj fazi utvrđuje se skup potrebne dokumentacije.

Nakon detaljnog utvrđivanja sastava procesa, broj funkcionalni elementi sustav se razvija i donosi se odluka o podjeli IS-a na podsustave koje može implementirati jedan tim programera u vremenu prihvatljivom za RAD projekte - oko 60 - 90 dana. Pomoću CASE alata projekt se raspodjeljuje na različite timove (funkcionalni model je podijeljen). Rezultati ove faze trebali bi biti:

    general informacijski model sustavi;

    funkcionalni modeli sustava u cjelini i podsustava implementirani od strane pojedinih razvojnih timova;

    sučelja između autonomno razvijenih podsustava precizno definiranih pomoću CASE alata;

    izgrađeni prototipovi ekrana, izvješća, dijaloga.

Svi modeli i prototipovi moraju biti dobiveni pomoću onih CASE alata koji će se koristiti u budućnosti pri izgradnji sustava. Ovaj zahtjev To je zbog činjenice da u tradicionalnom pristupu, prilikom prijenosa informacija o projektu iz faze u fazu, može doći do gotovo nekontroliranog iskrivljenja podataka. Korištenje jedinstvenog okruženja za pohranu informacija o projektu omogućuje vam da izbjegnete ovu opasnost.

Za razliku od tradicionalnog pristupa, koji je koristio specifične alate za izradu prototipa koji nisu dizajnirani za izradu stvarnih aplikacija i odbačene prototipove nakon što su poslužili u svrhu razjašnjavanja nejasnoća u dizajnu, u RAD pristupu svaki prototip se razvija u dio budući sustav. Tako se potpunije i korisnije informacije prenose u sljedeću fazu.

Faza izgradnje je mjesto gdje se odvija sam brzi razvoj aplikacije. U ovoj fazi programeri iterativno grade stvarni sustav na temelju modela dobivenih u prethodnoj fazi, kao i nefunkcionalnih zahtjeva. Programski kod je djelomično generiran pomoću automatskih generatora koji primaju informacije izravno iz repozitorija CASE alata. U ovoj fazi krajnji korisnici ocjenjuju dobivene rezultate i vrše prilagodbe ako tijekom procesa razvoja sustav više ne zadovoljava prethodno definirane zahtjeve. Testiranje sustava provodi se izravno tijekom procesa razvoja.

Nakon završetka rada svakog pojedinog razvojnog tima, provodi se postupna integracija ovog dijela sustava s ostalim, potpuna programski kod, testiranje se provodi kako bi se provjerilo kako ovaj dio aplikacije radi zajedno s ostalima, a zatim se testira sustav u cjelini. Fizički dizajn sustava je završen:

    utvrđuje se potreba za distribucijom podataka;

    provodi se analiza korištenja podataka;

    provodi se fizički dizajn baze podataka;

    utvrđuju se zahtjevi za hardverskim resursima;

    utvrđuju se načini povećanja produktivnosti;

    U tijeku je izrada projektne dokumentacije.

Rezultat faze je gotov sustav koji zadovoljava sve dogovorene zahtjeve.

U fazi implementacije provodi se obuka korisnika, organizacijske promjene i paralelno s implementacijom novi sustav radi se s postojećim sustavom (do potpune implementacije novog). Budući da je faza izgradnje prilično kratka, planiranje i priprema za implementaciju moraju započeti rano, obično tijekom faze projektiranja sustava. Zadana shema razvoja IS-a nije apsolutna. Moguće su različite opcije, ovisno npr. o početnim uvjetima u kojima se odvija razvoj: razvija se potpuno novi sustav; već je provedeno istraživanje poduzeća i postoji model njegovih aktivnosti; Poduzeće već ima neki IP koji se može koristiti kao početni prototip ili se mora integrirati s onim koji se razvija.

Treba, međutim, napomenuti da RAD metodologija, kao ni svaka druga, ne može tvrditi da je univerzalna; dobra je prvenstveno za relativno male projekte razvijene za određenog kupca. Ako se razvija standardni sustav koji nije gotov proizvod, već je kompleks standardnih komponenti, centralno održavan, prilagođen softverskim i hardverskim platformama, DBMS-u, telekomunikacijama, organizacijskim i ekonomskim značajkama objekata implementacije i integriran s postojećim razvojem, u prvi plan dolaze: pokazatelji projekta poput upravljivosti i kvalitete, koji mogu biti u sukobu s jednostavnošću i brzinom razvoja. Za takve projekte potrebno je visoka razina planiranje i stroga dizajnerska disciplina, strogo pridržavanje unaprijed razvijenih protokola i sučelja, što smanjuje brzinu razvoja.

RAD metodologija nije primjenjiva za izgradnju složenih proračunskih programa, operativnih sustava ili programa za upravljanje svemirskim letjelicama, tj. programe koji zahtijevaju pisanje velike količine (stotine tisuća redaka) jedinstvenog koda.

Nisu prikladne aplikacije koje nemaju jasno definiran dio sučelja koji jasno definira logiku sustava (npr. aplikacije u stvarnom vremenu) i aplikacije o kojima ovisi sigurnost ljudi (npr. upravljanje zrakoplovom ili nuklearnom elektranom). za razvoj pomoću RAD metodologije, budući da su iterativne, pristup pretpostavlja da prvih nekoliko verzija najvjerojatnije neće biti potpuno funkcionalne, što je u ovom slučaju isključeno.

Veličina aplikacija procjenjuje se na temelju tzv. funkcionalnih elemenata (zasloni, poruke, izvješća, datoteke itd.). Ova metrika ne ovisi o programskom jeziku u kojem se odvija razvoj. Veličina aplikacije koja se može izvršiti korištenjem RAD metodologije, za dobro uspostavljeno IC razvojno okruženje s maksimalnom ponovnom upotrebom softverskih komponenti, određena je kako slijedi:

Kao sažetak navodimo glavna načela RAD metodologije:

    razvoj aplikacija u iteracijama;

    mogućnost potpunog završetka rada u svakoj fazi životnog ciklusa;

    obvezno uključivanje korisnika u proces razvoja IS-a;

    potrebnu upotrebu CASE alata za osiguranje integriteta projekta;

    korištenje alata za upravljanje konfiguracijom koji olakšavaju unošenje izmjena u projekt i održavanje gotovog sustava;

    potrebna uporaba generatora koda;

    korištenje prototipa za bolje razumijevanje i zadovoljenje potreba krajnjeg korisnika;

    testiranje i razvoj projekta provodi se istodobno s razvojem;

    razvoj od strane malog, dobro vođenog tima stručnjaka;

    kompetentno upravljanje razvojem sustava, jasno planiranje i kontrola izvršenja radova.

Razvoj softverskih proizvoda poznaje mnoge vrijedne metodologije - drugim riječima, uspostavljene najbolje prakse. Izbor ovisi o specifičnostima projekta, proračunskom sustavu, subjektivnim preferencijama, pa čak i temperamentu upravitelja. U članku su opisane metodologije s kojima se redovito susrećemo u Edisonu.

1. "Model vodopada" (kaskadni model ili "vodopad")


Jedan od najstarijih, uključuje uzastopno prolaženje faza, od kojih svaka mora biti u potpunosti dovršena prije nego što započne sljedeća. Model Waterfall olakšava upravljanje projektom. Zahvaljujući svojoj krutosti, razvoj se odvija brzo, trošak i rok su unaprijed određeni. Ali ovo je dvosjekli mač. Kaskadni model će dati odličan rezultat samo u projektima s jasno i unaprijed određenim zahtjevima i načinima njihove provedbe. Ne postoji način da se napravi korak unatrag; testiranje počinje tek nakon što je razvoj dovršen ili gotovo dovršen. Proizvodi razvijeni prema ovom modelu bez opravdanog izbora mogu imati nedostatke (popis zahtjeva se ne može prilagoditi u bilo kojem trenutku), koji postaju poznati tek na kraju zbog strogog slijeda radnji. Trošak unošenja promjena je visok jer zahtijeva čekanje dok se cijeli projekt ne završi da bi se on pokrenuo. Međutim, fiksni trošak često nadmašuje nedostatke pristupa. Ispravljanje nedostataka uočenih tijekom izrade je moguće, a prema našem iskustvu zahtijeva jedan do tri dodatna dogovora uz ugovor s malom tehničkom specifikacijom.

Korištenjem kaskadni model stvorili smo mnoge projekte od nule, uključujući samo razvoj tehničkih specifikacija. Projekti o kojima se piše na Habréu: srednji - rendgenska mikrotomografija, mali - automatsko ažuriranje Windows servisa na AWS-u.

Kada koristiti metodologiju vodopada?

  • Samo kada su zahtjevi poznati, shvaćeni i zabilježeni. Nema proturječnih zahtjeva.
  • Nema problema s dostupnošću programera s potrebnim kvalifikacijama.
  • U relativno malim projektima.

2. "V-model"


Naslijedio strukturu "korak po korak" od kaskadnog modela. Model u obliku slova V primjenjiv je za sustave kojima je posebno važan neprekinuti rad. Na primjer, aplikacijski programi u klinikama za praćenje pacijenata, integrirani softver za upravljačke mehanizme za hitne zračne jastuke vozila i tako dalje. Posebnost modela je što je usmjeren na temeljitu provjeru i testiranje proizvoda koji je već u početnoj fazi projektiranja. Faza testiranja provodi se istovremeno s odgovarajućom fazom razvoja, na primjer, jedinični testovi se pišu tijekom kodiranja.

Primjer našeg rada po V-metodologiji - mobilna aplikacija za europski mobilni operater, što štedi troškove roaminga tijekom putovanja. Projekt se provodi prema jasnoj specifikaciji, ali uključuje značajnu fazu testiranja: praktičnost sučelja, funkcionalnost, opterećenje i uključujući integraciju, koja bi trebala potvrditi da je nekoliko komponenti iz raznih proizvođača zajedno rade stabilno, krađa novca i kredita je nemoguća.

Kada koristiti V-model?

  • Ako je potrebno temeljito testiranje proizvoda, tada će V-model opravdati svoju inherentnu ideju: validaciju i provjeru.
  • Za male i srednje projekte gdje su zahtjevi jasno definirani i fiksni.
  • U uvjetima dostupnosti inženjera s potrebnim kvalifikacijama, posebno ispitivača.

3. "Inkrementalni model" (inkrementalni model)

U inkrementalnom modelu puni zahtjevi sustava podijeljeni su u različite sklopove. Terminologija se često koristi za opisivanje sastavljanja softvera korak po korak. Odvija se nekoliko razvojnih ciklusa koji zajedno čine životni ciklus"viševodopad". Ciklus je podijeljen na manje, lako kreirane module. Svaki modul prolazi kroz faze definiranja zahtjeva, dizajna, kodiranja, implementacije i testiranja. Proces inkrementalnog razvoja uključuje puštanje na prvom mjestu velika pozornica proizvoda u osnovnoj funkcionalnosti, a zatim sekvencijalno dodavanje novih funkcija, takozvanih “inkrementacija”. Proces se nastavlja dok se ne stvori kompletan sustav.

Inkrementalni modeli se koriste tamo gdje su pojedinačni zahtjevi za promjenama jasni i mogu se lako formalizirati i implementirati. U našim projektima koristili smo ga za izradu DefView čitača, a potom i mreže elektroničke knjižnice Vivaldi.

Kao primjer, opisat ćemo suštinu jednog inkrementa. Vivaldijeva mreža elektroničkih knjižnica zamijenila je DefView. DefView je povezan s jednim poslužiteljem dokumenata i sada se može povezati s mnogima. Server za pohranu podataka instaliran je na mjestu institucije koja želi emitirati svoj sadržaj određenoj publici, koja izravno pristupa dokumentima i pretvara ih u traženi format. Pojavio se korijenski element arhitekture - središnji poslužitelj Vivaldi, nastupa kao samac tražilica na svim poslužiteljima za pohranu instaliranim u raznim institucijama.

Kada koristiti inkrementalni model?

  • Kada su osnovni zahtjevi za sustav jasno definirani i razumljivi. U isto vrijeme, neki detalji mogu biti poboljšani tijekom vremena.
  • Potrebno je rano uvođenje proizvoda na tržište.
  • Postoji nekoliko rizičnih značajki ili ciljeva.

4. "RAD Model" (model brzog razvoja aplikacija ili brzi razvoj aplikacija)

RAD model je vrsta inkrementalnog modela. U RAD modelu, komponente ili funkcije razvija nekoliko visoko kvalificiranih timova paralelno, poput nekoliko mini-projekata. Vremenski okvir jednog ciklusa je strogo ograničen. Stvoreni moduli se zatim integriraju u jedan radni prototip. Sinergija vam omogućuje da vrlo brzo klijentu pružite nešto što radi na pregled kako bi mogao primiti povratna informacija i unošenje promjena.

Model brzog razvoja aplikacije uključuje sljedeće faze:

  • Poslovno modeliranje: definiranje popisa protoka informacija između različitih odjela.
  • Modeliranje podataka: informacije prikupljene u prethodnoj fazi koriste se za određivanje objekata i drugih entiteta potrebnih za kruženje informacija.
  • Modeliranje procesa: Tokovi informacija povezuju objekte radi postizanja razvojnih ciljeva.
  • Izradite aplikaciju: koristi automatizirane alate za sklapanje za pretvaranje CAD modela u kod.
  • Testiranje: testiraju se nove komponente i sučelja.
Kada se koristi RAD model?

Može se koristiti samo s visoko kvalificiranim i visoko specijaliziranim arhitektima. Proračun projekta je velik za plaćanje ovih stručnjaka zajedno s troškovima gotovih alata automatizirana montaža. RAD model može se odabrati s pouzdanim znanjem ciljani posao te potreba hitne izrade sustava unutar 2-3 mjeseca.

5. “Agilni model” (fleksibilna metodologija razvoja)


U “agilnoj” metodologiji razvoja, nakon svake iteracije kupac može promatrati rezultat i shvatiti zadovoljava li ga ili ne. Ovo je jedna od prednosti fleksibilnog modela. Njegovi nedostaci uključuju činjenicu da je zbog nedostatka specifičnih formulacija rezultata teško procijeniti troškove rada i troškove potrebne za razvoj. Ekstremno programiranje(XP) jedna je od najpoznatijih primjena agilnog modela u praksi.

Ova vrsta se temelji na kratkim dnevnim sastancima - “Scrum” i sastancima koji se redovito ponavljaju (jednom tjedno, jednom svaka dva tjedna ili jednom mjesečno), pod nazivom “Sprint”. Na dnevnim sastancima članovi tima raspravljaju o:

  • izvješće o obavljenom poslu od posljednjeg Scruma;
  • popis zadataka koje zaposlenik mora obaviti prije sljedećeg sastanka;
  • poteškoće koje su se pojavile tijekom rada.
Metodologija je prikladna za velike projekte ili one koji imaju dug životni ciklus, uz stalno prilagođavanje tržišnim uvjetima. Sukladno tome, zahtjevi se mijenjaju tijekom procesa implementacije. Vrijedno je zapamtiti klasu kreativnih ljudi koji imaju tendenciju stvarati, smišljati i isprobavati nove ideje na tjednoj ili čak dnevnoj bazi. Agilni razvoj je najprikladniji za ovu vrstu menadžera. Razvijamo interne startupe tvrtke koristeći Agile. Primjer projekata klijenata je elektronički sustav medicinskog pregleda, stvoren za provođenje masovnih medicinskih pregleda u nekoliko minuta. U drugom odlomku ovog pregleda naši američki partneri opisali su vrlo važna stvar, temelj uspjeha u Agileu.

Kada koristiti Agile?

  • Kada se potrebe korisnika neprestano mijenjaju u dinamičnom poslovanju.
  • Agilne promjene provode se po nižoj cijeni zbog čestih povećanja.
  • Za razliku od modela vodopada, agilni model zahtijeva samo malo planiranja da bi se projekt pokrenuo.

6. “Iterativni model” (iterativni ili iterativni model)

Iterativni model životnog ciklusa ne zahtijeva kompletnu specifikaciju zahtjeva za početak. Umjesto toga, stvaranje počinje implementacijom dijela funkcionalnosti, koji postaje temelj za definiranje daljnjih zahtjeva. Ovaj proces se ponavlja. Verzija možda nije savršena, glavna stvar je da radi. Razumijevajući konačni cilj, težimo tome da svaki korak bude učinkovit, a svaka verzija izvediva.

Dijagram prikazuje iterativni "razvoj" Mona Lise. Kao što vidite, u prvoj iteraciji postoji samo skica Mona Lise, u drugoj se pojavljuju boje, a treća iteracija dodaje detalje, zasićenost i dovršava proces. U inkrementalnom modelu, funkcionalnost proizvoda se gradi dio po dio, proizvod se sastoji od dijelova. Za razliku od iterativnog modela, svaki komad predstavlja cjelovit element.

Primjer iterativnog razvoja je prepoznavanje glasa. Prva istraživanja i priprema znanstvene aparature započela su davno, prvo u mislima, a potom i na papiru. Sa svakom novom iteracijom, kvaliteta prepoznavanja se poboljšavala. Međutim, savršeno prepoznavanje još nije postignuto, stoga problem još nije u potpunosti riješen.

Kada je optimalno koristiti iterativni model?

  • Zahtjevi za konačni sustav jasno definiran i unaprijed shvaćen.
  • Projekt je velik ili vrlo velik.
  • Glavni cilj mora biti definiran, ali detalji provedbe mogu se razvijati tijekom vremena.

7. "Spiralni model" (spiralni model)


“Spiralni model” sličan je inkrementalnom modelu, ali s naglaskom na analizi rizika. Dobro funkcionira za rješavanje kritičnih poslovnih problema, kada je neuspjeh nekompatibilan s aktivnostima tvrtke, u kontekstu izdavanja novih linije proizvoda, ako je potrebno znanstveno istraživanje i praktično testiranje.

Spiralni model uključuje 4 stupnja za svaki zavoj:

  1. planiranje;
  2. analiza rizika;
  3. dizajn;
  4. evaluacija rezultata i, ako je kvaliteta zadovoljavajuća, prijelaz na novu fazu.
Ovaj model nije prikladan za male projekte, razuman je za složene i skupe, na primjer, razvoj sustava protoka dokumenata za banku, kada svaki sljedeći korak zahtijeva više analiza procijeniti posljedice nego programiranje. O projektu razvoja EDMS-a za ODU Sibira SO UES, dva sastanka o promjeni kodifikacije odjeljaka elektronička arhiva treba 10 puta dulje nego da programer spoji dvije mape. Državni projekti u kojima smo sudjelovali započeli su pripremom stručne javnosti skupog koncepta koji nipošto nije uvijek beskoristan, jer se isplati u nacionalnim razmjerima.

Sažmimo


Slajd pokazuje razlike između dvije najčešće metodologije.

U moderna praksa modeli razvoja softver viševarijantni. Ne postoji jedan pravi model za sve projekte, početne uvjete i modele plaćanja. Čak ni Agile, koji nam je toliko drag, ne može se svugdje primijeniti zbog nepripremljenosti pojedinih kupaca ili nemogućnosti fleksibilnog financiranja. Metodologije se dijelom preklapaju u sredstvima, a dijelom su slične jedna drugoj. Neki drugi koncepti korišteni su samo za promicanje vlastitih prevoditelja i nisu unijeli ništa novo u praksu.

O razvojnim tehnologijama:
Još jednom o sedam glavnih metodologija razvoja.
10 glavnih pogrešaka u sustavima skaliranja.
8 načela planiranja razvoja koja život čine jednostavnijim.
5 glavnih rizika u razvoju softvera po narudžbi.

U anketi mogu sudjelovati samo registrirani korisnici. , molim te.

Jedan od pristupa razvoju softvera u okviru spiralnog modela životnog ciklusa je široko korištena metodologija (tehnologija) za brzi razvoj aplikacija RAD (Rapid Application Development). Ovaj model je vrlo prikladan za razvoj kurikuluma, jer uključuje tri komponente:

Ø mali tim programera (od 2 do 10 ljudi);

Ø kratak, ali pažljivo razrađen raspored proizvodnje (od 2 do 6 mjeseci);

Ø iterativni ciklus u kojem programeri, kako aplikacija počinje poprimati oblik, zahtijevaju i implementiraju u proizvod zahtjeve primljene kroz interakciju s kupcem.

Razmotrimo ovaj model detaljnije. Razvojni tim trebao bi biti skupina stručnjaka s iskustvom u analizi, dizajnu, generiranju koda i testiranju softvera korištenjem CASE alata, sposobnih za dobru interakciju s krajnjim korisnicima i transformaciju njihovih prijedloga u radne prototipove. Životni ciklus softvera prema RAD metodologiji sastoji se od četiri faze(Slika 21):

1. Analiza i planiranje zahtjeva;

2. Dizajn;

3. Konstrukcije;

4. Implementacije.


Na prva faza analiza zahtjeva i planiranje korisnici sustava određuju funkcije koje on treba obavljati, izdvajaju one najvišeg prioriteta koje je potrebno prvo razraditi te opisuju informacijske potrebe (veze). Formuliranje zahtjeva sustava uglavnom provode korisnici pod vodstvom specijaliziranih programera. Opseg projekta je ograničen, a za svaku sljedeću fazu utvrđen je vremenski okvir. Osim toga, sama mogućnost realizacije projekta u zadane veličine financiranje, na postojećem hardveru itd.

Rezultat faze trebao bi biti: popis prioritetnih funkcija budućeg PS-a; preliminarni funkcionalni model PS; preliminarni informacijski model PS-a.

Na druga faza dizajn sudjeluju neki korisnici tehnički dizajn sustava pod vodstvom specijalista programera te u interakciji s njima razjasniti i dopuniti sistemske zahtjeve koji nisu identificirani u prethodnoj fazi. Razmotreno detaljnije procesi sustava. Po potrebi se prilagođava funkcionalni model, izrađuju se parcijalni prototipovi: ekrani, izvješća, otklanjaju nejasnoće ili dvosmislenosti. Zahtjevi su uspostavljeni ograničenja pristupa podacima. U istoj fazi utvrđuje se potrebna dokumentacija. Nakon detaljnog određivanja sastava procesa, procjenjuje se broj funkcionalnih elemenata sustava koji se razvija i donosi odluka o podjeli sustava na podsustave.

Rezultati ove faze trebali bi biti: opći informacijski model sustava; funkcionalni modeli sustava u cjelini i podsustava; precizno definirana sučelja između autonomno razvijenih podsustava; izgrađeni prototipovi ekrana, izvješća, dijaloga.

Za razliku od tradicionalnog pristupa, koji je koristio specifične alate za izradu prototipova koji nisu dizajnirani za izradu stvarnih aplikacija i odbacivao prototipove nakon što su poslužili svrsi razjašnjavanja dvosmislenosti dizajna, U RAD pristupu svaki se prototip razvija u dio budućeg sustava. Tako se potpunije i korisnije informacije prenose u sljedeću fazu.

Na treća faza konstrukcija Brzi razvoj same aplikacije (implementacija podsustava) provodi se direktno. U ovoj fazi programeri iterativno grade stvarni sustav na temelju modela dobivenih u prethodnoj fazi, kao i nefunkcionalnih zahtjeva. U ovoj fazi krajnji korisnici ocjenjuju dobivene rezultate i vrše prilagodbe ako tijekom procesa razvoja sustav više ne zadovoljava prethodno definirane zahtjeve. Testiranje sustava provodi se tijekom procesa razvoja.

Nakon završetka razvoja podsustava, ovaj dio sustava se postupno integrira s ostatkom, generira se kompletan programski kod te se testira sustav u cjelini. Dovršen je fizički dizajn sustava: utvrđena je potreba za distribucijom podataka; provodi se analiza korištenja podataka; provodi se fizički dizajn baze podataka; utvrđuju se zahtjevi za hardverskim resursima; utvrđuju se načini povećanja produktivnosti; U tijeku je izrada projektne dokumentacije.

Rezultat faze je spreman sustav, zadovoljavajući sve dogovorene zahtjeve.

Na četvrta faza implementacija osposobljavanje korisnika, provode se organizacijske promjene te se paralelno s implementacijom novog sustava radi s postojeći sustav(do potpune implementacije novog). Budući da je faza izgradnje prilično kratka, planiranje i priprema za implementaciju moraju započeti rano, obično tijekom faze projektiranja sustava.

RAD tehnologija (kao i svaka druga) ne može tvrditi da je univerzalna; dobra je prvenstveno za relativno male projekte razvijene za određenog kupca. Nije primjenjivo za razvoj operativni sustavi; složeni računski programi s velikom količinom programskog koda i složenim jedinstvenim upravljačkim algoritmima; aplikacije koje nemaju jasno definiran dio sučelja koji jasno definira logiku sustava (aplikacije u stvarnom vremenu), budući da iterativni pristup pretpostavlja da prvih nekoliko verzija neće u potpunosti zadovoljiti zahtjeve.

U zaključku navodimo osnovni principi RAD tehnologije:

Ø razvoj aplikacije u iteracijama;

Ø izborni završetak rada u svakoj fazi životnog ciklusa;

Ø obvezno uključivanje korisnika u fazi razvoja;

Ø korištenje prototipa za razjašnjavanje i zadovoljenje svih zahtjeva krajnji korisnik;

Ø testiranje i razvoj projekta istovremeno s razvojem;

Ø kompetentno upravljanje razvojem, jasno planiranje i kontrola izvršenja posla.


Sigurnosna pitanja do poglavlja 3:

1. Što je standardizacija i certifikacija softverskog proizvoda?

2. Koje vrste standarda postoje?

3. Navedite najpoznatije standarde životnog ciklusa koji su korišteni za razvoj softvera?

4. Što je životni ciklus softvera?

5. Navedite glavne faze životnog ciklusa softvera. Što je proces, akcija, zadatak?

6. Koje vrste procesa i specifičnih procesa se sjećate?

7. Objasnite osnovne inženjerske procese životnog ciklusa softvera.

8. Što je model životnog ciklusa softvera? Dajte definicije osnovnih pojmova povezanih s pojmom “model”.

9. Koje vrste modela poznajete? Koje su njihove prednosti, nedostaci, opseg primjenjivosti?

10. Što možete reći o značajkama modela životnog ciklusa vodopada?

11.Koja je razlika između generaliziranog kaskadnog modela i osnovnog?

12. Što možete reći o značajkama spiralnog modela životnog ciklusa?

13.Nabrojati komponente RAD tehnologije. Koje se vrste softvera mogu koristiti za razvoj RAD tehnologije?

14.Opišite glavne faze životnog ciklusa RAD tehnologije.

15.Nabrojati osnovne principe RAD tehnologije.


REFERENCE

1. Aptekar M.D., Ramazanov S.K., Freger G.E. Povijest inženjerskih aktivnosti. – Kijev, 2003. – 204 str. : ilustr.

2. Archibald R. Modeli životnog ciklusa visokotehnoloških projekata. http://www.pmprofy.ru/content/rus/107/1073-article.html

3. Brooks F. Mitski čovjek-mjesec ili kako nastaju programski sustavi. – Sankt Peterburg. : Simbol-plus, 1999. – 321 str. : ilustr.

4. Butch G. Objektno orijentirani dizajn s primjerima primjene. – M.: Concord, 1992. – 586 str. : ilustr.

5. Butch G. Objektno orijentirana analiza i objektno orijentirani dizajn u C++. – M.: Binom, – 2001. – 558 str. : ilustr.

6. Vendrov A. M. CASE tehnologije. Suvremene metode i alati za projektiranje informacijskih sustava. – M.: Financije i statistika, – 1999. – 256 str. : ilustr.

7. Wirth N. Algoritmi + strukture podataka = programi: Transl. s engleskog – M.: Mir, 1985. – 406 str.: ilustr.

8. Dahl O., Dijkstra E., Hoor K. Strukturirano programiranje: Prijevod. s engleskog – M.: Mir, 1975. – 247 str. : ilustr.

9. Dzerzhinsky F.Ya., Kalinichenko I.M. Disciplina programiranja: koncept i iskustvo u implementaciji metodoloških alata programskog inženjerstva. – M.: Središnji istraživački institut za informacijska i tehnička i ekonomska istraživanja u nuklearnoj znanosti i tehnologiji, 1988. – 245 str. : ilustr.

10. Zhogolev E. A. Tehnologije programiranja. – M.: Znanstveni svijet, 2004. – 216 str. : ilustr.

11. Zakon Ruske Federacije br. 149-FZ od 29. srpnja 2006. „O informacijama informacijske tehnologije i zaštita informacija”// Rossiyskaya Gazeta, broj 165 od 27. srpnja 2006.

12. Ivanova G. S. Tehnologija programiranja: Udžbenik za sveučilišta. – 2. izd., stereotip. – M.: Izdavačka kuća MSTU im. N.E. Bauman, 2003. – 320 str.: ilustr.

13. Kalyanov G. N. CASE: Strukturna analiza sustava (automatizacija i primjena). – M.: “Lori”, 1996. – 356 str. : ilustr.

14. Korablin M. A. Objektno orijentirano programiranje: Udžbenik. – Samara: Izdavačka kuća SSAU, 1994. – 94 str.

15. Leonenkov A.V. Priručnik za samoučenje UML. – Sankt Peterburg: VHV Sankt Peterburg, – 2001. – 304 str. : ilustr.

16. Lipaev V.V. Kvaliteta softvera. – M.: Financije i statistika, 1983. – 263 str. : ilustr.

17. Lipaev V.V. Otklanjanje pogrešaka složeni programi: Metode, sredstva, tehnologija. –M. : Energoatomizdat, 1993. – 384 str. : ilustr.

18. Lipaev V.V., Filippov E.N. Mobilnost programa i podataka na otvorenom informacijski sustavi. – M.: Znanstvena knjiga, 1997. – 297 str. : ilustr.

20. Ozhegov S.I. Rječnik ruskog jezika. – M.: Mir i obrazovanje, 2006. – 1328 str.

21. Tehnologija projektiranja programskih kompleksa sustava automatiziranog upravljanja / V. V. Lipaev, L. A. Serebrovsky, P. G. Gaganov i dr.; ur. Yu. V. Afanasyeva, V. V. Lipaeva. – M.: Radio i veze, 1983. – 256 str. : ilustr.

22. Hyvenen E., Seppanen J. Svijet LISP-a: Prijevod. iz finskog U 2 sveska T.1: Uvod u jezik Lisp i funkcionalno programiranje.– M.: Mir, 1990. – 447 str. : ilustr.

23. Hyvenen E., Seppanen J. Svijet LISP-a: Prijevod. iz finskog U 2 sveska. T.2: Metode i sustavi programiranja – M.: Mir, 1990. – 319 str. : ilustr.

24. Boehm B. “Spiralni model razvoja i poboljšanja softvera,” IEEE Computer, sv. 21, br. 5, str. 61–72, 1988.

25. Courtois P. lipnja 1985. O vremenskoj i prostornoj dekompoziciji složenih struktura. Priopćenja ACM-a vol.28(6), str.596.

26. Kriteriji za ocjenu softvera. ISO TC97/SC7 #383.

27. Dijktra E. 1979. Programiranje kao ljudska aktivnost. Klasici u softverskom inženjerstvu. New York, NY: Yourdon Press.

28. http://www.pmi.ru/glossary/.

29. http://www.staratel.com/iso/InfTech/DesignPO/ISO12207/ISO12207-99/ISO12207.htm.

30. Microsoft Corporation. Načela dizajna i razvoja softvera. Tečaj obuke MCSD: Prijevod s engleskog – M.: Izdavačka i trgovačka kuća “Rusko izdanje”, 2000. –608 str. : ilustr.

31. Parnas D., Clements P., Weiss D. 1983. Poboljšanje mogućnosti ponovne upotrebe sa skrivanjem informacija. Zbornik radova Radionice o ponovnoj upotrebi u programiranju. Stratford, CT: ITT programiranje. str.241.

32. Rechtin E. listopad 1992. Umijeće projektiranja sustava. IEEE Spektar, vol.29(10), str.66.

33. Royce W.W. Upravljanje razvojem velikih softverskih sustava. http://facweb.cti.depaul.edu/jhuang/is553/Royce.pdf.

34. Shaw M. Listopad 1984. Tehnike apstrakcije u modernim programskim jezicima. IEEE softver vol.1(4).

35. Simon H. 1982. Znanosti o umjetnom. Cambridge, MA: The MIT Press. – str.218.

36. Sommerville I. Programsko inženjerstvo. – Addison-Wesley Publishing Company, 1992. str.87.

37. Tesler L. kolovoz 1981. The Smalltalk Environment. Bajt vol.6(8), str.142.

38. Yonezawa A., Tokoro M. 1987. Objektno orijentirano paralelno programiranje. Cambridge, MA: The MIT Press.


popis pojmova


Izbor metoda razvoja aplikacije postaje zadatak broj 1 u uvjetima brz rast tržište. Prema studiji 310 milijardi američkih dolara potrošeno je na poslovni softver diljem svijeta u 2015. Razvoj konceptaRAD (Rapid Application Development)postao temelj za stvaranje fleksibilnog, adaptivni sustav razvoj aplikacija, što bi bila protuteža modelu krutog “vodopada”.

RAD je model brzog razvoja aplikacija koji se fokusira na brzinu i jednostavnost programiranja.

Pojava RAD

Pojavu brzog razvoja aplikacija možemo zahvaliti nesavršenosti obiteljskog modela Slap prilikom izrade softvera. Stvar je u tome što se u početku razvojni sustav vodopada temeljio na tradicionalnom korištenom inženjerskom modelu za projektiranje i građenje zgrada i mostova.

Dok se Waterfall temeljio na krutoj strukturi sekvencijalnih razvojnih aktivnosti, pojava RAD-a bila je pokušaj stvaranja fleksibilnog procesa koji bi mogao koristiti znanje stečeno tijekom životnog ciklusa projekta.

Prvu verziju RAD-a stvorio je Barry Boehm 1986., koji ju je nazvao "spiralni model". Svaki zavoj spirale podijeljen je u 4 sektora i odgovara razvoju fragmenta ili verzije softvera. Svakim novim zaokretom dolazi do produbljivanja i pojašnjavanja ciljeva i specifikacija projekta. Kao rezultat toga, postaje moguće odabrati informiranu opciju.

Koristeći Barryjeve ideje, Britanac James Martin razvio je svoj RAD sustav dok je 1980-ih radio u IBM-u, a konačno ih je formulirao u “Rapid Application Development” 1991.

Istina, postoji određena zabuna oko značenja riječi "RAD" čak i među IT stručnjacima. Uostalom, govorili smo o dva pojma: RAD kao učinkovita alternativa Waterfall-u I RAD kao specifičnu metodu koju je razvio Martin. Potonji je prilagođen poslovnim sustavima s intenzivnim korisničkim sučeljem.

Kasnije su se ideje razvijale i unapređivale Pioniri RAD-a James Kerr i Richard Hunter u suradnji "Inside RAD", koja je opisala putovanje voditelja projekta dok je učio i implementirao metodologiju brzog razvoja aplikacija u stvarnom životu za pravi projekt.

Spiralni model je proces razvoja softvera koji kombinira dizajn i fazu po fazu izrade prototipova.

Osnove (principi) brzog razvoja aplikacija

RAD principi usmjereni su na pružanje temeljnih prednosti brzog razvoja aplikacija:

  • povećana brzina razvoja
  • niske cijene
  • visoke kvalitete.

S zadnja točka Najviše problema nastaje jer programer i kupac različito vide predmet razvoja.

Kako bi uklonili ovaj i druge probleme, James Martin i njegovi sljedbenici identificirali su sljedeća RAD načela:

  • minimiziranje vremenskih troškova— skup alata trebao bi biti usmjeren na smanjenje vremena razvoja
  • izrada prototipova— izrada prototipova za specificiranje zahtjeva kupaca
  • ciklički razvoj— svaka nova verzija proizvoda temelji se na procjeni rezultata rada prethodna verzija kupac
  • suradnja— razvojni tim mora blisko surađivati ​​jedni s drugima, svaki član mora biti spreman obavljati višestruke odgovornosti
  • iterativni pristup na razvoj
  • kombinacijatestiranje i razvoj sustava.

RAD principi se koriste ne samo tijekom implementacije, već se protežu na sve faze životnog ciklusa, posebno na fazu organizacijskog pregleda, konstrukcije zahtjeva, analize i dizajna.

Životni ciklus softvera prema RAD-u

Tijekom RAD procesa aplikacija prolazi kroz četiri faze.

Analiza zahtjeva i faza planiranja

Utvrđuju se zahtjevi, funkcije aplikacije i njihov prioritet, opisuju se potrebe za informacijama. Fazu primarno provode korisnici uz sudjelovanje programera. U ovoj fazi također su naznačeni opseg projekta, vremenski i financijski okvir te platforme za pokretanje softvera.

, tvrtka Beverly Flowers treba aplikaciju za online naručivanje cvijeća na vaš dom. Vrijeme izrade je 50 dana, budžet je 3000 dolara.

Faza projektiranja

Neki korisnici sudjeluju u tehničkom dizajnu sustava pod vodstvom programera. RAD grupe ili podskupine u ovoj fazi obično koriste kombinaciju tehnikaS Kolaborativni razvoj aplikacija (JAD) I CASE alati prevesti potrebe korisnika u radne modele.

JAD (Joint Application Development) je koncept zajedničkog razvoja aplikacija, unutar kojeg postoji bliska interakcija između naručitelja i izvođača za maksimalnu učinkovito rješenje pitanja vezana uz softver koji se razvija.
Case je skup alata i metoda za dizajn softvera kako bi se osigurali visokokvalitetni softverski proizvodi bez grešaka i jednostavni za održavanje.

Tijekom faze projektiranja korisnici mogu razumjeti, modificirati i definirati radni model sustava koji odgovara njihovim potrebama. Svaki proces se detaljno razmatra i, ako je potrebno, kreiradjelomični prototip .

Kao rezultat toga, stvaraju se faze:

  • opći informacijski model aplikacije
  • funkcionalni modeli sustava i podsustava
  • radni prototipovi ekrana, izvješća i dijaloga.

Ako alati za razvoj prototipa nisu bili primjereni u prethodnim modelima stvarne primjene, i tada se više nisu koristili u RAD-u svaki prototip postaje dio budućeg sustava.

Dakle, u aplikaciji Beverly Flowers korisnici bi trebali imati pristup sljedećim opcijama: “Home Page”, “Flower Search”, “View Flower List”.

Kao razvojna platforma odabran je besplatni program SpringToolSuite za koji je dostupan velik broj uzoraka - napisanih dijelova koda.
Kao poslužitelj - Apache Tomcat 6.0.

Faza izgradnje

U ovoj fazi dolazi do trenutnog brzog razvoja na temelju rezultata dobivenih u prethodnim fazama. Istovremenokorisnici nastavljaju sudjelovati u razvoju sustava, sugerirajući promjene i poboljšanja aplikacije. Testiranje aplikacije također se odvija tijekom razvoja.

Aplikacija "Beverly Flowers" sastavljena je od tri funkcionalne komponente - prijelaz korisnika na " Početna stranica", "Pregledaj boje" i "Prikaži popis boja".
Za razvoj radni model bio je potreban 1 specijalist i 8 dana.

Faza implementacije

Pokriva obuku korisnika, testiranje i zamjena stari sustav za novi. Priprema za ovu fazu počinje fazom projektiranja.

Prethodno je Beverly Flowers primao narudžbe izravno na prodajnim mjestima i putem telefona.

Snimanjem poruke o mogućnosti naručivanja putem posebna primjena a postavljanjem informativnih štandova na prodajnim mjestima, u 2 tjedna uspjeli smo neke kupce prebaciti na novi kanal prodajni

Istodobno se proporcionalno smanjio udio telefonskih narudžbi, što znači da je bilo moguće smanjiti osoblje voditelja službe za korisnike.

Vrijedno je napomenuti da, za razliku od vodopada, životni ciklus projekta prema RAD metodologiji nije krut. Ovisno o startnim uvjetima može se smanjiti broj faza, kao i njihovo punjenje.

Za i protiv brzog razvoja aplikacija u vašoj tvrtki

Hoće li koristiti Rapid Application Development ili ne uvelike ovisi o početnim uvjetima, zahtjevima kupaca i vrsti aplikacije.

Jasne prednosti RAD-a uključuju:

  1. visoke kvalitete. Korisnička interakcija s prototipovima poboljšava funkcionalnost projekata brzog razvoja aplikacija. Takav softver može bolje zadovoljiti potrebe kupca (krajnjeg korisnika) od korištenja Agile/Waterfall metodologija.
  2. kontrola rizika- unatoč činjenici da lavlji udio materijali o RAD-u fokusirani su na ubrzati I uključenost korisnici kao ključne značajke modela, ne može se isključiti treća važna prednost — smanjenje rizika. Zanimljivo, Boehm, koji je stvorio prvu verziju RAD-a, opisao je spiralni model kao model temeljen na riziku.
    Korištenje brzog razvoja aplikacija omogućuje vam da se usredotočite na glavne čimbenike rizika i prilagodite im se u ranoj fazi.
  3. Više projekata je dovršeno po jedinici vremena unutar proračuna- budući da RAD podrazumijeva model inkrementalnog razvoja, šanse za kritične pogreške, koji se često događaju u velikim vodopadnim projektima, smanjeni su.
    Ako je u projektima vodopadnog sustava implementacija projekta bila moguća nakon šest ili više mjeseci analize i razvoja, onda se u RAD-u sve potrebne informacije otkrivaju ranije, tijekom procesa izrade same aplikacije.
Model inkrementalnog razvoja je format razvoja softvera koji uključuje podjelu proizvoda na relativno neovisne komponente. Potonji se razvijaju i puštaju u rad zasebno.

Nije bez svojih nedostataka.

Nedostaci brzog razvoja aplikacija uključuju:

  1. rizik od "novosti"— za većinu IT tvrtki RAD je bio novi proizvod koji je zahtijevao preispitivanje uobičajenih metoda rada. Otpor prema novim stvarima i potreba za učenjem alata i tehnika od nule dovodi do pogrešaka tijekom prvih implementacija brzog razvoja aplikacija.
  2. ako korisnici nisu u mogućnosti kontinuirano sudjelovati u procesu razvoja tijekom cijelog životnog ciklusa, to može negativno utjecati na finalni proizvod - značajka RAD-a je povećana interakcija između korisnika i programera, za razliku od Waterfall modela u kojima je uloga korisnika svedena na definiranje zahtjeva . Zatim programeri sami stvaraju sustav.
  3. smanjena kontrola— fleksibilnost, prilagodljivost procesa kao jedna od prednosti RAD-a idealno znači sposobnost brze prilagodbe i problemima i prilikama.
    Nažalost, morat ćete dati prednost jednoj stvari - fleksibilnosti ili kontroli. U potonjem slučaju, metodologija brzog razvoja aplikacija neće biti održiva.
  4. oskudan dizajn- fokusiranje na prototipove u nekim slučajevima dovodi do metodologije "hack and test", u kojoj programeri neprestano unoseći male promjene V pojedinačni elementi i ignorirati probleme arhitekture sustava.
  5. nedostatak skalabilnosti— RAD prvenstveno koriste mali i srednji projektni timovi. Nedostaci metodologije brzog razvoja aplikacija posebno dolaze do izražaja pri korištenju brzog razvoja aplikacija u radu na velikim projektima.


RAD metodologija je prikladna za vaš projekt ako:

  • važna mu je brzina i lakoća razvoja
  • jasno definiran prioritetna područja razvoj projekta
  • Aplikaciju je potrebno izraditi u kratkom vremenu
  • projekt se provodi u ograničenom proračunu
  • glavni kriterij je korisničko sučelje
  • Projekt je moguće rastaviti na funkcionalne komponente.

Metodologija brzog razvoja aplikacija neće odgovarati vašem projektu ako:

  • važni su mu kvaliteta i kontrola
  • govorimo o stvaranju projekt velikih razmjera- pretpostavljeno maksimalno vrijeme vrijeme razvoja aplikacije je 60-90 dana, a kod pisanja stotina tisuća linija programskog koda gotovo je nemoguće ispoštovati takvo ograničenje
  • ključna za provedbu je visoka razina planiranja i stroga dizajnerska disciplina, strogo pridržavanje unaprijed razvijenih protokola i sučelja
  • Sigurnost ljudi u određenoj mjeri ovisi o primjeni.

Presuda

Koncept brzog razvoja aplikacija (skraćeno RAD za Rapid Application Development) vrsta je inkrementalnih modela razvoja softvera.

Ključni parametri na kojima radi RAD su:
brzina i jednostavnost programiranja.

Metodologija će postati odličan izbor za provedbu mali projekti s ograničenim proračunom, koje treba razvijati u kratkom vremenu. Za velike sustave, sa visoke zahtjeve Za kontrolu i planiranje bolje je odabrati druge modele razvoja softvera.

Rapid Application Development (RAD) životni je ciklus procesa dizajna osmišljen da postigne više velika brzina razvoj i kvalitetu softvera nego što je to moguće tradicionalnim pristupom dizajnu.

Koncept RAD bio je odgovor na metode razvoja softvera iz 1970-ih i ranih 1980-ih, kao što je "vodopadni model". Te su metode uključivale tako spor proces stvaranja programa da su se često čak i zahtjevi za program imali vremena promijeniti prije kraja razvoja. Osnivačem RAD-a smatra se zaposlenik IBM-a James Martin, koji je osamdesetih godina prošlog stoljeća formulirao temeljna načela RAD-a, temeljena na idejama Barryja Boyma i Scotta Schultza. A 1991. godine Martin je objavio poznatu knjigu u kojoj je detaljno opisao koncept RAD-a i mogućnosti njegove primjene. Trenutno RAD postaje općeprihvaćena shema za izradu alata za razvoj softvera.

RAD pretpostavlja da razvoj softvera provodi mali tim programera u razdoblju od otprilike tri do četiri, koristeći vizualno modeliranje i razvojne alate. RAD tehnologija pruža aktivno uključivanje kupac već u ranim fazama - istraživanje organizacije, razvoj zahtjeva sustava. RAD metodologija jedan je od pristupa razvoju softvera unutar spiralnog modela životnog ciklusa.

Životni ciklus softvera prema RAD metodologiji sastoji se od četiri faze:

analiza zahtjeva i faza planiranja;

faza projektiranja;

faza izgradnje;

faza implementacije.

U fazi analize zahtjeva i planiranja korisnici izvode sljedeće radnje:

određivanje funkcija koje bi sustav trebao obavljati;

isticanje funkcija najvišeg prioriteta koje je potrebno prvo razraditi;

opis potreba za informacijama.

Formuliranje zahtjeva sustava uglavnom provode korisnici pod vodstvom specijaliziranih programera. Osim toga, u ovoj fazi rješavaju se sljedeći zadaci:

opseg projekta je ograničen;

utvrđuju se vremenski okviri za svaku od sljedećih faza;

utvrđuje se sama mogućnost realizacije projekta u okviru zadanih iznosa financiranja korištenjem postojeće hardverske opreme itd. Rezultat faze trebao bi biti:

popis prioritetnih funkcija budućeg softvera IS;

preliminarni softverski modeli.

U fazi projektiranja, neki korisnici sudjeluju u tehničkom dizajnu sustava pod vodstvom specijaliziranih programera. Za brzo dobivanje radnih prototipova aplikacija koriste se odgovarajući alati (CASE alati). Korisnici, u izravnoj interakciji s programerima, pojašnjavaju i dopunjuju zahtjeve sustava koji nisu identificirani u prethodnoj fazi. U ovoj fazi izvode se sljedeće radnje:

procesi sustava se detaljnije ispituju;

po potrebi se izrađuje djelomični prototip za svaki elementarni proces (zaslonska forma, dijalog, izvješće, otklanjanje nejasnoća ili dvosmislenosti);

utvrđuju se zahtjevi za ograničenje pristupa podacima;

utvrđuje se sastav potrebne dokumentacije.

Projekt se zatim distribuira različitim razvojnim timovima. U slučaju korištenja CASE alata, to znači podjelu funkcionalnog modela sustava (dijagrami protoka podataka za strukturirani pristup ili dijagrami slučaja upotrebe za objektno orijentirani pristup). Rezultat ove faze trebao bi biti:

opći informacijski model sustava;

funkcionalni modeli sustava u cjelini i podsustava implementirani od strane pojedinih razvojnih timova;

precizno definirana sučelja između autonomno razvijenih podsustava;

izgrađeni prototipovi ekranskih obrazaca, izvješća, dijaloga.

Svi modeli i prototipovi moraju biti dobiveni pomoću onih CASE alata koji će se koristiti u budućnosti pri izgradnji sustava. Ovaj zahtjev je zbog potrebe da se izbjegne nekontrolirano iskrivljavanje podataka prilikom prijenosa informacija o projektu iz faze u fazu.

U fazi implementacije provodi se brzi razvoj aplikacije:

Programeri iterativno grade stvarni sustav na temelju modela dobivenih u prethodnoj fazi, kao i nefunkcionalnih zahtjeva (zahtjeva pouzdanosti, zahtjeva performansi itd.).

Korisnici ocjenjuju dobivene rezultate i vrše prilagodbe ako tijekom procesa razvoja sustav više ne zadovoljava prethodno definirane zahtjeve. Testiranje sustava provodi se tijekom procesa razvoja.

Nakon završetka rada svakog pojedinog razvojnog tima, provodi se postupna integracija ovog dijela sustava s ostalima, generira se kompletan programski kod, testira se zajednički rad ovog dijela aplikacije, a zatim se sustav kao ispituje se cjelina. Implementacija sustava je završena izvođenjem sljedećih radova:

analizira se korištenje podataka i utvrđuje potreba njihove distribucije;

provodi se fizički dizajn baze podataka;

formulirani su zahtjevi za hardverskim resursima;

utvrđeni su načini povećanja produktivnosti;

U tijeku je izrada projektne dokumentacije. Rezultat etape je gotov sustav koji zadovoljava sve dogovorene zahtjeve.

U fazi implementacije provodi se obuka korisnika i organizacijske promjene.

Korištenje RAD tehnologije preporučljivo je kada:

projekt se mora završiti u kratkom roku (90 dana);

softverski zahtjevi nisu jasno definirani;

projekt se provodi u okviru proračunskih ograničenja;

korisničko sučelje (GUI) je glavni faktor;

projekt je velik, ali se može podijeliti na manje funkcionalne komponente;

Softver nema visoku računsku složenost.

RAD tehnologija nije univerzalna, odnosno njena upotreba nije uvijek preporučljiva. Na primjer, u projektima gdje su zahtjevi za softverski proizvod su jasno definirani i ne bi se trebali mijenjati, nije potrebno uključivanje korisnika u razvojni proces, a hijerarhijski razvoj (kaskadna metoda) može biti učinkovitiji. Isto se odnosi i na projekte, softver čija je složenost određena potrebom implementacije složeni algoritmi, te ulogu i volumen korisničko sučelje mali.

Slika 1 - Usporedba RAD i Cascade metode



POVEZANI ČLANCI