PQRS Console – Hoja de Ruta | Profe Diego · CEOGET
CEOGET · Python
Proyecto PQRS — Hoja de Ruta
Grupo: Atención al Ciudadano · 30 min
$ 0 – 10 min

¿Qué están construyendo?

// Contexto del problema → Los actores → Qué hace la app

💭 Para arrancar, piensen en esto
¿Alguna vez han ido a una entidad pública a poner una queja… y nunca supieron qué pasó con ella? ¿O a pedir algo que nunca llegó?
El problema real

Hoy, muchas Peticiones, Quejas, Reclamos y Sugerencias se manejan en papel, en correos sueltos o en formularios que nadie revisa. El ciudadano no sabe en qué estado está su solicitud. El funcionario no tiene control claro.

Su aplicación existe para resolver exactamente eso.

¿Qué significa PQRS?
  • Petición — Solicitar algo a la entidad
  • Queja — Expresar una inconformidad
  • Reclamo — Exigir el cumplimiento de un derecho
  • Sugerencia — Proponer una mejora

Cuando un ciudadano crea un ticket, elige cuál de los 4 tipos es.

¿Quiénes usan la app?
  • Ciudadano: la persona con un problema o idea. Crea tickets, los consulta, ve respuestas.
  • Funcionario: el empleado de la entidad. Revisa tickets, cambia estados, responde.

Cada rol tiene su propio menú. Lo que uno ve, el otro no.

Ciclo de vida de una PQRS

Un ticket no aparece y desaparece. Pasa por estados:

📥 Recibido → ⚙️ En trámite → 💬 Respondido → ✅ Cerrado

Pregunta: ¿quién puede cambiar el estado? ¿El ciudadano, el funcionario, o ambos?

✏️ Actividad X — hablen en equipo (3 min)
Sin abrir el computador: ¿cuáles son las 3 acciones mínimas que debe poder hacer un ciudadano? ¿Y las 3 acciones mínimas que debe poder hacer un funcionario?
No hay respuesta única. La decisión de qué incluir es del equipo.
$ 10 – 20 min

¿Cómo se organizan?

// Roles del equipo → Tablero Kanban → Primera distribución de trabajo

⚡ Regla de oro del equipo
Si todos hacen todo al mismo tiempo, nadie termina nada. Un proyecto de software se divide. Cada persona tiene una responsabilidad clara y una tarea concreta en cada momento.
Roles sugeridos del equipo
🧭
Líder / Coordinador
Gestiona el Kanban, revisa que el equipo avance y resuelve bloqueos.
🖥️
Dev Menús (UI)
Construye los 3 menús en consola: principal, ciudadano, funcionario.
⚙️
Dev Servicios
Implementa la lógica: crear tickets, listarlos, cambiar estado, autenticación.
🗃️
Datos + QA
Define y mantiene los JSON, prueba los flujos completos, redacta el README.

¿Son menos de 4 personas? Combinen roles. ¿Son más? Dividan las tareas de un mismo rol.

Tablero Kanban inicial del proyecto
Por hacer
🗂️ Crear estructura de carpetas
📄 Definir Usuarios.json
📄 Definir Tickets.json
🖥️ Menú principal
🖥️ Menú ciudadano
🖥️ Menú funcionario
🔐 Auth (login)
⚙️ Crear ticket
⚙️ Listar tickets
⚙️ Actualizar estado
📝 README.md
En progreso
Vacío al inicio.
¡Muevan tarjetas aquí
cuando las empiecen!
Hecho ✓
Aquí llega
el trabajo
terminado.

Herramienta sugerida: Trello, Notion, o una hoja en la pared. Lo que les funcione como equipo.

✏️ Actividad Y — decidan ahora (5 min)
¿Quién toma qué rol? Asignen un nombre a cada rol y decidan cuáles tarjetas del Kanban son responsabilidad de cada persona esta semana.
Pueden dividirlo diferente a los roles sugeridos — pero todos deben tener algo concreto que hacer.
$ 20 – 30 min

¿Por dónde empieza el código?

// Arquitectura → JSON → Flujo de datos → CRUD → Primera tarea

🗺️ Principio de arquitectura
El proyecto NO es un solo archivo enorme. Está dividido en capas. Cada capa tiene una responsabilidad. Nadie hace el trabajo de otro.
Estructura de carpetas en Spyder

Creen primero las carpetas y los archivos vacíos. No escriban código todavía.

# Tu carpeta raíz se llama: PQRS_Console/ │ ├── main.py # Punto de entrada │ ├── menus/ # Lo que ve el usuario │ ├── menu_principal.py │ ├── menu_ciudadano.py │ └── menu_funcionario.py │ ├── services/ # La lógica del negocio │ ├── auth_service.py │ └── ticket_service.py │ ├── utils/ # Herramientas reutilizables │ ├── file_manager.py │ └── validators.py │ ├── data/ # Archivos de persistencia │ ├── Usuarios.json │ └── Tickets.json │ └── README.md
¿Cómo se verán los datos en JSON?

Cada ticket es un objeto dentro de una lista. ¿Qué campos necesitan?

// Tickets.json — ejemplo de un ticket [ { "id": "T001", "tipo": "Q", // P / Q / R / S "asunto": "Hueco en la calle 45", "descripcion": "Lleva 2 meses sin reparar", "estado": "recibido", "respuesta": "", "id_ciudadano": "U001", "fecha_creacion":"2025-06-26" } ]

Pregunta: ¿para qué sirve el campo "id_ciudadano"?

El flujo de datos — cómo viaja una acción
Arranque
main.py
→
Presentación
menus/
→
Lógica
services/
→
Herramientas
utils/
→
Datos
data/

Cuando un ciudadano crea una PQRS: el menú pregunta los datos → llama al servicio → el servicio usa file_manager.py → el file_manager guarda en Tickets.json. Los datos persisten entre ejecuciones porque viven en el archivo, no en memoria.

CRUD aplicado al proyecto PQRS
Operación ¿Qué hace? Ejemplo concreto en su app ¿Quién lo hace?
CREATE Agregar un registro nuevo Ciudadano registra una PQRS nueva Ciudadano
READ Leer y mostrar registros Ver mis PQRS / Ver tickets pendientes Ciudadano + Funcionario
UPDATE Modificar un registro existente Funcionario cambia el estado y agrega respuesta Funcionario
DELETE Eliminar un registro Eliminar un ticket duplicado (funcionalidad avanzada) Admin (opcional)

Todo lo que hicieron en PSeInt —agregar, mostrar, modificar, borrar— es exactamente esto, ahora con nombres formales y sobre archivos JSON en vez de solo memoria.

✏️ Actividad Z — abran Spyder (5 min)
Creen la carpeta PQRS_Console/ con las subcarpetas y archivos vacíos de la estructura de arriba. Si terminan antes: escriban a mano en Tickets.json un ticket de ejemplo como el que vieron.
Meta: que todos puedan ver la misma estructura en su máquina antes de salir de aquí.
🙋
Espacio para preguntas

No hay preguntas malas. Si algo no quedó claro, este es el momento.

💭 Sobre el proyecto ¿Qué no entendieron del sistema PQRS? ¿Alguna funcionalidad les genera dudas?
👥 Sobre el equipo ¿Quedó claro quién hace qué? ¿Algún rol les parece demasiado difícil o demasiado fácil?
💻 Sobre el código ¿La estructura de carpetas quedó clara? ¿Saben cómo empezaría el main.py?
💡 Ideas adicionales ¿Quieren agregar algo al sistema? ¿Creen que hay funcionalidades importantes que no aparecen en la lista?
🚀
Para la próxima sesión, deben llegar con:
✅ Carpetas y archivos creados  ·  ✅ Tickets.json con un ejemplo manual  ·  ✅ Kanban montado (Trello, Notion o papel)  ·  ✅ Roles del equipo definidos y escritos  ·  ✅ main.py con el menú de 3 opciones funcionando
Temporizador
10:00
Bloque X
Scroll to Top