Introducción a la gestión de proyectos de software

Principios de gestión “Cualquier comandante que acepta llevar a

cabo un plan que él considera defectuoso es culpable; él debe exponer sus razones, e insistir en cambios necesarios y finalmente ofrecer su dimisión antes de ser el instrumento de la derrota de su ejército”. Napoleón.

La administración de proyectos requiere: planificación y control.

La planificación del proyecto consiste en distribuir la estimación del esfuerzo a lo largo del proyecto asignado.

Planificación

La planificación del proyecto consiste en redefinir la planificación sobre la marcha. Aportando medidas para palear los desfases respecto a la planificación inicial.

El control (o seguimiento) del proyecto consiste en ejecutar las actividades de revisión previstas en la etapa de planificación, y comparar los resultados contra lo planificado.

Principios Básicos

Segmentación - el proyecto debe ser separado en un número manejable de actividades y tareas.

Interdependencia – la planificación debe reflejar la segmentación de tareas, y la relaciones entre ellas. Hay algunas tareas ocurren en secuencia, otras en paralelo, algunas son requisito de otras, etc.

Asignación de tiempo - a cada tarea se le debe asignar un cierto número de unidades de trabajo (personas-días, etc) y fechas de inicio y término.

Validación del esfuerzo – se debe verificar que la gente asignada a una tarea esté disponible y además que sea suficiente.

Principios Básicos (2)

Definición de responsabilidades - cada tarea debe tener un responsable.

Salida definida - cada tarea debe tener un “producto” bien definido. Por ejemplo: diseño de un módulo, plan de pruebas, etc.

Definición de metas - cada grupo de tareas se debe estar asociado con una meta.

Gestión de Proyectos de Sw

Establecer el ámbito Recursos Estimación Análisis de Riesgos Planificación Seguimiento

Ambito

Ponerse de acuerdo con el cliente en los objetivos y ámbito del software. Los objetivos identifican los fines globales del

proyecto sin considerar como se llegará a esos fines.

El ámbito identifica las funciones primordiales que debe llevar a cabo el software y, lo que es más importante, intenta limitar esas funciones de manera cuantitativa.

Recursos

RR.HH Software (reutilización) Entorno

Estimación

LDC PF

Modelos Empíricos Cocomo Cocomo II Ecuación del Software (Putnam)

Visitar http://www.qsm.com

Riesgos

Riesgos del Proyecto: Amenazan al plan del proyecto.

Riesgos Técnicos: Amenazan la calidad Tecnología de Punta.

Riesgos del Negocio: peligra la viabilidad del software a desarrollar.

Riesgos (2)

Estrategias Reactivas

Supervisar el proyecto en previsión de posibles riesgos.

Resultado: el equipo no hace nada, proyecto en peligro

Proactivas Comienza antes que los trabajos Identificar riesgos potenciales, su

probabilidad e impacto

Riesgos (3)

Identificar el riesgo Crear una lista de posibles riesgos Organización en la lista de riesgos

Capítulo 6 (pressman 5ª edición)

Riesgos (4) Ejemplo

Riesgos Probabilidad Impacto

Usuarios finales resisten al sistema

40% 3

Personal sin experiencia

80% 2

Falta de información de herramientas

80% 3

El cliente cambiará los requisitos.

80% 2

Valores de Impacto:1- Catastrófico 2- Crítico3- Marginal 4- Despreciable

Planificación de Tareas Carta Gantt, Mallas Pert

Determinar la ruta crítica (secuencia de tareas que define la duración del proyecto)

Herramientas: Project

Control de tareas

Hay que contrastar la realidad contra lo planificado, ... Y generar planes de contingencia, en caso de ser necesario.

Hay que monitorear (controlar) todo, así se asegurará el tener “las riendas el proyecto”.

Control de tareas (2)

Formas de monitoreo Llevar a cabo reuniones periódicas en las

cuales los participantes informan del estado de las tareas, el progreso o los problemas encontrados.

Determinar si las metas están siendo cumplidas de acuerdo a lo programado

Comparar tiempos planeados contra tiempos reales, para las distintas tareas

Control de tareas (3)

Tener en cuenta que…..

“La mayoría de las veces el administrador del proyecto marca la diferencia entre el éxito o el fracaso de un proyecto”

“La gestión es tan importante como la parte técnica....”

¿Porqué se fracasa? (gente)

Baja motivación del equipo Baja calidad de la gente Personal “problema” Síntomas de heroísmo (only you) Agregar gente a proyecto atrasado

(Mythical man month, Frederick Brooks)

¿Porqué se fracasa? (2)

Espectativas poco realistas Falta de convencimiento de

colaboradores (stakeholders). Falta de input de los usuarios Falta de comunicación en el equipo de

trabajo.

¿Porqué se fracasa? (proceso)

Programación de tareas muy optimista Manejo de riesgo defectuoso Planeación Insuficiente Tiempo insuficiente en Análisis y

Diseño. Diseño inadecuado Plan de recuperarse mas adelante

¿Porqué se fracasa? (proceso)

Síndrome de la bala de plata. Sobreestimación de nuevos métodos o

herramientas. Cambio de herramientas en la mitad

del proyecto. Falta de manejo automatizado de

código fuente (gestión de configuración).

Importante

Para construir buen software no basta con ser buen programador.

Para ello, hay que conocer, planificar y controlar los procesos y recursos asignados a un proyecto.

Recomendaciones

Capitulo 3 Pressman, 5ª edición. Capitulo 6 Pressman, 5ª edición.

Conclusiones

La planificación del proyecto provee un marco de referencia para monitoreo y control de estas tareas.

La planificación del proyecto se desarrolla al comienzo pero es continuamente refinada a medida que el trabajo progresa.

Conclusiones (2)

Clásico…. “si se incorpora más gente a un proyecto que ya está atrasado, éste se atrasará aun más” (Brooks, 1975)

Es necesario ir comparando las estimaciones iniciales, con las reales, tan pronto como se pueda.

Hay que tener en cuenta los riesgos.

Conclusiones (3)

Una buena intuición soportada por experiencia documentada (información histórica) generalmente es más precisa que cualquier modelo.