Fundamentoconfiabilidad 1286753198 Phpapp02

PRIMERA EDICIN: 2008
ASOCIACIN ESPAOLA 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 distribucin por cualquier medio siempre que mantenga el
reconocimiento de sus autores, no se haga uso comercial de las obras y no realice
ninguna modificacin de ellas.
La licencia completa puede consultarse en:
http://creativecommons.org/licenses/by-nc-nd/2.5/es/legalcode.es
Comit de Confiabilidad
- 3 -
PRESENTACIN
Esta publicacin se enmarca dentro de las actividades que realiza el Comit de Confiabilidad de la
Asociacin Espaola para la Calidad (AEC) en su afn de divulgar los conocimientos de este campo de la
ingeniera.
El concepto de Confiabilidad, entendida sta como la integracin conjunta de las caractersticas de
Fiabilidad, Disponibilidad, Mantenibilidad y Seguridad de un dispositivo, es aplicable a cualquier tipo de
componente, equipo, sistema o instalacin.
Cada da ms, el software constituye un elemento bsico en la configuracin de los ms diversos
dispositivos, siendo primordial en muchos casos. Su papel operativo es relevante en la automocin, la ae-
ronutica, las instalaciones energticas y la prctica totalidad de los sectores industriales. Las funciones en-
comendadas al software tambin son significativas en trminos de criticidad: control, optimizacin,
seguridad, etc.
Sus especiales caractersticas requieren que los conceptos generales y los mtodos de anlisis de
la Ingeniera de Confiabilidad deban adaptarse de forma apropiada con el fin de disponer de un cuerpo
metodolgico que sea aplicable eficazmente para el desarrollo de sistemas informticos confiables.
El profesor Lus Fernndez 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 elaboracin de la presente publi-
cacin.
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
mtricas asociadas.
Con el deseo de que esta publicacin contribuya, desde la humildad con la que debe plantearse
cualquier accin humana, a ampliar la inacabable senda del conocimiento y desde el agradecimiento al
autor por su meritorio y ejemplar esfuerzo, les presentamos esta publicacin.
Siguiendo nuestro deseo de mejora continua, la AEC est interesada en conocer su opinin, comen-
tarios o sugerencias acerca de esta publicacin. Para ello, no dude en enviarnos todos sus comentarios a
la siguiente direccin de correo electrnico: publi@aec.es.
Antonio Jos Fernndez Prez
Presidente del Comit de Confiabilidad
Doctor Ingeniero Industrial
FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIN
- 4 -
NDICE
1. Introduccin 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 Prevencin de defectos 17
2.2 Tolerancia de defectos 18
2.3 Eliminacin de defectos 20
2.4 Prediccin 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 Evolucin y mejora tecnolgica 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
- 5 -
- 6 -
1. INTRODUCCIN
El concepto de confiabilidad es habitual en los diversos sectores industriales y tambin en el mbito
del diseo y desarrollo de sistemas. Sin embargo, no ha sido tan ampliamente aplicado en una gran parte
del desarrollo de software ya que slo ciertos sectores que trabajan con sistemas crticos (por ejemplo, el
aeroespacial, el de defensa, el de transporte, etc.) han profundizado en el anlisis de la dependability y de
las tcnicas especficas para su consecucin y evaluacin. Desde el punto de vista de la ingeniera del
software se suele integrar cualquiera de las caractersticas 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 trminos de ingeniera de software o en los
modelos de evaluacin de calidad mediante rboles de descomposicin de caractersticas. As, el estndar
IEEE Std. 610 [1] no contempla el trmino dependability. En cuanto a los modelos de calidad estandarizados
como ISO 9126 [2] (y, por supuesto, ISO 14598 [3]) no se opta por la caracterstica 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
informtico 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 aplicacin o sistema que interacta 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 catastrficas, significa fuera de peligro (safe)
Respecto de la prevencin de acceso y/o manejo de informacin no autorizados, significa seguro
(secure).
- 7 - Comit de Confiabilidad
- 8 -
En cuanto al desarrollo de sistemas informticos confiables supone la utilizacin combinada de un
conjunto de mtodos que abarcan:
Prevencin de la ocurrencia o introduccin de defectos.
Tolerancia a fallos o cmo proporcionar el servicio especificado a pesar de los defectos
Eliminacin de defectos o cmo reducir la presencia (gravedad o nmero) de los mismos.
Prediccin de defectos o cmo estimar el nmero 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 ms en cuanto a caractersticas:
Figura 1. Esquema de definicin de la confiabilidad de sistemas informticos
Comit de Confiabilidad - 9 -
1.1 Definiciones sobre amenazas: defectos, errores y fallos
Para una correcta comprensin 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 accin del sistema que deben estar recogidos en su especificacin.
Un fallo del sistema es un acontecimiento que ocurre cuando el sistema se desva del servicio
correcto
1
. Esta desviacin puede producirse por no cumplir la especificacin acordada o porque la
especificacin no describe correctamente la funcin requerida por el usuario. En el glosario IEEE
Std. 610 [1] se matiza la definicin 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 definicin de datos incorrecta en un programa o software.
El defecto (fault) es la causa comprobada o hipottica de un error. Un defecto est activo cuando
produce un error; en caso contrario, est aletargado.
Tambin se comenta en el glosario del IEEE [1] la distincin entre accin humana (error como
meter la pata
2
: mistake), su manifestacin en el sistema (defecto: fault, defect
3
), las consecuencias de un
defecto (fallo: failure) y el grado de desviacin por el cual el resultado es incorrecto (error: error). Se puede
ver la relacin causal entre estos trminos en la figura 2.
1
Un fallo se podra considerar como una transicin desde un servicio correcto a uno incorrecto. La restauracin del
servicio (service restoration) es la transicin inversa: de incorrecto a correcto. El perodo intermedio se denomina
cada del servicio (service outage).
2
Por ejemplo, un programador se equivoca en el diseo de un programa.
3
Se utiliza tambin la palabra bug ya que existe una ancdota situada en uno de los primeros ordenadores en los
aos cuarenta/cincuenta donde un insecto es la causa de los fallos aleatorios de funcionamiento al quedar atrapado
en su interior.
- 10 -
A modo de ejemplo, el resultado de un error de un programador lleva a equivocarse en escribir una
instruccin de cdigo o una definicin de datos incorrecta. Al activarse (se ejecuta dicha instruccin), el
defecto pasa a estado activo y produce un error; siempre y cuando dicho error afecta al servicio entregado
al usuario (en informacin 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 denegacin de servicio (denial-of-service).
Por supuesto tambin se puede representar el mecanismo de propagacin 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 reciba 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 publicacin de Avizienis et al. [5] se habla de modos de fallo
donde las tres vistas principales son (ver fig. 4):
El dominio
La percepcin por parte de los usuarios
Las consecuencias en el entorno
Figura 3. Propagacin de errores a travs del sistema
Figura 4. Esquema de clasificacin de fallos
- 12 -
Sin embargo, existen clasificaciones ms complejas como la recogida en el estndar IEEE Std.
1044 [6] [7], centrada en el registro de anomalas de software: siguiendo la terminologa ya presentada, los
errores o manifestaciones de desviaciones de lo especificado o requerido. En este caso, se sugiere tratar
con los siguientes datos
4
:
Actividad del proyecto que lo detect
Fase del proyecto en la que se detect
Causa sospechada
Repetibilidad: una vez, intermitente, recurrente, reproducible, desconocida
Sntoma
Estado del producto: no utilizable, degradado, afectado, no afectado
En cuanto a los defectos, tambin se proponen categoras para la clasificacin elemental de los
mismos como causas de fallos tanto en dos trabajos de Avizienis et al. [5] [9].
Figura 5. Esquema de clasificacin de defectos
1.2 Atributos de la confiabilidad
Por otra parte, es importante contrastar la definicin 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 evaluacin de calidad del software
Disponibilidad
~Integracin en modelos: no es mencionado como atributo de ningn nivel, ni en ISO
9126 [2] ni en el modelo de McCall et al. [8].
~Definicin: en la referencia de Avizienis et al. [5] se define como la preparacin para
proporcionar el servicio correcto.
Fiabilidad
~Integracin en modelos: se trata de un factor de primer nivel de descomposicin 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 recuperacin (restablecer nivel de prestaciones y recuperar datos afectados).
~Definicin: 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 perodo
fijado de tiempo.
Proteccin
5
(safeness)
~Integracin en modelos: no es mencionado como atributo de ningn nivel, en ISO [2]
ni en el modelo de McCall et al. [8].
~Definicin: en el trabajo de Avizienis [5] se define como la ausencia de consecuencias
catastrficas para el usuario o el entorno.
5 Se opta por el trmino proteccin para safeness para distinguir mejor con la seguridad (security) siguiendo reco-
mendaciones ya existentes de traduccin al espaol.
- 14 -
Confidencialidad
~Integracin en modelos: en el modelo de ISO [2] se menciona la seguridad de acceso
como subatributo del factor funcionalidad de primer nivel refirindose a la proteccin de
informacin 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 trmino integrity
precisamente como control de acceso a la informacin.
~Definicin: Avizienis [5] la define como la ausencia de revelacin no autorizada de
informacin.
Integridad
~Integracin en modelos: no es mencionado como atributo de ningn 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 auditora.
~Definicin: 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 (ms afn al de confidencialidad).
Facilidad de mantenimiento
~Integracin 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 modificacin. En el de McCall [8] tambin es un factor de primer
nivel con los subatributos de consistencia (en diseo e implementacin), simplicidad
(facilidad de comprensin), concisin (minimizacin de cdigo), modularidad
(independencia de componentes) y autodescripcin (autodocumentacin de la
implementacin).
~Definicin: 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.
Adems, 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 quizs 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 funcin 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.
- 16 -
riesgos. Este acuerdo de requisitos debe documentarse claramente como parte de la especificacin del
software desde el inicio del proyecto con la validacin 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 podra
haber matices, mientras que el resto de atributos podran ser esenciales o, por el contrario, no necesarios
en determinados proyectos. Adems, resulta especialmente conflictivo hablar de niveles absolutos de
confiabilidad debido a que no existe la total ausencia de defectos
6
.
En el caso del trmino seguridad (security), en el trabajo de Avizienis [5] se vincula a la agrupacin
de disponibilidad slo 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 proteccin enfatizan la capacidad para evitar una
clase especfica de fallos (catastrficos o acceso no autorizado) mientras que la disponibilidad y la fiabilidad
se centran ms en evitar fallos en general. Por ello, hay tendencia a agrupar estas dos ltimas
caractersticas y definirlas colectivamente como la evitacin o minimizacin de las cadas de servicio.
Existen otros trminos afines al de confiabilidad y que habitualmente han sido contemplados en el
mbito del desarrollo de software y sistemas informticos, especialmente por la importancia otorgada a la
proteccin ante todo tipo de amenazas en la proteccin de infraestructuras complejas controladas por
sistemas de informacin empotrados. Por una parte, hacemos referencia a trminos como la capacidad
para proporcionar confianza
7
(trustworthiness) y capacidad de supervivencia (survivability). Como se indica
en la referencia de Avizienis [5], el primero omite explcitamente los defectos internos aunque los considera
implcitamente. Tambin dichos defectos son contemplados implcitamente en la capacidad de
supervivencia mediante los fallos de componentes. El trmino de capacidad de supervivencia fue acuado
en mbitos militares en la dcada 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 trminos explcitamente 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 ecuacin: coste = 1/defectos de tal manera que preten-
der cero defectos supone costes inmanejables. Suele trabajarse ms bien con la bsqueda del nivel de riesgo acep-
table equilibrndolo con los recursos y plazos disponibles.
7
La capacidad para proporcionar confianza es muy similar, a efectos de traduccin al espaol, al trmino de confia-
bilidad.
Por otra parte, es habitual el trmino RAMS (Reliability, Availability, Maintainability and Safety), por
ejemplo, en el mbito de software crtico en la Agencia Europea del Espacio (ESA). En el caso de la ESA
[10], el propio trmino de confiabilidad se contempla con una definicin ms restringida que la de la
confiabilidad (limitada a la fiabilidad, disponibilidad y facilidad de mantenimiento) mientras que la proteccin
(safety) se considera aparte.
1.3 Peculiaridades del software
Una de las dificultades para aplicar las tcnicas 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 aos ya que la aplicacin al desarrollo de software no es directa y requiere cuidadosas
adaptaciones (incluso, en algunos casos, no es posible dicha adaptacin, lo que lleva a desechar ciertas
tcnicas).
Las peculiaridades del software se pueden resumir as segn Pressman [11]:
Se desarrolla, no se fabrica en el sentido clsico del trmino. Todo el coste de su produccin se
centra en el diseo de la primera copia, ya que la replicacin de un programa es una tarea trivial.
Se trata de un producto lgico, sin existencia fsica. El verdadero producto del software es el
diseo de una serie de instrucciones para el ordenador. Su existencia en papel (listado) o en soporte
magntico (fichero) no es ms que una representacin en un cdigo o lenguaje de su autntica
naturaleza, las instrucciones. De hecho, est protegido por leyes de propiedad intelectual al igual
que la msica o las obras escritas.
No se degrada o desgasta con el uso. La naturaleza lgica del software permite que permanezca
inalterable por muy intensa que sea su utilizacin. Se puede degradar su representacin magntica
pero no su esencia. Por ello, la reparacin no consiste en devolverlo al estado original en el que
estaba cuando se entreg (como un automvil cuando sale de fbrica). Si hay que repararlo, eso
significa que ya contaba con algn defecto en origen por lo que una correccin significa rectificar
el diseo.
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 pblicamente
declarados (p. ej., la lista de errores conocidos de ciertos paquetes informticos). 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 informtico, 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 produccin se hace an a medida, en vez de emplear
componentes existentes y ensamblarlos, aunque las bibliotecas de funciones o componentes estn
ya cambiando en parte esta situacin.
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 cdigo donde una simple coma es suficiente para alterar enormemente un
programas) es tambin un peligro que hay que controlar.
No obstante, como se comenta en la referencia de Pressman [11] en relacin a la aplicacin de
modelos probabilsticos 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 ejecucin del software es ciertamente
determinstica pero su desarrollo es probabilstico y permanecen muchos tipos de errores residuales. Por
otra parte, slo una pequea parte de los fallos en hardware se deben al desgaste ya que se identifican
hasta cuatro tipos de modos de fallo: mala calidad de fabricacin, errores de diseo, sobrecarga de
componentes y desgaste o edad. Los tres primeros son comunes con el software.
- 18 -
El desarrollo de software confiable supone la utilizacin combinada de un conjunto de 4 tipos de
acciones distintas:
Prevencin de la introduccin u ocurrencia de defectos.
Tolerancia a defectos para entregar el servicio correcto a pesar de su presencia.
Eliminacin de defectos para reducir su nmero o gravedad.
Prediccin de defectos, estimando el nmero actual, la incidencia futura y las consecuencias
probables de los mismos.
A continuacin abordaremos cada una de estas reas de actividad.
2.1 Prevencin de defectos
Este aspecto de la confiabilidad se basa en la utilizacin de los mejores medios y controles durante
el desarrollo de software para prevenir la introduccin de defectos. Dada la amplitud de esta disciplina de
ingeniera de software resumiremos en el apartado 3 los principales medios de actuacin.
Por otra parte, para prevenir otro tipo de defectos como los fsicos de operacin se utiliza el blindaje,
proteccin contra radiaciones, etc. mientras que los defectos de interaccin se previenen mediante
entrenamiento, procedimientos de operacin rigurosos, paquetes infalibles, elementos de gua y ayuda,
etc. Los defectos maliciosos se previenen mediante mecanismos de proteccin como cortafuegos y
defensas similares.
2. MEDIOS PARA OBTENER LA
CONFIABILIDAD DEL SOFTWARE
2.2 Tolerancia de defectos
El trmino (fault tolerance) est inspirado en la preservacin del servicio correcto ante la presencia
de defectos activos. Suele basarse en la deteccin de errores y la correspondiente recuperacin del servicio.
En general, la deteccin de defectos se centra en dos tipos de tcnicas segn Avizienis [5]:
Deteccin concurrente que se produce a la vez que se realiza la entrega del servicio.
Deteccin preventiva que se realiza mientras el servicio est suspendido tratando de
comprobar errores latentes y defectos dormidos.
La recuperacin transforma el estado del sistema que contiene uno o ms 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, segn Avizienis [5], en:
La vuelta atrs (rollback), donde se retorna a un estado (checkpoint) guardado que es previo a
la deteccin del error. Esta operacin suele recaer en el rea de explotacin y no suele implicar
trabajo de desarrollo o mantenimiento de software. Distintas herramientas y tecnologas 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 activacin de defectos localizados. Para ello suele
apoyarse en las siguientes fases:
Diagnstico, que identifica y registra la/s causa/s de error/es tanto en localizacin como en tipo.
Aislamiento del defecto, que supone la exclusin fsica o lgica de los componentes
defectuosos para evitar que participen en la entrega del servicio (es decir, dejar los defectos
dormidos).
Reconfiguracin del sistema, que cambia a componentes de repuesto, o sustitucin, o reasigna
tareas entre los componentes no defectuosos.
Reinicializacin del sistema, que comprueba, actualiza y registra la nueva configuracin y las
nuevas tablas y registros.
- 20 -
Lo normal es que al manejo de defectos le siga un proceso de depuracin o mantenimiento
correctivo
8
, pero el factor que distingue la tolerancia a defectos del mantenimiento es que ste requiere la
intervencin de un agente externo.
Una opcin adicional es el enmascaramiento de defectos que permite la recuperacin del sistema
sin una deteccin explcita de errores. As, una deteccin preventiva de errores (BIST: built-in self-test) ser
posiblemente seguida del manejo de defectos ejecutado al iniciarse el sistema. Tambin de spare checking,
recogida de basura, programas de auditora o el llamado rejuvenecimiento de software, que pretende
eliminar efectos de la edad en las aplicaciones antes de que puedan llevar a fallos.
Elegir tcnicas de deteccin de errores, manejo de errores o manejo de defectos depende del
criterio adoptado durante el diseo para las clases de defectos tolerables. Un mtodo habitualmente
empleado para la tolerancia a defectos es ejecutar varias veces los mismos clculos en distintos entornos
(en general con idntico diseo), de forma secuencial o concurrente, en general. Este enfoque es adecuado
para defectos de diseo esquivos mediante rollback, pero no lo es para los defectos de diseo slidos que
requieren entornos que implementen la misma funcin con diseos e implementaciones distintos: es lo que
se llama diversidad de diseo (design diversity). Como ejemplos de diversidad de diseo se pueden
mencionar el diseo independiente de componentes o la multiplicidad de versiones, entre otros. La
diversidad en el diseo es uno de los elementos propuestos por Randell [13] para la tolerancia a defectos
junto con los bloques de recuperacin, la prevencin 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 reflexin (reflection) de los lenguajes, el uso de la delegacin, etc.
Sin embargo, como se comenta en el clsico libro de Fenton y Pfleeger [14], existen algunos
problemas en esta filosofa. La utilizacin de la implementacin del sistema con varios diseos
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 tambin debe darse durante el desarrollo de software cuando las pruebas detectan defectos en los
productos. El trmino depuracin (debugging) suele aplicarse ms bien a la correccin de cdigo.
independientes de un software han revelado una alta proporcin de defectos comunes por lo que la tcnica
de diversidad de diseo 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 replicacin, comprobadores con
autochequeo, memoria estable para recuperar datos y programas, etc.). En el caso del autochequeo,
Fenton [14] resalta la limitacin de este tipo de controles a un estrecho campo de problemas de tipo
matemtico. Tambin 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 introduccin sistemtica de la tolerancia a defectos se facilita con aplicaciones supervisoras del
software, procesadores de servicios, comunicacin dedicada, etc. Por supuesto la tolerancia a defectos no
debe centrarse exclusivamente en los defectos accidentales sino que es de aplicacin para proteger de
intrusiones o ataques maliciosos mediante la fragmentacin y la dispersin de informacin, y la tolerancia
a lgica malintencionada (virus, etc.) mediante comprobacin del flujo de control o mediante diversidad de
diseo.
2.3 Eliminacin de defectos
La eliminacin se puede producir durante el desarrollo de software o durante la explotacin. Se
define en el glosario de IEEE [1] la depuracin como el proceso de detectar, localizar y corregir defectos.
De las tres fases sealadas, la localizacin del defecto o diagnstico consume la mayor parte (seguramente
un 80%) del esfuerzo necesario para el proceso de depuracin. En cuanto a la deteccin, suele apoyarse
en los conceptos de verificacin y validacin que se tratarn en detalle en el apartado 3 sobre prevencin
en el desarrollo de software:
Verificacin: 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.
Validacin: proceso de evaluar un sistema o componente durante el desarrollo, o al final del
mismo, para determinar si satisface los requisitos especificados.
- 22 -
Boehm resumi estas definiciones con las expresiones construimos correctamente el producto
software? o construimos el producto software correcto?. Insistiremos ms en el apartado 3 sobre el
papel de estas actividades (resumidas habitualmente como V&V) en la prevencin de defectos durante el
desarrollo de software.
En cuanto al proceso de depuracin puede surgir mediante la deteccin de defectos por resultados
de aplicacin de las distintas tcnicas de verificacin y/o validacin
9
, o por informes de explotacin, clientes,
etc. Durante el desarrollo es habitual la conexin entre depuracin y pruebas cuando los defectos se refieren
a la implementacin de cdigo (ver fig. 7) como se indica en la referencia de Piattini et al. [15]. Los casos
de prueba diseados para comprobar el software se ejecutan en el ordenador y se obtienen resultados.
Dichos resultados se analizan para la bsqueda de sntomas de defectos (errores) en el software. Esta
informacin se pasa al proceso de depuracin para obtener las causas del error (defecto). En caso de
conseguirlo, se corrige el defecto; en caso contrario se llevarn a cabo nuevas pruebas que ayuden a
localizarlo, reduciendo en cada pasada el posible dominio de existencia del defecto. Tras corregir el defecto,
se efectuarn nuevas pruebas que comprueben si se ha eliminado dicho problema.
- 23 -
9
Como se ver en el apartado suelen ser bsicamente las pruebas y las revisiones y auditorias aunque existen otras
en el amplio catlogo de tcnica de V&V.
Figura 7. Ciclo de pruebas y depuracin
La depuracin no es un proceso trivial y deben contemplarse algunas recomendaciones para
obtener los mejores resultados. En el caso del diagnstico y localizacin del defecto, se pueden indicar los
siguientes consejos de Myers [16]:
Analizar la informacin y pensar. La depuracin es un proceso mental de resolucin de un
problema y lo mejor para el mismo es el anlisis. No se debe utilizar un enfoque aleatorio en la
bsqueda 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 solucin.
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 depuracin (depuradores, trazadores de ejecucin, etc.) slo como recurso
secundario. Deben ayudar al anlisis 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 an ms la
depuracin.
Se debe fijar la atencin tambin en los datos manejados en el programa y no slo en la lgica
del proceso.
En cuanto a la fase de correccin, Myers sugiere lo siguiente [16]:
Donde hay un defecto, suele haber ms. Es una conclusin obtenida de la experiencia. Cuando
se corrige un defecto se debe examinar su proximidad inmediata buscando elementos sospechosos.
Debe fijarse el defecto, no sus sntomas. Lo que debe corregirse y desaparecer es el defecto, no
se trata de intentar enmascarar sus sntomas.
La probabilidad de corregir perfectamente un defecto no es del 100%. Por lo tanto, se deben
revisar las correcciones antes de implantarlas (mediante tcnicas de revisin: walkthroughs,
- 24 -
inspecciones, revisiones, etc. antes de la correccin). Despus de la correccin, se utilizan pruebas
especficas de regresin.
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) segn
algunos estudios.
La correccin debe situarnos temporalmente en la fase de diseo. Hay que mentalizarse de que
se reinicia el diseo de la seccin de cdigo defectuoso y no slo se retoca el cdigo.
Cambiar el cdigo fuente, no el cdigo objeto. Cambiar el cdigo objeto provoca:
~Experimentacin indeseable.
~Falta de sincronizacin fuente-objeto.
2.4 Prediccin de defectos
La prediccin de defectos se realiza mediante la evaluacin del comportamiento del sistema en
cuanto a ocurrencia o activacin de defectos. Se plantea bajo dos aspectos segn Avizienis [5]:
Evaluacin 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 podran llevar
a fallos del sistema.
Evaluacin cuantitativa o probabilstica que pretende evaluar en trminos de probabilidades la
extensin en que se satisfacen los atributos de confiabilidad; dichos atributos pueden verse como
medidas de confiabilidad.
Los mtodos de evaluacin para ambos aspectos pueden ser especficos (por ejemplo, modo de
fallo o anlisis de efectos para evaluacin cualitativa o cadenas de Markov y Redes de Petri estocsticas
para evaluacin cuantitativa) o pueden ser indiferentemente usados para ambos tipos de evaluacin (por
ejemplo, diagramas de bloques de fiabilidad, rboles de defectos).
La evolucin 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 nmero de fallos por unidad de tiempo) como medida de
la frecuencia de fallos segn la percibe el usuario. Tpicamente esta intensidad decrece (crecimiento de
fiabilidad), luego se estabiliza y despus de un cierto tiempo de operacin 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 trminos 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 cado. Ambos correspondern con el total de tiempos observados de cada clase:
La disponibilidad es una funcin del tiempo y se asume que es 1 en t0, decreciendo
posteriormente hasta un estado estable despus de varios ciclos fallo-reparacin. De hecho, la teora de
fiabilidad y confiabilidad suele centrarse en el estudio de estado estable aunque tambin se analiza el
perodo 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 poblacin
estudiada.
Ratio de uptime (entrega de servicio correcto) respecto de la suma de tiempos up y down (frmula
anterior).
- 26 -
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 nmero de fallos. Sin embargo, veremos
ms adelante los modelos de fiabilidad ms adaptados a la problemtica del software que podrn facilitar
estas estimaciones.
En cuanto a la facilidad de mantenimiento, se aplica la medicin del tiempo hasta la restauracin
del servicio (normalmente indicado como MTTR: Mean Time To Repair) o su equivalente de medida de
servicio incorrecto continuo.
El caso de la proteccin (safety) se considera una extensin de la fiabilidad segn la referencia de
Avizienis [5]. As mismo, cuando el estado del servicio correcto y los estados de servicio incorrecto debido
a fallos no catastrficos se agrupan en un estado seguro (en el sentido de estar libre de daos catastrficos
no de peligro), se mide la proteccin como proteccin continua o con su equivalente en tiempo de fallo
catastrfico. Por eso, la proteccin es la fiabilidad respecto de los fallos catastrficos.
En general, un sistema entrega diversos servicios y se contemplan dos o ms 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 nocin de capacidad de rendimiento (performability). Existen
dos enfoque principales para la prediccin probabilstica de defectos (que pretende derivar estimacin en
trminos de probabilidad de las medidas de confiabilidad), segn el trabajo de Avizienis [5]:
Modelado
Prueba y evaluacin
- 27 -
Estos enfoques son complementarios, ya que el modelado requiere datos de los procesos bsicos
modelados (proceso de fallo, proceso de mantenimiento, proceso de activacin, 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 prediccin 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 deberan converger en un sistema integrado de seguimiento de
defectos (defect-tracking) que suele enlazarse con la gestin de cambios y configuraciones; de hecho, en
organizaciones donde la gestin de configuracin ya controla los cambios realizados, la estadstica de
defectos se gestiona mediante estos mecanismos de control.
Cuando se evalan sistemas tolerantes a defectos, la cobertura proporcionada por los mecanismos
de manejo de errores y defectos tiene una drstica influencia sobre las medidas de confiabilidad. La
evaluacin de la cobertura se realizar a travs de modelado o a travs de pruebas, es decir, insercin de
defectos (fault-injection). Esta tcnica se basa en analizar los efectos de defectos insertados en el sistema
a travs de un modelo de simulacin o un prototipo implementado [17].
2.4.1 Modelos de fiabilidad
Para aportar una panormica rpida de los modelos relacionados con la fiabilidad del software,
debemos comenzar aclarando que el uso de los mismos siempre pasar por dos fases segn Fenton [14]:
1. Seleccin del modelo ms apropiado ajustndolo si hace falta.
2. Estimacin de los valores de los parmetros necesarios usando los valores ms probables de datos
disponibles.
El modelo ms sencillo, y uno de los primeros, para software es el Jelinski-Moranda [17]. En este
modelo se asume que la distribucin de probabilidad de fiabilidad es:
donde N es el nmero inicial de defectos y f es la contribucin de cada defecto a la tasa global de
defectos.
- 28 -
Las principales limitaciones del modelo surgen de los siguientes 3 hechos segn 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 precisin 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 ejecucin, aunque incluye tambin tiempo de calendario
para conectar con la gestin de proyecto.
Sin embargo, los modelos ms ajustados suelen incluir un aspecto doblemente estocstico ya que
tambin consideran que la contribucin de cada defecto es distinta. Los defectos que ms 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 tamaos, a diferencia de lo que ocurra en el de Jelinski-Moranda.
Como se indica en el trabajo de Fenton y Pfleeger [14], como slo se mide en funcin 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 precisin 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 automticas que facilitan mucho los arduos clculos que suponen los ajustes y la
aplicacin de los modelos.
En cualquier caso, hay que recordar que, como indica Fenton [14], slo funcionan correctamente
si el entorno futuro de operacin 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
filosofa es el de Cleanroom Method para desarrollo de software presentado por Dyer [22], donde se incluye
- 29 -
una estrategia de pruebas estadsticas basadas en seleccionar casos de pruebas en funcin 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 aos de operacin 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 ms por ms fiabilidad (ver figuras 8.a y 8.b).
- 30 -
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 fabricacin de
otros productos. Adems de las diferencias intrnsecas entre el software y otros productos (ver apartado 1.3)
tambin la manera de trabajar ha sido tradicionalmente distinta de los procesos ms tradicionales de
fabricacin como se explica en el IEEE [6]. Esta es la causa de que los mtodos y tcnicas aplicables para
la mejora de calidad en el software, no hayan podido resolverse con una inmediata traslacin de las
prcticas maduras existentes en otros sectores de fabricacin. El resultado ha sido la necesidad de realizar
un gran esfuerzo en la adaptacin fiable de dichas tcnicas a la realidad del software as como la creacin
de modelos y mtodos especficos para la actividad de desarrollo.
En general, la gestin de proyectos de desarrollo debera 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 lneas actuales de trabajo para la mejora de la calidad y prevencin de defectos en el software
y los sistemas podran clasificarse de acuerdo a su focalizacin principal en alguno de los elementos del
modelo anterior. Podemos presentar las principales lneas actuales en mejora de la calidad del software en
funcin del anlisis 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, podramos hablar de:
La formacin acadmica y los estudios de preparacin profesional: el autor ha realizado estudios
detallados de los requisitos exigidos en ofertas de empleo donde se puede constatar la evolucin
de conocimientos tcnicos y, sobre todo, la necesidad de competencias personales bsicas (trabajo
en equipo, comunicacin, etc.).
La cualificacin especfica en entornos, lenguajes, tipo de aplicaciones, etc. en buena parte ligada
a la experiencia en cada mbito.
El despliegue de buenas prcticas personales de desarrollo a travs de mtodos como PSP
presentado por Humphrey [26] pueden influir en la productividad y la calidad.
La motivacin y la cultura de calidad, el amor por el trabajo bien hecho, etc. que, tambin, suelen
ser dependientes de una actitud respetuosa con una tica profesional como la marcada en el cdigo
de IEEE [27].
Existen anlisis 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 tpico ejemplo
es el de Abdel-Hamid y su dinmica 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 -
la calidad, mucho mayor que la proporcin de ganancia de los factores positivos. En consecuencia, la
mxima de que las personas son nuestro principal activo se revela an ms cierta en los desarrollos de
software, al menos en lo que respecta a no tratar de ahorrar demasiado en este concepto.
Tambin existen otras reglas bsicas sobre la influencia de los recursos humanos en los proyectos.
Por ejemplo, se sabe que en un proyecto retrasado, incorporar ms personal supone retrasarlo ms como
se demuestra en Brooks [29]. De forma ms radical, tambin 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 Evolucin y mejora tecnolgica
Se trata de una opcin evidente para la mayora de los profesionales, dada la actividad comercial
generada respecto de las nuevas opciones tecnolgicas que surgen constantemente. En este sentido,
podemos resear no slo las opciones ms comentadas de evolucin (sistemas operativos, plataformas,
lenguajes etc.) sino la mejora de funcionalidad y de integracin entre las herramientas del desarrollador
(CASE para las distintas actividades y fases, IDEs, entornos visuales, etc.). Tambin deben contemplarse
los cambios de modelos y paradigmas (por ejemplo, la evolucin desde el desarrollo procedimental
tradicional a los entornos de orientacin 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 -
Las organizaciones suelen estar ms concienciadas en gastar en herramientas (>50%) que en
otras medidas, seguramente ms eficaces segn 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 ms 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
bsicas.
Resulta de gran importancia que las herramientas sean apropiadas y que se integren bien en la
organizacin de desarrollo a travs de formacin, de adaptacin a las necesidades de los desarrolladores,
del entorno tcnico y con otras herramientas ya existentes. El uso de CASE efectivo incrementa la
productividad en un 27%, pero la incorporacin inadecuada de herramientas puede disminuir la
productividad en un 75% segn los datos de Jones [24]
En general, como indica McConnell en [31] suele ocurrir que el mercado de tecnologas 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
formacin, etc. Incluso Jones en [33] considera poco crebles las afirmaciones en el 75% de la publicidad
y que, tras revisar 4000 proyectos, el 70% de los responsables crean que un nico factor como ste podra
proporcionar grandes mejoras. En cierto modo, esto enlaza con recurrentes noticias sobre la desaparicin
de la figura del programador. Ya se sugera al aparecer el lenguaje ensamblador y perdura hasta nuestros
das: en 2006 se publi que en 2008 las nuevas herramientas de desarrollo harn desaparecer dicho puesto.
3.3 Mejora de procesos de desarrollo
La mejora de las tcnicas y mtodos de desarrollo pasa por la intervencin en distintos planos de
actuacin dentro de la organizacin de desarrollo. Por una parte, a nivel de procesos y desde una
perspectiva global, debemos mencionar las iniciativas de evaluacin y mejora de procesos como CMMi
[34], ISO 15504 SPICE [35], etc. En este caso, el foco de atencin se centra en la organizacin de
actividades guiada o impulsada desde los responsables de la empresa. Por supuesto, la ordenacin de
procesos que provoca ISO 9001 [36] es tambin una forma de actuar desde el plano de los procesos.
En otro plano de actuacin podemos situar la adopcin de estndares, metodologas y tcnicas.
Propuestas como estndares, ciclos de vida (espiral, etc.) o procesos de desarrollo (RUP [37], extremme
programming [38], etc.), metodologas 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 anlisis de datos rigurosos que cuantifiquen y aclaren la influencia de los mismos sobre los productos
finales.
La mejora de procesos de software tiene una relacin directa y bastante clara con la obtencin de
beneficios en cuanto a ROI, productividad y calidad. De hecho, el modelo CMM [40] siempre se ha vinculado
a resultados de disminucin de riesgos e incremento de calidad y productividad. En este sentido, podemos
citar la mejora producida en la propia evaluacin de los procesos desde los resultados de 1992 a 2003
registrados por el SEI [41] as como los resultados de reduccin 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 mtodos de mejora de procesos como SPICE-ISO 15504 o de iniciativas como ISO 9001 (en este
caso, quizs ms eficaz en estabilizar estndares en los procesos ms que conseguir mejoras de
resultados).
Por ltimo, fuera de los modelos de mejora habituales, las mejoras en tcnicas de desarrollo,
metodologas, herramientas, etc. deben apoyarse en mediciones y evaluaciones apropiadas dentro de cada
entorno y empresa de aplicacin. En este sentido, es imprescindible usar mtodos de valoracin
contrastados como DESMET [43].
- 38 -
3.4 Mejora de procesos de aseguramiento de calidad de software
Tradicionalmente, por incorporacin de la normativa genrica de calidad, el establecimiento de
sistemas de calidad corporativos basados en ISO 9001 [11] ha sido una opcin 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 adaptacin 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 inters 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 estabilizacin de procesos y resultados. Tambin
ha servido para establecer unos mnimos en la aplicacin del aseguramiento de calidad como medio de
proporciona confianza a los desarrolladores y a los clientes sobre la sistemtica de trabajo en los proyectos.
A nivel de proyecto, el trabajo se suele apoyar en una planificacin especfica (aunque coherente
con el sistema de calidad u otras normas aplicables) a travs de un plan de aseguramiento de calidad de
software. Si adoptamos el correspondiente estndar IEEE, el 730 [45], como referencia, las tcnicas
incluidas para los proyectos se corresponden con las ms tradicionales y usadas: gestin de configuracin
(como elemento clave de control de los productos), medicin (para evaluacin completa de procesos y
productos) as como verificacin y validacin (principalmente basadas en aplicacin de pruebas y de
procesos de revisin y auditora). Por supuesto existen catlogos ms extensos de tcnicas (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 tcnicas de verificacin y validacin
- 40 -
Pruebas de software
De manera breve, debemos recordar que las pruebas de software deberan ceirse al ciclo de
pruebas propuesto en el estndar IEEE 1008 [48] (ver fig. 10). El diseo de casos de prueba est totalmente
mediatizado por la imposibilidad de probar exhaustivamente el software. Pensemos en un programa muy
sencillo que slo suma dos nmeros enteros de dos cifras (del 0 al 99). Si quisiramos probar, simplemente,
todos los valores vlidos que se pueden sumar deberamos probar 10.000 combinaciones distintas de cien
posibles nmeros del primer sumando y cien del segundo. Pensemos que an quedaran por probar todas
las posibilidades de error al introducir los datos (p. ej. teclear una letra en vez de un nmero). Tampoco
podemos pretender analizar todos los posibles caminos de ejecucin por el programa que son tambin
impracticables. Si para un programa tan elemental debemos realizar tantas pruebas, podemos imaginar lo
que supondra un programa de tamao real.
En consecuencia, las tcnicas de diseo de casos de prueba tienen como objetivo conseguir una
confianza aceptable en que se detectarn los defectos existentes (ya que la seguridad total slo 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 ejecucin). 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 difcil y que est lejos de parecerse a la imagen de actividad rutinaria que suele sugerir.
Figura 10. Cilco completo de pruebas definido en el estndar IEEE [48]
Ya que no se pueden probar todas las posibilidades de funcionamiento del software, la idea
fundamental para el diseo de casos de prueba consiste en elegir algunas de ellas que, por sus
caractersticas, 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 eleccin
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 eleccin 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
nmeros, 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 eleccin que
veremos a continuacin.
Existen tres enfoques principales para el diseo de casos como indica Myers [49]:
El enfoque estructural o de caja blanca
11
(vase la figura 11). Consiste en centrarse en la
estructura interna (implementacin) del programa para elegir los casos de prueba. En este caso, la
prueba ideal (exhaustiva) del software consistira en probar todos los posibles caminos de ejecucin,
a travs de las instrucciones del cdigo, que puedan trazarse.
El enfoque funcional o de caja negra
12
(vase la figura 11). Consiste en estudiar la especificacin
de las funciones, la entrada y la salida para derivar los casos. Aqu, la prueba ideal del software
consistira en probar todas las posibles entradas y salidas del programa.
El enfoque aleatorio consiste en utilizar modelos (en muchas ocasiones estadsticos) que
representen las posibles entradas al programa para crear a partir de ellos los casos de prueba. La
prueba exhaustiva consistira en probar todas las posibles entradas al programa.
Estos enfoques no son excluyentes entre s ya que se pueden combinar para conseguir una
deteccin de defectos ms eficaz. Veremos a continuacin una presentacin de cada uno de ellos.
11
En ingls, white box testing. Sin embargo, la denominacin caja blanca no es afortunada ya que se trata de una
caja transparente, que permite ver su interior. Recientemente, la mayora de autores ya utiliza la expresin prueba
de caja de cristal (Glass box testing).
12
En ingls, black box testing
Por ltimo, es importante recordar que la aplicacin de las pruebas durante el desarrollo de software
se realiza a travs 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 diseo de pruebas de caja blanca y de caja negra
Figura 12. Estrategia de aplicacin de pruebas en el desarrollo de software
Tcnicas de revisin y auditora
Son tcnicas de verificacin y validacin que permiten la evaluacin y el anlisis de productos
generados durante el desarrollo y que no pueden ser ejecutados. Esto es esencial para la filosofa de
aseguramiento de calidad del software puesto que la deteccin temprana de problemas y la inexistencia
de pruebas definitivas obliga a controlar paso a paso los productos generados en el proceso de
desarrollo. Adems esta filosofa es econmicamente rentable como se puede ver en la tabla 4.
Tabla 4. Correccin de un defecto segn la fase de desarrollo
Figura 13. Enfoque integral de aseguramiento de calidad del software
- 44 -
Para ello disponemos de diversos mtodos (ver tabla 5).
Las revisiones y auditoras se pueden utilizar para revisar tanto procedimientos de gestin del
proyecto como productos derivados del desarrollo o productos intermedios
13
. Se trata de documentos que
se comunican o entregan al cliente o al equipo de desarrollo
14
, que se producen o adquieren durante el
desarrollo o mantenimiento del software; por ejemplo, documentos de planificacin del proyecto (como
planes de desarrollo de software o planes de verificacin y validacin del software), especificaciones de
requisitos software, descripciones de diseo, cdigo fuente, etc. En la figura 14 vemos sobre qu se enfocan
los distintos mtodos.
Tabla5. Verificacin y validacin segn IEEE 1028
13
Tambin pueden encontrarse en la literatura anglosajona con los trminos work unit y software element.
14
En ingls, deliverables.
Figura 14. Enfoque de las distintas tcnicas de V&V
Otras tcnicas 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 ms concretas entre
las distintas variantes de revisin: revisiones de gestin, revisiones tcnicas, walkthroughs e inspecciones.
Hay que considerar aparte las auditoras de software, ya que presentan muchas diferencias de
proceso con las revisiones. Adems, se pueen utilizar para examinar tanto el proyecto como los productos
intermedios (ver tabla 6).
En cuanto a la recomendacin de utilizacin de estas tcnicas en los proyectos de desarrollo, se puede
aadir la lista incluida en el estndar IEEE 1012 [53] que se presenta en la tabla 7. Esta es una
recomendacin para software crtico que puede adaptarse a cada proyecto segn su nivel de riesgos.
Tabla 4. Comparativa entre revisiones y auditoras segn [50]
- 46 -
Tabla 7. Recomendacin de revisiones y auditoras segn IEEE 1012 [53]
Quizs el proceso ms formalizado de todos los de revisin es el de inspeccin. Las fases tpicas
de un proceso de inspeccin se resumen en la figura 15. Puede apreciarse que, al igual que en el resto de
procesos de revisin, se generan listas de defectos identificados que permiten el seguimiento para los
distintos aspectos de confiabilidad abordados en apartados anteriores.
Para que una inspeccin tenga xito debe seguir ciertas reglas:
Las inspecciones se realizan en un determinado nmero de puntos del ciclo de vida, tanto en el
proceso de planificacin del proyecto como en el proceso de desarrollo del sistema.
Se inspeccionan todas las clases de defectos posibles en todos los tipos de documentacin (no
slo errores lgicos o funcionales).
Figura 15. El proceso de inspeccin
(estndares, guas y procedimiento)
- 48 -
Participacin en las inspecciones: pares y personal de todos los niveles jerrquicos exceptuando
la alta direccin.
Las inspecciones se deben realizar en una serie predefinida y estricta de etapas.
La duracin de las reuniones no deber exceder las dos horas .
Las inspecciones deben ser dirigidas por moderadores entrenados y experimentados (a travs de
prcticas en inspecciones) para lograr eficacia en su trabajo.
Los miembros del equipo de inspeccin tienen asignados papeles especficos para incrementar
su efectividad.
Se usan listas de comprobacin para que los miembros del equipo de inspeccin tengan su tarea
definida y para incrementar el descubrimiento de los defectos.
Mtricas y evaluacin de calidad
La evaluacin de la calidad del software se basa en la utilizacin 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 ms variantes hasta la aparicin de los estndares actuales (principalmente ISO 9126 [2]:
ver figura 17). Todos ellos descomponen la calidad en sub-caractersticas ms fciles de medir o evaluar.
Figura 16. Modelo de evaluacin 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 funcin de las
necesidades expresadas para el cliente o usuario del software. Eso implica ponderar los distintos
factores y marcar criterios para su medicin con valores umbrales de aceptacin.
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 relacin inversa con la portabilidad del software ya que la eficiencia mxima suele exigir utilizar
todos los recursos propios de cada plataforma.
La evaluacin de cada caracterstica debe apoyarse en mtricas de software lo ms objetivas
posible y que estn validadas. La validacin en el mbito de la medicin significa poder demostrar
que una mtrica realmente mide lo que dice medir. El problema habitual es que existen mtricas
conocidas que no siempre cuentan con validacin adecuada. Para una panormica general de la
medicin de software y sobre la problemtica de la validacin, es recomendable consultar el libro
de Fenton y Pfleeger [14].
Figura 17. Modelo estndar ISO 9126 para evaluacin de calidad de software
- 50 -
Otras consideraciones sobre aseguramiento de calidad
Es importante recordar que estas tcnicas son caras y que su uso debe adaptarse a cada entorno
tanto para ser eficaz (incorporndose con facilidad a la vida diaria del equipo de desarrollo) como para ser
ms eficiente y rentable. Por ejemplo, los procesos de revisin de todo el cdigo de una aplicacin suelen
ser inabordables por su coste. Para buscar mayor eficiencia, se suele establecer unos anlisis previos con
herramientas basados en patrones de mtricas y reglas a cumplir. Aplicando el principio de Pareto, la
empresa slo aplica inspecciones a los trozos de cdigo ms crticos o con peores evaluaciones en dicho
anlisis para concentrar el esfuerzo disponible en los mdulos que puedan acumular ms defectos y ms
peligrosos. Otra tctica, que puede ser complementaria, consiste en disminuir esfuerzo automatizando
tareas de evaluacin con herramientas y disminuyendo el nmero de revisores implicados.
En cualquier caso, la aplicacin 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 aos ochenta, los programas corporativos pioneros en Hewlett-Packard [56] demostraron
cmo se podan compatibilizar actividades de aseguramiento de calidad, medicin de resultados y objetivos
corporativos basados en la rentabilidad, disminucin de break-even time y reduccin de defectos. La
reduccin de defectos supone un ahorro de costes debido a los ya mencionados costes de la mala calidad:
retrabajo, indemnizaciones, prdida de imagen. Como ya descubri IBM hace tiempo y se describe en [55],
cada dlar dedicado a prevencin supone el ahorro de 50 dlares despus. Por ello, el aseguramiento
debe ser especialmente insistente en proporcionar medios de deteccin y correccin temprana de defectos
(ver tabla 2).
Algunas ideas sobre el mantenimiento de software
La eliminacin 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
ms errores y que han sido reportados mientras que el mantenimiento preventivo pretende descubrir y
eliminar defectos antes de que puedan causar errores durante la operacin normal del sistema. Entre estos
ltimos defectos se podran incluir tanto defectos fsicos que hayan ocurrido despus del ltimo
mantenimiento preventivo como defectos de diseo que hayan llevado a errores en otros sistemas similares.
Las tcnicas y consejos ya explicados en el apartado 2.3 se aplican ms al mantenimiento
correctivo. Por otra parte, en el software se contemplan distintas estrategias y tcnicas para facilitar los
distintos tipos de mantenimiento: por ejemplo, ingeniera inversa, reingeniera, anlisis de cdigo,
recuperacin de diseo, reestructuracin, etc. Una buena explicacin de las mismas se encuentra en el libro
de Piattini et al. [15]. La mayora de estas tcnicas ha recibido un impulso importante gracias a la existencia
de herramientas automaticas que asisten en el proceso de anlisis y recuperacin de informacin para el
mantenimiento a partir del cdigo de la aplicacin.
- 52 -
4. ALGUNAS CONSIDERACIONES
ADICIONALES
En el mbito de la confiabilidad tambin se menciona el concepto de capacidad de supervivencia
(survivability), surgido principalmente a finales de los aos sesenta y principios de los setenta del siglo XX
en estndares 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 misin segn
indica Avizienis [5]. La confiabilidad ha evolucionado desde los conceptos de fiabilidad y disponibilidad a
travs de la evolucin tecnolgica de la informtica y de las comunicaciones para dar respuesta adecuada
a los desafos de aplicaciones en red y la necesidad creciente de confianza en la informtica ubicua. As,
la capacidad de supervivencia entendida como capacidad de un sistema para continuar con su misin en
presencia de ataques, fallos o accidentes, ha evolucionado desde los asuntos de pura seguridad y ha
ganado inters debido a la frecuencia y gravedad de ataques de adversarios inteligentes sistemas de
informacin crticos. Desde la perspectiva de la confiabilidad la capacidad de supervivencia es la
confiabilidad en presencia de defectos activos de todo tipo. La relacin 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 prevencin de
defectos.
Reconocimiento: capacidad de reconocer ataques y la extensin de los daos.
Recuperacin: 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 caractersticas van ms 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, Ingeniera del software. Un enfoque prctico, 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. Fernndez, Anlisis y diseo de aplicaciones informticas
de gestin, Un enfoque de ingeniera 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. Fernndez, Requisitos para el empleo en Nuevas Tecnologas de la Informacin: el estudio
RENTIC, Novtica, n161, 2003, pp. 51-56.
[26] W.S. Humphrey, Introduccin al proceso software personal. Addison-Wesley, Madrid, 2001.
[27] L. Fernndez y M. J. Garca, 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.
- 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 gestin de proyectos informticos. Cmo 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 gestin 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 explicacin de la programacin 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. Ingeniera del software. Gua de aplicacin 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. Daz 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).
- 58 -
- 59 -
Luis Fernndez Sanz es licenciado en informtica por la Universidad Politcnica de Madrid (1989)
y doctor en informtica por la Universidad del Pas Vasco (1997) con Premio Extraordinario de Doctorado.
Ha sido profesor en la Facultad de Informtica de la Universidad Politcnica de Madrid (1989-1996) en las
reas de ingeniera de software y de sistemas de informacin. En 1996 se integra en la Universidad Europea
de Madrid (UEM) centrado en las reas de ingeniera del software y programacin. En 2000 fue nombrado
profesor titular y en el perodo 2000-06 fue director de uno de los departamentos del rea de informtica.
Actualmente, es profesor en el Departamento de Ciencias de la Computacin de la Universidad de Alcal.
En 2005 recibi el 1
er
Premio en la segunda edicin de los Premios de Innovacin Docente de la UEM. Ha
sido profesor o docente invitado en diversos master y postgrados de universidades de toda Espaa, adems
de intervenir como director o profesor en ms de 30 cursos sobre ingeniera 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 ingeniera y la calidad del software. As, ha dirigido y participado en diversos proyectos de
consultora y servicios para entidades como Ministerio de Asuntos Exteriores, Meta4, France Telecom,
Vodafone, etc. y tambin ha dirigido como administrador nico una pequea compaa de servicios de
desarrollo de software. Tambin ha dirigido o participado en diversos proyectos de I+D financiados tanto por
entidades pblicas como privadas. Ha sido autor o coautor de diversos libros de texto y de investigacin
tanto en espaol como en ingls relacionados con la ingeniera y la calidad del software adems de
numerosas comunicaciones en congresos y artculos de revista en mbito nacional e internacional.
Desde 1993 es coordinador de la Seccin de Ingeniera del Software de la revista Novtica
(www.ati.es/novatica). En 2005 lanz la Revista Espaola de Innovacin, Calidad e Ingeniera del Software
(www.ati.es/reicis) de la que es editor. Tambin coordina el grupo de Calidad del Software de ATI desde 2000
siendo responsable de la organizacin de sus sesiones tcnicas y de las Jornadas de Innovacin y Calidad
del Software.
6. SOBRE EL AUTOR

Fundamentoconfiabilidad 1286753198 Phpapp02

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Fundamentoconfiabilidad 1286753198 Phpapp02

Transféré par

Droits d'auteur :

Formats disponibles

PRIMERA EDICIN: 2008

ASOCIACIN ESPAOLA PARA LA CALIDAD

Vous aimerez peut-être aussi