TFG MaríaPérezIniesta

UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INFORMÁTICA
GRADO EN INGENIERÍA INFORMÁTICA
TRABAJO FIN DE GRADO
Mesta: Herramienta multimodelo para la

estimación de proyectos software
María Pérez Iniesta
Julio, 2018
M ESTA : H ERRAMIENTA MULTIMODELO PARA LA ESTIMACIÓN DE
PROYECTOS SOFTWARE
UNIVERSIDAD DE CASTILLA-LA MANCHA
ESCUELA SUPERIOR DE INFORMÁTICA
Departamento de Tecnologías y Sistemas de la información
TECNOLOGÍA ESPECÍFICA DE
INGENIERÍA DEL SOFTWARE
TRABAJO FIN DE GRADO
Mesta: Herramienta multimodelo para la

estimación de proyectos software
Autor: María Pérez Iniesta

Director: Moisés Rodríguez Monje
Director: Mario Gerardo Piattini Velthuis
Julio, 2018
Ciudad Real – Spain
E-mail: Maria.Perez46@alu.uclm.es
Teléfono: (+34) 617066956

c 2018 María Pérez Iniesta
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU
Free Documentation License, Version 1.3 or any later version published by the Free Software
Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy
of the license is included in the section entitled "GNU Free Documentation License".
Se permite la copia, distribución y/o modificación de este documento bajo los términos de la
Licencia de Documentación Libre GNU, versión 1.3 o cualquier versión posterior publicada por
la Free Software Foundation; sin secciones invariantes. Una copia de esta licencia esta incluida en
el apéndice titulado «GNU Free Documentation License».
Muchos de los nombres usados por las compañías para diferenciar sus productos y servicios son
reclamados como marcas registradas. Allí donde estos nombres aparezcan en este documento, y
cuando el autor haya sido informado de esas marcas registradas, los nombres estarán escritos en
mayúsculas o como nombres propios.
i
TRIBUNAL:
Presidente:
Vocal:
Secretario:
FECHA DE DEFENSA:
CALIFICACIÓN:
PRESIDENTE VOCAL SECRETARIO
Fdo.: Fdo.: Fdo.:
iii
Resumen
La medición y estimación del software son un campo joven, incluso más que la Ingeniería
del Software, esto ha influido en que no hayan podido alcanzar todavía la madurez que tienen
otras áreas o ingenierías.
La necesidad por medir está asociada principalmente a la mejora, y una de las principales
razones de que haya aumentado el interés en las métricas ha sido la comprensión de que
pueden ayudarnos en la mejora de la calidad de nuestros procesos y productos software. Por
otro lado, la importancia de la estimación software está justificada puesto que, de una buena
estimación del esfuerzo y costes de un proyecto, dependerá posteriormente que se pueda rea-
lizar un adecuado control durante su desarrollo y se puedan cumplir los plazos y expectativas
del cliente.
Por ello, con el objetivo de dar una solución a esta necesidad, en este Trabajo de Fin de
Grado se va a desarrollar una aplicación de estimación multimodelo, en la cual el usuario
podrá estimar proyectos software desde el punto de vista tradicional con una gestión predic-
tiva y desde el punto de vista ágil, con una gestión adaptativa.
V
Abstract
The measurement and estimation of the software is a young field, even more than the Soft-
ware Engineering, this has influenced that they have not yet reached the maturity that other
areas or engineering have.
The need to measure is associated mainly with improvement, and one of the main reasons
that the interest in metrics has increased has been the understanding that they can help us in
improving the quality of our processes and software products. On the other hand, the impor-
tance of software estimation is justified since a good estimation of the effort and costs of a
project will depend later on that an adequate control can be carried out during its develop-
ment and the customer’s deadlines and expectations can be met.
Therefore, in order to provide a solution to this need, in this Final Degree Project, a mul-
timode estimation application will be developed, in which the user will be able to estimate
software projects from the traditional point of view with predictive management. and from
the agile point of view, with an adaptive management.
VII
Agradecimientos
En primer lugar, me gustaría agradecer a mis padres Manuel y Pilar por creer en mí en to-
do momento y haberme brindado la oportunidad de cumplir un sueño y conseguir una meta
con la que sé que se sienten muy orgullosos. Por darme la fuerza necesaria cuando las cosas
se ponían complicadas, pero sobre todo por explicarme con su ejemplo el significado de las
palabras trabajo y humildad.
A Ana Pilar, por confiar y darme todo su apoyo en cada paso que he dado en mi vida,
pero sobre todo por ser mi ejemplo a seguir desde que éramos pequeñas y hacer que con su
esfuerzo y trabajo pueda seguir contestando a la pregunta "¿Quién es tu ejemplo a seguir?
Es mi hermana".
A Pedro, porque ha sido una persona fundamental en esta etapa de mi vida, por estár cada
día apoyándome y dándome la fuerza que en muchos momentos me faltaba. Pero sobre todo
por creer en mí y hacer que todo fuera más fácil demostrándome día a día porque estoy tan
orgullosa de él.
Al resto de mi familia, en especial a mis abuelos, por su apoyo y ánimo en esta aventura.
A Moisés y Mario, por confiar en mí para realizar este Trabajo de Fin de Grado (TFG),
por darme la oportunidad de aprender de ellos cada día, por sus consejos académicos y todo
el tiempo que me han dedicado. Pero sobre todo por ser un gran ejemplo de esfuerzo y de-
dicación al trabajo. Me siento muy afortunada por haber podido compartir con vosotros esta
experiencia de mi vida.
A Mari Cruz, porque ha sido un gran apoyo desde el primer día de esta aventura hasta el
último, por animarme y creer en mí mucho más de lo que yo lo hacía.
A mis amigas y amigos de Campo de Criptana, a todos y cada uno de vosotros, por per-
mitirme formar parte de vuestras vidas y por hacerme sentir orgullosa de ser vuestra amiga.
A todos y cada uno de los amigos que me ha brindado, la que probablemente sea la mejor
etapa de mi vida, desde el primero al último, Alba, Alberto, Álvaro, Edu, Jaime, Jorge, José
María, Julio, Oliva, Pablo y Pedro, por esas Friki Night’s, por las experiencias y momentos
vividos a vuestro lado, no me imagino esta etapa de mi vida sin vosotros.
Gracias a todos, de corazón.

IX
Todos tenemos sueños, pero para que estos sueños se vuelvan realidad se necesita una gran
determinación, dedicación, autodisciplina y esfuerzo.
-Jesse Owens-
xi
Índice general
Resumen V
Abstract VII
Agradecimientos IX
Índice general XIII
Índice de cuadros XVII
Índice de figuras XXI
Listado de acrónimos XXV
1. Introducción 1
1.1. Contexto del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Estructura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Objetivos 5
2.1. Objetivo principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Objetivos parciales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Justificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Estado de la cuestión 7
3.1. Estimación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. Evolución de las estimaciones . . . . . . . . . . . . . . . . . . . . 7
3.2. Modelos de estimación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Puntos función . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.2. COCOMO II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.3. Puntos Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.4. Backfiring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
XIII
3.2.5. Historias de Usuario . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3. Herramientas de estimación existentes en el mercado . . . . . . . . . . . . 32
4. Método de trabajo 35
4.1. Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.1. Roles en Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1.2. Componentes de Scrum . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.3. Reuniones en Scrum . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.4. Aplicación de Scrum a este TFG . . . . . . . . . . . . . . . . . . . 38
4.1.5. Sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2. Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3. Proceso Unificado de Desarrollo . . . . . . . . . . . . . . . . . . . . . . . 40
4.4. Marco tecnológico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4.1. Medios software . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4.2. Medios hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5. Resultados 43
5.1. Definición del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2. Sprint 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2.1. Pila del Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2.2. Desarrollo del Sprint . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2.3. Reunión semanal . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2.4. Revisión del Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.2.5. Retrospectiva del Sprint . . . . . . . . . . . . . . . . . . . . . . . 47
5.3. Sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3.1. Refinamiento de la Pila del Producto . . . . . . . . . . . . . . . . . 48
5.3.2. Planificación del Sprint . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3.3. Desarrollo del sprint . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.3.4. Reunión Semanal . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.4. Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.4.2. Planificación del sprint . . . . . . . . . . . . . . . . . . . . . . . . 60
5.4.4. Reunión semanal . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
xiv
5.5. Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.5.4. Reunión Semanal . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.6. Sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.6.4. Reunión semanal . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.6.5. Revisión del sprint . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.7. Sprint 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.7.4. Reunión semanal . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.8. Sprint 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.8.4. Reunión semanal . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
6. Conclusiones 113
6.1. Análisis de los objetivos del proyecto . . . . . . . . . . . . . . . . . . . . 113
6.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
6.3. Opinión personal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
xv
Referencias 117
A. Historias de Usuario 123
B. Manual de Usuario 133

B.1. Registro de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
B.2. Acceso a la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
B.3. Página Principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
B.4. Crear estimación Puntos función . . . . . . . . . . . . . . . . . . . . . . . 135
B.5. Crear estimación COCOMO II . . . . . . . . . . . . . . . . . . . . . . . . 138
B.6. Crear estimación Puntos Casos de Uso . . . . . . . . . . . . . . . . . . . . 141
B.7. Crear estimación Backfiring . . . . . . . . . . . . . . . . . . . . . . . . . 143
B.8. Crear estimación Historias de Usuario . . . . . . . . . . . . . . . . . . . . 145
B.9. Filtrar estimaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
B.10. Modificar estimación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
B.11. Eliminar estimación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
B.12. Exportar estimación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
B.13. Comparar estimaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
B.14. Imputar estimación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
B.15. Perfil de Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
C. Contrato de Confidencialidad y Propiedad Intelectual 153
xvi
Índice de cuadros
3.1. Cronología puntos función [12] . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2. Complejidad de las entradas . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Complejidad de las Salidas y Consultas . . . . . . . . . . . . . . . . . . . 11
3.4. Complejidad de los Archivos y las Interfaces . . . . . . . . . . . . . . . . . 11
3.5. Peso de los diferentes elementos . . . . . . . . . . . . . . . . . . . . . . . 12
3.6. Parámetros para la estimación del esfuerzo [38] . . . . . . . . . . . . . . . 14
3.7. Distribución por fases del ciclo de vida para los proyectos de desarrollo [38] 16
3.8. Distribución por fases del ciclo de vida para proyectos de mantenimiento [38] 16
3.9. Equivalencia puntos función en líneas de código [36] . . . . . . . . . . . . 19
3.10. Tabla con los pesos en función de la complejidad de la interacción con los
actores [19]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.11. Tabla con los pesos en función de la complejidad de los casos de uso [20]. . 25
3.12. Peso de los factores de complejidad técnica [20]. . . . . . . . . . . . . . . 26
3.13. Peso de los factores de complejidad del entorno [20]. . . . . . . . . . . . . 27
3.14. Cantidad horas-persona según el valor [19]. . . . . . . . . . . . . . . . . . 28
4.1. Listado de las historias de usuario realizadas en cada sprint. . . . . . . . . . 39
5.1. Sprint 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2. Resumen historias de Usuario . . . . . . . . . . . . . . . . . . . . . . . . 46
5.3. Plan de Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.4. Prueba 1 de la Historia de Usuario 2 . . . . . . . . . . . . . . . . . . . . . 56
5.10. Prueba 3 Historia de Usuario 4 . . . . . . . . . . . . . . . . . . . . . . . . 58
XVII
5.14. Prueba 1 de la Historia de Usuario 10 . . . . . . . . . . . . . . . . . . . . 65
5.18. Prueba 3 de la historia de usuario 11 . . . . . . . . . . . . . . . . . . . . . 67
5.19. Prueba 1 de Historia de Usuario 12 . . . . . . . . . . . . . . . . . . . . . . 67
5.24. Prueba 3 de la historia de Usuario 14 . . . . . . . . . . . . . . . . . . . . . 79
5.25. Prueba 1 Historia de Usuario 15 . . . . . . . . . . . . . . . . . . . . . . . 79
xviii
6.1. Objetivo principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

6.2. Análisis de los objetivos parciales . . . . . . . . . . . . . . . . . . . . . . 114
xix
Índice de figuras
3.1. Formato de una Historia de Usuario . . . . . . . . . . . . . . . . . . . . . 31

3.2. Comparativa de herramientas similares . . . . . . . . . . . . . . . . . . . . 33
5.1. Caso de uso Insertar estimación Puntos Función . . . . . . . . . . . . . . . 49

5.2. Diagrama de clases Puntos Función . . . . . . . . . . . . . . . . . . . . . 49
5.3. Diagrama entidad relación Puntos Función . . . . . . . . . . . . . . . . . . 50
5.4. Introducir datos generales Puntos función . . . . . . . . . . . . . . . . . . 51
5.5. Funcionalidades Puntos Función . . . . . . . . . . . . . . . . . . . . . . . 51
5.6. Archivos lógicos internos (ILF) . . . . . . . . . . . . . . . . . . . . . . . . 52
5.7. Archivos lógicos externos (ELF) . . . . . . . . . . . . . . . . . . . . . . . 52
5.8. Entradas externas (EI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.9. Salidas externas (EO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.10. Consultas externas (EQ) . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.11. Pestaña Factores de Influencia . . . . . . . . . . . . . . . . . . . . . . . . 54
5.12. Resultados Puntos función . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.13. Resultados distribuciones Puntos función . . . . . . . . . . . . . . . . . . 55
5.14. Caso de uso Insertar estimación COCOMO II . . . . . . . . . . . . . . . . 61
5.15. Diagrama de Clases COCOMO II . . . . . . . . . . . . . . . . . . . . . . 61
5.16. Diagrama entidad relación COCOMO II . . . . . . . . . . . . . . . . . . . 62
5.17. Introducir datos generales COCOMO II . . . . . . . . . . . . . . . . . . . 63
5.18. Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.19. Factores de escala . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.20. Introducir módulos COCOMO . . . . . . . . . . . . . . . . . . . . . . . . 64
5.21. Resultados COCOMO II . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.22. Caso de uso Insertar estimación Puntos Casos de Uso . . . . . . . . . . . . 69
5.23. Caso de uso insertar estimación Backfiring . . . . . . . . . . . . . . . . . . 69
5.24. Diagrama de clases Puntos Casos de Uso . . . . . . . . . . . . . . . . . . . 70
5.25. Diagrama de clases Backfiring . . . . . . . . . . . . . . . . . . . . . . . . 71
XXI
5.26. Diagrama entidad relación Puntos Casos de Uso . . . . . . . . . . . . . . . 71
5.27. Diagrama entidad relación Backfiring . . . . . . . . . . . . . . . . . . . . 72
5.28. Introducir datos generales Puntos Casos de Uso . . . . . . . . . . . . . . . 73
5.29. Cálculo de los actores y los casos de uso . . . . . . . . . . . . . . . . . . . 73
5.30. Factores técnicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.31. Factores de entorno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.32. Resultados Puntos Casos de uso . . . . . . . . . . . . . . . . . . . . . . . 75
5.33. Introducir datos generales Backfiring . . . . . . . . . . . . . . . . . . . . . 75
5.34. Transformar líneas de código en puntos función . . . . . . . . . . . . . . . 76
5.35. Resultados Backfiring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.36. Resultados Distribuciones Backfiring . . . . . . . . . . . . . . . . . . . . . 77
5.37. Caso de uso insertar estimación Historias de Usuario . . . . . . . . . . . . 83
5.38. Diagrama de clases Historias de Usuario . . . . . . . . . . . . . . . . . . . 83
5.39. Diagrama entidad relación Historias de Usuario . . . . . . . . . . . . . . . 84
5.40. Introducir datos generales Historias de Usuario . . . . . . . . . . . . . . . 85
5.41. Introducir datos de las Historias de Usuario . . . . . . . . . . . . . . . . . 85
5.42. Estimación con la técnica Planning Poker . . . . . . . . . . . . . . . . . . 86
5.43. Resultados Historias de Usuario . . . . . . . . . . . . . . . . . . . . . . . 86
5.44. Diagrama de casos de uso Gestionar Aplicación . . . . . . . . . . . . . . . 92
5.45. Diagrama de casos de uso Gestionar Estimación . . . . . . . . . . . . . . . 92
5.46. Diagrama de casos de uso Gestionar Aplicación . . . . . . . . . . . . . . . 93
5.47. Diagrama entidad relación gestión de usuarios . . . . . . . . . . . . . . . . 94
5.48. Filtrar Estimaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.49. Datos generales de la estimación . . . . . . . . . . . . . . . . . . . . . . . 95
5.50. Funcionalidades de la estimación . . . . . . . . . . . . . . . . . . . . . . . 96
5.51. Factores de influencia modificados . . . . . . . . . . . . . . . . . . . . . . 96
5.52. Resultados modificados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.53. Resultados modificados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.54. Estimaciones que se pueden eliminar . . . . . . . . . . . . . . . . . . . . . 97
5.55. Confirmación de eliminación . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.56. Estimaciones resultantes después de la eliminación . . . . . . . . . . . . . 98
5.57. Imputar Estimación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.58. Registro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.59. Acceso a la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.60. Cerrar sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
xxii
5.61. Modificar perfil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.62. Datos generales exportados . . . . . . . . . . . . . . . . . . . . . . . . . . 108
5.63. Funcionalidades exportadas . . . . . . . . . . . . . . . . . . . . . . . . . . 108
5.64. ILF exportados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.65. Resultados exportados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.66. Comparar Estimaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
B.1. Pantalla de registro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

B.2. Pantalla de acceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
B.3. Pantalla de inicio de la aplicación . . . . . . . . . . . . . . . . . . . . . . 134
B.4. Pestaña Datos generales Puntos función . . . . . . . . . . . . . . . . . . . 135
B.5. Pestaña funcionalidades Puntos función . . . . . . . . . . . . . . . . . . . 135
B.6. Ventana para añadir archivos . . . . . . . . . . . . . . . . . . . . . . . . . 136
B.7. Ventana para añadir entradas . . . . . . . . . . . . . . . . . . . . . . . . . 136
B.8. Ventana Factores influencia . . . . . . . . . . . . . . . . . . . . . . . . . . 137
B.9. Pestaña resultados Puntos función . . . . . . . . . . . . . . . . . . . . . . 137
B.10. Pestaña resultados distribuciones Puntos función . . . . . . . . . . . . . . 138
B.11. Pestaña Datos generales COCOMO II . . . . . . . . . . . . . . . . . . . . 138
B.12. Ventana Factores de escala COCOMO II . . . . . . . . . . . . . . . . . . . 139
B.13. Ventana Planificación COCOMO II . . . . . . . . . . . . . . . . . . . . . 139
B.14. Pestaña Módulos COCOMO II . . . . . . . . . . . . . . . . . . . . . . . . 140
B.15. Pestaña Resultados COCOMO II . . . . . . . . . . . . . . . . . . . . . . . 140
B.16. Pestaña Datos generales Puntos Casos de Uso . . . . . . . . . . . . . . . . 141
B.17. Pestaña Calculos Puntos Casos de Uso . . . . . . . . . . . . . . . . . . . . 141
B.18. Ventana factores técnicos Puntos Casos de Uso . . . . . . . . . . . . . . . 142
B.19. Ventana factores entorno Puntos Casos de Uso . . . . . . . . . . . . . . . . 142
B.20. Pestaña Resultados Puntos Casos de Uso . . . . . . . . . . . . . . . . . . . 143
B.21. Pestaña Datos generales Backfiring . . . . . . . . . . . . . . . . . . . . . . 143
B.22. Pestaña Transformar líneas de código Backfiring . . . . . . . . . . . . . . 144
B.23. Pestaña Resultados Backfiring . . . . . . . . . . . . . . . . . . . . . . . . 144
B.24. Pestaña Resultados distribuciones Backfiring . . . . . . . . . . . . . . . . 145
B.25. Pestaña Datos generales Historias de Usuario . . . . . . . . . . . . . . . . 145
B.26. Pestaña Historias Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
B.27. Pestaña Planning Poker Historias de Usuario . . . . . . . . . . . . . . . . . 146
B.28. Pestaña Resultados Historias Usuario . . . . . . . . . . . . . . . . . . . . 147
B.29. Filtro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
xxiii
B.30. Ventana factores de influencias modificados . . . . . . . . . . . . . . . . . 148
B.31. Pestaña Resultados modificados . . . . . . . . . . . . . . . . . . . . . . . 148
B.32. Pestaña Resultados distribuciones modificados . . . . . . . . . . . . . . . . 149
B.33. Eliminar estimación seleccionada . . . . . . . . . . . . . . . . . . . . . . . 149
B.34. Ventana confirmar eliminar . . . . . . . . . . . . . . . . . . . . . . . . . . 150
B.35. Excel datos generales exportados . . . . . . . . . . . . . . . . . . . . . . . 150
B.36. Comparar resultados de las estimaciones . . . . . . . . . . . . . . . . . . . 151
B.37. Pestaña Resultados inserción resultados imputados . . . . . . . . . . . . . 151
B.38. Opción Modificar perfil . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
xxiv
Listado de acrónimos
TFG Trabajo de Fin de Grado

JS JavaScript
HTML 5 Lenguaje de Marcado para Hipertextos
HTML Lenguaje de Marcado para Hipertextos
CSS Hoja de estilo en cascada
AJAX JavaScript asíncrono y XML
ESI Escuela Superior de Informática
DQT EAM Data Quality Team S.L
DOM Modelo de Objetos del Documento
UCLM Universidad de Castilla-La Mancha
WYSIWYG What you see is what you get
TI Tecnologías de la Información
DET Data Element Type
RET Record Element Type
FTR File Type Referenced
ILF Ficheros lógicos internos
ELF Ficheros lógicos externos
EI Entradas externas
EO Salidas externas
EQ Consultas externas
MF Mainframe
MR Mid-Range
PC Personal Computer
M ULTI Multiplataforma
3GL Lenguaje de tercera generación
4GL Lenguaje de cuarta generación
G EN A P Generador de aplicaciones
COCOMO Constructive Cost Model
PUD Proceso Unificado de Desarrollo
XXV
Capítulo 1
Introducción
D esde antes de nacer, ya nos vemos sometidos a una serie de mediciones que determinan
nuestra vida; y, de hecho, la medición nos acompañará durante el resto de nuestra
vida y de forma cotidiana. Continuamente realizamos mediciones que nos guían a la hora
de tomar decisiones y seleccionar la alternativa que creemos mejor, tanto en nuestra vida
personal como en las diversas actividades profesionales [38].
La medición desde sus orígenes es una disciplina fundamental en las ingenierías, y la Inge-
niería del Software no debe ser una excepción, pero debemos tener presente que el software
cuenta con un conjunto de características que lo hacen diferente de otros productos.
Cuando nos encontramos en el entorno de proyectos de software, es difícil hacer una
diferenciación clara entre métodos o técnicas para la estimación de proyectos y métodos o
técnicas para la estimación del software. Se podría pensar que la diferencia es el tipo de tareas
estimadas en cada método, pero no siempre es determinante porque puede haber métodos que
permitan ambas opciones [34].
A finales del siglo XIX, Lord Kelvin afirmó: “Cuando puedes medir sobre lo que estás
diciendo, y expresarlo en números, sabes algo sobre ello, pero cuando no puedes medirlo ni
expresarlo en números entonces tu conocimiento es precario e insatisfactorio” [40].
La técnica de estimación en contraste con los modelos matemáticos, en los cuales los
controladores de costos explícitos se incluyen en los modelos como parámetros cuantitativos
o categóricos, no especifica qué parámetros se toman en cuenta o cómo son explícitamente
combinados [30].
La medición software es un campo joven, incluso más que la Ingeniería del Software, esto
ha influido en que la medición software no haya podido alcanzar todavía la madurez que
tienen otras ingenierías.
1
Esta necesidad por medir está asociada principalmente a la mejora, y una de las principales
razones de que haya aumentado el interés en las métricas ha sido la comprensión de que
pueden ayudarnos en la mejora de la calidad de nuestros procesos.
Desde hace algún tiempo, las organizaciones parecen estar más concienciadas sobre los
beneficios que supone una buena gestión de proyectos. Pero no siempre es fácil gestionar un
proyecto de manera exitosa. Esto está muy ligado con las estimaciones que se realizan sobre
un proyecto.
Desde 1994 el Standish Group, una organización independiente de investigación de las
Tecnologías de la Información (TI) internacionales fundada en 1985, publica el informe
CHAOS. Este informe da una visión sobre el fracaso o éxito de los proyectos en el sector de
las TI basándose en el triángulo de las tres restricciones: alcance, presupuesto y plazos.
El informe suele publicarse cada dos años, el último fue publicado en el año 2015. En
ésta última publicación se ha cambiado la definición de éxito de un proyecto. En lugar de
tomar como éxito el triángulo de las tres restricciones, la nueva definición de éxito es el
cumplimiento de los plazos, presupuesto y si se obtienen resultados satisfactorios [14].
Los retrasos en el coste y la duración del proyecto están directamente relacionados con
una mala estimación, de ahí la importancia de la precisión y exactitud de los datos que for-
man nuestra estimación. La calidad de los datos en los proyectos software es cada vez más
importante (entre ellos, los datos de estimación), ya que nos ayuda en la toma de decisiones
de nuestra organización. Por esto en Data Quality Team S.L (DQT EAM), empresa donde he
realizado este TFG, se trabaja para obtener datos de calidad y así poder ayudar a las organi-
zaciones a tomar mejores decisiones.
Dentro del desarrollo del software una de las principales fuentes de datos e información
para poder tomar decisiones son las estimaciones, y la precisión y exactitud de éstas. Por
ello se ha desarrollado una herramienta multimodelo basada en los principales estándares y
modelos de estimación que sirve para controlar y mejorar las estimaciones de las empresas
(desde un punto de vista tradicional con una gestión predictiva y desde un punto de vista ágil
con una gestión adaptativa), pudiendo mejorar así la calidad de los datos y, por tanto, la toma
de decisiones.
2
1.1 Contexto del problema
El presente TFG se ha realizado en la Escuela Superior de Informática (ESI) de Ciudad
Real, Universidad de Castilla-La Mancha (UCLM) con la empresa DQT EAM, por ello la alum-
na adquirió conocimiento sobre el uso de la metodología, herramientas y tecnología dispo-
nible en DQT EAM.
1.2 Estructura del documento

El presente documento está compuesto por 6 capítulos. A continuación, se describe el
contenido de cada uno de ellos.
Introducción: Primer capítulo, se introduce el problema que tratará este TFG y la

solución que se propone, también se incluye una estructura del documento.
Objetivos: Segundo capítulo, en este capítulo se presenta el objetivo que se desea
alcanzar y los subobjetivos.
Estado del arte: Tercer capítulo, en este capítulo se realiza una revisión completa
sobre el tema a tratar, se toma información relativa a los inicios y la evolución de las
empresas con la estimación, así como los conocimientos técnicos para poder entender
el problema.
Método de trabajo: Cuarto capítulo, en este capítulo se presenta y explica la elección
de la metodología de trabajo para realizar este proyecto, así como las iteraciones en
las que se ha dividido.
Resultados: Quinto capítulo, en este capítulo se exponen los resultados obtenidos du-
rante el desarrollo del proyecto.
Conclusiones: Sexto capítulo, se exponen las conclusiones obtenidas tras realizar el
trabajo, presentando también propuestas de trabajo futuro, así como una opinión per-
sonal del autor del proyecto.
Tras estos capítulos se incluye las referencias que han sido consultadas y citadas durante
el desarrollo de este documento.
En la parte final del presente documento se presentan los siguientes anexos:
Historias de Usuario
Manual de usuario
Contrato de Confidencialidad y Propiedad Intelectual
3
Capítulo 2
Objetivos
2.1 Objetivo principal

El objetivo principal de este TFG consiste en desarrollar un sistema multimodelo para la
estimación de proyectos software.
2.2 Objetivos parciales

Implementar los diferentes algoritmos que son utilizados posteriormente por ca-
da uno de los modelos de estimación
Análisis e implementación de los diferentes algoritmos utilizados por los modelos de
estimación.
Crear formularios para recoger los datos necesarios en cada modelo de estima-
ción
Recopilación de los datos generales y datos específicos de cada modelo de estimación.
Ofrecer mecanismos para la visualización, modificación y eliminación de las esti-
maciones realizadas anteriormente
Proveer de mecanismos para poder visualizar las estimaciones realizadas anteriormen-
te, así como su modificación y eliminación.
Exportar las estimaciones existentes
Generación de reportes basados en las estimaciones existentes.
Dar soporte a la imputación real de las estimaciones realizadas
Dar soporte a la obtención de los resultados reales de las estimaciones que se realizaron
con anterioridad.
Comparar esfuerzos y costes estimados respecto a los realmente incurridos
Cotejar los esfuerzos y costes estimados obtenidos con el sistema, respecto a los real-
mente incurridos.
5
2.3 Justificación
Este proyecto genera una solución al problema de la estimación del esfuerzo y coste de
proyectos software, permitiendo así la mejora de la calidad de nuestros procesos, principal-
mente los relacionados con la planificación, control y evaluación del proyecto.
Una gran ventaja que aportará este sistema desarrollado será que ofrece soporte a diferen-
tes modelos de estimación. De esta manera la herramienta se puede utilizar para proyectos
que siguen, un punto de vista tradicional con una gestión predictiva, como para proyectos
que siguen un punto de vista ágil, con una gestión adaptativa. Además de lo anterior, tam-
bién permitirá realizar comparaciones entre los resultados obtenidos con la herramienta y lo
imputado realmente tras la realización del proyecto, lo que permitirá a las empresas aprender
y ajustar sus factores de estimación.
6
Capítulo 3
Estado de la cuestión
E n este capítulo se presenta una visión general sobre los conceptos teóricos y técnicos
que sirven como base para la elaboración de este trabajo, contribuyendo a su base
tecnológica y de conocimiento.
3.1 Estimación
3.1.1 Evolución de las estimaciones
Los orígenes de la medición y estimación de software se sitúan en torno a finales de los
años 60, en los que aparecieron las primeras propuestas sobre las que se asentaron bases de
trabajo en el área.
En el año 1968 Rubery y Hartwick presentaron una métrica para la definición de la calidad
del software, que se basaba en el número de instrucciones originales y modificadas durante
la ejecución.
A finales de los años 70 se produjo una gran proliferación de métricas de complejidad,

basada en la idea de mejorar las métricas propuestas previamente, alcanzándose un estado en
el que, en 1979, Curtis llegó a afirmar que "hay más métricas de complejidad que científicos
de computación en activo"[38].
En 1974 Wolverton hizo uno de los primeros intentos para definir la productividad de un
programador usando líneas de código.
Una de las medidas que merece la pena destacar de esta época son los puntos función, fue
definida por Albretch en 1979 y que, a día de hoy, es una métrica fundamental para la gestión
de proyectos.
A finales de este periodo empieza a haber cierta repercusión del campo de la medición
en foros científicos. Además, aparecen talleres especializados como el IEEE Workshop on
Quantitative Software Models o el número especial de la revista IEEE Transactions on Soft-
ware Engineering en la que la investigación sobre métricas es la principal protagonista.
En los inicios de los años 80 se mantenía un cierto escepticismo sobre la aportación del
campo de la medición del software, debido a una serie de críticas sobre la imprecisión o la
simplicidad de las métricas.
7
Boehm en 1981 propuso el modelo COCOMO, uno de los modelos de estimación de costes
más aplicado y que se basa en la métrica de líneas de código.
Otro de los aspectos que cabe destacar en este período es la proliferación de proyectos de
investigación sobre medición de software. En Europa se desarrollan proyectos como MET-
KIT (Metrics Educational Toolkit), COSMOS (Cost Management with Metrics of Specifica-
tion) y MERMAID (Metrication and Resource Modelling Aid) [38].
En los años 90 se asentaron las bases iniciadas en el periodo anterior en relación a la

validación teórica de las métricas propuestas. Aparece el paradigma de orientación a objetos
y con ello surgen una gran cantidad de métricas para sistemas de orientación a objetos.
En la década del 2000 se da mayor importancia a la validación empírica de las métricas.

Aparece el importante papel de la medición del software en los estándares internacionales,
mediante el desarrollo específicos como la ISO 15939 y otros relacionados como ISO/IEC
9126, ISO/IEC 12207 O ISO 9000.
Después de conocer algunos de los aspectos de la historia de la estimación del software

se van a presentar los aspectos fundamentales de los modelos de estimación a los que dará
soporte el software desarrollado.
3.2 Modelos de estimación

3.2.1 Puntos función
Puntos función es la técnica algorítmica de estimación del tamaño de un producto software
más conocida. Propuesta por Albrecht en 1979, es una técnica muy extendida y que ha ido
evolucionando hasta prácticamente nuestros días como se puede ver en el cuadro 3.1.
3.2.1.1. ¿Qué son los puntos función?

"Es una métrica para establecer el tamaño y complejidad de los sistemas informáticos
basada en la cantidad de funcionalidad requerida y entregada a los usuarios"[38].
Partiendo de la definición anterior, se van a explicar sus características:
Tamaño: Los puntos función pretenden medir tamaño, no la calidad con la que se ha
realizado el software, ni el valor del producto, o el esfuerzo que ha sido requerido para
desarrollarlo.
Aplicaciones: Mide las aplicaciones de software, no considera el hardware que utili-

zará, ni la documentación, ni la gestión del proyecto.
Funcionalidad: Se refiere a la capacidad del software para que un usuario pueda rea-
lizar transacciones y guardar datos.
Usuario: Quien lo va a utilizar y no quién lo desarrolló o diseñó.
8
3.2.1.2. Historia de los puntos función
Los puntos función nacieron alrededor del año 1975 y surgieron y se difundieron por
Estados Unidos [12].
1979 - Allan Albrecht crea los FPA

1984 - Primer manual formal sobre FPA (IBM)
En sus comienzos
1986 - El primer IFPUG Board
1987 - El gobierno británico adopta FPA (una adaptación llamada MkII)
PF se extiende a Australia, Brasil, Italia, Japón y Sudáfrica, etc.
Aparecen algunas variaciones - COSMIC-FFP, NESMA FPA,
En la década de los 90 FiSMA FSM, Use Case Points, Early and Quick Function Points, etc.
1994 - IFPUG publica la versión 4 del manual de medición
PF se extiende a Corea, India y China
Los mayores usuarios de PF - Estados Unidos, Brasil, Italia y Corea
1999 - IFPUG publica la versión 4.1 del manual de medición de FP
2003 - El método IFPUG se convierte en el estándar ISO 20926 (no se
consideran los factores de ajuste)
En el sigo XXI
2004 - IFPUG publica la versión 4.2 del manual de medición de FPA
2007 - IFPUG inicia el TSF
2011 - IFPUG traducción al español de la versión 4.3 del manual
de medición
Cuadro 3.1: Cronología puntos función [12]
3.2.1.3. Características de los puntos función

A continuación, se listan las características principales de puntos función [38]:
Independiente de la tecnología. Una vez establecida la funcionalidad que requiere
la aplicación, se puede escoger la tecnología que hace más productivo al equipo para
obtener tal funcionalidad.
Simple. Puntos función es una métrica planteada para que no requiera grandes esfuer-
zos a la hora de su cálculo. Gracias a esto se puede establecer el tamaño de un producto
software que tal vez llegue a tener miles de líneas de código en pocas horas.
Enfoque en la funcionalidad proporcionada. Antes de realizar cualquier evaluación
técnica, el primer criterio que debemos evaluar es qué nuevas capacidades vamos a
obtener con el nuevo software.
Basada en los requisitos de usuario. Esta característica ayuda al usuario a entender el
significado del tamaño del producto software sin necesidad de tener que ser un experto
en sistemas. Otro punto importante es que se puede establecer el tamaño desde que
obtenemos los requisitos y no tendríamos que esperar a terminar el proyecto para saber
el tamaño de éste.
Consistencia. Los resultados obtenidos en proyectos distintos deben ser consistentes.
9
3.2.1.4. Procedimiento de cálculo de puntos función
A continuación, se van a explicar los pasos generales para el cálculo de puntos función
para nuevos desarrollos:
1. Calcular los puntos función sin ajustar:
1.1. Contar el número de funciones de usuario (Identificar los cinco elementos fun-
cionales). Los cinco elementos funcionales que debemos identificar son:
Ficheros lógicos internos (ILF): Grupo de datos relacionados lógicamente
o información de control reconocida por el usuario y mantenido dentro de
los límites de la aplicación.
Ficheros lógicos externos (ELF): Grupo de datos relacionados lógicamente,
identificable por el usuario, referenciado por la aplicación, pero mantenido
dentro de los límites de otra aplicación.
Entradas externas (EI): cualquier entrada que tenga un formato único o
un solo procesamiento, a través de la cual el usuario u otro programa puede
añadir, borrar o cambiar datos.
Salidas externas (EO): cualquier salida que tenga un formato diferente o
requiera un procesamiento diferente a otros tipos de salida, generada para el
usuario u otro programa.
Consultas externas (EQ): Combinaciones de entrada/salida en las que cada
entrada genera una salida simple e inmediata.
1.2. Determinar el nivel de complejidad de cada función de usuario. Para ello tenemos
en cuenta el número de tipos de elementos de datos y el número de tipos de
archivos referenciados.
Número de tipos de elementos de datos incluidos (Data Element Ty-
pe (DET)). Se debe contar un DET por cada subgrupo de datos elementales
reconocibles por el usuario.
Número de tipos de archivos lógicos referenciados (File Type Referenced
(FTR)). Se debe contar un FTR por cada fichero (interno o externo) leído por
el proceso de la entrada, salida o consulta.
Número de archivos lógicos internos referenciados (Record Element Ty-
pe (RET)). Se debe contar un RET por cada subgrupo de datos elementales
reconocibles por el usuario. Cabe destacar que los RET solo se identifican en
los ILF y los ELF.
Una vez determinados el número de DET, RET y FTR se determina la complejidad
conforme a las siguientes tablas 3.2, 3.3 y 3.4:
10
Número de tipos de Número de tipos de elementos de datos incluidos
registros referenciados 1-4 5-15 >=16
0-1 Baja Baja Media
2-3 Baja Media Alta
>=4 Media Alta Alta
Cuadro 3.2: Complejidad de las entradas

0-1 Baja Baja Media
2-3 Baja Media Alta
>=4 Media Alta Alta
Cuadro 3.3: Complejidad de las Salidas y Consultas

0-1 Baja Baja Media
2-5 Baja Media Alta
>=6 Media Alta Alta
Cuadro 3.4: Complejidad de los Archivos y las Interfaces
11
1.3. Aplicar pesos de complejidad. Aplicar pesos según el nivel de complejidad. La
suma para todas las funciones de usuario equivale al número de puntos función
sin ajustar.
Tipo de función Nivel de

Peso
de usuario complejidad
Baja 7
Ficheros lógicos
Media 10
internos
Alta 15
Baja 5
Ficheros lógicos
Media 7
externos
Alta 10
Baja 3
Entradas Media 4
Alta 6
Baja 4
Salidas Media 5
Alta 7
Baja 3
Consultas Media 4
Alta 6
Cuadro 3.5: Peso de los diferentes elementos
2. Calcular los puntos función ajustados:

Ajustar los puntos función obtenidos anteriormente para tener en cuenta la compleji-
dad del proceso. Para ello, se valora el grado de influencia de 14 factores diferentes.
A continuación, se explican los 14 factores de influencia:
Comunicaciones de datos: concerniente a la transmisión de datos o información
de control, enviados o recibidos mediante algún sistema de comunicaciones.
Procesamiento de datos distribuidos: concerniente a si una aplicación es mo-
nolítica y se ejecuta en un único procesador, o si la aplicación consiste en código
independiente ejecutándose en procesadores distintos y persiguiendo un fin co-
mún.
Rendimiento: Las aplicaciones que soportan negocios o aplicaciones críticas
tienen importantes restricciones.
Configuración de uso intensivo: describe el grado en que las restricciones de
recursos de la máquina influenciarán el desarrollo de la aplicación.
Tasas de transacción rápidas: describe el grado en que el ratio de transacciones
de negocio influenciarán el desarrollo de la aplicación.
Entrada de datos online: describe el grado de entrada de datos de forma inter-
activa.
12
Eficiencia de Usuario Final: mide la facilidad de uso de la aplicación de cara al
usuario final.
Actualización de datos online: tendrá puntuación máxima si las actualizaciones
en línea son obligatorias y especialmente dificultosas, quizá debido a la nece-
sidad de realizar copias de seguridad, o de proteger los datos contra cambios
accidentales.
Procesamiento complejo: se considera complejo cuando hay muchas interac-
ciones, puntos de decisión o gran número de ecuaciones lógicas o matemáticas.
Reutilización: indica si gran parte de la funcionalidad del proyecto está pensada
para un uso intensivo por otras aplicaciones.
Facilidad de instalación: mide si durante el desarrollo se consideran factores
que facilitan la instalación.
Facilidad de operación: mide si se han tenido en cuenta factores de operativi-
dad. Se han considerado procedimientos de arranque, de copia de respaldo y de
recuperación.
Múltiples localizaciones: la aplicación se diseña para soportar múltiples instala-
ciones en diferentes entornos y organizaciones.
Facilidad de cambio: se han tenido en cuenta criterios que facilitarán el posterior
mantenimiento.
Una vez elegidos los 14 factores. Utilizaremos la siguiente fórmula para obtener los
puntos función ajustados:
PF=PFSA*(0,65+0,01*(SUMA(GI)))
Siendo:
PF los puntos función ajustados,
PFSA los puntos función sin ajustar, y
SUMA(GI) la suma de los grados de influencia de los 14 factores que influyen
en la complejidad del proceso.
3.2.1.5. Procedimiento de cálculo del esfuerzo

Una vez obtenidos los puntos función ajustados podremos obtener el esfuerzo del equipo
de desarrollo de nuestro proyecto. Para ello se utiliza la siguiente fórmula:
Esfuerzo= C*P F E
13
Donde:
PF son los puntos función del proyecto que se quiere estimar,
C y E son factores de calibrado o de corrección para que el esfuerzo se ajuste mejor.
Los factores C y E toman distintos valores en función de las características que tiene el
proyecto que se está estimando (Véase tabla 3.6).
Características C E
1 MF 49,02 0,736
2 MR 78,88 0,646
3 PC 48,90 0,661
4 MULTI 16,01 0,865
5 3GL 54,65 0,717
6 4GL 29,50 0,758
7 GenAp 68,11 0,660
8 Mantenimiento 52,58 0,683
9 Nuevo 39,05 0,731
10 MF-3GL 65,37 0,705
11 MF-4GL 52,09 0,640
12 MF-GenAp 65,68 0,692
13 MR-3GL 126,3 0,565
14 MR-4GL 62,35 0,694
15 PC-3GL 60,46 0,648
16 PC-4GL 36,48 0,694
17 Multi-3GL 19,82 0,666
18 Multi-4GL 6,49 0,983
19 MF-3GL-Mantenimiento 83,27 0,650
20 MF-3GL-Nuevo 59,21 0,745
21 MF-4GL-Mantenimiento 69,37 0,538
22 MF-4GL-Nuevo 102,8 0,546
23 MF-GenAp-Nuevo 65,68 0,692
24 MR-3GL-Mantenimiento 123,2 0,585
25 MR-3GL-Nuevo 81,36 0,623
26 MR-4GL-Mantenimiento 96,31 0,616
27 PC-3GL-Mantenimiento 83,66 0,528
28 PC-3GL-Nuevo 48,60 0,699
29 PC-4GL-Mantenimiento 29,84 0,731
30 PC-4GL-Nuevo 42,58 0,668
31 Multi-3GL-Mantenimiento 5,05 1,135
32 Multi-3GL-Nuevo 58,16 0,664
33 Multi-4GL-Mantenimiento 115,8 0,450
Cuadro 3.6: Parámetros para la estimación del esfuerzo [38]
14
A continuación, se explican las características que aparecen en la tabla anterior:
Tipo de desarrollo:
• Nuevo: Proyectos en los que se desarrollan aplicaciones nuevas.
• Mantenimiento: Proyectos que se dedican a mejorar o mantener las aplicaciones
existentes.
Plataforma:
• Mainframe (MF): Llamamos mainframe a un tipo de ordenador grande, potente
y costoso capaz de procesar una gran cantidad de datos de manera muy rápida. Y
capaz de atender a una gran cantidad de clientes de manera simultánea.
• Mid-Range (MR): Un Mid-Range es un ordenador más grande que un micro
computador u ordenador personal pero más pequeño que un mainframe. Suelen
cumplir la función de servidores en entornos multiusuarios.
• Personal Computer (PC): Es un ordenador personal o micro computador.
• Multiplataforma (M ULTI): Es una combinación de las plataformas anteriores.
Tipo de lenguaje:
• Lenguaje de tercera generación (3GL): Consideramos lenguajes de tercera gene-
ración algunos como COBOL, C, Pascal o Fortan. También consideramos len-
guajes 3GL los lenguajes “modernos“ como Visual Basic, C++, Java, etc.
• Lenguaje de cuarta generación (4GL): Los lenguajes de cuarta generación son
más fáciles de utilizar que los lenguajes de tercera generación, debido a que ofre-
cen interfaces gráficas y capacidades de gestión avanzadas, aunque consumen
más recursos del ordenador.
• Generador de aplicaciones (G ENA P): Hace referencia a herramientas que permiten
la generación de aplicaciones de manera automática, tanto a nivel de datos como
a nivel de funcionalidad.
3.2.1.6. Procedimiento de cálculo del coste

Una vez obtenido el esfuerzo podemos obtener el coste total del proyecto. Para ello se
utiliza la siguiente fórmula:
Coste= Esfuerzo * Coste-Medio-Hora
Donde:
Esfuerzo es el total de horas estimado, y
Coste-Medio-Hora es el coste promedio de la hora de las personas que trabajarán en el
proyecto.
15
3.2.1.7. Estimaciones por fases del ciclo de vida
Para estimar el esfuerzo y coste para cada fase del proyecto se tendrá que multiplicar el
valor total del esfuerzo o del coste, según corresponda, por el porcentaje correspondiente a
cada fase. Distinguimos entre proyectos de desarrollo y proyectos de mantenimiento.
A continuación en las tablas 3.7 y 3.8, se muestran los porcentajes correspondientes a cada
fase:
Planificación Especificación Diseño Construcción Pruebas Implantación

9% 11 % 15 % 43 % 16 % 6%
Cuadro 3.7: Distribución por fases del ciclo de vida para los proyectos de desarrollo [38]
Planificación Especificación Diseño Construcción Pruebas Implantación

9% 9% 13 % 39 % 25 % 5%
Cuadro 3.8: Distribución por fases del ciclo de vida para proyectos de mantenimiento [38]
3.2.2 COCOMO II
Constructive Cost Model (COCOMO) es el modelo de estimación de costes del software
más utilizado. La primera versión de COCOMO fue desarrollado por Barry Boehm en 1981,
conocida como COCOMO 81.
3.2.2.1. ¿Qué es COCOMO?

Es un modelo matemático de base empírica utilizado para la estimación de costos de
software [11].
3.2.2.2. Historia de COCOMO

En el año 1981 Barry Boehm desarrolla el modelo COCOMO acorde a las prácticas de
desarrollo software de aquel momento. Durante la década de los 80 el modelo, se continuó
perfeccionando y consolidando, siendo el modelo más utilizado en el mundo para la estima-
ción de costos [31].
En el año 1983 se introduce el lenguaje de programación Ada para reducir los costos de
desarrollo de grandes sistemas. Algunos aspectos de Ada provocaron un gran impacto en los
costos de desarrollo y mantenimiento, por lo que Barry Boehm y Walker Royce definieron
un modelo revisado, llamado Ada COCOMO [32].
En los años 90 las técnicas de desarrollo de software dieron un giro, surgiendo la necesidad
de reusar el código existente, la introducción de librerías en los proyectos, etc. Estos cambios
hicieron que se tuviera que reinventar el modelo, por lo que apareció COCOMO II.
Las incorporaciones a este modelo lo reforzaron para ser aplicado en proyectos vinculados
16
a tecnologías como orientación a objetos, desarrollo incremental, composición de aplicación,
y reingeniería.
En la actualidad se sigue utilizando el modelo COCOMO II.
3.2.2.3. Modelos de estimación en COCOMO II

COCOMO II posee tres modelos, en función del grado de detalle que se dispone de la
información del sistema que se va a estimar. De menor a mayor detalle son:
Composición de aplicación: se emplea en desarrollos de software durante la etapa de
prototipado.
Diseño temprano (Early Design): Usado en las etapas iniciales cuando se conoce po-
co sobre el tamaño del producto, la plataforma, el personal o el proceso. Este modelo
utiliza 7 conductores de coste, o multiplicadores de esfuerzo, que afectan multiplicati-
vamente al esfuerzo y 5 factores de escala, que afectan exponencialmente al esfuerzo
del proyecto.
Post-Arquitectura (Post-Architecture): se aplica en la etapa de desarrollo, después
de definir la arquitectura del sistema, y en la etapa de mantenimiento. Este modelo
utiliza 17 conductores de coste que permiten considerar características del proyecto
referentes al personal, plataforma de desarrollo, etc. e incluye modificadores de tamaño
para valorar la reutilidad y otros aspectos.
3.2.2.4. Cálculo del tamaño

En la estimación del tamaño del software en COCOMO II utilizamos tres técnicas:
Puntos Objeto: Los puntos objeto son una medida alternativa relacionada con la fun-
cionalidad cuando se utilizan lenguajes 4GLs o similares para el desarrollo del pro-
yecto. Los puntos objeto no son clases de objetos. El número de puntos objeto viene
de una estimación ponderada de:
• El número de pantallas que son visualizadas por separado,
• El número de informes que son generados por el sistema, y
• El número de componentes 3GL que deben desarrollarse para completar el códi-
go 4GL
Puntos función no ajustados: Explicado anteriormente en el punto 3.2.1.4, apartado
1. Para determinar el esfuerzo nominal en el modelo COCOMO II los puntos función
no ajustados tienen que ser convertidos a líneas de código fuente considerando el len-
guaje de implementación. Esto se realiza para los modelos Diseño Temprano y Post
Arquitectura.
Para convertir los puntos función a líneas de código utilizamos la tabla 3.9:
17
Lenguaje Tamaño LOC
1 IntegraNova 5,33
2 Excel 6,400
3 BPM 7,11
4 Generators 7,11
5 Mathematica10 9,143
6 Mathematica9 12,800
7 TranscriptSQL 12,800
8 QBE 12,800
9 X 12,800
10 TELON 16,000
11 APS 16,842
12 Forte 17,778
13 MUMPS 18,824
14 IBM ADF 20,000
15 Smalltalk 21,333
16 Eiffel 22,857
17 ASP NET 24,615
18 Objetive C 26,667
19 Visual Basic 26,667
20 Delphi 29,091
21 APL 32,000
22 Julia 35,556
23 M 35,556
24 OPA 35,556
25 Perl 35,556
26 Elixir 37,647
27 Haskell 37,647
28 Mixed Languages 37,647
29 R 25,000
30 DB2 40,000
31 LiveScript 40,000
32 Oracle 40,000
33 Erlang 42,667
34 CICS 45,714
35 DTABL 45,714
36 F# 45,714
37 Ruby 45,714
38 Simula 45,714
39 Dart 47,407
40 RPG III 47,407
18
Lenguaje Tamaño LOC
41 Ada 95 49,231
42 Ceylon 49,231
43 Fantom 49,231
44 C# 51,200
45 X10 51,200
46 C++ 53,333
47 Go 53,333
48 Java 53,333
49 PHP 53,333
50 Python 53,333
51 Zimbu 58,182
52 Quick Basic 60,952
53 Basic (interpreted) 64,000
54 Forth 64,000
55 haXe 64,000
56 Lisp 64,000
57 Prolog 64,000
58 SH (shell scripts) 64,000
59 ESPL/l 71,111
60 JavaScript 71,111
61 ABAP 80,000
62 Modula 80,000
63 PL/l 80,000
64 Pascal 91,429
65 PL/S 91,429
66 GW Basic 98,462
67 Algol 106,667
68 Bliss 106,667
69 Chill 106,667
70 COBOL 106,667
71 Coral 106,667
72 Fortran 106,667
73 Jovial 106,667
74 C 128,000
75 XML 128,000
76 HTML 160,000
77 Macro Assembly 213,333
78 JCL 220,690
79 Basic Assembly 320,000
80 Machine Language 640,000
Cuadro 3.9: Equivalencia puntos función en líneas de código [36]
19
Líneas de código fuente: El objetivo es medir la cantidad de trabajo en el desarrollo
de un programa. Definir una línea de código es difícil debido a que existen diferencias
conceptuales cuando se cuentan sentencias ejecutables y de declaraciones de datos en
lenguajes diferentes.
3.2.2.5. Estimación del esfuerzo

El esfuerzo necesario para realizar un proyecto de desarrollo de software, sea cual sea el
modelo utilizado, se expresa en meses/persona (PM) y representa los meses de trabajo de
una persona fulltime, requeridos para desarrollar el proyecto. A continuación, se explica la
estimación del esfuerzo para los diferentes modelos:
Modelo de Composición de Aplicación
La fórmula propuesta para este modelo:
PM=NOP/PROD
Donde:
• NOP (Nuevos Puntos Objeto) es el tamaño del software a desarrollar expresado
en puntos objeto
NOP=OP*(100- %reuso)/100
◦ OP (Puntos Objeto) es el tamaño del software a desarrollar expresado en
Puntos Objeto.
◦ %reuso es el porcentaje que se espera lograr en el proyecto.
• PROD es el promedio de la productividad determinada a partir del análisis de
datos del proyecto.
Modelo de diseño temprano (EDM) y Modelo Post-Arquitectura (PAM)
La fórmula para calcular el esfuerzo nominal en el modelo EDM en el modelo PAM
es la misma y corresponde con:
P Mnominal = Ax(KSLOC)B
Donde:
• A es una constante que captura los efectos lineales sobre el esfuerzo de acuerdo
a la variación del tamaño. En nuestro caso A tiene el valor 2.94.
• KSLOC es el tamaño del software a desarrollar expresado en miles de líneas de
código fuente.
• B es factor de escala para tener en cuenta las diversas economías de escala, posi-
tivas o negativas, existentes en proyectos software.
20
5
X
B=0.91+0.01* Wi
i=1
Donde:
◦ Wi es el sumatorio de los 5 factores de escala, a los que se le asignan un peso
de 0 (muy bajo) a 5 (muy alto). Estos factores son:
PREC: Ausencia de precedentes
FLEX: Flexibilidad de desarrollo
RESL: Resolución Arquitectura/Riesgos (mide una combinación del uso
de la gestión de riesgos y de la minuciosidad al diseñar la arquitectura
del sistema)
TEAM: Cohesión del equipo
PMAT: Madurez del proceso (basado en utilizar el modelo CMM - Ca-
pability Maturity Model- del Software Engineering Institute)
Para obtener el esfuerzo estimado tendremos que aplicar unos multiplicadores al es-
fuerzo nominal obtenido anteriormente. Estos multiplicadores se denominan multipli-
cadores de esfuerzo, y son los factores de costo que tienen un efecto multiplicativo
sobre el esfuerzo. Cada factor se puede clasificar en 6 o 16 niveles diferentes (según
el modelo), que expresan el impacto del multiplicador sobre el esfuerzo de desarrollo.
Esta escala varía desde un nivel Extra Bajo hasta un nivel Extra Alto.
La fórmula para obtener el esfuerzo estimado es:
N
Y
P Mestimado = P Mnominal ∗ EMi
i=1
Donde:
• EM son los multiplicadores de esfuerzo.
Estos factores en el modelo EDM son:
◦ RCPX: Fiabilidad y complejidad del producto.
◦ RUSE: Reutilización requerida.
◦ PDIF: Dificultad de la plataforma.
◦ PERS: Capacidad del personal.
◦ PREX: Experiencia del personal.
◦ FCIL: Medios.
Estos factores en el modelo PAM se obtienen al desglosar los 7 anteriores, agru-
pándose en 4 categorías:
◦ Producto
RELY: Fiabilidad del producto requerida.
DATA: Tamaño de la base de datos.
21
CPLX: Complejidad del producto.
DOCU: Adecuación de la documentación a las necesidades del ciclo de
vida.
RUSE: Reutilización requerida.
◦ Plataforma
TIME: Limitaciones en el tiempo de ejecución.
STOR: Limitaciones en el almacenamiento principal
PVOL: Volatilidad de la plataforma
◦ Personal
ACAP: Capacidad de los analistas.
PCAP: Capacidad del programador.
PCON: Continuidad del personal.
AEXP: Experiencia en las aplicaciones.
PEXP: Experiencia en la plataforma.
LTEX: Experiencia con el lenguaje y las herramientas.
◦ Proyecto
TOOL: Uso de herramientas software.
SITE: Desarrollo en varios sitios.
3.2.2.6. Estimación de la duración

La estimación del tiempo de desarrollo, conociendo el esfuerzo estimado (en personas/-
mes) se calcula con la siguiente fórmula:
%SCED
T DEV = [3,67 ∗ P M (0,28+0,2∗(B−0,91)) ] ∗
100
Donde:
PM es el esfuerzo expresado en meses-horas
SCED % es el porcentaje de reducción o incremento en el calendario nominal del pro-
yecto
B es el factor de escala para tener en cuenta las diversas economías de escala, positivas
o negativas, existentes en proyectos software.
22
3.2.2.7. Estimación del coste
El coste estimado para el proyecto se calcula con la siguiente fórmula:
Coste = P Mestimado ∗ Ratio
Donde:
PMestimado es el esfuerzo estimado,
Ratio cantidad de dinero que debe cobrar por mes el desarrollador de cada módulo.
3.2.2.8. Estimación de la productividad

Para obtener la productividad estimada del proyecto se utilizará la siguiente fórmula:
P roductividad = T amano_del_modulo/P Mestimado
Donde:
Tamano_del_modulo es el tamaño del módulo en líneas de código,
PMestimado es el esfuerzo estimado.
3.2.2.9. Estimación del coste por instrucción

Para calcular el coste por línea de código se utilizará la siguiente fórmula:
Coste_instruccion= Coste/Tamano_del_modulo
Coste es el coste estimado para el proyecto,

Tamano_del_modulo es el tamaño del módulo en líneas de código.
3.2.2.10. Estimación del personal

Estimación del número de desarrolladores necesarios para completar un módulo en el
tiempo de desarrollo estimado. Para calcular el personal se utilizará la siguiente fórmula:
P ersonal = P Mestimado /Duracion
Duración cantidad de meses estimada para la realización del proyecto,

PMestimado es el esfuerzo estimado.
23
3.2.3 Puntos Casos de Uso
3.2.3.1. ¿Qué son los Puntos Casos de Uso?
Método de estimación del tiempo de desarrollo de un proyecto mediante la asignación de
pesos a un cierto número de factores que lo afectan.
3.2.3.2. Historia
Este modelo fue desarrollado por Gustav Kamer en 1993, basándose en el modelo de
puntos función, y bajo la supervisión de Ivar Jacobson, creador de los casos de uso y gran
promovedor del desarrollo de UML y el Proceso Unificado [20].
Este método ha sido utilizado por la empresa Rational Software (posteriormente adquirida
por IBM) durante varios años y obteniendo muy buenos resultados [19].
Ha sido analizado posteriormente en otros estudios, como la tesis de Kirsten Ribu (Uni-
versidad de Oslo) en 2001.
3.2.3.3. Procedimiento de Cálculo de los Puntos Casos de Uso

A continuación, se van a explicar los pasos generales para el cálculo de puntos casos de
uso:
1. Calcular los puntos casos de uso sin ajustar:
Para realizar el cálculo de los Puntos Caso de Uso sin ajustar, se tienen que realizar los
pasos definidos a continuación.
1.1. Clasificar cada interacción entre actor y caso de uso según su complejidad y asig-
nar un peso en función de ésta.
Para poder clasificar la complejidad de los actores tenemos que saber las interac-
ciones que éste tiene con el sistema que se va a desarrollar.
La complejidad de los actores se corresponde con una de estas tres categorías:
Simple: representa un sistema con una API definida.
Media: Representa a otro sistema que interactúa a través de un protocolo de
comunicaciones.
Compleja: La interacción se realiza a través de una interfaz gráfica.
A continuación en la tabla 3.10, se muestran los pesos asignados a cada categoría:
24
Tipo de interacción Peso
Simple 1
Medio 2
Complejo 3
Cuadro 3.10: Tabla con los pesos en función de la complejidad de la interacción con los
actores [19].
Por último, Se calcula el factor de peso de los actores sin ajustar, para ello utili-
zamos la siguiente fórmula:
UAW=SUM(CantidadTipoDeUnActor*Peso)
1.2. Calcular la complejidad de cada caso de uso según el número de transacciones o

pasos del mismo.
Para calcular la complejidad de un caso de uso debemos determinar el número de
transacciones, se entiende por transacción a un conjunto de actividades atómicas,
donde se ejecutan todas ellas o ninguna.
En función del número de transacciones que posee un caso de uso se pueden
clasificar en las siguientes categorías:
Simple: El número de transacciones es mayor o igual que 3.
Media: El número de transacciones es mayor o igual que 4 y menor que 7.
Compleja: El número de transacciones es mayor o igual que 7.
A continuación en la tabla 3.11, se muestran los pesos asignados a cada categoría:
Tipo de interacción Peso

Simple 5
Medio 10
Complejo 15
Cuadro 3.11: Tabla con los pesos en función de la complejidad de los casos de uso [20].
Por último, se calcula el factor de peso de los casos de uso sin ajustar, para ello
utilizamos la siguiente fórmula:
UUCW=SUM(CantidadTipoDeUnCasoDeUso*Peso)
1.3. Calcular los puntos casos de uso sin ajustar.

Para obtener los puntos casos de uso sin ajustar utilizaremos la siguiente fórmula:
UUCP=UAW+UUCW
2. Calcular los puntos casos de uso ajustados:

El siguiente paso es ajustar los puntos casos de uso obtenidos anteriormente, para ello
se valora el grado de influencia de 13 factores de complejidad técnica y 8 factores de
complejidad del entorno.
25
2.1. Cálculo de los factores técnicos.
Se compone de 13 factores que evalúan la complejidad de los módulos del siste-
ma que se desarrolla, cada uno de estos factores tiene un peso definido, y se le
asigna un valor de influencia entre 0 y 5.
A continuación en la tabla 3.12, se muestran los 13 factores con sus correspon-
dientes pesos:
Factor Descripción Peso

R1 Sistema distribuido 2
R2 Objetivos de rendimiento 1
R3 Eficiencia respecto al usuario final 1
R4 Procesamiento complejo 1
R5 Código reutilizable 1
R6 Instalación sencilla 0,5
R7 Fácil Utilización 0,5
R8 Portabilidad 2
R9 Fácil de cambiar 1
R10 Uso concurrente 1
R11 Características de seguridad 1
R12 Accesible por terceros 1
R13 Se requiere formación especial 1
Cuadro 3.12: Peso de los factores de complejidad técnica [20].
Con la siguiente fórmula se calcula el Factor Técnico que aplicaremos en la fór-

mula final para calcular los puntos casos de uso ajustados:
i=13
X
TCF=0,6+(0,01* Ri)
i=1
Donde:
Ri es el sumatorio de la influencia de cada factor por el peso asignado a ese
factor.
2.2. Cálculo de los factores de entorno.
Se compone de 8 factores que evalúan las habilidades y la experiencia del grupo
de personas involucrada en el desarrollo del proyecto. Cada uno de estos factores
tiene un peso definido, y se le asigna un valor de influencia entre 0 y 5.
A continuación en la tabla 3.13, se muestran los 8 factores con sus correspon-
dientes pesos:
26
Factor Descripción Peso
R1 Familiar con RUP 1,5
R2 Experiencia en la aplicación 0,5
R3 Eficiencia con orientación a objetos 1
R4 Capacidades de análisis 0,5
R5 Motivación 1
R6 Requisitos estables 2
R7 Trabajadores a tiempo parcial -1
R8 Lenguaje completo -1
Cuadro 3.13: Peso de los factores de complejidad del entorno [20].
Con la siguiente fórmula se calcula el Factor de Entorno que aplicaremos en la

fórmula final para calcular los puntos casos de uso ajustados:
i=8
X
EF=1,4-(0,03* Ri)
i=1
Donde:
Ri es el sumatorio de la influencia de cada factor por el peso asignado a ese
factor.
Una vez que hemos obtenido el factor técnico y el factor de entorno, multiplicamos
éstos con los puntos función sin ajustar utilizando la siguiente fórmula:
UCP=UUCP*TCF*EF

Este cálculo se realiza con el fin de tener una aproximación del esfuerzo, pensando solo en
el desarrollo según las funcionalidades de los casos de uso. Para ello se utilizará la siguiente
fórmula:
Esfuerzo= UCP * Factor_Productividad
Anteriormente en el factor de productividad, se sugería utilizar 20 horas persona por UCP,

pero a través del tiempo esto ha ido cambiando. Está basado en los factores de entorno y se
calcula de la siguiente manera:
Lo primero que se debe hacer es contar la cantidad de factores de entorno del E1 al E6 que
tienen una puntuación menor a 3, y contar la cantidad de estos mismos del E7 y E8 que son
mayores que 3.
Después evaluaremos el resultado anterior en la tabla 3.14:
27
Horas-Persona Descripción
20 valor <= 2
28 valor <= 4
36 valor >= 5
Cuadro 3.14: Cantidad horas-persona según el valor [19].
Se debe destacar, que el valor del esfuerzo estimado, calculado mediante la expresión
presentada anteriormente, no cubre todas las fases del ciclo de vida del proyecto, sino que se
refiere únicamente a las horas-persona invertidas en la fase de codificación [19].
Para obtener el esfuerzo en cada fase habría que multiplicar el esfuerzo calculado por el
porcentaje correspondiente a cada fase.
Estos porcentajes se corresponden con los mostrados en las tablas 3.7 y 3.8.

Una vez obtenido el esfuerzo podemos obtener el coste total del proyecto. Para ello se
utilizará la siguiente fórmula:
pago
Coste= Esfuerzo *(Numero_desarrolladores* hora )
Donde:
Esfuerzo es la suma total de los esfuerzos calculados por cada fase del ciclo de vida.
Numero_desarrolladores es el número de desarrolladores que trabajan en el proyecto.
pago
hora
es el salario del desarrollador en una hora.
3.2.4 Backfiring
3.2.4.1. ¿Qué es backfiring?
Es un método que consiste en derivar el número de puntos de función de la aplicación a
partir de su tamaño físico [1].
3.2.4.2. Historia
A principios de la década de 1970, la empresa IBM se dio cuenta de que las métricas de
líneas de código tenían graves fallos como métrica de productividad, porque penalizaba los
lenguajes modernos e invisibilizaba el trabajo de no codificación.
Alan Albrecht y sus compañeros de IBM White Plains comenzaron a desarrollar el modelo
de puntos función. A medida que se probaba la métrica de puntos función, se observó que
varios lenguajes tenían niveles característicos, o número de enunciados de código por punto
función. Estas observaciones condujeron a un concepto llamado Backfiring o conversión
matemática entre los datos LOC más antiguos y los puntos de función más nuevos [36].
28
Backfiring no era preciso, pero era fácil de realizar y pronto se convirtió en un método de
tamaño común para aplicaciones heredadas donde el código ya existía.
En 2014, varias compañías como Garner Group, QSM y Software Productivity Research
venden tablas comerciales de tasas de conversión para más de 1000 lenguajes de programa-
ción. Curiosamente, los valores entre estas tablas no son siempre los mismos para idiomas
específicos [36].
Actualmente Backfiring sigue siendo popular a pesar de su baja precisión para lenguajes
específicos.
3.2.4.3. Procedimiento de obtención de los Puntos Función

Para obtener el número total de puntos función tenemos que determinar el tamaño físi-
co del sistema en líneas de código a partir de los lenguajes utilizados en el proyecto. Para
esto realizamos la transformación de las líneas de código correspondientes a cada lengua-
je utilizado a través de la siguiente tabla de conversión 3.9. Una vez realizadas todas las
transformaciones se sumarian y obtendríamos el total de puntos función ajustados.

El esfuerzo para los proyectos estimados con la técnica de Backfiring se calcula igual que
el esfuerzo para los proyectos estimados con la técnica de Puntos Función.
Para ello se utilizará la siguiente fórmula:
Esfuerzo= C*P F E
Donde:
PF corresponde con lo puntos función ajustados anteriormente, y
C y E son constantes que vienen determinadas por las características del sistema, y
cuyo valor obtenemos de la tabla 3.6.

El coste para los proyectos estimados con la técnica de Backfiring se cálcula igual que el
coste para los proyectos estimados con la técnica de Puntos Función.
Para ello utilizaremos la siguiente fórmula:
Coste=Esfuerzo*Coste-Medio-Hora
Donde:
Esfuerzo es el total de horas estimado, y
29
Coste-Medio-Hora es el coste promedio de la hora de las personas que trabajarán en el
proyecto.
3.2.4.6. Estimaciones por fases del ciclo de vida

Para estimar el esfuerzo y coste de cada fase del proyecto se tendrá que multiplicar el
valor total del esfuerzo o del coste, según corresponda, por el porcentaje correspondiente a
cada fase. Las tablas utilizadas son las mismas que las que se utilizan en el modelo Puntos
Función 3.7 y 3.8.
3.2.5 Historias de Usuario

3.2.5.1. ¿Qué son las Historias de Usuario?
Las historias de usuario son descripciones cortas de una necesidad de un cliente del softwa-
re que estemos desarrollando. Su utilización es común cuando se aplican marcos de trabajo
ágiles, tales como Scrum o Extreme Programming [37].
3.2.5.2. Características de las Historias de Usuario

Algunas de las características que deben tener las historias de usuario son:
Independientes. Se debe intentar que no dependan de otras historias de usuario para
que pueda completarse.
Negociables. Deben ser ambiguas en su enunciado para poder debatirlas, dejando su
definición a los criterios de aceptación.
Valoradas. Deben ser valoradas por el cliente para poder saber cuánto aporta al Valor
de la aplicación, y junto con la estimación convertirse en un criterio de prioridad.
Estimables. Tener su alcance lo suficientemente definido como para poder suponer una
medida de trabajo en la que pueda ser completada.
Pequeñas. Para poder realizar una estimación con cierta validez y no perder la visión
de la Historia de Usuario. Se recomienda que sean mayores de dos días y menores de
dos semanas.
Verificables. Definir, junto al cliente, unos criterios de aceptación que verifiquen si se
ha cumplido con las funcionalidades descritas y esperadas.
30
3.2.5.3. Formato de una Historia de Usuario
En la figura 3.1 se visualiza el formato de una historia de Usuario:
Figura 3.1: Formato de una Historia de Usuario
Donde:
Id es el identificador de la historia de usuario,
Título es el título descriptivo de la historia de usuario,
Descripción es la descripción sintetizada de la historia de usuario,
Estimación es la estimación de los puntos historia necesarios para desarrollar esa his-
toria,
Valor es dado por el cliente y, junto con el tiempo, determinará la prioridad de la
historia,
Dependencias en este apartado se indicarán los ids de las historias de las que depende
otra historia, y
Criterios de aceptación son las pruebas consensuadas entre el cliente y el desarrollador
y que el código debe superar para dar como finalizada la implementación de la historia.
3.2.5.4. ¿Qué son los Puntos Historia?

Un punto historia es la cantidad de esfuerzo que supone desarrollar una historia de usuario,
la complejidad de su desarrollo y el riesgo inherente [33].
A la hora de estimar con puntos historia se debe conocer el equipo que va a desarrollar la
historia, ya que el punto historia depende de quién o quienes trabajarán en ella.
Lo más recomendable es que el equipo de manera conjunta dé un número final de puntos
historia, en lugar de un sumatorio individual.
A la hora de calcular los puntos historia no existe una fórmula para calcular éstos. Cuando
hay que asignar los puntos historia a una historia de usuario lo importante es el valor de esa
historia respecto al resto. Una historia a la que se le asignan dos puntos historia debe requerir
31
el doble de esfuerzo de una a la que se le asigna un punto historia. Por esta razón los puntos
historia se asignan relativizando unas historias frente a otras [33].
Es importante recordar a los miembros del equipo que deben estimar el esfuerzo total y no
solo la parte en la que vayan a trabajar.
La secuencia de números utilizada para estimar no es lineal para evitar una falsa sensación
de precisión en cuanto a estimaciones de tiempo y poder realizar estimaciones más exactas.
Esta secuencia está compuesta por los siguientes números: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40 y
100.
3.2.5.5. Planning Poker

La técnica de Planning Poker fue creada en 2002 por James Grenning con el fin de mini-
mizar el tiempo de las estimaciones y evitar que no participe todo el equipo en la estimación
[17].
Se utiliza un mazo de cartas compuesto por 13 cartas de las cuales 11 están numeradas con
la secuencia de Fibonacci y las dos restantes son cartas especiales, una de ellas utilizada para
indicar la falta de información (?) y la otra para representar un descanso (taza de café).
El funcionamiento de esta técnica es el siguiente:
Las personas implicadas en la estimación toman un mazo de cartas. El propietario del pro-
ducto presenta las historias de usuario que se van a estimar, y hace una descripción de las
mismas. Después cada una de las personas implicadas elige una carta de su mazo que repre-
senta los puntos historia que le asigna a la historia presentada. Una vez que todos han elegido
su carta cada miembro muestra su carta al resto de compañeros, si existe una gran disper-
sión entre las estimaciones se vuelve a discutir la historia de usuario y se vuelve a realizar
el proceso de estimación. Finalmente, cuando los miembros hayan llegado a un consenso se
asignará el valor elegido a la historia de usuario.
3.3 Herramientas de estimación existentes en el mercado

Existen numerosas herramientas de estimación en el mercado a continuación, se describi-
rán algunas de ellas:
Orange Effort Estimation Tool: Es una herramienta que permite la estimación del
esfuerzo de desarrollo del software utilizando 5 métodos diferentes. Los métodos que
se utilizan son los siguientes: COCOMO II, desglose de trabajo, analogía, estimación
modular personalizada para web y móvil y por último método de estimación modular
personalizado.
KnowledgePLAN: Herramienta desarrollada por Software Productivity Research. Tie-
ne un alto nivel de integración con Microsoft Project y permite calcular los puntos
función ajustados.
32
Cost Xpert: Es una herramienta para la estimación de costes que integra varios mode-
los de estimación, entre ellos COCOMO II, Puntos función etc.
scrumDo: Permite gestionar las listas de tareas e historias de usuario y también dar
soporte a la estimación con Planning Poker.
Pango Scrum: Permite escribir, estimar y priorizar historias de usuario. Facilita en
gran medida la planificación de Sprints.
A continuación, se muestra una comparativa de las funcionalidades entre la herramienta

desarrollada y las descritas anteriormente. Como se puede observar a simple vista, la herra-
mienta desarrollada en este TFG es mucho más completa que las existentes en el mercado, las
cuales se centran normalmente en una técnica concreta de estimación y no están preparadas
para comparar entre los resultados de diferentes técnicas ni con lo imputado realmente.
Figura 3.2: Comparativa de herramientas similares
33
Capítulo 4
Método de trabajo
A lo largo de este capítulo se describe la metodología de trabajo utilizada durante el

desarrollo de este TFG. Además se explican las herramientas y tecnologías aplicadas
para el desarrollo de este TFG.
La metodología de trabajo elegida ha sido Scrum. Se ha elegido esta metodología debido
a que es una metodología ágil, y aporta grandes beneficios al proyecto como:
Utilización del modelo iterativo incremental, que permite introducir variaciones y nue-
vas peticiones por parte de los stakeholders.
Mayor cohesión entre los miembros del equipo debido a que son autorganizados y
multifuncionales.
Adecuado para equipos de trabajo pequeños.
4.1 Scrum
Scrum es un framework adaptable, iterativo, rápido, flexible y eficaz que está diseñado
para entregar valor al cliente durante todo el desarrollo del proyecto. El objetivo primor-
dial es satisfacer las necesidades del cliente a través de un entorno de transparencia en la
comunicación, responsabilidad colectiva y progreso continuo [21].
Un proyecto en Scrum se divide en iteraciones llamadas sprints. Los sprints suelen tener
una duración entre una semana y un mes. Durante la elicitación de requisitos se identifican
lo que denominamos historias de usuario, éstas explican la funcionalidad que se desea para
el sistema. En cada sprint estas historias de usuario se dividirán en tareas que llevarán al
cumplimiento de los objetivos fijados para ese sprint. Después de cada iteración se obtiene
un entregable completo y funcional que pueda ser entregado al cliente, consiguiendo así que
éste pueda observar la evolución del proyecto pudiendo detectar ideas nuevas o problemas
en el desarrollo.
35
4.1.1 Roles en Scrum
En Scrum distinguimos tres roles principales [39]:
Product Owner: Representa a todos los interesados en el producto. Es el responsable

de lograr el mayor valor de producto para los clientes, usuarios y resto de implicados.
El propietario del producto es la persona responsable de gestionar la pila del producto.
La gestión de la pila del producto incluye:
• Expresar de manera clara los elementos de la pila del producto.
• Optimizar el valor del trabajo que el Equipo de Desarrollo realiza.
• Asegurar que la pila del producto es visible, transparente y clara para todos, y
que refleja aquello en lo que el equipo trabajará a continuación.
• Asegurar que el equipo de desarrollo entiende los elementos de la pila del pro-
ducto al nivel necesario.
El product owner también será el encargado de definir los criterios de validación de las
historias de usuario y de aceptar o rechazar los resultados del trabajo obtenido tras la
finalización de un sprint.
Este rol será desempeñado por Mario Piattini Velthuis.
El equipo o Scrum Team: Es el responsable de transformar la pila del sprint en un
incremento de la funcionalidad del sistema. Es decir, son los encargados de desarrollar
el producto. Está formado por un número reducido de personas, normalmente entre 5
y 9 personas. Las tres características principales que debe tener un equipo son:
• Auto-gestionado: No hay un líder en el equipo todos son iguales.
• Auto-organizado: Cada miembro del equipo elige las tareas que va a realizar.
• Multifuncional: Cada miembro del equipo debe tener las habilidades necesarias
para realizar cualquier trabajo (análisis, diseño, pruebas, documentación, etc).
El Scrum team en este proyecto estará compuesto únicamente por María Pérez Iniesta,
autora de este documento.
Scrum Master: Es el responsable de asegurar que la metodología Scrum se entienda y
se adopte. Los Scrum Masters hacen esto asegurándose de que el Scrum Team trabaja
ajustándose a la teoría, prácticas y reglas de Scrum.
El Scrum Master es un líder que está al servicio del equipo de trabajo, y ayuda a
las personas externas al equipo de trabajo a entender qué interacciones con el equipo
pueden ser útiles y cuáles no. También ayuda a todos a modificar estas interacciones
para maximizar el valor creado por el equipo de trabajo.
Este rol será desempeñado por Moisés Rodríguez Monje.
36
4.1.2 Componentes de Scrum
Product Backlog (Pila del Producto): Lista de requisitos priorizada que a partir de
la visión inicial del producto crece y evoluciona durante el desarrollo. Contiene el
inventario de funcionalidades, mejoras, tecnología y correcciones de errores que deben
incorporarse al producto a través de las sucesivas iteraciones en el desarrollo. Está
desarrollada por el product owner.
Una pila del producto nunca está completa. El desarrollo más temprano de la misma
solo refleja los requisitos conocidos y mejor entendidos al principio. La pila del pro-
ducto evoluciona a medida que el producto y el entorno en el que se usará también
lo hagan. La pila del producto es dinámica; cambia constantemente para identificar lo
que el producto necesita para ser adecuado, competitivo y útil. Mientras el producto
exista, su pila del producto también existe [39].
Sprint Backlog (Pila del Sprint): Lista de trabajos que debe realizar el Scrum team
durante el sprint. Descompone las funcionalidades de la pila del producto en las tareas
necesarias para construir un incremento. Es realizada por el Scrum Team de forma
conjunta y solo éste la puede modificar durante la ejecución del sprint. La duración de
las tareas oscila en un rango de 2 a 16 horas.
Incremento: Parte del producto desarrollada en un sprint.
4.1.3 Reuniones en Scrum

Las reuniones que se desarrollan en Scrum son las siguientes:
Planificación del sprint: Jornada de trabajo previa al inicio de cada sprint en la que se
determina cuál va a ser el trabajo y los objetivos que se deben conseguir en la iteración.
Esta reunión consta de dos partes:
• Primera parte: Tiene una duración de entre 1 y 4 horas, en esta primera parte
se decide qué elementos de la pila del producto se van a desarrollar. El product
owner presenta las historias de usuario que tienen mayor prioridad en la pila del
producto y que cree que se pueden realizar en el sprint. El Scrum team realiza
preguntas para entender bien cada historia de usuario, y propone sugerencias y
modificaciones. En esta fase se define el “Objetivo del sprint“ o expresión que
sintetiza cuál es el valor que se le va a entregar al cliente.
• Segunda parte: Puede durar como máximo hasta el final de la jornada, en esta
segunda parte se decide que tareas se van a abordar. El Scrum team desglosa
cada historia de usuario en tareas y estima el tiempo de cada una formando así la
pila del sprint. El product owner resuelve las dudas del equipo y comprueba que
éste comprende el objetivo del sprint. El Scrum master actúa como moderador
en la reunión.
37
Los miembros del equipo eligen las tareas en función de sus conocimientos y
comprobando que hay una distribución homogénea del trabajo.
Reunión diaria: Revisión diaria donde cada miembro del equipo indica el trabajo que
realizó ayer, el trabajo que realizará hoy y cosas que puede necesitar o problemas que
le hayan surgido a la hora de desarrollar sus tareas. Tienen una duración máxima de
15 minutos.
Revisión del sprint: La revisión del sprint se lleva acabo al final de cada sprint, el
Scrum Team y el Product Owner se reúnen para ver el trabajo que se ha llevado a cabo
durante el sprint. Si fuera necesario se podría realizar una adaptación de la pila del
producto. Se puede medir el progreso mediante los gráficos Burn-up y Burn-down.
Retrospectiva del sprint: La retrospectiva ofrece una oportunidad al Scrum Team de
inspeccionarse a sí mismo y ver las posibles mejoras para el siguiente sprint. La retros-
pectiva del sprint tiene lugar después de la revisión del sprint y antes de la siguiente
planificación del sprint. Los principales puntos a tratar en esta reunión son los siguien-
tes:
• Que se hizo mal durante el sprint.
• Que se hizo bien durante el sprint.
• Que inconvenientes se encontraron, y han impedido progresar adecuadamente.
4.1.4 Aplicación de Scrum a este TFG

Como comentamos anteriormente, Scrum nos permite seguir la evolución del proyecto
pudiendo de esta manera solucionar problemas de manera temprana. Además, después de
cada iteración obtenemos un incremento con funcionalidad para el cliente.
Después de una reunión con los tutores del TFG se decidió utilizar Scrum debido a que
los ciclos ágiles son unos de los más utilizados en la actualidad y, además, ha sido estudiado
y utilizado en el grado. Otra de las razones por las que se decidió utilizar un ciclo de vida
iterativo e incremental fue que al principio el alcance no estaba cerrado y había que controlar
la evolución del proyecto periódicamente para reenfocar la solución.
El equipo de trabajo está formado por Mario Piattini Velthuis como Product Owner, Moi-
sés Rodríguez Monje como Scrum Master y María Pérez Iniesta como Scrum Team. Cabe
destacar que el Development Team suele estar compuesto por más de una persona, pero en
este caso está compuesto solo por una, lo que muestra una pequeña adaptación de Scrum en
este TFG.
También dentro de esta adaptación se prescindió de las reuniones diarias debido a que el
equipo está formado únicamente por una persona. Sustituyendo éstas por reuniones sema-
nales con el Scrum Master para ver posibles dudas o problemas en el desarrollo del proyec-
to.
38
Se llevó a cabo una reunión en la que se realizó la pila del producto de manera conjunta
con el Product Owner y el Scrum Master y se decidió que la duración de los sprints sería de
dos semanas de duración.
4.1.5 Sprints
El proyecto se realizará en siete sprints. En cada sprint se llevarán a cabo una serie de
historias que supondrán un incremento en el proyecto.
Número Estimación en
Historia de Usuario
de Sprint Semanas
0 Configuración inicial 2 semanas
Implementación modelo
1 2 semanas
Puntos función
2 2 semanas
COCOMO II
Implementación modelos
3 2 semanas
Ptos. Caso de uso y backfiring
4 2 semanas
Implementación imputación real
5 2 semanas
y gestión de la aplicación
Implementación de la comparativa y
6 2 semanas
exportación de estimaciones
Cuadro 4.1: Listado de las historias de usuario realizadas en cada sprint.
4.2 Kanban
Kanban es una técnica creada por Toyota, que se utiliza para controlar el avance del tra-
bajo, en el contexto de una línea de producción, sirviéndose de tableros o pizarras donde de
una manera visual se observa el estado de las tareas.
Kanban no es una técnica específica del desarrollo software, su objetivo es gestionar de
manera general como se van completando tareas, pero en los últimos años se ha utilizado en
la gestión de proyectos de desarrollo software, a menudo con Scrum [26].
Para este TFG se utilizará Kanban, con ayuda de la herramienta Trello. Trello es una he-
rramienta que utiliza tarjetas, que en nuestro caso se corresponderán con las historias de
usuario, estas historias pasarán por distintos estados, que en nuestro caso serán TO DO que
corresponde a las historias de usuario que están pendientes de realizarse, DOING que co-
rresponde a las historias de usuario que se están realizando y DONE que corresponde con
las historias de usuario que se han completado. Con esto podremos conseguir una visión de
cómo se encuentran las historias de usuario de nuestro proyecto.
39
4.3 Proceso Unificado de Desarrollo
El Proceso Unificado de Desarrollo (PUD) es un marco genérico de trabajo que puede
especializarse para una gran variedad de sistemas de software, para diferentes áreas de apli-
cación, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaños
de proyectos [35].
Para el desarrollo de este TFG se han utilizado técnicas del PUD como los diagramas de
casos de uso y los diagramas de clase, utilizados para realizar el análisis y el diseño de cada
sprint.
4.4 Marco tecnológico

4.4.1 Medios software
Sistemas operativos
• Windows 10 Home x64: Portátil.
Herramientas y tecnologías para el desarrollo software
• Lenguaje de Marcado para Hipertextos (HTML 5): Es la última versión de

HTML, Lenguaje de Marcado para Hipertextos, es el elemento de construcción
básico de una página web y se usa para crear y representar visualmente una pá-
gina web [13].
• CSS3: Lenguaje utilizado para definir la presentación de un documento estructu-
rado escrito en HTML o XML[15].
• Bootstrap: Es un framework 1 creado por Twitter, que permite crear interfaces
web con Hoja de estilo en cascada (CSS) y JavaScript (JS), cuya particularidad es
adaptar la interfaz del sitio web al tamaño del dispositivo en el que se visualiza
[2].
• JavaScript: Lenguaje de programación interpretado. Se utiliza principalmente
en su forma del lado del cliente, implementado como parte de un servidor web
permitiendo mejoras en la interfaz de usuario y páginas web dinámicas [16].
• jQuery: Es una biblioteca multiplataforma de JS, creada por John Resig, que
permite simplificar la manera de interactuar con los documentos Lenguaje de
Marcado para Hipertextos (HTML), manipular el árbol Modelo de Objetos del
Documento (DOM), manejar eventos, desarrollar animaciones y agregar interac-
ción con la técnica JavaScript asíncrono y XML (AJAX) a páginas web [24].
• java: Lenguaje de programación y una plataforma informática comercializada
por Sun Microsystems [27].
1
Framework es un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de pro-
blemática particular que sirve como referencia, para enfrentar y resolver nuevos problemas de índole similar.
40
• Spring: Es un framework para el desarrollo de aplicaciones y contenedor de in-
versión de control, de código abierto para la plataforma Java [3].
• Maven: Es una herramienta que se utiliza para construir y gestionar cualquier
proyecto, y sus dependencias, basado en Java [4].
Control de versiones
• Git: Es un sistema de control de versiones de código abierto [23].
• Bitbucket: Es un servicio de alojamiento basado en web, para los proyectos que
utilizan el sistema de control de versiones Mercurial y Git [5].
Modelado y documentación
• LATEX: Es un sistema de composición de textos, orientado a la creación de docu-
mentos escritos que presenten una alta calidad tipográfica [18].
• Visual Paradigm: Es una herramienta para desarrollo de aplicaciones utilizando
modelado UML, bajo licencia comunnity [6].
• GIMP: Es un programa de edición de imágenes digitales en forma de mapa de
bits, tanto dibujos como fotografías. Es un programa libre y gratuito [7].
• Balsamiq Mockups: Es una aplicación para crear maquetas para interfaces grá-
ficas para usuario. Le permite al diseñador diagramar widgets preconstruidos uti-
lizado un editor What you see is what you get (WYSIWYG) de drag and drop. La
aplicación se ofrece en versión para escritorio y como plug-in para Google Drive,
Confluence, JIRA, FogBugz y XWiki [8].
Entorno de desarrollo
• Eclipse Jee Oxygen: Es una plataforma de software compuesto por un conjunto
de herramientas de programación de código abierto multiplataforma para desa-
rrollar software [22].
Servidor de aplicaciones
• Apache Tomcat 8: Es una implementación de código abierto de las tecnologías
Java Servlet, JavaServe Pages, Java Expression Language y Java WebSocket [9].
Administración de base de datos

• MySQL: Es un sistema de gestión de bases de datos relacional [25].
• MySQL Workbench: Es una herramienta visual de diseño de bases de datos que
integra desarrollo de software, administración de base de datos, diseño de base de
datos, creación y mantenimiento para el sistema de base de datos MySQL [10].
41
Gestión del proyecto
• Trello: Gestor de proyectos online que permitirá gestionar tus rutinas de trabajo,
priorizar, generar avisos de citas y muchas otras opciones [28].
4.4.2 Medios hardware

Portátil: Ordenador portátil Acer E5-571PG-74SP con las siguientes características:
Procesador Intel(R) Core(TM) i7-4510U CPU @ 2.00GHz 2.60GHz.
8 GB RAM.
HD 1 TB.
42
Capítulo 5
Resultados
E l objetivo de este capítulo es presentar de manera detallada los resultados obtenidos

tras aplicar la metodología descrita en el capítulo anterior. El capítulo se encuentra
estructurado por los sprints que se han realizado y los resultados obtenidos en cada uno de
ellos.
5.1 Definición del proyecto

En la fase inicial de definición del proyecto se han detallado las características de la he-
rramienta y de qué manera se han obtenido sus sprints.
Lo primero que se hizo fue tener una reunión para definir el alcance del proyecto, esto
facilitó la posterior obtención de los requisitos. Para ello se realizaron una serie de entrevistas
con Moisés Rodríguez Monje (Scrum Master) y Mario Piattini Velthuis (Product Owner).
Se definieron distintos tipos de reuniones para el seguimiento del proyecto:
Revisión del Sprint: Esta reunión se realizará al finalizar cada sprint, en ella se mos-
trará al Product Owner y al Scrum Master el trabajo desarrollado durante el sprint,
realizando una demo para ver los avances de la herramienta.
Reunión Semanal: Esta reunión sustituye a la reunión diaria utilizada comúnmente
en Scrum. En ella el equipo podrá resolver dudas y problemas que surjan durante el
desarrollo del proyecto con la ayuda del Scrum Master.
Cabe destacar que en cada sprint se han realizado las fases de análisis de la historia, diseño,
construcción y pruebas.
A continuación, se incluyen los 7 sprints incluyendo en cada uno la pila del sprint, el
análisis de las historia global para detallar las historias, el diseño de la historia, la imple-
mentación de la historia global, las pruebas realizadas y las reuniones realizadas durante el
sprint.
43
5.2 Sprint 0
El sprint 0 se compone de 4 tareas. En este sprint se ha realizado principalmente la docu-
mentación y análisis necesarios para comenzar el proyecto, que resultaron en el anteproyecto
de este TFG, la lista de historias de usuario y la planificación de los sprints que forman este
proyecto.
Para realizar este sprint se convocaron varias reuniones con Moisés y Mario.
5.2.1 Pila del Sprint

En la tabla 5.1 muestra un resumen de este sprint, con la duración estimada y la duración
real, mostrando las historias de usuario involucradas, y las tareas.
Sprint
Número de Sprint: 0
Duración estimada: 2 Semanas Duración real: 2 semanas
Historia de Usuario: 1
Tareas:
1. Alcance del Proyecto.
2. Captura de requisitos.
3. Elaboración del anteproyecto de este TFG.
4. Planificación del proyecto.
Cuadro 5.1: Sprint 0
5.2.2 Desarrollo del Sprint

En este sprint se realizaron las tareas previas e iniciales del proyecto, para garantizar su
correcto desarrollo.
5.2.2.1. Definición del alcance del proyecto

En esta primera tarea se han realizado varias reuniones con Moisés (Scrum Master) y
Mario (Product Owner), para definir y entender cuál es el alcance completo del proyecto.
Tras las reuniones realizadas el alcance definido fue la creación de una herramienta para la
estimación de proyectos software pudiendo estimar éstos desde un punto de vista tradicional
con una gestión predictiva, y desde un punto de vista ágil con una gestión adaptativa. Los
modelos elegidos han sido Puntos Función, Puntos Casos de Uso, COCOMO II y Backfiring
para la parte de gestión predictiva, e Historias de Usuario para la parte de gestión adaptativa.
Las estimaciones realizadas se podrán modificar y eliminar, exportar los resultados obtenidos
en formato Excel, también se podrá realizar la imputación real de los resultados, y por último
se podrán comparar las estimaciones realizadas en función del esfuerzo estimado-esfuerzo
real y coste estimado-coste real, obteniendo un gráfico con la comparativa.
44
5.2.2.2. Captura de requisitos
En esta segunda tarea se ha realizado la captura de requisitos, de la cual se han obtenido
las historias de usuario.
En el Anexo A se muestran las tablas que incluyen las 32 historias de usuario obtenidas
en la captura de los requisitos, incluyendo su nombre, el valor de negocio para la empresa,
el esfuerzo estimado en cada una de ellas, la descripción y las dependencias.
El valor de negocio puede tener un valor máximo de 100, éste ha sido asignado por el
Scrum Master.
A continuación en la tabla 5.2, se muestra un resumen de las 32 historias de usuario, con
el valor de negocio, el esfuerzo y el sprint al que pertenecen.
Valor de
Historia de
Sprint Epic No Esfuerzo
Usuario
negocio
Insertar datos
2 60 2 días
generales
Insertar
3 80 4 días
Funcionalidad
Estimación Puntos
2 Insertar
Función 4 80 1 día
ILF
Insertar
5 80 1 día
ELF
Insertar
6 80 1 día
EI
Insertar
7 80 1 día
EO
Insertar
8 80 1 día
EQ
Visualizar
9 90 3 días
resultados
Insertar datos
10 60 1 día
Estimación generales
3
COCOMO II Insertar
11 85 10 días
módulo
Visualizar
12 90 3 días
resultados
45
Valor de
o Historia de
Sprint Epic N Esfuerzo
Usuario
negocio
Insertar datos
13 60 1 día
Estimación Puntos generales
Casos de Uso Insertar actores
14 80 3 días
4 y Casos de uso
Visualizar
15 90 4 días
resultados
Insertar datos
16 60 1 día
Backfiring Transformar
17 líneas de 80 1 día
código
Visualizar
18 90 3 días
resultados
Insertar datos
19 60 1 día
5 Historias de Insertar
20 80 4 días
Usuario historias
Estimar
21 90 6 días
historias
Visualizar
22 90 3 días
resultados
29 Registrarse 70 1 día
Gestión de Acceso a
30 70 1 día
la aplicación la aplicación
31 Cerrar sesión 70 0,5 días
6
Modificar
32 75 1 día
Perfil
Filtrar
23 80 4 días
estimaciones
Gestión de las
Modificar
estimaciones 24 80 4 días
estimaciones
Eliminar
25 80 0,5 días
estimación
Imputar
27 85 0,5 días
estimación
Exportar
Gestión de las 26 85 8 días
7 estimación
estimaciones
Comparar
28 85 6 días
estimaciones
Cuadro 5.2: Resumen historias de Usuario
46
5.2.2.3. Elaboración del anteproyecto
Una vez realizadas las tareas anteriores, se procedió a redactar el anteproyecto de este
Trabajo Fin de Grado.
5.2.2.4. Plan del proyecto

A partir de las historias de usuario anteriormente descritas se elaboró un plan de proyecto
(véase tabla 5.3), el cual se divide en 6 sprints, cada uno de ellos con una serie de historias y
una duración determinada.
Historias de Duración del
Sprint Resultado del Sprint
usuario Sprint
Realizar estimaciones con el modelo Puntos
1. Puntos Función 2, 3, 4, 5, 6,7, 8, 9 2 semanas
Función.
Realizar estimaciones con el modelo
2. COCOMO II 10, 11, 12 2 semanas
COCOMO II.
3. Puntos Casos de Uso 13, 14, 15 Realizar estimaciones con el modelo
2 semanas
y Backfiring 16, 17, 18 Puntos Casos de Uso y Backfiring.
Realizar estimaciones de
4. Historias de Usuario 19, 20, 21, 22 2 semanas
5. Gestión de la aplicación 23, 24, 25, 27 Acceso y registro al sistema, gestión de la cuenta.
2 semanas
y Usuarios 29,30, 31, 32 Filtrar, modificar, eliminar e imputar estimaciones.
Exportar estimaciones y comparar
6. Gestión de la aplicación 26, 28 2 semanas
estimaciones.
Cuadro 5.3: Plan de Proyecto
5.2.3 Reunión semanal

Se han realizado reuniones diarias con Moisés (Director de este TFG), en las que se resol-
vían dudas y problemas que podían surgir durante este sprint, además de realizar un segui-
miento de cómo se encontraba el proyecto en ese momento.
5.2.4 Revisión del Sprint

Se ha realizado una reunión al final del sprint con Moisés y Mario para mostrar el trabajo
realizado, y que éstos dieran el visto bueno a los avances.
5.2.5 Retrospectiva del Sprint

Este sprint es el más importante, ya que se obtienen documentos necesarios para un co-
rrecto desarrollo. Además, nos servirán para planificar correctamente los sprint y las tareas
que se realizarán en cada uno de ellos.
47
5.3 Sprint 1
En el sprint 1 se abordarán las historias necesarias para llevar a cabo la implementación
del modelo Puntos Función. Básicamente estas historias consistirán en realizar los cálculos
necesarios para obtener los puntos función.
5.3.1 Refinamiento de la Pila del Producto

En este sprint la Pila del Producto no ha sido modificada.
5.3.2 Planificación del Sprint

En este sprint tenemos la historia 2 (Insertar datos generales), la historia 3 (Insertar funcio-
nalidad), la historia 4 (Insertar ILF), la historia 5 (Insertar ELF), la historia 6 (Insertar EI), la
historia 7 (Insertar EO), la historia 8 (Insertar EO) y la historia 9 (Visualizar resultados).
La historia 2 consiste en insertar los datos generales de la estimación que en este caso se
corresponden con la empresa, el proyecto, la fecha, el ciclo de vida utilizado, las caracterís-
ticas del sistema, la tecnología utilizada para desarrollar el proyecto que se va a estimar, la
descripción del proyecto, el coste por persona que desarrolla el proyecto y si el proyecto ya
está imputado. La duración estimada para esta historia es de 2 días.
La historia 3 consiste en insertar las funcionalidades que tendrá el proyecto que se va a
estimar. La duración estimada para esta historia es de 4 días.
La historia 4 consiste en insertar los archivos lógicos internos que van a tener las funcio-
nalidades del proyecto. La duración estimada para esta historia es de 1 día.
La historia 5 consiste en insertar los archivos lógicos externos que van a tener las funcio-
nalidades del proyecto. La duración estimada para esta historia es de 1 día.
La historia 6 consiste en insertar las entradas externas que van a tener las funcionalidades
del proyecto. La duración estimada para esta historia es de 1 día.
La historia 7 consiste en insertar las salidas externas que van a tener las funcionalidades
La historia 8 consiste en insertar las consultas externar que van a tener las funcionalidades
La historia 9 consiste en visualizar los resultados obtenidos, que en este caso son los puntos
función sin ajustar, los puntos función ajustados, el esfuerzo, el coste y las distribuciones por
fase del ciclo de vida del esfuerzo y el coste. La duración estimada para esta historia es de 3
días.
48
5.3.3 Desarrollo del sprint
5.3.3.1. Análisis de la historia global
La historia global Realizar estimación con Puntos Función se ha descompuesto en las his-
torias de usuario citadas anteriormente. Esta historia se corresponde con el requisito funcio-
nal Elaborar estimación con Puntos función. Que se corresponde con el caso de uso Insertar
estimación Puntos Función (véase figura 5.1).
Figura 5.1: Caso de uso Insertar estimación Puntos Función
5.3.3.2. Diseño de la historia global

Una vez realizado el análisis de la historia de usuario, se creó el diagrama de clases de
diseño que se muestra en la figura 5.2:
Figura 5.2: Diagrama de clases Puntos Función
En el diagrama de clases de la figura 5.2 se definen las siguientes clases:

Puntos_funcion almacena todos los datos generales de la estimación,
funcionalidades_puntos_funcion almacena los datos de las funcionalidades asociadas
a la estimación,
49
pf_ilf almacena los datos de los archivos lógicos internos,
pf_elf almacena los datos de los archivos lógicos externos,
pf_ei almacena los datos de las entradas externas,
pf_eo almacena los datos de las salidas externas,
pf_eq almacena los datos de las consultas externas,
pf_funcion_ajustados alamacena los valores de los 14 factores de ajuste, y
resultados_puntos_funcion almacena los resultados de la estimación.
En la figura 5.3 se muestran las distintas tablas de la base de datos asociadas al módulo
de la estimación con puntos función. Para obtener dichas entidades en el diagrama entidad
relación se ha decidido implementar el patrón una clase-una tabla.
Figura 5.3: Diagrama entidad relación Puntos Función
50
5.3.3.3. Implementación
Por cuestiones de confidencialidad relacionadas con la empresa en el marco de la cual se
ha desarrollado este TFG, no se mostrará el código desarrollado para este sprint. Por ello se
mostrará una imagen del resultado final de cada historia de usuario.
Historia de Usuario 2
Para implementarlo se ha utilizado la clase puntos_funcion que podíamos ver en el
diagrama de clases de la figura 5.2. Como se puede observar en la figura 5.4 se recogen
los datos generales de la estimación.
Figura 5.4: Introducir datos generales Puntos función
Para implementarlo se ha utilizado la clase funcionalidades_puntos_funcion que po-
díamos ver en el diagrama de clases de la figura 5.2. Como se puede observar en
la figura 5.5 se introducen y muestran las funcionalidades de la estimación. Con sus
respectivos ILF, ELF, EI, EO y EQ y también los puntos función sin ajustar para esa
funcionalidad.
Figura 5.5: Funcionalidades Puntos Función
51
Para implementarlo se ha utilizado la clase pf_ilf que podíamos ver en el diagrama de
clases de la figura 5.2. Como se puede observar en la figura 5.6 se introducen los det
y los ret calculados y obtenemos la complejidad y el número de puntos función sin
ajustar equivalentes a esa complejidad.
Figura 5.6: Archivos lógicos internos (ILF)
Para implementarlo se ha utilizado la clase pf_elf que podíamos ver en el diagrama
de clases de la figura 5.2. Como se puede observar en la figura 5.7 se introducen los
det y los ret calculados y obtenemos la complejidad y el número de puntos función sin
Figura 5.7: Archivos lógicos externos (ELF)
52
Para implementarlo se ha utilizado la clase pf_ei que podíamos ver en el diagrama de
clases de la figura 5.2. Como se puede observar en la figura 5.8 se introducen los det
y los ftr calculados y obtenemos la complejidad y el número de puntos función sin
Figura 5.8: Entradas externas (EI)
Para implementarlo se ha utilizado la clase pf_eo que podíamos ver en el diagrama
det y los ftr calculados y obtenemos la complejidad y el número de puntos función sin
Figura 5.9: Salidas externas (EO)
Para implementarlo se ha utilizado la clase pf_eq que podíamos ver en el diagrama
det y los ftr calculados y obtenemos la complejidad y el número de puntos función sin
53
Figura 5.10: Consultas externas (EQ)
Para implementarlo se han utilizado las clases puntos_funcion_ajustados y resulta-
dos_puntos_funcion que podíamos ver en el diagrama de clases de la figura 5.2. En
la figura 5.11 se muestran los 14 factores de influencia que se utilizan para ajustar los
puntos función sin ajustar y obtener los puntos función ajustados. En la figura 5.12 y
la figura 5.13 se muestran los resultados finales estimados.
Figura 5.11: Pestaña Factores de Influencia
54
Figura 5.12: Resultados Puntos función
Figura 5.13: Resultados distribuciones Puntos función
5.3.3.4. Pruebas
En este apartado se van a realizar pruebas funcionales al sistema, utilizando una plantilla
tomada como referencia del estándar ISO/IEC 29119-3: Software and systems engineering -
Software testing [29].
55
Identificador 01
Historia asociada 02
Nombre Introducir datos generales
Comprobar que los datos generales de
Objetivo
la estimación se introducen correctamente.
Se introducen los datos correctamente y se
Resultado Esperado
recarga la página con los datos introducidos.
Resultado Obtenido recarga la página mostrando los datos que se
han introducido
Resultado de la ejecución
Éxito
de la prueba
Cuadro 5.4: Prueba 1 de la Historia de Usuario 2
Identificador 02
Nombre Inserción incorrecta de los datos generales.
Comprobar que los datos no se introducen cuando dejas
Objetivo
algún campo obligatorio vacío.
La aplicación muestre en el campo que está vacío el
Resultado Esperado
mensaje “Complete este campo".
La aplicación muestra el mensaje “Complete este campo"
Resultado Obtenido
junto al campo vacío.
Éxito
de la prueba
Identificador 03
Nombre Introducir Funcionalidad
Comprobar que las funcionalidades de la
Objetivo
estimación se realizan correctamente.
Se introducen las funcionalidades y se muestran
Resultado Esperado los ifl, elf, ei, eo, eq y puntos función sin ajustar
correctamente.
Se introducen las funcionalidades mostrando los
Resultado Obtenido ilf, elf, ei, eo, eq y puntos función sin ajustar de
manera correcta.
Éxito
de la prueba
56
Identificador 04
Nombre Inserción incorrecta de las funcionalidades.
Comprobar que no se pueden introducir funcionalidades
Objetivo
sin insertar un nombre y descripción.
La aplicación muestre el mensaje "Por favor introduzca
Resultado Esperado
el nombre y la descripción".
La aplicación muestra el mensaje "Por favor introduzca
Resultado Obtenido
el nombre y la descripción".
Éxito
de la prueba
Identificador 05
Nombre Introducir archivos lógicos internos
Objetivo Comprobar que los ilf se calculan correctamente.
Se calcula la complejidad y los puntos función sin
Resultado Esperado
ajustar del ilf.
La herramienta muestra la complejidad y los puntos
Resultado Obtenido
función sin ajustar del ilf.
Éxito
de la prueba
Identificador 06
Nombre Inserción incorrecta los archivos lógicos internos.
Comprobar que no se pueden introducir ILFs
Objetivo
sin insertar los datos obligatorios.
La aplicación muestre el mensaje "Por favor introduzca
Resultado Esperado
los campos vacíos".
La aplicación muestra el mensaje "Por favor introduzca
Resultado Obtenido
los campos vacíos".
Éxito
de la prueba
57
Identificador 07
Nombre Modificar archivos lógicos internos
Objetivo Comprobar que los ilf se modifican correctamente.
Se modifica la complejidad y los puntos función sin
Resultado Esperado
ajustar del ilf.
La herramienta modifica la complejidad y los puntos
Resultado Obtenido
función sin ajustar del ilf.
Éxito
de la prueba
Cuadro 5.10: Prueba 3 Historia de Usuario 4
Identificador 08
Nombre Modificación incorrecta de los archivos lógicos internos.
Comprobar que no se pueden modificar los ILFs con
Objetivo
datos incorrectos.
La aplicación muestre el mensaje "No se ha podido
Resultado Esperado
insertar el ilf".
La aplicación muestra el mensaje "No se ha podido
Resultado Obtenido
insertar el ilf".
Éxito
de la prueba
Identificador 09
Nombre Eliminar archivos lógicos internos
Objetivo Comprobar que los ilf se eliminan correctamente.
Resultado Esperado Se elimina el ifl y desaparece de la lista de ilfs.
La herramienta elimina el ilf y desaparece de la
Resultado Obtenido
lista de ilfs.
Éxito
de la prueba
58
Para no alargar mucho el apartado de las pruebas omitiremos las pruebas realizadas a los
ELF, EI, EO y EQ, ya que son iguales que las realizadas a los ILF.
Identificador 10
Nombre Visualizar resultados.
Objetivo Comprobar que los resultados se calculan correctamente.
Cuando se eligen los 14 factores de influencia y los guardas
Resultado Esperado
se cierra el modal y aparecen automáticamente los resultados.
Cuando se han elegido los 14 factores de influencia y los hemos
Resultado Obtenido guardado se ha cerrado el modal y han aparecido los resultados
calculados automáticamente.
Éxito
de la prueba
5.3.4 Reunión Semanal

Se han realizado reuniones con Moisés Rodríguez (Scrum Master) en las que se planteaban
problemas y dudas que surgían durante el sprint, además de realizar un seguimiento de cómo
se encontraba el proyecto en ese momento

Tras finalizar las dos semanas de sprint se realizó una reunión con el Product Owner y el
Scrum Master en la que en la primera parte el podruct owner revisó las historias y en función
de los criterios de aceptación dijo que historias estaban completadas y que historias se tenía
que pasar al segundo sprint. Todas las historias fueron aceptadas.

El sprint ha finalizado con la realización de todas las historias asignadas a éste y sin ningún
incidente y cumpliendo la planificación estimada.
59
5.4 Sprint 2
del modelo COCOMO II. Básicamente estas historias consistirán en realizar los cálculos
necesarios para obtener los resultados.

5.4.2 Planificación del sprint

En este sprint se ha decidido abordar la historia 10 (insertar datos generales COCOMO
II), la historia 11 (Insertar módulos COCOMO II) y la historia 12 (visualizar resultados
COCOMO II).
corresponden con la empresa, la fecha, el proyecto, el ciclo de vida utilizado, la descripción
del proyecto y si el proyecto ya está imputado. Esta historia se ha estimado con una duración
de 1 día.
La historia 11 consiste en insertar los módulos que tendrá el proyecto. Los módulos están
compuestos por un tamaño, el precio que cobra una persona que desarrolla el módulo al mes,
el factor del ajuste del esfuerzo, el lenguaje, el esfuerzo nominal, el esfuerzo ajustado, la
productividad, el coste para ese módulo, el coste por instrucción y el personal necesario para
desarrollarlo. Esta historia se ha estimado con una duración de 10 días.
La historia 12 consiste en visualizar los resultados obtenidos, que en este caso son el es-
fuerzo, la duración, la productividad, el coste, el coste por instrucción y el personal necesario
para desarrollar el proyecto completo. Además, se calculan estos resultados citados anterior-
mente desde un punto de vista optimista y un punto de vista pesimista. Esta historia se ha
estimado con una duración de 3 días.

La historia global Realizar estimación con COCOMO II se ha descompuesto en las histo-
rias de usuario citadas anteriormente. Esta historia corresponde con el requisito del funcional
Elaborar estimación con COCOMO II. Que se corresponde con el caso de uso Insertar esti-
mación COCOMO II (véase figura 5.14).
60
Figura 5.14: Caso de uso Insertar estimación COCOMO II

Una vez realizado el análisis de la historia de usuario, se creó el diagrama de clases de
diseño que se muestra en la figura 5.15:
Figura 5.15: Diagrama de Clases COCOMO II

cocomo almacena los datos generales de la estimación y además almacena los valores
de los 5 factores de escala de la estimación,
modulo_cocomo almacena los datos de los módulos asociados a la estimación,
puntos_funcion_cocomo almacena los valores de los archivos, interfaces, entradas,
salidas y consultas del módulo para poder realizar la transformación de puntos función
a líneas de código,
eaf almacena los factores de ajuste del módulo, y
61
resultados_cocomo almacena los resultados de la estimación.
En la figura 5.16 se muestran las distintas tablas de la base de datos asociadas al módulo
de la estimación con COCOMO II. Para obtener dichas entidades en el diagrama entidad
Figura 5.16: Diagrama entidad relación COCOMO II
Para implementarlo se ha utilizado la clase cocomo que podíamos ver en el diagrama
de clases de la figura 5.15. Como se puede observar en la figura 5.17 se recogen los
datos generales de la estimación.
62
Figura 5.17: Introducir datos generales COCOMO II
Para implementarla se ha utilizado la clase modulo_cocomo, eaf y puntos_funcion_-
cocomo que podíamos ver en el diagrama de clases de la figura 5.15. En la figura 5.18
podemos observar el valor de la planificación para el proyecto.
Figura 5.18: Planificación
En la figura 5.19 se observan los 5 factores de escala que le aplicamos al proyecto.
63
Figura 5.19: Factores de escala
Y por último en la figura 5.20 se puede observar los módulos de la estimación.
Figura 5.20: Introducir módulos COCOMO
Para implementarlo se ha utilizado la clase resultados_cocomo que pódiamos ver en
el diagrama de clases de la figura 5.15. En la figura 5.21 se muestran los resultados
optimistas, los probables y los pesimistas. Para obtener el pesimista y el optimista se
ha aplicado un 20 % a los resultados probables.
64
Figura 5.21: Resultados COCOMO II
5.4.3.4. Pruebas
tomada como referencia del estándar ISO/IEC 29119-3: Software and systems engineering -
Identificador 11
Comprobar que los datos generales de la estimación
Objetivo
se introducen correctamente.
Se introducen los datos correctamente y se recarga
Resultado Esperado
la página mostrando los datos introducidos.
Se introducen los datos correctamente y se recarga
Resultado Obtenido
la página mostrando los datos introducidos.
Éxito
de la prueba
65
Identificador 12
Nombre Inserción incorrecta de los datos generales
Comprobar que los datos no se introducen cuando
Objetivo
dejas algún campo obligatorio vacío.
La aplicación muestra en el campo que está
Resultado Esperado
vacío el mensaje “Complete este campo".
Resultado Obtenido
Éxito
de la prueba
Identificador 13
Nombre Introducir módulo
Comprobar que los módulos se insertan
Objetivo
correctamente.
La aplicación introduce el módulo y lo
Resultado Esperado
muestra.
La aplicación introduce el módulo y lo
Resultado Obtenido
muestra.
Éxito
de la prueba
Identificador 14
Nombre Inserción incorrecta de los módulos.
Comprobar que los módulos no se insertan
Objetivo
sin insertar un nombre y descripción.
La aplicación muestra el mensaje: "Por favor
Resultado Esperado
introduzca el nombre y la descripción".
La aplicación muestra el mensaje: "Por favor
Resultado Obtenido
introduzca el nombre y la descripción".
Éxito
de la prueba
66
Identificador 15
Nombre Inserción incorrecta de los módulos.
Comprobar que los módulos no se insertan
Objetivo
si tiene vacío algún campo obligatorio.
La aplicación muestra en el campo vacío el
Resultado Esperado
mensaje “Complete el campo".
La aplicación muestra en el campo vacío el
Resultado Obtenido
mensaje “Complete el campo".
Éxito
de la prueba
Cuadro 5.18: Prueba 3 de la historia de usuario 11
Identificador 16
Comprobar que los resultados se calculan
Objetivo
correctamente.
Cuando se pasa a la pestaña resultados los
Resultado Esperado valores para cada campo se muestran auto-
máticamente.
Cuando se pasa a la pestaña resultados los
Resultado Obtenido valores para cada campo se muestran auto-
máticamente.
Éxito
de la prueba
Cuadro 5.19: Prueba 1 de Historia de Usuario 12

se encontraba el proyecto en ese momento.

Tras finalizar las dos semanas de SPRINT se realizó una reunión con el Product Owner
y el Scrum Master. Se hizo una demo en la que se mostraban los avances realizados en el
sprint y el Product Owner en función de los criterios de aceptación de cada historia decidió
cuales estaban completadas y cuales tenían que pasar al tercer sprint. Todas las tareas fueron
aceptadas.
67
5.5 Sprint 3
de los modelos Puntos Casos de Uso y Backfiring. Básicamente estas historias consistirán en
realizar los cálculos necesarios para obtener los Puntos Casos de Uso ajustados en caso del
modelo Puntos Casos de Uso, y los Puntos Función ajustados en caso del modelo Backfiring.
Además del esfuerzo y del coste.

En este Sprint la Pila del Producto no ha sido modificada.

En este sprint se ha decidido abordar la historia 13 (insertar datos generales Puntos Casos
de Uso), la historia 14 (insertar actores y casos de uso), la historia 15 (visualizar resultados
Puntos Casos de Uso), la historia 16 (insertar datos generales Backfiring), la historia 17
(transformar las líneas de código) y la historia 18 (visualizar resultados Backfiring).
La historia 13 consiste en insertar los datos generales de la estimación que en este caso
se corresponden con la empresa, el proyecto, la fecha, el ciclo de vida, el factor de produc-
tividad, el número de desarrolladores, la tecnología, el precio por hora del desarrollador, la
descripción y si el proyecto está imputado. Esta historia se ha estimado con una duración de
1 día.
La historia 14 consiste en calcular el factor de peso de los actores que interactúan con el
proyecto sin ajustar y el factor de peso de los casos de uso sin ajustar. Para ello tenemos
que introducir el número de actores y de casos de uso que hay de cada tipo establecido. Esta
historia se ha estimado con una duración de 3 días.
La historia 15 consiste en visualizar los resultados obtenidos, que en este caso son los
puntos casos de Uso sin ajustar, los puntos casos de uso ajustados, el esfuerzo, el coste,
las horas estimadas para cada fase del proyecto y las jornadas estimadas para cada fase del
proyecto. Esta historia se ha estimado con una duración de 4 días.
La historia 16 consiste en insertar los datos generales de la estimación que en este caso
se corresponden con la empresa, el proyecto, la fecha, el ciclo de vida, las características
del sistema, la descripción, el coste medio por hora del desarrollador y si la estimación está
imputada. Esta historia se ha estimado con una duración de 1 día.
La historia 17 consiste en introducir las líneas de código que se tienen de cada lenguaje
68
utilizado para la implementación del proyecto y convertirlas a puntos función ajustados. Esta
historia se ha estimado con una duración de 1 día.
La historia 18 consiste en visualizar los resultados obtenidos, que en este caso son los
puntos función ajustados, el esfuerzo, el coste y las distribuciones por fase de ciclo de vida
del esfuerzo y coste. Esta historia se ha estimado con una duración de 3 días.

La historia global Realizar estimación con Puntos Casos de Uso se ha descompuesto en
las historias 13, 14 y 15 citadas anteriormente. Esta historia se corresponde con el requisito
funcional Elaborar estimación con Puntos Casos de Uso. Que se corresponde con el caso de
uso Insertar estimación Puntos Casos de Uso (véase figura 5.22).
Figura 5.22: Caso de uso Insertar estimación Puntos Casos de Uso
La historia global Realizar estimación con Backfiring se ha descompuesto en las historias

16,17 y 18 citadas anteriormente. Esta historia se corresponde con el requisito funcional Ela-
borar estimación con Backfiring. Que se corresponde con el caso de uso Insertar estimación
Backfiring (véase figura 5.23).
Figura 5.23: Caso de uso insertar estimación Backfiring
69
Una vez que se ha realizado el análisis de las historias de usuario, se crearon los diagramas
de clases de diseño que se muestran en las figuras 5.24 y 5.25:
Figura 5.24: Diagrama de clases Puntos Casos de Uso

puntos_casos_uso almacena los datos generales de la estimación,
ptos_cuso_sin_ajustar almacena los pesos y el número de actores y de casos de uso,
factores_entorno almacena los 8 factores de entorno,
factores_tecnicos almacena los 13 factores técnicos, y
resultados_ptos_casos_uso almacena los resultados de la estimación.
70
Figura 5.25: Diagrama de clases Backfiring

backfiring almacena los datos generales de la estimación,
backfiring_transformacion almacena el lenguaje, las líneas de código de cada lenguaje
y la equivalencia de éstas en puntos función, y
backfiring_resultados almacena los resultados de la estimación.
En la figura 5.26 y 5.27 se muestran las distintas tablas de la base de datos asociadas
a los módulos de estimación Puntos Casos de Uso y de Backfiring. Para obtener dichas
entidades en el diagrama entidad relación se ha decidido implementar el patrón de una clase-
una tabla.
Figura 5.26: Diagrama entidad relación Puntos Casos de Uso
71
Figura 5.27: Diagrama entidad relación Backfiring
Para implementarla se ha utilizado la clase puntos_casos_uso que podíamos ver en
el diagrama de clases de la figura 5.24. Como se puede observar en la figura 5.28 se
recogen los datos generales de la estimación.
72
Figura 5.28: Introducir datos generales Puntos Casos de Uso
Para implementarla se ha utilizado la clase ptos_cuso_sin_ajustar que podíamos ver en
el diagrama de clases de la figura 5.24. Como se puede observar en la figura 5.29 se
recogen el número de actores y de casos de uso de cada tipo.
Figura 5.29: Cálculo de los actores y los casos de uso
73
Para implementarla se han utilizado las clases resultados_ptos_casos_uso, factores_-
tecnicos y factores_entorno que podíamos observar en el diagrama de clases de la
figura 5.24. En la figura 5.30 se muestran los 13 factores técnicos que junto con los
factores de entorno nos permiten calcular los puntos casos de uso ajustados. En la
figura 5.31 se muestran los 8 factores de entorno, y en la figura 5.32 se muestran los
resultados finales estimados.
Figura 5.30: Factores técnicos
Figura 5.31: Factores de entorno
74
Figura 5.32: Resultados Puntos Casos de uso
Para implementarla se ha utilizado la clase backfiring que podíamos ver en el diagrama
de clases de la figura 5.25. Como se puede observar en la figura 5.33 se recogen los
Figura 5.33: Introducir datos generales Backfiring
75
Para implementarla se ha utilizado la clase backfiring_transformacion que podíamos
ver en el diagrama de clases de la figura 5.25. En la figura 5.34 se introducen las líneas
de código de cada lenguaje y se transforman en puntos casos de uso.
Figura 5.34: Transformar líneas de código en puntos función
Para implementarla se ha utilizado la clase backfiring_resultados que podíamos ver
en el diagrama de clases de la figura 5.25. En las figuras 5.35 y 5.36 se muestran los
resultados estimados finales.
Figura 5.35: Resultados Backfiring
76
Figura 5.36: Resultados Distribuciones Backfiring
5.5.3.4. Pruebas
tomada como referencia del estándar ISO/IEC 29119-3: Software and Systems engineering-
Identificador 17
Nombre Introducir datos generales.
Comprobar que los datos generales de la
Objetivo
estimación se introducen correctamente.
Resultado Esperado
Resultado Obtenido
Éxito
de la prueba
77
Identificador 18
Nombre Inserción incorrecta datos generales.
Comprobar que los datos no se insertan
Objetivo
cuando dejas algún campo obligatorio vacío.
Resultado Esperado
Resultado Obtenido
Éxito
de la prueba
Identificador 19
Nombre Cálculo de los actores sin ajustar.
Comprobar que el factor de peso de los actores
Objetivo
sin ajustar se calcula correctamente.
La aplicación muestra el peso de los actores sin
Resultado Esperado
ajustar total.
La aplicación muestra el peso de los actores sin
Resultado Obtenido
ajustar total.
Éxito
de la prueba
Identificador 20
Nombre Cálculo de los casos de uso sin ajustar.
Comprobar que el factor de peso de los casos de
Objetivo
uso sin ajustar se calcula correctamente.
La aplicación muestra el peso de los casos de uso
Resultado Esperado
sin ajustar total.
La aplicación muestra el peso de los casos de uso
Resultado Obtenido
sin ajustar total.
Éxito
de la prueba
78
Identificador 21
Nombre Cálculo incorrecto de los casos de uso sin ajustar.
Comprobar que cuando metes una letra en alguna
Objetivo
de las opciones no da error.
Resultado Esperado La aplicación deja vacío el campo.
Resultado Obtenido La aplicación deja vacío el campo.
Éxito
de la prueba
Cuadro 5.24: Prueba 3 de la historia de Usuario 14
Identificador 22
Comprobar que los resultados se calculan corre-
Nombre
ctamente.
Una vez elegidos los factores de entorno y los
Objetivo factores técnicos se calculan automáticamente
los resultados.
Resultado Esperado Aparecen los resultados automáticamente.
Resultado Obtenido Aparecen los resultados automáticamente.
Éxito
de la prueba
Identificador 23
Nombre Introducir datos generales.
Objetivo
Resultado Esperado
Resultado Obtenido
Éxito
de la prueba
79
Identificador 24
Objetivo
cuando dejas algún campo obligatorio vacío.
Resultado Esperado
Resultado Obtenido
Éxito
de la prueba
Identificador 25
Comprobar que los puntos función se calculan
Nombre
correctamente.
Cuando se introducen las líneas de código para
Objetivo
un lenguaje se calculan los puntos función.
Resultado Esperado Aparecen los puntos función automáticamente.
Resultado Obtenido Aparecen los puntos función automáticamente.
Éxito
de la prueba
Identificador 26
Comprobar la inserción incorrecta de líneas de
Nombre
código.
No se puede introducir una letra en uno de los
Objetivo
campos de las líneas de código.
Resultado Esperado En el campo no aparece la letra.
Resultado Obtenido En el campo no aparece la letra.
Éxito
de la prueba
80
Identificador 27
Comprobar que los datos se calculan de manera
Objetivo
automática
Resultado Esperado Los resultados aparecen de manera automática.
Resultado Obtenido Los resultados aparecen de manera automática.
Éxito
de la prueba
5.5.4 Reunión Semanal


Scrum Master en la que en la primera parte el product owner revisó las historias y en función
de los criterios de aceptación dijo que historias estaban completadas y que historias se tenía
que pasar al cuarto sprint. Todas las historias fueron aceptadas.

El Sprint ha finalizado con la realización de todas las historias asignadas a éste y sin ningún
81
5.6 Sprint 4
del modelo Historias de Usuario. Estas historias consistirán en realizar la estimación del
esfuerzo de las historias para obtener el esfuerzo y el coste total del proyecto.


En este sprint se ha decidido abordar la historia 19 (insertar datos generales Historias
de Usuario), la historia 20 (insertar historias de usuario), la historia 21 (estimar historia de
usuario) y la historia 22 (visualizar resultados historias de usuario).
corresponden con la empresa, la fecha, el proyecto, el ciclo de vida, la equivalencia de puntos
historias en horas, la tecnología, el coste medio por hora del desarrollador, la descripción y
si el proyecto está imputado. Esta historia se ha estimado con una duración de 1 día.
La historia 20 consiste en insertar los datos de la historia de usuario que se va a estimar
que en este caso corresponden con el título, la descripción, el valor, las dependencias y los
criterios de validación de la historia. Esta historia se ha estimado con una duración de 4
días.
La historia 21 consiste en estimar las historias de usuario mediante la técnica de Planning
Poker. Esta historia se ha estimado con una duración de 6 días.
La historia 22 consiste en visualizar los resultados obtenidos, que en este caso es el esfuer-
zo de cada historia, el esfuerzo total y el coste. Esta historia se ha estimado con una duración
de 3 días.

La historia global Realizar estimación con Historias de Usuario se ha descompuesto en las
historias 19, 20, 21 y 22 citadas anteriormente. Esta historia se corresponde con el requisito
funcional Elaborar estimación con Historia de Usuario. Que se corresponde con el caso de
uso Insertar estimación Historias de Usuario (véase figura 5.37).
82
Figura 5.37: Caso de uso insertar estimación Historias de Usuario

Una vez que se ha realizado el análisis de la historia de usuario, se creó el diagrama de
clases de diseño de la figura 5.38:
Figura 5.38: Diagrama de clases Historias de Usuario
En el diagrama de clases 5.38 se distinguen las siguientes clases:

historias_usuario_datosgenerales almacena los datos generales de la estimación,
historias_usuario almacena los datos de las historias de usuario,
planning_poker almacena los participantes y la estimación del esfuerzo final de la
historia,
planning_poker_partidas almacena el valor propuesto para el esfuerzo de cada partici-
pante, y
resultados_historias almacena los resultados de la estimación.
83
En la figura 5.39 se muestran las distintas tablas de la base de datos asociadas al módulo de
la estimación Historias de Usuario. Para obtener dichas entidades en el diagrama de entidad
Figura 5.39: Diagrama entidad relación Historias de Usuario
Para implementarla se ha utilizado la clase historias_usuario_datosgenerales que mos-
trábamos en el diagrama de clases de la figura 5.38. En la figura 5.40 se recogen los
84
Figura 5.40: Introducir datos generales Historias de Usuario
Para implementarla se ha utilizado la clase historias_usuario que mostrábamos en el
diagrama de clases de la figura 5.38. En la figura 5.41 se recogen los datos de cada
historia de usuario que queremos estimar.
Figura 5.41: Introducir datos de las Historias de Usuario
85
Para implementarla se han utilizado las clases planning_poker y planning_poker_par-
tidas que mostrábamos en el diagrama de clases de la figura 5.38. En la figura 5.42
se estima el esfuerzo para cada historia de usuario utilizando la técnica del Planning
Poker.
Figura 5.42: Estimación con la técnica Planning Poker
Para implementarla se ha utilizado la case resultados_historias que mostrábamos en el
diagrama de clases de la figura 5.38. En la figura 5.43 se muestra el esfuerzo estimado
para cada historia, el esfuerzo total y el coste total.
Figura 5.43: Resultados Historias de Usuario
86
5.6.3.4. Pruebas
En este apartado se van a realizar pruebas funcionales a la herramienta, utilizando una
plantilla tomada como referencia del estándar ISO/IEE 29119-3: Software and Systems en-
gineering - Software testing [29].
Identificador 28
Objetivo
Resultado Esperado
Resultado Obtenido
Éxito
de la prueba
Identificador 29
Objetivo cuando dejas algún campo obligatorio
vacío.
Resultado Esperado
Resultado Obtenido
Éxito
de la prueba
87
Identificador 30
Nombre Introducir Historia de Usuario.
Comprobar que las historias de usuario se
Objetivo
crean correctamente.
La aplicación muestra la historia de usuario
Resultado Esperado con el título y la descripción que se ha
elegido anteriormente.
La aplicación muestra la historia de usuario
Resultado Obtenido con el título y la descripción que se ha
elegido anteriormente.
Éxito
de la prueba
Identificador 31
Nombre Inserción incorrecta Historia de Usuario.
Comprobar que las historias de usuario no
Objetivo
se introducen sin un título y descripción.
La aplicación muestra el mensaje "Por
Resultado Esperado
favor introduzca un título y una descripción"
La aplicación muestra el mensaje "Por
Resultado Obtenido
favor introduzca un título y una descripción"
Éxito
de la prueba
Identificador 32
Nombre Insertar datos Historia de Usuario.
Comprobar que los datos de la historia
Objetivo
se insertan correctamente.
La aplicación muestra el mensaje "Guardado
Resultado Esperado
con éxito".
La aplicación muestra el mensaje "Guardado
Resultado Obtenido
con éxito".
Éxito
de la prueba
88
Identificador 33
Inserción incorrecta datos Historia de
Nombre
Usuario.
Comprobar que la historia no se guarda si
Objetivo
tiene campos obligatorios vacíos.
La aplicación muestra el mensaje "Por favor
Resultado Esperado introduzca un valor y unos criterios de
validación".
La aplicación muestra el mensaje "Por favor
Resultado Obtenido introduzca un valor y unos criterios de
validación".
Éxito
de la prueba
Identificador 34
Nombre Estimación Planning Poker.
Comprobar que la historia se estima de
Objetivo
forma correcta con la técnica Planning Poker.
La aplicación introduce en la casilla esfuerzo
Resultado Esperado
el valor obtenido.
La aplicación introduce en la casilla esfuerzo
Resultado Obtenido
el valor obtenido.
Éxito
de la prueba
Identificador 35
Nombre Estimación incorrecta Planning Poker.
Comprobar que en el número de participantes
Objetivo
no deja introducir letras.
La aplicación no muestra la letra y deja vacío
Resultado Esperado
el campo.
La aplicación no muestra la letra y deja vacío
Resultado Obtenido
el campo.
Éxito
de la prueba
89
Identificador 36
Comprobar que los resultados se calculan
Objetivo
correctamente.
Cuando se pasa de pestaña los valores se
Resultado Esperado
muestran automáticamente.
Cuando se pasa de pestaña los valores se
Resultado Obtenido
muestran automáticamente.
Éxito
de la prueba

5.6.5 Revisión del sprint

Tras finalizar las dos semanas de spirnt se realizó una reunión con el Product Owner y
el Scrum Master. Se hizo una demo en la que se mostraban los avances realizados en el
sprint y el Product Owner en función de los criterios de aceptación de cada historia decidió
cuales estaban completadas y cuales tenían que pasar al quinto sprint. Todas las tareas fueron
aceptadas.

90
5.7 Sprint 5
En este sprint se abordarán las historias necesarias para llevar a cabo la gestión de la
aplicación y parte de la gestión de las estimaciones.


En este sprint se ha decidido abordar la historia 23 (filtrar estimaciones), la historia 24
(modificar estimaciones), la historia 25 (eliminar estimación), la historia 27 (imputación
real de la estimación), la historia 29 (Registrarse), la historia 30 (acceso a la aplicación), la
historia 31 (cerrar sesión) y la historia 32 (modificar perfil).
La historia 23 consiste en realizar un filtro para poder obtener las estimaciones realizadas
en función del modelo utilizado, la empresa, la fecha, el proyecto, el ciclo de vida utilizado
y si la estimación está imputada. La duración estimada para la realización de esta historia es
de 4 días.
La historia 24 consiste en visualizar las estimaciones realizadas, obtenidas después de
aplicar el filtro, y poder modificarlas. La duración estimada para la realización de esta historia
es de 4 días.
La historia 25 consiste en eliminar las estimaciones realizadas, obtenidas después de apli-
car el filtro. La duración estimada para la realización de esta historia es de 0,5 días.
La historia 27 permite introducir el esfuerzo y el coste real del proyecto. La duración
estimada para la realización de esta historia es de 0,5 días.
La historia 29 permite realizar el registro de los usuarios en la aplicación. La duración
estimada para la realización de esta historia es de 1 día.
La historia 30 permite acceder a la aplicación mediante un correo electrónico y una con-
traseña. La duración estimada para la realización de esta historia es de 1 día.
La historia 31 permite salir de la aplicación siempre que el usuario lo desee. La duración
estimada para la realización de esta historia es de 0,5 días.
La historia 32 permite modificar los datos personales del usuario. La duración estimada
para la realización de esta historia es de 1 día.

En este caso tenemos dos historias globales Gestionar la aplicación que se ha descompues-
to en las historias 29, 30, 31 y 32, y Gestionar las estimaciones que se ha descompuesto en
las historias 23, 24, 25 y 27. Estas historias se corresponden con los requisitos funcionales
91
Gestionar aplicación y Gestionar estimaciones. Que se corresponden con los casos de uso
gestionar aplicación (véase figura 5.44) y gestionar estimación (véase figura 5.45).
Figura 5.44: Diagrama de casos de uso Gestionar Aplicación
Figura 5.45: Diagrama de casos de uso Gestionar Estimación

Una vez realizado el análisis de las historias de usuario, se creará el diagrama de clases
para la historia gestionar aplicación como se puede ver en la figura 5.46, ya que la parte
de gestionar las estimaciones utiliza todos los diagramas de clases presentados anteriormen-
te.
92
Figura 5.46: Diagrama de casos de uso Gestionar Aplicación
En el diagrama de clases 5.46 además de las clases que ya se definieron anteriormente

se define la clase usuario que almacena los datos personales y de acceso a la aplicación del
usuario. Cabe destacar que para su mejor visualización hemos omitido las clases que están
relacionadas con los modelos de estimación.
En la figura 5.47 se muestran las distintas tablas de la base de datos asociadas a la gestión
de los usuarios. Para obtener dichas entidades en el diagrama entidad relación se ha decidido
implementar el patrón una clase-una tabla.
93
Figura 5.47: Diagrama entidad relación gestión de usuarios
Para implementarla se ha realizado un método filtrar en cada una de las clases Dao
de los modelos de estimación. Se recogen los datos por los que queremos filtrar las
estimaciones realizadas. En la figura 5.48 se muestran las estimaciones filtradas por el
modelo Puntos Función.
94
Figura 5.48: Filtrar Estimaciones
Para implementarla se ha realizado un método modificar en cada una de las clases
Dao de los modelos de estimación. Se muestra la estimación con los datos definidos
inicialmente pudiendo realizar las modificaciones que sean necesarias.
En las figuras 5.49, 5.50, 5.51, 5.52 y 5.53 podremos observar la estimación realizada
en el modelo Puntos Función anteriormente modificando los factores de influencia para
así obtener otros resultados y poder modificarlos.
Figura 5.49: Datos generales de la estimación
95
Figura 5.50: Funcionalidades de la estimación
Figura 5.51: Factores de influencia modificados
Figura 5.52: Resultados modificados
96
Figura 5.53: Resultados modificados
Para implementarla se ha realizado un método eliminar en cada una de las clases Dao
de los modelos de estimación. En las figuras 5.54, 5.55 y se elimina la estimación
seleccionada.
Figura 5.54: Estimaciones que se pueden eliminar
97
Figura 5.55: Confirmación de eliminación
Figura 5.56: Estimaciones resultantes después de la eliminación
Historia de Usuario 27 Para implementarla se ha añadido el método imputar a las clases

Resultados de los diferentes modelos de estimación. En la figura 5.57 se introduce el
coste y el esfuerzo real del proyecto para que posteriormente con otras funciones se
pueda hacer comparaciones entre lo que nuestra aplicación había estimado y lo que ha
sido en realidad.
Figura 5.57: Imputar Estimación
98
Historia de Usuario 29 Para implementarla se ha utilizado la clase usuarios que mos-
trábamos en el diagrama de clases de la figura 5.46. En la figura 5.58 Se introducen
los datos necesarios para realizar el registro de un usuario en la aplicación.
Figura 5.58: Registro
Para implementarla se ha utilizado la clase usuarios que mostrábamos en el diagrama
de clases de la figura 5.46. En la figura 5.59 se introduce el correo y la contraseña para
poder acceder a la aplicación.
Figura 5.59: Acceso a la aplicación
99
de clases de la figura 5.46. Permite cerrar la sesión de la aplicación volviendo a la
página de acceso (véase figura 5.60).
Figura 5.60: Cerrar sesión
de clases de la figura 5.46. Permite modificar los datos del perfil del usuario (véase
figura 5.61).
Figura 5.61: Modificar perfil
100
5.7.3.4. Pruebas
Identificador 37
Nombre Filtrar estimaciones
Comprobar que las estimaciones se filtran
Objetivo correctamente por los campos que se han
introducido.
Se muestren las estimaciones que cumplan
Resultado Esperado
esos criterios.
Se muestran las estimaciones que cumplan
Resultado Obtenido
esos criterios.
Éxito
de la prueba
Identificador 38
Nombre Filtrado incorrecto estimaciones
Comprobar que las estimaciones no se
Objetivo muestran cuando no cumplen ningún
criterio de los elegidos en el filtro.
Se muestra el mensaje "No hay ninguna
Resultado Esperado
estimación con esas características".
Se muestra el mensaje "No hay ninguna
Resultado Obtenido
estimación con esas características".
Éxito
de la prueba
101
Identificador 39
Nombre Modificar estimación.
Comprobar que las estimaciones se
Objetivo
modifican correctamente.
Se recarga la página y aparecen los
Resultado Esperado
datos nuevos.
Se recarga la página y aparecen los
Resultado Obtenido
datos nuevos.
Éxito
de la prueba
Identificador 40
Nombre Modificación incorrecta estimación.
Comprobar que no se modifica la
Objetivo
estimación si hay algún campo vacío.
Se muestra el mensaje “Complete este
Resultado Esperado campo“ en el campo que se encuentra
vacío.
Se muestra el mensaje “Complete este
Resultado Obtenido campo“ en el campo que se encuentra
vacío.
Éxito
de la prueba
Identificador 41
Nombre Eliminar estimación
Comprobar que se elimina la estimación
Objetivo
seleccionada.
Se muestra el mensaje "Se ha eliminado
Resultado Esperado correctamente se recarga la página
2
habiendo desaparecido la estimación.

Se muestra el mensaje "Se ha eliminado
Resultado Obtenido correctamente se recarga la página
2
habiendo desaparecido la estimación.

Éxito
de la prueba
102
Identificador 42
Nombre Eliminación incorrecta de una estimación.
Comprobar que no se ha podido eliminar
Objetivo
una estimación.
Se muestra el mensaje "No se ha podido
Resultado Esperado
eliminar la estimación".
Se muestra el mensaje "No se ha podido
Resultado Obtenido
eliminar la estimación".
Éxito
de la prueba
Identificador 43
Nombre Imputar estimación
Comprobar que los datos imputados se
Objetivo
insertan correctamente.
Se muestra el mensaje "Se han guardado
Resultado Esperado
correctamente".
Se muestra el mensaje "Se han guardado
Resultado Obtenido
correctamente".
Éxito
de la prueba
Identificador 44
Nombre Registrar usuario
Comprobar que los usuarios se registran
Objetivo
correctamente.
Accede a la página principal de la
Resultado Esperado
aplicación.
Accede a la página principal de la
Resultado Obtenido
aplicación.
Éxito
de la prueba
103
Identificador 45
Nombre Registrar incorrecto de un usuario.
Comprobar que un usuario no se puede
Objetivo registrar en la aplicación al utilizar un
correo ya registrado.
Se muestra el mensaje “El correo
Resultado Esperado seleccionado ya está en uso. Por favor
introduzca otro".
Se muestra el mensaje “El correo
Resultado Obtenido seleccionado ya está en uso. Por favor
introduzca otro".
Éxito
de la prueba
Identificador 46
Nombre Acceso correcto a la aplicación.
Comprobar que un usuario puede
Objetivo acceder a la aplicación con un email
y una contraseña correcta.
Se accede a la página principal de la
Resultado Esperado
aplicación.
Se accede a la página principal de la
Resultado Obtenido
aplicación.
Éxito
de la prueba
Identificador 47
Nombre Acceso incorrecto a la aplicación.
Comprobar que un usuario no puede
Objetivo acceder a la aplicación con un email
o una contraseña incorrecta.
Se muestra el mensaje “Email o
Resultado Esperado
contraseña incorrecta".
Se muestra el mensaje “Email o
Resultado Obtenido
contraseña incorrecta".
Éxito
de la prueba
104
Identificador 48
Nombre Cerrar sesión de la aplicación.
Comprobar que se cierra la sesión
Objetivo
en la aplicación.
La aplicación vuelve a la página
Resultado Esperado
de acceso.
La aplicación vuelve a la página
Resultado Obtenido
de acceso.
Éxito
de la prueba
Identificador 49
Nombre Modificación de datos de usuario.
Comprobar que un usuario registrado puede
Objetivo
modificar la información de su cuenta.
Resultado Esperado La aplicación muestra los nuevos datos.
Resultado Obtenido La aplicación muestra los nuevos datos.
Éxito
de la prueba
Identificador 50
Modificación incorrecta de datos
Nombre
de usuario.
Comprobar que un usuario registrado no puede
Objetivo
modificar el correo por uno que ya existe.
Se muestra el mensaje “El correo seleccionado
Resultado Esperado
ya está en uso. Por favor introduzca otro".
Se muestra el mensaje “El correo seleccionado
Resultado Obtenido
ya está en uso. Por favor introduzca otro".
Éxito
de la prueba
105

Scrum Master en la que en la primera parte el podruct owner revisó las historias y en función
de los criterios de aceptación dijo que historias estaban completadas y que historias se tenían
que pasar al sexto sprint. Todas las historias fueron aceptadas.

106
5.8 Sprint 6
En este sprint se abordarán las historias necesarias para llevar la otra parte de la gestión
de las estimaciones.


En este sprint se ha decidido realizar la historia 26 (exportar estimación) y la historia 28
(Comparar estimaciones).
La historia 26 consiste en exportar las estimaciones en formato excel.
La historia 28 consiste en realizar una comparación mediante un gráfico de las estimacio-
nes seleccionadas, pudiendo comparar el esfuerzo y coste estimado, y el coste y esfuerzo
real.

En este caso tenemos la historia global Gestionar estimaciones que se ha descompuesto
en las historias 26 y 28 más las nombradas en el sprint anterior. Esta historia se corresponde
con el requisito funcional Gestionar estimaciones. Que se corresponde con el caso de uso
Gestionar estimación. El diagrama de casos de uso correspondiente lo podemos ver en la
figura 5.45.

Una vez realizado el análisis de la historia de usuario, se creará el diagrama de clases en
este caso no se incluye ninguna clase nueva, por lo que el diagrama sería la unión de todos
los diagramas anteriores.
107
Para implementarla se ha realizado una clase auxiliar sin persistencia con las funciones
necesarias para exportar cada modelo de estimación. En las figuras 5.62, 5.63, 5.64 y
5.65 se muestran las figuras de una estimación exportada.
Figura 5.62: Datos generales exportados
Figura 5.63: Funcionalidades exportadas
108
Figura 5.64: ILF exportados
Figura 5.65: Resultados exportados
109
Para implementarla se ha realizado el método comparar en las clases de los diferentes
modelos de estimación. En la figura 5.66 se compara el esfuerzo y coste real con el
coste y esfuerzo estimado en un gráfico de barras.
Figura 5.66: Comparar Estimaciones
5.8.3.4. Pruebas
Identificador 51
Nombre Exportar datos de la estimación.
Comprobar que los datos se exportan
Objetivo
correctamente.
Se muestra el mensaje “Archivo exportado
Resultado Esperado
correctamente + (ruta)".
Se muestra el mensaje “Archivo exportado
Resultado Obtenido
correctamente + (ruta)".
Éxito
de la prueba
110
Identificador 52
Nombre Comparar estimaciones.
Comprobar que las estimaciones se
Objetivo
comparan correctamente.
Se muestra el gráfico de barras con las
Resultado Esperado
estimaciones.
Se muestra el gráfico de barras con las
Resultado Obtenido
estimaciones.
Éxito
de la prueba
Identificador 53
Nombre Comparación incorrecta estimaciones.
Comprobar que no se pueden elegir más
Objetivo
de 4 estimaciones.
Se muestra el mensaje "No se puede
Resultado Esperado
elegir más de 4 estimaciones".
Se muestra el mensaje "No se puede
Resultado Obtenido
elegir más de 4 estimaciones".
Éxito
de la prueba


Tras finalizar las dos semanas de sprint se realizó una reunión con el Product Owner
y el Scrum Master en la que en la primera parte el product owner revisó las historias y
en función de los criterios de aceptación dijo que historias estaban completadas. Al ser el
último sprint y todas las historias haber sido aceptadas, se dio por concluido el desarrollo de
la aplicación.

111
Capítulo 6
Conclusiones
E n este último capítulo se determina si se han conseguido los objetivos parciales detalla-
dos en el segundo capítulo de este documento, incluyendo el objetivo principal.
Para concluir, se presentan algunas propuestas de trabajo futuro relacionadas con la temá-
tica sobre la que versa este trabajo, se incluye al final una pequeña opinión personal de la
autora.
6.1 Análisis de los objetivos del proyecto

El objetivo principal de este trabajo era crear una herramienta multimodelo para la estima-
ción de proyectos software. El objetivo ha sido cumplido a través de la realización de todos
los objetivos parciales que definimos en el capítulo 2.
Ayudándome de la utilización de Scrum como metodología de trabajo, junto con una buena
planificación, me ha permitido cumplir el objetivo de este Trabajo Fin de Grado todo ello
documentado a lo largo de este documento.
Objetivo ¿Conseguida?
Realizar una herramienta multimodelo para la estimación de proyectos
software.
Cuadro 6.1: Objetivo principal
113
Objetivo Justificación ¿Conseguido?
Implementar los diferentes Se justifica haber superado este objetivo par-
algoritmos que son utiliza- cial en los sprints 1, 2, 3 y 4, debido a que es
dos posteriormente por ca- la base para realizar el resto de la aplicación.
da uno de los modelos de
estimación.
Crear formularios para re- Se justifica haber superado este objetivo par-
coger los datos necesarios cial en el sprint 1, 2, 3 y 4, debido a que es
en cada modelo de estima- necesario para poder realizar el resto de obje-
ción. tivos parciales.
Ofrecer mecanismos para la Se justifica haber superado este objetivo par-

visualización, modificación cial en el sprint 5, debido a que se necesitaba
y eliminación de las estima- tener los datos recogidos por los formularios
ciones realizadas anterior- creados anteriormente.
mente.
Exportar las estimaciones Se justifica haber superado este objetivo en el
existentes. sprint 6, debido a que se necesitaba tener los
datos recogidos por los formulários creados
anteriormente.
Dar soporte a la impu- Se justifica haber superado este objetivo par-

tación real de las estimacio- cial en el sprint 5, debido a que se necesitaban
nes realizadas. los datos recogidos por los formularios crea-
dos anteriormente.
Comparar esfuerzos y cos- Se justifica haber superado este objetivo par-

tes estimados respecto a los cial en el sprint 6, debido a que se necesitaban
realmente incurridos. los datos recogidos por los formularios crea-
dos anteriormente.
Cuadro 6.2: Análisis de los objetivos parciales
114
6.2 Trabajo futuro
Tras finalizar este trabajo surgen nuevas cuestiones para un trabajo futuro entre las que
destacan:
Añadir el coste de cada trabajador en función de su rol en el proyecto, lo que permitirá

ajustar más en los costes del proyecto.
Personalizar los modelos de estimación, pudiendo editar los algoritmos para adecuar
más la estimación a cada tipo de empresa, en base a lo que se vaya observando en cada
empresa según los resultados que se vayan obteniendo.
En el modelo Historias de Usuario, poder asignar las historias estimadas a los sprints
que se vayan a realizar y poder controlar la velocidad del equipo de desarrollo en cada
sprint.
Exportar las comparaciones realizadas en la aplicación.
6.3 Opinión personal

La realización de este trabajo me ha servido para adquirir nuevos conocimientos tanto
teóricos en el ámbito de la gestión de proyecto y la estimación de éstos, como aspectos
tecnológicos (profundizando en Java, JavaScript, HTML, utilizar plugins como datatables,
highcharts, la librería POI, etcétera).
Durante estos meses he adquirido conocimientos relacionados con la estimación de pro-
yectos software y he reforzado otros conceptos de aspectos tecnológicos.
El desarrollo de este trabajo y el paso de las dificultades, me han sido útiles para saber que
únicamente conozco una pequeña parte de este gran mundo, la informática, y, por ello, segui-
ré en formación y buscando nuevos retos que me apasionen tanto o más como la realización
de este trabajo.
Por lo tanto, como resultado global de este trabajo me encuentro muy satisfecha y con
ganas de seguir mejorando, evolucionando e innovando en este mundo.
Ciudad Real, a 2 de julio de 2018

Fdo. María Pérez Iniesta
115
Referencias
[1] http://fattocs.com/es/faq-fpa/10-faqes/32-18-que-es-backfiring.html.
[2] http://getbootstrap.com/.
[3] https://spring.io/.
[4] https://maven.apache.org/.
[5] https://es.atlassian.com/software/bitbucket.
[6] https://www.visual-paradigm.com/.
[7] https://www.gimp.org/release-notes/gimp-2.7.html.
[8] https://www.video2brain.com/es/balsamiq-mockups.
[9] http://tomcat.apache.org/.
[10] https://www.mysql.com/products/workbench/.
[11] Cocomo ii. http://sunset.usc.edu/csse/research/COCOMOII/cocomo main.html.
[12] Cronología interactiva de la historia de los puntos función. http://www.laboratorioti.
com/2013/06/03/cronologia-interactiva-de-la-historia-de-los-puntos-funcion/.
[13] Html. https://developer.mozilla.org/es/docs/Web/HTML.
[14] Informe del caos 2015 (chaos report 2015) o cómo de bien o mal fue-
ron los proyectos en el año 2015. http://www.laboratorioti.com/2016/05/16/
informe-del-caos-2015-chaos-report-2015-bien-mal-fueron-los-proyectos-ano-2015/
[15] Introducción a css3. https://www.ecured.cu/CSS3.
[16] Javascript. https://developer.mozilla.org/es/docs/Web/JavaScript.
[17] La técnica del planningpoker. http://www.javiergarzas.com/2018/01/
la-tecnica-del-planning-poker.html.
117
[18] Latex. https://www.latex-project.org/about/.
[19] Método de estimación de puntos de casos de uso. http://233gradosdeti.com/articulos/

metodo-de-estimacion-de-puntos-de-caso-de-uso/.
[20] Método de estimación puntos casos de uso (use ca-

se points). http://www.laboratorioti.com/2013/02/14/
metodo-de-estimacion-puntos-casos-de-uso-use-case-points/.
[21] Qué es scrum y los roles en scrum. https://platzi.com/blog/
que-es-scrum-y-los-roles-en-scrum/.
[22] What is eclipse? https://www.eclipse.org/home/newcomers.php.
[23] What is git. https://www.atlassian.com/git/tutorials/what-is-git.
[24] What is jquery? https://jquery.com/.
[25] What is mysql? https://dev.mysql.com/doc/refman/5.7/en/what-is-mysql.html.
[26] ¿qué es el método kanban para la gestión de proyectos? http://www.javiergarzas.com/
2011/11/kanban.html.
[27] ¿qué es la tecnología java y para qué la necesito? https://www.java.com/es/download/
faq/whatis java.xml.
[28] ¿qué es trello? https://trello.com/about.
[29] INTERNATIONAL STANDARD ISO/IEC/IEE 29119-3. 2013.
[30] A BRAN , A. Software Project Estimation. The fundamentals for Providing High Quality
Information to Decision Makers. John Wiley and Sons, Ltd., 2015.
[31] A DRIANA G ÓMEZ , M ARIA DEL C.L ÓPEZ , S. M., AND OTAZÚ , A. Cocomo- un
modelo de estimaciÓn de proyectos de software.
[32] B OEHM , B., AND ROYCE , W. Ada COCOMO and the Ada Process Model. Ra-Ma,
1989.
[33] G ARZÁS , J., AND NAVARRO , N. Guía de supervivencia ágil: estimación con puntos
historia.
[34] G ÓMEZ , J. Guía Práctica de Estimación y Medición de Proyectos Software. safeCrea-

tive, 2014.
[35] JACOBSON , I., G. B., AND RUMBAUGH , J. El proceso unificado de desarrollo soft-
ware. 2000.
118
[36] J ONES , C. A Guide to Selecting Software Measures and Metrics. CRC Press, 2017.
[37] K ACZOR , K. “5 common mistakes we make writing user stories.
[38] M ARIO G. P IATTINI V ELTHUIS , F ÉLIX Ó SCAR G ARCÍA RUBIO , J. G. P., AND B OC -
CO , M. F. G. Medición y estimación del software: Técnicas y métodos para mejorar
la calidad y la productividad. Ra-Ma, 2008.
[39] S CHWABER , K., AND S UTHERLAND , J. La Guía Definitiva de Scrum: Las Reglas del
Juego. 2016.
[40] V EAS , J. L. Métricas asociadas a la evaluación de si - parte2. https://es.scribd.com/

document/370831573/ESI-Unidad-03-Metricas-Parte-2-p51, 2017.
119
ANEXOS
121
Anexo A
123
Historia de Usuario
Número: 1
Nombre: Configuración Inicial
Valor de Negocio: 50 Esfuerzo: 2 semanas
Descripción: Se instalarán las herramientas necesarias, se creará la base de
datos, se creará el proyecto, se introducirán las dependencias necesarias, se
instalarán maven y spring.
Historias relacionadas:
Tabla 1: Historia de Usuario 1
Historia de Usuario
Número: 2
Nombre: Insertar datos generales Puntos Función
Valor de Negocio: 60 Esfuerzo: 2 días
Descripción: Se insertan los datos generales (empresa, proyecto, fecha, ciclo
de vida, tecnología, etc.) de la estimación.
Historia de Usuario
Número: 3
Nombre: Insertar funcionalidades Puntos Función
Descripción: Se insertan las funcionalidades que tendrá la estimación.
Historia de Usuario
Número: 4
Nombre: Insertar ILF
Valor de Negocio: 80 Esfuerzo: 1 día
Descripción: Se insertan los ficheros lógicos internos de una funcionalidad.
Historias relacionadas: 3
Historia de Usuario
Número: 5
Nombre: Insertar ELF
Descripción: Se insertan los ficheros lógicos externos de una funcionalidad.
Historia de Usuario
Número: 6
Nombre: Insertar EI
Descripción: Se insertan las entradas de una funcionalidad.
Historia de Usuario
Número: 7
Nombre: Insertar EO
Descripción: Se insertan las salidas de una funcionalidad.
Historia de Usuario
Número: 8
Nombre: Insertar EQ
Descripción: Se insertan las consultas de una funcionalidad.
Historia de Usuario
Número: 9
Nombre: Visualizar Resultados Puntos función
Descripción: Permite al usuario visualizar los puntos función sin ajustar, los
ajustados, el esfuerzo el coste y las distribuciones de una estimación.
Historias relacionadas: 2, 3, 4, 5, 6, 7 y 8
Historia de Usuario
Número: 10
Nombre: Insertar datos generales COCOMO II
Historia de Usuario
Número: 11
Nombre: Insertar módulos COCOMO II
Descripción: Se insertan los módulos que tendrá la estimación. En cada
módulo insertaremos el tamaño, el coste y el factor de ajuste.
Historia de Usuario
Número: 12
Nombre: Visualizar resultados COCOMO II
Descripción: Permite al usuario visualizar el esfuerzo, la duración, el coste, el
personal necesario y el coste por instrucción estimado para un proyecto.
Historia de Usuario
Número: 13
Nombre: Insertar datos generales Puntos Casos Uso
Historia de Usuario
Número: 14
Nombre: Insertar actores y casos de uso
Descripción: Se inserta el factor de peso de los actores y el factor de peso de
los casos de uso.
Historia de Usuario
Número: 15
Nombre: Visualizar Resultados Puntos Casos de Uso
Descripción: Permite al usuario visualizar los punto casos de uso sin ajustar,
los ajustados, el esfuerzo, el coste y las distribuciones.
Historia de Usuario
Número: 16
Nombre: Insertar datos generales Backfiring
Historia de Usuario
Número: 17
Nombre: Transformar líneas de código
Descripción: Se insertan las líneas de código de cada lenguaje utilizado y los
transforma en puntos función ajustados.
Historia de Usuario
Número: 18
Nombre: Visualizar Resultados Backfiring
Descripción: Permite al usuario visualizar los puntos función ajustados, el
esfuerzo, el coste y las distribuciones del proyecto.
Historia de Usuario
Número: 19
Nombre: Insertar datos generales Historias de Usuario
Historia de Usuario
Número: 20
Nombre: Insertar Historia de Usuario
Descripción: Se inserta el título, descripción, valor, tareas relacionadas y
criterios de aceptación de la historia de usuario
Historia de Usuario
Número: 21
Nombre: Estimar Historia de Usuario
Descripción: Se estima la historia mediante la técnica de Planning Poker.
Historia de Usuario
Número: 22
Nombre: Visualizar resultados Historias de Usuario
Descripción: Permite al usuario visualizar el esfuerzo y el coste.
Historias relacionadas: 20 y 21
Historia de Usuario
Número: 23
Nombre: Filtrar estimaciones
Descripción: Muestra las estimaciones en función de los filtros especificados.
Historias relacionadas: 2, 3, 4, 5, 6, 7, 8, 9, 10, 12, 13, 14, 15, 16, 17, 18, 19,
20, 21 y 22
Historia de Usuario
Número: 24
Nombre: Visualizar estimaciones
Descripción: Permite visualizar las estimaciones.
20, 21 y 22
Historia de Usuario
Número: 25
Nombre: Eliminar estimaciones
Valor de Negocio: 80 Esfuerzo: 0,5 días
Descripción: Permite eliminar estimaciones.
20, 21 y 22
Historia de Usuario
Número: 26
Nombre: Exporta estimaciones
Descripción: Permite exportar los resultados de las estimaciones en formato
Excel.
20, 21 y 22
Historia de Usuario
Número: 27
Nombre: Imputación real de las estimaciones
Descripción: Permite introducir el esfuerzo y el coste real del proyecto.
Historias relacionadas: 2, 10, 13, 16 y 19.
Historia de Usuario
Número: 28
Nombre: Comparar estimaciones
Descripción: Permite realizar comparaciones entre estimaciones, mostrando
además un gráfico de comparación.
20, 21 y 22
Historia de Usuario
Número: 29
Nombre: Registrarse
Descripción: Permite el registro de los usuarios.
Historia de Usuario
Número: 30
Nombre: Acceso a la herramienta
Descripción: Permite el acceso de los usuarios a la herramienta.
Historia de Usuario
Número: 31
Nombre: Cerrar Sesión
Valor de Negocio: 60 Esfuerzo: 0,5 días
Descripción: Permite salir de la aplicación.
Historia de Usuario
Número: 32
Nombre: Modificar Perfil
Descripción: Permite modificar los datos del usuario.
Anexo B
Manual de Usuario
En el presente anexo se incluye el correspondiente manual de usuario de la aplicacion

desarrollada en el contexto del presente TFG. En él se describirán las funcionalidades y los
diversos pasos que han de ser seguidos para el correcto uso de la aplicación.
B.1 Registro de usuarios

Para utilizar la aplicación el usuario debe estár registrado, lo podrá hacer a través de la
pantalla de registro (figura B.1). En dicha pantalla, el usuario deberá introducir su correo, su
nombre, sus apellidos, la empresa a la que pertenece y la contraseña.
Figura B.1: Pantalla de registro
133
B.2 Acceso a la aplicación
El usuario podrá iniciar sesión en la aplicación a través de la inserción de sus credenciales
(figura B.2).
Figura B.2: Pantalla de acceso
B.3 Página Principal

Como se puede observar en la figura B.3 aparecen las últimas estimaciones realizadas
por el usuario mostrando el tipo de estimación, el proyecto, la empresa a la que pertenece
la estimación, la versión y la fecha. También se puede observar un menú latera en el que
podemos realizar una nueva estimación, gestionar las estimaciones y acceder al perfil del
usuario.
Figura B.3: Pantalla de inicio de la aplicación
134
B.4 Crear estimación Puntos función
Cuando seleccionamos en el menú la opcion de Puntos función nos aparecerá la pestaña
para introducir los datos generales de la estimación (figura B.4), que en este caso se corres-
ponden con la empresa, el proyecto, la fecha, el ciclo de vida utilizado, las características
del sistema en el que se va a desarrollar el proyecto, la tecnología utilizada la descripción, el
coste medio por hora de cada desarrollador y si la estimación está imputada.
Figura B.4: Pestaña Datos generales Puntos función
Una vez que hemos introducido los datos generales de la estimación pasamos a la pestaña
Funcionalidades (figura B.5) en la que tendremos que introducir el nombre y la descripción
y al insertarla aparecerá abajo el nombre de la funcionalidad, los botones con los que podre-
mos acceder a insertar los archivos, interfaces, entradas, salidas y consultas, y por último el
número total de puntos función sin ajustar para esa funcionalidad.
Figura B.5: Pestaña funcionalidades Puntos función
135
Cuando pulsamos un botón de los anteriores nos aparecerá ventana en la que tendremos
que insertar la descripición y, en fución de la opción elegida, los det y ret (figura B.6) o los
det y ftr (figura B.7) correspondientes, obteniendo de manera automática la complejidad y
número de puntos función sin ajustar.
Figura B.6: Ventana para añadir archivos
Figura B.7: Ventana para añadir entradas
Por último una vez introducidas las funcionalidades en la pestaña Resultados aparecerá
calculado los puntos función sin ajustar totales, para obtener el resto de campos tenemos que
introducir los 14 factores de influencia (figura B.8). Una vez elegidos los factores obtendre-
mos el resto de resultados como podemos obervar en las figuras B.9 y B.10.
136
Figura B.8: Ventana Factores influencia
Figura B.9: Pestaña resultados Puntos función
137
Figura B.10: Pestaña resultados distribuciones Puntos función
B.5 Crear estimación COCOMO II

Cuando seleccionamos en el menú la opción COCOMO II nos aparecerá la pestaña para
introducir los datos generales de le estimación (figura B.11), que en este caso se correspon-
den con la empresa, el proyecto, la fecha, el ciclo de vida, descripción y si la estimación está
imputada.
Figura B.11: Pestaña Datos generales COCOMO II
Una vez que hemos introducido los datos generales de la estimación pasamos a la pestaña
Módulos, en esta pestaña podemos elegir el modelo de desarrollo, los factores de escala y
la planificación para el proyecto. Los modelos de desarrollo que se pueden elegir son Early
Design y Post Architecture. En la figura B.12 podemos observar los 5 factores de escala a los
que se les puede asignar un valor de muy bajo, bajo, normal, alto, muy alto y extra.
138
Figura B.12: Ventana Factores de escala COCOMO II
En la figura B.13 podemos observar la planificación a la que se le puede asignar un valor

de muy bajo, bajo, normal, alto y muy alto.
Figura B.13: Ventana Planificación COCOMO II
Después de elegir los valores anteriores se introduce un nombre y una descripción para el
módulo y aparece en la tabla el módulo creado. Una vez ha aparecido el módulo pinchando en
el campo tamaño podremos introducir las líneas de código del módulo o los puntos función
del módulo, los cuales se transformarán en líneas de código. En el campo ratio podremos
introducir el coste de una persona al mes y en el apartado factor del ajuste del esfuerzo
(EAF) se eligen los valores para ajustar el esfuerzo del proyecto.
Cuando se han determinado estos valores se calcúlan el resto de valores como se puede
ver en la figura B.14.
139
Figura B.14: Pestaña Módulos COCOMO II
Por último cuando se han introducido todos los módulos en la pestaña resultados (figura
B.15) se podrán observar los resultados obtenidos, así como el total de las líneas de código
y las horas persona mes.
Figura B.15: Pestaña Resultados COCOMO II
140
B.6 Crear estimación Puntos Casos de Uso
Cuando seleccionamos en el menú la opción Puntos Casos de Uso nos aparecerá la pestaña
para introducir los datos generales de la estimación (figura B.16), que en este caso se corres-
ponden con la empresa, el proyecto, la fecha, el ciclo de vida, el factor de productividad, el
número de desarrolladores, la tecnología el precio por hora del desarrollador, la descripción
y si la estimación está imputada.
Figura B.16: Pestaña Datos generales Puntos Casos de Uso
Una vez que se han introducido los datos generales de la estimación pasamos a la pestaña
Calculos (Figura B.17), en esta pestaña se introduce el número de actores y casos de uso de
cada de cada tipo obteniendo el número de actores sin ajustar y el número de casos de uso
sin ajustar.
Figura B.17: Pestaña Calculos Puntos Casos de Uso
141
Por último una vez introducidos los actores y casos de uso pasando a la pestaña Resul-
tados aparecerá calculado los puntos casos de uso sin ajustar totales, para obtener el resto
de campos tenemos que introducir los factores técnicos (figura B.18) y los factores de en-
torno (figura B.19). Una vez elegidos los factores obtendremos el resto de resultados como
podemos observar en la figura B.20.
Figura B.18: Ventana factores técnicos Puntos Casos de Uso
Figura B.19: Ventana factores entorno Puntos Casos de Uso
142
Figura B.20: Pestaña Resultados Puntos Casos de Uso
B.7 Crear estimación Backfiring

Cuando seleccionamos en el menú la opción Backfiring nos aparecerá la pestaña para in-
troducir los datos generales de la estimación (figura B.21), que en este caso se corresponden
con la empresa, la fecha, la empresa, el ciclo de vida, las características del sistema en el que
se va a desarrollar el proyecto, la descripción, coste medio por hora de un desarrollador y si
la estimación está imputada.
Figura B.21: Pestaña Datos generales Backfiring
143
Una vez se han introducido los datos generales de la estimación pasamos a la pestaña
Líneas de Código (figura B.22), en esta pestaña se introducen las líneas de código que hay
de cada lenguaje utilizado para desarrollar el proyecto y se transoforman en puntos función
ajustados. Al final se obteniene el total de puntos función ajustados.
Figura B.22: Pestaña Transformar líneas de código Backfiring
Por último cuando pasamos a la pestaña Restultado obtenemos los resultados finales como
podemos observar en las figuras B.23 y B.24.
Figura B.23: Pestaña Resultados Backfiring
144
Figura B.24: Pestaña Resultados distribuciones Backfiring
B.8 Crear estimación Historias de Usuario

Cuando seleccionamos en el menú la opción Historias de Usuario aparecerá la pestaña para
introducir los datos generales de la estimación (figura B.25) que en este caso se corresponden
con la empresa, la fecha, el proyecto, el ciclo de vida, la equivalencia en horas del punto
historia, la tecnología, la descripción, el coste medio por hora de un desarrollador y si la
estimación está imputada.
Figura B.25: Pestaña Datos generales Historias de Usuario
Una vez se han introducido los datos generales de la estimación pasamos a la pestaña His-
torias de Usuario (figura B.26), en esta pestaña podremos introducir las Historias de Usuario.
Lo primero que hay que hacer es introducir un título y una descripción para la historia, cuan-
do hemos introducido estos dos campos y le damos a insertar aparece la Historia de usuario,
en la que podremos insertar el valor que aporta la historia a la empresa, las depencias de esta
historia con otras historias y los criterios de validación.
145
Figura B.26: Pestaña Historias Usuario
Como se podía observar anteriormente en la figura B.26 el valor de la estimación no se

podía introducir, para obtener este valor se utilizará la técnica del Planning Poker. Para ello
tenemos que ir a la pestaña Planning Poker (figura B.27), se introducirá el número de parti-
cipantes que participará en la partida y una vez que pulsamos estimar aparecerá una tabla en
la que se introducirán los valores elegidos por cada uno de los participantes. Si no hay una
gran diferencia entre las estimaciones se introducirá el valor en el campo estimación final, se
guardará y aparecerá el valor en el campo estimación. Si por el contrario los participantes no
llegan a un consenso en la estimación se podrá volver a estimar las veces que sea necesario
pulsando el botón volver a estimar.
Figura B.27: Pestaña Planning Poker Historias de Usuario
Por último, cuando hemos estimado todas las historias se pasará a la pestaña Resultados
(figura B.28) y obtendremos los resultados finales de la estimación.
146
Figura B.28: Pestaña Resultados Historias Usuario
B.9 Filtrar estimaciones

Cuando seleccionamos en el menú la opción Mis estimaciones aparecerá un filtro en el
que podemos elegir las opciones por las que seleccionar las estimaciones realizadas. Como
se puede observar en la figura B.29 los campos por los que se puede filtrar son el tipo de
estimación, la empresa, el proyecto, la fecha, el ciclo de vida y si la estimación está impu-
tada.
Figura B.29: Filtro
147
B.10 Modificar estimación
Cuando hemos elegido las historias de usuario sobre las que queremos trabajar podemos
observar las acciones que se pueden realizar con ellas. En el botón modificar podremos
modificar y visualizar los datos de la estimación elegida. Los datos que se deseen modificar
serán guardadados de la misma manera que se hizo en la inserción. En las figuras B.30, B.31
y B.32 se puede observar que se han modificado los valores de los 14 factores de influencia y
los resultados se actualizan automáticamente. Cabe destacar que se va a utilizar la estimación
realizada para explicar la creación de estimaciones de puntos función.
Figura B.30: Ventana factores de influencias modificados
Figura B.31: Pestaña Resultados modificados
148
Figura B.32: Pestaña Resultados distribuciones modificados
B.11 Eliminar estimación

Otra de las opciones que se pueden realizar es eliminar una estimación. Para ello con
pulsar el botón eliminar bastaría. En las figuras B.33, B.33 y B.34 podemos observar como
eliminar una estimación.
Figura B.33: Eliminar estimación seleccionada
149
Figura B.34: Ventana confirmar eliminar
B.12 Exportar estimación

Otra de las opciones que se puede realizar es exportar una estimación. Para ello basta con
pulsar el botón de exportar y se descargará un archivo en formato excel. A continuación, se
muestra en la figura B.35 como quedarían los datos generales exportados.
Figura B.35: Excel datos generales exportados
B.13 Comparar estimaciones

Otra de las opciones que se pueden realizar es comparar estimaciones. Para ello tenemos
que pulsar el botón comparar y aparecerá una tabla con la estimación que queremos comparar
resaltada en color, un gráfico y otra tabla con las estimaciones con las que podemos comparar
la estimación elegida. Para poder seleccionar una estimación basta con dar un click sobre ella
y pasará a la primera tabla y actualizará el gráfico y aparecerán las dos estimaciones en él.
En la figura B.36 podemos observar una comparación entre tres estimaciones.
150
Figura B.36: Comparar resultados de las estimaciones
B.14 Imputar estimación

Otra de las opciones que se pueden realizar es imputar las estimaciones realizadas. Para
ello si pulsamos el botón imputar nos llevará a la pestaña resultados de la estimación elegida
y en la parte de abajo podremos encontrar los campos para introducir los valores imputados.
En la figura B.37 se pueden observar los campos imputados.
Figura B.37: Pestaña Resultados inserción resultados imputados
B.15 Perfil de Usuario

En el menú lateral en la opción de Mi perfil se pueden modificar los datos generales del
usuario. Para ello solo hace falta modificar los datos que se quieran y guardarlos. En la figura
B.38 se puede observar la opción de modificar perfil.
151
Figura B.38: Opción Modificar perfil
152
Anexo C
Contrato de Confidencialidad y Propiedad Intelec-

tual
153
Este documento fue editado y tipografiado con LATEX empleando
la clase esi-tfg (versión 0.20180702) que se puede encontrar en:
https://bitbucket.org/arco group/esi-tfg
157

TFG MaríaPérezIniesta

Cargado por

Copyright:

Formatos disponibles

TFG MaríaPérezIniesta

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

TFG MaríaPérezIniesta

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD DE CASTILLA-LA MANCHA

ESCUELA SUPERIOR DE INFORMÁTICA

GRADO EN INGENIERÍA INFORMÁTICA

TRABAJO FIN DE GRADO

Mesta: Herramienta multimodelo para la

María Pérez Iniesta

TRABAJO FIN DE GRADO

Mesta: Herramienta multimodelo para la

Autor: María Pérez Iniesta

PRESIDENTE VOCAL SECRETARIO

Fdo.: Fdo.: Fdo.:

Gracias a todos, de corazón.

Índice general XIII

Índice de cuadros XVII

Índice de figuras XXI

Listado de acrónimos XXV

A. Historias de Usuario 123

B. Manual de Usuario 133

C. Contrato de Confidencialidad y Propiedad Intelectual 153

3.1. Cronología puntos función [12] . . . . . . . . . . . . . . . . . . . . . . . . 9

4.1. Listado de las historias de usuario realizadas en cada sprint. . . . . . . . . . 39

6.1. Objetivo principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

3.1. Formato de una Historia de Usuario . . . . . . . . . . . . . . . . . . . . . 31

5.1. Caso de uso Insertar estimación Puntos Función . . . . . . . . . . . . . . . 49

B.1. Pantalla de registro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

TFG Trabajo de Fin de Grado

1.2 Estructura del documento

Introducción: Primer capítulo, se introduce el problema que tratará este TFG y la

2.1 Objetivo principal

2.2 Objetivos parciales

A finales de los años 70 se produjo una gran proliferación de métricas de complejidad,

En los años 90 se asentaron las bases iniciadas en el periodo anterior en relación a la

En la década del 2000 se da mayor importancia a la validación empírica de las métricas.

Después de conocer algunos de los aspectos de la historia de la estimación del software

3.2 Modelos de estimación

3.2.1.1. ¿Qué son los puntos función?

Partiendo de la definición anterior, se van a explicar sus características:

Aplicaciones: Mide las aplicaciones de software, no considera el hardware que utili-

Usuario: Quien lo va a utilizar y no quién lo desarrolló o diseñó.

1979 - Allan Albrecht crea los FPA

3.2.1.3. Características de los puntos función

Número de tipos de Número de tipos de elementos de datos incluidos

Número de tipos de Número de tipos de elementos de datos incluidos

Tipo de función Nivel de

2. Calcular los puntos función ajustados:

3.2.1.5. Procedimiento de cálculo del esfuerzo

3.2.1.6. Procedimiento de cálculo del coste

Coste= Esfuerzo * Coste-Medio-Hora

Planificación Especificación Diseño Construcción Pruebas Implantación

Planificación Especificación Diseño Construcción Pruebas Implantación

3.2.2.1. ¿Qué es COCOMO?

3.2.2.2. Historia de COCOMO

3.2.2.3. Modelos de estimación en COCOMO II

3.2.2.4. Cálculo del tamaño

3.2.2.5. Estimación del esfuerzo

3.2.2.6. Estimación de la duración

Coste = P Mestimado ∗ Ratio

3.2.2.8. Estimación de la productividad

P roductividad = T amano_del_modulo/P Mestimado