planificacion temporal y seguimiento del proyecto

PLANIFICACION TEMPORAL Y SEGUIMIENTO DEL PROYECTO

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.

En que consiste...

Selección de un modelo

adecuado

Selección de un modelo

adecuado

Ha identificadolas tareas deIngeniería

Ha identificadolas tareas deIngeniería

Estimado coste, esfuerzo y

tiempo

Estimado coste, esfuerzo y

tiempo

Crear una red detareas de Ingeniería

Crear una red detareas de Ingeniería

Asignar laresponsabilidadpara cada tarea

Asignar laresponsabilidadpara cada tarea

Planificación tem

poral yseguim

iento del proyecto

Asegurarse deque se haga

Asegurarse deque se haga

“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”

Algunas razones por las que el software se entrega tarde(1)

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.

2. Cambios de los requisitos del cliente que no se reflejan en los cambios de la planificación temporal.

3. Una subestimación honesta de la cantidad de esfuerzo y/o el numero de recursos que serán necesarios para hacer el trabajo.

4. Riesgos predecibles y no predecibles que no son considerados cuando empezó el proyecto.

Algunas razones por las que el software se entrega tarde(2)

5. Dificultades técnicas que no pudieron ser previstas por adelantado.

6. Dificultades humanas que no pudieron ser previstas por adelantado.

7. Falta de comunicación entre la plantilla del proyecto que causa retrasos.

8. Falta de reconocimiento por parte de la gestión del proyecto de su retraso y falta de medidas para corregir el problema.

Que hacer con fechas limite poco realistas...

1. Realice una estimación detallada usando información de proyectos anteriores.

2. 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.

3. Reúnase con el cliente y explique que la fecha limite impuesta no es realista.

4. Oferte la estrategia de desarrollo incremental como alternativa.

Perspectivas de la planificación temporal

1. 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.

2. 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.

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.

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.

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.

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.


Ejemplo:

Considere un proyecto de software estimado en:L = 33000 LDC

t = 1.3 años P = 12000 (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.


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 deanálisis y diseño.

2. Un 20% a la creación de código.3. Un 40% a las pruebas.

Proyecte la distribución del esfuerzo

Las pautas generalmente aceptadas son:

2-3% Planeación 10-25% Análisis de requisitos 20-25% Diseño15-20% Codificación30-40% Prueba y puesta a punto


Tipos de proyecto de software

1. Proyecto de desarrollo del concepto. Se inicia para explorar algún nuevo concepto de negocio o aplicación de nueva tecnología.

2. Proyecto de desarrollo de una nueva aplicación. Se aceptan como consecuencia del encargo de un cliente especifico.

3. 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.

4. Proyecto de mantenimiento de aplicaciones. Corrigiendo, adaptando, o extendiendo el software existente que pueden ser no obvios para el usuario final .

5. Proyectos de reingeniería. Reconstruyendo un sistema existente en su totalidad o parte.

Definición de tareas para el proyecto de software(1)

Grado de rigor del proceso de software

1. 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).

2. 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).

3. Estricto. Se aplicara el proceso completo para este proyecto con un grado de disciplina tal que garantice una alta calidad.

4. 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.


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


El gestor del proyecto debe tener criterios de adaptación para seleccionar el grado de rigor apropiado para cada proyecto.

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

Calculo del valor selector del conjunto de tareas


1. Revise cada uno de los criterios de adaptación y asigne los grados apropiados.

2. 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.

3. 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.

4. Calcule la media de todos las entradas en la columna producto.



CRITERIOS DE ADAPTACIONCRITERIOS DE ADAPTACION GradoGrado PesoPeso Multiplicador de punto de entradaMultiplicador de punto de entrada ProductoProducto

ConceptoConcepto Nueva Nueva AplicaciónAplicación

MejoraMejora ManttoMantto ReingeniReingenieriaeria

Tamaño del proyectoTamaño del proyecto 22 1.21.2 00 11 11 11 11 2.42.4

Numero de usuariosNumero de usuarios 33 1.11.1 00 11 11 11 11 3.33.3

Importancia para el negocioImportancia para el negocio 44 1.11.1 00 11 11 11 11 4.44.4

AntigüedadAntigüedad 33 0.90.9 00 11 11 00 00 2.72.7

Estabilidad de los requisitosEstabilidad de los requisitos 22 1.21.2 00 11 11 11 11 2.42.4

Facilidad de comunicaciónFacilidad de comunicación 22 0.90.9 11 11 11 11 11 1.81.8

Madurez de la tecnologíaMadurez de la tecnología 22 0.90.9 11 11 00 00 11 1.81.8

Limitaciones de rendimientoLimitaciones de rendimiento 33 0.80.8 00 11 11 00 11 2.42.4

Empotrado / No empotradoEmpotrado / No empotrado 33 1.21.2 11 11 11 00 11 3.63.6

Personal del proyectoPersonal del proyecto 22 1.01.0 11 11 11 11 11 2.02.0

InteroperabilidadInteroperabilidad 44 1.11.1 00 11 11 11 11 4.44.4

Factores de reingenieríaFactores de reingeniería 00 1.21.2 00 00 00 00 11 0.00.0

SELECTOR DE CONJUNTO DE SELECTOR DE CONJUNTO DE TAREAS (SCT)TAREAS (SCT)

2.82.8



Interpretación:

Valor del selector del conjunto de tareas

Grado de rigor

SCT < 1.2SCT < 1.2 CasualCasual

1.0 < SCT < 3.01.0 < SCT < 3.0 EstructuradoEstructurado

SCT > 2.4SCT > 2.4 EstrictoEstricto

“El solapamiento debe ser eliminado por la experiencia acumulada y el sentido común del gestor del proyecto”.

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.

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.


•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.


Los proyectos de desarrollo de concepto se enfocan aplicando las siguientes tareas principales:


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).


Desarrollo del concepto

1.1 Ámbito de concepto

1.2 Planificación preliminar del concepto

1.3 Valoración del riesgo tecnológico

1.4 Prueba del concepto

1.5 Implementación del concepto

1.6 Reacción del cliente

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

Definición del proyecto

Planificación Ingeniería / Construcción

Entrega Evaluación del cliente

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.

start

T2

M3T6

Finish

T10

M7T5

T7

M2T4

M5

T8

4/7/99

8 days

14/7/99 15 days

4/8/99

15 days

25/8/99

7 days

5/9/99

10 days

19/9/99

15 days

11/8/99

25 days

10 days

20 days

5 days25/7/99

15 days

25/7/99

18/7/99

10 days

T1

M1 T3T9

M6

T11

M8

T12

M4

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.


Tanto PERT como CPM proporcionan herramientas cuantitativas que permiten al planificador de software:

1. Determinar el camino critico, constituida por la cadena de tareas que fija la duración del proyecto.

2. Establecer las dimensiones de trabajo mas probable para las tareas individuales aplicando modelos estadísticos.

3. Calcular las limitaciones de tiempo que definen una “ventana” de tiempo de una tarea determinada.


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.


Graficas de tiempo:

1. El planificador empieza un conjunto de tareas (descomposición del trabajo).

2. Las entradas de cada tarea son:

• El esfuerzo

• Duración

• Fecha de inicio

3. Se asignan las tareas a individuos específicos.

Como resultado se obtiene una “tabla de proyecto”


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 Sem 1, d2 BLS 2 p-d que requiera

Identificar las necesidades y limitaciones

Sem 1,d2 Sem 1, d2 Sem 1, d2 Sem 1, d2 JPP 1 p-d mas esfuerzo/tiempo

Establecer la declaración del producto

Sem 1,d3 Sem 1, d3 Sem 1, d3 Sem 1, d3 BLS/JPP 1 p-d

Hito, declaración de producto definida

Sem 1,d3 Sem 1, d3 Sem 1, d3 Sem 1, d3


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:

1.Realizando reuniones periódicas del estado del proyecto en las que todos los miembros del equipo informan del progreso y de los problemas.

2.Evaluando los resultados de todos las revisiones realizadas a lo largo del proceso de Ingeniería de Software.

3.Determinando si se han conseguido los hitos formales del proyecto en la fecha programada.

4.Comparando la fecha real de inicio con las previstas para cada tarea del proyecto listada en la tabla de proyecto.

5.Reuniéndose informalmente con los profesionales del software para obtener sus valoraciones subjetivas del progreso.

Análisis de valor ganado(1)

•Es una medida cuantitativa del progreso.

•Aclara las dificultades de planificación antes de que ellas puedan aparecer.

Seguimiento cuantitativo de la planificación temporal:


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.


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.


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


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

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)

Seguimiento del error(2)

Los errores y defectos pueden ser registrados y obtener promedios para nuevas métricas, tales como:

1. Errores por componentes a nivel de diseño, Ediseño.2. Errores por componentes a nivel de código, Ecódigo.3. EED-análisis de requisitos4. EED-diseño arquitectónico5. EED-diseño a nivel de componentes6. 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.

Plan de proyectoSe 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:

1. Comunicar el ámbito y recursos a los gestores del software, personal técnico y al cliente.

2. Definir los riesgos y sugerir técnicas de aversión a los riesgos.

3. Definir los costes y planificación temporal para la revisión de la gestión.

4. Proporcionar un enfoque general de desarrollo del software para todo el personal relacionado con el proyecto.

5. Describir como se garantizara la calidad y la gestión de los cambios.

Como asegurar que lo ha hecho correctamente...

Una planificación adecuada requiere que:

1. Todas las tareas aparezcan en la red,

2. El esfuerzo y el tiempo se asigne inteligentemente a cada tarea,

3. Las relaciones entre tareas estén indicadas correctamente,

4. Los recursos sean asignados al trabajo a realizar,

5. Los hitos se sitúen rigurosamente espaciados para que se pueda seguir el progreso.

planificacion temporal y seguimiento del proyecto

Documents