Puntos de micro función ponderados ( WMFP ) es un algoritmo de dimensionamiento de software moderno que es un sucesor de métodos científicos ancestrales sólidos como COCOMO , COSYSMO , índice de mantenibilidad, complejidad ciclomática , puntos de función y complejidad de Halstead . Produce resultados más precisos que las metodologías tradicionales de dimensionamiento de software, [1] al tiempo que requiere menos configuración y conocimiento por parte del usuario final, ya que la mayor parte de la estimación se basa en mediciones automáticas de un código fuente existente.
Como muchos métodos de medición de antepasados usan líneas de código fuente (SLOC) para medir el tamaño del software, WMFP usa un analizador para comprender el código fuente dividiéndolo en micro funciones y derivar varias métricas de volumen y complejidad de código, que luego se interpolan dinámicamente en un final puntuación de esfuerzo. Además de la compatibilidad con la metodología del ciclo de vida del desarrollo de software en cascada , WMFP también es compatible con metodologías más nuevas, como las metodologías Six Sigma, Boehm spiral y Agile (AUP / Lean / XP / DSDM), debido a su capacidad de análisis diferencial hecho posible por sus elementos de medición de mayor precisión. [2]
Elementos medidos
Los elementos medidos de WMFP son varias métricas de software diferentes deducidas del código fuente por el análisis del algoritmo de WMFP. Se representan como porcentaje del esfuerzo total de la unidad (proyecto o archivo) y se traducen en tiempo.
- Complejidad de flujo (FC) : mide la complejidad de la ruta de control de flujo de un programa de manera similar a la complejidad ciclomática tradicional , con mayor precisión mediante el uso de cálculos de pesos y relaciones.
- Vocabulario de objetos (VO) : mide la cantidad de información única contenida en el código fuente de los programas, similar al vocabulario tradicional de Halstead con compensación dinámica de lenguaje.
- Conjuración de objetos (OC) : mide la cantidad de uso que hace la información contenida en el código fuente de los programas.
- Complejidad aritmética (IA) : mide la complejidad de los cálculos aritméticos en todo el programa.
- Transferencia de datos (DT) : mide la manipulación de estructuras de datos dentro del programa
- Estructura de código (CS) : mide la cantidad de esfuerzo invertido en la estructura del programa, como separar el código en clases y funciones
- Datos en línea (ID) : mide la cantidad de esfuerzo invertido en la incorporación de datos codificados de forma rígida
- Comentarios (CM) : mide la cantidad de esfuerzo invertido en la redacción de comentarios del programa
Cálculo
El algoritmo WMFP utiliza un proceso de tres etapas: análisis de funciones, transformación APPW y traducción de resultados. Un algoritmo dinámico equilibra y suma los elementos medidos y produce una puntuación de esfuerzo total. La fórmula básica es:
- ∑ (WiMi) ∏Dq
- M = el valor de las métricas de origen medido por la etapa de análisis de WMFP
- W = el peso ajustado asignado a la métrica M por el modelo APPW
- N = el recuento de tipos de métricas
- i = el índice de tipo métrico actual (iteración)
- D = el factor de los generadores de costos proporcionado por la entrada del usuario
- q = el índice de generador de costos actual (iteración)
- K = el recuento de generadores de costos
Luego, esta puntuación se transforma en tiempo mediante la aplicación de un modelo estadístico llamado ponderaciones de perfil de programador promedio (APPW), que es un sucesor patentado de COCOMO II 2000 y COSYSMO . El tiempo resultante en horas de trabajo del programador se multiplica luego por un costo por hora definido por el usuario de un programador promedio, para producir un costo promedio del proyecto, convertido a la moneda del usuario.
Desventajas
Los elementos básicos de WMFP, en comparación con los modelos de dimensionamiento tradicionales como COCOMO, son más complejos hasta el punto de que no pueden evaluarse manualmente de manera realista, incluso en proyectos más pequeños, y requieren un software para analizar el código fuente. Como resultado, solo se puede usar con predicciones de costos basadas en analogías y no con conjeturas teóricas.
Ver también
Referencias
- ^ Capers Jones (octubre de 2009) "Mejores prácticas de ingeniería de software": páginas 318–320 [1]
- ^ Publicación trimestral de TickIT (2009) "Trimestre 1, 2009": página 13