Analiza procesowa a obiektowa czyli niedopasowanie oporu

Właśnie dlatego analiza i wymagania powinny zawierać model dziedziny wraz z zaleceniami co do implementacji. Nie jest to dokument (ten model) dla sponsora projektu (w rozumieniu do czytania). Jego rola (wartość jaką wnosi do projektu) to minimalizacja ryzyka, że developer wykona coś czego nie chcemy.

Czytaj dalej Analiza procesowa a obiektowa czyli niedopasowanie oporu

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

Udziałowcy projektu czyli który diagram UML …

Stosowanie reguł (semantyki i syntaktyki) UML pozwala utrzymać spójność modeli zależnych (podległe temu diagramowi uszczegółowienia Projektu Systemu, realizacja Aktorów, przypadki użycia itp.) oraz zachować spójność logiczną i pojęciową całej dokumentacji. To zaś jest warunkiem weryfikacji poprawności całego projektu.

UML to notacja, której kluczowym pojęciem jest klasyfikator (oparta jest na definiowanych pojęciach i relacjach między nimi) dlatego warto przestrzegać (zawsze warto) zasad notacji i np. nie utożsamiać Aktora System CRM (jest to jakaś abstrakcja systemu integrowanego) z konkretnym Jakimś Systemem CRM. Aktor ma konkretne znaczenie na diagramie UML (zdefiniowane wyżej) i konkretny system także. Zachowanie tego podziału (abstrakcja i jej realizacja) pozwala zdefiniować oddzielnie wymagania i oddzielnie konkretne rozwiązania je spełniające co jest istotą rozdziału wymagań od spełniających je rozwiązań.

Diagramy przypadków użycia są bardzo ważnymi diagramami, gdyż stanowią “korzeń” modelu realizacji systemu zaś łamanie zasad notacji prowadzi praktycznie zawsze do utraty możliwości ich, modeli, weryfikacji.

Czytaj dalej Udziałowcy projektu czyli który diagram UML …

Ten straszny diagram klas

Warto zwrócić uwagę na to, że diagram klas diagramowi nie równy, to samo narzędzie może posłużyć do dwóch różnych celów w tej samej dokumentacji. Widać także (mam nadzieję), że próba pokazania na jednym diagramie zarówno systemu pojęć jak i sposobu ich przetwarzania, jako informacji w systemach informatycznych, jest raczej błędnym podejściem. Wydaje mi się, że podejmowanie takich prób świadczy o niezrozumieniu różnicy pomiędzy systemem pojęciowym a modelem przetwarzania informacji. W szczególności gdy dotyczy to systemów obiektowych.

Czytaj dalej Ten straszny diagram klas

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 dalej Diagram klas – czyli “re-inżynieria” analizy biznesowej. C.d. model dziedziny

Diagram klas ? czyli ?reinżynieria? analizy biznesowej

Dlaczego podnoszę pracochłonność analizy wymagań i projektuję model koncepcyjny do testów? Ano po to by błędy i niespójności odkryć teraz, bo na etapie implementacji ich usuwanie będzie nawet 100 razy droższe. Czy takie błędy są w projektach o uproszczonych analizach biznesowych (lub wręcz pominiętych?) Ci co mają takie projekty za sobą wiedzą doskonale, że są i to prawie zawsze…

Czytaj dalej Diagram klas ? czyli ?reinżynieria? analizy biznesowej

Model i dokumentowanie wdrożenia

Ten artykuł to próba przybliżenia czytelnikowi pojęcia metamodel i model. To także mała próbka tego co jest produktem nadzoru autorskiego. Nieco ponad pięć lat temu w artykule Diagram obiektów czyli…

Czytaj dalej Model i dokumentowanie wdrożenia