Ensayo de Resumen gestion de proyectos

CAPITULO 5

GESTION DE PROYECTOS

Los gestores de software son responsables la planificación  y temporalización del desarrollo de los proyectos. Supervisan el trabajo para asegurar que se lleva a cabo conforme a los estándares requeridos y supervisa el progreso para comprobar que el desarrollo se ajusta al tiempo previsto y al presupuesto. La administración de proyecto de software es necesaria debido a que la ingeniería de software profesional siempre está sujeta a restricciones organizacionales de tiempo y presupuesto.

La ingeniería de software es diferente en varios aspectos a otros tipos:

1. El producto es intangible: No se puede ver ni tocar. Los gestores de software no pueden ver el progreso. Confían en otros para elaborar la documentación necesaria para revisar el proyecto.
2. No existen procesos del software estándar: en las ingenierías de larga historia, el proceso se pone a prueba. Sin embargo los procesos de software varían notablemente de una organización a otra.
3. A menudo los proyectos grandes son únicos: los proyectos son diferentes de proyectos previos, aunque se cuente con experiencia, no es suficiente para anticipar los problemas. Además los cambios de tecnologías computacionales y comunicaciones hacen parecer obsoleta la experiencia nueva.-

Tres actividades importantes de gestión: planificación, calendarización de proyectos y gestión de riesgos.

5.1 ACTIVIDADES DE GESTION

Los gestores son responsables de alguna o de la totalidad de las siguientes actividades:

• Redacción de la propuesta: Describe los objetivos del proyecto y como se llevaría a cabo. Incluye estimaciones de tiempo y coste, también justifica porque se le debe asignar el contrato del proyecto a una organización o equipo en particular.
• Planificación: es la identificación de actividades, hitos y entregas del proyecto.
• Estimación del coste: Actividad relacionada con la estimación de los recursos requeridos para llevar a cabo el proyecto.
• Supervisión de proyecto: es una actividad continua. El gestor debe tener conocimiento del progreso del proyecto y compara el progreso con los costes actuales y los planificados.
• Selección y evaluación del personal: los gestores tienen que establecer un equipo ideal mínimo para el proyecto. Algunas restricciones (sueldos altos fuera de presupuesto, experiencia no disponible dentro o fuera de la organización, desarrollar las habilidades).
• Redacción y presentación  de informes: los gestores son responsables de informar a los clientes y contratistas sobre el proyecto. Comunicarse efectivamente de forma oral o escrita es una habilidad esencial.

5.2 PLANIFICACION DEL PROYECTO.

El proyecto de software depende de planificar completamente el progreso del proyecto.

El plan de proyecto fija los recursos disponibles, divide el trabajo y crea un calendario de trabajo.

Muchos planes incluyen las siguientes secciones:

1. Introducción: describe brevemente los objetivos del proyecto y expone las restricciones que afectan a la gestión.
2. Organización del proyecto: como el equipo está organizado, gente involucrada y roles en el equipo.
3. Análisis de riesgo: describe posibles riesgos y probabilidad de que ocurran, propuestas de reducción de los mismos.
4. Requerimientos de recursos de hardware y software: que serán utilizados para llevar a cabo el proyecto.
5. División del trabajo: división del proyecto en actividades e identifica los hitos y productos a entregar asociados a cada actividad.
6. Programa del proyecto: describe dependencias entre actividades, el tiempo estimado para alcanzar cada hito y la asignación de la gente a las actividades
7. Mecanismos de supervisión e informes: gestión de informes y cuando deben producirse. Mecanismos de supervisión a utilizar.

HITOS Y ENTREGAS

Hitos son puntos finales de una actividad del proceso del software. No deben ser documentos amplios. Los informes deben ser cortos de los logros de una actividad del proyecto, deben representar el fin de una etapa lógica del proyecto. Ejem. Los hitos indefinidos como “80% del código completo” es imposible de validar.

Una entrega se presenta al final de una fase principal del proyecto como la especificación, el diseño, etc…

5.3 CALENDARIZACION DEL PROYECTO.-

Implica separar todo el trabajo de un proyecto en actividades complementarias y considerar el tiempo requerido para completar dichas actividades. Algunas se llevan a cabo en paralelo, habrá que coordinar y organizar el trabajo para optimizar la mano de obra. Las actividades críticas deben evitarse para no causar un retraso del proyecto entero. El tiempo máximo a asignar es de 8 a 10 semanas, si es superior se deberá subdividir. Como regla los problemas previstos se le agregará un 30% a la estimación original y un 20% para cubrir algunas cosas no previstas.-

GRAFICOS Y BARRAS

Los gráficos de barra muestran quien es responsable de cada actividad y cuando debe comenzar y finalizar esta. Las redes de actividades muestran las dependencias entre las diferentes actividades que conforman el proyecto.

5.4 GESTION DE RIESGO

Una tarea importante del gestor de proyecto es anticipar los riesgos que podrían afectar a la programación del proyecto o a la calidad del software a desarrollar y emprender acciones para evitar esos riesgos. Los resultados de este análisis de riesgo se deben documentar a lo largo del plan del proyecto junto con el análisis de consecuencias cuando el riesgo ocurra, identificar estos y crear planes para minimizar sus efectos en el proyecto se llama gestión de riesgos.-

Categorías de riesgos:

1. Riesgos del proyecto: afectan la calendarización o los recursos del proyecto (ejem. Perdida de un diseñador experimentado)
2. Riesgos del producto: afectan a la calidad o al rendimiento del software que se está desarrollando. (componente de rendimiento menor al esperado)
3. Riesgos del negocio: afecta a la organización que desarrolla o suministra el software. (un competidor introduce un nuevo producto)

PROCESO DE GESTION DE RIESGOS

• IDENTIFICACION DE RIESGOS: comprende el descubrimiento de los posibles riesgos del proyecto. Tipos de riesgos:

1. De tecnología:
2. De personal: asociados con las personas del equipo de desarrollo
3. Organizacionales: derivan del entorno organizacional donde se desarrolla el software
4. De herramientas: se derivan de herramientas CASE y de otro software de apoyo utilizado para desarrollar el sistema.
5. De requerimientos: cambios de los requerimientos del cliente y del proceso de gestionar dicho cambio.
6. De estimación:  se derivan de los estimado administrativos de las características del sistema y los recursos requeridos para construir dicho sistema

• ANALISIS DE RIESGOS

No existe una forma fácil de hacer esto, recae en la opinión y experiencia del gestor de proyecto, la valoración se hace en intervalos:

1. La probabilidad del riesgo se valora como muy bajo (<10%), bajo (10-25%), moderado (25-50%), alto (50-75%) o muy alto (>75%).
2. Los efectos del riesgo pueden ser valorados como catastróficos, serio, tolerable o insignificante.

• PLANIFICACION DE RIESGOS

Se considera cada uno de los riesgos clave que han sido identificados, así como las estrategias para gestionarlos. Depende del juicio y de la experiencia del gestor de proyecto.

1. Estrategias de prevención: estas disminuyen la probabilidad de que el riesgo aparezca
2. Estrategias de minimización: busca reducir el impacto del riesgo.
3. Planes de contingencia: Estar preparado para lo peor y tener una estrategia para cada caso.

• SUPERVISION DE RIESGOS

Normalmente valora cada uno de los riesgos identificados para decidir si este es más o menos probable y si han cambiado sus efectos. No se puede observar de forma directa por lo que se tienen que buscar otros factores para dar indicios de la probabilidad del riesgo y sus efectos

CAPITULO 6

REQUERIMIENTOS DEL SOFTWARE

“si una compañía desea establecer un contrato para un proyecto de desarrollo del software grande, debe definir sus necesidades de una forma suficientemente abstracta para establecer a partir de ella una solución. Los requerimientos deben redactarse de tal forma que varios contratistas pueden licitar el contrato, ofreciendo, quizás, formas diferentes de cumplir las necesidades de los clientes en esa organización. Una vez que el contrato se asigna, el contratista debe redacta una definición del sistema para el cliente más detalladamente de forma que este comprenda y pueda validar lo que hará el software. Ambos documentos se pueden denominar documentos de requerimientos para el sistema”

1. REQUERIMIENTOS DEL USUARIO: son declaraciones en lenguaje natural y en diagramas, de los servicios que se espera que el sistema proporcione y de las restricciones bajo las cuales debe funcionar.
2. REQUERIMIENTOS DEL SISTEMA: Establecen con detalles las funciones, servicios y restricciones operativas del sistema. Debe definir exactamente qué es lo que se va a implementar. Puede ser parte del contrato entre el comprador del sistema y de los desarrolladores del software.-

REQUERIMIENTOS FUNCIONALES Y NO FUNCIONALES

Los requerimientos de sistemas de software se clasifican en:

1. REQUERIMIENTOS FUNCIONALES: Son declaraciones de los servicios que debe proporcionar el sistema, de la manera en que este debe reaccionar a las entradas particulares y de cómo se debe comportar en situaciones particulares. O también lo que el sistema no debe hacer. Estos requerimientos dependen del tipo de software y del enfoque general tomado por la organización al redactar requerimientos.
2. REQUERIMIENTOS NO FUNCIONALES: son restricciones de los servicios o funciones ofrecidas por el sistema. Se aplican al sistema en su totalidad. Tiene que ver con las propiedades emergentes del sistema, como la fiabilidad, el tiempo de respuesta y la capacidad de almacenamiento.

Los tipos de requerimientos no funcionales son:

1. R. DEL PRODUCTO: Especifican el comportamiento del producto. ( rapidez de ejecución de sistema, cantidad de memoria, fiabilidad, portabilidad, usabilidad)
2. R. ORGANIZACIONALES: Referido a las políticas y procedimientos existentes en la organización del cliente y la del desarrollador. Ejem. Estándares en los procesos, lenguajes de comunicación, método de diseño a utilizar.
3. R. EXTERNOS: Son factores externos al sistema y de su proceso de desarrollo. Estos pueden incluir requerimientos  de interoperabilidad, legislativos y éticos.

1. REQUERIMIENTOS DEL DOMINIO: Son requerimientos que provienen del dominio de aplicación del sistema y que reflejan las características y restricciones de ese dominio. Pueden ser funcionales o no funcionales. Los requerimientos del dominio son importante debido a que reflejan los fundamentos de la aplicación. Si estos fundamentos no se satisfacen, puede ser imposible hacer que el sistema funcione de forma satisfactoria.

Ejem. Se establece un interfaz estándar de usuario para una base de datos, los desarrolladores deberán informarse acerca de este para poder empezar el diseño.-

Ejem. Un R. del Dominio obtenido de un sistema de protección de trenes. La desaceleración del tren se calculara como:  . La terminología utilizada es específica del dominio. Para entenderla, se necesita una cierta comprensión del funcionamiento del sistema ferroviario y las características de los trenes.[pic 1]

...