Biznesowy model danych – nie chcemy

Nadal obser­wu­ję to, że model rela­cyj­ny i two­rze­nie mode­li danych na eta­pie ana­li­zy wyma­gań” trzy­ma­ją się twar­do mimo tego, że nie wie­le wno­szą do pro­jek­tu a narzu­ca­ją (suge­ru­ją) kiep­ską archi­tek­tu­rę apli­ka­cji z jed­ną rela­cyj­na bazą danych. Co cie­ka­we zaczy­na­nie od bazy danych jest wręcz zaprze­cze­niem zwin­no­ści (koniecz­ność ukoń­cze­nia pro­jek­tu doce­lo­wej bazy danych przed roz­po­czę­ciem kodo­wa­nia czy­li kla­sy­ka water­fall, w efek­cie beto­no­wa­nie sta­nu z dnia roz­po­czę­cia) mimo, że autor­ki arty­ku­łu piszą o sobie że są agile…

Popatrzmy na to co pro­po­nu­ją w tym 2017 roku.:

If the­re are spe­ci­fic busi­ness rules in the sys­tem that set maxi­mums on the 0..n or 1..n rela­tion­ships, the­se can be inc­lu­ded in the bounds for con­text. For exam­ple, the PO for SeiSounds might want to spe­ci­fy that each acco­unt can only be asso­cia­ted with a maxi­mum of five users or liste­ners to avo­id friends buy­ing one paid sub­scrip­tion and sha­ring with eve­ry­one else. See the exam­ple below:

[…] CONCLUSION Business Data Diagrams are one of tho­se MUST HAVE models for any pro­duct that is dealing with data. The exer­ci­se of cre­ating the model itself cre­ates a power­ful, sha­red under­stan­ding of the under­ly­ing data con­structs as users under­stand it. Instrumental in hel­ping to iden­ti­fy addi­tio­nal, more deta­iled models that might be needed, the BDD can also help you get to a com­ple­te set of user sto­ries aro­und users inte­rac­ting with the data fol­lo­wing the cre­ate, use, edit, dele­te, move and copy actions. (Źródło: Deep Dive Models in Agile Series: Business Data Diagram

Powyższy model:

  1. dekla­ru­je kon­kret­ną zna­ną na teraz”, war­tość limi­tu licz­by użyt­kow­ni­ków Konta,
  2. pomię­dzy auto­rem, utwo­rem i sta­cją jest nic nie­mó­wią­ca (każ­de z każ­dym bez żad­nych ogra­ni­czeń) zależność,
  3. pozo­sta­łe ele­men­ty nie wno­szą war­to­ści doda­nej (utwór jest cechą arty­sty czy może arty­sta jest cechą utworu…).

Zaryzykuję tezę, że powyż­sze w zasa­dzie nie poma­ga deve­lo­pe­ro­wi w niczym. Czy wno­si coś do pro­jek­tu? W moich oczach sta­no­wi pro­ste zapi­sa­nie” tego co zezna­li inda­go­wa­ni zama­wia­ją­cy (arty­kuł zawie­ra opis histo­ry­jek użyt­kow­ni­ka i ich koja­rze­nia z tym mode­lem danych). Stwierdzenie zaś, że …spe­ci­fic busi­ness rules in the sys­tem that set maxi­mums on the 0..n or 1..n rela­tion­ships…, (np. mak­si­mum pię­cio­ro użyt­kow­ni­ków może jed­no­cze­śnie słu­chać), to nie regu­ła biz­ne­so­wa a kry­te­rium decy­zyj­ne (wię­cej o regu­łach biz­ne­so­wych w lite­ra­tu­rze). 

Trzeba sobie tu jasno powie­dzieć, że induk­cyj­ne podej­ście do ana­li­zy (zbie­ra­nie i zapi­sy­wa­nie obser­wa­cji w celu iden­ty­fi­ka­cji tren­du lub powtó­rzeń) przy­po­mi­na pró­by zro­zu­mie­nia gry w sza­chy meto­dą wie­lo­krot­nej obser­wa­cji roz­gry­wek. Im wier­niej­szy opis gry ma powstać, tym wię­cej obser­wa­cji nale­ży udo­ku­men­to­wać, co nie zmie­nia fak­tu, że taki doku­ment nie mówi abso­lut­nie nic o przy­szłych roz­gryw­kach. Alternatywą jest deduk­cyj­ne podej­ście, pole­ga­ją­ce na zro­zu­mie­niu i opra­co­wa­niu, moż­li­wie naj­mniej­szym nakła­dem pra­cy, reguł gry w sza­chy, cze­go udo­ku­men­to­wa­nie wyma­ga naj­wy­żej dwóch stron papie­ru A4, taki doku­ment opi­su­je tak­że w 100% wszyst­kie przy­szłe roz­gryw­ki… 

Jak inaczej podejść do tego? 

Na począ­tek nale­ży zro­zu­mieć dzie­dzi­nę pro­ble­mu i opi­sać ją słownikiem:

Powyższy model poję­cio­wy (dia­gram nota­cji SBVR, dia­gram klas nota­cji UML) to słow­nik pojęć a nie model danych. To dia­gram obra­zu­ją­cy poję­cia i kon­tek­sto­we związ­ki mię­dzy nimi (tym kon­tek­stem są fak­ty z dzie­dzi­ny ana­li­zo­wa­ne­go pro­ble­mu). Nie są to ani dane ani regu­ły biz­ne­so­we. Są to nazwy, a nie byty sys­te­mo­we”. Poza takim dia­gra­mem, nale­ży tak­że stwo­rzyć słow­nik pojęć biz­ne­so­wych w posta­ci tabe­li zawie­ra­ją­cej pre­cy­zyj­ne, dzie­dzi­no­we defi­ni­cje tych pojęć. Dla wygo­dy i pre­zen­ta­cji ich tre­ści nanio­słem dwie regu­ły na dia­gram, są sko­ja­rzo­ne z Kontem gdyż jego doty­czą. Co do zasa­dy regu­ły biz­ne­so­we są koja­rzo­ne z ele­men­ta­mi na innych dia­gra­mach poprzez sło­wa zdefiniowane.

Cała ana­li­za powin­na się zaczy­nać od udo­ku­men­to­wa­nia mode­li pro­ce­sów. Tu pomi­ną­łem te mode­le bo ich opi­sów jest na moim blo­gu wie­le, a chcę się sku­pić na dzie­dzi­nie dla jakiej powsta­je apli­ka­cja. Analiza i zro­zu­mie­nie pro­ble­mu pro­wa­dzi do stwo­rze­nia mode­lu dzie­dzi­ny apli­ka­cji. Taki model powsta­je na pod­sta­wie tre­ści doku­men­tów wewnętrz­nych i zewnętrz­nych (tu np. Ustawa o pra­wach autor­skich), poma­ga­ją co naj­wy­żej bie­żą­ce wyja­śnie­nia. Do jego powsta­nia nie są potrzeb­ne żad­ne warsz­ta­ty ani cało­dzien­ne spotkania.

Celem mode­lo­wa­nia dzie­dzi­ny sys­te­mu (tu apli­ka­cji) jest udo­ku­men­to­wa­nie wewnętrz­nej logi­ki apli­ka­cji, czy­li mecha­ni­zmu jej dzia­ła­nia. Absolutnie nie jest to model danych. Powyższy model nie jest mode­lem ukoń­czo­nym”, wyma­ga na pew­no dopra­co­wa­nia, jed­nak moim celem jest jedy­nie poka­za­nie idei jego two­rze­nia. Nazwy klas, atry­bu­tów, ope­ra­cji zawie­ra­ją poję­cia zawar­te w słow­ni­ku pojęć. Zapewnia to jed­no­znacz­ność i zro­zu­mie­nie. Dodam, że dopie­ro ten model poka­zu­je bar­dzo waż­ną rzecz, to że autor jest cechą utwo­ru a nie odwrotnie. 

Tak więc:

  1. uru­cho­mie­nie i korzy­sta­nie z emi­sji kon­tro­lo­wa­ne jest przez Zarządzanie emi­sją, tu spraw­dza­ne są i egze­kwo­wa­ne, regu­ły biznesowe, 
  2. kom­po­nent Zarządzanie emi­sją korzy­sta tak­że z infor­ma­cji zawar­tych w Koncie użyt­kow­ni­ka i Playlisty, deta­le utwo­rów pobie­ra z Repozytorium utworów. 

Tu waż­ne jest pod­kre­śle­nie, że regu­ła doty­czą­ca ogra­ni­cze­nia licz­by jed­no­cze­śnie słu­cha­ją­cych, jest oddzie­lo­na od Kont użyt­kow­ni­ków i (nie poka­za­nych tu) Subskrypcji. Dzięki temu para­metr ten jest łatwo mody­fi­ko­wal­ny z pozio­mu apli­ka­cji (para­me­try­zo­wa­ne kry­te­rium decy­zyj­ne) bez potrze­by jakich­kol­wiek inge­ren­cji w model danych”. Umieszczanie jakich­kol­wiek reguł w bazie danych (czy­li na pozio­mie imple­men­ta­cji utrwa­la­nia) jest nie­ste­ty ich beto­no­wa­niem”.

Zmienność, nie tyl­ko ryn­ku ale i samych reguł w orga­ni­za­cjach, to sta­ły ele­ment śro­do­wi­ska apli­ka­cji. Dlatego dobrą prak­ty­ką jest, by utrwa­la­nie danych (wszel­kie bazy danych, pli­ki itp..) nie słu­ży­ło do nicze­go poza utrwa­la­niem. Logika biz­ne­so­wa powin­na być w w 100% w apli­ka­cji a nie podzie­lo­na pomię­dzy apli­ka­cję i dane (żad­na baza danych nie jest w sta­nie prze­cho­wy­wać innych reguł biz­ne­so­wych niż bez­po­śred­nie związ­ki ilo­ścio­we). Na eta­pie imple­men­ta­cji, sto­su­je­my zasa­dę her­me­ty­za­cji, czy­li nie współ­dzie­li­my, na żad­nym pozio­mie, danych pomię­dzy repo­zy­to­ria­mi i nie usu­wa­my redun­dan­cji. Dzięki temu nie odci­na­my sobie dro­gi do zmian sys­te­mu takich jak np. zastą­pie­nie kla­sy Dane oso­bo­we inter­fej­sem do zewnętrz­ne­go sys­te­mu, dys­po­nu­ją­ce­go taki­mi infor­ma­cja­mi (kla­sa ta zosta­nie zmie­nio­na, sta­nie się wte­dy mostem do API zewnętrz­ne­go sys­te­mu co nie pocią­gnie za sobą jakich­kol­wiek zmian, bo inter­fejs tej kla­sy i jej nazwa pozo­sta­ną nie­zmie­nio­ne, patrz zasa­da open-clo­se prin­ci­pia oraz polimorfizm).

Poniżej klu­czo­we związ­ki w UML i ilu­stra­cja związ­ku pomię­dzy mode­lem poję­cio­wym a mode­lem struk­tu­ry (archi­tek­tu­ry, to model dziedziny):

Na zakoń­cze­nie war­to zauwa­żyć, że zmien­ność śro­do­wi­ska biz­ne­so­we­go powo­du­je, że żad­ne decy­zje o logi­ce biz­ne­so­wej nie są osta­tecz­ne, jed­nak są ele­men­ty nie­zmien­ne takie jak np. nasze dane oso­bo­we. Tak więc to, co powszech­nie nazy­wa­ne jest mode­lem danych” (busi­ness data dia­gram) w rozu­mie­niu opi­sa­nym przez autor­ki arty­ku­łu, nie ma dzi­siaj racji bytu. Ma sens zacho­wa­nie zamó­wie­nia i osob­no fak­tu­ry, ale to czy regu­łą jest jed­no zamó­wie­nie do jed­nej fak­tu­ry, pod­le­ga zmia­nom wyni­ka­ją­cym i ze zmien­no­ści pra­wa i ze zmien­no­ści mode­li biz­ne­so­wych. Nie widzę żad­ne­go powo­du dekla­ro­wa­nia już na począt­ku pro­jek­tu, tego by nie wię­cej niż 5 osób mogło korzy­stać z jed­ne­go kon­ta i sub­skryp­cji. W szcze­gól­no­ści nie widzę powo­du by taka zasa­da była zawar­ta w samym kodzie aplikacji.

Warto tak­że mieć na uwa­dze to, że opro­gra­mo­wa­nie może być two­rzo­ne z uży­ciem zewnętrz­nych kom­po­nen­tów dostęp­nych na ryn­ku. Założenie więc na samym począt­ku pro­jek­tu, że dane są w jed­no­li­ty spo­sób prze­cho­wy­wa­ne i współ­dzie­lo­ne w jed­nej cen­tral­nej i współ­dzie­lo­nej bazie danych, wraz z logi­ką ich uży­cia, jest tu nie tyl­ko nie­uza­sad­nio­ne ale wręcz szkodliwe. 

I na koniec grat­ka: dokład­nie ta powsta­ła, i nadal tak wyglą­da, znacz­na więk­szość obec­nych na ryn­ku sys­te­mów ERP, CRM itp.… 

oraz cytat z literatury

z 1994 roku:

(źr. Designing Objects Systems, Steve Cook, John Daniels, 1994 rok.)

Przypadki użycia czy model procesu, czego używać?

Dość czę­sto spo­ty­kam sie z teza­mi, że uży­cie przy­pad­ków uży­cia nie wyma­ga mode­lo­wa­nia pro­ce­sów i odwrot­nie, albo że są to narzę­dzia” ofe­ru­ją­ce podob­ne lub takie same korzy­ści, np. tak jak tu:

So, as you can see we used dif­fe­rent tech­ni­qu­es and basi­cal­ly the result is the same. It was not real­ly impor­tant what tech­ni­qu­es were used unless solu­tion design is com­ple­te. It?s just a mat­ter of a habit so if you?re more com­for­ta­ble with use cases then stick to them or if you?re more fami­liar with pro­cess maps then draw a map. But note that in some cases you may be requ­ested to use a spe­ci­fic tech­ni­que that is a cor­po­ra­te stan­dard or becau­se the­re is an agre­ement that all BAs on the pro­ject will use one tem­pla­te (tech­ni­que) for con­si­sten­cy. (Źródło: Use cases or busi­ness pro­cess maps, what tech­ni­que to use?)

Sugeruję naj­pierw zapo­znać się z cyto­wa­nym powy­żej tek­stem a po zapo­zna­niu się z nim zapra­szam do dal­szej lek­tu­ry. Jak się komuś nie chce powyż­sze­go czy­tać, może potrak­to­wać mój tekst jak zwy­kły post a nie jak polemikę ;). 

Zacznę od mode­lu pro­ce­sów w BPMN jaki pre­zen­tu­je jego autor;

źr. http://​www​.moder​na​na​lyst​.com/​R​e​s​o​u​r​c​e​s​/​A​r​t​i​c​l​e​s​/​t​a​b​i​d​/​1​1​5​/​I​D​/​3​6​5​8​/​U​s​e​-​c​a​s​e​s​-​o​r​-​b​u​s​i​n​e​s​s​-​p​r​o​c​e​s​s​-​m​a​p​s​-​w​h​a​t​-​t​e​c​h​n​i​q​u​e​-​t​o​-​u​s​e​.​a​spx

Pierwsza rzecz: co do zasa­dy Klient i Podmiot go obsłu­gu­ją­cy to dwa odręb­ne pod­mio­ty więc dia­gram ten powi­nien zawie­rać dwie pule, a nie jed­ną wspól­ną pulę (albo jak kto woli base­ny). Dalej. BPMN w spe­cy­fi­ka­cji trak­tu­je tory wyłącz­nie jak uni­wer­sal­ne ele­men­ty gru­pu­ją­ce (nie są one jed­nak eks­por­to­wa­ne do pli­ków wymia­ny XPBL czy BPEL4WS), nie ma zaka­zu sto­so­wa­nie torów do repre­zen­to­wa­nia sys­te­mów”, model biz­ne­so­wy CIM (defi­ni­cja MDA) zaka­zu­je. Od sie­bie dodam, że to czym będą tory nale­ży zde­fi­nio­wać na począt­ku ana­li­zy (i powin­na to być jed­na spój­na definicja). 

Autor powyż­sze­go dia­gra­mu na jed­nym dia­gra­mie poka­zał wszyst­ko co wie, łamiąc nota­cyj­ne zasa­dy sto­so­wa­ni puli (base­nu) oraz dobre prak­ty­ki nie mie­sza­nia róż­nych kon­tek­stów na jed­nym modelu.

Model pro­ce­su powi­nien mieć zawsze kon­kret­ny kon­tekst i być osa­dzo­ny w jakiejś meto­dy­ce, bez tego trud­no pod­jąć decy­zję, któ­re infor­ma­cje są istot­ne i jakie deta­le poka­zy­wać (bo nota­cje są nad­mia­ro­we i nie są meto­dy­ką). Bez tego tak­że trud­no innej oso­bie taki dia­gram jed­no­znacz­nie zin­ter­pre­to­wać. Najgorsze wyj­ście to nie wiem, więc poka­że wszyst­ko co wiem” z czym tu mamy moim zda­niem do czynienia.

Jak to robić? Przyjmuję postę­po­wa­nie zgod­ne MDA/MDE (pisa­łem tu o tym nie raz), więc naj­pierw two­rzy­my model CIM (Computation Independent Model), któ­re­go celem jest zro­zu­mie­nie i udo­ku­men­to­wa­nie mecha­ni­zmu – tu – reje­stra­cji kon­ta, typo­wy mecha­nizm opt-in:

Co do zasa­dy aktyw­ność w pro­ce­sie to coś co sta­no­wi kom­plet­nie wyko­na­ną pra­cę (bo pro­ces to aktyw­ność prze­kształ­ca­ją­ca wej­ście w wyj­ście), więc dzie­le­nie jej na kawał­ki nie ma żad­ne­go uza­sad­nie­nia. Detale aktyw­no­ści poka­zu­je­my na odręb­nym dia­gra­mie, a czę­ściej jako zapi­sa­ną tek­stem pro­ce­du­rę (jest nie­po­dziel­na bo aktyw­ność jest jed­na). Np. aktyw­ność Rejestracja po stro­nie (w puli) Klienta to:

  1. ini­cja­cja reje­stra­cji konta
  2. SYSTEM wyświe­tla for­mu­larz Dane użytkownika
  3. wypeł­nie­nie pól for­mu­la­rza i potwierdzenie
  4. jeże­li 
    1. dane są popraw­ne – SYSTEM potwier­dza przy­ję­cie danych
    2. dane są nie­po­praw­ne – SYSTEM pre­zen­tu­je for­mu­larz Dane użyt­kow­ni­ka i wyświe­tla komu­ni­kat (lub idź do punkt 2.) 
  5. (koniec)

(cza­sa­mi doda­ję pseu­do krok pro­ce­du­ry koniec aby czy­tel­nik miał pew­ność, że to ukoń­czo­na praca).

Po stro­nie (w puli) Organizacji zaini­cjo­wa­ne żąda­nie reje­stra­cji spo­wo­du­je obsłu­gę pierw­sze­go dia­lo­gu z Klientem, tu ostat­nim kro­kiem pro­ce­du­ry jest wysła­nie moni­tu mailem. Następnie Organizacja cze­ka, jeże­li dosta­nie potwier­dze­nie to akty­wu­je kon­to Klienta, zaś po trzech dniach bez­czyn­no­ści, Dane użyt­kow­ni­ka zosta­ną usu­nię­te, i pro­ces reje­stra­cji zosta­nie uzna­ny za zakoń­czo­ny (tu niepowodzeniem).

Na tym eta­pie prac wie­my co i jak Organizacja robi w przy­pad­ku reje­stra­cji Klienta. Cały ten amba­ras jed­nak do cze­goś słu­ży, słu­ży do udo­stęp­nia­nia Klientowi moż­li­wo­ści skła­da­nia zamó­wień i danych o sta­nie jego roz­ra­chun­ków. W przy­kła­dzie mamy dia­gram przy­pad­ków uży­cia, więc i ja pój­dę tym tro­pem (zakres projektowania).

źr. http://​www​.moder​na​na​lyst​.com/​R​e​s​o​u​r​c​e​s​/​A​r​t​i​c​l​e​s​/​t​a​b​i​d​/​1​1​5​/​I​D​/​3​6​5​8​/​U​s​e​-​c​a​s​e​s​-​o​r​-​b​u​s​i​n​e​s​s​-​p​r​o​c​e​s​s​-​m​a​p​s​-​w​h​a​t​-​t​e​c​h​n​i​q​u​e​-​t​o​-​u​s​e​.​a​spx

Mamy tu czte­ry przy­pad­ki uży­cia. Skąd? O tym dalej. Pisałem już wcze­śniej o trans­for­ma­cji z mode­lu BPMN na model Przypadków uży­cia. Tu poka­że efekt końcowy. 

Dlaczego tak?

Przede wszyst­kim logo­wa­nie (wbrew wie­lu przy­kła­dom w sie­ci) nie jest przy­pad­kiem uży­cia, czy­li nie jest usłu­gą apli­ka­cji, jest cechą śro­do­wi­ska, jed­nym z wie­lu spo­so­bów auto­ry­zo­wa­nia użyt­kow­ni­ka do pra­cy (inne to LDAP, Activedirectory, odcisk pal­ca, itp., jest to meto­da reali­za­cji wyma­ga­nia poza­funk­cjo­nal­ne­go o nie­do­pusz­cza­niu do korzy­sta­nia z usług apli­ka­cji nie­au­to­ry­zo­wa­nych osób). Nie jest dobrym pomy­słem uzna­wa­nie takich czyn­no­ści jako usług apli­ka­cji (kto kupi coś co słu­ży wyłącz­nie do logo­wa­ni się?) 

Mamy tu przy­pa­dek uży­cia Zarządzanie kon­tem. Jest to usłu­ga pole­ga­ją­ca na two­rze­niu, aktu­ali­za­cji, pod­glą­dzie lub usu­nię­ciu danych użyt­kow­ni­ka (stan­dar­do­wo ozna­cza sie takie usłu­gi CRUD, ang. Create, Retrieve, Update, Delete, są to reje­stry pozba­wio­ne dzie­dzi­no­wej logi­ki biz­ne­so­wej, kon­tro­lu­je­my wyłącz­nie popraw­ność samych pól). Korzysta z niej Klient, pierw­sze uży­cie (kon­tekst Create) to nic inne­go jak reje­stra­cja w sys­te­mie, każ­de kolej­ne uży­cie to będzie kolej­na aktu­ali­za­cja danych (kon­tekst Update) lub osta­tecz­nie pole­ce­nie ich usu­nię­cia (kon­tekst Delete).

Scenariusz reje­stra­cji, opi­sa­ny wcze­śniej, wyglą­dał by tak:

To tu są poka­za­ne (udo­ku­men­to­wa­ne) kolej­ne kro­ki reali­zo­wa­ne przez pro­jek­to­wa­ny System. W tym przy­pad­ku cały pro­ces samo­ob­słu­gi Klienta (zarzą­dza­nie dany­mi o sobie) został zauto­ma­ty­zo­wa­ny (czy­li nie robią tego już pra­cow­ni­cy Organizacji a apli­ka­cja). W efek­cie model pro­ce­su biz­ne­so­we­go przy­bie­rze osta­tecz­ny kształt to-be”:

Jedynie Klient uży­wa apli­ka­cji, to kto jest wła­ści­cie­lem opro­gra­mo­wa­nia nie ma żad­ne­go zna­cze­nia i nie mode­lu­je­my tego. Wskazane na wcze­śniej­szym dia­gra­mie regu­ły biz­ne­so­we (np. ocze­ki­wa­nie na powie­dze­nie reje­stra­cji wyga­sa po trzech dniach) moż­na zebrać w posta­ci zesta­wie­nia i dołą­czyć do doku­men­ta­cji przy­pad­ków uży­cia, albo po pro­stu prze­ka­zać deve­lo­pe­ro­wi całą doku­men­ta­cję (oso­bi­ście powie­lam zesta­wie­nia reguł biz­ne­so­wych przy przy­pad­kach uży­cia, co pole­cam, zaś nad­mia­ro­wa doku­men­ta­cja jest łatwiej­sza w uży­ciu dla developera).

Autor cyto­wa­ne­go arty­ku­łu umie­ścił w nim tak­że taki diagram:

źr. http://​www​.moder​na​na​lyst​.com/​R​e​s​o​u​r​c​e​s​/​A​r​t​i​c​l​e​s​/​t​a​b​i​d​/​1​1​5​/​I​D​/​3​6​5​8​/​U​s​e​-​c​a​s​e​s​-​o​r​-​b​u​s​i​n​e​s​s​-​p​r​o​c​e​s​s​-​m​a​p​s​-​w​h​a​t​-​t​e​c​h​n​i​q​u​e​-​t​o​-​u​s​e​.​a​spx

Mogę to teraz sko­men­to­wać tak:

  1. jest to jakieś nie­for­mal­ne zesta­wie­nie funk­cjo­nal­no­ści”
  2. funk­cjo­nal­no­ści ozna­czo­ne 1, 2 oraz 3 to nic inne­go jak uży­cie, w róż­nym kon­tek­ście, przy­pad­ku uży­cia (CRUD) Zarządzanie kon­tem

Nie mode­lo­wa­łem już pro­ce­su skła­da­nia zamó­wie­nia (mam nadzie­ję że nie trze­ba :)). Kalendarz to pew­na for­ma zobra­zo­wa­nia ter­mi­nów (np. zamó­wień, jeże­li było takie wyma­ga­nie), być może na stro­nie panel Klienta” (robo­ta dla UX desi­gne­ra). Monitowanie (6. Notification) to nic inne­go jak kolej­ne poza­funk­cjo­nal­ne wyma­ga­nie (moni­to­wa­nie o czymś jako takie to nie jest przy­pa­dek uży­cia), reali­zo­wa­ne w spo­sób udo­ku­men­to­wa­ny na dia­gra­mie sekwen­cji (sce­na­riusz reali­za­cji przy­pad­ku uży­cia). Diagram sekwen­cji jak wyżej, po drob­nych korek­tach, będzie paso­wał do każ­dej ope­ra­cji z dany­mi Klienta, tak­że do aktyw­no­ści Zapoznanie się z tre­ścią danych w toku potwier­dza­nia reje­stra­cji (tu kon­tekst pro­ste­go potwier­dze­nia ope­ra­cji Retrive).

Przedstawiłem wer­sję, któ­ra nie wyma­ga uży­wa­nia żad­nych nie­for­mal­nych dia­gra­mów (UML i BPMN w zupeł­no­ści wystar­czą). Wersję, któ­ra jest zgod­na z MDA, więc wpi­su­je się dobrze w pro­ces ana­li­zy biz­ne­so­wej (model CIM), oddzie­lo­nej od pro­jek­to­wa­nia (model PIM) i imple­men­ta­cji (model PSM, tu pomi­nię­ty i real­nie rzad­ko wyko­ny­wa­ny u deve­lo­pe­ra). Wersję, któ­ra w 100% pozwa­la na śla­do­wa­nie wyma­gań. To co opi­sa­łem jest tak­że zgod­ne z zale­ce­nia­mi BABoK, two­rze­nia jako wyma­ga­nia mode­li bia­łej skrzyn­ki” czy­li pro­jek­tu roz­wią­za­nia (pro­duk­tu).

Jak widać, moż­li­we jest, że jeden przy­pa­dek przy­pa­dek uży­cia (doty­czy to szcze­gól­nie tych ozna­cza­nych CRUD) jako usłu­ga apli­ka­cji, będzie wyko­rzy­sty­wa­ny w wie­lu kon­tek­stach (podob­nie jak mło­tek i jego usłu­ga uderz w to”, może być uży­ty zarów­no do wbi­ja­nia gwoź­dzia jak i do wybi­ja­nia szyby). 

Chciałem tak­że kolej­ny raz poka­zać, że zamiast doku­men­to­wa­nia wyma­gań meto­dą mon­stru­al­nych opi­sów pro­zą i zesta­wień w tabe­lach, z któ­ry­mi to opi­sa­mi auto­rzy mają nie raz ogrom­ne pro­ble­my z utrzy­ma­niem ich kom­plet­no­ści, spój­no­ści i nie­sprzecz­no­ści zaś deve­lo­pe­rzy ogrom­ne pro­ble­my z inter­pre­ta­cją, war­to wyma­ga­nia prze­ka­zy­wać w posta­ci spój­ne­go i prze­te­sto­wa­ne­go i logicz­ne­go pro­jek­tu. Warto tak­że zadbać by sche­ma­ty blo­ko­we (mode­le) były two­rzo­ne zgod­ne z okre­ślo­ny­mi zasa­da­mi (nota­cje, dobre prak­ty­ki) bez cze­go będą trud­ne w jed­no­znacz­nej interpretacji. 

Moi zda­niem podej­ście MDA zapre­zen­to­wa­ne powy­żej jest znacz­nie sku­tecz­niej­sze i daje lep­sze zro­zu­mie­nie, niż wer­sja poka­za­na przez auto­ra arty­ku­łu Use cases or busi­ness pro­cess maps, what tech­ni­que to use?, ale oce­nę pozo­sta­wiam czy­tel­ni­kom (zachę­cam do zada­wa­nia pytań i dyskusji).

Co z tytu­ło­wym pyta­niem: Przypadki uży­cia czy model pro­ce­su, cze­go używać? 

Używać obu dia­gra­mów zgod­nie z ich przeznaczeniem…

Koncepcja to nie wymagania!

Dwa lata temu pisa­łem o tym, czym jest, po co się pro­wa­dzi i jak, stu­dium wyko­ny­wal­no­ści projektu:

W lite­ra­tu­rze moż­na spo­tkać róż­ne ?defi­ni­cje? stu­dium wyko­nal­no­ści, jed­nak ta któ­rą opi­sa­łem, zda­je się być naj­bliż­sza defi­ni­cji, któ­rą przy­to­czy­łem na począt­ku: bazu­ją­cej na zna­cze­niu słow­ni­ko­wym. Praktyka poka­zu­je, że inten­cje spon­so­rów tych ana­liz są z nią zbież­ne: celem jest pod­ję­cie decy­zji o naj­mniej­szym ryzy­ku w świe­tle posia­da­nej na dany temat wie­dzy. Definicje bazu­ją­ce na tech­nicz­nej i finan­so­wej wyko­nal­no­ści dane­go pro­jek­tu, są spo­ty­ka­ne dość czę­sto i w lite­ra­tu­rze i na stro­nach wie­lu insty­tu­cji. Metoda pro­wa­dze­nia takich ana­liz, bazu­ją­ca na mode­lo­wa­niu czy­li na ana­li­zie sys­te­mo­wej, wyda­je się być jed­nak naj­wła­ściw­szą. (Źródło: Studium wyko­nal­no­ści ? czym napraw­dę jest | | Jarosław Żeliński IT-Consulting)

W arty­ku­le tym zwra­ca­łem uwa­gę na war­tość mode­lo­wa­nia (a nie ryso­wa­nia…), war­to­ścią tą jest testo­wa­nie kon­cep­cji. Sama kon­cep­cja nie jest żad­nym wyma­ga­niem, co ilu­stru­je świet­ny arty­kuł na stro­nach Modernanalyst​.com:

Requirements must be based on facts and real-life sce­na­rios. When the con­cept is unte­sted or not ful­ly tested, then the requ­ire­ments are hypo­the­ti­cal. Moving to design and build with hypo­the­ti­cal requ­ire­ments, the design and/or build pha­se beco­mes the testing gro­und for the con­cept. This may lead to cla­shes as each par­ty has dif­fe­rent expec­ta­tions of the out­co­me of the ?hypo­the­ses?.

Źródło: Blueprints Are Not Requirements!

Powyższy dia­gram poka­zu­je głów­ne prze­sła­nie opi­sa­nej meto­dy, któ­ra jest zgod­na w 100% z peł­ną ana­li­zą sys­te­mo­wą: pierw­szy etap to opra­co­wa­nie kon­cep­cji czy­li hipo­te­zy mówią­cej taki sys­tem jest nam potrzeb­ny” do roz­wią­za­nia pro­ble­mu biz­ne­so­we­go (potrze­by biz­ne­so­we). Kolejny etap to stwier­dze­nie popraw­no­ści pomy­słu, to nic inne­go jak stu­dium wyko­nal­no­ści, testo­wa­nie pomy­słu. Tu waż­na rzecz: test musi być pro­wa­dzo­ny w opar­ciu o fak­ty i tyl­ko fak­ty, inny­mi sło­wy model nie może koli­do­wać z rze­czy­wi­sto­ścią, musi tak­że poka­zać, że zapro­jek­to­wa­ny nowy lub zmie­nio­ny mecha­nizm dzia­ła­nia orga­ni­za­cji da ocze­ki­wa­ne efek­ty. Dopiero gdy hipo­te­za mówią­ca, że taki sys­tem reali­zu­je nasze potrze­by” zosta­nie potwier­dzo­na testa­mi na mode­lu, ma sens opra­co­wy­wa­nie wyma­gań na to roz­wią­za­nie. W toku opra­co­wy­wa­nia wyma­gań, tak­że je testu­je­my. Tu zno­wu spraw­dza się sku­tecz­ność podej­ścia pro­jekt (model) jako wymaganie”.

Trzy lata temu opi­sa­łem cały taki pro­ces, na dość może try­wial­nym przy­kła­dzie (sza­chy), ale za to (mam nadzie­ję) przej­rzy­stym. Na zakoń­cze­nie arty­ku­łu zwró­ci­łem uwa­gę, że:

Analiza i pro­jek­to­wa­nie obiek­to­we (ang. OOAD) to nie­ja­ko ?imple­men­ta­cja? kla­sycz­nej ana­li­zy sys­te­mo­wej. Nie ma ona nic wspól­ne­go ze struk­tu­ral­ny­mi meto­da­mi ana­li­zy i pro­jek­to­wa­nia opro­gra­mo­wa­nia (cze­go wie­lu zda­je się nadal nie dostrze­gać). Wygląda na to, że jest znacz­nie trud­niej­sza ale prak­ty­ka poka­zu­je, że daje znacz­nie lep­sze rezul­ta­ty. Języki obiek­to­we to nie jakaś tam nowa nazwa kla­sy na pod­pro­gra­my, a zupeł­nie nowy para­dyg­mat pro­gra­mo­wa­nia: musi być poprze­dza­ny ana­li­zą i pro­jek­tem. Jego zale­tą jest to, że pozwa­la na odwzo­ro­wy­wa­nie, nie­mal­że jak w grze, ana­li­zo­wa­ne­go i roz­wią­zy­wa­ne­go pro­ble­mu, pozwa­la na prze­te­sto­wa­nie pomy­słu na pro­gram zanim powsta­nie choć jed­na linia pro­gra­mu. Problemem i wyzwa­niem na eta­pie ana­li­zy jest zro­zu­mie­nie pro­ble­mu, co mam nadzie­ję poka­za­łem. Niestety wie­le ana­liz doku­men­to­wa­nych z uży­ciem nota­cji UML nie ma wie­le wspól­ne­go z OOAD, sta­no­wią echa struk­tu­ral­nych metod ana­li­zy i pro­jek­to­wa­nia, sto­so­wa­nia baz rela­cyj­nych już na eta­pie ana­li­zy (obiek­to­we narzę­dzia nie czy­nią pro­jek­tów obiek­to­wy­mi). Niestety błę­dy te popeł­nia­ją nawet wykła­dow­cy wie­lu uczel­ni i kur­sów. (Źródło: Plansza do gry w sza­chy czy­li ana­li­za i pro­jek­to­wa­nie | | Jarosław Żeliński IT-Consulting).

Autor arty­ku­łu przy­wo­łu­je nie­zmien­ną od lat statystykę:

According to an often-quoted stu­dy from the Gartner Group, 75% of IT pro­jects fail. The Standish Group con­ducts an annu­al survey of IT pro­jects. Their latest report shows a decre­ase in pro­ject suc­cess rates.

  1. 32% of all pro­jects suc­ce­eded: deli­ve­red on time, on bud­get, with requ­ired features.
  2. 44% were chal­len­ged: late, over bud­get, and/or with less than the requ­ired features.
  3. 24% failed: can­cel­led prior to com­ple­tion or deli­ve­red and never used.

When we look back, we not only see failu­res but can cle­ar­ly see the boom the softwa­re indu­stry has been given with its suc­cess. But the wor­ry­ing aspect is that the­re are failu­res that are recur­ring eve­ry year, may­be in a dif­fe­rent orga­ni­za­tion but mostly with com­mon cau­ses. (Źródło: Blueprints Are Not Requirements!)

…i zwra­ca uwa­gę, że ich przy­czy­ny są od lat sta­le takie same…

Requirements must be based on facts and real-life sce­na­rios.” (wyma­ga­nia muszą być opar­te na fak­tach i real­nych sce­na­riu­szach). Więc ile war­te są wizje w pro­jek­tach agi­le albo wydu­ma­ne w toku warsz­ta­to­wych burz mózgów lita­nie życzeń i pomy­słów? Nie tyl­ko moim zda­niem: nie są wie­le war­te i nie powin­ny być wymaganiami.

Analityk biznesowy czyli wyplenić dwuznaczność z dokumentów analitycznych!

Why Organizations Need Business Analysts

We have always been fasci­na­ted by the excep­tio­nal busi­ness ana­ly­sts who can cre­ate order out of total cha­os. (za Ambiguity, Uncertainty or Both? > Business Analyst Community & Resources).

ModernAnalys​.com to jeden z moich ulu­bio­nych ser­wi­sów w sie­ci. W tego typu ser­wi­sach naj­bar­dziej fascy­nu­je mnie, że w zasa­dzie (w pew­nym sen­sie i ja tak­że w moim blo­gu) trak­tu­je o rze­czach oczywistych.

Powyżej kolej­ny cytat z tego ser­wi­su: Zawsze fascy­no­wa­ła nas nie­prze­cięt­na zdol­ność ana­li­ty­ków biz­ne­so­wych do porząd­ko­wa­nia total­ne­go cha­osu”. Tytuł arty­ku­łu brzmi Po co orga­ni­za­cjom Analityk Biznesowy”.

Autorzy słusz­nie zwra­ca­ją uwa­gę, że poję­cie nie­pew­no­ścinie­ja­sno­ści (dwu­znacz­ność) to odręb­ne poję­cia. Niepewność ma swo­je źró­dło w sta­ty­sty­ce i ozna­cza, ryzy­ko. Niejasność to poję­cie zwią­za­ne z komu­ni­ka­cją (pre­cy­zja języ­ka) i ozna­cza nie­jed­no­znacz­ność treści”.

Ale nie jest tu moim celem tłu­ma­cze­nie tego tek­stu na pol­ski. Postanowiłem dodać coś od sie­bie. Ryzyka zna­my (sta­ty­sty­ka nie­uda­nych pro­jek­tów IT) więc co z tymi dwo­ma poję­cia­mi? Zaryzykuje tezę:

Im więk­sza nie­jed­no­znacz­ność doku­men­tu wyma­gań tym więk­sze ryzy­ko, że pro­jekt będzie miał kłopoty”.

Powyższe nie sta­no­wi żad­ne­go odkry­cia co nie zmie­nia fak­tu, że jakość więk­szo­ści doku­men­tów wyma­gań (owe 70%) jest sła­ba, na co wska­zu­ją sami ankietowani.

Rola Kierownika Projektu to mię­dzy inny­mi zarzą­dza­nie ryzy­kiem. Statystyki są nie­ubła­ga­ne, więc brak dobre­go ana­li­ty­ka i dobrej ana­li­zy wyma­gań spy­cha pro­jekt w kie­run­ku kło­po­tów. No to mamy kolej­ne bada­nie: Znaczenie i zapo­trze­bo­wa­nie na spe­cja­li­stów wg. Forrestera: 70% bada­nych decy­den­tów uwa­ża, że Analityk Biznesowy to klu­czo­wa postać w pro­jek­cie. Jednak nie dla­te­go, że jest waż­niej­szy od np. kie­row­ni­ka pro­jek­tu, bo nie jest waż­niej­szy. Dlatego, że od jako­ści jego pro­duk­tu (ana­li­za i spe­cy­fi­ka­cja wyma­gań) zale­ży wła­śnie ryzy­ko całe­go projektu.

Co jest wadą większości analiz biznesowych?

To, że są one tak na praw­dę upo­rząd­ko­wa­nym zapi­sem wywia­dów z klien­tem a nie fak­tycz­ną ana­li­zą orga­ni­za­cji, jej potrzeb (bo raczej nie koniecz­nie jej pra­cow­ni­ków!) i celów biznesowych.

  • Jakie są tre­ści tek­sto­we­go lub tabe­la­rycz­ne­go zapi­su wywia­dów? NIEJEDNOZNACZNE! 
  • Jakie są nie­sfor­ma­li­zo­wa­ne, swo­bod­nie two­rzo­ne dia­gra­my pro­ce­sów? NIEJEDNOZNACZNE! 
  • Jakie są słow­ne opi­sy struk­tu­ry opro­gra­mo­wa­nia jakie ma powstać? NIEJEDNOZNACZNE!

Co zro­bić? Używać już na eta­pie ana­li­zy biz­ne­so­wej i pro­jek­to­wa­nia sfor­ma­li­zo­wa­nych narzę­dzi takich jak stan­dar­do­we nota­cje i meto­dy­ki, wte­dy opi­sy będą JEDNOZNACZNE. Czy to trud­ne? Tak, w koń­cu te 70% pora­żek to nie przypadek…

A na popra­wę humo­ru i na dowód, że powyż­sze jed­nak war­te jest uwa­gi, przy­kład nie­jed­no­znacz­no­ści w tek­ście czy­li jak inten­cje roz­mi­ja­ją się z …

Na zakoń­cze­nie przy­to­czę sło­wa jakie na podob­ny temat wygło­sił [[Alfred Tarski]]:

Dysputy tego rodza­ju [co jest czym, przyp. mój] wca­le nie ogra­ni­cza­ją się do poję­cia praw­dy. Występują we wszyst­kich dzie­dzi­nach, gdzie – zamiast ści­słej nauko­wej ter­mi­no­lo­gii – uży­wa się języ­ka potocz­ne­go, z jego nie­ja­sno­ścią i wie­lo­znacz­no­ścią: są one zawsze pozba­wio­ne sen­su, i dla­te­go daremne.