V-malli

V-malli (V-model) on prosessimalli jota voidaan käyttää kehitysprojektien suunnittelussa ja toteutuksessa. Se parantaa projektinhallintaa ja projektin onnistumisen todennäköisyyttä. V-mallin avulla voidaan määritellä projektin päämäärät ja tavat joilla näihin päämääriin päästään. Se määrittelee kaikkien projektiin osallistujien roolit: kuka tekee mitä ja milloin.  
 
V-mallia kehitettiin samanaikaisesti Saksassa ja Yhdysvalloissa. Saksassa sitä kehitettiin hallituksen puolustusprojekteja varten.

V-mallin tavoitteet 

 Projektin riskien minimointi 

V-malli parantaa projektinhallintaa määrittelemällä yhtenäiset käytännöt ja roolit, jotka edesauttavat projektin riskien tunnistamisen ja siten niiden ehkäisemisen. 

 Laadun parantaminen ja takaaminen

Standardina kehitysmallina V-malli takaa tulosten laadukkuuden. Laatu voidaan varmistaa jo projektin varhaisessa vaiheessa.

 Kustannusten pienentäminen

Standardin kehitysmallin kulut on helppo laskea jo projektin aikana, jolloin niissä pysyminen on myös helpompaa. 

 Kommunikoinnin parantaminen osakkeenomistajien välillä

V-mallissa on määritelty tarkkaan jokaisen rooli projektissa. Tämä tarkoittaa myös osakkeenomistajia, joilta vaaditaan omat osansa projektissa. Heidän tulee olla yhteisymmärryksessä projektin päämääristä ja tämä vaatii kommunikointia.

V-mallin rakenne 

V-malli määrittelee kuka tekee mitä ja milloin. V-mallia voidaan muokata projektin tarpeiden mukaan, jolloin sen rakenne saattaa hieman muuttua. 

V-malli lähtee liikkeelle suunnittelusta, joka löytyy kuvan mukaisesti V:n vasemman sakaran yläreunasta, josta lähdetään liikkeelle alaspäin. Ensin tehdään vaatimusmäärittely. Tämän jälkeen siirrytään suunnitteluvaiheeseen, jonka aikana suunnitellaan tuote aloittaen laajemmasta konseptista siirtyen tarkempaan eli esimerkiksi yksittäisiin toimintoihin.

Seuraava vaihe on tuotteen toteutus. Tämä vaihe löytyy V:n pohjalta.  

Kolmas eli viimeinen vaihe V-mallissa on testaus eli lähdetään nousemaan V:n oikea sakaraa ylös. Testaus suoritetaan tarkemmasta yleisempään. Eli testataan esimerkiksi ensimmäisenä tuotteen toiminnot, sitten koko tuotteen toiminta ja tämän jälkeen testaus loppukäyttäjällä.  

Testausvaiheessa verrataan koko ajan vastaako tuote samalla tasolla olevaa suunnitteluvaihetta. Eli siis esimerkiksi viimeistä testausta verrataan vaatimusmäärittelyyn, joka oli suunnittelun ensimmäinen vaihe.

Hyödyt ja rajoitukset

Hyödyt 
Alla löytyy V-mallin soveltamisen hyödyt:
 V-malli voidaan muokata jokaista projektia ja organisaatiota varten juuri sellaiseksi kuin on tarpeellista.
 V-mallin avulla on helppo määritellä mitä kukin tekee ja missä vaiheessa projektia.

Rajoitukset 
V-mallin rajoituksia ovat: 
 V-malli keskittyy ainoastaan projektiin, ei koko organisaatioon ja sitä käytetään vain kerran projektin aikana. 
 V-malli on joissain asioissa liian muokkautuva jolloin mallin käyttäjälle jää liikaa liikkumavaraa, joka saattaa aiheuttaa sen, että projektin aikana ei tiedetä mitä asioita malli ottaa mukaan ja mitä jättää pois.

Projektin määrittelemisen vaiheet 
Vaatimusten analysointivaihe keskittyy käyttäjien tarpeiden ja vaatimusten keräämiseen. Tämä vaihe ei määrittele, miten ohjelmisto suunnitellaan tai rakennetaan, vaan pikemminkin keskittyy siihen, mitä ihanteellisen järjestelmän tulisi saavuttaa. Yleinen käytäntö on haastatella käyttäjiä ja luoda vaatimusdokumentti niiden pohjalta.

Käyttäjien vaatimusdokumentti kuvaa yleensä järjestelmän toiminnalliset, käyttöliittymä-, suorituskyky-, tieto-, ja turvallisuusvaatimukset, jotka käyttäjät odottavat. Tämä dokumentti toimii ohjeena suunnittelijoille suunnitteluvaiheessa, ja siinä määritellään myös käyttäjien hyväksymistestit.

Vaatimusten keräämiseen on monia erilaisia menetelmiä, kuten haastattelut, kyselylomakkeet, dokumenttianalyysi, havainnointi, kertakäyttöprototyypit ja käyttötapaukset.

Järjestelmän suunnittelu on vaihe, jossa järjestelmäinsinöörit analysoivat ja ymmärtävät suunnitellun järjestelmän liiketoiminnan tutkimalla käyttäjien vaatimusdokumenttia. He selvittävät mahdollisuuksia ja tekniikoita, joilla käyttäjien vaatimukset voidaan toteuttaa. Jos jotkin vaatimukset eivät ole toteutuskelpoisia, käyttäjälle ilmoitetaan ongelmasta. Ratkaisu löydetään yhdessä käyttäjien kanssa ja vaatimusdokumenttia muokataan sen mukaisesti.

Arkkitehtuurisuunnittelu

Tietokoneen ja ohjelmiston arkkitehtuurin suunnitteluvaihetta kutsutaan myös korkean tason suunnitteluksi. Arkkitehtuurin valinnan perusperiaate on, että sen tulisi kattaa kaikki tarvittavat osatekijät. Tämä sisältää yleensä moduulien luettelon, lyhyet kuvaukset kustakin moduulista, niiden rajapintasuhteet, riippuvuudet, tietokantataulut, arkkitehtuurikaaviot, tekniset yksityiskohdat. Tässä vaiheessa suoritetaan myös integraatiotestisuunnittelu.

Moduulisuunnittelua kutsutaan myös tarkemman tason suunnitteluksi. Suunniteltu järjestelmä pilkotaan pienempiin yksiköihin tai moduuleihin, ja jokainen niistä kuvataan niin yksityiskohtaisesti, että ohjelmoija voi ryhtyä koodaamaan suoraan. Tarkemmassa suunnitteludokumentissa tai ohjelman teknisissä eritelmissä esitetään moduulin toiminnallinen logiikka pseudokoodilla johon sisältyy:

 Tietokantataulut kaikkine elementteineen, mukaan lukien niiden tyyppi ja koko.

 Kaikki rajapinnan yksityiskohdat täydellisine API-viittauksineen.

 Kaikki riippuvuudet.

 Virheilmoitusten luettelot.

 Kaikki moduulin syötteet ja tulosteet.

Tämän vaiheen aikana kehitetään myös yksikkötestisuunnittelu.

Lähteet

Aiheesta muualla 

 The V-model: http://www.the-software-experts.de/e_dta-sw-process.htm
 Fundamentals of the V-modell: http://v-modell.iabg.de/v-modell-xt-html-english/index.html#toc0 

Ohjelmistoprojektin hallinta