Plan De Pruebas

Introducción

Las métricas se realizan con el fin de calcular características y elementos esenciales en un sistema ya sea a través de los requerimientos funcionales y no funcionales, diagrama de casos de usos, diagrama de estructura, entre otros. Al desarrollar dichas métricas, se puede obtener información sobre el tamaño del sistema, así como la complejidad del mismo, según el tipo de métrica que se aplique al producto.

El presente trabajo se realizo a través de fundamentos teóricos que permitieron el cálculo de las métricas para el sistema del Consejo Comunal “Josefa Camejo”, a fin de hallar el tamaño, complejidad, grado de validación, especificidad, entre otros de dicho sistema.

Por razones antes expresadas, el equipo encargado de la investigación enfocara el tema en este caso hacia algunas métricas; recordemos que para este caso solo se medirán las métricas cuantitativas ya que estas se pueden medir directamente.

El siguiente trabajo quedo estructurado de la siguiente manera: en primera instancia el cálculo de las métricas de punto de función (PF), métricas de la calidad de la especificación, métricas de la calidad de diseño arquitectónico, métricas de la calidad de diseño de interfaz y por último las métricas de calidad del código fuente.

Métrica de Punto de Función (PF)

Es un método utilizado en ingeniería del software para medir el tamaño del software. Fue definida por Allan Albrecht, de IBM, en 1979 y pretende medir la funcionalidad entregada al usuario independientemente de la tecnología utilizada para la construcción y explotación del software, y también ser útil en cualquiera de las fases de vida del software, desde el diseño inicial hasta la implementación y mantenimiento.

Crítica

La crítica principal que recibe esta métrica es la de requerir una dedicación adicional en los proyectos de desarrollo de software, que suelen desenvolverse con presupuestos ajustados. Su implantación en una organización no acostumbrada a su uso suele resultar penosa y requerir un fuerte compromiso de la dirección. Suele ser vista por los desarrolladores como un mecanismo de control de su trabajo.

Otros aspectos negativos serían:

• Resulta arduo formar al personal en su utilización y más todavía mantener unos criterios homogéneos de recuento.

• Carece de precisión cuando se trata de proyectos pequeños. Por debajo de unos 100 PF resulta poco confiable.

Para resultar realmente útil, una organización de desarrollo y mantenimiento de software debe tener recontada la mayor parte de su base instalada, pero hacerlo resulta muy costoso especialmente si mantiene software adquirido a terceros.

• El factor de ajuste calculado a partir de las características generales del sistema resulta de dudosa utilidad.

Calculo

Para el cálculo de los puntos de función se determinan cinco características de dominios de información y se proporcionan las cuentas en la posición apropiada de la tabla. Los valores de los dominios de información se definen de la forma siguiente:

• Número de entradas de usuario: Se cuenta cada entrada de usuario que proporciona diferentes datos orientados a la aplicación. Las entradas se deberían diferenciar de las peticiones, las cuales se cuentan de forma separada.

• Número de salidas de usuario: Se cuenta cada salida que proporciona al usuario información orientada a la aplicación. En este contexto la salida se refiere a informes, pantallas, mensajes de error, etc. Los elementos de datos particulares dentro de un informe no se cuentan de forma separada.

• Número de consultas de usuario: Una petición se define como una entrada interactiva que produce la generación de alguna respuesta del software inmediata en forma de salida interactiva. Se cuenta cada petición por separado.

• Número de archivos: Se cuenta cada archivo maestro lógico (esto es, un grupo lógico de datos que puede ser una parte de una gran base de datos o un archivo independiente).

• Número de interfaces externas: Se cuentan todas las interfaces legibles por la máquina (por ejemplo: archivos de datos de cinta o disco) que se utilizan para transmitir información a otro sistema.

Una vez que se han recopilado los datos anteriores, a la cuenta se asocia un valor de complejidad. Las organizaciones que utilizan métodos de puntos de función desarrollan criterios para determinar si una entrada en particular es simple, media o compleja. No obstante la determinación de la complejidad es algo subjetiva.

A continuación se muestra el cálculo de la métrica de punto de función (PF), para el sistema del consejo comunal Josefa Camejo, en este caso se realizara con el Diagrama de Caso de Uso para la cual tomamos al actor Presidente de la Unidad Ejecutiva.

Factor de ponderación

Parámetro de medición Cuenta Simple Medio Complejo

Número de entradas del usuario 7 = 3 4 6 = 21

Número de salidas del usuario 6 = 4 5 7 = 24

Número de consultas del usuario 6 = 3 4 6 = 18

Número de Archivos 1 = 7 10 15 = 7

Número de Interfaces externas 9 = 5 7 20 = 45

Cuenta = Total

115

Para el calcular el PF, se utiliza la siguiente relación:

PF = Cuenta_Total*(0,65+0,01*∑Fi)

PF = 115*(0,65+0,01*54)

PF = 137

El Valor de Ajuste de Complejidad - Fi - es la sumatoria de cada uno de los valores de ajuste por el grado de influencia:

Grado de influencia de la complejidad:

0 No influencia

1 Incidencia

2 Moderado

3 Medio

4 Significativo

5 Esencial

Fi - Valores de ajuste de complejidad

N° Ítems Valor

1 ¿Requiere el sistema copias de seguridad y de recuperación fiable? 5

2 ¿Se requiere comunicación de datos? 4

3 ¿Existen funciones de procesamiento distribuido? 3

4 ¿Es crítico el rendimiento? 5

5 ¿Se ejecutará el sistema en un entorno operativo existente y fuertemente utilizado? 5

6 ¿Requiere el sistema entrada de datos interactivo? 5

7 ¿Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre múltiples pantallas u operaciones? 3

8 ¿Se actualizan los archivos maestros en forma interactiva? 4

9 ¿Son complejas las entradas, las salidas, los archivos o las peticiones? 2

10 ¿Es complejo el procesamiento interno? 1

11 ¿Se ha diseñado el código para ser reutilizable? 5

12 Están incluida en el diseño la conversión y la instalación? 2

13 Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones? 5

14 ¿Se ha diseñado la aplicación para facilitar los cambios y para ser fácilmente utilizados por el usuario? 5

∑(Fi)=

54

Asumimos que los datos que se disponen indican que un PF supone 137 líneas de código. Estos datos históricos proporcionan al gestor del proyecto una importante información de planificación basada en el modelo de análisis en el lugar de estimación preliminares.

Métrica de la Calidad de la Especificación

Davis y sus colegas proponen una lista de características que pueden emplearse para valorar la calidad del modelo de análisis y la correspondiente especificación de requisitos: Especificidad (ausencia de ambigüedad, corrección, compleción, comprensión, capacidad de verificación, consistencia externa e interna, capacidad de logro, concisión, traza habilidad, capacidad de modificación, exactitud y capacidad de reutilización. Además apuntan que las especificaciones de alta calidad deben estar almacenadas electrónicamente, ser ejecutables o al menos interpretables, anotadas por importancia y estabilidad relativas, con su versión correspondiente, organizadas, con referencias cruzadas y especificadas al nivel correcto de detalle.

En esta métrica se evalúan los siguientes aspectos:

• Valoración del modelo con la especificación de requisitos (completitud, consistencia, ambigüedad, comprensión, etc.).

• Se plantea una fórmula para cada uno de los atributos de la especificación, incluyendo requisitos Funcionales y no funcionales, interpretación, etc.).

Nomenclatura

nr – número requisitos en una especificación

nf – número de requisitos funcionales

rnf – número de requisitos no funcionales (rendimiento)

Asociados a la ecuación nr = nf + rnf

Especificidad – Q1 = nui / nr, siendo nui son los requisitos donde coinciden las revisiones.

Compleción – Q2 = nu / (ni*ns) Este es el porcentaje de funciones necesarias con base en las especificaciones del sistema.

nu– requisitos funcionales únicos

ni – número de entradas

ns – número de estados especificados

Grado de validación – Q3 = nc / (nc + nnv)

nc – número de requisitos considerados validos

nnv– número de requisitos no validos

Existe una lista de características para poder valorar la calidad del modelo de análisis y la correspondiente especificación de requisitos: Especificidad, corrección, compleción, comprensión, capacidad de verificación, consistencia externa e interna, capacidad de logro, concisión, traza

...