Programmatūras izstrādes dzīves cikls (SDLC) ir projektu vadībā izmantots garīgais modelis, kas nosaka informācijas sistēmas izstrādes projektā iekļautos posmus no sākotnējās priekšizpētes līdz pabeigtas lietojumprogrammas uzturēšanai.

Ir dažādi programmatūras izstrādes dzīves cikla modeļi, kurus nosaka un izstrādā, kas tiek ievēroti programmatūras izstrādes posmā. Šos modeļus sauc arī par ' Programmatūras izstrādes procesu modeļi .' Katrs procesa modelis seko fāzes sērijai, kas ir unikāla tā veidam, lai nodrošinātu panākumus programmatūras izstrādes posmā.

virkne līdz veselam skaitlim Java

Šeit ir daži svarīgi SDLC dzīves cikla posmi:

Ūdenskrituma modelis

Ūdenskritums ir vispārpieņemts SDLC modelis. Izmantojot šo metodi, viss programmatūras izstrādes process ir sadalīts dažādās fāzēs.

Ūdenskrituma modelis ir nepārtrauktas programmatūras izstrādes modelis, kurā attīstība tiek uzskatīta par vienmērīgu lejupvērstu (piemēram, ūdenskritumu), veicot prasību analīzes, projektēšanas, ieviešanas, testēšanas (validācijas), integrācijas un uzturēšanas posmus.

Lineārai darbību secībai ir dažas būtiskas sekas. Pirmkārt, lai noteiktu fāzes beigas un nākamās sākumu, katra posma beigās ir jāizmanto daži sertifikācijas paņēmieni. Dažas verifikācijas un validācijas parasti nozīmē, ka tiks nodrošināts, ka posma izvade atbilst tās ievadei (kas ir iepriekšējā posma izvade) un ka posma izvade atbilst sistēmas vispārējām prasībām.

RAD modelis

RAD jeb Rapid Application Development process ir ūdenskrituma modeļa pieņemšana; tā mērķis ir izstrādāt programmatūru īsā laika posmā. RAD modeļa pamatā ir koncepcija, ka labāku sistēmu var izstrādāt īsākā laikā, izmantojot fokusa grupas, lai apkopotu sistēmas prasības.

• Biznesa modelēšana
• Datu modelēšana
• Procesu modelēšana
• Lietojumprogrammu ģenerēšana
• Testēšana un apgrozījums

Spirālveida modelis

Spirālveida modelis ir a uz risku orientēts procesa modelis . Šis SDLC modelis palīdz grupai pieņemt viena vai vairāku procesa modeļu elementus, piemēram, ūdenskritumu, inkrementālo, ūdenskritumu utt. Spirālveida tehnika ir ātras prototipēšanas un dizaina un izstrādes darbību vienlaicības kombinācija.

Katrs spirāles cikls sākas ar šī cikla mērķu noteikšanu, dažādām alternatīvām, kas ir iespējamas mērķu sasniegšanai, un pastāvošajiem ierobežojumiem. Šis ir cikla pirmais kvadrants (augšējais kreisais kvadrants).

Nākamais cikla posms ir šo dažādo alternatīvu novērtēšana, pamatojoties uz mērķiem un ierobežojumiem. Šajā posmā vērtēšanas uzmanības centrā ir projekta riska uztvere.

Nākamais solis ir izstrādāt stratēģijas, kas atrisina neskaidrības un riskus. Šis solis var ietvert tādas darbības kā salīdzinošā novērtēšana, simulācija un prototipu izstrāde.

V-modelis

Šāda veida SDLC modeļa testēšanā un izstrādē solis tiek plānots paralēli. Tātad sānos ir verifikācijas fāzes, bet otrā pusē - apstiprināšanas fāze. V-Model pievienojas kodēšanas fāzē.

Inkrementālais modelis

Inkrementālais modelis nav atsevišķs modelis. Tas noteikti ir ūdenskrituma ciklu sērija. Projekta sākumā prasības tiek sadalītas grupās. Katrai grupai programmatūras izstrādei tiek izmantots SDLC modelis. SDLC process tiek atkārtots, ar katru laidienu pievienojot vairāk funkcionalitātes, līdz tiek izpildītas visas prasības. Izmantojot šo metodi, katrs cikls darbojas kā iepriekšējā programmatūras laidiena uzturēšanas fāze. Inkrementālā modeļa modifikācija ļauj izstrādes cikliem pārklāties. Pēc šī nākamā cikla var sākties pirms iepriekšējā cikla pabeigšanas.

sapludināt kārtot java

Veikls modelis

Agile metodoloģija ir prakse, kas veicina nepārtrauktu izstrādes un testēšanas mijiedarbību jebkura projekta SDLC procesa laikā. Izmantojot Agile metodi, viss projekts ir sadalīts mazos pakāpeniskos veidojumos. Visas šīs versijas tiek nodrošinātas iterācijās, un katra iterācija ilgst no vienas līdz trim nedēļām.

Jebkurš veikls programmatūras posms tiek raksturots tādā veidā, kas attiecas uz vairākiem galvenajiem pieņēmumiem par lielāko programmatūras projektu daļu:

1. Ir grūti iepriekš domāt, kuras programmatūras prasības saglabāsies un kuras mainīsies. Tikpat grūti ir prognozēt, kā mainīsies lietotāju prioritātes, projektam turpinoties.
2. Daudziem programmatūras veidiem dizains un izstrāde ir savstarpēji saistīti. Tas ir, abas darbības jāveic vienlaikus, lai dizaina modeļi tiktu pārbaudīti to izveides laikā. Ir grūti domāt par to, cik daudz dizaina ir nepieciešams, pirms tiek izmantota konstrukcija, lai pārbaudītu konfigurāciju.
3. Analīze, projektēšana, izstrāde un testēšana nav tik paredzama (no plānošanas viedokļa), kā mēs varētu vēlētos.

Iteratīvais modelis

Tā ir īpaša programmatūras izstrādes dzīves cikla ieviešana, kas koncentrējas uz sākotnējo, vienkāršotu ieviešanu, kas pēc tam pakāpeniski kļūst sarežģītāka un plašāka funkciju kopa, līdz tiek pabeigta galīgā sistēma. Īsāk sakot, iteratīvā izstrāde ir veids, kā lielas lietojumprogrammas programmatūras izstrādi sadalīt mazākos gabalos.

Lielā sprādziena modelis

Lielā sprādziena modelis koncentrējas uz visu veidu resursiem programmatūras izstrādē un kodēšanā, bez plānošanas vai ļoti maz. Prasības tiek saprastas un īstenotas, kad tās nāk.

Šis modelis vislabāk darbojas maziem projektiem ar mazāku izstrādes komandu, kas strādā kopā. Tas ir noderīgi arī akadēmiskos programmatūras izstrādes projektos. Tas ir ideāls modelis, kur prasības nav zināmas vai galīgais izlaišanas datums nav norādīts.

Prototipa modelis

Prototipu izstrādes modelis sākas ar prasību apkopošanu. Izstrādātājs un lietotājs satiekas un definē programmatūras mērķi, identificē vajadzības utt.

A ' ātrs dizains Pēc tam tiek izveidots. Šis dizains koncentrējas uz tiem programmatūras aspektiem, kas būs redzami lietotājam. Pēc tam tas noved pie prototipa izstrādes. Pēc tam klients pārbauda prototipu un tiek veiktas visas nepieciešamās izmaiņas vai izmaiņas.

Šajā solī notiek cilpa, un tiek izveidotas labākas prototipa versijas. Tie tiek nepārtraukti rādīti lietotājam, lai visas jaunas izmaiņas varētu atjaunināt prototipā. Šis process turpinās, līdz klients ir apmierināts ar sistēmu. Kad lietotājs ir apmierināts, prototips tiek pārveidots par faktisko sistēmu, ievērojot visus kvalitātes un drošības apsvērumus.