Wprowadzenie

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:

V‑Model is also refer­red to as the Verification and Validation Model. In this, each pha­se of SDLC must com­ple­te befo­re the next pha­se starts. It fol­lows a sequ­en­tial design pro­cess the same as the water­fall model. The testing of the devi­ce is plan­ned in paral­lel with a cor­re­spon­ding sta­ge of deve­lop­ment. (źr.: V‑model (Software Engineering) – javat­po­int).

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

Czy V‑model to waterfall

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 kom­po­nen­ty) a nie od fak­tu poprze­dza­nia imple­men­ta­cji projektowaniem.

Poniżej sche­mat obra­zu­ją­cy V‑model z per­spek­ty­wy dzi­siej­szych sys­te­mów mechatronicznych:

Godna pod­kre­śle­nia jest tu gra­ni­ca mię­dzy archi­tek­tu­rą a imple­men­ta­cja oraz fakt, że archi­tek­tu­ra to kom­po­nen­ty mul­ti­di­scy­pli­nar­ne: kom­po­nent sys­te­mu może być kon­struk­cją mecha­nicz­ną, elek­tro­me­cha­nicz­ną, itp.. może być kom­pu­te­rem. Tu waż­na uwa­ga: powszech­nie mówi sie o opro­gra­mo­wa­niu jako kom­po­nen­cie, jed­nak jest to pew­ne uprosz­cze­nie, gdyż kom­po­nen­tem sys­te­mów są kom­pu­te­ry a nie opro­gra­mo­wa­nie”. Elementem ste­ru­ją­cym w samo­cho­dzie czy pral­ce jest umiesz­czo­ny w nich i zin­te­gro­wa­ny z resz­tą kom­pu­ter, a nie opro­gra­mo­wa­nie”.

Skoro sys­tem z zasa­dy jest two­rem skła­da­ją­cym się ele­men­tów to zna­czy, że tak­że z zasa­dy ma wewnętrz­na archi­tek­tu­rę. Rakieta, samo­chód czy pral­ka to sys­te­my, jest jed­nak istot­na róż­ni­ca mię­dzy sys­te­mem jakim jest np. samo­chód a sys­te­mem jakim jest gru­pa ludzi, ume­blo­wa­nie miesz­ka­nia czy apli­ka­cja jak ele­ment kom­pu­te­ra. Samochód albo jest kom­plet­ny albo nie jest dzia­ła­ją­cym samo­cho­dem. Jednak każ­dy ele­ment sys­te­mu ume­blo­wa­nia miesz­ka­nia sam z sie­bie posia­da okre­ślo­ną i nie­za­leż­ną od pozo­sta­łych ele­men­tów tego sys­te­mu funk­cjo­nal­ność: każ­dy mebel do cze­goś słu­ży. Można nie mieć w peł­ni ume­blo­wa­ne­go salo­nu mając już jed­nak jeden fotel i sie­dzieć w nim by odpocząć.

Identyczną sytu­ację mamy w przy­pad­ku zło­żo­ne­go opro­gra­mo­wa­nia, jed­nak pod warun­kiem, że nie jest ono (jego archi­tek­tu­ra) mono­li­tem. Jeżeli ma archi­tek­tu­rę praw­dzi­wie kom­po­nen­to­wą (kom­po­nent są od sie­bie real­nie nie­za­leż­ne), budo­wa takie­go sys­te­mu to dwu­po­zio­mo­wy V‑model jaki poka­za­no poniżej:

Iteracyjne zagnież­dże­nie V‑model sys­te­mu i V‑model każ­de­go kom­po­nen­tu (opr. wła­sne autora)

O sys­te­mach pro­jek­to­wa­nych real­nie kom­po­nen­to­wo pisa­łem w arty­ku­le Interface-Oriented Design czy­li archi­tek­tu­ra sys­te­mu zorien­to­wa­na na inter­fej­sy. Tu sku­pi­my się na samym fak­cie, że sys­tem jest komponentowy. 

Mając pro­jekt HLD sys­te­mu mamy zde­fi­nio­wa­ne jego kom­po­nen­ty a kon­kret­nie ich inter­fej­sy i wyma­ga­ną logi­kę dzia­ła­nia (funk­cję jaką peł­nią w sys­te­mie). W efek­cie każ­dy kom­po­nent, na swo­im pozio­mie, ma wyma­ga­nia (zde­fi­nio­wa­ne inter­fej­sy) i powsta­je tak­że w pro­ce­sie V‑model. Z uwa­gi na wyżej opi­sa­ną spe­cy­fi­kę sys­te­mów jaką jest opro­gra­mo­wa­nie, czę­sto kom­po­nen­ty poje­dyn­czo posia­da­ją przy­dat­ną użyt­kow­ni­ko­wi apli­ka­cji funk­cjo­nal­ność. To ozna­cza, że moż­na je dostar­czać nie­za­leż­nie i w usta­lo­nej kolej­no­ści. Tak wła­śnie, ite­ra­cyj­nie-przy­ro­sto­wo, powsta­je zło­żo­ne opro­gra­mo­wa­nie podzie­lo­ne na nie­za­leż­ne kom­po­nen­ty .

Konflikt interesu czyli role w projekcie

Pierwszy cyto­wa­ny dia­gram w tym tek­ście poka­zu­je V‑model jako model pra­cy deve­lo­pe­ra. Jednak w zarzą­dza­niu pro­jek­ta­mi inży­nier­ski­mi coraz czę­ściej pod­kre­śla się kwe­stie jako­ści, a tam gdzie poja­wia się poję­cie jako­ści i nad­zo­ru poja­wia sie poję­cie kon­flik­tu interesu. 

Czym jest kon­flikt inte­re­su? Jest sta­rym jak świat problemem”:

Nemoiudexincausasua– nikt nie może być sędzią we wła­snej spra­wie. Nullus ido­neus testis in re sua intel­le­gi­tur – nikt nie może być wia­ry­god­nym świad­kiem we wła­snej sprawie.

sta­ro­rzym­skie pare­mie prawnicze 

Dlatego dia­gram ten uzu­peł­ni­łem poka­zu­jąc trzy klu­czo­we role w pro­jek­cie inżynierskim:

Główny kon­flikt inte­re­su to zama­wia­ją­cy vs. wyko­naw­ca – kla­sycz­na sprzecz­ność ceny i jakość oraz zakre­su: zama­wia­ją­ce­mu zale­ży na mak­sy­ma­li­za­cji funk­cjo­nal­no­ści a wyko­naw­cy na: mini­ma­li­za­cji kosz­tów (pro­jekt fixed-pri­ce) lub mak­sy­ma­li­za­cji kosz­tów (pro­jekt T&M).

Dlatego po stro­nie zama­wia­ją­ce­go anga­żu­je­my pro­jek­tan­ta bo:

  • zama­wia­ją­cy nie ma tej kompetencji, 
  • odbie­ra­my te role wyko­naw­cy z powo­du ww. kon­flik­tu interesu.

Potencjalny kon­flikt inte­re­su mię­dzy pro­jek­tan­tem (usta­la zakres pro­jek­tu) a przy­szły­mi użyt­kow­ni­ka­mi (pod­wład­ni zama­wia­ją­ce­go mak­sy­ma­li­zu­ją­cy ten zakres) roz­wią­zu­je­my umo­co­wu­jąc” pro­jek­tan­ta na pozio­mie” spon­so­ra projektu. 

Praktyka poka­zu­je, że brak sepa­ra­cji ww. ról jest jed­ną z głów­nych przy­czyn nie­po­wo­dzeń pro­jek­tów w bran­ży IT:

ZARZĄDZANIE PROJEKTEM WE WŁASNYM ZAKRESIE JEST KRYTYCZNE: Integratorzy sys­te­mów mogą być cen­nym ele­men­tem cyfro­wej trans­for­ma­cji, ale nigdy nie powin­ni mieć cał­ko­wi­tej, nie­kon­tro­lo­wa­nej wła­dzy nad całym przed­się­wzię­ciem (źr. PORAŻKA CYFROWEJ TRANSFORMACJI W FIRMIE HERTZ, oryg. : THE HERTZ VS. ACCENTURE DISASTER)

Podsumowanie

Jak poka­za­no moż­na pro­jek­to­wać, nawet bar­dzo duże, sys­te­my infor­ma­tycz­ne nie robiąc tego meto­dą mitycz­ne wodo­spa­du (water­fall). Waterfall to meto­da (model) wytwa­rza­nia opro­gra­mo­wa­nia w jed­nym prze­bie­gu”, czy­li przy zało­że­niu, że pra­ce imple­men­ta­cyj­ne roz­po­czy­na­ją się dopie­ro po opra­co­wa­niu osta­tecz­nej spe­cy­fi­ka­cji sys­te­mu. Taki model wytwa­rza­nia jest cechą sys­te­mów o mono­li­tycz­nej archi­tek­tu­rze. Tu war­to pod­kre­ślić, że mono­li­tem jest tak­że modu­ło­wy sys­te­my zbu­do­wa­ny na jed­nej, cen­tral­nej bazie danych w mode­lu relacyjnym. 

Podział sys­te­mu na kom­po­nen­ty w pierw­szym eta­pie ana­li­zy i pro­jek­to­wa­nia (archi­tek­tu­ra wyso­kie­go pozio­mu) to dekom­po­zy­cja pro­ble­mu i opra­co­wa­nie roz­wią­za­nia pro­ble­mu. Kolejne pra­ce to raz z razem”, pro­jek­to­wa­nie deta­li kolej­ne­go okre­ślo­ne­go kom­po­nen­tu (archi­tek­tu­ra niskie­go pozio­mu), jego inte­gra­cja z już ist­nie­ją­cy­mi, i wdra­ża­nie. Tak powsta­ją bar­dzo spraw­nie, ite­ra­cyj­nie przy­ro­sto­wo, nawet bar­dzo duże sys­te­my i nie ma to nic wspól­ne­go z meto­dą zwa­na water­fall” .

Podkreślić tu nale­ży, że klu­czo­we dla pro­ce­su V‑model, jest to, że z zasa­dy imple­men­ta­cja poprze­dza­na jest pro­jek­to­wa­niem. Jest to ogrom­na zale­ta tej meto­dy, gdyż na dowol­nym eta­pie mamy doku­men­ta­cje opi­su­ją­ca dzia­ła­nie sys­te­mu. Ta (ta sama) doku­men­ta­cja jest wyma­ga­niem na począt­ku i opi­sem tech­nicz­nych na końcu. 

Jednym z naj­więk­szych pro­ble­mów w bran­ży infor­ma­tycz­nej jest nie­ak­tu­al­na doku­men­ta­cja opro­gra­mo­wa­nia lub jej brak (patrz arty­kuł Dług infor­ma­cyj­ny). V‑model to pro­ces usu­wa­ją­cy te wadę. Po dru­gie pra­ce kon­cep­cyj­no-pro­jek­to­we na mode­lach (a nie na kodzie) są znacz­nie efek­tyw­niej­sze i tań­sze. Praktyka two­rze­nia doku­men­ta­cji dopie­ro po odda­niu opro­gra­mo­wa­nia do użyt­ku, jest bar­dzo kosz­tow­na i nie­efek­tyw­na, oraz obar­czo­na dużym ryzy­kiem, pominięć. 

Kluczem zaś jest sepa­ro­wa­nie ról z kon­flik­tem interesu. 

Źródła

Maciej Wnuk. (2015). Konflikt inte­re­sów czym jest i jak go uni­kać? Ministerstwo Spraw Zagranicznych. https://​www​.gov​.pl/​a​t​t​a​c​h​m​e​n​t​/​3​a​d​8​b​5​9​f​-​4​940 – 4fe7-8441 – 755cc9a52af8
Clark, J. O. (2009). System of Systems Engineering and Family of Systems Engineering from a stan­dards, V‑Model, and Dual‑V Model per­spec­ti­ve. 2009 3rd Annual IEEE Systems Conference, 381 – 387. https://​doi​.org/​1​0​.​1​1​0​9​/​S​Y​S​T​E​M​S​.​2​0​0​9​.​4​8​1​5​831
Graessler, I., & Hentze, J. (2020). The new V‑Model of VDI 2206 and its vali­da­tion. At – Automatisierungstechnik, 68(5), 312 – 324. https://​doi​.org/​1​0​.​1​5​1​5​/​a​u​t​o​-​2​020 – 0015
Mathur, S., & Malik, S. (2010). Advancements in the V‑Model. International Journal of Computer Applications, 1(12), 29 – 34.
Friman, E. (2020). BUILDING AND ADAPTING SYSML BASED SYSTEM ARCHITECTURE FRAMEWORK FOR MECHATRTONIC SYSTEMS. 75.
Arroyo, J. C. T. (2020). Analysis and Design of Enterprise Resource Planning System for a Coffee Shop. International Journal of Advanced Trends in Computer Science and Engineering, 9(3), 2972 – 2980. https://​doi​.org/​1​0​.​3​0​5​3​4​/​i​j​a​t​c​s​e​/​2​0​2​0​/​7​4​9​3​2​020

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.