Unidad 2. Planificación del sistema Objetivo: Realizar la planificación de un proyecto de software para una organización

Trabajo por equipos ¿Qué entiendo por planificación? ¿Cuáles son las tareas de la ingeniería de software? ¿Cuáles son las características generales de un proyecto? En un proyecto de software, quien realiza la planificación? ¿Porqué es importante realizar la planificación en el desarrollo de un proyecto de software?

Definición de Planificación La elaboración de un plan general, científicamente organizado y frecuentemente de gran amplitud, para obtener un objetivo determinado, tal como el desarrollo económico, la investigación científica, el funcionamiento de una industria, etc. Una de las grandes responsabilidades del Gerente de Proyectos es el de planificar y darle el seguimiento debido al proyecto encomendado, pues de sus acertadas decisiones depende el éxito del mismo, de lo contrario su fallo se traduciría en pérdidas económicas para la empresa. Entre otros problemas que acarrea una planificación deficiente en un proyecto, está el crecimiento desmedido en tiempo, recursos humanos, y por supuesto, capital ($).

Los proyectos bien ejecutados pasan por tres etapas básicas para crear una planificación software. Primero se estima el tamaño del producto, luego se estima el esfuerzo necesario para construir un producto con ese tamaño del producto, Y por último se realiza una planificación, basándose en la estimación del esfuerzo. Una estimación y/o planificación incorrecta, reduce la eficiencia en el desarrollo.

Lista de problemas que aparecen en el desarrollo del software, propuestos por Phillip W. Metzger Mala planificación. Contrato mal definido. Definición del problema inestable. Falta de experiencia en la gestión. Presión política. Control de cambios poco efectivo. Plazos poco realistas.

2.1 Planificación del tiempo Una de las tareas más difíciles de la administración del software. Proyectos distintos usan diferentes lenguajes metodologías de programación que complican la estimación del tiempo del proyecto. La planeación del tiempo del proyecto implica separar el trabajo total de un proyecto en tareas distintas y estimar cuándo se terminarán. Si varios individuos o grupos trabajan en el proyecto, algunas tareas se realizan en paralelo. El programador del tiempo del proyecto debe coordinar esas tareas paralelas y organizar las actividades de modo que la utilización de la fuerza de trabajo sea la óptima. Se debe esforzar por evitar que el proyecto total se atrase porque no está terminada una tarea crítica.

Guía general para la programación de los tiempos. El análisis de requisitos y el diseño suelen consumir el doble de tiempo que la codificación. Lo mismo sucede con la comprobación. Tiempo total requerido= tamaño del sistema / productividad esperada del programador. Lo anterior permite estimar el numero de programadores-mes requeridos para terminar el proyecto. Dificultades en la estimación de la duración real del proyecto. La cifra resultante es aproximada, debido a las dificultades que implica estimar el tamaño del sistema y las variaciones en la productividad del programador. Conforme el numero de programadores aumenta, surgen problemas de comunicación y la productividad disminuye. Algunas tareas son indivisibles, y con independencia de cuántos trabajen en ellas, el tiempo requerido no puede reducirse.

"Hay más proyectos de software que han salido mal por falta de tiempo que por todas las otras causas combinadas". Fred Brooks 1970. Ejemplo WinWord 1.0 tenía una planificación extremadamente agresiva. La planificación lo más corta posible para un proyecto de su tamaño es aproximadamente de 460 días. La estimación mayor para la planificación de WinWord 1.0 era de 395 días, lo cual significa 65 días menos que la planificación más corta posible. WinWord 1.0 para Windows, necesitó 5 años para su desarrollo, consumió 660 personas - mes de esfuerzo de desarrollo, y generó un sistema de 249.000 líneas de código. ¡La planificación final fue 5 años mayor de la diseñada en un principio!.

PERT y Gant. Ventajas y desventajas. Ventajas del diagrama de Gant Es muy sencilla y fácil de entender. Da una representación global del proyecto. Permite hacer sin muchas dificultades. Lo maneja los paquetes Computacionales. Desventajas del diagrama de Gantt. Desventajas de Gant No muestra relaciones de procedencia entre actividades claramente. No permite optimizar el desarrollo de un programa. No muestra las actividades críticas o claves de un proyecto. PERT es la representación de actividades en forma de red. Ventajas de PERT Permite determinar la ruta crítica. Permite determinar holguras. Muestra la secuencia de actividades en una forma muy clara. Permite optimizar tiempos, costos y recursos humanos. Ayuda establecer actividades. Desventaja del diagrama de Pert No es fácil de interpretar y desarrollar. Estas son herramientas muy útiles y utilizadas por los gerentes de proyecto, debido a la gran popularidad alcanzada por el software Microsoft Project, este consiste en una organización gráfica, de las tareas, asignándole a cada tarea un tiempo estimado, el cual debe seguir un orden cronológico, mediante este programa, los diagramas ya antes mencionados, son generados automáticamente.

Actividades para la planificación de un proyecto de software Estimación y planificación. Determinar el número de personas que deben participar en el equipo del proyecto, qué habilidades técnicas son necesarias, cuándo aumentar el número de personas y quién participará. Decidir cómo organizar el equipo. Elegir el modelo de ciclo de vida que se debe utilizar. Gestión de riesgos. Tomar decisiones estratégicas tales como controlar el conjunto de prestaciones del producto y decidir si hay que comprar o crear algunas partes del producto.

Se puede complacer a algunas personas algún tiempo… Pero no se puede complacer a todo el mundo todo el tiempo.

2.2 Evaluación del costo beneficio El método COCOMO Una metodología que se encarga de medir proyectos software es COCOMO. La metodología COCOMO (COnstructive COst MOdel) se debe a Barry Boehm, y está orientada a líneas de código. Hay una jerarquía de modelos COCOMO: básico, intermedio y avanzado, la cual se aplica a tres tipos diferentes de software:

Orgánico: proyectos relativamente sencillos, menores de 50 Orgánico: proyectos relativamente sencillos, menores de 50.000 líneas de código. Se tiene experiencia en proyectos similares y se encuentra en un entorno estable. Semiacoplado: proyectos intermedios en complejidad y tamaño. La experiencia en este tipo de proyectos es variable, y las restricciones intermedias. Empotrado: proyectos bastante complejos, en los que apenas se tiene experiencia y en un entorno de gran innovación técnica. Se trabaja con unos requisitos muy restrictivos y de gran volatilidad. (Mayores a 100,000 ldc)

Dado que sólo se va a emplear una variable para la estimación (la línea de código), se empleará COCOMO básico, ya que es un modelo univariable estático, con lo que se obtiene una valoración objetiva del esfuerzo realizado. La ecuación del esfuerzo de COCOMO básico tiene la siguiente forma: E = Esfuerzo = a (KLDC ^b) (persona x mes) donde KLDC es el número de líneas de código, distribuidas en millares, para el proyecto.

Tabla "Coeficientes COCOMO" La ecuación del tiempo de desarrollo es: T = Tiempo de duración del desarrollo = c (Esfuerzo ^ d) (meses) Para obtener el numero de personas necesarias para desarrollar el proyecto en ese tiempo: N = E / T (personas) Por su parte los coeficientes a, b, c y d se obtienen empíricamente del estudio de una serie de proyectos, y sus valores son: Proyecto de software a b c d Orgánico 2,4 1,05 2,5 0,38 Semiacoplado 3,0 1,12 0,35 Empotrado 3,6 1,20 0,32 Tabla "Coeficientes COCOMO"

Solución a ejercicios de estudio costo/beneficio por el método COCOMO EXPOSICIONES DE LOS TEMAS: Cocomo II 121-126 Estudio de viabilidad. Planificación de la documentación (externa 374 – 375,482 e interna 370 - 374) sommerville Gestión de la configuración del SW 151-159 pressman EXAMEN : 23 septiembre

Ejercicios COCOMO Supóngase que se calculó que el tamaño estimado de un proyecto de software de modo orgánico es de 32000 instrucciones fuente entregadas. Según la ecuación de esfuerzo, el número de personas requeridas por este proyecto es: E = 2.4(32)1.05 = 91 persona/mes Según la ecuación de programación de el tiempo, el periodo requerido para terminar el proyecto es: T = 2.5(91)0.38= 14 meses La cantidad de personal necesario para terminar el proyecto en la escala de tiempo es: N = E/T = 91/14= 6.5 personas

Ejercicio COCOMO Considérese ahora un proyecto de software en modo incorporado que consta de más de 128000 instrucciones fuente entregadas. Las ecuaciones de COCOMO básico dan los resultados: E = 3.6(128)1.20= 1216 persona/mes T = 2.5(1216)0.32=24 meses N = 1216/24 = 51 personas