fundamentos de confiabilidad en el desarrollo del software
Post on 28-Nov-2014
12.990 Views
Preview:
DESCRIPTION
TRANSCRIPT
PRIMERA EDICIÓN: 2008
ASOCIACIÓN ESPAÑOLA PARA LA CALIDAD
Claudio Coello 92
28006 Madrid
www.aec.es
publi@aec.es
ISBN: 978-84-691-6898-1
Este librose publica bajo licencia Creative Commons del tipo:“Reconocimiento-NoCormercial-SinObraDerivada”.
Se permite su copia y distribución por cualquier medio siempre que mantenga elreconocimiento de sus autores, no se haga uso comercial de las obras y no realiceninguna modificación de ellas.
La licencia completa puede consultarse en:http://creativecommons.org/licenses/by-nc-nd/2.5/es/legalcode.es
Comité de Confiabilidad - 3 -
PRESENTACIÓN
Esta publicación se enmarca dentro de las actividades que realiza el Comité de Confiabilidad de la
Asociación Española para la Calidad (AEC) en su afán de divulgar los conocimientos de este campo de la
ingeniería.
El concepto de Confiabilidad, entendida ésta como la integración conjunta de las características de
Fiabilidad, Disponibilidad, Mantenibilidad y Seguridad de un dispositivo, es aplicable a cualquier tipo de
componente, equipo, sistema o instalación.
Cada día más, el software constituye un elemento básico en la configuración de los más diversos
dispositivos, siendo primordial en muchos casos. Su papel operativo es relevante en la automoción, la ae-
ronáutica, las instalaciones energéticas y la práctica totalidad de los sectores industriales. Las funciones en-
comendadas al software también son significativas en términos de criticidad: control, optimización,
seguridad, etc.
Sus especiales características requieren que los conceptos generales y los métodos de análisis de
la Ingeniería de Confiabilidad deban adaptarse de forma apropiada con el fin de disponer de un cuerpo
metodológico que sea aplicable eficazmente para el desarrollo de sistemas informáticos confiables.
El profesor Luís Fernández Sanz, especialista en este campo, colaboró con el Comité de Confia-
bilidad de la AEC, impartiendo un tutorial sobre la Calidad del Software en el VIII Congreso de Confiabilidad,
organizado por dicho Comité, que constituyó la base documental para la elaboración de la presente publi-
cación.
A lo largo de esta obra y entre otros aspectos, se analizan los conceptos de defecto, error y fallo
aplicados al software, los atributos que confieren Confiabilidad al mismo, los medios que se deben emplear
para conseguir los niveles adecuados de Confiabilidad, así como el concepto de Calidad del Software y sus
métricas asociadas.
Con el deseo de que esta publicación contribuya, desde la humildad con la que debe plantearse
cualquier acción humana, a ampliar la inacabable senda del conocimiento y desde el agradecimiento al
autor por su meritorio y ejemplar esfuerzo, les presentamos esta publicación.
Siguiendo nuestro deseo de mejora continua, la AEC está interesada en conocer su opinión, comen-
tarios o sugerencias acerca de esta publicación. Para ello, no dude en enviarnos todos sus comentarios a
la siguiente dirección de correo electrónico: publi@aec.es.
Antonio José Fernández Pérez
Presidente del Comité de Confiabilidad
Doctor Ingeniero Industrial
FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN
Comité de Confiabilidad- 4 -
ÍNDICE
1. Introducción 7
1.1 Definiciones sobre amenazas: defectos, errores y fallos 9
1.2 Atributos de la confiabilidad 13
1.3 Peculiaridades del software 17
2. Medios para obtener la confiabilidad del software 17
2.1 Prevención de defectos 17
2.2 Tolerancia de defectos 18
2.3 Eliminación de defectos 20
2.4 Predicción de defectos 23
2.4.1 Modelos de fiabilidad 26
3. Calidad en el desarrollo del software 31
3.1 Mejora en los recursos humanos 32
3.2 Evolución y mejora tecnológica 33
3.3 Mejora de procesos de desarrollo 34
3.4 Mejora de procesos de aseguramiento de calidad de software 36
4. Algunas consideraciones adicionales 53
5. Referencias 55
6. Sobre el autor 59
Comité de Confiabilidad - 5 -
FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN
Comité de Confiabilidad- 6 -
1. INTRODUCCIÓN
El concepto de confiabilidad es habitual en los diversos sectores industriales y también en el ámbito
del diseño y desarrollo de sistemas. Sin embargo, no ha sido tan ampliamente aplicado en una gran parte
del desarrollo de software ya que sólo ciertos sectores que trabajan con sistemas críticos (por ejemplo, el
aeroespacial, el de defensa, el de transporte, etc.) han profundizado en el análisis de la dependability y de
las técnicas específicas para su consecución y evaluación. Desde el punto de vista de la ingeniería del
software se suele integrar cualquiera de las características relacionadas con la “bondad” del producto bajo
el ámbito de la calidad del software. No obstante, el concepto de confiabilidad (dependability) no se ha
establecido como concepto diferenciado en los diccionarios de términos de ingeniería de software o en los
modelos de evaluación de calidad mediante árboles de descomposición de características. Así, el estándar
IEEE Std. 610 [1] no contempla el término dependability. En cuanto a los modelos de calidad estandarizados
como ISO 9126 [2] (y, por supuesto, ISO 14598 [3]) no se opta por la característica de confiabilidad sino
que, como factor de primer nivel, se menciona la fiabilidad (reliability).
En general, se toma como referencia la obra de J.C.Laprie [4] a la hora de definir y establecer los
principios de la confiabilidad en el software. Así, se define confiabilidad como “la propiedad de un sistema
informático que nos permite tener justificadamente confianza sobre el servicio que proporciona”. En el
trabajo de Avizienis et al. [5] se aclara que dicho servicio es el comportamiento del sistema tal como el
usuario lo percibe bien sea una persona, otra aplicación o sistema que interactúa mediante la interfaz.
Se considera que el adjetivo “confiable” abarca varios aspectos:
�Respecto de estar preparado para el uso, significa “disponible” (availability).
�Respecto de continuidad de servicio, significa “fiable” (reliable).
�Respecto de eludir consecuencias catastróficas, significa fuera de peligro (safe)
�Respecto de la prevención de acceso y/o manejo de información no autorizados, significa “seguro”
(secure).
- 7 -Comité de Confiabilidad
FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN
Comité de Confiabilidad- 8 -
En cuanto al desarrollo de sistemas informáticos confiables supone la utilización combinada de un
conjunto de métodos que abarcan:
�Prevención de la ocurrencia o introducción de defectos.
�Tolerancia a fallos o cómo proporcionar el servicio especificado a pesar de los defectos
�Eliminación de defectos o cómo reducir la presencia (gravedad o número) de los mismos.
�Predicción de defectos o cómo estimar el número actual, la incidencia futura y las consecuencias
de los defectos.
En algunos casos, se suele resumir el ámbito de la confiabilidad con el siguiente diagrama de
Avizienis et al. [5] incluyendo algunos detalles más en cuanto a características:
Figura 1. Esquema de definición de la confiabilidad de sistemas informáticos
Comité de Confiabilidad - 9 -
1.1 Definiciones sobre amenazas: defectos, errores y fallos
Para una correcta comprensión de este esquema es fundamental tener claras las definiciones de,
y las posibles diferencias entre, algunos de los conceptos que se incluyen. Así, debemos contar con que el
servicio correcto se proporciona al usuario cuando él mismo implementa las funciones requeridas por el
usuario, es decir, los objetivos de acción del sistema que deben estar recogidos en su especificación.
�Un fallo del sistema es un acontecimiento que ocurre cuando el sistema se desvía del servicio
correcto1. Esta desviación puede producirse por no cumplir la especificación acordada o porque la
especificación no describe correctamente la función requerida por el usuario. En el glosario IEEE
Std. 610 [1] se matiza la definición indicando que el fallo es la “incapacidad de un sistema o
componente para realizar las funciones requeridas dentro de los requisitos de rendimiento
especificados”.
�Error es la parte del estado del sistema que puede causar el correspondiente fallo: el fallo ocurre
cuando el error alcanza la interfaz y altera el servicio. En el glosario del IEEE [1] se define defecto
como “un defecto en un hardware o dispositivo (por ejemplo, un cortocircuito o un cable roto)” o
como “paso, proceso o definición de datos incorrecta en un programa o software”.
�El defecto (fault) es la causa comprobada o hipotética de un error. Un defecto está activo cuando
produce un error; en caso contrario, está aletargado.
También se comenta en el glosario del IEEE [1] la distinción entre acción humana (error como
“meter la pata”2: mistake), su manifestación en el sistema (defecto: fault, defect3), las consecuencias de un
defecto (fallo: failure) y el grado de desviación por el cual el resultado es incorrecto (error: error). Se puede
ver la relación causal entre estos términos en la figura 2.
1 Un fallo se podría considerar como una transición desde un servicio correcto a uno incorrecto. La restauración delservicio (service restoration) es la transición inversa: de incorrecto a correcto. El período intermedio se denominacaída del servicio (service outage).2 Por ejemplo, un programador se equivoca en el diseño de un programa.3 Se utiliza también la palabra bug ya que existe una anécdota situada en uno de los primeros ordenadores en losaños cuarenta/cincuenta donde un insecto es la causa de los fallos aleatorios de funcionamiento al quedar atrapadoen su interior.
FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN
Comité de Confiabilidad- 10 -
A modo de ejemplo, el resultado de un error de un programador lleva a equivocarse en escribir una
instrucción de código o una definición de datos incorrecta. Al activarse (se ejecuta dicha instrucción), el
defecto pasa a estado activo y produce un error; siempre y cuando dicho error afecta al servicio entregado
al usuario (en información o en tiempo de entrega), se produce un fallo del sistema. Por supuesto, este
ejemplo no se restringe a defectos accidentales: un programador puede crear un virus que puede
permanecer dormido hasta que se active (por ejemplo, en cierta fecha) y producir un error que suponga un
desbordamiento de memoria y, como consecuencia, la entrega del servicio sufra lo que se llama un fallo
de denegación de servicio (denial-of-service).
Por supuesto también se puede representar el mecanismo de propagación de los errores a lo largo
de un sistema ya que el error producido en un componente puede suponer un fallo de servicio hacia otro
componente que recibía resultados del primero. El fallo del sistema se producirá cuando esta cadena
alcance la interfaz de servicio del sistema y el usuario (humano u otro sistema) reciba un servicio incorrecto
(ver figura 3).
Figura 2. Cadena causal que relaciona error, defecto y fallo
Comité de Confiabilidad - 11 -
Desde el punto de vista de los fallos, existen distintas clasificaciones que ayudan a analizar y
catalogar los datos sobre los mismos. Así, en la publicación de Avizienis et al. [5] se habla de modos de fallo
donde las tres vistas principales son (ver fig. 4):
�El dominio
�La percepción por parte de los usuarios
�Las consecuencias en el entorno
Figura 3. Propagación de errores a través del sistema
Figura 4. Esquema de clasificación de fallos
FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN
Comité de Confiabilidad- 12 -
Sin embargo, existen clasificaciones más complejas como la recogida en el estándar IEEE Std.
1044 [6] [7], centrada en el registro de anomalías de software: siguiendo la terminología ya presentada, los
errores o manifestaciones de desviaciones de lo especificado o requerido. En este caso, se sugiere tratar
con los siguientes datos4:
�Actividad del proyecto que lo detectó
�Fase del proyecto en la que se detectó
�Causa sospechada
�Repetibilidad: una vez, intermitente, recurrente, reproducible, desconocida
�Síntoma
�Estado del producto: no utilizable, degradado, afectado, no afectado
En cuanto a los defectos, también se proponen categorías para la clasificación elemental de los
mismos como causas de fallos tanto en dos trabajos de Avizienis et al. [5] [9].
Figura 5. Esquema de clasificación de defectos
Comité de Confiabilidad - 13 -
1.2 Atributos de la confiabilidad
Por otra parte, es importante contrastar la definición de los atributos explicativos de la confiabilidad
(ver figura 1) y situarlos dentro del contexto general de la calidad del software. Desde este punto de vista,
los atributos asignados a la confiabilidad cuentan con las siguientes relaciones con los modelos generales
de evaluación de calidad del software
�Disponibilidad
~Integración en modelos: no es mencionado como atributo de ningún nivel, ni en ISO
9126 [2] ni en el modelo de McCall et al. [8].
~Definición: en la referencia de Avizienis et al. [5] se define como la preparación para
proporcionar el servicio correcto.
�Fiabilidad
~Integración en modelos: se trata de un factor de primer nivel de descomposición tanto
en ISO [2] como en el modelo de McCall [8]. En ISO 9126 cuenta con los siguientes
subatributos: madurez (capacidad para evitar fallos), tolerancia a defectos (mantener
prestaciones en caso de fallo o de violar el uso especificado de sus interfaces) y capacidad
de recuperación (restablecer nivel de prestaciones y recuperar datos afectados).
~Definición: Avizienis [5] la define como continuidad del servicio correcto. En ISO [2] se
identifica con un conjunto de atributos que soportan la capacidad del software para
mantener su nivel de rendimiento en las condiciones especificadas durante un período
fijado de tiempo.
�Protección5 (safeness)
~Integración en modelos: no es mencionado como atributo de ningún nivel, en ISO [2]
ni en el modelo de McCall et al. [8].
~Definición: en el trabajo de Avizienis [5] se define como la ausencia de consecuencias
catastróficas para el usuario o el entorno.
5 Se opta por el término protección para safeness para distinguir mejor con la seguridad (security) siguiendo reco-mendaciones ya existentes de traducción al español.
FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN
Comité de Confiabilidad- 14 -
�Confidencialidad
~Integración en modelos: en el modelo de ISO [2] se menciona la seguridad de acceso
como subatributo del factor funcionalidad de primer nivel refiriéndose a la protección de
información de tal forma que usuarios o sistemas no autorizados no accedan a ella ni
tampoco accedan al uso del sistema. En el de MCCall [8] se menciona el término integrity
precisamente como control de acceso a la información.
~Definición: Avizienis [5] la define como la ausencia de revelación no autorizada de
información.
�Integridad
~Integración en modelos: no es mencionado como atributo de ningún nivel en, ISO [2]
pero sí aparece en el modelo de McCall [8] como factor de primer nivel con los subatributos
de control de accesos y facilidad para la auditoría.
~Definición: en el trabajo de Avizienis [5] se define como la ausencia de alteraciones
inadecuadas del estado del sistema, lo que supone un concepto claramente diferente al
recogido en el de McCall [8]: control de acceso al software o datos por personas no
autorizadas (más afín al de confidencialidad).
�Facilidad de mantenimiento
~Integración en modelos: es un factor de primer nivel en el modelo de ISO [2] donde
incluye como subatributos la facilidad para ser analizado, la facilidad de prueba, la
estabilidad y la facilidad de modificación. En el de McCall [8] también es un factor de primer
nivel con los subatributos de consistencia (en diseño e implementación), simplicidad
(facilidad de comprensión), concisión (minimización de código), modularidad
(independencia de componentes) y autodescripción (autodocumentación de la
implementación).
~Definición: para Avizienis [5] se define como la capacidad de realizar reparaciones y
modificaciones, lo que es similar a los indicadores en ISO [2] y en el de McCall [8].
Comité de Confiabilidad - 15 -
Por otra parte, hay que recordar que, en general, los distintos atributos de calidad de software no
son independientes. Existen, de hecho, relaciones de sinergia y de antagonismo entre ellos. Este hecho se
documentó ya en [8] identificando relaciones entre los distintos factores de la calidad (ver fig. 6). Como
ejemplo podemos apreciar que si pretendemos incrementar mucho la portabilidad debemos esperar que la
eficiencia sufra mientras que una mejora en facilidad de prueba contribuirá a la fiabilidad del software.
Además, en el caso de la confiabilidad, puede considerarse que la integridad es un prerrequisito
para otros atributos como la disponibilidad, la fiabilidad o la seguridad pero quizás no lo sea para la
confidencialidad toda vez que puede haber ataques mediante canales encubiertos o mediante escucha
pasiva.
Por tanto, es importante recordar que los proyectos de desarrollo no deben buscar un objetivo
absoluto de excelencia en todos los atributos de calidad. La idea es personalizar los niveles requeridos en
cada caso a las necesidades del usuario, normalmente en función del tipo de proyecto y de los posibles
Figura 6. Sinergia y antagonismo entre factores de calidad en el modelo de Mc Call et al.
FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN
Comité de Confiabilidad- 16 -
riesgos. Este acuerdo de requisitos debe documentarse claramente como parte de la especificación del
software desde el inicio del proyecto con la validación del cliente y/o usuario. En el caso de la confiabilidad,
se sugiere en la propuesta de Avizienis [5] que la disponibilidad debe estar siempre presente, aunque podría
haber matices, mientras que el resto de atributos podrían ser esenciales o, por el contrario, no necesarios
en determinados proyectos. Además, resulta especialmente conflictivo hablar de niveles absolutos de
confiabilidad debido a que no existe la total ausencia de defectos6.
En el caso del término seguridad (security), en el trabajo de Avizienis [5] se vincula a la agrupación
de disponibilidad sólo para usuarios autorizados, a la confidencialidad y a la integridad ante accesos no
autorizados. En resumen, la seguridad significa la ausencia de accesos no autorizados al, o el manejo del
estado del sistema. En las definiciones, la seguridad y la protección enfatizan la capacidad para evitar una
clase específica de fallos (catastróficos o acceso no autorizado) mientras que la disponibilidad y la fiabilidad
se centran más en evitar fallos en general. Por ello, hay tendencia a agrupar estas dos últimas
características y definirlas colectivamente como la evitación o minimización de las caídas de servicio.
Existen otros términos afines al de confiabilidad y que habitualmente han sido contemplados en el
ámbito del desarrollo de software y sistemas informáticos, especialmente por la importancia otorgada a la
protección ante todo tipo de amenazas en la protección de infraestructuras complejas controladas por
sistemas de información empotrados. Por una parte, hacemos referencia a términos como la capacidad
para proporcionar confianza7 (trustworthiness) y capacidad de supervivencia (survivability). Como se indica
en la referencia de Avizienis [5], el primero omite explícitamente los defectos internos aunque los considera
implícitamente. También dichos defectos son contemplados implícitamente en la capacidad de
supervivencia mediante los fallos de componentes. El término de capacidad de supervivencia fue acuñado
en ámbitos militares en la década de los sesenta del siglo XX para definir la capacidad del sistema para
resistir entornos hostiles manteniendo el cumplimiento de sus objetivos de servicio. Por tanto, se incluye
en ambos términos explícitamente las amenazas que tratan a diferencia de lo que ocurre con la
confiabilidad.
6 Se suele comentar que los costes de la calidad siguen esta ecuación: coste = 1/defectos de tal manera que preten-der cero defectos supone costes inmanejables. Suele trabajarse más bien con la búsqueda del nivel de riesgo acep-table equilibrándolo con los recursos y plazos disponibles.7 La capacidad para proporcionar confianza es muy similar, a efectos de traducción al español, al término de confia-bilidad.
Comité de Confiabilidad - 17 -
Por otra parte, es habitual el término RAMS (Reliability, Availability, Maintainability and Safety), por
ejemplo, en el ámbito de software crítico en la Agencia Europea del Espacio (ESA). En el caso de la ESA
[10], el propio término de confiabilidad se contempla con una definición más restringida que la de la
confiabilidad (limitada a la fiabilidad, disponibilidad y facilidad de mantenimiento) mientras que la protección
(safety) se considera aparte.
1.3 Peculiaridades del software
Una de las dificultades para aplicar las técnicas de confiabilidad y de calidad, en general, al software
es la peculiar naturaleza del software respecto de otros productos industriales. Esto dificulta el
aprovechamiento de las experiencias que otros sectores productivos han podido desarrollar desde hace
muchos años ya que la aplicación al desarrollo de software no es directa y requiere cuidadosas
adaptaciones (incluso, en algunos casos, no es posible dicha adaptación, lo que lleva a desechar ciertas
técnicas).
Las peculiaridades del software se pueden resumir así según Pressman [11]:
�Se desarrolla, no se fabrica en el sentido clásico del término. Todo el coste de su producción se
centra en el diseño de la primera copia, ya que la replicación de un programa es una tarea trivial.
�Se trata de un producto lógico, sin existencia física. El verdadero producto del software es el
diseño de una serie de instrucciones para el ordenador. Su existencia en papel (listado) o en soporte
magnético (fichero) no es más que una representación en un código o lenguaje de su auténtica
naturaleza, las instrucciones. De hecho, está protegido por leyes de propiedad intelectual al igual
que la música o las obras escritas.
�No se degrada o desgasta con el uso. La naturaleza lógica del software permite que permanezca
inalterable por muy intensa que sea su utilización. Se puede degradar su representación magnética
pero no su esencia. Por ello, la reparación no consiste en devolverlo al estado original en el que
estaba cuando se entregó (como un automóvil cuando sale de fábrica). Si hay que repararlo, eso
significa que ya contaba con algún defecto en origen por lo que una corrección significa rectificar
el diseño.
�La complejidad del software, la ausencia de controles adecuados y el mercado actual lleva a que
sea un producto que muchas veces se entrega conscientemente con defectos, incluso públicamente
declarados (p. ej., la lista de errores conocidos de ciertos paquetes informáticos). Eso es algo
inaceptable en el resto de sectores productivos (p. ej., no se entrega una lista de defectos conocidos
cuando se compra una nevera o un televisor). En el sector informático, incluso, se llega a cobrar una
cuota de mantenimiento para reparar los defectos que el propio productor del software ha entregado
con el mismo.
�Un porcentaje muy grande de la producción se hace aún a medida, en vez de emplear
componentes existentes y ensamblarlos, aunque las bibliotecas de funciones o componentes están
ya cambiando en parte esta situación.
�Es extraordinariamente flexible. Se puede cambiar con facilidad e, incluso, se pueden reutilizar
trozos de un producto para construir otro. Sin embargo, la facilidad para cambiarlo (basta con un
editor para alterar el código donde una simple coma es suficiente para alterar enormemente un
programas) es también un peligro que hay que controlar.
No obstante, como se comenta en la referencia de Pressman [11] en relación a la aplicación de
modelos probabilísticos para el software, como se ha indicado en uno de los puntos anteriores, el hardware
se desgasta pero el software no; esto es una media verdad ya que la ejecución del software es ciertamente
determinística pero su desarrollo es probabilístico y permanecen muchos tipos de errores residuales. Por
otra parte, sólo una pequeña parte de los fallos en hardware se deben al desgaste ya que se identifican
hasta cuatro tipos de modos de fallo: mala calidad de fabricación, errores de diseño, sobrecarga de
componentes y desgaste o edad. Los tres primeros son comunes con el software.
FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN
Comité de Confiabilidad- 18 -
El desarrollo de software confiable supone la utilización combinada de un conjunto de 4 tipos de
acciones distintas:
�Prevención de la introducción u ocurrencia de defectos.
�Tolerancia a defectos para entregar el servicio correcto a pesar de su presencia.
�Eliminación de defectos para reducir su número o gravedad.
�Predicción de defectos, estimando el número actual, la incidencia futura y las consecuencias
probables de los mismos.
A continuación abordaremos cada una de estas áreas de actividad.
2.1 Prevención de defectos
Este aspecto de la confiabilidad se basa en la utilización de los mejores medios y controles durante
el desarrollo de software para prevenir la introducción de defectos. Dada la amplitud de esta disciplina de
ingeniería de software resumiremos en el apartado 3 los principales medios de actuación.
Por otra parte, para prevenir otro tipo de defectos como los físicos de operación se utiliza el blindaje,
protección contra radiaciones, etc. mientras que los defectos de interacción se previenen mediante
entrenamiento, procedimientos de operación rigurosos, paquetes “infalibles”, elementos de guía y ayuda,
etc. Los defectos maliciosos se previenen mediante mecanismos de protección como cortafuegos y
defensas similares.
2. MEDIOS PARA OBTENER LA
CONFIABILIDAD DEL SOFTWARE
- 19 -Comité de Confiabilidad
2.2 Tolerancia de defectos
El término (fault tolerance) está inspirado en la preservación del servicio correcto ante la presencia
de defectos activos. Suele basarse en la detección de errores y la correspondiente recuperación del servicio.
En general, la detección de defectos se centra en dos tipos de técnicas según Avizienis [5]:
�Detección concurrente que se produce a la vez que se realiza la entrega del servicio.
�Detección preventiva que se realiza mientras el servicio está suspendido tratando de
comprobar errores latentes y defectos dormidos.
La recuperación transforma el estado del sistema que contiene uno o más errores y, posiblemente,
defectos en un estado sin errores o defectos detectados que se pueden activar de nuevo. Para ello, hay
que incluir el manejo de errores y de defectos para eliminar los errores del sistema. El manejo de errores
puede centrarse, según Avizienis [5], en:
�La vuelta atrás (rollback), donde se retorna a un estado (checkpoint) guardado que es previo a
la detección del error. Esta operación suele recaer en el área de explotación y no suele implicar
trabajo de desarrollo o mantenimiento de software. Distintas herramientas y tecnologías facilitan
el registro de estados del sistema para realizar cambios reversibles para el mismo.
�El avance donde el estado sin errores detectados es un estado nuevo. Suele entonces
conectarse con el manejo de defectos.
El manejo de defectos pretende prevenir la activación de defectos localizados. Para ello suele
apoyarse en las siguientes fases:
�Diagnóstico, que identifica y registra la/s causa/s de error/es tanto en localización como en tipo.
�Aislamiento del defecto, que supone la exclusión física o lógica de los componentes
defectuosos para evitar que participen en la entrega del servicio (es decir, dejar los defectos
dormidos).
�Reconfiguración del sistema, que cambia a componentes de repuesto, o sustitución, o reasigna
tareas entre los componentes no defectuosos.
�Reinicialización del sistema, que comprueba, actualiza y registra la nueva configuración y las
nuevas tablas y registros.
Comité de Confiabilidad
FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN
- 20 -
Lo normal es que al manejo de defectos le siga un proceso de depuración o mantenimiento
correctivo8, pero el factor que distingue la tolerancia a defectos del mantenimiento es que éste requiere la
intervención de un agente externo.
Una opción adicional es el enmascaramiento de defectos que permite la recuperación del sistema
sin una detección explícita de errores. Así, una detección preventiva de errores (BIST: built-in self-test) será
posiblemente seguida del manejo de defectos ejecutado al iniciarse el sistema. También de spare checking,
recogida de basura, programas de auditoría o el llamado rejuvenecimiento de software, que pretende
eliminar efectos de la edad en las aplicaciones antes de que puedan llevar a fallos.
Elegir técnicas de detección de errores, manejo de errores o manejo de defectos depende del
criterio adoptado durante el diseño para las clases de defectos tolerables. Un método habitualmente
empleado para la tolerancia a defectos es ejecutar varias veces los mismos cálculos en distintos entornos
(en general con idéntico diseño), de forma secuencial o concurrente, en general. Este enfoque es adecuado
para defectos de diseño esquivos mediante rollback, pero no lo es para los defectos de diseño sólidos que
requieren entornos que implementen la misma función con diseños e implementaciones distintos: es lo que
se llama diversidad de diseño (design diversity). Como ejemplos de diversidad de diseño se pueden
mencionar el diseño independiente de componentes o la multiplicidad de versiones, entre otros. La
diversidad en el diseño es uno de los elementos propuestos por Randell [13] para la tolerancia a defectos
junto con los bloques de recuperación, la prevención del efecto onda (ripple-efect), el manejo de
excepciones integrado en lenguajes (catch-throw de C++, try de Java, etc.), el enfoque de sistemas
distribuidos, la reflexión (reflection) de los lenguajes, el uso de la delegación, etc.
Sin embargo, como se comenta en el clásico libro de Fenton y Pfleeger [14], existen algunos
problemas en esta filosofía. La utilización de la implementación del sistema con varios diseños
independientes pretende disminuir la probabilidad de que todas las versiones fallen al mismo tiempo y se
ha aplicado a casos como el del Airbus A320. No obstante, diversos experimentos con 27 versiones
Comité de Confiabilidad - 21 -
8 Este proceso también debe darse durante el desarrollo de software cuando las pruebas detectan defectos en losproductos. El término depuración (debugging) suele aplicarse más bien a la corrección de código.
independientes de un software han revelado una alta proporción de defectos comunes por lo que la técnica
de diversidad de diseño no aporta confianza en entornos de ultra-alta fiabilidad.
La tolerancia a defectos es un concepto recursivo: los mecanismos que protegen el sistema deben
estar así mismo protegidos de defectos. Por ejemplo, mediante replicación, comprobadores con
autochequeo, memoria estable para recuperar datos y programas, etc.). En el caso del autochequeo,
Fenton [14] resalta la limitación de este tipo de controles a un estrecho campo de problemas de tipo
matemático. También se menciona la influencia del incremento de la facilidad de prueba como medio de
mejora de la fiabilidad. Tiene el inconveniente de que las aplicaciones tienen mayor probabilidad de estar
libres de defectos pero se incrementa la probabilidad de ocurrencia de fallos si los defectos permanecen.
La introducción sistemática de la tolerancia a defectos se facilita con aplicaciones supervisoras del
software, procesadores de servicios, comunicación dedicada, etc. Por supuesto la tolerancia a defectos no
debe centrarse exclusivamente en los defectos accidentales sino que es de aplicación para proteger de
intrusiones o ataques maliciosos mediante la fragmentación y la dispersión de información, y la tolerancia
a lógica malintencionada (virus, etc.) mediante comprobación del flujo de control o mediante diversidad de
diseño.
2.3 Eliminación de defectos
La eliminación se puede producir durante el desarrollo de software o durante la explotación. Se
define en el glosario de IEEE [1] la depuración como “el proceso de detectar, localizar y corregir defectos”.
De las tres fases señaladas, la localización del defecto o diagnóstico consume la mayor parte (seguramente
un 80%) del esfuerzo necesario para el proceso de depuración. En cuanto a la detección, suele apoyarse
en los conceptos de verificación y validación que se tratarán en detalle en el apartado 3 sobre prevención
en el desarrollo de software:
�Verificación: proceso de evaluar un sistema o componente para determinar si los productos de
una fase de desarrollo cumplen los requisitos impuesto al inicio de la misma.
�Validación: proceso de evaluar un sistema o componente durante el desarrollo, o al final del
mismo, para determinar si satisface los requisitos especificados.
FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN
Comité de Confiabilidad- 22 -
Comité de Confiabilidad
Boehm resumió estas definiciones con las expresiones “¿construimos correctamente el producto
software?” o “¿construimos el producto software correcto?”. Insistiremos más en el apartado 3 sobre el
papel de estas actividades (resumidas habitualmente como V&V) en la prevención de defectos durante el
desarrollo de software.
En cuanto al proceso de depuración puede surgir mediante la detección de defectos por resultados
de aplicación de las distintas técnicas de verificación y/o validación9, o por informes de explotación, clientes,
etc. Durante el desarrollo es habitual la conexión entre depuración y pruebas cuando los defectos se refieren
a la implementación de código (ver fig. 7) como se indica en la referencia de Piattini et al. [15]. Los casos
de prueba diseñados para comprobar el software se ejecutan en el ordenador y se obtienen resultados.
Dichos resultados se analizan para la búsqueda de síntomas de defectos (errores) en el software. Esta
información se pasa al proceso de depuración para obtener las causas del error (defecto). En caso de
conseguirlo, se corrige el defecto; en caso contrario se llevarán a cabo nuevas pruebas que ayuden a
localizarlo, reduciendo en cada pasada el posible dominio de existencia del defecto. Tras corregir el defecto,
se efectuarán nuevas pruebas que comprueben si se ha eliminado dicho problema.
- 23 -
9 Como se verá en el apartado suelen ser básicamente las pruebas y las revisiones y auditorias aunque existen otrasen el amplio catálogo de técnica de V&V.
Figura 7. Ciclo de pruebas y depuración
La depuración no es un proceso trivial y deben contemplarse algunas recomendaciones para
obtener los mejores resultados. En el caso del diagnóstico y localización del defecto, se pueden indicar los
siguientes consejos de Myers [16]:
�Analizar la información y pensar. La depuración es un proceso mental de resolución de un
problema y lo mejor para el mismo es el análisis. No se debe utilizar un enfoque aleatorio en la
búsqueda del defecto.
�Al llegar a un punto muerto, pasar a otra cosa. Si tras un tiempo razonable no se consiguen
resultados, merece la pena refrescar la mente, para empezar de nuevo o para que el inconsciente
nos proporcione la solución.
�Al llegar a un punto muerto, describir el problema a otra persona. El simple hecho de describir a
otro el problema nos descubre muchas cosas (“cuando todo falle, pedir ayuda”).
�Usar herramientas de depuración (depuradores, trazadores de ejecución, etc.) sólo como recurso
secundario. Deben ayudar al análisis mental, no pueden pretender sustituirlo, por lo menos, en la
actualidad.
�No experimentar cambiando el programa. Evitar depurar con esta actitud inadecuada, que se
puede resumir como: “No sé qué está mal, así que cambiaré este bucle y veré qué pasa”.
�Se deben atacar los errores individualmente, de uno en uno, si no se quiere dificultar aún más la
depuración.
�Se debe fijar la atención también en los datos manejados en el programa y no sólo en la lógica
del proceso.
En cuanto a la fase de corrección, Myers sugiere lo siguiente [16]:
�Donde hay un defecto, suele haber más. Es una conclusión obtenida de la experiencia. Cuando
se corrige un defecto se debe examinar su proximidad inmediata buscando elementos sospechosos.
�Debe fijarse el defecto, no sus síntomas. Lo que debe corregirse y desaparecer es el defecto, no
se trata de intentar enmascarar sus síntomas.
�La probabilidad de corregir perfectamente un defecto no es del 100%. Por lo tanto, se deben
revisar las correcciones antes de implantarlas (mediante técnicas de revisión: walkthroughs,
FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN
Comité de Confiabilidad- 24 -
Comité de Confiabilidad
inspecciones, revisiones, etc. antes de la corrección). Después de la corrección, se utilizan pruebas
específicas de regresión.
�Cuidado con crear nuevos defectos. Es frecuente crear nuevos defectos al corregir sin cautela.
La probabilidad de que un cambio se realice correctamente es del 50% (aproximadamente) según
algunos estudios.
�La corrección debe situarnos temporalmente en la fase de diseño. Hay que mentalizarse de que
se reinicia el diseño de la sección de código defectuoso y no sólo se retoca el código.
�Cambiar el código fuente, no el código objeto. Cambiar el código objeto provoca:
~Experimentación indeseable.
~Falta de sincronización fuente-objeto.
2.4 Predicción de defectos
La predicción de defectos se realiza mediante la evaluación del comportamiento del sistema en
cuanto a ocurrencia o activación de defectos. Se plantea bajo dos aspectos según Avizienis [5]:
�Evaluación cualitativa u ordinal que pretende identificar, clasificar y ordenar los modos de fallo o
las combinaciones de eventos (fallos de componentes o condiciones de entorno) que podrían llevar
a fallos del sistema.
�Evaluación cuantitativa o probabilística que pretende evaluar en términos de probabilidades la
extensión en que se satisfacen los atributos de confiabilidad; dichos atributos pueden verse como
medidas de confiabilidad.
Los métodos de evaluación para ambos aspectos pueden ser específicos (por ejemplo, modo de
fallo o análisis de efectos para evaluación cualitativa o cadenas de Markov y Redes de Petri estocásticas
para evaluación cuantitativa) o pueden ser indiferentemente usados para ambos tipos de evaluación (por
ejemplo, diagramas de bloques de fiabilidad, árboles de defectos).
La evolución de la confiabilidad en el ciclo de vida se basa en los conceptos de estabilidad,
crecimiento y decrecimiento que pueden plantearse para los diversos atributos independientemente. Así,
- 25 -
se considera la intensidad de fallos (es decir, el número de fallos por unidad de tiempo) como medida de
la frecuencia de fallos según la percibe el usuario. Típicamente esta intensidad decrece (crecimiento de
fiabilidad), luego se estabiliza y después de un cierto tiempo de operación se incrementa para,
posteriormente, iniciar un nuevo ciclo.
La alternativa de entrega de servicio correcto-incorrecto se cuantifica para definir la fiabilidad, la
disponibilidad y la facilidad de mantenimiento como medidas de confiabilidad. Así, se habla de fiabilidad
en términos de medida del servicio continuo correcto o su equivalente en tiempo hasta el fallo. En este
sentido, suele trabajarse con el MTTF (Mean Time To Failure). En cuanto a disponibilidad, se mide la
entrega de servicio correcto respecto de la alternativa de servicio correcto e incorrecto. En el libro de
Pressman [12] se formaliza de la siguiente manera:
Tup representa el tiempo en que el sistema entrega el servicio correcto y Tdown es el tiempo en que el
servicio “esta caído”. Ambos corresponderán con el total de tiempos observados de cada clase:
La disponibilidad es una función del tiempo y se asume que es 1 en t0, decreciendo
posteriormente hasta un estado estable después de varios ciclos fallo-reparación. De hecho, la teoría de
fiabilidad y confiabilidad suele centrarse en el estudio de estado estable aunque también se analiza el
período inicial (burn-in).
Desde este punto de vista, se puede considerar la disponibilidad de dos maneras:
�Ratio de sistema con entrega de servicio correcto en un instante respecto de la población
estudiada.
�Ratio de uptime (entrega de servicio correcto) respecto de la suma de tiempos up y down (fórmula
anterior).
FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN
Comité de Confiabilidad- 26 -
Comité de Confiabilidad
En el primer caso, se formula la disponibilidad de la siguiente manera:
donde MTTF es el Mean Time to Failure (que equivale al Tup) y el MTTR el Mean Time To Repair (que
equivale al Tdown), por lo que el MTBF es el Mean Time Between Failures. Ambos tiempos deben estimarse
por distintos medios para el estado estable. En algunas ocasiones se sugiere una manera simplificada
como la siguiente:
donde n es la muestra, T es el tiempo total acumulado y K es el número de fallos. Sin embargo, veremos
más adelante los modelos de fiabilidad más adaptados a la problemática del software que podrán facilitar
estas estimaciones.
En cuanto a la facilidad de mantenimiento, se aplica la medición del tiempo hasta la restauración
del servicio (normalmente indicado como MTTR: Mean Time To Repair) o su equivalente de medida de
servicio incorrecto continuo.
El caso de la protección (safety) se considera una extensión de la fiabilidad según la referencia de
Avizienis [5]. Así mismo, cuando el estado del servicio correcto y los estados de servicio incorrecto debido
a fallos no catastróficos se agrupan en un estado seguro (en el sentido de estar libre de daños catastróficos
no de peligro), se mide la protección como protección continua o con su equivalente en tiempo de fallo
catastrófico. Por eso, la protección es la fiabilidad respecto de los fallos catastróficos.
En general, un sistema entrega diversos servicios y se contemplan dos o más modos de calidad
de servicio, por ejemplo, desde capacidad total a servicio de emergencia. Por ello, las medidas relacionadas
con la confiabilidad deben integrarse con la noción de capacidad de rendimiento (performability). Existen
dos enfoque principales para la predicción probabilística de defectos (que pretende derivar estimación en
términos de probabilidad de las medidas de confiabilidad), según el trabajo de Avizienis [5]:
�Modelado
�Prueba y evaluación
- 27 -
Estos enfoques son complementarios, ya que el modelado requiere datos de los procesos básicos
modelados (proceso de fallo, proceso de mantenimiento, proceso de activación, etc.) que pueden obtenerse
mediante procesos de pruebas o procesando datos de fallos. En el siguiente apartado comentaremos
algunos modelos relacionados con la fiabilidad y disponibilidad. Evidentemente, los resultados de pruebas
son elementos muy valiosos para la predicción de fiabilidad mediante los correspondientes informes de
incidentes durante las mismas. Durante el mantenimiento, los informes de peticiones de mantenimiento
son la fuente de estos modelos. Ambos deberían converger en un sistema integrado de seguimiento de
defectos (defect-tracking) que suele enlazarse con la gestión de cambios y configuraciones; de hecho, en
organizaciones donde la gestión de configuración ya controla los cambios realizados, la estadística de
defectos se gestiona mediante estos mecanismos de control.
Cuando se evalúan sistemas tolerantes a defectos, la cobertura proporcionada por los mecanismos
de manejo de errores y defectos tiene una drástica influencia sobre las medidas de confiabilidad. La
evaluación de la cobertura se realizará a través de modelado o a través de pruebas, es decir, inserción de
defectos (fault-injection). Esta técnica se basa en analizar los efectos de defectos insertados en el sistema
a través de un modelo de simulación o un prototipo implementado [17].
2.4.1 Modelos de fiabilidad
Para aportar una panorámica rápida de los modelos relacionados con la fiabilidad del software,
debemos comenzar aclarando que el uso de los mismos siempre pasará por dos fases según Fenton [14]:
1. Selección del modelo más apropiado ajustándolo si hace falta.
2. Estimación de los valores de los parámetros necesarios usando los valores más probables de datos
disponibles.
El modelo más sencillo, y uno de los primeros, para software es el Jelinski-Moranda [17]. En este
modelo se asume que la distribución de probabilidad de fiabilidad es:
donde N es el número inicial de defectos y f es la contribución de cada defecto a la tasa global de
defectos.
FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN
Comité de Confiabilidad- 28 -
Comité de Confiabilidad
Las principales limitaciones del modelo surgen de los siguientes 3 hechos según Fenton [14]:
1. La secuencia de tasas es puramente determinista.
2. Todos los defectos contribuyen por igual a la tasa de riesgo. En el caso del software se ha
comprobado que esto no es así (ver apartado 3).
3. Tiene poca precisión con valores que suelen ser normalmente optimistas.
Otros modelos han pretendido refinar éste como el de Shooman [12] y el de Musa [19]. Éste último
aporta como novedad el centrarse en el tiempo de ejecución, aunque incluye también tiempo de calendario
para conectar con la gestión de proyecto.
Sin embargo, los modelos más ajustados suelen incluir un aspecto doblemente estocástico ya que
también consideran que la contribución de cada defecto es distinta. Los defectos que más contribuyen a la
falta de fiabilidad se encuentran y eliminan antes que los que pueden quedar dormidos mucho tiempo. Es
el caso de los modelos de Littlewood [20] y [21] en los que los pasos (tiempos entre incidentes) son de
distintos tamaños, a diferencia de lo que ocurría en el de Jelinski-Moranda.
Como se indica en el trabajo de Fenton y Pfleeger [14], como sólo se mide en función de los fallos,
es imposible medir la fiabilidad antes de terminar el desarrollo (de hecho, no es posible hasta llegar a
pruebas del sistema integrado, ya que pruebas parciales de componentes no pueden ser significativas para
este aspecto). No obstante, si recogemos con cuidado los tiempos entre fallos, existen medios para predecir
con cierta precisión la fiabilidad. Los modelos de crecimiento de fiabilidad presentados ayudan a esta labor,
pero ninguno de ellos es preciso con todos los conjuntos de datos en todos los entornos (no hay una
panacea para este trabajo). Por ello, suele ser necesario recalibrarlos con datos propios y, por otra parte,
existen herramientas automáticas que facilitan mucho los arduos cálculos que suponen los ajustes y la
aplicación de los modelos.
En cualquier caso, hay que recordar que, como indica Fenton [14], sólo funcionan correctamente
si el entorno futuro de operación es similar al que se usa para recoger datos de fallos. Por ello, antes de
entregar debemos simular convenientemente dicho entorno. Uno de los enfoques que contemplan esta
filosofía es el de Cleanroom Method para desarrollo de software presentado por Dyer [22], donde se incluye
- 29 -
una estrategia de pruebas estadísticas basadas en seleccionar casos de pruebas en función de la
probabilidad de uso de las funciones, como indica Linger [23].
De todas maneras, los casos de ultra-alta fiabilidad plantean graves problemas, ya que un requisito
como el impuesto al A320 para tasa de fallos de 10-9 supone hablar de 100.000 años de operación y no
podremos ejecutar el sistema y observar los tiempos de fallo para medir la fiabilidad. El incremento de
tiempo para alcanzar los distintos niveles de fiabilidad crece de manera exponencial por lo que debe
imponerse un esquema de objetivos viable y proporcionado a los riesgos y los costes asumibles tanto para
el fabricante como para el cliente en invertir más por más fiabilidad (ver figuras 8.a y 8.b).
FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN
Comité de Confiabilidad- 30 -
Figura 8.a Curso de coste y fiabilidad para el fabricante
Comité de Confiabilidad - 31 -
Figura 8.a Curso de coste y fiabilidad para el fabricante
Ciertamente la actividad de desarrollar software y sistemas difiere bastante de la fabricación de
otros productos. Además de las diferencias intrínsecas entre el software y otros productos (ver apartado 1.3)
también la manera de trabajar ha sido tradicionalmente distinta de los procesos más tradicionales de
fabricación como se explica en el IEEE [6]. Esta es la causa de que los métodos y técnicas aplicables para
la mejora de calidad en el software, no hayan podido resolverse con una inmediata traslación de las
prácticas maduras existentes en otros sectores de fabricación. El resultado ha sido la necesidad de realizar
un gran esfuerzo en la adaptación fiable de dichas técnicas a la realidad del software así como la creación
de modelos y métodos específicos para la actividad de desarrollo.
En general, la gestión de proyectos de desarrollo debería tener en cuenta los principales factores
que influyen en los mismos. Tomando como referencia a Jones [24], podemos asumir como base el modelo
de la figura 9.
- 33 -
3. CALIDAD EN EL DESARROLLO
DEL SOFTWARE
Comité de Confiabilidad
Figura 9. Factores que afectan a la calidad y la productividad en el software segun [24]
Las líneas actuales de trabajo para la mejora de la calidad y prevención de defectos en el software
y los sistemas podrían clasificarse de acuerdo a su focalización principal en alguno de los elementos del
modelo anterior. Podemos presentar las principales líneas actuales en mejora de la calidad del software en
función del análisis de los diferentes factores anteriores distinguiendo en los procesos aquellos destinados
al desarrollo en sí y los destinados al aseguramiento de calidad.
3.1 Mejora en los recursos humanos
Es evidente que el principal recurso y el que marca el principal coste de un desarrollo es el factor
humano. En este sentido, podríamos hablar de:
�La formación académica y los estudios de preparación profesional: el autor ha realizado estudios
detallados de los requisitos exigidos en ofertas de empleo donde se puede constatar la evolución
de conocimientos técnicos y, sobre todo, la necesidad de competencias personales básicas (trabajo
en equipo, comunicación, etc.).
�La cualificación específica en entornos, lenguajes, tipo de aplicaciones, etc. en buena parte ligada
a la experiencia en cada ámbito.
�El despliegue de buenas prácticas personales de desarrollo a través de métodos como PSP
presentado por Humphrey [26] pueden influir en la productividad y la calidad.
�La motivación y la cultura de calidad, el amor por el trabajo bien hecho, etc. que, también, suelen
ser dependientes de una actitud respetuosa con una ética profesional como la marcada en el código
de IEEE [27].
Existen análisis sofisticados de las relaciones entre los diversos factores que pueden influir en un
desarrollo, así como el esfuerzo y los resultados que se pueden obtener en los mismos. Un típico ejemplo
es el de Abdel-Hamid y su dinámica de proyectos [28]. Otro conjunto interesante de datos de influencia
relacionados con el personal de desarrollo de software son los proporcionados por Jones [24]. En la tabla
2, se puede apreciar la influencia de distintos factores clave tanto cuando son positivos (por ejemplo,
personal muy experimentado: +55%) como cuando son negativos (por ejemplo, -87%). En general,
acumular factores negativos en el entorno y el personal supone un gran descalabro de la productividad y
- 34 - Comité de Confiabilidad
FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN
- 35 -Comité de Confiabilidad
la calidad, mucho mayor que la proporción de ganancia de los factores positivos. En consecuencia, la
máxima de que “las personas son nuestro principal activo” se revela aún más cierta en los desarrollos de
software, al menos en lo que respecta a no tratar de ahorrar demasiado en este concepto.
También existen otras reglas básicas sobre la influencia de los recursos humanos en los proyectos.
Por ejemplo, se sabe que “en un proyecto retrasado, incorporar más personal supone retrasarlo más” como
se demuestra en Brooks [29]. De forma más radical, también se sabe que es mejor quitar a un programador
incompetente que incorporar otro adicional a efectos de recuperar un proyecto retrasado y con problemas
de calidad como observó Schulmeyer [30].
3.2 Evolución y mejora tecnológica
Se trata de una opción evidente para la mayoría de los profesionales, dada la actividad comercial
generada respecto de las nuevas opciones tecnológicas que surgen constantemente. En este sentido,
podemos reseñar no sólo las opciones más comentadas de evolución (sistemas operativos, plataformas,
lenguajes etc.) sino la mejora de funcionalidad y de integración entre las herramientas del desarrollador
(CASE para las distintas actividades y fases, IDEs, entornos visuales, etc.). También deben contemplarse
los cambios de modelos y paradigmas (por ejemplo, la evolución desde el desarrollo procedimental
tradicional a los entornos de orientación de objetos, etc.) que influyen en la capacidad y en el control de
calidad sobre los productos generados por parte de los desarrolladores.
Tabla 2. Impacto de factores clave de personal en la productividad y calidad
- 36 - Comité de Confiabilidad
FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN
Las organizaciones suelen estar más concienciadas en gastar en herramientas (>50%) que en
otras medidas, seguramente más eficaces según McConnell [31]. En general, aunque contar con
herramientas de desarrollo (por ejemplo, nuevas plataformas de desarrollo, compiladores, lenguajes,
entornos IDE, CASE, etc.) suele facilitar las tareas y, sobre todo, permite abordar sistemas más complejos
(o que, incluso, anteriormente eran inabordables) con el mismo personal. En efecto, en algunas ocasiones
permiten incrementar la productividad. Por ejemplo, en el modelo de Bohem [32], el uso de herramientas
avanzadas supone un porcentaje de -17% de esfuerzo frente al +24% de esfuerzo con herramientas muy
básicas.
Resulta de gran importancia que las herramientas sean apropiadas y que se integren bien en la
organización de desarrollo a través de formación, de adaptación a las necesidades de los desarrolladores,
del entorno técnico y con otras herramientas ya existentes. El uso de CASE efectivo incrementa la
productividad en un 27%, pero la incorporación inadecuada de herramientas puede disminuir la
productividad en un 75% según los datos de Jones [24]
En general, como indica McConnell en [31] suele ocurrir que el mercado de tecnologías y
herramientas es propicio a reclamos exagerados y sensacionalistas (por ejemplo, “reduzca sus tiempos de
desarrollo en un 15%”), que el 30% de las herramientas adquiridas no cubren las necesidades de los
usuarios, que el 10% no se usan nunca, que el 25% no se aprovechan convenientemente por falta de
formación, etc. Incluso Jones en [33] considera poco creíbles las afirmaciones en el 75% de la publicidad
y que, tras revisar 4000 proyectos, el 70% de los responsables creían que un único factor como éste podría
proporcionar grandes mejoras. En cierto modo, esto enlaza con recurrentes noticias sobre la desaparición
de la figura del programador. Ya se sugería al aparecer el lenguaje ensamblador y perdura hasta nuestros
días: en 2006 se publió que en 2008 las nuevas herramientas de desarrollo harán desaparecer dicho puesto.
3.3 Mejora de procesos de desarrollo
La mejora de las técnicas y métodos de desarrollo pasa por la intervención en distintos planos de
actuación dentro de la organización de desarrollo. Por una parte, a nivel de procesos y desde una
perspectiva global, debemos mencionar las iniciativas de evaluación y mejora de procesos como CMMi
[34], ISO 15504 SPICE [35], etc. En este caso, el foco de atención se centra en la organización de
- 37 -Comité de Confiabilidad
actividades guiada o impulsada desde los responsables de la empresa. Por supuesto, la ordenación de
procesos que provoca ISO 9001 [36] es también una forma de actuar desde el plano de los procesos.
En otro plano de actuación podemos situar la adopción de estándares, metodologías y técnicas.
Propuestas como estándares, ciclos de vida (espiral, etc.) o procesos de desarrollo (RUP [37], extremme
programming [38], etc.), metodologías y notaciones (Metrica v31, UML [39], etc.) parecen contar con apoyos
a favor de su buena influencia en la calidad del software aunque no siempre se han establecido recogidas
y análisis de datos rigurosos que cuantifiquen y aclaren la influencia de los mismos sobre los productos
finales.
La mejora de procesos de software tiene una relación directa y bastante clara con la obtención de
beneficios en cuanto a ROI, productividad y calidad. De hecho, el modelo CMM [40] siempre se ha vinculado
a resultados de disminución de riesgos e incremento de calidad y productividad. En este sentido, podemos
citar la mejora producida en la propia evaluación de los procesos desde los resultados de 1992 a 2003
registrados por el SEI [41] así como los resultados de reducción de defectos, incrementos de productividad,
etc. en porcentajes bastante interesantes recogidos desde los primeros estudios como el de Herbsleb et
al. [42]. En la literatura de calidad existen bastantes estudios donde se discuten los beneficios reales de
otros métodos de mejora de procesos como SPICE-ISO 15504 o de iniciativas como ISO 9001 (en este
caso, quizás más eficaz en estabilizar estándares en los procesos más que conseguir mejoras de
resultados).
Por último, fuera de los modelos de mejora habituales, las mejoras en técnicas de desarrollo,
metodologías, herramientas, etc. deben apoyarse en mediciones y evaluaciones apropiadas dentro de cada
entorno y empresa de aplicación. En este sentido, es imprescindible usar métodos de valoración
contrastados como DESMET [43].
- 38 - Comité de Confiabilidad
FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN
3.4 Mejora de procesos de aseguramiento de calidad de software
Tradicionalmente, por incorporación de la normativa genérica de calidad, el establecimiento de
sistemas de calidad corporativos basados en ISO 9001 [11] ha sido una opción habitualmente considerada
por las organizaciones preocupadas por la calidad. Las peculiaridades del software como producto han
motivado la existencia de una norma complementaria para la adaptación de la norma general ISO 9001 al
software, a la ISO 90003 [44]. Evidentemente, en el caso de ISO 9001 han confluido los intereses de imagen
comercial con el interés por la mejora por sus implicaciones de mercado. Entre los profesionales se ha
generado controversia por éste y otros aspectos, aunque resulta claro que el establecimiento de estructuras
organizativas orientadas a la calidad y documentadas (manual de calidad, procedimientos, etc.) ha
fomentado, al menos, un esquema claro de trabajo y una estabilización de procesos y resultados. También
ha servido para establecer unos mínimos en la aplicación del aseguramiento de calidad como medio de
proporciona confianza a los desarrolladores y a los clientes sobre la sistemática de trabajo en los proyectos.
A nivel de proyecto, el trabajo se suele apoyar en una planificación específica (aunque coherente
con el sistema de calidad u otras normas aplicables) a través de un plan de aseguramiento de calidad de
software. Si adoptamos el correspondiente estándar IEEE, el 730 [45], como referencia, las técnicas
incluidas para los proyectos se corresponden con las más tradicionales y usadas: gestión de configuración
(como elemento clave de control de los productos), medición (para evaluación completa de procesos y
productos) así como verificación y validación (principalmente basadas en aplicación de pruebas y de
procesos de revisión y auditoría). Por supuesto existen catálogos más extensos de técnicas (ver los trabajos
publicados en ACM [46] e IEEE [47]) pero no suelen ser tan comunes como las mencionadas (ver tabla 3).
- 39 -Comité de Confiabilidad
Tabla 2. Otras técnicas de verificación y validación
- 40 - Comité de Confiabilidad
FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN
Pruebas de software
De manera breve, debemos recordar que las pruebas de software deberían ceñirse al ciclo de
pruebas propuesto en el estándar IEEE 1008 [48] (ver fig. 10). El diseño de casos de prueba está totalmente
mediatizado por la imposibilidad de probar exhaustivamente el software. Pensemos en un programa muy
sencillo que sólo suma dos números enteros de dos cifras (del 0 al 99). Si quisiéramos probar, simplemente,
todos los valores válidos que se pueden sumar deberíamos probar 10.000 combinaciones distintas de cien
posibles números del primer sumando y cien del segundo. Pensemos que aún quedarían por probar todas
las posibilidades de error al introducir los datos (p. ej. teclear una letra en vez de un número). Tampoco
podemos pretender analizar todos los posibles caminos de ejecución por el programa que son también
impracticables. Si para un programa tan elemental debemos realizar tantas pruebas, podemos imaginar lo
que supondría un programa de tamaño real.
En consecuencia, las técnicas de diseño de casos de prueba tienen como objetivo conseguir una
confianza aceptable en que se detectarán los defectos existentes (ya que la seguridad total sólo puede
obtenerse de la prueba exhaustiva, que no es practicable) sin que se necesite consumir una cantidad
excesiva de recursos (p. ej. tiempo para probar o tiempo de ejecución). Toda la disciplina de pruebas debe
moverse, por lo tanto, en un equilibrio entre la disponibilidad de recursos y la confianza que aportan los
casos para descubrir los defectos existentes. Este equilibrio no es sencillo, lo que convierte a las pruebas
en una disciplina difícil y que está lejos de parecerse a la imagen de actividad rutinaria que suele sugerir.
Figura 10. Cilco completo de pruebas definido en el estándar IEEE [48]
- 41 -Comité de Confiabilidad
Ya que no se pueden probar todas las posibilidades de funcionamiento del software, la idea
fundamental para el diseño de casos de prueba consiste en elegir algunas de ellas que, por sus
características, se consideren representativas del resto. Así, se asume que, si no se detectan defectos en
el software al ejecutar dichos casos, podemos tener un cierto nivel de confianza (que depende de la elección
de los casos) en que el programa no tiene defectos. La dificultad de esta idea es saber elegir los casos que
se deben ejecutar. De hecho, una elección puramente aleatoria no proporciona demasiada confianza en que
se puedan detectar todos los defectos existentes. Por ejemplo, en el caso del programa de suma de dos
números, elegir cuatro pares de sumandos al azar no aporta mucha seguridad a la prueba (una probabilidad
de 4/10.000 de cobertura de posibilidades). Por eso es necesario recurrir a ciertos criterios de elección que
veremos a continuación.
Existen tres enfoques principales para el diseño de casos como indica Myers [49]:
�El enfoque estructural o de caja blanca11 (véase la figura 11). Consiste en centrarse en la
estructura interna (implementación) del programa para elegir los casos de prueba. En este caso, la
prueba ideal (exhaustiva) del software consistiría en probar todos los posibles caminos de ejecución,
a través de las instrucciones del código, que puedan trazarse.
�El enfoque funcional o de caja negra12 (véase la figura 11). Consiste en estudiar la especificación
de las funciones, la entrada y la salida para derivar los casos. Aquí, la prueba ideal del software
consistiría en probar todas las posibles entradas y salidas del programa.
�El enfoque aleatorio consiste en utilizar modelos (en muchas ocasiones estadísticos) que
representen las posibles entradas al programa para crear a partir de ellos los casos de prueba. La
prueba exhaustiva consistiría en probar todas las posibles entradas al programa.
Estos enfoques no son excluyentes entre sí ya que se pueden combinar para conseguir una
detección de defectos más eficaz. Veremos a continuación una presentación de cada uno de ellos.
11 En inglés, white box testing. Sin embargo, la denominación “caja blanca” no es afortunada ya que se trata de unacaja transparente, que permite ver su interior. Recientemente, la mayoría de autores ya utiliza la expresión “pruebade caja de cristal” (Glass box testing).12 En inglés, black box testing
FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN
Comité de Confiabilidad
Por último, es importante recordar que la aplicación de las pruebas durante el desarrollo de software
se realiza a través de una estrategia de fases centradas cada una de ellas en un aspecto distintos del
software desarrollado (ver figura 12).
- 42 -
Figura 11. Los enfoques de diseño de pruebas de caja blanca y de caja negra
Figura 12. Estrategia de aplicación de pruebas en el desarrollo de software
Técnicas de revisión y auditoría
Son técnicas de verificación y validación que permiten la evaluación y el análisis de productos
generados durante el desarrollo y que no pueden ser ejecutados. Esto es esencial para la filosofía de
aseguramiento de calidad del software puesto que la detección temprana de problemas y la inexistencia
de pruebas definitivas obliga a controlar paso a paso los productos generados en el proceso de
desarrollo. Además esta filosofía es económicamente rentable como se puede ver en la tabla 4.
Comité de Confiabilidad - 43 -
Tabla 4. Corrección de un defecto según la fase de desarrollo
Figura 13. Enfoque integral de aseguramiento de calidad del software
FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN
Comité de Confiabilidad- 44 -
Para ello disponemos de diversos métodos (ver tabla 5).
Las revisiones y auditorías se pueden utilizar para revisar tanto procedimientos de gestión del
proyecto como productos derivados del desarrollo o productos intermedios13. Se trata de documentos que
se comunican o entregan al cliente o al equipo de desarrollo14, que se producen o adquieren durante el
desarrollo o mantenimiento del software; por ejemplo, documentos de planificación del proyecto (como
planes de desarrollo de software o planes de verificación y validación del software), especificaciones de
requisitos software, descripciones de diseño, código fuente, etc. En la figura 14 vemos sobre qué se enfocan
los distintos métodos.
Tabla5. Verificación y validación según IEEE 1028
13 También pueden encontrarse en la literatura anglosajona con los términos “work unit” y “software element”.14 En inglés, deliverables.
Figura 14. Enfoque de las distintas técnicas de V&V
Comité de Confiabilidad - 45 -
Otras técnicas menos importantes son las revisiones Desk Checking [49], [51], Round-Robin [52], y
Peer Ratings [49]. En las referencias [50] y [52] se pueden encontrar las diferencias más concretas entre
las distintas variantes de revisión: revisiones de gestión, revisiones técnicas, walkthroughs e inspecciones.
Hay que considerar aparte las auditorías de software, ya que presentan muchas diferencias de
proceso con las revisiones. Además, se pueen utilizar para examinar tanto el proyecto como los productos
intermedios (ver tabla 6).
En cuanto a la recomendación de utilización de estas técnicas en los proyectos de desarrollo, se puede
añadir la lista incluida en el estándar IEEE 1012 [53] que se presenta en la tabla 7. Esta es una
recomendación para software crítico que puede adaptarse a cada proyecto según su nivel de riesgos.
Tabla 4. Comparativa entre revisiones y auditorías según [50]
- 46 - Comité de Confiabilidad
FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN
Tabla 7. Recomendación de revisiones y auditorías según IEEE 1012 [53]
- 47 -Comité de Confiabilidad
Quizás el proceso más formalizado de todos los de revisión es el de inspección. Las fases típicas
de un proceso de inspección se resumen en la figura 15. Puede apreciarse que, al igual que en el resto de
procesos de revisión, se generan listas de defectos identificados que permiten el seguimiento para los
distintos aspectos de confiabilidad abordados en apartados anteriores.
Para que una inspección tenga éxito debe seguir ciertas reglas:
�Las inspecciones se realizan en un determinado número de puntos del ciclo de vida, tanto en el
proceso de planificación del proyecto como en el proceso de desarrollo del sistema.
�Se inspeccionan todas las clases de defectos posibles en todos los tipos de documentación (no
sólo errores lógicos o funcionales).
Figura 15. El proceso de inspección
(estándares, guías y procedimiento)
- 48 - Comité de Confiabilidad
FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN
�Participación en las inspecciones: “pares” y personal de todos los niveles jerárquicos exceptuando
la alta dirección.
�Las inspecciones se deben realizar en una serie predefinida y estricta de etapas.
�La duración de las reuniones no deberá exceder las dos horas .
�Las inspecciones deben ser dirigidas por moderadores entrenados y experimentados (a través de
prácticas en inspecciones) para lograr eficacia en su trabajo.
�Los miembros del equipo de inspección tienen asignados papeles específicos para incrementar
su efectividad.
�Se usan listas de comprobación para que los miembros del equipo de inspección tengan su tarea
definida y para incrementar el descubrimiento de los defectos.
Métricas y evaluación de calidad
La evaluación de la calidad del software se basa en la utilización de modelos de calidad para
abarcar sus distintas facetas. Fundamentalmente, ha sido el modelo de McCall et al. [8] (ver figura 16) el
que ha inspirado más variantes hasta la aparición de los estándares actuales (principalmente ISO 9126 [2]:
ver figura 17). Todos ellos descomponen la calidad en sub-características más fáciles de medir o evaluar.
Figura 16. Modelo de evaluación de calidad de McCall
- 49 -Comité de Confiabilidad
En cualquier caso, estos modelos no son operativos sin tener en cuenta las siguientes
consideraciones:
�Son modelos de referencia que deben personalizarse para cada proyecto en función de las
necesidades expresadas para el cliente o usuario del software. Eso implica ponderar los distintos
factores y marcar criterios para su medición con valores umbrales de aceptación.
�Los distintos factores no son independientes. No es posible maximizar todos ellos puesto que, en
algunos casos, existen relaciones de antagonismo. Así , por ejemplo, la eficiencia del software tiene
una relación inversa con la portabilidad del software ya que la eficiencia máxima suele exigir utilizar
todos los recursos propios de cada plataforma.
�La evaluación de cada característica debe apoyarse en métricas de software lo más objetivas
posible y que estén validadas. La validación en el ámbito de la medición significa poder demostrar
que una métrica realmente mide lo que dice medir. El problema habitual es que existen métricas
conocidas que no siempre cuentan con validación adecuada. Para una panorámica general de la
medición de software y sobre la problemática de la validación, es recomendable consultar el libro
de Fenton y Pfleeger [14].
Figura 17. Modelo estándar ISO 9126 para evaluación de calidad de software
- 50 - Comité de Confiabilidad
FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN
Otras consideraciones sobre aseguramiento de calidad
Es importante recordar que estas técnicas son caras y que su uso debe adaptarse a cada entorno
tanto para ser eficaz (incorporándose con facilidad a la vida diaria del equipo de desarrollo) como para ser
más eficiente y rentable. Por ejemplo, los procesos de revisión de todo el código de una aplicación suelen
ser inabordables por su coste. Para buscar mayor eficiencia, se suele establecer unos análisis previos con
herramientas basados en patrones de métricas y reglas a cumplir. Aplicando el principio de Pareto, la
empresa sólo aplica inspecciones a los trozos de código más críticos o con peores evaluaciones en dicho
análisis para concentrar el esfuerzo disponible en los módulos que puedan acumular más defectos y más
peligrosos. Otra táctica, que puede ser complementaria, consiste en disminuir esfuerzo automatizando
tareas de evaluación con herramientas y disminuyendo el número de revisores implicados.
En cualquier caso, la aplicación de acciones apropiadas de aseguramiento de calidad de software
permite, al menos, estabilizar tiempos de entrega y niveles de calidad (como en la experiencia presentada
por Yasuda [54]). Son bastante frecuentes los estudios y publicaciones que demuestran mejoras de
productividad y rentabilidad basadas en disminuir retrabajo y minorar efectos adversos causados por
defectos y fallos en el software: los llamados costes de la mala calidad descritos por Harrington [55]
Ya en los años ochenta, los programas corporativos pioneros en Hewlett-Packard [56] demostraron
cómo se podían compatibilizar actividades de aseguramiento de calidad, medición de resultados y objetivos
corporativos basados en la rentabilidad, disminución de break-even time y reducción de defectos. La
reducción de defectos supone un ahorro de costes debido a los ya mencionados costes de la mala calidad:
retrabajo, indemnizaciones, pérdida de imagen. Como ya descubrió IBM hace tiempo y se describe en [55],
cada dólar dedicado a prevención supone el ahorro de 50 dólares después. Por ello, el aseguramiento
debe ser especialmente insistente en proporcionar medios de detección y corrección temprana de defectos
(ver tabla 2).
- 51 -Comité de Confiabilidad
Algunas ideas sobre el mantenimiento de software
La eliminación de defectos durante la vida operativa de un sistema se denominan mantenimiento
correctivo o preventivo. El mantenimiento correctivo pretende eliminar defectos que han producido uno o
más errores y que han sido reportados mientras que el mantenimiento preventivo pretende descubrir y
eliminar defectos antes de que puedan causar errores durante la operación normal del sistema. Entre estos
últimos defectos se podrían incluir tanto defectos físicos que hayan ocurrido después del último
mantenimiento preventivo como defectos de diseño que hayan llevado a errores en otros sistemas similares.
Las técnicas y consejos ya explicados en el apartado 2.3 se aplican más al mantenimiento
correctivo. Por otra parte, en el software se contemplan distintas estrategias y técnicas para facilitar los
distintos tipos de mantenimiento: por ejemplo, ingeniería inversa, reingeniería, análisis de código,
recuperación de diseño, reestructuración, etc. Una buena explicación de las mismas se encuentra en el libro
de Piattini et al. [15]. La mayoría de estas técnicas ha recibido un impulso importante gracias a la existencia
de herramientas automñaticas que asisten en el proceso de análisis y recuperación de información para el
mantenimiento a partir del código de la aplicación.
FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN
Comité de Confiabilidad- 52 -
4. ALGUNAS CONSIDERACIONES
ADICIONALES
En el ámbito de la confiabilidad también se menciona el concepto de capacidad de supervivencia
(survivability), surgido principalmente a finales de los años sesenta y principios de los setenta del siglo XX
en estándares militares (por ejemplo, MIL-STD-721 o DOD-D-5000.3). Se definió en dicho momento como
la capacidad del sistema para resistir en un entorno hostil de tal forma que pudiera cumplir su misión según
indica Avizienis [5]. La confiabilidad ha evolucionado desde los conceptos de fiabilidad y disponibilidad a
través de la evolución tecnológica de la informática y de las comunicaciones para dar respuesta adecuada
a los desafíos de aplicaciones en red y la necesidad creciente de confianza en la informática ubicua. Así,
la capacidad de supervivencia entendida como “capacidad de un sistema para continuar con su misión en
presencia de ataques, fallos o accidentes”, ha evolucionado desde los asuntos de pura seguridad y ha
ganado interés debido a la frecuencia y gravedad de ataques de adversarios inteligentes sistemas de
información críticos. Desde la perspectiva de la confiabilidad la capacidad de supervivencia es la
confiabilidad en presencia de defectos activos de todo tipo. La relación entre ambas se percibe como
estrecha cuando observamos las 3 R de la capacidad de supervivencia descritas por Lipson [57]:
�Resistencia: capacidad de repeler ataques. Se relaciona en confiabilidad con la prevención de
defectos.
�Reconocimiento: capacidad de reconocer ataques y la extensión de los daños.
�Recuperación: capacidad de restaurar los servicios esenciales durante el ataque y recuperar el
servicio completo tras el mismo, junto con el reconocimiento. Tiene mucho que ver con tolerancia
a defectos.
En cualquier caso, ambas características van más allá de los enfoques tradicionales basados en
evitar defectos.
Comité de Confiabilidad
5. REFERENCIAS
- 55 -
[1] IEEE, IEEE Standard 610. Computer dictionary. Compilation of IEEE Standard Computer Glossaries,
Institute of Electrical and Electronics Engineers, 1993.
[2] ISO, ISO 9126. Information technology. Software product evaluation. quality characteristics and
guidelines for their use, International Organization for Standardization, 2001.
[3] ISO, ISO 14598-1. Information technology software product evaluation. Part I: general overview,
International Organization for Standardization, 2001.
[4] J.C. Laprie. Dependability: Basic Concepts and Terminology. Springer Verlag, Vienna, Austria, 1992.
[5] A. Avizienis, J.-C. Laprie and B. Randell, Fundamental Concepts of Dependability, Research Report
N01145, LAAS-CNRS, abril, 2001.
[6] IEEE, IEEE Std 1044.1-1995 IEEE Guide to Classification for Software Anomalies -Description, Institute
of Electrical and Electronics Engineers, 1995
[7] IEEE, IEEE Std 1044-1993 IEEE Standard Classification for Software Anomalies – Description, Institute
of Electrical and Electronics Engineers, 1993.
[8] J.A. McCall, P.K. Richards y G.F. Walters, Factors in software quality, vols. I, II y III, US Rome Air
Development Center Reports NTIS AD/A-049 014, 015, 055, 1977.
[9] A. Avizienis, J-C., Laprie, B. Randell, “Fundamental Concepts of Computer System Dependability”,
IARP/IEEE-RAS Workshop on Robot Dependability: Technological Challenge of Dependable, Robots in
Human Environments, 2001.
[10] European Cooperation for Space Standardization, Space product assurance. Methods and techniques
to support the assesment of software dependability and safety, Draft ECSS-Q-80-03, ESA-ESTEC, marzo,
2006.
[11] R.S. Pressman, Ingeniería del software. Un enfoque práctico, McGraw-Hill, 2005.
[12] M.L.Shooman, Software Engineering Design, Reliability, And Management, McGraw-Hill, 1983
Comité de Confiabilidad
[13] B. Randell, “Approaches to Software Fault Tolerance”, Proc. the 25th Annual LAAS Conference,
Toulouse, France, 1993, p. 33-42.
[14] N.E. Fenton y S.L.Pfleeger, Software metrics. A rigorous and practical approach, PWS, 1997.
[15] M. Piattini, J.A. Calvo-Manzano, J.Cervera, L. Fernández, Análisis y diseño de aplicaciones informáticas
de gestión, Un enfoque de ingeniería del software, Ra-Ma, 2004.
[16] G. J., Myers, The art of software testing, Wiley and sons, 1979.
[17] J. Voas y C. McGraw, Software fault injection: inoculating programs against errors, Wiley and sons,
1997.
[18] Z. Jelinski and Paul B. Moranda. “Software Reliability Research”. In W. Freiberger, editor, Statistical
Computer Performance Evaluation. Academic Press, 1972.
[19] J. Musa, “A Theory of Software Reliability and Its Application,” IEEE Trans. on Soft. Eng., Sept. 1975,
pp 312-327.
[20] B. Littlewood, “A software reliability model for modular program structure”, IEEE transactions on
Reliability, vol. 28, nº 3, pp.241-246, 1979.
[21] B. Littlewood y J.L.Verrall, “A bayesian reliability growth model for computer software”, Journal of the
Royal Statistical Society, C22, pp. 332-334, 1973.
[22] M. Dyer, The cleanroom approach to quality software development, Wiley and sons, 1992.
[23] R. Linger, “Cleanroom process model”, IEEE Software, vol. 11, nº 2, marzo 1994, pp. 50-58.
[24] C. Jones, Estimating software costs. McGraw-Hill, 1998.
[25] L. Fernández, “Requisitos para el empleo en Nuevas Tecnologías de la Información: el estudio
RENTIC”, Novática, nº161, 2003, pp. 51-56.
[26] W.S. Humphrey, Introducción al proceso software personal. Addison-Wesley, Madrid, 2001.
[27] L. Fernández y M. J. García, “Software engineering professionalism”, Upgrade, nº 4, 2003, pp. 59-66.
[28] T. K. Abdel-Hamid y S. Madnick, Software project dynamics. An integrated approach, Prentice-Hall,
1991.
FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN
Comité de Confiabilidad- 56 -
[29] F. Brooks, The mythical man-month, Addison-Wesley,1975.
[30] G.G. Schulmeyer, “The net negative producing programmer”. American Programmer, nº 6 (1992).
[31] S. McConnell, Desarrollo y gestión de proyectos informáticos. Cómo dominar planificaciones ajustadas
de software. McGraw-Hill, 1997.
[32] B. W. Boehm, Software engineering economics. Prentice-Hall, 1981.
[33] C. Jones, Assessment and control of software risks, Yourdon Press, 1994.
[34] CMMi product team, CMMI® for Development, Version 1.2. CMU/SEI-2006-TR-008, Carnegie-Mellon
SEI, agosto 2006.
[35] ISO/IEC Commission, ISO/IEC 15504-3:2004. Information technology: Process assessment. Part 3:
Guidance on performing an assessment, ISO, 2003.
[36] ISO, UNE-ISO 9001. Sistemas de gestión de calidad. Requisitos. AENOR, 2000.
[37] I. Jacobson, J. Rumbaugh y G. Booch, The Unified Software Development Process. Addison-Wesley,
1999.
[38] K. Beck, Una explicación de la programación extrema: aceptar el cambio, Addison Wesley, 2002.
[39] OMG, UML 2.0 Superstructure Specification, OMG Adopted Specification, ptc/03-08-02, Object
Management Group, agosto, 2003.
[40] M. C. Paulk, C.V. Weber, S. M. Garcia, M. B. Chrissis y M. Bush, Capability Maturity Model For Software
v. 1.1., Software Engineering Institute, 1993.
[41] Software Engineering Institute, Software CMM CBA-IPI and SPA Appraisal results. 2003 Mid-Year
Update. Software Engineering Institute, 2003.
[42] Herbsleb, J. et al.: Benefits of CMM-based software process improvement: initial results. CMU-SEI-94-
TR-013. Software Engineering Institute, Pittsburgh (1994).
[43] B. A. Kitchenham, Evaluating software engineering methods and tools. Part I. ACM Software engineering
notes, vol. 21, nº 1, 1996, pp. 11-15.
Comité de Confiabilidad - 57 -
[44] AENOR, UNE-ISO/IEC 90003. Ingeniería del software. Guía de aplicación de la ISO 9001:2000 al
software, AENOR, julio, 2005.
[45] IEEE, Std. 730, Standard for Software Quality Assurance Plans. IEEE, 1998.
[46] W.R. Adrion, M. A. Branstad y J. C. Cherniavsky, “Verification, Validation, and testing of Computer
Software”. ACM Computing Surveys, vol. 14, nº 2, 1982, 159-192.
[47] D.R. Wallace y R.U.Fuji, Software Verification and Validation: An Overview, IEEE Software, vol. 6, nº 3,
mayo/junio 1989, pp. 10-17
[48] IEEE, IEEE Std. 1008-1986.Standard for Software Unit Testing, IEEE, 1987.
[49] G. J. Myers, The Art of Software Testing, Wiley and Sons, 2004.
[50] IEEE, IEEE Std. 1028-1997, Standard for Software Reviews and Audits, IEEE Computer Society, junio,
1997.
[51] Dunn, R. H., Software Defect Removal, McGraw-Hill, 1984.
[52] D. P. Freedman y G. M. Weinberg, Handbook of Walkthroughs, Inspections and Technical Reviews, Little
Brown & Company, 1982.
[53] IEEE, IEEE Std. 1012-1998, Standard for Software Verification and Validation Plans, IEEE Computer
Society, 1998.
[54] K. Yasuda, “Software quality assurance in Japan” en N. Fenton y B. Littlewood (eds.): Software reliability
and metrics. Elsevier Science Pub., 1991.
[55] H. J. Harrington, El coste de la mala calidad. Díaz de Santos, 1990.
[56] R. B. Grady, D. L. Caswell, Software metrics. Prentice-Hall, 1994.
[57] H.F. Lipson. “Survivability — A new security paradigm for protecting highly distributed mission-critical
systems 38th meeting of IFIP WG 10.4, Kerhonson, New York, June 28-July 2, 2000, pp. 63-89 (disponible
en LAAS-CNRS).
FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN
Comité de Confiabilidad- 58 -
Comité de Confiabilidad - 59 -
Luis Fernández Sanz es licenciado en informática por la Universidad Politécnica de Madrid (1989)
y doctor en informática por la Universidad del País Vasco (1997) con Premio Extraordinario de Doctorado.
Ha sido profesor en la Facultad de Informática de la Universidad Politécnica de Madrid (1989-1996) en las
áreas de ingeniería de software y de sistemas de información. En 1996 se integra en la Universidad Europea
de Madrid (UEM) centrado en las áreas de ingeniería del software y programación. En 2000 fue nombrado
profesor titular y en el período 2000-06 fue director de uno de los departamentos del área de informática.
Actualmente, es profesor en el Departamento de Ciencias de la Computación de la Universidad de Alcalá.
En 2005 recibió el 1er Premio en la segunda edición de los Premios de Innovación Docente de la UEM. Ha
sido profesor o docente invitado en diversos master y postgrados de universidades de toda España, además
de intervenir como director o profesor en más de 30 cursos sobre ingeniería y calidad del software tanto en
modalidad in-company como en convocatoria abierta para profesionales y empresa
En el ámbito de la I+D y en su ejercicio profesional y docente vinculado a la empresa, se ha
centrado en la ingeniería y la calidad del software. Así, ha dirigido y participado en diversos proyectos de
consultoría y servicios para entidades como Ministerio de Asuntos Exteriores, Meta4, France Telecom,
Vodafone, etc. y también ha dirigido como administrador único una pequeña compañía de servicios de
desarrollo de software. También ha dirigido o participado en diversos proyectos de I+D financiados tanto por
entidades públicas como privadas. Ha sido autor o coautor de diversos libros de texto y de investigación
tanto en español como en inglés relacionados con la ingeniería y la calidad del software además de
numerosas comunicaciones en congresos y artículos de revista en ámbito nacional e internacional.
Desde 1993 es coordinador de la Sección de Ingeniería del Software de la revista Novática
(www.ati.es/novatica). En 2005 lanzó la Revista Española de Innovación, Calidad e Ingeniería del Software
(www.ati.es/reicis) de la que es editor. También coordina el grupo de Calidad del Software de ATI desde 2000
siendo responsable de la organización de sus sesiones técnicas y de las Jornadas de Innovación y Calidad
del Software.
6. SOBRE EL AUTOR
top related