Poziomy modelowania procesów

Modne ostatnio projekty modelowania procesów biznesowych z reguły, jako produkt, dostarczają niezliczone ilości “map procesów”, które kończą swój żywot na zakurzonych z czasem półkach, powstawały zbyt dużym kosztem by je wyrzucić do kosza. Ich stałe utrzymanie (aktualizacja) nie raz bywa kosztowniejsze od wytworzenia. […] jeżeli uznamy, że jedynym powodem prowadzenia projektów jest usprawnianie określonych procesów biznesowych, to znaczy, że uruchamianie tych projektów bez wiedzy, które to dokładnie procesy i bez pełnego zrozumienia ich wpływu na organizację, projektów tych nie należy rozpoczynać.

Czytaj dalej Poziomy modelowania procesów

Analiza wymagań – zrozumienie

Dzisiaj krótki artykuł o wymaganiach dziedzinowych. W jednym z poprzednich artykułów pisałem o wymaganiach, że problem tkwi w ich zrozumieniu i o tym, że przyszły użytkownik nie powinien pisać "jaki…

Czytaj dalej Analiza wymagań – zrozumienie

Polski rynek MSP z małym żalem…

W wielu polskich firmach zarządy są – wbrew temu co sami o sobie myślą – bardzo słabe. Wyposażenie handlowca to wynik żądań handlowca a nie realnych potrzeb jego sponsora. Drogi samochód i wydatki na paliwo porównywalne z comiesięczną ratą leasingową na ten samochód, z reguły wygrywają z oprogramowaniem wspomagającym zarządzanie, z bardzo prostego powodu: samochód widać gołym okiem a wydatki na paliwo “świadczą o tym, że handlowiec ciężko pracuje”, oprogramowanie (15EUR za licencje miesięcznie to tylko 60zł kosztów na osobę!) z “gatunku” CRM nie przynosi żadnych korzyści handlowcom nastawianym na “dojenie pracodawcy” i żadnych korzyści właścicielom firm, których jedyna wiedza o sprzedaży zamyka się na tezie “trzeba być u klientów i sprzedawać”.

Czytaj dalej Polski rynek MSP z małym żalem…

O narzędziach CASE – rzadko ale jednak piszę

Prawdę mówiąc "zabraniam" przynoszenia komputerów na moje szkolenia, wymagam papieru i ołówka. Powody są dwa: Narzędzia CASE pomagają tylko wtedy gdy diagramów jest wiele i model jest złożony, na szkoleniach takich modeli się…

Czytaj dalej O narzędziach CASE – rzadko ale jednak piszę

Wzorzec analityczny Boundary Control Entity i ICONIX a także MVC i MVVM

Opisywałem ostatnio wzorzec DDD jako narzędzie dokumentowania analizy. Faktycznie, czytelnicy mają wiele racji, jest on dość “bliski implementacji”. Niejednokrotnie “lepszym pomysłem” jest opis logiki systemu na nieco wyższym poziomie abstrakcji pozostawiając tym samym więcej swobody developerowi. […] Nieco inne podejście, to które stosuję obecnie, opisuję poniżej. Zachowując podstawowe znaczenia tych trzech klas, dostosowałem je do wzorca MVVC. Jest to o tyle wygodne i ważne, że stosowanie wzorca BCE wyłącznie do modelowania logiki biznesowej wymaga zachowania hermetyzacji komponentu Model. W takim układzie boundary nie będzie elementem komponentu View a Modelu. Jego rola to stworzenie dedykowanego interfejsu do model np. pomiędzy komponentem View lub Controlerem. Dzięki temu możliwe jest stworzenie odrębnego interfejsu dla View na duży ekran i odrębnego dla View na np. małych ekranach smartfonów. Tak więc jest moim zdaniem droga do modelowania wymagań metodą “tak to ma działać” a nie tylko “tak to ma wyglądać”, bo to drugie jest przyczyną wielu problemów…

Czytaj dalej Wzorzec analityczny Boundary Control Entity i ICONIX a także MVC i MVVM

Poziomy szczegółowości wymagań – wzorce DDD – czyli czym jest analiza obiektowa

Kim więc jest dobry analityk?

Jest to projektant, który potrafi analizowaną organizację “rozłożyć na elementy składowe”. Tymi elementami są wzorce projektowe, elementy stosowanej notacji. Wynik analizy to nie “rysunek”. Jest modelem w postaci schematu blokowego (diagramu), na którym każdy element ma ściśle określone znacznie, konstrukcję i zasady wzajemnego łączenia.

Analiza Biznesowa to rozłożenie analizowanego “przedmiotu” na skończony zestaw elementów, który z określoną dokładnością zachowuje się jak analizowana organizacja. Jeżeli te elementy składowe mają także swoje odwzorowanie w kodzie programu, to wynik analizy staje się projektem tego oprogramowania.

Poziomy szczegółowości wymagań to:

cele biznesowe (produkty procesów biznesowych)
opis usług żądanych od oprogramowania (tu także formatki papierowe/ekranowe, przypadki użycia oprogramowania)
opis (projekt) wewnętrznej logiki biznesowej (wewnętrzne elementy składowe i scenariusze ich współdziałania)

Czytaj dalej Poziomy szczegółowości wymagań – wzorce DDD – czyli czym jest analiza obiektowa