tag:blogger.com,1999:blog-5197374494377847819.post6015016113414601312..comments2024-03-22T22:13:46.650+01:00Comments on Holistycznie o inżynierii oprogramowania: Przyczyna czy skutek?Sławek Sobótkahttp://www.blogger.com/profile/15082577671795313109noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-5197374494377847819.post-28658595113491451402019-04-14T15:40:16.970+02:002019-04-14T15:40:16.970+02:00Jeżeli chodzi o samo zarządzanie procesami bizneso...Jeżeli chodzi o samo zarządzanie procesami biznesowymi, to warto jest je poddać szczegółowej analizie, podczas której identyfikowane są wszystkie nieefektywności i obszary wymagające poprawy. Właściciele firm często korzystają w tym celu z specjalistycznych usług konsultingowych - <a href="https://www.crowe.com/pl/services/konsulting/zarzadzanie-procesami" rel="nofollow">https://www.crowe.com/pl/services/konsulting/zarzadzanie-procesami</a>, które służą głównie wskazaniu efektywnych oraz optymalnych rozwiązań w oparciu o oszczędności kosztowe przedsiębiorstwa.Anna Grzelakhttps://www.blogger.com/profile/01996905216985000220noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-60070201725341160632013-10-23T23:37:07.900+02:002013-10-23T23:37:07.900+02:00Chodzi mi po głowie seria poświęcona specjalnym ha...Chodzi mi po głowie seria poświęcona specjalnym hakom w DDD, w tym właśnie o stosowalności. Jest to bardzo dużo, ale prowadząc po 2 szkolenia w tygodniu (z czego większość na temat DDD lub zbliżone) po prostu nie mam siły aby zebrać myśli wieczorem... ale może w lutym...:) Sławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-13182179081743059482013-10-23T22:57:38.729+02:002013-10-23T22:57:38.729+02:00Cisza, cisza, cisza. Czekam na wpis:)Cisza, cisza, cisza. Czekam na wpis:)Anonymoushttps://www.blogger.com/profile/03968505875451301931noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-74021803604838321582013-10-03T15:25:58.057+02:002013-10-03T15:25:58.057+02:00heh coś w tym jest:P
bo w sumie próbujemy zamodel...heh coś w tym jest:P<br /><br />bo w sumie próbujemy zamodelować rzeczywistość...<br /><br />ale podchodząc filozoficznie: być może nie ma czegoś takiego jak rzeczywistość, jest tylko narracja sprawozdawców...<br /><br />niektórzy mając mindest procesowy, guiowy, czy domenowy będą nam o niej opowiadać w specyficzny sposób ze specyficznymi zniekształceniami...Sławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-80632546544739484342013-10-03T15:04:31.412+02:002013-10-03T15:04:31.412+02:00inżynieria oprogramowania to filozofia xxi wieku.....inżynieria oprogramowania to filozofia xxi wieku...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-37215406504873823252013-10-03T11:49:07.861+02:002013-10-03T11:49:07.861+02:00@Marcin
Jarek już odpowiedział. W sumie nic nowego...@Marcin<br />Jarek już odpowiedział. W sumie nic nowego nie dodam, jedynie powtórzę to samo swoimi słowami:<br /><br />W jakim celu organizacje standaryzują procesy? Odnosząc się do modelu kompetencji http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition niedoświadczeni pracownicy potrzebują procesów. Jeżeli organizacja ma dużą rotację pracowników to tym bardziej. Natomiast eksperci wiedzą "o co tak na prawdę chodzi w głębokich regułach" a proces, to jedynie jakaś "projekcja" ich wiedzy na potrzeby początkujących.<br /><br /><br />"Czy jest możliwy proces biznesowy trudny do wykonania przy użyciu modelu?"<br /><br />W takim razie coś nie nie tak z modelem - nie odpowiada rzeczywistości biznesu. Albo procesem - ktoś "majstruje w matrixie";)<br /><br />Wydaje się, że z Twojej wypowiedzi wynika, że model jest rozumiany jako struktury danych wspierające proces. Może tak być, ale to już nie będzie model w sensie DDD.<br /><br />"Nie wydaje mi się, aby DDD narzucała nam metodologię odkrywania modelu. Można dokonywać tego od zewnątrz lub od wewnątrz."<br />Jeżeli DDD tratować jedynie jako zestaw Building Blocks (i najlepszych praktyk ich tworzenia) to tak. Ale jeżeli przyjrzeć się oficjalnemu procesowi Modeling Whirlpool http://domainlanguage.com/ddd/whirlpool/ i dosłownie potraktować nazwę Domain DRIVEN to zaczynamy od domeny.<br /><br />Ale to wszystko oczywiście na pierwszych 2 poziomach Dreyfus, gdzie szukamy mechanicznej procedury postępowania. Natomiast mózg biegłego modelarza pewnie robi obie rzeczy (proces, domena) równolegle.<br /><br />Sławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-16024174367159996522013-10-03T11:14:52.021+02:002013-10-03T11:14:52.021+02:00"Moim skromnym osobistym zdaniem model wynika..."Moim skromnym osobistym zdaniem model wynika z przypadków użycia"<br /><br />moim zdaniem nie, przypadki użycia nie kształtują narzędzi, se "tylko tym co można z ich pomocą zrobić".<br /><br />Metafora z bilardem Fowlera to doskonale pokazuje: kule przemieszczają się zgodnie z prawami fizyki a nie na żądanie gracza. <br /><br />Przypadki użycia to etap analizy i projektowania, to życzenia usera, powszechne nazywanie ich "pobożnymi życzeniami" nie jest przypadkiem. Jeżeli user poprzestanie na opisie swojego celu to jeszcze ok, ale już "user story" z ust usera to nie raz "bilard w stanie nieważkości". <br /><br />Po drugie przypadki użycia nie zawierają żadnej informacji o "algorytmach" więc jakim cudem mają posłużyć do modelowani dziedziny? Moim zdaniem najpierw muszę zrozumieć czym jest stół bilardowy i kule, by mieć podstawy do projektowania "scenariuszy" i przy okazji weryfikowania ich realizowalności.<br /><br />Jeżeli model dziedzinowy jest poprawny, to każdy model realnego procesu jest łatwy do zamodelowania i sprawdzenia.ToJaJarekhttps://www.blogger.com/profile/07492446399792666065noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-61420462174440451222013-10-02T22:26:02.656+02:002013-10-02T22:26:02.656+02:00Czy jest możliwy proces biznesowy trudny do wykona...<br />Czy jest możliwy proces biznesowy trudny do wykonania przy użyciu modelu? Zapewne tak. W takim przypadku, czy nasz model ("odkryty" inside-out), wiernie oddaje rzeczywistość przedsiębiorstwa? Raczej nie. Innymi słowy, czy nasza domena po prostu istnieje i potem "upychamy" ja w procesy, czy tez procesy (lub tez przypadku użycia) kształtują nasz model?<br /><br />Moim skromnym osobistym zdaniem model wynika z przypadków użycia, odkrywany od zewnątrz. Nie będzie on starać się wspierać hipotetycznych przypadków lub tych "na zaś". Będzie on odwzorowywać dokładnie to, co jest od systemu wymagane (i te problemy które system ma rozwiązać)<br /><br />Nie wydaje mi się, aby DDD narzucała nam metodologię odkrywania modelu. Można dokonywać tego od zewnątrz lub od wewnątrz. Wybór należy do ciebie :)Marcin Gryszkohttps://www.blogger.com/profile/01484444354209264861noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-84085479271855251452013-10-02T09:52:57.855+02:002013-10-02T09:52:57.855+02:00:)
spotykam się czasami z opinią, że "niektór...:)<br />spotykam się czasami z opinią, że "niektórzy konsultanci" od modelowania procesów niczego nie modelują ale "kręcą film" chodząc po firmie. Innymi słowy nie mając pojęcia "dlaczego akurat tak" zapisują jakiś zaistniały scenariusz. <br /><br />Tak na prawdę ludzi ograniczają w ich działaniach wewnętrzne regulaminy oraz posiadane umiejętności. Proces jaki zajdzie jest skutkiem. Owszem Warto go "modelować" by takie skutki oceniać i ewentualnie "uszczelniać" ale nie jest to żaden "mechanizm funkcjonowania". <br /><br />Jak na tym tle wygląda User Story z ust usera? Tak samo jak proces: to postrzegany skutek a nie przyczyna.<br /><br />Od pewnego czasu, gdy chce zrozumieć (analiza i model) organizację, robię jej model obiektowy (procesowy też ale później, służy do testowanie modelu obiektowego). I tu właśnie pokazuje się potęga DDD: dziedzina systemu to nic innego jak fragment (zakres projektu) modelu danej organizacji. Mając model obiektowy, na bazie wzorców DDD, danej firmy oraz mając (najważniejszy!) model przypadków użycia robimy selekcję: które elementy modelu dziedziny będą realizowane przez system a które pozostaną poza nim. Ale całość MUSI nadal "trzymać się kupy". Wtedy np. FabrykaFaktur wejdzie w zakres projektu (system ma wystwiać faktury) ale np. Usługa "wylicz podatek VAT" pozostanie poza zakresem (zostaje przyporządkowana do aktora, to nadal jego wymagana umiejętność i wiedza). Owszem to prosty system ale jednak. <br /><br />Dlatego DDD (nie raz stosuję prostszy model BCE, bo niewprawny biznes łatwiej go przyjmuje ;)) to kluczowe narzędzie na etapie analizy problemu i określania zakresu projektu. Ten model powinien 1:1 wejść do implementacji jako Domain Model.ToJaJarekhttps://www.blogger.com/profile/07492446399792666065noreply@blogger.com