MÉTRICAS DEL MODELO DE ANÁLISIS
En esta fase es deseable que las métricas técnicas proporcionen una visión interna a la calidad del modelo de análisis. Estas métricas examinan el modelo de análisis con la intención de predecir el “tamaño” del sistema resultante; es probable que el tamaño y la complejidad del diseño estén directamente relacionados.
MÉTRICAS BASADAS EN LA FUNCIÓN
La métrica del punto de función (PF) se puede utilizar como medio para predecir el tamaño de un sistema obtenido a partir de un modelo de análisis. Para visualizar esta métrica se utiliza un diagrama de flujo de datos, el cual se evaluar para determinar las siguientes medidas clave que son necesarias para el cálculo de la métrica de punto de función:
• Número de entradas del usuario • Número de salidas del usuario • Número de consultas del usuario • Número de archivos • Número de interfaces externas
La cuenta total debe ajustarse utilizando la siguiente ecuación:
PF = cuenta-total x (0,65 + 0,01 x åFi)
Donde cuenta-total es la suma de todas las entradas PF obtenidas de la figura 9.2 y Fi (i=1 a 14) son los “valores de ajuste de complejidad”.
Para el ejemplo descrito en la figura 9.2 se asume que la åFi es 46 (un producto moderadamente complejo), por consiguiente:
PF = 50 x (0,65 + 0,01 x 46) = 56 Factor de ponderación
Parámetro de medición Cuenta Simple Media Compl. Número de entradas del usuario 3 X 3 4 6 = 9 Número de salidas del usuario 2 X 4 5 7 = 8 Número de consultas del usuario 2 X 3 4 6 = 6 Número de archivos 1 X 7 10 15 = 7 Número de interfaces externas 4 X 5 7 10 = 20 Cuenta total 50
Basándose en el valor previsto del PF obtenido del modelo de análisis, el equipo del proyecto puede estimar el tamaño global de implementación de las funciones de interacción. Asuma que los datos de los que se dispone indican que un PF supone 60 líneas de código (se utilizará un lenguaje orientado a objetos) y que en un esfuerzo de un mes-persona se producen 12 PF. Estos datos históricos proporcionan al gestor del proyecto una importante información de planificación basada en el modelo de análisis en lugar de estimaciones preliminares
Métricas de la Calidad de Especificación
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 habilidad, capacidad de modificación, exactitud y capacidad de reutilización. Aunque muchas de las características anteriores pueden ser de naturaleza cuantitativa, Davis [Pressman‘98] sugiere que todas puedan representarse usando una o más métricas. Por ejemplo asumimos que hay ni requisitos en una especificación, tal como ni = nf + nnf (4.8) Donde nf es el número de requisitos funcionales y nnf es el número de requisitos no funcionales (por ejemplo, rendimiento).Para determinar la especificidad de los requisitos, Davis [Pressman ‘98] sugiere una métrica basada en la consistencia de la interpretación de los revisores para cada requisito: Q1 = nui / nr (4.9) Donde nui es el número de requisitos para los que todos los revisores tuvieron interpretaciones idénticas. Cuanto más cerca de uno este el valor de Q1 menor será la ambigüedad de la especificación. La compleción de los requisitos funcionales puede terminarse calculando la relación Q2 = nu / (ni * ns) (4.10) 82 donde nu es el número de requisitos de función únicos, ni es el número de entradas (estímulos) definidos o implicados por la especificación y ns es el número de estados especificados. La relación Q2 mide porcentaje de funciones necesarias que se han especificado para un sistema, sin embargo, no trata los requisitos no funciónales. Para incorporarlos a una métrica global completa, debemos considerar el grado de validación de los requisitos: Q3 = nc / (nc + nnv) (4.11) donde nc es el número de requisitos que se han validados como correctos y nnv el número de requisitos que no se han validado todavía
REVISIONES TECNICAS FORMALES
Objetivos: descubrir errores en la función, lógica o implementación de cualquier representación del software. Verificar el cumplimiento de los requisitos Garantizar el cumplimiento de los estándares. Conseguir un desarrollo uniforme del software Obtener proyectos que hagan más sencillo los trabajos técnicos (análisis que permitan buenos diseños, diseños que permitan implementaciones sencillas, estrategias de pruebas que faciliten éstas,…)
RTFs: son un filtro que permite “purificar” las actividades de ingeniería de software. se aplican en diversos momentos del desarrollo para detectar defectos. Diseño: entre el 50 y el 60% de los errores del desarrollo. Aprovecha la diversidad de un grupo de personas para: señalar la necesidad de mejoras en el producto de ingeniería (diagramas del análisis, diccionario de datos, diseño, código, estrategia de pruebas,…) Confirmar las partes en las que no es necesaria una mejora. Conseguir un trabajo técnico de calidad más uniforme. Efectividad: se calcula que son efectivas en un 75%.
Técnicas
“Estáticas: análisis y chequeo de documentos de requisitos, diagramas de diseño, código fuente, etc.
“dinámicas: pruebas sobre implementación real (sólo pueden Usarse cuando ya se tiene código ejecutable).
Revisiones Técnicas Formales
Se eliminan errores en forma relativamente temprana (barato y fácil de corregir)
Cada revisión se conduce en forma de una reunión cuidadosamente planeada y controlada
La reunión de revisión
Entre 3 y 5 personas (grupo pequeño) Preparación previa (2 horas por persona) Especificación precisa (formal o informal)
Estándares de codificación
Duración máxima 2 horas (lento pero cansado) Foco en un segmento específico Participan los revisores y el productor
Directrices para la revisión
Revisar el producto y no al productor Indicar los errores con tino, tono constructivo Mantenerse estrictamente dentro de la agenda No irse por las ramas Limitar el debate Algunos asuntos pueden dejarse para discusión posterior Enunciar problemas no resolverlos Problema debería ser resuelto por el productor Tomar notas (pizarra deseable)
