PLANIFICACION DE UN PROYECTO DE SOFTWARE

Transcripción

1 PLANIFICACION DE UN PROYECTO DE SOFTWARE Actividades de Planificación de un Proyecto de Software Como se menciona anteriormente, el jefe de proyectos es el responsable de la elaboración y desarrollo del plan de proyecto, el cual puede ser de diferentes tipos y variar respecto a cada proyecto. A continuación se discutirán los elementos esenciales que se deben incluir en la planificación de un proyecto de software. a) Objetivos y metas para el proyecto de software El primer paso en la planificación de un proyecto de ingeniería de software, es determinar qué es lo que el proyecto debe cumplir y qué recursos son necesarios. Esto implica definir en forma clara los objetivos de este, especificándolos en términos cuantificables. Para que un objetivo esté bien definido debe presentar las siguientes características: Asequible: el objetivo identifica una meta que se debe conseguir en tiempos determinados y con restricciones dadas. Si la meta es demasiado ambiciosa, el objetivo puede perder credibilidad. Definitivo: especifica concretamente qué es lo que se debe lograr y en qué grado de detalle. Cuantificable: especifica un criterio de financiación. De duración específica: define la duración de las actividades, esto es necesario para evaluar el progreso del proyecto. El criterio de éxito debe ser especificado en forma clara. Este criterio, normalmente incluye la entrega de un sistema de software que satisfaga los requerimientos en el tiempo planificado y dentro de los costos. Sin embargo, puede haber otros criterios. Por ejemplo, el éxito podría incluir ganar un siguiente contrato; otro criterio puede incluir incrementar la magnitud y el alcance del actual contrato, o incrementar el margen de utilidad para ganar un premio de incentivo. El criterio de éxito puede también ser fijado en una jerarquía relativa de importancia. Por ejemplo, estar a tiempo puede ser más importante que estar dentro del presupuesto. b) Desarrollo de políticas para el proyecto de software Las políticas son decisiones de administración predeterminadas. El jefe de proyectos puede establecer políticas para el proyecto al proporcionar guías a los supervisores y a miembros individuales del equipo, respecto a toma de decisiones rutinarias. Por ejemplo, puede ser una política del proyecto que los reportes de estado de los jefes de equipo estén en la oficina del jefe de proyecto todos los días viernes. Las políticas pueden reducir la necesidad de interacción sobre cada decisión y proveer un sentido de dirección para los miembros del equipo [IEE97-

2 Thyer]. En muchos casos, el jefe de proyecto no desarrolla nuevas políticas, pero sigue las ya establecidas en los niveles corporativos. c) Desarrollar un plan para el proyecto de software Un plan de proyecto, especifica todas las acciones necesarias para entregar exitosamente un producto software. Típicamente el plan incluye lo siguiente: Las tareas en orden que deben ser ejecutadas por el equipo de trabajo que desarrolla el software para entregar el producto final. Esto generalmente requiere de la repartición de las actividades del proyecto en pequeñas tareas bien definidas. Una herramienta útil para representar el proyecto es el Work Breakdown Structure (WBS). El tamaño del sistema de software. El costo y recursos necesarios para realizar cada tarea del proyecto. La calendarización del proyecto, que especifica dependencias entre las tareas, y establece hitos para cada actividad del proyecto. Favorecer la discusión de la planificación del proyecto. d) Preparar presupuesto para el proyecto de software Confeccionar el presupuesto es el proceso de ubicar los costos asociados al proyecto en el plan del proyecto [IEE97-Thyer]. El jefe de proyecto es responsable de determinar los costos y añadir el presupuesto a cada una de las tareas de éste. El costo es el común denominador para todos los elementos del plan del proyecto. Los requerimientos de personal, servidores, viajes, oficinas, equipos, y otros, sólo pueden ser comparados en forma comercial en términos de su valor monetario. e) Pronosticar futuras situaciones La determinación de futuros cursos de acción habitualmente se basa en el sentido común, en el medio ambiente, la visión de futuro y experiencia del jefe de proyectos. El es responsable por las situaciones pronosticadas que pueden impactar o afectar al proyecto software. Aunque no existe una receta de como pronosticar situaciones, se pueden diferenciar dos etapas que permiten canalizar los esfuerzos para encontrar o prever los cursos de acción del proyecto: 1. Predecir el futuro medio ambiente en que se desenvolverá el proyecto, 2. Discutir cómo el proyecto responderá a este futuro. El primer paso implica predicción de eventos futuros, tales como: eficiencia del personal, tasa de inflación, eficacia de nuevas tecnologías de información (TI), y el impacto que tendrán estos eventos en el proyecto. El segundo paso implica la predicción de cómo afectará en los resultados esta situación futura, como afecta a los recursos y los costos. El jefe de proyecto es también responsable de la estimación de riesgos y desarrollo de planes de contingencia para contrarrestar estas situaciones.

3 f) Estimar riesgos para el proyecto El riesgo es la probabilidad que un evento poco deseable pueda ocurrir dentro de un período o circunstancia específica. El concepto de riesgo tiene dos elementos: la frecuencia, o probabilidad que este contratiempo específico pueda ocurrir, y las consecuencias de éste. Los factores de riesgo deben ser identificados y previstos, y se deben preparar planes de contingencia para las situaciones que puedan influir adversamente en el proyecto software. g) Planes de contingencia Esto es, especificar las acciones que se tomarán en caso de aparición de un riesgo (un problema potencial) y que pueden llegar a ser un problema real. El riesgo llega a ser un problema real, cuando un indicador de este riesgo sobrepasa los valores presupuestados. Por ejemplo, suponer que el presupuesto planificado para la revisión de la especificación de requerimientos va en un 12%, y el umbral planificado fue de 10%, esto implica que se debe poner en marcha el plan de contingencia apropiado. h) Determinar posibles cursos de acción En la mayoría de los proyectos, hay más de una manera para conducir el proyecto, pero con diferente costo, distinta calendarización o distinto riesgo. Es responsabilidad del jefe de proyecto examinar varias formas de poder alcanzar los objetivos del proyecto y satisfacer los criterios de éxito [IEEE97-Glabas]. Por ejemplo, una forma puede ser muy costosa en términos de personal y máquinas, sin embargo, reduce drásticamente la calendarización. Otra forma puede ser reducir ambos, calendarización y costos, pero en este caso existe el riesgo de ser incapaz de entregar un sistema satisfactorio. Una tercera forma puede ser extender la calendarización, de ese modo reducir el costo del proyecto. El jefe de proyecto debe examinar cada curso de acción para determinar ventajas, desventajas, riesgos y beneficios. i) Hacer plan de decisiones para el proyecto de software El jefe de proyecto, en consulta con los niveles más altos de la administración y el cliente, es el encargado de seleccionar el mejor camino para lograr las metas y objetivos establecidos. Además, es responsable de tomar decisiones comerciales que involucren costo, calendarización, diseño de estrategias y riesgos. Debe aprobar también los métodos y herramientas, tanto en términos técnicos y administrativos. Por ejemplo, los requerimientos serán documentados usando métodos de análisis estructurado o las representaciones gráficas en análisis orientado a objeto ; preguntas del tipo Cuáles herramientas, técnicas y procedimientos serán usados en planificar el desarrollo de la calendarización?, Redes PERT-CPM, representaciones gráficas y WBS.

4 j) Conjunto de procedimientos y reglas para el proyecto El jefe de proyecto establece procedimientos y reglas para el proyecto. Los procedimientos establecen métodos y proveen guías detalladas para actividades del proyecto. Detallan la manera exacta como cumplir una actividad. Por ejemplo, puede haber un procedimiento para revisar diseños de requerimientos. Una regla no permite discreción, establece acciones específicas y definidas para ser tomadas, pero no con respecto a una situación dada. Por ejemplo, una regla puede requerir que dos personas tengan la obligación de estar en la sala de máquinas todo el tiempo. Procesos estándares pueden ser usados para establecer procedimientos. Los procesos pueden ser adoptados desde los estándares corporativos o escritos para un proyecto particular. Los procesos estándares pueden cubrir tópicos tales como métodos de reportes, revisiones y requerimientos en la preparación de una documentación. k) Documentar el plan de proyecto de software El jefe de proyecto está a cargo de la documentación del plan de proyecto, y es responsable a su vez de preparar otros planes tales como, plan de recursos, riesgos, aseguramiento de calidad (SQA), gestión de configuración del software (SCM), y plan de prueba. El plan de proyecto es el medio primario de comunicación con otras entidades interconectadas con el proyecto [Piattini00]. SEGUIMIENTO Y CONTROL DE PROYECTOS El seguimiento y control de proyectos de software es una retroalimentación del sistema que informa cómo se está avanzando en el proyecto. Esto provee un medio para eliminar las diferencias entre el plan y el estado actual del proyecto, lo cual implica, revisar y comparar los resultados obtenidos frente a las estimaciones, compromisos y planes presupuestados en un comienzo, para poder actualizar o tomar decisiones basadas en los resultados. Además, el seguimiento y control de proyectos de software, permite detectar tareas que no siguen el plan, lo cual es muy provechoso, ya que para poder resolver un problema primero debe ser detectado. Basado en lo anterior, es posible decir que los objetivos que pretende conseguir el seguimiento y control de proyectos de software son: Comparar resultados actuales con los planes previstos. Descubrir problemas y deficiencias. Tomar acciones correctivas cuando existan desviaciones significativas de los planes previstos.

5 Actividades para Seguimiento y Control de un Proyecto de Software a) Establecer monitoreos y reportes de sistemas El jefe de proyecto está encargado del establecimiento de métodos de monitoreo y reportes de estado del proyecto de software. El jefe de proyecto necesita una retroalimentación del progreso del proyecto y calidad del producto para asegurarse que cada cosa va a estar de acuerdo al plan. El tipo y frecuencia de los reportes del proyecto deben ser especificados en un comienzo, idealmente incluido en la planificación. Los reportes de estado son herramientas para proveer visibilidad y progreso, y no sólo deben preocuparse de los recursos usados o del tiempo ocupado. Algunas herramientas que ayudan a controlar un proyecto de ingeniería de software son las redes PERT- CPM y Carta Gantt. A continuación, se presentan algunas técnicas usadas para el monitoreo de un proyecto. i) Hitos Los Hitos representan la mayor parte del proceso de control. Un hito es un evento discreto, y su logro debe ser basado en la culminación de uno o más productos de trabajo tangible [IEE97-Hans]. El propósito de un hito es permitir al jefe de proyecto la partición de éste en unidades limitadas, cada una de las cuales debe ser representada por un producto medible. Ejemplo de hitos es el documento de una especificación de requerimientos. ii) Revisión de hitos Las revisiones son un análisis de los procesos del proyecto y sus productos, realizadas por el cliente, usuarios y administradores, con el fin de medir el progreso del proyecto. Una revisión de hitos es realizada al final de cada fase del ciclo de vida del proyecto para evaluar si se pasa a la siguiente fase. Las revisiones de hitos son generalmente presididas por el cliente o la administración de nivel más alto. El jefe de proyecto presenta el estado actual y el progreso del proyecto, el trabajo hecho a la fecha, el dinero gastado, la calendarización actual y cualquier problema de administración y técnico que puede haber aparecido desde la última revisión. La revisión es un éxito cuando el cliente da autorización al jefe de proyecto para proseguir a la fase siguiente. iii) Baselines Una baseline es un acuerdo sobre la configuración técnica en algún punto en el proyecto de software [IEEE97-Hans]. Las baselines son acuerdos entre los desarrolladores, clientes y administradores, y éstas deben ser controladas y mantenidas por una junta de administración de gestión de configuración de software.

6 hitos. Las baselines son mantenidas hasta el final de una revisión exitosa de b) Medir y analizar resultados El jefe de proyecto debe medir los resultados del proyecto durante su desarrollo y hasta el final de éste. Por ejemplo, las entregas de la fase existente deben ser medidas contra las entregas de las planificadas. Los resultados medidos pueden ser resultados de administración (proceso) y/o resultados técnicos (productos). Un ejemplo de resultado de proceso sería el estado de la calendarización del proyecto. Un ejemplo de resultado del producto sería el grado en el cual el documento de especificación de requerimientos interpreta correctamente los requerimientos especificados. Algunas herramientas y métodos de medición de resultados son descritos a continuación: i) Chequeo e inspecciones Los chequeos e inspecciones son revisiones de un producto de software (especificaciones de diseño, código, procedimientos de prueba, etc.) dirigidas por los pares del grupo que está siendo revisado. Los chequeos son una crítica de un producto de software, con el único propósito de encontrar errores [IEEE97- Wheeler]. El sistema de inspección es otra forma de revisión realizada por los pares del grupo, éstas son más estructuradas que los chequeos y deben ser planificadas para ser ejecutadas. ii) Auditoría independiente La auditoría del proyecto de software es una revisión realizada por personas independientes al proyecto de software, para determinar la conformidad con los requerimientos de software, especificaciones, baseline, estándares, políticas y planes SQA. Una auditoría independiente es aquella hecha por una organización externa no asociada con el proyecto. El lado positivo de este tipo de revisión, es que un equipo totalmente independiente provee una opinión y realiza una revisión imparcial. El lado negativo, es que el equipo de auditoría necesita tiempo de aprendizaje para interiorizarse en el proyecto. iii) Verificación y validación La verificación y validación es uno de los métodos más importantes para determinar si el producto es correcto. La verificación asegura que cada fase del ciclo de vida interpreta correctamente la especificación desde las fases previas. La validación asegura que cada producto de software terminado satisfaga sus requerimientos.

7 iv) Testing El testing son pruebas controladas del código del programa con el fin de detectar errores. El testing unitario es la prueba de una unidad del código (usualmente un módulo) por el programador de la unidad. El testing de integración es la prueba de cada unidad o elemento en combinación con otros elementos, para mostrar la existencia de errores entre ellos. El testing del sistema son pruebas controladas del sistema terminado que permite validar que el producto realice lo que debe hacer o se dijo que haría. En cada caso, es importante desarrollar planes de pruebas, procedimientos de pruebas, casos de pruebas y resultados de pruebas. c) Acciones correctivas Si los requerimientos no están siendo logrados o si la planificación se está sobrepasando, el jefe de proyecto debe iniciar una acción correctiva. Por ejemplo, puede cambiar el plan o estándares, usar sobre tiempo u otros procedimientos para volver al plan o cambiar los requerimientos, por ejemplo, entregar sólo los requerimientos acordados y no realizar productos complementarios. El jefe de proyecto puede cambiar los planes o estándares si considera que el plan original no puede ser logrado, lo cual pondría en peligro el proyecto y al producto. Esto puede implicar requerimientos de un presupuesto más grande, más gente, o más tiempo para desarrollarlo. También puede requerir reducir los estándares (e indirectamente la calidad), reducir el número de chequeos o reducir la revisión de todos los módulos de software a sólo los módulos de software crítico. A veces, es posible volver a la calendarización para incrementar los recursos. Esto incrementa el plan de requerimientos de recursos. También es posible, a veces, mantener el costo original pero extender la calendarización o reducir la funcionalidad del sistema de software. Un ejemplo de cambio de requerimientos, implica entregar un software que no reúne completamente todos los requerimientos funcionales que fueron definidos en las especificaciones de requerimientos del software.