República Bolivariana de VenezuelaMinisterio del Poder Popular Para la Educación Superior Universitaria
Colegio Universitario de CaracasPrograma Nacional de Formación en Informática
Trayecto IV / Trimestre:IUnidad Curricular : Gestión de Proyecto.
ESTIMACION DE COSTO DEL SOFTWARE
Alumnos:José Luis Martínez 10.826.854
Douglas López 13.609.150Ruth Medina 10.350.059Rosa Rangel 10.486.685
Ingeniería del Software Página 1
Contenido:
1. Introducción
2. Factores que influyen en el costo del software
3. El proceso de Estimación
4. Técnica de estimación de costo:
Modelo de Costos COCOMO
5. Consejos sobre estimaciones
6. Procedimientos sugeridos para la estimación de costos
7. Conclusión
8. Bibliografía
Ingeniería del Software Página 2
1. INTRODUCCIÓN
Todo proyecto de ingeniería de software debe partir con un buen plan. Uno de los
aspectos que dificultan la labor de administradores y jefes de proyecto en torno a la
planificación es la difícil tarea de realizar una estimación de costos y plazos realista.
Existen técnicas para la estimación de costos, lo que permitirá obtener medidas
cuantitativas cuando todo lo que existe son datos cualitativos.
El manejador de costo principal para un proyecto de desarrollo de software es sin
duda el tamaño del producto. La medida del tamaño debe ser tal que esté en relación
directa con el esfuerzo de desarrollo, por lo que las métricas de tamaño tratan de con-
siderar todos los aspectos que influyen en el costo, como tecnología, tipos de recursos
y complejidad.
Barry Boehm en su libro "economía de la ingeniería de software" detalla un mode-
lo amplio de estimación de costos llamado COCOMO (Constructive Cost Model). La
palabra "constructive" se refiere a el hecho que el modelo ayuda a un estimador a
comprender mejor la complejidad del software; este modelo es un ejemplo de varia-
ble simple estático y es usado por miles de administradores de proyecto de software.
2. FACTORES QUE INFLUYEN EN EL COSTO DEL SOFTWARE
Ingeniería del Software Página 3
La estimación de lo que costará el desarrollo de un software es una de las activida-
des de planeación que reviste especial importancia, ya que una de las características
que debe tener un producto de software es que su costo sea adecuado, de lo contrario
el proyecto puede fracasar.
Muchas organizaciones utilizan una serie de estimaciones de costos parciales antes
de emitir el costo definitivo. Se hace una estimación durante el estudio preliminar del
problema y se revisa durante el análisis de factibilidad del proyecto. Una estimación
mejorada se presenta durante las especificaciones del software y la estimación final
durante la revisión del diseño.
Los factores que principalmente afectan el costo del software son:
A. Capacidad del programador
B. Complejidad del producto
C. Tamaño del proyecto
D. Tiempo disponible
E. Confiabilidad requerida
F. Nivel Tecnológico
A. CAPACIDAD DEL PROGRAMADOR
La producción de productos de programación son tareas complicadas, por lo que la
productividad es función directa de la capacidad individual. Los programadores que
Ingeniería del Software Página 4
se muestran competentes en el procesamiento de datos, suelen no serlo en áreas cien-
tíficas y de igual forma, un buen programador científico no es, forzosamente, un buen
programador de sistemas. Por tanto, la falta de familiaridad con el área de aplicación
puede implicar baja productividad y por ende mayor costo y esfuerzo.
B. COMPLEJIDAD DEL PRODUCTO
C. TAMAÑO DEL PROYECTO
Un proyecto grande de programación es obviamente más cara en su desarrollo que
uno pequeño.
D. TIEMPO DISPONIBLE
El esfuerzo total del proyecto se relaciona con el calendario de trabajo asignado
para la terminación del proyecto.
E. CONFIABILIDAD REQUERIDA
Ingeniería del Software Página 5
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
Baja
Nominal
Alta
Muy Alta
Algunas molestias menor
Las pérdidas son fáciles de recuperar
Dificultad relativa en la recuperación
Gran pérdida financiera
Riesgo de una vida
0.75
0.88
1.00
1.15
1.40
F. NIVEL TECNOLÓGICO
El nivel de tecnología empleado en un proyecto de programación se refle-
ja en el lenguaje utilizado.
3. PROCESO DE ESTIMACIÓN
Ingeniería del Software Página 6
4. MODELO DE COSTOS COCOMO
Características principales:
• Está basado en modelos de estimaciones matemáticas.
• Está orientado al producto final, no a fases intermedias.
• Se basa en la cantidad de líneas de código del proyecto.
Inconvenientes del modelo COCOMO:
• Comentarios en líneas de código.
• Estimaciones sobre un nº de líneas de código variable.
• No se le da importancia a la productividad, referente a los hábitos de trabajo
• Dificultad para contemplar costes de revisiones, reuniones…
Ingeniería del Software Página 7
El proceso para crear una planificación de desarrollo
exacta consta de tres pasos:
Estimar el tamaño del producto (en número de líneas de código fuente o puntos de función).
Estimar el esfuerzo(Personas - mes).
Estimar el plan(meses).
El modelo provee tres "niveles" de aplicación: básico, intermedio y avanzado, ba-
sados en los factores considerados por el modelo.
Básico, es un modelo estático simplemente evaluado que calcula el esfuerzo (y
costo) del desarrollo del software como función del programa expresado en líneas de
código (LDC estimados).
Intermedio, calcula el esfuerzo del desarrollo del software como función del tama-
ño del programa y un conjunto de "guías de costo" que incluye una evaluación subje-
tiva del producto, hardware, personal y de los atributos del proyecto.
Avanzado, incorpora todas las características de la versión intermedia con una
evaluación del impacto de las vías de costo en cada fase (análisis, diseño, etc.) del
proceso de la ingeniería de software.
El modelo básico se extiende para considerar un conjunto de atributos de guías de
costo que pueden agruparse en cuatro categorías principales:
Producto (por ej. Requerimientos de software, confiabilidad, tamaño de la base de
datos, y complejidad del producto).
Computadora (por ej. Restricciones en el tiempo de ejecución y almacenamiento).
Personal (por ej. Capacidad de análisis, experiencia en aplicaciones tanto en len-
guajes de programación y capacidad del programador).
Proyecto (por ej. Uso de prácticas modernas de programación, uso de herramientas
de software y requerimiento de un plan de desarrollo).
Ingeniería del Software Página 8
En cada nivel de aplicación están definidos para tres tipos de proyectos de softwa-
re:
Modo orgánico, proyectos de software relativamente pequeños y sencillos en los
que pequeños equipos con buena experiencia en la aplicación trabajan en un conjunto
de requerimientos poco rígidos.
Modo semi−acoplado (semi−detached), un proyecto de software intermedio en
tamaño y complejidad en el cual equipos con distintos niveles de experiencia debe sa-
tisfacer requerimientos poco y medio rígidos.
Modo acoplado (detached), un proyecto de software que debe ser desarrollado
dentro un conjunto estricto de hardware, software y de restricciones operativas.
Modos que están basados en la complejidad de la aplicación y el desarrollo del
ambiente. El modelo de esfuerzo general aplicable a todos los niveles de aplicación y
modos está dado por:
El modelo básico se usa para obtener una aproximación rápida del esfuerzo.
Usa las variables a, b, c y d, que varían en función de los modos.
Conforme se aumenta la complejidad del modo, aumentan los valores de las va-
riables (esfuerzo).
Personas necesarias para llevar a cabo el proyecto: (MM) = a*(Klb)
Tiempo de desarrollo del proyecto: (TDEV) = c*(MMd)
Personas necesarias para el proyecto: (CosteH) = MM/TDEV
Coste total del proyecto: (CosteM) = CosteH * Salario medio
Ingeniería del Software Página 9
Modo básico utiliza el tamaño y el modo intermedio 15 manejadores de costo que
son los siguientes:
• Software:
• RELY: Indica las consecuencias para el usuario si falla el
producto.
• DATA: Relación Tamaño de la BD / Líneas de código.
• CPLX: Complejidad del producto.
• Hardware:
• TIME: Limitaciones en el porcentaje del uso de la CPU.
• STOR: Limitaciones en el porcentaje del uso de la memoria.
• VIRT: Volatilidad de la máquina virtual.
• TURN: Tiempo de respuesta.
• Personal:
• ACAP: calificación de los analistas.
• AEXP: experiencia del personal.
• PCAP: calificación de los programadores.
• VEXP: experiencia del personal en la máquina virtual.
• LEXP: experiencia en el lenguaje.
• Proyecto:
• MODP: uso de prácticas modernas de programación.
Ingeniería del Software Página 10
• TOOL: uso de herramientas de desarrollo de software.
• SCED: limitaciones en el cumplimiento de la planificación.
Ejemplo
Se debe desarrollar un software de no muy elevada dificultad, con las siguientes
restricciones:
3 meses para el desarrollo del proyecto software.
Debe estar implementado en el lenguaje Visual Basic.
Calculo del esfuerzo:
Se necesita hallar la variable KDLC.
LENGUAJE LDC/PF
Ensamblador 320
C 150
COBOL 105
Pascal 91
Prolog/LISP 64
C++ 64
Visual Basic 32
SQL 12
Ingeniería del Software Página 11
KLDC = (PF * Líneas de código por cada PF)/1000 = (261,36*32)/1000 =
8,363
Usar el tipo Orgánico ya que el proyecto no supera las 50 KLDC, y es el mas
apropiado en este caso.
Coeficientes a usar:
PROYECTO SOFTWARE a b c d
Orgánico 3,2 1,05 2,5 0,38
Semi-acoplado 3,0 1,12 2,5 0,35
Acoplado 2,8 1,20 2,5 0,32
Calculo de la variable FAE:
Ingeniería del Software Página 12
Calculo de la variable FAE:
FAE = 1,15 * 1,00 * 0,85 * 1,11 * 1,00 * 1,00 * 1,07 * 0,86 * 0,82 * 0,70 *
1,00 * 0,95 * 1,00 * 0,91 * 1,08 = 0,53508480
Cálculo del esfuerzo del desarrollo:
E = a KLDC^(b) * FAE = 3,2 * (8.363)^1,05 * 0,53508480 = 15,91 personas
/mes
Cálculo tiempo de desarrollo:
Ingeniería del Software Página 13
T = c Esfuerzo d = 2,5 * (15,91)^0,38 = 7,15 meses
Productividad:
PR = LDC/Esfuerzo = 8363/15,91 = 525 ,64 LDC/personas mes
Personal promedio:
P = E/T = 15,91/7,15 = 2,22 personas
Según los resultados se necesita un equipo de 3 personas trabajando alrededor de 7
meses, pero como una restricción era 3 meses incrementamos a 6 el número de
personas. 1 Jefe de proyecto, 2 Analistas, 2 programadores y 1 Responsable de cali-
dad.
COCOMO II
El nuevo modelo incorporado en el año 1990, tiene características de los modelos
COCOMO 81 y Ada COCOMO. COCOMO II tiene también tres submodelos; El mo-
delo de composición de la aplicación es usada para estimar el esfuerzo y planificación
de proyectos que usa las herramientas integradas CASE (Computer Aided Software
Engineering) para un desarrollo rápido de la aplicación.
Realizando una comparación entre COCOMO 81 y COCOMO II; a este último se
le añadió nuevos manejadores de costos para la aplicaciones precedentes, flexibilidad
en el desarrollo, necesita documentación para el ciclo de vida, múltiples sitios de de-
sarrollo y requiere software reusable.
Modelo COCOMO II post−arquitectura cubre el actual desarrollo y mantenimiento
de un producto de software. Esta etapa del ciclo de vida procede mas a un costo efec-
Ingeniería del Software Página 14
tivo, si el ciclo de vida de una arquitectura de software ha sido desarrollada, validada
con respecto a la misión del sistema y establecida como un marco de trabajo para el
producto.
El modelo de post−arquitectura predice el esfuerzo de desarrollo del software, per-
sonas−mes (PM), utiliza un conjunto de 17 multiplicadores de manejadores de costo
(EM) y un conjunto de 5 escalas de manejadores de costo para determinar la escala
del exponente del proyecto (SF). Esta escalas de los manejadores de costo remplazan
los modos de aplicación (orgánico, semi−acoplado y acoplado); el modelo tiene la si-
guiente forma:
PM = A * (Size) 1.01 + "j5= 1* _ I17= 1 Emil
Los manejadores de costo tiene para elegir una de las seis posibilidades que son:
Very Low (VL), Low (L), Nominal (N), High (H), Very High (VH), y Extra High
(XH); no todos los rangos son válidos para todos los manejadores de costo.
ADA COCOMO
Barrí Bohema & Walter Rocíe, 1987, 1988 definen el nuevo modelo COCOMO,
llamado "Ada COCOMO".
Este modelo al igual que el COCOMO estándar utiliza los manejadores de costo y
ecuaciones anteriormente definidas.
COCOMO INCREMENTAL
Ingeniería del Software Página 15
Fue definido casi al mismo tiempo que Ada COCOMO. EL modelo COCOMO In-
cremental es una moderna alternativa para el tradicional modelo cascada de el desa-
rrollo de procesos de software.
El modelo de desarrollo Incremental COCOMO permite una variedad de desarro-
llo de procesos. En vez de modelar el software como a esfuerzo simple para obtener
un producto simple; el modelo incremental COCOMO permite desarrollar una serie
de proyectos de software concurrente y producir un producto intermedio.
Esta estrategia reduce risk y permite entregar un producto inicial más fácilmente al
cliente.
También existen algunas derivaciones de COCOMO como ser:
Cocots, (Constructive Cost).
Cossemo, (Constructive Staged Schedule & Effort Model).
Copromo, (Constructive Productivity Improvement Model).
Coqualmo.
Coradmo.
5. CONSEJOS SOBRE ESTIMACIONES
1. Evite estimaciones improvisadas (ojo de buen cubero).
2. Use datos de proyectos anteriores (método histórico).
3. Las estimaciones las debe hacer el desarrollador, no el directivo.
4. Estime por consenso.
5. Evite estimar el proyecto como un todo.
Ingeniería del Software Página 16
6. Estime por descomposición, es decir, estime cada función o requisito del so-
ftware individualmente. Luego la suma de ellos será la estimación del proyecto total.
7. Utilice diferentes técnicas de estimación, compare los resultados y resuelva las
diferencias.
8. Si es posible use una herramienta automática de estimación. Con esto tendrá
otro punto de comparación.
9. Refine sus estimaciones a medida que conozca más detalles del proyecto.
10. Emita una estimación preliminar después de revisar la Definición del Sistema.
Refínela durante el Análisis y de una estimación definitiva después de revisar el Dise-
ño. Si esto no es posible, trate de emitir su estimación definitiva al terminar el Análi-
sis. Si aún esto no es posible, deberá formularla solo con la Definición del Sistema
pero considere un factor de seguridad adecuado.
11. Presente sus estimaciones usando rangos o casos (mejor, más probable, peor).
12. Defienda sus estimaciones.
13. Finalmente UD. y su equipo son los que conocen el proyecto y lo desarrolla-
rán. En lo posible evite que un directivo le imponga una estimación que no esté justi-
ficada, para esto debe prepararse para defender sus estimaciones.
14. Negocie con el cliente.
6. PROCEDIMIENTOS SUGERIDOS PARA LA ESTIMACIÓN
DE COSTOS
Ingeniería del Software Página 17
1. Identificar todos los sub sistemas y los módulos del producto.
2. Estimar el tamaño o magnitud de cada módulo y luego del sistema en total.
3. Especificar los factores multiplicadores de esfuerzo para cada módulo, tal
como la complejidad del producto, la capacidad de los programadores, la experiencia
en el lenguaje de programación.
4. Estimar el tiempo de desarrollo de cada modulo y del sistema en total.
5. Determinar la cantidad de personal que integrará el equipo de programación.
6. Calcular el costo de desarrollo tomando en cuenta el tiempo, cantidad de per-
sonal y sueldo del personal.
7. Sumar los otros costos por planeación y análisis que no se hayan incluido an-
tes.
7. CONCLUSIÓN
Hoy en día es necesario para un administrador de proyectos poseer una herramien-
ta de estimación de costos; y esta herramienta puede ser COCOMO.
COCOMO representa el más extenso modelo empírico para la estimación de so-
ftware publicado hasta la fecha.
Existen herramientas automáticas que estiman costos basados en COCOMO como
ser: Costar, COCOMO 81.
Ingeniería del Software Página 18
Con la realización de este trabajo se amplía los conocimientos acerca de la estima-
ción de costos que es fundamental para un analista, administrador de proyecto.
8. BIBLIOGRAFÍA
Ian Somerville, "Software Engineering", cuarta Edicion.
R. S. Pressman, "Ingeniería de Software"
URL'S
http://www.reifer.com/cocomo_eff.htm
http://sunset.usc.edu/COCOMOII/cocomo81_pgm/cocomo81.html
Ingeniería del Software Página 19