Caso de uso 01: Alta de Empleado

A continuación se listan las funcionalidades técnicas críticas detectadas durante el relevamiento:

Actores:

• Empleado del Área RRHH (actor principal)

Precondiciones

• El usuario debe haber iniciado sesión en el sistema

Postcondiciones

• Se registra un nuevo empleado en el sistema.
• Se genera automáticamente su Legajo asociado.
• Se registra el estado inicial del empleado (Activo o En Revisión).
• Se guarda una entrada en el HistoricoEstado.

Escenario Principal de Éxito:

• 1. El usuario solicita registrar nuevo empleado.
• 2. El sistema solicita completar los datos obligatorios.
• 3. El usuario ingresa y confirma
• 4. El sistema valida la información.
• 5. El sistema crea el empleado y su legajo.
• 6. El sistema registra el estado inicial.
• 7. El sistema muestra confirmación de alta.
• 8. usuario finaliza alta de empleado.

Extensiones (Flujos Alternativos):

• *a. El sistema falla
• 1. El empleado reinicia el sistema.
• 2. El sistema vuelve al paso 1.
• 3a.Falta un dato obligatorio
• 1. El sistema solicita completarlo.
• 2. Continuar en paso 2.
• 4a. DNI duplicado
• 1. El sistema cancela el alta y muestra advertencia.
• Requisitos Especiales:
• 1. Validación estricta de unicidad de DNI.
• 2. Reglas de formato para email, teléfono, fecha de ingreso.
• Lista de tecnología:
• • Sistema Web:(arquitectura cliente–servidor)
• • Backend: Java + Spring Boot
• • Frontend: HTML5 / React (si aplica)
• • Base de Datos: MariaDB / SQL
• • Servidor Interno DPA (red y seguridad)
• • Control de Acceso: OAuth2 + JWT
• • Sistema de asistencia: Reloj biométrico externo (huella / tarjeta)

Caso de uso 02: Modificación de Empleado

Actores:

• Empleado del Área RRHH (actor principal)

Precondiciones

• El empleado debe existir.
• Usuario con permisos de modificación.

Postcondiciones

• Los datos se actualizan y se registran

Escenario Principal de Éxito:

• 1. El usuario solicita modificar datos del empleado.
• 2. el usuario ingresa número de legajo
• 3. el sistema valida legajo y busca legajo
• 4. el sistema muestra datos del empleado
• 5. usuario ingresa datos a modificar
• 6. el sistema valida y registra modificación
• 7. el usuario finaliza la modificación

Extensiones (Flujos Alternativos):

• *a. El sistema falla
• 1. El empleado reinicia el sistema.
• 2. El sistema vuelve al paso 1.
• 3d.Dato restringido
• 1. El sistema informa que el dato no puede modificarse.
• 4a. Validación fallida
• 1. El sistema informa el error.
• Requisitos Especiales:
• 1. Toda modificación queda auditada.

Caso de uso 03: Baja de Empleado

Actores:

• Empleado del Área RRHH (actor principal)

Precondiciones

• El empleado debe estar en estado Activo o Baja Temporal.
• Usuario con permisos para dar bajas.

Postcondiciones

• El empleado pasa a estado Baja Definitiva o Baja Temporal (según motivo).
• Se registra el cambio en el histórico.
• El legajo queda bloqueado para nuevas modificaciones salvo consulta.

Escenario Principal de Éxito:

• 1. El usuario ingresa legajo de empleado
• 2. El sistema busca legajo y muestra datos del empleado
• 3. El usuario ingresa el motivo de baja
• 4. El sistema valida y solicita confirmación.
• 5. El sistema actualiza el estado de empleado
• 6. El sistema registra el histórico.
• 7. El sistema muestra confirmación.
• 8. El usuario finaliza baja empleado

Extensiones (Flujos Alternativos):

• *a. El sistema falla
• 1. El empleado reinicia el sistema.
• 2. El sistema vuelve al paso 1.
• 3a. Motivo incompleto
• 1. El sistema solicita completarlo.
• 4b. Cancelación del usuario
• 1. El sistema vuelve a la pantalla anterior.
• Requisitos Especiales:
• 1. Política de retención documental: conservar registro por 5 años.

Caso de uso 04: Consulta

Actores:

• Empleado del Área RRHH
• Secretaría General
• Servicio Administrativo

Precondiciones

• Deben existir registros de asistencia previamente sincronizados con el sistema de reloj.
• Usuario autenticado.

Postcondiciones

• No se modifica información; solo se visualizan registros.

Escenario Principal de Éxito:

• 1. El usuario inicia nueva consulta.
• 2. El usuario ingresa filtro(area,estado de empleado, fecha, nombre apellido)
• 3. Sistema valida información
• 4. El sistema se conecta con el sistema reloj
• 5. 5. El sistema consulta y valida registros de asistencia en sistema de apoyo (reloj digital)
• 6. El sistema muestra los resultados.

Extensiones (Flujos Alternativos):

• *a. El sistema falla
• 1. El empleado reinicia el sistema.
• 2. El sistema vuelve al paso 1.
• 3a. No hay datos según filtros
• 1. El sistema muestra “Sin resultados”.
• 3b. Fallo de sincronización con el reloj
• 1. El sistema muestra alerta
• Requisitos Especiales:
• 1. Los datos de asistencia solo pueden ser consultados, nunca editados.
• 1. Debe manejar horarios nocturnos, doble turno, feriados y tolerancias.

Caso de uso 05: Carga de Documento

Actores:

• Empleado del Área RRHH
• Servicio Administrativo

Precondiciones

• El empleado debe existir.
• El archivo debe ser válido en extensión y tamaño.
• El usuario debe estar autenticado y tener permisos de carga.

Postcondiciones

• Se almacena el archivo en el sistema.
• Se registra un nuevo documento asociado.
• Si corresponde, se notifica a Asesoría Legal.
• • Se conserva el versionado documental (si el tipo de documento ya existía).

Escenario Principal de Éxito:

• 1. El usuario solicita incorporar documento.
• 2. El sistema valida información
• 3. El usuario selecciona tipo de documento.
• 4. El usuario ingresa archivo.
• 5. El sistema valida tamaño y formato
• 6. El sistema guarda el archivo.
• 7. El sistema muestra confirmación.

Extensiones (Flujos Alternativos):

• *a. El sistema falla
• 1. El empleado reinicia el sistema.
• 2. El sistema vuelve al paso 1.
• 2a. Tipo no permitido
• 1. El sistema solicita elegir un tipo válido.
• 3a. Archivo corrupto o excedido
• 1. El sistema informa el error.
• Notas:
• 1. Debe conservarse el historial de versiones de un documento si ya existía uno del mismo tipo.
• 2. El nombre del archivo no debe contener caracteres inválidos.
• 3. • Se debe registrar el usuario que realizó la carga.

Caso de uso 06: Cambio de Estado

Actores:

• Empleado del Área RRHH
• • Asesoría Legal

Precondiciones

• El empleado debe existir.
• El usuario debe estar autorizado

Postcondiciones

• El estado del empleado se actualiza.
• El estado del empleado se actualiza.

Escenario Principal de Éxito:

• 1. El usuario solicita cambio de estado.
• 2. El sistema muestra estado actual y posibles estados.
• 3. El usuario cambiaEstado(nuevoEstado, motivo).
• 4. El sistema valida.
• 5. El sistema registra el cambio.
• 6. El sistema muestra confirmación.

Extensiones (Flujos Alternativos):

• *a. El sistema falla
• 1. El empleado reinicia el sistema.
• 2. El sistema vuelve al paso 1.
• 3a. Estado incompatible
• 1. El sistema informa que no puede aplicarse.
• 2. Continúa en paso 2.
• 3b. Motivo incompleto
• 1. El sistema solicita completarlo.
• 2. Continúa en paso 3.
• Notas:
• 1. El reloj NO interviene en este flujo.
• Transiciones automáticas NO forman parte de este caso (solo manual).

Contrato 01 — altaEmpleado(datosEmpleado)

Operación:

• ingresarEmpleado(datosEmpleado)

Referencias:

• Caso de Uso: Alta de Empleado

Precondiciones:

• El usuario debe estar autenticado.
• No debe existir un empleado con el mismo DNI.

Postcondiciones:

• Se creó una nueva instancia de Empleado (creación de instancia).
• Se creó una nueva instancia de Legajo asociada al empleado (creación + asociación).
• Se creó un registro de HistóricoEstado para registrar el estado inicial (creación).
• El estado del empleado quedó establecido como Activo o En Revisión (modificación de atributo).
• El Legajo quedó asociado al nuevo empleado (asociación).

Contrato 02 — modificarEmpleado(idEmpleado, datosModificados)

Operación:

• modificarEmpleado(idEmpleado, datosModificados)

Referencias:

• Caso de Uso: Modificación de Empleado

Precondiciones:

• El empleado existe.
• El usuario tiene permisos de modificación.

Postcondiciones:

• Se actualizaron los datos del empleado según lo permitido (modificación de atributos).
• Se creó un registro de modificación en HistóricoEstado (creación).
• El empleado quedó asociado a su nuevo registro histórico (asociación)

Contrato 03 — bajaEmpleado(idEmpleado, motivo)

Operación:

• bajaEmpleado(idEmpleado, motivo)

Referencias:

• Caso de Uso: Baja de Empleado

Precondiciones:

• El empleado debe estar en estado Activo o Baja Temporal.

Postcondiciones:

• El estado del empleado fue actualizado a Baja Definitiva o Baja Temporal (modificación de atributo).
• Se creó un registro en HistóricoEstado con el motivo de baja (creación).
• Se asoció el registro histórico con el empleado (asociación).
• El legajo quedó bloqueado para edición (modificación de atributo del legajo).

Contrato 04 — consultarAsistencia(filtros)

Operación:

• consultarAsistencia(filtros)

Referencias:

• Caso de Uso: Consulta

Precondiciones:

• Deben existir registros provenientes del reloj biométrico.

Postcondiciones:

• (No hay creación ni modificación porque es una consulta)
• Se recuperaron los registros de asistencia que coincidieron con los filtros (consulta / recuperación de información).

Contrato 05 — cargarDocumento(idEmpleado, tipoDocumento, archivo)

Operación:

• cargarDocumento(legajo: Entero, tipo: TipoDocumento, archivo: Archivo)

Referencias cruzadas:

• Caso de Uso: Carga de Documentación

Precondiciones:

• El empleado existe.
• El archivo tiene formato y tamaño válidos.

Postcondiciones:

• Se creó una nueva instancia de Documento (creación).
• Se asoció el documento al empleado (asociación).
• Se registró el usuario que realizó la carga (modificación de atributo / metadato).
• Se registró una nueva versión del documento si existía uno previo del mismo tipo (creación + asociación).
• Se notificó a Asesoría Legal si correspondía (evento del sistema / regla de negocio).

Contrato 06 — cambiarEstado(idEmpleado, nuevoEstado, motivo)

Operación:

• cambiarEstado(idEmpleado, nuevoEstado, motivo)

Referencias:

• Caso de Uso: Cambio de Estado

Precondiciones:

• El empleado existe.
• La transición de estado es válida.

Postcondiciones:

• El estado del empleado fue actualizado (modificación de atributo).
• Se creó un registro en HistóricoEstado con motivo y fecha (creación).
• El registro histórico se asoció al empleado (asociación).