Fundamentos de Confiabilidad en el desarrollo del software

  • 12,831 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
12,831
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
406
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. PRIMERA EDICIÓN: 2008 ASOCIACIÓN ESPAÑOLA PARA LA CALIDAD Claudio Coello 92 28006 Madrid www.aec.es publi@aec.es ISBN: 978-84-691-6898-1 Este librose publica bajo licencia Creative Commons del tipo: “Reconocimiento-NoCormercial-SinObraDerivada”. Se permite su copia y distribución por cualquier medio siempre que mantenga el reconocimiento de sus autores, no se haga uso comercial de las obras y no realice ninguna modificación de ellas. La licencia completa puede consultarse en: http://creativecommons.org/licenses/by-nc-nd/2.5/es/legalcode.es
  • 2. 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. Comité de Confiabilidad -3-
  • 3. FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN Con el deseo de que esta publicación contribuya, desde la humildad con la que debe plantearse cualquier acción humana, a ampliar la inacabable senda del conocimiento y desde el agradecimiento al autor por su meritorio y ejemplar esfuerzo, les presentamos esta publicación. Siguiendo nuestro deseo de mejora continua, la AEC está interesada en conocer su opinión, comen- tarios o sugerencias acerca de esta publicación. Para ello, no dude en enviarnos todos sus comentarios a la siguiente dirección de correo electrónico: publi@aec.es. Antonio José Fernández Pérez Presidente del Comité de Confiabilidad Doctor Ingeniero Industrial -4- Comité de Confiabilidad
  • 4. ÍNDICE 1. Introducción 7 1.1 Definiciones sobre amenazas: defectos, errores y fallos 9 1.2 Atributos de la confiabilidad 13 1.3 Peculiaridades del software 17 2. Medios para obtener la confiabilidad del software 17 2.1 Prevención de defectos 17 2.2 Tolerancia de defectos 18 2.3 Eliminación de defectos 20 2.4 Predicción de defectos 23 2.4.1 Modelos de fiabilidad 26 3. Calidad en el desarrollo del software 31 3.1 Mejora en los recursos humanos 32 3.2 Evolución y mejora tecnológica 33 3.3 Mejora de procesos de desarrollo 34 3.4 Mejora de procesos de aseguramiento de calidad de software 36 4. Algunas consideraciones adicionales 53 5. Referencias 55 6. Sobre el autor 59 Comité de Confiabilidad -5-
  • 5. FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN -6- Comité de Confiabilidad
  • 6. 1. INTRODUCCIÓN El concepto de confiabilidad es habitual en los diversos sectores industriales y también en el ámbito del diseño y desarrollo de sistemas. Sin embargo, no ha sido tan ampliamente aplicado en una gran parte del desarrollo de software ya que sólo ciertos sectores que trabajan con sistemas críticos (por ejemplo, el aeroespacial, el de defensa, el de transporte, etc.) han profundizado en el análisis de la dependability y de las técnicas específicas para su consecución y evaluación. Desde el punto de vista de la ingeniería del software se suele integrar cualquiera de las características relacionadas con la “bondad” del producto bajo el ámbito de la calidad del software. No obstante, el concepto de confiabilidad (dependability) no se ha establecido como concepto diferenciado en los diccionarios de términos de ingeniería de software o en los modelos de evaluación de calidad mediante árboles de descomposición de características. Así, el estándar IEEE Std. 610 [1] no contempla el término dependability. En cuanto a los modelos de calidad estandarizados como ISO 9126 [2] (y, por supuesto, ISO 14598 [3]) no se opta por la característica de confiabilidad sino que, como factor de primer nivel, se menciona la fiabilidad (reliability). En general, se toma como referencia la obra de J.C.Laprie [4] a la hora de definir y establecer los principios de la confiabilidad en el software. Así, se define confiabilidad como “la propiedad de un sistema informático que nos permite tener justificadamente confianza sobre el servicio que proporciona”. En el trabajo de Avizienis et al. [5] se aclara que dicho servicio es el comportamiento del sistema tal como el usuario lo percibe bien sea una persona, otra aplicación o sistema que interactúa mediante la interfaz. Se considera que el adjetivo “confiable” abarca varios aspectos: Respecto de estar preparado para el uso, significa “disponible” (availability). Respecto de continuidad de servicio, significa “fiable” (reliable). Respecto de eludir consecuencias catastróficas, significa fuera de peligro (safe) Respecto de la prevención de acceso y/o manejo de información no autorizados, significa “seguro” (secure). Comité de Confiabilidad -7-
  • 7. FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN 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 -8- Comité de Confiabilidad
  • 8. 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 del servicio (service restoration) es la transición inversa: de incorrecto a correcto. El período intermedio se denomina caí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 los años cuarenta/cincuenta donde un insecto es la causa de los fallos aleatorios de funcionamiento al quedar atrapado en su interior. Comité de Confiabilidad -9-
  • 9. FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN 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). Figura 2. Cadena causal que relaciona error, defecto y fallo 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). - 10 - Comité de Confiabilidad
  • 10. Figura 3. Propagación de errores a través del sistema 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 4. Esquema de clasificación de fallos Comité de Confiabilidad - 11 -
  • 11. FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN 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 - 12 - Comité de Confiabilidad
  • 12. 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. Comité de Confiabilidad - 13 -
  • 13. FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN 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]. - 14 - Comité de Confiabilidad
  • 14. 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. Figura 6. Sinergia y antagonismo entre factores de calidad en el modelo de Mc Call et al. 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 Comité de Confiabilidad - 15 -
  • 15. FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN 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. - 16 - Comité de Confiabilidad
  • 16. 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. Comité de Confiabilidad - 17 -
  • 17. FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN 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. - 18 - Comité de Confiabilidad
  • 18. 2. MEDIOS PARA OBTENER LA CONFIABILIDAD DEL 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. Comité de Confiabilidad - 19 -
  • 19. FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN 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. - 20 - 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 los productos. El término depuración (debugging) suele aplicarse más bien a la corrección de código. Comité de Confiabilidad - 21 -
  • 21. FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN 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. - 22 - Comité de Confiabilidad
  • 22. 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. Figura 7. Ciclo de pruebas y depuración 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. 9 Como se verá en el apartado suelen ser básicamente las pruebas y las revisiones y auditorias aunque existen otras en el amplio catálogo de técnica de V&V. Comité de Confiabilidad - 23 -
  • 23. FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓ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, - 24 - Comité de Confiabilidad
  • 24. 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í, Comité de Confiabilidad - 25 -
  • 25. FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN 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). - 26 - Comité de Confiabilidad
  • 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 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 Comité de Confiabilidad - 27 -
  • 27. FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN 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. - 28 - Comité de Confiabilidad
  • 28. 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 Comité de Confiabilidad - 29 -
  • 29. FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN 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 - 30 - Comité de Confiabilidad
  • 30. Figura 8.a Curso de coste y fiabilidad para el fabricante Comité de Confiabilidad - 31 -
  • 31. 3. CALIDAD EN EL DESARROLLO DEL SOFTWARE 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. Figura 9. Factores que afectan a la calidad y la productividad en el software segun [24] Comité de Confiabilidad - 33 -
  • 32. FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN 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
  • 33. 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. Tabla 2. Impacto de factores clave de personal en la productividad y calidad 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. Comité de Confiabilidad - 35 -
  • 34. FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN Las organizaciones suelen estar más concienciadas en gastar en herramientas (>50%) que en otras medidas, seguramente más eficaces según McConnell [31]. En general, aunque contar con herramientas de desarrollo (por ejemplo, nuevas plataformas de desarrollo, compiladores, lenguajes, entornos IDE, CASE, etc.) suele facilitar las tareas y, sobre todo, permite abordar sistemas más complejos (o que, incluso, anteriormente eran inabordables) con el mismo personal. En efecto, en algunas ocasiones permiten incrementar la productividad. Por ejemplo, en el modelo de Bohem [32], el uso de herramientas avanzadas supone un porcentaje de -17% de esfuerzo frente al +24% de esfuerzo con herramientas muy básicas. Resulta de gran importancia que las herramientas sean apropiadas y que se integren bien en la organización de desarrollo a través de formación, de adaptación a las necesidades de los desarrolladores, del entorno técnico y con otras herramientas ya existentes. El uso de CASE efectivo incrementa la productividad en un 27%, pero la incorporación inadecuada de herramientas puede disminuir la productividad en un 75% según los datos de Jones [24] En general, como indica McConnell en [31] suele ocurrir que el mercado de tecnologías y herramientas es propicio a reclamos exagerados y sensacionalistas (por ejemplo, “reduzca sus tiempos de desarrollo en un 15%”), que el 30% de las herramientas adquiridas no cubren las necesidades de los usuarios, que el 10% no se usan nunca, que el 25% no se aprovechan convenientemente por falta de formación, etc. Incluso Jones en [33] considera poco creíbles las afirmaciones en el 75% de la publicidad y que, tras revisar 4000 proyectos, el 70% de los responsables creían que un único factor como éste podría proporcionar grandes mejoras. En cierto modo, esto enlaza con recurrentes noticias sobre la desaparición de la figura del programador. Ya se sugería al aparecer el lenguaje ensamblador y perdura hasta nuestros días: en 2006 se publió que en 2008 las nuevas herramientas de desarrollo harán desaparecer dicho puesto. 3.3 Mejora de procesos de desarrollo La mejora de las técnicas y métodos de desarrollo pasa por la intervención en distintos planos de actuación dentro de la organización de desarrollo. Por una parte, a nivel de procesos y desde una perspectiva global, debemos mencionar las iniciativas de evaluación y mejora de procesos como CMMi [34], ISO 15504 SPICE [35], etc. En este caso, el foco de atención se centra en la organización de - 36 - Comité de Confiabilidad
  • 35. 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]. Comité de Confiabilidad - 37 -
  • 36. FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN 3.4 Mejora de procesos de aseguramiento de calidad de software Tradicionalmente, por incorporación de la normativa genérica de calidad, el establecimiento de sistemas de calidad corporativos basados en ISO 9001 [11] ha sido una opción habitualmente considerada por las organizaciones preocupadas por la calidad. Las peculiaridades del software como producto han motivado la existencia de una norma complementaria para la adaptación de la norma general ISO 9001 al software, a la ISO 90003 [44]. Evidentemente, en el caso de ISO 9001 han confluido los intereses de imagen comercial con el interés por la mejora por sus implicaciones de mercado. Entre los profesionales se ha generado controversia por éste y otros aspectos, aunque resulta claro que el establecimiento de estructuras organizativas orientadas a la calidad y documentadas (manual de calidad, procedimientos, etc.) ha fomentado, al menos, un esquema claro de trabajo y una estabilización de procesos y resultados. También ha servido para establecer unos mínimos en la aplicación del aseguramiento de calidad como medio de proporciona confianza a los desarrolladores y a los clientes sobre la sistemática de trabajo en los proyectos. A nivel de proyecto, el trabajo se suele apoyar en una planificación específica (aunque coherente con el sistema de calidad u otras normas aplicables) a través de un plan de aseguramiento de calidad de software. Si adoptamos el correspondiente estándar IEEE, el 730 [45], como referencia, las técnicas incluidas para los proyectos se corresponden con las más tradicionales y usadas: gestión de configuración (como elemento clave de control de los productos), medición (para evaluación completa de procesos y productos) así como verificación y validación (principalmente basadas en aplicación de pruebas y de procesos de revisión y auditoría). Por supuesto existen catálogos más extensos de técnicas (ver los trabajos publicados en ACM [46] e IEEE [47]) pero no suelen ser tan comunes como las mencionadas (ver tabla 3). - 38 - Comité de Confiabilidad
  • 37. Tabla 2. Otras técnicas de verificación y validación Comité de Confiabilidad - 39 -
  • 38. FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN Pruebas de software De manera breve, debemos recordar que las pruebas de software deberían ceñirse al ciclo de pruebas propuesto en el estándar IEEE 1008 [48] (ver fig. 10). El diseño de casos de prueba está totalmente mediatizado por la imposibilidad de probar exhaustivamente el software. Pensemos en un programa muy sencillo que sólo suma dos números enteros de dos cifras (del 0 al 99). Si quisiéramos probar, simplemente, todos los valores válidos que se pueden sumar deberíamos probar 10.000 combinaciones distintas de cien posibles números del primer sumando y cien del segundo. Pensemos que aún quedarían por probar todas las posibilidades de error al introducir los datos (p. ej. teclear una letra en vez de un número). Tampoco podemos pretender analizar todos los posibles caminos de ejecución por el programa que son también impracticables. Si para un programa tan elemental debemos realizar tantas pruebas, podemos imaginar lo que supondría un programa de tamaño real. En consecuencia, las técnicas de diseño de casos de prueba tienen como objetivo conseguir una confianza aceptable en que se detectarán los defectos existentes (ya que la seguridad total sólo puede obtenerse de la prueba exhaustiva, que no es practicable) sin que se necesite consumir una cantidad excesiva de recursos (p. ej. tiempo para probar o tiempo de ejecución). Toda la disciplina de pruebas debe moverse, por lo tanto, en un equilibrio entre la disponibilidad de recursos y la confianza que aportan los casos para descubrir los defectos existentes. Este equilibrio no es sencillo, lo que convierte a las pruebas en una disciplina difícil y que está lejos de parecerse a la imagen de actividad rutinaria que suele sugerir. Figura 10. Cilco completo de pruebas definido en el estándar IEEE [48] - 40 - Comité de Confiabilidad
  • 39. 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 una caja transparente, que permite ver su interior. Recientemente, la mayoría de autores ya utiliza la expresión “prueba de caja de cristal” (Glass box testing). 12 En inglés, black box testing Comité de Confiabilidad - 41 -
  • 40. FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN Figura 11. Los enfoques de diseño de pruebas de caja blanca y de caja negra 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). Figura 12. Estrategia de aplicación de pruebas en el desarrollo de software - 42 - Comité de Confiabilidad
  • 41. 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 Comité de Confiabilidad - 43 -
  • 42. FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN Para ello disponemos de diversos métodos (ver tabla 5). Tabla5. Verificación y validación según IEEE 1028 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. Figura 14. Enfoque de las distintas técnicas de V&V 13 También pueden encontrarse en la literatura anglosajona con los términos “work unit” y “software element”. 14 En inglés, deliverables. - 44 - Comité de Confiabilidad
  • 43. 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. Tabla 4. Comparativa entre revisiones y auditorías según [50] 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. Comité de Confiabilidad - 45 -
  • 44. FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN Tabla 7. Recomendación de revisiones y auditorías según IEEE 1012 [53] - 46 - Comité de Confiabilidad
  • 45. 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. (estándares, guías y procedimiento) Figura 15. El proceso de inspección 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). Comité de Confiabilidad - 47 -
  • 46. FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN Participación en las inspecciones: “pares” y personal de todos los niveles jerárquicos exceptuando la alta dirección. Las inspecciones se deben realizar en una serie predefinida y estricta de etapas. La duración de las reuniones no deberá exceder las dos horas . Las inspecciones deben ser dirigidas por moderadores entrenados y experimentados (a través de prácticas en inspecciones) para lograr eficacia en su trabajo. Los miembros del equipo de inspección tienen asignados papeles específicos para incrementar su efectividad. Se usan listas de comprobación para que los miembros del equipo de inspección tengan su tarea definida y para incrementar el descubrimiento de los defectos. Métricas y evaluación de calidad La evaluación de la calidad del software se basa en la utilización de modelos de calidad para abarcar sus distintas facetas. Fundamentalmente, ha sido el modelo de McCall et al. [8] (ver figura 16) el que ha inspirado más variantes hasta la aparición de los estándares actuales (principalmente ISO 9126 [2]: ver figura 17). Todos ellos descomponen la calidad en sub-características más fáciles de medir o evaluar. Figura 16. Modelo de evaluación de calidad de McCall - 48 - Comité de Confiabilidad
  • 47. 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 Comité de Confiabilidad - 49 -
  • 48. FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN Otras consideraciones sobre aseguramiento de calidad Es importante recordar que estas técnicas son caras y que su uso debe adaptarse a cada entorno tanto para ser eficaz (incorporándose con facilidad a la vida diaria del equipo de desarrollo) como para ser más eficiente y rentable. Por ejemplo, los procesos de revisión de todo el código de una aplicación suelen ser inabordables por su coste. Para buscar mayor eficiencia, se suele establecer unos análisis previos con herramientas basados en patrones de métricas y reglas a cumplir. Aplicando el principio de Pareto, la empresa sólo aplica inspecciones a los trozos de código más críticos o con peores evaluaciones en dicho análisis para concentrar el esfuerzo disponible en los módulos que puedan acumular más defectos y más peligrosos. Otra táctica, que puede ser complementaria, consiste en disminuir esfuerzo automatizando tareas de evaluación con herramientas y disminuyendo el número de revisores implicados. En cualquier caso, la aplicación de acciones apropiadas de aseguramiento de calidad de software permite, al menos, estabilizar tiempos de entrega y niveles de calidad (como en la experiencia presentada por Yasuda [54]). Son bastante frecuentes los estudios y publicaciones que demuestran mejoras de productividad y rentabilidad basadas en disminuir retrabajo y minorar efectos adversos causados por defectos y fallos en el software: los llamados costes de la mala calidad descritos por Harrington [55] Ya en los años ochenta, los programas corporativos pioneros en Hewlett-Packard [56] demostraron cómo se podían compatibilizar actividades de aseguramiento de calidad, medición de resultados y objetivos corporativos basados en la rentabilidad, disminución de break-even time y reducción de defectos. La reducción de defectos supone un ahorro de costes debido a los ya mencionados costes de la mala calidad: retrabajo, indemnizaciones, pérdida de imagen. Como ya descubrió IBM hace tiempo y se describe en [55], cada dólar dedicado a prevención supone el ahorro de 50 dólares después. Por ello, el aseguramiento debe ser especialmente insistente en proporcionar medios de detección y corrección temprana de defectos (ver tabla 2). - 50 - Comité de Confiabilidad
  • 49. 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. Comité de Confiabilidad - 51 -
  • 50. FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN - 52 - Comité de Confiabilidad
  • 51. 4. ALGUNAS CONSIDERACIONES ADICIONALES En el ámbito de la confiabilidad también se menciona el concepto de capacidad de supervivencia (survivability), surgido principalmente a finales de los años sesenta y principios de los setenta del siglo XX en estándares militares (por ejemplo, MIL-STD-721 o DOD-D-5000.3). Se definió en dicho momento como la capacidad del sistema para resistir en un entorno hostil de tal forma que pudiera cumplir su misión según indica Avizienis [5]. La confiabilidad ha evolucionado desde los conceptos de fiabilidad y disponibilidad a través de la evolución tecnológica de la informática y de las comunicaciones para dar respuesta adecuada a los desafíos de aplicaciones en red y la necesidad creciente de confianza en la informática ubicua. Así, la capacidad de supervivencia entendida como “capacidad de un sistema para continuar con su misión en presencia de ataques, fallos o accidentes”, ha evolucionado desde los asuntos de pura seguridad y ha ganado interés debido a la frecuencia y gravedad de ataques de adversarios inteligentes sistemas de información críticos. Desde la perspectiva de la confiabilidad la capacidad de supervivencia es la confiabilidad en presencia de defectos activos de todo tipo. La relación entre ambas se percibe como estrecha cuando observamos las 3 R de la capacidad de supervivencia descritas por Lipson [57]: Resistencia: capacidad de repeler ataques. Se relaciona en confiabilidad con la prevención de defectos. Reconocimiento: capacidad de reconocer ataques y la extensión de los daños. Recuperación: capacidad de restaurar los servicios esenciales durante el ataque y recuperar el servicio completo tras el mismo, junto con el reconocimiento. Tiene mucho que ver con tolerancia a defectos. En cualquier caso, ambas características van más allá de los enfoques tradicionales basados en evitar defectos. Comité de Confiabilidad
  • 52. 5. REFERENCIAS [1] IEEE, IEEE Standard 610. Computer dictionary. Compilation of IEEE Standard Computer Glossaries, Institute of Electrical and Electronics Engineers, 1993. [2] ISO, ISO 9126. Information technology. Software product evaluation. quality characteristics and guidelines for their use, International Organization for Standardization, 2001. [3] ISO, ISO 14598-1. Information technology software product evaluation. Part I: general overview, International Organization for Standardization, 2001. [4] J.C. Laprie. Dependability: Basic Concepts and Terminology. Springer Verlag, Vienna, Austria, 1992. [5] A. Avizienis, J.-C. Laprie and B. Randell, Fundamental Concepts of Dependability, Research Report N01145, LAAS-CNRS, abril, 2001. [6] IEEE, IEEE Std 1044.1-1995 IEEE Guide to Classification for Software Anomalies -Description, Institute of Electrical and Electronics Engineers, 1995 [7] IEEE, IEEE Std 1044-1993 IEEE Standard Classification for Software Anomalies – Description, Institute of Electrical and Electronics Engineers, 1993. [8] J.A. McCall, P.K. Richards y G.F. Walters, Factors in software quality, vols. I, II y III, US Rome Air Development Center Reports NTIS AD/A-049 014, 015, 055, 1977. [9] A. Avizienis, J-C., Laprie, B. Randell, “Fundamental Concepts of Computer System Dependability”, IARP/IEEE-RAS Workshop on Robot Dependability: Technological Challenge of Dependable, Robots in Human Environments, 2001. [10] European Cooperation for Space Standardization, Space product assurance. Methods and techniques to support the assesment of software dependability and safety, Draft ECSS-Q-80-03, ESA-ESTEC, marzo, 2006. [11] R.S. Pressman, Ingeniería del software. Un enfoque práctico, McGraw-Hill, 2005. [12] M.L.Shooman, Software Engineering Design, Reliability, And Management, McGraw-Hill, 1983 Comité de Confiabilidad - 55 -
  • 53. FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN [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. - 56 - Comité de Confiabilidad
  • 54. [29] F. Brooks, The mythical man-month, Addison-Wesley,1975. [30] G.G. Schulmeyer, “The net negative producing programmer”. American Programmer, nº 6 (1992). [31] S. McConnell, Desarrollo y gestión de proyectos informáticos. Cómo dominar planificaciones ajustadas de software. McGraw-Hill, 1997. [32] B. W. Boehm, Software engineering economics. Prentice-Hall, 1981. [33] C. Jones, Assessment and control of software risks, Yourdon Press, 1994. [34] CMMi product team, CMMI® for Development, Version 1.2. CMU/SEI-2006-TR-008, Carnegie-Mellon SEI, agosto 2006. [35] ISO/IEC Commission, ISO/IEC 15504-3:2004. Information technology: Process assessment. Part 3: Guidance on performing an assessment, ISO, 2003. [36] ISO, UNE-ISO 9001. Sistemas de gestión de calidad. Requisitos. AENOR, 2000. [37] I. Jacobson, J. Rumbaugh y G. Booch, The Unified Software Development Process. Addison-Wesley, 1999. [38] K. Beck, Una explicación de la programación extrema: aceptar el cambio, Addison Wesley, 2002. [39] OMG, UML 2.0 Superstructure Specification, OMG Adopted Specification, ptc/03-08-02, Object Management Group, agosto, 2003. [40] M. C. Paulk, C.V. Weber, S. M. Garcia, M. B. Chrissis y M. Bush, Capability Maturity Model For Software v. 1.1., Software Engineering Institute, 1993. [41] Software Engineering Institute, Software CMM CBA-IPI and SPA Appraisal results. 2003 Mid-Year Update. Software Engineering Institute, 2003. [42] Herbsleb, J. et al.: Benefits of CMM-based software process improvement: initial results. CMU-SEI-94- TR-013. Software Engineering Institute, Pittsburgh (1994). [43] B. A. Kitchenham, Evaluating software engineering methods and tools. Part I. ACM Software engineering notes, vol. 21, nº 1, 1996, pp. 11-15. Comité de Confiabilidad - 57 -
  • 55. FUNDAMENTOS DE LA CONFIABILIDAD EN EL DESARROLLO DE SOFTWARE: ENFOQUE Y PREVENCIÓN [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). - 58 - Comité de Confiabilidad
  • 56. 6. SOBRE EL AUTOR 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. Comité de Confiabilidad - 59 -