1. Herramientas CASE: Conceptos y Clasificación

1.1 Definición de Herramientas CASE

CASE (Computer-Aided Software Engineering) son herramientas de software que automatizan y facilitan el desarrollo, mantenimiento y gestión de sistemas de información. Estas herramientas proporcionan un entorno integrado que combina múltiples funciones para optimizar el ciclo de vida del software, desde la planificación inicial hasta el mantenimiento final.

1.2 Clasificación de Herramientas CASE según Fases del Ciclo de Vida

2. Entornos Integrados de Desarrollo (IDE)

2.1 Concepto y Funcionalidades Principales

Un Entorno de Desarrollo Integrado (IDE) es una aplicación de software que proporciona un conjunto de herramientas integradas en una única interfaz gráfica para facilitar el desarrollo de software de manera eficiente. Los IDE combinan las funcionalidades más importantes necesarias para programar, permitiendo al desarrollador trabajar sin necesidad de cambiar entre múltiples aplicaciones.

2.2 Componentes Principales de un IDE

2.3 Tipos de Entornos de Desarrollo

IDEs Locales

Se instalan y ejecutan directamente en el equipo del desarrollador:

• Ventajas: Completo control, funcionamiento sin conexión, personalización total
• Desventajas: Configuración compleja, consume recursos locales, diferencias de configuración entre equipos
• Ejemplos: Visual Studio, IntelliJ IDEA, Eclipse, PyCharm

IDEs en la Nube

Se ejecutan en navegadores web, con recursos en servidores cloud:

• Ventajas: Acceso desde cualquier dispositivo, entorno estandarizado, menor consumo local
• Desventajas: Requiere conexión a internet, latencia potencial, dependencia del proveedor
• Ejemplos: VS Code Online, GitHub Codespaces, AWS Cloud9, Codenvy

2.4 IDEs Populares y sus Usos

3. Gestión de la Configuración del Software

3.1 Concepto y Objetivos

La Gestión de la Configuración del Software (SCM) es el conjunto de actividades que establecen y mantienen la integridad de los productos de software a lo largo de su ciclo de vida. Incluye la identificación, control, contabilidad y auditoría de la configuración de software.

3.2 Identificación de la Configuración

Elementos de Configuración (CIs)

Son los componentes del software que requieren seguimiento y control durante el ciclo de vida:

• Código fuente: Ficheros de programación (*.java, *.py, *.cpp, etc.)
• Documentación: Especificaciones, manuales, requisitos
• Componentes compilados: Librerías, ejecutables, módulos objeto
• Datos de prueba: Ficheros y bases de datos para testing
• Configuraciones: Archivos de configuración (.xml, .ini, .conf)
• Scripts: Scripts de instalación, despliegue, migración
• Dependencias: Librerías externas, versiones de herramientas

Líneas Base (Baselines)

Una línea base es un punto de referencia aprobado en el ciclo de vida del software que marca un estado estable documentado:

• Baseline Funcional: Especificaciones completas del sistema establecidas al inicio
• Baseline Asignada: Diseño del sistema documentado y aprobado
• Baseline del Producto: Software completamente desarrollado y probado, listo para producción
• Versiones Etiquetadas: Marcas específicas en el control de versiones que identifican releases

3.3 Componentes de un Plan de Gestión de Configuración

4. Control de Versiones: GIT

4.1 Conceptos Fundamentales

GIT es un sistema de control de versiones distribuido que permite a los desarrolladores rastrear cambios en el código fuente, colaborar eficientemente y mantener un historial completo de modificaciones. Es el sistema de control de versiones más popular en la actualidad, utilizado en más del 87% de los proyectos de software.

4.2 Conceptos Clave de GIT

Repositorio (Repository)

Almacén central que contiene todos los archivos, historial completo de cambios y metadatos del proyecto:

• Repositorio Local: Copia completa en la máquina del desarrollador (directorio .git)
• Repositorio Remoto: Servidor central (GitHub, GitLab, Bitbucket) donde se almacena versión oficial

Rama (Branch)

Línea independiente de desarrollo que permite trabajar en paralelo sin afectar el código principal:

• Rama Principal (main/master): Rama por defecto, generalmente contiene código estable y listo para producción
• Ramas de Desarrollo: Ramas temporales para nuevas funcionalidades, correcciones de errores
• Fusión (merge): Proceso de integrar cambios de una rama a otra

Confirmación (Commit)

Snapshots de los cambios realizados en el código en un momento específico:

• Registro permanente de modificaciones
• Incluye identificador hash SHA-1 único
• Contiene mensaje descriptivo de cambios
• Registra autor, fecha/hora y cambios exactos

4.3 Flujo de Trabajo Básico de GIT

1. MODIFICAR ARCHIVOS
   └─ Cambios realizados en el directorio de trabajo
      Estado: MODIFICADO

2. PREPARAR CAMBIOS (Staging)
   └─ Comando: git add .
      Archivos trasladados al área de preparación (index)
      Estado: PREPARADO

3. CONFIRMAR CAMBIOS (Commit)
   └─ Comando: git commit -m "Mensaje descriptivo"
      Cambios guardados permanentemente en repositorio local
      Estado: CONFIRMADO

4. ENVIAR AL REPOSITORIO REMOTO (Push)
   └─ Comando: git push origin main
      Cambios sincronizados con servidor remoto
      Disponibles para todo el equipo
            

4.4 Operaciones Principales de GIT

5. Flujos de Trabajo con GIT

5.1 Git Flow

Git Flow es un modelo de flujo de trabajo complejo y estructurado, diseñado para proyectos con ciclos de publicación planificados y versiones múltiples en mantenimiento.

Ramas Principales (vida infinita):

• main: Rama de producción, contiene código estable y lanzamientos oficiales
• develop: Rama de integración, contiene desarrollo actual en progreso

Ramas de Soporte (vida finita):

• feature/: Ramas para nuevas funcionalidades (ej: feature/login-system)
• release/: Ramas para preparar lanzamiento a producción
• hotfix/: Ramas para correcciones urgentes en producción

5.2 GitHub Flow

GitHub Flow es un modelo ligero y simple, ideal para equipos con entregas continuas e integración frecuente.

Características Principales:

• Rama main siempre lista para producción: El código en main debe ser estable y deployable
• Feature branches: Se crean ramas descriptivas desde main (ej: add-user-authentication)
• Pull Requests: Antes de fusionar, se abre un PR para revisión de código
• Revisión y discusión: El equipo revisa, comenta y aprueba cambios
• Merge a main: Una vez aprobado, se fusiona a main e inmediatamente a producción
• Despliegue frecuente: Múltiples despliegues por día posibles

5.3 GitLab Flow

GitLab Flow combina simplicidad de GitHub Flow con estructura de ambientes de Git Flow.

• Rama main: Código estable listo para producción
• Feature branches: Desarrollo de nuevas funcionalidades
• Environment branches: Ramas por cada ambiente (staging, production)
• Merge requests: Revisión de código antes de fusión
• Despliegue controlado: Promoción cuidadosa entre ambientes

6. Integración en MÉTRICA Versión 3

MÉTRICA versión 3 es la metodología estándar de la administración pública española para desarrollo de sistemas. Incorpora la gestión de configuración en el proceso de Construcción del Sistema (CSI):

6.1 Actividades de Gestión de Configuración en MÉTRICA 3

• CSI 1: Preparación del entorno, incluyendo configuración de herramientas de control de versiones
• CSI 2-5: Durante codificación y pruebas, todos los cambios deben ser registrados en GIT
• CSI 6-7: Generación de baselines de código probado y documentación de versiones

7. Mejores Prácticas en Gestión de Configuración

8. Cuestionario de Evaluación (20 Preguntas)

9. Referencias Bibliográficas