Universidad ORT Uruguay
Facultad de Ingeniería
Fútbol 360: Plataforma para organizar partidos
de fútbol.
Entregado como requisito para la obtención del título de Licenciado en Sistemas.
Martín Anza – 161413 Matías Ravera – 154969 Nicolás Martínez – 149368
Tutora: Helena Garbarino
2
Declaración de autoría
Nosotros, Nicolás Martínez, Martín Anza y Matías Ravera, declaramos que el trabajo que se presenta en esa obra es de nuestra propia mano. Podemos asegurar que:
La obra fue producida en su totalidad mientras realizábamos el proyecto final de carrera;
Cuando hemos consultado el trabajo publicado por otros, lo hemos atribuido con claridad;
Cuando hemos citado obras de otros, hemos indicado las fuentes. Con excepción de estas citas, la obra es enteramente nuestra;
En la obra, hemos acusado recibo de las ayudas recibidas;
Cuando la obra se basa en trabajo realizado conjuntamente con otros, hemos explicado claramente qué fue contribuido por otros, y qué fue contribuido por nosotros;
Ninguna parte de este trabajo ha sido publicada previamente a su entrega, excepto donde se han realizado las aclaraciones correspondientes.
Nicolás Martínez Matías Ravera Martín Anza
3
Agradecimientos
En primer lugar, queremos agradecer a nuestra tutora Dra. Helena Garbarino por la ayuda brindada a lo largo de todo el proyecto.
Queremos dar las gracias también a Ing. Nicolás Fornaro por ponerse a disposición cuando el equipo tuvo un problema con la tecnología al principio del proyecto.
Además, queremos agradecer a las personas que colaboraron con el equipo: Nicolás Zangaro y Marcelo Bendahan por su colaboración en la introducción sobre la tecnología Web y a Daniel Imoda por su colaboración sobre la tecnología Mobile.
Adicionalmente queremos agradecer a Rodrigo Acuña por brindarnos su conocimiento sobre los complejos deportivos y a “El Picante” Guillermo Dalmao, por brindarnos su experiencia en el armado de partidos de fútbol para el desarrollo de la aplicación Mobile.
Finalmente, queremos agradecer a nuestras familias y amigos por el apoyo brindado durante este año. No podríamos haber superado esta etapa sin su paciencia, comprensión y contención.
4
Abstract
Fútbol 360 surge como solución a la necesidad que hoy en día tienen las personas para organizar sus partidos de fútbol amateur. La plataforma tiene como objetivo lograr que las personas puedan organizar sus partidos de fútbol desde la reserva de la cancha hasta la búsqueda y confirmación de los jugadores.
Se realizó una investigación del mercado para entender el contexto del mismo, para luego desarrollar las actividades que comprende el proceso de ingeniería de requerimientos el cual fue ejecutado en tres etapas, en primer lugar, se desarrolló una extracción y análisis de las necesidades de los clientes, luego una especificación de los requerimientos identificados, y por último la validación de los mismos. Adicionalmente se tuvo en cuenta la importancia de lograr una plataforma que fuese intuitiva, rápida y fácil de uso.
Se centró el esfuerzo en desarrollar una aplicación Mobile en Android para los jugadores y una aplicación Web para los complejos deportivos.
La aplicación Mobile les permite a los jugadores organizar sus partidos de forma automática. Dentro de los principales desafíos a los que se enfrentó el equipo para dicha aplicación se destacan el desarrollo de los algoritmos de búsqueda de los jugadores y la obtención de la disponibilidad de la cancha.
Por otra parte, la decisión de realizar una aplicación Web para los complejos deportivos tiene como objetivo lograr que éstos reporten la disponibilidad de sus canchas de modo que los jugadores puedan desde la aplicación Mobile ver y reservar las mismas de forma automática.
Para lograr esta solución se implementaron tres plataformas, Mobile, Web y Cloud. Teniendo esta última la responsabilidad de integrar a las dos primeras en conjunto con otros sistemas existentes (Google APIs y Twilio).
6
Palabras clave
7
Glosario
Scrum: Marco de trabajo para la gestión y desarrollo de software basada en un proceso iterativo e incremental utilizado comúnmente en entornos basados en el desarrollo ágil de software. [1]
Sprint: Se denomina sprint a cada ciclo o iteración de trabajo que produce una parte del producto terminada y funcionalmente operativa (incremento). [2]
Product Backlog: Lista de requisitos de usuario, que a partir de la visión inicial del producto crece y evoluciona durante el desarrollo. [2]
Sprint Backlog: Lista de los trabajos que debe realizar el equipo durante el sprint para generar el incremento previsto. [2]
Daily Meeting: Reuniones breves diarias donde se revisa en conjunto el trabajo realizado por cada miembro el día anterior, y el previsto para el día en curso. [2]
Sprint Review: Análisis e inspección del incremento generado, y adaptación de la pila del producto si resulta necesario. [2]
Sprint Retrospective: Revisión de lo sucedido durante el Sprint. Reunión en la que el equipo analiza aspectos operativos de la forma de trabajo y crea un plan de mejoras para aplicar en el próximo sprint. [2]
Planning Poker: Es una técnica de estimación basada en el consenso del equipo. Los equipos ágiles en todo el mundo utilizan Planning Poker para estimar. [3]
Story Point: En gestión ágil se suelen emplear “puntos” como unidad de trabajo, empleando denominaciones como “puntos de historia” o simplemente “puntos” “puntos. La unidad “Story Point” de eXtreme Programming se define como la cantidad de trabajo que se realiza en un “día ideal”. [2]
8 Android: Es el sistema operativo personalizable y fácil de utilizar que incluyen más de mil millones de dispositivos de todo el mundo, como teléfonos, tabletas, relojes, televisores, coches y otros en los que se utilizará en el futuro. [5]
iOS: Es un sistema operativo móvil de la multinacional Apple Inc. [6]
Chrome: Google Chrome es un navegador web desarrollado por Google y compilado con base en varios componentes e infraestructuras de desarrollo de aplicaciones. [7]
WCF: Windows Communication Foundation (WCF) es un marco de trabajo para la creación de aplicaciones orientadas a servicios. Con WCF, es posible enviar datos como mensajes asincrónicos de un extremo de servicio a otro. [8]
Microsoft: Es una empresa multinacional de origen estadounidense, fundada el 4 de abril de 1975 por Bill Gates y Paul Allen. Dedicada al sector del software y el hardware. [9]
Microsoft Excel: Es una aplicación distribuida por la suite de oficina Microsoft Office, que se caracteriza por ser un software de hojas de cálculo, utilizado en tareas financieras y contables. [10]
Token: También llamado componente léxico es una cadena de caracteres que tiene un significado coherente en cierto lenguaje de programación. [11]
Framework: En el desarrollo de software, un Framework o infraestructura digital, es una estructura conceptual y tecnológica de soporte definido, normalmente con artefactos o módulos concretos de software, que puede servir de base para la organización y desarrollo de software. [12]
Release: Nueva versión de una aplicación informática. [13]
9 SMS: Es un servicio disponible en los teléfonos móviles que permite el envío de mensajes cortos, conocidos como mensajes de texto, entre teléfonos móviles. [15]
SQL: Es un lenguaje declarativo de acceso a bases de datos relacionales que permite especificar diversos tipos de operaciones en ellas. Una de sus características es el manejo del álgebra y el cálculo relacional que permiten efectuar consultas con el fin de recuperar, de forma sencilla, información de bases de datos, así como hacer cambios en ellas. [16]
BPMN: En español Modelo y Notación de Procesos de Negocio, es una notación gráfica estandarizada que permite el modelado de procesos de negocio, en un formato de flujo de trabajo. [17]
Hardware: La palabra hardware se refiere a las partes físicas tangibles de un sistema informático; sus componentes eléctricos, electrónicos, electromecánicos, mecánicos. [18]
Software: Se conoce como software al equipo lógico o soporte lógico de un sistema informático, que comprende el conjunto de los componentes lógicos necesarios que hacen posible la realización de tareas específicas, en contraposición a los componentes físicos que son llamados hardware. [19]
App Mobile: Es una aplicación informática diseñada para ser ejecutada en teléfonos inteligentes, tabletas y otros dispositivos móviles y que permite al usuario efectuar una tarea concreta de cualquier tipo, profesional, de ocio, educativas, de acceso a servicios, etc. [20]
App: Abreviación de App Mobile.
Overhead: Exceso de tiempo de computación, uso de memoria, ancho de banda u otros recursos; que son requeridos para llegar a un objetivo en particular. [21]
10 los mismos y de la disponibilidad constante de una versión estable de cada elemento para toda persona involucrada en el citado desarrollo. [22]
UBER: Uber Technologies Inc. es una empresa internacional que proporciona a sus clientes una red de transporte privado, a través de su software de aplicación móvil, que conecta los pasajeros con los conductores. [23]
NETFLIX: Netflix, Inc. es una empresa comercial estadounidense de entretenimiento que proporciona mediante tarifa plana mensual Streaming multimedia bajo demanda por Internet y de DVD. [24]
AIRBNB: Airbnb es un mercado comunitario para publicar, descubrir y reservar viviendas.[25]
Dropbox: Dropbox es un servicio de alojamiento de archivos multiplataforma en la nube, operado por la compañía Dropbox. [26]
REST: (Representational State Transfer): Interfaz entre sistemas que utilicen HTTP para obtener datos o indicar la ejecución de operaciones sobre los datos. [27]
SOAP: (originalmente las siglas de Simple Object Access Protocol) es un protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML. [28]
Login: En el ámbito de seguridad informática, login o logon (en español ingresar o entrar) es el proceso mediante el cual se controla el acceso individual a un sistema informático mediante la identificación del usuario utilizando credenciales provistas por el usuario.[29]
Feedback: Es una palabra del inglés que significa retroalimentación; podemos utilizarla como sinónimo de respuesta o reacción, o, desde un punto de vista más técnico, para referirnos a un método de control de sistemas. [30]
11 AJAX: AJAX, acrónimo de Asynchronous JavaScript And XML (JavaScript asíncrono y XML), es una técnica de desarrollo web para crear aplicaciones interactivas. [32]
JavaScript: JavaScript (abreviado comúnmente JS) es un lenguaje de programación interpretado. Se utiliza principalmente en su forma del lado del cliente, implementado como parte de un navegador web permitiendo mejoras en la interfaz de usuario y páginas Web dinámicas, aunque existe una forma de JavaScript del lado del servidor. [33]
SQA: Es el conjunto de actividades planificadas y sistemáticas aplicadas en un sistema de gestión de la calidad para que los requisitos de calidad de un producto o servicio sean satisfechos.[34]
LTE: Long Term Evolution (LTE, por sus siglas en inglés, lo que en español se traduce como Evolución a largo plazo), en telecomunicaciones, es un estándar para comunicaciones inalámbricas de transmisión de datos de alta velocidad para teléfonos móviles y terminales de datos.[35]
DataCenter: Se denomina centro de procesamiento de datos (CPD) a aquella ubicación donde se concentran los recursos necesarios para el procesamiento de la información de una organización. [36]
Popup: El término anglosajón pop-up (en español: ventana emergente) denota un elemento emergente que se utiliza generalmente dentro de la terminología Web. [37]
Layout: La noción de Layout suele utilizarse para nombrar al esquema de distribución de los elementos dentro un diseño. Es habitual que un diseñador que se dedica a la creación de páginas web desarrolle un Layout y se lo presente a su cliente para que éste lo apruebe y decida sobre la distribución de los contenidos. [38]
12 Look and Feel: Es una expresión inglesa que puede tener diferentes significados, por ejemplo, significa textualmente el "aspecto y tacto" de cosas, c1 haciendo referencia a características como serían el "color y la textura". [40]
Endpoint: Un identificador de punto de acceso al servicio Web. [41]
13
Índice
1. Introducción ... 26
1.1. Selección de Proyecto ... 26
1.2. Problema a resolver ... 27
1.3. Objetivos del Proyecto ... 27
1.4. Descripción del equipo ... 28
1.5. Estructura del documento ... 29
2. Análisis de la empresa y su entorno ... 31
2.1. Objetivo ... 31
2.2. Conclusión ... 33
3. Descripción de la solución ... 35
3.1. Aplicación web ... 35
3.1.1. Objetivo ... 35
3.1.2. Principales funcionalidades ... 35
3.2. Aplicación Mobile ... 36
3.2.1. Objetivo ... 36
3.2.2. Principales funcionalidades ... 36
3.3. Integración de las aplicaciones ... 39
4. Requerimientos ... 40
4.1. Alcance ... 40
4.1.1. Funcionalidades de la aplicación Mobile ... 40
4.1.2. Funcionalidades de la aplicación Web ... 43
4.2. Objetivos ... 44
14
4.3.1. Requerimientos de la aplicación Mobile (jugadores) ... 44
4.3.2. Requerimientos de la aplicación Web (complejos deportivos) ... 46
4.4. Ingeniería de requerimientos ... 48
4.4.1. Extracción y análisis ... 49
4.4.2. Especificación ... 49
4.4.3. Validación ... 50
5. Procesos de Gestión ... 51
5.1. Descripción del proceso de desarrollo ... 51
5.1.1. Fases ... 51
5.1.2. Metodología ... 52
5.1.3. Ciclo de Vida ... 54
5.1.4. Adecuación de la metodología Scrum en el proyecto ... 55
5.1.5. Asignación de roles ... 57
5.2. Gestión de Proyecto ... 58
5.2.1. Plan Macro ... 59
5.2.2. Estimación ... 60
5.2.3. Product Backlog ... 61
5.2.4. Sprint Planning ... 63
5.2.5. Daily Meeting ... 64
5.2.6. Sprint Review ... 66
5.2.7. Sprint Restrospective ... 67
5.2.8. Métricas ... 68
5.3. Gestión de alcance ... 72
5.3.1. Definición de alcance ... 73
5.3.2. Requerimientos construidos ... 74
15
5.4.1. Procedimiento para manejo de riesgos ... 76
5.4.2. Plan de Riesgos ... 78
5.4.3. Seguimiento y control de los riesgos ... 79
5.5. Gestión de Comunicación ... 81
5.5.1. Objetivo ... 81
5.5.2. Plan de comunicación ... 82
5.6. Gestión de Calidad ... 83
5.6.1. Objetivo ... 83
5.6.2. Actividades para asegurar la calidad del proceso ... 84
5.6.3. Actividades para asegurar la calidad del producto ... 86
5.7. Gestión de configuración ... 87
5.7.1. Objetivo ... 87
5.7.2. Gestión de archivos ... 87
5.7.3. Gestión del código ... 88
5.7.4. Gestión de los documentos ... 89
6. Arquitectura ... 90
6.1. Descripción de la arquitectura ... 90
6.1.1. Modelo conceptual ... 90
6.1.2. Arquitectura cliente servidor ... 93
6.1.3. Selección de tecnologías ... 94
6.1.4. Vista de módulos ... 97
6.1.5. Vista de capas ... 101
6.1.6. Vista de despliegue ... 103
6.2. Análisis de atributos de calidad ... 106
6.2.1. Seguridad ... 107
16
6.2.3. Disponibilidad ... 109
6.2.4. Escalabilidad ... 110
6.2.5. Performance ... 111
6.2.6. Usabilidad ... 112
6.3. Descripción de los servicios web ... 113
7. Testing ... 118
7.1. Objetivo ... 118
7.2. Estrategia de pruebas ... 118
7.3. Diseño de pruebas ... 119
7.4. Testeo funcional ... 119
7.4.1. Testeo unitario ... 119
7.4.2. Testeo de sistemas ... 120
7.4.3. Testeo de Integración de sistemas ... 121
7.4.4. Testeo exploratorio ... 122
7.4.5. Testeo Beta ... 123
7.4.6. Testeo de aceptación ... 123
7.5. Testeo no funcional ... 124
7.5.1. Testeo de usabilidad ... 124
7.5.2. Testeo de performance... 126
7.6. Métricas y cierre de las pruebas ... 128
7.6.1. Testing funcional ... 128
7.6.2. Testeo de performance... 129
8. Conclusiones ... 131
9. Lecciones Aprendidas... 134
10. Proyecciones a Futuro ... 135
17
ANEXO 1 – Análisis 5 Fuerzas PORTER ... 142
ANEXO 2 – Pestel ... 152
ANEXO 3 – Análisis FODA ... 157
ANEXO 4 – Canvas ... 162
ANEXO 5 – Integración de las aplicaciones ... 169
ANEXO 6 – Detalle de los Requerimientos de Sistema ... 183
ANEXO 7 – Encuesta a Complejo Deportivo ... 207
ANEXO 8 – Detalle de los Sprints ... 210
ANEXO 9 – Análisis y seguimiento de riesgos ... 242
ANEXO 10 – Arquitectura - vistas por plataforma ... 254
ANEXO 11 – Estrategia de Pruebas ... 264
ANEXO 12 – Casos de Pruebas ... 279
18
Índice de tablas
Tabla 1. Requerimientos Funcionales Mobile. ... 45
Tabla 2. Requerimientos No Funcionales Mobile. ... 46
Tabla 3. Requerimientos Funcionales Web. ... 47
Tabla 4. Requerimientos No Funcionales Web. ... 48
Tabla 5. Artefactos. ... 55
Tabla 6. Ceremonias ... 55
Tabla 7. Roles de Scrum. ... 56
Tabla 8. Documentos de la metodología tradicional. ... 56
Tabla 9. Roles tradicionales asignados en el proyecto. ... 57
Tabla 10. Roles y responsabilidades... 57
Tabla 11. Valores de la probabilidad de ocurrencia. ... 76
Tabla 12. Valores del impacto ... 76
Tabla 13. Exposición del riesgo ... 77
Tabla 14. Riesgos identificados y plan de acción sobre los mismos. ... 79
Tabla 15. Riesgo 1. ... 80
Tabla 16. Seguimiento realizado para el riesgo 1. ... 81
Tabla 17. Plan de comunicación ... 83
Tabla 18. Actividades para asegurar la calidad del proceso ... 86
Tabla 19. Representación módulos alto nivel - catálogo de elementos ... 99
Tabla 20. Vista de despliegue - Catálogo de elementos ... 105
Tabla 21. Servicios plataforma Web. ... 114
Tabla 22. Servicios plataforma Mobile ... 117
Tabla 23 Funcionalidades Mobile Usuario 1. ... 124
Tabla 24 Funcionalidad Mobile Usuario 2. ... 125
Tabla 25. Funcionalidades Web ... 126
Tabla 26. Lista de los partidos con sus estados. ... 189
Tabla 27. Sprint Backlog del Sprint 1 ... 210
Tabla 28. Asignación de tareas Sprint 1 ... 211
Tabla 29. Sprint Backlog del Sprint 2. ... 216
19
Tabla 31. Sprint Backlog del Sprint 3 ... 223
Tabla 32. Asignación de tareas Sprint 3 ... 231
Tabla 33. Sprint Backlog del Sprint 4. ... 235
Tabla 34. Asignación de tareas Sprint 4 ... 239
Tabla 35. Seguimiento y acciones riesgo 1 ... 243
Tabla 36. Seguimientos y acciones riesgo 2. ... 244
Tabla 37. Seguimiento y acciones riesgo 3. ... 246
Tabla 38. Seguimiento y acciones riesgo 4. ... 248
Tabla 39. Seguimiento y acciones riesgo 5. ... 250
Tabla 40. Seguimiento y acciones riesgo 6. ... 251
Tabla 41. Seguimiento y acciones riesgo 7 ... 253
Tabla 42. Catálogo de elementos Web Services... 256
Tabla 43. Catálogo de elementos Web ... 259
Tabla 44. Catálogo de elementos Mobile ... 262
Tabla 45. Tipos y niveles de prueba. ... 266
Tabla 46. Pruebas de funcionalidades Mobile. ... 268
Tabla 47. Pruebas de funcionalidades Web. ... 269
Tabla 48. Pruebas de integración ... 269
Tabla 49. Dispositivos utilizados para las pruebas ... 270
Tabla 50. Ambientes de prueba. ... 272
Tabla 51. Herramientas para gestión. ... 273
Tabla 52. Puestos de trabajo. ... 273
Tabla 53. Definición de severidad de los defectos. ... 278
Tabla 54. Casos de prueba para aplicación Mobile ... 285
Tabla 55. Casos de prueba aplicación Web. ... 290
20
Índice de ilustraciones
Ilustración 1. Esquema de análisis de las 5 Fuerzas de Porter. ... 31
Ilustración 2. Esquema de análisis FODA ... 32
Ilustración 3. Lienzo Canvas. ... 33
Ilustración 4. Aplicación web - Grilla de cancha. ... 36
Ilustración 5. Aplicación Mobile - Menú principal ... 37
Ilustración 6. Aplicación Mobile – Perfil ... 38
Ilustración 7. Aplicación Mobile – Amigos ... 38
Ilustración 8. Aplicación Mobile - Canchas ... 38
Ilustración 9. Aplicación Mobile - Partidos... 38
Ilustración 10. Proceso – Partido ... 39
Ilustración 11. Fases del Proyecto. ... 51
Ilustración 12. Ciclo de Vida Scrum.[47] ... 54
Ilustración 13. Foto del Plan Macro con todas las actividades de alto nivel de todo el proyecto. ... 59
Ilustración 14. Escala de Story Points y su equivalencia en horas para realizar el Planning Poker. ... 60
Ilustración 15. Planning Poker... 61
Ilustración 16. Product Backlog. ... 62
Ilustración 17. Ejemplo de un requerimiento bajado al detalle en la actividad en Sprint Planning de la iteración cuatro. ... 63
Ilustración 18. Fotos del pizarrón con el diseño de las pantallas “Finalizar Partido” y “Realizar Puntuaciones” en Sprint Planning de la iteración cuatro... 64
Ilustración 19. Conversaciones de WhatsApp con status de avance. ... 65
Ilustración 20. Conversaciones de WhatsApp con interacción en la etapa de construcción. ... 66
Ilustración 21. Sprint Review del Sprint 1. ... 67
Ilustración 22. Sprint Retrospective del Sprint 1. ... 68
Ilustración 23. Análisis de horas estimadas vs horas consumidas para cada Sprint. ... 69
Ilustración 24. Burndown Chart de todos los Sprints. ... 70
21
Ilustración 26. Distribución de horas por actividad en el proyecto. ... 72
Ilustración 27. Distribución de horas por tecnología en el proyecto. ... 72
Ilustración 28. Product Breackdown Structure. ... 74
Ilustración 29. Plan Product Backlog vs real construido ... 75
Ilustración 30. Story Points construidos. ... 75
Ilustración 31. Evolución de los riesgos a lo largo del proyecto. ... 81
Ilustración 32. Dropbox carpeta proyecto. ... 88
Ilustración 33. Modelo conceptual. ... 91
Ilustración 34. Representación arquitectura Cliente-Servidor ... 94
Ilustración 35. Representación módulos alto nivel ... 98
Ilustración 36. Representación de capas ... 101
Ilustración 37. Diagrama secuencia obtener partidos de jugador ... 102
Ilustración 38. Vista de despliegue ... 103
Ilustración 39. Niveles y tipos de pruebas realizados para cada subsistema. ... 118
Ilustración 40. Informe de Avance día 28/07/2016. ... 120
Ilustración 41. Foto de la Prueba de Integración de Sistemas. ... 122
Ilustración 42. Dispositivos utilizados para las pruebas. ... 122
Ilustración 43. Comentarios de la aplicación por medio de WhatsApp. ... 123
Ilustración 44. Usuarios finales probando la aplicación Mobile. ... 125
Ilustración 45. Distribución de carga para operaciones de la aplicación Mobile ... 127
Ilustración 46. Distribución de carga para operaciones de la aplicación Web. ... 127
Ilustración 47. Pruebas de Sistemas - Informe final. ... 129
Ilustración 48. Tiempos de Respuesta Aplicación Mobile en escenario 2. ... 130
Ilustración 49. Tiempos de Respuesta Aplicación Web en escenario 2. ... 130
Ilustración 50. Imágenes de la aplicación FUBLES. ... 147
Ilustración 51. Aplicación Mobile NosFaltaUno. ... 150
Ilustración 52 Comparación entre competidores ... 151
Ilustración 53. Esquema de análisis FODA ... 157
Ilustración 54. Proceso - Partido ... 170
Ilustración 55. Pantalla nuevo partido. ... 172
Ilustración 56. Nuevo partido – Día, hora, tipo ... 173
26
1.
Introducción
El presente documento tiene como objetivo describir el proyecto realizado como requisito para la obtención del título de “Licenciado en Sistemas”.
Dicho proyecto fue realizado por los alumnos Nicolás Martínez, Martín Anza y Matías Ravera, bajo la tutoría la Dra. Helena Garbarino. El mismo comprendió el período febrero a octubre de 2016 y fue denominado “Fútbol 360”.
Fútbol 360 consiste en una plataforma tecnológica con el objetivo de organizar de forma simple y ágil partidos de fútbol amateur, permitiendo la interacción entre los jugadores y los complejos deportivos.
Es una idea propia que se desarrolló dentro de los parámetros de ORT LISI [43], junto con el aval del CIE [44]. Adicionalmente se contó con la colaboración de expertos en el dominio del problema.
1.1.
Selección de Proyecto
El equipo comenzó a trabajar de forma temprana en el mes de enero de 2016, teniendo como primer objetivo decidir el tipo de proyecto a realizar. En la primera reunión de forma unánime se decidió realizar un proyecto de tipo emprendedor dado la motivación de trabajar sobre una idea propia con la posibilidad de continuarla como un nuevo emprendimiento más allá del alcance de este proyecto.
Una vez tomada esta decisión, se realizaron varias reuniones con el fin de presentar y discutir distintas ideas que resultasen proyectos innovadores y desafiantes para los integrantes del equipo; estas ideas debían solucionar problemas comunes y estar a la altura de un proyecto de grado.
27 En este taller el equipo se enfocó en analizar los problemas a resolver y el mercado existente, así como los potenciales clientes.
Finalmente, en conjunto con las opiniones brindadas en el taller emprendedor por parte de la Lic. Rosana Fernández y los diferentes encuestados, concluimos que el problema relacionado al fútbol amateur era el más interesante a ser explotado.
1.2.
Problema a resolverEl proyecto tuvo como objetivo resolver el problema concurrente que tienen aquellas personas que se encargan de la organización de un partido de fútbol amateur.
Para organizar los partidos, la persona debe llamar cancha por cancha preguntando por disponibilidad para cierta fecha y hora y luego contactar a cada jugador de forma “manual” por alguno de los siguientes medios: “WhatsApp”, “SMS”, correo electrónico o llamadas.
En muchas ocasiones quien organiza el partido de fútbol se frustra al no encontrar la cantidad de jugadores necesarios para completar un partido para el horario en el que la cancha está disponible.
Por otro lado, si bien los complejos en las horas pico se ven desbordados, existe un porcentaje del tiempo en el que estos no logran cubrir la totalidad de las horas. En este sentido las canchas no cuentan con un canal que les permita promocionarse y organizar los partidos de forma activa, de lo contrario lo hacen de forma pasiva esperando que sus clientes los contacten vía telefónica.
1.3.
Objetivos del Proyecto
El equipo se planteó los siguientes objetivos en relación a este proyecto:
28 - Desarrollar las capacidades de los integrantes del equipo a través de la
investigación y uso de nuevas tecnologías no vistas a lo largo de la carrera.
- Aprobar el proyecto de grado de la carrera Licenciatura en Sistemas, con una calificación superior a 90%.
1.4.
Descripción del equipo
El equipo está conformado por los siguientes integrantes:
Martín Anza
Tiene un perfil de desarrollo orientado a la integración de sistemas.
Posee más de 8 años de experiencia en informática.
Nicolás Martínez
Tiene más de diez años de experiencia en el área de calidad con un perfil orientado a la gestión de equipos y proyectos de pruebas de sistemas.
Matías Ravera
29
1.5.
Estructura del documento
A continuación, se detallan los capítulos que componen el documento junto con una breve descripción de cada uno:
Análisis estratégico de la empresa y su entorno: describe el análisis de mercado realizado para definir una estrategia adecuada que permita el correcto desempeño del proyecto emprendedor.
Descripción de la solución: describe la solución implementada de modo de mostrar el resultado del desarrollo realizado tanto para la plataforma Web como Mobile. Se mapean los procesos de negocio, los requerimientos funcionales y las interfaces de usuario intervinientes.
Requerimientos: contiene un detalle de cada requerimiento relevado tanto a nivel funcional como no funcional. Se detalla además la ingeniería de requerimientos aplicada para la obtención de los mismos y el alcance tenido en cuenta para el proyecto.
Procesos de gestión: describe detalladamente todas las actividades realizadas referentes a la gestión durante el proyecto. Se presenta el proceso de desarrollo utilizado junto con sus fases, metodología, ciclo de vida, roles, entre otros. Adicionalmente contiene la gestión del proyecto en sí, mostrando la metodología de trabajo aplicada y una descripción de las principales áreas de gestión tenidas en cuenta.
Arquitectura: presenta la arquitectura realizada para la solución al problema. Se pueden ver diferentes vistas de la misma a modo de lograr un entendimiento adecuado de ella. Adicionalmente se describen todos los atributos de calidad tenidos en cuenta durante el diseño y construcción de la solución.
Testing: detalla todas las pruebas realizadas con el objetivo de lograr un producto final de calidad. Este capítulo contiene el objetivo y estrategia del proceso de testing además de las secciones de testeo funcional, no funcional, métricas y conclusiones.
30 Proyecciones a futuro: las actividades que el equipo espera realizar luego de la finalización del proyecto.
31
2.
Análisis de la empresa y su entorno
2.1.
Objetivo
Se realizó un análisis estratégico para lograr identificar el mercado en donde la empresa ingresaría y así definir una estrategia adecuada que permita maximizar el desempeño a futuro.
Para ello se realizó un análisis del micro y macro entorno determinando las condiciones de funcionamiento y desarrollo de la empresa.
Con el objetivo de conocer cuál es el sector industrial al cual accederá el proyecto se realizó un análisis del sector tomando en cuenta proveedores, clientes, barreras de entrada, competidores y productos sustitutos; para ello utilizamos el Análisis de las 5 Fuerzas de Porter [45].
En la Ilustración 1, se presenta un esquema del análisis de las 5 fuerzas de Porter.
32 El estudio completo se encuentra adjunto en el ANEXO 1 – Análisis de las 5 fuerzas de Porter.
Tomando en cuenta el macro entorno en donde estará situado el proyecto se realizó un análisis PESTEL [45] para determinar los principales factores externos que pueden afectar futuras estrategias a seguir, el mismo se encuentra adjunto en el ANEXO 2 – Pestel.
Otros aspectos analizados respecto a la definición de la estrategia fueron las fortalezas, oportunidades, debilidades y amenazas.
En la Ilustración 2 se presenta un esquema del análisis FODA.
Ilustración 2. Esquema de análisis FODA
El análisis FODA [45] completo se encuentra en el adjunto ANEXO 3 – Análisis FODA.
33 Ilustración 3. Lienzo Canvas.
El detalle de este análisis se encuentra en el adjunto ANEXO 4 – Canvas
2.2.
Conclusión
34 Desde el punto de vista del análisis FODA, se concluyó que existen fortalezas que la empresa tiene las cuales deben ser explotadas en las estrategias a desarrollar de manera de mejorar la posición de la misma dentro del mercado, algunas de las principales fortalezas que se identificaron fueron, la capacidad del equipo, los procesos bien definidos, la calidad en la gestión y de sus productos. Por otro lado, se identificaron ciertas debilidades tales como los escasos recursos con los que cuenta para desenvolverse, el poco conocimiento del marketing entre otros.
Se detectó a su vez que las principales amenazas que se deben tener en cuenta son: el gobierno, los usuarios de gran exigencia que existen hoy en día y su resistencia al cambio.
Desde el punto de vista de las oportunidades, la que resultó la más atractiva fue el mercado insatisfecho al cual el proyecto apunta, ya que no existe en el sector una solución que provea las funcionalidades ofrecidas por mismo.
Tomando en cuenta el análisis Canvas realizado se puede concluir que la propuesta de valor es brindar una aplicación Mobile capaz de organizar partidos de fútbol y una aplicación Web capaz de administrar los horarios de las canchas de los complejos deportivos. Destacando entre sus principales características que ambas aplicaciones serían de carácter gratuito en primera instancia, confiando en que el mercado brinde la masa crítica de usuarios que permita generar alianzas clave con distintas empresas enfocadas en el deporte para obtener ganancias.
35
3.
Descripción de la solución
El presente capítulo describe la solución final desarrollada. Se detallan las principales funcionalidades, tanto Web como Mobile, en conjunto con Backend.
3.1.
Aplicación web
3.1.1.
Objetivo
La aplicación Web está orientada a las operaciones relacionadas con los complejos deportivos.
Se buscó lograr una interfaz de usuario sencilla y similar a la operación manual realizada por parte de los complejos deportivos, la cual era en su mayoría sin soporte tecnológico mediante el uso de papel. De esta manera se intentó disminuir la resistencia al cambio por parte de los usuarios, logrando brindar un sistema intuitivo ahorrando trabajo, tiempo y evitando errores.
3.1.2.
Principales funcionalidades
La principal funcionalidad con la que cuenta la aplicación Web es la administración de las reservas de las diferentes canchas del complejo deportivo. Mediante esta funcionalidad los usuarios de la aplicación pueden crear o eliminar reservas, ver la disponibilidad de cada una de sus canchas o la disponibilidad total del complejo de manera resumida.
Adicionalmente el complejo puede recibir, si así lo desea, reservas automáticas a través de la aplicación Mobile. Esto trae consigo mayor velocidad, simplicidad, además de evitar errores por mala comunicación entre los clientes y el complejo deportivo.
Además, el complejo deportivo tiene la posibilidad de crear partidos promocionales, para los cuales la plataforma de Fútbol 360 se encarga de enviar invitaciones a distintos jugadores de manera de dar a conocer ese partido promocional.
36 Ilustración 4. Aplicación web - Grilla de cancha.
3.2.
Aplicación Mobile
3.2.1.
Objetivo
La aplicación Mobile está orientada a los jugadores de fútbol, tanto organizadores de partidos, como participantes de los mismos.
La interfaz de usuario, navegabilidad y funcionalidad ofrecida fue uno de los puntos más importantes tenidos en cuenta durante el proceso de diseño y desarrollo de la solución.
Dado que el usuario Mobile fue considerado como el cliente más importante en términos de negocio, se optó por enfocar esfuerzos con el motivo de lograr la mejor solución posible dada la restricción en tiempos con la que se contaba.
3.2.2.
Principales funcionalidades
37 La comunicación entre el jugador organizador y cada uno de sus invitados se realiza mediante el envío de notificaciones propia de la aplicación. Es por tanto que una vez que el jugador invitado haya aceptado participar en el partido, será notificado de cada cambio o acción que el administrador realice sobre el partido.
Una vez finalizado el partido, tanto el organizador como los jugadores invitados, podrán realizar puntuaciones entre ellos.
A continuación, se presentan las seis principales secciones de la aplicación, accesibles a través de íconos en un menú principal. La Ilustración 5 muestra un ejemplo de dicho menú.
Ilustración 5. Aplicación Mobile - Menú principal
38 Ilustración 6. Aplicación Mobile – Perfil Ilustración 7. Aplicación Mobile – Amigos
39
3.3.
Integración de las aplicaciones
A modo de ejemplificar la integración lograda entre ambas aplicaciones, se presenta un ejemplo de proceso de negocio el cual involucra Web y Mobile.
La Ilustración 10 representa el mencionado proceso referente a la creación y ejecución de un partido en la plataforma. Dicho proceso es transversal a la mayoría de las funcionalidades tanto en Web como en Mobile.
Ilustración 10. Proceso – Partido
40
4.
Requerimientos
El presente capítulo tiene como cometido presentar el detalle de cada uno de los requerimientos del sistema a ser desarrollado en este proyecto.
A partir de los requerimientos de negocio identificados en etapas anteriores del proyecto se identifican los requerimientos del sistema a construir. Los requerimientos indican “qué” características y/o funcionalidades debe proveer el sistema. El listado de estos requerimientos se encuentra detallado en la sección “Requerimientos de sistema”.
Por otro lado, se presenta cómo fue la ingeniería de requerimientos, es decir, cuáles fueron las actividades para las etapas de extracción y análisis, especificación, y validación de los requerimientos.
4.1.
Alcance
Este proyecto se propone la construcción de una aplicación Mobile para la organización de partidos e interacción entre los jugadores de fútbol y una aplicación Web para los complejos deportivos para la gestión de las canchas. El alcance de este proyecto comprende diferentes funcionalidades, las cuales se describen a continuación para cada aplicación.
4.1.1.
Funcionalidades de la aplicación Mobile
A continuación, se presentan las funcionalidades de la aplicación Mobile, la cual será utilizada por los jugadores de fútbol amateur.
Partidos
Tiene como responsabilidad todo lo relacionado a la gestión y armado de los partidos, el ambiente previo y post partido entre los jugadores.
41 1) Red de amigos: un primer nivel el cual incluye solamente a la red de amigos del usuario organizador.
2) Amigos de mis amigos: segundo nivel al que un usuario que no consiguió reunir a los jugadores dentro de su red de amigos, pueda enviar invitaciones a los amigos de sus amigos. Esto le dará mayor difusión, pero con cierto grado de acercamiento, dado que no cualquier persona juega con personas desconocidas.
3) Toda la red de jugadores: para poder organizar partidos de futbol con cualquier persona desconocida. Esta opción es masiva, pero a su vez le permite ser selectiva con ciertos atributos de búsqueda tales como edad y complejo deportivo en el cual juega habitualmente.
Al finalizar cada partido los jugadores podrán puntuarse, interactuar con comentarios y fotos.
Perfil con Estadísticas
Funcionalidad que tiene como objetivo gestionar las estadísticas de cada jugador, tales como cantidad de partidos jugados, goles convertidos, entre otros.
Configuración
La funcionalidad de configuración tiene como responsabilidad y objetivo gestionar todo lo relacionado a las configuraciones que puede hacer el usuario en la aplicación Mobile.
Cada usuario podrá configurar su perfil de jugador, por ejemplo: nombre, fecha de nacimiento, país y ciudad de residencia, la posición en la cual juega, pie con el cual patea (zurdo, diestro, ambidiestro), entre otros.
42 Notificaciones
Permite visualizar las siguientes notificaciones:
Nuevo Partido: notificación que le indica al jugador que ha sido invitado a un nuevo partido.
Partido Confirmado: notificación que indica le indica al jugador que el partido al cual él había confirmado su participación, finalmente está confirmado.
Partido Finalizado:le indica al jugador que el partido que ha jugado se ha finalizado, y el mismo podrá ingresar a ver el resultado del mismo, pudiendo a los jugadores e indicar los goles que realizó.
Partico Cancelado: esta notificación le indica al jugador que el partido al cual él había confirmado su participación, finalmente se canceló.
Para cada notificación, al presionar sobre la misma, se despliega la pantalla con la visualización del partido y el estado del mismo.
Adicionalmente cada notificación podrá ser eliminada para “limpiar” su bandeja de notificaciones.
Amigos
Permite visualizar la lista de amigos que se encuentran en la plataforma y aquellos contactos del celular que no se encuentran en la misma. Para estos últimos el usuario tendrá la opción de enviarles invitaciones para que se descarguen la aplicación.
Canchas
43
4.1.2.
Funcionalidades de la aplicación Web
Las funcionalidades que se presentan a continuación serán utilizadas por los usuarios que administrarán las reservas y los partidos de fútbol en el complejo deportivo.
Administración
Tiene como objetivo la gestión de las canchas de los complejos deportivos tales como:
- agregar y quitar canchas, así como modificar los atributos de las mismas.
- configurar el horario disponible de las canchas para las reservas.
Reserva de canchas
Tiene como responsabilidad la gestión de las reservas de las canchas, pudiendo reservar una cancha específica en un día y horario determinado.
Este sistema de reserva permite que los administradores de las canchas, eliminen los papeles y gestionen las reservas de forma automatizada. Brindará la disponibilidad en línea para que sus clientes (los jugadores) puedan visualizar sus canchas y poder reservarlas desde la aplicación Mobile.
También el complejo deportivo podrá organizar sus propios partidos a través de la búsqueda de jugadores de la red, para aquellos horarios que no tendrán concurrencia.
Estadísticas y comunicación:
44
4.2.
Objetivos
- Organizar de forma automática los partidos de futbol amateur.
- Optimizar la gestión de reservas de las canchas y mostrar disponibilidad de las mismas a los jugadores.
- Obtener una base de datos con información de los jugadores y complejos deportivos con el fin de analizar nuevas oportunidades de negocio con marcas deportivas.
4.3.
Requerimientos del sistema
4.3.1.
Requerimientos de la aplicación Mobile (jugadores)
La Tabla 1 y Tabla 2, detallan los requerimientos funcionales y no funcionales respectivamente para la aplicación Mobile.
Requerimientos funcionales: Nro.
Req.
Prioridad Nombre Descripción
RFM1 1 Activación,
Creación y Registración de usuario.
Luego de que la aplicación Mobile Fútbol 360 haya sido descargada, el sistema deberá solicitar la activación y creación del usuario por única vez.
RFM2 2 Amigos El sistema debe contar con una funcionalidad que le permita:
- visualizar a sus amigos
- agregar nuevos amigos
- importar automáticamente sus amigos de la lista de contactos.
RFM3 1 Organizar
partidos de fútbol
El sistema debe permitir a un jugador poder organizar un partido de fútbol de forma ágil y automática.
RFM4 2 Partidos La aplicación deberá contar con una
funcionalidad que liste los partidos jugados por el usuario y los que tiene planificados jugar. RFM5 2 Finalizar partido El jugador que organizó el partido debe tener la
45 Nro.
Req.
Prioridad Nombre Descripción
y agrupar a cada jugador en los dos diferentes equipos.
RFM6 2 Puntuación y
asignación de goles
Al finalizar cada partido, los jugadores podrán puntuar si lo desean a los jugadores. Además, cada jugador podrá indicar cuantos goles ha realizado en ese partido.
RFM7 3 Análisis del
partido
Funcionalidad que permite a los jugadores compartir comentarios, audios y fotos luego de que el partido se haya finalizado con el objetivo de realizar un análisis del partido y poder
generar un relacionamiento entretenido entre los jugadores en el post-partido.
RFM8 2 Estadísticas Cada jugador tendrá una sección de estadísticas donde se le mostrará cuáles son sus datos estadísticos de acuerdo a sus partidos jugados.
RFM9 3 Organizar
partidos de futbol entre equipos
El sistema debe permitir en base a un equipo ya creado, buscar otros equipos de fútbol para competir.
Tabla 1. Requerimientos Funcionales Mobile. Requerimientos no funcionales:
Nro. Req.
Prioridad Nombre Descripción
RNFM1 1 Portabilidad -
Sistema Operativo soportado
La aplicación Mobile Fútbol 360 debe poder ejecutarse en el sistema operativo Android desde la versión 4.0 en adelante.
RNFM2 1 Performance La aplicación Mobile debe soportar una carga de hasta quinientos usuarios operando al mismo tiempo y la aplicación debe responder no superando 10 segundos en promedio.
46 Nro.
Req.
Prioridad Nombre Descripción
RNFM4 1 Seguridad La aplicación debe contar con un sistema de seguridad el cual pueda identificar a los usuarios, autenticar y autorizar las acciones de cada usuario.
RNFM5 1 Usabilidad El sistema deberá ser amigable con el usuario y deberá proveer al mismo una interfaz sencilla y eficaz.
Los usuarios deberán aprender a usar la aplicación sin contar con un manual de usuario o una capacitación.
Tabla 2. Requerimientos No Funcionales Mobile.
4.3.2.
Requerimientos
de
la
aplicación
Web
(complejos
deportivos)
A continuación, se detallan los requerimientos funcionales y no funcionales de la aplicación Web, en la Tabla 3 y Tabla 4 respectivamente.
Requerimientos funcionales: Nro.
Req.
Prioridad Nombre Descripción
RFW1 1 Login al Sistema El sistema debe contar con un Login, con seguridad, permitiendo el ingreso al sistema, solamente a los usuarios registrados en el mismo, e ingresando la contraseña correcta de ese usuario.
RFW2 1 Cerrar Sesión El usuario debe poder cerrar la sesión del sistema, quedando la pantalla del Login, para permitir el ingreso a otro usuario. RFW3 3 Alta de Usuarios El sistema deberá permitir el ingreso de los
usuarios que interactuarán con el mismo.
RFW4 3 Mantenimiento
de complejo
47 Nro.
Req.
Prioridad Nombre Descripción
RFW5 1 Actividad de
cancha
El sistema debe contar con una grilla en donde se mostrará el horario disponible (hora, día) y cancha.
RFW6 1 Reservar hora El sistema debe poder reservar una hora de la grilla.
RFW7 2 Múltiple gestión
de canchas
El sistema debe poder gestionar más de una cancha a la vez.
RFW8 2 Reserva Mobile
automática
El sistema debe poder recepcionar las reservas que se hacen mediante la aplicación.
RFW9 2 Cancelar reserva El sistema debe brindar la posibilidad de cancelar un partido considerando los motivos y la persona que había realizado la reserva.
RFW10 3 Armado
automático de partido
El sistema debe permitir seleccionando día y hora al usuario poder armar un partido automáticamente
RFW11 3 Marcar cancha
como inactiva
El sistema debe contar con la posibilidad de marcar una cancha como inactiva.
RFW12 3 Estadísticas El sistema debe contar con una pantalla para mostrar las estadísticas de las canchas para todos los complejos deportivos.
RFW13 2 Estado de reserva automática
El sistema debe contar con la posibilidad de ver el estado de aquellos partidos que se están organizando de manera automática RFW14 3 Notificación para
partido automático concretado
El sistema debe notificar al usuario en el momento en que se concretó un partido automático.
RFW15 3 Notificaciones El sistema debe contar con una pantalla en donde se visualicen notificaciones para el complejo deportivo.
48 Requerimientos no funcionales:
Nro. Req.
Prioridad Nombre Descripción
RNFW1 1 Portabilidad La aplicación debe correr sobre Google Chrome.
RNFW2 1 Usabilidad El sistema deberá ser amigable con el usuario y deberá proveer al mismo una interfaz sencilla y eficaz.
Los usuarios deberán aprender a usar la aplicación sin contar con un manual de usuario o una capacitación previa.
RNFW3 1 Performance Hoy en día es fundamental que los sistemas se comporten de manera ágil con tiempos de repuesta bajos para poder realizar acciones de manera fluida.
Es por esto que el sistema debe poder realizar estas acciones rápidamente para mejorar la experiencia de usuario.
Se establece un máximo de 5 segundos de espera para la respuesta en tiempos de cada paso de la App Web con una concurrencia de 200 usuarios
Tabla 4. Requerimientos No Funcionales Web.
El detalle de cada uno de estos requerimientos se encuentra en el ANEXO 6 – Detalle de los Requerimientos de Sistema
4.4.
Ingeniería de requerimientos
49
4.4.1.
Extracción y análisis
En primer lugar, se identificaron dos clientes, uno siendo el dueño de un complejo deportivo, al cual se le realizó un cuestionario, para entender la realidad de las canchas de fútbol y sus necesidades.
El segundo cliente se trata de un jugador de fútbol amateur, quien organiza al menos dos partidos de fútbol por semana, con él tuvimos varias reuniones con el objetivo de entender los problemas que tiene al organizar un partido de fútbol de forma manual y detectar sus necesidades.
En la fase 1 del proyecto (fase que se describe en la sección 5.1.1 Fases) se relevaron y se priorizaron los requerimientos de acuerdo a la importancia que estos tenían para el cliente, tanto para el complejo deportivo como para el jugador de futbol amateur que organiza partidos con sus amigos.
Para el caso del complejo deportivo el cual contábamos con menor información sobre el problema y contexto que pudieran tener los complejos, elaboramos una encuesta la cual fue distribuida a nuestro cliente con el objetivo de poder extraer y analizar mejor los requerimientos del sistema Web. Esta encuesta se encuentra en el ANEXO 7 – Encuesta a Complejo Deportivo.
4.4.2.
Especificación
Para especificar los requerimientos, se utilizaron las siguientes técnicas o actividades:
En el Product Backlog desarrollado al inicio del proyecto, se especificaron los requerimientos, los cuales fueron priorizados y ponderados con cada cliente (el del complejo deportivo que utiliza la plataforma Web y el jugador de fútbol amateur que utiliza la plataforma Mobile).
50
4.4.3.
Validación
51
5.
Procesos de Gestión
El objetivo de esta sección es describir detalladamente la gestión de proyecto implementada durante este ciclo de trabajo. Ésta incluye las condiciones que motivaron su definición, las adaptaciones realizadas para las particularidades del proyecto y la descripción de las diferentes etapas contempladas. Además, se presentan diversas métricas obtenidas a lo largo del proyecto.
5.1.
Descripción del proceso de desarrollo
5.1.1.
Fases
El proyecto se estructuró y ejecutó en tres fases con diferentes actividades a lo largo del proyecto como se muestra en la Ilustración 11.
Ilustración 11. Fases del Proyecto. Fase 1 – Inicio
La fase 1 tuvo como objetivo la definición de los procesos a utilizar en el proyecto y contó con las siguientes actividades:
- Definición de la metodología
- Definición de los procesos
- Definición de métricas
- Creación del plan de comunicación
- Creación del plan de gestión de calidad
52
- Análisis del mercado
- Relevamiento y documentación de los requerimientos del sistema
- Capacitación en la tecnología a utilizar durante el desarrollo.
Fase 2 – Construcción
Esta fase tuvo como objetivo la construcción del producto de software. La misma se ejecutó con la metodologia de Scrum definida en la fase 1 y adaptada a las necesidades del proyecto. El detalle de la adaptación y uso de la metodología se describe en la sección “4.1.4 Adecuación de la metodología Scrum en el proyecto”.
La fase de construcción constó de cuatro Sprints los cuales tuvieron como objetivo construir la aplicación Web para los complejos deportivos y la aplicación Mobile para el sistema operativo Android, para los jugadores de fútbol amateur.
Fase 3 – Cierre
En esta fase se realizaron todas las tareas que permitieron realizar el cierre del proyecto:
- Testing y ajustes finales a la aplicación
- Procesamiento de métricas
- Armado de informes
- Cierre de documentación
- Preparación de presentación
- Presentación del proyecto
5.1.2.
Metodología
53 De acuerdo con Proyectosagiles.org [46], se describen algunos beneficios que tiene la implementación de esta metodología, que creemos se ajustaron a la realidad de este proyecto:
Entrega mensual o quincenal de resultados con:
Gestión de la expectativa del cliente: El cliente establece sus expectativas indicando el valor que le aporta cada requisito del proyecto y cuando espera que esté completado. Comprueba de manera regular si se van cumpliendo sus expectativas, da Feedback, ya desde el inicio del proyecto puede tomar decisiones informadas a partir de resultados objetivos y dirige estos resultados del proyecto, iteración a iteración, hacia su meta.
Resultados anticipados: El cliente puede utilizar los resultados más importantes del proyecto antes de que esté finalizado por completo.
Flexibilidad y adaptación: El cliente redirige el proyecto en función de sus nuevas prioridades, de los cambios en el mercado, de los requisitos completados que le permiten entender mejor el producto, la velocidad real de desarrollo, etc.
Productividad y calidad:
De manera regular el equipo va mejorando y simplificando su forma de trabajar. Los miembros del equipo sincronizan su trabajo diariamente y se ayudan a resolver los problemas que pueden impedir conseguir el objetivo de la iteración. La comunicación y la adaptación a las diferentes necesidades entre los miembros del equipo son máximas (se van ajustando iteración a iteración), de manera que no se realizan tareas innecesarias y se evitan ineficiencias.
Las personas trabajan más enfocadas y de manera más eficiente cuando hay una fecha límite a corto plazo para entregar un resultado al que se han comprometido. La consciencia de esta limitación temporal favorece la priorización de las tareas y fuerza la toma de decisiones.
54 Los resultados y esfuerzos del proyecto se miden en forma de objetivos y requisitos entregados al negocio. Todos los participantes en el proyecto conocen cuál es el objetivo a conseguir. El producto se enriquece con las aportaciones de todos.
Equipo Motivado
Las personas están más motivadas cuando pueden usar su creatividad para resolver problemas y cuando pueden decidir organizar su trabajo.
Las personas se sienten más satisfechas cuando pueden mostrar los logros que consiguen.
5.1.3.
Ciclo de Vida
El ciclo de vida aplicado fue iterativo e incremental mediante la utilización de la metodología Scrum.
Para desarrollar la totalidad de los requerimientos que conformaban el producto final, se creó un plan el cual constaba de cuatro iteraciones cortas de tres semanas en las cuales, en cada iteración, se presentó el producto desarrollado. De esta manera se logró un Feedback temprano por parte de la tutora y de los usuarios finales, asegurando que se estaba construyendo el producto deseado.
Los ciclos de vida y el detalle de las ceremonias se pueden visualizar en la Ilustración 12 .
55
5.1.4.
Adecuación de la metodología Scrum en el proyecto
Dado que el proyecto tuvo ciertas particularidades es que fue necesario adecuar la metodología Scrum a las necesidades y contexto del proyecto.
A continuación, en la Tabla 5, Tabla 6 y Tabla 7 se detallas los artefactos, ceremonias y roles de Scrum en el proyecto; cuáles de estos fueron utilizados y de qué manera:
Artefactos Se utiliza Cómo se utiliza
Product Backlog Al inicio del proyecto se generó el Product Backlog Sprint Backlog Al inicio de cada sprint se generó el Sprint Backlog
Burndown Charts
Para cada sprint se generó un Burndown Charts para estudiar la evolución de lo planificado contra lo realizado. También se generó uno global de todo el proyecto el cual se midió contra el Product Backlog Tabla 5. Artefactos.
Ceremonias Se
utiliza Cómo se utiliza
Sprint Planning
Meeting
Al inicio de cada Sprint se realizó la reunión de Sprint Planning Meeting para construir el Sprint Backlog
Daily Scrum Meeting
Esta ceremonia se realizó vía Skype para revisar lo realizado, las dificultades que se tuvieron y las próximas tareas a realizar.
Además, los lunes tuvimos una reunión de seguimiento con la tutora del proyecto para repasar el avance del mismo.
Sprint Review Al finalizar cada Sprint se realizó esta ceremonia con la tutora presentando el producto.
Sprint Restrospective
Al finalizar cada Sprint se realizó esta ceremonia analizando lo realizado en dicho Sprint y tomando conclusiones de los puntos positivas y negativas del mismo.
56
Roles Se
utiliza Cómo se utiliza
Scrum Master Se utilizó este rol de forma de promover y organizar el equipo en la metodología.
Product Owner No
No se implementó el rol de Product Owner dado que no contamos con una disponibilidad y vínculo constante de los clientes (de ambas plataformas Mobile y Web), como lo propone la metodología Scrum.
Equipo
Consiste en el propio equipo del proyecto integrado por Matías Ravera, Martín Anza y Nicolás Martínez.
Tabla 7. Roles de Scrum. Incorporación de elementos de metodologías tradicionales
Se consideró conveniente desarrollar ciertos documentos propios de una metodología tradicional para monitorear las áreas clave del proyecto las cuales se describen en la Tabla 8.
Documento Propósito
Plan de calidad
Describir los distintos componentes que contribuyen al logro de los objetivos de calidad del proyecto, detallando cada una de las actividades de calidad que se realizarán para asegurar la calidad tanto en el proceso como en el producto a construir.
Plan de comunicación
Acordar y documentar las acciones de comunicación necesarias para un gobierno efectivo del proyecto, así como la identificación de los responsables e involucrados del proyecto Fútbol 360 a todos los niveles.
Plan y gestión de riesgos
Asegurar que la evaluación de los riesgos es realizada, identificando y priorizando potenciales riesgos, creando un apropiado plan de manejo de riesgos para minimizar su impacto en el proyecto, o reducir la probabilidad de ocurrencia de estos durante el mismo.
Plan de gestión de configuración
Describir un plan para asegurar que el proyecto Fútbol 360 tiene un control adecuado sobre todos los elementos de trabajo que serán entregables para el cliente.
57
5.1.5.
Asignación de roles
Adicionalmente en la a los roles que propone la metodología Scrum, se identificaron y asignaron dentro del equipo los roles de la metodología tradicional que se describen en la Tabla 9.
Roles adaptados para el proyecto
Persona Gerente del proyecto Ingeniero de requerimientos Arquitecto de Software
Desarrollador SQA SCM
Nicolás Martínez
Matías Ravera
Martín Anza
Tabla 9. Roles tradicionales asignados en el proyecto.
La Tabla 10 detalla las responsabilidades de cada uno de los roles mencionados en la tabla anterior.
Rol Responsabilidades
Gerente del proyecto
Responsable de la planificación, ejecución y control de todas las actividades definidas en el proceso. Realizó tareas
correspondientes para gestionar los riesgos determinados. Ingeniero de
requerimientos
Responsable del relevamiento y documentación de los requerimientos.
Arquitecto
Responsable de las decisiones relacionadas con la arquitectura, diseño y tecnologías involucradas para alcanzar los objetivos del proyecto.
Soporte y asesoramiento a los desarrolladores en el uso de las tecnologías.
Desarrollador Desarrollo del producto.
SQA
Responsable por el desarrollo y cumplimiento del plan de calidad.
Definición y ejecución del plan y estrategia de pruebas. Responsable del testing del proyecto.
SCM
Responsable de la elaboración del plan de gestión de la
configuración, así como de la ejecución de tareas y actividades necesarias para auditar la línea base.
58
5.2.
Gestión de Proyecto
Para gestionar y controlar el desarrollo de todo el proyecto, se implementó en una planilla de Microsoft Excel compartida en Dropbox llamada “Planificación Proyecto Fútbol 360”, la cual contenía todas las ceremonias y actividades que propone la metodología Scrum.
59
5.2.1.
Plan Macro
Se creó un plan macro del proyecto el cual contenía las actividades a alto nivel con los responsables de cada actividad para las tres fases del proyecto. Este plan proporcionaba una vista general del proyecto la cual permite identificar las principales actividades y fechas claves en cada fase del proyecto.
La Ilustración 13, muestra una foto del plan macro mencionado.
60
5.2.2.
Estimación
Para realizar la estimación de esfuerzo en la unidad: Story Point como propone la metodología de Scrum, se acordó entre el equipo la escala a utilizar y una equivalencia en horas para cada Story Point la cual se describe en la Ilustración 14. Esta equivalencia fue necesaria dado que el equipo no contaba con experiencia en estimación de esfuerzo en base a Story Points y si en horas.
Ilustración 14. Escala de Story Points y su equivalencia en horas para realizar el Planning Poker.
61 Ilustración 15. Planning Poker.
5.2.3.
Product Backlog
Una vez realizada la actividad de estimación, se procedió a realizar el Product Backlog, con el total de requerimientos distribuidos en los cuatro Sprints de acuerdo a la prioridad definida por el cliente y acordado el alcance del producto con la tutora.
Para asignar los requerimientos a cada Sprint, se tuvo en cuenta la prioridad de cada uno de acuerdo a la importancia de éstos para los clientes; por este motivo se incluyeron los requerimientos de mayor prioridad en los primeros Sprints.
62 Partidos de Fútbol”, para eso la aplicación debía contar con las canchas de fútbol, la red de jugadores en los tres niveles definidos en los requerimientos (amigos, amigos de mis amigos y otros), los algoritmos de búsqueda para los tres niveles y el sistema de notificaciones para contactar a los distintos jugadores y poder concretar el partido. Por el lado de la plataforma Web, se debía desarrollar las funcionalidades necesarias para que los complejos deportivos pudieran realizar la gestión de las reservas de canchas y los partidos.
Cómo se muestra en la Ilustración 16, todos los requerimientos con prioridad 1 y 2 fueron incluidos en el alcance, y de los de prioridad 3 se seleccionaron aquellos que eran de mayor importancia para el cliente. Los que se encuentran con fondo gris quedaron fuera del alcance de este proyecto.
