Struktura projektu UML

V‑model i zarządzanie jakością

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 :

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

Balaji, S., & Murugaiyan, M. S. (2012). Waterfall vs. V‑Model vs. Agile: A com­pa­ra­ti­ve stu­dy on SDLC. International Journal of Information Technology and Business Management, 2(1), 26 – 30.
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

Dlaczego tradycyjne metody zarządzania nie działają w projektach internetowych?

Jest dość licz­na gru­pa ludzi uwa­ża­ją­ca, że w Internecie nie obo­wią­zu­ją ani pra­wa fizy­ki, ani pra­wa eko­no­mii ani nawet zdro­wy roz­są­dek. W kwe­stii inży­nie­rii opro­gra­mo­wa­nia ludzie Ci stra­szą świat pro­jek­tów mitycz­nym wodo­spa­dem” jak kie­dyś dzie­ci stra­szo­ne były Babą Jagą.

[dzień po napi­sa­niu: po dys­ku­sji – patrz treść pod tym wpi­sem – a auto­rem cyto­wa­ne­go tu arty­ku­łu, doszli­śmy do wnio­sku, że nie róż­ni­my się zbyt­nio w poglą­dach, jed­nak zbyt­nie uprosz­cze­nie tre­ści mia­ło pra­wo wpro­wa­dzić mnie w błąd, jed­nak mój arty­kuł pozo­sta­nie w pier­wot­nej tre­ści bo pole­mi­zu­je głów­nie z pew­nym mitem a nie tym autorem]. 

Poniżej kolej­ny tego typu star­szak” o zna­mien­nym tytu­le Dlaczego tra­dy­cyj­ne meto­dy zarzą­dza­nia nie dzia­ła­ją w pro­jek­tach inter­ne­to­wych?” Szczerze mówiąc jak to czy­tam, natych­miast przy­po­mi­na mi się sta­re i wykpi­wa­ne w cza­sach sta­li­now­skich, obo­wiąz­ko­we wypra­co­wa­nie w szko­le na temat Dlaczego kocha­my Lenina” (bo, że go nie kocha­my wte­dy nie wcho­dzi­ło w grę).

Tu mamy dość cie­ka­wy przy­kład zastra­sze­nia, autor cyto­wa­ne­go arty­ku­łu uwa­ża, że pro­jek­ty inter­ne­to­we rzą­dzą się inny­mi prawami:

Mamy pomysł, ustal­my zakres oraz har­mo­no­gram na naj­bliż­sze 7 mie­się­cy, reali­zu­je­my pro­jekt i na koń­cu wpro­wadź­my pro­dukt na rynek. Oczywiście za nie­ma­łe pie­nią­dze. Czy war­to tak szcze­gó­ło­wa pla­no­wać swo­je nowe przed­się­wzię­cia? Czy war­to tak dłu­go dopiesz­czać swój pomysł?

waterfall_wiki

Jaką sku­tecz­ność w prze­wi­dy­wa­niu przy­szło­ści mają spe­cja­li­ści? Takie pyta­nie zadał sobie przed 10 laty Philip Tetlock, zna­ny ame­ry­kań­ski psy­cho­log. Przez dobrych kil­ka lat zbie­rał wśród mię­dzy­na­ro­do­wej śmie­tan­ki ana­li­ty­ków opi­nie na temat przy­szłych wyda­rzeń eko­no­micz­nych i poli­tycz­nych. Udało mu się uzy­skać ponad 82 tys. eks­perc­kich prze­po­wied­ni. (Dlaczego tra­dy­cyj­ne meto­dy zarzą­dza­nia nie dzia­ła­ją w pro­jek­tach internetowych?).

Drobne iro­nie w sty­lu za nie­ma­łe pie­nią­dze” to pró­by mani­pu­la­cji, któ­re pomi­jam. Po pierw­sze autor powo­łu­je się wyni­ki bada­nia, któ­re potwier­dza, że meto­dy heu­ry­stycz­ne się nie spraw­dza­ją jako meto­da pro­gno­zo­wa­nia, fakt zna­ny od daw­na w krę­gach nauki (pisa­łem o tym w Mucha…) i fak­tem jest, że takie (na bazie wie­dzy z okre­sów minio­nych) pro­gno­zo­wa­nie nie ma sen­su. Tu z auto­rem peł­na zgo­da. Ale jak się to ma do pro­jek­tów pro­gra­mi­stycz­nych? Nijak się nie ma, bo takich pro­gnoz nikt roz­sąd­ny nie robi w projekcie.

W inży­nie­rii opro­gra­mo­wa­nia nie pro­gno­zu­je się , bo to dome­na biz­ne­so­wa, w inży­nie­rii opro­gra­mo­wa­nia dąży się do zro­zu­mie­nia isto­ty pro­ble­mu imple­men­ta­cji. Czy ana­li­za i pro­jek­to­wa­nie to dłu­gie, szcze­gó­ło­we i zbęd­ne pla­no­wa­nie? Nie. Analiza ma za cel zro­zu­mie­nie i pod­ję­cie decy­zji o spo­so­bie imple­men­ta­cji. Jeżeli moż­na tu mówić o pla­no­wa­niu to raczej w kate­go­riach jak pla­nu­je­my zaim­ple­men­to­wać” to roz­wią­za­nie (któ­rym jest speł­nie­nie wyma­gań biznesu).

Owszem, moż­na pro­wa­dzić imple­men­ta­cje meto­dą pro­to­ty­pów, błą­dząc, z nadzie­ją, że szyb­ko (przy­pad­kiem) stwo­rzy­my dobre roz­wią­za­nie. Ale to w szcze­gól­no­ści trud­no zapla­no­wać (a nawet start-upy maja budże­ty). Czy to jest tań­sze? Nie sądzę. Nazywam to syn­dro­mem LOTTO: szyb­ka decy­zja bez pla­no­wa­nie daje pew­ne szan­se na odkry­cie popraw­ne­go roz­wią­za­nia, jed­nak to to samo co uzna­nie, że moż­na gra­jąc w LOTTO zaro­bić na bie­żą­ce życie aż do śmier­ci. Owszem, jest to moż­li­we, ale uda­je się nie­licz­nym (i wie­my dlaczego).

Start-upy nie­wąt­pli­wie mają swo­je pra­wa, i tu autor ma racje, twier­dząc, że nie ma cza­su”, jed­nak nie praw­dą jest, że:

Problem jest tyl­ko taki, że wszyst­ko, co na począt­ku usta­li­li­śmy to zwy­kłe prze­wi­dy­wa­nia naszych ?inter­ne­to­wych eko­no­mi­stów?. Całe nasze uza­sad­nie­nie biz­ne­so­we (model biz­ne­so­wy) jest prze­wi­dy­wa­niem, cały nasz zło­ty trój­ką pro­jek­tu (czas, zakres, budżet) jest prze­wi­dy­wa­niem. A jak dobrze wie­my, dzię­ki bada­niom Tetlocka, ludzie prze­wi­dy­wać dobrze nie potra­fią. Szczególnie w nowych warunkach.

Łączenie trój­ką­ta pro­jek­to­we­go” z pro­gno­za­mi biz­ne­so­wy­mi jest albo nie­po­ro­zu­mie­niem, albo nie­wie­dzą, albo cyni­zmem: model biz­ne­so­wy nie jest pro­gno­zą, model biz­ne­so­wy to opis spo­so­bu gene­ro­wa­nia war­to­ści doda­nej. Prognozą może być co naj­wy­żej plan przy­cho­dów z tej działalności.

Bo po pierw­sze w two­rze­niu mode­lu biz­ne­so­we­go, nie ma mowy o prze­wi­dy­wa­niu przy­szło­ści a o ana­li­zie gru­py doce­lo­wej. Wskazany zaś trój­kąt pro­jek­to­wy (zakres, ter­min, budżet) to plan wytwo­rze­nia kon­kret­ne­go opro­gra­mo­wa­nia (wspie­ra­ją­ce­go ten model biz­ne­so­wy). Owszem, tu – model biz­ne­so­wy – moż­na się pomy­lić, ale to nie pomył­ka pro­gno­zo­wa­nia tyl­ko np. zła decy­zja mar­ke­tin­go­wa. Teza, że np. moje kape­lu­sze będą mia­ły duży zbyt w gro­nie sno­bów”, to nie pro­gno­zo­wa­nie a plan mar­ke­tin­go­wy. Prognozowaniem było by stwier­dze­nie, że sprze­daż kape­lu­szy dla sno­bów osią­gnie 10 tys. szt. w cią­gu naj­bliż­sze­go roku” i tu fak­tycz­nie moż­na się nie­źle pomy­lić. Nie zmie­nia to fak­tu, że kape­lusz to kape­lusz i nale­ży go zapro­jek­to­wać i wytwo­rzyć, opro­gra­mo­wa­nie wspo­ma­ga­ją­ce sprze­daż kape­lu­szy przez inter­net (jego funk­cjo­nal­ność) nie zale­ży od ilo­ści sprze­da­ży (poza wydaj­no­ścią cało­ści) tyl­ko od tego co i jak chce­my sprzedawać.

Jednak nie zmie­nia to fak­tu, że pro­gram wspie­ra­ją­cy sprze­daż tych kape­lu­szy wyma­ga pew­nej ana­li­zy by zapro­jek­to­wać model dzie­dzi­ny tego opro­gra­mo­wa­nia, tu błąd kosz­tu­je cza­sem tyle, że wyma­ga­ny refak­to­ring (bez któ­re­go nie zre­ali­zu­je­my np. kolej­nej nowej potrzeb­nej funk­cjo­nal­no­ści) ad-hoc pisa­ne­go opro­gra­mo­wa­nia zabi­je budżet całe­go pro­jek­tu. To wyglą­da mniej wię­cej tak (źr. Znaczenie ma nie wiel­kość pro­jek­tu…):

Cykl życia aplikacji

Powyżej wykres poka­zu­ją­cy kosz­ty chwi­lo­we (linia cią­gła) i nara­sta­ją­ce (linia prze­ry­wa­na) pro­jek­tu two­rze­nia i utrzy­ma­nia opro­gra­mo­wa­nia. Linia zie­lo­na to pro­ces z dobrze opra­co­wa­nym pro­jek­tem na począt­ku, czer­wo­na to pro­jekt na żywioł”. 

Racje ma autor pisząc, że w przy­pad­ku start-upów może być dużym ryzy­kiem inwe­sto­wa­nie w pro­jek­to­wa­nie cze­goś co może oka­zać się nie­wy­pa­łem, jed­nak trze­ba pamię­tać, że jeże­li pro­jekt wypa­li, pra­wie na pew­no będzie wyma­gał wte­dy refak­to­rin­gu, by krzy­wa utrzy­ma­nia była jed­nak bliż­sza tej zie­lo­nej (niskie kosz­ty sta­łe to więk­sza marża).

Wodospad, któ­rym się star­szy dzie­ci” to przede wszyst­kim nie linio­wy” pro­jekt na lata (czy jak u auto­ra cyta­tów: 7 mie­się­cy start-up). Wodospad dzi­siaj to jedy­nie uzna­nie, że trzy fazy: ana­li­za, pro­jek­to­wa­nie, imple­men­ta­cja, są nie­roz­łącz­ne z czy­ste­go roz­sąd­ku. Prawda jest, że każ­da pro­gno­za wią­że się z ryzy­kiem, jeże­li uzna­my że jest ono duże (a z regu­ły jest), to nie pla­nu­je­my jak kiedyś:

Ryzyko projektu 1

(typo­wy struk­tu­ral­ny pro­ces), tyl­ko dzie­li­my pro­jekt na eta­py (kolej­ne funk­cjo­nal­no­ści) o dłu­go­ści na tyle krót­kiej, by błę­dy pro­gno­zy były akcep­to­wal­ne i nie nisz­czy­ły pro­jek­tu. Wtedy pro­jekt cha­rak­te­ry­zu­je się takim cyklem:

Ryzyko projektu 2

(źr. Mega pro­jek­ty…)

U auto­ra cyta­tów znaj­dzie­my bar­dzo podob­ny wykres, z jed­ną róż­ni­cą: tam jest to szu­ka­nie roz­wią­za­nia meto­dą pro­to­ty­pów, czy­li każ­da dotych­cza­so­wa pra­ca idzie do kosza. W tym przy­pad­ku, jest to prze­my­śla­ny pro­ces, powsta­ły już kod nie jest wyrzu­ca­ny, ale to wyma­ga dobre­go pro­jek­tu (szkie­le­tu archi­tek­tu­ry), obiek­to­wych metod i zasto­so­wa­nia wzor­ców analitycznych.

Autor arty­ku­łu pisze:

Mamy okre­ślo­ny cel biz­ne­so­wy. Nie wie­my, nie zna­my i nie mamy łatwe­go dostę­pu do naj­waż­niej­sze­go udzia­łow­ca ? użyt­kow­ni­ka, nie wie­my, co zro­bić, żeby speł­nić cel biz­ne­so­wy (zakres), tym samym nie wie­my, ile to będzie kosz­to­wać (budżet) i na kie­dy się uda go osią­gnąć (czas).

Wiemy nato­miast, że na pew­no będą zmia­ny i trze­ba jak naj­szyb­ciej z pro­duk­tem pro­jek­tu wejść na rynek.

Współczuję każ­de­mu, kto w tak eks­tre­mal­nych warun­kach, przy tak wiel­kim stop­niu nie­pew­no­ści musi tra­dy­cyj­ny­mi meto­da­mi reali­zo­wać projekt.

Od razu przy­po­mnę, że da się nowo­cze­sny­mi meto­da­mi two­rzyć opro­gra­mo­wa­nie odpo­wia­da­ją­ce powyż­szym wyma­ga­niom: to ma już nawet nawet ład­ną nazwę: SOLID gdzie klu­czo­wą cechą jest to, że tak pro­jek­to­wa­ne i wyko­ny­wa­ne opro­gra­mo­wa­nie jest zamknię­te na zmia­ny i otwar­te na roz­sze­rze­nia” (nie mylić zmian kodu ze zmia­ną stra­te­gii sprze­da­ży), ozna­cza to, że kod nie wyma­ga zmian (refak­to­ring, odrzu­ca­nie pro­to­ty­pów) a pozwa­la na roz­sze­rze­nia (nowe wyma­ga­nia). Metody obiek­to­we to nic inne­go jak odpo­wiedź na powyż­sze potrze­by. Jeżeli autor miał na myśli tra­dy­cyj­ne meto­dy w rodza­ju baza danych i funk­cje” to jestem po jego stro­nie, też współczuję.

Paradoksalnie to co opi­sa­łem jest tań­sze, bo nie­mal­że nic nie idzie do kosza. Każdy etap jest krót­ki więc pra­wie pew­ny”, nie­mal­że żad­na pra­ca nie idzie na mar­ne, sys­tem nie wyma­ga per­ma­nent­nej refak­to­ry­za­cji. Co tu jest waż­ne: zacho­wu­je­my cykl: ana­li­za, pro­jek­to­wa­nie, imple­men­ta­cja. Są to wte­dy krót­kie ite­ra­cje, ale zawsze kodo­wa­nie poprze­dza­my ana­li­zą dzie­dzi­ny. Druga waż­na rzecz: nie da się tak pro­wa­dzić pro­jek­tu meto­da­mi struk­tu­ral­ny­mi (naj­pierw baza danych, potem funk­cje) bo model bazy danych z zasa­dy obej­mu­je całą dzie­dzi­nę pro­ble­mu, a tej, jak słusz­nie zauwa­ża autor, nie zna­my (dłu­go­ter­mi­no­wa prognoza). 

Druga wer­sja (opi­sa­na powy­żej) jest rela­tyw­nie tania, moż­na prze­rwać w dowol­nym momen­cie i nie prze­in­we­sto­wać. Jednak rezy­gna­cja z ana­li­zy, któ­rej celem jest zro­zu­mie­nie pro­ble­mu i zde­cy­do­wa­nie o spo­so­bie imple­men­ta­cji to szu­ka­nie kło­po­tów takich jak ten:

most, agile, projektowanie, planowanie

Jak wyglą­da takie «wzor­co­we” pro­jek­to­wa­nie opi­sa­łem w arty­ku­le Plansza do gry w szachy…

Na koniec co nie­co o ryzyku:

ryzyko, popper, decyzje
(Karl Popper)

Tak więc nie ma metod jedy­nie słusz­nych (zwin­ne i nie­zwin­ne, itp.) , są tyl­ko ade­kwat­ne do sytu­acji projektowej.

Nie ma sen­su stra­sze­nie ludzie pro­ble­ma­mi inży­nie­rii opro­gra­mo­wa­nia z przed 30 lat (meto­dy struk­tu­ral­ne ana­li­zy i pro­jek­to­wa­nia, kosz­tow­ny water­fall)!. Mamy dziś rok 2013, dobrze roz­wi­nię­te meto­dy obiek­to­we ana­li­zy, pro­jek­to­wa­nia, mode­lo­wa­nia, imple­men­ta­cji. Aplikacje biz­ne­so­we moż­na wręcz linio­wo two­rzyć i roz­wi­jać, wystar­czy chcieć przejść na inne meto­dy pra­cy niż te, któ­rych (nie­ste­ty) nadal uczą na stu­diach: funk­cje + struk­tu­ry danych = opro­gra­mo­wa­nie” bo to prehistoria.

Tak zwa­ne pro­jek­ty inter­ne­to­we to tak­że opro­gra­mo­wa­nie, tu tak­że obo­wią­zu­ją pra­wa fizy­ki i eko­no­mii oraz roz­są­dek”. Jeżeli coś je odróż­nia o innych to uży­ta tech­no­lo­gia inter­ne­to­wa” a i to coraz mniej, bo obec­ne opro­gra­mo­wa­nie biz­ne­so­we to coraz częściej„system dostęp­ny przez internet”…

Na pew­no wszel­kie start-up’y to pro­jek­ty inne”, ale to wyni­ka z ich natu­ry biz­ne­so­wej (ryzy­ko powo­dze­nia) a nie tech­no­lo­gicz­nej. Mylenie tych pojęć pro­wa­dzi do wnio­sku, że np. nowy samo­chód pro­to­ty­po­wy kon­stru­uje się ina­czej niż standardowy”.…nie, ina­czej pla­nu­je się finan­so­wa­nie ale deska kre­ślar­ska pozo­sta­je ta sama…

A na tytu­ło­we pyta­nie odpo­wiedź brzmi: nie ist­nie­je taki problem.