👤
Clientes
La información y los saldos podían requerir reconstrucción manual.
Espiga es un sistema web de gestión desarrollado para centralizar clientes, pedidos, pagos, proveedores, archivos técnicos y entregas de PCR Amoblamientos.
Panel de gestión
Una herramienta pensada para que la información del negocio esté organizada, actualizada y disponible desde un mismo lugar.
El sistema busca centralizar la gestión cotidiana de un taller de muebles a medida: clientes con cuenta corriente, proveedores, pedidos, archivos técnicos, cobranzas y entregas.
La gestión de PCR Amoblamientos se realizaba de forma manual y dispersa, dificultando la consulta, el seguimiento y la trazabilidad de la información.
La información y los saldos podían requerir reconstrucción manual.
Era necesario seguir cada pedido y conocer su estado.
La organización de pagos y pendientes necesitaba mayor centralización.
Había que controlar fechas y anticipar entregas próximas.
Espiga reúne en una misma plataforma las principales tareas de gestión del taller.
Alta, consulta y gestión de clientes y sus cuentas corrientes.
Creación y seguimiento de pedidos según su estado.
Registro de pagos, comprobantes y consulta de saldos.
Control de proveedores y seguimiento de deudas.
Planos, fotografías y listas de corte asociados a cada pedido.
Calendario y avisos para entregas próximas, además de recordatorios de cobranza.
Link público por pedido: el cliente ve el estado, la entrega y las fotos, sin usuario ni clave.
Tablero por etapas: se arrastra cada pedido y su estado se actualiza al instante.
Inventario con aviso de bajo stock; el consumo por pedido lo descuenta solo.
Presupuesto por ítems y PDF con código QR; comprobantes y facturas descargables.
Panel con gráficos, flujo de caja y exportación de listados a Excel.
Cada perfil accede a las herramientas necesarias para realizar sus tareas dentro del sistema.
Un recorrido simple para entender cómo se organiza la información dentro de Espiga.
Se registra o consulta al cliente.
Se crea el pedido y se agregan archivos técnicos.
Se actualiza el estado del pedido y materiales.
Se registran pagos y se actualiza el saldo.
Se controla la fecha mediante calendario y alertas.
La solución combina una interfaz web, un backend para la lógica del sistema y una base de datos para organizar la información.
Interfaz web para acceder y trabajar con el sistema.
Procesa las operaciones y reglas del sistema.
Base de datos relacional normalizada para almacenar la información.
Sistema publicado en la nube y accesible desde distintos dispositivos.
Accesos para presentar el sistema, consultar su documentación y conocer su desarrollo.
Acceder a Espiga publicado en Railway.
Código y archivos del proyecto.
Requisitos, modelo, diagnóstico, bitácora, Gantt, contrato y más.
Instrucciones para utilizar las funciones principales de Espiga.
Primeros pasos para comenzar a utilizar Espiga.
Respuestas sobre uso, datos, comprobantes y backups.
Volver a la presentación principal de Espiga.
Una solución de gestión desarrollada para las necesidades de PCR Amoblamientos.
Ingresar al sistema ↗Carpeta del Proyecto · Documentación
Documentación técnica, operativa y económica del proyecto. Sistema web para gestionar clientes con cuenta corriente automática, proveedores, pedidos, archivos técnicos, cobranzas y entregas de un taller de muebles a medida, publicado en la nube y accesible desde cualquier dispositivo.
Registro de las modificaciones sobre la documentación y el alcance del proyecto, con fecha, responsable y detalle. Cada validación con Rodrigo que derive en un cambio de requerimiento se anota como una fila nueva.
| Versión | Fecha | Responsable | Detalle del cambio |
|---|---|---|---|
| 0.1 | Pendiente | Equipo | Versión inicial a partir del documento de análisis (mockup, roles, diagrama entidad-relación y diagrama de actividades). |
| 0.2 | Pendiente | Equipo | Arquitectura de 3 perfiles (administrador, administrativo, operario) y cobertura completa de RF01 a RF11. |
| 0.3 | Pendiente | Equipo | Se quitaron los usuarios y claves de ejemplo de la pantalla de login, por ser un hueco de seguridad detectado durante el desarrollo. |
| 0.4 | Pendiente | Equipo | Alta de recuperación de contraseña por email (RF09). Queda pausada hasta obtener el email real del administrador. |
| 0.5 | Pendiente | Equipo | Publicación del sistema en Railway y alta de subida real de archivos (RF07) con almacenamiento persistente. |
| 0.6 | Pendiente | Equipo | Cambio de dominio público a espiga-pcr.up.railway.app por uno más prolijo para presentar al cliente. |
| 0.7 | Pendiente | Equipo | Alta de RF12 a RF17: comprobantes al cliente, resumen de cuenta en PDF, consumo de materiales, buscador y filtros, app instalable (PWA) y notificaciones push de alertas. |
| 0.8 | Pendiente | Equipo | Alta de RF18 a RF22: backup automático, presupuesto en PDF, estadísticas, calendario de entregas y recordatorios de cobranza. Modelo de datos normalizado a 3FN. |
| 0.9 | Pendiente | Equipo | Rediseño estético de toda la interfaz manteniendo la identidad madera del taller. |
Diagnóstico elaborado por el equipo a partir del relevamiento en PCR Amoblamientos. Es la pieza que fundamenta todas las decisiones de diseño: el problema central y sus causas explican por qué el sistema gestiona lo que gestiona, y los medios del árbol de soluciones son el origen directo de los requerimientos funcionales.
El árbol de problemas se lee de abajo hacia arriba: las causas producen el problema central, y el problema central produce los efectos. El árbol de soluciones es su espejo: cada causa se convierte en un medio y cada efecto en un fin medible.
Condiciones que producen el problema central. Cada una se relevó con Rodrigo y se traduce después en un requerimiento concreto.
| Causa | Qué se observó en el relevamiento |
|---|---|
| El saldo de cada cliente se calcula a mano | Cobros y entregas parciales se anotan en distintos lugares; el saldo real depende de sumar a mano varios papeles, y se presta a errores. |
| No hay un registro único de pedidos | Los pedidos viven en la cabeza de Rodrigo y en anotaciones sueltas; no hay una lista con el estado de cada uno. |
| Las deudas con proveedores no están consolidadas | Las facturas de madereras y herrajerías se acumulan sin un total claro de cuánto se debe a cada proveedor. |
| No hay aviso de vencimiento de entregas | Un pedido puede pasarse de la fecha comprometida sin que nadie lo note a tiempo. |
| Los planos y listas de corte se traspapelan | Los archivos técnicos de cada trabajo (planos, listas de corte) están en distintas compus, mails y papeles; cuesta encontrarlos. |
| No hay registro histórico ni trazabilidad | No se puede reconstruir quién cargó un pago, ni comparar un mes con otro, ni saber qué cliente cobra más peso en el negocio. |
Consecuencias que el problema produce hoy en el taller. Sus valores actuales forman la línea de base contra la que se mide el proyecto.
| Efecto | Cómo se manifiesta hoy (línea de base) |
|---|---|
| Saldos poco confiables | El saldo de un cliente puede tardar minutos en reconstruirse y no siempre coincide con la realidad. |
| Cobranzas que se pierden | Clientes con saldo pendiente que no se reclaman a tiempo porque nadie tiene la lista a mano. |
| Entregas que se atrasan sin aviso previo | El taller se entera de un atraso cuando el cliente pregunta, no antes. |
| Tiempo perdido buscando información | Encontrar un plano, un pago o el estado de un pedido implica revisar papeles y varias compus. |
| Decisiones sin datos | No se sabe qué cliente pesa más, cuánto se cobró el mes pasado, ni a qué proveedor se le compra más. |
Cada medio neutraliza una causa identificada más arriba y se convierte después en uno o varios requerimientos.
| Medio | Causa que neutraliza |
|---|---|
| Cuenta corriente con saldo automático. El saldo se deriva de los pagos, nunca se guarda a mano. | El saldo de cada cliente se calcula a mano. |
| Registro único de pedidos con estado. Todos los pedidos en una lista, con su estado de producción y entrega. | No hay un registro único de pedidos. |
| Gestión de proveedores con deuda consolidada. Cada factura recibida suma a un total claro por proveedor. | Las deudas con proveedores no están consolidadas. |
| Alertas de entrega + notificación al celular. Aviso automático cuando una fecha se acerca. | No hay aviso de vencimiento de entregas. |
| Archivos por pedido con almacenamiento persistente. Planos y listas de corte guardados junto al pedido. | Los planos y listas de corte se traspapelan. |
| Base de datos histórica + estadísticas + backup. Cada movimiento queda registrado y respaldado. | No hay registro histórico ni trazabilidad. |
Los fines son el espejo de los efectos: expresan a qué valor debería llegar cada uno con el sistema funcionando.
| Fin | Meta verificable | Punto de partida |
|---|---|---|
| Saldo confiable e instantáneo | El saldo de cualquier cliente se ve al instante y siempre coincide con los pagos cargados. | Minutos, sumando papeles |
| No perder cobranzas | Lista de clientes con saldo siempre disponible, con recordatorio listo para enviar. | Se pierden por olvido |
| Detectar atrasos a tiempo | Aviso automático 7 días antes de la fecha de entrega, en el sistema y en el celular. | Cuando el cliente pregunta |
| Información en un solo lugar | Cliente, pedido, pago o plano encontrados en segundos desde cualquier dispositivo. | Papeles y varias compus |
Este diagnóstico alimenta la línea de base y los OKRs: los efectos aportan los valores de partida y los fines aportan los Key Results contra los que se evalúa el proyecto. Lo que el árbol identifica pero el sistema no resuelve en esta entrega queda declarado en las Limitaciones del alcance (5.1), y las mejoras diferidas, en la Evolución previsible (4.6).
Dotar a PCR Amoblamientos de una forma centralizada y confiable de gestionar su operación diaria: clientes con cuenta corriente, pedidos, pagos, proveedores, archivos técnicos y entregas. Hoy toda esa gestión es manual y dispersa, lo que genera saldos poco confiables, cobranzas que se pierden y entregas que se atrasan sin aviso.
Espiga busca resolver tres problemas medibles: la falta de un saldo confiable e inmediato por cliente, la pérdida de cobranzas por no tener la información a mano, y la detección tardía de atrasos en las entregas.
El sistema incluye: inicio de sesión con 3 perfiles, panel de saldos, gestión de clientes con cuenta corriente automática, gestión de proveedores con deudas, gestión de pedidos con estados y archivos técnicos, registro de consumo de materiales, emisión de comprobantes (Factura A / B / Recibo), resumen de cuenta y presupuesto en PDF, alertas de entrega (en el sistema y por notificación al celular), calendario de entregas, estadísticas del negocio, recordatorios de cobranza, buscador y filtros, gestión de usuarios, backup automático y la posibilidad de instalar el sistema como app en el celular. Todo publicado en la nube.
El sistema no incluye: factura electrónica ni integración con AFIP (sí emite comprobantes simples), control de stock de materiales más allá del consumo por pedido, envío 100% automático de recordatorios sin intervención, ni una app nativa de tienda (se instala como PWA). El detalle está en las Limitaciones (5.1) y se formaliza en el Contrato (sección 9).
Roles del equipo de proyecto, según los Lineamientos 2026 (PM, desarrollo Frontend/Backend, UX/UI, base de datos). Al ser un proyecto 100% software, no incluye el rol de técnico instalador propio de los proyectos con hardware.
| Rol | Responsabilidad principal | Integrante |
|---|---|---|
| Project Manager (PM) | Planificación temporal (GANTT), control de alcance y relación con el cliente. | A completar |
| Backend / BD | Servidor Node.js + Express, base de datos MySQL, API REST, despliegue. | A completar |
| Frontend / UX-UI | Interfaz web, mockup y validación de la interfaz con el usuario. | A completar |
| Documentación / QA | Documentación técnica y de usuario, pruebas y control de calidad. | A completar |
| Cliente | Valida requerimientos, prioriza y firma el contrato. | Rodrigo Pasut (PCR Amoblamientos) |
| Término | Definición |
|---|---|
| ABM | Alta, Baja y Modificación: operaciones básicas de gestión de un registro (cliente, proveedor, usuario). |
| Cuenta corriente | Registro de los movimientos (presupuesto y pagos) de un cliente, del que se deriva el saldo. |
| Saldo | Diferencia entre lo presupuestado y lo pagado, calculada por el sistema (nunca guardada a mano). |
| API REST | Interfaz HTTP que expone los datos del backend al frontend, en formato JSON. |
| Backend | Servidor (Node.js + Express) que procesa la lógica y se conecta a la base de datos. |
| Frontend | Interfaz web que consume la API REST y que usan Rodrigo, Ana y Facu. |
| Vista (SQL) | Consulta guardada que calcula datos derivados (como el saldo) en el momento, sin almacenarlos. |
| Trigger | Regla automática en la base de datos; en Espiga, cierra el pedido cuando está entregado y saldado. |
| JWT | Token de sesión que identifica al usuario logueado en cada pedido a la API. |
| PWA | Progressive Web App: web instalable en el celular sin pasar por una tienda de aplicaciones. |
| Push (VAPID) | Notificación que llega al celular aunque la app esté cerrada. VAPID son las claves que la autorizan. |
| RF / RNF | Requerimiento Funcional / Requerimiento No Funcional. |
| ISW | Interfaz de Software: componente de software del sistema y su tecnología. |
| 3FN | Tercera Forma Normal: nivel de normalización que evita que un dato quede repetido y se contradiga. |
| OKR / KR | Objective and Key Results / Resultado Clave (métrica de progreso). |
| Línea de base | Medición de la situación inicial (antes del sistema) usada como referencia de comparación. |
Formato APA 7ª edición.
Espiga es un sistema de gestión web para PCR Amoblamientos, un taller de muebles a medida ubicado en Villa Bosch. Centraliza clientes con cuenta corriente automática, proveedores con seguimiento de deudas, pedidos con alertas de entrega y archivos técnicos (planos, fotos, listas de corte) por pedido, con tres perfiles de acceso: administrador (Rodrigo), administrativo (Ana) y operario (Facu). Está construido con backend Node.js + Express y base de datos MySQL, y publicado en Railway para usarse desde cualquier dispositivo sin depender de una computadora del taller.
Público objetivo: talleres y pequeños fabricantes a medida que llevan clientes, proveedores y pedidos de forma manual. Resultados esperados: pasar de un saldo que se reconstruye a mano y a veces no coincide, a un saldo confiable e instantáneo; no volver a perder cobranzas por olvido; y detectar los atrasos de entrega 7 días antes en lugar de cuando el cliente pregunta.
Espiga es un sistema nuevo: hoy el taller no tiene ningún sistema de gestión, todo es manual (papel, cuadernos, memoria). No reemplaza ni mejora un software existente. Se apoya en infraestructura que el taller ya tiene (una PC y celulares con conexión a internet) y se publica en la nube para no depender de ningún equipo encendido en el local.
Arquitectura en tres capas (persistencia, lógica de negocio y presentación):
A nivel general (sin entrar todavía en los requisitos del 5.1), el producto permite:
Siguiendo el formato de la tabla de usuarios del libro UTN (tipo de usuario, formación y actividades). El sistema define tres perfiles de acceso, alineados con la matriz de permisos implementada en el backend.
Dueño del taller, 40+ años, comodidad tecnológica media. Acceso total: ve todos los módulos, crea pedidos, gestiona usuarios, revisa backups y estadísticas, y podrá recuperar su clave por email una vez configurada esa función. Uso diario.
Lleva clientes, proveedores, cobranzas y facturación. Acceso a cuentas corrientes, pagos, comprobantes, alertas, calendario, estadísticas y recordatorios; no crea pedidos ni gestiona usuarios. Uso diario.
Trabaja del lado de producción: consulta y actualiza el estado de los pedidos, carga materiales y sube archivos (planos, listas de corte). No accede a saldos, cobranzas ni gestión de usuarios. Uso ocasional durante la jornada.
Se desarrolla con software libre (Node.js, Express, MySQL). No hay costo de licencia. El único costo externo posible es el alojamiento en la nube (4.4.2). El repositorio se aloja en GitHub (felooaraujo-ai/Kore); si es privado, se incluye al equipo docente como colaborador.
El backend necesita estar disponible de forma continua para acceder desde el taller o desde afuera. Se resolvió con Railway, con un volumen persistente (kore-volume, montado en /app/uploads) para que los archivos subidos y los backups no se pierdan entre despliegues.
El sistema no se integra, en esta entrega, con AFIP, software contable ni pasarelas de pago. Es autónomo. Para las notificaciones push usa el estándar Web Push (con claves VAPID propias, sin depender de un servicio pago).
Autenticación con usuario y contraseña, y control de acceso por rol (administrador / administrativo / operario). La pantalla de login no muestra usuarios ni claves de ejemplo. Cada pago y cada comprobante queda registrado con el usuario que lo cargó (trazabilidad).
Toda la interfaz está en español, con los términos que usa el taller (cliente, proveedor, pedido, saldo) en lugar de jerga de sistemas.
Comunicación frontend → backend por HTTP/REST (JSON) con token JWT. Backend → base de datos por SQL sobre MySQL. Notificaciones por Web Push. Recuperación de clave por SMTP (email).
El sistema debe estar disponible durante el horario del taller y no perder archivos entre reinicios, gracias al volumen persistente. Un backup automático diario protege los datos, con retención de los últimos 7 respaldos.
Contraseñas almacenadas con hash (bcrypt), nunca en texto plano; sesiones con token JWT; acceso restringido por rol; sin datos de ejemplo en el login. La base de datos no tiene acceso público (solo el backend le habla por la red interna). La recuperación de clave por email está desarrollada, pausada hasta contar con el email real del administrador.
Mejoras identificadas para versiones futuras (surgen de las Limitaciones del 5.1):
Acciones concretas que el sistema debe poder realizar. Cada requerimiento indica su prioridad y su origen (el síntoma o la necesidad del que surge).
| ID | Requerimiento | Prioridad | Origen |
|---|---|---|---|
| RF01 | Inicio de sesión con 3 roles. Login sin usuarios ni claves de ejemplo visibles, con acceso diferenciado por rol. | Alta | Cada rol ve solo lo suyo |
| RF02 | Panel de saldos. Vista única con el estado de las cuentas corrientes de clientes y proveedores. | Alta | "No sé cuánto me deben en total" |
| RF03 | ABM de clientes con cuenta corriente automática. El saldo se recalcula solo con cada pago. | Alta | El saldo se calcula a mano |
| RF04 | ABM de proveedores con gestión de deudas. Seguimiento de lo que el taller debe a cada uno. | Alta | Deudas no consolidadas |
| RF05 | Gestión de pedidos. Alta y seguimiento de pedidos, con su estado de producción y entrega. | Alta | No hay registro único de pedidos |
| RF06 | Alertas de entrega. Aviso cuando la fecha comprometida de un pedido se acerca o se vence. | Alta | Atrasos sin aviso previo |
| RF07 | Carga y almacenamiento de archivos por pedido. Planos, fotos y listas de corte guardados de forma persistente. | Alta | Los planos se traspapelan |
| RF08 | Gestión de usuarios. Alta, edición y asignación de rol para cada persona del taller. | Media | Control de acceso por rol |
| RF09 | Recuperación de contraseña por email. Envío de un link para poner una clave nueva. Activa mediante la API de Brevo (envío por HTTPS). | Media | "¿Y si me olvido la clave?" |
| RF10 | Sección de ayuda «¿Cómo funciona?». Guía dentro del propio sistema para los tres roles. | Baja | Onboarding sin capacitación |
| RF11 | Publicación online del sistema. Acceso desde cualquier dispositivo, sin depender de una compu del taller. | Alta | No depender de un equipo local |
| RF12 | Emisión de comprobantes al cliente. Factura A, Factura B o Recibo por un pedido, con número, fecha y monto. | Media | Comprobante al cobrar |
| RF13 | Resumen de cuenta en PDF. Detalle de pedidos, pagos y saldo de un cliente, exportable. | Media | Rendir cuenta al cliente |
| RF14 | Registro de consumo de materiales. Materiales usados por pedido (descripción y cantidad). | Media | Saber qué se usó en cada trabajo |
| RF15 | Buscador y filtros. Búsqueda por texto y filtro por período (Hoy / Esta semana / Todos) en Clientes y Pedidos. | Media | Encontrar rápido |
| RF16 | App instalable en el celular. Se agrega a la pantalla de inicio (Android/iPhone) y abre a pantalla completa. | Media | Acceso rápido en la calle |
| RF17 | Notificaciones push de alertas. Aviso automático al celular cuando un pedido está a 7 días o menos de su entrega. | Media | Enterarse sin entrar al sistema |
| RF18 | Backup automático de datos. Copia diaria de todos los datos, descarga manual y retención de los últimos 7. | Media | No perder datos |
| RF19 | Presupuesto en PDF para el cliente. Presupuesto formal por pedido (validez, seña sugerida, condiciones) para enviar antes de confirmar. | Media | Cerrar trabajos nuevos |
| RF20 | Estadísticas del negocio. Mejores clientes, cobrado por mes y proveedores con más compras, en vivo. | Baja | Decidir con datos |
| RF21 | Vista calendario de entregas. Pedidos por fecha en un calendario mensual, con color por urgencia y filtros. | Media | Planificar la producción |
| RF22 | Recordatorios a clientes con saldo. Lista de deudores con un mensaje listo para copiar o abrir en WhatsApp. | Media | No perder cobranzas |
| RF23 | Seguimiento del pedido para el cliente. Link público sin login (código único) con estado, entrega estimada y pago. | Media | "¿Cómo va lo mío?" |
| RF24 | Presupuesto por ítems. Renglones con cantidad y precio; el total se calcula solo. | Media | Presupuestar con detalle |
| RF25 | Código QR en el presupuesto. El PDF incluye un QR al seguimiento del cliente. | Baja | Enlace rápido |
| RF26 | Exportación a Excel. Clientes, pedidos y pagos en .xlsx. | Media | Llevar a la planilla |
| RF27 | Historial de estados del pedido. Línea de tiempo con fecha y responsable. | Baja | Trazabilidad |
| RF28 | Aviso push al cliente. Notificación cuando el pedido cambia de estado. | Baja | Cliente informado |
| RF29 | Stock de insumos. Inventario con alerta de bajo stock; el consumo descuenta. | Media | Saber qué reponer |
| RF30 | Tablero Kanban de producción. Se arrastran los pedidos entre etapas. | Media | Ver el flujo |
| RF31 | Galería de fotos del mueble. Visibles también en el seguimiento. | Baja | Mostrar el avance |
| RF32 | Dashboard con gráficos. Cobrado por mes, pedidos por estado y mejores clientes. | Baja | Decidir con datos |
| RF33 | Flujo de caja, backup por mail y modo oscuro. Entradas vs. salidas, copia por email y tema oscuro. | Baja | Control y comodidad |
| ID | Requerimiento | Categoría |
|---|---|---|
| RNF01 | Contraseñas almacenadas con hash (bcrypt), nunca en texto plano. | Seguridad |
| RNF02 | La pantalla de login no muestra usuarios ni claves de ejemplo. | Seguridad |
| RNF03 | Accesible desde PC y celular por navegador, sin instalar nada; opcionalmente instalable como app (RF16). | Usabilidad |
| RNF04 | Interfaz completa en español, con el vocabulario que ya usa el taller. | Usabilidad |
| RNF05 | Los archivos subidos y los backups se conservan entre reinicios del servicio (volumen persistente). | Fiabilidad |
| RNF06 | Comunicación frontend-backend por API REST sobre HTTP, autenticada con JWT. | Protocolos |
| RNF07 | Los saldos nunca se almacenan: se calculan en el momento con vistas SQL, para que no puedan desincronizarse. | Integridad de datos |
Definen qué no hace el sistema en esta entrega. No son debilidades: son un contrato de honestidad con el usuario. Cada limitación puede convertirse en una versión futura (4.6).
| ID | Qué NO hace en esta entrega | Por qué | ¿Versión futura? |
|---|---|---|---|
| LIM01 | No emite factura electrónica ni se integra con AFIP (sí emite comprobantes simples, RF12). | La factura electrónica requiere homologación con AFIP, fuera del alcance académico. | Sí. v3. |
| LIM02 | Se sumó como módulo propio en la Fase 5. | Hecho (v2). | |
| LIM03 | No hay app móvil nativa de tienda; se instala como PWA desde el navegador (RF16). | Una app nativa duplica el desarrollo y requiere cuentas de tienda pagas. | A evaluar. |
| LIM04 | Railway bloquea el SMTP saliente; se resolvió con la API HTTP de Brevo. | Hecho (v2). | |
| LIM05 | Los recordatorios de cobranza se envían de forma asistida (mensaje listo para WhatsApp); el backup y la recuperación de clave sí salen por email automático. | El envío automático a WhatsApp requiere una API de terceros paga. | Sí. v3. |
El único punto de contacto de Rodrigo, Ana y Facu con el sistema es el frontend web, diseñado con criterio de usabilidad para un usuario de comodidad tecnológica media. En escritorio tiene una barra lateral de navegación (Panel de saldos, Clientes, Proveedores, Pedidos, Calendario, Alertas, Estadísticas, Recordatorios, Usuarios, Backups, ¿Cómo funciona?) y en celular una barra inferior simplificada (Inicio, Clientes, Prov., Pedidos, Alertas). Clientes y Pedidos tienen buscador y filtro por período. El login pide usuario y clave, sin datos de ejemplo, e incluye «¿Olvidaste tu clave?». El sistema se puede instalar como app (RF16) y activar notificaciones push (RF17). La estética sigue una identidad "madera" coherente con un taller de muebles.
Antes de conectar la lógica, el equipo trabajó sobre un mockup navegable y lo fue validando; el feedback se registra como hito en el control de cambios y en el Registro de Cambios de Interfaz (10.3).
espiga-pcr.up.railway.app).Componentes de software del sistema y cómo se comunican. No es lo mismo que los RNF (rendimiento y protocolos) ni que los RF (funcionalidades).
| ID | Componente | Tecnología / Stack | Rol en el sistema |
|---|---|---|---|
| ISW01 | Frontend | HTML, CSS y JavaScript, conectado a la API real. | Interfaz que usan Rodrigo, Ana y Facu según su rol. |
| ISW02 | Backend / API REST | Node.js + Express. Auth: JWT. | Lógica de negocio: cuenta corriente, alertas, permisos por rol. |
| ISW03 | Base de datos | MySQL, con vistas y triggers. | Persistencia central. Los saldos se derivan con vistas. Modelo en 5.6. |
| ISW04 | Almacenamiento de archivos | Volumen persistente de Railway (kore-volume, /app/uploads). | Guarda planos, fotos, listas de corte y los backups. |
| ISW05 | Hosting / despliegue | Railway, con despliegue automático desde GitHub. | Publica backend y frontend en espiga-pcr.up.railway.app. |
| ISW06 | Recuperación de contraseña | Email (Nodemailer/SMTP), desarrollado y pausado. | Implementa RF09, a la espera del email real del administrador. |
| ISW07 | Notificaciones push | Web Push API + claves VAPID + Service Worker. | Implementa RF17: avisa al celular sin depender de un tercero pago. |
| ISW08 | Generador de PDF | PDFKit (Node.js), del lado del servidor. | Implementa RF13 y RF19: resumen de cuenta y presupuesto. |
| ISW09 | Backup automático | Tarea programada en el backend; vuelca los datos a un archivo SQL en el volumen. | Implementa RF18: copia diaria, retención de 7, descarga por el administrador. |
| Interfaz | Protocolo / Formato | Detalle |
|---|---|---|
| Frontend → Backend | HTTP / REST (JSON) | Endpoints autenticados con JWT para clientes, proveedores, pedidos, pagos, alertas y usuarios. |
| Backend → Base de datos | SQL (MySQL) | Consultas y actualizaciones sobre el esquema relacional (5.6). Puerto 3306, red interna. |
| Backend → Almacenamiento | Sistema de archivos (volumen) | Lectura y escritura de los archivos subidos y de los backups, por pedido. |
| Backend → Navegador (push) | Web Push (VAPID) | Envío de las notificaciones de alerta de entrega al Service Worker del celular. |
| Recuperación → Usuario | SMTP (email) | Envío del link para poner una clave nueva. Pendiente de activar (LIM04). |
Modelo de datos relacional que sostiene la persistencia del sistema (componente ISW03). Representa qué guarda Espiga y cómo se relacionan las entidades: los clientes y sus pedidos, los pagos de cada pedido (de los que se deriva el saldo), los materiales y adjuntos por pedido, las facturas emitidas al cliente y las recibidas de proveedores, los usuarios del sistema y las suscripciones push de cada dispositivo.
El modelo está normalizado hasta la tercera forma normal (3FN). La normalización no es un trámite formal: es lo que evita que el mismo dato quede escrito en varios lugares y que esos lugares se contradigan con el tiempo. El apartado que sigue documenta qué se revisó y qué se corrigió.
Se partió de un modelo preliminar y se lo revisó forma por forma. En cada paso se buscó una dependencia funcional mal ubicada: un atributo que en realidad no depende de la clave de su tabla.
| Forma | Qué exige | Qué se encontró | Cómo se resolvió |
|---|---|---|---|
| 1FN | Cada celda guarda un único valor atómico y no hay grupos repetidos. | El campo cliente.contacto mezclaba en una sola celda teléfono y email (por ejemplo "11-5566-2233 / marta@mail.com"). El resto ya era atómico. | Conceptualmente se separa en telefono y email, los dos datos que la cobranza necesita por separado (el teléfono para WhatsApp, el email para el resumen). |
| 2FN | 1FN y además ningún atributo no clave depende solo de una parte de la clave. | Todas las tablas usan clave primaria simple (id), así que la 2FN se cumple por construcción. La verificación real es sobre la clave candidata natural: en factura_cliente esa clave es numero, y el tipo de comprobante no dependía del pedido sino del propio comprobante. | Se confirmó que tipo, fecha y monto dependen de la factura y no del pedido, y se mantuvieron en factura_cliente con numero como clave única. |
| 3FN | 2FN y además ningún atributo no clave depende de otro atributo no clave (sin dependencias transitivas). | Dos casos. El saldo de un pedido dependía de la suma de sus pagos, no del pedido en sí: guardarlo como columna lo haría quedar desactualizado en cuanto se cargara un pago. Y el rol, si se guardara como permisos sueltos en usuario, dependería del rol y no del usuario. | El saldo no se guarda: se calcula con la vista v_saldo_pedido. El rol quedó como un ENUM cerrado en usuario, y los permisos se resuelven en el backend (no hay tabla de permisos que mantener). |
No todo texto repetido es una violación de 3FN. pedido.estado (presupuestado, en_produccion, entregado, cerrado, no_concretado), factura_cliente.tipo (Factura A / B / Recibo) y pago.medio son dominios cerrados de pocos valores de los que no depende ningún otro atributo: se resuelven con un tipo ENUM y no necesitan tabla propia. Convertir cada enumeración en un catálogo agregaría joins sin ganar integridad.
En sentido contrario, ningún saldo se almacena: ni el del pedido, ni el del cliente, ni la deuda del proveedor. Los tres son datos derivables de los pagos y las facturas. Un valor derivable no viola la 3FN, pero duplica información y se puede desincronizar, así que se resuelven con vistas (v_saldo_pedido, v_saldo_cliente, v_deuda_proveedor). Es la razón del RNF07.
Hecho y dimensión son términos del modelado dimensional. Espiga no es un modelo en estrella: es transaccional y está en 3FN. Lo que se identifica es el rol que cumple cada tabla, que es lo que hace legibles las consultas de reporte (las estadísticas de RF20 y el panel de saldos de RF02). Un hecho registra algo que pasó, tiene fecha y crece todo el tiempo; una dimensión describe el contexto, cambia poco y sirve para filtrar y agrupar.
| Hecho | Grano (qué representa una fila) | Medida | Volumen |
|---|---|---|---|
| PAGO | Un pago de un cliente sobre un pedido, en una fecha. | monto, sumable. Es la base del saldo. | Alto. Crece con cada cobro. |
| FACTURA_CLIENTE | Un comprobante emitido por un pedido. | monto, sumable. | Medio. |
| FACTURA_PROVEEDOR | Una factura recibida de un proveedor. | monto y pagado; la deuda es su resta. | Medio. |
| MATERIAL | Un material consumido en un pedido. | Ninguna numérica sumable (cantidad como texto). | Medio. |
PAGO es el hecho principal, el que sostiene el saldo (RF03) y el cobrado por mes (RF20). Las tablas restantes son dimensiones, ordenadas por el eje de análisis que aportan:
CLIENTE y USUARIO: de quién es el pedido y quién cargó el pago.
PEDIDO, con ADJUNTO como detalle de sus archivos.
PROVEEDOR: origen de las facturas recibidas.
PUSH_SUSCRIPCION: dónde recibe las notificaciones cada usuario.
Cuándo: no hay tabla de tiempo. El tiempo vive en las columnas fecha de cada hecho. Un modelo en estrella agregaría una dimensión tiempo con año, mes y día de semana; acá el agrupamiento por mes de las estadísticas se resuelve con DATE_FORMAT en la consulta.
El núcleo del modelo tiene diez tablas. La versión 1.0 sumó seis tablas más (mismo criterio 3FN): dieciséis en total. Las nuevas se detallan a continuación y en el esquema relacional.
Personas con acceso (Rodrigo, Ana, Facu y quien se sume). El rol es un ENUM propio, no una tabla. Incluye email y datos de recuperación de clave.
Clientes del taller, con su contacto. Eje de la cuenta corriente.
Madereras y demás proveedores. Eje de las deudas.
Un pedido de un cliente, con presupuesto, estado y fecha de entrega comprometida.
Cada pago de un cliente sobre un pedido. De la resta contra el presupuesto sale el saldo. Es la tabla de mayor volumen.
Consumo de materiales registrado en un pedido: descripción y cantidad.
Plano, foto o lista de corte de un pedido, guardado en el volumen persistente.
Comprobante que el taller emite (Factura A / B / Recibo) por un pedido.
Comprobante recibido de un proveedor, con lo pagado; la deuda es su resta.
Dispositivo de un usuario suscripto a notificaciones push.
Renglones del presupuesto (descripción, cantidad, precio). El total del pedido sale de su suma.
Fotos del mueble; se ven en el seguimiento del cliente.
Cada cambio de estado del pedido, con fecha y responsable.
Material del depósito con stock actual y mínimo.
Entradas y salidas de stock de un insumo.
Suscripción push del cliente a un pedido, desde su link.
| Entidad | Card. | Entidad | Significado |
|---|---|---|---|
| CLIENTE | 1 : N | PEDIDO | Un cliente hace muchos pedidos. |
| PEDIDO | 1 : N | PAGO | Un pedido recibe muchos pagos parciales. |
| PEDIDO | 1 : N | MATERIAL | Un pedido consume varios materiales. |
| PEDIDO | 1 : N | ADJUNTO | Un pedido tiene varios archivos adjuntos. |
| PEDIDO | 1 : N | FACTURA_CLIENTE | Un pedido puede tener uno o más comprobantes emitidos. |
| PROVEEDOR | 1 : N | FACTURA_PROVEEDOR | Un proveedor tiene muchas facturas recibidas. |
| USUARIO | 1 : N | PAGO | Cada pago queda registrado con el usuario que lo cargó. |
| USUARIO | 1 : N | FACTURA_CLIENTE | Cada comprobante queda registrado con quien lo emitió. |
| USUARIO | 1 : N | PUSH_SUSCRIPCION | Un usuario puede tener notificaciones activas en varios dispositivos. |
| PEDIDO | 1 : N | PEDIDO_ITEM | Un pedido se detalla en varios renglones. v1.0 |
| PEDIDO | 1 : N | PEDIDO_FOTO | Un pedido tiene varias fotos. v1.0 |
| PEDIDO | 1 : N | PEDIDO_ESTADO_HISTORIAL | Un pedido acumula sus cambios de estado. v1.0 |
| INSUMO | 1 : N | INSUMO_MOVIMIENTO | Un insumo acumula entradas y salidas. v1.0 |
Definición de tablas (DDL) que materializa el modelo. Sirve como diccionario de datos. Las restricciones UNIQUE son las claves candidatas naturales usadas para verificar la 2FN. Los saldos aparecen como vistas al final, no como columnas.
-- ══════════ TABLAS PRINCIPALES ══════════
CREATE TABLE usuario (
id INT AUTO_INCREMENT PRIMARY KEY,
nombre VARCHAR(120) NOT NULL,
email VARCHAR(150),
usuario_login VARCHAR(60) NOT NULL UNIQUE, -- clave candidata natural
rol ENUM('administrador','administrativo','operario') NOT NULL,
hash_clave VARCHAR(255) NOT NULL, -- bcrypt, nunca texto plano (RNF01)
activo TINYINT(1) NOT NULL DEFAULT 1,
reset_token VARCHAR(64), -- recuperacion de clave (RF09)
reset_expira DATETIME
);
CREATE TABLE cliente (
id INT AUTO_INCREMENT PRIMARY KEY,
nombre VARCHAR(150) NOT NULL,
contacto VARCHAR(150), -- telefono y/o email
activo TINYINT(1) NOT NULL DEFAULT 1
);
CREATE TABLE proveedor (
id INT AUTO_INCREMENT PRIMARY KEY,
nombre VARCHAR(150) NOT NULL,
rubro VARCHAR(100),
activo TINYINT(1) NOT NULL DEFAULT 1
);
CREATE TABLE pedido (
id INT AUTO_INCREMENT PRIMARY KEY,
cliente_id INT NOT NULL REFERENCES cliente(id),
descripcion VARCHAR(255) NOT NULL,
presupuesto DECIMAL(12,2) NOT NULL DEFAULT 0,
fecha_entrega DATE,
estado ENUM('presupuestado','en_produccion','entregado','cerrado','no_concretado')
NOT NULL DEFAULT 'presupuestado'
);
-- Hecho principal: cada pago. El saldo se deriva de aca, no se guarda (3FN + RNF07)
CREATE TABLE pago (
id INT AUTO_INCREMENT PRIMARY KEY,
pedido_id INT NOT NULL REFERENCES pedido(id),
usuario_id INT NOT NULL REFERENCES usuario(id), -- trazabilidad (4.4.4)
fecha DATE NOT NULL,
monto DECIMAL(12,2) NOT NULL,
medio VARCHAR(60) NOT NULL
);
CREATE TABLE material (
id INT AUTO_INCREMENT PRIMARY KEY,
pedido_id INT NOT NULL REFERENCES pedido(id),
descripcion VARCHAR(150) NOT NULL,
cantidad VARCHAR(50) NOT NULL
);
CREATE TABLE adjunto (
id INT AUTO_INCREMENT PRIMARY KEY,
pedido_id INT NOT NULL REFERENCES pedido(id),
nombre_archivo VARCHAR(200) NOT NULL,
tipo VARCHAR(60) NOT NULL,
ruta VARCHAR(255) NOT NULL -- ubicacion en el volumen persistente
);
-- Comprobante emitido. numero es la clave candidata natural (unica)
CREATE TABLE factura_cliente (
id INT AUTO_INCREMENT PRIMARY KEY,
pedido_id INT NOT NULL REFERENCES pedido(id),
usuario_id INT NOT NULL REFERENCES usuario(id),
numero VARCHAR(40) NOT NULL UNIQUE,
fecha DATE NOT NULL,
monto DECIMAL(12,2) NOT NULL,
tipo ENUM('Factura A','Factura B','Recibo') NOT NULL
);
-- Factura recibida. La deuda se deriva de (monto - pagado), no se guarda
CREATE TABLE factura_proveedor (
id INT AUTO_INCREMENT PRIMARY KEY,
proveedor_id INT NOT NULL REFERENCES proveedor(id),
usuario_id INT NOT NULL REFERENCES usuario(id),
numero VARCHAR(40) NOT NULL,
monto DECIMAL(12,2) NOT NULL,
fecha DATE NOT NULL,
pagado DECIMAL(12,2) NOT NULL DEFAULT 0
);
-- Suscripcion push por dispositivo (RF17). endpoint es unico
CREATE TABLE push_suscripcion (
id INT AUTO_INCREMENT PRIMARY KEY,
usuario_id INT NOT NULL REFERENCES usuario(id),
endpoint VARCHAR(500) NOT NULL UNIQUE,
p256dh VARCHAR(255) NOT NULL,
auth VARCHAR(255) NOT NULL
);
-- ══════════ TABLAS AGREGADAS EN LA VERSION 1.0 ══════════
ALTER TABLE cliente ADD COLUMN telefono VARCHAR(40);
ALTER TABLE pedido ADD COLUMN token_seguimiento CHAR(20) UNIQUE;
ALTER TABLE material ADD COLUMN insumo_id INT REFERENCES insumo(id);
CREATE TABLE pedido_item (
id INT AUTO_INCREMENT PRIMARY KEY, pedido_id INT NOT NULL REFERENCES pedido(id),
descripcion VARCHAR(200) NOT NULL, cantidad DECIMAL(10,2) NOT NULL DEFAULT 1,
precio_unitario DECIMAL(12,2) NOT NULL DEFAULT 0
);
CREATE TABLE pedido_foto (
id INT AUTO_INCREMENT PRIMARY KEY, pedido_id INT NOT NULL REFERENCES pedido(id),
ruta VARCHAR(255) NOT NULL, creado_en DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE pedido_estado_historial (
id INT AUTO_INCREMENT PRIMARY KEY, pedido_id INT NOT NULL REFERENCES pedido(id),
estado ENUM('presupuestado','en_produccion','entregado','cerrado','no_concretado') NOT NULL,
usuario_id INT REFERENCES usuario(id), creado_en DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE insumo (
id INT AUTO_INCREMENT PRIMARY KEY, nombre VARCHAR(150) NOT NULL,
unidad VARCHAR(30) NOT NULL DEFAULT 'unidad',
stock_actual DECIMAL(12,2) NOT NULL DEFAULT 0, stock_minimo DECIMAL(12,2) NOT NULL DEFAULT 0,
activo TINYINT(1) NOT NULL DEFAULT 1
);
CREATE TABLE insumo_movimiento (
id INT AUTO_INCREMENT PRIMARY KEY, insumo_id INT NOT NULL REFERENCES insumo(id),
cantidad DECIMAL(12,2) NOT NULL, motivo VARCHAR(150),
usuario_id INT REFERENCES usuario(id), creado_en DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE push_seguimiento (
id INT AUTO_INCREMENT PRIMARY KEY, pedido_id INT NOT NULL REFERENCES pedido(id),
endpoint VARCHAR(500) NOT NULL UNIQUE, p256dh VARCHAR(255) NOT NULL, auth VARCHAR(255) NOT NULL
);
-- ══════════ VISTAS (datos derivados, no almacenados) ══════════
-- Saldo de cada pedido = presupuesto - suma de pagos
CREATE VIEW v_saldo_pedido AS
SELECT p.id AS pedido_id, p.cliente_id, p.presupuesto,
COALESCE(SUM(pg.monto),0) AS total_pagado,
p.presupuesto - COALESCE(SUM(pg.monto),0) AS saldo
FROM pedido p LEFT JOIN pago pg ON pg.pedido_id = p.id
GROUP BY p.id, p.cliente_id, p.presupuesto;
-- Deuda con cada proveedor = suma (monto - pagado) de sus facturas
CREATE VIEW v_deuda_proveedor AS
SELECT pr.id AS proveedor_id, pr.nombre,
COALESCE(SUM(fp.monto - fp.pagado),0) AS deuda
FROM proveedor pr LEFT JOIN factura_proveedor fp ON fp.proveedor_id = pr.id
GROUP BY pr.id, pr.nombre;
-- Alertas de entrega (RF06): pedidos en produccion a 7 dias o menos
CREATE VIEW v_alertas_entrega AS
SELECT p.id AS pedido_id, p.descripcion, p.fecha_entrega, c.nombre AS cliente,
DATEDIFF(p.fecha_entrega, CURDATE()) AS dias_restantes
FROM pedido p JOIN cliente c ON c.id = p.cliente_id
WHERE p.estado = 'en_produccion'
AND DATEDIFF(p.fecha_entrega, CURDATE()) <= 7;
El saldo (RF03) nunca se desincroniza. No es una columna que haya que actualizar con cada pago: es la vista v_saldo_pedido, que siempre refleja los pagos reales. Cargar un pago alcanza para que el saldo cambie en todas las pantallas.
El cierre del pedido es automático. Un trigger pasa el pedido a "cerrado" cuando está entregado y su saldo llegó a cero, sin que nadie tenga que hacerlo a mano — es la regla del diagrama de actividades del análisis, materializada en la base.
Un control que las claves foráneas no cubren. El número de una factura_cliente debe ser único a nivel de todo el taller: eso lo garantiza la restricción UNIQUE sobre numero, no una clave foránea.
Mientras el modelo entidad-relación (5.6) describe qué guarda el sistema, el diagrama de flujo describe qué hace: el recorrido de un pedido desde que se carga hasta que se cobra y se cierra, con las decisiones que el sistema evalúa. Está organizado por carriles (una columna por responsable), para leer también en qué capa ocurre cada paso.
v_saldo_pedido. Si el pedido está entregado y el saldo llegó a 0, el trigger lo cierra. (RF03)Figura 1. Diagrama de flujo del sistema Espiga, con carriles por responsable. El ciclo de un pedido atraviesa las tres capas: la interfaz carga y consulta, el backend valida, calcula y avisa, y la producción actualiza el estado.
Cronograma de tareas, responsables, duración estimada y horas de esfuerzo, organizado por las cinco fases del proyecto. El GANTT se lleva en una planilla de cálculo y se actualiza a medida que avanza el proyecto.
| Fase | Semanas | Tareas principales | Entregable |
|---|---|---|---|
| 1 · Ingeniería de Requerimientos | S1–S5 | Relevamiento del problema, entrevista con Rodrigo, definición de alcance y redacción de la ERS. | Línea de base aprobada + ERS. |
| 2 · Arquitectura y Diseño de Datos | S6–S11 | Modelo entidad-relación, normalización 3FN, diseño de interfaz y setup del entorno (GitHub, stack). | Plan de diseño + repositorio. |
| 3 · Construcción Core | S12–S20 | Base de datos, backend, módulos de clientes, proveedores, pedidos, archivos y panel. | Prototipo funcional (alpha). |
| 4 · Aseguramiento de Calidad | S21–S24 | Pruebas, integración, debugging y optimización. | Software certificado (beta). |
| 5 · Despliegue y Cierre | S25–S28 | Publicación en Railway, mejoras finales (backup, PDF, estadísticas, calendario), documentación y defensa. | Proyecto entregado y defendido. |
Gantt_Espiga.xlsx, con barras por semana y hitos por fase.Organización interna del equipo y herramientas de trabajo. Siguiendo el esquema del libro UTN, el equipo se organiza en un grupo de dirección/gestión y un grupo de desarrollo, adaptado a la escala del proyecto de 7mo.
| Grupo | Rol | Función |
|---|---|---|
| Dirección y Gestión | Director / PM | Cuestiones globales, coordinación, obtención de recursos y relación con el cliente. |
| Líder de proyecto | Asignación de tareas, planificación temporal y económica. | |
| Desarrollo | Backend / BD | Servidor, base de datos, API, despliegue en la nube. |
| Frontend / UX-UI / Doc | Interfaz, mockup, validación con el usuario y documentación. |
<span class="m-photo"> por una foto de perfil de estilo profesional (fondo neutro, encuadre de busto, misma proporción). Confirmar el rol principal de cada integrante — en la práctica el trabajo fue compartido de forma flexible.| Área | Herramienta |
|---|---|
| Gestión de tareas | Planilla de cálculo: GANTT, asignación y estimación de costos. |
| Documentación | Este documento; código y README en GitHub. |
| Comunicación | Grupo de mensajería del equipo + reuniones de validación con el cliente. |
| Repositorio | GitHub (felooaraujo-ai/Kore); equipo docente como colaborador si es privado. |
| Despliegue | Railway, dominio espiga-pcr.up.railway.app, con volumen persistente. |
Cotización de los servicios e insumos necesarios para el funcionamiento del sistema. Al ser un proyecto 100% software, no hay insumos electrónicos ni de fabricación: los únicos costos recurrentes son de infraestructura en la nube.
| Ítem | Detalle | Costo |
|---|---|---|
| Hosting del backend + frontend | Railway (plan usado para el despliegue de producción). | A cotizar |
| Base de datos MySQL | Servicio de base de datos en Railway. | A cotizar |
| Almacenamiento persistente | Volumen de Railway para archivos y backups. | A cotizar |
| Dominio propio (opcional) | Reemplazar el subdominio gratuito por uno propio del taller. | A cotizar |
| Servicio de envío de emails (opcional) | Necesario para activar la recuperación de contraseña (RF09). | A cotizar |
Presupuesto total del proyecto. Suma el costo de infraestructura (sección 7) más el esfuerzo en horas hombre, diferenciado por categoría profesional y su costo por hora (transparencia en el esfuerzo, según los Lineamientos 2026).
Estimación de esfuerzo por fase y por categoría. Las horas son una estimación del equipo para las 28 semanas del cronograma; el costo por hora se completa con el valor de referencia acordado.
| Categoría | Tareas | Horas estim. | $/hora | Subtotal |
|---|---|---|---|---|
| Análisis y diseño | Relevamiento, ERS, modelo de datos, normalización. | 40 h | A completar | Pendiente |
| Backend / Base de datos | API, lógica, vistas, triggers, seguimiento, stock, ítems, push, mails, PDF/QR, seguridad. | 176 h | A completar | Pendiente |
| Frontend / UX-UI | Interfaz, API, rediseño, PWA, modo oscuro, Kanban, dashboard, galería. | 168 h | A completar | Pendiente |
| QA / Pruebas | Pruebas, debugging, verificación en producción. | 40 h | A completar | Pendiente |
| Documentación | Manual de usuario, técnico, esta carpeta de proyecto. | 40 h | A completar | Pendiente |
| Gestión (PM) | Coordinación, relación con el cliente, planificación. | 40 h | A completar | Pendiente |
| Total horas | 508 h | A completar | ||
| Rubro | Detalle | Monto |
|---|---|---|
| Infraestructura / hosting | Railway + almacenamiento persistente (sección 7). | A completar |
| Horas hombre | 400 h estimadas, por categoría y costo/hora (8.1). | A completar |
| Total estimado | Suma de los rubros anteriores. | A completar |
Documento que explicita el acuerdo entre el equipo desarrollador y el cliente (Rodrigo Pasut, PCR Amoblamientos). Se firma en la reunión de validación, habiendo leído las limitaciones (5.1).
Desarrollar, implementar y poner en marcha Espiga, un sistema de gestión web que centraliza clientes con cuenta corriente, proveedores, pedidos, archivos técnicos, cobranzas y entregas, con acceso diferenciado por rol, para eliminar la gestión manual y dispersa del taller.
Equipo desarrollador (integrantes y roles según 3.3) y cliente: Rodrigo Pasut, titular de PCR Amoblamientos (Villa Bosch).
Se entrega lo definido en 3.2 y 5: login con 3 roles, panel de saldos, clientes, proveedores, pedidos, archivos, consumo de materiales, comprobantes y presupuestos en PDF, alertas de entrega (con notificación al celular), calendario, estadísticas, recordatorios de cobranza, backup automático, gestión de usuarios y app instalable, todo publicado en Railway. Queda fuera lo listado en las Limitaciones (LIM01 a LIM05).
Fechas clave del cronograma (6.1): las 5 fases distribuidas en 28 semanas, con entrega y defensa final en noviembre de 2026. A completar con las fechas del GANTT.
El equipo: desarrollo, despliegue, puesta en marcha y documentación. El cliente: validar requerimientos y prototipo, y proveer su email real para activar la recuperación de contraseña.
Se apoyan en los OKRs: saldo de clientes y proveedores calculado automáticamente, alertas de entrega generadas para todo pedido a ≤7 días, archivos conservados entre reinicios, backup diario funcionando, y el sistema accesible desde cualquier dispositivo.
Todo cambio de alcance solicitado durante el desarrollo se registra en el control de cambios (sección 1) y se evalúa su impacto en el GANTT y en la oferta económica antes de aceptarse.
Firma del equipo desarrollador y de Rodrigo Pasut (simbólica, en la validación del prototipo).
Documento de trabajo del equipo. Registra la investigación de campo (entrevistas y minutas) y el seguimiento de la iteración (cambios de interfaz y avances técnicos por fase). No describe el sistema sino el proceso, y se actualiza a medida que el proyecto avanza.
| Fecha | Con quién | Objetivo | Modalidad |
|---|---|---|---|
| A completar | Rodrigo Pasut · titular del taller | Entrevista 1. Identificación del problema real y relevamiento de la línea de base (cómo se lleva hoy el saldo, los pedidos y las deudas). | Presencial |
| A completar | Rodrigo Pasut | Entrevista 2. Detalle de los tres roles del taller (quién hace qué) y del circuito de un pedido, del presupuesto al cobro. | Presencial |
| A completar | Rodrigo Pasut | Validación del prototipo. Feedback sobre el mockup antes de conectar la lógica real. | Presencial / Virtual |
Acta breve de cada reunión, siempre con los mismos seis campos, para que cualquier participante pueda reconstruir qué se decidió y quién quedó a cargo de qué.
Modificaciones aplicadas a la interfaz después de validarla con Rodrigo. Es la trazabilidad de la iteración con el usuario.
| Componente modificado | Qué se modificó | Por qué (justificación UX / usuario) |
|---|---|---|
| Pantalla de login | Se quitaron los usuarios y claves de ejemplo que se mostraban al pie. | Era un hueco de seguridad: cualquiera que abriera la página veía credenciales válidas (RNF02). |
| Navegación en celular | Barra inferior simplificada (Inicio, Clientes, Prov., Pedidos, Alertas) distinta del menú de escritorio. | En pantalla chica, la barra lateral completa no entra; se prioriza lo que se usa en la calle. |
| Estética general | Rediseño con identidad "madera" (login, barra, menú, tarjetas), marcando el ítem activo del menú. | Un taller de muebles se identifica más con una estética cálida de madera que con un panel gris genérico. |
Hitos técnicos cerrados, en orden, siguiendo las fases del cronograma (6.1).
| Fase | Hitos registrados | Fecha de cierre |
|---|---|---|
| 1–2 | Documento de análisis: mockup, roles, diagrama entidad-relación y de actividades. Modelo de datos normalizado a 3FN. | A completar |
| 3 | Base de datos y backend construidos paso a paso, cubriendo RF01 a RF11. Conexión del mockup a la API real. | A completar |
| 5 | Publicación en Railway (repo felooaraujo-ai/Kore), subida real de archivos con volumen persistente y dominio propio. | A completar |
| 5 | Recuperación de clave por email (pausada), comprobantes y PDF, consumo de materiales, buscador y filtros (RF12–RF15). | A completar |
| 5 | App instalable (PWA) y notificaciones push probadas en un iPhone real (RF16, RF17). | A completar |
| 5 | Backup automático, presupuesto en PDF, estadísticas, calendario y recordatorios de cobranza (RF18–RF22). Rediseño estético. | A completar |
Puesta en marcha para Rodrigo, Ana y Facu. Sin jerga técnica: no hace falta saber qué es una API ni una base de datos para usar el sistema.
espiga-pcr.up.railway.app e ingresar con usuario y clave. La pantalla no muestra datos de ejemplo, por seguridad. (RF01)Las preguntas que el cliente y los usuarios del taller hacen con más frecuencia, con la respuesta y la referencia al requerimiento o la limitación que la respalda.
espiga-pcr.up.railway.app. No depende de ninguna computadora del taller (RF11). Opcionalmente se puede instalar como app en el celular (RF16).