Artículos

Respuestas a las preguntas del Webinar: "Estimaciones acertadas para la planeación y control del software"

 

 

El pasado martes 28 de Junio organizamos el webinar Estimaciones acertadas: Soluciones para la planeación y control del software, en el cual se presentó información sobre las estimaciones a partir de actividades, tales como la planificación de un proyecto o un tiempo de anteproyecto, siendo generalmente  un desafío a el TI.O método IFPUG (y los métodos de NESMA o COSMIC) permitiendo acercarse el tamaño funcional de la información disponible. 

 

Al final de este seminario, los participantes serán capaces de entender las dinámicas descritas y entender cómo los puntos de función y COCOMOII pueden integrarse para producir estimaciones fiables y  más técnicas que puedan ser utilizados con fines políticos, como la determinación de un objetivo o un centro de  compromisos entre las partes interesadas.

 

Sim más preambulos, pasemos a las preguntas:

 

 

Pregunta 1

¿Es cierto que la estimación por puntos de función depende de como se aplique, dado que tiene un modelo estándar de entradas y salidas (I/O)? - Tatiana Hernandez

 

Respuesta:

Es muy común que se confunda los resultados de la aplicación completa del análisis de puntos de función con una estimación, pero no lo es. Es una medición que refleja una cantidad de funcionalidad proveída por un producto de software listo o derivado de otras representaciones de sus requerimientos. Un ejemplo de son los  prototipos o especificaciones de requerimientos.

En este sentido, es cierto que la medición no depende de cómo se la aplique; sin embargo, depende de la calidad de las representaciones de los requerimientos y cuan bien se puede apartar elementos de diseño, implementación o pruebas de los requerimientos funcionales que describen el software en términos de las tareas o servicios del usuario transportados (o que se pretende transportar) para el software.

 

Sin embargo, para la solución de los problemas que surgen en el área que se destacó como área de problema en la introducción de la charla, el más común es aproximar el tamaño funcional por el uso de heurísticas como aquellas presentadas de la NESMA para quien es usuario del IFPUG. El COSMIC presenta heurísticas similares donde se puede aproximar el tamaño mismo, cuando todavia  no se puede medir.

 

Entonces, por supuesto, la aproximación de tamaño (prefiero usar el termino aproximación, porque el termino estimación es más comúnmente relacionado al esfuerzo o al plazo) depende de como se aplique. Depende de cuales heurísticas se utilizarán y de una información muy importante: Cuanto se acostumbra errar en estas aproximaciones.

En la derivación del esfuerzo, basado en la medición o en la aproximación del tamaño medido en puntos de función, hay otra variable que es la productividad. La productividad nada tiene que ver con el método de medición (o aproximación) y tiene un impacto directo en los resultados de estimaciones basadas en puntos de función.

Por ejemplo, la evaluación de los requerimientos iniciales de un proyecto llevo a una aproximación del tamaño de 200 puntos de función y la tasa de entrega en una organización A, expresada en horas-hombre por puntos de función, con 50% de probabilidad de subestimar o sobrevalorar es de 13 HH/PF. La estimación del esfuerzo en esta organización A , para este proyecto en discusión es de 2.600 HH (con 50% de probabilidad de que no se sobrevalorar).

En otra organización B, la tasa de entrega para la misma tecnología es de 10 HH/PF y la estimación del esfuerzo es de 2.000 HH (también con 50% de probabilidad de no sobrevalorar).

En resumen, el facto del método de medición de tamaño funcional es un estándar, no significa que:

a. Las estimaciones de esfuerzo o plazo sean idénticas independientemente de otras circunstancias de un proyecto que tienen efecto en la productividad;

b. La cualidad de la aproximación del tamaño o mismo de la medición depende de la cualidad de los requerimientos y del nivel de información disponible cuando de la aproximación del tamaño.

 

 

 

Pregunta 2 :

¿Qué opina de la estimación de poker para proyectos ágiles?  - Percy Calizaya

 

Respuesta:

 

En la apertura de la charla, procuré establecer dos escenarios donde se hacen las estimaciones. Uno que permite la estimación directa con éxito y otro que requiere soluciones para los mayores grados de exactitud que se exige en comparación con lo que las estimaciones directas proveen.

El Planning Poker es una variación del Delphi. Las unidades que se utilizan en el Planning Poker son típicamente Story Points o días ideales. Ambas, las dos unidades son unidades de esfuerzo. Es como pedir la estimación que se solicitó en la apertura para programación y prueba de una pequeña pieza de software. 

 

En resumen es un método adecuado para hacer estimaciones cuando ya se tiene los requerimientos funcionales identificados por lo menos en el nivel de tarea, como lo que se sugiere al identificar un caso de uso o una historia del usuario.   

 

Sin embargo, no resuelve los problemas de hacer estimaciones de proyectos completos en momentos cuando no se tiene, todavía, la información necesaria para el Planning Pocker. Sin embargo, es una mejora fantástica cuando comparada a solicitar de uno individuo por su juicio de experto en mi opinión. Otro punto que veo como excepcional el el Poker Planning es la utilización de la secuencia de Fibonacci. Esta secuencia refleja que la complejidad no es lineal y la lógica de elementos complejos son una construcción de elementos más simples en un nivel anterior.

 

 

 

Pregunta 3:

Yo quisiera saber como este tipo de estimaciones se adaptan a una metología como Scrum, ya que a veces entregar una propuesta de desarrollo para los clientes debe ser cuestión de 1 o 2 días. - Marcela Carvajal

 

Respuesta:

Hacer estimaciones de la implementación de una historia del usuario (No me refiero a algo épico) y eventuales ajustes en la arquitectura de soporte correspondientes esta (o lo debería estar) en la región donde no se tiene problemas en estimar. La opinión de expertos, métodos tales cuales el Delphi o el Planning Poker producen estimaciones con un nivel de exactitud compatible con las exigencias.

 

La segunda respuesta sobre la aplicación de los temas de la charla en el desarrollo ágil, es hacer estimaciones antes que se ha completado el Product Backlog. Hay trabajo para generarlo y este no solo se puede estimar sino es una necesidad para el establecimiento de objetivos razonables.

Todo empieza con una idea de negocio. Hay que se evolucionarla hasta que el nivel de información permita a la administración decidir por la implementación de la idea. Una nueva evolución es necesaria para que un Product Backlog este disponible. Cuando se empieza el primer Sprint, es seguro que hay ítems en el Product Backlog más cerca de un hecho épico que de una historia del usuario. En todo esta jornada de descubrimiento, las estimaciones tal cual las presentan, son necesarias para soportar decisiones informadas y conscientes de los riesgos.

 

 

EXPOSITOR

 

 

 

Carlos Eduardo Vazquez Profesional en TI con más de 20 años de experiencia en el desarrollo, mantenimiento y gestión de software de aplicación y de sistemas, direccionando la tecnología a las necesidades organizacionales. Tiene la visión de que las tecnologías de medición de software y medición del tamaño funcional en particular (con Puntos de Función definidos por el IFPUG, NESMA o COSMIC) son herramientas fundamentales para alcanzar objetivos empresariales. Desde 1991, es usuario del Análisis de Puntos de Función del IFPUG; ha entrenado cientos de profesionales desde 1993. En 1996, fue uno de los primeros brasileros certificados como Experto Certificado en Puntos de Función (CFPS) por el IFPUG - Organización de la cual es miembro con derecho a voto. De igual forma, en 2012 se convierte en pionero como titular en la certificación COSMIC. 

 

 

 

 

 

.

 

.