estimacion de costo del software "cocomo"

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


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


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


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


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


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…


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).


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


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.


• 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


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:


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:


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-


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


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.


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


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.


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


estimacion de costo del software "cocomo"

Education