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

Calidad delsoftware: gestiónde la calidad ymétricas Xavier Escudero Sabadell PID_00178930

© FUOC • PID_00178930 Calidad del software: gestión de la calidad y métricas

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 escritade los titulares del copyright.


Í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


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

© FUOC • PID_00178930 5 Calidad del software: gestión de la calidad y métricas

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 calidad 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, conventajas especiales para los estudiantes, denominado Viajes Campus Virtual (de ahoraen adelante VCV). Este sistema se desarrollará en una arquitectura de tres capas y tendráque ser usable, fiable y robusto.


Objetivos

Los objetivos que los estudiantes tenéis que haber alcanzado una vez trabaja-

dos los contenidos 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.


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.1ejemplos reales de errores enla 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, ladocumentación (diseño téc-nico, diseño funcional...), losprocedimientos y los datos ne-cesarios a fin de que funcioneel sistema.


• 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 sistemaantigoteo...

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 enla gestión de la calidad, reco-nocido sobre todo por su apli-cación del principio de Paretoa temas de calidad, y su ges-tión de la calidad total.Crosby ha sido un empresarionorteamericano que aplicó ala práctica la gestión de la ca-lidad y consiguió reducir enun 30% los costes inicialmentedebidos a la mala calidad. Asi-mismo, es reconocido por sufrase "hacerlo correctamente laprimera vez".

Aplicativo VCV de la UOC

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


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 delVCV

La primera versión del VCV hasido aceptada por el cliente,pues se han cubierto todos losrequisitos establecidos. Díasdespué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 webssimilares que ya conocíamos y la identificamos como de calidad. Esta catalogación labasamos 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 ofreceuna buena usabilidad, con la incorporación de ayudas contextuales, navegación sencillay 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 defacto e incorporamos puntos de control para cada actividad. El aplicativo resultante, alseguir las diferentes normas establecidas, se produce con calidad.

Ved también

Los modelos CMMI e ISO9001 los veremos en lossubapartados 3.1 y 3.2 de estemódulo.


• 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 uncoste de 1 euro por descarga. El 80% de los usuarios está dispuesto a pagarlo, según unaencuesta.

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 autorde libros tan reconocidos co-mo Ingeniería del software. Unenfoque práctico.


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 haobviado cerrar la conexión enla base de datos una vez que elusuario ha finalizado la reserva.


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 solicitado 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 deaccesos realizados consuma las máximas conexiones disponibles se producirá un fallo enlos 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énpuede cometer errores, ya quepuede especificar un caso deprueba de forma incorrecta,con lo que la ejecución de laspruebas no obtendría ningúnresultado objetivo.


• 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 incidencia

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. Secomprueba que esta funcionalidad no había sido prevista en los requisitos y se clasificacomo 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 cambios 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 deincidencias

Habitualmente, las incidenciasson registradas en aplicacionesespecíficas de gestión de inci-dencias que permiten su segui-miento.


• 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 delprograma (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 demantenimientoadaptativo

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


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


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 calidad 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 veremosejemplos de modelos de mejo-ra de procesos, mientras que elapartado 4 lo dedicaremos ex-clusivamente a las métricas.


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 crearel 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 proce-so, selección de herramientas.

Ejemplos: revisiones, pruebas.


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 con loque definía el diseño técnicogeneral, sin tener en cuenta siel elemento anterior es correc-to, lo estamos verificando.


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 implementació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 detallequé son las pruebas.


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 corrección de los mismos. Dentro de los costes de prevenció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 deeste módulo.


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 externoes mucho más complejo queel de la corrección de un fallointerno, por lo que sus costesson muy superiores.


Costes del mantenimiento del software

El mantenimiento es ignorado en algunos casos por los arquitectos y programadores deuna 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 mantenerpuede ser muy grande, ya que cualquier cambio puede implicar un esfuerzo mayor delque 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.


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 librode registro del incidente con la polilla todavía enganchada con cinta aislante.

Bugs

Los defectos también recibenel nombre de bugs (insectos,en inglés). Se considera que elorigen de esta relación se debea la anécdota mencionada.


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 activaban los haces de alta intensidad en lugar de los de 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.

Accidente del Ariane-5


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 transformació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.


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 votación, repetición de la votació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.


Ejemplo

Un analista con falta de experiencia expresa en UML una herencia entre clases como unaasociación simple. El programador construye el componente de forma incorrecta y losrestantes 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 nola comunica al programador que usa dicha interfaz. El programador no gestiona por lotanto 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 aceptartarjetas 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 queinicializar 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 loque estos son informados verbalmente.

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

entrega, los desarrolladores suelen cometer errores.


Ejemplo

El cliente ejerce presión sobre el proveedor de desarrollo para obligarle a entregar antesde tiempo a pesar de no estar realizadas las pruebas. El proveedor no puede validar lacorrección de las funcionalidades implementadas, por lo que aparecen un gran númerode 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 quese realizan antes de que el aplicativo se ponga en producción, en que el cliente confirmaque el producto hace lo que se deseaba.


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 decorrección de un defecto es 1 (1 hora, 1 euro...), el coste relativo será 10 si se corrige enla fase de pruebas y 100 si se tiene que corregir ya en producción, cuando el defecto esvisible 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 sulibro Software Engineering Eco-nomics en 1981 que el costede eliminación de un defectocrece exponencialmente encada 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ónde defectos

Existen diferentes herramientasde gestión de defectos, como,por ejemplo, Trac, Bugzilla oJIRA.


• 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 tareaesencial de los usuarios.

2


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 quese 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 quenos 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 delmé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álhay 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 defectoscon poca severidad y alta proba-bilidad si el coste de corrección esmuy pequeño (se da una mejora alusuario con poco esfuerzo).


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 sobrecuá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 defectono se corregirá. Por ejemplo,cuando hay un evolutivo enmarcha y se elimina la funciónque provoca el defecto, ya quehay un rediseño del aplicativo.


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 errormostrado 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úmerode 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 undefecto, así como la informa-ción del defecto que se tieneque introducir en cada fase delproceso.


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 diversosdefectos

En general no se generan ver-siones por cada defecto a co-rregir, sino que se definen pa-quetes de trabajo o versionesen 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 deiniciar el aplicativo, y las variables se cargan en pilas en lugar de registros. Estas diferenciasen 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 dedatos 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 esun principio de física cuánticaque considera que los observa-dores pueden afectar al com-portamiento de un elementoobservado simplemente por elhecho de observarlo.

Reflexión

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


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.


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 parala 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 formatoMPEG, 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 sonde pago, excepto en algunoscasos 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 satisfacció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 dela familia y se deroga que sean losclientes o disposiciones reglamen-tarias quienes las definan.


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 laextensión en la que se realizanlas actividades planificadas y seconsiguen los resultados pla-nificados, mientras que la efi-ciencia es la relación entre losresultados conseguidos y losrecursos 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 mejorade los procesos de producciónen Japón después de la Segun-da Guerra Mundial. Es asimis-mo uno de los referentes en elconcepto de gestión de cali-dad total.


• Identificar los procesos necesarios para el sistema de gestión de la calidad

y su aplicación por medio de la organización.

• Determinar cuál es la secuencia e interacción de estos procesos.

• Determinar los criterios y métodos necesarios para asegurar que tanto la

operación como el control de estos procesos son eficaces.

• Asegurar la disponibilidad de los recursos y la información necesarios para

apoyar la operación y el seguimiento de los procesos.

• Realizar el seguimiento, medición y análisis de los procesos.

• Implementar las acciones requeridas para conseguir los resultados planifi-

cados y la mejora continua de estos procesos.

Los criterios específicos se encuentran agrupados en cuatro categorías: "ges-

tión de responsabilidades", "gestión de recursos", "medidas, análisis y mejora"

y "realización del producto".


Ejemplo

Como ejemplo, ved el siguiente extracto del contenido del requisito "5.3 Política de ca-lidad":

"La alta dirección tiene que asegurarse de que la política de la calidad:

a) es adecuada para el propósito de la organización,

b) incluye un compromiso de cumplir con los requisitos y mejorar continuamente laeficacia del sistema de gestión de la calidad,

c) proporciona un marco de referencia para establecer y revisar los objetivos de la calidad,

d) es comunicada y entendida dentro de la organización, y

e) es revisada para su continua adecuación."

Certificación en ISO 9001

Cualquier organización puede ser certificada por una entidad externa certifi-

cadora en ISO 9001. El proceso de certificación incluye una revisión de la do-

cumentación de calidad y una auditoría. Si se obtiene la certificación, esta tie-

ne una validez de cuatro años, pero se realizan visitas anuales para verificar

que el sistema de gestión de calidad se mantiene correctamente.

La Asociación Española de Normalización y Certificación (AENOR) es una de

las entidades certificadoras en ISO 9001 más conocidas en España. Su marca

de conformidad otorgada a una organización le da credibilidad en la consecu-

ción de la ISO 9001. Adicionalmente, aporta la marca IQNet para facilitar su

reconocimiento internacional.

El estándar ISO 9001 ha sido criticado por ser un modelo muy general que no

da información de cómo se tiene que aplicar en diferentes industrias (¿cómo se

aplica, por ejemplo, en las organizaciones que desarrollan software?) o cómo

se aplica en las pequeñas empresas.

ISO 90003

La industria del software del Reino Unido, para suplir las posibles carencias

y dificultades de aplicación de la ISO 9001 al desarrollo del software, creó en

1997 la norma ISO 9000-3 (que en el 2004 pasó a llamarse ISO 90003).

Para cada uno de los apartados de la norma ISO 9001 se incluyen descripciones

de las adaptaciones o interpretaciones necesarias en el caso de las empresas de

desarrollo de software.

Entidad Nacional deAcreditación

Las entidades certificadorasson validadas por el organismooficial de acreditación de en-tidades certificadoras, que enEspaña es la Entidad Nacionalde Acreditación (ENAC).

AENOR y la marca IQNet


Inicialmente no existía ninguna certificación según la ISO 9000-3, que solo

estaba considerada como una guía de aplicación de la ISO 9001. El Reino Uni-

do, mediante la BCS (British Computer Society), definió la técnica TickIt para

poder certificar a empresas que tuvieran experiencia en la industria del soft-

ware y sus procesos.

ISO 9004. El modelo de calidad total

La norma ISO 9004 da directrices, que van más allá de los requisitos estable-

cidos por la ISO 9001, para potenciar la satisfacción de las partes interesadas y

el desarrollo de la organización (extendiendo los objetivos relativos a la satis-

facción del cliente y la calidad del producto definidos en la norma ISO 9001).

En la siguiente tabla se muestran las características y diferencias entre la ISO

9001 y la ISO 9004.

ISO 9001 ISO 9004

Requisitos Directrices de mejora

Satisfacción del cliente Satisfacción de las diferentes partes

Eficacia Eficiencia

Auditoría Autoevaluación

3.1.2. El modelo de excelencia EFQM

TickIt

TickIt es en sí misma materialde orientación para que losdesarrolladores de softwarepuedan alcanzar los objetivosde calidad establecidos en elmarco de la ISO 9001.

En 1988, catorce empresas europeas, líderes de diferentes sectores, fundaron

la European Foundation for Quality Management (EFQM) con el objetivo de

potenciar la posición de las empresas europeas en los mercados mundiales.

EFQM es la creadora y gestora del premio de excelencia EEA (EFQM Excellence

Award), que reconoce la excelencia en las organizaciones, y del modelo de

excelencia EFQM, que actualiza de forma continua con buenas prácticas. Este

modelo sirve de autoevaluación para las organizaciones, que pueden valorar

dónde se encuentran y cómo pueden mejorar.

En general, la ISO 9001 es usada para poder ser certificada por terceros, mien-

tras que el modelo EFQM es más usado para la autoevaluación. El modelo

EFQM, asimismo, especifica con más profundidad la orientación a procesos

y contempla aspectos relacionados con la gestión de recursos humanos, no

considerados en la ISO 9001.

El modelo EFQM se basa en diferentes principios:

• la orientación a los resultados y al cliente,

• el liderazgo en los objetivos,

• la gestión por procesos,

• el desarrollo e implicación de las personas,

Modelo de excelencia

El modelo de excelencia es elconjunto de criterios de refe-rencia, agrupados por áreas,para estructurar un plan quepermita a una organización oparte de ella la mejora conti-nua de su gestión y sus resulta-dos.


• el aprendizaje,

• la innovación,

• la mejora continua,

• el desarrollo de alianzas, y

• la responsabilidad social.

Para evaluar la excelencia de una organización el modelo está estructurado en

nueve criterios (liderazgo, personas...) definidos en dos grupos:

• Agentes�facilitadores�(cinco�criterios). Lo que hace la organización: pro-

cesos y valía de los trabajadores para producir buenos resultados.

• Resultados. Es lo que consigue la organización, como consecuencia de los

agentes facilitadores.

Estos criterios, a su vez, están subdivididos en subcriterios y áreas que se tienen

que abordar en cada uno de ellos. El modelo definido es dinámico, y uno de

sus objetivos es potenciar a los agentes facilitadores con la innovación y el

aprendizaje.

3.2. Modelos de calidad del proceso de software

En este subapartado veremos diferentes modelos relacionados con la mejora

del proceso de desarrollo y de los procesos relacionados con las pruebas. En el

primer caso, un proceso bien definido y de buena calidad permitirá obtener

un mejor producto, mientras que en el segundo caso, si el proceso de pruebas

es eficiente, seremos capaces de encontrar más defectos.


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

de software

Los modelos más utilizados en la industria del software son CMMI (capability

maturity model integrated) y SPICE (software process improvement and capability

determination). Estos dos estándares se están considerando externamente como

una garantía de calidad, y se observa que poco a poco pueden llegar a ser una

exigencia de los clientes con el fin de garantizar que los desarrollos son de

calidad.

Otros estándares de desarrollo

Hay estándares para software que no son tan frecuentes, como el PSP (personal softwareprocess) y el TSP (team software process). Algunos otros organismos también han descritoestándares de desarrollo, sumamente válidos como referencia, aunque pensados específi-camente para sectores muy concretos. En estos casos ya no se trata de recomendaciones,sino de obligaciones legislativas para la venta de productos en ciertos mercados, como,por ejemplo, el representado por la European Space Agency (ESA) y la National Aeronau-tics and Space Administration (NASA) para software vinculado a las misiones en el espa-cio; o la Foods and Drug Administration (FDA) para productos de software dentro delsector alimentario o el sanitario, que van destinados al mercado de Estados Unidos.

CMMI

En los años ochenta, el Departamento de Defensa de Estados Unidos se en-

contró en la necesidad de definir un modelo para evaluar la madurez de los

procesos de desarrollo de sus proveedores y asegurarse así de que estos tenían

la capacidad de entregar el producto deseado con la mayor calidad. En res-

puesta a esta necesidad, el Software Engineering Institute (SEI) desarrolló entre

1987 y 1997 un modelo de evaluación de madurez llamado CMM, formado

por cinco niveles de madurez en los que puede progresar una organización. La

evolución del modelo CMMI tiene como objetivo integrar diferentes modelos

en un solo marco (framework).

Modelos por niveles y porcapacidad

Los modelos de evaluacióny mejora de la calidad de losprocesos de software suelenestar estructurados en dos ti-pos: el de niveles de madurez,en el que una organización ob-tiene una puntuación de formaglobal, y el de niveles de capa-cidad, en el que la organiza-ción obtiene la puntuación porun proceso en concreto (ges-tión de requisitos, verificación,etc.).

CMMI permite que las organizaciones puedan progresar y mejorar ba-

sándose en dos modelos: por madurez o por capacidad.

En el modelo por madurez o representación por etapas, CMMI define cinco

niveles. Cada nivel establece qué conjunto de áreas de proceso tiene que ga-

rantizar la organización. Este modelo permite poder comparar diferentes or-

ganizaciones de forma sencilla.

Nivel de madu-rez organización

Descripción Áreas de proceso incluidas

1)�Inicial Procesos generalmente inexistentesy caóticos

Ninguna

Modelo de mejoresprácticas

CMMI no es un proceso en símismo y tampoco dice cómose tienen que realizar las cosas.Es un modelo de mejores prác-ticas en el desarrollo de siste-mas de información.

Evolución del coste de lacalidad

Diferentes estudios, como losrealizados por Knox y CapersJones, han comprobado que elcoste de la calidad disminuyea medida que se avanza en elnivel de madurez del CMMI.


Nivel de madu-rez organización

Descripción Áreas de proceso incluidas

2)�Gestionado Se han establecido los procesos bá-sicos y hay un primer nivel de disci-plina que obliga a utilizarlos

• Gestión de requisitos• Planificación de proyectos• Monitorización y control de

proyectos• Gestión acuerdos con provee-

dores• Medición y análisis• Aseguramiento de la calidad de

proceso y producto• Gestión de la configuración

3)�Definido Los procesos se encuentran descri-tos más rigurosamente que en elnivel 2, y se integran con los de-más procesos

• Desarrollo de requisitos• Solución técnica• Integración de producto• Verificación• Validación• Foco proceso organizativo• Definición proceso organizativo• Formación organizativa• Gestión integrada proyecto• Gestión de riesgos• Análisis de decisiones y resolu-

ción

4)�Gestionadocuantitativamente

Se establecen objetivos cuantitati-vos para el rendimiento de la cali-dad y el proceso

• Rendimiento organizativo delproceso

• Gestión cuantitativa de proyec-to

5)�En�optimización Se adoptan procesos de mejoracontinua y se realiza una retroali-mentación cuantitativa y pruebaspiloto con nuevas ideas y tecnolo-gías

• Innovación organizativa y des-pliegue

• Análisis causal y resolución

Ejemplo

Imaginemos que el proveedor del VCV se encuentra en el nivel 3. Eso quiere decir queha alcanzado todas las áreas de proceso incluidas en el nivel 3 (desarrollo de requisitos,solución técnica...) y todas las áreas de proceso de los niveles inferiores (gestión de requi-sitos, planificación de proyectos...).

En el modelo por etapas o representación continua, la mejora es realizada por

niveles de capacidad para cada área de proceso. Eso permite que una organi-

zación tenga flexibilidad para seleccionar qué áreas de proceso quiere mejorar

y se pueda evaluar una organización por la madurez que tiene en un área de

proceso concreta.

Nivel de capacidad Descripción

0)�Incompleto El proceso es incompleto, no se ejecuta o se ejecuta deforma parcial.

1)�Realizado El proceso realizado satisface las metas específicas del áreade proceso.

2)�Gestionado Proceso realizado que se planifica y ejecuta de acuerdocon políticas, tiene los recursos adecuados para producirresultados controlados, se monitoriza y se revisa.

Ejemplo

El proveedor del VCV conside-ra que la mejor forma es utili-zar la representación continuay escoger mejorar el área deproceso "Análisis causal y reso-lución" y alcanzar el nivel decapacidad 4 para esta área.


Nivel de capacidad Descripción

3)�Definido Proceso gestionado que se adapta a partir del conjunto deprocesos estándar de la organización, con lo que es másconsistente que en el nivel 2. El proceso es descrito conmayor rigor que en el nivel 2.

4)�Gestionado�cuantitativamen-te

Proceso definido en el que el rendimiento es controladocon técnicas estadísticas y otras técnicas cuantitativas.

5)�En�optimización Proceso gestionado cuantitativamente que se mejora deacuerdo con las variaciones inherentes al proceso.

Cada representación tiene sus ventajas. Algunas organizaciones pueden usar

las dos para establecer sus programas de mejora. Por ejemplo, una organización

puede encontrarse en el nivel 2 de la representación por etapas, pero trabajar

para conseguir un nivel de capacidad 4 en el área de proceso "verificación".

Para cada una de las áreas de proceso, CMMI describe sus objetivos o metas

específicas y las prácticas que se tienen que realizar para alcanzarlas. Asimis-

mo describe metas y prácticas genéricas que se aplican a diferentes áreas de

proceso.


Ejemplo

Arriba se muestra un extracto del área de proceso "validación", donde apare-

cen metas y prácticas específicas que se tienen que tener en cuenta, así como

ejemplos de aplicación.

Evaluación�en�CMMI

CMMI es un modelo, pero ¿cómo puede una organización obtener una certi-

ficación de su nivel de madurez o nivel de capacidades en las áreas de proceso?

Enlace de interés

Se puede obtener informa-ción pormenorizada de CM-MI y del detalle de las dife-rentes áreas de proceso acce-diendo al siguiente enlace:http://www.sei.cmu.edu/cm-mi/

http://www.sei.cmu.edu/cmmi/



Para iniciar un plan de mejora de procesos, la organización tiene que saber

en qué situación se encuentra para compararse con el modelo. La evaluación

SCAMPI (standard CMMI appraisal method for process improvement) determina el

nivel de madurez o capacidad que ha conseguido una organización que aplica

CMMI a sus procesos. Define un método para identificar fortalezas, debilidades

y poder clasificarse con respecto al modelo de referencia. Establece un período

de tres años durante el cual reconoce los resultados obtenidos.

Existen tres clases de evaluaciones:

1)�Clase�A. Es el método más usado, con la mayor cobertura, y el único que

puede proporcionar un sello de nivel de madurez o de nivel de capacidad a

una organización. Esta evaluación es liderada por un SCAMPI lead appraiser

autorizado por el SEI.

2)�Clase�B. Es menos detallado que la clase A y más económico. Se usa como

una evaluación inicial o parcial, que se enfoca a las áreas que requieren aten-

ción. No hace falta que sea realizado por un lead appraiser.

SCAMPI

SCAMPI es un método de eva-luación, no de certificación(aunque muchas organizacio-nes puedan decir que poseenuna certificación en SCAMPI),ya que el SEI no establece unmecanismo de vigilancia pos-terior a la evaluación para ga-rantizar el mantenimiento delos resultados (aunque recono-ce tres años).

3)�Clase�C. Es el más sencillo y económico y se requieren menos conocimien-

tos. Se enfoca a las áreas de más riesgo de la organización.

ISO 15504 (SPICE)

El estándar ISO 15504 –conocido como SPICE (software process improvement

and capability determination)– se usa mayoritariamente en Europa y está menos

extendido en la actualidad que CMMI. En su inicio estableció solo niveles de

capacidad por proceso, pero en el 2008 incorporó la evaluación por niveles de

madurez, equiparándose así a los modelos proporcionados por CMMI.

Enlace de interés

Los resultados de las evalua-ciones los publica el SEI en elhttp://sas.sei.cmu.edu/pars/.Desde aquí podéis consultar,por ejemplo, qué empresas tie-nen un nivel determinado.

A diferencia de CMMI, que define unas áreas de proceso propias, SPICE usa

como modelo de procesos de referencia el establecido por la norma ISO 12207.

Si bien las normas SPICE y CMMI son bastante similares, podemos establecer

algunas pequeñas diferenciaciones que pueden determinar su aplicabilidad,

tal como se ve en la siguiente tabla.

CMMI ISO/IEC 15504

Internacionalidad Estándar de facto de uso internacional Norma internacional

Popularidad Líder (sobre todo en EE. UU.) En crecimiento

Modelo�de�procesos Estructura propia. ISO/IEC 12207.

Modelo�de�evaluación SCAMPI. ISO/IEC 15504

Adaptabilidad Limitada Se puede adaptar más fácilmente

Tamaño�de�la�organización Grandes Todas

ISO/IEC 12207

El estándar ISO/IEC 12207 de-fine los procesos del ciclo devida del desarrollo, manteni-miento y operación de los sis-temas de software.

http://sas.sei.cmu.edu/pars/


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

Los procesos de pruebas son procesos de software, por lo que también pueden

ser mejorados. Si bien CMMI y otros modelos de mejora incluyen actividades

relacionadas con las pruebas, su nivel de detalle y alcance es reducido, por lo

que han surgido diferentes iniciativas o modelos que pretenden cubrir estas

deficiencias.

Los modelos de mejora del proceso de pruebas más conocidos son:

• TMMI (test maturity model integrated)

• TPI (test process improvement)

Todos ellos tienen bastantes similitudes y varían principalmente en su estruc-

turación.

TMMI

El modelo TMMI (testing maturity model integrated) fue desarrollado por Ilene

Burnstein y su equipo del Instituto de Tecnología de Illinois para poder evaluar

y mejorar los procesos de prueba de cualquier proceso de desarrollo.

El modelo TMMI se estructura en cinco niveles de madurez, al igual que CMMI.

Los fundadores del modelo consideran que la estructura de TMMI, similar a

la de CMMI, se tiene que ver como un complemento en CMMI, ya que la

madurez de los procesos de pruebas depende del proceso de madurez general.

STEP y CTP

Otros estándares no tan cono-cidos son STEP (systematic testand evaluation process) y CTP(critical testing process).


Los niveles de madurez son:

• Inicial. Las pruebas se desarrollan sin método después de que el código

haya sido desarrollado, y no se diferencian de la depuración. El objetivo de

las pruebas es comprobar que el software funciona (su funcionalidad mí-

nima). Hay una falta de recursos, herramientas y formación en el equipo.

• Definición. Las pruebas ya se planifican y están separadas de la depura-

ción, pero todavía se realizan a continuación de la codificación. Se usan

técnicas básicas de pruebas y las pruebas ya se realizan por diferentes ni-

veles (unitarias, integración, sistema y aceptación). Algunos de los proble-

mas en este nivel se deben a que la planificación de las pruebas tiene lugar

después de la codificación, y los defectos que se introducen en las fases de

requisitos y diseño se propagan al código, ya que no hay ningún programa

de revisiones para resolverlo.

• Integración. En este nivel las pruebas están integradas en todo el ciclo

de vida. Asimismo hay una organización dedicada a las pruebas, y estas

ya son reconocidas como una actividad profesional. Se usan herramientas

para dar apoyo a las actividades de prueba y el proceso ya es visible en toda

Ved también

Veremos en el módulo "Cali-dad del software: técnicas deprevención, detección y co-rrección de defectos" los dife-rentes niveles de prueba y lasdistintas técnicas existentes.


la organización. En este nivel no existen revisiones todavía y no hay un

programa de métricas para medir la calidad de los procesos y productos.

• Gestión�y�métricas. En este nivel, el proceso es medido y cuantificado

(número de casos de prueba ejecutados, planificados, defectos encontra-

dos...) y ya se encuentran introducidas las revisiones dentro de las activi-

dades de las pruebas o control de calidad. Los casos de prueba de todos los

proyectos son almacenados en una base de datos para que sean reutiliza-

bles y se usen en las pruebas de regresión.

• Optimización,�prevención�de�defectos�y�control�de�calidad. En este ni-

vel se han definido los mecanismos para aplicar mejoras de forma conti-

nua. Se hace un esfuerzo continuado en aprender de la experiencia para

reducir el número de defectos, analizándolos y estableciendo acciones for-

mativas en los equipos para evitarlos. Se da soporte a todas las actividades

con herramientas automatizadas.

TPI

El modelo TPI define diferentes áreas clave, en las que se puede alcanzar un

nivel de madurez A, B, C o D, siendo A el más bajo. El modelo establece qué

criterios o puntos de control se tienen que alcanzar para obtener un nivel

determinado.

No todas las áreas clave tienen los cuatro niveles de madurez (el área de "téc-

nicas de especificación de pruebas" solo tiene los niveles A y B) y existen de-

pendencias entre los diferentes niveles de madurez de las áreas clave, por lo

que para alcanzar un nivel en un área clave puede ser necesario que se hayan

alcanzado determinados niveles de madurez en otras áreas clave.

Independientemente del nivel alcanzado por un área clave, se puede evaluar

una organización por niveles de madurez de 0 a 13, según los niveles de ma-

durez obtenidos en diferentes áreas clave, tal como se representa en la siguien-

te tabla.

Controlado Eficiente Optimizado

Área�clave 0 1 2 3 4 5 6 7 8 9 10 11 12 13

Estrategia�de�pruebas A B C D

Modelo�de�ciclo�de�vida A B

Momento�de�implicación A B C D

Estimación�y�planificación A B

Técnicas�de�especificación�de�pruebas A B

Si una organización se encuentra en el nivel 6, ello quiere decir que tiene el nivel B en el área "estrategia de pruebas", el B en "modelo de ciclo de vida", el A en "estimación y planifi-cación", etc.


Controlado Eficiente Optimizado

Área�clave 0 1 2 3 4 5 6 7 8 9 10 11 12 13

Técnicas�estáticas�de�pruebas A B

Métricas A B C D

Herramientas�de�prueba A B C

Entorno�de�pruebas A B C

Entorno�oficina A

Compromiso�y�motivación A B C

Funciones�de�prueba�y�formación A B C

Alcance�de�la�metodología A B C

Comunicación A B C

Generación�de�informes A B C D

Gestión�de�defectos A B C

Gestión�del�testware A B C D

Gestión�del�proceso�de�pruebas A B C

Evaluación A B

Pruebas�de�bajo�nivel A B C

Si una organización se encuentra en el nivel 6, ello quiere decir que tiene el nivel B en el área "estrategia de pruebas", el B en "modelo de ciclo de vida", el A en "estimación y planifi-cación", etc.

3.3. Modelos de calidad en el producto de software

Los modelos de calidad en el producto intentan determinar cómo se puede

medir y evaluar la calidad del producto de software.

Se los suele definir mediante una descomposición jerárquica en la que el pri-

mer nivel de la jerarquía empieza por criterios externos y observables para los

usuarios, como la facilidad de uso, así como también por otros internos, como

la eficiencia.

Los criterios pueden ser descompuestos en más atributos, que son en general

internos en el producto. Finalmente, cada subatributo puede ser mapeado en

un conjunto de métricas de calidad.

Ved también

Veremos en el apartado 4 deeste módulo métricas específi-cas relacionadas con los atribu-tos que analizaremos en esteapartado.


El modelo de calidad en el producto más conocido es el estándar ISO 9126,

aunque todavía continúan vigentes otros, como los de McCall y Boehm.

3.3.1. ISO 9126

En 1991, la International Organization for Standardization (ISO) definió, ba-

sándose en los modelos de McCall y Boehm, el estándar ISO 9126. La norma

se basa en considerar que el foco en la calidad cambia durante el ciclo de vida:

• Al principio, durante la captura de los requisitos y su análisis, la calidad

se especifica de acuerdo con los requisitos de los usuarios, principalmente

desde su punto de vista externo (calidad�externa). La calidad externa se

mide por el comportamiento del producto en ejecución y en un entorno

simulado, con las pruebas.

• En la fase de diseño e implementación, la calidad externa se traduce en un

diseño técnico y un código. Se mide el punto de vista de los desarrolladores

sobre la calidad�interna del código y los requisitos implícitos que tiene

que cumplir este software.

• Una vez el software está operativo, la calidad final (calidad�de�uso) tiene

que ser la adecuada para los usuarios y el contexto de utilización. Se miden

los efectos del uso en los usuarios finales reales cuando el producto está

ejecutándose en un entorno productivo.

Calidad externa y calidad en el uso

La diferencia entre calidad externa y calidad en el uso es similar a la que existe entre laspruebas de sistema y las pruebas de aceptación. En el primer caso, las pruebas se realizancon datos "prefabricados" por el equipo que realiza las pruebas. En el segundo caso, laspruebas las realizan usuarios reales con datos reales.

¿Certificaciones ISO 9126?

¿Nos podemos certificar enel estándar ISO 9126? No, noexisten certificaciones en estanorma.


La ISO 9126 define seis factores de calidad, que se consideran tanto internos

como externos (funcionalidad, fiabilidad, usabilidad, eficiencia, facilidad de

mantenimiento y portabilidad), y cuatro factores de calidad de uso (eficacia,

productividad, seguridad y satisfacción):

1)�Funcionalidad. Conjunto de atributos que se basan en la existencia de un

conjunto de funciones y sus propiedades especificadas.

• Idoneidad. Miden si el conjunto de funciones es apropiado.

• Exactitud. Miden que los efectos sean los correctos y esperados.

• Interoperabilidad. Miden la habilidad de interactuar con otros sistemas.

• Seguridad. Miden la habilidad para prevenir accesos no autorizados.

• Cumplimiento. Seguimiento de estándares, convenciones o regulaciones

legales.

2)�Fiabilidad. Atributos relacionados con la capacidad del software de mante-

ner su nivel de fiabilidad bajo las condiciones establecidas durante un período

de tiempo.

• Madurez. Frecuencia de fallos por defectos en el software.

• Tolerancia�a�fallos. Habilidad para mantener el nivel de rendimiento en

caso de fallos del software.

• Recuperabilidad. Miden la capacidad de restablecer el nivel de rendimien-

to y recuperar datos en caso de fallo y el tiempo y esfuerzo necesario.

Nota

No hace falta que memoricéislos diferentes factores y atri-butos. Se exponen para quecomprobéis la complejidad yexhaustividad del modelo.


• Cumplimiento. Igual que en la funcionalidad.

3)�Usabilidad. Conjunto de atributos relacionados con el esfuerzo necesario

para usar el software.

• Comprensión. Miden el esfuerzo del usuario para reconocer el concepto

lógico del software y su aplicabilidad.

• Aprendizaje. Miden el esfuerzo del usuario para aprender a usar la aplica-

ción.

• Operatividad. Miden el esfuerzo del usuario en operar y administrar el

sistema.

• Atractividad. Miden el nivel de atracción de la aplicación.

• Cumplimiento. Igual que en la funcionalidad.

4)�Eficiencia. Conjunto de atributos relacionados con el nivel de rendimiento

del software y la cantidad de recursos utilizados.

• Comportamiento�en�el�tiempo. Atributos que miden el tiempo de res-

puesta y el tiempo de procesamiento de las funciones.

• Utilización�de�recursos. Miden la cantidad de recursos usados y la dura-

ción de este uso en la ejecución de las funciones.

• Cumplimiento.

5)�Mantenibilidad. Conjunto de atributos relacionados con el nivel de ren-

dimiento del software y la cantidad de recursos utilizados.

• Facilidad�de�análisis. Miden el esfuerzo necesario para diagnosticar defi-

ciencias o causas de fallos e identificar las partes que tienen que ser mo-

dificadas.

• Facilidad�de�cambio. Miden el esfuerzo necesario para hacer modificacio-

nes, eliminar defectos...

• Estabilidad. Miden el riesgo de los efectos no esperados en las modifica-

ciones.

• Facilidad�para�ser�probado. Miden el esfuerzo necesario para validar el

software modificado.

• Cumplimiento.


6)�Portabilidad. Conjunto de atributos relacionados con la habilidad del soft-

ware para ser transferido a un nuevo entorno.

• Adaptabilidad. Miden la oportunidad de adaptación a diferentes ámbitos

sin aplicar acciones que no sean las previstas por el propósito del software.

• Facilidad�de�instalación. Miden el esfuerzo necesario para instalar el soft-

ware en un nuevo entorno.

• Coexistencia. Mide el comportamiento del sistema o el usuario con otro

software independiente en un entorno común compartiendo recursos.

• Facilidad�de�reemplazo. Miden el esfuerzo de usar el software en lugar

de otro en su entorno.

• Cumplimiento. Miden si el software se adhiere a estándares o convencio-

nes relacionadas con la portabilidad.

La calidad en el uso es más simple y solo incluye cuatro factores de calidad:

1)�Eficacia. Capacidad del producto para permitir a los usuarios que alcancen

los objetivos con exactitud e integridad.

2)�Productividad. Capacidad para permitir a los usuarios la utilización de una

cantidad de recursos apropiados (tiempo para completar una tarea, coste fi-

nanciero, etc.).

3)�Seguridad. Capacidad de conseguir niveles aceptables de riesgo para las

personas, la programación, la propiedad o el entorno.

4)�Satisfacción. Criterios para establecer la satisfacción del cliente.

Ejemplos de métricas

El estándar establece algunos ejemplos de métricas que se pueden aplicar a cada uno delos factores. Por ejemplo, dentro de las métricas de facilidad de cambio se incluyen, entreotros, tiempo requerido para la implementación de cambios, eficiencia en los cambios...

3.3.2. Otros modelos

Uno de los modelos más conocidos es el de McCall (realizado en 1977), pre-

decesor de los modelos de calidad actuales. Al igual que la ISO 9126, define

diferentes factores de calidad, pero los agrupa en tres clasificaciones:

1)�Operación�del�producto�(características�de�su�operación). Analiza la efec-

tividad del software en el cumplimiento de un conjunto específico de tareas,

entre las que podemos encontrar la facilidad de entrada de datos al usuario o

la confianza en los datos de salida.


2)�Revisión�del�producto�(capacidad�para�cambiar�el�producto). Mide la

facilidad para actualizar, cambiar o mantener el producto. Esta característica

es especialmente importante, ya que determina el coste de las pruebas y el

de corrección de los defectos que surgen del proceso de pruebas. Incluye la

facilidad de mantenimiento, la flexibilidad y la facilidad de ser probado.

3)�Transición�del�producto�(adaptabilidad�a�nuevos�entornos). Mide la fa-

cilidad de migración. Incluye tres factores:

a)�Interoperabilidad. Es la capacidad de interactuar con otras piezas de soft-

ware.

b)�Reusabilidad. Es la frecuencia con que el software puede ser usado en otras

aplicaciones.

c)�Portabilidad. Es la facilidad de uso del software en otras plataformas.

La medición de cualquiera de los factores en el modelo de McCall se define de

acuerdo con un conjunto de 41 métricas. Para cada criterio de calidad aporta

una lista de condiciones que se tienen que dar en cada una de las etapas del

ciclo de vida (R: requisitos, D:diseño, I:implementación) y que definen el im-

pacto de los diferentes criterios de bajo nivel en el factor superior.

Otro modelo histórico es el modelo�de�Boehm, en el que la descomposición

jerárquica de la calidad de un producto se realiza con 17 factores de calidad,

de acuerdo con tres categorías principales bastante similares a las del modelo

de McCall:

1)�Utilidad�por�sí�mismo. Facilidad de uso, fiabilidad, eficiencia.

2)�Facilidad�de�mantenimiento. Facilidad para identificar qué se tiene que

cambiar, facilidad para ser modificado y facilidad para ser probado.

3)�Portabilidad. Facilidad de cambio del software para poder funcionar en un

nuevo entorno.

Aunque los modelos de Boehm y McCall son muy similares, el modelo de Mc-

Call está enfocado a medir con precisión las características de alto nivel, mien-

tras que el modelo de Boehm se basa en un conjunto mayor de características,

pero enfocadas principalmente a la facilidad de mantenimiento.

Si bien la descomposición en los factores y criterios de calidad difiere entre los

diferentes modelos, la gran diferencia entre el modelo ISO 9126 y los modelos

de McCall y de Boehm radica en que en estos una subcaracterística de calidad

puede impactar a más de una característica de calidad, mientras que en la ISO

9126 una subcaracterística solo pertenece a una característica específica.


4. Medidas y métricas en calidad del software

Para poder mejorar de forma objetiva la calidad de los procesos y productos

de software de una organización, es necesario realizar su medición y analizar

y comparar los resultados en el tiempo.

El objetivo de la medición es poder realizar diferentes evaluaciones du-

rante el ciclo de vida del software para comprobar que los requisitos de

calidad se están alcanzando, ofrecer una mayor visibilidad de la calidad

y adoptar las acciones correctivas necesarias.

Sin embargo, la utilización de métricas no elimina la necesidad de incluir siem-

pre un valor de juicio humano para la evaluación de su información. Muchas

iniciativas de medición fallan porque las métricas obtenidas no son utilizadas

o analizadas. Para tener éxito en la medición se tienen que seguir las siguien-

tes pautas:

• Recoger únicamente aquellas métricas que satisfacen las necesidades de la

organización.

Cita

"Cuando se puede medir aque-llo de lo que se está hablandoy se puede expresar en núme-ros, se sabe realmente acercade ello; pero cuando no pue-de expresarse en números, elconocimiento que se tiene deello es escaso e insatisfactorio."Lord Kelvin

• Analizar las métricas obtenidas. La medición es "fácil", pero analizar los

valores obtenidos puede requerir un esfuerzo que se suele evitar. La infor-

mación medida tiene que servir para tomar decisiones.

Ejemplo

Imaginemos que en un análisis de código se ha determinado que la cobertura de pruebasunitarias es del 99%. Desde un punto de vista objetivo puede parecer una cobertura exce-lente, pero en un análisis posterior se comprueba que el 1% restante no probado incluíaprecisamente las líneas de código de las funciones más críticas del negocio.

• Imponer objetivos no realistas. Muchos gestores se encuentran fascinados

por la medición, pero, a menudo, las medidas no tienen en cuenta los

valores históricos y la experiencia, por lo que acaban siendo medidas poco

útiles.

• No abusar del número de métricas obtenido. Implementar un conjunto

reducido de métricas. Una vez se haya demostrado la utilidad y estabilidad

de este conjunto podremos incorporar más.

• Dar información adecuada y explicativa. Las métricas tienen que ser en-

tendidas por todo el mundo.

Evaluación de las medidasrecogidas

En muchas organizaciones eshabitual que no se asigne ungrupo responsable de evalua-ción de las medidas recogidas.Las medidas tienen que seranalizadas y contrastadas pa-ra determinar cómo se puedenmejorar los procesos y produc-tos.


4.1. Conceptos básicos de medición

Ningún proceso de medición puede obtener resultados útiles si no satisface

alguna necesidad de información que haya detectado la organización. A partir

de estas necesidades se tendrán que identificar las entidades y atributos que se

quieren medir, así como las métricas necesarias.

Las características mensurables de una entidad, o atributos, pueden ser inter-

nas, si se pueden medir examinando la entidad (como, por ejemplo, el tamaño

del código fuente), o externas, cuando se mide cómo se relaciona la entidad

con su entorno.

Una métrica es una medida cuantitativa del grado que un sistema, com-

ponente o proceso tiene de un atributo específico.

Es habitual confundir los conceptos métrica y medida. La diferencia entre mé-

trica y medida es que la medida es el número (4, 5...) o categoría (muy bien,

mal, etc.) asignada a un atributo de una entidad mediante una medición. Es

decir, la medida es el valor de la métrica. Si, por ejemplo, usamos la métrica

líneas de código, su medida es el número concreto de líneas de código de la

entidad analizada.

La definición de las métricas se tiene que realizar a diferentes niveles:

• Métricas�base�o�directas. Se aplican directamente sobre un atributo obser-

vado (número de líneas de código, número de defectos descubiertos, etc.).

• Métricas�derivadas�o� indirectas. Se obtienen a partir de métricas base

y métricas derivadas (por ejemplo, la densidad de defectos de un compo-

nente o módulo, que se calcula como el número de defectos respecto del

número de líneas del componente o módulo).

• Indicadores. Tienen como objetivo proporcionar información útil para

la toma de decisiones, y, por lo tanto, están más próximos a las necesida-

Nota

Podríamos decir que las mé-tricas base y las derivadas sonmás bien métricas técnicas ylos indicadores, métricas estra-tégicas.


des reales que había detectado la organización. Son métricas específicas o

combinaciones de métricas base y derivadas.

4.2. Estrategia de medición del software

Si bien conocemos ya los diferentes conceptos básicos en medición, necesita-

mos formalizar cuál es el enfoque de medición que tenemos que aplicar en

una organización, basado en dos fases:

• definición de las necesidades de información de la organización, y

• definición de las métricas aplicables a cada proyecto.

El modelo de medición, leído de abajo arriba, establece que se realizan las

siguientes fases:

1)�Fase�de�recogida�de�datos. Se tiene que diseñar un método de medición

para obtener una medida base.

2)�Fase�de�preparación. A continuación, los valores de dos o más medidas

base pueden ser combinadas con una función de medición en una medida

derivada.

ISO/IEC 15939

El estándar ISO/IEC 15939(proceso de medición del soft-ware), basado en PSM, defineel proceso de medición parael desarrollo de software y in-geniería de sistemas, así comola terminología asociada a unmodelo de medición.


3)�Fase�de�análisis�de�datos. Estas medidas derivadas son usadas, según un

modelo establecido, para construir un indicador, que es interpretado para sa-

tisfacer las necesidades de información de la organización.

Ejemplo

Fase Descripción

Recogida�de�datos Medida base 1 (MB1): Número de defectos encontradosMedida base 2 (MB2): Número de casos de prueba ejecutados

Preparación�de�datos Función de medición: MB1/MB2Medida derivada: Densidad de defectos respecto de los casos de prueba

Análisis�de�datos La medida derivada se relaciona con la fiabilidad (característica de calidad) del grupo de ca-racterísticas externas de calidad de la ISO 9126

Asimismo, para cada métrica que usemos tendremos que definir una ficha que

indique, entre otros aspectos, cómo se recogerá la medida, sus beneficios y

sobre qué elementos se aplica.

Elemento Descripción

Nombre Nombre de la métrica

Costes Costes de utilización de la métrica

Beneficios Beneficios por el uso de la métrica

Impacto Indica si la métrica podrá ser usada para detener o alterar el proyecto (¿puede indicar la mé-trica una calidad deficiente del software?)

Valor objetivo Valor numérico de la métrica que tiene que conseguirse para cumplir los requisitos de cali-dad. Incluye el valor crítico y el rango de la métrica

Factores de calidad Factores de calidad relacionados con la métrica

Herramientas Herramientas de software o de hardware que serán usadas para recoger los datos, calcular lamétrica y analizar los resultados

Aplicación Cómo se usa la métrica y dónde se aplica

Elementos de datos Valores de entrada necesarios para calcular los valores de la métrica

Cálculo Explicación de los pasos necesarios para calcular los valores de la métrica

Interpretación Interpretación de los resultados del cálculo de la métrica

Consideraciones Consideraciones sobre cuándo es apropiada o no la métrica

Formación requerida Formación necesaria para implementar o usar la métrica

Ejemplo Ejemplo de aplicación de la métrica

Histórico de validación Nombres de los proyectos que han usado la métrica, y los criterios que ha satisfecho

Referencias Otras referencias


Para cada una de las métricas seleccionadas, y dentro de cada proyecto, se

tendrán que establecer sus rangos de valoración, tanto del nivel planificado

como del nivel mínimamente aceptable, que nos permitan determinar si el

valor obtenido indica que se tienen que adoptar acciones o por el contrario

nos dan un valor satisfactorio.

4.3. Tipos de métricas

En el software podemos encontrar tres tipos de métricas, asociadas a los tipos

de entidades siguientes:

• Procesos. Las medidas obtenidas en un proceso suelen incluir aspectos

de esfuerzo y tiempo en sus actividades. Podemos medir, entre otros, los

siguientes atributos internos: tiempo (duración del proceso), esfuerzo, etc.

• Productos. Entregables, componentes o documentos generados en el ciclo

de vida. Podemos encontrar atributos internos, como el tamaño en líneas

de código, y atributos externos, como la facilidad de mantenimiento del

código.

• Recursos. Cualquier elemento que participe en los procesos: recursos hu-

manos, materiales, herramientas. Por ejemplo, podemos medir el coste de

un perfil o su productividad.

En general, las métricas de calidad se utilizan mayoritariamente para las mé-

tricas de producto y de proceso, dejando de lado aspectos relacionados con los

recursos. En cualquier caso, el impacto del número de desarrolladores o su efi-

ciencia son también factores determinantes para la calidad final del producto.


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

Antes de empezar a revisar las diferentes tipologías de métricas es necesario

saber cómo medir el tamaño de un software, ya que se trata de una métrica

base que utilizaremos en otras métricas.

El tamaño de un software puede definirse según el número de líneas de código

o sus puntos función.

4.4.1. Líneas de código

La métrica de líneas de código contabiliza el número de líneas que tiene un

programa. Si bien este concepto puede parecer muy simple, tiene diferentes

interpretaciones.

El texto del código de un programa lo podemos dividir en líneas físicas, que

se pueden clasificar en:

• Líneas en blanco.

• Líneas de comentarios.

• Líneas de sentencia. Declaraciones o definiciones de datos, una sentencia

simple ejecutable o una sentencia compuesta. Por lo tanto, una línea de

sentencia puede incluir varias sentencias.

Las diferentes interpretaciones asociadas a las líneas de código se describen de

acuerdo con la combinación de las diferentes clasificaciones anteriores:

• Líneas�físicas�de�código. Incluye todos los tipos de líneas.

• Líneas�efectivas�de�código�o�líneas�de�código�sin�comentarios. Conta-

biliza todas las líneas que no estén en blanco y no sean líneas exclusivas

de comentario.

• Líneas�lógicas�de�código. Contabiliza cada una de las sentencias.

• Líneas�comentadas�de�código. Contabiliza las líneas de código que tienen

uno o más comentarios.

Debido a las diferentes interpretaciones posibles, siempre que usemos

esta métrica para calcular otras métricas tendremos que ser muy explí-

citos, indicando si consideramos líneas físicas, efectivas, lógicas o co-

mentadas.


Ejemplo de los tipos de líneas

Veamos con un ejemplo de código cada uno de los tipos de líneas descritas. En la tabla semarca una "X" cuando se encuentra en el código uno de los tipos de líneas establecidos.Por ejemplo, la línea int puntos=0; int iCnt=0 incluye dos sentencias y, por lotanto, dos líneas lógicas.

Líneasfísicas

Líneasefectivas

Líneaslógicas

Líneas co-mentadas

/* Cálculo de los puntos defidelización del VCV */

X X

public intcalculaPuntos(double anIm-port) {

X X X

int punts= 0; int iCnt = 0; X X XX (2)

X

if (anImport>=100 && anIm-port<300) { //un comentario

X X X X

// dar 2 puntos X X

puntos = 2; X X X

} else { X X X

puntos = 0; X X X

} X X X

retorno puntos; X X X

} X X X

TOTAL 12 9 10 3

Tasa de comentarios 3/13 = 25%

Una métrica bastante interesante derivada de las anteriores es la tasa de co-

mentarios, que nos indica cómo se encuentra comentado el código:

El número de líneas suele asociarse a la complejidad del software, ya que en la

práctica será más costoso desarrollar un programa de muchas líneas que uno

pequeño, y será más difícil mantenerlo. Sin embargo, es importante tener en

cuenta que las líneas de código no se pueden considerar en ningún caso co-

mo una medida de eficiencia de los desarrolladores. Habrá programadores que

pueden construir la misma funcionalidad con menos código o aplicar estruc-

turas de reutilización, y, en ese caso, el código seguramente será más fácil de

entender y mantener (y menos complejo).


La métrica de líneas de código está en ciertos aspectos cuestionada, ya que:

• Es poco útil cuando se quiere comparar la complejidad de programas que

se han escrito en diferentes lenguajes de programación, ya que el mismo

algoritmo puede ser implementado en un lenguaje con menos líneas que

otro (no por la habilidad del programador, sino por lo que ofrecen los

lenguajes y su nivel de detalle).

• No hay consenso sobre cómo se calculan determinados casos. Cuando usa-

mos una librería en el proyecto ¿tenemos que sumar las líneas de código

de esta librería? ¿Tenemos que contar las líneas del sistema operativo?

• Depende del estilo de programación utilizado. Por ejemplo, en nuestro

código ejemplo, las llaves de inicio de bloque se encuentran al final de

la línea física, en lugar de encontrarse en una nueva línea. Si hubiésemos

puesto las llaves en nuevas sentencias físicas, las métricas habrían variado.

• Existen herramientas que generan código de forma automática. Este códi-

go generado automáticamente desvirtúa la métrica.

Muchas de estas problemáticas se resuelven con la utilización de la métrica

puntos función.

4.4.2. Puntos función

El método de puntos función se basa en medir el tamaño del aplicativo según

las funcionalidades en que se quiera desarrollar. Su ventaja es que permite

calcular el tamaño de una aplicación antes de que se cree el código.

Los puntos función se pueden calcular en diferentes momentos del proyecto

según el conocimiento que se vaya obteniendo de él. En las fases iniciales ob-

tendremos un valor en el que tendremos que incluir un pequeño margen de

error, mientras que en fases más avanzadas, por ejemplo cuando se haya com-

pletado el análisis, obtendremos un valor más preciso. Aunque no se disponga

de requerimientos muy formales, se puede hacer una aproximación de forma

sencilla. El método permite comparar el tamaño de diferentes aplicaciones sin

importar el lenguaje de programación utilizado en cada una de ellas.

El proceso de cálculo de puntos función incluye los siguientes pasos:

1) De acuerdo con el documento de requisitos, identificar los siguientes tipos

de componentes:

a)�Número�de�entradas�de�usuario: número de datos de usuario o compo-

nentes de control de entrada diferentes en el sistema (datos de entrada, pro-

cesos batch...).


b)�Número�de�salidas�de�usuario: número de datos de usuario o componentes

de control de salida diferentes (informes, listados...).

c)�Número�de�consultas�de�usuario: número de operaciones en las que un

usuario introduce unos datos de entrada y obtiene al momento unos datos de

respuesta.

d)�Número�de�ficheros�lógicos�internos: número de entidades del modelo

de datos.

e)�Número�de�interfaces�externas: número de ficheros intercambiados entre

sistemas.

2) Analizar la complejidad de cada uno de los tipos anteriores y clasificarlos

en simples, medios o complejos.

3) Para cada nivel de complejidad y tipo de elemento (entradas, salidas, cam-

pos a procesar...) se establece un factor de ponderación, y según la tabla si-

guiente se calcula el número total de puntos función sin ajustar:

La suma del número de los diferentes elementos con su factor nos da el valor de lo que se denomina puntos�función�sinajustar (PFSA).

4) A continuación se calcula el factor de ajuste de complejidad relativa del

proyecto, teniendo en cuenta elementos que pueden variar el esfuerzo, valo-

rándolos en un grado de 0 a 5:

Factor Grado (0-5)

Requisitos de copias de confianza y recuperación

Requisitos de comunicación de datos

Alcance de proceso distribuido

Requisitos de rendimiento


Factor Grado (0-5)

Entorno operacional esperado

Alcance de las entradas en línea

Alcance de multipantallas o entradas para varias operaciones

Alcance de actualización en línea de ficheros maestros

Alcance de entradas, salidas, consultas y ficheros complejos

Alcance de procesamiento complejo de datos

Alcance de cómo el código desarrollado actual puede ser diseñadopara ser reutilizado

Alcance de funciones de conversión e instalación incluidas en el dise-ño

Alcance de múltiples instalaciones en la organización

Alcance de cambio y foco en la facilidad de uso

Total�(FC) Suma�de�los�grados

5) Finalmente, ya podemos calcular el valor de los puntos función ajustados o

puntos�función, teniendo en cuenta el valor obtenido de los puntos función

sin ajustar y el valor del factor de ajuste.

Existen diferentes estudios5 que han establecido factores de conversión para

conocer cuántas líneas de código equivalen a un punto función en diferentes

lenguajes de programación, con lo que, una vez construido el código, podre-

mos valorar si nuestras estimaciones en el modelo puntos función han estado

lo suficientemente próximas a la realidad.

Sin embargo, no tenemos que olvidar que, a partir de los puntos función y en

combinación con otros modelos, como, por ejemplo, COCOMO II, podemos

obtener el número de horas de esfuerzo en construcción necesarios para el

desarrollo del aplicativo.

4.5. Métricas de calidad en el proceso

Las métricas que estudiaremos a continuación se basan en medir cómo se rea-

liza el proceso. En concreto, veremos cómo analizar si somos eficientes en en-

contrar defectos con las pruebas, en su eliminación, e incluso cómo evaluar

qué partes del sistema estamos ya probando y cuáles no.

(5)El estudio más conocido es el deRoger Pressman, en el que se esta-blece que un punto función corres-ponde en media a 58 líneas de có-digo en Java.

Enlace de interés

El modelo constructivo decostes (COCOMO) se utilizapara la estimación de costesdel software. Podéis encon-trar más información en:http://es.wikipedia.org/wi-ki/COCOMO


4.5.1. Densidad de llegada de defectos

Con la métrica "densidad de llegada de defectos" podemos medir si la calidad

del producto va mejorando con el tiempo y si las pruebas se han realizado en

el momento oportuno.

Ejemplo

En el siguiente gráfico detectamos que las pruebas no han sido planificadas o ejecutadascorrectamente, ya que se han descubierto muchos defectos al final del ciclo de vida. Esopuede dar indicaciones de que habría que incorporar revisiones en el ciclo de vida.

4.5.2. Eficiencia en la eliminación de defectos

La eficiencia en la eliminación de defectos6 (EED) es una métrica especialmente

útil para valorar cómo el equipo de desarrollo va detectando y resolviendo los

defectos encontrados.

Se calcula como:

donde los defectos del producto presentes en esta fase corresponden a los de-

fectos existentes en la misma, tanto los que hubieran quedado de la fase an-

terior como los introducidos durante la fase. El valor de los defectos presentes

no lo podremos conocer hasta las siguientes fases.

(6)En inglés, defect removal effecti-veness (DRE).

Cuanto más alto sea el valor EED6 más efectivo será el proceso de desarrollo y

menos defectos habrán pasado a las siguientes fases o a producción.


Ejemplo

Imaginemos la siguiente tabla, en la que representamos para cada fase de desarrollo losdefectos que se han detectado y la fase en la que se introdujo realmente el defecto.

Fase donde se ha introducido el defecto

Fase en la que sedetecta el defecto

Requi-sitos

Análisisy�diseño

Codificación�ypruebas�unitarias

Prue-bas

Total�defectos�detec-tados�y�corregidos

Requisitos 7 - - - 7

Análisis�y�diseño 5 15 - - 20

Codificación�y�pruebas�unita-rias

2 6 3 - 11

Pruebas 6 3 10 - 19

Operación 1 2 5 - 8

Total 21 26 18

Según la tabla anterior, en la fase de pruebas detectamos seis defectos que ya se habíanintroducido en la fase de requisitos, tres que se introdujeron en la fase de análisis y diseñoy diez en la fase de codificación.

Veamos, por ejemplo, la eficiencia en la eliminación de defectos en la fase de análisisy diseño:

• Defectos detectados y corregidos en la fase de análisis y diseño = 20

• Defectos existentes a la entrada de la fase = 21 – 7 = 14 (han escapado de la detecciónen la fase de requisitos)

• Defectos introducidos en la fase de análisis y diseño = 26

• EED (análisis y diseño) = 20 / (14 + 26) = 50%

Este valor nos indica que la mitad de los defectos no han sido detectados en la fase deanálisis de diseño, por lo que sería necesario dirigir más esfuerzos a la revisión para poderdetectar más defectos.

4.5.3. Curva de progreso de las pruebas

El seguimiento del progreso de las pruebas se puede determinar con la curva

de progreso denominada S, en la que el eje de abscisas (x) representa las uni-

dades de tiempo y el eje de ordenadas (y) el número de casos de prueba. Los

datos representados son acumulativos en el tiempo. Podemos representar en

el mismo gráfico:

• Número de casos de prueba planificados y que tienen que ser completados

por período.

• Número de casos de prueba ejecutados por período.

• Número de casos de prueba pasados con éxito por período.


El objetivo es medir el progreso de las pruebas y compararlo con la planifica-

ción para realizar acciones correctivas si nos desviamos de la misma (disminuir

el número de casos de prueba porque nos cuestan más de lo que habíamos

planificado...).

4.5.4. Densidad de defectos encontrados en las pruebas

La métrica se basa en calcular el número total de defectos encontrados por las

pruebas respecto del número total de defectos conocidos. Este último incluye

tanto los defectos encontrados por las pruebas como los defectos encontrados

posteriormente (por los clientes o usuarios finales).

Esta medida es especialmente importante, ya que, al ser acumulativa, nos pue-

de dar idea de cuándo el coste de encontrar un defecto empieza a ser supe-

rior al coste de un defecto no encontrado. Cuando iniciamos las pruebas, en-

contrar los primeros defectos es relativamente sencillo y "barato". A medida

que avanzamos en las pruebas, el tiempo necesario para encontrar defectos es

mayor. Tenemos que evaluar si el tiempo y coste utilizado en las pruebas es

superior al impacto en coste que tendría la aparición de nuevos defectos en

producción no detectados en las pruebas.

Ejemplo

Si se han introducido 100 de-fectos en el software, y nues-tras pruebas solo encuentran50, la densidad de defectosencontrados será del 50%.


4.5.5. Métricas de cobertura de pruebas

La cobertura de pruebas mide cuál es la cantidad de elementos que se han

probado respecto del total de elementos que se pueden probar.

A medida que se avanza en la realización de las pruebas nos interesará deter-

minar qué cobertura hemos realizado y compararla con la cobertura inicial-

mente planificada. Podemos diferenciar diferentes medidas de cobertura se-

gún los elementos evaluados:

• En el nivel de código podemos medir la cobertura de sentencias, de deci-

siones, etc.

Ejemplo

En las pruebas unitarias se han cubierto el 65% de sentencias de código.

• En el nivel externo del usuario podemos medir el número de requisitos o

características probadas, el número de clases de equivalencia, etc.

Ejemplo

Se han probado el 80% de las funciones del módulo de pago, y se han probado el 25%de las clases de equivalencia de datos (las reservas de vuelos locales, no de vuelos inter-nacionales).

4.6. Métricas de calidad externa de producto

La calidad externa de un producto se suele medir por el número de defectos

en el software y el tiempo entre fallos del sistema.

Ved también

Veremos estos conceptos enmás detalle en el módulo "Ca-lidad del software: técnicas deprevención, detección y co-rrección de defectos".


4.6.1. Métricas de defectos y problemas del cliente

Una de las métricas más usadas para determinar la calidad de un producto es

la del número de defectos por miles de líneas efectivas de código. Esta métrica

se conoce como densidad de defectos.

Uno de los problemas de esta métrica es que es muy variable para cada nuevo

paradigma de programación (Java, PHP, Ruby...). Con la incorporación de la

orientación a objetos la medida pierde relevancia, y no existe una correspon-

dencia fácil entre el número de líneas de código de un lenguaje como C o

Pascal y Java o NET (reutilización, librerías...). Por este motivo podemos usar

su versión según los puntos función:

Cuando se libera la primera versión del software es fácil conocer su densidad

de defectos a medida que se registran estos defectos. Cuando se incorporan

mejoras evolutivas o correctivas en posteriores versiones, tendremos que me-

dir la calidad del producto completo, así como la nueva porción de software

incluida en la nueva versión.

Además de la métrica global de densidad de defectos suele ser muy útil clasi-

ficar la densidad de defectos por unidades o módulos, y por su severidad, para

poder así determinar dónde hay que concentrar más recursos de desarrollo y

de pruebas.

En la métrica de densidad de defectos consideramos todos los defectos "váli-

dos" (aquellos que realmente son defectos), pero, como vimos en el subapar-

tado 2.4 dedicado a la gestión de defectos, un cliente se puede enfrentar en

el uso del software a diferentes dificultades que igualmente se consideran pro-

blemas (anomalías): problemas de usabilidad, documentación que no está cla-

ra, defectos duplicados (defectos que ya fueron informados y corregidos pero

el cliente no lo sabía) o errores cometidos por el propio usuario, entre otros.

La métrica de problemas de usuario por mes tiene en consideración todos estos

elementos:


donde Núm. instalaciones del software corresponde al número de instalaciones

del software que hay en diferentes usuarios. Si hablamos de un entorno cliente

servidor, corresponde al número de ordenadores en los que se encuentra ins-

talada la aplicación, mientras que si hablamos, por ejemplo, de una aplicación

web podemos considerar el número de usuarios registrados en el sistema.

El objetivo es reducir el valor de esta métrica y mejorar el proceso de desarrollo

para reducir el número de defectos, mejorar los aspectos del producto como

la usabilidad y la documentación, formar más a los usuarios e incrementar el

número de instalaciones.

Finalmente, no podemos olvidar que, independientemente de estas métricas,

tenemos que valorar la satisfacción del usuario o cliente y obtener un valor

final resumen de todas las valoraciones que determine si en general está satis-

fecho o no con el producto.

4.6.2. Métricas de fallo

Las métricas de fallo nos permiten evaluar la fiabilidad del sistema y su im-

pacto en los usuarios.

La métrica de fallo más usada es la llamada media�de�tiempo�por�fallo7. Se

usa mayoritariamente en sistemas críticos, como los sistemas de tráfico aéreo.

Ejemplo

El Gobierno de Estados Unidos ordena que su sistema de control de tráfico no puedaestar fuera de servicio más de tres segundos al año.

A medida que se realizan las pruebas o se informa de un fallo podemos medir

el tiempo que transcurre entre un fallo y otro. El objetivo es que ese tiempo

sea cada vez mayor:

donde Intervalo tiempo fallo corresponde al intervalo de tiempo registrado entre

el fallo anterior y el nuevo fallo.

Una vez ha sido observado el fallo, los desarrolladores tienen que solucionarlo.

El tiempo medio de corrección del defecto se define como media de tiempo

por reparación (en inglés, mean time to be repair, MTTR).

La suma de las dos métricas nos da la llamada "media de tiempo entre fa-

llos" (en inglés, mean time between failures, MTBF):

MTEF = MTPF + MTTR

(7)En inglés se denomina mean ti-me for failure (MTTF).


Medidas en la industria del hardware

La métrica por término medio de tiempo entre fallos es muy habitual en la industria delhardware como una medida de fiabilidad de los sistemas proporcionados. Algunas de es-tas medidas habituales son la redundancia de discos, el clustering, o el aprovisionamientode una fuente de alimentación continua.

Algunos autores usan esta medida como una estimación de la "fiabilidad" del

sistema, entre la que encontramos la sugerida por Shooman:

4.7. Métricas de calidad interna del producto

Las métricas anteriormente analizadas se basan en considerar el software co-

mo una caja negra. Se basan en su comportamiento externo sin considerar el

diseño o el código del software. En este subapartado analizaremos qué métri-

cas podemos establecer internamente en el código.

4.7.1. Métricas de complejidad

La complejidad es uno de los factores más influyentes en el coste de desarrollo

y mantenimiento de un software.

La complejidad es el grado en que un sistema o componente tiene un

diseño o implementación que es difícil de entender y verificar.

La métrica más conocida y usada para medir la complejidad es la llamada com-

plejidad�ciclomática o complejidad de McCabe, que mide el número de ca-

minos independientes existentes en un programa mediante su representación

en un grafo.

Antes de revisar la fórmula de cálculo de la métrica es importante entender

cómo podemos representar un programa con un grafo.

Representación de un programa en un grafo

Todo programa consta de condiciones o bucles y sentencias. Según los valores

de entrada y el contexto, se realizarán unas u otras. Un grafo representa los

diferentes caminos que puede seguir un programa durante su ejecución.

En el grafo representaremos las sentencias con un círculo, las condiciones o

bucles con un rombo y los caminos entre condiciones o sentencias con una

flecha. Los círculos y los rombos se llaman nodos, mientras que las flechas se

denominan arcos.

Complejidad de McCabe

La complejidad de McCabese llama así por el nombre dequien la inventó, Thomas Mc-Cabe, en 1976.


Ejemplo

Suponiendo el ejemplo mostrado a la izquierda, obtenemos su grafo mostrado a la de-recha:

En la segunda franja hemos representado la condición if (aNum.Adultos>0) {, mien-tras que en la tercera hemos representado la condición if (...) {En un rombo y lasentencia puntos=2 en el círculo.

Cálculo de la métrica de McCabe

A partir de un grafo G, que representa el número de arcos y nodos de un pro-

grama, se puede calcular su valor de complejidad ciclomática como:

donde a es el número de arcos o aristas del grafo y n, el número de nodos.

Ejemplo del cálculo de la métrica de McCabe

En el ejemplo nos basaremos en el grafo del subapartado anterior.

V(G) = a - n + 2 = 12 (aristas) - 9 (nodos) + 2 = 5

Este valor nos da el número de caminos independientes o posibles caminos por los quepuede pasar una ejecución del fragmento de código. Si partimos el grafo en los caminosindependientes del ejemplo obtenemos las siguientes posibilidades, que coinciden conel número obtenido.

El número obtenido nos permite conocer el número mínimo de casos de prueba quetendríamos que realizar para probar todos los caminos posibles.

McCabe consideró que si el valor de la complejidad ciclomática es superior

a 10 la probabilidad de defectos en el programa aumenta, por lo que es un

código que tendría que ser revisado.


Complejidad ciclomática Evaluación del riesgo

1-10 Programa simple, poco riesgo

11-20 Más complejo, riesgo moderado

21-50 Complejo, alto riesgo

>50 Imposible de probar (riesgo altísimo)

Los mayores beneficios de la métrica de complejidad ciclomática son:

• Al representar el número mínimo de caminos, permite definir cuál es el

límite mínimo de casos de prueba para un programa.

• Es independiente del formato del código (no depende, por ejemplo, de si

se usa la clave de inicio en la sentencia anterior o en una nueva sentencia)

y poco dependiente del lenguaje de programación.

Su desventaja principal es que no tiene en consideración la complejidad deri-

vada de la relación con otros módulos. Si dentro de una función esta apela a

muchas otras funciones la complejidad es realmente mayor, pero la métrica

no lo tiene en cuenta.

4.7.2. Métricas de mantenibilidad

La mantenibilidad es un atributo del software que nos indica la facilidad con

que un código puede ser modificado para incluir nuevas funcionalidades, mo-

dificar funcionalidades existentes, mejorar su rendimiento, etc.

La métrica más utilizada es el índice de mantenibilidad, que se deriva del cálcu-

lo de algunas de las métricas que hemos visto anteriormente.

donde:

• Media (EH) es la media de los esfuerzos de Halstead por módulo.

• Media(CCE) es la media de la complejidad ciclomática extendida por mó-

dulo. La complejidad ciclomática extendida incrementa en 1 la compleji-

dad por cada operador binario que se encuentra dentro de una condición.

• Media(LíneasCódigo) es la media del número de líneas de código por mó-

dulo.

Métrica de Hasltead

La métrica de Hasltead, bas-tante compleja, incluye dife-rentes ecuaciones para obte-ner el tamaño de un progra-ma, su complejidad, el esfuer-zo en el desarrollo y el númeroprevisto de fallos en el softwa-re, y se basa en la clasificaciónde las partes de un programaen operandos y operadores.


• Media(LCC) es la media del número de líneas de código comentadas.

Aunque puede sorprender la complejidad de la fórmula, diferentes organiza-

ciones han comprobado su validez en proyectos reales.

4.7.3. Métricas estructurales

Las líneas de código y la complejidad ciclomática, entre otras, son métricas que

miden la complejidad de un módulo de forma aislada del resto de módulos.

Las métricas de estructura complementan las métricas anteriores para evaluar

las interacciones entre módulos de un sistema o entre sistemas. La métrica más

utilizada es la llamada fan-in y fan-out.

El fan-in mide el número de llamadas que recibe un módulo o clase desde otros

módulos o clases, mientras que el fan-out mide el número de los que efectúa

un módulo o clase a otros módulos o clases.

Fan-in y fan-out

La métrica fan-in y fan-out fueestablecida por Myers en 1978y Yourdon y Constantine en1979.

Los módulos con un alto fan-in son relativamente pequeños y simples y se en-

cuentran en las estructuras bajas del diseño. En cambio, los módulos grandes

y complejos suelen tener un bajo fan-in. Los módulos con un alto fan-in y un

alto fan-out implican un diseño pobre.

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

Dado que la orientación a objetos es el paradigma más usado en la actualidad

en el desarrollo de software, revisaremos en este subapartado un conjunto es-

pecífico de métricas para medir, principalmente, la complejidad de nuestro

software.

Métodos ponderados por clase

Los métodos ponderados por clase (MPC) son una métrica que mide la com-

plejidad total de una clase. Es un indicador del esfuerzo necesario para desa-

rrollar y mantener la clase. Un valor alto indicará que la clase tendría que estar

reestructurada en clases más pequeñas.

donde ci corresponde a la complejidad ciclomática del método respectivo, y n

es el número total de métodos de la clase.

Obtención de los fan-in yfan-out

El fan-in y el fan-out se puedenobtener fácilmente con herra-mientas de análisis estático delcódigo.


Profundidad del árbol de herencia

La profundidad del árbol de herencia (PAH) es una métrica que mide, para

una clase, el camino más largo desde esta hasta la raíz en el árbol de herencia.

Con un árbol de herencia creciente, la complejidad de diseño aumenta y se

hace más difícil interpretar el comportamiento de las clases. Un valor pequeño

indica que se hace poco uso de la herencia.

Ejemplo

En la figura siguiente, la subclase 212 tiene una profundidad del árbol de herencia de 4.

Número de descendientes

El número de descendientes (NDD) mide el nivel de reutilización de un siste-

ma según el número de clases subordinadas que tiene una clase dentro de su

jerarquía de herencia (sus clases hijas, las hijas de sus clases hijas, etc.). Un

número en aumento indica un mayor nivel de reutilización, pero también un

mayor esfuerzo requerido para realizar las pruebas.

Ejemplo

En el ejemplo del subapartado anterior, el número de descendientes de la superclase es3 (las subclases 1, 2 y 3).

Defectos de las clases

Glasberg predijo que las clasesque se encuentren en la jerar-quía de herencia con mayorprofundidad tienen menos de-fectos que las clases interme-dias.


Respuesta para una clase

La respuesta para una clase C (RPC) es el conjunto de métodos de la clase que

serán ejecutados en respuesta a un mensaje enviado a un objeto de esta clase.

El conjunto de respuesta incluye los mismos métodos de la clase C y los méto-

dos ejecutados fuera de C como resultado del mensaje recibido. Así, denotan-

do por M el conjunto de métodos de la clase y por A el conjunto de métodos

que activa el mensaje, entonces RPC es la cardinalidad de unión de M y A:

RPC = |M x A|.

Si este número es grande, la complejidad del diseño aumentará y las pruebas

y depuración de la clase serán más costosas, ya que requerirán un mayor nivel

de comprensión por parte del probador.

Acoplamiento entre clases

Se dice que una clase C1 está acoplada a una clase C2 si un método de C1 usa

al menos un método o una variable de instancia de la clase C2.

La métrica de acoplamiento (ACC) de una clase se puede definir entonces co-

mo el número total de clases con las que se encuentra acoplada la clase. Si te-

nemos clases altamente acopladas, se complica su reutilización y se perjudica

la capacidad de hacer modificaciones. Tenemos que conseguir que el valor de

la métrica sea bajo.

Carencia de cohesión en métodos (CCM)

La carencia de cohesión en métodos (CCM) es una métrica que mide la caren-

cia de cohesión dentro de una clase evaluando la similitud entre los diferen-

tes métodos de la clase. Una baja similitud indica que la clase está cubriendo

diferentes propósitos y tendría que ser dividida en varias clases y que la clase

es compleja.

Una clase es cohesiva cuando realiza un conjunto de acciones relacionadas en-

tre sí. Una falta de cohesión, en cambio, indica que una clase realiza diferentes

tareas sin relación. Aunque una falta de cohesión puede no tener impacto en

la funcionalidad completa de una clase, la clase será menos fácil de gestionar

a medida que se incorporen más y más comportamientos en diferentes sitios

incorrectos.

Existen diferentes formas de calcular la métrica de carencia de cohesión. No-

sotros veremos la forma definida por Henderson y Sellers:


donde:

• m es el número de métodos de la clase.

• a es el número de atributos de una clase, representados por un conjunto

• es el número de métodos que acceden al atributo y.

Ejemplo

El valor de la métrica puede variar entre los valores 0 y 2. Si el valor es superior

a 1, indica que hay una carencia de cohesión y se tienen que aplicar acciones

correctivas, partir la clase en varias clases.


Resumen

En este módulo hemos analizado la calidad como un aspecto primordial en

el éxito de un proyecto y el efecto de consecuencias catastróficas que puede

tener una mala calidad. La calidad puede ser entendida en diferentes ámbitos,

en el de la propia organización o en el de sus procesos o productos producidos.

Una organización puede evolucionar en su plan de calidad, pasando por un

proceso inicial de detección de defectos (con las pruebas y las revisiones), para

progresar en su prevención y finalmente en la mejora continua de toda la

organización. Es importante conocer cuál es el coste asociado a las medidas

que pueden evitar la mala calidad, pero saberlo justificar en comparación con

el coste mayor derivado de la mala calidad (errores, soporte, mala imagen,

etc.).

Asimismo, es importante saber cómo gestionar el ciclo de vida de un defecto,

desde que se detecta hasta que se corrige, y la importancia que tiene informar

un defecto para mejorar su seguimiento y resolución.

Una vez analizados los puntos más importantes relacionados con la calidad,

hemos estudiado diferentes modelos de calidad y estándares que ayudan a las

organizaciones a implantar procesos de desarrollo y productos con calidad,

entre los que hemos destacado los modelos ISO 9000 para la gestión de la

calidad en la organización, CCMI en la calidad del proceso de desarrollo e ISO

9126 para la calidad del producto. No hemos dejado de lado, sin embargo, los

modelos específicos de mejora en el proceso de pruebas, como TPI y TMMI.

Cualquier organización puede usar estos modelos de referencia para establecer

una mejora de sus procesos y compararse también con otras organizaciones.

Por último, y no menos importante, hemos analizado diferentes medidas y

métricas de calidad en el software, basadas principalmente en el producto

(complejidad ciclomática, métricas orientadas a objetos, densidad de defectos,

etc.) así como también en el proceso (como la curva de progreso de pruebas o

la eficiencia en la eliminación de defectos). El conocimiento de estas medidas

nos permite actuar sobre el proceso y el producto y prevenir la aparición de

nuevos defectos.


Actividades

1. Identificad tres ejemplos de fallos en sistemas de información que no hayan sido comen-tados en el módulo y describid su causa.

2. Para cada una de las siguientes descripciones identificad si se trata de un error y/o undefecto y/o un fallo (o ninguno de ellos):

a) Un usuario informa de que el manual del aplicativo VCV no está actualizado porque nodescribe una opción que aparece en el menú principal. Se comprueba que realmente faltabaen el manual.

b) Un usuario informa de que no tiene acceso al sistema VCV y que este está caído. Despuésde que los administradores realicen diferentes validaciones comprueban que el usuario notenía su cable de red conectado.

c) Por no tener conocimientos de buenas prácticas de desarrollo seguro un programador novalida correctamente los datos de entrada, hecho que deja una puerta abierta a los ataquesde seguridad. Han pasado tres años desde la puesta en marcha y ningún atacante ha entradonunca en el sistema.

d) Un probador especifica incorrectamente la prueba que tiene que comprobar que no sepuede reservar una plaza ya reservada en un vuelo. Posteriormente, durante la puesta enmarcha del aplicativo VCV, dos usuarios han podido reservar la misma plaza. En el momentode la facturación en el aeropuerto el segundo en llegar no puede viajar y se le comunica quesu plaza ya está ocupada.

3. Supongamos que encontramos un defecto en una aplicación con las siguientes caracterís-ticas:

• El defecto ha afectado a unos 100 usuarios. Cada usuario comporta para la organizaciónun coste medio por hora de 20 € (incluida la seguridad social...).

• El defecto ha sido informado por 20 usuarios al servicio telefónico. La atención necesariapara atender a cada usuario ha durado 15 minutos de media. Cada operador telefónicotiene un coste por hora de 10 €.

• El desarrollador (con coste de 30 €/hora) ha dedicado 8 horas a investigar y corregir eldefecto. Desde que se notificó la incidencia hasta que el desarrollador empezó la inves-tigación pasaron 2 horas.

• El probador (con un coste 40 €/hora) ha necesitado 3 horas para verificar que el progra-mador ha corregido correctamente el defecto.

• Para paquetizar de nuevo el aplicativo e instalarlo en el entorno productivo se han nece-sitado 2 horas de un arquitecto, que tiene un coste de 50 €/hora.

¿Cuáles son los costes totales derivados de este defecto? Analizad la importancia de invertiren calidad para evitar estos costes.

4. Describid en pocas líneas cuál es proceso de clasificación de defectos que propone IBM(clasificación ortogonal) y cuál es su objetivo. ¿Por qué creéis que es importante categorizarlos tipos de defectos que nos podemos encontrar?

5. Durante unas pruebas se detectan diferentes defectos que se clasifican en la siguiente se-veridad y prioridad:

• D1. Severidad = Alta; Probabilidad = Usualmente• D2. Severidad = Crítica; Probabilidad = En raras ocasiones• D3. Severidad = Baja; Probabilidad = Siempre• D4. Severidad = Crítica; Probabilidad = Usualmente• D5. Severidad = Media; Probabilidad = Usualmente

¿En qué orden se tendrían que corregir los defectos?

6. Analizad el estándar IEEE 1044 y determinad en qué fase y categoría se tiene que incluirla siguiente información (con los códigos RR del estándar). Asimismo, estableced cuál será elvalor adecuado para cada categoría identificada.

a) Un revisor ha identificado durante la fase de diseño del sistema un posible error en ladocumentación técnica, ya que no parece basarse en los estándares de la organización.

b) Un usuario interno del aplicativo VCV ha identificado un problema en la generación de lafacturación del mes anterior de febrero, ya que los datos aparecen desplazados un día respectodel día real. Este problema sabe reproducirlo fácilmente.


c) Durante el análisis del defecto, se comprueba que la causa real del defecto anterior era elsistema operativo en el que corre el aplicativo, que tiene un bug reconocido por el fabricante.

7. Estableced qué diferencias hay entre CMMI-DEV, CMMI-ACQ y CMMI-SVC. ¿Cuál de estasaplicaríais a una administración pública que subcontrata el 100% del desarrollo?

8. Descargad desde la web del SEI la última versión de la documentación de CMMI (CM-MI-DEV) y describid el área de proceso de "validación", indicando cuáles son los objetivosy las prácticas específicas.

9. Nuestra organización quiere mejorar en el desarrollo de los planes de pruebas. ¿Cuáles sonlas recomendaciones o prácticas que tendríamos que establecer basándonos en TMMI?

10. La empresa para la que desarrollamos un aplicativo ha establecido penalizaciones que sebasan en la eficiencia en la eliminación de defectos (EED). La penalización consiste en que sedescuente del precio total del proyecto (500.000 €) la diferencia entre el valor de eficiencia85% y el valor EED real en la fase de pruebas. Si partimos del ejemplo del subapartado 4.5.2,calculad cuál será el valor de penalización.

Ejercicios de autoevaluación

1. ¿Cómo podemos determinar que un software es de calidad?

2. ¿Cuáles son las diferencias entre un defecto, un error y un fallo? ¿Se produce siempre unfallo como consecuencia de un defecto?

3. ¿Cuáles son los mecanismos que tiene al alcance una organización para llegar a la calidaden sus procesos y productos de software?

4. ¿Cuáles son las diferencias que hay entre las pruebas y las revisiones? ¿Y cuál es la diferenciaprincipal que existe entre control de calidad y aseguramiento de la calidad?

5. ¿Qué ejemplos podemos encontrar dentro de los costes de prevención y evaluación? ¿Ydentro de los costes por fallo interno y externo?

6. ¿Por qué llamamos bugs a los defectos? ¿En qué consiste el proceso de debugging?

7. ¿En qué momentos del ciclo de vida se introducen y detectan más defectos? ¿Cuándo seránmás costosos de corregir? ¿De qué forma creéis que se podría reducir el coste de su corrección?

8. Si encontramos varios defectos durante unas pruebas, ¿cómo sabemos cuáles se tienen quecorregir en primer lugar?

9. ¿Qué modelo estándar propondríais en una organización dedicada al desarrollo de softwarepara conseguir la gestión de la calidad total?

10. Explicad y describid cuáles son las dos alternativas que proporciona CMMI para que unaorganización establezca un plan de mejora de sus procesos de desarrollo.

11. Suponed que una organización utiliza CMMI, pero quiere usar un modelo de mejoradirigido a las pruebas que sea fácil de equiparar con CMMI. ¿Qué modelo propondríais?

12. ¿Cuál es el modelo más reconocido para la calidad del producto de software? ¿Qué nivelesde calidad establece? ¿Qué otros modelos conocéis?

13. ¿Por qué es importante medir objetivamente la calidad de los procesos y productos desoftware que una organización realiza? ¿Qué tres tipos de métricas podemos definir, segúnel método de su obtención?

14. ¿Cómo podemos medir el tamaño de un software? ¿Cuáles son las ventajas de cada unade las opciones?

15. ¿Qué métrica utilizaríais para medir en qué punto de nuestro proceso del ciclo de vidasomos menos productivos en la detección y eliminación de defectos?

16. ¿Con qué métrica podríamos determinar el número de casos de prueba que tenemosque realizar para probar todos los caminos posibles de una función? ¿Y con cuál podemosdeterminar qué porcentaje de nuestro software no estamos probando?


Solucionario

Actividades

Solución�de�la�actividad�1

Libre


a) Error, defecto y fallo. Un desarrollador habrá olvidado que, ante un cambio en el software,tenía que actualizar el manual. Eso ha provocado un defecto en el manual, que finalmenteha sido detectado por un usuario (fallo).

b) Se trata únicamente de una incidencia, y no había ningún defecto en el aplicativo. Sinembargo, podemos considerar que ha sido un error del usuario.

c) Error (carece de conocimientos) y defecto (tratamiento de validación incorrecto). No esun fallo, porque nunca se ha reproducido el ataque.

d) En este caso hay dos escenarios. El primero incluye el defecto introducido por el progra-mador, que no ha realizado un bloqueo transaccional para evitar que dos personas puedanreservar la misma plaza, y el fallo en el momento real en que estas se han encontrado enel aeropuerto. El segundo escenario es debido al error cometido por el probador al no haberconsiderado este escenario, que hubiera encontrado el defecto del primer escenario y evitadosu fallo al ser corregido.


En primer lugar, podemos calcular el coste asociado a la corrección del defecto, sus pruebasy el despliegue:

Actividad Tiempo(en horas)

Coste / ho-ra recurso

Afectación (usuario/recurso) Coste por actividad

Atención usuario 0,25 (15 min) 10 20 50 €

Inactividad usuarios 15 20 100 30.000 €

Corrección 8 30 1 240 €

Pruebas 3 40 1 120 €

Despliegue 2 50 1 100 €

Total coste del defecto 30.510 €

El período de inactividad de 15 horas para cada usuario resulta de la suma de los intervalosdesde que se produjo la incidencia hasta su puesta en funcionamiento (despliegue): 2 + 8+ 3 + 2 = 15 h.


El proceso de clasificación ortogonal de defectos de IBM intenta categorizar los defectos paratrasladarlos a defectos en el proceso. Los defectos se clasifican en 8 atributos, un grupo inicialde 3 atributos que se describen en el momento en el que se encuentra el defecto, y un grupofinal de 5 atributos que se valoran cuando se ha corregido el defecto. Es importante catego-rizar los tipos de defectos para poder analizar dónde tenemos que focalizar los esfuerzos enprevención (formación...) y pruebas (dirigir las pruebas a los tipos de defectos más comunes).


Traduciendo las descripciones a sus valores y multiplicando la severidad por la probabilidadobtenemos que:

• D1 Severidad alta(2) × Probabilidad usualmente(2) = 4• D2. Severidad crítica(1) × Probabilidad en raras ocasiones(4) = 4• D3. Severidad baja(4) × Probabilidad siempre(1) = 4


• D4. Severidad crítica(1) × Probabilidad usualmente(2) = 2• D5. Severidad media(3) × Probabilidad usualmente(2) = 6

El orden de prioridad es D4, {D1, D2, D3}, D5. D1, D2 y D3 pueden tratarse bajo la mismaprioridad, pero se tendrá que determinar si se da más importancia a la severidad en caso deempate o se analizarán los defectos para decidir en qué orden se quieren resolver.


a) La información aportada corresponde a la fase de reconocimiento:

• Actividad del proyecto: RR120 (revisión)• Fase del proyecto: RR221 (diseño del sistema)• Causa sospechosa: RR315 (documentación)

b) Fase de reconocimiento:

• Actividad del proyecto: RR180 (soporte/operacional)• Fase del proyecto: RR250 (operación y mantenimiento)• Causa sospechosa: RR313 (datos del producto)• Repetibilidad: RR440 (reproducible)

c) Fase de investigación.

• Causa real: IV132 (plataforma-sistema operativo)• Tipo: IV402 (otro problema)


CMMI define tres áreas de interés o constelaciones. CMMI-DEV está dirigido a los procesosde desarrollo, CMMI-ACQ a cómo se tienen que gestionar los procesos de adquisición dedesarrollo de terceros y CMMI-SVC a cómo definir, gestionar y entregar los servicios (equi-valentes o comparables a ITIL). En el caso expuesto, dicha administración pública tendríaque optar por seguir el modelo CMMI-ACQ.


Contenido descrito en las páginas 393 a 400 del modelo que se puede descargar en http://www.sei.cmu.edu/cmmi.


Tendríamos que instaurar en nuestro proceso de pruebas la realización de las siguientes ac-tividades:

a) El calendario de las pruebas (SP4.1), identificando restricciones en duración, recursos yentradas necesarias, dependencias en las tareas, etc.

b) Planificar el equipo de pruebas (SP 4.2).

c) Planificar la implicación de los implicados (SP 4.3).

d) Identificar los riesgos de pruebas del proyecto (SP 4.4).

e) Establecer el plan de pruebas (SP 4.5).

Esta información se puede encontrar más detallada en las páginas 39 a 41 del modelo dereferencia de TMMI (versión 3.1), descargable en http://www.tmmifoundation.org/html/tmmiref.html.


Eficiencia en la eliminación de defectos de la fase de pruebas:

EED (Pruebas) = (6 + 3 + 10)/(6 +1 + 3 + 2 + 10 + 5) × 100% = 70,37%

(85% - 70,37%) × 500.000 € = 73.148,14 € de penalización

Ejercicios de autoevaluación

1. Un software es de calidad si no tiene defectos y las necesidades de los usuarios están cu-biertas, tanto las que los usuarios o clientes hayan especificado como las que, a pesar de no



http://www.tmmifoundation.org/html/tmmiref.html

http://www.tmmifoundation.org/html/tmmiref.html


estar especificadas, se consideran como obvias, que tienen que ser cubiertas (un buen rendi-miento, buena fiabilidad, seguro, etc.).

2. Un error es una equivocación, intencionada o no, de un desarrollador. Este hecho provocala introducción de un defecto en el software (documento, código fuente, etc.). Como conse-cuencia de este defecto, un observador puede detectar un comportamiento inesperado. Enotros casos hay fallos provocados por condiciones del entorno.

Un defecto no siempre produce un fallo. Si el defecto queda residente sin reproducir unresultado inesperado, no se produce ningún fallo. Solo se produce el fallo en el momento enque se dan las condiciones para que el defecto tenga un efecto negativo sobre los resultadosesperados.

3. Una organización tiene a su alcance diferentes mecanismos para alcanzar la calidad, en-focándose tanto a los procesos como al producto, el proyecto o los recursos. Habitualmentese sigue un camino de mejora que empieza por las pruebas, pasa por las revisiones y el ase-guramiento de la calidad y finalmente, termina por la gestión de la calidad total.

4. Las pruebas se realizan sobre el software en ejecución, para encontrar fallos. En las revi-siones se evalúan documentos y código fuente para encontrar defectos. El control de calidadcomprueba si se alcanza un nivel concreto de calidad, evaluando el cumplimiento de losestándares en cada paso del ciclo de vida. El aseguramiento de la calidad es preventivo, y seorienta al proceso que produce el producto.

5. Algunos costes de prevención pueden ser la inversión al definir procesos y estándares ola formación, entre otros. Dentro de los costes de evaluación encontramos las pruebas o lasrevisiones del producto construido, etc. Como costes de fallo interno encontramos aquelloscostes derivados de una mala calidad, antes de que llegue a los usuarios finales: correcciónde los defectos encontrados en las pruebas (que se incluyen en los costes de evaluación), larepetición de las pruebas para verificar que se han corregido bien los defectos detectados, etc.En los costes de fallo externo encontramos costes cuantitativos, como el tiempo de indispo-nibilidad, los costes de atención telefónica a los usuarios por incidencias, así como tambiéncualitativos, como la repercusión en imagen.

6. Se cree, aunque no se sabe seguro, que el concepto bug se asimila a los defectos porque elprimer caso reconocido de defecto fue por el hallazgo de un insecto dentro de una máquinaen la Universidad de Harvard que producía continuos fallos. El concepto debugging implicael hallazgo y eliminación de un defecto (con el análisis y corrección del mismo).

7. El mayor número de defectos se suelen introducir en las primeras fases del ciclo de vida,pero son detectados ya prácticamente al final de este, antes de la puesta en marcha del apli-cativo. En ese momento serán más costosos de corregir, ya que posiblemente tendremos quehacer modificaciones en diferentes partes del sistema o de los entregables intermedios pre-vios. La mejor solución para reducir el coste es incorporar revisiones ya en las fases inicialesdel ciclo de vida.

8. Usando su severidad y probabilidad, por ejemplo.

9. La ISO 90003 y la 9004, por ejemplo.

10. CMMI ofrece dos modelos de progreso: por madurez y por capacidad. En el primer caso,la organización puede seguir un camino preestablecido de madurez, en el que describe paracada nivel el conjunto de procesos que se tienen que abordar antes de pasar al siguiente nivel.En el modelo de capacidad, la madurez se alcanza dentro de un proceso concreto.

11. TMMI, ya que se basa en el modelo establecido para CMMI.

12. La ISO9126, que define 3 niveles de calidad, la calidad de uso, la calidad externa y lacalidad interna. Otros modelos reconocidos, en los que se basa la ISO9126, son el modelode McCall y el modelo de Boehm.

13. Es importante medir para verificar que el nivel requerido de calidad se está alcanzando.En caso de que este no se alcance, nos servirá para determinar qué mejoras aplicar y poste-riormente poder comparar en el tiempo la mejora alcanzada. Las métricas pueden ser direc-tas si se basan en un atributo observado, derivadas si se obtienen a partir de las primeras opor combinación de derivadas y directas, o indicadores si son métricas dirigidas a la tomade decisiones.

14. Podemos medir el software según sus líneas de código, o bien según sus puntos función.El primer método depende mucho del lenguaje utilizado y del estilo de programación, por loque no permite una comparación unívoca entre diferentes programas. En cambio, el segundo


método se basa en los puntos función, que se calculan según las especificaciones, y, por lotanto, es independiente del lenguaje de programación.

15. La eficiencia en la eliminación de defectos.

16. Con la complejidad ciclomática o métrica de McCabe y con la métrica de cobertura,respectivamente.


Glosario

AENOR f Organismo encargado de la difusión y normalización de normas técnicas en Es-paña y certificadora de referencia para la acreditación de las empresas en el cumplimiento delos requisitos establecidos en alguna norma. sigla de Asociación Española de Normalizacióny Certificación.

anomalía f Ved incidencia

bug m Ved defecto

CMMI k Modelo de referencia para la mejora de los procesos de desarrollo de una organi-zación. Establece dos opciones de mejora, uno para seguir un camino predeterminado y otraque permite focalizarse en aquellas áreas de proceso más importantes para la organización.sigla de capability maturity model integration

debugging m Acción consistente en buscar, analizar y eliminar las causas de un fallo.

defecto m Anomalía en el software que puede hacer que este se comporte de forma inco-rrecta, y contrariamente a su especificación.

EFQM f Modelo de referencia europeo para la búsqueda de la excelencia de las organiza-ciones en calidad, orientado a los procesos. sigla de European Foundation for Quality Ma-nagement.

error m Mala interpretación o equivocación cometida por parte de un desarrollador.

fallo m Consecuencia de un defecto sobre el sistema, observada por un desarrollador, pro-bador o usuario, que inhabilita su correcto funcionamiento y produce resultados que no sonlos esperados.

framework m y f Estructura conceptual o real que tiene como objetivo servir de soportea la construcción de algo útil.

incidencia f Cualquier situación que difiere del comportamiento esperado.

ISO 9000 m y f Familia de estándares para la gestión y el aseguramiento de la calidad enlas organizaciones.

ISO 15504 m y f Modelo de referencia para la mejora de procesos de desarrollo de unaorganización, muy similar a CMMI, pero que utiliza como base de procesos de desarrollo elestándar ISO 12207.

ISO 12207 m y f Estándar que establece cuáles son los procesos necesarios en un ciclo devida de software, desde la definición de los requisitos hasta su finalización.

modelo de calidad m Conjunto de características y relaciones que dan la base para espe-cificar requisitos de calidad y evaluarlos.

prueba f Proceso para verificar si un programa en ejecución satisface los requisitos especi-ficados y detectar fallos.

PSM f La metodología PSM representa las mejores prácticas en la medición de software ysistemas. Está esponsorizada por el Departamento de Defensa de Estados Unidos. sigla depractical software and systems measurement.

calidad f Concepto subjetivo que depende de la valoración de cada persona, pero quedesde un punto de vista técnico de software se puede definir como un producto o serviciolibre de defectos que satisface los requisitos especificados por el usuario y sus expectativas.

revisión f Técnica de examen de documentación o código para detectar defectos.

SCAMPI m Método de evaluación para determinar el nivel de madurez de una organizaciónen la consecución de CMMI. sigla de standard CMMI appraisal method for process improvement.

severidad f Grado o impacto que tiene un defecto sobre el uso del sistema.

testing m Ved prueba.

validación f Proceso de evaluación de un software durante o al final del proceso de desa-rrollo para determinar que satisface los requisitos especificados.


verificación f Proceso de evaluación de un software para determinar que los productosresultantes de una fase de desarrollo satisfacen las condiciones impuestas al principio de estafase.


Bibliografía

Beizer, B. (1990). Software Testing Techniques. The Coriolis Group.

Boehm, B. (2001). "Software Defect Reduction Top 10 List". IEEE Computer Society (vol. 34,enero 2001, pág. 135).

Campanella, J. (1999). Principles of Quality Costs. ASQ Quality Press.

Copeland, L. (2004). A Practitioner's Guide to Software Test Design. Artech House.

Galin, D. (2004). Software Quality Assurance: From theory to implementation. Pearson, AddisonWesley.

Jones, C. (2009). Software Quality in 2010: A Survey of the State of the Art.

Kshirasagar Naik, Priyadarshi Tripathy (2008). Software Testing and Quality Assurance.Theory and Practice. Wiley.

Schulmeyer, G. (2008). Handbook of Software Quality Assurance. Artech House

Tian, J. (2005). Software Quality Engineering. Wiley.

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

Documents

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