Krótka historia pewnego wymagania

Wprowadzenie

Zarówno w pro­jek­tach jak i w dys­ku­sjach np. na kon­fe­ren­cjach czy na LinkedIn, poja­wia się sta­le pew­ne nie­po­ro­zu­mie­nie: pro­jek­to­wa­nie to water­fall”. Myśli tak każ­dy, kto wyobra­ża sobie, że pro­jekt cze­goś to jakaś masa wszyst­kich moż­li­wych deta­li. Jednocześnie nie ja jeden widu­ję Dokumenty ana­li­zy biz­ne­so­wej” albo Dokumenty wyma­gań” zawie­ra­ją­ce set­ki pozy­cji o tre­ści sys­tem powi­nien…”, nie raz wyko­na­ne przez kry­ty­ków water fall”, któ­rzy repre­zen­tu­jąc deve­lo­pe­ra dekla­ru­ją­ce­go meto­dy agi­le”, zabez­pie­cza­ją się” przez odpo­wie­dzial­no­ścią za zakres projektu. 

Pierwsza waż­na uwa­ga: pro­jekt sys­te­mu to nie jest ani zestaw dzie­siąt­ków user sto­ry” ani deta­licz­na doku­men­ta­cja powy­ko­naw­cza! I o tym dzi­siaj będzie: abs­tra­ho­wa­nie od deta­li i jed­nak nadal zarzą­dza­nie logi­ką całości.

Poniżej wyma­ga­nie napi­sa­ne przez dział IT jed­ne­go z moich klientów:

1. System musi posia­dać wbu­do­wa­ne­go klien­ta pocz­ty elek­tro­nicz­nej obsłu­gu­ją­ce­go co naj­mniej pro­to­ko­ły IMAP i SMTP.
2. Wbudowany klient pocz­ty elek­tro­nicz­nej posia­da nastę­pu­ją­ce funkcje:
2.1. Utwórz wia­do­mość ? umoż­li­wia utwo­rze­nie nowej wiadomości,
2.2. Odpowiedz ? umoż­li­wia udzie­le­nie odpo­wie­dzi nadaw­cy wraz z cyto­wa­niem i ozna­cze­nie cyto­wa­ne­go tek­stu napi­sa­ne­go przez nadawcę,
2.3. Odpowiedz wszyst­kim ? umoż­li­wia udzie­le­nie odpo­wie­dzi nadaw­cy oraz z prze­sła­niem jej na pozo­sta­łe adre­sy ema­il wymie­nio­ne w polu Do, Do wia­do­mo­ści oraz Ukryty do wia­do­mo­ści wraz z cyto­wa­niem i ozna­cze­nie cyto­wa­ne­go tek­stu napi­sa­ne­go przez nadawcę,
2.4. Prześlij dalej ? umoż­li­wia prze­sła­nie pocz­ty elek­tro­nicz­nej kolej­ne­mu odbiorcy,
2.5. Przenieś ? umoż­li­wia prze­no­sze­nie pocz­ty elek­tro­nicz­nej pomię­dzy fol­de­ra­mi na wybra­nym koncie,
2.6. Drukuj ? umoż­li­wia wydru­ko­wa­nie pocz­ty elektronicznej,
2.7. Dołącz ? umoż­li­wia dołą­cze­nie pocz­ty elek­tro­nicz­nej do spra­wy lub dokumentu,
2.8. Odbierz ? umoż­li­wia ręcz­ne ode­bra­nie pocz­ty elektronicznej,
2.9. Usuń ? umoż­li­wia usu­nię­cie wybra­nej pocz­ty elektronicznej,
2.10. Znajdź ? umoż­li­wia wyszu­ka­nie listu w fol­de­rach pocz­ty elektronicznej,
2.11. Rejestruj ? umoż­li­wia reje­stra­cję pocz­ty elek­tro­nicz­nej jako doku­men­tu w sys­te­mie w spo­sób ana­lo­gicz­ny do reje­stra­cji doku­men­tu zeskanowanego.
3. System musi udo­stęp­niać moż­li­wość kon­fi­gu­ra­cji kon­ta pocz­ty elek­tro­nicz­nej każ­de­mu użytkownikowi.
4. System zapew­nia moż­li­wość kon­fi­gu­ra­cji wie­lu kont pocz­ty elek­tro­nicz­nej dla każ­de­go użytkownika.
5. System musi umoż­li­wiać reje­stra­cję (przej­mo­wa­nie) pocz­ty elek­tro­nicz­nej przez użyt­kow­ni­ka, lub poprzez zde­fi­nio­wa­ną regu­łę (uwzględ­nia­ją­cą zapi­sa­ne­go wcze­śniej adre­sa­ta, oraz cią­głość kore­spon­den­cji w spra­wie), jako doku­men­tów w sys­te­mie z podzia­łem na treść, załącz­ni­ki i nagłówek.
6. W celu ogra­ni­cze­nia zbęd­nej dupli­ka­cji, nie­prze­ję­te maile muszą być odczy­ty­wa­ne z ser­we­ra pocz­to­we­go tyl­ko na żąda­nie użyt­kow­ni­ka (dostęp­ny listing nagłów­ków wia­do­mo­ści) i nie powin­ny być dodat­ko­wo prze­cho­wy­wa­ne w Systemie.
7. Dotyczy to rów­nież pocz­ty wysy­ła­nej przez klienta.
8. System musi umoż­li­wiać dołą­cza­nie pocz­ty elek­tro­nicz­nej do doku­men­tów lub spraw. Dołączenie musi być moż­li­we z pozio­mu klien­ta pocz­ty elek­tro­nicz­nej wbu­do­wa­ne­go w system.
Powyżej wyma­ga­nia spi­sa­ne przez oso­bę A

Inna oso­ba z tego same­go dzia­łu dodała:

1. Chcemy mieć klien­ta pocz­to­we­go w sys­te­mie, jest to wygod­ne rozwiązanie.
2. Chcemy aby klient pocz­to­wy miał moż­li­wość odczy­ta­nia i wysła­nia wia­do­mo­ści pocztowej.
3. Nie chce­my żeby EOD gro­ma­dzi­ło wszyst­kie wia­do­mo­ści syn­chro­ni­zo­wa­ne z ser­we­rem pocz­to­wym pro­to­ko­łem IMAP, a tyl­ko pobie­ra­ło nagłów­ki wiadomości.
4. Gdy użyt­kow­nik uzna, że wia­do­mość jest czę­ścią spra­wy ini­cju­je czyn­no­ści w EOD.
Powyżej wyma­ga­nia spi­sa­ne przez oso­bę B.

Świadomie poda­je źró­dło: dział IT tej instytucji.

Opublikowałem tyl­ko powyż­sze, bo resz­ta po ano­ni­mi­za­cji i tak była by pustą kart­ką (nie­ste­ty ten OPZ uka­że się dopie­ro za jakiś czas, a do tego momen­tu jest pouf­ny), ale mam nadzie­ję, że wyobra­że­nie sobie resz­ty jest dość pro­ste. I co z tym? Nic! Otóż nie jest pro­ble­mem taka for­ma wyra­że­nia wyma­gań przez Zamawiającego, bo on (biz­nes i nie tyl­ko jak widać) ina­czej nie potra­fi i nie jest to jego rola. Problemem jest uzna­nie tego za wyma­ga­nia wobec opro­gra­mo­wa­nia”. Powyższe jest raczej dopie­ro mate­ria­łem do ana­li­zy i projektowania. 

Wyobraźmy sobie teraz hipo­te­tycz­ny doku­ment wyni­ko­wy, czy­li kil­ku­na­stu (a może nawet kil­ku­dzie­się­ciu) nie­tech­nicz­nych pra­cow­ni­ków tej insty­tu­cji (księ­go­wość, admi­ni­stra­cja, itp.) z pomo­cą ana­li­ty­ka wyma­gań”, zebra­ło wyma­ga­nia, i pra­cu­jąc z edy­to­rem tek­stu w try­bie reje­stra­cji zmian, warsz­ta­to­wo, po iluś tam tygo­dniach wypra­co­wa­ło” osta­tecz­ną wer­sję wyma­gań” a potem nawet dzie­siąt­ki user sto­ry”. Ile stron będzie mia­ła taka Analiza Biznesowa Wymagań i co w niej będzie? 

Przykłady łatwo zna­leźć w Internecie:

przy­kład 1 (źr. https://​zamo​wie​nia​.mazo​via​.pl/​?​a​c​t​=​i​n​f​o​&​i​d​=​1​2​001):

Powyższe opra­co­wa­nie kosz­to­wa­ło 90 tys. zł. 

przy­kład 2 (źr. https://​plat​for​ma​za​ku​po​wa​.pl/​t​r​a​n​s​a​k​c​j​a​/​3​6​1​167):

Rozwiązanie

Od cza­su do cza­su przy­wo­łu­je tu na blo­gu podej­ście zwa­ne Model jako wyma­ga­nie” (popu­lar­ne skró­ty to: MDD – Model Driven Development, MBSE – Model Based System Engineering, MDSE – Model Driven System Engineering, o MBSE już pisa­łem ).

Kluczem są mode­le struk­tur tre­ści (doku­men­tów i ekra­nów GUI) . Powyższe życze­nia” jako spi­sa­ne wyma­ga­nia to (w peł­nej wer­sji) ogrom­na lista życzeń, nie pod­da­ją­ca się żad­nej kon­tro­li spój­no­ści i kom­plet­no­ści. Proszę podej­rzeć wska­za­ne wyżej przy­kła­dy, doku­men­ty na ponad 200 stron nie pod­da­ją­ce się żad­nej kon­tro­li… (pomi­jam, że wadli­we for­mal­nie, jeśli cho­dzi o uży­cie deka­ro­wa­nej notacji). 

Poniżej zamien­nik wyłącz­nie powyż­sze­go o poczcie elek­tro­nicz­nej, wyra­żo­ny mode­lem struk­tu­ry tre­ści. Jaką ma to zale­tę? Tę, że mamy zamknię­tą struk­tu­rę tre­ści i może­my ją mapo­wać na inne doku­men­ty (ich sza­blo­ny w pro­jek­cie) w celi wery­fi­ka­cji logi­ki spójności. 

Zakresy danych nie reali­zu­ją­ce logi­ki biz­ne­so­wej (i mało ryzy­kow­ne jeśli cho­dzi o pra­co­chłon­ność) moż­na mar­ko­wać z dokład­no­ścią do roli dane­go zesta­wu danych (poni­żej obsza­ry ozna­czo­ne linia prze­ry­wa­ną). Zgodnie z defi­ni­cją, sys­te­my infor­ma­cyj­ne prze­twa­rza­ją dane, więc dowol­ny sys­tem infor­ma­cyj­ny jest spro­wa­dzal­ny do skoń­czo­nej licz­by infor­ma­cji wyra­ża­nej jako doku­ment gru­pu­ją­cy okre­ślo­ne dane i reguł ich prze­twa­rza­nia . Rzecz w tym, że nie jest to baza danych i rela­cyj­ny model” (nie­ste­ty mono­lit moż­li­wy do wypra­co­wa­nia meto­dą water­fall), a odręb­ne doku­men­ty i ich struk­tu­ry (oraz słow­ni­ki zna­czeń uży­tych nazw). Każdy z nich może być pod­sta­wą opra­co­wa­nia odręb­ne­go, moż­li­we­go do samo­dziel­ne­go wyko­na­nia, modułu. 

Warto wie­dzieć, że:

Model rela­cyj­ny danych: zapi­sy­wa­nie ich w posta­ci współ­dzie­lo­nych znor­ma­li­zo­wa­nych struk­tur poję­cio­wych, pozba­wio­nych redun­dan­cji, jest pozba­wio­ny kon­tek­stu , nie spraw­dza się w sys­te­mach zarzą­dza­ją­cych doku­men­ta­mi. Dokument, tak­że w sen­sie praw­nym, nie może być gene­ro­wa­ną dyna­micz­nie (zapy­ta­nia SQL do bazy rela­cyj­nej) struk­tu­rą, bo jest wte­dy wir­tu­al­nym bytem, a taki nie sta­no­wi doku­men­tu w pra­wie (Kodeks Cywilny), nie da się tak­że zarzą­dzać jego cyklem życia. Dlatego doku­men­ty są coraz czę­ściej wyra­ża­ne jako struk­tu­ry XML/XSD i uzu­peł­nia­ne posta­cią ??do czy­ta­nia i dru­ku? w for­ma­cie pdf (real­nie sa to pli­ki pdf z załą­czo­ny­mi wer­sja­mi XML. (źr. Informacje dla korzy­sta­ją­cych z moich opra­co­wań – Jarosław Żeliński IT-Consulting – Systemy Informacyjne)

Poniżej pro­sty model listy ode­bra­nych maili”:

Wymagania doty­czą­ce pra­cy z pocz­ta elek­tro­nicz­ną obra­zu­je ten oto – wery­fi­ko­wal­ny – model struk­tu­ry tre­ści otrzy­ma­nej mailem:

Aby poka­zać jak to dzia­ła” pisze­my sce­na­riusz (spe­cy­fi­ka­cja przy­pad­ku uży­cia) sta­no­wią­cy kon­tekst uży­cia tego doku­men­tu (for­mu­la­rza). Służy on tak­że jako test pro­jek­to­wa­nej logi­ki, a póź­niej jako test odbior­czy goto­we­go produktu: 

1. Pracownik wybie­ra opcję Poczta Elektroniczna
2. SYSTEM wyświe­tla Lista prze­sy­łek ema­il dla zalo­go­wa­ne­go użytkownika
3. Pracownik kli­ka wybra­na pozy­cje na liście ,
4. SYSTEM wyświe­tla Treść Poczty Elektronicznej
5. Pracownik dekre­tu­je ją lub ozna­cza do usu­nię­cia OK
6. if dekretacja
6.1. wska­za­nie punk­tu kan­ce­la­ryj­ne­go i OK
7. else if usuń
end if 
8. SYSTEM sys­tem potwier­dza operacje

W tym momen­cie będę koń­czył, bo kon­ty­nu­ację czy­tel­nik znaj­dzie w jed­nym z wcze­śniej­szych arty­ku­łów, frag­ment poniżej: 

Pełna doku­men­ta­cja powin­na zawie­rać w załą­cze­niu deta­licz­ne struk­tu­ry tych for­mu­la­rzy (dia­gra­my przed­sta­wia­ją­ce struk­tu­ry XML, lub sko­men­to­wa­ne mock-up?y doku­men­tów). Taka spe­cy­fi­ka­cja zawie­ra wszyst­kie infor­ma­cje pozwa­la­ją­ce deve­lo­pe­ro­wi stwo­rzyć opro­gra­mo­wa­nie słu­żą­ce do zbie­ra­nia i zarzą­dza­nia infor­ma­cją. Jako model wyma­gań na sys­te­my typu EOD jest wystar­cza­ją­ca. Gdyby było praw­dą, że wyma­ga­my od opro­gra­mo­wa­nia tak­że, by zawar­tość wybra­nych pól tych for­mu­la­rzy była wyli­cza­na lub wery­fi­ko­wa­na, musi­my dodat­ko­wo udo­ku­men­to­wać zależ­no­ści mię­dzy tymi pola­mi. Model taki czę­sto war­to uzu­peł­nić wyma­ga­ną archi­tek­tu­rą opro­gra­mo­wa­nia, bo od niej zale­żą cechy jako­ścio­we apli­ka­cji, tak zwa­ne poza­funk­cjo­nal­ne. Będzie to wła­śnie model dzie­dzi­ny sys­te­mu, opi­sy­wa­ny na moim blo­gu wie­lo­krot­nie. (źr. Modele infor­ma­cyj­ne – Jarosław Żeliński IT-Consulting – Systemy Informacyjne).

Źródła

Šilingas, D., & Butleris, R. (2009). Towards imple­men­ting a fra­me­work for mode­ling softwa­re requ­ire­ments in MagicDraw UML. Information Technology and Control, 38(2).
Paredaens, J., Bra, P. D., Gyssens, M., & Gucht, D. van. (2012). The Structure of the Relational Database Model. Springer Science & Business Media.

Dokument a kumulacja faktów: OOAD i model dziedziny systemu

Tym razem o czymś co potra­fi zabić 😉 czy­li czym jest doku­ment oraz fakt i obiekt. Czym się róż­ni zakup kil­ku pro­duk­tów, w tym samym skle­pie, w np. godzin­nych odstę­pach cza­su, od zaku­pu wszyst­kich razem? Poza for­mą udo­ku­men­to­wa­nia, niczym: w skle­pie to samo i tyle samo zeszło ze sta­nu maga­zy­nu, a my wyda­li­śmy w obu przy­pad­kach tyle samo pie­nię­dzy (o pro­mo­cjach póź­niej)! W pierw­szym przy­pad­ku mamy kil­ka fak­tów zaku­pu, w dru­gim, jeden, ale zawsze tyle samo obiek­tów (pro­dukt). Faktura (para­gon) to doku­ment opi­sją­cy fakt, przed­miot sprze­da­ży jest obiek­tem. Tu obiek­tem jest opi­sy­wa­ny przed­miot zaku­pu. Ten arty­kuł to przy­kład archi­tek­tu­ry usłu­gi apli­ka­cji, któ­ra jest nie­czu­ła na takie różnice. 

Wprowadzenie

Żeby upo­rząd­ko­wać treść, w sto­sun­ku to archi­tek­tu­ry apli­ka­cji tu nie będę uży­wał pojęć kla­sa i obiekt” a kom­po­nent i doku­ment. Pojęcia obiekt i fakt tu będą doty­czy­ły świa­ta real­ne­go, to odpo­wied­nio: opi­sy­wa­ny przed­miot i zda­rze­nie z nim powią­za­ne. Innymi sło­wy: doku­ment może opi­sy­wać obiekt lub zda­rze­nie z nim powią­za­ne. Np. pro­dukt oraz fakt jego sprze­da­nia (dwa byty: sepa­ro­wa­nie kon­tek­stu doku­men­tów). Konkretne opro­gra­mo­wa­nie jako sys­tem, to kom­po­nen­ty (w UML obiek­ty okre­ślo­nej kla­sy) oraz dane zor­ga­ni­zo­wa­ne np. jako doku­men­ty (doku­ment: nazwa­na, okre­ślo­na struk­tu­ra danych). Aplikacje prze­twa­rza­ją dane opi­su­ją­ce real­ny świat, co ład­nie poka­zał i opi­sał Smith :

computer model real world
Smith, B. C. (1985). Computers, Models, and the Embedding World, The Limits of Correctness. SIGCAS Comput. Soc., 14,15(1,2,3,4), 18?26. doi: 10.1145/379486.379512

Projektowanie opro­gra­mo­wa­nia to two­rze­nie jego mode­lu, potem pozo­sta­je już tyl­ko jego imple­men­ta­cja. Obecnie pra­ce pro­jek­to­we i przy­go­to­wa­nie do imple­men­ta­cji tak­że są zali­cza­ne do pro­gra­mo­wa­nia” .

Projekt systemu sprzedaży

Każda ana­li­za powin­na być opar­ta na onto­lo­gii z dzie­dzi­ny pro­ble­mu. Dzięki cze­mu nazwy doku­men­tów, atry­bu­tów i ich war­to­ści będą spój­ne, jed­no­znacz­ne i nie­sprzecz­ne. Poniżej pro­sty model poję­cio­wy dla dzie­dzi­ny opi­sy­wa­ne­go tu problemu:

Model poję­cio­wy (dia­gram fak­tów SBVR lub model poję­cio­wy, dia­gram klas UML)

(UWAGA! Powyższy model nie jest żad­nym mode­lem dzie­dzi­ny” ani mode­lem danych”. To model pojęciowy). 

Modele poję­cio­we słu­żą do zarzą­dza­nia sys­te­mem pojęć (onto­lo­gia) dla dane­go mode­lu opro­gra­mo­wa­nia. Testowanie tego mode­lu pole­ga na spraw­dze­niu czy każ­da para połą­czo­nych seman­tycz­nie pojęć two­rzy popraw­ne i praw­dzi­we(!) zda­nie w języ­ku natu­ral­nym (tu musi­my brać popraw­kę na flek­sję języ­ka pol­skie­go), np. «sprze­da­ją­cy wysta­wia fak­tu­rę» (fakt) lub «fak­tu­ra jest doku­men­tem» (typ).

Oprogramowanie słu­ży do prze­twa­rza­nia danych, dla­te­go war­to opi­sać jak się to odby­wa. Bardzo wygod­ną meto­dą pro­jek­to­wa­nia struk­tur danych doku­men­ty (w tym opi­sie dia­gram struk­tur zło­żo­nych nota­cji UML). Po pierw­sze są one zro­zu­mia­łe dla przy­szłe­go użyt­kow­ni­ka, po dru­gie meto­da ta pozwa­la uwol­nić się od wad mode­li rela­cyj­nych: usu­nię­cie redun­dan­cji nazw co pro­wa­dzi do utra­ty ich kon­tek­stu. Dokumenty czę­sto mają róż­ny kon­tekst, zna­cze­nie pojęć zale­ży od kon­tek­stu. Relacyjny model danych, pozba­wio­ny redun­dan­cji, jest strat­ny: utrwa­lo­ne dane nie sta­no­wią żad­nej infor­ma­cji a doku­men­tem jest dopie­ro wynik zapy­ta­nia SQL do tabel. 

W przy­pad­ku opi­sy­wa­ne­go tu pro­jek­tu wyglą­da to tak:

Struktury danych zor­ga­ni­zo­wa­nych w doku­men­ty (nota­cja UML)

Mamy tu dwa doku­men­ty: Oferta i Faktura. Pojęcie Produkt ma swo­ją defi­ni­cję real­na (defi­ni­cja atry­bu­to­wa: poprzez cechy): jest to cos co ma nazwę, cenę i ilość”. Atrybuty Produktu na doku­men­tach przyj­mu­ją war­to­ści opi­sa­ne tym typem. Po dru­gie doku­ment nie­sie kon­tekst więc nada­je nazwie zna­cze­nie: np. data to data fak­tu­ry i data ofer­ty. To nie są te same daty, a pro­dukt ofe­ro­wa­ny (jako atry­but ofer­ty) nie musi być tym samym pro­duk­tem sprze­da­nym (jako atry­but Faktury).

Projekt powyż­szy poka­zu­je tak­że waż­ną rzecz: sepa­ro­wa­nie danych o obiek­tach (pro­duk­ty) i fak­tach (fak­tu­ra). Nie nale­ży na jed­nym doku­men­cie łączyć (mie­szać) kon­tek­stów (uwspól­nia­nie danych w mode­lu rela­cyj­nym). (Więcej na temat sepa­ra­cji kon­tek­stów obiek­tu i fak­tu w publi­ka­cji Chapter 3 Digital Documents as Data Carriers and a Method of Data Management Guaranteeing the Unambiguity of the Recorded Information: Ontology-Oriented Data Management and Document Databases”).

Poniżej, na dia­gra­mie sekwen­cji, widać, że dla kom­po­nen­tu zarzą­dza­ją­ce­go sta­na­mi maga­zy­no­wy­mi nie ma żad­ne­go zna­cze­nia ile jest (było) fak­tur, ope­ra­cje zmia­ny ilo­ści to poje­dyn­cze ope­ra­cje. Tak zapro­jek­to­wa­na apli­ka­cja jest odpor­na na to ile pro­duk­tów jest na ofer­cie i fak­tu­rze, mogą to być róż­ne ilo­ści. Oba te doku­men­ty: ofer­ta i fak­tu­ra, to cał­ko­wi­cie odręb­ne kon­struk­cje, to doku­men­ty rzą­dzą­ce się każ­dy inną logi­ką i mają­ce każ­dy inny cykl życia (tu np. Oferta nie jest utrwa­la­na). Często sto­so­wa­ne kon­struk­cje, takie jak dzie­dzi­cze­nie fak­tu­ry i ofer­ty po doku­men­cie” są tu naj­gor­szym pomysłem. 

Architektura. Nasza apli­ka­cja to kil­ka współ­pra­cu­ją­cych komponentów:

Obiektowy (kom­po­nen­to­wy) model dziedziny. 

Klasy ozna­czo­ne ste­reo­ty­pem «Document» to cią­gi zna­ków (np. XML) sta­no­wią­ce war­to­ści atry­bu­tów i para­me­try wywo­łań ope­ra­cji. (w UML: ?Document? A human-reada­ble file. Subclass of ?File?. )

Model archi­tek­tu­ry to sta­tycz­ny model, a ten może być nie­zro­zu­mia­ły, dla­te­go zawsze wzbo­ga­ca­my pro­jekt tech­nicz­ny archi­tek­tu­ry mode­lem dyna­mi­ki sys­te­mu: dia­gra­mem sekwen­cji. Diagram taki powi­nien powstać dla każ­dej usłu­gi apli­ka­cji (przy­pad­ku użycia):

Scenariusz reali­za­cji sprze­da­ży (dia­gram sekwen­cji UML)

Powyższy dia­gram poka­zu­je współ­pra­cę kom­po­nen­tów, opi­sa­ne wcze­śniej doku­men­ty są war­to­ścia­mi atry­bu­tów i para­me­tra­mi wywo­ły­wa­nych ope­ra­cji i ich odpo­wie­dzi. Powyższa archi­tek­tu­ra z powo­dze­niem wyko­na tak­że usłu­gi wglą­du do histo­rycz­nych fak­tur czy aktu­ali­za­cję cennika. 

Poprawna obiek­to­wa archi­tek­tu­ra i kom­plet­ny pro­jekt tech­nicz­ny apli­ka­cji (model PIM) opi­su­je pre­cy­zyj­nie jak wyko­nać imple­men­ta­cje i nie zawie­ra pro­jek­tu żad­nej bazy danych, ani tym bar­dziej zapy­tań SQL. Implementacja utrwa­la­nia nie może mieć wpły­wu na logi­kę biz­ne­so­wą sys­te­mu ani nawet zawie­rać jej! 

Samo opra­co­wa­nie rela­cyj­ne­go mode­lu danych oraz zapy­tań SQL, by gene­ro­wać powyż­sze doku­men­ty z warian­ta­mi doty­czą­cy­mi róż­nych ilo­ści ofe­ro­wa­nych i zama­wia­nych, zaj­mie kil­ka­krot­nie wię­cej cza­su niż opra­co­wa­nie powyż­sze­go, goto­we­go do imple­men­ta­cji, pro­jek­tu. Opracowanie mode­lu rela­cyj­ne­go bazy danych, wyma­ga­ło by dodat­ko­wo wie­dzy o wszyst­kich pozo­sta­łych doku­men­tach w tym sys­te­mie, a tego z regu­ły nigdy nie wie­my na początku!

Powyższy model to w peł­ni współ­pra­cu­ją­ce obiek­ty mają­ce ope­ra­cje, a pod­sta­wo­wym związ­kiem mode­lu obiek­to­we­go jest zwią­zek uży­cia (wywo­ła­nia ope­ra­cji), czy­li nie jest to tak zwa­ny ane­micz­ny model dzie­dzi­ny.

Tu tak­że war­to zwró­cić uwa­gę na kolej­ny czę­sty błąd i antyw­zo­rzec w pro­jek­tach dekla­ro­wa­nych jako obiek­to­we: sto­so­wa­nie dzie­dzi­cze­nia. Jest to mie­sza­nie mode­li poję­cio­wych i archi­tek­tu­ry (dzie­dzi­cze­nie, jako współ­dzie­le­nie, łamie pod­sta­wo­wą zasa­dę para­dyg­ma­tu obiek­to­we­go jaką jest her­me­ty­za­cja). Dlatego model poję­cio­wy i model archi­tek­tu­ry to z zasa­dy dwa odręb­ne mode­le z powo­dów jak wyżej opisane.

Modelowanie archi­tek­tu­ry systemu 

Podsumowanie

Powyższy opis to krót­ki ale prak­tycz­nie kom­plet­ny Opis Techniczny Oprogramowania. Wymaga nie­wiel­kich uzu­peł­nień (ewen­tu­al­ne sche­ma­ty opi­su­ją­ce meto­dy ope­ra­cji). Wykonanie imple­men­ta­cji na jego pod­sta­wie nie powin­no spra­wić pro­ble­mu oso­bie radzą­cej sobie z czy­ta­niem nota­cji UML. Projekt jest na tyle pre­cy­zyj­ny, że sta­no­wi utwór w rozu­mie­niu pra­wa autor­skie­go (pro­gra­mi­sta nie ma tu żad­nej swo­bo­dy decy­zji w pisa­niu kodu dla tej czę­ści). Projekt taki to tak­że opis okre­ślo­ne­go mecha­ni­zmu dzia­ła­nia, zawie­ra więc opis know-how i jako jego udo­ku­men­to­wa­na for­ma chro­ni to know-how (usta­wa o prze­ciw­dzia­ła­niu nie­uczci­wej konkurencji). 

Dlatego każ­dy pro­gram kom­pu­te­ro­wy napi­sa­ny na pod­sta­wie takiej doku­men­ta­cji, z zasa­dy jest utwo­rem zależ­nym. Developer ma pra­wa autor­skie oso­bi­ste do kodu jaki napi­sze, ale nie ma pra­wa do dys­po­no­wa­nia tym kodem: ma je posia­dacz praw mająt­ko­wych do pro­jek­tu, któ­ry jest tu utwo­rem pier­wot­nym. Jedyny wybór jaki ma tu deve­lo­per to wybór tech­no­lo­gii jakiej użyje.

https://​www​.igi​-glo​bal​.com/​b​o​o​k​/​e​m​e​r​g​i​n​g​-​c​h​a​l​l​e​n​g​e​s​-​s​o​l​u​t​i​o​n​s​-​b​e​s​t​-​p​r​a​c​t​i​c​e​s​/​2​7​1​7​3​3​#​t​a​b​l​e​-​o​f​-​c​o​n​t​e​nts

Powyższy pro­jekt wyko­na­no z uży­ciem Visual Paradigm.

Źródła

OMG​.org. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/
Weilkiens, T. (2007). Systems engi­ne­ering with SysML/UML: mode­ling, ana­ly­sis, design (1. Aufl). Morgan Kaufmann OMG Press/Elsevier.
Ozkaya, I. (2020). Building Blocks of Software Design. IEEE Software, 37(2), 3 – 5. https://​doi​.org/​1​0​.​1​1​0​9​/​M​S​.​2​0​1​9​.​2​9​5​9​049
Smith, B. C. (1985). The Limits of Correctness. SIGCAS Comput. Soc., 14,15(1,2,3,4), 18 – 26. https://​doi​.org/​1​0​.​1​1​4​5​/​3​7​9​4​8​6​.​3​7​9​512

Model i dokumentowanie wdrożenia

Ten arty­kuł to pró­ba przy­bli­że­nia czy­tel­ni­ko­wi poję­cia meta­mo­del i model. To tak­że mała prób­ka tego co jest pro­duk­tem nad­zo­ru autorskiego.

Nieco ponad pięć lat temu w arty­ku­le Diagram obiek­tów czy­li bot­tom-up pisa­łem o poję­ciu instan­cji obiek­tu i dia­gra­mie obiek­tów. Wtedy sku­pi­łem się na jed­nym tyl­ko wąt­ku, jakim jest ana­li­za zmie­rza­ją­ca do opra­co­wa­nia … no wła­śnie, cze­go? Z regu­ły auto­rzy doku­men­tów zawie­ra­ją­cych dia­gra­my klas” mówią, że two­rzą mode­le. Czy zawsze są to modele?

Wprowadzenie

Jednym z bar­dzo nie­do­ce­nia­nych typów dia­gra­mów UML są dia­gram obiek­tów i dia­gram wdro­że­nia (któ­ry jest rodza­jem dia­gra­mu obiek­tów). Oba te dia­gra­my słu­żą do mode­lo­wa­nia okre­ślo­nych sytu­acji. Nie raz pisa­łem, że pro­jekt (doku­men­ta­cja pro­jek­to­wa) tez ma cykl życia. To nie jest tak, że powsta­je doku­ment Wymagania, zawie­ra­ją­cy jakieś mode­le, a następ­nie ktoś za nie­go pła­ci i ten doku­ment lądu­je za szy­bą tyl­ko do odczytu.

Patrząc na cykl życia pro­jek­tu, doku­men­ta­cja sta­no­wią­ca począt­ko­wo Wymagania, żyje i roz­wi­ja się razem z nim. Ona tak­że ma swój cykl życia. Na koniec doku­men­ta­cja ta jest opi­sem tego co powsta­ło. Jest to model kon­kret­ne­go ukoń­czo­ne­go wdrożenia.

Meta Object Facility

(oso­by nie inte­re­su­ją­ce się teo­rią mogą pomi­nąć ten rozdział) 

MOF (Meta Object Facility) to spe­cy­fi­ka­cja okre­śla­ją­ca bazo­we poję­cia dla nota­cji zarzą­dza­nych przez Object Management Group . Specyfikacja ta okre­śla trzy pod­sta­wo­we pozio­my abs­trak­cji oraz poziom pod­sta­wo­wy jakim jest świat (przed­mio­ty) mode­lo­wa­ny. Realny świat to poziom M0. Zobrazowanie real­ne­go świa­ta za pomo­cą nazw przed­mio­tów i ich wybra­nych klu­czo­wych cech (bo nie wszyst­kich) to abs­trak­cja tego świa­ta. Jeżeli jakieś gru­py przed­mio­tów mają te same klu­czo­we cechy, ale róż­nią sie jedy­nie war­to­ścia­mi tych cech, np. wie­le przed­mio­tów róż­ni się wyłącz­nie kolo­rem i dłu­go­ścią ale opi­su­je­my je z pomo­cą kolo­ru i dłu­go­ści, to mówi­my, że mamy kla­sę przed­mio­tów o atry­bu­tach kolor i dłu­gość, i nada­je­my jej (temu zbio­ro­wi) nazwę, nazwa ta czę­sto jaw­nie wystę­pu­je w języ­ku natu­ral­nym, np. kolo­ro­we słom­ki” mają atry­bu­ty: kolor i dłu­gość. Zakładamy, że przed­mio­ty reagu­ją na bodź­ce czy­li mają zacho­wa­nia: słom­ka pod wpły­wem siły prze­miesz­cza się lub wygi­na (to operacja). 

Powyższy dia­gram obra­zu­je ww. pozio­my abs­trak­cji MOF. Złóżmy, że wśród drob­nych przed­mio­tów real­nych (poziom M0) są tak­że nasze słom­ki. Dwie z tych sło­mek obra­zu­je­my jak pro­sto­ką­ty mają­ce nazwy: Egzemplarz 1 i Egzemplarz 2 (mają uni­kal­ne nazwy bo musi­my je roz­róż­niać). To – poziom M1 – jest abs­trak­cja nasze­go świa­ta: jego model. Skoro słom­ki mają te same cechy: nazwa, kolor i dłu­goś, to two­rzy­my nazwę (tu Class) dla zbio­ru wszyst­kich takich sło­mek. Nazwa tego zbio­ru repre­zen­tu­je wszyst­kie takie słom­ki (zbiór sło­mek). Na pozio­mie M2 uży­wa­my już tyl­ko nazwy zbio­ru. Poziom M2 to meta­mo­del. Aby upo­rząd­ko­wać nasze mode­le i meta­mo­de­le, stan­da­ry­zu­je­my tę meto­dę opi­su, uma­wia­jąc sie, że ele­men­ty naszych mode­li to poję­cia (nazwy) i związ­ki mię­dzy nimi (zwa­ne tak­że aso­cja­cje). Pojęcia mają zawsze defi­ni­cje i repre­zen­tu­ją nazwy, czy­li zbio­ry ele­men­tów zgod­nych z daną defi­ni­cją (ele­men­ty dia­gra­mów), a defi­ni­cja ta to kla­sy­fi­ka­tor. Ta umo­wa to poziom M3, nazy­wa­ny meta-meta­mo­del (zbiór zbio­rów). Mówimy, że w UML wszyst­ko jest klasą.

Najnowsza spe­cy­fi­ka­cja MOF wska­zu­je, że co praw­da pod­sta­wo­we pozio­my abs­trak­cji to te czte­ry wymie­nio­ne, jed­nak nie ma żad­ne­go zaka­zu orga­ni­zo­wa­nia zbio­rów w zbio­ry. Robimy to na pozio­mie M2 a słu­żą do tego tak zwa­ne ste­reo­ty­py: są to kla­sy klas. Np. gdy­by było praw­dą, że słom­ki mają prze­kro­je kwa­dra­to­we i okrą­głe to albo doda­je­my im nową cechę: prze­krój o war­to­ści koło lub kwa­drat, albo two­rzy­my pod­zbio­ry «kwa­dra­to­we» i «okrą­głe». Możemy tak­że dopre­cy­zo­wać, że cechą sło­mek «kwa­dra­to­we» zawsze jest tak­że zapach a sło­mek «okrą­głe» ich cię­żar. Taka dodat­ko­wa defi­ni­cja typów klas i ich spe­cy­fi­ki to profil. 

Projektowanie i realizacja projektu

Cykl życia pro­jek­tu zaczy­na się od budo­wy archi­tek­tu­ry sys­te­mu, budu­je­my struk­tu­rę zło­żo­na z blo­ków o okre­ślo­nym zasto­so­wa­niu: mówi­my sys­tem kla­sy CRM”, sys­tem kla­sy ERP” czy sys­tem kla­sy WorkFlow”. Nie wie­my jakie kon­kret­ne apli­ka­cje wdro­ży­my, ale wie­my (powin­ni­śmy to zde­fi­nio­wać) jakie wyma­ga­nia sta­wia­my przed każ­dą z tych klas aplikacji.

Idea podej­ścia zgod­ne­go z MOF to ana­li­za i jej efekt: nazwa­ne blo­ki funk­cjo­nal­ne sys­te­mu (dia­gram komponentów):

Ich defi­ni­cje to wyma­ga­nia na te kom­po­nen­ty. Każdy z powyż­szych kom­po­nen­tów moż­na opi­sać przy­pad­ka­mi uży­cia. Całość może zostać zre­ali­zo­wa­na jako odręb­ne apli­ka­cje, każ­dy impo­nent jest zde­fi­nio­wa­ny poprzez wyma­ga­nia wobec nie­go. Nazwy kom­po­nen­tów są zwy­cza­jo­we, tak na praw­de są one defi­nio­wa­ne poprzez przy­pad­ki uży­cia i wewnętrz­ną archi­tek­tu­rę infor­ma­cji: są to dzie­dzi­no­we komponenty. 

Wybierając i wdra­ża­jąc kolej­ne apli­ka­cje zna­my ich nazwy i to jak współ­pra­cu­ją (dia­gram wdrożenia):

Instancje (nazwy apli­ka­cji praw­dzi­we ale przy­pad­ko­we, nie jest to reko­men­da­cja żad­ne­go z tych programów)

Powyższy dia­gram mozna uzu­peł­nić o infor­ma­cje o doce­lo­wym śro­do­wi­sku ich pracy:

Instancje wraz ze śro­do­wi­ska­mi w jakich zosta­ły uruchomione

Należy tak­że wska­zać jakiej kla­sy są to apli­ka­cje (któ­re wyma­ga­nia reali­zu­ją), dla­te­go każ­dą kon­kret­ną apli­ka­cje przy­po­rząd­ko­wu­je­my do okre­ślo­nej wcze­śniej kla­sy komponentów:

Instancje wraz przy­po­rząd­ko­wa­ny­mi kla­sy­fi­ka­to­ra­mi (np. Salesforce to egzem­plarz apli­ka­cji kla­sy System CRM)

Detali opi­su­ją­cych wdro­że­nie krok po kro­ku może być wię­cej (np. inter­fej­sy i ich spe­cy­fi­ka­cje). W każ­dym razie w dniu zakoń­cze­nia wdro­że­nia dostaw­ca zosta­wi po sobie deta­licz­ną doku­men­ta­cję wyko­na­nej imple­men­ta­cji, dla admi­ni­stra­to­ra całe­go sys­te­mu, będzie to kil­ka­set, a bywa że kil­ka tysię­cy, stron. Analityk-pro­jek­tant, po eta­pie nad­zo­ru autor­skie­go, zosta­wi po sobie doku­men­ta­cję zawie­ra­ją­ca abs­trak­cję: model sys­te­mu na potrze­by podej­mo­wa­nia decy­zji tak­tycz­nych i stra­te­gicz­nych, raczej kil­ka­dzie­siąt stron (patrz tak­że: Analiza, mode­lo­wa­nie i uspraw­nia­nie orga­ni­za­cji).

Następne wdro­że­nie nowe­go ele­men­tu sys­te­mu lub wpro­wa­dze­nie w nim zmian, nie będzie już wyma­ga­ło żad­nej owej ana­li­zy, a jed­nie pro­jek­tu poka­zu­ją­ce­go nowy kom­po­nent lub miej­sce gdzie będą wdra­ża­ne zmiany. 

Diagram kom­po­nen­tów to poziom M2. Diagram wdro­że­nia to poziom M1 wg. MOF. W ramach UML korzy­sta­my tu z dia­gra­mu kom­po­nen­tów i dia­gra­mu wdro­że­nia, są stan­dar­do­we pro­fi­le dla UML (MOF tak­że war­stwa M2: dodat­ko­we ste­reo­ty­py). Gdybyśmy chcie­li two­rzyć dedy­ko­wa­ne kom­po­nen­ty, zapew­ne deve­lo­per wyko­rzy­sta wzor­ce fra­me­wor­ki (goto­we zesta­wy biblio­tek) i wzor­ce pro­jek­to­we. To tak­że defi­niu­je się jako pro­fi­le w war­stwie M2 .

Źródła

OMG​.org. (2016, October). MetaObject Facility (MOF). https://​www​.omg​.org/​s​p​e​c​/​MOF
D’Souza, D. (1998). Objects, Components, and Frameworks with UML The CatalysisTM Approach. 116.
Larman, C. (2005). Applying UML and pat­terns: an intro­duc­tion to object-orien­ted ana­ly­sis and design and ite­ra­ti­ve deve­lop­ment (3rd ed). Prentice Hall PTR, c2005.
Wei, B., Sun, J., & Wang, Y. (2018). A Knowledge Engineering Approach to UML Modeling (S). SEKE, 60 – 63.
Evans, E. (2014). Domain-dri­ven design: tac­kling com­ple­xi­ty in the heart of softwa­re. Addison-Wesley.

Od zapytania do realizacji zamówienia czyli jak to się robi z BPMN

Wprowadzenie

Ostatnio poja­wi­ła się w pra­sie i mediach inter­ne­to­wych dys­ku­sja na temat tego czym jest fak­tu­ra, nie­ste­ty bar­dzo wie­le z tych opi­nii jest pozba­wio­na pod­staw mery­to­rycz­nych i praw­nych, są nie­jed­no­krot­nie po pro­stu nie­praw­dzi­we. Biorąc pod uwa­gę fakt, że wie­le tych opi­nii to opi­nie wygła­sza­ne przez przed­się­bior­ców, wyła­nia się smut­ny obraz jako­ści infor­ma­cji zbie­ra­nej meto­dą wywia­dów w toku ana­liz biz­ne­so­wych. Studiowanie lite­ra­tu­ry, cudzych opra­co­wań w roli audy­to­ra, ana­li­za pytań i uwag moich klien­tów to ogrom­ne doświad­cze­nie. Rok temu w arty­ku­le Mit o nota­cji BPMN pisa­łem o szko­dli­wo­ści nad­mia­ru szcze­gó­łów na mode­lach. To wszyst­ko razem skło­ni­ło mnie tym razem do opra­co­wa­nia przy­kła­du dia­gra­mu obra­zu­ją­ce­go pro­ces biz­ne­so­wy wyko­na­ny w nota­cji BPMN1.

Celem tego arty­ku­łu jest poka­za­nie jak opra­co­wać model pro­ce­su biz­ne­so­we­go bazu­jąc wyłącz­nie na pra­wie i tego jak to zro­bić zgod­nie z nota­cją BPMN. Pokazano tak­że, że nota­cja BPMN nie jest narzę­dziem doku­men­to­wa­nia wszyst­kie­go co wie­my o pro­ce­sie”. Istotne jest tak­że to, że nota­cja BPMN to język wyra­zu – narzę­dzie – a nie meto­dy­ka, oraz to że spe­cy­fi­ka­cja BPMN to nie pod­ręcz­nik mode­lo­wa­nia a jedy­nie opis pojęć i ich zna­czeń oraz przy­kła­dy kon­struk­cji (seman­ty­ka i syn­tak­ty­ka nota­cji) co nie zna­czy, że są to wzor­ce pro­jek­to­we. Uważam, że wzor­ców takich nie ma takich w biz­ne­sie, pro­ce­sów refe­ren­cyj­nych” też nie ma. Biznes to pra­wo oraz indy­wi­du­al­ne wewnętrz­ne regulacje.

W ramach wpro­wa­dze­nia opi­sa­no naj­pierw zasa­dy two­rze­nia mode­li ana­li­tycz­nych z uży­ciem nota­cji BPMN.

Notacja BPMN a MDA i UML

Kilka uwag na temat nota­cji BPMN i klu­czo­wych jej cech. Celem stwo­rze­nia tej nota­cji była komunikacja:

The pri­ma­ry goal of BPMN is to pro­vi­de a nota­tion that is readi­ly under­stan­da­ble by all busi­ness users, from the busi­ness ana­ly­sts that cre­ate the ini­tial dra­fts of the pro­ces­ses, to the tech­ni­cal deve­lo­pers respon­si­ble for imple­men­ting the tech­no­lo­gy that will per­form tho­se pro­ces­ses, and final­ly, to the busi­ness people who will mana­ge and moni­tor tho­se pro­ces­ses. Thus, BPMN cre­ates a stan­dar­di­zed brid­ge for the gap betwe­en the busi­ness pro­cess design and pro­cess imple­men­ta­tion.[BPMN c.1.1. 1]

Generalnie rzecz bio­rąc (patrz moje wytłusz­cze­nie): dia­gra­my te powin­ny być zro­zu­mia­łe dla tak zwa­nych ludzi biz­ne­su (bo jeże­li nie są, to są bez­u­ży­tecz­ne), sta­no­wią (sfor­ma­li­zo­wa­ny) szkic dla ludzi odpo­wie­dzial­nych za ich imple­men­ta­cję. Modele pro­ce­sów biz­ne­so­wych sta­no­wią ele­ment mode­li CIM (Computational Independent Model, model nie­za­leż­ny od tech­no­lo­gii IT2).

Poniżej cytu­ję aka­pit opi­su­ją­cy isto­tę podzia­łu mode­li na pozio­my abs­trak­cji (dokład­no­ści).

As an alter­na­ti­ve to full Process Modeling Conformance, the­re are three con­for­man­ce sub-clas­ses defined:

  • Descriptive
  • Analytic
  • Common Executable

Descriptive is con­cer­ned with visi­ble ele­ments and attri­bu­tes used in high-level mode­ling. It sho­uld be com­for­ta­ble for ana­ly­sts who have used BPA flow­char­ting tools.

Analytic con­ta­ins all of Descriptive and in total abo­ut half of the con­structs in the full Process Modeling Conformance Class. It is based on expe­rien­ce gathe­red in BPMN tra­ining and an ana­ly­sis of user-pat­terns in the Department of Defense Architecture Framework and plan­ned stan­dar­di­za­tion for that framework.

Both Descriptive and Analytic focus on visi­ble ele­ments and a mini­mal sub­set of sup­por­ting attributes/elements.

Common Executable focu­ses on what is needed for exe­cu­ta­ble pro­cess models.

Elements and attri­bu­tes not in the­se sub-clas­ses are con­ta­ined in the full Process Modeling Conformance class. The ele­ments for each sub-class are defi­ned in the next sub clau­se. [BPMN c.2.2.1.1]

Istotą mode­lo­wa­nia pro­ce­sów z uży­ciem BPMN jest więc wła­ści­wy dobór pozio­mu szcze­gó­ło­wo­ści. Powyższe ma zna­cze­nie w kon­tek­ście umiesz­cze­nia tych typów mode­li na tle MDA (Model Driven Architecture2) i sko­re­lo­wa­nia z mode­la­mi UML.

Na pozio­mie CIM powsta­ją mode­le opi­su­ją­ce mecha­nizm dzia­ła­nia orga­ni­za­cji w cał­ko­wi­tym ode­rwa­niu od tech­no­lo­gii IT wspie­ra­ją­cych tę orga­ni­za­cję. Notacja BPMN jest tu wspie­ra­na spe­cy­fi­ka­cją SBVR3 (biz­ne­so­wy słow­nik pojęć i regu­ły biz­ne­so­we). Są to wyłącz­nie mode­le poglą­do­we i analityczne.

Kolejny krok to opra­co­wa­nie mode­li wyko­ny­wal­nych czy­li mode­li imple­men­ta­cji pro­ce­sów (wyra­żo­nych w BPMN) z uży­ciem sys­te­mów BPMS (Business Process Management Systems, są to śro­do­wi­ska wyko­naw­cze mode­li BPMN com­mon exe­cu­ta­ble). W prak­ty­ce te mode­le mają wer­sję PIM (wyko­na­ne na bazie stan­dar­du BPMN/BPEL/XPDL) i PSM czy­li dosto­so­wa­ne do śro­do­wi­ska BPMS kon­kret­ne­go pro­du­cen­ta plat­for­my. Jest to ścież­ka bazu­ją­ca cał­ko­wi­cie na nota­cji BPMN i plat­for­mach wyko­naw­czych BPMS.

Proces tra­dy­cyj­ny” inży­nie­rii opro­gra­mo­wa­nia opar­ty na MDA tak­że zaczy­na się powsta­nia mode­lu CIM. Kolejny etap (model) to zawar­cie umo­wy na zakres pro­jek­tu czy­li okre­śle­nie wyma­gań. Do tego słu­ży model przy­pad­ków uży­cia (w UML od wer­sji 2.5 jest jaw­nie okre­śla­ny jako dodat­ko­wy”, patrz Figure 6.1 Semantic Areas of UML4):

Rys. Semantic are­as of UML 2.5.1

Biorąc pod uwa­gę zmia­ny jakie wpro­wa­dzo­no do UML w v.2.5. w zasa­dzie książ­ki i pod­ręcz­ni­ki UML napi­sa­ne przed 2015 rokiem (wej­ście 2.5. UML), moż­na wyrzu­cić do kosza.

Po okre­śle­niu zakre­su pro­duk­tu, powsta­je model PIM sta­no­wią­cy model mecha­ni­zmu dzia­ła­nia opro­gra­mo­wa­nia. Ten model to spe­cy­fi­ka­cja logi­ki dzia­ła­nia (czę­sto sta­no­wi know-how zama­wia­ją­ce­go). Po doko­na­niu wybo­ru dostaw­cy, ten – mając na uwa­dze tech­no­lo­gię któ­rej uży­je, two­rzy model PSM i reali­zu­je imple­men­ta­cję (w prak­ty­ce, pomi­ja się model PSM, naj­czę­ściej powsta­je od razu kod na bazie archi­tek­tu­ry opi­sa­nej w mode­lu PIM).

Zostało to zobra­zo­wa­ne na dia­gra­mie poniżej:

Rys. Struktura mode­li zgod­nie z MDA.

Proces realizacji potrzeb przedsiębiorstwa

Proces reali­za­cji potrzeb przed­się­bior­stwa (orga­ni­za­cji) jest ini­cjo­wa­ny stwier­dze­niem owej potrze­by (wyma­ga­na usłu­ga, przed­miot, inne) a koń­czy się roz­li­cze­niem jej reali­za­cji (dostar­cze­nia). Standardowy pro­ces świad­cze­nia usłu­gi lub dostar­cze­nia pro­duk­tu jest opi­sa­ny w Kodeksie Cywilnym5 (zle­ce­nie lub dzie­ło). Co do zasa­dy więc, na pew­nym okre­ślo­nym pozio­mie szcze­gó­ło­wo­ści, pro­ces ten jest moż­li­wy do opi­sa­nia bez jakich­kol­wiek kon­sul­ta­cji z kim­kol­wiek, treść usta­wy wystarczy.

Opis pro­ce­su: Pojawianie się potrze­by skut­ku­je opra­co­wa­niem zapy­ta­nia ofer­to­we­go (opis przed­mio­tu zamó­wie­nia jakim może być usłu­ga lub pro­dukt). Z regu­ły przy­bie­ra for­mę Zapytania ofer­to­we­go. Zapytanie takie prze­ka­zy­wa­ne jest poten­cjal­ne­mu dostaw­cy, któ­ry opra­co­wu­je ofer­tę na reali­za­cję tego co opi­sa­no w Zapytaniu. Oferta taka jest ana­li­zo­wa­na, jeże­li zosta­nie przy­ję­ta, sta­je się umo­wą pomię­dzy Nabywcą a Dostawcą. Umowa ta sta­no­wi pod­sta­wę Realizacji zamó­wie­nia (jakim jest zaak­cep­to­wa­na ofer­ta). Po zre­ali­zo­wa­niu Zamówienia Dostawca zgła­sza goto­wość prze­ka­za­na przed­mio­tu zamó­wie­nia, nastę­pu­je odbiór. Po odbio­rze jest wysta­wia­na fak­tu­ra na kwo­tę wska­za­ną w Ofercie, w okre­ślo­nym ter­mi­nie ma miej­sce płat­ność. Zamówienie jest zre­ali­zo­wa­ne i rozliczone.

Opisane aktyw­no­ści są uza­leż­nio­ne od okre­ślo­nych ter­mi­nów. Biorąc pod uwa­gę fakt, że udział bio­rą w tym pro­ce­sie dwa pod­mio­ty, a całość jest syn­chro­ni­zo­wa­na ter­mi­na­mi (muszą one być usta­la­ne) pro­ces ten moż­na opi­sać takim modelem:

Rys. Proces reali­za­cji potrze­by w orga­ni­za­cji. Notacja BPMN.

Powyższy dia­gram to model ana­li­tycz­ny. Model poglą­do­wy były­by uprosz­czo­ny do aktyw­no­ści i doku­men­tów, zapew­ne były by to dwa odręb­ne pro­ste mode­le (dla Dostawcy i dla Zamawiającego).

Jak widać uwzględ­nio­no na tym mode­lu (model ana­li­tycz­ny) klu­czo­we fak­ty jaki­mi są ter­mi­ny i momen­ty dorę­cze­nia. Wszelkie deta­le poszcze­gól­nych aktyw­no­ści sta­no­wią naj­czę­ściej spe­cy­fi­kę kon­kret­nych pod­mio­tów i są opi­sa­ne pro­ce­du­ra­mi (np. pro­ce­du­ra­mi ISO z god­nie ze sto­sow­ną nor­mą). Dokumentowanie tych deta­li z uży­ciem kolej­nych, szcze­gó­ło­wych dia­gra­mów w nota­cji BPMN z regu­ły nie ma sen­su, gdyż ich adre­sa­ta­mi (recen­zen­ta­mi) byli by (są) wyko­naw­cy tych prac, a Ci raczej bez pro­ble­mu posłu­gu­ją się pro­ce­du­ra­mi w typo­wej posta­ci zna­nej z norm (testy), a nie dia­gra­ma­mi BPMN. Umieszczanie dodat­ko­wych deta­li wprost na tym dia­gra­mie dopro­wa­dzi do powsta­nia mon­stru­al­ne­go arku­sza, trud­ne­go w użyciu.

Na mode­lach ana­li­tycz­nych posłu­gu­je­my dwo­ma klu­czo­wy­mi poję­cia­mi (BPMN, Annex C Glossary1):

Atomic Activity – An acti­vi­ty not bro­ken down to a finer level of Process Model deta­il. It is a leaf in the tree-struc­tu­re hie­rar­chy of Process acti­vi­ties. Graphically it will appe­ar as a Task in BPMN.

Business Process – A defi­ned set of busi­ness acti­vi­ties that repre­sent the steps requ­ired to achie­ve a busi­ness objec­ti­ve. It inc­lu­des the flow and use of infor­ma­tion and resources.

Atomowym zada­niem, sta­no­wią­cym abs­trak­cję całej aktyw­no­ści biz­ne­so­wej pro­wa­dzą­cej do osią­gnię­cia celu tej pra­cy, jest aktyw­ność two­rzą­ca okre­ślo­ny pro­dukt, mode­lo­wa­ny w BPMN jako DataObject (nota­cja BPMN jest opar­ta na zało­że­niu, że wszel­kie efek­ty pra­cy są doku­men­to­wa­ne). Innymi sło­wy nie umiesz­cza­my na mode­lach pro­ce­sów deta­licz­nych skła­do­wych zadań sta­no­wią­cych ele­men­ty pro­ce­du­ry danej aktyw­no­ści. Procedury mode­lu­je­my na osob­nych dia­gra­mach lub po pro­stu opi­su­je­my tek­stem w odręb­nej doku­men­ta­cji i powo­łu­je­my się na nie.

Co do zasa­dy na mode­lach ana­li­tycz­nych sto­su­je­my pod­sta­wo­wy, mini­mal­ny zestaw sym­bo­li opi­sa­ny w spe­cy­fi­ka­cji, co gwa­ran­tu­je ich czy­tel­ność i zro­zu­mia­łość przez typo­we­go adre­sa­ta jakim jest oso­ba, któ­rej pra­cę opi­sa­no. Korzystanie z roz­sze­rzo­ne­go zesta­wu sym­bo­li (np. sym­bo­le deta­licz­nych zadań z iko­na­mi w lewym gór­nym roku, dodat­ko­we zda­rze­nia itp.) nie ma sen­su na pozio­mie mode­li ana­li­tycz­nych, gdyż sym­bo­le te powsta­ły dla mode­li wyko­ny­wal­nych, prze­cięt­ny adre­sat doku­men­ta­cji ana­li­tycz­nej nie pora­dzi sobie z ich inter­pre­ta­cją. W efek­cie po pro­stu utra­ci­my komu­ni­ka­cję w pro­jek­cie, co jest nie­ste­ty bar­dzo czę­stym zja­wi­skiem i przy­czy­ną więk­szo­ści pro­ble­mów w projektach.

Podsumowanie

Na począt­ko­wym, biz­ne­so­wym, eta­pie pro­jek­tów ana­li­tycz­nych celem doku­men­ta­cji pro­ce­sów biz­ne­so­wych jest opi­sa­nie mecha­ni­zmu dzia­ła­nia orga­ni­za­cji bez zbęd­nych deta­li (te zmie­nia­ją się dość czę­sto). Jeżeli doku­men­ta­cja pro­ce­sów biz­ne­so­wych wyma­ga aktu­ali­za­cji czę­ściej niż raz w roku (a lepiej raz na pięć lat) jest to sygnał, że jest to zła, zbyt szcze­gó­ło­wa dokumentacja.

Literatura nauko­wa jest peł­na opra­co­wań wska­zu­ją­cych, że pro­ce­sy biz­ne­so­we i logi­ka biz­ne­so­wa to odręb­ne obsza­ry opi­su i mode­lo­wa­nia. Notacja BPMN słu­ży do mode­lo­wa­nia pro­ce­sów. Logikę biz­ne­so­wą opi­su­je­my z uży­ciem reguł biz­ne­so­wych3, tablic decy­zyj­nych (patrz arty­kuł SBVR…), tu jeden z wie­lu przy­kła­dów takich komen­ta­rzy:6.

Model pro­ce­sów biz­ne­so­wych jest czę­sto, w lite­ra­tu­rze przed­mio­tu, nazy­wa­ny mode­lem wewnętrz­ne­go łań­cu­cha war­to­ści, a nie raz po pro­stu wewnętrz­ną stra­te­gią reali­za­cji celów ryn­ko­wych. Skoro jest to stra­te­gia, to nie powin­na się ona czę­sto zmie­niać. W powyż­szym mode­lu, uszcze­gó­ło­wie­nia może wyma­gań aktyw­ność reali­za­cji zamó­wie­nia, gdyż w zależ­no­ści od pod­mio­tu, może to być reali­za­cja nie­try­wial­nej usłu­gi lub wytwo­rze­nia pro­duk­tu. Była by to tak zwa­na dekom­po­zy­cja i powsta­nie dru­gi poziom szcze­gó­ło­wo­ści. Pozostałe aktyw­no­ści to two­rze­nie okre­ślo­nych doku­men­tów, a spo­sób ich powsta­wa­nia jest okre­ślo­ny pro­ce­du­rą i tym jakie pola zawie­ra dana for­mat­ka DataObject. Ten poziom szcze­gó­łów opi­su­je­my słow­ni­kiem i regu­ła­mi biz­ne­so­wy­mi (SBVR3).

Biorąc pod uwa­gę fakt, że ser­we­ry BPMS są bar­dzo rzad­ko wyko­rzy­sty­wa­ne, dia­gra­my BPMN na pozio­mie com­mon exe­cu­ta­ble prak­tycz­nie nie są two­rzo­ne. Jeżeli celem two­rze­nia mode­li pro­ce­sów biz­ne­so­wych jest ana­li­za przed­wdro­że­nio­wa, po mode­lu ana­li­tycz­nym powsta­je umo­wa w posta­ci dia­gra­mu Przypadków Użycia. Przypadek uży­cia (patrz arty­kuł Transformacja…) to odpo­wied­nik ato­mo­wej aktyw­no­ści. Innymi sło­wy Przypadki Użycia (UML), jako usłu­gi apli­ka­cyj­ne, wspie­ra­ją okre­ślo­ne aktyw­no­ści (a kon­kret­nie powsta­wa­nie lub prze­twa­rza­nie kon­kret­nych doku­men­tów mode­lo­wa­nych w BPMN jako obiek­ty DataObject), co opi­sa­no na pierw­szym diagramie.

Faktura. Diagram pro­ce­su biz­ne­so­we­go poka­zu­je tak­że, że fak­tu­ra jako doku­ment, nie jest zobo­wią­za­niem. Zobowiązaniem Dostawcy jest zawar­ta umo­wa na dosta­wę a zobo­wią­za­niem Nabywcy jest płat­ność po otrzy­ma­niu przed­mio­tu zamó­wie­nia. Zobowiązanie Nabywcy powsta­je dopie­ro po (z regu­ły pisem­nym) ode­bra­niu przed­mio­tu zamó­wie­nia, fak­tu­ra jest wyłącz­nie tak zwa­nym dowo­dem księ­go­wym, czy­li doku­men­tem stwier­dza­ją­cy jakie kwo­ty zaksięgować.

________________________________
1.
About the Business Process Model And Notation Specification Version 2.0.2. OMG​.org. https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/. Published January 13, 2014. Accessed February 10, 2019.
2.
MDA Specifications | Object Management Group. https://​www​.omg​.org/​m​d​a​/​s​p​e​c​s​.​htm. Published June 1, 2014. Accessed February 11, 2019.
3.
About the Semantics Of Business Vocabulary and Rules Specification Version 1.4. OMG​.org. https://​www​.omg​.org/​s​p​e​c​/​S​B​VR/. Published May 1, 2017. Accessed February 11, 2019.
4.
About the Unified Modeling Language Specification Version 2.5.1. OMG​.org. https://​www​.omg​.org/​s​p​e​c​/​U​ML/. Published December 1, 2017. Accessed February 11, 2019.
6.
Domain-Specific Conceptual Modeling Concepts, Methods and Tools, Herausgeber: Karagiannis, Dimitris, Mayr, Heinrich C., Mylopoulos, John (Eds.), ISBN 978 – 3‑319 – 39417‑6, str. 405.

Procesy biznesowe a procedury

Wstęp

Powodem napi­sa­nia tego arty­ku­łu była publikacja:

Wdrożenie zin­te­gro­wa­nych elek­tro­nicz­nych usług, infor­ma­cyj­nych na przy­kła­dzie porad­ni­ków przed­się­bior­cy, udo­stęp­nia­nych poprzez Punkt Kontaktowy w Polsce” (Elektroniczna gospo­dar­ka nr 4/2015, plik pdf).

Autorzy Mgr Szymon Mamrot, dok­to­rant na Wydziale Informatyki i Gospodarki Elektronicznej Uniwersytetu Ekonomicznego w Poznaniu, głów­ny spe­cja­li­sta w Centrum Elektronicznej Gospodarki Instytutu Logistyki i Magazynowania (e‑mail: szymon.mamrot@ilim.poznan.pl). Mgr Magdalena Stachowicz, absol­went­ka stu­diów dok­to­ranc­kich na Wydziale Politologii Uniwersytetu Marii Curie-Skłodowskiej w Lublinie, star­szy spe­cja­li­sta w Centrum Elektronicznej Gospodarki Instytutu Logistyki i Magazynowania (e‑mail: magdalena.stachowicz@ilim.poznan.pl). Artykuł był recenzowany.

Autorzy cytu­ją mię­dzy inny­mi mój arty­kuł, a kon­kret­nie defi­ni­cję pro­ce­su biz­ne­so­we­go, piszą tak­że o mode­lo­wa­niu pro­ce­sów i o nota­cji BPMN. Autorzy piszą:

W arty­ku­le auto­rzy pod­ję­li pró­bę zgłę­bie­nia pro­ble­mu badaw­cze­go, jakim jest zasto­so­wa­nie nota­cji Business Process Modeling Notation ( BPMN) do two­rze­nia z inte­gro­wa­nych elek­tro­nicz­nych usług infor­ma­cyj­nych. Posługując się przy­kła­dem porad­ni­ków przed­się­bior­cy, udo­stęp­nia­nych na por­ta­lu Punktu Kontaktowego (PK), udo­wod­ni­li, że nota­cja BPMN pozwa­la budo­wać skom­pli­ko­wa­ne mode­le pro­ce­sów, uwzględ­nia­ją­cych wie­le powią­za­nych ze sobą zadań i infor­ma­cji. Tworzenie zin­te­gro­wa­nych elek­tro­nicz­nych usług infor­ma­cyj­nych, cie­ka­wych w for­mie i obszer­nych w pomoc­ne tre­ści mery­to­rycz­ne, jest przy­szło­ścią współ­cze­snej e‑administracji, nie tyl­ko w Polsce, ale i w Europie.

Jednak w tre­ści, jest nie­praw­dzi­wa teza:

Nie ma w tym przy­pad­ku ogra­ni­cze­nia, że pro­ces musi coś wytwarzać.

Wyjaśnijmy sobie dla­cze­go nieprawdziwa.

Streszczenie

Jako, że zosta­łem zacy­to­wa­ny przez ww. auto­rów, arty­kuł ten sta­no­wi moją odpo­wiedź do tej publi­ka­cji. Autorzy pod­wa­ży­li defi­ni­cję, mówią­cą, że pro­ces biz­ne­so­wy two­rzy pro­dukt. Skupiłem się tu na for­mal­nym wywo­dzie pro­wa­dzą­cym do defi­ni­cji pojęć: pro­ces, pro­ces biz­ne­so­wy i pro­ce­du­ra, na tle nota­cji BPMN, na któ­rą auto­rzy się powo­łu­ją. Wykazałem, że poję­cie pro­duk­tu pro­ce­su jest fun­da­men­tem defi­ni­cji poję­cia pro­ces biz­ne­so­wy nie tyl­ko w nota­cji BPMN. Wskazałem tak­że błęd­ne uży­cie przez auto­rów powią­za­ne­go z poję­ciem pro­ces poję­cia bram­ki (ang. gateway).

Procedura, proces i proces biznesowy

Autorzy piszą:

Według defi­ni­cji języ­ko­wej, zawar­tej w Słowniku Języka Polskiego PWN, pro­ce­du­ra to: 1. okre­ślo­ne regu­ły postę­po­wa­nia w jakiejś spra­wie, zwy­kle o cha­rak­te­rze urzę­do­wym lub praw­nym; 2. w języ­kach pro­gra­mo­wa­nia: wydzie­lo­ny frag­ment algorytmu.

W arty­ku­le auto­rzy posłu­gu­ją się pierw­szym zna­cze­niem uży­tym w Słowniku (pro­ce­du­ra jako okre­ślo­ne regu­ły postę­po­wa­nia), przy czym istot­na jest lista czyn­no­ści i sama kolej­ność ich wykonania.

Przyjmowanie naj­ogól­niej­szych defi­ni­cji jest ryzy­kow­ne, tym bar­dziej, że celem publi­ka­cji było

…przed­sta­wie­nie nowej meto­dy two­rze­nia zin­te­gro­wa­nych elek­tro­nicz­nych usług infor­ma­cyj­nych, przy zasto­so­wa­niu nota­cji BPMN.

Zastosowanie sfor­ma­li­zo­wa­nej nota­cji, jaką jest BPMN, i jed­no­cze­sne ujmo­wa­nie poję­cia pro­ce­su naj­ogól­niej jak się da i w ode­rwa­niu od tej nota­cji, jest ryzy­kow­ne. Już tu: pro­ce­du­ra jako okre­ślo­ne regu­ły postę­po­wa­nia, przy czym istot­na jest lista czyn­no­ści i sama kolej­ność ich wyko­na­nia” widać, że ogól­na defi­ni­cja zosta­ła uzu­peł­nio­na o istot­ność listy czyn­no­ści i ich kolej­no­ści, czym auto­rzy zbli­ży­li się jed­nak do poję­cia algo­ryt­mu”. W dal­szej czę­ści piszą:

Według nor­my ISO 9000, pro­ces to: każ­de dzia­ła­nie, któ­re prze­kształ­ca wej­ście (dane wej­ścio­we) na
wyj­ście (dane wyj­ścio­we). Proces może w swo­im ?wnę­trzu? zawie­rać zbiór róż­nych ope­ra­cji (dzia­łań) wza­jem­nie ze sobą powią­za­nych i na sie­bie oddzia­łu­ją­cych. Jarosław Żeliński w swo­jej pra­cy, jako ana­li­tyk biz­ne­so­wy i sys­te­mo­wy, sto­su­je nastę­pu­ją­cą defi­ni­cję pro­ce­su: pro­ces to prze­kształ­ce­nie wej­ścia pro­ce­su w jego wyj­ście, z uży­ciem okre­ślo­nych zaso­bów i w obec­no­ści okre­ślo­nych ogra­ni­czeń.

Autorzy nie­ste­ty wyję­li to zda­nie z kon­tek­stu, cały mój zapis brzmiał:

Polecam cie­ka­wy arty­kuł na temat defi­ni­cji pro­ce­sów, w szcze­gól­no­ści Procesu Biznesowego. Zestawiono ze sobą roż­ne defi­ni­cje na prze­strze­ni ostat­nich nie­mal 20 lat. Najbardziej podo­ba mi się pro­sto­ta: ?a busi­ness pro­cess is a series of steps desi­gned to pro­du­ce a pro­duct or servi­ce? (Szczegóły:" style="box-sizing: border-box; margin: 0px; padding: 0px; border-bottom: 1px dotted #000000 !important; text-decoration: none !important; color: #000000 !important;">pro­ces biz­ne­so­wy to Szczegóły:" style="box-sizing: border-box; margin: 0px; padding: 0px; border-bottom: 1px dotted #000000 !important; text-decoration: none !important; color: #000000 !important;">sekwen­cja dzia­łań zapro­jek­to­wa­nych w celu wytwo­rze­nia pro­duk­tu lub Szczegóły:" style="box-sizing: border-box; margin: 0px; padding: 0px; border-bottom: 1px dotted #000000 !important; text-decoration: none !important; color: #000000 !important;">usłu­gi).

Jeśli uzna­my, że Szczegóły:

" style="box-sizing: border-box; margin: 0px; padding: 0px; border-bottom: 1px dotted #000000 !important; text-decoration: none !important; color: #000000 !important;">pro­dukt i usłu­ga to coś co ma war­tość dla klien­ta”, to powsta­je pro­sta i praw­dzi­wa moim zda­niem defi­ni­cja opi­su­ją­ca sed­no spra­wy”. Ogólnie wymo­wa arty­ku­łu potwier­dza moją tezę o abs­trak­cyj­no­ści pro­ce­su”, nama­cal­ne są za to pozo­sta­łe jego ele­men­ty: wej­ście i wyj­ście (pro­duk­ty), zaso­by (ludzie i maszy­ny) oraz Szczegóły:
" style="box-sizing: border-box; margin: 0px; padding: 0px; border-bottom: 1px dotted #000000 !important; text-decoration: none !important; color: #000000 !important;">regu­ły biz­ne­so­we (te są dokumentowane). 

Na zachę­tę cytat :):

The term ?pro­cess? is used in a wide varie­ty of ways. The first defi­ni­tion offe­red by MerriamWebster Online is (1) a natu­ral phe­no­me­non mar­ked by gra­du­al chan­ges that lead toward a par­ti­cu­lar result (e.g. the pro­cess of growth). In order to avo­id con­fu­sing our use of the term ?pro­cess? with any other possi­ble usa­ge, we will con­si­sten­tly use the term Business Process.

źr. http://​www​.bptrends​.com/​p​u​b​l​i​c​a​t​i​o​n​f​i​l​e​s​/​a​d​v​i​s​o​r​2​0​1​0​1​2​1​4​.​pdf

Osobiście w swo­ich pro­jek­tach sto­su­ję defi­ni­cję brzmią­cą: Szczegóły:" style="box-sizing: border-box; margin: 0px; padding: 0px; border-bottom: 1px dotted #000000 !important; text-decoration: none !important; color: #000000 !important;">Proces to prze­kształ­ce­nie wej­ścia pro­ce­su w jego wyj­ście, z uży­ciem okre­ślo­nych zaso­bów i w obec­no­ści okre­ślo­nych ograniczeń. 

(https://it-consulting.pl//2010/12/17/co-to-jest-proces-biznesowy-po-raz-kolejny/)

Tak więc gene­ral­nie cho­dzi o roz­róż­nie­nie pojęć: pro­ces i pro­ces biz­ne­so­wy. Na moim blo­gu pro­wa­dzę tak­że słow­nik, jego celem jest zapew­nie­nie jed­no­znacz­no­ści arty­ku­łów, któ­re publi­ku­ję. Publikowane tam defi­ni­cje opie­ra­ją się na dostęp­nych źró­dłach, speł­nia­ją też pod­sta­wo­wą zasa­dę budo­wy słow­ni­ka (name­spa­ce): defi­ni­cje pojęć dzie­dzi­no­wych muszą się wza­jem­nie wyklu­czać i obej­mo­wać sobą wszyst­kie desy­gna­ty z opi­sy­wa­nej dzie­dzi­ny: każ­dy nazwa­ny byt dzie­dzi­ny (desy­gnat) speł­nia tyl­ko jed­ną defi­ni­cję, popraw­nie opi­sa­na dzie­dzi­na pro­ble­mu nie ma bytów nie­zde­fi­nio­wa­nych czy­li nie­na­zwa­nych (co ozna­cza, że popraw­ny słow­nik zawie­ra poję­cia pozwa­la­ją­ce jed­no­znacz­nie nazwać wszyst­ko w danej dzie­dzi­nie), poję­cie spe­cja­li­zu­ją­ce są typa­mi swo­ich uogól­nień i łącz­nie sta­no­wią tak­że popraw­ny słow­nik (na pod­sta­wie OMG spe­cy­fi­ka­cja nota­cji SBVR3).

Autorzy piszą, że z defi­ni­cja­mi jak wyżej, nie zga­dza się Object Management Group (OMG​.org), stwier­dze­nie to co mnie zaskoczyło.

Jednak z powy­żej przy­to­czo­ny­mi defi­ni­cja­mi nie zga­dza się orga­ni­za­cja Object Management Group (OMG), któ­ra w opra­co­wa­nej przez sie­bie defi­ni­cji pod­kre­śla, że pro­ces biz­ne­so­wy nie zawsze musi być upo­rząd­ko­wa­ny; co wię­cej – nie zawsze jego wyni­kiem jest wytwo­rze­nie jakie­goś dobra (towa­ru, usłu­gi, itp.). 

Troszkę teorii

Powołując się na spe­cy­fi­ka­cję nota­cji BPMN czytamy:

Business Process: A defi­ned set of busi­ness acti­vi­ties that repre­sent the steps requ­ired to achie­ve a busi­ness objec­ti­ve. It inc­lu­des the flow and use of infor­ma­tion and resources.

Process: A sequ­en­ce or flow of Activities in an orga­ni­za­tion with the objec­ti­ve of car­ry­ing out work. In BPMN, a Process is depic­ted as a graph of Flow Elements, which are a set of Activities, Events, Gateways, and Sequence Flow that adhe­re to a fini­te exe­cu­tion semantics.

(ang. Proces biz­ne­so­wy: zde­fi­nio­wa­ny zestaw dzia­łań biz­ne­so­wych, któ­re repre­zen­tu­ją kro­ki wyma­ga­ne do osią­gnię­cia celu biz­ne­so­we­go. Obejmuje prze­pływ i wyko­rzy­sta­nie infor­ma­cji i zasobów.

Proces: sekwen­cja lub prze­pływ dzia­łań w orga­ni­za­cji w two­rzą­ca efekt pra­cy. W BPMN pro­ces jest przed­sta­wio­ny jako graf obra­zu­ją­cy prze­pływ ele­men­tów, któ­re są zbio­rem dzia­łań, zda­rzeń, bra­mek i prze­pły­wu, któ­re są zgod­ne z okre­ślo­ną seman­ty­ką ich realizacji).

Autorzy wycią­ga­ją wniosek:

Nie ma w tym przy­pad­ku ogra­ni­cze­nia, że pro­ces musi coś wytwa­rzać, gdyż ? jak zauwa­żo­no ? we wszyst­kich orga­ni­za­cjach reali­zu­je się sze­reg prac, któ­re nie zawsze przy­no­szą jakie­kol­wiek efek­ty (nie­któ­re zada­nia są reali­zo­wa­ne, mimo, iż nie mają biz­ne­so­we­go uza­sad­nie­nia). Według OMG, pro­ces biz­ne­so­wy to sekwen­cja lub prze­pływ czyn­no­ści w jakiejś orga­ni­za­cji, któ­rych celem jest wyko­na­nie jakiejś pra­cy. Zatem pro­ce­sem jest nie tyl­ko sekwen­cja czyn­no­ści, ale tak­że sam prze­pływ czynności.

Prawdą jest więc, że pro­ces biz­ne­so­wy wg. OMG to pra­ca jako okre­ślo­ny łań­cuch czyn­no­ści, ale nie zro­zu­mia­łe jest dla mnie ostat­nie zda­nie: pro­ce­sem jest nie tyl­ko sekwen­cja czyn­no­ści, ale tak­że sam prze­pływ czyn­no­ści. OMG w spe­cy­fi­ka­cji BPMN (patrz wyżej) jasno defi­niu­je poję­cie pro­ce­su (sekwen­cja ele­men­tów, któ­re są zbio­rem dzia­łań, zda­rzeń, bra­mek i prze­pły­wu, ten ostat­ni jest rów­no­praw­nym ele­men­tem a nie jakimś innym, osob­nym czymś).

Zajrzyjmy do spe­cy­fi­ka­cji nota­cji BPMN: Powyższy dia­gram, to tak zwa­ny dia­gram pro­fi­lu (UML), pro­fil to gra­ficz­na for­ma słow­ni­ka pojęć i ich syn­tak­ty­ki5. Profil (dia­gram pro­fi­lu) to dia­gram klas w nota­cji UML (patrz spe­cy­fi­ka­cja OMG: MOF), zawie­ra­ją­cy związ­ki struk­tu­ral­ne (kom­po­zy­cja) oraz poję­cio­we (aso­cja­cja i gene­ra­li­za­cja). Powyższe czytamy:

  1. ele­men­ty prze­pły­wu w pro­ce­sie to: Obiekt Danych, Węzeł Przepływu, prze­pływ (może zawie­rać waru­nek prze­pły­wu), Odnośnik Do Składu danych, prze­pływ to ele­ment sta­no­wią­cy wyma­ga­ny łącz­nik pomię­dzy węzłami,
  2. typy węzłów prze­pły­wu: Aktywność, Zdarzenie, Bramka, Aktywność choreografii.

Na tle powyż­sze­go, teza auto­rów publikacji:

Nie ma w tym przy­pad­ku ogra­ni­cze­nia, że pro­ces musi coś wytwa­rzać. […] Zatem pro­ce­sem jest nie tyl­ko sekwen­cja czyn­no­ści, ale tak­że sam prze­pływ czynności.

jest nie­praw­dzi­wa. Proces to okre­ślo­na sekwen­cja ale pro­ces biz­ne­so­wy z zasa­dy coś two­rzy, jest to sku­tek (efekt, pro­dukt) wyko­na­nia tej sekwen­cji czyn­no­ści. Stanowi więc zmia­nę okre­ślo­ne­go sta­nu rze­czy (pro­ces, jako coś co zaszło, z zasa­dy zmie­nia śro­do­wi­sko w jakim zacho­dził). Teza, mówią­ca że coś zaszło bez skut­ków jest nie­lo­gicz­na. Definicja pro­ce­su biz­ne­so­we­go w BPMN (doda­tek) zawie­ra w sobie pro­dukt tego procesu.

ele­men­tar­ny pro­ces biz­ne­so­wy to okre­ślo­ne zada­nie wraz z jego pro­duk­tem, mogą one two­rzyć łań­cu­chy pro­ce­sów poka­za­ne jako ich mapy (mode­le)

(wię­cej o nota­cji BPMN w arty­ku­le Notacja BPMN ? Jak czy­tać diagramy)

Proces vs. procedura

W 2014 roku pisałem:

…kil­ka klu­czo­wych defi­ni­cji (słow­nik języ­ka pol­skie­go PWN):

pro­ces: prze­bieg nastę­pu­ją­cych po sobie i powią­za­nych przy­czy­no­wo okre­ślo­nych zmian

Szczegóły:">pro­ce­du­ra: okre­ślo­ne regu­ły postępowania

(https://it-consulting.pl//2014/10/05/sekwencje-a-procesy/)

przy­po­mnij­my defi­ni­cje słow­ni­ko­we7:

pro­ce­du­ra

1. ?okre­ślo­ne regu­ły postę­po­wa­nia w jakiejś spra­wie, zwy­kle o cha­rak­te­rze urzę­do­wym lub prawnym?
2. ?w języ­kach pro­gra­mo­wa­nia: wydzie­lo­ny frag­ment algorytmu?

regu­ła

1. ?zasa­da postę­po­wa­nia usta­lo­na przez kogoś lub przy­ję­ta na mocy zwyczaju?
Zgodnie z zasa­dą logi­ki zdań (i cech popraw­ne­go słow­ni­ka), mówią­cą że zastą­pie­nie poję­cia w zda­niu jego defi­ni­cją nie może zmie­nić sen­su całe­go zda­nia otrzymamy:
Procedura: okre­ślo­ne zasa­dy postę­po­wa­nia, usta­lo­ne przez kogoś, w jakiejś spra­wie, zwy­kle o cha­rak­te­rze urzę­do­wym lub prawnym

Zaglądamy ponow­nie do słownika:

zasa­da

1. ?pra­wo rzą­dzą­ce jaki­miś pro­ce­sa­mi, zja­wi­ska­mi; też: for­mu­ła wyja­śnia­ją­ca to prawo?
Otrzymamy:
Procedura: okre­ślo­ne pra­wa rzą­dzą­ce postę­po­wa­niem, usta­lo­ne przez kogoś, w jakiejś spra­wie, zwy­kle o cha­rak­te­rze urzę­do­wym lub prawnym

Innymi sło­wy pro­ce­du­ra to zbiór praw (zasad) a nie prze­pływ zda­rzeń (ale ich kolej­ność może wyni­kać z tych praw lub może być tym pra­wem). Potocznie poję­cie pro­ce­du­ry fak­tycz­nie jest uży­wa­ne do nazwa­nia dowol­ne­go opi­sa­ne­go (pro­ce­du­rą) spo­so­bu postę­po­wa­nia (tak­że w nor­mach jako­ści ISO) jed­nak poja­wie­nie się poję­cia pro­ces biz­ne­so­wy wyma­ga już dopro­wa­dze­nia tych defi­ni­cji do posta­ci, w któ­rej defi­ni­cje te speł­nia­ją wyma­ga­nia wobec słow­ni­ka: defi­ni­cje muszą się wyklu­czać i jed­no­cze­śnie pokry­wać sobą wszyst­kie desy­gna­ty danej dzie­dzi­ny (patrz trój­kąt seman­tycz­ny nota­cja SBVR ).

Jednym z ele­men­tów pro­ce­su w BPMN jest tak zwa­na aktyw­ność4.

Activity: Work that a com­pa­ny or orga­ni­za­tion per­forms using busi­ness pro­ces­ses. An acti­vi­ty can be ato­mic or non-ato­mic (com­po­und). The types of acti­vi­ties that are a part of a Process Model are: Process, Sub-Process, and Task.

Atomic Activity: An acti­vi­ty not bro­ken down to a finer level of Process Model deta­il. It is a leaf in the tree-struc­tu­re hie­rar­chy of Process acti­vi­ties. Graphically it will appe­ar as a Task
in BPMN.

(ang. Aktywność: pra­ca wyko­ny­wa­na przez fir­mę lub orga­ni­za­cję w toku (przy uży­ciu) pro­ce­sów biz­ne­so­wych. Aktywność może być ato­mo­wa lub nie­ato­mo­wa (zło­żo­na). Rodzaje aktyw­no­ści wcho­dzą­cych w skład Modelu Procesu to: Proces, Podproces i Zadanie.

Aktywność ato­mo­wa: aktyw­ność nie dzie­lo­na na mniej­sze czę­ści jako kolej­ne pozio­my szcze­gó­łów mode­lu pro­ce­su. Jest to liść w hie­rar­chii drze­wia­stej w pro­ce­sach. Graficznie poja­wi się jako zada­nie w BPMN.)

Nie tyl­ko w języ­ku pol­skim, aktyw­no­ścią nazy­wa­my każ­de podej­mo­wa­ne dzia­ła­nie (czy­jeś postę­po­wa­nie). Tak więc w BPMN mamy:

  1. Każda sekwen­cja okre­ślo­nych aktyw­no­ści to pro­ces, taka któ­ra ma okre­ślo­ne kon­se­kwen­cje: two­rzy pro­dukt (w BPMN zda­rze­nie lub obiekt danych), to pro­ces biz­ne­so­wy (nota­cja BPMN nie zawie­ra sym­bo­lu: pro­ces biznesowy!).
  2. Najniżej w hie­rar­chii pro­ce­sów i skła­da­ją­cych się na nie aktyw­no­ści jest zada­nie (ato­mo­wa aktywność).

Aktywności w BPMN opi­su­je poniż­szy profil:

Czytamy dia­gram tak (związ­ki słow­ni­ko­we generalizacji):

  1. Aktywność jest typem węzła, czy­li ele­men­tem prze­pły­wu (patrz poprzed­ni profil),
  2. Aktywność to poję­cie abs­trak­cyj­ne, typa­mi aktyw­no­ści są zada­nia, odwo­ła­nia do zadań oraz pod-procesy.

Warto tu zwró­cić, uwa­gę na to, że pod-pro­ces to tak zwa­ny kon­te­ner. Kontener to zasob­nik na ele­men­ty, for­mal­nie w BPMN takim zasob­ni­kiem jest dia­gram. Innymi sło­wy: jeże­li na dia­gra­mie poja­wi się ele­ment pod-pro­ces, to musi z nim być sko­ja­rzo­ny okre­ślo­ny dia­gram BPMN sta­no­wią­cy jego dekom­po­zy­cję. Innymi sło­wy jeże­li aktyw­ność jest zada­niem (ato­mo­wa aktyw­ność) nie ma ona już dal­szych pod-pro­ce­sów. Aktywność będą­ca pod-pro­ce­sem musi być opi­sa­na z pomo­cą kolej­ne­go dia­gra­mu BPMN. Najniżej w hie­rar­chii aktyw­no­ści BPMN są zada­nia (task). Zgodnie z przy­to­czo­nym defi­ni­cja­mi, zada­nie i jego pro­dukt to «ato­mo­wy pro­ces biz­ne­so­wy» (w lite­ra­tu­rze moż­na tak­że spo­tkać alter­na­tyw­ne poję­cie: pro­ces elementarny).

Co z procedurą?

W BPMN to poję­cie for­mal­nie nie wystę­pu­je, poja­wia się jed­nak w więk­szo­ści narzę­dzi do mode­lo­wa­nia i symu­lo­wa­nia pro­ce­sów. Tam pro­ce­du­ra jest defi­nio­wa­na jako spo­sób postę­po­wa­nia w ramach aktyw­no­ści. Ma to głę­bo­ki sens, bo uzna­nie, że pro­ce­du­ra jest na szczy­cie hie­rar­chii pro­ce­sów pro­wa­dzi­ło by do sytu­acji, w któ­rej wszyst­ko jest pro­ce­du­rą, co prze­czy zasa­dzie wyłącz­no­ści w budo­wa­niu słow­ni­ków (pro­ces nie może być typem lub czę­ścią pro­ce­du­ry). W ramach norm ISO jest wymóg by pro­ce­du­ry two­rzy­ły sobą spój­ne pro­ce­sy biz­ne­so­we. Innymi słowy, 

pro­ce­du­ra to spe­cy­fi­ka­cja reali­za­cji (postę­po­wa­nia w ramach) okre­ślo­nej aktywności

Proces biznesowy jako abstrakcja

Proces biz­ne­so­wy to aktyw­ność jako abs­trak­cja okre­ślo­nej pra­cy oraz powią­za­ne z nią jej wej­ście i wyj­ście . Proces jest ste­ro­wa­ny (ma ogra­ni­cze­nia), wyma­ga zaso­bów. Graficzna postać tej definicji:

Powyższe moż­na przed­sta­wić tak:

(źr.: Jarosław Żeliński, mate­ria­ły kon­fe­ren­cyj­ne) Proces biz­ne­so­wy jako aktyw­no­ści i jej otoczenie.

Z powyż­sze­go wyni­ka, że 

poję­cie pro­ces biz­ne­so­wy” to abs­trak­cja łączą­ca w sobie: aktyw­ność, jej wej­ście i wyj­ście, ogra­ni­cze­nia i regu­ły, oraz nie­zbęd­ne zasoby

(źr. Jarosław Żeliński, mate­ria­ły konferencyjne)

To dla­te­go orga­ni­za­cje mają udo­ku­men­to­wa­ne: wzo­ry doku­men­tów, zarzą­dze­nia, pro­ce­du­ry, zakre­sy obo­wiąz­ków, instruk­cje sta­no­wi­sko­we i instruk­cje użyt­kow­ni­ka wyko­rzy­sty­wa­ne­go wypo­sa­że­nia, nad tym wszyst­kim jest obo­wią­zu­ją­ce pra­wo. Rzadko kie­dy mają jed­nak mapy i mode­le pro­ce­sów poka­zu­ją­ce to w jakiej kolej­no­ści i dla­cze­go to wszyst­ko sie odbywa. 

Z per­spek­ty­wy metod ana­li­zy MBSE: spoj­rze­nia przez pry­zmat tech­no­lo­gii i ludzi wyglą­da to tak: 

Podsumowując: pro­ces jako ele­ment mode­lu to abs­trak­cja pra­cy: aktyw­ność wraz z okre­śle­niem co powsta­je” (pro­dukt). Sposób wyko­na­nia tej pra­cy: meto­da, to narzu­co­na okre­ślo­na pro­ce­du­ra. Procedura może wska­zy­wać na potrze­bę uży­cia okre­ślo­nych narzę­dzi. Całość reali­zo­wa­na jest w okre­ślo­nym śro­do­wi­sku: orga­ni­za­cja i narzę­dzia, w tym opro­gra­mo­wa­nie (np. ERP). 

Kluczowe pojęcia w modelowaniu

W nota­cji BPMN ele­men­tar­ny pro­ces biz­ne­so­wy to nie­po­dziel­na Aktywność (Zadanie) i jej Wejście i Produkt (w BPMN są ele­men­ty typu DataObject). W przy­pad­ku mode­lo­wa­nia wewnętrz­ne­go zacho­wa­nia się sys­te­mu (logi­ka biz­ne­so­wa reali­zo­wa­na przez opro­gra­mo­wa­nie) z uży­ciem nota­cji UML, mamy odpo­wied­nio aktyw­ność oraz jej pro­ce­du­rę jako ciąg zadań (linii kodu). 

Poniżej model poję­cio­wy dla opi­sy­wa­ne­go powy­żej zbio­ru pojęć.

Model poję­cio­wy (dia­gram fak­tów, nota­cja SBVR, opra­co­wa­nie własne)

Model powyż­szy poka­zu­je, że umiesz­cze­nie poję­cia pro­ce­du­ra gdzie­kol­wiek wyżej w hie­rar­chii pojęć BPMN jest prak­tycz­nie nie­moż­li­we przy zacho­wa­niu zasa­dy logi­ki zwa­nej zasa­dą wyłą­czo­ne­go środ­ka: pro­ce­du­ra nie jest pro­ce­sem a pro­ces nie jest pro­ce­du­rą. Tak więc pro­ce­sy biz­ne­so­we, jako łań­cu­chy zadań i ich pro­duk­tów, może­my dekom­po­no­wać aż do pozio­mu pro­ce­sów ato­mo­wych, a pro­ce­du­ra to spo­sób postę­po­wa­nia w reali­zo­wa­niu zada­nia (ato­mo­wej aktyw­no­ści w pro­ce­sie). Umieszczenie poję­cia pro­ce­du­ra w innym miej­scu dopusz­cza­ło by praw­dzi­wość stwier­dze­nia: pro­ce­du­ra skła­da się pro­ce­sów, co nie­ste­ty prze­czy logice.

Na zakoń­cze­nie waż­na uwa­ga na temat mode­li pro­ce­sów z uży­ciem BPMN. Jednym z ele­men­tów prze­pły­wu są tak zwa­na bram­ki (ang. gate­way). Dość czę­stym błę­dem jest przy­po­rząd­ko­wy­wa­nie bram­kom jakiej­kol­wiek pra­cy. Specyfikacja BPMN mówi:

8.4.9 Gateways
Gateways are used to con­trol how the Process flows (how Tokens flow) thro­ugh Sequence Flows as they conver­ge and diver­ge within a Process. If the flow does not need to be con­trol­led, then a Gateway is not needed. The term ?gate­way? implies that the­re is a gating mecha­nism that either allows or disal­lows pas­sa­ge thro­ugh the Gateway; that is, as tokens arri­ve at a Gateway, they can be mer­ged toge­ther on input and/or split apart on out­put as the Gateway mecha­ni­sms are invoked.

Gateways, like Activities, are capa­ble of con­su­ming or gene­ra­ting addi­tio­nal con­trol tokens, effec­ti­ve­ly con­trol­ling the exe­cu­tion seman­tics of a given Process. The main dif­fe­ren­ce is that Gateways do not repre­sent ?work? being done and they are con­si­de­red to have zero effect on the ope­ra­tio­nal measu­res of the Process being exe­cu­ted (cost, time, etc.).

Ostatnie, wytłusz­czo­ne zda­niem mówi:

Główną róż­ni­cą jest to, że bram­ki nie repre­zen­tu­ją pra­cy”, mają więc zero­wy wpływ na mia­ry ope­ra­cyj­ne wyko­ny­wa­ne­go pro­ce­su (koszt, czas itp.).

Innymi sło­wy jaka­kol­wiek pra­ca, np. z ana­li­zą danych i podej­mo­wa­niem decy­zji, jest reali­zo­wa­na w aktyw­no­ściach poprze­dza­ją­cych bram­kę, ta (bram­ka) sta­no­wi sobą wyłącz­nie mecha­nizm prze­pusz­cza­nia lub blo­ko­wa­nia (toke­na), opar­ty na tre­ści (typo­wa bram­ka to bram­ka danych, np. jakiś atry­but toke­nu zawie­ra okre­ślo­ną treść i ta jest wyma­ga­na, to bram­ka prze­pu­ści taki token). Innymi sło­wy bram­ka danych jest mani­fe­sta­cją decy­zji jaka zosta­ła pod­ję­ta w aktyw­no­ści poprze­dza­ją­cej ją.

To ozna­cza, że auto­rzy nie­po­praw­nie uży­wa­ją bra­mek XOR (cyto­wa­na pra­ca, Rys.3.), pisząc, że repre­zen­tu­je ona pra­cę czy­li zada­nie pyta­nia (dia­log) i ocze­ki­wa­nie odpo­wie­dzi. Poprawne podej­ście w BPMN: pew­na okre­ślo­na aktyw­ność zbie­ra dane (ankie­ta) i dane te (pro­dukt aktyw­no­ści ankie­to­wa­nia), w posta­ci ele­men­tu DataObject (lub jako token) tra­fia­ją na bram­kę XOR, a ta np. prze­pusz­cza dalej wyłącz­nie token repre­zen­tu­ją­cy ankie­tę zawie­ra­ją­ca odpo­wiedź TAK na okre­ślo­ne pytanie.

Podsumowanie

[2021 – 06-22] Po wie­lu pyta­niach i dys­ku­sjach, uzu­peł­ni­łem artykuł: 

Generalizując, powyż­sze moż­na zebrać w posta­ci struk­tu­ry poka­za­nej poniżej:

Struktura mode­li pro­ce­sów biznesowych

Na powyż­szym dia­gra­mie pokazano:

  • W cen­tral­nej czę­ści poka­za­no ele­men­tar­ny (ato­mo­wy) pro­ces biz­ne­so­wy (może on być czę­ścią więk­szej całości).
  • Nad nim poka­za­no model (mapę) pro­ce­sów biz­ne­so­wych (może to być nad­rzęd­ny pro­ces) poka­zu­ją­cych jak pro­ce­sy biz­ne­so­we po sobie następują.
  • Pod nim pro­ce­du­ra i róż­ne for­my ich doku­men­to­wa­nia (tekst, tabe­la, sche­mat blo­ko­wy, może zawie­rać regu­ły biz­ne­so­we, macie­rze RACI itp.).
  • Po pra­wej stro­nie struk­tu­ra doku­men­tu (arte­fakt), jest on nośni­kiem danych, jest przy­wo­ły­wa­ny na każ­dym pozio­mie mode­lo­wa­nia (na mode­lach pro­ce­sów BPMN jest to kar­tecz­ka z zagię­tym rogiem, w pro­ce­du­rach powo­łu­je­my się na nazwy doku­men­tów) .

Warto tu zwró­cić uwa­gę na fakt, że mode­lo­wa­nie pro­ce­sów biz­ne­so­wych na pod­sta­wie wywia­dów i ankiet (pozy­ski­wa­nie infor­ma­cji o wyko­ny­wa­nych czyn­no­ściach) wpro­wa­dza ogrom­ną zależ­ność uzy­ska­nych wyni­ków od subiek­tyw­ne­go postrze­ga­nia orga­ni­za­cji przez zatrud­nio­nych w niej (i ankie­to­wa­nych) pra­cow­ni­ków. Powoli, od ponad deka­dy, prze­bi­ja­ją się do świa­do­mo­ści firm ana­li­tycz­nych, meto­dy opar­te na fak­tach, a są nimi tak zwa­ne «arte­fak­ty» czy­li nama­cal­ne śla­dy po wyko­na­nej pra­cy. W warun­kach biz­ne­so­wych są do doku­men­ty ope­ra­cyj­ne i ich treść. 

Każda fir­ma, nie­za­leż­nie od tego, jakie fizycz­ne towa­ry lub usłu­gi wytwa­rza, opie­ra się na doku­men­ta­cji han­dlo­wej. Musi ona zapi­sy­wać szcze­gó­ły tego, co wytwa­rza w posta­ci kon­kret­nych infor­ma­cji. Artefakty biz­ne­so­we są mecha­ni­zmem zapi­su tych infor­ma­cji w jed­nost­kach, któ­re są kon­kret­ne, iden­ty­fi­ko­wal­ne, samo­opi­su­ją­ce się i niepodzielne.” 

W cią­gu ostat­nich kil­ku lat, coraz więk­sze wyma­ga­nia sta­wia­ne są efek­tyw­nym podej­ściom do pro­jek­to­wa­nia, mode­lo­wa­nia i wdra­ża­nia mię­dzy­or­ga­ni­za­cyj­nych pro­ce­sów biz­ne­so­wych. W pro­ce­sie współ­pra­cy ponad gra­ni­ca­mi orga­ni­za­cyj­ny­mi, orga­ni­za­cje nadal pozo­sta­ją auto­no­micz­ne, co ozna­cza, że każ­da z nich może dowol­nie mody­fi­ko­wać swo­je wewnętrz­ne ope­ra­cje, aby osią­gnąć swo­je pry­wat­ne cele, jed­no­cze­śnie speł­nia­jąc wza­jem­ne cele swo­ich part­ne­rów. Ostatnio udo­wod­nio­no, że mode­lo­wa­nie pro­ce­sów skon­cen­tro­wa­ne na arte­fak­tach zapew­nia więk­szą ela­stycz­ność w mode­lo­wa­niu i reali­za­cji pro­ce­sów niż tra­dy­cyj­ne meto­dy mode­lo­wa­nia skon­cen­tro­wa­ne na działaniach.” 

Dlatego mode­lo­wa­nie orga­ni­za­cji bazu­ją­ce na defi­ni­cji pro­ce­su postrze­ga­ne­go jako dzia­ła­nia two­rzą­ce pro­dukt (arte­fakt), wyda­je się być obec­nie naj­lep­szą prak­ty­ką ana­li­zy biznesowej. 

Źródła

Estefan, J. A. (2008). INCOSE MBSE Initiative Survey of Model-Based Systems Engineering (MBSE) Methodologies.
Gerede, C. E., Bhattacharya, K., & Su, J. (2007). Static ana­ly­sis of busi­ness arti­fact-cen­tric ope­ra­tio­nal models. IEEE International Conference on Service-Oriented Computing and Applications (SOCA’07), 133 – 140.
Nigam, A., & Caswell, N. S. (2003). Business arti­facts: An appro­ach to ope­ra­tio­nal spe­ci­fi­ca­tion. IBM Systems Journal, 42(3), 428 – 445. https://​doi​.org/​1​0​.​1​1​4​7​/​s​j​.​4​2​3​.​0​428
OMG​.org. (2014, January). Business Process Model and Notation (BPMN). https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/
Walden, D. D., Roedler, G. J., & Forsberg, K. (2015). INCOSE Systems Engineering Handbook Version 4: Updating the Reference for Practitioners. INCOSE International Symposium, 25(1), 678 – 686. https://​doi​.org/​1​0​.​1​0​0​2​/​j​.​2​334 – 5837.2015.00089.x
Yongchareon, S., liu, C., Yu, J., & Zhao, X. (2015). A view fra­me­work for mode­ling and chan­ge vali­da­tion of arti­fact-cen­tric inter-orga­ni­za­tio­nal busi­ness pro­ces­ses. Information Systems, 47, 51 – 81. https://​doi​.org/​1​0​.​1​0​1​6​/​j​.​i​s​.​2​0​1​4​.​0​7​.​004