Estimación de proyectos software
La estimación de proyectos software es una tarea muy compleja, pero de vital importancia en toda la etapa de desarrollo del software.
Introducción
editarTenemos que saber que las estimaciones que hagamos nunca serán exactas debido a la gran cantidad de variables que intervienen en su cálculo. Pero evidentemente, cuanto mejor sea la estimación que realicemos, mejor podremos maniobrar para conseguir los objetivos o mejorar la rentabilidad del proyecto.
Estimar es difícil, ya que:
- Los requisitos iniciales no están totalmente delimitados.
- Puede que necesitemos utilizar tecnologías nuevas.
- Las personas involucradas en el proyecto pueden tener distintos grados de experiencia.
Pero es muy importante partir de una estimación inicial.
Una de las actividades en la gestión de proyectos software es la estimación de costes y tiempos.
La estimación de un proyecto software requiere:
- Experiencia.
- Buena información histórica.
- Confianza en las métricas y la experiencia.
Principios básicos de estimación
editarLa estimación depende de varios factores:
- Complejidad del proyecto.
- Tamaño del proyecto.
- Estabilidad de los requisitos.
- Facilidad de identificar funciones.
- Estructura de la información.
- Disponibilidad de información histórica.
Algunos de los principios que hay que tener presentes:
- Retrasar la estimación lo máximo posible. Cuanto más se retrase, más precisa será.
- Hacer estimación por analogía. Utilizar el coste de proyectos similares.
- Ley de Parkinson. El trabajo se extiende para rellenar el tiempo disponible.
- Precio para ganar. El coste se estima en todo el dinero que el cliente puede gastar en el proyecto.
- Existen técnicas de descomposición. Estimas el coste descomponiendo el producto y/o el proceso.
- Existen modelos empíricos. Modelos de regresión que relacionan esfuerzo con tamaño o funcionalidad.
Estimación de recursos
editarLos recursos pueden estimarse como personas, componentes software reutilizables y las herramientas de hardware/software necesarios para realizar el proyecto.
Cada recurso se especifica con cuatro características (las dos últimas se denominan ventana temporal):
- Descripción.
- Informe de disponibilidad.
- Fecha cronológica en la que se requiere.
- Tiempo durante el que será aplicado.
Respecto al personal hay que especificar su posición en la organización y su especialidad.
Los componentes software, por su parte, pueden estar:
- Ya desarrollados.
- Ya experimentados.
- Con experiencia parcial.
- Nuevos.
Estimación de costes
editarPara la mayoría de los proyectos, el factor fundamental del coste es el esfuerzo. El esfuerzo es el número de personas-mes necesarias para desarrollar el proyecto. Es el factor con mayor incertidumbre, ya que se ve influenciado por factores como la motivación, la experiencia, el nivel de formación y otras características de los miembros del equipo, así como por el tamaño del mismo. Para realizar estimaciones precisas, se han desarrollado técnicas que capturan la relación entre el esfuerzo y las características del personal, los requisitos del proyecto y otros factores que puedan afectar al tiempo, esfuerzo y el coste de desarrollar un proyecto.
Técnicas de estimación de esfuerzo
editarA continuación se presentan algunas de las más conocidas técnicas de estimación.
Juicio u opinión de expertos
editarEn su forma más simple, se basa en realizar una estimación del esfuerzo a partir de la experiencia y conocimiento de otras personas.
Tablas de estimación
editarLa organización puede disponer de tablas de estimación disponibles porque han ido guardando un registro a lo largo de su historia.
Estimaciones Top-Down y Bottom-Up
editarEn la estimación top-down (de arriba a abajo) una estimación de conjunto para los costes del proyecto es extraída de las propiedades generales del producto a desarrollar. El coste total es después distribuido, repartido entre los distintos componentes. (ii)
Esta técnica (y también la bottom-up) puede ser llevada a cabo en conjunción con otro de los métodos tratados anteriormente. (ii)
Como ventajas:
- Enfoque a nivel de sistema. Debido a que la estimación se basa en la experiencia previa en proyectos completados, tendrá en cuenta todos los subsistemas a implementar del proyecto.
Como inconvenientes:
- No suele identificar problemas a bajo nivel para los que sería conveniente emplearse a fondo en la estimación.
- Se olvida de pequeños subsistemas que no están previstos en principio a desarrollar.
- Tiene menos estabilidad que una estimación por componentes.
En la estimación bottom-up (de abajo a arriba), el coste de cada componente se estima por un individuo distinto, frecuentemente por la persona que será el responsable de su desarrollo. Después, esos costes son sumados para conseguir el total del producto.
Esta estimación es complementaria al top-down, siendo las debilidades de esta última las virtudes de la primera, y viceversa. Debido a que la estimación bottom-up se centra en cada uno de los componentes, pierde de vista costes globales como la integración, gestión de calidad, etc.; que están asociados al desarrollo de un proyecto. Por todo esto, estas estimaciones suelen ser un poco optimistas.
Se ha de añadir que este tipo de estimación requiere un mayor esfuerzo que la top-down, siendo esto en muchos aspectos una ventaja.
Además, una estimación bottom-up tiende a ser bastante más estable en el sentido de que los errores posibles en la estimación de varios componentes pueden compensarse mutuamente.
Modelos algorítmicos de estimación
editarLa estructura global de todos los modelos paramétricos de estimación es:
E = A + Bx^C
donde:
E: esfuerzo (pm)
A, B, C: constantes obtenidas empíricamente
x: variable de estimación (LDC o PF)
Los modelos de regresión son modelos derivados de la realización de un 'análisis de regresión' sobre proyectos anteriores.
Algunos modelos orientados a LDC son:
- Walston‐Felix: E = 5,2KLDC^0,91 (i)
- Bailey‐Basisli: E = 5,5 + 0,73KLDC^1,16 (i)
- Simple de Boehm: E = 3,2KLDC^1,05 (i)
- Doty (KLDC>9): E = 5,288KLDC^1,0457 (i)
Como modelos orientados a PF encontramos:
- Albretch y Gaffney: E = ‐91,4+0,355PF (i)
- Kemerer: E = ‐37 + 0,96PF (i)
- Proyectos pequeños: E = ‐12,88+0,405PF (i)
Para el mismo valor de LDC o PF los modelos difieren por lo que necesitan calibración para las necesidades locales.
COCOMO
editarEl modelo COCOMO original está compuesto de tres modelos:
- Básico: Calcula el esfuerzo en función del tamaño estimado (KLDC).
- Intermedio: Calcula el esfuerzo en función del tamaño estimado y de “conductores de coste”. Los conductores de coste evalúan un conjunto de atributos del producto, del hardware, del personal y del proyecto.
- Avanzado: Modificación del modelo intermedio para considerar el impacto de los conductores de coste en cada fase del proyecto.
Se usa uno u otro en función del conocimiento que se tenga del proyecto.
Estos tres modelos se definen para tres tipos de proyectos:
- Modo orgánico: proyectos pequeños y medianos, mucha experiencia, pocas restricciones, realizado por equipos pequeños, entorno familiar.
- Modo semiacoplado: proyectos intermedios en tamaño y complejidad, varios niveles de experiencia.
- Modo empotrado: proyectos complejos y muy restrictivos. Proyectos innovadores. Desarrollados dentro de un conjunto estricto de hardware, de software y restricciones operativas.
El modo determina los valores que tendrán las constantes y los exponentes de las ecuaciones.
COCOMO es el modelo empírico más completo para la estimación del software publicado hasta la fecha.
COCOMO II constituye una mejora y avance importante sobre el COCOMO original, también llamado COCOMO 81.
SLIM
editarPutnam (1991) desarrolló un modelo de restricciones denominado SLIM para proyectos que superan las 70 mil líneas de código (70 KLDC). Este modelo de estimación se propone encontrar las variables estratégicas del proceso de desarrollo de software, derivar de su comportamiento un sistema de ecuaciones e introducir dichas ecuaciones en una computadora para su estudio y análisis. (ii)
Encontrar estas variables o factores ha sido el objetivo de la mayoría de los estudios acerca de la estimación. En la mayor parte de los casos estos factores han sido ordenados según su importancia, pero no medidos de forma precisa. La ordenación es subjetiva, depende del individuo que la realiza o de casos particulares; este modelo lo que pretende es medir estos factores de forma objetiva y exacta, de forma que cualquier observador determinará los mismos valores y grado de influencia para los factores que están siendo estudiados.
Modelos no algorítmicos de estimación
editarLos modelos no algorítmicos o modelos heurísticos de estimación se basan también en la aplicación de algoritmos... pero algoritmos no deterministas. Las principales técnicas aplicadas son:
- Redes neuronales
- Minería de datos
- Programación genética
- Razonamiento basado en casos
- Simulación
Conclusiones
editarEstimar el esfuerzo que nos requiere la realización de un proyecto debería ser siempre el primer paso que demos para acometerlo. En Ingeniería del Software una adecuada estimación es la base de toda planificación creíble y útil, por lo que debemos conocer las distintas técnicas existentes y usarlas (a menudo de manera combinada) como medio para elaborar un plan de proyecto orientado hacia el éxito.