1 Generalidades del Proyecto - Davidcuama/via-coinogas GitHub Wiki
Sección 1 · Generalidades del Proyecto
1.1 Descripción del problema y su solución software
Contexto y descripción del problema
Coinogas gestiona la radicación de sus requerimientos de compra mediante el formato ADM-F-22 «Manifestación Requerimiento de Compra», Revisión 02, vigente desde el 18 de enero de 2021. El funcionario que necesita adquirir un bien o servicio descarga el archivo de Excel, lo diligencia manualmente y lo envía por correo al área de compras. Allí, el equipo vuelve a transcribir esa información a un archivo consolidado al que internamente llaman la sábana.
Durante la sesión de levantamiento del 24 de julio de 2026, el cliente identificó los siguientes problemas:
- Ausencia de trazabilidad. El área de compras no cuenta con un registro consultable de las especificaciones iniciales de cada requerimiento.
- Errores por copiado y pegado. Reutilizar formatos anteriores arrastra información desactualizada. El caso citado por el cliente fue un requerimiento de calibración de un equipo Fluke 725 donde se emplearon especificaciones de un periodo que ya no correspondía.
- Doble digitación. La información viaja del solicitante al correo, y del correo a la sábana a mano. Cada transcripción es una oportunidad de error.
- Diligenciamiento incompleto. El formato pide expresamente no dejar espacios vacíos y rellenar con «N/A», pero al ser una hoja de cálculo nada impide enviarlo incompleto.
- Bloqueo del proceso de cotización. Compras no puede pedir cotizaciones sin un formato correctamente diligenciado, así que cada formato incompleto es un retraso directo.
- Desgaste operativo. El cliente calificó el proceso actual como «tedioso y desgastante».
Solución software propuesta
VIA Coinogas es una aplicación web que reemplaza el archivo Excel por un formulario digital conectado a una base de datos centralizada. Conserva íntegramente la estructura del formato institucional vigente, de modo que el cambio no obliga a rediseñar el procedimiento administrativo, pero traslada al software las responsabilidades que hoy dependen de la disciplina del usuario.
Capacidades centrales:
- Formulario web que replica el ADM-F-22: encabezado, justificación, planeación de la recepción, tabla de ítems, especificaciones técnicas, proveedores sugeridos y alternativas.
- Validación de campos obligatorios que impide enviar un requerimiento incompleto.
- Carga de fotografías desde computador o desde la cámara de un dispositivo móvil.
- Registro automático en base de datos central, eliminando la transcripción manual hacia la sábana.
- Bandeja centralizada para el área de compras con filtros y acceso a la ficha completa.
- Capa analítica de solo lectura consumida desde Power BI para el tablero de indicadores.
- Formulario siempre en blanco, por decisión expresa del cliente.
Decisión de diseño relevante Durante la sesión se evaluó reutilizar plantillas para agilizar el diligenciamiento. El cliente descartó explícitamente esa alternativa y pidió mantener el proceso «manual y fresco». Esta restricción va en contra de lo que sería una optimización natural del producto y debe respetarse en el diseño.
Alcance del MVP y exclusiones acordadas
Se acordó priorizar la funcionalidad esencial sobre los desarrollos complejos. Quedan fuera del alcance de esta primera versión:
- Un sistema propio de autenticación con gestión de usuarios y roles a la medida. La administración se resuelve con el panel nativo de Django.
- Una base de datos maestra de proveedores. El solicitante sugiere hasta tres como texto libre y compras los valida al iniciar el contacto formal.
- Flujos de aprobación jerárquica por jefatura o presupuesto.
- Integración con el ERP o el sistema contable de Coinogas.
Requerimiento en confirmación El cliente planteó de forma preliminar incorporar Microsoft Power BI para la visualización de indicadores. El alcance se definió para que sea viable sin comprometer el flujo principal: el equipo entrega las vistas de solo lectura y un usuario de base de datos restringido, y el tablero se construye sobre esa base. Falta confirmar si Coinogas cuenta con licencias de Power BI y quién será el responsable de publicar y mantener el tablero.
1.2 Personas y roles del proyecto
| Integrante | Correo institucional | Rol en el proyecto |
|---|---|---|
| David Cuadros | (pendiente) | Product Owner. Enlace con el cliente, priorización del backlog y construcción del tablero de indicadores. |
| Juan Esteban Villada | (pendiente) | Scrum Master y desarrollador backend. Facilita las ceremonias y lidera el modelo de datos y la lógica del formulario. |
| Juan Camilo Gómez | (pendiente) | Desarrollador backend. Responsable de la persistencia, las vistas analíticas y el acceso de solo lectura. |
| Juan Pablo Posso | (pendiente) | Desarrollador frontend y responsable de calidad. Interfaz del formulario, validaciones en cliente y pruebas. |
Interesados por parte del cliente
| Interesado | Organización | Papel en el proyecto |
|---|---|---|
| Sergio Andrés Quintero Albarracín | Coinogas | Interlocutor principal y fuente de requisitos. |
| Daryi Alejandra Silva López | Coinogas — Área de Compras | Usuaria final; recibe y procesa los requerimientos radicados. |
| Gerardo Cuadros Chahín | Coinogas | Interesado; participante de la sesión de levantamiento. |
1.3 Público objetivo y contexto
Tipos de usuario
| Tipo de usuario | Descripción | Interacción principal |
|---|---|---|
| Solicitante | Funcionario de cualquier área de Coinogas que detecta la necesidad de adquirir un bien o contratar un servicio. Es un usuario ocasional: no radica requerimientos todos los días, por lo que no puede asumirse familiaridad con la herramienta. Puede conocer a fondo la especificación técnica de lo que pide, pero no el vocabulario del área de compras. | Diligencia y envía el formulario; adjunta fotografías; consulta el estado de sus solicitudes. |
| Analista de Compras | Personal del área de compras. Es un usuario intensivo: trabaja con la herramienta a diario y depende de ella para iniciar los procesos de cotización. | Consulta la bandeja centralizada; filtra y prioriza; revisa la ficha completa; cambia estados; exporta el consolidado; consulta el tablero de indicadores. |
| Administrador del sistema | Perfil técnico responsable de los datos maestros: áreas, centros de costo, catálogos de prioridad y cuentas. En el MVP se atiende con el panel administrativo nativo de Django. | Parametriza catálogos; gestiona cuentas; supervisa la integridad de los datos. |
Sistemas de software y hardware que interactúan
| Sistema / elemento | Tipo | Relación con VIA Coinogas |
|---|---|---|
| Navegador web | Software | Único cliente de la aplicación. Chrome, Edge y Firefox en escritorio; Chrome y Safari en móvil. |
| Dispositivo móvil con cámara | Hardware | Permite capturar la fotografía del artículo requerido y adjuntarla directamente. |
| Servicio de correo corporativo (SMTP) | Software externo | Recibe la notificación de radicación dirigida al área de compras. |
| Almacenamiento de archivos e imágenes | Infraestructura | Persiste los adjuntos fotográficos y los sirve en la consulta. |
| Base de datos PostgreSQL | Software | Repositorio central de requerimientos, ítems, especificaciones y bitácora. |
| Sábana consolidada en Excel | Sistema heredado | Convive durante la transición. Se alimenta por exportación, no por digitación. |
| Microsoft Power BI (Desktop y Service) | Software externo | Se conecta mediante un usuario de solo lectura sobre vistas expuestas por el sistema. No escribe en la base de datos. |
| Servidor de aplicación (Docker) | Infraestructura | Aloja la aplicación Django y la expone en la red interna de Coinogas. |
Diagrama de contexto
1.4 Descripción del proceso de interacción
Flujo del Solicitante
- Detecta una necesidad de compra en su área y accede a la URL del formulario desde la red interna.
- El sistema presenta un formulario en blanco. No se ofrece duplicar ni precargar un requerimiento anterior.
- Diligencia el encabezado: nombre, área o proyecto y centro de costo. La fecha se registra automáticamente.
- Redacta la justificación del requerimiento.
- Agrega uno o más ítems con cantidad y descripción, y marca si requieren calibración y si son reembolsables.
- Diligencia las especificaciones técnicas aplicables.
- Adjunta fotografías o imágenes ilustrativas del artículo.
- Sugiere hasta tres proveedores con teléfono e indica si existen productos sustitutos.
- Define la prioridad y la fecha requerida de recepción.
- Envía. Si falta algún campo obligatorio, el sistema bloquea el envío y señala qué falta.
- Al validar correctamente, el sistema asigna un consecutivo único y muestra la confirmación.
- Puede consultar después el listado de sus requerimientos y su estado.
Flujo del Analista de Compras
- Recibe la notificación por correo de un nuevo requerimiento radicado.
- Ingresa a la bandeja centralizada.
- Filtra y ordena por área, prioridad, fecha requerida o estado.
- Abre la ficha completa y revisa ítems, especificaciones, proveedores sugeridos y fotografías.
- Si la información no es suficiente, devuelve el requerimiento con observaciones. Si lo es, lo marca como «En cotización».
- Exporta el consolidado para el seguimiento del área.
- Consulta el tablero de indicadores en Power BI.
Flujo del Administrador
- Ingresa al panel de administración con sus credenciales.
- Parametriza áreas, centros de costo y niveles de prioridad.
- Crea, modifica o desactiva cuentas de usuario y permisos.
- Supervisa la integridad de los datos.
Diagramas de flujo
1.5 Glosario de términos
El glosario completo está en la página Glosario.