La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Gestión de Proyectos Profesores: LLuís Duran, Process Improvement Febrero 2006.

Presentaciones similares


Presentación del tema: "Gestión de Proyectos Profesores: LLuís Duran, Process Improvement Febrero 2006."— Transcripción de la presentación:

1

2 Gestión de Proyectos Profesores: LLuís Duran, Process Improvement Febrero 2006

3 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved A. Introducción Gestión Proyectos Informáticos B. Creación del Plan de Proyecto C. Ciclo de vida en la Gestión del Proyecto D. Gestión de la Calidad Gestión de Proyectos Informáticos Programa

4 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved APARTADO A Introducción Gestión Proyectos Informáticos

5 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 4 ÍNDICE A. Introducción a la Gestión de Proyectos Informáticos A.1. Objetivo de la gestión A.2. Áreas a gestionar A.3. Elementos de la gestión Objetivo: obtener una visión básica de los temas fundamentales a tratar en este módulo Finalidad: evitar asociar gestión de un proyecto informático a la gestión del cronograma de un proyecto

6 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved A.1. Objetivo de la gestión - ¿Cuál? (1/2) A. Introducción Gestión Proyectos COSTE TIEMPO REQUISITOS OBJETIVO COSTE TIEMPO REQUISITOS OBJETIVO COSTE TIEMPO REQUISITOS OBJETIVO

7 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved OBJETIVO: garantizar la satisfacción del cliente y darle una solución. No sólo es necesario aportarle una solución sino que ésta solución debe implantarse en un tiempo y con unos costes acordados. Para asegurar estos plazos y costes se realizan una serie de actividades relacionadas con la gestión del proyecto. A.1. Objetivo de la gestión - ¿Cuál? (2/2) A. Introducción Gestión Proyectos

8 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 7 A.2. Áreas a gestionar - ¿Cómo? A. Introducción Gestión Proyectos Personas Procesos Tecnología

9 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 8 A.2. Área a gestionar - Procesos A. Introducción Gestión Proyectos Evitar siempre la reinvención de la rueda, tanto en métodos como en herramientas (no es recomendable la improvisación). Analizadas las características del proyecto, los principales procesos a considerar son casi siempre: –Como validamos el cumplimiento de expectativas de nuestro cliente –Como vamos a gestionar los riesgos del proyecto –Como vamos a planificar (definición y seguimiento semanal) –Asociado a la Ingeniería del Software, que ciclo de vida debe ser aplicado, centrándose en dos aspectos fundamentales: La obtención de requerimientos, y la posterior validación en todo el ciclo de vida de que el software cumple con estos requerimientos (revisiones/pruebas y gestión de la configuración) –Como se van a gestionar los costes, no sólo directos, sino también los indirectos (puesto de trabajo, recursos administrativos, bonus/malus proveedor, garantías, formación…).

10 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 9 A.2. Área a gestionar - Personas A. Introducción Gestión Proyectos Una de las principales causas de proyectos fracasados es la mala definición de roles y responsabilidades, tanto a nivel interno como del cliente/usuario, que afloran de manera indirecta (mala valoración, pruebas defectuosas,..) Una buena gestión del proyecto ha de permitir definir, y mantener: –Responsabilidades a nivel de cliente/usuario final: ¿Van a haber resistencias al cambio, o simplemente boicoteadores? ¿Quien define los requisitos es quien va a usar la aplicación? ¿Existen recursos humanos de parte del cliente/organización para abordar el proyecto? –Responsabilidades y funciones del equipo de trabajo: Saber determinar el nivel de compromiso con el proyecto con relación a la criticidad del rol de cada persona. Fijar diferencial capacidades (técnicas y de gestión) con relación a las necesidades del proyecto.

11 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 10 A.2. Área a gestionar - Tecnología A. Introducción Gestión Proyectos Tal vez los aspectos tecnológicos sean los más directamente gestionables por parte del Gestor de Proyectos. De todas maneras, no perder de vista el impacto en: –Procesos: Riesgos tecnológicos, impacto en ciclo de vida del software, costes/ahorros,… –Personas: Formación usuarios finales / no disponibilidad de técnicos capacitados. La tecnología no sólo debe contemplarse como un elemento a aplicar en el producto objeto del proyecto, sino sobre todo, en la mejora de la productividad del propio proyecto, tanto a corto como a medio plazo: –Gestión documental –Herramientas CASE –Planificadores/Simuladores –Herramientas gestión configuración –E-Learning –Teleworking

12 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 11 A.3 Elementos de la Gestión A. Introducción Gestión Proyectos Comunica- ciones Calidad Alcance Planificación Riesgo Finanzas Contrato Recursos

13 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 12 A.3. Elementos de la Gestión TRABAJO EN GRUPO - identificación de factores de éxito A. Introducción Gestión Proyectos

14 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved APARTADO B Creación del Plan de Proyecto

15 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 14 B. Creación del Plan de Proyecto B.0. Componentes del Plan de Proyecto B.1. Definición del ámbito del Proyecto, y gestión de expectativas y requerimientos B.2. Gestión Riesgos B.3. Gestión Calidad B.4. Gestión Planificación B.5. Gestión Equipo Trabajo B.6. Gestión Comunicaiones B.7. Gestión Económíca Índice Objetivo: conocer los diferentes componentes de un Plan de Proyecto, así como sus características principales Finalidad: ser conscientes de que antes de iniciar la ejecución del proyecto es necesario haber creado la versión inicial del Plan, y que dicho Plan es la herramienta para la gestión del mismo a lo largo de su ciclo de vida.

16 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 15 B.0. Componentes del Plan de Proyecto (1/1) B. Creación del Plan de Proyecto El Plan de Proyecto es un conjunto de planes para cada elemento a gestionar, controlados cada uno bajo su propio versionado, cada plan tiene anexados un conjunto de documentos que demuestran la aplicación del mismo. Comunicaciones Presupuesto Equipo Trabajo Planificación Calidad Riesgos Expectativas y requerimientos Componentes Plan Proyecto Comunica- ciones Calidad Alcance Planificación Riesgo Finanzas Contrato Recursos

17 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 16 B.1. Definición del ámbito del Proyecto (1/6) B. Creación del Plan de Proyecto Determinar la dimensión de los tres ejes que definen el objetivo de un proyecto. Se debe tomar como punto de partida el contrato con el Cliente (si existe), o en su defecto el acta de la reunión de lanzamiento/aprobación del proyecto. COSTE TIEMPO REQUISITOS OBJETIVO Han de quedar perfectamente identificados los objetivos de negocio que han decidido la realización de dicho proyecto: –Expectativas y Requisitos del cliente –Fecha límite de implantación asociada a motivos de negocio. –Presupuesto aprobado para este proyecto. Sobre todo, objetivos que no son misión de este proyecto su consecución

18 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 17 B.1. Ámbito del proyecto (2/6) B. Creación del Plan de Proyecto Ejemplos: OBJETIVOS de negocio para realizar el proyecto –Obtener una solución orientada única i exclusivamente a los requisitos del cliente –Facilitar el acceso a la información –Unificar y racionalizar la información –Mejorar el rendimiento del sistema NO son Objetivos –Modelo de datos y acceso a ala información muy costoso –No estandarización de los procesos

19 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 18 B.1. Gestión Expectativas (3/6) B. Creación del Plan de Proyecto Quien tiene la única visión válida de si un proyecto ha sido exitoso o no, es el cliente/s destinatario/s (muchas veces no coincide con el usuario final) En consecuencia, es fundamental que el Gestor del Proyecto tenga explicitadas, dentro de lo posible, las expectativas del cliente/s. Para ello debería ser posible el crear una matriz donde: –Definir cada expectativa en términos de negocio del cliente –Identificar la prioridad de su cumplimiento –Identificar el parámetro objetivamente medible que indica el valor actual, el valor objetivo, así como cuando se prevé obtener dicho valor –Medir periódicamente el valor de dicho parámetro –Definir acciones/responsables asociados al seguimiento de dichas expectativas

20 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 19 B.1. Gestión Requerimientos (4/6) B. Creación del Plan de Proyecto Recoger de una manera formal los requerimientos del cliente que conforman el objeto del proyecto, así como cuales han sido los cambios posteriormente solicitados y aprobados de estos requerimientos originales, son la base que facilita una gestión exitosa. En este capítulo del Plan de Proyecto deben recogerse: –Documentos, o ubicación física o electrónica, que indican cuales son los requisitos originalmente aprobados por el cliente, así como los cambios posteriormente solicitados/aprobados. –Documentos, o ubicación física o electrónica, que recogen la transformación de estos requerimientos en diseño físico, tanto de datos como procesos. Por ejemplo, donde encontrar el modelo conceptual de datos y de procesos, o el modelo lógico de procesos,... –Ubicaciones de los diferentes conjuntos de software y BB.DD.,tanto para el desarrollo, como para la pre-producción (entorno integración). –Versiones de software que hay en producción, indicando el nexo de unión entre cada versión de software con los requerimientos originales del cliente.

21 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 20 B.1. Gestión Requerimientos (5/6) B. Creación del Plan de Proyecto Una buena gestión de requerimientos, y en función de la envergadura del proyecto, necesitará disponer de una serie de herramientas fundamentales: –Herramienta que facilite de manera formal el diálogo cliente – equipo gestor del proyecto –Herramienta CASE adecuada a la metodología seleccionada, y que permite un control de versiones de los diferentes elementos implicados –Herramienta de control de configuración del software y de las BB.DD. –Matriz trazabilidad Requerimientos

22 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 21 B.1. Gestión Requerimientos (6/6) B. Creación del Plan de Proyecto Ejemplo de Matriz de Trazabilidad de Requerimientos:

23 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 22 B.2. Gestión Riesgos (1/9) B. Creación del Plan de Proyecto Definiciones –Riesgo Un posible evento futuro que, si ocurre, puede provocar resultados inesperados. –Riesgos del Proyecto Efecto acumulado de los sucesos con resultado incierto que afectan negativamente a los objetivos del proyecto. –Gestión del riesgo Conjunto de actividades realizadas para la identificación, análisis y control de los riesgos de un proyecto.

24 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 23 B.2. Gestión Riesgos (2/9) B. Creación del Plan de Proyecto Por que es necesaria la gestión del Riesgo? –Los proyectos tienen tendencia a complicarse y a crecer –Cada vez son necesarias más y diversas tecnologías –El número de usuarios es mayor –Los cambios en los negocios cada vez son más radicales Hechos que afectan a la gestión del Riesgo –Construir software es un negocio arriesgado. –Es estándar de la industria es ignorar los riesgos. –La gestión de riesgos cuesta dinero y no se puede demostrar, de antemano, que sea necesaria. –La tendencia natural es posponer las partes más complejas del proyecto.

25 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 24 B.2. Gestión Riesgos (3/9) B. Creación del Plan de Proyecto Frases célebres sobre la gestión de Proyectos –Las Malas noticias no mejoran con el tiempo. –Lo que no está escrito en un papel, no se ha dicho.

26 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 25 B.2. Valoración y Control (4/9) Gestión de Riesgos Valoración de Riesgos Control de Riesgos Identificación de Riesgos Análisis de Riesgos Priorización de Riesgos Planificación de la Gestión Resolución de Riesgos Monitorización de Riesgos B. Creación del Plan de Proyecto

27 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 26 Identificación de los Riesgos –Se debe mantener un inventario de los riesgos identificando la causa y el efecto que tendrá. –Las fuentes pueden ser muy diversas, como sesiones de Brainstorming, datos de Consultores, Análisis Causa-Efecto, Herramientas, etc. –Nuestras fuentes son las Suposiciones realizadas al recoger los requerimientos, el plan de trabajo (camino crítico) y el análisis de los Costes esperados. Análisis de los Riesgos –Se identifica cuándo puede ocurrir, el impacto que puede tener, la probabilidad de que ocurra y la proximidad al núcleo del proyecto. – Nosotros utilizamos un método cualitativo, asignando las letras A (bueno) a D (malo) a cada concepto. B.2. Gestión Riesgo: Identificación y Análisis (5/9) B. Creación del Plan de Proyecto

28 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved Riesgo con alto Impacto 27 B.2. Gestión Riesgo: Priorización (6/9) B. Creación del Plan de Proyecto Tiempo Estamos aquí PrimerRiesgo a mirar Riesgo de Bajo Impacto (Cerca del Núcleo) (LejosdelNúcleo) D C B A Probability D C C B B B D A A Proximidad

29 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 28 Planificación de la gestión de riesgos –Contiene qué acciones se realizarán para Estabilizar o Desensibilizar el proyecto de los efectos de, al menos, los 10 riesgos principales, quién las ejecutará y en que momento. –Adicionalmente el plan deberá contener los criterios de éxito de la acción así como los procedimientos de monitorización y los eventos que deben disparar las alarmas. Monitorización de riesgos –Se realiza una revisión continua e individualizada de las acciones planificadas para eliminar o mitigar los riesgos principales. –Se realizan revisiones periódicas para ver si aparecen nuevos riesgos o se pueden modificar los resultados del análisis de los riesgos –Los encargados de riesgos deben estar alerta sobre los riesgos y evitar que estos sean ignorados. B.2. Gestión Riesgo: Control y monitorización (7/9) B. Creación del Plan de Proyecto

30 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 29 TRABAJO EN GRUPO - identificación de riesgos B.2. Gestión Riesgo (8/9) B. Creación del Plan de Proyecto

31 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 30 Problemas más comunes en proyectos de desarrollo de Software –Estimaciones inferiores Si no se valoran los proyectos de forma adecuada, el resultado final puede ser entre un 100% y un 250% mayor de lo previsto. –Gestión del ámbito Los proyectos de software tienden a crecer durante el tiempo. Se puede esperar un crecimiento del tamaño de un 1% mensual. –Pérdida de esfuerzo Puede que todo el tiempo invertido no sea productivo por una baja calidad del tiempo (interrupciones, ruido ambiental, etc.), por rotación o por realizar reuniones demasiado largas –Bajo rendimiento La productividad es un factor clave que puede verse alterada por la complejidad del proyecto, uso de nuevos lenguajes y tecnologías, herramientas de soporte no adecuadas o necesidad de invertir en procesos de mejora. B.2. Gestión Riesgo: Trabajo en Grupo (9/9) B. Creación del Plan de Proyecto

32 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 31 B.4. Componentes - Gestión Calidad (1/5) B. Creación del Plan de Proyecto Dentro del Plan de Proyecto de calidad deben contemplarse tres aspectos básicos: –La definición de los estándares seleccionados, los cuales han de cubrir desde el ciclo de vida / metodología que se va a utilizar para el proyecto, hasta aspectos fundamentales de diseño, programación, documentación… –El plan de control de configuración, tanto del software como de la documentación utilizada. Es fundamental tener una eficiente gestión de cambios, y poder asociar cada versión de software/documento con el requerimiento aprobado por el cliente. –El plan de revisiones de conformidad, así como el resultado de su ejecución, para validar que: la ejecución del proyecto se ciñe a los estándares elegidos se está diseñando/programando/probando/implantado/manteniendo exclusivamente en base a los requerimientos formalmente aprobados.

33 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 32 B.4. Componentes - Gestión Calidad (2/5) B. Creación del Plan de Proyecto Actual Futuro Fallos Defectos Testing Prevención Ahorro Tiempo, Coste, Esfuerzo ¿Cuál es el coste de la Inversión? ¿Vale la pena para este proyecto?

34 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 33 B.4. Componentes - Gestión Calidad (3/5) B. Creación del Plan de Proyecto COSTECOSTE De Proyectos De Implantación Calidad ¿ T I E M P O ? Costes de un proyecto = Del desarrollo + De la implantación + Del mantenimiento Porque es necesario una buena gestión de la cualidad: no repetir el mismo error más de una vez seguir unos estándares del proyecto o del cliente, previenen defectos minimizar los costes/tiempo/esfuerzo a consumir en el tiempo es clave para conseguir el objetivo del proyecto

35 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 34 B.4. Componentes - Gestión Calidad (4/5) B. Creación del Plan de Proyecto Para poder evaluar la calidad del proyecto es necesario disponer de medidas que no puedan ayudar a ver si se están consiguiendo los objetivos del proyecto. Las métricas más usuales en la gestión de proyectos son: –Número de Recursos –Tamaño o estimación del proyecto –Defectos, que incluyen los resultados de las revisiones de calidad de los productos –Cambios

36 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 35 B.4. Componentes - Gestión Calidad (5/5) B. Creación del Plan de Proyecto Ejemplo del plan de métricas básicas para el proyecto

37 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 36 B.6. Componentes - Gestión Planificación (1/4) B. Creación del Plan de Proyecto Este apartado del Plan de Trabajo es el que requiere la mayor atención del Jefe de Proyecto, pero hay que evitar el perder de vista el resto de capítulos (enfoques) del dicho Plan. Dependiendo de la envergadura del proyecto, o del nivel de experiencia del Jefe de Proyecto en el manejo de planificaciones, esta tarea podría recaer en el grupo de Planificación y Control. En líneas generales, tal y como se verá en el capítulo C de este curso, el ciclo de vida de un plan de trabajo se inicia con la valoración y la posterior obtención de la planificación base con un horizonte hasta el final del proyecto, pero periódicamente (semanalmente) debe de recogerse el nivel de actividad incurrido de cada recurso, replanificar toda la parte no ejecutada del proyecto analizando el efecto de las medidas correctoras a aplicar en caso de desviaciones, y obtener el plan de trabajo para cada recurso a realizar en el periodo (semana) siguiente.

38 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 37 B.6. Componentes - Gestión Planificación (2/4) B. Creación del Plan de Proyecto En este apartado del Plan de Proyecto debe de recogerse: –La valoraciones de los requerimientos del cliente (ver detalle en capítulo C) –Los diferentes planes de trabajo iniciales elaborados a partir de estas valoraciones y de la metodología utilizada, así como de las restricciones de tiempo asociadas. –La diferentes versiones de dichos planes de trabajo, aunque normalmente con la planificación base y con la planificación actual es suficiente. –Los indicadores de actividad, o partes de trabajo, de cada período (semanales). –El análisis de las principales desviaciones de cada período, y las medidas particulares previstas a aplicar o aplicadas. Finalmente, destacar que el enfoque de la planificación no puede ser el mismo para un proyecto cerrado (construcción/implantación nuevo sistema),que para un proyecto parcialmente abierto (mantenimiento de una aplicación) –En el primer caso este irá orientado a tareas/fechas, incorporando/desincorporando recursos a medida que sea necesario. –Mientras que en el segundo caso, la planificación irá orientada a la capacidad de los recursos disponibles, fijando la finalización de las tareas en función de estas capacidades.

39 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 38 B.6. Componentes - Gestión Planificación (3/4) B. Creación del Plan de Proyecto

40 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 39 B.6. Componentes - Gestión Planificación (3/4) B. Creación del Plan de Proyecto

41 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 40 B.7. Componentes - Gestión Equipo Trabajo (1/6) B. Creación del Plan de Proyecto Roles y Responsabilidades Definición de Roles y Responsabilidades Organizational Breakdown Structure Infraestructura Plan de Reasignación/ Adquisición de Recursos Requerimientos de Plantilla Plan de Recursos (Personas) Relación de Conocimientos Plan de Desarrollo del Equipo Plan de Reconocimiento Este capítulo del Plan de Trabajo se encontrará condicionado por la política de RR.HH. que impere en la empresa. No obstante, en mayor o menor medida, será indispensable detallar los siguientes aspectos del proyecto:

42 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 41 B.7. Componentes - Gestión Equipo Trabajo (2/6) B. Creación del Plan de Proyecto S S S S S Definición Roles: Es fundamental que en un proyecto cada miembro del equipo de trabajo tenga claras sus responsabilidades. En el cuadro siguiente se define las responsabilidades de algunos de los miembros de un equipo : FunciónResponsabilidadesPersona(s) Especialista en la gestión de requerimientos (RM) Definidas por la versión vigente de GSCM y los estándares vigentes en el SC para la función del miembro del equipo. Además: -Interlocutor válido para los compromisos con el cliente -Responsable para las peticiones de desarrollo pequeñas y medianas Jefe Proyecto Especialista en el aseguramiento de calidad (QA) Definidas por la versión vigente de GSCM y los estándares vigentes en el SC para la función del miembro del equipo. Además: -Participa en las revisiones del proceso y auditorías de QA -Participa y puede liderar las revisiones de productos Jefe Proyecto Analista B Especialista en la gestión de configuración (CM) Definidas por la versión vigente de GSCM y los estándares vigentes en el SC para la función del miembro del equipo. Además: -Da soporte al resto del equipo en las actividades del control de cambios y versiones -Realiza las revisiones de las Baselines según lo planificado en el Plan de gestión de configuración Analista A Analista B

43 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 42 B.7. Componentes - Gestión Equipo Trabajo (3/6) B. Creación del Plan de Proyecto S S S S S En el cuadro siguiente se muestra un ejemplo de una distribución roles/responsabilidades de un proyecto:

44 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved B.7. Componentes - Gestión Equipo Trabajo (4/6) B. Creación del Plan de Proyecto Requerimientos Plantilla: A partir de la planificación del proyecto, se debe analizar la necesidad de recursos por perfiles profesionales, así como cual ha de ser la evolución de la pirámide durante la vida del proyecto. Es importante el saber calcular, a partir del número equivalente de recursos obtenidos de la planificación del proyecto, los recursos que realmente son necesarios en función del % de utilización de los mismos. –%Utilización = (Horas Disponibles - Formación - Bajas - Vacaciones) / Horas Disponibles Por ejemplo, en el cuadro siguiente, cada mes será necesario prever un recurso más por mes.

45 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved B.7. Componentes - Gestión Equipo Trabajo (5/6) B. Creación del Plan de Proyecto En el momento de la asignación de personas a las diferentes funciones derivadas de la planificación del proyecto, dado que el encaje ideal casi nunca se da, será necesario planificar una serie de acciones para conseguir dicho encaje, pasando por la formación, la recompensa de sobreesfuerzos no productivos... Reconocimiento al Empleado Formación Desarrollo de Carrera

46 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved B.7. Componentes - Gestión Equipo Trabajo (6/6) B. Creación del Plan de Proyecto Infraestructura: Finalmente, para que los niveles de productividad estén dentro de los previstos en la planificación del proyecto, los medios al alcance del equipo de trabajo han de ser los adecuados, y su nivel de disponibilidad tan elevado como el que suele exigirnos el cliente. Dentro de estos recursos hay que contemplar: –Hardware y software base, tanto de servidores como de redes –Hardware y software particular para el desarrollo del proyecto –Servicios de soporte de calidad suficiente para resolución de incidencias, alta usuarios, tareas administrativas… –Puestos de trabajo: mesa, teléfono, … En consecuencia, si las particularidades del proyecto difieren de los estándares imperantes para el resto de proyectos, será necesario planificar las acciones particulares a implantar

47 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 46 B.8. Componentes - Gestión Comunicaciones (1/3) B. Creación del Plan de Proyecto Los elementos a considerar para crear un plan eficaz de comunicaciones son: – Determinar qué debe ser comunicado – Describir el contenido de cada elemento de comunicación – Documentar el propósito – Documentar a qué audiencia va dirigido – Documentar la frecuencia y el lugar – Documentar el medio elegido – Documentar el responsable de cada item de comunicación – Documentar el responsable de la distribución – Documentar la cantidad estimada y el coste Como principales outputs del plan de comunicaciones hay que considerar: – El informe periódico de avance del proyecto a compartir con el cliente. – La estructura de actas y relación de compromisos derivados – La sesión mensual con el equipo de trabajo

48 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 47 B.8. Componentes - Gestión Comunicaciones (2/3) B. Creación del Plan de Proyecto TRABAJO EN GRUPO - elementos de un plan de comunicación

49 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 48 B.8. Componentes - Gestión Comunicaciones (3/3) B. Creación del Plan de Proyecto Por lo tanto, en este capítulo del Plan del Proyecto, se deberán definir: –Estructuras y frecuencia de los principales informes, tanto internos como hacia el cliente –Responsables de la elaboración de los contenidos –Circuitos de aprobación de dichos informes, o de los contenidos de las presentaciones Finalmente, no basta con describir los elementos del plan de comunicaciones, sino que en este capítulo del Plan del Proyecto deben de almacenarse, o indicar donde pueden ser localizados, lo elementos de comunicación elaborados en el transcurso del proyecto, destacando la relación de actas/compromisos derivados de las múltiples sesiones de trabajo.

50 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 49 B.9. Componentes - Gestión Económica (1/3) B. Creación del Plan de Proyecto Al igual que en el resto de capítulos del Plan de Proyecto, en este se deberá de: –Describir los procedimientos/métodos utilizados para realizar el análisis del grado de avance económico del proyecto –Asignar los responsables de realizar dicho análisis, y de determinar acciones correctoras para corregir las desviaciones en el plano económico –Documentar periódicamente, a partir de los procedimientos descritos, el estado de salud económica del proyecto No hay que dar por supuesto que un proyecto con desviaciones en plazos tiene desviaciones económicas, o que la inexistencia de desviaciones en esfuerzo/plazo es un indicativo de que económicamente el proyecto va bien.

51 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 50 B.9. Componentes - Gestión Económica (2/3) B. Creación del Plan de Proyecto Ejemplo del seguimiento económico de un proyecto planificado para el año 2004 al cerrar el mes de Febrero Estos datos, por si solos, no son indicativos de si el proyecto va bien o no. Deben analizarse conjuntamente con el resto de métricas

52 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 51 B.9. Componentes - Gestión Económica (2/3) B. Creación del Plan de Proyecto Ejemplo del seguimiento de las métricas del proyecto

53 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved APARTADO C Ciclo de vida en la Gestión del Proyecto

54 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 53 C. Ciclo de vida de la Gestión de un Proyecto C.0. Introducción C.1. Definición ámbito y valoración esfuerzo C.2. Planificación C.3. Seguimiento y control C.4. Cierre Índice Objetivo: Describir las cuatro etapas del ciclo de vida de la gestión de un proyecto Finalidad: Conocer en cada fase del ciclo de vida las principales actividades a realizar

55 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 54 C.0 Introducción C. Ciclo de vida de la Gestión de un Proyecto

56 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 55 C. Ciclo de vida de la Gestión de un Proyecto ¿Cómo se lleva a cabo la estimación de un proyecto de software? –1º Se estima el tamaño del producto –2º Se estima el esfuerzo –3º Se estima la planificación –4º Se da un intervalo de estimación y se refina periódicamente C.1. Definición ámbito y valoración esfuerzo Estimación tamaño Estimación esfuerzo Estimación planificación Refinamiento de la planificación Puntos Función Desglose Tareas Persona/mesNúmero meses

57 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 56 Definición del ámbito –Amplitud y profundidad del conjunto de prestaciones –Complejidad y dificultad del producto –Fundamental una excelente gestión de los requerimientos Registrar las diferentes versiones de software asociadas a los cambios en los requerimientos del cliente Estimación del tamaño del producto –Enfoque algorítmico partiendo de las prestaciones del producto –Software de estimación partiendo de la descripción de las prestaciones del producto –Antecedentes: a partir de la estimación de antiguos proyectos La medida exacta de proyectos anteriores es clave de éxito a largo plazo, utilizando cualquier tipo de estimación C.1. Definición ámbito y valoración esfuerzo C. Ciclo de vida de la Gestión de un Proyecto

58 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 57 Es una medida sintética bastante exacta para medir el tamaño de un Sistema de Información. Su objetivo es obtener una medida de las unidades a producir, aunque se puede llegar a deducir el esfuerzo en horas asociado a dicha producción. Características –El cálculo de las unidades de medida de producción es independiente del entorno técnico y de las herramientas de programación –Se basa en funciones, facilidades y características que conoce y pide el que establece los requerimientos –Los PF se calculan después de que los requerimientos se plasmen en el Análisis Funcional –El cálculo puede ser llevado a cabo por personal de perfil no técnico C.1. Definición ámbito y valoración esfuerzo - PUNTOS FUNCION C. Ciclo de vida de la Gestión de un Proyecto

59 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 58 Cálculo de PF –Calcular PF desajustados (PFD) –Calcular Factor Ajuste del Valor (FAV) –Calcular los PF ajustados (PFA) PF de desarrollo (proyecto): PFA = PFD * FAV C.1. Definición ámbito y valoración esfuerzo - PUNTOS FUNCION C. Ciclo de vida de la Gestión de un Proyecto

60 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 59 Proceso de recuento de PFD –Si hemos de aplicar técnicas de análisis y diseño estructurado, cerrar el Diseño Funcional de contexto y el modelo conceptual de datos –Clasificar todas las estructuras de datos dentro de los 5 tipos de función requeridos por el usuario (Entrada, Salida, Consultas, Ficheros Internos, Ficheros Externos) –Clasificar,según los criterios a aplicar a cada tipo de función, en uno de los 3 niveles de complejidad de procesamiento de información (A/M/B), todas las estructuras de datos. –Por cada tipo de función/nivel de complejidad, contar el número de estructuras de datos, y aplicar factor de peso a cada combinación para obtener PFD C. Ciclo de vida de la Gestión de un Proyecto C.1. Definición ámbito y valoración esfuerzo - PUNTOS FUNCION

61 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 60 SALIDAS CONSULTAS FICHEROS EXTERNOS Todas las estructuras de datos se agrupan en 5 tipos de función C. Ciclo de vida de la Gestión de un Proyecto C.1. Definición ámbito y valoración esfuerzo - PUNTOS FUNCION ENTRADAS FICHEROS INTERNOS SISTEMA DE INFORMACION

62 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 61 C.1. Definición ámbito y valoración esfuerzo - PUNTOS FUNCION C. Ciclo de vida de la Gestión de un Proyecto Por ejemplo: Clasificación del tipo de función FLI (fichero lógico interno) según complejidad funcional Clasificación individual de las estructuras de datos según la complejidad funcional

63 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved Factor de peso fijo Número de ocurrencias según complejidad funcional 62 C. Ciclo de vida de la Gestión de un Proyecto Tipos de función Entradas Salidas Consultas Ficheros lógicos internos Ficheros de interfaz externos Total PFD sin ajustar Baja 6 x 3 = 18 7 x 4 = 28 0 x 3 = 0 5 x 7 = 35 9 x 5 = Media 2 x 4 = 8 7 x 5 = 35 2 x 4 = 8 2 x 10 = 20 0 x 7 = 0 Alta 3 x 6 = 18 0 x 7 = 0 4 x 6 = 24 3 x 15 = 45 2 x 10 = 20 C.1. Definición ámbito y valoración esfuerzo - PUNTOS FUNCION

64 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved Comunicación de datos Proceso distribuido Rendimiento Configuraciones ampliamente utilizadas Volumen de transacciones Entrada interactiva de datos Diseño orientado a la eficiencia del usuario final C.1. Definición ámbito y valoración esfuerzo - PUNTOS FUNCION C. Ciclo de vida de la Gestión de un Proyecto Actualización interactiva Complejidad de los procesos Reutilización Facilidad de instalación Facilidad de operación Ubicación múltiple Facilidad de cambios GIT = GI Criterios de Ajuste para obtener el Grado de Influencia (GI) NO PRESENTA INFLUENCIA 1 - INFLUENCIA INCIDENTAL 2 - INFLUENCIA MODERADA 3 - INFLUENCIA MEDIA 4 - INFLUENCIA SIGNIFICATIVA 5 - INFLUENCIA FUERTE Tabla de valores para estimar el G.I. de cada criterio

65 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 64 C. Ciclo de vida de la Gestión de un Proyecto Tipos de función Entradas Salidas Consultas Ficheros lógicos internos Ficheros de interfaz externos Total PFD sin ajustar FAV = 0,65 + (0,01 x GIT) PFA = PFD * FAV Baja 6 x 3 = 18 7 x 4 = 28 0 x 3 = 0 5 x 7 = 35 9 x 5 = , Media 2 x 4 = 8 7 x 5 = 35 2 x 4 = 8 2 x 10 = 20 0 x 7 = 0 Alta 3 x 6 = 18 0 x 7 = 0 4 x 6 = 24 3 x 15 = 45 2 x 10 = 20 C.1. Definición ámbito y valoración esfuerzo - PUNTOS FUNCION

66 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 65 Existen otros sistemas para la valoración del esfuerzo/tamaño –Recuento del número de componentes de software –Recuento del número de líneas de código (sin contar con las líneas de comentarios) –Existen herramientas más modernas (algunas empresas se han especializado en este tema y son requeridas por empresas de servicios para ayudar en este tema). –Ejemplo de sistema de valoración de un proyecto de mantenimiento, que se utiliza en EDS. C. Ciclo de vida de la Gestión de un Proyecto C.1. Definición ámbito y valoración esfuerzo - OTROS

67 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 66 C.2. Planificación C. Ciclo de vida de la Gestión de un Proyecto

68 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 67 C.2. Planificación C. Ciclo de vida de la Gestión de un Proyecto Planificación –Sitúa el desarrollo informático en un calendario concreto, usando recursos asignados y disponibles y teniendo en cuenta todas las relaciones externas del proyecto Variables de la planificación –Las tareas y su coste de estimación –El perfil necesario para la realización según la estimación –La ordenación de las tareas en el tiempo según la metodología –Las personas del equipo y su disponibilidad –El calendario con todas sus constantes –La relación de dependencia con otras tareas externas –La estrategia global de la planificación: calendario vs. recursos

69 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 68 C.2. Planificación C. Ciclo de vida de la Gestión de un Proyecto La Planificación da respuesta a las siguientes preguntas –Qué hay que hacer –Cómo debe hacerse –Quién debe hacerlo –Cuándo hay que hacerlo –Cuánto va a costar –Cómo tiene que ser de bueno –Qué rendimiento se requiere –Qué puntos fuertes tiene –Qué puntos débiles –Qué oportunidades –Qué amenazas Puntos clave –Nivel de detalle –Técnica de aproximación –Herramientas de apoyo –Seguimiento/Refinamiento semanal –Flexibilidad/Agilidad al cambio –Apoyarse en experiencias de proyectos similares

70 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 69 C.2. Planificación C. Ciclo de vida de la Gestión de un Proyecto Errores usuales –Trabajar sin un plan es la esencia del planteamiento desordenado –No tengo tiempo para planificar –No sabemos adónde nos dirigimos, pero vamos a llegar muy rápidos –No implicar en el proceso de planificación a los ejecutores del plan –Olvidar que las personas no producen 8h al día, 20 días al mes, 12 meses al año (vacaciones,formación, bajas, falta formación, asignación a otras actividades, …..) –Creer que vamos a gestionar los recursos externos como si fueran internos (disponibilidad usuarios, otros proveedores, ….) –Inexistencia de la Gestión de Cambios, sobre todo por el impacto en la planificación en la fase de ejecución del proyecto

71 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 70 C.2. Planificación - Deficiente gestión de cambios C. Ciclo de vida de la Gestión de un Proyecto Insatisfacción del Cliente Los Antídotos El Pozo Planificación Excedida Coste Excedido Beneficio Reducido Baja Moral de Equipo Retrabajo en aumento Baja Calidad Gestión de la Configuración Alertar al equipo de los peligros Simplemente decir no Fuente - Cursos PM2 EDS

72 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 71 C.2. Planificación C. Ciclo de vida de la Gestión de un Proyecto Pasos en la planificación –Definir el problema que debe resolver el proyecto (OBJETIVOS) –Elaborar una estructura de desglose del trabajo –Calcular la duración, necesidades de recursos y costes de la actividad –Preparar el calendario del proyecto y el presupuesto –Definir técnicas y herramientas de planificación y control –Decidir la estructura organizativa del proyecto –Conseguir la aceptación de la Planificación

73 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 72 Estructura de Descomposición del Trabajo Técnica para hacer o refinar la estimación del esfuerzo y del coste de un proyecto Identificación y definición de las tareas en las que se descompone un proyecto Descomposición jerárquica con 6 niveles de estructura: –Programa total –Proyecto –Tarea –Subtarea –Paquete de trabajo –Actividad o nivel de esfuerzo C.2. Planificación – Desglose de Tareas C. Ciclo de vida de la Gestión de un Proyecto

74 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 73 Objetivo: Reducir el proyecto a tareas que, individualmente puedan ser definidas, presupuestadas, planificadas, asignadas y controladas Ventajas –Buena definición del trabajo (especificación) –Asignación de recursos necesarios –El esfuerzo requerido para su realización –Coste total y coste por tarea –Un programa de trabajo por periodos (p.e., semanal) –Asignación de responsabilidades –Una visión global del alcance del proyecto C.2. Planificación - Desglose de Tareas C. Ciclo de vida de la Gestión de un Proyecto

75 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 74 C.2. Planificación - Desglose de Tareas Modelo C. Ciclo de vida de la Gestión de un Proyecto FASE SUBFASE ACTIVIDAD PROYECTO TAREA FASE Nivel 2 Nivel 3 Nivel 4 Nivel 5 Nivel 6

76 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 75 C.2. Planificación - Desglose de Tareas Ejemplo C. Ciclo de vida de la Gestión de un Proyecto PINTURA INTERIOR SUSTITUCION DEL TEJADO MOVER MUEBLES CUBRIR SUELOS PINTAR ELEGIR PINTURA MEZCLARAPLICAR REFORMA VIVIENDA JARDINERIA Nivel 2 Nivel 3 Nivel 4 Nivel 5 TAPAR VENTANAS QUITAR ÁRBOLES INSTALAR RIEGO PLANTAR ARBUSTOS

77 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 76 C.2. Planificación - Desglose de Tareas Proyecto C. Ciclo de vida de la Gestión de un Proyecto Nivel 2 Nivel 3 Nivel 4 Nivel 5 AnálisisConstrucción An. Modelo datosEntrada datosSalida datos PantallaCodificar programaPruebas integradas Compra entradas por cajero Dibujar pantalla Puesta en marcha Nivel 6

78 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 77 Catálogo de Actividades –Adicionalmente a las propias derivadas del método de Ingeniería de Software seleccionado: Análisis y Diseño Programación y prueba unitaria Pruebas de integración, de rendimiento y de usuario Pase a explotación y seguimiento post-arranque –Deben contemplarse con el mismo grado de precisión: Las asociadas a la gestión del proyecto: Gestión plan de trabajo, controles de calidad (revisiones formales), informes de progreso,... Las asociadas a la gestión del cambio: Documentación, Formación, Atención HelpDesk... Las asociadas a la infraestructura tecnológica: Instalación y tunning de sistemas y de elementos de comunicaciones, … C.2. Planificación - Desglose de Tareas C. Ciclo de vida de la Gestión de un Proyecto

79 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 78 EN FASE DE ESTIMACION Las cargas de trabajo por elemento de realización Las competencias requeridas Las posibilidades de paralelismo Los medios materiales que van a utilizarse La duración de la realización Los costes de la realización y las inversiones necesarias C.2. Planificación - Desglose de Tareas C. Ciclo de vida de la Gestión de un Proyecto EN FASE DE PLANIFICACION Ordenar cronológicamente las tareas Asignar un responsable y los recursos necesarios Determinar su duración Definir las fechas Calcular los márgenes Calcular las cargas por participante

80 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 79 C.2. Planificación - Programación del proyecto C. Ciclo de vida de la Gestión de un Proyecto Sistemas de Programación –Diagramas de GANTT: Henry Gantt ã Nos muestra las interrelaciones entre tareas dentro de su secuencia temporal –Sistema PERT: Performance Evaluation and review technique –Sistema CPM: Critical Path Method ã PERT y CPM son similares ya que contemplan la relación entre actividades ã PERT usa métodos probabilísticos basados en estadística y CPM no –El camino crítico es un método de programación que determina el camino más largo para obtener la fecha más temprana

81 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 80 C.2. Planificación - Programación del proyecto C. Ciclo de vida de la Gestión de un Proyecto Sistemas de Programación - Diagrama de GANTT

82 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 81 C.2. Planificación - Programación del proyecto C. Ciclo de vida de la Gestión de un Proyecto PERT- Red de Actividades –Componentes: Origen y Extremo Arcos o Flechas Nudos o Sucesos Duración –La Red es una representación lógica del proyecto –La Red se construye estableciendo para cada actividad: cuáles la preceden, cuáles la siguen, cuáles pueden hacerse simultáneamente –El Camino es la sucesión de actividades que permiten ir de un suceso a otro –Las actividades críticas definen el camino crítico de la Red

83 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 82 C.2. Planificación - Programación del proyecto C. Ciclo de vida de la Gestión de un Proyecto Sistemas de Programación - PERT

84 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 83 C.2. Planificación - Programación del proyecto C. Ciclo de vida de la Gestión de un Proyecto PRINCIPIO D E F A (20,2) B (20,0) C (10,2) (15,5) (10,2) (14,2) FIN OTM=0 OTR=0 OTM=20 OTR=25 OTM=35 OTR=35 OTM=49 OTR=49 CTM=0 CTR=5 CTM=20 CTR=25 CTM=35 CTR=35 CTM=20 CTR=20 CTM=0 CTR=0 CTM=20 CTR=39 OTM=20 OTR=20 OTM: OCURRENCIA MÁS PRONTO POSIBLE OTR: OCURRENCIA MÁS TARDE POSIBLE CTM: COMIENZO MÁS PRONTO POSIBLE CTR: COMIENZO MÁS TARDE POSIBLE Sistemas de Programación - CPM

85 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 84 C.2. Planificación - Cálculo de la programación C. Ciclo de vida de la Gestión de un Proyecto Cálculo de la programación –1º Se construye la Red partiendo del desglose de Tareas –2º Se calcula el camino crítico –3º Se observa si la duración total del proyecto encaja entre las fechas establecidas ã El camino crítico esté dentro del margen de fechas ã El camino crítico sea más largo de lo esperado y deba ser acortado –Redes secuenciales y Redes escalonadas ã Elementos de Espera y Desfase

86 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 85 C.2. Planificación - Uso del planificador C. Ciclo de vida de la Gestión de un Proyecto Fases de la planificación de un proyecto –Planificación del proyecto ã Definición de objetivos ã Determinación de la secuencia (constricciones temporales) ã Asignación de recursos necesarios ã Programación del proyecto (calendario) –Control y seguimiento de la ejecución ã Actualizar información ã Controlar el uso de recursos ã Ajustar la planificación (correcciones) ã Ordenar la información

87 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 86 C.2. Planificación - Uso del planificador C. Ciclo de vida de la Gestión de un Proyecto Planificador –El planificador es una herramienta para planificar y controlar la ejecución de proyectos, permitiendo actualizar la información y presentar el estado del proyecto –Formatos Formulario Tabla Diagramas gráficos ã GANTT ã CPM/PERT ã Recursos

88 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 87 C.2. Planificación - Uso del planificador C. Ciclo de vida de la Gestión de un Proyecto División en partes del proyecto Tiene como misión facilitarnos la planificación Colección de tareas de fácil evaluación Técnica TOP-DOWN –División del proyecto en unidades recurrentes –Similar al EDT Establecimiento de relaciones entre tareas Tomar cada tarea y comparala con el resto del proyecto Posibles relaciones: –Finish-to-Start –Start-to-Start –Finish-to-Finish Tras esta fase se obtiene una visión clara del calendario

89 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 88 C.2. Planificación - Uso del planificador C. Ciclo de vida de la Gestión de un Proyecto Asignación de recursos a las tareas Especificación de quiénes y con qué materiales deberán realizar las tareas Planificación dirigida por los recursos –La duración de las tareas dependerá de la cantidad de recursos que dispongamos para ella, y de la productividad de dichos recursos –La duración del proyecto dependerá de la utilización que hagamos de los recursos Planificación de duración fija –La duración de cada tarea es fija –Es independiente de los recursos que se le asignen

90 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 89 C.2. Planificación - Uso del planificador C. Ciclo de vida de la Gestión de un Proyecto Asignación de calendarios de trabajo –Pretende tener en cuenta cuáles van a ser los días en los que se va a trabajar y con qué horario –Primero se crea un calendario base para el proyecto y calendarios particulares para cada recurso o grupos de recursos Análisis y optimización de la planificación –Es un proceso con un alto grado de realimentación –Observar con mucha atención el camino crítico y las holguras de las tareas para evitar los retrasos Total Stack Free Stack

91 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 90 C.2. Planificación - Uso del planificador C. Ciclo de vida de la Gestión de un Proyecto Seguimiento de la ejecución de un proyecto –Pretende evaluar en cada momento la situación real del proyecto: ã Desviaciones en tiempo y coste ã Análisis de la causas ã Evaluación de los recursos ã Evaluación de las consecuencias de los cambios planteados –Se desarrolla en 3 pasos: ã Establecimiento de un plan de ejecución a partir de la planificación del proyecto ã Actualización periódica de la planificación ã Preparación de la situación actual del proyecto con la planificación inicial que se realizó para él

92 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 91 C.2. Planificación C. Ciclo de vida de la Gestión de un Proyecto TRABAJO EN GRUPO - planificación proyecto

93 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 92 C.3. Seguimiento y Control C. Ciclo de vida de la Gestión de un Proyecto

94 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 93 Objetivo: Cumplir con el objetivo del proyecto Valor añadido a largo plazo: Conocimiento Instrumentos necesarios –Comité de Seguimiento ã Impulsar el desarrollo de los Sistema de Información ã Decidir acciones de alto nivel ã Garantizar el compromiso del usuario –Técnicas y herramientas de seguimiento ã La planificación ã El registro de consumos y la previsión del estimado que falta ã La supervisión de tareas y productos ã El informe de progreso y los documentos de presentación C.3. Seguimiento y Control C. Ciclo de vida de la Gestión de un Proyecto

95 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 94 Características del Control –Evaluar el grado de avance en el proceso productivo del sistema –Evaluar el grado de calidad del sistema en base a los resultados intermedios obtenidos –Identificar las desviaciones que se producen o se producirán en los 2 aspectos de la construcción: el proceso y el producto –Comunicar el impacto en recursos, plazos, alcance y productividad del proyecto –Reflexionar sobre los factores de riesgo –Facilitar la toma de decisiones correctas en el ámbito del proyecto y otras de rango superior C.3. Seguimiento y Control C. Ciclo de vida de la Gestión de un Proyecto

96 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 95 El control se logra comparando dónde estamos y dónde se supone que debemos estar ¿Qué es el control? Saber donde estamos, cómo estamos, donde deberíamos estar ¿Qué se controla? Planificación, tareas, grado avance,.. ¿Cómo se controla? Diferentes métodos ¿Cuáles son los componentes de un sistema de control? Depende de la herramienta utilizada para el control (horas imputadas por tarea, componentes de software, dedicaciones, fechas,..) –El control se ejerce de acuerdo a un Sistema de realimentación C.3. Seguimiento y Control C. Ciclo de vida de la Gestión de un Proyecto PROCESO REALIMENTACION Entradas Salidas

97 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 96 El control debe concebirse como información y no como poder ( es necesario que sea consultable por los miembros del equipo, sobretodo los analistas) Hay que controlar el trabajo por cumplimiento de objetivos, no a los trabajadores Un directivo ejerce el control únicamente cuando todos y cada uno de los miembros de la estructura de su equipo controlan su propio trabajo ¿Cómo delegar en las personas? –Es necesario fomentar su COMPLICIDAD –Se delegan tareas no responsabilidades –Definición clara de lo que deben hacer cada uno de los miembros del equipo (fechas inicio/fin, tiempo de ejecución, requerimientos bien definidos, objetivos, como se relaciona su trabajo con el trabajo de los demás miembros del equipo,...) –Un plan personal de cómo hacer el trabajo C.3. Seguimiento y Control C. Ciclo de vida de la Gestión de un Proyecto

98 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 97 –Supervisión/realimentación sobre los progresos (es muy importante informar de los errores y corregirlos en el momento en que se descubren a las personas que han realizado el trabajo para prevenir su repetición. Además descubrir errores en fase de análisis es menos costoso que en fase de construcción y aún menos costoso que en fase de puesta en marcha) –Capacidades y recursos adecuados –Definición clara de su autoridad La dirección de proyectos no es sólo un conjunto de herramientas, es también una disciplina y sólo será un éxito si las personas están bien dirigidas C.3. Seguimiento y Control C. Ciclo de vida de la Gestión de un Proyecto

99 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 98 No puede haber control si no se realiza una evaluación, y por lo tanto se cuenta con medidas precisas El análisis de la varianza o valor acumulado mide el progreso de un proyecto Varianza es cualquier desviación respecto a un plan que debe ser sometida a seguimiento –Varianza de coste: compara desviaciones de coste real y presupuestado –Varianza de programa: compara el trabajo planificado ya terminado con el trabajo real Las variables para realizar las mediciones son –Coste presupuestado del trabajo programado (CPTP) –Coste presupuestado del trabajo realizado (CPTR) –Coste real del trabajo realizado (CRTR) Varianza de coste = CPTR - CRTR Varianza de programa = CPTR - CPTP C.3. Seguimiento y Control - Análisis del valor acumulado C. Ciclo de vida de la Gestión de un Proyecto

100 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 99 C.3. Seguimiento y Control - Análisis del valor acumulado C. Ciclo de vida de la Gestión de un Proyecto Informe de situación del proyecto

101 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 100 C.3. Seguimiento y Control - Actividades de seguimiento (1/7) C. Ciclo de vida de la Gestión de un Proyecto Orden de trabajo (lunes) Captura de información (jueves) Análisis del progreso (viernes) Valoración de problemas (viernes) Reuniones de seguimiento (quincena) Informe de seguimiento interno/externo (mensual)

102 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 101 C.3. Seguimiento y Control - Actividades de seguimiento (2/7) C. Ciclo de vida de la Gestión de un Proyecto Orden de trabajo (lunes) – Objetivos del trabajo – Fechas previstas para su realización – Persona que debe realizar la tarea – Dedicaciones presupuestadas para la persona y tarea – Encuadre de la tarea dentro del Desglose del Proyecto – Especificaciones y requisitos

103 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 102 C.3. Seguimiento y Control - Actividades de seguimiento (3/7) C. Ciclo de vida de la Gestión de un Proyecto Captura de información (jueves) – Identificación de la persona – Código de la tarea – Dedicaciones consumidas – Dedicaciones Pendientes – Fecha de inicio real – Fecha de fin real – ¡¡Ojo a los cambios de requerimientos en fase de ejecución!!

104 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 103 C.3. Seguimiento y Control - Actividades de seguimiento (4/7) C. Ciclo de vida de la Gestión de un Proyecto Análisis de progreso (viernes) – Por cada tarea y proyecto completo – Fechas de inicio y final previstos – Fecha de comienzo real – Fecha programada de finalización – Dedicación presupuestada – Dedicación consumida – Responsable y resultado – Calidad del producto

105 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 104 C.3. Seguimiento y Control - Actividades de seguimiento (5/7) C. Ciclo de vida de la Gestión de un Proyecto Valoración de problemas (viernes) – Analizar causas de los problemas y desviaciones – Grado importancia en relación al proyecto – Decidir acciones correctivas – Impacto – Prever desviaciones – Detectar nuevos factores de riesgo

106 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 105 C.3. Seguimiento y Control - Actividades de seguimiento (6/7) C. Ciclo de vida de la Gestión de un Proyecto Informe de seguimiento – Comprensión general de los objetivos – Conocimiento del progreso de tareas y de necesidades de coordinación – Planificación más realista, adaptada a las nuevas necesidades – Detección temprana de problemas potenciales y del retraso en el proyecto – Valorar el grado de avance del proyecto – Enumerar los cambios en los requerimientos del cliente que afectan a la planificación, objetivos,.. – Enumerar los nuevos factores de riesgo y revisar el estado de los anteriores

107 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 106 C.3. Seguimiento y Control - Actividades de seguimiento (7/7) C. Ciclo de vida de la Gestión de un Proyecto Reuniones de seguimiento – Motivar a los participantes en la consecución de los objetivos (complicidad) – Clarificar y coordinar los diferentes puntos de vista – Resolver los conflictos planteados – Revisar las prioridades de los trabajos – Reconducir la marcha del proyecto – Revisar el método de trabajo – Analizar desviaciones y proponer alternativas de solución

108 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 107 C.4. Cierre C. Ciclo de vida de la Gestión de un Proyecto

109 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 108 C.4. Cierre del Proyecto C. Ciclo de vida de la Gestión de un Proyecto ¿Cuando puede darse por cerrado un proyecto? ¿Cuando se realiza el pase a producción? ¿Cuando se paga/cobra la última factura? ¿Cuando finaliza la garantía? ¿Cuando los temas pendientes se dejan para una Fase II?

110 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 109 C.4. Cierre del Proyecto - Proceso de Cierre C. Ciclo de vida de la Gestión de un Proyecto Cierre del Contrato Cierre del Proyecto Revisión Post- Proyecto

111 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 110 C.4. Cierre del Proyecto - Cierre del Contrato C. Ciclo de vida de la Gestión de un Proyecto Asegurar que se han cumplido los requerimientos del contrato Terminar los entregables del contrato Identificar, documentar y resolver los temas pendientes derivados del cierre del contrato Realizar la aceptación formal de la finalización del contrato (por parte del cliente) Archivar la documentación del contrato

112 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 111 C.4. Cierre del Proyecto - Finalización formal del proyecto C. Ciclo de vida de la Gestión de un Proyecto Comunicar el cierre del proyecto Actualizar el Plan de Recursos Recoger las métricas finales Completar la Revisión Final de Aseguramiento de la Calidad Actualizar estándares y procedimientos de la organización Realizar el cierre financiero Archivar el Plan del Proyecto

113 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 112 C.4. Cierre del Proyecto - Revisión Post-Proyecto C. Ciclo de vida de la Gestión de un Proyecto Preparar la revisión a partir de los datos asociados a las expectativas del cliente tanto de calidad, como de uso, como de Business Plan Realizar la revisión y documentarla. Comunicar el resultado de la misma, así como el plan de acciones correctoras, si se ha detectado alguna. Cerrar/Prorrogar formalmente el período de garantía

114 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved APARTADO D Gestión de la Calidad

115 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved D.0. Introducción D.1. El proceso de mejora de la calidad. Modelos de referencia D.2. Ejemplo de implantación en EDS Catalunya. D.3. Plan de Calidad del proyecto D.3.1 Plan de Calidad D.3.2 Plan de Métricas D.3.3 Plan de Gestión de Configuración Objetivo: Demostrar que las buenas prácticas asociadas a la Gestión de Proyectos, emanan de un modelo de Gestión de Calidad completo y orientado a la ingeniería del software, así cómo ver la materialización de algunas de dichas prácticas dentro de los proyectos. Finalidad: Presentar dos modelos de referencia de gestión de calidad, relacionando sus puntos débiles y fuertes desde el punto de vista de la gestión de proyectos de software. Presentar los planes de proyecto relacionados con la función de Aseguramiento de Calidad. D. Gestión de la Calidad Índice

116 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved Calidad …..es algo que inventaron un día un grupo de empleados aburridos y que consiste en generar papeles, muchos papeles, cantidades ingentes de papeles….para justificar que se está haciendo algo cuando en realidad no se hace nada -- Dilbert. D.0 Introducción

117 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved A todos los Gestores se les exige: –Reducción de costes. –Mayor productividad. –Aprovechar las oportunidades del mercado global. –Fidelizar las relaciones Cliente/Proveedor: Orientación a resultados: Acordes del nivel de servicio (SLA) Orientación al beneficio mutuo: Relaciones WIN-WIN No obstante el entorno profesional es cada vez más complejo –Impacto creciente de les aplicaciones en el negocio –Tiempo de desarrollo más corto. –Visibilidad y control del proyecto: calendario, costes y defectos –Herencia histórica: Poca documentación existente de procesos. D.0 Introducción

118 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved Su mejora continua se mide a partir de las variables: planificación / costes / defectos PERSONAS TECNOLOGIA La calidad del SW viene directamente determinada por la calidad de los procesos utilizado para su desarrollo PROCESOS D.0 Introducción

119 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved ¿Que procesos deben mejorarse? De gestión del proyecto: Planificación, Expectativas, Riesgos, Seguimiento, Cierre. De desarrollo : Análisis, Codificación, testing... De gestión de la configuración : Versiones, Control de cambios... De gestión de la calidad : Programa de Métricas, Calendario revisiones…. De gestión de proveedores …. D.0 Introducción

120 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved Objetivo principal: tener un plan de gestión de la calidad para Empezar a dar pequeños pasos en la mejora de los procesos de software Mejorar la planificación del tiempo de entrega de un producto Tener el flujo de trabajo controlado Disminuir el coste de mantenimiento del SW Tener datos objetivos sobre el estado del producto en cada momento: Nivel de Calidad D.0 Introducción

121 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved Algunos datos: Ratio del coste que se consume en la resolución de errores según la etapa de ejecución del proyecto donde se descubre el error D.0 Introducción ETAPACOSTE RELATIVO RESOLUCIÓN Definición requerimientos1 Diseño3.5 Desarrollo10 Pruebas50 Post-entrega170 Los errores de SW cuestan anualmente a la economía norteamericana (según datos de junio del 2004): 62 billones de dólares

122 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved La Calidad: aspectos fundamentales D.0 Introducción Mejoras continuadas del proceso Procesos de Alta calidad Producto de alta calidad COMUNICACIÓN Micromejoras, porqué: - Para que no sean imposibles - Para que no se vean como imposibles - Para que se entiendan - Para que se puedan compatibilizar con el trabajo diario Comunicación, aspecto clave para el éxito: - Explicar, aclarar y justificar (qué se va a hacer, porqué, cómo,..) - A quién comunicar (equipo desarrollo, responsables superiores, usuarios) - Comunicar y saber escuchar - Persuadir, motivar, orientar,….

123 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved D.0. Introducción D.1. El proceso de mejora de la calidad. Modelos de referencia D.2. Ejemplo de implantación en EDS Catalunya. D.3. Plan de Calidad del proyecto D.3.1 Plan de Calidad D.3.2 Plan de Métricas D.3.3 Plan de Gestión de Configuración D.1 Modelo de Referencia

124 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved ¿ Por qué un modelo ? ¿ Qué modelo ? 1.ISO International Organization Standardization 2.CMM Software Capability Maturity Model D.1 Modelo de Referencia

125 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved Modelo general de aseguramiento de la calidad del diseño, desarrollo, producción, instalación y servicio post-venta. En consecuencia, para el software, necesita ser complementado con guías específicas. – ISO : Guías para la aplicación de la ISO 9001 al desarrollo, suministro y mantenimiento del SW. – Otras guías prácticas de ayuda: TickIT: (UK) guía de ayuda a la interpretación de estas. SEDISI: Guia para la Calidad según ISO 9001 D.1 Modelo de Referencia ISO

126 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved Amplio reconocimiento internacional Gran difusión en las TIC –(a2000) cerca de 7000 certificaciones ww Frecuentemente por requerimientos de clientes Procesos Software, Hardware, Servicios…. 20 Capítulos Requisitos mínimos. D.1 Modelo de Referencia ISO

127 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved Falta de detalle (genérico) Procesos de auditoria poco estandarizados Alineamiento objetivos mayor orientación certificación La mejora... de los propios capítulos de la norma D.1 Modelo de Referencia ISO

128 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved SPICE ISO (actual) Software Process Improvement and Capability Etermination »El objetivo de SPICE es el desarrollo de un estándart internacional para la consultoría en procesos de software, que permite determinar un plan de mejora de los procesos, definiendo detalladamente los riesgos y prioridades, de forma que se pueda determinar el nivel de madurez de los procesos que componen el desarrollo de sw. »Tiene en cuenta la estrategia de negocio del usuario. D.1 Modelo de Referencia ISO

129 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved Capability Maturity Model Define las etapas de evolución de una organización a medida que progresivamente va: Definiendo, gestionando, midiendo, y mejorando sus procesos de desarrollo de software. Originario del Software Engineering Institute (SEI) organización de investigación y desarrollo de software, financiada por el Departamento de Defensa de los Estados Unidos de América y gestionada por la Universidad Carnegie Mellon de Pittsburg. D.1 Modelo de Referencia CMM

130 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved Específico SW Con gran rodaje: evaluado y medido No orientado al diploma Proceso de auditoria: –CBA-IPI ( Common based appraisal for internal process improvement ) –no tan orientado al pie de la letra y más al comportamiento Mayor detalle: 4 Niveles de madurez con áreas Clave (18) que definen objetivos (52) y centenares de prácticas. D.1 Modelo de Referencia CMM

131 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved Sólo actividades Ing. Soft. (no Ing Sist, no Consult.) En proceso de difusión en UE –(Jun 2002) Evaluaciones en ~1750 Org ww Soporte a objetivos de negocio D.1 Modelo de Referencia CMM SW CMM 1.1 CMMI 1.0 (Integrated CMM) Representación por etapas y también continua. Cobertura de actividades de Ing. Sistemas Revisión áreas clave, prácticas...

132 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved Dependencia exclusiva del esfuerzo personal, actuaciones apagafuegos, poca integración de herramientas de soporte, etc... 1 INICIAL Mejora continua. 5 OPTIMIZADO Control estadístico del proceso. 4 GESTIONADO Proceso organizativo estándar, planes de formación, metodologías, etc. 3 DEFINIDO Modelo básico de la gestión de proyectos, gestión de proveedores, gestión de la configuración y calidad. 2 REPETIBLE D.1 Modelo de Referencia CMM

133 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved D.1 Modelo de Referencia CMM ACTIVITIES KEY PRACTICES CONTIENEN DESCRIBEN GOALS KEY PROCESS AREAS ESTRUCTURADOS EN AREAS CLAVE (KPA) ALCANZAN COMMON FEATURES IMPLANTATION INSTITUTIONALIZATION IMPLANTATION INSTITUTIONALIZATION ORGANIZADOS EN CARACTERÍSTICAS COMUNES CONDUCEN PROCESS CAPABILITY INDICAN MATURITY LEVELS NIVELES DE MADUREZ Ejemplo: NIVEL=2 Los cambios a los requisitos se revisan y se incorporan al proyecto… GOAL: Los planes, productos y actividades se mantienen consistentes con los requisitos acordados.... REPETITIBILIDAD IMPLANTATION FOCUS = GESTIÓN DE PROYECTOS Gestión de Requisitos (RM) Gestión de Proyectos (SPP y SPTO) Aseguramiento de Calidad (SQA) Gestión de la Configuración (SCM) Gestión de la subcontratación (SSM) COMMITMMENT ABILITIES ACTIVITIES MEASUREMENT VERIFICATION

134 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved D.1 Modelo de Referencia CMM versus SPICE CMMSPICE Modelo en dos dimensiones (procesos y capacidades de estos procesos) Modelo en una dimensión (define etapas de evolución) 5 niveles de madurez (inicial, repetible, definido, gestionado, optimizado) 6 niveles de capacidad (incomplete, performed, managed, established, predictable, optimizing) 18 áreas clave (kpa: key practice areas) que definen 52 objetivos y centenares de practicas) 6 categorías de procesos con 238 tipos de procesos Se realizan auditorias para revisar el nivel CMM, certifica un nivel final para una organización SPICE, certifica para cada proceso un nivel final, en un proyecto/área determinados

135 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved D.0. Introducción D.1. El proceso de mejora de la calidad. Modelos de referencia D.2. Ejemplo de implantación en EDS Catalunya. D.3. Plan de Calidad del proyecto D.3.1 Plan de Calidad D.3.2 Plan de Métricas D.3.3 Plan de Gestión de Configuración D.2 Ejemplo de Implantación en EDS Cat.

136 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved INGENIERIA DEL SOFTWARE INGENIERIA DEL SOFTWARE GESTIÓN DE PROYECTOS GESTIÓN DE PROYECTOS GSMS 2.0 SW-CMM Objetivos de calidad Proceso estándar EDS Modelo avanzado de gestión de la calidad D.2 Ejemplo de Implantación Estrategia EDS

137 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved 1. Mejora de la gestión de proyectos: Más visibilidad hacia los responsables y hacia la Dirección Mejor control del proceso - parámetros cuantitativos: métricas 2. Mejora del rendimiento: Reducción de defectos y incidencias en producción Mejor capacidad de aprendizaje a partir del proceso estándar 3. Mejora de los resultados: Conseguir o superar las expectativas del Cliente credibilidad Aumentar el beneficio de EDS éxito Model avançat de gestió de la calidad ENGINYERIA DE SOFTWARE GESTIÓ DE PROJECTES GSMS 2.0 SW-CMM Objectius de calidad Procés estàndard EDS D.2 Ejemplo de Implantación Objetivos EDS

138 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved Model avançat de gestió de la calidad ENGINYERIA DE SOFTWARE GESTIÓ DE PROJECTES GSMS 2.0 SW-CMM Objectius de calidad Procés estàndard EDS Modelo avanzado de mejora de los procesos corporativos. Grupo certificado de soporte: CMM Lead Assessors Soporte a la implantación EDS University ofrece formación CMM EDS CMM Assessment Framework Self Assessment Mentored Self Assessment Mini-Assessment Interpretación detallada y global a través de GSMS D.2 Ejemplo de Implantación CMM a EDS

139 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved Ciclos de vida predefinidos Plantillas para los documentos Roles y responsabilidades Herramientas de soporte Aseguramiento calidad Reporting y métricas Control de cambios GSMS Proceso estándar EDS. Grupo de PPI (Performance & Productivity Improvement): realiza el mantenimento y guía la mejora de GSMS Grupo de QA: realiza control y seguimiento de las actividades Model avançat de gestió de la calidad ENGINYERIA DE SOFTWARE GESTIÓ DE PROJECTES GSMS 2.0 SW-CMM Objectius de calidad Procés estàndard EDS Metodología gestión proyectos PM2 Metodología desarrollo SLC3 Metodología gestión de requisitos RDP Metodología gestión de riesgos etc... MODELO DE PROCESOS EDS D.2 Ejemplo de Implantación GSMS

140 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved ? Aseguramiento: GSMS - Proceso estándar EDS Visión del Cliente Control Procesos: 1. Autoevaluaciones 2. Auditorias Control Resultados: 1. Puntos de control 2. Conformance R. Cliente: 1. SLAs Model avançat de gestió de la calidad ENGINYERIA DE SOFTWARE GESTIÓ DE PROJECTES GSMS 2.0 SW-CMM Objectius de calidad Procés estàndard EDS D.2 Ejemplo de Implantación Proyectos

141 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved D.3 Plan de Calidad del proyecto D.0. Introducción D.1. El proceso de mejora de la calidad. Modelos de referencia D.2. Ejemplo de implantación en EDS Catalunya. D.3. Plan de Calidad del proyecto D.3.1 Plan de Calidad D.3.2 Plan de Métricas D.3.3 Plan de Gestión de Configuración

142 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved D.3.1 Plan de Calidad Identificación: -objetivos del proyecto -estándares y normativas aplicables Actividades para su cumplimiento Planning Calidad Aseguramiento Calidad Control Calidad Gestión Calidad del Proyecto Actividades orientadas a la verificación del cumplimiento de los objetivos del proyecto contemplando productos de ingeniería y gestión. Monitorización de resultados para determinar el cumplimiento respecto al sistema de calidad, e identificar defectos y oportunidades de mejora SI NO SABES DONDE IR…. NO HAY CARRETERA QUE TE LLEVE….

143 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved D.3.1 Plan de Calidad Planificación de la Calidad Inputs Política Calidad Descripción Proyecto SLA Objetivos del proyecto Estándares y normativas Técnicas y herramientas 1.Diagramas de flujo 2.Análisis coste-beneficio 3.Benchmarking Outputs Plan de Calidad del Proyecto Checklists Planning Calidad –Objetivos proyecto analizados –Estructura del equipo –Responsabilidades –Procedimientos –Recursos necesarios –Definiciones-Acepciones Identificación: -objetivos del proyecto -estándares y normativas aplicables Actividades para su cumplimiento Planning Calidad Asegurami ento Calidad Control Calidad Gestión Calidad del Proyecto Actividades orientadas a la verificación del cumplimiento de los objetivos del proyecto. Monitorización de resultados para determinar el cumplimiento respecto al sistema de calidad, e identificar defectos y oportunidades de mejora

144 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved D.3.1 Plan de Calidad Aseguramiento de la Calidad Inputs Plan de Calidad del Proyecto Registros de las pruebas, auditorías, control… Técnicas y herramientas 1.Auditorías de Calidad 2.Benchmarking 3.Costes de Calidad Outputs Mejoras de calidad Aseguramiento Calidad Identificación: -objetivos del proyecto -estándares y normativas aplicables Actividades para su cumplimiento Planning Calidad Asegurami ento Calidad Control Calidad Gestión Calidad del Proyecto Actividades orientadas a la verificación del cumplimiento de los objetivos del proyecto. Monitorización de resultados para determinar el cumplimiento respecto al sistema de calidad, e identificar defectos y oportunidades de mejora x x x x

145 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved D.3.1 Plan de Calidad Control de la Calidad Inputs Plan de Calidad del Proyecto SLA Checklists Productos del proyecto Técnicas y herramientas 1.Inspecciones y revisiones 2.Gráficas Charts, Pareto… 3.Diagramas de flujo 4.Análisis estadístico Outputs Mejoras de calidad Checklists completadas Gestión incumplimientos Control Calidad Identificación: -objetivos del proyecto -estándares y normativas aplicables Actividades para su cumplimiento Planning Calidad Asegurami ento Calidad Control Calidad Gestión Calidad del Proyecto Actividades orientadas a la verificación del cumplimiento de los objetivos del proyecto. Monitorización de resultados para determinar el cumplimiento respecto al sistema de calidad, e identificar defectos y oportunidades de mejora

146 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved CheckPoints ¿ Cuando se realizan ? Al final de cada fase (análisis, diseño,...) ¿ Por parte de quien ? Equipo del proyecto ¿ Cómo ? Cuestionario establecido por etapa con los criterios a validar FASE DE ORIGEN FASE DE DETECCIÓN EXPLOTACIÓN D.3.1 Plan de Calidad Ejemplo: Evaluación de productos Conformance Review ¿ Cuando se realizan ? En proyectos de nuevo desarrollo, antes de la entrega a cliente. En proyectos de mantenimiento, periódicamente - cada mes. ¿ Por parte de quien ? Equipo del proyecto conjuntamente con el Jefe de Proyecto ¿ Cómo ? Se verifica que todos los productos entregables son conformes a los requisitos y libres de error. Se verifican todos los puntos de control o CheckPoints

147 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved Objetivo: Verificar de forma independiente la adecuación de las actividades del proyecto a los estándares aplicables. ¿ Cuando se realizan ? Periódicamente / espontáneamente ¿ Por parte de quien ? Responsable: equipo de QA Participantes: auditores (equipo de QA), Project Manager y miembros equipo. ¿ Cómo ? Preparación: definición del ámbito Realización: entrevistas con el equipo de proyecto y análisis de evidencias. Reporting: evaluación, redacción de incumplimientos y mejoras D.3.1 Plan de Calidad Ejemplo: Auditorías de Calidad

148 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved Me gusta el golf Aunque necesitaría mejorar mi técnica Así pues, me auditan el juego Y quizás debo hacer cosas, que pueden parecer no ser de golf Pero, adoptándolas a las características de mi juego... Saqué dos hoyos de ventaja….. D.3.1 Plan de Calidad Ejemplo: Auditorías de Calidad

149 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved D.3.2 Plan de Métricas PLANIFICACIÓNSEGUIMIENTO Y ANÁLISIS BALANCE Y CIERRE GESTIÓN MÉTRICAS PROYECTO NO SE PUEDE CONTROLAR…. LO QUE NO SE PUEDE MEDIR….

150 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved D.3.2 Plan de Métricas Planificación Inputs Plan de Calidad del Proyecto Programa de Métricas Cuadro de Mando PLANIFICA CIÓN SEGUIMIEN TO Y ANALISIS BALANCE Y REPOSITO RIO GESTIÓN MÉTRICAS PROYECTO Técnicas y herramientas 1.Goal Question Metric 2.Relación métricas primitivas estándar Outputs Plan de Métricas ADAPTACIÓN DEL PROGRAMA MÉTRICAS PLANIFICACIÓN, INSTRUCCIONES DE RECOLECCION, PERIODICIDAD, RESPONSABLE, REPORTING, ANALISIS Y DISPARADORES Baseline Planificación Q1 Q2 Q3 m1 m2 m3 m4 G1

151 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved D.3.2 Plan de Métricas Seguimiento y análisis Inputs Plan de Métricas Baseline PLANIFICA CIÓN SEGUIMIEN TO Y ANALISIS BALANCE Y REPOSITO RIO GESTIÓN MÉTRICAS PROYECTO Técnicas y herramientas 1.Repositorio de métricas 2.Control Estadístico 3.Benchmarking 4.Diagramas de flujo - Causa/Efecto Outputs Variabilidad Defectos Escalaciones... Seguimiento y Análisis

152 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved D.3.2 Plan de Métricas Balance y cierre PLANIFICA CIÓN SEGUIMIEN TO Y ANALISIS BALANCE Y REPOSITO RIO GESTIÓN MÉTRICAS PROYECTO Técnicas y herramientas 1.Repositorio de métricas 2.Control Estadístico 3.Benchmarking 4.Diagramas de flujo - Causa/Efecto Outputs Report proceso Repositorio actualizado Balance y cierre Inputs Plan de Métricas Baseline

153 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved D.3.2 Plan de Métricas Ejemplo. Métrica: Size FP (Function Points) – medida del tamaño de las aplicaciones en términos del número de funciones desde el punto de vista del usuario. SLOC (Líneas de Código) – N° de instrucciones representativas de la lógica del conjunto de programas software del producto final. N° Páginas de documentación – medida para determinar el tamaño de los productos documentales creados como soporte al desarrollo y/o entregables. BENEFICIOS CONCRETOS Factor que con las consideraciones tecnológicas adecuadas, puede permitir establecer un referente histórico y/o internacional y hacer posibles comparaciones y análisis. Proporciona el contexto necesario para expresar otras métricas …

154 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved H (Horas) – Proporciona información (a través del seguimiento de imputaciones) de ayuda a la determinación de la productividad Resulta de vital interés a clientes y proveedores por la derivación directa de costes. D.3.2 Plan de Métricas Ejemplo. Métrica: Esfuerzo BENEFICIOS CONCRETOS Mejora de futuras estimaciones Evaluación de la productividad Validación de best practices y procesos de mejora …

155 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved NUM. Personas – Número de personas asignadas a un proyecto durante un periodo determinado. Fuertemente relacionada con Esfuerzo y Duración, proporciona visibilidad respecto a la relación COSTE / CALIDAD / TIEMPO. D.3.2 Plan de Métricas Ejemplo. Métrica: Staff BENEFICIOS CONCRETOS Mejora de la planificación y seguimiento del proyecto: Dimensionamiento Velocidad de cambios (altas/bajas) en el equipo …

156 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved DIAS / HORAS – Proporciona información necesaria para la estimación y control de las actividades Resulta de vital interés a clientes y proveedores por la derivación directa del tiempo de implantación. D.3.2 Plan de Métricas Ejemplo. Métrica: Duración BENEFICIOS CONCRETOS Mejora en la estimación, medida y análisis del ciclo de vida de desarrollo: Etapas Actividades …

157 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved NUM DEFECTOS – Proporciona información para la evaluación de la calidad y de la fiabilidad de los productos. El análisis de defectos proporciona comprensión del proceso de desarrollo, facilitando la focalización de acciones. D.3.2 Plan de Métricas Ejemplo. Métrica: Defectos BENEFICIOS CONCRETOS Mejora de la calidad y de la satisfacción del cliente. Mejora de la información en cuanto a la eficiencia del proceso de desarrollo. Ayuda a la determinación de acciones de mejora. …

158 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved NUM. CAMBIOS – Proporciona información de los cambios que experimenta un proyecto a lo largo del tiempo, facilitando su control y gestión. Proporciona una medida de la volatilidad (frecuencia de cambio) de un sistema respecto a los requisitos. D.3.2 Plan de Métricas Ejemplo. Métrica: Cambios BENEFICIOS CONCRETOS Medida del impacto por cambios de requerimientos en el proyecto. Mejora de la información en cuanto a la eficiencia del proceso de cambios. Ayuda a la determinación de acciones de mejora. …

159 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved D.3.2 Plan de Métricas Métricas informales en entornos no CMM Pizza Productivity Metric – número de cajas de pizza por persona- hombre, como medida del sobreesfuerzo necesario del equipo delante de una mala estimación del proyecto. Aspirin Metric – medida del estrés del equipo durante el desarrollo del proyecto expresado en número de aspirinas tomadas. Beer Metric – número de invitaciones a cañas de cerveza los Viernes tarde, como indicador del factor de frustración del equipo.

160 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved Objetivo: La Gestión de Configuración define una serie de procesos y actividades encaminadas a gestionar la evolución de los Sistemas de Información a lo largo de su ciclo de vida completo, de forma que en todo momento pueda conocerse su estado. En el Plan….contemplamos y describimos las actividades y características particulares dentro del proyecto en cuanto a: a)CONTROL DE LA CONFIGURACIÓN, b)CONTROL DE CAMBIOS, c)GESTIÓN DE LOS REPOSITORIOS Y BASELINES. D.3.3 Plan de Gestión de Configuración

161 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved D.3.3 Plan de Gestión de Configuración Procesos ExtracciónInserción Baseline 1 Baseline 2 Baseline N... ACTIVIDADES DE DESARROLLO Producto 1. Configuración: ¿ Que Baselines? ¿ Que productos pertenecen a cada baseline ? 2. Cambios: ¿ Como se modifican los productos ? 3. Gestión de los repositorios y baselines: ¿ Es coherente, completa, etc.. la baseline ? ¿ Esta definida la función de seguridad de acceso ? Código fuente Clases... Diseño Técnico Programación... Fase Beta Testing... Producto

162 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved D.3.3 Plan de Gestión de Configuración Control de la Configuración Actividades principales Identificación de los elementos de configuración. Se entiende por configuración, el conjunto de PRODUCTOS o elementos que definen un sistema. En esta actividad se determina cuáles de ellos serán productos del sistema tanto iniciales, como intermedios y finales. Codificación de los elementos de configuración. Los elementos de configuración y su documentación asociada, deben de poder ser identificados en todo momento según una codificación que cumpla ciertos requisitos como simplicidad, unicidad y auto-explicación. Identificación de las líneas de base y de los repositorios que las contendrán. El plan de gestión de configuración establece qué líneas de referencia (en qué etapas o fases), y los repositorios que las contendrán junto con sus propiedades de acceso.

163 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved D.3.3 Plan de Gestión de Configuración Control de cambios Actividades principales Gestión de cambios. Delante de cambios, se aplican los procedimientos predefinidos de extracción y inserción. Análisis de impacto. Identificación de las áreas y elementos del proyecto a las que puede afectar un cambio y de qué manera. Evaluación de cambios. Actividades de decisión sobre la viabilidad y conveniencia de la implantación de un cambio (CCB – Comité de control de cambios) Seguimiento e implantación de los cambios autorizados. Una vez que la orden de cambio a la línea base ha sido autorizada por el CCB, el responsable del proyecto realiza la planificación y seguimiento de las actividades necesarias para su implantación.

164 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved D.3.3 Plan de Gestión de Configuración Gestión de los repositorios y baselines Actividades principales Creación y organización de los repositorios. Establecimiento de las medidas de seguridad a aplicar. Verificación y Auditorías periódicas a las baselines para asegurar su completitud y coherencia. Seguimiento de las actividades, accesos, versiones, etc..

165 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved –Production Support Software de la aplicación (código, BBDD, datos, etc.) Requisitos del Cliente (peticiones) –Development + Software de la aplicación (código, BBDD, datos, etc.) Requisitos del Cliente (peticiones) Análisis funcionales Diseños técnicos –Project Workbook, se controlan las versiones y se documentan cambios y estado del documento, pero en general, no se identifica como elemento de configuración. D.3.3 Plan de Gestión de Configuración Ejemplo: Elementos de Configuración

166 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

167 eds.com Lluís Duran Alsina –


Descargar ppt "Gestión de Proyectos Profesores: LLuís Duran, Process Improvement Febrero 2006."

Presentaciones similares


Anuncios Google