Ingeniería de sistemas basada en modelos (MBSE) como metodología no aborda directamente capacidades, que describe las habilidades de un sistema para lograr o realizar una tarea o una misión. Como parte de la descripción de un problema, las capacidades tienen una fuerte conexión con los requisitos del sistema y se pueden modelar utilizando enfoques similares. En la publicación del weblog de SEI Requisitos en Ingeniería de Sistemas Basada en Modelos (MBSE), discutí el dominio de requisitos. En esta publicación, considero el papel de las capacidades en la ingeniería de sistemas: su propósito, cómo se modelan y analizan mediante MBSE y SysML, y cómo se pueden asociar con los requisitos comerciales.
Capacidad es un término sobrecargado. Existen capacidades comerciales y habilidades técnicas del dominio de la arquitectura empresarial, capacidades de solución del dominio del proceso de desarrollo de sistemas, como marco ágil escalado (SAFe)Y solo capacidades de el perfil unificado para DoDAF/MODAF (UPDM) o Marco arquitectónico unificado (UAF). Estas definiciones se dividen esencialmente en dos tipos: (1) un concepto de alto nivel que describe la capacidad de un sistema para lograr o realizar una tarea o misión y (2) un concepto técnico que describe una solución para un problema comercial específico. En esta publicación de weblog, me enfoco en el primer tipo de capacidad, un concepto de alto nivel al que me referiré simplemente como capacidad.
Los gerentes de productos o proyectos a menudo consideran las capacidades de un sistema futuro o existente al considerar la visión y la hoja de ruta del sistema. Las capacidades proporcionan una imagen completa en ausencia de detalles de implementación. Al igual que los requisitos, las capacidades son elementos de la descripción del problema. Las capacidades y los requisitos están estrechamente conectados y se informan y perfeccionan mutuamente. Los expertos en negocios a menudo definen las etapas del proceso comercial respondiendo primero a la pregunta, ¿Qué debería poder hacer el sistema? A partir de ahí surgen las capacidades.
Por ejemplo, M. Maier en su artículo de 1998, “Principios de arquitectura para el sistema de sistemas” descrito sistemas de transporte inteligente (ITS) como un ejemplo de un sistema de sistemas. ya que Según Maier, la visión empresarial de este tipo de sistemas es
- proporcionar “información en tiempo actual sobre condiciones gráficas y opciones de transporte a los viajeros en cualquier lugar”
- “permitir que un viajero escanee las condiciones del tráfico y elija el modo de transporte con el menor tiempo de viaje previsto”
- “permitir la aplicación de una amplia gama de estrategias de management de tráfico en áreas metropolitanas utilizando estrategias optimizadas a partir de la información disponible”
- utilizar información que “podría incluir estimaciones predictivas y en tiempo actual de los tiempos de enlace en toda la crimson de tráfico”
- usar información que podría incluir “estadísticas en tiempo actual sobre los puntos de inicio y destino del conductor y la ruta planificada”
De esta visión de negocio se podrían extraer varias capacidades, entre ellas
- gestión de viajeros
- gestión de condiciones de viaje
- gestión de controles de tráfico
- gestión de la información
- gestión de rutas
- gestión y optimización de estrategias de management de tráfico
- gestión de la comunicación
MBSE ofrece explícitamente un medio para modelar los requisitos, pero no brinda capacidades como un tipo de elemento. Hay un requisito de negocio elemento (ver mi publicación Requisitos en Ingeniería de Sistemas Basada en Modelos) que se puede utilizar para modelar las capacidades del sistema, como se muestra en la Figura 1 a continuación.
Figura 1: Ejemplo de requisitos comerciales como capacidades
Al igual que con muchos elementos de alto nivel en la ingeniería de sistemas, las capacidades requieren descomposición. Artículos en Analista moderno, Capsteray el Cuerpo de conocimiento de arquitectura de tecnología empresarial establece que puede haber hasta cinco niveles de capacidades, y el número de niveles depende del tamaño y la complejidad del sistema. Los sistemas complejos de sistemas pueden requerir los cinco niveles más un subnivel, capaz de. El ejemplo de la Figura 2 usa solo tres niveles de descomposición de capacidad y llama a estos niveles categorías. Las capacidades se pueden organizar en función de otros principios, como áreas funcionales o estructura empresarial. El uso de la estructura del paquete, los estereotipos personalizados y la codificación por colores puede ayudar a los ingenieros de sistemas y a los arquitectos comerciales o empresariales a organizar mejor la descomposición de la capacidad.
Figura 2: Ejemplo de organización de capacidad por paquete
Si la estructura del paquete se utiliza para organizar las capacidades de un sistema, la derivar La relación muestra la descomposición de las capacidades de diferentes paquetes que representan niveles, como se muestra en la Figura 3. Para el etiquetado visible de capacidades de diferentes categorías, los estereotipos personalizados pueden ser útiles.
Figura 3: Ejemplo de descomposición de capacidad con estereotipo personalizado
Como se muestra en la Figura 4, una combinación de estereotipo personalizado, codificación de colores y relación padre-hijo también puede organizar capacidades sin separarlas en diferentes paquetes.
Figura 4: Ejemplo de descomposición de capacidad con codificación de colores
Una función de las capacidades es cubrir lo que hace una empresa o un sistema sin necesidad de desglosarlos en detalles. Los detalles que incluyen una vista del usuario de la funcionalidad o las restricciones provienen de los requisitos. Un buen modelo debe ofrecer una conexión entre capacidades y requisitos. En lugar de derivar la relación entre las capacidades representadas como requisitos comerciales y otros requisitos (como mostré en la publicación del weblog SEI Requisitos en Ingeniería de Sistemas Basada en Modelos (MBSE)), el más suelto rastro Se puede usar la relación, como se muestra en la Figura 5.
Figura 5: Ejemplo de trazabilidad de capacidad a requisitos
Conectar las capacidades con los requisitos crea un vínculo very important entre dos tipos diferentes de descripción conceptual del problema que ayuda a gestionar la complejidad del sistema. Al mantenerse en un alto nivel de abstracción, las capacidades permiten a un arquitecto planificar las fases de la evolución del sistema sin tener que tener en cuenta muchos detalles. Esos detalles no se perderán si se capturan como requisitos y se rastrean hasta la capacidad correspondiente.
Hay una diferencia clave entre las capacidades y los requisitos: los requisitos provienen de diferentes fuentes, patrocinados por diferentes partes interesadas y, por lo common, se capturan en diferentes niveles de abstracción. Por el contrario, las capacidades siempre deben representar una visión coherente y consolidada del sistema o empresa.
Después de capturarlos y descomponerlos, se deben analizar las capacidades. Un tipo de análisis es identificar dependencias entre capacidades. Aunque dos capacidades pueden pertenecer a dos áreas diferentes del sistema, una puede depender de otra, como se muestra en la Figura 6 a continuación. La naturaleza de las dependencias también puede diferir. Una capacidad puede depender funcionalmente de otra capacidad debido a un proceso comercial, orden de operaciones o transferencia de datos.
Figura 6: Ejemplo de relación de dependencia de capacidad
Por otro lado, una capacidad puede ser una extensión de otra capacidad utilizando una funcionalidad ya existente del sistema. Tales capacidades deben desarrollarse en un orden apropiado, como se muestra en la Figura 7 a continuación. Él dependencia La relación captura esta información elementary en el modelo y asegura que se entregará a la siguiente fase del ciclo de vida del desarrollo del sistema.
Figura 7: Ejemplo de relación de dependencia de capacidad utilizada para capturar la dependencia de desarrollo
Las capacidades por sí solas no son suficientes para comprender cómo funcionará un sistema o una empresa. Deben complementarse con una explicación de cómo se comportará un sistema cuando muestre esas capacidades. Incluso cuando nos mantenemos en un alto nivel de abstracción, necesitamos analizar el comportamiento del sistema o empresa en ese nivel. A Lenguaje de modelado de sistemas (SysML) El diagrama de actividad es una forma de capturar el comportamiento en forma de proceso. Una relación a usar para asociar capacidad y actividad es refinarcomo se muestra en la Figura 8 a continuación.
Figura 8: Ejemplo de Relación entre Capacidad y Actividad
Como parte del análisis de capacidad, un arquitecto a menudo comienza a pensar en una parte de un sistema o módulos que realizarán las capacidades bajo análisis, así como en los usuarios y los roles que desempeñarán los humanos al interactuar con el sistema o como parte del mismo. empresa. Aquí el actividad y bloquear Los elementos de SysML podrían ayudar, como se muestra en la Figura 9 a continuación.
Figura 9: Ejemplo de capacidad con ejecutante, rol y proceso
Cuando un arquitecto empresarial termina la descomposición y el análisis de las capacidades, el siguiente paso lógico es crear una hoja de ruta para el desarrollo de capacidades y una versión que incluya la fase de las capacidades. Para ello, SysML no proporciona ninguna herramienta especializada. Todas las relaciones capturadas por el modelo junto con el análisis estándar ayudarán a un arquitecto a encontrar una ruta crítica para entregar una capacidad y definir la hoja de ruta, como se muestra en el ejemplo de la Figura 10 a continuación.
Figura 10: Ejemplo de análisis de hoja de ruta
Observaciones y Conclusiones
SysML tiene algunas deficiencias en su compatibilidad con la arquitectura empresarial y de cartera que se pueden superar con la ayuda de marcos arquitectónicos:
- SysML no admite funciones de forma predeterminada.
- Un arquitecto deberá crear estereotipos adicionales y un mecanismo de cumplimiento para adaptarse a las capacidades.
- SysML no admite la creación de una hoja de ruta para las capacidades, incluida la planificación a lo largo del tiempo.
En teoría, sería posible que un arquitecto empresarial experimentado creara un metamodelo personalizado para implementar hasta cierto punto uno de los marcos arquitectónicos estándar, como El marco de arquitectura de grupo abierto (TOGAF) o Marco de arquitectura DoD (DoDAF)/Marco de arquitectura unificado (UAF) usando solo SysML. Sin embargo, hacerlo llevaría mucho tiempo y produciría un resultado apenas utilizable. Dicho metamodelo sería complejo, difícil de implementar y seguir, y difícil de hacer cumplir sin reglas complicadas de verificación de modelos que serían difíciles de crear. Una mejor opción sería mirar las extensiones existentes de SysML que implementan un marco arquitectónico de elección. Todos los principales proveedores de entornos de modelado MBSE/SysML admiten los marcos arquitectónicos más populares.
Las capacidades de modelado que utilizan MBSE abordan varios aspectos críticos de la construcción de un sistema de sistemas. El modelado de capacidades ayuda a los ingenieros de sistemas a administrar la complejidad y el volumen de requisitos al abstraer características específicas del sistema. Este nivel de abstracción también facilita la comunicación entre las partes interesadas y ayuda a crear la hoja de ruta del proyecto. Al ayudar a producir capacidades bien analizadas y entendidas, el modelado respalda la creación de un mejor sistema y arquitectura empresarial. Las prácticas de MBSE respaldan la trazabilidad de las capacidades a los requisitos, así como la trazabilidad de las capacidades a la arquitectura operativa y lógica transitivamente a la arquitectura de la solución. Una mayor trazabilidad mejora la calidad del sistema y garantiza la confianza de que el sistema se construirá de acuerdo con los requisitos.
