Tema 7 Gestión de Proyectos - kybele.etsii.urjc.es · Ingeniería del Software I – 2011/2012 ¿Qué es un proyecto? – Objetivo El objetivo principal es obtener un resultado en

Tema 7 Gestión de Proyectos

Ingeniería del Software I

[email protected]

www.kybele.es www.kybele.etsii.urjc.es Ingeniería del Software I – 2011/2012

¿Qué es un proyecto?.

Gestión de proyectos.

Esquema básico para la gestión de un proyecto.

Estudio de viabilidad.

Planificación

Estimación.

Planificación temporal.

Planificación económica.

Planificación de riesgos.

Seguimiento y control del proyecto.

Cierre del proyecto.

Índice


¿Qué es un proyecto?

Definición 1:

Es un conjunto de actividades planificadas, ejecutadas y supervisadas que, con recursos finitos, tiene como objetivo crear un producto o servicio único.

Definición 2:

Un proyecto es una actividad que tiene un inicio, que se lleva a cabo para conseguir unos objetivos definidos y tiene un final previsto.


¿Qué es un proyecto? – Objetivo

El objetivo principal es obtener un resultado en forma de bien o producto para un cliente que da una especificaciones y marca unos objetivos a cumplir para que el proyecto se lleve a cabo.


¿Qué es un proyecto? – Esquema

Actividades del

proyecto

Cliente

Recursos

Restricciones

económicas,

temporales,

de personal…

Bien o servicio

Gestión y

planificación

Especificaciones

y objetivos

a cumplir.


¿Cómo debe ser un buen proyecto?

Objetivos claros y definidos.

Las actividades se deben poder planificar, ejecutar y controlar.

Menor número de recursos y mínimo tiempo.

Debe tener un inicio y un final previstos.

Debe tener un resultado único.


Fases de un proyecto y tareas de gestión

INICIO

DESARROLLO

FINAL

Planificación y

estimaciones.

Seguimiento del

proyecto.

Comprobar que todo

ha terminado con

éxito.


¿Por qué la Gestión de Proyectos?

Gran número de empresas, buenas y malas, grandes y pequeñas, tienen a menudo un factor común Proyectos pesadilla:

Proyectos con fechas imposibles de cumplir

Generando productos decepcionantes para sus usuarios y

Consumiendo ingentes horas de mantenimiento

Idea de Meiler Page-Jones






Planificación

Estimación.






Índice


Dificultad de Dirigir un Proyecto Informático

El software es intangible ◦ Tiene una naturaleza no física (el hardware tiene una importancia

sólo relativa), lo que le separa de los productos de otras ingenierías No es fácil de controlar (efectos laterales imprevistos) Composición no trivial (costos de integración) Muy difícil de medir (necesidad de métricas propias)

Medir el producto, y también el proceso

◦ Además, su costo de replicación es prácticamente nulo Es la característica principal que distingue al proceso de software No es comparable a una ingeniería clásica

El costo de diseño no se amortiza con la producción en serie

Recuerda más a la arquitectura, y aun así no se construye. La complejidad lógica es mayor en los proyectos informáticos.

◦ Finalmente, incluso el comportamiento del proyecto es distinto Ley de Brooks – en Informática, no existe el hombre-mes “La adición de personal a un proyecto informático, de hecho lo retrasa”


Un chiste demasiado cierto …


¿Qué es la gestión de proyectos?

Es un conjunto de actividades con el objetivo de ordenar, disponer y organizar los recursos y las necesidades para completar con éxito un cierto proyecto.

El proceso de gestión es un conjunto de actividades que se hacen antes y durante todo el proceso de desarrollo de forma paralela a éste.

PLANIFICAR Y HACER EL SEGUIMIENTO


¿Qué es la gestión de proyectos?

Las actividades de gestión engloban todos los ámbitos del proyecto, desde los factores técnicos, los comerciales hasta las tareas administrativas, contables o financieras.


Áreas que se deben gestionar

Gestión RRHH

Gestión técnica

Gestión costes

Gestión recursos

temporales

Gestión calidad

Gestión

comunicación

Gestión alcance

y contenidos Gestión riesgos

Gestión compras ¿Qué

debemos

gestionar?


Elementos que debemos gestionar

Personal

Proceso

Producto

Proyecto


A quién involucra la Gestión de Proyectos

¿Quién la hace?: Todos gestionan. ◦ Ingeniero Software (IS): Gestiona sus actividades diarias;

planifica, supervisa y controla labores técnicas.

◦ Gestores de Proyecto: Planifican, supervisan y controlan el trabajo del equipo de IS.

◦ Gestores Ejecutivos: Coordinan la relación entre el negocio y los profesionales del software.

¿Por qué es importante?: ◦ La construcción de software involucra a mucha gente

que trabaja durante mucho tiempo

Actividad compleja que necesita ser gestionada.


El Personal: como elemento de gestión

Factor humano: aspecto más importante de la gestión.

¿Qué es el grupo del proyecto? Es el grupo formado por un conjunto de personas directa o

indirectamente relacionadas con el proyecto o con su ejecución, cada una de ellas con un perfil determinado.

Así, tenemos: Grupo del proyecto: el personal del proyecto. Aspecto más

importante de la gestión.

Cliente: especificación de requisitos y detalles. Proporciona también recursos financieros.

Usuario: interacción con el producto/solución software

Proveedores: Subministran algo relacionado con el proyecto.


El Personal: Perfiles

Existen diferentes perfiles en el grupo del proyecto:

Directivos.

Responsables del proyecto.

Consultor interno o externo.

Personal de soporte administrativo y logístico.

Equipo de software: Estructura organizada del personal de desarrollo de software encargada de la implementación de una solución. Ingeniero o analista.

Programador.


El Personal: Gestión vs Dirección

La dirección de proyectos es un termino más amplio que el de gestión.

La dirección abarca actividades de más responsabilidad.

La dirección requiere más experiencia y profesionalidad.


El Personal: Directivos

Características:

Empleados de alto nivel en la dirección de la empresa.

Personal con conocimientos de los objetivos estratégicos y de negocio.

Personal con autoridad para revisar y aprobar formalmente todos los procesos que se realizan en el desarrollo del proyecto.

Personal para proporcionar todos los recursos necesarios para el buen funcionamiento del proyecto y el cumplimiento de los objetivos propuestos.



Los tiempos de la Dirección “heroica” en la que el máximo responsable de la empresa asumía además del papel de “Director de Orquesta”, el de tocar todos los instrumentos que fueran precisos según se presentaba la situación o según lo “exigía la partitura”, están totalmente superados.

Por lo tanto, dentro de este perfil podemos encontrar diferentes agentes o participantes:

Comité de dirección.

Director del departamento.

Comité de seguimiento.



Comité de Dirección:

Es un órgano que engloba a los responsables de los principales departamentos de la empresa, tanto operacionales como funcionales, que permite reunir en un equipo todas las facetas de la empresa y que, en consecuencia, tendrá una visión global de la problemática de la misma.

Comité de seguimiento:

Su objetivo es asegurarse de la eficacia y la calidad de la ejecución del proyecto, con el fin de alcanzar los objetivos específicos del Programa.


Personal: Responsables del proyecto

En este perfil podemos encontrar diferentes participantes.

Jefe de proyecto.

Responsable de desarrollo.

Responsable de implantación.

Responsable de operación.

Responsable de mantenimiento.

Responsable de sistemas.

Responsable de seguridad.

Responsable de calidad.


Es una figura principal en el equipo.

Buen técnico ≠ Buen jefe.

Habilidades del jefe de proyecto: Motivación: Adecuar la producción conforme a las mejores

capacidades de cada empleado Organización: Adecuar/Crear procesos para llevar el concepto inicial

al producto final Ideas/Innovación: Motivar al personal para aportar ideas dentro de

los límites del proyecto

Objetivo principal: hacer ver al equipo la importancia de la calidad del producto en desarrollo

El Personal: Jefe de Proyecto


El Personal: Jefe de Proyecto

Otras características. Del jefe de proyecto eficientes:

Resolución del problema: Diagnosticar, estructurar, motivar, aplicar lecciones aprendidas, flexibilidad.

Dotes de gestión. Liderazgo: control y libertad.

Incentivos por logros: Recompensas, no penalizaciones si dentro de riesgos controlados.

Motivación del espíritu de equipo: Control en cada situación.


El Personal: Jefe de proyecto

Sus principales tareas son:

Gestión de RRHH y gestión de la comunicación.

Seguimiento del rendimiento de los trabajadores.


Planificación económica, temporal, de riesgos.

Gestión de la configuración.

Seguimiento de incidencias y tareas.


Selección de la estrategia de desarrollo.

Coordinar el equipo de trabajo.


El Personal: Equipo Software

Estructura organizada del personal de desarrollo de software encargado de la implementación de una solución.

Organigramas del Equipo Software:

Descentralizado democrático (DD).

Descentralizado controlado (DC).

Centralizado controlado (CC).


Criterios de formación de Equipos Software: (factores de planificación del organigrama)

Dificultad del problema.

Tamaño de la solución.

Tiempo que el equipo estará junto

Grado de modularidad del problema

Nº de personas por equipo. Niveles de preparación

Calidad y fiabilidad requeridas

Rigidez de la fecha de entrega

Grado de comunicación requerido

El Personal: Equipo Software


Organigramas de Equipo – (DD)

No existe un líder permanente del equipo. Se nombran coordinadores de tarea a corto plazo.

Las decisiones se toman por consenso dentro del grupo.

Comunicación horizontal.

Características:

Recomendado en problemas difíciles.

Para equipos con tiempo de vida largo. Satisfacción de los integrantes.

Hay una buena comunicación.


Organigramas de Equipo – (DC)

En el equipo existe un líder permanente y líderes secundarios en sub-equipos.

La resolución de problemas se hace en equipo, pero la implementación de las soluciones se reparte entre subgrupos.

Comunicación horizontal y vertical entre subgrupos e individuos.

Características:

Recomendado en problemas complejos pero modularizables.

Proyectos grandes con formación de subgrupos.


Organigramas de Equipo – (CC)

Existe un líder permanente del equipo que se encarga de la resolución de problemas de alto nivel y la coordinación interna del equipo.

Comunicación entre líder y equipo es vertical.

Características:

Menos defectos que organigramas no controlados.

Requieren menos tiempo que organigramas descentralizados.

Se realizan las tareas más rápidamente.

Adecuada para manejar problemas sencillos.


Organigramas de Equipo

Descripción mediante los factores de organización:

Factores organización DD DC CC

Dificultad del problema a resolver

Alta Baja Baja

Tamaño del SW a desarrollar

Pequeño Grande Grande

Tiempo de vida del equipo

Largo Corto Corto

Grado de modularidad del

problema

Baja Alta Alta

Calidad del sistema que se construye

Alta Alta Baja

Rigidez de la fecha de entrega

Flexible Flexible Estricta

Grado de comunicación

requerido

Alta Baja Baja


Organigramas de Equipo - Conclusiones

Una estructura centralizada: se realizan las tareas más rápidamente. Es la adecuada para manejar problemas sencillos.

Los equipos descentralizados generan mejores soluciones (+ éxito en la resolución de problemas). Requieren más tiempo.

La estructura DD es la mejor para problemas difíciles.

Los proyectos muy grandes son mejor dirigidos con una estructura DC o CC, donde se pueden formar subgrupos. (Se debe tener en cuenta que el rendimiento de un equipo es inversamente proporcional a la cantidad de comunicación que se establece).

La estructura DD conviene para equipos que permanecerán juntos durante mucho tiempo.

La estructura DD se aplica mejor a problemas con modularidad baja.


Paradigmas de organización

Constantine, sugiere 4 paradigmas de organización para equipos de IS:

Paradigma cerrado.

Jerarquía tradicional de autoridad (similar al organigrama CC).

Estos equipos trabajan bien cuando producen sw similar a otros anteriores.

Paradigma aleatorio.

Libertad en el equipo.

Ideales para cuando se requiere innovación y avances tecnológicos.

Problemas para el rendimiento ordenado.


Paradigmas de organización

Paradigma abierto.

Se controla al equipo siguiendo el paradigma cerrado y se motiva la innovación como en el paradigma aleatorio.

Mucha comunicación, colaboración. Toma de decisiones consensuadas.

Este paradigma es bueno para la resolución de problemas complejos.

Paradigma sincronizado.

Organiza los miembros del grupo para trabajar en partes del problema con poca comunicación activa entre ellos.


El Personal: Coordinación y comunicación

Factores que dificultan la coordinación y comunicación en proyectos:

La escala del proyecto. Los proyectos grandes conllevan complejidad, confusión y dificultad para coordinar los miembros del equipo.

La incertidumbre del proceso. Los continuos cambios.

La interoperatividad del software. El software nuevo debe comunicarse con otros sistemas y ajustarse a restricciones.

Para conseguir una buena coordinación y comunicación en un proyecto se deben establecer mecanismos de comunicación formales e informales entre los miembros del equipo y entre diferentes equipos.



Comunicación formal: se lleva a cabo mediante escritos y reuniones organizadas.

Comunicación informal: se produce cuando los miembros de un equipo comparten ideas entre sí e interactúan los unos con los otros diariamente de forma personal.



Kraul y Streeter proponen una clasificación de las técnicas de coordinación:

Formal, enfoque impersonal: memorandos técnicos, planificaciones, informes de seguimiento…

Formal, procedimientos interpersonales: reuniones de revisión de estado e inspecciones de diseño y código.

Informal, procedimientos interpersonales: reuniones de grupo para la divulgación de información y resolución de problemas.

Comunicación electrónica: correo electrónico, boletines de noticias electrónicos y sistemas de videoconferencia.

Red interpersonal: discusiones informales con los miembros del equipo y con personas que no están en el proyecto pero que pueden tener mucha experiencia que puede ayudar.



Kraul y Streeter proponen una clasificación de las técnicas de coordinación:

Formal, enfoque impersonal: memorandos técnicos, planificaciones, informes de seguimiento…

Formal, procedimientos interpersonales: reuniones de revisión de estado e inspecciones de diseño y código.

Informal, procedimientos interpersonales: reuniones de grupo para la divulgación de información y resolución de problemas.

Comunicación electrónica: correo electrónico, boletines de noticias electrónicos y sistemas de videoconferencia.

Red interpersonal: discusiones informales con los miembros del equipo y con personas que no están en el proyecto pero que pueden tener mucha experiencia que puede ayudar.


El Producto

El producto se gestiona desde el inicio del proyecto mediante estimaciones y un plan organizado.

Problemas:

La poca información existente.

Un análisis detallado de los requisitos es una tarea que requiere tiempo.

Los requisitos funcionales siempre pueden cambiar.

Para examinar el producto y el problema a resolver justo al inicio del proyecto se debe:

Establecer el ámbito del producto.

Descomponer el problema.


El Producto

Establecer el ámbito del producto:

Es la primera actividad de gestión de un proyecto software.

La definición del ámbito del producto debe contestar las siguientes cuestiones:

¿Cómo encaja el software a construir, en un sistema/producto/sistema de negocio y qué limitaciones existen?

¿Qué datos se obtienen del software a construir? ¿Qué datos se requieren como entrada?

¿Qué función realiza el software para transformar la información de entrada en una salida?

El ámbito debe ser entendible a niveles de gestión y a nivel técnico.

Los datos cuantitativos se definen (Ej. número de usuarios simultáneos, tiempo de respuesta del software).

Se anotan las limitaciones (Ej. el tamaño de la memoria puede limitar)

Se describen los factores de reducción de riesgos.


El Producto

Descomposición del problema:

Es una actividad que se asienta en el núcleo del análisis de requisitos de software.

Contesta las siguientes cuestiones:

¿Qué funcionalidad debe entregarse al cliente?

¿Qué proceso se seguirá para entregarlo?

Para desarrollar un Plan de Proyecto razonable, tiene que descomponer funcionalmente el problema a resolver.

Esta descomposición proporciona más detalle antes del comienzo de la estimación.

La descomposición hace más fácil la planificación.


El Proceso

Quien gestione el proyecto deberá decidir qué modelo de proceso ( modelo en cascada, incremental, evolutivo, en espiral, métodos formales…) se deberá seguir para el desarrollo.

Factores a tener en cuenta para la elección del modelo de proceso:

El equipo software que desarrollará el sistema. (Si el equipo software es poco experimentado conviene modelos muy estructurados como el modelo en cascada).

Las características del producto en sí. (Si es un producto multimedia donde la interfaz de usuario tiene relevancia conviene un modelo incremental o evolutivo).

El entorno del proyecto. (Si es un entorno con un alto nivel de incertidumbre conviene un modelo incremental o evolutivo).


El Proceso

Después de la elección del modelo de proceso, en el Plan de Proyecto se define el conjunto de actividades necesarias para nuestro desarrollo (Ej, comunicación con el cliente, planificación, análisis del riesgo…)

Estas actividades reciben el nombre de actividades estructurales.

Para definir y analizar estas actividades es necesario:

Analizar el producto y el proceso: se estiman los recursos, fechas de inicio y fin y los productos a obtener para cada actividad.

Descomposición del proceso: Definir qué tareas serían necesarias para cada actividad.

Una vez se tiene claro el modelo de proceso y se conocen las actividades estructurales se puede elegir la metodología a

seguir. Siempre adaptándola al proyecto en cuestión.


El Proyecto

Para gestionar un proyecto con éxito debemos reconocer qué cosas pueden ir mal y qué debo hacer para evitarlas o solucionarlas en el caso de que sucedan.

John Reel define 10 señales que indican que un proyecto está en peligro:

1. El equipo software no entiende las necesidades de los clientes.

2. El ámbito está definido pobremente.

3. Cambios mal realizados.

4. La tecnología elegida cambia continuamente.

5. Las necesidades del negocio cambian o están mal definidas.

6. Las fechas de entrega no son realistas.

7. Los usuarios se resisten.

8. No se tienen patrocinadores.

9. El equipo software no tiene las habilidades apropiadas.

10. Los jefes de proyecto no hacen una buena gestión del equipo.


El Proyecto

Para evitar poner en peligro el proyecto:

1. Comprender claramente el problema a solucionar y establecer objetivos y expectativas realistas.

2. Elegir el equipo software adecuado y dotarlo de autonomía, autoridad y tecnología adecuada para realizar el trabajo.

3. Seguir de cerca el progreso del proyecto. Evaluar los productos que se generan en cada actividad.

4. Extraer y almacenar información útil al finalizar cada proyecto. (Ej. evaluar la estimación real y la estimada). Esto ayudará a tomar mejores decisiones en futuros proyectos.






Planificación

Estimación.






Índice


Esquema básico para la gestión

INICIO

SEGUIMIENTO Y

CONTROL DEL

PROYECTO

CIERRE DEL

PROYECTO

Estudio de viabilidad: Plan de negocio




Seguimiento de las tareas.

Seguimiento de las incidencias.

Inclusión en

histórico

de proyectos.

Archivo de la

documentación de

gestión del proyecto.

Ge

stión d

e la c

onfigura

ció

n

PLAN DEL

PROYECTO






Planificación

Estimación.






Índice


Estudio de viabilidad

¿Cómo podemos detectar oportunidades comerciales?

Concursos.

Detectar una necesidad.

Crear la necesidad en el cliente.

Divulgación y publicidad.


Estudio de viabilidad - Actividades

Estudio del alcance y objetivos.

Descripción del entorno.

Describir la situación actual del mercado.

Determinar la estrategia de mercado.

Crear planes operativos y de gestión.

Planear la estrategia de salida.

Pensar medidas de seguridad.

Hacer resumen y extraer conclusiones.


Estudio de viabilidad – Plan de negocio

El Plan de Negocio es un documento que define con claridad los objetivos de un negocio y describe los métodos que se van a emplear para alcanzar los objetivos.

Sirve como mapa de guía de la empresa.






Planificación

Estimación






Índice


Planificación de proyectos

Planificación de proyectos. Definición ◦ Conjunto de actividades previas a la puesta en

marcha del proyecto

◦ Objetivo Proporcionar un marco de trabajo que permita al gestor

hacer estimaciones razonables de recursos, coste y planificación temporal

◦ Incluye: Estimación

Planificación temporal

Planificación económica

Análisis y gestión del riesgo


Estimación Uno de los conceptos claves de la planificación.

Parámetros estimados:

Tiempo, esfuerzo, recursos (HW, SW, humanos) y riesgo

Difícil, pero no imposible. Existen técnicas útiles para la estimación del esfuerzo y del tiempo.

No es una ciencia exacta, aunque no debe descuidarse

La experiencia es un elemento muy importante en la estimación.

Se utilizan métricas para dar una estimación cuantitativa del esfuerzo y del tiempo

Planificación de proyectos: Estimación


Un destacado ejecutivo dijo, referente a la característica más importante que debe tener un gestor de proyectos: “..una persona con la habilidad de saber qué es lo que va a ir mal

antes de que ocurra y con el coraje para hacer estimaciones cuando el futuro no está claro…”

La estimación requiere experiencia y acceder a una buena información histórica.

Factores que condicionan la estimación:

Complejidad del proyecto.

Tamaño del proyecto.

La disponibilidad de la información histórica.

Grado de definición de los requisitos.



Modos de llevar a cabo la estimación:

Basar las estimaciones en proyectos similares.

Utilizar técnicas de descomposición.

Utilizar modelos empíricos

Utilizar herramientas automáticas



Técnicas de descomposición. Se descompone el software en funciones que se pueden estimar

individualmente. Para cada función se estiman las LDC y el PF.

Estimaciones de líneas de código (LDC)

Estimación basada en Puntos de Función (PF), Alan Albretch 1979 (IBM).

Ambas técnicas son distintas pero tienen aspectos comunes.

Cuando se utiliza LDC la descomposición es absolutamente esencial.

Utilizando LCD la descomposición se centra en las funciones del software.

Utilizando PF en lugar de centrarse en la función, se estiman características como: entradas, salidas, archivos de datos, peticiones e interfaces externas.



Modelos empíricos de estimación: COCOMO (COnstructive COst MOdel): es uno de los modelos de

estimación de coste del software más utilizados y estudiados en la industria.

El modelo original ha evolucionado al modelo COCOMO II.

El modelo COCOMO necesita información del tamaño del software. Para saber ese tamaño utiliza el punto objeto que mide el software por el número de pantallas de usuario, informes y componentes necesarios para construir la aplicación…







Planificación

Estimación.






Índice


Definición 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

Objetivo principal Configuración del calendario del proyecto

Origen Modelo de proceso, tareas de ingeniería, estimación de la cantidad de

trabajo, número de personas, fechas de entrega, riesgos… Resultado

Planificación del proyecto e información asociada para su seguimiento Documento estándar: IEEE Std 1058.1-1987

Elementos Definición de la red de tareas (completa) Esfuerzo y tiempo asignado a cada tarea Relaciones entre las tareas Recursos asignados a las tareas Espaciado de los “hitos” para poder hacer un seguimiento del progreso




Actividades principales:

Identificamos todas las tareas involucradas en el desarrollo del proyecto y hacemos un análisis de cada una de ellas: nombre, empiece, fin, duración, coste, descripción…

Identificamos las dependencias entre las tareas.



Las tareas tienen que ser sencillas pero sin incrementar demasiado las tareas de coordinación.

Han de tener unas entradas y han de producir unas salidas.


Planificación temporal - Actividades

Descomponer el proyecto en tareas.

Estimar la duración de cada una.

Determinar la fecha de inicio y de fin.

Se definen los hitos y el calendario de entregas al cliente.

Determinar el orden de ejecución.

Asignar a cada tarea un responsable.

Asignar recursos humanos y materiales a cada tarea.

Estimar el esfuerzo (personas + tiempo) necesario para llevar a cabo una tarea.


Planificación temporal – Determinar el orden de ejecución.

Se trata de establecer las relaciones de dependencia entre las tareas.

¿Qué es una dependencia?

Relación entre dos tareas, de tal manera que una de las tareas no puede empezar o acabar, hasta que no haya empezado o terminado otra. (tarea dependiente o sucesora / tarea predecesora).


Relación de final a comienzo.

Relación final a final.

Relación de comienzo a comienzo.

Relación de comienzo a final.

Planificación temporal – Determinar el orden de ejecución –

Relaciones de dependencia


Para llevar a cabo la planificación temporal existen diversas técnicas. Las más conocidas son:

Diagrama de hitos

Diagrama de Gantt

Diagrama de Pert

Planificación temporal Técnicas


Diagramas de hitos Es un cuadro o tabla formada por dos columnas:

Ventajas: facilidad de uso (es el método más simple) y mínimo coste de preparación (todo el mundo lo comprende inmediatamente)

Desventajas: incertidumbre existente sobre las fechas de comienzo de las actividades y la imposibilidad de reflejar las interrelaciones entre ellas.

Se utiliza para resumir calendarios complejos


Tarea Fecha fin

Tarea 1.1 Marzo-2006

Tarea 1.2 Mayo-2006

Tarea 1.3 Junio-2006

Tarea 2.1 Mayo-2006

Tarea 2.2 Agosto-2006

Tarea 2.3 Octubre-2006


Gráfico de tiempo (Diagrama de Gantt)

Diagrama de barras en forma de tabla donde se hace una

referencia cruzada entre las tareas (filas) y los tiempos de

duración (unidades de tiempo) de las mismas (columnas)

Muestra claramente la duración de las actividades y la

precedencia de unas tareas con respecto a otras.

Se utiliza frecuentemente en proyectos pequeños (menos de

25 actividades)

En un Diagrama de Gantt sería posible también reflejar las

dependencias entre actividades.

Expresa claramente los solapamientos entre actividades.



Gráfico de tiempo (Diagrama de Gantt)


Unidades de tiempo

1 2 3 4 5 6 7 8 9 10

Tarea 1.1

Tarea 1.2

Tarea 1.3

Tarea 2.1

Tarea 2.2

Tarea 2.3


Estrategia genérica. Diagrama de Gantt con MS Project




Pert (Project Evaluation Technique).

Técnica que nos permite planificar, evaluar y revisar un proyecto.

Representa las actividades de un proyecto y sus relaciones de dependencia temporal.

Facilita la asignación de recursos y la determinación del presupuesto.

Cuándo utilizar esta técnica: Actividades bien definidas

Actividades como entidades atómicas independientes

Las actividades pueden relacionarse entre sí y ser ordenadas

Existe una ejecución secuencial de las actividades

La red debería tener más de 20 eventos y menos de 300


Diagrama Pert

¿Qué es un hito/suceso?

Es un objetivo parcial del proyecto. Se obtiene un resultado importante.

¿Qué son tareas críticas?

Son aquellas que si varían su comienzo o su final, varía la fecha de fin del proyecto. Si no son críticas, son tareas móviles.

¿Qué es el camino crítico?

Conjunto de tareas críticas. Camino más largo, desde el inicio hasta el final. Representa la Duración del proyecto.



Diagrama Pert

Las tareas consumen recursos y ocurren entre dos sucesos.

Un suceso no consume recursos.

2

A

1

Suceso Suceso Tarea



Diagrama PERT. Principios

Relaciones de precedencia: actividades que deben estar finalizadas justamente antes del comienzo de la actividad dada

RELACIONES DE

PRECEDENCIA

LINEALES

RELACIONES DE

PRECEDENCIA

DIVERGENTES

1 2 3

RELACIONES DE

PRECEDENCIA

CONVERGENTES

A B

Para iniciar la actividad B es

necesario haber finalizado la

actividad A. El suceso 2 es

suceso final de A y suceso

inicio de B.

1

2

3

4 5

A

B

C

D

Para iniciar la actividad D es

necesario haber finalizado las

actividades A, B y C.

1

3

2

5

4A

B

C

D

Para poder iniciar cualquiera

de las actividades B, C, o D, es

necesario que haya finalizado

la actividad A.



Diagrama PERT. Asignación de tiempos a actividades

El siguiente paso es el cálculo de los tiempos early (tiempo más temprano posible) y last (tiempo más tardío posible) de cada suceso descrito en el grafo.

ATEi TLi TEj TLj

suceso i suceso j

Tiempo más temprano para comenzar la

actividad A (tiempo early de comienzo de A)

Tiempo más tardío para

comenzar la actividad A

Tiempo más temprano para

finalizar la actividad A

Tiempo más tardío para

finalizar la actividad A


Duración de la actividad


Diagrama PERT

Cálculo de los tiempos más tempranos (early)

El tiempo early del suceso j, que representamos por TEj, se calcula sumando los tiempos early de los sucesos en los que nace una actividad que finaliza en el suceso j, la duración de la actividad (Tij) y cogiendo el mayor de todos ellos

TEj = máx [ TEi + Tij ]

Siendo:

TEi el tiempo early del suceso i

Tij la duración de la actividad que comienza en el suceso i y finaliza en el suceso j



Diagrama PERT

Supongamos calculados los tiempos PERT de cada actividad:

Actividad A B C D E F G H

Duración 8 5 6 5 6 7 9 3

3

4

5

6

7A1 2

B

C

D

E

F

H

G

8

5

6

5

6

7

9

3

0 8

13

14

13

21

24

19

22



Diagrama PERT

Cálculo de los tiempos más tardíos (late)

El tiempo late del último suceso, coincide con su tiempo early

El resto de los tiempos late se calculan restando a los tiempos late de los sucesos en los que finalizan actividades que nacen en el suceso i, la duración de las actividades y escogiendo el menor de ellos.

TLi = min [ TLj - Tij ]

Siendo:

TLj el tiempo late del suceso j

Tij la duración de la actividad que comienza por el suceso i y finaliza en el suceso j



Diagrama PERT

3

4

5

6

7A1 2

B

C

D

E

F

H

G

8

5

6

5

6

7

9

3

0 8

13

14

13

21

24

19

22

24

21

15

15

1480

10

21

248



Holgura total de una actividad y camino crítico:

Holgura de un suceso i:

Hi = TLi - TEi

Indica el número de unidades de tiempo en que se puede retrasar su realización de forma que no se aumente la duración total del proyecto.

Se dice que un suceso es crítico si Hi = 0



Holgura total de una actividad y camino crítico:

Holgura total de una actividad:

HTij = TLj - TEi - Tij

Representa el número de unidades de tiempo que puede retrasarse la realización de la actividad con respecto al tiempo PERT previsto, sin que aumente la duración del proyecto.

Se dice que una actividad es crítica si la holgura total = 0



Holgura total de una actividad y camino crítico: Camino crítico: camino que se forma uniendo todas las

actividades críticas desde el suceso inicial al suceso final del proyecto

Cualquier retraso que sufra alguna de las actividades del camino crítico, implicará un retraso del proyecto.

El jefe de proyecto no debe sólo prestar atención a las actividades críticas sino también a las que no lo son, ya que si una actividad no crítica consume el total de su holgura, se convierte en crítica, y aparecería un nuevo camino crítico.



Holgura libre y holgura independiente de la actividad

Holgura libre de una actividad ij: tiempo que resulta de restar al tiempo early del suceso final el tiempo early del suceso inicial y la duración de la actividad:

HLij = TEj - TEi - Tij

Es lo que puede retrasarse una actividad sin que afecte a la fecha de comienzo más temprana (TE) de las de las tareas sucesoras.



Holgura libre y holgura independiente de la actividad

Holgura independiente de una actividad ij: tiempo que resulta de restar al tiempo early del suceso final el tiempo late del suceso inicial y la duración de la actividad.

HIij = TEj - TLi - Tij

Es lo que puede retrasarse una actividad sin que afecte a la fecha de comienzo más temprana (TE) de las tareas sucesoras habiendo empezado en su tiempo late (TL).



Si dos tareas tienen el mismo suceso de inicio y de fin, pero tienen diferente duración:

A=3

B=2

C=5

D=3

A=3

B=2

C=5

D=3

f


Conflictos entre tareas – Tareas ficticias


Cuando B es la sucesora de dos tareas, pero C no, sólo de una de ellas.

A=3 B=2

A=3 B=2

C=5 D=3

f

D=3 C=5


Conflictos entre tareas– Tareas ficticias


Actividad

sucesora

Actividad

predecesora

Duración

actividad

A - 2

B A 4

C B,H 1

D - 6

E G 3

F E 5

G D 2

H G 2

I D 3

J I 4

K D 3

L J,K 5

M C,L 2

EJERCICIO 1


Actividad

sucesora

Actividad

predecesora

Duración

actividad

A - 3

B A 3

C A 2

D B,C 4

E B,C 7

F C 2

H E,D,F 5

I F 8

J I 3

K H 6

EJERCICIO 2


EJERCICIO 3

Actividad

sucesora

Actividad

predecesora

Duración

actividad

A 2

B A 1

C 4

D A 2

E C,D 3

F D 4

G B 8

H G 1

I E 2

J F 3

K F 5

L H,I,J,K 9

M L 4


EJERCICIO 4

Actividad Actividades precedentes Duración

A B,D 3

B C 6

C J 4

D I, M 8

E I, M 9

F I, M 3

G H 5

H J 4

I J 2

J -- 3

K F, G 6

L A, E, P 4

M H 3

P F, G 7


Actividad Sucesores Duración

1 2 3

2 3,4 2

3 5 3

4 10, 11 5

5 8 0

6 9 7

7 15 10

8 6,7 17

9 14 1

10 12, 16 4

11 13, 17 6

12 14 8

13 15 10

14 15 2

15 18 2

16 18 4

17 18 4

18 19 2

19 Final 0

EJERCICIO 5


Planificación temporal Estrategia genérica

1. Se identifican las actividades.

2. Se estudia para cada actividad las relaciones de precedencia.

3. Se estudia la existencia de conflictos y su solución.

4. Se asignan los tiempos de cada actividad (TEi y TLi).

5. Se calculan las holguras.

6. Se elije el camino crítico.


Determinar las personas que van a trabajar en cada tarea.

El tiempo que van a dedicar.

Los materiales que van a utilizar.

Todo esto nos sirve para empezar la

planificación económica.

Planificación temporal Determinar el esfuerzo






Planificación

Estimación.






Índice


Consiste en hacer el estudio completo de los costes del proyecto y elaborar el presupuesto que vamos a entregar al cliente.

Planificación económica


Costes directos: Relación clara y específica entre lo que se ha producido y los recursos utilizados.

Nº de horas que ha trabajado una persona.

Costes indirectos: Costes con los que no se puede establecer una relación cuantificable entre el recurso y el producto.

Consumo de energía eléctrica.

Planificación económica – Conceptos


Costes variables: El coste aumenta o disminuye según unos parámetros de producción, tiempo dedicado, etc…

Costes fijos: El coste no varía cuando cambia la dedicación, el tiempo o el esfuerzo.

Planificación económica – Conceptos


Se consigue disminuir la duración de una tarea asignando más recursos de coste directo, pero:

Ley de Rendimientos Decrecientes: A partir de un cierto número de recursos de coste directo, cualquier incremento de éstos hace aumentar la duración de la tarea.

Ley de costes indirectos: Estos disminuyen cuando la duración de la tarea también disminuye, y a la inversa.

Solución DURACIÓN ÓPTIMA

Planificación económica – Duración y coste


Cada empleado supone un determinado coste directo:

Sueldos y salarios.

Cotizaciones obligatorias.

Cotizaciones voluntarias: asistencia sanitaria.

Prestaciones sociales directas: paro, jubilación, bajas.

Indemnizaciones: despidos improcedentes.

Otros: formación, transporte, comedores…

Planificación económica – Personal y coste


Se trata de personal que no pertenece a la empresa pero que interviene en el proyecto y cobra un sueldo.

Tipos:

Importe prefijado: independiente de los recursos dedicados.

Importe variable: sujeto al parámetro de la duración.

Planificación económica Subcontrataciones.


¿Por qué?

Permite abaratar los costes ya que una empresa especializada podría ejecutar el trabajo a un coste inferior que nosotros.

¿Para qué?

Para completar un área de conocimiento o una tarea específica del proyecto.

¿Cuándo?

Cuando esta infraestructura sólo se necesita para un proyecto concreto, y no compensa comprar.

Planificación económica Subcontrataciones.


Costes referentes a la infraestructura.

Representan el doble de los costes directos.

Proporcionales al consumo de recursos.

Coste de Hw y Sw: derivados del sistema informático.

Coste de consumibles: compra o alquiler de material.

Costes de infraestructuras.

Planificación económica – Costes indirectos


Analiza costes, beneficios, gastos e ingresos del proyecto.

Se evalúa la rentabilidad del proyecto a partir de unos indicadores de evaluación económica.

Planificación económica – Plan financiero






Planificación

Estimación.






Índice


Se identifican y se estudian todos aquellas situaciones que puedan desviar nuestro proyecto de su objetivo y ocasionar pérdidas económicas a la empresa.

Planificación de riesgos


¿Qué causas pueden suponer un riesgo?

Cambios en los requisitos.

Pensar en terminar rápido y que luego ya se refinará el producto.

Planificaciones demasiado optimistas (por falta de información de proyectos anteriores.)

No hacer un diseño.

Trabajar con herramientas nuevas.

Personal mediocre.

Fallan las subcontratas.

Malas relaciones entre el cliente y el personal de desarrollo.

Identificación de riesgos - Causas


Referente a la planificación.

Referente a la organización y la gestión.

Referente a la infraestructura.

Referente a los usuarios finales.

Referente al cliente.

Referente al personal contratado.

Referente a los requisitos.

Referente al producto.

Referente al diseño e implementación.

Referente al proceso.

Identificación de riesgos - Tipos


Cálculo de la probabilidad de riesgo.

Cálculo de la magnitud del riesgo.

Probabilidad Magnitud Impacto

de que suceda del riesgo del riesgo

Una vez sabemos el impacto de cada uno de

ellos los podemos priorizar.

Análisis de riesgos


Minimización de los riesgos: intentar que no ocurra la incidencia.

Resolución de las incidencias: Planificar las acciones que tendremos que tomar una vez sucede un riesgo y se convierte en incidencia.

Análisis de riesgos






Planificación

Estimación.






Índice


Seguimiento de las tareas:

Responsable: jefe de proyecto.

Comprueba la evolución de las tareas.

Ficha de seguimiento de tarea u otro tipo de herramienta.

Tipos de tareas de seguimiento:

Semanales.

Periódicas.

Reuniones urgentes: incidencias prioritarias.

Seguimiento y control


Se produce una incidencia:

Responsable de la tarea lo comunica al jefe de proyecto.

Se registra la incidencia en una ficha.

Si es prioritaria, reunión urgente.

Seguimiento de las incidencias:

Matriz de seguimiento de las incidencias no resueltas.

Seguimiento y control






Planificación

Estimación.






Índice


Cierre del proyecto

Se almacena toda esa información que el jefe de proyecto cree que será esencial para un futuro.

Se almacena en un histórico de proyectos.

Objetivo: ayuda, para proyectos futuros, a no cometer los mismos errores.


Dentro del histórico de proyectos existe el archivo de la documentación de gestión del proyecto.

Se guarda toda la información de gestión tanto en soporte magnético como en papel.

Creamos ficha para facilitar la consulta y reutilización de la información del archivo.

Cierre del proyecto


Roger S. Pressman. Ingeniería del Software: Un enfoque práctico. Capítulo 3. Ed. McGraw Hill. 5ª edición.2002

M. Piattini et al. Análisis y Diseño detallado de Aplicaciones Informáticas de Gestión. Ed. Ra-Ma. 1996

Bibliografía

Tema 7 Gestión de Proyectos

Ingeniería del Software I

[email protected]

Documents

Tema 7 Gestión de Proyectos - kybele.etsii.urjc.es · Ingeniería del Software I – 2011/2012 ¿Qué es un proyecto? – Objetivo El objetivo principal es obtener un resultado en