Articulo de referencia

Modelado de objetivos

Un modelo de objetivos es un elemento de la ingeniería de requisitos que también puede utilizarse de forma más amplia en el análisis de negocio . Los elementos relacionados incl...

Un modelo de objetivos es un elemento de la ingeniería de requisitos que también puede utilizarse de forma más amplia en el análisis de negocio . Los elementos relacionados incluyen el análisis de partes interesadas , el análisis de contexto y los escenarios , [ 1 ] entre otras áreas técnicas y de negocio.

Principios

Los objetivos son metas que un sistema debe alcanzar mediante la cooperación de los actores en el software previsto y en el entorno. [ 2 ] El modelado de objetivos es especialmente útil en las fases iniciales de un proyecto. Los proyectos pueden considerar cómo el sistema previsto cumple con los objetivos organizacionales (véase también [ 3 ] ), por qué se necesita el sistema y cómo se pueden abordar los intereses de las partes interesadas. [ 4 ]

Un modelo de objetivos:

  • Expresa las relaciones entre un sistema y su entorno (es decir, no solo lo que se supone que debe hacer el sistema, sino también por qué). La comprensión que esto proporciona sobre las razones por las que se necesita un sistema, en su contexto, es útil porque "los sistemas se utilizan cada vez más para cambiar fundamentalmente los procesos de negocio en lugar de automatizar prácticas establecidas desde hace mucho tiempo". [ 5 ] [ 6 ]
  • Aclara los requisitos  : Especificar los objetivos lleva a preguntar "por qué", "cómo" y "de qué otra manera". [ 5 ] Los requisitos de las partes interesadas a menudo se revelan en este proceso, con menor riesgo de omitir requisitos o de especificar en exceso (pedir cosas que no se necesitan).
  • Permite analizar los grandes objetivos y convertirlos en objetivos pequeños y alcanzables:
  • Aborda los conflictos  : el modelado de objetivos puede identificar y ayudar a resolver las compensaciones entre costo, rendimiento, flexibilidad, seguridad y otros objetivos. Puede revelar intereses divergentes entre las partes interesadas. Puede identificar conflictos porque el cumplimiento de un objetivo puede interferir con el cumplimiento de otros. [ 5 ]
  • Permite medir la exhaustividad de los requisitos: estos se consideran completos si cumplen todos los objetivos del modelo de objetivos.
  • Conecta los requisitos con el diseño: por ejemplo, el marco de trabajo "Requisitos no funcionales (RNF)" de i* utiliza objetivos para guiar el proceso de diseño.

Notaciones

Existen varias notaciones que se utilizan para los modelos de objetivos en el desarrollo de software , entre las que se incluyen:

Otros investigadores han propuesto notaciones, [ 10 ] mientras que la Notación de Estructuración de Objetivos (GSN) y GRL se utilizan a veces para elaborar casos de seguridad que satisfagan al regulador en industrias relacionadas con la seguridad. [ 11 ] [ 12 ]

Modelado de objetivos en i*

La notación de modelado de objetivos i* proporciona dos tipos de diagramas: [ 13 ]

  • "Dependencia Estratégica" (DE), que define las relaciones entre roles en términos de objetivos específicos que un rol depende del otro para lograr.
  • "Fundamento Estratégico" (FE), que analiza los objetivos identificados en el modelo SD en objetivos y tareas subsidiarias.

i* representa cada rol (actor, agente o posición) como un círculo grande que contiene los objetivos, tareas y recursos que le corresponden. En i*, la propiedad implica que el rol desea la satisfacción de sus objetivos, ya sea para su propio beneficio o para el de otro rol. Los objetivos pueden ir acompañados de "obstáculos" (objetivos negativos) que deben superarse. Los objetivos no funcionales pueden representarse como "objetivos blandos" en i*: se diagraman como nubes u óvalos con sangría.

Modelado de objetivos en KAOS

La notación de modelado de objetivos KAOS proporciona una forma de definir objetivos y obstáculos, sustentada en un método formal (matemático) de análisis. [ 8 ]

Modelado de objetivos en UML

El diagrama de casos de uso de UML proporciona una notación simple para modelar objetivos. Las burbujas nombran objetivos funcionales, [ 14 ] por lo que un diagrama de casos de uso forma un modelo de objetivos simple basado únicamente en funciones: como escribe Cockburn, los casos de uso cubren solo los requisitos de comportamiento. [ 15 ] Los roles se muestran como actores (figuras esquemáticas en el diagrama), vinculados a los casos de uso en los que participan. Los casos de uso se dibujan como burbujas elípticas, que representan los objetivos de comportamiento deseados. [ 16 ]

Con la adición de casos de mal uso , la notación puede modelar tanto los objetivos deseados como las amenazas activas. La notación de casos de mal uso muestra a las partes interesadas negativas (posiblemente hostiles) como los actores principales de los casos de mal uso; estos pueden agruparse en el lado derecho del diagrama. La notación puede ayudar a descubrir objetivos de mitigación o prevención adecuados, mostrados como casos de uso subsidiarios. Estos a menudo tienen como objetivo mejorar la seguridad, la protección o la confiabilidad, que son objetivos no funcionales. Los requisitos no funcionales pueden, hasta cierto punto, describirse al estilo de los casos de uso utilizando casos de mal uso para definir objetivos negativos; pero los objetivos (positivos) así descubiertos suelen ser funcionales. Por ejemplo, si el robo es una amenaza para la seguridad , entonces la instalación de cerraduras es una mitigación; pero que una puerta pueda cerrarse con llave es un requisito funcional. [ 17 ]

El argumento contrario es que los casos de uso no tienen raíces en la ciencia cognitiva , a diferencia de i* y KAOS. De hecho, la literatura sobre casos de uso no incluye discusiones sobre la intención del objetivo, el refinamiento del objetivo ni los medios y fines, ni menciona a Rasmussen, etcétera. Puede existir una predilección por relacionar los casos de uso con los objetivos debido a la metáfora visual de los objetivos, más que a la semántica del refinamiento del objetivo según la ciencia cognitiva.

Bibliografía

  • Alexander, Ian y Beus-Dukic, Ljerka. Descubriendo los requisitos: cómo especificar productos y servicios . Wiley, 2009.
  • Alexander, Ian F. y Maiden, Neil. Escenarios, historias, casos de uso . Wiley, 2004.
  • Cockburn, Alistair . Cómo escribir casos de uso eficaces . Addison-Wesley, 2001.
  • Fowler, Martin . UML Distilled . 3.ª edición. Addison-Wesley, 2004.
  • van Lamsweerde, Axel . Ingeniería de requisitos: de los objetivos del sistema a los modelos UML y a las especificaciones de software . Wiley, 2009.
  • Yu, Eric, Paolo Giorgini, Neil Maiden y John Mylopoulos (editores). Modelado social para la ingeniería de requisitos . MIT Press, 2011.

Véase también

Referencias

  1. ^ Alexander y Beus-Dukic, 2009. Páginas 17-18
  2. Lin Liu y Eric Yu (2003). «Diseño de sistemas de información en contexto social: un enfoque de modelado de objetivos y escenarios» (PDF) . Universidad de Toronto. Archivado del original (PDF) el 5 de febrero de 2005.
  3. Ellis-Braithwaite, R.; Lock, R.; Dawson, R.; Haque B. (2013). "Hacia un enfoque para analizar la alineación estratégica de los requisitos de software utilizando gráficos de objetivos cuantificados". International Journal on Advances in Software . 6 : 119–130 . arXiv : 1307.2580 . Bibcode : 2013arXiv1307.2580E .
  4. E. Yu, "Hacia el modelado y el soporte de razonamiento para la ingeniería de requisitos en fase temprana", 1997 IEEE
  5. 1 2 3 Eric Yu y John Mylopoulos. "Por qué la ingeniería de requisitos orientada a objetivos" . Universidad de Toronto.
  6. K. Pohl y P. Haumer, "Modelado de información contextual sobre escenarios", Actas del 3er Taller Internacional sobre Ingeniería de Requisitos: Fundamentos de la Calidad del Software REFSQ '97, Barcelona, ​​Cataluña, España, junio de 1997, págs. 187-204.
  7. Yu et al, 2011.
  8. 1 2 van Lamsweerde , 2009.
  9. Fowler, 2004. Páginas 99-105
  10. Rolland, Colette ; Prakash, Naveen; Benjamen, Adolphe (1999). "Una visión multimodelo del modelado de procesos" (PDF) . Ingeniería de requisitos . 4 (4): 169– 187. doi : 10.1007/s007660050018 . S2CID 6988662 . 
  11. Estándar de la comunidad GSN
  12. Feodoroff, R. (2016). «Arquitectura empresarial intencional». Conferencia anual de sistemas IEEE de 2016 (SysCon) . págs. 1–8 . doi : 10.1109/SYSCON.2016.7490555 . ISBN  978-1-4673-9519-9. S2CID 206586399 . 
  13. Yu, Eric (6 de septiembre de 2011). "i*" . i*: un marco de modelado orientado a agentes y objetivos . Universidad de Toronto . Recuperado el 17 de diciembre de 2011 .
  14. ^ Alexander y Beus-Dukic, 2009. Página 121
  15. Cockburn, 2001. Página 62
  16. Cockburn, 2001. Página 221
  17. Alexander y Maiden, 2004. Capítulo 7. Páginas 119-139.
  • i* Sitio web oficial, con tutorial y bibliografía : "un marco de modelado orientado a agentes y objetivos".
  • wiki i* con directrices y ejemplos
  • Tutorial de KAOS
  • Uso de EEML para el modelado combinado orientado a objetivos y procesos: un estudio de caso - John Krogstie