Universidad ORT Uruguay Facultad de Ingenier´ıa
Smart Mirror
Sistema para la mejora de compra in-store de las tiendas de ropa
Entregado como requisito para la obtenci´ on del t´ıtulo de Ingeniero en Sistemas
Germ´ an Garc´ıa - 207418 Rodrigo Pisani - 202093 Rafael Torre - 209743
Tutor: Rafael Bentancur
2022
Declaraci´ on de Autor´ıa
Nosotros, Germ´an Garc´ıa, Rodrigo Pisani y Rafael Torre declaramos que el trabajo que se presenta en esta obra es de nuestra propia mano. Podemos asegurar que:
La obra fue producida en su totalidad mientras realiz´abamos el Proyecto Final de Ingenier´ıa en Sistemas;
Cuando hemos consultado el trabajo publicado por otros, lo hemos atribuido con claridad;
Cuando hemos citado obras de otros, hemos indicado las fuentes. Con excep- ci´on 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´e fue contribuido por otros, y qu´e fue contribuido por nosotros;
Ninguna parte de este trabajo ha sido publicada previamente a su entrega, excepto donde se han realizado las aclaraciones correspondientes.
Agradecimientos
En primer lugar queremos agradecerle a nuestras familias y amigos, que nos han acompa˜nado durante el desarrollo del proyecto y a lo largo de toda la carrera, siendo nuestro fundamental sustento.
En segundo lugar a nuestro tutor Rafael Bentancur por guiarnos en todo mo- mento y estar siempre dispuesto a ayudarnos compartiendo su conocimiento y experiencia.
Tambi´en a nuestros revisores, Pablo Hernandez y Dar´ıo Macchi, por sus con- tribuciones en cada instancia.
Tambi´en a Dualboot Partners LATAM en especial a los cofundadores, Federico Rodriguez, Federico Gepp, Matias Varini y Jordano Caputto, por haber confiado en nosotros para realizar su proyecto, y habernos acompa˜nado durante todo el proceso. Menci´on especial a Jos´e Perdomo, quien nos ayud´o en ocasiones con la UI del espejo.
A Bruno Monetti, por ayudarnos con la edici´on del video de presentaci´on del producto.
Por ultimo a Facundo C´anepa y a todo el equipo de Yamba Store, por la buena disposici´on, siendo el cliente piloto del producto.
A todos ellos, muchas gracias.
Abstract
Existe desde ya hace un tiempo cierta tendencia a realizar actividades coti- dianas de forma online. Esta tendencia se vi´o impulsada por el contexto de pan- demia en el que vivimos. Gracias a una gran cantidad de nuevas plataformas de e-commerce, tiendas de peque˜no y mediano tama˜no pueden acceder a tener su tienda online de forma muy accesible.
Esto genera que la experiencia de compra in-store, se vea afectada negativa- mente en ciertos aspectos. Sin embargo, la mayor´ıa de la gente sigue comprando dentro de las tiendas, lo que hace pensar que los beneficios que le genera a estas personas sobrepasan los perjuicios.
Es aqu´ı donde entra Smart Mirror. Est´a soluci´on intenta llevar las ventajas del mundo virtual a las tiendas f´ısicas de forma entretenida; con una experiencia de usuario sencilla y agradable.
Habiendo mencionado el problema del lado del comprador, se entiende que existen problemas tambi´en del lado del vendedor.
Estamos en la era de los datos. Las marcas usan estos datos para tomar de- cisiones basadas en la informaci´on. ¿Pero qu´e pasa cuando el comportamiento de los clientes en las tiendas no genera datos? Smart Mirror tambi´en plantea una soluci´on a este problema.
Mediante el uso de un “espejo inteligente”, los clientes de las distintas tiendas logran tener acceso a informaci´on sobre la prenda que tienen en la mano, como el stock y variedad de colores disponibles. Tambi´en acceden a promociones y prendas recomendadas por la marca.
La prueba de concepto de est´a soluci´on, que sigue y seguir´a en desarrollo, cum- pli´o con los objetivos pautados junto con Dualboot Partners LATAM, empresa impulsora del proyecto, gracias a la aplicaci´on de metodolog´ıas ´agiles como Scrum y Dual Track Agile. Los principales componentes de la soluci´on incluyen un espejo inteligente, un back-office, una aplicaci´on mobile y una API GraphQL. Las tecno- log´ıas utilizadas fueron ReactJS (NextJS), NodeJS (NestJS), Flutter y Python.
En resumen “Smart Mirror” es un ecosistema de aplicaciones que ayuda tanto al comprador como a las tiendas de ropa a mejorar lo relacionado a las compras dentro de las tiendas, agregando valor, sobre todo en la cantidad de informaci´on a la pueden acceder ambas partes.
Palabras clave
Espejo, Tienda, Estad´ıstica, Dualboot, Dual Track Agile, Ingenier´ıa de reque- rimientos, Proceso de dise˜no, UI, Usabilidad, UX, Raspberry PI, Python, NodeJS, NestJS, React, NextJS.
´ Indice general
1 Introducci´on 18
1.1 Presentaci´on del equipo . . . 19
1.2 Elecci´on del proyecto . . . 19
1.3 Objetivos . . . 20
1.3.1 Objetivos del equipo . . . 21
1.3.2 Objetivos acad´emicos . . . 23
1.3.3 Objetivos del producto . . . 24
1.3.4 Objetivos del proyecto . . . 25
1.4 Descripci´on del cliente . . . 26
1.5 Estructura del documento . . . 27
2 Problema y soluci´on 30 2.1 El problema y su contexto . . . 30
2.2 An´alisis de interesados . . . 32
2.3 Desaf´ıos del proyecto . . . 34
2.4 Proceso de selecci´on de la soluci´on . . . 35
2.5 Soluci´on . . . 36
3 Marco metodol´ogico 39
3.1 Caracter´ısticas del proyecto . . . 39
3.1.1 Fase de desarrollo . . . 40
3.1.2 Surge de una idea . . . 40
3.1.3 Cliente t´ecnico . . . 40
3.1.4 Requerimientos funcionales cambiantes . . . 41
3.2 Caracter´ısticas del equipo . . . 41
3.2.1 Buen relacionamiento entre los integrantes . . . 41
3.2.2 Experiencia previa trabajando juntos . . . 42
3.2.3 Progreso en la carrera . . . 42
3.2.4 Sentimiento de obligaci´on de hacer un excelente proyecto . 42 3.3 Roles del equipo . . . 43
3.4 Metodolog´ıas de desarrollo . . . 43
3.4.1 Ciclo de vida del proyecto . . . 43
3.4.2 Scrum . . . 45
3.4.3 Roles . . . 50
3.4.4 Dual Track Agile . . . 53
3.5 Etapas del proyecto . . . 55
3.5.1 Definici´on del problema y la soluci´on t´ecnica . . . 56
3.5.2 Etapa de desarrollo . . . 57
3.5.3 Etapa de documentaci´on . . . 57
3.5.4 Etapa de Gesti´on . . . 57
3.6 Conclusiones . . . 58
4 Ingenier´ıa de requerimientos 60 4.1 Relevamiento . . . 61
4.1.1 Reuniones con el cliente . . . 61
4.1.2 Encuesta . . . 62
4.1.3 Entrevista . . . 63
4.1.4 An´alisis del estado del arte de las herramientas similares . . 64
4.2 Validaci´on . . . 65
4.2.1 Prototipos de UI . . . 65
4.3 Especificaci´on . . . 66
4.3.1 Requerimientos funcionales . . . 66
4.3.2 Requerimientos no funcionales . . . 69
4.3.3 Restricciones . . . 72
4.4 Conclusiones . . . 73
5 Arquitectura y Dise˜no 75 5.1 Introducci´on a la arquitectura . . . 75
5.2 Atributos de Calidad . . . 78
5.2.1 Mantenibilidad . . . 78
5.2.2 Performance y Disponibilidad . . . 85
5.2.3 Interoperabilidad . . . 88
5.3 Otras decisiones . . . 89
5.3.1 Multitenancy . . . 89
5.3.2 Firebase . . . 90
5.4 Conclusiones . . . 91
6 Gesti´on de proyecto 92 6.1 Cronograma e hitos del proyecto . . . 93
6.2 Gesti´on etapa de desarrollo . . . 95
6.3 Gesti´on del alcance . . . 96
6.4 Plan de release . . . 97
6.5 Gesti´on del tiempo . . . 99
6.6 M´etricas de gesti´on . . . 102
6.7 Gesti´on de riesgos . . . 108
6.7.1 Identificaci´on inicial de riesgos . . . 108
6.7.2 An´alisis cualitativo . . . 110
6.7.3 Plan de respuesta y contingencia . . . 110
6.7.4 Seguimiento . . . 112
6.7.5 Conclusiones . . . 114
6.8 Gesti´on de la comunicaci´on . . . 114
6.8.1 Comunicaci´on interna en el equipo . . . 114
6.8.2 Comunicaci´on con el cliente . . . 115
6.8.3 Comunicaci´on con el tutor y docentes de ORT . . . 115
6.9 Conclusiones . . . 115
7 Gesti´on de calidad 117 7.1 Definici´on de calidad . . . 117
7.2 Objetivos de calidad . . . 118
7.2.1 Objetivos del producto . . . 118
7.2.2 Objetivos del proceso . . . 119
7.3 Plan de calidad . . . 119
7.4 Aseguramiento de la calidad . . . 120
7.4.1 Aplicaci´on de est´andares . . . 121
7.4.2 Capacitaciones . . . 126
7.4.3 Pruebas . . . 126
7.4.4 Revisiones . . . 135
7.4.5 Retrospectivas . . . 138
7.5 Gesti´on de incidentes . . . 139
7.6 M´etricas . . . 140
7.6.1 Del proceso . . . 141
7.6.2 Del producto . . . 142
7.7 Conclusiones . . . 145
8 Gesti´on de la configuraci´on 147 8.1 Elementos de la configuraci´on . . . 147
8.1.1 Elementos de documentaci´on . . . 147
8.1.2 Elementos desoftware . . . 148
8.2 Herramientas utilizadas . . . 149
8.2.1 Herramientas utilizadas para la gesti´on de la documentaci´on149 8.2.2 Herramientas utilizadas para la gesti´on del software . . . . 150
8.3 Organizaci´on de los repositorios . . . 151
8.3.1 Divisi´on de los repositorios . . . 151
8.3.2 Manejo de las ramas . . . 152
8.4 Gesti´on de las dependencias . . . 153
8.5 Conclusiones . . . 154
9 Conclusiones 156 9.1 Estado actual . . . 156
9.2 Conclusiones del proyecto . . . 157
9.2.1 Objetivos del equipo . . . 157
9.2.2 Objetivos acad´emicos . . . 158
9.2.3 Objetivos del producto . . . 159
9.2.4 Objetivos del proyecto . . . 160
9.3 Reflexiones y lecciones aprendidas . . . 161
10 Referencias Bibliogr´aficas 165 11 Anexos 173 11.1 Encuesta de entendimiento del problema y relevamiento . . . 173
11.2 Entrevista a Sabrina Argul . . . 179
11.3 Requerimientos funcionales . . . 180
11.4 Riesgos . . . 218
11.5 Encuesta satisfacci´on del cliente . . . 226
11.6 Plan de calidad . . . 228
11.7 Investigaci´on UI/UX . . . 230
11.8 Heur´ısticas de Nielsen . . . 239
11.9 Revisiones de avance . . . 243
11.9.1 Primera revisi´on . . . 243
11.9.2 Segunda revisi´on . . . 244
11.9.3 Tercera revisi´on . . . 246
11.10 Herramientas utilizadas . . . 248
11.11 Plantillas de notas de ceremonias . . . 251
11.12 Encuesta desempe˜no del equipo . . . 255
11.13 Encuesta de pruebas con usuarios en Yamba Store . . . 259
Glosario
API
API Application Programming Interfaces, es un m´odulo de un software que se comunica o interact´ua con otro para cumplir una o muchas funciones.
Backend
Refiere a la separaci´on de intereses entre una capa de presentaci´on y una capa de acceso a datos en la Ingenier´ıa de Software. En este caso, corresponde a la capa de acceso a datos, que se encuentra del lado del servidor y que procesa la entrada desde el frontend. [1]
Bug
Un bug es un error, un problema con el c´odigo en un programa inform´atico.
Brainstorming
Brainstorming es una t´ecnica de grupo en la que se da la creaci´on de ideas novedosas que aporten a la soluci´on de problemas o para hacer m´as eficiente alg´un proceso o actividad que tenga una determinado equipo. [2]
Code review
Code review es la revisi´on del c´odigo por parte de un tercero para la detecci´on temprana de errores en dicho c´odigo.
Coronavirus
Coronavirus es el nombre del virus SARS-CoV-2, cuyo contagio ocasion´o una pandemia mundial.
Commit
El comando git commit guardar´a todos los cambio hechos en la zona de montaje o ´area de preparaci´on.
Epic
Un epic es una gran cantidad de trabajo que se puede desglosar en varias historias de menor tama˜no.
Features
Una feature es un caracter´ıstica distintiva de un elemento de software (por ejemplo, rendimiento, portabilidad o funcionalidad).
Feedback
Feedback es el proceso mediante el cual una persona u entidad que recibe un producto o servicio comunica, de alg´un modo, su nivel de satisfacci´on.
Framework
Un framework es una estructura base utilizada como punto de partida para elaborar un proyecto con objetivos espec´ıficos
Frontend
Refiere a la separaci´on de intereses entre una capa de presentaci´on y una capa de acceso a datos en la Ingenier´ıa de Software. En este caso corresponde a la capa de presentaci´on, que se encuentra del lado del cliente e interact´ua con los usuarios.[1]
Gitflow
Es un flujo de trabajo basado en Git que brinda un mayor control y organi- zaci´on en el proceso de integraci´on continua.[3]
HTTP
HTTP,Hypertext Transfer Protocol, es el nombre de un protocolo el cual nos permite realizar una petici´on de datos y recursos, como pueden ser docu- mentos HTML.[4]
IDE
IDE, Integrated Development Environment, es una aplicaci´on inform´atica para facilitarle al programador el desarrollo de software.
Merge
Merge permite tomar las l´ıneas independientes de desarrollo e integrarlas en una sola rama.
Middleware
Middleware es un software que ofrece servicios y funciones comunes para las aplicaciones.
Prettier
Prettier es una herramienta que se usa para dar formato a tu c´odigo.
Poker planning
El poker planning es una herramienta para la estimaci´on de los proyectos de desarrollo de software.[5]
Pull request
Un pull request es un evento en Git donde un colaborador le pide al mante- nedor de un repositorio de Git que revise el c´odigo que desea fusionar en un proyecto.
QA
QA, Quality Assurance se encarga del aseguramiento de la calidad del soft- ware.
Release
En cualquier enfoque ´agil un release es una versi´on que va a pasar a produc- ci´on.
Sprint
Sprint es un cuadro de tiempo fijo repetible durante el cual se crea un pro- ducto.
SCM
SCM, (Software Configuration Management) es una especializaci´on de la gesti´on de configuraci´on a todas las actividades en el sector del desarrollo de software.
Scrum
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas pr´acticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. [6]
SPA
SPA, single page application, o aplicaci´on de p´agina ´unica, es una aplicaci´on web o es un sitio web que cabe en una sola p´agina.
Stack
Stack es una lista de todos los servicios tecnol´ogicos utilizados para construir y ejecutar una sola aplicaci´on.
Stakeholders
Stakeholder significa interesados o partes interesada, y se refiere a todas aque- llas personas u organizaciones afectadas por las actividades y las decisiones de una empresa.
UI
UI es la vista que permite a un usuario interactuar de manera efectiva con un sistema. Es la suma de una arquitectura de informaci´on m´as elementos visuales m´as patrones de interacci´on. [7]
User Story
Es una explicaci´on general e informal de una funci´on de software escrita desde la perspectiva del usuario final. Su prop´osito es articular c´omo proporcionar´a una funci´on de software valor al cliente.
UX
UX es aquello que una persona percibe al interactuar con un producto o servicio. [7]
1 Introducci´ on
El presente documento describe el proyecto “Smart Mirror: Mejora de la compra in-store de las tiendas de ropa”, realizado como requisito para la obtenci´on del t´ıtulo Ingeniero en Sistemas de la Universidad ORT Uruguay.
El proyecto fue desarrollado por los estudiantes Germ´an Garc´ıa, Rodrigo Pisani y Rafael Torre, bajo la tutor´ıa de Rafael Bentancur, en el per´ıodo comprendido entre los meses de marzo de 2021 y marzo de 2022.
Este cap´ıtulo tiene como objetivo introducir al lector al el proyecto, fundamen- tando su elecci´on y brindando una descripci´on del cliente con el cual se trabaj´o.
Adem´as, se presenta al equipo y se describen los objetivos planteados para el trabajo.
1.1 Presentaci´ on del equipo
Rafael Torre: Posee aproximadamente dos a˜nos de experiencia como fulls- tack developer. Actualmente trabaja en Dualboot Partners LATAM como desarrollador y se capacita para ser Team Leader con conocimientos t´ecni- cos.
Rodrigo Pisani: Tiene casi dos a˜nos de experiencia como fullstack developer hoy en d´ıa m´as espec´ıfico en la parte mobile usando Flutter. Actualmente trabaja en Dualboot Partners LATAM como desarrollador y se capacita para ser Teach Lead.
Germ´an Garc´ıa: Posee m´as de 3 a˜nos de experiencia como fullstack deve- loper. Actualmente trabaja Beloved Robot como desarrollador y se capacita para ser Team Leader con conocimientos t´ecnicos.
1.2 Elecci´ on del proyecto
Si bien el equipo se conoc´ıa previamente y le interesaba emprender, no hubo una idea innovadora que motivara a comenzar dicho emprendimiento. Aunque
actualmente no todos los integrantes trabajan para quien es el cliente de este proyecto, previo al arranque as´ı lo era y fue ´el mismo quien incentiv´o a buscar algo innovador no solo para el equipo sino tambi´en para la empresa.
Por otro lado, gracias a la feria de proyectos realizada por la Universidad ORT se pudo ver otras opciones y ver cual le parec´ıa mejor al equipo para realizar el proyecto final del curso.
Luego de ver todas las opciones que le interesaban al equipo y tener las reunio- nes correspondientes, se decidi´o ir con la propuesta de Dualboot Partners LATAM.
Si bien esta elecci´on no fue sencilla y las otras ofertas tambi´en fueron tentadoras, fue el planteo innovador y la libertad que propuso el cliente para este proyecto lo que convenci´o al equipo de seleccionarlo.
Esta elecci´on se fundamenta en el hecho de que este proyecto se adecuaba m´as a los objetivos del equipo asociados a tecnolog´ıas a utilizar, desaf´ıos t´ecnicos, libertad de la toma de decisiones a lo largo del proyecto, y por sobre todas las cosas, intentar innovar.
1.3 Objetivos
La definici´on de los objetivos al comienzo del proyecto ayud´o a poder dirigir y alinear los esfuerzos del equipo hacia una meta en com´un que se quer´ıa conseguir.
Sirvi´o como motivaci´on para que se fuera trabajando en conjunto con el objetivo de lograr cumplir con los mismos, y permiti´o evaluar los resultados obtenidos al finalizar el proyecto compar´andolos con los inicialmente planteados, para de esta manera corroborar si el proyecto tuvo ´exito.
Para la definici´on de los objetivos se siguieron las pr´acticas recomendadas por SMART[8], las cuales permiten hacer de estos objetivos medibles y que sean claros para todos.
Se decidi´o dividir los mismos en cuatro categor´ıas: objetivos del equipo, obje- tivos acad´emicos, objetivos del producto y objetivos del proyecto.
1.3.1 Objetivos del equipo
Obtener una calificaci´ on de 4 o m´ as (sobre 5) en las en- cuestas de desempe˜ no del equipo que se realizar´ an cada 4 meses
Al enfrentarse a un proyecto cuya duraci´on es de un a˜no, se considera que pueden surgir discrepancias o momentos de tensi´on entre los integrantes del equipo.
Es por esto que se intentar´a tener una comunicaci´on fluida y transparente durante todo el transcurso del mismo, buscando que la expresi´on de sensaciones o problemas se den tempranamente, evitando as´ı problemas mayores que pudieran repercutir en el resultado del proyecto. Se pretendi´o tener una buena din´amica de trabajo en equipo, con apoyo constante para hacer frente a los desaf´ıos que depararon durante el proyecto.
Algo fundamental para alcanzar este objetivo es mantener el grado de compro- miso establecido al comienzo del proyecto.
Para poder medir este objetivo se realizar´an encuestas de desempe˜no y se tendr´an reuniones para analizar los resultados y ver aspectos a destacar y cosas a mejorar.
Adquirir experiencia en din´ amicas de trabajo en equipo y trabajo remoto cumpliendo con las ceremonias y plazos de entrega en tiempo y forma
Dado que al comienzo del proyecto el pa´ıs est´a atravesando una pandemia por coronavirus, que adem´as se considera que puede durar durante todo el transcurso del mismo,las instancias presenciales no ser´a tantas como se esperaba originalmen- te. Esto representar´a un gran desaf´ıo para los integrantes, ya que la motivaci´on resulta fundamental en este tipo de proyectos para cumplir con los plazos y entre- gas. Estas circunstancias no siempre resultan ideales en este tipo de aspectos.
El cumplimiento de este objetivo depende del cumplimiento de plazos y entre- gas.
Afianzar nuestra capacidad de trabajo en equipo para fu- turos proyectos personales. Cumpliendo con las fechas de entrega en tiempo y forma
Este proyecto adem´as de ser la tesis de las carreras de los integrantes del equipo, representa tambi´en una prueba para ver como el mismo funciona. Se considera que a futuro pueden trabajar en proyectos con otros clientes y tener la obligaci´on de realizarlo para la culminaci´on de la carrera fue un motivador muy fuerte.
El cumplimiento de plazos y entregas ser´a la forma de medir este objetivo.
1.3.2 Objetivos acad´ emicos
Aprender al menos 3 nuevas tecnolog´ıas para que nos resul- te m´ as interesante el proyecto a lo largo del desarrollo del mismo.
En una industria tan cambiante como lo es la tecnol´ogica, es clave mantener- se actualizado con las nuevas tendencias que emergen del mercado. Es por esto que el equipo considera que esta es una excelente oportunidad para aprender y/o profundizar el conocimiento que cada uno posee sobre distintas tecnolog´ıas.
La meta particular de 3 es porque se quiere que represente un desaf´ıo pero que no se vuelva un impedimento para cumplir con los plazos y entregas.
Aplicar al menos 3 cosas (metodolog´ıas o t´ ecnicas) aprendi- das en la carrera.
Como una forma de terminar el ciclo acad´emico de una manera exitosa, el equipo se plantea poder aplicar las t´ecnicas y pr´acticas de ingenier´ıa de software adquiridas durante toda la carrera en un ´unico proyecto real. De esta manera se puede afianzar el conocimiento y llevarlo luego la carrera de cada integrante.
La meta es de al menos 3 porque se considera que se aprendi´o mucho en todo este tiempo y no solo sirven como prueba de ver que tanto se ha aprendido sino que tambi´en resultan herramientas muy ´utiles que favorecen al cumplimiento del proyecto.
Cerrar el ciclo acad´ emico con una calificaci´ on mayor a 95, para terminar de la mejor manera.
El proyecto es un trabajo de gran importancia para la formaci´on de los inte- grantes del equipo como futuros profesionales, por lo tanto se plantea el objetivo de lograr una calificaci´on de excelencia en su evaluaci´on. Para lograr el cumplimiento de este objetivo el equipo se debe comprometer desde el comienzo a brindar lo mejor de cada uno para obtener el mejor resultado posible.
1.3.3 Objetivos del producto
Entregar un producto mantenible (el cliente piensa seguir us´ andolo y trabajando en ´ el), en estado de pre-producci´ on.
Debe estar bien documentado y testeado. Tambi´ en se deben usar herramientas que midan la calidad del c´ odigo.
El equipo se plantea el objetivo de entregar un producto que le aporte valor al cliente y que pueda servir de base para que el mismo contin´ue trabajando sobre ´el y materializar su idea, de manera tal de innovar en el mercado y hacerse conocidos internacionalmente.
Para medir el cumplimiento de este objetivo, se har´a uso del feedback recibido por el cliente y las herramientas utilizadas para evaluar la calidad del c´odigo. Se considerar´a exitoso si se cumple con el 100 % de las features acordadas con el cliente, y si la herramienta da una nota mayor a B para todos los archivos de la soluci´on.
Que el producto sea lo suficientemente innovador como pa- ra que despierte curiosidad en el mercado recibiendo buen feedback de las pruebas con usuarios del producto con la encuesta realizada luego del test
Este objetivo no solo brinda informaci´on sobre la validaci´on de la idea, sino que los integrantes del equipo est´en muy conformes con el trabajo realizado. Esto implicar´ıa que se va por buen camino y que las decisiones tomadas fueron las correctas a lo largo del proyecto.
Para medir este objetivo se usar´a la encuesta realizada luego de la prueba en la tienda. Se espera que al menos el 80 % de los usuarios de prueba logren completar una compra sin ayuda y que el 100 % le de un puntaje mayor o igual a 2 (sobre 3) en la facilidad de uso.
Se menciona que el producto se entrega en estado de pre-produccion. Esto significa que se aceptan peque˜nos bugs y la infraestructura puede no ser final. Se aceptar´an hasta 5 errores menores y 3 errores medios.
1.3.4 Objetivos del proyecto
Adquirir la experiencia de llevar adelante un proyecto real de forma aut´ onoma. Cumpliendo con las fechas de entrega en tiempo y forma.
Ninguno de los integrantes del equipo tiene experiencia previa en gestionar y liderar un proyecto por s´ı mismos. Con el objetivo de poder aumentar el rendimien- to y maximizar el potencial de cada uno, se considera clave aprender a trabajar y organizarse en forma aut´onoma, adem´as de adquirir conocimientos valiosos sobre gesti´on y negociaci´on que servir´a para el futuro profesional de cada integrante.
Tanto cumplimiento de plazos y entregas como el feedback a recibir por parte de los revisores son la formas de medir el cumplimiento de este objetivo.
Obtener una calificaci´ on de 4 o m´ as (de 5) en la encuesta a realizar al cliente cada 3 meses.
Resulta de vital importancia mantener una buena relaci´on con el cliente a lo largo del proyecto. Esto permite mantener una comunicaci´on fluida, colaborativa y transparente. Adem´as, mantener una buena relaci´on, permite que el equipo pueda seguir teniendo libertad en la toma de decisiones del proyecto.
El grado de satisfacci´on del cliente se puede medir mediante encuestas de sa- tisfacci´on. El objetivo es obtener un promedio de 4 o mayor, siendo 5 el m´aximo puntaje.
Entregar un producto que cumpla con los requerimientos solicitados por el cliente en tiempo y forma.
Tan importante como la buena experiencia con el proceso, es que la salida del mismo, sea un producto de calidad, cumpliendo con todos los requisitos estableci- dos a lo largo del desarrollo
El cumplimiento de plazos y entregas ser´a la forma de medir este objetivo.
1.4 Descripci´ on del cliente
El cliente es Dualboot Partners LATAM, una empresa uruguaya, anteriormente llamada Attica Labs, fundada en 2014 que trabaja haciendo software a medida para clientes a nivel nacional e internacional, principalmente Estados Unidos.
Los 3 integrantes del equipo entraron en la empresa cuando la misma se llamaba Attica Labs, en el a˜no 2021 la misma se fusion´o con Dualboot Partners, empresa estadounidense y cambi´o su nombre.
Su equipo es multidisciplinario ya que combina las ´areas de desarrollo web, mo- bile, dise˜no UX/UI, QA y equipo de Marketing. Trabaja en proyectos innovadores con clientes de diversos rubros.
Est´an impulsados por la misi´on y enfocados en las personas, siempre hacen referencia de que la empresa es un “club social”. Aplican metodolog´ıas ´agiles al estilo start-up para nuevos productos y negocios desde el primer concepto hasta su lanzamiento.
Consideran que lo m´as importante (y que en parte los diferencia) es tener un equipo excelente, capaz de resolver problemas y sobreponerse a cualquier desaf´ıo.
1.5 Estructura del documento
A continuaci´on, se resume el contenido de cada cap´ıtulo del presente documen- to.
Problema y soluci´ on
Se expone el problema a resolver junto con su proceso de definici´on, esto incluye no solo aciertos sino tambi´en errores. Se describe el contexto en el cual se encuentra el problema, un an´alisis de los interesados y cuales son sus necesidades, adem´as se describe la soluci´on implementada por el equipo.
Marco metodol´ ogico
Se analizan las caracter´ısticas del proyecto, del equipo, y la elecci´on del ciclo de vida. Adem´as, se describen las principales etapas del proyecto, especificando las metodolog´ıas utilizadas en cada una de ellas.
Ingenier´ıa de requerimientos
Se describen todos los pasos llevadas a cabo para realizar la etapa de ingenier´ıa de requerimientos, esto incluye desde, las t´ecnicas de relevamiento, validaci´on y especificaci´on utilizadas, junto con la definici´on de los requerimientos funcionales, no funcionales y restricciones.
Arquitectura y dise˜ no
Se describe la arquitectura de la soluci´on implementada por el equipo, las principales decisiones de dise˜no de dicha arquitectura, y como se relacionan con los atributos de calidad identificados.
Gesti´ on de proyecto
Se muestra como se llevo a cabo la gesti´on del proyecto, desde el cronograma en una l´ınea temporal, la planificaci´on, organizaci´on y seguimiento del proyecto, hasta las distintas m´etricas de gesti´on obtenidas y como fue la gesti´on de riesgos.
Gesti´ on de calidad
Se describe el proceso de calidad y las acciones tomadas para cumplir los ob- jetivos de calidad definidos, tanto desde el punto de vista del producto como del
proceso. Adem´as de mostrar el plan de calidad y cuales fueron las actividades del aseguramiento de calidad, junto con las m´etricas obtenidas y los resultados del an´alisis de las mismas.
Gesti´ on de la configuraci´ on
Se describe cu´al fue la estrategia definida para la gesti´on de la configuraci´on del software y las herramientas utilizadas para el control de la documentaci´on, con las que equipo logr´o mantener un control de los cambios asegurando la calidad del producto.
Conclusiones del proyecto
Se expone el estado actual del proyecto, las conclusiones del mismo respecto a los objetivos planteados, las lecciones aprendidas y los pasos a seguir en el futuro.
Referencias Bibliogr´ aficas
Se enumeran las distintas referencias bibliogr´aficas consultadas para la elabo- raci´on de este documento.
Anexos
Se exponen los distintos anexos del presente documento.
2 Problema y soluci´ on
Es muy com´un que en el mundo del software, los clientes sepan que tienen un problema y creen que tienen la soluci´on pero que no sea realmente de esta manera.
Puede suceder que hayan identificado el problema pero no la soluci´on, o que quiz´as no hayan captado el problema real que tienen o intentan resolver.
El presente cap´ıtulo tiene como objetivos exponer el problema a resolver y los desaf´ıos identificados luego de considerar el contexto y el plan de negocios del cliente.
A su vez, se mencionar´an las principales decisiones tomadas en las fases tem- pranas del proyecto, las cuales posibilitaron que el resultado del mismo sea un producto acorde a las expectativas del cliente y funcional a las necesidades de los usuarios, resolviendo el problema existente.
2.1 El problema y su contexto
Seg´un un estudio realizado por Opci´on Consultores[9], en el ´ultimo tiempo se duplic´o la cantidad de gente que realiza compras online. Esto es algo esperable
debido a la situaci´on de pandemia y por otro lado, las personas optan por quedarse en la comodidad de sus casas y luego de unos cuantos clicks tener la ropa elegida y comprada.
Sin embargo, seg´un los estudios realizados por la consultora, el 86 % de las personas siguen yendo f´ısicamente a realizar las compras de ropa. Es ah´ı donde realmente uno puede probarse y ver f´ısicamente lo que se est´a eligiendo, reduciendo los posibles errores y productos que quiz´as no le gusten realmente.
Aunque la realidad es que las tiendas se han quedado un poco en el pasado, siempre hay que esperar por un empleado para hacer consultas sobre disponibilidad de talle y colores. La espera a ser atendidos tanto para consultas como para realizar una compra son problemas que a´un existen y no han sido atacados. Este tipo de comodidades surgen a partir de los e-commerce, en donde existe un acceso instant´aneo a toda esta informaci´on y la compra se realiza instant´aneamente.
A su vez, este nuevo formato de tienda permite que se pueda acceder a mas informaci´on acerca del comportamiento de los clientes. La ventaja m´as grande se encuentra cuando una persona entra a una p´agina, selecciona uno o varios productos pero, no concreta la compra, a´un as´ı se recogen datos sobre los pasos que el cliente tom´o y las prendas que seleccion´o. En una tienda f´ısica, las personas pueden elegir ropa y no concretar una compra, solo que en este caso, no se podr´a obtener informaci´on de lo que hab´ıa hecho este cliente.
Por otro lado en las tiendas, nunca se sabe bien que es lo que realmente quiere la gente y es muy com´un que pierdan clientes por falta de disponibilidad o falta de exposici´on. La muestra de ofertas o productos destacados se vuelve un problema tambi´en en las tiendas f´ısicas, mientras que en una p´agina web, normalmente se encuentran en el inicio, o tienen su apartado particular para esto.
Es por todo esto entonces que se puede decir que dentro del contexto de una tienda f´ısica, existen varios problemas a resolver.
Velocidad en que los clientes obtienen informaci´on con respecto a la disponi- bilidad del producto. Es muy com´un que las personas hagan consultas sobre productos que se presenten en la tienda, ya sea por talles, colores, o incluso directamente preguntar por algo que no saben si lo tienen. Adem´as de esto, no siempre hay una persona disponible que pueda atender.
Presentaci´on de productos recomendados, ofertas y promociones.
Falta de productos por la poca informaci´on que se maneja en una tienda f´ısica.
P´erdida de clientes para la tienda por no tener los productos que se solicitan.
Cantidad de tiempo que les lleva realizar una compra.
Informaci´on como datos del usuario o productos por los que se hacen con- sultas por la poca trazabilidad.
En resumen ser´ıa muy ´util contar con un asistente al cliente que est´e siempre disponible, que registre su comportamiento en la tienda y le haga sugerencias sobre ofertas, promociones, etc.
2.2 An´ alisis de interesados
La resoluci´on de este problema atrae tres posibles grupos de interesados. Para evaluar a estos es que se los coloca dentro de la siguiente matriz[10]:
Figura 2.1: Matriz de an´alisis de interesados
A continuaci´on se habla espec´ıficamente de cada interesado y se los ubica dentro de un cuadrante de la matriz.
Dentro de los stakeholders, el equipo tom´o como promotor mas importante a su cliente, Dualboot Partners LATAM. Es el interesado clave, ya que es quien define el nivel de ´exito del producto, por m´as que la relaci´on de confianza haya permitido un grado de autonom´ıa elevado. Para Dualboot Partners LATAM este proyecto puede ser el comienzo de su segundo producto propio, por lo que el inter´es es alto.
Considerando que tiene un nivel alto de poder, ya que es el que toma las decisiones y un nivel alto en inter´es ya que el producto es suyo, se ubica dentro del sector a gestionar atentamente.
Una segunda categor´ıa est´a conformada por los posibles clientes de este pro- ducto. Los due˜nos de las tiendas de ropas son quienes consumir´ıan el producto y podr´ıan solucionar todos estos problemas planteados previamente y de esta manera
aumentar la experiencia de compra in-store, obteniendo a su vez mucha informa- ci´on para seguir mejorando en este aspecto. Si bien son los posibles clientes del producto, tienen un poder bajo pero un inter´es alto, ya que van a ser los que lo utilicen. Es a ra´ız de esto que se ubican dentro del sector mantener informados.
Finalmente, el ´ultimo grupo de interesados son las personas que vayan a las tiendas de ropa f´ısicamente y hagan uso de este producto. Son ellos los que se beneficiar´ıan con una experiencia m´as entretenida pero por sobre todas las cosas, m´as sencilla y eficiente. Si bien principalmente son estas personas las que m´as uso le dar´an al producto, hoy en d´ıa tienen un inter´es bajo ya que no conocen al producto y un poder bajo ya que no tienen ninguna autoridad sobre el mismo. Es por esto que se ubican dentro del sector de monitorizar.
2.3 Desaf´ıos del proyecto
El principal desaf´ıo de este proyecto es brindarle una soluci´on a los problemas planteados, cumpliendo con los requisitos del cliente y entregando un producto en estado de pre-producci´on teniendo en cuenta que el mismo va a seguir siendo perfeccionado a futuro. El mismo estar´a en estado de pre-producci´on ya que va a ser una prueba para ver si el producto es viable t´ecnicamente y aceptado por los usuarios. No solo esto, sino que tambi´en van a hacer falta a´un m´as pruebas y continuar con el perfeccionamiento del mismo. A su vez, el mismo puede presentar errores no cr´ıticos una vez que se entregue.
El otro desaf´ıo muy importante tiene que ver directamente con el equipo. Si bien como se detalla en la presentaci´on, este ha trabajado junto y existe una muy buena relaci´on entre los integrantes m´as all´a de lo profesional, es una prueba para
corroborar como funcionan como equipo para posibles proyectos a futuro. Esta es la primera vez que el equipo se enfrenta al desarrollo de un producto de esta magnitud.
2.4 Proceso de selecci´ on de la soluci´ on
Partiendo de la base que el cliente quer´ıa implementar un espejo inteligente fue que se arm´o la soluci´on. Para informar al lector, se define como espejo inteligente a un espejo que gracias al uso del IOT (internet of things)[11] se conecta a internet para variados usos.
Inicialmente, el cliente no sab´ıa cual era el problema real, simplemente consi- deraba que las tiendas se hab´ıan quedado un poco en el pasado y cre´ıa que con este producto pod´ıa mejorar la experiencia en las tiendas.
La primera idea que surgi´o, si bien fue descartada r´apidamente por temas de costos, consist´ıa en que el espejo fuese un probador virtual y donde la persona sin necesidad de probarse, pudiera ver como le quedaba.
Luego al equipo se le ocurri´o que el espejo funcionara parecido a como funciona un e-commerece en donde se muestran cat´alogos, se pueden seleccionar y realizar compras desde ah´ı. Esta idea surgi´o de la investigaci´on de productos similares los cuales se describen en el cap´ıtulo 4 Ingenier´ıa de requerimientos . Aqu´ı fue el cliente quien crey´o que no era una buena idea, primero, porque era un proceso complejo, para el comprador, que llevaba tiempo y la idea es que fuera algo simple, adem´as el espejo perder´ıa la funcionalidad original del mismo, reflejar. Por otro lado, no agregar´ıa valor a la tienda, ser´ıa como tener una tienda dentro de otra.
Fue a ra´ız de esto que, se realizaron la entrevista y la encuesta en la cual se
puede ver m´as informaci´on en el cap´ıtulo de 4.1 Relevamiento , y haciendo uso de toda la informaci´on obtenida es de donde surge la soluci´on. El motivo del uso de estas t´ecnicas es que se aplican sobre los posibles interesados y van a ayudar a descubrir el problema real, tanto para los usuarios que hagan uso del espejo como los due˜nos de las tiendas.
Es en base al resultado de las actividades mencionadas previamente que surge la soluci´on que se mostrar´a a continuaci´on.
2.5 Soluci´ on
La soluci´on implementada tiene como fin resolver el problema anteriormente planteado, dentro del contexto especificado, teniendo como objetivo la mejora de experiencia de compra in-store y, brindar la mayor cantidad de informaci´on posible a los due˜nos de estas tiendas para que, los mismos est´en preparados y sepan como se maneja un usuario que va a una tienda f´ısicamente.
Smart Mirror permite solucionar todos estos problemas en donde no solo se ve beneficiado el due˜no y empleados de la tienda sino el cliente que va a la misma.
Esta soluci´on consta de 3 plataformas distintas
Espejo: El centro del producto. El mismo es ubicado en las tiendas de ropa donde los clientes de las tiendas interact´uan con el para escanear prendas, consultar por su disponibilidad, realizar una compra, ver las publicidades y productos recomendados de la tienda.
Portal administrador: Este no solo permite personalizar el layout del es- pejo a gusto de cada cliente, como por ejemplo la publicidad, sino tambi´en
es el que brinda toda la informaci´on obtenida de la interacci´on del cliente a trav´es del espejo, desde prendas escaneadas a compras realizadas, as´ı tam- bi´en como la elecci´on de productos recomendados y publicidad a mostrar.
Es utilizado por los empleados o due˜nos de las tiendas de ropa.
Aplicaci´on de usuarios: A trav´es de esta los cliente de las tiendas pueden ver su historial de compras y productos recomendados de todas las tiendas que hagan uso del producto. La misma esta disponible solo para dispositivos m´oviles.
La idea del portal administrador surge principalmente de la entrevista, fue gracias a ella que, el equipo vio como se pod´ıa aprovechar la oportunidad de la implementaci´on del espejo para darle a´un m´as valor aportando informaci´on y customizaci´on del espejo.
El uso de un espejo es una restricci´on dictada por el cliente, que con la entrevista y la encuesta se pudieron evaluar las funcionalidades que se necesitaban realmente.
La aplicaci´on de los usuarios surge principalmente de la encuesta en donde se resalta que el acceso a ofertas y promociones no es muy visible y la falta de un historial de compras.
Cabe destacar que el equipo decidi´o ubicar al espejo en la parte de la tienda donde se encuentra toda la ropa para que todas las personas que pasen puedan verlo e interactuar con ´el.
El equipo en un momento consider´o ubicarlo dentro de los probadores en don- de se pueden atacar otros posibles problemas, pero resolvi´o que como prueba de concepto inicialmente se ubicar´ıa en la zona general de la tienda porque no solo se
crey´o que las tiendas tendr´ıan que hacer una inversi´on m´as grande porque tendr´ıan que comprar m´as de un dispositivo, sino que tambi´en los clientes de las tiendas pod´ıan verse intimidados de que este producto pudiera estar film´andolos mientras se cambian.
De m´as est´a decir que el producto est´a preparado para ubicarse en cualquier de los dos lugares y es decisi´on final de la tienda ver donde ubicarlo.
En resumen, lo importante es mostrar m´as informaci´on. Mostrar informaci´on de la tienda a su cliente e informaci´on de la tienda a su cliente. El equipo cree que esto puede generar un circulo virtuoso donde todos se vean beneficiados. Otro beneficio a destacar, es que gracias a esta disponibilidad que se le brinda a los clientes de las tiendas, estos pueden completar sus procesos de compra de ma- nera mas r´apida y eficiente. De mas est´a decir que, en caso de ser un producto exitoso, Dualboot Partners LATAM se ver´a beneficiado tanto con prestigio como retribuci´on econ´omica.
Para ver un resumen de la prueba realizada por el equipo en una tienda de ropa se puede hacer click aqu´ı.
3 Marco metodol´ ogico
Ya con los objetivos establecidos en la secci´on 1.3 Objetivos , el siguiente cap´ıtulo pretende exponer las distintas metodolog´ıas y herramientas utilizadas en el proyecto con el fin de alcanzar dichos objetivos. Se mostrar´a el motivo de selecci´on de las metodolog´ıas y herramientas, haciendo un enfoque mayor en las que marcaron un camino clave a la hora del desarrollo del proyecto. Previo a la elecci´on de las metodolog´ıas y herramientas, es de suma importancia especificar las caracter´ısticas del proyecto y del equipo, con el fin de elegir las metodolog´ıas y herramientas que m´as se adec´uen a la situaci´on.
3.1 Caracter´ısticas del proyecto
A la hora de analizar el motivo de las decisiones que fueron tomadas por el equipo a lo largo del proyecto, es clave tener en cuenta las particularidades del proyecto ya que, las mismas fueron factores que influyeron a la hora de elegir el marco metodol´ogico.
A continuaci´on detallamos las caracter´ısticas m´as relevantes:
3.1.1 Fase de desarrollo
Si bien se defini´o al principio del proyecto que al final del mismo se ten´ıa que entregar un MVP(minimum viable product), el mismo iba a constar de aspectos que lo hacen terminar en una fase de pre-producci´on, es decir, que no es una versi´on final. Estos aspectos est´an relacionados a restricciones econ´omicas en el hardware ya que primero se desea validar que la idea sea ´util para luego ir mejor´andolos si la soluci´on prospera y se consigue posibles clientes que financien dicha mejora.
Por otra parte, se cree que el producto tendr´ıa que tener una etapa de prueba en una tienda en donde la misma funcione por varios d´ıas con ´este incorporado para realmente validar que es ´util. Finalmente, se aceptan peque˜nos bugs y la infraestructura puede no ser final. Se aceptar´an hasta 5 errores menores y 3 errores medios.
3.1.2 Surge de una idea
Un aspecto no menor en cuanto al producto es que el cliente propuso al equipo una idea y no un problema a solucionar, por lo que fue necesario hacer hincapi´e en el etapas de definici´on e investigaci´on para poder definir el problema y la soluci´on.
3.1.3 Cliente t´ ecnico
Un aspecto a tener en cuenta es que el cliente es una empresa de software la cual cuenta con una gran cantidad de desarrolladores que tienen conocimientos t´ecnicos en un espectro grande de tecnolog´ıas por lo cual el equipo contaba con dicho respaldo t´ecnico de ser necesario. A su vez, result´o a´un m´as sencilla la comunicaci´on
cuando se hablaba de temas m´as t´ecnicos, gracias al conocimiento del cliente en este aspecto. Si bien no se hizo uso de los l´ıderes t´ecnicos de a empresa, siempre fue una seguridad para el equipo saber que contaba con ellos.
3.1.4 Requerimientos funcionales cambiantes
Dada la naturaleza del proyecto, el cambio en los requerimientos funcionales fue un aspecto a tener en cuenta. Como el cliente lleg´o con una idea y no con un problema espec´ıfico, era de esperar que los requerimientos funcionales vayan cambiando a lo largo del proyecto. Es bueno destacar que dicha caracter´ıstica no repercute ´unicamente en lo que es el proyecto, sino que tambi´en en el equipo, ya que debe ser capaz de mantener una actitud positiva, desechar progreso y volver a enfocarse en realizar los cambios establecidos, con el fin de lograr un mejor producto y satisfacer al cliente.
3.2 Caracter´ısticas del equipo
Las caracter´ısticas del equipo son otro gran factor a la hora de elegir la me- todolog´ıa de trabajo a utilizar, por lo que a continuaci´on se proceder´a a listar las principales.
3.2.1 Buen relacionamiento entre los integrantes
Antes de comenzar el proyecto, los tres integrantes del equipo ya contaba con un estrecha relaci´on tanto laborar como extra laboral la cual al correr del mismo se
fue afianzando a´un m´as, manteniendo as´ı un clima de trabajo muy bueno. Adem´as en cuanto lo que compete a lo laborar, el equipo en su totalidad se encontr´o en su mayor´ıa trabajando en una misma empresa y hasta incluso siendo parte de un mismo proyecto, lo cual les permiti´o crecer como profesionales a la par.
3.2.2 Experiencia previa trabajando juntos
El equipo ten´ıa ya experiencia realizando todos los obligatorios en los cuales se permit´ıa un grupo de tres integrantes durante toda la carrera. A su vez como se mencion´o anteriormente, los mismos tambi´en compartieron equipos de trabajo en el ´ambito laboral. Esto permiti´o que cada uno supiera cuales eran las principales virtudes y debilidades de los integrantes, pudiendo as´ı realizar una planificaci´on acorde a las mismas.
3.2.3 Progreso en la carrera
El equipo en su totalidad luego de culminar el proyecto y si el mismo alcanza los objetivos deseados, obtendr´a el t´ıtulo profesional lo cual genera una motivaci´on extra y a su vez, aporta seguridad a los integrantes el saber que todos tienen la experiencia necesaria para poder cumplir con sus tareas.
3.2.4 Sentimiento de obligaci´ on de hacer un ex- celente proyecto
Como ya fue mencionado previamente, debido a que este proyecto se trata de la tesis de grado de los integrantes del equipo, se acord´o que es de primordial importancia arribar a una soluci´on excelente desde el punto de vista acad´emico, construida a trav´es de un proceso ordenado y eficiente.
3.3 Roles del equipo
Con el fin de mantener una gesti´on de trabajo organizada, se decidi´o definir roles para cada miembro del equipo, teniendo en cuenta virtudes, experiencia y preferencias de los integrantes del mismo:
Project Manager : Rafael Torre.
Analista de requerimientos: Germ´an Garc´ıa.
L´ıderFrontend : Rafael Torre.
L´ıderBackend : Rafael Torre.
L´ıderMobile: Rodrigo Pisani Devops: Germ´an Garc´ıa Dise˜nador: Rodrigo Pisani Arquitecto: Germ´an Garc´ıa
Encargado de la calidad: Rodrigo Pisani
3.4 Metodolog´ıas de desarrollo
3.4.1 Ciclo de vida del proyecto
Debido a las caracter´ısticas del proyecto y del equipo mencionadas anterior- mente, es que se opt´o por utilizar el ciclo de vida incremental e iterativo [12].
Figura 3.1: Ciclo de vida incremental e iterativo
Como se puede apreciar en la figura, el mismo consiste en repetir una serie de actividades, incrementando en cada versi´on el estado del producto final. Dichas actividades se repiten en conjunto, las veces que sean necesarias para cubrir la totalidad de funcionalidades del producto. Con dicho ciclo el cliente va obteniendo incrementos del producto con avances progresivos lo que permite que encontrar discrepancia y errores en las mismas lo m´as temprano posible con el fin de no com- prometer a las funcionalidades que dependen de las desarrolladas anteriormente.
Una de las principales razones de esta elecci´on esta relacionada con la carac- ter´ıstica ya conocida del proyecto que establece que los requerimientos pueden ser cambiantes. Trabajando de este modo se puede bajar el riesgo que esto genera al proyecto, dado que, adem´as de que la etapa de an´alisis se realiza repetidas veces, las entregas progresivas ayudan al cliente a visualizar la aplicaci´on, logrando as´ı poder visualizar y validar la correctitud de las funcionalidades antes de finalizar la totalidad del producto.
Por ´ultimo pero no menos importante, el equipo consider´o que la forma de trabajo en iteraciones cortas en las cuales se va pasando por todas las diferentes etapas tiene varios beneficios. Uno de ellos es que dada la poca experiencia del equipo tanto en algunas de las tecnolog´ıas a trabajar como, en la gesti´on de pro- yecto, esta modalidad de trabajo permite ir aprendiendo de los aciertos y errores en cada versi´on y mejorando sobre la marcha. Otro aspecto importante es que, en el caso de que pueda surgir alg´un imprevisto o desv´ıo inesperado, gracias a las iteraciones cortas se puede retomar el camino correcto de forma inmediata, minimizando el impacto de los mismos en el proyecto.
3.4.2 Scrum
En esta secci´on se presentar´a lo que es la metodolog´ıa ´agil Scrum[6], explicando los motivos que llevaron al equipo a incorporar dicha metodolog´ıa para la gesti´on del proyecto en lo que refiere a la aplicaci´on m´ovil , el portal administrador y el Backend Core ya que para el espejo en si mismo, el equipo decidi´o inclinarse por otra metodolog´ıa la cual ser´a explicada m´as adelante.
Scrum es un marco de trabajo para el desarrollo ´agil de software que combi- na buenas pr´acticas para trabajar colaborativamente y obtener el mejor resultado posible en proyectos. La principal idea que adopta esta metodolog´ıa es definir una estrategia de desarrollo incremental, en lugar de la planificaci´on y ejecuci´on com- pleta del producto. Este desarrollo incremental permite, en peque˜na iteraciones, agregar caracter´ısticas al producto que sean de valor para el usuario final, a medida que se responden a requerimientos cambiantes.
Figura 3.2: Metodolog´ıa Scrum[13]
Dicha metodolog´ıa como toda metodolog´ıa ´agil, responde a los principios que est´an definidos en el manifiesto ´agil[14].
Dada la naturaleza del proyecto, el equipo decidi´o adaptar ciertos aspectos de Scrum ya que sinti´o que los mismos no se adecuaban al proyecto. Las adaptaciones m´as relevantes realizadas son las siguientes:
3.4.2.1 Duraci´ on de los sprints
El equipo decidi´o que en la etapa de desarrollo los sprints tendr´ıan una duraci´on de dos semanas porque se consider´o que era un tiempo prudencial para agregar valor al producto en cada una de estas iteraciones.
3.4.2.2 Backog inicial
El equipo decidi´o realizar una estimaci´on y un backlog al inicio del proyecto con el fin de, visualizar y validar si el alcance del proyecto era lo suficientemente profundo para un equipo de 3 personas obtengan su t´ıtulo de grado.
3.4.2.3 Dailies
En cuanto a estas reuniones que establece Scrum, el equipo decidi´o que las mismas no eran necesarias ya que, dada la relaci´on entre los mismos y la experiencia trabajando juntos, la comunicaci´on exist´ıa diariamente mediante Whatsapp o cara a cara por lo cual, no era necesario definir un momento del d´ıa en espec´ıfico para hacerlo.
3.4.2.4 Retrospectivas
Aunque al principio del proyecto se comenz´o realizando la ceremonia al final de cada sprint como se especifica en la metodolog´ıa, las mismas resultaron poco productivas debido a la gran confianza que existe entre los integrantes del equipo, se decidi´o no establecer una retro al final de cada sprint ya que las incomodidades o aspectos a corregir eran hablados cuando se detectaban y no era necesario esta- blecer una reuni´on espec´ıfica para hablar sobre aspectos que se hicieron bien o a mejorar iteraci´on a iteraci´on. Sin embargo, se hicieron retrospectivas cada dos ite- raciones para establecer instancias formales de conversaciones. Las reuniones fue- ron realizadas en la herramienta retro.io [15]. Dicha herramienta provee un board con tres columnas:Went well (cosas que se hicieorn bien),To improve(aspectos a mejorar)y Action items(acciones a tomar) las cuales facilitan el desarrollo de este tipo de ceremonias.
Figura 3.3: Evidencia Retro.io - Retrospectiva
3.4.2.5 Uso de un Proxy Product Owner
Adopta parte de las responsabilidades que habitualmente desempe˜na un Pro- duct Owner como recoger las necesidades de los clientes, estructurar y priorizar el Backlog de producto, negociar con el equipo la realizaci´on del Backlog y validar cuando el producto est´a listo para ser entregado a los clientes.
Una de las carencias de este rol en comparaci´on con el de Product Owner es que el mismo no es el due˜no del producto, por lo que no toma las decisiones fundamentales ni suele ser responsable de su resultado ni tampoco controla el presupuesto. Si bien se introdujo este nuevo rol, el mismo no fue remplazando al de Product Owner, la intenci´on fue poder liberar la carga que llevaba el mismo y as´ı continuar con el desarrollo del producto en tiempo y forma. A su vez, el cliente tiene confianza en el equipo. Esto otorg´o mucha libertad en la toma de decisiones y facilidad para establecer contacto.
3.4.2.6 Planning
Dado a que el equipo ya hab´ıa realizado una estimaci´on inicial del proyecto, estas reuniones no fueron tal cual la metodolog´ıa indica, debido a que parte del
trabajo ya se hab´ıa definido anteriormente. Igualmente, el equipo decidi´o realizar las reuniones a principio de cada sprint en las cuales se utiliz´o la t´ecnica Poker Planning[5] con la escala Fibonacci[16] con el fin de hacer una estimaci´on m´as exhaustiva sobre lo ya planificado y tambi´en proceder a estimar los cambios que hayan surgido con respecto al plan inicial. Se decidi´o usarde escala Fibonacci[16]
ya que, brinda a los equipos una forma m´as realista de abordar las estimaciones utilizando puntos de la historia.
Los puntos de historia se utilizan para representar el tama˜no, la complejidad y el esfuerzo necesarios para completar o implementar una historia de usuario. A cada punto de la historia se le asigna un n´umero en la escala de Fibonacci. Cuanto mayor sea el n´umero, m´as complejo ser´a el punto de la historia y, presumiblemente, la cantidad de esfuerzo que llevar´a completarlo.
Cabe destacar que si bien Scrum recomienda que el valor de los story points se ajuste org´anicamente durante el comienzo del proyecto, el equipo decidi´o ajustar estos valores previo al primer sprint planning. Esto fue debido a que por la relati- vamente corta duraci´on de la etapa de desarrollo del proyecto, no se crey´o que se iba a tener m´etricas confiables en cuanto a la velocidad del equipo.
Dentro de la escala de Fibonacci se decidi´o que el 13 ser´ıa la estimaci´on de un sprint de un desarrollador A su vez, si bien exist´ıan estimaciones iniciales, las mismas fueron cambiando a medida que la etapa de desarrollo avanzaba, gracias a los conocimientos adquiridos a lo largo del proyecto.
3.4.2.7 Releases
En cuando a este aspecto, el cliente decidi´o que no era necesario realizar relea- ses. Igualmente, el equipo decidi´o establecer 2 reuniones formales de demostraci´on
del progreso y funcionalidades que ya se ten´ıan desarrolladas con el fin de tener un mayor orden y no depositar todo en una entrega final. Sin embargo, se decidi´o hacer demostraciones informales de las funcionalidades desarrolladas, con el fin de obtener feedback temprano y en caso de haber cambios, tener el menor impacto posible.
3.4.3 Roles
En cuanto a los roles relacionados a Scrum se definieron los siguientes:
Product Owner : El cliente fue quien comenz´o asumiendo este rol, sin em- bargo en el transcurso del proyecto advertimos que no se estaba cumpliendo seg´un lo esperado, por lo que se defini´o que Germ´an Garc´ıa tome el rol de Proxy Product Owner.
Scrum Master : Rafael Torre fue quien asumi´o este rol, gestionando el proceso Scrum y asegur´andose de que el equipo funcione de manera correcta logrando as´ı los objetivos planteados.
Desarrolladores: Rol asumido por los tres integrantes del equipo.
Artefactos
En cu´anto a los artefactos de Scrum, el equipo decidi´o trabajar con los siguien- tes:
Product Backlog : Listado din´amico de todas las historias de usuario a incluir en el proyecto. Las mismas fueron especificadas como User Stories previo a realizar la fase de desarrollo. Durante el transcurso del proyecto se
fueron agregando o quitando algunas, con el objetivo de ampliar el alcance o modificarlo, todo esto con el fin de entregar el mejor producto posible.
El listado de User Stories se puede encontrar en el anexo 11.3 Requerimien- tos funcionales .
Sprint Backlog : Listado de historias de usuario extra´ıdas del Product Bac- klog, seleccionadas a implementar en la siguiente iteraci´on. La selecci´on se hizo en la Sprint Planning, teniendo en cuenta tanto la prioridad de las mismas como tambi´en mantener una asignaci´on balanceada entre los desa- rrolladores.
Producto incrementado: Incremento del producto que se obtuvo al fina- lizar cada sprint.
Tablero Scrum : Para el seguimiento de las tareas utilizamos la herramienta Jira, ya que es una herramienta que el equipo domina y brinda las funcio- nalidades necesarias cubrir todos los aspectos requeridos en este proyecto. A continuaci´on se muestra un ejemplo de lo que fue el board del sprint 3
Figura 3.4: Board en Jira del sprint 3
A la hora de realizar la Sprint Planning se analizaron las tareas del sprint que estaba transcurriendo que no se encontraban en Done a´un, las cuales se volv´ıan a estimar y priorizar para ver si ir´ıan a formar parte de la pr´oxima iteraci´on.
3.4.4 Dual Track Agile
Figura 3.5: Etapas definidas por Dual Track Agile[17]
Como se menciona anteriormente, para el desarrollo del software del espejo no se siguieron las pautas de Scrum. Dada la poca informaci´on que el equipo ten´ıa acerca de las funcionalidades que iba a tener el espejo, y la poca experiencia en dise˜no, a´un m´as en pantallas grandes, se decidi´o utilizar la metodolog´ıa Dual Track Agile[18] la cual tiene como principal ventaja la existencia de dos carriles paralelos.
Estos permiten ir iterando tanto en la parte de desarrollo como en la parte de dise˜no a la vez. El comienzo de la metodolog´ıa parte de una instancia de dise˜no, en donde luego a la hora de desarrollar se trabaja sobre esa salida del proceso de dise˜no, mientras que el dise˜no itera nuevamente.
Estos carriles son, como se puede apreciar en la imagen anterior, el de dise˜no y el de desarrollo. Cabe destacar que la metodolog´ıa habla de dos carriles y no
de dos equipos diferentes, lo cual genera una interacci´on entre las personas de los diferentes carriles, permitiendo as´ı intercambiar ideas para definir un producto m´as completo y uniforme.
Debido a que el equipo es peque˜no todos los integrantes del mismo participaron en los dos carriles a lo largo del proyecto.
Dicha distinci´on de carriles, permiti´o al equipo no trancar el desarrollo por falta de investigaci´on y definici´on, sino, una vez que el mismo consigui´o obtener una primera versi´on se comenz´o a iterar mientras se segu´ıa puliendo el producto.
La imagen que se muestra a continuaci´on, ejemplifica el proceso que se realiza en el carril de dise˜no. En el mismo se parte de un dise˜no base, el cual indic´o el inicio del desarrollo, pero luego gracias al trabajo del equipo de investigaci´on y dise˜no, la funcionalidad va mutando, pasando por diferentes etapas hasta llegar a la etapa final.
Estos redise˜nos fueron fruto de un arduo trabajo que, de no haber usado dicha metodolog´ıa hubieran trancado al desarrollo. Este ejemplo muestra el motivo y la gran ventaja que el equipo obtuvo a la hora de usar Dual Track Agile frente a otro tipo de metodolog´ıa.
Figura 3.6: Cambios en la pantalla de una prenda de Smart Mirror
3.5 Etapas del proyecto
A continuaci´on se detallan las distintas etapas del proyecto en relaci´on con el tiempo.
Figura 3.7: Etapas del proyecto
Debido a que el cliente lleg´o con una idea y no con un problema y soluci´on clara, el equipo decidi´o dedicar los primeros 4 meses a investigar y definir el problema
para luego concluir en una posible primer soluci´on. En esta primer etapa, a su vez se hizo toda la fase de ingenier´ıa de requerimientos, para definir el alcance del producto, el an´alisis de riegos junto a todo lo que conlleva, el armado del plan de calidad y adem´as se realiz´o el an´alisis y la definici´on de la arquitectura.
Luego de finalizada esta etapa, es que comienza el desarrollo, en donde se pro- cede con la implementaci´on de la aplicaci´on. Cabe destacar que debido al uso de la metodolog´ıa Dual Track la fase de investigaci´on y dise˜no no culmin´o ya que el equipo sigui´o investigando y redise˜nando el sistema con el fin de lograr un mejor producto. Adem´as, al hacer uso de metodolog´ıas ´agiles, ciertas etapas de la inge- nier´ıa de requerimientos como la especificaci´on, validaci´on y, hasta relevamiento, suceden reiteradas veces en la etapa de desarrollo.
Finalmente, se pasa a la etapa de documentaci´on, en la cual el equipo se dedic´o a la elaboraci´on de este documento acad´emico.
Como se puede apreciar, la etapa de gesti´on, es una etapa que persisti´o a lo largo de todo el proyecto dado que al trabajar con metodolog´ıas ´agiles siempre se est´a abierto a cambios y esos cambios deben ser gestionados.
3.5.1 Definici´ on del problema y la soluci´ on t´ ecni- ca
Se trata de la primera etapa del proyecto, en primer lugar el equipo realiz´o investigaciones tanto del contexto del problema como de aplicaciones similares que exist´ıan en el mercado. A su vez, el equipo decidi´o investigar en patrones y buenas practicas relacionados con dise˜nos en pantallas grandes y t´actiles ya que, era un aspecto importante para el desarrollo del mismo, y los integrantes no ten´ıan ning´un tipo de experiencia en este rubro.
Esto fue de gran utilidad para comprender tanto los requerimientos del cliente tanto como la necesidad de los potenciales clientes de la soluci´on.
Luego de definir el problema, se procedi´o a definir los procesos de trabajo y atacar la soluci´on del mismo y con el fin de definir una primera versi´on base con la cual comenzar el desarrollo.
3.5.2 Etapa de desarrollo
Partiendo del resultado de la etapa anterior, el equipo procedi´o a comenzar con la etapa de desarrollo. En la misma se trabaj´o usando Scrum y Dual Track Agile con algunas adaptaciones para que se ajuste mejor a las caracter´ısticas del proyecto, como fue mencionado anteriormente. El resultado de esta etapa fue el c´odigo fuente de la soluci´on desplegado en un ambiente productivo.
3.5.3 Etapa de documentaci´ on
La misma comenz´o al final del proyecto cuando ya se ten´ıan las funcionalidades desarrolladas y un producto armado. Se le dedic´o una buena parte del tiempo ya que resulta muy importante para poder cumplir con los objetivos establecidos. En esta etapa se sintetiz´o todo el material recavado y aprendizajes adquiridos a lo largo del a˜no.
3.5.4 Etapa de Gesti´ on
Es la etapa m´as larga del proyecto ya que es la encargada de dirigir, marcar y guiar al resto de las etapas del proyecto. La correcta realizaci´on de dicha etapa es clave para obtener buenos resultados. Consta de una basta cantidad de actividades las cuales van a ser descritas m´as adelante en este documento.
Si bien se indica como una sola etapa, se puede definir como una cadena de micro-etapas donde cada una tiene su entrada (casi siempre la salida de la anterior) y una salida tangible.
3.6 Conclusiones
El equipo piensa que fue fundamental adaptar las metodolog´ıas a las necesida- des del proyecto, teniendo as´ı en cuenta el contexto en el que se encontraban y las caracter´ısticas propias del proyecto y del equipo.
La etapa de investigaci´on fue un aspecto clave en el proyecto ya que permiti´o definir un problema y trabajar en una posible soluci´on de una forma m´as guiada y ordenada. El equipo cree que la elecci´on de la metodolog´ıa Dual Track Agile fue necesaria para lograr un producto de mayor calidad ya que, permiti´o extender la etapa de investigaci´on y dise˜no sin tener que ponerle un fin prematuro para comenzar con el desarrollo.
En cuanto a la etapa de desarrollo, la elecci´on de la metodolog´ıa Scrum fue de gran ayuda para lograr un producto de forma incremental e ir aceptando cambios como filosof´ıa, ya que dada la naturaleza del proyecto, la existencia de cambios era algo que se ten´ıa que asumir.
Por ´ultimo pero no menos importante, haber mantenido el foco en la gesti´on durante todo el transcurso del proyecto, permiti´o tener orden, un accionar frente a situaciones de riesgo y sobre todo, un plan a seguir en las distintas etapas del proyecto.
A su vez, la asignaci´on de roles tanto transversales como de Scrum permitieron tener una experiencia valiosa que sirvi´o de aprendizaje para el resto de las carreras profesionales de los integrantes del equipo.
4 Ingenier´ıa de requerimientos
Esta etapa dentro de cualquier proceso de desarrollo de software es de las m´as importantes. La principal raz´on es porque en la mayor´ıa de los casos, el cliente no sabe exactamente que es lo que quiere, sino que viene con un problema y algo que puede considerar su soluci´on. Es responsabilidad del equipo llevar a cabo un proceso en el cual se relevar´an, validar´an y especificar´an los requerimientos del sistema, para de esta manera poder resolver el problema planteado.
Algo muy importante a destacar es que, para este proyecto, este proceso se realiz´o inicialmente en su totalidad y luego durante las iteraciones ocurri´o par- cialmente. Para el caso de las iteraciones, las partes en las que se hizo hincapi´e de este proceso fueron las reuniones con el cliente, validaci´on y especificaci´on. En algunos casos incluso se repite la etapa de relevamiento, donde surgieron nuevas funcionalidades, principalmente de las pruebas con usuarios.
La forma en que se implement´o este proceso se detallar´a a continuaci´on.
4.1 Relevamiento
Desde la primera reuni´on con el cliente, el equipo supo que el objetivo del producto era mejorar la experiencia de compra in-store, mediante el uso de un espejo inteligente. Se tuvo un concepto desde el cual empezar, pero sin tener un problema espec´ıfico a solucionar.
Para ser m´as espec´ıficos, no se sab´ıa en qu´e lugar de la tienda iba a ir el espejo, ni que se esperaba del mismo.
Para poder encontrar el problema, se utilizaron varias t´ecnicas de relevamiento de requerimientos las cuales se presentan a continuaci´on.
4.1.1 Reuniones con el cliente
La primer instancia de reuni´on con el cliente fue antes de inscribirse en la tesis en donde se le consult´o si ten´ıa alguna idea que quisiera implementar y si la misma pod´ıa ser el proyecto final del equipo.
Hubo varias instancias de reuniones previo a la asignaci´on de proyecto para sa- ber que se iba a hacer y que el mismo fuera aprobado por la Universidad ORT. La t´ecnica utilizada en estas reuniones era brainstorming, en donde tanto los integran- tes del equipo como el cliente intercambiaban ideas para determinar las posibles funcionalidades.
Una vez asignado el proyecto existieron m´as instancias de reuniones, tanto con el cliente como internas, en donde al finalizar cada una se conversaba para ver el alcance, viabilidad y utilidad de lo propuesto hasta que se lleg´o a una serie de requerimientos los cuales se plantearon al cliente y al tutor.
