Examen final · un TDR por grupo

Los 6 TDR

Cada grupo trabaja el TDR que le tocó por sorteo. Son casos ficticios pero realistas del contexto salvadoreño, calibrados con el mismo criterio. Recuerden: el TDR dice qué se necesita; el cómo lo deciden ustedes en la propuesta.

← Consigna, rúbrica y plantilla del examen

TDR · T1 · Sistema de expedientes y citas

Asociación de Salud Comunitaria “Clínicas del Bálsamo”

Términos de Referencia para el diseño de una solución de software. El presente documento describe la necesidad de la organización. La propuesta de solución (arquitectura, tecnología y diseño) es responsabilidad del equipo proveedor.

Nota: la organización y el cliente de este TDR son ficticios, creados para la clase. El tipo de problema es realista, pero no representan a ninguna entidad real.

1. Sobre la organización

Clínicas del Bálsamo es una asociación sin fines de lucro que opera cuatro clínicas comunitarias en la zona rural de La Libertad. Atiende a población de bajos recursos con consulta general, control prenatal, vacunación y odontología. Hoy los expedientes son en papel y las citas se anotan en un cuaderno por clínica. Cuando un paciente se atiende en una clínica distinta a la habitual, su historial no viaja con él.

La asociación se financia con donantes internacionales que exigen reportes de atención (cuántos pacientes, qué tipo de consulta, resultados de programas como el control prenatal). Hoy esos reportes se arman a mano y tardan semanas.

2. Objetivo

Contar con un sistema que centralice los expedientes de los pacientes y la gestión de citas de las cuatro clínicas, de modo que el historial de un paciente esté disponible en cualquiera de ellas, y que los reportes para donantes se generen de forma automática.

3. Alcance solicitado

El sistema debe cubrir el ciclo de atención: registro del paciente, agenda de citas, consulta (con notas del profesional), y reportería. Debe operar en las cuatro clínicas de forma unificada.

4. Requerimientos funcionales

Registro de pacientes con expediente único (una persona, un expediente, sin importar la clínica).
Agenda de citas por clínica y por profesional, con estados de la cita: solicitada, confirmada, atendida, no-asistió, cancelada.
Registro de la consulta: motivo, notas del profesional, indicaciones, próximo control.
Historial clínico del paciente consultable desde cualquier clínica.
Recordatorio de cita al paciente por mensaje de texto (SMS) el día previo.
Reportes de atención por período, por clínica, por tipo de consulta y por programa (ej. control prenatal), exportables para donantes.
Distintos tipos de consulta (general, prenatal, vacunación, odontología) capturan datos distintos, pero todas comparten el flujo de la cita.

5. Roles de usuario

Recepcionista: registra pacientes, agenda y confirma citas.
Profesional de salud (médico / odontólogo / enfermería): atiende y registra la consulta.
Coordinador de clínica: ve la agenda de su clínica, reasigna citas.
Administrador de la asociación: acceso a las cuatro clínicas y a la reportería para donantes.

6. Requerimientos no funcionales

Auditoría / trazabilidad: todo acceso o cambio a un expediente debe quedar registrado (quién, cuándo, qué), es información médica sensible y los donantes lo exigen.
Confidencialidad: un profesional solo debe ver expedientes de pacientes que atiende; no toda la base.
Disponibilidad en conexión intermitente: las clínicas rurales tienen internet inestable; la agenda del día debe poder consultarse aunque la conexión se caiga por momentos.
Interfaz simple: el personal no es técnico.

7. Restricciones

Presupuesto acotado (organización sin fines de lucro): preferencia por tecnologías sin costos de licencia altos.
El personal usa computadoras de escritorio en recepción y algún dispositivo móvil en consulta.
El envío de SMS se hará a través de un proveedor externo (la asociación ya tiene contrato con uno; el sistema debe integrarse con su API).

8. Entregables esperados del proveedor

Un documento de solución que describa la arquitectura propuesta, las decisiones de diseño, el stack tecnológico justificado y los riesgos identificados. (No se solicita implementación en esta fase.)

TDR · T2 · Plataforma de gestión de microcréditos

Cooperativa de Ahorro y Crédito “ACACES de R.L.”

Términos de Referencia para el diseño de una solución de software. El presente documento describe la necesidad de la organización. La propuesta de solución (arquitectura, tecnología y diseño) es responsabilidad del equipo proveedor.

Nota: la organización y el cliente de este TDR son ficticios, creados para la clase. El tipo de problema es realista, pero no representan a ninguna entidad real.

1. Sobre la organización

ACACES es una cooperativa de ahorro y crédito con seis mil asociados en el oriente del país. Su producto principal es el microcrédito: préstamos pequeños para negocios familiares, agricultura y consumo. Hoy la evaluación de un crédito se lleva en hojas de cálculo y expedientes físicos; la aprobación pasa por varias personas que firman un formulario en papel, y el cálculo de la cuota y la mora se hace manualmente, lo que genera errores y reclamos.

2. Objetivo

Contar con una plataforma que gestione el ciclo completo del microcrédito: solicitud, evaluación, aprobación, desembolso y seguimiento de pagos (incluida la mora), reemplazando el proceso manual actual.

3. Alcance solicitado

Desde que un asociado solicita un crédito hasta que termina de pagarlo. Incluye el flujo de aprobación por niveles y el cálculo automático de cuotas, intereses y mora.

4. Requerimientos funcionales

Registro de la solicitud de crédito con los datos del asociado, monto y destino.
Flujo de aprobación por niveles según el monto: un crédito pequeño lo aprueba el asesor; uno mediano requiere además al jefe de agencia; uno grande sube al comité de crédito. Cada nivel puede aprobar, rechazar o pedir más información.
Cálculo automático de la tabla de amortización (cuotas, intereses) según el tipo de producto crediticio.
Distintos tipos de producto (agrícola, comercial, consumo) calculan el interés de forma distinta, pero comparten el flujo de solicitud y aprobación.
Registro de pagos y cálculo automático de mora cuando una cuota se vence.
Notificación al asociado en hitos: crédito aprobado, cuota próxima a vencer, cuota en mora.
Historial de créditos del asociado.

5. Roles de usuario

Asesor de crédito: ingresa solicitudes, aprueba en primer nivel.
Jefe de agencia: aprueba en segundo nivel, ve la cartera de su agencia.
Comité de crédito: aprueba montos altos.
Cajero: registra los pagos de cuotas.
Administrador: configura productos crediticios, tasas y reglas de aprobación.

6. Requerimientos no funcionales

Trazabilidad / auditoría: cada aprobación, rechazo o cambio en un crédito debe quedar registrado con quién y cuándo (es dinero de los asociados; hay auditorías externas).
Exactitud: el cálculo de cuotas y mora no puede tener errores de redondeo; es la fuente de reclamos actual.
Concurrencia: en fin de mes muchos cajeros registran pagos simultáneamente; el sistema debe manejar la carga sin bloquear.
Seguridad: acceso por rol; un cajero no puede aprobar créditos ni ver la cartera completa.

7. Restricciones

La cooperativa opera en cinco agencias; el sistema es central pero usado desde todas.
Debe integrarse con el sistema contable existente de la cooperativa (para registrar desembolsos y pagos) a través de la API que ese sistema expone.
Las reglas de aprobación por monto pueden cambiar por decisión del consejo; deben ser configurables sin reprogramar.

8. Entregables esperados del proveedor

TDR · T3 · Sistema de trazabilidad de café

Cooperativa Cafetalera “Cumbres de Apaneca de R.L.”

Términos de Referencia para el diseño de una solución de software. El presente documento describe la necesidad de la organización. La propuesta de solución (arquitectura, tecnología y diseño) es responsabilidad del equipo proveedor.

Nota: la organización y el cliente de este TDR son ficticios, creados para la clase. El tipo de problema es realista, pero no representan a ninguna entidad real.

1. Sobre la organización

Cumbres de Apaneca agrupa a 120 productores de café de altura en la zona de Apaneca-Ilamatepec. Exporta café a compradores en Europa que pagan un sobreprecio por café con trazabilidad y certificaciones (orgánico, comercio justo). Hoy la trazabilidad se lleva en cuadernos y hojas de cálculo: cuando un comprador pregunta “¿de qué fincas salió este lote?”, reconstruir la respuesta toma días, y a veces no se puede probar.

2. Objetivo

Contar con un sistema que registre la cadena de custodia del café desde la finca hasta el contenedor de exportación, de modo que cualquier lote exportado pueda rastrearse hasta las fincas que lo componen, con sus certificaciones asociadas.

3. Alcance solicitado

Registrar cada paso por el que pasa el café (recolección en finca → recibo en beneficio → despulpado → secado → clasificación → conformación del lote de exportación), manteniendo la trazabilidad de qué entró en qué.

4. Requerimientos funcionales

Registro de entregas de café por productor en la finca (peso, fecha, variedad).
Registro de cada etapa de proceso (despulpado, secado, clasificación), donde el café de varias entregas se mezcla y avanza. El sistema debe mantener de qué entregas proviene cada resultado.
Conformación de lotes de exportación que agrupan café ya procesado, posiblemente de varias etapas y fincas.
Consulta de trazabilidad inversa: dado un lote de exportación, listar las fincas y entregas que lo componen.
Registro de certificaciones (orgánico, comercio justo) a nivel de finca, que se propagan a los lotes que contienen su café.
Distintos tipos de proceso (lavado, honey, natural) tienen etapas distintas, pero todos parten de una entrega y terminan en un lote.
Reportes para compradores y para las certificadoras.

5. Roles de usuario

Técnico de campo: registra las entregas en las fincas.
Operario de beneficio: registra las etapas de proceso.
Encargado de exportación: conforma los lotes y genera la trazabilidad.
Administrador de la cooperativa: gestiona productores, fincas y certificaciones.

6. Requerimientos no funcionales

Operación offline en finca: los técnicos registran entregas en fincas sin cobertura; los datos deben capturarse localmente y sincronizarse al recuperar conexión.
Integridad de la cadena: una vez registrada una etapa, no debe poder alterarse sin dejar rastro (auditoría), es la base de la confianza del comprador.
Trazabilidad completa: ningún lote exportado puede quedar sin su origen; el sistema debe impedir cerrar un lote cuyo origen no esté completo.
Interfaz simple para personal de campo, usable desde el celular.

7. Restricciones

Los técnicos de campo usan teléfonos de gama media; el beneficio tiene una computadora.
La certificación orgánica tiene una fecha de vigencia; el sistema debe reflejar cuándo una finca deja de estar certificada.
El período de cosecha concentra casi toda la carga en pocos meses del año.

8. Entregables esperados del proveedor

TDR · T4 · Sistema de gestión de becas

Fundación Educativa “Semilla de Futuro”

Términos de Referencia para el diseño de una solución de software. El presente documento describe la necesidad de la organización. La propuesta de solución (arquitectura, tecnología y diseño) es responsabilidad del equipo proveedor.

Nota: la organización y el cliente de este TDR son ficticios, creados para la clase. El tipo de problema es realista, pero no representan a ninguna entidad real.

1. Sobre la organización

Semilla de Futuro es una fundación que otorga becas de estudio a jóvenes de escasos recursos para bachillerato y universidad. Recibe fondos de empresas y donantes individuales, cada uno con condiciones (una empresa financia becas de carreras técnicas; otra, solo mujeres en STEM). Hoy las convocatorias se gestionan por correo y hojas de cálculo: reciben cientos de postulaciones, las evalúan a mano con criterios que varían por convocatoria, y el seguimiento del desembolso y del rendimiento del becario se pierde.

2. Objetivo

Contar con un sistema que gestione el ciclo de la beca: convocatoria, postulación, evaluación multi-criterio, adjudicación, desembolso por tramos y seguimiento del becario, con reportes para los donantes que financian cada beca.

3. Alcance solicitado

Desde que se abre una convocatoria hasta que un becario termina (o pierde) su beca. Incluye la evaluación con criterios configurables y el desembolso condicionado al rendimiento.

4. Requerimientos funcionales

Creación de convocatorias con sus requisitos y su fondo asociado (qué donante la financia, cuántas becas, condiciones).
Postulación en línea del aspirante con sus documentos.
Evaluación multi-criterio: cada postulación se puntúa por varios criterios (situación socioeconómica, mérito académico, entrevista) cuyo peso varía por convocatoria.
Distintos tipos de beca (bachillerato, universidad, técnica) tienen requisitos y criterios distintos, pero comparten el flujo de postulación y evaluación.
Adjudicación: ranking de postulantes y selección según el cupo del fondo.
Desembolso por tramos condicionado: el siguiente tramo se libera solo si el becario cumple el requisito de rendimiento (ej. promedio mínimo) del período anterior.
Seguimiento del becario: notas del período, estado de la beca (activa, en riesgo, suspendida, finalizada).
Notificación al postulante (seleccionado / no seleccionado) y al becario (tramo liberado, beca en riesgo).
Reportes por fondo/donante: cuántas becas, en qué carreras, con qué resultados.

5. Roles de usuario

Postulante / becario: postula, sube documentos y notas.
Evaluador: puntúa postulaciones según los criterios de la convocatoria.
Coordinador de becas: crea convocatorias, adjudica, gestiona desembolsos.
Administrador / enlace con donantes: ve reportes por fondo, configura los fondos.

6. Requerimientos no funcionales

Trazabilidad: la evaluación y la adjudicación deben ser auditables (los donantes exigen transparencia sobre por qué se eligió a cada becario).
Confidencialidad: los datos socioeconómicos de los postulantes son sensibles; acceso por rol.
Picos de carga: al cierre de una convocatoria entran cientos de postulaciones en pocos días.
Configurabilidad: los criterios de evaluación y sus pesos deben poder definirse por convocatoria sin reprogramar.

7. Restricciones

Presupuesto de fundación: preferencia por bajo costo operativo.
Los postulantes acceden desde el celular, con conexión variable.
Cada fondo/donante tiene sus condiciones; el sistema debe respetarlas sin crear un flujo distinto por donante.

8. Entregables esperados del proveedor

TDR · T5 · Sistema de despacho y rutas

Distribuidora de Agua Envasada “Agua Cristalina, S.A. de C.V.”

Términos de Referencia para el diseño de una solución de software. El presente documento describe la necesidad de la organización. La propuesta de solución (arquitectura, tecnología y diseño) es responsabilidad del equipo proveedor.

Nota: la organización y el cliente de este TDR son ficticios, creados para la clase. El tipo de problema es realista, pero no representan a ninguna entidad real.

1. Sobre la organización

Agua Cristalina embotella y distribuye agua en garrafones y botellas a hogares y negocios en el área metropolitana de San Salvador. Tiene una flota de doce camiones con sus repartidores. Hoy los pedidos se toman por teléfono y WhatsApp, las rutas se arman a mano cada mañana en una pizarra, y el cobro en ruta se registra en un talonario. Se pierden pedidos, hay clientes que reclaman que “no pasó el camión”, y la caja no cuadra con lo despachado.

2. Objetivo

Contar con un sistema que gestione pedidos, armado de rutas de reparto y cobro en ruta, de modo que cada camión salga con su ruta del día, los repartidores registren entregas y cobros, y la administración concilie lo despachado con lo cobrado.

3. Alcance solicitado

Desde que entra un pedido (puntual o recurrente) hasta que se entrega y se cobra en ruta, con el armado de las rutas diarias y la conciliación.

4. Requerimientos funcionales

Registro de pedidos: puntuales y recurrentes (ej. un negocio que recibe 10 garrafones cada lunes). Los recurrentes generan el pedido del día automáticamente.
Armado de rutas diarias: asignar los pedidos del día a los camiones según zona.
Estados de la entrega: programada, en ruta, entregada, no-entregada (cliente ausente), reprogramada.
Registro de cobro en ruta por el repartidor: efectivo, y en algunos clientes, transferencia.
Distintos tipos de cliente (hogar, negocio con crédito, mayorista) tienen precios y condiciones de pago distintos, pero comparten el flujo de pedido y entrega.
Notificación al cliente cuando su pedido va en ruta.
Conciliación al cierre del día: lo despachado vs. lo entregado vs. lo cobrado por camión.

5. Roles de usuario

Teleoperador: toma pedidos, gestiona los recurrentes.
Despachador: arma las rutas del día y asigna camiones.
Repartidor: ve su ruta, marca entregas y registra cobros (desde el celular).
Administrador / caja: concilia despacho vs. cobro, gestiona precios y clientes.

6. Requerimientos no funcionales

Operación en ruta con conexión intermitente: el repartidor marca entregas y cobros en la calle, donde la señal falla; debe capturarse localmente y sincronizarse.
Exactitud del dinero: el cobro registrado debe cuadrar con la conciliación; es el problema actual. No puede haber ambigüedad en cuánto cobró cada repartidor.
Concurrencia: en la mañana, varios despachadores y muchos pedidos entran a la vez al armar rutas.
Trazabilidad: quién marcó cada entrega y cobro, y cuándo.

7. Restricciones

Los repartidores usan teléfonos de gama media provistos por la empresa.
El pago con transferencia se valida contra la cuenta bancaria de la empresa mediante la API del banco (ya disponible).
La zona de reparto está dividida en sectores fijos; un camión atiende uno o dos sectores.

8. Entregables esperados del proveedor

TDR · T6 · Sistema de reservas y control de aforo

Red de Parques Recreativos “Turismo Municipal de Sonsonate”

Términos de Referencia para el diseño de una solución de software. El presente documento describe la necesidad de la organización. La propuesta de solución (arquitectura, tecnología y diseño) es responsabilidad del equipo proveedor.

Nota: la organización y el cliente de este TDR son ficticios, creados para la clase. El tipo de problema es realista, pero no representan a ninguna entidad real.

1. Sobre la organización

La alcaldía de Sonsonate administra una red de tres parques recreativos (un balneario, un parque ecológico y un centro turístico con senderos). Los fines de semana y días festivos los parques se saturan: llegan más visitantes de los que el lugar soporta, se forman filas en la entrada y hay quejas por sobrecupo. Hoy la entrada se cobra en efectivo en taquilla y no hay forma de saber cuánta gente hay adentro hasta que ya es un problema.

2. Objetivo

Contar con un sistema de reservas en línea y control de aforo en tiempo real que permita al visitante reservar su entrada por franja horaria, pagar en línea, y a los parques controlar cuánta gente ingresa para no exceder el aforo.

3. Alcance solicitado

Desde que un visitante reserva una entrada hasta que ingresa al parque, con control del aforo por franja horaria y la reportería de ocupación e ingresos.

4. Requerimientos funcionales

Reserva en línea de entradas por parque y franja horaria (mañana / tarde), con cupo máximo por franja según el aforo del parque.
Distintos tipos de visitante (adulto, niño, adulto mayor, grupo escolar) pagan tarifas distintas, pero comparten el flujo de reserva.
Pago en línea de la reserva; si el pago no se completa en cierto tiempo, la reserva se libera y el cupo vuelve a estar disponible.
Estados de la reserva: pendiente de pago, confirmada, usada (ingresó), expirada, cancelada.
Control de aforo en tiempo real: al ingresar un visitante (validando su reserva en la entrada), el sistema descuenta del aforo de esa franja e impide sobrecupo.
Venta en taquilla para quien llega sin reserva, siempre que quede cupo en la franja actual.
Notificación al visitante: reserva confirmada, recordatorio el día previo.
Reportes de ocupación por parque/franja e ingresos por período.

5. Roles de usuario

Visitante: reserva y paga en línea.
Personal de entrada: valida reservas e ingresa visitantes; vende en taquilla.
Administrador de parque: ve la ocupación de su parque, ajusta cupos por franja.
Administración municipal: reportes de los tres parques, configura tarifas y aforos.

6. Requerimientos no funcionales

Concurrencia / no sobrecupo: en un festivo, muchos visitantes reservan la misma franja al mismo tiempo; el sistema no puede vender más entradas que el aforo aunque las reservas entren simultáneamente. Es el requerimiento crítico.
Consistencia del aforo en tiempo real: el conteo de gente adentro debe ser confiable en el momento (es un tema de seguridad, no solo de negocio).
Disponibilidad en picos: la carga se concentra en fines de semana y festivos.
Trazabilidad: cada ingreso y cada venta en taquilla registrados.

7. Restricciones

El pago en línea se procesa con una pasarela de pagos externa (la alcaldía ya tiene convenio); el sistema se integra con su API.
El personal de entrada usa una tablet en la puerta; la conexión en los parques es aceptable pero no perfecta.
Las tarifas y el aforo de cada parque los define la administración municipal y pueden cambiar por temporada.