Sistemas Operativos

Sesión 7: Proyecto
Primera Entrega

Modalidades · Componentes · Rúbricas · GitHub · Actividad en clase

Hoy definen la modalidad de su proyecto, construyen la propuesta inicial y arrancan el repositorio. En 2 días hacen la primera entrega.

Navegación: ← → | Home End | F pantalla completa | Táctil: desliza

I.U. Pascual Bravo · Sistemas Operativos
Plan de la sesión

¿Qué haremos en 120 minutos?

  • 0–15 min — Contexto del proyecto incremental: qué son E1, E2 y E3, y qué se espera de cada una.
  • 15–35 min — Presentación de las dos modalidades y sus rúbricas finales.
  • 35–55 min — Rúbrica de la Entrega 1 y flujo de entrega con GitHub.
  • 55–100 min — Taller guiado: elección de modalidad, definición del problema y arranque del repositorio.
  • 100–120 min — Compromisos por equipo: qué tendrán listo en 2 días.

Resultado esperado al salir:

  • Modalidad elegida y pre-aprobada.
  • Repositorio GitHub creado con estructura básica.
  • Problema y alcance de E1 escritos.
  • Un compromiso concreto por integrante.
Unidad 1 · Actividad 3 · Tarea 2 · Indicadores D-I · F-I · G-I
Contexto del proyecto

Un proyecto en 3 incrementos, no uno gigante al final

ENTREGA 1 · Semana actual
  • Propuesta técnica.
  • Mock funcional / boceto.
  • Arranque del repositorio.
  • Algo básico que ya funciona.
  • Presentación en clase.
ENTREGA 2 · Unidad 2
  • Componentes de Unidad 1 completos.
  • Concurrencia real demostrable.
  • Sincronización implementada.
  • Integración con Unidad 2.
ENTREGA 3 · Final
  • Sistema completo e integrado.
  • Monitoreo de recursos.
  • Documentación final.
  • Sustentación oral (25 pts).

Regla de oro: un equipo que solo planea pero no tiene nada ejecutable tiene 0 en el criterio de Incremento, en cualquier entrega.

La sustentación individual con peso del 25% aplica a partir de la Entrega 2.
Modalidades del proyecto

Elige tu camino — ambas son equivalentes en exigencia

AspectoModalidad 1 — Proyecto BaseModalidad 2 — Proyecto Alternativo
Nombre Gestor de Procesos y Concurrencia Propuesto por el equipo
Lenguaje Libre (C#, Java, Python, C/C++, etc.) Libre (cualquiera que soporte los criterios)
Simulación de procesos Obligatoria (componente 1 de 5) No obligatoria
Concurrencia real Obligatoria Obligatoria
Sincronización Obligatoria (sección crítica + solución) Obligatoria
Interacción con el SO real Obligatoria (procesos reales) Obligatoria
Pre-aprobación No requiere, es el proyecto por defecto Requiere aprobación del docente HOY

Alternativo: si el equipo no recibe aprobación del docente al final del taller, trabajará con el Proyecto Base.

Ambas modalidades tienen la misma rúbrica de 100 pts y el mismo peso en el curso.
Modalidad 1 — Proyecto Base

Gestor de Procesos y Concurrencia

Una aplicación que integra progresivamente los conceptos de la asignatura:

1. Simulación académica (didáctica)
  • Modelado de procesos con estados y transiciones.
  • Algoritmo de planificación (ej. Round Robin).
  • Máquina de estados coherente con la teoría.
2. Procesos reales del SO
  • Listar, iniciar y finalizar procesos reales.
  • Obtener PID, memoria básica y estado.
5. Monitoreo de recursos
  • Uso de CPU, memoria o número de hilos.
  • Registro de actividad concurrente.
3. Concurrencia real
  • Múltiples hilos o tareas reales.
  • Procesamiento concurrente observable.
4. Sincronización
  • Demostrar una condición de carrera real.
  • Solucionarla: Mutex, Semáforo o lock (o equivalente).
  • Explicar conceptualmente la sección crítica.
Lenguaje libre: C#, Java, Python, C/C++, Rust, Go — lo que el equipo domine mejor.
Modalidad 1 — Rúbrica final (Entrega 3)

100 puntos totales

CriterioPtsQué se verifica
Simulación académica15Estados correctos, transiciones coherentes, algoritmo funcional, relación con teoría.
Procesos reales20Listado funcional, inicio/finalización, manejo adecuado de la API del SO.
Concurrencia15Hilos/tareas reales, diseño concurrente adecuado, evidencia observable.
Sincronización15Condición de carrera demostrada, mecanismo correcto, explicación conceptual.
Monitoreo de recursos10Datos reales obtenidos (CPU, memoria o hilos), presentación clara.
Sustentación y comprensión25Cada integrante demuestra dominio de proceso, hilo, sincronización y decisiones de diseño. Quien no pueda explicarlo no aprueba el componente.

La sustentación es individual. El proyecto puede ser grupal, pero cada persona debe poder explicar cualquier parte del código y justificar cada decisión de diseño.

Esta rúbrica se aplica en la Entrega 3. Las entregas 1 y 2 se evalúan por avance incremental esperado.
Modalidad 2 — Proyecto Alternativo

Criterios obligatorios para que sea aprobado

El proyecto DEBE:

  • Interactuar con el sistema operativo real.
  • Incluir procesos o hilos reales.
  • Implementar concurrencia observable (no secuencial encubierto).
  • Resolver un problema de sincronización verificable.
  • Demostrar uso/monitoreo de un recurso real.
El recurso puede ser: CPU, memoria, archivo compartido, base de datos, dispositivo de E/S, socket de red, servicio externo o hardware (ej. Arduino).

NO se acepta:

  • CRUD simple sin concurrencia real.
  • Aplicación puramente secuencial.
  • Sin sincronización real demostrable.
  • Simulación puramente teórica sin interacción con el SO.

Lenguaje: libre. Cualquiera que permita cumplir los criterios.

Aprobación: el docente debe dar visto bueno hoy en clase antes de que termine el taller.

Si el proyecto alternativo no es aprobado hoy, el equipo trabaja con el Proyecto Base.
Modalidad 2 — Ejemplos válidos

Ideas que cumplen los criterios

  • Servidor concurrente con control de sesiones.
  • Sistema de logs concurrentes con control de acceso a archivo.
  • Monitor de base de datos con acceso simultáneo desde múltiples hilos.
  • Sistema de impresión con cola y sincronización.
  • Control concurrente de sensores — Arduino u otro hardware.
  • Sistema de tareas en segundo plano con prioridades.
  • Analizador de procesos y consumo de memoria en tiempo real.
  • Mini-servidor web concurrente con límite de conexiones.
  • Chat o mensajería con hilos y paso de mensajes.
  • Pipeline de procesamiento de archivos concurrente.

Para proponer uno propio, el equipo debe responder estas 3 preguntas al docente:

  1. ¿Dónde están los hilos o procesos reales?
  2. ¿Cuál es el recurso compartido y cuál es la sección crítica?
  3. ¿Cómo se demuestra que la concurrencia es real y no secuencial?
Si responden estas 3 preguntas con claridad, el proyecto probablemente cumple los criterios.
Modalidad 2 — Rúbrica final (Entrega 3)

100 puntos totales

CriterioPtsQué se verifica
Aplicación real de conceptos de SO20Hilos/procesos reales, concurrencia observable, sincronización funcional, interacción con recursos.
Problema técnico resuelto15Problema no trivial, justificación técnica clara, no es un CRUD simple.
Sincronización15Sección crítica evidente, mecanismo correcto implementado, explicación conceptual.
Uso o monitoreo de recursos15Recurso real controlado (DB, archivo, puerto, CPU/memoria, socket), funcional.
Calidad técnica10Código estructurado, modularidad, buen uso del lenguaje elegido.
Sustentación conceptual25Cada integrante demuestra comprensión de proceso, hilo, concurrencia, sincronización y sección crítica. Quien no pueda explicarlo no aprueba el componente.

La rúbrica de Entrega 3 es la misma para ambas modalidades en cuanto a peso de sustentación: 25 pts individuales e irremplazables.

Esta rúbrica se aplica en la Entrega 3. Las entregas 1 y 2 son hitos de avance.
Entrega 1 — Esta semana (100 pts)

Rúbrica de la primera entrega — 2 días para hacerla

CriterioPtsQué se evalúa y qué se acepta
Propuesta técnica 30 Problema delimitado, alcance para las 3 entregas, arquitectura básica de módulos, decisión de lenguaje y modalidad justificada. No debe ser perfecta, debe ser clara.
Mock funcional / boceto 20 Flujo representado con mínimo 3 estados o pantallas visibles. Se acepta wireframe en papel fotografiado, Excalidraw o draw.io.
Incremento 1 — primer arranque 30 Repositorio GitHub creado con estructura de carpetas. Al menos un componente básico funciona y puede demostrarse. README con instrucciones mínimas de ejecución. No se exige que esté completo.
Presentación del equipo 20 Cada integrante participa y habla. Se entiende qué hace el proyecto, qué funciona hoy y cuál es el plan. 2–3 min por equipo.

Nota: la sustentación formal con peso del 25% aplica a partir de la Entrega 2. En E1 se evalúa la presentación grupal como hito de arranque.

Si el repositorio no existe o el README no tiene instrucciones de ejecución → 0 en el criterio Incremento 1.
Entrega via GitHub

Repositorio obligatorio desde la Entrega 1

Nombre del repositorio
SO-proyecto-equipoXX

Reemplaza XX por el número de equipo asignado en clase.

Estructura mínima de carpetas
SO-proyecto-equipoXX/ ├── README.md ← Obligatorio ├── propuesta/ │ └── propuesta-tecnica.pdf ├── mock/ │ └── (capturas, wireframe o video) └── src/ └── (código fuente)
README.md debe incluir:
  • Nombre del equipo e integrantes.
  • Nombre y modalidad del proyecto.
  • Descripción breve (3–5 líneas).
  • Lenguaje y dependencias.
  • Instrucciones de ejecución.
  • Qué funciona y qué no (por entrega).

Entrega al docente: compartir el link del repositorio en el aula virtual (Classroom) antes de la fecha límite.

El repositorio debe ser público o tener al docente como colaborador.

Cada entrega incremental (E2, E3) se entrega actualizando el mismo repositorio con commits claros.
GitHub — Buenas prácticas de trabajo en equipo

Cómo usar el repositorio durante el proyecto

Ramas recomendadas
  • main — versión estable de cada entrega (no se toca a diario).
  • develop — trabajo del día a día, integración continua.
  • feature/nombre — funcionalidades individuales (opcional).
Mensajes de commit útiles
git commit -m "feat: listado de procesos reales" git commit -m "fix: condición de carrera en buffer" git commit -m "docs: actualizar README con E1"

Errores comunes a evitar:

  • Subir solo en la última noche antes de la entrega (sin historial).
  • Un solo integrante hace todos los commits.
  • README vacío o con placeholder.
  • Repositorio privado sin agregar al docente.

El historial de commits es evidencia de trabajo. Un repositorio con commits de todos los integrantes y mensajes claros vale más que un zip entregado en el último momento.

No se requiere Git Flow completo — solo main + develop es suficiente para el alcance del proyecto.
Taller en clase (55–100 min)

Lo que deben construir ahora mismo

  1. Formar/confirmar equipo y asignar roles básicos: líder de integración, responsable de cada componente.
  2. Elegir modalidad (Base o Alternativo). Si es Alternativo, llamar al docente para pre-aprobación respondiendo las 3 preguntas de la diapositiva 8.
  3. Escribir el problema: 1 párrafo que defina QUÉ hace el sistema y PARA QUÉ sirve.
  4. Definir el alcance de E1: ¿qué componente específico estará listo en 2 días? ¿Qué criterio de aceptación tendrá?
  1. Dibujar el diagrama de módulos: bloques + flechas, 5–8 componentes, en papel o Excalidraw.
  2. Crear el repositorio en GitHub con el nombre correcto y la estructura de carpetas. Subir el README mínimo.
  3. Definir 1 compromiso por integrante para las próximas 48 horas: concreto, verificable, fechado.

Pregunta del docente durante la revisión: "¿Cuál es el componente mínimo verificable que tendrán listo en 2 días?" Si la respuesta es vaga, el equipo debe reducir el alcance.

El docente circula, valida y hace preguntas — no da respuestas, hace que el equipo las encuentre.
Cierre (100–120 min)

Presentación rápida — 2 minutos por equipo

Cada equipo debe decir:

  1. Nombre del proyecto y modalidad elegida.
  2. En 1 oración: qué problema resuelve.
  3. Lenguaje elegido y por qué.
  4. Qué componente tendrá listo para E1 (2 días).
  5. Link del repositorio GitHub (ya debe existir).
Si el repositorio no está creado al momento de hablar → el equipo pierde 5 pts de presentación.

Fecha de entrega E1: [Definir con el grupo]

Entregar el link del repositorio en Classroom antes de la fecha límite.

Recuerden: E1 no requiere el proyecto terminado. Requiere que algo funcione, que el diseño esté pensado y que el equipo haya arrancado.

La siguiente sesión comenzará con revisión rápida del estado de cada repositorio.