Aerospace & Defence

El control y validación de un software no son, por lo tanto, procesos meramente técnicos, sino que responden a una filosofía operativa centrada en dos necesidades clave: a) comprobar si se ha realizado el software que el cliente espera y que ha descrito al comienzo del proceso; b) convalidar la correcta creación desde el punto de vista técnico y conforme a las condiciones impuestas.

En el Área de Defensa y Espacio Aéreo, Exprivia es especialmente competente con respecto al proceso de Control y Validación (es decir, puesta a prueba del software), en el que se sirve también de la colaboración de departamentos informáticos universitarios.

Objetivos
Los principales objetivos del procedimiento de realización de pruebas del software consisten en garantizar la independencia del equipo de ensayo respecto al equipo de desarrollo, detectar y gestionar posibles defectos del software, proporcionar datos para evaluar los avances de desarrollo de forma autónoma y junto al cliente durante el ciclo de vida o parte del mismo, proporcionar una certificación del producto y/o de los sistemas de software que incluya una completa trazabilidad de los defectos detectados durante la actividad de puesta a prueba.

La validación del software prevé dos pasos: evaluación de los resultados y gestión del cambio.

• Evaluación de los resultados: evaluación continua y reiterada de los resultados (documentales y software) de la implementación de los requisitos del sistema y/o software respecto a los Requisitos de Usuario (User Requirements) (si están presentes) mediante técnicas de análisis e inspección interna y/o a través de revisiones acordadas con el cliente o los usuarios finales;
• Gestión del cambio: en caso de cambio de los requisitos de usuario, de los requisitos del sistema, de los requisitos del software, en cualquier fase del ciclo de vida del software, activar una investigación sobre el impacto que dichos cambios tienen sobre la totalidad del propio sistema.

Ventajas
A pesar de la poca difusión de la cultura de la puesta a prueba del software en las empresas, los procesos de control y validación ofrecen ventajas relevantes con costes reducidos:

• detectar defectos del software ya en la fase inicial de desarrollo, obteniendo así ventajas en términos de estabilidad del propio software y un ahorro sustancial en términos de costes para la resolución de problemas (detección temprana de defectos de software);
• aumentar el control en todo el ciclo de vida del software, mediante un proceso que permita gestionar de forma organizada los defectos del software y garantice la trazabilidad de la correlación entre defectos, requisitos y pruebas con que se han detectado;
• introducir un ciclo positivo de feedback entre equipo de ensayo y diseñadores y desarrolladores para corregir los defectos detectados en tiempos breves;
• crear documentos y certificados que atestigüen la corrección y la validez del software conforme a los criterios acordados junto al cliente, o también el cumplimiento con criterios y niveles requeridos por organizaciones y/o estándares internacionales.

Proceso de Aceptación

Definición de estándar documental. Se elige el estándar documental que se debe utilizar durante todo el ciclo de vida: se trata de un set de plantillas documentales sobre el que basar la descripción de todo el sistema y de las actividades vinculadas al mismo (planes).

• MIL-STD-498, estándar documental completo de origen militar que abarca todos los aspectos vinculados al ciclo de vida del software;
• estándar que ya posee el cliente y se puede adoptar tal como es o, también, se puede adquirir y modificar de acuerdo con nuevas necesidades;
• estándar ex profeso que se debe definir desde cero junto al cliente.

Definición del flujo de trabajo
En esta actividad, se define el procedimiento de aceptación de los ítems documentales y de los ítems de software y del sistema y su archivo junto al sistema de versiones que se debe adoptar y los niveles de firma previstos para los ítems. En esta fase también se define el flujo de trabajo para la gestión formal del Informe de Problemas (Problem Report).

Individuación de la cadena de herramientas
de garantía de calidad (quality assurance toolchain) Elección de las herramientas de software de soporte de las actividades de garantía de calidad, como la aceptación de ítems, la gestión del informe de problemas, las propuestas de cambio de software, etc., (por ej.: SAP, Polarion, Redmine).

Adquisición de normativas
Durante esta actividad, se reúne información sobre las normativas legislativas aplicables (si las hay), sobre las normas vinculadas al sector/área al que pertenece el cliente y sobre las normas técnicas aplicables (ISO, IEEE…) relevantes para la redacción de las especificaciones.

Formalización
Durante esta actividad, se definen, de acuerdo con el cliente, las cuestiones formales en lo que se refiere a las especificaciones, los niveles de detalle de las mismas y los niveles del sistema de software pertinente:

• las cuestiones formales se refieren al lenguaje o la técnica seleccionada para escribir las especificaciones: se pueden usar especificaciones informales (informal specifications (párrafos escritos en lenguaje común) o también lenguajes semiformales como el UML2 (Unified Modeling Language - Lenguaje Unificado de Modelización) o derivados o, también, lenguajes para especificaciones formales (formal specification languages) (notaciones matemáticas formales como el Lenguaje Z);
• los niveles de detalle disponibles comprenden necesidades del usuario, características, requisitos de software;
• los niveles del sistema previstos: sistema, subsistema y módulo software. Se pueden combinar cuestiones formales, niveles de detalle y niveles de sistema de acuerdo con las diversas necesidades y objetivos.

Contenido
Durante la actividad para reunir las especificaciones, se proporciona soporte directo al cliente en la definición práctica de requisitos con el fin de mejorar su claridad de exposición y su carácter exhaustivo.

Definición
De acuerdo con el sector del sistema objetivo, se definen las necesidades para el entorno de ensayo tanto desde el punto de vista del hardware como del software adecuado para las diversas actividades de ensayo definidas, describiendo así el entorno a través de las especificaciones pertinentes.

Toolchain y tecnología para la puesta a prueba
Se individúan las tecnologías necesarias para crear el Entorno de ensayo y las herramientas necesarias para el soporte de las actividades de prueba. Se puede efectuar un sondeo de las tecnologías y herramientas utilizadas en la sede del cliente con el fin de volver a utilizar las mismas.

Desarrollo de procesos originales
En caso de que el cliente lo requiera, o si se individúa la necesidad, se puede realizar una plataforma para una puesta a prueba original, que se integre con las tecnologías y las herramientas individuadas. El cliente puede encargarla (y, por lo tanto, se cederá al mismo); también se pueden adaptar los productos internos de nuestra empresa, en caso de que hubiera alguno adecuado.

Planificación de Actividades de Prueba
Fase en la que se programan las sesiones de prueba, estimando los esfuerzos en términos de recursos y tiempo. La descripción de dichas actividades confluye en los planes descritos utilizando los estándares documentales individuados.

Definición de los casos de prueba
En esta fase, los diseñadores de las pruebas proyectan y realizan los casos de prueba cumpliendo con los requisitos. La definición prevé un refinado continuo (reiterativo) de las pruebas, también mediante la ejecución de las mismas in situ.

Ejecución de las sesiones de prueba
Durante esta actividad, se realizan sesiones de prueba planificadas en el entorno de prueba definido. Estas pueden ser semiformales, como la ejecución en seco, o formales, como las calificaciones de módulo, si están previstas. Dichas actividades se pueden repetir si la programación (scheduling) lo prevé, o también si se han hallado fallos totales o parciales (se pueden repetir el subconjunto seleccionado).

Gestión de los informes de problemas (problem report)
Cuando, durante las actividades de definición de los casos de prueba y de ejecución de las sesiones de prueba, surgen problemas en el software puesto a prueba, dichos problemas deben dar vida a un PR (Problem Report - Informe de Problemas), donde los mismos se identifican de forma unívoca. Los PR se gestionan mediante las herramientas y el flujo de trabajo definidos en las fases previas.

Las tecnologías utilizadas en las plataformas de control del software para las pruebas automáticas comprenden tecnologías para la gestión del flujo de trabajo de los ítems aplicativos, documentales y de ensayo, lenguajes para el desarrollo de la plataforma de prueba y de los procedimientos de prueba, sistema de soporte de la plataforma de prueba (integración, mensajes), herramientas para grabar y repetir las acciones en GUI (Interfaz gráfica de usuario) Java (Swing, JavaFX), QT, web, set de librerías como soporte a las actividades de transformación Model2Text (de Modelo UML2 a Código), tecnologías de virtualización Vmware –con el fin de aprovechar al máximo los recursos de hardware disponibles, habilitar un despliegue rápido, la tolerancia a fallos y otros.