¿Qué tan útiles son los puntos de función? [cerrado]

¿Qué tan útil es medir puntos de función ?

Usamos puntos de función en mi nuevo trabajo. He oído hablar de puntos de función, pero no he tenido ningún entrenamiento o experiencia ... pero no tengo mucha confianza en cosas que no se pueden explicar de manera sucinta.

Personalmente, nunca he encontrado una respuesta explícita a la pregunta "¿Qué es un punto de función?" Sin eso, realmente DUDO sobre cualquier metodología de estimación que afirme hacer algo con los Puntos de Función.

La parte más importante de una metodología de estimación de software seria es la "recalibración periódica a datos reales", lo que significa que hace su estimación, la anota y luego, cuando termina el proyecto, compara sus resultados reales con su estimación, y , si es necesario, revise su proceso de estimación. INCLUIDO EN ESO es comparar sus ENTRADAS a su proceso de estimación con las ENTRADAS ACTUALES.

Si, por ejemplo, estima las líneas de código fuente (SLOC) y parte de allí, debe comparar su SLOC real entregado con su SLOC estimado, y ver si, qué tan lejos, dónde y por qué se extravió. Un estimador que predice horas-hombre perfectamente, dada una estimación precisa y precisa de SLOC, no le servirá de nada si sus estimaciones de SLOC no valen nada. Basura dentro basura fuera. (Lo mismo se aplica a los puntos de función).

Si sus datos reales de SLOC (o punto de función) coinciden con sus estimaciones iniciales, puede ver sus costos reales en comparación con sus costos estimados y ajustar los parámetros de su estimador para mejorar sus resultados. La División General Dynamics / Fort Worth realizó este ejercicio, en detalle, a principios de la década de 1980, para el desarrollo de software F-16C / D, y luego, durante varios años, apostaría habitualmente a los resultados de la compañía en esas estimaciones. GD / FW fue la fuente de ingresos de GD durante bastante tiempo, manteniendo el resto de la empresa a flote, por lo que deben haber estado haciendo algo bien.

Y tenga en cuenta que los requisitos y el arrastre de características es EL ENEMIGO de la estimación de software.

(Esta es una edición posterior). El último punto de Bernd merece una respuesta. Pregunta qué se debe hacer con los proyectos que llegan temprano y no gastan todas las horas de trabajo asignadas.

Esto es tanto un error de estimación como los excesos de programación (mucho más comunes). El hecho es este: si todos sus proyectos están sobrepasando su cronograma, sus estimados no están haciendo su trabajo.

Si sus estimadores están haciendo todo bien, y sus gerentes están haciendo todo bien, entonces tendrán algunos proyectos que llegarán temprano, junto con los que lleguen tarde. Las estimaciones son probabilidades. Sombree su estimador para eliminar los retrasos en el cronograma y, POR DEFINICIÓN, aumentará la probabilidad de excesos en el cronograma. Si su gestión exige horarios y estimaciones con cero posibilidad de empotramiento, a continuación, va a ser la entrega horarios que SERÁ ser invadido, garantizado, y luego usted comenzará a ver las demandas de Marchas de la muerte, y luego se empiezan a ver renuncias y sus excesos de obtener mucho, mucho peor, a medida que intenta reclutar reemplazos (y se corre la voz de que su empresa es una fábrica de explotación).

Cuando se trata del alcance de un proyecto, generalmente es mejor usar una medida de Puntos de Función en lugar de Líneas de Código . Debido a que los proyectos de software pueden tener más de millones de LOC (incluido LOC en las bibliotecas), el número se vuelve relativamente insignificante.

¿Cómo se mide LOC si está llamando a la funcionalidad de las bibliotecas? ¿Incluye LOC de las bibliotecas? Si no incluye LOC de las bibliotecas, ¿su jefe no cree que está escribiendo suficiente LOC?

En general, es mejor decir "Completé la funcionalidad XXX" en lugar de "Escribí XXX líneas de código".

Pero te sugiero que lo veas por ti mismo. ¿Es más fácil para usted estimar puntos de función o líneas de código? Conecte esos resultados al modelo COCOMO II y vea cuál es más fácil de usar.

Además, este Manual de COCOMO II ofrece una descripción detallada de los Puntos de función y LOC en la página 11. Esperemos que sea suficiente para que continúe.

Trabajo en una organización donde introdujimos puntos de función para calcular proyectos de precio fijo, es decir, el cliente y contamos según las especificaciones, acordamos el recuento y luego multiplicamos el #FP con un precio FP para determinar el precio del proyecto. Todo esto en un entorno con una facturación anual de dos millones de millones de euros. La intención es eliminar la ambigüedad y la negociación de la determinación del precio, que fue una causa constante de fricción.

Hemos realizado una calibración inicial, evaluando aproximadamente 2 años de historia del proyecto por valor de dos dígitos millones de euros.

Claramente vemos que #FP y los costos del proyecto se correlacionan de manera muy indirecta. Las desviaciones de +/- 50% son razonablemente posibles. Sin embargo, vemos (bueno, esperamos, o mejor: esperamos) que a largo plazo los puntos de función cuentan y los costos del proyecto convergen.

Ahora estamos en el proceso de implementar esto en la organización y la experiencia (desde un punto de vista superior):

• Debates sobre las aplicaciones de las reglas de conteo de FP. Hay estándares sobre esto, sin embargo, están sujetos a negligencia si no se puede discutir sobre los precios directamente.

• Las impresiones de los clientes de que los precios subieron, a pesar de los esfuerzos que gastamos y estamos gastando en calibración y verificación de calibración. La razón sospechada es que este procedimiento deja los costos brutalmente claros, no hay forma de ocultar, cambiar o cubrir los costos en algunos proyectos "no preguntar" o estratégicos.

• Necesidad de manejar proyectos que no cubren sus costos (50% menos de lo esperado ...)

Parecen ser marginalmente útiles para expresar la complejidad de un sistema / componente dado, y pueden ayudar a los gerentes / equipo a liderar el trabajo de distribución, pero en realidad no son más útiles que cualquier otra métrica sintética / arbitraria (SLOC, Complejidad Ciclomática, etc. .) Es decir, pueden dar una indicación de la cantidad relativa de esfuerzo requerido para partes específicas de un sistema, pero no hay forma de mapearlos con estimaciones concretas.

El uso de puntos de función a favor de líneas de código busca abordar varios problemas adicionales:

• El riesgo de "inflación" de las líneas de código creadas, y así reducir el valor del sistema de medición, si se incentiva a los desarrolladores a ser más productivos. Los defensores de FP se refieren a esto como medir el tamaño de la solución en lugar del tamaño del problema.

• Las líneas de código (LOC) miden los lenguajes de bajo nivel de recompensa porque se necesitan más líneas de código para ofrecer una cantidad similar de funcionalidad a un lenguaje de nivel superior. C. Jones ofrece un método para corregir esto en su trabajo.

• Las medidas LOC no son útiles durante las primeras fases del proyecto, donde es difícil estimar la cantidad de líneas de código que se entregarán. Sin embargo, los puntos de función pueden derivarse de los requisitos y, por lo tanto, son útiles en métodos como la estimación por proxy.

Huir.

En mi experiencia, las compañías que he visto usar puntos de función están solo un paso por encima de la locura pura.