Profesores: LLuís Duran, Process Improvement

Profesores: LLuís Duran, Process Improvement
Gestión de Proyectos Title Slide Title is 28 pt. Arial. Subtitle and speaker’s name are 18 pt. Arial. Photo may be customized for your purpose. Photos depict interesting points of view. Photo colors are desaturated for a subtle effect. Profesores: LLuís Duran, Process Improvement Febrero 2006

Gestión de Proyectos Informáticos
Programa 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 Alternate Layout In this layout, place photos on the top or the bottom of the slide. Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

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

A. Introducción a la Gestión de Proyectos Informáticos
ÍNDICE 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 A.1. Objetivo de la gestión A.2. Áreas a gestionar A.3. Elementos de la gestión 4 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

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

A.1. Objetivo de la gestión - ¿Cuál? (2/2)
A. Introducción Gestión Proyectos A.1. Objetivo de la gestión - ¿Cuál? (2/2) 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. Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

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

A.2. Área a gestionar - Procesos 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…). 8 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

A.2. Área a gestionar - Personas 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. 9 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

A.2. Área a gestionar - Tecnología 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 10 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

A.3. Elementos de la Gestión TRABAJO EN GRUPO - identificación de factores de éxito Lista de los factores identificados: Buena planificación Claridad de las especificaciones técnicas Uso de un sistema de comunicación formal (internas y externas) Claras responsabilidades de los miembros del equipo Control de la planificación Utilización de consultores Control del presupuesto Claridad de los objetivos del proyecto Personal bien cualificado Toma de decisiones Estrategia de contrato bien desarrollada Trabajo en equipo efectivo Adecuada integración de hw, sw y personas Liderazgo efectivo Apoyo de la alta dirección Efectiva gestión de los conflictos 12 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

APARTADO B Creación del Plan de Proyecto

B. Creación del Plan de Proyecto
Í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. 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 14 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

B.0. Componentes del Plan de Proyecto (1/1) 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 Contrato Comunica- ciones Planificación Calidad Finanzas Riesgo Riesgos Expectativas y requerimientos Calidad Alcance Componentes Plan Proyecto Recursos Planificación 15 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

B.1. Definición del ámbito del Proyecto (1/6) 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. 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 COSTE TIEMPO REQUISITOS OBJETIVO 16 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

B.1. Ámbito del proyecto (2/6) 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 17 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

B.1. Gestión Expectativas (3/6) 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 18 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

B.1. Gestión Requerimientos (4/6) 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”. 19 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

B.1. Gestión Requerimientos (5/6) 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 20 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

B.2. Gestión Riesgos (1/9) 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. 22 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

B.2. Gestión Riesgos (2/9) 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. 23 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

B.2. Gestión Riesgos (3/9) 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. 24 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

B.2. Valoración y Control (4/9) Gestión de Riesgos Valoración de Riesgos Control de 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 25 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

B.2. Gestión Riesgo: Identificación y Análisis (5/9) 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. 26 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

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

B.2. Gestión Riesgo: Control y monitorización (7/9) 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. 28 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

B.2. Gestión Riesgo: Trabajo en Grupo (9/9) 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. 30 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

B.4. Componentes - Gestión Calidad (1/5) 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. 31 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

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

De Implantación Calidad
B. Creación del Plan de Proyecto B.4. Componentes - Gestión Calidad (3/5) Costes de un proyecto = De Proyectos C O S T E Del desarrollo + De la implantación + Del mantenimiento De Implantación Calidad ¿ T I E M P O ? 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 33 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

B.4. Componentes - Gestión Calidad (4/5) 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 34 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

B.6. Componentes - Gestión Planificación (1/4) 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. 36 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

B.6. Componentes - Gestión Planificación (2/4) 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. 37 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

B.7. Componentes - Gestión Equipo Trabajo (1/6) 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: Roles y Responsabilidades Definición de Roles y ‘Organizational Breakdown Structure’ Requerimientos de Plantilla Plan de Recursos (Personas) Relación de Conocimientos Plan de Desarrollo del Equipo Plan de Reconocimiento Infraestructura Plan de Reasignación/ Adquisición de Recursos 40 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

B.7. Componentes - Gestión Equipo Trabajo (2/6) 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ón Responsabilidades Persona(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) Participa en las revisiones del proceso y auditorías de QA Participa y puede liderar las revisiones de productos Analista B Especialista en la gestión de configuración (CM) 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 S S S S S 41 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

B.7. Componentes - Gestión Equipo Trabajo (3/6) En el cuadro siguiente se muestra un ejemplo de una distribución roles/responsabilidades de un proyecto: S C R A = Responsable del Proceso Aprueba/Acepta los entregables del Proceso Soporte en la creación de los entregables I Necesita Información del ‘status’ y contenido de los entregables Proporciona consultoría o información a los entregables Clave Establecer Equipo del Proyecto Crear el Libro del Proyecto Elaborar el Plan del Proyecto Participantes en el Proyecto Establecer Relaciones Cliente Definir el Alcance del Proyecto Establecer el entorno de Dirección de Proyecto Establecer el Proceso de Gestión de la Configuración Definir Procedim. Financieros Identificar Riesgo del Proyecto Anunciar Proyecto Revisar el Plan del Proyecto Tareas Gestión Gerente Cuenta Jefe Proy. AF’s AP’s Experto Tecnol. Direcc. Financ. Superv. Cliente S S S S S 42 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

B.7. Componentes - Gestión Equipo Trabajo (4/6) 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. Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

B.7. Componentes - Gestión Equipo Trabajo (5/6) 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 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

B.7. Componentes - Gestión Equipo Trabajo (6/6) 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 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

B.8. Componentes - Gestión Comunicaciones (1/3) 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 46 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

B.8. Componentes - Gestión Comunicaciones (3/3) 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. 48 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

B.9. Componentes - Gestión Económica (1/3) 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. 49 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

B.9. Componentes - Gestión Económica (2/3) 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 50 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

APARTADO C Ciclo de vida en la Gestión del Proyecto

C. Ciclo de vida de la Gestión de un Proyecto
Í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 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 53 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.1. Definición ámbito y valoración esfuerzo ¿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 Estimación tamaño Estimación esfuerzo Estimación planificación Puntos Función Desglose Tareas Persona/mes Número meses Refinamiento de la planificación 55 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.1. Definición ámbito y valoración esfuerzo 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 56 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.1. Definición ámbito y valoración esfuerzo - PUNTOS FUNCION 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 57 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.1. Definición ámbito y valoración esfuerzo - PUNTOS FUNCION 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 58 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C. Ciclo de vida de la Gestión de un Proyecto C. 1
C. Ciclo de vida de la Gestión de un Proyecto C.1. Definición ámbito y valoración esfuerzo - PUNTOS FUNCION 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 59 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

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

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

C.1. Definición ámbito y valoración esfuerzo - PUNTOS FUNCION 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 = 45 304 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 Número de ocurrencias según complejidad funcional Factor de peso fijo 62 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.1. Definición ámbito y valoración esfuerzo - PUNTOS FUNCION Criterios de Ajuste para obtener el Grado de Influencia (GI) 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 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 Tabla de valores para estimar el G.I. de cada criterio 63 0 - NO PRESENTA INFLUENCIA 1 - INFLUENCIA INCIDENTAL 2 - INFLUENCIA MODERADA 3 - INFLUENCIA MEDIA 4 - INFLUENCIA SIGNIFICATIVA 5 - INFLUENCIA FUERTE Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.1. Definición ámbito y valoración esfuerzo - PUNTOS FUNCION 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 = 45 304 1,15 350 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 64 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C. Ciclo de vida de la Gestión de un Proyecto C.1. Definición ámbito y valoración esfuerzo - OTROS 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. 65 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.2. Planificación 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 67 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.2. Planificación 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 68 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.2. Planificación 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 69 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

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

C.2. Planificación 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 71 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.2. Planificación – Desglose de Tareas 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 72 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.2. Planificación - Desglose de Tareas 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 73 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

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

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

C.2. Planificación - Desglose de Tareas Proyecto Compra entradas por cajero Nivel 2 Análisis Construcción Puesta en marcha Nivel 3 Nivel 4 An. Modelo datos Entrada datos Salida datos Nivel 5 Pantalla Codificar programa Pruebas integradas Nivel 6 Dibujar pantalla 76 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.2. Planificación - Desglose de Tareas 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, … 77 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

EN FASE DE PLANIFICACION
C. Ciclo de vida de la Gestión de un Proyecto C.2. Planificación - Desglose de Tareas 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 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 78 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.2. Planificación - Programación del 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 79 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.2. Planificación - Programación del 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 81 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

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

C.2. Planificación - Cálculo de la programación 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 84 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.2. Planificación - Uso del planificador 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 85 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.2. Planificación - Uso del planificador 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 86 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.2. Planificación - Uso del planificador 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 87 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.2. Planificación - Uso del planificador 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 88 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.2. Planificación - Uso del planificador 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 89 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.2. Planificación - Uso del planificador 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 90 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.3. Seguimiento y Control 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 93 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.3. Seguimiento y Control 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 94 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.3. Seguimiento y Control 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 PROCESO REALIMENTACION Entradas Salidas 95 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.3. Seguimiento y Control 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 96 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.3. Seguimiento y Control 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 97 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.3. Seguimiento y Control - Análisis del valor acumulado 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 98 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

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

C.3. Seguimiento y Control - Actividades de seguimiento (1/7) 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) 100 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.3. Seguimiento y Control - Actividades de seguimiento (2/7) 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 101 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.3. Seguimiento y Control - Actividades de seguimiento (3/7) 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!! 102 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.3. Seguimiento y Control - Actividades de seguimiento (4/7) 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 103 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.3. Seguimiento y Control - Actividades de seguimiento (5/7) 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 104 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.3. Seguimiento y Control - Actividades de seguimiento (6/7) 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 105 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.3. Seguimiento y Control - Actividades de seguimiento (7/7) 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 106 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.4. Cierre del 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? 108 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

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

C.4. Cierre del Proyecto - Cierre del Contrato 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 110 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.4. Cierre del Proyecto - Finalización formal del 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 111 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

C.4. Cierre del Proyecto - Revisión Post-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 112 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

APARTADO D Gestión de la Calidad

D. Gestión de la Calidad Índice
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.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 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

D.0 Introducción -- Dilbert.
“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. Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

D.0 Introducción 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. Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

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

D.0 Introducción ¿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…. Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

D.0 Introducción 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 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

D.0 Introducción 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 ETAPA COSTE RELATIVO RESOLUCIÓN Definición requerimientos 1 Diseño 3.5 Desarrollo 10 Pruebas 50 Post-entrega 170 Los errores de SW cuestan anualmente a la economía norteamericana (según datos de junio del 2004): 62 billones de dólares Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

D.0 Introducción La Calidad: aspectos fundamentales
Producto de alta calidad Procesos de Alta calidad Mejoras continuadas del proceso 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,…. Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

D.1 Modelo de Referencia 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 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

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

D.1 Modelo de Referencia ISO
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 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

 D.1 Modelo de Referencia ISO 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. Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

 D.1 Modelo de Referencia ISO 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 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

D.1 Modelo de Referencia ISO
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. Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

D.1 Modelo de Referencia CMM
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. Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

 D.1 Modelo de Referencia CMM 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. Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

 D.1 Modelo de Referencia CMM
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 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... Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

D.1 Modelo de Referencia CMM
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 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

INSTITUTIONALIZATION
D.1 Modelo de Referencia CMM Ejemplo: NIVEL=2 PROCESS CAPABILITY INDICAN MATURITY LEVELS NIVELES DE MADUREZ 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) GOALS KEY PROCESS AREAS ESTRUCTURADOS EN AREAS CLAVE (KPA) ALCANZAN COMMON FEATURES IMPLANTATION INSTITUTIONALIZATION ORGANIZADOS EN CARACTERÍSTICAS COMUNES CONDUCEN REPETITIBILIDAD COMMITMMENT ABILITIES ACTIVITIES MEASUREMENT VERIFICATION ACTIVITIES KEY PRACTICES CONTIENEN DESCRIBEN GOAL: Los planes, productos y actividades se mantienen consistentes con los requisitos acordados. ... IMPLANTATION Los cambios a los requisitos se revisan y se incorporan al proyecto… Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

D.1 Modelo de Referencia CMM versus SPICE
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 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

D.2 Ejemplo de Implantación en EDS Cat.
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 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

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

Qualitat 1. Mejora de la gestión de proyectos:
D.2 Ejemplo de Implantación Objetivos EDS de gestió de la calidad Model avançat DE SOFTWARE ENGINYERIA PROJECTES GESTIÓ DE GSMS 2.0 SW-CMM 1.1 Qualitat .... Objectius de calidad EDS Procés estàndard 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 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

Qualitat CMM Lead Assessors D.2 Ejemplo de Implantación CMM a EDS
de gestió de la calidad Model avançat DE SOFTWARE ENGINYERIA PROJECTES GESTIÓ DE GSMS 2.0 SW-CMM 1.1 Qualitat .... Objectius de calidad EDS Procés estàndard 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 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

Qualitat D.2 Ejemplo de Implantación GSMS GSMS Proceso estándar EDS.
de gestió de la calidad Model avançat DE SOFTWARE ENGINYERIA PROJECTES GESTIÓ DE GSMS 2.0 SW-CMM 1.1 Qualitat .... Objectius de calidad EDS Procés estàndard MODELO DE PROCESOS EDS Ciclos de vida predefinidos Plantillas para los documentos Roles y responsabilidades Herramientas de soporte Aseguramiento calidad Reporting y métricas Control de cambios Metodología gestión proyectos PM2 Metodología desarrollo SLC3 Metodología gestión de requisitos RDP Metodología gestión de riesgos etc... 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 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

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

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

D.3.1 Plan de Calidad Planificación de la Calidad Identificación: -objetivos del proyecto -estándares y normativas aplicables Actividades para su cumplimiento Planning Calidad Aseguramiento Calidad Control Gestión 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 Técnicas y herramientas Diagramas de flujo Análisis coste-beneficio Benchmarking ... Outputs Plan de Calidad del Proyecto Checklists Inputs Política Calidad Descripción Proyecto SLA Objetivos del proyecto Estándares y normativas Planning Calidad Objetivos proyecto analizados Estructura del equipo Responsabilidades Procedimientos Recursos necesarios Definiciones-Acepciones Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

Aseguramiento Calidad Aseguramiento Calidad
D.3.1 Plan de Calidad Aseguramiento de la Calidad Identificación: -objetivos del proyecto -estándares y normativas aplicables Actividades para su cumplimiento Planning Calidad Aseguramiento Calidad Control Gestión 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 Técnicas y herramientas Auditorías de Calidad Benchmarking Costes de Calidad ... x x Aseguramiento Calidad Inputs Plan de Calidad del Proyecto Registros de las pruebas, auditorías, control… Outputs Mejoras de calidad Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

D.3.1 Plan de Calidad Control de la Calidad Identificación: -objetivos del proyecto -estándares y normativas aplicables Actividades para su cumplimiento Planning Calidad Aseguramiento Calidad Control Gestión 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 Técnicas y herramientas Inspecciones y revisiones Gráficas Charts, Pareto… Diagramas de flujo Análisis estadístico ... Control Calidad Inputs Plan de Calidad del Proyecto SLA Checklists Productos del proyecto Outputs Mejoras de calidad Checklists completadas Gestión incumplimientos Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

D.3.1 Plan de Calidad Ejemplo: Evaluación de productos
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 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 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

D.3.1 Plan de Calidad Ejemplo: Auditorías de Calidad
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 Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

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

SEGUIMIENTO Y ANÁLISIS
D.3.2 Plan de Métricas GESTIÓN MÉTRICAS PROYECTO PLANIFICACIÓN NO SE PUEDE CONTROLAR…. LO QUE NO SE PUEDE MEDIR…. SEGUIMIENTO Y ANÁLISIS This definition can be found in the Overview section of the S&G. BALANCE Y CIERRE Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

D.3.2 Plan de Métricas Planificación
GESTIÓN MÉTRICAS PROYECTO PLANIFICACIÓN Q1 Q2 Q3 m1 m2 m3 m4 G1 Técnicas y herramientas Goal Question Metric Relación métricas primitivas estándar ... SEGUIMIENTO Y ANALISIS BALANCE Y REPOSITORIO Planificación Outputs Plan de Métricas ADAPTACIÓN DEL PROGRAMA MÉTRICAS PLANIFICACIÓN, INSTRUCCIONES DE RECOLECCION, PERIODICIDAD, RESPONSABLE, REPORTING, ANALISIS Y DISPARADORES Baseline Inputs Plan de Calidad del Proyecto Programa de Métricas Cuadro de Mando Our clients ask us to provide numbers about the effort, duration and quality of our software and nonsoftware outputs. Prediction - Effort, Staff, Duration. A manager needs to be able to estimate work accurately. Costs can be measured on the input side and the output side of the product. We must measure both the input side and output side. Providing a certain amount of effort is not good enough anymore. The business world is concerned with, “what do I get for my money?” The answer to this question is usually provided in functional units. Builders say they will build for $$ per square foot, but what do we provide as size in software products and services? Quality impacts client satisfaction with our products. We need to understand how quality can be measured. On Schedule? Is the project where it should be? How can you be sure? Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

D.3.2 Plan de Métricas Seguimiento y análisis
GESTIÓN MÉTRICAS PROYECTO PLANIFICACIÓN Técnicas y herramientas Repositorio de métricas Control Estadístico Benchmarking Diagramas de flujo - Causa/Efecto .... SEGUIMIENTO Y ANALISIS BALANCE Y REPOSITORIO Seguimiento y Análisis Outputs Variabilidad Defectos Escalaciones ... Inputs Plan de Métricas Baseline Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

D.3.2 Plan de Métricas Balance y cierre
GESTIÓN MÉTRICAS PROYECTO PLANIFICACIÓN Técnicas y herramientas Repositorio de métricas Control Estadístico Benchmarking Diagramas de flujo - Causa/Efecto .... SEGUIMIENTO Y ANALISIS BALANCE Y REPOSITORIO Balance y cierre Outputs Report proceso Repositorio actualizado Inputs Plan de Métricas Baseline 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 … Function Points - measure the size of applications in terms of the number of its delivered software functions. Counted using IFPUG Counting Practices Manual (International Function Point Users Group) Lines of code - source statements of a software product that represent the encoded logic of a final software product. Based on IEEE Standards for Software Productivity Metrics Pages of documentation - is a measure for sizing nonsoftware deliverables which include the collection of named structural units created to support the development or usage of a software product. Based on IEEE standards for Software Productivity Metrics Other size such as modules or scripts can be used, but these kinds of measures cannot be used to compare our productivity with other organizations or industry measures Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

D.3.2 Plan de Métricas Ejemplo. Métrica: Esfuerzo
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. BENEFICIOS CONCRETOS Mejora de futuras estimaciones Evaluación de la productividad Validación de ‘best practices’ y procesos de mejora … This definition can be found in Section 6 of the S&G. Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

D.3.2 Plan de Métricas Ejemplo. Métrica: Staff
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. BENEFICIOS CONCRETOS Mejora de la planificación y seguimiento del proyecto: Dimensionamiento Velocidad de cambios (altas/bajas) en el equipo … This definition can be found in Section 7 of the S&G. Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

D.3.2 Plan de Métricas Ejemplo. Métrica: Duración
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. BENEFICIOS CONCRETOS Mejora en la estimación, medida y análisis del ciclo de vida de desarrollo: Etapas Actividades … This definition can be found in Section 8 of the S&G. Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

D.3.2 Plan de Métricas Ejemplo. Métrica: Defectos
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. 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. … This definition can be found in Section 9 of the S&G. Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

D.3.2 Plan de Métricas Ejemplo. Métrica: Cambios
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. 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. … This definition can be found in Section 10 of the S&G. Stress these definitions. 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. Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

D.3.3 Plan de Gestión de Configuración
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: CONTROL DE LA CONFIGURACIÓN, CONTROL DE CAMBIOS, GESTIÓN DE LOS REPOSITORIOS Y BASELINES. Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

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

D.3.3 Plan de Gestión de Configuración Ejemplo: Elementos de Configuración
Production Support Software de la aplicación (código, BBDD, datos, etc.) Requisitos del Cliente (peticiones) Development + 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. Copyright © 2003 Electronic Data Systems Corporation. All rights reserved

Lluís Duran Alsina – Lluis.Duran@eds.com
Use this slide as the final slide in all presentation decks. If you do not have additional contact or URL information, delete all text except “eds.com.” Lluís Duran Alsina –

Profesores: LLuís Duran, Process Improvement

Presentaciones similares

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

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Profesores: LLuís Duran, Process Improvement

Presentaciones similares

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

Presentaciones similares

Sobre el proyecto

Feedback