Üheks võimalikuks lähenemiseks tarkvaraarendusele spiraalse elutsükli mudeli raames on viimasel ajal laialt levinud RAD (Rapid Application Development) metoodika. See termin viitab tavaliselt tarkvaraarendusprotsessile, mis sisaldab kolme elementi:

väike programmeerijate meeskond (2-10 inimest);

lühike, kuid hoolikalt läbi töötatud tootmisgraafik (2 kuni 6 kuud);

korduv tsükkel, mille käigus arendajad, kui rakendus hakkab kuju võtma, taotlevad ja juurutavad tootesse kliendiga suhtlemise kaudu saadud nõudeid.

Arendusmeeskond peaks koosnema professionaalidest, kellel on CASE-tööriistade abil analüüsi, disaini, koodi genereerimise ja tarkvara testimise kogemus. Samuti peavad meeskonnaliikmed suutma tõlkida lõppkasutajate soovitused töötavateks prototüüpideks.

Tarkvara elutsükkel RAD metoodika järgi koosneb neljast faasist:

nõuete analüüsi ja planeerimise etapp;

projekteerimise etapp;

ehitusetapp;

rakendamise etapp.

Nõuete analüüsi ja planeerimise etapis määravad süsteemi kasutajad kindlaks funktsioonid, mida see peab täitma, selgitavad välja esmatähtsad, mis nõuavad esmalt läbitöötamist, ning kirjeldavad teabevajadusi. Nõudeid määravad peamiselt kasutajad spetsialistide arendajate juhendamisel. Projekti ulatus on piiratud ja iga järgneva etapi ajaraam määratakse kindlaks. Lisaks määratakse selle projekti elluviimise võimalus kehtestatud rahastusraamistikus, antud riistvara kasutades jne. Selle etapi tulemuseks peaks olema tulevase IS-i funktsioonide loetelu ja prioriteet, IS-i esialgsed funktsionaalsed ja infomudelid.

Projekteerimisetapis osalevad mõned kasutajad spetsialistide arendajate juhendamisel süsteemi tehnilises projekteerimises. CASE-tööriistu kasutatakse rakenduste töötavate prototüüpide kiireks tootmiseks. Kasutajad, kes nendega vahetult suhtlevad, täpsustavad ja täiendavad süsteeminõudeid, mida eelmises etapis ei tuvastatud. Süsteemiprotsesse käsitletakse üksikasjalikumalt. Funktsionaalset mudelit analüüsitakse ja vajadusel korrigeeritakse. Iga protsessi käsitletakse üksikasjalikult. Vajadusel luuakse igale elementaarsele protsessile osaline prototüüp: ekraan, dialoog, aruanne, mis kõrvaldab ebaselgused või ebaselgused. Määratakse andmetele juurdepääsu piiramise nõuded. Samas etapis määratakse kindlaks vajalike dokumentide komplekt.

Pärast protsesside koostise üksikasjalikku määratlemist hinnatakse väljatöötatud süsteemi funktsionaalsete elementide arvu ja tehakse otsus jagada IS alamsüsteemideks, mida saab üks arendajate meeskond RAD-projektidele vastuvõetava aja jooksul rakendada - umbes 60-90 päeva. CASE tööriistu kasutades jaotatakse projekt erinevate meeskondade vahel (funktsionaalne mudel on jagatud). Selle etapi tulemused peaksid olema:

süsteemi üldinfomudel;

üksikute arendusmeeskondade poolt juurutatud süsteemi kui terviku ja alamsüsteemide funktsionaalsed mudelid;

täpselt määratletud liidesed autonoomselt arendatud allsüsteemide vahel, kasutades CASE tööriista;

ehitatud ekraanide, aruannete, dialoogide prototüübid.

Kõik mudelid ja prototüübid tuleb hankida nende CASE tööriistade abil, mida tulevikus süsteemi ehitamisel kasutatakse. See nõue tuleneb asjaolust, et traditsioonilise lähenemise korral võib projekti kohta teabe edastamisel etapist teise tekkida praktiliselt kontrollimatu andmete moonutamine. Ühtse keskkonna kasutamine projektiteabe salvestamiseks võimaldab seda ohtu vältida.

Erinevalt traditsioonilisest lähenemisviisist, mis kasutas spetsiifilisi prototüüpide loomise tööriistu, mis ei olnud mõeldud reaalsete rakenduste loomiseks, ja prototüüpide kasutusest kõrvaldamine pärast seda, kui need olid täitnud disaini ebaselguste kõrvaldamise, muudab RAD-lähenemine iga prototüübi tulevase süsteemi osaks. Seega läheb täielikum ja kasulikum info üle järgmisse faasi.

Ehitusetapp on see, kus toimub kiire rakenduste arendamine. Selles etapis loovad arendajad iteratiivselt reaalse süsteemi, mis põhineb eelmises etapis saadud mudelitel ja mittefunktsionaalsetel nõuetel. Programmi kood genereeritakse osaliselt automaatsete generaatorite abil, mis saavad teavet otse CASE tööriista hoidlast. Selles etapis hindavad lõppkasutajad saadud tulemusi ja teevad muudatusi, kui arendusprotsessi käigus süsteem ei vasta enam eelnevalt määratletud nõuetele. Süsteemi testimine toimub otse arendusprotsessi käigus.

Pärast iga individuaalse arendusmeeskonna töö lõpetamist viiakse läbi selle süsteemi osa järkjärguline integreerimine ülejäänud osaga, genereeritakse täielik programmikood, testitakse selle rakenduse osa ühist toimimist ülejäänud osaga ja seejärel testitakse süsteemi tervikuna. Süsteemi füüsiline projekteerimine on lõpetatud:

määratakse andmete levitamise vajadus;

teostatakse andmete kasutamise analüüs;

teostatakse andmebaasi füüsiline projekteerimine;

määratakse kindlaks nõuded riistvararessurssidele;

määratakse kindlaks viisid tootlikkuse suurendamiseks;

Lõpetamisel on projekti dokumentatsiooni väljatöötamine.

Etapi tulemuseks on valmis süsteem, mis vastab kõigile kokkulepitud nõuetele.

Juurutamisetapis viiakse läbi kasutajakoolitusi, organisatsioonilisi muudatusi ning paralleelselt uue süsteemi juurutamisega töötatakse olemasoleva süsteemiga (kuni uue täieliku juurutamiseni). Kuna ehitusetapp on üsna lühike, tuleb planeerimist ja juurutamise ettevalmistamist alustada varakult, tavaliselt süsteemi projekteerimisetapis. Antud IS-i arendusskeem ei ole absoluutne. Võimalikud on mitmesugused variandid, olenevalt näiteks algtingimustest, milles arendust teostatakse: töötatakse välja täiesti uus süsteem; ettevõttes on küsitlus juba läbi viidud ja selle tegevuse mudel olemas; Ettevõttel on juba mõni IP, mida saab kasutada esialgse prototüübina või mis tuleb integreerida arendatavaga.

Tuleb aga märkida, et RAD-metoodika, nagu ükski teine, ei saa väita, et see on universaalne, see on hea eelkõige konkreetse kliendi jaoks välja töötatud suhteliselt väikeste projektide jaoks. Kui töötatakse välja standardsüsteem, mis ei ole valmistoode, vaid on standardsete komponentide kompleks, mis on tsentraalselt hooldatud, kohandatav tarkvara- ja riistvaraplatvormidele, DBMS-i, telekommunikatsiooni, rakendusobjektide organisatsiooniliste ja majanduslike omadustega ning integreeritud olemasolevate arendustega, esiplaanile tulevad projektinäitajad nagu juhitavus ja kvaliteet, mis võivad minna vastuollu arenduse lihtsuse ja kiirusega. Sellised projektid nõuavad kõrget planeerimist ja ranget disainidistsipliini, eelnevalt väljatöötatud protokollide ja liideste ranget järgimist, mis vähendab arenduskiirust.

RAD metoodika ei ole rakendatav keerukate arvutusprogrammide, operatsioonisüsteemide ega kosmoseaparaadi juhtimisprogrammide ehitamisel, s.t. programmid, mis nõuavad suure hulga (sadu tuhandeid ridu) unikaalse koodi kirjutamist.

Ei sobi rakendused, millel puudub selgelt määratletud liidese osa, mis selgelt määratleb süsteemi loogika (näiteks reaalajas rakendused) ja rakendused, millest sõltub inimeste ohutus (näiteks lennuki või tuumajaama juhtimine). RAD-i metoodikat kasutava arenduse jaoks, kuna see on iteratiivne, eeldab lähenemisviis, et paar esimest versiooni ei ole tõenäoliselt täielikult funktsionaalsed, mis on antud juhul välistatud.

Rakenduste suurust hinnatakse nn funktsionaalsete elementide (ekraanid, sõnumid, aruanded, failid jne) põhjal. See mõõdik ei sõltu programmeerimiskeelest, milles arendust teostatakse. Rakenduse suurus, mida saab RAD-metoodikat kasutades käivitada, väljakujunenud IC-arenduskeskkonna jaoks, kus tarkvarakomponente kasutatakse maksimaalselt, määratakse järgmiselt:

Kokkuvõtteks loetleme RAD-i metoodika peamised põhimõtted:

rakenduste arendamine iteratsioonides;

töö täieliku lõpetamise valikulisus elutsükli igal etapil;

kasutajate kohustuslik kaasamine IS arendusprotsessi;

CASE tööriistade vajalik kasutamine projekti terviklikkuse tagamiseks;

konfiguratsioonihaldusvahendite kasutamine, mis hõlbustavad projektis muudatuste tegemist ja valmis süsteemi hooldamist;

koodigeneraatorite vajalik kasutamine;

prototüüpide kasutamine lõppkasutaja vajaduste paremaks mõistmiseks ja rahuldamiseks;

projekti testimine ja arendus, mis viiakse läbi arendusega samaaegselt;

arendust väikese, hästi juhitud professionaalide meeskonna poolt;

süsteemiarenduse kompetentne juhtimine, selge planeerimine ja tööde teostamise kontroll.

Rakenduste arendusmeetodite valimine muutub kiire turukasvu kontekstis ülesandeks nr 1. Uuringu kohaselt 2015. aastal kulutati kogu maailmas ettevõttetarkvarale 310 miljardit USA dollarit. Kontseptsiooni arendamineRAD (Rapid Application Development)sai aluseks paindliku, kohanduva rakenduste arendussüsteemi loomisel, mis oleks vastukaaluks jäigale kosemudelile.

RAD on kiire rakenduste arendusmudel, mis keskendub kiirusele ja programmeerimise lihtsusele.

RADi tekkimine

Peremudeli ebatäiuslikkust võime tänada rakenduste kiire arendamise eest Kosk tarkvara loomisel. Asi on selles, et algselt põhines juga arendussüsteem kasutatud traditsioonilisel insenerimudelil hoonete ja sildade projekteerimiseks ja ehitamiseks.

Kui Waterfall põhines järjestikuste arendustegevuste jäigal struktuuril, siis RADi tekkimine oli katse luua paindlik protsess, mis saaks kasutada projekti elutsükli jooksul omandatud teadmisi.

RAD-i esimese versiooni lõi 1986. aastal Barry Boehm, kes nimetas seda "spiraalmudeliks". Iga spiraali pööre on jagatud 4 sektoriks ja vastab fragmendi või tarkvaraversiooni arendamisele. Iga uue pöördega süvenetakse ja täpsustatakse projekti eesmärke ja spetsifikatsioone. Selle tulemusena on võimalik valida teadlik valik.

Kasutades Barry ideid, Britt James Martin töötas välja oma RAD-süsteemi 1980ndatel IBMis töötades ja lõpuks sõnastas need 1991. aastal rakenduste kiireks arendamiseks.

Tõsi, sõna “RAD” tähenduse osas on segadust isegi IT-spetsialistide seas. Lõppude lõpuks rääkisime kahest kontseptsioonist: RAD kui tõhus alternatiiv Waterfallile Ja RAD kui Martini välja töötatud spetsiifiline meetod. Viimane on kohandatud UI-mahukatele ärisüsteemidele.

Seejärel ideid arendati ja täiustati RAD-i pioneerid James Kerr ja Richard Hunter koostöös "Inside RAD", mis kirjeldas projektijuhi teekonda, kui ta õppis ja rakendas reaalse projekti jaoks reaalset rakenduste kiirarendusmetoodikat.

Spiraalmudel on tarkvara arendusprotsess, mis ühendab disaini ja etapiviisilise prototüüpimise.

Rakenduste kiire arendamise põhitõed (põhimõtted).

RAD-i põhimõtted keskenduvad rakenduste kiire arendamise peamiste eeliste pakkumisele:

• suurenenud arengukiirus
• odav
• kõrge kvaliteet.

Viimane punkt on see, kus kõige rohkem probleeme tekib, sest arendaja ja tellija näevad arenduse teemat erinevalt.

Selle ja teiste probleemide kõrvaldamiseks tuvastasid James Martin ja tema järgijad järgmised RAD-i põhimõtted:

• ajakulude minimeerimine— tööriistakomplekt peaks olema suunatud arendusaja lühendamisele
• prototüüpimine— prototüüpide loomine kliendi nõudmiste täpsustamiseks
• tsükliline areng— iga toote uus versioon põhineb kliendi hinnangul eelmise versiooni tulemustele
• koostöö— arendusmeeskond peab omavahel tihedalt suhtlema, iga liige peab olema valmis täitma mitmeid kohustusi
• iteratiivne lähenemine arengule
• kombinatsioonsüsteemi testimine ja arendus.

RAD-i põhimõtteid ei kasutata mitte ainult juurutamisel, vaid need laienevad ka elutsükli kõikidele etappidele, eelkõige organisatsiooni uuringu, nõuete koostamise, analüüsi ja projekteerimise etapile.

Tarkvara elutsükkel vastavalt RAD-ile

RAD-protsessi käigus läbib rakendus neli faasi.

Nõuete analüüsi ja planeerimise etapp

Määratakse nõuded, rakendusfunktsioonid ja nende prioriteetsus, kirjeldatakse infovajadusi. Etapi viivad läbi peamiselt kasutajad arendajate osalusel. Selles etapis näidatakse ka projekti ulatust, aja- ja finantsraamistikku ning tarkvara käivitamise platvorme.

, vajab ettevõte Beverly Flowers rakendust lillede veebist koju tellimiseks. Loomise aeg on 50 päeva, eelarve on 3000 dollarit.

Disaini faas

Osa kasutajaid osaleb süsteemi tehnilises projekteerimises arendajate juhendamisel. Selles faasis olevad RAD-rühmad või alamrühmad kasutavad tavaliselt tehnikate kombinatsiooniKoos Koostöörakenduste arendus (JAD) Ja CASE tööriistad muuta kasutajate vajadused toimivateks mudeliteks.

JAD (Joint Application Development) on ühisrakenduste arendamise kontseptsioon, mille raames toimub tihe suhtlus kliendi ja juurutajate vahel, et arendatava tarkvaraga seotud probleeme kõige tõhusamalt lahendada.

Case on tarkvara kujundamise tööriistade ja meetodite komplekt, et tagada kvaliteetsed, veatud ja hõlpsasti hooldatavad tarkvaratooted.

Disainifaasis saavad kasutajad mõista, muuta ja määratleda nende vajadustele vastava süsteemi töömudeli. Iga protsessi käsitletakse üksikasjalikult ja vajadusel luuakseosaline prototüüp .

Selle tulemusena luuakse faasid:

• rakenduse üldteabe mudel
• süsteemi ja alamsüsteemide funktsionaalsed mudelid
• ekraanide, aruannete ja dialoogide töötavad prototüübid.

Kui varasemates mudelites ei vastanud prototüüpide arendustööriistad reaalsetele rakendustele ja neid ei kasutatud ka edaspidi, siis RAD-is saab iga prototüüp tulevase süsteemi osaks.

Seega peaks Beverly Flowersi rakenduses kasutajatel olema juurdepääs järgmistele valikutele: "Koduleht", "Lilleotsing", "Vaata lillenimekirja".

Arendusplatvormiks valiti vabavaraline SpringToolSuite, mille jaoks on saadaval suur hulk näidiseid – kirjutatud koodijuppe.
Serveri roll on Apache Tomcat 6.0.

Ehitusetapp

Selles etapis toimub eelmistes faasides saadud tulemuste põhjal kohene kiire areng. Kuskasutajad jätkavad osalemist süsteemi arendamisel, soovitades rakenduses muudatusi ja täiendusi. Rakenduste testimine toimub ka arenduse käigus.

Rakendus "Beverly Flowers" on kokku pandud kolmest funktsionaalsest komponendist - kasutaja avab "Avalehe", "Lilleotsingu" ja "Vaata lillenimekirja".
Töötava mudeli väljatöötamiseks kulus 1 spetsialist ja 8 päeva.

Rakendusfaas

Hõlmab kasutajate koolitust, testimist ja vana süsteemi asendamine uuega. Selle etapi ettevalmistamine algab projekteerimisetapiga.

Varem võttis Beverly Flowers tellimusi vastu otse müügipunktides ja telefoni teel.

Salvestades spetsiaalse rakenduse kaudu tellimise võimalusest sõnumi ja paigutades müügikohtadesse infostendid, õnnestus 2 nädalaga osa kliente uuele müügikanalile ümber lülitada.

Samal ajal vähenes proportsionaalselt telefonitellimuste osakaal, mis tähendab, et oli võimalik vähendada klienditeenindusjuhtide personali.

Väärib märkimist, et erinevalt Waterfallist ei ole projekti elutsükkel RAD metoodika järgi jäik. Sõltuvalt käivitustingimustest võib väheneda faaside arv ja ka nende täituvus.

Rakenduste kiire arendamise plussid ja miinused teie ettevõttes

Kas kasutada rakenduste kiirarendust või mitte, sõltub suuresti lähtetingimustest, kliendi nõudmistest ja rakenduse tüübist.

RAD-i selged eelised hõlmavad järgmist:

1. kõrge kvaliteet. Kasutaja interaktsioon prototüüpidega suurendab rakenduste kiirete arendusprojektide funktsionaalsust. Selline tarkvara võib paremini vastata kliendi (lõppkasutaja) vajadustele kui Agile/Waterfall metoodikate kasutamine.
2. riskikontroll- kuigi lõviosa RAD-i käsitlevad materjalid keskenduvad kiirust Ja kaasamine kasutajad mudeli põhiomadustena, ei saa välistada ka kolmandat olulist eelist — riski vähendamine. Huvitaval kombel kirjeldas RAD-i esimese versiooni loonud Boehm spiraalmudelit riskipõhisena.
   Rakenduste kiire arendamise kasutamine võimaldab keskenduda peamistele riskiteguritele ja nendega varakult kohaneda.
3. Ajaühikus valmib eelarve piires rohkem projekte- kuna RAD viitab inkrementaalse arengu mudel, väheneb suurte Waterfalli projektide puhul sageli ette tulevate kriitiliste vigade tõenäosus.
   Kui jugasüsteemi projektides oli projekti elluviimine võimalik pärast kuue või enama kuu analüüsi ja arendustööd, siis RAD-is selgub kogu vajalik info varem, rakenduse enda loomise käigus.

Inkrementaalne arendusmudel on tarkvaraarendusvorming, mis hõlmab toote jagamist suhteliselt sõltumatuteks komponentideks. Viimased töötatakse välja ja võetakse kasutusele eraldi.

Mitte ilma oma puudusteta.

Rakenduste kiire arendamise puudused hõlmavad järgmist:

1. "uudsuse" oht— enamiku IT-ettevõtete jaoks oli RAD uus toode, mis nõudis tavapäraste töömeetodite ümbermõtestamist. Vastupidavus uutele asjadele ning vajadus tööriistade ja tehnikate nullist selgeks õppida toovad kaasa vigu kiire rakenduste arendamise esimestel rakendustel.
2. kui kasutajad ei saa kogu elutsükli jooksul pidevalt arendusprotsessis osaleda, võib see lõpptoodet negatiivselt mõjutada – RAD-i eripäraks on suurem suhtlus kasutajate ja arendajate vahel, erinevalt Waterfall mudelitest, kus kasutajate roll on taandatud nõuete määratlemisele. . Järgmiseks loovad arendajad süsteemi ise.
3. vähenenud kontroll— paindlikkus, protsesside kohanemisvõime kui RADi üks eeliseid tähendab ideaalis võimet kiiresti kohaneda nii probleemide kui võimalustega.
   Kahjuks peate eelistama ühte asja - paindlikkust või kontrolli. Viimasel juhul ei ole kiire rakenduste arendamise metoodika elujõuline.
4. hõre disain- prototüüpidele keskendumine viib mõnel juhul häkkimise ja testimise metoodikani, milles arendajad pidevalt väikseid muudatusi tegemaüksikutesse elementidesse ja ignoreerida süsteemi arhitektuuri probleeme.
5. skaleeritavuse puudumine— RAD-i kasutavad peamiselt väikesed ja keskmise suurusega projektimeeskonnad. Rakenduste kiirarenduse metoodika puudused tulevad eriti esile rakenduste kiire arendamise kasutamisel suurte projektidega töötamisel.

RAD-metoodika sobib teie projekti jaoks, kui:

• tema jaoks on oluline arengu kiirus ja kergus
• projektide arendamise prioriteetsed valdkonnad on selgelt määratletud
• Rakendus tuleb välja töötada lühikese aja jooksul
• projekt viiakse ellu piiratud eelarvega
• peamiseks kriteeriumiks on kasutajaliides
• Projekti on võimalik jagada funktsionaalseteks komponentideks.

Rakenduse kiire arendamise metoodika ei sobi teie projektiga, kui:

• tema jaoks on oluline kvaliteet ja kontroll
• me räägime loomisest suuremahuline projekt— hinnanguline maksimaalne rakenduste arendusaeg on 60-90 päeva ja sadade tuhandete ridade programmikoodi kirjutamisel on sellisest piirangust peaaegu võimatu kinni pidada
• elluviimisel on ülioluline planeerimise kõrge tase ja range disainidistsipliin, eelnevalt väljatöötatud protokollide ja liideste range järgimine
• Inimeste ohutus sõltub teatud määral rakendusest.

Kohtuotsus

Rakenduste kiire arendamise kontseptsioon (lühendatult RAD tähendab Rapid Application Development) on teatud tüüpi tarkvaraarenduse mudelid.

Peamised parameetrid, millega RAD töötab, on:
programmeerimise kiirus ja lihtsus.

Metoodika on rakendamiseks suurepärane valik väikesed projektid piiratud eelarvega, mida tuleb arendada lühikese aja jooksul. Suuremahuliste kõrgete juhtimis- ja planeerimisnõuetega süsteemide jaoks on parem valida muud tarkvaraarendusmudelid.

Kiireloomuline tarkvaraarendus on tänapäevasel IT-turul hädasti vajalik. Tööstuse positsioon on selline, et ta peab üsna tõhusalt reageerima mis tahes sageli muutuvatele tingimustele. Kiiresti, kiiresti – need sõnad ei kao edukate arendajate sõnavarast. Rakendused peavad rahuldama praegust nõudlust, pakkudes funktsionaalsust, mida eile aimati, kuid täna on seda juba vaja – see on kiire tarkvaraarendus. Tarkvaraarendus on tänapäeval tunginud sõna otseses mõttes kõikidesse eluvaldkondadesse ja uued nõuded võivad ilmneda igast suunast. Tarkvara on tänapäeval:

• Kaasaegne juhtimine
• Kontroll
• Järelevalve

Kas kiireloomuline ei tähenda halba kvaliteeti?

Programmi väljatöötamine on töömahukas protsess, mis nõuab esitaja taset ja teadmisi. Traditsiooniliselt arvatakse, et kvaliteet eeldab pikka tsüklit. Aga kas see on tõesti nii? Kas tarkvara on võimalik kiiresti ja kiiresti välja töötada?

• Toote kiireks tootmiseks vajate kas hästi koordineeritud professionaalide meeskonda või individuaalset igakülgset töötajat. Loomulikult ei kehti see kõigi programmide kohta.
• Kvaliteedikontroll on kohustuslik protseduur. Kvaliteedikontrolli ja "vigade" püüdmist sellises protsessis nagu tarkvara loomine ei saa tootmisprotsessist välja jätta, isegi selle kiirendamiseks. See on professionaalselt koostatud programmi vajalik tingimus.
• Tagamaks, et kiireloomulisus lõpptoodet ei kahjustaks, vajame esinejaid, kes on pikka aega õppinud ja loonud oma tootmisprotsessi. Tõenäoliselt on selliste spetsialistide tarkvaraarendus tõesti kvaliteetne ja kiire.

Kõik, kes vajavad teostamist kiiresti, kiiresti ja professionaalselt, saavad juba täna tellida kiireloomulisi arendusteenuseid. Lahtiseks jääb küsimus: kust leida pädevaid spetsialiste programmide kiireloomuliseks loomiseks?

Otsige esinejaid.

Sarnaseid teenuseid pakuvad paljud tsiviilspetsialistid ja organisatsioonid. Neilt saate tellida kõike, loomulikult sõltuvad hinnad spetsialisti tasemest, tema nõudlusest ja ülesande keerukusest. Enamik kliente kasutab kolme peamist viisi.

• Stuudio arendus. Stuudiod eeldavad kvaliteetset töötlust, kuid kiireloomulisuse korral nõuavad nad väga-väga suuri lisatasusid. Saate neilt programmi tellida, kui klient on nõus need kulud tasuma.
• Vabakutselised. Vastuoluline teema. Saate säästa raha, kuid võite lõppeda tähtaja ületamisega ja väga keskpärase kvaliteediga.

Spetsialiseeritud platvormid, mis pakuvad mugavat platvormi tsiviilspetsialistidele tellimuste esitamiseks ja võistlemiseks. Need erinevad eelmisest valikust kiiruse, turvalisuse ja võimaluse poolest valida kõige konkurentsivõimelisem pakkumine. Parim teenustest on Yudu, mis võimaldab uurida iga spetsialisti tegelikku portfelli ja valida sobivaima variandi.

RAD tehnoloogia (Kiire Rakendus Areng) – on tehnoloogia prototüüpimisel ja graafilise kasutajaliidese kasutamisel põhinevate rakenduste kiireks loomiseks GUI (Graafiline Kasutaja Liides).

RAD-tehnoloogia ei suuda toetada keerukate toodete arendamist, mis sisaldavad palju fragmente, mille programmeerimine võtab aega üle kahe nädala. See tehnoloogia on rohkem keskendunud üsna lihtsa kohandatud tarkvara arendamisele kui tööstuslikule IC-disainile.

Peaaegu kõigi väikeste IC arendusprobleemide lahendused saavutatakse maailmas tuntud RAD-tehnoloogia abil. See seisneb 6-7-liikmelise nn RAD-grupi organiseerimises, kuhu kuuluvad juht, süsteemianalüütik ja 4-5 programmeerijat, kellele tehakse selged plaanid kogu projekti arendusperioodiks ajaraamiga 1-2 inimest. nädalaid.

Selle tehnoloogia aluseks on IP loomise spiraalmudel (joonis 6.1). Nagu jooniselt näha, kulgeb arendus spiraalselt, läbides korduvalt IP arenduse kõik 4 etappi.

Joonis 6.1 – RAD-tehnoloogial põhinev spiraaldisaini mudel

Analüüsi etapis kasutajad teevad järgmisi toiminguid:

määrata funktsioonid, mida süsteem peab täitma;

tõsta esile kõrgeima prioriteediga funktsioonid, mis nõuavad esmalt läbitöötamist;

kirjeldada infovajadusi. Süsteeminõuete sõnastamise teostavad peamiselt kasutajad spetsialistide arendajate juhendamisel. Lisaks lahendatakse selles etapis järgmised ülesanded:

projekti ulatus on piiratud;

iga järgneva etapi jaoks kehtestatakse ajaraamid;

määratakse projekti elluviimise võimalus etteantud rahastussummade piires, olemasoleva riistvara kasutamine jne. Etapi tulemus peaks olema:

tulevase IS-tarkvara prioriteetsete funktsioonide loetelu;

esialgsed tarkvaramudelid.

Projekteerimise etapis Mõned kasutajad osalevad süsteemi tehnilises projekteerimises spetsialistide arendajate juhendamisel. Rakenduste töötavate prototüüpide kiireks hankimiseks kasutatakse vastavaid tööriistu (CASE-tööriistu). Kasutajad, kes suhtlevad otseselt arendajatega, selgitavad ja täiendavad süsteeminõudeid, mida eelmises etapis ei tuvastatud. Selles etapis tehakse järgmised toimingud:

süsteemiprotsesse vaadeldakse üksikasjalikumalt;

vajadusel luuakse igale elementaarsele protsessile osaline prototüüp: ekraanivorm, dialoog, aruanne, mis kõrvaldab ebaselgused või ebaselgused;

kehtestatakse nõuded andmetele juurdepääsu piiramiseks;

määratakse vajaliku dokumentatsiooni koosseis.

Pärast protsesside koostise üksikasjalikku määratlemist hinnatakse arendatava süsteemi nn funktsioonipunktide arvu ja otsustatakse jagada IS alamsüsteemideks, mida saab üks arendajate meeskond vastuvõetava aja jooksul juurutada. RAD-projektidele (kuni 3 kuud).

Funktsioonipunkt - See mis tahes arendatava süsteemi element:

rakenduse sisendelement (sisenddokument või kuvar);

rakenduse väljundelement (aruanne, dokument, ekraanivorm);

päring (küsimus/vastus paar);

loogiline fail (rakenduses kasutatav andmekirjete kogum);

rakenduse liides (teisele rakendusele edastatud või sealt vastu võetud andmekirjete kogum).

Seejärel jagatakse projekt erinevate arendusmeeskondade vahel laiali. Suurte IS-i arendamise kogemus näitab, et töö efektiivsuse tõstmiseks on vaja projekt jagada eraldiseisvateks alamsüsteemideks, mis on andmete ja funktsioonide poolest nõrgalt seotud. Alamsüsteemide juurutamist peaksid teostama eraldi spetsialistide rühmad. Samal ajal on vaja tagada kogu projekti koordineerimine ja välistada iga projektirühma töötulemuste dubleerimine, mis võib tekkida ühiste andmete ja funktsioonide olemasolu tõttu.

CASE-tööriistade kasutamise puhul tähendab see süsteemi funktsionaalse mudeli jagamist (struktureeritud lähenemise puhul andmevoo diagrammid või objektorienteeritud lähenemise puhul kasutusjuhtude diagrammid.

Selle etapi tulemus peaks olema:

süsteemi üldinfomudel;

üksikute arendusmeeskondade poolt juurutatud süsteemi kui terviku ja alamsüsteemide funktsionaalsed mudelid;

täpselt määratletud liidesed autonoomselt arendatud allsüsteemide vahel;

ehitatud ekraanivormide, aruannete, dialoogide prototüübid.

Kõik mudelid ja prototüübid tuleb hankida nende CASE tööriistade abil, mida tulevikus süsteemi ehitamisel kasutatakse. See nõue tuleneb vajadusest vältida kontrollimatut andmete moonutamist projekti kohta käiva teabe edastamisel etapist teise.

Erinevalt varasemast lähenemisviisist, mis kasutas spetsiifilisi prototüüpide loomise tööriistu, mis ei olnud mõeldud reaalsete rakenduste ehitamiseks, ja prototüüpe, mis olid kasutusest kõrvaldatud pärast seda, kui need olid täitnud disaini ebaselguste kõrvaldamise, arendatakse RAD-i lähenemisviisis iga prototüüp tulevase süsteemi osaks. . Seega viiakse täielikum ja kasulikum teave üle järgmisse etappi.

Rakendamise etapis Rakenduse kiire arendus ise toimub otse:

arendajad ehitavad iteratiivselt reaalse süsteemi eelmises etapis saadud mudelite, aga ka mittefunktsionaalsete nõuete (töökindlusnõuded, jõudlusnõuded jne) põhjal;

kasutajad hindavad saadud tulemusi ja teevad kohandusi, kui arendusprotsessi käigus süsteem ei vasta enam eelnevalt määratletud nõuetele. Süsteemi testimine viiakse läbi arendusprotsessi käigus.

Pärast iga individuaalse arendusmeeskonna töö lõpetamist viiakse läbi selle süsteemi osa järkjärguline integreerimine ülejäänud osaga, genereeritakse täielik programmikood, testitakse rakenduse selle osa ühist toimimist ja seejärel süsteem testitakse tervikut. Süsteemi juurutamine viiakse lõpule järgmiste tööde tegemisega:

analüüsitakse andmete kasutamist ja selgitatakse välja nende levitamise vajadus;

teostatakse andmebaasi füüsiline projekteerimine;

sõnastatakse nõuded riistvararessurssidele;

luuakse võimalused tootlikkuse suurendamiseks;

Lõpetamisel on projekti dokumentatsiooni väljatöötamine.

Tarkvara tootearendus tunneb paljusid väärt metoodikaid – teisisõnu väljakujunenud parimaid praktikaid. Valik sõltub projekti spetsiifikast, eelarvesüsteemist, subjektiivsetest eelistustest ja isegi juhi temperamendist. Artiklis kirjeldatakse meetodeid, millega me Edisonis regulaarselt kokku puutume.

1. kose mudel (kaskaadmudel või kosk)

Üks vanemaid, hõlmab järjestikuste etappide läbimist, millest igaüks tuleb enne järgmise algust täielikult lõpetada. Waterfall mudel muudab projekti haldamise lihtsaks. Tänu jäikusele kulgeb arendus kiiresti, maksumus ja tähtaeg on ette määratud. Kuid see on kahe teraga mõõk. Kose mudel annab suurepäraseid tulemusi ainult projektides, millel on selgelt ja eelnevalt määratletud nõuded ja viisid nende rakendamiseks. Testimine algab alles pärast seda, kui arendus on lõppenud või peaaegu lõpetatud. Selle mudeli järgi ilma põhjendatud valikuta välja töötatud toodetel võib esineda puudusi (nõuete loetelu ei saa igal ajal korrigeerida), mis saavad teatavaks alles lõpus tänu tegevuste rangele järjestusele. Muudatuste tegemise hind on kõrge, kuna selle algatamiseks on vaja oodata, kuni kogu projekt on lõpetatud. Siiski kaaluvad püsikulud sageli üles lähenemisviisi puudused. Loomisprotsessi käigus ilmnenud puuduste parandamine on võimalik ning meie kogemuse kohaselt nõuab üks kuni kolm lisakokkulepet väikese tehnilise spetsifikatsiooniga lepingusse.

Kose mudelit kasutades lõime paljusid projekte nullist, sealhulgas ainult tehniliste kirjelduste väljatöötamise. Projektid, millest Habrel kirjutatakse: keskmine - röntgeni mikrotomograafia, väike - Windowsi teenuse automaatne värskendamine AWS-is.

Millal kasutada kose metoodikat?

• Ainult siis, kui nõuded on teada, arusaadavad ja fikseeritud. Vastuolulisi nõudeid ei ole.
• Nõutava kvalifikatsiooniga programmeerijate olemasoluga probleeme pole.
• Suhteliselt väikestes projektides.

2. "V-mudel"

Pärandas kaskaadmudelilt "samm-sammult" struktuuri. V-kujuline mudel on rakendatav süsteemidele, mille jaoks on eriti oluline katkematu töö. Näiteks rakendusprogrammid kliinikutes patsientide jälgimiseks, integreeritud tarkvara sõidukite avariiturvapatjade juhtimismehhanismide jaoks jne. Mudeli eripäraks on see, et see on suunatud juba projekteerimise algstaadiumis oleva toote põhjalikule kontrollimisele ja testimisele. Testimisetapp viiakse läbi samaaegselt vastava arendusetapiga, näiteks kirjutatakse kodeerimise käigus ühiktestid.

Meie V-metoodikal põhineva töö näiteks on Euroopa mobiilioperaatori mobiilirakendus, mis säästab reisil olles rändluskulusid. Projekt viiakse läbi selge spetsifikatsiooni järgi, kuid see sisaldab olulist testimisetappi: liidese mugavus, funktsionaalsus, koormus ja sealhulgas integratsioon, mis peaks kinnitama, et mitmed erinevate tootjate komponendid töötavad stabiilselt koos, raha ja laenude vargus on võimatu.

Millal V-mudelit kasutada?

• Kui toote põhjalik testimine on vajalik, siis V-mudel õigustab selle olemuslikku ideed: valideerimist ja kontrollimist.
• Väikestele ja keskmise suurusega projektidele, kus nõuded on selgelt määratletud ja fikseeritud.
• Vajaliku kvalifikatsiooniga inseneride, eriti testijate olemasolu tingimustes.

3. "Inkrementaalne mudel" (inkrementaalne mudel)

Inkrementmudelis on täielikud süsteeminõuded jagatud erinevatesse sõlmedesse. Terminoloogiat kasutatakse sageli tarkvara samm-sammult kokkupanemise kirjeldamiseks. Toimub mitu arendustsüklit ja koos moodustavad need mitme kose elutsükli. Tsükkel on jaotatud väiksemateks, hõlpsasti moodustatavateks mooduliteks. Iga moodul läbib nõuete määratlemise, kavandamise, kodeerimise, rakendamise ja testimise etapid. Arenguprotseduur vastavalt astmelisele mudelile hõlmab põhifunktsionaalsusega toote vabastamist esimeses suures etapis ja seejärel järjestikku uute funktsioonide, nn juurdekasvu, lisamist. Protsess jätkub kuni kogu süsteemi loomiseni.

Inkrementaalseid mudeleid kasutatakse juhul, kui üksikud muudatustaotlused on selged ning neid on lihtne vormistada ja rakendada. Oma projektides kasutasime seda DefView lugeja ja seejärel Vivaldi elektrooniliste raamatukogude võrgustiku loomiseks.

Näitena kirjeldame ühe juurdekasvu olemust. Vivaldi elektrooniliste raamatukogude võrk asendas DefView. DefView on ühendatud ühe dokumendiserveriga ja saab nüüd ühenduse luua paljudega. Selle asutuse asukohta, mis soovib oma sisu edastada kindlale sihtrühmale, paigaldatakse salvestusserver, mis pääseb otse dokumentidele juurde ja teisendab need nõutavasse vormingusse. Ilmunud on arhitektuuri juurelement - keskne Vivaldi server, mis toimib ühtse otsingumootorina kõigi erinevatesse asutustesse installitud salvestusserverite jaoks.

Millal kasutada inkrementaalset mudelit?

• Kui süsteemi põhinõuded on selgelt määratletud ja arusaadavad. Samal ajal võivad mõned detailid aja jooksul täpsustuda.
• Vajalik on toote varajane turule toomine.
• On mitmeid riskantseid omadusi või eesmärke.

4. „RAD-mudel” (kiire rakenduste arendusmudel või rakenduste kiire arendus)

RAD-mudel on teatud tüüpi inkrementaalne mudel. RAD-mudelis arendavad komponente või funktsioone paralleelselt mitmed kõrgelt kvalifitseeritud meeskonnad, näiteks mitmed miniprojektid. Ühe tsükli ajaraam on rangelt piiratud. Seejärel integreeritakse loodud moodulid üheks toimivaks prototüübiks. Sünergia võimaldab väga kiiresti midagi toimivat kliendile ülevaatamiseks esitada, et saada tagasisidet ja teha muudatusi.

Rakenduste kiire arendusmudel sisaldab järgmisi etappe:

• Äri modelleerimine: erinevate osakondade vaheliste infovoogude loendi määratlemine.
• Andmete modelleerimine: eelmises etapis kogutud teavet kasutatakse teabe ringlemiseks vajalike objektide ja muude olemite määramiseks.
• Protsessi modelleerimine: infovood seovad objekte arengueesmärkide saavutamiseks.
• Rakenduse koostamine: kasutab CAD-mudelite koodiks teisendamiseks automatiseeritud koostetööriistu.
• Testimine: testitakse uusi komponente ja liideseid.

Millal RAD-mudelit kasutatakse?

Saab kasutada ainult kõrgelt kvalifitseeritud ja kõrgelt spetsialiseerunud arhitektidega. Projekti eelarve on suur, et maksta nende spetsialistide eest koos valmis automatiseeritud montaažitööriistade maksumusega. RAD-mudelit saab valida kindlate teadmistega sihtettevõttest ja süsteemi kiireloomulise tootmise vajadusest 2-3 kuu jooksul.

5. “Agiilne mudel” (paindlik arendusmetoodika)

“Agiilse” arendusmetoodika puhul saab klient pärast iga iteratsiooni tulemust jälgida ja aru saada, kas see teda rahuldab või mitte. See on üks paindliku mudeli eeliseid. Selle miinusteks on asjaolu, et tulemuste konkreetsete sõnastuste puudumise tõttu on raske hinnata tööjõukulusid ja arendamiseks vajalikke kulusid. Extreme Programming (XP) on agiilse mudeli üks tuntumaid rakendusi praktikas.

See tüüp põhineb lühikestel igapäevastel koosolekutel – “Scrum” ja regulaarselt korduvatel koosolekutel (kord nädalas, kord kahe nädala tagant või kord kuus), mida nimetatakse “Sprintiks”. Igapäevastel koosolekutel arutavad meeskonnaliikmed:

• aruanne tehtud töö kohta pärast viimast Scrumit;
• ülesannete loetelu, mida töötaja peab täitma enne järgmist koosolekut;
• töö käigus tekkinud raskused.

Metoodika sobib suurte projektide või nende jaoks, mis on suunatud pikale elutsüklile, pidevalt kohandudes turutingimustega. Vastavalt sellele muutuvad ka nõuded rakendusprotsessi käigus. Tasub meeles pidada loomeinimeste klassi, kes kipuvad iganädalaselt või lausa igapäevaselt uusi ideid genereerima, välja mõtlema ja katsetama. Sellele psühhotüübile juhtidele sobib kõige paremini agiilne areng. Arendame ettevõttesiseseid startuppe Agile abil. Kliendiprojektide näide on elektrooniline tervisekontrolli süsteem, mis on loodud massiliste tervisekontrollide läbiviimiseks mõne minutiga. Selle ülevaate teises lõigus kirjeldasid meie Ameerika partnerid väga olulist asja, mis on Agile'i edu jaoks ülioluline.

Millal Agile'i kasutada?

• Kui kasutajate vajadused muutuvad dünaamilises äris pidevalt.
• Agiilsed muudatused viiakse ellu madalamate kuludega tänu sagedastele juurdekasvudele.
• Erinevalt kosemudelist nõuab agiilne mudel projekti käivitamiseks vaid veidi planeerimist.

6. Iteratiivne mudel (iteratiivne või iteratiivne mudel)

Iteratiivne elutsükli mudel ei nõua alustuseks täielikku nõuete spetsifikatsiooni. Selle asemel algab loomine funktsionaalsuse tüki rakendamisega, mis saab aluseks edasiste nõuete määratlemisel. Seda protsessi korratakse. Versioon ei pruugi olla täiuslik, peaasi, et see töötab. Mõistes lõppeesmärki, püüdleme selle poole, et iga samm oleks tõhus ja iga versioon töötaks.

Diagramm näitab Mona Lisa iteratiivset "arengut". Nagu näete, on esimeses iteratsioonis vaid Mona Lisa visand, teises ilmuvad värvid ja kolmas iteratsioon lisab detaile, küllastust ja viib protsessi lõpule. Inkrementmudelis ehitatakse toote funktsionaalsus tükikaupa üles, toode koosneb osadest. Erinevalt iteratiivsest mudelist esindab iga tükk terviklikku elementi.

Iteratiivse arenduse näide on hääletuvastus. Teadusliku aparaadi esimene uurimine ja ettevalmistamine algas juba ammu, algul mõtetes, siis paberil. Iga uue iteratsiooniga paranes äratundmise kvaliteet. Täiuslikku tunnustamist pole aga veel saavutatud, seega pole probleem veel täielikult lahendatud.

Millal on optimaalne kasutada iteratiivset mudelit?

• Lõplikule süsteemile esitatavad nõuded on selgelt määratletud ja eelnevalt arusaadavad.
• Projekt on suur või väga suur.
• Peamine eesmärk tuleb määratleda, kuid rakendamise üksikasjad võivad aja jooksul muutuda.

7. "Spiraalmudel" (spiraalmudel)

"Spiraalmudel" sarnaneb inkrementaalsele mudelile, kuid rõhuasetusega riskianalüüsil. See sobib hästi kriitiliste äriprobleemide lahendamiseks, kui ebaõnnestumine ei sobi kokku ettevõtte tegevusega, uute tootesarjade väljalaskmise kontekstis, kui on vaja teaduslikku uurimistööd ja praktilist testimist.

Spiraalmudel sisaldab iga pöörde jaoks 4 etappi:

1. planeerimine;
2. riskianalüüs;
3. disain;
4. tulemuse hindamine ja rahuldava kvaliteedi korral üleminek uude etappi.

See mudel ei sobi väikeste projektide jaoks, see on mõistlik näiteks keerukate ja kallite projektide puhul, nagu näiteks panga dokumendivoo süsteemi arendamine, kui iga järgmine samm nõuab tagajärgede hindamiseks rohkem analüüsi kui programmeerimine. Siberi ODU SO UES-i EDMS-i väljatöötamise projekti raames võtab kaks koosolekut elektroonilise arhiivi sektsioonide kodifitseerimise muutmiseks kümme korda rohkem aega kui programmeerija poolt kahe kausta ühendamine. Valitsusprojektid, milles osalesime, said alguse sellest, et ekspertkogukond valmistas ette kalli kontseptsiooni, mis pole sugugi alati kasutu, kuna tasub end ära riigi mastaabis.

Teeme kokkuvõtte

Slaid demonstreerib erinevusi kahe enimlevinud metoodika vahel.

Kaasaegses praktikas on tarkvaraarenduse mudelid mitme muutujaga. Kõigi projektide, starditingimuste ja maksemudelite jaoks pole olemas ühte õiget mudelit. Isegi meie kõigi poolt nii armastatud Agile ei saa mõne kliendi ettevalmistamatuse või paindliku finantseerimise võimatuse tõttu igal pool rakendada. Metoodikad osaliselt kattuvad vahendite poolest ja on osaliselt sarnased. Mõningaid teisi mõisteid kasutati ainult oma koostajate reklaamimiseks ega toonud praktikasse midagi uut.

Arendustehnoloogiate kohta:
Veelkord seitsmest peamisest arendusmetoodikast.
10 peamist viga skaleerimissüsteemides.
8 arenguplaneerimise põhimõtet, mis muudavad elu lihtsamaks.
5 peamist riski kohandatud tarkvara arenduses.

Küsitluses saavad osaleda ainult registreerunud kasutajad. , Palun.