Saber Pro Diseño de Software study plan
Saber Pro Diseño de Software · Give each week a clear focus.
8 weeks · About 6 hours per week
Diseño de Software (módulo específico del programa; no enumerado en la fuente)
Definir con precisión qué evalúa el módulo de Diseño de Software y listar los conceptos que aparecen con más frecuencia (requisitos, arquitectura, UML, patrones, pruebas, calidad).
Diagnosticar el punto de partida resolviendo un conjunto de 20 preguntas tipo Saber Pro y clasificar cada error por causa (desconocimiento, mala lectura, confusión conceptual).
Construir un glosario personal de 25 términos técnicos en inglés y español (p. ej. coupling, cohesion, requirement, traceability, refactoring).
Establecer un calendario de estudio de 8 semanas con bloques fijos de 6 horas semanales y registrar el avance en una hoja de cálculo.
Your checkpoint
Un documento de diagnóstico de 3 páginas con el resultado del test inicial (puntaje y errores clasificados), el glosario de 25 términos y el calendario de estudio.
Diseño de Software (módulo específico del programa; no enumerado en la fuente)
Explicar el ciclo de vida del software y diferenciar modelos predictivos (cascada, incremental) de adaptativos (iterativo, ágil) con criterios de selección.
Redactar requisitos funcionales y no funcionales verificables a partir de un caso de estudio propio, evitando ambigüedades.
Aplicar técnicas de elicitación (entrevista, observación, cuestionario) y documentar cómo se priorizan los requisitos.
Distinguir alcance, stakeholders y restricciones en un enunciado de problema dado.
Your checkpoint
Una especificación de requisitos de 2 a 3 páginas para un sistema ficticio (por ejemplo, gestión de préstamos de biblioteca) con al menos 10 requisitos funcionales y 5 no funcionales medibles.
Diseño de Software (módulo específico del programa; no enumerado en la fuente)
Modelar casos de uso con actores, escenarios principal y alternativos, y relaciones include y extend correctamente justificadas.
Traducir requisitos a un diagrama de clases preliminar identificando clases, atributos, métodos y relaciones con multiplicidad.
Diferenciar asociación, agregación, composición y generalización y justificar cada elección en el modelo.
Revisar la consistencia entre casos de uso y diagrama de clases detectando requisitos sin cubrir.
Your checkpoint
Un paquete de modelado UML (diagrama de casos de uso y diagrama de clases) acompañado de una tabla de trazabilidad requisito-caso de uso-clase.
Diseño de Software (módulo específico del programa; no enumerado en la fuente)
Comparar estilos arquitectónicos (capas, cliente-servidor, microservicios, event-driven, MVC) y elegir uno justificando atributos de calidad.
Aplicar el principio de separación de responsabilidades y evaluar cohesión y acoplamiento en un diseño dado.
Describir el rol de las interfaces y la inversión de dependencias en la mantenibilidad del sistema.
Identificar riesgos arquitectónicos y proponer mitigaciones en un escenario con restricciones de tiempo y presupuesto.
Your checkpoint
Un documento de decisión arquitectónica (ADR) de 2 páginas que elija un estilo para el caso de estudio, con al menos tres alternativas comparadas y una tabla de atributos de calidad.
Diseño de Software (módulo específico del programa; no enumerado en la fuente)
Clasificar los patrones de diseño creacionales, estructurales y de comportamiento y reconocer el problema que resuelve cada uno.
Seleccionar y justificar patrones (por ejemplo, Strategy, Observer, Factory Method, Adapter, Repository) para problemas concretos del caso de estudio.
Implementar en pseudocódigo o en un lenguaje de su elección al menos dos patrones aplicados al diseño propio.
Detectar anti-patrones (God Class, acoplamiento excesivo, duplicación) en un diseño y proponer refactorizaciones.
Your checkpoint
Un catálogo de 8 patrones con su problema, estructura y ejemplo de aplicación, más dos implementaciones funcionales o en pseudocódigo comentado.
Diseño de Software (módulo específico del programa; no enumerado en la fuente)
Diseñar un plan de pruebas que cubra pruebas unitarias, de integración y de aceptación, relacionándolas con los requisitos.
Escribir casos de prueba con entradas, condiciones y resultados esperados, incluyendo valores límite y casos negativos.
Explicar métricas de calidad (cobertura, defectos por módulo, deuda técnica) y cómo interpretarlas sin sobrevalorarlas.
Aplicar una revisión por pares o inspección a un artefacto de diseño propio siguiendo una lista de verificación.
Your checkpoint
Un plan de pruebas de 2 páginas con al menos 12 casos de prueba y el informe de una revisión por pares con hallazgos y acciones correctivas.
Diseño de Software (módulo específico del programa; no enumerado en la fuente)
Resolver 40 preguntas tipo Saber Pro cronometradas, registrando tiempo por pregunta y tasa de acierto por subárea.
Analizar cada respuesta incorrecta y escribir la justificación correcta en una o dos frases, identificando el concepto faltante.
Practicar la lectura de enunciados largos extrayendo la pregunta central, las restricciones y las palabras clave antes de mirar las opciones.
Reforzar los tres subáreas con menor acierto mediante repaso dirigido y ejercicios nuevos.
Your checkpoint
Un registro de errores con 40 entradas analizadas y una lista de los cinco conceptos más débiles con su plan de refuerzo.
Diseño de Software (módulo específico del programa; no enumerado en la fuente)
Simular un examen completo en condiciones reales de tiempo y sin material de apoyo, y comparar el resultado con el diagnóstico de la semana 1.
Consolidar una hoja de repaso de una página con definiciones, patrones, estilos arquitectónicos y criterios de calidad.
Revisar el registro de errores y verificar que cada concepto débil quedó resuelto con una explicación propia.
Definir una estrategia de manejo del tiempo y de descarte de opciones para el día del examen.
Your checkpoint
Un simulacro final con puntaje, la hoja de repaso de una página y una comparación numérica con el diagnóstico inicial que muestre la mejora.
Milestones
Week 2: Puede redactar cinco requisitos funcionales y tres no funcionales medibles para un caso nuevo en 20 minutos, sin ambigüedades.
Week 4: Puede justificar por escrito la elección de un estilo arquitectónico frente a dos alternativas usando atributos de calidad, y su modelo UML es internamente consistente.
Week 6: Puede asociar cada requisito del caso de estudio con al menos un caso de prueba y explicar la diferencia entre prueba unitaria, de integración y de aceptación.
Week 8: Alcanza al menos 75 % de acierto en el simulacro final cronometrado, con mejora de al menos 20 puntos porcentuales respecto al diagnóstico de la semana 1.