V-malli on eräänlainen SDLC malli jossa prosessi suoritetaan peräkkäin V-muodossa. Se tunnetaan myös Verification and Validation -mallina. Se perustuu kunkin vastaavan kehitysvaiheen testausvaiheen yhdistämiseen. Kunkin vaiheen kehitys liittyy suoraan testausvaiheeseen. Seuraava vaihe alkaa vasta edellisen vaiheen päätyttyä, eli jokaiselle kehitystoiminnalle on sitä vastaava testaustoiminto.

Sisällysluettelo

• V-mallin suunnittelu
• V-mallin merkitys
• V-mallin periaatteet
• Milloin V-mallia käytetään?
• V-mallin edut
• V-mallin huonot puolet
• Johtopäätös

V-Model on ohjelmistokehityksen elinkaarimalli (SDLC), joka tarjoaa systemaattisen ja visuaalisen esityksen ohjelmistokehitysprosessista. Se perustuu ajatukseen V-muodosta, jossa V:n kaksi jalkaa edustavat V:n etenemistä ohjelmistokehitysprosessi alkaen vaatimusten kerääminen ja analyysi suunnitteluun, toteutukseen, testaukseen ja ylläpitoon.

perintö javassa

V-mallin suunnittelu

1. Vaatimusten kerääminen ja analysointi : V-mallin ensimmäinen vaihe on vaatimusten keräämis- ja analysointivaihe, jossa asiakkaan ohjelmistovaatimukset kootaan ja analysoidaan projektin laajuuden määrittämiseksi.
2. Design: Suunnitteluvaiheessa kehitetään ohjelmistoarkkitehtuuria ja suunnittelua, mukaan lukien korkeatasoinen suunnittelu ja yksityiskohtainen suunnittelu.
3. Toteutus: Toteutusvaiheessa ohjelmisto rakennetaan suunnittelun pohjalta.
4. Testaus: Testausvaiheessa ohjelmisto testataan sen varmistamiseksi, että se vastaa asiakkaan vaatimuksia ja on laadukas.
5. Käyttöönotto: Käyttöönottovaiheessa ohjelmisto otetaan käyttöön ja otetaan käyttöön.
6. Huolto: Ylläpitovaiheessa ohjelmistoa ylläpidetään niin, että se vastaa jatkossakin asiakkaan tarpeita ja odotuksia.
7. V-mallia käytetään usein turvallisuuteen: kriittiset järjestelmät, kuten ilmailu- ja puolustusjärjestelmät, koska se painottaa perusteellista testausta ja sen kykyä määritellä selkeästi ohjelmistokehitysprosessin vaiheet.

SDLC V-malli

Seuraava kuva esittää SDLC:n V-mallin eri vaiheita.

Todentaminen Vaiheet :

Se sisältää staattisen analyysitekniikan (tarkistus), joka tehdään ilman koodin suorittamista. Se on tuotekehitysvaiheen arviointiprosessi sen selvittämiseksi, täyttyvätkö tietyt vaatimukset.

V-mallissa on useita vahvistusvaiheita:

Liiketoiminnan vaatimusten analyysi:

Tämä on ensimmäinen vaihe kehityssyklin määrittämisessä, jossa tuotteen vaatimus tulee parantaa asiakkaan näkökulmasta. Näihin vaiheisiin sisältyy asianmukainen viestintä asiakkaan kanssa asiakkaiden vaatimusten ymmärtämiseksi. Nämä ovat erittäin tärkeitä toimintoja, jotka on hoidettava oikein, koska useimmiten asiakkaat eivät tiedä tarkalleen mitä haluavat, eivätkä he ole varmoja siitä silloin, jolloin käytämme hyväksyntätestin suunnittelu suunnittelua, joka tehdään liiketoiminnan vaatimuksen aikaan, sitä käytetään syöttö hyväksymistestausta varten.

mysql jätti liittymään

Järjestelmäsuunnittelu:

Järjestelmän suunnittelu alkaa, kun yleisesti olemme selvillä tuotteen vaatimuksista, ja sitten on suunniteltava järjestelmä kokonaan. Tämä ymmärrys valmistuu tuotekehitysprosessin alussa. näistä on hyötyä testitapausten tulevaa suorittamista varten.

Arkkitehtoninen suunnittelu:

Tässä vaiheessa arkkitehtoniset eritelmät ymmärretään ja suunnitellaan. Yleensä esitetään useita teknisiä lähestymistapoja, ja lopullinen valinta tehdään tarkasteltaessa sekä teknistä että taloudellista kannattavuutta. Järjestelmäarkkitehtuuri on edelleen jaettu moduuleihin, joista jokainen hoitaa erillisen toiminnon. Toinen nimi tälle on High-Level Design (HLD).

Tässä vaiheessa sisäisten moduulien ja ulkoisten järjestelmien välinen tiedonvaihto ja viestintä on hyvin ymmärretty ja määritelty. Tässä vaiheessa integraatiotestejä voidaan luoda ja dokumentoida annettujen tietojen avulla.

Moduulin suunnittelu:

Tämä vaihe, joka tunnetaan nimellä Low-Level Design (LLD), määrittää kattavan sisäisen suunnittelun jokaiselle järjestelmämoduulille. Suunnittelun ja muiden ulkoisten järjestelmien sekä muiden järjestelmäarkkitehtuurin moduulien yhteensopivuus on ratkaisevan tärkeää. Yksikkötestit ovat olennainen osa kehitysprosessia, koska ne auttavat tunnistamaan ja poistamaan suurimman osan virheistä ja puutteista varhaisessa vaiheessa. Nämä yksikkötestit voidaan nyt luoda sisäisten moduulisuunnitelmien perusteella.

Koodausvaihe:

Koodausvaihe sisältää koodin kirjoittamisen suunnitteluvaiheessa luoduille järjestelmämoduuleille. Järjestelmä- ja arkkitehtuurivaatimuksia käytetään määrittämään, mikä ohjelmointikieli on sopivin.

Koodauksessa noudatetaan koodausstandardeja ja -periaatteita. Ennen kuin lopullinen koontiversio tarkistetaan arkistoon, koodi käy läpi useita kooditarkastuksia ja optimoidaan optimaalista suorituskykyä varten.

Validointi Vaiheet :

Se sisältää dynaamisia analyysitekniikoita (toiminnallisia ja ei-toiminnallisia) ja testausta suorittamalla koodia. Validointi on prosessi, jossa ohjelmisto arvioidaan kehitysvaiheen päätyttyä sen määrittämiseksi, vastaako ohjelmisto asiakkaan odotuksia ja vaatimuksia.

rj12 vs rj11

Joten V-malli sisältää todentamisvaiheet toisella puolella validointivaiheet toisella puolella. Varmennus- ja validointivaiheet yhdistetään koodausvaiheella V-muotoon. Siksi sitä kutsutaan V-malliksi.
On useita Validointi vaiheet V-mallissa:

Yksikkötestaus:

Yksikkötestaussuunnitelmat kehitetään moduulin suunnitteluvaiheessa. Nämä yksikkötestisuunnitelmat suoritetaan koodin tai yksikön tason virheiden poistamiseksi.

Integraatiotestaus:

Yksikkötestauksen päätyttyä suoritetaan integrointitestaus. Integraatiotestauksessa moduulit integroidaan ja järjestelmä testataan. Integrointitestaus suoritetaan arkkitehtuurin suunnitteluvaiheessa. Tämä testi varmistaa moduulien välisen viestinnän.

Järjestelmän testaus:

Järjestelmätestaus testaa koko sovelluksen sen toimivuuden, keskinäisen riippuvuuden ja kommunikoinnin kanssa. Se testaa kehitetyn sovelluksen toiminnallisia ja ei-toiminnallisia vaatimuksia.

javalla on seuraava

Käyttäjän hyväksyntätestaus (UAT):

UAT suoritetaan käyttäjäympäristössä, joka muistuttaa tuotantoympäristöä. UAT varmistaa, että toimitettu järjestelmä täyttää käyttäjän vaatimukset ja että järjestelmä on valmis käytettäväksi todellisessa maailmassa.

Suunnitteluvaihe:

• Vaatimusanalyysi: Tämä vaihe sisältää yksityiskohtaisen yhteydenpidon asiakkaan kanssa hänen vaatimustensa ja odotustensa ymmärtämiseksi. Tämä vaihe tunnetaan nimellä Requirement Gathering.
• Järjestelmäsuunnittelu: Tämä vaihe sisältää järjestelmän suunnittelun ja täydelliset laitteisto- ja viestintäasetukset tuotteen kehittämiseksi.
• Arkkitehtoninen suunnittelu: Järjestelmäsuunnittelu on jaettu edelleen moduuleiksi, jotka ottavat erilaisia ​​toimintoja. Tiedonsiirto ja viestintä sisäisten moduulien välillä ja ulkomaailman (muiden järjestelmien) kanssa ymmärretään selvästi.
• Moduulin suunnittelu: Tässä vaiheessa järjestelmä hajoaa pieniksi moduuleiksi. Moduulien yksityiskohtainen suunnittelu on määritelty, tunnetaan myös nimellä Low-Level Design (LLD).

Testausvaiheet:

• Yksikkötestaus: Yksikkötestaussuunnitelmat kehitetään moduulin suunnitteluvaiheessa. Nämä yksikkötestisuunnitelmat suoritetaan virheiden poistamiseksi koodi- tai yksikkötasolla.
• Integraatiotestaus: Yksikkötestauksen päätyttyä suoritetaan integrointitestaus. Integraatiotestauksessa moduulit integroidaan ja järjestelmää testataan. Integrointitestaus suoritetaan arkkitehtuurin suunnitteluvaiheessa. Tämä testi varmistaa moduulien välisen viestinnän.
• Järjestelmän testaus: Järjestelmätestaus testaa koko sovelluksen toimivuuden, keskinäisen riippuvuuden ja kommunikoinnin kanssa. Se testaa kehitetyn sovelluksen toiminnallisia ja ei-toiminnallisia vaatimuksia.
• Käyttäjän hyväksyntätestaus (UAT): UAT suoritetaan käyttäjäympäristössä, joka muistuttaa tuotantoympäristöä. UAT varmistaa, että toimitettu järjestelmä täyttää käyttäjän vaatimukset ja että järjestelmä on valmis käytettäväksi todellisessa maailmassa.

Teollisuuden haaste:

Alan kehittyessä teknologiat ovat muuttuneet monimutkaisemmiksi, nopeammiksi ja ikuisesti muuttuviksi, mutta edelleen on joukko perusperiaatteita ja käsitteitä, jotka ovat yhtä soveltuvia nykyään kuin silloin, kun IT oli lapsenkengissään.

myivecricket

• Määritä ja tarkenna käyttäjien vaatimukset tarkasti.
• Suunnittele ja rakenna sovellus valtuutettujen käyttäjien vaatimusten mukaisesti.
• Vahvista, että heidän rakentamansa sovellus vastasi valtuutettuja liiketoimintavaatimuksia.

V-mallin merkitys

1. Varhainen viantunnistus

Sisällyttämällä varmennus- ja validointitehtävät kehitysprosessin jokaiseen vaiheeseen V-Model kannustaa varhaiseen testaukseen. Tämä alentaa kustannuksia ja vaivaa, joita tarvitaan ongelmien korjaamiseen myöhemmin kehitysvaiheen elinkaaren aikana auttamalla vikojen varhaisessa havaitsemisessa ja ratkaisemisessa.

2. kehitys- ja testausvaiheiden määrittäminen

V-malli sisältää testausvaiheen, joka vastaa kehitysprosessin kutakin vaihetta. Varmistamalla, että testaus- ja kehitysprosessit ovat selkeästi kartoitettuja, tämä selkeä kartoitus edistää järjestelmällistä ja järjestelmällistä lähestymistapaa ohjelmistosuunnitteluun.

3. Estää Big Bang -testauksen

Perinteisissä kehitysmalleissa testaus tehdään usein aivan kehityksen elinkaaren lopussa, mikä johtaa Big Bang -lähestymistapaan, jossa kaikki testaustoiminnot kohdistetaan kerralla. Integroimalla testaustoiminnot kehitysprosessiin ja kannustamalla edistyksellisempään ja säännellympään testaustapaan V-malli estää tämän.

4. Parantaa yhteistyötä

V-Model edistää kaikilla tasoilla yhteistyötä testaus- ja kehitystiimien välillä. Tämän yhteistyön kautta projektien vaatimukset, suunnitteluvalinnat ja testausmenetelmät ymmärretään paremmin, mikä parantaa kehitysprosessin tehokkuutta ja tehokkuutta.

5. Parempi laadunvarmistus

Yleistä laadunvarmistusta parantaa V-malli, joka sisältää testaustoiminnot kaikilla tasoilla. Ennen kuin ohjelma saavuttaa lopullisen käyttöönottovaiheen, se varmistaa, että se täyttää vaatimukset ja käy läpi tiukan validointi- ja varmennusprosessin.

V-mallin periaatteet

• Suuresta pieneen: V-Modelissa testaus tehdään hierarkkisessa näkökulmassa, esimerkiksi projektitiimin määrittelemät vaatimukset, High-Level Design- ja Detailed Design -vaiheet projektista. Kun jokainen näistä vaiheista täyttää vaatimukset, ne tarkentuvat ja tarkentuvat.
• Tietojen/prosessien eheys: Tämä periaate edellyttää, että minkä tahansa projektin onnistunut suunnittelu edellyttää sekä datan että prosessien yhdistämistä ja yhteenkuuluvuutta. Prosessielementit on tunnistettava jokaisessa vaatimuksessa.
• Skaalautuvuus: Tämä periaate edellyttää, että V-Model-konseptilla on joustavuus mukautua mihin tahansa IT-projektiin sen koosta, monimutkaisuudesta tai kestosta riippumatta.
• Ristiviittaus: Vaatimusten ja vastaavan testaustoiminnan välinen suora korrelaatio tunnetaan ristiviittauksina.

Aineellinen dokumentaatio:

Tämä periaate edellyttää, että jokaisesta projektista on luotava asiakirja. Sekä projektin kehitystiimi että tukitiimi vaativat ja soveltavat tätä dokumentaatiota. Dokumentaatiota käytetään sovelluksen ylläpitoon, kun se on saatavilla tuotantoympäristössä.

Miksi suositeltava?

• Sitä on helppo hallita mallin jäykkyyden ansiosta. Jokaisella V-Modelin vaiheella on omat suoritukset ja tarkistusprosessi.
• Ennakoiva vikojen seuranta – eli viat löydetään varhaisessa vaiheessa.

Milloin käyttää / V-malli ?

• Vaatimusten jäljitettävyys: V-malli osoittautuu hyödylliseksi tilanteissa, joissa on välttämätöntä luoda tarkka jäljitettävyys vaatimusten ja niihin liittyvien testitapausten välille.
• Monimutkaiset projektit: V-Model tarjoaa metodisen tavan hallita testaustoimintoja ja vähentää integraatio- ja käyttöliittymäongelmiin liittyviä riskejä projekteille, jotka ovat erittäin monimutkaisia ​​ja järjestelmäkomponenttien keskinäisiä riippuvuuksia.
• Vesiputouksen kaltaiset projektit : Koska V-malli tarjoaa lähestyttävän rakenteen testaustoimintojen järjestämiseen, suorittamiseen ja seurantaan kaikilla kehitystasoilla, se sopii projekteihin, joissa käytetään peräkkäistä lähestymistapaa kehitykseen, aivan kuten vesiputousmallissa.
• Turvallisuuskriittiset järjestelmät: Näitä järjestelmiä käytetään ilmailu-, auto- ja terveydenhuoltoteollisuudessa. Niissä painotetaan voimakkaasti jäykkiä varmennus- ja validointimenettelyjä, jotka auttavat varmistamaan, että olennaiset järjestelmävaatimukset täyttyvät ja mahdolliset riskit löydetään ja eliminoidaan varhaisessa kehitysprosessissa.

Edut V-mallista

• Tämä on erittäin kurinalainen malli, ja vaiheet suoritetaan yksi kerrallaan.
• V-mallia käytetään pienissä projekteissa, joissa projektivaatimukset ovat selkeät.
• Yksinkertainen ja helppo ymmärtää ja käyttää.
• Tämä malli keskittyy verifiointi- ja validointitoimintoihin elinkaaren varhaisessa vaiheessa, mikä parantaa todennäköisyyttä rakentaa virheetön ja laadukas tuote.
• Sen avulla projektinhallinta voi seurata edistymistä tarkasti.
• Selkeä ja jäsennelty prosessi: V-malli tarjoaa selkeän ja jäsennellyn prosessin ohjelmistokehitys , mikä helpottaa ymmärtämistä ja seuraamista.
• Testauksen painopiste: V-mallissa painotetaan voimakkaasti testausta, joka auttaa varmistamaan ohjelmiston laadun ja luotettavuuden.
• Parannettu jäljitettävyys: V-malli tarjoaa selkeän yhteyden vaatimusten ja lopputuotteen välillä, mikä helpottaa ohjelmiston muutosten jäljittämistä ja hallintaa.
• Parempi viestintä: V-mallin selkeä rakenne auttaa parantamaan viestintää asiakkaan ja kehitystiimin välillä.

V-mallin huonot puolet

• Suuri riski ja epävarmuus.
• Se ei sovellu monimutkaisiin ja olioprojekteihin.
• Se ei sovellu projekteihin, joissa vaatimukset eivät ole selkeitä ja joissa on suuri muutosriski.
• Tämä malli ei tue vaiheiden iterointia.
• Se ei helposti käsittele samanaikaisia ​​tapahtumia.
• Joustamattomuus: V-malli on lineaarinen ja peräkkäinen malli, joka voi vaikeuttaa muuttuviin vaatimuksiin tai odottamattomiin tapahtumiin sopeutumista.
• Aikaa vievä: V-malli voi olla aikaa vievä, koska se vaatii paljon dokumentaatiota ja testausta.
• Yliluottamus dokumentaatioon: V-mallissa painotetaan voimakkaasti dokumentointia, mikä voi johtaa liialliseen dokumentointiin todellisen kehitystyön kustannuksella.

Johtopäätös

Software Engineering V-Model tarjoaa tieteellisen ja organisoidun lähestymistavan ohjelmistokehityksen elinkaariin (SDLC). Tiimin asiantuntemus valitulla menetelmällä, projektin ainutlaatuiset ominaisuudet ja vaatimusten luonne tulee ottaa huomioon valittaessa SDLC-malleja, mukaan lukien V-malli.

Hakuteos:

Ohjelmistotekniikka: A Practitioner's Approach, Roger S. Pressman, julkaissut McGraw-Hill Education, 2017.