Una estimación de proyectos de software puede tener diversos fines, analizar la viabilidad económica de un proyecto, elaborar una propuesta de servicios, determinar con exactitud el presupuesto de un proyecto luego que ha sido aprobado, determinar el precio de un software, entre otros. Dependiendo del grado de exactitud que necesitemos, aplicaremos un método u otro.
Existen diversas técnicas de estimación de software, las que utilizan el juicio de experto, analogías por medio de comparación con proyectos anteriores y también están los modelos de estimación de proyectos de software como COCOMO II, análisis de puntos de función y COSMIC. En este artículo te presentamos 10 técnicas de estimación de software.
Tu prestigio en proyectos de software depende que cumplas las fechas y costos que comprometes. No lo dejes al azar, inscríbete en el curso Estimación de proyectos de software🚀💼📊 en Udemy para no volver a fallar en una estimación de software.
Una estimación de software es una predicción de cuánto tiempo durará o costará su desarrollo y mantenimiento. Si se trata de una estimación de tiempo, el esfuerzo puede expresarse en horas-persona u otra unidad, si se trata de estimación de costo, se puede expresar en la moneda de preferencia.
El reto de elaborar estimaciones de software, es realizar predicciones realistas, basándose en información incompleta e incierta.
En Ingeniería de software y gestión de proyectos de software, las estimaciones se utilizan para:
Las técnicas de estimación de proyectos de software se pueden clasificar en cuatro tipos:
Los métodos de estimación de software por juicio de experto, consisten entregar la información de levantamiento de requisitos de software (por ejemplo las minutas de reunión o documento de especificación de requisitos de software) y entregárselo a uno o varios conocedores del desarrollo de software y del área de negocio que se dispone representar en el nuevo sistema.
Este tipo de estimación de proyectos de software consiste en comparar el desarrollo de software propuesto con proyectos previos similares. La ventaja sobre la estimación por juicio experto, es que la analogía se basa en experiencias que están documentadas, por lo cual esta se basa en números documentados.
Una posible desventaja es que si existe mucha variación de las tecnologías y funcionalidades de un proyecto a otro será más difícil establecer estimaciones confiables.
Consiste en realizar una descomposición de proyecto en componentes, y estos a su vez en subcomponentes de mayor detalle. Este tipo de estimación parte del principio que dividir un problema en sus partes facilita su abordaje y análisis.
Hemos descrito los tipos de estimaciones de software en los que se pueden clasificar las distintas técnicas.
En lo que sigue del artículo, explicaremos las siguientes técnicas de estimación:
Posiblemente el juicio de experto sea la forma más común utilizada por muchos para obtener un estimado, ¿Parece fácil no? Simplemente consigue un experto con experiencia directa en el software que quieres desarrollar y su modelo de negocio, pásale los requerimientos de software y ve que te dice.
Claro está, debes asegurarte que todos tengan un mismo entendimiento de cómo debe funcionar el software a desarrollar y que se espera de él. También otro reto que las personas que van a hacer el estimado sean las que vayan a hacer el proyecto.
Las técnicas de estimación mediante juicio de experto consideran siempre algún tipo de descomposición funcional del software en sus partes.
Una vez que el experto o grupo de expertos ha dividido el problema en actividades, pueden proceder a asignar un estimado a cada una, por medio de las siguientes técnicas.
En esta técnica se asigna únicamente un solo estimado a cada actividad, usualmente por una sola persona. Una vez que se tienen los estimados de cada actividad, se puede calcular la duración total.
Esta es una de las técnicas más usadas, sin embargo tiene dos problemas, primero el estimado está altamente influenciado por el sesgo y las premisas del estimado. ¿Qué sucede si alguna pieza clave de información es omitida? ¿O algún aspecto no es considerado? Además, el estimado también podría “inflar” sus estimados.
¿Qué sucedería si en lugar de pedir un estimado como en el caso anterior pedimos 3 estimados? Más allá, ¿Qué opinarías si entregamos la especificación a tres expertos diferentes y vemos los estimados de cada uno?
Si tenemos tres estimados podemos asignar a cada actividad una estimación pesimista, más probable y optimista, luego podemos determinar el estimado de la actividad por medio de una formula.
La estimación de tres puntos no es campo exclusivo de la Ingeniería del software, de hecho el Project Management Institute (PMI) la describe en su guía del PMBOK 6 como un método de estimación. Siguiendo el estándar del PMI, la siguiente formula se usa para estimar la duración de una actividad:
Wideband Delphi es una técnica de estimación de software en la que interviene un grupo de expertos. A diferencia de otras técnicas de estimación por juicio de expertos, los integrantes del grupo no tienen comunicación entre sí mientras están elaborando sus estimados, y se los entregan unicamente a un coordinador.
El método Delphi data de los años 40, en el, varios expertos creaban las estimaciones individualmente y luego se reunian para ponerse de acuerdo. En los años 70, un estudio mostró que el método no estaba produciendo mejores resultados que estimaciones individuales, debido a las presiones políticas y dinámica de grupo. Fue por esto que Boehm y Farquhar desarrollaron el método Wideband Delphi, que reduce las discusiones y debates.
Para realizar una estimación Wideband Delphi se siguen los siguientes pasos:
Como puedes observar el hecho que los estimadores elaboren sus estimados sin comunicarse entre sí y que el voto en la estimación final sea anónimo elimina el sesgo de dinámica grupal, con lo que se busca obtener estimados más realistas.
La estimación por analogía tiene como premisa que la organización debe contar con una base de datos en la cual se registre la información necesaria sobre las características, duración real y costo real de proyectos previos.
El reto de este método de estimación es el tener una base de datos lo suficientemente detallada que permita identificar las características de los proyectos y determinar si son comparables con el proyecto a estimar. Además, para una organización de constante innovación o muchos proyectos disimiles, puede ser un reto el aplicar este método.
Su aplicación es factible si se están elaborando estimados de baja exactitud y alta incertidumbre, es decir si se tienen tolerancia de desviación respecto al estimado de 50% o más. También es más fácil su aplicación si la organización ejecuta proyectos similares y comparables entre sí.
Estimación de software mediante descomposición.
Mediante una estructura de desglose de trabajo (EDT) de alto nivel, compaginada con datos que tengamos de proyectos previos, podemos hacer estimados para cada elemento de trabajo para determinar un esfuerzo y costo de forma general.
El método Top-Down no emplea análisis detallado, por lo tanto es mejor utilizarla solamente cuando necesitamos un primer estimado para evaluar la viabilidad de proyectos, pero no recomendable si necesitamos estimaciones o costos detallados para determinar por ejemplo un presupuesto.
Para aplicar este método, se necesita una estructura de desglose de trabajo (EDT) detallada, lo cual en Ingeniería de software implicaría prácticamente realizar todo el análisis y diseño de la solución. Por ende, es una técnica mejor empleada en proyectos que ya te han aprobado y que cuentas con presupuesto para todo el análisis que requiere realizar este tipo de estimación.
Cada tarea de la EDT se estima individualmente, para luego ir agregando los estimados y tener números de mayor nivel. Al aplicar esta técnica obtendrás estimados de mayor exactitud que con el método Top-Down, sin embargo la inversión de tiempo es mayor.
La principal diferencia entre las técnicas de descomposición y las técnicas de juicio experto vistas anteriormente es el análisis detallado del proyecto que estas implican.
Para el caso de técnicas de juicio experto, si bien cada experto puede realizar un desglose de tareas en su análisis individual, la técnica no lo requiere (aunque es recomendable).
Por otro lado, las técnicas de descomposición establecen formalmente la necesidad de analizar y diseñar la solución, en el caso de Bottom-Up, se requieren detalles que solamente se pueden lograr después que te has comprometido en el proyecto y cuentas con presupuesto y un equipo de trabajo asignado.
Sin embargo, las técnicas de descomposición aún requieren que alguien (un experto) estime cada paquete de trabajo, lo que conlleva la posible aplicación de estándares disimiles entre un estimado u otro, así como sesgo, o que el estimador sea muy optimista y pesimista.
Veremos a continuación una serie de métodos que buscan evitar esta situación.
Los modelos de estimación buscan producir estimaciones de proyectos de software a partir de fórmulas matemáticas que puedan aplicarse de igual manera de un proyecto a otro, trayendo como beneficio que todos los proyectos sean evaluados objetivamente, además, producen estimados exactos que se pueden desglosar y analizar en partes, por ejemplo analizando el esfuerzo y costo de alguna funcionalidad especifica o módulo de software.
Veamos a continuación algunas técnicas que usan modelos de estimación de proyectos de software.
Las siglas COCOMO significan Constructive Cost Model, o “Modelo constructivo de costos” en español (COCOMO II). El método COCOMO fue desarrollado originalmente por el Dr. Barry Boehm en 1981. Luego en los años 90 se realizó una actualización y a partir de 1995 se conoce como COCOMO II.
COCOMO II está documentado en el Manual COCOMO II, disponible en el sitio web de la Universidad del Sur de California (University of Southern California).
Para realizar estimaciones de proyectos de software, COCOMO II utiliza tres submodelos, cada uno con mayor nivel de fidelidad que el anterior, estos modelos son:
El Modelo de composición de aplicaciones se utiliza para analizar el software a desarrollar y modificar, identificando componentes, subcomponentes, dividiéndolos y clasificándolos. Los modelos de diseño inicial y post arquitectura son los que producen la estimación, ambos utilizan las siguientes ecuaciones:
donde:
a, b: Constantes con valores asignados según el modelo que se esté utilizando (Diseño inicial o post arquitectura).
Kl: Líneas de código (em miles).
m (X): Multiplicador que depende de 15 atributos.
donde:
c, d: Constantes con valores asignados según el modelo que se esté utilizando (Diseño inicial o post arquitectura).
E: Esfuerzo requerido (Calculado con la primera ecuación)
La variable clave para lograr una estimación acertada en el modelo, es la de medición del tamaño del software a desarrollar. Para la medición del tamaño, COCOMO propone dos enfoques, el conteo de líneas de código y el conteo de puntos de función.
El mayor reto es poder calcular cuantas líneas de código tendrá un proyecto que aún no hemos realizado, COCOMO II propone el uso de datos históricos que se tengan de proyectos pasados.
Si no se tienen datos históricos, se puede recurrir a la opinión de expertos (técnica explicada en el numeral 1) solo para obtener una medición de líneas de código, siendo recomendable tener 3 estimaciones, una pesimista, más probable y optimista (3 puntos).
Como se puede ver, COCOMO II también se vale del juicio de expertos, sin embargo, tener una fórmula matemática probada para establecer una correlación entre las líneas de código probables y el esfuerzo requerido es mejor que simplemente valernos de la opinión del estimador.
La estimación de costos por puntos de función se basa en la cantidad de funcionalidad involucrada en el software a desarrollar, son útiles porque se basan en información que está disponible desde que se realiza el análisis del proyecto.
Los puntos de función no ajustados miden un proyecto de software por medio de la cuantificación de las funcionalidades de procesamiento de información, clasificando las mismas en Entradas o salidas de datos, archivos lógicos internos o externos. Para cada uno se asigna una cantidad predeterminada de puntos de función, que nos aporta una medición funcional del software.
COCOMO II sigue las mismas definiciones el método de puntos de función IFPUG, el cual veremos en más detalle en la siguiente técnica de estimación de proyectos de software.
Si bien el Análisis de puntos de función puede utilizarse conjuntamente con COCOMO II, el método puede funcionar por sí solo como técnica para estimación de proyectos de software.
Fue desarrollado originalmente por Allan Albrecht en 1979 mientras trabajaba para IBM, quien definió conceptos para medir el software a partir de valoraciones de funcionalidades entregadas al usuario y no a partir de aspectos técnicos, con la intención de producir valoraciones independientes de la tecnología y fases del ciclo de vida utilizado.
El trabajo de Albrecht fue continuado por el grupo internacional de usuarios de puntos de función, quienes plasmaron sus conceptos en el método IFPUG-FPA.
IFPUG-FPA realiza las valoraciones a partir de la funcionalidad del sistema, primero clasificándolas, luego asignando una complejidad y ponderación a cada una según unas tablas predefinidas, determinando así el valor de puntos de función.
Para mayor información del método, te recomendamos nuestra serie de artículos sobre el método de puntos de función del IFPUG:
> Introducción a la estimación de proyectos de software por puntos de función
> Determinar tipo de conteo y componentes funcionales
> Cálculo de los puntos de función no ajustados
Una vez determinado el tamaño de un software en puntos de función, debemos conseguir una medida de productividad, es decir, determinar cuántos puntos de función puede desarrollar nuestro equipo de trabajo en un tiempo determinado. Al conocer esto, podremos determinar cuántas horas hombre tomará el proyecto y con ello el costo.
Aquí te compartimos un ejemplo de cómo estimar costos de software utilizando puntos de función:
> Ejemplos de estimación de costos de un proyecto de software
COSMIC es un método de análisis de puntos de función de segunda generación, en el cual se determina el tamaño funcional del software a partir del número de interacciones entre los procesos funcionales.
El método IFPUG (previo a COSMIC) depende de los “tipos de funciones” definidos por Albrecht, los cuales eran adecuados para la década de los 70, pero se ha hecho difícil asignárselos a formas modernas de modelar los requerimientos de software, como por ejemplo cuando el software se construye como servicios (SOA) y en áreas como el software de tiempo real o de infraestructura.
Para los años 90 la industria estaba demandando un método de análisis de puntos de función estándar, sin embargo, no existía acuerdo para seleccionar alguno de los métodos de medición que existían.
El principal cambio de COSMIC frente a IFPUG, es que en lugar de clasificar las funcionalidades y asignar una cantidad predeterminada de puntos de función a cada tipo, se enfoca en contar las interacciones entre funcionalidades y de estas con archivos de datos.
Por ejemplo, si una funcionalidad del tipo entrada de datos, tiene dos procesos de entrada de datos, uno de escritura de esos datos en la base de datos y otro de consulta a otra funcionalidad vía interfaz (webservice), esto cuenta por 4 interacciones.
Para saber más sobre el método COSMIC, te recomendamos el siguiente artículo:
> Medición y estimación: Método COSMIC
Los pasos para realizar una medición bajo COSMIC son:
COSMIC tiene la ventaja de no establecer límites arbitrarios al tamaño funcional, así puede medir componentes de software muy grandes o pequeños. Adicionalmente, está basado en el desglose funcional de los componentes de software, alineado con las prácticas de Ingeniería de software.
> Ejemplos de estimación de costos de un proyecto de software
Planning Poker es una técnica de estimación utilizada en proyectos ejecutados con metodologías ágiles, como por ejemplo Scrum. Es una técnica para medir los elementos de pila de producto (Product Backlog) en un proyecto ágil, que no son más que el trabajo a realizar para desarrollar el software desglosado en componentes del software, funcionalidades especificas, en inclusive partes de funcionalidades.
Una de las mejors explicaciones de Planning Poker que hemos leído la podemos encontrar en la obra Essential Scrum. A Practical Guide to the Most Popular Agile Process - Kenneth S. Rubin
. La recomendamos ampliamente.
También te recomendamos leer nuestros artículos sobre el Product Backlog antes de continuar:
> Plantilla de Product Backlog
> 11 Reglas para administrar el Product Backlog
Planning Poker es una técnica de juicio de expertos (vistas anteriormente) pero se basa en el consenso. Los expertos, integrantes del equipo de desarrollo (por lo que serán quienes realizaran el trabajo) entablan una discusión para exponer las premisas y adquirir un entendimiento compartido de cada elemento del Product Backlog que se dispongan a estimar.
Los estimados que produce Planning Poker no son en medidas absolutas, en su lugar son medidas relativas, en la que los elementos de tamaño similar son agrupados.
Escala de estimación
La escala de estimación más frecuentemente utilizada en Planning Poker es la propuesta por Mike Cohn, basada en parte en la secuencia de numeros Fibonacci. La secuencia es: 1, 2, 3, 5, 8, 13, 20, 40 y 100.
Cuando se utiliza esta técnica, los elementos de software (funcionalidades del Product Backlog) se agrupan por tamaño y a cada grupo se le asigna el mismo número en la escala.
Cuando se le va a asignar a un elemento del Backlog un tamaño, es necesario compararlo con los otros elementos que ya se encuentran en esa misma escala, si los expertos juzgan que coinciden le asignarán esa escala, mientras que si no deberían buscar en otro de los tamaños.
Como se juega al Planning Poker
¿Cuáles métodos aplicas en tu trabajo y empresa para elaborar estimaciones de software? ¿Utilizas el juicio experto o te basas en modelos numéricos de estimación? ¿Cuáles ventajas y desventajas ves en cada método? Déjanos tus comentarios.
Crump, K. 5 Methods of Project Estimation
Garzas, J. Estimación de software, una breve introducción
OBS Business School. 12 técnicas para la estimación de costes en proyectos
University of Southern California. COCOMO II
Wikipedia. Software development effort estimation
Una estimación de software es una predicción de cuánto tiempo durará o costará su desarrollo y mantenimiento. Si se trata de una estimación de tiempo, el esfuerzo puede expresarse en horas-persona u otra unidad, si se trata de estimación de costo, se puede expresar en la moneda de preferencia.
El reto de elaborar estimaciones de software, es realizar predicciones realistas, basándose en información incompleta e incierta.
En Ingeniería de software y gestión de proyectos de software, las estimaciones se utilizan para:
- Desarrollar planes de proyectos.
- Elaborar planificaciones de iteración en desarrollo de software.
- Elaborar presupuestos.
- Realizar análisis de inversión.
- Fijación de precios de un software para un cliente empresarial.
- Análisis para determinar el precio en software dirigido al consumidor.
- Para planificar estrategia cuando se dispone a participar en subastas de contratos en los que participan varios proveedores.
Tipos de estimación de software
Las técnicas de estimación de proyectos de software se pueden clasificar en cuatro tipos:
Estimación de software por juicio de expertos
Los métodos de estimación de software por juicio de experto, consisten entregar la información de levantamiento de requisitos de software (por ejemplo las minutas de reunión o documento de especificación de requisitos de software) y entregárselo a uno o varios conocedores del desarrollo de software y del área de negocio que se dispone representar en el nuevo sistema.
Estimación de software por analogía
Este tipo de estimación de proyectos de software consiste en comparar el desarrollo de software propuesto con proyectos previos similares. La ventaja sobre la estimación por juicio experto, es que la analogía se basa en experiencias que están documentadas, por lo cual esta se basa en números documentados.
Una posible desventaja es que si existe mucha variación de las tecnologías y funcionalidades de un proyecto a otro será más difícil establecer estimaciones confiables.
Estimación de software por descomposición
Consiste en realizar una descomposición de proyecto en componentes, y estos a su vez en subcomponentes de mayor detalle. Este tipo de estimación parte del principio que dividir un problema en sus partes facilita su abordaje y análisis.
Los estimados sobre componentes más pequeños tendrían un mejor nivel de exactitud que los componentes grandes, permitiendo identificar y depurar la falta de información que pudiera afectar el estimado.
Comprende la utilización de modelos paramétricos, procedimentales, algorítmicos o de otra índole para realizar las estimaciones de software. La ventaja de estos métodos es que al tener una base numérica tienden a reducir el sesgo asociado con el juicio de un estimador al realizar las estimaciones.
Estimación de software por medio de modelos de estimación
Comprende la utilización de modelos paramétricos, procedimentales, algorítmicos o de otra índole para realizar las estimaciones de software. La ventaja de estos métodos es que al tener una base numérica tienden a reducir el sesgo asociado con el juicio de un estimador al realizar las estimaciones.
Un ejemplo de estimación por modelo es COCOMO, en el cual se utiliza una fórmula de regresión lineal aplicada a datos históricos de proyectos anteriores, produciendo los estimados mediante esta función de estimación.
Otro ejemplo es el análisis de puntos de función, bajo este método, se aplica una clasificación estándar a los componentes de software, luego se asignan cantidades determinadas de puntos de función de acuerdo a sus características, obteniendo una medición de su tamaño.
A diferencia de otros tipos de estimación de software, los modelos de estimación producen estimados que están basados en fórmulas matemáticas y estadísticas.
Otro ejemplo es el análisis de puntos de función, bajo este método, se aplica una clasificación estándar a los componentes de software, luego se asignan cantidades determinadas de puntos de función de acuerdo a sus características, obteniendo una medición de su tamaño.
A diferencia de otros tipos de estimación de software, los modelos de estimación producen estimados que están basados en fórmulas matemáticas y estadísticas.
Domina los costos y fechas de tu proyecto
Curso: Estimación de proyectos de software
Aprende a prever costos y plazos con precisión. Esfuerzo y tamaño bajo control: Domina la estimación y planificación de tu desarrollo de software.
10 Técnicas de estimación de software
Hemos descrito los tipos de estimaciones de software en los que se pueden clasificar las distintas técnicas.
En lo que sigue del artículo, explicaremos las siguientes técnicas de estimación:
- Juicio de expertos:
- 1 solo punto.
- 3 puntos.
- Método Wideband Delphi.
- Estimación por analogía.
- Descomposición:
- Top down.
- Bottom up.
- Modelos de estimación de proyectos de software:
- COCOMO II.
- Estimación de proyectos ágiles por medio de Planning Poker.
Estimación mediante juicio de expertos
Posiblemente el juicio de experto sea la forma más común utilizada por muchos para obtener un estimado, ¿Parece fácil no? Simplemente consigue un experto con experiencia directa en el software que quieres desarrollar y su modelo de negocio, pásale los requerimientos de software y ve que te dice.
Claro está, debes asegurarte que todos tengan un mismo entendimiento de cómo debe funcionar el software a desarrollar y que se espera de él. También otro reto que las personas que van a hacer el estimado sean las que vayan a hacer el proyecto.
Las técnicas de estimación mediante juicio de experto consideran siempre algún tipo de descomposición funcional del software en sus partes.
Una vez que el experto o grupo de expertos ha dividido el problema en actividades, pueden proceder a asignar un estimado a cada una, por medio de las siguientes técnicas.
1.- Un solo punto
En esta técnica se asigna únicamente un solo estimado a cada actividad, usualmente por una sola persona. Una vez que se tienen los estimados de cada actividad, se puede calcular la duración total.
Esta es una de las técnicas más usadas, sin embargo tiene dos problemas, primero el estimado está altamente influenciado por el sesgo y las premisas del estimado. ¿Qué sucede si alguna pieza clave de información es omitida? ¿O algún aspecto no es considerado? Además, el estimado también podría “inflar” sus estimados.
2.- Tres puntos
¿Qué sucedería si en lugar de pedir un estimado como en el caso anterior pedimos 3 estimados? Más allá, ¿Qué opinarías si entregamos la especificación a tres expertos diferentes y vemos los estimados de cada uno?
Si tenemos tres estimados podemos asignar a cada actividad una estimación pesimista, más probable y optimista, luego podemos determinar el estimado de la actividad por medio de una formula.
La estimación de tres puntos no es campo exclusivo de la Ingeniería del software, de hecho el Project Management Institute (PMI) la describe en su guía del PMBOK 6 como un método de estimación. Siguiendo el estándar del PMI, la siguiente formula se usa para estimar la duración de una actividad:
Duración esperada = (Pesimista + (4 x Más probable) + Optimista) / 6
Desviación estándar de la actividad: (Pesimista – Optimista) / 6
3.- Método Wideband Delphi
 |
| Imagen obtenida de: Tutorials Point |
Wideband Delphi es una técnica de estimación de software en la que interviene un grupo de expertos. A diferencia de otras técnicas de estimación por juicio de expertos, los integrantes del grupo no tienen comunicación entre sí mientras están elaborando sus estimados, y se los entregan unicamente a un coordinador.
El método Delphi data de los años 40, en el, varios expertos creaban las estimaciones individualmente y luego se reunian para ponerse de acuerdo. En los años 70, un estudio mostró que el método no estaba produciendo mejores resultados que estimaciones individuales, debido a las presiones políticas y dinámica de grupo. Fue por esto que Boehm y Farquhar desarrollaron el método Wideband Delphi, que reduce las discusiones y debates.
Para realizar una estimación Wideband Delphi se siguen los siguientes pasos:
- Un coordinador presenta a cada experto una especificación de software y el formulario de estimación.
- Cada experto trabaja individualmente en su estimación.
- Se sostiene una reunión en la cual los expertos hablan sobre posibles problemas en sus estimaciones, de esta manera cada experto proporciona Feedback a los demás sin influir directamente en el estimado final que producirá.
- Cada experto prepara un formulario de estimación y se los presenta al coordinador de forma anónima.
- El coordinador prepara un resumen y lo distribuye al grupo de expertos.
- El coordinador y los expertos se reúnen, viendo las variaciones en las estimaciones. También producen una estimación media.
- Los expertos votan de forma anónima si aceptan la estimación media. El voto debe ser unánime, si alguien vota que no se debe regresar al paso 3, es decir, el grupo debe discutir nuevamente los problemas en sus estimaciones, para luego elaborar nuevos estimados.
Como puedes observar el hecho que los estimadores elaboren sus estimados sin comunicarse entre sí y que el voto en la estimación final sea anónimo elimina el sesgo de dinámica grupal, con lo que se busca obtener estimados más realistas.
Estimación por analogía
4.- Métodos de estimación de software por analogía
La estimación por analogía tiene como premisa que la organización debe contar con una base de datos en la cual se registre la información necesaria sobre las características, duración real y costo real de proyectos previos.
El reto de este método de estimación es el tener una base de datos lo suficientemente detallada que permita identificar las características de los proyectos y determinar si son comparables con el proyecto a estimar. Además, para una organización de constante innovación o muchos proyectos disimiles, puede ser un reto el aplicar este método.
Su aplicación es factible si se están elaborando estimados de baja exactitud y alta incertidumbre, es decir si se tienen tolerancia de desviación respecto al estimado de 50% o más. También es más fácil su aplicación si la organización ejecuta proyectos similares y comparables entre sí.
Estimación de software mediante descomposición.
5.- Descomposición Top-Down
Mediante una estructura de desglose de trabajo (EDT) de alto nivel, compaginada con datos que tengamos de proyectos previos, podemos hacer estimados para cada elemento de trabajo para determinar un esfuerzo y costo de forma general.
El método Top-Down no emplea análisis detallado, por lo tanto es mejor utilizarla solamente cuando necesitamos un primer estimado para evaluar la viabilidad de proyectos, pero no recomendable si necesitamos estimaciones o costos detallados para determinar por ejemplo un presupuesto.
6.- Descomposición Bottom-Up
Cada tarea de la EDT se estima individualmente, para luego ir agregando los estimados y tener números de mayor nivel. Al aplicar esta técnica obtendrás estimados de mayor exactitud que con el método Top-Down, sin embargo la inversión de tiempo es mayor.
Lectura recomendada
Guía Práctica de Estimación y Medición de Proyectos Software: ¿Por qué?, ¿Para qué? y ¿Cómo? (En Español)
Técnicas que hemos visto hasta ahora
La principal diferencia entre las técnicas de descomposición y las técnicas de juicio experto vistas anteriormente es el análisis detallado del proyecto que estas implican.
Para el caso de técnicas de juicio experto, si bien cada experto puede realizar un desglose de tareas en su análisis individual, la técnica no lo requiere (aunque es recomendable).
Por otro lado, las técnicas de descomposición establecen formalmente la necesidad de analizar y diseñar la solución, en el caso de Bottom-Up, se requieren detalles que solamente se pueden lograr después que te has comprometido en el proyecto y cuentas con presupuesto y un equipo de trabajo asignado.
Sin embargo, las técnicas de descomposición aún requieren que alguien (un experto) estime cada paquete de trabajo, lo que conlleva la posible aplicación de estándares disimiles entre un estimado u otro, así como sesgo, o que el estimador sea muy optimista y pesimista.
Veremos a continuación una serie de métodos que buscan evitar esta situación.
Técnicas basadas en modelos de estimación de proyectos de software
Los modelos de estimación buscan producir estimaciones de proyectos de software a partir de fórmulas matemáticas que puedan aplicarse de igual manera de un proyecto a otro, trayendo como beneficio que todos los proyectos sean evaluados objetivamente, además, producen estimados exactos que se pueden desglosar y analizar en partes, por ejemplo analizando el esfuerzo y costo de alguna funcionalidad especifica o módulo de software.
Veamos a continuación algunas técnicas que usan modelos de estimación de proyectos de software.
7.- COCOMO II
Las siglas COCOMO significan Constructive Cost Model, o “Modelo constructivo de costos” en español (COCOMO II). El método COCOMO fue desarrollado originalmente por el Dr. Barry Boehm en 1981. Luego en los años 90 se realizó una actualización y a partir de 1995 se conoce como COCOMO II.
COCOMO II está documentado en el Manual COCOMO II, disponible en el sitio web de la Universidad del Sur de California (University of Southern California).
Para realizar estimaciones de proyectos de software, COCOMO II utiliza tres submodelos, cada uno con mayor nivel de fidelidad que el anterior, estos modelos son:
- Composición de aplicaciones.
- Diseño inicial (Diseño temprano).
- Modelos post arquitectura.
El Modelo de composición de aplicaciones se utiliza para analizar el software a desarrollar y modificar, identificando componentes, subcomponentes, dividiéndolos y clasificándolos. Los modelos de diseño inicial y post arquitectura son los que producen la estimación, ambos utilizan las siguientes ecuaciones:
Esfuerzo expresado en personas meses (E)= a (Kl)^b x m (X)
donde:
a, b: Constantes con valores asignados según el modelo que se esté utilizando (Diseño inicial o post arquitectura).
Kl: Líneas de código (em miles).
m (X): Multiplicador que depende de 15 atributos.
Tiempo (Calendario) del proyecto (Tdev) = c (E)^d
c, d: Constantes con valores asignados según el modelo que se esté utilizando (Diseño inicial o post arquitectura).
E: Esfuerzo requerido (Calculado con la primera ecuación)
Número de personas requeridas en el equipo (P) = E / Tdev
La variable clave para lograr una estimación acertada en el modelo, es la de medición del tamaño del software a desarrollar. Para la medición del tamaño, COCOMO propone dos enfoques, el conteo de líneas de código y el conteo de puntos de función.
COCOMO II con conteo de líneas de código
El mayor reto es poder calcular cuantas líneas de código tendrá un proyecto que aún no hemos realizado, COCOMO II propone el uso de datos históricos que se tengan de proyectos pasados.
Si no se tienen datos históricos, se puede recurrir a la opinión de expertos (técnica explicada en el numeral 1) solo para obtener una medición de líneas de código, siendo recomendable tener 3 estimaciones, una pesimista, más probable y optimista (3 puntos).
Como se puede ver, COCOMO II también se vale del juicio de expertos, sin embargo, tener una fórmula matemática probada para establecer una correlación entre las líneas de código probables y el esfuerzo requerido es mejor que simplemente valernos de la opinión del estimador.
COCOMO II con puntos de función
La estimación de costos por puntos de función se basa en la cantidad de funcionalidad involucrada en el software a desarrollar, son útiles porque se basan en información que está disponible desde que se realiza el análisis del proyecto.
Los puntos de función no ajustados miden un proyecto de software por medio de la cuantificación de las funcionalidades de procesamiento de información, clasificando las mismas en Entradas o salidas de datos, archivos lógicos internos o externos. Para cada uno se asigna una cantidad predeterminada de puntos de función, que nos aporta una medición funcional del software.
COCOMO II sigue las mismas definiciones el método de puntos de función IFPUG, el cual veremos en más detalle en la siguiente técnica de estimación de proyectos de software.
8.- Puntos de función IFPUG
Si bien el Análisis de puntos de función puede utilizarse conjuntamente con COCOMO II, el método puede funcionar por sí solo como técnica para estimación de proyectos de software.
Fue desarrollado originalmente por Allan Albrecht en 1979 mientras trabajaba para IBM, quien definió conceptos para medir el software a partir de valoraciones de funcionalidades entregadas al usuario y no a partir de aspectos técnicos, con la intención de producir valoraciones independientes de la tecnología y fases del ciclo de vida utilizado.
El trabajo de Albrecht fue continuado por el grupo internacional de usuarios de puntos de función, quienes plasmaron sus conceptos en el método IFPUG-FPA.
IFPUG-FPA realiza las valoraciones a partir de la funcionalidad del sistema, primero clasificándolas, luego asignando una complejidad y ponderación a cada una según unas tablas predefinidas, determinando así el valor de puntos de función.
Para mayor información del método, te recomendamos nuestra serie de artículos sobre el método de puntos de función del IFPUG:
> Introducción a la estimación de proyectos de software por puntos de función
> Determinar tipo de conteo y componentes funcionales
> Cálculo de los puntos de función no ajustados
Una vez determinado el tamaño de un software en puntos de función, debemos conseguir una medida de productividad, es decir, determinar cuántos puntos de función puede desarrollar nuestro equipo de trabajo en un tiempo determinado. Al conocer esto, podremos determinar cuántas horas hombre tomará el proyecto y con ello el costo.
Aquí te compartimos un ejemplo de cómo estimar costos de software utilizando puntos de función:
> Ejemplos de estimación de costos de un proyecto de software
9.- Puntos de función COSMIC
COSMIC es un método de análisis de puntos de función de segunda generación, en el cual se determina el tamaño funcional del software a partir del número de interacciones entre los procesos funcionales.
El método IFPUG (previo a COSMIC) depende de los “tipos de funciones” definidos por Albrecht, los cuales eran adecuados para la década de los 70, pero se ha hecho difícil asignárselos a formas modernas de modelar los requerimientos de software, como por ejemplo cuando el software se construye como servicios (SOA) y en áreas como el software de tiempo real o de infraestructura.
Para los años 90 la industria estaba demandando un método de análisis de puntos de función estándar, sin embargo, no existía acuerdo para seleccionar alguno de los métodos de medición que existían.
El principal cambio de COSMIC frente a IFPUG, es que en lugar de clasificar las funcionalidades y asignar una cantidad predeterminada de puntos de función a cada tipo, se enfoca en contar las interacciones entre funcionalidades y de estas con archivos de datos.
Por ejemplo, si una funcionalidad del tipo entrada de datos, tiene dos procesos de entrada de datos, uno de escritura de esos datos en la base de datos y otro de consulta a otra funcionalidad vía interfaz (webservice), esto cuenta por 4 interacciones.
Para saber más sobre el método COSMIC, te recomendamos el siguiente artículo:
> Medición y estimación: Método COSMIC
Los pasos para realizar una medición bajo COSMIC son:
- Fase 1: Estrategia de medición.
- Fase 2: Mapeo.
- Fase 3: Medición.
COSMIC tiene la ventaja de no establecer límites arbitrarios al tamaño funcional, así puede medir componentes de software muy grandes o pequeños. Adicionalmente, está basado en el desglose funcional de los componentes de software, alineado con las prácticas de Ingeniería de software.
En el siguiente enlace, te compartimos un ejemplo de como estimar costos de software con COSMIC:
Métodos de estimación de software ágiles
10.- Planning Poker
 |
| Imagen de: Thoughts from a Thirsty Bear |
Planning Poker es una técnica de estimación utilizada en proyectos ejecutados con metodologías ágiles, como por ejemplo Scrum. Es una técnica para medir los elementos de pila de producto (Product Backlog) en un proyecto ágil, que no son más que el trabajo a realizar para desarrollar el software desglosado en componentes del software, funcionalidades especificas, en inclusive partes de funcionalidades.
Una de las mejors explicaciones de Planning Poker que hemos leído la podemos encontrar en la obra Essential Scrum. A Practical Guide to the Most Popular Agile Process - Kenneth S. Rubin
. La recomendamos ampliamente.También te recomendamos leer nuestros artículos sobre el Product Backlog antes de continuar:
> Plantilla de Product Backlog
> 11 Reglas para administrar el Product Backlog
Planning Poker es una técnica de juicio de expertos (vistas anteriormente) pero se basa en el consenso. Los expertos, integrantes del equipo de desarrollo (por lo que serán quienes realizaran el trabajo) entablan una discusión para exponer las premisas y adquirir un entendimiento compartido de cada elemento del Product Backlog que se dispongan a estimar.
Los estimados que produce Planning Poker no son en medidas absolutas, en su lugar son medidas relativas, en la que los elementos de tamaño similar son agrupados.
Escala de estimación
La escala de estimación más frecuentemente utilizada en Planning Poker es la propuesta por Mike Cohn, basada en parte en la secuencia de numeros Fibonacci. La secuencia es: 1, 2, 3, 5, 8, 13, 20, 40 y 100.
Cuando se utiliza esta técnica, los elementos de software (funcionalidades del Product Backlog) se agrupan por tamaño y a cada grupo se le asigna el mismo número en la escala.
Cuando se le va a asignar a un elemento del Backlog un tamaño, es necesario compararlo con los otros elementos que ya se encuentran en esa misma escala, si los expertos juzgan que coinciden le asignarán esa escala, mientras que si no deberían buscar en otro de los tamaños.
Como se juega al Planning Poker
- Todo el equipo ágil participa en la sesión. Cada integrante recibe un manojo de cartas de Planning Poker.
- El dueño de producto (Product Owner) presenta el elemento del Product Backlog que se van a estimar.
- El equipo de desarrollo discute el elemento a estimar y realiza preguntas al dueño de producto. Este último responde a las preguntas.
- Cada estimador en privado selecciona una carta que representará su estimado.
- Se exponen simultaneamente las cartas seleccionadas por cada estimador.
- Si todos han seleccionado la misma carta, se abrá logrado el consenso. El resultado se le asigna como estimación al elemento de Product Backlog.
- Si los estimados no fueron los mismos, se realiza una discusión enfocada en exponer las premisas tomadas en cada estimación o malos entendidos. Por lo general se comienza por preguntar al estimador más alto y al más bajo que expliquen y justifiquen sus estimados.,
- Luego de la discusión se regresa al paso 3. El ciclo se repetirá hasta lograr el consenso.
¿Y qué opinas tú?
¿Cuáles métodos aplicas en tu trabajo y empresa para elaborar estimaciones de software? ¿Utilizas el juicio experto o te basas en modelos numéricos de estimación? ¿Cuáles ventajas y desventajas ves en cada método? Déjanos tus comentarios.
¿Buscas más información de gerencia informática?
Síguenos en Twitter, Facebook o Linkedin:
Referencia
Crump, K. 5 Methods of Project Estimation
Garzas, J. Estimación de software, una breve introducción
OBS Business School. 12 técnicas para la estimación de costes en proyectos
University of Southern California. COCOMO II
Wikipedia. Software development effort estimation
intersante la informacion y muy util
ResponderEliminarvery useful and detailed information, thank you
ResponderEliminar