Unidad IV Métricas para la evaluación del análisis

 

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

4.1.1 Métricas basadas en la Función.

La métrica de punto de función (PF) se puede usar como medio para predecir el tamaño de un sistema que se va a obtener de un modelo de análisis.

 

_Utilizada para medir el tamaño del sistema a construir.

_Se calcula: el no. de entradas del U, de salidas del U, de peticiones al U, de archivos, y de interfaces externas, asociados a un no. de complejidad (simple, medio, complejo), más un factor de complejidad.

_Se aplica en forma anádesdeloga a las LDC.

 

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

 

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.

 

4.1.2 Métrica Bang.

Puede aplicarse para desarrollar una indicación del tamaño del software a implementar como consecuencia del modelo del análisis. La métrica bang es “una indicación, independiente de la implementación, del tamaño del sistema” [Ejiogo ‰].

Para calcular la métrica bang, el desarrollador de software debe evaluar primero un conjunto de primitivas (elementos del modelo de análisis que no se subdividen más en el nivel de análisis). Estas ayudan a evaluar el análisis y diseño, proporcionan medidas de la complejidad, y ayudan a diseñar pruebas más efectivas. Estas métricas se dividen en: Medidas del análisis, medidas de especificación, medidas de diseño.

Las primitivas se determinan evaluando el modelo de análisis y desarrollando cuentas para los siguientes elementos:

- Primitivas funcionales (Pfu) Transformaciones (burbujas) que aparecen en el nivel inferior de un diagrama de flujo de datos.

- Elementos de datos (ED) Los atributos de un objeto de datos, los elementos de datos no compuestos y aparecen en el diccionario de datos.

- Objetos (OB) Objetos de datos.

- Relaciones (RE) Las conexiones entre objetos de datos.

- Transiciones (TR) El número de transacciones de estado en el diagrama de transición de estado.

4.1.3 Métricas de la calidad de la 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. En estas métricas se emplea una lista de características que pueden emplearse para valorar la calidad del modelo de análisis y la correspondiente especificación de requisitos

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

Donde nui es el numero 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 pueden terminarse calculando la relación

 

Q2 = nu / (ni * ns)

 

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)

 

donde nc es el número de requisitos que se han validados como correctos y en el

número de requisitos que no se han validado todavía.

 

4.2 Revisiones Técnicas Formales.

Una revisión técnica formal (RTF) es una actividad de garantía de calidad del software llevada a cabo por los ingenieros del software (y otros). Los objetivos de la RTF son:

(1)    Descubrir errores en la función, la lógica o la implementación de cualquier representación del software.

 

(2)    Verificar que el software bajo revisión alcanza sus requisitos.

 

 

(3)    Garantizar que el software ha sido representado de acuerdo con ciertos estándares predefinidos.

 

(4)    Conseguir un software desarrollado de forma uniforme.

 

(5)    Hacer que los proyectos sean más manejables.

 

Ventajas de las revisiones técnicas:

 

•         Reduce sustancialmente el coste del software.

•         Tiene gran valor educativo para los participantes.

•         Sirve para comunicar la información técnica.

•         Fomenta la seguridad y la continuidad.

 

La RTF es realmente una clase de revisión que incluye recorridos, inspecciones, revisiones cíclicas y otro pequeño grupo de evaluaciones técnicas del software. Cada RTF se lleva a cabo mediante una reunión y sólo tendrá éxito si es bien planificada, controlada y atendida.

También sirve como campo de entrenamiento para que el personal más joven pueda observar los diferentes enfoques al análisis, diseño e implementación de los sistemas. EL RTF Sirve para promover la seguridad y continuidad, ya que varias personas se familiarizarán con partes del sistema de información, que de otro modo, no hubieran visto. Es una clase de revisión que incluye recorridos, inspecciones, torneo de revisiones y otras tareas de revisión técnica de los sistemas. Cada RTF se lleva a cabo mediante una reunión y sólo tendrá éxito si es bien planificada, controlada y atendida.

Proceso:

1.    El productor informa al jefe de proyecto la terminación del producto.

2.    Jefe de proyecto contacta el jefe de revisión.

3.    Revisores y jefe de revisión revisan el producto.

4.    La reunión revisión es llevada a cabo por el jefe de revisión, los revisores y el productor.

5.    Al final todos los participantes deben decidir si:

              I.        Aceptan el producto sin posteriores modificaciones.

            II.        Rechazan el producto por errores.

           III.        Aceptan el producto provisionalmente.

6.    Una vez tomada una decisión, todos firman.

 

4.2.1 Reunión de revisión.

Independientemente del formato que se elija para la RTF, cualquier reunión de revisión debe acogerse a las siguientes restricciones:

 

 

·         Deben convocarse para la revisión (normalmente) entre tres y cinco personas;

·         Se debe preparar por adelantado, pero sin que requiera más de dos horas de trabajo a cada persona;

·         La duración de la reunión de revisión debe ser menor de dos horas.

 

Con las anteriores limitaciones, debe resultar obvio que cada RTF se centra en una parte específica (y pequeña) del software total. Por ejemplo, en lugar de intentar revisar un diseño completo, se hacen inspecciones para cada módulo (componente) o pequeño grupo de módulos. Al limitar el centro de atención de la RTF, la probabilidad de descubrir errores es mayor.

 

Al final de la revisión, todos los participantes en la RTF deben decidir si:

 

(1)  Aceptan el producto sin posteriores modificaciones.

 

(2)  Rechazan el producto debido a los serios errores encontrados (una vez corregidos, ha de hacerse otra revisión).

 

(3)  Aceptan el producto provisionalmente (se han encontrado errores menores que deben ser corregidos, pero sin necesidad de otra revisión).

 

Una vez tomada la decisión, todos los participantes terminan firmando, indicando así que han participado en la revisión y que están de acuerdo con las conclusiones del equipo de revisión.

4.2.2 Registro e informe.

Durante la RTF, uno de los revisores (el registrador) procede a registrar todas las inconformidades que vayan surgiendo. Al final de la reunión de revisión, resume todas las inconformidades y genera una lista de sucesos de revisión. Además, prepara un informe sumario de la revisión técnica formal. El informe sumario de revisión responde a tres preguntas:

1. ¿Qué fue revisado?                   

2. ¿Quién lo revisó?           

3. ¿Qué se descubrió y cuáles son las conclusiones?

 

El informe sumario de revisión es una página simple (con posibles suplementos). Se adjunta al registro histórico del proyecto y puede ser enviada al jefe del proyecto y a otras partes interesadas.

La lista de sucesos de revisión sirve para dos propósitos:

(1)  Identificar áreas problemáticas dentro del producto

(2)  Servir como lista de comprobación de puntos de acción que guíe al productor para hacer las correcciones.

 

4.2.3 Directrices de revisión.

Se deben establecer de antemano directrices para conducir las revisiones técnicas formales, distribuyéndolas después entre los revisores, para ser consensuadas y, finalmente, seguidas. A menudo, una revisión incontrolada puede ser peor que no hacer ningún tipo de revisión. A continuación se muestra un conjunto mínimo de directrices para las revisiones técnicas formales:

1.    Revisar el producto, no al productor.

Conducida adecuadamente, la RTF debe llevar a todos los participantes a un sentimiento agradable de estar cumpliendo su deber. Si se lleva a cabo incorrectamente, la RTF puede tomar el aura de tribunal de la inquisición.

 

2.    Fijar una agenda y mantenerla.

Un mal de las reuniones de todo tipo es la deriva. La RTF debe seguir un plan de trabajo concreto. El jefe de revisión es el que carga con la responsabilidad de mantener el plan de la reunión y no debe tener miedo de cortar a la gente cuando se empiece a divagar.

3. Limitar el debate y las impugnaciones.

Cuando un revisor ponga de manifiesto una pega, podrá no haber unanimidad sobre su impacto. En lugar de perder el tiempo debatiendo la cuestión, debe registrarse el hecho y dejar que la cuestión se lleve a cabo en otro momento.

4. Enunciar áreas de problemas, pero no intentar resolver cualquier problema que se ponga de manifiesto.

Una revisión no es una sesión de resolución de problemas.

 

 

5. Tomar notas escritas.

A veces es buena idea que el registrador tome las notas en una pizarra, de forma que las declaraciones o la asignación de prioridades pueda ser comprobada por el resto de los revisores, a medida que se va registrando la información.

6. Limitar el número de participantes e insistir en la preparación anticipada. Mantener número de participantes en el mínimo. Además, los miembros del equipo de revisión deben prepararse por anticipado.

7. Desarrollar una lista de comprobación para cada producto que haya de ser revisado.

Una lista de comprobaciones ayuda al jefe de revisión a estructurar la reunión de RTF y ayuda a cada revisor a centrarse en los asuntos importantes. Se deben desarrollar listas de comprobaciones para los documentos de análisis, de diseño, de codificación e incluso de prueba.

8. Disponer recursos y una agenda para las RTF.

Para que las revisiones sean efectivas, se deben planificar como una tarea del proceso de ingeniería del software. Además se debe trazar un plan de actuación para las modificaciones inevitables que aparecen como resultado de una RTF.

9. Llevar a cabo un buen entrenamiento de todos los revisores.

Por razones de efectividad, todos los participantes en la revisión deben recibir algún entrenamiento formal.

10. Repasar las revisiones anteriores.

Las sesiones de información pueden ser beneficiosas para descubrir problemas en el propio proceso de revisión. El primer producto que se haya revisado puede establecer las propias directivas de revisión.

Resumiendo, una RTF tiene los siguientes principios:

·         Se revisa UN producto: especificación, módulo, listado, etc.

·         Poca gente, preparación y duración breves.

·         Participantes: jefe de revisión, revisores (ingenieros, programadores, etc.) y productor.

·         Decisión final:

(1) Aceptación.              

(2) Rechazo.      

(3) Aceptación condicionada a pequeñas modificaciones.

Una RTF tiene los siguientes Objetivos:

·         Descubrir errores.

·         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 sencillos los trabajos técnicos (análisis que permitan buenos diseños, diseños que permitan implementaciones sencillas, estrategias de pruebas que faciliten éstas,...)