Cechy wyróż­nia­ją­ce nowo­cze­sną teo­rię orga­ni­za­cji to jej poję­cio­wo-ana­li­tycz­na pod­sta­wa, jej opar­cie się na danych uzy­ski­wa­nych z badań empi­rycz­nych, ale przede wszyst­kim jej syn­te­ty­zu­ją­cy, inte­gra­cyj­ny cha­rak­ter. Te cechy wyróż­nia­ją­ce są zawar­te w filo­zo­fii, któ­ra akcep­tu­je zało­że­nie, że jedy­nym spo­so­bem bada­nia orga­ni­za­cji jest trak­to­wa­nie ich jako sys­te­mów (Kostrzewski et al., 1979).

Wprowadzenie

Wbrew ocze­ki­wa­niom, tak zwa­ne zwin­ne meto­dy (agi­le mani­fe­sto, 2001 r.) nie popra­wi­ły jako­ści pro­jek­tów infor­ma­tycz­nych, nie raz zaś spo­wo­do­wa­ły wzrost kosz­tów i wydłu­ża­nie ter­mi­nów, a z uwa­gi na sys­tem roz­li­czeń czas i mate­riał”, nie pozwa­la­ją na pla­no­wa­nie budże­tu pro­jek­tu. Średnie i duże pro­jek­ty IT to nadal w ponad 80% poraż­ki .

Sama obser­wa­cja sie­bie i naśla­do­wa­nie innych nie dają żad­nej popra­wy, wzrost efek­tyw­no­ści daje dopie­ro zro­zu­mie­nie tego co zaobserwowano…

Dlatego spraw­dza­ją się trud­niej­sze, ale znacz­nie sku­tecz­niej­sze, meto­dy zorien­to­wa­ne na mode­lo­wa­nie (ana­li­za sys­te­mo­wa i pro­jek­to­wa­nie) oraz rezy­gna­cja z mono­li­tycz­nej archi­tek­tu­ry sys­te­mów na rzecz archi­tek­tu­ry kom­po­nen­to­wej, wdra­ża­nej meto­da­mi ite­ra­cyj­no-przy­ro­sto­wy­mi . Metody te pozwo­li­ły na pro­jek­to­wa­nie roz­wią­zań infor­ma­tycz­nych i wdra­ża­nie ich w takt zmie­nia­ją­cych sie potrzeb. Pozwalają one tak­że na pla­no­wa­nie kosz­tów i ter­mi­nów już od począt­ku pro­jek­tu . Tak powsta­je tak zwa­na Specyfikacja SWS (Specyfikacja Wymagań Systemowych). 

Model Based Systems Engineering

The Systems Engineering Cube – Potrzeby biz­ne­so­we -> inży­nie­ria sys­te­mów -> pro­jekt sys­te­mu jaki ma dostar­czyć deweloper

Modelowanie pole­ga na abs­tra­ho­wa­niu od szcze­gó­łów i stwo­rze­niu ide­ali­za­cji tak, by sku­pić się na isto­cie danej rze­czy. Dobry model opi­su­je wyłącz­nie mecha­nizm .

MBSE to skrót od Model Based Systems Engineering (ang. inży­nie­ria sys­te­mów opar­ta na mode­lo­wa­niu) . System to nie tyl­ko sys­tem infor­ma­tycz­ny”, to tak­że cała orga­ni­za­cja, a nawet Państwo. 

Celem tego krót­kie­go arty­ku­łu jest poka­za­nie stan­dar­do­wej ścież­ki ana­li­zy sys­te­mo­wej i popra­wy orga­ni­za­cji, czy­li meto­dy pro­wa­dze­nia ana­li­zy sta­nu obec­ne­go i pro­jek­to­wa­nia roz­wią­zań, opar­tej na ana­li­zie fak­tów i mode­lo­wa­niu , któ­rych celem jest opra­co­wa­nie reko­men­da­cji do ulep­sze­nia orga­ni­za­cji . W 2008 roku OMG opu­bli­ko­wa­ło spe­cy­fi­ka­cję Software & Systems Process Engineering Metamodel (SPEM?), opi­su­ją­cą pro­ces prac nad budo­wą sys­te­mów, jed­nak wyglą­da na to, że pra­ce nad tą spe­cy­fi­ka­cją nie są kon­ty­nu­owa­ne. MBSE jako meto­da, wyda­je się być następ­cą tego pomy­słu (patrz: Survey of Model-Based Systems Engineering (MBSE) Methodologies) .

Podstawą pra­cy z mode­la­mi w ana­li­zie sys­te­mo­wej orga­ni­za­cji jest ide­ali­za­cja . Polega ona tym by w toku ana­li­zy i poszu­ki­wa­nia roz­wią­za­nia zapro­jek­to­wać ide­ał (model orga­ni­za­cji w wer­sji ide­al­nej), następ­nie opra­co­wa­niu stu­dium jego wyko­nal­no­ści, uzu­peł­nie­niu ide­ału o pozna­ne ogra­ni­cze­nia i wdro­że­nia tak zapro­jek­to­wa­ne­go sys­te­mu . Studium wyko­nal­no­ści ide­ału to ofer­ty dostaw­ców roz­wią­zań, któ­rych rola jest nie ana­li­za a opra­co­wa­nie kon­cep­cji wdrożenia. . 

Trzy poziomy modelowanie organizacji

Organizacje moż­na opi­sać na trzech klu­czo­wych poziomach:

Enterprise Level – (poziom orga­ni­za­cji) jest to poziom, na któ­rym opi­su­je się i mode­lu­je, stra­te­gie orga­ni­za­cji i jej rolę w oto­cze­niu ryn­ko­wym (ryn­ko­wy łań­cuch war­to­ści). Dotyczy to tak­że insty­tu­cji publicz­nych. Taki opis jako krót­ki doku­ment, jest czę­sto dostęp­ny na stro­nach WWW orga­ni­za­cji w zakład­ce O nas”, w pro­spek­tach emi­syj­nych, sta­tu­tach itp. Model powsta­je w toku for­ma­li­za­cji tego opisu. 

Business Process Level – to środ­ko­wy poziom, na któ­rym two­rzo­ny jest abs­trak­cyj­ny model orga­ni­za­cji w posta­ci tak zwa­ne­go wewnętrz­ne­go łań­cu­cha war­to­ści (pro­ces biz­ne­so­wy). Znakomita więk­szość orga­ni­za­cji nie ma takie­go doku­men­tu lub jest on nie­ak­tu­al­ny. Powodem tego sta­nu rze­czy jest to, że bie­żą­cej pra­cy ope­ra­cyj­nej jest on nie­po­trzeb­ny. Model taki przy­no­si jed­nak ogrom­ne korzy­ści w przy­pad­ku podej­mo­wa­niu decy­zji o zmia­nach. Jest to wte­dy pod­sta­wo­wy mate­riał obni­ża­ją­cy ryzy­ko wszel­kich decy­zji o jakich­kol­wiek zmia­nach orga­ni­za­cyj­nych lub pla­no­wa­nych wdrożeniach.

Implementation Level – to poziom opi­su­ją­cy szcze­gó­ły reali­zo­wa­nej pra­cy i wyko­rzy­sty­wa­nych narzę­dzi. To obszar tre­ści doku­men­tów takich jak: zakre­sy obo­wiąz­ków pra­cow­ni­ków i ich kom­pe­ten­cji, instruk­cje sta­no­wi­sko­we, pro­ce­du­ry, zarzą­dze­nia i regu­la­cje wewnętrz­ne, pod­ręcz­ni­ki uży­wa­nia sprzę­tu i opro­gra­mo­wa­nia oraz wie­le innych doku­men­tów o podob­nych cha­rak­te­rze. Dokumenty te są potrzeb­ne w bie­żą­cej pra­cy, jed­nak szyb­kie i sku­tecz­nie podej­mo­wa­nie decy­zji na ich pod­sta­wie ich tre­ści jest prak­tycz­nie nie­moż­li­we z uwa­gi na ich ilość i szczegółowość. 

Analiza biz­ne­so­wa pole­ga na audy­cie doku­men­tów ist­nie­ją­cych, czy­li tych z pozio­mu pierw­sze­go i trze­cie­go na powyż­szym dia­gra­mie, i opra­co­wa­niu na ich pod­sta­wie Modelu Procesów Biznesowych (środ­ko­wa war­stwa). Model ten to mecha­nizm funk­cjo­no­wa­nia orga­ni­za­cji, jej abs­trak­cyj­ny obraz, pozwa­la­ją­cy zapla­no­wać przy­szłe wdro­że­nie i prze­wi­dzieć jego efekty.

W toku ana­li­zy ma czę­sto miej­sce stan­da­ry­za­cja opi­su dzia­ła­nia i stra­te­gii. Jej celem jest for­ma­li­za­cja opi­su orga­ni­za­cji, bez cze­go nie jest moż­li­we doko­na­nie jakich­kol­wiek porów­nań np. z kon­ku­ren­cją, wyzna­cze­nie celów biz­ne­so­wych i wska­za­nie w orga­ni­za­cji miejsc mają­cych wpływ na te cele. 

Enterprise Level – Model biznesowy organizacji 

Strategia orga­ni­za­cji i jej rola w oto­cze­niu ryn­ko­wym są klu­czo­we dla zro­zu­mie­nia osią­ga­nych przez orga­ni­za­cję efek­tów. Mimo tego, że więk­szość orga­ni­za­cji dys­po­nu­je takim opi­sem, są one wyko­na­ne nie­for­mal­ny­mi meto­da­mi, tak róż­ny­mi, że jakie­kol­wiek porów­na­nie dwóch orga­ni­za­cji lub tej samej na prze­strze­ni lat jest prak­tycz­nie nie­moż­li­we. Dlatego opra­co­wa­no stan­dard zwa­ny Model Motywacji Biznesowej .

Standard ten sta­no­wi sobą pewien okre­ślo­ny sys­tem klu­czo­wych pojęć i związ­ków mię­dzy nimi. Jego celem jest stan­da­ry­za­cja pojęć takich jak: misja i wizja, stra­te­gia i tak­ty­ka, wewnętrz­ne i zewnętrz­ne czyn­ni­ki wpły­wu, cele i mier­ni­ki osią­ga­nia celu. 

Business Process Level – Model procesów biznesowych organizacji

Jest to model pozio­mu Business Process Level. To zna­czy, że nie ma tu miej­sca na szcze­gó­ły opi­sa­ne w doku­men­tach na pozio­mie Implementation Level. Model pro­ce­sów biz­ne­so­wych ma (powi­nien mieć) jedy­nie odno­śni­ki do szcze­gó­łów trze­ciej war­stwy, w szcze­gól­no­ści do pro­ce­dur, repre­zen­to­wa­nych na tym pozio­mie w posta­ci (abs­trak­cyj­nych) nazwa­nych aktywności.

Jednym z naj­bar­dziej zna­nych wzor­ców opi­su tego pozio­mu jest tak zwa­ny Wewnętrzny Łańcuch Wartości M. Portera, jest on nadal pod­sta­wo­wą wie­dzą każ­de­go absol­wen­ta stu­diów MBA. Model ten zakła­da podział pro­ce­sów na wspie­ra­ją­ce (admi­ni­stra­cja) i ope­ra­cyj­ne. Konkurencyjność i spraw­ność ope­ra­cyj­na ma dwa obsza­ry: w obsza­rze admi­ni­stra­cji, ści­śle regu­lo­wa­nym pra­wem, w zasa­dzie kon­ku­ru­je­my kosz­ta­mi, ale w obsza­rze ope­ra­cyj­nym, dają­cym znacz­nie więk­szą swo­bo­dę jego kształ­to­wa­nia, kon­ku­ren­cyj­ność to efekt spraw­no­ści orga­ni­za­cji, archi­tek­tu­ry pro­ce­sów biz­ne­so­wych i informacji. 

Łańcuch wartości M.E.Porter
Wewnętrzny łań­cuch wartości 

Z ww. powo­du w toku ana­li­zy i mode­lo­wa­nia sku­pia­my sie na obsza­rze ope­ra­cyj­nym, gdyż obszar wspar­cia admi­ni­stra­cyj­ne­go, z powo­du ści­słej zależ­no­ści od pra­wa, moż­na wes­przeć stan­dar­do­wym opro­gra­mo­wa­niem, łatwo dostęp­nym na ryn­ku. Ewentualne dedy­ko­wa­ne modu­ły są pro­jek­to­wa­ne wła­śnie dla obsza­ru ope­ra­cyj­ne­go, bo to tu wystę­pu­ją róż­ni­ce mię­dzy orga­ni­za­cja­mi i tu powsta­je prze­wa­ga kon­ku­ren­cyj­na (jeże­li doty­czy to orga­ni­za­cji kon­ku­ru­ją­cej na ryn­ku). Kluczem na tym eta­pie jest wska­za­nie miejsc do uspraw­nie­nia i opra­co­wa­nie roz­wią­za­nia. Próby kom­plek­so­we­go wdra­ża­na jed­ne­go sys­te­mu do wszyst­kie­go” naj­czę­ściej koń­czą się nie­ste­ty źle (kom­plek­so­we wdro­że­nia mono­li­tów ERPII mają bar­dzo złą reno­mę). Model Portera odno­si sie jed­na­ko­wym stop­niu do firm ryn­ko­wych jak i do insty­tu­cji publicznych. 

Więcej w arty­ku­le Analiza orga­ni­za­cji i opra­co­wa­nie Mapy Procesów.

Implementation Level – wdrożenie

Ten poziom i jego doku­men­ta­cja, to tak na praw­dę efekt pra­cy ope­ra­cyj­nej i pro­dukt wdro­że­nia norm jako­ści i pro­ce­dur, stra­te­gii zatrud­nie­nia, sys­te­mu infor­ma­tycz­ne­go itp. (patrz Operational Resources w poprzed­nim pod­roz­dzia­le). Tę doku­men­ta­cję two­rzą dostaw­cy roz­wią­zań oraz wewnętrz­ne służ­by admi­ni­stra­cji. Jako, że ona w róż­nych for­mach ist­nie­je w każ­dej fir­mie, sta­no­wi bazo­wy mate­riał źró­dło­wy w ana­li­zach sta­nu obec­ne­go. To dla­te­go ana­li­zę orga­ni­za­cji moż­na prze­pro­wa­dzić prak­tycz­nie w 100% bez kło­po­tli­wych i kosz­tow­nych spo­tkań warsz­ta­to­wych z pra­cow­ni­ka­mi ana­li­zo­wa­ne­go podmiotu. 

Rozwiązania informatyczne i wymagania

Niestety same spi­sa­ne funk­cjo­nal­no­ści pro­gra­mu czy­li spe­cy­fi­ka­cja (lista) wyma­gań funk­cjo­nal­nych to wyłącz­nie idea jego powsta­nia (wyrok SA w Poznaniu z dnia 4 stycz­nia 1995 r. I ACr 422/94). Precyzję opi­su, dają­cą ochro­nę w posta­ci peł­ne­go pra­wa do powsta­łe­go pro­duk­tu, uzy­sku­je się dopie­ro opra­co­wu­jąc pro­jekt jego kon­struk­cji, struk­tur danych i mecha­ni­zmu dzia­ła­nia, sto­su­jąc wzo­ry mate­ma­tycz­ne, algo­ryt­my, uni­kal­ne struk­tu­ry i sche­ma­ty blo­ko­we.

Obecne cza­sy to wszech­obec­na cyfry­za­cja. Dlatego zna­ko­mi­ta więk­szość roz­wią­zań wspie­ra­ją­cych dzia­ła­nia orga­ni­za­cji to sys­te­my infor­ma­cyj­ne wspie­ra­ją­ce pro­ce­sy biznesowe. 

Powyżej poka­za­no (zna­ny od lat 90-tych ubie­głe­go wie­ku) model archi­tek­tu­ry sys­te­mów infor­ma­cyj­nych zorien­to­wa­nej na usłu­gi apli­ka­cyj­ne. Pokazuje on związ­ki pomię­dzy pro­ce­sa­mi biz­ne­so­wy­mi a sys­te­ma­mi infor­ma­cyj­ny­mi, któ­rych doce­lo­wo w każ­dej orga­ni­za­cji jest wię­cej niż jeden. 

Systemy infor­ma­cyj­ne tak­że mode­lu­je­my na kil­ku poziomach: 

  1. Business Services – jako nazwa­ne usłu­gi biz­ne­so­we wyma­ga­ją­ce okre­ślo­nych usług apli­ka­cyj­nych, wspie­ra­ją­cych okre­ślo­ne aktyw­no­ści w pro­ce­sach, usłu­gi apli­ka­cyj­ne mode­lu­je­my jako przy­pad­ki uży­cia apli­ka­cji (są to wyma­ga­nia na rozwiązanie),
  2. Components – jako nazwa­ne i wyspe­cy­fi­ko­wa­ne kom­po­nen­ty apli­ka­cyj­ne wraz z ich inte­gra­cją (jest to opis rozwiązania),
  3. Operational Resources – jako model opi­su­ją­cy fak­tycz­ne ich wdro­że­nie i roz­lo­ko­wa­nie (jest to doku­men­ta­cja wdro­żo­ne­go systemu). 

Kluczowymi sto­so­wa­ny­mi stan­dar­da­mi nota­cyj­ny­mi są tu BPMN, UML, SBVR . Więcej w arty­ku­le Analiza i opra­co­wa­nie wyma­gań na opro­gra­mo­wa­nie.

Opracowanie spe­cy­fi­ka­cji wyma­gań (mode­li) nie powin­no nigdy w obec­nych cza­sach trwać dłu­żej niż kwar­tał, co ozna­cza, że im więk­szy pro­jekt tym bar­dziej spe­cy­fi­ka­cja wyma­gań jest poli­ty­ką (archi­tek­tu­rą) niż deta­licz­nym opi­sem. Detale są spe­cy­fi­ko­wa­ne już w toku wdro­że­nia w toku nad­zo­ru autor­skie­go, zgo­dzie z poli­ty­ką budo­wy i wdra­ża­nia sys­te­mu (archi­tek­tu­rą). Wycena reali­za­cji nie powin­na spra­wić kło­po­tu, żad­nej doświad­czo­nej, zna­ją­cej wzor­ce archi­tek­to­nicz­ne, fir­mie ofru­ją­cej oprogramowanie. 

Praca z dostawcami rozwiązań

Praktycznie zawsze pada pyta­nie: a co jeże­li dostaw­ca też robi ana­li­zę przed­wdro­że­nio­wą? Otóż tu już jej nie robi bo ją dosta­je. Z uwa­gi na ryzy­ko pro­jek­tu i poten­cjal­ny kon­flikt inte­re­su, Dostawca z zasa­dy nie powi­nien być auto­rem wyma­gań (pro­jek­tu rozwiązania). 

Dostawca musi opra­co­wać pro­po­no­wa­ną przez sie­bie Koncepcję Wdrożenia ofe­ro­wa­ne­go pro­duk­tu, w odpo­wie­dzi na wyma­ga­nia wyra­żo­ne w posta­ci mode­li pro­ce­sów biz­ne­so­wych, struk­tur doku­men­tów i reguł biz­ne­so­wych (Model Biznesowy Organizacji). Z uwa­gi na to, że pro­jek­ty takie zawsze reali­zo­wa­ne są meto­dą ite­ra­cy­no-przy­ro­sto­wą, w toku pro­jek­tu ma miej­sce sta­ła współ­pra­ca: Dostawca roz­wią­za­nia żąda kolej­nych deta­licz­nych infor­ma­cji o tym jak dzia­ła fir­ma Zamawiającego, Zamawiający, z moją pomo­cą (nad­zór autor­ski), odpo­wia­da odsy­ła­jąc sta­le uzu­peł­nia­ny Model Biznesowy. Dostawca doku­men­tu­je kolej­ne eta­py pro­wa­dzo­ne­go wdro­że­nia (aktu­ali­zu­je Koncepcję Wdrożenia, któ­ra sta­je się doku­men­ta­cją tego wdro­że­nia) a ja je (te doku­men­ty) wery­fi­ku­ję, i tak aż do zakoń­cze­nia wdrożenia. 

Na koniec wdro­że­nia Zamawiający dys­po­nu­je dwo­ma aktu­al­ny­mi doku­men­ta­mi: Model Biznesowy (środ­ko­wa war­stwa opi­su orga­ni­za­cji) i Dokumentacja Wdrożenia (opi­sa­ny wyżej Poziom Implementacji).

Podsumowanie

Każdy pro­jekt zwią­za­ny z reor­ga­ni­za­cją i/lub wdra­ża­niem nowe­go opro­gra­mo­wa­nia (zmian, roz­bu­do­wy) moż­na więc prze­pro­wa­dzić meto­dą ana­li­zy orga­ni­za­cji i jej mode­lo­wa­nia na z góry usta­lo­nym pozio­mie szcze­gó­ło­wo­ści. Modele te są ści­śle zin­te­gro­wa­ne z sobą, a całość ma cha­rak­ter opi­su od ogó­łu do szczegółu”. 

Podejście to gwa­ran­tu­je spój­ność, kom­plet­no­ści i nie­sprzecz­ność opi­su na każ­dym eta­pie pro­jek­tu. Dzięki temu mini­ma­li­zu­je­my ryzy­ko nie­uda­ne­go wdro­że­nia a całość trwa krót­ko (żaden etap ana­li­zy nie powi­nien trwać dłu­żej niż kwar­tał!). Prosty ale obra­zo­wy przy­kład opi­sa­łem TUTAJ.

Całość lite­ra­tu­ra przed­mio­tu opi­su­je od wie­lu lat, meto­dy te są sta­le dosko­na­lo­ne. Poniżej pro­ces two­rze­nia opro­gra­mo­wa­nia jako pro­jek­to­wa­nie systemu: 

Model sys­te­mu jest celem ana­li­zy opar­tej o przy­pad­ki uży­cia (wywo­dzo­ne z pro­ce­sów biz­ne­so­wych) i ich sce­na­riu­sze, na ich pod­sta­wie powsta­je model sys­te­mu, kolej­ny krok to imple­men­ta­cja (code) jed­nak nadal dłu­go jesz­cze będzie to pra­ca dla deve­lo­pe­rów .

Przypadki uży­cia (use case) to wynik opi­sa­nej na począt­ku ana­li­zy biz­ne­so­wej (orga­ni­za­cja to tak­że sys­tem) i wyod­ręb­nie­nia celów biz­ne­so­wych. Mamy rok 2021 i ogrom­ny wybór dostęp­ne­go, goto­we­go opro­gra­mo­wa­nia wyma­ga­ją­ce­go jedy­nie wła­ści­we­go dobo­ru i inte­gra­cji. Tak opi­sa­ny wyżej sys­tem to struk­tu­ra i zacho­wa­nie się dobra­nych kom­po­nen­tów, nie koniecz­nie jest to pisa­nie dedy­ko­wa­ne­go opro­gra­mo­wa­nia od zera”, bo to ma miej­sce coraz rza­dziej i doty­czy ewen­tu­al­nie 10 – 15% dedy­ko­wa­nych potrzeb nie­któ­rych firm. 

Obecne na ryn­ku sys­te­my wspie­ra­ją­ce ana­li­zy i pro­jek­to­wa­nie (CASE: Computer Aided System Engineering) oraz wzor­ce archi­tek­to­nicz­ne i narzę­dzia infor­ma­tycz­ne, pozwa­la­ją pro­wa­dzić ana­li­zy i mode­lo­wa­nie eta­pa­mi trwa­ją­cy­mi poje­dyn­cze tygo­dnie a nie lata. Iteracyjno-przy­ro­stwe meto­dy dostar­cza­nia opro­gra­mo­wa­nia pozwa­la­ją wdra­żać nowo­cze­sne roz­wią­za­nia w okre­sach kwar­tal­nych a nie lat. 

Więc kil­ka słów na zakończenia:

  • jeże­li pra­cu­je nad zro­zu­mie­niem logi­ki dzia­ła­nia cze­goś, nie ma zna­cze­nia język programowania
  • jeże­li chce udo­ku­men­to­wać to co odkry­łem, nie ma zna­cze­nia język programowania
  • jeże­li chce zapro­jek­to­wać archi­tek­tu­rę przy­szłej apli­ka­cji, nie ma zna­cze­nia język programowania
  • jeże­li chcę opi­sać wyma­ga­ne algo­ryt­my, nie ma zna­cze­nia język programowania
  • jeże­li chce te algo­ryt­my roz­ło­żyć na poszcze­gól­ne kom­po­nen­ty, nie ma zna­cze­nia język programowania
  • jeże­li chce spraw­dzić jak to zadzia­ła i czy zadzia­ła, nie ma zna­cze­nia język programowania

Język pro­gra­mo­wa­nia ma zna­cze­nie dla dewe­lo­pe­ra, bo to on się nim posłu­gu­je. Implementacja jest naj­kosz­tow­niej­szym eta­pem two­rze­nia sys­te­mu, więc nale­ży mini­ma­li­zo­wać zaan­ga­żo­wa­nie dewe­lo­pe­ra na rzecz ana­li­zy i projektowania.

Źródła

Koźmiński, A. K. (1979). Decyzje: ana­li­za sys­te­mo­wa orga­ni­za­cji. Pánstwowe Wydawn. Naukowe.
Object Management Group. (2015). Business Motivation Model (BMM). https://​www​.omg​.org/​s​p​e​c​/​B​MM/
Object Management Group. (2014, January). Business Process Model and Notation (BPMN). OMG​.Org. https://​www​.omg​.org/​s​p​e​c​/​B​P​MN/
Object Management Group. (2017, December). Unified Modeling Language (UML) [OMG​.org]. UML. https://​www​.omg​.org/​s​p​e​c​/​U​ML/
Sienkiewicz, P. (1994). Analiza sys­te­mo­wa: pod­sta­wy i zasto­so­wa­nia. Wydaw. Bellona.
Estefan, J. A. (2007). Survey of Model-Based Systems Engineering (MBSE) Methodologies. 47.
Harel, D. (2000). From play-in sce­na­rios to code: An achie­va­ble dre­am. International Conference on Fundamental Approaches to Software Engineering, 22 – 34.
Kitchenham, B. A., Dybå, T., & Jørgensen, M. (2004). Evidence-based Software Engineering. Th International Conference on Software Engineering, 9.
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/
D’Souza, D. (1998). Objects, Components, and Frameworks with UML The CatalysisTM Approach. 116.
Suri, K., Cuccuru, A., Cadavid, J., Gerard, S., Gaaloul, W., & Tata, S. (2017). Model-based Development of Modular Complex Systems for Accomplishing System Integration for Industry 4.0: Proceedings of the 5th International Conference on Model-Driven Engineering and Software Development, 487 – 495. https://​doi​.org/​1​0​.​5​2​2​0​/​0​0​0​6​2​1​0​5​0​4​8​7​0​495
Jones, S. (2006). Enterprise SOA adop­tion stra­te­gies: using SOA to deli­ver IT to the busi­ness. C4Media.
Ackoff, R. L., Magidson, J., Addison, H. J., & Ehrlich, A. (2007). Projektowanie ide­ału: kształ­to­wa­nie przy­szło­ści orga­ni­za­cji. Wyższa Szkoła Przedsiębiorczości i Zarządzania im. Leona Koźmińskiego : Wydawnictwa Akademickie i Profesjonalne.
Liu, C. (2004). Laws and Models in a Theory of Idealization. Synthese, 138(3), 363 – 385.
Jenney, J., Gangl, M., Kwolek, R., Melton, D., Ridenour, N., & Coe, M. (2010). Modern methods of sys­tems engi­ne­ering: with an intro­duc­tion to pat­tern and model based methods. Joe Jenney.
Porter, M. E. (1998). Competitive advan­ta­ge: cre­ating and susta­ining supe­rior per­for­man­ce: with a new intro­duc­tion (1st Free Press ed). Free Press.