Métricas en el Desarrollo de Software
por MarcsTutos XDLOL
1. 4.1.3 Medidas de fiabilidad y de disponibilidad.
1.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).
2. 4.1.4 Eficacia de la Eliminación de Defectos
2.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).
3. 4.1.5 Factores de Calidad de McCall
3.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).
4. 4.2 Métricas del modelo de análisis
4.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.
5. 4.2.2 La métrica Bang
5.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”
6. 4.3 Métrica del modelo del diseño
6.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.
7. 4.3.2.1 Métricas de cohesión.
7.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
8. 4.3.2.3 Métricas de complejidad.
8.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.
9. 4.4 Métricas de código fuente
9.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.
10. 4.6 Métricas de mantenimiento
10.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)
11. 4.1.1 Visión General de los Factores que Afectan a la Calidad
11.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
12. 4.1.2 Medida de la calidad
12.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
13. 4.1.6 FURPS (Funcionality, Usability, Reliability, Performance, Supportability)
13.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]
14. 4.2.1 Métricas basadas en la función
14.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
15. 4.2.3 Métricas de la Calidad de Especificación
15.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.
16. 4.3.1 Métricas de diseño de alto nivel
16.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.
16.2. 4.3.2 Métricas de diseño en los componentes
16.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.