Administración de Proyectos de Software

Presentación del tema: "Administración de Proyectos de Software"— Transcripción de la presentación:

1 Administración de Proyectos de Software

2 Objetivo Planear un proyecto de software considerando la administración de actividades y compromisos necesarios para su cumplimiento aplicando las técnicas apropiadas para darle seguimiento, así como las estrategias de comunicación que permitan a la totalidad de los integrantes del equipo de trabajo acordar los compromisos relacionados con el proyecto.

3 Antes de entrar en materia ...
Habilidades necesarias en un PM (Project Management) Liderazgo Comunicación Solución de Problemas Negociación Influencia en la organización Mentoring Experiencia Técnica Procesos

4 1.0 Introducción Procesos De Negocio PM Ambiente de PM Métodos
Técnicos Politicas

5 1.1 Atributos de un proyecto
PMI “A project is a temporary endeavor undertaken to create a unique product or service” Elaborado en forma progresiva Con elementos repetitivos Tienen un PM Conductor, Coach, Capitán ? Interacciones: Sponsor, Ejecutivos, Equipo de trabajo, Clientes, Contratistas, Gerentes.

6 1.2 Ciclo de vida de un proyecto

7 1.2 Ciclo de vida de un proyecto

8 1.2 Ciclo de vida de un proyecto

9 1.3 Proceso de planeación El control del proyecto solo puede ser alcanzado cuando el costo, calendario y los objetivos técnicos están claramente documentados, son realistas y están manejados en forma responsable y deliberada.

10 1.3 Proceso de planeación ...como un proceso cerrado
Criterios de Entrada Criterios de Salida

11 1.3 Proceso de planeación El proceso de planeación debe resultar de la conjunción de las partes: sentido claro del costo, calendario y objetivos técnicos. El establecimiento de estas partes deben de ser: Objetivos técnicos derivados de un claro entendimiento de los requisitos del negocio. Los costos deben de ser realistas y de acuerdo al presupuesto El calendario debe de ser alcanzable y de acuerdo a las necesidades del negocio.

12 1.4 Identificación de las necesidades de un proyecto: Estructura de una solicitud de propuesta
1 Resumen Ejecutivo 1.1 Nuestro Entendimiento de Sus Metas 1.2 Nuestro Enfoque para Atender sus Metas 1.3 Visión General de la Solución 1.4 Cómo Entregaremos 1.5 ¿Por qué nosotros? 2 Recomendación de Solución 2.1 Capacidades de la Solución 2.2 Ventajas de la Arquitectura de la Solución 2.3 Recursos y Beneficios 2.4 Cómo Nuestra Experiencia Puede Ayudarlo

13 1.5 Soluciones propuestas: Estructura de la propuesta de solución
3 Administración de Proyecto 3.1 Plan de Implementación por Fase 3.2 Metas de Rendimiento y Responsabilidad 3.3 Plan de Trabajo del Proyecto y Cronograma Estimado 3.4 Estructura Organizacional 3.5 Equipo del Proyecto 4 Precio 4.1 Visión General 4.2 Entregables y Precio Estimado 5 Referencias Adicionales 5.1 Estudio de Caso 5.2 Miembros del Equipo y Roles 5.3 Marca Registrada y Términos de Contrato

14 1.6 Consideración de la planeación y control en:CMM, ISO, MoProsoft
Capability Maturity Model Carnegie Mellon Software Engineering Institute Modelo de Procesos para la Industria del Software International Standard Office

15 Un poco de experiencia personal ! . . .
Actividades de un PM Definir el alcance del proyecto Identificar stakeholders, decision-makers, y proceso de escalamiento Desarrollar la lista de actividades (work breakdown structures) Estimación de tiempos Diagrama de flujo del manejo del proyecto Identificacion de recursos y presupuesto

16 Un poco de experiencia personal ! . . .
Mas actividades ! Evaluar requerimientos del proyecto Identificar y evaluar riesgos. Preparar el plan de contingencia Identificar interdependencias Identificar y dar seguimiento a compromisos/fechas criticas Participar en las revisiones Asegurar los recursos necesarios Control de cambios Estatus del proyecto

17 Un poco de experiencia personal ! . . .
Errores que tenemos que evitar!!!

18 Relacionados a las personas
Baja Motivación Personal técnicamente débil Débil vs. Junior Problemas de los empleados sin control Heroes Agregar personal tarde al proyecto Oficinas ruidosas, congestionadas Fricciones cliente-desarrollador Expectativas no reales Política Ilusiones/deseos

19 Relacionados al proceso
Calendarios optimistas Manejo de riesgos insuficiente Fallas en el proveedor Planeación insuficiente Abandono del plan en caso de crisis Diseño inadecuado Controles gerenciales insuficientes Omisión de tareas necesarias en estimados Planear actividades de recuperacion Programación Code-like-hell

20 Relacionadas a la tecnología
Síndrome de “La Bala de Plata” Sobre-estimación de ahorros basados en nuevas herramientas y métodos Cambios de herramientas a la mitad del proyecto Falta de un control automático de código fuente

21 1.3 Proceso de planeación El proceso de planeación debe resultar de la conjunción de las partes: sentido claro del costo, calendario y objetivos técnicos. El establecimiento de estas partes deben de ser: Objetivos técnicos derivados de un claro entendimiento de los requisitos del negocio. Los costos deben de ser realistas y de acuerdo al presupuesto El calendario debe de ser alcanzable y de acuerdo a las necesidades del negocio.

22 2.0 Planeación del Proyecto de Software

23 ...antes de iniciar PMI PMI Scope Planning Scope Definition
Activity Definition Activity Sequencing Activity Duration Estimating Resource Planning Cost Estimating Cost Budgeting Risk Planning Schedule Development PMI Quality Planning Communications Planning Organization Planning Staff Acquisition Procurement Planning Project Plan Development

24 2.1 Definición del Objetivo del proyecto
Lo primero que tenemos que hacer ! Identificar alcance y objetivos Identificar el ambiente organizacional Analizar las características del proyecto Identificar los productos y las actividades Estimar el esfuerzo de cada actividad Identificar los riesgos Asegurar los recursos Revisar y comunicar el plan En pocas palabras ! ... Entender que es lo que queremos hacer y ponerlo en blanco y negro. Aquí comienza el SOW ( Statement of work )‏

25 2.2 Elección de un modelo de proceso de Software
Lineal Secuencial Prototipos Evolutivo

26 2.2 Elección de un modelo de proceso de Software
Conclusiones Podemos crear modelos que se ajusten a nuestras necesidades Es critico el que evaluemos los modelos para seleccionar el que mejor nos convenga. Debo de hacer un análisis previo del cliente, del recurso humano y del objetivo del sistema para poder hacer una mejor elección del modelo Nos damos cuenta de que los modelos no son excluyentes Respetar y seguir el modelo elegido No etiquetar modelos

27 2.3 Estructura de la división del trabajo ( WBS )‏

28 2.3 Ejemplo de un WBS 0.0 Retail Web Site 1.0 Project Management
2.0 Requirements Gathering 3.0 Analysis & Design 4.0 Site Software Development 4.1 HTML Design and Creation 4.2 Backend Software 4.2.1 Database Implementation 4.2.2 Middleware Development 4.2.3 Security Subsystems 4.2.4 Catalog Engine 4.2.5 Transaction Processing 4.3 Graphics and Interface 4.4 Content Creation 5.0 Testing and Production

29 2.3 ¿Que es un WBS? Es una lista de actividades, no de cosas
La lista de las cosas viene de diferentes fuentes. Describe las actividades No poner mas detalles del que pueda ser manejado

30 2.3 Técnicas para hacer un WBS
Top-Down Bottom-Up Analógia Post-It en la pared

31 2.3 Técnicas para hacer un WBS
Top-Down Comienza a un nivel alto En forma sistemática se desarrolla mas detalle Es bueno si: El problema es bien entendido Tecnología y Metodología no son nuevos Similar a un proyecto anterior. Aplicado en muchas situaciones.

32 2.3 Técnicas para hacer un WBS
Botton - up Comienza desde abajo Se van agregando conforme se incrementa el nivel Tiene en contra que consume tiempo Necesita tener los requerimientos completos. La ventaja es que es muy detallado

33 2.3 Técnicas para hacer un WBS
Analogía Se basa en un proyecto similar Se usa un template La estimación puede ser basada en la analogía también Tiene la ventaja de basarse en la experiencia Pero necesita un proyecto comparable.

34 2.3 WBS El WBS es la base de: Calendarización Costos
Analísis de riesgos Estructura Organizacional Control Métricas

35 2.4 Estimación de tamaño de productos de trabajo
Primero hablemos de un par de verdades ! ... Arte y Ciencia en la estimación del Software Ciencia son herramientas bien desarrolladas y bien soportadas. El arte de la estimación se basa aun en “rule of thumb” y todavia necesita mas trabajo

36 2.4 Estimación de tamaño de productos de trabajo
Después hablemos de los pecados ! ... El primero y mas importante ... NO APRENDER !!! Estimar cuanto nos vamos a tardar antes de saber que es lo que tenemos que hacer. Asumir que las mejores estimaciones vienen de las personas con mas influencia en la organización Comparar la estimación de un proyecto haciendo referencia a uno similar (anterior)... Que fue mal !!!! Asumir que otros departamentos estiman mejor que los que harán realmente el trabajo. No estimar educación y entrenamiento, o vacaciones, o gente que se puede ir a otro proyecto, o se enferma, o ..., o .... Presentar un estimado muy exacto ( 67.4 días ) con un error muy alto de exactitud ( +/- 2 meses )‏ El razonamiento de que entre mas rápido nos demos cuenta de que vamos mal, mas tiempo tendremos de reponernos Asumir que los programadores dan el estimado por verse bien o por no hacer rápido el trabajo

37 2.4 Estimación de tamaño de productos de trabajo
Después hablemos de los pecados MORTALES ! ... Asumir que las metas y los estimados, es lo mismo Decir SI cuando queremos decir NO Programadores son jovenes Comprometer los estimados demasiado temprano Asumir que una mala estimación no tiene impactos en los resultados del proyecto Estimar lo imposible Sobre-estimar ahorros Usar una sola técnica de estimación No usar una herramienta No incluir los impactos del análisis de riesgos en el estimado

38 2.4 Estimación de tamaño de productos de trabajo
¿ Como se estima ? Es necesario usar un método/modelo Tal vez el mas usado es “Function Points” COCOMO Basarse en datos históricos o si no hay, en preguntar a expertos Hacer un análisis sensitivo Mejor Caso Caso más probable Peor Caso Incluir análisis de riesgos Bajo Riesgo Riesgo mediano Alto Riesgo Normalizar la información (que de todo, saquemos una sola cosa, para que todos entendamos lo mismo)‏ Curva de aprendizaje (Considerar la curva de aprendizaje)‏

39 2.4 Estimación de tamaño de productos de trabajo
¿ Como se estima ? Establecimiento de métricas Falta de compromiso gerencial Demasiadas métricas, demasiado rápido Pocas métricas, muy tarde (ver doc Clase 3)‏ Medir algo incorrecto Indefinición en las métricas No debemos usar los datos para evaluar personas No usar las métricas para motivar personas sino para entender el proceso. Recolectar información que no es usada (usen la info y retroalimente, porque si no se corre el riesgo de que las personas dejen de capturar metricas)‏ Falta de comunicación y entrenamiento (Ya empezamos a medir, ¿alguien sabe, que estamos midiendo? Mala interpretación de las métricas

40 2.4 Estimación de tamaño de productos de trabajo

41 2.4 Estimación de tamaño de productos de trabajo

42 2.5 Estimación de esfuerzo del proyecto.

43 2.5 Estimación de esfuerzo del proyecto.

44 2.5 Estimación de esfuerzo del proyecto.
El cono de la incertidumbre

45 2.5 Estimación de esfuerzo del proyecto.
Seguimiento a “El cono de la incertidumbre”

46 2.5 Estimación de esfuerzo del proyecto.
Vamos viendo los puntos importantes para poder estimar el esfuerzo de un proyecto Calendario Tareas a realizar Análisis de riesgos Recursos Administración Operaciones Calidad Espacio/Equipo/Instalaciones Relaciones Publicas

47 2.5 Estimación de esfuerzo del proyecto.
Calendario Desarrolladores tienden a ser introve(Lamentablemente el desarrollador no tiene habilidades de negociante)rtidos (los obligamos a decirnos los numeros que deseamos y no los que ellos realmente piensan)‏ El calendario típicamente se negocia entre el gerente y ventas Desarrolladores carecen de habilidades de negociación Algunos tips para negociar el calendario Separar la persona del problema (Debemos buscar a la persona que entre en el perfil)‏ Enfocarse en el interés no en la posición (Debemos ver que es lo que mas nos conviene como compañia en vez de convenencias individuales)‏ Buscar una solución de ganar-ganar Establecer un criterio objetivo (Que? como? escritos y firmados, por cumplimiento de actividades y no por satisfacción del cliente)‏ Juntas de Kickoff (Juantas de arranque, para aclarar fechas y compromisos y que todos las conozcan)‏ Planear e incluir en el calendario las juntas de estatus y la forma de comunicarse (Cuantas juntas por que medio)‏ Asignar responsables a las tareas a realizar

48 2.5 Estimación de esfuerzo del proyecto.
Tareas a realizar ( WBS )‏ Estimar cada una de las tareas Juicio experto Experiencia Preguntando Técnica del mejor caso, peor caso, caso mas probable Dependencias entre los recursos y las tareas (Por lo general asumimos que los recursos son ilimitados, nunca le asignaremos 59 tareas a una sola persona)‏

49 2.5 Estimación de esfuerzo del proyecto.
Análisis de Riesgos Basado en la experiencia Datos Históricos (es la mejor opción, solamente que requiere cierta diciplina para monitorear la frecuencia de en que se presentan los riesgos, ¿Cada cuanto y Cuantas veces se va la luz? ¿Qué puede suceder? ¿cómo lo arreglamos?

50 2.5 Estimación de esfuerzo del proyecto.
Recursos ¿Qué podemos aprender de nuestros errores pasados? ¿Qué podemos aprender de nuestros éxitos pasados? Recursos con los que contamos Recursos faltantes Plan para adquirirlos Restricciones de calendario Algo similar Recursos ejecutivos Plan estratégico Prioridades, direcciones, metas Posición competitiva

51 2.5 Estimación de esfuerzo del proyecto.
Administración Con quién se cuenta Líneas de comunicación Métodos de reporte Estructuras que necesitamos Personal necesario Personal actual Contrataciones, subcontratos, consultores Proceso de involucramiento (como van a ir entrando y como van a ir saliendo)‏ Habilidades y conocimientos (los que tenemos y los que hacen falta)‏ Quién necesita saber que Entrenamiento ¿Quién necesita estar enterado?, ¿como ? Costos, Financiamiento

52 2.5 Estimación de esfuerzo del proyecto.
Operaciones Tiempos Fechas límite Que afecta a los tiempos Como aseguramos entregar a tiempo Quien hará el trabajo

53 2.5 Estimación de esfuerzo del proyecto.
Calidad Monitorear el progreso Como sabemos si estamos a tiempo o no Métricas Reportes Datos necesarios Quien reporta a quien.

54 2.5 Estimación de esfuerzo del proyecto.
Espacio/Equipo/Instalaciones Necesidades de infraestructura (Capacidad instalada, colores)‏ Herramientas Equipo de computo