Mojawapo ya njia zinazowezekana za ukuzaji wa programu ndani ya mfumo wa modeli ya mzunguko wa maisha ni ile iliyopokelewa Hivi majuzi matumizi makubwa ya mbinu ya RAD (Rapid Application Development). Neno hili kawaida hurejelea mchakato wa ukuzaji wa programu iliyo na vitu 3:
timu ndogo ya waandaaji wa programu (kutoka kwa watu 2 hadi 10);
ratiba fupi lakini iliyoandaliwa kwa uangalifu (kutoka miezi 2 hadi 6);
mzunguko unaorudiwa ambao watengenezaji, wakati programu inapoanza kuchukua sura, kuomba na kutekeleza mahitaji ya bidhaa kupokelewa kupitia mwingiliano na mteja.
Timu ya maendeleo inapaswa kuwa kikundi cha wataalamu wenye uzoefu katika uchanganuzi, muundo, utengenezaji wa msimbo na upimaji wa programu kwa kutumia zana za CASE. Washiriki wa timu lazima pia waweze kutafsiri mapendekezo ya watumiaji wa mwisho kuwa mifano inayofanya kazi.
Mzunguko wa maisha ya programu kulingana na mbinu ya RAD ina awamu nne:
uchambuzi wa mahitaji na awamu ya kupanga;
awamu ya kubuni;
awamu ya ujenzi;
awamu ya utekelezaji.
Katika awamu ya uchanganuzi na upangaji wa mahitaji, watumiaji wa mfumo huamua kazi ambazo ni lazima ifanye, kutambua zile za kipaumbele zaidi ambazo zinahitaji ufafanuzi kwanza, na kuelezea mahitaji ya habari. Ufafanuzi wa mahitaji unafanywa hasa na watumiaji chini ya uongozi wa watengenezaji maalum. Upeo wa mradi ni mdogo, na muda wa kila moja ya awamu zinazofuata umeamua. Kwa kuongeza, uwezekano mkubwa wa utekelezaji umeamua wa mradi huu ndani ya mipaka ya ufadhili iliyowekwa, kwenye vifaa vilivyopewa, nk. Matokeo ya awamu hii inapaswa kuwa orodha na kipaumbele cha kazi za IS ya baadaye, mifano ya awali ya kazi na habari ya IS.
Wakati wa awamu ya kubuni, baadhi ya watumiaji hushiriki katika muundo wa kiufundi wa mfumo chini ya uongozi wa watengenezaji maalum. Zana za KESI hutumika kutoa haraka prototypes zinazofanya kazi za programu. Watumiaji, kuingiliana nao moja kwa moja, kufafanua na kuongeza mahitaji ya mfumo ambayo hayakutambuliwa katika awamu iliyopita. Michakato ya mfumo inajadiliwa kwa undani zaidi. Mfano wa kazi unachambuliwa na, ikiwa ni lazima, kurekebishwa. Kila mchakato unazingatiwa kwa undani. Ikihitajika, kielelezo kidogo kinaundwa kwa kila mchakato wa kimsingi: skrini, mazungumzo, ripoti inayoondoa utata au utata. Mahitaji ya kuzuia ufikiaji wa data yamebainishwa. Katika awamu hiyo hiyo, seti ya nyaraka muhimu imedhamiriwa.
Baada ya uamuzi wa kina wa utungaji wa taratibu, idadi ya vipengele vya kazi mfumo unatengenezwa na uamuzi unafanywa wa kugawanya IS katika mifumo ndogo inayoweza kutekelezwa na timu moja ya wasanidi programu katika muda unaokubalika kwa miradi ya RAD - takriban siku 60 - 90. Kwa kutumia zana za CASE, mradi unasambazwa kati ya timu tofauti (mfano wa kazi umegawanywa). Matokeo ya awamu hii yanapaswa kuwa:
jumla mfano wa habari mifumo;
mifano ya kazi ya mfumo kwa ujumla na mifumo ndogo inayotekelezwa na timu za maendeleo ya mtu binafsi;
miingiliano iliyofafanuliwa kwa usahihi kati ya mifumo midogo iliyotengenezwa kwa uhuru kwa kutumia zana ya KESI;
kujengwa prototypes ya skrini, ripoti, dialogs.
Aina zote na prototypes lazima zipatikane kwa kutumia zana hizo za CASE ambazo zitatumika katika siku zijazo wakati wa kujenga mfumo. Sharti hili Hii ni kutokana na ukweli kwamba katika mbinu ya jadi, wakati wa kuhamisha habari kuhusu mradi kutoka hatua hadi hatua, uharibifu wa data usio na udhibiti unaweza kutokea. Kutumia mazingira ya umoja kwa kuhifadhi habari za mradi hukuruhusu kuzuia hatari hii.
Tofauti na mbinu ya kitamaduni, ambayo ilitumia zana maalum za uigaji ambazo hazikuundwa kuunda programu halisi na prototypes zilizotupwa baada ya kutimiza madhumuni ya kuondoa utata katika muundo, katika mbinu ya RAD kila mfano hutengenezwa kuwa sehemu. mfumo wa baadaye. Kwa hivyo, habari kamili zaidi na muhimu huhamishiwa kwa awamu inayofuata.
Awamu ya ujenzi ni ambapo maendeleo ya maombi ya haraka yenyewe hutokea. Katika awamu hii, watengenezaji hujenga mara kwa mara mfumo halisi kulingana na mifano iliyopatikana katika awamu iliyopita, pamoja na mahitaji yasiyo ya kazi. Msimbo wa programu huzalishwa kwa kiasi kwa kutumia jenereta za kiotomatiki ambazo hupokea taarifa moja kwa moja kutoka kwa hazina ya zana ya CASE. Katika awamu hii, watumiaji wa mwisho hutathmini matokeo yaliyopatikana na kufanya marekebisho ikiwa, wakati wa mchakato wa usanidi, mfumo hautimizi mahitaji yaliyoainishwa hapo awali. Upimaji wa mfumo unafanywa moja kwa moja wakati wa mchakato wa maendeleo.
Baada ya kukamilisha kazi ya kila timu ya maendeleo ya mtu binafsi, ujumuishaji wa taratibu wa sehemu hii ya mfumo na zingine unafanywa, kamili. msimbo wa programu, upimaji unafanywa ili kujaribu jinsi sehemu hii ya programu inavyofanya kazi pamoja na zingine, na kisha kupima mfumo kwa ujumla. Muundo wa kimwili wa mfumo umekamilika:
hitaji la usambazaji wa data imedhamiriwa;
uchambuzi wa matumizi ya data unafanywa;
muundo wa kimwili wa hifadhidata unafanywa;
mahitaji ya rasilimali za vifaa imedhamiriwa;
njia za kuongeza tija zimedhamiriwa;
Uendelezaji wa nyaraka za mradi unakamilika.
Matokeo ya awamu ni mfumo wa kumaliza ambao unakidhi mahitaji yote yaliyokubaliwa.
Wakati wa awamu ya utekelezaji, mafunzo ya mtumiaji, mabadiliko ya shirika na, sambamba na utekelezaji, hufanyika mfumo mpya kazi inafanywa na mfumo uliopo (mpaka mpya itatekelezwa kikamilifu). Kwa kuwa awamu ya ujenzi ni fupi sana, upangaji na maandalizi ya utekelezaji lazima uanze mapema, kwa kawaida wakati wa awamu ya muundo wa mfumo. Mpango wa maendeleo uliotolewa wa IS sio kamili. Chaguzi mbalimbali zinawezekana, kulingana, kwa mfano, juu ya hali ya awali ambayo maendeleo hufanyika: mfumo mpya kabisa unatengenezwa; uchunguzi wa biashara tayari umefanywa na mfano wa shughuli zake upo; Biashara tayari ina IP ambayo inaweza kutumika kama mfano wa awali au lazima iunganishwe na ile inayotengenezwa.
Ikumbukwe, hata hivyo, kwamba mbinu ya RAD, kama nyingine yoyote, haiwezi kudai kuwa ni ya watu wote; Ikiwa mfumo wa kawaida unatengenezwa, ambao sio bidhaa ya kumaliza, lakini ni ngumu ya vipengele vya kawaida, vinavyotunzwa katikati, vinavyoweza kubadilika kwa majukwaa ya programu na vifaa, DBMS, mawasiliano ya simu, vipengele vya shirika na kiuchumi vya vitu vya utekelezaji na kuunganishwa na maendeleo yaliyopo, zifuatazo zinakuja mbele: viashiria vya mradi kama vile usimamizi na ubora, ambavyo vinaweza kupingana na urahisi na kasi ya maendeleo. Kwa miradi kama hiyo ni muhimu ngazi ya juu kupanga na nidhamu kali ya kubuni, kufuata kali kwa itifaki na miingiliano iliyoandaliwa kabla, ambayo inapunguza kasi ya maendeleo.
Mbinu ya RAD haitumiki kwa ajili ya kujenga programu changamano za hesabu, mifumo ya uendeshaji au programu za udhibiti wa vyombo vya anga, i.e. programu zinazohitaji kuandika kiasi kikubwa (mamia ya maelfu ya mistari) ya msimbo wa kipekee.
Maombi ambayo hayana sehemu ya kiolesura iliyofafanuliwa wazi ambayo inafafanua kwa uwazi mantiki ya mfumo (kwa mfano, maombi ya wakati halisi) na programu ambazo usalama wa binadamu hutegemea (kwa mfano, kudhibiti ndege au mtambo wa nyuklia) hazifai. kwa ajili ya maendeleo kwa kutumia mbinu ya RAD, kwa kuwa ni ya kurudia mbinu inadhania kuwa matoleo machache ya kwanza labda hayatafanya kazi kikamilifu, ambayo yametengwa katika kesi hii.
Ukubwa wa programu inakadiriwa kulingana na kinachojulikana vipengele vya kazi (skrini, ujumbe, ripoti, faili, nk). Ukubwa wa programu ambayo inaweza kutekelezwa kwa kutumia mbinu ya RAD, kwa mazingira ya uendelezaji wa IC iliyoimarishwa vyema na utumiaji wa juu zaidi wa vipengee vya programu, huamuliwa kama ifuatavyo:
Kama muhtasari, tunaorodhesha kanuni kuu za mbinu ya RAD:
maendeleo ya maombi katika marudio;
hiari ya kukamilisha kazi kamili katika kila hatua ya mzunguko wa maisha;
ushiriki wa lazima wa watumiaji katika mchakato wa ukuzaji wa IS;
matumizi muhimu ya zana za CASE ili kuhakikisha uadilifu wa mradi;
matumizi ya zana za usimamizi wa usanidi zinazowezesha kufanya mabadiliko kwenye mradi na kudumisha mfumo wa kumaliza;
matumizi ya lazima ya jenereta za kificho;
matumizi ya prototyping kuelewa na kukidhi mahitaji ya mtumiaji wa mwisho;
kupima na maendeleo ya mradi kutekelezwa wakati huo huo na maendeleo;
maendeleo na timu ndogo, iliyosimamiwa vizuri ya wataalamu;
usimamizi mzuri wa maendeleo ya mfumo, upangaji wazi na udhibiti wa utekelezaji wa kazi.
Utengenezaji wa bidhaa za programu unajua mbinu nyingi zinazofaa - kwa maneno mengine, mbinu bora zilizowekwa. Chaguo inategemea maalum ya mradi, mfumo wa bajeti, upendeleo wa kibinafsi na hata tabia ya meneja. Nakala hiyo inaelezea mbinu ambazo tunakutana nazo mara kwa mara huko Edison.
1. "Mfano wa Maporomoko ya Maji" (mfano wa mteremko au "maporomoko ya maji")
Moja ya kongwe zaidi, inahusisha kifungu cha mfululizo cha hatua, ambayo kila moja lazima ikamilike kabisa kabla ya ijayo kuanza. Mtindo wa Maporomoko ya maji hurahisisha kusimamia mradi. Shukrani kwa ugumu wake, maendeleo yanaendelea haraka, gharama na tarehe ya mwisho imedhamiriwa mapema. Lakini huu ni upanga wenye makali kuwili. Mfano wa cascade utatoa matokeo bora tu katika miradi iliyo na mahitaji na njia zilizowekwa wazi na zilizopangwa kwa utekelezaji wake. Hakuna njia ya kuchukua hatua nyuma; majaribio huanza tu baada ya usanidi kukamilika au karibu kukamilika. Bidhaa zilizotengenezwa kulingana na mtindo huu bila chaguo sahihi zinaweza kuwa na mapungufu (orodha ya mahitaji haiwezi kurekebishwa wakati wowote), ambayo inajulikana tu mwishoni kwa sababu ya mlolongo mkali wa vitendo. Gharama ya kufanya mabadiliko ni kubwa kwa sababu inahitaji kusubiri hadi mradi mzima ukamilike ili kuuanzisha. Hata hivyo, gharama ya kudumu mara nyingi huzidi hasara za mbinu. Kurekebisha mapungufu yaliyopatikana wakati wa mchakato wa uundaji inawezekana, na, kwa uzoefu wetu, inahitaji makubaliano moja hadi matatu ya ziada kwa mkataba na vipimo vidogo vya kiufundi.
Kwa kutumia mtindo wa kuteleza tumeunda miradi mingi kutoka mwanzo, ikiwa ni pamoja na maendeleo ya vipimo vya kiufundi pekee. Miradi ambayo imeandikwa kuhusu Habré: kati - X-ray microtomography, ndogo - kusasisha kiotomatiki kwa huduma ya Windows kwenye AWS.
Wakati wa kutumia mbinu ya maporomoko ya maji?
- Ni wakati tu mahitaji yanajulikana, kueleweka na kurekodiwa. Hakuna mahitaji yanayokinzana.
- Hakuna matatizo na upatikanaji wa watayarishaji wa programu walio na sifa zinazohitajika.
- Katika miradi midogo.
2. "V-Model"
Alirithi muundo wa "hatua kwa hatua" kutoka kwa mfano wa kuteleza. Mfano wa umbo la V unatumika kwa mifumo ambayo operesheni isiyoingiliwa ni muhimu sana. Kwa mfano, programu za maombi katika kliniki kwa ajili ya ufuatiliaji wa wagonjwa, programu jumuishi kwa ajili ya mifumo ya udhibiti kwa airbags dharura katika magari Nakadhalika. Kipengele maalum cha mfano ni kwamba inalenga kuangalia na kupima kwa makini bidhaa ambayo tayari iko katika hatua za awali za kubuni. Hatua ya kupima inafanywa wakati huo huo na hatua ya maendeleo sambamba, kwa mfano, vipimo vya kitengo vimeandikwa wakati wa coding.
Mfano wa kazi yetu kulingana na mbinu ya V - programu ya simu kwa Ulaya operator wa simu, ambayo huokoa gharama za kuzurura unaposafiri. Mradi huo unafanywa kwa mujibu wa maelezo wazi, lakini ni pamoja na hatua muhimu ya kupima: urahisi wa interface, kazi, mzigo, na ikiwa ni pamoja na ushirikiano, ambayo inapaswa kuthibitisha kwamba vipengele kadhaa vinatoka. wazalishaji mbalimbali wanafanya kazi pamoja kwa utulivu, wizi wa pesa na mikopo hauwezekani.
Wakati wa kutumia V-modeli?
- Ikiwa upimaji wa kina wa bidhaa unahitajika, basi mfano wa V utahalalisha wazo lake la asili: uthibitishaji na uthibitishaji.
- Kwa miradi midogo na ya kati ambapo mahitaji yanafafanuliwa wazi na yamewekwa.
- Katika hali ya upatikanaji wa wahandisi wenye sifa zinazohitajika, hasa wapimaji.
3. "Mfano wa Kuongeza" (mfano wa nyongeza)
Katika mfano wa nyongeza mahitaji kamili kwa mfumo umegawanywa katika makusanyiko tofauti. Istilahi mara nyingi hutumiwa kuelezea mkusanyiko wa hatua kwa hatua wa programu. Mizunguko kadhaa ya maendeleo hufanyika, na kwa pamoja huunda mzunguko wa maisha"maporomoko ya maji mengi". Mzunguko umegawanywa katika modules ndogo, zilizoundwa kwa urahisi. Kila moduli hupitia awamu za ufafanuzi wa mahitaji, muundo, usimbaji, utekelezaji na majaribio. Mchakato wa maendeleo unaoongezeka unahusisha kutolewa kwa kwanza hatua kubwa bidhaa katika utendakazi wa kimsingi, na kisha kuongeza vitendaji vipya kwa mpangilio, kinachojulikana kama "ongezeko". Mchakato unaendelea hadi mfumo kamili utengenezwe.
Miundo ya ongezeko hutumiwa ambapo maombi ya mabadiliko ya mtu binafsi yako wazi na yanaweza kurasimishwa na kutekelezwa kwa urahisi. Katika miradi yetu tuliitumia kuunda msomaji wa DefView, na kisha mtandao maktaba za elektroniki Vivaldi.
Kwa mfano, tutaelezea kiini cha nyongeza moja. Mtandao wa Vivaldi wa maktaba za kielektroniki ulibadilisha DefView. DefView imeunganishwa kwenye seva moja ya hati na sasa inaweza kuunganisha kwa nyingi. Seva ya hifadhi imewekwa kwenye tovuti ya taasisi inayotaka kutangaza maudhui yake kwa watazamaji maalum, ambayo hupata hati moja kwa moja na kuzibadilisha kuwa muundo unaohitajika. Sehemu ya mizizi ya usanifu imeonekana - seva ya kati Vivaldi, akiigiza kama single injini ya utafutaji kwenye seva zote za hifadhi zilizosakinishwa katika taasisi mbalimbali.
Wakati wa kutumia mfano wa nyongeza?
- Wakati mahitaji ya msingi ya mfumo yanafafanuliwa wazi na kueleweka. Wakati huo huo, baadhi ya maelezo yanaweza kusafishwa kwa muda.
- Utangulizi wa mapema wa bidhaa kwenye soko unahitajika.
- Kuna vipengele au malengo kadhaa hatari.
4. "Mfano wa RAD" (muundo wa ukuzaji wa programu ya haraka au ukuzaji wa haraka wa programu)
Mfano wa RAD ni aina ya mfano wa nyongeza. Katika muundo wa RAD, vipengele au utendaji hutengenezwa kwa sambamba na timu kadhaa zenye ujuzi wa hali ya juu, kama vile miradi midogo mingi. Muda wa mzunguko mmoja ni mdogo sana. Kisha moduli zilizoundwa zimeunganishwa katika mfano mmoja wa kufanya kazi. Harambee hukuruhusu kumpa mteja haraka kitu kinachofanya kazi kwa ukaguzi ili kupokea maoni na kufanya mabadiliko.
Mtindo wa maendeleo ya haraka ya maombi ni pamoja na awamu zifuatazo:
- Muundo wa biashara: kufafanua orodha ya mtiririko wa habari kati ya idara tofauti.
- Mfano wa data: habari iliyokusanywa katika hatua ya awali hutumiwa kuamua vitu na vyombo vingine muhimu kwa mzunguko wa habari.
- Uundaji wa mchakato: Habari hutiririka kuunganisha vitu ili kufikia malengo ya maendeleo.
- Unda programu: Hutumia zana za kusanyiko za kiotomatiki kubadilisha miundo ya CAD kuwa msimbo.
- Majaribio: vipengele vipya na violesura vinajaribiwa.
Inaweza kutumika tu na wasanifu waliohitimu sana na waliobobea sana. Bajeti ya mradi ni kubwa kuwalipia wataalamu hawa pamoja na gharama zana zilizopangwa tayari mkusanyiko wa kiotomatiki. Mfano wa RAD unaweza kuchaguliwa kwa ujuzi wa ujasiri biashara lengwa na haja ya uzalishaji wa haraka wa mfumo ndani ya miezi 2-3.
5. "Mfano Agile" (mbinu rahisi ya ukuzaji)
Katika mbinu ya ukuzaji "ya haraka", baada ya kila kurudia mteja anaweza kutazama matokeo na kuelewa ikiwa yanamridhisha au la. Hii ni moja ya faida za mfano rahisi. Hasara zake ni pamoja na ukweli kwamba kutokana na ukosefu wa uundaji maalum wa matokeo, ni vigumu kukadiria gharama za kazi na gharama zinazohitajika kwa maendeleo. Utayarishaji Mkubwa(XP) ni moja wapo ya utumizi unaojulikana zaidi wa modeli ya kisasa katika mazoezi.
Aina hii inategemea mikutano mifupi ya kila siku - "Scrum" na mikutano ya mara kwa mara (mara moja kwa wiki, mara moja kila wiki mbili au mara moja kwa mwezi), inayoitwa "Sprint". Katika mikutano ya kila siku, washiriki wa timu hujadili:
- ripoti juu ya kazi iliyofanywa tangu Scrum ya mwisho;
- orodha ya majukumu ambayo mfanyakazi lazima amalize kabla ya mkutano ujao;
- matatizo yaliyojitokeza wakati wa kazi.
Wakati wa kutumia Agile?
- Wakati mahitaji ya mtumiaji yanabadilika kila wakati katika biashara inayobadilika.
- Mabadiliko ya agile yanatekelezwa kwa gharama ya chini kutokana na ongezeko la mara kwa mara.
- Tofauti na mfano wa maporomoko ya maji, mtindo wa agile unahitaji mipango kidogo tu ya kupata mradi chini.
6. "Mfano wa Kurudia" (mfano wa kurudia au wa kurudia)
Muundo unaorudiwa wa mzunguko wa maisha hauhitaji vipimo kamili vya mahitaji ili kuanza. Badala yake, uumbaji huanza na utekelezaji wa kipande cha utendaji, ambayo inakuwa msingi wa kufafanua mahitaji zaidi. Utaratibu huu unarudiwa. Toleo hilo haliwezi kuwa kamilifu, jambo kuu ni kwamba linafanya kazi. Kwa kuelewa lengo la mwisho, tunajitahidi ili kila hatua iwe na ufanisi, na kila toleo linaweza kutekelezeka.
Mchoro unaonyesha "maendeleo" ya kurudia ya Mona Lisa. Kama unaweza kuona, katika iteration ya kwanza kuna mchoro tu wa Mona Lisa, kwa pili rangi zinaonekana, na iteration ya tatu inaongeza maelezo, kueneza na kukamilisha mchakato. Katika mfano wa kuongezeka, utendaji wa bidhaa umejengwa kipande kwa kipande, bidhaa imeundwa na sehemu. Tofauti na mfano wa kurudia, kila kipande kinawakilisha kipengele kamili.
Mfano wa maendeleo ya kurudia ni utambuzi wa sauti. Utafiti wa kwanza na maandalizi ya vifaa vya kisayansi ulianza muda mrefu uliopita, kwanza katika mawazo, kisha kwenye karatasi. Kwa kila marudio mapya, ubora wa utambuzi uliboreshwa. Hata hivyo, utambuzi kamili bado haujapatikana, kwa hiyo, tatizo bado halijatatuliwa kabisa.
Ni lini ni bora kutumia mfano wa kurudia?
- Mahitaji ya mfumo wa mwisho iliyofafanuliwa wazi na kueleweka mapema.
- Mradi ni mkubwa au mkubwa sana.
- Lengo kuu lazima lifafanuliwe, lakini maelezo ya utekelezaji yanaweza kubadilika baada ya muda.
7. "Spiral Model" (mfano wa ond)
"Mfano wa ond" ni sawa na mfano wa kuongezeka, lakini kwa msisitizo juu ya uchambuzi wa hatari. Inafanya kazi vizuri kwa kutatua shida muhimu za biashara, wakati kutofaulu hakuendani na shughuli za kampuni, katika muktadha wa kutolewa kwa mpya. mistari ya bidhaa, kama ni lazima utafiti wa kisayansi na majaribio ya vitendo.
Mfano wa ond unajumuisha hatua 4 kwa kila zamu:
- kupanga;
- uchambuzi wa hatari;
- kubuni;
- tathmini ya matokeo na, ikiwa ubora ni wa kuridhisha, mpito kwa hatua mpya.
Hebu tufanye muhtasari
Slaidi inaonyesha tofauti kati ya mbinu mbili za kawaida.
KATIKA mazoezi ya kisasa mifano ya maendeleo programu multivariate. Hakuna mfano mmoja sahihi kwa miradi yote, hali ya kuanzia na mifano ya malipo. Hata Agile, anayependwa sana na sisi sote, haiwezi kutumika kila mahali kwa sababu ya kutokuwa tayari kwa baadhi ya wateja au kutowezekana kwa ufadhili rahisi. Mbinu kwa sehemu zinaingiliana katika njia na zinafanana kwa sehemu. Dhana zingine zilitumika tu kukuza watunzi wao wenyewe na hazikuleta chochote kipya katika vitendo.
Kuhusu teknolojia ya maendeleo:
Kwa mara nyingine tena kuhusu mbinu saba kuu za maendeleo.
Makosa 10 kuu katika mifumo ya kuongeza kiwango.
Kanuni 8 za Mipango ya Maendeleo Zinazofanya Maisha Rahisi.
Hatari 5 kuu katika ukuzaji wa programu maalum.
Watumiaji waliojiandikisha pekee ndio wanaweza kushiriki katika utafiti. , Tafadhali.
Mojawapo ya mbinu za ukuzaji wa programu ndani ya mfumo wa modeli ya mzunguko wa maisha ond ni mbinu inayotumika sana (teknolojia) kwa ukuzaji wa utumaji wa haraka wa RAD (Maendeleo ya Maombi ya Haraka). Mtindo huu unafaa sana kwa ukuzaji wa mtaala, kwa sababu inajumuisha vipengele vitatu:
Ø timu ndogo ya waandaaji wa programu (kutoka kwa watu 2 hadi 10);
Ø ratiba fupi lakini iliyoandaliwa kwa uangalifu (kutoka miezi 2 hadi 6);
Ø mzunguko unaorudiwa ambapo wasanidi programu, wakati programu inapoanza kuunda, huomba na kutekeleza katika bidhaa mahitaji yanayopokelewa kupitia mwingiliano na mteja.
Hebu tuzingatie mtindo huu kwa maelezo. Timu ya watengenezaji inapaswa kuwa kikundi cha wataalamu wenye uzoefu katika uchanganuzi, muundo, utengenezaji wa msimbo na majaribio ya programu kwa kutumia zana za CASE, wanaoweza kuingiliana vyema na watumiaji wa mwisho na kubadilisha mapendekezo yao kuwa prototypes zinazofanya kazi. Mzunguko wa maisha ya programu kulingana na mbinu ya RAD inajumuisha awamu nne(Mchoro 21):
1. Uchambuzi na upangaji wa mahitaji;
2. Kubuni;
3. Ujenzi;
4. Utekelezaji.
Washa awamu ya kwanza uchambuzi wa mahitaji na mipango watumiaji wa mfumo huamua majukumu ambayo inapaswa kufanya, kuangazia yale ya kipaumbele zaidi ambayo yanahitaji ufafanuzi kwanza, na kuelezea mahitaji ya habari (miunganisho). Uundaji wa mahitaji ya mfumo unafanywa hasa na watumiaji chini ya uongozi wa watengenezaji maalum. Upeo wa mradi ni mdogo, na muda wa muda umewekwa kwa kila awamu zinazofuata. Aidha, uwezekano sana wa kutekeleza mradi katika saizi zilizopewa ufadhili, kwenye vifaa vilivyopo, nk.
Matokeo ya awamu inapaswa kuwa: orodha ya kazi zilizopewa kipaumbele za PS ya baadaye; mfano wa awali wa kazi wa PS; mfano wa maelezo ya awali ya PS.
Washa awamu ya pili kubuni watumiaji wengine hushiriki muundo wa kiufundi mifumo chini ya uongozi wa watengenezaji wataalamu na, kuingiliana nao, kufafanua na kuongeza mahitaji ya mfumo ambayo hayakutambuliwa katika awamu iliyopita. Imejadiliwa kwa undani zaidi michakato ya mfumo. Ikiwa ni lazima, mfano wa kazi unarekebishwa, prototypes za sehemu huundwa: skrini, ripoti, kuondoa utata au utata. Mahitaji yanawekwa vikwazo vya ufikiaji wa data. Katika awamu hiyo hiyo, nyaraka zinazohitajika zimedhamiriwa. Baada ya uamuzi wa kina wa muundo wa michakato, idadi ya vipengele vya utendaji vya mfumo unaotengenezwa hupimwa na uamuzi unafanywa kugawa mfumo katika mfumo mdogo.
Matokeo ya awamu hii yanapaswa kuwa: mfano wa habari wa jumla wa mfumo; mifano ya kazi ya mfumo kwa ujumla na mfumo mdogo; miingiliano iliyofafanuliwa kwa usahihi kati ya mifumo midogo iliyotengenezwa kwa uhuru; kujengwa prototypes ya skrini, ripoti, dialogs.
Tofauti na mbinu ya kitamaduni, ambayo ilitumia zana mahususi za uigaji ambazo hazijaundwa kwa ajili ya kuunda programu za ulimwengu halisi na mifano iliyotupwa baada ya kutimiza madhumuni ya kuondoa utata wa muundo, Katika mbinu ya RAD, kila mfano hutengenezwa kuwa sehemu ya mfumo wa siku zijazo. Kwa hivyo, habari kamili zaidi na muhimu huhamishiwa kwa awamu inayofuata.
Washa awamu ya tatu ujenzi Uendelezaji wa haraka wa maombi yenyewe (utekelezaji wa mfumo mdogo) unafanywa moja kwa moja. Katika awamu hii, watengenezaji hujenga mara kwa mara mfumo halisi kulingana na mifano iliyopatikana katika awamu iliyopita, pamoja na mahitaji yasiyo ya kazi. Katika awamu hii, watumiaji wa mwisho hutathmini matokeo yaliyopatikana na kufanya marekebisho ikiwa, wakati wa mchakato wa usanidi, mfumo hautimizi mahitaji yaliyoainishwa hapo awali. Uchunguzi wa mfumo unafanywa wakati wa mchakato wa maendeleo.
Baada ya maendeleo ya mfumo mdogo kukamilika, sehemu hii ya mfumo inaunganishwa hatua kwa hatua na wengine, msimbo kamili wa programu hutolewa, na mfumo kwa ujumla unajaribiwa. Muundo wa kimwili wa mfumo umekamilika: haja ya usambazaji wa data imedhamiriwa; uchambuzi wa matumizi ya data unafanywa; muundo wa kimwili wa hifadhidata unafanywa; mahitaji ya rasilimali za vifaa imedhamiriwa; njia za kuongeza tija zimedhamiriwa; Uendelezaji wa nyaraka za mradi unakamilika.
Matokeo ya awamu ni mfumo tayari, kukidhi mahitaji yote yaliyokubaliwa.
Washa awamu ya nne utekelezaji mafunzo ya watumiaji, mabadiliko ya shirika yanafanywa na, sambamba na utekelezaji wa mfumo mpya, kazi inafanywa na mfumo uliopo(mpaka mpya itekelezwe kikamilifu). Kwa kuwa awamu ya ujenzi ni fupi sana, upangaji na maandalizi ya utekelezaji lazima uanze mapema, kwa kawaida wakati wa awamu ya muundo wa mfumo.
Teknolojia ya RAD (kama nyingine yoyote) haiwezi kudai kuwa ya ulimwengu wote ni nzuri kimsingi kwa miradi midogo iliyotengenezwa kwa mteja mahususi. Haitumiki kwa maendeleo mifumo ya uendeshaji; mipango ngumu ya hesabu yenye idadi kubwa ya msimbo wa programu na algorithms tata ya udhibiti wa kipekee; programu ambazo hazina sehemu ya kiolesura iliyofafanuliwa wazi ambayo inafafanua kwa uwazi mantiki ya mfumo (matumizi ya wakati halisi), kwani mbinu ya kurudia inadhania kuwa matoleo machache ya kwanza hayatatimiza mahitaji kikamilifu.
Kwa kumalizia, tunaorodhesha Kanuni za msingi za teknolojia ya RAD:
Ø maendeleo ya maombi katika marudio;
Ø hiari ya kukamilisha kazi katika kila hatua ya mzunguko wa maisha;
Ø ushiriki wa lazima wa watumiaji katika hatua ya maendeleo;
Ø matumizi ya prototipu kufafanua na kukidhi mahitaji yote mtumiaji wa mwisho;
Ø kupima na kuendeleza mradi wakati huo huo na maendeleo;
Ø usimamizi mzuri wa maendeleo, upangaji wazi na udhibiti wa utekelezaji wa kazi.
Maswali ya kudhibiti kwa sura ya 3:
1. Kusanifisha na uthibitishaji wa bidhaa ya programu ni nini?
2. Kuna aina gani za viwango?
3. Orodhesha viwango maarufu zaidi vya mzunguko wa maisha ambavyo vimetumika kwa ukuzaji wa programu?
4. Mzunguko wa maisha ya programu ni nini?
5. Orodhesha hatua kuu za mzunguko wa maisha ya programu. Mchakato, hatua, kazi ni nini?
6. Ni aina gani za michakato na michakato maalum unakumbuka?
7. Eleza michakato ya msingi ya uhandisi ya mzunguko wa maisha ya programu.
8. Mfano wa mzunguko wa maisha ya programu ni nini? Toa ufafanuzi wa dhana za kimsingi zinazohusiana na dhana ya "mfano".
9. Je! unajua aina gani za mifano? Je, ni faida zao, hasara, upeo wa matumizi?
10.Unaweza kusema nini kuhusu vipengele vya mtindo wa mzunguko wa maisha ya maporomoko ya maji?
11.Je, kuna tofauti gani kati ya mtindo wa mteremko wa jumla na ule wa msingi?
12.Unaweza kusema nini kuhusu sifa za modeli ya mzunguko wa maisha ond?
13.Orodhesha vipengele vya teknolojia ya RAD. Je! ni aina gani za programu ambazo teknolojia ya RAD inaweza kutumika kutengeneza?
14.Eleza awamu kuu za mzunguko wa maisha wa teknolojia ya RAD.
15.Orodhesha kanuni za msingi za teknolojia ya RAD.
BIBLIOGRAFIA
1. Aptekar M.D., Ramazanov S.K., Freger G.E. Historia ya shughuli za uhandisi. - Kyiv, 2003. - 204 p. : mgonjwa.
2. Archibald R. Mifano ya mzunguko wa maisha ya miradi ya teknolojia ya juu. http://www.pmprofy.ru/content/rus/107/1073-article.html
3. Brooks F. Mwezi wa kizushi wa mwanadamu au jinsi walivyoumbwa mifumo ya programu. - St. Petersburg. : Alama-plus, 1999. - 321 p. : mgonjwa.
4. Butch G. Muundo unaolenga kitu na mifano ya matumizi. - M.: Concord, 1992. - 586 p. : mgonjwa.
5. Butch G. Uchambuzi unaolenga kitu na muundo unaolenga kitu katika C++. - M.: Binom, - 2001. - 558 p. : mgonjwa.
6. Vendrov A. M. CASE teknolojia. Mbinu za kisasa na zana za kubuni mifumo ya habari. - M.: Fedha na Takwimu, - 1999. - 256 p. : mgonjwa.
7. Wirth N. Algorithms + data miundo = mipango: Transl. kutoka kwa Kiingereza - M.: Mir, 1985. - 406 p.: mgonjwa.
8. Dahl O., Dijkstra E., Hoor K. Utayarishaji wa muundo: Transl. kutoka kwa Kiingereza - M.: Mir, 1975. - 247 p. : mgonjwa.
9. Dzerzhinsky F.Ya., Kalinichenko I.M. Nidhamu ya programu: dhana na uzoefu katika kutekeleza zana za mbinu za uhandisi wa programu. - M.: Taasisi Kuu ya Utafiti wa Habari na Utafiti wa Kiufundi na Kiuchumi katika Sayansi ya Nyuklia na Teknolojia, 1988. - 245 p. : mgonjwa.
10. Zhogolev E. A. Teknolojia za programu. - M.: Ulimwengu wa kisayansi, 2004. - 216 p. : mgonjwa.
11. Sheria ya Shirikisho la Urusi No. 149-FZ ya Julai 29, 2006. "Kuhusu taarifa teknolojia ya habari na ulinzi wa habari”// Rossiyskaya Gazeta, No. 165 ya Julai 27, 2006.
12. Ivanova G. S. Teknolojia ya programu: Kitabu cha maandishi kwa vyuo vikuu. - Toleo la 2., aina potofu. - M.: Nyumba ya uchapishaji ya MSTU im. N.E. Bauman, 2003. - 320 pp.: mgonjwa.
13. Kalyanov G. N. KESI: Uchambuzi wa mfumo wa miundo (otomatiki na matumizi). - M.: "Lori", 1996. - 356 p. : mgonjwa.
14. Korablin M. A. Programu inayolenga kitu: Kitabu cha maandishi. - Samara: nyumba ya uchapishaji ya SSAU, 1994. - 94 p.
15. Leonenkov A.V. Mwongozo wa mafundisho ya UML. - St. Petersburg: VHV St. Petersburg, - 2001. - 304 p. : mgonjwa.
16. Lipaev V.V. - M.: Fedha na Takwimu, 1983. - 263 p. : mgonjwa.
17. Lipaev V.V programu ngumu: Mbinu, njia, teknolojia. -M. : Energoatomizdat, 1993. - 384 p. : mgonjwa.
18. Lipaev V.V., Filippov E.N. Uhamaji wa programu na data katika wazi mifumo ya habari. - M.: Kitabu cha kisayansi, 1997. - 297 p. : mgonjwa.
20. Ozhegov S.I. Kamusi ya lugha ya Kirusi. – M.: Amani na Elimu, 2006. – 1328 p.
21. Teknolojia ya kubuni complexes ya mfumo wa kudhibiti automatiska / V. V. Lipaev, L. A. Serebrovsky, P. G. Gaganov, nk; Mh. Yu. V. Afanasyeva, V. V. Lipaeva. - M.: Redio na Mawasiliano, 1983. - 256 p. : mgonjwa.
22. Hyvenen E., Seppanen J. Ulimwengu wa LISP: Transl. kutoka Kifini Katika juzuu 2 T.1: Utangulizi wa lugha ya Lisp na programu ya kazi.- M.: Mir, 1990. - 447 p. : mgonjwa.
23. Hyvenen E., Seppanen J. Ulimwengu wa LISP: Transl. kutoka Kifini Katika kiasi cha 2 T.2: Mbinu na mifumo ya programu - M.: Mir, 1990. - 319 p. : mgonjwa.
24. Boehm B. "Mfano wa Ond wa Ukuzaji na Uboreshaji wa Programu," Kompyuta ya IEEE, Vol. 21, Na. 5, uk. 61–72, 1988.
25. Courtois P. Juni 1985. Mtengano wa Wakati na Nafasi wa Miundo tata. Mawasiliano ya ACM juzuu ya 28(6), uk.596.
26. Vigezo vya Tathmini ya Programu. ISO TC97/SC7 #383.
27. Dijktra E. 1979. Upangaji Programu Unazingatiwa kama Shughuli ya Kibinadamu. Classics katika Uhandisi wa Programu. 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. Shirika la Microsoft. Kanuni za kubuni na maendeleo ya programu. Kozi ya mafunzo MCSD: Transl. kutoka kwa Kiingereza - M.: Nyumba ya kuchapisha na biashara "Toleo la Kirusi", 2000. -608 p. : mgonjwa.
31. Parnas D., Clements P., Weiss D. 1983. Kuimarisha Utumiaji tena kwa Kuficha Taarifa. Kesi za Warsha juu ya Utumiaji Upya katika Utayarishaji. Stratford, CT: Utayarishaji wa ITT. uk.241.
32. Rechtin E. Oktoba 1992. Sanaa ya Usanifu wa Mifumo. IEEE Spectrum, juzuu ya 29(10), uk.66.
33. Royce W.W. Kusimamia Maendeleo ya Mifumo Mikubwa ya Programu. http://facweb.cti.depaul.edu/jhuang/is553/Royce.pdf.
34. Shaw M. Oktoba 1984. Mbinu za Uondoaji katika Lugha za Kisasa za Kuandaa. IEEE Programu juzuu ya 1(4).
35. Simon H. 1982. Sayansi ya Bandia. Cambridge, MA: MIT Press. – uk.218.
36. Sommerville I. Uhandisi wa programu. – Addison-Wesley Publishing Company, 1992. p.87.
37. Tesler L. Agosti 1981. Mazingira ya Mazungumzo Madogo. Byte juzuu ya 6(8), uk.142.
38. Yonezawa A., Tokoro M. 1987. Upangaji wa Programu unaozingatia Malengo. Cambridge, MA: MIT Press.
orodha ya masharti
Uchaguzi wa mbinu za maendeleo ya maombi inakuwa kazi No 1 katika hali ukuaji wa haraka soko. Kulingana na utafiti Dola za Marekani bilioni 310 zilitumika kwenye programu za biashara duniani kote mwaka 2015. Maendeleo ya dhanaRAD (Maendeleo ya Maombi ya Haraka)ikawa msingi wa kuunda muundo rahisi, mfumo wa kubadilika uendelezaji wa maombi, ambayo itakuwa kinyume na mfano wa "maporomoko ya maji" magumu.
RAD ni modeli ya ukuzaji wa programu ya haraka ambayo inazingatia kasi na urahisi wa programu.
Kuibuka kwa RAD
Tunaweza kushukuru kutokamilika kwa mfano wa familia kwa kuibuka kwa maendeleo ya haraka ya maombi Maporomoko ya maji wakati wa kuunda programu. Jambo ni kwamba mwanzoni mfumo wa maendeleo ya maporomoko ya maji ulikuwa msingi wa mfano wa uhandisi wa jadi uliotumiwa kwa ajili ya kubuni na ujenzi wa majengo na madaraja.
Ingawa Maporomoko ya Maji yalitokana na muundo mgumu wa shughuli za maendeleo zinazofuatana, kuibuka kwa RAD ilikuwa jaribio la kuunda mchakato rahisi ambao unaweza kutumia maarifa yaliyopatikana wakati wa mzunguko wa maisha ya mradi.
Toleo la kwanza la RAD liliundwa na Barry Boehm mnamo 1986, ambaye aliiita "modeli ya ond." Kila zamu ya ond imegawanywa katika sekta 4 na inafanana na maendeleo ya fragment au toleo la programu. Kwa kila upande mpya kuna kuongezeka na ufafanuzi wa malengo na vipimo vya mradi. Matokeo yake, inakuwa inawezekana kuchagua chaguo la habari.
Kwa kutumia mawazo ya Barry, Muingereza James Martin alitengeneza mfumo wake wa RAD wakati wa kufanya kazi katika miaka ya 1980 katika IBM, na hatimaye kuziunda kuwa "Maendeleo ya Haraka ya Maombi" katika 1991.
Ukweli, kuna machafuko juu ya maana ya neno "RAD" hata kati ya wataalamu wa IT. Baada ya yote, tulizungumza juu ya dhana mbili: RAD kama njia mbadala inayofaa kwa Maporomoko ya Maji Na RAD kama njia maalum iliyoundwa na Martin. Mwisho umebadilishwa kwa mifumo ya biashara inayohitaji UI.
Baadaye, mawazo yalitengenezwa na kuboreshwa Waanzilishi wa RAD James Kerr na Richard Hunter katika ushirikiano wa "Ndani ya RAD," ambayo iliangazia safari ya meneja wa mradi alipokuwa akijifunza na kutekeleza mbinu halisi ya utumaji maombi ya haraka kwa mradi halisi.
Mfano wa ond ni mchakato wa ukuzaji wa programu ambao unachanganya muundo na protoksi ya hatua kwa hatua.
Misingi (kanuni) za maendeleo ya haraka ya maombi
Kanuni za RAD zinalenga katika kutoa manufaa ya msingi ya maendeleo ya haraka ya programu:
- kuongezeka kwa kasi ya maendeleo
- gharama nafuu
- ubora wa juu.
NA hatua ya mwisho Shida nyingi huibuka kwa sababu msanidi programu na mteja wanaona mada ya maendeleo kwa njia tofauti.
Ili kuondoa shida hii na zingine, James Martin na wafuasi wake waligundua kanuni zifuatazo za RAD:
- kupunguza gharama za muda- zana inapaswa kulenga kupunguza muda wa maendeleo
- uchapaji picha- Uundaji wa prototypes kubainisha mahitaji ya wateja
- maendeleo ya mzunguko- kila toleo jipya la bidhaa linatokana na tathmini ya matokeo ya kazi toleo la awali mteja
- ushirikiano- Timu ya maendeleo lazima kuingiliana kwa karibu na kila mmoja, kila mwanachama lazima awe tayari kutekeleza majukumu mengi
- mbinu ya kurudia kwa maendeleo
- mchanganyikoupimaji na maendeleo ya mfumo.
Kanuni za RAD hazitumiwi tu wakati wa utekelezaji, lakini pia zinaenea kwa hatua zote za mzunguko wa maisha, hasa, kwa hatua ya uchunguzi wa shirika, mahitaji ya ujenzi, uchambuzi na kubuni.
Mzunguko wa maisha ya programu kulingana na RAD
Wakati wa mchakato wa RAD, maombi hupitia awamu nne.
Uchambuzi wa mahitaji na awamu ya kupanga
Mahitaji, kazi za maombi na kipaumbele chao ni kuamua, mahitaji ya habari yanaelezwa. Awamu hiyo inafanywa kimsingi na watumiaji kwa ushiriki wa watengenezaji. Katika hatua hii, ukubwa wa mradi, wakati na mfumo wa kifedha, na majukwaa ya kuzindua programu pia yanaonyeshwa.
, kampuni ya Beverly Flowers inahitaji maombi ya kuagiza maua mtandaoni nyumbani kwako. Muda wa uundaji ni siku 50, bajeti ni $3,000.Awamu ya kubuni
Watumiaji wengine hushiriki katika muundo wa kiufundi wa mfumo chini ya uongozi wa watengenezaji. Vikundi vya RAD au vikundi vidogo katika awamu hii kwa kawaida hutumia mchanganyiko wa mbinuNa Maendeleo ya Maombi ya Ushirikiano (JAD) Na Vyombo vya KESI kutafsiri mahitaji ya mtumiaji katika miundo ya kufanya kazi.
JAD (Maendeleo ya Maombi ya Pamoja) ni dhana ya ukuzaji wa maombi ya pamoja, ambayo ndani yake kuna mwingiliano wa karibu kati ya mteja na watendaji kwa kiwango cha juu. suluhisho la ufanisi masuala yanayohusiana na programu inayotengenezwa.
Case ni seti ya zana na mbinu za uundaji wa programu ili kuhakikisha bidhaa za programu za ubora wa juu, zisizo na hitilafu na ambazo ni rahisi kutunza.
Wakati wa awamu ya kubuni, watumiaji wanaweza kuelewa, kurekebisha, na kufafanua muundo wa kufanya kazi wa mfumo unaokidhi mahitaji yao. Kila mchakato unazingatiwa kwa undani na, ikiwa ni lazima, kuundwamfano wa sehemu .
Kama matokeo, awamu zinaundwa:
- maelezo ya jumla mfano wa maombi
- mifano ya kazi ya mfumo na mifumo ndogo
- prototypes zinazofanya kazi za skrini, ripoti na mazungumzo.
Ikiwa zana za ukuzaji wa mfano hazikuwa za kutosha katika mifano ya hapo awali maombi halisi, na hazikutumiwa zaidi, basi kwa RAD, kila mfano unakuwa sehemu ya mfumo wa siku zijazo.
Kwa hivyo, katika programu ya Maua ya Beverly, watumiaji wanapaswa kupata chaguzi zifuatazo: "Ukurasa wa Nyumbani", "Utafutaji wa Maua", "Orodha ya Maua".
SpringToolSuite ya bure ilichaguliwa kama jukwaa la ukuzaji, ambalo idadi kubwa ya sampuli zinapatikana - vipande vilivyoandikwa vya msimbo.
Kama seva - Apache Tomcat 6.0.
Awamu ya ujenzi
Katika hatua hii, maendeleo ya haraka ya haraka hutokea kulingana na matokeo yaliyopatikana katika awamu zilizopita. Ambapowatumiaji wanaendelea kushiriki katika uundaji wa mfumo, na kupendekeza mabadiliko na uboreshaji wa programu. Upimaji wa maombi pia hutokea wakati wa maendeleo.
Programu ya "Maua ya Beverly" imekusanywa kutoka kwa vipengele vitatu vya kazi - mpito wa mtumiaji hadi " Ukurasa wa nyumbani", "Vinjari Rangi" na "Tazama Orodha ya Rangi".
Kwa maendeleo mtindo wa kufanya kazi ilichukua mtaalamu 1 na siku 8.
Awamu ya utekelezaji
Inashughulikia mafunzo ya watumiaji, upimaji na mbadala mfumo wa zamani kwa mpya. Maandalizi ya awamu hii huanza na awamu ya kubuni.
Hapo awali, Beverly Flowers ilikubali maagizo moja kwa moja katika maeneo ya mauzo na kwa simu.
Kwa kurekodi ujumbe kuhusu uwezekano wa kuagiza kupitia maombi maalum na kwa kuweka vituo vya habari katika maeneo ya mauzo, katika wiki 2 tuliweza kubadili wanunuzi wengine kituo kipya mauzo
Wakati huo huo, sehemu ya maagizo ya simu ilipungua kwa uwiano, ambayo ina maana ilikuwa inawezekana kupunguza wafanyakazi wa wasimamizi wa huduma kwa wateja.
Inafaa kuzingatia kwamba, tofauti na Maporomoko ya Maji, mzunguko wa maisha ya mradi kulingana na mbinu ya RAD sio ngumu. Kulingana na hali ya kuanzia, idadi ya awamu inaweza kupungua, pamoja na kujaza kwao.
Faida na hasara za maendeleo ya haraka ya programu katika kampuni yako
Iwapo utatumia Ukuzaji wa Programu ya Haraka au la kwa kiasi kikubwa inategemea hali ya kuanzia, mahitaji ya mteja na aina ya programu.
Faida za wazi za RAD ni pamoja na:
- ubora wa juu. Mwingiliano wa mtumiaji na prototypes huongeza utendakazi wa miradi ya maendeleo ya programu ya haraka. Programu kama hizo zinaweza kukidhi mahitaji ya mteja (mtumiaji wa mwisho) kuliko kutumia mbinu za Agile/Maporomoko ya maji.
- udhibiti wa hatari- ingawa sehemu ya simba nyenzo kuhusu RAD inazingatia kasi Na kuhusika watumiaji kama vipengele muhimu mfano, faida ya tatu muhimu haiwezi kutengwa — kupunguza hatari.
Inafurahisha, Boehm, ambaye aliunda toleo la kwanza la RAD, alielezea mfano wa ond kama msingi wa hatari.
Kutumia maendeleo ya haraka ya maombi inakuwezesha kuzingatia mambo makuu ya hatari na kukabiliana nao katika hatua ya awali. - Miradi zaidi inakamilika kwa kila kitengo cha muda ndani ya bajeti- kwa kuwa RAD inamaanisha modeli ya maendeleo ya nyongeza, nafasi kwa makosa muhimu, ambayo mara nyingi hutokea katika miradi mikubwa ya Maporomoko ya Maji, hupunguzwa.
Ikiwa katika miradi ya mfumo wa maporomoko ya maji utekelezaji wa mradi uliwezekana baada ya miezi sita au zaidi ya uchambuzi na maendeleo, basi katika RAD taarifa zote muhimu zinafunuliwa mapema, wakati wa mchakato wa kuunda maombi yenyewe.
Muundo wa ukuzaji wa nyongeza ni umbizo la ukuzaji programu ambalo linahusisha kugawanya bidhaa katika vipengele vinavyojitegemea kiasi. Mwisho hutengenezwa na kuweka katika operesheni tofauti.
Sio bila mapungufu yake.
Hasara za maendeleo ya haraka ya maombi ni pamoja na:
- hatari ya "novelty"- kwa kampuni nyingi za IT, RAD ilikuwa bidhaa mpya ambayo ilihitaji kufikiria tena njia za kawaida za kufanya kazi. Upinzani wa mambo mapya na haja ya kujifunza zana na mbinu kutoka mwanzo husababisha makosa wakati wa utekelezaji wa kwanza wa maendeleo ya haraka ya programu.
- ikiwa watumiaji hawawezi kuendelea kushiriki katika mchakato wa ukuzaji katika kipindi chote cha maisha, hii inaweza kuathiri vibaya bidhaa ya mwisho - kipengele cha RAD ni kuongezeka kwa mwingiliano kati ya watumiaji na wasanidi programu, tofauti na miundo ya Maporomoko ya maji ambayo jukumu la watumiaji linapunguzwa hadi kufafanua mahitaji. . Ifuatayo, watengenezaji huunda mfumo wenyewe.
- kupunguzwa udhibiti— unyumbufu, ubadilikaji wa kuchakata kama mojawapo ya faida za RAD maana yake ni uwezo wa kukabiliana haraka na matatizo na fursa zote mbili.
Kwa bahati mbaya, utalazimika kutoa upendeleo kwa jambo moja - kubadilika au kudhibiti. Katika kesi ya mwisho, mbinu ya maendeleo ya maombi ya haraka haitawezekana. - kubuni sparse- kuzingatia prototypes katika baadhi ya matukio husababisha "hack na mtihani" mbinu, ambayo watengenezaji mara kwa mara kufanya mabadiliko madogo V vipengele vya mtu binafsi na kupuuza masuala ya usanifu wa mfumo.
- ukosefu wa scalability- RAD hutumiwa kimsingi na timu ndogo na za kati za mradi. Upungufu wa mbinu ya maendeleo ya maombi ya haraka hutamkwa hasa wakati wa kutumia maendeleo ya maombi ya haraka katika kazi kwenye miradi mikubwa.
Mbinu ya RAD inafaa kwa mradi wako ikiwa:
- kasi na urahisi wa maendeleo ni muhimu kwake
- iliyofafanuliwa wazi maeneo ya kipaumbele maendeleo ya mradi
- Programu inahitaji kuendelezwa kwa muda mfupi
- mradi unafanywa chini ya bajeti ndogo
- kigezo kuu ni kiolesura cha mtumiaji
- Inawezekana kuvunja mradi katika vipengele vya kazi.
Mbinu ya ukuzaji wa programu ya haraka haitafaa mradi wako ikiwa:
- ubora na udhibiti ni muhimu kwake
- tunazungumza juu ya kuunda mradi mkubwa- inatakiwa muda wa juu wakati wa ukuzaji wa programu ni siku 60-90, na wakati wa kuandika mamia ya maelfu ya mistari ya nambari ya programu, karibu haiwezekani kufuata kizuizi kama hicho.
- muhimu kwa utekelezaji ni kiwango cha juu cha mipango na nidhamu kali ya kubuni, ufuasi mkali kwa itifaki na violesura vilivyotengenezwa awali
- Usalama wa watu hutegemea kwa kiasi fulani juu ya maombi.
Uamuzi
Dhana ya ukuzaji wa haraka wa programu (kifupi cha RAD kwa Ukuzaji wa Programu ya Haraka) ni aina ya modeli za ukuzaji wa programu zinazoongezeka.
Vigezo muhimu ambavyo RAD inafanya kazi ni:
kasi na urahisi wa programu.
Mbinu itakuwa chaguo bora kwa utekelezaji miradi midogo yenye bajeti ndogo, ambayo yanahitaji kuendelezwa kwa muda mfupi. Kwa mifumo mikubwa, na mahitaji ya juu Kwa udhibiti na mipango, ni bora kuchagua mifano mingine ya maendeleo ya programu.
Ukuzaji wa Programu ya Haraka (RAD) ni mchakato wa kubuni maisha ulioundwa ili kufikia zaidi kasi kubwa maendeleo na ubora wa programu kuliko inavyowezekana kwa mbinu ya kubuni ya jadi.
Dhana ya RAD ilikuwa jibu kwa mbinu za ukuzaji programu za miaka ya 1970 na mapema miaka ya 1980, kama vile "mfano wa maporomoko ya maji". Njia hizi zilihusisha mchakato wa polepole wa kuunda programu ambayo mara nyingi hata mahitaji ya programu yalikuwa na wakati wa kubadilika kabla ya mwisho wa maendeleo. Mwanzilishi wa RAD anachukuliwa kuwa mfanyakazi wa IBM James Martin, ambaye katika miaka ya 1980 alitengeneza kanuni za msingi za RAD, kulingana na mawazo ya Barry Boym na Scott Schultz. Na mnamo 1991, Martin alichapisha kitabu maarufu ambacho alielezea kwa undani wazo la RAD na uwezekano wa matumizi yake. Hivi sasa, RAD inakuwa mpango unaokubalika kwa ujumla wa kuunda zana za ukuzaji programu.
RAD inadhani kwamba uundaji wa programu unafanywa na timu ndogo ya wasanidi programu kwa muda wa takriban tatu hadi nne, kwa kutumia uundaji wa vielelezo vya kuona na zana za ukuzaji. Teknolojia ya RAD hutoa ushiriki hai mteja tayari katika hatua za mwanzo - uchunguzi wa shirika, maendeleo ya mahitaji ya mfumo. Mbinu ya RAD ni mojawapo ya mbinu za ukuzaji wa programu ndani ya modeli ya mzunguko wa maisha.
Mzunguko wa maisha ya programu kulingana na mbinu ya RAD ina awamu nne:
uchambuzi wa mahitaji na awamu ya kupanga;
awamu ya kubuni;
awamu ya ujenzi;
awamu ya utekelezaji.
Katika uchanganuzi wa mahitaji na hatua ya kupanga, watumiaji hufanya vitendo vifuatavyo:
kuamua kazi ambazo mfumo unapaswa kufanya;
kuangazia kazi za kipaumbele za juu zaidi zinazohitaji ufafanuzi kwanza;
maelezo ya mahitaji ya habari.
Uundaji wa mahitaji ya mfumo unafanywa hasa na watumiaji chini ya uongozi wa watengenezaji maalum. Kwa kuongeza, katika hatua hii kazi zifuatazo zinatatuliwa:
upeo wa mradi ni mdogo;
muafaka wa muda umeanzishwa kwa kila hatua zinazofuata;
uwezekano sana wa kutekeleza mradi ndani ya kiasi kilichotolewa cha fedha kwa kutumia vifaa vilivyopo, nk imedhamiriwa. Matokeo ya hatua inapaswa kuwa:
orodha ya kazi zilizopewa kipaumbele za programu ya IS ya siku zijazo;
mifano ya programu ya awali.
Katika hatua ya kubuni, watumiaji wengine wanashiriki katika muundo wa kiufundi wa mfumo chini ya uongozi wa watengenezaji maalum. Ili kupata haraka prototypes za kufanya kazi za programu, zana zinazofaa (zana za KESI) hutumiwa. Watumiaji, wanaoingiliana moja kwa moja na wasanidi programu, hufafanua na kuongeza mahitaji ya mfumo ambayo hayakutambuliwa katika hatua ya awali. Katika hatua hii, vitendo vifuatavyo hufanywa:
michakato ya mfumo inachunguzwa kwa undani zaidi;
ikiwa ni lazima, mfano wa sehemu huundwa kwa kila mchakato wa kimsingi (fomu ya skrini, mazungumzo, ripoti, kuondoa utata au utata);
mahitaji ya kuzuia upatikanaji wa data yanaanzishwa;
muundo wa nyaraka muhimu imedhamiriwa.
Mradi huo kisha kusambazwa kati ya timu mbalimbali za maendeleo. Kwa upande wa zana za CASE, hii ina maana ya kugawanya muundo wa utendaji wa mfumo (michoro ya mtiririko wa data kwa mbinu iliyopangwa au kutumia michoro ya kesi kwa mbinu inayolenga kitu). Matokeo ya hatua hii inapaswa kuwa:
mfano wa habari wa jumla wa mfumo;
mifano ya kazi ya mfumo kwa ujumla na mifumo ndogo inayotekelezwa na timu za maendeleo ya mtu binafsi;
miingiliano iliyofafanuliwa kwa usahihi kati ya mifumo midogo iliyotengenezwa kwa uhuru;
prototypes zilizojengwa za fomu za skrini, ripoti, mazungumzo.
Aina zote na prototypes lazima zipatikane kwa kutumia zana hizo za CASE ambazo zitatumika katika siku zijazo wakati wa kujenga mfumo. Sharti hili linatokana na hitaji la kuzuia upotoshaji wa data usiodhibitiwa wakati wa kuhamisha habari kuhusu mradi kutoka hatua hadi hatua.
Katika hatua ya utekelezaji, maendeleo ya haraka ya maombi hufanywa:
Waendelezaji mara kwa mara huunda mfumo halisi kulingana na mifano iliyopatikana katika hatua ya awali, pamoja na mahitaji yasiyo ya kazi (mahitaji ya kuaminika, mahitaji ya utendaji, nk).
Watumiaji hutathmini matokeo yaliyopatikana na kufanya marekebisho ikiwa, wakati wa mchakato wa usanidi, mfumo haukidhi mahitaji yaliyoainishwa hapo awali. Uchunguzi wa mfumo unafanywa wakati wa mchakato wa maendeleo.
Baada ya kukamilisha kazi ya kila timu ya maendeleo ya mtu binafsi, ujumuishaji wa taratibu wa sehemu hii ya mfumo na iliyobaki unafanywa, nambari kamili ya programu inatolewa, utendakazi wa pamoja wa sehemu hii ya maombi hujaribiwa, na kisha mfumo kama. nzima hujaribiwa. Utekelezaji wa mfumo unakamilika kwa kufanya kazi zifuatazo:
matumizi ya data yanachambuliwa na haja ya usambazaji wake imedhamiriwa;
muundo wa kimwili wa hifadhidata unafanywa;
mahitaji ya rasilimali za vifaa yanaundwa;
njia za kuongeza tija zimeanzishwa;
Uendelezaji wa nyaraka za mradi unakamilika. Matokeo ya hatua ni mfumo wa kumaliza ambao unakidhi mahitaji yote yaliyokubaliwa.
Katika hatua ya utekelezaji, mafunzo ya watumiaji na mabadiliko ya shirika hufanywa.
Matumizi ya teknolojia ya RAD inapendekezwa wakati:
mradi unahitajika kukamilika ndani ya muda mfupi (siku 90);
mahitaji ya programu hayajafafanuliwa wazi;
mradi unafanywa chini ya vikwazo vya bajeti;
kiolesura cha mtumiaji (GUI) ndio sababu kuu;
mradi ni mkubwa, lakini unaweza kugawanywa katika vipengele vidogo vya kazi;
Programu haina utata wa juu wa kukokotoa.
Teknolojia ya RAD sio ya ulimwengu wote, yaani, matumizi yake haifai kila wakati. Kwa mfano, katika miradi ambapo mahitaji ya bidhaa ya programu zimefafanuliwa kwa uwazi na hazipaswi kubadilika, ushiriki wa mteja katika mchakato wa maendeleo hauhitajiki, na maendeleo ya kihierarkia (njia ya kuteleza) inaweza kuwa na ufanisi zaidi. Vile vile hutumika kwa miradi, programu, utata ambao umeamua na haja ya kutekeleza algorithms ngumu, na jukumu na kiasi kiolesura cha mtumiaji ndogo.
Kielelezo 1 - Ulinganisho wa njia ya RAD na Cascade
