ESTIMACIÓN DE COSTOS DEL SOFTWARE

1. ESTIMACION DE COSTE DEL
SOFTWARE

2. INTRODUCCIÓN
FUNCIÓN
–1.1. ¿Qué es un proyecto de Sistema o Software?
RENDIMIENTO
Es el Proceso de gestión para la creación de un Sistema o RESTRICCIONES ÁMBITO DEL
software, la cual encierra un conjunto de actividades, una SOFTWARE
de las cuales es la estimación. INTERFACES
FIABILIDAD
– 1.2. Objetivos de la Planificación del Proyecto.
El objetivo de la Planificación del proyecto de Software es
proporcionar un marco de trabajo que permita al gestor hacer
estimaciones razonables de recursos costos y planificación
temporal.
PLANIFICACIÓN
EXPERIENCIA
EXPERIENCIA
ESTIMACIÓN RIESGO
DATOS
DATOS
HISTÓRICOS
HISTÓRICOS

3. 2.- FACTORES EN EL COSTO DEL SOFTWARE
2.1 Capacidad del programador
2.2 Complejidad del producto (Software)
- Programas de Aplicación (procesamiento de datos y programas de datos).
- Programas de Apoyo (compiladores, ligadores y sistemas de inventarios).
- Programas de Sistema (sistema de base de Datos, sistemas operativos
y sistemas para tiempo real).

4. 2.3 Tamaño del Producto.-
Un proyecto grande de programación es obviamente mas cara en su
desarrollo que un o pequeño.
2.4 Tiempo Disponible.-
El esfuerzo total del proyecto se relaciona con el calendario de trabajo
asignado para la terminación del proyecto
2.5 Nivel de Confiabilidad Requerido.-
La confiabilidad puede expresarse en términos de exactitud, firmeza, cobertura
y consistencia de código fuente.
Categoría Consecuencia de la falla Factor
Muy Baja Algunas molestias menor 0.75
Baja Las perdidas son fáciles de recuperar 0.88
Nominal Dificultad relativa en la recuperación 1.00
Alta Gran perdida financiera 1.15
Muy Alta Riesgo de una vida 1.40

5. 2.6 Nivel Tecnológico
El nivel de tecnología empleado en un proyecto de programación se refleja
en el lenguaje utilizado
3.- TÉCNICAS DE DESCOMPOSICIÓN
Normalización de las métricas
Los datos normalizados son utilizados para evaluar el proceso y el
producto (pero nunca a los individuos)
normalizació n orientada al tamañ o
—Por líneas de có digo
normalizació n orientada a la funció n
—Por puntos funció n

6. 3.1.- Estimación LDC (LOC es la sigla de la expresión
inglesa Lines of Code. )
La medida más utilizada para determinar el tamaño de un proyecto informático ha
sido, durante mucho tiempo, la de las líneas de código del software final obtenido.
Problemas de la utilización de LDC
* no existe definición estándar de LDC (p.ej., ¿se consideran LDC los
comentarios?)
* líneas físicas o lógicas
* contabilización del código reutilizable
* aplicaciones en diferentes lenguajes
* estilos individuales de programación

7. Ejemplo de LOC
Hay que desarrollar un software CAD que aceptará datos geométricos de 2 o 3 dimensiones por parte del ingeniero. Éste controlará el sistema
CAD por medio de una interfaz que debe tener un diseño de buena calidad.2 o 3 base de datos CAD contiene todos los datos geométricos y la
Hay que desarrollar un software CAD que aceptará datos geométricos de Una dimensiones por parte del ingeniero. Éste controlará el sistema
información de soporte. Se desarrollarán módulos de análisis buena calidad. Una basela salida requerida que se va a los datos geométricos y la
CAD por medio de una interfaz que debe tener un diseño de de diseño para producir de datos CAD contiene todos visualizar en varios
información de soporte. Se desarrollarán módulos de análisis de diseño para producir la salida requerida que se va a visualizar en varios
dispositivos gráficos.
dispositivos gráficos.
El software se diseñará para controlar e interconectar diversos periféricos, como un ratón, un digitalizador y una impresora láser.
El software se diseñará para controlar e interconectar diversos periféricos, como un ratón, un digitalizador y una impresora láser.
Funciones identificadas:
Funciones identificadas: Estimación en LDC de AG3D:
descomposición
interfaz de usuario yy facilidades de control (IUFC) Estimación en LDC de AG3D:
interfaz de usuario facilidades de control (IUFC)
descomposición
de funciones
optimista: 4600
de funciones
análisis geométrico de dos dimensiones (AG2D) optimista: 4600
análisis geométrico de dos dimensiones (AG2D) más probable: 6900
análisis geométrico de tres dimensiones (AG3D) más probable: 6900
análisis geométrico de tres dimensiones (AG3D) pesimista: 8600
gestión de base de datos (GBD) pesimista: 8600
gestión de base de datos (GBD)
facilidades de la interfaz gráfica (FIG)
facilidades de la interfaz gráfica (FIG)
control periféricos (CP)
control periféricos (CP)
módulos de análisis del diseño (MAD) VE ==(Sopt ++4Sm ++Spes)/6
módulos de análisis del diseño (MAD) VE (Sopt 4Sm Spes)/6
Datos históricos:
Datos históricos:
productividad media de la organización en
métricas de
Función LDC estimada
anteriores
productividad media de la organización en
proyectos
métricas de
Función LDC estimada
anteriores
proyectos similares: 620 LDC/pm
proyectos
proyectos similares: 620 LDC/pm
IUFC 2300
Tarifa laboral: 8000 $$ /mes IUFC 2300
Tarifa laboral: 8000 /mes AG2D
AG2D
5300
5300
AG3D 6800
Coste LDC: 13 $$ AG3D 6800
Coste LDC: 13 GBD 3350
GBD 3350
FIG 4950
FIG 4950
CP 2100
CP 2100
MAD 8400
MAD 8400
Total 33200
Total 33200
Coste total proyecto: 431000 $$
Coste total proyecto: 431000
Esfuerzo estimado: 54 personas-
Esfuerzo estimado: 54 personas-
mes
mes

8. Puntos de función: relación empírica basada en medidas cuantitativas del
dominio de información del software y valoraciones subjetivas acerca de la
complejidad del software
3.2 Estimación por PF (Expresión de Punto Función)
Determinación de los puntos de función El recuento de los puntos de
función se elabora a partir de determinadas características funcionales,
que pueden ser de datos o de transacción:
¿Por qué la preferencia a
FP?
independencia del lenguaje de programación
utiliza inmediatamente características
contables del “dominio de información” del problema
no “penalizar” implementaciones que requieren menos LOCs
que otras (vs. mantenimiento)
facilitan el reuso y favorecen a las iniciativas orientadas a
objetos

9. Calcular Puntos
Analizar el dominio
de la informació n de la
Función
Establecer el conteo para cada dominio
aplicaciò n y desarrollar de entrada e interfaces de sistema
el conteo
Pesar cada conteo por
evaluació n de la
Asignar el nivel de complejidad o peso
complejidad para cada conteo
evaluar la influencia de
factores globales que
Grado de importancia de factores externos
afecten la aplicació n Fi tales como reuso, concurrencia, SO,...
Puntos funció n = Σ (conteo x peso) x C
Calcular puntos
funció n donde:
Factor de complejidad: C = (0.65 + 0.01 x N)
Grado de influencia: N = Σ Fi

10. Analizar el Dominio de la
Informaciónponderació n
conteo
factor de
simple prom. complejo
pará
metro de medida
# de entradas de usuario X 3 4 6 =
# de salidas de usuario X 4 5 7 =
# de consultas X 3 4 6 =
# de archivos X 7 10 15 =
# of interfaces ext. X 5 7 10 =
conteo-total
factor de complejidad
puntos funció n

11. Considerar la
Los factores Complejidad
se tasan en una escala
0 (sin importancia) – 5 (muy importante)
comunicaciones de datos actualizació n en línea
funciones distribuidas procesamiento complejo
configuració n pesada facilidad de instalació n
tasa de transacció n facilidad operacional
entrada de datos en lìnea sites mú ltiples
eficiencia para el usuario facilidad de cambios

12. Ejemplo FP
Valor dominio Opt. Probable Pesimista Cuenta Peso Cuenta
información est PF
Num. entradas 20 24 30 24 4 96
Num. salidas 12 15 22 16 5 80
Num. peticiones 16 22 28 22 4 88
Num. archivos 4 4 5 4 10 40
Num. interfaces ext. 2 2 3 2 7 14
Cuenta total 318
Copia de seguridad y recuperación 4
Copia de seguridad y recuperación
Comunicaciones 24
Comunicaciones
Proceso distribuido 02
Proceso distribuido
Rendimiento crítico 40
PF estimado == cuenta total x (0,65 + 0,01 x Suma (Fi)
PF estimado cuenta total x (0,65 + 0,01 x Suma (Fi)
Rendimiento crítico
Entorno operativo existente 34
Entorno operativo existente
Entrada de datos online 43
Entrada de datos online
Transacciones entrada en varias pant. 54
Transacciones entrada en varias pant.
Archivos maestros actualizados online 35
Complejidad valores actualizados online
Archivos maestros dominio información 53
Complejidad valores dominio información
Complejidad procesamiento interno 55
Complejidad procesamiento interno
Código diseñado para reutilización 45 PF estimado ==372
PF estimado 372
Conversión en diseño reutilización
Código diseñado para 34
Instalaciones en diseño
Conversión múltiples 53
Instalaciones múltiples
Aplicación diseñada para cambios 55
Aplicación diseñada para cambios 5
Coste total proyecto: 457000 $$
Coste total proyecto: 457000
Datos históricos: Esfuerzo estimado: 58 personas-
Datos históricos: Esfuerzo estimado: 58 personas-
productividad media de la organización en mes
métricas de
anteriores
productividad media de la organización en
proyectos
mes
métricas de
anteriores
proyectos similares: 6,5 PF/pm
proyectos
proyectos similares: 6,5 PF/pm
Tarifa laboral: 8000 $$ /mes
Tarifa laboral: 8000 /mes
Coste por PF: 1.230 $$
Coste por PF: 1.230

13. 3.3 Relación entre puntos de función y líneas de código
Aunque los puntos de función y las líneas de código sean diferentes, es
posible encontrar una especie de equivalencia entre los unos y las otras
relación entre LDC y PF: depende del lenguaje escogido
Lenguaje
Lenguaje LDC/PF (media)
LDC/PF (media)
Ensamblador
Ensamblador 320
320
CC 128
128
Cobol
Cobol 105
105
Fortran
Fortran 105
105
Pascal
Pascal 90
90
Ada
Ada 70
70
Lenguajes OO
Lenguajes OO 30
30
L4G
L4G 20
20
Lenguajes visuales
Lenguajes visuales 44
4.-TECNICAS DE ESTIMACION
La estimación se utiliza para definir si el presupuesto del proyecto y el
producto se ajusta para que las cifras del presupuesto se cumplan.

14. 4.1 Estimación basada en el enfoque descendente o ascendente
Estos enfoques para la estimación del costo se pueden abordar utilizando
enfoque descendente o ascendente
Un enfoque descendente inicia en el nivel de sistema. La estimación comienza
examinando la funcionalidad total del producto y cómo es que esa funcionalidad se
propaga al interactuar con las subfunciones
El enfoque ascendente, en contraste, inicia en el nivel de componente. El
sistema se divide en componentes y se calcula el esfuerzo requerido para
desarrollar cada uno de éstos
4.2 Estimación basada en el Proceso.
Es la técnica más común para estimar un proyecto es basar la
estimación en el proceso que se va a utilizar, es decir, el proceso se
descompone en un conjunto relativamente pequeño de actividades o
tareas, y en el esfuerzo requerido para llevar a cabo la estimación de
cada tarea.

15. 4.3 Tipos de Técnicas de Estimación de costos.-
Técnica Descripción
Se desarrolla un modelo utilizando información histórica de costos que
Modelado del algoritmo de
relaciona alguna métrica de software (por lo general, su tamaño) con
costos
el costo del proyecto.
Se consultan varios expertos en las técnicas de desarrollo de software
propuestas y en el dominio de aplicación. Cada uno de ellos estima
Opinión de expertos
el costo del proyecto. Estas estimaciones se comparan y discuten. El
proceso de estimación se itera hasta que se acuerda una estimación.
Esta técnica es aplicable cuando otros proyectos en el mismo dominio de
Estimación por analogía aplicación se han completado. Se estima el costo de un nuevo
proyecto por analogía con estos proyectos completados.
La Ley de Parkinson establece que el trabajo se extiende para llenar el
Ley de Parkinson tiempo disponible. El costo se determina por los recursos
disponibles más que por los objetivos logrados.
El costo del software se estima dependiendo de lo que el cliente esté
Asignar costos para ganar dispuesto a pagar por el proyecto. El esfuerzo estimado depende del
presupuesto del cliente y no de la funcionalidad del software

16. 5 TÉCNICAS DE ESTIMACIÓN DE COSTOS DEL SOFTWARE
5.1.- Estimación de Costos por la Técnica del Juicio Experto.-
Se basa en la experiencia, como en el conocimiento anterior en el sentido comercial
de uno o mas individuos dentro de la organización, su mayor ventaja es la
experiencia la cual puede llegar a ser su debilidad
5.2. – Estimación del costo por la técnica DELFI
La técnica DELFI fue desarrollada con el fin de tener el consenso de expertos,
sin contar con los efectos negativos de las reuniones de grupos
5.3- MODELOS DE ESTIMACIÓN EMPÍRICA
Donde los datos que soportan la mayoría de los modelos de estimación
obtienen una muestra limitada de proyectos

17. COCOMO (MEDELO CONSTRUCTIVO DE COSTE)
• Tres tipos de proyectos:
MODELO 1 (COCOMO básico)
MODELO 1 (COCOMO básico) – Orgánicos: relativamente pequeños y sencillos,
calcula el esfuerzo y el coste del desarrollo en
calcula el esfuerzo y el coste del desarrollo en
función del tamaño estimado del programa (LDC). en los que trabajan pequeños equipos con
función del tamaño estimado del programa (LDC).
Se utiliza para una aproximación rápida al principio
Se utiliza para una aproximación rápida al principio experiencia, sobre un conjunto de requisitos
del ciclo de vida.
del ciclo de vida. poco rígidos.
ESFUERZO: EE = ab KLDC
ESFUERZO: = ab KLDCbb
bb
– Semiacoplados: proyectos intermedios (en
TIEMPO: D == cb E
D c Edbdb
TIEMPO: b tamaño y complejidad) en los que participan
equipos con variados niveles de experiencia, y
que deben satisfacer requisitos poco o medio
rígidos.
MODELO 2 (COCOMO intermedio) – Empotrados: proyectos que deben ser
MODELO 2 (COCOMO intermedio)
calcula el esfuerzo y el coste en función del tamaño
calcula el esfuerzo y el coste en función del tamaño desarrollados en un conjunto de hardware,
estimado del programa y de un conjunto de “guías
estimado del programa y de un conjunto de “guías
de coste” que incluyen una evaluación software y restricciones operativas muy
de coste” que incluyen una evaluación
subjetiva del producto, hardware, personal y atributos
subjetiva del producto, hardware, personal y atributos restringido.
del producto
del producto
ESFUERZO: EE = aKLDCbi xx FAE (factor
ESFUERZO: = ai i KLDC FAE (factor
bi
MODELO COCOMO BÁSICO
MODELO COCOMO BÁSICO
de ajuste del esfuerzo)
de ajuste del esfuerzo)
Proyecto
Proyecto aa
b bb
b cc
b dd
b
b b b b
Orgánico
Orgánico 2,4 1,05
2,4 1,05 2,5
2,5 0,38
0,38
MODELO 3 (COCOMO avanzado)
MODELO 3 (COCOMO avanzado)
incorpora las características del mod. 2 y evalúa el
incorpora las características del mod. 2 y evalúa el
Semiacoplado 3,0
Semiacoplado 3,0 1,12
1,12 2,5
2,5 0,35
0,35
impacto de los FAE en cada fase del desarrollo.
impacto de los FAE en cada fase del desarrollo.
Empotrado
Empotrado 3,6
3,6 1,20
1,20 2,5
2,5 0,32
0,32

18. Ejemplo COCOMO
Por ejemplo, si sabemos que en el proyecto se trabajará con un nivel alto de
utilización de herramientas de desarrollo, el factor de coste tendrá un valor de 0,91.
•Por lo tanto, si el esfuerzo nominal calculado es de 40 personas-mes, la estimación
de coste final (suponiendo el resto de factores a nivel medio) será E = 40x0,91 = 36,4
personas-mes
• Se trata de estimar el esfuerzo de desarrollo de un sistema de comunicaciones de 30
KDLC, de alta complejidad.
Afortunadamente podremos emplear personal de muy alta cualificación con una gran
experiencia específica en este tipo de software.
El coste del salario mensual de cada persona es de 1.350 _/mes
Si aplicamos COCOMO, podemos ver que el esfuerzo estimado será:
Esfuerzo nominal = 3,2 x (30)1,05 = 113,79 personas-mes.

19. 5.5.-Modelo de Estimación de Putnam
Es un modelo multivariable dinámico que asume una distribución especifica del
esfuerzo a lo largo de la vida de un proyecto de desarrollo de Software .
5.6 Modelos del Punto Función
Las métricas del software orientadas a la función son medidas indirectas del
software y del proceso por el cual se desarrolla. Más que calcular las LDC las
métricas orientadas a la función se centran en la funcionalidad o utilidad del
programa
5.7 Modelo de estudio temporal
En un nivel individual, el proceso de desarrollo del software se ve afectado
por un numero n de gente interaccionando en el proyecto y por las
características del entorno en el cual esa gente interacciona.

20. 6 HERRAMIENTAS AUTOMÁTICAS DE ESTIMACIÓN.
Las herramientas automáticas de estimación permiten al planificador estimar costos
y esfuerzos, así como llevar a cabo análisis del tipo, que pasa si, con importantes
variables del proyecto, tales como la fecha de entrega o la selección del personal.
7.- ESTIMACIÓN DE LOS COSTOS DE MANTENIMIENTO DE SOFTWARE
La mayor preocupación con respecto al mantenimiento durante la fase de
plantación de un proyecto de programación es estimar el número de
programadores de mantenimiento que se requerirán, así como especificar las
facilidades necesarias para que se lleve acabo.
Actividad % del esfuerzo
Mejoras 51.3
Mayor eficiencia 4.0
Mejor documentación 5.5
Mejoras para el usuario 41.8
Adaptación 23.6
Datos de entrada y archivos 17.4
Equipo y sistema operativo 6.2
Correcciones 21.7
Arreglos de emergencia 12.4
Arreglos programados 9.3
Otros 3.4

21. Ejemplos de posibles riesgos en el desarrollo de software
riesgo tipo de riesgo descripción
proyecto, producto personal con experiencia abandona el proyecto antes de que
rotación de personal
y negocio finalice
cambio de cambio de administración organizativa con diferentes
proyecto
administración prioridades
no disponibilidad del
proyecto el hardware necesario para el proyecto no se recibe a tiempo
hardware
cambios de proyecto y existencia de más cambios de requerimientos de los previstos
requerimientos producto inicialmente
retrasos en la proyecto y
retrasos en las especificaciones de interfaces esenciales
especificación producto
subestimación del proyecto y
el tamaño del sistema se ha subestimado
tamaño producto
bajo rendimiento de
las herramientas CASE que ayudan al proyecto no tienen el
la herramienta producto
rendimiento y las funcionalidades esperadas
CASE
cambio de la tecnología fundamental sobre la que se está construyendo el
negocio
tecnología sistema es sustituida por una nueva
competencia del un producto competitivo se pone en venta antes de que el
negocio
producto sistema se complete

22. 8 Conclusiones
En conclusión la planificación del Proyecto de Software tiene que estimar tres
cosas antes de que comience el proyecto: cuanto durara, cuanto esfuerzo
requerirá y cuanta gente estará implicada. Además el planificador debe predecir
los recursos de hardware y software que va a requerir y el riesgo implicado

23. Cualquier cosas que necesites
cuantificar debe ser medido
y de alguna forma es superior
a no medirlo del todo
Tom Gilb