2. Modelos de estimación de costes de producción de software Los modelos y técnicas de estimación de costes de la ingeniería del software se emplean con una serie de fines: ? Presupuestar: el uso principal, pero no el único importante. La precisión en la estimación es una de las capacidades más deseadas ? Análisis de mercados y riesgos: una importante capacidad es la de alumbrar las consecuencias de las decisiones en los proyectos software (objetivos, personal, herramientas, reutilizabilidad etc.) ? Planificación y control de proyectos: una capacidad adicional importante es la de proporcionar costes y descomposiciones según estado, componente y actividad ? Análisis de la inversión en la mejora del software: una capacidad adicional importante es la de estimar los costes, así como los beneficios de las estrategias, herramientas, reutilizabilidad o madurez del proceso. En este apartado, resumimos las principales técnicas e indicamos su fuerza relativa para cumplir cada uno de los cuatro objetivos señalados. La investigación sobre modelos de estimación de costes de producción de software podría situarse en 1965 con el estudio SDC de los 104 atributos de 169 proyectos de software. Éste estudio condujo a una serie de modelos parcialmente útiles a finales de los 60 y comienzos de los 70. En los últimos años de la década de los 70 se produjo un florecimiento de modelos mucho más robustos como SLIM , Checkpoint , PRICE-S, SEER y COCOMO. Aunque muchos de éstos investigadores comenzaron trabajando en modelos de estimación de costes de desarrollo aproximadamente a la misma vez, todos encontraron el mismo dilema: a medida que el software crece en tamaño e importancia también crece en complejidad, haciendo muy difícil predecir con precisión el coste del desarrollo del software. Esta dinámica de la estimación de software retuvo el interés de estos investigadores que tuvieron éxito en el establecimiento de las piedras de base de los modelos de costes de la ingeniería del software. Como cualquier otro campo, los modelos de estimación de costes de la ingeniería del software tienen sus propios escollos. El rápido cambio de la naturaleza del desarrollo de software ha hecho muy difícil el desarrollo de modelos paramétricos que logren suficiente precisión en todos los dominios. El coste del desarrollo de software continúa creciendo y los profesionales continuamente expresan su incapacidad para predecir con precisión dichos costes. Uno de los más importantes objetivos de la ingeniería del software ha sido el desarrollo de modelos útiles que expliquen el ciclo de vida del desarrollo y que predigan con precisión el coste del desarrollo de un producto software. Con ese fin, muchos modelos de estimación de costes han surgido en la últimas dos décadas basándose en los pioneros esfuerzos de los investigadores mencionados arriba. Las técnicas más comúnmente usadas para estos modelos incluyen enfoques de regresión múltiple. En cualquier caso, estas técnicas clásicas de construcción de modelos no son necesariamente las mejores cuando se usan sobre datos de la ingeniería del software, como reflejamos en este apartado. Más allá de la regresión, numerosos artículos discuten los pros y los contras de unas técnicas de estimación de costes frente a otras y presentan resultados de análisis. En contraste con éstos, en este apartado nos centramos en la clasificación de las técnicas existentes en seis categorías proporcionando una visión con ejemplos de cada categoría. Estas categorías son: Técnicas basadas en el modelo Técnicas basadas en la experiencia Técnicas orientadas al aprendizaje Técnicas dinámicas Técnicas basadas en regresión Ténicas compositivas A continuación examinaremos con mayor profundidad algunos de los más populares modelos de costes que se encuentran englobados en la categoría de “Modelos de estimación de costes basados en el modelo”. 2.1 Técnicas basadas en el modelo Tal y como se ha comentado en la introducción, se han desarrollado varios modelos de estimación en las últimas décadas. Muchos de ellos son modelos propietarios y en consecuencia no pueden ser comparados y contrastados en términos de estructura de modelos. La teoría o la experimentación determinan la forma funcional de estos modelos. En este apartado presentamos siete de los modelos más populares y en la tabla al final del mismo los comparamos y contrastamos. 2.1.1 Modelo del Ciclo de vida del software de Putnam Larry Putnam, de Quantitative Software Measurement , desarrolló el SLIM (Software Life-cycle Model) a finales de los 70. SLIM está basado en el análisis del ciclo de vida en términos de la llamada “distribución de Rayleigh de personal frente al tiempo. Da soporte a la mayoría de las técnicas de estimación de tamaño más populares como las de líneas de código o las de puntos función. Hace uso de la curva de Rayleigh para estimar el esfuerzo necesario para el proyecto, programación temporal y rango de error. Dos índices se emplean para ajustar la forma de la curva, el MBI (Manpower Buildup Index) y el PF (Productivity Factor). SLIM puede almacenar y analizar datos de proyectos ya realizados que se emplean para calibrar el modelo. Si los datos no están disponibles se pueden tratar de ajustar los valores de los índices a través de una serie de preguntas a los desarrolladores. En SLIM, la productividad se emplea para enlazar la distribución básica de Rayleigh con las características de tamaño e influencia de la tecnología del desarrollo de software. La productividad, P, es el cociente del tamaño del producto software y el esfuerzo de desarrollo, E. Esto es, P? S E La curva de Rayleigh usada para la definición de la distribución de esfuerzo, viene dada por la ecuación diferencial: 2 dy ? 2 Kate? at dt Un ejemplo es el mostrado en la figura 2, donde K=1’0, a=0’02, t d = 0’18 donde Putnam asume que el pico de nivel de personal en la curva de Rayleigh corresponde al tiempo de desarrollo. Algunas de las suposiciones de la curva de Rayleigh no siempre se ajustan a la práctica. Para solventar este problema Putnam ha desarrollado distintos modelos de ajuste para estas situaciones. Recientemente el Quantitative Software Management ha desarrollado un set de tres herramientas basadas en el SLIM de Putnam. Incluye Estimación-SLIM, ControlSLIM y Métricas-SLIM. Estimación-SLIM en una herramienta de planificación de proyectos, SLIM-Control es una herramienta de seguimiento de proyectos, MétricasSLIM es una herramienta de cálculo de métricas del software. 2.1.2 Checkpoint Checkpoint es una herramienta de estimación de proyectos basada en el conocimiento del Software Productivity Research (SPR) desarrollada a partir de los estudios de Capers Jones. Posee una base de datos propia de aproximadamente unos 8000 proyectos software y se centra en cuatro areas que deben ser controladas para mejorar la calidad y la productividad del software. Se basa en el empleo de los Puntos Función como la principal entrada de tamaños. El sumario de oportunidades del SPR aparece en la figura . Hace hincapié en tres capacidades principales para sostener el ciclo de vida completo del desarrollo de software: ? Estimación: Checkpoint predice el esfuerzo en cuatro niveles de granularidad: proyecto, fase, actividad y tarea. Las estimaciones también incluyen recursos, entregables, defectos, costes y horarios. ? Medidas: Checkpoint habilita a los usuarios para tomar las métricas del proyecto para realizar análisis, identificar las mejores prácticas y desarrollar bases de conocimiento para la estimación interna. ? Valoración: Chekpoint facilita la comparación del rendimiento actual y el estimado con varios estándares de la industria incluídos en la base de conocimiento. También evalúa la fortaleza o debilidad del entorno software. 2.1.2.1 Otros modelos de estimación de costes basados en la funcionalidad Las técnicas vistas hasta ahora están basadas en el análisis de los puntos función. Pero en la actualidad hay mucha más actividad en el área de la estimación basada en ña funcionalidad y merece la atención de este punto. Uno de los proyectos más recientes es el proyecto COSMIC (Common Software Measurement Internacional Consortium). Desde el lanzamiento de la iniciativa COSMIC, en noviembre de 1999, un equipo internacional de expertos en métricas del software ha estado trabajando para establecer los principios del nuevo método, que se espera se basen en los mejores aspectos de los métodos ya existentes. Desde que los puntos función son considerados más útiles en el dominio de MIS y problemáticos en el dominio del software en tiempo real, se han realizado nuevos esfuerzos en la estimación basada en la funcionalidad, fruto de ellos es la técnica de los Puntos Función Completos (FFP) que son una medida específicamente adaptada al software integrado y en tiempo real. La última versión el COSMIC-FFP usa un modelo de software genérico adaptado al objetivo de la medida del tamaño funcional, un acercamiento en dos fases a la medida del tamaño funcional (mapeo y medida), un conjunto simplificado de componentes funcionales y una función escalable de agregación. 2.1.3 PRICE-S El modelo PRICE-S fue originalmente desarrollado en el RCA para su uso interno en proyectos como por ejemplo algunos de los que eran parte del programa espacial Apollo. Fue hecho público en 1977 como un modelo propietario y fue usado para la estimación en numerosos proyectos del US DoD, la NASA y otros organismos gubernamentales. Las ecuaciones del modelo no se hicieron públicas, aunque algunos de los algoritmos centrales del modelo fueron publicados. La herramienta se hizo popular y en la actualidad es comercializada por PRICE Systems. El modelo consiste en en tres subsistemas que permiten la estimación de costes y plazos para el desarrollo de sistemas de ordenadores. Estos tres submodelos son: ? El submodelo de adquisición. Este submodelo pronostica costes y plazos. El modelo cubre el desarrollo de todos los tipos de software, incluyendo sistemas de negocios, comunicaciones, comando y control etc… ? El submodelo de tamaño. Este submodelo facilita la estimación del tamaño del software a desarrollar. El tamaño puede estimarse en líneas de código, puntos función o POPs (Predictive Object Points), para desarrollos orientados a objetos. ? El submodelo de coste del ciclo de vida. Este submodelo se emplea para la estimación del coste de la fase de mantenimiento del software. 2.1.4 ESTIMACS Este método de estimación de centra en la fase de desarrollo del ciclo de vida del sistema, dejando el mantenimiento a futuras extensiones del método. ESTIMACS hace hincapié en lograr la estimación en términos de negocio. También hace hincapié en la necesidad de realizar análisis de sensibilidad y mercado prematuramente, no sólo con el producto en mano, sino también sobre cómo el actual proyecto se ajustará al proceso de desarrollo a largo plazo de la compañía desarrolladora, en términos de personal y costes y riesgos asociados. Identifica seis dimensiones importantes de la estimación y se crea un mapa en el que se muestran las relaciones entre las mismas. La premisa básica de ESTIMACS es que las especificaciones a groso modo del negocio, o “factores del proyecto”, determinan las dimensiones de estimación. Se definen los “factores del proyecto” como “aspectos de la funcionalidad del sistema objeto que son bien definidos al comienzo del proceso “. En la siguiente tabla se muestran los factores de proyecto importantes. Dimensión de estimación Horas de esfuerzo Factores de proyecto Complejidad de cliente Geografía de cliente Familiaridad del desarrollador Función de tamaño de negocio Objetivo de sofisticación del sistema Objetivo de complejidad del sistema Horas de esfuerzo Productividad de personal Nivel de desrtreza en el desarrollo Tasa en cada nivel Categoría del sistema Tipo genérico del sistema Ventana de operación Volumen de transacción Tamaño del sistema Estructura del proyecto Objetivo tecnológico Recursos necesarios para proyectos concurrentes Riesgos relativos del proyecto Personal/coste Hardware Riesgo Portfolio Los elementos de la tabla anterior forman la base de los cinco submodelos que componen ESTIMACS. Los submodelos estás diseñados para ser usados secuencialmente, de tal forma que las salidas de uno son las entradas del siguiente. De forma general, se realiza un proceso iterativo que lleva a la estimación final de desarrollo. El proceso en cada modelos sería: 1.- Estimación de la evolución de los datos de entrada 2.- Resumen de estimación 3.- Análisis de sensibilidad 4.- Revisión del paso 1 basado en el resultado del paso 3 Los cinco submodelos de ESTIMACS en el orden de uso son: ? Estimación de esfuerzo en el desarrollo del sistema. ? Estimación de personal necesario y coste. ? Estimaciones de configuración de Hardware ? Estimación de riesgos ? Análisis de “portfolio” (análisis a largo plazo del proyecto en el proceso global de la compañía) La principal ventaja/diferencia de ESTIMACS es su habilidad para estimar y analizar las sensibilidades no sólo de software, sino también de hardware, y su objetivo de planificación orientada al negocio. 2.1.5 SEER-SEM Este producto lleva ya más de quince años en el mercado. Durante ese tiempo ha evolucionado a una sofisticada herramienta que soporta metodologías de estimación top-down y bottom-top. Las ecuaciones del modelo son propietarias. El objetivo del modelo es bastante amplio. Cubre todas las fases del ciclo de vida del proyecto, desde las primeras especificaciones al diseño, desarrollo y mantenimiento. Maneja una amplia variedad de entornos y configuraciones de aplicaciones. Modela los métodos de desarrollo y lenguajes más extendidos. Las entradas son: tamaño, personal, entorno, complejidad y restricciones. Las salidas sin: esfuerzo, coste, plazos, riegos,mantenimiento y fiabilidad. Las características del modelo son: ? Permite como entradas el nivel de probabilidad de la estimación, el personal y los horarios ? Facilita el análisis extensivo de sensibilidad y mercado sobre los parámetros de entrada ? Organiza los elementos del proyecto en WBS (Work Breakdown Structures) para una planificación y control convenientes. ? Muestra los conductores de los costes del proyecto ? Permite la programación interactiva de los elementos del proyecto en diagramas de Gantt ? Construye las estimaciones a partir de una base de datos sobre proyectos ya existentes Las especificaciones del modelo incluyen las siguientes: ? Parámetros: tamaño, personal, complejidad, entorno y resticciones. ? Predicciones: esfuerzo, horarios, personal, errores y costes. ? Análisis de riegos ? Métodos de estimación de tamaño: puntos función, líneas de código… ? Salidas e interfaces. 2.1.6 Estimador SELECT Está diseñado para el desarrollo de sistemas distribuidos de gran escala. Está orientado a objetos, basando sus estimaciones en los objetos y componentes de negocio. Asume un ciclo de vida de desarrollo incremental. La naturaleza de sus entradas permite que el modelo pueda ser aplicado en cualquier del ciclo de vida del desarrollo del producto. Es especialmente interesante que se puede aplicar en las primeras fases es las que es escaso el conocimiento de las especificaciones del proyecto. A medida que avanza el proyecto las estimaciones se van haciendo más fiables. La técnica actual de estimación está basada en el ObjectMetrix, desarrollado por The Object Factory. ObjectMetrix funciona midiendo el tamaño de un proyecto contando y clasificando los elementos software inherentes al mismo. Las técnicas ObjectMetrix comienzan con una métrica básica del esfuerzo en personas-días requeridos típicamente para desarrollar un elemento de un proyecto. Este esfuerzo asume todas las actividades de un proceso normal de desarrollo de software, pero no tiene en cuenta nada relativo a las características del proyecto o la tecnología empleada. Se aplican perfiles predefinidos de actividades como la planificación, análisis, diseño, programación, prueba integración y revisión en función del tipo de elemento del proyecto, que es la base de las métricas de esfuerzo. Una vez realizado lo anterior, se utilizan calificadores para ajustar las estimaciones. También se aplica un factor de tecnología empleada que ajusta la estimación en función del entorno de programación Aplicando los calificadores y el factor de tecnología se obtiene una estimación global del esfuerzo en personas-días, por actividad. Esta estimación total representa el esfuerzo requerido por una persona de nivel medio para completar el proyecto. Usando el esfuerzo requerido de una persona, se pueden determinar los plazos en función del número de desarrolladores y su nivel. El estimador SELECT adapta la estimación ObjectMetrix refinando los calificadores y los factores de tecnología. 2.1.7 COCOMO II (COnstructive COst MOdel) El modelo tiene tres submodelos, Composición de Aplicaciones, Diseño Temprano y Post-Arquitectura, que se pueden combinar de varias formas para que puedan ser utilizados con las prácticas software actuales y futuras. El modelo de Composición de Aplicaciones se emplea para estimar el esfuerzo y los plazos en proyectos que usan herramientas de Integrated Computer Aided Software Engineering para desarrollo rápido de aplicaciones. Está basado en Puntos Objeto, que consisten en una cuenta de pantallas, reports y módulos de lenguajes de 3ª generación. Cada objeto se pondera según su nivel de complejidad. El modelo de Diseño Temprano implica la exploración de arquitecturas de sistema alternativas y conceptos de operación. Se aplica cunado la información no es sificiente para realizar un una estimación detallada. Se basa en los Puntos Función. El modelo de Post-Arquitectura cuando el diseño de alto nivel ha sido completado y hay información detallada del proyecto disponible y, como su propio nombre sugiere, la arquitectura del sistema está bien definida y establecida. Estima para todo el ciclo de vida y es una extensión detallada del modelo de Diseño Temprano. Este modelo se ha calibrado con 161 proyectos procedentes de la industria comercial, aeroespacial y gubernamental. 2.2 Técnicas basadas en la experiencia Las técnicas basadas en la experiencia son de utilidad cuando no hay disponibles datos empíricos cuantitativos. Utilizan el conocimiento y la experiencia de los desarrolladores en el dominio de interés, proporcionando estimaciones basadas en la síntesis de los resultados de proyectos pasados en los que el desarrollador ha participado. La principal pega de este método es obvia, la calidad del método depende de la opinión del “experto”, y no hay forma de probar dicha opinión hasta que no es demasiado tarde. Años de experiencia no tienen por qué traducirse en altos niveles de competencia. Más aún, incluso los expertos más competentes pueden en ocasiones hacer estimaciones equivocadas. Se han desarrollado dos técnicas que capturan el juicio del experto y que tratan de mitigar los juicios erróneos dividiendo el proceso en pasos. 2.2.1 Técnica Delphi. Se trata de una técnica útil para llegar a conclusiones cuando la información está basada fundamentalmente en la experiencia y no en datos empíricos. Consiste en una serie de rondas de encuestas sobre la estimación de esfuerzo a los expertos. En la primera se les hace de forma individual, en la siguiente con conocimiento de lo que los otros expertos han opinado en primera ronda. De esta forma está demostrado que la estimación va tendiendo a unos valores medios. 2.2.2 WBS (Work Breakdown Structure) WBS es una forma de organizar los elementos del proyecto en una jerarquía que simplifica las tareas de estimación de presupuesto y control. Ayuda a determinar de forma exacta qué costes están siendo estimados. Si se asignan probabilidades a los costes asociados con cada elemento individual de la jerarquía, se puede determinar un valor total esperado de desarrollo a partir de los elementos básicos. Los expertos entran en juego en esta técnica a la hora de determinar la especificación de componentes más útil y las probabilidades asociadas con cada componente. Además de ayudar en el proceso de estimación, WBS es muy útil a la hora del control el desarrollo de los proyectos. A cada elemento de la estructura se le puede asignar una estimación de presupuesto y esfuerzo. Si el personal va registrando el tiempo empleado en cada actividad, se puede crear una importante base de datos en la cual basar las futuras estimaciones. 2.3 Técnicas orientadas al aprendizaje. Las técnicas orientadas al aprendizaje incluyen algunas de las técnicas más antiguas de estimación y también algunas de las más modernas. Las primeras están representadas por los casos de estudio, y las segundas por las redes neuronales, que tratan de automatizar las mejoras en el proceso de estimación construyendo modelos que “aprenden” de la experiencia previa. 2.3.1 Casos de estudio. Representan un proceso inductivo, donde los estimadores y planificadores tratan de obtener reglas generales y heurísticos de estimación a partir de ejemplos concretos. Tratan de obtener de estos casos las conexiones causa-efecto que pueden aplicarse en otros contextos. Idealmente se buscan proyectos similares al proyecto que hay que estimar, aplicando la regla de analogía que dice que los costes y plazos serán similares. Las fuentes de casos de estudio pueden ser internas o externas a la organización, aunque a priori los primeros proporcionarán una estimación mejor. 2.3.2 Redes neuronales Las redes neuronales son la técnica de construcción de modelos de estimación más usada como alternativa a la regresión de mínimos cuadrados. Éstos son modelos de estimación que pueden ser entrenados utilizando datos históricos para producir mejores resultados ajustando automáticamente los parámetros para reducir la delta entre lo actual y las predicciones del modelo. El desarrollo de la red neuronal comienza con el desarrollo de una distribución apropiada de neuronas, o conexiones entre nodos de la red. Esto incluye definir el número de capas de la red, el número de neuronas en cada capa y la manera en que todo se relaciona. Las funciones estimadas de ponderación y el algoritmo específico de entrenamiento a usar también debe ser determinado. Una vez que se ha construido la red, hay que entrenar al modelo proporcionándole datos históricos de estimaciones y los valores actuales conocidos de costes y plazos. El modelo entonces itera en su algoritmo de entrenamiento, ajustando automáticamente los parámetros de sus funciones de estimación hasta que las estimaciones del modelo y los datos actuales están sobre una delta pre-especificada.. La especificación del valor de delta es importante, sin él, el modelo podría ser “sobreentrenado” hasta los datos históricos, ajustando sus algoritmos de estimación hasta que son muy buenos prediciendo los resultados de los datos históricos de entrenamiento, pero debilitando la aplicabilidad de esos algoritmos de estimación a un conjunto más amplio de datos. 2.4 Técnicas dinámicas Las técnicas dinámicas tienen en cuenta explícitamente que los esfuerzos o los costes de un proyecto varían a lo largo del desarrollo del sistema. Ésta es una diferencia significativa con el resto de modelos aquí presentados, que son de carácter estático. 2.4.1 Enfoque de sistemas dinámicos Se trata de una metodología de simulación en la que los resultados del modelo y el comportamiento se muestran en forma de gráficas de información que varían a lo largo del tiempo. Los modelos se representan como redes modificadas con realimentaciones positivas y negativas. Los elementos del modelo se expresan como niveles variando dinámicamente o acumulaciones (los nodos), rangos o flujos entre niveles e información relativa al sistema que varía a lo largo del tiempo y afecta dinámicamente a los flujos entre niveles. Los modelos más comunes utilizan las siguientes suposiciones/afirmaciones debidas a Brooks: ? El personal nuevo debe ser entrenado por personal experimentado para mejorar su productividad. ? Incrementar el personal dedicado a un proyecto implica incrementar la comunicación y coordinación. ? El personal que ha estado trabajando un tiempo en un proyecto es más productivo que el personal nuevo añadido. Matemáticamente, las técnicas de sistemas dinámicos se expresan como un conjunto de ecuaciones diferenciales de primer orden: x’(t) = f(x,p) donde: x : es un vector que describe los niveles en el modelo p : es un conjunto de parámetros del modelo f : es una función vectorial no lineal t : tiempo 2.5 Técnicas basadas en regresión Son las técnicas más populares de construcción de modelos. Se suelen usar junto con las técnicas basadas en el modelo. 2.5.1 Regresión estándar. Mínimos cuadrados. Este método emplea el clásico enfoque estadístico de regresión de mínimos cuadrados. Funciona correctamente cuando: ? Hay muchos datos disponibles. ? No falta información en los datos. ? No hay casos extremos que “se salgan de la linea“ ? Las variables predictoras no están correladas. ? Las variables predictoras son de fácil interpretación para su uso en el modelo. ? Los parámetros de regresión son todos continuos o todos discretos. 2.5.2 Regresión robusta. Es una mejora de la regresión estándar que alivia el problema de los datos “que no cuadran” en el modelo. Normalmente los datos de los proyectos tienen muchos datos dispares debido a desacuerdos en la definición de las métricas del software, la coexistencia de numerosos procesos de desarrollo de software y la disponibilidad de datos cualitativos frente a los cuantitativos. Hay muchas técnicas estadísticas que podrían englobarse dentro de la regresión robusta, por ejemplo la técnica de mínimos cuadrados medios. 2.6 Técnicas compositivas. Las técnicas compositivas incorporan una combinación de dos o más técnicas para formular la forma funcional más apropiada para la estimación. 2.6.1 Enfoque Bayesiano Un enfoque muy atractivo de estimación es el análisis Bayesiano. Se trata de un modo inductivo de razonamiento usado en múltiples disciplinas científicas. Permite al investigador usar los datos de muestra y la información de experiencia previa en una manera lógicamente consistente de hacer inferencia. Esto se lleva a cabo aplicando el teorema de Bayes para producir post-datos o distribuciones posteriores de los parámetros del modelo. Utilizando el teorema de Bayes, los datos previos se transforman en vistas de post-datos. Esta transformación puede verse como un proceso de aprendizaje. La distribución posterior viene determinada por las varianzas de la información previa y de la información de muestra. Si la varianza de la información previa es menor que la de la información de muestra, se le asigna un peso mayor y viceversa. El enfoque Bayesiano proporciona un proceso formal mediante el cual se puede combinar el juicio previo de un experto con la información de muestra disponible para producir un modelo a posteriori robusto. El análisis Bayesiano tiene todas las ventajas de la regresión “estándar” e incluye el conocimiento de los expertos. 2.7 Conclusiones En este apartado se ha presentado una visión general de la variedad de técnicas de estimación de software, proporcionando información de modelos de estimación populares que están en uso y disponibles en la actualidad. La experiencia demuestra que las ténicas de redes neuronales y las dinámicas están menos maduras que el resto de técnicas, pero todas las técnicas son desafiadas constantemente por la rápida evolución de la tecnología del software. La conclusión más importante que se puede sacar de esta visión general es que no debería a priori preferirse ninguna técnica sobre las demás. La clave para lograr buenos modelos es usar varias técnicas y después investigar las razones que motivan que las estimaciones de unos varíen significativamente de las estimaciones proporcionadas por otros. Si se es capaz de determinar y explicar estas diferencias con unos niveles razonables de satisfacción, entonces se podrá decir que se tiene una buena comprensión de los factores que están conduciendo los costes del proyecto y se estaré mejor preparado para las tareas de planificación y control.