Fundamentos de Confiabilidad en el desarrollo del software

PRIMERA EDICIÓN: 2008

ASOCIACIÓN ESPAÑOLA PARA LA CALIDAD

Claudio Coello 92

28006 Madrid

www.aec.es

[email protected]

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: [email protected].

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


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



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


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.



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


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



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


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.



�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].


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.



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.


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.



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


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


- 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


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.




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,




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).




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.




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).



Figura 8.a Curso de coste y fiabilidad para el fabricante


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


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



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



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


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].



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).


Tabla 2. Otras técnicas de verificación y validació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]


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



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.


Tabla 4. Corrección de un defecto según la fase de desarrollo

Figura 13. Enfoque integral de aseguramiento de calidad del software



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


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]



Tabla 7. Recomendación de revisiones y auditorías según IEEE 1012 [53]


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)



�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


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



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).


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.

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.


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


[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.



[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.


[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).




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

Fundamentos de Confiabilidad en el desarrollo del software

Documents

Transcript of Fundamentos de Confiabilidad en el desarrollo del software