Spis treści – Archimate 2.0

Elementy

Interesariusz (Stakeholder)

Interesariusz jest zdefiniowany jako rola jednostki, zespołu lub organizacji (lub jej pochodnej), która może pozostawać pod wpływem lub mieć wpływ na wynik architektury.

Interesariusz posiada jedno lub więcej zainteresowań (lub trosk) dotyczących organizacji i jej architektury korporacyjnej. Interesariusze zmieniają, ustawiają lub podkreślają cele organizacji, w taki sposób aby realizowały ich interesy lub troski. Przykładami interesariuszy są CEO, dyrektor rady, klienci, biznes, architekci oprogramowania, jak i ustawodawcy.

image

Notacja dla interesariusza

Na modelu poniżej został przedstawiony przykład modelowania interesariuszy. Zostali zamodelowani dwaj główni Interesariusze: Zarząd i Klient. Zarząd został utworzony z trzech innych interesariuszy: CIO, CEO, CFO.

image

Przykład użycia interesariusza

Czynnik sterujący (Driver)

Czynnik sterujący jest zdefiniowany jako element który tworzy, motywuje lub napędza zmiany w organizacji.

Czynnik sterujący może być wewnętrzny – w takim wypadku jest zazwyczaj powiązany z interesariuszem. Przykładem czynników sterujących (lub „trosk”) są „Satysfakcja klienta”, „Zgodność z prawem”, czy „Rentowność”. Czynnik sterujące także mogą być zewnętrzne, np. zmiany ekonomiczne lub zmiany prawa.

image

Notacja dla czynnika sterującego

Na modelu poniżej zostały przedstawione przykłady zastosowania wewnętrznych i zewnętrznych czynników sterujących dla zmian. Interesariusze CEO i Klient współdzielą troskę o satysfakcję klienta. CEO dodatkowo ma przypisaną troskę dotyczącą satysfakcji akcjonariuszy, które są dalej rozłożone na dwa podrzędne czynniki sterujące Wartość akcji i Zysk. Został także zamodelowany zewnętrzny czynnik sterujący Zmiany ekonomiczne, który ma wpływ na wewnętrzny czynnik Wartość akcji.

image

Przykład użycia czynnika sterującego

Ocena (Assessment)

Ocena jest zdefiniowana jako wynik pewnej analizy dla czynnika sterującego.

Ocena może ujawniać silne i słabe strony, szanse i zagrożenia dla jakiegoś obszaru zainteresowania. Ocena powinna wpływać na aktualizację aktualnych lub powstawanie nowych celów, a także wywoływać zmiany w architekturze korporacyjnej. Silne i słabe strony występują wewnątrz organizacji. Szanse i zagrożenia na zewnętrz. Słabe strony i zagrożenia mogą być rozważane jako problemy, które powinny być rozwiązane poprzez cele, które będą je eliminować. Silne strony i szanse powinny być tłumaczone bezpośrednio na cele. Na przykład ocena słabej strony „Klienci narzekają na helpdesk” powinna być zdefiniowana jako cel „Usprawnić działanie helpdesk”. Natomiast szansa „Klienci preferują ubezpieczenia, które mogą być zarządzane on-line”, powinno być zdefiniowane jako cel „Wprowadzenie zarządzania portfelem usług on-line”.

image

Notacja dla oceny

Model poniżej opisuje ocenę czynników sterujących Satysfakcja klienta oraz Obsługa wsparcia helpdesk. Wszystkie przedstawione oceny reprezentują słabości. Odnośnie oceny ogólnej satysfakcji klienta wyszczególniono problemy dotyczące narzekań klientów oraz rezygnacji klientów z firmy ArchiSurance. Dalsza ocena narzekań klientów pozwoliła na podzielenie skarg na cztery bardziej szczegółowe problemy.

image

Przykład użycia oceny

Cel (Goal)

Cel jest definiowany jako końcowy stan, który chce osiągnąć interesariusz.

Cel może reprezentować dowolny stan, jaki ma zostać osiągnięty przez interesariusza, np. załatwienie sprawy lub wyprodukowanie jakiejś wartości. Cele mogą być zdekomponowane, aby określić bardziej szczegółowe cele, łatwiejsze do opisania. Na przykład cel „zwiększenie przychodu, może zostać zdekomponowane na cele „redukcja kosztów” i „zwiększenie sprzedaży”. Cele często są opisywane z wykorzystaniem słów opisujących jakość, np. „zwiększenie”, „zmniejszenie”, „poprawienie” lub „uproszczenie”. Przykładami celów mogą być np. zwiększenie przychodu lub zmniejszenie czasu oczekiwania na serwis.

image

Notacja dla celu

Model poniżej przedstawia użycie celów adresujących ocenę czynnika sterującego Koszt, którego ocena wykazała za duże koszty oprogramowania oraz za duże koszty pracownicze. Za duże koszty oprogramowania, zostały zaadresowane przez cele Redukcja kosztów utrzymania oraz Redukcja bezpośrednich kosztów oprogramowania. Za duże koszty pracownicze natomiast zostały zaadresowane przez Redukcję obciążenia pracowników, która została rozdzielona na cele Ograniczenie pracy wykonywanej ręcznie oraz Redukcję interakcji z klientami.

image

Przykład użycia celu

Wymaganie (Requirement)

Wymaganie jest zdefiniowane jako deklaracja potrzeby, która ma zostać zrealizowana przez system.

Wymagania modulują właściwości tych elementów, które są potrzebne do osiągnięcia końcowych celów biznesowych, które są zamodelowane przez elementy typu cel. Cele te są realizowane przez wprowadzenie zmian w aktualnych systemach lub przez tworzenie nowych systemów w organizacji. Termin „system” w tym kontekście ma ogólne znaczenie i może się odnosić np. do grupy powiązanych (funkcjonalnością) elementów, a następnie każdy z tych elementów może być rozważany jako oddzielny system. Dlatego jako system może występować każdy element organizacji, taki jak aktor biznesowy, komponent aplikacji, proces biznesowy, czy obiekt danych.

Na przykład, jeden lub dwa alternatywne wymagania mogą realizować cel dotyczący usprawnienia zarządzania portfelem: (i) przypisanie opiekuna do każdego klienta lub (ii) wprowadzenie aplikacji do zarządzania portfelem on-line. Pierwsze z nich może zostać zrealizowane przez aktora biznesowego, drugie przez nowe oprogramowanie. Te wymagania mogą być następnie zdekomponowane, tak aby definiowały wymagania dotyczące aktora biznesowego (np. zakres jego wiedzy) lub oprogramowania (np. wymaganie dotyczące sposobu implementacji aplikacji).

image

Notacja dla wymagania

Model poniżej ilustruje rozkład celów wobec wymagań. Cele Ułatwienie samoobsługi i Wprowadzenie efektywniejsze interakcji z użytkownikiem powstały z dekompozycji celu Redukcji interakcji z klientami, który jest częścią dekompozycji celu Redukcja obciążenia pracowników. Cel Ułatwienie samoobsługi może zostać zrealizowany przez wymagania Zapewnienie dostępu do portfela on-line oraz Zapewnienie dostępu do informacji on-line. Oba te wymagania są realizowane przez określone komponenty aplikacji. Natomiast oba wymagania Przypisanie opiekuna do klienta oraz Zapewnienie dostępu do portfela on-line realizują Usprawnienie zarządzania portfelem.

image

Przykład użycia wymagania

Ograniczenie (Constraint)

Ograniczenie jest zdefiniowane jako restrykcja opisująca sposób w jaki system zostanie zrealizowany.

W odróżnieniu do wymagania, ograniczenie nie precyzuje jaka funkcjonalność ma być zrealizowana przez system, a nakłada ograniczenie w jaki sposób system ma być zrealizowany. To mogą być restrykcje dotyczące sposobu implementacji systemu (np. specyfikujące technologię jaka zostanie wykorzystana) lub ograniczeń procesu implementacyjnego (np. czasu lub budżetu).

image

Notacja dla ograniczenia

Na modelu poniżej został przedstawiony przykład zastosowania ograniczeń do projektu realizacji oprogramowania. Pierwsze dotyczy wysokości budżetu przeznaczonego na projekt, drugie dotyczy technologii jaka ma być użyta do implementacji komponentu aplikacji realizowanego w projekcie.

image

Przykład użycia ograniczenia

Pryncypium (Principle)

Pryncypium jest zdefiniowane jako zasada określająca właściwości wszystkich systemów w danym kontekście lub sposób w jaki są one realizowane.

Pryncypia są ściśle powiązane z celami i wymaganiami. Podobnie jak wymagania, pryncypia definiują pożądane właściwości systemów. Jednak pryncypia mają szerszy zasięg i są bardziej abstrakcyjne od wymagań. Pryncypium definiuje ogólną właściwość, która ma zastosowanie do wszystkich systemów w danym kontekście. Wymaganie natomiast definiuje właściwość, która ma zastosowanie do określonego systemu.

image

Notacja dla pryncypium

Model poniżej przedstawia pryncypium System powinien być przyjazny użytkownikowi, które realizuje cele Redukcja interakcji z klientem oraz Ograniczenie pracy wykonywanej ręcznie. Pryncypium to następnie jest wyspecyfikowane przez dwa wymagania: Zapewnienie dostępu do portfela on-line oraz Zapewnienie dostępu do informacji on-line.

image

Przykład użycia pryncypium

Relacje

Relacja agregacji (Aggregation Relationship)

Relacja agregacji modeluje zamiar podzielenia jakiegoś przedsięwzięcia, na kilka innych przedsięwzięć.

Relacja agregacji jest zazwyczaj stosowana do opisu pewnej intencji w bardziej szczegółowy sposób, przez jej dekompozycję.

image

Notacja dla relacji agregacji

Alternatywnie relacja agregacji może zostać przedstawiona przez zagnieżdżenie elementów modelu.

Na modelu poniżej zostały przedstawione dwa sposoby na zaprezentowanie dekompozycji celu Redukcja obciążenia pracowników, na cele podrzędne Ograniczenie pracy wykonywanej ręcznie oraz Redukcja interakcji z klientami.

image

Przykład użycia dla relacji agregacji

Relacja realizacji (Realization Relationship)

Relacja realizacji pozwala zamodelować sytuację, w której jeden element realizuje inny.

Relacja realizacji pozwala na zamodelowanie następujący relacji:

1. Cel jest realizowany przez principium, ograniczenie lub wymaganie.

2. Principium jest realizowane przez ograniczenie lub wymaganie.

3. Wymaganie jest realizowane przez system, który może być reprezentowany przez dowolny element organizacji.

image

Notacja dla relacji realizacji

Model poniżej przedstawia kilka możliwych użyć relacji realizacji. Pryncypium System powinien być przyjazny użytkownikowi realizuje cele Redukcja interakcji z klientem oraz Ułatwienie samoobsługi. Wymaganie Zapewnienie dostępu do portfela on-line realizuje pryncypium System powinien być przyjazny użytkownikowi. Wymaganie to natomiast jest realizowane przez Usługę dostępu do portfela on-line.

image

Przykład użycia relacji realizacji

Relacja wpływu (Influence Relationship)

Relacja wpływu modeluje, że jakiś element motywacji ma pozytywny lub negatywny wpływ na inny motywacyjny element.

Element motywacyjny jest realizowany do pewnego stopnia. Wpływ innego elementu motywacyjnego może zmienić ten stopień pozytywnie lub negatywnie. Na przykład stopień dla celu podniesienia satysfakcji klienta może zostać wyrażony za pomocą procentu zadowolonych klientów, którzy zgodzą się uczestniczyć w danym badaniu. Procent ten może zostać podwyższony przez poprawę czasu obsługi klienta.

image

Notacja dla realizacji wpływu

Na modelu poniżej zostały przedstawione dwa wymagania Przypisanie opiekuna klienta oraz Zapewnienie dostępu do portfela on-line, które realizują cel Usprawnienie zarządzania portfelem. Wymagania te mają wpływ na inne elementy motywacyjne. Na przykład wymaganie Przypisanie opiekuna klienta pozytywnie wpłynie na cel Zwiększenie satysfakcji klienta, natomiast negatywnie wpłynie na cel Redukcja obciążenia pracowników oraz pryncypium System powinien być przyjazny użytkownikowi.

image

Przykład użycia relacji wpływu

Punkty widzenia

Punkt widzenia interesariuszy

Punkt widzenia interesariuszy pozwala projektantowi lub analitykowi na zamodelowanie interesariuszy, wewnętrznych i zewnętrznych czynników sterujących dla zmian oraz ocen (z uwzględnieniem mocny i słabych stron, szans i zagrożeń) dla tych czynników. Może także opisywać (na wysokim poziomie abstrakcji) cele, które mają za zadanie rozwiązanie trosk interesariuszy.

image

Przykład modelu dla punktu widzenia interesariuszy

Punkt widzenia realizacji celów

Punkt widzenia realizacji celów pozwala na uszczegółowienie celów wysokiego poziomu, za pomocą bardziej szczegółowych/konkretnych celów oraz określenie tych bardziej szczegółowych celów za pomocą wymagań i ograniczeń, które określą właściwości jakie muszą być spełnione dla realizacji tych celów.

image

Przykład modelu dla punktu widzenia realizacji celów

Punkt widzenia kontrybucji celów

Punkt widzenia kontrybucji celów pozwala projektantowi analitykowi na zamodelowanie wpływu wymagań na cele. Model ten może posłużyć do analizy wpływu celów na inne cele lub do wykrycia konfliktów pomiędzy celami interesariuszy.

image

Przykład modelu dla punktu widzenia kontrybucji celów

Punkt widzenia pryncypiów

Punkt widzenie pryncypiów pozawala analitykowi lub projektantowi zamodelować pryncypia, które są istotne dla określonych problemów projektowania, włączając cele, które motywują powstanie tych pryncypiów.

image

Przykład modelu dla punktu widzenia pryncypiów

Punkt widzenia realizacji wymagań

Punkt widzenia realizacji wymagań pozwala projektantowi na zamodelowanie realizacji wymagań przez inne elementy, takie jak aktorzy biznesowi, usługi i procesy biznesowe, usługi i komponenty aplikacji, itd. Zwykle wymagania wynikają z uszczegółowienia celów.

image

Przykład modelu dla punktu widzenia realizacji wymagań

Punkt widzenia motywacji

Punkt widzenia motywacji pozwala projektantowi lub analitykowi na zamodelowanie aspektów motywacyjnych, bez skupiania się na konkretnych elementach związanych z tym aspektem. Na przykład ten punkt widzenia może być wykorzystany do przedstawienia całościowego lub częściowego opisu aspektu motywacyjnego dla powiązanych interesariuszy, ich podstawowych celów, pryncypiów które są stosowane, oraz podstawowych wymagań dla usług, procesów, aplikacji i obiektów.

image

Przykład modelu dla punktu widzenia motywacji

Spis treści – Archimate 2.0

Chcę otrzymywać powiadomienia o nowych wpisach na tym blogu

Wyrażam zgodę na przetwarzanie powyższych danych. Potwierdzam zapisanie się na newsletter w celu otrzymywania powiadomień o nowych wpisach. (Mogę wypisać się w dowolnym momencie)

FreshMail.pl
 
Close