Página de inicio de Nesma El Dimensionamiento Dimensionamiento – FPA Factores de cambio en Nesma FPA

Etiquetado: , , ,

Visita 6 publicaciones - 1 mediante 6 (de 6 total)
  • Autor
    Publicaciones
  • #6485
    Leandro Kirsch
    Partícipe

    Aquí en el mercado de TI de Brasil existe un concepto de Factor de Cambio que se utiliza para varias y grandes empresas y que está establecido por la regla NESMA.. Recientemente me asocié y pude leer el manual de la FPA y no encontré ninguna referencia a eso..

    Aquí un resumen de esos factores de cambio y fórmulas.:

    Factores de cambio en Nesma FPA

    ¿Eso realmente proviene de NESMA?? Tengo la impresión de que podría ser parte de NESMA FPA antes de ser el estándar ISO., pero eso es sólo una suposición por mi parte (y posible incorrecto…)

    ¿Puede alguien ayudarme con eso??

    Gracias por adelantado,
    Leandro Kirsch

    #6488
    Frank Vogelezang
    Llave maestra

    leandro,

    Estas fórmulas provienen de una fuente de Nesma., pero como has observado correctamente, no vienen del estándar Nesma. Vienen de una guía FPA para mejora de software, o APF para mejora de software en portugues. Este enfoque alternativo fue diseñado para permitir una cifra de productividad tanto para el software recién creado como para las mejoras del software existente.. Dado que se trata de una combinación de tamaño y productividad (de acuerdo con la ISO / IEC 14143 definiciones) Este enfoque no puede ser parte del estándar Nesma., para tamaño funcional. Es una extensión popular del estándar Nesma e IFPUG y su uso documentado se describe en los Países Bajos., Brasil y Corea del Sur. Si realmente se trata de una mejora en el uso de la forma estándar de mejoras de tamaño es un debate de larga data dentro de la comunidad Nesma.. Escribí un artículo al respecto que ha sido publicado como mejor artículo en el 2014 La medida IWSM conferencia: El valor añadido de los puntos de función de mejora – Una evaluación empírica. Hasta donde yo sé, esta es la única comparación documentada entre el enfoque estándar y el enfoque alternativo..

    Espero que esto ayude.

    #7524
    Leandro Kirsch
    Partícipe

    Hola frank,

    Perdón por no haber recibido respuesta. Estaba disfrutando de mis largas vacaciones anuales y fiestas de fin de año.! te deseo un feliz 2016!

    Después de leer los documentos que mencionó como se enumeran a continuación:
    FPA para mejora de software EN v2.2.1
    PTF para mejora de software PT v2.2.1
    2014 La medida IWSM – El valor añadido de los puntos de función de mejora – Una evaluación empírica

    Llego a algunas conclusiones de la FPA para la Guía de mejora de software que me gustaría que su opinión o la de los miembros correspondientes de la junta directiva:
    1. Estas pautas ignoran en absoluto el concepto de Tipo de elemento de registro para el factor de impacto al analizar las funciones de datos.;
    2. Como se menciona en la sección Descargo de responsabilidad (1.6) NESMA informa que estas pautas requieren investigación y uso práctico y aún no han sido validadas científicamente.;
    3. Como se mencionó varias veces, El recuento estándar de FPA debe proporcionarse o realizarse antes de utilizar esas pautas y otros requisitos previos también definidos y deben tenerse en cuenta.;
    4.Estas directrices han sido elaboradas por NESMA, sin embargo, utilizan como base toda la información proporcionada por NESMA e IFPUG en ambas normas ISO de FPA. (24570 y 20926 respectivamente) ;
    5. Aunque, según los estándares mencionados, diría que si se han utilizado las reglas IFPUG para el recuento de proyectos de desarrollo, se deberían utilizar las mismas reglas para el recuento de proyectos de mejora.; por otro lado, si se han utilizado las reglas NESMA para el recuento de proyectos de desarrollo, se deben utilizar las mismas reglas para el recuento de proyectos de mejora.;
    6. No se debe fomentar el uso de las reglas IFPUG en el conteo de proyectos de desarrollo y las reglas NESMA en el conteo de proyectos de mejora o viceversa.. Mi principal preocupación al usar diferentes reglas en diferentes conteos es que, aunque sean menores en todo un proyecto de desarrollo, contabilizan, Para un proyecto de mejora, estos pueden ser significativos.. P.ej. NESMA e IFPUG divergen en las definiciones de investigación externa y resultados y si un proyecto de mejora determinado tiene un impacto mayoritario en ese tipo de funciones, tal vez EFP podría ser bastante diferente de lo esperado.;
    7. En la sección 5 – Mejora del presupuesto, se recomienda que en general la EFP (Mejora) y PTF (Pruebas) Las horas de productividad difieren de las horas por punto de función cuando se utiliza el método FPA estándar..
    8. En la evaluación empírica compartida en 2014 IWSM basado en la mejora de Apex parece que las variaciones usando unidades FPA estándar fueron menores que usando el método EFP y luego, en ese contexto, FPA estándar parece ser más confiable que EFP.

    Interesado en escuchar las opiniones de otros miembros de NESMA sobre mis comentarios anteriores..
    Leandro Kirsch

    #7527
    Frank Vogelezang
    Llave maestra

    leandro,

    Gracias por tus observaciones.. Estas son algunas de las respuestas que puedo dar con certeza..

    2. Hasta donde yo sé mi 2014 El artículo de IWSM es la única validación científica conocida de Enhancement FPA.

    3. El FPA regular es de hecho la base para realizar el FPA de mejora.

    4. Puede utilizar este enfoque con IFPUG FPA como base. Por lo que he oído sobre la aplicación de este enfoque, esto es bastante común en países que están más familiarizados con IFPUG que con Nesma como métrica básica de FPA..

    8. Nunca he experimentado una ventaja real del método Enhancement FPA sobre el uso del enfoque de mejora estándar de IFPUG o Nesma.. El conjunto de datos que presenté en el 2014 El artículo de IWSM parece respaldar esa experiencia., aunque las estadísticas no son un rechazo firme al enfoque.

    Espero que esto ayude.

    #7528
    Ton Dekkers
    Partícipe

    leandro, Primero un poco de historia. Aunque yo',metro “oficialmente” involucrado en EFPA más tarde, La base se estableció en la época en la que trabajaba para un banco holandés a principios de los años 90. . Siempre hubo una discusión sobre la aplicación de FPA en mejoras.. Especialmente la dirección que tuvo que aprobar el presupuesto cuestionó el número de FP: ¿Cómo podría un simple cambio tener el mismo FP que un nuevo desarrollo?? Aunque para efectos presupuestarios se ajustó la productividad. Sin embargo, el banco me pidió que desarrollara algo que se ajustara mejor a su percepción.. Utilicé los principios de la FPA.: si eso, RETIRADO, FTR determina la complejidad de una función. , Los cambios de estos elementos podrían ser una buena medida para identificar la complejidad del cambio.. En mi enfoque original tenía 4 categorias (y todavía prefiero usar esos)- cambio sencillo , promedio, cambio, solo cambio y prueba compex. Mis fórmulas utilizan el número de cambios., no el percentil. En mi “investigación” para el banco (Residencia en 5 proyectos) Se me ocurrió una matriz similar a las de EFPA solo que con números absolutos y basada en Nesma FPA 1.0 (no ISO en ese momento). los “calculado” factores 0.27, 0.47 y 0.72 se cambian a 0.25, 0.50 y 0.75 también para alejarse de la percepción de que este enfoque es preciso. De todos modos, el banco estuvo satisfecho con el enfoque y funcionó bastante bien en ese período con las actividades de TI dentro de esa organización..
    Luego lo retomó un grupo de trabajo de Nesma y crearon el documento original.. Esto se ajusta a Nesma. 2.2 luego conmigo como editor.
    El origen de EFP sigue siendo el enfoque ISO. Determinar el número de FP según el estándar elegido. (Nesma o IFPUG). Utilice el factor de cambio para determinar (coherente) la complejidad del cambio. Si tu base es IFPUG, utilizar reglas IFPUG para determinar el cambio. Mantenga también las reglas consistentes..
    “Postergación” el RET es algo de la historia. En el momento del origen del enfoque Nesma, RET no es igual 1 fue bastante raro. Para mantener el enfoque simple, esto no era tan relevante para incorporar.
    Debido a la falta de evidencia científica y al posible conflicto con el cumplimiento de la norma ISO, se agregó el descargo de responsabilidad en el 2.2.1. lanzamiento.
    Supongo que la razón principal por la que se utiliza EFPA, Cumple más con la percepción de los expertos, especialmente los que no pertenecen a la FPA.. Y después de todos estos años siento que sigue siendo útil identificar la complejidad del cambio..
    Ton Dekkers

    #7530
    Leandro Kirsch
    Partícipe

    Muchas gracias a ambos por la respuesta rápida y detallada..

Visita 6 publicaciones - 1 mediante 6 (de 6 total)
  • Debes iniciar sesión para responder a este tema.