Temat: Modelowanie czy rysowanie

Stosunkowo niedawno zbiegło mi się kilka projektów, w których ... no właśnie. Ciekaw jestem czy macie podobne odzcucia: model czy jednak tylko rysunek... mój esej na ten temat tu:

http://it-consulting.pl/php/html/modules.php?name=News...

Temat: Modelowanie czy rysowanie

Panie Jarku, niełatwy temat Pan podjął i wiele wątków. Rozumiem, że jednak jak najbardziej twardo osadzony w rzeczywistości.

Co do pytania. Cóż, zaliczył bym je do kategori tych, które udowadniają prawdziwość tezy, że wystawiana ocena zależy od zdolności sprawczych oceniającego. Sukces / porażka "modelarza" uzależniona jest tym samym od wiedzy zlecającego. Postawa Golema, który najpierw zbadał iloraz inteligencji swoich przełozonych a następnie odmówił jakiejkolwiek współpracy z nimi, w tym kontekście jest dla mnie całkowicie zrozumiała.

No i współczense realia: klient jest klient. No i może tu jest odpowiedź na pytanie dlaczego "poważna" firma podsyła do klienta "niepoważnego" konsultanta. W takich firmach też pracują odpowiednio wysoko "umocowani" i trzeba ich jakoś zagospodarować. O zaspokajaniu ambicji pełnienia misji i właściwym uzasadnieniu fakturowanej kwoty nie zapominając.

Rysunek to syntaktyka. Model to semantyka. Całość spaja pragmatyka. Aby to prawidłowo zaopiniować potrzebna jest zrównoważona ocena całości. Semiotyka zaś nie dla każdego jest zrozumiała i dłuuugooo nie będzie, jeżeli będzie.

Temat: Modelowanie czy rysowanie

Nawiązując do mojego przedmówcy, Pana Marka, który poruszył tematykę nauki o języku ;-)...

Ja bym to ujął jeszcze inaczej, lepiej mam nadzieję porządkując podstawowe pojęcia, które wprowadzono. To co troszkę zostało wymieszane to pojęcie modelu i języka modelowania. To, co napisał Pan Marek odnosi się do języka modelowania, w ramach którego możemy rzeczywiście wyróżnić syntaktykę, semantykę i pragmatykę. Jeżeli odwołamy się do modeli konceptualnych, tworzonych z wykorzystaniem odpowiedniej, ściśle określonej graficznej konwencji notacyjnej to możemy poszczególne elementy zdefiniować korzystając np. z klasycznej analizy strukturalnej (metodyki Yourdona) i diagramów przepływu danych.

Syntaktyka - okrąg z nazwą w środku - symbol procesu
Semantyka - proces symbolizuje przetwarzanie - pobiera coś na wejściu, przetwarza wg wewnętrznej logiki i generuje wyjście, które może być zapisane np. w magazynie danych a następnie wykorzystane przez inny proces.
Pragmatyka - wykorzystanie języka, czyli w naszym przypadku symboli procesu, przepływu, terminatora i magazynu danych.

Model jest artefaktem, który został zbudowany z wykorzystaniem języka modelowania, dzieki czemu niesie określoną treść, która będzie interpretowana stosownie do zdefiniowanej semantyki języka modelowania. Dobrze jest gdy interpretacja modelu jest jednoznaczna. Oznacza to, że każdy członek zespołu interpretuje model w ten sam sposób. Jednoznaczna interpretacja jest możliwa tylko w sytuacji, gdy mamy do czynienia z semantyką formalną języka, która póki co nie została zdefiniowana dla takiego jezyka jak UML.

Oprócz pojęcia modelu możnaby jeszcze dodać pojęcia metody modelowania i metodyki. Przez metodę rozumiemy język modelowania oraz procedurę tworzenia modelu z wykorzystaniem języka wraz z regułami gramatyki mówiącymi jakie połączenia elementów języka nie są dopuszczalne. Metodyka to z kolei w dużym uproszczeniu zbiór metod modelowania wraz z procedurą mówiącą jak korzystać z określonych metod w kontekście cyklu życia systemu.

Pozdrawiam!

PS. Mam nadzieję, że wspólnie uda nam się coraz lepiej uporządkować ontologię naszej dziedziny i wszyscy z określonymi pojęciami będziemy łączyć takie samo znaczenie...

Temat: Modelowanie czy rysowanie

No to widzę, że fajna dyskusja nam się zapowiada. :D

Zgadzam się z uwagą Pana Jacka o pewnym skrócie, którego dokonałem, bo temat szeroki i niełatwy. Jeżeli zaczynamy rozmawiać o modelu i języku modelowania, to nie sposób pominąć, że jeżeli wchodzimy w obszar dyskusji o porządkowaniu, to najpierw wypada odpowiedzieć sobie na pytanie co jest wiedzą a co metawiedzą. Brak świadomego, wyraźnego rozrózniania tego przez wielu publicznie wypowiadających się jest czymś co mnie osobiście przeszkadza.

Prawdę powiedziawszy nie umiem w tej chwili zaproponować czegoś, co z całym przekonaniem propagowałbym jako to, co właściwie oddziela nam metawiedzę od wiedzy. To co nasuwa mi się jako pierwsze to algorytmika, i tu szukałbym punktu wyjścia. Omawianie wybranego języka zaproponowałbym zaś na koniec dyskusji.

To co trochę jest dla mnie nie zrozumiałe to to dlaczego zaproponował Pan Panie Jacku patrzenie na model jako na coś co jest skutkiem ubocznym zastosowania wybranego algorytmu. Artefakt to przede wszystkim niedoskonałość powstająca jako efekt zastosowanej przez nas metody rozwiązania zadania. W tym kontekście artefakt dla mnie jest konsekwencją stosowania takiego a nie innego modelu. Np: założenie klient ma zawsze rację i artefakt - nasze działania kiedy obiektywnie jej nie ma, ale ponieważ to on nam płaci, to tak postępujemy aby miał.

Porządkując może zaproponuję takie spojrzenie, które jest nawet tytułem serii książek sprzed lat: problem, metoda, zadanie, rozwiązanie. Innymi słowy zabierając się za coś wybieramy metodę. Metodę eksplorujemy zgodnie z określoną metodyką i sposobem postępowania (też nazywanym metodą tu: modelowania), np: poruszanie się w przestrzeni rozwiązywania zadania z góry lub od dołu (ang. forward / backward). Powstaje nam model, który aby zapisać musimy użyć jakiegoś języka. Język ze swoją gramatyką pozwala nam przekazać jakieś treści semantyczne.

Pytaniem otwartym pozostaje pytanie na ile konkretyzując wizję udaje się nam wiernie oddać to co sobie wymyśliliśmy. Tu jest miejsce na dyskusję o syntaktyce. Tyle tylko, że w kontekście cyklu życia sprawa nam się bardziej komplikuje. :D

Temat: Modelowanie czy rysowanie

Marek K.:
No to widzę, że fajna dyskusja nam się zapowiada. :D

Zgadzam się z uwagą Pana Jacka o pewnym skrócie, którego dokonałem, bo temat szeroki i niełatwy. Jeżeli zaczynamy rozmawiać o modelu i języku modelowania, to nie sposób pominąć, że jeżeli wchodzimy w obszar dyskusji o porządkowaniu, to najpierw wypada odpowiedzieć sobie na pytanie co jest wiedzą a co metawiedzą.

Prawdę powiedziawszy nie umiem w tej chwili zaproponować czegoś, co z całym przekonaniem propagowałbym jako to, co właściwie oddziela nam metawiedzę od wiedzy.

(Tak na marginesie to nie my pierwsi mamy z tym kłopoty. Już m.in. Whitehead and Russell mieli z tym problemy, kiedy odkryto antynomie logiczne (np. 'paradoks kłamcy') i dopóki nie okazało się, że za wszystkimi problemami stoi pomieszanie języka i metajęzyka myślano, że fundamenty matematyki legły w gruzach.)

Wracając jednak do tematu...myślę, że w kontekście modelowania (w obszarze, który nas interesuje) zostało to dosyć dobrze zdefiniowane na gruncie mniej filozoficznym a bardziej technicznym w ramach modelu warstwowego zaproponowanego przez grupę OMG, gdzie zdefiniowane jest pojęcie modelu, metamodelu, meta-metamodelu. Tak więc podobnie jak w przypadku języka możemy mówić o metajęzyku jako o 'języku służącym do opisywania pewnego innego języka...' tak i w przypadku metamodelu możemy mówić o modelu, który opisuje inny model. Każda wyższa warstwa opisuje warstwę znajdującą się poniżej w tym sensie, że elementy modelu warstwy niższej są instancjami klas elemetów warstwy wyższej.

Z 'koniecznością rozdzielenia wiedzy od meta-wiedzy', o czym wspomniał Pan Marek wiąże się również inne, istotne w kontekście modelowania pojęcie trójkąta Ogdena, które mówi nam o różnicach pomiędzy pojęciem, symbolem który na nie wskazuje, intensji oraz ekstensji. Tworząc model często zapominamy o tych subtelnych różnicach, które sa tak istotne w procesie modelowania konceptualnego.

To co trochę jest dla mnie nie zrozumiałe to to dlaczego zaproponował Pan Panie Jacku patrzenie na model jako na coś co jest skutkiem ubocznym zastosowania wybranego algorytmu. Artefakt
to przede wszystkim niedoskonałość powstająca jako efekt zastosowanej przez nas metody rozwiązania zadania. W tym kontekście artefakt dla mnie jest konsekwencją stosowania takiego a nie innego modelu. Np: założenie klient ma zawsze rację i artefakt - nasze działania kiedy obiektywnie jej nie ma, ale ponieważ to on nam płaci, to tak postępujemy aby miał.

Niezrozumienie wynika z niejednoznacznej sematyki pojęcia artefakt, które biorąc pod uwagę 'common knowledge' jest w informatyce rzeczywiście definiowane jako 'wady będące skutkami ubocznymi zastosowania poszczególnych algorytmów [wikipedia]' ale ma również inne znaczenia np. 'sztuczny wytwór metody, a nie element realnie istniejący' lub 'przedmiot, będący dziełem pracy ludzkiej, w odróżnieniu od przedmiotów naturalnych'. Użyłem pojęcia artefakt w odniesieniu do produktu procesu modelowania. Określenie to często pojawia się w literaturze związanej z modelowaniem systemów informatycznych, gdzie przez artefakt rozumiane są dokumenty powstające w trakcie tworzenia systemu np. dokument wizji systemu, modele (np. diagramy lub zbiory diagramów), elementy modeli czy w końcu elementy oprogramowania. 'Artefakt' bardzo często pojawia się również w kontekście języka UML. Stąd moje użycie (być może nadużycie) takiej nazwy, we wspomnianym przez Pana Marka kontekście.

Pozdrawiam!

Temat: Modelowanie czy rysowanie

Jacek J.:
...myślę, że w kontekście modelowania (w obszarze, który nas
interesuje) zostało to dosyć dobrze zdefiniowane na gruncie
mniej filozoficznym a bardziej technicznym w ramach modelu
warstwowego zaproponowanego przez grupę OMG, gdzie zdefiniowane
jest pojęcie modelu, metamodelu, meta-metamodelu.

Jak najbardziej zasługujące na popularyzację podejście.

Tak więc podobnie jak w przypadku języka możemy mówić o metajęzyku jako o 'języku służącym do opisywania pewnego innego języka...' tak i w przypadku metamodelu możemy mówić o modelu, który opisuje inny model. Każda wyższa warstwa opisuje warstwę znajdującą się poniżej w tym sensie, że elementy modelu warstwy niższej są instancjami klas
elemetów warstwy wyższej.

No i mamy syntaktykę oraz semantykę modelowania w praktyce.

Z 'koniecznością rozdzielenia wiedzy od meta-wiedzy', o czym wspomniał Pan Marek wiąże się również inne, istotne w kontekście modelowania pojęcie trójkąta Ogdena, które mówi nam o różnicach pomiędzy pojęciem, symbolem który na nie wskazuje, intensji oraz ekstensji.

To już lingwistyka stosowana w rzyczywistości pozajęzykowej o charakterze strategicznym dla omawianego zagadnienia.

Tworząc model często zapominamy o tych subtelnych różnicach, które sa tak istotne w procesie modelowania konceptualnego.

Model biznesowy, z definicji, definiuje procesy pod ich nieobecność. Stąd duże znaczenie niniejszego dla właściwego rozumienia całości. Czyli przykład, budujemy relację: strzałka (forma znaku) --> składa zamówienie (pojęcie) --> klienci chcący złożyć zamówienie kierowani są do Działu 1, osoba odpowiedzialna X (rzeczywista zależność). Oczywiście nie istnieje bezpośredni związek pomiędzy strzałką a panią/panem X i klientem. Ten związek definiuje pojęcie, tu: składa zamówienie, nadające sens naszej relacji klient - osoba X.

'Artefakt' bardzo często pojawia się również w kontekście języka UML.

Opowiadam się za opcją nie nazywania po nowemu rzeczy już nazwanych zachowując sobie prawo do proponowania nowych terminów dla nienazwanego (zdarzyło się :D), nieodkrytego (nie zdarzyło się :D). ;D

Temat: Modelowanie czy rysowanie

To już lingwistyka stosowana w rzyczywistości pozajęzykowej o charakterze strategicznym dla omawianego zagadnienia.

Jest to prawda w odniesieniu do trójkąta Ogdena. Warto jednak pamiętać o tym, że zrozumienie tych subtelności nie jest sprawą prostą ale jest moim zdaniem kluczem do lepszego zrozumienia procesu modelowania konceptualnego. O tym, jak jest to istotne zagadnienie może świadczyć fakt zamieszczenia go przez guru podejścia obiektowego Jamesa Odell'a w jednym z pierwszych rozdziałów jego rewelacyjnej książki pt. "Podstawy metod obiektowych". Wprawdzie nie nazywa on tego 'po imieniu' ale wprowadza pojęcie 'trójki pojęciowej' którego zrozumienie jest bardzo istotne dla procesu klasyfikacji, który z kolei jest podstawowym procesem wykorzystywanym w analizie i projektowaniu obiektowym.

Pozdrawiam!

Temat: Modelowanie czy rysowanie

Jacek J.:
O tym, jak jest to istotne zagadnienie może świadczyć fakt zamieszczenia go przez guru podejścia obiektowego Jamesa Odell'a
w jednym z pierwszych rozdziałów jego rewelacyjnej książki pt.
"Podstawy metod obiektowych".

Czyli rozmawiamy o czymś ... banalnym no bo o podstawach. ;-D Najważniejsze to zacząć od czegoś łatwego to później będzie "z górki". ;-D Metody polimorficzne i enkapsulacja oraz przesłanianie identyfikatorów czekają ... . ;-D

Temat: Modelowanie czy rysowanie

Marek K.:

Jacek J.:
O tym, jak jest to istotne zagadnienie może świadczyć fakt zamieszczenia go przez guru podejścia obiektowego Jamesa Odell'a
w jednym z pierwszych rozdziałów jego rewelacyjnej książki pt.
"Podstawy metod obiektowych".

Czyli rozmawiamy o czymś ... banalnym no bo o podstawach. ;-D Najważniejsze to zacząć od czegoś łatwego to później będzie "z górki". ;-D Metody polimorficzne i enkapsulacja oraz przesłanianie identyfikatorów czekają ... . ;-D

Hmmm...no pewno banalnym...chociaz zajelo mi to kiedys troche czasu zanim dobrze zrozumiałem te banały (no ale juz dawno doszedlem do wniosku, ze jestem 'cienias' ;-)). A' propos wzglednosci okreslenia banalne przypomniala mi sie pewna anegdota z zycia UJ i sp. prof. Lojasiewicza, ktory uzywal takich stwierdzen na wykladach z rozmaitosci rozniczkowalnych. Jezeli twierdzenie bylo trywialne to student musial spedzic 1 miesiac nad dowodem, jezeli banalne to do 3 miesiecy a jezeli proste to podobno bywalo, ze i semestr.

Ale wracajac do naszego tematu...z moich obserwacji wynika, ze podstawowym problemem, z ktorego czesto wynikaja zle zaprojektowane systemy jest brak zrozumienia podstaw i umiejetnosci myslenia z wykorzystaniem pewnego bazowego 'mindset'u', ktory pozwala wlasciwie przeprowadzic proces konceptualizacji dziedziny problemu. Wielokrotnie wspolpracowalem z osobami, ktore swietnie radzily sobie z technika programowania w okrelonym jezyku ale ich rozwiazania nie byly stworzone z wykorzystaniem dobrych praktyk...

Temat: Modelowanie czy rysowanie

Jacek J.:
anegdota z zycia UJ i sp. prof. Lojasiewicza, ktory uzywal takich stwierdzen na wykladach z rozmaitosci rozniczkowalnych.
Jezeli twierdzenie bylo trywialne to student musial spedzic 1
miesiac nad dowodem, jezeli banalne to do 3 miesiecy a jezeli
proste to podobno bywalo, ze i semestr.

Tak, tak, to już klasyka. Ja na swój własny użytek korzystałem z tego, że jak nie było to z jakichś powodów niezbędne, to nie podejmowałem prób poszukiwania rozwiązania jak autor w podręczniku napisał co łatwo mozna udowodnić, a nie czynił tego. Jak rzeczywiście prosto to czemu tego nie przedstawił, choćby w załączniku jak mu do pozostałej treści rozdziału nie pasowało.

podstawowym problemem, z ktorego czesto wynikaja zle zaprojektowane systemy jest brak zrozumienia podstaw i umiejetnosci myslenia z wykorzystaniem pewnego bazowego 'mindset'u', ktory pozwala wlasciwie przeprowadzic proces konceptualizacji dziedziny problemu.

To prawda uniwersalna.

wspolpracowalem z osobami, ktore swietnie radzily sobie z
technika programowania w okrelonym jezyku ale ich rozwiazania
nie byly stworzone z wykorzystaniem dobrych praktyk...

Ja bym użył ich rozwiazania nie były eleganckie, przejrzyste, optymalne, lub tp. Dobre praktyki, bardzo ładne słowo, ang. best practise, jeszcze ładniejsze słowo, jest dla mnie czymś niezrozumiałym. Kiedyś na konferencji CA w Warszawie, promującej ich rozwiązania z zakresu ITIL, tłumaczono co to takiego jest. Niewytrzymałem i zapytałem. Przepraszam ale nie rozumiem. Proponujecie Państwo najpierw zapoznanie się z tym jak to robią inni, a następnie korzystanie z najlepszych sprawdzonych rozwiązań. Przecież to elementarz działań zdroworozsądkowo myślącego człowieka. (Oczywistym jest, że opcja CA promowana była jako ta już wyselekcjonowana najlepsza.)

W takim razie jaki sposób postępowania ma wybrać człowiek porwany przez lawinę? Idąc torem myślenia dobrych praktyk należy stosować najlepsze rozwiązania, ze zbioru tych które się sprawdziły. W tym przypadku za takie należy uznać te, które pozwoliły przeżyć. No i teraz rzeczywiste przypadki.

Jeden porwany przez lawinę zwinął się w kłębek i dzięki temu wyrzuciło go na powierzchnię. Drugi próbując utrzymać się na powierzchni odgarniał śnieg niczym pływak i teraz mówi, że tylko ruchy żabką. Inny miał takiego stracha, że cały zasztywniał i jak patyk ostał się na powierzchni, no i oczywiście twierdzi, że broń boże ruszać się. Jeszcze inny nie był w stanie nic zrobić, wymaglowało go nieżle góra dół i teraz prawi, żeby się rozluźnić! Nic nie robić i pozwolić aby połamało nam wszystkie kości? ...

No to, za przeproszeniem, o co chodzi z tymi najlepszymi praktykami?

PS Przepraszam pomyliłem cytowany tytuł: Zadanie metoda rozwiązanie. Techniki twórczego myślenia pod redakcją Andrzeja Góralskiego

Temat: Modelowanie czy rysowanie

Jeden porwany przez lawinę zwinął się w kłębek i dzięki temu wyrzuciło go na powierzchnię. Drugi próbując utrzymać się na powierzchni odgarniał śnieg niczym pływak i teraz mówi, że tylko ruchy żabką. Inny miał takiego stracha, że cały zasztywniał i jak patyk ostał się na powierzchni, no i oczywiście twierdzi, że broń boże ruszać się. Jeszcze inny nie był w stanie nic zrobić, wymaglowało go nieżle góra dół i teraz prawi, żeby się rozluźnić! Nic nie robić i pozwolić aby połamało nam wszystkie kości? ...

No to, za przeproszeniem, o co chodzi z tymi najlepszymi praktykami?

...a moze po analizie okaze sie (przy zalozeniu, ze modelowanie jest bardziej powtarzalnym dzialaniem niz uczestniczenie w lawinach :-)), ze zwinieci w klebek przezyli 1000 razy na 1100 uczestnictw w lawinach, plywacy 800, patyczaki 500 etc. wowczas mozemy zwijanie w klebek uznac za dobra praktyke :-)...ale tak na powaznie, okreslenia 'dobre praktyki' uzylem w kontekscie wzorcow projektowych oraz umiejetnosci korzystania w procesie modelowania z wlasciwych danemu podejsciu pojec modelowania oraz uniwersalnych zasad projektowania i mechanizmow cechujacych okreslone podejscie (np. zasada abstrakcji, uscislania krokowego, projektowania skladanego, hermetyzacji etc). Oczywiscie na pierwszym planie w strukturze pojeciowej wykorzystywanej przez 'modelarza' powinny znalezc sie podstawowe cechy systemu zlozonego, ktorym kazda organizacja, czy system informatyczny jest bez watpienia.

Pozdrawiam!

Temat: Modelowanie czy rysowanie

Jacek J.:
... ale tak na powaznie, okreslenia 'dobre praktyki' uzylem w
kontekscie wzorcow projektowych oraz umiejetnosci korzystania w
procesie modelowania z wlasciwych danemu podejsciu pojec
modelowania oraz uniwersalnych zasad projektowania i mechanizmow
cechujacych okreslone podejscie

'Dobre praktyki' też postrzegam jako umiejętność korzystania z właściwych pojęć, zasad, mechanizmów, co potocznie można by określić jako zwyczaj używania głowy. Więc rozumiemy się bardzo dobrze. ;-D To, że napisałem 'nie rozumiem' wynika z mojego
sprzeciwu wobec używania terminu 'dobra praktyka' jako nazwy produktu na sprzedaż, z założenia najlepszego w swojej klasie. Stąd już blisko do jedynie słusznych konfiguracji sieci, organizacji pracy, oprogramowania, ... itd, itp. :((( I tego nie
rozumiem, bo zaraz okaże się, że całe kształcenie szerokich rzeszy też nie ma sensu bo wystarczy wybranych (tych z IQ > x,
?). To co dobre i sprawdzone należy propagować, można sprzedawać
jak ktoś potrafi, ale sprzedawać 'dobrą praktykę' na poziomie metawiedzy jest nadużyciem, oczywiście jak dla mnie. :( A nasuwa
mi się ta dygresja bo oczywiście o biznesie rozmawiamy. :D

(np. zasada abstrakcji, uscislania krokowego, projektowania
skladanego, hermetyzacji etc). Oczywiscie na pierwszym planie w
strukturze pojeciowej wykorzystywanej przez 'modelarza' powinny
znalezc sie podstawowe cechy systemu zlozonego, ktorym kazda organizacja, czy system informatyczny jest bez watpienia.

Dla mnie przedsiębiorstwo jest też przestrzenią zamkniętą. Zamkniętą ponieważ ma określoną liczbę pracowników, lokalizacji, obiektów, środków trwałych i wyposażenia, produktów i usług. Ilość partnerów biznesowych (dostawcy/odbiorcy) co prawda jest zmienna ale też należy do jakiejś grupy docelowej. Modelując organizację poruszamy się więc w ramach jakiejś przestrzeni rozwiązywania zadania. Jeżeli o przestrzeni zaś mowa, to nie sposób pominąć teorii grafów. Jak można eksploatować graf pokazuje rysunek.





Otwartym pytaniem jest jak daleko odbiegliśmy już w dyskusji od praktyki? Moim zdaniem nie aż tak daleko. :DMarek Kubiś edytował(a) ten post dnia 29.09.07 o godzinie 11:59

Temat: Modelowanie czy rysowanie

Dla mnie przedsiębiorstwo jest też przestrzenią zamkniętą. Zamkniętą ponieważ ma określoną liczbę pracowników, lokalizacji, obiektów, środków trwałych i wyposażenia, produktów i usług. Ilość partnerów biznesowych (dostawcy/odbiorcy) co prawda jest zmienna ale też należy do jakiejś grupy docelowej. Modelując organizację poruszamy się więc w ramach jakiejś przestrzeni rozwiązywania zadania. Jeżeli o przestrzeni zaś mowa, to nie sposób pominąć teorii grafów. Jak można eksploatować graf pokazuje rysunek.

Spojrzenie na organizację w taki sposób jest oczywiście bardzo istotną perspektywą modelowania. Pisząc o ramie pojęciowej 'modelarza organizacji' zawierajacej kluczowe cechy systemow zlożonych mialem dodatkowo na mysli następujące kwestie:

1. Złożoność często przyjmuje formę hierarchii, zgodnie z którą system jest skomponowany z powiązanych między sobą podsystemów, które mają swoje podsystemy, które z kolei mają swoje podsystemy i tak dalej, aż zostanie osią-gnięty poziom elementarny. Hierarchia nie oznacza tutaj relacji typu zwierzchnik-podwładny. Dzięki temu, że systemy złożone są CZĘŚCIOWO DEKOMPONOWALNE (ang. Nearly Decomposable) możemy je zrozumieć, opisać a nawet „zobaczyć”. Jak twierdzi Simon „…jest bardzo prawdopodobne, że w rzeczywistości można zrozumieć tylko te systemy, które mają strukturę hierarchiczną…”. Patrząc na organizację z perspektywy tej cechy systemów złożonych, możliwe jest wyodrębnienie takich poziomów hierarchii jak poziom aktorów organizacyjnych, procesów biznesowych, poziom pojedynczej organizacji oraz odpowiedniej konfiguracji kilku organizacji w formie organizacji wirtualnej.

2. Wybór tego, które komponenty systemu powinny być traktowane jako elementarne jest relatywnie arbitralny i zależy od decyzji obserwatora systemu.

3. Istnieje możliwość zidentyfikowania interakcji zachodzących zarówno pomiędzy podsystemami jak i wewnątrz podsystemów, pomiędzy ich blokami składowymi, przy czym, te drugie mają o rząd wielkości większą częstotliwość i są bardziej przewidywalne. Częstotliwość interakcji będzie się różniła w zależności od poziomu hierarchii. Przykładowo, w organizacji gospodarczej, więcej interakcji będzie miało miejsce pomiędzy pracownikami realizującymi swoje zadania w obrębie tego samego procesu niż pomiędzy pracownikami działającymi w różnych zespołach proceowych. Różnice występujące pomiędzy częstością interakcji zachodzących wewnątrz i pomiędzy podsystemami pozwalają przeprowadzić dekompozycję i prowadzą do jasnego podziału pomiędzy obszarami analizy. W przypadku systemów socjalnych, a takim bez wątpienia jest każda organizacja CZĘŚCIOWA DEKOMPONOWALNOŚĆ jest cechą bardzo dobrze widoczną, dzięki czemu możliwe jest wykorzystanie zalet metody dekompozycji.

4. Systemy złożone są najczęściej kolekcją podobnych do siebie elementów zestawionych w różnych układach i kombinacjach. Mówiąc inaczej istnieją pewne wspólne wzorce tworzone na zasadzie ponownego wykorzystania podobnych do siebie elementarnych komponentów lub większych struktur w postaci podsystemów. Dobrymi przykładami takiej „filozofii konstrukcji” są komórki lub system naczyniowy roślin i zwierząt. Innym przykładem elementarnych komponentów, może być pojęcie pozycji społecznej lub roli organizacyjnej, która może być traktowana jako podstawowy blok składowy każdej organizacji.

5. Systemy zorganizowane w formie hierarchii mają tendencje do ewoluowania w czasie, przy czym systemy hierarchiczne ewoluują szybciej w porównaniu z niehierarchicznymi. Jak twierdzi Simon, systemy złożone będą ewoluować z prostych systemów, jeżeli istnieją pewne stabilne formy pośrednie.

Jeżeli 'modelarz' ma intuicje zwiazane z tymi cechami, to jest w stanie, w sytuacji gdy wymaga tego kontekst skorzystac w procesie tworzenia modelu z właściwej zasady (abstrakcji, dekompozycji, uściślania etc.).

Pozdrawiam!

Temat: Modelowanie czy rysowanie

Tak sobie piszemy, piszemy i pewnie książeczkę niedługo napiszemy. ;-D A tu jakoś chętnych do dodania czegoś nie widać. :( Nie szkodzi. :-D

Tak się zastanawiam do jakiego stopnia złożoności organizacji wystarcza intuicja, doświadczenie "modelarza". Kiedy modelowanie z wykorzystaniem aparatu matematycznego staje się niezbędne. Kolejna rzecz to nie bardzo potrafię wyobrazić sobie niehierarchicznie zorganizowany biznes. Słowo 'często' skłonny więc jestem w pkt.1 zastąpić słowem 'zawsze'. Nawet jeżeli nie ma jednego szefa, jednej najważniejszej rzeczy to i tak całość muszą łączyć jakieś zależności, a jak zależności to i hierarchia.

Nawet nawiązując do Simona, nie jestem sobie w stanie wyobrazić funkcjonowania organizacji, której nie jesteśmy w stanie zrozumieć. Abstrahując od zdolności sprawczych konkretnej osoby, bo wyobrazić sobie funkcjonowanie czegoś co ja nie rozumiem jestem w stanie, to jednak musi być ktoś kto rozumie. Dekomponowalność może pomóc zrozumieć, ale nawet jak by nie udało się nam sensownie wydzielić jednostek organizacyjnych, to jednak musimy być świadomi biznesowego celu ich istnienia. Bo i po co, oraz jak opisywać twór, którego sensu istnienia nie umiemy uzasadnić.

Kolejna rzecz to co Pan rozumie jako elementarne komponenty systemu. Rozumiem, że ma to szczególne znaczenie w sytuacji kiedy okazuje się iż mamy swoisty 'deadlock', np: X nie może przekazać dokumentu do Y bez podpisu Z, a Z nie może dostać do podpisu jak nie ma podpisu Y.

Tak się też zastanawim, jak w modelowaniu własciwie ująć dynamicznie tworzone, bez powiązania ze strukturą organizacyjną, twory, takie jak np: samozarządzające się grupy pracowników. Może być ich wiele, skład osobowy jest kompletnie wymieszany, czas funkcjonowania ograniczony, sztywna struktura organizacyjna, czy obieg dokumentów nie ma tu nic do rzeczy. To co je łączy to problem do rozwiązania. Można przewidzieć potrzebę ich istnienia ale to koniec. Czym się będą zajmowały, od kogo wyjdzie inicjatywa, jak długo, itd. nie sposób wiedzieć a'priori.

Temat: Modelowanie czy rysowanie

Tak nam trochę zamarła dyskusja ... :-(

Trudno oprzeć mi się zadaniu pytania, komu to potrzebne? komu to się przyda? kto skorzysta? czy to niezbędne? jaką mamy alternatywę (można inaczej)? skąd się to wzięło? czy ma to przyszłość? jakie konsekwencje?

Przy całej sympatii do obowiązującego tu stylu myślenia "twórczych" wątpliwości mam wiele. Oczywiście mam swoją odpowiedź ale jestem ciekaw waszego zdania.

OMG przygotowuje nową wersję BPMN 2.0 i być może będzie ona dostępna po 18.02.2008. Notacja BPMN rozszerzona zostanie do koncepcji modelowania na poziomie meta, BPDM (Business Process Definition Metamodel). Poprzeczka w górę?

Temat: Modelowanie czy rysowanie

Wynurzę się za jakieś 10 dni to wspomogę. Jak wiadomo wielu zainteresowanym, jestem zdecydowanym krytykiem tej koncepcji (rodzina BPML).

Temat: Modelowanie czy rysowanie

Andrzej G.:
Wynurzę się za jakieś 10 dni to wspomogę. Jak wiadomo wielu zainteresowanym, jestem zdecydowanym krytykiem tej koncepcji (rodzina BPML).

:-D

Temat: Modelowanie czy rysowanie

Ano niestety trochę zamarła :-(. Ilość zajęc w nowym roku akademickim powoduje, że nie jestem w stanie trzeźwo myslec po 21 (i nie chodzi o alkohol ani lekarstwa na chorobę z Filipin :D), a stratą czasu jest przesyłanie mętnych wypowiedzi...Od dluższego czasu się przymierzam, żeby odpowiedzieć na post Pana Marka i może w końcu mi się to uda...Pozdrawiam!

Temat: Modelowanie czy rysowanie

Wcięło mnie na troszke za co przepraszm :), robota....

No ciekawe to co przeczytałem :) ... i tak sobie myślę:

- nie mam przekonania do tego, że organizacje to zamknięte organizmy do modelowania bo organizacje współpracują z otoczeniem (np. model SCOR) wiec są na nie jednak otwarte

- to wszystko prawda co piszecie dlatego staram się testować modele wiedzą o zdarzeniach z historii modelowanej organizacji

- nie wiem czy to dobrze ale jak przekonam się do notacji i jej syntaktyki to przymus modelowania w zgodzie z syntaktyką traktuje to jako test zrozumienia modelowanej organizacji, dokładam do tego style modelwania np. orientacje na produkty

- kluczowym testem jest według mnie to czy źródło wiedzy o firmie (osoba którą wypytuję) potrafi poprawnie odzczytać diagramy i zweryfikowac je.

Powyższe traktuję właśnie jako sposób na "leczenie" niedostaków prostego diagramowania, o których słusznie piszecie.

Ciekaw jestem Waszych doświadczeń w tym względzie.

Temat: Modelowanie czy rysowanie

[author]Jarosław

Link do wypowiedzi