Las dos tareas más importantes en ingeniería de sistemas son comprender las necesidades de las partes interesadas y transformarlas en requisitos del sistema. Este white paper analiza el empleo de modelado en fases iniciales de desarrollo para realizar estas tareas. También se exponen técnicas de modelado con diversos grados de valor y sofisticación, desde modelos puramente descriptivos hasta pruebas formales. Lograr mayor calidad de requisitos del sistema justifica por sí sola la inversión en estas técnicas. Pero los modelos resultantes también se pueden utilizar en etapas posteriores del proyecto para representar las necesidades de las partes interesadas de forma más efectiva. En este documento también mostramos cómo utilizar modelos de requisitos para obtener requisitos del sistema congruentes y completos. La figura 1 muestra el proceso para obtener estos beneficios.
Figura 1. Proceso de transformación de necesidades de las partes interesadas en requisitos del sistema que producen requisitos detallados.
En este caso práctico, se extraerán los requisitos del sistema de refrigeración de una máquina a partir de las necesidades de las partes interesadas detalladas a continuación:
Proporcionar un sistema que mantenga la temperatura en funcionamiento de una máquina para evitar daños por sobrecalentamiento.
- [restricción] El sistema de refrigeración debe mantener la temperatura en funcionamiento por debajo de 40 °C.
- [restricción] La refrigeración se debe realizar dentro de un tiempo establecido.
- [supuesto] La temperatura ambiental de ser superior a -10 ˚C e inferior a 80 ˚C.
Estas necesidades de las partes interesadas son ambiguas y podrían malinterpretarse fácilmente, lo que a su vez podría provocar requisitos del sistema incompletos o incorrectos, y en última instancia, generar un diseño que no cumple las expectativas. Para evitarlo, es necesario validar las necesidades de las partes interesadas.
Existen técnicas de modelado que ayudan a validar las necesidades de las partes interesadas y unificar criterios en un conjunto de requisitos del sistema. Estos métodos incluyen el uso de:
Describiremos cada uno de estos métodos en las siguientes secciones, y concluiremos con un análisis del uso de un hilo digital para establecer trazabilidad entre las necesidades de las partes interesadas y los diversos niveles de requisitos capturados.
Un primer paso para explorar las necesidades de las partes interesadas consiste en describir los distintos escenarios en que el sistema de refrigeración debe funcionar. Por ejemplo, qué ocurre si la temperatura es demasiado alta, o cuando la refrigeración no es efectiva.
Los modelos de requisitos descriptivos son más avanzados que los requisitos del lenguaje natural tradicionales, ya que ofrecen una representación gráfica y estructurada de cada requisito, lo que mejora la colaboración entre los equipos de trabajo involucrados. Un diagrama de secuencia es un buen ejemplo de representación.
Introducción a los modelos descriptivos
Un modelo descriptivo es una especificación gráfica de un sistema que describe lo que el sistema es o hace de una manera legible.
La figura 2 describe el siguiente escenario: Si la temperatura (T) es demasiado alta (T>=40), se necesita refrigeración; si la refrigeración es efectiva (T<40), la refrigeración debe apagarse; pero si no es efectiva (delay>=30), la máquina debe apagarse.
Figura 2. Diagrama de secuencia que describe nuestro escenario.
Los diagramas de secuencia ofrecen descripciones gráficas de cómo los componentes modelados del sistema de refrigeración funcionan juntos en diferentes escenarios. No obstante, estos modelos de requisitos descriptivos son una parte intrínseca del dominio de ingeniería, mientras que los modelos de requisitos simulables (o ejecutables) permiten sacar conclusiones y observaciones en el dominio del sistema, lo que permite a las partes interesadas comprender directamente los requisitos en el contexto de su dominio específico. Un gráfico de estados es un buen ejemplo de formalismo ejecutable que puede producir estas salidas (consulte la figura 3).
Introducción a los modelos de simulación
Un modelo de simulación es una especificación de sistema destinada a interpretación automática donde las salidas de la interpretación se someten a interpretación humana para sacar conclusiones.
Figura 3. Componente de arquitectura simulable (máquina de estado) y sus salidas.
Esto es importante, porque la simulación ofrece una interpretación inequívoca de cada escenario descrito en los diagramas de secuencia anteriores. Además, proporciona un medio para comunicar esta interpretación a las partes interesadas, explorar diferentes escenarios y comprender las necesidades específicas, para poder describir esa información en los requisitos del sistema.
Ahora que tenemos un modelo que simula los comportamientos especificados en los diagramas de secuencia, las partes interesadas pueden observar y analizar las salidas generadas por la máquina de estado. Asimismo, podemos validar si el comportamiento de la máquina de estado es congruente con los escenarios descritos en el diagrama de secuencia. En la figura 4, las marcas de selección verdes del diagrama de secuencia indican que los eventos correctos se han producido en el orden correcto durante la simulación. Esto confirma que el comportamiento del modelo funcional es correcto. Estos resultados también se pueden utilizar para la validación con las partes interesadas.
Figura 4. Validación mediante simulación.
Aunque las técnicas de simulación ofrecen una buena cobertura de los comportamientos del sistema, la simulación suele estar orientada a escenarios clave para permitir trabajo colaborativo. Los modelos de requisitos formales, por otro lado, contienen formalismos que permiten una evaluación más sistemática de la calidad del modelo en cuestión.
Uno de estos formalismos es una tabla de requisitos, que se puede utilizar para demostrar formalmente la congruencia y la integridad de un conjunto de requisitos. Requisitos congruentes son los que no provocan conflictos, mientras que requisitos completos son aquellos en los que no falta ninguna funcionalidad. Las columnas de precondiciones (A) de la figura 5 describen las entradas del sistema (valores de temperatura) y cuándo un requisito es válido o está “activo”. Las columnas de poscondiciones (B) describen el comportamiento esperado cuando el requisito especificado está activo.
Introducción a los modelos formales
Un modelo formal es una especificación de un sistema destinada a interpretación automática donde las salidas de la interpretación se procesan para presentar conclusiones definitivas para uso humano.
Figura 5. Modelo formal para describir requisitos.
Por ejemplo, el requisito N.º 1 establece que cuando T es inferior a 40 ˚C (T<40), el sistema de refrigeración debe apagarse (Turn_off_cooling == true).
Un análisis que utilice los métodos formales de Simulink Design Verifier™ ahora puede determinar si los requisitos son congruentes y completos. En la figura 6 no se ha incluido el escenario en el que la temperatura es exactamente 40 ˚C y, por lo tanto, este conjunto de requisitos está incompleto.
Figura 6. El análisis formal ha identificado un problema de integridad (falta T=40).
Prueba de modelos de diseño
Los modelos de requisitos formales proporcionan un buen punto de partida para los equipos de trabajo que intervienen después de la fase inicial, dado que la calidad de los requisitos es mayor y los elementos del modelo de requisitos se pueden reutilizar durante el diseño, generación automática de pruebas y verificación. Los modelos de requisitos también se pueden utilizar como parte de pruebas unitarias para garantizar que se desarrollen modelos funcionales que cumplan con los requisitos. Estas pruebas unitarias se pueden ejecutar interactivamente y como parte de un marco de CI/CD. La figura 7 muestra que los requisitos 1 y 2.2 superan la prueba, y los otros requisitos no se han aplicado.
Figura 7. Uso de requisitos formales como prueba para validar modelos de diseño.
Hilo digital
A lo largo de las diferentes etapas del ciclo de desarrollo de productos se crean o generan muchos artefactos. Estos artefactos digitales incluyen requisitos, arquitectura, modelos de diseño, archivos de código y archivos de verificación y validación. Es fundamental establecer un enlace con trazabilidad entre estos artefactos para comprender cómo los requisitos afectan a otros requisitos, modelos, o actividades de verificación y validación. Este enlace sirve como hilo digital.
Por ejemplo, se pueden generar automáticamente diagramas de trazabilidad de requisitos a partir de los requisitos y modelos de arquitectura, lo que aporta información sobre cómo estos requisitos, modelos y artefactos de verificación están enlazados gráficamente entre sí.
La figura 8 muestra el hilo digital donde las necesidades de una parte interesada son satisfechas por otra parte interesada. En realidad, existen varias partes interesadas a lo largo de la organización que cubren diferentes áreas funcionales con diversos niveles de abstracción. Es por eso que el hilo digital resulta indispensable. Además, un hilo digital facilita el uso de infraestructura y procesos automáticos, ágiles, iterativos y prácticas de DevOps. Por ejemplo, la figura 8 muestra cómo el estado de verificación de una prueba se comunica automáticamente al personal de ingeniería responsable.
Figura 8. Diagrama de trazabilidad que muestra el hilo digital del sistema de refrigeración.
A medida que las organizaciones emprenden su camino de transformación digital, los conceptos de hilos digitales, gemelos digitales y prácticas de DevOps desempeñan papeles complementarios para establecer una base sólida para la ingeniería digital. Estos conceptos actúan solidariamente para crear una infraestructura que permite la transición de prácticas de ingeniería tradicionales a digitales.
En este documento, hemos descrito un proceso en el que, a partir de las necesidades de las partes interesadas, se unificaron los criterios en requisitos del sistema (simulables/ejecutables) utilizando simulación y métodos formales. Para ello, utilizamos modelos de requisitos que podían simular (máquinas de estado), evaluar (diagramas de secuencia) y analizarse formalmente (tabla de requisitos).
El uso de modelos de requisitos permite automatizar las actividades de verificación y validación, lo que produce requisitos del sistema completos, congruentes y validados. Además, mejoran la colaboración entre los diferentes equipos de trabajo, ya que ofrecen más información que la que pueden facilitar requisitos puramente descriptivos o basados en texto.
Por Alan Moore, Becky Petteys y Stephan van Beek
