Wprowadzenie bardzo często mozna spotkać opisu typu: MVC architecture. AngularJS divides your web app into three distinct parts — Model (data), View (the UI layer), and Controller (business logic). The three units can be developed in parallel and separately tested. As a result, the code becomes easier to understand, maintain, and extend. (https://www.altexsoft.com/blog/the-good-and-the-bad-of-angular-development/) Niestety jest to powielanie podejścia z czasów lat 90-tych i JavaEE/SE. Patrząc na te trzy pojęcia View to owszem "widoki" czyli GUI, nieporozumienia dotyczą Model'u i Controler'a. Poniżej obecne źródło (jedno z wielu) tego nieporozumienia: Model to…
Bardzo często spotykam, pewnie nie ja jeden, specyfikacje wymagań zawierające zapisy "oczekiwań użytkowników". Bardzo często słyszę także, że to przyszły użytkownik oprogramowania powinien być źródłem wymagań. nic bardziej błędnego.. [...] Więc np. wymaganie "system powinien pozwalać na budowanie dowolnych rabatów sprzedaży do stałych klientów" (także cytat z pewnej specyfikacji systemu CRM) jest pustym stwierdzeniem. Po pierwsze jak te rabaty są naliczane, po drugie czy aby na pewno mechanizm pozwala na "dowolne rabaty"... Jak to opisać? Tu powinny się pojawić np. tablice decyzyjne a nie lakoniczne "dowolne rabaty".
Na zakończenie uwaga: jeżeli planujemy kupić gotowe oprogramowanie, to ono już (gdzieś tam) istnieje, i specyfikowanie szczegółów opisujących dokładnie elementy pracy z interfejsem użytkownika i enigmatyczne opisy tego jak "system liczy", jest bezwartościowe. Raczej wywoła listę tak zwanych kastomizacji (zwanych gdzieniegdzie zabójcami projektów :)). Tak jednak właśnie wyglądają najczęściej specyfikacje pisane rękami przyszłych użytkowników: opiszą oni to z czym się stykają i co znają ale w ogóle nie opiszą wnętrza, którego najczęściej po protu nie rozumieją (i nie muszą bo to nie ich rola), wtedy specyfikacje systemów CRM pisane rękami przyszłych użytkowników - np. sprzedawców - zawierają właśnie bezwartościowe zapisy w rodzaju: "system powinien pozwalać na budowanie dowolnych rabatów sprzedaży do stałych klientów" a nie zawierają opisu jak te rabaty wyliczać.
Odpowiadając na tytułowe pytanie: wymagania (funkcjonalne) realizują się w modelu dziedziny systemu, którego nie zawiera większość znanych specyfikacji wymagań... a warunkiem poprawnego wyboru oprogramowania są oczekiwania co do efektów przetwarzania.
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...
I tak mamy: 100% interfejsu użytkownika zamawia użytkownik (sam lub z pomocą specjalistów), 100% wymagań funkcjonalnych realizuje Model Dziedziny (projekt analityka-projektanta), 100% wymagań poza-funkcjonalnych realizuje developer (projekt i implementacja). Developer także implementuje model dziedziny z pomocą technologii jakiej używa.
A jeżeli klient powie: nie mamy tych wzorów dokumentów i ekranów! To pierwszy sygnał, że nie ma podstaw do zamawiania jakiegokolwiek oprogramowania, bo najpierw trzeba "wiedzieć co się chce".
Jak to zrobić? Tu kłania się analiza biznesowa: modelujemy procesy biznesowe, dla każdego z nich ustalamy wejście oraz efekt (produkt) czyli właśnie owe "wzory dokumentów". Po uporządkowaniu tego i upewnieniu się, że nie ma w tym bałaganu (powtórki, braki, niekonsekwencje, sprzeczności itp.) możemy pytać o gotowe oprogramowanie lub "zamawiać" jego wytworzenie. Produktem pracy analityka powinny być, poza modelami procesów bo one są narzędziem a nie celem, obiektowy model dziedziny czyli model tego jakimi informacjami i jak zorganizowanymi operuje organizacja, oraz to jak pracownicy tej organizacji chcą się komunikować z oprogramowaniem (źrodłem informacji jest jednak klient).
Mamy czysty podział odpowiedzialności i łatwość rozliczenia projektu. Na czym polega haczyk? Klient nie może unikać odpowiedzialności za skutki swoich decyzji i udzielanych informacji. Ale też, co jest kluczowe: Analityk musi zrozumieć problem i zaproponować rozwiązanie.
Jednak nie jest rolą analityka wykonanie oprogramowania! To "jak - technologia - ma to zostać zrealizowane" jest decyzją developera. Ma dużo pracy. Nie zapominajmy, że kod realizujący tak zwaną logikę biznesową to ledwie kilka procent całości kodu aplikacji, jednak nie zapominajmy także (programiści), że zła logika biznesowa dyskwalifikuje całe to oprogramowanie z prostego powodu: staje się nieprzydatne.
