Control de prestaciones de un proyecto

Transcripción

1 Temario de la clase Gestión de Proyectos con problemas Control de prestaciones Clasificación de avaance de proyectos Formas de gestionar el término del proyecto Recomendaciones generales Qué hacer cuando nos corresponde hacernos cargo de un proyecto con problemas? Primero distinguir el avance del proyecto Evaluar el impacto del proyecto en la organización Tomar rapidamente alguna desición que active (parte) el proyecto Grados de Avance de un proyecto Proyecto por iniciar Proyecto Avanzado Proyecto por terminar 1

2 Especificación mínima Filtrado de requerimientos Desarrollo por versiones Proyecto Avanzado: Control de cambios de prestaciones Orígenes de los cambios Métodos de control de cambios Proyecto por terminar: Recorte de prestaciones Todos comprenden la necesidad de control de prestaciones pero todos continúan incluyendo tantas prestaciones como puedan en sistemas ya recargados Como si esto fuera poco, debemos agregar el problema de los requerimientos tardíos o el cambio de requerimientos, todos ellos realizados con posterioridad al comienzo del desarrollo del proyecto Los fenómenos hermanos de cambios de última hora y retrasos del proyecto son causa y efecto. Recordemos que la velocidad de desarrollo viene dada por una combinación de personas procesos producto tecnología 2

3 En general existen tres tipos de control de prestaciones de un proyecto de software: Control al principio del proyecto: Definición de prestaciones consistente con los objetivos de planificación y presupuesto. Control a mitad del proyecto: Control de cambios en los requerimientos Control al final del proyecto: Recortando requerimientos (prestaciones) para lograr cumplir plazos o costos. No! ( Alguna duda?) El control de conjunto de prestaciones en la fase inicial de un proyecto consiste principalmente en no introducir requerimientos (prestaciones) innecesarias en el proyecto. En Inside RAD, Kerr y Hunter dicen que el primer mandamiento del desarrollo rápido es «reducir el ámbito». Para lograr esto, existen tres métodos: Especificación mínima Filtrado de requerimientos Desarrollo por versiones 3

4 * Especificación mínima Existen problemas con las especificaciones tradicionales. Esfuerzo desperdiciado en la especificación Obsolescencia Falta de eficacia Diseño excesivamente restringido Solución: Especificación Mínima * Especificación mínima Creación de una especificación mínima Especificación resumida del software (± 10 pags) Especificación del punto de partida Manual del usuario como especificación Prototipo de interfaz de usuario Cuadernos Definición del alcance (Marcar claramente lo que NO es parte del software) Objetivo global del producto 4

5 * Especificación mínima Beneficios de la especificación mínima Mejoras en la moral y la motivación Eficiencia oportunista Menos esfuerzo desperdiciado Fase de requerimiento más corta * Especificación mínima Riesgos en la especificación mínima Omisión de requerimientos clave Objetivos poco claros o imposibles Meticulosidad y requerimientos innecesarios Falta de soporte de actividades paralelas Incremento de la relación del desarrollador con características específicas Uso de una especificación mínima por una razón equivocada 5

6 * Especificación mínima Claves para el éxito en el uso de especificaciones mínimas Usar una especificación mínima sólo cuando los requerimientos sean flexibles Mantener la especificación en un nivel mínimo Capturar los requerimientos importantes Usar métodos flexibles de desarrollo Involucrar a los usuarios claves Centrarse en la documentación gráfica * Filtrado de Requerimientos Claves para el éxito en el uso de especificaciones mínimas Suprimir o filtrar una prestación (requerimiento) es una de las formas más eficaces de reducir la duración y el tamaño de un proyecto de software. Además, el filtrado de requerimientos es menos arriesgado que la especificación mínima, ya que al reducir el tamaño y la complejidad del sistema, reduce también el nivel general de riesgo del producto. 6

7 * Filtrado de Requerimientos Claves para el éxito en el uso de especificaciones mínimas La idea de filtrar es simple. Luego de crear una especificación del software, estudiar la especificación en profundidad con los siguientes objetivos: Eliminar todos los requerimientos que no son absolutamente necesarios. Simplificar los requerimientos que son más complicados de lo necesario. Sustituir con opciones menos costosas todos los requerimientos que dispongan de opciones más económicas. * Desarrollo por Versiones Es una alternativa a las opciones anteriores. Se planifica un conjunto de requerimientos para un proyecto robusto, completo e ideal, pero luego se implementa el proyecto por partes. Los métodos de entrega evolutiva y prototipado se prestan para este enfoque. Normalmente al terminar la versión 1, se detecta que parte de los requerimientos de la versión 2 en realidad no son necesarios y se deben añadir otras, evitando con esto trabajo innecesario y cambios de última hora. 7

8 Proyecto iniciado: Control de cambios en las prestaciones * Orígenes de los cambios Aún cuando se haya hecho un buen trabajo especificando un software claramente, es probable que el proyecto sufra entre un 25 a un 100% modificaciones en sus requerimientos. Los cambios a un proyecto avanzado surgen de varias fuentes: Usuarios, vendedores, ejecutivos, desarrolladores, siendo la principal fuente los usuarios que descubren necesidades adicionales derivadas del medio o de la comprensión del sistema a medida que éste se construye. Proyecto iniciado: Control de cambios en las prestaciones Otros hechos que gatillan cambios son: * Orígenes de los cambios Aplicaciones competitivas Objetivos poco claros Cuando los clientes no saben lo que quieren Cuando se desea ser receptivo con su cliente Cuando el mercado evoluciona rápidamente 8

9 Proyecto iniciado: Control de cambios en las prestaciones * Métodos de control de cambios Como detener los cambios a toda costa no suele beneficiar los intereses del proyecto, la gestión efectiva de cambios se convierte se convierte en algo fundamental para la realización del proyecto. Cambios Proyecto iniciado: Control de cambios en las prestaciones * Métodos de control de cambios Cualquier plan de gestión de cambios, debe incluir al menos los siguientes objetivos: Permitir cambios que ayuden a obtener el mejor producto posible en el tiempo disponible. No permitir ningún otro tipo de cambios. Permitir que todas las partes afectadas por un cambio, estimen los impactos en la planificación, los recursos y el producto. Notificar cada cambio a los miembros del entorno, indicando el impacto estimado y si nivel de rechazo o aceptación. Mantener un registro con las desiciones tomadas y la afectación del producto 9

10 Proyecto iniciado: Control de cambios en las prestaciones * Métodos de control de cambios Tareas de apoyo a la gestión de cambios Para cumplir los objetivos mencionados en la gestión del cambio, es necesario apoyarse en algunas de las siguientes tareas: Análisis de los cambios Versión dos Ciclos cortos de entrega Grupo de control de cambios Análisis conjunto de los cambios Destrío Agrupación Proyecto a punto de terminar: Recorte de prestaciones Gestión de retrasos en la última etapa del proyecto Aunque haya tenido éxito al especificar un conjunto inicial mínimo de prestaciones y controlar los cambios en medio del proyecto, existen muchas razones posibles por las cuales el proyecto puede encontrarse fuera de lo programado. En este caso las medidas recomendables son: Eliminación de prestaciones de baja prioridad Traslado de funcionalidad a Versión dos 10

11 Dudas, Consultas? Presente!! 11