IIC2143 es uno de esos ramos que suena relajado hasta que llega la I1 y te das cuenta de que aprenderte las definiciones de memoria no te salva. Ingeniería de Software en la UC no te pide programar como en Programación Avanzada: te pide entender cómo se construye software de verdad, con requisitos, procesos, diagramas y decisiones de diseño. Y todo eso, si no lo ordenas, se te transforma en un mar de conceptos sueltos que en la prueba no sabes dónde encajar.

En esta guía te ordeno lo que realmente entra en la I1, con ejemplos y un plan concreto para las últimas semanas. La idea es que llegues entendiendo, no repitiendo. Si después quieres seguir profundizando con material por ramo, te dejo el hub de la Universidad Católica, donde vamos juntando las guías de cada curso.

Qué mide realmente la I1 de IIC2143

Lo primero que tienes que asumir es que esta prueba no premia al que más código sabe, sino al que razona mejor sobre el proceso de construir software. La I1 suele concentrarse en la primera mitad del curso: qué es la ingeniería de software, los modelos de proceso, la ingeniería de requisitos y las bases del modelado con UML. Son temas conceptuales, y ahí está la trampa: parecen fáciles de leer, pero cuesta aplicarlos.

La mayoría de las preguntas te van a pedir justificar decisiones. No basta con decir “usaría Scrum”; tienes que explicar por qué Scrum y no cascada para ese contexto. Estudia pensando en el “por qué” detrás de cada concepto y no solo en la definición, porque la prueba casi siempre te va a poner en un escenario y te va a pedir que decidas.

Procesos de software: de la cascada a lo ágil

Este es uno de los bloques más seguros de la I1. Tienes que manejar con claridad los modelos de proceso: cascada, incremental, iterativo y los enfoques ágiles como Scrum. De cada uno debes saber cómo funciona, cuáles son sus ventajas y, sobre todo, en qué contexto conviene usarlo.

La cascada es lineal y ordenada, pero se cae cuando los requisitos cambian. Los modelos iterativos e incrementales te permiten entregar de a poco y corregir en el camino. Scrum lleva eso al extremo con sprints, roles definidos (Product Owner, Scrum Master, equipo de desarrollo) y ceremonias como el daily y la retrospectiva. Un error clásico es aprenderte los nombres pero no entender para qué sirve cada rol o evento; si te preguntan por qué existe la retrospectiva y respondes bien, ganas puntos que muchos pierden. Ojo también con el modelo en espiral y el énfasis en el riesgo: aunque no lo uses en la práctica, es típico que te pidan compararlo con la cascada para ver si entiendes cuándo conviene un enfoque que gestiona la incertidumbre de forma explícita.

Ingeniería de requisitos: el corazón de la I1

Si hay un tema que casi nunca falta, es este. Tienes que distinguir con seguridad entre requisitos funcionales (qué debe hacer el sistema) y no funcionales (cómo debe comportarse: rendimiento, seguridad, usabilidad, escalabilidad). Es simple en teoría, pero en un caso concreto muchos confunden un requisito no funcional con uno funcional, y eso se penaliza.

También cae el proceso de levantar requisitos: elicitación, análisis, especificación y validación. Practica escribir historias de usuario con el formato “Como [rol], quiero [acción] para [beneficio]” y define criterios de aceptación claros. Y ten cuidado con la ambigüedad: un requisito como “el sistema debe ser rápido” es malo justamente porque no es medible. Si te muestran un requisito así y te piden mejorarlo, la respuesta es hacerlo específico y verificable: por ejemplo, “el sistema debe responder en menos de dos segundos para el 95% de las consultas”. Ese pequeño cambio transforma un deseo vago en algo que un equipo puede probar y validar, y demuestra que entendiste de qué se trata un buen requisito no funcional.

UML: los diagramas que sí caen

UML es donde la I1 se pone visual, y donde más se nota si estudiaste dibujando o solo leyendo. Los diagramas que aparecen con más frecuencia son el de casos de uso, el de clases y el de secuencia. Del de casos de uso debes manejar actores, casos, y las relaciones include y extend. Del de clases, las asociaciones, la multiplicidad, la herencia y la diferencia entre agregación y composición, que es un clásico para bajarte medio punto.

El diagrama de secuencia modela la interacción entre objetos en el tiempo, y suele preguntarse junto a un caso de uso para que muestres cómo se ejecuta el flujo. Mi recomendación concreta: no estudies UML solo leyendo, dibuja. Toma un enunciado simple (una app de pedidos, un sistema de biblioteca) y modélalo completo. En la prueba te van a pedir producir diagramas, no reconocerlos, así que la mano tiene que estar entrenada.

Diseño y buenas prácticas que no puedes ignorar

Dependiendo de cómo venga el semestre, la I1 puede tocar las bases del diseño de software. Aquí lo importante es entender dos ideas que se repiten en todo el ramo: alta cohesión y bajo acoplamiento. Un buen diseño agrupa lo que va junto y minimiza las dependencias entre módulos, porque eso hace el sistema más fácil de mantener y modificar.

Si alcanzan a ver principios SOLID o patrones de diseño, no intentes memorizar los cinco principios como una lista: entiende el problema que cada uno resuelve. Por ejemplo, el principio de responsabilidad única existe para que una clase no se transforme en un monstruo que hace de todo. Cuando entiendes el problema, la definición se te queda sola.

¿Quieres llegar a la I1 con todo ordenado y ejercicios resueltos? Armamos un curso de preparación específico para IIC2143 con resúmenes, diagramas de ejemplo y práctica guiada. Ver curso de preparación IIC2143 UC y estudia con material hecho a la medida del ramo.

Cómo organizar tu estudio para la I1

Con dos semanas por delante, parte armando un resumen propio de los modelos de proceso y las definiciones de requisitos: escribirlo con tus palabras vale mucho más que subrayar el PDF del profe. Dedica la primera semana a los conceptos (procesos y requisitos) y la segunda casi entera a UML y diseño, porque son las partes que se aprenden practicando.

Consigue interrogaciones de años anteriores y hazlas con tiempo, como si fuera la prueba real. Corrige después comparando tu razonamiento, no solo el resultado. Si puedes, estudia en grupo para el UML: que un compañero revise tus diagramas te muestra errores que solo no ves. Cronometra tus ensayos: en la I1 el tiempo se va volando cuando tienes que dibujar diagramas, así que conviene que llegues con velocidad de mano y no descubriendo recién en la prueba que un diagrama de secuencia te toma veinte minutos. Y llega descansado el día de la prueba; en un ramo tan conceptual, la mente fresca marca la diferencia entre confundir agregación con composición o no.

Preguntas frecuentes

¿Es difícil la I1 de IIC2143?
No es difícil por complejidad matemática, sino por volumen conceptual. Si estudias entendiendo el “por qué” de cada tema y practicas diagramas, es una prueba muy abordable.

¿Necesito saber programar para esta prueba?
No en el sentido de escribir código. La I1 mide tu capacidad de modelar, decidir procesos y especificar requisitos. Programar ayuda a entender el contexto, pero no es lo que se evalúa.

¿Qué es lo que más se pregunta?
Ingeniería de requisitos y UML son los temas más recurrentes. Distinguir requisitos funcionales de no funcionales y producir diagramas correctos te asegura buena parte del puntaje.

¿Cuánto tiempo debería dedicarle?
Con dos semanas de estudio ordenado alcanza de sobra, siempre que la segunda semana la dediques a practicar UML y casos concretos en vez de solo leer.

¿Sirve estudiar en grupo?
Sí, sobre todo para revisar diagramas y discutir decisiones de diseño. Explicarle un concepto a otro es la mejor forma de darte cuenta de si de verdad lo entendiste.