Enfoque de marcos de problemas

El análisis de problemas o el enfoque de marcos de problemas es un método —un conjunto de conceptos— que se utiliza para recopilar requisitos y crear especificaciones para software informático. Su filosofía básica es notablemente diferente de otros métodos de requisitos de software, ya que insiste 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 ni siquiera a la interfaz con el sistema de software.

Es más útil... reconocer que la solución reside 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 al mundo exterior. ^{[ 10 ]}

La moraleja es clara: para estudiar y analizar un problema, debes centrarte en estudiar y analizar el mundo del problema en profundidad, y en tus investigaciones debes estar dispuesto a alejarte un poco del ordenador. ... [En un problema de desvío de llamadas...] Debes describir lo que hay: personas, oficinas, vacaciones, cambios de oficina y delegación de responsabilidades, y qué efectos [en el mundo del problema] quieres que logre el sistema: las llamadas al número de A deben llegar a A, y [cuando B está de vacaciones y C trabaja 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 profundamente en el mundo que eso. ^{[ 12 ]}

Este 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 de dominio ), requisitos de 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 problema (aproximadamente análogo a un patrón de diseño ).

En un marco de problemas, los dominios reciben nombres generales y se describen en función de sus características principales. Un dominio, por ejemplo, puede clasificarse como causal (reacciona de forma determinista y predecible ante los eventos) o susceptible de ser manipulado (se le puede pedir que responda a los eventos, pero no se puede esperar que siempre reaccione de forma predecible y determinista). (Un dominio susceptible de ser manipulado 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 problema, salvo por algunas pequeñas diferencias: los dominios tienen nombres generales, en lugar de específicos; y los rectángulos que representan los dominios están anotados para indicar el tipo (causal o susceptible de ser manipulado) del dominio.

El primer grupo de marcos problemáticos identificados por Jackson incluía:

1. comportamiento requerido
2. comportamiento ordenado
3. visualización de información
4. piezas de trabajo sencillas
5. transformación

Posteriormente, otros investigadores han descrito o propuesto marcos de problemas adicionales.

El análisis de problemas considera una aplicación de software como 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 a dicho contexto, donde producirá ciertos efectos deseados.

La parte específica del contexto del problema que resulta de interés en relación con un problema concreto —la parte específica del contexto del problema que conforma el contexto del problema— se denomina dominio de aplicación .

Una vez finalizado el proyecto de desarrollo de software y tras la inserción de la máquina de software en el contexto del problema, dicho contexto 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 comprende la máquina y el dominio de la aplicación. La interfaz de la máquina es el punto de encuentro e interacción entre la máquina y el dominio de la aplicación.

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. Esto implica comprender el contexto en el que se plantea el problema. Y eso significa elaborar un diagrama de contexto.

Aquí está la descripción de Jackson sobre el análisis del contexto del problema, en este caso el contexto de un puente que se va a construir:

Eres un ingeniero que planea construir un puente sobre un río. Así que visitas el lugar. De pie en una orilla, observas el terreno circundante y el tráfico fluvial. Sientes lo expuesto que está el lugar, la fuerza del viento y la velocidad de la corriente. Miras la orilla y te preguntas qué fallas revelará un estudio geológico en el terreno rocoso. Visualizas el puente que vas a construir. ( Requisitos y especificaciones del software : "El contexto del problema")

Un analista que intenta comprender un problema de desarrollo de software debe seguir el mismo proceso que un ingeniero de puentes. Comienza examinando los distintos dominios del problema dentro del dominio de la aplicación. Estos dominios conforman el contexto en el que debe encajar la máquina planificada. Luego, imagina cómo encajará la máquina en este contexto. Finalmente, 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 problemáticos en el dominio de la aplicación, sus conexiones y la máquina y sus conexiones con (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 la caja que representa la máquina.
• los dominios problemáticos que son relevantes para el problema.
• Las líneas continuas representan las interfaces de dominio : áreas donde los dominios se superponen y comparten fenómenos comunes.

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 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 los dominios como organismos unicelulares primitivos (como las amebas). Estos organismos son capaces de extender partes de sí mismos en forma de pseudópodos. Imaginemos que dos de estos organismos extienden pseudópodos uno hacia el otro, como si se dieran la mano, y que el material celular en la zona 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 o ocurren tanto en A como en B.

Los individuos, estados y eventos compartidos pueden tener un aspecto diferente para los dominios que los comparten. Consideremos, por ejemplo, una interfaz entre un ordenador y un teclado. Cuando el dominio del teclado ve el evento " El operador del teclado pulsa la barra espaciadora", el ordenador verá el mismo evento como " Aparece el byte hexadecimal ("20") en el búfer de entrada".

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 elementos 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.
• Las líneas punteadas representan referencias a requisitos : referencias en el requisito a fenómenos en los dominios del problema.

Una interfaz que conecta un dominio de problema con la máquina se denomina interfaz de especificación , y los fenómenos que se presentan en dicha interfaz se denominan fenómenos de especificación . El objetivo del analista de requisitos es desarrollar una especificación del comportamiento que la máquina debe exhibir en la interfaz de máquina para satisfacer el requisito.

Aquí tenéis un ejemplo de un diagrama de un problema real, aunque sencillo.

Este problema podría estar relacionado con un sistema informático hospitalario. En el hospital, los pacientes están conectados a sensores que detectan y miden su temperatura y presión arterial. El requisito es diseñar una máquina que muestre información sobre el estado del paciente en un panel en la estación de enfermería.

El nombre del requisito es "Visualización ~ Estado del paciente". La tilde (~) indica que el requisito se refiere a una relación o correspondencia entre la pantalla del panel y el estado del paciente. La flecha indica que la referencia al requisito vinculada al dominio de Visualización del panel también es una restricción. Esto significa que el requisito contiene una condición que la pantalla del panel debe cumplir. En resumen, el requisito es que la pantalla del panel muestre información que coincida con el estado del paciente y lo reporte con precisión.

Un marco de problemas es la descripción de una clase reconocible de problemas, donde dicha clase tiene una solución conocida. En cierto modo, los marcos de problemas son patrones de problemas.

Cada marco de problema tiene su propio diagrama de marco . Un diagrama de marco se parece esencialmente a un diagrama de problema, 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 los dominios están anotados para indicar el tipo (causal o negociable) del dominio.

En su obra "Marcos de problemas", Jackson analizó 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 introduce 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.

Jackson también analiza ciertos tipos de preocupaciones que surgen al trabajar con marcos de problemas.

Preocupaciones particulares

• invadir
• inicialización
• fiabilidad
• identidades
• lo completo

Preocupaciones sobre la composición

• descripciones comparables
• consistencia
• precedencia
• interferencia
• sincronización

La idea intuitiva que subyace a este planteamiento del problema es:

• Existe alguna parte del mundo físico cuyo comportamiento debe controlarse para que cumpla ciertas condiciones. El problema consiste en construir una máquina que imponga dicho control.

La idea intuitiva que subyace a este planteamiento del problema es:

• Existe una parte del mundo físico cuyo comportamiento debe controlarse mediante comandos emitidos por un operador. El problema consiste en construir una máquina que acepte dichos comandos y aplique el control correspondiente.

La idea intuitiva que subyace a este planteamiento del problema es:

• Existe algún aspecto del mundo físico sobre cuyos estados y comportamiento se necesita información constante. El problema consiste en construir una máquina que obtenga esta información del mundo y la presente en el lugar y formato requeridos.

La idea intuitiva que subyace a este planteamiento del problema es:

• Se necesita una herramienta que permita al usuario crear y editar un tipo específico de texto u objetos gráficos procesables por ordenador, o estructuras similares, para poder copiarlos, imprimirlos, analizarlos o utilizarlos de otras maneras. El problema consiste en construir una máquina que funcione como tal herramienta.

La idea intuitiva que subyace a este planteamiento del problema es:

• Se dispone de archivos de entrada legibles por ordenador cuyos datos deben transformarse para obtener archivos de salida específicos. Los datos de salida deben tener un formato determinado y derivarse de los datos de entrada siguiendo ciertas reglas. El problema consiste en construir una máquina que genere los resultados requeridos a partir de las entradas.