Analiza systemowa jako metoda analizy i projektowania

Jeżeli mam godzi­nę na roz­wią­za­nie pro­ble­mu, 55 minut myślę o pro­ble­mie a 5 minut o jego roz­wią­za­niu” (Albert Einstein)

  • Produkt: zobiek­ty­wi­zo­wa­ne i sfor­ma­li­zo­wa­ne opra­co­wa­nie wyko­na­ne otwar­ty­mi, nie chro­nio­ny­mi paten­ta­mi, meto­da­mi pod­da­ją­cy­mi sie audytom.
  • Korzyść: otwar­te stan­dar­dy metod ana­li­zy i doku­men­to­wa­nia jej wyni­ków: brak meto­dycz­ne­go uza­leż­nie­nia od auto­ra opra­co­wa­nia, moż­li­wość prze­ka­za­nia kon­ty­nu­acji pra­cy innej osobie.

Wprowadzenie

Bardzo popu­lar­ną meto­dą pro­wa­dze­nia ana­liz są spo­tka­nia, wywia­dy i warsz­ta­ty. Czy to sku­tecz­ne? Wywiady i warsz­ta­ty z pra­cow­ni­ka­mi bada­nej orga­ni­za­cji dadzą infor­ma­cje o tym, jak oni sobie wyobra­ża­ją to co robią. Wynikiem ana­li­zy są spi­sa­ne wyobra­że­nia, nie raz bar­dzo dale­kie od rze­czy­wi­sto­ści. Na tej pod­sta­wie nie da się zapro­jek­to­wać i wdro­żyć ade­kwat­ne­go do potrzeb orga­ni­za­cji sys­te­mu. Jak ina­czej? Oprzeć się na fak­tach (dowo­dach). To ana­li­za doku­men­tów, a nie roz­mo­wy, da obraz tego jak orga­ni­za­cja dzia­ła na praw­dę. Dlatego w toku ana­li­zy sto­su­ję meto­dy opar­te na fak­tach i mode­le opra­co­wa­ne nauko­wy­mi meto­da­mi .

Porównanie efek­tów zapi­su wywia­dów obser­wa­cji oraz mode­lu zbu­do­wa­ne­go w opar­ciu o logi­kę i fak­ty. Po lewej o góry: sta­ty­sty­ka obser­wa­cji nie­ba czy­li epi­cy­kle – skom­pli­ko­wa­ne mate­ma­tycz­ne figu­ry. Po pra­wej model ukła­du sło­necz­ne­go, któ­ry wyja­śnia obser­wa­cje nie­ba: pro­sty nauko­wy model.

Orientacja na fakty

Dokumenty ope­ra­cyj­ny to pisma klien­tów, ofer­ty, fak­tu­ry, zamó­wie­nia, umo­wy, zarzą­dze­nia? Ich uzu­peł­nie­niem są obo­wią­zu­ją­ce akty praw­ne doty­czą­ce reali­zo­wa­nej ana­li­zy. Razem sta­no­wią sobą tak zwa­ne arte­fak­ty (arti­fact-cen­tric para­digm, ). Zawierają one efek­ty pra­cy ludzi, infor­ma­cje jakich potrze­bu­ją i te jakie two­rzą, wszel­kie istot­ne regu­la­cje. To są fak­ty z życia orga­ni­za­cji. Badanie doku­men­tów, czy­li nośni­ków infor­ma­cji, to naj­sku­tecz­niej­sza obec­nie meto­da ana­li­zy . Praca w opar­ciu o takie doku­men­ty pozwa­la tak­że na prze­pro­wa­dze­nie pro­jek­tu ana­li­tycz­ne­go w 100% zdal­nie.

Przekaż mi doku­men­ty ope­ra­cyj­ne, a ja oddam ci doku­ment opi­su­ją­cy to jak na praw­dę dzia­ła Twoja organizacja

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.” 

https://​ieeexplo​re​.ieee​.org/​a​b​s​t​r​a​c​t​/​d​o​c​u​m​e​n​t​/​5​3​8​6​806

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.” 

https://​www​.scien​ce​di​rect​.com/​s​c​i​e​n​c​e​/​a​r​t​i​c​l​e​/​a​b​s​/​p​i​i​/​S​0​3​0​6​4​3​7​9​1​4​0​0​1​264

Dlatego od wie­lu lat z powo­dze­niem sto­su­ję meto­dy pro­wa­dze­nia audy­tu i ana­li­zy opar­te na dowo­dach (arti­fact-cen­tric para­digm, evi­den­ce-based ana­ly­sis), są to tak­że w inży­nie­rii opro­gra­mo­wa­nia, meto­dy opie­ra­ją­ce się przede wszyst­kim na fak­tach, wywia­dy są jedy­nie ewen­tu­al­nym uzu­peł­nie­niem .

Od wie­lu lat, z powo­dze­niem, ana­li­zy i pro­jek­to­wa­nie reali­zu­ję zdal­nie, dając jako pro­dukt w peł­ni obiek­tyw­ny obraz bada­nej organizacji.

Notacje

Wykorzystuje wyłącz­nie otwar­te stan­dar­dy i nota­cje oraz meto­dy nie wyma­ga­ją­ce opłat licen­cyj­nych. Dzięki cze­mu doku­men­ty, któ­re prze­ka­zu­ję jako pro­duk­ty swo­jej pra­cy, są w 100% moż­li­we do dal­sze­go, samo­dziel­ne­go użytku.

Dość powszech­ne w fir­mach, uży­wa­nie licen­cjo­no­wa­nych lub opa­ten­to­wa­nych metod pra­cy i narzę­dzi powo­du­je, że bene­fi­cjent takiej usłu­gi sta­je się nie­wol­ni­kiem usłu­go­daw­cy. Jeżeli meto­dy pra­cy są dodat­ko­wo utrzy­my­wa­ne w tajem­ni­cy jako tajem­ni­ca usłu­go­daw­cy, nie jest moż­li­we spraw­dze­nie czy usłu­ga zosta­ła wyko­na­na należycie.

W arty­ku­le Metoda nauko­wa w ana­li­zie biz­ne­so­wej w 2011 roku opi­sa­łem czym jest meto­da nauko­wa. Poniżej usys­te­ma­ty­zo­wa­ny opis spo­so­bu pro­wa­dze­nia audy­tów i ana­liz uzu­peł­nio­ny lite­ra­tu­rą źródłową. 

Fundamentem metod jakie sto­su­ję są mode­le: pro­ste i sko­men­to­wa­ne, sfor­ma­li­zo­wa­ne sche­ma­ty blo­ko­we, zro­zu­mia­łe dla adre­sa­ta. W efek­cie ana­li­za i komu­ni­ka­cja pole­ga na: pozy­ski­wa­niu mate­ria­łów o orga­ni­za­cji ana­li­zo­wa­nej, two­rze­niu mode­li opi­su­ją­cych tę orga­ni­za­cję, oraz recen­zo­wa­niu ich przez oso­by z ana­li­zo­wa­nej orga­ni­za­cji. Jest to sku­tecz­na meto­da ana­li­zy i mode­lo­wa­nia dzia­ła­nia orga­ni­za­cji .

[Jeżeli inte­re­su­je Cię mniej tech­nicz­ny a bar­dziej biz­ne­so­wy opis, przejdź teraz na stro­nę: Analiza, wyma­ga­nia i uspraw­nia­nie orga­ni­za­cji.]

Struktura produktu analizy systemowej

Celem ana­liz sys­te­mo­wych nie jest two­rze­nie ogrom­nej i kosz­tow­nej doku­men­ta­cji, jest nim two­rze­nie mode­li i opra­co­wa­nie reko­men­da­cji w posta­ci moż­li­wie zwię­złe­go opracowania.

Analiza orga­ni­za­cji nie powin­na się opie­rać na subiek­tyw­nych rela­cjach jej pra­cow­ni­ków, powin­ny być opar­te w 100% na fak­tach. Relacje mogą być ich uzu­peł­nie­niem . Dlatego sto­su­ję meto­dy ana­li­zy bazu­ją­ce cał­ko­wi­cie na dostar­cza­nych doku­men­tach i auto­ry­zo­wa­nych opi­sach, wywia­dy są jedy­nie uzu­peł­nie­niem tak pozy­ska­nej wie­dzy. Cała ana­li­za opar­ta jest na kolek­cjo­no­wa­niu fak­tów (pra­wo, regu­la­mi­ny wewnętrz­ne, doku­men­ty ope­ra­cyj­ne i ich sza­blo­ny, wyni­ki audy­tów tech­nicz­nych i eks­per­tyz, prze­ka­zy­wa­ne przez zama­wia­ją­ce­go w for­mie pisem­nej). . Tak pro­wa­dzo­na ana­li­za i jej efek­ty, są w mak­sy­mal­nie moż­li­wym stop­niu obiek­tyw­ne i wol­ne od subiek­tyw­nych ocen pra­cow­ni­ków orga­ni­za­cji analizowanej. 

Podstawowe pyta­nia w ana­li­zie sys­te­mo­wej to: ?jak jest i dla­cze­go jest tak jak jest? oraz ?jak powin­no być i co nale­ży uczy­nić, aby było tak jak być powin­no? , mode­lo­wa­nie zaś to narzę­dzie a nie cel . Dlatego ana­li­zy, któ­re reali­zu­ję skła­da­ją się z eta­pu bada­nia i mode­lo­wa­nia orga­ni­za­cji oraz ana­li­zy tych mode­li i opra­co­wa­nia reko­men­da­cji. Jedną z moż­li­wych reko­men­da­cji może być opis reko­men­do­wa­ne­go roz­wią­za­nia np. w posta­ci wyma­gań na opro­gra­mo­wa­nie.

Proces analizy systemowej
Proces ana­li­zy sys­te­mo­wej: ana­li­za sytu­acji, sfor­mu­ło­wa­nie pro­ble­mu, bada­nie, opra­co­wa­nie mode­li, inter­pre­ta­cja i testy mode­li, powtó­rze­nie pro­ce­du­ry lub publi­ka­cja wyni­ków. ,

Model pojęciowy

Pierwszym i klu­czo­wym eta­pem pra­cy jest ana­li­za poję­cio­wa dzie­dzi­ny pro­ble­mu. Tworzenie mode­li poję­cio­wych jest pod­sta­wo­wym narzę­dziem do zagwa­ran­to­wa­nia spój­no­ści tre­ści i wyni­ków każ­dej ana­li­zy i opi­su roz­wią­za­nia. Model poję­cio­wy (prze­strzeń poję­cio­wa, ang. name­spa­ce) to słow­nik klu­czo­wych pojęć bada­nej dzie­dzi­ny oraz wra­żo­na gra­ficz­nie ich struk­tu­ra, obra­zu­ją­ca związ­ki mię­dzy tymi poję­cia­mi: tak­so­no­mia i związ­ki syn­tak­tycz­ne, pozwa­la­ją­ca zagwa­ran­to­wać spój­ność i nie­sprzecz­ność nazew­nic­twa zasto­so­wa­ne­go w toku ana­li­zy i doku­men­to­wa­nia jej wyni­ków. . Proces ana­li­zy poję­cio­wej opi­su­je . poniż­szy dia­gram :

M. van Sinderen and P. Johnson (Eds.): IWEI 2011, LNBIP 76, pp. 146?162, 2011. ? IFIP International Federation for Information Processing 2011
M. van Sinderen and P. Johnson (Eds.): IWEI 2011, LNBIP 76, pp. 146?162, 2011. ? IFIP International Federation for Information Processing 2011

Określenie problemu

Pierwszym eta­pem jest sfor­mu­ło­wa­nie pro­ble­mu badaw­cze­go czy­li okre­śle­nie przy­czy­ny i celu pro­wa­dze­nia ana­li­zy. W sfor­ma­li­zo­wa­nej for­mie, tak­że gra­ficz­nej efek­ty tego eta­pu są doku­men­to­wa­ne jako Model Motywacji Biznesowej . Kluczowymi ele­men­ta­mi tego mode­lu są wizja i misja fir­my oraz stra­te­gia i cele biz­ne­so­we wyra­żo­ne okre­ślo­ną war­to­ścią i jej miarą.

Zbudowanie modelu organizacji

Jakiekolwiek reko­men­da­cje, jeże­li mają być świa­do­me i popar­te dowo­dem ich popraw­no­ści, muszą być poprze­dzo­ne wza­jem­nym zro­zu­mie­niem i udo­ku­men­to­wa­niem mecha­ni­zmu dzia­ła­nia organizacji. 

Do opi­su mecha­ni­zmu dzia­ła­nia orga­ni­za­cji sto­su­je­my sfor­ma­li­zo­wa­ne mode­le wyra­żo­ne jako Architektura Biznesowa (mode­le pro­ce­sów biz­ne­so­wych, regu­ły biz­ne­so­we, mode­le infra­struk­tu­ry IT i mapo­wa­nie pro­ce­sów na opro­gra­mo­wa­nie, struk­tu­ry doku­men­tów w pro­ce­sach). .

Model pro­ce­sów biz­ne­so­wych poka­zu­je, jakie zada­nia są wyko­ny­wa­ne w ramach pro­ce­sów oraz w jakiej kolej­no­ści. Zawiera infor­ma­cje na temat ich wyko­naw­ców, doku­men­tów wyko­rzy­sty­wa­nych i two­rzo­nych w ramach pro­ce­su, ich tre­ści, zaso­bów nie­zbęd­nych do reali­za­cji pro­ce­su (w tym sys­te­mów IT), może zawie­rać opi­sy wskaź­ni­ków KPI (Key Performance Indicators) . (opis tego eta­pu w doku­men­cie Analiza i opra­co­wa­nie archi­tek­tu­ry biz­ne­so­wej).

Wszystkie ele­men­ty mode­lu orga­ni­za­cji powsta­ją i są kon­tro­lo­wa­ne jed­no­cze­śnie, gdyż zbie­ra­ne mate­ria­ły źró­dło­we rzad­ko kie­dy są upo­rząd­ko­wa­ne w cza­sie ich kolek­cjo­no­wa­nia. Kolejne, ite­ra­cyj­nie uzgad­nia­ne, wer­sje pro­wa­dzą do powsta­nia osta­tecz­ne­go Raportu z Analizy zawie­ra­ją­ce­go opis orga­ni­za­cji od ogó­łu do szcze­gó­łu j.w. oraz wyma­ga­nia na reko­men­do­wa­ne rozwiązanie.

Rekomendowane rozwiązanie

Na bazie powsta­łej Architektury Biznesowej, opra­co­wy­wa­ne są reko­men­da­cje do zmian wyra­żo­ne jako pro­jekt roz­wią­za­nia, sta­no­wią wyma­ga­nia dla dostaw­cy roz­wią­za­nia (patrz opis: Wymagania na opro­gra­mo­wa­nie). .

Realizacja

Po zawar­ciu umo­wy z dostaw­cą roz­wią­za­nia, wspie­ram orga­ni­za­cję pro­wa­dząc nad­zór autor­ski, któ­ry pole­ga na bie­żą­cym aktu­ali­zo­wa­niu doku­men­ta­cji opi­su­ją­cej model orga­ni­za­cji i roz­wią­za­nia. W dniu zakoń­cze­nia wdro­że­nia sta­no­wi on aktu­al­ną doku­men­ta­cję uzy­ska­ne­go efektu. 

Dlaczego metoda naukowa?

Celem nauki jest obser­wa­cja fak­tów i zro­zu­mie­nie mecha­ni­zmu ich powsta­wa­nia, celem inży­nie­rii jest two­rze­nie kon­struk­cji wyko­rzy­stu­ją­cych odkry­te mecha­ni­zmy

Opisany powy­żej pro­ces to kla­sycz­na ana­li­za sys­te­mo­wa . Jest to zasto­so­wa­nie zasad nauki do pro­jek­tów biznesowych.

Analiza sys­te­mo­wa to pro­ces nauko­wy, opar­ty na ana­li­zie fak­tów, sto­so­wa­ny w pro­jek­tach o pod­wyż­szo­nym ryzy­ku (a pro­jek­ty infor­ma­tycz­ne do takich nale­żą, ponad 70% tych pro­jek­tów to nie­ste­ty pro­jek­ty nie­uda­ne). Podejście sys­te­mo­we wymu­sza sys­te­ma­tycz­ną i logicz­ną ana­li­zę reali­zo­wa­nych przez przed­się­bior­stwo dzia­łań, sto­su­jąc opar­te na mode­lach podej­ście, pozwa­la zro­zu­mieć stan obec­ny i jego przy­czy­ny. Dzięki temu wyni­ki ana­liz sys­te­mo­wych są obiek­tyw­ne.

Nauka to nie tyl­ko, ency­klo­pe­dycz­ne gro­ma­dze­nie wie­dzy, to meto­dycz­ne bada­nia dzie­dzi­ny, będą­cej przed­mio­tem zainteresowania. 

Nauka nie pole­ga bowiem na gro­ma­dze­niu infor­ma­cji, choć­by cie­ka­wych i poży­tecz­nych, ale na roz­wią­zy­wa­niu zagad­nień .

Bardzo wie­le ksią­żek zali­cza­nych do opra­co­wań nauko­wych, powo­łu­je się w pierw­szych roz­dzia­łach na zna­cze­nia pojęć, gdzie zwra­ca się uwa­gę na to, że nauka to bada­nia dążą­ce do odkry­wa­nia pra­wa zaś inży­nie­ria to two­rze­nie (roz­wią­zań) na bazie wie­dzy o tych pra­wach

W toku pra­cy badaw­czej okre­śla­ne są warian­ty (sce­na­riu­sze) roz­wią­za­nia pro­ble­mu. Aby wska­zać (zare­ko­men­do­wać) wybra­ny wariant, opra­co­wy­wa­ny jest model orga­ni­za­cji (model jest testo­wa­ny na zgod­ność z fak­ta­mi). Na bazie mode­lu pro­wa­dzo­ne są ana­li­zy warian­tów, na bazie wyni­ków tych ana­liz powsta­ją reko­men­da­cje. Mogą nimi być: zale­ce­nia reor­ga­ni­za­cji, zale­ce­nia wdro­że­nia nowych tech­no­lo­gii, wyma­ga­nia na reko­men­do­wa­ne roz­wią­za­nie infor­ma­tycz­ne, itp. Wynik ana­li­zy ma postać opra­co­wa­nia nauko­we­go: stresz­cze­nie, wpro­wa­dze­nie (opis pro­ble­mu), uży­te meto­dy, opis rezul­ta­tów, opis pro­ce­su ich powsta­wa­nia, bibliografia. 

(wię­cej o meto­dzie nauko­wej z arty­ku­le: Metoda nauko­wa w ana­li­zie biz­ne­so­wej)

Orientacja na modele: MBSE

Proces ana­li­zy i mode­lo­wa­nia jest znacz­nie mniej kosz­tow­ny, w porów­na­niu z meto­da­mi opar­ty­mi na prak­ty­ce”, czy­li pro­to­ty­po­wa­niu decy­zji we wła­snej organizacji. 

(źr. )

Projektowanie to pro­ces pro­wa­dzą­cy od sfor­mu­ło­wa­nia pro­ble­mu do powsta­nia wdro­że­nia rozwiązania:

Orientacja na mode­le (Model Driven Engineering, ) pozwa­la zarzą­dzać zło­żo­no­ścią pro­jek­tów, pano­wać nad ich zakre­sem, a kolej­ne fazy, będąc wyni­kiem śla­do­wa­nia czy­li wywo­dze­nia jed­nym mode­li z dru­gich (trans­for­ma­cje) pozwa­la­ją sta­le testo­wać popraw­ność kon­cep­cji całe­go roz­wią­za­nia i pro­jek­tu .

Standardowo sto­su­ję nota­cje BMM, BPMN, SBVRUML . Kluczowy etap to opra­co­wa­nie prze­strze­ni poję­cio­wej (name­spa­ce) czy­li dzie­dzi­no­we­go słow­ni­ka pojęć. Na jego pod­sta­wie two­rzo­ny jest pro­fil poję­cio­wy dla wszyst­kich sche­ma­tów blo­ko­wych. Następnie two­rzo­ne sa mode­le opi­su­ją­ce dzia­ła­nie ana­li­zo­wa­ne­go i pro­jek­to­wa­ne­go sys­te­mu – wyra­żo­ne jako sche­ma­ty blo­ko­we i sce­na­riu­sze testu­ją­ce opra­co­wa­ne modele. 

Istotnym ele­men­tem mode­lo­wa­nych orga­ni­za­cji są doku­men­ty: ich struk­tu­ry i zawar­tość oraz regu­ły kon­tro­li popraw­no­ści (sys­tem infor­ma­cyj­ny orga­ni­za­cji). Obecnie są one z zasa­dy są mode­lo­wa­ne jako struk­tu­ry XML.

Większość orga­ni­za­cji to zło­żo­ne sys­te­my ludzi i infor­ma­cji mają­ce sta­łe inte­rak­cje z oto­cze­niem. Są to więc tak­że bar­dzo zło­żo­ne mode­le (wie­le ele­men­tów i wie­le połą­czeń mię­dzy nimi). Budowanie wiel­kich i szcze­gó­ło­wych sche­ma­tów blo­ko­wych jest nie­efek­tyw­ne komu­ni­ka­cyj­nie: ich zro­zu­mie­nie jest trud­ne a dla więk­szo­ści ludzi po pro­tu nie­moż­li­we. Dlatego doku­men­ta­cje sys­te­mu opra­co­wu­je się jako zestaw wie­lu rela­tyw­nie pro­stych dia­gra­mów, sta­no­wią­cych tak zwa­ne per­spek­ty­wy, czy­li pro­ste opi­sy ukie­run­ko­wa­ne na jeden okre­ślo­ny kontekst

Poniżej pro­sty dia­gram, któ­ry obra­zu­je opi­sa­ne podej­ście jako całość:

Można to pod­su­mo­wać tak: 

Analiza sys­te­mo­wa orga­ni­za­cji to pro­ces pro­wa­dzą­cy do zro­zu­mie­nia tego jak dzia­ła ana­li­zo­wa­na orga­ni­za­cja. Powstały w toku tej ana­li­zy model opi­su­ją­cy tę orga­ni­za­cję, to teo­ria wyja­śnia­ją­ca zacho­wa­nie się orga­ni­za­cji i to jak ona na praw­dę funk­cjo­nu­je. Mając taki model moż­na prze­wi­dy­wać skut­ki pla­no­wa­nych zmian.

Na zakończenie…

(źr. Martin Fowler, Analysis Patterns, 1997)

Źródła

Ackoff, R. L. (1999). Ackoff’s best: his clas­sic wri­tings on mana­ge­ment. Wiley.
Arlow, J., & Neustadt, I. (2004). Enterprise pat­terns and MDA: buil­ding bet­ter softwa­re with arche­ty­pe pat­terns and UML. Addison-Wesley.
Bertalanffy, L. van. (2003). General sys­tem the­ory: foun­da­tions, deve­lop­ment, appli­ca­tions (Rev. ed., 14. paper­back print). Braziller.
Borshchev, A., & Filippov, A. (2004). From sys­tem dyna­mics and discre­te event to prac­ti­cal agent based mode­ling: reasons, tech­ni­qu­es, tools. Proceedings of the 22nd International Conference of the System Dynamics Society, 22.
Bridgeland, D. M., & Zahavi, R. (2009). Business mode­ling: a prac­ti­cal guide to reali­zing busi­ness value. Morgan Kaufmann/Elsevier.
Bronk, A. (2006). Metoda nauko­wa. Nauka, 47 – 64.
Craver, C., & Tabery, J. (2019). Mechanisms in Science. In E. N. Zalta (Ed.), The Stanford Encyclopedia of Philosophy (Summer 2019). Metaphysics Research Lab, Stanford University. https://​pla​to​.stan​ford​.edu/​e​n​t​r​i​e​s​/​s​c​i​e​n​c​e​-​m​e​c​h​a​n​i​s​ms/
Dyba, T., Kitchenham, B. A., & Jorgensen, M. (2005). Evidence-based softwa­re engi­ne­ering for prac­ti­tio­ners. IEEE Software, 22(1), 58 – 65. https://​doi​.org/​1​0​.​1​1​0​9​/​M​S​.​2​0​0​5.6
Forward, A., & Lethbridge, T. C. (2008). A taxo­no­my of softwa­re types to faci­li­ta­te search and evi­den­ce-based softwa­re engi­ne­ering. Proceedings of the 2008 Conference of the Center for Advanced Studies on Collaborative Research Meeting of Minds – CASCON 08, 179. https://​doi​.org/​1​0​.​1​1​4​5​/​1​4​6​3​7​8​8​.​1​4​6​3​807
Fowler, M. (1997). Analysis pat­terns: reu­sa­ble object models. Addison Wesley.
Hamdani, A., & Abdelli, A. (2019). Towards model­ling and ana­ly­zing timed work­flow sys­tems with com­plex syn­chro­ni­za­tions. Journal of King Saud University – Computer and Information Sciences, S131915781930182X. https://​doi​.org/​1​0​.​1​0​1​6​/​j​.​j​k​s​u​c​i​.​2​0​1​9​.​0​8​.​007
Kamiński, S. (1919−1986). (1981). Pojęcie nauki i kla­sy­fi­ka­cja nauk / Stanisław Kamiński. Oddział Zbiorów Cyfrowych. https://​dli​bra​.kul​.pl/​d​l​i​b​r​a​/​p​u​b​l​i​c​a​t​i​o​n​/​3​3​7​9​2​/​e​d​i​t​i​o​n​/​3​1​624
Kitchenham, B. A., Budgen, D., & Brereton, P. (2016). Evidence-based softwa­re engi­ne­ering and sys­te­ma­tic reviews. CRC Press.
Kitchenham, B. A., Dybå, T., & Jørgensen, M. (2004). Evidence-based Software Engineering. Th International Conference on Software Engineering, 9.
Koźmiński, A. K. (1979). Decyzje: ana­ly­za sys­te­mo­wa orga­ni­za­cji. Pánstwowe Wydawn. Naukowe.
Kreuter, T., Scavarda, L. F., Thomé, A. M. T., Hellingrath, B., & Seeling, M. X. (2021). Empirical and the­ore­ti­cal per­spec­ti­ves in sales and ope­ra­tions plan­ning. Review of Managerial Science. https://​doi​.org/​1​0​.​1​0​0​7​/​s​1​1​8​4​6​-​021 – 00455‑y
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/
OMG​.org. (2015, April). Business Motivation Model (BMM). https://​www​.omg​.org/​s​p​e​c​/​B​MM/
OMG​.org. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/
OMG​.org. (2014, June 18). Model Driven Architecture (MDA). https://​www​.omg​.org/​m​da/
Paul, D. (2013). Business ana­ly­sis.
Popper, K. R. (2002). Logika odkry­cia nauko­we­go (U. Niklas, Trans.). Fundacja Aletheia.
Reynolds, C. (2010). Introduction to busi­ness archi­tec­tu­re. Course Technology PTR.
Ross, R. G. (2013). Business rule con­cepts: get­ting to the point of know­led­ge (4th Ed). Business Rule Solutions.
Šenkýř, D., & Kroha, P. (2019). Problem of Incompleteness in Textual Requirements Specification: Proceedings of the 14th International Conference on Software Technologies, 323 – 330. https://​doi​.org/​1​0​.​5​2​2​0​/​0​0​0​7​9​7​8​0​0​3​2​3​0​330
Sienkiewicz, P. (1994). Analiza sys­te­mo­wa: pod­sta­wy i zasto­so­wa­nia. Wydaw. Bellona.
Sobczak, A. (2009). Wstęp do Architektury Korporacyjnej (B. Szafrański, Ed.). Wojskowa Akademia Techniczna.
Thalheim, B. (2019). Models for Communication, Understanding, Search, and Analysis. Data Analytics and Management in Data Intensive Domains: ХХI In-Ternational Conference DAМDID/RCDL’2019 (October 15 – 18, 2019, Kazan, Russia): Conference Proceedings. Edited Bу Alexander Elizarov, Boris Novikov, Sergey Stupnikov. – Kazan: Kazan Federal University, 2019. – 496 р., 19.
Thalheim, B. (2011). The scien­ce of con­cep­tu­al model­ling. International Conference on Database and Expert Systems Applications, 12 – 26.
van Sinderen, M., & Johnson, P. (Eds.). (2011). Enterprise Interoperability: Third International IFIP Working Conference, IWEI 2011, Stockholm, Sweden, March 23 – 24, 2011. Proceedings (Vol. 76). Springer Berlin Heidelberg. https://​doi​.org/​1​0​.​1​0​0​7​/​978 – 3‑642 – 19680‑5
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
Zelinski, J. (2020). Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns. In Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities (pp. 78 – 89). IGI Global. https://​www​.igi​-glo​bal​.com/​b​o​o​k​/​a​p​p​l​i​c​a​t​i​o​n​s​-​a​p​p​r​o​a​c​h​e​s​-​o​b​j​e​c​t​-​o​r​i​e​n​t​e​d​-​s​o​f​t​w​a​r​e​/​2​3​5​699