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

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…

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

Business Model vs. System Model

Swego czasu pisałem o tym, że np. klasa przechowująca informacje o pracowniku raczej powinna nazywać się DaneOPracowniku a nie Pracownik. Dlaczego? Bo projekt systemu zawierający informacje o pracownikach i klientach, a także treść wielu dokumentów, powinien pozwalać zrozumieć co jest "w systemie" a co w "rzeczywistości" (pracownik jest żywym organizmem, oprogramowanie co najwyżej zarządza danymi opisującymi tego pracownika). Ku mojemu zaskoczeniu ale także radości, niemalże ten sam problem poruszył Ron Ross (bloger i autor książki BUILDING BUSINESS SOLUTIONS: Business Analysis with Business Rules): To make a long story short, business models talk directly about real-world things (as business people do);…

Czytaj dalejBusiness Model vs. System Model

Czym jest jakość oprogramowania… a może od czego ona zależy?

Coraz częściej utożsamiam analizę z projektem gdyż w sumie produktem analizy jest jakiś projekt czyli model tego co analizowano, model tego co rekomenduję by powstało. Analiza sama z siebie nie jest samowystarczalna (to znaczy samo analizowanie nie jest wartościowym produktem samym w sobie). Problemy z projektami obserwuje nie ja jeden. W każdym kolejnym projekcie staram się szukać przyczyn, zrozumieć problem i podjąć próbę rozwiązania. Problem w zasadzie jest znany. [...] Dalej mamy same dobre rady, z którymi trudno polemizować: Wysoka modularność, współpraca wielu niezależnych, lub luźno powiązanych elementów, możliwość wymiany małych części, lub tworzenie różnych wariantów tego samego modułu, to podejścia, które przyniosą nam wartość dodaną. Ludzie mający do czynienia z monolitami (układ: jedna wielka baza danych i do tego wielki serwer aplikacyjny) z reguły postrzegają podejście rozproszone (dziesiątki lub setki małych kawałków fruwających gdzieś w koło) jako trudniejsze, bardziej skomplikowane i przez to gorsze i bardziej ryzykowne. Takie spojrzenie to postawienie sprawy do góry nogami. I tu moim zdaniem autor ma 100% racji. Nie ma chyba nic gorszego niż uznanie, że "jeden wielki zintegrowany system" to zaleta tego Systemu, jest to jego największa wada.

Czytaj dalejCzym jest jakość oprogramowania… a może od czego ona zależy?

Model jako symulacja – także w analizie i projektowaniu oprogramowania

Model dziedziny nie powinien więc być diagramem słownikowym (diagram klas z gęsto powiązanymi klasami nafaszerowany dziedziczeniem i asocjacjami). Taki diagram to model pojęciowy (pojęcia słownikowe) nie nadający się do implementacji. Wymaga jeszcze wiele pracy. Jeżeli skażemy na nią programistę, osobę która nie zna tej "dziedziny", to z dużym prawdopodobieństwem powstanie "coś co nie koniecznie jest tym czymś co powinno powstać", i nie jest to wina tego programisty tylko tego, który mu dał opis tego co ma powstać w takiej właśnie, niezdefiniowanej postaci. [...] Tak więc szanowni klienci: sprawdzajcie co Wam dają analitycy, jeżeli model dziedziny systemu jest dla Was totalnie nie zrozumiały (to co mówi lub referuje analityk), to prawdopodobnie jest to zły model... Tak więc model dziedziny opisujący sprzedaż, powinien zawierać obiekt biznesowy Faktura ale obiekt ten nie powinien mieć operacji "nowa faktura", model powinien zawierać odrębny obiekt np. NarzędzieFakturzysty, mający "w sobie" wiedzę o tym jak się wystawia faktury. Powody są dwa: techniczny opisał powyżej kolega programista, drugi powód jest bardzo prozaiczny: bo faktury same się nigdzie nie wystawiają...

Czytaj dalejModel jako symulacja – także w analizie i projektowaniu oprogramowania

Krótki wpis o śladowaniu

Dobrze opracowany, kompletny model organizacji, łączy w sobie: model motywacji biznesowej, [[model struktury organizacyjnej]], model procesów biznesowych (wymieniony już powyżej), model reguł biznesowych. Elementy każdego z tych modeli są ze sobą powiązane: role w procesach są wywodzone ze stanowisk w modelu organizacyjnym, analizowane procesy są wywodzone z modelu motywacji, reguły biznesowe są kojarzone z czynnościami w procesach i wywodzone z aktów prawnych i wewnętrznych zarządzeń. Mając tak opracowany kompletny model organizacji, zawierający śladowanie, i odpowiednie oprogramowanie CASE można przeprowadzić analizę oddziaływania, np. sprawdzić na jakie osoby w organizacji przeniesie się zmiana wybranych reguł biznesowych. Mając model systemu informatycznego skojarzony z procesami, można sprawdzić wpływ awarii poszczególnych podsystemów na procesy biznesowe i ich skutki dla firmy. Takich analiz można wykonać wiele, nie było by to możliwe bez tak skonstruowanego modelu. Dlatego, podstawową wartością poprawnie wykonanych modeli organizacji i użycia właściwych narzędzi, jest nie tylko opracowanie wymagań np. na oprogramowanie. Możliwe jest testowanie reakcji elementów struktury organizacji na zdarzenia np. awarie. Możliwe jest opracowanie projektów integracji, wymiany oprogramowania. Możliwe jest sprawdzenie na co ma wpływ np. nieoczekiwana obecność pracownika. To tylko wybrane przykłady, jednak możliwe jest to wyłącznie pod warunkiem posiadanie poprawnie wykonanego modelu.

Czytaj dalejKrótki wpis o śladowaniu

Ach ten wstrętny, wścibski analityk

Cóż, zastąpienie procesu analizy i projektowania werbalną komunikacją to droga na skróty: czerwona strzałka. Czy to zła droga? Droga na skróty to wspomniane na początku ryzyko, ogromne bo statystyki wskazują stale, że ok. 70-80% projektów programistycznych ma poważne kłopoty. Statystyki te są takie same od lat. Od lat znany jest powyższy proces i mimo to zawsze jest te 80% klientów i ich dostawców, którzy dogadują się, że analiza i projektowania żadnemu z nich nie służy... tak jak to napisano na początku. Po co to napisałem? By każdy z Państwa sam, świadomie, oceniał ryzyko swoich projektów. Rezygnacja z analizy i projektowania to podjęcie pewnego ryzyka, przez klienta. Niestety rezygnacja z analizy i projektowania ze strony dewelopera to czasem dodatkowo skutek uznania, że analiza i projektowanie leży poza kompetencjami programistów (Ci obiektowo kodują) wiec wybierają jest droga na skróty.

Czytaj dalejAch ten wstrętny, wścibski analityk

Diagram klas – czyli re-inżynieria” analizy biznesowej. C.d. model dziedziny

Nowy system informatyczny to interakcja firmy i oprogramowania, musi być traktowana łącznie jako jeden system złożony z ludzi i narzędzi w ich otoczeniu. Dlatego decyzja biznesowa o outsourcingu płatności i integracji z ERP powinna być moim zdaniem integralną częścią i produktem analizy biznesowej w projekcie informatycznym.

Czytaj dalejDiagram klas – czyli re-inżynieria” analizy biznesowej. C.d. model dziedziny

Koniec treści

Nie ma więcej stron do załadowania