Gestión y Desarrollo de Proyectos Software: Guía Completa

Gestión de Proyectos Software

Decisión de Emprender el Proyecto

La decisión de emprender un proyecto de software puede surgir por diversas razones, entre ellas:

• Cambios en los requisitos del software existente.
• Petición de un cliente o usuario.
• Propuesta generada dentro de la organización.
• Necesidad detectada por el departamento de marketing.
• Recomendación específica del personal de mantenimiento.
• Detección de necesidades de desarrollo por parte del personal informático.

Selección del Jefe de Proyecto

La selección del jefe de proyecto se basa en criterios como:

• Relación con el negocio.
• Competencias personales.
• Competencias de actuación interpersonal.
• Habilidades de gestión.

Características del Jefe de Proyecto

• Liderazgo: Habilidad para motivar al equipo.
• Capacidad de Relación: Comunicar con el equipo y desarrollar sus capacidades.
• Visión del Negocio: Conocimiento, negociación y compromiso con la calidad.
• Comprensión Técnica: Conocimientos para la toma de decisiones técnicas.
• Competencia en la Gestión: Capacidad de planificación y control de actividades, costes y presupuestos.
• Presteza y Decisión: Observar, evaluar y decidir con rapidez.
• Versatilidad y Flexibilidad: Adaptarse a acontecimientos imprevistos.
• Integridad: Reclutar personal capacitado y ganar la confianza del cliente.
• Previsión: Anticiparse a los problemas y aportar soluciones.

Estudios de Viabilidad

Los estudios de viabilidad analizan diferentes aspectos del proyecto:

• Económico: ¿Es rentable la inversión?
• Técnico: ¿Son realizables la funcionalidad, el rendimiento y las restricciones?
• Legal: ¿Cumplen los requisitos con la legislación vigente?
• Operativa: ¿Se puede implementar de manera efectiva?
• Plazos y Calendario: ¿Es realista el plazo propuesto?

Fases del Análisis de Viabilidad

1. Estudiar la solicitud del proyecto y definir el alcance y los límites del sistema.
2. Analizar la situación actual, describiendo y evaluando los sistemas de información existentes e identificando a los usuarios y personas involucradas.
3. Realizar una definición preliminar de los requisitos.
4. Estudiar y especificar las diferentes alternativas.
5. Evaluar cada alternativa, incluyendo su viabilidad económica.
6. Seleccionar y aprobar la alternativa más apropiada.

Análisis de Coste-Beneficio

Permite seleccionar la alternativa más beneficiosa y prever las necesidades financieras.

Costes a Tener en Cuenta

• Hardware y software.
• Comunicaciones.
• Coste de desarrollo del sistema.
• Gastos de instalación e infraestructura.
• Costes anuales de mantenimiento.
• Consultoría.
• Formación.
• Material de oficina.
• Disminución de productividad por la curva de aprendizaje.
• Otros costes: financieros, publicitarios.

Beneficios

• Incremento de productividad y ahorro de recursos.
• Ahorro de gastos de mantenimiento.
• Ahorros en inversiones y mantenimiento de hardware o software.
• Incremento de ventas o disminución de costes de producción.
• Ahorros en material, recursos externos, etc.
• Beneficios financieros.
• Intangibles: Incremento de calidad, reducción de errores, aumento de velocidad.

Pruebas de Software

Verificación y Validación

Verificación: Proceso de evaluación para determinar si los productos de una fase satisfacen las condiciones impuestas al inicio de la misma.

Validación: Proceso de evaluación para determinar si el sistema o componente satisface los requisitos especificados.

Definiciones

• Prueba (test): Proceso de ejecutar un programa para encontrar errores.
• Caso de Prueba (test case): Conjunto de entradas, condiciones de ejecución y resultados esperados.
• Defecto (defect, fault, bug): Defecto en el software.
• Fallo (failure): Incapacidad de un sistema o componente para realizar las funciones requeridas.
• Error.

Recomendaciones para las Pruebas

• Definir el resultado de salida esperado para cada caso de prueba.
• Evitar que un programador pruebe sus propios programas.
• Inspeccionar a conciencia el resultado de cada prueba.
• Incluir datos de entrada válidos y esperados, así como no válidos e inesperados.
• Centrar las pruebas en dos objetivos:
  • Probar si el software no hace lo que debe.
  • Probar si el software hace lo que no debe.
• Evitar improvisar con los casos de prueba.
• No hacer planes de prueba suponiendo que hay pocos defectos.
• Tener en cuenta que donde hay un defecto suele haber otros.

Enfoques para el Diseño de Casos de Prueba

Caja Blanca: Se centra en la estructura interna del programa para elegir los casos de prueba.

Caja Negra: Se estudia la especificación de las funciones, la entrada y la salida para derivar los casos de prueba.

Prueba Funcional

Dos definiciones:

• Reduce el número de otros casos necesarios para que la prueba sea razonable.
• Cubre un conjunto extenso de otros casos posibles.

Enfoque Práctico Recomendado para el Diseño de Casos

• Si la especificación contiene combinaciones de condiciones de entrada, comenzar formando sus grafos de causa-efecto.
• Usar el análisis de valores-límites para añadir casos de prueba.
• Identificar las clases válidas y no válidas.
• Utilizar la técnica de conjetura de errores.
• Ejecutar los casos generados hasta el momento (de caja negra) y analizarlos.
• Examinar la lógica del programa para añadir los casos precisos (de caja blanca).

Plan de Pruebas

Objetivo: Señalar el enfoque, los recursos y el esquema de actividades de prueba, las características, las actividades de prueba y el personal responsable.

Depuración

Es el proceso de localizar, analizar y corregir los defectos del software.

Consecuencias

• Encontrar la causa del error, analizarla y corregirla.
• No encontrar la causa y tener que generar nuevos casos de prueba.

Etapas

1. Localización del defecto.
2. Corrección del defecto.

Localización del Error

• Analizar la información y pensar. Al llegar a un punto muerto, pasar a otra cosa.
• Usar herramientas de depuración como recurso secundario.
• No experimentar cambiando el programa.
• Atacar los errores individualmente.

Estrategia de Aplicación de las Pruebas

• Las pruebas comienzan a nivel de módulo.
• Progresan hacia la integración del sistema completo y su instalación.
• Culminan cuando el cliente acepta el producto y se pasa a su explotación.

Ciclo de Vida en UVE

Relación de productos de desarrollo y fases de pruebas.

• Prueba de Módulo (Prueba de Unidad): Se centra en la lógica del módulo (caja blanca) y los aspectos de la especificación de las funciones (caja negra).
• Prueba de Integración: Considera los mecanismos de agrupación de módulos y las interfaces entre componentes.
• Prueba del Sistema: Se centra en el cumplimiento de los objetivos del sistema.
• Prueba de Aceptación: El usuario verifica si el producto final se ajusta a los requisitos.

Planificación, Organización, Dirección y Supervisión

Planificación

• Objetivos a corto y largo plazo.
• Políticas organizativas.
• Procedimientos estándares.
• Análisis de tareas.
• Obtención y distribución de recursos.

Organización

• Asignación de tareas a puestos de trabajo.
• Gestión del personal.
• Determinación de las relaciones organizativas.
• Delegación de autoridad.

Dirección

• Comunicación.
• Jefatura.
• Coordinación.
• Valoración de la ejecución.
• Resolución de conflictos.
• Mantenimiento de políticas de la empresa.

Supervisión

• Comparación de la ejecución actual y la deseada.
• Toma de decisiones correctivas.

Jefe de Proyecto y Plan de Proyecto

Jefe de Proyecto: Persona responsable de planificar, controlar y dirigir las actividades del proyecto.

Plan de Proyecto: Documento que describe los trabajos a realizar y la forma en que se dirigirá su desarrollo. Define un conjunto de tareas coordinadas en el tiempo.

Objetivos del Plan de Proyecto

• Proporcionar un resumen del proyecto a los directivos.
• Permitir la supervisión del progreso del proyecto.
• Presentarse como un documento orientado al cliente.
• Constituir un documento base del proyecto, con la aprobación del cliente y actualizable.

Contenido del Plan de Proyecto

• Resumen del proyecto.
• Lista de hitos.
• Procedimientos y estándares.
• Especificación del proceso de revisión.
• Plan de comunicación entre la organización de desarrollo y el cliente.
• Diagrama de descomposición del trabajo.
• Lista del personal del proyecto y su asignación.
• Red de actividades que muestra la secuencia de tareas.
• Responsables de todas las actividades.
• Presupuestos de esfuerzo, dinero, calendarios y plazos.

Calendario

Representación gráfica de las actividades del proyecto necesarias para producir el resultado final.

Pasos para la Elaboración del Calendario

1. Definición de los objetivos del proyecto.
2. Descomposición de las actividades.
3. Relación entre las actividades.
4. Estimación de los tiempos y costes de las actividades.
5. Ajuste del programa de tiempos a las restricciones del proyecto.
6. Asignación de recursos / Definición de la organización del equipo.
7. Revisión del calendario.

Técnicas para la Elaboración del Calendario

• Diagrama de Hitos: Tabla con actividades y fechas de finalización.
• Diagramas de Gantt: Tabla que relaciona tareas y tiempos de duración.
• Redes de Precedencia (PERT y CPM): Representación gráfica de las actividades y sus dependencias.

Crítica a los Modelos de Costes

• Dificultad para calcular el coste del desarrollo.
• La aplicación de los puntos de función puede ser problemática.
• La cantidad y representatividad de los proyectos históricos puede ser limitada.
• Los modelos pierden precisión en entornos distintos a los que se basan.
• Los factores de coste son difíciles de cuantificar y se consideran independientes.
• Los modelos tienen cierto margen de error.

Seguimiento y Supervisión del Proyecto Software

Objetivos

• Comparar los resultados actuales con los planes previstos.
• Tomar acciones correctivas ante desviaciones significativas.
• Acordar compromisos con el personal afectado por las acciones correctivas.
• Supervisar los resultados.

Problemas que Afectan al Calendario

• Dificultad para definir el trabajo.
• Poca implicación del equipo.
• Problemas con la organización y constitución del equipo.
• Organización del equipo insuficiente.
• Proyecto considerado poco importante.
• Falta de planes de contingencia.
• Mala comunicación con la dirección y el cliente.
• Mala comprensión en las líneas de comunicación.
• Dificultad para trabajar entre departamentos.
• Mala dirección del proyecto.
• Poca asistencia de la dirección.
• Falta de compromiso del jefe de proyecto con el equipo.
• Dificultades para valorar los riesgos.

Seguimiento de Costes, Calendario y Aspectos Técnicos

Además de los costes y el calendario, es necesario hacer seguimiento de los recursos críticos del proyecto y el tamaño de los productos software.

Importancia del Seguimiento de Aspectos Técnicos

• Detecta problemas que no se ven con otros seguimientos.
• Genera datos históricos útiles para la estimación de futuros desarrollos.

Seguimiento de Hitos

Informa de manera más realista sobre el porcentaje completado del proyecto, ya que el sistema entero tiene que haber superado ciertas fases del ciclo de vida.

El análisis de valor ganado asigna un valor monetario a cada parte del sistema y fase del ciclo de vida. La finalización de la fase se convierte en una métrica de valor conseguido, que se compara con el presupuesto gastado para ver si el proyecto sigue el plan.

Criterios para Controlar Proyectos

• Planificación detallada del proyecto.
• Descomposición del proyecto en actividades y tareas.
• Definición de resultados y entregables.
• Establecimiento de hitos.
• Compromiso del equipo.
• Seguimiento del proyecto.
• Medición del progreso.
• Revisiones regulares.

Acciones Correctivas

Se realizan cuando los resultados reales se desvían significativamente de los planes.

Ejemplos de acciones correctivas:

• Añadir personal o horas extra.
• Reasignar empleados para mejorar la eficiencia.
• Reducir el alcance o contenido de una entrega.
• Ajustar el calendario, negociando con el cliente.

Gestión de Riesgos del Software

Tipos de Riesgos

• Riesgos estratégicos: Relacionados con la estrategia de la organización.
• Riesgos comerciales: Problemas con la venta del proyecto, el seguimiento del cliente o el precio.
• Riesgos contractuales y financieros: Relacionados con los términos contractuales.
• Riesgos de gestión: Organización de los proyectos, recursos, equipos y calendarios.
• Riesgos de proyecto: Aspectos técnicos del software (especificación, diseño, realización, integración y validación).
• Riesgos de explotación: Fallos durante la explotación que pueden causar daños significativos.
• Riesgos de mantenimiento: Sobrecostes en mantenimiento correctivo, preventivo y soporte.