Desarrollo de Software
¿Método o metodología?

¿Método o metodología? Decidir cómo se construye el software

Un equipo no fracasa por escribir mal el código: fracasa por organizar mal el trabajo. Esta actividad parte de cero — aquí mismo aprendes qué son los métodos, los modelos de ciclo de vida, las metodologías y los marcos de trabajo— y termina pidiéndote algo que ningún examen de memoria pide: elegir bajo restricciones reales y sostener la decisión.

Encuadre

Competencia

Distingue método, modelo de ciclo de vida, metodología y marco de trabajo; y selecciona, adapta y sustenta una forma de organizar el desarrollo coherente con las restricciones de un proyecto.

Resultados de aprendizaje

  • RA1. Diferencia con precisión método, modelo de ciclo de vida, metodología y marco de trabajo.
  • RA2. Caracteriza los principales enfoques (predictivos, iterativos y adaptativos) y su origen.
  • RA3. Argumenta una elección metodológica frente a restricciones contractuales, normativas, de riesgo y de equipo.
  • RA4. Configura un marco de trabajo documentando cadencia, roles, artefactos, métricas y definición de terminado.

Ruta de la actividad

  • 1 · Conceptos base — lectura + clasificador · 10 pts
  • 2 · Banco de marcos — 10 fichas de estudio · sin puntaje
  • 3 · Desmontaje de mitos10 pts
  • 4 · Matriz de identificación20 pts
  • 5 · Simulador de decisión — 5 casos · 50 pts
  • 6 · Acta de marco de trabajo10 pts
  • 7 · Informe — descarga y entrega

Calificación

60 % puntaje del simulador (100 pts automáticos) · 40 % rúbrica docente sobre las justificaciones escritas, el acta y la sustentación oral. Escala 0.0 – 5.0.

Aviso: en dos de los cinco casos del simulador, la respuesta que "suena moderna" es la más débil. Lee las restricciones antes de responder por costumbre.

Identificación

Momento 1 · Los cuatro conceptos que casi nadie separa 10 pts

En la industria estas cuatro palabras se usan como sinónimos. No lo son, y la confusión tiene consecuencias: equipos que creen "estar haciendo Scrum" cuando lo que cambiaron fue el nombre de la reunión del lunes.

Nivel 1

Método

Procedimiento concreto y repetible para resolver una tarea específica de ingeniería.

Pregunta que responde:
¿cómo ejecuto esta tarea?

Ejemplos:análisis orientado a objetos, casos de uso, TDD, programación en parejas, diagramas entidad-relación, revisión por pares.
Nivel 2

Modelo de ciclo de vida

Forma en que se ordenan las fases en el tiempo: secuencia, repetición y cadencia.

Pregunta que responde:
¿en qué orden y cada cuánto entrego?

Ejemplos:cascada, modelo V, incremental, iterativo, evolutivo, espiral.
Nivel 3

Metodología

Cuerpo completo y prescriptivo: integra métodos + ciclo de vida + roles + artefactos + criterios de calidad, con una filosofía detrás.

Pregunta que responde:
¿cómo trabajamos de principio a fin?

Ejemplos:RUP/UP, XP, Métrica v3, MSF.
Nivel 3 bis

Marco de trabajo

Estructura mínima, incompleta a propósito: define lo indispensable y deja que el equipo ponga sus propios métodos.

Pregunta que responde:
¿qué reglas mínimas nos damos?

Ejemplos:Scrum, Kanban, SAFe.
La frase que debes poder defender en la sustentación: «Scrum no es una metodología de desarrollo de software: es un marco de gestión del trabajo. No te dice cómo programar, cómo probar ni cómo diseñar la arquitectura. Esas prácticas técnicas las aporta XP o las decide tu equipo.» Por eso existen equipos "haciendo Scrum" que entregan software de mala calidad: el marco nunca prometió resolver eso.

Clasificador

Clasifica cada elemento en el nivel que le corresponde. 1 punto cada uno.

Momento 2 · Banco de marcos material de estudio

Diez fichas. Ninguna supera media página. Léelas antes de los momentos 3, 4 y 5 — y vuelve a ellas cuando dudes: en el simulador se puede consultar este banco, porque en la vida profesional también se consulta.

Cada ficha responde seis preguntas: qué es · de dónde viene · cómo ordena el trabajo · qué produce · cuándo sirve · cuándo falla. La última es la que casi nunca aparece en clase y la que más se evalúa aquí.

Momento 3 · Desmontaje de mitos 10 pts

Cinco afirmaciones que circulan en foros, videos y hasta en algunas clases. Decide si son verdaderas o falsas.

Momento 4 · Matriz de identificación 20 pts

Cada rasgo pertenece de forma característica a un enfoque. Asigna el que corresponde. Varios se parecen a propósito; si dudas, vuelve al banco de fichas.

Momento 5 · Simulador de decisión 50 pts

Cinco proyectos con restricciones reales. Para cada uno: elige el enfoque (hasta 8 pts), marca los dos factores que de verdad determinan la decisión (hasta 2 pts) y escribe tu justificación técnica (la evalúa el docente con la rúbrica).

No hay una única respuesta válida. Hay respuestas óptimas, defendibles, débiles e inadecuadas. El sistema te dice en cuál caíste y por qué — léelo, es la parte que enseña.

Momento 6 · Acta de marco de trabajo 10 pts

Elegir un enfoque no es implementarlo. Configura el proceso que usarías realmente si dirigieras uno de los casos. El sistema revisa la coherencia entre lo que configuras y las restricciones del caso: puede aprobarte la elección y reprobarte la implementación.

Momento 7 · Informe y entrega

Rúbrica docente (40 % de la nota)

CriterioSuperior 4.6–5.0Alto 4.0–4.5Básico 3.0–3.9Bajo <3.0
Dominio conceptual
RA1
Separa con precisión método, ciclo de vida, metodología y marco; usa ejemplos propios.Los separa con imprecisiones menores.Confunde marco de gestión con prácticas técnicas.Usa los cuatro términos como sinónimos.
Pertinencia de la selección
RA3
Elige enfoques coherentes en los 5 casos y explicita los trade-offs que asume.Coherente en 4 casos; reconoce algunos trade-offs.Coherente en 3 casos; decide por costumbre.Elige por moda, sin leer las restricciones.
Argumentación técnica
RA3
Cada justificación conecta restricción → riesgo → mecanismo del enfoque, con vocabulario preciso.Argumenta técnicamente pero deja un salto sin sustentar.Argumenta en general, sin aterrizar al caso.Repite definiciones de manual.
Coherencia del acta
RA4
Cadencia, ceremonias, artefactos y métricas se sostienen entre sí y con el caso; la DoD es verificable.Acta completa con una incoherencia menor.Acta completa pero genérica: serviría para cualquier proyecto.Acta incompleta o contradictoria.
SustentaciónDefiende la decisión ante el contraargumento del docente y admite los límites de su elección.Defiende con seguridad; vacila ante el contraargumento.Expone pero no defiende.No sustenta.

Nota final = (puntaje del simulador ÷ 20) × 0.6 + (promedio de rúbrica) × 0.4

Referencias

  • Royce, W. (1970). Managing the Development of Large Software Systems. Proc. IEEE WESCON. — Revisa las figuras: el autor del "cascada" advirtió que el modelo puro era riesgoso.
  • Boehm, B. (1988). A Spiral Model of Software Development and Enhancement. IEEE Computer, 21(5), 61–72.
  • Kruchten, P. (2003). The Rational Unified Process: An Introduction (3.ª ed.). Addison-Wesley.
  • Beck, K. & Andres, C. (2004). Extreme Programming Explained: Embrace Change (2.ª ed.). Addison-Wesley.
  • Schwaber, K. & Sutherland, J. (2020). La Guía de Scrum. scrumguides.org — 13 páginas; léela completa antes de opinar sobre Scrum.
  • Anderson, D. (2010). Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press.
  • Manifiesto por el Desarrollo Ágil de Software (2001). agilemanifesto.org — 4 valores y 12 principios.
  • ISO/IEC/IEEE 12207:2017. Systems and software engineering — Software life cycle processes.
  • Sommerville, I. (2016). Ingeniería de Software (10.ª ed.), caps. 2 y 3. Pearson.
  • Pressman, R. & Maxim, B. (2020). Ingeniería del Software: un enfoque práctico (9.ª ed.), parte 1. McGraw-Hill.