Las industrias críticas para la seguridad pueden definirse con ligereza como aquellas en las que una falla de software podría matarlo. Piense en los dispositivos automotrices, de aviación o médicos como ejemplos. Las industrias críticas para la seguridad utilizan procesos pesados ​​para garantizar que (especialmente, pero no exclusivamente) el software se desarrolle de manera segura. Los procesos pesados ​​a menudo necesitan herramientas pesadas. En términos de gestión de requisitos , esas herramientas de gestión de requisitos pesados ​​(RMT *) incluyen DOORS, DOORS Next Generation, Polarion, Jama, solo por nombrar algunos. Estos RMT pesados ​​requieren una inversión sustancial de tiempo y dinero para usarse correctamente.

He sido ingeniero de requisitos durante muchos años y he trabajado en proveedores de aviónica y automoción que tenían los recursos para implementar esos RMT pesados. Estoy acostumbrado a tener sus funciones avanzadas al alcance de la mano. Ahora soy el ingeniero de requisitos del equipo de Linux para automoción aquí en SUSE y mi trabajo es utilizar los recursos disponibles para gestionar con éxito los requisitos de nuestros proyectos de automoción. Analizamos detenidamente cómo invertir recursos en un RMT pesado. Pero ya teníamos a Jira en su lugar, por lo que asumimos el desafío para ver si podía servir como nuestro RMT.

Jira nunca fue diseñado para ser un RMT. Jira fue diseñado para ser un rastreador de errores y problemas. Pero tiene las características principales de las RMT: objetos (problemas) direccionables individualmente con atributos (campos) que se pueden vincular entre sí. El resto es solo presentación. Entonces, en el fondo, Jira proporciona la funcionalidad principal de un RMT; solo tenemos que trabajar para complementar su presentación.

Configurar Vanilla Jira (sin complementos **) como RMT es un asunto sencillo. Puede crear algunos tipos de problemas para representar sus tipos de requisitos (por ejemplo, requisitos de las partes interesadas, requisitos del sistema, requisitos de software). Haga una lista de los atributos que necesitará cada tipo de requisito. Por ejemplo, es posible que necesite algo para indicar si el requisito es "funcional" o "no funcional". Es posible que necesite un campo de texto para contener la justificación de por qué es necesario el requisito. Etcétera etcétera. Puede asignar esas necesidades a campos existentes (por ejemplo, texto de requisito en el campo Descripción) o crear campos personalizados y banderas para contener los datos. Usted crea o reutiliza tipos de enlaces para vincular sus requisitos. Una vez que todo está implementado, puede buscar, ver, crear, modificar y vincular requisitos como cualquier otro RMT pesado, tal vez no tan eficientemente.

Con esta configuración de Jira-as-RMT en su lugar, puede comenzar felizmente a completar el proyecto con sus requisitos. Eventualmente, necesitará crear una salida para que alguien la lea. Hay tres documentos de salida clave en la gestión de requisitos y, por el bien de este ejemplo, me ceñiré a los requisitos de software. El primero es el plan de gestión de requisitos (RMP) que describe cómo gestiona los requisitos. Este suele ser un documento escrito gratuito, es decir, no se genera a partir de datos. Jira no es de ayuda aquí. Puede usar su prima Confluence para escribir su RMP, Word o lo que sea. El segundo documento de salida clave tiene muchos nombres, pero lo llamaremos especificación de requisitos de software (SRS). El SRS debe incluir todos los requisitos de software aplicables del proyecto más secciones adicionales sobre suposiciones y algo sobre arquitectura y otro material explicativo para ayudar al lector a comprender los requisitos de software del proyecto, incluido el uso liberal de imágenes y tablas. Este documento se puede crear en Confluence (las "secciones adicionales") y utilizar filtros de Jira integrados para incluir los requisitos en sí. Uno puede imaginar otras formas, por ejemplo, volcar los requisitos de Jira en documentos individuales de Word y fusionarlos con las secciones adicionales.

El tercer documento de salida clave se llama matriz de seguimiento (TM). Este es el complicado para Jira. La TM es típicamente una hoja de cálculo que enumera cada ruta única a través de los requisitos de vinculación. Por ejemplo, dado un conjunto de requisitos de partes interesadas, vinculados a los requisitos de su sistema, vinculados a sus requisitos de software, vinculados a casos de prueba y resultados, la MT mostraría cada ruta única desde cada requisito de parte interesada hasta un resultado de prueba. Si imagina los requisitos y los casos de prueba como nodos, y los enlaces como bordes, todo el conjunto constituye un gráfico y está realizando una búsqueda en profundidad (DFS) comenzando por los requisitos de las partes interesadas. El objetivo principal de la MT es analizar estas rutas para garantizar que cada requisito esté completamente cubierto por requisitos de nivel inferior y, finalmente, probado.

Usamos Ruby de otras formas para complementar nuestro Jira-as-RMT. Obtenemos hojas de cálculo de Excel para actualizar los requisitos del cliente. Estos son procesados ​​por un script Ruby para transformar los datos en algo que se pueda importar a Jira usando su API REST (ese script está escrito en Python). También tenemos un script Ruby que genera archivos CSV que se pueden cargar en una base de datos gráfica de Neo4j . Usando un navegador de escritorio Neo4j podemos generar un gráfico simple, pero expresivo, para visualizar la vinculación entre los requisitos.

Generación de una MT, visualización de enlaces, búsqueda basada en enlaces: todos estos aspectos normalmente forman parte de los RMT pesados ​​mencionados anteriormente, pero deben resolverse con scripts de soporte para Jira. Pero ahora debo confesar que no usamos vainilla Jira aquí en SUSE. También usamos el complemento Structures. Debo admitir que las estructuras son esenciales para mi uso diario de Jira-as-RMT. Crecí como ingeniero usando hojas de cálculo de Excel para todo. Los RMT pesados ​​suelen tener un método de visualización e interacción de estilo matricial (filas como requisitos, columnas como valores de atributo). Entonces, las estructuras en Jira son una forma muy natural para mí de interactuar con los datos de requisitos y, si no tuviera estructuras, probablemente me habría rendido.

(Además, sería negligente si no mencionara una deficiencia evidente con Jira-as-RMT: no hay línea de base. Vanilla Jira no tiene un mecanismo de línea de base . Esto hace explotar muchas estrategias de gestión de requisitos, especialmente en industrias críticas para la seguridad donde la línea de base figura fuertemente en sus criterios de certificación. Argumentamos que una versión adecuada de los documentos de salida puede reemplazar las líneas de base en la herramienta).

Por lo tanto, es posible utilizar Jira como una herramienta de gestión de requisitos (RMT) para un proyecto industrial de seguridad crítica. SUSE lo está haciendo ... con un poco de ayuda de nuestros amigos de scripting.

Para su información: los comentarios y la discusión de este artículo aparecen en mi publicación de LinkedIn .