Propuesta de una guía de métricas para evaluar el desarrollo de los Sistemas de Información Geográfica

La calidad es una de las metas propuestas por toda empresa dedicada a la producción de software, tiene una relación directamente proporcional a la satisfacción del cliente, y depende de diversos factores, estrechamente relacionados con el tiempo de desarrollo y la capacidad para cumplir los contratos en la fecha prevista, sin perjuicio para la calidad del producto

Introducción

Para obtener software de calidad es preciso medir el proceso de desarrollo, cuantificar lo que se ha hecho y lo que falta por hacer, estimar el tamaño del programa, costos, tiempo de desarrollo y otros parámetros. La medición de este producto se realiza mediante las métricas, para caracterizar numéricamente los distintos aspectos del desarrollo del software.

Las métricas de software tienen un papel decisivo en la obtención de un producto de alta calidad, porque determinan mediante estadísticas basadas en la experiencia, el avance del software y el cumplimiento de parámetros requeridos. Siempre habrá elementos cualitativos para la creación de software. El problema estriba en que la valoración cualitativa puede no ser suficiente. Un ingeniero del software necesita criterios objetivos para guiarse en el diseño de datos, de la arquitectura, de las interfaces y de los componentes. El verificador necesita una referencia cuantitativa que le ayude en la selección de los casos de prueba y de sus objetivos. Las métricas técnicas facilitan una base para que el análisis, diseño, codificación y prueba puedan ser conducidas más objetivamente y valoradas más cuantitativamente.” (Pressman, 2005)

La Universidad de las Ciencias Informáticas (UCI) surge en el 2002 con la misión de formar profesionales en el campo de la informática a partir de un modelo pedagógico flexible, que vincula dinámicamente el estudio con la producción y la investigación, de acuerdo a las necesidades sociales del país y otros pueblos hermanos (Gil Morell, 2003).

La facultad 9 de la UCI enfoca la producción de software hacia las áreas de televisión digital y geoinformática, a esta área pertenece el proyecto Grupo de Sistemas de Información Geográfica (GSIG) donde actualmente se está desarrollando el SIG-UCI, que consiste en un Sistema de Información Geográfica para el apoyo a la toma de decisiones, a los directivos de la UCI, relacionadas con información espacial y la consulta de esta por parte de los usuarios interesados, en este caso, estudiantes, profesores y demás trabajadores del centro. En los riesgos identificados para el desarrollo del SIG-UCI, elaborada por el GSIG, se observa la falta de métricas que permitan medir el avance del producto en cada etapa de su desarrollo y la calidad del mismo.

Dada la situación planteada anteriormente es una tarea de alta prioridad para el equipo de desarrollo, proponer una guía de métricas que permita evaluar la calidad durante el desarrollo de los productos del GSIG.

Desarrollo de la propuesta de métricas para evaluar el SIG-UCI:

El SIG-UCI es el primer producto del proyecto GSIG por tanto no existen datos históricos sobre tamaño, tiempo de ejecución y desempeño del equipo de desarrollo. Partiendo de esto se define para el GSIG emplear métricas de producto para evaluar la calidad del SIG-UCI, porque permiten cuantificar las características de los artefactos generados en cada flujo de trabajo, además de controlar la estabilidad y calidad del producto durante su desarrollo y evaluar el resultado final.

Las métricas de proceso y proyecto de CMMI, TSP y otros modelos de calidad no se consideran adecuados para el entorno de producción del GSIG porque no se ajustan a sus características particulares ofreciendo valores alejados de la realidad.

Las métricas a aplicar según la propuesta están basadas en los siguientes factores de calidad, tomados del modelo ISO 9126:

  • Funcionalidad.
  • Usabilidad.
  • Confiabilidad.
  • Facilidad de mantenimiento.
  • Facilidad de prueba.

Métricas para requerimientos.

El objetivo del flujo de trabajo requerimientos es establecer y mantener un acuerdo con los clientes acerca de lo que el software debe hacer.

Los requerimientos son condiciones o capacidades que debe alcanzar o poseer un sistema o componente para satisfacer un contrato, estándar u otro documento impuesto formalmente. Los requerimientos deben estar correctamente estructurados, completos y deben ser fáciles de aplicar.

Según el estándar IEEE 830, 1998 se considera que una especificación es de calidad si cumple con las siguientes características (Guevara, 2007):

  1. Especificación correcta: Un conjunto de requisitos es correcto sólo si todos los requisitos contenidos representan algo que es requerido para la construcción del sistema y no hay errores que afecten el diseño.
  2. Especificación no ambigua: Un requisito es no ambiguo si y sólo si puede estar sujeto a una única interpretación.
  3. Especificación completa: Si y sólo si, describe todos los requisitos relevantes para el usuario, incluyendo requisitos asociados con funcionalidad, desempeño, restricciones de diseño, atributos o interfaces externas.
  4. Especificación consistente: si y sólo si no hay ningún subconjunto de requisitos descrito dentro de ella que está en conflicto con cualquier otro.
  5. Especificación ordenada por importancia y/o estabilidad
  6. Especificación verificable: Se considera que una especificación es verificable si lo son cada uno de los requisitos constituyentes. Se considera que un requisito individual es verificable si existe un proceso acotado (en plazo y presupuesto) que permita determinar que el sistema construido satisface lo descrito en el propio requisito. La descripción detallada y prueba de los requisitos una vez implementados ayudan considerablemente en su verificación.
  7. Especificación modificable: Si su estructura es tal que permite realizar cambios sobre los requisitos que contiene de forma sencilla, completa y consistente, manteniendo la estructura inicial del conjunto.
  8. Especificación trazable: Una especificación es trazable si el origen de cada requisito individual está claro y existe algún mecanismo que permita seguir el impacto de dicho requisito a lo largo del resto de las actividades del ciclo productivo.

En este flujo de trabajo se aplicarán las métricas de entendimiento de los requerimientos, estabilidad de los requerimientos, especificidad de los requerimientos y grado de validación de los requerimientos, que brindarán información sobre la comprensibilidad y validez de los mismos.

1. Estabilidad de los requerimientos

Es necesario lograr una estabilidad en los requerimientos para el correcto funcionamiento de los demás flujos de trabajo. El objetivo de esta métrica es medir la estabilidad de los requerimientos para asegurar su adecuación antes de pasar al próximo flujo de trabajo. Se considera que los requerimientos son estables cuando no existen adiciones o supresiones en ellos que impliquen modificaciones en las funcionalidades principales de la aplicación. La estabilidad de los requerimientos se calcula como:

pag5.gif

Donde:

  • ETR: valor de la estabilidad de los requerimientos.
  • RT: total de requerimientos definidos.
  • RM: número de requerimientos modificados, que se obtienen como la sumatoria de los requerimientos insertados, modificados y eliminados.

Esta métrica ofrece valores entre 0 y 100. El mejor valor de ETR es el más cercano a 100 porque mostrará que no se están realizando cambios sobre los requerimientos, son estables y por tanto es confiable trabajar el análisis y diseño sobre ellos.

2. Especificidad de los requerimientos

La comprensibilidad de los requerimientos depende en gran medida de la ausencia de ambigüedades en su especificación, facilitando los procesos de captura y procesamiento de requerimientos. El objetivo de esta métrica es cuantificar la especificidad o falta de ambigüedad en la definición de los requerimientos. Para calcular esta métrica deben contarse los requerimientos que tuvieron igual interpretación por los revisores y compararlos con el total de requerimientos definidos. La especificidad de los requerimientos se calcula como:

pag6-1.gif

Donde:

  • ER: grado de especificidad de los requerimientos.
  • nui: número de requerimientos para los que todos los revisores tuvieron interpretaciones idénticas.
  • nr: cantidad de requerimientos en una especificación y comprende la suma de los requisitos funcionales y no funcionales.

El valor de esta métrica debe estar siempre entre 0 y 1. Mientras más cerca de 1 esté el valor de ER mayor será la consistencia de la interpretación de los revisores para cada requerimiento y menor será la ambigüedad en la especificación de los requerimientos.

3. Grado de validación de los requerimientos

Los requerimientos deben ser posibles de validar. La validación de los requerimientos se realiza en consenso del equipo de desarrollo al contrastar lo que desea el cliente con la posibilidad real de implementarlo. El grado de validación de los requerimientos mide la corrección en la definición de los requerimientos. Este valor se calcula como:

pag6-2.gif

Donde:

  • VR: grado de validación de los requerimientos.
  • nc: número de requerimientos que se han validado como correctos.
  • nnv: número de requisitos no validados aún.

El resultado de esta métrica está siempre entre 0 y 1. El valor óptimo de esta métrica es el más cercano a 1 e indica un alto nivel de corrección en la definición de los requerimientos.

Métricas para análisis y diseño.

Los objetivos del análisis y diseño de la aplicación consisten en transformar los requerimientos en el sistema a implementar, desarrollar una arquitectura robusta para el sistema y adaptar el diseño al entorno de implementación, diseñándolo para su desempeño. El análisis se centra fundamentalmente en la modelación de los requerimientos funcionales para su implementación en el sistema, mientras que el diseño asegura que se cumplan en la aplicación los requerimientos no funcionales.

Durante el análisis y diseño se aplicarán los puntos de función para estimar el tamaño del software como base para métricas a aplicar en próximas fases del desarrollo del software; la métrica de flujo de información, que ofrece una medida de la complejidad del diseño del modelo de datos y la complejidad ciclomática de McCabe se utiliza como medida de la facilidad de mantenimiento y pruebas del software.

1. Puntos de función

Una métrica de eficiencia conocida y ampliamente utilizada es la métrica basada en puntos de función, que se basa en pesos. Para calcular esta métrica primero se deben obtener las siguientes medidas:

  • Número de entradas del usuario: Número de entradas que el usuario proporciona al software. Cada pantalla de entrada de datos debe contarse como una, excepto en el caso de pantallas divididas en las que se da información para varias características distintas de la función. Representa la habilidad de controlar y mantener el procesamiento de datos.
  • Número de salidas del usuario: Número de salidas que proporcionan información al usuario. Igual al punto anterior, se cuenta cada salida completa que tenga una unidad lógica de información. Representa la salida de información de la aplicación al usuario.
  • Número de archivos lógicos internos: Número de colecciones lógicas de datos mantenidas desde la aplicación.
  • Número de archivos de interfaz externa: Número de colecciones lógicas de datos mantenidas fuera de la aplicación, pero referenciadas por ella.
  • Número de consultas del usuario: Número de elementos que el usuario puede solicitar a la aplicación.

Las Tablas 1, 2 y 3 indican como asignar la complejidad de las medidas descritas anteriormente.

Tabla 1. Evaluación de complejidad de las entradas del usuario. (Tomado de Manual de Cálculo de Puntos de Función de la IPFUG, versión 4.1)

Número de archivos actualizados o referenciados

Número de entradas

1-4

5-15

>15

0-1

Baja

Baja

Media

2

Baja

Media

Alta

3 ó más

Media

Alta

Alta

Tabla 2. Evaluación de la complejidad de las salidas y las consultas del usuario. (Tomado de Manual de Cálculo de Puntos de Función de la IPFUG, versión 4.1)

Número de archivos actualizados o referenciados

Número de salidas o consultas del usuario

1-5

6-19

>19

0-1

Baja

Baja

Media

2-3

Baja

Media

Alta

>3

Media

Alta

Alta

Tabla 3. Evaluación de la complejidad de los archivos lógicos internos y de los archivos de interfaz externa. (Tomado de Manual de Cálculo de Puntos de Función de la IPFUG, versión 4.1)

Tipos de elementos de registro

Número de archivos internos lógicos y de interfaz externa

1-19

20-50

>50

1

Baja

Baja

Media

2-5

Baja

Media

Alta

>5

Media

Alta

Alta

A cada una de las medidas anteriores se le asignan tres posibles pesos: simple, medio o complejo, dependiendo de la complejidad de entrada. Cada uno de los valores obtenidos se multiplica por el peso de acuerdo la complejidad del factor, según se muestra en la Tabla 3. Se obtiene la suma de todas las entradas por sus pesos, dando así un total de cuenta.

Tabla 4. Factores de peso de las medidas en caso de los límites de complejidad superiores e inferiores. (Tomado de Manual de Cálculo de Puntos de Función de la IPFUG, versión 4.1)

Medida

Complejidad baja

Complejidad media

Complejidad alta

Número de entradas del usuario

3

4

6

Número de salidas del usuario

4

5

7

Número de archivos lógicos internos

3

4

6

Número de archivos de interfaz externa

7

10

15

Número de consultas externas

5

7

10

Dados los factores de peso y los valores de cada medida, se calcula los puntos de función sin ajustar según la fórmula:

pag9.gif

Donde:

  • wij: factores de peso de los 5 componentes por nivel de complejidad (alto, medio, bajo).
  • xij: valores de cada componente en la aplicación.

Las características del software que deben tenerse en cuenta para evaluar esta métrica son: la comunicación de los datos, las funciones distribuidas, el desempeño del programa, la configuración utilizada en exceso, la tasa de transacción, la entrada de datos en línea, la eficiencia para el usuario final, la actualización en línea, la complejidad de procesamiento, la reusabilidad, la facilidad de instalación, la facilidad de operación, la existencia de sitios múltiples y la facilidad de cambios. La descripción de estas características se muestra en la Tabla 5.

Tabla 5. Características del software a evaluar para calcular los puntos de función. (Elaborado por la autora)

Característica

Descripción

1. Comunicación de los datos

¿Qué influencia tendrán los medios de comunicación que se necesitará para la transacción de datos entre la aplicación y otros sistemas?

2. Procesamiento distribuido

¿Cómo se manipulan los datos y las funciones distribuidas?

3. Desempeño

¿Es requerido por el usuario un tiempo de respuesta determinado?

4. Configuración utilizada en exceso

¿Cuán dependiente es la aplicación de la plataforma de hardware sobre la que se ejecuta?

5. Tasa de transacción

¿Cuál es la frecuencia de ejecución de las transacciones en la aplicación?

6. Entrada de datos en línea

¿Qué porcentaje de la información se introduce en línea?

7. Eficiencia para el usuario

¿La aplicación fue diseñada con para proveer la máxima eficiencia al usuario final?

8. Actualización en línea

¿Cuántos archivos internos se actualizan mediante transacciones en línea?

9. Procesamiento complejo

¿La aplicación tiene procesamiento lógico o matemático complejo?

10. Reusabilidad

¿El código del sistema puede utilizarse en otras aplicaciones?

11. Facilidad de instalación

¿Cuánta dificultad implica la instalación y la adaptación a diferentes plataformas de software?

12. Facilidad de operación

¿Es intuitivo el uso de la aplicación para el usuario final?

13. Sitios múltiples

¿Es posible utilizar la aplicación en diferentes organizaciones con cambios mínimos?

14. Facilidad de cambios

¿Es fácil realizar cambios sobre la aplicación?

Los valores de ajuste de complejidad son obtenidos de la asignación de pesos, donde se otorga un puntaje de 0 a 5 a las características del sistema mencionadas anteriormente. Estos valores se evalúan de acuerdo a la Tabla 6.

Tabla 6. Valores de ajuste de complejidad. (Elaborado por la autora)

Valor

Evaluación

0

Sin influencia

1

Incidental

2

Moderado

3

Medio

4

Significativo

5

Esencial

El factor de ajuste del valor (FAV) indica la funcionalidad general que la aplicación provee al usuario final. Además permite ajustar los puntos de función con una aproximación de +/- 35%:

pag11-1.gif

Donde:

  • ci: puntuación para las características generales del sistema.

Por último, el valor de los puntos de función ajustados se obtiene multiplicando la suma de funciones y el factor de ajuste de valores:

pag11-2.gif

Una eficiencia alta corresponde a la obtención del producto en el menor tiempo, con la menor cantidad de recursos, con la mejor precisión y con la mayor cantidad de beneficio. Esta métrica ofrece una estimación del tamaño del software basado en su funcionalidad por tanto es recomendable para lograr una alta eficiencia que su valor sea tan alto como es posible.

2. Flujo de información

Permite valorar programas basados en datos y ofrece la ventaja de calcularse antes de realizar la implementación. Aunque puede dar valores de complejidad cero cuando el programa no tiene interacciones externas, lo cual sería incorrecto porque la complejidad siempre es mayor que 1, por esta razón es aconsejable combinar esta métrica con la de complejidad ciclomática de McCabe y los puntos de función. La complejidad del flujo de información se calcula como:

pag12-1.gif

Donde:

  • fanin: número de flujos hacia un procedimiento + número de estructuras de datos globales de las cuales el procedimiento obtiene información.
  • fanout: número de flujos desde un procedimiento + número de estructuras de datos globales que el procedimiento actualiza.

Los módulos del programa que tienen un alto valor de fanin son relativamente pequeños y simples; al contrario de aquellos cuyo valor de fanin es bajo que tienden a ser grandes y complejos.

3. Complejidad ciclomática

Dado el grafo de control de flujo (G) de cualquier programa, cada nodo corresponde a un bloque de código secuencial y cada arco a una bifurcación o punto de decisión en el programa. La complejidad ciclomática de G se calcula como:

pag12-2.gif

Donde:

  • a: número de aristas del grafo G.
  • n: número de nodos del grafo G.

La complejidad ciclomática de un programa con múltiples salidas se define como:

pag12-3.gif

Donde:

  • R: número de declaraciones “return” o nodos terminados del programa.

Esta complejidad también puede calcularse como:

pag12-4.gif

La complejidad ciclomática del software debe ser siempre menor que 10. El valor de esta métrica es el límite superior del número de casos de prueba necesarios para cubrir todas las bifurcaciones del programa y el límite inferior del

número de caminos básicos. Los módulos que tienen una mayor complejidad tienden a ser los menos confiables en el programa.

Métricas para implementación.

La implementación se empieza con el resultado del análisis y diseño para construir el sistema en términos de componentes. Los objetivos de la implementación son: definir la organización del código en términos de subsistemas de implementación organizados en capas, implementar los elementos de diseño en términos de elementos de implementación, hacer pruebas de unidad a los componentes desarrollados e integrar los resultados producidos por implementadores individuales o equipos en un sistema ejecutable.

Al finalizar la implementación del producto se aplicarán métricas para calcular el índice de funcionalidad del software, la métrica de éxito para evaluar el grado de completamiento en la realización de las funcionalidades de la aplicación y la cantidad de páginas de acceso rápido de la aplicación.

1. Índice de funcionalidad

La funcionalidad es una característica de alto nivel que representa la existencia de un grupo de funciones y comportamientos que satisfacen un conjunto específico de requerimientos. Para medir esta característica del software se tienen en cuenta los distintos tipos de archivos que forman parte de una aplicación web, que se describen en la Tabla 7.

Tabla 7. Tipos de archivos que se utilizan en una aplicación web. (Elaborado por la autora)

Tipo de archivo

Extensiones de archivo

Descripción

Estructurales

HTML, IHTML

En esta categoría se incluyen los archivos que describen lógicamente las interfaces de los objetos que componen una aplicación web.

Funcionales (servidor)

php, jsp, asp, pl, cgi

Estos son los archivos que implementan las funcionalidades de la aplicación web desde el lado del servidor.

Funcionales (cliente)

js, css, vs

Son archivos que implementan funcionalidades o apariencia de la aplicación web desde el lado del cliente.

Funcionales (incrustados)

class, swf, dir

Estos son archivos de funcionalidad externa que se visualizan mediante una funcionalidad agregada al navegador.

Imágenes

gif, jpg, bmp

Son archivos binarios de imágenes en varios formatos.

Documentos

pdf, ps, doc, xls, ppt, rtf

Este tipo de archivos, comprende los documentos que pueden ser desplegados o descargados de la aplicación web por el cliente mediante el navegador.

Esta métrica valora entre 0 y 1 la funcionalidad de un portal web mediante un conjunto de archivos, para el cálculo de la misma se considera el peso de los distintos tipos de archivos en kilobytes. El índice de funcionalidad se calcula como:

Donde:

  • IFtipo: índice funcional según el tipo de archivo funcional (servidor, cliente o incrustado).
  • PAFtipo: peso del tipo de archivo funcional.
  • PAE: peso de los archivos estructurales.

Para clasificar una aplicación web en funcional o no se debe calcular el Índice de Funcionalidad Neto (IFN) como una combinación lineal de los valores anteriores:

pag14-2.gif

El valor del IFN está siempre entre 0 y 1. Una aplicación web es funcional si 0.5 ≤ IFN ≤ 1.

2. Métrica de éxito

La usabilidad del software es una característica de alto nivel que se valora de acuerdo a factores humanos, la estética, consistencia y documentación general, es el esfuerzo necesario por el usuario para aprender, operar los datos de entrada e interpretar las salidas de un programa. La forma más simple de medir la usabilidad de un programa es el índice de éxito logrado al realizar una función específica. Esta métrica se basa en registrar el porcentaje de usuarios que lograron realizar exitosamente la prueba que se les solicitó. A cada funcionalidad se le asigna un peso según su estado de realización como se indica en la Tabla 8.

Tabla 8. Pesos de la realización de funcionalidades. (Elaborado por la autora)

Estado de realización de la funcionalidad

Peso

Funcionalidad no realizada

0

Funcionalidad a medio realizar

0.5

Funcionalidad realizada

1

La métrica de éxito se calcula como:

pag15.gif

Donde:

  • ME: valor de la métrica de éxito.
  • CFT: cantidad de funcionalidades terminadas.
  • CFM: cantidad de funcionalidades a medio terminar.
  • CTF: número total de funcionalidades.

Mientras mayor sea el valor de ME, mayor usabilidad tendrá la aplicación web. Esto implica una mayor aceptación por parte del usuario.

3. Páginas de acceso rápido

Las aplicaciones web deben permitir el despliegue rápido y sin dificultades técnicas de las páginas web y la visualización de las páginas de la misma forma en que fueron construidas y visualizadas por los desarrolladores. Esta métrica permite cuantificar la facilidad de navegación de la aplicación web. Para cumplir este objetivo se especifica un tamaño umbral aceptable al tamaño de cada página, en este caso se utiliza el de 35.2 Kb.

Las normas internacionales al respecto establecen que un usuario no esperará más de(Lafuente, 2000):

  • 5 segundos para que aparezca algo visible en la pantalla.
  • 10 segundos para que aparezca algo legible en la pantalla.
  • 30 segundos para hacer un clic hacia otra parte del sitio o hacia otro sitio.

Para calcular esta métrica es preciso medir el tamaño de todas las páginas estáticas de la aplicación considerando todos sus componentes gráficos, tabulares y textuales. El tamaño de cada página se especifica como una función del

tiempo de espera y de la velocidad mínima establecida para una línea de comunicación dada. La fórmula para esta métrica es:

pag16-1.gif

Donde:

  • Tdescarga: tiempo que demora una página en cargar en el navegador del usuario.
  • TPE: tamaño de la página estática.
  • VLC: velocidad de la línea de conexión.

Considerando como el tiempo máximo de descarga los 20 segundos, la página es de acceso rápido si el tiempo de descarga es menor que el tiempo máximo, y no lo es si ocurre el caso contrario.

Métricas para pruebas

Las pruebas al software se realizan con el objetivo de encontrar y documentar los defectos en la calidad del software, aconsejar en base a la calidad determinada, validar y probar las hipótesis hechas en el diseño y la especificación de requerimientos mediante una demostración concreta, validar que el producto trabaja de acuerdo a lo que fue diseñado y validar que los requerimientos están correctamente implementados.

Durante la etapa de pruebas se utilizarán la métrica de cobertura, madurez y profundidad de las pruebas, el porcentaje de defectos por tipo, la densidad de defectos, la métrica para el control de pruebas de unidad, la tasa de propagación de defectos, la métrica para pruebas de camino básico, el porcentaje de enlaces rotos de una aplicación web, el índice de madurez del software, la cantidad de nodos muertos de una aplicación web y el porcentaje de redundancia de imágenes.

1. Exhaustividad de las pruebas

a) Medida de amplitud o cobertura de las pruebas: Proporciona un indicador de cuantos requisitos se han probado del número total de ellos. Indica la compleción del plan de pruebas. La cobertura de las pruebas indica cómo se van cumpliendo los casos de prueba especificados, por tanto una mayor cobertura de las pruebas indica un buen desarrollo de las pruebas. La cobertura de las pruebas se calcula como:

pag-2.gif

Donde:

  • CP: valor de la cobertura de las pruebas.
  • CPE: número de casos de prueba que han sido ejecutados.
  • CPR: número de casos de prueba a ejecutar requeridos para cubrir todos los requerimientos.

El valor de CP debe estar entre 0 y 1. La cobertura de pruebas será más eficiente mientras más se acerque a 1, esto implica que se están ejecutando la mayor cantidad de casos de prueba de los que se propusieron en el plan de pruebas.

b) Profundidad de las pruebas: Porcentaje de los caminos básicos independientes probados en relación al total de ellos sumando la complejidad ciclomática de todos los módulos del programa. La métrica para pruebas del camino básico se calcula como:

pag17-1.gif

Donde:

  • PCB: porcentaje de caminos básicos.
  • P: número de pruebas diseñadas.
  • : complejidad ciclomática calculada anteriormente.

Si el valor de PCB no está cerca del 100%, entonces el número de pruebas diseñadas no es suficiente para asegurar que se ejecutan todas las sentencias del programa.

c) Madurez de las pruebas: Indicador del buen desempeño del flujo de trabajo de pruebas, no sólo se enfoca en la completitud de los casos de prueba según los definidos para cubrir los requerimientos, sino que también comprende los casos de pruebas que han obtenido resultados satisfactorios. Para obtener esta métrica es preciso registrar los casos de prueba que obtuvieron resultados satisfactorios y el total de los casos de prueba definidos para el cumplimiento de los requerimientos. La madurez de las pruebas se calcula como:

pag17-2.gif

Donde:

  • MP: valor de la madurez de las pruebas.
  • CPS: número de casos de prueba que han dado resultados satisfactorios.
  • CPR: número de casos de prueba diseñados para cubrir todos los requerimientos.

El valor de esta métrica debe estar entre 0 y 1. Mientras mayor sea el número de casos de prueba que han obtenido un resultado satisfactorio de los casos realmente ejecutados y que se requieren para cubrir los requerimientos, mayor será la madurez alcanzada por el equipo de probadores del software, lo ideal es un valor tan cercano a 1 como sea posible.

d) Perfiles de fallos: Se emplean para categorizar y priorizar los errores. La prioridad indica la severidad del problema. Las categorías de fallos proporcionan una descripción del error para realizar análisis estadísticos de errores. El porcentaje de defectos por tipo permite categorizar los fallos porque identifica los tipos de defectos más comunes que puedan presentarse en cualquier etapa del desarrollo del software. El porcentaje de defectos por tipo se calcula como:

pag18-1.gif

Donde:

  • %DT: porcentaje de defectos por tipo.
  • NDT: es el número de defectos por tipo.
  • TDI: número total de defectos identificados en una etapa del proyecto.

El valor del %DT indica la frecuencia de aparición del error analizado, por tanto mientras mayor sea su valor más frecuente será la aparición de ese error específico.

2. Densidad de defectos

La densidad de defectos ofrece una medida sobre la proporción de defectos con respecto a la cantidad de elementos de especificación. Esta métrica permite realizar análisis estadísticos al finalizar las pruebas para valorar la integridad y madurez del software analizado. La densidad de defectos se calcula como:

pag18-2.gif

Donde:

  • DD: densidad de defectos.
  • TD: número total de defectos encontrados durante las pruebas.
  • CER: número de elementos de especificación revisados.

Es recomendable para una alta calidad del software que la densidad de defectos tenga un valor mínimo.

3. Métrica para el control de pruebas de unidad

Las pruebas de unidad son aquellas pruebas individuales, que se realizan durante la implementación, en las cuales se prueban los componentes antes de enviarlos para integrarlos, compilarlos, enlazarlos con uno o más ejecutables y realizar las comprobaciones del sistema.

La métrica para el control de pruebas de unidad ofrece una medida de los componentes que se han probado individualmente antes de la integración con respecto al total de componentes que fueron implementados. La métrica para el control de pruebas de unidad se calcula como:

pag19-1.gif

Donde:

  • CPU: valor de la métrica para el control de pruebas de unidad.
  • NCP: número de componentes probados individualmente antes de integrarlos.
  • CImp: número de componentes implementados.

Esta métrica ofrece valores entre 0 y 1. Si CPU = 1 significa que todos los componentes implementados fueron probados individualmente antes de la integración.

4. Tasa de propagación de defectos

La corrección de defectos en el software puede originar nuevos defectos, este fenómeno es conocido como propagación de defectos. La tasa de propagación de defectos indica el comportamiento de la propagación de defectos en la realización de las pruebas. La tasa de propagación de defectos se calcula como:

pag19-2.gif

Donde:

  • Dn: número de defectos ocasionados al corregir defectos anteriores.
  • Dc: número de defectos corregidos.

El valor de TPD ofrece mejores resultados cuando está más cerca de 1. Al calcular esta métrica pueden obtenerse valores negativos, cuando el número de defectos ocasionados al corregir defectos es mayor que el número de defectos corregidos, en este caso dichos valores no se tendrán en cuenta al trabajar con el resultado de la métrica, sino que se considerarán como cero.

5. Índice de Madurez del Software

El Índice de Madurez del Software (IMS), propuesto por el estándar IEEE 982.1-1988, proporciona un indicador de la estabilidad del software basado en los cambios que ocurren en cada versión del producto, este es un indicador de la facilidad de mantenimiento del software. El IMS se calcula como:

pag20.gif

Donde:

  • IMS: índice de madurez del software.
  • Mt: número de módulos en la versión actual.
  • Fc: número de módulos en la versión actual que han sido modificados.
  • Fa: número de módulos en la versión actual que han sido añadidos.
  • Fe: número de módulos en la versión actual que han sido eliminados.

El valor del IMS está siempre entre 0 y 1. Mientras más cerca esté el valor del IMS de 1, más estable será el producto software.

Conclusiones

  • Se definió una guía de métricas a aplicar durante cada fase del desarrollo del SIG-UCI para evaluar su avance y calidad durante el ciclo de desarrollo, en ella se incluyen las métricas de estabilidad, especificidad y grado de validación de los requerimientos, puntos de función, flujo de información y complejidad ciclomática para análisis y diseño, índice de funcionalidad, métrica de éxito y cantidad de páginas de acceso rápido para la implementación, métricas de exhaustividad de las pruebas y control de pruebas de unidad, entre otras para la etapa de pruebas.
  • Se detectaron varios problemas en el producto como una pobre documentación que dificulta el trabajo de recolección de las medidas, incorrecto diseño de varios módulos de la aplicación debido a una desacertada distribución de responsabilidades entre ellos y otros.
  • Las recomendaciones para la solución de los problemas detectados fueron transmitidas al equipo de desarrollo para ser efectuadas en próximas iteraciones.
  • La efectividad de la guía se demostró mediante la cantidad de problemas detectados y la posibilidad de informar al equipo de desarrollo.

Referencias

  • Gil Morell, Melchor. 2003. Carta del Rector de la Universidad de Ciencias Informáticas (UCI). Portal de la Universidad de Ciencias Informáticas. [Online] 2003. [Cited: 05 22, 2009.] .
  • Guevara, Bedsy. 2007. Procedimiento Propuesto para medir la Calidad en. Biblioteca UCI. [Online] 07 2007. [Cited: 02 16, 2009.] . MIS-006086.
  • Pressman, Roger S. 2005. Ingeniería del Software. Un enfoque prático. Ciudad de La Habana : Félix Varela, 2005.

Notas

Divulgar este artículo:

Puedes reproducir este artículo en otras publicaciones electrónicas o impresas en tanto incluyas: 1) Los datos de los autores correspondientes y; 2) Su fuente en Revista Vinculando, con la dirección electrónica (URL) de esta página.

 


Si te gustó este artículo, suscríbete gratis:

Suscríbete a nuestra revista hoy mismo.

 

Importante: Recuerda responder el correo de confirmación que te va a llegar en unos minutos para activar tu suscripción!

Más de 23,900 suscriptores.
¡No te quedes fuera!

P.D. Tu suscripción es segura y puedes cancelarla en cualquier momento.