ASIGNATURA:

ESTIMACION DE PROYECTOS SW
(Master en TI)

ALUMNOS:
SANTIAGO GALLEGO Expediente: 522
CESAR GONZALES Matrcula:350
RICARDO INSIO BRAVO Expediente: A00494
JOSE MIGUEL ALONSO Matrcula: A00369
EJERCICIO:
METODOLOGIA AGILE COCOMO II
PROFESOR:
ANA. M MORENO
Enero 2010

1(32)

NDICE
1

Introduccin........................................................................................................

2
2.1
2.2

Metodologas Agiles...........................................................................................
Historia.................................................................................................................
Valorar ms a los individuos y su interaccin que a los procesos y
las herramientas...................................................................................................
Valorar ms el software que funciona que la documentacin
exhaustiva............................................................................................................
Valorar ms la colaboracin con el cliente que la negociacin
contractual............................................................................................................
Valorar ms la respuesta al cambio que el seguimiento de un plan
.............................................................................................................................

2.3
2.4
2.5
3
3.1
3.2
3.3
3.4
3.5
3.6

Descripcin de Algunas metodologas Agiles.................................................

Programacin Extrema (Extreme Programming, XP)...........................................
SCRUM5..............................................................................................................
Crystal Methodologies..........................................................................................
Dynamic Systems Development Method (DSDM)................................................
Adaptive Software Development (ASD)................................................................
Feature -Driven Development (FDD)....................................................................

4
4.1
4.2
4.3
4.3.1
4.3.2
4.3.3
4.3.4
4.3.5
4.3.6

Desarrollo Incremental de la aplicacin para la empresa

PCGeek................................................................................................................
Modelo de desarrollo incremental.........................................................................
Modelo de Desarrollo iterativo..............................................................................
Desarrollo Incremental de la Aplicacin PCGeek..................................................
Primera Fase........................................................................................................
Segunda Fase......................................................................................................
Tercera Fase.......................................................................................................
Cuarta Fase........................................................................................................
Quinta Fase........................................................................................................
Sexta Fase.........................................................................................................

5
5.1

AGILE COCOMO II............................................................................................

COCOMO II........................................................................................................

6
6.1
6.2
6.3
6.4
6.5
6.6
6.7

Los parmetros de analoga de AGILE COCOMO II.......................................

Parmetro: Costo total en dlares......................................................................
Parmetro: Esfuerzo total en persona-meses.....................................................
Parmetro: Productividad en dlares / puntos de funcin...................................
Parmetro: Productividad en dlares / lneas de cdigo.....................................
Productividad en puntos de funcin / persona-meses........................................
Productividad en lneas de cdigo / persona-meses...........................................
Velocidad del proyecto en total de ideal-persona-semanas /
iteracin..............................................................................................................

Estimacin de PCGeek usando Agile COCOMO II.........................................

Conclusiones....................................................................................................

Referencias.......................................................................................................

2(32)

1 Introduccin

El objetivo de este ejercicio es realizar el estudio terico de la Metodologa de

Estimacin SW Agile COCOMO II y su aplicacin a travs de un caso prctico sobre el
cual ya hemos trabajado utilizando la metodologa de Puntos de Funcin (Tcnica de
Albrecht).
Pretendemos analizar las diferencias entre ambas Metodologas desde el Punto de
Vista terico y analizar los resultados a los que llegamos para el mismo caso prctico
usando la metodologa Agile COCOMO II y la Metodologa de Puntos de Funcin.
El caso prctico que vamos a utilizar es el de la problemtica de la empresa
PCGeek, de acuerdo al anterior ejercicio realizado por el grupo. El anlisis final nos
debe proporcionar los resultados de Estimacin de SW a los que llegamos con ambos
mtodos de Estimacin para el mismo caso prctico.
Agile COCOMO II es una metodologa de Estimacin SW con aplicabilidad en aquellos
casos en los que utilizamos Metodologa de Desarrollo incremental e iterativa.
En base a esto, una de las cuestiones a realizar es el anlisis del desarrollo de la
aplicacin SW que proporcionaba respuesta al caso PCGeek, siguiendo una
metodologa de Desarrollo incremental. Por lo tanto, en uno de los apartados de esta
memoria se realizar una aproximacin de desarrollo incremental de la aplicacin SW
que daba respuesta a la problemtica de PCGeek.

2 Metodologas Agiles
Se entiende como desarrollo gil de software a un paradigma de desarrollo de
software basado en procesos giles. Los procesos giles de desarrollo de software,
conocidos anteriormente como metodologas livianas, intentan evitar los tortuosos y
burocrticos caminos de las metodologas tradicionales.
Es un marco de trabajo conceptual de la ingeniera de software que promueve
iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen
muchos mtodos de desarrollo gil; la mayora minimiza riesgos desarrollando
software en cortos lapsos de tiempo. El software desarrollado en una unidad de tiempo
es llamado una iteracin. Cada iteracin del ciclo de vida incluye: planificacin, anlisis
de requerimientos, diseo, codificacin, revisin y documentacin. Una iteracin no
debe agregar demasiada funcionalidad debiendo tener un prototipo al final de cada
iteracin. Al final de cada iteracin el equipo vuelve a evaluar las prioridades del
proyecto.

3(32)

Los mtodos giles enfatizan la comunicacin personal entre los agentes del proyecto
en vez de la documentacin. Combinado con la preferencia por las comunicaciones
personales cara a cara, generalmente los mtodos giles son criticados y tratados
como "indisciplinados" por la falta de documentacin tcnica.
Frente a la tcnica Agile COCOMO, utilizamos en la anterior prctica la tcnica de
Puntos de Funcin, la cual mide el software cualificando la funcionalidad que
proporciona externamente, basndose en el diseo lgico del sistema.

2.1

Historia

La definicin moderna de desarrollo gil de software evolucion a mediados de los

aos 1990, como parte de una reaccin contra los mtodos de "peso pesado", muy
estructurados y estrictos, extrados del modelo de desarrollo en cascada. El proceso
originado del uso del modelo en cascada era visto como burocrtico, lento, degradante
e inconsistente con las formas de desarrollo de software que realmente realizaban un
trabajo eficiente.
Los mtodos de desarrollo giles e iterativos pueden ser vistos como un retroceso a
las prcticas de desarrollo observadas en los primeros aos del desarrollo de software.
Inicialmente, los mtodos giles fueron llamados mtodos de "peso liviano".
Las prcticas giles estn especialmente indicadas para productos difciles de definir
con detalle en el principio, o que si se definieran as tendran al final menos valor que
si se van enriqueciendo con retro-informacin continua durante el desarrollo. Tambin
para los casos en los que los requisitos van a ser muy inestables por la velocidad del
entorno de negocio.
En el ao 2001, miembros prominentes de la comunidad se reunieron y adoptaron el
nombre de "metodologas giles" y formaron la Alianza gil para promover el
desarrollo gil de aplicaciones. Los integrantes de la reunin resumieron los principios
sobre los que se basan los mtodos alternativos en cuatro postulados, lo que ha
quedado denominado como Manifiesto gil.
En el Manifiesto gil se valora:
A los individuos y su interaccin, por encima de los procesos y las
herramientas.
El software que funciona, por encima de la documentacin exhaustiva.
La colaboracin con el cliente, por encima de la negociacin contractual.
La respuesta al cambio, por encima del seguimiento de un plan.
Algunos mtodos similares al gil son: Scrum (1986), Crystal Clear (cristal
transparente), programacin extrema o XP (1996) Adaptive SW Development.

2.2

Valorar ms a los individuos y su interaccin que a los procesos

y las herramientas

Este es posiblemente el principio ms importante del manifiesto. Por supuesto que los
procesos ayudan al trabajo. Son una gua de operacin. Las herramientas mejoran la
eficiencia, pero sin personas con conocimiento tcnico y actitud adecuada, no
producen resultados.

4(32)

La gente es el principal factor de xito de un proyecto software. Es ms importante

construir un buen equipo que construir el entorno. Los procesos deben ser una ayuda
y un soporte para guiar el trabajo. Deben adaptarse a la organizacin, a los equipos y
a las personas; y no al revs.

2.3

Valorar ms el software que funciona que la documentacin

exhaustiva

La regla a seguir es no producir documentos a menos que sean necesarios de

forma inmediata para tomar un decisin importante.. Estos documentos deben
ser cortos y centrarse en lo fundamental.

Los documentos no pueden sustituir, ni pueden ofrecer la riqueza y generacin de

valor que se logra con la comunicacin directa entre las personas y a travs de la
interaccin con los prototipos. Por eso, siempre que sea posible debe preferirse, y
reducir al mnimo indispensable el uso de documentacin.

2.4

Valorar ms la colaboracin con el cliente que la negociacin

contractual

En el desarrollo gil el cliente es un miembro ms del equipo, que se integra y

colabora en el grupo de trabajo. Se propone que exista una interaccin constante entre
el cliente y el equipo de desarrollo. Esta colaboracin entre ambos ser la que marque
la marcha del proyecto y asegure su xito.

2.5

Valorar ms la respuesta al cambio que el seguimiento de un

plan

La habilidad de responder a los cambios que puedan surgir a los largo del proyecto
(cambios en los requisitos, en la tecnologa, en el equipo, etc.) determina tambin el
xito o fracaso del mismo. Por lo tanto, la planificacin no debe ser estricta sino
flexible y abierta.
Para un modelo de desarrollo que surge de entornos inestables, que tienen como
factor inherente al cambio y la evolucin rpida y continua, resulta mucho ms valiosa
la capacidad de respuesta que la de seguimiento y aseguramiento de planes preestablecidos. Los principales valores de la gestin gil son la anticipacin y la
adaptacin; diferentes a los de la gestin de proyectos ortodoxa: planificacin y control
para evitar desviaciones sobre el plan.

5(32)

3
3.1

Descripcin de Algunas metodologas Agiles

Programacin Extrema (Extreme Programming, XP)

XP4 es una metodologa gil centrada en potenciar las relaciones interpersonales

como clave para el xito en desarrollo de software, promoviendo el trabajo en equipo,
preocupndose por el aprendizaje de los desarrolladores, y propiciando un buen clima
de trabajo. XP se basa en realimentacin continua entre el cliente y el equipo de
desarrollo, comunicacin fluida entre todos los participantes, simplicidad en las
soluciones implementadas y voluntad para afrontar los cambios. XP se define como
especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes,
y donde existe un alto riesgo tcnico.

3.2

SCRUM5

Desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle. Define un marco para
la gestin de proyectos, que se ha utilizado con xito durante los ltimos 10 aos. Est
especialmente indicada para proyectos con un rpido cambio de requisitos. Sus
principales caractersticas se pueden resumir en dos. El desarrollo de software se
realiza mediante iteraciones, denominadas sprints, con una duracin de 30 das,
siendo el resultado de cada sprint un incremento ejecutable que se muestra al cliente.
La segunda caracterstica importante son las reuniones a lo largo proyecto, entre ellas
destaca la reunin diaria de 15 minutos del equipo de desarrollo para coordinacin e
integracin.

3.3

Crystal Methodologies

Se trata de un conjunto de metodologas para el desarrollo de software caracterizadas

por estar centradas en las personas que componen el equipo y la reduccin al mximo
del nmero de artefactos producidos. Han sido desarrolladas por Alistair Cockburn. El
desarrollo de software se considera un juego cooperativo de invencin y
comunicacin, limitado por los recursos a utilizar. El equipo de desarrollo es un factor
clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas,
as como tener polticas de trabajo en equipo definidas. Estas polticas dependern del
tamao del equipo, establecindose una clasificacin por colores, por ejemplo Crystal
Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros).

3.4

Dynamic Systems Development Method (DSDM)

Define el marco para desarrollar un proceso de produccin de software. Nace en 1994

con el objetivo de crear una metodologa RAD unificada. Sus principales
caractersticas son: es un proceso iterativo e incremental y el equipo de desarrollo y el
usuario trabajan juntos. Propone cinco fases: estudio viabilidad, estudio del negocio,
modelado funcional, diseo y construccin, y finalmente implementacin. Las tres
ltimas son iterativas, adems de existir realimentacin a todas las fases.

6(32)

3.5

Adaptive Software Development (ASD)

Su impulsor es Jim Highsmith. Sus principales caractersticas son: iterativo, orientado

a los componentes software ms que a las tareas y tolerante a los cambios. El ciclo de
vida que propone tiene tres fases esenciales: especulacin, colaboracin y
aprendizaje. En la primera de ellas se inicia el proyecto y se planifican las
caractersticas del software; en la segunda desarrollan las caractersticas y finalmente
en la tercera se revisa su calidad, y se entrega al cliente. La revisin de los
componentes sirve para aprender de los errores y volver a iniciar el ciclo de desarrollo.

3.6

Feature -Driven Development (FDD)

Define un proceso iterativo que consta de 5 pasos. Las iteraciones son cortas (hasta 2
semanas). Se centra en las fases de diseo e implementacin del sistema partiendo
de una lista de caractersticas que debe reunir el software. Sus impulsores son Jeff De
Luca y Peter Coad.

Metodologas Agiles

Metodologas Tradicionales

Basadas en heursticas provenientes

de prcticas de produccin de
cdigo

Basadas en normas provenientes de

estndares seguidos por el entorno
de desarrollo

Especialmente preparados para

cambios durante el proyecto
Impuestas internamente (por el
equipo) Impuestas externamente

Cierta resistencia a los cambios

Proceso menos controlado, con
pocos principios Proceso mucho ms
controlado, con numerosas
polticas/normas

No existe contrato tradicional o al

menos es bastante flexible

Existe un contrato prefijado

El cliente es parte del equipo de

desarrollo

El cliente interacta con el

equipo de desarrollo mediante
reuniones

Grupos pequeos (<10 integrantes) Grupos grandes y posiblemente

y trabajando en el mismo sitio
distribuidos
Pocos roles
Menos nfasis en la arquitectura del
software

Ms roles
La arquitectura del software es
esencial y se expresa mediante
modelos

7(32)

Tabla 1.Diferencias entre metodologas giles y no giles

4 Desarrollo Incremental de la aplicacin para la empresa PCGeek

Como hemos mencionado anteriormente Agile COCOMO II es una metodologa de

Estimacin SW con aplicabilidad en aquellos casos en los que utilizamos Metodologa
de Desarrollo incremental e iterativa.
En este apartado realizamos un breve anlisis de diseo Incremental que proporciona
respuesta al caso PCGeek, siguiendo una metodologa de Desarrollo iterativa.

4.1

Modelo de desarrollo incremental

El modelo de desarrollo incremental implica la produccin y entrega de SW en

paquetes de entregas incrementales, en vez de en un solo paquete.
En el modelo incremental, el sistema a desarrollar y especificado en los documentos
de requerimientos es dividido en subsistemas, que se desarrollan en ciclos diferentes.
Cada ciclo puede ser desarrollado de acuerdo a otros modelos de Desarrollo SW,
siendo lo ms comn que sigan el modelo de desarrollo de waterfall. El desarrollo del
sistema comienza con un pequeo subsistema funcional, el cual debe ser
completamente desarrollado. En cada ciclo un subsistema funcional es desarrollado y
una nueva versin es entregada al usuario al final de dicho ciclo.
En este modelo, el desarrollo de SW comienza con las ms importantes
funcionalidades y contina y finaliza con las menos importantes. El sistema total es
construido gradualmente a travs de diversas iteraciones, por lo que en cada iteracin
cada subsistema es sometido a las fases de requerimientos, diseo, implementacin y
testing.
Las dos principales ventajas de esta aproximacin son: la entrega en breve tiempo de
ciertas funcionalidades y el compromiso e implicacin del cliente en el sistema. Este
tipo de desarrollo implica que debe existir una comprensin de los requerimientos
desde el principio y simplemente elegir la implementacin en subconjuntos
incrementales de funcionalidad.
Otra ventaja importante es que el riesgo de desarrollos errneos se reduce al dividir el
proyecto en diversas series de pequeos subproyectos.
Un riesgo al afrontar los desarrollos de SW siguiendo este modelo es que en las
primeras entregas pueden cubrir un nmero limitado de requerimientos que produzcan
cierta decepcin en el cliente. Por otro lado, en el supuesto de que haya habido malentendidos en la interpretacin de los requerimientos, estos desarrollos pueden ser
corregidos en breve.

8(32)

4.2

Modelo de Desarrollo iterativo

Este modelo de desarrollo tambin divide el sistema en pequeas partes, como

sucede en el desarrollo incremental. Sin embargo, en vez de construir y entregar un
nuevo y completo subsistema en cada ciclo, el modelo de desarrollo iterativo
construye y entrega en cada ciclo un sistema con todos los subsistemas parcialmente
desarrollados, siendo las funcionalidades de cada subsistema mejoradas en cada
nuevo ciclo. Al final de cada ciclo una nueva versin mejorada del sistema completo es
entregada al usuario.
Este modelo tiene como propsito reducir el riesgo de disconformidades entre las
necesidades del usuario y el producto final, consiguindose al final de cada iteracin
una versin mejorada del producto SW que es entregado al usuario

4.3

Desarrollo Incremental de la Aplicacin PCGeek

El desarrollo de la aplicacin PCGeek, la realizamos en sucesiones incrementales de

acuerdo a los requerimientos totales establecidos por el cliente.
Estos Desarrollos incrementales los realizaremos partiendo de fases de funcionalidad
sencilla, sobre las cuales iremos aadiendo funcionalidad hasta completar con todos
los requerimientos del cliente.
Como se estudi en el anterior ejercicio, la problemtica que afronta PCGeek aborda
problemtica en la Gestin del almacn, en la Gestin de Compras (Gestin
proveedores) y en la Gestin de Ventas (Gestin de Pedidos Clientes).
En el desarrollo final, vamos a tener el mismo nmero de Ficheros Internos que se
consideraron utilizando la tcnica de Puntos de funcin (Ficheros Lgicos Internos).
Estos ficheros lgicos sern: Componentes, PCs, Almacn, Proveedores, clientes,
Pedidos Clientes, Detalles Pedidos Clientes, Pedidos Proveedores, Detalles Pedidos
Proveedores.
El desarrollo incremental lo vamos a realizar en un total de 6 fases.
4.3.1

Primera Fase.

En esta primera fase vamos a desarrollar las actividades relacionadas con los Ficheros
de Proveedores y Ficheros de clientes. Estas actividades proporcionarn al usuario
funcionalidad par realizar el Alta de Proveedores, Baja de proveedores, Modificacin
de Proveedores y en relacin a clientes: Alta de Clientes, Baja de Clientes y
modificacin de clientes.

4.3.2

Segunda Fase

9(32)

En la segunda fase nos enfocaremos en las actividades relacionadas con la Gestin

del Almacn y Gestin de los Componentes. Por lo tanto, estaremos trabajando con
dos ficheros principales que son Almacn y Componentes para poder proporcionar al
usuario funcionalidad relativa al alta de componentes, Baja de componentes y
Modificacin de componentes.
4.3.3

Tercera Fase

En esta tercera fase nos enfocaremos en trabajar con todas las cuestiones
relacionadas con la Gestin de Compras y Gestin de Proveedores. Trabajaremos
con tres tipos de ficheros que sern Pedidos Proveedores, Detalle Pedidos
Proveedores y Proveedores, proporcionando funcionalidad para poder realizar el Alta
de Pedidos de Proveedores, Baja de Pedidos de Proveedores y modificacin de
Pedidos de Proveedores.
4.3.4

Cuarta Fase

En la cuarta fase el principal enfoque ser en las cuestiones relacionadas con la

Gestin de Ventas y Gestin de Clientes. Trabajaremos con tres tipos de ficheros que
sern Pedidos Clientes, Detalle Pedidos Clientes y Clientes, proporcionando
funcionalidad para poder realizar el Alta de Pedidos de Clientes, Baja de Pedidos de
Clientes y modificacin de Pedidos de Clientes.
4.3.5

Quinta Fase

En la quinta fase el principal enfoque ser toda la gestin relacionada con el Montaje y
Fabricacin de los PCs. Para ello tendremos que trabajar con tres tipos de ficheros
que sern Componentes, PCs y Almacn, proporcionando informacin y funcionalidad
relativa al las existencias de PCs y de componentes que hay en el almacn segn el
proceso de fabricacin y Montaje avanza. Esta funcionalidad es quizs de las ms
complicadas, no slo por el nmero de ficheros con el que trabajaremos, sino tambin
por la cantidad de informacin de cada fichero extrada.
4.3.6

Sexta Fase

En la sexta fase los desarrollos proporcionarn funcionalidad relacionada con la

Gestin del Envo de Pedidos, lo que implica que habr que trabajar con el mayor
nmero de ficheros, siendo estos, los ficheros de componentes, Almacn, PCs y
Pedidos de Clientes. Esta ltima fase proporcionar informacin y funcionalidad
relativa a qu pedido de cliente pertenece cada componente y cada PC que existe en
el Almacn. Como sucede con el mdulo anterior, est es la parte ms complicada de
la aplicacin por la cantidad de informacin a la que hay que acceder.

10(32)

5 AGILE COCOMO II
Agile COCOMO II incorpora todos los parmetros de COCOMO y usa una estimacin
basadas en analogas para generar resultados ptimos y lo ms exacto posible para
un nuevo proyecto. Su analoga se basa en proyectos similares terminados es decir
yesterdays weather approach to predict what the weather would be like today y
algunos cambios en los parmetros de COCOMO, siendo muy fcil de usar y
aprender.
La primera versin de AgileCOCOMO II fue desarrollado en 2002 por los estudiantes
Cyrus Fakharzadeh y Gunjan Sharman bajo la supervisin del Dr. Barry Boehm cuyo
objetivo fue mejorar algunos puntos en el uso de COCOMOII:

El uso de COCOMO II requiere la manipulacin de todos sus parmetros (22)

Tiene una alta curvatura de aprendizaje
La estimacin en s se podra complicar demasiado y por ende podra abarcar
demasiado tiempo.

11(32)

El principal objetivo de Agile COCOMO II es proveer a los managers de proyectos un

mecanismo simple para estimaciones de esfuerzo y costos rpidos, exactos y fiables
que:

Sean entendibles por s mismos

Que requieran el mnimo de entradas
Que aproveche las experiencias del pasado con proyectos similares para
controlar sus diferencias.
Que aproveche la confiabilidad y exactitud que provee el modelo COCOMO II

El manejo de AgileCOCOMO II es bastante simple y solamente requiere 3 pasos

bsicos para generar una estimacin:
1. Seleccionar un analogy parameter e indicar un baseline value para este
parmetro.
2. Seleccionar un cost driver and/or scale factor para diferenciar nuevos
proyectos con los antiguos proyectos
3. Proveer valores para cada cost driver and/or scale factor seleccionado en
el paso 2
Para un mejor entendimiento detallaremos cada terminologa mencionada en cada
paso de la estimacin

Analogy Parameter: Es la base de similitud entre un proyecto previo y un

nuevo proyecto. Sus opciones son
o Total Cost in Dollars
o Total Effort in Person-Months
o Productivity in Dollars / Function Point
o Productivity in Dollars / Lines of Code
o Productivity in Function Points / Person-Months
o Productivity in Lines of Code / Person-Month
o Project Velocity in Total Ideal-Person-Weeks / Iteration

Baseline Value: Es el valor de un analogy parameter especifico para el

proyecto. Por ejemplo: 5 Function Points/Person-Month, 1000 Dollars, 800
Person-Month, etc

Cost Driver/Scale Factor: Es el Cost Driver y/o Scale Factor de COCOMO II

que ha cambiado entre el nuevo proyecto con el antiguo proyecto. Obviamente
pueden cambiar uno o varios cost driver/scale factors.

Como hemos visto hasta el momento Agile COCOMO II realiza una estimacin con
aproximacin iterativa, es decir por ciclo.
Por cada ciclo debemos seguir los 3 pasos indicados anteriormente es decir:
1. Seleccionar un analogy parameter e indicar un baseline value para este
parmetro.
2. Seleccionar un cost driver and/or scale factor para diferenciar nuevos
proyectos con los antiguos proyectos
3. Proveer valores para cada cost driver and/or scale factor seleccionado en
el paso 2

12(32)

Al final de cada ciclo, podramos seleccionar cualquiera de las siguientes acciones:

5.1

Ver el reporte.
Cambiar un cost driver/scale factor independiente del anterior.
Cambiar un cost driver/scale factor segn los resultados del anterior.
Regresar a una estimacin inicial (Reset Project)
Estimar otro proyecto

COCOMO II

COCOMO II fue desarrollado para que sea compatible con el futuro mercado del
software, permitiendo ajustar las entradas y salidas de los submodelos de COCOMO II
dependiendo de la informacin disponible para realizar la estimacin, cada submodelo
est enfocada a las estrategias de procesos particulares de cada proyecto, teniendo
en cuenta las necesidades de cada sector. Estos submodelos ofrecen mayor fidelidad
a medida que uno avanza en la planificacin del proyecto y en el proceso del diseo,
estos submodelos son:

Modelo de Composicin de Aplicaciones: Para proyectos construidos con

herramientas modernas de interfaces grficos para usuario.
Modelo de Diseo Temprano: Para proyectos donde aun no este determinada
por completo su arquitectura. Esta basada en Puntos de Funcin si ajustar o
KSLOC (Miles de lneas de cdigo fuente)
Modelo Post-Arquitectura: Modelo mas completo, para proyectos donde ya
se tenga la arquitectura del proyecto, tiene nuevos drivers de costes, recuento
de lneas y nuevas ecuaciones.

La estructura de COCOMO II se basa en estos 3 modelos que asumen que se

progresa a lo largo de un desarrollo de tipo espiral para consolidar los requisitos y la
arquitectura, reduciendo el riesgo.
COCOMO II utiliza variables establecidas en funcin de una medida de 5 factores de
escala:
PREC Precedencia
FLEX Flexibilidad de desarrollo
RESL Resolucin de Arquitectura / Riesgos
TEAM Cohesin de equipo
PMAT Madurez del proceso
Para realizar las estimaciones COCOMO II utiliza como medida puntos de objeto,
puntos de funcin o lneas de cdigo, basndose en el diseo lgico del sistema.
COCOMO II posee 17 drivers de costes, cada uno de los cuales debe ser estimado:

RELY Fiabilidad
DATA Tamao de la Base de Datos
CPLX Complejidad
RUSE Reutilizacin requerida
DOCU Documentacin

13(32)

TIME Restriccin tiempo de ejecucin

STOR Restriccin de almacenamiento principal
PVOL Volatilidad plataforma
ACAP Capacidad del analista
PCAP Capacidad del programador
AEXP Experiencia de aplicaciones
PEXP Experiencia plataforma
LTEX Experiencia del lenguaje y herramienta
PCON Continuidad del personal
TOOL Uso de herramientas software
SITE Desarrollo Multi-lugar
SCED Planificacin requerida

Una caracteriza importante a destacar es su modelo de reutilizacin y caractersticas

de auto calibracin.
Como vemos en sus parmetros de configuracin muchos de ellos son subjetivos, por
lo tanto la exactitud de la estimacin depende en gran medida de la experiencia de la
persona que lo realiza, adems es muy importante la cantidad de proyectos anteriores
(con caractersticas similares al nuevo proyecto) porque nos ayudara a obtener datos
ms precisos y partir de una base.

6 Los parmetros de analoga de AGILE COCOMO II

Son la base de similitud entre un proyecto previo y uno nuevo. AGILE COCOMO II
considera los siguientes parmetros anlogos:

Costo total en dlares

Esfuerzo total en persona-meses
Productividad en dlares / puntos de funcin
Productividad en dlares / lneas de cdigo
Productividad en puntos de funcin / persona-meses
Productividad en lneas de cdigo / persona-meses
Velocidad del proyecto en total de ideal-persona-semanas / iteracin

Pero es necesario identificar los factores que cambiaran y cuanto. Esto determinara
los resultados de la estimacin de los costos o la estimacin del esfuerzo del nuevo
proyecto.
Lnea Base
Ser el valor de un especfico parmetro de analoga del proyecto anterior que sirve de
entrada para el clculo de AGILE COCOMO II. La obtencin de la lnea base difiere en
cada parmetro de analoga. A continuacin se describe con ejemplos el uso de los
parmetros de analoga.
Aplicacin de los parmetros de analoga
Para obtener la lnea base de algunos parmetros es necesaria un clculo donde
puede intervenir la cantidad de puntos de funcin o la cantidad de lneas de cdigo,

14(32)

valores obtenidos del proyecto anterior. Consideramos para este ejemplo los
siguientes valores:
Parmetros proyecto anterior
Puntos de funcin
Lneas de cdigo

Valor
160
6032

Lneas base a partir de los parmetros de analoga

Entonces las lneas base para estimar nuestro actual proyecto sern las siguientes:
Parmetros de analoga
Costo total en dlares

Lnea
base
90000

Razonamiento

Es el total de dinero gastado en el proyecto

anterior.
Esfuerzo total en persona- 17,9
Es el resultado de la estimacin del esfuerzo
meses
del proyecto anterior.
Productividad en dlares / $562,50 Para obtener este parmetro se tiene que
puntos de funcin
dividir el costo total del proyecto anterior entre
la cantidad de puntos de funcin del mismo.
En este ejemplo si tenemos el costo del
proyecto= 90,000 dlares y el numero de
puntos de funcin=160 obtenemos una lnea
base de 562.5 dlares / puntos de funcin.
Productividad en dlares / $14,92
lneas de cdigo

Para obtener este parmetro se tiene que

dividir el costo total del proyecto anterior entre
la cantidad de lneas de cdigo del mismo. En
este ejemplo si tenemos el costo del
proyecto= 90,000 dlares y el numero de
lneas de cdigo=6032 obtenemos una lnea
base de 14.92 dlares / lneas de cdigo.

Productividad en puntos de 8,93

funcin / persona-meses

Para obtener este parmetro es necesario

dividir la cantidad de Puntos de funcin del
proyecto anterior entre el esfuerzo en
persona-meses de este proyecto. Por ejemplo
para 160 puntos de funcin entre 17.9
persona-meses de esfuerzo obtenemos 8.93
puntos de funcin / persona-meses

Productividad en lneas de 336,98

cdigo / persona-meses

Para obtener este parmetro es necesario

dividir la cantidad de lneas de cdigo del
proyecto anterior entre el esfuerzo en
persona-meses de este proyecto. Por ejemplo
para 6032 lneas de cdigo entre 17.9
persona-meses de esfuerzo obtenemos
336.98 lneas de cdigo / persona-meses

Velocidad del proyecto en

15(32)

total
de
ideal-personasemanas / iteracin
Otros datos relevantes para la medicin, correspondientes del proyecto actual:
- Salario actual:
$5000
- Lneas de cdigo: 7000
- Puntos de funcin 171
Con estos datos estamos preparados para usar el software de AGILE COCOMO II,
para realizar la estimacin del esfuerzo y del costo. A continuacin los detalles de las
estimaciones usando los parmetros de analoga

6.1

Parmetro: Costo total en dlares.

Figura 1

16(32)

Figura 2

Con una lnea base de $90000.00 para un proyecto con una cantidad estimada de 7
KSLOC y un salario mensual por analista de $5000.00 con caractersticas similares al
anterior proyecto y donde cuatro factores de medicin de COCOMO cambiaron de
acuerdo a lo que indica la figura obtenemos una estimacin del costo de $74404.08 y
una estimacin del esfuerzo de 14.88 persona-meses.
Estos datos pueden resultar ambiguos al tener como lnea base solo el costo total del
proyecto anterior por lo que analizaremos los otros parmetros.

6.2

Parmetro: Esfuerzo total en persona-meses.

Figura 3

17(32)

Figura 4
Notamos que al usar el parmetro Esfuerzo total en persona-meses obtenemos los
mismos resultados. Tambin se observa que el software redondea al entero ms
prximo si ingresamos valores con parte decimal.

6.3

Parmetro: Productividad en dlares / puntos de funcin

Figura 5

18(32)

Figura 6
Al usar el parmetro productividad en dlares por puntos de funcin notamos que los
resultados de la medicin han aumentado, una de las razones es el redondeo de los
valores ingresados para convertirlos a enteros. Adems, necesita de entrada los
puntos de funcin estimados en el proyecto actual y el lenguaje que se va usar para el
desarrollo, con estos dos valores calcula un KSLOC que es incluido en la estimacin.

6.4

Parmetro: Productividad en dlares / lneas de cdigo.

Figura 7

19(32)

Figura 8
Para el parmetro productividad en dlares por lnea de cdigo notamos que el
resultado es an mayor, esto ocurre en primer lugar porque estamos dividiendo el
costo total de proyecto anterior por su cantidad de lneas de cdigo, luego el sistema
usa el redondeo del valor perdiendo exactitud en su clculo.

6.5

Productividad en puntos de funcin / persona-meses

20(32)

Figura 9

Figura 10
Igualmente, los resultados son distintos por que los datos ingresados son redondeados
originando un clculo que no es exacto.

6.6

Productividad en lneas de cdigo / persona-meses

21(32)

Figura 11

Figura 12
Las lneas de cdigo por ser un nmero demasiado grande y al dividirlo y redondearlo
tambin pierde exactitud como dato de entrada.

6.7

Velocidad del proyecto en total de ideal-persona-semanas /

iteracin

Se basa en el modelo MBASE, modelo espiral usado en RUP.

Se trata de estimar cual sera el esfuerzo ideal de cada iteracin de un ciclo de vida de
desarrollo considerando las fases de Inicio, Elaboracin, Construccin y Transicin
expresado en hombre-semanas.

22(32)

La iteracin tendr como resultado el lanzamiento de un producto ejecutable (externo

o interno).
Para dar un ejemplo de cmo obtener esta entrada empezamos revisando la siguiente
figura.
Tenemos los datos del ltimo proyecto desarrollado donde tenemos desglosado los
esfuerzos por fases.

Figura 13
Lo que podramos hacer es tomar los 17,856 personas-meses y dividirlos en cuantas
iteraciones se necesitaron para terminar el proyecto, por ejemplo 3.
Esfuerzo por Iteracin = 17,856 / 3 = 5,952
Al resultado debemos multiplicar 152 para obtener las horas totales trabajadas:
Horas totales = 5,952 * 152 = 904,704
Al resultado se le debe dividir entre 38 horas que es lo que el modelo COCOMO II
considera una semana de trabajo. As obtenemos el esfuerzo en hombre-semanas:
Hombre-semanas / iteracin = 904,704 / 38 = 23,808
Este valor es el que servir como lnea base:

23(32)

Figura 14

Figura 15

24(32)

Estimacin de PCGeek usando Agile COCOMO II

En este punto vamos a realizar una estimacin usando Agile COCOMO II de

algunas fases del proyecto PCGeek. Vamos a seguir las siguientes fases:
Choose cost
driver/scale
factor
to be
changed in
this cycle

Define
analogy
parameter
and its
baseline
value

Start
cycle

Provide old &

new values
for
the cost
driver/scale
factor

Specify size
to relate
productivity
and effort

Create
report

La primera etapa del proyecto ser la gestin de proveedores y clientes.

Para ello, como primer paso definimos el parmetro de analoga: la
productividad en puntos de funcin por persona y mes. Debido a que el
equipo que trabajar en este proyecto es el mismo que el que ha trabajado
en proyectos anteriores, es de esperar que la productividad sea similar.
Partimos del conocimiento de que el equipo es capaz de generar 8.93
puntos de funcin por persona y mes, as que como para el proyecto actual
hemos estimado 45 puntos de funcin y el coste medio por persona y mes
es de 5000$, se obtienen los siguientes valores:

25(32)

La estimacin inicial es de unos $25k para esta primera etapa del proyecto,
sin realizar ningn ajuste. Ahora bien, si tenemos en cuenta que el
desarrollo en esta etapa se realizar teniendo en cuenta la reusabilidad,
para que el mdulo desarrollado aqu sea portable a otras lneas de
producto, mientras que en el proyecto que se toma como referencia no se
tuvo en cuenta la reusabilidad, podemos introducir este parmetro como
uno de los que modificar el coste de este proyecto:

Con la introduccin del nuevo parmetro se observa cmo vara el coste y

esfuerzo del proyecto, el cual ha aumentado en un factor de 1.24/0.95 =
1.305 aproximadamente:

26(32)

Igualmente, si tenemos en cuenta que durante el otro proyecto existi en el

equipo cierta rotacin de personal, y ahora por los tiempos de crisis en que
estamos esta rotacin es nula, podemos introducir este factor tambin en la
estimacin:

Esto nos da una nueva estimacin, en este caso menor que la anterior
debida a la menor rotacin del personal esperada para este proyecto:

Adems, debido a que estas primeras etapas del proyecto PCGeek son muy
similares entre s, e involucran la gestin de distintos tipos de datos
(proveedores, clientes, almacn, componentes, compras) la similitud con
proyectos anteriores ser mayor que la del proyecto tomado como
referencia. Esto se hace notar con el factor de escala de nivel de
precedencia del proyecto:

27(32)

Una vez que se han terminado de aadir factores se puede obtener un

informe con la estimacin final del proyecto, donde se desglosa cada uno de
los factores que se han utilizado para realizar la estimacin y cmo influyen
en la estimacin final. Como se puede ver, el resultado debe ser similar al
obtenido con la aplicacin directa de COCOMO II, pero debido a que esta
estimacin se realiza nicamente por comparacin con algn proyecto
anterior se puede llegar al mismo resultado de una manera mucho ms
rpida y directa.

28(32)

29(32)

Conclusiones

Agile COCOMO II proporciona estimaciones simples de la analoga de COCOMO II, y

a priori es aplicable all donde COCOMO II es aplicable. Provee a los gestores de
proyectos de un simple mecanismo para obtener rpidos, exactos y confiables
estimaciones de costo y esfuerzo, es intuitivo, requiere de pocas entradas, toma como
base experiencias pasadas en proyectos similares mientras toma en cuenta las
diferencias.
Toma como base la exactitud y confiabilidad de un modelo probado: COCOMO II.
Usando los diferentes parmetros de analoga con los mismos factores que han
cambiado obtenemos resultados diferentes, pero con un porcentaje o margen de
diferencia entre 8 y 9% que es consecuencia del redondeo de los valores de entrada al
clculo de estimacin.
Usa filosofa Agile para la estimacin, realizando mltiples ciclos sencillos y
predecibles que resultan cada uno de ellos en una estimacin cada vez ms refinada y
precisa.
Sin embargo, sigue necesitando el clculo de los puntos de funcin para una
estimacin precisa, aunque bien es cierto que basndose en la comparacin con
proyectos anteriores incluso esta estimacin podra ser innecesaria, puesto que se
puede tomar como punto de partida los puntos de funcin de un proyecto similar que
fuera realizado con anterioridad.
Pone especial nfasis en la comparacin entre proyectos pasados (cuyos datos son
conocidos) y el proyecto actual, principalmente en qu se diferencia el proyecto actual
del proyecto pasado. No se estima el proyecto de forma absoluta, sino como qu
cambia en este proyecto respecto a qu ocurri en proyectos anteriores. Debido a esto
es muy importante guardar los resultados reales de proyectos anteriores, para poder
proceder a la comparacin, no solamente la estimacin sino qu ocurri en realidad.
Podra tomarse esto como una especie de calibracin implcita, ya que al usar como
dato de entrada los resultados de otros proyectos en la misma compaa, los factores
que difieran del modelo de COCOMO se vern automticamente ajustados.
Por otra parte, es imposible guardar una estimacin para volver despus y modificar
ciertos valores. Sin embargo, debido a su sencillez y velocidad de uso, esta desventaja
se puede considerar menor, ya que cualquier estimacin no lleva ms de unos pocos
minutos.
Se ajusta mejor a un proceso de desarrollo iterativo, ya que al proporcionar
comparacin con proyectos anteriores, cada iteracin puede ser considerada un
subproyecto y podemos estimar la nueva iteracin en base a lo que ocurri en
iteraciones pasadas. As, podemos considerar que el mbito de aplicacin de Agile
COCOMO II es mayor que el de COCOMO II, ya que se autocalibra al usar como
entrada resultados de proyectos anteriores en la misma compaa.
Tambin es verdad que tiene las mismas limitaciones que COCOMO II. Por ejemplo,
no est calibrado correctamente para proyectos muy pequeos, de menos de 2000
lneas de cdigo. En stos, nicamente se pueden aadir factores de coste pero no de
escala.

30(32)

Adems, aunque potencialmente est disponible para cualquier plataforma, en

realidad slo ha funcionado correctamente bajo Internet Explorer en Windows. Se ha
probado sin xito bajo Firefox en Windows y Linux, Chrome en Windows y Linux, y
Opera en Linux.

31(32)

Referencias

http://csse.usc.edu/csse/research/COCOMOII/cocomo_main.html
http://csse.usc.edu/csse/research/AgileCOCOMO/

32(32)