Métricas en el Desarrollo de Software

Comienza Ya. Es Gratis
ó regístrate con tu dirección de correo electrónico
Rocket clouds
Métricas en el Desarrollo de Software por Mind Map: Métricas en el Desarrollo de Software

1. 4.1.1 Visión General de los Factores que Afectan a la Calidad

1.1. Estos factores evalúan el software desde tres puntos de vista distintos: (1) operación del producto (utilizándolo), (2) revisión del producto (cambiándolo) y (3) transición del producto (modificándolo para que funcione en un entorno diferente

2. 4.1.2 Medida de la calidad

2.1. Aunque hay muchas medidas de la calidad de software, la corrección, facilidad de mantenimiento, integridad y facilidad de uso suministran indicadores útiles para el equipo del proyecto

3. 4.1.3 Medidas de fiabilidad y de disponibilidad.

3.1. Los trabajos iniciales sobre fiabilidad buscaron extrapolar las matemáticas de la teoría de fiabilidad del hardware a la predicción de la fiabilidad del software TMEF = TMDF+TMDR (4.2) (TMDF (tiempo medio de fallo) y TMDR (tiempo medio de reparación). Disponibilidad = TMDF/(TMDF + TMDR) x 100 % (4.3).

4. 4.1.4 Eficacia de la Eliminación de Defectos

4.1. es la eficacia de la eliminación de defectos (EED) En particular el EED es una medida de la habilidad de filtrar las actividades de las 68 garantías de calidad y de control al aplicarse a todas las actividades del marco de trabajo del proceso. EED = E / (E + D).

5. 4.1.5 Factores de Calidad de McCall

5.1. Los factores que perturban la calidad del software se pueden categorizar en dos grandes grupos: (1) factores que se pueden medir directamente (por ejemplo: defectos por puntos de función) y (2) factores que se pueden medir sólo indirectamente (por ejemplo: facilidad de uso o de mantenimiento).

6. 4.1.6 FURPS (Funcionality, Usability, Reliability, Performance, Supportability)

6.1. Hewlett-Packard ha desarrollado un conjunto de factores de calidad de software al que se le ha dado el acrónimo de FURPS: [Pressman ’98]

7. 4.2 Métricas del modelo de análisis

7.1. En esta fase se obtendrán los requisitos y se establecerá el fundamento para el diseño. Y es por eso que se desea una visión interna a la calidad del modelo de análisis.

8. 4.2.1 Métricas basadas en la función

8.1. La métrica de punto de función (PF) (capítulo 3.6.2) se puede usar como medio para predecir el tamaño de un sistema que se va a obtener de un modelo de análisis. Para instruir el empleo de la métrica PF, se considerará una sencilla representación del modelo de análisis mostrada por Pressman

9. 4.2.2 La métrica Bang

9.1. para desarrollar una indicación del tamaño del software a implementar como consecuencia del modelo de análisis. Desarrollada por Tom DeMarco [Ejiogo ‘91], la métrica bang es “ una indicación, independiente de la implementación, del tamaño del sistema”

10. 4.2.3 Métricas de la Calidad de Especificación

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

11. 4.3 Métrica del modelo del diseño

11.1. Las métricas para software, como otras métricas, no son perfectas; muchos expertos argumentan que se necesita más experimentación hasta que se puedan emplear bien las métricas de diseño. Sin embargo el diseño sin medición es una alternativa inaceptable.

12. 4.3.1 Métricas de diseño de alto nivel

12.1. Estas métricas son de caja negra, en el sentido de que no se requiere ningún conocimiento del trabajo interno de ningún modo en particular del sistema.

12.2. 4.3.2 Métricas de diseño en los componentes

12.2.1. a nivel de componentes se concentran en las características internas de los componentes del software e incluyen medidas de la cohesión, acoplamiento y complejidad del módulo.

13. 4.3.2.1 Métricas de cohesión.

13.1. una colección de métricas que proporcionan una indicación de la cohesión de un módulo. Las métricas se definen con cinco conceptos y medidas

14. 4.3.2.2 Métricas de acoplamiento.

14.1. El acoplamiento de módulo proporciona una indicación de la “conectividad” de un módulo con otros módulos, datos globales y entorno exterior.

15. 4.3.2.3 Métricas de complejidad.

15.1. Muchas de éstas se basan en una representación denominada grafo de flujo, un grafo es una representación compuesta de nodos y enlaces (también denominados filos) Cuando se dirigen los enlaces (aristas), el grafo de flujo es un grafo dirigido.

16. 4.3.3 Métricas de diseño de interfaz

16.1. se ha publicado relativamente poca información sobre métricas que proporcionen una visión interna de la calidad y facilidad de empleo de la interfaz.

17. 4.4 Métricas de código fuente

17.1. ‘probablemente la mejor conocida y más minuciosamente estudiada... medidas compuestas de la complejidad (software)’ [Ejiogo ‘91]. La ciencia software propuso las primeras ‘leyes’ analíticas para el software de computadora.

18. 4.5 Métricas para pruebas

18.1. Se pueden juntar y correlacionar varias características a nivel de proyecto (p ej.: esfuerzo y tiempo las pruebas, errores descubiertos, número de casos de prueba producidos) de proyectos anteriores con el número de Pf producidos por un equipo del proyecto.

19. 4.6 Métricas de mantenimiento

19.1. diseñadas explícitamente para actividades de mantenimiento. El estándar IEEE 982.1-1988 [Pressman ‘98] sugiere un índice de madurez del software (IMS) que proporciona una indicación de la estabilidad de un producto de software (basada en los cambios que ocurren con cada versión del producto)