Modelowanie celu

Model celu jest elementem inżynierii wymagań , który może być również szerzej wykorzystywany w analizie biznesowej . Powiązane elementy obejmują analizę interesariuszy , analizę kontekstu i scenariusze , a także inne obszary biznesowe i techniczne.

Zasady

Cele to cele, które system powinien osiągnąć poprzez współpracę aktorów w zamierzonym oprogramowaniu iw środowisku. Modelowanie celów jest szczególnie przydatne we wczesnych fazach projektu. Projekty mogą dotyczyć tego, w jaki sposób planowany system spełnia cele organizacji (patrz także ), dlaczego system jest potrzebny i jak można zająć się interesami interesariuszy.

Model celu:

  • Wyraża relacje między systemem a jego otoczeniem (tj. nie tylko co system ma robić, ale dlaczego). Zrozumienie, jakie to daje, powodów, dla których system jest potrzebny w swoim kontekście, jest przydatne, ponieważ „systemy są coraz częściej wykorzystywane do fundamentalnej zmiany procesów biznesowych, a nie do automatyzacji ugruntowanych praktyk”.
  • Wyjaśnia wymagania: określenie celów prowadzi do pytania „dlaczego”, „jak” i „jak inaczej”. Wymagania interesariuszy są często ujawniane w tym procesie, co zmniejsza ryzyko pominięcia wymagań lub nadmiernego określenia (prośby o rzeczy, które nie są potrzebne).
  • Umożliwia przekształcenie dużych celów w małe, możliwe do zrealizowania cele:
  • Radzi sobie z konfliktami: modelowanie celów może identyfikować i pomagać w rozwiązywaniu kompromisów między kosztami, wydajnością, elastycznością, bezpieczeństwem i innymi celami. Może ujawnić rozbieżne interesy interesariuszy. Może identyfikować konflikty, ponieważ osiągnięcie jednego celu może kolidować z osiągnięciem innych celów.
  • Umożliwia pomiar kompletności wymagań: wymagania można uznać za kompletne, jeśli spełniają wszystkie cele w modelu celów.
  • Łączy wymagania z projektem: na przykład i* „rama wymagań niefunkcjonalnych (NFR)” wykorzystuje cele do kierowania procesem projektowania.

Notacje

Istnieje kilka notacji używanych do modeli celów w tworzeniu oprogramowania, w tym:

Naukowcy zaproponowali inne notacje, podczas gdy notacja struktury celów (GSN) i GRL są czasami używane do tworzenia przypadków bezpieczeństwa w celu spełnienia wymagań organu regulacyjnego w branżach związanych z bezpieczeństwem.

Modelowanie celów w i*

Główny artykuł: ja*

Notacja modelowania celów i* udostępnia dwa rodzaje diagramów:

  • „Strategiczna zależność” (SD), definiująca relacje między rolami pod względem konkretnych celów, których zapewnienie jednej roli zależy od drugiej.
  • „Strategiczne uzasadnienie” (SR), analizujące cele zidentyfikowane w modelu SD na cele i zadania pomocnicze.

i* pokazuje każdą rolę (aktora, agenta lub stanowisko) jako duże koło zawierające cele, zadania i zasoby, które posiada ta rola. Własność w i* oznacza, że ​​rola pragnie zaspokojenia swoich celów, albo dla własnej korzyści, albo dla korzyści jakiejś innej roli. Celom mogą towarzyszyć „przeszkody” (cele negatywne), które należy pokonać. Cele niefunkcjonalne można modelować jako „miękkie cele” w i*: są one przedstawiane jako chmury lub wcięte owale.

Modelowanie celów w KAOS

Główny artykuł: KAOS (tworzenie oprogramowania)

Notacja modelowania celów KAOS zapewnia sposób definiowania celów i przeszkód, poparty formalną (matematyczną) metodą analizy.

Modelowanie celów w UML

Główny artykuł: Diagram przypadków użycia

Diagram przypadków użycia UML zapewnia prostą notację modelowania celów. Bąbelki nazywają cele funkcjonalne, więc diagram przypadków użycia tworzy prosty model celów obejmujący tylko funkcje: jak pisze Cockburn, przypadki użycia obejmują tylko wymagania behawioralne. Role są pokazane jako aktorzy (stickmen na diagramie), powiązani z przypadkami użycia, w których biorą udział. Przypadki użycia są rysowane jako eliptyczne bąbelki, reprezentujące pożądane cele behawioralne.

Po dodaniu przypadków nadużyć notacja może modelować zarówno pożądane cele, jak i aktywne zagrożenia. Notacja przypadków nadużyć pokazuje negatywnych (prawdopodobnie wrogich) interesariuszy jako głównych aktorów przypadków nadużyć; można je zgrupować po prawej stronie diagramu. Notacja może pomóc w odkryciu odpowiednich celów łagodzących lub zapobiegawczych, przedstawionych jako pomocnicze przypadki użycia. Często mają one na celu poprawę bezpieczeństwa, bezpieczeństwa lub niezawodności, które nie są celami funkcjonalnymi. Wymagania niefunkcjonalne można w pewnym stopniu opisać w stylu przypadków użycia, używając przypadków nadużyć do zdefiniowania celów negatywnych; ale odkryte w ten sposób (pozytywne) cele są często funkcjonalne. Na przykład, jeśli kradzież stanowi zagrożenie dla bezpieczeństwa , montaż zamków jest środkiem zaradczym; ale możliwość zamknięcia drzwi jest wymogiem funkcjonalnym.

Kontrapunkt polega na tym, że przypadki użycia nie wywodzą się z kognitywistyki, podczas gdy i* i KAOS tak. Rzeczywiście, literatura stojąca za przypadkami użycia nie obejmuje dyskusji na temat intencji celu, udoskonalenia celu, środków końcowych, nie wspomina o Rasmussenie i tak dalej. Może istnieć skłonność do wiązania przypadków użycia z celami ze względu na wizualną metaforę celów, a nie semantykę udoskonalania celów według kognitywistyki.

Bibliografia

  • Alexander, Ian i Beus-Dukic, Ljerka. Odkrywanie wymagań: jak określać produkty i usługi . Wiley, 2009.
  • Alexander, Ian F. i Maiden, Neil. Scenariusze, historie, przypadki użycia . Wiley, 2004.
  • Cockburn, Alistair . Pisanie efektywnych przypadków użycia . Addison-Wesley, 2001.
  • Fowler, Marcin . UML destylowany . 3. edycja. Addison-Wesley, 2004.
  • van Lamsweerde, Axel . Inżynieria wymagań: od celów systemowych, przez modele UML, po specyfikacje oprogramowania . Wiley, 2009.
  • Yu, Eric, Paolo Giorgini, Neil Maiden i John Mylopoulos . (redaktorzy) Modelowanie społeczne dla Inżynierii Wymagań . MIT Press, 2011.

Zobacz też

Linki zewnętrzne

Pobrano z „ https://en.wikipedia.org/w/index.php?title=Goal_modeling&oldid=1042017042 ”