Repository navigation
Home
- Repositorio de ceremonias: Por cada sprint es necesario tener un repositorio de las ceremonias hechas al interior del equipo, con sus respectivas evidencias (grabaciones, fotos, actas de reuniones). Estas evidencias tendrán un peso en la rúbrica de evaluación.
- Plataforma de entrega: En este documento se enuncian los contenidos de cada entrega, pero no serán documentos en Word, sino que serán secciones dentro de una Wiki (o su elemento homólogo en la herramienta de gestión del proyecto que se esté trabajando). Para cada entregable se deberá crear una sección en la Wiki con el fin de conservar el orden y facilitar la calificación de cada entrega.
- Presentaciones: En cada entrega hay una presentación, y cada presentación tiene contenidos asociados.
- Sustentación: La sustentación de cada entrega es de carácter obligatorio. Ojo: si un integrante no asiste a la sustentación tendrá 0.0 en la nota completa del sprint.
- Este documento estará disponible en Interactiva y en Teams.
A continuación, encontrarán todos los ítems evaluables para el Sprint 0.
Importante: Recuerden que toda la entrega debe diligenciarse en la plataforma de gestión de proyectos que se esté utilizando. NO se recibe un documento por aparte; SOLO SE REVISA LA HERRAMIENTA DE GESTIÓN DE PROYECTOS.
En este Sprint nos centramos en la definición del producto. NO SE ESPERAN AVANCES A NIVEL DE DESARROLLO.
- Repositorios creados.
- Acuerdos con el cliente / empresa / product owner.
- Evidencias de las ceremonias.
- Definición del Producto.
- Diseño de la Arquitectura.
- Mockups de las Interfaces de la aplicación a construir.
- Sustentación (hay sustentación para clientes, y para los profesores).
| Entregable | Peso en la nota (%) |
|---|---|
| Repositorios, Wiki, Acuerdos con el cliente, y Evidencias de las ceremonias | 10% |
| Definición del Producto | 20% |
| Diseño de la Arquitectura | 30% |
| Mockups de las Interfaces | 20% |
| Presentación | 20% |
Coinogas gestiona hoy la radicación de sus requerimientos de compra mediante un formato en Microsoft Excel denominado 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 un servicio descarga el archivo, lo diligencia manualmente y lo envía por correo electrónico al área de compras. Una vez allí, el equipo de compras vuelve a transcribir esa información, de forma manual, hacia un archivo consolidado de Excel al que internamente se le llama «la sábana».
Durante la sesión de levantamiento de requerimientos realizada el 24 de julio de 2026, el cliente identificó los siguientes problemas asociados a este proceso:
- Ausencia de trazabilidad: El área de compras no cuenta con un registro claro y consultable de las especificaciones iniciales de cada requerimiento, lo que impide reconstruir qué se pidió, quién lo pidió y bajo qué condiciones.
- Errores por copiado y pegado: El hábito de reutilizar formatos de requerimientos anteriores arrastra información desactualizada. El propio archivo que sirve de insumo a este documento —el requerimiento de calibración del equipo Fluke 725 con módulos de presión y RTD— fue citado por el cliente como un caso donde se emplearon especificaciones que ya no correspondían al periodo vigente.
- Doble digitación: La información viaja del solicitante al correo, del correo a la vista del analista y de allí, a mano, a la sábana de Excel. Cada transcripción es una oportunidad de error y un costo de tiempo que no agrega valor.
- Diligenciamiento incompleto: El formato exige explícitamente no dejar espacios sin diligenciar y rellenar con «N/A» cuando no haya información, pero al ser un archivo de hoja de cálculo no existe ningún mecanismo que impida enviarlo incompleto. En el ejemplo analizado, los campos de precio de referencia unitario quedaron vacíos y los totales en cero.
- Bloqueo del proceso de cotización: El personal de compras no puede iniciar la solicitud de cotizaciones a proveedores mientras no reciba un formato correctamente diligenciado, de modo que cada formato incompleto se traduce directamente en retraso.
- Desgaste operativo: El cliente calificó el proceso actual como «tedioso y desgastante» para los funcionarios que deben radicar requerimientos.
Se propone VIA Compras, una aplicación web que reemplaza el archivo Excel ADM-F-22 por un formulario digital conectado a una base de datos centralizada. La solución conserva íntegramente la estructura y la lógica del formato institucional vigente —de modo que el cambio no obligue a rediseñar el procedimiento administrativo de Coinogas— pero traslada al software las responsabilidades que hoy recaen sobre la disciplina del usuario.
Las capacidades centrales del producto son:
- Formulario web que replica el ADM-F-22: Encabezado con solicitante, área y centro de costo; justificación del requerimiento; planeación de la recepción con prioridad y fecha requerida; tabla de ítems con cantidad, descripción, marca de calibración y de reembolsable; especificaciones técnicas; sugerencias de proveedor; y alternativas o productos sustitutos.
- Validación de campos obligatorios: Impide enviar un requerimiento incompleto, sustituyendo la instrucción escrita al pie del formato por una regla que el sistema hace cumplir.
- Carga de fotografías: Carga de imágenes ilustrativas directamente desde el computador o desde la cámara de un dispositivo móvil, para eliminar las confusiones sobre qué artículo se está solicitando.
- Registro automático: Almacenamiento directo en una base de datos central, que elimina por completo la transcripción manual hacia la sábana de Excel.
- Bandeja centralizada: Panel para el área de compras con filtros por área, prioridad, estado y fecha, y acceso a la ficha completa de cada requerimiento con sus adjuntos.
- Capa analítica (Power BI): Capa de solo lectura sobre la base de datos, consumida desde Microsoft Power BI, que permite al área de compras y a la dirección ver indicadores de la operación —volumen de requerimientos por área, distribución por prioridad, tiempos de atención y tasa de devolución— sin tocar los datos transaccionales.
- Formulario siempre en blanco: Por decisión expresa del cliente, el sistema no ofrece plantillas ni precarga de requerimientos anteriores, precisamente para forzar que cada solicitante redacte las especificaciones desde cero y no herede datos erróneos de periodos previos.
Decisión de diseño relevante: Durante la sesión se evaluó la posibilidad de reutilizar plantillas para agilizar el diligenciamiento. El cliente descartó explícitamente esa alternativa y solicitó mantener el proceso «manual y fresco». Esta restricción se documenta porque va en contra de lo que sería una optimización natural del producto y debe respetarse en el diseño.
En la sesión se acordó priorizar la funcionalidad esencial sobre los desarrollos complejos, con el fin de garantizar que la solución principal funcione antes de añadir capas adicionales. En consecuencia, quedan fuera del alcance de esta primera versión:
-
Un sistema propio de autenticación e inicio de sesión con gestión de usuarios y roles a la medida. La administración se resolverá con el panel administrativo nativo del framework.
-
Una base de datos maestra de proveedores. El solicitante sugiere hasta tres proveedores como texto libre y el área de compras se encarga de validarlos y crearlos cuando inicie el contacto formal.
-
Flujos de aprobación jerárquica por jefatura o presupuesto.
-
Integración con el ERP o con el sistema contable de Coinogas.
-
Requerimiento en confirmación: El cliente planteó de forma preliminar la posibilidad de incorporar Microsoft Power BI para la visualización de indicadores. El alcance quedó definido de manera 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. Debe confirmarse con el cliente si Coinogas ya cuenta con licencias de Power BI y quién será el responsable de publicar y mantener el tablero.
-
Supuesto por validar: El alcance excluye un login propio, pero el panel de administración del framework sí exige credenciales. Se asume que esto es aceptable para el cliente porque no implica desarrollo adicional. Debe confirmarse en la siguiente sesión.
| Nombre completo | Correo institucional | Rol en el proyecto |
|---|---|---|
| David Cuadros | dacuadrosm@eafit.edu.co | Scrum Master |
| Juan Camilo Gomez | jcgomezj@eafit.edu.co | UX/UI - Tester |
| Juan Esteban Villada | jevilladao@eafit.edu.co | Desarrollador |
| Juan Pablo Posso | jppossov@eafit.edu.co | Project Manager - Desarrollador |
| Interesado | Organización | Papel en el proyecto |
|---|---|---|
| Sergio Andrés Quintero Albarracín | Coinogas | Interlocutor principal y fuente de requisitos; describe el proceso actual y define el alcance esperado. |
| Daryi Alejandra Silva López | Coinogas — Área de Compras | Usuaria final del área de compras; recibe y procesa los requerimientos radicados. |
| Gerardo Cuadros Chahín | Coinogas | Gerente General de la Empresa |
| Tipo de usuario | Descripción | Interacción principal |
|---|---|---|
| Solicitante | Funcionario de cualquier área de Coinogas —operativa, técnica o administrativa— 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 ni memoria del procedimiento. Puede conocer a fondo la especificación técnica de lo que pide pero no necesariamente el vocabulario del área de compras. | Diligencia y envía el formulario de requerimiento; adjunta fotografías; consulta el estado de sus solicitudes. |
| Analista de Compras | Personal del área de compras, representado por Alejandra. Es un usuario intensivo: trabaja con la herramienta a diario y depende de ella para iniciar los procesos de cotización. Necesita ver todos los requerimientos en un solo lugar y detectar rápidamente los que están incompletos o son urgentes. | 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 mantener los datos maestros del sistema: áreas, centros de costo, catálogos de prioridad y cuentas de usuario. En el MVP este rol se atiende con el panel administrativo nativo del framework, sin desarrollo adicional. | Parametriza catálogos; gestiona cuentas; supervisa la integridad de los datos. |
| Sistema / elemento | Tipo | Relación con VIA Compras |
|---|---|---|
| Navegador web | Software | Único cliente de la aplicación. Se soportarán versiones recientes de Chrome, Edge y Firefox en escritorio, y Chrome y Safari en dispositivos móviles. |
| Dispositivo móvil con cámara | Hardware | Permite al solicitante capturar la fotografía del artículo requerido y adjuntarla directamente, sin pasar por un computador. |
| Servicio de correo corporativo (SMTP) | Software externo | Recibe del sistema la notificación de radicación dirigida al área de compras y la confirmación al solicitante. |
| Almacenamiento de archivos e imágenes | Software / infraestructura | Persiste los adjuntos fotográficos asociados a cada requerimiento y los sirve al momento de la consulta. |
| Base de datos relacional PostgreSQL | Software | Repositorio central de requerimientos, ítems, especificaciones, proveedores sugeridos y bitácora de cambios. |
| Sábana consolidada en Excel | Sistema heredado | Convive con el sistema durante la transición. VIA Compras la alimenta mediante exportación, en lugar de que el analista la digite a mano. |
| Microsoft Power BI (Desktop y Service) | Software externo | Se conecta a la base de datos mediante un usuario de solo lectura y un conjunto de vistas expuestas por el sistema, para construir el tablero de indicadores del área de compras. No escribe sobre la base de datos ni participa del flujo transaccional. |
| Servidor de aplicación (contenedor Docker) | Infraestructura | Aloja la aplicación Django y la expone en la red interna de Coinogas. |
El siguiente diagrama muestra a VIA Compras como una caja única y sus intercambios de información con los actores y sistemas externos descritos:
Figura 1. Diagrama de contexto del sistema VIA Compras.
- El funcionario 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 ninguna opción de duplicar o precargar un requerimiento anterior.
- El solicitante diligencia el encabezado: su nombre, el área o proyecto y el centro de costo. La fecha de solicitud se registra automáticamente.
- Redacta la justificación del requerimiento, explicando por qué se necesita la compra.
- Agrega uno o más ítems. Por cada ítem indica cantidad y descripción, y marca si requiere calibración y si es reembolsable. Opcionalmente registra el precio de referencia unitario; el sistema calcula el total.
- Diligencia las especificaciones técnicas aplicables: marca, material, número de parte, referencia, color, dimensiones, presentación y otras.
- Adjunta una o más fotografías o imágenes ilustrativas del artículo solicitado.
- Sugiere hasta tres proveedores con su respectivo teléfono de contacto, e indica si existen productos o servicios sustitutos.
- Define la prioridad de la compra y la fecha en que requiere recibirla.
- Envía el requerimiento. Si algún campo obligatorio está vacío, el sistema bloquea el envío y señala con precisión qué falta.
- Cuando la validación es satisfactoria, el sistema asigna un consecutivo único, almacena el requerimiento y muestra la confirmación en pantalla.
- En cualquier momento posterior el solicitante puede consultar el listado de sus requerimientos y el estado de cada uno.
- Recibe la notificación por correo de que se radicó un nuevo requerimiento.
- Ingresa a la bandeja centralizada, donde ve todos los requerimientos recibidos en un solo lugar.
- Filtra y ordena por área, prioridad, fecha requerida o estado, para decidir cuáles atender primero.
- Abre la ficha completa de un requerimiento y revisa ítems, especificaciones técnicas, proveedores sugeridos y fotografías adjuntas.
- Si la información no es suficiente, devuelve el requerimiento al solicitante con observaciones. Si es suficiente, lo marca como «En cotización» e inicia el contacto con proveedores.
- Cuando lo necesita, exporta el consolidado de requerimientos para el seguimiento y los informes del área.
- Ingresa al panel de administración con sus credenciales.
- Parametriza los datos maestros: áreas, centros de costo y niveles de prioridad disponibles en el formulario.
- Crea, modifica o desactiva cuentas de usuario y sus permisos.
- Supervisa la integridad de los datos y corrige registros cuando el área de compras lo reporta.
El alcance técnico de la arquitectura del Producto Mínimo Viable (MVP) se enfoca en resolver el núcleo operativo de captura, validación, almacenamiento y consulta de solicitudes de compra de Coinogas.
| Componente / Característica | Alcance en el MVP | Solución Completa / Futuras Fases |
|---|---|---|
| Captura de Requerimiento | Formulario web interactivo con validación estricta en cliente/servidor y carga directa de fotos. Formulario siempre en blanco. | Sugerencias inteligentes de items y autocompletado desde historial administrativo. |
| Gestión de Proveedores | Campos de texto libre para hasta 3 proveedores sugeridos por el solicitante. | Base de datos maestra de proveedores con calificación, historial de cotizaciones y NIT verificado. |
| Autenticación y Permisos | Acceso abierto a radicación interna y panel de administración nativo de Django para gestión de usuarios y catálogos. | Integración con SSO corporativo (Azure AD / Active Directory) y control de acceso basado en roles finos (RBAC). |
| Flujos de Aprobación | Transición de estados directa por el Analista de Compras (Radicado, En Cotización, Devuelto, Finalizado). | Motor de flujo de trabajo con aprobaciones jerárquicas multinivel según presupuesto y centro de costo. |
| Integración de Sistemas | Exportación a formato Excel desde la bandeja central y vistas SQL exponibles a Power BI. | Integración bidireccional vía REST API / SOAP con el ERP contable de Coinogas. |
- Tiempos de respuesta esperados: Carga inicial del formulario y renderizado en < 1.5 segundos. Procesamiento de radicación con imágenes y envío de correos en < 3.0 segundos en red interna.
- Cantidad de usuarios del sistema: Aproximadamente 150 usuarios solicitantes potenciales en la organización, 5 analistas de compras activos y 2 administradores de sistema.
- Concurrencia estimada: Entre 5 y 15 usuarios concurrentes pico durante el horario laboral (8:00 AM - 5:00 PM).
- Peticiones a recibir por segundo (RPS): Promedio de 2 a 5 RPS; picos máximos estimados de 15 RPS durante el cierre de requerimientos semanales.
- Volumen de almacenamiento: Estimado en 500 requerimientos mensuales, con un promedio de 2 fotografías por requerimiento (aprox. 3 MB por foto optimizada), lo que genera un crecimiento mensual de almacenamiento de ~3 GB.
| Categoría | Requisito No Funcional | Descripción e Implementación |
|---|---|---|
| Seguridad | Protección de datos e integridad | Saneamiento de entradas contra inyecciones SQL y XSS. Aislamiento de la capa analítica mediante usuarios PostgreSQL de solo lectura. Transmisión cifrada vía HTTPS en la intranet. |
| Usabilidad | Diseño Responsive y Accesible | Interfaz limpia optimizada para pantallas de escritorio y dispositivos móviles (tabletas/smartphones) permitiendo la captura y subida directa de imágenes desde la cámara. |
| Disponibilidad | SLA Operativo | Disponibilidad del 99.5% durante horario laboral corporativo mediante contenedor Docker autoreiniciable y respaldo diario de base de datos. |
| Mantenibilidad | Arquitectura Modular | Separación clara de responsabilidad siguiendo la arquitectura Modelo-Vista-Template (MVT) de Django, facilitando la incorporación de nuevos módulos. |
- RequerimientoCompra: Entidad principal que representa la solicitud ADM-F-22. Almacena el consecutivo único, fecha de radicación, estado (Radicado, En Cotización, Devuelto, Procesado), justificación, prioridad y fecha requerida de entrega.
- Solicitante / Usuario: Funcionario que genera la solicitud. Contiene nombre completo, correo corporativo, cargo y relación con el área.
- Area / CentroCosto: Catálogos maestros para clasificar la procedencia presupuestal del requerimiento (ej. Operativa, Mantenimiento, Dirección).
- ItemRequerimiento: Bien o servicio solicitado individualmente dentro de un requerimiento. Incluye cantidad, unidad de medida, descripción detallada, indicador de calibración (booleano) e indicador de reembolsable (booleano).
- EspecificacionTecnica: Ficha técnica asociada a un ítem o requerimiento. Contiene marca, número de parte, referencia, dimensiones, material, color y presentación.
- ProveedorSugerido: Información de hasta tres proveedores recomendados por el solicitante (nombre/razón social, teléfono de contacto y observaciones).
- AdjuntoFotografico: Archivos multimedia o fotografías que respaldan visualmente los ítems solicitados, almacenados con su ruta y metadata.
- BitacoraEstado: Registro histórico de cambios de estado y observaciones realizadas por el Analista de Compras.
(Diagrama E-R definido para el sistema)
La arquitectura de VIA Compras se estructura bajo un esquema de Monolito Modular desplegado sobre contenedores, dividida en los siguientes componentes principales:
| Componente / Subsistema | Tecnología Utilizada | Descripción y Responsabilidad |
|---|---|---|
| Capa de Presentación (Frontend Web) | HTML5, CSS3 (Tailwind CSS), JavaScript (ES6) | Interfaz de usuario responsive. Se encarga de capturar las solicitudes mediante el formulario digital, ejecutar validaciones inmediatas en el navegador (campos requeridos, formatos de archivo), permitir la captura/carga de fotografías y presentar la bandeja centralizada con filtros al analista de compras. |
| Controlador y Lógica de Negocio (Backend) | Python 3.11 / Django Framework | Procesa las peticiones HTTP, aplica la lógica de dominio, valida reglas de negocio del formato ADM-F-22, gestiona las transacciones de base de datos, administra la bitácora de cambios de estado y maneja las sesiones del panel administrativo. |
| Servicio de Notificaciones | Django Mail API / Protocolo SMTP | Subsistema encargado de enviar correos electrónicos automáticos de confirmación al solicitante y avisos inmediatos al área de compras al radicarse un nuevo requerimiento. |
| Módulo de Almacenamiento de Archivos (Media Storage) | Docker Volume / Sistema de archivos local servido por Nginx | Almacena, organiza y sirve de forma segura las imágenes y fotografías adjuntas cargadas por los usuarios durante el proceso de solicitud. |
| Base de Datos Relacional | PostgreSQL 15 | Repositorio central de información transaccional. Garantiza la consistencia ACID de los requerimientos, catálogos, ítems, proveedores sugeridos y usuarios. Expone vistas SQL optimizadas para la capa analítica. |
| Capa Analítica y Reportes | Microsoft Power BI (Desktop / Service) | Consume las vistas expuestas por PostgreSQL mediante una conexión con usuario de solo lectura para generar el tablero de control de KPIs (volumen por área, tiempos de atención, tasa de devolución). |
(Diagrama Arquitectónico de Componentes Nivel 2 definido para el sistema)
La arquitectura monolítica modular basada en Django y PostgreSQL desplegada en contenedores Docker fue seleccionada por las siguientes razones estratégicas vinculadas a los requisitos del proyecto:
- Simplicidad y Velocidad de Desarrollo (Alineación con el MVP): Un enfoque monolítico modular evita la complejidad innecesaria de infraestructura propia de microservicios, permitiendo construir, probar y desplegar el sistema dentro de las restricciones de tiempo del Sprint 0.
- Aseguramiento del Requisito "Formulario Siempre en Blanco": Django centraliza la validación del lado del servidor, asegurando que ninguna solicitud sea procesada si contiene especificaciones heredadas o incompletas.
- Aislamiento de la Capa Analítica: Al conectar Power BI directamente a vistas SQL de solo lectura en PostgreSQL, se logra brindar capacidad analítica a la gerencia y compras sin recargar la aplicación web transaccional ni arriesgar la integridad de los datos.
- Portabilidad y Bajo Mantenimiento: El empaquetamiento completo mediante Docker asegura que la solución pueda ser ejecutada en la infraestructura interna de Coinogas sin fricciones de configuración de dependencias.
(Sección correspondiente a los mockups y diseños de pantalla del sistema)