Sesión 7: Proyecto Integrador

Entrega 1 — Lanzamiento, propuesta y primer commit

Unidad 1 · Aplicando algoritmos simples · TIA: Proyecto — Entrega 1 · 10%

Navegación: ← → | Home End | F pantalla completa · Mouse: botones · Touch: desliza

Plan de trabajo

0–10 · Cierre Unidad 1: qué tienen que saber aplicar en el proyecto.
10–20 · El Proyecto Integrador: 3 entregas, propósito y reglas generales.
20–35 · Modalidades A y B: diferencias, criterios y proceso de elección.
35–50 · Requisitos de la Entrega 1 y cómo se califica.
50–60 · GitHub: estructura del repositorio y primer commit.
60–105 · Trabajo en clase: equipo, propuesta, IPO, variables y primer commit.
105–115 · Socialización rápida: cada equipo presenta su idea (1 min).
115–120 · Cierre, fechas y canales de entrega.

Al finalizar esta sesión cada equipo debe tener: modalidad definida, propuesta aprobada, repositorio creado y al menos un commit con el README.

Una solución que crece con el curso

No es un ejercicio aislado. Cada entrega extiende la anterior con los nuevos conceptos de la unidad. En la Entrega 3 tienes el mismo problema resuelto de forma completa y modular.

Regla clave: en cada entrega partes del código de la anterior y lo amplías. No se empieza de cero en la Entrega 2 ni en la 3.

Modalidad A

Problema propuesto por el docente

El dominio y las reglas del problema ya están definidos. El equipo implementa la solución en C# siguiendo la especificación entregada.

Enfoque: implementación correcta y evidencia de comprensión.
Sin tiempo de diseño del problema — pueden arrancar a codificar antes.
Útil si el equipo no tiene un dominio claro en mente.

Modalidad B

Problema propuesto por el equipo

El equipo elige el dominio. Debe redactar una propuesta en clase y obtener aprobación del docente antes de terminar la sesión.

El problema debe requerir ≥ 3 condicionales y ≥ 3 tipos de datos.
Sin aprobación antes de las 8:50 PM → pasa automáticamente a Modalidad A.
La rúbrica es idéntica para A y B.

Equipos: máximo 2 integrantes. La sustentación (30%) es individual y se califica por separado — cada integrante debe poder defender todo el código.

Sistema de clasificación de pedidos

Una tienda en línea necesita un programa que, dados los datos de un pedido, determine su categoría de despacho y el costo de envío.

Entradas: monto del pedido (decimal), ciudad destino (string), tipo de cliente: "nuevo" / "recurrente" (string), cantidad de ítems (int).
Reglas a implementar:
- Envío gratis si monto ≥ $150.000 Y cliente recurrente.
- Envío express si ítems ≥ 5 O monto ≥ $300.000.
- Envío estándar en todos los demás casos.
- Costo adicional si ciudad destino es "exterior".
Salidas: categoría de despacho, costo de envío, mensaje al cliente.

Lo que esto exige

Mínimo 3 tipos: decimal, string, int.
Operadores: aritméticos, relacionales y lógicos (&&, ||).
≥ 3 condicionales anidadas o con condiciones compuestas.
Decisiones de diseño reales: ¿cuándo aplica cada regla? ¿en qué orden evalúas?

La complejidad no viene de la sintaxis, viene de que las reglas se cruzan. Un caso de prueba mal pensado lo evidenciará en la sustentación.

La propuesta debe incluir

Nombre del sistema y dominio (3 líneas máximo).
IPO esquemático: entradas (nombre + tipo), proceso en lenguaje natural, salidas con ejemplos.
Justificación de que requiere ≥ 3 condicionales y ≥ 3 tipos de datos distintos.
Al menos 2 reglas de negocio que generen condicionales compuestas.

Se redacta directamente en el README del repositorio. No hay formato especial; claridad y completitud es lo que se evalúa.

Ejemplos de dominio válido

Calculadora de tarifa de parqueadero (tipo vehículo, horas, día).
Clasificador de notas con estado académico y beca condicional.
Sistema de turnos de atención según tipo de usuario y prioridad.
Diagnóstico básico de dispositivo por síntomas ingresados.
Calculadora de descuentos de tienda (producto, cantidad, tipo de cliente).

Si la propuesta no tiene aprobación antes de terminar la sesión, el equipo trabaja con Modalidad A sin penalización.

Qué debe tener el código entregado

Criterio	Mínimo requerido	Nota
Lenguaje	C# consola (.NET SDK)	Sin frameworks ni librerías externas
Condicionales	≥ 3 estructuras if / else if / else	Con operadores lógicos && \|\|
Variables	≥ 3 tipos distintos, nombres en camelCase	Propósito claro; sin variables sin usar
Entrada	Console.ReadLine() con conversión explícita	TryParse recomendado (no obligatorio en E1)
Salida	Mensajes con contexto, no solo valores crudos	El usuario debe entender la respuesta
GitHub	Repositorio público + README + .gitignore	Enlace entregado en el LMS

Dado que solo tienen 2 días, el foco de la entrega es la propuesta sólida, las variables bien declaradas y al menos la lógica condicional principal funcionando.

Entrega en GitHub — 70%

Criterio	Peso
Variables y tipos bien declarados	20%
Condicionales funcionales y correctas	25%
Operadores usados con propósito	15%
README + propuesta + casos de prueba	20%
Commits individuales ≥ 5% del avance c/u	20%

Si solo un integrante tiene commits, ese criterio (20%) se pierde para el otro.

Sustentación oral — 30%

Se califica por separado e individualmente. Cada integrante defiende el código completo, no solo "su parte".

El docente da una entrada no documentada; el estudiante predice la salida y traza la lógica.
Se pide justificar por qué se eligió un tipo de dato específico.
Se puede pedir modificar una regla en vivo (ej. cambiar un umbral).

Si un integrante no puede sustentar, pierde su 30% aunque el código esté correcto. Ambos deben entender todo el proyecto.

Estructura del repositorio

/src Proyecto.cs README.md .gitignore ← incluye bin/ y obj/

Commits mínimos esperados

init: README con descripción del problema y equipo feat: declaración de variables y lectura de entradas feat: lógica condicional principal implementada fix: ajustes según casos de prueba

Cada integrante debe aparecer como autor en al menos 1 commit que represente ≥ 5% del avance real del proyecto.

README mínimo

Nombre del proyecto y equipo (ambos integrantes).
Descripción del problema (3–5 líneas).
IPO: tabla de entradas, proceso y salidas con ejemplos.
Variables: nombre, tipo y propósito de cada una.
Casos de prueba: mínimo 2 (normal + borde).
Instrucciones para compilar y ejecutar.

Entrega: enlace del repositorio en el LMS antes de las 23:59 del 03/03/2026. No se aceptan envíos por correo ni por chat.

Modelo IPO del proyecto

El IPO va en el README. Es el diseño antes del código.

Variables: tabla de diseño

Nombre	Tipo C#	Propósito
monto	decimal	Valor del pedido en pesos
ciudad	string	Destino del envío
cantItems	int	Número de ítems
tipoCliente	string	"nuevo" o "recurrente"
costoEnvio	decimal	Resultado calculado
categoria	string	Tipo de despacho asignado

Esta tabla va en el README. El docente la revisa para verificar que los tipos tienen sentido antes de ver el código.

Pasos guiados

Definir equipo y modalidad (5 min) — confirmar integrante, elegir A o B.
Propuesta (15 min) — si es B, redactar y obtener aprobación ahora.
Crear repositorio en GitHub (10 min) — nombre, .gitignore, README vacío, agregar colaborador.
Diseño en README (15 min) — escribir IPO y tabla de variables.
Primer commit (5 min) — init: README con propuesta y diseño IPO. Ambos verifican que ven el commit.
Arranque del código (15 min) — declarar variables, leer entradas, primer condicional funcional.
Segundo commit — feat: variables y lectura de entradas.

Regla de commits:

Ambos integrantes deben tener commits propios antes de terminar la sesión. Configuren Git con su usuario de GitHub en la máquina que usen.

No para la sesión:

No es necesario que el código esté 100% completo hoy.
La prioridad es: propuesta clara + IPO en README + primer commit.
El resto lo completan en los 2 días siguientes.

Cada equipo presenta en 1 minuto

Deben responder:

¿Qué problema resuelve su sistema?
¿Cuáles son sus entradas y de qué tipo?
¿Cuál es la regla condicional más compleja que van a implementar?

No es una sustentación. Es una verificación de que el enfoque es viable y el dominio es suficientemente rico.

El docente verifica:

Que el problema realmente requiere ≥ 3 condicionales.
Que los tipos de datos tienen sentido para el dominio.
Que ambos integrantes conocen el problema (no solo uno).
Que el repositorio tiene al menos 1 commit visible.

Si el docente detecta un problema con el enfoque, el equipo tiene hasta el cierre de la clase para ajustar. Después de eso, la propuesta queda bloqueada para la entrega.

Checklist antes de salir hoy

☐ Equipo definido (máx. 2 integrantes).
☐ Modalidad elegida (A o B aprobada).
☐ Repositorio creado, público, colaborador agregado.
☐ README con IPO y tabla de variables.
☐ Al menos 1 commit visible de cada integrante.
☐ Propuesta presentada en la socialización.

Fechas clave

Qué	Cuándo
Entrega 1 en LMS	03/03/2026 — 23:59
Sesión 8 — Prueba Unidad 1	05/03/2026
Inicio Unidad 2	12/03/2026
Entrega 2 (extiende E1)	07/04/2026
Entrega 3 + sustentación	19/05/2026

Navegación: ← → | Home End | F · Botones · Desliza