Business Motivation Model, notacja opublikowana przez organizację Object Management Group (https://www.omg.org/spec/BMM/), dostarcza model pojęciowy do analizy, tworzenia, dokumentowania biznesplanu i metod zarządzania oraz system symboli pozwalający tworzyć diagramy modelujące elementy misji i wizji, strategii i celów biznesowych organizacji, notacja BMM odwołuje do notacji BPMN i SBVR a także do modeli struktur organizacyjnych, poniżej szkielet systemu:
Jest to diagram, który na równi z Diagramem Klas, budzi bardzo często ogromne problemy interpretacyjne (patrz: Diagram klas…). Bardzo wielu autorów przypisuje temu diagramowi role, których on nie pełni, a nie raz prezentowane w sieci i literaturze przykłady są niepoprawne. Znakomita większość autorów tych diagramów używa ich jako „zbioru możliwych kliknięć” co jest całkowitym niezrozumieniem celu użycia i idei tego diagramu. Nawet jeżeli ktoś potrzebuje takiej mapy klikania, to są do tego lepszych narzędzia i metody (przykład: Mapa ekranów aplikacji – podstawa dobrego UX/UI design). Tworzenie niezgodnych z notacją diagramów przypadków użycia po prostu psuje strukturę projektu w narzędziach CASE, czyniąc ją praktycznie bezużyteczną w projektowania architektury systemu.
Najpierw opiszę krótko diagram przypadków użycia posługując sie cytatami z oryginalnej specyfikacji. Później opiszę typowe błędy.
Czym jest Diagram Przypadków Użycia
Kluczowe są tu wyjaśnienia wstępu do rozdziału UseCases Specyfikacji UML :
18 UseCases 18.1 Use Cases 18.1.1 Summary UseCases are a means to capture the requirements of systems, i.e., what systems are supposed to do. The key concepts specified in this clause are Actors, UseCases, and subjects. Each UseCase’s subject represents a system under consideration to which the UseCase applies. Users and any other systems that may interact with a subject are represented as Actors. […] 18.1.3 Semantics 18.1.3.1 Use Cases and Actors A UseCase may apply to any number of subjects. When a UseCase applies to a subject, it specifies a set of behaviors performed by that subject, which yields an observable result that is of value for Actors or other stakeholders of the subject. A UseCase is a kind of BehavioredClassifier that represents a declaration of a set of offered Behaviors. Each UseCase specifies some behavior that a subject can perform in collaboration with one or more Actors. UseCases define the offered Behaviors of the subject without reference to its internal structure.
Powyższe wytłuszczenia zebrałem poniżej, uwagi oznaczone „[…]” są moje:
Przypadki użycia są sposobem na uchwycenie [wskazanie] wymagań stawianych systemom, tzn. tego, co systemy mają robić [powody, dla których one powstaną, co będą realizowały na rzecz i na żądanie Aktora].
Każdy Przypadek Użycia reprezentuje określony cel (powód), dla którego System jest projektowany.
Przypadek Użycia jest rodzajem klasyfikatora behawioralnego, który reprezentuje deklarację zbioru oferowanych zachowań. [to znaczy, że grupuje określony kontekstowo powiązany zbiór zachowań, są to alternatywne scenariusze tego samego przypadku użycia].
Przypadki Użycia definiują oferowane zachowania [modelowanego] systemu bez odwoływania się do jego wewnętrznej struktury. (!)
Są to pryncypia budowy tych diagramów.
Związki między Przypadkami Użycia
Extend
Specyfikacja UML:
An Extend is a relationship from an extending UseCase (the extension) to an extended UseCase (the extendedCase) that specifies how and when the behavior defined in the extending UseCase can be inserted into the behavior defined in the extended UseCase. The extension takes place at one or more specific extension points defined in the extended UseCase. Extend is intended to be used when there is some additional behavior that should be added, possibly conditionally, to the behavior defined in one or more UseCases.
Związku «extend» można użyć do pokazania, że pewne elementy zachowania Systemu realizowane są warunkowo. Te dodatkowe zachowania są jednak z zasady częścią bazowego Przypadku Użycia.
Autorzy specyfikacji UML jasno piszą, że: „Szczegółowy sposób określania położenia punktu rozszerzeń jest celowo nieokreślony. Wynika to z faktu, że Przypadki użycia mogą być specyfikowane w różnych formatach, takich jak język naturalny, tabele, drzewa itp. […] Zazwyczaj, przypadek użycia z ExtensionPoints składa się z zestawu drobnoziarnistych opisów fragmentów zachowania (scenariusze), które są najczęściej wykonywane w pewnej sekwencji. Taka segmentowa struktura tekstu opisu danego przypadku użycia pozwala na rozszerzenie pierwotnego opisu zachowania przez dołączanie dodatkowych opisów, fragmentów zachowania, w odpowiednich punktach wstawiane pomiędzy pierwotne fragmenty (punkty rozszerzeń). Tak więc, rozszerzenie UseCase składa się zwykle z jednego lub więcej opisów fragmentów zachowania, które mają być wstawione w odpowiednie miejsca rozszerzanego przypadku użycia. Rozszerzenia są więc specyfikacją wszystkich różnych punktów rozszerzeń w danym przypadku użycia, w których można umieścić dodatkowe zachowania.”
Innymi słowy, formalnie można na Diagramie Przypadków Użycia pokazać, to że scenariusz przypadku użycia jest podzielony na fragmenty, które są wykonywane warunkowo. Jest to jednak modelowanie scenariusza zawierającego instrukcje „if … then”. Tu przypomnę więc kluczową zasadę, zapisaną w specyfikacji UML: „Przypadki Użycia definiują oferowane zachowania [modelowanego] przedmiotu bez odwoływania się do jego wewnętrznej struktury”. Dlatego wielu autorów zwraca uwagę na pewne, ‚takie jak ta, niekonsekwencje w specyfikacji.
Include
Specyfikacja UML:
The Include relationship is intended to be used when there are common parts of the behavior of two or more UseCases. This common part is then extracted to a separate UseCase, to be included by all the base UseCases having this part in common. As the primary use of the Include relationship is for reuse of common parts, what is left in a base UseCase is usually not complete in itself but dependent on the included parts to be meaningful. This is reflected in the direction of the relationship, indicating that the base UseCase depends on the addition but not vice versa.
Innymi słowy: jeżeli dwa Przypadki Użycia mają pewne wspólne fragmenty zachowania, można taki fragment „wyjąć przed nawias”, ten fragment jest na diagramie reprezentowany także jako Przypadek Użycia, jednak jest to niesamodzielny fragment, stanowiący część wspólną co najmniej dwóch PU bazowych i on sam z siebie nie reprezentuje samodzielnego zachowania. Ten wspólny, wyłączony fragment, łączymy z PU bazowymi związkiem «include».
Tak więc związki «include» i «extend» owszem nadal są w specyfikacji UML, jednak „Wynika to z faktu, że Przypadki użycia mogą być specyfikowane w różnych formatach, takich jak język naturalny, tabele, drzewa itp.” i ktoś może chcieć taki tekstowy format zobrazować na Diagramie.
Konsekwencje
Diagram Przypadków użycia ma rodowód w metodyce strukturalnej (stosowanie instrukcji „go to” i „subroutine” w programowaniu strukturalnym). Związki «extend» i «include» mają właśnie taki rodowód i nadal są w notacji UML, gdyż Diagram Przypadków Użycia jest nadal popularnym narzędziem w metodach strukturalnych. Jest też niekonsekwencją specyfikacji UML, co widać w jej treści, gdzie na początku rozdziału autorzy specyfikacji UML zwracają jednak uwagę, że „Przypadki Użycia definiują oferowane zachowania przedmiotu bez odwoływania się do jego wewnętrznej struktury”. Więc stosowanie powyższych związków jest reliktem metod strukturalnych, i nie należy ich stosować w projektach zorientowanych obiektowo, tym bardziej, że jest to łamanie podstawowej zasady paradygmatu obiektowego jaką jest hermetyzacja.
Autorzy specyfikacji notacji UML, takim oto przykładem podsumowują rozdział 18. Przypadki Użycia:
Jak widać celem projektowania bankomatu są: Wypłata, Wpłata, Przelew, a także: Rejestrowanie bankomatu (w sieci) i Udostępnianie listy transakcji. Detale tych działań i kolejność ich realizacji nie są przedmiotem tego modelu, nie ma tu związków «include» ani «extend», mimo, że np. trzy kluczowe operacje wymagają użycia karty płatniczej i kodu PIN (owszem, wspólna część, ale są to jednak detale scenariuszy a nie osobne PU).
Traktując więc PU zgodnie z jego podstawową, przytoczoną powyżej definicją, jako: „określony cel (powód), dla którego System jest projektowany”, uznajemy, że celem aplikacji biznesowej jest np. Rejestrowanie Zamówień czy Fakturowanie, a nie to, że „Drukujemy dokument”, „szukamy faktury” czy „wprowadzamy NIP kontrahenta”. Pokazanie drukowania jako wyłączonej części wspólnej, lub rozszerzenia, PU Faktura i Zamówienie (stosując związek «include» lub «extend»), czy też wydzielanie na diagramie PU „Wybór klienta z listy kontrahentów”, to projektowanie architektury i droga do klęski tego diagramu. To, że komponent realizujący drukowanie będzie osobnym elementem architektury tego systemu zapewne jest prawdą, ale Diagram PU, jak już wiemy, to nie jest model architektury systemu. Nie jest to także specyfikacja procesu biznesowego.
Obiektowo-zorientowane modelowanie systemu
W artykule Use Case 2.0 opisywałem koncepcję obiektowego podejścia w projektowaniu zorientowanym na Przypadki Użycia, opracowaną przez jednego z współtwórców UML: Ivara Jacobsona . W artykule Aplikacje webowe i mikroserwisy czyli architektura systemów webowych opisałem projektowanie oprogramowania oparte na obiektowym paradygmacie i wzorcach projektowych takich jak mikroserwisy. Cytowałem między innymi ten diagram:
Po prawej stronie powyższego widzimy architekturę zorientowaną na mikroserwisy. Jest to typowe i znane od lat komponentowe podejście z hermetyzacją komponentów, realizujących usługi aplikacji . Bloki [MS] (microservices) to nic innego jak komponenty realizujące Przypadki Użycia tego systemu. Każdy PU ma własną implementację (i bazę danych, dane [DB] także nie są współdzielone między przypadkami użycia). Komponent [UI] to zagregowane na jednym ekranie wywołania usług, czyli główne menu systemu. Tak więc Diagram Przypadków Użycia, to model tego głównego menu systemu, a nie model implementacji usług (nie architektura kodu i nie proces biznesowy).
Podsumowanie
Na poniższym diagramie po lewej stronie, pokazano formalnie poprawny diagram przypadków użycia. Z perspektywy projektowania zorientowanego na komponenty, oraz zachowania zasady mówiącej, że ten diagram nie służy do modelowania wewnętrznej architektury systemu, poprawna projektowo jest wersja pokazana po prawej stronie:
Warto też wiedzieć, że w konsekwencji powyższego, łączenie Aktora z wydzielonymi, niesamodzielnymi, opisami zachowań reprezentowanymi przez przypadki użycia 4 i 5, jest pozbawione logiki (podobnie jak tylko jeden PU połączony związkiem «include»).
Więc jak i gdzie pokazać owe scenariusze PU? Osobno na diagramach aktywności (role komponentów) lub na diagramach sekwencji (wywoływane operacje interfejsów). (Patrz artykuł: Diagram aktywności – kiedy).
Powyższa forma (diagram po prawej stronie) ma także praktyczną zaletę: Zamawiający zrozumie ten diagram. Diagram o po lewej, jest już praktyczną utratą komunikacji z Zamawiającym, bo mało który z nich studiuje specyfikację UML. Specyfikacja po lewej prowadzi także do ogromnego zawyżania oszacowania wycen, gdyż miary oparte na tak zwanych punktach funkcyjnych, traktują każdy PU jako samodzielną, kompletną jedną jednostkę kosztową.
A co możemy znaleźć w sieci? Poniżej kilka przykładów wraz ze źródłami, ich ocenę pozostawię czytelnikom.
przykład 1
(w notacji UML nie ma i nigdy nie było pojęcia „biznesowy przypadek użycia”, to pojęcie jest reliktem metody RUP, Rational Unified Process, z czasów gdy nie było notacji BPMN i BMM).
Jeżeli chcesz dowiedzieć sie więcej o publikowanej tu treści poniżej znajdziesz opis.
Artykuły czyli o czym tu piszę
Publikacje powstają nieregularnie: są to jeden, czasami dwa teksty każdego miesiąca. Zawierają opisy wybranych pozycji literaturowych, opisy problemów jakie napotykam w toku audytów u klientów i ich rozwiązania, oraz efekty prac badawczych.
Publikuje także informacje o planowanych konferencjach, w których biorę udział jako prelegent.
Poza tematami z obszaru analizy biznesowej i inżynierii systemów, omawiam także problemy takie jak prawo autorskie, ochrona wartości intelektualnych i know-how, bo są to kluczowe cechy dokumentów stanowiących wyniki analiz i projektowania, używane często jako załączniki do umów na dostarczenie oprogramowania.
Tematy, które można subskrybować
Audyty i Modele Biznesowe (CIM)
CIM to Computation Independent Model (modelowanie organizacji). W tej części ukazują artykuły z obszaru modelowania biznesowego, szeroko pojętej analizy biznesowej i modelowania procesów biznesowych, dokumentowania logiki biznesowej. Pojawiają się wzmianki o notacjach BPMN, SBVR, BMM.
Inżynieria i Modelowanie Systemów (PIM)
PIM to Platform Independent Model (modelowanie systemów) W tej części ukazują się artykuły z zakresu inżynierii systemów, oprogramowania, na poziomie analizy i dokumentowania logiki dziedzinowej systemów oraz projektowania ich architektury. Pojawiają się wzmianki o notacjach UML i SysML.
„Jestem dostawcą oprogramowania”
To lista na którą wysyłam zapytania ofertowe od moich klientów, tak zwane RFI, wysyłam gdy klient zleci mi przeprowadzenie tego procesu (na etapie RFI mój klient bardzo często nie chce wyjawiać siebie jako nabywcy). Drugim etapem jest zawsze rozesłanie konkretnych zapytań RFP do firm wybranych spośród oferentów RFI (zapoznaj się z przykładami).
Jeżeli reprezentujesz developera lub integratora oprogramowania oraz treść moich specyfikacji jest dla Ciebie zrozumiała i akceptujesz taką formę współpracy, zapraszam do rejestracji. Na tę listę wysyłam czasami także pytania o dostępność rynkową określonej technologii. Moimi klientami są i firmy małe i bardzo duże, być może więć część tych zapytań nie będzie pasowała każdemu…
„Jestem „C‑level” menedżerem”
Od wielu lat moi sponsorzy (zarządy firm i dyrektorzy zamawiający moje usługi) mają moje pełne wsparcie na etapie wyboru dostawcy i negocjowania umów: po opracowaniu dokumentacji do projektu wspieram moich klientów i prowadzę nadzór autorski nad pracami dostawców. Zebrałem ogromne doświadczenie nie tylko w analizie i projektowaniu systemów, ale także w obszarze prawa autorskiego w IT i ochrony know-how, którym to doświadczeniem także dzielę się na tym blogu. Jeżeli jesteś właścicielem firmy tworzącej oprogramowanie lub menedżerem w niej, to także jest tematyka dla Ciebie.
?Cechy wyróżniające nowoczesną teorię organizacji to jej pojęciowo-analityczna podstawa, jej oparcie się na danych uzyskiwanych z badań empirycznych, ale przede wszystkim jej syntetyzujący, integracyjny charakter. Te cechy wyróżniające są zawarte w filozofii, która akceptuje założenie, że jedynym sposobem badania organizacji jest traktowanie ich jako systemów? (Kostrzewski et al., 1979).
Wprowadzenie
Wbrew oczekiwaniom, tak zwane zwinne metody (agile manifesto, 2001 r.) nie poprawiły jakości projektów informatycznych, nie raz zaś spowodowały wzrost kosztów i wydłużanie terminów, a z uwagi na system rozliczeń „czas i materiał”, nie pozwalają na planowanie budżetu projektu. Średnie i duże projekty IT to nadal w ponad 80% porażki .
Sprawdzają się jednak trudniejsze, ale znacznie skuteczniejsze, metody zorientowane na modelowanie (analiza systemowa i projektowanie) oraz rezygnacja z monolitycznej architektury systemów na rzecz architektury komponentowej, wdrażanej metodami iteracyjno-przyrostowymi . Metody te pozwoliły na projektowanie rozwiązań informatycznych i wdrażanie ich w takt zmieniających sie potrzeb. Pozwalają one także na planowanie kosztów i terminów już od początku projektu . Tak powstaje tak zwana Specyfikacja SWS (Specyfikacja Wymagań Systemowych).
Model Based Systems Engineering
Modelowanie polega na abstrahowaniu od szczegółów i stworzeniu idealizacji tak, by skupić się na istocie danej rzeczy. Dobry model opisuje wyłącznie mechanizm .
MBSE to skrót od Model Based Systems Engineering (ang. inżynieria systemów oparta na modelowaniu) . System to nie tylko „system informatyczny”, to także cała organizacja, a nawet Państwo.
Celem tego krótkiego artykułu jest pokazanie standardowej ścieżki analizy systemowej i poprawy organizacji, czyli metody prowadzenia analizy stanu obecnego i projektowania rozwiązań, opartej na analizie faktów i modelowaniu , których celem jest opracowanie rekomendacji do ulepszenia organizacji . W 2008 roku OMG opublikowało specyfikację Software & Systems Process Engineering Metamodel (SPEM?), opisującą proces prac nad budową systemów, jednak wygląda na to, że prace nad tą specyfikacją nie są kontynuowane. MBSE jako metoda, wydaje się być następcą tego pomysłu (patrz: Survey of Model-Based Systems Engineering (MBSE) Methodologies) .
.
Podstawą pracy z modelami w analizie systemowej organizacji jest idealizacja . Polega ona tym by w toku analizy i poszukiwania rozwiązania zaprojektować ideał (model organizacji w wersji idealnej), następnie opracowaniu studium jego wykonalności, uzupełnieniu ideału o poznane ograniczenia i wdrożenia tak zaprojektowanego systemu . Studium wykonalności ideału to oferty dostawców rozwiązań, których rola jest nie analiza a opracowanie koncepcji wdrożenia. .
Trzy poziomy modelowanie organizacji
Organizacje można opisać na trzech kluczowych poziomach:
Enterprise Level – (poziom organizacji) jest to poziom, na którym opisuje się i modeluje, strategie organizacji i jej rolę w otoczeniu rynkowym (rynkowy łańcuch wartości). Dotyczy to także instytucji publicznych. Taki opis jako krótki dokument, jest często dostępny na stronach WWW organizacji w zakładce „O nas”, w prospektach emisyjnych, statutach itp. Model powstaje w toku formalizacji tego opisu.
Business Process Level – to środkowy poziom, na którym tworzony jest abstrakcyjny model organizacji w postaci tak zwanego wewnętrznego łańcucha wartości (proces biznesowy). Znakomita większość organizacji nie ma takiego dokumentu lub jest on nieaktualny. Powodem tego stanu rzeczy jest to, że bieżącej pracy operacyjnej jest on niepotrzebny. Model taki przynosi jednak ogromne korzyści w przypadku podejmowaniu decyzji o zmianach. Jest to wtedy podstawowy materiał obniżający ryzyko wszelkich decyzji o jakichkolwiek zmianach organizacyjnych lub planowanych wdrożeniach.
Implementation Level – to poziom opisujący szczegóły realizowanej pracy i wykorzystywanych narzędzi. To obszar treści dokumentów takich jak: zakresy obowiązków pracowników i ich kompetencji, instrukcje stanowiskowe, procedury, zarządzenia i regulacje wewnętrzne, podręczniki używania sprzętu i oprogramowania oraz wiele innych dokumentów o podobnych charakterze. Dokumenty te są potrzebne w bieżącej pracy, jednak szybkie i skutecznie podejmowanie decyzji na ich podstawie ich treści jest praktycznie niemożliwe z uwagi na ich ilość i szczegółowość.
Analiza biznesowa polega na audycie dokumentów istniejących, czyli tych z poziomu pierwszego i trzeciego na powyższym diagramie, i opracowaniu na ich podstawie Modelu Procesów Biznesowych (środkowa warstwa). Model ten to mechanizm funkcjonowania organizacji, jej abstrakcyjny obraz, pozwalający zaplanować przyszłe wdrożenie i przewidzieć jego efekty.
W toku analizy ma często miejsce standaryzacja opisu działania i strategii. Jej celem jest formalizacja opisu organizacji, bez czego nie jest możliwe dokonanie jakichkolwiek porównań np. z konkurencją, wyznaczenie celów biznesowych i wskazanie w organizacji miejsc mających wpływ na te cele.
Enterprise Level – Model biznesowy organizacji
Strategia organizacji i jej rola w otoczeniu rynkowym są kluczowe dla zrozumienia osiąganych przez organizację efektów. Mimo tego, że większość organizacji dysponuje takim opisem, są one wykonane nieformalnymi metodami, tak różnymi, że jakiekolwiek porównanie dwóch organizacji lub tej samej na przestrzeni lat jest praktycznie niemożliwe. Dlatego opracowano standard zwany Model Motywacji Biznesowej .
Standard ten stanowi sobą pewien określony system kluczowych pojęć i związków między nimi. Jego celem jest standaryzacja pojęć takich jak: misja i wizja, strategia i taktyka, wewnętrzne i zewnętrzne czynniki wpływu, cele i mierniki osiągania celu.
Business Process Level – Model procesów biznesowych organizacji
Jest to model poziomu Business Process Level. To znaczy, że nie ma tu miejsca na szczegóły opisane w dokumentach na poziomie Implementation Level. Model procesów biznesowych ma (powinien mieć) jedynie odnośniki do szczegółów trzeciej warstwy, w szczególności do procedur, reprezentowanych na tym poziomie w postaci (abstrakcyjnych) nazwanych aktywności.
Jednym z najbardziej znanych wzorców opisu tego poziomu jest tak zwany Wewnętrzny Łańcuch Wartości M. Portera, jest on nadal podstawową wiedzą każdego absolwenta studiów MBA. Model ten zakłada podział procesów na wspierające (administracja) i operacyjne. Konkurencyjność i sprawność operacyjna ma dwa obszary: w obszarze administracji, ściśle regulowanym prawem, w zasadzie konkurujemy kosztami, ale w obszarze operacyjnym, dającym znacznie większą swobodę jego kształtowania, konkurencyjność to efekt sprawności organizacji, architektury procesów biznesowych i informacji.
Wewnętrzny łańcuch wartości
Z ww. powodu w toku analizy i modelowania skupiamy sie na obszarze operacyjnym, gdyż obszar wsparcia administracyjnego, z powodu ścisłej zależności od prawa, można wesprzeć standardowym oprogramowaniem, łatwo dostępnym na rynku. Ewentualne dedykowane moduły są projektowane właśnie dla obszaru operacyjnego, bo to tu występują różnice między organizacjami i tu powstaje przewaga konkurencyjna (jeżeli dotyczy to organizacji konkurującej na rynku). Kluczem na tym etapie jest wskazanie miejsc do usprawnienia i opracowanie rozwiązania. Próby kompleksowego wdrażana „jednego systemu do wszystkiego” najczęściej kończą się niestety źle (kompleksowe wdrożenia monolitów ERPII mają bardzo złą renomę). Model Portera odnosi sie jednakowym stopniu do firm rynkowych jak i do instytucji publicznych.
Ten poziom i jego dokumentacja, to tak na prawdę efekt pracy operacyjnej i produkt wdrożenia norm jakości i procedur, strategii zatrudnienia, systemu informatycznego itp. (patrz Operational Resources w poprzednim podrozdziale). Tę dokumentację tworzą dostawcy rozwiązań oraz wewnętrzne służby administracji. Jako, że ona w różnych formach istnieje w każdej firmie, stanowi bazowy materiał źródłowy w analizach stanu obecnego. To dlatego analizę organizacji można przeprowadzić praktycznie w 100% bez kłopotliwych i kosztownych spotkań warsztatowych z pracownikami analizowanego podmiotu.
Rozwiązania informatyczne i wymagania
Niestety same spisane funkcjonalności programu czyli specyfikacja (lista) wymagań funkcjonalnych to wyłącznie idea jego powstania (wyrok SA w Poznaniu z dnia 4 stycznia 1995 r. I ACr 422/94). Precyzję opisu, dającą ochronę w postaci pełnego prawa do powstałego produktu, uzyskuje się dopiero opracowując projekt jego konstrukcji, struktur danych i mechanizmu działania, stosując wzory matematyczne, algorytmy, unikalne struktury i schematy blokowe.
Obecne czasy to wszechobecna cyfryzacja. Dlatego znakomita większość rozwiązań wspierających działania organizacji to systemy informacyjne wspierające procesy biznesowe.
Powyżej pokazano (znany od lat 90-tych ubiegłego wieku) model architektury systemów informacyjnych zorientowanej na usługi aplikacyjne. Pokazuje on związki pomiędzy procesami biznesowymi a systemami informacyjnymi, których docelowo w każdej organizacji jest więcej niż jeden.
Systemy informacyjne także modelujemy na kilku poziomach:
Business Services – jako nazwane usługi biznesowe wymagające określonych usług aplikacyjnych, wspierających określone aktywności w procesach, usługi aplikacyjne modelujemy jako przypadki użycia aplikacji (są to wymagania na rozwiązanie),
Components – jako nazwane i wyspecyfikowane komponenty aplikacyjne wraz z ich integracją (jest to opis rozwiązania),
Operational Resources – jako model opisujący faktyczne ich wdrożenie i rozlokowanie (jest to dokumentacja wdrożonego systemu).
Opracowanie specyfikacji wymagań (modeli) nie powinno nigdy w obecnych czasach trwać dłużej niż kwartał, co oznacza, że im większy projekt tym bardziej specyfikacja wymagań jest polityką (architekturą) niż detalicznym opisem. Detale są specyfikowane już w toku wdrożenia w toku nadzoru autorskiego, zgodzie z polityką budowy i wdrażania systemu (architekturą). Wycena realizacji nie powinna sprawić kłopotu, żadnej doświadczonej, znającej wzorce architektoniczne, firmie ofrującej oprogramowanie.
Praca z dostawcami rozwiązań
Praktycznie zawsze pada pytanie: a co jeżeli dostawca też robi analizę przedwdrożeniową? Otóż tu już jej nie robi bo ją dostaje. Z uwagi na ryzyko projektu i potencjalny konflikt interesu, Dostawca z zasady nie powinien być autorem wymagań (projektu rozwiązania).
Dostawca musi opracować proponowaną przez siebie Koncepcję Wdrożenia oferowanego produktu, w odpowiedzi na wymagania wyrażone w postaci modeli procesów biznesowych, struktur dokumentów i reguł biznesowych (Model Biznesowy Organizacji). Z uwagi na to, że projekty takie zawsze realizowane są metodą iteracyno-przyrostową, w toku projektu ma miejsce stała współpraca: Dostawca rozwiązania żąda kolejnych detalicznych informacji o tym jak działa firma Zamawiającego, Zamawiający, z moją pomocą (nadzór autorski), odpowiada odsyłając stale uzupełniany Model Biznesowy. Dostawca dokumentuje kolejne etapy prowadzonego wdrożenia (aktualizuje Koncepcję Wdrożenia, która staje się dokumentacją tego wdrożenia) a ja je (te dokumenty) weryfikuję, i tak aż do zakończenia wdrożenia.
Na koniec wdrożenia Zamawiający dysponuje dwoma aktualnymi dokumentami: Model Biznesowy (środkowa warstwa opisu organizacji) i Dokumentacja Wdrożenia (opisany wyżej Poziom Implementacji).
Podsumowanie
Każdy projekt związany z reorganizacją i/lub wdrażaniem nowego oprogramowania (zmian, rozbudowy) można więc przeprowadzić metodą analizy organizacji i jej modelowania na z góry ustalonym poziomie szczegółowości. Modele te są ściśle zintegrowane z sobą, a całość ma charakter opisu „od ogółu do szczegółu”.
Podejście to gwarantuje spójność, kompletności i niesprzeczność opisu na każdym etapie projektu. Dzięki temu minimalizujemy ryzyko nieudanego wdrożenia a całość trwa krótko (żaden etap analizy nie powinien trwać dłużej niż kwartał!). Prosty ale obrazowy przykład opisałem TUTAJ.
Całość literatura przedmiotu opisuje od wielu lat, metody te są stale doskonalone. Poniżej proces tworzenia oprogramowania jako projektowanie systemu:
Model systemu jest celem analizy opartej o przypadki użycia (wywodzone z procesów biznesowych) i ich scenariusze, na ich podstawie powstaje model systemu, kolejny krok to implementacja (code) jednak nadal długo jeszcze będzie to praca dla developerów .
Przypadki użycia (use case) to wynik opisanej na początku analizy biznesowej (organizacja to także system) i wyodrębnienia celów biznesowych. Mamy rok 2021 i ogromny wybór dostępnego, gotowego oprogramowania wymagającego jedynie właściwego doboru i integracji. Tak opisany wyżej system to struktura i zachowanie się dobranych komponentów, nie koniecznie jest to „pisanie dedykowanego oprogramowania od zera”, bo to ma miejsce coraz rzadziej i dotyczy ewentualnie 10 – 15% dedykowanych potrzeb niektórych firm.
Obecne na rynku systemy wspierające analizy i projektowanie (CASE: Computer Aided System Engineering) oraz wzorce architektoniczne i narzędzia informatyczne, pozwalają prowadzić analizy i modelowanie etapami trwającymi pojedyncze tygodnie a nie lata. Iteracyjno-przyrostwe metody dostarczania oprogramowania pozwalają wdrażać nowoczesne rozwiązania w okresach kwartalnych a nie lat.
Poniżej prosty przykład produktu takiej pracy:
Estefan, J. A. (2007). Survey of Model-Based Systems Engineering (MBSE) Methodologies. 47.
Harel, D. (2000). From play-in scenarios to code: An achievable dream. International Conference on Fundamental Approaches to Software Engineering, 22 – 34.
Kitchenham, B. A., Dybå, T., & Jørgensen, M. (2004). Evidence-based Software Engineering. Th International Conference on Software Engineering, 9.
Suri, K., Cuccuru, A., Cadavid, J., Gerard, S., Gaaloul, W., & Tata, S. (2017). Model-based Development of Modular Complex Systems for Accomplishing System Integration for Industry 4.0: Proceedings of the 5th International Conference on Model-Driven Engineering and Software Development, 487 – 495. https://doi.org/10.5220/0006210504870495
Jones, S. (2006). Enterprise SOA adoption strategies: using SOA to deliver IT to the business. C4Media.
Koźmiński, A. K. (1979). Decyzje: analyza systemowa organizacji. Pánstwowe Wydawn. Naukowe.
Ackoff, R. L., Magidson, J., Addison, H. J., & Ehrlich, A. (2007). Projektowanie ideału: kształtowanie przyszłości organizacji. Wyższa Szkoła Przedsiębiorczości i Zarządzania im. Leona Koźmińskiego : Wydawnictwa Akademickie i Profesjonalne.
Liu, C. (2004). Laws and Models in a Theory of Idealization. Synthese, 138(3), 363 – 385.
Jenney, J., Gangl, M., Kwolek, R., Melton, D., Ridenour, N., & Coe, M. (2010). Modern methods of systems engineering: with an introduction to pattern and model based methods. Joe Jenney.
Porter, M. E. (1998). Competitive advantage: creating and sustaining superior performance: with a new introduction (1st Free Press ed). Free Press.
Agile business analyst has the capability to keep the wheel rolling. They?re a transformative funnel through which a requirement passes down to the delivery path towards an expected outcome. This SDLC machine needs continuous fuel in the form of well-defined and informed information which is provided by an agile business analyst. As long as an agile business analyst does the job, this machine will remain on its course to deliver greater solutions.Coming to our original question, is an agile business analyst a myth or a reality? There is a clear answer. It is a reality if an organization realizes the value, but it is a myth for immature organizations whose processes are ill-defined and are nowhere on a path towards best practices. (Is Agile Business Analyst a Myth or a Reality? )
Tak więc (zwinny) analityk biznesowy to model pracy polegający na stałym dostarczaniu (na etapie implementacji) kolejnych informacji. Projekt tworzenia aplikacji zawsze trwa w czasie, więc w toku tworzenia oprogramowania zmienia się biznes.
Developerzy często mówią, że klient zmienia im wymagania, a tak na prawdę ktoś zbyt wcześnie zapisał zbyt wiele szczegółów. Implementacja dedykowanego oprogramowania to tak na prawde pętla iteracyjno-przyrostowa: zbieramy informacje potrzebne do wytworzenia jednej usługi aplikacyjnej i implementujemy ją, wszelkie szczegóły odkładamy na ostatni moment. Wymaga to jednak zmiany podejścia. Trzy lata temu pisałem na tym blogu:
Rynek zmienia się szybko, więc nie ma sensu szczegółowe projektowanie czegokolwiek z uwagi na czas jaki zajmie takie projektowanie i ryzyko, że taki projekt stanie się szybko nieaktualny. Nikt rozsądny nie namawia dzisiaj do czegoś o wdzięcznej nazwie ??waterfall?. Co więc zrobić? Dla dużych projektów tworzymy architekturę, opisujemy mechanizmy działania, politykę rozbudowy i opis cyklu życia. Czyli to co pozwoli rozwijać rozwiązanie metodą iteracyjno-przyrostową, w razie potrzeby pozwoli na przeprojektowanie, ale jako całość nadal będzie spójne, nie będzie wymagało wymiany całości gdy zmienią się warunki na rynku.Można w tym miejscu zaryzykować tezę, że nie ma czegoś takiego jak ??inżynieria wymagań? bo czym ona jest i co jest jej produktem? Uporządkowany spis życzeń? Mamy natomiast na pewno ??inżynierię systemów?.? systemami są organizacje a także narzędzia jakich używają np. oprogramowanie? (Wymagania umarły. Rozwiązaniem jest cykl życia produktu | | Jarosław Żeliński IT-Consulting)
Z czego należy więc od razu zrezygnować? Z opracowania relacyjnego modelu (bazy) danych dla całej aplikacji, i przestawić sie na idee mikro-serwisów, czyli uznania, że aplikacja nie jest monolitem a zestawem komponentów realizujących usługi aplikacyjne. Usługi aplikacyjne modelujemy jako Przypadki Użycia (notacja UML) i to stanowi kontakt z dostawcą. Jednak „czarna skrzynka” (opis nie zawierający mechanizmu działania) jest bardzo ryzykowny, dlatego skuteczne metody dokumentowania wymagań, to metody zorientowanie na modele (MDA) opisujące logikę działania systemu (model jako wymaganie), a zamiast tworzenia korporacyjnego relacyjnego modelu danych, zamykamy się w dokumentach jako elementarnych nośnikach danych (i nie boimy sie redundancji danych w całym systemie). Ogromne i szczegółowe dokumenty i modele są wyłącznie stratą czasu i pieniędzy:
(Designing Object Systems: Object-Oriented Modelling with Syntropy Textbook Binding ? November 18, 1994 by Steve Cook (Author), John Daniels (Author))
Dlatego od lat fascynuje mnie niekonsekwencja wielu developerów: najpierw wieszają psy na metodach nazywanych „waterfall”, a już chwilę potem zaczynają projektowanie jednego relacyjnego modelu danych dla całego projektu!
Zwinny Analityk Biznesowy utrzymuje pętlę iteracji przyrostu zakresu projektu: mając opracowaną architekturę całości i paradygmat (politykę) projektowania (np. obiektowy), dostarcza cyklicznie i zawsze na ostatni moment, kolejne szczegóły, bo wtedy ma największą wiedzę, i ryzyko zmiany zakresu jest najmniejsze. To się nazywa «nadzór autorski».
Tak więc kluczem do sukcesu, w dzisiejszych warunkach, jest model oparty na komponentowej architekturze i iteracyjnym dostarczaniu kolejnych usług aplikacyjnych . Jak? Analiza, projektowanie i implementacja:
Analiza biznesowa (procesy biznesowe) i systemu informacji w organizacji, i decyzja o ewentualnej standaryzacji dokumentów i procesów. (notacje BMM, SBVR, BPMN, UML)
Opracowanie modelu informacyjnego czyli szablonów dokumentów, ich wzajemnych powiązań i słownika pojęć. (notacja UML, SBVR)
Opracowaniu architektury całości i opisanie cyklu życia projektu (notacja UML).
Przejścia do fazy implementacji z nadzorem autorskim autora projektu (zarządzanie zmianą, stała aktualizacja dokumentacji systemu).
Pierwsze przy punkty, ich realizacja, nie powinny nigdy trwać dużej niż kwartał, a dokumentacja pierwotna raczej nie powinna przekroczyć nigdy 100 stron, bez względy na wielkość projektu! Im większy projekt tym bardziej dokumentacja początkowa powinna być abstrakcyjnym modelem. Innymi słowy: im większy i dłużej trwający projekt, tym bardziej jego opis powinien być strategią jego realizacji, a nie taktyką.
Czy zwinny analityk biznesowy jest mitem czy rzeczywistością? Istnieje jasna odpowiedź: to rzeczywistość, jeśli organizacja zdaje sobie sprawę z wartości takiej pracy, ale jest mitem dla niedojrzałych organizacji, których procesy są źle zdefiniowane.
Jenney, J. et al. (2010) Modern methods of systems engineering: with an introduction to pattern and model based methods. Erscheinungsort nicht ermittelbar: Joe Jenney.
Awaysheh, F.M. et al. (2019) ‘Next-Generation Big Data Federation Access Control: A Reference Model’, arXiv:1912.11588 [cs] [Preprint]. Available at: http://arxiv.org/abs/1912.11588 (Accessed: 4 January 2020).
Garland, J. and Anthony, R. (2003) Large-scale software architecture: a practical guide using UML. Chichester ; New York: J. Wiley.
Kumar, R.N.P. and Patil, S. (2019) ‘A System and Method for improving the Model Based Systems Engineering Environment capability’, INCOSE International Symposium, 29(S1), pp. 277 – 290. http://doi.org/10.1002/j.2334 – 5837.2019.00685.x.
Oprogramowanie Generator Ofert zostało zaprojektowane przeze mnie dla Biura Polonijnego Kancelarii Senatu. Zadanie jakie dostałem to opracowanie wymagań (Opis Przedmiotu Zamówienia) na aplikację, która:
pozwala składać wnioski na dofinansowanie projektów Polonii z całego świata,
składać wnioski stanowiące formularze o bardzo rozbudowanej i zmiennej w czasie strukturze, przechowywać ich kolejne wersje,
prowadzić proces oceny wniosków przez ekspertów Bura Polonii Kancelarii Senatu,
tworzyć i zawierać umowy, w których te wnioski są załącznikiem,
śledzić rozliczanie tych umów.
prowadzi archiwum tych dokumentów,
Analizę i projekt zrealizowałem zdalnie sam, w ciągu miesiąca (komunikacja). W toku przetargu nie było żadnych skarg na treść OPZ do KIO. Implementacja wykonana w ciągu pięciu miesięcy w budzęcie i terminie, pod moim nadzorem (nadzór autorski).
Łączny koszt (analiza plus prace developera) zajęły mniej niż 6 miesięcy kosztem ok. 500tys. Aplikacja nadal działa i jest rozwijana.
Całość jest na AZURE. Aplikacja działa do dziś w dobrej kondycji, jest relatywnie tania w utrzymaniu mimo corocznych zmian przepisów (w tym formularzy). Poprzednie wyceny (niektóre na bazie metod opartych o punkty funkcyjne, inne na bazie wielodniowych warsztatów z pracownikami Kancelarii Senatu czy te na bazie setek stron modeli UML baz danych i niezrozumiałych diagramów UC), dawały wielokrotnie (bywały ponad 10 krotnie) wyższe prognozy kosztów.
Dokument stanowiący Opis Przedmiotu Zamówienia (projekt techniczny) jest dostępny na stronie BIP Kancelarii pod adresem: https://www.senat.gov.pl/gfx/senat/userfiles/_public/k8/kancelaria/zam/2017/15/zalacznik_nr_1_do_siwz.pdf dlatego często służy mi za przykładową referencję. Z uwagi na to, że miewam pytania o konstrukcję schematów blokowych użyte w tym dokumencie, omówię je tu pokrótce. Między innymi całkowicie zrezygnowałem z SQL i relacyjnego modelu danych dla formularzy, dzięki czemu wielokrotnie spadła pracochłonność wytworzenia oraz późniejsze koszty utrzymania i rozwoju (między innymi co roku nieco zmienione formularze).
W takich projektach bardzo ważny jest nadzór autorski, czyli tu mój udział w projekcie w toku implementacji:
nadzoruję pracę dewelopera,
na bieżąco wyjaśniam wątpliwości developera co do dokumentacji,
na bieżąco uzupełniam dokument o nowe elementy (czas się nie zatrzymuje w dniu ogłoszenia przetargu i podpisaniu umowy z wykonawcą),
na bieżąco aktualizuję dokumentację o wszelkie podjęte decyzje architektoniczne,
w dniu oddania aplikacji do użytku, stale aktualizowany OPZ, stanowi aktualną dokumentację powstałego systemu, tu na koniec nadzoru, miał nieco ponad 80 stron.
(Dokument OPZ został w całości wykonany z użyciem oprogramowania Visual-Paradigm: wbudowanego edytora DocComposer pakietu Visual-Paradigm. Cały cykl pracy nad wymaganiami i ich dokumentowaniem nie wymaga użycia żadnych narzędzi biurowych typu Office.)
Zakres
Na tym diagramie kolorami pokazano zakres odpowiedzialności Zamawiającego i Wykonawcy. Kolor niebieski oznacza produkty, które ma dostarczyć Wykonawca. Jest to diagram przypadków użycia notacji UML. Zależności (uzależnienia) zostały zamodelowane standardowym związkiem zależności w UML. W tej postaci diagram ten często nazywany jest Modelem Kontekstowym.
Cele biznesowe
Powyższy diagram to model motywacji biznesowej (BMM). Jest to bardzo ważny diagram w projekcie: służy do określenia celu biznesowego. Jest używany do selekcji zgłaszanych wymagań biznesowych. Do zakresu projektu powinny być kwalifikowane wyłącznie wymagania wspierające cele biznesowe projektu. Pozwala to skutecznie zarządzać zakresem projektu.
Słownik i model pojęciowy
Co do zasady projekt powinien mieć Biznesowy słownik pojęć. Jest to lista pojęć wraz z ich definicjami, której celem jest zagwarantowanie jednoznaczności treści całej dokumentacji. Są to pojęcia dziedzinowe a słownik ten stanowi przestrzeń pojęciową dla innych diagramów. Diagram ten standardowo wykonuję jako Model Faktów notacji SBVR, ale jest to tak naprawdę diagram klas składający się wyłącznie z klas, związków generalizacji i skierowanych asocjacji. Celem jego budowy jest zagwarantowanie spójności i niesprzeczności pojęć w słowniku. Cechą tego diagramu (metodą kontroli jego poprawności) jest to, że każde dwa połączone skierowaną asocjacją pojęcia, tworzą (powinny) poprawne zdanie w języku naturalnym np. ?metryka zawiera fakty z historii sprawy? czy ?umowa jest typem pisma?. Nazwy klas, atrybutów, operacji, aktorów itp. na pozostałych diagramach muszą pochodzić z tej przestrzeni pojęciowej!
Poglądowa mapa procesów biznesowych
Bardzo przydatnym diagramem jest nieformalny schemat blokowy obrazujący procesy biznesowe operacyjne. Każdy ?pagonik? to abstrakcja procesu, którego detale pokazane zostaną na dedykowanych diagramach w notacji BPMN. Można taki diagram także wykonać w notacji BPMN, jednak jego adresatem są sponsorzy projektu, którzy rzadko mają łatwość posługiwania sie notacją BPMN.
Podmioty w otoczeniu Kancelarii
Diagram współpracy notacji BPMN jest tworzony w celu inwentaryzacji podmiotów zaangażowanych w procesach obsługi wniosków. Nazwy tych podmiotów stanowią potencjalne wartości atrybutów metadanych dokumentów, będą także użyte jako pule na diagramach BPMN.
Zarządzanie przepływem dokumentów
Diagram BPMN, na którym pokazano czynności związane z pracą z dokumentami. W takich przypadkach, gdzie ludzie wykonują czynności sami dobierając ich kolejność wg. ustalonych reguł (np. w instrukcjach) nie ma sensu modelowanie wszelkich wariantów z użyciem wielkiej ilości bramek i możliwych przepływów (specyfikacja BPMN 2.0.2, Figury 10.35, 10.36, 10.37).
Jeżeli przepływ pracy jest bardziej deterministyczny powstają diagramy jak poniżej.
Przypadki użycia ? usługi aplikacyjne
Diagram przypadków użycia ma pokazać usługi aplikacyjne i interesariuszy systemu (ludzi) oraz ewentualnych aktorów będących innymi aplikacjami (integracje). Tu wyjątkowo użyłem dość rzadkiej konstrukcji jaką jest generalizacja (a nie dziedziczenie! którego nie ma w UML od 2015 roku, od wersji 2.5), pokazująca że zarówno recenzenci jaki referenci to pracownicy Kancelarii. To uogólnienie to słownikowy zabieg mający na celu uproszczenie diagramu (jeden związek zależności do generalizacji zamiast dwóch do jej instancji). Jest to zabieg słownikowy, analogiczny to tego, w którym mówimy ?weterynarz leczy zwierzęta? zamiast mówić ?weterynarz leczy, psy, koty, świnki morskie? (słowo zwierzęta jest słownikową generalizacją konkretnych zwierząt). Tej rzadko używanej konstrukcji użyłem tylko z powodu presji czas i odradzam ją. Lepszą konstrukcją była by tu strukturalna metaklasa zamiast uogólnienia i związki «instanceOf» zamiast pojęciowej generalizacji, a jeszcze prościej pokazać te zależności wyłącznie na modelu pojęciowym.
Model dziedziny
Został wykonany z użyciem standardowe wzorca BCE, nie raz już opisywanego na tym blogu, po prawej strony, pokazano wybrane detale struktury repozytoriów jako realizacje.
Powyższe to wybrane kluczowe elementy projektu.
Podsumowanie
Pozostałe elementy OPZ dla Kancelarii Senatu wydają mi się dość oczywiste, tu starałem się skomentować te elementy tego dokumentu, które budzą najwięcej pytań i emocji. Są to bardzo przydatne i niedoceniane konstrukcje zarówno w notacji UML jak i BPMN.
Strona używa plików cookie, aby zapewnić Ci wygodę przeglądania poprzez zapamiętywanie Twoich preferencji i powtarzających się wizyt. Klikając "Akceptuj wszystko", wyrażasz zgodę na użycie WSZYSTKICH plików cookie. Jednakże, możesz odwiedzić "Ustawienia plików cookie", aby zapewnić kontrolowaną zgodę.
Ta strona korzysta z plików cookie, aby poprawić wygodę podczas podczas przeglądania witryny. Pliko cookie, które są sklasyfikowane jako niezbędne, są przechowywane w przeglądarce, ponieważ są niezbędne do działania podstawowych funkcji witryny. Używamy również plików cookie stron trzecich, które pomagają nam analizować i zrozumieć, w jaki sposób korzystasz z tej witryny. Te pliki cookie będą przechowywane w przeglądarce tylko za Twoją zgodą. Możesz również zrezygnować z tych plików cookie. Ale rezygnacja z niektórych z tych plików cookie może mieć wpływ na wygodę przeglądania.
Niezbędne pliki cookie są absolutnie niezbędne do prawidłowego funkcjonowania witryny. Ta kategoria obejmuje tylko pliki cookie, które zapewniają podstawowe funkcje i zabezpieczenia strony. Te pliki cookie nie przechowują żadnych danych osobowych.
Wszelkie pliki cookie, które mogą nie być szczególnie potrzebne do działania witryny i są wykorzystywane w szczególności do gromadzenia danych osobowych użytkowników za pośrednictwem analiz, reklam i innych treści osadzonych, są określane jako niepotrzebne pliki cookie. Wymagane jest uzyskanie zgody użytkownika przed uruchomieniem tych plików cookie w witrynie.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Cookie
Duration
Description
__atuvc
1 year 1 month
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
__atuvs
30 minutes
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
bcookie
2 years
LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser ID.
bscookie
2 years
LinkedIn sets this cookie to store performed actions on the website.
language
session
This cookie is used to store the language preference of the user.
lidc
1 day
LinkedIn sets the lidc cookie to facilitate data center selection.
na_id
1 year 24 days
The na_id is set by AddThis to enable sharing of links on social media platforms like Facebook and Twitter.
ouid
1 year 24 days
Associated with the AddThis widget, this cookie helps users to share content across various networking and sharing forums.
vc
1 year 24 days
The vc cookie is set by addthis.com on sites that allow sharing on social media.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie
Duration
Description
at-rand
never
AddThis sets this cookie to track page visits, sources of traffic and share counts.
browser_id
5 years
This cookie is used for identifying the visitor browser on re-visit to the website.
CONSENT
2 years
YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
uid
1 year 24 days
This is a Google UserID cookie that tracks users across various website segments.
uvc
1 year 1 month
Set by addthis.com to determine the usage of addthis.com service.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Cookie
Duration
Description
di2
1 year 24 days
AddThis sets this cookie on sites that allow sharing on social media. It is used to track user behaviour anonymously, to create usage trends that will improve relevance to their services and advertising.
loc
1 year 1 month
AddThis sets this geolocation cookie to help understand the location of users who share the information.
um
1 year 24 days
Set by AddThis for registering the user's sharing of content through social media.
VISITOR_INFO1_LIVE
5 months 27 days
A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
YSC
session
YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.
yt-remote-connected-devices
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt-remote-device-id
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt.innertube::nextId
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.
yt.innertube::requests
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.