Evaluación de Gestión de Proyectos de Software
1. Work Breakdown Structure (WBS)
a) ¿Qué es?
La Work Breakdown Structure (WBS) o Estructura de Descomposición del Trabajo es una herramienta que permite descomponer un proyecto en partes más pequeñas y manejables.
b) ¿Para qué sirve?
Sirve para planificar todas las etapas, sub-etapas, actividades y tareas que se deben desarrollar en un proyecto de software, indicando el esfuerzo, costo, duración, etc. de cada una.
c) ¿Qué práctica(s) específica(s) apoya?
Apoya la planificación de actividades y la estimación de esfuerzo.
d) ¿Por qué es importante utilizarla?
Es importante utilizarla porque lo que no se incluya en la WBS deberá realizarse en tiempo cero y sin costo adicional, lo cual es inviable en la práctica.
2. Estimación de Esfuerzo en Software
Considerando que la estimación de esfuerzo de software es una mezcla entre arte y ciencia, se proponen 3 acciones concretas para hacerla más científica:
- Utilizar datos históricos: Recopilar y analizar datos de proyectos anteriores para identificar patrones y tendencias.
- Emplear técnicas de estimación formales: Como el método de puntos de función o COCOMO, que proporcionan un enfoque más estructurado y basado en datos.
- Realizar revisiones por expertos: Involucrar a expertos en el dominio y en estimación para validar y ajustar las estimaciones.
3. Planes para la Gestión de Riesgos
a) Planes de Mitigación:
Corresponden a la planificación de acciones proactivas para disminuir la probabilidad de un riesgo, su impacto, o ambos. Ejemplo: Realizar pruebas de rendimiento anticipadas para mitigar el riesgo de baja performance del sistema.
b) Planes de Contingencia:
Corresponden a la planificación de acciones reactivas que se ejecutarán cuando el riesgo se presente, es decir, cuando se convierta en un problema real. Ejemplo: Tener un servidor de respaldo listo para ser activado en caso de una falla del servidor principal.
4. Gestión Consciente de las Personas
a) ¿En qué consiste?
Consiste en hacer un uso efectivo de los recursos de personal, considerando sus habilidades, motivaciones y necesidades.
b) ¿Cómo influye en la conformación de un equipo de trabajo?
Influye positivamente al promover un ambiente de trabajo colaborativo, donde cada miembro se siente valorado y puede contribuir con sus fortalezas, lo que resulta en un equipo más cohesionado y productivo.
5. Calidad de Software
a) Distintas Visiones de Calidad:
- Visión Trascendental: La calidad se reconoce pero no puede definirse.
- Visión del Usuario: Grado de adecuación al propósito.
- Visión del Productor: Conformidad con la especificación.
- Visión del Producto: Características inherentes de un buen producto.
- Visión del Cliente o Basada en Valor: ¿Cuánto está dispuesto a pagar?
b) Verificación de Software:
¿Estamos construyendo el producto correctamente?
c) Validación de Software:
¿Estamos construyendo el producto correcto?
d) ¿Qué visión de calidad sólo se focaliza en validación?
La visión del usuario se focaliza principalmente en la validación.
6. Testing de Software
a) Objetivo Específico:
Ejecutar un producto de software para que falle y de ese modo detectar defectos.
b) Actividad Clave:
Diseño de los casos de prueba, ya que deben diseñarse buenos casos (aquellos que tienen una alta probabilidad de detectar un defecto aún no descubierto).
c) Ejemplo:
Sumar dos números y obtener el resultado. Buen caso: 1,25 + (-3,67). Caso no tan bueno: 2 + 2, pues puede haber un error en la operación (* en vez de +) e igual se obtiene 4.
7. Gestión de Configuración de Software (SCM)
a) Baseline:
Un baseline es un elemento de la configuración de software (artefacto) que ha sido revisado y aprobado en algún hito del proceso de desarrollo, por lo que no puede ser modificado. Se le asigna un número de versión.
b) Modificación de un Baseline:
Un baseline no se modifica directamente. Se trabaja sobre una copia del baseline, la cual se puede modificar, creando así una nueva versión del artefacto.
8. SCRUM
a) ¿Metodología de Desarrollo o de Gestión?
La aseveración «SCRUM no es realmente una metodología de desarrollo de software, sino de gestión de proyectos» es esencialmente correcta. SCRUM no determina prácticas de desarrollo de software y su foco está en controles de gestión (ej. daily scrum).
b) Rol del SCRUM Master:
Es un facilitador que guía al equipo SCRUM, remueve obstáculos y se preocupa de que no se pierda el espíritu SCRUM en el proyecto.
9. Procesos de Software Gerenciables y CMMI
Un proceso de software es gerenciable cuando es definido, medible, controlable y mejorable. Esto es bueno porque permite aumentar la eficiencia, reducir errores y mejorar la calidad del producto final. El modelo CMMI (Capability Maturity Model Integration) se relaciona con esto al proporcionar un marco de referencia para la mejora de procesos, incluyendo la gestión de proyectos de software.