Structured System Analysis
tools & techniques by Chris Gane and Trish Sarson
Dzisiaj nieco archeologii. Właśnie upolowałem książkę jak poniżej :
Jednym z powodów był niedawny artykuł (Diagram Przepływu Danych…) na temat diagramów DFD i zobrazowaniu kluczowych funkcjonalności systemów. Książka napisana w 1977 roku, ja mam wydanie z 1989-go (!).
Nie raz tu pisałem, że w branży IT jest źle, nadal: “The Standish Group report 83.9% of IT projects partially or completely fail” (83%9 projektów IT to porażki). Ale ciekawsze jest to, że tak jest od początku tej branży do dzisiaj! Te statystyki rok do roku są niemalże identyczne od dekad.
W ramach chwili luzu pomyślałem, że kilka rzeczy z tek książki tu przytoczę.
Pierwszy rozdział zatytułowany jest Potrzeba lepszych narzędzi. Zawiera między innymi Podrozdział Co poszło źle w analizie? I czytamy np. że projektu kończą sie często stwierdzeniem: “Zbudowaliśmy doskonały technicznie system, ale nie tego chcieli użytkownicy”. Znamy to wszyscy, nie? ;). Albo: [zwykli] ludzie nie wiedzą zbyt wiele na temat elektronicznego przetwarzania danych, dlatego są podatni na propagandę, która obiecuje wiele. To tez znamy, nie? Analitycy zbyt szybko rzucają się na szczegóły (!). Dokumentacja wymagań jest przeładowana szczegółami technicznymi (!). Jeżeli dokumentacja zawiera tyko to co zrozumiałe dla użytkownika, stanowi mało przydatne narzędzie dla programistów (!). Co jest problemem? Brak modeli i nadmiar naturalnego języka w specyfikacjach.
Co proponują autorzy? Proponują modele w postaci diagramów przepływu danych rozumiane jako przepływy logiczne, biznesowe. Proponują budowanie słowników (nazwy dokumentów, ich atrybutów, wartości atrybutów). Co ciekawe, książka powstawała gdy model relacyjny nie był w powszechnym użyciu, pojawiają się raczej pojęcia “dane o książce, dane o zamówieniu”. Mowa jest o dokumentach i plikach w hierarchii: plik -> wiersz -> pole -> podrzędne pole (systemy hierarchiczne organizacji danych i język taki jak np. COBOL lub PL/I). Dane te miały struktury bardzo bliskie dzisiejszym plikom XML.
Logika biznesowa? Albo proste związki między polami (takie jak większy, mniejszy, równy), drzewa decyzyjne albo…. Tablice Decyzyjne ;), które nie raz tu opisywałem, one przeżywają dzisiaj renesans. Co ciekawe nie był żadnych sugestii do usuwania redundancji gdyż dokumenty (formularze) miały swoje indywidualne cykle życia, i przepływ danych był rozumiany jako przepływ tych wypełnionych formularzy. Podział dużych systemów na podsystemy (moduły) był konsekwencją dziedziny (patrz bounded context).
Czy widzicie podobieństwo do dzisiejszych wzorców projektowych? Mikroserwisy, nierelacyjne systemy zarządzania danymi, brak monolitycznych rozwiązań, integracja danych poprzez ich wymianą a nie współdzielenie. Czy to cofanie się? Nie, to sprawdzone wzorce, współdzielenie danych i usuwanie redundancji, nie sprawdza się… Systemy znowu są zorientowane na dokumenty biznesowe. A relacyjne systemy danych? Są i pozostaną raczej tam, gdzie się sprawdzają doskonale: hurtownie danych, big data, itp.
Dawne dokumenty i moduły to dzisiaj obiekty transferujące dane DTO, komponenty, mikroserwisy, systemy rozproszone.
Tyle historii na dzisiaj. 🙂 Czy to jakaś forma nawoływania do powrotu do metod strukturalnych? Nie. Ale dzisiaj mamy metody zorientowane na komponenty, na dokumenty, na logikę przetwarzania nie będąca częścią danych/dokumentów. Czy faktura zawiera jakiekolwiek informacje o tym jak powstała? Nie! Czy Treść umowy zawiera informacje o tym ile trwały negocjacje i skąd sie wzięły takie a nie inne ceny? Nie! Logika biznesowa nie jest częścią danych tak jak wzór na upust nie częścią faktury.
Mamy ogromny postęp w technologii i cały czas ten sam biznes.
