Consigna del examen final · La propuesta técnica de solución (ASD)

Lanzamiento: miércoles 15 jul 2026 (presencial) · Entrega: jueves 23 jul 2026, 23:59 Defensa oral: viernes 24 jul 2026, 4:00–8:00 PM · Modalidad: grupal (los 6 grupos) Peso: 25% de la nota final del curso.

Tienen más de una semana (15 → 23 jul) para producir el documento. No es un sprint de un día; es tiempo para pensar las decisiones con calma.

En una frase

Cada grupo recibe, por sorteo, un TDR distinto (la necesidad de un cliente ficticio, un caso realista del contexto salvadoreño) y produce un documento: la propuesta técnica de cómo se va a construir la solución (arquitectura, patrones, stack, trade-offs), que cierra con una estimación breve de esfuerzo y costo.

Es el mismo documento que en la industria se llama propuesta técnica de solución. No escriben código: deciden y justifican. Ese es el músculo que entrenamos todo el curso, ahora sobre un problema nuevo que no vieron antes.

1. De dónde parten: su TDR

A cada grupo le toca, por sorteo, un TDR distinto (Términos de Referencia): un caso ficticio pero realista, ambientado en el contexto salvadoreño y escrito desde la voz de un cliente. El TDR dice qué se necesita; no dice cómo hacerlo: eso lo deciden ustedes. (El cliente y la organización son inventados para la clase; el tipo de problema sí es real.)

El TDR tiene huecos a propósito. El cliente no es técnico: no definió la arquitectura, ni los patrones, ni el stack, y dejó cosas sin especificar. Detectar esos huecos y resolverlos con criterio es parte central de la nota. Un buen documento hace explícito lo que el cliente asumió sin decir.

2. Qué entrega cada grupo

Un documento en PDF, 8–15 páginas (sin contar portada ni anexos), con las secciones que se listan en el punto 3. Un solo archivo por grupo.

Cómo entregarlo:

• Por Moodle, en la tarea del examen final. Suban el PDF (un solo archivo por grupo).
• Nombre del archivo: TDR<n>-<grupo>.pdf (usen el número de su TDR y el nombre de su grupo, o “Grupo N” si no tienen nombre). Ejemplo: TDR4-LosPatrones.pdf.
• Fecha límite: jueves 23 jul, 23:59 (medianoche del jueves). Moodle cierra a esa hora; no dejen la subida para el último minuto.

El formato visual es libre (Google Docs, Word, Markdown exportado, lo que dominen). No se evalúa el diseño gráfico; se evalúa el contenido y el criterio. No pierdan tiempo en la estética del documento.

Referencia para arrancar. Más abajo tienen una plantilla con las secciones ya armadas, cada una con “qué va acá” y un ejemplo lleno, de un sistema distinto al de ustedes (una plataforma de telemedicina). Cópienla y llénenla con su TDR. No arrancan de una hoja en blanco.

Ojo con el nivel del ejemplo. La plantilla está llena al nivel sobresaliente y usa una arquitectura de servicios que no vimos en clase. NO se espera que lleguen a ese nivel de arquitectura. Lo que se espera es ese nivel de justificación de patrones. Un sistema organizado en módulos con responsabilidades claras (como el legacy que trabajaron todo el curso: órdenes, notificaciones, pagos…) y 3-4 patrones bien puestos y justificados es sobresaliente. Copiar la forma (microservicios, muchos patrones) sin el criterio es la sobre-ingeniería que se penaliza.

3. Anatomía del documento (secciones obligatorias)

Estas secciones son el esqueleto. Cada una se apoya en algo que ya vieron en el curso.

1. Contexto y objetivo. En sus palabras: qué organización es, qué problema tiene (con su costo), qué debe lograr el sistema. Cierren con el objetivo del MVP en una frase medible.

2. Alcance y fuera de alcance. Qué SÍ resuelve el sistema y, sobre todo, qué NO. El “fuera de alcance” tiene que existir y tener criterio (YAGNI): cada exclusión con su razón. Aquí van los huecos del TDR que decidieron dejar fuera.

3. Requerimientos funcionales. Qué hace el sistema, por módulo o por rol, con operaciones concretas. Marquen cuáles vienen del TDR y cuáles infirieron ustedes.

4. Requerimientos no funcionales. Los atributos de calidad (concurrencia, disponibilidad, seguridad, auditoría…): qué tan bien tiene que funcionar el sistema, no qué hace. Aten cada uno a algo del TDR. Un no-funcional se vuelve verificable cuando le ponés un criterio: no “rápido” sino “responde en menos de X”, no “seguro” sino “acceso por rol, datos cifrados”. Poner números donde tenga sentido suma; lo mínimo es identificar los del TDR y no ignorarlos.

5. Arquitectura propuesta. Cómo se organiza el sistema: sus módulos (las piezas en que lo dividen), qué hace cada uno, cómo se comunican, dónde viven los datos, qué servicios externos se integran. Con al menos un diagrama (cajas para los módulos y flechas para lo que habla con qué; ASCII o imagen sirve). Debe responder al problema real del TDR, no ser un diagrama genérico de libro. Pensá en el legacy que trabajaron: sus módulos (órdenes, pagos, notificaciones) y cómo se relacionan. Ese nivel de organización es una respuesta válida y suficiente; no hace falta arquitectura de servicios.

6. Patrones de diseño. El corazón del documento. Qué patrones aplican, dónde en el sistema y por qué ese y no otro. Por cada uno, una frase de “cuándo NO lo usaría acá”. Esperamos los que el dominio pida con criterio (típicamente 3 a 6). Si tu caso justifica solo 3 impecables, explicá por qué y no penaliza. Lo que baja la nota es el patrón forzado para llegar a un número, no la cantidad.

7. Modelo de datos y stack tecnológico. Las entidades principales y sus relaciones, y las tecnologías elegidas con su porqué atado a un requerimiento o NFR. Incluyan por qué descartaron una alternativa obvia. No una lista de modas.

8. Trade-offs, supuestos y riesgos. Por cada decisión grande, qué alternativa descartaron y qué costo aceptaron. Qué asumen que el cliente debe cumplir. Qué puede salir mal y cómo lo mitigan.

9. Estimación (la sección de cierre, corta). Un par de párrafos: esfuerzo aproximado (personas y roles), cronograma por fases y un costo estimado con sus supuestos. No se evalúa si el monto es “el correcto” (nadie espera una cotización real), sino que sea coherente con el alcance y la arquitectura que ustedes mismos definieron. Una arquitectura grande estimada en dos semanas es incoherente. Estimar los ayuda a dimensionar su propia solución.

Es un solo documento. Las secciones 1–8 son el grueso (arquitectura y patrones, que es lo que más pesa en la nota); la sección 9 es un cierre breve, como en cualquier propuesta real. No es un segundo entregable.

4. La defensa (24 jul)

El viernes 24 cada grupo presenta y defiende el documento que subió a Moodle (el mismo, no una versión nueva) en ~30 min: ~15 min de exposición + ~12 min de preguntas. Repártanse la exposición entre el grupo; no presentan código, defienden decisiones.

Habrá preguntas, y pueden ir dirigidas a cualquier integrante. No es un cuestionario a todos por igual: son las preguntas que surjan sobre sus decisiones, y se las puedo hacer a quien quiera del grupo. Por eso conviene que todos entiendan el documento, no solo el que lo escribió. No buscamos que se sepan todo de memoria; buscamos que sostengan lo que decidieron. Preguntas típicas: “¿por qué este patrón acá y no otro?”, “¿qué pasa con este requerimiento del TDR que no veo resuelto?”, “¿por qué este stack?“.

5. Fechas

6. Reglas

• Un TDR por grupo, no se cambia. El que les tocó en el sorteo es el que defienden.
• Casi no va código. Es un documento de decisiones. Un snippet corto (hasta ~10 líneas, la interfaz de un patrón y sus métodos) para ilustrar está bien; clases implementadas o lógica de negocio, no. Si dudás, describilo en prosa.
• Todos entienden el documento. Le puedo preguntar a cualquier integrante sobre cualquier decisión (ver sección 4). No alcanza con que uno solo sepa defenderlo.
• Los patrones que el dominio pida, con criterio. Meter patrones de más porque sí es el anti-patrón que criticamos todo el curso. Se penaliza la sobre-ingeniería, no la cantidad justa.
• El “fuera de alcance” y los trade-offs no son relleno. Son donde se ve el criterio de ingeniero. Un documento sin ellos está incompleto.
• Sobre la IA: pueden usarla como asistente (para redactar, ordenar, revisar). Pero cada decisión del documento tiene que poder defenderse sin ayuda en la oral del 24. La nota real se juega ahí: si el documento dice algo que el grupo no puede sostener ni explicar por qué, no cuenta. Usen la IA para escribir mejor, no para decidir por ustedes.
• Dudas: por Teams, respondo estos días.

7. Por dónde arrancar

No abran tres documentos sin rumbo. El orden para empezar:

1. Terminen de leer esta consigna. Es el mapa: qué entregan, cómo se califica y qué secciones lleva. (Si llegaron hasta acá, ya casi.)
2. Copien la plantilla (en pds.cesar.sh/asd-final) y empiecen a llenarla con su TDR. La sección 3 de arriba y las 9 secciones de la plantilla son el mismo esqueleto.
3. Repártanse el trabajo como grupo y fijen cuándo se reúnen. Cada quien tiene que poder defender su parte (sección 4).

Checkpoint voluntario (lun 21 jul): si quieren saber si van bien antes de entregar, mándenme por Teams, a más tardar el lunes 21, 5-6 bullets: (a) su patrón “estrella” y dónde lo ponen, (b) el requerimiento no funcional más crítico de su TDR, (c) los módulos principales en que dividen el sistema. Les respondo en dos líneas. No se califica: es una red de seguridad para que nadie llegue al 23 con el rumbo equivocado.

Rúbrica · La propuesta técnica de solución (ASD) · examen final

Peso en el curso: 25% · Modalidad: grupal · Entrega: jue 23 jul (Moodle) · Defensa: vie 24 jul

La nota sale de dos cosas: el documento (lo que más pesa) y la defensa oral. No hay fórmula ni puntajes por decimal: se califica con criterio, mirando lo de abajo.

Qué se mira en el documento

En orden de lo que más pesa:

1. Patrones con criterio (lo más importante). Los patrones que el dominio pide, puestos dónde corresponde y con el por qué ese y no otro. Por cada uno, el “cuándo NO lo usaría”. Es el eje del curso: acá se ve si aprendieron a aplicar patrones o solo a nombrarlos. Meter patrones de más (sobre-ingeniería) baja la nota; tres bien puestos valen más que seis forzados.

2. Arquitectura y stack. El sistema organizado en módulos con responsabilidades claras (al nivel del legacy del curso), que responde al problema del TDR, con un diagrama que se entiende. El stack elegido con su porqué atado a un requerimiento, no a la moda.

3. Alcance bien delimitado. Qué SÍ y, sobre todo, qué NO resuelve el sistema, con criterio (YAGNI). Los huecos del TDR resueltos o excluidos con razón.

4. Requerimientos. Funcionales y no funcionales, los del TDR más los que infirieron con criterio. No ignorar un no-funcional clave del TDR (concurrencia, offline, auditoría…).

5. Trade-offs y supuestos. Por cada decisión grande, qué alternativa descartaron y qué costo aceptaron. Es donde se ve el criterio de ingeniero.

6. Estimación (cierre corto). Esfuerzo, cronograma y costo coherentes con la solución que ellos mismos propusieron. No se evalúa si el monto es “correcto”, solo que no contradiga lo que diseñaron.

La nota del documento es una valoración global de esas seis cosas, con el peso puesto en las dos primeras (patrones y arquitectura). Un documento genérico (que podría ser de cualquier sistema, sin el TDR específico adentro) o que sobre-diseña, no llega a nota alta aunque esté completo.

La defensa oral

El viernes 24 cada grupo presenta y defiende el documento que subió a Moodle, ~30 min (~15 de exposición + ~12 de preguntas). No presentan código: defienden decisiones. Lo que se mira:

• Sostienen sus decisiones con criterio, no con “así lo vimos”.
• El grupo entiende su documento: las preguntas pueden ir a cualquier integrante; que respondan, no solo el que escribió esa parte.
• Reaccionan bien a una objeción: cuando se les señala un hueco o una alternativa, la discuten con honestidad.

La nota de defensa es del grupo, pero puede ajustarse por integrante si alguien no logra sostener nada de lo que entregaron.

Plantilla · Propuesta técnica de solución

Cómo usar esto. Este es el esqueleto de su documento. Cada sección trae qué va acá y un ejemplo lleno (recuadros grises, de un sistema distinto al de ustedes: una plataforma de telemedicina). Bórrenlo y pongan lo suyo. Es un solo documento. Las secciones 1–8 son el grueso; la 9 (estimación) es un cierre corto. Extensión: 8–15 páginas (sin portada ni anexos). Se evalúa el criterio, no la cantidad.

⚠️ Leé esto antes de copiar el ejemplo. El ejemplo de telemedicina está lleno al nivel sobresaliente (1.0) y usa una arquitectura de servicios que no vimos en clase (API Gateway, componentes separados, proveedor de video externo). NO tenés que llegar a ese nivel de arquitectura. Para un documento competente alcanza con un sistema organizado en módulos con responsabilidades claras (al nivel del legacy que trabajaron todo el curso), 3-4 patrones bien atados y NFR identificados. No necesitás microservicios ni tantos patrones. Copiar la forma del ejemplo (muchos componentes, muchos patrones) sin el criterio es exactamente la sobre-ingeniería que se penaliza. El ejemplo marca cómo se justifica, no cuánta arquitectura poner.

Portada

Nombre del sistema · organización cliente · grupo e integrantes · número de TDR · versión · fecha.

1. Contexto y objetivo

Qué va acá: qué organización es, qué problema concreto tiene hoy (con el costo de ese problema), qué debe lograr el sistema y para quién. No es un resumen del TDR: es la lectura que ustedes hacen de él. Cierren con el objetivo del MVP en una frase medible.

Ejemplo (telemedicina, “Clínica Conecta”): Clínica Conecta es una red de clínicas privadas que quiere ofrecer consulta médica remota por video a pacientes que hoy deben trasladarse físicamente. El problema actual: la agenda se llena con consultas de control que no requieren presencia física (renovar una receta, revisar un examen), saturando los consultorios y generando esperas de hasta 3 semanas para un cupo. Cada consulta perdida por inasistencia le cuesta a la red un cupo que pudo darse a otro paciente.

Objetivo del MVP: permitir que un paciente agende, pague y realice una consulta por video con un médico de la red, reciba una receta digital verificable, y que el médico documente la atención en el expediente, con la disponibilidad médica sincronizada en tiempo real para evitar sobre-agenda.

2. Alcance y fuera de alcance

Qué va acá: qué SÍ resuelve el sistema y qué NO, con criterio. El “fuera de alcance” no es una lista de excusas: cada exclusión lleva su razón (por qué no aporta al objetivo del MVP, o por qué su costo no se justifica ahora). Acá aterrizan los huecos del TDR que decidieron no cubrir.

Ejemplo:

Dentro del alcance:

• Agenda de disponibilidad médica y reserva de consulta por franja.
• Consulta por video en tiempo real entre paciente y médico.
• Pago en línea de la consulta, con liberación del cupo si el pago no se completa.
• Emisión de receta digital con código de verificación público.
• Registro de la atención en el expediente del paciente (motivo, notas, receta).

Fuera del alcance (con su razón):

• Integración con farmacias para despacho automático de la receta. El MVP emite la receta verificable; el paciente la lleva a la farmacia que prefiera. Automatizar el despacho requiere convenios comerciales que exceden esta fase.
• Atención de urgencias. El sistema es para consultas de control programadas; una urgencia necesita protocolos y responsabilidad legal que no se resuelven con software en esta etapa.
• App móvil nativa. Se entrega una web responsiva; una app nativa duplica el esfuerzo sin aportar al objetivo del MVP (el video corre en el navegador).

3. Requerimientos funcionales

Qué va acá: qué hace el sistema, agrupado por módulo o por rol. Sean específicos: no “gestionar citas” sino qué operaciones concretas. Marquen cuáles vienen del TDR y cuáles infirieron ustedes.

Ejemplo (por módulo):

Agenda y reserva

• El médico publica su disponibilidad por franjas horarias.
• El paciente busca médicos por especialidad y reserva una franja libre.
• Una franja reservada deja de estar disponible para otros pacientes de inmediato (del TDR).
• Si el paciente no completa el pago en 10 minutos, la reserva expira y la franja se libera (inferido: el TDR pide “no sobre-agendar” pero no dice cómo manejar reservas sin pagar).

Consulta

• Al iniciar la franja, ambos entran a una sala de video privada.
• El médico documenta motivo, hallazgos y plan en el expediente durante o después de la consulta.

Receta

• El médico emite una receta digital asociada a la consulta.
• Cada receta tiene un código único verificable públicamente (una farmacia confirma que es real y no fue alterada) (del TDR).

4. Requerimientos no funcionales

Qué va acá: los atributos de calidad (qué tan bien funciona, no qué hace), con un criterio verificable en vez de un adjetivo. “Rápido” no dice nada; “conecta en menos de 5 s” sí. Poner números donde tenga sentido suma; lo mínimo es identificar los del TDR y no ignorarlos. Aten cada uno a algo del TDR. (El ejemplo de abajo usa números porque es nivel sobresaliente; un criterio claro sin número también cuenta.)

Ejemplo:

Atributo	Requerimiento	Por qué
Concurrencia	Soportar 200 consultas de video simultáneas sin degradar la calidad.	La red tiene 40 médicos que pueden coincidir en horario pico.
Consistencia	Una franja no puede reservarse dos veces, ni bajo reservas simultáneas.	Doble reserva = dos pacientes esperando al mismo médico. Es el riesgo central del TDR.
Disponibilidad	99.5% mensual en horario de atención (7am–9pm).	Una consulta caída es una atención médica interrumpida.
Seguridad y privacidad	Datos médicos cifrados en tránsito (TLS) y en reposo; acceso por rol.	Información clínica sensible; hay responsabilidad legal.
Auditoría	Todo acceso o cambio a un expediente queda registrado (quién, cuándo, qué).	Trazabilidad clínica exigible ante una disputa.
Latencia del video	< 300 ms de retardo extremo a extremo.	Por encima de eso la conversación médico-paciente se vuelve incómoda.

5. Arquitectura propuesta

Qué va acá: cómo se organiza el sistema. Los módulos nombrados (las piezas en que lo dividen), qué hace cada uno, cómo se comunican, dónde viven los datos, qué servicios externos se integran. Un diagrama (cajas para los módulos, flechas para lo que habla con qué; no tres cajas genéricas). Justifiquen las decisiones grandes: por qué esta forma y no otra. La arquitectura debe responder a los NFR de la sección 4.

✅ El piso (lo que se les pide): organizar el sistema en módulos, como el legacy. Piensen en el legacy que refactorizaron todo el curso: estaba dividido en piezas con una responsabilidad cada una (órdenes, notificaciones, pagos, y sus datos). Dibujar esos módulos, decir qué hace cada uno, cómo se comunican y dónde viven los datos, ya es una arquitectura válida y suficiente (nivel Competente). No necesitan servicios separados ni API Gateway.

⚠️ El ejemplo de abajo está por ENCIMA del piso. Usa arquitectura de servicios (API Gateway, componentes separados, proveedor externo) que no vimos en clase. Es referencia de cómo se justifica una decisión, no de cuánta arquitectura poner. Copiar la forma (muchas cajas) sin el criterio es la sobre-ingeniería que se penaliza.

Ejemplo (nivel sobresaliente, por encima de lo esperado):

Arquitectura de servicios sobre una API Gateway. El video no pasa por nuestros servidores (sería un cuello de botella para los NFR de concurrencia y latencia): se usa un proveedor de videollamada (WebRTC gestionado) y nuestro backend solo orquesta las salas.

                        ┌─────────────────┐
       Paciente ──────▶ │   API Gateway   │ ◀────── Médico
       (web)            └────────┬────────┘         (web)
                                 │
         ┌───────────────┬───────┼───────────┬──────────────┐
         ▼               ▼       ▼           ▼              ▼
   ┌──────────┐   ┌──────────┐ ┌──────┐ ┌──────────┐  ┌──────────┐
   │  Agenda  │   │ Consulta │ │Receta│ │Expediente│  │   Pago   │
   │ (reserva)│   │ (salas)  │ │ (QR) │ │  (notas) │  │(pasarela)│
   └────┬─────┘   └────┬─────┘ └──┬───┘ └────┬─────┘  └────┬─────┘
        │              │          │          │             │
        ▼              ▼          ▼          ▼             ▼
   ┌─────────────────────────────────────────┐    ┌──────────────┐
   │       Base de datos (PostgreSQL)         │    │ Pasarela ext.│
   └─────────────────────────────────────────┘    └──────────────┘
             │                         │
             ▼                         ▼
    ┌─────────────────┐      ┌──────────────────┐
    │ Proveedor video │      │ Servicio de email│
    │  (WebRTC ext.)  │      │  (notificaciones)│
    └─────────────────┘      └──────────────────┘

Decisiones clave:

• Reserva con bloqueo transaccional en el servicio de Agenda. La franja se marca ocupada dentro de una transacción para cumplir el NFR de consistencia bajo reservas simultáneas.
• El video se delega a un proveedor externo. Streamear video propio no cumpliría el NFR de 200 sesiones concurrentes sin una inversión de infraestructura fuera del alcance.
• Servicios separados por responsabilidad, no un monolito, para que Consulta (crítico en disponibilidad) escale independiente de Expediente (que tolera más carga).

6. Patrones de diseño

Qué va acá: qué patrones del catálogo aplican, DÓNDE en el sistema y POR QUÉ ese y no otro. Por cada patrón, un “cuándo NO lo usaría acá” que demuestre criterio. Aten cada patrón a un problema real de su arquitectura, no al catálogo. Los que el dominio pida con criterio (típicamente 3 a 6); si tu caso justifica solo 3 impecables, explicá por qué y no penaliza. Lo que baja la nota es el patrón forzado para llegar a un número, no la cantidad. Un snippet corto (hasta ~10 líneas, la interfaz del patrón) para ilustrar está bien, pero no es obligatorio; la justificación en prosa es lo que se evalúa.

✅ El piso (lo que se les pide): 3-4 patrones bien atados = sobresaliente. Lo que se evalúa no es cuántos, sino que cada uno esté puesto donde el dominio lo pide, con su “por qué ese y no otro” y su “cuándo NO”. Tres impecables valen más que seis forzados.

Ejemplo (nivel sobresaliente): este ejemplo usa 3 patrones, cada uno atado a un problema real del dominio. Podría meter más (Strategy para los precios, Facade para verificar la receta), pero no lo hace a propósito: esos serían patrones de catálogo, forzados para inflar el número. El de ustedes puede pedir 3-4; lo que importa es que cada uno se gane su lugar.

State · ciclo de vida de la consulta. Una consulta pasa por reservada → pagada → en curso → finalizada / cancelada / expirada, y cada transición tiene reglas (no se puede iniciar el video de una consulta impaga; una expirada libera el cupo). State encapsula esas reglas y evita un switch gigante regado por el código. Cuándo NO: si la consulta solo tuviera “abierta/cerrada” sin reglas de transición, State sería sobre-ingeniería.

(Snippet opcional, para ilustrar la forma del patrón, no hace falta más que esto:)

interface EstadoConsulta {
    iniciarVideo(): void;   // cada estado decide si puede
    cancelar(): void;
}
// Reservada, Pagada, EnCurso… implementan la interfaz;
// Consulta delega en su estado actual sin un switch gigante.

Observer · reacciones al pago de la consulta. Cuando una consulta se paga, tienen que pasar varias cosas independientes entre sí: confirmar la reserva de la franja, generar la sala de video y avisar al paciente. Acoplar esas tres dentro del código de pago lo vuelve frágil (agregar una cuarta reacción obliga a tocar el pago). Con Observer, el pago solo emite “consulta pagada” y cada reacción se suscribe por su cuenta. Cuándo NO: si hubiera una sola reacción y no fuera a crecer, un llamado directo es más claro que montar el mecanismo.

Adapter · integración con la pasarela de pago y con el proveedor de video. Ambos son servicios externos con sus propias APIs. Un Adapter los envuelve tras una interfaz nuestra, de modo que cambiar de proveedor de video no obligue a tocar el código de la consulta. Cuándo NO: si el proveedor fuera definitivo y su API estable, el adapter agregaría una capa sin retorno.

¿Y por qué NO otros? Strategy para el precio (particular/seguro/corporativo) sería el ejemplo de manual, pero el precio no es el núcleo de este MVP y meterlo solo suma un patrón sin resolver un problema real: queda fuera. Facade para verificar la receta suena bien, pero “¿existe? ¿no vencida? ¿no alterada?” son un puñado de validaciones, no un subsistema complejo que valga la pena esconder: un método validarReceta() normal alcanza. Nombrar por qué descartás un patrón es tan valioso como justificar los que usás.

7. Modelo de datos y stack tecnológico

Qué va acá: las entidades principales y sus relaciones (un diagrama o una lista clara), y las tecnologías elegidas con su porqué atado a un NFR o requerimiento, no a la moda. Incluyan por qué descartaron una alternativa obvia.

Ejemplo:

Entidades principales: Paciente, Médico, Disponibilidad (franjas), Consulta, Receta, Expediente (una entrada por Consulta), Pago. Relaciones clave: una Consulta pertenece a una Disponibilidad y a un Paciente; una Receta pertenece a una Consulta; un Expediente acumula las Consultas de un Paciente.

Stack:

• Backend: PHP 8 + Laravel. El equipo lo domina; su ORM y sistema de transacciones simplifican el bloqueo transaccional que exige el NFR de consistencia de la agenda.
• Base de datos: PostgreSQL. Necesitamos transacciones ACID confiables para la reserva de franjas. Descartamos una NoSQL: la consistencia fuerte aquí pesa más que la escala horizontal.
• Video: proveedor WebRTC gestionado (ej. una API de videollamada). Cumplir el NFR de 200 sesiones concurrentes con latencia < 300 ms construyendo video propio es inviable en el plazo.
• Frontend: web responsiva (sin framework pesado innecesario). El video corre en el navegador vía el SDK del proveedor; no se justifica una SPA compleja para el MVP.

8. Trade-offs, supuestos y riesgos

Qué va acá: tres cosas que separan una propuesta seria de una lista de deseos.

• Trade-offs: por cada decisión grande, qué alternativa descartaron y qué costo aceptaron.
• Supuestos: qué están asumiendo que el cliente debe cumplir (sin esto, la propuesta no aplica).
• Riesgos: qué puede salir mal, con su mitigación.

Ejemplo:

Trade-offs:

• Elegimos consistencia fuerte en la reserva (transacción con bloqueo) sobre máxima velocidad. Una reserva tarda un instante más, pero nunca se agenda dos veces la misma franja. Para un sistema médico, la correctitud vale más que ese milisegundo.
• Delegamos el video a un tercero en vez de construirlo. Ganamos cumplir los NFR de concurrencia y latencia sin infraestructura propia; aceptamos una dependencia externa y su costo por minuto.

Supuestos:

• La red provee los datos de sus médicos y sus habilitaciones vigentes.
• Existe una pasarela de pago contratada con API disponible.
• Los pacientes cuentan con dispositivo con cámara y una conexión mínima estable.

Riesgos:

Riesgo	Probabilidad	Mitigación
Conexión inestable del paciente corta el video	Alta	Reconexión automática a la sala; permitir reprogramar sin costo si la consulta se cae.
El proveedor de video cambia su API o su precio	Media	El Adapter aísla el proveedor; migrar no toca la lógica de Consulta.
Doble reserva bajo carga alta	Media	Bloqueo transaccional en la franja; pruebas de concurrencia antes del go-live.

9. Estimación (cierre corto)

Qué va acá: un par de párrafos, no un plan de proyecto. Esfuerzo aproximado (personas y roles), cronograma por fases y un costo estimado con los supuestos detrás. No tiene que ser una cotización real; solo tiene que ser coherente con el alcance y la arquitectura que ustedes propusieron. Una arquitectura de servicios con integración de video y pago no se construye en dos semanas.

Ejemplo: Estimamos un equipo de 4 personas (2 desarrolladores backend, 1 frontend, 1 QA) a lo largo de 12 semanas: 2 de discovery y diseño, 7 de desarrollo (agenda y consistencia primero, por ser el núcleo de riesgo), 2 de integración con video y pago, 1 de pruebas y puesta en marcha. A una tarifa referencial de $18/hora y ~40 h semanales por persona, el desarrollo ronda los $34,500, sin contar el costo por minuto del proveedor de video (operativo, a cargo del cliente). Supuestos: los accesos a la pasarela de pago y al proveedor de video están disponibles desde la semana 1.

Cómo estimar sin haberlo hecho nunca (un método simple): contá los componentes/módulos de su arquitectura, asigná semanas a cada uno según su dificultad, sumá una fase de diseño al inicio y una de pruebas al final, y multiplicá por un equipo razonable. Lo que se evalúa no es el número, es que el número no contradiga la solución que propusieron.

Glosario rápido (términos que usa esta plantilla)

• Requerimiento no funcional (NFR): qué tan bien funciona el sistema, no qué hace. Se vuelve verificable con un criterio: no “rápido” sino “responde en menos de X”; no “seguro” sino “acceso por rol, datos cifrados”. (Un requerimiento funcional es “el usuario reserva una cita”; el no funcional es “la reserva es consistente aunque dos usuarios la pidan a la vez”.)
• Módulo: una pieza del sistema con una responsabilidad clara (ej. “órdenes”, “pagos”, “notificaciones”), no una clase suelta. En el diagrama, cada caja es un módulo. (En el ejemplo de telemedicina, que es de nivel alto, a esas piezas se les dice “componentes” o “servicios”: es lo mismo, más grande.)
• Trade-off: una decisión donde ganás algo y sacrificás otra cosa. Documentarlo es decir qué ganaste, qué perdiste y por qué valió la pena.
• Supuesto: algo que están asumiendo que el cliente cumple y sin lo cual su propuesta no aplica (ej. “el cliente provee la lista de médicos y sus habilitaciones”).
• MVP: Minimum Viable Product, el producto mínimo útil: la versión más chica del sistema que ya resuelve el problema central del cliente. Todo lo demás va al “fuera de alcance” de esta fase.
• ACID: las cuatro garantías de una base de datos transaccional (Atomicidad, Consistencia, Aislamiento, Durabilidad). En corto: una operación pasa entera o no pasa, y dos operaciones simultáneas no se pisan. Es lo que asegura, por ejemplo, que una franja no se reserve dos veces.

TDR · T0 (EJEMPLO DE CLASE) · Plataforma de telemedicina

Red de Clínicas Privadas “Clínica Conecta”

Este es un TDR de ejemplo, para mostrar en clase cómo se ve el insumo (el TDR) del que nace una propuesta técnica. Es el “antes” que corresponde a la plantilla de propuesta (s10m-plantilla-propuesta.md), que es el “después”. NO se rifa: ningún grupo lo usa.

La organización y el cliente son ficticios, creados para la clase.

1. Sobre la organización

Clínica Conecta es una red de clínicas privadas con presencia en varias ciudades. Atiende consultas de medicina general y algunas especialidades. Hoy toda la atención es presencial: el paciente pide cita por teléfono, se traslada a la clínica y espera su turno.

Buena parte de la agenda se ocupa con consultas de control que no requieren presencia física: renovar una receta, revisar el resultado de un examen, un seguimiento breve. Estas consultas saturan los consultorios y hacen que un paciente que sí necesita atención presencial espere hasta tres semanas por un cupo. Además, cuando un paciente no llega a su cita, ese cupo se pierde: nadie más pudo usarlo.

2. Objetivo

Contar con una plataforma que permita ofrecer consulta médica por video para los casos que no requieren presencia física, liberando la agenda presencial y reduciendo los tiempos de espera.

3. Alcance solicitado

Desde que un paciente agenda una consulta remota hasta que recibe su receta digital, incluyendo la consulta por video y el registro de la atención. La disponibilidad de los médicos debe manejarse de forma que no se generen sobre-agendas.

4. Requerimientos funcionales

• El médico publica su disponibilidad para consultas remotas por franjas horarias.
• El paciente busca por especialidad y reserva una franja libre.
• Una franja reservada deja de estar disponible para otros pacientes de inmediato.
• El paciente paga la consulta en línea antes de la atención.
• A la hora de la consulta, médico y paciente se conectan por video.
• El médico registra la atención (motivo, hallazgos, indicaciones) en el expediente del paciente.
• El médico emite una receta digital asociada a la consulta.
• La receta puede verificarse públicamente (una farmacia confirma que es auténtica y no fue alterada) mediante un código o enlace.

5. Roles de usuario

• Paciente: agenda, paga y realiza su consulta; consulta sus recetas.
• Médico: publica disponibilidad, atiende, documenta y receta.
• Personal administrativo: gestiona médicos, especialidades y reportes de atención.

6. Requerimientos no funcionales

• La consulta por video debe funcionar de forma fluida, sin cortes ni retardos molestos, aun con varias consultas ocurriendo al mismo tiempo.
• Una franja no puede reservarse dos veces, aunque dos pacientes intenten tomarla a la vez.
• La información clínica es sensible: debe protegerse y solo verla quien corresponde.
• Debe quedar registro de quién accedió o modificó cada expediente.
• La plataforma debe estar disponible en el horario de atención sin interrupciones.

7. Restricciones

• Los pacientes acceden desde su casa, con dispositivos y conexiones variables.
• El pago en línea se procesará con una pasarela de pago que la red ya tiene contratada.
• El sistema debe integrarse con la información de médicos y especialidades que la red ya maneja.

8. Lo que este TDR NO resuelve (a propósito)

El cliente describe qué necesita, pero no dice cómo construirlo. No define la arquitectura, ni qué tecnología usar para el video, ni cómo garantizar que una franja no se reserve dos veces, ni qué pasa si un paciente no paga a tiempo. Todo eso lo resuelve el proveedor en su propuesta. Esos son los huecos que una buena propuesta técnica llena con criterio.