Wprowadzenie

Bardzo wiele emocji budzą kwestie styku aplikacji i jej środowiska: mój wpis na LinkedIn “Czy logowanie jest przypadkiem użycia” wzbudził burzliwą dyskusję i wiele kontrowersji. Ten artykuł to opis modelu aplikacji i jej środowiska.

Kluczowe pojęcia

Pojęcie aplikacja jest definiowane (SJP) jako “komputerowy program użytkowy”. Biorąc pod uwagę fakt, że słownikowo “użytkownik” to osoba (użytkownik – osoba lub instytucja użytkująca coś, SJP), aplikacja to “program użytkowy dla człowieka”.

W specyfikacji notacji UML czytamy:

Przypadki Użycia są środkiem do uchwycenia wymagań systemów, tj. tego, co systemy mają robić. Kluczowymi pojęciami
w tym rozdziale są aktor, przypadek użycia i system (modelowany podmiot). […] Użytkownicy i wszelkie inne systemy, które mogą wchodzić w interakcje z systemem, są reprezentowane jako aktor. Przypadek użycia reprezentuje specyfikacje zachowania. Instancja Przypadku Użycia odnosi się do wystąpienia pojawiającego się zachowania, które jest zgodne z odpowiednim Przypadkiem Użycia. Takie instancje są często opisywane przez Interakcje. [zotpressInText item=”{5085975:DCYU6XZJ}”]

Pozostaje pojęcie środowisko, które definiujemy jako ogół elementów otoczenia (SJP). Tak więc można napisać: aplikacja instalowana jest w określonymi środowisku systemowym, korzystają z niej (aktor) ludzie i inne systemy.

Architektura heksagonalna

Jest to, opisany przez Cocburn’a [zotpressInText item=”{5085975:IQ3YKX86}”], wzorzec architektoniczny zakładający całkowitą separację kodu aplikacji od kodu środowiska.

Wzorzec ten jest przywoływany obecnie także pod nazwą “Porty i adaptery”:

Na powyższym diagramie zilustrowano wybrane detale środowiska aplikacji. Aplikacja (jej kod) to część realizująca wymagania funkcjonalne. Środowisko realizuje wymagania poza-funkcjonalne. Środowisko to najczęściej produkty standardowe: to systemy operacyjne, środowiska programistyczne i frameworki, motory baz danych, sterowniki urządzeń (dostarczają je zwykle ich producenci) itp.

Chronologicznie wcześniej opisanym wzorcem architektonicznym jest wzorzec MVC (Model, View, Controller) [zotpressInText item=”{5085975:PH5HEUCP},{5085975:VMQ2WAE4},{5085975:WMICMKW9}”]. Podział na trzy części ma uzasadnienie z uwagi na typ aktora: człowiek wymaga do komunikacji klawiatury i ekranu monitora, inna maszyna (a konkretnie inna aplikacja lub komponent) jedynie wymienia komunikaty na poziomie zwanym API (Application Programming Interface). Dlatego Środowisko aplikacji jest dzielone na część User Interface (View) oraz Instrastructure (Controller). Cała logika i jej dane to Model (Application Core).

Powyższe można zilustrować tak:

Podstawowe środowisko to system operacyjny. Stanowi on standardowe środowisko dla aplikacji. System operacyjny dla aplikacji to API do sprzętu (dysku, sieć, itp.) i usług systemowych (data, sesje użytkowników, peryferia itp.) oraz sieciowych (dostęp do Internetu). Kolejne ważne pojęcie to sesja: to uwierzytelniony “dialog” ze zidentyfikowanym użytkownikiem (anonim to też forma identyfikacji sesji), i jest to funkcja środowiska. Na poniższym diagramie pokazano idee tego czym jest sesja (Application serwer to środowisko aplikacji na nim uruchamianych). Ważne: logowanie to funkcja środowiska a nie aplikacji, co pokazano np, na tym diagramie:

“Sesja” to termin odnoszący się do czasu przeglądania strony internetowej przez użytkownika. Sesja oznacza czas pomiędzy pierwszym wejściem użytkownika na stronę witryny a momentem, w którym przestaje on z niej korzystać. (https://hazelcast.com/foundations/caching/web-session/)

Kroki 4 i 5 to trwający dialog użytkownika z serwerem, jest nim najczęściej praca z aplikacją, udostępnianą przez ten serwer (który jest kontrolerem sesji, patrz Control w MVC). Zalogowanie się i praca z aplikacją wygląda tak:

Patrząc na Architekturę Oprogramowania i powyższy diagram można stwierdzić, że:

• logujemy się do środowiska, w których wykonuje się aplikacja,
• przypadki użycia aplikacji to to, co się dzieje od momentu pojawienia się na ekranie jej menu (pętla Loop na powyższym diagramie),
• zmiana sposobu uwierzytelnienia to zmiana (dodanie, wymiana) komponentu środowiska (np. dodatnie czytnika linii papilarnych i jego sterownika czy zastąpienie logowania parą login i hasło, sprzętowym kluczem, itp.),
• wiele aplikacji korzysta z bibliotek systemowych, także tych dostarczanych producentów języków programowania i frameworków,
• serwery webowe to bardzo często serwery jednej aplikacji, dlatego granica między logowaniem a pracą z aplikacją jest z reguły niewidoczna,
• środowisko uwierzytelnia sesję użytkownika, jest możliwe by aplikacja – mając numer sesji (ID użytkownika) – zarządzała własną tablicą “imię nazwisko – ID użytkownika”,
• środowisko przechowuje procedury autoryzacji do zasobów systemowych,
• aplikacja przechowuje procedury autoryzacji do komponentów (funkcji) w obszarze logiki biznesowej (dostęp do danych biznesowych itp.),
• jest możliwa komunikacja aplikacji ze środowiskiem w celu wymiany danych np. o autoryzacji do określonych zasobów (wtedy ta aplikacja musi mieć w środowisku autoryzację do takich działań).

Podsumowanie

Wzorce architektoniczne pomagają zrozumieć działania oprogramowania. Pomagają także identyfikować ryzyka związane z cyberbezpieczeństwem. Bardzo ważna jest ich znajomość i rozumienie, a jeszcze ważniejsze jest świadome stosowanie. Jednym z kluczowych zaleceń architektonicznych, także dotyczącym bezpieczeństwa, jest nie umieszczanie logiki biznesowej poza aplikacją, np. w systemie tabel baz danych (logika biznesowa i w aplikacji i w środowisku).

Bardzo znanym przypadkiem pokazującym skutki umieszczania “czegoś” w środowisku, jest firma CrowdStrike i jej produkt Falcon, który podmieniał bibliotekę systemową Windows by zmienić zachowanie się kilku funkcji bezpieczeństwa. Niestety błąd CrowdStrike spowodował, że upgrade Falcon powodował “wieszanie się” Windows: ta awaria nie była winą Microsoft (“CrowdStrike IT Outage Explained by a Windows Developer”), była winą dostawcy oprogramowania ingerującego w środowisko.

Źródła

[zotpressInTextBib style=”apa” sort=”ASC”]

Wprowadzenie

Oprogramowanie na obecnym rynku, w ogromnej ilości, nadal stanowią produkty powstałe ponad dwie dekady temu (legacy systems). Znakomita większość powstawała ewolucyjnie. Lata 90-te to bardzo często monolity budowane w oparciu o EJB, JavaEE i nieco później Microsoft .NET. Są to wzorce powstała na bazie relacyjnego modelu danych i skryptów transakcyjnych.

“W anemicznym projekcie domeny logika biznesowa jest zwykle implementowana w oddzielnych klasach, które przekształcają stan obiektów domeny. Fowler nazywa takie zewnętrzne klasy skryptami transakcyjnymi. Ten wzorzec jest powszechnym podejściem w aplikacjach Java, wspieranym przez technologie takie jak wczesne wersje Entity Beans EJB, a także w aplikacjach .NET zgodnych z architekturą Three-Layered Services Application, gdzie takie obiekty należą do kategorii “Business Entities” (chociaż Business Entities mogą również zawierać zachowanie).” https://en.wikipedia.org/wiki/Anemic_domain_model

“Jest to jeden z tych anty-wzorców, który istnieje już od dłuższego czasu, ale wydaje się, że obecnie przeżywa szczególny rozkwit. Rozmawiałem na ten temat z Ericiem Evansem i obaj zauważyliśmy, że wydają się one być coraz bardziej popularne. Jako świetni zwolennicy właściwego modelu domeny, nie jest to dobra rzecz.” (M.Fowler) https://martinfowler.com/bliki/AnemicDomainModel.html
https://martinfowler.com/eaaCatalog/transactionScript.html

Z powyższych powodów nadal powstają diagramy jak ten poniżej:

W artykule Ten straszny diagram klas opisałem przyczyny, dla których jest to bardzo zły (anemiczny) model: powyższy diagram tak na prawdę nie jest dokumentacją działającego oprogramowania (o ile w ogóle ten diagram powstanie i ktoś go aktualizuje).

Od dłuższego czasu kolejne firmy zgłaszają podobny problem: mamy nieudokumentowaną aplikację a jej autorzy odchodzą na emerytury, czy można coś z tym zrobić?

Czym jest architektura aplikacji?

W artykule Architektura kodu aplikacji, opisywałem komponentowe i obiektowe wzorce projektowe. Komponentowo zorientowane oprogramowane ma standardowo cztery poziomy budowania architektury:

1. aplikacja zbudowana jest z komponentów,
2. komponenty zbudowane są z klas,
3. klasy zbudowane są z operacji,
4. operacja to nazwa procedury, zbudowanej z poleceń wyrażonych w określonym języku (metoda).

Graficznie można to zilustrować tak:

Na powyższym diagramie pokazano wymienione poziomy architektury. Oprogramowanie to kod, lista instrukcji dla procesora. Z perspektywy kodu (i kodera) są to setki i tysiące linii kodu, który stanowi sobą ciąg instrukcji dla procesora. Razem (procesor i kod w pamięci) stanowią komputer, który realizuje określony mechanizm [zotpressInText item=”{5085975:ZCXJ2S7U}”].

Jest to odpowiednik tak zwanego V-Modelu:

Problem w tym, że tego mechanizmu, jako całości, nie widać z perspektywy kodu. Dlatego zaprojektowanie oprogramowania realizującego złożone mechanizmy wymaga pracy od ogółu do szczegółu. Uzyskany efekt to setki procedur wyrażone w postaci kodu, ale przemyślane i przetestowane jeszcze przed pisaniem kodu, które to kodowanie jest najkosztowniejszą częścią w inżynierii oprogramowania [zotpressInText item=”{5085975:3T3PUJZL}”].

Problem w tym, że sam kod źródłowy to tekstowy opis. Proszę sobie wyobrazić tekstowy opis konstrukcji i zasady działania okrętu, samochodu czy nawet tylko zwykłej pralki. Na pewno można opisać prozą istniejącą obserwowaną działającą konstrukcję, ale raczej nie uda się jej bezbłędne zaprojektowanie w ten sposób za pierwszym razem. Zawsze bezie to kosztowne pasmo prób i błędów.

Dlatego: grupujemy procedury w klasy (operacja klas), klasy grupujemy w komponenty, całość testujemy na modelach (diagramy sekwencji). To wszystko jako całość, po wykonaniu implementacji, stanowi sobą działającą aplikację.

Mamy aplikację ale nie mamy jej dokumentacji

Kodowanie z pominięciem projektowania i jego skutki opisywałem nie raz. A jeżeli aplikacja istnieje? Skoro istnieje i działa (bez wnikania ile kosztowało jej powstanie) to znaczy, że można ją opisać. Działający komputer to “czarna skrzynka”, w której wykonywane są procedury (oprogramowanie). Bez dokumentacji nie jesteśmy w stanie “odkryć” jej architektury, ale analizując wejścia i wyjścia (formularze, zrzuty ekranowe, wydruki), można podjąć próbę odtworzenia procedur [zotpressInText item=”{5085975:H5Z2U363}”].

Jak rozwiązać problem długu informacyjnego (patrz: Dług informacyjny)? Należy opisać mechanizm działania aplikacji abstrahując całkowicie od jej architektury, której niestety nie znamy a nakłady na jej odtworzenie na bazie analizy kodu (code review) były by wyższe niż napisanie całości od zera. Wiele aplikacji jest niestety słabo napisana, ich kod jest trudny do zrozumienia (What is Bad Code?), więc taka analiza kodu najczęściej nie ma uzasadnienia ekonomicznego. Nie ma też żadnego sensu tworzenie diagramów klas takich jak ten na początku tego artykułu.

Bardzo często słyszę, że analityk nie ma wpływu na architekturę modelu dziedziny, bo robi to deweloper, i niestety często jest to prawdą. Analogiczny problem:

Jak zaprojektować (opisać) system nie mając wpływu na architekturę?

Jak w UML dokumentować model systemu, którego budowy nie znamy?

Patrząc na wcześniej przytoczony diagram opisujący poziomy abstrakcji architektury, pomijamy dwie środkowe warstwy: HLD i LLD. Wtedy zostają nam do udokumentowania: przypadki użycia i ich scenariusze oraz procedury.

W efekcie tworzymy:

1. diagram Przypadków Użycia (PU) reprezentujący komu i do czego ta aplikacja służy (co ma powstać, czego aktor oczekuje jako efekt),
2. dla każdego PU:
   • przyporządkowujemy formularz/dokument (szablon ekranu, graficzna forma, zalecana forma to diagram struktur złożonych UML),
   • dokumentujemy dialog (scenariusz) aktor-system w postaci listy wypunktowanej (to także test odbiorczy),
   • każdy scenariusz odwzorowujemy na diagramie aktywności jako łańcuch procedur:
     • każdą procedurę dokumentujemy na osobnym diagramie UML,
     • jest możliwe, że procedury te będą wielokrotnie wykorzystywane w różnych scenariuszach różnych przypadków użycia.

W repozytorium narzędzia CASE powstaje hierarchia diagramów:
– Diagram Przypadków Użycia
— scenariusz PU 1 (łańcuch procedur)
— procedura 1 (kroki procedury, algorytmy)
— procedura 2 (kroki procedury, algorytmy)
— procedura 3 (kroki procedury, algorytmy)
— scenariusz PU 2(łańcuch procedur)
— procedura 3(kroki procedury, algorytmy)
— procedura 4 (kroki procedury, algorytmy)
— procedura 5 (kroki procedury, algorytmy)
— scenariusz PU 3 (łańcuch procedur)
— procedura 6 (kroki procedury, algorytmy)
— procedura 7 (kroki procedury, algorytmy)
— procedura 8 (kroki procedury, algorytmy)

Możliwe jest reużywanie procedur (dlatego maja unikalne nazwy). Mona je grupowa osobno (stos procedur) i wywoływać niezależnie ze scenariuszy PU. Taki model nie zawiera diagramów klas (wyjątkiem jest diagram struktur złożonych jako model formularza/komunikatu), komponentów, sekwencji.

Przykład

Co do zasady Diagram Przypadków Użycia to zakres projektu.

UseCases są sposobem na uchwycenie wymagań systemów, tj. tego, co systemy mają robić. Kluczowymi pojęciami
w tym rozdziale są aktorzy, UseCases i przedmiot modelowania (system). Kontekstem każdego UseCase jest rozważany system, do którego, do którego odnosi się UseCase. Użytkownicy i wszelkie inne systemy, które mogą wchodzić w interakcje z systemem, są reprezentowane jako aktor. [zotpressInText item=”{5085975:DCYU6XZJ}”]

Poniżej prosty model: zakres projektu “System Fakturowanie Zamówień”.

Przypadek użycia Faktury ma tu następujący scenariusz:

Na tym poziomie tworzymy Diagramy Aktywności:

Aktywności mogą opisywać obliczenia proceduralne, tworząc hierarchie działań wywołujących inne działania lub, w modelu obiektowym, mogą być wywoływane pośrednio jako metody związane z operacjami, które są bezpośrednio wywoływane. […]
Aktywności mogą być również wykorzystywane do modelowania systemów informatycznych w celu określenia procesów na poziomie systemu. [zotpressInText item=”{5085975:DCYU6XZJ}”]

Diagram Aktywności reprezentujący powyższy scenariusz:

Na diagramie pozostawiono numery linii ze scenariusza opisanego tekstem, dla ułatwienia porównania ich ze sobą. Powyższe to pierwszy poziom modelowania mechanizmu działania systemu. Czynność “2. SYSTEM wyświetla Formularz Lista Zamówień został oznaczony symbolem “grabie” (prawy dolny róg). Podobnie jak 4. SYSTEM wyświetla wstępnie wypełniony Formularz Faktura. Oznacza to, że istnieje detaliczny opis tego zadania. Wygląda on tak:

oraz

Dokładny opis tworzenia powyższych konstrukcji zawiera rozdz. 16 spec. UML:

Pozostaje udokumentowanie elementów “Object Node” (prostokąty reprezentujące formularze i komunikaty). Najwygodniej w narzędziu CASE użyć do tego Diagramu Struktur Złożonych notacji UML, gdyż pozwala to na pełną kontrolę spójności modeli:

Oba powyższe formularze (komunikaty) mają wczesną formę, są ogólne i zawierają obszary danych. W toku projektu są one doprowadzane do postaci detalicznie opisującej treść tych dokumentów i ich walidacje.

Przykład tworzenia nowego zamówienia:

Podsumowanie

Jako ludzie używamy komputerów (ogólnie różnych urządzeń, komputer jest jednym z nich) a nie oprogramowania. Komputer to procesor, pamięć i program [zotpressInText item=”{5085975:ZCXJ2S7U}”]. Oprogramowanie to skrypty konfigurujące zachowanie się tego urządzenia jakim jest komputer. Każda aplikacja jest reprezentowana w postaci kodu (maszynowego), który powstaje z pomocą (za pośrednictwem) języków programowania wysokiego poziomu (Pyton, Java, C, PHP, itp.). Ten kod to procedury.

Proste rozwiązania to kilkanaście do kilkudziesięciu procedur, które mieszczą sie na kilkunastu stronach wydruku. Jednak większe systemy to setki powiązanych ze sobą procedur. Zapamiętanie i zrozumienie ich wzajemnych powiązań jest dla człowieka praktycznie niemożliwe, dlatego już w latach 80-tych powstały koncepcje podziału dużych systemów na moduły, a późnej w latach 90-tych, na komponenty [zotpressInText item=”{5085975:3T3PUJZL}”]. Moduł to tematycznie powiązane procedury, które nadal stanowią sobą jedną całość (monolit).

Komponent to wydzielona, odseparowana od reszty ich grupa procedur, stanowiąca sobą odrębną zamkniętą całość [zotpressInText item=”{5085975:HPRRUHDL},{5085975:NSJBENX9}”]. Tak budowane są systemy zorientowane obiektowo (komponent to także obiekt). Tu przypomnę, że tak zwany paradygmat obiektowy to “hermetyczne komponenty i komunikacja między nimi” a nie “dziedziczenie i łączenie funkcji i danych w obiekty” (polecam referat: Object Oriented Programming vs Functional Programming).

Odpowiedź na tytułowe pytanie: Jak udokumentować monolit, brzmi: przeanalizować jego działanie na podstawie danych (dokumentów) wprowadzanych oraz danych (dokumentów) jakie on tworzy, i udokumentować wyniki tej analizy tak jak pokazano powyżej. Na pewno się okaże, że jest to duży i skomplikowany system, więc już na etapie analizy, od początku jej prowadzenia, grupujemy dokumenty i procedury na tematyczne grupy (moduły). Jeżeli zapadnie decyzja o wykonaniu tego systemu jeszcze raz, projektujemy jego architekturę HLD, i prowadzony projekt metodami obiektowymi (nie mylić z dziedziczeniem i łączeniem danych i funkcji w obiekty), bo to podejście pozwala “opanować” złożoność takiego systemu a projekt architektury grupujący wszystkie procedury w komponentu i klasy, stanowi doskonała dokumentację całości [zotpressInText item=”{5085975:64KN4B9L}”].

Polecam artykuł Jak wyjść z długu technologicznego jakim jest centralny monolityczny system, jako kontynuacje tego tekstu.

Źródła

[zotpressInTextBib style=”apa” sort=”ASC”]

Wprowadzenie

Jednym z większych problemów wielu firm jest zarządzanie produktami, a kluczowym elementem tego procesu jest klasyfikacja produktów: nadawanie im nazw i indeksów oraz kategoryzacja.

Wiele firm popełniło błąd generując tysiące indeksów lub tworząc ich mało, ale budując setki ich wariantów. Oba przypadki są szkodliwe dla systemów e-commerce, ERP, magazynowych i sprzedaży, a także potem na etapie wsparcia po sprzedaży.

Ogromnym problemem dla wielu firm jest rozróżnianie nowych produktów od ich nowych wersji i wariantów. Do tego dochodzi problem braku kompatybilności opisów w wymianie towarów i usług z innymi firmami.

Jak do tego podejść czyli ontologia

Metody i narzędzia

Słownik JP tak definiuje ontologię z perspektywy informatyki:

ontologia – inform. formalna reprezentacja określonego zasobu wiedzy, mająca postać systemu pojęć i wiążących je relacji

Jest to metoda gromadzenia wiedzy. Czym jest ta wiedza? To są treści złożone ze zdań, zdań prawdziwych.

Ontologia jest często nazywana reprezentacją wiedzy. Pozostaje pytanie co jest tu tą wiedzą? Czy wiedzą jest to co oznacza w określonym języki (tu polskim) słowo “samochód”, czy wiedzą jest to, kto wczoraj jechał, gdzie, kiedy i jakim samochodem? Nie jest ontologią sprawozdanie, więc jest nią słownictwo użyte do stworzenia tego sprawozdania. Dlatego często ontologię nazywa się także modelem pojęciowym ale nie jest to “domain model” bo model dziedziny to nie model pojęciowy! (źr.: Ontologia czyli jak się to robi – Jarosław Żeliński IT-Consulting)

Jak wyrazić System pojęć i wiążących je relacji? Robimy (standard OMG) to obecnie z pomocą notacji SBVR i tak zwanego diagramu faktów. Ontologia wyrażona jest tu jako model w postaci diagramu (diagramów) obrazującego pojęcia danej dziedziny oraz związków między nimi: predykaty i generalizacje [zotpressInText item=”{5085975:3XJ5DR4Y}”]. Poniżej przykład prostego modelu (źr.: Biblioteka):

W nomenklaturze SBVR predykaty [zotpressInText item=”{5085975:48AAP7N2}”] to fakty oraz związek “jest typem/rodzajem” (generalizacja). Konstrukcje na diagramie powyżej czytamy:

• Wiersze, Powieści, Nowele to TYPY książek (w tej dziedzinie, książkę tu definiujemy jako treść a nie przedmiot).
• Książka (jest) wypożyczana z Biblioteki.
• Biblioteka jest zarządzana.

Uzupełnieniem powyższego modelu są definicje tych pojęć (dziedzinowy słownik pojęć). Każe pojęcie to klasa (jako nazwa zbioru a nie zbiór), jego definicja to klasyfikator.

Pojęcia klasy obiektów, klasyfikatora, wartości a także pojęcia reprezentującego obiekty, które mogę reprezentować wartość czego to zbiory, definicje elementów i elementy. Z elementów zbioru, za pomocą predykatów, można budować “zdania prawdziwe” czyli opisy. Poniżej ciekawa prezentacja o teorii zbiorów i rachunku predykatów. Bardzo ważna dla zrozumienia tego czym tak na prawdę jest analiza pojęciowa. (źr.: Ontologia – zastosowanie w inżynierii oprogramowania)

Dziedzinowy model pojęciowy

Modele pojęciowe, ich tworzenie, są jednym z kluczowych etapów analiz, służą do uporządkowania przestrzeni pojęciowej i zagwarantowania jej spójności, niesprzeczności i kompletności [zotpressInText item=”{5085975:GAEAR7C8}”]. Jednym z elementów analizy pojęciowej i testowania modeli pojęciowych jest analiza i sprawdzanie tekstów dziedzinowych: zdań w których pojęcia te zostały użyte zgodnie ich powszechnym przeznaczeniem w dziedzinowym kontekście. Przykład kontekstów użycia:

pojęcie	przykłady użycia (połączenia z innymi pojęciami, źr. https://wsjp.pl/)
asortyment	bogaty, duży, główny, mizerny, niewielki, olbrzymi, podstawowy, różnorodny, skromny, spory, szeroki, ubogi, wąski; aktualny, dostępny, nowy, obecny; dochodowy, luksusowy, tradycyjny; aromatyczny, erotyczny asortyment; handlowy, produkcyjny, towarowy asortyment alkoholu, chleba, herbat, mięsa, napojów, pieczywa, piwa, smaków; książek, podręczników; lekarstw, leków, środków antykoncepcyjnych, farmaceutycznych; dywanów, kosmetyków, obuwia, odzieży, ubrań; ceramiki budowlanej, farb, grzejników, kabli, kotłów, kółek, kształtek, mebli, narzędzi, urządzeń, węgla, wyrobów (hutniczych, stalowych…); nawozów, roślin; koncernu, sklepu; robót (budowlanych), usług
cecha	cecha identyfikacyjna cecha firmy, urzędu, zakładu oznaczyć coś cechą czegoś
produkt	dobry, dostępny, elementarny, główny; gotowy; nowy; polski produkt; podstawowe; zakupione, zamówione; wybrane; podrobione/podrabiane; tanie; różne produkty; produkt leczniczy; produkty przemysłowe, rolne; spożywcze, żywnościowe; mleczne, roślinne, zwierzęce; chmielowe; naftowe; tradycyjne produkt firmy; produkty pochodzenia zwierzęcego, przemysłu chemicznego, kosmetycznego; ziemi produkty dla konsumenta, dla użytkownika; dla dzieci, dla kobiet, dla niemowląt; dla kotów; dla rolnictwa, dla zdrowia; produkty do golenia, do pielęgnacji ciała, twarzy, włosów… produkt i marka; produkty i ceny, produkty i firmy, produkty i koszty, produkty i półprodukty, produkty i procesy produkcyjne, technologiczne…, produkty i projekty, produkty i technologie, produkty i towary, produkty i usługi bezpieczeństwo; cechy, charakter, właściwości; nazwa; opis, oznaczenie, oznakowanie; pochodzenie produktu; producent; produkcja; ceny, wartość; dostawa, przesyłka, tranzyt; eksport; grupy, kategorie, rodzaj; ilość, jakość; kontrola; reklama; sprzedaż; nabycie, zakup; wymiana; zbyt; lista, rejestr, wykaz; próbki; rynek produktów
wariant	dostępny, możliwy, prawdopodobny, realny; nowy, ostatni, poprzedni, stary; konkretny, określony; następujący; główny, podstawowy; alternatywny; maksymalny, radykalny, skrajny; ostateczny; droższy, najkorzystniejszy, najlepszy, optymalny; najprostszy; najgorszy wariant; wariant indywidualny; rządowy; oszczędnościowy; rozszerzony; kompromisowy, pośredni; inwestycyjny; ofensywny, taktyczny; optymistyczny, pesymistyczny; poszczególne, rozmaite; pozostałe warianty drugi, pierwszy, trzeci wariant; dwa, trzy warianty liczba; ocena, opis; wybór wariantu wariant obejmuje, przewiduje, uwzględnia, zakłada, zapewnia coś; wymaga czegoś; pozwala na coś; warianty różnią się czymś
wersja	wersja luksusowa w dwóch wersjach wersja standard wersja armaty, maszyny, radaru…; twierdzy
kategoria	kategoria prawna; kluczowe, podstawowe; abstrakcyjne kategorie; kategorie ekonomiczne, estetyczne, filozoficzne, ontologiczne, socjologiczne; pojęciowe definicja kategorii myśleć, rozumować jakimiś kategoriami interpretować, postrzegać, ujmować coś w kategoriach czegoś

Powyższe pojęcia wyrażone w postaci diagramu faktów (fact model):

Diagram faktów powyżej, jako model ontologiczny (na diagramie są pojęcia wyrażone jako słowa w mianowniku liczby pojedynczej, budując zdania robimy w zgodzie z gramatyką danego języka) czytamy:

• cechy odróżniają produkty
• produkty należą do kategorii
• istnieją warianty konstrukcyjne produktów
• istnieją wersje rodzajowe produktów
• asortyment to (określona) grupa produktów

Pojęcia powyższe mają poprawne definicje jeżeli powyższe zdania są zdaniami prawdziwymi w danej przestrzeni pojęciowej.

Definicja produktu a cechy definiujące

Definiując coś stosujemy dwie formy definicji: definicje sprawozdawcze (opisowe) i realne (atrybutowe) [zotpressInText item=”{5085975:6LD24N2L}”]. Jako ludzie na co dzień stosujemy definicje sprawozdawcze, i takie mamy w słownikach. Definicje realne to definicje budowane jako lista cech i ich wartości.

Definicje sprawozdawcze (https://wsjp.pl/):

• pies: zwierzę domowe mające cztery łapy, ogon i wilgotny czarny nos, wydające odgłos zwany szczekaniem, hodowane przez człowieka dla towarzystwa, do pilnowania domu lub pomocy przy wykonywanych obowiązkach, uważane za wroga kota
• pomidor: owoc pomidora – rośliny

Definicje realne:

• pies: wydawany głos=szczek (jeżeli jest prawdą że tylko pies wydaje dźwięk zwany szczekaniem)
• pomidor: kolor=czerwony, kształt=kulisty, średnia={4 do 6 cm}, smak=słodki, waga=120g (jeżeli to prawda)

Systemy informatyczne to dane oraz procedury i algorytmy. Komputer “nie rozumie” definicji opisowych, dodaje i realizuje procedury a te to jedynie porównywanie ciągów znaków. Dlatego projektowanie oprogramowania wymaga sprowadzenia problemu do poziomu definicji atrybutowych i procedur.

Pies, poza tym że szczeka, ma takie cechy jak kolor sierści, rasa, waga itp. jednak te cechy nie są cechami czyniącymi go psem. Każda rzecz ma cechy definiujące i pozostałe. Pozostałe cechy to cechy niedefiniujące, część z nich to mogą być cechy grupujące: np. grupa rzeczy czerwonych, grupa rzeczy ważących ponad 5kg.

Proste grupowanie bazuje na wybranych cechach rzeczy (np. kolor), jednak możliwe jest budowanie grup na bazie innych kryteriów niż cecha: np. zastosowania czy właścicielstwo. Zastosowania czy grupa odbiorców, nie są cechami rzeczy, których używamy: używanie noża do krojenia chleba nie jest cechą noża (ale jego funkcją jest krojenie/cięcie, to jego cecha), bycie czyjąś własnością nie jest cechą przedmiotu. Innym przykładem jest asortyment. Jest to umowna grupa przedmiotów (produktów) budowana uznaniowo. Podobnie jak np. studenci: to że jakaś osoba jest studentem Akademii WIT nie jest cechą tej osoby, ta osoba jest na liście studentów. To, że talerze zostały zakwalifikowane do asortymentu Kuchnia i wyposażenie kuchni, nie wynika z tego czym jest talerz (kiedyś były trzymane w jadalniach). Koszyk zakupowy grupuje produkty do niego włożone, produkty w koszyku nie maja żadnej wspólnej cechy, po prostu łączy je to, że są w tym samym koszyku (a później na tym samym paragonie lub fakturze).

Kolejną cechą “produktu”, nie będącą cechą przedmiotu, jest jego wersja montażowa czy wersja rozumiana jako numer wydania (revision). Patrząc na żaluzje do montażu na suficie (i nie mając innych przed sobą) nie dowiemy się, że to jedna z wersji (druga to wersja do montaży na ścianie). Nie dowiemy się także ile “wersji rozwojowych” było wcześniej. Te dane nie są cechą przedmiotu, to wiedza zapisana poza tym przedmiotem.

Taksonomia

Słownik Języka Polskiego mówi:

taksonomia: nauka o zasadach stosowanych w systematyce organizmów przy opisie gatunków, ich nazywaniu i włączaniu w układ systematyczny zwierząt i roślin

Szersze ujęcie taksonomii mówi, że jest to element klasyfikacji [zotpressInText item=”{5085975:B57QDEJY}”]. Elementem klasyfikacji jest typowanie czyli budowanie drzewiastej hierarchii typów (związek “jest typem”) [zotpressInText item=”{5085975:RJQTUZUH}”]. Klasyfikacje, w tym taksonomie, wyrażamy z np. z pomocą diagramów klas lub faktów (diagram faktów notacji SBVR to diagram klas zawierający wyłącznie skierowane asocjacje i związki generalizacji, patrz wcześniej opisana biblioteka).

przykład klasyfikacji wyrażonej w postaci taksonomii:

Czym jest produkt rynkowy

Przypomnijmy jak Słownik Języka Polskiego definiuje produkt:

«to, co zostało wyprodukowane i jest przeznaczone na sprzedaż»
«wytwór czyjejś działalności artystycznej, społecznej, czyjegoś umysłu itp.»

Z perspektywy rynku:

Produkt można zdefiniować jako dobro fizyczne (przedmiot), usługę (świadczenie), osobę, organizację, ideę lub miejsce zawierające w sobie cechy, które jednostki lub organizację jako niezbędne.

Produkt według koncepcji marketingowej to zespół cech i właściwości które mogą służyć do zaspokojenia konkretnych potrzeb przez potencjalnego nabywcę, użytkownika, właściciela produktu lub osobę doświadczającą możliwośći korzystania z produktu.

Produktem może być wszystko to, co można zaoferować na rynku nabywcom i co jest w stanie zaspokoić ich określoną potrzebę lub pragnienie (T.Smoleń, 2012 s. 80). (źr.: https://mfiles.pl/pl/index.php/Produkt).

Z perspektywy tego artykułu skupiamy się na przedmiotach. Opis produktu, na bazie powyższych ustaleń, mógłby mieć taki opis:

Powyżej przykładowa “Karta produktu”. Zawiera:

• kluczowe dane identyfikacyjne produktu,
• jego pozostałe (niedefiniujące) cechy (kolor, wymiary, waga itp.),
• klasyfikację zewnętrzną (atrybuty produktu nie będące cechami, przynależność do grupy), tu pojawia sie np. grupa asortymentowa,
• opis techniczny lub odnośnik do takiego opisu.

F.A.Q.

Przygotowując się do napisania tego artykułu zebrałem pytania od osób zainteresowanych jego treścią, oto one wraz z moimi komentarzami:

1. Uwzględnienie rozróżnienia w/w zarządzania produktami ze względu na na branże: FMCG, Automotive itd
   • to są właśnie grupy, czyli atrybuty nie będące cechami produktu
2. Drzewo kategorii ze zróżnicowaniem na kanał sprzedaży, b2c/b2b, krajowa/zagraniczna.
   • kanał sprzedaży to nie kategoria a atrybut taki jak grupa czy asortyment.
3. Wariantowość produktu przestrzenna czy płaska (2 osiowa 1 osiowe) jak atrybut osi wariantu wpływa na wyniki sprzedażowe (listening różnych kolorów vs. różnych rozmiarów).
   • wariant to “pod-produkt”, kolory to cechy, rozmiary to (raczej) warianty: np. produktem są buty, cechą konkretnego modelu jest kolor a rozmiary to warianty (rozmiar ma wpływ na proces produkcji, kolor nie)
4. Standard kategoryzacji (bądź jego brak) np. Google, Ceneo, heureka itp.
   • fakt, możemy mieć kilka systemów kategoryzacji, będą to odrębne cechy np. kategoria_goodle=xxx, kategoria_cene=YYY,
5. Produkt konfigurowalny czy wariantowy w liczbie kilku setek tysięcy. Osobny czy wspólny EAN.
   • konfigurowalność produktu (robi to użytkownik) nie buduje wariantów (samodzielne dopasowanie wymiarów w określonym zakresie), jeżeli są to warianty to robi to producent (klient zamawia wybrany kolor i szerokość żaluzji),
6. EAN rozpoznawany na rynku (możliwość porównania cen) czy produkt “ukryty”
   • to atrybut nie będący cechą produktu (tak jak nazwa)
7. Dzień dobry, Panie Jarosławie w artykule nie powinno zabraknąć opisu wykorzystania normy IEC 81346 oraz prac zespołu Henrika Balsleva Systems Engineering. Mam wrażenie, że te drzwi są otwarte.
   • celowo nie wchodziłem w tę normę, skupiłem sie na analizie pojęciowej, nie widzę tu kolizji z ta norma.
8. W moim obecnym projekcie erp, a jestem konsultantem, kłuczowym problemem w obszarze PIM są tzw. customy. Czyli Indexy, które są generowane ad-hoc podczas realizacji zamówienia na front-end eSklepu czy innego B2B portalu a potem wtłaczanie tych tysięcy indexów do erpa. Nie dam rady przekonać klienta do zbudowania właśnie indexu + warianty oparte np. o wariantowe i grupujące cechy. Jak Pan mierzy się z takimi wyzwaniami? Proszę o uwzględnienie mojego przypadku w planowanym artykule. Z góry dziękuję za podjęcie zagadnienia. Pozdrawiam serdecznie.
   • ja nigdy do niczego nie ‘zmuszam ani nie zakazuję”, pokazuje klientowi dwa scenariusze i ich skutki, klient wybiera (zakładam, że świadomie).
9. Wg mnie problemem nie jest technika (przykładową opisano w PN-EN 81346) czy narzędzia a mentalność kadry zarządzającej, która (tu uogólniam) nie zdaje sobie sprawy z wagi zagadnienia – bo najczęściej jest zainteresowana osiągnięciem “targetu” czy pożądanej wydajności. Być może artykuł powinien być skierowany właśnie do tych, którzy nie widzą relacji między procesami i zamiast troszczyć się o nie (na bazie zrozumienia czynników determinujących ich skuteczność) artykułują jedynie swe żądania i deklaracje. Od czasów Demina, który stwierdził, że 90% problemów ma swoje źródło w kadrze zarządzającej jakby się nic nie zmieniło. Serdecznie pozdrawiam, Panie Jarku, w Nowym Roku 🙂 Jest Pan źródłem niekończącej się inspiracji i motywacji do walki z wiatrakami 🙂
   • mogę potwierdzić: konserwatyzm bywa źródłem wielu problemów, nie tylko w tym obszarze wdrożeń, jednak bywa, że firmy może być nie stać na “przeindeksowanie” wszystkiego, wtedy polecam wykonanie idealizacji i mapowania na nią tego “co zastaliśmy”, to jest kompromis nie raz możliwy do wdrożenia.
10. W systemie SAP ERP istnieje możliwość tworzenia partii dla produktu/indeksu do którego jest przepisana nazwa. Mamy zatem sytuacje gdy sposób konfekcjonowania produktu jest po prostu partia dla indeksu produktu. W mojej ocenie nie ma lepszego sposobu rozwiązania tego problemu. Sprzedajemy produkt / indeks materiałowy a sposób pakowania ( paleta, big-bag, inne ) to informacja logistyczna mająca wpływ na warunki cenowe.
    • nie mieszajmy w to partii, która jest cechą niedefiniującą, partia ma swoją ścisła definicję: jest to raz data produkcji a raz konsekwencja numeru partii użytego surowca, osobiście odradzam stosowanie predefiniowanych atrybutów formularzy w standardowych systemach co celów innych niż te, dla których faktycznie powstały.
11. Semantyka – różnice pomiędzy wersją produktu a wariantem produktu.
    • opisane w artykule.
12. Katalog produktów podstawy – czyli baza danych tego co produkuje/wytwarza się w firmie
    • to cennik.
13. Katalog produtków metadane – najważniejsze metadane produktów,
    • to pola opisanego formularza Opis Produktu.
14. Znakowanie produktów wewnętrzne i zewnętrzne
    • to kolejne atrybuty nie będące cechą produktu.
15. Produktem może być też rodzaj sprzedawanego ubezpieczenia lub produktu finansowego, jak pożyczka, leasing, najem i tu już trudno mówić o indeksach i magazynie, ale jakże też trudno jest ułożyć pod ich różne warianty, cechy, promocje – architekturę.
    • jedyne co jest inne to to, że nie ma ilości w magazynie, ale indeks (kod usługi) jak najbardziej jest.
16. Istnieje gotowy do wykorzystania standard: RDS IEC 81346 [zotpressInText item=”{5085975:YMKLKK5U},{5085975:WPRZCU3T}”]. Wiele firm korzysta, polecam.
    • Ja też polecam ten standard, tam są definicje i modele danych. Ale wiele firm ma problem już z samym używaniem tych definicji. Przykładowo decyzja czy nowy kolor to nowy produkt czy tyko cecha? Jeżeli firma produkuje takie same długopisy w setkach kolorów, to kolor będzie cechą. Jednak firma produkująca je jako dedykowane gadżety dla IBM (Panton niebieski) i Coca-Cola (Panton czerwony) to raczej będą to dwa osobne produkty.

Źródła

[zotpressInTextBib style=”apa” sort=”ASC”]

Wprowadzenie

W roku 2013 pisałem:

Pisząc recenzję książki Modelowanie biznesowe napisałem, że kompletny model organizacji to: słownik pojęć (Glossary), model struktury organizacyjnej, reguły biznesowe (specyfikacja) oraz model procesów biznesowych korzystający z trzech poprzednich. Całość stanowi dopiero kompletny model organizacji. W Listopadzie ubiegłego roku także pisałem o modelowaniu struktury organizacyjnej. Osobiście uważam, że modelowanie struktury organizacyjnej w UML nie jest dobrym pomysłem. Są do tego prostsze narzędzia, nie przypadkiem te lepsze narzędzia CASE mają do tego dedykowany diagram. Niestety nie ma tu dedykowanej notacji, dlatego bardzo ważne jest by słownik pojęć w modelu zawierał takie pojęcia jak pracownik, komórka organizacyjne itp. Dobrym pomysłem jest zdefiniowanie własnej konwencji (diagram, symbole, definicje pojęć) np. jak ta na początku artykułu. (Modelowanie struktury organizacyjnej).

źr.: Modelowanie struktury organizacyjnej – widać światełko w tunelu – Jarosław Żeliński IT-Consulting

Po dwunastu latach praktyki analiz i modelowania, nie zmieniłem zdania, ale mam kilka wniosków. Po pierwsze patrząc na dorobek OMG warto korzystać z MOF (Meta Object Facility, [zotpressInText item=”{5085975:3DBER492}”]):

Specyfikacja MetaObject Facility Specification™ (MOF™) jest podstawą standardowego środowiska OMG, w którym modele mogą być eksportowane z jednej aplikacji, importowane do innej, transportowane przez sieć, przechowywane w repozytorium, a następnie pobierane, renderowane do różnych formatów (w tym XMI™, standardowego formatu OMG opartego na XML do transmisji i przechowywania modeli), przekształcane i wykorzystywane do generowania kodu aplikacji. Funkcje te nie są ograniczone do modeli strukturalnych, ani nawet do modeli zdefiniowanych w UML – modele behawioralne i modele danych również uczestniczą w tym środowisku, a języki modelowania inne niż UML mogą również uczestniczyć, o ile są oparte na MOF.

Po drugie warto zadbać o spójność pojęciową z BPMN i UML w obszarach definiowania ról i aktorów oraz z normami, w których pojawia sie pojęcie odpowiedzialności. Bardzo ważne jest upewnienie się jak sobie z tym radzi używane narzędzie CASE (jaką strukturę danych ma repozytorium). Jak ktoś używa prostych narzędzi (PowerPoint, Draw.io, IRO itp.) nie musi się martwić niczym, te narzędzia nie mają żadnych mechanizmów walidacji modeli i schematów [zotpressInText item=”{5085975:3DBER492}”].

I ciekawostka:

“W obliczu złożoności i wielu konkurencyjnych wymagań organizacje po prostu nie są w stanie podejmować decyzji w całkowicie racjonalny sposób. Nic więc dziwnego, że pojedynczy tępy instrument, taki jak struktura, raczej nie okaże się głównym narzędziem, które może zmienić organizacje z najlepszym skutkiem”. [zotpressInText item=”{5085975:2CHHERMF}”]

Notacja

Korzystając z MOF tak na p”W obliczu złożoności i wielu konkurencyjnych wymagań organizacje po prostu nie są w stanie podejmować decyzji w całkowicie racjonalny sposób. Nic więc dziwnego, że pojedynczy tępy instrument, taki jak struktura, raczej nie okaże się głównym narzędziem, które może zmienić organizacje z najlepszym skutkiem”.rawdę możemy zbudować swoją notację. W zasadzie robimy to zawsze wtedy gdy budujemy schematy blokowe i opatrujemy je legendą symboli. MOF wymaga by legenda ta była sformalizowana (https://wsjp.pl/):

formalizacja: procedura prowadząca do przedstawienia danej teorii lub systemu w postaci sformalizowanej, nauk.: ujmowanie czegoś w postaci ściśle określonych, precyzyjnych formuł wyjaśniających i porządkujących jakieś zjawiska

Postać sformalizowana to taka, w której pojęcia (symbole) mają ściśle zdefiniowane znaczenia i stanowią sobą przestrzeń pojęciową zupełną. Innymi słowy można, w obszarze modelowanym, jednoznacznie sklasyfikować i nazwać każdy element (np. na schemacie blokowym). Po co to robimy?

walidacja nauk.: proces sprawdzania, czy coś funkcjonuje prawidłowo i umożliwia uzyskanie zaplanowanych wyników

Celem jest utrzymanie w całym modelu jednolitych reguł walidacji modeli (np. narzędzia CASE robią to automatycznie) i taki jest cel MOF. Używamy do tego tak zwanych profili, które są sformalizowaną formą słownika kategorii (klasy pojęć). [zotpressInText item=”{5085975:JBYTQSMS}”].

Struktura organizacyjna

Czym jest i do czego nam jest potrzebna struktura organizacyjna?

Struktura organizacyjna – sposób formalnej organizacji firmy, zestaw elementów (komórek organizacyjnych: stanowisk, działów, części wyodrębnianych przez samą firmę) i powiązań między nimi (przepływów informacji, formalnych podziałów obowiązków, przynależności itp.). Struktura organizacji jest sposobem na formalne określenie relacji i zależności między jej uczestnikami – pozwala w pewnym stopniu ograniczyć proces “ucierania się” pozycji, prestiżu itp. poprzez mozolne negocjacje i rozgrywki, tak jak następuje to w organizacjach nieformalnych (w których struktura jest płynna, często postrzegana różnie przez różnych uczestników, zależy wyłącznie od autorytetu osobistego), ułatwia obieg informacji itd (D. Jemielniak i in. 2015, s. 89)

Struktura organizacji dostarcza odpowiedzi na pytania (A.Koźmiński, D. Jemielniak 2011, s. 69):

• kto z kim może i powinien kontaktować się i współpracować, a jakie związki są zakazane
• kto, o czym i o kim decyduje i kto, komu w jakiej sprawie i jak podlega
• kto, za co i za kogo odpowiada i w jaki sposób
• kto, co i od kogo wie i jak ma tę wiedzę wykorzystać
• jaki jest podział korzyści i przywilejów (materialnych, prestiżowych i innych) między członków organizacji

(https://mfiles.pl/pl/index.php/Struktura_organizacyjna) 

Potraktujmy powyższy tekst jako materiał do analizy pojęciowej. Z tekstu dziedzinowego wyodrębniamy kluczowe pojęcia i budujemy z nich ontologię (z ustawy dodano pojęcie organ):

Diagram ten to graficzna forma ontologii. Jego celem jest walidacja spójności i niesprzeczności słownika. Walidacja ta polega na testowaniu czy pojęcia połączone predykatem lub generalizacją tworzą poprawne w danym języku i prawdziwe zdania, np. (zaniedbujemy fleksję na diagramach).

• struktura organizacji opisuje firmę
• komórka organizacyjna grupuje stanowiska
• dział jest typem komórki organizacyjnej

Na podstawie tego modelu pojęciowego tworzymy tak zwany profil w MOF:

Struktura organizacyjna – przykład

Diagram (model) struktury organizacyjne to z reguły “bloczki” na tym diagramie. W prostej wersji te bloczki będą miały nazwy, a to czym one są często pozostaje często w sferze domysłów. Poniżej przykład z realnego , np.:

Dodatkowa informacja (https://ztiusepolno.pl/about/wladze-spolki/):

Zarząd spółki:

Grzegorz Gliński – Prezes Zarządu
(od dnia 01 czerwca 2017 roku)

Rada nadzorcza:

Błażej  Hubert Czerkawski – przewodniczący rady
Jerzy  Andrzej Domek – członek rady,
Aniela Danuta Jaworska – członek rady

Zgromadzenie wspólników:

Burmistrz Gminy Sępólno Kraj., jako przedstawiciel właściciela spółki.

Po przeprowadzeniu formalizacji diagram wygląda tak:

Jak widać wymaga pewnych wyjaśnień, np. Głowna Księgowa to nazwa działu czy roli: to nie jest oczywiste, wymaga potwierdzenia. Taki diagram ma proste reguły: jednostki podrzędne są poniżej swoich nadrzędnych a dany bloczek klasyfikujemy nadając tak zwany stereotyp (wyrażenie <<xxx>>). W efekcie nie mamy wątpliwości czy (tu) Główna Księgowa to rola czy dział. Widzimy także, że do rozwiązania mamy problem: co lub kto to jest “Zarząd – Prezes Zarządu”?

Podsumowanie

Formalizacja to klasyczny przykład powiedzenia brzmiącego: “Jeżeli nie potrafisz czegoś poprawnie narysować to znaczy, że nadal tego nie rozumiesz”. Po co to wszystko? Dzięki temu uzyskujemy [zotpressInText item=”{5085975:B5MY4ZNI}”]:

• możliwość budowania precyzyjnych reguł biznesowych (np. uprawnienia),
• jasne zasady podległości i odpowiedzialności,
• łatwy i szybki “onboarding” nowych pracowników, kontrahentów, kontraktorów, itp.
• mając to w narzędziu CASE mamy możliwość wykonania natychmiastowe walidacji i analizy wpływu każdej komórki organizacyjnej na procesy biznesowe, aplikacje systemu IT i odwrotnie,
• i wiele innych analiz bazujących na wzajemnie powiązanych modelach.

W firmach, którym pomagałem przeprowadzić standaryzację procesów i dokumentów, każdy pracownik dostaje i podpisuje załączone do umowy o pracę:

• dokumenty które podpisują wszyscy pracownicy firmy (np. polityka bezpieczeństwa, regulamin budynku, itp.),
• dokument opisujący stanowisko,
• opcjonalnie dokument nadający mu dodatkowe, specjalne uprawnienia lub obowiązki.

Struktura organizacyjna to materiał na aktorów w modelach procesów biznesowych (tory) a w konsekwencji także modelach przypadków użycia:

Warto zainwestować troszkę czasu w te modele, bo zły model struktury organizacyjnej to także zły model procesów i wymagań… a to w efekcie prawie pewna porażka projektu.

Bibliografia

[zotpressInTextBib style=”apa” sort=”ASC”]

Wprowadzenie

Wpis na LinkedIn:

GUI czy DSL, klikanie czy tekst? Co wybierzesz do modelowania?

Structurizr ma swój DSL, za pomocą którego opisywana jest architektura a następnie generowane są odpowiednie widoki C4. Text to Model.

Z drugiej strony możemy zamodelować strukturę bazy danych w LucidChart albo Miro klikając w GUI. Click to Model.

Jeśli mógłbyś wybrać, to którą z tych opcji preferowałbyś do modelowania i dlaczego?

Jako devsi jesteśmy przyzwyczajeni do kodowania, stąd DLS structurizra jest dla nas czymś naturalnym. Jedynym problemem jest to, że trzeba się go nauczyć. Tego problemu nie ma w przypadku GUI. Ale znowu GUI cierpi z UX gdy dodawane są kontrolki manipulujące elementami (dodaj, usuń, zmień nazwę).

Ja osobiście wolę DSL nawet jeśli potrzebuje czasu by się go nauczyć, ze względu na prostotę podglądu wygenerowanego na podstawie tekstu.

(link do źródła)

Deweloperzy często deklarują: “my wszystko dokumentujemy w modelach C4 a nie w UML, którego deweloper nie używa!” Problem? Modele C4 nie są dokumentacją działania aplikacji, są jedynie opisem jej instalacji. Sam autor (Simon Brown) w swoich publikacjach zaleca dodatkowo UML i ER by udokumentować realizowaną logikę.

(more…)