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,

S
P?
E

La curva de Rayleigh usada para la definición de la distribución de esfuerzo, viene

dada por la ecuación diferencial:
 dy
? 2 Kate? at
2

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, Control-
SLIM 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étricas-
SLIM 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 Factores de proyecto

Horas de esfuerzo 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
Personal/coste Horas de esfuerzo
Productividad de personal
Nivel de desrtreza en el desarrollo
Tasa en cada nivel
Hardware Categoría del sistema
Tipo genérico del sistema
Ventana de operación
Volumen de transacción
Riesgo Tamaño del sistema
Estructura del proyecto
Objetivo tecnológico
Portfolio Recursos necesarios para proyectos
concurrentes
Riesgos relativos del proyecto

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.