Wzorzec analityczny Boundary Control Entity i ICONIX a także MVC i MVVM

Opisywałem ostat­nio wzo­rzec DDD jako narzę­dzie doku­men­to­wa­nia ana­li­zy. Faktycznie, czy­tel­ni­cy mają wie­le racji, jest on dość bli­ski imple­men­ta­cji”. Niejednokrotnie lep­szym pomy­słem” jest opis logi­ki sys­te­mu na nie­co wyż­szym pozio­mie abs­trak­cji pozo­sta­wia­jąc tym samym wię­cej swo­bo­dy deve­lo­pe­ro­wi. […] Nieco inne podej­ście, to któ­re sto­su­ję obec­nie, opi­su­ję poni­żej. Zachowując pod­sta­wo­we zna­cze­nia tych trzech klas, dosto­so­wa­łem je do wzor­ca MVVC. Jest to o tyle wygod­ne i waż­ne, że sto­so­wa­nie wzor­ca BCE wyłącz­nie do mode­lo­wa­nia logi­ki biz­ne­so­wej wyma­ga zacho­wa­nia her­me­ty­za­cji kom­po­nen­tu Model. W takim ukła­dzie boun­da­ry nie będzie ele­men­tem kom­po­nen­tu View a Modelu. Jego rola to stwo­rze­nie dedy­ko­wa­ne­go inter­fej­su do model np. pomię­dzy kom­po­nen­tem View lub Controlerem. Dzięki temu moż­li­we jest stwo­rze­nie odręb­ne­go inter­fej­su dla View na duży ekran i odręb­ne­go dla View na np. małych ekra­nach smart­fo­nów. Tak więc jest moim zda­niem dro­ga do mode­lo­wa­nia wyma­gań meto­dą tak to ma dzia­łać” a nie tyl­ko tak to ma wyglą­dać”, bo to dru­gie jest przy­czy­ną wie­lu problemów…

Czytaj dalej Wzorzec analityczny Boundary Control Entity i ICONIX a także MVC i MVVM

Poziomy szczegółowości wymagań – wzorce DDD – czyli czym jest analiza obiektowa

Kim więc jest dobry analityk?

Jest to pro­jek­tant, któ­ry potra­fi ana­li­zo­wa­ną orga­ni­za­cję roz­ło­żyć na ele­men­ty skła­do­we”. Tymi ele­men­ta­mi są wzor­ce pro­jek­to­we, ele­men­ty sto­so­wa­nej nota­cji. Wynik ana­li­zy to nie rysu­nek”. Jest mode­lem w posta­ci sche­ma­tu blo­ko­we­go (dia­gra­mu), na któ­rym każ­dy ele­ment ma ści­śle okre­ślo­ne znacz­nie, kon­struk­cję i zasa­dy wza­jem­ne­go łączenia.

Analiza Biznesowa to roz­ło­że­nie ana­li­zo­wa­ne­go przed­mio­tu” na skoń­czo­ny zestaw ele­men­tów, któ­ry z okre­ślo­ną dokład­no­ścią zacho­wu­je się jak ana­li­zo­wa­na orga­ni­za­cja. Jeżeli te ele­men­ty skła­do­we mają tak­że swo­je odwzo­ro­wa­nie w kodzie pro­gra­mu, to wynik ana­li­zy sta­je się pro­jek­tem tego oprogramowania.

Poziomy szcze­gó­ło­wo­ści wyma­gań to:

cele biz­ne­so­we (pro­duk­ty pro­ce­sów biznesowych)
opis usług żąda­nych od opro­gra­mo­wa­nia (tu tak­że for­mat­ki papierowe/ekranowe, przy­pad­ki uży­cia oprogramowania)
opis (pro­jekt) wewnętrz­nej logi­ki biz­ne­so­wej (wewnętrz­ne ele­men­ty skła­do­we i sce­na­riu­sze ich współdziałania)

Czytaj dalej Poziomy szczegółowości wymagań – wzorce DDD – czyli czym jest analiza obiektowa

Projekt wykonany – co było robione

Powyższe jest zgod­ne z zale­ce­nia­mi OMG​.org (https://​www​.omg​.org/​mda), audyt to etap CIM a pro­jek­to­wa­nie przy­pad­ków uży­ci i mode­lu dzie­dzi­ny to etap PIM.

Wykonanie takiej ana­li­zy jest pra­co­chłon­ne i wyma­ga duże­go doświad­cze­nia, umie­jęt­no­ści ana­liz pro­ce­sów biz­ne­so­wych, pro­jek­to­wa­nia obiek­to­we­go i dobre­go narzę­dzia CASE, jed­nak mode­le te pozwa­la­ją tak­że prze­pro­wa­dzić ana­li­zy wpły­wu (zależ­no­ści pomię­dzy pro­ce­sa­mi, skut­ki i podat­ność na awa­rie opro­gra­mo­wa­nia itp.) oraz zre­du­ko­wać do mini­mum praw­do­po­do­bień­stwo prze­kro­cze­nia ter­mi­nu i kosz­tów (sta­ty­sty­ki wska­zu­ją na śred­nie prze­kro­cze­nie kosz­tów o 60% i ter­mi­nów o 200% pro­jek­tów z niskiej jako­ści spe­cy­fi­ka­cji wyma­gań). Praktyka auto­ra wska­zu­je, że war­to taką ana­li­zę prze­pro­wa­dzić dla pro­jek­tów, któ­rych budżet prze­kra­cza 50 – 70 tys, zł i większych.

Czytaj dalej Projekt wykonany – co było robione

Proces zbierania i analizy wymagań u developera

Analiza Biznesowa i spe­cy­fi­ka­cja wyma­gań opra­co­wa­na meto­dą opi­sy­wa­ną tu i na stro­nach OMG, jest od tej ostat­niej (gru­pa kon­sul­tan­tów i sesje warsz­ta­to­we) znacz­nie tań­sza. W cza­sie trwa podob­nie, jed­nak robi to z regu­ły jed­na oso­ba (tak! ale przy zało­że­niu ma sto­su­je zaawan­so­wa­ne narzę­dzia CASE nie tyl­ko do two­rze­nia dia­gra­mów ale tak­że do ich wery­fi­ka­cji śla­do­wa­nia zarzą­dza­nia spój­no­ścią mode­li itp.), a efek­tem jest pro­jekt logicz­ny a nie dopie­ro lista wyma­ga­nych cech. Korzyść jest więc podwój­na. Jeżeli zro­bi to Analityk wyna­ję­ty przez Klienta a nie Dostawcy, to wszel­kie pra­wa (know-how) do pro­jek­tu pozo­sta­ją po stro­nie nabywcy.

Można powie­dzieć, że to trud­ne i kosz­tow­ne. Trudne owszem, wyma­ga doświad­cze­nia i wie­dzy zarów­no z zakre­su zarzą­dza­nia jak i inży­nie­rii opro­gra­mo­wa­nia. Per sal­do, wli­cza­jąc w to kosz­ty mody­fi­ka­cji na eta­pie wdra­ża­nia i odkry­wa­nia wyma­gań (wady spe­cy­fi­ka­cji nie pod­da­ją­cej się wery­fi­ka­cji) jest to pro­ces zawsze tań­szy (bada­nia kie­row­ni­ków pro­jek­tów wska­zu­ją, że zła jakość wyma­gań gene­ru­je dodat­ko­we kosz­ty rzę­du 60% war­to­ści pro­jek­tu, koszt takiej ana­li­zy nie prze­kra­cza zaś 20%). Do tego poja­wia­ją się poten­cjal­ne kosz­ty nie­ujaw­nio­ne klien­to­wi: pra­wa autor­skie do pro­jek­tu i apli­ka­cji. Jeżeli fir­ma będą­ca wyko­naw­ca opro­gra­mo­wa­nia robi ana­li­zę swo­je­go klien­ta i potem mu sprze­da­je pra­wa do jej wyni­ków wraz z dostar­cza­nym opro­gra­mo­wa­niem, to jest to kla­sycz­ny przy­pa­dek aneg­do­ty o kon­sul­tan­tach, któ­rzy zapy­ta­ni o to któ­ra jest godzi­na, pro­szą Cie o Twój zega­rek, odpo­wia­da­ją na pyta­nie któ­ra godzi­na i wysta­wia­ją fak­tu­rę za usłu­gę i tak­że za zwra­ca­ny Ci Twój zegarek.

Czytaj dalej Proces zbierania i analizy wymagań u developera

Sprzedam Ci prawa do kodu czyli wielka ściema

A może chce­cie pra­wa do kodu źródłowego?

A jasne, może­my chcieć. No to zapłać­cie za to pra­wo”. A prze­pra­szam za co teraz? Kod, któ­ry powstał to utwór zależ­ny, jest więc chro­nio­ny i już mamy na nie­go wyłącz­ność, nie musi­my eks­tra za to pła­cić. Ale nie chce­my tego sami pisać (kodo­wać) jesz­cze raz. No dobrze, patrzy­my na fak­tu­ry, a tam jest kil­ka­set godzin pro­gra­mi­stów. Czyli co? Już zapła­ci­li­śmy za ich pra­cę, za ten kod! Wystarczy!

Kiedy poja­wia się problem?

W więk­szo­ści przy­pad­ków z jaki­mi się nie­ste­ty spo­ty­kam to pro­jek­ty, w któ­rych nie powsta­ła opi­sa­na tu doku­men­ta­cja. Jaki mamy efekt? No jest kod, wszel­kie pra­wa do nie­go i jego logi­ki ma wyko­naw­ca (jest auto­rem cało­ści). Specyfikacja wyma­gań funk­cjo­nal­nych i poza-funk­cjo­nal­nych pod­le­ga wyłącz­nie ochro­nie jako dzie­ło lite­rac­kie, jed­nak nie­ste­ty to-co-pro­gram-ma-robić to tyl­ko idea, a ta nie pod­le­ga ochro­nie (stwier­dze­nie fak­tu, że wysta­wia­my fak­tu­ry, jako treść, nie sta­no­wi żad­ne­go zdat­ne­go do ochro­ny tajem­ni­cą fir­my know-how). Tak więc wszel­kie pra­wa do kodu ma w takim wypad­ku pro­gra­mi­sta bo sam od zera to napi­sał (kod).

Pada pro­po­zy­cja: za dodat­ko­we pie­nią­dze sprze­da­my pra­wa mająt­ko­we do kodu, będzie­cie się Państwo czu­li bez­piecz­nie. I teraz pyta­nie: jaką war­tość ma nie­udo­ku­men­to­wa­ny kod opro­gra­mo­wa­nia? Tysiące linii kodu pro­gra­mu, nie raz kil­ka milio­nów, pisa­ny bez pro­jek­tu w wie­lu ite­ra­cjach. Mamy któ­rąś tam jego wer­sję, w koń­cu powsta­wał w bólach, wie­lo­krot­nie mody­fi­ko­wa­ny, bez pro­jek­tu. Nakład pra­cy znacz­nie prze­wyż­sza­ją­cy jego prze­pi­sa­nie. Kto i jakim kosz­tem będzie ten kod ana­li­zo­wał by go zro­zu­mieć i roz­wi­jać? Ten kod, bez jego auto­ra, jest BEZWARTOŚCIOWY a My, bez tej opła­ty, nie mamy żad­nych praw do tego za co zapła­ci­li­śmy (poza licen­cją czy­li pra­wem do korzystania).

Tak więc nie­jed­no­krot­nie ofer­ta na sprze­daż praw do kodu to zwy­kła ściema!

Czytaj dalej Sprzedam Ci prawa do kodu czyli wielka ściema

Podkasty czyli opowiadam o tym co proponuję

"Jeśli chcesz opisać prawdę, elegancję zostaw krawcom."(A. Einstein) Poniżej wybrane moje wystąpienia. Regularnie dzielę się wiedzą na konferencjach, bywam zapraszany przez dostawców oprogramowania ERP by opowiedzieć ich klientom jak podejść…

Czytaj dalej Podkasty czyli opowiadam o tym co proponuję

Reguły biznesowe jako motor sterujący organizacji: fakty + definicje pojęć

Mapa (model) pro­ce­sów oraz struk­tu­ra orga­ni­za­cyj­na, by były jed­no­znacz­ne, muszą być tak­że zesta­wem zde­fi­nio­wa­nych pojęć. Musimy wie­dzieć co zna­czy sło­wo: prze­ło­żo­ny, pod­wład­ny, komór­ka orga­ni­za­cyj­na czy jej kie­row­nik. Jeszcze więk­szym wyzwa­niem zde­fi­nio­wa­nie sys­te­mu pojęć dla mapy pro­ce­sów (pro­ces, czyn­ność, zda­rze­nie, doku­ment…). Budowanie sys­te­mów poję­cio­wych speł­nia­ją­cych powyż­sze warun­ki jest bar­dzo trud­ne dla­te­go dla mode­li pro­ce­sów biz­ne­so­wych naj­le­piej wyko­rzy­stać goto­wy model poję­cio­wy: jest nim nota­cja. Najlepiej obec­nie opra­co­wa­nym takim mode­lem poję­cio­wym jest goto­wa nota­cja [[BPMN]]. Tworzenie wła­snych jest kosz­tow­ne (czas i wie­dza oso­by opra­co­wu­ją­cej) i bar­dzo ryzy­kow­ne (może się nie udać). Dlatego uży­wa­nie dzi­siaj wła­snych lub innych (np. dosto­so­wy­wa­ne pro­fi­la­mi dia­gra­my UML) jest w moich oczach nie­ra­cjo­nal­nym podejściem.

Model pojęć spe­cy­ficz­ny dla danej orga­ni­za­cji nie­ste­ty musi powstać od zera”, podob­nie jak powią­za­na z nim spe­cy­fiak­cja reguł biz­ne­so­wych. Jest to trud­ne bo two­rze­nie prze­strze­ni nazw wyma­ga utrzy­ma­nia nie­za­leż­no­ści poszcze­gól­nych defi­ni­cji i spój­no­ści i zupeł­no­ści całe­go ich sys­te­mu. Niedochowanie tych wyma­gań pro­wa­dzi do nie­peł­no­ści a nawet sprzecz­no­ści reguł biz­ne­so­wych, któ­re w koń­cu są budo­wa­ne (odkry­wa­ne i doku­men­to­wa­ne) z pomo­cą tych pojęć. Zanim wiec zaan­ga­żu­jesz kogoś do mode­lo­wa­nia wła­snej fir­my, upew­nij się, komu zle­casz tę pracę… 

W bar­dzo dużym więc skrócie:

pro­ce­sy biz­ne­so­we to fak­tycz­ny, widocz­ny spo­sób pra­cy firm (ludzi w nich zatrudnionych),
pro­ce­sy to efekt funk­cjo­no­wa­nia ludzi w śro­do­wi­sku ograniczeń,
nale­ży poznać tych ludzi,
ogra­ni­cze­nia to: pro­ce­du­ry, pra­wo, zarzą­dze­nia wewnętrz­ne oraz spe­cy­ficz­ne dla fir­my wewnętrz­ne nor­my zwa­ne regu­ła­mi biznesowymi,
opra­co­wa­nie biz­ne­so­we­go mode­lu fir­my wyma­ga zro­zu­mie­nia i opi­sa­nia tego co powy­żej opisałem,
nie ist­nie­je dro­ga na skróty.

Czytaj dalej Reguły biznesowe jako motor sterujący organizacji: fakty + definicje pojęć

Udziałowcy projektu czyli który diagram UML …

Stosowanie reguł (seman­ty­ki i syn­tak­ty­ki) UML pozwa­la utrzy­mać spój­ność mode­li zależ­nych (pod­le­głe temu dia­gra­mo­wi uszcze­gó­ło­wie­nia Projektu Systemu, reali­za­cja Aktorów, przy­pad­ki uży­cia itp.) oraz zacho­wać spój­ność logicz­ną i poję­cio­wą całej doku­men­ta­cji. To zaś jest warun­kiem wery­fi­ka­cji popraw­no­ści całe­go projektu. 

UML to nota­cja, któ­rej klu­czo­wym poję­ciem jest kla­sy­fi­ka­tor (opar­ta jest na defi­nio­wa­nych poję­ciach i rela­cjach mię­dzy nimi) dla­te­go war­to prze­strze­gać (zawsze war­to) zasad nota­cji i np. nie utoż­sa­miać Aktora System CRM (jest to jakaś abs­trak­cja sys­te­mu inte­gro­wa­ne­go) z kon­kret­nym Jakimś Systemem CRM. Aktor ma kon­kret­ne zna­cze­nie na dia­gra­mie UML (zde­fi­nio­wa­ne wyżej) i kon­kret­ny sys­tem tak­że. Zachowanie tego podzia­łu (abs­trak­cja i jej reali­za­cja) pozwa­la zde­fi­nio­wać oddziel­nie wyma­ga­nia i oddziel­nie kon­kret­ne roz­wią­za­nia je speł­nia­ją­ce co jest isto­tą roz­dzia­łu wyma­gań od speł­nia­ją­cych je rozwiązań. 

Diagramy przy­pad­ków uży­cia są bar­dzo waż­ny­mi dia­gra­ma­mi, gdyż sta­no­wią korzeń” mode­lu reali­za­cji sys­te­mu zaś łama­nie zasad nota­cji pro­wa­dzi prak­tycz­nie zawsze do utra­ty moż­li­wo­ści ich, mode­li, weryfikacji.

Czytaj dalej Udziałowcy projektu czyli który diagram UML …