PLANIFICACION TEMPORAL Y SEGUIMIENTO DEL PROYECTO

Presentación del tema: "PLANIFICACION TEMPORAL Y SEGUIMIENTO DEL PROYECTO"— Transcripción de la presentación:

1 PLANIFICACION TEMPORAL Y SEGUIMIENTO DEL PROYECTO

2 Apreciación global Describe el proceso de construir y supervisar los tiempos para los proyectos de desarrollo de software. Para construir los sistemas un sistema complejo, muchas tareas de la Ingeniería del Software se realizan en paralelo y el resultado del trabajo desarrollado durante una tarea puede tener un gran efecto en el trabajo a realizar en otra tarea. Es difícil asegurar que un equipo está trabajando en las tareas más apropiadas sino se tiene una planificación detallada.

3 En que consiste... Selección de un modelo adecuado Crear una red de tareas de Ingeniería seguimiento del proyecto Planificación temporal y Ha identificado las tareas de Ingeniería Estimado coste, esfuerzo y tiempo Asignar la responsabilidad para cada tarea “La planificación temporal de un proyecto de software es una actividad que distribuye el esfuerzo estimado a lo largo de la duración prevista del proyecto, asignando el esfuerzo a las tareas especificas de la ingeniería del software” Asegurarse de que se haga

4 Algunas razones por las que el software se entrega tarde(1)
Fecha limite de entrega poco realista, establecida por alguien que no pertenece al grupo de ingeniería de software e impuesta a los gestores y profesionales del grupo. Cambios de los requisitos del cliente que no se reflejan en los cambios de la planificación temporal. Una subestimación honesta de la cantidad de esfuerzo y/o el numero de recursos que serán necesarios para hacer el trabajo. Riesgos predecibles y no predecibles que no son considerados cuando empezó el proyecto.

5 Algunas razones por las que el software se entrega tarde(2)
Dificultades técnicas que no pudieron ser previstas por adelantado. Dificultades humanas que no pudieron ser previstas por adelantado. Falta de comunicación entre la plantilla del proyecto que causa retrasos. Falta de reconocimiento por parte de la gestión del proyecto de su retraso y falta de medidas para corregir el problema.

6 Que hacer con fechas limite poco realistas...
Realice una estimación detallada usando información de proyectos anteriores. Emplear un modelo de proceso incremental, para establecer una estrategia de desarrollo que proporcione una funcionalidad critica mínima para la fecha limite propuesta, pero deje otras funcionalidades para mas tarde. Reúnase con el cliente y explique que la fecha limite impuesta no es realista. Oferte la estrategia de desarrollo incremental como alternativa.

7 Perspectivas de la planificación temporal
En la primera se ha establecido ya (irrevocablemente) una fecha final de entrega de un sistema basado en computadora. La organización del software esta limitada a distribuir el esfuerzo dentro del marco de trabajo propuesto. El segundo punto de vista de la planificación temporal asume que se han estudiado unos limites cronológicos aproximados, pero que la fecha limite será establecida por la organización de la Ingeniería del Software. El esfuerzo se distribuye para conseguir el mejor empleo de los recursos y definir una fecha final después de un cuidadoso análisis del software.

8 Principios de la planificación de proyecto de software (1)
Compartimentación. El producto y el proceso debe descomponerse en un número manejable de actividades y tareas. Interdependencia. Deben separarse tareas que pueden completarse en paralelo de aquéllas que deben ser completados consecutivamente. Asignación de tiempo. A cada tarea se le debe asignar una fecha de inicio y otra de finalización que son funciones de las interdependencias y de si el trabajo se hará a tiempo total o parcial. Validación de esfuerzo. El gerente del proyecto debe asegurar que en cualquier día dado hay suficientes miembros del personal asignados para completar las tareas dentro del tiempo estimado en el plan del proyecto.

9 Principios de la planificación de proyecto de software (2)
Responsabilidades definidas. Cada tarea fijada necesita ser asignada a un miembro del equipo específico. Resultados definidos. Cada tarea programada debe tener un resultado definido, normalmente un producto de trabajo o entregable (diseño de un modelo). Hitos definidos. Todas las tareas o grupos de tareas deberían asociarse con un hito del proyecto. Un hito es conseguido cuando uno o más productos de trabajo de una tarea de la ingeniería han pasado la revisión de calidad.

10 Relación entre las personas y el esfuerzo(1)
Las personas agregadas tardíamente a un proyecto tiene a menudo un efecto negativo, provocando aun más retraso. Ejemplo: -Cuatro IS, pueden producir 5040 LDC individualmente en un año. -La productividad del equipo se ve reducida en 250 LDC/año por cada vía de comunicación (son posibles 6 vías de comunicación)  La productividad del equipo es: 5040 x 4 – (250 x 6) = 18,660 LDC/año. -El proyecto sufre un retraso y a los dos meses de la fecha limite se agregan 2 personas (El numero de vías de comunicación ahora es 15).  La productividad del nuevo equipo es: 5040 x 4 + (840 x 2) – ( 250 x 15 ) = 18,090 LDC/año.

11 Relación entre las personas y el esfuerzo (2)
La relación entre el número de las personas en un proyecto y la productividad global no es lineal (por ejemplo 3 personas no producen 3 veces el trabajo de cada persona, si las personas tienen que trabajar en cooperación entre si). Se tiene la ecuación del software: L = P x E 1/3 t 4/3, donde: E = esfuerzo de desarrollo en persona-mes P = parámetro de productividad (2000 – 12000) t = tiempo del proyecto en meses. L3 Luego : E = , donde: P3 x t4 E = esfuerzo invertido (persona-año) durante el ciclo de vida de desarrollo del software y su mantenimiento. t = tiempo del proyecto en años.

12 Relación entre las personas y el esfuerzo (3)
Ejemplo: Considere un proyecto de software estimado en: L = LDC t = 1.3 años P = (madurez, habilidades equipo, complejidad de la aplicación)  E = (33000)3 / (12000)3 x (1.3)4 = 7.28 Persona-año Si t se establece en 1.7 años  E = (33000)3 / (12000)3 x (1.7)4 = 2.49 Persona-año Esto implica que extendiendo la fecha de finalización en 6 meses, podemos reducir el numero de personas desde 8 hasta 3.

13 Relación entre las personas y el esfuerzo (4)
Las razones principales para usar más de 1 persona en un proyecto es conseguir que el trabajo se realice más rápidamente y a la vez mejorar la calidad del software. Distribución del esfuerzo (Directriz): La regla: 40 – 20 – 40 1. El 40% de todo el esfuerzo o mas se asigna a las tareas de análisis y diseño. Un 20% a la creación de código. 3. Un 40% a las pruebas.

14 Proyecte la distribución del esfuerzo
Relación entre las personas y el esfuerzo (5) Proyecte la distribución del esfuerzo Las pautas generalmente aceptadas son: 2-3% Planeación 10-25% Análisis de requisitos 20-25% Diseño 15-20% Codificación 30-40% Prueba y puesta a punto

15 Tipos de proyecto de software
Definición de tareas para el proyecto de software(1) Tipos de proyecto de software Proyecto de desarrollo del concepto. Se inicia para explorar algún nuevo concepto de negocio o aplicación de nueva tecnología. Proyecto de desarrollo de una nueva aplicación. Se aceptan como consecuencia del encargo de un cliente especifico. Proyecto de mejora de aplicaciones. Ocurre cuando un software existente sufre grandes modificaciones de su funcionamiento, rendimiento o interfaces que son observables por el usuario final. Proyecto de mantenimiento de aplicaciones. Corrigiendo, adaptando, o extendiendo el software existente que pueden ser no obvios para el usuario final . Proyectos de reingeniería. Reconstruyendo un sistema existente en su totalidad o parte.

16 Grado de rigor del proceso de software
Definición de tareas para el proyecto de software(2) Grado de rigor del proceso de software Casual. Se aplican todas las actividades estructurales del proceso, pero se requiere un conjunto de tareas mínimo (tareas, hitos, entregas, puntos de garantía de calidad). Estructurado. Se aplicaran las las actividades estructurales y las tareas relativas apropiadas para el tipo de proyecto, así como las actividades protectoras necesarias para garantizar la calidad (gestión de configuraciones y medición). Estricto. Se aplicara el proceso completo para este proyecto con un grado de disciplina tal que garantice una alta calidad. Reacción rápida. Se aplicara la estructura del proceso a este proyecto, pero debido a una situación de emergencia, solo se aplicaran aquellas tareas esenciales para mantener una alta calidad.

17 Criterios de adaptación del rigor
Definición de tareas para el proyecto de software(3) El gestor del proyecto debe tener criterios de adaptación para seleccionar el grado de rigor apropiado para cada proyecto. Criterios de adaptación del rigor Tamaño del proyecto Número potencial de usuarios Importancia de la misión Antigüedad de la aplicación Estabilidad de los requisitos Facilidad de comunicación cliente/desarrollador Madurez de la tecnología aplicable Limitaciones de rendimiento Características empotradas / no empotradas Personal del proyecto Factores de Reingeniería A cada criterio se le asigna un grado que va desde 1 hasta 5, donde: 1 : requiere un mínimo de subconjunto de tareas, requisitos generales metodológicas y de documentación. 5 : requiere un conjunto completo

18 Calculo del valor selector del conjunto de tareas
Definición de tareas para el proyecto de software(4) Calculo del valor selector del conjunto de tareas Revise cada uno de los criterios de adaptación y asigne los grados apropiados. Revise los factores de ponderación asignado a cada criterio. Están entre 0.8 y 1.2, y proporcionan una indicación de relativa importancia de un criterio de adaptación en particular a los tipos de software desarrollados dentro del entorno local. Multiplique el grado por el factor de ponderación (peso) y por el multiplicador de entrada del tipo de proyecto a realizar. El multiplicador de punto de entrada toma un valor entre 0 y 1 e indica la importancia del criterio de adaptación. El resultado se coloca en la columna producto. Calcule la media de todos las entradas en la columna producto.

19 Calculo del valor selector del conjunto de tareas
Definición de tareas para el proyecto de software(5) Calculo del valor selector del conjunto de tareas CRITERIOS DE ADAPTACION Grado Peso Multiplicador de punto de entrada Producto Concepto Nueva Aplicación Mejora Mantto Reingenieria Tamaño del proyecto 2 1.2 1 2.4 Numero de usuarios 3 1.1 3.3 Importancia para el negocio 4 4.4 Antigüedad 0.9 2.7 Estabilidad de los requisitos Facilidad de comunicación 1.8 Madurez de la tecnología Limitaciones de rendimiento 0.8 Empotrado / No empotrado 3.6 Personal del proyecto 1.0 2.0 Interoperabilidad Factores de reingeniería 0.0 SELECTOR DE CONJUNTO DE TAREAS (SCT) 2.8

20 Calculo del valor selector del conjunto de tareas
Definición de tareas para el proyecto de software(6) Calculo del valor selector del conjunto de tareas Interpretación: Valor del selector del conjunto de tareas Grado de rigor SCT < 1.2 Casual 1.0 < SCT < 3.0 Estructurado SCT > 2.4 Estricto “El solapamiento debe ser eliminado por la experiencia acumulada y el sentido común del gestor del proyecto”.

21 Selección de las tareas de ingeniería de Software(1)
Los proyectos de desarrollo de concepto que tienen éxito evolucionan a menudo en nuevos proyectos de desarrollo de una nueva aplicación. Cuado termina un proyecto de desarrollo de una nueva aplicación, empieza a veces un proyecto de mejora de la aplicación. Esta progresión es natural y predecible y ocurrirá sea cual sea el modelo de proceso que adopte la organización.

22 Selección de las tareas de ingeniería de Software(2)
Los proyectos de desarrollo de concepto se enfocan aplicando las siguientes tareas principales: Ámbito del concepto. Determina el ámbito general del proyecto . Planificación preliminar del concepto. Establece la capacidad de la organización para llevar a cabo el trabajo implicado por el ámbito del proyecto. Valoración del riesgo tecnológico. Evalúa el riesgo asociado con la tecnología a implementar como parte del proyecto. Prueba de concepto. Demuestra la viabilidad de una nueva tecnología en el contexto del software.

23 Selección de las tareas de ingeniería de Software(3)
Los proyectos de desarrollo de concepto se enfocan aplicando las siguientes tareas principales: Implementación del concepto. Implementa la representación del concepto de una manera que pueda revisarlo el cliente y se emplea para propósitos de marketing cuando hay que vender un concepto a otros clientes. Reacción del cliente ante el concepto. Solicita la opinión del cliente sobre un nuevo concepto de tecnología y va encaminada a aplicaciones especificas del cliente.

24 Selección de las tareas de ingeniería de Software(4)
El flujo de las tareas de Ingeniería de Software para proyectos de desarrollo de concepto es poco mas que sentido común. El equipo de software debe entender lo que hay que hacer (ámbito), el equipo o gestor debe determinar si hay alguien disponible para hacerlo (planificación); debe considerar los riesgos asociados al trabajo (valoración del riesgo); probar la tecnología de alguna ,manera (prueba de concepto) e implementarlo en forma de prototipo de manera que el cliente pueda evaluar (implementación del concepto de evaluación del cliente). Finalmente si el concepto es viable, se debe fabricar una versión de producción (traducción).

25 Selección de las tareas de ingeniería de Software(5)
Definición del proyecto Planificación Ingeniería / Construcción Entrega Evaluación del cliente Desarrollo del concepto 1.1 Ámbito de concepto 1.4 Prueba del concepto 1.6 Reacción del cliente 1.2 Planificación preliminar del concepto 1.3 Valoración del riesgo tecnológico 1.5 Implementación del concepto Proyecto de desarrollo de nueva aplicación Proyecto de mejora de la aplicación Mantenimiento de la aplicación Reingeniería Tareas de desarrollo del concepto en un modelo secuencial lineal

26 Definir una red de tareas
Las tareas y subtareas individuales tienen interdependencias basadas en su secuencia. También llamada red de actividades, es una representación grafica del flujo de tareas de un proyecto.

27 Planificación temporal(1)
Herramientas de planificación temporal de proyectos: Técnica de evaluación y revisión del programa (PERT) Método del camino critico (CPM) Estas técnicas son dirigidas por la información ya desarrollada en actividades anteriores de la planificación del proyecto: Estimaciones del esfuerzo Una descripción de la función del producto La selección del modelo de proceso adecuado y del conjunto de tareas. La descomposición de tareas.

28 Planificación temporal(2)
Tanto PERT como CPM proporcionan herramientas cuantitativas que permiten al planificador de software: Determinar el camino critico, constituida por la cadena de tareas que fija la duración del proyecto. Establecer las dimensiones de trabajo mas probable para las tareas individuales aplicando modelos estadísticos. Calcular las limitaciones de tiempo que definen una “ventana” de tiempo de una tarea determinada.

29 Planificación temporal(3)
Limitaciones de tiempo que pueden discernirse de una red PERT o CPM: Lo antes posible que puede empezar una tarea cuando las tareas precedentes se completan también lo antes posible. Lo más tarde que se puede empezar una tarea antes de que se retrase el tiempo mínimo para finalizar el proyecto. La fecha mas temprana de finalización La fecha límite de finalización El margen total. La cantidad de tiempo extra o atrasos permitidos en la planificación temporal de las tareas de manera que el camino critico de la red se mantenga conforme a la planificación temporal.

30 Planificación temporal(3)
Graficas de tiempo: El planificador empieza un conjunto de tareas (descomposición del trabajo). Las entradas de cada tarea son: El esfuerzo Duración Fecha de inicio Se asignan las tareas a individuos específicos. Como resultado se obtiene una “tabla de proyecto”

31 Planificación temporal(3)
Tareas de trabajo Inicio previsto Inicio real Terminación prevista Terminación real Personas asignadas Esfuerzo asignado Observaciones 1.1.1 identificar necesidades y beneficios Es previsible Reunirse con los clientes Sem 1,d1 Sem 1, d1 Sem 1, d2 BLS 2 p-d que requiera Identificar las necesidades y limitaciones Sem 1,d2 JPP 1 p-d mas esfuerzo/tiempo Establecer la declaración del producto Sem 1,d3 Sem 1, d3 BLS/JPP Hito, declaración de producto definida

32 Planificación temporal(3)
Seguimiento cualitativo de la planificación temporal: La planificación temporal del proyecto le proporciona al gestor un mapa de carretera. Si se ha desarrollado apropiadamente, define las tareas e hitos que deben seguirse y controlarse a medida que progresa el proyecto. Se pueden hacer de distintas maneras: Realizando reuniones periódicas del estado del proyecto en las que todos los miembros del equipo informan del progreso y de los problemas. Evaluando los resultados de todos las revisiones realizadas a lo largo del proceso de Ingeniería de Software. Determinando si se han conseguido los hitos formales del proyecto en la fecha programada. Comparando la fecha real de inicio con las previstas para cada tarea del proyecto listada en la tabla de proyecto. Reuniéndose informalmente con los profesionales del software para obtener sus valoraciones subjetivas del progreso.

33 Análisis de valor ganado(1)
Seguimiento cuantitativo de la planificación temporal: Es una medida cuantitativa del progreso. Aclara las dificultades de planificación antes de que ellas puedan aparecer.

34 Análisis de valor ganado(2)
Pasos para determinar el valor ganado: El coste de presupuesto de trabajo planificado (CPTP). Se determina para cada tarea de trabajo que se representa en el plan (durante la actividad de estimación el trabajo de cada tarea de ingeniería de software es convenientemente planificada). CPTPi , es el trabajo que se ha planificado para una cierta tarea i. Calcular el presupuesto a la terminación (PAT). PAT = Sumatoria CPTPk , para todas las tareas k Calcular el coste presupuestado del trabajo desarrollado (CPTD). Es la suma de los valores CPTP para todas las tareas de trabajo que hayan sido realmente terminadas.

35 Análisis de valor ganado(3)
La distinción entre el CPTP y el CPTD es que el primero representa el presupuesto de las actividades que estaban planificadas para ser completadas y el ultimo representa el presupuesto de las actividades que realmente estaban acabadas. Dados los valores para CPTP, PAT, CPTD, podemos calcular los indicadores de progreso: Índice de desarrollo de planificación (IDP): Mide la eficiencia con que el proyecto esta utilizando los recursos de la planificación. IDP = CPTD / CPTP Un valor cercano a 1, indica una ejecución eficiente de la planificación.

36 Análisis de valor ganado(4)
Varianza de la planificación (VP): Es simplemente una indicación absoluta de la varianza de la planificación prevista. VP = CPTD - CPTP Porcentaje planificado para terminar (CPT): Proporciona una indicación del % de trabajo que debería estar terminado en el instante t. CPT = CPTD / PAT Porcentaje completado (PC): Indica el grado de avance en la realización (%) del proyecto en un instante determinado de tiempo t. PC = CPTP / PAT

37 Análisis de valor ganado(5)
Coste real de trabajo realizado (CRTR): Es la suma del esfuerzo realmente desarrollado en tareas de trabajo que hayan sido realizadas en un instante de tiempo de la planificación del proyecto. Índice de desarrollo del coste (IDC): Un valor cercano a 1 indica evidentemente de que el proyecto esta dentro del presupuesto que para el se ha definido. IDC = CPTP / CRTR Varianza del coste (VC): Una indicación absoluta de los ahorros del coste. VC = CPTP - CRTR

38 Seguimiento del error(1)
Permite la comparación de trabajo actual con los proyectos del pasado y proporciona un indicador cuantitativo de la calidad del trabajo. Eficiencia de eliminación de errores: EED = E / ( E + D ) donde: E = errores encontrados durante la tarea de IS D = errores encontrados en tareas posteriores (defectos)

39 Seguimiento del error(2)
Los errores y defectos pueden ser registrados y obtener promedios para nuevas métricas, tales como: Errores por componentes a nivel de diseño, Ediseño. Errores por componentes a nivel de código, Ecódigo. EED-análisis de requisitos EED-diseño arquitectónico EED-diseño a nivel de componentes EED-codificación. A medida que el proyecto progresa a través de cada paso de la ingeniería de software, el equipo de software registra e informa del numero de errores encontrados en los requisitos, diseño y revisiones de código. El gestor calcula los valores actuales para Ecódigo,Ediseño. Estos son después comparados con los promedios anteriores.

40 Plan de proyecto Se produce a la culminación de las tareas de planificación, proporcionando información básica de costes y planificación temporal que será utilizada a lo largo del proceso de software. DEBE: Comunicar el ámbito y recursos a los gestores del software, personal técnico y al cliente. Definir los riesgos y sugerir técnicas de aversión a los riesgos. Definir los costes y planificación temporal para la revisión de la gestión. Proporcionar un enfoque general de desarrollo del software para todo el personal relacionado con el proyecto. Describir como se garantizara la calidad y la gestión de los cambios.

41 Como asegurar que lo ha hecho correctamente...
Una planificación adecuada requiere que: Todas las tareas aparezcan en la red, El esfuerzo y el tiempo se asigne inteligentemente a cada tarea, Las relaciones entre tareas estén indicadas correctamente, Los recursos sean asignados al trabajo a realizar, Los hitos se sitúen rigurosamente espaciados para que se pueda seguir el progreso.