- Este tema tiene 18 respuestas, 9 voces, y fue actualizado por última vez 6 años, 3 meses hace por
.
-
Publicaciones
-
Hola a todos,
No estaba seguro en qué tema debería publicar mi pregunta, así que lo pongo aquí. Creo que los puntos de función son una excelente manera de adjuntar algún tipo de medida de tamaño a una pieza de código., pero es una molestia contarlos. Tengo que pasar por todos los requisitos de E/S y estructuras de datos para obtener un conteo razonablemente bueno. Encontré algunas herramientas que pueden contar automáticamente, pero son bastante caros y estaba buscando algo de experiencia con ese tipo de herramientas. ¿Hay alguien en esta comunidad que tenga experiencia con el conteo automatizado de FPA??
Ian
Estimado,
Al responder a tu pregunta: Tengo experiencia en conteo automatizado de FPA.
El último 5 años, He dedicado mucho tiempo a desarrollar una herramienta para el conteo automatizado de FPA. Esta herramienta se basa en el procesamiento del lenguaje natural y puede leer texto en inglés y holandés.. Entonces, si tiene documentos como un diseño funcional, Requisitos, Casos de uso, etc., esta herramienta puede dar un recuento estimado de FPA. Puede procesar varios documentos al mismo tiempo. También puede proporcionar un recuento estimado de documentos de diseño de SAP como Blue Prints, etc.. El recuento se basa en Nesma. 2.2 versión.
Si quieres más información, me envió un correo electrónico.
Saludos
Peter Bellen
Países Bajos
pwhbellen@hotmail.comIan,
Residencia en (IFPUG) FPA, el Object Management Group ha publicado el Especificaciones FPA automatizadas a comienzos de 2014. Yo sé eso Software de CAST tiene una herramienta de trabajo que cuenta los puntos de función, basado en las especificaciones OMG. Esta herramienta es bastante cara..
Sé que dentro de la comunidad COSMIC hay mucho trabajo en progreso para automatizar el proceso de conteo.. Renault tiene una herramienta de trabajo en funcionamiento, pero eso no está disponible para uso comercial. Sé que Dutchsoft tiene una herramienta semiautomática para el conteo de puntos de función de SAP, pero eso solo está disponible como servicio. Los trabajos de Renault y Dutchsoft se presentaron en la 2014 Conferencia IWSM Mensura en Róterdam. Los papeles están disponibles en 2014.iwsm-mensura.org.
Peter,
¿Hay mucha diferencia entre Nesma 2.2 (parece estar solo en holandés) y el 2.1 versión? Y entre Nesma e IFPUG?
Franco,
¿Tiene algunas referencias a COSMIC que estén disponibles públicamente?? El enlace IWSM me envía a un sitio IEEE donde tengo que pagar por los documentos.
Hola, Ian,
soy de CAST. Ya que lo mencionaste, No niego que hay un cierto precio asociado con nuestro software ;-).
Una de las razones por las que CAST puede contar automáticamente los APF es la inversión de 120 millones de dólares que se invirtió en R&D para llegar a un producto capaz de calcular nuestra estructura interna de aplicaciones complejas de múltiples capas con suficiente precisión y proporcionar una precisión, repetible, y con el tiempo, conteo automatizado bastante rentable de AFP y EFP (Puntos de función de mejora).A su pregunta sobre el intercambio de experiencias en APF, ha habido una adopción significativa de CAST AFP en varias cuentas y en varios integradores de sistemas importantes en el último año más o menos. Si me envías un correo electrónico, Puedo indicarle contactos relevantes para su interés. Solo en la primera página de la lista de cuentas de miembros de Nesma, pude detectar 2 principales SI que tienen CAST COE con experiencia significativa en el tema.
Saludos
Gerardo
g.karsenti@castsoftware.comIan,
Si vas a Esfuerzo conjunto de dos Asociaciones de Métricas de Software encontrará algunos documentos sobre el tema que se pueden descargar de forma gratuita. La inversión en algunos de los periódicos es muy pequeña en relación a la inversión de CAST ;-). También puede publicar su pregunta en el Grupo de usuarios COSMIC está en LinkedIn. Sé que varias personas involucradas en el desarrollo COSMIC automatizado son miembros de ese grupo.
También puedo responder las preguntas que le dirigiste a Peter. nesma 2.2 es la versión holandesa del inglés 2.1 estándar. Dado que la versión en inglés es compatible con ISO / IEC 24570 estándar tiene un capítulo adicional 1 con las cosas ISO, pero aparte de eso son identicos. Con respecto a las diferencias entre Nesma e IFPUG hay un documento en el Sección de descarga de artículos de este sitio web que explica las diferencias.
Actualmente, la ISO/CEI 24570 está debajo revisión sistemática y la Nesma Comité de Prácticas de Conteo ha emitido una lista de mantenimiento con mejoras. Cuando se acepten estas mejoras, se generará una nueva versión de las pautas de conteo.. Nos aseguraremos de que las versiones en inglés y holandés sean idénticas., para evitar confusión.
Saludos, Franco
Una pregunta dirigida a los proveedores de software automatizado de conteo de puntos de función: ¿Está considerando ofrecer su software como un servicio, como un modelo de pago por uso??
también, Todavía tengo que encontrar evaluaciones de AFPC que respondan todas las siguientes preguntas sobre la muestra en la que se basa la evaluación:
– distancia media (proporción de errores) de conteo automatizado de conteo experto (+relación mediana si la distribución es sesgada)
– Desviación estándar de la distancia media
– tamaño de la muestra (norte)
– Clase de tamaño de los conteos de la muestra (Por ejemplo 100-500 FP, 500-1500 FP, etc. — si la muestra es mixta, proporcione las medidas anteriores por clase de tamaño)
– tipo de conteo (como sistema, Mejora,… — si la muestra es mixta, proporcione las medidas anteriores por tipo de conteo)
– Lo mismo para el tipo de sistema (incorporado, negocio, interactivo, lote,…)Hasta ahora siempre he sentido que faltaba uno u otro aspecto para poder hacer una llamada. Por ejemplo, si el error promedio se da como 5%, pero no se da ninguna indicación sobre la clase de tamaño de conteo, No puedo juzgar si la medida sería adecuada para los recuentos de sistemas individuales.. Por lo que vale, solo podría ser adecuado para cuentas de cartera con un tamaño de más de 50,000 FP (ley de los grandes numeros). ¿Conoce algún artículo que evalúe el software de punto de función y que sea lo suficientemente completo como para cubrir todos estos aspectos??
Hola,
Hice un par de publicaciones sobre el estándar OMG y lo que se necesita para que un software SCA cuente AFP en el blog de cualilogía.
Juan Pedro,
Esta es una publicación de blog interesante.. Puedo aconsejar a todos que lo lean.. Por el bien de esta discusión, copié algunas de sus observaciones.:
Como podemos ver, el documento del estándar OMG especifica los requisitos para el uso de Puntos de Función Automatizados, así como sus limitaciones. Los puntos que creo que es más importante recordar son los siguientes.
Perímetro
El estándar no “aborda el dimensionamiento de las mejoras a una aplicación o funcionalidad mantenida (a menudo llamados puntos de función de mejora) » y, por lo tanto, solo se aplicaría a nuevos desarrollos. Si este es el caso, limita mucho su uso e interés.AFP e IFPUG
El estándar AFP no pretende el cumplimiento estricto de un conteo manual de Puntos de Función: « Los recuentos de puntos de función automatizados pueden diferir de los recuentos manuales producidos por contadores de puntos de función certificados por IFPUG ». Este me parece un primer punto importante: Los puntos de función automatizados no son puntos de función IFPUG. Esta es otra medida, que tiene la ventaja de ser computable automáticamente por una herramienta, y por tanto con menos esfuerzo que un contador manual, pero también con un resultado diferente.Configuración
Contar AFP requiere identificar y ensamblar en componentes funcionales todas las estructuras de datos y transacciones, y decidir cuáles son internos o externos, y cuáles tener en cuenta o no al configurar la herramienta y configurar el análisis. Esto supone que tiene personas disponibles con un buen conocimiento de:- La solicitud por parte de una PYME o un experto del proyecto.
- El proceso de contar Puntos de Función Automatizados para determinar el alcance del análisis y los factores a considerar.
- La herramienta y sus parámetros para configurar el análisis, verificar falsos positivos y validar los resultados, de acuerdo con los dos puntos anteriores.
- Esta fase de configuración es obviamente crítica si queremos lograr un resultado más objetivo., y por lo tanto lo más creíble posible a la hora de medir la productividad de un equipo.
Análisis y validación
Contar puntos de función automatizados con una herramienta supone que esta herramienta es capaz de:- Analiza cualquier tipo de componente.
- Identificar cualquier vínculo entre estos componentes..
- Reúna todos estos enlaces en transacciones con la menor cantidad posible de falsos positivos.
Pero es raro que una herramienta de análisis de código tenga un analizador capaz de reconocer y analizar cualquier tipo de archivo en una tecnología determinada., y menos en diferentes tecnologías. Una herramienta puede reconocer operaciones como "leer" o "escribir" en un archivo plano en una aplicación por lotes, para identificar los diferentes tipos de enlaces entre archivos xml de un marco Java y no poder analizar un informe Html o Excel. Una característica importante de nuestra aplicación Timesheet en nuestro ejemplo será producir hojas de actividades para validación antes de facturar., generalmente en diferentes formatos: Sobresalir, PDF, etc. No conozco ninguna herramienta de análisis de código que gestione este tipo de archivos..
Encontrar todos los enlaces entre los componentes puede ser difícil o imposible para algunas tecnologías.. El uso de marcos (Primavera, Hibernar, etc.) complica el análisis, y esto supone un importante trabajo de validación de los resultados para evitar en lo posible falsos positivos, y luego verifique las transacciones identificadas y el conteo de Puntos de Función para cada una de ellas.Conclusión
La métrica de tamaño de punto de función también se puede usar para medir de manera efectiva la calidad del software que se entrega., Creo que los puntos de función automatizados son una medida diferente, que produce resultados diferentes a una estimación manual realizada por un consultor IFPUG. En una situación ideal, sería genial contar con un consultor así para participar en la definición del alcance del análisis, la configuración de la herramienta, la validacion de los resultados. Esto asumiendo que la herramienta es capaz de identificar todos los componentes, los vínculos entre ellos, estructuras de datos, actas, etc.Incluso en un caso tan ideal, Creo que la diferencia entre una estimación manual y los puntos de función automatizados es al menos 10% a 20%, más a menudo entre 40% y 50%. como minimo. también podría ser 200% o 300% diferente, por ejemplo para una aplicación Cobol Batch (muchos archivos planos), un software integrado (ERP) con diferentes módulos, en caso de un marco que haga imposible identificar claramente las transacciones, etc.
Usted plantea algunas dificultades prácticas.. Ahora puedo entender por qué CAST ha invertido USD 120 millones para que funcione..
A todos ustedes,
gran discusión. Vamos a replantearnos si vamos a empezar con el conteo automatizado. He visto algunos enfoques rápidos en los documentos de Nesma que pueden ser útiles.. Tal vez regrese con algunas preguntas sobre eso..
A Jean-Pierre,
Es una pena que la discusión en tu blog de Qualilogy esté cerrada., así que pondré mis puntos aquí. Una de las objeciones que planteas en el blog que Frank no copió es que AFP no trabaja en mejoras.. me parece un comentario injusto, ya que cambiar de software es una actividad. Puede describirlo en un documento de cambio., puedes imaginarlo en tu cabeza y luego cambias el código. AFP mide el código, que se cambia o no. El cambio no está en el código., por lo que un analizador nunca podrá capturarlo. Eso no es un defecto de AFP., eso es tecnicamente imposible. Es posible que pueda capturar parte del cambio comparando un recuento antes y después del cambio, pero eso será muy difícil cuando se realicen mejoras en las funciones existentes.
Hubo un par de cosas en tu blog y la reacción que me gustaría comentar. Ya que no puedo hacerlo en Qualilogy, Podría hacerlo aquí en una publicación separada.
Ian,
Los comentarios en mi blog fueron cerrados. 30 días después de la publicación, para evitarme tener que gestionar a todos estos spammers que intentan vender pastillas y todo tipo de productos que no tienen nada que ver con mi blog. Lo acabo de volver a abrir para que puedas dejar un comentario y cualquiera pueda participar en una discusión., después de la moderación.
No entiendo muy bien tu punto sobre los cambios.. Frank mencionó arriba la parte sobre las mejoras. (ver “Perímetro”).
Y si, Las herramientas SCA pueden analizar cambios, basado en la diferencia entre diferentes análisis, en el código existente o no. Puede (o deberia) diga cuántos componentes se han agregado, eliminado, modificado, y si se modifica, el cambio en métricas habituales como LOC, CC, … y también en AFP.Como se menciona en la publicación, esto es obligatorio para lo que la gente quiere principalmente cuando se trata de AFP: estimación de la productividad. Si cedes el mantenimiento de una aplicación a un subcontratista, debes saber cuanto afp agrego, eliminado, modificado en base a estos cambios para medir su productividad, y compararlo con otros subcontratistas o en diferentes tecnologías.
¿Es un nuevo subcontratista responsable de los defectos ya presentes en el código que debe mantener?? No. Lo mismo para la AFP, cuentas lo que cambió, no lo que esta en el codigo que le entregas.Como todos sabéis, 90% de las actividades de programación están en mantenimiento, no hay tantas novedades. Entonces, tener el estándar OMG que dice que AFP se aplica solo en nuevos desarrollos realmente me sorprendió, porque disminuye seriamente el interés de esta medida por 90% de los proyectos.
Juan Pedro,
Lo siento si no fui lo suficientemente claro. Intentaré de nuevo. Escribes que te sorprendió la declaración de OMG.
Ante todo. La OMG establece que AFP no aplica para mejoras. Eso no es exactamente lo mismo que decir que solo se aplica a los nuevos desarrollos.. Trataré de explicar por qué.
Las herramientas AFP funcionan en código estático, por lo que miden el tamaño del código tal como es. Eso es antes o después del mantenimiento.. Cambiar el software es una actividad que puede describir en un documento de cambio, pero no en el código. El código se cambia, O no. Para medir el tamaño de un proyecto de mantenimiento, necesitaría dos instancias estáticas del código, uno antes y otro despues, y luego analiza las diferencias. No estoy seguro de si eso es técnicamente posible.. Así que no juzgaría negativamente el hecho de que Dios mío no está haciendo que suceda este milagro..
Ian,
Publiqué respuestas a sus comentarios en mi blog. http://qualilogy.com/en/do-developers-dream-of-automated-function-points-2/#comment-2312.
Dentro de poco:
. si, tendrás que analizar al menos 2 versiones y almacenar las diferencias. Esto es lo que suelen hacer las herramientas SCA.
. A menudo es posible con estas herramientas hacer un análisis incremental solo en cambios (agregado, eliminado, modificado) componentes, pero esto no funcionará para AFP ya que debe analizar cada transacción y estructuras de datos en todas las capas de la aplicación.
. Si las herramientas SCA pueden hacer esto, por qué esta limitación de las especificaciones OMG? esto no es preciso.Me encantaría saber por qué porque no puedo entender, y si esta norma se limita solo a nuevos proyectos, Me gustaría saberlo antes de que las empresas empiecen a medir AFP en todo su portafolio de aplicaciones, cuyo 90% son aplicaciones en mantenimiento.
Juan Pedro,
Gracias por sus respuestas. Si las herramientas SCA pueden almacenar las diferencias, que las herramientas de conteo deberían poder hacer lo mismo. Tal vez Gerard pueda responder esa pregunta.. No puedo imaginar que no pensaran en eso como parte de un 120 M$ inversión.
Estimados,
aquí está mi contribución a la (muy estimulante) discusión.En mayo 17, en WETSOM 2015, Presenté una evaluación crítica de AFP. Puede recuperar el papel de
http://conferences.computer.org/icse/2015/content/papers/7103a035.pdf#page=1.
Si se solicita un nombre de usuario y contraseña, mandame un email y te los envio.En cuanto a las preguntas sobre la mejora, Ian tiene toda la razón: Código de medida AFP que puede ser resultado de mantenimiento o resultado de nuevo desarrollo. sin embargo, en WETSOM Bill Curtis mencionó que CISQ está trabajando en la especificación de puntos de función de mejora automatizada (ver también http://it-cisq.org/cisq-to-start-work-on-automated-enhancement-function-point-specification/).
Finalmente, hay alguna actividad de investigación que aborda la medición automatizada de puntos de función basada en la ejecución del código. La idea es que al observar los rastros de ejecución, es posible ver qué procesos invocaron los usuarios., qué datos se utilizaron en cada proceso, y qué datos se intercambiaron entre los usuarios y el sistema. En la práctica, por la traza de ejecución contiene la información necesaria para calcular los puntos de función. Estas iniciativas prometen, pero el código a medir necesita ser instrumentado, y actualmente no hay ninguna herramienta de apoyo, excepto prototipos académicos y pruebas de concepto.
- Debes iniciar sesión para responder a este tema.