Skip to content

Tema 3: Principios que Guían la Práctica de la Ingeniería del Software

1. Resumen Ejecutivo

Esta sesión establece las "buenas prácticas" fundamentales para el desarrollo de software moderno, alejándose de procesos rígidos hacia enfoques ágiles y adaptables. Se divide en principios que rigen el proceso general, la práctica técnica, la comunicación del equipo, la planificación, el modelado, la construcción y el despliegue. El núcleo de la lección es el sentido común aplicado: buscar la calidad, gestionar el cambio y entender que el software es una disciplina madura donde no se debe reinventar la rueda.

2. Conceptos Clave

  • Economía de Acción (Agile): Maximizar el trabajo no realizado; hacer solo lo necesario sin sacrificar calidad.
  • Abstracción: Capacidad de manejar un sistema complejo enfocándose en diferentes niveles de detalle según la fase (requisitos vs. código).
  • Divide y Vencerás: Descomponer un problema grande en subproblemas pequeños para resolverlos de forma independiente.
  • Principio de Pareto (80/20): En pruebas, una minoría de componentes (20%) suele contener la mayoría de los errores (80%).
  • KISS (Keep It Simple, Stupid): Buscar siempre la solución o el modelo más sencillo posible.
  • Cohesión y Acoplamiento: Metas del diseño modular: alta cohesión (lo de dentro tiene sentido junto) y bajo acoplamiento (poca dependencia entre módulos).

3. Desarrollo del Temario

3.1. Principios que Guían el Proceso

Estos principios se refieren al "día a día" y la filosofía general de trabajo.

  • Ser Ágil y Adaptable: No se trata solo de rapidez, sino de economía de acción. El proceso no puede ser rígido (como los antiguos modelos en cascada); debe adaptarse al proyecto, a las personas y a los cambios.
  • Enfoque en la Calidad: Es la base de todo. Los hitos de paso deben enfocarse en la calidad del entregable, no solo en cumplir fechas.
  • Equipo Eficaz y Multidisciplinar: > Ejemplo del Profesor: En proyectos modernos no solo hay informáticos. Se trabaja con diseñadores gráficos, psicólogos (para UX) e incluso expertos en neuromarketing para entender las emociones del usuario. Hay que saber coordinarse con perfiles que no son técnicos ("Divide y vencerás" aplica también a los equipos).
  • Gestión del Riesgo:
    • No basta con listar los riesgos. Hay que tener un Plan de Contingencia.
    • Pregunta clave: "¿Y si ocurre?". Si el riesgo se materializa, ¿qué hacemos?.
  • Valor Añadido: No publicar productos por el mero hecho de cumplir un hito. El producto debe ser útil para el siguiente eslabón de la cadena (sea otro equipo o el cliente final).

3.2. Principios que Guían la Práctica (Ingeniería)

Reglas generales para ejecutar la ingeniería del software.

  • Divide y Vencerás:
    • Problema grande \(N\) problemas pequeños.
    • Permite desarrollo independiente y concurrente.
  • Abstracción:
    • Es entender el sistema desde diferentes puntos de vista y niveles de detalle.

      Ejemplo del Profesor ("Frutería Paki"): 1. Nivel Alto (Requisitos): Tomar un café con el cliente y que te cuente cómo funciona su negocio. 2. Nivel Medio (Diseño): Documentos funcionales y prototipos. 3. Nivel Bajo (Implementación): Picar el código. El sistema es el mismo (la frutería), pero el nivel de detalle técnico cambia.

  • Buscar la Coherencia:
    • La informática es una disciplina madura. Existen estándares de facto que el usuario espera (ej. iconos de guardar, disposición de menús).

      Ejemplo del Profesor: El cambio de botones en Android (versiones 4.4 a 5.0) o en Linux. Si cambias el botón "Aceptar" de la derecha a la izquierda, confundes al usuario porque rompes su "memoria muscular" y la coherencia cultural.

  • Mantenimiento: Entenderlo como parte del ciclo de vida. El software no se rompe, se degrada o queda obsoleto. Mantener es evolucionar.

3.3. Principios de Comunicación

La comunicación debe ser fluida entre el equipo y con el cliente.

  • Escucha Activa: Para entender o dudar, primero hay que escuchar.
  • Preparación: Las reuniones funcionan mejor con una agenda (orden del día) y documentación previa. Evita perder tiempo.
  • Documentar Decisiones:
    • ¡OJO AL DATO!: Lo más importante de documentar en una reunión son las DECISIONES tomadas. Las actas evitan el "¿Por qué decidimos esto hace tres meses?".
  • Colaboración y Consenso: Las decisiones consensuadas son más estables.
  • Avanzar: Evitar bloqueos. Si no hay acuerdo o falta info, se avanza al siguiente punto y se retoma en otra iteración.
  • Negociación: Buscar el "Win-Win" (Objetivo común), no "uno gana y otro pierde".

3.4. Principios de Planificación

  • Iterativa: Las planificaciones secuenciales (todo cerrado al principio) no tienen sentido hoy en día. Se asume que habrá cambios.
  • Estimaciones:
    • Se basan en la experiencia.

      Consejo Académico: Aprovechad los trabajos (como el TFG) para practicar estimaciones. Equivocaos ahora para aprender a ajustar los tiempos ("dije 2 días, tardé 4").

  • Gestión del Riesgo en Planificación: Si hay riesgos identificados, asume que algunos se cumplirán. Debes reservar tiempo ("colchón") para cuando esos riesgos se materialicen.
  • Realismo: Contar con bajas, vacaciones, y % de horas efectivas no al 100%.
  • Coste de la Calidad: Las revisiones, métricas y gestión del cambio consumen tiempo; eso debe estar reflejado en el plan.

3.5. Principios de Modelado

En metodologías ágiles, el software funcional pesa más que la documentación exhaustiva.

  • Regla de Oro: No crear más modelos de los que se necesiten. Si un modelo no aporta valor o no sabes para qué lo haces, no lo hagas.
  • Principio KISS: El modelo perfecto no es rentable. Busca el modelo más sencillo que explique el problema.
  • Requisitos:
    • Enfocarse en el Modelo del Dominio (datos) y el comportamiento frente a eventos.
    • La modularidad empieza aquí: dividir requisitos funcionales.
  • Diseño:
    • Trazabilidad: El diseño debe rastrearse hasta los requisitos.
    • Arquitectura: Define interfaces y estructura de datos.
    • Modularidad Eficaz: Buscar Alta Cohesión (funcionalidad concentrada) y Bajo Acoplamiento (poca dependencia externa).

3.6. Principios de Construcción (Codificación y Pruebas)

Codificación

  1. Antes: Entender el problema y seleccionar el lenguaje/entorno adecuado. Crear pruebas antes de codificar (TDD).
  2. Durante: Prioridad a la Orientación a Objetos (OO), uso de estándares (indentación, nomenclatura clara - no llamar a variables "patata") y revisión por pares (Peer-review).
  3. Después: Validar, corregir y, si hay errores, rediseñar las pruebas primero, luego el código.

Pruebas (Testing)

  • Trazabilidad: Cada prueba debe validar un requisito.
  • Principio de Pareto (\(80/20\)): El 80% de los errores suelen estar en el 20% de los componentes. El objetivo es localizar esos módulos problemáticos.
  • Jerarquía de Pruebas: De pequeño a grande:
    1. Unitarias.
    2. Integración.
    3. Validación.
    4. Aceptación .
  • Factibilidad: No es posible probar todas las rutas de ejecución ("exhaustive testing is impossible"). Hay que priorizar.

3.7. Principios de Despliegue

  • Expectativas: Explicar al cliente fidedignamente qué se le entrega para evitar decepciones.
  • Incremento Desplegable: El software debe estar completo y auto-contenido ("Potentially Shippable Increment"). No entregar cosas a medias que explotan si tocas un botón.
  • Soporte: Materiales de aprendizaje, changelogs y formación planificada antes de la entrega.
  • Calidad Final: Nunca entregar software defectuoso solo por cumplir la fecha. La mala calidad deja una percepción negativa prolongada.

4. Preguntas de Autoevaluación

  1. ¿Cómo se aplica el Principio de Pareto en el contexto de las pruebas de software?

    • Respuesta: Sugiere que una minoría de componentes (aprox. el 20%) contiene la mayoría de los errores (80%), por lo que el esfuerzo de prueba debe centrarse en localizar esos módulos críticos.

  2. Según los principios de modelado en un entorno ágil, ¿cuándo se debe crear un modelo adicional?

    • Respuesta: Únicamente cuando aporte valor claro y utilidad. Se debe evitar crear modelos por burocracia; el software funcionando tiene prioridad sobre los modelos extensos.

  3. Diferencia entre Cohesión y Acoplamiento (mencionada en principios de diseño).

    • Respuesta: La Cohesión es la medida en que los elementos dentro de un módulo pertenecen juntos (se busca alta). El Acoplamiento es la medida de interdependencia entre distintos módulos (se busca bajo).

  4. ¿Qué implica la "economía de acción" en los principios del proceso?

    • Respuesta: Implica maximizar el trabajo no realizado, es decir, ser ágil evitando tareas que no aportan valor directo al producto o a la calidad, manteniendo el enfoque técnico lo más sencillo posible.

  5. ¿Por qué se dice que el mantenimiento es parte del ciclo de vida y no una reparación?

    • Respuesta: Porque el software se degrada por obsolescencia del entorno o cambio de necesidades, no por "rotura" física. El mantenimiento implica evolución y adaptación continua, no solo arreglar bugs.