Ingeniería Investigación y Tecnología, volumen XV (número 3), julio-septiembre 2014: 403-418

ISSN 1405-7743 FI-UNAM

(artículo arbitrado)

Estimación y control de costos en métodos ágiles para

desarrollo de software: un caso de estudio
Estimation and Control in Agile Methods for
Software Development: a Case Study

Mitre-Hernández Hugo A.
Centro de Investigación en Matemáticas (CIMAT)
Ciencias de la Computación, Zacatecas, México Lemus-Olalde Cuauhtémoc
Correo: hmitre@cimat.mx
Centro de Investigación en Matemáticas (CIMAT)
Ortega-Martínez Edgar Ciencias de la Computación, Zacatecas, México
Correo: clemola@cimat.mx
Centro de Investigación en Matemáticas (CIMAT)
Ciencias de la Computación, Zacatecas, México
Correo: eortegam@cimat.mx

Información del artículo: recibido: diciembre de 2012, reevaluado: abril de 2013, aceptado: julio 2013

Resumen

El desarrollo de software utilizando métodos ágiles está en crecimiento debi-

˜ȱŠȱ•Šȱ™›˜žŒ’Ÿ’ŠȱŠœ˜Œ’ŠŠȱŠȱŽœŠœȱ–Ž˜˜•˜ÇŠœǰȱŠŽ–¤œȱŽȱ•Šȱ̎¡’‹’•’-
Descriptores:
dad demostrada para equipos pequeños. Sin embargo, estas metodologías
cuentan con debilidades claras de estimación y gestión de costos de desarro- ‡ JHVWLyQGHOsoftware
••˜ǰȱŠ•ȱ’žŠ•ȱšžŽȱ•˜œȱŠ–’—’œ›Š˜›ŽœȱŽȱ™›˜¢ŽŒ˜œȱ—˜ȱŒžŽ—Š—ȱŒ˜—ȱ•Šœȱœžę- ‡ JHVWLyQGHFRVWRV
cientes evidencias para la comprobación del gasto del presupuesto en un ‡ PpWRGRViJLOHV
proyecto debido a la poca documentación generada y por la falta de segui- ‡ GHVDUUROORGHsoftwareiJLO
miento en el gasto de los recursos. Se presenta una propuesta de estimación ‡ 6DD6
y control de costos en métodos agiles para resolver estas carencias. En este
sentido, se realizó un caso de estudio en una empresa de desarrollo de soft-
ware ágil utilizando la propuesta en proyectos de software de servicio (SaaS)
y aplicaciones Web. En los resultados se encontró que la propuesta genera
un alto grado de evidencias para los administradores de proyectos, pero pre-
senta carencias en la administración de las evidencias para el control y toma
ŽȱŽŒ’œ’˜—Žœǰȱ•˜ȱŒžŠ•ȱ’˜ȱ˜›’Ž—ȱŠȱž—ŠȱŽę—’Œ’à—ȱŽȱž—ȱ™›˜ŒŽœ˜ȱŽȱ˜–ŠȱŽȱ
decisiones para ser aunado a la propuesta de medición.
 Estimación y control de costos en métodos ágiles para desarrollo de software: un caso de estudio

Abstract

The development of software (SW) using agile methods is growing due to the pro-
žŒ’Ÿ’¢ȱŠœœ˜Œ’ŠŽȱ ’‘ȱ‘ŽœŽȱ–Ž‘˜˜•˜’Žœǰȱ’—ȱŠ’’˜—ȱ˜ȱ‘Žȱ̎¡’‹’•’¢ȱœ‘˜ —ȱ’—ȱ
Keywords:
small teams. However, these methods have clear weaknesses of software development
in cost estimation and management, as well as the fact that project managers do not ‡ software management
‘ŠŸŽȱ Ž—˜ž‘ȱ ŽŸ’Ž—ŒŽȱ ˜ȱ ŸŽ›’¢ȱ ‘Žȱ ‹žŽȱ œ™Ž—’—ȱ ˜—ȱ Šȱ ™›˜“ŽŒȱ žŽȱ ˜ȱ ‘Žȱ ™˜˜›ȱ ‡ cost management
documentation generated and the lack of monitoring of resource spending. A pro- ‡ agile methods
posal estimation and cost control in agile methods to solve these shortcomings. To ‡ agile software development
this end, a case study was conducted in an agile software development company ‡ SaaS
žœ’—ȱ‘Žȱ™›˜™˜œŠ•ȱ˜›ȱ˜ Š›ŽȱŠœȱŠȱŽ›Ÿ’ŒŽȱǻŠŠǼȱŠ—ȱŽ‹ȱŠ™™•’ŒŠ’˜—ȱ™›˜“ŽŒœǯȱ
The results found were that the proposal generates a high degree of evidence for
™›˜“ŽŒȱ–Š—ŠŽ›œǰȱ‹žȱ’ȱ‘Šœȱœ‘˜›Œ˜–’—œȱ’—ȱ‘ŽȱŠ–’—’œ›Š’˜—ȱ˜ȱ‘ŽȱŽŸ’Ž—ŒŽȱ˜›ȱ
‘ŽȱŒ˜—›˜•ȱŠ—ȱŽŒ’œ’˜—ȱ–Š”’—ǰȱ ‘’Œ‘ȱ•Žȱ˜ȱŠȱŽę—’’˜—ȱ˜ȱŠȱŽŒ’œ’˜—ȱ–Š”’—ȱ™›˜-
ŒŽœœȱ˜ȱ‹ŽȱŒ˜ž™•Žȱ ’‘ȱ‘Žȱ–ŽŠœž›Ž–Ž—ȱ™›˜™˜œŠ•ǯ

Introducción
Las metodologías ágiles son bien adoptadas por las pe-
queñas y medianas empresas (PYME) debido a que les per-
miten tener procesos organizados, repetibles y mejorables
sin una alta inversión de presupuesto y de tiempo en su
implementación. Las metodologías más utilizadas en la
tos del registro del producto (PBI, Product Backlog Items)
ǻŠ™ǰȱŘŖŖŜǼǰȱŠŽ–¤œȱŽ•ȱŠ–ŠÛ˜ȱŽ•ȱ™›˜¢ŽŒ˜ȱœŽȱ–’ŽȱŽ—ȱ
el esfuerzo total que se necesita para su desarrollo.
Conforme a lo anterior, las medidas más comunes en
métodos agiles son el esfuerzo y el tamaño, sin embar-
go, esto da pie a diversas pérdidas económicas por falta
de medidas de costos.
’—žœ›’Šȱ ŠŒžŠ•–Ž—Žȱ œ˜—DZȱ ¡›Ž–Žȱ ›˜›Š––’—ȱ ǻŽ-
fries et al., 2000), SCRUM (Deemer et al., 2010) y Feature
Drive Development (Anderson, 2003).
ŽŠŸŽ—Ž¢ȱ¢ȱ˜—‹˜¢ǰȱŘŖŖŜDzȱž•Š’–Š—ȱ¢ȱŠ›-
Las metodologías ágiles toman su nombre después
El problema con los costos en los métodos ágiles es la
falta de una administración y monitorización efectivas
ǻŠ™ǰȱŘŖŖŜDzȱ
˜—ǰȱŘŖŖŜDzȱžœ”ǰȱŘŖŖşǼǰȱŠŽ–¤œȱŽȱŒŠ›ŽŒŽ›ȱŽȱ•ŠȱŽ—Ž›Š-
ŽȱšžŽȱŽ—ȱŘŖŖŗȱž—ȱ›ž™˜ȱŽȱŗŝȱŽ¡™Ž›˜œȱŽ—ȱŽœŠ››˜••˜ȱŽȱ
softwareȱ›Žž—’Ž›˜—ȱœžœȱ’ŽŠœȱ¢ȱŒ›ŽŠ›˜—ȱŽ•ȱ–Š—’ęŽœ˜ȱ¤’•ǰȱ
estableciendo doce principios y en donde cada metodo-
ŽŠŸŽ—Ž¢ȱ ¢ȱ ˜—‹˜¢ǰȱ ŘŖŖŜDzȱ ‘Š–ȱ ǯȱ ¢ȱ
logía debía cumplir con los siguientes preceptos: indivi-
duos e interacciones sobre procesos y herramientas,
softwareȱ ž—Œ’˜—Š—˜ȱ œ˜‹›Žȱ ˜Œž–Ž—ŠŒ’à—ȱ Ž¡Ž—œ’ŸŠǰȱ
colaboración con el cliente sobre negociación contrac-
tual, respuesta ante el cambio sobre seguir un plan.
La administración de proyectos de software es una
de las partes fundamentales para obtener resultados
Œ’à—ȱŽȱŽŸ’Ž—Œ’Šœȱǻ˜—ŽœǰȱŘŖŖŚDzȱž•Š’–Š—ȱ¢ȱŠ›˜—ǰȱŘŖŖŜDzȱ
žœ”ǰȱŘŖŖşǼȱ¢ȱŽœ’–ŠŒ’˜—ŽœȱŽȱŒ˜œ˜œȱž’ŠŠȱ™˜›ȱ™›˜ŒŽ-
œ˜œȱ –Ž“˜›Š‹•Žœȱ ǻ
Pham P., 2011), afectando con esto al dueño de la empre-
sa de SW y ocasionando un descontrol con los adminis-
›Š˜›ŽœȱŽȱ™›˜¢ŽŒ˜œȱ¢ȱŽ¡™Ž›˜œȱŽ—ȱ–·˜˜œȱŠ’•Žœǯ
Si se logra crear un método capaz de estimar costos
basados en evidencias históricas, controlar y monitori-
zar los costos periódicamente, se logrará minimizar la
pérdida de costos y ajustar el programa a los tiempos y
Ž¡’˜œ˜œȱœŽø—ȱ˜—ŽœȱǻŘŖŖŚǼǰȱŒ˜—œ’Ž›Š—˜ȱž—ȱ™›˜¢ŽŒ˜ȱ compromisos con el cliente.
Ž¡’˜œ˜ȱŒ˜–˜ȱŽ•ȱšžŽȱŽ›–’—ŠȱŽ—›˜ȱŽ•ȱ’Ž–™˜ǰȱŒ˜œ˜ȱ¢ȱ El objetivo de esta investigación es proveer un méto-
ŒŠ•’ŠȱŽœ™Ž›ŠŠȱǻ˜—ŽœǰȱŘŖŖřDzȱŠ› Š•ȱ¢ȱŠ‘˜ǰȱŘŖŖŜDzȱ
‘˜ ȱ ¢ȱ Š˜ǰȱ ŘŖŖŞǼǰȱ ™›’—Œ’™Š•–Ž—Žȱ ™›ŽœŽ›ŸŠ—˜ȱ •˜œȱ
˜ŒŽȱ ™›’—Œ’™’˜œȱ Ž•ȱ –Š—’ęŽœ˜ȱ ¤’•ȱ Žȱ ‘˜ ȱ ¢ȱ Š˜ȱ
ǻŘŖŖŞǼǯȱ—ȱ•Šȱ’—žœ›’ŠȱŽȱ–Š—žŠŒž›Šȱ¤’•ȱœŽȱ‘Š—ȱ™›Ž-
sentado buenos resultados de adaptabilidad a los cam-
‹’˜œȱ Ž¡Ž›—˜œȱ Œ˜—ȱ –Ž—˜œȱ ™·›’Šœȱ Žȱ Œ˜œ˜œȱ ǻŠŠ—’ȱ ¢ȱ
ŽĴž—Ž—ǰȱŘŖŖŜǼǰȱŽ—ȱŒžŠ—˜ȱŠ•ȱŽœŠ››˜••˜ȱ¤’•ȱŽȱsoftware
esta adaptabilidad es necesaria en los cambios de los
productos de software (SW).
En la administración de métodos ágiles la medida
utilizada para evaluar el rendimiento de un equipo es
conocer la velocidad con que se desarrollan los elemen-
404 Ingeniería Investigación y Tecnología, volumen XV (número 3), julio-septiembre 2014: 403-418 ISSN 1405-7743 FI-UNAM
do para la administración y monitoreo del presupuesto
además de la estimación de costos en los métodos ágiles,
œ’ž’Ž—˜ȱ•˜œȱ™›’—Œ’™’˜œȱŽ•ȱ–Š—’ęŽœ˜ȱ¤’•ȱ¢ȱŠ‹˜›Š—˜ȱ
los problemas de administración, monitorización, gene-
ración de evidencias y estimación de costos.
El presente artículo está organizado de la siguiente
manera: la sección de trabajos relacionados presenta al-
gunos trabajos que proponen métodos para el control
Ž•ȱ™›Žœž™žŽœ˜ȱ¢ȱ•ŠȱŽœ’–ŠŒ’à—ȱŽȱŒ˜œ˜œDzȱŽ—ȱ•ŠȱœŽŒŒ’à—ȱ
de propuesta de medición de costos se desarrolla la
propuesta del control de presupuesto y del proceso de
Žœ’–ŠŒ’à—ȱŽȱŒ˜œ˜œDzȱŽ—ȱ•ŠȱŒžŠ›ŠȱœŽŒŒ’à—ȱœŽȱŽœŠ››˜••Šȱ
 Mitre-Hernández Hugo A., Ortega-Martínez Edgar, Lemus-Olalde Cuauhtémoc
el caso de estudio, desde su diseño hasta la interpreta-
Œ’à—ȱŽȱ•˜œȱ›Žœž•Š˜œDzȱ™˜›ȱø•’–˜ȱœŽȱŠ—ȱȱ•ŠœȱŒ˜—Œ•žœ’˜-
—Žœȱ¢ȱŽ•ȱ›Š‹Š“˜ȱžž›˜DzȱŽ—ȱ•Šȱ™Š›Žȱꗊ•ȱŽ•ȱ˜Œž–Ž—˜ȱ
œŽȱŠ›Žàȱž—ȱŠ—Ž¡˜ȱŒ˜—ȱ•ŠȱŽ›–’—˜•˜ÇŠȱ–¤œȱž’•’£ŠŠȱ
en el ambiente de los métodos ágiles.
Trabajos relacionados
Se realizó una revisión de la literatura con temas que
abordan los problemas en la administración de costos
en métodos ágiles, se encontraron dos temas principa-
les: el primero tiene que ver con el monitoreo y control
del presupuesto de un proyecto y el segundo corres-
ponde a la estimación del costo de desarrollo de un
proyecto. En la sección de monitoreo y control del cos-
˜ȱœŽȱŽ¡™˜—ŽȱŽ•ȱ–˜—’˜›Ž˜ȱŽ•ȱ™›Žœž™žŽœ˜ȱ¢ȱ•ŠȱœŽŒŒ’à—ȱ
siguiente trata acerca de la estimación de costos. El
método ágil para administración de proyectos más co-
–ø—ȱ šžŽȱ œŽȱ Ž—Œ˜—›àȱ Ž—ȱ •Šȱ •’Ž›Šž›Šȱ žŽȱ ȱ
(Deemer et al., 2010), por lo que será este en el que se
base este artículo.
0RQLWRUHR\FRQWUROGHOSUHVXSXHVWR
—ȱŽ•ȱŠ›ÇŒž•˜ȱŽȱž•Š’–Š—ȱ¢ȱŠ›˜—ȱǻŘŖŖŜǼȱœŽȱŽę—Žȱž—Šȱ
metodología llamada AgileEVM, que tiene el propósito
de monitorear el avance de un proyecto en los atributos
de tiempo y costo. AgileEVM se basa en el método de
administración del valor ganado (EVM, Earned Value
ManagementǼǯȱ ȱ œŽȱ Žę—Žȱ Ž—ȱ ›˜“ŽŒȱ Š—ŠŽ–Ž—ȱ
Institute (2003) como: “EVM es un método para la inte-
gración del alcance, cronograma y recursos, y para me-
dir el desempeño del proyecto”.
En AgileEVM las métricas de SCRUM se relacionan
directamente con las métricas de EVM tradicional bus-
cando no agregar burocracia innecesaria al proceso de
desarrollo.
El monitoreo del desempeño y el presupuesto del
™›˜¢ŽŒ˜ȱŽ—ȱ’•ŽȱœŽȱ›ŽŠ•’£ŠȱŠ•ȱꗊ•ȱŽȱŒŠŠȱ’Ž›Š-
ción, en estas revisiones se recolectan cuatro paráme-
›˜œDZȱ Ž•ȱ —ø–Ž›˜ȱ Žȱ ’Ž›ŠŒ’à—ȱ ŠŒžŠ•ȱ ǻ—Ǽǰȱ •˜œȱ ™ž—˜œȱ Žȱ
historia terminados durante la iteración (PC), los pun-
tos de historia agregados o eliminados de la lista de tra-
bajo que se tiene que desarrollar en la siguiente iteración
(•’œŠȱ‹ŠŒ”•˜) durante la iteración actual (PA) y el costo
de la iteración (SC).
Las métricas de monitoreo que AgileEVM muestra
son el índice del desempeño del costo (CPI), el índice
del desempeño en el tiempo (SPI) y los puntos de histo-
ria SP (Story PointsǼȱŠ•Š—Žœȱž›Š—ŽȱŒŠŠȱ’Ž›ŠŒ’à—ȱǻę-
gura 1). Entonces, conociendo el CPI y el SPI es posible
ya que si es así, el valor de CPI y SPI debe ser igual a 1.
Si el CPI es mayor que 1 entonces se está gastando me-
—˜œȱŽȱ•˜ȱ™•Š—ŽŠ˜ǰȱž—ȱȱ–Ž—˜›ȱšžŽȱŗȱœ’—’ęŒŠȱšžŽȱœŽȱ
está gastando más del presupuesto. Si el SPI es mayor
que 1 entonces se terminará el proyecto antes de lo pla-
neado y si el SPI es menor que 1 el proyecto terminará
tarde.
—ȱ Ž•ȱ Š›ÇŒž•˜ȱ Žȱ Š—ȱ Š œ‘˜›—Žȱ ǻŘŖŖŞǼȱ œŽȱ ˜–Šȱ
como base el método AgileEVM (Sulaiman y Barton,
ŘŖŖŜǼǰȱ™Ž›˜ȱŠ›ŽŠ—˜ȱŠȱ•˜œȱǗ’ŒŽœȱȱ¢ȱȱŽ•ȱŸŠ•˜›ȱ
del negocio ganado durante cada iteración (EBV), ya
šžŽȱ Š œ‘˜›—Žȱ •˜ȱ Œ˜—œ’Ž›Šȱ ž—Šȱ –·›’ŒŠȱ ’–™˜›Š—Žȱ
para conocer el valor de negocio que el equipo de desa-
››˜••˜ȱŠ›ŽŠȱŠ•ȱ™›˜žŒ˜ȱ¢ȱšžŽȱ‹Ž—ŽęŒ’ŠȱŠ•ȱŒ•’Ž—Žȱž-
rante cada iteración. En el método propuesto se asigna
un costo de desarrollo a cada SP y la estimación del cos-
to del proyecto está basada en días por persona.
Al término de cada iteración, además de obtener los
parámetros necesarios para conocer el CPI y el SPI, es
indispensable conocer el valor de negocio (BV, Business
Value) que aporta cada HU (historia de usuarioǼǰȱ œŽø—ȱ
Š œ‘˜›—Žȱ•Šȱ•Ç—ŽŠȱŽ›’ŸŠŠȱŽ•ȱȱŽȱž—ȱ™›˜¢ŽŒ˜ȱ
debe ser muy parecida a una línea S como la mostrada
Ž—ȱ•Šȱꐞ›ŠȱŘǯ
Šȱ’—ŸŽœ’ŠŒ’à—ȱŽȱžœ”ȱŽ—ȱŘŖŖşȱŠ–‹’·—ȱŽœ¤ȱ›Ž•Š-
cionada con el control y monitoreo de costos, su pro-
puesta está fundada en el EVM descrito en el estándar
ȦȬŝŚŞǯȱžœ”ǰȱ‹ŠœŠ˜ȱŽ—ȱœžȱŽ¡™Ž›’Ž—Œ’Šȱ–Ž—Œ’˜-
na que el enfoque tradicional de EVM encaja bastante
bien en los métodos ágiles y que es muy fácil entender
œžȱŠ™•’ŒŠŒ’à—ǯȱŽø—ȱžœ”ǰȱŒ˜—˜ŒŽ›ȱŽ•ȱŒ˜—Ž¡˜ȱꗊ—Œ’Ž-
ro de los proyectos desarrollados en métodos ágiles no
Žœȱ ™˜œ’‹•Žȱ ž’•’£Š—˜ȱ ø—’ŒŠ–Ž—Žȱ •Šœȱ ›¤ęŒŠœȱ Žȱ ‹ž›—ȱ
down proporcionadas por la administración ágil.
Para monitorear el desempeño del proyecto y el
Œ˜—Ž¡˜ȱꗊ—Œ’Ž›˜ǰȱœŽȱž’•’£àȱž—Šȱ›¤ęŒŠȱŽ—ȱà—Žȱ•Šȱ
métrica de presupuesto y SP desarrolladas se repre-
sentan con valores porcentuales durante cada itera-
Œ’à—ȱŽ—ȱ›Ž•ŠŒ’à—ȱŒ˜—ȱŽ•ȱ˜Š•ȱŽȱȱŽ•ȱ™›˜žŒ˜ǯȱžœ”ȱ
)LJXUD *UiILFDSDUDPRVWUDUHOYDORUJDQDGR&3,\63,HQ
conocer si el proyecto marcha de acuerdo a lo planeado, $JLOH(906XODLPDQ\%DUWRQ

Ingeniería Investigación y Tecnología, volumen XV (número 3), julio-septiembre 2014: 403-418 ISSN 1405-7743 FI-UNAM 405
 Estimación y control de costos en métodos ágiles para desarrollo de software: un caso de estudio

)LJXUD/tQHD6LGHDOSDUDHO(%9HQXQSUR\HFWRVHJ~Q )LJXUD*UiILFDXWLOL]DGDSRU5XVNSDUDPRQLWRUHDUHOFRQWH[WR
5DZVWKURQH ILQDQFLHUR\HOGHVHPSHxRHQXQSUR\HFWR

ž’•’£àȱž—Šȱ›¤ęŒŠǰȱŒ˜–˜ȱ•Šȱ–˜œ›ŠŠȱŽ—ȱ•Šȱꐞ›ŠȱřǰȱŽ—ȱ los puntos de función FP (Function Points), los cuales

donde dibujó una línea punteada correspondiente a describen la funcionalidad de cada HU. En este modelo
una función lineal, basada en la velocidad del equipo el monitoreo es diario, por lo que se tiene una base his-
de desarrollo, en la que se supone una velocidad cons- à›’ŒŠȱ Žȱ ’—˜›–ŠŒ’à—Dzȱ ŽœŽȱ –˜Ž•˜ȱ ž’•’£Šȱ Ž•ȱ ꕝ›˜ȱ Žȱ
tante para mostrar el avance esperado en cada itera- Š•–Š—ȱ¢ȱŽ•ȱ–˜Ž•Š˜ȱŽȱŽœ™ŠŒ’˜œȱŽȱŽœŠ˜ȱŒ˜—ȱ•Šȱę-
Œ’à—Dzȱž’•’£àȱž—Šȱ•Ç—ŽŠȱ—Ž›Šȱ™Š›Šȱ–˜œ›Š›ȱŽ•ȱŠŸŠ—ŒŽȱŽȱ nalidad de hacer proyecciones muy precisas del avance
ȱŽœŠ››˜••Š˜ȱŠ•ȱꗊ•’£Š›ȱŒŠŠȱ’Ž›ŠŒ’à—ȱ¢ȱž—Šȱ•Ç—ŽŠȱ en puntos de función que se espera tenga el producto
gris para ilustrar el gasto del presupuesto en cada ite- œŽø—ȱ•ŠȱŸŽ•˜Œ’Šȱ‘’œà›’ŒŠȱŽ•ȱŽšž’™˜ǯȱ•ȱ–˜Ž•˜ȱŽœ-
›ŠŒ’à—ǰȱ Šȱ ŽœŠȱ ›¤ęŒŠȱ •Žȱ Šȱ Ž•ȱ —˜–‹›Žȱ Žȱ ›¤ęŒŠȱ Žȱ pacio de estado se alimenta con la información de los
’Ž–™˜ȱ ¢ȱ ™›Žœž™žŽœ˜ǯȱ —ȱ Ž••Šȱ Žœȱ ™˜œ’‹•Žȱ ’Ž—’ęŒŠ›ȱ FP faltantes y las variaciones del alcance en el proyecto.
situaciones de riesgo cuando el presupuesto se consu- —ȱ•Šȱꐞ›ŠȱśȱœŽȱ–žŽœ›Šȱ•Šȱ›¤ęŒŠȱž’•’£ŠŠȱ™Š›ŠȱŽ•ȱ–˜-
me más rápido de lo planeado o el costo del esfuerzo —’˜›Ž˜ȱǻ Š—ȱ¢ȱ‘˜’ǰȱŘŖŗŖǼǰȱœŽȱ™žŽŽȱŸŽ›ȱž—Šȱ›¤ęŒŠȱ
es mayor al esperado. del tipo ‹ž›—ȱ˜ — en donde los FP son los valores del
En el artículo de Miranda y Bourque (2010), se pro- eje Y. En el eje X se muestran los FP faltantes por día.
pone una técnica de monitorización de proyectos ba- En las metodologías mostradas en esta sección se
sándose en la técnica de línea de balance (LOB, line of encontraron puntos de mejora. Los métodos basados en
‹Š•Š—ŒŽ) y utilizando puntos de control en las activida- ȱǻž•Š’–Š—ȱ¢ȱŠ›˜—ǰȱŘŖŖŜDzȱžœ”ǰȱŘŖŖşDzȱŠ œ‘˜›-
des del proceso de desarrollo, además se propone que —ŽǰȱŘŖŖŞǼȱ—˜ȱ˜–Š—ȱŽ—ȱŒžŽ—ŠȱŽ•ȱŒŠ–‹’˜ȱŽ—ȱŽ•ȱŠ•ŒŠ—ŒŽȱŽȱ
la recolección de información se realice en los sistemas un proyecto, es decir, la replaneación no se muestra en
de control de versiones utilizados para la integración •Šœȱ›¤ęŒŠœȱŽȱŠ™˜¢˜ȱ™Š›ŠȱŽ•ȱ–˜—’˜›Ž˜ǰȱœ’Ž–™›ŽȱœŽȱŒ˜—-
del producto. En esta técnica el monitoreo se realiza œ’Ž›Šȱø—’ŒŠ–Ž—ŽȱŽ•ȱŸŠ•˜›ȱ˜‹Ž—’˜ȱŽȱ•Šȱ™›’–Ž›Šȱ™•Š-
durante cada iteración aunque la información se reco- neación como un todo, por lo que la información que se
ge durante cada compromiso (commit) realizado al ser-
vidor del control de versiones por el equipo. Para
obtener información desde los repositorios de código
fue necesario estandarizar la manera en que se envían
los commits, escribiendo la HU a la que pertenece y el
punto de control en el que está ubicada esa HU. En la
ꐞ›ŠȱŚȱœŽȱ˜‹œŽ›ŸŠȱ•Šȱ˜›–ŠȱŽ—ȱšžŽȱŽœŽȱ–˜Ž•˜ȱ–žŽœ-
tra la información durante el monitoreo del desempe-
ño en cada punto de control, la información mostrada
Ž—ȱ •Šȱ ›¤ęŒŠȱ ’Ž—Žȱ Œ˜–˜ȱ –·›’ŒŠȱ ‹¤œ’ŒŠȱ ž—Šȱ
ǯȱ —ȱ
este modelo solo es posible conocer la cantidad de re-
querimientos planeados y reales en cada punto de
control en forma de HU durante un tiempo determi-
nado.
Kang y Choi (2010) proponen un modelo de monito- )LJXUD *UiILFDSDUDHOPRQLWRUHRGH+8SRU3XQWRGH&RQWURO
rización dinámico, la métrica básica de monitoreo son XWLOL]DGRHQ/2%0LUDQGD\%RXUTXH

406 Ingeniería Investigación y Tecnología, volumen XV (número 3), julio-septiembre 2014: 403-418 ISSN 1405-7743 FI-UNAM
 Mitre-Hernández Hugo A., Ortega-Martínez Edgar, Lemus-Olalde Cuauhtémoc

nará. Conociendo el tiempo necesario para desarrollar

el proyecto, el líder del proyecto calcula el costo de las
personas que forman parte del equipo para obtener el
presupuesto necesario para el recurso humano, a tal es-
timación además se agregan otros tipos de gastos que el
proyecto necesite y se agrega una suma acumulada de
Šœ˜œȱŠ•ȱ˜Š•ȱŽ•ȱ™›Žœž™žŽœ˜ȱŽœ’–Š˜ȱǻ˜‘—ǰȱŘŖŖśǼǯ
Otra manera de obtener la estimación de costos se
propuso en Kang y Choi (2010), donde la métrica base
para realizar estas estimaciones es utilizar FP, lo que in-
volucra más esfuerzo en la planeación del producto,
pero los autores aseguran que su modelo es más preciso,
ya que los FP son valores absolutos y no relativos como
)LJXUD*UiILFDFRQODLQIRUPDFLyQUHVXOWDQWHGHOILOWUR.DOPDQ
.DQJ\&KRL los SP. La forma en que realizan la estimación del costo
–žŽœ›Šȱ—˜ȱŽœȱŒ˜—ꊋ•ŽȱŠ•ȱ›ŽŠ•’£Š›ȱŒŠ–‹’˜œȱŽ—ȱŽ•ȱŠ•ŒŠ—ŒŽȱ
del proyecto. En el método descrito en Kang y Choi
(2010) se utiliza la aserción de que los FP son valores
absolutos, por lo que son más precisos para planear el
costo y tiempo de un producto, la inversión de mayor
ŽœžŽ›£˜ȱ™Š›Šȱ™•Š—ŽŠ›ȱž—ȱ™›˜žŒ˜ȱŽ—ȱȱ—˜ȱŽœ¤ȱ“žœ’ę-
cada para obtener una planeación más precisa. En el
método de Miranda y Bourque (2010) la precisión de
cada punto de control se muestra con una unidad míni-
ma de HU, por lo que el esfuerzo invertido a cada HU
—˜ȱœŽȱ›ŽĚŽ“ŠȱŽ—ȱœžȱ–Ž˜˜•˜ÇŠǯ
˜œȱ™ž—˜œȱŽȱ–Ž“˜›Šȱ’Ž—’ęŒŠ˜œȱŽ—ȱ•Šœȱ™›˜™žŽœ-
tas de Kang y Choi (2010) y Miranda y Bourque (2010)
fueron contemplar los cambios de alcance del producto
en la replaneación durante cada iteración, además de
utilizar los puntos de historia como métrica para el
esfuerzo.
(VWLPDFLyQGHFRVWRV
En los métodos ágiles se utilizan prácticas empíricas
‹ŠœŠŠœȱŽ—ȱŽ•ȱ“ž’Œ’˜ȱŽȱŽ¡™Ž›˜œȱ™Š›ŠȱŽœ’–Š›ȱŽ•ȱŒ˜œ˜ȱŽȱ
desarrollo para un nuevo producto, en la literatura se
’Ž—’ęŒŠ›˜—ȱ˜œȱ™›¤Œ’ŒŠœȱŒ˜–ž—Žœȱ™Š›ŠȱŽœŠȱꗊ•’Šǰȱ
•Šȱ –¤œȱ Œ˜–ø—ȱ ’—Ÿ˜•žŒ›Šȱ Œ˜–˜ȱ –·›’ŒŠȱ ‹ŠœŽȱ Šȱ •˜œȱ ȱ
ǻ˜‘—ǰȱ ŘŖŖśDzȱ ž•Š’–Š—ȱ ¢ȱ Š›˜—ǰȱ ŘŖŖŜDzȱ žœ”ǰȱ ŘŖŖşDzȱ
Š œ‘˜›—Žǰȱ ŘŖŖŞDzȱ ’›Š—Šȱ ¢ȱ ˜ž›šžŽǰȱ ŘŖŗŖǼȱ ¢ȱ •Šȱ œŽ-
gunda se basa en FP (Kang y Choi, 2010).
Šȱ ™›’–Ž›Šȱ –Š—Ž›Šȱ ’Ž—’ęŒŠŠǰȱ šžŽȱ Žœȱ •Šȱ –¤œȱ Œ˜-
–ø—ȱŽ—ȱ–·˜˜œȱ¤’•Žœǰȱ’Ž—ŽȱŒ˜–˜ȱ–·›’ŒŠȱ™›’—Œ’™Š•ȱŠȱ
•˜œȱȱǻ˜‘—ǰȱŘŖŖśǼǯȱ—ȱŽœŠȱ™›¤Œ’ŒŠȱ•Šȱ™›’–Ž›ŠȱŠ›ŽŠȱŠȱ
realizar es la estimación del esfuerzo total necesario
para desarrollar el proyecto, esta estimación la realiza
el equipo encargado de su desarrollo. En seguida, se
Žę—Žȱž—ŠȱŸŽ•˜Œ’Šȱ‹ŠœŽȱŠšž’›’ŠȱŽȱŠ˜œȱ‘’œà›’Œ˜œȱ
—˜ȱ–ž¢ȱŒ˜—ꊋ•Žœǰȱ˜ȱŽ•ȱ“ž’Œ’˜ȱŽȱŽ¡™Ž›˜œǰȱ™Š›ŠȱŒ˜—˜-
ŒŽ›ȱŽ•ȱ’Ž–™˜ȱŠ™›˜¡’–Š˜ȱŽ—ȱŽ•ȱšžŽȱŽ•ȱ™›˜¢ŽŒ˜ȱŽ›–’-
Ingeniería Investigación y Tecnología, volumen XV (número 3), julio-septiembre 2014: 403-418 ISSN 1405-7743 FI-UNAM
Ž•ȱ™›˜¢ŽŒ˜ȱŽœȱœ’–’•Š›ȱŠȱ•ŠȱšžŽȱœŽȱž’•’£ŠȱŒ˜–ø—–Ž—ŽȱŽ—ȱ
métodos ágiles, con la diferencia que a cada HU le co-
rresponde un conjunto de FP, los cuales tienen un costo
basado en líneas de código o en personas por mes.
Las prácticas de estimación de costos basadas en jui-
Œ’˜œȱŽȱŽ¡™Ž›˜œȱ¢ȱšžŽȱž’•’£Š—ȱȱŒŠ›ŽŒŽ—ȱŽȱž—ȱ–˜Ž•˜ȱ
formal para realizar estimaciones, los datos históricos de
los proyectos de un equipo en una empresa no siempre
se consideran para realizar futuras proyecciones en la es-
timación de costos, posiblemente debido a la burocracia
que acarrearía generar esta información. En la metodolo-
gía propuesta por Kang y Choi (2010) se toman en cuenta
•˜œȱŠ˜œȱ‘’œà›’Œ˜œǰȱ™Ž›˜ȱø—’ŒŠ–Ž—Žȱ•˜œȱŽ•ȱ™›˜¢ŽŒ˜ȱŽ—ȱ
que se trabaja, además de que el costo está en función de
FP, al ser una métrica de esfuerzo que implica un mayor
detalle en la planeación de las HU.
Las mejoras potenciales que se encuentran en la es-
timación de costos son realizar estimaciones de costos
basados en datos históricos de los proyectos, con atri-
butos similares en una empresa, utilizando SP y ajustar
el costo por SP durante cada iteración basado en el de-
sarrollo del proyecto actual.
3URSXHVWDGHPHGLFLyQGHFRVWRV
—ȱ•Šȱ•’Ž›Šž›ŠȱœŽȱŽ—Œ˜—›Š›˜—ȱŠ•ž—ŠœȱŽęŒ’Ž—Œ’ŠœȱŽ—ȱ
los métodos de monitoreo y control del presupuesto
además de la estimación de costos. En el monitoreo y
control del presupuesto se encontró que el alcance de
•˜œȱ™›˜¢ŽŒ˜œȱ—˜ȱœŽȱ™•Š—ŽŠȱŽȱ—žŽŸ˜ȱŠ•ȱꗊ•’£Š›ȱŒŠŠȱ
iteración, por lo que es la re-planeación una de las par-
Žœȱž—Š–Ž—Š•ŽœȱŽ—ȱ•˜œȱ–·˜˜œȱ¤’•Žœȱǻ˜‘—ǰȱŘŖŖśǼȱ
para adaptarse al cambio. En la sección de motivación
se muestra una propuesta que considera el cambio del
alcance en el monitoreo y control de costos apegándo-
se a la administración del valor ganado (EVM) y a los
™›’—Œ’™’˜œȱŽ•ȱ–Š—’ęŽœ˜ȱ¤’•ǯȱ—ȱ•ŠȱœŽŒŒ’à—ȱŽȱŠ—¤•’œ’œȱ
e interpretación se propone una técnica para estimar
407
 Estimación y control de costos en métodos ágiles para desarrollo de software: un caso de estudio
el costo de un proyecto de desarrollo basado en los
tiempos históricos para un conjunto de HU con el mis-
mo esfuerzo.
La propuesta está dirigida a empresas que desa-
rrollan software utilizando métodos ágiles, en las que
se tenga un plan de estimación basado en métricas
relativas y que ven la necesidad de monitorear el pre-
supuesto de sus proyectos, además de ver la necesi-
dad de tener una base histórica para la estimación de
costos basada en hechos históricos dentro de la orga-
nización.
0RQLWRUHR\FRQWUROGHOFRVWR
ŠœȱŽęŒ’Ž—Œ’Šœȱ’Ž—’ęŒŠŠœȱŽ—ȱŽ•ȱ–˜—’˜›Ž˜ȱ¢ȱŒ˜—›˜•ȱ
de costos de la sección de monitoreo y control del pre-
supuesto se solucionan en este punto del artículo.
’ȱ Žœȱ Ž•ȱ Œ˜—“ž—˜ȱ Žȱ
’œ˜›’Šœȱ Žȱ žœžŠ›’˜ȱ
Debido a que el plan de desarrollo en los métodos
¤’•ŽœȱŽ‹ŽȱœŽ›ȱ̎¡’‹•Žȱ¢ȱŒŠ–‹’Š—Žȱ™˜›ȱ•Šȱ™›˜™’Šȱ—Šž-
raleza de los proyectos de desarrollo de software (Cohn,
ŘŖŖśǼǰȱŽœŽȱŽ‹ŽȱœŽ›ȱ–˜—’˜›ŽŠ˜ȱ¢ȱŒ˜—›˜•Š˜ȱ™Š›ŠȱŽŸ’-
Š›ȱ™˜—Ž›ȱŽ—ȱ›’Žœ˜ȱŽ•ȱ·¡’˜ȱŽ•ȱ™›˜¢ŽŒ˜ǰȱ—Ž˜Œ’Š›ȱŒ˜—ȱŽ•ȱ
cliente los cambios del alcance, reducir la incertidum-
bre del estado actual del proyecto, apoyar la toma de
decisiones con el cliente y el equipo de desarrollo, gene-
›Š›ȱŒ˜—ꊗ£Šȱ¢ȱ›Š—œ–’’›ȱ’—˜›–ŠŒ’à—ȱꊋ•ŽȱŠȱ•˜œȱ’—Ÿ˜-
lucrados.
—ȱŽœŠȱ™›˜™žŽœŠȱœŽȱž’•’£Š—ȱ›Žœȱ›¤ęŒŠœȱ™Š›Šȱ˜‹-
servar la información agrupada y que sea fácil de co-
–ž—’ŒŠ›ȱ ¢ȱ Ž—Ž—Ž›ȱ ™˜›ȱ ŒžŠ•šž’Ž›ȱ ™Ž›œ˜—Šǰȱ Šø—ȱ œ’—ȱ
conocimiento en administración de proyectos de desa-
rrollo de softwareǯȱŽȱ’Ž—’ęŒŠ›˜—ȱ˜œȱŠŒ’Ÿ’ŠŽœȱ’–-
portantes para poder realizar el monitoreo, y fue la
planeación el primer acercamiento en donde se generó
un plan de trabajo y estimación de recursos necesarios
™Š›ŠȱŽ•ȱ™›˜¢ŽŒ˜Dzȱ•ŠȱœŽž—ŠȱŠŒ’Ÿ’Šȱ—ŽŒŽœŠ›’Šȱ™Š›Šȱ
permitir el monitoreo y el control del proyecto confor-
me evoluciona es la replaneación, en donde se identi-
ꌊ—ȱ¢ȱœŽȱŠ–’—’œ›Š—ȱ›’Žœ˜œȱ™Š›Šȱ™˜Ž›ȱŽ›–’—Š›ȱŽ•ȱ
™›˜¢ŽŒ˜ȱŒ˜—ȱ·¡’˜ǯ
Planificación
Šȱ™•Š—’ęŒŠŒ’à—ȱŽœȱ•ŠȱŠŒ’Ÿ’Šȱ˜—Žȱœž›ŽȱŽ•ȱ™›’–Ž›ȱ
acercamiento detallado de las necesidades del cliente
¢ȱ˜—ŽȱœŽȱ’Ž—’ęŒŠ—ȱ•˜œȱ›ŽŒž›œ˜œȱ—ŽŒŽœŠ›’˜œȱ™Š›ŠȱŽ•ȱ
desarrollo de un producto de software. En esta pro-
™žŽœŠȱ—˜ȱœŽȱ›ŠŠ—ȱ•Šȱ’Ž—’ęŒŠŒ’à—ȱŽȱ•Šœȱ—ŽŒŽœ’ŠŽœȱ
˜ȱ•ŠȱŽę—’Œ’à—ȱŽȱ•˜œȱ›ŽšžŽ›’–’Ž—˜œȱŽȱŒ•’Ž—Žǰȱ™Ž›˜ȱœÇȱ
es importante que el tamaño del producto utilice la
métrica relativa de puntos de historia, ya que es la más
utilizada en los métodos ágiles y no agrega esfuerzo
408 Ingeniería Investigación y Tecnología, volumen XV (número 3), julio-septiembre 2014: 403-418 ISSN 1405-7743 FI-UNAM
en la actividad de la estimación de esfuerzo requerido
por HU, como en Kang y Choi (2010) donde se utilizan
puntos de función.
En esta propuesta se realiza la planeación utilizando
ǰȱ ŽœŠȱ ™•Š—’ęŒŠŒ’à—ȱ ŸŠȱ Šȱ œŽ›ȱ ŒŠ–‹’Š—Žȱ ž›Š—Žȱ
ŒŠŠȱ’Ž›ŠŒ’à—ȱ¢ȱœŽȱŽ¡™•’ŒŠȱŽ—ȱŽ•ȱ™ž—˜ȱŽ•ȱ˜‹“Ž’Ÿ˜ȱŽȱ
investigación.
Para planear un nuevo proyecto de software es nece-
sario conocer las siguientes métricas base:
Ȋȱȱȱ Š–ŠÛ˜ȱ‹ŠœŽȱ˜Š•ȱŽ•ȱ™›˜žŒ˜ȱǻTBTP): es el tamaño
Ž•ȱ™›˜žŒ˜ȱŽę—’˜ȱŽ—ȱ™ž—˜œȱŽȱ‘’œ˜›’ŠǯȱŠ›Šȱ
conocer este valor se puede aplicar la siguiente
fórmula:
(1)
Ȋȱȱȱ ˜—Žȱ
del proyecto y Esfuerzo es la métrica con que se
–’ŽȱŽ•ȱŠ–ŠÛ˜ȱŽȱ•Šœȱ‘’œ˜›’ŠœȱŽȱžœžŠ›’˜ȱŽę—’˜ȱ
por puntos de historia (SP).
Ȋȱȱȱ Ž•˜Œ’Šȱ‹ŠœŽȱŽ•ȱŽšž’™˜ȱ(VB): es la cantidad de pun-
tos de historia pronosticada que el equipo de desa-
rrollo entregará al usuario durante cada iteración.
œŠȱ –·›’ŒŠȱ œŽȱ ˜‹’Ž—Žȱ Œ˜–ø—–Ž—Žȱ ™˜›ȱ “ž’Œ’˜ȱ Žȱ
Ž¡™Ž›˜œǯȱ —ȱ •Šȱ œŽŒŒ’à—ȱ Žȱ Š—¤•’œ’œȱ Žȱ ’—Ž›™›ŽŠŒ’à—ȱ
se hace una propuesta para obtener esta métrica de
una forma más precisa, basada en información his-
tórica de proyectos con atributos similares desarro-
llados en una organización.
Ȋȱȱȱ Número de Iteraciones (I): es la cantidad de iteracio-
nes que el equipo necesita para desarrollar el pro-
ducto. Para conocer este valor se aplica la siguiente
fórmula:
(2)
ȊȱȱŠ›Šȱ˜‹Ž—Ž›ȱž—ȱŸŠ•˜›ȱŽ—Ž›˜ȱŽ•ȱ›Žœž•Š˜ȱŽȱȱŽ‹Žȱ
œŽ›ȱ›Ž˜—ŽŠ˜ȱ‘ŠŒ’ŠȱœžȱŽ—Ž›˜ȱ™›à¡’–˜ǯ
Ȋȱȱȱ Duración de iteración (DI): indica la duración en tiem-
™˜ȱ Žȱ ŒŠŠȱ Ž›ŠŒ’à—ǰȱ Ž—ȱ ˜—Žȱ Ž•ȱ ›Š—˜ȱ Œ˜–ø—ȱ Žœȱ
Ž—›ŽȱŘȱœŽ–Š—Šœȱ¢ȱŚǯ
Ȋȱȱȱ ˜œ˜ȱ‹ŠœŽȱŽ•ȱ™›˜žŒ˜ȱ(CBP): Žę—ŽȱŽ•ȱŒ˜œ˜ȱŠȱ’—ŸŽ›-
tir para el desarrollo del producto. En los métodos
¤’•Žœȱ—˜ȱŽ¡’œŽȱž—Šȱ™›¤Œ’ŒŠȱ˜ȱ–·˜˜ȱŽœ¤—Š›ȱ™Š›Šȱ
estimar el costo de un producto.
Ȋȱȱȱ ˜œ˜ȱ ‹ŠœŽȱ Ž•ȱ Žšž’™˜ȱ ™˜›ȱ ’Ž›ŠŒ’à—ȱ (CBIǼDZȱ œŽȱ Žę—Žȱ
como el costo monetario que se espera gastar duran-
te cada iteración. Para conocer este valor se utiliza la
siguiente fórmula,
(3)
 Mitre-Hernández Hugo A., Ortega-Martínez Edgar, Lemus-Olalde Cuauhtémoc

Ȋȱȱȱ ˜œ˜ȱ‹ŠœŽȱŽȱȱ™˜›ȱ’Ž›ŠŒ’à—ȱ(CBSPI): es el costo mo- 7DEOD0pWULFDVEDVHSDUDHOSUR\HFWR

netario por desarrollar un punto de Historia y se ´6LVWHPDGHJHVWLyQGHFRQWHQLGRVµ
puede calcular con la siguiente fórmula, Métrica Valor obtenido
TBTP ŚŞŜȱ
ȱ ǻŚǼ
VB 70 SP/Iteración
Además de las métricas base en esta actividad, se obtie- DI 2 semanas
—Žȱ•Šȱ›¤ęŒŠȱ‹ž›—ȱ˜ —ȱde planeación, en la que se gra- I 7
ꌊȱ •Šȱ ŒŠ—’Šȱ Žȱ ȱ Š•Š—Žȱ ™˜›ȱ ŽœŠ››˜••˜ȱ ž›Š—Žȱ
CBP ǞŘśŘǰȱŖŖŖǯŖŖ
ŒŠŠȱ ’Ž›ŠŒ’à—ǯȱ Š›Šȱ ˜‹Ž—Ž›ȱ ŽœŠȱ ›¤ęŒŠȱ Žœȱ —ŽŒŽœŠ›’˜ȱ
conocer la cantidad de SP que el equipo va a desarrollar CBI ǞřŜǰȱŖŖŖǯŖŖ
durante cada iteración basándose en la información de CBSPI ǞȱśŜřǯŝŚ
•Šȱ™•Š—ŽŠŒ’à—ǯȱŠȱž—Œ’à—ȱŠȱ›ŠęŒŠ›ȱŽœȱ•Šȱœ’ž’Ž—ŽDZ
El resumen de la información se ilustra en la tabla 2. El
ȱ ǻśǼ ‹ž›—ȱ˜ —ȱŽȱ™•Š—’ęŒŠŒ’à—ȱœŽȱ–žŽœ›ŠȱŽ—ȱ•Šȱꐞ›ŠȱŜǯ

en donde ¡ȱŽœȱ•Šȱ’Ž›ŠŒ’à—ȱšžŽȱœŽȱŸŠȱŠȱ›ŠęŒŠ›ȱ¢ȱȱœ˜—ȱ Replanificación

los SP a desarrollar en la iteración i.
Šȱ›¤ęŒŠȱŽȱ‹ž›—ȱ˜ —ȱŽȱ™•Š—’ęŒŠŒ’à—ȱŽŸ˜•žŒ’˜—Š›¤ȱž-
Š›ŠȱŽ“Ž–™•’ęŒŠ›ȱŽœŠȱŠŒ’Ÿ’Šȱ˜–Š–˜œȱŒ˜–˜ȱŽ“Ž–-
rante cada revisión de iteración, en ella se mostrará que:
plo el proyecto “Sistema de gestión de contenidos” desa-
rrollado en la empresa Compulogic, a través de su división Ȋȱȱȱ •ȱŠŸŠ—ŒŽȱ‹ŠœŽȱ™•Š—ŽŠ˜ȱ(ABǼȱœŽȱ›ŠęŒŠȱŒ˜—ȱ•Šȱ–’œ–Šȱ
de software, en donde el equipo de desarrollo está confor- ž—Œ’à—ȱž’•’£ŠŠȱŽ—ȱ•Šȱ™•Š—’ęŒŠŒ’à—ǯ
–Š˜ȱ ™˜›ȱ ž—ȱ •ÇŽ›ȱ Žȱ ™›˜¢ŽŒ˜ȱ ¢ȱ śȱ ŽœŠ››˜••Š˜›Žœǯȱ •ȱ Ȋȱȱȱ El avance real (AR) mostrará el valor ganado durante
Žšž’™˜ȱ •ŽŸŠ—àȱ ›ŽšžŽ›’–’Ž—˜œȱ Œ˜—ȱ ž—ȱ ˜Š•ȱ Žȱ ŚŜȱ
œǰȱ cada iteración incluyendo los cambios en el alcance
cada una con su respectivo esfuerzo, donde se obtuvo un durante cada iteración. Los cambios en el alcance se
ȱŽȱŚŞŜȱǯȱ•ȱ•ÇŽ›ȱŽ•ȱ™›˜¢ŽŒ˜ȱŒ˜—œ’Ž›àȱž—ŠȱȱŽȱ mostrarán a la alza cuando se agreguen SP al pro-
70 SP por iteración basándose en las velocidades logradas ducto y a la baja cuando se eliminen.
Ž—ȱ™›˜¢ŽŒ˜œȱŠ—Ž›’˜›ŽœDzȱŒ˜—ȱŽ•ȱȱ¢ȱȱœŽȱ˜‹’Ž—Ž—ȱŝȱ Ȋȱȱ•ȱŠŸŠ—ŒŽȱ›Ž™•Š—’ęŒŠ˜ȱǻARR) mostrará los ajustes que
iteraciones necesarias para desarrollar el producto con el equipo toma durante cada planeación de una
una duración de 2 semanas cada una. Además, el líder —žŽŸŠȱ’Ž›ŠŒ’à—ǯȱž›Š—ŽȱŒŠŠȱ™•Š—’ęŒŠŒ’à—ȱŽȱ’Ž›Š-
estimó el costo del producto basándose en los sueldos de ción el equipo decide qué HU va a desarrollar, se
los desarrolladores que forman parte del equipo y del ‹ŠœŠȱŽ—ȱ•Šȱ’—˜›–ŠŒ’à—ȱŽȱ•Šȱ™•Š—’ęŒŠŒ’à—ǰȱ™Ž›˜ȱŽœŠȱ
tiempo que durará el proyecto, de donde obtuvo un CBP es susceptible a cualquier tipo de cambio generado
ŽȱǞŘśŘǰŖŖŖǯŖŖ1. El equipo planea los SP a desarrollar en por petición del involucrado para mitigar riesgos o
cada iteración y obtiene la información que se muestra en para eliminar restricciones.
la tabla 1. Para controlar el cambio del alcance y mantenerlo visi-
ble durante cada iteración se propone la ›¤ęŒŠȱŽȱŒŠ–-
‹’˜œȱ Ž—ȱ Ž•ȱ Š•ŒŠ—ŒŽ, que mostrará el impacto de estos
7DEOD63SODQHDGRVSRULWHUDFLyQSDUDHOSUR\HFWR
´6LVWHPDGHJHVWLyQGHFRQWHQLGRVµ cambios en los SP agregados o eliminados del TBTP.
Iteración SPI
1 ŜŜ
2 71
3 71
Ś Ŝś
ś Ŝś
Ŝ ŜŞ
7 ŞŖ

3DUDFRQVHUYDUODFRQILGHQFLDOLGDGFRQORVFRVWRVGHQWURGHODHP- )LJXUDBurn downGHSODQLILFDFLyQSDUDHOSUR\HFWR´6LVWHPD

SUHVDHOFRVWRUHIHUHQFLDGRVHFDPELy GHJHVWLyQGHFRQWHQLGRVµ

Ingeniería Investigación y Tecnología, volumen XV (número 3), julio-septiembre 2014: 403-418 ISSN 1405-7743 FI-UNAM 409
 Estimación y control de costos en métodos ágiles para desarrollo de software: un caso de estudio
En esta actividad es necesario obtener las siguientes
métricas:
Ȋȱȱȱ Costo actual de la iteración (CAI):ȱŽę—ŽȱŽ•ȱŒ˜œ˜ȱ–˜-
netario de una iteración.
ȊȱȱSP desarrollados en la iteración (SPAIǼDZȱŽę—Žȱ•˜œȱȱŽ-
sarrollados en una iteración. Solo se contabilizan los
ȱŠŒŽ™Š˜œȱ™˜›ȱŽ•ȱŒ•’Ž—ŽȱŠ•ȱꗊ•’£Š›ȱž—Šȱ’Ž›ŠŒ’à—ǯȱ
También se puede nombrar velocidad de iteración.
Ȋȱȱȱ Costo actual de SP (CASPIǼDZȱŽę—ŽȱŽ•ȱŒ˜œ˜ȱ–˜—ŽŠ›’˜ȱ
por desarrollar un SP en una iteración. Para conocer
este costo se utiliza la siguiente función:
ȱ ǻŜǼ
Ȋȱȱȱ A—’ŒŽ de desempeño del costo (CPI): esta métrica per-
–’ŽȱŸ’œžŠ•’£Š›ȱ•Šȱ̞ŒžŠŒ’à—ȱŽ•ȱŒ˜œ˜ȱ™˜›ȱȱŒ˜—›Šȱ
el costo por SP real durante cada iteración. Este índi-
ce permite conocer si el equipo desarrolla los SP
‹Š“˜ȱ•˜ȱ™›Žœž™žŽœŠ˜ȱŽ—ȱ•Šȱ™•Š—’ęŒŠŒ’à—ȱ˜ȱŽœ¤ȱŽ¡-
ŒŽ’Ž—˜ȱ Ž•ȱ ™›Žœž™žŽœ˜ȱ ¢ȱ ™˜—Žȱ Ž—ȱ ›’Žœ˜ȱ Ž•ȱ ·¡’˜ȱ
del proyecto. El CPI ideal debe tener un valor igual
ŠȱŗǯȱžŠ—˜ȱŽ•ȱȱŽœȱ–Š¢˜›ȱšžŽȱŗȱœ’—’ęŒŠȱšžŽȱŽ•ȱ
costo por SP es menor al planeado y si el CPI es me-
—˜›ȱšžŽȱŗȱœ’—’ęŒŠȱšžŽȱŽ•ȱŒ˜œ˜ȱ™˜›ȱȱŽœȱ–Š¢˜›ȱšžŽȱ
el planeado. La fórmula para conocer este índice es
la siguiente:
Ȋȱȱȱ A—’ŒŽȱŽ•ȱŽœŽ–™ŽÛ˜ȱŽ•ȱŒŠ•Ž—Š›’˜ȱǻSPI): este ín-
dice es el que permite realizar el monitoreo del ca-
•Ž—Š›’˜ǰȱ Ž•ȱ Žšž’™˜ȱ Œ˜—˜ŒŽ›¤ȱ •Šȱ ̞ŒžŠŒ’à—ȱ Žȱ •Šȱ
velocidad planeada respecto a la real durante cada
iteración. Cuando el SPI obtenido durante una itera-
ción es mayor que 1, el proyecto terminará antes de
•˜ȱ ™•Š—ŽŠ˜Dzȱ œ’ȱ Ž•ȱ ȱ Žœȱ –Ž—˜›ȱ šžŽȱ ŗǰȱ Ž•ȱ ™›˜¢ŽŒ˜ȱ
terminará después de la fecha planeada. La fórmula
para conocer este índice es la siguiente:
SPA1
SPI
VB
ȊȱȱŠ–‹’˜œȱŽ—ȱŽ•ȱŠ•ŒŠ—ŒŽȱ(SPCA): esta métrica permitirá
conocer la cantidad de SP agregados o eliminados al
TBTP durante una iteración.
Ȋȱȱȱ ˜Š•ȱŽȱŒŠ–‹’˜œȱŽ—ȱŽ•ȱŠ•ŒŠ—ŒŽȱ(TSPCA): con esta métri-
ca será posible monitorear el total de cambios reali-
£Š˜œȱŽ—ȱŽ•ȱ™›˜¢ŽŒ˜ǯȱ—ȱȱœŽȱŒ˜—œ’Ž›ŠȱŽ¡’˜œ˜ȱ
ž—ȱ™›˜¢ŽŒ˜ȱšžŽȱŸŠ›’àȱřŖƖȱœžȱ’Ž–™˜ȱ¢ȱŒ˜œ˜ȱǻžœ”ǰȱ
ŘŖŖşǼǰȱŽœȱ™˜›ȱŽ••˜ȱšžŽȱœŽȱ›ŽŒ˜–’Ž—ŠȱšžŽȱŽœŠȱ–·›’-
ca nunca sea mayor que 30%. Para obtener esta mé-
trica se utiliza la siguiente función:
410 Ingeniería Investigación y Tecnología, volumen XV (número 3), julio-septiembre 2014: 403-418 ISSN 1405-7743 FI-UNAM
ǻşǼ
en donde se calculan el total de cambios de alcance
en cada iteración hasta una iteración n.
El monitoreo y control de los cambios en el alcance se
Œ˜—Š‹’•’£Š—ȱŠ•ȱꗊ•’£Š›ȱŒŠŠȱ’Ž›ŠŒ’à—ȱŽ—ȱ•Šȱ›Žž—’à—ȱŒ˜—ȱ
el cliente para negociar los cambios, si es necesario, ya
que es recomendable que el cambio del alcance no sea
mayor que 30% del TBTP.
Š›ŠȱŽ“Ž–™•’ęŒŠ›ȱ•ŠȱŠŒ’Ÿ’ŠȱŽȱ›Ž™•Š—ŽŠŒ’à—ȱŒ˜—’-
nuaremos con el proyecto de “Sistema de gestión de
contenidos” en donde se ilustrará el desarrollo del pro-
¢ŽŒ˜ȱ ž›Š—Žȱ •Šœȱ œ’ŽŽȱ ’Ž›ŠŒ’˜—Žœǯȱ —ȱ •Šȱ ꐞ›Šȱ ŝȱ œŽȱ
–žŽœ›Šȱ•Šȱ›¤ęŒŠȱŽȱ‹ž›—ȱ˜ — de iteración obtenida al
ꗊ•’£Š›ȱŽ•ȱ™›˜¢ŽŒ˜ǯȱ—ȱŽœŠȱ›¤ęŒŠȱŽœȱ™˜œ’‹•ŽȱŠ™›ŽŒ’Š›ȱ
šžŽȱŽ—ȱ•Šœȱ’Ž›ŠŒ’˜—Žœȱŗȱ¢ȱŚȱ‘ž‹˜ȱŒŠ–‹’˜œȱŽ—ȱŽ•ȱŠ•ŒŠ—ŒŽȱ
¢ȱ›Ž™Ž›Œž’Ž›˜—ȱ™Š›ŠȱšžŽȱœŽȱ‘’Œ’Ž›Šȱž—Šȱ›Ž™•Š—’ęŒŠŒ’à—ȱ
de las HU a desarrollar durante cada iteración.
Como se mencionó, los cambios en el alcance del
proyecto también se monitorean en esta propuesta con
•Šȱ›¤ęŒŠȱŽȱŒŠ–‹’˜œȱŽ—ȱŽ•ȱŠ•ŒŠ—ŒŽDzȱ•Šȱꐞ›ŠȱŞȱ’•žœ›ŠȱŽ•ȱ
TSPCA, el cual permaneció menor que 30% del TBTP.
—ȱ•Šȱꐞ›ŠȱşȱœŽȱ™žŽŽȱŸŽ›ȱ•Šȱ̞ŒžŠŒ’à—ȱŽȱ•˜œȱǗ’-
ces CPI y SPI. En la tabla 3 se muestra la información
recabada durante cada iteración para poder realizar la
(7) ꐞ›Šȱşǯ
—ȱ•Šȱ’Ž›ŠŒ’à—ȱŜȱœŽȱ’—Ž›àȱŠ•ȱŽšž’™˜ȱŽȱŽœŠ››˜••˜ȱ
un miembro más para colaborar y terminar en tiempo
Ž•ȱ™›˜¢ŽŒ˜ǯȱŽȱŠ™›ŽŒ’ŠȱšžŽȱŽ•ȱȱŽ—ȱ•Šœȱ’Ž›ŠŒ’˜—ŽœȱŜȱ¢ȱ
7 es mayor que 1, por lo que el costo de SP fue mayor al
planeado. En la columna de SPI se aprecia que en las
’Ž›ŠŒ’˜—ŽœȱŜȱ¢ȱŝȱ•ŠȱŸŽ•˜Œ’ŠȱŽ•ȱŽšž’™˜ȱžŽȱ–Š¢˜›ȱŠȱ•Šȱ
™•Š—’ęŒŠŠǰȱ•˜ȱšžŽȱ™Ž›–’’àȱŽ›–’—Š›ȱŽ—ȱ’Ž–™˜ǯ
El costo real por iteración del proyecto se muestra
Ž—ȱ•ŠȱŠ‹•ŠȱŚǯȱ•ȱ™›ŽŒ’˜ȱ›ŽŠ•ȱŽ•ȱ™›˜¢ŽŒ˜ȱžŽȱŽȱ Ǟȱ ŘśŞǰȱ
şŘřǯŖŞȱ’—Œ›Ž–Ž—¤—˜œŽȱŽ—ȱž—ȱŘǯŝŚƖǯȱŽ‹’˜ȱŠȱšžŽȱŽ•ȱ
proyecto terminó en tiempo y con un presupuesto ma-
ǻŞǼ
¢˜›ȱŽ—ȱž—ȱŘǯŝŚƖǰȱ™žŽŽȱœŽ›ȱŒ˜—œ’Ž›Š˜ȱŒ˜–˜ȱŽ¡’˜œ˜ǯ
(VWLPDFLyQGHOFRVWR
En esta sección se presenta una técnica para estimar el
costo de un proyecto basándose en datos históricos de
la organización. Vale la pena aclarar que para planear
un nuevo proyecto, los datos históricos deben provenir
de proyectos con características similares en cuanto a la
tecnología, que se utilicen SP o alguna métrica semejan-
Žȱ ™Š›Šȱ œžȱ ™•Š—’ęŒŠŒ’à—ȱ ¢ȱ šžŽȱ Ž•ȱ Žšž’™˜ȱ Žȱ ŽœŠ››˜••˜ȱ
del nuevo producto sea maduro.
 Mitre-Hernández Hugo A., Ortega-Martínez Edgar, Lemus-Olalde Cuauhtémoc
La estimación de costos para el desarrollo de un
nuevo producto es una de las tareas más difíciles en in-
geniería de software, por lo que no es novedoso que en
métodos ágiles sea una tarea empírica y casi siempre
‹ŠœŠŠȱŽ—ȱ“ž’Œ’˜œȱŽȱŽ¡™Ž›˜œȱšž’Ž—ŽœȱŒ˜—ÇŠ—ȱŽ—ȱœžȱŠ–-
™•’ŠȱŽ¡™Ž›’Ž—Œ’Šǯ
La técnica propuesta en este artículo involucra el
uso de la información generada de proyectos desarro-
llados en una organización, por lo que cada organiza-
ción obtendrá resultados diferentes.
Para estimar el costo de un proyecto en esta pro-
puesta la base es el tiempo de desarrollo necesario,
por lo que el costo de un proyecto es directamente
proporcional al tiempo necesario para terminarlo. El
tiempo necesario para desarrollar una HU se obtiene
de datos históricos que se procesan utilizando la des-
Ÿ’ŠŒ’à—ȱ Žœ¤—Š›ȱ ¢ȱ ž—Šȱ ›¤ęŒŠȱ Œ˜—ȱ •Šȱ ŒŠ–™Š—Šȱ Žȱ
Šžœœȱ™Š›Šȱ’Ž—’ęŒŠ›ȱŽ•ȱ’Ž–™˜ȱ–¤œȱŒ˜—ꊋ•Žȱ™Š›Šȱ•Šœȱ
HU que tengan un mismo esfuerzo, es decir, cada con-
“ž—˜ȱŽȱ•Šœȱ
ȱŽœ’–ŠŠœȱŽ—ȱŞȱȱŽ—›¤—ȱŠœ’—Š˜œȱ
inherentemente un tiempo estimado para su desarro-
••˜ǰȱŠœÇȱŒ˜–˜ȱ•ŠœȱŽœ’–ŠŠœȱŽ—ȱŘȱǰȱŚȱǰȱŗřȱǰȱŘŖȱǰȱ
etcétera. Esta serie se considera, ya que se utiliza en la
planeación de métodos ágiles (Project Management
—œ’žŽǰȱŘŖŖřDzȱž•Š’–Š—ȱ¢ȱŠ›˜—ǰȱŘŖŖŜǼǰȱ™Ž›˜ȱŒŠŠȱ˜›-
ȱŒ˜—ȱŽœžŽ›£˜ȱŽȱŞȱǯ
ganización puede utilizar su propia serie de valores
relativos.
El tiempo de desarrollo de una HU se considera des-
de que un desarrollador la toma en la fase de desarro-
llo, hasta que el cliente la acepta. Los tiempos muertos
durante el proceso de desarrollo no deben contabilizar-
se, solo el tiempo invertido en trabajo sobre una HU.
Conocer el tiempo real de desarrollo de cada HU es
difícil y sería costoso que el equipo recabara esa infor-
mación de forma manual, por lo que se sugiere obtener
la información de herramientas desarrolladas con
BPMN que permiten la automatización de los procesos
de la organización y su completo monitoreo, herra-
)LJXUD Burn downGHLWHUDFLyQSDUDHOSUR\HFWR´6LVWHPD
GHJHVWLyQGHFRQWHQLGRVµ
Ingeniería Investigación y Tecnología, volumen XV (número 3), julio-septiembre 2014: 403-418 ISSN 1405-7743 FI-UNAM
mientas como BizAgi permiten obtener esta informa-
ción de una forma fácil y sin invertir mucho esfuerzo
para obtener información de calidad. Este artículo no
™›˜™˜—Žȱž—Šȱ‘Ž››Š–’Ž—Šȱ™Š›ŠȱŽ¡›ŠŽ›ȱŽ•ȱ’Ž–™˜ȱ™›ŽŒ’-
so de desarrollo por cada HU.
Para realizar esta técnica de estimación de costos es
necesario contar con la información de los tiempos his-
tóricos del desarrollo de HU de la organización agrupa-
˜œȱ œŽø—ȱ œžȱ ŽœžŽ›£˜ǰȱ Žȱ ˜›–Šȱ œ’–’•Š›ȱ Šȱ •Šȱ šžŽȱ œŽȱ
–žŽœ›ŠȱŽ—ȱ•ŠȱŠ‹•Šȱśǯ
—ȱ•ŠȱŠ‹•ŠȱśȱœŽȱŠ™›ŽŒ’Š—ȱ•˜œȱ’Ž–™˜œȱŠœŠ˜œȱŽ—ȱ‘˜-
ras y agrupados por esfuerzo para las HU de un pro-
yecto. Se comprobó que tener un rango muy amplio
entre los tiempos de desarrollo arroja menor precisión
Š•ȱ ›ŠęŒŠ›ȱ •Šȱ ’œ›’‹žŒ’à—ȱ —˜›–Š•ȱ ™Š›Šȱ •Šȱ ŒŠ–™Š—Šȱ Žȱ
Gauss, es por eso que se sugiere que los tiempos se cap-
turen con valores que respeten una serie, con incremen-
tos de un cuarto de hora, es decir, podremos representar
el tiempo de las HU con la siguiente serie y sus combi-
—ŠŒ’˜—ŽœDZȱŖǯŘśȱ‘˜›ŠŠǰȱŖǯśȱ‘˜›ŠœǰȱŖǯŝśȱ‘˜›Šœǰȱŗȱ‘˜›Šǯ
Con esta serie de tiempos se tiene la información
más agrupada en la campana de Gauss lo que permite
Ž—Ž›ȱ–Š¢˜›ȱ™›ŽŒ’œ’à—ǯȱ—ȱ•ŠȱŠ‹•ŠȱŜȱœŽȱ–žŽœ›Šȱž—ȱŽ“Ž–-
plo de la forma en que se verían los tiempos invertidos
™Š›Šȱ•Šœȱ
Con la información de los tiempos de desarrollo
Œ˜–˜ȱŽ—ȱ•ŠȱŠ‹•ŠȱŜǰȱŽ•ȱœ’ž’Ž—Žȱ™Šœ˜ȱŽœȱŒŠ•Œž•Š›ȱ•Šȱ–Ž-
dia, la varianza (S2) y la desviación estándar (S).
Calcular la varianza del conjunto de tiempos por
cada conjunto de esfuerzos servirá para conocer su
’œ™Ž›œ’à—ǰȱ•ŠȱŸŠ›’Š—£ŠȱœŽȱŽę—ŽȱŒ˜–˜ȱ•Šȱ–Ž’ŠȱŽȱ•Šœȱ
diferencias cuadráticas de n puntuaciones con respec-
to a su media aritmética y se obtiene con la siguiente
fórmula:
1 n
S2 ¦ ( x  x )2
ni1 i
(10)
donde ¡i es el tiempo para una HU, n es el total de datos
de la muestra y ¡Ɉ la media del conjunto de datos.
La desviación estándar del conjunto de datos hará
que la medida de dispersión sea de la misma dimensión
que las muestras, en este caso horas, se obtiene sacando
la raíz cuadrada de S.
S S2 (11)
Los valores de la media, de S2 y de S para el conjunto de
Š˜œȱŽȱ•ŠȱŠ‹•ŠȱŜȱœŽȱ–žŽœ›Š—ȱŽ—ȱ•ŠȱŠ‹•Šȱŝǯ
Utilizando la distribución normal para los tiempos
de un conjunto de HU con el mismo esfuerzo nos per-
mitirá una mejor entropía entre los tiempos recolecta-
dos para el conjunto de HU con esfuerzos iguales.
411
 Estimación y control de costos en métodos ágiles para desarrollo de software: un caso de estudio

La distribución normal se calcula con la siguiente fór- donde ¡ȱes un tiempo del conjunto de las HU con mismo
mula: esfuerzo, μ es la media o ¡ȱy V es la desviación estándar
§ ( N P )1 ·
¨ ¸
o S.
1 ¨ 2 V2 ¸
f ( x , P , V) e © ¹ (12) —ȱ•ŠȱŠ‹•ŠȱŞȱœŽȱŒŠ•Œž•Šȱ•Šȱ’œ›’‹žŒ’à—ȱ—˜›–Š•ȱ™Š›Šȱ•Šȱ
2 SV ¡ȱ ¢ȱ •Šȱ ȱ ˜‹Ž—’Šœȱ Œ˜—ȱ •Šȱ ’—˜›–ŠŒ’à—ȱ Žȱ •Šȱ Š‹•Šȱ Ŝǯȱ Šȱ
Œ˜•ž–—Šȱ Žȱ ›ž™˜œȱ –žŽœ›Šȱ Ž•ȱ ›Š—˜ȱ ’Ž—’ęŒŠ˜ȱ Žȱ
’Ž–™˜œȱ™Š›Šȱ•Šœȱ
ȱŽȱŞȱœȱŽȱ•ŠȱŠ‹•ŠȱŜǯ
—ȱ •Šȱ ꐞ›Šȱ ŗŖȱ œŽȱ –žŽœ›Šȱ •Šȱ ŒŠ–™Š—Šȱ Žȱ Šžœœȱ ˜ȱ
distribución normal para los tiempos de HU de un pro-
¢ŽŒ˜ȱŒ˜—ȱŽœžŽ›£˜ȱŽȱŞȱǯȱ—ȱŽ••ŠȱœŽȱ™žŽŽȱŠ™›ŽŒ’Š›ȱšžŽȱ
™Š›Šȱž—Šȱ¡ȱŽȱŗȱ‘˜›ŠȱœŽȱ’Ž—Žȱž—ȱŸŠ•˜›ȱ–ž¢ȱŒŽ›ŒŠ—˜ȱŠȱŗǰȱ
•˜ȱšžŽȱœ’—’ęŒŠȱšžŽȱ™Š›Šȱž—Šȱ
ȱŽȱŞȱȱŒ˜—ȱ¡ȱ¢ȱȱ˜‹Ž-
—’Šœȱ Žȱ •˜œȱ ‘’œà›’Œ˜œȱ –˜œ›Š˜œȱ Ž—ȱ •Šȱ Š‹•Šȱ ŗŗȱ Ž¡’œŽȱ
şŗǯřƖȱŽȱ™›˜‹Š‹’•’ŠȱŽȱšžŽȱŽ•ȱŽœžŽ›£˜ȱ—ŽŒŽœŠ›’˜ȱ™Š›Šȱ
su desarrollo sea de 1 hora.
Con la campana de Gauss podemos conocer el tiem-
po con mayor precisión de la serie de valores históricos
Žȱ•Šœȱ
ȱŽ—ȱž—ȱŽœžŽ›£˜ȱŽŽ›–’—Š˜ȱǻŽ“ǯȱŞȱǼǰȱ’Ž—-
’ęŒŠ—˜ȱŽ•ȱŸŠ•˜›ȱ™›ŽŒ’œ˜ȱŒ˜–˜ȱ•ŠȱY más alta en la cur-
)LJXUD 763&$SDUDHOSUR\HFWR´6LVWHPDGHJHVWLyQGH
FRQWHQLGRVµ va. De esta forma, para estimar el costo de un nuevo
™›˜¢ŽŒ˜ȱ™˜Ž–˜œȱŒ˜—ꊛȱŽ—ȱ•˜œȱŠ˜œȱ‘’œà›’Œ˜œȱŽȱ•˜œȱ
tiempos de desarrollo invertidos en las HU con esfuer-
zos iguales.

Caso de estudio

El presente caso de estudio se diseña de tal forma que

pueda presentar las discusiones respecto a dos proyec-
tos de una empresa de software utilizando el método de
medición propuesto. Primero, se da una motivación
señalizando el foco del problema, el objetivo de la in-
vestigación y el problema. Después se presentan los
›Žœž•Š˜œȱŽȱ•Šœȱ›¤ęŒŠœȱŽ•ȱ–·˜˜ȱŽȱ–Ž’Œ’à—ȱ¢ȱ•Šœȱ
interpretaciones de sus resultados, así como también
)LJXUDÌQGLFHV&3,\63,SDUDHOSUR\HFWR´6LVWHPDGHJHVWLyQ
GHFRQWHQLGRVµ
•Šœȱ’œŒžœ’˜—Žœȱœ˜‹›Žȱ•Šœȱ’ęŒž•ŠŽœȱ¢ȱ™›˜‹•Ž–Šœȱ™›Ž-
sentados en el estudio.

7DEOD&3,\63,GHOSUR\HFWR´6LVWHPDGHJHVWLyQGHFRQWHQLGRVµ 7DEOD&RVWRUHDOSRULWHUDFLyQ
HQHOSUR\HFWR
Costo por SP Costo replaneado
Iteración planeado siguiente iteración Costo real CPI SPI Iteración Costo Real
0 1 1 1 ǞȱřŜǰŖŖŖǯŖŖ
1 śŗŚǯŘŞśŝŗŚř śŞŖǯřŗŜŝŚŘŗ ŖǯşŝŗŚŘŞśŝŗ ŖǯşŝŗŚŘŞśŝŗ 2 ǞȱřŜǰŖŖŖǯŖŖ

2 śŗŚǯŘŞśŝŗŚř ŚŜŝǯśřŘŚŜŝś śŘŗǯŝřşŗřŖŚ ŖǯşŞśŝŗŚŘŞŜ ŖǯşŞśŝŗŚŘŞŜ 3 ǞȱřŜǰŖŖŖǯŖŖ

3 śŗŚǯŘŞśŝŗŚř ŚŜŗǯśřŞŚŜŗś ŚśśǯŜşŜŘŖŘś ŗǯŗŘŞśŝŗŚŘş ŗǯŗŘŞśŝŗŚŘş Ś ǞȱřŜǰŖŖŖǯŖŖ

Ś śŗŚǯŘŞśŝŗŚř ŚŞŜǯŚŞŜŚŞŜś ŚŞŜǯŚŞŜŚŞŜś ŗǯŖśŝŗŚŘŞśŝ ŗǯŖśŝŗŚŘŞśŝ ś ǞȱřŜǰŖŖŖǯŖŖ

ś śŗŚǯŘŞśŝŗŚř ŚŖŚǯŚşŚřŞŘ śşŖǯŗŜřşřŚŚ ŖǯŞŝŗŚŘŞśŝŗ ŖǯŞŝŗŚŘŞśŝŗ Ŝ ǞȱřşǰŚŜŗǯśŚ

Ŝ śŗŚǯŘŞśŝŗŚř ŚŚŞǯŚŘŜśŝřŚ ŚŞŝǯŗŝşŚŞŝŘ ŗǯŖśśŜřşŖşŞ ŗǯŗśŝŗŚŘŞśŝ 7 ǞȱřşǰŚŜŗǯśŚ

7 śŗŚǯŘŞśŝŗŚř ŚŚŞǯŚŘŜśŝřŚ ŗǯŗŚŜŞŜŝŗŜŞ ŗǯŘśŝŗŚŘŞśŝ ǞȱŘśŞǰşŘřǯŖŞ

412 Ingeniería Investigación y Tecnología, volumen XV (número 3), julio-septiembre 2014: 403-418 ISSN 1405-7743 FI-UNAM
 Mitre-Hernández Hugo A., Ortega-Martínez Edgar, Lemus-Olalde Cuauhtémoc
Motivación
Para informar al lector del foco y el alcance del presente
trabajo, a continuación se presenta el problema y los ob-
jetivos de investigación, además de los fundamentos
™Š›Šȱ•ŠȱŒ˜–™›Ž—œ’à—ȱŽ•ȱŒ˜—Ž¡˜ȱŽ•ȱŠ›ÇŒž•˜ǯ
Establecimiento del problema
En este artículo se tomaron en cuenta los siguientes
problemas para los administradores de proyectos y e¡™Ž›-
tos en metodologías ágiles para el desarrollo de software:
1. Varios autores han encontrado una necesidad clara
de los gestores de proyectos de software en métodos
¤’•Žœǯȱ¡’œŽȱž—Šȱescasa gestión y monitoreo de costos
Ž—ȱ–·˜˜œȱ¤’•ŽœȱǻŠ™ǰȱŘŖŖŜDzȱ
ŽŠŸŽ—Ž¢ȱ¢ȱ˜—‹˜¢ǰȱ el desarrollo de dos proyectos de software en una peque-
ŘŖŖŜDzȱž•Š’–Š—ȱ¢ȱŠ›˜—ǰȱŘŖŖŜDzȱžœ”ǰȱŘŖŖşǼǯ
2. Otros autores indican que hay poca evidencia acerca de
la medición de los costos de un proyecto para los ad-
En suma, el problema es la falta de una efectiva gestión,
–˜—’˜›’£ŠŒ’à—ǰȱŽ—Ž›ŠŒ’à—ȱŽȱŽŸ’Ž—Œ’Šœȱ¢ȱŽœ’–ŠŒ’˜—Žœȱ‹Š-
œŠŠœȱ Ž—ȱ ™›˜ŒŽœ˜œȱ –Ž“˜›Š‹•Žœȱ Ž—ȱ Œ˜œ˜œȱ ™Š›Šȱ ™›˜¢ŽŒ˜œȱ Žȱ
software desarrollados con métodos ágiles. Los principales
afectados son los administradores de proyectos, los
Ž¡™Ž›˜œȱŽ—ȱ–·˜˜œȱ¤’•Žœȱ¢ȱ•˜œȱžŽÛ˜œȱŽȱ•ŠœȱŽ–™›Ž-
sas de desarrollo de SW, con respecto a la pérdida de
costos, precisión en los tiempos y compromisos con el
cliente.
Objetivo de investigación
El objetivo de esta investigación es analizar el control,
monitorización y generación de evidencias por parte de los
desarrolladores y los administradores de proyectos durante
ña empresa del ramo. Su propósito es descubrir las ’ę-
Œž•ŠŽœȱ˜ȱ™›˜‹•Ž–Šœ con respecto al uso de la propuesta
en cuanto a la pérdida de costos, precisión en los tiempos,
–’—’œ›Š˜›ŽœȱŽȱ™›˜¢ŽŒ˜œȱǻ˜—ŽœǰȱŘŖŖŚDzȱž•Š’–Š—ȱ¢ȱ imprevistos y compromisos con el cliente, desde la perspec-
Š›˜—ǰȱŘŖŖŜDzȱȱžœ”ǰȱŘŖŖşǼǯ tiva de un administrador de proyectosȱŽ—ȱŽ•ȱŒ˜—Ž¡˜ȱŽ•ȱ
3. La estimación de costos en métodos ágiles se basa co- uso de métodos ágiles.
–ø—–Ž—Žȱ Ž—ȱ “ž’Œ’˜œȱ Žȱ Ž¡™Ž›˜œȱ ¢ȱ —˜ȱ Ž—ȱ procesos
›Ž™Ž’‹•Žœȱ ¢ȱ –Ž“˜›Š‹•Žœȱ ǻ
ŽŠŸŽ—Ž¢ȱ ¢ȱ ˜—‹˜¢ǰȱ ŘŖŖŜDzȱ Contexto
‘Š–ȱǯȱ¢ȱ‘Š–ȱǯǰȱŘŖŗŗǼǯȱ’—ȱž—ȱ™›˜ŒŽœ˜ȱ‹’Ž—ȱŽę-
nido y medible, no es posible lograr una optimiza- El estudio se llevó a cabo en una pequeña empresa de
ción ni la reducción de costos. desarrollo de software basado en procesos ágiles, especí-
ꌊ–Ž—Žȱ Ž—ȱ Scrum y eXtreme Programming. Dos pro-
7DEOD7LHPSRVDJUXSDGRVSRUHVIXHU]RSDUDXQSUR\HFWR yectos de software fueron parte del estudio:
Conjunto Conjunto Conjunto Conjunto Conjunto Ȋȱȱȱ •ȱprimer proyecto (P1) fue el desarrollo de un soft-
esfuerzo 2 ŽœžŽ›£˜ȱŚ ŽœžŽ›£˜ȱŞ esfuerzo 13 esfuerzo 20
ware como servicio (SaaS, Software as a Service) para
1.10 7.00 śǯŘ ŗşǯŘ ŘřǯŜ
gestionar la red de colaboración entre la triple hélice
ŗǯŜŖ 7.00 ŗŜ Řŝǯś řŗǯŚ (gobierno, industria y academia). Se registraron en
ŗǯŚś 7.00 Şǯř 23 37.2 el equipo un total de 7 desarrolladores, un total de
ŗřǯŚŖ 7.00 şǯŘ ŘŞǯŞ řśǯŗ ŝśȱ
ȱ ™•Š—’ęŒŠŠœǰȱ ŘŘȱ ȱ ™˜›ȱ ’Ž›ŠŒ’à—ǰȱ ž—ȱ Œ˜œ˜ȱ
ŚǯśŖ Ş ŝǯś ŗśǯŗ řŖǯś ‹ŠœŽȱŽȱǞŗŘŞǯŜŞȱ™Žœ˜œȱ–Ž¡’ŒŠ—˜œȱ™˜›ȱŒŠŠȱȱǻŽ•ȱŒ˜œ-
ŜǯśŖ ŝǯś 11.7 23.2 ŚŘ to no contiene impuestos ni ganancias para la em-
3.10 7 Řřǯś ™›ŽœŠǼȱ¢ȱŽ•ȱ™Ž›’˜˜ȱŽȱŽœŠ››˜••˜ȱžŽȱŽ•ȱŚȱŽȱ“ž—’˜ȱŠ•ȱ
řǯŜŖ Ş 17.2 ŞȱŽȱŠ˜œ˜ǯȱ—ȱŽœŽȱ™›˜¢ŽŒ˜ȱœŽȱž’•’£àȱ•Šȱ™›˜™žŽœŠȱ
2.00 7 21.2 de estimación y control de costos.
7 ŗřǯś Ȋȱȱȱ •ȱ segundo proyecto (P2) fue el desarrollo de una
Ŝ 12.1 herramienta de diseño y seguimiento de indicado-
ŝǯś 21.3 ›Žœǰȱ˜—ŽȱœŽȱŽę—’Ž›˜—ȱ’Ž›ŠŒ’˜—ŽœȱŽȱž›ŠŒ’à—ȱœŽ-
7 ŗşǯŜ –Š—Š•ǰȱŒ˜—ȱŚȱ’Ž›ŠŒ’˜—Žœȱ™•Š—’ęŒŠŠœǯȱŽȱ›Ž’œ›àȱŽ—ȱ
Ş ŗŗǯŚ Ž•ȱ Žšž’™˜ȱ ž—ȱ ˜Š•ȱ Žȱ Şȱ ŽœŠ››˜••Š˜›Žœȱ ž›Š—Žȱ Ž•ȱ
Ş ŗśǯř ™›˜ŒŽœ˜ǰȱŚŝȱ‘’œ˜›’ŠœȱŽȱžœžŠ›’˜ȱ™•Š—ŽŠŠœǰȱž—ŠȱŽœ’-
7 ŗŞǯŝ –ŠŒ’à—ȱ Žȱ ŘŜřȱ ™ž—˜œȱ Žȱ ‘’œ˜›’Šǰȱ ž—Šȱ ŸŽ•˜Œ’Šȱ
7 21.1 ‹ŠœŽȱ Žȱ Ŝşȱ ȱ ™˜›ȱ ’Ž›ŠŒ’à—ȱ ¢ȱ ž—ȱ Œ˜œ˜ȱ ‹ŠœŽȱ Žȱ
Ŝ ŘśǯŜ ǞŗŘŞǯŜŞȱ™Žœ˜œȱ–Ž¡’ŒŠ—˜œȱ™˜›ȱŒŠŠȱǯȱ—ȱŽœŽȱ™›˜-
7 17 yecto no se utilizó la propuesta de estimación y con-
ŝǯś ŘśǯŘ ›˜•ȱ Žȱ Œ˜œ˜œȱ Ž•ȱ ™›ŽœŽ—Žȱ Š›ÇŒž•˜ǯȱ ˜›ȱ ø•’–˜ǰȱ Ž•ȱ

Ingeniería Investigación y Tecnología, volumen XV (número 3), julio-septiembre 2014: 403-418 ISSN 1405-7743 FI-UNAM 413
 Estimación y control de costos en métodos ágiles para desarrollo de software: un caso de estudio

™Ž›’˜˜ȱŽȱŽœŠ››˜••˜ȱžŽȱŽ•ȱŘśȱŽȱœŽ™’Ž–‹›ŽȱŠ•ȱŞȱ Žȱ ™•Š—ŽŠŒ’à—Dzȱ Ž•ȱ ŠŸŠ—ŒŽȱ 7DEOD7LHPSRV

de noviembre. real, que muestra el valor ga- KLVWyULFRVGHOSUR\HFWR
SDUD+8VFRQHVIXHU]R
nado durante cada iteración,
GH63XWLOL]DQGRODVHULH
así como los cambios en el
Análisis e interpretación SURSXHVWDGHWLHPSRV
alcance, mostrando picos
ȱ Œ˜—’—žŠŒ’à—ȱ œŽȱ ™›ŽœŽ—Š—ȱ •˜œȱ ›Žœž•Š˜œȱ ꗊ•Žœȱ Žȱ cuando el alcance crece o se Conjunto de tiempos
•˜œȱ™›˜¢ŽŒ˜œȱŽ—ȱ•Šœȱ›¤ęŒŠœȱŒ˜››Žœ™˜—’Ž—Žœǯȱ agrega esfuerzo al desarrollo ™Š›ŠȱŽœžŽ›£˜ȱŞ
•ȱ™›˜¢ŽŒ˜ȱŗȱ—˜ȱŽ—Ž›àȱ•˜œȱœžęŒ’Ž—ŽœȱŠ˜œȱ™Š›Šȱ ¢ȱ Ž•ȱ ŠŸŠ—ŒŽȱ ›ŽȬ™•Š—’ęŒŠ˜ǰȱ 1.00
Ž—Ž›Š›ȱ •Šœȱ ›¤ęŒŠœȱ Žȱ Žœ’–ŠŒ’˜—Žœȱ Žȱ ŽœžŽ›£˜œǰȱ ¢Šȱ que muestra el avance repla- 1.00
šžŽȱ—˜ȱœŽȱŒ˜—Š‹ŠȱŒ˜—ȱŠ˜œȱ‘’œà›’Œ˜œȱœžęŒ’Ž—Žœǯȱ’—ȱ —’ęŒŠ˜ȱ™Š›ŠȱŒŠŠȱ’Ž›ŠŒ’à—ǯȱ ȱȱȱȱȱȱȱȱȱȱȱȱȱȱŖǯśŖ
Ž–‹Š›˜ǰȱ •Šȱ Žœ’–ŠŒ’à—ȱ Žȱ •˜œȱ Ž¡™Ž›˜œȱ žŽȱ œžęŒ’Ž—Žǰȱ Como se puede apreciar en 1.00
ya que este era un diseño de desarrollo conocido por el los resultados, el avance real
ȱȱȱȱȱȱȱȱȱȱȱȱȱȱŗǯś
Œ•’Ž—Žǯȱ Šœȱ ›¤ęŒŠœȱ Ž—Ž›ŠŠœȱ Ž•ȱ –·˜˜ȱ ™›˜™žŽœ˜ȱ fue más rápido de lo planea-
do debido al conocimiento 1
œ˜—ȱ•Šȱ›¤ęŒŠȱ‹ž›—ȱ˜ — al cierre del proyecto, como se
™žŽŽȱŠ™›ŽŒ’Š›ȱŽ—ȱ•Šȱꐞ›Šȱŗŗǰȱ¢ȱ•Šȱ›¤ęŒŠȱȦȱŠ–- de la solución del sistema, es ȱȱȱȱȱȱȱȱȱȱȱȱȱȱŗǯŘś
‹’·—ȱŠ•ȱŒ’Ž››ŽȱŽ•ȱ™›˜¢ŽŒ˜ȱŽ—ȱ•Šȱꐞ›ŠȱŗŘǯ decir, un sistema bastante 1
ŠœȱœŽ›’ŽœȱŽȱŠ˜œȱŽȱ•Šȱ›¤ęŒŠȱ‹ž›—ȱ˜ — se descri- Œ˜—˜Œ’˜ȱ ™˜›ȱ •˜œȱ Ž¡™Ž›˜œȱ ȱȱȱȱȱȱȱȱȱȱȱȱȱȱŖǯŝś
ben como el avance planeado, que muestra el esfuerzo respecto a las entrevistas con ȱȱȱȱȱȱȱȱȱȱȱȱȱȱŖǯś
restante para su desarrollo, obtenido durante la etapa el cliente. Es por esto que no
ȱȱȱȱȱȱȱȱȱȱȱȱȱȱŖǯś
žŽȱ —ŽŒŽœŠ›’Šȱ ž—Šȱ ›Ž™•Š—’ę-
ȱȱȱȱȱȱȱȱȱȱȱȱȱȱŗǯŘś
cación. Este método de me-
dición es de mayor utilidad ȱȱȱȱȱȱȱȱȱȱȱȱȱȱŗǯś
para proyectos en donde se 1
desconoce el problema para ȱȱȱȱȱȱȱȱȱȱȱȱȱȱŖǯś
poder tomar decisiones res- ȱȱȱȱȱȱȱȱȱȱȱȱȱȱŖǯŝś
™ŽŒ˜ȱŠȱ•Šœȱ›Ž™•Š—’ęŒŠŒ’˜—Žœǰȱ ȱȱȱȱȱȱȱȱȱȱȱȱȱȱŗǯŝś
como resultados esperados
ȱȱȱȱȱȱȱȱȱȱȱȱȱȱŗǯŘś
de esfuerzo.
Žœ™ŽŒ˜ȱŠȱ•Šȱ›¤ęŒŠȱŽȱȦ 2
SPI en el cierre del proyecto ȱȱȱȱȱȱȱȱȱȱȱȱȱȱŖǯś
ǻꐞ›Šȱ ŗŘǼǰȱ —˜ȱ –žŽœ›Šȱ ›Ž- 1
sultados inesperados con-
forme al tiempo y al costo,
fueron resultados controla-
)LJXUD 'LVWULEXFLyQQRUPDOSDUDORVWLHPSRVGH+8VFRQ dos en todo momento. Los
HVIXHU]RGH63
resultados fueron, por lo 7DEOD9DORUHVGH[
mismo, una solución cono- 6\6SDUDHOFRQMXQWR
cida y entendida por las ne- GHWLHPSRVGH+8VFRQ
cesidades del cliente. Por HVIXHU]RGH63GHOD
WDEOD
ø•’–˜ǰȱ —˜ȱ œŽȱ Ž—Ž›àȱ ž—Šȱ
›¤ęŒŠȱȱŽ‹’˜ȱŠȱšžŽȱ X 1.03
no se creó un valor agrega- S2 ŖǯŗşŖŗřŗśŝş
do a las historias de usuario S ŖǯŚřŜŖŚŖŞ
durante el desarrollo del
proyecto.
En el segundo proyecto,
al igual que en el primero,
Šø—ȱ—˜ȱœŽȱŽ—ÇŠ—ȱ•˜œȱœžęŒ’Ž—ŽœȱŠ˜œȱ‘’œà›’Œ˜œȱ™Š›ŠȱŽ-
—Ž›Š›ȱ•ŠœȱŽœ’–ŠŒ’˜—Žœȱœ˜‹›Žȱ•˜œȱŽœžŽ›£˜œǯȱŠȱ›¤ęŒŠȱŽȱ
la que se parte para la toma de decisiones es la ‹ž›—ȱ
downȱŽ—ȱ•ŠȱšžŽȱœŽȱ–žŽœ›Š—ȱ•Šœȱ’ęŒž•ŠŽœȱŽȱŒ˜—›˜•ǰȱ
)LJXUD Burn downDOFLHUUHGHOSUR\HFWR3 ™›’—Œ’™Š•–Ž—ŽȱŽȱ•ŠȱœŽž—Šȱ’Ž›ŠŒ’à—ȱŠȱ•Šȱšž’—ŠDzȱ™Š›Šȱ

414 Ingeniería Investigación y Tecnología, volumen XV (número 3), julio-septiembre 2014: 403-418 ISSN 1405-7743 FI-UNAM
 Mitre-Hernández Hugo A., Ortega-Martínez Edgar, Lemus-Olalde Cuauhtémoc

7DEOD'LVWULEXFLyQQRUPDOSDUDODx \6SDUDHOJUXSRGH
WLHPSRVGH+8VFRQ63LGHQWLILFDGRVHQODWDEOD

Grupos Distribución Normal

0 ŖǯŖśŝŝřşŞŗř
ŖǯŘś ŖǯŗŞŞśŚśŘřř
Ŗǯś ŖǯŚŚřŗşŚŝŗş
Ŗǯŝś ŖǯŝŚşşŗśŜŞŘ
1 ŖǯşŗřŚŗŝŖŞş
ŗǯŘś ŖǯŞŖŖŞŝŚŞŝŘ
ŗǯś ŖǯśŖśŚŝŚŘśś
ŗǯŝś ŖǯŘŘşŜśřŖŜş )LJXUD. &3,63,DOFLHUUHGHOSUR\HFWR3
2 ŖǯŖŝśŗŖŝŜŝŘ

ŽŽŒ˜œȱ Žȱ Ž—Œ˜—›Š›ȱ •Šœȱ ’ęŒž•ŠŽœȱ ¢ȱ ™›˜‹•Ž–Šœȱ Ž•ȱ

método de medición se discuten dichas iteraciones. Las
›¤ęŒŠœȱ ž’•’£ŠŠœȱ œ˜—ȱ •Šœȱ Žȱ •Šȱ ꐞ›Šȱ ŗřȱ Œ˜—ȱ •Šȱ ‹ž›—ȱ
downȱŠ•ȱŒ’Ž››ŽȱŽ•ȱ™›˜¢ŽŒ˜ǰȱ•Šȱꐞ›ŠȱŗŚǰȱŒ˜—ȱ›¤ęŒŠȱȦ
ȱŠ•ȱŒ’Ž››ŽȱŽ•ȱ™›˜¢ŽŒ˜ǰȱ¢ȱ•Šȱꐞ›ŠȱŗśȱŒ˜—ȱ•Šȱ›¤ęŒŠȱ
TSPCA para el cierre del proyecto.
A continuación se describen las discusiones de los
™›˜‹•Ž–Šœȱ ¢ȱ •Šœȱ ’ęŒž•ŠŽœȱ Žȱ •Šœȱ ’Ž›ŠŒ’˜—Žœȱ Ž—ȱ Ž•ȱȱ
proyecto.
)LJXUD Burn downDOFLHUUHGHOSUR\HFWR3
Iteración 2
El esfuerzo que el equipo estimó desarrollar en esta ite-
›ŠŒ’à—ȱžŽȱŽȱŜŜȱǰȱ™Ž›˜ȱ›ŽŠ•–Ž—ŽȱŽ•ȱValor Ganado (EV)
žŽȱśŖȱǯȱœŽȱ›Žœž•Š˜ȱŽ—ȱȱ’Ž—Žȱž—ȱ’–™ŠŒ˜ȱ’›ŽŒ˜ȱ
Ž—ȱŽ•ȱŒ˜œ˜DzȱŽ•ȱǗ’ŒŽȱŽ•ȱŽœŽ–™ŽÛ˜ȱŽ•ȱŒ˜œ˜ȱǻǼȱ™Š›Šȱ
esta iteración fue 0.73, lo que muestra que el costo por
SP fue más caro que el valor planeado, teniendo un cos-
˜ȱŽȱǞŗŝśǯŖŖǰȱřŜƖȱ–¤œȱŒŠ›˜ȱ™Š›ŠȱŽ•ȱŽœŠ››˜••˜ȱŽȱž—ȱǯȱ
Además, el índice del desempeño del calendario (SPI)
fue 0.73, indicando que el equipo desarrolló más lento
Žȱ•˜ȱ™•Š—ŽŠ˜ǰȱŽœȱŽŒ’›ǰȱŘŚǯŘŚƖȱ–¤œȱ•Ž—˜ǯȱ•ȱ™›˜‹•Ž–Šȱ
fue que no se estimó de una forma precisa la velocidad
de desarrollo y no se estimaron los riesgos de nuevas
)LJXUD &3,63,$OFLHUUHGHOSUR\HFWR3
tecnologías adquiridas en la empresa.
Al cierre de la iteración 2, el equipo se reunió con el
Iteración 3
cliente para mostrar los avances y obtener alguna re-
troalimentación acerca de las tareas desarrolladas. Al inicio de la iteración 3 el alcance del proyecto ya ha-
˜–˜ȱ ›Žœž•Š˜ȱ œŽȱ Š›ŽŠ›˜—ȱ ŗřśȱ ȱ Œ˜–˜ȱ ŽœŒž‹›’- ‹ÇŠȱŠž–Ž—Š˜ȱśŚȱƖǰȱ™˜›ȱ•˜ȱšžŽȱœŽȱŠ›ŽŠ›˜—ȱ˜œȱŽœŠ-
–’Ž—˜ȱŽȱ—žŽŸŠœȱŽŸ’Ž—Œ’ŠœǰȱšžŽȱ›Ž™›ŽœŽ—Š›˜—ȱśŗǯřƖȱ rrolladores más al equipo para aumentar la produc-
del total del producto planeado, lo que ponía en riesgo tividad de SP en el proyecto. El impacto en el costo de
la terminación en tiempo y costo del desarrollo del pro- Š›ŽŠ›ȱ Šȱ ˜œȱ ŽœŠ››˜••Š˜›Žœȱ žŽȱ ŜŞƖȱ –¤œȱ ŒŠ›˜ȱ ™Š›Šȱ
ducto, además de que la velocidad de desarrollo era ŽœŠȱ ’Ž›ŠŒ’à—ǯȱ —ȱ ŽœŽȱ ™›˜¢ŽŒ˜ȱ ›Š‹Š“àȱ Ž•ȱ Žšž’™˜ȱ ŘDzȱ Š•ȱ
más lenta. Por estas razones se decidió agregar 2 desa- ·›–’—˜ȱŽȱ•Šȱ’Ž›ŠŒ’à—ȱ•ŠȱŸŽ•˜Œ’ŠȱŽȱŽœŠ››˜••˜ȱžŽȱŜşȱ
rrolladores más al inicio de la tercera iteración. SP, acorde a lo esperado en el plan, dicho de otra forma,

Ingeniería Investigación y Tecnología, volumen XV (número 3), julio-septiembre 2014: 403-418 ISSN 1405-7743 FI-UNAM 415
 Estimación y control de costos en métodos ágiles para desarrollo de software: un caso de estudio
)LJXUD 763&$SDUDHOFLHUUHGHOSUR\HFWR3
el SPI tuvo un valor igual a 1, ya que el equipo avanzó
Œ˜—˜›–ŽȱŠȱ•Šȱ™•Š—ŽŠŒ’à—ȱ’—’Œ’Š•ǯȱž–Ž—Š›ȱŽ•ȱ—ø–Ž›˜ȱ
de desarrolladores incrementó el costo de la iteración y
Ž•ȱŒ˜œ˜ȱŽȱŽœŠ››˜••˜ȱŽȱž—ȱǰȱŽ•ȱȱžŽȱŖǯŜŜǰȱŽ•ȱŒžŠ•ȱ
ŽŸ’Ž—Œ’ŠȱŽ•ȱŠž–Ž—˜ȱŽ—ȱŽ•ȱŒ˜œ˜ǰȱŜŜƖȱ–¤œȱŒŠ›˜ǯ
En el cierre de la iteración, al mostrar los avances al
cliente, fue aumentado el alcance debido a nuevos ha-
llazgos y características necesarias para el sistema, el
total de SP agregados fue 120. Esta repercusión es nota-
‹•ŽȱŸ’œžŠ•’£Š—˜ȱ•Šȱ›¤ęŒŠȱŽ•ȱ‹ž›—ȱ˜ — para este pro-
¢ŽŒ˜ǰȱ¢ŠȱšžŽȱŽ•ȱŽšž’™˜ȱŽœ™Ž›Š‹ŠȱŽ—Ž›ȱž—ȱ›ŽœŠ—ŽȱŽȱśşȱ
ȱ™Ž›˜ȱœž‹’àȱŠȱřŝŞȱȱŽ•ȱŸŠ•˜›ȱ›ŽŠ•ǯȱ˜–Š—˜ȱŽ—ȱŒžŽ—Šȱ
estos valores el remanente al cierre de la iteración 3 se
ž™•’ŒàǰȱŽ—ȱ•Šȱꐞ›ŠȱŗřȱœŽȱ˜‹œŽ›ŸŠȱž—ȱŠž–Ž—˜ȱŽȱŗŖŖƖȱ
más respecto al valor planeado.
Iteración 4
En esta iteración el encargado del desarrollo, agregó un
ŽœŠ››˜••Š˜›ȱ–¤œǰȱŒ˜–™•ŽŠ—˜ȱ•˜œȱŞȱŽœŠ››˜••Š˜›ŽœȱŽ•ȱ
Žšž’™˜ǰȱŽœ˜ȱ˜ŒŠœ’˜—àȱšžŽȱœž‹’Ž›ŠȱŽ•ȱŒ˜œ˜ȱ™˜›ȱŽ•ȱ—ø–Ž›˜ȱ
Žȱ’—Ž›Š—Žœǯȱ•ȱŸŠ•˜›ȱŠ—Š˜ȱŽ—ȱŽœŠȱ’Ž›ŠŒ’à—ȱžŽȱşŘȱǰȱ
řśƖȱ–¤œȱ›¤™’˜ȱŽ—ȱœžȱŽœŠ››˜••˜ȱŒ˜—ȱž—ȱȱŽšž’ŸŠ•Ž—ŽȱŠȱ
ŗǯřśǯȱ •ȱ Œ˜œ˜ȱ Šœž–’˜ȱ ™Š›Šȱ ŽœŠȱ ’Ž›ŠŒ’à—ȱ žŽȱ –Š¢˜›ǰȱ Ž•ȱ
ȱ˜‹Ž—’˜ȱžŽȱ’žŠ•ȱŠȱŖǯŜŞǰȱřŘƖȱ–¤œȱŒŠ›˜ǯ
Basados en la planeación inicial es en esta iteración
cuando el proyecto debió terminar su fase de desarro-
••˜ǰȱŠ•ȱŽœŠ›ȱŠø—ȱŘŞŜȱȱŠ•Ž“Š˜œȱŽȱ•Šȱ–ŽŠǰȱŠȱ•ŠȱŒžŠ•ȱœŽȱ
agregaron otros 13 SP, con lo que el proyecto creció
ŗŖŚƖǯȱ—ȱœž–ŠǰȱŽ•ȱŽšž’™˜ȱ—˜ȱŽ›–’—àȱ•˜ȱ™•Š—ŽŠ˜ȱŠȱŒ˜—-
secuencia de los cambios en el alcance, y fue más caro el
ŽœŠ››˜••˜ȱŽ•ȱ™›˜¢ŽŒ˜ǯȱ•ȱ™›˜‹•Ž–ŠȱžŽȱŠŒŽ™Š›ȱŗŖŚƖȱ
de cambios sobre lo planeado.
Iteración 5
En esta iteración el equipo de desarrollo a cargo fue el
Žšž’™˜ȱřǯȱ•ȱŒ’Ž››ŽǰȱŽ•ȱŸŠ•˜›ȱŠ—Š˜ȱžŽȱŘŞŞȱǰȱšžŽŠ—-
416 Ingeniería Investigación y Tecnología, volumen XV (número 3), julio-septiembre 2014: 403-418 ISSN 1405-7743 FI-UNAM
do solo un restante de 2 SP. Acorde al SPI tenemos que
•ŠȱŸŽ•˜Œ’ŠȱŽ•ȱŽšž’™˜ȱžŽȱŚǯŘřȱ–Š¢˜›ȱšžŽȱ•Šȱ™•Š—ŽŠŠȱ
ǻꐞ›ŠȱŗŚǼǰȱřŘřƖȱ–¤œȱ›¤™’˜ȱŽȱ•˜ȱ™•Š—ŽŠ˜ǯȱ•ȱŒ˜œ˜ȱŽȱ
desarrollar un SP en esta iteración fue más barato, con
ž—ȱȱ’žŠ•ȱŠȱŘǯŗŚǰȱ•˜ȱšžŽȱœ’—’ęŒŠȱšžŽȱžŽȱśŚƖȱ –¤œȱ
‹Š›Š˜ȱšžŽȱ•˜ȱ™•Š—ŽŠ˜ǯȱ›˜‹Š‹•Ž–Ž—Žǰȱ•˜œȱ‹Ž—ŽęŒ’˜œȱ
de la velocidad y el costo se debieron a la sobreestima-
ción del esfuerzo planeado, por lo que es necesario rea-
lizar estimaciones más precisas.
•ȱꗊ•’£Š›ȱ•Šȱ’Ž›ŠŒ’à—ȱœŽȱŠ›ŽŠ›˜—ȱŗŚşȱǰȱœ’—’ę-
ŒŠ—˜ȱśřƖȱŽ•ȱ™Žœ˜ȱ™•Š—ŽŠ˜ȱ™Š›ŠȱŽ•ȱ™›˜¢ŽŒ˜ȱ¢ȱœŽȱ˜‹-
žŸ˜ȱ ž—Šȱ œž–Šȱ Žȱ ŒŠ–‹’˜œȱ Ž—ȱ Ž•ȱ Š•ŒŠ—ŒŽȱ Žȱ ŗśŞǯŗŝƖȱ
sobre el esfuerzo total planeado del proyecto. Nueva-
mente, el problema de este incremento fue aceptar más
de 30% de cambios sobre el plan.
˜—˜›–ŽȱŠȱ•Šœȱ’ęŒž•ŠŽœȱ¢ȱ™›˜‹•Ž–ŠœȱœŽȱŒ˜—Œ•ž¢Žȱ
que es necesario crear un proceso de toma de decisiones
ž’•’£Š—˜ȱ•Šœȱ›ŠęŒŠœȱ¢ȱ•˜œȱ›ŽŒž›œ˜œȱ‘ž–Š—˜œǰȱŽȱ’—˜›-
mación y tecnológicos de que se disponga.
Conclusiones y trabajo futuro
Se creó un método de medición para la estimación, con-
trol y gestión de costos y esfuerzos en equipos de desa-
rrollo de softwareȱ ¤’•ȱ Œ˜—ȱ •Šȱ ꗊ•’Šȱ Žȱ ›Žœ˜•ŸŽ›ȱ •˜œȱ
problemas encontrados en la literatura: una escasa ges-
tión y monitoreo de costos, poca evidencia acerca de la
medición de los costos de un proyecto para los admi-
nistradores y falta de estimación de costos en métodos
ágiles basada en procesos repetibles. La causa principal
Žȱ ŽœŠœȱ ŽęŒ’Ž—Œ’Šœȱ Žœȱ šžŽȱ •˜œȱ –·˜˜œȱ ¤’•Žœȱ œ’žŽ—ȱ
•˜œȱ ™›’—Œ’™’˜œȱ Ž•ȱ –Š—’ęŽœ˜ȱ ¤’•ǯȱ •ȱ ™›’—Œ’™’˜ȱ Žȱ ŽœŠȱ
aclaración es: “El software funcionando es la medida princi-
pal de ͒progreso”. Este principio se centra en la medida
software del funcionamiento para medir un avance del
proyecto, y el principio “A intervalos regulares el equipo
›ŽĚŽ¡’˜—Šȱœ˜‹›Ž͒cómo ser más efectivo para a continuación
ajustar y͒perfeccionar su comportamiento en consecuencia”
se aleja de las medidas predictivas como son las estima-
ciones. Ambos principios restringen a los investigado-
res al crear propuestas precisas para las estimaciones
de tiempos, esfuerzos y costos. Sin embargo, este traba-
“˜ȱ˜›ŽŒŽȱ›Žœȱ’™˜œȱŽȱ›¤ęŒŠœȱ™Š›ŠȱŠ™˜¢Š›ȱ•˜œȱ™›˜‹•Ž-
–Šœȱ–Ž—Œ’˜—Š˜œDZȱ•Šȱ›¤ęŒŠȱȱ™Š›ŠȱŽ•ȱŒ˜—›˜•ȱŽȱ
cambios realizados en el proyecto y no sobrepasar el
tamaño del proyecto de softwareȱŽ—ȱřŖƖǰȱ•Šȱ›¤ęŒŠȱȦ
SPI para el control de costo por SP y calendario, y la
›¤ęŒŠȱ‹ž›—ȱ˜ —ȱšžŽȱ™Ž›–’Žȱ›Ž™›ŽœŽ—Š›ȱ•Šȱ›Ž™•Š—’ę-
cación de cada iteración, además de la técnica de esti-
mación de esfuerzo con datos históricos de SPs.
A pesar de haber diseñado el método para resolver
los problemas mencionados, la información de los da-
 Mitre-Hernández Hugo A., Ortega-Martínez Edgar, Lemus-Olalde Cuauhtémoc
tos históricos de proyectos anteriores y actuales no fue
œžęŒ’Ž—Žȱ™Š›Šȱ’—›˜žŒ’›ȱŠ˜œȱ¢ȱŒ˜–™›˜‹Š›ȱ•ŠȱŽęŒŠŒ’Šȱ
de las evidencias de estimaciones. También se presenta-
›˜—ȱ ’ęŒž•ŠŽœȱ ž›Š—Žȱ •Šœȱ ’Ž›ŠŒ’˜—Žœȱ Ž•ȱ œŽž—˜ȱ
proyecto, por lo que los costos y esfuerzos no se contro-
laron correctamente. Como trabajo futuro es necesario
crear un proceso de toma de decisiones para resolver
•Šœȱ’ęŒž•ŠŽœȱ¢ȱ™›˜‹•Ž–Šœȱ™›ŽœŽ—Š˜œȱŽ—ȱ•˜œȱ™›˜¢ŽŒ-
˜œȱŽȱ–Š—Ž›ŠȱšžŽȱœŽȱž’•’ŒŽ—ȱ•Šœȱ›Žœȱ›ŠęŒŠœȱ™Š›Šȱž—Šȱ
toma de decisiones efectiva.
Para lograr realizar estas estimaciones sin afectar al
–Š—’ęŽœ˜ȱ¤’•ǰȱŠŒžŠ•–Ž—ŽȱœŽȱŽœ¤ȱŽœŠ››˜••Š—˜ȱž—Šȱ
‘Ž››Š–’Ž—Šȱ ™Š›Šȱ Ž—Ž›Š›ȱ •Šœȱ ›¤ęŒŠœȱ ȃ’œ›’‹žŒ’à—ȱ
normal para los tiempos de historias de usuario con es-
fuerzo en SP” y lograr realizar las estimaciones del es-
fuerzo de los proyectos con más precisión y poca
interacción entre los desarrolladores y la herramienta.
En un futuro, con el uso de la herramienta, se espera
generar la información histórica automáticamente para
lograr realizar estimaciones de esfuerzo precisas para
nuevos proyectos.
Otro trabajo en un futuro se puede desarrollar a par-
tir de calcular la cuenta de los tiempos gastados en una
actividad dentro de un proceso, el cual suele ser difícil
si se realiza de forma manual. Para ello, se realizará una
propuesta basada en BPMN y en automatización de
procesos, para conocer el tiempo invertido en cada HU
dentro de un proyecto de software, utilizando la distri-
bución normal para conocer la tendencia de un conjun-
to de HU con un mismo esfuerzo dado en SP.
œȱšžŽȱœŽ›¤—ȱŽœŠ››˜••ŠŠœȱ¢ȱ
Anexo
7pUPLQRV\GHILQLFLRQHV
FRPXQHVHQPpWRGRViJLOHV
Para entender mejor la forma en que los métodos ágiles
monitorean y estiman el costo de los proyectos es nece-
œŠ›’˜ȱŽę—’›ȱ•˜œȱŒ˜—ŒŽ™˜œȱž’•’£Š˜œȱŽ—ȱŽœŽȱ’™˜ȱŽȱŠ-
–’—’œ›ŠŒ’à—ǯȱ—ȱŽœŽȱŠ—Ž¡˜ȱœŽȱŽę—Žȱšž·ȱŽœȱž—ȱ™ž—˜ȱ
de historia, qué es una historia de usuario, qué es una
iteración (sprintǼǰȱ•ŠȱŸŽ•˜Œ’ŠȱŽȱ’Ž›ŠŒ’à—ȱ¢ȱ•Šœȱ›¤ęŒŠœȱ
‹ž›—ȱ˜ —.
Las historias de usuario (HU) son la unidad más pe-
)LJXUD*UiILFDEXUQGRZQSDUDPRVWUDUORV63VUHVWDQWHVSDUD
HOGHVDUUROOR
ducto en métodos ágiles es utilizar historias de usuario.
˜‘—ȱǻŘŖŖŚǼȱŒ˜—’Ž—Žȱ–¤œȱ’—˜›–ŠŒ’à—ǯ
Š›ŠȱŽę—’›ȱŽ•ȱtamaño de una HU la métrica que se
utiliza son los puntos de historia (SP, story points)
ǻ˜‘—ǰȱŘŖŖŚǼǰȱŠž—šžŽȱŠ–‹’·—ȱœŽȱž’•’£Š—ȱ˜›Šœȱ–·›’ŒŠœȱ
Œ˜–˜ȱ•˜œȱÇŠœȱ’ŽŠ•Žœȱǻ˜‘—ǰȱŘŖŖśǼǰȱ•Šœȱ‘˜›ŠœȱŽȱ’—Ž-
niería perfecta y los puntos de función (Kang y Choi,
2010). Los SPȱŽę—Ž—ȱšž·ȱŠ—ȱ›Š—ŽȱŽœȱŽ•ȱŽœžŽ›£˜ȱ—Ž-
cesario para desarrollar una funcionalidad del produc-
to comparándola con otra funcionalidad del mismo
producto y no qué tan largo es su desarrollo.
En los métodos ágiles se realizan revisiones periódi-
cas con el cliente, que toman el nombre de iteración o en
inglés sprint. Durante cada iteración se realiza una pla-
—ŽŠŒ’à—ȱ™Š›ŠȱŽę—’›ȱ•Šœȱ
entregadas al cliente al terminar la iteración. El desarro-
llo de un producto está conformado por una o varias li-
beraciones (releases) y cada liberación tiene un conjunto
de n iteraciones con duraciones de una a cuatro semanas.
Para monitorear que los compromisos establecidos
en el proyecto se cumplan, el desempeño del equipo de
ŽœŠ››˜••˜ȱœŽȱ–’Žȱ‹Šœ¤—˜œŽȱŽ—ȱŽ•ȱ—ø–Ž›˜ȱŽȱȱŽœŠ-
rrollados y aceptados por el cliente durante cada itera-
ción, esta métrica se llama velocidad de la iteración.
Šȱ ‘Ž››Š–’Ž—Šȱ –¤œȱ Œ˜–ø—ȱ Ž—ȱ •˜œȱ –·˜˜œȱ ¤’•Žœȱ
para monitorear el avance del proyecto son las ›¤ęŒŠœȱ
burn downȱ ǻꐞ›Šȱ ŗŜǼDzȱ Ž—ȱ ŽœŠȱ ›¤ęŒŠȱ œŽȱ –žŽœ›Šȱ Ž•ȱ
avance de desarrollo de un equipo durante cada itera-
ción, mostrando los SP faltantes para su desarrollo, en
šžŽÛŠȱŠ–’—’œ›ŠŠȱŽ—ȱŽ•ȱ™›˜¢ŽŒ˜ȱ¢ȱœŽȱŽę—Ž—ȱŽ—ȱŽ›-
fries et al. (2000) como: “Una promesa de conversación”.
Una HU básicamente contiene cuatro características,
una descripción corta de la funcionalidad a desarrollar,
ž—ȱŠ–ŠÛ˜ȱ›Ž•Š’Ÿ˜ǰȱž—ȱŸŠ•˜›ȱŽȱ—Ž˜Œ’˜ȱšžŽȱŽę—Žȱšž·ȱ
tan importante es esta HU para el negocio y uno o más
Œ›’Ž›’˜œȱŽȱŸŠ•’ŠŒ’à—ȱ™Š›ŠȱŽę—’›ȱœ’ȱŽœ¤ȱŽ›–’—ŠŠǯȱŠȱ
manera de documentar los requerimientos de un pro-
donde el eje X presenta las iteraciones y el eje Y la can-
tidad de los SP.
Agradecimientos
Este es un proyecto apoyado por el Consejo de Nacio-
nal de Ciencia y Tecnología (Conacyt) a través del pro-
yecto: “Plataforma de colaboración para cadenas
productivas en micro, pequeñas y medianas empresas

Ingeniería Investigación y Tecnología, volumen XV (número 3), julio-septiembre 2014: 403-418 ISSN 1405-7743 FI-UNAM 417
 Estimación y control de costos en métodos ágiles para desarrollo de software: un caso de estudio

bajo el modelo de softwareȱŒ˜–˜ȱœŽ›Ÿ’Œ’˜ȄȱŒ˜—ȱ—ø–Ž›˜ȱ Miranda E. y Bourque P. Agile Monitoring Using the Line of Ba-
Žȱ™›˜¢ŽŒ˜ȱŖŖŖŖŖŖŖŖŖŗŞŗŗŝŘǯ lance. Journal of Systems and SoftwareǰȱŸ˜•ž–Ž—ȱŞřȱǻ—ø–Ž›˜ȱŝǼǰȱ
“ž•’˜ȱŽȱŘŖŗŖDZȱŗŘŖśȬŗŘŗśǯ
Pham A. y Pham P. Scrum in Action: Agile Software Project Manage-
Referencias ment and Development, Cengage Learning Center, Boston,
—Ž›œ˜—ȱǯǯȱAgile Management for Software Engineering: Applying ESUA 2011, pp. 17-31.
the Theory of Constraints for Business Results, Coad Series, Pren- Project Management Institute. Guide to the Project Management
tice Hall Computer, EUA, 2003. ˜¢ȱ˜ȱ
—˜ •ŽŽȱȬȱ
țȱ ž’ŽȱŘŖŖřȱ’’˜—ǰȱŘŖŖřǯ
Š› Š•ȱǯǰȱȱŠ‘˜ȱǯȱŽę—’—ȱžŒŒŽœœȱ˜›ȱ˜ Š›Žȱ›˜“ŽŒœDZȱ—ȱ Š œ‘˜›—Žȱ ǯȱ ˜—’˜›’—ȱ Œ›ž–ȱ ›˜“ŽŒœȱ  ’‘ȱ ’•Žȱ Š—ȱ
¡™•˜›Š˜›¢ȱŽŸŽ•Š’˜—ǯȱInternational Journal of Project Manage- Earned Business Value (EBV) Metrics. Agile Journal, volumen
mentǰȱŸ˜•ž–Ž—ȱŘŚȱǻ—ø–Ž›˜ȱŚǼǰȱŘŖŖŜDZȱřśŞȬřŝŖǯ ŖǰȱŘŖŖŞǯ
‘˜ ȱǯǰȱȱŠ˜ȱǯǯȱȱž›ŸŽ¢ȱž¢ȱ˜ȱ›’’ŒŠ•ȱžŒŒŽœœȱŠŒ˜›œȱ’—ȱ
’•Žȱ˜ Š›Žȱ›˜“ŽŒœǯȱJournal of Systems and Software, volu-
–Ž—ȱŞŗȱǻ—ø–Ž›˜ȱŜǼǰȱ“ž—’˜ȱŽȱŘŖŖŞDZȱşŜŗȬşŝŗǯ
Cohn M. Agile Estimating and Planningǰȱ›Ž—’ŒŽȱ
Š••ǰȱǰȱŘŖŖśǯ Œ›ž–ȱ›˜“ŽŒœǰȱŽ—DZȱ’•Žȱ˜—Ž›Ž—ŒŽǰȱŘŖŖŜǯ
Cohn M. User Stories Applied: For Agile Software Development, Addi-
œ˜—ȬŽœ•Ž¢ȱ›˜Žœœ’˜—Š•ǰȱǰȱŘŖŖŚǯ
ŽŽ–Ž›ȱ ǯǰȱ Ž—ŽęŽ•ȱ ǯǰȱ Š›–Š—ȱ ǯȱ The SCRUM Primer, Scrum
Training Institute, EUA, 2010, pp. 1–22.
žœ”ȱǯȱŠ›—ŽȱŠ•žŽȱ˜›ȱ’•ŽȱŽŸŽ•˜™–Ž—ǯȱSoftware Tech News,
Ÿ˜•ž–Ž—ȱŗŘȱǻ—ø–Ž›˜ȱŗǼǰȱŘŖŖşDZȱŘŖȬŘŝǯ
SulaimanT. y Barton B. AgileEVM-Earned Value Management in
ȱŠ™ȱǯȱŠ•žŽȱŠœŽȱ¡›Ž–Žȱ›˜›Š––’—ǰȱŽ—DZȱ’•Žȱ˜—Ž›Ž—-
ce, ŘŖŖŜǯ
Este artículo se cita:
Žě›’Žœȱǯǰȱ—Ž›œ˜—ȱǯǰȱ
Ž—›’Œ”œ˜—ȱǯȱ¡›Ž–Žȱ›˜›Š––’—ȱ—œ-
Citación estilo Chicago
talled, 2000. The XP Series.
ȱ˜—Žœȱǯȱ˜ Š›Žȱ›˜“ŽŒȱŠ—ŠŽ–Ž—ȱ›ŠŒ’ŒŽœDZȱŠ’•ž›ŽȱŽ›œžœȱ 0LWUH+HUQiQGH]+XJR$(GJDU2UWHJD0DUWtQH]&XDXKWpPRF
Success. The Journal of Defense Softwareǰȱ ǻ—ø–Ž›˜ȱ ˜Œž‹›ŽǼǰȱ /HPXV2ODOGH(VWLPDFLyQ\FRQWUROGHFRVWRVHQPpWRGRViJLOHV
ŘŖŖŚDZȱśȮşǯ SDUDGHVDUUROORGHsoftwareXQFDVRGHHVWXGLRIngenier¯a Inves-
Kang S. y Choi O. Model-Based Dynamic Cost Estimation and tigaciµn y Tecnolog¯a;9
›ŠŒ”’—ȱŽ‘˜ȱ˜›ȱ’•Žȱ˜ Š›ŽȱŽŸŽ•˜™–Ž—ǰȱŽ—DZȱŒ’Ž—-
ŒŽȱǻǼǰȱŘŖŗŖȱȦȱş‘ǰȱŠ˜œ˜ȱŽȱŘŖŗŖǰȱ™™ǯȱŝŚřȬŝŚŞǯ Citación estilo ISO 690
Keaveney S. y Conboy K. Cost Estimation in Agile Development Pro- 0LWUH+HUQiQGH]+$2UWHJD0DUWtQH](/HPXV2ODOGH&(VWL-
“ŽŒœǰȱŽ—DZȱ›˜ŒǯȱŗŚ‘ȱž›˜™ŽŠ—ȱ˜—ǯȱ—˜›–Š’˜—ǰȱŘŖŖŜǰȱȱ™™ǯȱŗȬŗśǯ PDFLyQ\FRQWUROGHFRVWRVHQPHWRGRViJLOHVSDUDGHVDUUROORGH
ŠŠ—’ȱǯȱ¢ȱ
ŽĴž—Ž—ȱǯȱ˜œȱ˜Ž•’—ȱ’•Žȱ˜ Š›ŽȱŽŸŽ•˜™- softwareXQFDVRGHHVWXGLRIngenier¯a Investigaciµn y Tecnolo-
ment. International Transactions on Systems Science and Applica- g¯aYROXPHQ;9Q~PHURMXOLRVHSWLHPEUH
tionsǰȱŸ˜•ž–Ž—ȱŗȱǻ—ø–Ž›˜ȱŘǼǰȱŘŖŖŜDZȱŗŝśȬŗŝşǯ

Semblanza de los autores

Hugo A. Mitre-Hernández. Investigador en ingeniería del software en CIMAT, Unidad Zacatecas, Mé-
¡’Œ˜ǰȱŠę•’Š˜ȱŽ—ȱŽ•ȱ›ž™˜ȱȬřȱǻ˜ Š›Žȱ—’—ŽŽ›’—ȱŠ‹) de la Universidad Carlos III de
Š›’ȱ¢ȱ™Ž›Ž—ŽŒŽȱŠ•ȱ’œŽ–ŠȱŠŒ’˜—Š•ȱŽȱŸŽœ’Š˜›ŽœȱǻǼȱŽȱ·¡’Œ˜ǯȱ—ȱŽ•ȱŘŖŗŖǰȱꗊ•’£àȱ
su doctorado del Ministerio Español de Ciencia e Innovación (MICINN), realizó una estancia en
el Centro de Investigación Fraunhofer USA (Maryland), para después obtener el grado de doc-
tor en ciencia y tecnología informática de la Universidad Carlos III de Madrid. Sus áreas de inte-
rés son: gestión del conocimiento, medición de productos y procesos, gestión estratégica para
organizaciones de ingeniería del Software, Gobierno de las TICs y gestión de Clusteres.
Edgar Ortega-Martínez. Es desarrollador de software en Compulogic S.A. de C.V., además es SCRUM
–ŠœŽ›ȱŒŽ›’ęŒŠ˜ȱ™˜›ȱ•ŠȱŒ›ž–ȱ••’Š—ŒŽǯȱŽŒ’·—ȱ˜‹žŸ˜ȱœžȱ›Š˜ȱŽȱ–ŠŽœ›ÇŠȱŽ—ȱ’—Ž—’Ž›ÇŠȱŽȱ
software en el Centro de Investigación en Matemáticas A.C. Sus intereses son el desarrollo de
software con métodos ágiles y la mejora de procesos de desarrollo de software.
Cuauhtémoc Lemus-Olalde. Ingeniero en sistemas computacionales por el Instituto Tecnológico y de
œž’˜œȱž™Ž›’˜›ȱŽȱ˜—Ž››Ž¢ǰȱŠ–™žœȱ˜—Ž››Ž¢ȱǻŗşŞŜǼǯȱ‘ÇȱŽœž’àȱ•Šȱ–ŠŽœ›ÇŠȱŽ—ȱŒ’Ž—Œ’Šœȱ
Œ˜–™žŠŒ’˜—Š•ŽœȱǻŗşŞŞǼǰȱ™Š›Šȱ•žŽ˜ȱ˜‹Ž—Ž›ȱ˜Œ˜›Š˜ȱŽ—ȱ•Šȱ–’œ–Šȱ–ŠŽ›’Šȱ™˜›ȱ•Šȱ—’ŸŽ›œ’Šȱ
Žȱž•Š—ŽǰȱžŽŸŠȱ›•ŽŠ—œȱǻŗşşŜǼǯȱ—ȱ•Šȱ—’ŸŽ›œ’ŠȱŽȱ
˜žœ˜—Ȭ•ŽŠ›ȱŠ”Žǰȱ›ŽŠ•’£àȱž—ȱ™˜œ˜Œ-
torado en calidad de investigador visitante como parte del programa aeroespacial del Instituto
™Š›Šȱ˜™Ž›ŠŒ’˜—ŽœȱŽȱœ’œŽ–ŠœȱŽœ™ŠŒ’Š•ŽœǰȱŽ—ȱŒ˜˜›’—ŠŒ’à—ȱŒ˜—ȱ•Šȱȱ¢ȱŽ•ȱŽ—›˜ȱœ™ŠŒ’Š•ȱ˜-
hnson. Es director del Centro de Investigación en Matemáticas, A.C. (CIMAT), Unidad Zacate-
cas. Sus intereses de investigación son: mejora de procesos de Softwareǰȱ–Ž’Œ’à—ȱŽȱ™›˜ŒŽœ˜œȱǻŜȱ
sigma), gestión de la innovación y métodos de innovación TRIZ aplicados a la industria.

418 Ingeniería Investigación y Tecnología, volumen XV (número 3), julio-septiembre 2014: 403-418 ISSN 1405-7743 FI-UNAM