Fundamentos de Ingeniería de Software: Gestión, Calidad y Metodologías Ágiles

Preguntas Frecuentes sobre Gestión de Proyectos de Software

1. Herramienta WBS (Work Breakdown Structure)

Considere la herramienta WBS (Work Breakdown Structure) o EDT (Estructura de Descomposición del Trabajo) y explique de forma breve y precisa, en el contexto de gestión de proyectos de software:

• a) ¿Qué es?
• b) ¿Para qué sirve?
• c) ¿Qué práctica(s) específica(s) apoya?
• d) ¿Por qué le parece que es importante utilizarla cuando se desarrolla software?

Respuestas:

a) ¿Qué es?

Es una estructura jerárquica que descompone el trabajo total del proyecto en componentes más pequeños y manejables (entregables, fases, sub-tareas, paquetes de trabajo).

b) ¿Para qué sirve?

Sirve para planificar todas las etapas, sub-etapas, actividades y tareas que se deben desarrollar, indicando el esfuerzo, costo, duración, etc., de cada una. Facilita la definición del alcance y la organización del trabajo.

c) ¿Qué práctica(s) específica(s) apoya?

Apoya principalmente la planificación de actividades, la estimación de esfuerzo y costos, la asignación de responsabilidades y el seguimiento y control del proyecto.

d) ¿Por qué es importante?

Porque ayuda a asegurar que todo el trabajo necesario esté identificado y planificado. Lo que no se incluye en la WBS corre el riesgo de no ser considerado en la planificación inicial, lo que podría requerir realizarlo sin tiempo ni presupuesto asignado ("en tiempo cero y gratis").

2. Estimación de Esfuerzo: De Arte a Ciencia

Considerando que la estimación de esfuerzo de software es una mezcla entre arte y ciencia, explique brevemente tres acciones concretas que ejecutaría como jefe de proyecto para lograr que sea cada vez más ciencia y menos arte.

Acciones Propuestas:

1. Utilizar Datos Históricos: Recopilar y analizar métricas de proyectos anteriores (esfuerzo real, tamaño del software, complejidad) para basar las nuevas estimaciones en evidencia empírica.
2. Aplicar Modelos de Estimación: Emplear modelos algorítmicos reconocidos (como COCOMO, Puntos de Función) adaptados al contexto de la organización, en lugar de depender únicamente de la intuición o juicio experto.
3. Descomposición Detallada (WBS): Utilizar la WBS para descomponer el trabajo en tareas más pequeñas y específicas, lo que permite estimar cada componente de forma más precisa y luego agregar las estimaciones parciales.

3. Planes Útiles para Gestionar el Riesgo

¿Cuáles son los planes útiles para gestionar el riesgo? Ilustre con un ejemplo cada uno.

Tipos de Planes:

a) Planes de Mitigación:

Corresponde a la planificación de las acciones que se realizarán para disminuir la probabilidad de ocurrencia de un riesgo, su impacto, o ambos. Es una estrategia proactiva.

Ejemplo: Si existe el riesgo de que un miembro clave del equipo deje el proyecto, un plan de mitigación podría ser documentar exhaustivamente su trabajo y capacitar a otro miembro del equipo como respaldo.

b) Planes de Contingencia:

Corresponde a la planificación de las acciones que se realizarán si el riesgo se materializa, es decir, cuando se transforma en un problema real. Es una estrategia reactiva.

Ejemplo: Siguiendo con el riesgo anterior, si el miembro clave efectivamente deja el proyecto, el plan de contingencia podría ser contratar temporalmente a un consultor externo o reasignar tareas específicas al miembro del equipo que fue capacitado como respaldo.

4. Gestión Consciente de las Personas

Una de las mejores prácticas propuestas para la gestión de proyectos de software es la “gestión consciente de las personas”, que apunta a hacer un uso efectivo de los recursos de personal. Explique brevemente:

• a) ¿En qué consiste la práctica?
• b) ¿Cómo influye en la conformación de un equipo de trabajo?

Explicación:

a) ¿En qué consiste?

Consiste en reconocer que las personas son el activo más importante del proyecto. Implica entender sus habilidades, motivaciones, aspiraciones y limitaciones para asignarles tareas adecuadas, fomentar su desarrollo, promover un ambiente de trabajo positivo y colaborativo, y gestionar conflictos de manera constructiva.

b) ¿Cómo influye?

Influye directamente en la conformación de un equipo de trabajo cohesionado, motivado y productivo. Al considerar las características individuales, se pueden crear sinergias, asignar roles que potencien las fortalezas de cada miembro y construir un equipo equilibrado y comprometido con los objetivos del proyecto.

5. Calidad de Software: Visiones, Verificación y Validación

Explique brevemente:

• a) Las distintas visiones de calidad de software.
• b) Verificación de software.
• c) Validación de software.
• d) ¿Qué visión de calidad solo se focaliza en validación y no en verificación?

Conceptos de Calidad:

a) Visiones de Calidad de Software:

• Visión Trascendental: La calidad se reconoce intuitivamente, pero no puede definirse explícitamente ("Sé que es bueno cuando lo veo").
• Visión del Usuario: Grado de adecuación del software al propósito para el cual fue creado, desde la perspectiva del usuario final (fitness for purpose).
• Visión del Productor: Conformidad del software con sus especificaciones y requisitos definidos.
• Visión del Producto: Se enfoca en las características inherentes de un buen producto (ej. eficiencia, mantenibilidad, portabilidad).
• Visión del Cliente o Basada en Valor: Relaciona la calidad con el precio que el cliente está dispuesto a pagar por el software.

b) Verificación de Software:

Asegura que el software se construye correctamente de acuerdo a sus especificaciones. Responde a la pregunta: "¿Estamos construyendo el producto correctamente?" (Ej. revisiones de código, pruebas unitarias).

c) Validación de Software:

Asegura que se está construyendo el producto correcto, es decir, que satisface las necesidades del cliente y los usuarios finales. Responde a la pregunta: "¿Estamos construyendo el producto correcto?" (Ej. pruebas de aceptación del usuario).

d) Visión Focalizada en Validación:

La visión del usuario se focaliza principalmente en la validación, ya que su principal interés es si el software cumple con sus necesidades y propósito, independientemente de si sigue estrictamente la especificación interna.

6. Testing de Software

Explique de forma breve y precisa:

• a) ¿Cuál es el objetivo específico del testing de software?
• b) ¿Cuál es la actividad clave para el éxito del testing?
• c) Ilústrelo con un ejemplo sencillo.

Conceptos de Testing:

a) Objetivo Específico:

El objetivo principal del testing es ejecutar un producto de software con la intención de encontrar defectos (errores, fallos), es decir, hacer que falle para identificar dónde no cumple con los requisitos o expectativas.

b) Actividad Clave:

La actividad clave es el diseño de los casos de prueba. Se deben diseñar buenos casos de prueba, entendiendo por "buenos" aquellos que tienen una alta probabilidad de detectar un defecto aún no descubierto.

c) Ejemplo:

Funcionalidad: Sumar dos números y obtener el resultado.

Caso de prueba "bueno": 1.25 + (-3.67). Este caso prueba números decimales y negativos, cubriendo más escenarios que un caso simple.

Caso de prueba "no tan bueno": 2 + 2. Aunque válido, es menos probable que descubra ciertos tipos de errores. Por ejemplo, si por error la operación implementada fuera multiplicación (*) en lugar de suma (+), este caso daría 2 * 2 = 4, que coincide con el resultado esperado de la suma, ocultando el defecto. El caso "bueno" sí detectaría el error: 1.25 * (-3.67) = -4.5875, diferente del resultado esperado de la suma (-2.42).

7. Gestión de Configuración de Software (SCM) y Baselines

En el contexto de Gestión de Configuración de Software (SCM), explique:

• a) ¿Qué es una baseline (línea base)?
• b) ¿Cómo se modifica una baseline durante el ciclo de vida del producto de software?

Conceptos de SCM:

a) ¿Qué es una Baseline?

Una baseline o línea base es un elemento de la configuración de software (un artefacto como un documento de requisitos, código fuente, ejecutable) que ha sido revisado y aprobado formalmente en algún hito del proceso de desarrollo. Una vez establecida, la baseline se convierte en un punto de referencia estable y no puede ser modificada directamente sin un control formal. Se le asigna un número de versión específico.

b) ¿Cómo se modifica?

Una baseline establecida no se modifica directamente. Para realizar cambios, se trabaja sobre una copia de la baseline. Esta copia es la que se puede modificar. Una vez que los cambios son completados, revisados y aprobados a través de un proceso formal de control de cambios, se crea una nueva versión del artefacto, la cual puede convertirse en una nueva baseline.

8. Método Ágil Scrum

En relación al método ágil Scrum:

• a) Comente la siguiente aseveración: “Scrum no es realmente una metodología de desarrollo de software, sino de gestión de proyectos”.
• b) ¿Cuál es el rol del Scrum Master?

Conceptos de Scrum:

a) Aseveración sobre Scrum:

La afirmación es esencialmente correcta. Scrum es un marco de trabajo (framework) para la gestión de proyectos complejos, especialmente en desarrollo de software. No prescribe prácticas específicas de ingeniería o desarrollo de software (como programación pareada, TDD, integración continua), sino que se enfoca en roles, eventos (ceremonias) y artefactos para gestionar el flujo de trabajo y la entrega de valor de forma iterativa e incremental. Su foco está en los controles de gestión (ej. Daily Scrum, Sprint Review, Sprint Retrospective).

b) Rol del Scrum Master:

El Scrum Master actúa como un líder servicial y facilitador para el equipo Scrum. Sus responsabilidades principales incluyen:

• Guiar al equipo en la comprensión y adopción de la teoría, prácticas y reglas de Scrum.
• Remover obstáculos o impedimentos que dificulten el progreso del equipo.
• Proteger al equipo de interrupciones externas.
• Asegurar que los eventos de Scrum se lleven a cabo y sean productivos.
• Fomentar un ambiente de autoorganización y mejora continua.
• Asegurarse de que no se pierda el espíritu ágil y los valores de Scrum en el proyecto.

9. Proceso de Software Gestionable y CMMI

¿Qué significa que un proceso de software sea gestionable (manageable)? ¿Por qué eso es bueno? ¿Qué relación tiene con esto el modelo CMMI (Capability Maturity Model Integration)?

Proceso Gestionable:

Un proceso de software es gestionable cuando:

• Está definido, documentado y comprendido por el equipo.
• Se planifica su ejecución.
• Se monitoriza y controla su rendimiento (se recopilan métricas).
• Se toman acciones correctivas cuando hay desviaciones respecto a lo planificado.
• Los productos y artefactos generados son gestionados (ej. control de versiones, baselines).

¿Por qué es bueno?

Es bueno porque permite tener visibilidad y control sobre el proyecto. Reduce la incertidumbre, mejora la predictibilidad de los resultados (costos, plazos, calidad), facilita la toma de decisiones basada en datos y permite repetir éxitos pasados y aprender de los errores de forma sistemática.

Relación con CMMI:

El modelo CMMI proporciona un marco para la mejora de procesos organizacionales. Define niveles de madurez (y capacidad) para los procesos. Un proceso "gestionable" corresponde típicamente al Nivel de Madurez 2 (Gestionado) de CMMI. En este nivel, los proyectos establecen y gestionan sus procesos básicos, asegurando que se planifiquen, ejecuten, midan y controlen. CMMI ayuda a las organizaciones a implementar las prácticas necesarias para que sus procesos sean gestionables y, posteriormente, alcanzar niveles superiores de madurez (Definido, Gestionado Cuantitativamente, Optimizado).