Inżynieria systemów oparta na modelach (MBSE) jest sformalizowaną metodologią, która jest używana do wspierania wymagań, projektowania, analizy, weryfikacji i walidacji związanych z rozwojem złożonych systemów. W przeciwieństwie do inżynierii skoncentrowanej na dokumentach, MBSE stawia modele w centrum projektowania systemu. Zwiększone przyjęcie środowisk modelowania cyfrowego w ciągu ostatnich kilku lat doprowadziło do zwiększonego przyjęcia MBSE. W styczniu 2020 roku NASA odnotowała ten trend, informując, że MBSE “jest coraz częściej przyjmowane zarówno przez przemysł, jak i rząd jako sposób na śledzenie złożoności systemu.” W tym wpisie na blogu przedstawiam krótkie wprowadzenie do MBSE.
Książka Business Analyst?s Mentor Book mile mnie zaskoczyła. Dość często spotykam się z polecaniem książki Business Analysis, którą ja niestety raczej odradzam z uwagi na bardzo mechaniczne, uproszczone porady a nie raz wręcz fałszywe. Ta książka zaś, dla odmiany, nie skupia się na narzędziach (to nie jest lista porad w rodzaju "w celu ... zrób to ... używając tego...) bo nie da się żadnej analizy sprowadzić do procedury. Ta książka to praktyczne, rzetelne rady i dobre praktyki. Autorzy zwracają uwag na to, że analiza i projektowanie (no bo czym są rekomendacje…
Dzisiaj będzie bardzo krótki wpis, którym niemalże w całości będzie cytat z artykułu pewnego programisty. Każdy analityk i projektant powinien przeczytać cały artykuł (nie jest długi) i koniecznie komentarze pod nim. Jeden komentarz zacytuje bo jest znamienny, choćby dlatego, że moje doświadczenia są dokładnie takie same: Co Ty człowieku, życia nie znasz? Przecież w realu jakbyś poszedł do takiego i podzielił się takimi uwagami to foch na pare tygodni co najmniej gwarantowany. Kiedyś miałem podobną sytuację (a raczej serię sytuacji, ale dotyczących rzeczy o mniejszej skali) to efekt był taki,…
Tym razem małe "case study". Poniżej opis , tak wygląda większość mich projektów. Najczęściej mam kontakt z firmami, które przekonały się, że zawarcie umowy od razu na analizę wymagań i realizację projektu bez projektowania, i to w dodatku jako umowę T&M (czas i materiał) rodzi problemy. Prezes EXTREM, lubi zadawać wiele pytań, miał doświadczenie z poprzedniego wdrożenia (w zasadzie nie doprowadzonego nigdy do końca): Firma EXTREM w 2013 roku rozpoczęła proces wyszukiwania na rynku oprogramowania CRM i jego dostawcy. W toku prowadzanych prezentacji okazało się, że oferty różnią się od…
Równo 10 lat temu (wtedy to na full time stałem się niezależną jednoosobową firma analityczną) napisałem: Decyzja o wdrożeniu jakiegokolwiek systemu informatycznego wspierającego działalność firmy wymaga oceny zasadności takiego projektu oraz wskazaniu obszarów działalności firmy, które zyskają na takim wdrożeniu. Bardzo często popełnianym błędem jest rozpoczęcie rozważań dotyczących potrzeby i możliwości wdrożenia konkretnej aplikacji. Jest to dość typowe działania inicjowane najczęściej złożeniem oferty przez dostawcę aplikacji a nie raz także znalezieniem reklamy danego produktu obiecującej poprawę funkcjonowania firmy w wyniku li tylko wdrożenia oferowanego rozwiązania. Dlaczego to jest błąd? Odpowiedź…
Dbałość o jednoznaczność i spójność dokumentacji to kluczowa cecha analityka, pisałem o tym między innymi w artykule o tępieniu niejednoznaczności. Uznawanie, że to nie ważne, dopuszczanie do nieprecyzyjnych definicji, uznawanie pewnych pojęcia za bliskoznaczne czy wręcz synonimy, prowadzi do nie tylko do emocji w rozmowach ale to nieprzydatności tworzonych dokumentów.
Tak więc brak (umiejętności) stosowania abstrakcji w modelowaniu czyni te i inne modele (schematy blokowe) nieczytelnymi, trudnymi do interpretacji, kosztownymi w wytworzeniu i utrzymaniu. To ostatnie powoduje, że większość takich dokumentów szybko kończy życie na półkach, bo dezaktualizują się jak tylko dojdzie do jakiejkolwiek, nawet najdrobniejszej, zmiany w organizacji. Co ciekawe, biorąc pod uwagę czas trwania przeciętnego wdrożenia oprogramowania, taki zbyt szczegółowy model nie ma szans być przydatnym w toku takiego projektu, tu rację mają developerzy, którzy twierdzą, że im takie dokumenty im w niczym nie pomagają.
Tak więc modele procesów, w których pojawiają się tory reprezentujące jakiekolwiek oprogramowanie gwałcą tę podstawową zasadę: organizacja to celowe działanie ludzi, narzędzia im w tym tylko pomagają, narzędzia nie są istotą działania organizacji. Można to sprawdzić czymś co ja nazywam testem wyłączenia zasilania: czy wyłączenie automatów pozbawi organizację sensu jej istnienia? Jeżeli nie to znaczy, że automaty nie pełnią ról w procesach, a są jedynie narzędziami w rękach ludzi. Narzędzi nie umieszczamy więc w modelach procesów.
Mój niedawny referat na temat trendów w wyborze i wdrażaniu systemów workflow i zaproszenie na kolejną konferencję z tego zakresu, skłoniły mnie do przerzucenia ciężaru referatu z istoty przepływu dokumentów, na przepływ dokumentów w kontekście wdrożenia narzędzia. które w tym pomaga. Poniżej prezentacja ilustrująca referat: http://www.slideshare.net/zelinski/zarzdzanie-informacj-i-automatyzacja-procesw-biznesowych-40106919 Na koniec tego krótkiego wpisu dodam, że w swej głównej części, system obiegu dokumentów to jeden przypadek użycia. (referat był wygłoszony na konferencji EOIF GigaCon, 9 Października 2014 we Wrocławiu).
Autor prezentuje podejście, które nazywam podejściem "opartym na danych". Co mam na myśli? Otóż podejście to zakłada, że istotą "systemu" jakim jest organizacja są gromadzona i zarządzane dane (wiedza). Inne podejście, nazwę je operacyjne (lub procesowe), zakłada że istotą organizacje jest odgrywanie określonej roli na rynku (dostawca produktów, usługodawca, itp.). Innymi słowy istotne jest to co potrafię zaoferować a nie to jakimi danymi dysponuję.
Warstwa procesów, usług aplikacyjnych/przypadków użycia i komponentów to odrębne warstwy i perspektywy. Nie mieszamy więc ani poziomów abstrakcji ani perspektyw modeli. W przeciwnym razie, ulegając sugestiom w rodzaju "ale ja chcę zobaczyć to wszystko na jednym diagramie" pchamy projekt w kierunku "utraty panowania nad złożonością"... To prosta droga do klęski projektu.
Analizy biznesowe wymagają oderwania się od technokracji, nie ma czegoś takiego jak dziesiątki przypadków użycia dla jednej faktury, nie ma systemowych przypadków użycia (nawet w specyfikacji UML ich nie znajdziecie), są kompletne (dające jako efekt przydatne produkty) usługi aplikacyjne i korzystający z tych usług aktorzy, w tym inne aplikacje lub komponenty. Dokumentacje zawierające setki przypadków użycia to nieporozumienie, technokratyczni zabójcy projektów. Warto się zastanowić zanim powierzycie analizę i projekt logiki systemu technokratycznemu developerowi...
Ta konferencja przekonała mnie, że w sumie to jestem zwinny, bo: moje umowy mają zakres i harmonogram, praca jest iteracyjna, całość bazuje na wizji, opisuję jak stwierdzimy, że wykonałem swoją prace... a specyfikacje wymagań jakie opracowuję, mają nie setki i tysiące pozycji, a góra kilkadziesiąt.