| Identificación
|-----------
| Fundamentos de Ingeniería de Software M4A
| Docente: Alejandro Adorjan
| Integrantes: Emiliano Yozzi, Franco Thomasset, Daniela Waldeck

03/05/2021

https://github.com/ORT-FIS-202103/proyecto_1-grupo-2

# Repositorio Git

## Creación y uso de repositorios locales y remotos
A partir del repositorio dado, cada integrante del equipo generó un repositorio local usando el comando git clone (url).

Cada integrante trabajará localmente e irá actualizando los cambios en el repositorio remoto.

## Comandos Git ejecutados desde terminal y desde el IDE
Nosotros optamos por trabajar desde la terminal de Visual Studio Code y utilizamos los siguientes comandos:

| Comando | Función |
| -------- | -------- |
| git clone (url) | Clonar el repositorio remoto en forma local. |
| git branch 'name' | Genera una nueva rama con el nombre indicado. |
| git checkout 'name' | Nos posiciona en la rama indicada. |
| git add . | Agrega los archivos que fueron modificados al staging area (los habilita para ser commiteados)|
| git commit -m 'message' | Graba los cambios aplicados a los archivos en el repositorio local agregando un mensaje que sintetiza dichos cambios. |
| git push -u origin 'branch name' | Actualiza el repositorio remoto, guardando los cambios hechos en la rama especificada. |
| git pull | Actualiza el repositorio remoto, descargando los cambios |
|git status|Muestra el estado del repositorio remoto y del staging area|

# Versionado
## Buenas prácticas de versionado
Utilizar mensajes de commit claros y concisos escritos en inglés. En cada commit aclarar si se está agregando, cambiado, arreglando o quitando información utilizando las palabras: *add*, *change*, *fix* y *remove* antes de definir el cambio.

No es recomendable trabajar directamente sobre la rama 'main'. Es preferible trabajar sobre ramas secundarias y al tener una versión estable, agregar los cambios al main.

## Uso de ramas separadas de 'main'
Decidimos trabajar sobre una rama secundaria llamada develop para agregar cambios sin afectar al main. Solo hacemos modificamos la rama principal "main" al tener una versión estable del proyecto. Consideraremos que una versión es estable cuando todas las secciones trabajadas están completas.

## Resumen de commits y evolución del proyecto
| commit add | commit remove |
| ---------- | ------------- |
|| |

# Elicitación

## Evidencia de actividades de investigación
Como actividades de investigación utilizamos:
* Entrevistas
* Workshop
* Ingeniería inversa

**Entrevistas:**

La entrevista permite tener un diálogo más fluido y respuestas más extensas y personales.
Dado que nuestro público objetivo son las personas mayores, consideramos que esta es la mejor técnica de elicitación para llegar a ellas. Por otro lado, también es útil entrevistar a personas relacionadas con este rubro (en nuestro caso, verduleros) para conocer las modalidades de venta, necesidades y cualidades de sus clientes.

Conclusiones entrevista posibles clientes:

El primer aspecto importante resaltado por los entrevistados es la accesibilidad. Las personas mayores se suelen confundir con íconos ya que no tienen un significado claro y resaltan que solo la usarían en caso de que sea fácil de usar, esto fue tomado en cuenta al momento de definir los requerimientos. Algo a considerar es que muchas veces los entrevistados prefieren el supermercado como lugar para adquirir sus frutas y verduras en lugar de la verdulería, es probable que esto reduzca nuestro número de clientes de manera importante.
Los entrevistados además dijeron que preferirían elegir los productos ellos mismos, solo en un caso, dejarían que el verdulero elija los productos siempre y cuando, se tomen en cuenta sus preferencias a la hora de elegir: la aplicación debería tener un lugar para expresarlas.
Dos de los tres entrevistados dijeron que usarían nuestra aplicación si se cumplen estos aspectos.

Conclusiones entrevista verduleros:

Todos los entrevistados ya reciben pedidos a domicilio a través de WhatsApp o teléfono. Algunos habían usado Pedidos Ya! pero dejaron de hacerlos por las altas comisiones. Lo que implica que nuestra aplicación tiene que ser lo suficientemente útil y comercialmente interesante para ellos para que cambien su sistema actual de recepción de pedidos.

Afortunadamente sus clientes suelen ser personas mayores, lo cual coincide con nuestro público objetivo y los métodos de pago más relevantes son el débito y el efectivo.
A pesar de esto ninguno de los entrevistados se veía entusiasmado por la adopción de nuestra aplicación, a algunos les parecía que sus clientes no la usarían y a otros directamente les parecía redundante.

Conclusiones generales de las entrevistas:

Nuestra aplicación no cuenta con el apoyo de los verduleros y nuestros potenciales clientes también muestran un poco de rechazo a su uso, pidiendo muchas condiciones para que les sea de utilidad.
En base a las entrevistas concluimos que con un excelente diseño y mucha accesibilidad el proyecto podría funcionar pero no será tarea fácil.

[Ver transcripción de entrevistas](https://github.com/ORT-FIS-202103/proyecto_1-grupo-2/blob/develop/investigacion/Entrevistas/Entrevistas.pdf)

**Workshop:**

Al tener como público objetivo a las personas mayores, es importante asegurarnos de que la aplicación resulte sencilla y fácil de usar.
Para esto, desarrollamos prototipos en papel para simular los diferentes casos de uso y generamos instancias con posibles usuarios para observar su interacción con los diseños.

El workshop sirvió para ver un posible cliente usando la App por primera vez, la persona tuvo dificultades para ir avanzando por las pantallas pero pudo realizar un pedido exitosamente. El problema ocurrió cuando quiso agregar más objetos a la compra.
Nos sugirió que el botón que permite hacer esto sea más grande. A la persona le agradó la opción de elegir las verduras por Kg o por cantidad.


**Ingeniería inversa:**

La técnica de ingeniería inversa consta de analizar aplicaciones existentes para identificar requerimientos funcionales a imitar y problemas o limitantes a evitar o resolver en nuestro diseño.

<img src="https://upload.wikimedia.org/wikipedia/commons/c/c5/Isologotipo_PedidosYa.jpg" alt="Isologotipo_PedidosYa" width="100" />

En nuestro caso, analizamos como potencial competidor a **Pedidos Ya!**, aplicación que incluye un módulo de pedidos de frutas y verduras en su plataforma. Ésta no es la única funcionalidad de la app, la misma también permite hacer pedidos a restaurantes (funcionalidad principal), supermercados, farmacias, etc. Esto hace al diseño de la plataforma bastante complejo sobre todo para el uso de personas mayores y por lo tanto reconocemos en este punto una oportunidad.

A continuación detallaremos algunas ventajas y desventajas identificadas.

Al tener muchas funcionalidades, el proceso para llegar a seleccionar la verdulería de preferencia puede ser un poco largo:

1. Seleccionar la sección "Mercados"
2. Dentro de "Mercados", seleccionar "Frutas y verduras"
3. Seleccionar la verdulería deseada.

Una vez en la verdulería, el usuario puede navegar por las diferentes categorías de productos o buscar el nombre de un producto específicamente. Los productos se muestran con imágenes para agilizar el reconocimiento de los mismos. Vimos esto como un punto positivo y lo incorporamos en nuestro diseño.

Al seleccionar un producto, se muestra la siguiente pantalla donde el usuario debe aclarar la cantidad de unidades deseadas. En este punto creemos que la aplicación no es del todo intuitiva ya que no queda claro si por unidad se refiere a la unidad en sí misma, al kilo o al cuarto kilo.

Aquí presentamos algunos ejemplos:

| Unidades | Cabezas |
| -------- | -------- |
|  |  |

| Kilo | 250g |
| ---- | ---- |
|  |  |

Una vez agregado el producto, se retorna a la tienda. Allí el usuario puede continuar seleccionando productos o bien puede ir a ver su pedido haciendo click en "Ver mi pedido".

Si el usuario deseara modificar uno de los productos agregados, el proceso no es para nada intuitivo. En la esquina superior derecha aparece la palabra editar y al seleccionar la vista se modifica sutilmente para realizar los cambios (borrar producto o editar cantidad).

Por último, el proceso de finalización del pedido es muy lineal e intuitivo.

| Vista verdulería | Vista pedido | Vista edición de pedido |
| ---------------- | ------------ | ----------------------- |
| <img src="https://github.com/ORT-FIS-202103/proyecto_1-grupo-2/blob/develop/investigacion/Pedidos%20Ya/PedidosYa_verduleria_2.PNG" width=400px /> | <img src="https://github.com/ORT-FIS-202103/proyecto_1-grupo-2/blob/develop/investigacion/Pedidos%20Ya/PedidosYa_resumen_pedido.PNG" width=400px /> | <img src="https://github.com/ORT-FIS-202103/proyecto_1-grupo-2/blob/develop/investigacion/Pedidos%20Ya/PedidosYa_pedido_editar.PNG" width=400px /> |

## Referencias a fuentes de información

Las entrevistas a verduleros fueron realizadas en verdulerías de Montevideo y Paysandú.

Las entrevistas y los workshops fueron realizados con las abuelas de los integrantes del equipo.

App analizada con ingeniería inversa: [Pedidos Ya!](https://www.pedidosya.com.uy/cadenas?pycat=googlesearch&cmp=sem_bra_UY_Montevideo_01&ag=pedidos%20ya%20%28e%29&kwd=pedidos%20ya&mt=e&net=g&dev=c&sitelink=&br=0&gclid=Cj0KCQjw1a6EBhC0ARIsAOiTkrH2SZh3lwo2h212foN64UImFChI_neIsk_O-d-1jGGGJxtYqVbnKZQaAsqSEALw_wcB)

## Caracterización de usuarios: User Personas



## Modelo conceptual del problema

Verdulista es una aplicación que permite a un cliente realizar una lista de compras de frutas y verduras y efectuar el pedido.
Decidimos agregar esta última funcionalidad debido a la situación sanitaria actual, para poder brindar una forma más segura de comprar verduras a la gente mayor.

A su vez, cuenta con un "modo verdulero" que permite a la verdulería recepcionar, gestionar y enviar los pedidos. En futuras versiones, la misma podría aportar información sobre preferencias de compra, estadísticas, etc.

Nuestro público objetivo es, por un lado, la familia y por otro las verdulerías. Dentro de la familia haremos mayor hincapié en los adultos mayores. Por lo tanto, serán considerados especialmente a la hora de definir los requerimientos funcionales y la interfaz de usuario. Esto se traduce en una experiencia de usuario inclusiva y funcionalidades acotadas y lineales.

# Especificación

## Definición de requerimientos funcionales y no funcionales
### Actores:
* Verdulero
* Cliente

### Requerimientos funcionales:

#### RF1: Hacer pedido
**Actor:** Cliente.

**Descripción:** El sistema deberá contar con la opción de hacer un pedido a una verdulería. Para ello, el cliente tendrá que seleccionar una verdulería, los productos, su cantidad y finalmente confirmar la compra.

**Prioridad:** Alta.

#### RF2: Ver historial
**Actor:** Verdulero y Cliente.

**Descripción:** Tanto los clientes como los verduleros deben de poder acceder a un historial de compras/ventas que hayan hecho.

**Prioridad:** Alta

#### RF3: Autocompletado del formulario datos de usuario
**Actor:** Cliente.

**Descripción:** El cliente solo tiene que completar los datos cuando realiza el primer pedido, el resto de ocasiones todos los campos estarán completos.

**Prioridad:** Baja

#### RF4: Pedido por unidades o peso
**Actor:** Cliente.

**Descripción:** El cliente podrá elegir su producto expresando la cantidad en unidades o peso según su preferencia.

**Prioridad:** Alta

#### RF5: Comunicación con cliente
**Actor:** Verdulero.

**Descripción:** El verdulero podrá comunicarse telefónicamente con el cliente en caso de tener alguna duda con su pedido o en el envío.

**Prioridad:** Alta

#### RF6: Reparto de pedidos
**Actor:** Verdulero.

**Descripción:** El verdulero podrá visualizar en una lista todos los pedidos preparados prontos para entregar y utilizarla para gestionar sus envíos.

**Prioridad:** Alta

#### RF7: Preparación de pedidos
**Actor:** Verdulero.

**Descripción:** El verdulero podría visualizar un listado con los productos que conforman el pedido.

**Prioridad:** Alta

### Requerimientos no funcionales:

#### RNF1: Color
**Descripción:** Se utilizará como color principal Light Green 800 y como secundario Deep Orange 800.

**Prioridad:** Alta

#### RNF2: Tipografía
**Descripción:** La fuente a usar debe ser Roboto.

**Prioridad:** Alta

#### RNF3: Íconos

**Descripción:** Cualquier ícono debe estar relleno.

**Prioridad:** Alta

#### RNF4: Botones explicativos
**Descripción:** Todos los botones tendrán un mensaje que describa su función.

**Prioridad:** Alta

#### RNF5: Botones (tamaño)

**Descripción:** Evitar usar botones pequeños y en grandes cantidades.

**Prioridad:** Media

#### RNF6: UX

**Descripción:** La experiencia del cliente con la aplicación debe ser lo más lineal posible. Pocas opciones por pantalla.

**Prioridad:** Alta

#### RNF7: Sistemas operativos

**Descripción:** La aplicación en su v1 deberá funcionar en Android 9.0.

**Prioridad:** Alta

#### RNF8: Capacidad de usuarios

**Descripción:** El sistema en su v1 deberá soportar 200 usuarios concurrentes.

**Prioridad:** Media

#### RNF9: Lenguajes de programación
**Descripción:** El sistema será programado en JavaScript Node.JS.

**Prioridad:** Alta

## User Stories / Use Cases detallados

### User Stories

**ID:** #1

**Título:** Conocer el monto del pedido.

**Narrativa:**

- **Como** cliente
- **Quiero** conocer el monto acumulado del pedido a medida que se ingresan nuevos productos.
- **Para** para tener una noción de cuánto estoy gastando.

**Criterios de aceptación:**

A medida que se agregan productos se debe ir actualizando el subtotal en la vista. Al finalizar el pedido la app debe informar el monto total a pagar.

**ID:** #2

**Título:** Selección de cantidades

**Narrativa:**

- **Como** cliente
- **Quiero** poder pedir los productos por cantidad o por peso
- **Para** que mi proceso de compra a través de la app sea más parecido a mis compras presenciales.

**Criterios de aceptación:**

A la hora de agregar un producto nuevo, el cliente debe tener la posibilidad de expresar la cantidad del producto pedido en unidades o peso.

**ID:** #3

**Título:** Entregar pedido

**Narrativa:**

- **Como** verdulero
- **Quiero** saber el lugar de la entrega de un pedido
- **Para** entregarlo en la dirección correcta

**Criterios de aceptación:**

La ubicación se debe de mostrar en un mapa y a su vez tener la dirección escrita y el contacto del cliente a mano para cualquier eventualidad.

---
### Use Cases

#### Título: Ver historial de compra.

Actor: Cliente.

Curso normal:

| Acción de los actores | Respuesta del sistema |
| -------- | -------- |
| 1. Toca el botón que dice "consultar historial". (Ver Fig 1) | 2. Muestra una lista con los pedidos hechos hasta la fecha. (Ver Fig 2)|
(Caso de uso asociado al RF2.)

#### Título: Hacer pedido.

Actor: Cliente

Curso normal:

| Acción de los actores | Respuesta del sistema |
| -------- | -------- |
|1. Solicito un nuevo pedido (Ver Fig 1) |2. Solicita la elección de una verdulería (Ver Fig 3) |
| 3. Elige una verdulería | 4. Muestra el catálogo de productos y solicita la elección de uno (Ver Fig 4) |
| 5. Elige un producto | 6.Solicita cantidad de producto y aclaraciones, en base a eso da estimación de precio (Ver Fig 5) |
|7. Confirma la cantidad del producto | 8. Muestra un listado con los productos elegidos y espera confirmación (Ver Fig 7) |
|9. Confirma la compra | 10. Solicita información de contacto y dirección (Ver Fig 8) |
|11. Completa la información y presiona “Finalizar compra” |12. Informa al usuario el precio final y envía el pedido a la verdulería (Ver Fig 9)|

Cursos alternativos:
El usuario se equivoca de verdulería y presiona el botón volver, el sistema vuelve al menú principal.

El usuario quiere quitar un producto, lo selecciona y presiona el botón Quitar seleccionados, el sistema elimina los elementos seleccionados de la lista.

El usuario quiere comprar más de un producto, el sistema vuelve a mostrar el catálogo de productos.

(Caso de uso asociado al RF1 y RF3.)

#### Titulo: Preparar pedido

Actores: Verdulero

Curso normal:

| Acción de los actores | Respuesta del sistema|
| -------- | -------- |
| 1. Presiona el botón Preparar pedido que indica el número de pedidos pendientes (Ver Fig 10) |2. Muestra un listado con los pedidos pendientes (Ver Fig 15) |
|3. Selecciona un pedido de la lista |4. Muestra una lista de los productos que conforman el pedido (Ver Fig 16) |
|5. Prepara todo y presiona pedido completado |6. Lo devuelve al menú principal (Ver Fig 10)|

Cursos alternativos:

Si al momento que el verdulero termina de preparar un pedido tiene más pedidos pendientes, el sistema lo devuelve al listado de pedidos pendientes en lugar de al menú principal.

(Caso de uso asociado al RF7.)

#### Título: Repartir pedido

Actor: Verdulero

Curso normal:

|Acción de los actores | Respuesta del sistema |
| -------- | -------- |
|1. Presiona el botón de repartir pedido que indica el número de repartos pendientes (Ver Fig 10) |2. Muestra un listado con los repartos pendientes (Ver Fig 17) |
|3. Selecciona uno de los repartos pendientes |4. El sistema devuelve información del cliente y un mapa de su ubicación (Ver Fig 18) |
|5. Presiona fuera de la ventana emergente |6. Vuelve a mostrar el listado de repartos pendientes (Ver Fig 17) |
|7. Marca el pedido que acaba de completar como entregado|8. Muestra el listado de repartos pendientes|

Curso alternativo:

Hay un problema con el reparto y el verdulero presiona el botón para comunicarse con el cliente, el sistema realiza la llamada.

(Caso de uso asociado al RF5 y RF6.)

#### Título: Ver historial de pedidos:

Actores: Verdulero:

Curso normal:

| Acción de los actores | Respuesta del sistema |
| -------- | -------- |
|1. Presiona el botón consultar historia (Ver Fig 10) |2. Muestra un listado con todos los pedidos (Ver Fig 14) |
|3. Selecciona el botón ver a la derecha del cliente |4. Muestra la lista de productos pedidos por ese cliente en esa fecha (Ver Fig 19)|

Curso alternativo:

El usuario solo quería ver la lista de pedidos y luego presiona regresar al menú principal.

(Caso de uso asociado al RF2.)

## Bocetos de IU

### Vistas Cliente

| Fig 1 | Fig 2 | Fig 3 |
| ----- | ----- | ----- |
|<img src="https://github.com/ORT-FIS-202103/proyecto_1-grupo-2/blob/develop/bocetosiu/Cliente/cliente_inicio.jpg" width=400px />|<img src="https://github.com/ORT-FIS-202103/proyecto_1-grupo-2/blob/develop/bocetosiu/Cliente/cliente_historial_pedidos.jpg" width=400px /> | <img src="https://github.com/ORT-FIS-202103/proyecto_1-grupo-2/blob/develop/bocetosiu/Cliente/cliente_seleccionar_verduleria.jpg" width=400px />|

| Fig 4 | Fig 5 | Fig 6 |
| ----- | ----- | ----- |
|<img src="https://github.com/ORT-FIS-202103/proyecto_1-grupo-2/blob/develop/bocetosiu/Cliente/cliente_seleccionar_productos.jpg" width=400px />| <img src="https://github.com/ORT-FIS-202103/proyecto_1-grupo-2/blob/develop/bocetosiu/Cliente/cliente_seleccion_cantidad_kg.jpg" width=400px />| <img src="https://github.com/ORT-FIS-202103/proyecto_1-grupo-2/blob/develop/bocetosiu/Cliente/cliente_seleccion_cantidad_u.jpg" width=400px />|

| Fig 7 | Fig 8 | Fig 9 |
| ----- | ------ | ------ |
|<img src="https://github.com/ORT-FIS-202103/proyecto_1-grupo-2/blob/develop/bocetosiu/Cliente/cliente_pedido.jpg" width=400px />|<img src="https://github.com/ORT-FIS-202103/proyecto_1-grupo-2/blob/develop/bocetosiu/Cliente/cliente_finalizar.jpg" width=400px />|<img src="https://github.com/ORT-FIS-202103/proyecto_1-grupo-2/blob/develop/bocetosiu/Cliente/cliente_completado.jpg" width=400px />|

### Vistas Verdulero

| Fig 10 | Fig 11 | Fig 12 |
| ------ | ------ | ------ |
|<img src="https://github.com/ORT-FIS-202103/proyecto_1-grupo-2/blob/develop/bocetosiu/Verdulero/verdulero_inicio1.jpg" width=400px />|<img src="https://github.com/ORT-FIS-202103/proyecto_1-grupo-2/blob/develop/bocetosiu/Verdulero/verdulero_inicio2.jpg" width=400px />|<img src="https://github.com/ORT-FIS-202103/proyecto_1-grupo-2/blob/develop/bocetosiu/Verdulero/verdulero_inicio3.jpg" width=400px />|

| Fig 13 | Fig 14 | Fig 15 |
| ------ | ------ | ------ |
|<img src="https://github.com/ORT-FIS-202103/proyecto_1-grupo-2/blob/develop/bocetosiu/Verdulero/verdulero_inicio4.jpg" width=400px />|<img src="https://github.com/ORT-FIS-202103/proyecto_1-grupo-2/blob/develop/bocetosiu/Verdulero/verdulero_historial_pedidos.jpg" width=400px />|<img src="https://github.com/ORT-FIS-202103/proyecto_1-grupo-2/blob/develop/bocetosiu/Verdulero/verdulero_pedidos.jpg" width=400px />|

| Fig 16 | Fig 17 | Fig 18 |
| ------ | ------ | ------ |
|<img src="https://github.com/ORT-FIS-202103/proyecto_1-grupo-2/blob/develop/bocetosiu/Verdulero/verdulero_preparacion.jpg" width=400px />|<img src="https://github.com/ORT-FIS-202103/proyecto_1-grupo-2/blob/develop/bocetosiu/Verdulero/verdulero_reparto.jpg" width=400px />|<img src="https://github.com/ORT-FIS-202103/proyecto_1-grupo-2/blob/develop/bocetosiu/Verdulero/verdulero_reparto_detalle.jpg" width=400px />|

| Fig 19 |
| ------ |
|<img src="https://github.com/ORT-FIS-202103/proyecto_1-grupo-2/blob/develop/bocetosiu/Verdulero/verdulero_historial_pedidos_detalle.jpg" width=33% />|

# Validación y verificación

## Verificar la especificación

Evaluamos los requisitos funcionales utilizando una tabla.

| El requerimiento | RF1 | RF2 | RF3 | RF4 | RF5 | RF6 | RF7 |
| ---------------- | --- | --- | --- | --- | --- | --- | --- |
| ¿Es factible? (viable de ser hecho) |Si|Si|Si|Si|Si| Si | Si |
| ¿Es consistente? (no se contradice con otro) |Si|Si|Si|Si|Si|Si|Si|
| ¿Es ambiguo? |No|No|No|No|No|No|No|
| ¿Es verificable? |Si|Si|Si|Si|Si|Si|Si|
| ¿Está priorizado? |Si|Si|Si|Si|Si|Si|Si|

## Validar la solución con personas no involucradas en el proyecto

Para validar la solución presentamos el proyecto a diferentes usuarios. Algunos de ellos habían sido entrevistados previamente. Les resultó sencilla de usar y manifestaron que posiblemente la utilizarían si tuvieran un verdulero de confianza al cual hacer sus pedidos a través de ella.

# Reflexión

## Detalle del trabajo individual

Para realizar el trabajo utilizamos hackmd como previsualizador. En reiteradas ocasiones, los commits que se pueden ver en el repositorio conllevan detrás el trabajo de los tres integrantes del grupo.

Dado que uno de los integrantes del equipo posee conocimientos en diseño, el bocetado quedó en sus manos, obviamente con el apoyo del resto del grupo, que constantemente aportó comentarios y sugerencias relevantes.

El resto de las secciones fueron realizadas en conjunto.

### Reflexión Daniela

Este obligatorio me sirvió para utilizar y terminar de comprender el uso de repositorios locales y remotos. Fue muy útil su aplicación durante el proyecto, tanto para trabajar en conjunto con mis compañeros como para trabajar personalmente en diferentes ordenadores.

A su vez, me resultó interesante la utilización de técnicas de elicitación para luego facilitar la definición de requerimientos funcionales y no funcionales. En mi formación en diseño industrial realizamos procesos similares en las etapas de definición e ideación de proyectos y creo que este proyecto fue un buen ejemplo de que no importa si el producto final es un producto tangible (material) o un producto digital, el proceso de definición de requerimientos es muy parecido.

Como punto negativo, fue un poco desmotivante que teniendo entrevistas no muy positivas respecto a la intención del uso de la app las posibilidades de cambiar el proyecto (por definición de letra de entrega y obviamente también por tiempos) eran muy bajas. Simplemente nos enfocamos en hacer la mejor aplicación posible respetando las sugerencias y necesidades de los usuarios entrevistados.

### Reflexión Franco

Este trabajo sirvió como una primera aproximación a un trabajo de la vida real, lo cuál es emocionante. Disfrute especialmente la parte de investigación ya que nunca había hecho algo similar. Fue una muy buena experiencia de trabajo en equipo en la que nos apoyamos mutuamente en toda la realización del trabajo, aprovechando las habilidades de cada uno. Sin dudas lo aprendido aquí será útil en el futuro.

### Reflexión Emiliano

En esta materia aprendí a manejar git y salvo contadas ocasiones, no lo pude poner en práctica hasta llegado el momento de trabajar en este obligatorio. Me sirvió para reafirmar esos conocimientos y también para aplicar lo aprendido en clase.

También fue una buena experiencia para acercarme un poco más a las mecánicas que se manejan en un equipo de desarrollo de software de calidad.

Si bien la consigna no era algo para nada viable (lo cual molestaba un poco), cumplió con su cometido.

## Técnicas aplicadas y aprendizajes
Para organizar el trabajo, creamos un grupo en whatsApp y realizamos llamadas a través de google Meet. Nos definimos objetivos semanales (realización de entrevistas, bocetado ui, completar una sección, etc.) y fuimos trabajando coordinadamente en ellos.

En una ocasión tuvimos problemas con respecto a las versiones del repositorio debido a que a un integrante se le olvidó usar 'git pull' antes de empezar a editar. Luego de ese incidente, todos nos aseguramos de hacer el pull antes de hacer cualquier modificación.