COCOMO
DEFINICIÓN:
El Modelo Constructivo de Costos (o COCOMO, por su acrónimo del inglés COnstructive COst MOdel) es un modelo matemático de base empírica utilizado para estimación de costos1 de software. Incluye tres submodelos, cada uno ofrece un nivel de detalle y aproximación, cada vez mayor, a medida que avanza el proceso de desarrollo del software: básico, intermedio y detallado.
Este modelo fue desarrollado por Barry W. Boehm a finales de los años 70 y comienzos de los 80, exponiéndolo detalladamente en su libro "Software Engineering Economics" (Prentice-Hall, 1981).
Este modelo fue desarrollado por Barry W. Boehm a finales de los años 70 y comienzos de los 80, exponiéndolo detalladamente en su libro "Software Engineering Economics" (Prentice-Hall, 1981).
Modelos de estimación:
Las ecuaciones que se utilizan en los tres modelos son:2
E = a(Kl)^b*m(X), en persona-mes
Tdev = c(E)^d, en meses
P = E/Tdev, en personas
donde:
Las ecuaciones que se utilizan en los tres modelos son:2
E = a(Kl)^b*m(X), en persona-mes
Tdev = c(E)^d, en meses
P = E/Tdev, en personas
donde:
- E es el esfuerzo requerido por el proyecto, en persona-mes
- Tdev es el tiempo requerido por el proyecto, en meses
- P es el número de personas requerido por el proyecto
- a, b, c y d son constantes con valores definidos en una tabla, según cada submodelo
- Kl es la cantidad de líneas de código, en miles.
- m(X) Es un multiplicador que depende de 15 atributos.
A la vez, cada submodelo también se divide en modos que representan el tipo de proyecto, y puede ser:
- modo orgánico: un pequeño grupo de programadores experimentados desarrollan software en un entorno familiar. El tamaño del software varía desde unos pocos miles de líneas (tamaño pequeño) a unas decenas de miles (medio).
- modo semilibre o semiencajado: corresponde a un esquema intermedio entre el orgánico y el rígido; el grupo de desarrollo puede incluir una mezcla de personas experimentadas y no experimentadas.
- modo rígido o empotrado: el proyecto tiene fuertes restricciones, que pueden estar relacionadas con la funcionalidad y/o pueden ser técnicas. El problema a resolver es único y es difícil basarse en la experiencia, puesto que puede no haberla.
Modelo básico:
Se utiliza para obtener una primera aproximación rápida del esfuerzo,2 y hace uso de la siguiente tabla de constantes para calcular distintos aspectos de costes:
Se utiliza para obtener una primera aproximación rápida del esfuerzo,2 y hace uso de la siguiente tabla de constantes para calcular distintos aspectos de costes:
MODO
|
a
|
b
|
c
|
d
|
Orgánico
|
2.40
|
1.05
|
2.50
|
0.38
|
Semi - Orgánico
|
3.00
|
1.12
|
2.50
|
0.35
|
Empotrado
|
3.60
|
1.20
|
2.50
|
0.32
|
Estos valores son para las fórmulas:
Personas necesarias por mes para llevar adelante el proyecto (MM) = a*(Klb)
Tiempo de desarrollo del proyecto (TDEV) = c*(MMd)
Personas necesarias para realizar el proyecto (CosteH) = MM/TDEV
Costo total del proyecto (CosteM) = CosteH * Salario medio entre los programadores y analistas.
Se puede observar que a medida que aumenta la complejidad del proyecto (modo), las constantes aumentan de 2.4 a 3.6, que corresponde a un incremento del esfuerzo del personal. Hay que utilizar con mucho cuidado el modelo básico puesto que se obvian muchas características del entorno
Personas necesarias por mes para llevar adelante el proyecto (MM) = a*(Klb)
Tiempo de desarrollo del proyecto (TDEV) = c*(MMd)
Personas necesarias para realizar el proyecto (CosteH) = MM/TDEV
Costo total del proyecto (CosteM) = CosteH * Salario medio entre los programadores y analistas.
Se puede observar que a medida que aumenta la complejidad del proyecto (modo), las constantes aumentan de 2.4 a 3.6, que corresponde a un incremento del esfuerzo del personal. Hay que utilizar con mucho cuidado el modelo básico puesto que se obvian muchas características del entorno
Modelo intermedio:
Este añade al modelo básico quince modificadores opcionales para tener en cuenta en el entorno de trabajo, incrementando así la precisión de la estimación.
Para este ajuste, al resultado de la fórmula general se lo multiplica por el coeficiente surgido de aplicar los atributos que se decidan utilizar.
Los valores de las constantes a reemplazar en la fórmula son:
Este añade al modelo básico quince modificadores opcionales para tener en cuenta en el entorno de trabajo, incrementando así la precisión de la estimación.
Para este ajuste, al resultado de la fórmula general se lo multiplica por el coeficiente surgido de aplicar los atributos que se decidan utilizar.
Los valores de las constantes a reemplazar en la fórmula son:
MODO
|
a
|
b
|
Orgánico
|
3.20
|
1.05
|
Semi - Orgánico
|
3.00
|
1.12
|
Empotrado
|
2.80
|
1.20
|
Se puede observar que los exponentes son los mismos que los del modelo básico, confirmando el papel que representa el tamaño; mientras que los coeficientes de los modos orgánico y rígido han cambiado, para mantener el equilibrio alrededor del semilibre con respecto al efecto multiplicador de los atributos de coste.
Atributos
Cada atributo se cuantifica para un entorno de proyecto. La escala es muy bajo - bajo - nominal - alto - muy alto - extremadamente alto. Dependiendo de la calificación de cada atributo, se asigna un valor para usar de multiplicador en la fórmula (por ejemplo, si para un proyecto el atributo DATA es calificado como muy alto, el resultado de la fórmula debe ser multiplicado por 1000).
El significado de los atributos es el siguiente, según su tipo:
De software
RELY: garantía de funcionamiento requerida al software. Indica las posibles consecuencias para el usuario en el caso que existan defectos en el producto. Va desde la sola inconveniencia de corregir un fallo (muy bajo) hasta la posible pérdida de vidas humanas (extremadamente alto, software de alta criticidad).
DATA: tamaño de la base de datos en relación con el tamaño del programa. El valor del modificador se define por la relación: D / K, donde D corresponde al tamaño de la base de datos en bytes y K es el tamaño del programa en cantidad de líneas de código.
CPLX: representa la complejidad del producto.
De 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 requerido.
De personal
ACAP: calificación de los analistas.
AEXP: experiencia del personal en aplicaciones similares.
PCAP: calificación de los programadores.
VEXP: experiencia del personal en la máquina virtual.
LEXP: experiencia en el lenguaje de programación a usar.
De 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.
El valor de cada atributo, de acuerdo a su calificación, se muestra en la siguiente tabla:
Atributos
Cada atributo se cuantifica para un entorno de proyecto. La escala es muy bajo - bajo - nominal - alto - muy alto - extremadamente alto. Dependiendo de la calificación de cada atributo, se asigna un valor para usar de multiplicador en la fórmula (por ejemplo, si para un proyecto el atributo DATA es calificado como muy alto, el resultado de la fórmula debe ser multiplicado por 1000).
El significado de los atributos es el siguiente, según su tipo:
De software
RELY: garantía de funcionamiento requerida al software. Indica las posibles consecuencias para el usuario en el caso que existan defectos en el producto. Va desde la sola inconveniencia de corregir un fallo (muy bajo) hasta la posible pérdida de vidas humanas (extremadamente alto, software de alta criticidad).
DATA: tamaño de la base de datos en relación con el tamaño del programa. El valor del modificador se define por la relación: D / K, donde D corresponde al tamaño de la base de datos en bytes y K es el tamaño del programa en cantidad de líneas de código.
CPLX: representa la complejidad del producto.
De 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 requerido.
De personal
ACAP: calificación de los analistas.
AEXP: experiencia del personal en aplicaciones similares.
PCAP: calificación de los programadores.
VEXP: experiencia del personal en la máquina virtual.
LEXP: experiencia en el lenguaje de programación a usar.
De 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.
El valor de cada atributo, de acuerdo a su calificación, se muestra en la siguiente tabla:
Atributos
|
Valor
|
|||||
Muy bajo
|
Bajo
|
Nominal
|
Alto
|
Muy alto
|
Extra alto
|
|
Atributos de software
|
||||||
Fiabilidad
|
0,75
|
0,88
|
1,00
|
1,15
|
1,40
|
|
Tamaño
de Base de datos
|
0,94
|
1,00
|
1,08
|
1,16
|
||
Complejidad
|
0,70
|
0,85
|
1,00
|
1,15
|
1,30
|
1,65
|
Atributos de hardware
|
||||||
Restricciones
de tiempo de ejecución
|
1,00
|
1,11
|
1,30
|
1,66
|
||
Restricciones
de memoria virtual
|
1,00
|
1,06
|
1,21
|
1,56
|
||
Volatilidad
de la máquina virtual
|
0,87
|
1,00
|
1,15
|
1,30
|
||
Tiempo
de respuesta
|
0,87
|
1,00
|
1,07
|
1,15
|
||
Atributos de personal
|
||||||
Capacidad
de análisis
|
1,46
|
1,19
|
1,00
|
0,86
|
0,71
|
|
Experiencia
en la aplicación
|
1,29
|
1,13
|
1,00
|
0,91
|
0,82
|
|
Calidad
de los programadores
|
1,42
|
1,17
|
1,00
|
0,86
|
0,70
|
|
Experiencia
en la máquina virtual
|
1,21
|
1,10
|
1,00
|
0,90
|
||
Experiencia
en el lenguaje
|
1,14
|
1,07
|
1,00
|
0,95
|
||
Atributos del proyecto
|
||||||
Técnicas
actualizadas de programación
|
1,24
|
1,10
|
1,00
|
0,91
|
0,82
|
|
Utilización
de herramientas de software
|
1,24
|
1,10
|
1,00
|
0,91
|
0,83
|
|
Restricciones
de tiempo de desarrollo
|
1,22
|
1,08
|
1,00
|
1,04
|
1,10
|
|
Modelo Detallado:
Presenta principalmente dos mejoras respecto al anterior:
Presenta principalmente dos mejoras respecto al anterior:
- Los factores correspondientes a los atributos son sensibles o dependientes de la fase sobre la que se realizan las estimaciones. Aspectos tales como la experiencia en la aplicación, utilización de herramientas de software, etc., tienen mayor influencia en unas fases que en otras, y además van variando de una etapa a otra.
- Establece una jerarquía de tres niveles de productos, de forma que los aspectos que representan gran variación a bajo nivel, se consideran a nivel módulo, los que representan pocas variaciones, a nivel de subsistema; y los restantes son considerados a nivel sistema.
Ejemplo Estimación con el método de Cocomo
Entre los distintos métodos de estimación de costes de desarrollo de software, el modelo COCOMO (COnstructive COst MOdel) desarrollado por Barry M. Boehm, se engloba en el grupo de los modelos algorítmicos que tratan de establecer una relación matemática la cual permite estimar el esfuerzo y tiempo requerido para desarrollar un producto.
Por un lado COCOMO define tres modos de desarrollo o tipos de proyectos:
• Orgánico: proyectos relativamente sencillos, menores de 50 KDLC líneas de código, en los cuales se tiene experiencia de proyectos similares y se encuentran en entornos estables.
• Semi-acoplado: proyectos intermedios en complejidad y tamaño (menores de 300 KDLC), donde la experiencia en este tipo de proyectos es variable, y las restricciones intermedias.
• Empotrado: proyectos bastante complejos, en los que apenas se tiene experiencia y se engloban en un entorno de gran innovación técnica. Además se trabaja con unos requisitos muy restrictivos y de gran volatilidad.
Y por otro lado existen diferentes modelos que define COCOMO:
• Modelo básico: Se basa exclusivamente en el tamaño expresado en LDC.
• Modelo intermedio: Además del tamaño del programa incluye un conjunto de medidas subjetivas llamadas conductores de costes.
• Modelo avanzado: Incluye todo lo del modelo intermedio además del impacto de cada conductor de coste en las distintas fases de desarrollo.
Para nuestro caso el modelo intermedio será el que usaremos, dado que realiza las estimaciones con bastante precisión.
Así pues las fórmulas serán las siguientes:
• E = Esfuerzo = a KLDC e * FAE (persona x mes)
• T = Tiempo de duración del desarrollo = c Esfuerzo d (meses)
• P= Personal = E/T (personas)
Para calcular el Esfuerzo, necesitaremos hallar la variable KDLC (Kilo-líneas de código), donde los PF son 261,36 (dato conocido) y las líneas por cada PF equivalen a 32 según vemos en la tabla que se ilustra a continuación:
LENGUAJE
|
|
Ensamblador
|
320
|
C
|
150
|
COBOL
|
105
|
Pascal
|
91
|
Prolog/LISP
|
64
|
C++
|
64
|
Visual Basic
|
32
|
SQL
|
12
|
Así pues tras saber que son 32 LDC por cada PF, por el hecho de ser Visual Basic el resultado de los KDLC será el siguiente:
KLDC= (PF * Líneas de código por cada PF)/1000 = (261,36*32)/1000= 8,363 KDLC
Así pues, en nuestro caso el tipo orgánico será el más apropiado ya que el número de líneas de código no supera los 50 KLDC, y además el proyecto no es muy complejo, por consiguiente, los coeficientes que usaremos serán las siguientes:
KLDC= (PF * Líneas de código por cada PF)/1000 = (261,36*32)/1000= 8,363 KDLC
Así pues, en nuestro caso el tipo orgánico será el más apropiado ya que el número de líneas de código no supera los 50 KLDC, y además el proyecto no es muy complejo, por consiguiente, los coeficientes que usaremos serán las siguientes:
Proyecto Software
|
a
|
e
|
c
|
d
|
Orgánico
|
3,2
|
1,05
|
2,5
|
0,38
|
Semi-acoplado
|
3,0
|
1,12
|
2,5
|
0,35
|
Empotrado
|
2,8
|
1,20
|
2,5
|
0,32
|
Y por otro lado también hemos de hallar la variable FAE, la cual se obtiene mediante la multiplicación de los valores evaluados en los diferentes 15 conductores de coste que se observan en la siguiente tabla:
Conductores de coste
|
VALORACIÓN
|
|||||
Muy bajo
|
Bajo
|
Nominal
|
Alto
|
Muy
alto
|
Extr. alto
|
|
Fiabilidad
requerida del software
|
0,75
|
0,88
|
1.00
|
1,15
|
1,40
|
-
|
Tamaño
de la base de datos
|
-
|
0,94
|
1.00
|
1,08
|
1,16
|
-
|
Complejidad
del producto
|
0,70
|
0,85
|
1.00
|
1,15
|
1,30
|
1,65
|
Restricciones
del tiempo de ejecución
|
-
|
-
|
1.00
|
1,11
|
1,30
|
1,66
|
Restricciones
del almacenamiento principal
|
-
|
-
|
1.00
|
1,06
|
1,21
|
1,56
|
Volatilidad
de la máquina virtual
|
-
|
0,87
|
1.00
|
1,15
|
1,30
|
-
|
Tiempo de
respuesta del ordenador
|
-
|
0,87
|
1.00
|
1,07
|
1,15
|
-
|
Capacidad del
analista
|
1,46
|
1,19
|
1.00
|
0,86
|
0,71
|
-
|
Experiencia
en la aplicación
|
1,29
|
1,13
|
1.00
|
0,91
|
0,82
|
-
|
Capacidad de
los programadores
|
1,42
|
1,17
|
1.00
|
0,86
|
0,70
|
-
|
Experiencia
en S.O. utilizado
|
1,21
|
1,10
|
1.00
|
0,90
|
-
|
-
|
Experiencia
en el lenguaje de programación
|
1,14
|
1,07
|
1.00
|
0,95
|
-
|
-
|
Prácticas de
programación modernas
|
1,24
|
1,10
|
1.00
|
0,91
|
0,82
|
-
|
Utilización
de herramientas software
|
1,24
|
1,10
|
1.00
|
0,91
|
0,83
|
-
|
Limitaciones
de planificación del proyecto
|
1,23
|
1,08
|
1.00
|
1,04
|
1,10
|
-
|
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
Justificación de los valores:
Atributos de software
• Fiabilidad requerida del software: Si se produce un fallo por el pago de un pedido, o fallo en alguna reserva, etc... puede ocasionar grandes pérdidas a la empresa (Valoración Alta).
• Tamaño de la base de datos: La base de datos de nuestro producto será de tipo estándar (Valoración Nominal).
• Complejidad del producto: La aplicación no va a realizar cálculos complejos (Valoración Baja).
Atributos de hardware
• Restricciones del tiempo de ejecución: En los requerimientos se exige alto rendimiento (Valoración Alta).
• Restricciones del almacenamiento principal: No hay restricciones al respecto (Valoración Nominal).
• Volatilidad de la máquina virtual: Se usarán sistemas de la “Familia Windows” (Valoración Nominal).
• Tiempo de respuesta del ordenador: Deberá ser interactivo con el usuario (Valoración Alta).
Atributos del personal
• Capacidad del analista: Capacidad alta relativamente, debido a la experiencia en análisis en proyecto similar (Valoración Alta)
• Experiencia en la aplicación: Se tiene cierta experiencia en aplicaciones de esta envergadura (Valoración muy alta).
• Capacidad de los programadores: Teóricamente deberá tenerse una capacidad muy alta por la experiencia en anteriores proyectos similares (Valoración muy alta).
• Experiencia en S.O. utilizado: Con Windows 2000 Professional la experiencia es a nivel usuario (Valoración Nominal).
• Experiencia en el lenguaje de programación: Es relativamente alta, dado que se controlan las nociones básicas y las propias del proyecto (Valoración Alta).
Atributos del proyecto
• Prácticas de programación modernas: Se usarán prácticas de programación mayormente convencional (Valoración Nominal).
• Utilización de herramientas software: Se usarán herramientas estándar que no exigirán apenas formación, de las cuales se tiene cierta experiencia (Valoración Alta).
• Limitaciones de planificación del proyecto: Existen pocos límites de planificación. (Valoración Baja).
Cálculo del esfuerzo del desarrollo:
E = a KLDC e * 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 estas cifras será necesario un equipo de 3 personas trabajando alrededor de 7 meses, pero puesto que el desarrollo del proyecto debe realizarse en un plazo 3 meses, incrementaremos a 6 personas el número de personas del equipo de proyecto (ya que 15,91/3 nos da alrededor de este resultado).
Justificación de los valores:
Atributos de software
• Fiabilidad requerida del software: Si se produce un fallo por el pago de un pedido, o fallo en alguna reserva, etc... puede ocasionar grandes pérdidas a la empresa (Valoración Alta).
• Tamaño de la base de datos: La base de datos de nuestro producto será de tipo estándar (Valoración Nominal).
• Complejidad del producto: La aplicación no va a realizar cálculos complejos (Valoración Baja).
Atributos de hardware
• Restricciones del tiempo de ejecución: En los requerimientos se exige alto rendimiento (Valoración Alta).
• Restricciones del almacenamiento principal: No hay restricciones al respecto (Valoración Nominal).
• Volatilidad de la máquina virtual: Se usarán sistemas de la “Familia Windows” (Valoración Nominal).
• Tiempo de respuesta del ordenador: Deberá ser interactivo con el usuario (Valoración Alta).
Atributos del personal
• Capacidad del analista: Capacidad alta relativamente, debido a la experiencia en análisis en proyecto similar (Valoración Alta)
• Experiencia en la aplicación: Se tiene cierta experiencia en aplicaciones de esta envergadura (Valoración muy alta).
• Capacidad de los programadores: Teóricamente deberá tenerse una capacidad muy alta por la experiencia en anteriores proyectos similares (Valoración muy alta).
• Experiencia en S.O. utilizado: Con Windows 2000 Professional la experiencia es a nivel usuario (Valoración Nominal).
• Experiencia en el lenguaje de programación: Es relativamente alta, dado que se controlan las nociones básicas y las propias del proyecto (Valoración Alta).
Atributos del proyecto
• Prácticas de programación modernas: Se usarán prácticas de programación mayormente convencional (Valoración Nominal).
• Utilización de herramientas software: Se usarán herramientas estándar que no exigirán apenas formación, de las cuales se tiene cierta experiencia (Valoración Alta).
• Limitaciones de planificación del proyecto: Existen pocos límites de planificación. (Valoración Baja).
Cálculo del esfuerzo del desarrollo:
E = a KLDC e * 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 estas cifras será necesario un equipo de 3 personas trabajando alrededor de 7 meses, pero puesto que el desarrollo del proyecto debe realizarse en un plazo 3 meses, incrementaremos a 6 personas el número de personas del equipo de proyecto (ya que 15,91/3 nos da alrededor de este resultado).
Así pues tendremos un equipo formado por 1 Jefe de proyecto, 2 Analistas, 2 programadores y 1 Responsable de calidad.
RESUMEN:
El
Modelo Constructivo de Costos (o COCOMO, por su acrónimo del inglés
COnstructive COst MOdel) es un modelo matemático de base empírica
utilizado para estimación de costos1 de software. Incluye tres
submodelos, cada uno ofrece un nivel de detalle y aproximación, cada vez
mayor, a medida que avanza el proceso de desarrollo del software:
básico, intermedio y detallado.
Modelo básico:
Se utiliza para obtener una primera aproximación rápida del esfuerzo,2 y hace uso de la siguiente tabla de constantes para calcular distintos aspectos de costes:
Se utiliza para obtener una primera aproximación rápida del esfuerzo,2 y hace uso de la siguiente tabla de constantes para calcular distintos aspectos de costes:
Modelo intermedio:
Este añade al modelo básico quince modificadores opcionales para tener en cuenta en el entorno de trabajo, incrementando así la precisión de la estimación.
Este añade al modelo básico quince modificadores opcionales para tener en cuenta en el entorno de trabajo, incrementando así la precisión de la estimación.
Modelo Detallado:
Los
factores correspondientes a los atributos son sensibles o dependientes
de la fase sobre la que se realizan las estimaciones. Aspectos tales
como la experiencia en la aplicación, utilización de herramientas de
software, etc., tienen mayor influencia en unas fases que en otras, y
además van variando de una etapa a otra.
SUMMARY:
El Modelo Constructivo de Costos (o COCOMO, por su acronimo del inglés COnstructive modelo del costo) Es Un modelo matemático de la base empírica utilizado para estimation de costos1 de software. Incluye Tres submodelos, Cada Uno offers ONU Nivel de detalle y aproximación, Cada Vez Mayor, una Medida que Avanza El Proceso de Desarrollo del software: básico, intermedio y Detallado.
Modelo básico:
Se utilizació para Obtener Una primera aproximación Rápida del Esfuerzo, 2 y Hace USO de la siguiente tabla de Constantes para Calcular Distintos Aspectos de Costes:
Modelo intermedio:
Este ánade al modelo básico de membrillo Modificadores Opcionales para Tener en Cuenta en el Entorno de Trabajo, incrementando Así la precisión Que de la estimation.
Modelo Detallado:
Los Factores correspondientes a los Atributos hijo Sensibles o Dependientes De La Fase Sobre La Que Se Realizan las estimaciones. Aspectos cuentos Como la Experiencia en la Aplicación, utilizacion de Herramientas de software, etc., Tienen alcalde f influencia en Unas Fases Que En otras, y van variando: Además De Una Etapa una otra.
Modelo básico:
Se utilizació para Obtener Una primera aproximación Rápida del Esfuerzo, 2 y Hace USO de la siguiente tabla de Constantes para Calcular Distintos Aspectos de Costes:
Modelo intermedio:
Este ánade al modelo básico de membrillo Modificadores Opcionales para Tener en Cuenta en el Entorno de Trabajo, incrementando Así la precisión Que de la estimation.
Modelo Detallado:
Los Factores correspondientes a los Atributos hijo Sensibles o Dependientes De La Fase Sobre La Que Se Realizan las estimaciones. Aspectos cuentos Como la Experiencia en la Aplicación, utilizacion de Herramientas de software, etc., Tienen alcalde f influencia en Unas Fases Que En otras, y van variando: Además De Una Etapa una otra.
RECOMENDACIONES:
- Analizar las funciones del COCOMO para el desarrollo del proyecto de software .
CONCLUSIONES:
- Es necesario hacer mas investigaciones acerca de cómo medir todos los factores que afectan los sistemas de productividad profesional, si la profesión es encontrarse con los cambios del futuro.
LINKOGRAFIA:
- https://es.wikipedia.org/wiki/COCOMO
Presenatción en Power Point : SlideSahre Cocomo
No hay comentarios:
Publicar un comentario