Inżynieria wymagań ? model tego co chcemy

Niedawno mój serdeczny kolega napisał: Samo zebranie wymagań to ważny etap. Schody zaczynają się jednak dalej. Trzeba zweryfikować pozyskane wymagania, uszczegółowić, nadać priorytety. Gdzie te schody? [...] Nie mamy w Polsce standardu dokumentowania projektów. Czegoś na co można się powołać. (Inżynieria wymagań ? certyfikat | Michał Wolski). jak to mówią "święte słowa". Jednak mamy standard dokumentowania wymagań, który można wykorzystać. Jaki? Moje początkowe opory do stosowania "kolejnej notacji" były jednak chyba przesadzone. SysML to obiektowe (w sensie paradygmatu) rozszerzenie UML. Pomijając kwestie samej notacji, jeden z jej diagramów, diagram wymagań, pozwala…

Czytaj dalejInżynieria wymagań ? model tego co chcemy

Ile tego ma być … analiza i model procesów biznesowych

Tak więc analiza organizacji i opracowanie jej modelu to trudna, praca, nie raz długa, ale nie powinny to opasłe księgi. Dobry model organizacji to właśnie broszurka, która odpowiada na pytanie "dlaczego". Jeżeli wynikiem analizy są opasłe księgi to znaczy, że mamy jedynie dziesiątki nagrań kolejnych partii szachów a nie reguły tej gry... a wtedy nadal nie wiemy "dlaczego". Co ciekawe, każda organizacja ma, lub powinna mieć, taką instrukcję: jest to lista stanowisk (struktura organizacyjna) i reguły gry w postaci wewnętrznych zarządzań i procedur. Ale powinna ona być spójna i kompletna. Przypomnę, że każda organizacja jakoś funkcjonuje, a mało która ma mapy procesów biznesowych. Po co więc te modele procesów? Wróćmy do wspomnianej na początku "piramidy". Jej szczyt to cele, model biznesowy: chcemy grać w szachy i wygrywać. Jej najniższa warstwa to figury i reguły gry. Czym jest środkowa warstwa, czym są te modele procesów biznesowych? Dobry szachista ma pewne z góry przewidziane scenariusze, są to "gotowe" rozwiązania na pewne powtarzająca się sytuacje na szachownicy. One oczywiście nie są w stanie zastąpić szachisty, ale bardzo ułatwiają mu grę, raz przećwiczone i uznane za "dobre" i skuteczne scenariusze, stosuje zawsze gdy napotka "standardową sytuację". Organizacje także je mają, to właśnie procesy biznesowe, ale nie jest to recepta na pracę firmy, takiej nie jesteśmy w stanie stworzyć. Procesy biznesowe, te udokumentowane by służyły firmie, to wszystkie te przewidywalne, powtarzające się scenariusze, które stanowią tak na prawdę nasze organizacyjne know-how. Cała reszta to kompetencje naszych pracowników a tych nie modelujemy, z nich korzystamy.

Czytaj dalejIle tego ma być … analiza i model procesów biznesowych

Semiotyka – czyli dlaczego sama notacja to za mało

Tym razem krótki wpis po pewnym spotkaniu projektowym, dla tworzących i czytających diagramy: Semiotyka, ogólna teoria znaku związana z logiką i lingwistyką. Jej współczesna postać pochodzi od Ch. Morrisa, który uznał, że semiotyka powinna stanowić podstawę badań nad związkami między wszelkimi działaniami ludzkimi i ich odzwierciedleniem w systemie znaków. Semiotyka dzieli się na:1) semantykę (w węższym sensie), czyli naukę o znaczeniowej stronie języka, o tym, jakie relacje zachodzą między znakami i ich znaczeniem (sensem).2) syntaktykę rozpatrującą związki zachodzące między znakami i między systemami znaków.3) pragmatykę badającą warunki użycia określonych znaków.(za Semiotyka…

Czytaj dalejSemiotyka – czyli dlaczego sama notacja to za mało

Business Model Canvas vs. Business Motivation Model

Jak widać, "klasyczny" model biznesowy pokazuje tylko "co jest przedmiotem działalności i kluczowym źródłem zysku". Model taki jest modelem procesu, ten proces jednak to tylko opis tego co, jaką wartość dodaną, dana organizacja dostarcza swoim klientom i gdzie się zaopatruje. Model to-Be opisuje stan pożądany, nie daje żadnej wiedzy o tym, jak do niego dojść. Model As-is i To-be ma lukę pomiędzy tymi As-Is i To-be. Tę lukę wypełnia moim zdaniem kompletny model BMM - każe "opracować" strategię, taktykę, analizę SWOT, ryzyka i inne mające wpływ na osiągnięcie celu, a nawet na to czy jest on w ogóle osiągalny. Po co to wszystko? Bo dobra analiza, powinna być sama dla siebie dowodem słuszności jej wyników (dlatego nie raz tu napisałem, że powinna być prowadzona "metodą naukową").

Czytaj dalejBusiness Model Canvas vs. Business Motivation Model

Rachunek kosztów działań ABC ? model procesu niezbędny

O procesach biznesowych i ich modelowaniu napisano już wiele, jednak w większości przypadków pisze się o tym w kontekście albo wdrożeń systemów IT albo w kontekście reorganizacji. Jakiś czas temu znalazłem się na konferencji związanej z zarządzaniem kontrolingiem i finansami. Usłyszałem coś co mnie nieco i zdziwiło, pewna pani zajmująca się właśnie metodami kontrolingu, w swoim referacie, zwróciła uwagę na dziwne jej zdaniem zjawisko: bardzo wiele firm wdraża metody zarządzania kosztami działań nie mając modelu procesów biznesowych, czy to nie jest wróżenie z fusów, zapytała? Czym jest zarządzanie kosztami działań albo inaczej, na czym polega metoda ABC ([[Activity Based…

Czytaj dalejRachunek kosztów działań ABC ? model procesu niezbędny

Bo najważniejsi Panie są Aktorzy…

Bardzo często spotykam się z projektami, w których użytkownicy narzekają na dostawcę oprogramowania, uważają że program nie całkiem spełnia ich oczekiwania (wymagania podpisali... ale to nie rozwiązuje tego problemu). Problem polega na często spotykanym podejściu: analiza wymagań tylko w postaci wywiadów i w konsekwencji niepełne zrozumienie specyfiki biznesowej oraz fakt, że developer ma skłonności do uproszczeń i "normalizacji". Innym, moim zdaniem jeszcze gorszym podejściem, jest rozpoczęcie kodowania jeszcze w trakcie trwania wywiadów i tworzenie oprogramowania metodą codziennych, lub co tygodniowych spotkań z użytkownikiem opisującym kolejne aspekty systemu. Zbyt późne odkrywanie (a nie raz nawet niedostrzeganie tego), tego że pewne rzeczy są 'tymi samymi rzeczami" ale w innych kontekstach, prowadzi do bardzo wielu problemów z implementacją. Ale po kolei.

Czytaj dalejBo najważniejsi Panie są Aktorzy…

Wojna handlowa

Wpadł mi w ręce, jakiś czas temu, krótki artykuł na temat [[rynku FMCG]]. Pomijając "nieczyste" praktyki reklamy porównawczej, pokazuje jaka arogancja panuje w świecie korporacji i "dużych firm", którym się wydaje, że duży może więcej. Pogoń za zyskiem, pozbawiona nie tylko rozsądku ale także krzty etyki,  objawia się między innymi takimi próbami szantażu: To jednak także efekt zapędzenia się przez branżę handlową w kozi róg. Bo wiadomo: klienci chcą kupować tanio. A sklepy chcą im to zapewnić. (za Wojna handlowa: Kaufland wyrzucił Danone ze sklepów). W pewnym sensie cieszą mnie…

Czytaj dalejWojna handlowa

CQRS czyli kto, co i jak zamawia i dostarcza

Opisując wymagania wyłącznie jako "czarną skrzynkę" nie wiem co dostanę. Większość developerów będzie dążyło do uproszczenia implementacji (ich koszt, nie raz brak wiedzy) by zaspokoić na minimalnym poziomie wymagania opisane przypadkami użycia. Nie raz klient słyszy "tu musimy to uprościć bo tak się nie da", a zamawiający, nie mając kompetencji by polemizować z taką opinią, zgadza się i dostarczony system staje się zgniłym kompromisem opartym właśnie na "czarnej skrzynce" jako specyfikacji zamówień: "dostaliśmy dokładnie to co zamówiliśmy ale zupełnie nie to czego naprawdę potrzebujemy". Tak więc, nie ma znaczenia fakt, że na pewno są na rynku developerzy znający problem, który opisałem i stosujący opisane tu rozwiązanie takich problemów. Jednak nawet cień ryzyka (a jest ono na prawdę duże), że dostaniemy bubla, daje zamawiającemu prawo do szczegółowego definiowania wymagań jako "białej skrzynki", bo dzięki temu zamawiający dostanie "to czego potrzebuje a nie tylko to co zamówił".

Czytaj dalejCQRS czyli kto, co i jak zamawia i dostarcza

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 dalejWzorzec analityczny Boundary Control Entity i ICONIX a także MVC i MVVM

Kim więc jest dobry analityk?

Skoro logikę biznesową "programuje się" (implementuje się) z użyciem obiektowych wzorców projektowych, to ideałem było by wskazać te wzorce, które wg. najlepszych praktyk są wykorzystywane do implementacji logiki biznesowej i uczynić z nich "klocki", na które należy, na etapie analizy biznesowej, rozłożyć problem. To się np. nazywa DDD czyli siedem wzorców spośród wielu. Korzyści są ogromne, bo "wycinamy" etap głuchego telefonu między Zamawiającym i wymaganiami w postaci prozy i tabel a developerem, który ma zrobić obiektowy model czegoś czego tak na prawdę nie rozumie, a opis prozą jest niestety bardzo niejednoznaczny i podatny na przekłamania (głuchy telefon).

Czytaj dalejKim więc jest dobry analityk?

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 dalejPoziomy szczegółowości wymagań – wzorce DDD – czyli czym jest analiza obiektowa

Nie każdy współpracujący system to Aktor – czyli jak opisać wymagane interfejsy

To jest to co zrozumie Klient, najprostszy diagram do pokazania, zawiera zakres projektu, granice systemu (najważniejsza rzecz) i aktorów (część różowa tylko dla lepszego zrozumienia treści artykułu). Inny System, jeżeli inicjuje akcję czyli żąda usługi także jest aktorem, ale System realizujący na nasze zlecenie jakieś usługi nie jest aktorem, jest tylko wywoływany, sam z siebie nie inicjuje żadnej akcji. On realizuje jakąś potrzebną nam funkcję. Może się okazać, że Zewnętrzny system ma zarówno interfejs oferowany jak i wymagany, wtedy w projekcie, na diagramie przypadków użycia, warto operować nie nazwą zewnętrznego systemu (np. ERP który może mieć dziesiątki interfejsów oferowanych i wymaganych) a nazwą usługi (interfejs oferowany) lub zdarzenia (interfejs wymagany) będących przedmiotem takich akcji i zakresu projektu. Diagram przypadków użycia to pierwszy test zrozumienia tego co i po co ma powstać. Jest to bardzo prosty diagram i dlatego każde uproszczenie lub niezrozumienie, prowadzi nie raz do poważnych nieporozumień a bywa, że do krachu projektu. To bardzo ważny diagram. Powie nam do czego Systemy Projektowany będzie używany, to cel sponsora. Na tej podstawie można wybrać gotowe oprogramowanie i testując je ocenić przydatność (nie radze wybierać gotowego oprogramowania na bazie prezentacji!). Ale diagram ten nigdy nie powie jaką logikę należy zaimplementować, dlatego w przypadku tworzenia oprogramowania konieczny jest jego projekt: model dziedziny systemu, jako kolejny etap projektu na oprogramowanie dedykowane. Przypomnę także, że przypadki użycia w wersji minimalnej powinny mieć opis: cel jego użycia (co Aktor chce osiągnąć) stan początkowy (wejście, dane wejściowe, itp.) stan końcowy (wyjście, dane wyjściowe itp.) Tu zwracam uwagę, że powyższe to zarazem testy akceptacyjne otrzymanego oprogramowania.

Czytaj dalejNie każdy współpracujący system to Aktor – czyli jak opisać wymagane interfejsy

Koniec treści

Nie ma więcej stron do załadowania