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.
El enfoque de los marcos de problemas fue esbozado por primera vez por Jackson en su libro Software Requirements & Specification (1995) y en una serie de artículos en varias revistas dedicadas a la ingeniería de software. Recibió su descripción más completa en su libro Problem Frames: Analysing and Structuring Software Development Problems (2001).
Una sesión sobre marcos de problemas fue 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 celebró como parte de ICSE'04 celebrado en Edimburgo, Escocia. Uno de los resultados de ese taller fue un número especial de 2005 sobre marcos de problemas en el International Journal of Information and Software Technology .
El Segundo Taller Internacional sobre Aplicaciones y Avances en Marcos de Problemas [3] se llevó a cabo como parte de ICSE 2006 en Shanghái, China. El Tercer Taller Internacional sobre Aplicaciones y Avances en Marcos de Problemas (IWAAPF) [4] se llevó a cabo como parte de ICSE 2008 en Leipzig, Alemania. En 2010, los talleres IWAAPF fueron reemplazados por el Taller Internacional sobre Aplicaciones y Avances en Orientación a Problemas (IWAAPO). IWAAPO amplía el enfoque de los talleres para incluir enfoques alternativos y complementarios para el desarrollo de software que comparten un énfasis en el análisis de problemas. [5] IWAAPO-2010 se llevó a cabo como parte de ICSE 2010 en Ciudad del Cabo, Sudáfrica. [6]
En la actualidad, se están realizando investigaciones sobre el enfoque de marcos de problemas en varias universidades, más notablemente en la Open University del Reino Unido como parte de su tema de investigación Relacionar estructuras de problemas y soluciones [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.
El análisis de problemas o el enfoque de marcos de problemas es un enfoque (un conjunto de conceptos) que se utiliza 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, ya que insiste en que:
Es más útil... reconocer que la solución está en la computadora y su software, y que el problema está en el mundo exterior. ... Las computadoras pueden proporcionar soluciones a estos problemas porque están conectadas con el mundo exterior. [10]
La moraleja es clara: para estudiar y analizar un problema, hay que centrarse en estudiar y analizar el mundo del problema con cierta profundidad, y en las investigaciones hay que estar dispuesto a viajar a cierta distancia del ordenador. ... [En un problema de desvío de llamadas...] hay que describir lo que hay allí –gente, oficinas, vacaciones, cambio de oficina y delegación de responsabilidades– y qué efectos [en el mundo del problema] se desea que el sistema consiga –las llamadas al número de A deben 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 de C deben llegar a C. [11]
Ninguno de ellos aparece en la interfaz con la computadora... Todos ellos están más profundamente en el mundo que eso. [12]
El enfoque utiliza tres conjuntos de herramientas conceptuales.
Los conceptos utilizados para describir problemas específicos incluyen: fenómenos (de varios tipos, incluidos eventos ), contexto del problema , dominio del problema , dominio de la solución (también conocido como la máquina ), fenómenos compartidos (que existen en las interfaces del dominio ), requisitos del dominio (que existen en los dominios del problema) y especificaciones (que existen en la interfaz dominio del problema:máquina).
Las herramientas gráficas para describir problemas son el diagrama de contexto y el diagrama 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 (de forma similar 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 manera determinista y predecible a los eventos) o dócil (se le puede pedir que responda a los eventos, pero no se puede esperar que siempre reaccione a los eventos de una manera predecible y determinista). (Un dominio dócil generalmente está formado por personas).
La herramienta gráfica para representar un marco de problemas es un diagrama de marcos . Un diagrama de marcos se parece en general a un diagrama de problemas, salvo por algunas diferencias menores: los dominios tienen nombres generales, en lugar de específicos, y los rectángulos que representan dominios están anotados para indicar el tipo de dominio (causal o negociable).
El primer grupo de marcos problemáticos identificados por Jackson incluía:
Posteriormente, otros investigadores han descrito o propuesto marcos de problemas adicionales.
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 su incorporación al contexto del problema, donde producirá determinados 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 una vez insertada la máquina de software en el contexto del problema, este último 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:
La primera tarea del analista de problemas es comprender verdaderamente el problema, lo que significa comprender el contexto en el que se sitúa el problema y, por lo tanto, dibujar un diagrama de contexto.
A continuación se presenta la descripción que hace Jackson del examen del contexto del problema, en este caso el contexto de la construcción de un puente:
Un analista que intenta comprender un problema de desarrollo de software debe pasar por el mismo proceso que el ingeniero de puentes. Comienza examinando los distintos dominios del problema 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 distintos dominios de problemas en el dominio de la aplicación, sus conexiones y la máquina y sus conexiones con (algunos de) los dominios de problemas. Así es como se ve un diagrama de contexto.
Este diagrama muestra:
Un dominio es simplemente una parte del mundo que nos interesa. Está formado por fenómenos : individuos, eventos, situaciones, relaciones y comportamientos.
Una interfaz de dominio es un área donde los dominios se conectan y se 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.
Podemos imaginar que los dominios son como organismos unicelulares primitivos (como las amebas). Son capaces de extender partes de sí mismos en seudópodos. Imaginemos que dos de estos organismos extienden seudópodos uno hacia el otro en una especie de apretón de manos, y que el material celular en el área donde se dan la mano se mezcla, de modo que pertenece a ambos. Eso es una interfaz.
En el siguiente diagrama, X es la interfaz entre los dominios A y B. Los individuos que existen o los 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 para 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 cuando el byte hex("20") aparezca en el búfer de entrada.
La herramienta básica del analista de problemas para describir un problema es un diagrama de problemas . A continuación se muestra 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:
Una interfaz que conecta un dominio de problema con 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 problema real, aunque sencillo.
Este problema podría 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 enfermeras.
El nombre del requisito es "Mostrar ~ Estado 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 del requisito conectada al dominio de visualización del panel también es una restricción de requisito. Esto significa que el requisito contiene algún tipo de estipulación que la pantalla del panel debe cumplir. En resumen, el requisito es que la pantalla del panel debe mostrar información que coincida e informe con precisión sobre la condición de los pacientes.
Un marco de problemas es una descripción de una clase reconocible de problemas, donde la clase de problemas tiene una solución conocida. En cierto sentido, los marcos de problemas son patrones de problemas.
Cada marco de problemas tiene su propio diagrama de marcos . Un diagrama de marcos se parece básicamente 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, en lugar de específicos; y los rectángulos que representan dominios están anotados para indicar el tipo (causal o negociable) del dominio.
En Problem Frames, Jackson analizó variantes de los cinco marcos de problemas básicos que había identificado. Una variante suele añadir un dominio al contexto del problema.
Jackson también analiza ciertos tipos de preocupaciones que surgen cuando se trabaja con marcos problemáticos.
Preocupaciones particulares
Preocupaciones sobre la composición
Los primeros problemas identificados por Jackson incluyeron:
Posteriormente, otros investigadores han descrito o propuesto marcos de problemas adicionales.
La idea intuitiva detrás de este marco de problemas es:
La idea intuitiva detrás de este marco de problemas es:
La idea intuitiva detrás de este marco de problemas es:
La idea intuitiva detrás de este marco de problemas es:
La idea intuitiva detrás de este marco de problemas es:
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:
En este punto, el análisis del problema ( descomposición del problema ) está completo. El siguiente paso es invertir el proceso y construir el sistema de software deseado mediante 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. Si extrapolamos las sugerencias de Requisitos y especificaciones del software , podemos suponer que el proceso de desarrollo del software continuaría con los desarrolladores, quienes:
Hay algunas otras ideas de desarrollo de software que son similares en algunos aspectos al análisis de problemas.