Post on 12-Feb-2018
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
7/23/2019 2841_Apunte11COCOMOV2
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.html7/23/2019 2841_Apunte11COCOMOV2
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
7/23/2019 2841_Apunte11COCOMOV2
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
7/23/2019 2841_Apunte11COCOMOV2
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.
7/23/2019 2841_Apunte11COCOMOV2
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/23/2019 2841_Apunte11COCOMOV2
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.
7/23/2019 2841_Apunte11COCOMOV2
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.
7/23/2019 2841_Apunte11COCOMOV2
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:
7/23/2019 2841_Apunte11COCOMOV2
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.
7/23/2019 2841_Apunte11COCOMOV2
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
7/23/2019 2841_Apunte11COCOMOV2
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.
7/23/2019 2841_Apunte11COCOMOV2
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.
7/23/2019 2841_Apunte11COCOMOV2
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.
Orgnico Semiempotrado Empotrado
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.
7/23/2019 2841_Apunte11COCOMOV2
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:
Orgnico Semiempotrado Empotrado
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:
7/23/2019 2841_Apunte11COCOMOV2
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/)
7/23/2019 2841_Apunte11COCOMOV2
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.
7/23/2019 2841_Apunte11COCOMOV2
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.
7/23/2019 2841_Apunte11COCOMOV2
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.
7/23/2019 2841_Apunte11COCOMOV2
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.
7/23/2019 2841_Apunte11COCOMOV2
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
7/23/2019 2841_Apunte11COCOMOV2
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.
7/23/2019 2841_Apunte11COCOMOV2
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
7/23/2019 2841_Apunte11COCOMOV2
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
7/23/2019 2841_Apunte11COCOMOV2
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.
7/23/2019 2841_Apunte11COCOMOV2
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
7/23/2019 2841_Apunte11COCOMOV2
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
7/23/2019 2841_Apunte11COCOMOV2
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.
7/23/2019 2841_Apunte11COCOMOV2
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
7/23/2019 2841_Apunte11COCOMOV2
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
7/23/2019 2841_Apunte11COCOMOV2
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
7/23/2019 2841_Apunte11COCOMOV2
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.
7/23/2019 2841_Apunte11COCOMOV2
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
7/23/2019 2841_Apunte11COCOMOV2
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.
7/23/2019 2841_Apunte11COCOMOV2
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
7/23/2019 2841_Apunte11COCOMOV2
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
7/23/2019 2841_Apunte11COCOMOV2
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.
7/23/2019 2841_Apunte11COCOMOV2
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.
7/23/2019 2841_Apunte11COCOMOV2
39/54
35
Figura 5
7/23/2019 2841_Apunte11COCOMOV2
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
7/23/2019 2841_Apunte11COCOMOV2
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
7/23/2019 2841_Apunte11COCOMOV2
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).
7/23/2019 2841_Apunte11COCOMOV2
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
7/23/2019 2841_Apunte11COCOMOV2
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
7/23/2019 2841_Apunte11COCOMOV2
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.
7/23/2019 2841_Apunte11COCOMOV2
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
7/23/2019 2841_Apunte11COCOMOV2
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
7/23/2019 2841_Apunte11COCOMOV2
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
7/23/2019 2841_Apunte11COCOMOV2
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