En este último tema integraremos los conceptos principales del curso mediante un caso práctico. La idea no es construir código completo, sino recorrer el razonamiento de la Ingeniería de Software desde una necesidad inicial hasta una solución que pueda desarrollarse, probarse, entregarse y mantenerse.
El caso mostrará cómo se conectan requerimientos, análisis, diseño, arquitectura, construcción, pruebas, calidad, despliegue, documentación, mantenimiento y gestión del proyecto.
Una clínica recibe muchas llamadas telefónicas para reservar, cambiar o cancelar turnos médicos. El personal administrativo dedica varias horas por día a estas tareas, los pacientes no siempre logran comunicarse y se producen confusiones con horarios, profesionales y especialidades.
La organización plantea una necesidad general: quiere un sistema que permita gestionar turnos de manera más ordenada, reducir llamadas y mejorar la experiencia de pacientes y personal interno.
Punto de partida: todavía no tenemos una solución técnica. Tenemos un problema del mundo real que debe analizarse antes de decidir qué software construir.
Antes de definir funcionalidades, conviene identificar a las personas y grupos afectados por el sistema. Cada interesado puede tener necesidades, restricciones y expectativas diferentes.
| Interesado | Necesidad principal |
|---|---|
| Pacientes | Reservar, consultar, cambiar o cancelar turnos de forma simple. |
| Personal administrativo | Gestionar agendas, resolver consultas y corregir problemas. |
| Profesionales médicos | Consultar su agenda y conocer los pacientes asignados. |
| Dirección de la clínica | Reducir costos operativos y mejorar la calidad del servicio. |
| Equipo técnico | Construir, desplegar, mantener y proteger el sistema. |
Los objetivos permiten orientar el proyecto y evaluar si la solución aporta valor. Deben expresar resultados esperados, no solamente funciones aisladas.
Definir el alcance ayuda a separar qué se construirá en una primera versión y qué quedará para futuras etapas. Esto evita que el proyecto crezca sin control.
| Incluido en la primera versión | Fuera de la primera versión |
|---|---|
| Registro e inicio de sesión de pacientes. | Historia clínica completa. |
| Búsqueda de turnos por especialidad, profesional y fecha. | Videoconsultas médicas. |
| Reserva, cancelación y consulta de turnos. | Facturación y pagos en línea. |
| Panel administrativo básico para agendas. | Integración con sistemas externos de obras sociales. |
| Recordatorios por correo electrónico. | Aplicación móvil nativa. |
Los requerimientos funcionales describen comportamientos o servicios que el sistema debe ofrecer. Para este caso, algunos ejemplos son:
Los requerimientos no funcionales definen condiciones de calidad, restricciones y atributos que la solución debe cumplir.
Una historia de usuario permite expresar una necesidad desde la perspectiva de quien usará el sistema. Los criterios de aceptación ayudan a definir cuándo esa historia puede considerarse cumplida.
Historia: como paciente, quiero buscar turnos disponibles por especialidad para elegir un horario que se ajuste a mi disponibilidad.
El modelo de dominio identifica conceptos importantes del negocio y sus relaciones. No es todavía una base de datos ni una implementación, sino una forma de comprender el problema.
A partir del análisis, el sistema puede dividirse en responsabilidades. Esta división ayuda a organizar el código y reducir acoplamiento.
| Módulo | Responsabilidad |
|---|---|
| Usuarios y acceso | Registro, inicio de sesión, roles y permisos. |
| Agenda médica | Disponibilidad de profesionales y horarios de atención. |
| Turnos | Búsqueda, reserva, cancelación y consulta de turnos. |
| Notificaciones | Envío de recordatorios y avisos. |
| Administración | Gestión interna de especialidades, profesionales y agendas. |
Para una primera versión, el equipo podría elegir una aplicación web con interfaz para pacientes y personal administrativo, una API para la lógica de negocio y una base de datos relacional para almacenar usuarios, profesionales, agendas y turnos.
Esta decisión debe justificarse según el contexto: permite acceso desde navegadores, facilita una primera entrega, centraliza datos y deja abierta la posibilidad de integrar una aplicación móvil en el futuro.
Como el sistema trabaja con datos personales, la seguridad y la privacidad deben considerarse desde el diseño.
La solución debe ser fácil de usar, especialmente para pacientes que pueden tener distintos niveles de experiencia digital. La interfaz debe guiar la tarea principal: encontrar y confirmar un turno.
El equipo puede construir el sistema en incrementos. Así obtiene retroalimentación temprana y evita esperar hasta el final para descubrir problemas de alcance, diseño o experiencia de usuario.
Las pruebas deben cubrir tanto reglas funcionales como atributos de calidad. Para este caso, algunas pruebas importantes son:
La documentación debe concentrarse en información útil para operar, mantener y evolucionar el sistema.
El equipo debe estimar el trabajo, identificar riesgos y hacer seguimiento continuo. En este caso, algunos riesgos relevantes podrían ser:
| Riesgo | Acción posible |
|---|---|
| Reglas de agenda poco claras. | Realizar entrevistas y validar ejemplos con personal administrativo. |
| Recordatorios que no llegan correctamente. | Probar temprano el servicio de correo y registrar fallos. |
| Usuarios con poca experiencia digital. | Validar prototipos con pacientes representativos. |
| Datos sensibles expuestos por error. | Revisar permisos, mensajes, registros y pruebas de acceso. |
Antes de pasar a producción, se debe definir cómo se configurará, desplegará, monitoreará y respaldará el sistema. También es necesario preparar un plan de comunicación para usuarios internos y pacientes.
Después de la primera entrega, aparecerán nuevas necesidades: integración con pagos, aplicación móvil, reportes para dirección, conexión con sistemas externos o mejoras en la experiencia de usuario.
Para evolucionar sin perder calidad, el equipo deberá gestionar cambios, priorizar solicitudes, mantener pruebas, revisar deuda técnica, actualizar documentación y cuidar la arquitectura.
| Etapa | Pregunta guía | Resultado esperado |
|---|---|---|
| Necesidad | ¿Qué problema real queremos resolver? | Reducir llamadas y ordenar la gestión de turnos. |
| Requerimientos | ¿Qué debe hacer el sistema y bajo qué condiciones? | Funcionalidades, restricciones y criterios de aceptación. |
| Análisis | ¿Qué conceptos del negocio debemos comprender? | Modelo de dominio inicial. |
| Diseño | ¿Cómo organizaremos responsabilidades y componentes? | Módulos, interfaces y decisiones de arquitectura. |
| Construcción | ¿Cómo implementaremos la solución por incrementos? | Versiones funcionales progresivas. |
| Pruebas | ¿Cómo verificaremos comportamiento y calidad? | Casos de prueba, pruebas de calidad y evidencias. |
| Operación | ¿Cómo desplegaremos y sostendremos el sistema? | Ambientes, monitoreo, soporte y recuperación. |
| Evolución | ¿Cómo seguirá cambiando el producto? | Mantenimiento, priorización y control de deuda técnica. |
Este caso práctico muestra que desarrollar software profesionalmente requiere mucho más que programar. La Ingeniería de Software aporta métodos, criterios y prácticas para comprender problemas, diseñar soluciones, trabajar en equipo, controlar cambios, cuidar la calidad y sostener productos en el tiempo.
Con este recorrido finaliza el curso de Introducción a la Ingeniería de Software. A partir de aquí, cada tema puede estudiarse con mayor profundidad en cursos específicos sobre requerimientos, casos de uso, UML, modelado de dominio, documentación técnica, mantenimiento, deuda técnica, calidad y ciclo de vida del software.