LA CONFIABILIDAD DEL
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 prácticas 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.
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.
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 CONFIABILIDAD DEL SOFTWARE?
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 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.
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.
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 gráfica típica usada para monitorear la reducción de las
intensidades de falla.
