Software Development Lifecycle (SDLC) on projektinhallinnassa käytetty henkinen malli, joka määrittelee tietojärjestelmän kehitysprojektin vaiheet alustavasta kannattavuustutkimuksesta valmiin sovelluksen ylläpitoon.

Ohjelmiston kehitystyön elinkaarimalleja määritellään ja suunnitellaan erilaisia, joita noudatetaan ohjelmistokehitysvaiheessa. Näitä malleja kutsutaan myös ' Ohjelmistokehitysprosessimallit .' Jokainen prosessimalli seuraa tyypiltään ainutlaatuista vaihesarjaa varmistaakseen onnistumisen ohjelmistokehitysvaiheessa.

Tässä on joitain SDLC:n elinkaaren tärkeitä vaiheita:

Vesiputous malli

Vesiputous on yleisesti hyväksytty SDLC-malli. Tässä menetelmässä koko ohjelmistokehitysprosessi on jaettu eri vaiheisiin.

Vesiputousmalli on jatkuva ohjelmistokehitysmalli, jossa kehityksen nähdään jatkuvan alaspäin (kuten vesiputous) vaatimusanalyysin, suunnittelun, toteutuksen, testauksen (validoinnin), integroinnin ja ylläpidon vaiheiden kautta.

Lineaarisella toimintojen järjestyksellä on joitain merkittäviä seurauksia. Ensinnäkin vaiheen lopun ja seuraavan alun tunnistamiseksi jokaisen vaiheen lopussa on käytettävä joitain sertifiointitekniikoita. Jotkut tarkastukset ja validointi yleensä tarkoittavat tätä, mikä varmistaa, että vaiheen lähtö on yhdenmukainen sen syötteen kanssa (joka on edellisen vaiheen lähtö) ja että vaiheen lähtö on yhdenmukainen järjestelmän yleisten vaatimusten kanssa.

RAD malli

RAD tai Rapid Application Development -prosessi on vesiputousmallin omaksuminen; se tähtää ohjelmistojen kehittämiseen lyhyessä ajassa. RAD-malli perustuu ajatukseen, että parempi järjestelmä voidaan kehittää lyhyemmässä ajassa käyttämällä kohderyhmiä järjestelmävaatimusten keräämiseen.

linux run -komento

• Liiketoiminnan mallinnus
• Tietojen mallinnus
• Prosessin mallinnus
• Sovellusten sukupolvi
• Testaus ja liikevaihto

Spiraali malli

Spiraalimalli on a riskilähtöinen prosessimalli . Tämä SDLC-malli auttaa ryhmää ottamaan käyttöön elementtejä yhdestä tai useammasta prosessimallista, kuten vesiputous, inkrementaalinen, vesiputous jne. Spiraalitekniikka on yhdistelmä nopeaa prototyyppien luomista ja suunnittelu- ja kehitystoimintojen samanaikaisuutta.

Jokainen kierteen sykli alkaa syklin tavoitteiden, tavoitteiden saavuttamisen mahdollisten eri vaihtoehtojen ja olemassa olevien rajoitteiden tunnistamisella. Tämä on syklin ensimmäinen neljännes (vasen ylempi kvadrantti).

Seuraava vaihe syklissä on näiden eri vaihtoehtojen arviointi tavoitteiden ja rajoitusten perusteella. Arvioinnin painopiste tässä vaiheessa perustuu hankkeen riskinäkemykseen.

Seuraava askel on kehittää strategioita, jotka ratkaisevat epävarmuustekijät ja riskit. Tämä vaihe voi sisältää toimintoja, kuten esikuva-analyysiä, simulointia ja prototyyppien luomista.

V-malli

Tämän tyyppisessä SDLC-mallin testauksessa ja kehittämisessä vaihe suunnitellaan rinnakkain. Joten toisella puolella on varmennusvaihe ja toisella puolella validointivaihe. V-Model liittyy koodausvaiheeseen.

Inkrementaalinen malli

Inkrementaalinen malli ei ole erillinen malli. Se on välttämättä sarja vesiputousjaksoja. Vaatimukset jaetaan ryhmiin projektin alussa. Jokaiselle ryhmälle noudatetaan SDLC-mallia ohjelmistojen kehittämisessä. SDLC-prosessi toistetaan, ja jokainen julkaisu lisää toimintoja, kunnes kaikki vaatimukset täyttyvät. Tässä menetelmässä jokainen sykli toimii edellisen ohjelmistojulkaisun ylläpitovaiheena. Muutos inkrementtimalliin mahdollistaa kehityssyklien päällekkäisyyden. Tämän jälkeen seuraava sykli voi alkaa ennen kuin edellinen jakso on valmis.

Ketterä malli

Ketterä metodologia on käytäntö, joka edistää jatkuvaa kehittämisen ja testauksen vuorovaikutusta minkä tahansa projektin SDLC-prosessin aikana. Agile-menetelmässä koko projekti jaetaan pieniin inkrementaalisiin rakenteisiin. Kaikki nämä koontiversiot tarjotaan iteraatioina, ja jokainen iteraatio kestää yhdestä kolmeen viikkoa.

Mikä tahansa ketterä ohjelmistovaihe on luonnehdittu tavalla, joka vastaa useisiin keskeisiin oletuksiin suurimmasta osasta ohjelmistoprojekteista:

1. On vaikea ajatella etukäteen, mitkä ohjelmistovaatimukset säilyvät ja mitkä muuttuvat. Yhtä vaikeaa on ennustaa, kuinka käyttäjien prioriteetit muuttuvat projektin edetessä.
2. Monen tyyppisissä ohjelmistoissa suunnittelu ja kehitys ovat limittäisiä. Toisin sanoen molemmat toiminnot tulisi suorittaa rinnakkain, jotta suunnittelumallit todistetaan niitä luotaessa. On vaikea ajatella, kuinka paljon suunnittelua tarvitaan ennen kuin konfiguraatiota testataan rakentamalla.
3. Analyysi, suunnittelu, kehitys ja testaus eivät ole niin ennustettavissa (suunnittelun näkökulmasta) kuin haluaisimme.

Iteratiivinen malli

Se on ohjelmistokehityksen elinkaaren erityinen toteutus, joka keskittyy alkuperäiseen, yksinkertaistettuun toteutukseen, joka sitten muuttuu asteittain monimutkaisemmiksi ja laajemmiksi, kunnes lopullinen järjestelmä on valmis. Lyhyesti sanottuna iteratiivinen kehitys on tapa hajottaa suuren sovelluksen ohjelmistokehitys pienempiin osiin.

Big bang malli

Big bang -malli keskittyy kaikenlaisiin resursseihin ohjelmistokehityksessä ja koodauksessa ilman suunnittelua tai se on hyvin vähän. Vaatimukset ymmärretään ja toteutetaan, kun ne tulevat.

Tämä malli toimii parhaiten pienissä projekteissa, joissa on pienempi kokoinen kehitystiimi, joka työskentelee yhdessä. Se on hyödyllinen myös akateemisissa ohjelmistokehitysprojekteissa. Se on ihanteellinen malli, jossa vaatimuksia ei tunneta tai lopullista julkaisupäivää ei ole annettu.

python-tavut merkkijonoon

Prototyyppi malli

Prototyyppimalli alkaa vaatimusten keräämisellä. Kehittäjä ja käyttäjä kohtaavat ja määrittelevät ohjelmiston tarkoituksen, tunnistavat tarpeet jne.

A ' nopea suunnittelu ' luodaan sitten. Tämä suunnittelu keskittyy niihin ohjelmiston osiin, jotka näkyvät käyttäjälle. Se johtaa sitten prototyypin kehittämiseen. Tämän jälkeen asiakas tarkistaa prototyypin ja prototyyppiin tehdään tarvittavat muutokset tai muutokset.

Tässä vaiheessa tehdään silmukoita, ja prototyypistä luodaan parempia versioita. Näitä näytetään jatkuvasti käyttäjälle, jotta prototyyppiin voidaan päivittää uudet muutokset. Tätä prosessia jatketaan, kunnes asiakas on tyytyväinen järjestelmään. Kun käyttäjä on tyytyväinen, prototyyppi muunnetaan todelliseksi järjestelmäksi kaikkiin laatu- ja turvallisuusnäkökohtiin.