Traditionaalisen suunnittelun kannattajat pitävät V:tä parempana kuin ”ketteriä” menetelmiä. Tämä pätee erityisesti silloin, kun on kyse kriittisistä järjestelmistä.
Ketä meidän pitäisi uskoa?
Noh, jos olemme rehellisiä, kun V on olemassa yhtenä loistavana läpikäyntinä kokonaiselle järjestelmälle, uusi sukupolvi tekee loistavaa työtä. V voi todella hidastaa hyvää ohjelmistokehitystä.
Ytimeltään Systems Engineering V on looginen konstruktio. Se kuvaa järjestelmävaatimusten löytämistä pilkkomalla järjestelmä pienempiin osiin ja sitten kokoamalla ja validoimalla nämä osat.
Systeemi-insinöörit soveltavat V:tä eri yhteyksissä. Useimmiten V:tä käytetään suurissa organisaatioissa, kuten Yhdysvaltain puolustusministeriössä. Se on näkyvästi esillä myös akateemisissa laitoksissa.
Näissä suurissa ohjelmissa tai organisaatioissa V:tä käytetään osana ylimmän tason toteutusprosessia. Yleisessä työnkulussa on seitsemän vaihetta:
Prosessi alkaa V:n vasemmalta puolelta, jossa (1) luodaan käsitteitä. Seuraavaksi (2) määritellään, puretaan ja jaetaan koko järjestelmää koskevat vaatimukset. Sitten (3) järjestelmän osat suunnitellaan yksityiskohtaisesti.
Toteutus tapahtuu V:n alaosassa (4). Täällä suunnitellut komponentit luodaan prosessin aikaisemmassa vaiheessa asetettujen vaatimusten mukaisesti.
V:n oikealla puolella ylöspäin siirryttäessä nämä komponentit (5) integroidaan yhteen lopulliseksi järjestelmäksi. Integroitu järjestelmä todennetaan sen jälkeen sen varmistamiseksi, että se täyttää alkuperäiset vaatimukset, ja validoidaan sen varmistamiseksi, että se vastaa käyttäjien tarpeita (6). Lopuksi (7) järjestelmä toimitetaan ja sitä ylläpidetään.
V-prosessin haasteet
V-prosessin toteuttaminen osoittautuu hankalaksi monissa suurissa projekteissa – erityisesti niissä, jotka sisältävät ohjelmistoja.
Integrointi
Yksi suurimmista ongelmista on se, että integraatio tapahtuu liian myöhään kehitysprosessissa. Ohjelmat, jotka luottavat V:hen, odottavat, kunnes ohjelmistokomponentit ovat valmiita, jotta voidaan vähentää kallista integroinnin uudelleentyöstämistä.
Ohjelmistokomponenttien manuaalinen integrointi vie valtavasti aikaa. Totuus, jonka me kaikki tiedämme olevan totta, on se, että ohjelmisto ei ole koskaan valmis. Loppuun jätettyjä integrointitoimia kiirehditään, jotta päästään ohjelman aikatauluun.
V:ssä integroidut komponentit täyttävät yleensä toiminnalliset vaatimukset, mutta eivät useinkaan ole turvallisia, varmoja tai oikeita.
Verifiointi &Validointi
Odottaminen siihen asti, että järjestelmä on integroitu täydellisesti, jotta voidaan suorittaa verifikaatio- ja validointityö (V&V), pahentaa tätä ongelmaa. Korjausten toteuttaminen aiheuttaa heijastusvaikutuksia koko järjestelmään, mikä tekee V&V:n aikana ilmenevien ongelmien ratkaisemisesta haastavaa ja kallista.
Ohjelmissa otetaan usein käyttöön ”järjestelmätason” korjauksia sen sijaan, että ratkaistaisiin ongelman perimmäinen syy – tämä on laastari. Ohjelmistoriskiä lievennetään usein käytännöillä, kuten järjestelmätason palomuureilla ja virustorjuntaohjelmistoilla, sen sijaan, että siihen puututtaisiin koodissa.
Laastarit vähentävät mahdollisuutta, että käyttäjät törmäävät virheeseen, mutta itse virhettä ei korjata, vaan se lymyää edelleen järjestelmässä.
Haasteeseen vastaaminen
Systeemitekniikan V:n käsitteet eivät ole ongelma – ongelmana on V:n rakenne, joka ei sovellu ohjelmistoihin
Nykyaikaisilla tekniikoilla voidaan mahdollistaa ohjelmistojen jatkuva integrointi, jopa suurissa ohjelmissa. Varhaiseen integrointiin ja verifiointiin perustuvien työkalujen ja prosessien käyttö ei mitätöi V:n ydinkäsitteitä – ne parantavat V:tä niin, että se toimii ohjelmistokehityksessä.
Lopputuloksena on ohjelmisto, joka on oikein luotaessa, ja järjestelmä, joka on halvempi, turvallisempi ja nopeampi toimittaa.