Módulo 7: Proyecto Final Integrador

Introducción

Has llegado al último módulo del curso y al cierre de toda la Ruta Python de COA.

En esta etapa no aprenderás otro framework ni agregarás funciones sin propósito. Utilizarás todo lo construido para entregar un producto coherente, probado, documentado y desplegado.

Lógica de Programación
        ↓
Python Nivel 1
        ↓
Python Intermedio
        ↓
Python Práctico
        ↓
Desarrollo de Software con Python
        ↓
SQL y Bases de Datos
        ↓
Desarrollo de Aplicaciones Web Profesionales con Django
        ↓
COA Gestión Empresarial Web

El proyecto final debe responder cinco preguntas:

¿Resuelve un problema empresarial definido?
¿Mantiene datos correctos?
¿Protege cada operación según el rol?
¿Puede instalarse, probarse y desplegarse?
¿Puedes explicar y modificar el código?

Una gran cantidad de pantallas no compensa una regla incorrecta. Un diseño atractivo no compensa una autorización rota. Una aplicación publicada no compensa un repositorio con secretos.

El objetivo es demostrar dominio, no aparentar complejidad.

Objetivos de aprendizaje

Al finalizar este módulo podrás:

• analizar una necesidad empresarial;
• convertir necesidades en requisitos verificables;
• definir alcance y prioridades;
• diseñar un modelo relacional coherente;
• conectar requisitos, reglas, código y pruebas;
• desarrollar un sistema empresarial web completo;
• aplicar arquitectura MVT y separación por responsabilidades;
• implementar autenticación, perfiles, grupos y permisos;
• construir CRUD con validaciones;
• ejecutar operaciones transaccionales;
• mantener un historial confiable de inventario;
• crear paneles y reportes;
• exportar CSV y Excel;
• probar procesos críticos y accesos;
• configurar un entorno seguro;
• desplegar con PostgreSQL;
• documentar instalación y uso;
• preparar datos y usuarios de demostración;
• presentar el proyecto como evidencia de portafolio;
• defender la autoría del código;
• implementar una solicitud de cambio controlada;
• documentar el uso profesional de IA;
• reconocer limitaciones y próximos pasos.

Conocimientos previos

Antes de comenzar debes tener aprobados los seis módulos anteriores y disponer de la versión candidata del sistema.

Debes poder:

• trabajar con Git y GitHub;
• crear y organizar aplicaciones Django;
• diseñar modelos y migraciones;
• utilizar Forms, ModelForms y formsets;
• implementar autenticación y permisos;
• construir servicios y selectores;
• utilizar transacciones;
• optimizar consultas del ORM;
• escribir pruebas automáticas;
• generar reportes;
• configurar PostgreSQL;
• desplegar una aplicación;
• proteger variables y secretos.

Este módulo no está diseñado para comenzar el sistema desde cero. Si tu versión del Módulo 6 todavía tiene observaciones críticas, corrígelas antes de continuar.

Competencias finales

Podrás comprender un proceso empresarial, identificar actores, reglas, datos y excepciones.

Podrás transformar requisitos en una aplicación Django funcional y organizada.

Podrás diseñar relaciones, conservar integridad y consultar información útil para la empresa.

Podrás comprobar procesos críticos mediante pruebas, revisión de seguridad y criterios de aceptación.

Podrás publicar, documentar, demostrar y modificar una aplicación frente a una revisión técnica.

Podrás utilizar IA para acelerar tareas sin entregar código que no comprendes ni exponer información sensible.

Resultado obligatorio

Construirás COA Gestión Empresarial Web, un sistema para administrar las operaciones principales de una pequeña empresa comercial.

El sistema integrará:

Usuarios y permisos
        ↓
Clientes y proveedores
        ↓
Productos e inventario
        ↓
Ventas transaccionales
        ↓
Panel e indicadores
        ↓
Reportes y exportaciones
        ↓
Administración, pruebas y despliegue

Puedes adaptar el nombre comercial, los colores y los datos ficticios. No puedes eliminar módulos funcionales obligatorios ni reemplazar el dominio empresarial por otro proyecto sin autorización.

Distribución recomendada del tiempo

La estimación parte del proyecto aprobado del Módulo 6. Los tiempos de espera del proveedor y las correcciones posteriores a la revisión no cuentan como trabajo activo del módulo.

Metodología de trabajo

No intentes completar todo y revisarlo al final.

Fase 1 → requisitos aprobados
Fase 2 → modelo coherente
Fase 3 → flujo crítico aprobado
Fase 4 → funciones completas
Fase 5 → pruebas y seguridad
Fase 6 → despliegue final
Fase 7 → documentación
Fase 8 → cambio solicitado
Fase 9 → demostración y defensa

Cada fase produce evidencia. Si el flujo crítico falla, no continúes agregando reportes o detalles visuales.

Caso empresarial

Una pequeña empresa comercial administra clientes, proveedores, productos, inventario y ventas. Actualmente utiliza hojas de cálculo separadas. Esto provoca:

• existencias inconsistentes;
• ventas sin historial completo;
• dificultad para conocer productos disponibles;
• acceso de empleados a funciones que no necesitan;
• reportes preparados manualmente;
• datos duplicados;
• poca trazabilidad cuando se corrige una operación.

Una aplicación web que centralice la operación y permita:

• controlar el acceso por rol;
• administrar catálogos;
• registrar movimientos;
• confirmar ventas sin inventario negativo;
• cancelar operaciones de forma controlada;
• consultar indicadores;
• generar reportes;
• conservar evidencia de operaciones importantes.

No agregues como requisitos obligatorios:

• pagos reales;
• facturación electrónica;
• integración bancaria;
• tienda pública;
• API REST;
• aplicación móvil;
• microservicios;
• WebSockets;
• Celery;
• Docker avanzado;
• contabilidad completa;
• cálculo fiscal de un país;
• múltiples sucursales;
• múltiples monedas;
• inteligencia empresarial avanzada.

Estas funciones necesitan requisitos, seguridad y tiempo propios. Agregarlas sin profundidad reduce la calidad del proyecto principal.

Actores del sistema

Implementa cuatro roles mediante grupos y permisos de Django.

Puede:

• administrar usuarios, grupos y permisos;
• acceder al panel administrativo;
• consultar todos los módulos;
• realizar operaciones de configuración;
• revisar registros importantes.

No debe utilizarse como cuenta cotidiana para registrar ventas.

Puede:

• consultar clientes, proveedores, productos y ventas;
• consultar paneles e indicadores;
• generar reportes;
• autorizar descuentos dentro de la política definida;
• cancelar ventas cuando la regla lo permita.

No administra permisos globales salvo que se defina expresamente.

Puede:

• consultar productos disponibles;
• crear y consultar clientes;
• registrar ventas;
• consultar sus operaciones;
• descargar los comprobantes permitidos.

No puede ajustar inventario, administrar usuarios ni consultar información gerencial restringida.

Puede:

• administrar proveedores;
• administrar categorías y productos;
• registrar entradas y ajustes autorizados;
• consultar movimientos y existencias.

No puede confirmar ventas ni administrar usuarios.

Puedes endurecer la matriz. No puedes otorgar más acceso sin justificarlo.

Documento de requisitos

Antes de programar, crea docs/requisitos.md.

Cada requisito debe contener:

Identificador:
Nombre:
Actor:
Descripción:
Precondiciones:
Flujo principal:
Excepciones:
Resultado esperado:
Criterios de aceptación:
Pruebas relacionadas:

Ejemplo:

Identificador: RF-VEN-01
Nombre: Confirmar una venta
Actor: Ventas
Descripción: Registrar una venta con uno o más productos disponibles.
Precondiciones: Usuario autenticado, permiso vigente y cliente activo.
Flujo principal:
1. Seleccionar cliente.
2. Agregar productos y cantidades.
3. Validar existencias.
4. Calcular subtotales y total.
5. Confirmar la operación.
6. Actualizar el inventario.
Excepciones:
- Cliente inactivo.
- Producto inactivo.
- Cantidad no positiva.
- Existencias insuficientes.
Resultado esperado: Venta confirmada y movimientos registrados.
Criterios de aceptación:
- No existe inventario negativo.
- La venta y sus detalles se guardan completamente.
- Un error no deja cambios parciales.
Pruebas relacionadas: test_confirmar_venta, test_rollback_stock_insuficiente.

Requisitos funcionales obligatorios

El sistema debe incluir:

• usuario personalizado definido desde el inicio del proyecto;
• inicio y cierre de sesión;
• recuperación de contraseña;
• perfil de usuario;
• grupos y permisos;
• rutas protegidas;
• páginas 403, 404 y 500;
• registro de operaciones importantes.

La recuperación debe utilizar el flujo seguro de Django. En desarrollo puede enviar el enlace a la consola. En una demostración pública solo se presenta como funcional si existe un servicio de correo correctamente configurado.

Debe permitir:

• crear clientes;
• buscar por nombre o identificador empresarial ficticio;
• consultar detalle;
• modificar información;
• activar o desactivar;
• consultar historial de compras;
• impedir una nueva venta a un cliente inactivo;
• conservar las ventas anteriores aunque el cliente se desactive.

Los documentos adjuntos son opcionales. Si se habilitan, requieren almacenamiento privado persistente y autorización por objeto.

Debe permitir:

• crear proveedores;
• consultar y buscar;
• modificar;
• activar o desactivar;
• asociar productos;
• registrar información de contacto ficticia;
• conservar referencias históricas.

Debe permitir:

• administrar categorías;
• crear productos con código único;
• registrar nombre, descripción, precio, existencias y cantidad mínima;
• cargar una imagen cuando exista almacenamiento persistente;
• activar o desactivar;
• buscar y filtrar;
• mostrar alerta de stock bajo;
• evitar que un producto inactivo se agregue a una nueva venta.

Debe permitir:

• registrar entradas;
• registrar salidas justificadas;
• registrar ajustes positivos o negativos controlados;
• asociar cada movimiento con usuario, fecha, tipo y motivo;
• consultar historial por producto;
• impedir existencias negativas;
• mantener vínculo con la venta cuando el movimiento fue automático.

No permitas editar directamente el stock sin crear un movimiento.

Debe permitir:

• seleccionar un cliente activo;
• agregar uno o más productos activos;
• indicar cantidades positivas;
• conservar el precio aplicado a cada detalle;
• calcular subtotal y total en el servidor;
• aplicar un descuento opcional controlado;
• validar existencias;
• confirmar en una transacción;
• disminuir inventario una sola vez;
• consultar detalle;
• cancelar de forma controlada;
• devolver inventario una sola vez al cancelar;
• impedir editar arbitrariamente una venta confirmada.

Debe mostrar:

• ventas recientes;
• total vendido en el periodo;
• productos con stock bajo;
• productos más vendidos;
• clientes frecuentes;
• indicadores filtrados por fecha;
• periodo y moneda visibles;
• estado vacío cuando no hay datos.

Debe incluir:

• reporte de ventas;
• reporte de inventario;
• reporte de movimientos;
• reporte de clientes;
• filtros válidos;
• exportación CSV;
• exportación Excel;
• autorización por reporte;
• protección contra fórmulas en texto exportado.

El panel administrativo debe incluir:

• modelos necesarios;
• columnas útiles;
• búsqueda;
• filtros;
• ordenamiento;
• acciones administrativas seguras;
• acceso restringido.

El admin complementa el sistema. No sustituye la interfaz empresarial principal.

Reglas empresariales obligatorias

Documenta estas reglas con identificadores y crea pruebas para las críticas.

Define una política concreta. Ejemplo:

Ventas puede aplicar de 0 % a 5 %.
Gerencia puede aplicar de 0 % a 15 %.
Un valor superior se rechaza.
El descuento se calcula en el servidor.

Si utilizas otra política, documéntala y pruébala.

BORRADOR → todavía no afecta inventario
CONFIRMADA → afecta inventario y reportes
CANCELADA → conserva historial y revierte inventario una vez

Define transiciones permitidas. No cambies estados mediante un campo libre.

Requisitos no funcionales

• permisos aplicados en servidor;
• protección CSRF;
• contraseñas gestionadas por Django;
• secretos fuera del repositorio;
• DEBUG=False en público;
• mensajes sin información interna;
• validación de archivos;
• logs sin datos sensibles.

• navegación consistente;
• formularios con etiquetas y errores;
• confirmaciones para acciones delicadas;
• estados vacíos;
• mensajes de éxito y error;
• interfaz responsive;
• contraste y foco visibles.

• listas paginadas;
• ausencia de N+1 en pantallas principales;
• rangos de reporte limitados;
• consultas agregadas en la base;
• índices justificados.

• aplicaciones por responsabilidad;
• vistas delgadas;
• servicios para reglas críticas;
• selectores reutilizables;
• nombres claros;
• migraciones versionadas;
• pruebas organizadas.

• dependencias registradas;
• variables documentadas;
• instalación reproducible;
• SQLite para desarrollo permitido;
• PostgreSQL para despliegue final.

Modelo de datos mínimo

El diagrama final debe reflejar tu implementación. Esta estructura es una guía, no un archivo para copiar sin revisar.

Usuario ──────── Perfil
   │
   ├──────────── Venta ─────────── Cliente
   │                │
   │                └──────────── DetalleVenta ───── Producto
   │
   └──────────── MovimientoInventario ──────────────┘

Proveedor ────── ProductoProveedor ───── Producto

Categoría ─────< Producto

Usuario y perfil

• identificador;
• nombre de usuario o correo;
• datos de perfil no sensibles;
• estado;
• grupos y permisos.

Cliente

• identificador;
• nombre;
• documento ficticio opcional;
• correo;
• teléfono;
• dirección;
• estado;
• fechas de auditoría.

Proveedor

• identificador;
• nombre;
• contacto;
• correo;
• teléfono;
• estado.

Categoría

• identificador;
• nombre único;
• estado.

Producto

• identificador;
• código único;
• categoría;
• nombre;
• descripción;
• precio;
• stock;
• stock mínimo;
• imagen opcional;
• estado.

Relación producto-proveedor

Si un producto puede tener varios proveedores, utiliza una relación explícita cuando necesites guardar datos adicionales, como código del proveedor o costo de referencia.

Venta

• identificador;
• cliente;
• vendedor;
• fecha;
• estado;
• subtotal;
• descuento;
• total;
• fecha de cancelación;
• usuario que canceló;
• motivo de cancelación.

Detalle de venta

• venta;
• producto;
• cantidad;
• precio unitario histórico;
• subtotal.

Movimiento de inventario

• producto;
• tipo;
• cantidad;
• existencia anterior;
• existencia posterior;
• fecha;
• usuario;
• motivo;
• venta relacionada cuando corresponda.

Registro de operación

Puede representar eventos importantes sin almacenar secretos:

• actor;
• acción;
• entidad;
• identificador del objeto;
• fecha;
• contexto mínimo permitido.

No guardes contraseñas, tokens, cookies ni formularios completos.

Integridad y decisiones de datos

Cada regla importante debe ubicarse conscientemente.

No uses señales para esconder el flujo principal de ventas. Una operación empresarial explícita es más fácil de comprender, probar y mantener.

Trazabilidad

Crea docs/trazabilidad.md:

La trazabilidad permite responder:

¿Dónde se implementó este requisito?
¿Qué prueba lo verifica?
¿Qué evidencia demuestra el resultado?

No necesitas registrar cada línea. Concéntrate en los requisitos y reglas críticos.

Definition of Done

Una función solo está terminada cuando:

• cumple el requisito;
• respeta permisos;
• valida entradas;
• conserva datos consistentes;
• maneja errores esperados;
• tiene pruebas proporcionales al riesgo;
• funciona en interfaz responsive;
• no genera consultas evitables;
• está documentada cuando lo necesita;
• fue confirmada en Git;
• puede explicarse.

“La pantalla abre” no significa “la función está terminada”.

Preparación del repositorio final

Crea una rama de trabajo final:

git switch -c proyecto-final

Antes de cambiar código:

1. ejecuta todas las pruebas;
2. registra el resultado inicial;
3. crea una etiqueta de la versión candidata;
4. revisa observaciones pendientes;
5. crea una lista priorizada.

git tag -a v0.9.0 -m "Versión candidata aprobada"

No uses una etiqueta si todavía no puedes identificar con claridad la versión que representa.

Organiza el trabajo:

CRÍTICO  → seguridad, datos, transacciones, despliegue
ALTO     → requisito obligatorio incompleto
MEDIO    → experiencia o documentación importante
BAJO     → mejora visual sin impacto funcional

Resuelve primero los riesgos, no los detalles más entretenidos.

Fase 1: análisis y alcance

Describe cómo trabaja la empresa ficticia antes del sistema:

¿Quién registra una venta?
¿De dónde obtiene el stock?
¿Quién puede corregir una operación?
¿Cómo se conoce el total vendido?
¿Qué ocurre cuando una venta se cancela?

Evita una descripción genérica como “la empresa necesita modernizarse”.

Ejemplo:

La empresa mantiene ventas e inventario en archivos separados.
Una venta puede registrarse sin actualizar existencias y no existe
una forma confiable de identificar quién corrigió una cantidad.

El proyecto tendrá éxito si:

• ninguna venta confirmada deja inventario negativo;
• cada rol ve únicamente funciones permitidas;
• una cancelación conserva historial y devuelve stock una vez;
• gerencia obtiene indicadores sin cálculos manuales;
• otra persona instala el sistema con el README;
• las reglas críticas tienen pruebas;
• la aplicación funciona desplegada.

Formato:

Como [rol]
quiero [capacidad]
para [beneficio].

Ejemplo:

Como responsable de inventario
quiero consultar los movimientos de un producto
para explicar por qué cambió su existencia.

Cada historia debe tener criterios observables:

Dado un producto con existencia 10
cuando se confirma una venta de 3 unidades
entonces la existencia final es 7
y existe un movimiento asociado con la venta.

Crea tres listas:

No muevas un elemento a “obligatorio” durante la construcción sin ajustar tiempo y riesgo.

Fase 2: arquitectura y datos

Una organización posible:

config/        → configuración global
usuarios/      → usuario, perfil y acceso
clientes/      → clientes e historial
proveedores/   → proveedores
productos/     → categorías y productos
inventario/    → movimientos y existencias
ventas/        → ventas, detalles y transacciones
reportes/      → panel, consultas y exportadores
core/          → inicio, errores y utilidades verdaderamente compartidas

No crees una aplicación utils para depositar código sin dueño. Una función compartida debe tener un propósito estable.

URL
 ↓
Vista protegida
 ↓
Formulario / formset
 ↓
Servicio transaccional
 ├── valida cliente
 ├── bloquea productos necesarios
 ├── valida existencias
 ├── crea venta y detalles
 ├── registra movimientos
 └── confirma todo
 ↓
Redirección al detalle

Antes de modificar modelos, comprueba:

• cardinalidades;
• obligatoriedad de relaciones;
• comportamiento de on_delete;
• unicidad;
• restricciones;
• datos históricos;
• campos derivados;
• estados;
• auditoría;
• índices.

No elimines un modelo con datos sin revisar las migraciones y el impacto.

Incluye una vista sencilla:

Navegador
   ↓
Django URLs y Views
   ↓
Forms ─ Services ─ Selectors
   ↓
Models y ORM
   ↓
PostgreSQL

Archivos estáticos → WhiteNoise
Imágenes públicas → almacenamiento persistente

Fase 3: integración funcional

Cuando el flujo crítico esté aprobado, completa el resto mediante recorridos verticales.

Requisito
   ↓
Modelo y regla
   ↓
Formulario
   ↓
Vista y permiso
   ↓
Template
   ↓
Prueba
   ↓
Evidencia

No construyas todos los modelos, luego todas las vistas y finalmente todas las pruebas. Completar un recorrido permite detectar antes los problemas de diseño.

Comprueba:

• alta válida;
• duplicado o identificador inválido;
• búsqueda;
• edición;
• desactivación;
• historial;
• bloqueo de nueva venta si está inactivo;
• acceso según rol.

Comprueba:

• creación;
• asociación;
• código único;
• precio válido;
• estado;
• filtros;
• imagen alternativa;
• permisos.

Comprueba:

• entrada;
• salida permitida;
• salida mayor al stock rechazada;
• ajuste con motivo;
• historial;
• actor registrado;
• inexistencia de edición directa insegura.

Comprueba:

• cliente y productos válidos;
• formset con al menos una línea;
• cantidades positivas;
• descuento según rol;
• total del servidor;
• transacción;
• detalle histórico;
• cancelación controlada;
• doble cancelación rechazada.

Comprueba:

• filtros;
• estados;
• totales conocidos;
• periodo visible;
• listas optimizadas;
• CSV;
• Excel;
• fórmulas neutralizadas;
• permisos.

Conexión con toda la Ruta Python

El proyecto debe mostrar conocimientos anteriores de forma natural.

• descomposición del proceso de venta;
• condiciones de estados;
• manejo de excepciones;
• prueba de casos límite.

• funciones;
• clases;
• colecciones;
• excepciones;
• módulos;
• programación orientada a objetos.

• fechas;
• manejo de archivos;
• pathlib;
• CSV;
• OpenPyXL;
• funciones integradas.

• arquitectura por responsabilidades;
• servicios;
• validaciones;
• código reutilizable;
• automatización;
• documentación.

• claves;
• relaciones;
• integridad;
• filtros;
• agregaciones;
• transacciones;
• índices;
• interpretación de consultas.

• MVT;
• ORM;
• formularios;
• autenticación;
• permisos;
• templates;
• pruebas;
• despliegue.

No agregues una tecnología solo para mencionarla. Cada herramienta debe resolver una necesidad del proyecto.

Automatizaciones útiles

El proyecto debe incluir al menos un comando propio de Django.

python manage.py cargar_demo

Debe:

• crear grupos y permisos;
• crear usuarios ficticios cuando no existan;
• crear catálogos y operaciones de demostración;
• evitar duplicaciones al repetirse;
• no imprimir contraseñas;
• negarse a ejecutarse accidentalmente en producción o exigir confirmación explícita.

Una estrategia segura:

from django.conf import settings
from django.core.management.base import BaseCommand, CommandError


class Command(BaseCommand):
    help = "Carga datos ficticios para demostración"

    def add_arguments(self, parser):
        parser.add_argument("--permitir-produccion", action="store_true")

    def handle(self, *args, **options):
        if not settings.DEBUG and not options["permitir_produccion"]:
            raise CommandError(
                "Operación detenida fuera de desarrollo."
            )

        self.stdout.write("Carga de demostración iniciada")

El indicador no vuelve segura cualquier carga. Revisa qué crea, actualiza o elimina el comando.

• exportación de reporte;
• carga controlada de catálogos ficticios;
• verificación de configuración;
• limpieza de archivos temporales no referenciados.

No agregues tareas programadas o infraestructura avanzada si el proyecto no la necesita.

Plan maestro de pruebas

Crea docs/plan_pruebas.md.

Incluye al menos 30 pruebas automáticas relevantes:

No dividas una comprobación trivial en muchas pruebas para alcanzar la cifra.

• stock insuficiente;
• rollback;
• doble confirmación o doble cancelación;
• cliente inactivo;
• producto inactivo;
• descuento fuera del límite;
• acceso anónimo;
• acceso sin permiso;
• URL directa;
• reporte sin datos;
• periodo inválido;
• CSV con texto que comienza con =;
• comando repetido sin duplicar;
• cancelación excluida de ingresos.

Además de automatizar, intenta:

• volver atrás después de enviar un formulario;
• enviar dos veces;
• abrir dos sesiones con roles diferentes;
• modificar identificadores en la URL;
• usar valores límite;
• eliminar una fila del formset y agregar otra;
• descargar un reporte vacío;
• navegar con pantalla pequeña;
• usar solo teclado en un flujo principal;
• abrir una ruta inexistente.

Registra hallazgos, correcciones y pruebas de regresión.

Revisión de seguridad

• El acceso utiliza el sistema de Django.
• La contraseña no se guarda ni registra manualmente.
• El logout requiere el método apropiado.
• La recuperación no revela si una cuenta existe más de lo necesario.

• Cada URL sensible valida permisos.
• Los objetos consultados pertenecen al alcance permitido.
• El admin está restringido.
• Ocultar botones no es la única protección.

• Los formularios validan datos.
• Los identificadores se consultan de forma segura.
• Los archivos tienen tipo y tamaño controlados.
• Los filtros tienen límites.
• Los cálculos no confían en valores del navegador.

• No hay secretos en Git.
• DEBUG=False en público.
• HTTPS funciona.
• Cookies seguras están activas.
• ALLOWED_HOSTS es específico.
• check --deploy fue revisado.

• Los datos de demostración son ficticios.
• Los logs no contienen credenciales.
• Las exportaciones respetan permisos.
• Los documentos privados no tienen URL pública permanente.
• Se explica la política de respaldo del entorno.

Revisión de experiencia de usuario

• el menú cambia según permisos;
• la página actual se identifica;
• existe una salida clara de cada formulario;
• no hay enlaces rotos.

• cada campo tiene etiqueta;
• los errores aparecen cerca del campo;
• los datos válidos se conservan tras un error;
• las acciones destructivas se confirman;
• el botón evita ambigüedad: “Confirmar venta”, no “Aceptar”.

• encabezados claros;
• filtros visibles;
• paginación;
• estado vacío;
• acciones consistentes;
• adaptación a móvil.

• HTML semántico;
• foco visible;
• navegación por teclado;
• contraste legible;
• texto alternativo para imágenes informativas;
• mensajes que no dependen solo del color;
• iconos acompañados por texto o etiqueta accesible.

No afirmes que el sistema es completamente accesible si no realizaste una auditoría formal. Documenta que aplicaste comprobaciones básicas.

Revisión de rendimiento

Selecciona al menos cuatro pantallas:

1. lista de productos;
2. lista de ventas;
3. detalle de venta;
4. panel empresarial.

Para cada una registra:

Comprueba:

• select_related() para relaciones directas usadas;
• prefetch_related() para colecciones;
• agregaciones en base de datos;
• paginación;
• índices alineados con filtros;
• ausencia de consultas dentro de ciclos del template.

No necesitas realizar pruebas de carga avanzadas. Debes demostrar que sabes detectar y corregir problemas evidentes.

Despliegue final

La aplicación final debe utilizar:

• Django 5.2 LTS;
• PostgreSQL;
• servidor de producción;
• HTTPS;
• variables de entorno;
• archivos estáticos preparados;
• estrategia persistente de multimedia;
• migraciones aplicadas;
• ruta de salud;
• logs de aplicación.

Pruebas locales
      ↓
Revisión de migraciones
      ↓
Revisión de secretos
      ↓
Commit y etiqueta
      ↓
Construcción
      ↓
Migraciones
      ↓
Inicio del servicio
      ↓
Pruebas de humo

Después del despliegue comprueba:

• página principal;
• login y logout;
• acceso de cada rol;
• lista de productos;
• creación de cliente;
• venta de demostración;
• detalle y movimiento;
• panel;
• CSV y Excel;
• 403 y 404;
• persistencia tras un nuevo despliegue.

Cuando la versión revisada sea estable:

git tag -a v1.0.0 -m "Proyecto Final COA"
git push origin v1.0.0

No etiquetes como v1.0.0 una versión que todavía contiene una condición crítica conocida.

Datos y cuentas de demostración

Los datos deben contar una historia coherente.

Incluye como mínimo:

• 4 roles;
• 4 usuarios de demostración;
• 12 clientes;
• 5 proveedores;
• 5 categorías;
• 25 productos;
• 40 movimientos;
• 20 ventas en fechas y estados diferentes;
• productos con stock normal, bajo y agotado;
• clientes activos e inactivos.

Entrega credenciales de demostración mediante el canal autorizado por COA, no como contraseñas permanentes en un repositorio público.

Las cuentas deben:

• usar contraseñas únicas para la demostración;
• no compartir credenciales reales;
• tener permisos limitados;
• poder rotarse;
• excluir acceso innecesario al admin.

Utiliza nombres, correos, teléfonos, direcciones e identificadores completamente ficticios. No copies una base real para “hacer el proyecto más creíble”.

Documentación profesional

Debe incluir:

1. nombre y propósito;
2. problema resuelto;
3. funciones principales;
4. tecnologías;
5. arquitectura;
6. capturas;
7. requisitos de instalación;
8. configuración;
9. migraciones;
10. datos de demostración;
11. pruebas;
12. despliegue;
13. roles;
14. seguridad;
15. limitaciones;
16. autoría y licencia si corresponde.

Otra persona debe poder:

clonar
crear entorno
instalar dependencias
configurar variables
migrar
cargar datos
crear administrador
ejecutar pruebas
iniciar el sistema

Organiza por tarea, no por archivo técnico:

• iniciar sesión;
• registrar cliente;
• registrar entrada;
• confirmar venta;
• cancelar venta;
• consultar panel;
• generar reporte;
• cerrar sesión.

Incluye permisos y advertencias en cada operación delicada.

Explica:

• mapa de aplicaciones;
• responsabilidades;
• flujo crítico;
• modelo de datos;
• servicios;
• selectores;
• decisiones de seguridad;
• estrategia de despliegue;
• limitaciones.

Crea CHANGELOG.md con al menos:

v1.0.0
- funciones entregadas;
- correcciones importantes;
- limitaciones conocidas.

Presentación de portafolio

El proyecto debe poder comprenderse sin abrir primero el código.

Redacta entre 150 y 250 palabras:

Problema
Solución
Responsabilidad personal
Decisión técnica importante
Reto resuelto
Resultado

No escribas solamente una lista de tecnologías.

• login;
• panel por rol;
• clientes;
• proveedores;
• productos;
• movimiento de inventario;
• creación de venta;
• detalle de venta;
• reporte filtrado;
• Excel o CSV;
• admin configurado;
• aplicación publicada.

No muestres secretos, correos reales ni paneles del proveedor con credenciales.

Duración recomendada: 6 a 8 minutos.

0:00 Problema y objetivo
0:45 Roles
1:30 Cliente y producto
2:15 Entrada de inventario
3:00 Venta completa
4:30 Panel y reporte
5:30 Pruebas y arquitectura
6:30 Despliegue y limitaciones

Demuestra un flujo, no todas las pantallas.

Solicitud de cambio del instructor

Después de la entrega inicial recibirás una modificación pequeña y limitada. Su objetivo es comprobar que entiendes la arquitectura y puedes cambiarla sin romper lo existente.

• agregar filtro de categoría al reporte de inventario;
• limitar descuento por grupo;
• mostrar motivo de cancelación;
• agregar un campo empresarial validado;
• cambiar un permiso;
• incluir una columna en CSV y Excel;
• agregar un indicador al panel;
• impedir una transición de estado;
• crear una prueba de regresión;
• modificar el comando de datos de demostración.

1. Repite el requisito con tus palabras.
2. Identifica archivos afectados.
3. Explica el riesgo.
4. Escribe o ajusta la prueba.
5. Implementa el cambio mínimo.
6. Ejecuta la batería completa.
7. Confirma en un commit separado.
8. Actualiza documentación.

docs/cambio_instructor.md

Debe contener:

• solicitud recibida;
• análisis;
• archivos modificados;
• prueba añadida;
• resultado;
• commit;
• evidencia visual cuando aplique.

No se evaluará la velocidad aislada. Se evaluará comprensión, control del impacto y calidad.

Defensa de autoría

La defensa confirma que el proyecto representa tu aprendizaje.

Debes poder explicar:

URL → vista → formulario o selector → servicio o modelo → template/respuesta

• una consulta con filtro;
• una agregación;
• una optimización de relaciones;
• el motivo de un índice.

• una regla de formulario;
• una regla del servicio;
• una restricción de datos.

• autenticación;
• permiso por URL;
• protección de secretos;
• separación de roles.

• qué operaciones agrupa;
• qué ocurre ante un error;
• cómo se evita una venta parcial;
• cómo se prueba.

• preparación;
• acción;
• resultado esperado;
• razón empresarial.

• dónde la utilizaste;
• qué propuesta rechazaste o modificaste;
• cómo validaste el resultado;
• qué información evitaste compartir.

Si no puedes explicar un fragmento, deberás estudiarlo, corregirlo o retirarlo.

Errores comunes

Se incorporan pagos, API o notificaciones mientras la venta principal todavía puede dejar datos inconsistentes.

Corrección: congela alcance y resuelve primero condiciones críticas.

El documento termina describiendo lo que casualmente se construyó.

Corrección: define comportamiento y criterios antes de cerrar la implementación.

El menú se oculta, pero la URL sigue disponible.

Corrección: grupos, permisos en servidor y pruebas directas.

Una edición simple destruye trazabilidad.

Corrección: toda variación ocurre mediante un movimiento con responsable y motivo.

Una venta antigua cambia cuando cambia el precio actual del producto.

Corrección: conserva el precio aplicado en DetalleVenta.

El inventario permanece descontado o se devuelve dos veces.

Corrección: servicio transaccional, transición válida y pruebas de idempotencia.

Se pierde el historial que explica ventas y movimientos.

Corrección: estados, protección de relaciones y política documentada.

Una corrección rompe otra regla sin ser detectada.

Corrección: automatiza procesos críticos y conserva pruebas exploratorias.

Existen muchas pruebas que no comprueban riesgos empresariales.

Corrección: conecta cada caso crítico con requisito y regla.

No puedes demostrar totales conocidos ni errores límite.

Corrección: crea un escenario de demostración intencional.

Una cuenta administrativa queda expuesta.

Corrección: entrega credenciales temporales por el canal autorizado y limita permisos.

Una corrección improvisada rompe la versión revisada.

Corrección: implementa el cambio en una rama, prueba y despliega de forma controlada.

El proyecto gana capas y dependencias que no puedes explicar.

Corrección: solicita cambios pequeños, compara con el diseño y elimina lo innecesario.

La audiencia no entiende qué problema resolviste.

Corrección: explica problema, flujo, decisión, evidencia y resultado.

La demo no tiene contrato de respaldo, soporte, privacidad ni disponibilidad.

Corrección: presenta limitaciones y requisitos para una operación real.

Recomendaciones del instructor

1. Demuestra primero la venta completa. Es el proceso que conecta más conocimientos de la ruta.
2. Usa números que puedas verificar a mano. Un reporte convincente parte de datos conocidos.
3. Mantén commits pequeños y descriptivos. Facilitan la solicitud de cambio y la defensa.
4. Crea una prueba de regresión por cada error importante. La corrección no debe depender de memoria.
5. Ensaya con cada rol. Una sesión de administrador puede ocultar fallos de permisos.
6. Prueba una instalación limpia antes de entregar. Tu computadora puede tener dependencias no documentadas.
7. No cambies la versión desplegada minutos antes de la revisión. Etiqueta y conserva una versión estable.
8. Explica las limitaciones con seguridad. Reconocer el alcance demuestra criterio profesional.
9. Si una propuesta de IA parece demasiado extensa, divídela. Integra solo lo que puedas probar y explicar.
10. Prioriza la confiabilidad sobre la cantidad de funciones. Un sistema pequeño y correcto es mejor evidencia que uno enorme e inestable.

Videos recomendados

Estos videos sirven como repaso para organizar y presentar el proyecto. La documentación oficial es la referencia técnica para Django 5.2.

Canal: Jorge Ruiz Tema: estructura y criterios de historias de usuario 📖Ver video en YouTube

Utilízalo para redactar necesidades desde el punto de vista del rol. No sustituye los criterios de aceptación.

Canal: May Code Tema: entidades, atributos, relaciones y cardinalidad 📖Ver video en YouTube

Contrasta el diagrama con tus modelos y migraciones reales.

Canal: Catch Exception Canal Tema: selección de casos de prueba útiles 📖Ver video en YouTube

El recurso explica conceptos generales. Implementa los casos con las herramientas de pruebas de Django aprendidas en el Módulo 6.

Canal: Código para Principiantes Tema: separar secretos y configuración 📖Ver video en YouTube

Úsalo como repaso. La configuración final debe seguir la documentación de Django 5.2 y del proveedor actual.

Canal: XAVII07 Tema: recorrido de publicación 📖Ver video en YouTube

La interfaz, los paquetes y las condiciones del plan pueden cambiar. Verifica cada paso con la guía oficial.

Canal: MATHS AND CODES Tema: creación y escritura de archivos Excel con Python 📖Ver video en YouTube

En el proyecto reutilizarás estos fundamentos dentro de una respuesta protegida de Django.

Documentación oficial y recursos confiables

• 📖Documentación de Django 5.2
• 📖Modelos
• 📖Restricciones de modelos
• 📖Consultas del ORM
• 📖Agregaciones
• 📖Optimización de base de datos
• 📖Transacciones
• 📖Formularios
• 📖Formsets
• 📖Autenticación
• 📖Permisos
• 📖Vistas de autenticación
• 📖Panel administrativo
• 📖Comandos propios
• 📖Pruebas
• 📖Seguridad
• 📖Checklist de despliegue

• 📖Restricciones en PostgreSQL
• 📖Control de concurrencia
• 📖Transacciones

• 📖Acerca de los README
• 📖Acerca de las versiones de GitHub
• 📖Sintaxis básica de Markdown

• 📖Desplegar Django en Render
• 📖Servicios web de Render
• 📖PostgreSQL en Render
• 📖Limitaciones de recursos gratuitos
• 📖WhiteNoise para Django

• 📖OWASP Top 10
• 📖Introducción a la accesibilidad web — W3C
• 📖Lista rápida de accesibilidad — W3C

• 📖diagrams.net — diagramas de arquitectura y flujo.
• 📖dbdiagram.io — diagrama relacional.
• 📖GitHub — repositorio y versiones.
• 📖Render — demostración desplegada según disponibilidad del plan.

Material complementario

Este módulo no necesita un PDF que repita la página. Utiliza plantillas editables.

ID:
Nombre:
Actor:
Descripción:
Precondiciones:
Flujo principal:
Excepciones:
Resultado:
Criterios de aceptación:
Pruebas:

Decisión:
Contexto:
Opciones:
Opción elegida:
Razón:
Consecuencias:
Prueba o evidencia:

Identificador:
Severidad:
Pasos para reproducir:
Resultado actual:
Resultado esperado:
Causa:
Corrección:
Prueba de regresión:
Commit:

Solicitud:
Comprensión del requisito:
Impacto:
Archivos afectados:
Riesgos:
Prueba añadida:
Implementación:
Resultado:
Commit:

[ ] versión etiquetada
[ ] aplicación disponible
[ ] usuarios de prueba válidos
[ ] datos preparados
[ ] flujo ensayado
[ ] reportes descargables
[ ] pruebas ejecutadas
[ ] secretos fuera de pantalla
[ ] limitaciones preparadas
[ ] repositorio accesible

Glosario

Actor: persona o rol que interactúa con el sistema.

Alcance: conjunto explícito de funciones incluidas y excluidas.

Criterio de aceptación: condición observable que determina si un requisito está cumplido.

Defensa de autoría: demostración de que comprendes y puedes modificar el proyecto entregado.

Definition of Done: condiciones que debe cumplir una función antes de considerarse terminada.

Dato histórico: valor que debe conservarse para interpretar una operación pasada.

Idempotencia: propiedad por la que repetir una operación controlada no duplica su efecto.

Integridad: garantía de que los datos respetan reglas y relaciones.

Matriz de permisos: mapa de funciones disponibles para cada rol.

Migración de datos: cambio versionado que transforma datos existentes además del esquema.

Prueba de humo: recorrido breve que confirma las funciones esenciales después de publicar.

Requisito funcional: comportamiento que el sistema debe ofrecer.

Requisito no funcional: condición de calidad, seguridad, rendimiento u operación.

Regla empresarial: restricción o decisión propia del proceso de la organización.

Regresión: error que reaparece o función que se rompe después de un cambio.

Release: versión identificada y preparada para entrega.

Rollback: reversión de todos los cambios de una transacción fallida.

Solicitud de cambio: modificación controlada realizada después de una versión inicial.

Trazabilidad: vínculo entre requisito, regla, implementación, prueba y evidencia.

Versión estable: versión que cumple criterios conocidos y no contiene fallos críticos abiertos.

Resumen final

En este módulo integraste toda la Ruta Python en un producto empresarial completo.

Demostraste:

• análisis lógico;
• dominio de Python;
• programación orientada a objetos;
• arquitectura de software;
• diseño relacional;
• SQL y ORM;
• desarrollo web con Django;
• autenticación y permisos;
• transacciones;
• automatización de archivos;
• pruebas;
• seguridad;
• documentación;
• Git;
• despliegue;
• uso responsable de IA.

El resultado no es solamente una colección de pantallas:

Necesidad empresarial
        ↓
Requisitos y reglas
        ↓
Datos y arquitectura
        ↓
Aplicación funcional
        ↓
Pruebas y seguridad
        ↓
Despliegue y documentación
        ↓
Defensa y cambio profesional

Checklist final del estudiante

• El problema está definido.
• El alcance está congelado.
• Las historias tienen criterios.
• Las veinte reglas están implementadas o justificadas.
• Existe trazabilidad.

• Los cuatro roles funcionan.
• Clientes y proveedores están completos.
• Productos e inventario conservan historial.
• La venta es transaccional.
• La cancelación devuelve stock una vez.
• Panel y reportes concuerdan.
• Admin está configurado y protegido.

• Existen al menos 30 pruebas relevantes.
• El flujo crítico está aprobado.
• Las migraciones funcionan desde cero.
• La carga demo no duplica.
• No existe N+1 evidente.
• Los errores tienen respuesta segura.

• No hay secretos.
• Los permisos se validan en servidor.
• No hay datos reales.
• La configuración pública usa DEBUG=False.
• Las exportaciones están protegidas.
• La multimedia tiene estrategia correcta.

• PostgreSQL está conectado.
• HTTPS funciona.
• Static funciona.
• La ruta de salud responde.
• Los datos sobreviven un despliegue.
• Las pruebas de humo terminan correctamente.

• README completo.
• Manual de instalación probado.
• Manual de usuario.
• Diagramas actualizados.
• Plan de pruebas.
• Limitaciones conocidas.
• Bitácora de IA.

• ZIP con nombre correcto.
• Enlaces accesibles.
• Credenciales entregadas de forma segura.
• Etiqueta v1.0.0 correcta.
• Cambio del instructor implementado.
• Guion ensayado.
• Puedes explicar el código crítico.

Cierre de la Ruta Python

Al aprobar el proyecto final habrás completado la formación técnica de la Ruta Python de COA.

El siguiente paso es el Programa de Experiencia Profesional COA, donde aplicarás estas competencias en proyectos reales para empresas y emprendimientos.

Curso completado
      ↓
Proyecto final aprobado
      ↓
Correcciones terminadas
      ↓
Defensa aprobada
      ↓
Preparación para Experiencia Profesional COA

Lleva al programa:

• disciplina para analizar antes de programar;
• capacidad para leer código existente;
• respeto por datos y permisos;
• hábito de probar;
• comunicación clara;
• uso responsable de IA;
• disposición para recibir y aplicar retroalimentación.

La meta final de la ruta no era memorizar Python ni Django. Era aprender a convertir problemas reales en software confiable que puedas comprender, mantener y mejorar.