• No se han encontrado resultados

Estimación y control de costos en métodos ágiles para desarrollo de software: un caso de estudio

N/A
N/A
Protected

Academic year: 2021

Share "Estimación y control de costos en métodos ágiles para desarrollo de software: un caso de estudio"

Copied!
16
0
0

Texto completo

(1)

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éxico

Correo: hmitre@cimat.mx

Ortega-Martínez Edgar

Centro de Investigación en Matemáticas (CIMAT) Ciencias de la Computación, Zacatecas, México

Correo: eortegam@cimat.mx

Lemus-Olalde Cuauhtémoc

Centro de Investigación en Matemáticas (CIMAT)

Ciencias de la Computación, Zacatecas, México Correo: clemola@cimat.mx

Descriptores: ‡ JHVWLyQGHOsoftware ‡ JHVWLyQGHFRVWRV ‡ PpWRGRViJLOHV

‡ GHVDUUROORGHsoftwareiJLO ‡ 6DD6

Resumen

El desarrollo de software utilizando métodos ágiles está en crecimiento debi- ˜ȱŠȱ•Šȱ™›˜žŒ’Ÿ’ŠȱŠœ˜Œ’ŠŠȱŠȱŽœŠœȱ–Ž˜˜•˜ÇŠœǰȱŠŽ–¤œȱŽȱ•Šȱ̎¡’‹’•’-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- ••˜ǰȱŠ•ȱ’žŠ•ȱšžŽȱ•˜œȱŠ–’—’œ›Š˜›ŽœȱŽȱ™›˜¢ŽŒ˜œȱ—˜ȱŒžŽ—Š—ȱŒ˜—ȱ•Šœȱœžę-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 softsoft-ware 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.

(2)

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 ’—žœ›’Šȱ ŠŒžŠ•–Ž—Žȱ œ˜—DZȱ ¡›Ž–Žȱ ›˜›Š––’—ȱ ǻŽ-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ȱ›Žž—’Ž›˜—ȱœžœȱ’ŽŠœȱ¢ȱŒ›ŽŠ›˜—ȱŽ•ȱ–Š—’ęŽœ˜ȱ¤’•ǰȱ 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 Ž¡’˜œ˜œȱœŽø—ȱ˜—ŽœȱǻŘŖŖŚǼǰȱŒ˜—œ’Ž›Š—˜ȱž—ȱ™›˜¢ŽŒ˜ȱ Ž¡’˜œ˜ȱŒ˜–˜ȱŽ•ȱšžŽȱŽ›–’—ŠȱŽ—›˜ȱŽ•ȱ’Ž–™˜ǰȱŒ˜œ˜ȱ¢ȱ ŒŠ•’ŠȱŽœ™Ž›ŠŠȱǻ˜—ŽœǰȱŘŖŖř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-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 ǻŠ™ǰȱŘŖŖŜDzȱŽŠŸŽ—Ž¢ȱ¢ȱ˜—‹˜¢ǰȱŘŖŖŜDzȱž•Š’–Š—ȱ¢ȱŠ›- ˜—ǰȱŘŖŖŜDzȱžœ”ǰȱŘŖŖşǼǰȱŠŽ–¤œȱŽȱŒŠ›ŽŒŽ›ȱŽȱ•ŠȱŽ—Ž›Š-Œ’à—ȱŽȱŽŸ’Ž—Œ’Šœȱǻ˜—ŽœǰȱŘŖŖŚDzȱž•Š’–Š—ȱ¢ȱŠ›˜—ǰȱŘŖŖŜ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á minimimonitori-zar 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, œ’ž’Ž—˜ȱ•˜œȱ™›’—Œ’™’˜œȱŽ•ȱ–Š—’ęŽœ˜ȱ¤’•ȱ¢ȱŠ‹˜›Š—˜ȱ 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ȱŽ—ȱ•ŠȱŒžŠ›ŠȱœŽŒŒ’à—ȱœŽȱŽœŠ››˜••Šȱ Abstract

The development of software (SW) using agile methods is growing due to the pro-žŒ’Ÿ’¢ȱŠœœ˜Œ’ŠŽȱ ’‘ȱ‘ŽœŽȱ–Ž‘˜˜•˜’Žœǰȱ’—ȱŠ’’˜—ȱ˜ȱ‘Žȱ̎¡’‹’•’¢ȱœ‘˜ —ȱ’—ȱ 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 žœ’—ȱ‘Žȱ™›˜™˜œŠ•ȱ˜›ȱ˜ Š›ŽȱŠœȱŠȱŽ›Ÿ’ŒŽȱǻŠŠǼȱŠ—ȱŽ‹ȱŠ™™•’ŒŠ’˜—ȱ™›˜“ŽŒœǯȱ The results found were that the proposal generates a high degree of evidence for ™›˜“ŽŒȱ–Š—ŠŽ›œǰȱ‹žȱ’ȱ‘Šœȱœ‘˜›Œ˜–’—œȱ’—ȱ‘ŽȱŠ–’—’œ›Š’˜—ȱ˜ȱ‘ŽȱŽŸ’Ž—ŒŽȱ˜›ȱ ‘ŽȱŒ˜—›˜•ȱŠ—ȱŽŒ’œ’˜—ȱ–Š”’—ǰȱ ‘’Œ‘ȱ•Žȱ˜ȱŠȱŽę—’’˜—ȱ˜ȱŠȱŽŒ’œ’˜—ȱ–Š”’—ȱ™›˜ -ŒŽœœȱ˜ȱ‹ŽȱŒ˜ž™•Žȱ ’‘ȱ‘Žȱ–ŽŠœž›Ž–Ž—ȱ™›˜™˜œŠ•ǯ Keywords: ‡ software management ‡cost management ‡agile methods

‡agile software development ‡SaaS

(3)

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 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-—˜œȱŽȱ•˜ȱ™•Š—ŽŠ˜ǰȱž—ȱȱ–Ž—˜›ȱšžŽȱŗȱœ’—’ęŒŠȱšžŽȱœŽȱ 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 proyeccos-to 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 tradicioȦȬŝŚŞǯȱžœ”ǰȱ‹ŠœŠ˜ȱŽ—ȱœžȱŽ¡™Ž›’Ž—Œ’Šȱ–Ž—Œ’˜-nal de EVM encaja bastante bien en los métodos ágiles y que es muy fácil entender œžȱŠ™•’ŒŠŒ’à—ǯȱŽø—ȱžœ”ǰȱŒ˜—˜ŒŽ›ȱŽ•ȱŒ˜—Ž¡˜ȱꗊ—Œ’Ž-ro de los pœžȱŠ™•’ŒŠŒ’à—ǯȱŽø—ȱžœ”ǰȱŒ˜—˜ŒŽ›ȱŽ•ȱŒ˜—Ž¡˜ȱꗊ—Œ’Ž-royectos desarœžȱŠ™•’ŒŠŒ’à—ǯȱŽø—ȱžœ”ǰȱŒ˜—˜ŒŽ›ȱŽ•ȱŒ˜—Ž¡˜ȱꗊ—Œ’Ž-rollados 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 $JLOH(906XODLPDQ\%DUWRQ

(4)

ž’•’£àȱž—Šȱ›¤ęŒŠǰȱŒ˜–˜ȱ•Šȱ–˜œ›ŠŠȱŽ—ȱ•Šȱꐞ›ŠȱřǰȱŽ—ȱ 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-Œ’à—Dzȱž’•’£àȱž—Šȱ•Ç—ŽŠȱ—Ž›Šȱ™Š›Šȱ–˜œ›Š›ȱŽ•ȱŠŸŠ—ŒŽȱŽȱ ȱŽœŠ››˜••Š˜ȱŠ•ȱꗊ•’£Š›ȱŒŠŠȱ’Ž›ŠŒ’à—ȱ¢ȱž—Šȱ•Ç—ŽŠȱ gris para ilustrar el gasto del presupuesto en cada ite-›ŠŒ’à—ǰȱ Šȱ ŽœŠȱ ›¤ęŒŠȱ •Žȱ Šȱ Ž•ȱ —˜–‹›Žȱ Žȱ ›¤ęŒŠȱ Žȱ ’Ž–™˜ȱ ¢ȱ ™›Žœž™žŽœ˜ǯȱ —ȱ Ž••Šȱ Žœȱ ™˜œ’‹•Žȱ ’Ž—’ęŒŠ›ȱ 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 activida-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 ꐞ›ŠȱŚȱœŽȱ˜‹œŽ›ŸŠȱ•Šȱ˜›–ŠȱŽ—ȱšžŽȱŽœŽȱ–˜Ž•˜ȱ–žŽœ-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-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-à›’ŒŠȱ Žȱ ’—˜›–ŠŒ’à—Dzȱ ŽœŽȱ –˜Ž•˜ȱ ž’•’£Šȱ Ž•ȱ ꕝ›˜ȱ Žȱ Š•–Š—ȱ¢ȱŽ•ȱ–˜Ž•Š˜ȱŽȱŽœ™ŠŒ’˜œȱŽȱŽœŠ˜ȱŒ˜—ȱ•Šȱę-nalidad de hacer proyecciones muy precisas del avance en puntos de función que se espera tenga el producto œŽø—ȱ•ŠȱŸŽ•˜Œ’Šȱ‘’œà›’ŒŠȱŽ•ȱŽšž’™˜ǯȱ•ȱ–˜Ž•˜ȱŽœ-pacio de estado se alimenta con la información de los FP faltantes y las variaciones del alcance en el proyecto. —ȱ•Šȱꐞ›ŠȱśȱœŽȱ–žŽœ›Šȱ•Šȱ›¤ęŒŠȱž’•’£ŠŠȱ™Š›ŠȱŽ•ȱ–˜-—’˜›Ž˜ȱǻŠ—ȱ¢ȱ‘˜’ǰȱŘŖŗŖǼǰȱœŽȱ™žŽŽȱŸŽ›ȱž—Šȱ›¤ęŒŠȱ 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 ȱǻž•Š’–Š—ȱ¢ȱŠ›˜—ǰȱŘŖŖŜDzȱžœ”ǰȱŘŖŖşDzȱŠ œ‘˜›-—ŽǰȱŘŖŖŞǼȱ—˜ȱ˜–Š—ȱŽ—ȱŒžŽ—ŠȱŽ•ȱŒŠ–‹’˜ȱŽ—ȱŽ•ȱŠ•ŒŠ—ŒŽȱŽȱ un proyecto, es decir, la replaneación no se muestra en •Šœȱ›¤ęŒŠœȱŽȱŠ™˜¢˜ȱ™Š›ŠȱŽ•ȱ–˜—’˜›Ž˜ǰȱœ’Ž–™›ŽȱœŽȱŒ˜—- œ’Ž›Šȱø—’ŒŠ–Ž—ŽȱŽ•ȱŸŠ•˜›ȱ˜‹Ž—’˜ȱŽȱ•Šȱ™›’–Ž›Šȱ™•Š-neación como un todo, por lo que la información que se )LJXUD/tQHD6LGHDOSDUDHO(%9HQXQSUR\HFWRVHJ~Q

5DZVWKURQH )LJXUD*UiILFDXWLOL]DGDSRU5XVNSDUDPRQLWRUHDUHOFRQWH[WRILQDQFLHUR\HOGHVHPSHxRHQXQSUR\HFWR

)LJXUD*UiILFDSDUDHOPRQLWRUHRGH+8SRU3XQWRGH&RQWURO XWLOL]DGRHQ/2%0LUDQGD\%RXUTXH

(5)

–žŽœ›Šȱ—˜ȱŽœȱŒ˜—ꊋ•ŽȱŠ•ȱ›ŽŠ•’£Š›ȱŒŠ–‹’˜œȱŽ—ȱŽ•ȱŠ•ŒŠ—ŒŽȱ 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 Žę—Žȱž—ŠȱŸŽ•˜Œ’Šȱ‹ŠœŽȱŠšž’›’ŠȱŽȱŠ˜œȱ‘’œà›’Œ˜œȱ —˜ȱ–ž¢ȱŒ˜—ꊋ•Žœǰȱ˜ȱŽ•ȱ“ž’Œ’˜ȱŽȱŽ¡™Ž›˜œǰȱ™Š›ŠȱŒ˜—˜-

ŒŽ›ȱŽ•ȱ’Ž–™˜ȱŠ™›˜¡’–Š˜ȱŽ—ȱŽ•ȱšžŽȱŽ•ȱ™›˜¢ŽŒ˜ȱŽ›–’-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 Ž•ȱ™›˜¢ŽŒ˜ȱŽœȱœ’–’•Š›ȱŠȱ•ŠȱšžŽȱœŽȱž’•’£ŠȱŒ˜–ø—–Ž—ŽȱŽ—ȱ 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 )LJXUD*UiILFDFRQODLQIRUPDFLyQUHVXOWDQWHGHOILOWUR.DOPDQ

(6)

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

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 iduran-teración. Para conocer esduran-te valor se utiliza la siguiente fórmula,

(7)

)LJXUDBurn downGHSODQLILFDFLyQSDUDHOSUR\HFWR´6LVWHPD GHJHVWLyQGHFRQWHQLGRVµ

Ȋȱȱȱ˜œ˜ȱ‹ŠœŽȱŽȱȱ™˜›ȱ’Ž›ŠŒ’à—ȱ(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-—Žȱ•Šȱ›¤ęŒŠȱ‹ž›—ȱ˜ —ȱde planeación, en la que se gra-ꌊȱ •Šȱ ŒŠ—’Šȱ Žȱ ȱ Š•Š—Žȱ ™˜›ȱ ŽœŠ››˜••˜ȱ ž›Š—Žȱ ŒŠŠȱ ’Ž›ŠŒ’à—ǯȱ Š›Šȱ ˜‹Ž—Ž›ȱ ŽœŠȱ ›¤ęŒŠȱ Žœȱ —ŽŒŽœŠ›’˜ȱ conocer la cantidad de SP que el equipo va a desarrollar durante cada iteración basándose en la información de •Šȱ™•Š—ŽŠŒ’à—ǯȱŠȱž—Œ’à—ȱŠȱ›ŠęŒŠ›ȱŽœȱ•Šȱœ’ž’Ž—ŽDZ

ȱ ǻśǼ

en donde ¡ȱŽœȱ•Šȱ’Ž›ŠŒ’à—ȱšžŽȱœŽȱŸŠȱŠȱ›ŠęŒŠ›ȱ¢ȱȱœ˜—ȱ los SP a desarrollar en la iteración i.

Š›ŠȱŽ“Ž–™•’ęŒŠ›ȱŽœŠȱŠŒ’Ÿ’Šȱ˜–Š–˜œȱŒ˜–˜ȱŽ“Ž–-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-–Š˜ȱ ™˜›ȱ ž—ȱ •ÇŽ›ȱ Žȱ ™›˜¢ŽŒ˜ȱ ¢ȱ śȱ ŽœŠ››˜••Š˜›Žœǯȱ •ȱ Žšž’™˜ȱ •ŽŸŠ—àȱ ›ŽšžŽ›’–’Ž—˜œȱ Œ˜—ȱ ž—ȱ ˜Š•ȱ Žȱ ŚŜȱ œǰȱ cada una con su respectivo esfuerzo, donde se obtuvo un ȱŽȱŚŞŜȱǯȱ•ȱ•ÇŽ›ȱŽ•ȱ™›˜¢ŽŒ˜ȱŒ˜—œ’Ž›àȱž—ŠȱȱŽȱ 70 SP por iteración basándose en las velocidades logradas Ž—ȱ™›˜¢ŽŒ˜œȱŠ—Ž›’˜›ŽœDzȱŒ˜—ȱŽ•ȱȱ¢ȱȱœŽȱ˜‹’Ž—Ž—ȱŝȱ 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. 7DEOD63SODQHDGRVSRULWHUDFLyQSDUDHOSUR\HFWR ´6LVWHPDGHJHVWLyQGHFRQWHQLGRVµ Iteración SPI 1 ŜŜ 2 71 3 71 Ś Ŝś ś Ŝś Ŝ ŜŞ 7 ŞŖ 3DUDFRQVHUYDUODFRQILGHQFLDOLGDGFRQORVFRVWRVGHQWURGHODHP -SUHVDHOFRVWRUHIHUHQFLDGRVHFDPELy 7DEOD0pWULFDVEDVHSDUDHOSUR\HFWR ´6LVWHPDGHJHVWLyQGHFRQWHQLGRVµ

Métrica Valor obtenido

TBTP ŚŞŜȱ 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 ‹ž›—ȱ˜ —ȱŽȱ™•Š—’ęŒŠŒ’à—ȱœŽȱ–žŽœ›ŠȱŽ—ȱ•Šȱꐞ›ŠȱŜǯ Replanificación

Šȱ›¤ęŒŠȱŽȱ‹ž›—ȱ˜ — ȱŽȱ™•Š—’ęŒŠŒ’à—ȱŽŸ˜•žŒ’˜—Š›¤ȱž-rante cada revisión de iteración, en ella se mostrará que: Ȋȱȱȱ•ȱŠŸŠ—ŒŽȱ‹ŠœŽȱ™•Š—ŽŠ˜ȱ(ABǼȱœŽȱ›ŠęŒŠȱŒ˜—ȱ•Šȱ–’œ–Šȱ

ž—Œ’à—ȱž’•’£ŠŠȱŽ—ȱ•Šȱ™•Š—’ęŒŠŒ’à—ǯ

Ȋȱȱȱ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.

Ȋȱȱ•ȱŠŸŠ—ŒŽȱ›Ž™•Š—’ęŒŠ˜ȱǻARR) mostrará los ajustes que el equipo toma durante cada planeación de una —žŽŸŠȱ’Ž›ŠŒ’à—ǯȱž›Š—ŽȱŒŠŠȱ™•Š—’ęŒŠŒ’à—ȱŽȱ’Ž›Š-ción el equipo decide qué HU va a desarrollar, se ‹ŠœŠȱŽ—ȱ•Šȱ’—˜›–ŠŒ’à—ȱŽȱ•Šȱ™•Š—’ęŒŠŒ’à—ǰȱ™Ž›˜ȱŽœŠȱ 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 ›¤ęŒŠȱŽȱŒŠ– -‹’˜œȱ Ž—ȱ Ž•ȱ Š•ŒŠ—ŒŽ, que mostrará el impacto de estos cambios en los SP agregados o eliminados del TBTP.

(8)

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 conoíndi-cer 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:

(7) Ȋȱȱȱ 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:

ǻŞǼ ȊȱȱŠ–‹’˜œȱŽ—ȱŽ•ȱŠ•ŒŠ—ŒŽȱ(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 métri-cambios reali-£Š˜œȱŽ—ȱŽ•ȱ™›˜¢ŽŒ˜ǯȱ—ȱȱœŽȱŒ˜—œ’Ž›ŠȱŽ¡’˜œ˜ȱ ž—ȱ™›˜¢ŽŒ˜ȱšžŽȱŸŠ›’àȱřŖƖȱœžȱ’Ž–™˜ȱ¢ȱŒ˜œ˜ȱǻžœ”ǰȱ ŘŖŖşǼǰȱŽœȱ™˜›ȱŽ••˜ȱšžŽȱœŽȱ›ŽŒ˜–’Ž—ŠȱšžŽȱŽœŠȱ–·›’-ca nunŘŖŖşǼǰȱŽœȱ™˜›ȱŽ••˜ȱšžŽȱœŽȱ›ŽŒ˜–’Ž—ŠȱšžŽȱŽœŠȱ–·›’-ca 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 Œ˜—Š‹’•’£Š—ȱŠ•ȱꗊ•’£Š›ȱŒŠŠȱ’Ž›ŠŒ’à—ȱŽ—ȱ•Šȱ›Žž—’à—ȱŒ˜—ȱ 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 ꐞ›Šȱşǯ

—ȱ•Šȱ’Ž›ŠŒ’à—ȱŜȱœŽȱ’—Ž›àȱŠ•ȱŽšž’™˜ȱŽȱŽœŠ››˜••˜ȱ 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.

1 SPA SPI

(9)

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 des-desarrollador la toma en la fase des-de des- 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-˜œȱ œŽø—ȱ œžȱ ŽœžŽ›£˜ǰȱ Žȱ ˜›–Šȱ œ’–’•Š›ȱ Šȱ •Šȱ šžŽȱ œŽȱ –žŽœ›ŠȱŽ—ȱ•ŠȱŠ‹•Šȱśǯ

—ȱ•ŠȱŠ‹•ŠȱśȱœŽȱŠ™›ŽŒ’Š—ȱ•˜œȱ’Ž–™˜œȱŠœŠ˜œȱŽ—ȱ‘˜-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:

(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 i i S x x n

¦

2 S S

)LJXUDBurn downGHLWHUDFLyQSDUDHOSUR\HFWR´6LVWHPD GHJHVWLyQGHFRQWHQLGRVµ

(10)

)LJXUD763&$SDUDHOSUR\HFWR´6LVWHPDGHJHVWLyQGH FRQWHQLGRVµ )LJXUDÌQGLFHV&3,\63,SDUDHOSUR\HFWR´6LVWHPDGHJHVWLyQ GHFRQWHQLGRVµ Iteración Costo por SP planeado Costo replaneado

siguiente iteración Costo real CPI SPI

0 1 1 1 śŗŚǯŘŞśŝŗŚř śŞŖǯřŗŜŝŚŘŗ ŖǯşŝŗŚŘŞśŝŗ ŖǯşŝŗŚŘŞśŝŗ 2 śŗŚǯŘŞśŝŗŚř ŚŜŝǯśřŘŚŜŝś śŘŗǯŝřşŗřŖŚ ŖǯşŞśŝŗŚŘŞŜ ŖǯşŞśŝŗŚŘŞŜ 3 śŗŚǯŘŞśŝŗŚř ŚŜŗǯśřŞŚŜŗś ŚśśǯŜşŜŘŖŘś ŗǯŗŘŞśŝŗŚŘş ŗǯŗŘŞśŝŗŚŘş Ś śŗŚǯŘŞśŝŗŚř ŚŞŜǯŚŞŜŚŞŜś ŚŞŜǯŚŞŜŚŞŜś ŗǯŖśŝŗŚŘŞśŝ ŗǯŖśŝŗŚŘŞśŝ ś śŗŚǯŘŞśŝŗŚř ŚŖŚǯŚşŚřŞŘ śşŖǯŗŜřşřŚŚ ŖǯŞŝŗŚŘŞśŝŗ ŖǯŞŝŗŚŘŞśŝŗ Ŝ śŗŚǯŘŞśŝŗŚř ŚŚŞǯŚŘŜśŝřŚ ŚŞŝǯŗŝşŚŞŝŘ ŗǯŖśśŜřşŖşŞ ŗǯŗśŝŗŚŘŞśŝ 7 śŗŚǯŘŞśŝŗŚř ŚŚŞǯŚŘŜśŝřŚ ŗǯŗŚŜŞŜŝŗŜŞ ŗǯŘśŝŗŚŘŞśŝ 7DEOD&3,\63,GHOSUR\HFWR´6LVWHPDGHJHVWLyQGHFRQWHQLGRVµ 7DEOD&RVWRUHDOSRULWHUDFLyQ HQHOSUR\HFWR

Iteración Costo Real

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

La distribución normal se calcula con la siguiente fór-mula: (12) 1 2 ( ) 2 1 ( , , ) 2 N f x e § P · ¨¨ ¸¸ V © ¹ P V SV

donde ¡ȱes un tiempo del conjunto de las HU con mismo esfuerzo, μ es la media o ¡ȱy V es la desviación estándar o S. —ȱ•ŠȱŠ‹•ŠȱŞȱœŽȱŒŠ•Œž•Šȱ•Šȱ’œ›’‹žŒ’à—ȱ—˜›–Š•ȱ™Š›Šȱ•Šȱ ¡ȱ ¢ȱ •Šȱ ȱ ˜‹Ž—’Šœȱ Œ˜—ȱ •Šȱ ’—˜›–ŠŒ’à—ȱ Žȱ •Šȱ Š‹•Šȱ Ŝǯȱ Šȱ Œ˜•ž–—Šȱ Žȱ ›ž™˜œȱ –žŽœ›Šȱ Ž•ȱ ›Š—˜ȱ ’Ž—’ęŒŠ˜ȱ Žȱ ’Ž–™˜œȱ™Š›Šȱ•ŠœȱȱŽȱŞȱœȱŽȱ•ŠȱŠ‹•ŠȱŜǯ —ȱ •Šȱ ꐞ›Šȱ ŗŖȱ œŽȱ –žŽœ›Šȱ •Šȱ ŒŠ–™Š—Šȱ Žȱ Šžœœȱ ˜ȱ 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-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 •Šœȱ’œŒžœ’˜—Žœȱœ˜‹›Žȱ•Šœȱ’ęŒž•ŠŽœȱ¢ȱ™›˜‹•Ž–Šœȱ™›Ž-sentados en el estudio.

(11)

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ȱŽŠŸŽ—Ž¢ȱ¢ȱ˜—‹˜¢ǰȱ ŘŖŖŜDzȱž•Š’–Š—ȱ¢ȱŠ›˜—ǰȱŘŖŖŜDzȱžœ”ǰȱŘŖŖşǼǯ

2. Otros autores indican que hay poca evidencia acerca de la medición de los costos de un proyecto para los ad-–’—’œ›Š˜›ŽœȱŽȱ™›˜¢ŽŒ˜œȱǻ˜—ŽœǰȱŘŖŖŚDzȱž•Š’–Š—ȱ¢ȱ Š›˜—ǰȱŘŖŖŜDzȱȱžœ”ǰȱŘŖŖşǼǯ

3. La estimación de costos en métodos ágiles se basa co-–ø—–Ž—Žȱ Ž—ȱ “ž’Œ’˜œȱ Žȱ Ž¡™Ž›˜œȱ ¢ȱ —˜ȱ Ž—ȱprocesos ›Ž™Ž’‹•Žœȱ ¢ȱ –Ž“˜›Š‹•ŽœȱǻŽŠŸŽ—Ž¢ȱ ¢ȱ ˜—‹˜¢ǰȱ ŘŖŖŜDzȱ ‘Š–ȱǯȱ¢ȱ‘Š–ȱǯǰȱŘŖŗŗǼǯȱ’—ȱž—ȱ™›˜ŒŽœ˜ȱ‹’Ž—ȱŽę-nido y medible, no es posible lograr una optimiza-ción ni la reducoptimiza-ció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 ’ę -Œž•ŠŽœȱ˜ȱ™›˜‹•Ž–Šœ 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í-ꌊ–Ž—Žȱ Ž—ȱ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, Softsoft-ware 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 ŝśȱ ȱ ™•Š—’ęŒŠŠœǰȱ ŘŘȱ ȱ ™˜›ȱ ’Ž›ŠŒ’à—ǰȱ ž—ȱ Œ˜œ˜ȱ ‹ŠœŽȱŽȱǞŗŘŞǯŜŞȱ™Žœ˜œȱ–Ž¡’ŒŠ—˜œȱ™˜›ȱŒŠŠȱȱǻŽ•ȱŒ˜œ-to no contiene impues‹ŠœŽȱŽȱǞŗŘŞǯŜŞȱ™Žœ˜œȱ–Ž¡’ŒŠ—˜œȱ™˜›ȱŒŠŠȱȱǻŽ•ȱŒ˜œ-tos 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- ›Žœǰȱ˜—ŽȱœŽȱŽę—’Ž›˜—ȱ’Ž›ŠŒ’˜—ŽœȱŽȱž›ŠŒ’à—ȱœŽ-–Š—Š•ǰȱŒ˜—ȱŚȱ’Ž›ŠŒ’˜—Žœȱ™•Š—’ęŒŠŠœǯȱŽȱ›Ž’œ›àȱŽ—ȱ Ž•ȱ Žšž’™˜ȱ ž—ȱ ˜Š•ȱ Žȱ Şȱ ŽœŠ››˜••Š˜›Žœȱ ž›Š—Žȱ Ž•ȱ ™›˜ŒŽœ˜ǰȱŚŝȱ‘’œ˜›’ŠœȱŽȱžœžŠ›’˜ȱ™•Š—ŽŠŠœǰȱž—ŠȱŽœ’-–ŠŒ’à—ȱ Žȱ ŘŜřȱ ™ž—˜œȱ Žȱ ‘’œ˜›’Šǰȱ ž—Šȱ ŸŽ•˜Œ’Šȱ ‹ŠœŽȱ Žȱ Ŝşȱ ȱ ™˜›ȱ ’Ž›ŠŒ’à—ȱ ¢ȱ ž—ȱ Œ˜œ˜ȱ ‹ŠœŽȱ Žȱ ǞŗŘŞǯŜŞȱ™Žœ˜œȱ–Ž¡’ŒŠ—˜œȱ™˜›ȱŒŠŠȱǯȱ—ȱŽœŽȱ™›˜-yecto no se utilizó la propuesta de estimación y con-›˜•ȱ Žȱ Œ˜œ˜œȱ Ž•ȱ ™›ŽœŽ—Žȱ Š›ÇŒž•˜ǯȱ ˜›ȱ ø•’–˜ǰȱ Ž•ȱ 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 ŝǯś ŘśǯŘ 7DEOD7LHPSRVDJUXSDGRVSRUHVIXHU]RSDUDXQSUR\HFWR

(12)

™Ž›’˜˜ȱŽȱŽœŠ››˜••˜ȱžŽȱŽ•ȱŘśȱŽȱœŽ™’Ž–‹›ŽȱŠ•ȱŞȱ de noviembre. Análisis e interpretación ȱ Œ˜—’—žŠŒ’à—ȱ œŽȱ ™›ŽœŽ—Š—ȱ •˜œȱ ›Žœž•Š˜œȱ ꗊ•Žœȱ Žȱ •˜œȱ™›˜¢ŽŒ˜œȱŽ—ȱ•Šœȱ›¤ęŒŠœȱŒ˜››Žœ™˜—’Ž—Žœǯȱ •ȱ™›˜¢ŽŒ˜ȱŗȱ—˜ȱŽ—Ž›àȱ•˜œȱœžęŒ’Ž—ŽœȱŠ˜œȱ™Š›Šȱ Ž—Ž›Š›ȱ •Šœȱ ›¤ęŒŠœȱ Žȱ Žœ’–ŠŒ’˜—Žœȱ Žȱ ŽœžŽ›£˜œǰȱ ¢Šȱ šžŽȱ—˜ȱœŽȱŒ˜—Š‹ŠȱŒ˜—ȱŠ˜œȱ‘’œà›’Œ˜œȱœžęŒ’Ž—Žœǯȱ’—ȱ Ž–‹Š›˜ǰȱ •Šȱ Žœ’–ŠŒ’à—ȱ Žȱ •˜œȱ Ž¡™Ž›˜œȱ žŽȱ œžęŒ’Ž—Žǰȱ ya que este era un diseño de desarrollo conocido por el Œ•’Ž—Žǯȱ Šœȱ ›¤ęŒŠœȱ Ž—Ž›ŠŠœȱ Ž•ȱ –·˜˜ȱ ™›˜™žŽœ˜ȱ œ˜—ȱ•Šȱ›¤ęŒŠȱ‹ž›—ȱ˜ — al cierre del proyecto, como se ™žŽŽȱŠ™›ŽŒ’Š›ȱŽ—ȱ•Šȱꐞ›Šȱŗŗǰȱ¢ȱ•Šȱ›¤ęŒŠȱȦȱŠ–-‹’·—ȱŠ•ȱŒ’Ž››ŽȱŽ•ȱ™›˜¢ŽŒ˜ȱŽ—ȱ•Šȱꐞ›ŠȱŗŘǯ

ŠœȱœŽ›’ŽœȱŽȱŠ˜œȱŽȱ•Šȱ›¤ęŒŠȱ‹ž›—ȱ˜ — se descri-ben como el avance planeado, que muestra el esfuerzo restante para su desarrollo, obtenido durante la etapa

Žȱ ™•Š—ŽŠŒ’à—Dzȱ Ž•ȱ ŠŸŠ—ŒŽȱ 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 ¢ȱ Ž•ȱ ŠŸŠ—ŒŽȱ ›ŽȬ™•Š—’ęŒŠ˜ǰȱ que muestra el avance repla-—’ęŒŠ˜ȱ™Š›ŠȱŒŠŠȱ’Ž›ŠŒ’à—ǯȱ Como se puede apreciar en los resultados, el avance real fue más rápido de lo planea-do debiplanea-do 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 žŽȱ —ŽŒŽœŠ›’Šȱ ž—Šȱ ›Ž™•Š—’ę-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-™ŽŒ˜ȱŠȱ•Šœȱ›Ž™•Š—’ęŒŠŒ’˜—Žœǰȱ como resultados esperados de esfuerzo.

Žœ™ŽŒ˜ȱŠȱ•Šȱ›¤ęŒŠȱŽȱȦ SPI en el cierre del proyecto ǻꐞ›Šȱ ŗŘǼǰȱ —˜ȱ –žŽœ›Šȱ ›Ž-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 ø•’–˜ǰȱ —˜ȱ œŽȱ Ž—Ž›àȱ ž—Šȱ ›¤ęŒŠȱȱŽ‹’˜ȱŠȱšžŽȱ 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,

Šø—ȱ—˜ȱœŽȱŽ—ÇŠ—ȱ•˜œȱœžęŒ’Ž—ŽœȱŠ˜œȱ‘’œà›’Œ˜œȱ™Š›ŠȱŽ-—Ž›Š›ȱ•ŠœȱŽœ’–ŠŒ’˜—Žœȱœ˜‹›Žȱ•˜œȱŽœžŽ›£˜œǯȱŠȱ›¤ęŒŠȱŽȱ la que se parte para la toma de decisiones es la ‹ž›—ȱ downȱŽ—ȱ•ŠȱšžŽȱœŽȱ–žŽœ›Š—ȱ•Šœȱ’ęŒž•ŠŽœȱŽȱŒ˜—›˜•ǰȱ ™›’—Œ’™Š•–Ž—ŽȱŽȱ•ŠȱœŽž—Šȱ’Ž›ŠŒ’à—ȱŠȱ•Šȱšž’—ŠDzȱ™Š›Šȱ Conjunto de tiempos ™Š›ŠȱŽœžŽ›£˜ȱŞ 1.00 1.00 ȱȱȱȱȱȱȱȱȱȱȱȱȱȱŖǯśŖ 1.00 ȱȱȱȱȱȱȱȱȱȱȱȱȱȱŗǯś 1 ȱȱȱȱȱȱȱȱȱȱȱȱȱȱŗǯŘś 1 ȱȱȱȱȱȱȱȱȱȱȱȱȱȱŖǯŝś ȱȱȱȱȱȱȱȱȱȱȱȱȱȱŖǯś ȱȱȱȱȱȱȱȱȱȱȱȱȱȱŖǯś ȱȱȱȱȱȱȱȱȱȱȱȱȱȱŗǯŘś ȱȱȱȱȱȱȱȱȱȱȱȱȱȱŗǯś 1 ȱȱȱȱȱȱȱȱȱȱȱȱȱȱŖǯś ȱȱȱȱȱȱȱȱȱȱȱȱȱȱŖǯŝś ȱȱȱȱȱȱȱȱȱȱȱȱȱȱŗǯŝś ȱȱȱȱȱȱȱȱȱȱȱȱȱȱŗǯŘś 2 ȱȱȱȱȱȱȱȱȱȱȱȱȱȱŖǯś 1 7DEOD7LHPSRV KLVWyULFRVGHOSUR\HFWR SDUD+8VFRQHVIXHU]R GH63XWLOL]DQGRODVHULH SURSXHVWDGHWLHPSRV 7DEOD9DORUHVGH[ 6\6SDUDHOFRQMXQWR GHWLHPSRVGH+8VFRQ HVIXHU]RGH63GHOD WDEOD X 1.03 S2 ŖǯŗşŖŗřŗśŝş S ŖǯŚřŜŖŚŖŞ )LJXUD'LVWULEXFLyQQRUPDOSDUDORVWLHPSRVGH+8VFRQ HVIXHU]RGH63

(13)

ŽŽŒ˜œȱ Žȱ Ž—Œ˜—›Š›ȱ •Šœȱ ’ęŒž•ŠŽœȱ ¢ȱ ™›˜‹•Ž–Šœȱ Ž•ȱ 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.

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 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. ˜–˜ȱ ›Žœž•Š˜ȱ œŽȱ Š›ŽŠ›˜—ȱ ŗřśȱ ȱ Œ˜–˜ȱ ŽœŒž‹›’-–’Ž—˜ȱŽȱ—žŽŸŠœȱŽŸ’Ž—Œ’ŠœǰȱšžŽȱ›Ž™›ŽœŽ—Š›˜—ȱśŗǯřƖȱ 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 Š›ŽŠ›ȱ Šȱ ˜œȱ ŽœŠ››˜••Š˜›Žœȱ žŽȱ ŜŞƖȱ –¤œȱ ŒŠ›˜ȱ ™Š›Šȱ ŽœŠȱ ’Ž›ŠŒ’à—ǯȱ —ȱ ŽœŽȱ ™›˜¢ŽŒ˜ȱ ›Š‹Š“àȱ Ž•ȱ Žšž’™˜ȱ ŘDzȱ Š•ȱ ·›–’—˜ȱŽȱ•Šȱ’Ž›ŠŒ’à—ȱ•ŠȱŸŽ•˜Œ’ŠȱŽȱŽœŠ››˜••˜ȱžŽȱŜşȱ SP, acorde a lo esperado en el plan, dicho de otra forma, 7DEOD'LVWULEXFLyQQRUPDOSDUDODx \6SDUDHOJUXSRGH

WLHPSRVGH+8VFRQ63LGHQWLILFDGRVHQODWDEOD Grupos Distribución Normal

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

)LJXUDBurn downDOFLHUUHGHOSUR\HFWR3

(14)

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

Žšž’™˜ȱřǯȱ•ȱŒ’Ž››ŽǰȱŽ•ȱŸŠ•˜›ȱŠ—Š˜ȱžŽȱŘŞŞȱǰȱšžŽŠ—-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-)LJXUD763&$SDUDHOFLHUUHGHOSUR\HFWR3

Referencias

Documento similar

trañables para él: el campo, la vida del labriego, otra vez el tiempo, insinuando ahora una novedad: la distinción del tiempo pleno, el tiempo-vida, y el tiempo

La siguiente y última ampliación en la Sala de Millones fue a finales de los años sesenta cuando Carlos III habilitó la sexta plaza para las ciudades con voto en Cortes de

Ciaurriz quien, durante su primer arlo de estancia en Loyola 40 , catalogó sus fondos siguiendo la división previa a la que nos hemos referido; y si esta labor fue de

Después de una descripción muy rápida de la optimización así como los problemas en los sistemas de fabricación, se presenta la integración de dos herramientas existentes

por unidad de tiempo (throughput) en estado estacionario de las transiciones.. de una red de Petri

Por lo tanto, en base a su perfil de eficacia y seguridad, ofatumumab debe considerarse una alternativa de tratamiento para pacientes con EMRR o EMSP con enfermedad activa

The part I assessment is coordinated involving all MSCs and led by the RMS who prepares a draft assessment report, sends the request for information (RFI) with considerations,

o Si dispone en su establecimiento de alguna silla de ruedas Jazz S50 o 708D cuyo nº de serie figura en el anexo 1 de esta nota informativa, consulte la nota de aviso de la