2.6 CALIDAD DEL PROYECTO

2.6.1 ESTRATEGIAS DE PRUEBA

Integra las técnicas de diseño de casos de prueba en una serie de pasos bien planificados que dan como resultado una correcta construcción del software. También describe un mapa con los pasos que hay que llevar acabo como parte de la prueba, cuando se debe planificar y realizar esos pasos, cuanto esfuerzo, tiempo y recursos se van a requerir.

 2.6.1.1 UN ENFOQUE ESTRATÉGICO PARA LAS PRUEBAS DEL SW

n  Las pruebas comienzan a nivel de modulo y trabajan hacia fuera.

n  Según el momento son apropiadas diferentes técnicas de prueba.

n  La prueba la lleva acabo el responsable del desarrollo del SW.

n  La prueba y la depuración son actividades diferentes, pero la depuración se debe incluir en cualquier estrategia de prueba.

2.6.1.2 VERIFICACIÓN Y VALIDACIÓN (V &V)

La verificación se refiere al conjunto de actividades que asegura que el software implementa adecuadamente una función específica.

La validación se refiere a un conjunto diferente de actividades que aseguran que el software construido se ajusta a lo requerimientos del cliente.

    Bohem, lo define de otra forma:

Verificación “¿Estamos construyendo el producto correctamente?”

Validación “¿Estamos construyendo el producto correcto?”

2.6.1.3 ORGANIZACIÓN PARA LAS PRUEBAS DEL SW

No es correcto:

n  El responsable del desarrollo no debería entrar en la prueba.

n  El SW debe ser puesto a salvo de personas que puedan probarlo de forma despiadada.

n  Los encargados de la prueba solo aparecen cuando comienzan las etapas de la prueba.

2.6.1.4 UNA ESTRATEGIA DE PRUEBA DEL SW

n  La prueba en el contexto de espiral

CRITERIOS PARA COMPLETAR LA PRUEBA

Cada vez que se tratan de las pruebas del SW surgen unas preguntas clásicas:

¿Cuándo hemos terminado la prueba?

 ¿Cómo sabemos que hemos probado lo suficiente?

‘¿Cuando debemos probar?’

Una respuesta a la “La prueba nuca termina ya que el responsable carga o pasa el problema al cliente

Otra respuesta algo cínica es “Se termina la prueba cuando se agota el tiempo o el dinero disponible para cada efecto

2.6.1.5 ASPECTOS ESTRATÉGICOS

n  Ton Gilb, plantea que se deban abordar los siguientes puntos si se desea implementar con éxito una estrategia de prueba del SW:

n  Especificar los requisitos del producto de manera cuantificable mucho antes que comiencen las pruebas.

n  Establecer los objetivos de la prueba de manera explicita.

n  Comprender que usuarios van a manejar el SW y desarrollar un perfil para cada categoría de usuario.

Desarrollar un plan de prueba que haga hincapié en la prueba de ciclo rápido.

Construir un SW robusto diseñado para probarse así mismo.

Usar revisiones técnicas formales y efectivas como filtro antes de la prueba.

Llevar acabo revisiones técnicas formales para evaluar la estrategia de prueba y los propios casos de prueba.

Desarrollar un enfoque de manera continua al proceso de prueba. Debería medirse la estrategia de prueba.

2.6.1.6 PRUEBA DE UNIDAD.

La prueba de unidad centra el proceso de verificación en la menor unidad del diseño del software (Módulo). Aquí se prueban los caminos de control importantes, con el fin de descubrir errores dentro del ámbito de un módulo.

¿QUÉ ERRORES SON LOS MÁS COMUNES DURANTE LA PRUEBA DE UNIDAD :

  1. Procedencia aritmética incorrecta mal aplicada
  2. Operaciones de modo mezcladas.
  3. Inicializaciones incorrectas.
  4. Falta de precisión.
  5. Representación incorrecta de una expresión.

2.6.1.7 TIPOS DE INTEGRACIÓN

La primera es no incremental “big bang”. Se combinan todos los módulos por anticipado, se prueba todo el producto.

La segunda es una integración incremental en donde se desarrollan módulos pequeños y funcionales que hacen que los errores sean más fácil de aislar y corregir.

2.6.1.8 INTEGRACIÓN DESCENDENTE.

Es una estrategia de integración incremental a la construcción de la estructura de programas, en cual se integran los módulos moviéndose en dirección hacia abajo por la jerarquía de control comenzando con el módulo principal .

Los módulos subordinados al módulo de control principal se incorpora en la estructura, de forma primero-en-profundidad, ó primero-en-anchura

2.6.1.9 INTEGRACIÓN ASCENDENTE.

Es un modelo de integración no incremental, en donde la construcción del diseño empieza de los módulos atómicos (es decir, módulos de los niveles más bajos de la estructura del programa). Dado que los módulos se integran de abajo hacia arriba, el  proceso  requerido de los módulos  subordinados  siempre  está disponible    y    elimina    la   necesidad   de resguardos.

2.6.2.0 LA PRUEBA DE REGRESIÓN.

Cada vez que se añade  un  nuevo  modulo como parte de una prueba de integración el software cambia.

La   prueba   de   regresión   es   volver  a ejecutar un subconjunto de pruebas que se han  llevado  a  cabo  anteriormente  para asegurarse  de  que  los  cambios  no  han propagado efectos colaterales no deseados.

2.6.2.1 PRUEBA DE VALIDACIÓN.

La validación puede definirse de muchas formas, pero una simple definición es que la validación se consigue cuando el software funciona de acuerdo con las expectativas razonables del cliente.

2.6.2.2 CRITERIOS DE LA PRUEBA DE VALIDACIÓN

La prueba alfa se lleva a cabo, por un cliente, en el lugar de desarrollo. Se usa el software de forma natural con el desarrollador como observador del usuario y registrando los errores y los problemas de uso. Las pruebas alfa se llevan a cabo en un entorno controlado.

La prueba beta se lleva a cabo por los usuarios finales del software en los lugares de trabajo de los clientes. A diferencia de la prueba alfa, el desarrollador no está presente normalmente. Así, la prueba beta es una aplicación «en vivo» del software en un entorno que no puede ser controlado por el desarrollador.

2.6.2.3 PRUEBA DEL SISTEMA

Un problema típico es la «delegación de culpabilidad», esto ocurre cuando se descubre un error y cada uno de los creadores de cada elemento del sistema echa la culpa del problema a los otros. Se debe anticipar a los posibles problemas y:

    1. diseñar caminos de manejo de errores que prueben toda la información procedente de los elementos del sistema;
    2. llevar a cabo una serie de pruebas que simulen la presencia de datos en mal estado o de otros posibles errores en la interfaz del software;
    3. registrar los resultados de las pruebas como «evidencia» en el caso de que se le señale con el dedo;
    4. participar en la planificación y el diseño de pruebas del sistema para asegurarse de que el software se prueba de forma adecuada.

2.6.2.4  PRUEBA DE SEGURIDAD

Este acceso al sistema incluye un amplio rango de actividades: «piratas informáticos» que intentan entrar en los sistemas por deporte, emplea­dos disgustados que intentan penetrar por venganza e individuos deshonestos que intentan penetrar para obtener ganancias personales ilícitas.

La prueba de seguridad  intenta verificar que los mecanismos de protección incorporados en el sistema lo protegerán, de hecho, de accesos impropios.

2.6.2.5 PRUEBA DE RESISTENCIA (STRESS)

La prueba de resistencia ejecuta un sistema de forma que demande recursos en cantidad, frecuencia o volúmenes anormales. Por ejemplo:

  1. incrementar las frecuencias de datos de entrada en un orden de magnitud con el fin de comprobar cómo responden las funciones de entrada;
  2. diseñar pruebas especiales que generen diez, interrupciones por segundo, cuando las normales son una o dos;
  3. ejecutar casos de prueba que requieran el máximo de memoria o de otros recursos;
  4. diseñar casos de prueba que puedan dar problemas en un sistema operativo virtual

2.6.2.6  PRUEBA DE RENDIMIENTO

La prueba de rendimiento está diseñada para probar el rendimiento del software en tiempo de ejecución dentro del contexto de un sistema integrado.

La prueba de rendimiento se da durante todos los pasos del procesó de la prueba. Incluso al nivel de unidad, se debe asegurar el rendimiento de los módulos individuales a medida que se llevan a cabo las pruebas de caja blanca. Sin embargo, hasta que no están completamente integrados todos los elementos del sistema no se puede asegurar realmente el rendimiento del sistema.

2.6.2.7  EL ARTE DE LA DEPURACIÓN.

La depuración ocurre como consecuencia de una prueba efectiva. Es decir, cuando un caso de prueba descubre un error, la depuración es el proceso que provoca la eliminación del error.

Aunque la depuración puede y debe ser un proceso ordenado, sigue teniendo mucho de arte. Un ingeniero del software, al evaluar los resultados de una prueba, se encuentra frecuentemente con una indicación «sintomática» de un problema en el software. Es decir, la manifestación externa de un error, y la causa interna del error pueden no estar relacionadas de una forma obvia. El proceso mental, apenas comprendido, que conecta un síntoma con una causa es la depuración.

La depuración no es una prueba, pero siempre ocurre como consecuencia de la prueba. El proceso de depuración siempre tiene uno de los dos resultados siguientes:

  1.  se encuentra la causa, se corrige y se elimina;
  2.  o no se encuentra la causa.

                En este último caso, la persona que realiza la depuración debe sospechar la causa, diseñar un caso de prueba que ayude a confirmar sus sospechas y el trabajo vuelve hacia atrás a la corrección del error de una forma iterativa.

                Durante la depuración encontramos errores que van desde lo ligeramente inesperado (por ejemplo, un formato de salida incorrecto) hasta lo catastrófico (por ejemplo, el sistema falla, produciéndose serios daños económicos o físicos).

EL PROCESO DE DEPURACIÓN

CONSIDERACIONES PSICOLÓGICAS

Desafortunadamente, todo parece indicar que la habilidad en la depuración es un rasgo innato del ser humano. A ciertas personas se les da bien y a otras no. Aunque las manifestaciones experimentales de la depuración están abiertas a muchas interpretaciones, se han detectado grandes variaciones en la destreza para la depuración de distintos programadores con el mismo bagaje de formación y de experiencia.

ENFOQUES DE LA DEPURACIÓN

Depuración por fuerza bruta es la más común y menos eficiente a la hora de aislar la causa del error en el software. Aplicamos la depuración por fuerza bruta cuando todo lo demás falla.

La vuelta atrás es un enfoque más normal porque se puede usar con éxito para pequeños programas. Partiendo del lugar donde se descubre el síntoma, se recorre hacia atrás el código fuente hasta que se llega a la posición de error. Pero a medida que aumenta el número de líneas del código, el número de posibles caminos de vuelta se hace difícilmente manejable.

la depuración eliminación de causas se manifiesta mediante inducción o deducción e introduce el concepto de partición binaria. Los datos relacionados con la ocurrencia del error se organizan para aislar las posibles causas. Se llega a una «hipótesis de causa» y se usan los datos anteriores para probar o revocar la hipótesis

 

2.6.2.0 TECNICAS DE PRUEBA

El desarrollo de Sistemas de software implica la realización de una serie de actividades predispuestas a incorporar errores (en la etapa de definición de requerimientos, de diseño, de desarrollo, …).

Debido a que estos errores se deben a nuestra habilidad innata de provocar errores, tenemos que incorporar una actividad que garantice la calidad del software.

En este capítulo estudiaremos:

  • • Fundamentos de la prueba del software, que definen los objetivos fundamentales de la fase de prueba.
  • • Diseño de casos de prueba, que se centra en un conjunto de técnicas para que satisfagan los objetivos globales de la prueba.

 

2.6.2.1.0 FUNDAMENTOS DE LA PRUEBA DEL SOFTWARE

En la etapa de prueba del software se crean una serie de casos de prueba que intentan “destruir” el software desarrollado.

La prueba requiere que se descarten ideas preconcebidas sobre la “calidad o corrección” del

software desarrollado.

2.6.2.1.1           Objetivos de la prueba

  • La prueba es un proceso de ejecución de un programa con la intención de descubrir un error

  • • Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces
  • • Una prueba tiene éxito si descubre un error no detectado hasta entonces

 El objetivo es diseñar casos de prueba que, sistemáticamente, saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y de esfuerzo.

La prueba no puede asegurar la ausencia de errores; sólo puede demostrar que existen defectos en el software.

2.6.2.1.2. Proceso de prueba

El proceso de prueba tiene dos entradas:

  • • Configuración del software: Incluye la especificación de requisitos del software, la especificación del diseño y el código fuente
  • • Configuración de prueba: Incluye un plan y un procedimiento de prueba.

Si el funcionamiento del software parece ser correcto y los errores encontrados son fáciles de corregir, podemos concluir con que:

  • • La calidad y la fiabilidad del software son aceptables, o que
  • • Las pruebas son inadecuadas para descubrir errores serios

 

Se trata de diseñar pruebas que tengan la mayor probabilidad de encontrar el mayor número de errores con la mínima cantidad de esfuerzo y de tiempo.

Cualquier producto de ingeniería se puede probar de dos formas:

  • Pruebas de caja negra: Realizar pruebas de forma que se compruebe que cada función es operativa.
  • Pruebas de caja blanca: Desarrollar pruebas de forma que se asegure que la operación interna se ajusta a las especificaciones, y que todos los componentes internos se han probado de forma adecuada.

En la prueba de la caja negra, los casos de prueba pretenden demostrar que las funciones del software son operativas, que la entrada se acepta de forma adecuada y que se produce una salida correcta.

En la prueba de caja blanca se realiza un examen minucioso de los detalles procedimentales, comprobando los caminos lógicos del programa, comprobando los bucles y condiciones, y examinado el estado del programa en varios puntos.

A primera vista, la prueba de caja blanca profunda nos llevaría a tener “programas 100 por cien correctos”, es decir:

  • • Definir todos los caminos lógicos
  • • Desarrollar casos de prueba para todos los caminos lógicos
  • • Evaluar los resultados

Pero esto supone un estudio demasiado exhaustivo, que prolongaría excesivamente los planes de desarrollo del software, por lo que se hará un estudio de los caminos lógicos importantes.

 

2.6.2.1.4 PRUEBA DE LA CAJA BLANCA

La prueba de la caja blanca es un método de diseño de casos de prueba que usa la estructura de control del diseño procedimental para derivar los casos de prueba.

Las pruebas de caja blanca intentan garantizar que:

  • • Se ejecutan al menos una vez todos los caminos independientes de cada módulo
  • • Se utilizan las decisiones en su parte verdadera y en su parte falsa
  • • Se ejecuten todos los bucles en sus límites
  • • Se utilizan todas las estructuras de datos internas

 

2.6.2.1.5 Prueba del camino básico

El método del camino básico (propuesto por McCabe) permite obtener una medida de la complejidad de un diseño procedimental, y utilizar esta medida como guía para la definición de una serie de caminos básicos de ejecución, diseñando casos de prueba que garanticen que cada camino se ejecuta al menos una vez.

 Notación del grafo de flujo o grafo del programa

Representa el flujo de control lógico con la siguiente notación:

A continuación se muestra un ejemplo basado en un diagrama de flujo que representa la estructura de control del programa.

En el grafo de flujo

  • • Cada nodo representa una o más sentencias procedimentales
  • • Un solo nodo puede corresponder a una secuencia de pasos del proceso y a una decisión
  • • Las flechas (aristas) representan el flujo de control

Cualquier representación del diseño procedimental se puede traducir a un grafo de flujo.

Si en el diseño procedimental se utilizan condiciones compuestas, la generación del grafo de flujo tiene que descomponer las condiciones compuestas en condiciones sencillas, tal y como muestra la figura siguiente.

2.6.2.1.5 Complejidad ciclomática

Es una medida que proporciona una idea de la complejidad lógica de un programa.

  • • La complejidad ciclomática coincide con el número de regiones del grafo de flujo
  • • La complejidad ciclomática, V(G), de un grafo de flujo G, se define como:

                      V (G) = Aristas – Nodos + 2

  • • La complejidad ciclomática, V (G), de un grafo de flujo G, también se define: como

                      V (G) = Nodos de predicado + 1

A partir del grafo de flujo de la figura 4, la complejidad ciclomática sería:

  • • Como el grafo tiene cuatro regiones, V (G) = 4
  • • Como el grafo tiene 11 aristas y 9 nodos, V (G) = 11 – 9 – 2 = 4
  • • Como el grafo tiene 3 nodos predicado, V (G) = 3 + 1 = 4

A partir del valor de la complejidad ciclomática obtenemos el número de caminos independientes, que nos dan un valor límite para el número de pruebas que tenemos que diseñar.

En el ejemplo, el número de caminos independientes es 4, y los caminos independientes son:

  • • 1-11
  • • 1-2-3-4-5-10-1-11
  • • 1-2-3-6-7-9-10-1-11
  • • 1-2-3-6-8-9-10-1-11

Pasos del diseño de pruebas mediante el camino básico

  • • Obtener el grafo de flujo, a partir del diseño o del código del módulo
  • • Obtener la complejidad ciclomática del grafo de flujo
  • • Definir el conjunto básico de caminos independientes
  • • Determinar los casos de prueba que permitan la ejecución de cada uno de los caminos anteriores
  • • Ejecutar cada caso de prueba y comprobar que los resultados son los esperados

 

2.6.2.1.6 Prueba de bucles

Los bucles son la piedra angular de la inmensa mayoría de los algoritmos implementados en software, por lo que tenemos que prestarles una atención especial a la hora de realizar la prueba del software.

La prueba de bucles es una técnica de prueba de caja blanca que se centra en la validez de las construcciones de los bucles.

Se pueden definir cuatro tipos de bucles diferentes:

  • • Bucles simples
  • • Bucles concatenados
  • • Bucles anidados
  • • Bucles no estructurados

2.6.2.1.7 Bucles simples

A los bucles simples (de n iteraciones) se les tiene que aplicar el conjunto de pruebas siguientes:

  • • Saltar el bucle
  • • Pasar sólo una vez por el bucle
  • • Pasar dos veces por el bucle
  • • Hacer m pasos del bucle con m < n
  • • Hacer n-1, n y n+1 pasos por el bucle

 

2.6.2.1.8 Bucles anidados

Si extendiésemos el conjunto de pruebas de los bucles simples a los bucles anidados, el número de pruebas crecería geométricamente, por lo que Beizer sugiere el siguiente conjunto de pruebas para bucles anidados:

  • • Comenzar con el bucle más interno, estableciendo los demás bucles a los valores mínimos
  • • Llevar a cabo las pruebas de bucles simples para el bucle más interno, conservando los valores de iteración de los bucles más externos a los valores mínimos
  • • Progresar hacia fuera en el siguiente bucle más externo, y manteniendo los bucles más externos a sus valores mínimos
  • • Continuar hasta que se hayan probado todos los bucles

 

2.6.2.1.9 Bucles concatenados

Probar los bucles concatenados mediante las técnicas de prueba para bucles simples, considerándolos como bucles independientes.

 

2.6.2.2.0 Bucles no estructurados

Rediseñar estos bucles para que se ajusten a las construcciones de la programación estructurada.

Ejemplo

Construir el Grafo de Flujo correspondiente a la siguiente especificación del software en LDP.

Ejemplo

Construir el Grafo de Flujo correspondiente al siguiente código de un programa

2.6.2.2.1 PRUEBA DE LA CAJA NEGRA

Las pruebas de caja negra se llevan a cabo sobre la interfaz del software,

obviando el comportamiento interno y la estructura del programa.

Los casos de prueba de la caja negra pretenden demostrar que:

  • • Las funciones del software son operativas
  • • La entrada se acepta de forma correcta
  • • Se produce una salida correcta
  • • La integridad de la información externa se mantiene

A continuación se derivan conjuntos de condiciones de entrada que utilicen

todos los requisitos funcionales de un programa.

Las pruebas de caja negra pretenden encontrar estos tipos de errores:

  • • Funciones incorrectas o ausentes
  • • Errores en la interfaz
  • • Errores en estructuras de datos o en accesos a bases de datos externas
  • • Errores de rendimiento
  • • Errores de inicialización y de terminación

Los tipos de prueba de cana negra que vamos a estudiar son:

  • • Prueba de partición equivalente
  • • Prueba de análisis de valores límites

 

 Prueba de partición equivalente

Este método de prueba de caja negra divide el dominio de entrada de un programa en clases de datos, a partir de las cuales deriva los casos de prueba.

Cada una de estas clases de equivalencia representa a un conjunto de estados válidos o inválidos para las condiciones de entrada.

 

2.6.2.2.2 Identificación de las clases de equivalencia

Se identifican clases de equivalencia válidas e inválidas con la siguiente tabla

A continuación se siguen estas directrices:

  • • Si una condición de entrada especifica un rango de valores (p.e, entre 1 y 999), se define una CEV (1 <= valor <= 999) y dos CEI (valor < 1 y valor > 999)
  • • Si una CE requiere un valor específico (p.e., el primer carácter tiene que ser una letra), se define una CEV (una letra) y una CEI (no es una letra)
  • • Si una CE especifica un conjunto de valores de entrada, se define una CEV para cada uno de los valores válidos, y una CEI (p.e., CEV para “Moto”, “Coche” y “Camión”, y CEI para “Bicicleta”)
  • • Si una condición de entrada especifica el número de valores (p.e., una casa puede tener uno o dos propietarios), identificar una CEV y

dos CEI (0 propietarios y 3 propietarios)

 

Identificación de casos de prueba

Seguir estos pasos

  • • Asignar un número único a cada clase de equivalencia
  • • Escribir casos de prueba hasta que sean cubiertas todas las CEV, intentando cubrir en cada casos tantas CEV como sea posible
  • • Para cada CEI, escribir un caso de prueba, cubriendo en cada caso una CEI

Ejemplo

Diseñar casos de prueba de partición equivalente para un software que capte estos datos de entrada:

  • Código de área: En blanco o un número de tres dígitos
  • Prefijo: Número de tres dígitos que no comiencen por 0 ó 1
  • Sufijo: Número de cuatro dígitos
  • Ordenes: “Cheque”, “Depósito”, “Pago factura”
  • Palabra clave: Valor alfanumérico de 6 dígitos

2.6.3 CALIDAD Y METRICAS

2.6.3.1.1 Introducción

Las métricas del software permiten medir de forma cuantitativa la calidad de sus atributos internos del producto, esto permite al ingeniero evaluar la calidad antes de su construcción. Es importante establecer ¿qué es la calidad del software?,¿Quién lo hace?,¿Por qué es importante?, ¿Cuáles son los pasos? Para determinar la calidad, ¿Cuál es el producto obtenido?, ¿Cómo estar seguro de hacerlo correctamente? Todas estas interrogantes se determinarán a lo largo del desarrollo del presente informe. Aspectos a considerar tales como hacer una distinción entre medida, métrica e indicador, qué factores de calidad se toman en cuenta.

 

2.6.3.1.2 Desarrollo del tema

La medición, considerada como un elemento clave en cualquier proceso de  ingeniería.

Medición: Proceso mediante el cual se asignan números o símbolos a los atributos reales para definirlas de acuerdo con reglas claramente establecidas.

 

2.6.3.1.3Calidad General

Calidad del Software es el cumplimiento de los requisitos de funcionalidad y desempeño explícitamente establecidos, de los estándares de desarrollo explícitamente documentados y de las características implícitas que se esperan de todo software desarrollado profesionalmente.

Con esta definición se destacan tres puntos importantes:

1. Los requisitos del software son la base de las medidas de calidad. La falta de concordancia con estos requisitos es una falta de calidad.

2. Los estándares especificados definen un conjunto de criterios de desarrollo que guían la ingeniería del software. Si no se siguen los criterios, el resultado será, casi seguramente, la falta de calidad.

3. A menudo se soslaya un conjunto de requisitos implícitos. Si el software cumple con sus requisitos explícitos pero no con los implícitos, la calidad del software estará en duda.

 

2.6.3.1.4 Factores de Calidad de McCall

Estos factores se dividen en dos grupos muy importantes:

1. Los que se miden directamente.

2. Los que solo se miden indirectamente. McCall, Richards y Walters propusieron unos factores los cuales se concentran en tres aspectos importantes de un producto de software: sus características operativas, su capacidad para experimentar cambios y su capacidad para adaptarse a nuevos entornos.

Corrección: Grado en que cumple el programa con su especificación y satisface los objetivos que propuso el cliente.

Confiabilidad: Grado en que se esperaría que un programa desempeñe su función con la precisión requerida.

Eficiencia: Cantidad de código y de RR. De cómputo necesarios para que un programa realice su función.

Integridad: Grado de control sobre el acceso al S/W o los datos por parte de personas no autorizadas.

Facilidad de uso: Esfuerzo necesario para prender, operar y preparar los datos de entrada de  un programa e interpretar la salida.

Facilidad de mantenimiento: Esfuerzo necesario para localizar y corregir un error en un programa.

Flexibilidad: Esfuerzo necesario para modificar un programa en operación.

Facilidad de prueba: Esfuerzo que demanda probar un programa con el fin de asegurar que realiza su función.

Portabilidad: Esfuerzo necesario para transferir el programa de un entrono de hardware o software a otro.

Facilidad de reutilización: grado en que un programa puede reutilizarse en otras aplicaciones.

Interoperabilidad: Esfuerzo necesario para acoplar un sistema con otro.

Muchas de estas métricas solo se miden subjetivamente.

 Factores de calidad del estándar ISO 9126

Se desarrolló como un intento por identificar los atributos de calidad para el software de computadora. El estándar identifica 6 puntos:

  •  Funcionalidad
  •  Confiabilidad
  •  Facilidad de uso
  •  Eficiencia
  •  Facilidad de mantenimiento
  •  Portabilidad

 Un marco conceptual para las métricas del producto

 

2.6.3.1.5 Medidas, métricas e indicadores

Aunque estos tres términos suelen utilizarse de manera intercambiable, es necesario especificar las diferencias entre éstos.

Medida: proporciona indicación cuantitativa de la extensión, la cantidad, la dimensión, la capacidad o el tamaño de algún atributo de un producto o proceso.

Medición: acto de determinar una medida.

Métrica: Medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo determinado.

Un ingeniero de software recopila medidas y desarrolla métricas para obtener los indicadores.

Indicador: métrica o combinación de métricas que proporcionan conocimientos. Estos conocimientos le permiten al jefe de proyecto o a los ingenieros de software ajustar el proceso, el proyecto o el producto para que las cosas mejores.

2.6.3.1.5 Medidas, métricas e indicadores

El peligro de tratar de encontrar medidas que caractericen tantos atributos diferentes es que inevitablemente las medidas tienen que satisfacer objetivos que entran en conflicto entre sí. Esto se opone a la teoría de que cada medición debe ser representativa. Aunque la afirmación de Fenton es correcta, muchas personas argumentan que la medición del producto realizada durante las primeras etapas del proceso de software proporciona a los ingenieros un mecanismo consistente y objetivo para evaluar la calidad.

 Principios de medición

Roche sugiere un proceso de medición al que caracterizan cinco actividades:

 Formulación. Derivación de medidas y métricas apropiadas para la representación del software que se considera.

Recolección. Mecanismo con que se acumulan los datos necesarios para derivar las métricas formuladas.

Análisis. Cálculo de las métricas y la aplicación de herramientas matemáticas.

Interpretación. Evaluación de las métricas en un esfuerzo por conocer mejor la calidad de la representación.

Retroalimentación. Recomendaciones derivadas de la interpretación de las métricas del producto transmitidas al equipo del software.

Existen principios que son representativos de muchos otros que podrían proponerse para caracterizar y validar las métricas:

  • Una métrica debe tener propiedades matemáticas deseables.
  • Cuando una métrica representa una característica de software que aumenta cuando se presentan rasgos positivos o que disminuye al encontrar rasgos indeseables, el valor de la métrica debe aumentar o disminuir en el mismo sentido.
  • Cada métrica debe validarse empíricamente en una amplia variedad de contextos antes de publicarse o aplicarse a la toma de decisiones.

 

 Medición del Software Orientado a Objetos

 

El paradigma objetivo/pregunta/métrica (OPM) desarrollado por Basili y Weiss es considerado una técnica para identificar significativa métricas las cuales son aplicables en cualquier parte del proceso de software; destaca la necesidad de:

1. Establecer un objetivo de medición que sea específico para la actividad del proceso o las características del producto que se está evaluando.

2. Definir un conjunto de preguntas que deben responderse con el _n de alcanzar el objeto.

3. Identificar métricas bien formadas que ayuden a responder esas preguntas.

 Los atributos de las métricas efectivas del software Ejiogu define un conjunto de atributos que toda métrica efectiva del software debe abarcar:

  • Simples y calculable
  • Consistentes y objetivas
  • Consistentes en el uso de unidades y dimensiones
  • Independientes del lenguaje de programación
  • Mecanismos efectivos para la retroalimentación de alta calidad

 

 Panorama de las métricas del producto

          Métricas para el modelo de análisis

         Incluyen aspectos como:

  • Funcionalidad entregada
  • Tamaño del sistema
  • Calidad de la especificación

Métricas para el modelo de diseño

  • Métricas arquitectónicas
  • Métricas al nivel de componente
  • Métricas de diseño de la interfaz
  • Métricas especializadas en diseño orientado a objetos

Métricas para el código fuente

Se usan para evaluar su complejidad, además la facilidad con que se mantiene y prueba.

  • Métricas de Halstead
  • Métricas de complejidad
  • Métricas de longitud
  • Métricas para pruebas

Ayudan a diseñar casos de prueba efectivos y evaluar la eficacia de las pruebas.

  • Métricas de cobertura de instrucciones y ramas
  • Métricas relacionadas con los defectos
  • Efectividad de la prueba
  • Métricas en el proceso

En muchos modelos las métricas de un modelo pueden aplicarse en actividades posteriores a la ingeniería del software.

 

 Métricas para el modelo de análisis

 Métricas basadas en la función

La métrica de punto de función (PF) es para medir la funcionalidad que entrega un sistema. Se usa para:

1. estimar el costo o el esfuerzo requerido para diseñar, codificar y probar el software

2. predecir el número de errores que se encontrarán durante la prueba

3. pronosticar el número de componentes, de líneas de código proyectadas, o ambas, en el sistema implementado.

Los valores del dominio de la información se definen de la siguiente manera:

Número de entradas externas (EE).

Número de salidas externas (SE)

Número de consultas externas (CE)

Número de archivos lógicos internos (ALI)

Número de archivos de interfaz externos (AIE)

Para calcular los puntos de función se usa la siguiente relación:

Métricas para el modelo de diseño

Métricas del diseño arquitectónico

Consideradas métricas de caja negra ya que no requieren ningún conocimiento del funcionamiento interno de un componente de software en particular.

Card y Glass definen tres medidas de la complejidad del diseño del software:

  • Complejidad Estructural en el caso de arquitecturas jerárquicas

  • Complejidad de datos indica complejidad de la interfaz interna de un módulo

  • Complejidad del sistema es la suma de las complejidades estructural y de datos.

Métricas para el diseño orientado a objetos Whitmire describe nueve características distintivas y mensurables de un Diseño OO:

  • Tamaño
  • Complejidad
  • Acoplamiento
  • Suficiencia
  • Grado de avance
  • Cohesión
  • Primitivismo
  • Similitud
  • Volatilidad

 Métricas para el código fuente

Estás métricas asignadas como cuantitativas por Halstead, se derivan después de que se ha generado el código o se estima una vez que el diseño esté completo.

Las medidas son:

n1 = el número de operadores distintos que aparecen en un programa.

n2 = el número de operandos distintos que aparecen en un programa.

N1= el número total de veces que aparece el operador.

N2= el número total de veces que aparece en operando.

Halstead demuestra que la longitud N se puede estimas de la siguiente manera:

El volumen del programa se define como:

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: