konto usunięte

Temat: Modelowanie biznesowe, a analiza systemowa

To w końcu co jest tematem tego działu ? Modelowanie biznesowe, czy analiza systemowa ? Pytam, bo jeśli ktoś zna się na rzeczy to wie, że są to zupełnie różne dyscypliny ... A tu widzę groch z kapustą ...
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Modelowanie biznesowe, a analiza systemowa

Jerzy N.:
To w końcu co jest tematem tego działu ? Modelowanie biznesowe, czy analiza systemowa ? Pytam, bo jeśli ktoś zna się na rzeczy to wie, że są to zupełnie różne dyscypliny ... A tu widzę groch z kapustą ...

„Analiza systemowa to działanie mające na celu dostarczenie wskazówek do podjęcia decyzji, poprzez generowanie i odpowiednie przedstawianie informacji związanej z zagadnieniem, którego decyzja dotyczy. Podstawowe pojęcia analizy systemowej: cele, warianty, koszty, miary jakości, kryteria wyboru, modele.”

Zwracam uwagę, że analiza systemowa to nie tylko analiza, której celem jest projekt systemu IT, teoria systemów to nie informatyka,
albo: http://pl.wikipedia.org/wiki/Analiza_systemowa

Modelowanie biznesowe jest jednym z elementów analizy systemowej, która to wypracowuje rekomendacje na bazie budowanych modeli.

Jeżeli więc analizy systemowej używamy do wypracowywania rekomendacji w sferze biznesowej (reorganizacja, wymagania na system ERP itp.) to potrzebny jest między innymi model biznesowy analizowanej organizacji a nie raz model jej procesów binesowych.

Nazwa grupy to Modelowanie biznesowe czyli tworzenie modeli przydatnych w decyzjach biznesowych w procesach prowadzonych analiz. Analiza systemowa używa między innymi tych modeli.

Kilka definicji ze słownika PWN:

analiza
1. «rozpatrywanie jakiegoś problemu, zjawiska z różnych stron w celu jego zrozumienia lub wyjaśnienia; też: wyjaśnienie lub opis, będące wynikiem takiego rozpatrywania»
2. «metoda badawcza polegająca na wyodrębnieniu z danej całości jej elementów i badaniu każdego z osobna»

system
1. «układ elementów mający określoną strukturę i stanowiący logicznie uporządkowaną całość»
4. «uporządkowany zbiór twierdzeń, poglądów, tworzących jakąś teorię»
5. «określony sposób wykonywania jakiejś czynności lub zasady organizacji czegoś»

konto usunięte

Temat: Modelowanie biznesowe, a analiza systemowa

„Analiza systemowa to działanie mające na celu dostarczenie wskazówek do podjęcia decyzji, poprzez generowanie i odpowiednie

Panie Jarku,
Cytuje Pan terminy nie z tej bajki, naprawdę ....
Modelowanie biznesowe, Analiza systemowa itd. to dyscypliny zdefiniowane w pewnej takiej metodyce, która RUP się zwie, a która to metodyka podpiera się UML-em (a ostatnio zaczyna BPMN-em), a poza tym staje się coraz bardziej popularna na świecie ... i z trudem u nas w Polsce ...
Ja bardziej operuję w sferze tworzenia oprogramowania (od pisania ofert, aż do wdrożeń itd.) i z PW IT jestem, toteż pozwoli Pan, Panie Jarku, że pozostanę na razie przy RUP-ie i innych metodykach z zakresu Inżynierii Oprogramowania.
W takim przypadku odpowiedź na moje pytanie jest prosta ... wystarczy poczytać na Wikipedii wątek RUP. Polecam ;)
Jerzy Niepostyn.
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Modelowanie biznesowe, a analiza systemowa

Jerzy N.:
„Analiza systemowa to działanie mające na celu dostarczenie wskazówek do podjęcia decyzji, poprzez generowanie i odpowiednie

Panie Jarku,
Cytuje Pan terminy nie z tej bajki, naprawdę ....

Nie z Pana bajki ;)
Modelowanie biznesowe, Analiza systemowa itd. to dyscypliny zdefiniowane w pewnej takiej metodyce, która RUP się zwie, a która to metodyka podpiera się UML-em (a ostatnio zaczyna BPMN-em), a poza tym staje się coraz bardziej popularna na świecie ... i z trudem u nas w Polsce ...

Nie dziwię się, RUP, jako reprezentant metodyk "ciężkich" ma wiele konkurentów...

Analiza Systemowa to nie analiza systemów infomatycznych.... sugeruje jednak książki a nie WIKI...

Są jeszcze na świecie inne rzeczy poza RUP. Doceniam religijność w sferze RUP jednak nie jest to jedyna metodyka a jedna z kilku. Ja zaś polecam metodyki SOMA, Catalyst, a nawet SCRUM czy Agile, metody zorientowane procesowo, analizę systemową i obiektową itp..

Ja bardziej operuję w sferze tworzenia oprogramowania (od pisania ofert, aż do wdrożeń itd.) i z PW IT jestem, toteż pozwoli Pan, Panie Jarku, że pozostanę na razie przy RUP-ie i innych metodykach z zakresu Inżynierii Oprogramowania.

Jeżeli tylko Pan oferuje, sprzedaje i wdraża systemy IT to ma Pan wąsko specjalizowane doświadczenie.

Co tu ma do rzeczy PW IT? Bo ja jestem z AM WPiT KSI.

Ja operuję w sferze, w której oprogramowanie jest tylko częścią strategii rynkowej firmy .... i muszę troszkę szerzej patrzeć na problem... szczególnie w kwestii rentowności, w której RUP nie ma za wiele do powiedzenia. Dla mnie podstawą jest BPMN i modele biznesowe, modele UML to ich konsekwencja (polecam też SysML).

W takim przypadku odpowiedź na moje pytanie jest prosta ... wystarczy poczytać na Wikipedii wątek RUP. Polecam ;)
Jerzy Niepostyn.

Ogólna Teoria Systemów to pojęcie znacznie szersze i jeżeli RUP to obecnie kupiona od Rational Software IBMowska religia (nota bene nie taka skuteczna wcale jak pokazuje życie, bywa że robię szkolenia z RUP) bazująca na przypadkach użycia (ostatnio nie traktowanych zbyt poważnie w sferze biznesowej, polecam współczesne książki o analizie obiektowej, mam nadzieję, że Wiki to nie jedyne źródło Pana wiedzy), niezrozumiałym dla biznesu UML (ja go używam tylko gdy klientem jest dla mnie ktoś kto zna UML).

A jeżeli już Pan tan ceni sobie WIKI to sugeruję konsekwencję w zdobywaniu unikalnej wiedzy:

http://pl.wikipedia.org/wiki/Analiza_systemowa

http://pl.wikibooks.org/wiki/Obiektowo%C5%9B%C4%87_w_t...

http://pl.wikipedia.org/wiki/Scrum

do poduszki polecam np. coś krótkiego:

http://deuter.am.put.poznan.pl/zwm/eskrypty_pliki/inzy...

Co do religii to dla mnie "biznesowe przypadki użycia" i "biznesowe klasy" w RUP to kosmos, którego nikt poza autorami, mną i byc może Panem i paroma innymi, nie kuma. Gdybym chciał się pozbyć któregoś z moich klientów dał bym mu (np. Prezesowi firmy) taki diagram UML.

Osobiście wole biznes opisywac notacją BPMN a z niej wyprowadzać za pośrednictwem SysML wymagania, które modeluje dopiero w UML. Przypadki użycia to tylko sytuacje, w których wybrany proces lub czynność planujmey do wsparcia systemem IT. W niektórych metodykach (Catalyst lub SOMA właśnie) UseCase to trzeci lub czwarty etap nawet nie analizy a specyfikowania wymagań.

A przy okazji zapraszam na konferencję gdzie można będzie mnie spotkać i podyskutować co lubię robić :)

http://www.cpi.com.pl/imprezy/2007/uml/index.php

konto usunięte

Temat: Modelowanie biznesowe, a analiza systemowa

Analiza Systemowa to nie analiza systemów infomatycznych.... sugeruje jednak książki a nie WIKI...

Doceniam Pańską złośliwość, jednakże chciałbym zauważyć, że to Pan, Panie Jarku wcześniej powoływał się na wikipedię, stąd moje uwagi w tym względzie, z uwagi na to, że inne źródła wiedzy mogłyby być dla Pana całkowicie nieosiągalne ;)
Są jeszcze na świecie inne rzeczy poza RUP. Doceniam religijność w sferze RUP jednak nie jest to jedyna metodyka a jedna z kilku. Ja zaś polecam metodyki SOMA, Catalyst, a nawet SCRUM czy Agile, metody zorientowane procesowo, analizę systemową i obiektową itp..

Jak by Pan trochę spróbował coś więcej dowiedzieć się o metodykach lekkich (agilnych), to zapewne ze zdziwieniem dowiedziałby się Pan o tym, że te metodyki w zasadzie całkowicie pozbawione są wspomagania ze strony np. modelowania biznesowego (jak najmniej jakiejkolwiek dokumentacji). No, ale cóż, coś Pan słyszał, ale w którym kościele, to już nie za bardzo Pan wie, nieprawdaż ?
Jeżeli tylko Pan oferuje, sprzedaje i wdraża systemy IT to ma
Pan wąsko specjalizowane doświadczenie.

Rozumiem, że chciałby Pan obejrzeć moje cv. Spróbuję coś niedługo skrobnąć, gdyż widzę, że aż tupie Pan nóżkami ze zniecierpliwienia ;)
Ja operuję w sferze, w której oprogramowanie jest tylko częścią strategii rynkowej firmy .... i muszę troszkę szerzej

Znaczy, że nigdy Pan nie programował ? Cóż ... bardzo wąskie doświadczenie ma Pan w Inżynierii Oprogramowania.
Ogólna Teoria Systemów to pojęcie znacznie szersze i jeżeli RUP to obecnie kupiona od Rational Software IBMowska religia (nota bene nie taka skuteczna wcale jak pokazuje życie, bywa że robię
szkolenia z RUP) bazująca na przypadkach użycia (ostatnio nie
traktowanych zbyt poważnie w sferze biznesowej, polecam współczesne książki o analizie obiektowej, mam nadzieję, że Wiki to nie jedyne źródło Pana wiedzy), niezrozumiałym dla biznesu UML (ja go używam tylko gdy klientem jest dla mnie ktoś
kto zna UML).

Aż dziw, że taka firemka jak TPSA wzięła się za UML w opisie swoich procesów biznesowych.
A jeżeli już Pan tan ceni sobie WIKI to sugeruję konsekwencję
w zdobywaniu unikalnej wiedzy:
http://pl.wikipedia.org/wiki/Analiza_systemowa
http://pl.wikibooks.org/wiki/Obiektowo%C5%9B%C4%87_w_t...
http://pl.wikipedia.org/wiki/Scrum

A jednak z Pan to niesamowity szperacz po wikipedii ;)
Co do religii to dla mnie "biznesowe przypadki użycia" i "biznesowe klasy" w RUP to kosmos, którego nikt poza autorami,
mną i byc może Panem i paroma innymi, nie kuma. Gdybym chciał
się pozbyć któregoś z moich klientów dał bym mu (np. Prezesowi firmy) taki diagram UML.
Osobiście wole biznes opisywac notacją BPMN a z niej wyprowadzać za pośrednictwem SysML wymagania, które modeluje dopiero w UML. Przypadki użycia to tylko sytuacje, w których wybrany proces lub czynność planujmey do wsparcia systemem IT. W
niektórych metodykach (Catalyst lub SOMA właśnie) UseCase to trzeci lub czwarty etap nawet nie analizy a specyfikowania wymagań.

Naprawdę Pan kuma use-case'y ? Biznesowe, czy systemowe ?
A przy okazji zapraszam na konferencję gdzie można będzie mnie
spotkać i podyskutować co lubię robić :)
http://www.cpi.com.pl/imprezy/2007/uml/index.php

Dziękuję za zaproszenie. Nie mówię nie ... :)
I przepraszam za złośliwości ... to chyba od Alicji, której wydawało się, że może z Panem rozmawiać jak równy z równym ;)
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Modelowanie biznesowe, a analiza systemowa

Jerzy N.:
Doceniam Pańską złośliwość, jednakże chciałbym zauważyć, że to Pan, Panie Jarku wcześniej powoływał się na wikipedię, stąd moje uwagi w tym względzie, z uwagi na to, że inne źródła wiedzy mogłyby być dla Pana całkowicie nieosiągalne ;)

I widzi Pan jak to się można na człowieku przejechać...;)

Jak by Pan trochę spróbował coś więcej dowiedzieć się o metodykach lekkich (agilnych), to zapewne ze zdziwieniem dowiedziałby się Pan o tym, że te metodyki w zasadzie całkowicie pozbawione są wspomagania ze strony np. modelowania biznesowego (jak najmniej jakiejkolwiek dokumentacji). No, ale cóż, coś Pan słyszał, ale w którym kościele, to już nie za bardzo Pan wie, nieprawdaż ?

No to sugeruje jednak czytać dalej (np. Agile manifesto): metodyki lekkie zalecają wykonywanie tylko potrzebnych dokumentów czyli tych także czytanych (czyli takich, które coś wnoszą poza kilogramami papieru) a nie wszystkich możliwych, modele jak są potrzebne to sie je robi a jak są nieporzebne to nie.

Rozumiem, że chciałby Pan obejrzeć moje cv. Spróbuję coś niedługo skrobnąć, gdyż widzę, że aż tupie Pan nóżkami ze zniecierpliwienia ;)

Nie palę się , o człowieku świadczą głównie jego słowa a nie wypisy z historii ;)

Znaczy, że nigdy Pan nie programował ? Cóż ... bardzo wąskie doświadczenie ma Pan w Inżynierii Oprogramowania.

Czy to znaczy, że kto nie programował ten nie zna życia? Kodowanie to tylko część czasu projektów, mniejsza ..... Ja jestem raczej architektem, który daje murarzom 'obrazki' do wykonania, a Pan to rozumiem z tej wypowiedzi głównie murarz????

Aż dziw, że taka firemka jak TPSA wzięła się za UML w opisie swoich procesów biznesowych.

No, po roku czasu w grupie TP_SA nic mnie już nie zaskoczy. Po drugie napisałem, że UML jest dla tych co go znają, jeżeli w TPSA adresatów tych diagramów przeszkolili z UML to super. Po drugie polecam przysłowie o muchach jedzących gówno (za przeproszeniem).

A jednak z Pan to niesamowity szperacz po wikipedii ;)

W google....
Naprawdę Pan kuma use-case'y ? Biznesowe, czy systemowe ?

Jedne i drugie są raczej obśmiane, use casy w analizie obiektowej to interakcje człowieka z programem. W mojej bajce drukarka czy konkurencyjny serwer to obiekt z interfejsem a nie aktor systemowy z systemowym przypadkiem użycia, które to pojęcia nie wytrzymują prostych opisów sematyki modelowania w UML.

Dziękuję za zaproszenie. Nie mówię nie ... :)

:)
I przepraszam za złośliwości ... to chyba od Alicji, której wydawało się, że może z Panem rozmawiać jak równy z równym ;)

Ależ Pan nie ma za co przepraszać :), proszę pozdrowić Alicję ... ostatnio także freelancerke :)

konto usunięte

Temat: Modelowanie biznesowe, a analiza systemowa

No to sugeruje jednak czytać dalej (np. Agile manifesto): metodyki lekkie zalecają wykonywanie tylko potrzebnych dokumentów czyli tych także czytanych (czyli takich, które coś
wnoszą poza kilogramami papieru) a nie wszystkich możliwych, modele jak są potrzebne to sie je robi a jak są nieporzebne to
nie.
Czy to znaczy, że kto nie programował ten nie zna życia? Kodowanie to tylko część czasu projektów, mniejsza ..... Ja jestem raczej architektem, który daje murarzom 'obrazki' do wykonania, a Pan to rozumiem z tej wypowiedzi głównie murarz????
Z murarza wyrosłem, to się zgadza. Daje mi to kolosalną przewagę nad wieloma osobami, którym się wydaje, że jak przeczytają kilka książek, to już wiedzą jak robić system informatyczny. A z tą dziedziną jak w życiu ... książki są jakimiś tam uogólnieniami, czy nawet tylko spojrzeniem innych osób na zagadnienie.
A diabeł tkwi w szczegółach. Jak się nie zrobi jakiegoś systemu w jakiejś tam metodyce, to nie ma się pojęcia o czym się mówi.
No, po roku czasu w grupie TP_SA nic mnie już nie zaskoczy. Po
drugie napisałem, że UML jest dla tych co go znają, jeżeli w TPSA adresatów tych diagramów przeszkolili z UML to super. Po
drugie polecam przysłowie o muchach jedzących gówno (za przeproszeniem).
Nie należy, Panie Jarku, nikim gardzić. Poza tym najważniejsze, że zaczęli coś w tym rzeźbić. Poza tym rozumiem, że wielkie banki, ubezpieczalnie i wiele wiele innych instytucji też nie wiedzą co czynią. A z tego co widziałem i słyszałem, ponoć te nieuki z zagranicy im kazali ;)
Jedne i drugie są raczej obśmiane, use casy w analizie obiektowej to interakcje człowieka z programem. W mojej bajce
drukarka czy konkurencyjny serwer to obiekt z interfejsem a nie
aktor systemowy z systemowym przypadkiem użycia, które to pojęcia nie wytrzymują prostych opisów sematyki modelowania w
UML.

UML powstał z myślą o modelowaniu oprogramowania. Na szczęście stereotypy pozwalają modelować również systemy informacyjne. Ponadto oprócz Pańskiego artykułu sprzed lat kilku (głosił Pan koniec ery use-cas'ów - ile lat jeszcze Pan daje tej notacji ?) nie słyszałem, by ktoś się naśmiewał z UML-a, aczkolwiek jest wiele narzekań ze względów jak wyżej.
Ależ Pan nie ma za co przepraszać :), proszę pozdrowić Alicję
... ostatnio także freelancerke :)

Z Alicją to ja się bardzo dawno nie widziałem, jak również z 4pi. Chłopaki zakupili sobie furki i nie mają czym płacić ludziom. Takie dziecinne zagrania ;)
Wracjąc jednak do 4pi, to się trochę minęliśmy w UPRP. Aczkolwiek muszę powiedzieć, że to dzięki Panu bardziej zainteresowałem się BPMN-em. Przeglądając diagramiki (nie wiem, czy to Pan, czy AS to wytworzył - nie dopytywałem się) stwierdziłem, że ktoś zbyt abstrakcyjnie potraktował modelowanie biznesowe. I faktycznie. Ściągnięta dokumentacja z omg wskazywała, że jedna sprawa to radosna twórczość analityków, a druga to wymagane standardy, a trzecia to narzędzia, które czasem zupełnie nie odzwierciedlają jakichkolwiek standardów.
Z tą myślą pozdrawiam Pana i polecam pozbycia się pychy. Ta cecha bardzo przeszkadza w uczeniu się nowych rzeczy.
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Modelowanie biznesowe, a analiza systemowa

Jerzy N.:
Z murarza wyrosłem, to się zgadza. Daje mi to kolosalną przewagę nad wieloma osobami, którym się wydaje, że jak przeczytają kilka książek, to już wiedzą jak robić system informatyczny. A z tą dziedziną jak w życiu ... książki są jakimiś tam uogólnieniami, czy nawet tylko spojrzeniem innych
osób na zagadnienie.

To, że wyrósł Pan z murarza moze być takze kolosalnym ograniczeniem w projektowaniu.

Człowiek jest w stanie robić skończoną ilość rzeczy w skończonym czasie, to na co nie ma czasu (zdobywac doświadczenia) znajduje w książkach. Jak słusznie Pan zauważył, książki są przede wszystkim innym spojrzeniem na tę samą rzecz. Nie musze napisać żadnego nawet programu, żeby dowiedzieć sie o ograniczeniach tego czy innego języka z książek lub z rozmowy z ekspertem programistą. Sztuką analizy i projektowania jest rozumienie tego jak zbudowany jest dom bez konieczności zbudowania ich kilku własnymi rękami.

A diabeł tkwi w szczegółach. Jak się nie zrobi jakiegoś systemu w jakiejś tam metodyce, to nie ma się pojęcia o czym się mówi.

Czyli większość architektów to brakoroby bo nigdy nie machali kielnią? Czy wie, Pan, że czołowi i najbogatsi kreatorzy mody nigdy nie byli krawcami? Są plastykami itp. za to potrafią zadawać pytania krawcom. Jak Pan poczyta mój profil to tam jest napisane, że jestem analitykiem a nie programiwstą, zgodnie z metodykami obiektowymi np. pokazaną w OMG, mało mnie obchodzi więc to nawet jakim językiem to coś zostanie zaprogramowane (nawet nie powinno mnie to obchodzić) wiec uwagi o progamowaniu kierowane do analiytka są raczej efektem małej wiedzy... osoby która je formułuje...

Nie należy, Panie Jarku, nikim gardzić. Poza tym najważniejsze, że zaczęli coś w tym rzeźbić. Poza tym rozumiem, że wielkie banki, ubezpieczalnie i wiele wiele innych instytucji też nie wiedzą co czynią. A z tego co widziałem i słyszałem, ponoć te nieuki z zagranicy im kazali ;)

A kto powiedział, że jak z zagranicy to zawsze mądrzejszy? Troszke wiary w siebie i patriotyzmu :) Nigdy Pan nie poprawiał po "gigantach z zagranicy" bo ja często. Ja nikim nie gardze, napisałem tylko, że jeżeli znają UML to super bo zrozumieją produkt który dostaną.

Wielkie banki to używają raczej w większości eEPC i ARISA a nie UML'a... (no te dla ktorych ja pracowałem a znam z polskich nie tylko PKO BP a z zagranicznych np. niemiecki WestLB). W bankach standardem biznesowym jest raczej ARIS jako narzędzie i eEPC jako notacja a nie UML (nie licząc działów IT). Ostatnio przekonują się zreszta do BPMN.

Po trzecie moje doświadczenie mówi, że wiele projektów analitycznych biznesowych powstało w UML tylko dlatego, ze zleceno je informatykom którzy po protu nie znali innej notacji. Z reguły były to nieudane niestety projekty.

UML powstał z myślą o modelowaniu oprogramowania. Na szczęście stereotypy pozwalają modelować również systemy informacyjne. Ponadto oprócz Pańskiego artykułu sprzed lat kilku (głosił Pan koniec ery use-cas'ów - ile lat jeszcze Pan daje tej notacji ?) nie słyszałem, by ktoś się naśmiewał z UML-a, aczkolwiek jest wiele narzekań ze względów jak wyżej.

Prosze czytać ze zrozumieniem, napisałem że obśmiewane są Use Case jako pierwotne narzędzie analizy a nie UML jako notacja. Sam używam UML jak narzędzia do dokumentowania analizy obiektowej. UML powstał do dokumentowania analizy obiektowej a między innymi rozszerzono go do projektowania oprogramowania. Co do stereotypów to owszem, ale po co wymyślać stereotypy w UML do modelwoania procesów biznesowych skoro sa lepsze narzędzia? Po drugie: wymyślanie stereotypów przez ludzi w projektach kończy się najczęściej tym, że: zrobili semantykę, zaniedbali syntaktykę a w ogóle nie mieli pojęcia i nie wzięli pod uwage semiotyki modelu (diagramu) dlatego właśnie UML nie nadaje się do modelowania elementów biznesowych w projektach (te pojęcia na s... to chyba Pan jako PW IT rozumie, w razie czego google). Tak wiec rozszerzanie UML stereotypami przez nie majacych pojęcia o teorii modelowania programistów do niczego dobrego nie prowadzi.
Wracjąc jednak do 4pi, to się trochę minęliśmy w UPRP. Aczkolwiek muszę powiedzieć, że to dzięki Panu bardziej zainteresowałem się BPMN-em. Przeglądając diagramiki (nie wiem, czy to Pan, czy AS to wytworzył - nie dopytywałem się) stwierdziłem, że ktoś zbyt abstrakcyjnie potraktował modelowanie biznesowe. I faktycznie. Ściągnięta dokumentacja z omg wskazywała, że jedna sprawa to radosna twórczość analityków, a druga to wymagane standardy, a trzecia to narzędzia, które czasem zupełnie nie odzwierciedlają jakichkolwiek standardów.

Nie wiem, o które diagramy chodzi więc nie potrafię odpowiedzieć, ich autorów się tam przewinęło nie mało... diagramy które ja robiłem miały pewne "wady techniczne" (np. konieczność sztucznego dzielenia na strony i podprocesy bo Visio pracuje tylko na stronach papieru) bo robione były w Visio (wymaganie 4pi na MS Office). Moje diagramy robiłem z pracownikami UPRP, którzy je akceptowali i rozumieli. Ich rozszerzanie (dekompozycja) nie doczekało mojej ręki ....

Z tą myślą pozdrawiam Pana i polecam pozbycia się pychy. Ta cecha bardzo przeszkadza w uczeniu się nowych rzeczy.

Daleki jestem od pychy, raczej zwracam uwagę na takie rzeczy: należy mieć pokorę do własnej wiedzy, nie należy wypowiadać sie o rzeczach, które się zna pobieżnie, nie należy traktować cudzych doświadczeń jako gorsze a tylko jako inne, zanim użyjemy słowa "powszechnie się używa" należy mieć wiedze nie o tym czy UMLa użyto w jakichś bankach a o tym jaki procent banków używa UML do opisu procesów biznesowych. Tak przy okazji to nie jest przypadek, ze OMG planuje włączenie diagramów BPMN jako metody modelowania procesów bizneswych. Diagramy czynności w UML nawet do pięt nie dorastają tej notacji. UML to nie panaceum na wszelkie diagramy choć zdaję sobie sprawę z tego, że dla człowika z młotkiem w ręku wszystko wygląda jak gwoździe.

Nowe rzeczy, jak każdy szanujący sie analityk, poznaje stale :)

Żeby nie było niejasności, nie atakuję Pana, szanuję Pana wiedze i doświadczenie, staram się tylko wskazać na to, ze różnice między nami także należy szanowac co ja czynię :).

Jako analityk na prawdę nie ubolewam nad tym, że nie programowałem (no kiedyś na studniach...) wiem zaś za to, że analizując funckojonalności nie mam ograniczeń jakie mają programiści czego nie raz doświadczyłem patrząc, jak łatwo można jednak zrobić rzeczy, które programiści początkowo określali jako niewykonywalne tylko dlatego że "nikt tak nigdy nie robił". Z drugiej strony nie produkuje niewykonywalnych wymagań bo konsultuje je stale (Agile modeling) także z programistami jeżeli tylko jest taka konieczność. W przeciwieństwie do wielu projektantów ja w czasie całej analizy śledzę rentownść projektu i nie wymyślam kosztownych i pracochłonnych wynalazków w programach będących tylko efektem zbyt szczegółowych analiz przedwdrożniowych.

Rzeby nie było niejasności, to nie uwaga do Pana bo nie widziałem Pana projektów.Jarosław Żeliński edytował(a) ten post dnia 14.09.07 o godzinie 14:47
Karol K.

Karol K. Specjalista

Temat: Modelowanie biznesowe, a analiza systemowa

Czy ktoś wie gdzie można znaleźć profesjonalne szkolenia z analizy biznesowej i systemowej?
Dzięki za informacje.
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Modelowanie biznesowe, a analiza systemowa

Karol K.:
Czy ktoś wie gdzie można znaleźć profesjonalne szkolenia z analizy biznesowej i systemowej?
Dzięki za informacje.

nieskromnie powiem, ze u mnie ;)
http://it-consulting.pl/autoinstalator/wordpress/semin...
Zbigniew Fałek

Zbigniew Fałek Dyrektor Generalny

Temat: Modelowanie biznesowe, a analiza systemowa

Karol K.:
Czy ktoś wie gdzie można znaleźć profesjonalne szkolenia z analizy biznesowej i systemowej?
Dzięki za informacje.

http://falcom.pl

Następna dyskusja:

Zapraszam na kurs" Modelowa...




Wyślij zaproszenie do