Scrum (agilidad e incrementos):

• Ciclo de trabajo: organizado en sprints semanales, con entrega continua de "incrementos potenciales". El profesor enfatizó que pasar de "Hola Mundo" a "Hola Mundo Juan" NO constituye un incremento potencial.
• Artefactos requeridos: ficha de inicio, visión del producto, product backlog, historias de usuario con criterios de aceptación, sprint backlog.
• Historias de usuario (ejemplos): H1 — Registrar vehículo (prioridad alta); H2 — Consultar espacios disponibles (prioridad alta); H5 — Calcular costo de estancia. Se organizan en tableros por prioridad (alta/media/baja).
• Seguimiento y Git: reuniones diarias enfocadas en verificar objetivos; bitácora de experimentos para registrar impedimentos (falta de licencias, problemas de configuración, límites de RAM). El progreso se audita en Git, exigiendo mínimo dos modificaciones semanales.

Cascada (enfoque tradicional):

• Definición inicial: todo el alcance y requerimientos quedan documentados formalmente desde el principio; no se permiten cambios arbitrarios durante el desarrollo (ej. cambiar un modelo de red neuronal por un chatbot a medio proyecto).
• Etapas secuenciales: definición de solución → desarrollo → pruebas → implementación.
• Documentación exigida: planteamiento del problema, objetivos, alcances, estudio de factibilidad (o estudio del estado del arte si no hay datos financieros), especificaciones RF/RNF, diagramas de casos de uso, diseño del sistema y bases de datos, plan y casos de prueba, acta de control de cambios.
• Revisiones del semestre: inicial (acuerdo de alcance) · intermedia (verificación de avance real y control formal) · final.

• RF (Requerimientos Funcionales): definen comportamientos directos del sistema. Ej.: "RF1: El sistema deberá registrar la entrada de un vehículo"; "RF2: El sistema deberá registrar la salida de un vehículo".
• RNF (Requerimientos No Funcionales): miden calidad o restricciones operativas. Ej.: "RNF1: El sistema deberá responder en un tiempo máximo definido".

• Entorno virtualizado: obligatorio 2 a 3 VMs por proyecto (o hardware dedicado equivalente, ej. Raspberry Pi, si se justifica).
• Sistemas operativos permitidos: Ubuntu Server o Windows Server como base.
• Cruce de SO: servidor Windows Server exige cliente Linux; servidor Ubuntu Server exige cliente Windows.
• Ejes de evaluación: configuración de red, gestión de servicios, seguridad, evidencias de funcionamiento.

1. Intranet empresarial: servidor DNS y dominio interno; Apache con virtual hosts; HTTPS (SSL/TLS); documentación de direccionamiento IP y archivos de configuración.
2. Servidor de correo electrónico empresarial: DNS con dominio corporativo (ej. juanito@empresa.com); protocolos SMTP, POP3, IMAP; creación de usuarios, autenticación, cifrado TLS/SSL.
3. Servidor de acceso remoto seguro: SSH con llaves criptográficas; administración de usuarios/grupos/permisos; SFTP; políticas de seguridad.
4. Servidor de archivos empresariales: Samba y NFS; grupos por departamento (administración, ventas, sistemas, público) con permisos de lectura/escritura/ejecución. Restricción: toda la administración por línea de comandos, sin interfaz gráfica.
5. Servidor web con base de datos: frontend/backend con PHP, Java o Python; base de datos relacional o no relacional (SQL Server prohibido por licencias); DNS e HTTPS (nada de localhost:8080); CRUD completo.
6. Servidor web con balanceo de cargas: arquitectura distribuida, proxy de balanceo apuntando a Web 1 y Web 2; publicación con DNS; pruebas de disponibilidad con servidor espejo (alta disponibilidad ante fallas).
7. Infraestructura de servicios para una escuela: integración de DHCP, DNS, sitio web informativo y servidor de archivos Samba.
8. Servidor web con HTTPS y seguridad: red virtual, certificados SSL/TLS migrando de HTTP a HTTPS, modelos de autenticación (plus por implementar 2FA).
9. Servidor de archivos y acceso remoto multiplataforma: Samba + NFS + SSH + SFTP con permisos por departamento, interoperable entre Windows y Linux.
10. Servidor proxy y control de accesos: proxy con reglas de filtrado, autenticación, triggers para bitácoras de auditoría de seguridad (usuario, fecha, hora, acciones, tiempo conectado).

• (Contexto) El profesor recordó que en la primera clase preguntó "¿quién viene por el 6?" y todos dijeron que venían a aprender; advirtió que no quiere que a fin de semestre anden buscándolo para pedir puntos.
• (Contexto) En tono de broma dijo que los alumnos le caen mal y él a ellos, "tenemos un trato"; ante una petición de cambiar la integración de un equipo respondió "quiero cambiarlos de alumnos, pero eso no se puede".
• (Contexto) Anécdota: comiendo una torta en el laboratorio de bases de datos le tomaron una foto que terminó convertida en sticker.
• (Contexto) Contó que solo una vez hizo exponer a un grupo y fue "la cosa más triste que me tocó ver en esta facultad", por eso prefiere evaluaciones prácticas individuales.
• (Contexto) Ironizó sobre pretextos clásicos de entrega ("le juro que afuera sí estaba jalando y ahorita que entré ya no jaló", el patrón de "ya casi acabo" durante meses); sobre el video de 15 min sugirió "en lo posible se echen un baño y salgan ahí si es posible".

• Modalidad individual: quien decida hacer el proyecto solo, tiene como límite la próxima clase para notificarlo, con los mismos requerimientos de entrega que un equipo completo.
• Cambio de tema de proyecto: equipos que quieran cambiar su tema asignado (excepto el Equipo 3) tienen hasta el viernes para enviar propuesta justificada por Classroom (2 a 3 VMs). Sin propuesta el viernes, se confirma el tema asignado.
• Próxima sesión: lunes, según calendario oficial — estar pendientes de Classroom por avisos de modificación de calendario o paros.
• Material publicado: presentación en PDF y formatos/guías de apoyo para los proyectos, subidos a Classroom.