Análisis y desarrollo de un sistema de control de asistencia: requisitos, diseño y validación

Antes de escribir código, el proyecto debe responder una pregunta básica: ¿qué problema operativo debe resolver el sistema? El alcance no se define por una lista de pantallas, sino por los procesos que necesitan quedar controlados y por los resultados que deben poder verificarse.

Separar necesidad, alcance y solución

Una necesidad puede ser consolidar marcaciones dispersas, disminuir correcciones manuales, administrar turnos variables o cerrar un periodo con menos pendientes. El alcance determina qué parte de esa necesidad se resolverá en la primera versión. La solución técnica se decide después, cuando ya existe claridad sobre usuarios, datos y reglas.

Un documento de alcance útil debería precisar, como mínimo:

• qué grupos de personas estarán incluidos y cuáles quedan fuera;
• qué sedes, turnos, modalidades o escenarios operativos deben contemplarse;
• qué eventos se registrarán: entrada, salida, pausas u otros definidos por la organización;
• qué incidencias deben detectarse y quién podrá resolverlas;
• qué resultado debe existir al cerrar el periodo;
• qué procesos posteriores consumirán ese resultado.

Trabajar con una línea base del proceso actual

Conviene mapear cómo se realiza hoy el proceso, incluso si es manual. Esto permite identificar puntos donde se duplican datos, decisiones que dependen de una persona, reglas que solo existen de manera informal y excepciones que aparecen con frecuencia. Esa línea base ayuda a decidir qué debe conservarse, simplificarse o eliminarse.

Ejemplo conceptual: si el problema principal es que RR.HH. recibe correcciones desde distintos canales, la primera versión puede concentrarse en registrar incidencias y resolverlas dentro de un flujo trazable. Añadir módulos ajenos al problema aumentaría el alcance sin mejorar el resultado que se busca.

Un sistema de asistencia conecta personas con responsabilidades distintas. Diseñarlo solo desde la perspectiva del colaborador que marca deja fuera decisiones críticas: quién asigna horarios, quién revisa incidencias, quién autoriza correcciones, quién cierra el periodo y quién administra la configuración.

Construir un mapa de actores

El análisis puede comenzar con actores funcionales, sin asumir todavía nombres de perfiles técnicos:

• colaborador: registra eventos y consulta su información cuando corresponda;
• supervisor: revisa situaciones de su equipo y participa en validaciones definidas;
• administración de personal o RR.HH.: gobierna reglas, excepciones y cierre;
• operaciones: aporta la lógica de turnos, cobertura y escenarios reales;
• tecnología o administración del sistema: gestiona configuración técnica, accesos e integraciones;
• procesos consumidores: reciben información ya validada para continuar su propio flujo.

Pasar de actores a casos de uso

Cada actor debe asociarse a acciones concretas: registrar, consultar, asignar, corregir, aprobar, rechazar, cerrar, reabrir o exportar. Un buen caso de uso describe el objetivo, las condiciones previas, el flujo normal, las excepciones y el resultado esperado. Esto evita requisitos ambiguos como “el supervisor administra asistencia” sin precisar qué puede hacer realmente.

Definir límites de responsabilidad

El análisis también debe responder quién puede modificar qué información y en qué momento. Por ejemplo, permitir que un mismo usuario cree, apruebe y cierre una corrección puede ser funcionalmente cómodo, pero debilita la trazabilidad. La responsabilidad debe diseñarse de forma explícita y luego traducirse a permisos y flujos.

Los requisitos son el contrato entre la necesidad del negocio y el desarrollo. Deben poder leerse, discutirse y probarse. Expresiones como “el sistema debe ser rápido”, “debe ser flexible” o “debe controlar bien la asistencia” no son suficientes porque no indican qué comportamiento se espera ni cómo comprobarlo.

Requisitos funcionales

Describen lo que el sistema debe hacer. Dependiendo del alcance, pueden incluir:

• registrar y conservar marcaciones originales;
• asignar o consultar el horario aplicable;
• comparar eventos registrados con reglas definidas;
• generar incidencias por condiciones concretas;
• solicitar y resolver correcciones;
• aplicar aprobaciones según responsabilidad;
• cerrar un periodo y producir un resultado validado;
• entregar información a procesos posteriores.

Requisitos no funcionales

Definen la calidad con la que debe operar el sistema: disponibilidad esperada, tiempos de respuesta aceptables, protección de datos, trazabilidad, recuperación ante fallos, mantenibilidad, capacidad de crecimiento y facilidad de uso. No son “extras”; condicionan arquitectura, pruebas y operación.

Redactar requisitos verificables

Cada requisito debería tener una condición observable. En vez de “el sistema debe controlar marcaciones duplicadas”, es mejor definir qué se considera duplicado, qué intervalo se evalúa, qué resultado produce y quién puede resolverlo. La verificabilidad evita discusiones al final del proyecto sobre si una funcionalidad está realmente terminada.

El modelo de datos determina qué podrá reconstruirse después. Un diseño pobre puede mostrar una pantalla correcta y aun así perder el origen de una marcación, mezclar datos originales con correcciones o impedir saber qué regla produjo una incidencia.

Entidades funcionales que conviene separar

Sin imponer una estructura de base de datos concreta, el análisis suele necesitar distinguir conceptos como:

• persona y vínculo o asignación laboral relevante para el periodo;
• horario, turno o calendario aplicable;
• marcación o evento original;
• incidencia detectada;
• corrección o ajuste solicitado;
• aprobación o rechazo;
• periodo de procesamiento y su estado;
• bitácora de cambios y responsables.

Conservar el dato original y derivar resultados

Una marcación capturada debería poder distinguirse de la interpretación que el sistema hace sobre ella. El evento original, la incidencia calculada y una eventual corrección no son el mismo dato. Separarlos permite reconstruir qué ocurrió, qué regla se aplicó y qué decisión humana modificó el resultado.

Diseñar para la calidad del dato

Identificadores consistentes, fecha y hora, origen del evento, estado de procesamiento y referencias al horario aplicable son elementos que deben definirse desde el diseño. También conviene establecer qué ocurre ante registros incompletos, duplicados, fuera de secuencia o recibidos con retraso. Esas situaciones no deberían resolverse de forma improvisada en producción.

Las reglas de negocio son la parte más sensible del sistema porque convierten horarios y marcaciones en decisiones. Si se programan antes de acordarlas con las áreas responsables, cada excepción termina convirtiéndose en una corrección urgente o en lógica difícil de mantener.

Modelar primero los escenarios normales

Debe quedar definido qué significa una jornada esperada: hora de inicio, hora de fin, pausas, tolerancias si existen, turnos que cruzan medianoche, días no laborables y cambios de horario. El sistema necesita saber qué referencia usar antes de evaluar una marcación.

Después, modelar excepciones y precedencias

Entre las situaciones que conviene especificar están:

• marcación de entrada sin salida o viceversa;
• más de una marcación para el mismo evento;
• cambio de turno realizado después de una marcación;
• permisos o ausencias que modifican la jornada esperada;
• correcciones aprobadas que sustituyen un resultado anterior;
• eventos recibidos después del cierre.

Evitar reglas escondidas en el código

Siempre que una condición pueda cambiar por política interna, sede, grupo o periodo, conviene identificarla como regla configurable o al menos documentada, en lugar de dispersarla como constantes difíciles de rastrear. También debe existir una precedencia clara cuando dos reglas podrían aplicarse al mismo caso.

Con requisitos y reglas definidos, el siguiente paso es diseñar el flujo de procesamiento. Aquí no basta con dibujar una pantalla de marcaciones: hay que establecer qué estados atraviesa la información y qué módulo es responsable de cada transformación.

Un flujo funcional de referencia

1. Captura: recibe el evento y conserva su origen.
2. Normalización: valida formato, identidad y datos mínimos.
3. Contexto: determina el horario, turno o regla aplicable.
4. Evaluación: compara el evento con lo esperado.
5. Resultado preliminar: obtiene tiempo procesado e incidencias.
6. Resolución: incorpora correcciones o aprobaciones cuando corresponda.
7. Cierre: congela el resultado validado del periodo según las reglas definidas.

Diseñar estados y transiciones

Un registro puede estar pendiente, observado, corregido, aprobado o cerrado, según el modelo adoptado. Es importante definir qué transición puede realizar cada actor y qué condiciones impiden avanzar. Así se evita que un dato pase de “pendiente” a “cerrado” sin la validación necesaria.

El diseño debe especificar interfaces entre etapas y resultados esperados, sin confundir asistencia con productividad o desempeño. El sistema procesa evidencia de tiempo y reglas de asistencia; otros procesos pueden utilizar esa información para sus propios fines.

Las correcciones son inevitables en cualquier operación real. El problema no es que existan, sino que borren el dato anterior o queden fuera del sistema. Por eso, la trazabilidad debe diseñarse desde el inicio y no agregarse después como una auditoría parcial.

Corregir sin reemplazar silenciosamente

Una corrección debería dejar evidencia del valor anterior, el valor propuesto, el motivo, la persona que la solicitó, quién la aprobó o rechazó y cuándo ocurrió cada acción. El resultado vigente puede cambiar, pero la historia no debería desaparecer.

Definir quién puede hacer cada acción

El diseño de permisos debe acompañar el flujo funcional. Registrar una solicitud, aprobarla, modificar reglas y cerrar un periodo son responsabilidades diferentes. La separación reduce errores y permite investigar posteriormente cómo se llegó a un resultado.

Resolver reaperturas y cambios posteriores al cierre

También debe definirse qué ocurre si aparece información nueva después del cierre. El sistema puede requerir una reapertura controlada, un ajuste en un periodo posterior u otro mecanismo definido por la organización. Lo importante es que el procedimiento sea explícito y deje rastro, en lugar de modificar directamente datos cerrados.

Un sistema de asistencia rara vez vive aislado. Puede recibir personas, sedes, horarios o calendarios desde otras fuentes y entregar resultados validados a procesos posteriores. Si esas fronteras no se diseñan desde el análisis, las integraciones suelen convertirse en importaciones manuales difíciles de conciliar.

Definir contratos de entrada y salida

Para cada intercambio conviene documentar:

• qué sistema es dueño de cada dato;
• qué identificador común relaciona a las entidades;
• qué campos son obligatorios y cuáles opcionales;
• qué estados pueden enviarse o recibirse;
• qué frecuencia necesita la operación;
• cómo se registran errores y cómo se reintentan sin duplicar información;
• cómo se concilia lo enviado con lo recibido.

Integrar resultados validados, no interpretaciones incompletas

Cuando otro proceso necesita horas o incidencias, conviene definir si consumirá marcaciones originales o resultados ya procesados. En muchos escenarios, enviar datos sin validar traslada la lógica de asistencia al sistema receptor y crea dos versiones distintas de las reglas.

Elegir el mecanismo después de definir el contrato

El intercambio puede resolverse mediante archivos, servicios, colas u otros mecanismos según la arquitectura disponible. La decisión técnica debe venir después de definir propiedad del dato, frecuencia, volumen, tolerancia a fallos y necesidad de trazabilidad.

Las pruebas deben nacer junto con los requisitos. Si se dejan para el final, el equipo termina verificando pantallas en lugar de comprobar reglas y resultados. Cada condición importante necesita un caso de prueba con datos de entrada, resultado esperado y criterio de aceptación.

Casos funcionales que no deberían faltar

• jornada normal con entrada y salida válidas;
• entrada tardía o salida anticipada según la regla definida;
• marcación faltante o duplicada;
• turno que inicia un día y termina al siguiente;
• cambio de horario o turno antes y después de una marcación;
• permiso o excepción que modifica el resultado;
• corrección aprobada y corrección rechazada;
• cierre de periodo con pendientes;
• reprocesamiento controlado después de un ajuste;
• intercambio correcto y fallido con un sistema relacionado.

Probar también condiciones no funcionales

El plan debe incluir acceso por roles, recuperación ante errores, volumen representativo, tiempos de respuesta, concurrencia cuando sea relevante y registro de auditoría. Un cálculo correcto que no puede operar con la carga prevista sigue siendo un diseño incompleto.

Usar criterios de aceptación explícitos

La aceptación no debería depender de “se ve bien”. Debe comprobar que el sistema produce el resultado acordado para cada escenario y que los responsables del proceso validan esa interpretación. Esto reduce diferencias entre desarrollo, RR.HH. y operaciones al momento de salir a producción.

Implementar todo el alcance de una sola vez aumenta el costo de corregir requisitos mal entendidos. Una estrategia por etapas permite validar reglas y datos con un grupo representativo antes de extender el sistema a más personas, sedes o modalidades.

Secuencia de implementación recomendada

1. Configuración o versión inicial: cubre el flujo mínimo acordado.
2. Piloto: utiliza usuarios y escenarios suficientemente diversos para revelar excepciones reales.
3. Operación controlada: compara resultados con la referencia existente y documenta diferencias.
4. Corrección: ajusta reglas, datos, permisos e integraciones antes de ampliar alcance.
5. Despliegue progresivo: incorpora nuevas unidades solo cuando los criterios de salida del piloto están cumplidos.
6. Evolución: registra nuevas necesidades mediante un proceso de cambios y regresión.

Definir criterios para salir del piloto

El sistema está listo para escalar cuando los casos críticos son reproducibles, las incidencias tienen responsables, las integraciones concilian, los cierres pueden completarse y las reglas importantes cuentan con pruebas. También debe existir documentación suficiente para operar y dar soporte sin depender únicamente del equipo que desarrolló la primera versión.

Ejemplo conceptual: una organización puede comenzar con una sede que incluya turnos diurnos y nocturnos, probar el ciclo completo hasta el cierre y ampliar después a sedes con reglas distintas. El piloto no busca demostrar que la pantalla funciona; busca demostrar que el modelo puede representar el proceso real con resultados verificables.