Antes de programar: análisis, arquitectura y decisiones tecnológicas

1 El proceso de desarrollo de software

Programar es una etapa del proceso, no el punto de partida. Una solución útil comienza entendiendo el problema y termina —siempre provisionalmente— cuando puede operar, medirse y evolucionar.

La flecha de regreso representa aprendizaje: usuarios, errores y métricas producen una nueva iteración.

Microactividad

Convierte “queremos un sistema moderno” en una descripción de problema que incluya usuario, situación y consecuencia. Después identifica qué dato necesitarías para comprobar que mejoró.

2 Sitio web, aplicación web, aplicación móvil y API

Estas piezas pueden coexistir, pero tienen propósitos y formas de interacción distintas.

Vocabulario para seguir el recorrido

Recorrido de una consulta

HTTP/1.1 200 OK
Content-Type: application/json

{"solicitudes":[{"id":42,"asunto":"Proyector","estado":"asignada"}]}

3 Cómo definir requisitos antes de programar

AulaDesk es el caso provisional: una institución necesita registrar solicitudes, asignarlas, dar seguimiento y notificar cambios.

De una frase vaga a una condición comprobable

Historia breve con aceptación

Como coordinador, quiero asignar una solicitud a un responsable para que exista una persona claramente encargada.

• Solo el rol coordinador puede asignar.
• El responsable debe estar activo y pertenecer al área correspondiente.
• La asignación registra responsable, autor y fecha.
• Si no hay responsables disponibles, se informa el problema sin perder datos.

4 Comparación de tecnologías

Primero distinguimos categorías. Un lenguaje expresa instrucciones; un framework organiza una aplicación e impone convenciones; una biblioteca aporta piezas que el programa llama; un entorno de ejecución ejecuta código.

Tres decisiones, tres contextos

5 Bases de datos

Persistencia significa que los datos sobreviven al cierre del programa. El modelo elegido debe representar el dominio y sus consultas importantes, no solo guardar “cosas”.

Criterios de selección

Modelo de datos, relaciones, transacciones, consultas, volumen, concurrencia, consistencia, respaldo, habilidades, alojamiento, costo, herramientas y migración futura. La pregunta correcta no es “¿cuál es mejor?”, sino “¿qué riesgo reduce y qué costo introduce en este contexto?”.

6 Herramientas de desarrollo local

Una herramienta se incorpora cuando resuelve una necesidad del flujo. Instalar todo desde el primer día no mejora automáticamente el proyecto.

Docker con una analogía precisa

Tres entornos, tres propósitos

7 Infraestructura y despliegue

La infraestructura sostiene la aplicación. Debe ser suficiente, recuperable y operable por el equipo, no simplemente “la más grande”.

Dirección y confianza en Internet

• Dominio: nombre legible, por ejemplo auladesk.institucion.mx.
• DNS: traduce el dominio hacia el servicio correcto mediante registros.
• HTTPS: cifra y autentica la comunicación HTTP mediante TLS.
• Certificado: vincula criptográficamente una identidad/dominio con una clave; debe renovarse.

Arquitectura simple y arquitectura compleja

Navegador
   ↓ HTTPS
Hosting PHP
   ├─ Aplicación
   └─ MySQL administrado
        ↳ respaldo diario

DNS + CDN + balanceador
          ↓
  varias instancias de app
      ↓          ↓
 base gestionada  cola/workers
 réplica/backup   archivos objeto

Costos fijos: dominio, plan base, soporte. Variables: cómputo por uso, transferencia, almacenamiento, mensajes, usuarios o llamadas a APIs. El costo total también incluye horas de administración.

8 Servicios adicionales y notificaciones

“Notificar” no es una sola función: cambia el canal, la autorización, el costo, la entrega y la experiencia.

Más integraciones posibles

Criterios: urgencia, audiencia, permiso, confirmación requerida, sensibilidad, frecuencia, conectividad, costo por evento, accesibilidad y capacidad de soporte.

9 Desarrollo de software asistido por IA

Codex puede acelerar el trabajo, pero no transforma una intención ambigua en una decisión correcta por arte de magia. La calidad del resultado depende del contexto, las restricciones y la verificación.

Prompt incorrecto

“Créame un sistema de inventarios completo.”

Faltan problema, usuarios, alcance, reglas, tecnología, seguridad, datos, criterio de éxito y entregables. “Completo” no es verificable.

Prompt técnico estructurado

Actúa como analista técnico. NO escribas código todavía.

Problema: una institución pierde solicitudes recibidas por mensajes dispersos.
Usuarios: solicitante, responsable y coordinador.
Requisitos iniciales: registrar, asignar, comentar, cambiar estado y consultar historial.
Restricciones: equipo principiante en PHP; hosting PHP 8.1 y MySQL existente;
presupuesto bajo; interfaz web responsiva; no app móvil en el MVP.
Tecnologías candidatas: PHP sin framework o Laravel; MySQL/MariaDB;
HTML del servidor con JavaScript puntual.
Criterios de aceptación: propón escenarios Given/When/Then para cada flujo crítico.
Pruebas: incluye permisos, validación, errores, integración y recorrido de usuario.
Entregables de esta fase: preguntas abiertas, alcance/MVP, 2 alternativas de
arquitectura con ventajas y riesgos, recomendación justificada, modelo conceptual,
plan por etapas y estimación con supuestos.

Primero: detecta ambigüedades y riesgos. Haz preguntas o declara supuestos.
Después presenta propuestas. Espera aprobación antes de generar código.

Revisión mínima de una contribución de IA

• ¿Resuelve el requisito y nada más?
• ¿Respeta convenciones y datos existentes?
• ¿Valida permisos en el servidor?
• ¿Maneja entradas, errores y secretos?
• ¿Las pruebas fallarían si la función se rompe?
• ¿Entiendo cada archivo modificado?
• ¿El costo operativo sigue siendo razonable?

10 Práctica de la clase

Producto: una propuesta técnica de 2–4 páginas o 5 diapositivas. Esta práctica consiste exclusivamente en diseñar y justificar la solución antes de programar. No se crea un CRUD, no se instala software y no se inicia un repositorio.

Se puede utilizar inteligencia artificial para investigar conceptos y comparar alternativas, pero cada elección debe explicarse con criterio propio, evidencia y supuestos visibles.

Escenarios de decisión

11 Primer contacto con el proyecto integrador

Durante el cuatrimestre se construirá gradualmente una aplicación web funcional con apoyo de IA. AulaDesk es una propuesta provisional que puede adaptarse cuando se defina el proyecto definitivo.

Ejemplo conceptual de organización documental

El siguiente árbol sirve como mapa del contenido que conviene documentar; no es una instrucción para crear carpetas o archivos en esta práctica.

auladesk/
├── README.md
└── docs/
    ├── 01-problema-y-objetivos.md
    ├── 02-requerimientos.md
    ├── 03-arquitectura.md
    ├── 04-decisiones-tecnicas.md
    └── 05-plan-de-pruebas.md

12 Cierre de la clase

Glosario esencial

Decisiones clave que debemos poder defender

1. Problema y usuarios antes que tecnología.
2. MVP y límites antes que lista infinita de funciones.
3. Arquitectura proporcional al riesgo y escala conocidos.
4. Tecnología compatible con equipo, presupuesto y operación.
5. Datos y permisos diseñados desde el inicio.
6. IA como colaborador revisado, no como autoridad.

Preguntas de comprobación

Criterios de evaluación de la práctica

Salida de clase: escribe una decisión técnica que ahora tomarías de manera diferente y la pregunta que harías antes de aceptarla.