Skip to main content
Query

10.2: Mzunguko wa Maendeleo ya Maendeleo ya Mifumo (SDLC)

  • Page ID
    164890
  • \( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \) \( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)\(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\) \(\newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\) \( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\) \( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\) \( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\) \( \newcommand{\Span}{\mathrm{span}}\)\(\newcommand{\AA}{\unicode[.8,0]{x212B}}\)

    Mzunguko wa Maendeleo ya Maisha ya Mifumo (SDLC)

    SDLC ilianzishwa kwanza katika miaka ya 1960 ili kusimamia miradi mikubwa inayohusishwa na mifumo ya ushirika inayoendesha kwenye mainframes. Ni mchakato wa muundo sana iliyoundwa kusimamia miradi mikubwa na jitihada za watu wengi, ikiwa ni pamoja na wataalamu wa kiufundi, biashara, msaada. Miradi hii mara nyingi huwa na gharama kubwa ya kujenga, na ina athari kubwa kwa shirika. Mradi ulioshindwa au uamuzi usio sahihi wa biashara ya kuchukua mradi usiofaa wa kufadhili unaweza kuwa biashara au janga la kifedha kwa shirika.

    SDLC ni mfano unaofafanua mchakato wa seti ya awamu za kupanga, uchambuzi, kubuni, utekelezaji, matengenezo. Sura ya 1 inazungumzia kwamba mfumo wa habari (IS) unajumuisha vifaa, programu, database, mitandao, mchakato, na watu. SDLC imetumika mara nyingi kusimamia mradi wa IS ambao unaweza kujumuisha moja, baadhi, au mambo yote ya IS. Hebu tembee kupitia kila awamu tano za SDLC kama ilivyoonyeshwa kwenye Mchoro 10.1:

    Awamu tano na mshale unaozungumzia awamu inayofuata kuanzia na Mipango, Uchambuzi, Design, Utekelezaji, Matengenezo
    Kielelezo 10.1 - Mfano wa Maendeleo ya Maendeleo ya Programu. Picha na Ly-Huong Pham, Ph.D. ni leseni chini ya CC BY NC
    1. Kupanga. Katika awamu hii, ombi linaanzishwa na mtu anayefanya kazi kama mdhamini kwa wazo hili. Timu ndogo imekusanyika kufanya tathmini ya awali ya sifa ya ombi na uwezekano. Malengo ya awamu hii ni:
    • Kuamua jinsi ombi inafaa na mkakati wa kampuni au malengo ya biashara.
    • Kufanya uchambuzi wa uwezekano, unaojumuisha uchambuzi wa uwezekano wa kiufundi (inawezekana kuunda hii?) , uwezekano wa kiuchumi (tunaweza kumudu kufanya hivyo?) , na uwezekano wa kisheria (je, sisi kuruhusiwa kufanya hivyo?).
    • Kupendekeza kwenda/hakuna kwenda kwa ombi. Ikiwa ni kwenda, basi pendekezo la dhana pia linazalishwa kwa usimamizi wa kupitisha.
    1. Uchambuzi. Mara pendekezo la dhana linapoidhinishwa, mradi huo umewekwa rasmi na timu mpya ya mradi (ikiwa ni pamoja na awamu ya awali). Kutumia pendekezo la dhana kama hatua ya mwanzo, wanachama wa mradi wanafanya kazi na vikundi tofauti vya wadau ili kuamua mahitaji maalum ya mfumo mpya. Hakuna programu au maendeleo yanayofanyika katika hatua hii. Malengo ya awamu hii ni:
    • Kutambua na Mahojiano wadau muhimu.
    • Document taratibu muhimu
    • Kuendeleza mahitaji ya data
    • Ili kuzalisha hati ya mahitaji ya mfumo kama matokeo ya awamu hii. Hii ina maelezo ya kuanza muundo wa mfumo.
    1. Kubuni. Mara baada ya mahitaji ya mfumo kupitishwa, timu inaweza kuwa reconfigured kuleta wanachama zaidi. Awamu hii inalenga timu ya mradi kuchukua hati ya mahitaji ya mfumo iliyoundwa katika awamu ya awali na kuendeleza maelezo maalum ya kiufundi yanayotakiwa kwa mfumo. Malengo ni:
    • Tafsiri mahitaji ya biashara katika mahitaji maalum ya kiufundi
    • Tengeneza interface ya mtumiaji, database, pembejeo za data na matokeo, na ripoti
    • Kuzalisha hati ya kubuni mfumo kama matokeo ya awamu hii. Hati hii itakuwa na kila kitu ambacho programu itahitaji kuunda mfumo.
    1. Utekelezaji. Mara baada ya kubuni mfumo kupitishwa, msimbo wa programu hatimaye huandikwa katika awamu ya programu, na jitihada za maendeleo kwa vipengele vingine kama vile vifaa pia hutokea. Kusudi ni kujenga mfumo wa awali wa kazi. Malengo ni:
    • Kuendeleza msimbo wa programu, na vipengele vingine vya IS. Kutumia hati ya mfumo wa kubuni kama mwongozo, watengenezaji wanaanza kuandika au kuendeleza vipengele vyote vya mradi wa IS.
    • Mtihani mfumo wa kazi kupitia mfululizo wa vipimo vya muundo kama vile:
      • Ya kwanza ni mtihani wa kitengo, ambayo huchunguza sehemu za kibinafsi za msimbo kwa makosa au mende.
      • Ifuatayo ni mtihani wa mfumo, ambapo vipengele tofauti vya mfumo vinajaribiwa ili kuhakikisha kuwa wanafanya kazi pamoja vizuri.
      • Hatimaye, mtihani wa kukubalika mtumiaji huwawezesha wale ambao watatumia programu kupima mfumo ili kuhakikisha kwamba inakidhi viwango vyao.
      • Iteratively mtihani marekebisho yoyote tena kushughulikia mende yoyote, makosa, au matatizo kupatikana wakati wa kupima.
      • Treni watumiaji
      • Kutoa nyaraka
      • Fanya mabadiliko muhimu kutoka kwa mfumo wowote uliopita hadi mfumo mpya.
      • Kuzalisha, kwa sababu hiyo, mfumo wa awali wa kazi ambao unakidhi mahitaji yaliyowekwa katika awamu ya uchambuzi na kubuni iliyoandaliwa katika awamu ya kubuni.
    1. Matengenezo. Awamu hii hufanyika mara moja awamu ya utekelezaji imekamilika. Katika awamu hii, mfumo lazima uwe na mchakato wa usaidizi wa muundo mahali pa:
    • Ripoti ya mende
    • Peleka marekebisho ya mdudu
    • Kubali maombi ya vipengele vipya
    • Tathmini vipaumbele vya mende zilizoripotiwa au vipengele vilivyoombwa kutekelezwa
    • Tambua ratiba ya kutabirika na ya kawaida ya kutolewa sasisho za mfumo na kufanya salama.
    • Tupa data na kitu kingine chochote ambacho hakihitaji tena

    Mashirika yanaweza kuchanganya au kugawanya awamu hizi ili kufaa mahitaji yao. Kwa mfano, badala ya awamu moja, Mipango, shirika linaweza kuchagua kuwa na awamu mbili: Kuanzishwa, Dhana; au kugawanya utekelezaji katika awamu mbili: utekelezaji na kupima.

    maporomoko ya maji

    Mfano mmoja maalum wa SDLC ni mfano wa maporomoko ya maji, na jina mara nyingi hufikiriwa kuwa sawa na SDLC. Inatumika kusimamia miradi ya programu kama ilivyoonyeshwa kwenye Kielelezo 10.2 na awamu tano: Mahitaji, Kubuni, Kutekeleza, Uhakikisho, na Matengenezo. Mfano huu unasisitiza kwamba kila awamu inapaswa kukamilika kabla ya ijayo kuanza (kwa hiyo jina la maporomoko ya maji). Kwa mfano, mabadiliko ya mahitaji hayaruhusiwi mara moja awamu ya utekelezaji imeanza, au mabadiliko lazima yatafutwe na kupitishwa kwa mchakato wa mabadiliko. Wanaweza kuhitaji mradi kuanza upya kutoka awamu ya mahitaji tangu mahitaji mapya yanahitaji kupitishwa, ambayo inaweza kusababisha kubuni kurekebishwa kabla ya awamu ya utekelezaji kuanza.

    Masanduku matano yenye mishale inayoelezea awamu inayofuata. sanduku kwanza ni kinachoitwa Mahitaji na mshale wa ziada kwa maandishi, Bidhaa mahitaji hati. Sanduku la pili linaitwa Kubuni na mshale wa ziada kwa maandishi, Usanifu wa Programu. Sanduku la tatu linaitwa Utekelezaji na mshale wa ziada kwa maandishi, Programu. Masanduku mawili yafuatayo ni Uthibitishaji na Matengenezo bila mishale ya ziada.
    Kielelezo 10.2 Maporomoko ya maji Model ya Maendeleo Picha na Peter Kemp/Paul Smit ni leseni CC BY 3.0

    Mfumo wa rigid wa mtindo wa maporomoko ya maji umekosolewa kwa kuwa rigid kabisa na kusababisha timu kuwa hatari-mnachukia ili kuepuka kurudi kwenye awamu zilizopita. Hata hivyo, kuna faida kwa muundo huo pia. Baadhi ya faida na hasara za SDLC na Maporomoko ya maji ni:

    Faida na hasara ya SDLC na Maporomoko ya maji

    Faida

    Hasara

    Mchakato thabiti wa kudhibiti na kufuatilia mabadiliko ili kupunguza idadi ya hatari unaweza kufuta mradi bila kujua.

    Chukua muda wa kurekodi kila kitu, kinachoongoza kwa gharama za ziada na wakati wa ratiba.

    Michakato ya kawaida na ya uwazi husaidia usimamizi wa timu kubwa.

    Muda mwingi uliotumiwa kuhudhuria mikutano, kutafuta idhini, nk. ambayo husababisha gharama za ziada na wakati wa ratiba.

    Nyaraka hupunguza hatari za kupoteza wafanyakazi, rahisi kuongeza watu kwenye mradi huo.

    Wanachama wengine hawapendi kutumia muda kuandika, na kusababisha muda wa ziada unahitajika kukamilisha mradi.

    Rahisi kufuatilia tatizo katika mfumo kwa mizizi yake wakati wowote makosa yanapatikana, hata baada ya mradi kukamilika.

    Ni vigumu kuingiza mabadiliko au maoni ya wateja tangu mradi unapaswa kurudi kwenye awamu moja au zaidi ya awali, na kuongoza timu kuwa hatari ya kupuuza.

    Mifano nyingine hutengenezwa baada ya muda ili kushughulikia ukosoaji huu. Tutajadili mifano mingine miwili: Maendeleo ya Maombi ya haraka na Agile, kama mbinu tofauti za SDLC.

    Maendeleo ya Maombi ya haraka (RAD)

    Maendeleo ya haraka ya maombi (RAD) ni maendeleo ya programu (au mifumo-maendeleo) mbinu ambayo inalenga chini katika kupanga na kuchanganya mabadiliko kwa misingi inayoendelea. RAD inalenga katika kujenga haraka mfano wa kazi wa programu au mfumo, kupata maoni kutoka kwa watumiaji, na uppdatering mfano wa kazi. Baada ya iterations kadhaa ya maendeleo, toleo la mwisho linatengenezwa na kutekelezwa. Hebu tembee kupitia awamu nne katika mfano wa RAD kama ilivyoonyeshwa kwenye Mchoro 10.3.

    mduara na maandishi Mahitaji ya Mipango ina mshale kwa duru mbili, User kubuni na ujenzi. Hizi duru mbili ina mishale kuonyesha kwamba ni awamu iterative, na mshale kwa uhakika mduara wa mwisho Kata Over.
    Kielelezo 10.3 Image Rapid Maombi Maendeleo Model ni leseni uwanja wa umma.
    1. Mahitaji ya Mipango. Awamu hii ni sawa na mipango, uchambuzi, na awamu ya kubuni ya SDLC.
    2. User Design. Katika awamu hii, wawakilishi wa watumiaji hufanya kazi na wachambuzi wa mfumo, wabunifu, na waandaaji ili kuunda muundo wa mfumo. Mbinu moja ya kufanya kazi na wadau hawa wote ni kikao cha Maendeleo ya Maombi ya Pamoja (JAD). Kipindi cha JAD kinapata watumiaji wote wanaohusika wanaoingiliana na mifumo kutoka mitazamo tofauti, wadau wengine muhimu, ikiwa ni pamoja na watengenezaji, kuwa na majadiliano ya muundo kuhusu muundo wa mfumo. Malengo ni kwa watumiaji kuelewa na kupitisha mfano wa kazi na kwa watengenezaji kuelewa jinsi mfumo unahitaji kufanya kazi kwa mtazamo wa mtumiaji kutoa uzoefu mzuri wa mtumiaji.
    3. Ujenzi. Katika awamu ya ujenzi, kazi ni sawa na awamu ya utekelezaji wa SDLC. Waendelezaji wanaendelea kufanya kazi kwa uingiliano na watumiaji kuingiza maoni yao wanapoingiliana na mfano wa kazi unaoendelezwa. Huu ni mchakato wa maingiliano, na mabadiliko yanaweza kufanywa kama watengenezaji wanafanya kazi kwenye programu. Hatua hii inafanywa sambamba na hatua ya User Design kwa mtindo wa iterative mpaka toleo la kukubalika la bidhaa limeendelezwa.
    4. Cutover. Hatua hii ni sawa na baadhi ya kazi za awamu ya utekelezaji wa SDLC. Mfumo unaendelea kuishi au unatumika kikamilifu. Hatua zote zinazohitajika kuhamia kutoka hali ya awali hadi kutumia mfumo mpya zimekamilika hapa.

    Ikilinganishwa na mfano wa SDLC au Maporomoko ya maji, mbinu ya RAD imesisitizwa zaidi. Hatua nyingi za SDLC zimeunganishwa, na lengo ni ushiriki wa mtumiaji na iteration. Njia hii inafaa zaidi kwa miradi midogo na ina faida iliyoongezwa ya kuwapa watumiaji uwezo wa kutoa maoni katika mchakato. SDLC inahitaji nyaraka zaidi na makini kwa undani na inafaa kwa miradi mikubwa, yenye nguvu ya rasilimali. RAD inafaa zaidi kwa miradi ambayo ni chini ya rasilimali kubwa na inahitaji kuendelezwa haraka. Hapa ni baadhi ya faida na hasara za RAD:

    Faida na Hasara ya RAD

    Faida

    Hasara

    Ongeza ubora kutokana na mzunguko wa kuingiliana na watumiaji

    Hatari za utekelezaji dhaifu wa vipengele ambavyo hazionekani kwa watumiaji, kama vile usalama

    Kupunguza hatari ya kukataa watumiaji kukubali bidhaa ya kumaliza

    Ukosefu wa udhibiti wa mabadiliko ya mfumo kutokana na kugeuka kwa haraka kwa toleo la kazi ili kushughulikia masuala ya watumiaji.

    Kuboresha nafasi ya wakati, juu ya bajeti kukamilika kama watumiaji update katika muda halisi, kuepuka mshangao wakati wa maendeleo.

    Ukosefu wa kubuni tangu mabadiliko yanawekwa katika mfumo inaweza kutojua kuathiri sehemu nyingine za mfumo.

    Kuongeza muda wa mwingiliano kati ya watengenezaji/wataalam na watumiaji

    Rasilimali zisizo na uwezo kama watengenezaji zimefungwa, ambazo zinaweza kupunguza kasi ya miradi mingine.

    Bora zaidi kwa timu ndogo za mradi wa ukubwa

    Vigumu kuongeza hadi timu kubwa

    Mbinu za Maendeleo ya Agile

    Mbinu za agile ni kundi la mbinu zinazotumia mabadiliko ya Unaozidi kulenga ubora na tahadhari kwa undani. Kila nyongeza hutolewa katika kipindi maalum cha muda (kinachoitwa sanduku la wakati), na kuunda ratiba ya kutolewa mara kwa mara na malengo fulani. Wakati kuchukuliwa mbinu tofauti kutoka RAD, wao kushiriki baadhi ya kanuni sawa: maendeleo iterative, user mwingiliano, na mabadiliko. Mbinu za agile zinategemea “Agile Manifesto,” iliyotolewa kwanza mwaka 2001.

    Tabia za mbinu za agile ni pamoja na:

    • timu ndogo za msalaba ambazo zinajumuisha wanachama wa timu ya maendeleo na watumiaji;
    • mikutano ya hali ya kila siku ili kujadili hali ya sasa ya mradi huo;
    • nyongeza za muda mfupi (kutoka siku hadi wiki moja au mbili) kwa kila mabadiliko kukamilika; na
    • Mwishoni mwa kila iteration, mradi wa kazi umekamilika kuonyesha kwa wadau.

    Kwa asili, mbinu ya Agile inaweka thamani ya juu juu ya kazi zinazoendeleza mwingiliano, kujenga matoleo ya mara kwa mara ya kazi, ushirikiano wa wateja/mtumiaji, na majibu ya haraka ya mabadiliko na msisitizo mdogo juu ya taratibu na nyaraka. Lengo la mbinu za agile ni kutoa kubadilika kwa njia ya iterative wakati wa kuhakikisha bidhaa bora.

    Kuna aina mbalimbali za mifano ambazo zimejengwa kwa kutumia mbinu za Agile. Mfano mmoja ni mfano wa maendeleo ya Scrum.

    Mfano wa maendeleo ya Scrum

    Mfano huu unafaa kwa timu ndogo zinazofanya kazi ili kuzalisha seti ya vipengele ndani ya mwingiliano wa muda mfupi, kama vile wiki mbili hadi nne, inayoitwa sprints. Hebu tembee kupitia vipengele vinne muhimu vya mfano wa Scrum kama ilivyoonyeshwa kwenye Mchoro 10.4.

    Picha nne na mshale akizungumzia moja ijayo, kuanzia na backlog ya Bidhaa, Spring backlog, Sprint, na Kazi ya ziada ya programu. 

Picha ya Spring imejumuisha mduara mkubwa na maandiko siku 30, na mduara mdogo na maandishi 24h

    Kielelezo 10.4. Njia ya usimamizi wa mradi wa Scrum. Picha na Lakeworks ni leseni CC BY-SA 4.0

    1. Bidhaa backlog. Hii ni orodha ya kina ya kuvunjika kwa kazi inayofanyika. Kazi yote ni kipaumbele kulingana na vigezo kama vile hatari, maelewano, utume-muhimu, nk Waendelezaji kuchagua kazi zao wenyewe na kujitegemea kuandaa ili kufanya kazi.
    2. Sprint backlog. Hii ni orodha ya kazi inayofanyika katika sprint ijayo.
    3. Mbio mbio. Huu ni wakati uliowekwa, kama siku 1, wiki 2, au wiki 4, kama ilivyokubaliwa na timu. Mkutano wa maendeleo ya kila siku unaitwa scrum ya kila siku, kwa kawaida mkutano mfupi wa dakika 10-15 unaowezeshwa na bwana wa scrum ambaye jukumu lake ni kuondoa vizuizi vya barabara kwa timu.
    4. Kazi nyongeza ya programu e. Hii ni toleo la kazi ambalo linazidi kujengwa na orodha za kuvunjika mwishoni mwa sprints.

    Lean Mbinu

    Njia moja ya mwisho tutakayojadili ni dhana mpya iliyochukuliwa kutoka kwa biashara bora ya biashara The Lean Startup, na Eric Reis.

    3 kubwa ya bluu duru kwa maneno kujenga, kupima na kujifunza kwa mishale inayoongoza kutoka kujenga kupima kujifunza na kurudi tena kujenga moja pink mduara kati ya kila jozi ya mduara wa bluu na kanuni maneno, data, mawazo
    Kielelezo 10.5. Mbinu Lean. David T. Bourgeois, Ph.D. ni leseni CC BY-SA 2.0

    Njia hii inalenga katika kuchukua wazo la awali na kuendeleza bidhaa ndogo inayofaa (MVP). MVP ni programu ya programu ya kazi na utendaji wa kutosha ili kuonyesha wazo nyuma ya mradi huo. Mara MVP inapoanzishwa, hutolewa kwa watumiaji wenye uwezo wa mapitio. Maoni juu ya MVP yanayotokana katika aina mbili: (1) uchunguzi wa moja kwa moja na majadiliano na watumiaji, na (2) takwimu za matumizi zilizokusanywa kutoka programu yenyewe. Kutumia aina hizi mbili za maoni, timu huamua kama wanapaswa kuendelea katika mwelekeo huo au kufikiri upya wazo la msingi la mradi, kubadilisha kazi, au kuunda MVP mpya. Mabadiliko haya katika mkakati inaitwa egemeo. Mabadiliko kadhaa ya MVP yanatengenezwa, na kazi mpya zinaongezwa kila wakati kulingana na maoni, mpaka bidhaa ya mwisho imekamilika.

    Tofauti kubwa kati ya mbinu konda na mbinu nyingine ni kwamba mfumo kamili seti ya mahitaji haijulikani wakati mradi ni ilizinduliwa. Kama kila iteration ya mradi hutolewa, takwimu na maoni yaliyokusanywa hutumiwa kuamua mahitaji. Njia ya konda inafanya kazi bora katika mazingira ya ujasiriamali ambapo kampuni ina nia ya kuamua kama wazo lao la programu ya programu linafaa kuendeleza.

    Marejeo:

    Ilani ya Maendeleo ya Programu ya Agile (2001). Iliondolewa Desemba 10, 2020, kutoka http://agilemanifesto.org/

    Startup Lean. Ilirudishwa mnamo Desemba 9, 2020, kutoka http://theleanstartup.com/