El análisis de problemas o el enfoque de marcos de problemas es un enfoque para el análisis de requisitos de software . Fue desarrollado por el consultor de software británico Michael A. Jackson en la década de 1990.
Historia
El enfoque de marcos de problemas fue esbozado por primera vez por Jackson en su libro Requisitos y especificaciones de software (1995) y en varios artículos de varias revistas dedicadas a la ingeniería de software. Ha recibido su descripción más completa en su Problem Frames: Analyzing and Structuring Software Development Problems (2001).
Una sesión sobre marcos de problemas formó parte del 9º Taller internacional sobre ingeniería de requisitos: Fundación para la calidad del software (REFSQ)] celebrado en Klagenfurt / Velden, Austria en 2003. [1] El primer taller internacional sobre aplicaciones y avances en marcos de problemas [2 ] se llevó a cabo como parte de la ICSE'04 celebrada en Edimburgo, Escocia. Uno de los resultados de ese taller fue un número especial de 2005 sobre marcos de problemas en la Revista Internacional de Tecnología de la Información y el Software .
El segundo taller internacional sobre aplicaciones y avances en marcos de problemas [3] se celebró como parte de ICSE 2006 en Shanghai, China. El tercer taller internacional sobre aplicaciones y avances en marcos de problemas (IWAAPF) [4] se celebró como parte de ICSE 2008 en Leipzig, Alemania. En 2010, los talleres de IWAAPF fueron reemplazados por el Taller internacional sobre aplicaciones y avances de la orientación a problemas (IWAAPO). IWAAPO amplía el enfoque de los talleres para incluir enfoques alternativos y complementarios al desarrollo de software que comparten un énfasis en el análisis de problemas. [5] IWAAPO-2010 se celebró como parte de ICSE 2010 en Ciudad del Cabo, Sudáfrica. [6]
En la actualidad, la investigación sobre el enfoque de marcos de problemas se está llevando a cabo en varias universidades, sobre todo en la Open University del Reino Unido como parte de su tema de investigación Relating Problem & Solution Structures [7] [8]
Las ideas del enfoque de marcos de problemas se han generalizado en los conceptos de desarrollo orientado a problemas (POD) e ingeniería orientada a problemas (POE), de los cuales la ingeniería de software orientada a problemas (POSE) es una subcategoría particular. El primer taller internacional sobre desarrollo orientado a problemas se celebró en junio de 2009.
Descripción general
Filosofía fundamental
El análisis de problemas o el enfoque de marcos de problemas es un enfoque, un conjunto de conceptos, que se utilizará al recopilar requisitos y crear especificaciones para software de computadora. Su filosofía básica es sorprendentemente diferente de otros métodos de requisitos de software al insistir en que:
- La mejor manera de abordar el análisis de requisitos es mediante un proceso de descomposición paralela, no jerárquica, de los requisitos del usuario. [9]
- Los requisitos del usuario se refieren a las relaciones en el mundo real, el dominio de la aplicación , no al sistema de software o incluso a la interfaz con el sistema de software.
Es más útil ... reconocer que la solución se encuentra en la computadora y su software, y que el problema está en el mundo exterior. ... Las computadoras pueden brindar soluciones a estos problemas porque están conectadas con el mundo exterior. [10]
La moraleja es clara: para estudiar y analizar un problema debes concentrarte en estudiar y analizar el mundo problemático con cierta profundidad, y en tus investigaciones debes estar dispuesto a alejarte un poco de la computadora. ... [En un problema de desvío de llamadas ...] Debe describir lo que hay (personas, oficinas, vacaciones, mudanza de oficina y delegación de responsabilidades) y qué efectos [en el mundo problemático] le gustaría que lograra el sistema: llamadas al número de A debe llegar a A, y [cuando B está de vacaciones y C está trabajando temporalmente en el escritorio de D] las llamadas al número de B o C deben llegar a C. [11]
Ninguno de estos aparece en la interfaz con la computadora ... Todos están más adentrados en el mundo que eso. [12]
El enfoque utiliza tres conjuntos de herramientas conceptuales.
Herramientas para describir problemas específicos
Conceptos utilizados para describir problemas específicos incluyen: fenómenos (de diversos tipos, incluyendo eventos ), contexto del problema , dominio del problema , dominio solución (también conocido como la máquina ), fenómenos compartidos (que existen en los interfaces de dominio ), requisitos de dominio (que existen en el problema dominios) y especificaciones (que existen en el dominio del problema: interfaz de máquina).
Las herramientas gráficas para describir problemas son el diagrama de contexto y el diagrama de problemas .
Herramientas para describir clases de problemas (marcos de problemas)
El enfoque de marcos de problemas incluye conceptos para describir clases de problemas. Una clase reconocida de problemas se denomina marco de problemas (más o menos análogo a un patrón de diseño ).
En un marco de problemas, los dominios reciben nombres generales y se describen en términos de sus características importantes. Un dominio, por ejemplo, puede clasificarse como causal (reacciona de una manera determinista y predecible a los eventos) o licitable (se puede licitar o pedir que responda a los eventos, pero no se puede esperar que siempre reaccione a los eventos de manera predecible, forma determinista). (Un dominio por el que se puede pujar suele estar formado por personas).
La herramienta gráfica para representar un marco de problema es un diagrama de marco . Un diagrama de marco se parece generalmente a un diagrama de problemas, excepto por algunas diferencias menores: los dominios tienen nombres generales, en lugar de específicos; y los rectángulos que representan dominios se anotan para indicar el tipo (causal o licitable) del dominio.
Una lista de clases de problemas reconocidas (marcos de problemas)
El primer grupo de marcos problemáticos identificados por Jackson incluyó:
- comportamiento requerido
- comportamiento ordenado
- pantalla de información
- piezas de trabajo simples
- transformación
Posteriormente, otros investigadores han descrito o propuesto marcos de problemas adicionales.
Describiendo problemas
El contexto del problema
El análisis de problemas considera que una aplicación de software es una especie de máquina de software . Un proyecto de desarrollo de software tiene como objetivo cambiar el contexto del problema mediante la creación de una máquina de software y agregarla al contexto del problema, donde producirá ciertos efectos deseados.
La parte particular del contexto del problema que es de interés en relación con un problema particular, la parte particular del contexto del problema que forma el contexto del problema, se denomina dominio de aplicación .
Una vez finalizado el proyecto de desarrollo de software, y la máquina de software se ha insertado en el contexto del problema, el contexto del problema contendrá tanto el dominio de la aplicación como la máquina. En ese momento, la situación se verá así:
El contexto del problema contiene la máquina y el dominio de la aplicación. La interfaz de la máquina es donde la máquina y el dominio de la aplicación se encuentran e interactúan.
La misma situación se puede mostrar en un tipo diferente de diagrama, un diagrama de contexto , de esta manera:
El diagrama de contexto
La primera tarea del analista de problemas es comprender verdaderamente el problema. Eso significa comprender el contexto en el que se plantea el problema. Y eso significa dibujar un diagrama de contexto.
Aquí está la descripción de Jackson de examinar el contexto del problema, en este caso el contexto para construir un puente:
- Eres un ingeniero que planea construir un puente sobre un río. Entonces visitas el sitio. Parado en una orilla del río, miras la tierra circundante y el tráfico fluvial. Sientes lo expuesto que está el lugar, lo fuerte que sopla el viento y lo rápido que corre el río. Miras el banco y te preguntas qué fallas mostrará un estudio geológico en el terreno rocoso. Te imaginas el puente que vas a construir. ( Requisitos y especificaciones de software : "El contexto del problema")
Un analista que intente comprender un problema de desarrollo de software debe pasar por el mismo proceso que el ingeniero de puentes. Comienza examinando los diversos dominios de problemas en el dominio de la aplicación. Estos dominios forman el contexto en el que debe encajar la Máquina planificada. Luego imagina cómo encajará la Máquina en este contexto. Y luego construye un diagrama de contexto que muestra su visión del contexto del problema con la Máquina instalada en él.
El diagrama de contexto muestra los diversos dominios problemáticos en el dominio de la aplicación, sus conexiones y la Máquina y sus conexiones a (algunos de) los dominios problemáticos. Así es como se ve un diagrama de contexto.
Este diagrama muestra:
- la máquina que se va a construir. El borde oscuro ayuda a identificar el cuadro que representa la Máquina.
- los dominios del problema que son relevantes para el problema.
- las líneas continuas representan interfaces de dominio , áreas donde los dominios se superponen y comparten fenómenos en común.
Un dominio es simplemente una parte del mundo que nos interesa. Consiste en fenómenos : individuos, eventos, estados de cosas, relaciones y comportamientos.
Una interfaz de dominio es un área donde los dominios se conectan y comunican. Las interfaces de dominio no son flujos de datos ni mensajes. Una interfaz es un lugar donde los dominios se superponen parcialmente, de modo que los fenómenos en la interfaz son fenómenos compartidos : existen en ambos dominios superpuestos.
Puede imaginarse dominios como organismos unicelulares primitivos (como amebas). Son capaces de extender partes de sí mismos en pseudópodos. Imagínese que dos de estos organismos extienden pseudópodos entre sí en una especie de apretón de manos, y que el material celular en el área donde se dan la mano se está mezclando, de modo que les pertenece a ambos. Esa es una interfaz.
En el siguiente diagrama, X es la interfaz entre los dominios A y B. Individuos que existen o eventos que ocurren en X, existen u ocurren tanto en A como en B.
Los individuos, estados y eventos compartidos pueden verse de manera diferente a los dominios que los comparten. Considere, por ejemplo, una interfaz entre una computadora y un teclado. Cuando el dominio del teclado ve un evento, el operador del teclado presiona la barra espaciadora, la computadora verá el mismo evento que Byte hexadecimal ("20") aparece en el búfer de entrada.
Diagramas de problemas
La herramienta básica del analista de problemas para describir un problema es un diagrama de problemas . Aquí hay un diagrama de problemas genérico.
Además de los tipos de cosas que se muestran en un diagrama de contexto, un diagrama de problemas muestra:
- un óvalo punteado que representa el requisito de producir ciertos efectos en los dominios del problema.
- líneas punteadas que representan referencias de requisitos : referencias en el requisito a fenómenos en los dominios del problema.
Una interfaz que conecta un dominio de problema a la máquina se denomina interfaz de especificación y los fenómenos en la interfaz de especificación se denominan fenómenos de especificación . El objetivo del analista de requisitos es desarrollar una especificación para el comportamiento que la Máquina debe exhibir en la interfaz de la Máquina para satisfacer el requisito.
A continuación se muestra un ejemplo de un diagrama de problemas real, aunque simple.
Este problema puede ser parte de un sistema informático en un hospital. En el hospital, los pacientes están conectados a sensores que pueden detectar y medir su temperatura y presión arterial. El requisito es construir una máquina que pueda mostrar información sobre las condiciones del paciente en un panel en la estación de enfermería.
El nombre del requisito es "Pantalla ~ Condición del paciente". La tilde (~) indica que el requisito se refiere a una relación o correspondencia entre la pantalla del panel y las condiciones del paciente. La punta de flecha indica que la referencia de requisitos conectada al dominio de visualización del panel también es una restricción de requisitos. Eso significa que el requisito contiene algún tipo de estipulación que debe cumplir la pantalla del Panel. En resumen, el requisito es que la pantalla del panel debe mostrar información que coincida e informe con precisión la condición de los pacientes.
Describir clases de problemas
Marcos de problemas
Un marco de problemas es una descripción de una clase de problemas reconocible, donde la clase de problemas tiene una solución conocida. En cierto sentido, los marcos de problemas son patrones de problemas.
Cada cuadro de problemas tiene su propio diagrama de cuadros . Un diagrama de marco se parece esencialmente a un diagrama de problemas, pero en lugar de mostrar dominios y requisitos específicos, muestra tipos de dominios y tipos de requisitos; los dominios tienen nombres generales, más que específicos; y los rectángulos que representan dominios se anotan para indicar el tipo (causal o licitable) del dominio.
Marcos variantes
En Problem Frames, Jackson analizó las variantes de los cinco marcos de problemas básicos que había identificado. Una variante generalmente agrega un dominio al contexto del problema.
- una variante de descripción introduce un dominio léxico de descripción
- una variante de operador presenta un operador
- una variante de conexión introduce un dominio de conexión entre la máquina y el dominio central con el que interactúa
- una variante de control no introduce ningún dominio nuevo; cambia las características de control de los fenómenos de interfaz
Preocupaciones por problemas
Jackson también analiza ciertos tipos de preocupaciones que surgen cuando se trabaja con marcos problemáticos.
Preocupaciones particulares
- invadir
- inicialización
- fiabilidad
- identidades
- lo completo
Preocupaciones por la composición
- descripciones conmensurables
- consistencia
- precedencia
- interferencia
- sincronización
Marcos de problemas reconocidos
Los primeros marcos problemáticos identificados por Jackson incluyeron:
- comportamiento requerido
- comportamiento ordenado
- pantalla de información
- piezas de trabajo simples
- transformación
Posteriormente, otros investigadores han descrito o propuesto marcos de problemas adicionales.
Marco de problemas de comportamiento requerido
La idea intuitiva detrás de este marco de problemas es:
- Hay una parte del mundo físico cuyo comportamiento debe controlarse para que satisfaga ciertas condiciones. El problema es construir una máquina que imponga ese control.
Marco de problemas de conducta ordenada
La idea intuitiva detrás de este marco de problemas es:
- Existe una parte del mundo físico cuyo comportamiento debe controlarse de acuerdo con los comandos emitidos por un operador. El problema es construir una máquina que acepte los comandos del operador e imponga el control en consecuencia.
Cuadro de problemas de visualización de información
La idea intuitiva detrás de este marco de problemas es:
- Hay una parte del mundo físico sobre cuyos estados y comportamiento se necesita continuamente cierta información. El problema es construir una máquina que obtenga esta información del mundo y la presente en el lugar requerido en la forma requerida.
Marco de problemas de piezas de trabajo simples
La idea intuitiva detrás de este marco de problemas es:
- Se necesita una herramienta que permita a un usuario crear y editar una determinada clase de texto u objetos gráficos procesables por computadora, o estructuras similares, de modo que puedan ser posteriormente copiados, impresos, analizados o utilizados de otras formas. El problema es construir una máquina que pueda actuar como esta herramienta.
Marco del problema de transformación
La idea intuitiva detrás de este marco de problemas es:
- Hay algunos archivos de entrada legibles por computadora cuyos datos deben transformarse para dar ciertos archivos de salida requeridos. Los datos de salida deben estar en un formato particular y deben derivarse de los datos de entrada de acuerdo con ciertas reglas. El problema es construir una máquina que produzca las salidas requeridas a partir de las entradas.
Análisis de problemas y proceso de desarrollo de software
Cuando el análisis de problemas se incorpora al proceso de desarrollo de software , el ciclo de vida del desarrollo de software comienza con el analista de problemas, quien estudia la situación y:
- crea un diagrama de contexto
- reúne una lista de requisitos y agrega un óvalo de requisitos al diagrama de contexto, creando un gran diagrama de problemas "todo en uno". (Sin embargo, en muchos casos crear un diagrama de problemas todo en uno puede ser poco práctico o inútil: habrá demasiadas referencias de requisitos entrecruzando el diagrama para que sea muy útil).
- descompone el problema todo en uno y el diagrama de problemas en problemas más simples y diagramas de problemas más simples. Estos problemas son proyecciones , no subconjuntos, del diagrama todo en uno.
- continúa descomponiendo problemas hasta que cada problema es lo suficientemente simple como para que pueda verse como una instancia de un marco de problema reconocido. Cada descripción de subproblema incluye una descripción de las interfaces de especificación para la máquina que se va a construir.
En este punto, el análisis del problema (descomposición del problema ) está completo. El siguiente paso es revertir el proceso y construir el sistema de software deseado a través de un proceso de composición de la solución .
El proceso de composición de la solución aún no se comprende bien y sigue siendo un tema de investigación. Extrapolando de las sugerencias en Requisitos y especificaciones de software , podemos suponer que el proceso de desarrollo de software continuaría con los desarrolladores, quienes:
- componga las especificaciones de la máquina con múltiples subproblemas en la especificación para una sola máquina todo en uno: una especificación para una máquina de software que satisface todos los requisitos del cliente. Esta es una actividad no trivial: el proceso de composición puede muy bien plantear problemas de composición que deben resolverse.
- Implemente la máquina todo en uno pasando por el proceso tradicional de código / prueba / implementación.
Enfoques similares
Hay algunas otras ideas de desarrollo de software que son similares en algunos aspectos al análisis de problemas.
- La noción de patrón de diseño es similar a la noción de marco problema de Jackson. Se diferencia en que un patrón de diseño se usa para reconocer y manejar problemas de diseño (a menudo problemas de diseño en lenguajes de programación orientados a objetos específicos como C ++ o Java) en lugar de reconocer y manejar problemas de requisitos. Además, una diferencia es que los patrones de diseño cubren las soluciones, mientras que en los marcos de problemas se representan los problemas . Sin embargo, los patrones de diseño también tienden a tener en cuenta los resultados semánticos que no son nativos del lenguaje de programación en el que se implementarán. Por lo tanto, otra diferencia es que los marcos de problemas son una metanotación nativa para el dominio de problemas, mientras que los patrones de diseño son un catálogo de la deuda técnica que dejaron los implementadores del lenguaje.
- La programación orientada a aspectos , AOP (también conocida como desarrollo de software orientado a aspectos , AOSD) está igualmente interesada en la descomposición paralela, que aborda lo que los proponentes de AOP llaman preocupaciones o aspectos transversales . AOP aborda preocupaciones que están mucho más cerca de la fase de diseño y generación de código que de la fase de análisis de requisitos.
- AOP se ha trasladado a notaciones de ingeniería de requisitos, como UIT-T Z.151 Notación de requisitos de usuario (URN). En URN el AOP está sobre todos los elementos intencionales. AOP también se puede aplicar sobre el modelado de requisitos que utiliza marcos de problemas como heurística. Los modelos URN impulsados con el pensamiento de marcos de problemas e intercalados con aspectos permiten la inclusión de tácticas arquitectónicas en el modelo de requisitos.
- El libro Analysis Patterns de Martin Fowler es muy similar al análisis de problemas en su búsqueda de patrones. Sin embargo, en realidad no presenta un nuevo método de análisis de requisitos. Y la noción de descomposición paralela, que es tan importante para el análisis de problemas, no forma parte de los patrones de análisis de Fowler.
- Jon G. Hall, Lucia Rapanotti, junto con Jackson, han desarrollado el marco de Ingeniería de Software Orientado a Problemas (POSE) [13] que comparte los fundamentos de los marcos de problemas. Desde 2005, Hall y Rapanotti han extendido POSE a la Ingeniería Orientada a Problemas (POE), que proporciona un marco para el diseño de ingeniería, que incluye un modelo de proceso de desarrollo y un diseño basado en aseguramiento, [14] y puede ser escalable a proyectos que incluyen muchos intereses. titulares y que combinan diversas disciplinas de ingeniería como software y provisión de educación. [15]
Referencias
- ^ Noveno Taller Internacional sobre Ingeniería de Requisitos: Fundación para la Calidad del Software (REFSQ) celebrado en Klagenfurt / Velden, Austria en 2003.
- ^ Primer taller internacional sobre aplicaciones y avances en marcos de problemas
- ^ Segundo taller internacional sobre aplicaciones y avances en marcos problemáticos Archivado el 19 de agosto de 2007 en la Wayback Machine.
- ^ "Tercer taller internacional sobre aplicaciones y avances en marcos de problemas" . Archivado desde el original el 24 de diciembre de 2010 . Consultado el 19 de junio de 2010 .
- ^ Taller internacional sobre aplicaciones y avances de la orientación a problemas. Archivado el 11 de enero de 2011 en la Wayback Machine.
- ^ "IWAAPO-2010" . Archivado desde el original el 28 de enero de 2010 . Consultado el 19 de junio de 2010 .
- ^ Relacionando el tema de investigación de estructuras de problemas y soluciones .
- ^ Por ejemplo: "Relacionar los requisitos de software y las arquitecturas utilizando marcos de problemas" por Hall, JG; Jackson, M .; Laney, RC; Nuseibeh, B .; Rapanotti, L., en Proceedings of the IEEE Joint International Conference on Requirements Engineering (2002), págs. 137-144
- ^ Jackson, Michael (1995). "Problema de descomposición para su reutilización". págs. 1, 2.
- ^ Jackson, Michael (2001). Marcos de problemas . Addison-Wesley. págs. 3, 4.
- ^ Jackson, Michael (2001). Marcos de problemas . Addison-Wesley. pag. 9.
- ^ Jackson, Michael (2001). Marcos de problemas . Addison-Wesley. págs. 9, 10.
- ^ JG Hall, L. Rapanotti y M. Jackson. Ingeniería de software orientada a problemas: solución del problema de control del encaminador de paquetes. IEEE Trans. Software Eng., 2008. doi : 10.1109 / TSE.2007.70769 .
- ^ JG Hall y L. Rapanotti. Diseño impulsado por la garantía. En Actas de la tercera Conferencia Internacional sobre Avances en Ingeniería de Software. 2008.
- ^ L. Rapanotti y JG Hall. Diseño de un maestro de filosofía en línea a tiempo parcial. En Actas de la Cuarta Conferencia Internacional sobre Internet y Aplicaciones y Servicios Web. IEEE Press, 24 al 28 de mayo de 2009.
enlaces externos
- http://mcs.open.ac.uk/mj665/ es la página de inicio de Michael A. Jackson
- http://www.jacksonworkbench.co.uk/stevefergspages/pfa/index.html tiene artículos y artículos sobre el enfoque de los marcos de problemas