Wprowadzenie

Adresatem tego wpisu są moi typowi klienci (biznes, inwestorzy, itp.) oraz kierownicy projektów i rekruterzy szukający kompetencji projektanta (patrz: solution designer, software engineer) na etapie analizy i projektowania.

Co oferuję

Jeżeli jesteś czytelnikiem mojego bloga, pomiń ten akapit, 🙂 znasz mnie. Jeżeli nie to realizuję audyty i tworzę dokumentację (projekty), która odpowiada między innymi na te Państwa pytania:

Analiza biznesowa (Architektura Korporacyjna):

• Jak działa nasza firma?
• Jak nasza firma obsługuje klientów i dostawców?
• Jakie obowiązki mają konkretni pracownicy, za co odpowiadają?
• Jak działają nasze systemy informatyczne, kogo i kiedy wspierają w pracy?
• Jak nasze systemy są zintegrowane ze sobą, jak wymieniają dane miedzy sobą i z systemami kontrahentów?
• Jak poprawić efektywność pracy naszej firmy?

Projektowanie systemów IT:

• Jak opisać nasze potrzeby by dostawca oprogramowania wiedział co nam dostarczyć i wdrożyć?
• Jak udokumentować mechanizm działania i logikę aplikacje dedykowanej?
• Co zrobić by oprogramowanie wykonane dla nas było naszą własnością?

Czy dokumentacja którą opracuję:

• będzie stale aktualizowana? Tak, będzie.
• dużo kosztuje? Zawsze znacznie mniej niż balagan i nieudane wdrożenie.
• ma jakieś przykłady które można zobaczyć? Tak, na końcu tej strony.

U mnie płacisz tylko za moją efektywną merytoryczną pracę. Opracowywanie treści raportów i dokumentacji systemów zajmuje mi znikomy czas, bo używam do tego narzędzi CASE (Visual Paradigm). Na moich fakturach nie ma dodatkowej pozycji “opracowanie dokumentacji/raportu”.

Inżynieria oprogramowania

Poniższa tabela to zestawienie dwóch kluczowych ról w projektach inżynierii oprogramowania

Osoba po lewej stronie to analityk oraz projektant i architekt systemu – to moja rola w projektach. Po prawej stronie osoby (zespół) odpowiedzialne za implementacje – deweloper. Z perspektywy Zamawiającego wygląda to jak poniżej:

Realne projekty, nad którymi pracujemy w IT, są dużo bardziej złożone i wymagają dużo więcej pracy koncepcyjnej. Tak, pisanie kodu i implementowanie rozwiązań to tak naprawdę ostatni etap pracy.

https://www.jaknauczycsieprogramowania.pl/czy-sztuczna-inteligencja-zastapi-programistow/

Projekty dużych systemów to najczęściej odpowiednio dobrane i integrowane standardowe aplikacje. Tam gdzie potrzeby firmy wymagają dedykowanego rozwiązania (aplikacja, moduł), projektowana jest ich logika działania.

Przebieg projektu

Kadry kierownicze Sponsora projektu (przyszły użytkownik) dostarczają mi materiały w postaci potrzeb biznesowych (wymagania biznesowe), na podstawie których powstaje projekt aplikacji (model), którą realizuje (implementuje) deweloper.

Bardzo często analiza wymagań poprzedzana jest powstaniem analitycznego modelu workflow/docflow (procesy biznesowe) i dopiero na jego podstawie powstają wymagania biznesowe.

Projekty w których biorę udział są prowadzone zgodnie z tak zwanym V-Model:

Moja rolę jest lewa gałąź powyższego modelu: Requirement Analysis, System Design, Architecture Design (HLD), Modul Design (LLD), czyli na dzisiaj profesjonalne analizy i projektowanie z użyciem notacji UML. Deweloper (coding i następne po prawej) dostarcza i konfiguruje środowisko oraz koduje (realizuje implementacje projektu). Większe aplikacje mają już na poziomie High Level Design komponentową architekturę i są dostarczane iteracyjnie-przyrostowo. Moimi klientami także bywają softwarehousy (przykładowe referencje).

Od wielu lat część sponsorów wydziela fazę analizy wymagań i projektowanie (lewa strona V-Model).

Jako Projektant

Od początku mojej kariery pełnie także rolę analityka-projektanta. To znaczy, że Zamawiający zaczyna prace od podpisania umowy ze mną. Moim produktem są wymagania wyrażone w formie przypadków użycia, a ewentualnie brakujące w standardowych systemach funkcjonalności projektuję jako dedykowane, zintegrowane, dodatkowe aplikacje lub ich moduły (add-on). Pełnie też stały nadzór autorski na etapie po wyborze Wykonawcy (ww. Audytor).

Jako Audytor

ZARZĄDZANIE PROJEKTEM WE WŁASNYM ZAKRESIE JEST KRYTYCZNE: Integratorzy systemów mogą być cennym elementem cyfrowej transformacji, ale nigdy nie powinni mieć całkowitej, niekontrolowanej władzy nad całym przedsięwzięciem

(źr. PORAŻKA CYFROWEJ TRANSFORMACJI W FIRMIE HERTZ, oryg. : THE HERTZ VS. ACCENTURE DISASTER)

Dlatego wiele firm zawiera ze mną umowę na audyt (nadzór merytoryczny prac Wykonawcy) po zawarciu umowy z Wykonawcą.

Dokumentowanie

Bywam także angażowany gdy oprogramowanie już istnieje i należy udokumentować jego architekturę i logikę działania (kod źródłowy nie jest dokumentacją aplikacji).

Szczegóły i zakres umowy jest każdorazowo ustalany.

Proces opracowania i wdrożenia aplikacji

Ten opis powstał w taki sposób, by można było przerwać jego czytanie w dowolnym momencie: od ogółu do szczegółu. Dlatego zachęcam do lektury osoby zainteresowane moją rolą w projektach, bez względu na to czy jesteście Państwo nabywcą oprogramowania (mój potencjalny klient) czy jego dostawcą (partnerem mojego klienta a być może klientem). Na końcu tekstu udostępniłem przykładowe dokumentacje do pobrania bezpłatnie.

Poniższy diagram obrazuje proces analizy, projektowania o wdrożenia rozwiązania:.

Moje projekty to wypracowane na świecie wzorce zobrazowane na powyższym diagramie:

Analiza, opracowanie Architektury Korporacyjnej, wymagania:
1. Powstaje model organizacji (procesy biznesowe i struktury dokumentów), ,
2. Określane są wymagania biznesowe (potrzeby),
3. Projektowana jest niezależna od platformy logika realizacji wymagań (model systemu), .

Kolejny etap to wybór dewelopera, który:

4. wybiera i stawia środowisko ,
5. realizuje implementację zaprojektowanej logiki w wybranym środowisku ,
6. przekazuje użytkownikom system i wdraża go.

UWAGA!
Moje projekty są architekturą komponentową (mikroserwisy), wdrożenie będzie sprawnym , iteracyjno-przyrostowym procesem (punkty 5. i 6. w pętli). Bywa, że środowisko jest już wymaganiem poza funkcjonalnym (firma już je posiada, będzie to określona chmura, itp.).

Czym jest Model Logiki Aplikacji

Jest także nazywany Opisem Technicznym Oprogramowania albo Mechanizmem Działania. Opis Techniczny Oprogramowania (nie mylić z opisem powykonawczym wdrożenia) to dokumentacja, pozwalająca osobie mającej odpowiednią wiedzę, samodzielnie zrozumieć jego działanie i wytworzyć go.

Poniżej tak zwany “opis minimalny i wystarczający opis produktu” (czyli także aplikacji). Wynalazek to produkt zgłaszany do patentowania, poza Urzędem Patentowym “opis wynalazku” to “opis przedmiotu zamówienia” kierowany do jego wykonawcy (przedmiot umowy na wykonanie):

Opis wynalazku powinien przedstawiać (ujawniać) wynalazek na tyle jasno i wyczerpująco, aby znawca Jest mógł ten wynalazek urzeczywistnić, a ekspert mógł dokonać rzeczowej analizy porównawczej z dotychczasowym stanem techniki. Za „znawcę z danej dziedziny” uważa się przeciętnego praktyka dysponującego przeciętną, ogólnie dostępną wiedzą z danej dziedziny w odpowiednim czasie, który dysponuje typowymi środkami i możliwościami prowadzenia prac i doświadczeń. Przyjmuje się, że specjalista taki ma dostęp do stanu techniki; tzn. informacji zawartych w podręcznikach, monografiach, książkach. Zna także informacje zawarte w opisach patentowych i publikacjach naukowych, jeżeli wynalazek dotyczy rozwiązań, które są na tyle nowe, że nie są zawarte w książkach. Ponadto, potrafi korzystać ze stanu techniki w działalności zawodowej do rozwiązywania problemów technicznych. Przedstawiony wynalazek powinien więc nadawać się do odtworzenia bez dodatkowej twórczości wynalazczej. Pod pojęciem tym należy rozumieć dodatkową działalność umysłową, eksperymentalną związaną z niepełną informacją techniczną zawartą w opisie wynalazku, a także konieczność dodatkowych uzupełniających badań naukowych, niezbędnych do realizacji rozwiązania według wynalazku w pełnym zakresie żądanej ochrony. Odtworzenie wynalazku powinno być możliwe na podstawie przeciętnej wiedzy specjalisty w danej dziedzinie, bez nadmiernego wysiłku. (art. 33 ust. 1 § 32 ust. 2 pkt. 63)

Innymi słowy: Opis ten powinien pozwalać urzeczywistnić produkt, a urzeczywistnienie to nie powinno wymagać: innej niż powszechnie dostępna widza, działalności twórczej. Przy czym podkreśla się, że samo stosowanie wiedzy nie jest działalnością twórczą.

Sama aplikacja, jej funkcjonalność, wymaga opracowania (zaprojektowania) a potem implementacji. Środowisko w jakim będzie funkcjonowała to konsekwencja wymagań poza-funkcjonalnych (wymagana infrastruktura).

Tak zwana architektura heksagonalna (hexagonal architecture, diagram pokazany w dalszej części) perfekcyjnie pokazuje granicę między aplikacją a jej środowiskiem. Pokazuje zatem mój, projektanta aplikacji, zakres odpowiedzialności w projekcie:

• ja, jako projektant logiki rozwiązania, projektuję to co jest wewnątrz czerwonej granicy (jest to tak zwany Platform Independent Model),
• deweloper dostarcza to co jest poza czerwoną granicą (środowisko wykonawcze, framework, itp..),
• koder (najczęściej pracuje dla dewelopera) implementuje to co zaprojektuję ja jako projektant.

Projekt to Opis techniczny, i jako opis mechanizmu działania aplikacji zawiera:

1. modele struktur dokumentów i komunikatów,
2. metody wyliczania lub weryfikowania wartości wszystkich pół wyliczanych w tych dokumentach,
3. model architektury kodu (komponenty, moduły, integracje, itp.),
4. oraz opisuje mechanizmy współdziałania komponentów wyjaśniające integrację, wprowadzanie danych i powstawanie nowych treści.

Rolą dewelopera jest dobór i uruchomienie środowiska oraz implementacja ww. mechanizmu w wybranym języku programowania. Więcej w opisie Projektowanie aplikacji.

Warto tu podkreślić, że sama “idea systemu” wyrażona jako opis jego zewnętrznych cech i sposobów użycia (wymagania funkcjonalne i poza-funkcjonalne, user story), nie stanowi opisu technicznego i nie podlega żadnej ochronie. Z zasady nie stanowią opisu mechanizmu działania, know-how ani nie stanowią tajemnicy przedsiębiorstwa (polecam tu cały wpis: Ochrona Wartości Intelektualnych).

Bez względu na dziedzinę inżynierii , powyższe wymogi są identyczne. Komputer (oprogramowanie) jest zawsze częścią nadrzędnej konstrukcji (systemu, raz jest to macierzyste urządzenie a raz organizacja). Powoduje to, że oprogramowanie komputera, który wraz z tym oprogramowaniem z zasady realizuje jakiś mechanizm , musi zostać udokumentowane na równi z innymi elementami systemu, którego jest częścią.

Dokumentowanie istniejącego oprogramowania

Jeżeli celem jest opracowanie dokumentacji oprogramowania, które powstało ale nie ma ono profesjonalnej dokumentacji technicznej:

1. dostaje aktualne dokumenty (jakiekolwiek jakimi dysponuje zleceniodawca) i na bazie ich audytu powstaje dokumentacja techniczna w takiej postaci w jakiej jest możliwa do stworzenia na bazie dostarczonego materiału źródłowego, na tym etapie jako efekt, powstaje także opis tego jakie dalsze prace są konieczne by projekt Techniczny uzyskał docelową postać (koszt: stawka za analizą dokumentacji),
2. kontynuacja jako realizacja prac określonych w poprzednim punkcie (harmonogram i z góry ustalona kwota, rozliczenia miesięczne ryczałtem), 
3. przekazanie praw majątkowych do opracowanej dokumentacji ma miejsce zawsze, zależnie od ustalenia: po pierwszym lub po drugim etapie.

Projektowanie jako specyfikowanie wymagań PIM (MBSE)

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.

Zakres 1 to nie raz samodzielny projekt biznesowy, którego celem jest potencjalna optymalizacja procesów. Jeżeli jedną z rekomendacji jest wdrożenie oprogramowania, realizowany jest Zakres 2. Jeżeli okaże sie, że na rynku nie ma wymaganego oprogramowania, realizowany jest Zakres 3.

Jeżeli moim zleceniodawcą jest deweloper, każdorazowo ustalam indywidualnie wymagania wobec dokumentacji jaka ma powstać.

Typowy podział na role w projekcie

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. Bywa, że jest to zewnętrzny audytor.

3. Analityk: jako architekt-projektant (inżynier systemów, obszar Information Systems), 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, obszar Information Technology): jako wykonawca implementacji rozwiązania, wybiera technologię, narzędzia i środowisko aplikacji, projektuje i wykonuje implementację, dostarcza i wdraża oprogramowanie.

(źr.: https://builtin.com/recruiting/software-engineer-vs-programmer)

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…).

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.

Dodatek techniczny

Dlaczego moje projekty są zorientowane na dokumenty/komunikaty

Ważna uwaga! Dotyczy zarówno aplikacji tworzonych od zera jak i aplikacji już istniejących i rozwijanych. Ten opis dotyczy obu rodzajów aplikacji. 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 przeze mnie wzorce projektowe to Repozytorium/Envelope, Active Record lub Active Table oraz DDD/Aggregate . Co do zasady na etapie analizy i projektowania nie tworzę i nie używam modeli danych rozumianych jako “jedna relacyjna baza danych dla projektu”.

Innymi słowy logika dziedzinowa to dokumenty jako komunikaty, a te mogą być i przesyłane i utrwalane. Jak widać po prawej, metody utrwalania są poza zakresem modelu dziedziny, czyli poza modelem opisującym mechanizm działania aplikacji.

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.

W dzisiejszej erze big data można zaobserwować ogromną ewolucję w typach baz danych i ich wykorzystaniu. Rozwiązania takie jak np. MySQL czy Oracle, nie są w stanie sprostać współczesnym wymaganiom związanym z obsługą dużej różnorodności, szybkości, prawdziwości i, co ważne, obszernych zbiorów danych. Bazy danych NoSQL są szybkimi rozwiązaniami i doskonale radzą sobie z tymi wymaganiami dzięki dodatkowym cechom, takim jak skalowanie poziome, wysoka wydajność, zgodność z elastycznością i wszechstronność.

Dokument jako agregat

Dokumenty w systemach informatycznych są coraz częściej wyrażane jako struktury XML/XSD/DTD (lub JSON) w bazach dokumentowych (NpSQL) i przechowywane w postaci agregatów .

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ś struktury takie jaki XML czy JSON, można przetwarzać i przesyłać między aplikacjami ze znacznie większą swobodą .

W moich projektach dane są modelowane jako hierarchiczne agregaty (patrz wzorce obiektowe) przechowywane w niezależnych płaskich (nie powiązanych relacyjnie) tabelach: kolumny takiej 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 . Dokument jest tu agregatem.

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 .

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).

Komentarze do projektu Generator Ofert na stronie: Generator Ofert ? Komentarze

Przykł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.

Źródła: