Wakacje sprzy­ja­ją filo­zo­fii. Tym razem kon­ty­nu­acja opi­sa­nej tu nie­daw­no książ­ki Kotarbińskiego: Kurs logi­ki. Logika bar­dzo poma­ga w ana­li­zie. Prawie trzy lata temu pisa­łem o Trzech zasa­dach logi­ki, jed­na z nich jest klu­czem w ana­li­zie, to zasa­da wyłą­czo­ne­go środ­ka. Brzmi ona:

jeże­li p to nie q

Można ją wyra­zić pro­ściej sło­wa­mi: jeże­li coś jest czymś, to nie jest niczym innym. Czemu jest tak waż­na? Zobaczmy naj­pierw zna­cze­nie sło­wa ana­li­za (źr. sł. j.polskiego PWN, pomi­ną­łem che­micz­ne, trze­cie zna­cze­nie):

ana­li­za 1. ?roz­pa­try­wa­nie jakie­goś pro­ble­mu, zja­wi­ska z róż­nych stron w celu jego zro­zu­mie­nia lub wyja­śnie­nia; też: wyja­śnie­nie lub opis, będą­ce wyni­kiem takie­go roz­pa­try­wa­nia? 2. ?meto­da badaw­cza pole­ga­ją­ca na wyod­ręb­nie­niu z danej cało­ści jej ele­men­tów i bada­niu każ­de­go z osobna?

Analizując orga­ni­za­cje, w celu zro­zu­mie­nia mecha­ni­zmu ich dzia­ła­nia, two­rząc rapor­ty z takich ana­liz, jeste­śmy ana­li­ty­kiem w pierw­szym zna­cze­niu tego sło­wa. Słownik cyto­wa­ny powy­żej mówi (pomi­ną­łem zna­cze­nia z innych dziedzin):

model ?kon­struk­cja, sche­mat lub opis uka­zu­ją­cy dzia­ła­nie, budo­wę, cechy, zależ­no­ści jakie­goś zja­wi­ska lub obiektu?

Innymi sło­wy model to pew­ne uprosz­cze­nie rze­czy­wi­sto­ści. Tworząc model ana­li­zo­wa­nej orga­ni­za­cji, two­rzy­my (doku­men­tu­je­my) opis jej dzia­ła­nia. Wygodną meto­dą opi­sy­wa­nia mecha­ni­zmu dzia­ła­nia np. orga­ni­za­cji, jest jej model w posta­ci sche­ma­tu opi­su­ją­ce­go zależ­no­ści pomię­dzy poszcze­gól­ny­mi jej ele­men­ta­mi. Sformalizowane sche­ma­ty two­rzy­my z pomo­cą nota­cji czy­li sfor­ma­li­zo­wa­nych gra­ficz­nych (sche­ma­ty blo­ko­we) języ­ków opi­su. Notacje takie nie raz tu opi­sy­wa­łem, są to sto­so­wa­ne w ana­li­zie biz­ne­so­wej i pro­jek­to­wa­niu, mię­dzy inny­mi UML, BMM, BPMN, SysML, SBVR.

Do cze­go nam wspo­mnia­na na począt­ku zasa­da wyłą­czo­ne­go środ­ka? Przypomnę, że ana­li­za to (dru­gie powyż­sze zna­cze­nie) meto­da badaw­cza pole­ga­ją­ca na wyod­ręb­nie­niu z danej cało­ści jej ele­men­tów i bada­niu każ­de­go z osob­na.  Do pro­wa­dze­nia ana­li­zy (wyod­ręb­nia­nie ele­men­tów) sto­su­je­my wła­śnie zasa­dę wyłą­czo­ne­go środ­ka: jeże­li jakiś ele­ment orga­ni­za­cji jest czymś (i będzie repre­zen­to­wa­ny na sche­ma­cie z pomo­cą okre­ślo­ne­go ele­men­tu nota­cji), to nie jest niczym innym. Otóż w toku ana­li­zy biz­ne­so­wej opi­su­je­my orga­ni­za­cję z pomo­cą skoń­czo­nej ilo­ści ele­men­tów. W przy­pad­ku opi­su orga­ni­za­cji za pomo­cą pro­ce­sów biz­ne­so­wych (pro­ces biz­ne­so­wy) spro­wa­dza­my całą wie­dzę o niej do pro­stej defi­ni­cji pro­ce­su biz­ne­so­we­go. Jeżeli uzna­my, że pro­ces biz­ne­so­wy to (w uprosz­cze­niu) aktyw­ność two­rzą­ca pro­dukt, to zna­czy, że aktyw­ność nie two­rzą­ca pro­duk­tu z zasa­dy (zasa­da wyłą­czo­ne­go środ­ka) nie jest pro­ce­sem. Takie podej­ście pozwa­la w toku ana­li­zy wyko­nać popraw­ny pro­ce­so­wy model orga­ni­za­cji ale też zapa­no­wać nad szcze­gó­ło­wo­ścią ana­li­zy i jej produktów.

Znowu sł. j. polskiego:

wyma­ga­nie ?waru­nek lub zespół warun­ków, któ­rym ktoś lub coś musi odpowiadać?

Analogicznie więc two­rzy­my obiek­to­we mode­le orga­ni­za­cji (model dzie­dzi­ny jako wyma­ga­na logi­ka dzia­ła­nia), mode­le (spe­cy­fi­ka­cje) wyma­gań biz­ne­so­wych (to cze­go ocze­ku­ją inte­re­sa­riu­sze). Jeżeli wyma­ga­nie to cecha roz­wią­za­nia decy­du­ją­ca o jego przy­dat­no­ści, to zna­czy, że wszyst­ko to (opis), co nie decy­du­je o tej przy­dat­no­ści (nie jest warun­kiem przy­dat­no­ści), nie jest wyma­ga­niem. Podobnie postę­pu­je­my mode­lu­jąc roz­wią­za­nie z pomo­cą tak zwa­nych przy­pad­ków użycia.

Celem tego – opar­te­go na logi­ce – podej­ścia jest usu­wa­nie nad­mia­ro­wo­ści i utrzy­my­wa­nie zara­zem kom­plet­no­ści i nie­sprzecz­no­ści doku­men­tu (w tym modelu).

W toku ana­liz wyma­gań czę­sto sto­so­wa­ne są meto­dy pole­ga­ją­ce na wypy­ty­wa­niu przy­szłych użyt­kow­ni­ków o wyma­ga­nia. Jest to kom­plet­nie nie­przy­dat­ne. Ludzie w potocz­nym języ­ku nie sto­su­ją rygo­ry­stycz­nie logi­ki (:)), mają natu­ral­ną skłon­ność do zaj­mo­wa­nia się nie­istot­ny­mi szcze­gó­ła­mi i do pomi­ja­nia waż­nych a oczy­wi­stych rze­czy, o czym wia­do­mo od daw­na (Kotarbiński, Logika):

nadmiarowosc

Tak więc ana­li­tyk, dla czy­sto­ści ana­li­zy, powi­nien usu­wać wszel­ką nad­mia­ro­wość, wpro­wa­dza­ją­cą zamie­sza­nie, zaciem­nia­ją­cą obraz bada­nej sytuacji.

Często jed­nak widzi­my, że roz­wią­za­nie samo w sobie jest zło­żo­ne, jak tu postą­pić? Pogodzić się z tym, że nie jeste­śmy w sta­nie roz­sąd­nie opi­sać zbyt dużej zło­żo­no­ści, więc nale­ży zmie­nić podej­ście: upro­ścić opis sys­te­mu do pozio­mu wystar­cza­ją­ce­go do nasze­go celu (wybór roz­wią­za­nia) i opi­sać go, ale nie, zna­ny­mi nam (ocze­ki­wa­ny­mi) jego cecha­mi (a mogą być ich tysią­ce), a sku­pić się na cechach istot­nych i chcia­nych oraz niechcianych:

wymaganie jako cechy niechciane

Np. cały zło­żo­ny moduł finan­so­wo-księ­go­wy opro­gra­mo­wa­nia moż­na opi­sać: apli­ka­cja nie może być nie­zgod­na z obo­wią­zu­ją­cym pra­wem” i ewen­tu­al­nie dodać jedy­nie to, jakie ope­ra­cje pla­nu­je­my wyko­ny­wać. Nie ma tu sen­su opi­sy­wa­nie w szcze­gó­łach jak będą wyko­ny­wa­ne. Inna meto­dą wal­ki” ze zło­żo­no­ścią jest podział pro­ble­mu na mniej­sze (dekom­po­zy­cja systemu).

Obecne opro­gra­mo­wa­nie wspo­ma­ga­ją­ce zarzą­dza­nie jest bar­dzo zło­żo­ne. Tak więc nale­ży bez­względ­nie odróż­nić pro­jek­to­wa­nie takie­go opro­gra­mo­wa­nie (tysią­ce cech roz­bu­do­wa­nych sys­te­mów ERP, imple­men­to­wa­nych wie­le lat) od opi­su potrzeb­ne­go roz­wią­za­nia, któ­re pla­nu­je­my kupić na ryn­ku w posta­ci goto­wej aplikacji.

Przeciętny samo­chód to ok. 10 tys. deta­li lub wię­cej. Samych jego cech i ele­men­tów, któ­rych poten­cjal­nie może­my użyć jest tyle, że instruk­cja obsłu­gi samo­cho­du oso­bo­we­go to co naj­mniej książ­ka śred­niej gru­bo­ści. Mimo to doko­nuj­my wybo­ru nowe­go samo­cho­du na pod­sta­wie kil­ku pożą­da­nych cech i kil­ku nie­chcia­nych (np. mię­dzy inny­mi chce­my by miał sil­nik ben­zy­no­wy i nie chce­my by zuży­wał dużo paliwa).

Tak więc ana­li­za, któ­rej wyni­ki mają np. sku­tecz­nie poma­gać w wybo­rze nawet zło­żo­nych apli­ka­cji, to nie wiel­kie i szcze­gó­ło­we opi­sy, bo i tak mało kto (kto­kol­wiek?) je czy­ta. Skuteczne są opi­sy dość ską­pe”, ale wystar­cza­ją­co szcze­gó­ło­we” by z małym ryzy­kiem wybrać speł­nia­ją­cy wyma­ga­nia i przy­dat­ny pro­dukt. Są to opi­sy kom­plet­ne, nie­sprzecz­ne i spój­ne, ale ich stwo­rze­nie wyma­ga peł­ne­go zro­zu­mie­nia mecha­ni­zmu dzia­ła­nia ana­li­zo­wa­nej orga­ni­za­cji. A zro­zu­mie­nie to popraw­ny, prze­te­sto­wa­ny model (mecha­nizm) jej funkcjonowania.

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.