Modernización offline de un flujo legacy de registro y reporting.
Estado
Aplicación funcional · 2026
Rol
Análisis · diseño de sistema · dirección técnica
Stack
C# · .NET 8 · WPF · SQLite
Aplicación desktop para Windows, desarrollada durante una práctica profesional en 2026, que moderniza un flujo legacy de registro y reporting operativo. Funciona offline con persistencia local y cubre registro, consulta, gestión de estados y reporting. Tuve ownership técnico sobre el análisis, el diseño, las reglas y la validación. Una parte sustancial de la implementación se generó con agentes de código, bajo mi especificación y revisión.
01 /Proceso legacy
El proceso operativo dependía de una combinación de software legacy, planillas y pasos manuales. La información quedaba repartida entre herramientas y preparar reportes requería trabajo manual.
El objetivo era simplificar ese flujo sin introducir una dependencia de Internet ni infraestructura central innecesaria.
02 /Discovery
El trabajo empezó con el levantamiento y análisis del proceso existente: qué se registraba, cómo se consultaba, qué estados atravesaba un registro y cómo se preparaban los reportes.
De ese análisis salieron la definición funcional y el alcance de la aplicación: registro, consulta, gestión de estados y reporting.
03 /Restricciones
Conectividad limitada: la aplicación debía funcionar offline.
Entorno Windows: la solución debía ejecutarse como aplicación local.
Sin infraestructura central innecesaria: los datos se mantienen en persistencia local.
Reporting: la generación de reportes era una parte importante del flujo.
04 /Mi rol
Tuve ownership técnico del proyecto, pero no fui el autor manual exclusivo del código. Mi responsabilidad cubrió:
Levantamiento y análisis del proceso.
Definición funcional y alcance.
Arquitectura y reglas de negocio.
UX de la aplicación.
Revisión técnica, integración y aceptación de cambios.
Es una aplicación desktop organizada en capas: presentación con MVVM, servicios con las reglas de la aplicación, repositorios para la persistencia local y un componente de reporting. Toda la lógica de la aplicación se ejecuta en el equipo local.
El proyecto pasó por una primera aproximación en Python antes de migrar a .NET/WPF, para consolidar una base desktop más adecuada al entorno objetivo.
Aplicación desktop · Windows
InterfazWPF · XAML
↓
ViewModelsMVVM · CommunityToolkit.Mvvm
↓
Serviciosreglas de la aplicación
↓
RepositoriosSQL parametrizado · SQLite local
ReportingExcel · ClosedXML
Diagrama abstracto. La interfaz WPF se enlaza con ViewModels (MVVM). Los ViewModels delegan en servicios con las reglas de la aplicación, que usan repositorios sobre una base SQLite local y un componente que genera reportes en Excel.
Todo se ejecuta en el equipo local y no requiere conexión. El diagrama no representa tablas, archivos ni configuraciones reales.
06 /Decisiones de ingeniería
Decisión Desktop frente a dependencia web
Problema
La solución debía operar sin depender de conectividad continua.
Decisión
Aplicación desktop para Windows con datos locales.
Trade-off
Mayor autonomía operacional, a cambio de depender del entorno Windows y de una gestión local.
Decisión SQLite frente a infraestructura central
Problema
Una infraestructura central agregaba dependencias y complejidad no justificadas para el alcance.
Decisión
Persistencia local con SQLite.
Trade-off
Simplicidad y operación offline, pero sin sincronización central automática.
Decisión SQL explícito frente a un ORM pesado
Problema
Mantener controladas las dependencias y las abstracciones.
Decisión
Repositorios con SQL parametrizado sobre Microsoft.Data.Sqlite.
Trade-off
Más control y menos abstracción, a cambio de escribir más SQL a mano.
Decisión Agentes de código con revisión humana
Problema
Materializar la solución con rapidez sin perder control técnico.
Decisión
Usar agentes de código para implementar bajo especificación, con revisión y aceptación humana.
Trade-off
Más velocidad de ejecución, pero más necesidad de revisión disciplinada y validación.
07 /Implementación asistida por IA
Codex y Claude Code generaron una parte sustancial de la implementación. El uso de agentes fue una forma de construir la aplicación, no una característica del producto.
Responsabilidad humana (mía)
Alcance, arquitectura y reglas de negocio.
Especificación y prompts para los agentes.
Revisión del código generado.
Ejecución de builds y tests.
Aceptación de cambios e integración.
Los agentes no reemplazaron la validación técnica: ningún cambio se daba por aceptado solo porque un agente lo hubiera generado.
08 /Reporting
La generación de reportes era una parte importante del flujo y antes requería trabajo manual. La aplicación automatiza la creación de archivos Excel con ClosedXML.
Este case no muestra plantillas, columnas ni datos reales.
09 /Resultado y estado
El resultado es una aplicación funcional para Windows, desarrollada durante una práctica profesional en 2026, que opera offline con persistencia local.
La aplicación cubre
Registro
Consulta
Gestión de estados
Reporting en Excel
Este case describe la aplicación desarrollada. No incluye métricas de uso ni de impacto.