Calidad del software: gestión de la calidad y métricas

90  22  Descargar (0)

Texto completo

(1)

Calidad del

software: gestión

de la calidad y

métricas

Xavier Escudero Sabadell

(2)

Ninguna parte de esta publicación, incluido el diseño general y la cubierta, puede ser copiada, reproducida, almacenada o transmitida de ninguna forma, ni por ningún medio, sea éste eléctrico, químico, mecánico, óptico, grabación, fotocopia, o cualquier otro, sin la previa autorización escrita de los titulares del copyright.

(3)

Índice

Introducción... 5

Objetivos... 6

1. La calidad... 7

1.1. Problemas actuales del software ... 7

1.2. Qué es la calidad ... 8

1.2.1. Perspectivas de la calidad ... 9

1.2.2. Definición de calidad del software ... 10

1.3. Defecto, error, fallo e incidencia. Diferencias y características ... 11

1.4. Gestión de la calidad ... 14

1.4.1. Control y aseguramiento de la calidad ... 16

1.4.2. Verificación y validación ... 18

1.4.3. Las pruebas o testing... 18

1.5. El coste de la calidad ... 19

2. Los defectos. Causas y ciclo de vida... 23

2.1. Breve historia de los defectos más famosos ... 23

2.1.1. El primer defecto conocido ... 23

2.1.2. Therac-25 (1985-1987) ... 24

2.1.3. Ariane-5 (1996) ... 24

2.1.4. Mars Climate Orbiter (1998) ... 25

2.1.5. Efecto 2000 ... 25

2.1.6. Consulta de la votación de la Diagonal (2010) ... 25

2.2. Causas de los errores ... 26

2.3. Introducción y eliminación de los defectos. Coste de su corrección ... 28

2.4. Gestión de los defectos ... 29

2.4.1. Contenido de un informe de defecto ... 29

2.4.2. Proceso de gestión o tratamiento de un defecto ... 33

2.5. Algunos defectos poco habituales ... 34

3. Modelos de calidad y estándares... 35

3.1. Modelos de gestión de calidad en la organización ... 36

3.1.1. Normas ISO ... 36

3.1.2. El modelo de excelencia EFQM ... 40

3.2. Modelos de calidad del proceso de software ... 41

3.2.1. Modelos de evaluación y mejora de la calidad de procesos de software ... 42

3.2.2. Modelos específicos de calidad en el proceso de pruebas ... 47

(4)

3.3. Modelos de calidad en el producto de software ... 50

3.3.1. ISO 9126 ... 51

3.3.2. Otros modelos ... 54

4. Medidas y métricas en calidad del software... 56

4.1. Conceptos básicos de medición ... 57

4.2. Estrategia de medición del software ... 58

4.3. Tipos de métricas ... 60

4.4. Métricas básicas: el tamaño del software ... 61

4.4.1. Líneas de código ... 61

4.4.2. Puntos función ... 63

4.5. Métricas de calidad en el proceso ... 65

4.5.1. Densidad de llegada de defectos ... 66

4.5.2. Eficiencia en la eliminación de defectos ... 66

4.5.3. Curva de progreso de las pruebas ... 67

4.5.4. Densidad de defectos encontrados en las pruebas ... 68

4.5.5. Métricas de cobertura de pruebas ... 69

4.6. Métricas de calidad externa de producto ... 69

4.6.1. Métricas de defectos y problemas del cliente ... 70

4.6.2. Métricas de fallo ... 71

4.7. Métricas de calidad interna del producto ... 72

4.7.1. Métricas de complejidad ... 72

4.7.2. Métricas de mantenibilidad ... 74

4.7.3. Métricas estructurales ... 75

4.7.4. Métricas específicas por orientación a objetos ... 75

Resumen... 79 Actividades... 81 Ejercicios de autoevaluación... 82 Solucionario... 83 Glosario... 87 Bibliografía... 89

(5)

Introducción

Este módulo introduce los conceptos necesarios para que cualquier ingeniero u organización pueda desarrollar software de calidad.

Analizaremos los elementos, tanto de los procesos como de los productos re-sultantes (entregables, código fuente, etc.), en los que se basa la calidad, con-siderando cuáles son las causas más habituales de los errores y algunos de los ejemplos históricos más conocidos.

Desde el punto de vista organizativo, veremos cuáles son las acciones que se pueden realizar para mitigar los riesgos y costes asociados a una mala calidad de nuestro software. A fin de que el camino sea más sencillo veremos qué modelos y estándares están a nuestro alcance.

Finalmente, cualquier ingeniero que se encuentre dentro del proceso de cali-dad tiene que saber cómo medir la calicali-dad real de un producto y de su proceso. Por ello veremos cómo medir la dimensión o el tamaño de un software, cómo evaluar su complejidad y cómo determinar si nuestro proceso de detección de defectos es efectivo, entre otros. Estas medidas nos permitirán establecer pla-nes de mejora y determinar a qué puntos conviene dedicar mayores esfuerzos. Más adelante, en el módulo "Calidad del software: técnicas de prevención, de-tección y corrección de defectos" veremos cómo implantar de forma específica los diferentes objetivos descritos en este módulo y qué herramientas tenemos a nuestro alcance para llevarlos a cabo.

A lo largo de este módulo y del módulo "Calidad del software: técnicas de pre-vención, detección y corrección de defectos" intentaremos aplicar desde un enfoque lo más práctico posible los diferentes conceptos que vayan aparecien-do, utilizando el siguiente caso:

La UOC quiere extender los servicios incluidos en la Virtual del Campus con la incor-poración de un espacio web específico para la reserva de vuelos, hoteles y coches, con ventajas especiales para los estudiantes, denominado Viajes Campus Virtual (de ahora en adelante VCV). Este sistema se desarrollará en una arquitectura de tres capas y tendrá que ser usable, fiable y robusto.

(6)

Objetivos

Los objetivos que los estudiantes tenéis que haber alcanzado una vez trabaja-dos los contenitrabaja-dos de este módulo son:

1. Entender qué es la calidad en todas sus vertientes, tanto en el plano teórico

como en el práctico.

2. Entender cuál es el proceso y las causas por las que se generan defectos en

el software, desde el error humano hasta el fallo real en el sistema.

3. Entender cuáles son las actividades que podemos realizar para detectar y

prevenir los defectos, e identificar su importancia respecto del coste deri-vado de una mala calidad.

4. Identificar cuál es el proceso de detección de un defecto, su investigación

y resolución, reconociendo cuál es la información más importante que tenemos que asociar a un defecto para su seguimiento.

5. Conocer los modelos y estándares en calidad de software más importantes

y su utilidad.

6. Conocer cuáles son las métricas más utilizadas para medir la calidad de

un producto de software y la del proceso de desarrollo. Entender cómo se pueden usar para su mejora.

(7)

1. La calidad

1.1. Problemas actuales del software

Hoy en día, todo el mundo es consciente de la importancia y el crecimiento que tiene el software en nuestras vidas. Lo encontramos en el trabajo, en casa, en nuestras compras, en nuestro teléfono móvil, etc. Lo que no podemos ne-gar, sin embargo, es que todos nos hemos enfrentado en alguna ocasión a al-gún error o mal funcionamiento inesperado. Algunos de estos errores pueden tener consecuencias desastrosas y provocar incluso daños humanos (imaginad un error en una central nuclear o en el sistema de navegación de un avión, por ejemplo).

¿Por qué se producen esos errores? La realidad es que nos encontramos con una industria relativamente "joven" y sufrimos algunos de los siguientes pro-blemas:

• El software se desarrolla todavía de forma bastante "artesanal". Depende-mos mucho de los llamados "héroes" o de las personas.

• Existe una "prisa patológica", consecuencia de la desorganización y falta de planificación. Se quiere obtener resultados rápidamente, sin analizar el alcance, los riesgos y los requisitos del proyecto.

• Se dedican muchos esfuerzos "hoy" para corregir lo que se hizo mal "ayer". En la mayoría de los casos se trabaja de forma reactiva para resolver crisis, en lugar de tener una visión preventiva.

• No hay una visión objetiva de la calidad y fiabilidad de los sistemas cons-truidos.

• Ante restricciones en tiempo y presupuesto, el factor que se sacrifica es la calidad del producto.

Ved también

Ved en el subapartado 2.1 ejemplos reales de errores en la historia.

¿Cómo conseguir el éxito de los proyectos? El éxito de un proyecto acostum-bra a determinarse por la consecución de los hitos establecidos en coste, pla-nificación y alcance, pero también se tiene que considerar la gestión de su ca-lidad. Por este motivo, las organizaciones y las empresas toman cada vez más conciencia sobre la calidad de sus productos y procesos:

• Especificando los requisitos de calidad de un producto.

Software o producto

A lo largo del módulo usare-mos indistintamente los con-ceptos de software y produc-to para representar el conjun-to de código y ejecutables, la documentación (diseño téc-nico, diseño funcional...), los procedimientos y los datos ne-cesarios a fin de que funcione el sistema.

(8)

• Definiendo e implantando una metodología que permita poner en prácti-ca los métodos, procesos, procedimientos y herramientas para desarrollar, operar, desplegar y mantener los productos.

• Evaluando la calidad de sus procesos y productos de forma objetiva y cuan-titativa.

En este módulo analizaremos cuáles son los mecanismos incluidos dentro de la gestión de la calidad y cómo medirla, pero antes revisaremos qué se entiende por calidad.

1.2. Qué es la calidad

La calidad es un término intangible y difícil de definir. La mayoría de la gente es capaz de reconocer la calidad y dar algunos ejemplos, pero tiene problemas para definirla de una manera clara y sin ambigüedades.

En general, podemos pensar que la calidad de un producto o servicio es alta si responde o supera nuestras expectativas, mientras que la con-sideramos baja en caso contrario.

Sin embargo, cualquier valoración de la calidad de un producto o servicio de-penderá de diferentes factores de aquel que lo observa, como su educación, sus experiencias, situación, estado de ánimo o necesidades.

Calidad de un tarro de miel

¿Cómo definiríais la calidad que tiene un tarro de miel? Por el atractivo de su envase, porque otros productos de la misma marca son de buena calidad, por tener un sistema antigoteo...

Necesitamos concretar y eliminar la ambigüedad del concepto calidad, defi-niéndolo como un elemento específico. Juran, en los años setenta, definió la

calidad como la "idoneidad de uso" mientras que Crosby añadió que tenía que

incluir la "conformidad con los requisitos".

La conformidad con los requisitos tiene en cuenta que se definan los requisitos y especificaciones de forma concreta y se tomen medidas para determinar, de forma continuada, que se cumplen.

Juran (1970) y Crosby (1979)

Juran ha sido un evangelista en la gestión de la calidad, reco-nocido sobre todo por su apli-cación del principio de Pareto a temas de calidad, y su ges-tión de la calidad total. Crosby ha sido un empresario norteamericano que aplicó a la práctica la gestión de la ca-lidad y consiguió reducir en un 30% los costes inicialmente debidos a la mala calidad. Asi-mismo, es reconocido por su frase "hacerlo correctamente la primera vez".

Aplicativo VCV de la UOC

El aplicativo VCV de la UOC tiene que permitir la búsqueda de vuelos de bajo coste. Ten-dremos que verificar si real-mente lo permite.

(9)

Podemos pensar que si el producto satisface los requisitos especificados tam-bién se satisfarán las necesidades del cliente o usuario, y ello parece bastante lógico, pero la realidad es que las necesidades del cliente o usuario incluyen otros elementos que no se encuentran recogidos en las especificaciones. Se es-pera también que el producto no tenga errores y se hayan considerado otros factores de influencia en la calidad, como la facilidad en su instalación, la fa-cilidad de mantenimiento, su rendimiento o su usabilidad, entre otros. Estos elementos definen lo que llamamos "idoneidad de uso".

1.2.1. Perspectivas de la calidad

La calidad puede ser entendida de forma sistemática desde diferentes puntos de vista o perspectivas:

Punto�de�vista�trascendental. Desde esta perspectiva, la calidad es difícil

de definir y medir, pero se puede reconocer si está presente. Responde a la frase "este producto me gusta y supera los límites usuales". El problema de esta perspectiva o punto de vista es que la calidad es intuitiva. Se basa en la percepción y depende de factores subjetivos de los diferentes observadores (experiencia, estado anímico, estatus social, etc.).

La primera versión del VCV

La primera versión del VCV ha sido aceptada por el cliente, pues se han cubierto todos los requisitos establecidos. Días después de su puesta en mar-cha, un acceso masivo de peti-ciones hace que se caiga el sis-tema.

Ejemplo

Al acceder por primera vez al aplicativo VCV1 vemos que es mucho mejor que otras webs similares que ya conocíamos y la identificamos como de calidad. Esta catalogación la basamos en nuestra percepción.

Punto�de�vista�del�usuario. Desde esta perspectiva, la calidad responde

a cómo el producto es capaz de satisfacer las necesidades del usuario (usa-bilidad, eficiencia...).

Ejemplo

La aplicación VCV permite a los usuarios realizar las búsquedas de forma rápida y ofrece una buena usabilidad, con la incorporación de ayudas contextuales, navegación sencilla y una estructura similar a la del campus.

(1)Recordad que VCV es la

abrevia-tura de Viajes Campus Virtual.

Punto�de�vista�de�la�fabricación. Desde esta perspectiva, la calidad es

el resultado de un desarrollo correcto del producto, basado en el cumpli-miento de estándares de proceso. Este punto de vista tiene sus orígenes en la industria (fabricación de automóviles, electrónica, etc.). Los modelos CMMI e ISO 9001 se basan en este punto de vista.

Ejemplo

Para el desarrollo del VCV definimos una nueva metodología basada en estándares de facto e incorporamos puntos de control para cada actividad. El aplicativo resultante, al seguir las diferentes normas establecidas, se produce con calidad.

Ved también

Los modelos CMMI e ISO 9001 los veremos en los subapartados 3.1 y 3.2 de este módulo.

(10)

Punto�de�vista�del�producto. La calidad se define por las características

internas del producto. Si el producto tiene buenas propiedades internas tendrá buenas propiedades externas.

Ejemplo

Si la aplicación VCV está bien modularizada, será más fácil probarla y mantenerla (faci-lidad para incorporar cambios o correcciones).

Punto�de�vista�del�valor. En este caso, la calidad se define por el valor

económico del software o por lo que estamos dispuestos a pagar por él.

Ejemplo

El aplicativo VCV se puede usar desde plataformas móviles iPhone y Android con un coste de 1 euro por descarga. El 80% de los usuarios está dispuesto a pagarlo, según una encuesta.

Desde una visión relacionada con el tipo de rol en la calidad, podemos también diferenciar entre la visión de la calidad que tiene el productor (quien construye el producto) y la que tiene el cliente o el usuario final (quien usa el producto). Desde el punto de vista del productor, construir el producto de acuerdo con los requisitos es el camino para conseguir la calidad. Desde el punto de vista del cliente o usuario final, la calidad es el valor final percibido del producto.

1.2.2. Definición de calidad del software

Hasta ahora hemos visto la calidad desde un punto de vista genérico, aplicable a cualquier tipología de servicio, producto o proceso. Si bien el software tiene ciertas particularidades, la definición de calidad del software no difiere mucho de las anteriores definiciones.

Un software de calidad está libre de defectos y cumple los requisitos especificados y las necesidades o expectativas del cliente o usuario.

Tenemos que incluir el proceso como una parte integrante de la calidad, y es que una manera de producir un software de calidad es mediante un proceso de desarrollo que tenga calidad. Ahora bien, si construimos un software que cumple a la perfección el conjunto de las especificaciones y requisitos, ¿tene-mos un producto de calidad? La respuesta es quizá que no, ya que el cliente o usuario puede argumentar que no satisface sus necesidades. Roger Pressman apoya esta idea con su definición de calidad del software.

Roger Pressman

Roger Pressman es un referen-te en la ingeniería del softwa-re, integrante del IEEE y autor de libros tan reconocidos co-mo Ingeniería del software. Un

(11)

Según Roger Pressman, la calidad del software es la "conformidad con los requisitos funcionales y de rendimiento, con los estándares de desa-rrollo prefijados y con las características implícitas que se esperan de cualquier software profesional desarrollado".

1.3. Defecto, error, fallo e incidencia. Diferencias y características

Acabamos de indicar en el subapartado anterior que un software de calidad es el que no tiene defectos. Sin embargo ¿qué es exactamente un defecto?

Defecto

Un defecto es una anomalía en el software que puede hacer que este se comporte de forma incorrecta, contrariamente a su especificación.

Un defecto es a menudo denominado error o fallo, pero, en realidad, estos tres términos no representan exactamente lo mismo. A continuación veremos en qué se diferencian.

Error

Un error es una mala interpretación o equivocación por parte de un desarrollador (analista, programador, probador...).

Ejemplo de error

En el VCV, el programador ha obviado cerrar la conexión en la base de datos una vez que el usuario ha finalizado la reserva.

(12)

Estos errores humanos pueden ser tanto técnicos, por haber introducido una mala práctica de programación, o lógicos, por no haber construido o interpre-tado de forma correcta el requisito soliciinterpre-tado por el usuario, el cliente o un integrante del equipo de desarrollo.

Como resultado de un error se introduce un defecto en el software.

El efecto de un error es la introducción de un defecto en el software, en cual-quiera de sus entregables, tanto en su código fuente como en un documento o requisito.

Fallo

Un fallo es la consecuencia de un defecto sobre el sistema, observada por un desarrollador, probador o usuario, que inhabilita su correcto funcio-namiento y produce resultados que no son los esperados.

Ejemplo de fallo

En el VCV, el error de un programador provoca que no se cierren las conexiones previa-mente abiertas en la base de datos (defecto). Solo en el momento en que el número de accesos realizados consuma las máximas conexiones disponibles se producirá un fallo en los usuarios (un mensaje en la pantalla que inhabilite cualquier operación, por ejemplo).

Un defecto no siempre produce directamente un fallo. Un sistema o compo-nente puede funcionar durante largo tiempo de forma correcta hasta que se den las condiciones que hacen que se manifieste el fallo. Por ejemplo, un de-fecto en el código puede ser "neutralizado" por líneas de código posteriores que eviten que se produzca el defecto (una condición que nunca tiene lugar...); o puede quedar residente hasta que surja alguna situación que lo haga visible. No todos los fallos son producidos siempre por defectos. En determinados casos, los fallos pueden estar causados por condiciones en el entorno (campos magnéticos, radiaciones, etc.) que provocan un cambio de comportamiento en el software.

Las fallos pueden asimismo clasificarse según su duración en transitorios o permanentes. Un fallo transitorio desaparece finalmente, a veces inexplicable-mente sin una intervención aparente, mientras que un fallo permanente que-da hasta que sea eliminado por alguien. Según cómo se comporte el compo-nente que ha provocado el fallo una vez producido este, podemos tener: • Fallos�estrepitosos. El componente deja completamente de dar servicio o

nunca vuelve a un estado válido.

Errores del probador

Un probador o tester también puede cometer errores, ya que puede especificar un caso de prueba de forma incorrecta, con lo que la ejecución de las pruebas no obtendría ningún resultado objetivo.

(13)

Fallos�de�omisión. El componente falla completamente al realizar el

ser-vicio.

Fallos�de�tiempo. El componente no completa el servicio en el tiempo

necesario.

Fallos�aleatorios. Fallos de naturaleza arbitraria. Incidencia

Por último, describiremos el concepto de incidencia (también llamada a veces anomalía).

Una anomalía o incidencia es cualquier situación que difiere del com-portamiento esperado.

Cuando los usuarios o los probadores observan un acontecimiento inespera-do en el uso del aplicativo, informan de la situación y generan una inciden-cia que tendrá que ser revisada y corregida por algún equipo. Esta incideninciden-cia acostumbran a asociarla mentalmente con un fallo, ya que interpretan que el software no hace lo que ellos esperan, pero no siempre una incidencia lleva asociado un fallo.

Ejemplo de incidencia

El usuario espera que los resultados del histórico de las reservas del VCV se puedan ex-portar a Excel con un botón que no le aparece activado e informa de la incidencia. Se comprueba que esta funcionalidad no había sido prevista en los requisitos y se clasifica como una mejora para una versión futura, en lugar de como un fallo.

Todas las incidencias tienen que ser registradas, ya sea de forma manual, ya con una herramienta. Cuanta más información y detalle se tenga de las mismas más facilidades habrá para realizar la localización de los posibles defectos. Toda incidencia puede provocar como resultado la necesidad de realizar cam-bios en el software (código o documentación). Estos camcam-bios se incluyen en una de las actividades de mantenimiento del software siguientes:

Mantenimiento� correctivo. Modificaciones en el software hechas

des-pués de la entrega para corregir los fallos o defectos descubiertos.

Aplicaciones de gestión de incidencias

Habitualmente, las incidencias son registradas en aplicaciones específicas de gestión de inci-dencias que permiten su segui-miento.

(14)

Mantenimiento�adaptativo. Modificaciones en el software para adaptarse

a cambios en el entorno (hardware o software).

Mantenimiento�perfectivo. Acciones para mejorar la calidad interna del

software: reestructuración del código, optimización del rendimiento, etc. • Mantenimiento� evolutivo. Incorporaciones, modificaciones y

elimina-ciones necesarias para que el software pueda cubrir los cambios en las ne-cesidades del usuario o funcionalidades que fueron planificadas en versio-nes futuras.

Para finalizar este subapartado resumiremos las diferencias entre los conceptos analizados anteriormente:

Concepto Descripción Cómo se puede evitar Error Es el error o la equivocación humana cometidos. Con la formación, comunicación, procesos, etc.

Defecto Es la consecuencia de un error. Se incorpora dentro del

programa (código fuente o entregables intermedios). Con la realización de revisiones.

Fallo Es la materialización del defecto. Con la realización de pruebas.

Incidencia Acontecimiento observado o anomalía. Se observan

re-sultados inesperados. Con la gestión de requisitos, la minuciosa evaluación delas necesidades de los usuarios y la formación. 1.4. Gestión de la calidad

Ya hemos visto qué se entiende por calidad del software, pero ¿cómo puede una organización implantar o establecer acciones para alcanzarla?

Una organización puede alcanzar la calidad de una forma global definiendo el conjunto de actividades y elementos que se necesitan para obtener eficien-temente productos de calidad con medios como la planificación, el control, la garantía o la mejora. Este conjunto de medidas y acciones se incluyen en lo que se denomina gestión de la calidad.

La gestión de la calidad puede ser realizada por una organización desde dife-rentes ámbitos:

1)�Ámbito�del�producto. El objetivo es la observación dentro del proceso de

desarrollo de la calidad del producto (entregables, código, etc.) en sus diferen-tes fases para detectar y corregir los defectos que se puedan encontrar. La cali-dad del producto se podrá medir desde dos puntos de vista:

Calidad�interna. Características internas del software que son visibles a

los desarrolladores, como el código fuente o el diseño técnico.

Ejemplo de mantenimiento adaptativo

Un ejemplo de mantenimien-to adaptativo se da cuando el aplicativo tiene que ser migra-do desde el servimigra-dor de aplica-ciones JBoss a un nuevo servi-dor de aplicaciones Glassfish.

(15)

Calidad�externa. Características visibles a los usuarios. Se mide el

com-portamiento del software mediante, por ejemplo, la realización de pruebas o revisiones.

2)�Ámbito�del�proceso. El objetivo es la implantación de una metodología

que permita aumentar la calidad de los productos construidos con ella. Si el proceso para desarrollar un producto no está bien definido, no se podrá pre-decir la calidad del software creado.

3)�Ámbito�del�proyecto. El objetivo es centrarse en la implantación de

me-todologías para la gestión del proyecto (seguimiento de hitos y objetivos, ges-tión de sus riesgos, etc.).

4)�Ámbito�de�los�recursos. El objetivo es centrarse en cómo se puede mejorar

la calidad de los recursos mediante su formación, su motivación, etc. En pro-yectos pequeños, la calidad de los desarrolladores es un factor determinante. Existen diferentes prácticas y técnicas para alcanzar la gestión completa de la calidad en una organización. Si bien no hay un orden establecido en la realización de estas prácticas, las organizaciones acostumbran a implantar en el tiempo la secuencia de técnicas mostradas en la figura siguiente.

La técnica más habitual y extendida es la realización de pruebas en las que se ejecuta el software para buscar fallos. Ninguna organización tendría que obviar esta técnica, aunque no puede ser la única técnica utilizada, ya que las pruebas se suelen realizar cuando el producto ya está construido, momento en el que el coste de corrección de un defecto puede ser muy alto. Sin embargo, solo tiene en cuenta el software en ejecución, pero no otros tipos de entregables.

(16)

Otros entregables del proyecto, como, por ejemplo, la documentación funcio-nal o los manuales de usuario no se pueden evaluar con las pruebas, pero sí con las revisiones. Con las revisiones se mitiga el problema de detección de defectos en las fases finales del proyecto de las pruebas, ya que las revisiones incluyen la inspección y evaluación de entregables desde fases tempranas del proyecto y previas a la construcción. Las revisiones y pruebas se consideran actividades de lo que se denomina control de la calidad.

Los defectos se observan con la realización de revisiones, mientras que los fallos se observan con la realización de pruebas.

Más allá de las pruebas y las revisiones, encontramos el aseguramiento de la calidad, en el que se trabaja para definir estándares y procedimientos de desa-rrollo de software, tanto de proceso como de producto, y se monitoriza el se-guimiento y la calidad de los mismos en los proyectos.

En el nivel más alto encontramos la gestión de la calidad total, en la que se establece una rutina de planificación, ejecución y coordinación de todos los procesos de calidad en la misión de la organización. Dentro de esta gestión de la calidad se miden los costes de calidad, las ganancias obtenidas, etc. Todas las técnicas anteriores se basan en la ejecución de diferentes tareas re-lacionadas:

Verificación�y�validación. La verificación tiene como objetivo asegurar

que el producto cumple las especificaciones técnicas, mientras que la va-lidación asegura que el producto cubre las necesidades del usuario y sus expectativas.

Auditoría�y�mejora�de�procesos. Una de las formas de incrementar la

ca-lidad de un producto es mejorar la caca-lidad de los procesos de su desarrollo. • Métricas. Para poder gestionar la calidad, es importante poder medir la

calidad del producto y de los procesos.

1.4.1. Control y aseguramiento de la calidad

Los términos aseguramiento de la calidad y control de calidad se suelen usar de forma confusa, bien para referirse al mismo concepto, bien de forma inter-cambiada.

En primer lugar, y con el fin de poder diferenciar más fácilmente estos con-ceptos, consideraremos que los métodos de calidad pueden ser segmentados en dos categorías: los métodos reactivos (o de evaluación) y los métodos pre-ventivos.

Ved también

En el apartado 3 veremos ejemplos de modelos de mejo-ra de procesos, mientmejo-ras que el apartado 4 lo dedicaremos ex-clusivamente a las métricas.

(17)

a) El control de calidad es una actividad de evaluación que comprueba si la

calidad de un producto o servicio alcanza un nivel concreto de calidad. Si el equipo de control de calidad identifica un problema se puede llegar a detener el desarrollo del producto.

b) El aseguramiento de la calidad es un conjunto de actividades preventivas

focalizado en definir los estándares que se tienen que seguir en uno o más proyectos para satisfacer las necesidades del cliente o usuario.

El control de calidad es el que evaluará que los estándares definidos durante el aseguramiento de la calidad se han seguido en cada paso del ciclo de vida. Ba-sándose en los informes que produzca el control de calidad, el aseguramiento de la calidad puede analizar las necesidades correctivas que requiera el proceso. El aseguramiento de la calidad puede detectar, por ejemplo, que hay una ne-cesidad de definir o mejorar los procesos de gestión de requisitos, la gestión de la configuración o la estimación de los esfuerzos que, posteriormente, serán medidos en los proyectos para poder identificar debilidades y corregirlas con una visión de mejora continua del proceso.

El control de calidad se orienta a la evaluación de un producto, servicio o proceso, el aseguramiento de la calidad se orienta al proceso que pro-duce el producto (buenas prácticas, estándares...).

El control de calidad es un objetivo táctico –actividades necesarias para pro-ducir un producto o servicio de calidad– mientras que el aseguramiento de la calidad es un objetivo estratégico de la organización (está dirigido al proceso, la formación, la implantación de herramientas, etc.).

Aseguramiento de la calidad Control de calidad

Preventivo Reactivo o de evaluación

Orientado a proceso. Mide la calidad del proceso usado para crear

el producto. Orientado a producto o servicio. Mide la calidad del producto. Responsabilidad a escala organizativa. Objetivo estratégico. Responsabilidad a escala del equipo de control (un o más).

Objeti-vo táctico. Identificación de las debilidades de determinados procesos.

Mejo-ra de estos procesos. Verificar si los atributos especificados están presentes o no en elproducto. Ejemplos: definiciones de proceso, formación, auditorías de

(18)

1.4.2. Verificación y validación

En todos los modelos de ciclo de vida de desarrollo tienen que establecerse puntos de control que evalúen si el trabajo realizado hasta el momento cumple los objetivos previstos y se puede avanzar a la siguiente fase.

Las comprobaciones o puntos de control que se realizan durante el ciclo de vida incluyen dos tipos de tareas, la verificación y la validación. La verifica-ción responde a "¿se está construyendo el producto de manera correcta"? (¿es-tá construyéndose de acuerdo con su especificación?), y la validación a ¿"se está construyendo el producto correctamente"?, (¿satisface las expectativas del cliente?).

La verificación es el proceso de evaluación de un software para deter-minar que los productos resultantes de una fase de desarrollo satisfacen las condiciones impuestas al principio de esta fase.

La verificación es un proceso incremental que se realiza durante el ciclo de vida de desarrollo del producto, desde la verificación de los requisitos hasta su operación y mantenimiento. La verificación está relacionada siempre con un componente o elemento anterior que describe nuestro producto. Dentro de ella podemos incluir las revisiones y reuniones de evaluación de entregables, como documentos, planes de prueba, código, requisitos o especificaciones.

La validación es el proceso de evaluación de un software durante o al final del proceso de desarrollo para determinar que satisface los requi-sitos especificados.

La validación, a diferencia de la verificación, tiene como objetivo asegurar que el producto satisface las expectativas del cliente. Eso quiere decir que tiene que demostrar que el aplicativo hace lo que el cliente espera que haga, aunque no se haya incluido en la especificación. Dentro de la validación se incluyen las pruebas.

1.4.3. Las pruebas o testing

Las pruebas son un conjunto de actividades en el que un sistema o componente es ejecutado bajo un conjunto de condiciones específicas, se registran los resultados y se hace una evaluación de alguno de los aspectos del sistema o componente (su rendimiento, su usabilidad, su seguridad, etc.).

Ejemplo de verificación

Si revisamos un diseño técni-co detallado de acuerdo técni-con lo que definía el diseño técnico general, sin tener en cuenta si el elemento anterior es correc-to, lo estamos verificando.

(19)

En algunos ámbitos se suele aceptar que las pruebas son únicamente una téc-nica de validación, como una fase del ciclo de vida después de la construc-ción o la implementaconstruc-ción en el que, una vez se ha finalizado el desarrollo del software, el sistema es validado o probado para comprobar su funcionalidad y rendimiento operacional (satisface las expectativas del cliente).

Ahora bien, cuando la verificación se incorpora a las pruebas, estas tienen lu-gar durante todo el ciclo de vida de desarrollo. Para obtener los mejores resul-tados tenemos que combinar la verificación y la validación en el proceso de pruebas. De esta forma, la verificación incluiría procedimientos sistemáticos de revisión, análisis y pruebas desde la fase de requisitos.

1.5. El coste de la calidad

El coste�de�la�calidad es el gasto que tiene que asumir una organiza-ción para asegurar que el producto construido satisface los requisitos del cliente.

La calidad de una aplicación no se alcanza ni al cero por cien ni al cien por cien. En su lugar podemos obtener diferentes grados de calidad. Será respon-sabilidad de la organización decidir cuál tiene que ser el grado de calidad al que quiere llegar y evaluar su coste.

Ved también

En el módulo "Calidad del soft-ware: técnicas de prevención, detección y corrección de de-fectos" se ve con más detalle qué son las pruebas.

(20)

Formalmente, el coste de la calidad (o coste total de la calidad) es la suma de los costes de no conformidad y los costes de conformidad.

Los costes�de�conformidad son los costes relacionados con las activi-dades necesarias para prevenir la mala calidad (reducir los defectos) y evaluar que el producto satisface los requisitos.

Dentro de los costes de conformidad podemos distinguir:

1)�Costes�de�prevención. Son los costes asociados a la prevención de defectos.

Si podemos evitar la aparición de errores, podemos evitar el coste de localiza-ción y correclocaliza-ción de los mismos. Dentro de los costes de prevenlocaliza-ción encon-tramos, entre otros, los relativos a las siguientes actividades:

• Inversión en desarrollo y mantenimiento de infraestructuras y procesos para el aseguramiento de la calidad: procedimientos, métricas de calidad, entorno de integración continua, sistema para la gestión de la configura-ción, etc.

• Actividades de formación y certificación de las personas. Actividades de difusión de buenas prácticas en la construcción del software, su diseño, etc.

• Control del funcionamiento del aseguramiento de la calidad con revisio-nes internas, auditorías externas, etc.

• Mejora continua de los procesos de desarrollo (basados, por ejemplo, en CMMI).

Ved también

Veremos CMMI con más de-talle en el subapartado 3.2 de este módulo.

(21)

2)�Costes�de�evaluación. Costes asociados al análisis y las pruebas del

pro-ducto para validar que cumple los requisitos. Dentro de ellos se incluyen las revisiones y las pruebas.

Los costes�de�no�conformidad son los costes derivados de una mala calidad.

Los costes de no conformidad se pueden clasificar en dos grupos:

1)�Costes�de�fallo�interno. Son los costes relacionados con la corrección de los

defectos que han sido detectados en la evaluación (con revisiones o pruebas) antes de que el software fuera instalado en las dependencias del cliente y de que el aplicativo estuviera ya abierto a los usuarios finales. Incluye, entre otros: • costes de rediseño del aplicativo,

• costes de reprogramación o corrección de defectos, • costes de repetición de revisiones y pruebas.

2)�Costes�de�fallo�externo. Son los costes asociados a la corrección de defectos

que han sido detectados por usuarios o equipos de mantenimiento una vez el producto quedó liberado en el entorno de producción. Se incluyen entre otros: • costes de rediseño, corrección de defectos y repetición de revisiones y

prue-bas;

• costes relacionados con la gestión de reclamaciones y quejas de los usua-rios;

• activación de períodos de garantía;

• reclamaciones al proveedor en caso de fallos críticos (por ejemplo, en caso de un software crítico de sistema de vuelo);

• daños a otros proyectos que se integran en el sistema y son retrasados por sus fallos (que se propagan a otros proyectos, como un efecto dominó); • aspectos cualitativos: pérdida de imagen, pérdida de fidelización de los

usuarios o clientes...

Los costes de no conformidad son costes llamados ocultos porque no suelen estar medidos en las organizaciones. Si la dirección los conoce valorará positivamente invertir más en calidad.

Existen algunos tipos de características, como el rendimiento, la usabilidad, la facilidad de mantenimiento y la seguridad, que acostumbran a tener un impacto alto en el coste y son obviados en algunas organizaciones.

Costes superiores

El proceso de diagnóstico y co-rrección de un fallo externo es mucho más complejo que el de la corrección de un fallo interno, por lo que sus costes son muy superiores.

(22)

Costes del mantenimiento del software

El mantenimiento es ignorado en algunos casos por los arquitectos y programadores de una aplicación, que buscan ofrecer lo más rápidamente posible una aplicación que fun-cione, sin considerar que habrá que mantenerla y evolucionarla posteriormente, quizá durante años. El coste asociado al impacto por tener una aplicación difícil de mantener puede ser muy grande, ya que cualquier cambio puede implicar un esfuerzo mayor del que realmente sería necesario si el aplicativo se hubiera diseñado correctamente.

Por último, tenemos que tener en cuenta que los costes de conformidad y no conformidad están íntimamente relacionados en diferentes aspectos:

• Si gastamos más en conformidad, gastaremos menos en no conformidad, y al revés.

• Los costes de conformidad son voluntarios, mientras que los de no con-formidad son involuntarios (tendremos que asumirlos si hay algún fallo). • Los costes de conformidad son necesarios, mientras que los de no

confor-midad son evitables.

• Los costes de conformidad son una inversión, por lo que hace falta que se justifiquen muy claramente a la dirección y se especifique cómo reducirán los costes de no conformidad. Los costes de no conformidad son un gasto.

(23)

2. Los defectos. Causas y ciclo de vida

2.1. Breve historia de los defectos más famosos

2.1.1. El primer defecto conocido

El origen histórico más conocido del que fue el primer defecto lo encontra-mos el 9 de septiembre de 1947 en la Universidad de Harvard. Después de su-frir continuos problemas por el mal funcionamiento de una máquina llamada Mark II Aiken Relay Calculator, unos operadores realizaron diferentes pruebas para intentar averiguar el origen del problema. Hasta que finalmente lo en-contraron: una polilla atrapada entre los puntos de un relay. Los operadores informaron del hallazgo con la siguiente frase:

"Primer caso puntual de hallazgo de un insecto (bug)".

Y publicaron que habían "debugado" la máquina (eliminado el bug), introdu-ciendo así también el concepto debugging o depuración en el mundo informá-tico.

Hasta 1988 se podía ver en el museo de computadores del Naval Surface Warfare Center (Dahlgren, Virginia) el libro de registro del incidente con la polilla todavía enganchada con cinta aislante.

Bugs

Los defectos también reciben el nombre de bugs (insectos, en inglés). Se considera que el origen de esta relación se debe a la anécdota mencionada.

(24)

2.1.2. Therac-25 (1985-1987)

Therac-25 es el nombre de una máquina de radioterapia producida en Canadá que fue noticia entre 1985 y 1987 por haber provocado al menos seis acciden-tes, tres de ellos mortales. Los pacientes recibieron una radiación cien veces superior a la dosis esperada.

La máquina ofrecía dos modos de terapia de emisión de radiación, uno de baja intensidad, basado en la emisión de haces de electrones, y uno de alta intensidad, que convertía los haces de electrones en rayos X con un filtro que hacía que estos se repartieran en un área más amplia. El problema se origina-ba cuando se activaorigina-ban los haces de alta intensidad en lugar de los de origina-baja intensidad sin activar el filtro. Eso hacía que los pacientes recibieran una dosis muy superior.

Therac-25

El software tenía en cuenta en qué orden escogía las opciones el operador. Si este elegía primero el modo de haces alto y después se daba cuenta de que se había equivocado y escogía el modo de haces bajo, todo eso en un intervalo de 8 segundos de tiempo, el sistema no activaba el filtro y la radiación era mucho mayor. Esta secuencia era a priori improbable, y el problema2 no se reprodujo

durante largo tiempo.

2.1.3. Ariane-5 (1996)

(2)Este tipo de defecto se llama

"condición de carrera".

La Agencia Espacial Europea (AEE, o ESA por sus siglas en inglés) creó en 1996 un cohete de nueva generación más grande y potente y con más capacidades que su predecesor Ariane-4. El proyecto tuvo un coste de 6.000 millones de euros.

El primer lanzamiento, denominado vuelo 501, se realizó el 4 de junio de 1996 y fue un fracaso, ya que el cohete explotó 39 segundos después de su lanzamiento.

El motivo de la explosión se atribuyó a que una de las unidades de 60 bits que controlaban la trayectoria del cohete realizó unos cálculos y emitió el resultado a una unidad de 16 bits. Esta unidad no pudo procesar el cálculo, ya que el número que recibió era muy grande y no podía ser representado en 16 bits. La unidad dio un mensaje de error y se desconectó. Rápidamente se activó un sistema de emergencia para contrarrestar el problema, pero el software era idéntico al que había fallado, interpretó que estaba fuera de control e inició una operación de autodestrucción.

El error humano se produjo por utilizar el anterior sistema operativo del Aria-ne-4 (en lenguaje Ada) sin haber valorado que el nuevo cohete sería más rápi-do y necesitaría almacenar una mayor información.

(25)

2.1.4. Mars Climate Orbiter (1998)

La Mars Climate Orbiter (MCO) era una sonda de la NASA que se lanzó desde Cabo Cañaveral el 11 de diciembre de 1998 y llegó a Marte el 23 de septiembre de 1999 después de nueve meses y medio de trayecto. La misión, llamada "Mars Surveyor 98 Orbiter," tenía que estudiar el clima de Marte.

La MCO se destruyó por un error de navegación. El equipo de control en la Tierra hacía uso del sistema anglosajón de unidades (millas) y envió datos a la nave, que utilizaba el sistema métrico decimal (kilómetros). Así, cada vez que se encendían los motores la sonda se acercaba más y más al planeta en lugar de mantener su trayectoria. Finalmente, la sonda se acercó a solo 57 km de altura, en lugar de los 140-150 previstos, y quedó destruida por la fricción con la atmósfera del planeta.

2.1.5. Efecto 2000

A lo largo de los años noventa, para ahorrar espacio de almacenamiento de memoria, los desarrolladores omitían en las fechas de los programas los dos primeros dígitos del año, asumiendo que el software solo funcionaría durante los años que empezaran con 19 (1975, 1976...). Ello implicaba que el día des-pués del 31 de diciembre de 1999 sería interpretado por los sistemas como el 1 de enero de 1900, y todas las fechas introducidas pasarían a estar consideradas por el sistema dentro del siglo XX. Al acercarse el año 2000, en previsión del

caos y el colapso mundial que se anunciaba, se invirtieron grandes cantidades en corregir las aplicaciones.

Si bien creemos que el efecto se ha superado y no volverá a aparecer existe un caso similar, el efecto 2038. La mayoría de los sistemas de 32 bits usan un tipo de datos time_t para almacenar un contador de segundos con signo (entre –2.147.483.648 y 2.147.483.647) que empezó el 1 de enero de 1970. Un segundo después de las 03:14:07 hora UTC del 19 de de enero del 2038 el contador se desbordará y saltará al valor mínimo, interpretado como el año 1901 o el año 1970 (según como esté implementado).

2.1.6. Consulta de la votación de la Diagonal (2010)

Barcelona sometió a referéndum popular, en mayo del 2010, la transforma-ción o no transformatransforma-ción de su avenida de la Diagonal para ubicar el nuevo tranvía y reducir el tráfico de coches. Los ciudadanos podían escoger entre tres opciones: la creación de un bulevar similar al existente; una rambla central que obligaba a mover cuatro hileras de árboles, con un coste de 70 millones de euros; o no realizar ninguna acción y mantener la Diagonal tal como se encontraba en aquel momento.

(26)

Durante el referéndum se produjeron diferentes fallos informáticos: errores de conexión, sesiones caducadas antes de la finalización de la votación, suplan-tación de la vosuplan-tación, repetición de la vosuplan-tación varias veces por la misma per-sona, etc. El software tampoco cubría al 100% los requisitos, pues si bien daba tres opciones como se había definido, la opción C indicaba "Ninguna de las anteriores", en lugar de "No quiero que se haga ningún cambio en la Diagonal".

Titular de La Vanguardia sobre los problemas en la votación sobre el cambio en la Diagonal

Algunos de los fallos fueron reproducidos por varios cargos políticos y regis-trados por algunos medios de comunicación. Las diferentes críticas provoca-ron la dimisión de algunos cargos institucionales.

2.2. Causas de los errores

Como ya hemos visto anteriormente, todas las causas de los errores son huma-nas. Los analistas, programadores, probadores, expertos en documentación, gestores y, a veces, los propios usuarios o clientes cometen errores. Incluso en los casos en que aseguramos que los errores se deben al entorno de desarrollo (generadores, herramientas de desarrollo, etc.) la causa sigue siendo un error de alguna persona que trabajaba con dicho entorno de desarrollo.

Podemos encontrar diferentes causas de los errores humanos en el desarrollo: • Errores�de�formación�y�experiencia. La falta de conocimiento o

expe-riencia en el uso de los lenguajes de programación, técnicas y herramien-tas es uno de los errores más comunes.

(27)

Ejemplo

Un analista con falta de experiencia expresa en UML una herencia entre clases como una asociación simple. El programador construye el componente de forma incorrecta y los restantes componentes duplican el código, en vez de heredarlo por este error.

Errores�de�comunicación. Un error de comunicación entre el cliente y

el desarrollador o dentro del equipo de desarrollo acostumbra a provocar que no se cubra de forma correcta la necesidad deseada.

Ejemplo

Un programador desarrolla una interfaz en la que genera una nueva excepción, pero no la comunica al programador que usa dicha interfaz. El programador no gestiona por lo tanto la excepción, y esta puede llegar al usuario.

Errores�en�los�requisitos: definición errónea de los requisitos, ausencia de

requisitos vitales, incompletud, inclusión de requisitos no necesarios, etc.

Ejemplo

En el sistema VCV, los requisitos especificaban que para el pago se tenían que aceptar tarjetas bancarias de débito, pero no decía nada respecto de las tarjetas bancarias de cré-dito, aunque el cliente esperaba que estas también fueran aceptadas.

Omisión�o�desviación�deliberada�de�los�requisitos. A veces, los

desarro-lladores pueden desviarse de los requisitos de forma deliberada.

Ejemplo

Mejoras no aprobadas o no comunicadas al cliente son incluidas sin aprobación de este, que según el desarrollador no tienen ningún impacto, pero que en realidad acaban pro-vocando defectos en el software.

Errores�de�transcripción. En este caso, el desarrollador sabe lo que tiene

que hacer y cómo, pero comete un error al hacerlo.

Ejemplo

El programador olvida inicializar una variable, a pesar de saber que siempre se tienen que inicializar las variables.

Proceso�inmaduro�o�mal�definido. Un proceso mal definido puede dirigir

incorrectamente las actividades que realiza el desarrollador.

Ejemplo

La organización no ha implantado ningún seguimiento de los defectos abiertos, por lo que estos son informados verbalmente.

Restricciones�en�tiempo. Bajo restricciones de tiempo y presiones en la

(28)

Ejemplo

El cliente ejerce presión sobre el proveedor de desarrollo para obligarle a entregar antes de tiempo a pesar de no estar realizadas las pruebas. El proveedor no puede validar la corrección de las funcionalidades implementadas, por lo que aparecen un gran número de defectos.

2.3. Introducción y eliminación de los defectos. Coste de su corrección

Los defectos, consecuencia de los errores que hemos estudiado en el subapar-tado anterior, son introducidos en diferentes momentos del ciclo de vida del desarrollo, pero ¿en cuáles de ellos se introducen más?, y ¿cuándo acostum-bran a ser detectados?

Esquema

Diferentes estudios han intentado evaluar en qué punto del ciclo de vida se introducen más defectos y cuándo son detectados. Estos estudios, a pesar de tener pequeñas diferencias entre sí, demuestran que:

La mayoría de los defectos se introducen durante las fases de requisitos y diseño, pero son detectados en las pruebas de aceptación del usuario y en producción.

Pruebas de aceptación

Aunque lo veremos con más detalle en el módulo "Calidad del software: técnicas de pre-vención, detección y corrección de defectos", las pruebas de aceptación son aquellas que se realizan antes de que el aplicativo se ponga en producción, en que el cliente confirma que el producto hace lo que se deseaba.

(29)

Asimismo, el coste de corrección o eliminación de un defecto se incrementa a medida que se avanza en el desarrollo y el defecto permanece sin ser descu-bierto.

Cuanto más tarde se detecte un defecto mayor será su coste de correc-ción.

Proporción 1:10:100

Algunos estudios establecen que el coste de la corrección de un defecto tiene una pro-porción de 1:10:100. Eso quiere decir que si en la fase de requisitos y diseño el coste de corrección de un defecto es 1 (1 hora, 1 euro...), el coste relativo será 10 si se corrige en la fase de pruebas y 100 si se tiene que corregir ya en producción, cuando el defecto es visible a los usuarios externos.

El incremento de coste a medida que el defecto sigue sin ser descubierto justi-fica la necesidad de incluir revisiones durante las fases iniciales del proyecto y la realización de pruebas iterativas durante la construcción, antes de que el producto esté finalizado.

2.4. Gestión de los defectos

Los defectos tienen que ser registrados y gestionados. Tenemos que saber qué defectos se han detectado, en qué estado se encuentran (corregidos, pendien-tes...), e incluso qué desarrollador tiene asignada su evaluación y corrección.

Lectura recomendada Barry Boehm publicó en su libro Software Engineering

Eco-nomics en 1981 que el coste

de eliminación de un defecto crece exponencialmente en cada fase hasta ser descubier-to.

El registro puede realizarse en una hoja de cálculo o en una base de datos, pero la mejor alternativa es utilizar un sistema dedicado que restrinja las reglas y el proceso de gestión y facilite el mecanismo de presentación de informes.

Es habitual hablar de gestión de defectos para referirse a la gestión de incidencias. En realidad, tendríamos que decir gestión de incidencias, ya que podemos registrar acontecimientos que no son realmente defectos.

2.4.1. Contenido de un informe de defecto

Cualquier defecto detectado tendrá que ser registrado e informado. A fin de que el defecto pueda ser gestionado correctamente y eliminado de forma efec-tiva, hace falta que sea definido de la siguiente forma:

Objetiva. No se tiene que criticar el trabajo realizado por ningún otro, ni

ser subjetivos o emocionales.

Específica. En un informe solo ha de aparecer representado un único

de-fecto, nunca varios al mismo tiempo.

Herramientas de gestión de defectos

Existen diferentes herramientas de gestión de defectos, como, por ejemplo, Trac, Bugzilla o JIRA.

(30)

Concisa. El informe tiene que ser simple e "ir al grano" (reducir

informa-ción superflua o compleja).

Reproducible. Tiene que incluir la información mínima que permita a

cualquier persona reproducir el problema.

Explícita. Se tiene que dar información clara y facilitar las fuentes en las

que se puede encontrar la información (capturas de pantalla que represen-tan el fallo...).

Persuasiva. Tiene que motivar a los desarrolladores para resolverlo.

La clasificación o información de los defectos puede realizarse de distintas formas: según la fase en que sean detectados, el tipo de entregable donde se encuentren, su impacto, etc. Cualquier organización tiene que establecer cuál será su forma de clasificar los defectos y aplicarla a todos los proyectos de forma única.

Importancia del defecto

Uno de los aspectos más relevantes en la gestión de los defectos es saber qué importancia tienen. Esta puede depender de varios factores: sus consecuencias o impacto (severidad), su frecuencia o probabilidad (cuántas veces tiene lugar el defecto), su coste de corrección o el coste de instalación de esta corrección, entre otros.

Lo más común es usar la severidad del defecto para establecer su importancia. La severidad indica el impacto, inmediato o no, de un defecto sobre el sistema, independientemente de su probabilidad de ocurrencia bajo las condiciones de los usuarios finales o la afectación que pueda tener en los usuarios (un usuario, muchos usuarios, internos, externos...). Esta información la suele introducir el probador o la persona que ha podido reproducir el fallo (un usuario, un desarrollador...).

La severidad es el grado del impacto que tiene un defecto sobre el uso de un sistema.

Si bien existen diferentes maneras de asignar la severidad a un defecto, pode-mos usar la clasificación de la siguiente tabla.

Severidad Descripción Valor

Crítica El defecto podría tener consecuencias desastrosas para el sistema. 1 Alta El defecto puede tener consecuencias serias para el sistema. Evita el cumplimiento de una tarea

(31)

Severidad Descripción Valor

Media El defecto puede tener consecuencias serias, pero existe una solución alternativa o paliativa. 3 Baja El defecto puede tener un bajo impacto en el sistema. Es fácil de corregir. 4 Sin efecto Se trata de un defecto cosmético o trivial que no tiene ninguna consecuencia negativa, pero que

se tiene que corregir (errores ortográficos, alineaciones incorrectas...). 5

Solución alternativa

Una solución alternativa o paliativa (workaround, en inglés) es un método temporal que nos permite conseguir un objetivo cuando el camino tradicional no funciona. Este mé-todo temporal se mantiene hasta que se corrige el problema que impide la ejecución del método habitual.

Si una organización no tiene muchos defectos, la severidad puede ser el único factor de importancia del defecto, pero si existe un volumen grande de defec-tos se hace necesario fijar un criterio para establecer el orden de corrección de los defectos que tengan un mismo nivel de severidad. Para resolverlo se usa habitualmente su probabilidad de ocurrencia, como se representa en la siguiente tabla.

Probabilidad Descripción Valor

Siempre El defecto se reproduce siempre. 1

Habitualmente El defecto se da a menudo. 2

Algunas veces El defecto solo se reproduce bajo determinadas condiciones. 3 En raras ocasiones El defecto no se puede reproducir casi nunca. 4

Nunca No se reproduce nunca. 5

Con los valores de severidad y probabilidad alcanzados podemos obtener un valor final del valor de su prioridad como:

Prioridad defecto = Severidad × Probabilidad

Reflexión

Si dos defectos tienen el mis-mo nivel de severidad ¿cuál hay que corregir primero?

Cuando más pequeño sea este valor más importante será el defecto y antes tendrá que ser corregido3.

Estado del defecto. Su ciclo de vida

El estado de un defecto determina cuál es su ciclo de vida. Un defecto pasa a lo largo del tiempo por los siguientes estados:

1)�Nuevo. El defecto se acaba de registrar y está pendiente de que sea asignado

a un desarrollador para su resolución.

2)�Asignado. El defecto se encuentra asignado a un desarrollador a fin de que

lo evalúe y corrija.

(3)En casos especiales se puede

de-terminar la corrección de defectos con poca severidad y alta proba-bilidad si el coste de corrección es muy pequeño (se da una mejora al usuario con poco esfuerzo).

(32)

3)�Resuelto. El desarrollador ha resuelto el defecto. En este caso se informa

el motivo de resolución (corregido, inválido, no se corregirá, duplicado, no se puede reproducir, etc.).

4)�Reabierto. El probador ha encontrado que el defecto no está corregido o

solo lo está parcialmente.

5)�Verificado. Se ha comprobado mediante alguna prueba que el defecto ha

sido corregido correctamente.

6)�Cerrado. Es el estado al que se pasa un defecto una vez se ha desplegado la

corrección en el entorno productivo.

Otra información del defecto

Además de la severidad, el estado o la resolución de un defecto se pueden registrar otros tipos de información, entre otros:

Campo Descripción Identificador�del�defecto Código único para ser referenciado

Originador ¿Quién ha encontrado el defecto? (nombre de la persona, teléfono de contacto, correo, etc.).

Fecha ¿En qué fecha se informó y reprodujo el defecto?

Causa�sospechosa�y�causa�real El usuario puede informar sobre cuál cree que es la causa, y, una vez corregido el defecto, se puede informar sobre cuál era la causa real.

Resultados�esperados�y�reales ¿Cuál era el resultado que se esperaba? ¿Cuál ha sido el re-sultado obtenido?

Defectos sin corregir

En algunos casos el defecto no se corregirá. Por ejemplo, cuando hay un evolutivo en marcha y se elimina la función que provoca el defecto, ya que hay un rediseño del aplicativo.

(33)

Campo Descripción

Entorno ¿En qué entorno se ha dado el problema? (versión del siste-ma operativo, navegador...).

Tipo�de�defecto Lógico, datos incorrectos, etc.

Ficheros�adjuntos Para facilitar información del defecto se pueden adjuntar, por ejemplo, capturas de pantalla con el mensaje de error mostrado en la pantalla del usuario.

Persona�asignada Persona asignada para la resolución del defecto.

Versión Versión de la aplicación (nos permitirá comparar el número de defectos entre versiones, y evaluar si hay o no mejora) 2.4.2. Proceso de gestión o tratamiento de un defecto

Una vez se ha registrado un defecto tenemos que gestionarlo con su evaluación y corrección.

En el tratamiento de un defecto podemos considerar cuatro fases: las de su reconocimiento, investigación, acción de su corrección y su cierre. Dentro de cada fase podemos incluir tres pasos que actualizan la información asociada al defecto; esos pasos son los de su registro, su clasificación y la identificación de su impacto (severidad, prioridad...):

1)�Reconocimiento. Esta fase se inicia cuando se encuentra el defecto y

fina-liza cuando este es asignado a alguien para su investigación. En el primer paso del registro se identifican y se informa de, entre otros, el síntoma, el entorno (navegador, sistema operativo...) o la hora en que se ha reproducido. En el de clasificación podemos informar, por ejemplo, la fase del proyecto en la que se ha dado el defecto (pruebas, diseño, etc.) o su repetibilidad. Por último, du-rante la identificación del impacto se puede informar de su severidad.

IEEE 1044

El estándar IEEE 1044 descri-be el proceso de gestión de un defecto, así como la informa-ción del defecto que se tiene que introducir en cada fase del proceso.

(34)

2)�Investigación. De acuerdo con la información proporcionada en el informe

del defecto, se realiza un análisis para comprobar si realmente es un problema, cuál es el impacto de su corrección y su coste. En esta fase, dicha información es evaluada en un comité de control de cambios (formado por diferentes im-plicados en el proyecto, tanto por parte del cliente como del proveedor) para establecer la priorización final y la asignación de paquetes de trabajo por di-ferentes defectos.

3)�Acción. Durante esta fase se identifican cuáles son los elementos o

com-ponentes a corregir, quiénes realizarán la corrección y en qué fecha se habrá resuelto. En el paso de clasificación se informa de la resolución y de su motivo. Por último, se tiene que verificar mediante alguna prueba que realmente se ha corregido el defecto.

4)�Cierre. Una vez han sido validados todos los cambios, se notifica al cliente

de su resolución. El cliente es, habitualmente, quien tiene que dar por cerrado el defecto cuando valide que la corrección funciona.

2.5. Algunos defectos poco habituales

En general, los defectos suelen ser "fácilmente" reproducibles, pero existen al-gunos tipos de defectos realmente extraños, ya que se desconoce por qué apa-recen o por qué son muy difíciles de reproducir. Algunos de estos defectos son:

Versiones con diversos defectos

En general no se generan ver-siones por cada defecto a co-rregir, sino que se definen pa-quetes de trabajo o versiones en los que se incluye la correc-ción de varios defectos al mis-mo tiempo.

Heisenbug. Este defecto toma su nombre del principio de incertidumbre

de Heisenberg. Se caracteriza por ser un defecto que en el momento de ser estudiado desaparece (ya no se reproduce) o altera su comportamiento.

Alteración del estado inicial

Cuando ejecutamos un programa en modo de depuración se libera la memoria antes de iniciar el aplicativo, y las variables se cargan en pilas en lugar de registros. Estas diferencias en la ejecución alteran el efecto del defecto o el estado inicial.

Bohrbug. Toma su nombre del modelo atómico de Bohr. Es un defecto

que se reproduce de forma consistente, según un conjunto definido de condiciones pero posiblemente desconocidas. No desaparece o se altera si es observado. Incluye tanto los defectos más fáciles de corregir (si se sabe en qué condiciones se dan) como los más difíciles de detectar y corregir, cuando el fallo puede darse solo en circunstancias especiales y poco ha-bituales. En estos casos el defecto puede quedar residente y no aparecer hasta mucho tarde en el tiempo.

Ejemplo

Un ejemplo habitual se da cuando el software está preparado y probado, inicialmente, con un volumen de datos. Cuando la realidad supera las expectativas y el volumen de datos es infinitamente superior, puede suceder que el software aborte por no estar pre-parado para asumir ese volumen.

Principio de Heisenberg

El principio de Heisenberg es un principio de física cuántica que considera que los observa-dores pueden afectar al com-portamiento de un elemento observado simplemente por el hecho de observarlo.

Reflexión

¿Habéis escuchado alguna vez la frase "por qué da este error, si nunca lo había dado y hace tiempo que el software es ope-rativo"?

(35)

3. Modelos de calidad y estándares

Son diversos los organismos que se preocupan desde hace tiempo de desarro-llar modelos y estándares que conduzcan a las organizaciones a obtener y ga-rantizar productos de software de calidad.

Un modelo de calidad es un conjunto de características y relaciones que sientan las bases para especificar requisitos de calidad y evaluarlos.

Dentro de los modelos establecidos podemos diferenciar tres ámbitos de apli-cación:

1)� Organización� o� sistema� (gestión� de� la� calidad� total). Ejemplos: ISO

90004, EFQM.

2)�Proceso. Requisitos de calidad para el proceso de desarrollo. Ejemplos:

CM-MI, SPICE.

3)�Producto. Requisitos de calidad para el producto. Ejemplo: ISO 9126.

Algunos de estos modelos permiten que entidades externas puedan reconocer "objetivamente" si una organización puede entregar productos de calidad. A continuación veremos algunos de los modelos de referencia más conocidos en cada uno de los tres ámbitos.

(36)

3.1. Modelos de gestión de calidad en la organización

3.1.1. Normas ISO

La International Organization for Standardization (ISO) es la organización in-ternacional para la estandarización y es responsable del desarrollo de una fa-milia de estándares llamada ISO 9000 para la implementación y operación de sistemas de gestión de calidad eficaces, de aplicación a cualquier producto tangible creado, sea o no de software.

ISO

La organización ISO se encarga de promover el desarrollo de normas internacionales para la fabricación, comercialización y comunicación en todas las ramas industriales, excep-to la eléctrica y la electrónica. Algunos ejemplos son los códigos de países, el formaexcep-to MPEG, los productos sanitarios, la mejora y evolución de procesos de desarrollo, el for-mato openDocument, la gestión medioambiental, etc.

Dentro de la familia ISO 9000 podemos encontrar las siguientes normas: • ISO�9000. Describe los fundamentos de los sistemas de gestión de la

cali-dad y sus conceptos.

Estándares de pago

Los estándares de la ISO son de pago, excepto en algunos casos muy puntuales.

ISO�9001. Especifica los requisitos4 genéricos aplicables a cualquier

orga-nización que quiera demostrar sus capacidades de generar productos que cumplan con los requisitos del cliente.

ISO�90003. Anexo de aplicación de la ISO 9001 para organizaciones

dedi-cadas al desarrollo de software.

ISO�9004. Da directrices para mejorar la forma de trabajo de la

organiza-ción y la satisfacorganiza-ción del cliente

ISO�19011. Directrices para la auditoría de sistemas de gestión de la calidad

y sistemas de gestión medioambiental.

Las normas establecen el camino que una organización debe seguir para im-plantar un sistema de gestión de la calidad; dicho camino consta de los si-guientes pasos:

1) Determinar las necesidades y expectativas de los clientes y otras partes

in-teresadas.

2) Establecer la política y objetivos de calidad de la organización.

3) Determinar los procesos y responsabilidades necesarias para conseguir los

objetivos de calidad.

(4)Los requisitos para los

produc-tos de la ISO 9001 no están descri-tos en ninguna de las normas de la familia y se deroga que sean los clientes o disposiciones reglamen-tarias quienes las definan.

(37)

4) Establecer los métodos para medir la eficacia y eficiencia de cada proceso. 5) Aplicar estas medidas para determinar la eficacia y eficiencia de cada

pro-ceso.

6) Determinar los medios para prevenir no conformidades y eliminar sus

cau-sas.

7) Establecer y aplicar un proceso para la mejora continua del sistema de

ges-tión de la calidad.

ISO 9000

La norma ISO 9000 es la norma que define el enfoque de un sistema de ges-tión de calidad regido por diferentes principios básicos en las organizaciones: foco en el cliente, liderazgo, participación del personal, enfoque basado en procesos, mejora continua, toma de decisiones basada en hechos y búsqueda de relaciones recíprocas beneficiosas con el proveedor.

Eficacia

Recordad que la eficacia es la extensión en la que se realizan las actividades planificadas y se consiguen los resultados pla-nificados, mientras que la efi-ciencia es la relación entre los resultados conseguidos y los recursos utilizados.

El modelo de sistema de gestión de calidad se basa en el ciclo de Deming, que establece cuáles son los pasos que se tienen que realizar en un área de mejora (proceso, organización...): planificar, hacer, verificar y actuar.

ISO 9001

La norma ISO 9001 da concreción a la norma ISO 9000 con la incorporación de los requisitos específicos de los sistemas de gestión de calidad según un enfoque basado en procesos. Se definen los criterios generales y los criterios específicos en diferentes áreas. Como criterios generales, establece que la or-ganización tiene que velar por:

Deming

El ciclo de Deming contribu-yó notablemente a la mejora de los procesos de producción en Japón después de la Segun-da Guerra Mundial. Es asimis-mo uno de los referentes en el concepto de gestión de cali-dad total.

Figure

Actualización...