Ingeniería de la Confiabilidad de Software

Las organizaciones que desarrollan productos basados en software requieren de prácticas efectivas que permitan mejorar la calidad del producto. La Ingeniería de la Confiabilidad de Software es una práctica cuantitativa que puede ser implementada en organizaciones de cualquier tamaño bajo distintos modelos de desarrollo.

Las organizaciones desarrolladoras de productos basados en software destinan grandes cantidades de recursos para mejorar la calidad de sus productos. Una parte de dichos recursos se utiliza para la adopción de mejores prácticas. Sin embargo, la dificultad de la adopción de dichas practicas no sólo reside en el costo y el tiempo requerido para institucionalizarlas, sino en cómo medir su impacto en la calidad del software, así como demostrar el retorno de dicha inversión. El grupo de Confiabilidad de Software y Sistemas (SoSYR) del Centro de Investigación en Matemáticas A.C., lleva a cabo investigación sobre prácticas industriales de bajo costo, con un alto impacto en la calidad de los productos de software y que sean aplicables a organizaciones de distintos tamaños.

En este artículo se introduce a la Ingeniería de la Confiabilidad de Software (ICS). La ICS es una práctica de bajo costo, independiente del modelo de desarrollo y de la plataforma tecnológica que permite caracterizar y controlar de manera cuantitativa la calidad del producto.

La calidad, las fallas y la confiabilidad de Software
La calidad es un atributo percibido por los usuarios o clientes de cualquier producto o servicio. En el caso de productos basados en software, la percepción de la calidad está en función de las fallas que el cliente percibe del mismo durante su operación.

La confiabilidad es un atributo que mide el grado en que un producto opera sin fallas bajo condiciones establecidas por un periodo de tiempo determinado. La confiabilidad es un atributo cuantitativo que ha sido ampliamente analizado, estudiado y usado en otras industrias para caracterizar la calidad de los productos o servicios. En su concepción más general, la confiabilidad es un atributo que mide el grado en que un producto opera sin fallas bajo condiciones establecidas por un periodo de tiempo determinado.

Una falla es la manifestación percibida por el cliente de que algo no funciona correctamente e impacta su percepción de la calidad. Un defecto es el problema en el producto de software que genera una falla.

¿Qué es la Ingeniería de Confiabilidad de Software?

La ICS es una práctica que permite planear y guiar el proceso de la prueba del software de manera cuantitativa. La ICS no es algo nuevo. Se origina en los años 70 con los trabajos de J. D. Musa, A. Iannino, y K. Okumoto[1]. Su efectividad ha hecho que muchas empresas incorporen esta práctica en sus proyectos, tales como AT&T, Alcatel, HP, IBM, Lockheed-Martin, Microsoft, Motorola, entre otras. El impacto de dicha práctica se ha visto en la aprobación de un estándar de la AIAA (en 1993) así como sus correspondientes versiones en los estándares de IEEE. Cabe mencionar que se han documento más de 60 artículos reportando los resultados de la aplicación de la ICS en distintos proyectos[2].

Dos elementos caracterizan la ICS: (1) el uso esperado relativo de las funcionalidades del sistema y (2) los requerimientos de calidad definidos por el cliente, que incluyen la confiabilidad, la fecha de liberación y costo del ciclo de vida del proyecto.

El primer elemento (1) se centra en caracterizar de manera cuantitativa el uso esperado del sistema mediante la definición del llamado perfil de operación del sistema. Esta caracterización cuantitativa permite optimizar el uso de los recursos en las funciones que tengan un mayor impacto y mayor uso esperado dentro
del sistema.

El perfil de operación de un sistema es la caracterización cuantitativa del uso que se espera de las funcionalidades principales del sistema. Por lo general se usan probabilidades para cuantificar dicho uso esperado.

El segundo elemento (2) se refiere al enfoque al cliente mediante el establecimiento de objetivos cuantitativos asociados a la calidad del producto (representados con base a las fallas del producto). La satisfacción de dichos objetivos permite establecer un balance entre los costos del producto, así como la satisfacción de las necesidades del cliente.

¿Por qué usar la ICS?

La ICS es independiente de la tecnología y de la plataforma de desarrollo. No requiere ningún cambio en arquitectura, diseño, o código, sino que puede sugerir los cambios que serían útiles. También, la ICS está altamente orientada al cliente y está altamente correlacionada con los niveles 4 y 5 del Modelo Integrado de Madurez de las Capacidades (CMM-I) del Instituto de Ingeniería de Software. Su alta orientación al cliente se debe a la naturaleza de la información requerida en el proceso de la ICS, lo que implica tener un contacto frecuente y cercano con los clientes. Esta interacción mejora la satisfacción del cliente y reduce riesgos de manera similar a lo propuesto en los métodos ágiles de desarrollo.

La alta correlación con los niveles de madurez 4 y 5 de CMM-I se debe a que dicha práctica satisface varios objetivos relacionados con la medición para la optimización del proceso de desarrollo. La ICS es una buena opción para alcanzar dicho objetivo. Comparado con las ventajas, el costo de aplicar la ICS es bajo de acuerdo a la experiencia de John D. Musa[3]. Hay un costo de inversión de no más de 3 días equivalentes del personal por persona en una organización, que incluye un entrenamiento de dos días para cada uno y la planeación con un número mucho más pequeño. Los gastos reflejados en el proyecto varían típicamente a partir 0.1 a 3.0 por ciento de costo total del proyecto[3]. Cabe mencionar que el componente más grande del costo es el asociado al desarrollo del perfil de operación.

El proceso de la ingeniería de confiabilidad de software

El proceso de la ICS puede verse como un conjunto de actividades adicionales y complementarias a las ya realizadas dentro de cualquier proceso de desarrollo. Seis actividades definen el marco de trabajo de la ICS que son mostradas en la Figura 1 y descritas a continuación.

1. Definir el Producto. Puede verse como un complemento del Análisis de Requerimientos y Diseño Arquitectónico. En esta actividad se define quiénes son los clientes, usuarios, proveedores y otros sistemas relacionados.

2. Desarrollar el Perfil de Operación. Se define el conjunto completo de operaciones (i.e., tareas o funcionalidades lógicas principales del sistema) con su correspondiente probabilidad de ocurrencia o uso esperado. En esta etapa, la administración de los recursos toma un nivel cuantitativo basado en la importancia de cada operación del sistema. La Tabla 1 muestra un ejemplo parcial de un perfil de operación para un producto para la navegación en el Web.

Figura 1. Proceso de la ICS[2]


Tabla 1. Ejemplo de un Perfil de Operación

3. Definir la Confiabilidad Adecuada. Se define lo que se considera como “falla” para el producto en desarrollo así como los medios para identificarla. Esta definición es crítica para el proceso y debe ser constante durante todo el ciclo de vida. La Tabla 2 muestra un ejemplo de clases de severidades de fallas y ejemplos de cada tipo de falla.

Tabla 2. Clases de Severidades de Fallas

En la segunda parte de esta actividad se definen las medidas de referencia con la que se cuantificarán las intensidades de falla, tales como el número de fallas por tiempo o número de fallas por unidad natural. Las unidades naturales representan la cantidad de proceso o trabajo realizado por el sistema (e.g., transacciones, páginas impresas, llamadas a funciones, accesos, etcétera).

En la tercera parte de la actividad se fijan las Intensidades de Falla Objetivo (IFO) para cada sistema asociado al producto. Las IFOs representan la calidad del producto en desarrollo y son definidas por el cliente.

En la cuarta parte se seleccionan las mejores estrategias de apoyo a la confiabilidad de software que ayuden a alcanzar los IFOs respectivos al menor costo. Las estrategias de apoyo a la confiabilidad de software son aquellas actividades y mecanismos dentro del proceso de desarrollo que reducen las intensidades de falla y afectan positivamente los costos y el tiempo de desarrollo. Ejemplos de dichas estrategias incluyen mecanismos de tolerancia a fallos, inspecciones, revisiones, distintos tipos de pruebas, etc.

La ICS proporciona pautas y cierta información cuantitativa para la determinación de la mezcla de estrategias. Sin embargo, los proyectos pueden mejorarse usando la información que es particular a su ambiente y al dominio propio del producto.

4. Preparar las Pruebas. Se definen los casos de prueba y los métodos de prueba a partir de la información de los perfiles operacionales y las estrategias de apoyo a la confiabilidad de software. Esta actividad puede integrarse con el proceso de pruebas del modelo de desarrollo que se tenga. Lo importante en esta etapa es la decisión de qué cosas se van a probar y qué datos se usaran en los casos de prueba.

5. Ejecutar las Pruebas. Se asignan los tiempos para las pruebas entre los sistemas, los tipos de prueba (i.e., características, carga y regresión) así como su ejecución.

6. Guiar las Pruebas. Se procesa la información obtenida en la ejecución de las pruebas para varios propósitos. El primero es monitorear el crecimiento de la confiabilidad del sistema (o la reducción de las intensidades de falla) mientras se van reparando los defectos encontrados que generaron las fallas. Otro propósito es el de poder determinar si es necesario seguir probando; finalmente, el tercero es el de dirigir la fase del liberación del producto. La Figura 2 muestra una grafica típica usada para monitorear la reducción de las intensidades de falla.

Figura 2. Gráfica para controlar las actividades de Prueba[3].

Algo muy importante dentro del proceso de ICS es la recolección de datos de campo (i.e., información sobre el uso y las fallas encontradas en la operación real del sistema). El proceso de ICS no está completo cuando se libera el producto dado que la información que usamos puede ser imprecisa. El recolectar dicha información permitirá evaluar con mayor detalle la satisfacción del cliente y la calidad del producto.

En esta breve descripción del proceso de la ICS se han omitido detalles relacionados con aspectos cuantitativos. Existen modelos estadísticos que permiten determinar el momento para detener las actividades de prueba basados en la información que se tiene de las fallas encontradas, objetivos de intensidades de falla y del número de casos de prueba ejecutados. Recomendamos al lector revisar [3, 4] para una mayor información.

Conclusión

Podemos decir que la efectividad que presenta la ICS reside en una idea ya mencionada por Tom de Marco: “No puedes controlar lo que no puedes medir.”. La bondad de la ICS reside en llevar dicha idea a elementos concretos con beneficios específicos:

• La construcción del perfil de operación mejora el análisis de requerimientos dado que el proceso de cuantificar las probabilidades de uso de las operaciones del producto exige un proceso adicional de reflexión y trabajo con el cliente.
• La definición de lo que se considera como “falla” para el producto involucra discutir con el cliente y usuarios los criterios de calidad del producto. Esta idea establece las bases para medir la calidad del producto reduciendo riesgos.
• La determinación de qué estrategias de apoyo a la confiabilidad del software son usadas para la calidad deseada del producto provee de un medio cuantitativo para optimizar los recursos del proyecto.
• El monitoreo cuantitativo de los resultados de las pruebas y del crecimiento de la confiabilidad permite administrar mejor el proyecto.

La ICS representa una práctica que puede ser usada con resultados positivos. Las micro y pequeñas industrias pueden incorporar dicha práctica dentro de sus procesos no sólo para mejorar la calidad de sus productos sino para sentar las bases que permitan definir el marco de medición de sus procesos en busca de niveles 4 y 5 de CMM-I.

Referencias
1. Musa, J., Iannino, Okumoto; Software Reliability: Measurement, Prediction, Application, ISBN 0-07-044093-X, McGraw-Hill, 1987.
2. User Experiences with Software Reliability Engineering. Available at: http://members.aol.com/JohnDMusa/users.htm
3. Musa, J., Software Reliability Engineering: More Reliable Software Faster and Cheaper, AuthorHouse, 2nd ed., 2004.
4. Lyu, M. (Editor), Handbook of Software Reliability Engineering, ISBN 0-07-039400-8, McGraw-Hill, 1996.