Ten arty­kuł to krót­ki wpis o tak zwa­nym V‑modelu. Jest to model wytwa­rza­nia opar­ty na pętli ana­li­zy, pro­jek­to­wa­nia, testo­wa­nia i prze­ka­za­nia do użyt­ku. Oparty jest połą­cze­niu dwóch cykli życia: pro­jek­to­wa­nia i wytwa­rza­nia. jest sto­so­wa­ny w sze­ro­ko poję­tej inży­nie­rii sys­te­mów, nie koniecz­nie oprogramowania. 

W bran­ży IT zna­na jego postać wyglą­da np. tak:

Niedawno w innej wer­sji v‑model publi­ko­wa­łem, pisząc o tym czym jest mecha­tro­ni­ka :

Bardzo czę­sto auto­rzy piszą, że jest to skom­pro­mi­to­wa­ny, tak zwa­ny wodo­spa­do­wy (water­fall), sys­tem wytwa­rza­nia opro­gra­mo­wa­nia. Była by to praw­da, gdy zawsze cho­dzi­ło o hipo­te­tycz­ny ​„cały sys­tem”. Jednak V‑model, jako meto­da, nie pre­cy­zu­je ska­li pro­jek­tu. W przy­pad­ku więk­szo­ści daw­nych kon­struk­cji mecha­nicz­nych była by to praw­da, jed­nak modu­ło­wość to od lat cecha każ­dej kon­struk­cji inży­nier­skiej. Model ten więc nie koniecz­nie musi być tym ​„złym wodo­spa­dem”. Pojawiają się od cza­su do porów­na­nia mię­dzy wodo­spa­dem, v‑modelem a agi­le, jako meto­da­mi, jed­nak ich auto­rzy nie pre­cy­zu­ją tego, czy w danym przy­pad­ku cho­dzi o moduł czy o cały sys­tem . Model ten jest sta­le przed­mio­tem poszu­ki­wań popra­wy jako­ści i więk­szej ​„zwin­no­ści” .

Myślę, że kla­sycz­ny wodo­spad, jako meto­da pro­wa­dze­nia powo­li odcho­dzi w nie­pa­mięć (powi­nien). Nie zapo­mi­naj­my jed­nak, że roz­po­czy­na­nie two­rze­nia opro­gra­mo­wa­nia od pro­jek­to­wa­nia wspól­ne­go (rela­cyj­ne­go) mode­lu danych to taki wła­śnie kla­sycz­ny struk­tu­ral­ny wodo­spad. Więc jak?

Modułowe sys­te­my to w zasa­dzie zagnież­dżo­ne dwa v‑modele. Najpierw pro­jek­tu­je­my archi­tek­tu­rę cało­ści: powsta­je model kom­po­nen­to­wy. Kolejne eta­py to ite­ra­cyj­ne dostar­cza­nie poszcze­gól­nych kom­po­nen­tów. W kon­struk­cjach elek­tro­me­cha­nicz­nych i tak musi­my cze­kać na ukoń­cze­nie cało­ści (samo­chód czy pral­ka albo jest w cało­ści, albo nie mamy cze­go uży­wać). W przy­pad­ku opro­gra­mo­wa­nia może­my sku­pić sie na poje­dyn­czych komponentach. 

Poprawnie zapro­jek­to­wa­ne opro­gra­mo­wa­nie to samo­dziel­ne usłu­gi apli­ka­cyj­ne. Złożone nie raz, apli­ka­cje powsta­ją jako zbio­ry takich usług, na ryn­ku widzi­my je jako goto­we wie­lo­mo­du­ło­we sys­te­my. Jednak dedy­ko­wa­ne pro­jek­ty nie mają rygo­ru ​„odda­nia w cało­ści”. Usługi apli­ka­cyj­ne mogą być odda­wa­ne jed­na po dru­giej. Wtedy opi­sy­wa­ny tu v‑model to naj­pierw lewa stro­na: tak zwa­na ​„archi­tek­tu­ra wyso­kie­go pozio­mu”, a następ­nie ite­ra­cyj­no-przy­ro­sto­we reali­za­cje kolej­nych kom­po­nen­tów i usług. Każda kolej­na usłu­ga (kom­po­nent) to pro­jek­to­wa­nie, imple­men­ta­cja, testy i odda­nie do użytku.

Podejścia zna­ne jako Use Case 2.0 czy Microservice, to wła­śnie takie modułowe 

Jednak nadal na eta­pie ana­liz i pro­jek­to­wa­nia auto­rzy tych pro­jek­tów bar­dzo czę­sto nadal poprze­sta­ją na opi­su idei, czy­li pro­ce­su biz­ne­so­we­go i nazwa­nych usług, nie jest to jed­nak pro­jek­to­wa­nie sys­te­mu a co naj­wy­żej biz­ne­so­we wyma­ga­nia . V‑model opie­ra się na tym, że imple­men­ta­cja jest poprze­dza­na pro­jek­to­wa­niem, czy­li swo­istym stu­dium wyko­nal­no­ści. Jest to spraw­dzo­na meto­da z każ­dej innej inżynierii: 

zanim zaczniesz budo­wać, upew­nij się, że wiesz co powin­no powstać.

Tak więc v‑model wyglą­da na dobrą meto­dę-pro­ces. To czy jest to wodo­spad czy nie, zale­ży od archi­tek­tu­ry cało­ści (mono­lit czy nie mikro­ser­wi­sy) a nie od fak­tu poprze­dza­nia imple­men­ta­cji projektowaniem.

Źródła