Modelos_estimacion_costo
22
't \ if :l Il 11 ,1 lt It f 1;;- :1 MODELOS DE ESTIMACION DE COSTO Y ESFUERZO EN PROYECTOS DE SOFTWARE RAFAEL ANTONIO GORDILLO ALBERTO NOE GIRALDO LUIS BALDOMERO DAVILA Alumnos del curso de Investigación de VIII Semestre de Ingeniería de Sistemas del ICES!. INTRODUCCION En todo de desarrollo de que afectan L de una u otra...torrna...eI cago .. requerimientos de El factor iieÍllpo-tambié-ñ-ha-de téñersé en cuen- ta a la hora de evaluar las característi- cas finales del producto. Es necesario, por lo tanto, contar·con herramlentas-y el esfuerzo y el tiempo al de- sarrollo Este documento presenta una des- cripción de los principales modelos utili- zados en la estimación de costo, esfuer- zo y tiempo de desarrollo, así como los parámetros y variables en que se ba- san estos modelos. El principal modelo que se trata en este documento es el Modelo CO- COMO, propuesto por Barry Boehm, puesto que, en la actualidad, es el más utilizado y referenciado. Este modelo no s610 aporta un conjunto de ecuaciones sino que, además, permite presentar razonadamente el porqué de sus resul- tados, comprobar las diferentes valo- raciones que aportan sus tablas e iden- tilicar claramente los factores de mayor influencia en el proceso de desarrollo. Ya que los modelos basan sus esti- maciones en la determinación previa del tamaño del producto, se tratará la me- todología de los Puntos de Función (PF) desarrollada por A. Albrecht, que permi- te valorar el tamaño de una aplicación, en las etapas previas de su desarrollo. OBJETIVO GENERAL Elaborar un documento sobre los di- ferentes modelos y herramientas que existen para la estimación de costo, es- fuerzo y tiempo en el desarrollo de soft- ware, el cual sirva de guía, para su apli- cación, a quienes desarrollan productos de software. OBJETIVOS ESPECIFICOS 1. Identificar los diferentes modelos existentes para la estimación de cos- tos y esfuerzos para el desarrollo de software. 2. Identificar los principales parámetros y variables utilizados por los mode- los de estimación. ",1:
-
Upload
luis-armando -
Category
Documents
-
view
216 -
download
3
description
Proyectos
Transcript of Modelos_estimacion_costo
-
~o~
't\
if:lIl11,1
ltIt~ f1;;-
:1
MODELOS DE ESTIMACION DE COSTOY ESFUERZO EN PROYECTOS DE SOFTWARE
RAFAEL ANTONIO GORDILLOALBERTO NOE GIRALDO
LUIS BALDOMERO DAVILAAlumnos del curso de Investigacin de VIII Semestre de Ingeniera de Sistemas del ICES!.
~
INTRODUCCION
En todo p~ecto de desarrollo de~oftwar~_est!:'_.incluidosfacto~ queafectanL de una u otra...torrna...eI cago_fjD.~I~tproducto,a~ como.!m!?i~I'l..IQ~requerimientos de p-~.rsonal. El factoriiellpo-tambi--ha-de ters en cuen-ta a la hora de evaluar las caractersti-cas finales del producto. Es necesario,por lo tanto, contarcon herramlentas-y
tc~i.~as~.~.p(ijj1!~Q:.~~1l.~_L~i.c~.~t~,el esfuerzo y el tiempo in~El.mlJtll$al de-sarrollo geiinpraQ'Q~~_~~.~!,:~
Este documento presenta una des-cripcin de los principales modelos utili-zados en la estimacin de costo, esfuer-zo y tiempo de desarrollo, as como losparmetros y variables en que se ba-san estos modelos.
El principal modelo que se trata eneste documento es el Modelo CO-COMO, propuesto por Barry Boehm,puesto que, en la actualidad, es el msutilizado y referenciado. Este modelo nos610 aporta un conjunto de ecuacionessino que, adems, permite presentarrazonadamente el porqu de sus resul-tados, comprobar las diferentes valo-
raciones que aportan sus tablas e iden-tilicar claramente los factores de mayorinfluencia en el proceso de desarrollo.
Ya que los modelos basan sus esti-maciones en la determinacin previa deltamao del producto, se tratar la me-todologa de los Puntos de Funcin (PF)desarrollada porA. Albrecht, que permi-te valorar el tamao de una aplicacin,en las etapas previas de su desarrollo.
OBJETIVO GENERAL
Elaborar un documento sobre los di-ferentes modelos y herramientas queexisten para la estimacin de costo, es-fuerzo y tiempo en el desarrollo de soft-ware, el cual sirva de gua, para su apli-cacin, a quienes desarrollan productosde software.
OBJETIVOS ESPECIFICOS
1. Identificar los diferentes modelosexistentes para la estimacin de cos-tos y esfuerzos para el desarrollo desoftware.
2. Identificar los principales parmetrosy variables utilizados por los mode-los de estimacin.
",1:
-
26 ~=========================ICESI:::======:=:::=:=:=========~27ICES/-
3. Determinar las condiciones bsicasque permitan realizar estimacionesms confiables.
4. Definir en qu etapas del desarrollode un proyecto de software son apli-cables las estimaciones de los mo-delos.
1. ESTIMACION EN LOSPROYECTOS DE SOFTWARE
Aunque la estimacin es ms un arteque una ciencia, es una actividad im-portante que no debe llevarse a cabode forma descuidada. Existen tcnicastiles para la estimacin de costos ytiempos. Y dado que la estimacin es labase de tod"aSlas'demSactividadesde'hlpfanificac6n y que la plnifi.9-clndel.proyecto sirve .como gua pra una b.u!rna in~geniera del software, no es ~nabsolUto a()nsejable embarcar$e.J~jn.eUa..
Un proyecto de software generalmen-te comienza con la produccin de unplan de desarrollo, donde se identificael trabajo por ser realizado, el presu-puesto y el itinerario. La efectividad dela planeacin depende de una estima-cin correcta.
Una importante faceta en el desarro-llo de software es la capacidad de esti-mar el costo asociado con las primerasetapas del ciclo de vida. La estimacinde recursos, costos e itinerarios requie-re experiencia y acceso a una buenainformacin histrica. Adems, esta es-timacin conlleva un riesgo inherente, ylos factores que lo aumentan son:
- La complejidad del proyecto: esuna medida relativa que se ve afec-tada por la familiaridad con anterio-res esfuerzos.
- El tamao del proyecto: es el fac-tor ms importante que afecta la pre-cisin y la eficacia de las estimacio-nes. A medida que crece el tamao,la interdependencia entre los distin-tos elementos del software crecerpidamente. Sin embargo, estimar
el tamao del software es un proble-ma complicado que requiere cono-cimiento especfico de las fUncionesdel sistema en trminos del entor-no, complejidad e interacciones. Lasmedidas ms frecuentes utilizadasson Lneas de Cdigo (LDC) y An-lisis de puntos de funcin (PF).
- El grado de estructuracin delproyecto: en este contexto, la es-tructuracin se refiere a la facilidadcon que las funciones pueden sermodularizadas y a la natUraleza je-rrquica de la informacin que debeser procesada. A medida que au-menta el grado de estructuracin, laposibilidad de estimar con precisinmejora y el riesgo disminuye.
La disponibilidad de informacin his-trica tambin determina el riesgo de laestimaciri. Cuando se dispone de unaamplia mtrica del software de proyec-tos pasados se pueden' hacer las esti-maciones con gran seguridad, se pue-den establecer mtodos para evitar an-teriores dificultades y se puede reducirel riesgo globaL
1.1 . Recursos humanos
Es necesario evaluar el entorno dedesarrollo y seleccionar las habilidadestcnicas que se requieren para llevar acabo el desarrollo. Hay que especificartanto la posicin dentro de la organiza-cin como la especialidad.
El nmero de personas requeridopara un proyecto de software slo pue-de ser determinado despus de haceruna estimacin del esfuerzo del desa-rrollo (por ejemplo, personas-mes o per-sonas-ao).
1.2. Categoras del hardware
Durante la planificacin del proyectode software se deben considerar trescategoras de hardware: el sistema dedesarrollo, que est compuesto por lacomputadora que se utilizar durante
-- 'i,
la fase de desarrollo del software y susperifricos asociados; la mquina ob-jetivo, que es el equipo donde se eje-cutar el software desarrollado, y losdems elementos de hardware del nue-vo sistema.
1.3. Recursos del software
Al igual que utilizamos el hardwarecomo herramienta para construir nuevohardware. utilizamos el software comoayuda en el desarrollo de nuevo soft-ware. La primera aplicacin que se ledio al software en el desarrollo de soft-ware fue lo que se denominaba recons-truccin. Se comenz por escribir unprimitivo traductor de lenguaje en-samblador a lenguaje mquina, y se uspara desarrollar un ensamblador mssofisticado. Aumentando las posibilida-des de cada versin previa, los equipostie desarrollo fueron reconstruyendoeventualmente el software, hasta llegara construir compiladores de lenguajesde alto nivel y otras herramientas.
1.4. Software reutilizable
Cualquier estudio sobre recursos desoftware no estar completo sino sec.Qnsidera la reusabilidad, esto es, lacreacin y reutilizacin de mdulosconstructivos de software. Estos mdu-los.constructivos deben ser catalogadospara una fcil referencia, estandariza-dos para una fcil aplicacin y vali-dados para una fcil integracin.
La mayora de los observadores dela industria del software estn de acuer-do en que la mejora de la productividaddel desarrollo del software y de la cali-dad de los productos minimizar el ni-vel de mantenimiento. En un mundo as,abundara el software reutilizable. losmdulos constructivos de software es-taran disponibles para la construccinde grandes programas, con un mfnlmoesfuerzo de desarrollo, partiendo "de lanada".
1.5. Formas de estimacin
La estimacin del costo y del esfuer-zo del software nunca ser una cienciaexacta. Son demasiadas las variables(humanas, tcnicas, de entorno, polti-cas)gue pueden afectar el costo finaldel software y el esfuerzo aplicado paradesarrollarlo. Sin embargo, fa estimacindel proyecto de software puede dejar deser un oscuro arte para convertirse enuna serie de pasos sistemticos queproporcionen estimaciones con un gra-do de riesgo aceptable.
Para realizar estimaciones segurasde costos y esfuerzos tenemos variasopciones posibles:
1. Dejar la estimacin para ms ade-lante (obviamente, podemos realizaruna estimacin del 100% fiable, trashaber terminado el proyecto).
2. Utilizar tcnicas de descomposicinrelativamente sencillas, para gene-rar las estimaciones de costo y es-fuerzo del proyecto.
3. Desarrollar un modelo emprico, parael clculo de costos y esfuerzos delsoftware.
4. Adquirir una o varias herramientasautomticas de estimacin.
Infortunadamente la primera opcin,aunque atractiva, no es prctica. Lasestimaciones de costos han de ser pro-porcionadas de antemano. Sin embar-go, hay que reconocer que cuanto mstiempo esperemos ms cosas sabre-mos, y cuanto ms sepamos menor ser
. la probabilidad de cometer serios erro-res en nuestras estimaciones.
Las tcnicas de descomposicin uti-lizan un enfoque de "divide y vencers",para la estimacin del proyecto de soft-ware. Mediante la descomposicin delproyecto en sus funciones principales yen las tareas de ingeniera de softwareque le corresponden, la estimacin delcosto y del esfuerzo pueden realizarsede una forma escalonada e idnea.
-
28 -=========================ICES, :::=::::==:=::::::========~/CE'i,
Igualmente, se pueden utilizar los mo-delos empricos de estimacin comocomplemento de las tcnicas de des-composicin. Cada modelo se basa enla experienC~(datoshistricos) y tomacomo base: =f(vl) donde:
d: es uno de los valores estimados(por ejemplo: esfuerzo, costo, duracindel proyecto).
VI: son determinados parmetros in-dependientes (por ejemplo: Lneas decdigo o Puntos de funcin estimados).
Las herramientas automticas deestimacin implementan una o variastcnicas de descomposicin o modelosempricos. Cuando se combinan con unainterfaz atractiva hombre-mquina, lasherramientas automticas resultan muyatractivas para la estimacin.
Cada una de las opciones viablespara la estimacin de costos y esfuerzodel software slo ser buena si 105 da-tos histricos que se utilizan como basede la estimacin son buenos. Si no exis-ten datos histricos, la estimacin delcosto descansar sobre una base muyinestable.
1.6. Parmetros y variablesutilizados en la estimacin
Las estimaciones que suelen realizar-se para el software involucran variablesy constantes, adems de datos histri-cps. Se suele utilizar el supuesto volu-men del software (lneas de cdigo-LOC), con otras entradas que caracteri-zan los factores de riesgos principalesen el desarrollo.
Debido a que las estimacionesde costo y esfuerzo para un proyectode software son demasiado comple-jas si se consideran como un solo pro-blema, se hace necesario descompo-nerlo en problemas ms pequeos.Las tcnicas de estimacin, las lineasde cdigo LDC y los puntos de fun-cin PF difieren en el nivel de detalle
que requiere la descomposicin delproblema. Los datos de LDC y PF seemplean de dos formas en el procesode estimacin: como variables de esti-macin y como mtricas de base, re-cogidas de anteriores proyectos.
Debe tenerse en cuenta que mien-tras el LOC se estima directamente, 105PF se determinan indirectamente, me-diante la estimacin del nmero de en-tradas, salidas, archivos de datos, peti-ciones e interfaces externas.
1.6.1. Lneas de cdigo (LOe)La mtrica de tamao tradicional para
est~raftO:esf~e~'y-paraml!ldir-productividad ha sido' el de las lne~de cdigo. Un gran nmero de modelosd Elsffm'don de costo ha sido propues-to muchos de los cuales estn funda-m~ntados en las lneas de cdigo (omiles de lneas de cdigo - KLDC). Ge-neralmente, los modelos de estimacinde esfuerzo se componen de dos par-tes; la primera ofrece una base de esti-macin en funcin del tamao del soft-ware y es de la forma:
E=A+B (KLDC)C---~_._-
Oonde E es el esfuerzo estimado enhombres-mes; A, B YC son constantesy KLDC es el nmero estimado en mi-les de lneas de cdigo en el sistemafinal.
En la segunda parte, se ajusta la basede estimacin para responder a la in-fluencia de factores ambientales. Entreestos factores ambientales se incluyenel uso de tcnicas, tales como el cdigoestructurado, el diseo Top-Oown, larevisin estructurada y los equipos deprogramadores especializados; la capa-cidad de personal; los requerimientos dehardware. Por ejemplo, el ModeloCOCOMO usa lneas de cdigo eleva-das a una potencia entre 1.05 y 1.20,para determinar la base de estimacin.
f "'r'IlII,
El exponente especficamente dependede la simplicidad promedio o de la com-plejidad del proyecto,
Los siguientes son ejemplos de mo-delos tpicos:
=5.2(KLDC)O.91. Modelo Wlaston-Flix
E=5.S+0.73(KLDC)'16 Modelo Bailey-Basili
E=3.2(KLDC)1.05 Modelo COCOMOBsico
E=3.0(KLDC)"2 Modelo COCOMOIntermedio
.E=2.8(KLDC)'2 Modelo COCOMOAvanzado
E=5.288(KLDCt044 Modelo Doty.
La definicin de KLDC es importantea la hora de comparar estos modelos.Algunos modelos incluyen lneas de co-mentarios y otros no. Ja definicin dequ tipo de esfuerzo se h~ es.!L~9_~
iguatmenteimportante, ya.qua.eLes1uer.-2Ose'puede asumir corno la soJa codifi-caCiri'ocomo el anlisis total (el dise:-o, la codificacin y la fase da pruebascOiijiamente). Esto nos indica que la'.comparaCin de modelos que usan cri-terios distintos; en cuanto a los mismos
. parmetros, es relativamente difcil.
Hay numerosos problemas con e~uso de .IJneas..aecdlgQ como lIoi$da-i.8l:Ma para el tamaijo !l~;>~.Erprimero consiste en.esta~!~~cmfinicin exacta de.l?q~~J~. lJOa Ioea'(f"cdigo y, a la v.f3z,9.u.!l~~.~~l!1i:.CI6n's~~~~~ta~jY.msalmente~~ctcon las lneas de cdigo es sQ.dependencia respecto d~Uenguaje uti-iiiado. No es posible comparar directa-ietej:>foyectos desarrollad.~s-~nJeD=_guajes diferel'l!~~:p6i"ejTlplo,el tiem-po por lnea para un lenguaje d~ altoivel pueaesermayor que para uno debafnfverPedeqnlo sea posiblelglartrrrmnimo de lneas de cdigo enun lenguaje de alto nivel para una fun-cin de un lenguaje de bajo nivel.
Todava se cuenta con un problemams y es el de estimar el nmero del-ne~s req~e!.!~liBta.~~rronill:.illistema, c9n!a!lQ,Q.s1oconJaIDfonll-ci9nproveniente .ele laJase de rG'I' lerimien':.cto;> o diseiio...$i los modelos para cos-t'os, basados en el tamao, son utiliza-dos, es necesario tener la capacidad depredecir el tamao del producto final tanpronto como sea posible. Es aqu don-de entra en juego la recoleccin de da-tos. Inlortunadamente la estimacin deltamao, usando las mtricas LOC, de-pende de experiencias previas con pro-yectos similares, ms especficamentede datos histricos.
UrmJo:ma Ele estimar el tamao dQj..proyecto, en lneas de cdigo LOC, con-siste en descomponer el proyecto en su.fu~nes principales y se estiman la~LOC para cada una de stas. Las esti-macones de las funciones se combinanpara producir una estimacin global delproyecto. A partir de 105
-
30 ~=========================ICESI
Funcin Optimista Probable Pesimista Esperado
Control de perifricos 2.000 2.100 2.450 2.140
1.9. Modelos empricosde estimacin
Un modelo de estimacin utiliza fr-mulasderi,idas l"!!pjricarn.rm.te p~tra_preaecrl05diiti$-gue s~JegLJi~_~~fl.l-l~neTpaso-de pJ~llficaddeLproye.ctQd.esoftWare. Los datos empricos que so-prtlmia-- mayora de los modelos seobtienen de una muestra de proyectoslimitada. Se identifican cuatro clases demodelos: mdefos:~r.taDJej=ii.~tlcos;mode1o:~-:m:ulvariabJes esbili-cos, mocielos muJtivariables'dinml-cosymodelos tericos.
Un modelo univariable esttico tomala forma:
Recurso =c1x(caracterstica estimada)c2
(donde el recurso podra ser el esfuer-zo, la duracin del proyecto, la cantidadde personal o las lneas requeridas dedocumentacin del software. las consantes c
ly c
2se deriVan de los datos
apilados de los anteriores proyectos_a caracterstica estimada puede ser laantidad de lneas del cdigo fuente, elsfuerzo (si ya est estimado) u otra
ware. En la resolucin de cada tarea delproyecto se aplica un nmero determi-nado de personas/da,personas/mes opersonas/ao. Se asocia un costo acada unidad de esfuerzo y se deriva elcosto total estimado.
Al igual que las tcnicas lOC y PF, laestimacin del esfuerzo comienza conuna delimitacin de las funciones delsoftware, obtenidas del mbito del soft-ware. Para cada funcin debe realizar-se una serie de tareas de ingeniera delsoftware, tales como anlisis de requi-sitos, diseo, implementacin y pruebas.
. Se aplican las tarifas laborales (costo/unidad de esfuerzo) a cada una de lastareas de ingeniera del software.
En el ltimo paso se calculan los cos-tos y el esfuerzo para cada funcin y sederiva el costo total del proyecto.
1.8 Estimacin del esfuerzo
La estimacin del esfuerzo es la tc-nica mas utilizada ?!_control de perifricos, para el cual se tie-ne un valor optimista de 2.000 LDC, unvalor probable de 2.100 LDC y un valorpesimista de 2.450 LOC. Aplicamos en-tonces la funcin del valor esperado yobtenemos el siguiente resultado:
Sumando verticalmente, en la colum-na del valor esperado, se establece unaestimacin de 25.060 LOC.
1.6.2. Anlisis del punto de funcin
El ~nalisi~el.Qunto.Ee funcin~mtodo de cuantificacin del ram~?_1_comPlejidad deI.i9.!!'I!~.~~-~~J.r"!J!.!lQ.O's-nmCo~._q!!~J~t!~te~ai-usuarlo. La funcin entregada no estrefacionada con el lenguaje o herramien-tas utilizadas en el desarrollo del pro-yecto. Este anl~~~~seado para_aplicacio~~..9~!!!~~~;J]o es apropIa-do p'araaplicaciones de tipo tcnico ocientfico, ya que stas tratan conalgoritmos compiejos, que los puntos defuncin no estn diseados para mane-jar.
En este mtodo se contabilizan losvarios tipos de funcin de usuarios, los
Funcin Optimista Probable Pesimista Esperado
Interfaz de usuario y facilidad de control 1.800 2.400 2.650 2.340
Anlisis geomtrico bidimensional 4.100 5.200 7.400 5.360
Anlisis geomtrico tridimensional 4.600 6.900 6.600 6.800
Control de perifricos 2.000 2.100 2.450 2.140
Mdulos de anlisis de diseo 6.600 8.500 9.800 8.400
Total 25.060
Realizamos el mismo proceso con lasdems funciones Yconstruimos una ta-bla como la siguiente:
Control de perifricos.Mdulos de anlisis de diseo.
El paso siguiente consiste en esta-blecer los valores optimista, probable ypesimista para cada una de las funcio-nes anteriores. Tomemos por ejemplo el
-
32 ~==========================ICESI : ::::::::::::::::::::::::::::-: 33ICESI
caracterstica del software. Un ejemplode este tipo de modelo es la versinbsica del modelo de costo constructi-vooCOCOMO..
/Los modelos multivariables estti-( co~ emplean los datos histricos para
btener relaciones empricas. Un mode-de esta categora toma la forma:
Recurso=clle. + c.2e2+...
onde el es la caracterstica isima delsoftware y cll + c.2 con constantes ob-tenidas para el'
{Los modelos multivariables din-micos proyectan los requisitos de recur-\..sos como una funcin del tiempo. Los
recursos se definen en una serie de pa-sos consecutivos en el tiempo, que asig-nan cierto porcentaje de esfuerzo(o deotro recurso) a cada etapa del procesode ingeniera del software. Este modeloincluye una "curva continua de utiliza-cin del recurso" como hiptesis, y apartir de ella obtiene ecuaciones quemodelizan el comportamiento del recur-so.
El modelo terico de recurso exa-mina el software desde un punto de vis-ta microscpico; es decir, las caracte-rsticas del cdigo-fuente (por ejemplo:el nmero de operadores y operandos).
2. MODELO COCOMO
Es el modelo ms completo existen-te hasta el momento y ha sido propues-to por Barry Boehm en su libro SoftwareEngineering Economics. En este libro,Boehm trata el ciclo de vida del softwaredesde una perspectiva econmica, entrminos del tiempo y el esfuerzo reque-ridos para completar cada fase del ciclode vida del software. Establece una re-lacin matemtica que permite estimarel esfuerzo y el tiempo requerido paradesarrollar un proyecto, en funcin delnmero de instrucciones-fuente desarro-lladas.
El modelo inicial, que tena un nicomodo de desarrollo, se ajust utilizandolos datos correspondientes a doce pro-yectos completos. El modelo obtenidofue evaluado contrastando sus resulta-dos frente a los obtenidos en otros 36proyectos.
Sin embargo, la aplicacin del modeloa otros proyectos, en una amplia varie-dad de entornos, indicaron que un ni-co modo de desarrollo no era suficientepara explicar las variaciones pbserva-das, lo que indujo a introducir en el mo-delo actual tres modos de desarrollo, deforma que sus predicciones pudiesenaplicarse, con un buen grado de preci-sin, en cualquier entorno de desarro-llo. .
Boehm propuso entonces una jerar-qua de modelos de estimacin para elsoftware denominada COCOMO, porConstructive COst MOdel, o ModeloConstructivo de Costo; dicha jerarquade modelos est constituida as:
Modelo bsico
Modelo intermedio
Modelo avanzado o detallado.
Para poder aplicar adecuadamenteestos modelos se deben tener en cuen-ta las siguientes consideraciones:
1. El factor principal sobre el que sbasan las estimaciones de costos esel tamao del producto, es decir, el.nmero de instrucciones-fuente en-tregadas DSI (Delivered SourceInstructions).
Este trmino incluye todas las ins-trucciones creadas por el personalasignado al proyecto, y procesadasen cdigo mquina,-~xcluyendo laslneas de comentarios.
Igualmente, deben considerarse lassentencias de Lenguaje de Controlde Trabajos (JCL), las sentencias deformatos y las declaraciones de da-tos.
.(~
II
IIri
t
Las instrucciones se definen comolneas de cdigo y, por tanto, todalnea que contenga dos o tres sen-tencias se considerar como unasoja instruccin.
2. COCOMO considera slo las fasesdel perodo de desarrollo, com-prendidas desde el comienzo de lafase de diseo del producto hastael final de la fase de integracin yprueba.
Los costos, esfuerzo y tiempo de lasotras fases (planificacin, especifica-ciones, mantenimiento, etc.) debenestimarse por separado.
3. Los costos estimados mediante estemodelo no incluyen los correspon-dientes a las actividades de forma-cin del usuario, la instalacin y lostrabajos de conversin, aunque es-tas actividades se realicen durantela etapa de desarrollo. Se cubrentodos los costos directos del pro-yecto; es decir, la gestin del proyec-to,los trabajos de documentacin ylibrera, pero se excluyen los corres-pondientes al personal del centro decmputo, las secretarias, los subal-ternos y los altos directivos que noestn directamente involucrados enel desarrollo del proyecto.
4. La unidad de esfuerzo HM (Hombre-Mes) supone un total de 152 horasde trabajo por persona, valor toma-do basndose en la experienciaprctica, que considera aspectostales como vacaciones, permisos,festivos, licencias, etc.
Para convertir las unidades HM aotras unidades empleamos las siguien-tes equivalencias:
1 HM= 152 MH (MH: hombre-hora)
1 HM = 19 MD (MD: hombre-da)
1 HM = 1 MY/12 (MY-Hombre-ao).
5. Se supone que despus de la fasede especificacin de requerimientps,
stas no cambiarn substancial-mente, aunque evidentemente estoser inevitable. En el caso que seproduzcan modificaciones significa-tivas, se estara obligado a revisarlas estimaciones anteriores.
6. El modelo avanzado del COCOMOasume que los factores que influyensobre los costos de desarrollo de-penden de la fase en que aparecen.El COCOMO bsico y el intermediono consideran los factores que afec-tan el costo, excepto para distinguirentre desarrollo y mantenimiento.
7. En los costos por fase se incluyentodos aquellos que se produzcandurante ese espacio de tiempo. Esdecir que los costos relativos a lostrabajos de actualizacin del plan deintegracin y prueba, la terminacindel plan de pruebas de aceptacin,la actualizacin de la documenta-cin, etc., se incluyen dentro de loscostos de la fase de diseo detalla-do.
8. Para convertir las estimaciones ob-tenidas de hombres-mes (HM) a uni-dades monetarias, la mejor forma esaplicar un valor medio de unidadesmonetarias, por unidad de esfuerzo,para cada una de las fases en eldesarrollo.
2.1. Modos de desarrollo
Como se mencion anteriormente,eOCOMO comprende tres modos dedesarrollo que de algn modo reflejanlas diferentes condiciones o entornos dedesarrollo, y aunque matemticamentepueden expresarse en forma similar,conducen a estimaciones diferentes;estos modos son los siguientes:
2.1.1. Modo orgnico
Este modo abarca slo los proyec-tos relativamente pequeos y sencillos;en stos trabajan pequeos equipos,con buena experiencia en otros proyec-tos relacionados con la misma organi-
-
34 ~==========================ICESI :=========================~35ICESI
Orgnico E=2.4(KLDC)105 T=2.5(E)038
Semilibre E=3.0(KLDC)1.12 T=2.5(E)o.35
Restringido E=3.6(KLDC)120 T=2.5(E)o.32
Los modelos COCOMO calculanesencialmente el costo a la entrega, quepuede ser una pequea proporcin delcosto total de la vida del software.
E=2.4(32)'05=91 hombres-mes
32.000 LDC191 HM=352LOC/HM
T=2.5 (91)38= 14 meses,
esfuerzo:
productividad:
tiempo dedesarrollo:
y el valor medio del nmero de perso-nas que, de tiempo completo, serannecesarias para desarrollar el proyectoes:
cin para mantener la informacin so-bre materias primas. Se desarrollar unaaplicacin por un equipo propio de pro-gramadores y analistas, quienes handesarrollado aplicaciones similares du-rante varios aos. Adems, es un buenejemplo de un software de modo org-nico. Un estudio inicial ha determinadoque el tamao del programa ser aproxi-madamente de 32.000 lneas de cdigo(32 KLDC). De las ecuaciones bsicasobtenemos las caractersticas del pro-yecto, que son:
PE= 91 HM14 meses = 65 FSP
FSP: Ful/-time-equivalent Personnel:personal de tiempo completo para elsoftware.
E=91 HM es el esfuerzo total en hom-bres-mes necesario en el proyecto.
T=14 meses es el tiempo de desa-rrollo, expresado en meses.
El Modelo COCOMO ofrece perfilesobtenidos de aplicar las anterioresecuaciones a proyectos de tamaoestndar. Los tamaos estndares, uti-lizados por el modelo, son los siguien- .tes:
Pequeo 2.000 lneas de cdigo
Intermedio 8.000 lneas de cdigoMedio 32.000 lneas de cdigo
Grande 128.000 lneas de cdigo.
En la siguiente tabla puede observar-se que un proyecto pequeo es esen-cialmente un trabajo de una persona,
Tiempo estimadoEsfuerzoModo
2.2. Modelo COCOMO bsico
Es un modelo univariable, esttico,que calcula el costo y el esfuerzo de unproyecto de software, exclusivamente enfuncin de su tamao, expresado en l-neas de cdigo (KLDC) estimadas. Estemodelo es apropiado para una pronta yrpida estimacin del costo del software,pero su precisin es necesariamente li-mitada, porque carece de factores queinvolucren los aspectos del hardware, lacalidad del personal, la experiencia, eluso de modernas herramientas y tcni-cas y otros tributos del proyecto que tie-nen una significativa influencia en loscostos del software.,
La siguiente tabla presenta lasecuaciones para los tres modos de de-sarrollo del modelo COCOMO bsico:
La ecuacin E=2.4(KLDC)1.05 es utili-zada para la estimacin de hombres-mes (HM) requeridos para desarrollar eltipo ms comn de productos de soft-ware, en trminos de miles de instruc-ciones-fuente entregadas KLDC.
Se obtiene tambin que T=2.5(HM)o.38 es una ecuacin para estimarel tiempo de desarrollo, en meses.
Estas ecuaciones son aplicables a lamayora de los proyectos de software,de tamao mediano/pequeo, desarro- .liados en un ambiente de software fami-liar. Ejemplo:
Du Bridge Chemical lnc. es una im-portante compaa de productos qumi-cos, que planea desarrollar una aplica-
tos del sistema que se pretende de-sarrollar, pero no en todos.
Un tpico proyecto, en modo se-milibre, puede ser un sistema de proce-so de transacciones con pocas in-terfaces rigurosas (por ejemplo con laterminal hardware) y algunas otrasinterfaces muy flexibles (naturaleza yformatos de presentacin de mensajes).El trmino semilibre hace referencia ala flexibilidad parcial que presenta unproyecto de este tipo, el cual general-mente sobrepasa las 300 KLDC.
2.1 .3. Modo restringido
La principal caracterstica de un pro-yecto, en este modo, es la necesidadde operar dentro de fuertes restriccio-nes. El trmino incorporado se refierebsicamente al hecho que el productodebe operar dentro de un complejo ,al-tamente interconectado de hardware,software, reglas y procedimientosoperacionales, como es el caso, porejemplo, de un sistema de control de tr-fico areo.
En condiciones de modo de desarro-llo restringido, el costo de modificar par-te del complejo sistema es tan alto, quesus caractersticas se podran conside-rar inmodificables. Como resultado, estemodo de proyecto no siempre tiene laopcin de realizar fcilmente cambios desoftware, por ms sencillos que sean,debido a la modificacin de los requeri-mientos y la especificacin de lasinterfaces. Por lo tanto, el proyecto debeemplear ms esfuerzo en realizar y ade-cuar los cambios y correcciones, y enasegurar que el software actualmentesatisfaga las especificaciones. Tambinse debe emplear ms esfuerzo en veri-ficar que los cambios se realicen correc-tamente.
Los proyectos, en este modo, gene-ralmente abarcan reas ms amplias ymenos conocidas que en los casos an-teriores.
2.1.2. Modo semilibre
Representa un estado intermedioentre el modo orgnico y el modo res-tringido. Son proyectos intermedios entamao y complejidad en los que equi-pos de trabajo, con variados niveles deexperiencia, deben satisfacer requisitospoco o medio rgidos.
Con respecto a la experiencia delequipo de trabajo, se consideran las si-guientes situaciones:
Todos los miembros del equipo tie-nen un nivel intermedio de experien-cia en sistemas relacionados con elproyeCto.
El equipo de desarrollo est forma-do por una mezcla de gente expertae inexperta.
Los miembros del equipo tienen ex-periencia en algunos de los aspec-
zacin y con pleno conocimiento decmo el sistema en desarrollo contribuircon los objetivos de la organizacin.
Esto significa que la mayora de laspersonas pueden contribuir de formaefectiva a la terminacin puntual de cadauna de las etapas, sin necesidad demucha comunicacin, para determinarcon precisin las tareas que cada unodebe desarrollar en el proyecto. Existe,por lo tanto, facilidad para establecer losrequisitos y las especificaciones de cadauna de las fases del proyecto.
Otros factores catactersticos de estemodo son:
- Un ambiente generalmente establede desarrollo, con muy poca ocurren-cia de nuevo hardware y procedi-mientos operacionales.
- Mnima necesidad para innovar ar-quitectura de procesamiento de da-tos o algoritmos.
- Muy pocos proyectos, en este modo,han desarrollado productos con msde cincuenta KLDC.
-
Tamao Esfuerzo (HM) Productividad (lnealHM) T1empo(meses) PE
Pequeo 2KlDC 5.0 400 4.6 1.1
Intermedio 8 KlDC 21.3 376 8.0 2.7
Medio 32 KlDC 91.0 352 14.0 6.5
Grande 132 KlDC 392.0 327 24.0 16.0
mientras que un proyecto consideradogrande requiere un nivel medio de 16personas. Cabe anotar que para un pro-yecto pequeo el esfuerzo estimado de5 HM hace referencia al desarrollo de
2.000 instrucciones del producto, inclu-yendo, por lo tanto, el esfuerzo de do-cumentacin, las pruebas, las correccio-nes, etc.
Distribucin del esfuerzo estimado (%). Modo semlllbre
FASE TAMAO (KLDC)
Pequeo Interm. Medio Grande Muy grande
(2) (8) (32) (128) (512)
Planificacin y especificaciones 7 7 7 7 7Diseo del producto 17 17 17 17 17Programacin 64 61 58 55 52Diseo detallado 27 26 25 24 23Codificacin ypruebas de unidades 37 35 33 31 29Integracin y pruebas 19 22 25 28 31
Distribucin del esfuerzo estimado ('Yo). Modo restringido
Fase Tamao (KLDC)
Pequeo Interm. Medio Grande Muy grande(2) (8) (32) (128) (512)
Planificacin y especificaciones 8 8 8 8 8Diseo del producto 18 18 18 18 18
Programacin 60 57 54 51 48Diseo detallado 28 27 26 25 24
Codificacin y prueba de unidades 32 30 28 26 24
Integracin y pruebas 22 25 28 31 34
Obviamente, el tiempo para desarrollarun programa, por ejemplo de 2000 ins-trucciones para uso personal, ser me-nor, ya que ste no requerir de muchasexigencias, mientras que si el mismo sedesarrolla como un producto profesio-nal, entonces requerir un poco ms detiempo y esfuerzo.
2.2.1. Distribucin del esfuerzoy tiempos por fases
Es de esperar qiJe las estimacionespara cada una de las fases del proyectodifieran considerablemente de un modode desarrollo a otro. La distribucin porfases vara en funcin del tamao; losproyectos de gran tamao precisan
mayor tiempo y esfuerzo para desarro-llar actividades, tales como la integra-cin y la prueba, mientras que puedenreducir el tiempo durante la fase de pro-gramacin, distribuyendo esta actividadentre un nmero mayor de programa-dores. Los pequeos proyectos presen-tan una distribucin ms uniforme y tie-nen que dedicar, relativamente, ms re-cursos a las fases de diseo y progra-macin que a las de prueba e integra-cin.
Las siguientes tres tablas presentanlos porcentajes de distribucin del es-fuerzo de desarrollo, entre las distintasfases, en los tres modos de desarrollo. Las siguientes tres tablas presentan los
porcentajes de tiempo de desarrollo,para cada una de las fases, en los tresmodos de desarrollo.
Distribucin del esfuerzo estimado (%). Modo orgnico
FASE TAMAO (KLDC)
Pequeo Interm. Medio Grande Muy grande(2) (8) (32) (128) (512)
Planificacin y especificaciones 6 6 6 6 -
Diseo del producto 16 16 16 16 -
Programacin 68 65 62 59 -
Diseo detallado 26 25 24 23 -Codificacin y prueba de unidades 42 40 38 36 -
Integracin y pruebas 16 19 22 25 -
~ES:/~========================:
Distribucin del tiempo (%). Modo orgnico
Fase Tamao (KLDC)
Pequeo Interm. Medio Grande Muy grande
(2) (8) (32) (128) (512)
Planificacin y especificaciones 10 11 12 13 -Diseo del producto 19 19 19 19 -Programacin 63 59 55 51 -Integracin ypruebas 18 22 26 30 -
:=========:::::::==========~ 37ICESI
-
Productividad (LDC/HM)
Distribucin del tiempo (%). Modo semlllbre
Fase Tamao (KLDC)
Pequeo Interm. Medio Grande Muy grande(2) (8) (32) (128) (512)
Planificacin y especificaciones 16 18 20 22 24
Diseo del producto 24 25 26 27 28
Programacin 56 52 48 44 40
Integracin y pruebas 20 23 26 29 32
Distribucin del tiempo (%). Modo restringido
Fase Tamao (KLDC)
Pequeo Interm. Medio Grande Muy grande(2) (8) (32) (128) (512)
Planificacin yespecificaciones 24 28 32 36 40
Diseo del producto 30 32 34 36 38
Programacin 48 44 40 36 32
Integracin ypruebas 22 24 26 28 30
Conceptos
Esfuerzo(HM)
Tiempo(Meses)
Personal8.0Equiv.(Pe)
Fases
Planificacin y requisitosDiseo del productoProgramacinDiseo detalladoCodificacin ypruebade unidades .Integracin y pruebas
Esfuerzo total
(Planificacin y requisitosDiseo del productoProgramacinIntegracin ypruebas
Tiempo total estimado
Planificacin y requisitos
Diseo del productoProgramacin1ntegracin ypruebas
Pequeo Intermedio Medio Grande
(2 KLDC) (8 KLDC) (32 KLDC) (128 KLDC)
0.3 1.3 5 240.8 3.4 15 633.4 13.8 56 2311.3 5.3 22 902.1 8.5 34 141
0.8 4.1 20 98
5.0 21.3 91 392
0.5 0.9 1.7 3.10.9 1.5 2.7 4.62.9 4.7 7.7 12.20.8 1.8 3.6 7.2
4.6 8.0 14 24
0.6 1.4 2.9
0.9 2.3 5.6 141.2 2.9 7.3 191.0 2.3 5.6 14
400 376 352 327
38 ~=========================ICESI
Esfuerzo (HM) Pequeo Intermedio Medio Grande Muy grande(2 KLDC) (8 KLDC) (32 KLDC) (128 KLDC) (512 KLDC)
Orgnico 5.0 21.3 91 392
Semilibre 6.5 31 146 687 3.250
Restringido 8.3 44 230 1.216 6.420
Productividad (KLDCIHM) Pequeo Intermedio Medio Grande Muy grande(2 KLDC) (8 KLDC) (32 KLDC) (128 KLDC) (512 KLDC)
Orgnico 400 376 352 327
Semilibre 308 258 219 186 158
Restringido 241 182 139 105 80
;bE~
Pero cmo usar estas tablas?Retomando el ejemplo anterior, vamosa calcular el esfuerzo y el tiempo duran-te la fase de programacin. Recordemosque en este proyecto se consideran 32KLDC estimadas; por lo tanto, de acuer-do con la tabla para el esfuerzo en elmodo orgnico, tenemos que el porcen-taje para el esfuerzo estimado, en pro-gramacin para 32 KLDC, es del 62%;entonces:
Eprog=(O.62)(E)
Eprog=(O.62)(91 HM)=56 HM
De la misma manera, el porcentajede tiempo destinado a la fase de pro-gramacin, para 32 KLDC, en el modoorgnico, es del 55%; por lo tanto:
Tprog=(O.55)(T)
Tprog=(O.55)(14 meses)=7.7 meses
El nivel medio de personal equivalen-te sera de:
Pe=(56 HM)/(717 meses)=7.3 hombres.
Un proceso similar se puede realizarcon las otras tablas, para los otros mo-dos de desarrollo, de acuerdo con el ta-mao estimado del producto cuandoste se ajusta a los tamaos estnda-res.
La siguiente tabla muestra los valo-res nominales obtenidos de aplicar losporcentajes de las tablas de esfuerzo ytiempo de desarrollo, en el modo org-nico, a los proyectos de tamao es-tndar. Adems, se muestran los valo-res relativos a la productividad del pro-yecto y el personal medio equivalentenecesario en cada fase.
De igual manera, aplicando 105 porcen-tajes y ecuaciones adecuados para losmodos semilibre y restringidos, obte-nemos tablas similares a la anteriorpara proyectos de tamao estndar.
A continuacin se presenta una tabla
donde se totalizan los valores de es-fuerzo, tiempo, productividad y perso-nal equivalente, para todos los modosde desarrollo, en proyectos de tama-o estndar. Por lo tanto, no se discri-mina por fases.
-
Distribucin del esfuerzo por actividades. Modo restringido
Ttempo (meses) Pequeo Intermedio Medio Grande Muy grande(2 KLDC) (8 KLDC) (32 KLDC) (128 KLDC) (512 KLDC)
Orgnico 4.6 8.0 14 24Semilibre 4.8 8.3 14 24 42
Restringido 4.9 8.4 14 24 41
Personal equivalente -PE Pequeo Intermedio Medio Grande Muy grande(Hombres) (2 KLDC) (8 KLDC) (32 KLDC) (128 KLDC) (512 KLDC)
Orgnico 1.1 2.7 6.5 16Semilibre 1.4 3.7 10 29 77
Restringido 1.7 5.2 16 51 157
FASEPlanificacin y Diseo del Programacin Integracin Desarrollo
requisitos producto y prueba
'Tamao PIMGMG PIMGMG PIMGMG PIMGMG PI MG MG
('Yo) fase completa 8 8 8 8 8 18181818 18 60 57 54 5148 22 252831 34
ACTIVIDAD
Anlisis de requisitos 50 48 46 44 42 10 10101010 33333 2 222 2 4 4 4 4 4
Diseo del producto 12 13 14 15 16 42 424242 42 66666 4 4 4 4 4 12 1212 1212
Programacin 2 4 6 810 10 11121314 55 55 55 55 55 3236l44 48 42 43 43 4445
Plan de pruebas 2 3 4 5 6 4 5 678 45678 3 344 5 4 4 5 6 7
Verificacin yvalidacin 6 7 8 910 6 7 8 910 8 910 11 12 30 28 25 23 20 12 1314 1414
Oficina de proyectos 16 14 12 10 8 15 1311 9 7 9 8 7 6 5 10 9 8 7 6 10 9 8 7 6
GC'CC 5 4 4 4 3 4 3 3 3 2 87776 10 9 9 9 8 8 7 7 7 6
MarJJales 7 7 6 5 5 9 9 8 5 5 77655 9 9 8 7 7 8 8 7 7 6
2.2.2. Distribucin del esfuerzopor actividades
Por ltimo, una vez determinada ladistribucin del esfuerzo entre las fasesprincipales del ciclo de vida de un pro-ducto software, es necesario conocercmo se distribuye entre las diferentesactividades, de forma que sirva de refp-rencia para:
- preparar planes de distribucin delos recursos y
- adecuar la estructura de la organi-zacin al tamao de los equipos de-dicados a cada una de las activida-des que, en proyectos de gran ta-mao, ser necesario modificar amedida que avanza el proyecto, enfuncin de los cambios de activida-nes y segn la fase en que se en-cuentre el proyecto.
Las siguientes tablas muestran la dis-tribucin por actividades, dentro de cadauna de las fases principales.
Distribucin del esfuerzo por actividades. Modo orgnico
FASEPlaniflC8cin Diseo del Programacin Integracin Desarrolloyrequisitos producto yprueb
Tamao P I MG P r M G P I M G PI M G P I M G(%) Fase completa 6 16 69 65 62 25 16 19 22 25
ACTIVIDAD
Anlisis de requisitos 46 15 5 3 6
Diseo del producto 20 40 10 6 14
Programacin 3 14 58 34 48474645
Plan de pruebas 3 5 4 2 4
Verificacin yvalidacin 6 6 6 34 10111213
Oficina de proyectos 15 11 6 7 7
GClCC 2 2 6 7 7
Manuales 5 7 5 7 7
Distribucin del esfuerzo por actividades. Modo semllibre
FAse
Planificacin y Diseo del Programacinrequisitos producto
Tamao P I M G MG P I M G MG P I M G MG(%) Fase completa 7 7 7 7 7 17 t7 17 17 17 64 61 58 51 52
ACTIVIDAD
Anlisis de requisitos 48 47 46 45 44 12.5 12.5 12.5 12.5 12.5 4 4 4 4 4
Diseo del producto 16 16.5 17 17.5 18 41 41 41 41 41 8 B 8 B B
Programacin 2.5 3.5 4.5 5.5 6.5 12 12.5 13 13.5 14 56.5 56.5 56.5 56.5 56.5
Plan de pruebas 2.5 3 3.5 4 4.5 4.5 5 5.5 6 6.5 4 4.5 5 5.5 6
Verificacin yvalidacin 6 6.5 7 7.5 8 6 6.5 7 7.5 B 7 7.5 B a5 9
Oficina de proyectos 15.514.5 13.5 12.5 11.5 13 12 11 10 9 7.5 7 6.5 6 5.5
GCICC 3.5 3 3 3 2.5 3 2.5 2.5 2.5 2 7 6.5 6.5 6.5 6
Manuales 6 6 5.5 5 5 8 8 7.5 7 7 6 6 5.5 5 5
~ES:/~========================: :=========================~. 41ICESI
-
Distribucin del esfuerzo por actividades. Modo semilibre(Continuacin)
42 .,.==========================ICESI
FASE
Integraciny pruebas Desarrollo
Tamao P I M G GM P I M G MG(0/0) Fase completa 19 22 25 28 31
ACTIVIDAD
Anlisis de requis~os 2.5 2.5 2.5 2.5 2.5 5 5 5 5 5
Diseo del producto 5 5 5 5 5 13 13 13 13 13Programacin 33 33 37 39 41 45 45 44.5 44.5 44.5
Plan de pruebas 2.5 2.5 3 3 3.5 4 4 4.5 5 5.5Verificacin y validacin 32 31 29.5 28.5 27 11 12 13 13.5 14
Oficina de proyectos 8.5 8 7.5 7 6.5 8.5 8 7.5 7 6.5
GC/CC 8.5 8 8 8 7.5 6.5 6 6 6 5.5
Manuales 8 8 7.5 7 7 7 7 6.6 6 6
:=========================~'CE':,
Modo de desarrollo Ecuacin nominal de esfuerzo
Orgnico Enom
=3.2(KLDC)'05
Semilibre Enom
=3.0(KLDC)1.12
Restringido Enom=2.8(KSDI)1.2
El modelo intermedio presenta unatabla de multiplicadores de esfuerzo,donde cada atributo conductor de costotiene asociado un conjunto de multipli-cadores. Estos, a su vez, estn relacio-nados con un conjunto de clasificacio-nes de proyectos.
- Atributos del personal:Capacidad de anlisisExperiencia en aplicacionesCapacidad de los programadoresExperiencia en el sistema operativoutilizadoExperiencia con el lenguaje de pro-gramacin
- Atributos del proyecto:
Aplicacin de mtodosde ingeniera del software
Utilizacin de herramientasde software
Restriccin del tiempode desarrollo.
Cada uno de estos atributos tieneasociado un factor multiplicativo, el cualestima el efecto del atributo en el es-fuerzo del desarrollo del software; estefactor se denomina multpllcador deesfuerzo. Estos multiplicadores se apli-can a un estimativo-base del esfuerzo,para obtener un estimativo refinado(ajustado) del esfuerzo del desarrollo.Este modelo inicia la estimacin, con lageneracin de un estimativo nominal obsico del esfuerzo, usando funcionesescalares similares a las del modelobsico. Este estimativo nominal es, en-tonces, ajustado, aplicando los multipli-cadores de esfuerzo, derivados de laclasificacin del proyecto respecto delos 15 atributos del costo.
La siguiente tabla presenta lasecuaciones del esfuerzo nominal, paralos tres modos de desarrollo, utilizadosen el COCOMO, intermedio.
Eprog=(O.644){E)Eprog=(O.644)(35)=22.5 HM
2.3. Modelo COCOMO intennedioEn este modelo se calcula el esfuer-
zo de desarrollo de software en funcindel tamao del programa y de un con-junto de atributos conductores del cos-to, que incluyen la evaluacin subjetivadel producto, del hardware, del perso-nal y de los atributos del proyecto.
El COCOMO intermedio es una ver-sin ampliada del COCOMO bsico,pues presenta un mayor nivel de detalley de seguridad, pero conservando lamisma sencillez.
Los atributos conductores de costosson 15 factores, compuestos por cuatrocategoras y que no se tienen en cuentaen el modelo bsico. Dichos atributosson:
- Atributos del producto:
Confiabilidad requerida del software.
Tamao de la base de datos.Complejidad del producto.
- Atributos del hardware:
Restricciones de tiempode ejecucin.Restricciones de memoria.Volatilidad de mquina virtualTiempo de respuesta del equipo
Pe=22.5HM/5.6 meses=4.01 hombres
De la misma forma podemos obtenerel porcentaje de tiempo de programa-cin, interpolando los porcentajes detiempo, del 59% para 8 KLDC y del 55%para 32 KLDC.
y.=59+12.8-8(55-59)=58.232=8
Entonces, el tiempo en la fase de pro-gramacin corresponde al 58.2% deltiempo total, es decir:
Tprog=(O.582){9.7 meses)=5.6 meses
El valor medio de personal, equiva-lente en la fase de programacin, serde:
y=65+ 12.8-8 (62-65)=64.432-8
El porcentaje de esfuerzo, para eltamao no estndar, es del 64.4% y, porlo tanto, el esfuerzo dedicado, en la fasede programacin, ser:
y=yo+[x~-~~o) (y1-yo)
donde: y es el porcentaje que se de-sea calcular
x es el tamao del proyecto enKLDC
yo y y1 corresponden al 65%y 62%, respectivamente.
xo y x1 corresponden a 8 KLDCy 32 KLDC, respectivamente.
total de nuestro proyecto estar com-prendido entre el 65% del proyecto de8 KLDC y el 62% del proyecto de32 KLDC.
El porcentaje buscado, empleandointerpolacin lineal, ser:
2.2.3. Proyectos de tamao noestndar (InterpolacI6n)
En el caso que el tamao estimadodel producto no se ajuste a los tamaosestndares, podemos obtener el perfildel proyecto por interpolacin de losdatos de los proyectos estndares detamao inferior y superior.
Por ejemplo, supongamos que de-seamos obtener el esfuerzo de desarro-llo en la fase de programacin de unproducto de software, cuyo tamao fija-
o mos en 12.800 Ifneas fuente en el modoorgnico.
Aplicando las ecuaciones de estima-cin del esfuerzo total y el tiempo dedesarrollo, tenemos:
Esfuerzo total E=2.4(12.8),05=35 HM
Tiempo de desarrollo T=2.5(35)38=9.7 meses
Para obtener el esfuerzo en la fasede programacin, tenemos que referir-nos a los proyectos de 8 KLDC y 32KLDC. El porcentaje sobre el esfuerzo
-
VALORAtributos Muy bajo Bajo Nomil\lll Alto Muy alto Extra altoAtributos del prodcto
Confiabilidad del software requerida 0.75 0.88 1.0 1.15 1.40 -Tamallo de la base de datos - 0.94 1.0 1.08 1.16 -Comple;dad del producto 0.70 0.85 1.0 1.15 1.30 1.65Atributos del hardware
Restricciones de tiempo de ejecucin - - 1.0 1.11 1.30 1.66Restricciones de memoria - - 1.0 1.06 1.21 1.56Volatilidad de la mquina virtual - 0.87 1.0 1.15 1.30 -Tiempo de respuesta del equipo - 0.87 1.0 1.07 1.15 -Atributos del personal
Capacidad de anlisis 1.46 1.19 1.0 0.86 0.71 -ExperienCia en aplicadones 1.29 1.13 1.0 0.91 0.82 -Capacidad de programadores 1.42 1.17 1.0 0.86 0.70 -Experienda en el S.O. utilizado 1.21 1.10 1.0 0.90 - -Experiencia con e/lenguaje 1.14 1.07 1.0 0.95 - -Atribu10s del proyecto
Aplicadn de la ingeniera del software 1.24 1.10 1.0 0.91 0.82 -Utilizacin de herramientas del software 1.24 1.10 1.0 0.91 0.83 -Restricdn del tiempo de desarrollo 1.23 1.08 1.0 1.04 1.10 -
E=(Enom)(Factor multiplicativo)
E=(146 HM)(1.40)=204 hombres-mes
dad, puesto que su impacto operacionales generalmente a largo plazo y muchasfallas podran ocasionar prdidas paralos usuarios, fcilmente recuperables.Estas caractersticas le dan un peso, enla tabla mencionada, de 0.88 (bajo) paraun ajuste de:
E=(Enom)(Factor multiplicativo)E=(146 HM)(0.88)-128 hombres-mes
Pero si el sistema por desarrollar es,por ejemplo, un sistema de control dereactor nuclear, podra tener un muy altorequerimiento de confiabilidad. Aqu elefecto de fallas del software podra pro-vocar la prdida de vidas humanas; porlo tanto, tiene un factor multiplicativomayor que el anterior. La estimacin delesfuerzo ser, de acuerdo con el nivelde confiabilidad 1.40 (muy alto), la si-guiente:
Como ayuda para seleccionar el fac-tor aplicable en cada caso, la siguientetabla establece los criterios que sirvenpara elegir el factor adecuado.
Por ejemplo. si consideramos el de-sarrollo de una aplicacin del modosemilibre, con 32 KLDC, que presentadiferentes requerimientos de confiabili-dad debido a la naturaleza de su am-biente de trabajo, el esfuerzo nominalse calcular as:
Enom=3.0(32)1.12=146 hombres-mes.
Indica un esfuerzo total de 146 hom-bres-mes que son requeridos para de-sarrollar un producto de 32 KLDC, enmodo semilibre, independiente de cual-quier consideracin de los requerimien-tos de confiabilidad.
A partir de aqu, los ajustes en el es-timativo final deben hacerse de acuer-do con el tipo de producto final. Porejemplo. si el sistema por desarrollar esun modelo de prediccin del clima, po-dra tener un relativo nivel bajo de cali-
:::::=====================~I~CE~
I
~
tti
e
~5loz
'"~i1!~'"._ CI)E 15.Si
:E:S~'==========================
-
Por lo tanto, para ajustar la estima-cin del esfuerzo usamos la siguienteecuacin, empleando los factoresmultiplicativos:
E=(KLDC)S 1t1 5j=1 FJ
Donde S es el exponente correspon-diente al modo de desarrollo y F el fac-tor multiplicativo.
Veamos ahora un ejemplo sobrecmo aplicar los factores multiplicativosen el modelo de COCOMO intermedio.Supongamos que estamos negociandocon la compaa Megabit Comunicacio-nes el precio de desarrollar un productode software para el procesamiento defunciones de comunicacin, en unmicroprocesador comercial, cuyo tama-o se estima en 10 KLDC y se desarro-lla en modo restringido. De acuerdo con
la ecuacin nominal del esfuerzo paraeste modo, obtenemos el siguiente es-fuerzo nominal:
2.8(10)12=44 HM
Deseamos ahora determinar el efec-to de varias caractersticas del pro-yecto, en el esfuerzo y costo de desa-rrollo. Por ejemplo, el software para elprocesamiento de comunicaciones ge-neralmente tiene una valoracin muyalta, en la escala de complejidad, perose planea usar personal analista y pro-gramador con alta capacidad, lo cualbalancea la tendencia a incrementar loscostos, debido a la complejidad. El cos-to del personal ser de $6.000 por mes.
En la siguiente tabla tenemos las ca-ractersticas presentes para el desarro-llo del producto:
I!
Atributo Situacin ClasificacinMultiplicadorde esfuerzo
Capacidad Programadores Alta 0.86de programadores con experiencia
Experiencia en el 6 meses Baja 1.10s.a. utilizadoExperiencia 12 meses Nominal 1.00con el lenguaje
Aplicacin de la Muchas tcnicas Alta 0.91ingeniera del por ms desoftware un ao
Utilizacin Herramientas Baja 1.10de herramientasdel sotfware
Restriccin del 9 meses Nominal 1.00tiempo de desarrollo
Factor de esfuerzo ajustado (producto de multiplicadores de esfuerzo) 1.17
:::::::=::::=====:=========:~ 47ICESf
Atributo Situacin Clasificacin Multiplicadorde esfuerzo
Confiabilidad del software Uso local del sistema Nominal 1.00requerida No hay problemas serios
de recuperacin
Tamao de la base de datos 20.000 bytes Baja 0.94
Complejidad del producto Procesamiento Muy alta 1.30de comunicaciones
Restricciones de tiempo Se usar el 70% del Alta 1.11de ejecucin tiempo disponible
Restricciones de memoria 45K de 64K disponible Alta 1.06
Volatilidad Basado en Nominal 1.00de la mquina virtual microprocesador
comercial
Tiempo de respuesta 2 horas Nominal 1.00del equipo promedio
Capacidad de anlisis Analistas Alto 0.86con experiencia
Experiencia 3 aos Nominal 1.00en aplicaciones
~ES:':-:=========================:
Ntese que el factor de ajuste se in-crementa en 1.30, debido a la compleji-dad muy alta, pero ms adelante se re-duce el valor a 0.86, debido a la alta ca-pacidad de analistas y programadores.El factor de ajuste final, de 1.17, repre-senta un incremento del 17% en el es-fuerzo nominal; entonces, el costo y elesfuerzo estimados finalmente son:
Esfuerzo: (44 HM)(1.17)=51 HM
Costo: (51 HM)($6.000/HM)=$306.000
2.3.1. Anlisis de sensibilidad
El modelo COCOMO intermedio per-mite realizar un anlisis de sensibilidadcon respecto a los atributos directoresdel costo, logrando as estimar el efectosobre el costo de desarrollo, debido alos cambios en los niveles de clasifica-cin de los atributos.
Por ejemplo, supongamos que tene-mos la opcin de realizar el proyecto delejercicio anterior con personal de me-
nor capacidad y menos costoso. Paraeste caso, el costo por persona-mespodra ser de $5.000 en lugar de los$6.000 anteriores, y la capacidad deanlisis y programacin la podramosclasificar como Nominal. De acuerdo conla tabla anterior, este nivel de capaci-dad del personal resulta en un factormultiplicador de 1.00, en lugar del 0.86obtenido anteriormente. Esto significaque el estimativo de COCOMO debe serajustado de acuerdo con las considera-ciones anteriores:
Nuevo factor de ajustede esfuerzo =1.58
Esfuerzo=(44 HM)(1.58)=70 HM
Costo: (70 HM)($5.000/HM)=$350.000
Segn lo anterior podemos notar queresulta ms ventajoso usar personal demayor capacidad, segn el anlisis rea-lizado con el factor de ajuste del esfuer-zo, porque el estimativo de costo esmenor.
-
~ES:/~=======================: :::::::===:==::==:::::::::::~ 49ICESI
40%
30%
30%
Veamos otro ejemplo para el factorde ajuste de restriccin del almacena-miento. Supongamos que por $10.000,Megabit podra comprar 96K palabrasde memoria para el microprocesador porusar, en lugar de usar 64K. Esto podracambiar las restricciones del almacena-miento principal del 70% al 47%. El re-sultado en el multiplicador del esfuerzosera de 1.00, que corresponde a unaclasificacin Nominal, en lugar de 1.06(alta), que era el anterior caso. Con loanterior se tiene que:
Factor de ajuste del esfuerzo=1.1 O
Esfuerzo=(44 HM)(1.10)=48HM
Costo=(48 MM)($6.000/HM)=$288.000
Lo anterior nos indica que se lograun ahorro de $18.000, lo cual compen-sa la inversin de $10.000 en costos dehardware. Adems, al negociar con lacompaa Megabit, se puede proponeresta opcin como forma para reducir elcosto del software.
2.3.2. Estimacin de los efectosde software reutilizable
Hasta ahora todas las estimacionesse haban basado en el supuesto que latotalidad del producto estaba siendoespecificado, diseado y desarrolladopor completo, sin considerar que algu-no de sus componentes hubieran sido
. desarrollados para otros proyectos pre-viamente y que pudiesen utilizarse di-rectamente o por adaptacin en el nue-vo producto.
Obviamente, las lneas-fuente de unprograma adaptado no pueden tener lamisma consideracin que la del nuevosoftware, para efectos de la estimacin.Por ejemplo, supongamos que utiliza-mos, como parte de nuestro nuevo pro-ducto, una rutina simple de entrada/sa-lida, que ya forma parte de la librera deutilidades de otros proyectos, con lo cualse incrementa el nmero de IIneas-fuen-
te de nuestro nuevo producto, pero a lavez no incrementa la cantidad de esfuer-zo requerido para el desarrollo del nue-vo producto.
Por otra parte, en muchas ocasionesno se necesita adaptar completamenteun paquete, sino que slo se precisarealizar un esfuerzo adicional, pa-ra redisear el software adaptado, paraajustarlo a los objetivos del nuevo pro-ducto, el cual consiste en rehacer algu-nas porciones para acomodarlas a loscambios del entamo del nuevo produc-to.
Los efectos de la adaptacin de pro-ductos existentes son tratados por elModelo COCOMO, a travs del clculodel nmero equivalente de instruccionesfuente-lE, que se emplean en sustitu-cin de las lneas de cdigo-fuente LDC.
El nmero de lneas lE de un produc-to adaptado se calcula a partir de la esti-macin de las siguientes cantidades:
Nmero de lneas-fuente adaptadasal nuevo producto, lA.
Porcentaje de rediseo del software. MD. Es el porcentaje de diseo del
software que ha sido modificadopara adaptarlo al nuevo entamo. Ne-cesariamente sta es una estima-cin subjetiva.
Porcentaje de cdigo modificado. Esaqul que es modificado con el finde adaptarlo al nuevo entamo.
Porcentaje del esfuerzo de integra-cin del software adaptado MI. Es elporcentaje de esfuerzo requeridopara integrar el software adaptadoal nuevo producto, el cual se obtie-ne por comparacin con el esfuerzode integracin necesario para unproducto de tamao similar.
El total de lneas equivalentes se cal-cula a travs de un factor de adaptacindefinido como FA:
FA=0.40 MD+0.30MC+0.30MI
,~.
A partir del cual el nmero de lneasequivalentes vendra dado por:
IE=IA*FA Uneas equivalentes.
Este valor puede aadirse a las esti-maciones de nuestro producto y tratar-las como hemos estado haciendo hastaahora, de forma que el tamao final delproducto ser:
LDC.-=LDC+IE.
Como ejemplo, supongamos quedeseamos convertir un programa deanlisis de circuitos, escrito en FOR-TRAN, de 50.000 Ifneas, desarrollado enmodo orgnico desde un entorno hard-ware-software determinado en otro di-ferente.
Para esta situacin podramos con-siderar que:
MD=O (es decir, no hay cambios en eldiseo del programa).
MC=15 (posiblemente el 15% de las l-neas de cdigo deban cambiarse paraadaptarlo a las caractersticas propiasdel nuevo sistema operativo, del lengua-je de control, etc.)..
MI=5 (se precisa una pequea cantidadde esfuerzo para integrar estos cam-bios).
Los resultados de la adaptacin seran:
FA=0.40(0)+0.30(15)+0.30(5)=6
y parlo tanto, el nmero de lneas equi-valentes sera:
IE=50.000 LDC0.06=3.000 lneas equi-valentes.
Utilizando las estimaciones del mo-delo bsico, se obtiene un esfuerzo deadaptacin de:
E=2.4(3)1.05=7.6 HM
Los coeficientes de la ecuacin delfactor de adaptacin se determinan apartir del valor medio de los porcentajesdedicados a las tareas de diseo, cadi-
ficacin e integracin y pruebas dadaspor el modelo:
Diseo:
Codificacin:
Integracin y prueba:
Para estimar el tiempo de desarrollose emplean las mismas ecuaciones uti-lizadas en el Modelo COCOMO bsico.
En cuanto a la distribucin del esfuer-zo por fase, el modelo intermedio utilizalas mismas tablas empleadas en el mo-delo bsico.
Los multiplicadores de esfuerzo, eneste modelo, pueden aplicarse a la fasede mantenimiento, del mismo modo quese realizan en la fase de desarrollo.
2.4. Modelo COCOMO detallado
Este modelo incorpora todas las ca-ractersticas del modelo intermedio y lle-va a cabo una evaluacin del impactode los atributos conductores del costo,en cada fase del proceso de la ingenie-ra del software.
El modelo intermedio es altamenteefectivo para muchos propsitos de es-timacin del software. Sin embargo, tie-ne dos Iimitantes principales que pue-den ser significativas en estimacionesde costo ms detalladas para proyec-tos extensos:
La estimacin distribuida de esfuer-zo, por fases, puede ser inexacta.
Puede ser muy engorroso para usar-lo en productos con muchos compo-nentes.
El madelo detallado provee dos prin-cipales facultades que consignan lasIimltantes del modelo intermedio.
- Multiplicadores de esfuerzo de fasesensitiva: en la R!'"ctica, factores ta-les como confiablli d, experienciay desarrollo interactivo ectan a al-gunas fases mucho ms otras.El modelo detallado ofrece u"",con-
-
50 ~=========================ICES; :==========================~51ICESI
junto de multiplicadores de esfue~zo, de fase sensitiva, para cada atrI-buto del costo. Estos son usadospara determinar la cantidad de es-fuerzo requerido para completarcada fase.
Los multiplicadores se usan de acuer-do con la precisin que refleje el efectode los conductores de costo, en la dis-tribucin de fase del esfuerzo. Por ejem-plo, un nivel bajo en experiencia de apli-caciones puede significar esfuerzo adi-cional en las primeras fases. En las lti-mas fases el equipo podr familiarizar-se con la aplicacin y, as, no se reque-rir mucho esfuerzo adicional.
De otra parte, un tiempo de respues-ta alto en el computador tendr muypoco efecto en las fases de diseo yrequerimientos, pero ciertamente con-sumir ms tiempo del equipo durantela codificacin y las pruebas.
- Jerarqua de producto de tres nive-les: en el modelo intermedio la clasi- .ficacin separada de los conducto-res de costo puede ser suministra-da por diferentes componentes delproducto. Este proceso puede sertedioso e innecesariamente re-petitivo si un nmero de componen-tes se agrupa en un subsistema, conprcticamente todas las mismas cla-sificaciones. El modelo detalladoexcluye este problema, ofreciendo lajerarqua de producto de tres nive-les, para lo cual:
_ Algunos efectos, que tienden a va-riar con cada mdulo de nivel inter-no, son' tratados en el nivel de m-dulo.
_ Algunos efectos, que varan menosfrecuentemente, son atados en elnivel de subsistema.
- Algunos efectos, tales como el efec-to de tamao total del producto, sontratados en el nivel del sistema.
La jerarqua mdulo-subsistema-sis-tema se da por la descomposicin je-rrquica del producto, del cual se va aestimar el costo.
El nivel ms bajo, el nivel de mdulo,se describe por el nmero de lneas decdigo-fuente en el mdulo, y por aque-llos atributos de costo que tienden avariar al ms mnimo nivel. Por ejem-plo, la complejidad del mdulo y suadaptacin al software existente; la ca-pacidad de los programadores y la ex-periencia en el manejo del lenguaje enel que se desarrolla el software.
El segundo nivel, nivel de sub-sistema, se caracteriza por el resto delos conductores de costo (tiempo, con-diciones de almacenamiento, capacidadde analistas, herramientas, etc.), loscuales tienden a variar de un subsistemaa otro, por lo cual tiende a ser lo mismopara tocios los mdulos del subsistema.
El nivel ms alto, el nivel del siste-ma, se usa para aplicar las principalesrelaciones del proyecto, tales como lasecuaciones de esfuerzo y tiempo, y paraaplicar, durante las interrupciones, en elesfuerzo y 105 tiempos del proyecto.
3. METODOS DE LOS PUNTOSDE FUNCIONLa mtrica de 105 puntos de funcin
~rmit~~aritmcar una,ap~c~~.~~- .sndose en aosreaSde evaJ"uaclon:Lapriira consiste' ' El cicJTf~,~~ji:tosdeiC,-simples.LSgunda reaonssle'e-justar el 'model, el1 flJ.6::cin de la complejidaq y~el aml?l~r!tl3~,de desarrollo de la aplicacin., ..._
L~'fi~alidad de esta metodologa es,en primer lugar, estimar el tamao deun producto de software en las etapasprevias de su desarrollo y, por otra par-te, estimar el esfuerio de desarrollo,expresado en este caso en horas tra-bajadas. 'por el punto de funcin desa-
rrollado. Un ~:: ~~cin es unamtrica .w..e-i "dad-deL...._""'y_., ..~,.,-
roducto de trabajo, tales comofuerzo e esarro o y o mantenimientodelSoftware. Una componente of~.e.l!..'!'lQr:QQeso nico o reQperimiento dedatos de la aplicacin por ejemplo l/Dal2flotalla donde se adicionan datos o '10_~.QQrte impre&o
En este mtodo se evala la fun-cionabilidad de una aplicacin en trmi-nos de qu se le entrega al usuario enla aplicacin y no cmo se le entrega.Unicamente los componentes visibles ylos requerimientos del usuario son con-tabilizados. Estos componentes son tra-tados como Tipos de Funcin, los cua-les estn divididos en Datos y Transac-ciones:
Tipos de Funcin Datos: ArchivosLgicos Internos (AL!) yArchivos Exter-nos de Interface (AEI).
TIpos de Funcin Transacciones:Funciones de Entrada (Entradas Exter-nas), Funciones de Salida (Salidas Ex-ternas), Consultas Externas (CE).
Los objetivos principales de estametodologa son:
Medir lo que el usuario requiere y loque se le entrega.
Medir la aplicacin, independiente-mente de la tecnologa usada para laimplementacin.
Proveer una mtrica de tamao quesoporte anlisis de calidad y productivi-dad.
Proveer un vehculo para la estima-cin del software.
Este ltimo aspecto es el que se tra-ta en este documento.
3.1. Tipos de funcin
Los puntos de funcin sin ajuste tra-tan exclusivamente del conteo de lasfunciones del usuario y se realiza trasuna previa clasificacin de las funciones,basndose en aquellos componentes deuna aplicacin que son requeridos y sonvisibles al usuario.
3.1.1. Archivo Lgico 1n1ecrJ.":~~I2l
