Agrega S5 — Modelos y métodos de desarrollo de software

prisma/content/courses/index.ts

@@ -16,10 +16,12 @@ import type { CoursePackageDefinition } from "../authoring";
 
 import { cppDesdeCero } from "./cpp-desde-cero";
 import { csharpPoo1 } from "./csharp-poo-1";
+import { modelosMetodosDesarrolloSoftware } from "./modelos-metodos-desarrollo-software";
 
 const packages = [
   cppDesdeCero,
   csharpPoo1,
+  modelosMetodosDesarrolloSoftware,
 ] satisfies readonly CoursePackageDefinition[];
 
 export const { allCourses, allPracticeSets } = buildContentRegistry(packages);

prisma/content/courses/modelos-metodos-desarrollo-software/index.ts

@@ -0,0 +1,52 @@
+import { defineCourse } from "../../authoring";
+
+import { mmProyectoCascada } from "./units/01-proyecto-cascada";
+import { mmRequerimientos } from "./units/02-requerimientos";
+import { mmUmlDiseno } from "./units/03-uml-diseno";
+import { mmGitVersiones } from "./units/04-git-versiones";
+import { mmPlanificacionImplementacion } from "./units/05-planificacion-implementacion";
+import { mmPruebasCalidad } from "./units/06-pruebas-calidad";
+import { mmMantenimiento } from "./units/07-mantenimiento";
+import { mmSolid } from "./units/08-solid";
+import { mmIncremental } from "./units/09-incremental";
+import { mmIntegrador } from "./units/10-integrador";
+
+// =====================================================================
+// Paquete de curso: Modelos y métodos de desarrollo de software.
+//
+// S5 (nueva materia): 10 unidades, una sola CurriculumSection semestral.
+// Lenguaje práctico C#, pero la identidad del Course es proceso/ingeniería
+// de desarrollo (cascada, requisitos, UML, Git, planificación, pruebas,
+// mantenimiento, SOLID, incrementos, proyecto integrador). Las 10 unidades
+// nacen `published: true` — no hay release gate para esta entrega.
+// =====================================================================
+
+export const modelosMetodosDesarrolloSoftware = defineCourse({
+  slug: "modelos-metodos-desarrollo-software",
+  title: "Modelos y métodos de desarrollo de software",
+  description:
+    "Convierte problemas en proyectos de software trazables: requisitos, diseño, control de versiones, pruebas, mantenimiento, SOLID y entregas incrementales.",
+  subjectName: "Modelos y métodos de desarrollo de software",
+  academicContext: "CETI · Tecnólogo en Desarrollo de Software",
+  language: "csharp",
+  executionProfile: "csharp-mono-6.12",
+  curriculum: [
+    {
+      key: "s5-modelos-metodos-desarrollo-software-1",
+      semester: 5,
+      subjectName: "Modelos y Métodos de Desarrollo de Software I",
+      units: [
+        mmProyectoCascada,
+        mmRequerimientos,
+        mmUmlDiseno,
+        mmGitVersiones,
+        mmPlanificacionImplementacion,
+        mmPruebasCalidad,
+        mmMantenimiento,
+        mmSolid,
+        mmIncremental,
+        mmIntegrador,
+      ],
+    },
+  ],
+});

prisma/content/courses/modelos-metodos-desarrollo-software/units/01-proyecto-cascada/index.ts

@@ -0,0 +1,16 @@
+import { defineUnit } from "../../../../authoring";
+
+import { leccion01 } from "./lessons/01-de-programa-a-proyecto";
+import { leccion02 } from "./lessons/02-fases-cascada";
+import { leccion03 } from "./lessons/03-ventajas-limites-cascada";
+import { leccion04 } from "./lessons/04-roles-y-entregables";
+
+export const mmProyectoCascada = defineUnit({
+  slug: "mm-01-proyecto-cascada",
+  title: "Del programa al proyecto: modelo en cascada",
+  description:
+    "Reconoce qué distingue un proyecto de software de un programa aislado y recorre las fases del modelo en cascada.",
+  icon: "🧭",
+  published: true,
+  lessons: [leccion01, leccion02, leccion03, leccion04],
+});

prisma/content/courses/modelos-metodos-desarrollo-software/units/01-proyecto-cascada/lessons/01-de-programa-a-proyecto.ts

@@ -0,0 +1,49 @@
+import { defineLesson } from "../../../../../authoring";
+
+export const leccion01 = defineLesson({
+  slug: "de-programa-a-proyecto",
+  title: "De programa aislado a proyecto de software",
+  description:
+    "Reconoce que un proyecto incluye problema, personas, decisiones, artefactos y evidencia, no sólo código.",
+  estimatedMinutes: 15,
+  xpReward: 45,
+  steps: [
+    {
+      type: "theory",
+      markdown: `Un programa puede resolver una operación puntual. Un **proyecto de software** intenta resolver un problema para personas concretas, durante un periodo, con restricciones y evidencia de que la solución cumple lo acordado.
+
+Antes de escribir código aparecen preguntas que el compilador no responde: quién usa el sistema, qué necesita, qué queda fuera, cómo sabremos que funciona y quién aprueba un cambio.
+
+Durante S5 usaremos un sistema de solicitudes de soporte. El código importa, pero también requisitos, modelos, commits, pruebas, cambios y entregables.`,
+    },
+    {
+      type: "matching",
+      pairs: [
+        { left: "Problema", right: "Situación observable que justifica construir algo" },
+        { left: "Requisito", right: "Condición que la solución debe satisfacer" },
+        { left: "Implementación", right: "Código/configuración que materializa el diseño" },
+        { left: "Evidencia", right: "Prueba o artefacto que verifica una afirmación" },
+      ],
+      explanation: "Proyecto conecta necesidad, decisión, construcción y evidencia.",
+    },
+    {
+      type: "quiz",
+      question:
+        "Hay 800 líneas de C#, pero nadie puede decir qué problema resuelven ni cómo aceptar la entrega. ¿Qué falta primero?",
+      options: ["Más clases", "Problema y requisitos verificables", "Optimización", "Otro lenguaje"],
+      correctIndex: 1,
+      explanation: "Más código no sustituye una definición verificable del objetivo.",
+    },
+    {
+      type: "fill_blank",
+      prompt: "Completa los espacios.",
+      template: "Problema → {{0}} → diseño → implementación → {{1}}",
+      blanks: [
+        { answer: "requisitos", hint: "Expresan qué debe cumplirse." },
+        { answer: "evidencia", hint: "Permite comprobarlo." },
+      ],
+      explanation:
+        "La trazabilidad mínima conecta por qué existe una pieza y cómo se demuestra.",
+    },
+  ],
+});

prisma/content/courses/modelos-metodos-desarrollo-software/units/01-proyecto-cascada/lessons/02-fases-cascada.ts

@@ -0,0 +1,54 @@
+import { defineLesson } from "../../../../../authoring";
+
+export const leccion02 = defineLesson({
+  slug: "fases-cascada",
+  title: "Fases y ciclo de vida en cascada",
+  description: "Ordena las fases y explica qué evidencia produce cada una.",
+  estimatedMinutes: 15,
+  xpReward: 45,
+  steps: [
+    {
+      type: "theory",
+      markdown: `En cascada las fases avanzan con dependencia fuerte: requisitos, diseño, implementación, verificación, entrega y mantenimiento.
+
+El valor no está en dibujar flechas hacia abajo, sino en hacer explícitos los **criterios de salida**. Si requisitos termina ambiguo, el diseño hereda ambigüedad; programar más rápido sólo acelera el error.`,
+    },
+    {
+      type: "code_completion",
+      prompt: "Ordena los elementos.",
+      lines: [
+        "Requisitos",
+        "Diseño",
+        "Implementación",
+        "Verificación",
+        "Entrega",
+        "Mantenimiento",
+      ],
+      explanation:
+        "Cada fase usa resultados de la anterior y deja una salida comprobable.",
+    },
+    {
+      type: "quiz",
+      question: "¿Cuál es la mejor condición para cerrar requisitos?",
+      options: [
+        "Ya pasaron dos semanas",
+        "El equipo empezó a programar",
+        "Los requisitos están revisados y tienen criterios verificables",
+        "Existe un repo Git",
+      ],
+      correctIndex: 2,
+      explanation: "Una fase se cierra por evidencia suficiente, no por calendario.",
+    },
+    {
+      type: "matching",
+      pairs: [
+        { left: "Requisitos", right: "Necesidades/restricciones acordadas" },
+        { left: "Diseño", right: "Modelo de solución" },
+        { left: "Implementación", right: "Producto construido" },
+        { left: "Verificación", right: "Resultados de pruebas" },
+        { left: "Mantenimiento", right: "Correcciones/evolución" },
+      ],
+      explanation: "Los entregables hacen observable el ciclo de vida.",
+    },
+  ],
+});

prisma/content/courses/modelos-metodos-desarrollo-software/units/01-proyecto-cascada/lessons/03-ventajas-limites-cascada.ts

@@ -0,0 +1,51 @@
+import { defineLesson } from "../../../../../authoring";
+
+export const leccion03 = defineLesson({
+  slug: "ventajas-limites-cascada",
+  title: "Ventajas, límites y contexto",
+  description: "Elige cascada sólo cuando sus supuestos encajan con el problema.",
+  estimatedMinutes: 15,
+  xpReward: 45,
+  steps: [
+    {
+      type: "theory",
+      markdown: `Cascada facilita planificación, documentación e hitos claros cuando el problema es estable y el coste de cambio es alto. Puede fallar cuando el usuario descubre lo que necesita al ver versiones reales, porque el feedback llega tarde.
+
+La pregunta útil no es "¿cascada es buena o mala?", sino **qué incertidumbre existe y cuánto cuesta descubrir tarde un error**.`,
+    },
+    {
+      type: "matching",
+      pairs: [
+        { left: "Requisitos regulatorios estables", right: "Cascada puede encajar bien" },
+        { left: "Producto nuevo con necesidades inciertas", right: "Riesgo de feedback tardío" },
+        { left: "Contrato con entregables formales", right: "Trazabilidad útil" },
+        { left: "Interfaz experimental", right: "Conviene feedback temprano" },
+      ],
+      explanation: "El contexto decide qué ventaja o desventaja pesa más.",
+    },
+    {
+      type: "quiz",
+      question: "¿Cuál es un riesgo típico si los requisitos cambian mucho?",
+      options: [
+        "No permite documentación",
+        "El aprendizaje del usuario puede llegar después de comprometer diseño/implementación",
+        "Prohíbe pruebas",
+        "No puede usar Git",
+      ],
+      correctIndex: 1,
+      explanation:
+        "El problema es el coste de corregir decisiones tomadas con información incompleta.",
+    },
+    {
+      type: "fill_blank",
+      prompt: "Completa los espacios.",
+      template:
+        "Si la incertidumbre es {{0}} y el costo de cambio tardío es {{1}}, necesito feedback temprano.",
+      blanks: [
+        { answer: "alta", hint: "Hay mucho por descubrir." },
+        { answer: "alto", hint: "Corregir tarde es costoso." },
+      ],
+      explanation: "Es una heurística, no una ley universal.",
+    },
+  ],
+});

prisma/content/courses/modelos-metodos-desarrollo-software/units/01-proyecto-cascada/lessons/04-roles-y-entregables.ts

@@ -0,0 +1,50 @@
+import { defineLesson } from "../../../../../authoring";
+
+export const leccion04 = defineLesson({
+  slug: "roles-y-entregables",
+  title: "Roles, responsabilidades y entregables",
+  description: "Distingue responsabilidad de rol y actividad de evidencia.",
+  estimatedMinutes: 15,
+  xpReward: 45,
+  steps: [
+    {
+      type: "theory",
+      markdown: `Analista, desarrollador o tester son agrupaciones de responsabilidades. En un equipo pequeño una persona puede cubrir varias; lo importante es que ninguna responsabilidad quede implícita.
+
+También distingue **actividad** de **entregable**: reunirse no es evidencia; requisitos revisados sí. Programar no es evidencia de calidad; resultados de pruebas sí.`,
+    },
+    {
+      type: "matching",
+      pairs: [
+        { left: "Analizar necesidades", right: "Requisitos revisados" },
+        { left: "Diseñar solución", right: "UML/maquetado" },
+        { left: "Implementar", right: "Código versionado" },
+        { left: "Verificar", right: "Casos/resultados de prueba" },
+        { left: "Gestionar avance", right: "Lista de tareas/seguimiento" },
+      ],
+      explanation: "Una responsabilidad debe dejar una salida observable.",
+    },
+    {
+      type: "quiz",
+      question: "En un equipo de dos personas, ¿hacen falta cinco personas para cubrir cinco roles?",
+      options: [
+        "Sí",
+        "No; una persona puede asumir varias responsabilidades explícitas",
+        "Sólo con cascada",
+        "Sólo en proyectos grandes",
+      ],
+      correctIndex: 1,
+      explanation: "Rol describe responsabilidad, no obliga a una persona diferente.",
+    },
+    {
+      type: "matching",
+      pairs: [
+        { left: "Entrevistar usuario", right: "Requisitos acordados" },
+        { left: "Revisar diseño", right: "UML corregido" },
+        { left: "Ejecutar pruebas", right: "Reporte de resultados" },
+        { left: "Planear cambio", right: "Tarea/cronograma actualizado" },
+      ],
+      explanation: "El curso evalúa evidencia, no sólo actividad.",
+    },
+  ],
+});

prisma/content/courses/modelos-metodos-desarrollo-software/units/02-requerimientos/index.ts

@@ -0,0 +1,20 @@
+import { defineUnit } from "../../../../authoring";
+
+import { leccion01 } from "./lessons/01-problema-actores-alcance";
+import { leccion02 } from "./lessons/02-requisitos-funcionales";
+import { leccion03 } from "./lessons/03-requisitos-no-funcionales";
+import { leccion04 } from "./lessons/04-criterios-aceptacion";
+import { leccion05 } from "./lessons/05-cambio-de-alcance";
+
+import { practice } from "./practice";
+
+export const mmRequerimientos = defineUnit({
+  slug: "mm-02-requerimientos",
+  title: "Requerimientos, alcance y criterios de aceptación",
+  description:
+    "Convierte una petición vaga en problema, actores, alcance y requisitos funcionales y no funcionales verificables.",
+  icon: "📋",
+  published: true,
+  lessons: [leccion01, leccion02, leccion03, leccion04, leccion05],
+  practice,
+});