1.

Pregunta 1
2. Pregunta 2
Se asume que la aplicación realiza pedidos en base a un historial de locales, por ende, los proveedores,
serı́an los diferentes locales que están trabajando junto a la aplicación.

2.1. Diagrama de contexto

1
2.2. Diagrama de contenedores

2
2.3. Diagrama de componentes
En cuanto al nivel de componentes, se obtienen los microservicios que otorga la aplicación. Para ello
se verán los tres contenedores principales:
En Servicio WEB se ve la logı́stica:
1.-obtener pedido (usando Amazon y Postgres se podrı́a filtrar por precio, por tipo, etc)
2.-Generar órdenes de pedido
En el de Management se ve la gestión:
1.-Realizar cobros
2.-Obtener ventas (Con Azure SQL DB y DW se podrı́a obtener un resumen estadı́stico de las ventas)
3.-Enviar ofertas o mails a clientes.
En el de App Delivery:
1.- Mostrar rutas
2.- Enviar mensaje a clientes

3. Pregunta 3
En primer lugar, se calculará el tiempo estimado en horas para la implementación de lo básico, más
todo o asociado a la funcionalidad 1, es decir, al primer release:
Escenario optimista: 164 horas persona.
Escenario pesimista: 336 horas persona.
Por otra parte, las tres personas suman un total de 88 horas semanales de trabajo, por ende, en un
mes cumplirı́an 352 horas. Ası́, se cumplirı́a incluso en el escenario pesimista. Sin embargo, si en esas
88 horas de trabajo se considerase, por ejemplo, una hora de colación en la persona que trabaja a
jornada completa, entonces, habrı́a que restar 20 horas de trabajo a dicho mes, es decir, un total de
332 horas posibles, lo que provocarı́a que no se alcance el objetivo frente a un escenario pesimista,
sin embargo, solo serı́an cuatro horas faltantes.
En cuanto a los cinco meses siguientes (tres releases adicionales), se tiene:
Escenario optimista: 770 horas persona.
Escenario pesimista: 1180 horas persona.
Y en cinco meses, las tres personas cumplirı́an un total de 1760 horas, que nuevamente, serı́an
1660 horas en caso de que se considere una hora de colación para la persona que trabaja jornada

3
completa. En este caso, si se tiene un margen mucho más grande para conseguir el objetivo, incluso
en el escenario pesimista.
Para cumplir con un desarrollo ágil y estar atentos a posibles problemas, se recomienda hacer sprints
semanales.
Plan de desarrollo del primer release:

3.1. Planificación del primer release

Desarrollo en 4 sprints (1 por semana)
Basado en los datos anteriores y el escenario pesimista, se esperarı́a cumplir con el primer
release efectivamente en el primer mes, sin embargo, si llegase a faltar algún detalle, podrı́a
hacerse un ajuste por alcance, dado que debe estar terminado en un mes si o si.
Elegir relatos en base a su prioridad, para tener terminados primero los que sean más necesarios
en el primer release.
Al finalizar cada sprint, se debe verificar la productividad de cada individuo, para modificar en
caso de ser necesario (la idea del desarrollo ágil con sprint semanales es poder aletar tempra-
namente este punto).

3.2. Planificación a nivel de producto

Considerar que cada persona por separado debe cumplir con sus horas de trabajo, ası́, en el periodo
de 5 meses, la persona de jornada completa (Llamada Persona 1), posee 880 horas persona en total.
Las personas que trabajan 22 horas semanales (Llamadas Persona 2 y 3), cumplirı́an en cinco meses
440 horas persona cada uno. Por ende, la persona de jornada completa, al tener el doble de horas,
puede poseer más carga (para que el pago de sueldo tenga sentido).
Ası́, se tendrı́a que el total de 1180 horas de trabajo (en el caso pesimista), se divide en cuatro partes
y la persona 1 obtendrá 2/4 del trabajo aproximadamente, y el resto 1/4.
Persona 2 y 3 deben cumplir con 295 horas de trabajo cada uno y persona 1 con 590 aproximadamente.
Dado que son 3 releases en cinco meses, se podrı́a realizar el primero al cabo de 2 meses, el segundo
al cabo del 4 mes y el útimo release al mes cinco. Sin embargo, siempre con sprint semanales para
mantener el desarrollo ágil.
Luego, una opción factible serı́a:
Segundo Release (Meses 2 y 3):
1.- Persona 1 trabaja en funcionalidad 5. 2.- Persona 2 y 3 en funcionalidad 3.

4
Al término del segundo release, todos debiesen haber terminado su parte (Persona 1 puede trabajar
maximo 352 horas, mientras que personas 2 y 3, máximo 176 ), dado que el tiempo fue suficiente.
Tercer Release (Meses 4 y 5):
1.- Persona 1 trabaja en funcionalidad 4. 2.- Persona 2 y 3 en funcionalidad 2.
Cuarto Release (Mes 6):
1.- Todos pueden trabajar en funcionalidad 6.
Lo importante es no dejar para el final lo que parece ser que necesita más horas persona para ser
completado.
Con este itinerario, se tendrı́a que el trabajo de cada persona en horas totales es:
Persona 1: 590 horas totales
Persona 2 y 3: 295 horas totales cada uno.
Suponiendo que en el último release Persona 1 realizó el 50 % del trabajo y el resto se repartió entre
los dos trabajadores de media jornada.

4. Pregunta 4
Se divide el input según resultados posibles, creando por ejemplo, las siguientes opciones:
monto neto = 10.000
* Si es considerado como punto frontera, entonces puede agregarse:
- monto neto = 10.001
- monto neto = 9.999
monto neto = 100.000
monto neto = 100.001
* Al no tener total conocimiento del software y su código, no es posible verificar que se omitan valores
negativos o cero, por ende, serı́a útil al menos tener un test que los considere (monto neto = 0 y
monto neto = -10.000)
Por ende, creando las combinaciones posibles con el resto de opciones, los inputs de test posibles son:
Caso 1.1: monto neto = 10.000, es primera compra y antigüedad de 2 meses
Caso 1.2: monto neto = 10.000, es primera compra y antigüedad de 3 meses
Caso 1.3: monto neto = 10.000, es primera compra y antigüedad de 6 meses

5
Caso 1.4: monto neto = 10.000, NO es primera compra y antigüedad de 2 meses
Caso 1.5: monto neto = 10.000, NO es primera compra y antigüedad de 3 meses
Caso 1.6: monto neto = 10.000, NO es primera compra y antigüedad de 6 meses
Caso 2.1: monto neto = 10.001, es primera compra y antigüedad de 2 meses
Caso 2.2: monto neto = 10.001, es primera compra y antigüedad de 3 meses
Caso 2.3: monto neto = 10.001, es primera compra y antigüedad de 6 meses
Caso 2.4: monto neto = 10.001, NO es primera compra y antigüedad de 2 meses
Caso 2.5: monto neto = 10.001, NO es primera compra y antigüedad de 3 meses
Caso 2.6: monto neto = 10.001, NO es primera compra y antigüedad de 6 meses
Caso 3.1: monto neto = 9.999, es primera compra y antigüedad de 2 meses
Caso 3.2: monto neto = 9.999, es primera compra y antigüedad de 3 meses
Caso 3.3: monto neto = 9.999, es primera compra y antigüedad de 6 meses
Caso 3.4: monto neto = 9.999, NO es primera compra y antigüedad de 2 meses
Caso 3.5: monto neto = 9.999, NO es primera compra y antigüedad de 3 meses
Caso 3.6: monto neto = 9.999, NO es primera compra y antigüedad de 6 meses
Caso 4.1: monto neto = 100.000, es primera compra y antigüedad de 2 meses
Caso 4.2: monto neto = 100.000, es primera compra y antigüedad de 3 meses
Caso 4.3: monto neto = 100.000, es primera compra y antigüedad de 6 meses
Caso 4.4: monto neto = 100.000, NO es primera compra y antigüedad de 2 meses
Caso 4.5: monto neto = 100.000, NO es primera compra y antigüedad de 3 meses
Caso 4.6: monto neto = 100.000, NO es primera compra y antigüedad de 6 meses
Caso 5.1: monto neto = 100.001, es primera compra y antigüedad de 2 meses
Caso 5.2: monto neto = 100.001, es primera compra y antigüedad de 3 meses
Caso 5.3: monto neto = 100.001, es primera compra y antigüedad de 6 meses
Caso 5.4: monto neto = 100.001, NO es primera compra y antigüedad de 2 meses
Caso 5.5: monto neto = 100.001, NO es primera compra y antigüedad de 3 meses
Caso 5.6: monto neto = 100.001, NO es primera compra y antigüedad de 6 meses

6
Caso 6.1: monto neto = -10.000, NO es primera compra y antigüedad de 3 meses
Caso 6.2: monto neto = 0, NO es primera compra y antigüedad de 3 meses