Análisis de Puntos de Función - una técnica sobreestimar serio?

https://stackoverflow.com/questions/2694382

01-10-2019
|

Pregunta

Bounty aclaración

Yo sé que es una cuestión subjetiva. La respuesta ideal que estoy buscando es el que explica por qué el escenario citado aquí sería tan sorprendente.

Si cree que el escenario citado es hecho de no sorprendente y lo que se espera, por favor romper los pasos necesarios para probar cómo una pequeña aplicación de este tipo puede tener más de un mes y varios miles de dólares de desarrollo. Fui bastante lejos para hacer los cálculos (por ejemplo, mirando hacia arriba los salarios mínimos), así que esperar la respuesta ideal para hacer similar.

Si cree que el escenario citado es, en efecto sobreestimada, por favor determinar exactamente sus razones. ¿Qué errores se puede detectar en su cálculo que dio lugar a un enorme costo para tal una sencilla aplicación de esa manera? ¿Cómo se habrían hecho de otra manera? (Sin necesidad de escribir todo el proceso, pero los detalles en lugar de sentimientos generalizados sería bueno)

Sé preguntas acerca FPA ha pedido numerosas veces antes, pero esta vez me estoy tomando un punto de vista más analítico en ella, copia de seguridad con los datos .

1. En primer lugar, algunos datos

Esta pregunta se basa en un tutorial . Tenía una sección de "número de muestra" donde demostró paso a paso. Se pueden ver algunas capturas de pantalla de su aplicación de ejemplo aquí .

En el extremo, él calcula la FP no ajustado ser 99.

Hay otro artículo en InformIT con los datos de la industria sobre la hora típica / FP. Se extiende de 2 horas / PF a 27,4 horas / FP. try Vamos a seguir con 2 por el momento (ya que los lectores también lo son, probablemente, la multitud más eficiente: p).

2. Verificación de la realidad!?

Ahora sólo echa un vistazo a la imágenes de nuevo.

Hacer un poco de matemáticas aquí

99 * 2 = 198 hours
198 hours / 40 hours per week = 5 weeks

En serio? Que la aplicación de la muestra se va a tomar 5 semanas para poner en práctica? ¿Es sólo mi sensación de que no tomaría cualquier programador decente más de una semana (I "m fin de semana ni siquiera diciendo) para tenerlo completo?

Ahora vamos a tratar de estimar el costo del proyecto. Vamos a utilizar el salario mínimo de Nueva York en el momento ( Wikipedia ), la cual es $ 7,25

198 * 7.25 = $1435.5

Por lo que pude ver en las imágenes, esta aplicación es una pequeña aplicación Excel-mejora. Que podría haber comprado MS Office Pro por 200 dólares que me da una mayor interoperabilidad (archivos .xls) y flexibilidad (hojas de cálculo).

(Para el registro, el mismo sitio Web tiene otro artículo sobre la productividad Parece que suelen utilizar 4,2 horas / PF, lo que nos da las estadísticas aún más impactantes:.

99 * 4.2 = 415 hours = 10 weeks = almost 3 whopping months!
415 hours * $7.25 = $3000 zomg

(que es incluso suponiendo que todos nuestros codificadores pobres reciben el salario mínimo!)

3. Me estoy perdiendo algo aquí?

En este momento, podría llegar a varias explicaciones posibles:

FPA es realmente sólo adecuado para proyectos más grandes (1000 PM) por lo que se convierte en extremadamente inexacta en menor escala.
Las horas / PF fluctúa métricas bruscamente de equipo en equipo, un proyecto a otro. Para un pequeño proyecto como este, nos podría haber usado algo así como 0,5 horas / FP o algo así. (Ahora bien, este tipo de cosa que hace que toda la estimación sin sentido, a menos que mi empresa hace el mismo tipo de proyectos desde hace varios años con el mismo equipo, no muy común).

A partir de mi experiencia con varias métricas de software, punto de función no es realmente una métrica de peso ligero. Si las horas / PF cosa fluctúa mucho, entonces ¿cuál es el punto, tal vez podría haber ido con historia de usuario Puntos wHICH es mucho más rápido para llegar y podría decirse que casi tan incierto.

¿Cuál sería respuestas de los expertos de FP a esto?

Solución

Hace

unos diez años, un compañero de copas mío me dio un gran trozo de sabiduría. En cualquier proyecto de consulta, hacer tres preguntas: 1. ¿Cuál es el problema que estamos tratando de resolver? 2. ¿Cuáles son los entregables? 3. ¿Cómo sabremos cuando hayamos terminado? Añadió que uno nunca debe asumir cualquier proyecto para el que ninguna de las preguntas no fue respondida antes del inicio del proyecto.

En el caso que nos ocupa, tenemos otra historia de terror software de estimación de método, en el que la estimación parece ridículamente alto. Me gustaría responder a su historia de terror al señalar que él no ha dado respuestas a la segunda y tercera, y en realidad no ha respondido a la primera, excepto para decir "queremos construir algo que funciona algo como esto."

I se expandiría en ese señalando explícitamente que ni siquiera ha preguntado qué tareas la estimación de Puntos de Función está incluyendo o excluyendo del total estimado. ¿Cuánto esfuerzo extra es el estimador puntual función que permite a la documentación, por ejemplo? Si la estimación es para la aplicación, sin ningún tipo de documentación, y la estimación del punto del estimador de la función era para la aplicación con la documentación completa, bueno, yo diría que hay algo de espacio para el desacuerdo sobre la cantidad total de trabajo (y el tiempo) requerida.

Otros consejos

¿Es sólo mi sensación de que no lo haría tomar cualquier programador decente más de una semana (I "m ni siquiera diciendo fin de semana) tenerlo completo?

Los desarrolladores siempre tienden a subestimar el tiempo que toma para terminar en realidad algo. Ellos piensan que no habrá errores, no hay cambios en los requisitos, y nada de lo que nunca he hecho antes y tienen que pasar unos días en averiguar.

Por lo que pude ver en la capturas de pantalla, esta aplicación es una pequeña aplicación Excel-mejora. yo podría ha comprado Pro MS Office para 200 dinero que me da mayor interoperabilidad (archivos .xls) y flexibilidad (hojas de cálculo).

Se está comparando el precio de una pieza completamente personalizado de software para uno que está vendiendo millones de copias? En serio?

La realidad es que la mayoría de los métodos de estimación de software no reflejan suficientemente, aunque a primera vista, parece contrario a la intuición. Una vez trabajé en una empresa donde 300 líneas de código por mes-hombre se consideró una estimación de altura, y la mayoría de los meses que se situó en más como 200-250. Pero vamos a ir con el 200. Eso es 10 líneas de código por día de trabajo. Que no pueden escribir 10 líneas de código en un día de trabajo? ¡Venga! Podría escribir 50 a 100 o más líneas de código en un buen día! Y sin embargo, las empresas que utilizan números como éstos terminan en repetidas ocasiones sus proyectos de retraso y por encima del presupuesto. ¿Porqué es eso? Así, la corrupción del alcance, como sugiere Michael Borgwardt, es un grande. Pero la atracción de dejar que eso fuera la imagen durante un minuto, y se supone que el cliente y el cliente lo hizo bien la primera vez. ¿Por qué una empresa estimación sólo 10 líneas de código por día?

Análisis de los requerimientos
El diseño de software basado en los requerimientos
Las reuniones para coordinar las interfaces y la arquitectura con compañeros de equipo.
Los gastos generales (reuniones de estado con la gestión, tiempo por enfermedad, vacaciones, ...)
pruebas de unidad de escritura
Escribir un plan de pruebas para toda la applicaiton
pruebas de nivel de aplicación

Eso es toda la ingeniería del día a día el software que puedo tirar de la parte superior de la cabeza en 3 minutos, estoy seguro de que me perdí un poco más, pero ¿que ayuda obtener una imagen más completa de dónde vienen esas estimaciones de?

No es un experto FP. Sin embargo estamos mirando FP en este momento. En particular, estamos realizando análisis de FP contra viejos proyectos que tenemos las métricas para el esfuerzo / coste, etc. A continuación, podemos evaluar su utilidad para nosotros en la estimación / proyectos de tamaño.

Mi opinión en este punto es que va a ser una de arriba hacia abajo 'orden de magnitud' útil estimado inferior a la estimación de complemento a. Siempre es bueno si más de una técnica de estimación se puede aplicar para ayudar a validar que los números que están siendo llegaron a 'sostienen'.

Un pensamiento adicional - el coste / esfuerzo por punto de función (es decir requisito funcional) dependerá de los requisitos no funcionales que se requieren para el sistema. Una vez que empiece a tomar en cuenta la seguridad, la accesibilidad, el rendimiento, la explotación forestal (y alerta), mantenibilidad, portabilidad, cumplimiento de normas y así sucesivamente, el coste / esfuerzo por FP aumenta significativamente. Ahora bien, estos pueden no ser una consideración para la aplicación de ejemplo de un solo usuario citado. Pero si esta aplicación es importante para una empresa o potencialmente sus clientes o una gran proporción de la población en general, la necesidad de tener en cuenta esos requisitos no funcionales sin duda aumentará.

En lo personal he encontrado FPA engañosa ... inicialmente.

A menos que tenga los datos históricos de FPA de proyectos anteriores, FPA sin duda puede llegar a una sobreestimación de todo el asunto, utilizando estándares de la industria.

Me supo que VAF es un buen indicador a utilizar cuando se trata de FPA. A pesar de que le da un rango de variación del 35% en el recuento de FP, que está deteniendo el gerente analista / proyecto de convertir esto en una variación del 50%.

Un buen líder de equipo siempre se evalúa su capacidad equipos antes de hacer estimaciones. Lo mismo va para FPA, cifras estándar de la industria se alcanzaron basan en datos históricos, y estos datos varía de empresa a empresa, equipo a equipo y desarrollador a desarrollador.

Así que yo diría que si se utiliza el mejor de los casos de -35% en el recuento no ajustada, se llega a una cifra ajustada de FP ~ 64. Le da más o menos 3 semanas y media de estimación. Por experiencia, diría que una aplicación de este tipo pueden hacerse mucho más rápido que eso, pero ninguna prueba cuidadosa, depuración, documentación y demás papeleo se extendería más lejos y FP toma en cuenta. Es muy posible que su equipo está haciendo 1 FP / h. Según los estándares normales, codificación y pruebas representa el 25% del conteo FP, por lo que en este caso, incluso teniendo su figura de 99 programas marco, la parte de codificación y prueba bajaría a 25 fps, que es más comprensible teniendo en cuenta la situación.

Lo que también he visto en la práctica es que algunas empresas han ideado sus propias tablas de complejidad, por lo que si las RET 3 y 10 DETs significan complejidad media para una empresa, otra clasificaría como de baja complejidad. Esto afectaría en gran medida el número de FP final.

Así que utilice la herramienta de FP como guía y recoger la mayor cantidad de datos para proyectos anteriores como sea posible antes de empezar a depender de FPA establecer estimaciones de costes y tiempo.

Como nota al margen, creo que las estimaciones de costos en un software simple como eso parecería ridícula hoy, donde la subcontratación y el trabajo independiente es el camino a seguir. Las grandes empresas que han estado en este negocio siguen cobrando ridículamente alto para el desarrollo de software. Por ejemplo, si desea un ingeniero de nivel 3 de apoyo que le ayude con sus servidores en una empresa buena de alojamiento, que cobran $ 250 por hora, sin embargo, usted puede obtener el mismo consejo de alguien basándose en otras partes del mundo en $ 25 o incluso $ 2,5.

Esperanza mis 2 centavos son de alguna utilidad para ti.

En mi empresa anterior que habría calculado como que - especialmente si alguien quiere que pagar por ello;)

Me han practicado FP en algunos proyectos y se encontró que proporciona una estimación bastante precisa. A veces se puede sobreestimar ya veces subestimar dependiendo del tipo de aplicación. Normalmente para aplicaciones científicas, FP podría ser subestimada. FP ofrece durante todo el tiempo de desarrollo del proyecto, no sólo el tiempo para escribir código. Por supuesto no hay actividades de desarrollo, como la configuración del entorno de prueba, etc y estos deben ser estimados por separado. No soy un gran defensor de FP, pero aprecio su uso. Si no es una estimación precisa, si se practica correctamente (la identificación de archivos y elementos de registro), que al menos valida lo completo de sus necesidades.

En cierto modo, hay que decir que el FP es bueno para medianas y grandes proyectos, escalado más de 350-400 fps.

pagos basados ??en el tiempo conducen a un menor rendimiento indirectamente. Recuerdo proyectos con pagos basados ??en el tiempo que hizo un gran trabajo de investigación para cada aspecto del proyecto, mientras que si tuviera un método de pago basado en proyectos tal vez no lo hice. No es la mente inconsciente ética. La mejor práctica es refiriéndose definición "Proyecto" (dentro de un tiempo limitado y el presupuesto) y la decisión sobre la base de maquillaje limitaciones. No se trata de la propia obra, es decir, que paga por un paraguas en un día lluvioso mucho más que cuando usted compra normalmente. No se moleste en sí mismo acerca de lo que ha hecho y lo mucho que vale la pena. Centrarse en el valor de la obra al cliente y sus opciones.

El tapar los valores del ejemplo ha citado en este práctico calculadora punto la función en línea ( http://developergeeks.com/ functionpoint.aspx ), que calcula los PM ajustado y tiene en cuenta varios otros factores de ponderación, consigo los siguientes resultados, suponiendo una tasa de productividad de 2 imágenes por segundo por hora desde el sistema en el ejemplo es tan simple:

Ajustado PM: 42,9
Meses persona estimados: 0,54

Suponiendo 160 horas en un mes de trabajo, que funciona a aproximadamente 86,4 horas, o más o menos dos semanas de trabajo de un desarrollador. No cinco semanas como se concluyó en el paso 2. Teniendo en cuenta que el desarrollo de los sistemas de pago de los clientes requiere tomar sólo un poco más de cuidado y esfuerzo que acaba golpeando a cabo algún código tarde en la noche para su propia diversión, no creo que eso es una estimación razonable en todos.

Es decir, no me malinterpreten, el análisis de FP en las manos equivocadas es probablemente una idea terrible. Pero si usted tiene antecedentes de un desarrollador puede aplicar a contar MF y destripar la comprobación de los diversos factores de ponderación, no es una mala manera de obtener una estimación razonable de que no se basa en la pura fantasía cuando no se dispone de las especificaciones de diseño detallado , requisitos o un plan de proyecto a nivel de tareas detallada para el trabajo de documentación completa. Pero usted tiene que utilizar el sentido común para hacer que funcione para usted.

A partir de mi experiencia con varias métricas de software, es función de punto Realmente no es una métrica de peso ligero. Si la hora cosa / FP fluctúa mucho, entonces ¿cuál es el punto, tal vez podría haber ido con historia de usuario Puntos que es mucho más rápido para llegar y podría decirse que casi tan incierto.

El punto de tener Análisis de Puntos de Función está teniendo algún tipo de reglas / directrices que son tan objetivo y el nivel que debería (dentro de un cierto margen) terminan dándole la misma cantidad de puntos de función en una aplicación y / o proyecto , independientemente de qué experto contado, si se aplican las reglas de manera consistente y correcta. La productividad por punto de función, como has descubierto, es altamente fiable de muchos factores como la experiencia del equipo, herramientas, lenguaje de programación, plataforma, etc, etc Por lo tanto estándares de la industria son bueno saber, pero en la mayoría de los casos completamente inútiles (en mi humilde opinión ). El principal valor de conteo repetitiva es la construcción de su propio 'benchnmark' basado en su propio historial de la productividad del equipo. Esto a su vez le ayudará a ver las tendencias y también ayudan a planificar y predecir horas necesarias para los cambios futuros. Si usted está buscando para la velocidad, basta con aplicar los recuentos globales en lugar de recuentos detallados. Al hacer unos recuentos de ejemplo (como en la preparación para los exámenes) se dará cuenta de la diferencia entre un recuento detallado y un recuento global no son lo suficientemente grandes para dormir suelta sobre (en%).

Esta discusión es absolutamente engañoso, ya que la cuestión ya supone FPA es una técnica de estimación de esfuerzo. No es .

tamaño funcional (expresada en puntos funciones) puede ser uno de los muchos factores de entrada para un modelo de estimación (como COCOMO). No más -. Pero tampoco menos si estamos de acuerdo en que la 'cantidad' de los requisitos funcionales es un controlador esfuerzo para proyectos de software

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow