Universidad Simón Bolívar
Ingeniería de Software 3
Enero-Marzo 2001

COCOMO II: Una Familia de Modelos de Estimación

Tabla de contenido

1. El modelo base de estimación
1.1 Factores de escalamiento del exponente (SF)
1.2 Multiplicadores de esfuerzo (EM)

2. Ajustes al modelo base por estimación más temprana (diseño pre-arquitectura)

3. Ajuste por mantenimiento
3.1 ¿Cómo estimar el número de líneas a modificarse y agregarse?

4. Estimación del número esperado de defectos

Lecturas adicionales

COCOMO II pasó a ser una familia de modelos de productividad, estimación y toma de decisiones. Lamentablemente muchos de los modelos siguen conservando parámetros claves que se prestan más a evaluaciones post-facto de productividad más que a estimaciones pre-facto. Algunos de los modelos se consideran en desarrollo, es decir que requieren todavía estudios para validarlos y calibrarlos.

Todas las constantes que aparecerán son sujetos a calibración según los datos históricos de la empresa que adopte el modelo. En este sentido no se distingue de COCOMO 81.
 

1. El Modelo Base de Estimación

Comenzaremos con el modelo "base" de COCOMO II, el cual corresponde al esfuerzo de desarrollo estimado una vez que se ha fijado la arquitectura del sistema (estimación del proceso post-arquitectura). Despues de presentar tal modelo base veremos cómo se ajusta el modelo para:

Paso 1: Estimación de puntos de función

Sugerimos comenzar el modelo según las ideas de N. Callaos, vistas el trimestre pasado, esto es considerar que cada pantalla o reporte a generar equivale a 8 puntos de función (de ahora en adelante pf).
 
Nota 1: Modelo más detallado
El modelo más detallado de N. Callaos (y más cónsono con la literatura sobre puntos de función, técnicamente "feature points") es:


La simplificación de N. Callaos consiste en considerar que toda pantalla o reporte vale 5 pf y que sólo el 60% de los puntos de función provienen de pantalla --el resto vienen de tablas o archivos lógicos.
 

Nota 2: Ajuste a puntos de función por complejidad de pantalla o reporte
N. Callaos también preve ajustar el número de puntos de función por pantalla, según el número de datos por pantalla. La matriz de factores multiplicativos de ajuste tiene por filas el número de tablas que requiere accesar cada pantalla y por columnas el número de items de datos en la pantalla.
 
Datos por pantalla
# de tablas
1-4
5-9
10+
1
0.5
1
1.5
2-3
...
...
...
4+
...
...
...
Nota 3: Puntos de función en COCOMO II
COCOMO II juega con la posible adopción de un modelo de puntos de función y uno de puntos de aplicación. Ambos son menos prácticos que la propuesta de N. Callaos. Considere que es posible que el modelo de N. Callaos sea más específico al desarrollo de sistemas de información en Venezuela y para 'optimos resultados requiere el uso de la metodología propia de Callaos y Asociados.
 
 

Paso 2: Conversión de puntos de función a KSLOC.

Recomiendo manejar las fórmulas básicas de COCOMO II en KSLOC. En COCOMO II se abandona definitivamente la idea de medir el tamaño del código en líneas físicas y se utilizan instrucciones o líneas lógicas de código fuente. Para medir a posteriori el número de líneas lógicas, Boehm pone a la disposición el programa CodeCount y las reglas sobre las cuales se basa tal programa.

Para efectos de Java, cada punto de función corresponde a 53 líneas lógicas de código fuente. Los factores para diferentes lenguajes se encuentran en:
 

http://www.spr.com/library/0Langtbl.htm

 

Paso 3: Aplicación de las fórmulas básicas de esfuerzo, tiempo calendario y personal requerido

La fórmula básica de esfuerzo (PM, person-months):
PM = 2.94 * TamañoE * PRODUCTORIA(i=1..n) EMi
donde
Tamaño se mide en KSLOC,
EMi corresponde a los factores de ajuste de costo.
E es el exponente no lineal, calculado según:
E = 0.91 + 0.01* SUMATORIA(i=1..5)SFi
donde SFi son parámetros de costo (cost-drivers).
Nota 4: Comparación respecto al esfuerzo en COCOMO 81
COCOMO 81 preveía:
PM = 2.4 * Tamaño1.05
En el nuevo modelo, el exponente de 1,0521 puede obtenerse a partir de los siguientes valores SF:


El modelo COCOMO ajustado según N. Callaos usa una constante de 2.4, el modelo orgánico de COCOMO 81 usaba 3.2. La diferencia en el factor corresponde a ajuste a la empresa desarrolladora. COCOMO 81, preveía sólo tres exponentes diferentes según el tipo de desarrollo (1.05 correspondía a desarrollos orgánicos, 1.12 a desarrollos semi-separados y 1.2 a desarrollos embebidos). COCOMO II podría abarcar más de mil valores diferentes, entre un mínimo de 0.91 y un máximo de 1.2262.
 

Nota 5: Valor del exponente para equipos del curso CI-4713
Para el caso de los equipos que desarrollaron Delta Pensum 2.1-2.3 estimo que el rango de valores para cada factor es: Esto da un rango de valores del exponente entre 1.0466 y 1.1683.
 

La fórmula básica para tiempo calendario del desarrollo TDEV:

TDEV = 3.67* PM0.28+0.002* SUMATORIA(i=1..5)SFi
Nota 6: Comparación con COCOMO 81
En COCOMO 81:
TDEV = 2.4 * PM0.35
Usando los mismos valores de SF que arrojaron un exponente E de 1.0521, cercano al viejo desarrollo orgánico, el exponente del tiempo calendario se incrementa de 0.35 a 0.5642!

COCOMO II preve que este exponente pueda variar de 0.28 a 0.9124,
 

Nota 7: Exponente del calendario para equipos del curso CI-4713
Para los rangos mencionados en la nota 5, el exponente en la fórmula de TDEV varía de 0.5532 a 0.7966.

Para estimar cuántas personas requiere el desarrollo:

PM/TDEV

1.1 Factores de escalamiento del exponente (SF)

Son cinco factores que afectan E, el exponente del TAMAÑO:
  • PREC: Desarrollos previos similares
  • FLEX: Flexibilidad del desarrollo (e.g. grado de acuerdo con requerimientos pre-establecidos o con interfaces externos pre-existente)
  • RESL: Manejo de riesgos y arquitectura
  • TEAM: Cohesión del equipo de desarrollo
  • EPML: nivel de madurez estimada, en relación al modelo de madurez de software CMM:

    • 1.2 Multiplicadores de esfuerzo (EM)

    Son 17: Más información sobre estos multiplicadores se encuentra en la sección 2.3.1 Scale Factors [Boehm, 2000].
     

    2. Ajustes al modelo base por estimación más temprana (diseño pre-arquitectura)

    COCOMO II sugiere que muchos de los 17 multiplicadores de esfuerzo no pueden estimarse en el diseño temprano, por lo que los reduce a 7 multiplicadores: La descripción de estos multiplicadores se encuentran en la sección 2.3.2.2 Early Design Model Drivers [Boehm, 2000].
     

    3. Ajuste por mantenimiento


    Francamente considero un poco decepcionante los ajustes por mantenimiento, ya que los parámetros del modelo  correspondiente de COCOMO II lucen muy difíciles de estimar en la práctica. Por esta razón, combinaremos las ideas de COCOMO II con las de N. Callaos.

    Se utilizan las mismas fórmulas que para desarrollo post-arquitectura, con las siguientes excepciones:

    1. No se consideran aplicables los multiplicadores SCED y RUSE, por argumentos que me resultan poco convincentes. En particular, pienso que el grado de mantenibilidad con que fue desarrollado el software (en cierto modo esto lo mide RUSE) tiene que impactar el grado de esfuerzo del mantenimiento.

    2. El multiplicador RELY (fiabilidad requerida para el software) depende de las exigencias de fiabilidad con que fue desarrollado el producto a mantener y que presumiblemente siguen imperando para el producto mantenido. La idea es que alejarse del valor nominal de fiabilidad incrementa el esfuerzo. Por un lado, si el producto fue desarrollado originalmente con un bajo grado de fiabilidad, costará más arreglarlo por su baja calidad; por otro lado si se desarroll'o con altos requerimientos de fiabilidad, costará más arreglarlo para no desmejorar su calidad. Los valores posibles para este multiplicador son:

    1. 1.23, si el software orginal contempla que la peor falla del sistema sólo conduce a una incomodidad leve del usuario (e.g. juegos);
    2. 1.10, si el software original contempla que a lo sumo sus fallas pueden conducir a pérdidas pequeñas, recuperables;
    3. 1.0, si el software puede conducir a fallas moderadas, fácilmente recuperables;
    4. 0.99, si las fallas del software pueden conducir a pérdidas financieras mayores;
    5. 1.07, si fallas del software ponen en riesgo alguna vida humana.


    3. Si se cambia menos del 50% del código existente puede utilizarse un modelo sencillo de mantenimiento;
     

    TAMmanten = (Códigoagregado + Códigomodif) * MAF + Códigoeliminado


    El multiplicador MAF toma en cuenta el toma en cuenta los factores SU y UNFM, según la fórmula:
     

    MAF = 1 + (SU/100 *UNFM)


    El factor SU refleja la dificultad en comprender el software a reutilizar y se estima subjetivamente según la siguiente tabla:
     

     
    Muy bajo
    Bajo
    Nominal
    Alto
    Muy alto
    Estructura
    Poca cohesión, acoplamiento alto, código "espagueti"
    Cohesión moderada, acoplamiento alto
    Razonablemente bien estructurado; algunas áreas fallas
    Cohesión alta, acoplamiento bajo
    Modularidad fuerte, información encapsulada, asbtracciones de datos y de control
    Correlación entre  la estructura del programa y la del mundo de la aplicación
    No hay correlación
    Algo de correlación
    Correlación moderada 
    Buena correlación 
    Alta correlación
    Documentación
    Oscura, confusa, obsoleta o incompleta
    Código parcialmente comentado, algo de documentación útil adicional
    Moderadamente completa y clara
    Buena, con algunas fallas
    Excelente, bien organizada, incluye justificaciones de diseño.
    SU
    50
    40
    30
    20
    10

    El factor UNFM pretende capturar el grado de familiarirización del programador con el código que está adaptando y toma los siguientes valores:

    MAF en COCOMO II varía entre 1 y 1.5. Para el desarrollo de Delta Pensum 2.3 calculo que MAF podría estar entre 1.12 y 1.3 , por cuanto estimo que SU estaría entre 20 y 30 y UNFM entre 0.6 y 1.0.
     

    3.1 ¿Cómo estimar el número de líneas a modificarse y agregarse?

    En la discusión anterior, se mide realmente la productividad de un mantenimiento, ya que se requiere conocer el número de líneas de cóidgo (KSLOC) agregadas, modificadas y eliminadas.

    Estas cifras son muy difíciles de estimar a priori, por lo que conviene nuevamente aprovechar los modelos de N. Callaos.

    Según el modelo de mantenimiento de N. Callaos, un mantenimiento perfectivo que involucra cambiar un campo, corresponde al 20% del esfuerzo de desarrollar originalmente la pantalla, mientras que agregar un campo nuevo corresponde al 10%. Tomando en cuenta que el mantenimiento perfectivo corresponde tan sólo al 55% del costo del mantenimiento (el resto corresponde a mantenimiento correctivo y adaptativo), deberíamos estimar el número de puntos de función PFbase para un mantenimiento tipo Delta Pensum según el siguiente esquema:
     


    Calculado PFbase tenemos dos opciones:


    Seguir las ideas de N. Callaos y considerar que un mantenimiento perfectivo siempre esconde cierto grado de mantenimiento correctivo (ciertamente fue el caso de Delta Pensum), por lo que agregaremos 36% de pf por ello. Si se incluye mantenimiento adaptativo, agregaremos 40% adicional. Es decir el total ajustado de puntos de función es o bien PFbase*1.36 o bien PFbase*1.76. Multiplicamos ese valor por el factor de traducción a Java (y dividimos por mil) para obtener TAMmanten en KSLOC. Este modelo arroja una estimación más alta del tamaño de código que la primera opción.
     

    Nota 8: Un modelo de mantenimiento más detallado --pero dificil de aplicar
    Una forma alterna de encontrar TAMmanten, según COCOMO es:

    Paso A:
    Obtenga TAMAdaptado, la suma de KSLOC debido a instrucciones nuevas e instrucciones modificadas, excluyendo aquellas líneas que son generadas automáticamente por alguna herramienta traductora (por ejemplo excluya las líneas que se generan por un compilador 4GL, porque se cambió de ambiente de ejecución).

    Paso B:
    Evalúe AAF, el llamado porcentaje de modificación. AAF se determina de la fórmula:

    AAF = 0.4*DM + 0.3*CM + 0.3*IM
    donde
    DM: porcentaje de diseño modificado, que se considera un factor totalmente subjetivo,
    CM: porcentaje del código modificado,
    IM: porcentaje de esfuerzo de integración.
    Estos porcentajes son dificiles de precisar: DM por su caracter subjetivo, CM por cuanto Boehm no precisa si, además de las líneas modificadas, cuentan las líneas agregadas (probablemente) y las eliminadas (no se especifica), e IM porque francamente veo dificil determinar "el porcentaje del esfuerzo que se requiere para integrar el software adaptado a un producto y probarlo, comparado con el esfuerzo normal de integración y prueba de un software nuevo de tamaño comparable".


    Paso C:
    Calcule AAM, el factor de ajuste por código adaptado. AAM se determina de la fórmula:

    AAM =
    [AA +AAF*(1 + 0.02*SU *UNFM)]/100, si AAF <= 50%

    [AA+AAF + (SU*UNFM)]/100, si AAF>50%


    AA es el grado de trabajo necesario para evaluar y asimilar el código, y es dado por la siguiente tabla:

    Paso D:
    Determine TAMequiv, el valor de KSLOC que COCOMO II considera equivalente en esfuerzo a desarrollo de código nuevo aplicando la siguiendo fórmula:
     
    TAMequiv = TAMAdaptado *AAM
    .
    Paso E:
    Ajuste el tamaño del mantenimiento TAMmanten , para tomar en cuenta código eliminado. Sencillament se suman las líneas eliminadas:
    TAMmanten = TAMequiv + Tamelim


    Paso F:
    Aplique las fórmulas del paso 3, sustituyendo TAMAÑO por TAMmanten y recordándose de los ajustes por mantenimiento 1,2.
     
     

    4. Estimación del número esperado de defectos

    La familia de modelos de COCOMO II incluye COQUALMO (COcomo QUAlity MOdels) conformado por dos modelos, un modelo de inyección de defectos y un modelo de remoción de defectos.

    La salida del modelo de inyección de defectos es el número de defectos no triviales, lo que incluye:

    Estos modelos están bajo desarrollo. Según una primera aproximación, las tasas de inyección base de defectos no triviales son:


    Note que COQUALMO considera que se genera una tasa de defectos por tamaño de código, a diferencia de TSP que considera que se genera por tiempo de desarrollo.

    Las tasas base de COQUALMO, pueden ajustarse con casi todos los multiplicadores y factores de ajuste salvo FLEX. Tentativamente se considera que los multiplicadores pueden ser de hasta:

    Note que para un desarrollo estimado de 3 KSLOC correspondiente al desarrollo de Delta Pensum entre Septiembre 2000 y Marzo 2001, este modelo arroja un estimado de 30 defectos de requerimientos, 60 de diseño y 90 de códificación. Desafortunadamente, la falta de una definición clara para lo que constituye un defecto de requerimiento o de diseño, nos deja con un estimado de entre 90 y 180 defectos por KSLOC (90 corresponde a sólo tomar los defectos de codificación, 180 a tomar los tipos de defectos; el modelo COQUALMO no explica claramente cuál de las opciones es la correcta). Utilizando la tasa preliminar dada en clase de 5 defectos por falla, esto arroja un número aproximado de entre 18 y 36 fallas, que correlaciona bastante bien con la cifra de 24 fallas, calculadas a partir de la adaptación de TSP. Sin embargo, las cifras  lucen altas si se considera que corresponde al rango base, sin ajuste por multiplicadores.

    No entraremos en detalle en el modelo de remoción de defectos. Basta con indicar que la tasa de remoción de defectos se ve afectado por inspecciones, herramientas de análisis y pruebas (de la ejecución). COQUALMO estima que la tasa residual de defectos puede variar entre 1.57 y 60 defectos por KSLOC: Las pruebas contribuyen a remover entre 23 y 88% de los defectos (pero, sólo de codificación?).
     

    Lecturas adicionales

    COCOMO II se presenta en: Información adicional puede encontrarse en el University of Southern California Center for Software Engineering:
    http://sunset.usc.edu/
    que presenta material sobre COCOMO, el modelo WinWin y el modelo de espiral.

    COCOMO 81 se presentó en:

    Los modelos de estimación de N. Callaos no se encuentran disponibles públicamente. Una interesante (y polémica) descripción de los fundamentos de la metodología que han desarrollado se encuentra en:


    Esta página fue creada el 27 de febrero de 2001.
    Ultima actualización: 1 de marzo de 2001.
    Por favor dirija sus comentarios al Prof. Alejandro Teruel.