2841_Apunte11COCOMOV2

7/23/2019 2841_Apunte11COCOMOV2

1/54

CCCCCCCCOOOOOOOOCCCCCCCCOOOOOOOOMMMMMMMMOOOOOOOO vvvvvvvv22222222MMooddeellooddeeEEssttiimmaacciinnddeeCCoosstteess

ppaarraapprrooyyeeccttoossssooffttwwaarree

ANTONIO DE LA FUENTE MOYAPROFESOR: Francisco Ruiz Gonzlez Cuarto Curso

Escuela Superior de InformticaASIGNATURA: Planificacin y Gestin deSistemas de Informacin Universidad de Castilla-La Mancha

MAYO 1999 Campus de Ciudad Real


2/54

Notas del Profesor sobre este trabajo

- El apndice B (Calibracin del modelo post-arquitectura no est incluida en estedocumento.

- Algunas frmulas tienen coeficientes que no coinciden con los utilizados en la

actualidad para el modelo COCOMO.

Consultar la pgina siguiente para informacin actualizada sobre los dos aspectos

anteriores:

http://sunset.usc.edu/research/COCOMOII/cocomo_main.html
http://sunset.usc.edu/research/COCOMOII/cocomo_main.htmlhttp://sunset.usc.edu/research/COCOMOII/cocomo_main.htmlhttp://sunset.usc.edu/research/COCOMOII/cocomo_main.html


3/54

i

NNDDIICCEE

Pgina

ANOTACIONES 1

INTRODUCCIN

SITUACIN 2

INTRODUCCIN A LAS TCNICAS DE ESTIMACIN DE COSTES 3+ PUNTOS FUNCIN 5+ MODELO COCOMO 81 8

- Modelo Bsico 9- Modelo Intermedio 10- Modelo Detallado 11- Calibracin del modelo 11

- Situacin a principios de los 90 13

COCOMO v.2.0

INTRODUCCIN 14

COCOMO 2.0: FUNDAMENTOS Y ESTRATEGIA 15+ ESTIMACIN DEL ESFUERZO DE DESARROLLO 17

- Nmero medio de Personas Mes 17- Breakage 17- Ajustando la Reusabilidad 17- Ajustando la Conversin o Reingeniera 20

+ ESTIMACIN DE LA PLANIFICACIN TEMPORAL DE DESARROLLO 20- Rangos de salida 21

ESCALA DE PRODUCTIVIDAD DEL SOFTWARE 22+ ESCALANDO LOS PARMETROS 22

- Precedentes (PREC) y Flexibilidad de Desarrollo (FLEX) 23- Resolucin de Arquitectura/Riesgos 24- Cohesin del Equipo de Trabajo 24- Madured del Proceso (PMAT) 24

MODELO DE COMPOSICIN DE APLICACIN 26

+ PROCEDIMIENTO PARA CONTAR PUNTOS OBJETO 26MODELO DE DISEO INICIAL 28

+ CUENTA DE PUNTOS FUNCIN 28+ PROCEDIMIENTO DE CUENTA DE PUNTOS FUNCIN DESAJUSTADOS 29+ CONVERSIN DE PUNTOS FUNCIN A LNEAS DE CDIGO 29+ PARMETROS DE COSTE (COST DRIVERS) 30

- Aproximacin global: Ejemplo de Capacidad Personal (PERS) 30- Complejidad y Confianza del Producto 31- Reutilizacin Requerida (RUSE) 32- Inconvenientes de la plataforma (PDIF) 32- Experiencia Personal (PREX) 32

- Facilidades (FCIL) 33- Planificacin (SCED) 33


4/54

ii

Pgina

MODELO POST-ARQUITECTURA 34+ NORMAS PARA CONTAR LAS LNEAS DE CDIGO 34+ PUNTOS FUNCIN 36+ PARMETROS DE COSTE 36

- Factores del Producto 36

- Factores de la Plataforma 39- Factores Personales 39- Factores del Proyecto 40

GLOSARIO 42

Apndice A: ECUACIONES 45+ COMPOSICIN DE APLICACIONES 45+ DISEO INICIAL 46+ POST-ARQUITECTURA 47+ ESTIMACIN DE LA PLANIFICACION 48

Apndice B: Calibracin del Modelo Post-Arquitectura 49+ RESUMEN DEL MODELO POST-ARQUITECTURA 49+ CALIBRACIN DEL MODELO 51

- Resultados de la Calibracin del Esfuerzo 52- Resultados de la Calibracin de Planificacin 54

ESTADO ACTUAL 55

BIBLIOGRAFIA 56


5/54

1

ANOTACIONES

1. Se pretende dar una introduccin suficiente, pero no abusiva (aunque estaconsideracin siempre resulte subjetiva), para situar a quien lea este trabajo dentro

del significado y del mundo donde se utiliza el modelo COCOMO, recordndolealgunos conceptos y dejndolo al final de la introduccin en condiciones suficientespara comprender lo que significa y la utilidad de COCOMO.

2. Se ha perseguido que despus de leer este documento, se comprenda el modeloCOCOMO 2.0, y se tenga la suficiente informacin para poder utilizar el softwareque acompaa a este documento, y que no es sino una herramienta desarrolladapor la Universidad del Sur de California, para aplicar este modelo.

3. Ms documentacin, sobre manuales, mtodos especficos de calibracin delmodelo, etc podr encontrarse en las referencias bibliogrficas, al final de estedocumento.


6/54

2

SITUACINSITUACINSITUACINSITUACIN

COCOMO (COnstructive COnst MOdel) es una herramienta utilizada para la

estimacin de algunos parmetros (costes en personas, tiempo, ...) en el diseo yconstruccin de programas y de la documentacin asociada requerida paradesarrollarlos, operarlos y mantenerlos (Boehm), es decir, en la aplicacin prctica dela Ingeniera del Software.

Este desarrollo de software, y ante los problemas que se encuentran en l, hizo quedesde la dcada de los 70 creciera un inters en el estudio de los problemas que llevaconsigo el software, surgiendo conceptos como control de calidad (SQA),metodologas de anlisis y diseo, ingeniera del software, etc...

Cules son algunos de estos problemas que se encuentran en el desarrollo deaplicaciones?:

- Incremento de la complejidad de los sistemas (mecanizar reas msamplias y complejas)

- Los proyectos nunca terminan en el plazo previsto. Las estimaciones serealizan en un momento en el que no se tiene suficiente informacin o stano se usa correctamente para poder determinar plazos.

- Los problemas ms costosos se producen en las fases ms tempranas deldesarrollo del software.

- Los costes de mantenimiento actualmente son muy elevados debido a lacontinua evolucin de los sistemas y a los errores en su concepcin.

- Distinto vocabulario incluso dentro de los integrantes del propio equipo dedesarrollo informtico.

- Cada diseador utiliza una "forma de hacer" diferente para definir unsistema de informacin.

- Riesgo inherente a que la definicin de los sistemas la realicen tcnicosprovisionales.

- Escasa implicacin del usuario en las tareas de desarrollo de los nuevossistemas.


7/54

3

INTRODUCCIN A LAS TCNICINTRODUCCIN A LAS TCNICINTRODUCCIN A LAS TCNICINTRODUCCIN A LAS TCNICAS DE ESTIMACIN DEAS DE ESTIMACIN DEAS DE ESTIMACIN DEAS DE ESTIMACIN DE

COSTESCOSTESCOSTESCOSTES

Debido a lo que se conoce como "crisis del software", con problemas como losanteriormente descritos, comienza una preocupacin por controlar los costes dedesarrollo, as como la distorsin de este desarrollo respecto a la planificacinestablecida.

"Para llevar a cabo un buen proyecto de desarrollo de software, debemoscomprender el mbito del trabajo a realizar, los recursos requeridos, las tareas aejecutar, las referencias a tener en cuenta, el esfuerzo (COSTE) a emplear y laagenda a seguir." (R. Pressman)

Para intentar dar solucin a estos problemas se han introducido en la Ingeniera delSoftware una serie de tcnicas, utilizadas dentro de las tareas de planificacin, que

ayudan a planificar y controlar el esfuerzo y el tiempo necesario de desarrollo:

- Tcnicas de estimacin del esfuerzo (coste) de desarrollo. Dentro de lascuales se sita COCOMO.

- Tcnicas de planificacin y seguimiento de proyectos.

El problema de realizar estimaciones es que en el instante en que se requiere dichaestimacin no se tiene suficiente informacin para que sta tenga la exactitudrequerida.

No obstante, el desarrollo de software presenta un comportamiento caractersticoque puede ser analizado y empleado para planificar adecuadamente su desarrollodentro de unos lmites de tiempo y coste razonables. Se necesita por tanto conocer:

- cmo se comportan los trabajos de desarrollo.

- qu factores pueden ser controlados.

- cules de stos son determinantes para el proceso de desarrollo de unproyecto.

Existen algunos trabajos que intentan desde un estudio estadstico de una muestra,elegida de manera representativa, de un conjunto de casos reales, establecer modelosbsicamente empricos, que ayuden a realizar dichas estimaciones con un mayorgrado de fiabilidad.

Tradicionalmente existan dos premisas bsicas:

los recursos humanos y el tiempo son variables intercambiables.

el nivel de productividad, dentro de una organizacin, es relativamenteconstante para todos los proyectos.


8/54

4

Hoy en da ambas afirmaciones pueden considerarse errneas o al menosinexactas, ya que:

- el incremento del nmero de personas si aumenta su productividad, perotambin aade otras tareas como la integracin de esas personas dentrodel grupo de trabajo que aumentan el global necesario.

- a su vez si el aumento de personas se realiza no al principio del proyecto,sino durante la realizacin del mismo, hay que aadir el tiempo necesariopara poner al da a los nuevos integrantes del equipo.

- por ltimo se ha demostrado que la productividad es, entre otros factores,una funcin compleja del nivel de dificultad intrnseca de cada proyecto.

Por tanto la relacin siguiente solamente es aplicable a proyectos de muy pequeotamao.

Esfuerzo =Nmero de lneas de cdigo ////Productividad

Existen dos grandes orientaciones de medida del software:

- Funcin: Tipo de problema que resuelve.- Tamao: Volumen del software.

Dentro de la primera se sita la tcnica de los Puntos de Funcin, de A. Albrecht(1979) y de la segunda el modelo COCOMO (Constructive Const Model) de BarryBoehm (1981).

La utilizacin de LDC (lneas de cdigo) o DSI (delivered source instructions) esdiscutida por algunos autores pues la consideran una medida poco consistente, la cualpresenta variaciones difcilmente ponderables:

- longitud- dificultad- cantidad de informacin y- funcionalidad- etc.

ms an si se trata de lneas escritas en distintos lenguajes.

As, algunos investigadores de estos temas han llegado a decir, por ejemplo, que lafuncionalidad de una LDC PL1 es casi el doble que la de una COBOL, y que una de un4GL proporciona entre dos y cuatro veces ms funcionalidad que la de un lenguaje deprogramacin convencional.

El modelo COCOMO, an basndose en una estimacin de LDC, ha sidoampliamente aceptado por:

ser un modelo pblico bien documentado.

debido a que los datos de entrada que solicita el modelo y sus resultadosson mucho ms claros y precisos que en otros modelos.

admite la posibilidad de calibrarse para entornos especficos.


9/54

5

PUNTOS FUNCIN.

Realizada por Allan Albercht en 1979 y revisada a continuacin en 1983, estatcnica est basada (orientada) en la teora de la "ciencia del software" desarrolladapor Halstead, la cual est orientada al anlisis del proceso de construccin de

programas y se basa en la medida del nmero de "unidades sintcticas bsicas"(operadores y operandos).

No se fija en el nmero de LDC sino en su funcionalidad.

La finalidad de la tcnica de los puntos funcin es estimar el tamao de un productosoftware y el esfuerzo asociado a su desarrollo, expresado ste en horas trabajadaspor punto funcin, en las etapas previas a su desarrollo.

Los estudios realizados sobre la utilizacin de este mtodo reflejan la bondad delmismo y la existencia de un elevado grado de correlacin entre el nmero de lneas decdigo (LDC) y la estimacin total de los puntos funcin.

Etapas del mtodo:

1. Contar las funciones de usuario.2. Ajustar el modelo en funcin de la complejidad del proceso.

1. Contar las funciones de usuario. En la etapa primera, se definen cinco tipos defunciones de usuario:

Entradas (al slstema): entradas de usuario que proporcionan al sistemadiferentes datos orientados a la aplicacin.

Salidas: salidas de usuario que le proporcionan a ste informacin sobre laaplicacin.

Consultas: peticiones de usuario que como resultado obtienen algn tipo derespuesta en forma de salida.

Ficheros lgicos internos o archivos maestros: nmero de archivos lgicosmaestros (agrupacin lgica de datos).

Ficheros o interfaces externos: interfaces legibles (archivos de datos encinta o disco) utilizados para transmitir informacin a otros sistemas .

2. Ajustar el modelo en funcin de la complejidad del proceso. El recuento de lasfunciones de usuario se realiza tras una clasificacin previa de stas en tresniveles de complejidad:

Simple Medio Complejo

Tras esta divisin de las funciones de usuario segn su tipo y complejidad se les

aplica un peso, como aparece reflejado en la tabla adjunta, obteniendo el total de lospuntos funcin sin ajustar:


10/54

6

Nivel de complejidad

Tipo de funcin Simple Medio Complejo Total

Entradas

SalidasFicheros lgicos internos

Ficheros externos

Consultas

___ x3= ___

___ x4= ______ x7= ___

___ x5= ___

___ x3= ___

___ x4= ___

___ x5= ______ x10= ___

___ x7= ___

___ x4= ___

___ x6= ___

___ x7= ______ x15= ___

___ x10= ___

___ x6= ___

_____

__________

_____

_____

Total Puntos funcin sin ajustar CF=________

Valoraciones segn el nivel de complejidad

La estimacin del contador de puntos de funcin (CF) debe ajustarse valorando la"complejidad del proceso", la cual puede variar dependiendo del entorno de desarrolloy de las caractersticas propias de la aplicacin.

Esta complejidad puede verse afectada segn este mtodo por catorcecaractersticas, las cuales se evalan de conformidad a una escala de "grados deinfluencia" que toma valores enteros comprendidos entre 0 (sin influencia alguna) y 5(grado de influencia ms elevado). Es decir:

Caractersticas GI

C1

C2

C3

C4

C5

C6

C7

C8

C9

C10C11

C12

C13

C14

Transmisin de datos

Proceso distribuido

Rendimiento, respuesta

Configuracin

Indice de transacciones

Entrada de datos on-line

Eficiencia de usuario

Actualizacin on-line

Complejidad del proceso

ReusabilidadFacilidad de instalacin

Sencillez en operacin

Adaptabilidad

Flexibilidad

____

____

____

____

____

____

____

____

____

________

____

____

Total Grados de Influencia GI = ____

Caractersticas de la aplicacin

Como resultado obtenemos los puntos de funcin ajustados.

PF = CF x (0,65 + (0,01 x GI)) PF: Puntos funcin ajustadosCF: Puntos funcin sin ajustar GI: Grados de influencia.


11/54

7

Ejemplo:

APLICACIN: ____________________________________ APL ID: _______________

PREPARADO POR: ___________ __/__/__ REVISADO POR: ___________ __/__/__NOTAS:

RECUENTO DE FUNCIONES

Nivel de complejidad

Tipo de funcin Simple Medio Complejo Total

Entradas

SalidasFicheros lgicos internos

Ficheros externos

Consultas

. x3= .

. x4= .

. x7= .

. x5= .

. x3= .

. x4= .

. 4 x5= 20 .

. x10= .

. x7= .

. 5 x4= 20 .

. 4 x6= 24.

. x7= .. 6 x15= 70.

. x10= .

. x6= .

. 24 .

. 20 .

. 90 .

. .

. 20 .

Total Puntos funcin sin ajustar CF = 154

COMPLEJIDAD DEL PROCESO

Caractersticas GI Caractersticas GI

C1 Transmisin de datos

C2 Proceso distribuido

C3 Rendimiento, respuesta

C4 Configuracin

C5 Indice de transacciones

C6 Entrada de datos on-line

C7 Eficiencia de usuario

. .

. .

. 4 .

. .

. 4 .

. .

. .

C8 Actualizacin on-line

C9 Complejidad del proceso

C10 Reusabilidad

C11 Facilidad de instalacin

C12 Sencillez de operacin

C13 Adaptabilidad

C14 Flexibilidad

. .

. .

. .

. .

. .

. .

. 5 .

Total Grados de Influencia GI 13 .

ESCALA DE GRADOS DE INFLUENCIA:

No influye = 0 Media = 3Insignificante = 1 Significativa = 4

Moderada = 2 Fuerte = 5

FACTOR DE AJUSTE CP = 0,65 + (0,01) x GI = 0,78TOTAL PUNTOS FUNCIN PF = CF x CP = 120N LINEAS CODIGO I = 66 x PF = 7.920=8k

esto ser para un lenguaje concreto


12/54

8

MODELO COCOMO'81 (Constructive Cost Model, versin de 1981)

Este fue presentado por Barry Boehm en 1981 y se convirti en el ms conocido yreferenciado, adems del ms documentado de todos los modelos de estimacin de

esfuerzo de las actividades de diseo, codificacin, pruebas y mantenimiento.La versin inicial de COCOMO se obtuvo a partir de la revisin de los modelos de

costes existentes, en la cual participaron varios expertos en direccin de proyectos, loscuales posean adems cierta experiencia en la utilizacin de diferentes modelos deestimacin.

Inicialmente se cre un modelo con un nico modo de desarrollo, peroposteriormente se vio que la aplicacin del modelo a una amplia variedad de entornosimplicaba la creacin de los tres modos de desarrollo:

Orgnico. Proyectos de no ms de 50 KLDC (50.000 LDC), sobre reas

muy especficas y bien conocidas por el equipo participante. Semiempotrado (semilibre). El nivel de experiencia del equipo de

desarrollo se sita en niveles intermedios y suelen ser sistemas coninterfaces con otros sistemas, siendo su tamao menor a 300 KLDC.

Empotrado (restringido). Proyectos de gran envergadura, con unaexigencia de altos niveles de fiabilidad y en los que participan muchaspersonas.

Por otra parte Boehm presenta una jerarqua de modelos de estimacin segn elnivel de detalle empleado en su utilizacin:

Bsico. Modelo que calcula el esfuerzo de desarrollo como funcin deltamao estimado del software en LDC. Adecuado para realizarestimaciones de forma rpida, aunque sin gran precisin.

Intermedio. En ste el esfuerzo se calcula como funcin del tamao delproducto, modificado por la valoracin de los atributos directores del coste,los cuales incluyen una valoracin subjetiva del producto, del hardware, delpersonal, etc. Los valores de los diferentes atributos se consideran comotrminos de impacto agregado al coste total del proyecto.

Detallado. En l la valoracin de los atributos tiene en cuenta su influenciaen cada una de las fases de desarrollo del proyecto.

Las estimaciones relacionadas con el coste (esfuerzo) se expresan en meses-

hombre (tiempo que requerira una sola persona para desarrollar el sistema),considerando que la dedicacin de una persona es de 152 horas al mes.


13/54

9

1. Modelo Bsico.

Orgnico Semiempotrado Empotrado

Esfuerzo estimado ED=2,4(KLDC)1,05 h-m ED=3,0(KLDC)1,12 h-m ED=3,6(KLDC)1,20 h-m

Tiempo de desarrollo TD=2,5(ED)0,38 m TD=2,5(ED)

0,35 m TD=2,5(ED)0,32 m

Productividad PR = LDC / ED

N medio de personas

FSP (Full-Time equivalent Software Personel)

PE= ED/ TDh

Esfuerzo

De

Mantenimiento

TCA (Trfico de cambio anual): porcin de instrucciones fuente que

sufren algn cambio durante un ao, bien sea por adicin o pormodificacin.

EM= TCA x ED

Y por tanto el valor medio del nmero de personas a tiempo completo,

dedicadas a mantenimiento durante 12 meses sera:

(PE)M= EM/ 12

h=hombre, m=mes, h-m=hombres-mes

Ejemplo.Un estudio inicial determina que el tamao del producto estar alrededor de 32.000LDC, a partir de las anteriores ecuaciones obtendramos que las caractersticas delproyecto seran:

Por el tamao del producto a desarrollar vemos que debemos aplicar las ecuacionesasociadas al modo orgnico, obteniendo lo siguiente:

ED = 2,4 (32)1,05 = 91 hombre-mes

TD = 2,5 (91)0,38 = 14 meses

PR = 32.000 / 91 = 352 lneas/hombre-mes

PE = 91 / 14 = 6,5 hombres

Tamao(lneas)

Esfuerzo(hombre-mes)

Productividad(lneas/hombre-mes)

Tiempo(meses)

PE(hombres)

Pequeo 2KSIntermedio 8KSMedio 32KSGrande 128KS

5,021,391,0392,0

400376352327

4,68,014,024,0

1,12,76,516,0

Perfiles de proyectos estndares: Modo orgnico.


14/54

10

2. Modelo Intermedio.

Este modelo es una versin ampliada del modelo Bsico, en la que se presentauna mayor precisin en las estimaciones, manteniendo prcticamente la misma

sencillez del anterior modelo. Esta mayor precisin viene dada por la incorporacin de15 factores que reflejan la influencia de ciertos elementos sobre el coste del software.

El criterio para la eleccin de estos factores es generalidad e independencia. Esdecir, se eliminaron aquellos factores que solamente eran significativos de un pequeonmero de situaciones, as como aquellos otros que mostraban una fuerte correlacincon aspectos puntuales del desarrollo del software.

Finalmente estos 15 factores se agruparon en cuatro grandes grupos: Atributos delProducto, del Computador, del Personal y del Proyecto.

Cada uno de estos 15 atributos tiene asociado un factor multiplicador para estimar

el efecto de ste sobre el esfuerzo nominal.


Ecuaciones del

esfuerzo nominal

EN=3,2(KLDC)1,05 EN=3,0(KLDC)

1,12 EN=2,8(KLDC)1,20

ValorAtributos Muy

bajo

Bajo Nominal Alto Muy

alto

Extra

altoAtributos del productoFiabilidadTamao base de datosComplejidad

,75

,70

,88,94,85

1,001,001,00

1,151,081,15

1,401,161,30 1,65

Atributos del computadorRestricciones de tiempo de ejecucinRestricciones de memoria virtualVolatilidad de la mquina virtualTiempo de respuesta

,87,87

1,001,001,001,00

1,111,061,151,07

1,301,211,301,15

1,661,56

Atributos del personalCapacidad de anlisisExperiencia en la aplicacinCalidad de los programadores

Experiencia en la mquina virtualExperiencia en el lenguaje

1,461,291,42

1,211,14

1,191,131,17

1,101,07

1,001,001,00

1,001,00

,86,91,86

,90,95

,71,82,70

Atributos del proyectoTcnicas actualizadas de programacinUtilizacin de herramientas softwareRestricciones de tiempo de desarrollo

1,241,241,23

1,101,101,08

1,001,001,00

,91,91

1,04

,82,83

1,10Factores multiplicadores del esfuerzo de desarrollo de software

Esfuerzo total: ED = EN * fidonde fi se corresponde con los quince factores descritosanteriormente.


15/54

11

Si se observan los valores para el modelo Intermedio, se puede ver que loscoeficientes escalares (3'2, 3'0, 2'8) decrecen a medida que se incrementa lacomplejidad del modo de desarrollo, al contrario que en el modelo Bsico.

Esta diferencia indujo a Conte y otros a presentar un conjunto de ecuacionesalternativas, cuyo comportamiento, segn sus autores, mejora el de las ecuacionesoriginales del modelo Intermedio:


Ecuaciones del

esfuerzo nominal

EN=2,6(KLDC)1,08 EN=2,9(KLDC)

1,12 EN=2,9(KLDC)1,20

3. Modelo Detallado.Este modelo presenta principalmente dos mejoras respecto al anterior modelo:

+ Los factores correspondientes a los atributos son sensibles a la fase sobre laque se realizan las estimaciones, puesto que aspectos tales como experienciaen la aplicacin, utilizacin de herramientas software, etc, tienen mayorinfluencia en unas fases que en otras.

+ Establece una jerarqua de tres niveles de productos, de forma que:- los aspectos que presentan gran variacin a bajo nivel, se

consideran a nivel mdulo.

- los que presentan pocas variaciones a nivel de subsistema- los restantes se consideran a nivel sistema.

Calibracin del modelo.

El modelo puede ajustarse para mejorar la precisin de sus estimaciones, por lascaractersticas propias de una instalacin particular.

Este proceso puede realizarse por diversos procedimientos, no excluyentes:

- calibrar las ecuaciones del esfuerzo nominal de acuerdo al comportamientodel proyectos finalizados.

- consolidar o eliminar algunos de los atributos directores del coste.

- aadir otros atributos que pueden ser ms significativos en la instalacin enparticular.

Veamos cmo podra ser una posible calibracin de las ecuaciones propuestas porel modelo Intermedio para su modo orgnico:


16/54

12

1. Calibracin de una constante:

ED = c(KLDC)1,05*

Supongamos que en una instalacin se han finalizado n proyectos cuyos tamaos

finales fueron KLDC1, ... KLDCn, los factores de ajustes empleados 1, ... n, y elesfuerzo dedicado a cada uno de ellos E1, ... En. En este caso calcular la constante cconsiste en resolver el sistema de ecuaciones tal que la suma de cuadrados de esasdiferencias sea lo ms pequea posible.

E1 = c (KLDC1)1,05 1

E2 = c (KLDC2)1,05 2

. . . . . . . . . . . .En = c (KLDCn)

1,05 n

As pues, planteamos la suma de cuadrados de las diferencias como:

15E = 3(c(KLDCi)

1,05i - Ei)2

i=1

Haciendo

Qi = (KLDCi)1,05i

y sustituyendo15

E = 3(cQi- Ei)2

i=1

para minimizar E calculamos su derivada e igualamos a cero:

0 = dE/dc = 2 3(cQi- Ei) Qi

de ah puede despejarse la constante ccomo:

c = 3EiQi / 3Qi2

2. Calibracin de dos constantes:

Para realizar esta calibracin puede aplicarse la misma tcnica de aproximacinpor mnimos cuadrados, teniendo en cuenta que ahora se desea determinar el trminomultiplicador cy el factor de escala bde la ecuacin de esfuerzo:

ED = c(KLDC)b*

Comencemos reescribiendo la ecuacin tomando logaritmos:

ln(c) + b ln(KLDC) = ln(ED/)


17/54

13

En este caso nos interesa minimizar

E = 3( ln(c)+ bln(KLDCi) - ln(Ei/i) )2

Los valores ptimos de ln(c) y b pueden determinarse resolviendo el siguientesistema:

a0ln(c) + a1b = d0a1ln(c) + a2b = d1

donde

a0 = n (nmero de proyectos)a1 = 3 ln(KLDCi)

a2 = 3( ln(KLDCi) )2

d0 = 3ln(Ei/i)d1 = 3ln(Ei/i) ln(KLDCi)

resolviendo obtenemos:

ln(c) = a2d0- a1d0 / a0a2 - a12

b = a0d1- a1d0 / a0a2 - a12

Situacin a principios de los 90

Al inicial modelo de estimacin de costes COCOMO 81, le sigui una actualizacinpara el lenguaje Ada en 1987, que recibi el nombre de Ada COCOMO. Desdeentonces el desarrollo de nuevos ciclos de vida, ocasionados por la evolucin deldesarrollo del software, ha incrementado la dificultad de estas estimaciones. Yestamos hablando de trminos como desarrollo rpido de aplicaciones, aplicacionesno secuenciales, reusabilidad del software, reingeniera, programacin orientada aobjetos, etc.


18/54

14

COCOMO 2.0

INTRODUCCIN .

Actualmente una nueva generacin de procesos y productos software estcambiando la forma en que las organizaciones desarrollan software, intentando serms competitivas. Estas nuevas aproximaciones -procesos software colaborativos,evolucionarios, y centrados en los riesgos; generadores de aplicaciones y lenguajes decuarta generacin; "comercial off-the-shelf" (COTS) y dependientes de la reutilizacinque se deba hacer del software- llevan a significativos beneficios en trminos decalidad software y reduccin de coste que supone su desarrollo, reduccin de riesgosy del tiempo de ciclo.

De cualquier forma, si bien alguno de los modelos de estimacin de coste softwareexistentes poseen iniciativas que tienen en cuenta algunos de estos aspectos, estasnuevas aproximaciones no han sido tenidas en cuenta suficientemente hasta hacepocos aos por los nuevos modelos de estimacin de costes y planificacin. Esto haceque sea difcil a las organizaciones realizar una planificacin, anlisis y control deproyectos de manera efectiva y utilizando las nuevas aproximaciones.

Estos argumentos han llevado a realizar una nueva formulacin del modeloCOCOMO, sucesor de los anteriores COCOMO 81 de Boehm (1981) y el COCOMOAda de Royce (1989).

OBJETIVOS:

Los principales objetivos de COCOMO 2.0 son:

1. El desarrollo de un modelo de estimacin de costes y planificacin que pudiera serutilizado en el ciclo de vida de la dcada de los 90 y posterior al 2000.

2. Desarrollar una base de datos indicativa del coste del software y un soporte deherramientas con la capacidad suficiente para el continuo progreso yperfeccionamiento del modelo.

3. Proporcionar un cuantioso y analtico marco de trabajo, y un conjunto deherramientas y tcnicas para la evaluacin de los efectos que la tecnologasoftware tiene sobre el coste de los ciclos de vida software y de planificacin.

Las principales capacidades de COCOMO 2.0 son los ajustes a medidadependiendo del software a desarrollar, involucrando en la estimacin del coste a lospuntos objeto (object points), puntos funcin (function points) y lneas de cdigofuente; utilizando modelizaciones no lineales para atender a la reingeniera yreusabilidad del software, ... y todo esto sobre la base del anterior COCOMO.


19/54

15

CCOOCCOOMMOO22..00:: FFUUNNDDAAMMEENNTTOOSSYYEESSTTRRAATTEEGGIIAA ..

Los cuatro elementos principales de la estrategia de COCOMO 2.0 son:

1. Preservar las habilidades y apertura del modelo original, para que contine siendoun modelo abierto y pblico (algoritmos, parametrizaciones, etc...)

2. Adaptar la estructura de COCOMO 2.0 a los futuros sectores del mercado softwaredescritos antes.

3. Adaptar las entradas y salidas de los submodelos de COCOMO 2.0 al nivel deinformacin disponible en cada etapa.

4. Permitir a los submodelos de COCOMO 2.0 ajustarse a la medida dependiendo dela estrategia utilizada en cada proyecto particular (atender a las distintascalibraciones de los submodelos que se utilicen para obtener mayor fiabilidad en la

estimacin global).

Un fundamento importante es el considerar la granularidad del modelo deestimacin de coste, teniendo en cuenta la informacin disponible que sirve de soporteal modelo, entendiendo que en las primeras etapas del proyecto software se conocenmuy pocas cosas sobre el tamao del producto a ser desarrollado, la naturaleza de laplataforma objetivo, la naturaleza del personal involucrado en el proyecto, o losdetalles especficos del proceso que se utilizar.

La siguiente figura indica el efecto de las incertidumbres del proyecto tienen sobrela precisin del tamao del software y la estimacin del coste. En los primerosestados, al comienzo, no puede conocerse la naturaleza especfica del producto a

desarrollar con una aproximacin mayor de un factor 4. Segn el ciclo de vida avanza,y se realizan decisiones sobre el producto, la naturaleza del producto y suconsecuente tamao son mejor conocidos, y la naturaleza del proceso y susconsecuentes parmetros de coste son mejor conocidos:

Figura 2. Precisin de tamao y coste software dependiendo de la fase en que se encuentre el proceso.


20/54

16

COCOMO 2.0 permite a los proyectos suministrar a los parmetros de coste unainformacin rudamente granulada en los primeros estados del proyecto, para irincrementandola ms detalladamente granulada segn se avanza en los estados.

Resumiendo, el modelo COCOMO 2.0 proporciona los siguientes 3 estados (seriesde modelos) para la estimacin de Generadores de Aplicaciones, Integracin deSistemas, e infraestructura de proyectos software:

1. En las primeras fases o ciclos espirales que generalmente incluirn prototipado, sehacen uso de las capacidades del Modelo de Composicin de Aplicaciones.Este modelo soporta estas fases, y cualquiera otras actividades de prototipado quesuceden con posterioridad en el ciclo de vida.

Incluye pues tareas de prototipado para resolver cuestiones como el diseo delos inferfaces de usuario, la interaccin del software con el sistema, el rendimientoo la madured de la tecnologa empleada. Asi, los costes de este tipo de esfuerzoson mejor estimados por un modelo de composicin de aplicaciones..

Nos encontramos pues en una situacin donde existen aplicaciones muydiversas, tanto que no se manejan como paquetes integrados de soluciones, peroque son lo suficientemente simples para ser rpidamente acopladas y deinteroperar sus componentes.

Como veremos posteriormente, el modelo COCOMO se basa en Puntos Objetopara modelizar la Composicin de Aplicaciones, y es una cuenta de las pantallas,informes y mdulos desarrollados con lenguajes de tercera generacin, cada unocon un peso segn la complejidad del parmetro (mnimo, medio, alto). Estomantiene una equivalencia con el nivel de informacin de la que generalmente sedispone, sobre esta composicin de aplicaciones, durante sus estados de

planificacin temporal, y el correspondiente nivel de precisin necesaria paraestimar el coste software.

2. Las siguientes fases o ciclos espirales que generalmente incluyen la exploracinde arquitecturas alternativas o estrategias de desarrollo incrementales. Parasoportar estas actividades, COCOMO 2.0 proporciona un temprano modelollamado Modelo de Diseo Inicial. Este nivel de detalle en este modelo esconsistente con el nivel general de informacin disponible y con el nivel general deestimacin detallada que es necesaria en esta etapa.

Se utilizan, como veremos, puntos funcin y/o instrucciones fuente, y un

pequeo nmero de parmetros de coste (cost drivers).

3. Una vez que el proyecto esta listo para ser desarrollado se debera tener unaarquitectura de ciclo de vida, la cual proporcionase ms informacin detalladasobre las entradas de los parmetros de coste, y permitieses mayor precisin en laestimacin del coste. Para soportar esta etapa, COCOMO 2.0 proporciona elModelo Post-Arquitectura.

Incluye este modelo el desarrollo y mantenimiento ltimo del producto software.Se utilizan, como veremos, instrucciones fuente y/o puntos funcin para laestimacin, existiendo modificadores que los operan; un conjunto de 17 factoresmultiplicativos de evaluacin de coste, y un total de 5 modos para dimensionar elproyecto, que sustituyen a los anteriores modos Orgnico, Semiempotrado yEmpotrado del COCOMO original.


21/54

17

Un anlisis de los datos debera permitir tambin la calibracin de las relaciones

entre puntos objeto, puntos funcin, y lneas de cdigo fuente para varios lenguajes ycomposicin de sistemas, permitiendo mayor flexibilidad al elegir los parmetros queinfluyen en la clasificacin del tamao.

ESTIMACIN DEL ESFUERZO DE DESARROLLO.

COCOMO 2.0 expresa el esfuerzo en terminos de Personas Mes (PM). Todas lasecuaciones del esfuerzo estn representadas en el apndice A. Una persona mes esla cantidad de tiempo que una persona dedica a trabajar sobre el proyecto dedesarrollo software durante un mes. El nmero de personas mes es diferente deltiempo que tomar el proyecto para ser completado; a esto se le llama planificacin dedesarrollo. Por ejemplo, un proyecto puede estimarse en requerir 50 PM de esfuerzo,

pero tener una planificacin temporal de 11 meses.

Nmero nominal de Personas Mes.

La siguiente ecuacin es la base de los modelos de Diseo Inicial y Post-Arquitectura. Las entradas son el tamao del desarrollo software, una constante A, yun factor de escala B. El tamao se dan en miles de lneas de cdigo fuente (KSLOC).Pudindose estimar tambin utilizando Puntos Funcin Desajustados (UFP), yconvertirlos a SLOC dividiendo por mil.

El factor de escala (o exponencial) B, cuenta la relativa economa, positiva o

negativa, de la escala encontrada en proyectos software segn cambie el tamao deste.

La constante A es usada para capturar los efectos multiplicativos sobre el esfuerzocon proyectos que incrementan su tamao.

PMnominal = A x(Size)B Ecuacin 1

Breakage.

El Modelo COCOMO 2.0 utiliza un porcentaje del cdigo "breakage" (BRAK) paraajustar el tamao efectivo del producto. El trmino Breakage hace referencia a lavolatilidad de los requerimientos de un proyecto. Esto es, el porcentaje de cdigo quese desecha. Por ejemplo, un proyecto formado finalmente por 100.000 instruccionesde las que se han descartado otras 20.000 instrucciones adicionales, entonces BRAKtendr un valor de 20. Esto debera usarse para ajustar el tamao efectivo del proyectoa 120.000 instrucciones. Ese factor BRAK no se utiliza en el modelo de Composicinde Aplicaciones, donde se espera un cierto grado de interaccin del producto, incluidauna calibracin de los datos.

Ajustando la reusabilidad.

Efectos no lineales: Selby realiza un anlisis sobre cerca de 3000 mdulosreutilizables, en el Laboratorio de Ingeniera Sofware de la NASA, de cmo influye la


22/54

18

reutilizacin del cdigo, y como resultado indica que este coste queda expresado poruna funcin no lineal, debido a dos razones principales:

No se comienza desde el principio. Existe un coste alrededor del 5% debidoa la valoracin, seleccin y asimilacin que debe hacerse del componentereutilizable.

Pequeas modificaciones producen desproporcionadas reacciones en elcoste. Esto es debido principalmente a dos factores: el coste decomprender el software que va a ser modificado, y el relativo costeasociado a testear el interface.

Estudios realizados determinan que el 47% del esfuerzo de mantenimiento delsoftware est directamente relacionado con la comprensin del software que semodifica. Tambin se demuestra que si se modifican k de m mdulos, el nmero N queindica los interfaces de mdulos que son chequeadas es N = k * (m-k) + k *x (k-1) / 2.Relacin que se muestra la Figura 4, donde la curva demuestra la mencionadarelacin no lineal.

Siempre teniendo en cuenta que el tamao que supone este tiempo de comprensin

del software y de chequeo del interface puede ser reducido mediante una buenaestructura sofware.


23/54

19

Un modelo para tener en cuenta la reusabilidad:el modelo COCOMO 2.0 trata estareutilizacin del software usando un modelo de estimacin no lineal. Esto incluye unaestimacin de la cantidad de software a ser adaptado, ASLOC, y tres parmetrossegn el grado de modificacin: porcentaje de diseo modificado (DM), porcentaje decdigo modificado (CM), y porcentaje del esfuerzo original que supone integrar elsoftware reutilizable (IM).

El incremento que supone la comprensin del software (SU) se obtiene de lasiquiente tabla; y expresado cuantitativamente como un porcentaje.

Muy Bajo Bajo Nominal Alto Muy AltoEstructura Muy baja

cohesin, altoacoplamiento,definicin pococlara delcdigo.

Moderada bajacohesin, altoacoplamiento.

Razonablemente bienestructurado;algunas reasresultandbiles.

Alta cohesin,bajoacoplamiento.

Enormementemodular,Informacinocultadamedianteestrucuras dedatos y control.

Claridad de laAplicacin

No existe unaclara identidadentre lasvisiones delprograma y dela aplicacin.

Existe algunacorrelacinentre elprograma y laaplicacin.

Moderadacorrelacinentre elprograma y laaplicacin.

Buenacorrelacinentre ambos.

Existe una clararelacin entrelas visionesglobales deambos(programa yaplicacin).

Descripcinimplcita

Cdigo obtuso;ladocumentacino no existe oresulta oscura uobsoleta.

Existen algunoscomentarios enel cdigo yalgunadocumentacintil.

Un moderadonivel decomentarios enel cdigo, ydocumentacin.

Biencomentado elcdigo,documentacintil, aunquedbilmente enalgunas reas.

Cdigoautodescriptivo,documentacinactualizada,bien organizaday con un diseoracional.

Incremento deSU en ESLOC

50 40 30 20 10

Tabla 1: Escala segn se Incrementa la Compresin del Software (SU).

El otro incremento no lineal sobre la reusabilidad tiene que ver con el grado deValoracin y Asimilacin (AA) necesarias para determinar si un cierto mdulo softwarecompletamente reutilizable es apropiado para la aplicacin, e integrar su descripcindentro de la descripcin global del producto. La Tabla 2 siguiente proporciona unaescala para este porcentaje:

Incremento de AA Nivel de esfuerzo AA0 Ninguno.2 Una bsica bsqueda modular y de documentacin.4 Alguna Evaluacin y Chequeo modular, documentacin.6 Una considerable Evaluacin y Chequeo modular, documentacin.8 Una gran Evaluacin y Chequeo modular, documentacin.

Tabla 2: Escala segn el incremento de Valoracin y Asimilacin (AA).

Finalmente la ecuacin usada para determinar esta reusabilidad es:

Ecuacin 2


24/54

20

Ajustando la Conversin o Reingeniera.

El modelo COCOMO 2.0 necesita de un refinamiento adicional para estimar elcoste de la reingeniera software y conversin. La mayor diferencia viene por laeficiencia de las herramientas automatizadas para la reestructuracin del software,que permiten que a un alto porcentaje de cdigo modificado le corresponda unpequeo esfuerzo.

Para realizar esta estimacin se incluye un parmetro adicional, AT, que indica elporcentaje de cdigo que es tratado en esta reingeniera mediante translacinautomtica:

Ecuacin 3

Ajustando Personas Mes.

Los parmetros de coste (cost drivers) son utilizados para capturar caractersticasdel desarrollo del software que afectan al esfuerzo para completar el proyecto. Estosparmetros de coeste expresan el impacto del parmetro sobre el esfuerzo dedesarrollo, en Personas Mes (PM). Este rango va de Muy Bajo a Extra Alto, y tiene unpeso asociado segn el rango al que pertenezca cada parmetro. Este peso esllamado multiplicador de esfuerzo (EM), siendo la media asignada a cada uno de 1'0(rango medio o nominal). Este valor ser mayor que 1'0 si influye incrementando elesfuerzo, y menor que 1'0 si lo disminuye.

Existen 7 de estos multiplicadores de esfuerzo en el modelo de Diseo Inicial, y 17en el modelo Post-Arquitectura.

Ecuacin 4

ESTIMACIN DE LA PLANIFICACIN TEMPORAL DE DESARROLLO.

La ecuacin base inicial para mostrar la planificacin para los tres estados deCOCOMO 2.0 es:

Ecuacin 5


25/54

21

donde TDEV es un calendario temporal expresado en meses, utilizado para determinarque los requerimientos del producto se han completado y que quedan certificados. PM"negado" indica la estimacin Personas-Mes excluyendo el multiplicador de esfuerzoSCED. B es la suma de los factores exponentes de escala.

Rangos de salida.

Los tres estados del modelo COCOMO 2.0 permiten que la estimacin seaexpresada dentro de un rango de valores, que teniendo en cuenta la Figura 2 de"Precisin de tamao y coste de software segn la fase en que se encuentra elproyecto" expresa el resultado E (esfuerzo estimado) como un conjunto deestimaciones pesimitas y optimistas.

Estado Estimacin Optimista Estimacin Pesimista1 050 E 2'00 E2 0'67 E 1'50 E3 0'80 E 1'25 E

Tabla 4.Rangos de salida.


26/54

22

EESSCCAALLAA DDEE PPRROODDUUCCTTIIVVIIDDAADD DDEELL SSOOFFTTWWAARREE..

Los modelos de estimacin de coste software a menudo poseen un factorexponencial que cuenta lo favorable o desfavorable que es econmicamente unproyecto dependiendo de cmo varie su tamao. El exponente B de la Ecuacin 1 seutiliza para capturar estos efectos.

Si B < 1'0 el proyecto muestra una escala positiva, econmicamente favorable, detal forma que si el tamao del producto se duplicase, el esfuerzo resultante seriamenor del doble. Es decir, la productividad del proyecto se incrementa conforme eltamao del producto aumenta.

Si B = 1'0, el proyecto est economicamente equilibrado. Este modelo lineal esusado frecuentemente para realizar estimaciones en pequeos proyectos. Usado en elmodelo de Composicin de Aplicaciones.

Si B > 1'0 el proyecto muestra una escala negativa, economicamente desfavorable,debido generalmente a dos razones principales: crecimiento de las comunicacionesinterpersonales que lo desbordan, y crecimiento de la integracin de sistemasgrandes, que igualmente desborda. En el sentido de que proyectos grandesnecesitarn de ms personal, y a ms personal mayor comunicacin que se requiere,no olvidando que incluso aunque un proyecto grande se organiza en pequeossubproyectos que necesitan un esfuerzo menor, se requiere un esfuerzo adicional paradisear, mantener, integrar y testear todos estos productos por separado y luegoglobalmente.

Ya el anlisis de datos del COCOMO original indicaba que los proyectos mostrabanuna escala desfavorable econmicamente, as existian ya tres clases de modelos de

desarrollo software (Orgnico, Semiempotrado, y Empotrado), cada uno con unexponente distinto (B=1'05, B=1'12, B=1'20 respectivamente).

La distincin entre los factores de estos modelos bsicamente concierne al entorno:proyectos en modo empotrado tuvieron menos precedentes, requiriendo mayorsaturacin de comunicaciones as como una integracin compleja, son menosflexibles, ...

ESCALANDO LOS PARMETROS.

La Ecuacin 6 define el clculo de este exponente B, utilizado ya en la Ecuacin 1.La Tabla 19 proporciona una valoracin por niveles para estos parmetros de escaladel COCOMO 2.0. Cada uno de estos parmetros se divide en un rango segn elnivel, que va desde Muy Bajo a Extra Alto. Cada uno de estos rangos tiene un peso(W). Los factores de escala de un proyecto se suman para determinar el exponente deescala B, mediante la siguiente frmula

B = 1'01 + 0'01 * W i Ecuacin 6

Por ejemplo si a la escala Extra Alta le asignamos el peso cero, entonces unproyecto con 100KSLOC con todos sus factores de escala en el rango "Extra Alto"tendrn W i=0, y B=1'01, y un esfuerzo relativo E=100

1'01=105 PM. Si por el contrario

los factores, todos, estn en el rango "Muy Bajo", asignamos un peso de 5 a cada uno,teniendo Wi=25 y B=1'26, y un esfuerzo relativo E=331 PM. Aunque esto representa


27/54

23

una gran variacin, el incremento provocado por un cambio en un nico parmetrorepresenta tan slo el 4'7%.

Factor de

Escala (Wi)

Muy Bajo

(5)

Bajo

(4)

Nominal

(3)

Alto

(3)

Muy Alto

(1)

Extra Alto

(0)PREC Mnima Poca Algo Medianamente

familiarMuy familiar Altamente

familiarFLEX Poca o

ninguna (muyriguroso)

Ocasional Alguna alta Muy alta Tendiendo aoptima (metasgenerales)

RESLa Reduccin delriesgo entornoal 20%

Idem 40% Idem 60% Idem 75% Idem 90% Idem 100%

TEAM Interaccionesmuy dificiles

Algunasinteraccionesdificiles

Interaccionespara unacooperacinbsica

Muycooperativo

Altamentecooperativo

Cooperacinptima

PMATpeso medio de las respuestas afirmativas en el cuestionario Madured CMM

Tabla 5. Escala de Factores para los modelos de Diseo Inicial y Post-Arquitectura.

Precedentes (PREC) y Flexibilidad de Desarrollo (FLEX).

Estos dos escalas de factores capturan en gran medida las diferencias entre losmodos, del COCOMO original, Orgnico, Semiempotrado y Empotrado. La Tabla 6reorganiza las caractersticas de un proyecto en estos trminos. Esta tabla puede serusada para ms de una profundidad de exploracin para los factores PREC y FLEXdados por la Tabla 19.

Caracterstica Muy Baja Nominal / Alta Extra AltaPrecedencias

Objetivos del producto ycomprensinorganizacional

General Considerable Profundo

Experiencia trabajandocon sistemas softwarerelacionados

Moderada Considerable Extensiva

Desarrollo concurrenteasociado a nuevohardware y nuevosprocedimientosoperacionales

Extensivo Moderado Alguno

Necesidad para lainnovacin enarquitecturas de proceso

de datos , algoritmos

Considerable Alguno Minimo

Flexibilidad de desarrolloNecesidad de que elsofware se ajuste a losrequerimientospreestablecidos

Completo Considerable Bsico

Necesidad de que elsofware se ajuste a lasespecificaciones deinterface externos

Completo Considerable Bsico

Prima para un desarrollocompleto inicial Alto Medio Bajo

Tabla 6: escala de Factores relacionados con los modos de desarrollo de COCOMO


28/54

24

Resolucin de Arquitectura/Riesgos (RESL).

Este factor combina a dos de los factores de escala del modelo Ada COCOMO:"Diseo minucioso mediante examen del Diseo del Producto (PDR)", y "Eliminacin deriesgos mediante PDR". La Tabla 7 consolida estos factores del modelo AdaCOCOMO para formar una definicin ms comprensiva de los niveles de valoresRESL en COCOMO 2.0. Esta valoracin del RESL es una medida de los pesossubjetiva.

Cohesin del Equipo de Trabajo (TEAM).

El factor de escala de Cohesin del Equipo cuenta las fuentes que originanturbulencias y entropia en el proyecto debido a las dificultades de sincronizacin:usuarios, clientes, desarrolladores, personal encargado del mantenimiento, interfaces,otros. Estas diferencias pueden deberse a diferencias culturales, dificultades parareconocer objetivos, hasta familiaridad para trabajar en equipo. La Tabla 8 proporcionauna definicin detallada para el conjunto completo de niveles TEAM. La valoracin

final es la media subjetiva de los pesos.Madured del Proceso (PMAT)

El procedimiento para determinar PMAT se organiza mediante 18 claves e rea deproceso (KPAs) por el Modelo de Capacidad de Madured, del SEI. Este procedimientoque determina PMAT decide el porcentaje de conformidad para cada uno de los KPAs.


29/54

25

Casi siempre: cuando los objetivos son consistentemente alcanzables y bien establecidos en

procedimientos operativos estndar. Frecuentemente: cuando los objetivos son alcanzables con relativa frecuencia, pero en

algunas ocasiones son emitidas bajo circunstancias difciles (entre el 60% y 90% de lasveces).

Sobre la mitad: cuando los objetivos son alcanzables sobre la mitad de las veces (entre el405 y 60% de las veces).

Ocasionalmente: cuando los objetivos son alcanzados algunas veces, pero poco frecuentes(entre el 10% y 40% de las veces).

Raramente (si acaso): cuando los objetivos raramente son alcanzados (menos del 10% delas veces).

No se aplica: cuando se tiene el conocimiento requerido sobre el proyecto u organizacin yel KPA, pero se tiene un sentimiento de que los KPAs circunstancialmente no se puedenaplicar.

Se desconoce: cuando no se tiene certeza de cmo respondern los KPAs.

Despus de que el nivel de KPA es determinado, a cada nivel de conformidad se le

asigna un peso o valor y el factor PMAT queda calculado:

Ecuacin 7


30/54

26

MMOODDEELLOO DDEE CCOOMMPPOOSSIICCIINN DDEE AAPPLLIICCAACCIINN..

Este modelo est dirigido a aplicaciones que estn demasiado diversificadas comopara crear rpidamente una herramienta especfica dentro de un dominio. Ejemplos deestos sistemas basados en componentes son los generadores de interfaces de usuario(GUI), gestores de objetos o bases de datos, procesamiento distribuido o detransacciones, manejadores hipermedia, pequeos buscadores de datos, ycomponentes de un dominio especfico tales como domnios financieros, mdicos, opaquetes de control de procesos industriales.

Objeto de este estudio son estos sistemas que se caracterizan por llevar asociadosesfuerzos de prototipado, uso de ICASE (CASE integrado) para obtener unacomposicin rpida asistida por la computadora, que proporcionan generadores deinterfaces grficos de usuario, herramientas de desarrollo software, y un largo nmerode componentes de aplicaciones e infraestructuras. En estas reas se ha demostradoel buen funcionamiento de los Puntos Funcin para realizar estimaciones sobre un

conjunto no trivial de aplicaciones.

Estudios experimentales realizados demuestran que tanto el uso de PuntosFuncin como de Puntos Objeto dan unas estimaciones muy prximas, si bien elmtodo de los Puntos Objeto resulta ms fcil de utilizar.

PROCEDIMIENTO PARA CONTAR PUNTOS OBJETO

Definicin de trminos:

NOP: Nuevos Puntos Objeto (cuenta de los Puntos Objeto ajustados para

su reutilizacin). srvr: nmero de servidores de datos (mainframes o equivalentes). clnt: nmero de clientes de datos (estaciones de trabajo personales). %reutilizacin: porcentaje de pantallas, informes y mdulos 3GL

reutilizados por aplicaciones previas, segn su grado de reutilizacin.

Pasos:

1. Estimar el nmero de pantallas, informes, y componentes 3GL que comprendernla aplicacin. Asumiendo las definiciones estandar de estos objetos en el entorno

ICASE utilizado.2. Clasificar cada instancia de cada objeto en niveles de complejidad simple, media o

alta, dependiendo de los valores segn la dimensin. Utilizar el siguiente esquema:

Pantallas InformesNmero

devistasque

contiene

Total < 4

( 5 clnt )

Nmerode

secciones que

contiene

Total < 4

( 5 clnt )

8 Medio Alto Alto 4+ Medio Alto Alto


31/54

27

3. Valorar con un peso (nmero) como los mostrados en la siguiente tabla, uereflejan el esfuerzo relativo requerido para implementar una instancia deese objeto dependiendo del nivel de complejidad:

ComplejidadTipo de Objeto Simple Media AltaPantalla 1 2 3Informe 2 5 8

Componente 3GL 10

4. Sumar todos los pesos de los objetos instanciados para obtener un niconmero, que ser la cuenta de Puntos Objeto.

5. Estimar el porcentaje de reutilizacin esperado para realizar el proyecto.Calcular los nuevos Puntos Objeto a ser desarrollados.

Ecuacin 8

6. Determinar un ratio de productividad PROD=NOP/Personas-mes utilizandoel siguiente esquema:

Capacidad y experienciade los desarrolladores Muy Baja Baja Nominal Alta Muy AltaCapacida y madured de

ICASE Muy Baja Baja Nominal Alta Muy AltaPROD 4 7 13 25 50

7. Calcular la estimacin de personas-mes:

Ecuacin 9


32/54

28

MMOODDEELLOO DDEE DDIISSEEOO IINNIICCIIAALL ((AANNTTIICCIIPPAADDOO))..

Se utilizarn Puntos Funcin Desajustados como medida de tamao. Este modeloes usado en los primeros estados de un proyecto software, cuando pocas cosaspodemos conocer sobre el tamao del producto a desarrollar, la naturaleza de laplataforma objetivo, la naturaleza del personal involucrado en el proyecto, o losdetalles especficos del proceso que se utilizar. Este modelo podra ser empleado enGeneradores de Aplicaciones, Integracin de Sistemas, o sectores de desarrollo deinfraestructuras.

CUENTA DE PUNTOS FUNCIN

La aproximacin de la estimacin del coste mediante Puntos Funcin est basadaen la cantidad de funcionalidades de un proyecto software y en un conjunto de factoresindividuales del proyecto. Los Puntos Funcin son estimaciones valiosas ya que estnbasadas en la informacin que est disponible al inicio del ciclo de vida del proyecto.

Los Puntos Funcin miden un proyecto software cuantificando la informacinasociada a los principales datos externos o control de entrada, salida, o tipos deficheros.

Pueden identificarse cinco tipos de funciones de usuario segn la Tabla 9:

Entrada Externa(Entradas)

Cuenta cada dato de usuario o tipo de entrada de control del usuario que(1) se introduce desde el exterior del sistema y (2) que aade o modificadatos en un fichero lgico interno.

Salida Externa(Salidas)

Cuenta cada dato de usuario o tipo de entrada de control que abandona elsistema hacia el exterior.

Ficheros Lgicos Internos

(Ficheros)

Ficheros pasados o compartidos entre sistemas software que deberan

contarse como tipos de ficheros de interface externos que estn dentro delsistema.

Consultas Externas(Informes)

Cuenta cada combinacin de entrada-salida nica, donde una entradacausa y genera una salida inmediata, como un tipo de consulta externa.

Tabla 9: Tipos de Funciones de Usuario.

Cada instancia de estos tipos de funciones es clasificado segn su nivel decomplejidad. Los niveles de complejidad determinan un conjunto de pesos o valores,los cuales son aplicados a su correspondiente cuenta de tipo de funcin paradeterminar la cantidad de Puntos Funcin Desajustados. Esta es la funcin de medidadel tamao empleada por COCOMO 2.0. El procedimiento usual de Puntos Funcinincluye una valoracin del grado de influencia (DI) de catorce caractersticas de laaplicacin del proyecto software de acuerdo a una escala, que va desde 0'0 a 0'05para cada caracterstica. Los 14 ratios son sumados juntos, y aadidos a un nivel basede 0'65 para producir un factor de ajuste de las caractersticas generales con un rangoque va desde 0'65 hasta 1'35.

Cada una de estas 14 caractersticas, como son las funciones distribuidas,rendimiento, y reusabilidad, contribuyen hasta un mximo del 5% sobre el esfuerzoestimado. Esto resulta inconsistente para la experiencia de COCOMO; es por ello queCOCOMO 2.0 utiliza Puntos Funcin Desajustados para realizar una medida deltamao, y aplica factores de reutilizacin, parmetros de coste multiplicativos delesfuerzo, y factores de escala que son exponenciales.


33/54

29

PROCEDIMIENTO DE CUENTA DE PUNTOS FUNCIN DESAJUSTADOS

El procedimiento usado en COCOMO 2.0 para determinar los Puntos FuncinDesajustados es el siguiente:

1. Contar las funciones segn su tipo: la cuenta de funciones desajustadas deberaser realizada por un tcnico basndose en la informacin recopilada en losdocumentos de requerimientos y diseo del software. El nmero de cada uno delos cinco tipos de funciones de usuario (Ficheros Lgicos Internos (ILF), Ficherosde Interface Externos (EIF), Entrada Externa (EI), Salida Externa (EO), y ConsultasExternas (EQ)) debe de ser obtenido.

2. Contar las funciones atendiendo al nivel de complejidad: contar y clasificar cadafuncin dentro de los niveles (Bajo, Medio, o Alto) de complejidad dependiendo delos tipos de datos y el nmero de tipos de ficheros referenciados. Utilizar para elloel siguiente esquema:

Para ILF y EIF Para EO y EQ Para EIElementos Dato Elementos Dato Elementos DatoElementosRegistro 1-19 20-50 51+

Tipos deFicheros 1-5 6-19 20+

Tipos deFicheros 1-4 5-15 16+

1 Bajo Bajo Med 0 o 1 Bajo Bajo Med 0 o 1 Bajo Bajo Med2-5 Bajo Med Alto 2-3 Bajo Med Alto 2-3 Bajo Med Alto6+ Med Alto Alto 4+ Med Alto Alto 3+ Med Alto Alto

3. Aplicar los pesos asignados a cada nivel de complejidad: utilizar los pesos delsiguiente esquema (los pesos reflejan el valor relativo de cada funcin para elusuario):

Complejidad-PesoTipos de Funcin Bajo Medio Alto

Ficheros Lgicos Internos 7 10 15Ficheros de Interface Externos 5 7 10Entradas Externas 3 4 6Salidas Externas 4 5 7Consultas Externas 3 4 6

4. Calcular los Puntos Funcin Desajustados: sumar todos los pesos contados paraobtener un nico nmero, nmero que determina el valor de los Puntos FuncinDesajustados.

CONVERSIN DE PUNTOS FUNCIN A LNEAS DE CDIGO

Para determinar el nmero nominal de personas mes que nos da la Ecuacin 1para el Modelo de Diseo Inicial, los Puntos Funcin Desajustados han de convertirsea lneas de cdigo fuente que implementen el lenguaje (ensamblador, lenguaje de altonivel, lenguaje de cuarta generacin, etc).

COCOMO 2.0 realiza esto para los modelos de Diseo Inicial y Post-Arquitecturamediante el uso de tablas para poder transladar estos Puntos Funcin Desajustadosen el equivalente a SLOC:

Lenguaje SLOC/FPAda 71AI Shell 49APL 32

Ensamblador 320Ensamblador (Macro) 213


34/54

30

Lenguaje SLOC/FPANSI/Quick/Turbo Basic 64Basic-Compilado 91Basic-Interpretado 128C 128C++ 29ANSI Cobol 85 91Fortran 77 105Forth 64Jovial 105Lisp 64Modula 2 80Pascal 91Prolog 64Generador de Informes 80Hoja de Clculo 6

Tabla 10: Conversin de Puntos Funcin a Lneas de Cdigo.

PARMETROS DE COSTE (COST DRIVERS)

El modelo de Diseo Inicial utiliza KSLOC para valorar el tamao. Los PuntosFuncin Desajustados son convertidos a su equivalente en SLOC y luego a KSLOC.La aplicacin de los factores de escala del proyecto es igual en el modelo de DiseoInicial y en el modelo Post-Arquitectura. En el modelo de Diseo Inicial un reducidoconjunto de parmetros de coste es utilizado. Los parmetros de coste del modelo deDiseo Inicial se obtienen por combinacin de los parmetros de coste del modeloPost-Arquitectura de la Tabla 19. La ecuacin de esfuerzo es la misma que la dada porla Ecuacin 4.

Aproximacin global: Ejemplo de Capacidad Personal (PERS).

La siguiente aproximacin es utilizada para "mapear" un conjunto completo deparmetros de coste y escalas de ratios de los participantes en el modelo de DiseoInicial. Esto incluye el uso y combinacin de equivalentes numricos a los niveles deratio. Ms especficamente, a un parmetro de coste del modelo Post-Arquitectura conun ratio de "Muy Bajo" le corresponde un valor numrico de 1, 2 para "Bajo", 3 para"Nominal o medio", 4 para "Alto", 5 para "Muy Alto" y 6 para "Extra Alto". Para losparmetros de coste combinados del modelo de Diseo Inicial, los valores numricosde los parmetros de coste del modelo Post-Arquitectura, Tabla 11, son sumados y elresultado total es asignado a un ratio de escala (desde Extra Bajo a Extra Alto) del

modelo de Diseo Inicial.

Parmetro de CosteDiseo Inicial

Combinacin EquivalentePost-Arquitectura

RCPX RELY, DATA, CPLX, DOCURUSE RUSEPDIF TIME, STOR, PVOLPERS ACAP, PCAP, PCONPREX AEXP, PEXP, LTEXFCIL TOOL, SITE

SCED SCEDTabla 11: Multiplicadores de esfuezo Diseo Inicial y Post-Arquitectura.

La escala de ratios del modelo de Diseo Inicial siempre tiene un total nominaligual a la suma de los ratios nominales de los elementos del modelo Post-Arquitecturacon los que se han formado.


35/54

31

El siguiente ejemplo ilustrar esta aproximacin. El parmetro de coste PERS delDiseo Inicial combina los parmetros de coste Post-Arquitectura de capacidad delanalista (ACAP), capacidad del programador (PCAP), y continuidad del personal(PCON). Cada uno de estos tiene una escala de ratios desde Muy Bajo (=1) a MuyAlto (=5). Sumando estos ratios numricos se produce un rango de valores entre 3 y15. Estos son diseados sobre una escala, y los niveles de ratio PERS del DiseoInicial son asignados a ellos, tal y como muestra la Tabla 19.

Extra Bajo Muy Bajo Bajo Nominal Alto Muy Alto Extra AltoSuma de

rangos ACAP,PCAP, PCON

3, 4 5, 6 7, 8 9 10, 11 12, 13 14, 15

Combinacinporcentajes

ACAP y PCAP20% 39% 45% 55% 65% 75% 85%

Personal queanualmente

regresa45% 30% 20% 12% 9% 5% 4%

Tabla 12: Niveles de ratio PERS

El ratio personal PERS con valor 9 corresponde a la suma (3+3+3) de los ratiosnominales para ACAP, PCAP y PCON, y su multiplicador de esfuerzo correspondientees 1'0. Tener en cuenta que de todas formas el ratio nominal PERS de 9 resulta depoder haber sumado otras combinaciones, por ejemplo 1+3+5=9 para ACAP=MuyBajo, PCAP=Nominal, y PCON=Muy Alto.

Las escalas de ratio y los multiplicadores de esfuerzo para PCAP y los otrosparmetros de coste de Diseo Inicial mantienen la consistencia relacional con susequivalentes en el modelo Post-Arquitectura. Por ejemplo, los niveles de ratio ExtraBajo de PERS (20% combinando ACAP y PCAP, y el 25% de movimiento de personal)representan niveles de ratio medios de ACAP, PCAP, y PCON por encima del 3 o 4.

Manteniendo estas relaciones de consistencia entre los niveles de ratio del DiseoInicial y Post-Arquitectura se asegura la consistencia en las estimaciones de coste deestos dos modelos (de Diseo Inicial y Post-Arquitectura).

Complejidad y Confianza del Producto.

Estos parmetros de coste del Diseo Inicial combinan los cuatro parmetros decoste Post-Arquitectura (Confianza Software Requerida (RELY), tamao de la base dedatos (DATA), Complejidad del Producto (CPLX), y Documentacin asociada a lasnecesiddes del ciclo de vida (DOCU)). A diferencia de los componentes PERS, loscomponentes RCPX tienen escalas de ratio con diferente margen. Los rangos deRELY y DOCU van desde Muy Bajo a Muy Alto; los rangos de DATA van desde Bajo aMuy Alto; y los rangos de CPLX van desde Muy Bajo a Extra Alto. Y con un valornumrico entre 5 (Muy Bajo, Bajo, Muy Bajo, Muy Bajo) y 21 (Muy Alto, Muy Alto, ExtraAlto, Muy Alto).

La Tabla 19 asigna los ratios RCPX a travs de este rango, y asocia escalas deratio apropiadas a cada uno de los ratios RCPX (desde Extra Bajo a Extra Alto).

ExtraBajo

MuyBajo

Bajo Nominal Alto MuyAlto

ExtraAlto

Suma de ratios RELY,DATA, CPLX, DOCU

5, 6 7, 8 9 -11 12 13 - 15 16 - 18 19 - 21

Enfasis sobre confiana,documentacin Muypoco Poco Algo Basico Fuerte Muyfuerte Extremo

Complejidad del producto Muy Simple Algo Moderado Compl Muy Extrema


36/54

32

ExtraBajo

MuyBajo

Bajo Nominal Alto MuyAlto

ExtraAlto

Simple ejo complejo damentecomplejo

Tamao de la base da datos Pequeo Pequeo Pequeo Moderado grande Muygrande

Muygrande

Tabla 13: Niveles de ratio de RCPX

Reutilizacin Requerida (RUSE).

Este parmetro de coste del Diseo Inicial es el mismo a su homnimo en elmodelo Post-Arquitectura. Un resumen de estos niveles de ratio se ofrece aqu, y en laTabla 19:

Muy Bajo Bajo Nominal Alto Muy Alto Extra Alto

RUSEninguno A travs del

proyectoA travs delprograma

A travs de lalnea deproducto

A travs demltipleslneas de

productoTabla 14: Resumen del nivel de ratio de RUSE

Inconvenientes de la Plataforma (PDIF).

Este parmetro de coste del Diseo Inicial combina los tres parmetros de costePost-Arquitectura (tiempo de ejecucin (TIME), almacenamiento principal (STOR), yvolatilidad de la plataforma (PVOL)). TIME y STOR tienen rangos desde Nominal aExtra Alto; PVOL rangos desde Bajo a Muy Alto. Y con un valor numrico entre 8(Nominal, Nominal, Bajo) y 17 (Extra Alto, Extra Alto, Muy Alto).

Bajo Nominal Alto Muy Alto Extra AltoSuma de TIME,STOR, y PVOL

8 9 10 - 12 13 - 15 16, 17

Restriccin dealmacenamiento yTiempo

#50% #50%65% 80% 90%

Volatilidad de laplataforma

Muy estable estable Algo volatil volatil Altamentevolatil

Tabla 15: Niveles de ratio de PDIF

Experiencia Personal (PREX).

Este parmetro de coste del Diseo Inicial combina los tres parmetros de costePost-Arquitectura (experiencia en la aplicacin (AEXP), experiencia en la plataforma(PEXP), y experiencia en las herramientas y lenguajes (LTEX)). Cada uno de estoscon un rango desde Muy Bajo a Muy Alto. Y con un valor numrico entre 3 y 15.

ExtraBajo

Muy Bajo Bajo Nominal Alto Muy Alto ExtraAlto

Suma de ratios deAEXP, PEXP, y

LTEX 3, 4 5, 6 7, 8 9 10, 11 12, 13 14, 15Experiencia enAplicaciones,

Plataforma,Lenguaje y

Herramientas

#3 meses5 meses 9 meses 1 ao 2 aos 4 aos 6 aos

Tabla 16: Niveles de ratio PREX


37/54

33

Facilidades (FCIL).

Este parmetro de coste del Diseo Inicial combina dos parmetros de costePost-Arquitectura: uso de herramientas software (TOOL) y desarrollo multisitio odistribuido (SITE). TOOL tiene un rango desde Muy Bajo a Muy Alto; el rango de SITEva desde Muy Bajo a Extra Alto. El valor numrico suma de estos ratios est entre 2(Muy Bajo, Muy Bajo) y 11 (Muy Alto, Extra Alto).

Planificacin (SCED).

Este parmetro de coste de Diseo Inicial es el mismo que su hommino en elmodelo Post-Arquitectura. Ver Tabla 19.

ExtraBajo

Muy Bajo Bajo Nominal Alto Muy Alto ExtraAlto

Suma ratios de TOOLy SITE

2 3 4, 5 6 7, 8 9, 10 11

Soporte TOOL Minima Alguna Simplecoleccin

deherramientas CASE

Herramientas deciclo de

vidabsicas

Buena;moderada

menteintegrada

Fuerte;moderada

menteintegrada

Fuerte;muy

integrada

Condiciones Multisitio Escasosoporte

decomplejodesarrollomultisitio

Algnsoporte

decomplejodesarrollomultisitio

Algnsoporte

demoderadodesarrollomultisitio

Soportebsico demoderadodesarrollomultisitio

Fuertesoporte

demoderadodesarrollomultisitio

Fuertesoporte

de simpledesarrollomultisitio

Muyfuerte deordenadoo simple

desarrollomultisitio

Tabla 17: niveles de ratio FCIL.

Muy Bajo Bajo Nominal Alto Muy Alto Extra AltoSCED 75% del

nominal85% 100% 130% 160%

Tabla 18: Resumen de nivel de ratio SCED.


38/54

34

MMOODDEELLOO PPOOSSTT--AARRQQUUIITTEECCTTUURRAA..

Este modelo es el ms detallado y es utilizado cuando la arquitectura del ciclo devida del software ha sido desarrollada. Este modelo es usado en el desarrollo ymantenimiento de productos software como Generadores de Aplicaciones, Integracinde Sistemas e Infraestructura.

NOMAS PARA CONTAR LAS LNEAS DE CDIGO

En COCOMO 2.0 las sentencias lgicas fuente han sido elegidas como el estndarpara determinar la lnea de cdigo. Definir el concepto de lnea de cdigo es una difciltarea debido a las diferencias conceptuales que suponen para diferentes lenguajes lassentencias ejecutables y declaraciones de datos. El objetivo es medir la cantidad detrabajo intelectual puesto en el desarrollo del programa, pero surgen dificultadescuando intentamos definir medidas consistentes para lenguajes diferentes. Para

minimizar estos problemas, la definicin que da el Instituto de Ingeniera del Software(SEI) de sentencia lgica fuente es utilizada para definir la medida de lneas decdigos.

La figura 5 de la pgina siguiente muestra cmo una parte de esta definicin esaplicada para soportar el desarrollo del modelo COCOMO 2.0. Cada marca en lacolumna "Incluye" identifica un tipo de sentencia particular o atributo incluido en ladefinicin, y viceversa para la columna "Exclude". Otras secciones en la definicinclarifican los atributos de las sentencias para su uso, reparto, funcionalidad, replicaciny estudio de desarrollo. Hay tambin aclaraciones para sentencias especficas delenguajes como ADA, C, C++, CMS-2, COBOL, FORTRAN, JOVIAL y Pascal.

Algunos cambios fueron realizados para definir lnea de cdigo para apartarse dela definicin por defecto. Estos cambios eliminan categoras de software las cualesresultan ser generalmente pequeas fuentes de esfuerzo del proyecto. El cdigogenerado con generadores de cdigo fuente no est incluido, aunque sin embargoser tenido en cuenta para soportar el anlisis.

La definicin de lnea de cdigo de COCOMO 2.0 est calculada directamente porla coleccin de herramientas mtricas automatizadasAmadeus, las cuales son usadaspara asegurar la uniformidad de la coleccin de datos dentro de los datos recopiladosy del anlisis del proyecto de COCOMO 2.0.

Para soportar mejor el anlisis de datos, Amadeus tomar automticamentemedidas adicionales que incluyen las lneas fuente totales, comentarios, sentenciasejecutables, declaraciones, estructura, componentes de interfaz, y otros. Laherramienta proporcionar varias medidas del tamao.


39/54

35

Figura 5


40/54

36

PUNTOS FUNCIN

Para la estimacin de puntos funcin del modelo Post-Arquitectura, son vlidos losclculos utilizados para convertir los Puntos Funcin Desajustados a KSLOC que seutilizan en el modelo de Diseo Inicial. COCOMO 2.0 permite que algunoscomponentes sean evaluados utilizando puntos funcin, y otros (en los cuales lospunto funcin no los describen correctamente, tales como clculos cientficos o entiempo real) en SLOC. Toda medida es expresada en KSLOC y usada en la Ecuacin4. El Apndice A muestra la ecuacin para el modelo Post-Arquitectura.

PARMETROS DE COSTE

Existen 17 multiplicadores de esfuerzo utilizados en el modelo Post-Arquitecturapara ajustar el esfuerzo nominal, Persona mes, para poder reflejar el productosoftware bajo desarrollo. Estos multiplicadores son agrupados en cuatro categorias:

del producto, de la plataforma, personales, y del proyecto. La figura 19 muestra losdiferentes parmetros de coste junto a sus criterios para establecer los rangos.Siempre que una valoracin de un parmetro de coste est entre un rango de valorescercanos al valor medio, por ejemplo si un parmetro de coste est entre Alto y MuyAlto, entonces seleccionaremos Alto. Una parte de estos multiplicadores del esfuerzohan sido tratados ya en el modelo de Diseo Inicial.

Factores del Producto:

Confianza Software Requerida (RELY). Esta es una medida hasta el puntode lo que el software debe realizar mediante las funciones construidas ydurante un periodo de tiempo. Si el efecto de un fallo software es

nicamente producir pequeos inconvenientes, entonces RELY tienen unvalor bajo. Si un fallo llegase a arriesgar la vida humana entonces RELYtomara un valor muy alto.

Tamao de Base de Datos (DATA). Esta medida pretende capturar losefectos que tienen requerimientos de gran cantidad de datos sobre eldesarrollo del producto. El porcentaje est determinado por clculo D/P. Eltamao de la base de datos es una consideracin importante debido alesfuerzo requerido para generar todos los test de datos.

Ecuacin 10

DATA toma un valor bajo si D/P es menor de 10, y toma un valor muy alto sies mayor de 100.

Complejidad del Producto (CPLX). La Tabla 20 proporciona la nueva escalade ratios de CPLX en el modelo COCOMO 2.0. La complejidad es divididaen cinco reas: operaciones de control, operaciones computacionales (declculo), operaciones que son dependientes de los dispositivos,operaciones de manejo de datos, y operaciones de gestin del interfaz de

usuario. Una seleccin de ests reas o combinacin de ellas caracterizar


41/54

37

el producto, o a un subsistema o parte del producto. La escala decomplejidad es una valoracin subjetiva media de estas reas.

Reutilizacin Requerida (RUSE). Este parmetro de coste mide el esfuerzoadicional necesario para la construccin de componentes que puedanreutilizarse en el actual o en futuros proyectos. Este esfuerzo es consumidodurante la creacin de un diseo software ms genrico, unadocumentacin ms elaborada, y un chequeo ms exhaustivo paraasegurarse de que los componentes quedan listos para ser utilizados enotras aplicaciones.

Muy bajo Bajo Nominal Alta Muy alta Extra AltaRELY Inconvenientes

sin importanciaPoco Moderado Alta Riesgos

DATA DB bytes/PgmSLOC


42/54

38

Muy baja Baja Nominal Alta Muy alta Extra alta

Operacionesde control

Lineas simplesde cdigo conpoco codigo ysin estructurasanidadas:

DOs, CASEs,IFTHENELSs.Llamadas aprocedimientossimples.

Uso anidadode operadoresdeprogramacinestructurada

de formadirecta.Mayoritariamente uso depredicadossimples.

Mayora de losanidamientosde operadoresson simples.Algn control

entre modulos.Tablas dedecisin. Pasode mensajes,incluyendoprocesodistribuido amedio nivel

Programacinaltamenteanidada conmuchacomposicin

de predicados.Procesosdistribuidos.Control entiempo realsimple.

Codigoreentrante yrecursivo.Manejo deinterrupciones

con prioridad.Sincronizacinde tareas,control entiempo realcomplejo.

Mltipleplanificacinde recursoscon prioridadesque cambian

dinamicamente. Control anivel demicrocdigo.Controldistribuido entiempo real.

Operacionesde computo

Evaluacinsimple deexpresiones:A=B+C*(D-E)

Evaluacin deexpresiones anivel medio:SQRT(B2-4*A*C)

Uso de rutinasestandar,matemticas yestadsticas.Operacionesbsicas sobrematrices ovectores.

Analisisnumricobsico:multivariable,interpolacion,ecuacionesdiferencialesde primerorden.

Dificil yestructuradoanlisisnumrico:ecuacionesmatriciales,ecuacionesdiferencialesparciales.Paralelizacinsimple.

Analisisnumrico dificily noestructurado:anlisisaltamentepreciso deruido, datosestocsticos.Paralelizacincompleja.

Operacionesdependientesdedispositivos

Lecturassimples,escritura dedeclaracionescon formassimples.

No esnecesarioconocimientosobreprocesadoresI/Oparticulares. LaI/O se realiza aniivel deGET/PUT.

El proceso deI/O incluyeseleccin dedispositivos,comprobacinde estado, yproceso de loserrores.

Operacionesde I/O a nivelfisico(traduccin dedireccionesfsicas,posicionamientos enmemoria,lecturas, ...).

Rutinas paradiagnstico, deservicio, deenmascaramiento deinterrupciones.Manejo de linadecomunicaciones. Sistemas deprocesointensivo.

Codificacincon control detiempos dedispositivos,operacionesdemicroprogramacin. Sistemasde procesocrtico.

Operacionesde manejo dedatos

Arrayssencillos enmemoriaprincipal.Consultas yactualizacionessimples de labase de datos.

Tramtamientode ficheros deforma simple,sin cambios enla estrucutrade datos, sinficherosintermedios, ...Consultas yactualizacionesmoderadas dela base dedatos.

Entrada desdevarios ficheros,y salida nica.Cambiossimples en laestructura.Consultas yactualizacionescomplejas.

Simplesseales deactivacinflujos dedatos.Reestructuracin de datoscompleja.

Coordinacinde bases dedatosdistribuidas.Seales deactivacincomplejas.Optimizacinde bsquedas.

Altamenteacoplados,relacionadosdinmicamentey conestructura deobjetos.Manejo delenguajenatural dedatos.

Operacionespara gestindel interfaz deusuario

Formularios deentradasimples.Generador delistados.

Uso de GUIssimples.

Uso simple deelementos deinterfaz.

Desarrollo deelementos deinterfaz.Multimedia yI/O simple convoz.

Moderadamente complejo,2D/3D,grficosdinmicos.

Multimediacompleja,realidad virtual.

Tabla 20. Valoracin de complejidad segn el tipo de modulo

Documentacin relacionada con las necesidades del ciclo de vida (DOCU).Distintos modelos de coste software poseen un parmetro de coste paravalorar el nivel de documentacin requerida. En COCOMO 2.0, la escala deratio para el parmetro de coste DOCU es evaluada en trminos de laadecuada documentacin del proyecto que necesita el ciclo de vida. Estaescala va desde Muy Bajo (se observan algunas necesidades del ciclo devida) hasta Muy Alto (muchas y grandes necesidades del ciclo de vida).


43/54

39

Factores de la Plataforma:

La plataforma se refiere al complejo formado por el hardware e infraestructurasoftware (antes conocido como mquina virtual) de la mquina objetivo. Los factoreshan sido revisados para reflejar estos parmetros tal y como se describen. Algunosfactores adicionales de la plataforma fueron considerados, tal como distribucin,paralelismo, sistemas empotrados, y operaciones en tiempo real. Estasconsideraciones han sido acomodadas mediante la expansin de los porcentajes delModulo de Complejidad en la Ecuacin 20.

Tiempo de Ejecucin Necesitado (TIME). Esta es una medida del tiempode ejecucin que es impuesto, por necesidad, por el sistema software. Elporcentaje es expresado en trminos del tanto por ciento del tiempo deejecucin disponible que se espera que ea consumido por el sistema osubsistema, del total del recurso formado por el tiempo de ejecucin. Losrangos van desde Nominal, menos del 50% usado de este recurso, hasta elExtra Alto, 95% de este tiempo.

Volatilidad de la plataforma (PVOL). El trmino "plataforma" es utilizadopara comprender el complejo conjunto formado por el hardware y software(OS, DBMS, etc) que el producto software utiliza, llama, para realizar sustareas. Si el software a desarrollar es un sistema operativo entonces laplataforma es el hardware de la computadora. Si es un sistema gestor debases de datos lo que va a desarrollarse, entonces la plataforma es elhardware y el sistema operativo. Si es un navegador texto de red el objetivodel desarrollo, entonces la plataforma es la red, el hardware de lacomputadora, el sistema operativo, y los lugares distribuidos donde selocaliza la informacin. La plataforma incluye cualquier compilador oensamblador utilizado para desarrollar el sistema software. Este rango va

desde Bajo, donde existen cambios importantes en la plataforma cada 12meses, hasta Muy Alta, con cambios importantes cada dos semanasaproximadamente.

Factores Personales:

Capacidad de los Analistas (ACAP). Los analistas son personas quetrabajan sobre los requerimientos, disean a un alto nivel y lo detallan. Losprincipales atributos que deberan de ser considerados en esta categorason la habilidad y eficiencia, y la habilidad de comunicacin y cooperacin.Esta escala no debera de expresar el nivel de experiencia del analista, queya es valorado con AEXP.

Capacidad del Programador (PCAP). La tendencia actual enfatiza laimportancia de analistas altamente capaces, sin embargo el papel crecientede los complejos paquetes COTS, y la influencia de una significativaproductividad asociada con la habilidad de los programadores para tratarcon estos paquetes COTS, indica una buena tendencia que da mayorimportancia a las capacidades del programador.

La evaluacin debera de basase en la capacidad de los programadorespara formar grupos ms que en su individualidad. Los principales factores

que deberan ser considerados para establecer estos niveles son pues lahabilidad y eficiencia, y la habilidad de comunicacin y cooperacin. La


44/54

40

experiencia de los programadores no debera de ser considerada aqu, yaque es valorada con AEXP.

Experiencia en las Aplicaciones (AEXP). Esta valoracin es dependientedel nivel de experiencia que se posee en las aplicaciones por el equipo dedesarrollo. Los ratios son definidos en trminos de equipos de proyectoequivalentes al nivel de experiencia con ese tipo de aplicacin. Un rango deMuy Bajo para una experiencia menor de 2 meses, y Muy Alto si se poseeuna experiencia igual o superior a 6 aos.

Experiencia en la Plataforma (PEXP). El modelo Post-Arquitectura amplia lainfluencia que sobre la productividad tiene este parmetro PEXP,reconociendo la importancia de comprender el uso de ms plataformaspotentes, incluyendo interfaces de usuario grficos, bases de datos, trabajocon redes, etc...

Experiencia con Herramientas y Lenguajes (LTEX). Esta es una medida del

nivel de experiencia con lenguajes de programacin y utilidades softwareque posee el equipo de desarrollo del sistema o subsistema. El desarrollodel software incluye el uso de herramientas para realizar los requerimientos,y el anlisis y diseo de la representacin, manejo de la configuracin,extraccin de la documentacin, gestin de librerias, formateo y estilo deprograma, chequeo de consistencia, etc... Adicionalmente a la experienciaen programacin con un lenguaje especfico, el soporte de un conjunto deutilidades o herramientas tiene efectos sobre el tiempo de desarrollo. Unratio Bajo se da para una experiencia menor de 2 meses, y de Muy Altopara experiencias iguales o mayores a 6 aos.

Continuidad del Personal (PCON). El ratio de la escala para PCON se da

en trminos del personal que retorna anualmente al proyecto: desde 3%,Muy Alto, al 48%, Muy Bajo.

Factores del Proyecto:

Uso de herramientas software ITOOL). Las herramientas software hanmejorado significativamente desde los aos 70, que sirvieron para calibrarel COCOMO. El ratio de rangos van desde las simples herramientas deedicin y coficicacin, a las que se les asigna un valor asociado de MuyBajo, hasta las herramientas integradas de gestin del ciclo de vida,asignndoles un valor de Muy Alto.

Desarrollo Multisitio (SITE). Dan la creciente frecuencia de desarrollosrealizados en distintos lugares, e indican como este desarrollo multisitiotiene unos efectos significativos, es por ello que estas caractersticas fueronaadidas al COCOMO 2.0. La determinacin de estos parmetros de costeincluyen la valoracin y un promedio de dos factores: la situacin (dentrode una distribucin mundial) y el soporte de comuncicaciones (desde elcorreo y telfono, hasta los completos medios interactivos de carctermultimedia).

Planificacin de Desarrollo Requerida (SCED). Este ratio mide la

planificacin temporal a establecer, obligada e impuesta por el equipo dedesarrollo del proyecto del software. Los ratios son definidos en trminos


45/54

41

del porcentaje de planificacin que se alarga o acelera con respecto a laplanificacin media para un proyecto que necesita una cantidad deesfuerzo determinado. Planificaciones temporales aceleradas tienden aproducir ms esfuerzo en las ltimas fases de desarrollo debido a que msasuntos son dejados para ser determinados posteriormente. Unaplanificacin comprimida un 74% es valorada como un porcentaje MuyBajo, y un alargamiento del 160% es valorada como un porcentaje MuyAlto.


46/54

42

GLOSARIOGLOSARIOGLOSARIOGLOSARIO

3GL Lenguaje de Tercera Generacin

AA Porcentaje de esfuerzo de reusabilidad que es debido a la Valoracin yAsimilacin de ese cdigo reutilizable.

ACAP Capacidad del Analista

AEXP Experiencia en la Aplicacin

ASLOC Adaptacin de Lnea de Cdigo Fuente

BRAK Breakage. Cantidad de cambios controlados que se permiten en un

desarrollo software antes del "cierre" de los requerimientos.CASE Ingeniera del Software Asistida por Computador

CM Porcentaje de cdigo modificado persiguiendo la reutilizacin

CMM Modelo de Capacidad de Madured

CostDrivers

Prametro que influye en el coste del software. Es una caractersticaparticular de un desarrollo software que tiene efectos sobre la cantidad delesfuerzo de desarrollo, incrementandolo o decrementandolo.

COTS "Commercial Off The Shelf"

CPLX Complejidad del Producto

DATA Tamao de la Base de Datos.

DBMS Sistema Gestor de Bases de Datos.

DI Grado de Influencia.

DM Porcentaje del diseo que es modificado debido a la reusabilidad.

DOCU Documentacin asociada con las necesidades del ciclo de vida.

ESLOC Equivalente en Lneas de Cdigo Fuente.

FCIL Facilidades.

FP Puntos Funcin

GUI Interface Grfico de Usuario


47/54

43

ICASE Entorno Software Integrado Asistido por Computador

IM Porcentaje de integracin que se vuelve a hacer persiguiendo lareutilizacin de cdigo

KSLOC Miles de Lneas de Cdigo Fuentes

LTEX Experiencia en Lenguajes y Herramientas

NOP Nuevos Puntos Objeto

OS Sistemas Operativos

PCAP Capacidad del Programador

PCON Continuidad del Personal

PDIF Dificultad de la Platadorma

PERS Capacidad del Personal

PEXP Experiencia en la Plataforma

PL Linea de Producto

PM Persona Mes. Es la cantidad de tiempo que dedica durante un mes una

sla pesona que trabaja sobre un proyecto de desarrollo softwarePREX Experiencia Personal

PROD Porcentaje de Productividad

PVOL Volatilidad de la Plataforma

RCPX Complejidad y Fiabilidad del Producto

RELY Fiabilidad Software Requerida

RUSE Reusabilidad Requerida

SCED Planificacin de Desarrollo Requerida

SEI Instituto de Ingeniera del Software

SITE Desarrollo Multisitio

SLOC Lneas de Cdigo Fuente


48/54

44

STOR Restriccin de Almacenamiento Principal

SU Porcentaje de esfuerzo requerido en la reutilizacin del cdigo, y que esdebido a la comprensin del software

TIME Restriccin de Tiempo de Ejecucin

TOOL Uso de Herramientas Software


49/54

45

Apndice A: ECUACIONESApndice A: ECUACIONESApndice A: ECUACIONESApndice A: ECUACIONES

CCOOMMPPOOSSIICCIINNDDEEAAPPLLIICCAACCIIOONNEESS ..

Los Puntos Objeto Nuevos son determinados por:

Ecuacin 11

El porcentaje de productividad, PROD, es estimado mediante una media subjetiva deexperiencia del desarrollador y la capacidad y madured de la herramienta ICASE:

Capacidad y Experiencia deldesarrollador

Muy Bajo Bajo Medio Alto Muy Alto

Capacidad y Madured de

2841_Apunte11COCOMOV2

Documents

Transcript of 2841_Apunte11COCOMOV2