Ingenieria De Software

UNIDAD 4. PLANIFICACIÓN DE PROYECTOS DE SOFTWARE Y GESTIÓN DEL RIESGO

4.1 Objetivos de la Planificación del proyecto

El objetivo de la planificación del proyecto de software es proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos, coste y planificación temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un proyecto de software, y deberían actualizarse regularmente a medida que progresa el proyecto. Además, las estimaciones deberían definir los escenarios del «mejor caso» y «peor caso» de forma que los resultados del proyecto puedan limitarse.

El objetivo de la planificación se logra mediante un proceso de descubrimiento de la información que lleve a estimaciones razonables. En las secciones siguientes, se estudian cada una de las actividades asociadas a la planificación del proyecto de software.

4.2 Ámbito del software

La primera actividad de la planificación del proyecto de software es determinar el ámbito del software. Se deben evaluar la función y el rendimiento que se asignaron al software durante la ingeniería del sistema de computadora, para establecer un ámbito de proyecto que no sea ambiguo, ni incomprensible para directivos y técnicos. Se debe delimitar la declaración del ámbito del software.

El ámbito del software describe el control y los datos a procesar, la función, el rendimiento, las restricciones, las interfaces y la fiabilidad. Se evalúan las funciones descritas en la declaración del ámbito, y en algunos casos se refinan para dar más detalles antes del comienzo de la estimación. Dado que las estimaciones del coste y de la planificación temporal están orientadas a la función, muchas veces es Útil llegar a un cierto grado de descomposición. Las consideraciones de rendimiento abarcan los requisitos de tiempo de respuesta y de procesamiento. Las restricciones identifican los límites del software originados por el hardware externo, por la memoria disponible y por otros sistemas existentes.

4.3 Recursos

La segunda tarea de la planificación del desarrollo de software es la estimación de los recursos requeridos para acometer el esfuerzo de desarrollo de software. Los recursos de desarrollo en forma de pirámide.

En la base de la pirámide de recursos se encuentra el entorno de desarrollo herramientas de hardware y software- que proporciona la infraestructura de soporte al esfuerzo de desarrollo. En un nivel más alto se encuentran los componentes de software reutilizables -los bloques de software que pueden reducir drásticamente los costes de desarrollo y acelerar la entrega-.

En la parte más alta de la pirámide está el recurso primario -el personal-. Cada recurso queda especificado mediante cuatro características: descripción del recurso, informe de disponibilidad, fecha cronológica en la que se requiere el recurso, tiempo durante el que será aplicado el recurso. Las dos últimas características pueden verse como una ventana temporal. La disponibilidad del recurso para una ventana específica tiene que establecerse lo más pronto posible.

4.3.1 Recursos Humanos

El encargado de la planificación comienza elevando el ámbito y seleccionando las habilidades que se requieren para llevar a cabo el desarrollo. Hay que especificar tanto la posición dentro de la organización (por ejemplo: gestor, ingeniero de software experimentado, etc.) como la especialidad (por ejemplo: telecomunicaciones, bases de datos, cliente/servidor). Para proyectos relativamente pequeños (una persona-año o menos) una sola persona puede llevar a cabo todos los pasos de ingeniería del software, consultando con especialistas siempre que sea necesario.

El número de personas requerido para un proyecto de software sólo puede ser determinado después de hacer una estimación del esfuerzo de desarrollo (por ejemplo, personas-mes). Estas técnicas de estimación del esfuerzo se estudiarán después en este mismo capítulo.

4.3.2 Recursos del software reutilizables

La ingeniería del software basada en componentes (ISBC) destaca la reutilización - esto es, la creación y la reutilización de bloques de construcción de software. Dichos bloques de construcción, llamados componentes, deben establecerse en catálogos para una consulta más fácil, estandarizarse para una fácil aplicación y validarse para una fácil integración.

Bennatan sugiere cuatro categorías de recursos de software que se deberían tener en cuenta a medida que se avanza con la planificación:

Componentes ya desarrollados. El software existente se puede adquirir de una tercera parte o provenir de uno desarrollado internamente para un proyecto anterior. Llamados componentes CCYD (componentes comercialmente ya desarrollados), estos componentes están listos para utilizarse en el proyecto actual y se han validado totalmente.

Componentes ya experimentados. Especificaciones, diseños, código o datos de prueba existentes desarrollados para proyectos anteriores que son similares al software que se va a construir para el proyecto actual. Los miembros del equipo de software actual ya han tenido la experiencia completa en el área de la aplicación representada para estos componentes. Las modificaciones, por tanto, requeridas para componentes de total experiencia, tendrán un riesgo relativamente bajo.

Componentes con experiencia parcial. Especificaciones, diseños, código o datos de prueba existentes desarrollados para proyectos anteriores que se relacionan con el software que se va a construir para el proyecto actual, pero que requerirán una modificación sustancial. Los miembros del equipo de software actual han limitado su experiencia sólo al área de aplicación representada por estos componentes. Las modificaciones, por tanto, requeridas para componentes de experiencia parcial tendrán bastante grado de riesgo.

Componentes nuevos. Los componentes de software que el equipo de software debe construir específicamente para las necesidades del proyecto actual.

4.3.3 Recursos de entorno

El entorno es donde se apoya el proyecto de software, llamado a menudo entorno de ingeniería del software (ElS), incorpora hardware y software. El hardware proporciona una plataforma con las herramientas (software) requeridas para producir los productos que son el resultado de una buena práctica de la ingeniería del software. Como la mayoría de las organizaciones de software tienen muchos aspectos que requieren acceso a EIS, un planificador de proyecto

...