CAPITULO #7PLANIFICACION TEMPORAL Y SEGUIMIENTO DEL PROYECTO

7.1.- CONCEPTOS BASICOS7.1.1.- Comentarios sobre los “Retrasos”7.1.2.- Principios Básicos

7.2.- LA RELACION ENTRE LAS PERSONAS Y EL ESFUERZO7.2.1.- Un Ejemplo7.2.2.- Una Relación empírica7.2.3.- Distribución del esfuerzo

7.3.- DEFINICION DE UN CONJUNTO DE TAREAS PARA EL PROYECTO DE SOFTWARE7.3.1.- Grado de Rigor7.3.2.- Definir los criterios de adaptación7.3.3.- Cálculo del valor selector del conjunto de tareas7.3.4.- Interpretar el valor SCT y seleccionar el conjunto de tareas

7.4.- SELECCIÓN DE LAS TAREAS DE INGENIERIA DEL SOFTWARE

7.5.- REFINAMIENTO DE LAS TAREAS PRINCIPALES

7.6.- DEFINIR UNA RED DE TAREAS

7.7.- LA PLANIFICACION TEMPORAL7.7.1.- Gráficos de Tiempo7.7.2.- Seguimiento de la planificación temporal

7.8.- ANALISIS DE VALOR GANADO

7.9.- SEGUIMIENTO DEL ERROR

7.10.- EL PLAN DEL PROYECTO

CUESTIONES NECESARIAS A TRATAR A LA HORA DE DESARROLLAR SOFTWARE1) Seleccionar un proceso adecuado2) Identificar las tareas de ingeniería del software que hay que llevar a cabo3) Obtener un estimado de la cantidad de trabajo a realizar4) Conocer el número necesario de personas para desarrollar el proyecto5) Conocer las fechas límites de entrega del proyecto6) Considerar los riesgos posibles al momento de elaborarlo

¿CÓMO SOLUCIONAR DICHOS PROBLEMAS DE LA FORMA MÁS INTELIGENTE POSIBLE?1) Crear una red de tareas de ingeniería que permitan conseguir el trabajo a tiempo.2) Asignar responsabilidad para cada tarea3) Asegurarse de que se cumplan y adaptar la red antes de que los riesgos se

conviertan en realidad.

TODO LO ANTERIOR ES LA PLANIFICACION TEMPORAL Y EL SEGUIMIENTO DEL PROYECTO DE SOFTWARE.

Es prácticamente imposible obtener resultados correctos respecto a la medición de cuanto se avanza en un determinado proyecto sin poseer una planificación detallada desde principio del mismo.

¿COMO PUEDO ASEGURARME DE QUE LO HE HECHO CORRECTAMENTE?Una planificación adecuada requiere que:

1) Todas las tareas aparezcan en la red2) El esfuerzo y el tiempo se asignen inteligentemente a cada tarea3) Las relaciones entre tareas estén indicadas correctamente4) Los recursos sean asignados al trabajo a realizar5) Los hitos se sitúen rigurosamente espaciados para que se pueda seguir el progreso.

7.1.- CONCEPTOS BASICOS¿RAZONES PORQUE SE ENTREGAN TARDE LOS PROYECTOS?

1) Fecha de entrega poco realista.2) Cambios de los requisitos del cliente no contemplados.3) Subestimar el proyecto a realizar.4) Riesgos que no se consideraron en la planificación.5) Dificultades técnicas que no fueron previstas por adelantado.6) Dificultades humanas que no pudieron ser previstas por anticipado.7) Falta de reconocimiento de retrasos por parte de los encargados de proyecto.

7.1.1.- COMENTARIOS SOBRE LOS RETRASOSNapoleón dijo una vez: “Un comandante en jefe que acepta llevar a cabo un plan que considera defectuoso está cometiendo un error; debe exponer sus razones, insistir en cambiar el plan y finalmente presenta rus dimisión antes de ser el instrumento de la destrucción de su ejército.”

¿QUE DEBERIAMOS HACER CUANDO LA GESTION NOS EXIGE QUE CUMPLAMOS UNA FECHA DE LIMITE DE ENTREGA QUE ES IMPOSIBLE?

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

2) Emplear un modelo de proceso incremental y establecer una estrategia de desarrollo que proporcione una funcionalidad critica mínima para la fecha límite de entrega. Documente el plan.

3) Reúnase con el cliente y (empleando la estimación detallada) explique porque razón la fecha límite impuesta no es realista. ASEGURESE de apuntar que todas las estimaciones se basan en proyectos del pasado.

4) Ofertar la estrategia de desarrollo incremental como alternativa. Exponerle al cliente de que para cumplir con lo requerido se deberá incrementar la inversión en el presupuesto lo cual generara más costo y, a la vez, se verá significativamente afectada la calidad del proyecto debido a que se trabajara innecesariamente presionado lo cual puede llevar a obviar ciertos criterios necesarios para desarrollar software de calidad.

7.1.2.- PRINCIPIOS BASICOSNo importa qué tipo de proyecto sea el que se realice, siempre se debe tener la idea clara de que para llegar al objetivo final antes se deberá realizar cientos de pequeñas tareas interdependientes unas respecto de las otras.

Además se debe tener en consideración que hay tareas CRITICAS, las cuales si se retrasan pondrán en peligro la fecha de terminación del proyecto.

OBJETIVO DEL GESTOR DE PROYECTOSDefinir todas las tareas del proyectoConstruir una red que describa sus interdependenciasIdentificar las tareas que son críticas dentro de la redHacer un seguimiento para asegurarse de que el retraso se reconoce “DE INMEDIATO”

¿QUE ES LA PLANIFICACION 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 específicas de la ingeniería del software.

Cabe mencionar que esta evoluciona con el tiempo.

Las primeras etapas de la planificación del proyecto se desarrolla a un nivel MACROSCOPICA (Contemplando actividades y funciones del producto a las que se aplican de forma general) y luego a un nivel DETALLADO (Identificación y programación de las tareas requeridas para realizar una actividad)

LA PLANIFICACION TEMPORAL DE PROYECTOS SE GUIA POR LOS SIGUIENTES PRINCIPIOS BASICOS:

Compartimentación: Consiste en dividir el proyecto en un número de actividades y tareas manejables.

Interdependencia: Se deben determinar las interdependencias dé cada actividad o tarea compartimentada. Por ejemplo:

Algunas tareas deben ocurrir en una secuencia determinada.Otras pueden darse en paraleloAlgunas actividades no pueden comenzar hasta que el resultado de otras no este disponible.Otras actividades pueden ocurrir independientemente.

Asignacion de tiempo: A cada tarea que se vaya a programar se le debe asignar cierto numero de unidades de trabajo.Por ejemplo: PERSONAS – Dias de esfuerzo.

VALIDACION DE ESFUERZO:Asegurarse de que no se ha asignado un número de personas mayor para tareas que realmente no lo necesiten o de forma inversa.

RESPONSABILIDADES DEFINIDASAsignaciones de tareas a miembros del equipo.

RESULTADOS DEFINIDOSRealización de módulos completamente funcionales de forma independiente tanto como una vez ya integrados en el tiempo estipulado.

HITOS DEFINIDOS:Se considera un hito cuando se ha revisado la calidad de uno o más productos y se han aceptado.

7.2.- LA RELACION ENTRE LAS PERSONAS Y EL ESFUERZOEsto habla de que en proyectos pequeños como los nuestros(en su mayoría), una sola persona se puede encargar del diseño, análisis, programación de módulos e integración de los mismos; pero en el caso de proyectos de gran tamaño se requerirá la participación de más miembros.

Agregar gente tarde a un proyecto provoca más retrasos porque:Tienen que aprenderse el sistema lo cual implicaría pérdida de tiempo innecesario.Y lo peor del caso es que por lógica quien le tiene que enseñar es la misma persona que estaba trabajando en el, razón por la cual, se reduce el tiempo de avance de desarrollo.La relación entre el número de personas que trabajan en un proyecto de software y la productividad no es lineal.

7.2.2.- UNA RELACION EMPIRICAMenciona que se pueden obtener beneficios usando menos gente durante un periodo de tiempo algo mayor para realizar el mismo trabajo.

7.2.3.- DISTRIBUCION DEL ESFUERZOUna distribución recomendada de esfuerzo en las fases de definición y desarrollo se conoce normalmente como la REGLA 40-20-40.Explicación del 40 – 20 – 40Significa que el 40% de todo el esfuerzo o más se asigna a las tareas de análisis y diseño.El 20% a la codificación yEl 40% restante insiste mucho en las pruebas (validaciones y posibles fallas del sistema)

7.3.- DEFINICION DE UN CONJUNTO DE TAREAS PARA EL PROYECTO DE SOFTWAREUn conjunto de tareas es una colección de entregas, hitos y tareas de ingeniería del software que deben realizarse para completar un proyecto particular.

TIPOS DE PROYECTOS ENCONTRADOS EN LAS ORGANIZACIONES:Proyectos de desarrollo del concepto: Desarrollo de aplicaciones de negocios o nuevas tecnologías.

Proyectos de desarrollo de una nueva aplicación: Surgen como encargo de un cliente determinado.

Proyecto de mejoras de aplicaciones: Realización de modificaciones a un sistema ya existente.

Proyectos de mantenimiento de aplicaciones: Correcciones y algunas mejoras de un sistema existente.

Proyectos de Reingeniería: Reconstrucción de un sistema existente en su totalidad o en parte.

7.3.1.- GRADO DE RIGOREl conjunto de tareas crecerá en tamaño y complejidad al mismo tiempo que crece el grado de rigor.

NOTA: No importa el tamaño del proyecto, sea grande o pequeño, siempre se deben ejecutar de manera que terminen en puntuales entregas de alta calidad.

GRADOS DE RIGOR:Casual: Se aplican todas las actividades estructurales del proceso, pero solo se requiere un conjunto de tareas mínimo.

Estructurado: se aplicara lo realizado en el grado de rigor casual pero incluyendo documentación y tareas de medición de manera fluida.

Estricto: Se aplicara el proceso completo para este proyecto con un grado de disciplina tal que garantice una alta calidad incluyendo una robusta documentación.

Reacción Rápida: Se aplicaran solo tareas esenciales para mantener la calidad del software y luego de entregar la aplicación ser desarrollara un conjunto completo de documentación, realizar revisiones adicionales debido a una emergencia.

7.3.2.- DEFINIR LOS CRITERIOS DE ADAPTACIONEstos se emplean para determinar el grado de rigor recomendado con el que el proceso del software debería aplicarse en un proyecto.

Tamaño del proyectoNumero potencial de usuariosImportancia de la misiónAntigüedad de la aplicaciónEstabilidad de los requisitosFacilidad de comunicación cliente/desarrolladorMadurez de la tecnología aplicableLimitaciones de rendimientoCaracterísticas empotradas/no empotradasPersonal del proyectoFactores de reingeniería.

NOTA: A cada CRITERIO DE ADAPTACION se le asignara un grado de 1 – 5, DONDE:1 representara un proyecto en el que se requiere un pequeño subconjunto de tareas de proceso, y los requisitos generales metodológicos y de documentación son mínimos.

Y 5 representa un proyecto en el que se debería aplicar un conjunto completo de tareas de proceso y en el que los requisitos generales metodológicos y de documentación son sustanciales.

7.4.- SELECCIÓN DE LAS TAREAS DE INGENIERIA DEL SOFTWAREPara desarrollar una planificación temporal del proyecto, se debe distribuir un conjunto de tareas a lo largo dela duración del proyecto.

¿Cuándo se inician los proyectos de desarrollo de concepto?Se inician cuando se debe explorar el potencial de alguna nueva tecnología.

LOS PROYECTOS DE DESARROLLO DE CONCEPTO SE ENFOCAN EN LAS SIGUIENTES TAREAS PRINCIPALES:

Ámbito del concepto: Determina el ámbito general del proyecto.

Planificación preliminar del concepto: capacidad de la organización para llevar a cabo el trabajo implicado por el ámbito del proyecto.

Valoración del riegos tecnológico: Evalúa si hay riegos con la tecnología que una empresa quiera implementar como parte del proyecto.

Prueba de Concepto: Demuestra si es viable o no implementar nueva tecnología en el contexto del software.

Implementación del Concepto: Implementación del concepto de forma entendible para el cliente y de esta forma cuando hay que vender un concepto a otros clientes o departamentos de gestión.

Reacción del cliente ante el concepto: se solicita la opinión del cliente sobre un nuevo concepto de tecnología y va encaminada a aplicaciones específicas del cliente.

PUNTOS IMPORTANTES:El equipo de software debe entender lo que hay que hacer (AMBITO)El equipo (o GESTOR) debe determinar si hay alguien disponible para hacerlo (PLANIFICACION)Debe considerar los riesgos asociados con el trabajo (VALORACION DEL RIESGO)Probar la tecnología de alguna manera (PRUEBA DEL CONCEPTO)