Tekst ten zawiera opis metod jakie stosuje w pracy i opis produktów jakie dostarczam. Adresatem tego wpisu są moi klienci oraz dostawcy oprogramowania ERP i deweloperzy, gdyż Opis Techniczny Oprogramowania (architektura i logika przetwarzania informacji – model dziedziny systemu) to wymaganie klienta w stosunku do produktu zamawianego u dewelopera lub dostawcy oprogramowania. Deweloper/dostawca wraz z projektem logiki działania systemu otrzymuje także Analizę Biznesową jako opis kontekstu jego użycia.
Standardowo w projektach analizuję otrzymane materiały źródłowe, produktem tych analiz sá Analizę Biznesowa i Opis Techniczny Oprogramowania. Ten ostatni to dokument, zawierający opis mechanizmu działania poszczególnych obszarów organizacji. Oprogramowanie, którego używa lub planuje wdrożyć do użycia ta organizacja, realizuje (będzie realizować ) część tego mechanizmu działania: to jest logika biznesowa.
Systemy zarządzające informacją zorganizowane są wokół dokumentów i dziedzinowych (kontekstowych) reguł ich przetwarzania. Dlatego najbardziej adekwatna metodą ich projektowania są wzorce oparte na ontologiach, dziedzinowych komponentach, dokumentach i ich przekazywaniu między komponentami.
W razie jakichkolwiek pytań prosze o kontakt. Poniżej ogólny opis metod pracy.
Typowy podział na role w projekcie
Najczęściej jestem angażowany do projektów, w których ustalono role:
1. Zamawiający: jako Organizacja Analizowana zgłasza cele biznesowe i problemy, udostępnia wiedzę na swój temat, jest stałym recenzentem produktów analizy i projektowania (zamawiający to ekspert dziedzinowy) w toku projektu. To kadry kierownicze Zamawiającego, wspierane przez Asystenta-koordynatora, dostarczają materiały źródłowe opisujące opis ich działania i potrzeby.
2. Asystent-koordynator: osoba zaangażowana bezpośrednio z zbieranie materiałów źródłowych (wywiady, kolekcjonowanie dokumentów, itp.), z reguły jest to osoba angażowana (zatrudniana, wyznaczana) przez Zamawiającego.
3. Analityk: jako architekt-projektant (inżynier systemów), prowadzi analizę otrzymanych materiałów, opracowuje model biznesowy organizacji (procesy biznesowe, przepływ i logika przetwarzania informacji), a potem opracowuje model dziedzinowy rozwiązania jako architekturę i logikę działania systemu (patrz jak powstaje Opis Techniczny Oprogramowania), jest ona wymaganiem dla dostawcy.
4. Deweloper (Programmer): jako wykonawca implementacji rozwiązania, wybiera technologię, narzędzia i środowisko aplikacji, projektuje i wykonuje implementację, dostarcza i wdraża oprogramowanie.
Poniżej zobrazowano to jako proces wytwarzania/dostarczania oprogramowania (w moim przypadku zorientowanego na modele: MBSE). W przypadku wdrażania systemów standardowych, rolę dewelopera pełni firma wdrażająca dostarczone gotowe oprogramowanie, której konsultacji konfigurują dostarczony system, jednak w przypadku gdy wymagane są funkcjonalności dedykowane, powstają one jako dedykowane komponenty (add-ons).:

Projekt rozwiązania to początkowo model przypadków użycia (UML) i ich specyfikacje (makiety, scenariusze i logika danych) oraz architektura integracji HLD (komponenty, dokumentowy model danych, sekwencje) . Na jego podstawie Dostawcy składają oferty.
Po wyborze Dostawcy projekt jest realizowany iteracyjnie: kolejne przypadki użycia (usługi aplikacji) są wdrażane, a jeżeli wymagane jest dedykowane oprogramowanie, przypadki użycia są doprecyzowywane (architektura LLD) i implementowane. Zgodnie z zaleceniami producentów systemów standardowych, nie dopuszczam kastomizacji standardowego oprogramowania, brakujące funkcjonalności są dostarczane jako oprogramowanie dedykowane (patrz Kastomizacja…).
Od wielu lat pracuję wg. zasady:
software developer vs software engineer
https://www.randstad.co.uk/career-advice/career-guidance/full-stack-developer-vs-software-engineer/
Generally, software engineers look after the bigger picture, while software developers focus on one area to execute their plans. Engineers can act as developers, too, or simply oversee developers who create functional programs.
Czym jest Projekt czyli Model Logiczny Systemu
Model Logiczny Systemu w nomenklaturze MDA (Model-driven Architecture) to Platform Independent Model (PIM) czuli model mechanizmu jego działania. Związek między projektem a działającym oprogramowaniem wygląda tak:

Ważne jest to, by wiedzieć, że: 1. kod nie jest swoją dokumentacją a jego ochrona prawna jest bardzo ograniczona, 2. prawo chroni projekt oprogramowania (Platform Independent Model) jako utwór i jako know-how, kod jako odtworzenie projektu w określonym języku programowania zawsze jest utworem zależnym.
Powyższe jest też często określane nazwą: architektura heksagonalna (Hexagonal Architecture). Podstawowym założeniem jest tu wyraźne oddzielenie strony użytkownika (User-Side), logiki biznesowej (Business Logic) i strony serwera czyli środowiska wykonywania aplikacji (Server-Side) (patrz: Hexagonal Architecture: three principles and an implementation example).
Powyższy diagram bywa przedstawiany także w innej formie:

Obszar nazwany Domain to nasz model PIM (logika biznesowa). Jest to często w przetargach dokument nazywany Opis Techniczny Oprogramowania (lub Opis Przedmiotu Zamówienia), w rozumieniu opisu mechanizmu jego działania. Ta część realizuje wymagania funkcjonalne. Pozostałe komponenty odpowiadają za realizację wymagań pozafunkcjonalnych.
Struktura i treść moich opracowań
Więcej na temat samego procesu powstawania tych produktów w: Analiza Potrzeb i Opracowanie Wymagań na Oprogramowanie, więcej o stosowanych metodach i standardach: Metoda analizy i projektowania systemów biznesowych. Słownik stosowanych metod i narzędzi jest dostępny na stronie: Słownik metodyczny.
Model Biznesowy
Jest to produkt Analizy Biznesowej, Mapa procesów i ich modele to część opisująca mechanizmy rządzące pracą analizowanej i opisanej organizacji. Celem tego etapu pracy jest zrozumienie tego jak określona organizacja działa i współdziała z otoczeniem oraz przekazanie tej wiedzy dostawcy dostawcy rozwiązania w celu lepszego zrozumienia przez niego kontekstu i środowiska w jakim rozwiązanie będzie wdrażane. Model biznesowy zawiera schematy blokowe wykonane z użyciem notacji BMM (Business Model Motivation) , BPMN (Procesy biznesowe), UML (struktury danych dokumentów biznesowych) oraz SBVR (słownik pojęć i reguły biznesowe). Na tym etapie są realizowane ewentualne zmiany w procesach to-be i określany zakres projektu.
Projekt Rozwiązania
Ten etap to określenie wymagań na oprogramowanie. Najpierw powstają: Diagram przypadków użycia (lista usług aplikacji) i model HLD (podsystemy, integracje). Jeżeli zawiedzie poszukiwanie na rynku zgodnego z tymi wymaganiami gotowego oprogramowania (np. ERP), usługi aplikacji wymagające wytworzenia, specyfikowane są jako projekt logiki systemu do implementacji (jako odrębne mikroserwisy).
Z zasady operuję przypadkami użycia, ich scenariuszami oraz modelem dziedziny budowanym jako architektura separowanych od siebie usług aplikacyjnych (implementowane jako mikroserwisy, komponenty) . Struktury informacji są specyfikowane jako dokumenty (potem XML/JSON), co opisałem w tekście Projekt aplikacji….
Ogólnie moje projekty są oparte na wzorcach projektowych, szczególnie są to ICONIX, DDD, micro serwisy i dokumentowe struktury danych. Architektura mikroserwisów oparta jest na poniższym schemacie:

To co obecnie nazywamy zwinnym tworzeniem oprogramowania (agile) to „raczej” szybka analiza całości problemu (analiza biznesowa), projekt logiki biznesowej rozwiązania, czyli podział całego systemu na komponenty biznesowe (architektura HLD) oraz iteracyjne ich uszczegóławianie (architektura LLD każdego komponentu) i kolejne, iteracyjne ich implementowanie. Praktyka pokazuje, koszt prac analityka projektanta (tu inżynier systemowy), zależnie od stopnia złożoności projektu, to ok. 10 – 20 % całego budżetu na wykonanie oprogramowania (koszty środowiska: licencje, sprzęt itp. do dodatkowe koszty), czyli developer to jednak znakomita większość pracochłonności i budżetu.
Dlaczego moje projekty są zorientowane na dokumenty
Ważna uwaga! Poniższe dotyczy zarówno aplikacji tworzonych od zera jak i aplikacji już istniejących i rozwijanych. Poniższy opis dotyczy obu rodzajów aplikacji, w przypadku aplikacji już istniejących, dokumenty w modelu logicznym mogą być utrwalane w bazie i modelu relacyjnym z pomocą dodatkowej warstwy ORM (mapowanie obiektowo-relacyjne), ma to jednak opisane niżej konsekwencje. Najczęściej stosowane wtedy wzorce projektowe dla Repozytorium to Active Record lub Active Table. Co do zasady na etapie analizy i projektowania nie tworzę i nie używam modeli danych rozumianych jako „jedna relacyjna baza danych dla projektu”.
Krótkie wyjaśnienie
Pojęcie „zbiór danych” większości nadal kojarzy się z relacyjnym modelem danych. Jednak my jako ludzie gromadzimy informacje w postaci redundantnych dokumentów, ich struktury odpowiadają naszym potrzebom a dokumenty są z zasady niezależnymi od siebie bytami (to nie raz zawierają powiązane logicznie treści niczego tu nie zmienia). Dokument to przede wszystkim kontekst dla danych na nim zgromadzonych. Dlatego tak zwane Systemy Biznesowe często nazywane są systemami formularzowymi: z zasady operują na dokumentach (formularzach), integracja systemów – wewnątrz organizacji jak i między organizacjami – to wymiana nazwanych zestawów danych: dokumentów .
Relacyjny model danych jest nieelastyczny. Cechuje się precyzyjnie zdefiniowaną strukturą danych, która jednak bardzo ją ogranicza. Musimy zdefiniować stałą strukturę jak kolumny i wiersze tabel oraz określić ich relacje, co jest później trudne do zmiany. Ponadto, jeśli dziedzina pojęciowa jest głęboko zagnieżdżona, użycie modelu relacyjnego dla niej będzie wymagało wielu tabel i złączeń. Relacyjne bazy danych mają słabą skalowalność poziomą. Mogą być skalowane w pionie poprzez dodanie większej ilości zasobów, takich jak procesor i pamięć RAM. Ale nie mogą być skalowane poziomo, tzn. łączyć wielu maszyn i tworzyć klastrów. Wynika to z wymagań dotyczących spójności. Baza danych zorientowana na dokumenty rozwiązuje niektóre z tych problemów, z którymi boryka się baza danych w modelu relacyjnym.
Główną wadą relacyjnego modelu danych w systemach biznesowych jest zapisywanie danych w postaci współdzielonych znormalizowanych struktur pojęciowych, pozbawionych redundancji, co powoduje, że dane są pozbawione kontekstu , a w konsekwencji model ten nie sprawdza się w systemach zarządzających dokumentami i ich treścią. Dokumenty biznesowe (dowody księgowe ale także umowy, oferty i wiele innych) to złożone agregaty danych więc zapytania SQL do tabel relacyjnych (do ich zapisu i odczytu) to bardzo złożone struktury kodu, powodujące, że tak zorganizowane bazy szybko stają się niewydajne (zasoby takie jak procesor i RAM są ograniczone a skalowanie poziomie tu jest niemożliwe). Dodatkowo dokument, w sensie fizycznym nie może być generowaną dynamicznie strukturą (zapytania SQL do bazy relacyjnej), bo jest wtedy tylko wirtualnym chwilowym bytem, nie stanowi także dokumentu w sensie prawnym (Kodeks Cywilny), nie da się też zarządzać jego cyklem życia.
Dokument jako bazowa struktura danych
Dlatego od dwóch dekad dokumenty w systemach informatycznych są coraz częściej wyrażane jako struktury XML/XSD/DTD (lub JSON) i przechowywane w takiej postaci , często uzupełniane wersją „do czytania i druku” w formacie pdf (realnie są to często pliki pdf zawierające treść XML).
Dane grupowane w dokumenty i przetwarzane jako całe struktury informacyjne, a nie jako pojedyncze pola danych, są coraz częściej stosowaną metodą budowania architektury oprogramowania . Podejście takie daje znacznie większą swobodę projektowania, zaś pliki XML jako dokumenty, można przetwarzać i przesyłać między aplikacjami ze znacznie większą swobodą .
W moich projektach dane są modelowane jako hierarchiczne agregaty (np. struktury dokumentów XML) przechowywane w niezależnych płaskich (nie powiązanych relacyjnie) tabelach: kolumny tabeli reprezentują metadane, cały dokument jako XML/JSON jest zawartością jednego z pól. Każdy dokument ma określoną strukturę oraz zdefiniowane reguły określające jego poprawność (słownik i reguły biznesowe , . Struktura ta może być przejrzyście wyrażona w postaci diagramu UML .
Mechanizm utrwalania standardowo modeluję z użyciem wzorca repozytorium. Obiekt «entity» (wiersz ww. tabeli z dokumentami) odpowiedzialny jest za przechowanie dokumentu (patrz wzorzec «envelope» ): ma atrybuty zawierające kluczowe metadane do realizowania logiki biznesowej oraz operacje CRUD dla tego dokumentu . Od pozostałej części aplikacji oddziela go komponent realizujący logikę dostępu do danych.
Logika dziedzinowa (także walidacja dokumentów) może być wspólna dla wielu dokumentów w określonym dziedzinowym kontekście .
Jednym z kluczowych powodów powszechnego stosowania XML jest także standaryzacja dokumentów, głównie finansowych i urzędowych w ramach Unii Europejskiej oraz standaryzacja, także w Unii, metod zarządzania nimi (archiwa) .
Z racji tego, że pojęcie dokumentu ma także charakter prawny, wydaje się oczywistym, że zachowanie interoperacyjności wymaga takiej standaryzacji. Jest to – standaryzacja – proces postępujący w ramach Unii Europejskiej i wewnątrz państw wspólnoty, dlatego z zasady w moich projektach wymaganiem jest stosowanie XML jako metody zapisu informacji. To czy fizycznie będzie to motor bazy NoSQL czy płaskie tablice w motorach SQL nie ma większego znaczenia, bo istotny jest tu nierelacyjny model danych .
Jeżeli masz jeszcze czas
Jak masz czas polecam wystąpienie M. Fowlera z 2012 roku:
Komunikacja i moja rola w projekcie
Spotkania np. na Skype, są jak najbardziej prowadzone, jednak ich celem są bieżące ustalenia, planowanie, prezentacje prototypów, itp. a nie np. „warsztaty i zbieranie wymagań”. Pisemna forma przekazywania wszelkich materiałów zabezpiecza interes wszystkich trzech stron projektów (sponsor, projektant, wykonawca). Więcej na stronie Komunikacja w projekcie, opis narzędzia jakie stosuję w komunikacji na stronie: Visual Paradigm Postmania (biorący udział w komunikacji sponsor i developer nie muszą niczego instalować, ani kupować jakichkolwiek licencji).
Co do zasady pracuję zdalnie i preferuję pisemną formę wymiany treści i materiałów (komunikacja asynchroniczna w projekcie). Dokumenty to przesyłane mi materiały opisujące potrzeby zamawiającego, elementy obowiązującego prawa, wewnętrzne instrukcje i regulaminy, przykładowe dokumenty operacyjne, itp.
Jako analityk biznesowy i jednoczenie architekt rozwiązania, jestem projektantem. Na podstawie otrzymanych materiałów projektuję rozwiązanie i odsyłam jego opis (opisane schematy blokowe prezentujące procesy biznesowe, architekturę integracji, struktury dokumentów i logikę ich poprawności, itp. (co do zasady stosuję standardy: notacje BPMN, UML, SBVR, itp.). Jak i dlaczego dlaczego? Polecam poniższy referat, który mam nadzieję wiele wyjaśni:
Przykłady specyfikacji wymagań
Prezentowanie przykładowych specyfikacji jest możliwe wyłącznie wtedy, gdy nie są one objęte tajemnicą przedsiębiorstwa, mogę więc pokazać tylko wybrane opracowania. Sa to wyłącznie opublikowane wcześniej dokumenty w przetargach publicznych lub opisy „demo” (tu jako artykuł: Projekt aplikacji – przykład). Poniższe opracowania to dokumentacja dedykowanych systemów, jednak nie każdy system musi być dedykowany.
Projekty dla administracji były realizowane z moim wsparciem (nadzór autorski), zostały wykonane w terminie i w budżecie, zamawiający dostał autorskie prawa majątkowe do projektu, aplikacje te nadal są w użyciu i są rozwijane przez ich właścicieli.
Większość projektów nastawiona jest na zakup i wdrożenie oprogramowania gotowego, dlatego przygotowanie np. do wdrożenia systemu ERP to zawsze Analiza Biznesowa oraz „architektura wysokiego poziomu” (HLD) integracji systemu. Jedynie tam, gdzie wymagane są dedykowane funkcjonalności tworzona jest architektura LLD (ww. specyfikacja techniczna).
Generator_Ofert_zalacznik_nr_1_do_siwz.pdf
1.92 MBKomentarze do projektu Generator Ofert na stronie: Generator Ofert – Komentarze
ZW_RZP_32_PN_S_2019_zal_1a_-_Dokumentacja_Projektowa_Oprogramowania_do_OPZa.pdf
2.88 MBJZelinski-Biblioteka-Projekt-demo.pdf
30.66 MBAnaliza-systemu-promocji-PKP-IC.pdf
2.27 MBPrzykład procesu prowadzenia analizy i wykonania opisu dokumentacji, wraz z filmem jak powstawał, znajdziesz na stronie: https://it-consulting.pl/2020/12/11/analiza-biznesowa-od-zlecenia-do-kompletnego-projektu-technicznego-z-uzyciem-narzedzia-case/.
W razie jakichkolwiek pytań lub sugestii co do tego, czego wg. Was developerów brakuje w tych przykładach zapraszam do komentarzy pod tym tekstem lub proszę o kontakt.
Stale poszukuję developerów dla moich klientów: zarejestruj się jako developer na newsletter.
Na zakończenie moje małe motto
Projekty, do których jestem angażowany, to często projekty trudne, rozpoczynane po raz drugi po nieudanym pierwszym podejściu. Dlatego ich sponsorzy teraz dbają o podział na role i odpowiedzialność każdej strony projektu.
never ask your users what they want, never ask your developer what they think the users want…