Cotizar #3

Anuncio de noticias IFPUG

 

Pero, ¿cuál es la precisión de un FPA de alto nivel en comparación con un FPA detallado??

Ahora que IFPUG publicó Cotizar #3, los usuarios del método IFPUG ahora obtuvieron oficialmente luz verde para usar métodos de estimación de tamaño que se pueden usar antes en el ciclo de vida del proyecto de software que el momento de un diseño funcional completo. fpa #3 los métodos FPA de alto nivel (En Nesma, a menudo llamado 'FPA global' o 'FPA estimado') y FPA indicativo se describen. fpa (fpa) y muchas organizaciones comerciales y gobiernos de todo el mundo han estado utilizando estos métodos durante muchos años.. De echo, en la práctica, la documentación funcional rara vez es lo suficientemente completa y detallada para llevar a cabo un FPA detallado tan pronto en el ciclo de vida del proyecto de software como se necesita para estimar el proyecto. Este es en realidad un argumento de muchos gerentes de proyecto para no usar FPA, ya que asumen incorrectamente que una medición FPA solo se puede llevar a cabo en un diseño funcional completo, que está demasiado tarde en el ciclo de vida del proyecto para ser útil para fines de estimación.

Especialmente con la industria alejándose de las metodologías de desarrollo tradicionales hacia metodologías más ágiles., la documentación funcional que es lo suficientemente completa y detallada para llevar a cabo un FPA detallado se vuelve cada vez más rara, por lo que uno no tiene más remedio que adoptar un método estimado para poder medir/estimar el tamaño funcional.

Por supuesto, con cualquier estimación de cualquier cosa… uno debe preguntarse cuál sería la precisión de la estimación y cuál es la incertidumbre que se introduce debido a la estimación. La buena noticia es que se han publicado estudios en los que se estudió la precisión del método FPA de alto nivel y el método indicativo en comparación con un FPA detallado.. En Sogeti Holanda por ejemplo, el departamento, Estimación & Control (SEGUNDO) presentó un papel en el Foro Europeo de Medición de Software en Roma (Italia), en junio 2009, en el que la pérdida de precisión y ahorro de esfuerzo sobre el uso de FPA de alto nivel y FPA indicativo de 42 los proyectos se estudiaron en comparación con las mediciones detalladas de FPA.

Aunque para este estudio se utilizó el método Nesma, los resultados de ese estudio también deben ser comparables con el método IFPUG, como los hay muy pocas diferencias entre los dos métodos en la práctica hoy en día.

los papel, incluyendo los datos de medición, está disponible en el Artículos página. Las principales conclusiones del estudio se enumeran en la siguiente tabla.:

MétodoExactitudPérdida de precisiónEsfuerzoganancia de esfuerzo
PromedioPromedio
Detallado100%100 horas normales
Nivel alto*98.5%1.5%67 horas normales33%
Indicativo83.5%16.5%18 horas normales82%
* El FPA de alto nivel también se denomina "FPA global" o "FPA estimado" en el método Nesma.

Resulta que usar el método FPA de alto nivel en promedio da como resultado solo 1,5% Lista de características, lo que generalmente no es realmente un gran problema al principio del ciclo de vida del proyecto de software. El método indicativo es, en promedio, algo menos preciso, pero como este método se puede usar incluso antes en el ciclo de vida del proyecto de software (cuando solo se conoce o se puede determinar el número de archivos lógicos), este método es muy útil para crear un "orden de magnitud aproximado" temprano (ROM)' estimación del tamaño funcional esperado.

La columna de horas de esfuerzo muestra horas normalizadas en lugar de horas reales. Esto significa que el método estimado toma en promedio 67% del tiempo de medición en comparación con una medición detallada de FPA. El método FPA indicativo toma en promedio 18% del esfuerzo de una medición detallada de FPA.

 

Sobre los autores

Harold Heeringen, Edwin van Gorp y Theo Prins son consultores de métricas de software / ingenieros de costos de software para Sogeti Nederland B.V. Publican regularmente en congresos internacionales sobre aspectos prácticos de la medición del software.. La mayoría de sus artículos se pueden encontrar en Artículos página.

Una publicación de blog representa la opinión personal de los autores.
y puede no coincidir necesariamente con las políticas oficiales de Nesma.
Comparte este artículo en:

6 Comentarios

Deja un comentario
  1. ¿Qué porcentaje de sus análisis de FP utiliza el método detallado?? Háganos saber en el foro.

  2. Harold y Theo: Gracias por publicar esto.
    He usado el método Light FPA durante los últimos diez años por un par de razones:
    – Las primeras estimaciones requieren una visión de alto nivel del tamaño funcional. Un análisis fp detallado llevaría a creer que hay precisión donde no puede haberla..
    – Incluso en un análisis de referencia, mis clientes a menudo no pueden dar una descripción detallada sobre la implementación de atributos individuales. Falta de documentación, falta de conocimiento, falta de algo…. las razones son multiples.
    – Normalmente ofrezco presupuestos a precio fijo, por lo tanto, ser rentable, el análisis de alto nivel es la mejor opción.
    – No quiero aburrir a la audiencia.. Los clientes están bastante satisfechos cuando termino una gran aplicación SAP dentro de 2 días (“Siempre pensamos que tomaría semanas, … como puede ser que estimar solo tome 2 días….”). ¿Y no todos queremos clientes felices??
    Solo en una ocasión casi comencé a sudar: Había capacitado a personas de una gran empresa de telecomunicaciones en análisis de FPA ligero. Habíamos contado el volumen de los resultados de desarrollo de 12 meses de la organización. Después de informar los resultados de fp, la gerencia no se atrevió a confiar ni en mí ni en su propio personal, quién sabe? Entonces volaron en otra empresa de métricas. (siempre los vuelan desde muy lejos, esperando que esto lo haga más efectivo) para rehacer todo el análisis utilizando el método IFPUG detallado.
    Adivinas lo que pasó entonces, no lo haces? Encontraron menos de 1% desviación entre nuestro análisis de luz y su análisis detallado!

  3. Creo que la ganancia de esfuerzo que se informa es bastante conservadora y puede depender de sus estándares de informes.. En su comparación (2 semanas frente a 2 días) Eva muestra una ganancia de esfuerzo de 80% para un análisis de alto nivel. mi experiencia es parecida: un análisis de alto nivel es al menos 4 veces más rápido que un análisis detallado.

  4. En la conferencia de confianza de TI (tokio, octubre 2014), Investigadores japoneses realizaron una presentación que acreditó que el método FPA de alto nivel de Nesma es responsable del mayor interés en el uso del dimensionamiento funcional en la industria japonesa.. Estoy tratando de obtener la presentación., pero ya hay un artículo corto disponible, también a través de ISBSG slideshare: http://www.slideshare.net/ISBSG/matsumoto-towards-an-early-software-effort-estimation-based-on-the-nesma-method-estimated-fp

  5. Me sorprendió mucho escuchar que IFPUG ha anunciado FPA uTIP # 3 'Early FPA'. sobre más de 10 años el análisis estimado de NESMA’ (que es idéntico al análisis de alto nivel) es una práctica común en la escena de consultoría métrica holandesa.
    Las tablas del blog muestran sin ambigüedades que solo hay una ligera diferencia de tamaño entre el análisis detallado y el análisis estimado.. Por lo tanto, se puede concluir que la precisión de 'alto nivel’ el análisis es casi tan bueno como el análisis detallado, con una ganancia considerable en el esfuerzo.
    En mi opinión, la verdadera ventaja es que el "alto nivel’ FPA se puede aplicar a especificaciones de grano más grueso, por lo tanto, antes en el proyecto. En mi práctica, esto significa que se puede entregar rápidamente una estimación del tamaño y una estimación del proyecto bastante precisas al final del análisis de requisitos. (y antes del Diseño de Detalle). Tengo mucha curiosidad por la 'Estimación de costos consistente’ de IFPUG.

  6. Es una autoridad reconocida en el uso de métricas de desempeño para monitorear el impacto de TI en el negocio y en el avance de las organizaciones de TI hacia niveles más altos de madurez de procesos de software. dice:

    Gracias por esta publicación; es bastante útil. Hemos utilizado Quick FPA en muchas situaciones, y la precisión de la estimación siempre se debate. Este análisis me vendría bien.!

Deja una respuesta