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

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)

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

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éxicoCorreo: [email protected]

Ortega-Martínez EdgarCentro de Investigación en Matemáticas (CIMAT)


Lemus-Olalde CuauhtémocCentro de Investigación en Matemáticas (CIMAT)


Descriptores:

" iguvk„p"fgn"software

" iguvk„p"fg"equvqu" ofivqfqu"ƒikngu" fgucttqnnq"fg"software"ƒikn" UccU

Resumen

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

Ł©ややœや¬°©Ł³ª²ıµıŁŁや±©ªıŁややØ±²±やßØ²©Ł©œ©ºç±╇やŁØßÀ±やŁØやœやSØ¼ıÆıœı-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-

œœ©╇やœや ıº³œや®³Øやœ©±やŁßı-ı±²°Ł©°Ø±やŁØや¬°©½Øª²©±や-©やª³Ø-²-やª©-やœ±や±³R-

cientes evidencias para la comprobación del gasto del presupuesto en un

proyecto debido a la poca documentación generada y por la falta de segui-

miento en el gasto de los recursos. Se presenta una propuesta de estimación

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

ŁØやŁØªı±ı©-Ø±╇やœ©やª³œやŁı©や©°ıºØ-やや³-やŁØR-ıªıŸ-やŁØや³-や¬°©ªØ±©やŁØや²©ßやŁØやdecisiones para ser aunado a la propuesta de medición.


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

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

ı-Ł³±²°ıやª²³œßØ-²Øや±©-╈や&¼²°ØßØや1°©º°ßßı-ºや〉+ØŒ-fries et al., 2000), SCRUM (Deemer et al., 2010) y Feature

Drive Development (Anderson, 2003).

Las metodologías ágiles toman su nombre después

ŁØや®³ØやØ-やｲｰｰｱや³-やº°³¬©やŁØやｱｷやØ¼¬Ø°²©±やØ-やŁØ±°°©œœ©やŁØやsoftwareや°Ø³-ıØ°©-や±³±やıŁØ±や½やª°Ø°©-やØœやß-ıRØ±²©やÀºıœ╇やestableciendo doce principios y en donde cada metodo-

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

Ø¼ı²©±©±や±Øº1-や+©-Ø±や〉ｲｰｰｴ《╇やª©-±ıŁØ°-Ł©や³-や¬°©½Øª²©やØ¼ı²©±©やª©ß©やØœや®³Øや²Ø°ßı-やŁØ-²°©やŁØœや²ıØß¬©╇やª©±²©や½やªœıŁŁやØ±¬Ø°Łや〉+©-Ø±╇やｲｰｰｳ╉や"º°¹œや½や3²æ©Ł╇やｲｰｰｶ╉や$æ©¹や ½や $©╇やｲｰｰｸ《╇や ¬°ı-ªı¬œßØ-²Øや ¬°Ø±Ø°µ-Ł©や œ©±やŁ©ªØや ¬°ı-ªı¬ı©±や ŁØœや ß-ıRØ±²©や Àºıœや ŁØや $æ©¹や ½や $©や〉ｲｰｰｸ《╆や&-やœやı-Ł³±²°ıやŁØやß-³Œª²³°やÀºıœや±Øやæ-や¬°Ø-sentado buenos resultados de adaptabilidad a los cam-

Æı©±やØ¼²Ø°-©±やª©-やßØ-©±や¬Ô°ŁıŁ±やŁØやª©±²©±や〉--²ıや½や,Øm³-Ø-╇やｲｰｰｶ《╇やØ-やª³-²©やœやŁØ±°°©œœ©やÀºıœやŁØや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-

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.

El problema con los costos en los métodos ágiles es la

falta de una administración y monitorización efectivas

〉: ¬╇やｲｰｰｶ╉や,ØµØ-Ø½や½や$©-Æ©½╇やｲｰｰｶ╉や4³œıß-や½や#°-²©-╇やｲｰｰｶ╉や3³±ø╇やｲｰｰｹ《╇やŁØßÀ±やŁØやª°ØªØ°やŁØやœやºØ-Ø°-

ªıŸ-やŁØやØµıŁØ-ªı±や〉+©-Ø±╇やｲｰｰｴ╉や4³œıß-や½や#°²©-╇やｲｰｰｶ╉や3³±ø╇やｲｰｰｹ《や½やØ±²ıßªı©-Ø±やŁØやª©±²©±やº³ıŁや¬©°や¬°©ªØ-±©±やßØł©°ÆœØ±や〉,ØµØ-Ø½や ½や$©-Æ©½╇やｲｰｰｶ╉や 1æßや"╆や ½や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-

do para la administración y monitoreo del presupuesto

además de la estimación de costos en los métodos ágiles,

±ıº³ıØ-Ł©やœ©±や¬°ı-ªı¬ı©±やŁØœやß-ıRØ±²©やÀºıœや½やÆ©°Ł-Ł©や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

ŁØœや¬°Ø±³¬³Ø±²©や½やœやØ±²ıßªıŸ-やŁØやª©±²©±╉やØ-やœや±ØªªıŸ-やde propuesta de medición de costos se desarrolla la

propuesta del control de presupuesto y del proceso de

Ø±²ıßªıŸ-やŁØやª©±²©±╉やØ-やœやª³°²や±ØªªıŸ-や±ØやŁØ±°°©œœや

Abstract

The development of software (SW) using agile methods is growing due to the pro-

Ł³ª²ıµı²½や±±©ªı²ØŁや¹ı²æや²æØ±ØやßØ²æ©Ł©œ©ºıØ±╇やı-やŁŁı²ı©-や²©や²æØやSØ¼ıÆıœı²½や±æ©¹-やı-や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

æµØや Ø-©³ºæや ØµıŁØ-ªØや ²©やµØ°ıŒ½や ²æØやÆ³ŁºØ²や ±¬Ø-Łı-ºや©-やや¬°©łØª²やŁ³Øや ²©や ²æØや¬©©°やdocumentation generated and the lack of monitoring of resource spending. A pro-

posal estimation and cost control in agile methods to solve these shortcomings. To

this end, a case study was conducted in an agile software development company

³±ı-ºや²æØや¬°©¬©±œやŒ©°や4©Œ²¹°Øや±やや4Ø°µıªØや〉44《や-Łや8ØÆや¬¬œıª²ı©-や¬°©łØª²±╆やThe results found were that the proposal generates a high degree of evidence for

¬°©łØª²やß-ºØ°±╇やÆ³²やı²やæ±や±æ©°²ª©ßı-º±やı-や²æØやŁßı-ı±²°²ı©-や©Œや²æØやØµıŁØ-ªØやŒ©°や²æØやª©-²°©œや-ŁやŁØªı±ı©-やßøı-º╇や¹æıªæやœØŁや²©ややŁØR-ı²ı©-や©ŒややŁØªı±ı©-やßøı-ºや¬°©-

ªØ±±や²©やÆØやª©³¬œØŁや¹ı²æや²æØやßØ±³°ØßØ-²や¬°©¬©±œ╆

Keywords:

software management

""cost management

""agile methods

""agile software development

""SaaS

405

Mitre-Hernández Hugo A., Ortega-Martínez Edgar, Lemus-Olalde Cuauhtémoc

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

el caso de estudio, desde su diseño hasta la interpreta-

ªıŸ-やŁØやœ©±や°Ø±³œ²Ł©±╉や¬©°や1œ²ıß©や±ØやŁ-ややœ±やª©-ªœ³±ı©-

-Ø±や½やØœや²°Æł©やŒ³²³°©╉やØ-やœや¬°²ØやR-œやŁØœやŁ©ª³ßØ-²©や±Øやº°ØºŸや³-や-Ø¼©やª©-やœや²Ø°ßı-©œ©ºçやßÀ±や³²ıœı¾Łや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-

ß1-や ®³Øや ±Øや Ø-ª©-²°Ÿや Ø-や œや œı²Ø°²³°や Œ³Øや 4$36.や(Deemer et al., 2010), por lo que será este en el que se

base este artículo.

Oqpkvqtgq"{"eqpvtqn"fgn"rtguwrwguvq

&-やØœや°²çª³œ©やŁØや4³œıß-や½や#°²©-や〉ｲｰｰｶ《や±ØやŁØR-Øや³-や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《╆や &7.や ±Øや ŁØR-Øや Ø-や 1°©łØª²や.-ºØßØ-²や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

¬°©½Øª²©やØ-や"ºıœØ&7.や±Øや°Øœı¾やœやR-œやŁØやªŁやı²Ø°-

ción, en estas revisiones se recolectan cuatro paráme-

²°©±╈や Øœや -1ßØ°©やŁØや ı²Ø°ªıŸ-や ª²³œや〉-《╇や œ©±や ¬³-²©±や ŁØや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《やŒœ²-²Ø±やŁ³°-²ØやªŁやı²Ø°ªıŸ-や〉R-

gura 1). Entonces, conociendo el CPI y el SPI es posible

conocer si el proyecto marcha de acuerdo a lo planeado,

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-

-©±やŁØやœ©や¬œ-ØŁ©╇や³-や$1*やßØ-©°や®³Øやｱや±ıº-ıRªや®³Øや±Øや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.

&-や Øœや °²çª³œ©や ŁØや%-や 3¹±²æ©°-Øや〉ｲｰｰｸ《や ±Øや ²©ßやcomo base el método AgileEVM (Sulaiman y Barton,

ｲｰｰｶ《╇や¬Ø°©やº°Øº-Ł©ややœ©±やç-ŁıªØ±や$1*や½や41*やØœやµœ©°やdel negocio ganado durante cada iteración (EBV), ya

®³Øや3¹±²æ©°-Øや œ©や ª©-±ıŁØ°や³-やßÔ²°ıªや ıß¬©°²-²Øやpara conocer el valor de negocio que el equipo de desa-

°°©œœ©やº°Øºやœや¬°©Ł³ª²©や½や®³ØやÆØ-ØRªıやœやªœıØ-²ØやŁ³-

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《╇や ±Øº1-や3¹±²æ©°-Øやœやœç-ØやŁØ°ıµŁやŁØœや&#7やŁØや³-や¬°©½Øª²©やdebe ser muy parecida a una línea S como la mostrada

Ø-やœやRº³°やｲ╆-やı-µØ±²ıºªıŸ-やŁØや3³±øやØ-やｲｰｰｹや²ßÆıÔ-やØ±²Àや°Øœ-

cionada con el control y monitoreo de costos, su pro-

puesta está fundada en el EVM descrito en el estándar

"/4*の&*"まｷｴｸ╆や3³±ø╇やÆ±Ł©やØ-や±³やØ¼¬Ø°ıØ-ªıやßØ-ªı©-

na que el enfoque tradicional de EVM encaja bastante

bien en los métodos ágiles y que es muy fácil entender

±³や¬œıªªıŸ-╆や4Øº1-や3³±ø╇やª©-©ªØ°やØœやª©-²Ø¼²©やR--ªıØ-ro de los proyectos desarrollados en métodos ágiles no

Ø±や ¬©±ıÆœØや ³²ıœı¾-Ł©や 1-ıªßØ-²Øや œ±や º°ÀRª±や ŁØや Æ³°-やdown proporcionadas por la administración ágil.

Para monitorear el desempeño del proyecto y el

ª©-²Ø¼²©やR--ªıØ°©╇や±Øや³²ıœı¾Ÿや³-やº°ÀRªやØ-やŁŸ-ŁØやœやmétrica de presupuesto y SP desarrolladas se repre-

sentan con valores porcentuales durante cada itera-

ªıŸ-やØ-や°ØœªıŸ-やª©-やØœや²©²œやŁØや41やŁØœや¬°©Ł³ª²©╆や3³±øや

Hkiwtc"30 Itƒhkec"rctc"oquvtct"gn"xcnqt"icpcfq."ERK"{"URK"gp"CikngGXO"*Uwnckocp"{"Dctvqp."4228+"



³²ıœı¾Ÿや³-やº°ÀRª╇やª©ß©やœやß©±²°ŁやØ-やœやRº³°やｳ╇やØ-やdonde dibujó una línea punteada correspondiente a

una función lineal, basada en la velocidad del equipo

de desarrollo, en la que se supone una velocidad cons-

tante para mostrar el avance esperado en cada itera-

ªıŸ-╉や³²ıœı¾Ÿや³-やœç-Øや-Øº°や¬°やß©±²°°やØœやµ-ªØやŁØや41やŁØ±°°©œœŁ©やœやR-œı¾°やªŁやı²Ø°ªıŸ-や½や³-やœç-Øやgris para ilustrar el gasto del presupuesto en cada ite-

°ªıŸ-╇やや Ø±²や º°ÀRªや œØや Łや Øœや -©ßÆ°Øや ŁØや º°ÀRªや ŁØや²ıØß¬©や ½や ¬°Ø±³¬³Ø±²©╆や &-や Øœœや Ø±や ¬©±ıÆœØや ıŁØ-²ıRª°や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.

En el artículo de Miranda y Bourque (2010), se pro-

pone una técnica de monitorización de proyectos ba-

sándose en la técnica de línea de balance (LOB, line of

Æœ-ªØ) y utilizando puntos de control en las activida-

des del proceso de desarrollo, además se propone que

la recolección de información se realice en los sistemas

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-

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

Rº³°やｴや±Øや©Æ±Ø°µやœやŒ©°ßやØ-や®³ØやØ±²Øやß©ŁØœ©やß³Ø±-tra la información durante el monitoreo del desempe-

ño en cada punto de control, la información mostrada

Ø-や œや º°ÀRªや ²ıØ-Øや ª©ß©やßÔ²°ıªや ÆÀ±ıªや ³-や)6╆や &-や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-

rización dinámico, la métrica básica de monitoreo son

los puntos de función FP (Function Points), los cuales

describen la funcionalidad de cada HU. En este modelo

el monitoreo es diario, por lo que se tiene una base his-

²Ÿ°ıªや ŁØや ı-Œ©°ßªıŸ-╉や Ø±²Øやß©ŁØœ©や ³²ıœı¾や Øœや Rœ²°©や ŁØや,œß-や½やØœやß©ŁØœŁ©やŁØやØ±¬ªı©±やŁØやØ±²Ł©やª©-やœやR-

nalidad de hacer proyecciones muy precisas del avance

en puntos de función que se espera tenga el producto

±Øº1-やœやµØœ©ªıŁŁやæı±²Ÿ°ıªやŁØœやØ®³ı¬©╆や&œやß©ŁØœ©やØ±-pacio de estado se alimenta con la información de los

FP faltantes y las variaciones del alcance en el proyecto.

&-やœやRº³°やｵや±Øやß³Ø±²°やœやº°ÀRªや³²ıœı¾Łや¬°やØœやß©-

-ı²©°Ø©や〉,-ºや½や$æ©ı╇やｲｰｱｰ《╇や±Øや¬³ØŁØやµØ°や³-やº°ÀRªやdel tipo Æ³°-やŁ©¹- en donde los FP son los valores del

eje Y. En el eje X se muestran los FP faltantes por día.

En las metodologías mostradas en esta sección se

encontraron puntos de mejora. Los métodos basados en

&7.や〉4³œıß-や½や#°²©-╇やｲｰｰｶ╉や3³±ø╇やｲｰｰｹ╉や3¹±²æ©°--Ø╇やｲｰｰｸ《や-©や²©ß-やØ-やª³Ø-²やØœやªßÆı©やØ-やØœやœª-ªØやŁØやun proyecto, es decir, la replaneación no se muestra en

œ±やº°ÀRª±やŁØや ¬©½©や¬°やØœやß©-ı²©°Ø©╇や±ıØß¬°Øや±Øやª©--

±ıŁØ°や1-ıªßØ-²ØやØœやµœ©°や©Æ²Ø-ıŁ©やŁØやœや¬°ıßØ°や¬œ-

neación como un todo, por lo que la información que se

Hkiwtc"40"N‡pgc"U"kfgcn"rctc"gn"GDX"gp"wp"rtq{gevq"ugi¿p"Tcyuvjtqpg"*422:+"

Hkiwtc"50"Itƒhkec"wvknk¦cfc"rqt"Twum"rctc"oqpkvqtgct"gn"eqpvgzvq"hkpcpekgtq"{"gn"fgugorg‚q"gp"wp"rtq{gevq"*422;+"

Hkiwtc"60 Itƒhkec"rctc"gn"oqpkvqtgq"fg"JW"rqt"Rwpvq"fg"Eqpvtqn"wvknk¦cfq"gp"NQD"*Oktcpfc"{"Dqwtswg."4232+

407



ß³Ø±²°や-©やØ±やª©-RÆœØや œや°Øœı¾°やªßÆı©±やØ-やØœや œª-ªØや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

Ø±Œ³Ø°¾©や¬°や¬œ-Ø°や³-や¬°©Ł³ª²©やØ-や'1や-©やØ±²Àやł³±²ıR-

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

-©や±Øや°ØSØłやØ-や±³やßØ²©Ł©œ©ºç╆-©±や¬³-²©±やŁØやßØł©°やıŁØ-²ıRªŁ©±やØ-やœ±や¬°©¬³Ø±-

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.

Guvkocek„p"fg"equvqu

En los métodos ágiles se utilizan prácticas empíricas

Æ±Ł±やØ-やØœやł³ıªı©やŁØやØ¼¬Ø°²©±や¬°やØ±²ıß°やØœやª©±²©やŁØやdesarrollo para un nuevo producto, en la literatura se

ıŁØ-²ıRª°©-やŁ©±や¬°Àª²ıª±やª©ß³-Ø±や¬°やØ±²やR-œıŁŁ╇やœやßÀ±や ª©ß1-や ı-µ©œ³ª°や ª©ß©やßÔ²°ıªや Æ±Øやや œ©±や 41や〉$©æ-╇やｲｰｰｵ╉や 4³œıß-や ½や #°²©-╇やｲｰｰｶ╉や 3³±ø╇やｲｰｰｹ╉や3¹±²æ©°-Ø╇やｲｰｰｸ╉や.ı°-Łや½や#©³°®³Ø╇やｲｰｱｰ《や ½や œや ±Ø-gunda se basa en FP (Kang y Choi, 2010).

-や¬°ıßØ°やß-Ø°や ıŁØ-²ıRªŁ╇や®³ØやØ±や œやßÀ±やª©-

ß1-やØ-やßÔ²©Ł©±やÀºıœØ±╇や²ıØ-Øやª©ß©やßÔ²°ıªや¬°ı-ªı¬œややœ©±や41や〉$©æ-╇やｲｰｰｵ《╆や&-やØ±²や¬°Àª²ıªやœや¬°ıßØ°や²°Øやや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

ŁØR-Øや³-やµØœ©ªıŁŁやÆ±Øや Ł®³ı°ıŁやŁØやŁ²©±やæı±²Ÿ°ıª©±や-©やß³½やª©-RÆœØ±╇や©やŁØœやł³ıªı©やŁØやØ¼¬Ø°²©±╇や¬°やª©-©-

ªØ°やØœや²ıØß¬©や¬°©¼ıßŁ©やØ-やØœや®³ØやØœや¬°©½Øª²©や²Ø°ßı-

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

los SP. La forma en que realizan la estimación del costo

ŁØœや¬°©½Øª²©やØ±や±ıßıœ°ややœや®³Øや±Øや³²ıœı¾やª©ß1-ßØ-²ØやØ-や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-

ªı©±やŁØやØ¼¬Ø°²©±や½や®³Øや³²ıœı¾-や41やª°ØªØ-やŁØや³-やß©ŁØœ©や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

œ©±やŁ²©±やæı±²Ÿ°ıª©±╇や¬Ø°©や1-ıªßØ-²Øやœ©±やŁØœや¬°©½Øª²©やØ-や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.

Rtqrwguvc"fg"ogfkek„p"fg"equvqu

&-やœやœı²Ø°²³°や±ØやØ-ª©-²°°©-やœº³-±やŁØRªıØ-ªı±やØ-や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

œ©±や¬°©½Øª²©±や-©や±Øや¬œ-ØやŁØや-³Øµ©やœやR-œı¾°やªŁや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

¬°ı-ªı¬ı©±やŁØœやß-ıRØ±²©やÀºıœ╆や&-やœや±ØªªıŸ-やŁØや-Àœı±ı±やe interpretación se propone una técnica para estimar

Hkiwtc"70"Itƒhkec"eqp"nc"kphqtocek„p"tguwnvcpvg"fgn"hknvtq"Mcnocp"*Mcpi"{"Ejqk."4232+



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.

Oqpkvqtgq"{"eqpvtqn"fgn"equvq

-±やŁØRªıØ-ªı±やıŁØ-²ıRªŁ±やØ-やØœやß©-ı²©°Ø©や½やª©-²°©œや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

ÀºıœØ±やŁØÆØや±Ø°やSØ¼ıÆœØや½やªßÆı-²Øや¬©°やœや¬°©¬ıや-²³-

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-

°°やª©-R-¾や½や²°-±ßı²ı°やı-Œ©°ßªıŸ-やRÆœØややœ©±やı-µ©-

lucrados.

&-やØ±²や¬°©¬³Ø±²や±Øや³²ıœı¾-や²°Ø±やº°ÀRª±や¬°や©Æ-

servar la información agrupada y que sea fácil de co-

ß³-ıª°や ½や Ø-²Ø-ŁØ°や ¬©°や ª³œ®³ıØ°や ¬Ø°±©-╇や 1-や ±ı-やconocimiento en administración de proyectos de desa-

rrollo de software╆や4ØやıŁØ-²ıRª°©-やŁ©±やª²ıµıŁŁØ±やıß-

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

¬°やØœや¬°©½Øª²©╉やœや±Øº³-Łやª²ıµıŁŁや-ØªØ±°ıや¬°やpermitir el monitoreo y el control del proyecto confor-

me evoluciona es la replaneación, en donde se identi-

Rª-や½や±ØやŁßı-ı±²°-や°ıØ±º©±や¬°や¬©ŁØ°や²Ø°ßı-°やØœや¬°©½Øª²©やª©-やÔ¼ı²©╆

Planificación

-や¬œ-ıRªªıŸ-やØ±やœやª²ıµıŁŁやŁ©-ŁØや±³°ºØやØœや¬°ıßØ°やacercamiento detallado de las necesidades del cliente

½やŁ©-ŁØや±ØやıŁØ-²ıRª-やœ©±や°Øª³°±©±や-ØªØ±°ı©±や¬°やØœやdesarrollo de un producto de software. En esta pro-

¬³Ø±²や-©や±Øや²°²-やœやıŁØ-²ıRªªıŸ-やŁØやœ±や-ØªØ±ıŁŁØ±や©やœやŁØR-ıªıŸ-やŁØやœ©±や°Ø®³Ø°ıßıØ-²©±やŁØやªœıØ-²Ø╇や¬Ø°©や±çや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

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

&7.╇や Ø±²や ¬œ-ıRªªıŸ-や µやや ±Ø°や ªßÆı-²Øや Ł³°-²ØやªŁやı²Ø°ªıŸ-や½や±ØやØ¼¬œıªやØ-やØœや¬³-²©やŁØœや©ÆłØ²ıµ©やŁØやinvestigación.

Para planear un nuevo proyecto de software es nece-

sario conocer las siguientes métricas base:

ゃややや5ßü©やÆ±Øや²©²œやŁØœや¬°©Ł³ª²©や〉TBTP): es el tamaño

ŁØœや¬°©Ł³ª²©やŁØR-ıŁ©やØ-や¬³-²©±やŁØやæı±²©°ı╆や1°やconocer este valor se puede aplicar la siguiente

fórmula:

(1)

ゃややや%©-ŁØや)6ıやØ±やØœやª©-ł³-²©やŁØや)ı±²©°ı±やŁØや³±³°ı©やdel proyecto y Esfuerzo es la métrica con que se

ßıŁØやØœや²ßü©やŁØやœ±やæı±²©°ı±やŁØや³±³°ı©やŁØR-ıŁ©やpor puntos de historia (SP).

ゃややや7Øœ©ªıŁŁやÆ±ØやŁØœやØ®³ı¬©や(VB): es la cantidad de pun-

tos de historia pronosticada que el equipo de desa-

rrollo entregará al usuario durante cada iteración.

&±²やßÔ²°ıªや ±Øや©Æ²ıØ-Øや ª©ß1-ßØ-²Øや¬©°や ł³ıªı©やŁØやØ¼¬Ø°²©±╆や&-や œや±ØªªıŸ-やŁØや-Àœı±ı±やØや ı-²Ø°¬°Ø²ªıŸ-や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)

ゃやや1°や©Æ²Ø-Ø°や³-やµœ©°やØ-²Ø°©やØœや°Ø±³œ²Ł©やŁØや*やŁØÆØや±Ø°や°ØŁ©-ŁØŁ©やæªıや±³やØ-²Ø°©や¬°Ÿ¼ıß©╆

ゃやややDuración de iteración (DI): indica la duración en tiem-

¬©やŁØやªŁや*²Ø°ªıŸ-╇やØ-やŁ©-ŁØやØœや°-º©やª©ß1-やØ±やØ-²°Øやｲや±Øß-±や½やｴ╆

ゃややや$©±²©やÆ±ØやŁØœや¬°©Ł³ª²©や(CBP): ŁØR-ØやØœやª©±²©ややı-µØ°-tir para el desarrollo del producto. En los métodos

ÀºıœØ±や-©やØ¼ı±²Øや³-や¬°Àª²ıªや©やßÔ²©Ł©やØ±²À-Ł°や¬°やestimar el costo de un producto.

ゃややや$©±²©や Æ±Øや ŁØœや Ø®³ı¬©や ¬©°や ı²Ø°ªıŸ-や (CBI《╈や ±Øや ŁØR-Øやcomo el costo monetario que se espera gastar duran-

te cada iteración. Para conocer este valor se utiliza la

siguiente fórmula,

(3)

409



Hkiwtc"80"Burn down"fg"rncpkhkecek„p"rctc"gn"rtq{gevq"ÑUkuvgoc"fg"iguvk„p"fg"eqpvgpkfquÒ

ゃややや$©±²©やÆ±ØやŁØや41や¬©°やı²Ø°ªıŸ-や(CBSPI): es el costo mo-

netario por desarrollar un punto de Historia y se

puede calcular con la siguiente fórmula,

や〉ｴ《

Además de las métricas base en esta actividad, se obtie-

-Øやœやº°ÀRªやÆ³°-やŁ©¹-やde planeación, en la que se gra-

Rªや œや ª-²ıŁŁやŁØや41や Œœ²-²Øや¬©°やŁØ±°°©œœ©やŁ³°-²ØやªŁや ı²Ø°ªıŸ-╆や 1°や ©Æ²Ø-Ø°や Ø±²や º°ÀRªや Ø±や -ØªØ±°ı©やconocer la cantidad de SP que el equipo va a desarrollar

durante cada iteración basándose en la información de

œや¬œ-ØªıŸ-╆や-やŒ³-ªıŸ-ややº°Rª°やØ±やœや±ıº³ıØ-²Ø╈

や〉ｵ《

en donde ¼やØ±やœやı²Ø°ªıŸ-や®³Øや±Øやµややº°Rª°や½や41*や±©-やlos SP a desarrollar en la iteración i.

1°やØłØß¬œıRª°やØ±²やª²ıµıŁŁや²©ßß©±やª©ß©やØłØß-

plo el proyecto “Sistema de gestión de contenidos” desa-

rrollado en la empresa Compulogic, a través de su división

de software, en donde el equipo de desarrollo está confor-

ßŁ©や ¬©°や ³-や œçŁØ°や ŁØや ¬°©½Øª²©や ½やｵや ŁØ±°°©œœŁ©°Ø±╆や &œやØ®³ı¬©や œØµ-²Ÿや °Ø®³Ø°ıßıØ-²©±や ª©-や³-や ²©²œやŁØやｴｶや)6±╇やcada una con su respectivo esfuerzo, donde se obtuvo un

5#51やŁØやｴｸｶや41╆や&œやœçŁØ°やŁØœや¬°©½Øª²©やª©-±ıŁØ°Ÿや³-や7#やŁØや70 SP por iteración basándose en las velocidades logradas

Ø-や¬°©½Øª²©±や-²Ø°ı©°Ø±╉やª©-やØœや5#51や½や7#や±Øや©Æ²ıØ-Ø-やｷやiteraciones necesarias para desarrollar el producto con

una duración de 2 semanas cada una. Además, el líder

estimó el costo del producto basándose en los sueldos de

los desarrolladores que forman parte del equipo y del

tiempo que durará el proyecto, de donde obtuvo un CBP

ŁØや┵ｲｵｲ╇ｰｰｰ╆ｰｰ1. El equipo planea los SP a desarrollar en

cada iteración y obtiene la información que se muestra en

la tabla 1.

Vcdnc"30"UR"rncpgcfqu"rqt"kvgtcek„p"rctc"gn"rtq{gevq""ÑUkuvgoc"fg"iguvk„p"fg"eqpvgpkfquÒ

Iteración SPI

1 ｶｶ2 71

3 71

ｴｶｵｵｶｵｶｶｸ7 ｸｰ

3"Rctc"eqpugtxct"nc"eqphkfgpekcnkfcf"eqp"nqu"equvqu"fgpvtq"fg"nc"go-rtguc."gn"equvq"tghgtgpekcfq"ug"ecodk„0

Vcdnc"40"Ofivtkecu"dcug"rctc"gn"rtq{gevq""ÑUkuvgoc"fg"iguvk„p"fg"eqpvgpkfquÒ

Métrica Valor obtenido

TBTP ｴｸｶや41

VB 70 SP/Iteración

DI 2 semanas

I 7

CBP ┵ｲｵｲ╇やｰｰｰ╆ｰｰ

CBI ┵ｳｶ╇やｰｰｰ╆ｰｰ

CBSPI ┵やｵｶｳ╆ｷｴ

El resumen de la información se ilustra en la tabla 2. El

Æ³°-やŁ©¹-やŁØや¬œ-ıRªªıŸ-や±Øやß³Ø±²°やØ-やœやRº³°やｶ╆

Replanificación

-やº°ÀRªやŁØやÆ³°-やŁ©¹-やŁØや¬œ-ıRªªıŸ-やØµ©œ³ªı©-°ÀやŁ³-

rante cada revisión de iteración, en ella se mostrará que:

ゃややや&œやµ-ªØやÆ±Øや¬œ-ØŁ©や(AB《や±Øやº°Rªやª©-やœやßı±ßやŒ³-ªıŸ-や³²ıœı¾ŁやØ-やœや¬œ-ıRªªıŸ-╆

ゃやややEl avance real (AR) mostrará el valor ganado durante

cada iteración incluyendo los cambios en el alcance

durante cada iteración. Los cambios en el alcance se

mostrarán a la alza cuando se agreguen SP al pro-

ducto y a la baja cuando se eliminen.

ゃやや&œやµ-ªØや°Ø¬œ-ıRªŁ©や〉ARR) mostrará los ajustes que

el equipo toma durante cada planeación de una

-³Øµやı²Ø°ªıŸ-╆や%³°-²ØやªŁや¬œ-ıRªªıŸ-やŁØやı²Ø°-

ción el equipo decide qué HU va a desarrollar, se

Æ±やØ-やœやı-Œ©°ßªıŸ-やŁØやœや¬œ-ıRªªıŸ-╇や¬Ø°©やØ±²やes susceptible a cualquier tipo de cambio generado

por petición del involucrado para mitigar riesgos o

para eliminar restricciones.

Para controlar el cambio del alcance y mantenerlo visi-

ble durante cada iteración se propone la º°ÀRªやŁØやªß-

Æı©±や Ø-や Øœや œª-ªØ, que mostrará el impacto de estos

cambios en los SP agregados o eliminados del TBTP.



En esta actividad es necesario obtener las siguientes

métricas:

ゃやややCosto actual de la iteración (CAI):やŁØR-ØやØœやª©±²©やß©-

netario de una iteración.

ゃややSP desarrollados en la iteración (SPAI《╈やŁØR-Øやœ©±や41やŁØ-sarrollados en una iteración. Solo se contabilizan los

41やªØ¬²Ł©±や¬©°やØœやªœıØ-²ØやœやR-œı¾°や³-やı²Ø°ªıŸ-╆やTambién se puede nombrar velocidad de iteración.

ゃやややCosto actual de SP (CASPI《╈やŁØR-ØやØœやª©±²©やß©-Ø²°ı©やpor desarrollar un SP en una iteración. Para conocer

este costo se utiliza la siguiente función:

や〉ｶ《

ゃややや `-ŁıªØ de desempeño del costo (CPI): esta métrica per-

ßı²Øやµı±³œı¾°やœやS³ª²³ªıŸ-やŁØœやª©±²©や¬©°や41やª©-²°やel costo por SP real durante cada iteración. Este índi-

ce permite conocer si el equipo desarrolla los SP

Æł©やœ©や¬°Ø±³¬³Ø±²Ł©やØ-やœや¬œ-ıRªªıŸ-や©やØ±²ÀやØ¼-

ªØŁıØ-Ł©や Øœや¬°Ø±³¬³Ø±²©や½や¬©-Øや Ø-や °ıØ±º©や Øœや Ô¼ı²©やdel proyecto. El CPI ideal debe tener un valor igual

やｱ╆や$³-Ł©やØœや$1*やØ±やß½©°や®³Øやｱや±ıº-ıRªや®³ØやØœやcosto por SP es menor al planeado y si el CPI es me-

-©°や®³Øやｱや±ıº-ıRªや®³ØやØœやª©±²©や¬©°や41やØ±やß½©°や®³Øやel planeado. La fórmula para conocer este índice es

la siguiente:

(7)

ゃややや `-ŁıªØやŁØœやŁØ±Øß¬Øü©やŁØœやªœØ-Ł°ı©や〉SPI): este ín-

dice es el que permite realizar el monitoreo del ca-

œØ-Ł°ı©╇や Øœや Ø®³ı¬©や ª©-©ªØ°Àや œや S³ª²³ªıŸ-や ŁØや œや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

œ©や¬œ-ØŁ©╉や ±ıや Øœや 41*や Ø±やßØ-©°や®³Øやｱ╇や Øœや¬°©½Øª²©やterminará después de la fecha planeada. La fórmula

para conocer este índice es la siguiente:

〉ｸ《

ゃやや$ßÆı©±やØ-やØœやœª-ªØや(SPCA): esta métrica permitirá

conocer la cantidad de SP agregados o eliminados al

TBTP durante una iteración.

ゃややや5©²œやŁØやªßÆı©±やØ-やØœや œª-ªØや(TSPCA): con esta métri-

ca será posible monitorear el total de cambios reali-

¾Ł©±やØ-やØœや¬°©½Øª²©╆や&-や&7.や±Øやª©-±ıŁØ°やØ¼ı²©±©や³-や¬°©½Øª²©や®³Øやµ°ıŸやｳｰゾや±³や²ıØß¬©や½やª©±²©や〉3³±ø╇やｲｰｰｹ《╇やØ±や¬©°やØœœ©や®³Øや±Øや°Øª©ßıØ-Łや®³ØやØ±²やßÔ²°ı-ca nunca sea mayor que 30%. Para obtener esta mé-

trica se utiliza la siguiente función:

〉ｹ《

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

ª©-²Æıœı¾-や œやR-œı¾°やªŁやı²Ø°ªıŸ-やØ-やœや°Ø³-ıŸ-やª©-や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.

1°やØłØß¬œıRª°やœやª²ıµıŁŁやŁØや°Ø¬œ-ØªıŸ-やª©-²ı-nuaremos con el proyecto de “Sistema de gestión de

contenidos” en donde se ilustrará el desarrollo del pro-

½Øª²©や Ł³°-²Øや œ±や ±ıØ²Øや ı²Ø°ªı©-Ø±╆や &-や œや Rº³°やｷや ±Øやß³Ø±²°やœやº°ÀRªやŁØやÆ³°-やŁ©¹- de iteración obtenida al

R-œı¾°やØœや¬°©½Øª²©╆や&-やØ±²やº°ÀRªやØ±や¬©±ıÆœØや¬°Øªı°や®³ØやØ-やœ±やı²Ø°ªı©-Ø±やｱや½やｴやæ³Æ©やªßÆı©±やØ-やØœやœª-ªØや½や°Ø¬Ø°ª³²ıØ°©-や¬°や®³Øや±ØやæıªıØ°や³-や°Ø¬œ-ıRªªıŸ-や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

œやº°ÀRªやŁØやªßÆı©±やØ-やØœやœª-ªØ╉やœやRº³°やｸやıœ³±²°やØœやTSPCA, el cual permaneció menor que 30% del TBTP.

&-やœやRº³°やｹや±Øや¬³ØŁØやµØ°やœやS³ª²³ªıŸ-やŁØやœ©±やç-Łı-ces CPI y SPI. En la tabla 3 se muestra la información

recabada durante cada iteración para poder realizar la

Rº³°やｹ╆&-やœやı²Ø°ªıŸ-やｶや±Øやı-²Øº°ŸやœやØ®³ı¬©やŁØやŁØ±°°©œœ©や

un miembro más para colaborar y terminar en tiempo

Øœや¬°©½Øª²©╆や4Øや¬°Øªıや®³ØやØœや$1*やØ-やœ±やı²Ø°ªı©-Ø±やｶや½や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

ı²Ø°ªı©-Ø±やｶや½やｷやœやµØœ©ªıŁŁやŁØœやØ®³ı¬©やŒ³Øやß½©°ややœや¬œ-ıRªŁ╇やœ©や®³Øや¬Ø°ßı²ıŸや²Ø°ßı-°やØ-や²ıØß¬©╆

El costo real por iteración del proyecto se muestra

Ø-やœや ²Æœやｴ╆や&œや¬°Øªı©や°ØœやŁØœや¬°©½Øª²©やŒ³ØやŁØや┵やｲｵｸ╇やｹｲｳ╆ｰｸやı-ª°ØßØ-²À-Ł©±ØやØ-や³-やｲ╆ｷｴゾ╆や%ØÆıŁ©やや®³ØやØœやproyecto terminó en tiempo y con un presupuesto ma-

½©°やØ-や³-やｲ╆ｷｴゾ╇や¬³ØŁØや±Ø°やª©-±ıŁØ°Ł©やª©ß©やØ¼ı²©±©╆

Guvkocek„p"fgn"equvq

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-

²Øや¬°や±³や¬œ-ıRªªıŸ-や½や®³ØやØœやØ®³ı¬©やŁØやŁØ±°°©œœ©やdel nuevo producto sea maduro.

1SPASPI

VB?

411



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-

µıªıŸ-や Ø±²À-Ł°や ½や ³-や º°ÀRªや ª©-や œや ªß¬-や ŁØや(³±±や¬°やıŁØ-²ıRª°やØœや²ıØß¬©やßÀ±やª©-RÆœØや¬°やœ±やHU que tengan un mismo esfuerzo, es decir, cada con-

ł³-²©やŁØやœ±や)6やØ±²ıßŁ±やØ-やｸや41や²Ø-Ł°À-や±ıº-Ł©±やinherentemente un tiempo estimado para su desarro-

œœ©╇や±çやª©ß©やœ±やØ±²ıßŁ±やØ-やｲや41╇やｴや41╇やｱｳや41╇やｲｰや41╇やetcétera. Esta serie se considera, ya que se utiliza en la

planeación de métodos ágiles (Project Management

*-±²ı²³²Ø╇やｲｰｰｳ╉や4³œıß-や½や#°²©-╇やｲｰｰｶ《╇や¬Ø°©やªŁや©°-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-

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-

Ł©±や ±Øº1-や ±³や Ø±Œ³Ø°¾©╇や ŁØや Œ©°ßや ±ıßıœ°やや œや ®³Øや ±Øやß³Ø±²°やØ-やœや²Æœやｵ╆

&-やœや²Æœやｵや±Øや¬°Øªı-やœ©±や²ıØß¬©±やº±²Ł©±やØ-やæ©-

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

œやº°Rª°や œやŁı±²°ıÆ³ªıŸ-や-©°ßœや¬°や œやªß¬-やŁØや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-

-ªı©-Ø±╈やｰ╆ｲｵやæ©°╇やｰ╆ｵやæ©°±╇やｰ╆ｷｵやæ©°±╇やｱやæ©°╆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

¬°やœ±や)6やª©-やØ±Œ³Ø°¾©やŁØやｸや41╆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

Łı±¬Ø°±ıŸ-╇やœやµ°ı-¾や±ØやŁØR-Øやª©ß©やœやßØŁıやŁØやœ±やdiferencias cuadráticas de n puntuaciones con respec-

to a su media aritmética y se obtiene con la siguiente

fórmula:

(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.

(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.

2 2

1

1( )

n

ii

S x xn ?

? /Â

2S S?

Hkiwtc"90 Burn down"fg"kvgtcek„p":"rctc"gn"rtq{gevq<"ÑUkuvgoc"fg"iguvk„p"fg"eqpvgpkfquÒ



Hkiwtc":0 VUREC"rctc"gn"rtq{gevq<"ÑUkuvgoc"fg"iguvk„p"fg"eqpvgpkfquÒ

Hkiwtc";0"ìpfkegu"ERK"{"URK"rctc"gn"rtq{gevq<"ÑUkuvgoc"fg"iguvk„p"fg"eqpvgpkfquÒ

Iteración

Costo por SP planeado

Costo replaneado siguiente iteración

Costo real

CPI

SPI

0 1 1

1 ｵｱｴ╆ｲｸｵｷｱｴｳｵｸｰ╆ｳｱｶｷｴｲｱｰ╆ｹｷｱｴｲｸｵｷｱｰ╆ｹｷｱｴｲｸｵｷｱ

2 ｵｱｴ╆ｲｸｵｷｱｴｳｴｶｷ╆ｵｳｲｴｶｷｵｵｲｱ╆ｷｳｹｱｳｰｴｰ╆ｹｸｵｷｱｴｲｸｶｰ╆ｹｸｵｷｱｴｲｸｶ

3 ｵｱｴ╆ｲｸｵｷｱｴｳｴｶｱ╆ｵｳｸｴｶｱｵｴｵｵ╆ｶｹｶｲｰｲｵｱ╆ｱｲｸｵｷｱｴｲｹｱ╆ｱｲｸｵｷｱｴｲｹ

ｴｵｱｴ╆ｲｸｵｷｱｴｳｴｸｶ╆ｴｸｶｴｸｶｵｴｸｶ╆ｴｸｶｴｸｶｵｱ╆ｰｵｷｱｴｲｸｵｷｱ╆ｰｵｷｱｴｲｸｵｷ

ｵｵｱｴ╆ｲｸｵｷｱｴｳｴｰｴ╆ｴｹｴｳｸｲｵｹｰ╆ｱｶｳｹｳｴｴｰ╆ｸｷｱｴｲｸｵｷｱｰ╆ｸｷｱｴｲｸｵｷｱ

ｶｵｱｴ╆ｲｸｵｷｱｴｳｴｴｸ╆ｴｲｶｵｷｳｴｴｸｷ╆ｱｷｹｴｸｷｲｱ╆ｰｵｵｶｳｹｰｹｸｱ╆ｱｵｷｱｴｲｸｵｷ

7 ｵｱｴ╆ｲｸｵｷｱｴｳｴｴｸ╆ｴｲｶｵｷｳｴｱ╆ｱｴｶｸｶｷｱｶｸｱ╆ｲｵｷｱｴｲｸｵｷ

Vcdnc"50"ERK"{"URK"fgn"rtq{gevq<"ÑUkuvgoc"fg"iguvk„p"fg"eqpvgpkfquÒ Vcdnc"60"Equvq"tgcn"rqt"kvgtcek„p""gp"gn"rtq{gevq

Iteración Costo Real

1 ┵やｳｶ╇ｰｰｰ╆ｰｰ



ｴ ┵やｳｶ╇ｰｰｰ╆ｰｰ

ｵ ┵やｳｶ╇ｰｰｰ╆ｰｰ

ｶ ┵やｳｹ╇ｴｶｱ╆ｵｴ

7 ┵やｳｹ╇ｴｶｱ╆ｵｴ

┵やｲｵｸ╇ｹｲｳ╆ｰｸ

La distribución normal se calcula con la siguiente fór-

mula:

(12)

1

2

( )

21( , , )

2

N

f x e

Ã Ô/o/Ä ÕÄ ÕuÅ Öo u ? ru

donde ¼やes un tiempo del conjunto de las HU con mismo

esfuerzo, μ es la media o ¼やy u es la desviación estándar

o S.

&-やœや²Æœやｸや±Øやªœª³œやœやŁı±²°ıÆ³ªıŸ-や-©°ßœや¬°やœや¼や½や œや4や©Æ²Ø-ıŁ±やª©-や œや ı-Œ©°ßªıŸ-やŁØや œや ²Æœやｶ╆や-やª©œ³ß-や ŁØや º°³¬©±や ß³Ø±²°や Øœや °-º©や ıŁØ-²ıRªŁ©や ŁØや²ıØß¬©±や¬°やœ±や)6やŁØやｸや41±やŁØやœや²Æœやｶ╆

&-や œやRº³°やｱｰや ±Øやß³Ø±²°や œや ªß¬-やŁØや(³±±や©やdistribución normal para los tiempos de HU de un pro-

½Øª²©やª©-やØ±Œ³Ø°¾©やŁØやｸや41╆や&-やØœœや±Øや¬³ØŁØや ¬°Øªı°や®³Øや¬°や³-や¼やŁØやｱやæ©°や±Øや²ıØ-Øや³-やµœ©°やß³½やªØ°ª-©ややｱ╇やœ©や®³Øや±ıº-ıRªや®³Øや¬°や³-や)6やŁØやｸや41やª©-や¼や½や4や©Æ²Ø--ıŁ±やŁØや œ©±やæı±²Ÿ°ıª©±やß©±²°Ł©±や Ø-や œや ²Æœやｱｱや Ø¼ı±²Øやｹｱ╆ｳゾやŁØや¬°©ÆÆıœıŁŁやŁØや®³ØやØœやØ±Œ³Ø°¾©や-ØªØ±°ı©や¬°や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

ŁØやœ±や)6やØ-や³-やØ±Œ³Ø°¾©やŁØ²Ø°ßı-Ł©や〉Øł╆やｸや41《╇やıŁØ--

²ıRª-Ł©やØœやµœ©°や¬°Øªı±©やª©ß©やœやY más alta en la cur-

va. De esta forma, para estimar el costo de un nuevo

¬°©½Øª²©や¬©ŁØß©±やª©-R°やØ-やœ©±やŁ²©±やæı±²Ÿ°ıª©±やŁØやœ©±や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

°Ø±³œ²Ł©±やŁØやœ±やº°ÀRª±やŁØœやßÔ²©Ł©やŁØやßØŁıªıŸ-や½やœ±やinterpretaciones de sus resultados, así como también

œ±やŁı±ª³±ı©-Ø±や±©Æ°Øやœ±やŁıRª³œ²ŁØ±や½や¬°©ÆœØß±や¬°Ø-

sentados en el estudio.

413



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

Ø-やßÔ²©Ł©±やÀºıœØ±や〉:¬╇やｲｰｰｶ╉や,ØµØ-Ø½や½や$©-Æ©½╇やｲｰｰｶ╉や4³œıß-や½や#°²©-╇やｲｰｰｶ╉や3³±ø╇やｲｰｰｹ《╆

2. Otros autores indican que hay poca evidencia acerca de

la medición de los costos de un proyecto para los ad-

ßı-ı±²°Ł©°Ø±やŁØや¬°©½Øª²©±や〉+©-Ø±╇やｲｰｰｴ╉や4³œıß-や½や#°²©-╇やｲｰｰｶ╉やや3³±ø╇やｲｰｰｹ《╆

3. La estimación de costos en métodos ágiles se basa co-

ß1-ßØ-²Øや Ø-や ł³ıªı©±やŁØや Ø¼¬Ø°²©±や ½や -©や Ø-やprocesos

°Ø¬Ø²ıÆœØ±や ½や ßØł©°ÆœØ±や〉,ØµØ-Ø½や ½や $©-Æ©½╇やｲｰｰｶ╉や1æßや"╆や½や1æßや1╆╇やｲｰｱｱ《╆や4ı-や³-や¬°©ªØ±©やÆıØ-やŁØR-

nido y medible, no es posible lograr una optimiza-

ción ni la reducción de costos.

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

el desarrollo de dos proyectos de software en una peque-

ña empresa del ramo. Su propósito es descubrir las ŁıR-

ª³œ²ŁØ±や©や¬°©ÆœØß± con respecto al uso de la propuesta

en cuanto a la pérdida de costos, precisión en los tiempos,

imprevistos y compromisos con el cliente, desde la perspec-

tiva de un administrador de proyectosやØ-やØœやª©-²Ø¼²©やŁØœやuso de métodos ágiles.

Contexto

El estudio se llevó a cabo en una pequeña empresa de

desarrollo de software basado en procesos ágiles, especí-

RªßØ-²Øや Ø-やScrum y eXtreme Programming. Dos pro-

yectos de software fueron parte del estudio:

ゃややや &œやprimer proyecto (P1) fue el desarrollo de un soft-

ware como servicio (SaaS, Software as a Service) para

gestionar la red de colaboración entre la triple hélice

(gobierno, industria y academia). Se registraron en

el equipo un total de 7 desarrolladores, un total de

ｷｵや)6や ¬œ-ıRªŁ±╇やｲｲや 41や ¬©°や ı²Ø°ªıŸ-╇や ³-や ª©±²©やÆ±ØやŁØや┵ｱｲｸ╆ｶｸや¬Ø±©±やßØ¼ıª-©±や¬©°やªŁや41や〉Øœやª©±-to no contiene impuestos ni ganancias para la em-

¬°Ø±《や½やØœや¬Ø°ı©Ł©やŁØやŁØ±°°©œœ©やŒ³ØやŁØœやｴやŁØやł³-ı©や œやｸやŁØやº©±²©╆や&-やØ±²Øや¬°©½Øª²©や±Øや³²ıœı¾Ÿやœや¬°©¬³Ø±²やde estimación y control de costos.

ゃややや &œや segundo proyecto (P2) fue el desarrollo de una

herramienta de diseño y seguimiento de indicado-

°Ø±╇やŁ©-ŁØや±ØやŁØR-ıØ°©-やı²Ø°ªı©-Ø±やŁØやŁ³°ªıŸ-や±Ø-ß-œ╇やª©-やｴやı²Ø°ªı©-Ø±や¬œ-ıRªŁ±╆や4Øや°Øºı±²°ŸやØ-やØœや Ø®³ı¬©や³-や ²©²œやŁØやｸやŁØ±°°©œœŁ©°Ø±やŁ³°-²Øや Øœや¬°©ªØ±©╇やｴｷやæı±²©°ı±やŁØや³±³°ı©や¬œ-ØŁ±╇や³-やØ±²ı-ßªıŸ-や ŁØやｲｶｳや ¬³-²©±や ŁØや æı±²©°ı╇や ³-や µØœ©ªıŁŁやÆ±Øや ŁØやｶｹや 41や ¬©°や ı²Ø°ªıŸ-や ½や ³-や ª©±²©や Æ±Øや ŁØや┵ｱｲｸ╆ｶｸや¬Ø±©±やßØ¼ıª-©±や¬©°やªŁや41╆や&-やØ±²Øや¬°©-

yecto no se utilizó la propuesta de estimación y con-

²°©œや ŁØや ª©±²©±や ŁØœや ¬°Ø±Ø-²Øや °²çª³œ©╆や 1©°や 1œ²ıß©╇や Øœや

Conjunto esfuerzo 2

Conjunto Ø±Œ³Ø°¾©やｴ

Conjunto Ø±Œ³Ø°¾©やｸ

Conjunto esfuerzo 13

Conjunto esfuerzo 20

1.10 7.00 ｵ╆ｲｱｹ╆ｲｲｳ╆ｶｱ╆ｶｰ 7.00 ｱｶｲｷ╆ｵｳｱ╆ｴｱ╆ｴｵ 7.00 ｸ╆ｳ 23 37.2

ｱｳ╆ｴｰ 7.00 ｹ╆ｲｲｸ╆ｸｳｵ╆ｱｴ╆ｵｰｸｷ╆ｵｱｵ╆ｱｳｰ╆ｵｶ╆ｵｰｷ╆ｵ 11.7 23.2 ｴｲ3.10 7 ｲｳ╆ｵｳ╆ｶｰｸ 17.2

2.00 7 21.2

7 ｱｳ╆ｵｶ 12.1

ｷ╆ｵ 21.3

7 ｱｹ╆ｶｸｱｱ╆ｴｸｱｵ╆ｳ7 ｱｸ╆ｷ7 21.1

ｶｲｵ╆ｶ7 17

ｷ╆ｵｲｵ╆ｲ

Vcdnc"70"Vkgorqu"citwrcfqu"rqt"guhwgt¦q"rctc"wp"rtq{gevq



¬Ø°ı©Ł©やŁØやŁØ±°°©œœ©やŒ³ØやŁØœやｲｵやŁØや±Ø¬²ıØßÆ°Øやœやｸやde noviembre.

Análisis e interpretación

"やª©-²ı-³ªıŸ-や ±Øや¬°Ø±Ø-²-や œ©±や °Ø±³œ²Ł©±やR-œØ±やŁØやœ©±や¬°©½Øª²©±やØ-やœ±やº°ÀRª±やª©°°Ø±¬©-ŁıØ-²Ø±╆や

&œや¬°©½Øª²©や1ｱや-©やºØ-Ø°Ÿやœ©±や±³RªıØ-²Ø±やŁ²©±や¬°やºØ-Ø°°や œ±や º°ÀRª±や ŁØや Ø±²ıßªı©-Ø±や ŁØや Ø±Œ³Ø°¾©±╇や ½や®³Øや-©や±Øやª©-²Æやª©-やŁ²©±やæı±²Ÿ°ıª©±や±³RªıØ-²Ø±╆や4ı-やØßÆ°º©╇や œやØ±²ıßªıŸ-やŁØや œ©±やØ¼¬Ø°²©±や Œ³Øや±³RªıØ-²Ø╇やya que este era un diseño de desarrollo conocido por el

ªœıØ-²Ø╆や -±や º°ÀRª±や ºØ-Ø°Ł±や ŁØœやßÔ²©Ł©や¬°©¬³Ø±²©や±©-やœやº°ÀRªやÆ³°-やŁ©¹- al cierre del proyecto, como se

¬³ØŁØや¬°Øªı°やØ-やœやRº³°やｱｱ╇や½やœやº°ÀRªや$1*の41*や²ß-

ÆıÔ-やœやªıØ°°ØやŁØœや¬°©½Øª²©やØ-やœやRº³°やｱｲ╆-±や±Ø°ıØ±やŁØやŁ²©±やŁØやœやº°ÀRªやÆ³°-やŁ©¹- se descri-

ben como el avance planeado, que muestra el esfuerzo

restante para su desarrollo, obtenido durante la etapa

ŁØや ¬œ-ØªıŸ-╉や Øœや µ-ªØやreal, que muestra el valor ga-

nado durante cada iteración,

así como los cambios en el

alcance, mostrando picos

cuando el alcance crece o se

agrega esfuerzo al desarrollo

½や Øœや µ-ªØや °Øま¬œ-ıRªŁ©╇やque muestra el avance repla-

-ıRªŁ©や¬°やªŁやı²Ø°ªıŸ-╆やComo se puede apreciar en

los resultados, el avance real

fue más rápido de lo planea-

do debido al conocimiento

de la solución del sistema, es

decir, un sistema bastante

ª©-©ªıŁ©や ¬©°や œ©±や Ø¼¬Ø°²©±やrespecto a las entrevistas con

el cliente. Es por esto que no

Œ³Øや -ØªØ±°ıや ³-や °Ø¬œ-ıR-

cación. Este método de me-

dición es de mayor utilidad

para proyectos en donde se

desconoce el problema para

poder tomar decisiones res-

¬Øª²©ややœ±や°Ø¬œ-ıRªªı©-Ø±╇やcomo resultados esperados

de esfuerzo.

3Ø±¬Øª²©ややœやº°ÀRªやŁØや$1*のSPI en el cierre del proyecto

〉Rº³°やｱｲ《╇や -©や ß³Ø±²°や °Ø-

sultados inesperados con-

forme al tiempo y al costo,

fueron resultados controla-

dos en todo momento. Los

resultados fueron, por lo

mismo, una solución cono-

cida y entendida por las ne-

cesidades del cliente. Por

1œ²ıß©╇や -©や ±Øや ºØ-Ø°Ÿや ³-やº°ÀRªや541$"やŁØÆıŁ©やや®³Øやno se creó un valor agrega-

do a las historias de usuario

durante el desarrollo del

proyecto.

En el segundo proyecto,

al igual que en el primero,

1-や-©や±Øや²Ø-ç-やœ©±や±³RªıØ-²Ø±やŁ²©±やæı±²Ÿ°ıª©±や¬°やºØ--Ø°°やœ±やØ±²ıßªı©-Ø±や±©Æ°Øやœ©±やØ±Œ³Ø°¾©±╆や-やº°ÀRªやŁØやla que se parte para la toma de decisiones es la Æ³°-やdownやØ-やœや®³Øや±Øやß³Ø±²°-やœ±やŁıRª³œ²ŁØ±やŁØやª©-²°©œ╇や¬°ı-ªı¬œßØ-²ØやŁØやœや±Øº³-Łやı²Ø°ªıŸ-ややœや®³ı-²╉や¬°や

Conjunto de tiempos ¬°やØ±Œ³Ø°¾©やｸ

1.00

1.00

ややややややややややややややｰ╆ｵｰ

1.00

ややややややややややややややｱ╆ｵ

1

ややややややややややややややｱ╆ｲｵ

1

ややややややややややややややｰ╆ｷｵ

ややややややややややややややｰ╆ｵ



ややややややややややややややｱ╆ｵ

1


ややややややややややややややｰ╆ｷｵ

ややややややややややややややｱ╆ｷｵ


2


1

Vcdnc"80"Vkgorqu"jkuv„tkequ"fgn"rtq{gevq"rctc"JWu"eqp"guhwgt¦q"fg":"UR"wvknk¦cpfq"nc"ugtkg"rtqrwguvc"fg"vkgorqu

Vcdnc"90"Xcnqtgu"fg"z."U4"{"U"rctc"gn"eqplwpvq"fg"vkgorqu"fg"JWu"eqp"guhwgt¦q"fg":"UR"fg"nc"vcdnc"8

X 1.03

S2 ｰ╆ｱｹｰｱｳｱｵｷｹS ｰ╆ｴｳｶｰｴｰｸ

Hkiwtc"320 Fkuvtkdwek„p"pqtocn"rctc"nqu"vkgorqu"fg"JWu"eqp"guhwgt¦q"fg":"UR

Hkiwtc"330 Burn down"cn"ekgttg"fgn"rtq{gevq"R3

415



ØŒØª²©±や ŁØや Ø-ª©-²°°や œ±や ŁıRª³œ²ŁØ±や ½や ¬°©ÆœØß±や ŁØœやmétodo de medición se discuten dichas iteraciones. Las

º°ÀRª±や³²ıœı¾Ł±や ±©-や œ±やŁØや œや Rº³°やｱｳや ª©-や œやÆ³°-やdownや œやªıØ°°ØやŁØœや¬°©½Øª²©╇やœやRº³°やｱｴ╇やª©-やº°ÀRªや$1*の41*やœやªıØ°°ØやŁØœや¬°©½Øª²©╇や½やœやRº³°やｱｵやª©-やœやº°ÀRªやTSPCA para el cierre del proyecto.

A continuación se describen las discusiones de los

¬°©ÆœØß±や ½や œ±や ŁıRª³œ²ŁØ±や ŁØや œ±や ı²Ø°ªı©-Ø±や Ø-や Øœややproyecto.

Iteración 2

El esfuerzo que el equipo estimó desarrollar en esta ite-

°ªıŸ-やŒ³ØやŁØやｶｶや41╇や¬Ø°©や°ØœßØ-²ØやØœやValor Ganado (EV)

Œ³Øやｵｰや41╆や&±²Øや°Ø±³œ²Ł©やØ-や&7や²ıØ-Øや³-やıß¬ª²©やŁı°Øª²©やØ-やØœやª©±²©╉やØœやç-ŁıªØやŁØœやŁØ±Øß¬Øü©やŁØœやª©±²©や〉$1*《や¬°や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-

²©やŁØや┵ｱｷｵ╆ｰｰ╇やｳｶゾやßÀ±やª°©や¬°やØœやŁØ±°°©œœ©やŁØや³-や41╆や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

tecnologías adquiridas en la empresa.

Al cierre de la iteración 2, el equipo se reunió con el

cliente para mostrar los avances y obtener alguna re-

troalimentación acerca de las tareas desarrolladas.

$©ß©や °Ø±³œ²Ł©や ±Øや º°Øº°©-やｱｳｵや 41や ª©ß©や ŁØ±ª³Æ°ı-ßıØ-²©やŁØや-³Øµ±やØµıŁØ-ªı±╇や®³Øや°Ø¬°Ø±Ø-²°©-やｵｱ╆ｳゾやdel total del producto planeado, lo que ponía en riesgo

la terminación en tiempo y costo del desarrollo del pro-

ducto, además de que la velocidad de desarrollo era

más lenta. Por estas razones se decidió agregar 2 desa-

rrolladores más al inicio de la tercera iteración.

Iteración 3

Al inicio de la iteración 3 el alcance del proyecto ya ha-

Æçや³ßØ-²Ł©やｵｴやゾ╇や¬©°やœ©や®³Øや±Øやº°Øº°©-やŁ©±やŁØ±-

rrolladores más al equipo para aumentar la produc-

tividad de SP en el proyecto. El impacto en el costo de

º°Øº°ややŁ©±やŁØ±°°©œœŁ©°Ø±や Œ³ØやｶｸゾやßÀ±や ª°©や¬°やØ±²や ı²Ø°ªıŸ-╆や&-やØ±²Øや¬°©½Øª²©や ²°ÆłŸやØœやØ®³ı¬©やｲ╉やœや²Ô°ßı-©やŁØやœやı²Ø°ªıŸ-やœやµØœ©ªıŁŁやŁØやŁØ±°°©œœ©やŒ³ØやｶｹやSP, acorde a lo esperado en el plan, dicho de otra forma,

Vcdnc":0"Fkuvtkdwek„p"pqtocn"rctc"nc"x {"U"rctc"gn"itwrq"fg"vkgorqu"fg"JWu"eqp":"UR."kfgpvkhkecfqu"gp"nc"vcdnc"8

Grupos Distribución Normal

0 ｰ╆ｰｵｷｷｳｹｸｱｳ

ｰ╆ｲｵｰ╆ｱｸｸｵｴｵｲｳｳ

ｰ╆ｵｰ╆ｴｴｳｱｹｴｷｱｹ

ｰ╆ｷｵｰ╆ｷｴｹｹｱｵｶｸｲ

1 ｰ╆ｹｱｳｴｱｷｰｸｹ

ｱ╆ｲｵｰ╆ｸｰｰｸｷｴｸｷｲ

ｱ╆ｵｰ╆ｵｰｵｴｷｴｲｵｵ

ｱ╆ｷｵｰ╆ｲｲｹｶｵｳｰｶｹ

2 ｰ╆ｰｷｵｱｰｷｶｷｲ

Hkiwtc"34. ERK1URK"cn"ekgttg"fgn"rtq{gevq"R3

Hkiwtc"350 Burn down"cn"ekgttg"fgn"rtq{gevq"R4

Hkiwtc"360 ERK1URK"Cn"ekgttg"fgn"rtq{gevq"R4



el SPI tuvo un valor igual a 1, ya que el equipo avanzó

ª©-Œ©°ßØややœや¬œ-ØªıŸ-やı-ıªıœ╆や"³ßØ-²°やØœや-1ßØ°©やde desarrolladores incrementó el costo de la iteración y

Øœやª©±²©やŁØやŁØ±°°©œœ©やŁØや³-や41╇やØœや$1*やŒ³Øやｰ╆ｶｶ╇やØœやª³œやØµıŁØ-ªıやØœや³ßØ-²©やØ-やØœやª©±²©╇やｶｶゾやßÀ±やª°©╆

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-

ÆœØやµı±³œı¾-Ł©やœやº°ÀRªやŁØœやÆ³°-やŁ©¹- para este pro-

½Øª²©╇や½や®³ØやØœやØ®³ı¬©やØ±¬Ø°Æや²Ø-Ø°や³-や°Ø±²-²ØやŁØやｵｹや41や¬Ø°©や±³ÆıŸややｳｷｸや41やØœやµœ©°や°Øœ╆や5©ß-Ł©やØ-やª³Ø-²やestos valores el remanente al cierre de la iteración 3 se

Ł³¬œıªŸ╇やØ-やœやRº³°やｱｳや±Øや©Æ±Ø°µや³-や³ßØ-²©やŁØやｱｰｰゾやmás respecto al valor planeado.

Iteración 4

En esta iteración el encargado del desarrollo, agregó un

ŁØ±°°©œœŁ©°やßÀ±╇やª©ß¬œØ²-Ł©やœ©±やｸやŁØ±°°©œœŁ©°Ø±やŁØœやØ®³ı¬©╇やØ±²©や©ª±ı©-Ÿや®³Øや±³ÆıØ°やØœやª©±²©や¬©°やØœや-1ßØ°©やŁØやı-²Øº°-²Ø±╆や&œやµœ©°やº-Ł©やØ-やØ±²やı²Ø°ªıŸ-やŒ³Øやｹｲや41╇やｳｵゾやßÀ±や°À¬ıŁ©やØ-や±³やŁØ±°°©œœ©やª©-や³-や41*やØ®³ıµœØ-²Øややｱ╆ｳｵ╆や&œや ª©±²©や±³ßıŁ©や¬°やØ±²や ı²Ø°ªıŸ-や Œ³Øやß½©°╇やØœや$1*や©Æ²Ø-ıŁ©やŒ³Øやıº³œややｰ╆ｶｸ╇やｳｲゾやßÀ±やª°©╆

Basados en la planeación inicial es en esta iteración

cuando el proyecto debió terminar su fase de desarro-

œœ©╇やœやØ±²°や1-やｲｸｶや41やœØłŁ©±やŁØやœやßØ²╇ややœやª³œや±Øや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

Ø®³ı¬©やｳ╆や"œやªıØ°°Ø╇やØœやµœ©°やº-Ł©やŒ³Øやｲｸｸや41╇や®³ØŁ--

do solo un restante de 2 SP. Acorde al SPI tenemos que

œやµØœ©ªıŁŁやŁØœやØ®³ı¬©やŒ³Øやｴ╆ｲｳやß½©°や®³Øやœや¬œ-ØŁや〉Rº³°やｱｴ《╇やｳｲｳゾやßÀ±や°À¬ıŁ©やŁØやœ©や¬œ-ØŁ©╆や&œやª©±²©やŁØやdesarrollar un SP en esta iteración fue más barato, con

³-や$1*や ıº³œややｲ╆ｱｴ╇や œ©や®³Øや±ıº-ıRªや®³ØやŒ³ØやｵｴゾやßÀ±やÆ°²©や®³Øやœ©や¬œ-ØŁ©╆や1°©ÆÆœØßØ-²Ø╇や œ©±やÆØ-ØRªı©±や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.

"œやR-œı¾°やœやı²Ø°ªıŸ-や±Øやº°Øº°©-やｱｴｹや41╇や±ıº-ıR-

ª-Ł©やｵｳゾやŁØœや¬Ø±©や¬œ-ØŁ©や¬°やØœや¬°©½Øª²©や½や±Øや©Æ-

²³µ©や ³-や ±³ßや ŁØや ªßÆı©±や Ø-や Øœや œª-ªØや ŁØやｱｵｸ╆ｱｷゾや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.

$©-Œ©°ßØややœ±やŁıRª³œ²ŁØ±や½や¬°©ÆœØß±や±Øやª©-ªœ³½Øやque es necesario crear un proceso de toma de decisiones

³²ıœı¾-Ł©やœ±やº°Rª±や½やœ©±や°Øª³°±©±やæ³ß-©±╇やŁØやı-Œ©°-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や Àºıœや ª©-や œやR-œıŁŁやŁØや °Ø±©œµØ°や œ©±や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

ŁØやØ±²±やŁØRªıØ-ªı±やØ±や®³Øや œ©±やßÔ²©Ł©±やÀºıœØ±や±ıº³Ø-やœ©±や¬°ı-ªı¬ı©±やŁØœやß-ıRØ±²©やÀºıœ╆や&œや¬°ı-ªı¬ı©やŁØやØ±²や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

°ØSØ¼ı©-や±©Æ°Øぉ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-

ł©や©Œ°ØªØや²°Ø±や²ı¬©±やŁØやº°ÀRª±や¬°や¬©½°やœ©±や¬°©ÆœØ-ß±やßØ-ªı©-Ł©±╈やœやº°ÀRªや541$"や¬°やØœやª©-²°©œやŁØやcambios realizados en el proyecto y no sobrepasar el

tamaño del proyecto de softwareやØ-やｳｰゾ╇やœやº°ÀRªや$1*のSPI para el control de costo por SP y calendario, y la

º°ÀRªやÆ³°-やŁ©¹-や®³Øや¬Ø°ßı²Øや°Ø¬°Ø±Ø-²°やœや°Ø¬œ-ıR-

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-

Hkiwtc"370 VUREC"rctc"gn"ekgttg"fgn"rtq{gevq"R4

417



tos históricos de proyectos anteriores y actuales no fue

±³RªıØ-²Øや¬°やı-²°©Ł³ªı°やŁ²©±や½やª©ß¬°©Æ°やœやØRªªıやde las evidencias de estimaciones. También se presenta-

°©-や ŁıRª³œ²ŁØ±や Ł³°-²Øや œ±や ı²Ø°ªı©-Ø±や ŁØœや ±Øº³-Ł©や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

œ±やŁıRª³œ²ŁØ±や½や¬°©ÆœØß±や¬°Ø±Ø-²Ł©±やØ-やœ©±や¬°©½Øª-²©±やŁØやß-Ø°や®³Øや±Øや³²ıœıªØ-やœ±や²°Ø±やº°Rª±や¬°や³-やtoma de decisiones efectiva.

Para lograr realizar estas estimaciones sin afectar al

ß-ıRØ±²©やÀºıœ╇やª²³œßØ-²Øや±ØやØ±²ÀやŁØ±°°©œœ-Ł©や³-やæØ°°ßıØ-²や ¬°や ºØ-Ø°°や œ±や º°ÀRª±や｠%ı±²°ıÆ³ªıŸ-や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

30"Vfitokpqu"{"fghkpkekqpgu""""""eqowpgu"gp"ofivqfqu"ƒikngu

Para entender mejor la forma en que los métodos ágiles

monitorean y estiman el costo de los proyectos es nece-

±°ı©やŁØR-ı°やœ©±やª©-ªØ¬²©±や³²ıœı¾Ł©±やØ-やØ±²Øや²ı¬©やŁØやŁ-

ßı-ı±²°ªıŸ-╆や&-やØ±²Øや-Ø¼©や±ØやŁØR-Øや®³ÔやØ±や³-や¬³-²©やde historia, qué es una historia de usuario, qué es una

iteración (sprint《╇やœやµØœ©ªıŁŁやŁØやı²Ø°ªıŸ-や½やœ±やº°ÀRª±やÆ³°-やŁ©¹-.

Las historias de usuario (HU) son la unidad más pe-

®³ØüやŁßı-ı±²°ŁやØ-やØœや¬°©½Øª²©や½や±ØやŁØR-Ø-やØ-や+ØŒ°-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,

³-や²ßü©や°Øœ²ıµ©╇や³-やµœ©°やŁØや-Øº©ªı©や®³ØやŁØR-Øや®³Ôやtan importante es esta HU para el negocio y uno o más

ª°ı²Ø°ı©±やŁØやµœıŁªıŸ-や¬°やŁØR-ı°や±ıやØ±²Àや²Ø°ßı-Ł╆や-やmanera de documentar los requerimientos de un pro-

ducto en métodos ágiles es utilizar historias de usuario.

$©æ-や〉ｲｰｰｴ《やª©-²ıØ-ØやßÀ±やı-Œ©°ßªıŸ-╆1°やŁØR-ı°やØœや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やŁØR-Ø-や®³Ôや²-やº°-ŁØやØ±やØœやØ±Œ³Ø°¾©や-Ø-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-

-ØªıŸ-や¬°やŁØR-ı°やœ±や)6±や®³Øや±Ø°À-やŁØ±°°©œœŁ±や½や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

ŁØ±°°©œœ©や±ØやßıŁØやÆ±À-Ł©±ØやØ-やØœや-1ßØ°©やŁØや41やŁØ±-

rrollados y aceptados por el cliente durante cada itera-

ción, esta métrica se llama velocidad de la iteración.

-やæØ°°ßıØ-²やßÀ±や ª©ß1-や Ø-や œ©±やßÔ²©Ł©±や ÀºıœØ±やpara monitorear el avance del proyecto son las º°ÀRª±やburn downや〉Rº³°やｱｶ《╉や Ø-や Ø±²や º°ÀRªや ±Øや ß³Ø±²°や Øœやavance de desarrollo de un equipo durante cada itera-

ción, mostrando los SP faltantes para su desarrollo, en

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

Hkiwtc"380"Itƒhkec"dwtp"fqyp"rctc"oquvtct"nqu"URu"tguvcpvgu"rctc"gn"fgucttqnnq



bajo el modelo de softwareやª©ß©や±Ø°µıªı©をやª©-や-1ßØ°©やŁØや¬°©½Øª²©やｰｰｰｰｰｰｰｰｰｱｸｱｱｷｲ╆

Referencias

"-ŁØ°±©-や%╆+╆やAgile Management for Software Engineering: Applying

the Theory of Constraints for Business Results, Coad Series, Pren-

tice Hall Computer, EUA, 2003.

"º°¹œや/╆╇やや3²æ©Łや6╆や%ØR-ı-ºや4³ªªØ±±やŒ©°や4©Œ²¹°Øや1°©łØª²±╈や"-や&¼¬œ©°²©°½や3ØµØœ²ı©-╆やInternational Journal of Project Manage-

ment╇やµ©œ³ßØ-やｲｴや〉-1ßØ°©やｴ《╇やｲｰｰｶ╈やｳｵｸまｳｷｰ╆$æ©¹や5╆╇やや$©や%╆#╆や"や4³°µØ½や4²³Ł½や©Œや$°ı²ıªœや4³ªªØ±±や'ª²©°±やı-や

"ºıœØや4©Œ²¹°Øや1°©łØª²±╆やJournal of Systems and Software, volu-

ßØ-やｸｱや〉-1ßØ°©やｶ《╇やł³-ı©やŁØやｲｰｰｸ╈やｹｶｱまｹｷｱ╆Cohn M. Agile Estimating and Planning╇や1°Ø-²ıªØや)œœ╇や&6"╇やｲｰｰｵ╆Cohn M. User Stories Applied: For Agile Software Development, Addi-

±©-ま8Ø±œØ½や1°©ŒØ±±ı©-œ╇や&6"╇やｲｰｰｴ╆%ØØßØ°や1╆╇や#Ø-ØRØœŁや(╆╇や-°ß-や$╆やThe SCRUM Primer, Scrum

Training Institute, EUA, 2010, pp. 1–22.

+ØT°ıØ±や3╆╇や"-ŁØ°±©-や"╆╇や)Ø-Ł°ıªø±©-や$╆や&¼²°ØßØや1°©º°ßßı-ºや*-±-talled, 2000. The XP Series.

や+©-Ø±や$╆や4©Œ²¹°Øや1°©łØª²や.-ºØßØ-²や1°ª²ıªØ±╈や'ıœ³°Øや7Ø°±³±やSuccess. The Journal of Defense Software╇や〉-1ßØ°©や ©ª²³Æ°Ø《╇やｲｰｰｴ╈やｵむｹ╆

Kang S. y Choi O. Model-Based Dynamic Cost Estimation and

5°ªøı-ºや.Ø²æ©ŁやŒ©°や"ºıœØや4©Œ²¹°Øや%ØµØœ©¬ßØ-²╇やØ-╈や4ªıØ--

ªØや〉*$*4《╇やｲｰｱｰや*&&&の"$*4やｹ²æ╇やº©±²©やŁØやｲｰｱｰ╇や¬¬╆やｷｴｳまｷｴｸ╆Keaveney S. y Conboy K. Cost Estimation in Agile Development Pro-

łØª²±╇やØ-╈や1°©ª╆やｱｴ²æや&³°©¬Ø-や$©-Œ╆や*-Œ©°ß²ı©-╇やｲｰｰｶ╇やや¬¬╆やｱまｱｵ╆--²ıや.╆や½や,Øm³-Ø-や1╆や$©±²や.©ŁØœı-ºや"ºıœØや4©Œ²¹°Øや%ØµØœ©¬-

ment. International Transactions on Systems Science and Applica-

tions╇やµ©œ³ßØ-やｱや〉-1ßØ°©やｲ《╇やｲｰｰｶ╈やｱｷｵまｱｷｹ╆

Miranda E. y Bourque P. Agile Monitoring Using the Line of Ba-

lance. Journal of Systems and Software╇やµ©œ³ßØ-やｸｳや〉-1ßØ°©やｷ《╇やł³œı©やŁØやｲｰｱｰ╈やｱｲｰｵまｱｲｱｵ╆

Pham A. y Pham P. Scrum in Action: Agile Software Project Manage-

ment and Development, Cengage Learning Center, Boston,

ESUA 2011, pp. 17-31.

Project Management Institute. Guide to the Project Management

#©Ł½や©Œや,-©¹œØŁºØやまや1.#0,せや(³ıŁØやｲｰｰｳや&Łı²ı©-╇やｲｰｰｳ╆3¹±²æ©°-Øや%╆や.©-ı²©°ı-ºや 4ª°³ßや1°©łØª²±や¹ı²æや"ºıœØ&7.や-Łや

Earned Business Value (EBV) Metrics. Agile Journal, volumen

ｰ╇やｲｰｰｸ╆3³±øや+╆や&°-ØŁや7œ³ØやŒ©°や"ºıœØや%ØµØœ©¬ßØ-²╆やSoftware Tech News,

µ©œ³ßØ-やｱｲや〉-1ßØ°©やｱ《╇やｲｰｰｹ╈やｲｰまｲｷ╆SulaimanT. y Barton B. AgileEVM-Earned Value Management in

4ª°³ßや1°©łØª²±╇やØ-╈や"ºıœØや$©-ŒØ°Ø-ªØ╇やｲｰｰｶ╆や:¬や.╆や7œ³Øや#±ØŁや&¼²°ØßØや1°©º°ßßı-º╇やØ-╈や"ºıœØや$©-ŒØ°Ø--

ce, ｲｰｰｶ╆

Este artículo se cita:

Citación estilo Chicago

Okvtg/Jgtpƒpfg¦."Jwiq"C0."Gfict"Qtvgic/Octv‡pg¦."Ewcwjvfioqe"Ngowu/Qncnfg0"Guvkocek„p"{"eqpvtqn"fg"equvqu"gp"ofivqfqu"ƒikngu"rctc"fgucttqnnq"fg"software<"wp"ecuq"fg"guvwfkq0"IngenierÌa Inves-

tigaciÒn y TecnologÌa."ZX."25"*4236+<"625/63:0

Citación estilo ISO 690

Okvtg/Jgtpƒpfg¦"J0C0."Qtvgic/Octv‡pg¦"G0."Ngowu/Qncnfg"E0"Guvk-ocek„p"{"eqpvtqn"fg"equvqu"gp"ogvqfqu"ƒikngu"rctc"fgucttqnnq"fg"software<"wp"ecuq"fg"guvwfkq0"IngenierÌa InvestigaciÒn y Tecnolo-

gÌa."xqnwogp"ZX"*p¿ogtq"5+."lwnkq/ugrvkgodtg"4236<"625/63:0

Semblanza de los autores

Hugo A. Mitre-Hernández. Investigador en ingeniería del software en CIMAT, Unidad Zacatecas, Mé-

¼ıª©╇やRœıŁ©やØ-やØœやº°³¬©や4&-ま6$ｳ.や〉4©Œ²¹°Øや&-ºı-ØØ°ı-ºや-Æ) de la Universidad Carlos III de

.Ł°ıŁや½や¬Ø°²Ø-ØªØやœや4ı±²Øßや/ªı©-œやŁØや*µØ±²ıºŁ©°Ø±や〉4/*《やŁØや.Ô¼ıª©╆や&-やØœやｲｰｱｰ╇やR-œı¾Ÿや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

ß±²Ø°やªØ°²ıRªŁ©や¬©°やœや4ª°³ßや"œœı-ªØ╆や3ØªıÔ-や©Æ²³µ©や±³やº°Ł©やŁØやßØ±²°çやØ-やı-ºØ-ıØ°çやŁØや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

&±²³Łı©±や4³¬Ø°ı©°やŁØや.©-²Ø°°Ø½╇や$ß¬³±や.©-²Ø°°Ø½や〉ｱｹｸｶ《╆や"æçやØ±²³ŁıŸやœやßØ±²°çやØ-やªıØ-ªı±やª©ß¬³²ªı©-œØ±や〉ｱｹｸｸ《╇や¬°やœ³Øº©や©Æ²Ø-Ø°やŁ©ª²©°Ł©やØ-やœやßı±ßやß²Ø°ıや¬©°やœや6-ıµØ°±ıŁŁやŁØや5³œ-Ø╇や/³Øµや0°œØ-±や〉ｱｹｹｶ《╆や&-やœや6-ıµØ°±ıŁŁやŁØや)©³±²©-ま$œØ°や-øØ╇や°Øœı¾Ÿや³-や¬©±²Ł©ª-torado en calidad de investigador visitante como parte del programa aeroespacial del Instituto

¬°や©¬Ø°ªı©-Ø±やŁØや±ı±²Øß±やØ±¬ªıœØ±╇やØ-やª©©°Łı-ªıŸ-やª©-やœや/"4"や½やØœや$Ø-²°©や&±¬ªıœや+©-

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.

Documents

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