Process for System Architecture and Requirements Engineering

Warto tę książkę przeczytać, by poznać dobrze opisaną, spójną koncepcję analizy i modelowania systemów w rozumieniu organizacji. Dla kogoś mającego przywiązanie do analizy strukturalnej, opisany szkielet będzie zapewne dobrym narzędziem pracy. Przyznam jednak, że kojarzy mi się to z latami 90-tymi i pierwszymi narzędziami typu EJB ([[Enterprise Java Bean]]) i anemicznym modelem dziedziny.

Czytaj dalej Process for System Architecture and Requirements Engineering

Ogarnąć złożoność

Wakacje sprzyjają filozofii. Tym razem kontynuacja opisanej tu niedawno książki Kotarbińskiego: Kurs logiki. Logika bardzo pomaga w analizie. Prawie trzy lata temu pisałem o Trzech zasadach logiki, jedna z nich …

Czytaj dalej Ogarnąć złożoność

Panowanie nad złożonością czyli gdzie są Przypadki Użycia czyli MVVM-MVC

Tak więc przypadkami użycia opisujemy abstrakcję jaką jest [[Model Dziedziny Systemu]]. Są one wtedy proste, zawierają scenariusz, który w skrócie ma postać: aktor inicjuje usługę, system prezentuje formularz do wypełnienia, aktor wypełnia go i potwierdza, system potwierdza odebranie danych i pokazuje wynik swojej pracy (lub komunikaty o błędach). Tu skupiamy się na opisie tego jakie usługi są wymagane od systemu. Kolejny etap to “komplikowanie” każdego scenariusza w postaci projektowania, dla każdego przypadku użycia, różnego rodzaju wizardów lub wprowadzamy ograniczenia związane z uprawnieniami użytkowników. Ten etap to praca projektantów UX i grafików, specjalistów od ergonomii itp.

Czytaj dalej Panowanie nad złożonością czyli gdzie są Przypadki Użycia czyli MVVM-MVC

Praw fyzyki Pan nie złamiesz i nie bądź Pan głąb

zbieranie wymagań tylko metodą spisywania oczekiwań czy wręcz żądań, użytkowników, jest jedną z najgorszych metod pozyskiwania wymagań! Praktycznie zawsze prowadzi do powstawania specyfikacji bardzo złej jakości (niespójne i niekompletne) oraz niekontrolowanego rozrastania się harmonogramu i budżetu projektu. Dostawcy oprogramowania, godzący się na taki styl prowadzenia projektu, świadomie lub nie, działają na szkodę swoich klientów. Analiza systemowa organizacji jako sposób pozyskania wymagań, który chroni przed takimi zjawiskami.

Czytaj dalej Praw fyzyki Pan nie złamiesz i nie bądź Pan głąb

Gdzie są te cholerne szczegóły

Tak więc, warto rozważyć stosowanie reguł biznesowych i słowników pojęć (Semantics Of Business Vocabulary And Rules), gdyż jest to sprawdzona i bardzo przydatna technika analizy i dokumentowania logiki biznesowej. Polecam także stronę The Business Rules Group i zamieszczony tam Manifest Reguł Biznesowych. Tworzenie monstrualnych dokumentów wymagań, zawierających dziesiątki razy powielane “walidacje” prowadzi do wielu kłopotów z utrzymaniem spójności i kompletności takich specyfikacji. Pomijam już ich uciążliwą objętość. Jako materiał dla programisty są one wtedy trudne w użyciu, do tego skłaniają do najgorszych praktyk, jakimi jest między innymi umieszczanie logiki biznesowej w kodzie formatek ekranowych.

Czytaj dalej Gdzie są te cholerne szczegóły

Konformizm w projektach

Na koniec największy mit: analiza jest prosta, wystarczy wiedzieć jak ją wykonać i mieć właściwe wzorce dokumentów. Nic tej tezy nie potwierdza, a tak wielu próbuje… Znam masę przypadków, gdy ktoś uznał, że przyuczona grupa pracowników sama wykona analizę wymagań, w końcu to tylko spisywanie potzreb. Niestety nie znam żadnego przypadku gdzie, na bazie tak spisanych wymagań, projekt zakończył się sukcesem. Jest zresztą prosty sposób na ocenę jakości dokumentu opisującego wymagania: skonfrontowanie go z tym co w końcu powstało.

Czytaj dalej Konformizm w projektach

Zintegrowany ERP: postęp czy cofanie?

Zakup oprogramowania, które stanowi jeden, zintegrowany współdzieleniem danych, monolit to nic innego jak zafundowanie sobie długu technologicznego w momencie podjęcia decyzji o takim zakupie. Żadna firma, działająca w obecnych czasach, nie da sama sobie gwarancji, że jej wewnętrzne aktywności nie zmienią się co do ich specyfiki, że nie przybędzie nowych, nie zrezygnuje z niektórych. Monolityczny całościowy system ERP stanowi hamulec każdej takiej zmiany. Oparcie całości na centralnym , współdzielonym module rejestrującym (jest z nim z reguły księgowość) to niemalże “zabetonowanie” architektury biznesowej firmy.

Czytaj dalej Zintegrowany ERP: postęp czy cofanie?

Skomplikowana sieć aplikacji to kula u nogi działów IT

Tak na prawdę integracja taka polega nie na samym zainstalowaniu ESB i “podłączeniu” komponentów, to samo z siebie nic nie wnosi i nie jest łatwe. Integracja z użyciem ESB, to po pierwsze stworzenie (lub użycie jeżeli istnieje) dla każdego komponentu odpowiedniego adaptera i API, po drugie zaprojektowanie schematu komunikacji.

Czytaj dalej Skomplikowana sieć aplikacji to kula u nogi działów IT