Od czasu do czasu jestem pytany o to, kiedy używać diagramu aktywności UML. Od 2015 roku specyfikacja UML wskazuje, że diagramy te są narzędziem modelowania metod czyli logiki kodu (dla Platform Independent Model): aktywności (activities) to nazwy metod, zadania/kroki (actions) to elementy kodu (przykłady w dalszej części).
Gdy powstawał UML, diagramy aktywności były używane także do modelowanie procesów biznesowych. W roku 2004 opublikowano specyfikację notacji BPMN, która w zasadzie do roku 2015 „przejęła” po UML funkcję narzędzia modelowania procesów biznesowych. W 2015 roku formalnie opublikowano specyfikację UML 2.5, gdzie generalnie zrezygnowano z używania UML do modeli CIM. Obecnie Mamy ustabilizowaną sytuację w literaturze przedmiotu: BPMN wykorzystujemy w modelach CIM (modele biznesowe), UML w modelach PIM i PSM jako modele oprogramowania (a modele systemów: SysML, profil UML).
Na przełomie lat 80/90-tych rozpoczęto prace nad standaryzację notacji modelowania obiektowego, w 1994 opublikowano UML 0.9, w 2001 roku pojawiają się pierwsze publikacje o pracach nad notacją BPMN, jednocześnie pojawia się Agile Manifesto, od 2004 roku ma miejsce spadek zainteresowania dokumentowaniem projektów programistycznych, w 2004 rok publikowano specyfkację BPMN 1.0, od tego roku ma miejsce wzrost zainteresowania modelowaniem procesów biznesowych, powoli stabilizuje się obszar zastosowania notacji UML. W 2015 roku opublikowano UML 2.5, stosowanie analizy (CIM) i i projektowania (PIM), jako etapu poprzedzającego implementacje, stało się standardem (źr. wykresu: Google Ngram).
Tak więc obecnie:
Nie używamy diagramów aktywności do modelowania procesów biznesowych. Do tego służy notacja BPMN!
Diagram aktywności może być modelem kodu na wysokim lub niskim poziomie abstrakcji, operujemy wtedy odpowiednio aktywnościami (activity) lub działaniami (actions). Te ostatnie to w zasadzie reprezentacja poleceń programu.
Nie ma czegoś takiego jak „proces systemowy”, oprogramowanie realizuje „procedury”.
Projektując oprogramowanie zgodnie ze SPEM , powstaje Platform Independent Model. W praktyce już na tym etapie programujemy, bo tworzymy logikę i obraz przyszłego kodu. Taka forma dokumentowania pozwala także lepiej chronic wartości intelektualne zamawiającego.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Napisałem o orientacji na dokumenty w toku analiz:
Często jestem i ja pytany o to ??Jak wyjaśnić złożone rozwiązanie techniczne interesariuszom nietechnicznym?? Jak wielu mi podobnych odpowiadam: rozmawiaj dokumentami. Sponsor projektu, przyszli użytkownicy, postrzegają swoją pracę poprzez dokumenty: ich treść i układ. (Wymagania na formularze czyli diagramy struktur złożonych i XML)
Dzisiaj pójdziemy dalej, omówimy to gdzie i jak zachować tę informację. Posłużę się prostym przykładem przychodni weterynaryjnej. Artykuł będzie opisem metody podejścia do analizy zorientowanej na procesy i dokumenty.
Tekst ma dwie części: pierwsza jest opisem drogi jaka prowadzi nas do zdefiniowania tego jakie dokumenty, jaką mają (mieć) zawartość i strukturę. Praktycznie jest to opis analizy i projektowania. Druga – krótka – to przykładowa architektura logiki realizacji aplikacji, pokazująca miejsce dokumentowej bazy danych w architekturze i projekcie, czyli także projektowanie.
Celem tego wpisu jest pokazanie czym może być analiza oraz jej produkt jakim jest Techniczny Projekt Oprogramowania.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
W lutym 2017 r. opisywałem prawne aspekty pojęcia „przedmiot zamówienia” w sferze inżynierii oprogramowania. Niedawno ukazał się w prasie artykuł o domniemanym planowaniu wywłaszczenia programistów:
Sejm jest o włos od zniesienia mechanizmu ochrony autorskiej twórców aplikacji. Na razie tych, którzy informatyzowali sądy, prokuratury i komorników. 1
Wywołał on sporą burzę w branży IT, niestety większość publikowanych w mediach wypowiedzi jest bardzo powierzchowna a niestety bardzo często wręcz fałszywa. Do tego nakładają się wypowiedzi lobbystów z branży IT, niejednokrotnie przemilczające pewne fakty a nie raz stawiające wręcz nieprawdziwe tezy. Otóż, o czym nie raz pisałem, stale …
W przestrzeni publicznej toczą się spory co do tego ?czym jest oprogramowanie?, jednak moim zdaniem, większość tych sporów ma swoje źródła w niezrozumieniu specyfiki technologii informatycznych i samego prawa, część jest skutkiem celowego lub nie, mataczenia w samych umowach. Ustawodawca, moim zdaniem bardzo słusznie, zakwalifikował oprogramowanie do utworów literackich, gdyż w swej istocie jest ono zawsze zapisem analogicznym do tekstu. Osobną kwestią jest treść tkwiąca w takim utworze (o czym on jest), co podobnie jak w przypadku literackich tekstów, może mieć ale nie musi, znaczenie. Tekst Kodu programu zinterpretowana przez odpowiednią maszynę, potocznie zwaną komputerem, decyduje o tym ?czym dany komputer jest?. Raz jest programatorem pralki a raz edytorem tekstu czy grą interaktywną. Oprogramowanie często cechuje się określonym ?mechanizmem działania?. W literaturze z obszaru technik komputerowych i filozofii, bardzo często można spotkać teorię mówiącą, że ?komputer to uniwersalny mechanizm?. Innymi słowy komputer może być ?czymkolwiek?, decyduje o tym ?program komputerowy?. 2
Jeżeli nałożymy na to fakt, że zamawiający w większości nie znają i nie rozumieją prawnych aspektów ochrony wartości intelektualnych, to mamy do czynienia z obecnym ogromnym bałaganem, nie tylko w administracji publicznej, ale i z tym jakie i kto ma prawa do wykorzystywanego oprogramowania. Niestety przewaga merytoryczna jaką ma branża IT nad swoimi klientami pozwala na wiele nadużyć, szczególnie w sferze zawłaszczania know-how przez twórców oprogramowania.
Wartości intelektualne w umowach
Dzisiaj opiszę kwestie prawno-autorskie właśnie z perspektywy wartości intelektualnych w umowach. Kluczem jest uporządkowanie pojęć wykorzystywanych w umowach i ustawach.
Poniższy diagram to model pojęciowy wykonany w notacji SBVR (diagram faktów) 3:
Model pojęciowy dla praw autorskich i własności intelektualnej (opr. Jarosław Żeliński)
Opiszę treść diagramu. Poszczególne pojęcia zostały zobrazowane jako prostokąty. Linie między nimi to fakty łączące je parami w określony kontekst. Strzałki łączą pojęcia ogólne z ich szczególnymi typami. Kluczowe pojęcia: utwór, know-how oraz pole eksploatacji, zostały opisane cytatami z aktów prawnych. Zestaw powiązanych kontekstem pojęć nazywamy przestrzenią pojęciową.
Treść to zawartość wypowiedzi lub dokumentu 4. Zawartością może być (treść niesie) ta zwane know-how. Jeżeli treść ma indywidualny charakter, jest utworem. Zgodnie z prawem jest nim każda treść o indywidualnym charakterze, w szczególności specyfikacja (projekt techniczny) i kod programu komputerowego. Oba są utworami w rozumieniu prawa. Użytkownika korzysta z aplikacji (jest ona oprogramowaniem), ta może być wyrażona z pomocą symboli, wzorów i schematów blokowych lub/i w postaci kodu programu. Należy pamiętać, co bardzo ważne w branży inżynierskiej, że …
Program komputerowy napisany na podstawie opracowanego wcześniej projektu (podobnie jak każde inne rozwiązanie lub produkt) stanowi utwór zależny (jest to realizacja projektu). Utworem pierwotnym dla oprogramowania jest tu projekt tego oprogramowania (jeżeli powstał), w tym jego unikalna architektura. Oprogramowanie powstałe na podstawie projektu innego autora, powinno zostać oznaczone danymi autora tego projektu 5
Tak więc, jeżeli kod powstał na podstawie specyfikacji, jest utworem (dziełem) zależnym, jeżeli nie, jest samodzielnym utworem. Wśród wielu pól eksploatacji utworu są wydruki i uruchamianie w pamięci komputera.
Wnioski dla nabywców oprogramowania
Przede wszystkim należy podjąć decyzję o tym co licencjonujemy, do czego nabywamy prawa majątkowe i na jakich polach eksploatacji. Tak zwane oprogramowanie standardowe to produkty rynkowe sprzedawane do wielu podmiotów, tu możemy liczyć na określoną formę licencji. Jak użytkownik najczęściej na uruchamianie w pamięci komputera, ale nie na dystrybucję. Taki zakup jest relatywnie prosty a umowy licencyjne są standardowe dla danego producenta i produktu.
Problemem jest zlecenie wykonania dedykowanego dla nas oprogramowania. Kod programu jest utworem, utwór jako treść niesie (zakładamy, że tak jest) know-how firmy zlecające wykonanie dla siebie dedykowanego oprogramowania (specyfika logiki biznesowej, mechanizmy działania różnych funkcji itp.). Na pytanie czy wykonawca musi nam przekazać w umowie praw majątkowe? Może ale nie musi (wtedy sugeruję nie zawieranie umowy i szukanie innego wykonawcy). Jednak jeżeli zamawiający najpierw opracuje specyfikację (to także utwór, zawiera dokładny opis wykonania oprogramowania) i uczyni z niej element umowy na wykonanie dla niego oprogramowania, wykonawca nie ma żadnych praw (o ile mu ich nie przekażemy) do dysponowania tak wytworzonym oprogramowaniem.
W projektach dużych, kluczową częścią powinien być projekt architektury, uwzględniający prawa do poszczególnych komponentów oraz separowanie komponentów standardowych od tych zawierających nasze know-how. To dlatego najwięcej szkód przynosi kupującym oprogramowanie tak często oferowana przez dostawców kastomizacja… czyli wbudowywanie logiki biznesowej kupującego we własny już kod, tu ma miejsce całkowite przejęcie know-how przez dostawce oprogramowania.
Nie będę opisywał detali takich umów (a są one istotne), gdyż celem moim było opisanie mechanizmów prawnych ich konstruowania i mechanizmów ochrony. Chciałem tu przede wszystkim wskazać mechanizm nadużyć polegający na tym, że: dostawca oprogramowania oferuje (forsuje) pracę bez uprzedniego specyfikowania aplikacji (tak zwane zwinne projekty agile) lub oferuje samodzielne wykonanie takiej specyfikacji (pod nazwą analiza wymagań, analiza przed-wdrożeniowa itp.). W obu przypadkach pełnię praw autorskich (osobiste i majątkowe) pozostają przy twórcy kodu. Pozycja negocjacyjna nabywcy jest tu bardzo słaba. Dzięki temu mechanizmowi bardzo wiele form produkujących oprogramowanie wymusza na administracji publicznej zakupy z wolnej ręki, podobnie zresztą w firmach prywatnych: monopolizują prawa do oprogramowania i praktycznie całkowicie blokują konkurencję a użytkownika skazują na siebie jako dostawce usług utrzymania i rozwoju.
Dlatego niezależnie od tego co sądzimy o metodach zwinnych, warto zadbać o swoje know-how i dokumentować je. Nie warto także zlecać prac analityczno-projektowych producentom oprogramowania.
Wspomniane na początku „wywłaszczanie” programistów ma zaradzić takim nadużyciom na przyszłość. Osobną jednak kwestią, nie na ten artykuł, jest sposób przeprowadzenia tego.
___
2017-08-07 Temat stał się na tyle gorący, że Pani red. Sylwia Czubkowska w Gazecie Prawnej kontynuowała temat w rozmowie ze mną:
? Doradzałbym szklankę zimnej wody. Owszem, ten przepis jest źle napisany, ale nie jest wcale bezpodstawny. To, że w tym wypadku resort sprawiedliwości, a za chwilę może po prostu rząd, myśli o tym, by ustawowo nakazać przekazanie kodów źródłowych, z których korzysta administracja, nie jest wcale nieuzasadnione ? ocenia Jarosław Żeliński, założyciel i główny analityk firmy IT-Consulting, zajmującej się doradztwem przy inwestycjach w nowe technologie. ? Ustawowe wywłaszczenie to metoda skrajna, ale niestety może okazać się czasami niezbędne. Przecież państwo, czyli jego instytucje, za te programy firmom zapłaciło, a w niejednym przypadku wcale nie dostało pełnowartościowego produktu. Często z własnej winy, bo nie dopilnowało od razu, by zabezpieczyć swoje prawa także do kodów. A bez nich niestety produkt jest niepełnowartościowy. Czasem jednak taka konstrukcja umów to polityka firm, które kodów nie chcą przekazywać ? tłumaczy ekspert. A nie chcą, bo dzięki temu instytucja publiczna ? nie mając kodów ? jest zmuszona, by kolejne zlecenia dawać ich właścicielowi. (6)
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Pomijając ich warianty, stosowane są dwie metody (grupy metod) dokumentowania wymagań i zarządzania nimi. Zakładamy, że są to wymagania wobec produktu (rozwiązania) jaki ma dostarczyć jego dostawca. W BABoK (Business Analysis Body of Knowledge), wymagania te musi spełnić dostarczony produkt, jednak oczywiście rozliczany jest dostawca rozwiązania.
Stosowane są trzy metody (grupy metod) specyfikowania wymagań:
Specyfikacja wymagań funkcjonalnych i poza-funkcjonalnych (i warianty tej metody).
Specyfikowanie tak zwanej „czarnej skrzynki” (przypadki użycia).
Specyfikowanie tak zwanej „białe skrzynki” (przypadki użycia + model dziedziny systemu).
Pierwsza i najstarsza metoda bazuje na założeniu, że zamawiający i (lub) przyszły użytkownik wie czego chce. Wymagania w postaci listy (funkcjonalne i poza-funkcjonalne) kolekcjonowane są na warsztatach, burzach mózgów, tak zwanych sesjach JAD (ang. [[Joint Application Development]]), bywa, że z pomocą ankiet. Powstaje lista (tabela) z odpowiednio oznaczonymi i sklasyfikowanymi wymaganiami.
„Czarna skrzynka” to wymagania opracowane w postaci opisu rozwiązania skupiającego się wyłącznie na jego zewnętrznych cechach, zmusza do wyspecyfikowania tego do czego ma ono służyć, jednak nie opisuje mechanizmu jego działania, specyfikacja przypadków użycia w zasadzie zamyka się na udokumentowaniu bodźca i efektu (stan początkowy i końcowy) każdego przypadku użycia (usługi specyfikowanej aplikacji), wyjaśnienie np. sposobu wykonania obliczeń – owszem – dokumentowane jest w postaci np. wzorów matematycznych czy algorytmów, jednak taka cecha jak np. „możliwość skojarzenia wszystkich zamówień, na bazie których powstała zbiorcza faktura na koniec miesiąca” pozostaje tylko nazwanym wymaganiem, specyfikacja taka nie zawiera opisu mechanizmu pozwalającego na taka operację.
„Biała skrzynka” to specyfikacja jak wyżej, uzupełniona o opis (model) np. mechanizmu pozwalającego na skojarzenie tych zamówień z właściwą fakturą.
BABoK generalnie wskazuje (skupia się) na dwóch ostatnich metodach.
W każdym projekcie trwającym w czasie i dopuszczającym zmiany w jego zakresie (w wymaganiach) pojawia się potrzeba zarządzania zmianami, zaspokajana praktycznie zawsze z pomocą tak zwanego wersjonowania. Wersjonowanie wymagań w postaci płaskiej listy wymagań funkcjonalnych i poza-funkcjonalnych, jest żmudne, sprowadza się do niezależnego wersjonowania treści (brzmienia) każdego wymagania wraz z możliwością pojawienia się nowego i usunięcia już istniejącego (lub nadania mu statusu „odrzucone”). Opisał to ładnie Miał Wolski:
Zmiany w wymaganiach wymaga ich wersjonowania. Wersje wymagań pomagają uzyskać dostęp do określonego stanu wymagania w trakcie życia oprogramowania. Najczęściej wersje wymagań określane są za pomocą kolejnych ich numerów. Najbardziej popularnym sposobem nadawania numerów wymagań jest złożenie numeru z wersji wymagania oraz przyrostu, oddzielonych znakiem kropki. Wersja 1.3 oznacza wtedy 1 wersję wymagania i 3 przyrost. (Źródło: Wymagania ? Zarządzanie wersjami | Michał Wolski)
Zupełnie inaczej wygląda w pozostałych dwóch metodach. Zarówno „czarna skrzynka” jak i jej „biała” odmiana, to są już projekty rozwiązania (np. aplikacji), „biała skrzynka” zawiera wewnętrzną architekturę. Wobec tego jest to „jeden projekt” a nie np. „czterysta wymagań”. Wersjonowaniu podlega tu jeden projekt, dzięki temu sam proces wersjonowania i zarządzanie nim staje się znacznie prostszy (można to robić np. z pomocą systemów zarządzania wersjami takimi jak [[CVS]], [[SVR]] itp.). Owszem, projekt może zawierać wiele detali, żeby ułatwić znalezienie różnicy między wersjami (tego co zostało właśnie zmienione) na początku dokumentu (specyfikacji projektu) umieszcza się tak zwany regestr zmian (dotyczy całego projektu).
Opracowanie listy wymagań funkcjonalnych i poza funkcjonalnych jest relatywnie najprostsze, nie wymaga od pracowników zamawiającego dodatkowych kwalifikacji, mogą w tym procesie brać udział przyszli użytkownicy, jednak utrzymanie kompletności, spójności i niesprzeczności takiej specyfikacji jest najtrudniejsze.
W przypadku „skrzynek” już sam fakt, że są one projektem (pewną konstrukcją) pozwala stosować do ich opisu typowe inżynierskie metody takie jak modelowanie. Model można testować więc zagwarantowanie spójności, kompletności i niesprzeczności jest łatwiejsze, problemem pozostaje co najwyżej kompletność, czyli odpowiedź na pytanie „Czy to są wszystkie wymagane funkcje”. Ryzyko jakie stwarza „czarna skrzynka” to pozostawienie dostawcy (wykonawcy, developerowi) decyzji o postaci mechanizmu działania (jego zaprojektowanie). Dostawca może go zbyt uprościć lub wręcz nie rozumieć i powstanie coś co nie realizuje w 100% logiki biznesowej danej organizacji. „Biała skrzynka” niweluje to ryzyko: powstaje tu projekt wewnętrznej logiki: mechanizm działania aplikacji.
Konsekwencje. Wydawało by się, że pierwsza metoda jest najtańsza, bo projektowanie jest kosztowniejszą pracą bo wymaga znacznie większych kompetencji niż prowadzenie warsztatów, sam przyszły użytkownik z reguły nie posiada tych kompetencji i musi za nie zapłacić. Niestety jest to prawda dla małych projektów, tam gdzie pojawiają się wymagania w ilości setek i nie raz tysięcy, samo zarządzanie nimi jest tak pracochłonne, że koszt rośnie szybciej niż liczba tych wymagań.
Po przekroczeniu pewnego poziomu złożoności znacznie lepsze są metody systemowe oparte na projektowaniu („skrzynki”), i tu ważna uwaga: projektowanie to etap specyfikowania wymagań, jeżeli projekt opracuje zamawiający, niweluje ryzyka jakie niesie ze sobą zlecenie projektowania developerowi: prawdopodobnie będzie upraszczał projekt (obniżał swój koszt) i bardzo prawdopodobne, że będzie forsował swoje dotychczasowe doświadczenie z firmy o podobnym charakterze co niestety bardzo często prowadzi do nieuprawnionego powielenie cudzej i niekoniecznie dobrej, logiki biznesowej. Do tego pojawia się problem (duże ryzyko) zawłaszczenia przez dostawcę praw autorskich do projektu tej biznesowej logiki i całego mechanizmu działania aplikacji a tym samym organizacji (o czym nie raz tu już pisałem).
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
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.