V-mallia kutsutaan myös varmistus- ja validointimalliksi. Tässä SDLC:n jokaisen vaiheen on saatava päätökseen ennen kuin seuraava vaihe alkaa. Se noudattaa peräkkäistä suunnitteluprosessia, joka on sama kuin vesiputousmalli. Laitteen testaus suunnitellaan rinnakkain vastaavan kehitysvaiheen kanssa.
Todentaminen: Se sisältää staattisen analyysimenetelmän (tarkistuksen), joka tehdään ilman koodin suorittamista. Se on tuotekehitysprosessin arviointiprosessi sen selvittämiseksi, täyttävätkö tietyt vaatimukset.
Validointi: Se sisältää dynaamisen analyysimenetelmän (toiminnallinen, ei-toiminnallinen), testaus suoritetaan suorittamalla koodia. Validointi on prosessi, jossa ohjelmisto luokitellaan kehitysprosessin päätyttyä sen määrittämiseksi, vastaako ohjelmisto asiakkaiden odotuksia ja vaatimuksia.
Joten V-Model sisältää todentamisvaiheet toisella puolella validointivaiheet toisella puolella. Varmennus- ja validointiprosessi yhdistetään koodausvaiheella V-muotoon. Siksi se tunnetaan nimellä V-malli.
V-mallin varmennusvaiheessa on useita eri vaiheita:
| Liiketoiminnan vaatimusanalyysi: | Tämä on ensimmäinen askel, jossa tuotteen vaatimukset ymmärretään asiakkaan puolelta. Tämä vaihe sisältää yksityiskohtaista viestintää asiakkaan odotusten ja täsmällisten vaatimusten ymmärtämiseksi.
| Järjestelmäsuunnittelu: | Tässä vaiheessa järjestelmäinsinöörit analysoivat ja tulkitsevat ehdotetun järjestelmän liiketoimintaa tutkimalla käyttäjävaatimusasiakirjaa.
| Arkkitehtuurisuunnittelu: | Arkkitehtuurin valinnassa lähtökohtana on, että sen tulee ymmärtää kaikki, mikä tyypillisesti koostuu moduuliluettelosta, kunkin moduulin lyhyestä toiminnasta, niiden rajapintasuhteista, riippuvuuksista, tietokantataulukoista, arkkitehtuurikaavioista, teknologian yksityiskohdista jne. Integraatiotestausmalli on mukana ulos tietyssä vaiheessa.
| Moduulin suunnittelu: | Moduulien suunnitteluvaiheessa järjestelmä hajoaa pieniksi moduuleiksi. Moduulien yksityiskohtainen suunnittelu on määritelty, joka tunnetaan nimellä Low-Level Design
| Koodausvaihe: | Suunnittelun jälkeen aloitetaan koodausvaihe. Vaatimusten perusteella päätetään sopiva ohjelmointikieli. Koodaukselle on olemassa joitain ohjeita ja standardeja. Ennen arkistoon tarkistamista lopullinen koontiversio optimoidaan suorituskyvyn parantamiseksi, ja koodi käy läpi useita kooditarkastuksia suorituskyvyn tarkistamiseksi.
V-mallin validointivaiheessa on useita eri vaiheita:
| Yksikkötestaus: | V-mallissa yksikkötestisuunnitelmat (UTP) kehitetään moduulin suunnitteluvaiheessa. Nämä UTP:t suoritetaan virheiden poistamiseksi kooditasolla tai yksikkötasolla. Yksikkö on pienin itsenäisesti olemassa oleva kokonaisuus, esimerkiksi ohjelmamoduuli. Yksikkötestaus varmistaa, että pienin kokonaisuus voi toimia oikein, kun se on eristetty muista koodeista/yksiköistä.
| Integraatiotestaus: | Integraatiotestisuunnitelmat kehitetään arkkitehtisuunnitteluvaiheessa. Nämä testit varmistavat, että itsenäisesti luodut ja testatut ryhmät voivat elää rinnakkain ja kommunikoida keskenään.
| Järjestelmän testaus: | Järjestelmätestisuunnitelmat laaditaan järjestelmän suunnitteluvaiheessa. Toisin kuin yksikkö- ja integraatiotestisuunnitelmat, järjestelmätestisuunnitelmat laativat asiakkaan liiketoimintatiimi. Järjestelmätesti varmistaa, että sovelluskehittäjän odotukset täyttyvät.
| Hyväksymistesti: | Hyväksymistestaus liittyy liiketoiminnan vaatimusten analysointiosaan. Se sisältää ohjelmistotuotteen testaamisen käyttäjäympäristössä. Hyväksymistestit paljastavat yhteensopivuusongelmat eri järjestelmien kanssa, mikä on saatavilla käyttäjäilmapiirissä. Se löytää yhdessä todellisen käyttäjän ilmapiirin ei-toiminnalliset ongelmat, kuten kuormitus- ja suorituskykyvirheet.
Milloin V-mallia käytetään?
- Kun vaatimus on hyvin määritelty eikä moniselitteinen.
- V-muotoista mallia tulisi käyttää pienissä ja keskisuurissa projekteissa, joissa vaatimukset on selkeästi määritelty ja kiinteä.
- V-muotoinen malli tulee valita, kun käytettävissä on malliteknisiä resursseja ja olennaista teknistä asiantuntemusta.
V-mallin edut (edut):
- Helppo ymmärtää.
- Testausmenetelmät, kuten suunnittelu, testisuunnittelu tapahtuu hyvissä ajoin ennen koodausta.
- Tämä säästää paljon aikaa. Näin ollen suurempi mahdollisuus menestyä vesiputousmallin yli.
- Estää vikojen virtauksen alaspäin.
- Toimii hyvin pienissä suunnitelmissa, joissa vaatimukset ovat helposti ymmärrettävissä.
V-mallin huonot puolet:
- Erittäin jäykkä ja vähiten joustava.
- Ei sovi monimutkaiseen projektiin.
- Ohjelmistoa kehitetään toteutusvaiheessa, joten ohjelmiston varhaisia prototyyppejä ei valmisteta.
- Jos puolivälissä tapahtuu muutoksia, testiasiakirjat ja tarvittavat asiakirjat on päivitettävä.
