example cosmic project-management function-points

project-management - example - cosmic function points wiki



Análisis de puntos de función: ¿una técnica seriamente sobreestimada? (11)

¿Siento que no le tomaría a un programador decente más de una semana (ni siquiera digo fin de semana) que se complete?

Los desarrolladores siempre tienden a subestimar el tiempo que se tarda en terminar algo. Piensan que no habrá errores, no habrá cambios en los requisitos, y nada que nunca hayan hecho antes y que tengan que pasar días investigando.

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

¿Está comparando el precio de un software completamente personalizado con uno que vende millones de copias? ¿Seriamente?

Aclaración de la generosidad

Sé que es una pregunta subjetiva. La respuesta ideal que estoy buscando es una que explique por qué el escenario citado aquí sería tan sorprendente.

Si cree que el escenario citado no es sorprendente y es de esperar, analice los pasos para demostrar cómo una aplicación tan pequeña puede tardar más de un mes y varios miles de dólares en desarrollo. Fui bastante lejos para hacer los cálculos (por ejemplo, buscando salarios mínimos), por lo que espero que la respuesta ideal sea similar.

Si cree que el escenario citado está realmente sobreestimado, señale exactamente sus razones. ¿Qué errores puede detectar en su cálculo que llevaron a un costo tan grande para una aplicación simple como esa? ¿Cómo lo habrías hecho diferente? (No es necesario escribir todo el proceso, pero los detalles en lugar de los sentimientos generalizados serían agradables)

Sé que las preguntas sobre FPA se han hecho muchas veces antes, pero esta vez estoy tomando un ángulo más analítico, respaldado por datos .

1. Primero, algunos datos.

Esta pregunta se basa en un tutorial . Tenía una sección de "Recuento de muestras" donde lo demostró paso a paso. Puedes ver algunas capturas de pantalla de su aplicación de muestra aquí .

Al final, calculó que el FP no ajustado era 99 .

Hay otro artículo en InformIT con datos de la industria en hora típica / PF. Se extiende desde 2 horas / FP hasta 27.4 horas / FP. Intentemos mantenernos con 2 por el momento (ya que los lectores SO son probablemente la gente más eficiente: p).

2. ¿Verificación de la realidad?

Ahora solo echa un vistazo a las capturas de pantalla de nuevo.

Hacer un poco de matemáticas aquí

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

¿Seriamente? ¿Que aplicación de muestra va a tardar 5 semanas en implementarse? ¿Siento que no le tomaría a un programador decente más de una semana (ni siquiera digo fin de semana) que se complete?

Ahora intentemos estimar el costo del proyecto. Usaremos el salario mínimo de Nueva York en este momento ( Wikipedia ), que es de $ 7.25

198 * 7.25 = $1435.5

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

(Para el registro, ese mismo sitio web tiene otro artículo que discute la productividad. Parece que normalmente usan 4.2 horas / PF, lo que nos da estadísticas aún más impactantes:

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

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

3. ¿Me estoy perdiendo algo aquí?

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

  1. El FPA es realmente adecuado solo para proyectos más grandes (1000+ FP) por lo que se vuelve extremadamente inexacto a menor escala.
  2. La métrica de horas / FP fluctúa abruptamente de un equipo a otro, de un proyecto a otro. Para un proyecto pequeño como este, podríamos haber usado algo como 0.5 hour / FP o algo así. (Ahora este tipo de cosas hace que la estimación no tenga sentido, a menos que mi empresa realice el mismo tipo de proyectos durante varios años con el mismo equipo, no es realmente común).

Desde mi experiencia con varias métricas de software, Function Point no es realmente una métrica liviana. Si la cosa hora / PF fluctúa tanto, entonces cuál es el punto, tal vez podría haber elegido Puntos de historia de usuario, lo cual es mucho más rápido de obtener y, sin duda, casi incierto.

¿Cuáles serían las respuestas de los expertos en PF a esto?

Desde mi experiencia con varias métricas de software, Function Point no es realmente una métrica liviana. Si la cosa hora / PF fluctúa tanto, entonces cuál es el punto, tal vez podría haber elegido Puntos de historia de usuario, lo cual es mucho más rápido de obtener y, sin duda, casi incierto.

El punto en el que tiene el análisis de puntos de función es tener algún tipo de reglas / directrices que son objetivas y estándar, de modo que (dentro de un cierto margen) terminen dándole la misma cantidad de puntos de función en una aplicación y / o proyecto, independientemente de qué experto lo contó, si las reglas se aplican de manera consistente y correcta. La productividad por punto de función, como descubrió, es altamente dependiente de muchos factores como la experiencia del equipo, las herramientas, el lenguaje de programación, la plataforma, etc. Por lo tanto, es bueno conocer los estándares de la industria, pero en la mayoría de los casos es completamente inútil (en mi humilde opinión ). El valor principal en el conteo repetido es construir su propia ''referencia'' basada en el historial de productividad de su propio equipo. Esto, a su vez, lo ayudará a ver las tendencias y también a planificar y predecir las horas necesarias para futuros cambios. Si está buscando velocidad, simplemente aplique conteos globales en lugar de conteos detallados. Al hacer algunos recuentos de ejemplo (como cuando se prepara para los exámenes), notará que la diferencia entre un recuento detallado y un recuento global no es lo suficientemente grande como para perder el sueño (en%).

Al conectar los valores del ejemplo que citó en esta práctica calculadora de puntos de función en línea ( http://developergeeks.com/functionpoint.aspx ), que calcula los PF ajustados y tiene en cuenta otros factores de ponderación, obtengo los siguientes resultados, suponiendo una tasa de productividad de 2 FP por hora ya que el sistema en el ejemplo es tan simple:

  1. FP ajustados: 42.9
  2. Persona estimada meses: 0.54

Suponiendo 160 horas en un mes de trabajo, eso equivale a aproximadamente 86.4 horas, o aproximadamente dos semanas de trabajo para un desarrollador. No son cinco semanas como lo concluyó en el paso 2. Dado que desarrollar sistemas para pagar a los clientes requiere un poco más de cuidado y esfuerzo que simplemente eliminar algunos códigos a última hora de la noche para su propia diversión, no creo que sea una estimación irrazonable en todos.

Quiero decir, no me malinterpreten, el análisis de FP en las manos equivocadas es probablemente una idea terrible. Pero si tiene antecedentes de desarrollador, puede aplicar para contar FPs y revisar los diversos factores de ponderación, no es una mala manera de obtener una estimación razonable que no esté basada en fantasía pura cuando no tiene especificaciones de diseño detalladas. , requisitos completamente documentados o un plan de proyecto detallado a nivel de tarea para trabajar desde. Pero tienes que usar un poco de sentido común para que funcione para ti.

En mi empresa anterior lo habríamos calculado así, especialmente si alguien quiere pagar por ello;)

Esta discusión es absolutamente engañosa, ya que la pregunta ya supone que el FPA es una técnica de estimación del esfuerzo. No lo es

El tamaño funcional (expresado en puntos de 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 requisitos funcionales es un factor de esfuerzo para los proyectos de software.

Hace unos diez años, un amigo mío me dio una gran cantidad de sabiduría. En cualquier consulta de proyecto, haga 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 nunca se debe asumir ningún proyecto para el cual no se haya respondido ninguna de las preguntas antes de que comience el proyecto.

En el caso que nos ocupa, tenemos otra historia de terror del Método de estimación de software, en la que la estimación parece ridículamente alta. Yo respondería a su historia de horror al señalar que no ha respondido a la segunda y tercera preguntas, y realmente no ha respondido a la primera, excepto para decir "Queremos construir algo que funcione de esta manera".

Me gustaría ampliar eso al señalar que explícitamente ni siquiera ha preguntado qué tareas incluye o excluye la estimación de Puntos de Función del total estimado. ¿Cuánto esfuerzo extra está permitiendo el estimador de puntos de función para la documentación, por ejemplo? Si su estimación es para la aplicación, sin ningún tipo de documentación, y la estimación del estimador del punto de función fue para la solicitud con la documentación completa, bueno, diría que hay cierto margen de desacuerdo sobre la cantidad total de trabajo (y tiempo) requerida.

He practicado la PF en algunos proyectos y descubrí que proporciona una estimación bastante precisa. Algunas veces puede sobreestimar y otras veces subestimar dependiendo del tipo de aplicación. Típicamente para aplicaciones científicas, la PF podría ser subestimada. FP proporciona el tiempo completo de desarrollo del proyecto, no solo el tiempo para escribir código. Por supuesto, no hay actividades de desarrollo, como la configuración del entorno de prueba, etc., y estas deben estimarse por separado. No soy un gran defensor de FP, pero aprecio su uso. Si no es una estimación precisa, si se practica correctamente (identificando archivos y elementos de registro), al menos valida la integridad de sus requisitos.

En cierto modo, deberíamos decir que la PF es buena para proyectos medianos a grandes, escalando más de 350-400 PF.

La realidad es que la mayoría de los métodos de estimación de software en realidad se subestiman, aunque a primera vista parece contraintuitivo. Una vez trabajé en una compañía donde 300 líneas de código por hombre-mes se consideraron una estimación ALTA, y la mayoría de los meses tuvimos más de 200-250. Pero vamos con los 200. Eso es 10 líneas de código por día de trabajo. ¿Quién no puede escribir 10 líneas de código en un día de trabajo? ¡Venga! ¡Podría escribir de 50 a 100 o más líneas de código en un buen día! Y, sin embargo, las compañías que usan números como estos completan repetidamente sus proyectos atrasados ​​y por encima del presupuesto. ¿Porqué es eso? Bueno, el alcance del alcance, como sugiere Michael Borgwardt, es muy importante. Pero saquemos eso de la imagen por un minuto, y asumamos que el cliente y el cliente lo entendieron bien la primera vez. ¿Por qué una empresa estima solo 10 líneas de código por día?

  • Análisis de requerimientos
  • Diseño de software basado en requerimientos.
  • Reuniones para coordinar interfaces y arquitectura con compañeros de equipo.
  • Costos generales (reuniones de estado con la administración, tiempo de enfermedad, vacaciones, ...)
  • Pruebas unitarias de escritura.
  • Escribiendo un plan de prueba para toda la aplicación.
  • Pruebas a nivel de aplicación

Esa es toda la ingeniería de software del día a día que puedo sacar de mi cabeza en 3 minutos, estoy seguro de que me perdí un poco más, pero ¿eso ayuda a obtener una imagen más completa de dónde provienen esas estimaciones?

Los pagos basados ​​en el tiempo conducen a un menor rendimiento indirectamente. Recuerdo proyectos con pagos basados ​​en el tiempo en los que hice mucha investigación para cada aspecto del proyecto, mientras que si tenía un método de pago basado en proyectos tal vez no lo hice. Es la mente inconsciente, no la ética. La mejor práctica es referir la definición de "Proyecto" (dentro de un tiempo y presupuesto limitados) y tomar decisiones basadas en limitaciones. No se trata del trabajo en sí, es decir, usted paga por un paraguas en un día lluvioso mucho más que cuando compra normalmente. No te preocupes por lo que ha hecho y cuánto vale. Centrarse en el valor del trabajo para el cliente y sus opciones.

No es un experto en FP. Sin embargo estamos mirando a FP en este momento. En particular, estamos realizando un análisis de PF contra proyectos antiguos, ya que contamos con métricas de esfuerzo / costo, etc. Luego, podemos evaluar su utilidad para los proyectos de estimación / dimensionamiento.

Mi punto de vista en este punto es que será una estimación útil de ''orden de magnitud'' de arriba hacia abajo para complementar la estimación de abajo hacia arriba. Siempre es bueno si se puede aplicar más de una técnica de estimación para ayudar a validar que los números a los que se llega se "retrasan".

Un pensamiento adicional: el costo / esfuerzo por punto de función (es decir, requisito funcional) dependería de los requisitos no funcionales que se requieren para el sistema. Una vez que comienza a tener en cuenta la seguridad, accesibilidad, rendimiento, registro (y alerta), capacidad de mantenimiento, portabilidad, cumplimiento normativo, etc., el costo / esfuerzo por PF aumenta significativamente. Ahora, esto puede no ser una consideración para la aplicación de ejemplo de usuario único citada. Pero si esta aplicación es importante para una empresa o potencialmente para sus clientes o para una gran parte del público en general, la necesidad de tener en cuenta esos requisitos no funcionales ciertamente aumentará.

Personalmente encontré FPA engañosa ... inicialmente.

A menos que tenga datos de FPA históricos de proyectos anteriores, FPA definitivamente puede terminar sobreestimando todo esto, utilizando los estándares de la industria.

Aprendí que VAF es un buen indicador para usar cuando se trata de FPA. Aunque le da un rango de variación del 35% en su recuento de PF, quién está impidiendo que el analista / gerente de proyecto convierta esto en una variación del 50%.

Un buen líder de equipo siempre evalúa la capacidad de sus equipos antes de hacer estimaciones. Lo mismo ocurre con FPA, las cifras estándar de la industria se alcanzaron basándose en datos históricos, y estos datos varían de una compañía a otra, de un equipo a otro y de un desarrollador a otro.

Por lo tanto, diría que si utiliza el mejor escenario posible de -35% en el recuento no ajustado, alcanzará un recuento de FP ajustado de ~ 64. Le da aproximadamente 3 semanas y media de estimación. Por experiencia, diría que una aplicación de este tipo PUEDE hacerse mucho antes, pero cualquier prueba exhaustiva, depuración, documentación y otro trabajo de papel lo ampliaría aún más y FP lo tiene en cuenta. Es muy posible que su equipo esté haciendo 1 FP / hr. Según los estándares normales, la codificación y las pruebas representan el 25% del recuento de FP, por lo que en este caso, incluso tomando su cifra de 99 FP, la parte de codificación y prueba se reduciría a 25 FP, lo que es más comprensible dada la situación.

Lo que también he visto en la práctica es que algunas compañías han diseñado sus propias tablas de complejidad, por lo que si 3 RET y 10 DET significan complejidad promedio para una compañía, otra lo calificaría de baja complejidad. Esto afectaría en gran medida el recuento final de FP.

Entonces, use la herramienta de PF como guía y recopile la mayor cantidad de datos de proyectos anteriores que pueda antes de comenzar a confiar en FPA para establecer las estimaciones de costos y tiempo.

Como nota al margen, creo que las estimaciones de costos en un software simple como ese parecen hoy ridículas, donde la externalización y el trabajo independiente son el camino a seguir. Las grandes compañías que han estado en este negocio todavía cobran de manera ridículamente alta por el desarrollo de software. Por ejemplo, si desea que un ingeniero de soporte de nivel 3 lo ayude con sus servidores en una buena compañía de alojamiento, le cobrarían $ 250 por hora, sin embargo, puede obtener el mismo consejo de alguien con sede en otras partes del mundo a $ 25 o incluso $ 2.5.

Espero que mis 2 centavos te sean de alguna utilidad.