B3-T11: Metodologías de Desarrollo, Control de Versiones y Pruebas
Este tema combina metodologías de desarrollo (Scrum, cascada, Métrica v3), control de versiones (Git) y calidad del software (pruebas, CI/CD). Git aparece en TODOS los exámenes desde 2016. Scrum y Métrica v3 aparecen frecuentemente.
METODOLOGÍAS DE DESARROLLO
| Metodología | Tipo | Características |
|---|---|---|
| Cascada (Waterfall) | Predictiva / Secuencial | Fases secuenciales: Requisitos → Diseño → Implementación → Verificación → Mantenimiento. No se vuelve atrás |
| Modelo en V | Predictiva | Cada fase de desarrollo tiene su fase de prueba simétrica. Verificación continua |
| Espiral (Boehm) | Iterativa, basada en riesgo | Ciclos: Planificar → Análisis de riesgos → Desarrollar → Evaluar. Prototipado |
| Iterativo / Incremental | Iterativa | Entregas parciales funcionales. Cada iteración añade funcionalidad |
| Scrum | Ágil | Sprints cortos, equipo autoorganizado, entrega continua de valor |
| Kanban | Ágil | Flujo continuo, tablero visual, límites WIP (Work In Progress) |
| XP (Extreme Programming) | Ágil | Pair programming, TDD, integración continua, refactoring constante |
| DevOps | Cultura / Práctica | Unión Dev + Ops. CI/CD, automatización, monitorización. Cultura, no metodología |
MANIFIESTO ÁGIL
Fuente: Manifesto for Agile Software Development (agilemanifesto.org) — 2001, documento público. 17 firmantes.
| # | Valoramos más... | ...que |
|---|---|---|
| 1 | Individuos e interacciones | Procesos y herramientas |
| 2 | Software funcionando | Documentación extensiva |
| 3 | Colaboración con el cliente | Negociación contractual |
| 4 | Respuesta ante el cambio | Seguir un plan |
Tip examen: El manifiesto no dice que lo de la derecha no importe — dice que se valora más lo de la izquierda. Tiene además 12 principios ágiles.
SCRUM
Fuente: The Scrum Guide (scrumguides.org) — Ken Schwaber y Jeff Sutherland. Versión actual: noviembre 2020. Documento público.
| Rol | Responsabilidad | NO confundir con |
|---|---|---|
| Product Owner | Maximizar el valor del producto. Gestiona y prioriza el Product Backlog | Jefe de proyecto (no lo es) |
| Scrum Master | Facilita Scrum, elimina impedimentos, protege al equipo | Líder técnico (no lo es) |
| Developers | Equipo autoorganizado que crea el Incremento. Scrum Team completo: 10 o menos personas (Scrum Guide 2020) | Solo programadores (incluye testers, diseñadores, etc.) |
| Evento | Timebox | Propósito |
|---|---|---|
| Sprint | 1-4 semanas (fijo) | Contenedor de todos los eventos. Produce un Incremento potencialmente entregable |
| Sprint Planning | 8h (Sprint de 1 mes) | Qué se puede hacer en este Sprint + cómo (Sprint Backlog) |
| Daily Scrum | 15 minutos | Inspección del progreso hacia el Sprint Goal. Solo Developers |
| Sprint Review | 4h (Sprint de 1 mes) | Inspeccionar el Incremento con stakeholders. Feedback y adaptación del backlog |
| Sprint Retrospective | 3h (Sprint de 1 mes) | Cómo mejorar el proceso. Plan de mejoras para el siguiente Sprint |
| Artefacto | Compromiso asociado | Descripción |
|---|---|---|
| Product Backlog | Product Goal | Lista ordenada de todo lo necesario para el producto. Gestionado por el Product Owner |
| Sprint Backlog | Sprint Goal | Subset del Product Backlog seleccionado para el Sprint + plan de trabajo |
| Incremento | Definition of Done | Suma de todos los Product Backlog Items completados + valor de Incrementos anteriores |
Pregunta clásica: Scrum tiene 3 roles, 5 eventos (Sprint + 4 ceremonias) y 3 artefactos. El Sprint Goal, Product Goal y Definition of Done son compromisos (Scrum Guide 2020).
SCRUM vs KANBAN
| Aspecto | Scrum | Kanban |
|---|---|---|
| Iteraciones | Sprints fijos (1-4 semanas) | Flujo continuo (sin iteraciones) |
| Roles | PO, SM, Developers (obligatorios) | No prescribe roles |
| Planificación | Sprint Planning por Sprint | Según capacidad (pull system) |
| Límite de trabajo | Sprint Backlog fijo | WIP limits por columna |
| Métricas | Velocity, Burndown | Lead Time, Cycle Time, Throughput |
| Cambios | No durante el Sprint | En cualquier momento |
MÉTRICA v3
Fuente: PAe — Portal de Administración Electrónica (administracionelectronica.gob.es). Métrica v3 es la metodología oficial de la AGE para desarrollo de sistemas de información.
| Proceso | Sigla | Descripción |
|---|---|---|
| Planificación de SI | PSI | Plan estratégico de SI de la organización. Catálogo de requisitos. Arquitectura tecnológica |
| Desarrollo de SI | — | Se divide en 5 subprocesos: |
| Estudio de Viabilidad | EVS | ¿Es viable el sistema? Alternativas de solución, análisis coste-beneficio |
| Análisis del SI | ASI | Qué debe hacer el sistema: requisitos funcionales y no funcionales, modelo de datos |
| Diseño del SI | DSI | Cómo se construye: arquitectura, diseño detallado de módulos, pantallas, BD |
| Construcción del SI | CSI | Codificación, pruebas unitarias, integración de componentes |
| Implantación y Aceptación | IAS | Instalación, migración de datos, formación, pruebas de aceptación, paso a producción |
| Mantenimiento de SI | MSI | Mantenimiento correctivo, evolutivo, adaptativo, perfectivo |
| Interfaz | Sigla | Función |
|---|---|---|
| Gestión de Proyectos | GP | Planificación, seguimiento y control. Transversal a todo el desarrollo |
| Seguridad | SEG | Análisis de riesgos, mecanismos de seguridad. Transversal |
| Gestión de la Configuración | GC | Control de versiones, gestión de cambios, líneas base |
| Aseguramiento de la Calidad | CAL | Revisiones, auditorías, métricas de calidad |
Tip examen: Métrica v3 tiene 3 procesos principales (PSI, Desarrollo con 5 subprocesos, MSI) y 4 interfaces (GP, SEG, GC, CAL). Los subprocesos de desarrollo son: EVS → ASI → DSI → CSI → IAS.
GIT — CONTROL DE VERSIONES
Fuente: Git Reference Manual (git-scm.com/docs) — Linus Torvalds, 2005. Licencia GPL v2. Documentación pública.
| Concepto | Descripción |
|---|---|
| Tipo | DVCS — Sistema de control de versiones distribuido |
| Snapshots | Git almacena snapshots (instantáneas) del proyecto, no deltas/diferencias |
| Integridad | Todo identificado por hash SHA-1 (40 caracteres hexadecimales) |
| 3 áreas | Working Directory → Staging Area (index) → Repository (.git) |
| Branch | Puntero ligero a un commit. Por defecto: main (antes master) |
| HEAD | Puntero al commit actual / branch activo |
| Comando | Función | Área |
|---|---|---|
git init | Inicializa repositorio local | Crea .git/ |
git clone url | Clona repositorio remoto | Copia completa |
git add archivo | Añade al staging area | Working → Staging |
git commit -m "msg" | Crea snapshot (commit) | Staging → Repository |
git status | Estado de archivos (modified, staged, untracked) | Info |
git log | Historial de commits | Info |
git diff | Diferencias entre áreas | Info |
git branch nombre | Crea rama | Repository |
git checkout rama | Cambia a rama (o git switch) | Working |
git merge rama | Fusiona rama en la actual | Repository |
git rebase rama | Reaplica commits sobre otra base (historial lineal) | Repository |
git pull | Descarga + merge del remoto | Remote → Local |
git push | Sube commits al remoto | Local → Remote |
git fetch | Descarga del remoto sin merge | Remote → Local (sin aplicar) |
git stash | Guarda cambios temporalmente | Working → Stash |
git tag v1.0 | Etiqueta un commit (release) | Repository |
git reset | Mueve HEAD. --soft (staging), --mixed (working), --hard (borra todo) | Repository |
git revert commit | Crea nuevo commit que deshace otro (seguro) | Repository |
Pregunta clave:git pull=git fetch+git merge. Git es distribuido (cada clon tiene el historial completo). Merge crea commit de fusión; rebase reescribe el historial.
ESTRATEGIAS DE RAMIFICACIÓN
| Estrategia | Ramas principales | Cuándo usar |
|---|---|---|
| Git Flow | main, develop, feature/*, release/*, hotfix/* | Releases planificadas, equipos grandes |
| GitHub Flow | main + feature branches | Deploy continuo, equipos ágiles |
| Trunk-Based | main (todos integran directo) | CI/CD maduro, feature flags |
PLATAFORMAS GIT
| Plataforma | Tipo | Diferenciador |
|---|---|---|
| GitHub | SaaS (Microsoft) | Mayor comunidad open source. GitHub Actions (CI/CD) |
| GitLab | SaaS + Self-hosted | DevOps integrado (CI/CD, registry, monitoring) |
| Bitbucket | SaaS (Atlassian) | Integración con Jira. Pipelines integrados |
CI/CD (Integración Continua / Entrega Continua)
Fuente: Conceptos de CI/CD popularizados por Martin Fowler ("Continuous Integration", 2006) y Jez Humble ("Continuous Delivery", 2010). Documentos públicos.
| Práctica | Qué automatiza | Frecuencia |
|---|---|---|
| CI (Continuous Integration) | Build + tests automáticos en cada commit/push | Cada commit |
| CD (Continuous Delivery) | CI + artefacto listo para deploy (aprobación manual) | Cada merge a main |
| CD (Continuous Deployment) | CI + deploy automático a producción (sin intervención humana) | Cada commit verde |
| Herramienta | Tipo | Uso |
|---|---|---|
| Jenkins | Servidor CI/CD (open source, Java) | Pipelines declarativos/scripted. Plugins extensibles |
| GitHub Actions | CI/CD integrado en GitHub | Workflows en YAML. Runners hosted o self-hosted |
| GitLab CI/CD | CI/CD integrado en GitLab | .gitlab-ci.yml. Runners, stages, jobs |
| SonarQube | Análisis estático de código | Calidad: bugs, vulnerabilidades, code smells, cobertura, duplicación |
| Nexus / Artifactory | Repositorio de artefactos | Almacén de binarios (JAR, Docker images, npm packages) |
| Docker | Contenedorización | Empaqueta app + dependencias. Dockerfile → image → container |
Tip examen: SonarQube mide calidad de código (no lo ejecuta). Sus métricas clave: bugs, vulnerabilities, code smells, coverage (%), duplications (%). Las Quality Gates definen umbrales mínimos.
TIPOS DE PRUEBAS SOFTWARE
Fuente: ISO/IEC 29119 — Software Testing. ISTQB Foundation Syllabus (istqb.org) — documentos públicos. IEEE 829 — Test Documentation.
| Nivel | Prueba | Qué prueba | Quién |
|---|---|---|---|
| 1 | Unitarias | Funciones/métodos individuales aislados (con mocks) | Desarrollador |
| 2 | Integración | Interacción entre módulos/componentes | Desarrollador / QA |
| 3 | Sistema | Sistema completo contra requisitos funcionales y no funcionales | QA |
| 4 | Aceptación | El sistema cumple las necesidades del usuario/cliente | Cliente / Usuario |
| Tipo (por enfoque) | Descripción |
|---|---|
| Caja negra (Black box) | Se prueba sin conocer el código interno. Solo entradas y salidas esperadas |
| Caja blanca (White box) | Se prueba conociendo la estructura interna: ramas, caminos, cobertura |
| Caja gris | Combinación: se conoce parcialmente la estructura interna |
| Tipo (no funcional) | Qué mide |
|---|---|
| Rendimiento | Tiempo de respuesta, throughput bajo carga normal |
| Carga (Load) | Comportamiento bajo carga esperada |
| Estrés (Stress) | Comportamiento bajo carga extrema (más allá del límite) |
| Seguridad | Vulnerabilidades, inyecciones, autenticación, autorización |
| Usabilidad | Facilidad de uso, eficiencia, satisfacción del usuario |
| Regresión | Que cambios nuevos no rompan funcionalidad existente |
| Humo (Smoke) | Verificación rápida de que lo básico funciona (build verification test) |
TDD Y BDD
| Práctica | Ciclo | Descripción |
|---|---|---|
| TDD (Test-Driven Development) | Red → Green → Refactor | Escribir test primero (falla), implementar mínimo para pasar, refactorizar |
| BDD (Behavior-Driven Development) | Given → When → Then | Especificaciones en lenguaje natural (Gherkin). Herramientas: Cucumber, SpecFlow |
TIPOS DE MANTENIMIENTO
| Tipo | Motivo | Ejemplo |
|---|---|---|
| Correctivo | Corregir defectos | Fix de un bug reportado |
| Adaptativo | Adaptar a cambios de entorno | Migrar a nuevo SO, nueva versión de BD |
| Perfectivo | Mejorar funcionalidad o rendimiento | Nueva feature solicitada, optimización |
| Preventivo | Prevenir problemas futuros | Refactoring, actualizar dependencias, documentar |
FUENTES PÚBLICAS
Este resumen ha sido elaborado íntegramente a partir de fuentes de dominio público. No se ha utilizado material con copyright de terceros ni material de preparadores.
| Fuente | Tipo | Referencia |
|---|---|---|
| The Scrum Guide (2020) | Guía oficial | scrumguides.org (CC BY-SA) |
| Manifiesto Ágil (2001) | Documento público | agilemanifesto.org |
| Métrica v3 | Institucional | administracionelectronica.gob.es (PAe) |
| Git Reference Manual | Documentación oficial | git-scm.com/docs (GPL v2) |
| ISTQB Foundation Syllabus | Certificación pública | istqb.org |
| ISO/IEC 29119 — Software Testing | Estándar | ISO |