Red de Actividades de un Proyecto

Fig. 4.3 Red de Actividades de un Proyecto

Fig. 4.4 Gráfico de Gantt

Sin embargo, los retrasos de las actividades que no están ligadas a la trayectoria crítica no provocan necesariamente un aplazamiento en todo el calendario. Mientras que los retrasos no se propaguen a estas actividades como para que se exceda el tiempo total del camino crítico, el proyecto no se verá afectado. Por ejemplo, si T8 se retrasa, no se afectará la fecha final de terminación del proyecto puesto que no se encuentra sobre la trayectoria crítica.

Por lo tanto, el análisis del camino crítico nos indica quién debe esperar y para qué, a medida que se esta desarrollando el proyecto.  También nos informa sobre cuales son las actividades que deben ser terminadas dentro de lo planeado para evitar demoras.

Los administradores también utilizan las redes de actividades para asignar los tra­bajos en el proyecto. Dichas redes pueden dar una percepción en la dependencia de las actividades que de forma intuitiva no son obvias. Es posible modificar el diseño del sistema de tal forma que se acorte la trayectoria crítica. El calendario del proyecto se puede acortar debido a que se reduce la cantidad de tiempo de espera para finalizar las actividades.

La figura 4.4 es una forma alternativa de representar la información del calendario del proyecto. Es un gráfico de barras (también llamado gráfico de Gantt) que muestra el calendario de un proyecto y las fechas iniciales y finales de las actividades. Algunas de las actividades que se muestran en la figura 4.4 son seguidas por una barra sombreada cuya longitud muestra la ampli­tud de los posibles retrasos. Esto mues­tra que existe alguna flexibilidad en las fechas de terminación de estas actividades. Si alguna de éstas no se completa a tiempo, la trayectoria crítica no se afectará hasta el final del perio­do marcado por la barra sombreada. Las actividades que caen sobre dicha trayectoria no tienen margen de error y se distinguen por no tener asociada una barra sombreada.

Durante el desarrollo del proyecto, se deben comparar las estimaciones previstas con las reales. Esta comparación se puede utilizar como base para revisar la calendarización en las si­guientes partes del proyecto. Cuando se conozcan las cifras reales, se debe revisar la red de actividades. Después, se deben reorganizar las actividades posteriores para reducir la longitud de la trayectoria crítica.

4.4 GESTIÓN DE RIESGOS

Una tarea importante del administrador de proyectos es anticipar los riegos que podrían afectar la programación del proyecto o la calidad del software a desarrollar y empren­der acciones para evitar esos riesgos. Un riesgo es un evento no deseado que tiene consecuencias negativas. Los gerentes de proyecto deben ocuparse del análisis y la gestión de riesgos para comprender y controlar los riesgos en sus proyectos. Los resultados del análisis de riesgos se deben documentar a lo largo del plan del proyecto junto con el análisis de consecuencias cuando el riesgo ocurra. Identificar éstos y crear planes para minimizar sus efectos en el pro­yecto se llama administración o gestión de riesgos.

La administración de riesgos es importante particularmente para los proyectos de software debido a las incertidumbres inherentes que enfrentan muchos proyectos. Estas incertidumbres son el resultado de definir pobremente los requerimientos, las difi­cultades en la estimación de tiempos y los recursos para el desarrollo del software, la dependencia en las habilidades individuales, y los cambios en los requerimientos debidos a los cambios en las necesidades del cliente. El administrador de proyectos debe anticiparse a los riesgos; comprender el impacto de éstos en el proyecto, en el producto y en el negocio; y considerar los pasos para evitarlos. En el caso de que ocurran, se deben crear planes de contingencia para que sea posible aplicar acciones de recuperación.

4.4.1 ¿Qué es un riesgo?

De forma simple, se puede definir un riesgo como una probabilidad de que una circunstancia adversa ocurra. Los riesgos son una amenaza para el proyecto, para el soft­ware que se está desarrollando y para la organización. Son muchos los eventos que ocurren durante el desarrollo del software. Se distingue a los riesgos de otros eventos del proyecto examinando estos tres aspectos:

1. Una pérdida asociada con el evento. El evento debe crear una situación donde al proyec­to le pasen algunas cosas negativas: una pérdida de tiempo, de calidad, dinero, control, comprensión. Por ejemplo, si los requerimientos cambian drásticamente después de que se ha hecho el diseño, entonces el proyecto puede sufrir pérdidas de control y de com­prensión si tales nuevos requerimientos son para funciones o características con las cua­les el equipo de diseño no está familiarizado. Y es probable que un cambio radical en los requerimientos lleve a la pérdida de tiempo y dinero si el diseño no es lo suficientemen­te flexible para cambiar rápida y fácilmente. La pérdida asociada a un riesgo se denomi­na impacto del riesgo.

2. La probabilidad de que el evento pueda ocurrir. Se debe tener alguna idea de la probabi­lidad de que ocurra el evento. Por ejemplo, supongamos que un proyecto se está desa­rrollando en una máquina y puede transportarse a otra cuando el sistema esté completamente probado. Si la segunda máquina es un modelo nuevo a ser entregado por el vendedor, se debe estimar la probabilidad de que no esté listo en tiempo. La probabili­dad del riesgo, medida desde 0 (imposible) hasta 1 (certeza), se denomina probabilidad de riesgo. Cuando la probabilidad de riesgo es 1, entonces el riesgo se denomina pro­blema, dado que hay certeza de que suceda.

3. El grado en que se puede cambiar el resultado. Para cada riesgo, se debe determinar qué se puede hacer para minimizar o evitar el impacto del evento. El control de riesgo involu­cra un conjunto de acciones tomadas para reducir o eliminar un riesgo. Por ejemplo, si los requerimientos pueden cambiar después del diseño, se puede minimizar el impacto del cambio creando un diseño flexible. Si la segunda máquina no está lista cuando el software esté probado, hay que ser capaz de identificar otros modelos o marcas que ten­gan la misma funcionalidad y desempeño, y puedan ejecutar el nuevo software hasta que se entregue el nuevo modelo.

4.4.2 Tipos de Riesgos

Hay dos fuentes principales de riesgos: los riesgos genéricos y los riesgos específicos del proyecto. Los riesgos genéricos son aquellos comunes a todos los proyectos de software, tales como entender mal los requerimientos, perder personal clave o dejar tiempo insuficiente para las pruebas. Los riesgos específicos del proyecto son amenazas que resultan de las vulnerabilidades particulares de un proyecto dado. Por ejemplo, un vendedor puede prometer un software de red para una fecha particular, pero hay algún riesgo de que ese software no esté listo a tiempo.

Los tipos de riesgo que pueden afectar un proyecto dependen de éste y el entorno organizacional en el que se esté desarrollando el mismo. Sin embargo, muchos riesgos son universales; la tabla 4.3 describe algunos de ellos.

Tabla 4.3 Riesgos posibles en el software

Riesgo	Tipo de Riesgo	Descripción
Rotación de personal	Proyecto	Personal con experiencia abandona el proyecto antes de que finalice.
Cambio de administración	Proyecto	Habrá un cambio de administración organizacional con diferentes prioridades
No disponibilidad del hardware	Proyecto	El hardware esencial para el proyecto no será entregado a tiempo.
Cambio de requerimientos	Proyecto y producto	Habrá más cambios en los requerimientos que lo anticipado.
Retrasos en la especificación	Proyecto y producto	Las especificaciones de las interfaces esenciales no estarán a tiempo.
Subestimación del tamaño	Proyecto y producto	El tamaño del sistema se ha subestimado.
Bajo desempeño de la herramienta CASE	Producto	Las herramientas CASE que ayudan al pro­ yecto no tienen el desempeño anticipado.
Cambio de tecnología	Negocio	La tecnología fundamental sobre la que se construirá el sistema se sustituye por nueva tecnología.
Competencia del producto	Negocio	Un producto competitivo se pone en ven­ta antes de que el sistema se complete.

4.4.3 Actividades de la gestión del riesgo

La gestión del riesgo involucra varias etapas importantes, cada una de las cuales se ilustra en la Figura 4.5. Primero, se determinan los riesgos del proyecto, de manera de entender qué puede ocurrir durante el desarrollo o el mantenimiento. Esta determinación consiste de tres actividades: identificar los riesgos, analizarlos y asignarles prioridades a cada uno de ellos..

Si el sistema que se está construyendo es en alguna forma similar a uno construido con anterioridad, ya se tendrá una lista de los problemas que pueden ocurrir, y por ende se podrá revisar esa lista para determinar si el nuevo proyecto estará sujeto a los riesgos mencionados. Para sistemas que son nuevos en alguna forma, se puede engrosar la lista con un análisis de cada una de las actividades en el ciclo de desarrollo; descomponiendo el proceso en pequeñas partes, se llega a ser capaz de anticiparse a problemas que puedan aparecer. Por ejemplo, se decide que existe el riesgo de que el jefe de diseño renuncie durante el diseño. De manera similar, se pueden analizar las suposiciones o las decisiones que se hacen sobre cómo se harán los proyectos, quién los hará y con qué recursos. Entonces, cada suposición determina los riesgos involucrados.

El proceso de administración de riesgos comprende varias etapas:

1.   Identificación de riesgos. Identificar los posibles riesgos para el proyecto, el pro­ducto y los negocios.

2.   Análisis de riesgos.  Valorar las probabilidades y consecuencias de estos riesgos.

3.   Planeación de riesgos. Priorizar los riesgos y crear planes para abordarlos, ya sea para evitar­los o minimizar sus efectos en el proyecto.

4.   Supervisión de riesgos  . Valorar los riesgos de forma constante y revisar los planes para la mitigación de riesgos tan pronto como la información de los riesgos esté disponible.

El proceso de administración de riesgos, como otros de planeación de proyectos, es un proceso iterativo que se aplica a lo largo de todo el proyecto. Una vez que se genera un conjunto de planes iniciales, se supervisa la situación. En cuanto surja más informa­ción acerca de los riesgos, éstos se deben analizar nuevamente y establecer nuevas prio­ridades. La prevención de riesgos y los planes de contingencia se deben modificar tan pronto como surja nueva información de los riesgos.

Los resultados del proceso de administración de riesgos se deben documentar en un plan de administración de riesgos. Esto debe incluir una discusión de dichos riesgos a los que se enfrenta el proyecto, un análisis de éstos y los planes requeridos para su administración. Si es necesario, puede incluir algunos resultados de la administración de riesgos, por ejemplo, planes específicos de contingencia que se activan si dichos riesgos ocurren.

Fig. 4.5 El proceso de administración de riesgos

4.4.3.1 Identificación de Riesgos

Ésta es la primera etapa de la administración de riesgos. Comprende el descubrimiento de los posibles riesgos del proyecto. En principio, no se les debe valorar o priorizar en esta etapa aunque, en la práctica, por lo general no se consideran los riesgos con con­secuencias menores o con baja probabilidad.

Esta identificación se puede llevar a cabo a través de un proceso de grupo utilizando un enfoque de lluvia de ideas o simplemente puede basarse en la experiencia del admi­nistrador. Para ayudar al proceso, se utiliza una lista de posibles tipos de riesgos. Estos tipos incluyen:

1.   Riesgos de tecnología. Éstos se derivan de las tecnologías de software o de hard­ware utilizadas en el sistema que se está desarrollando.

2.   Riesgos de personas. Riesgos asociados con las personas en el equipo de desa­rrollo.

3.   Riesgos organizacionales. Éstos se derivan del entorno organizacional donde el software se está desarrollando.

4.   Riesgos de herramientas.  Éstos se derivan de herramientas CASE y de otro soft­ware de apoyo utilizado para desarrollar el sistema.

5.   Riesgos de requerimientos. Éstos se derivan de los cambios de los requerimientos del cliente y el proceso de administrar dicho cambio.

6.   Riesgos de estimación. Éstos que se derivan de los estimados administrativos de las características del sistema y los recursos requeridos para construir dicho sistema.

La tabla 4.4 da algunos ejemplos de riesgos posibles en cada una de estas catego­rías. El resultado de este proceso debe ser una larga lista de riesgos que podrían ocurrir y afectar el producto, el proceso o el negocio.

4.4.3.2 Análisis de Riesgos

Durante éste proceso, se considera por separado cada riesgo identificado y se decide acerca de la probabilidad y la seriedad del mismo. Esto recae en la opinión y experiencia del administrador del proyecto. No se hace una valoración con números precisos sino en intervalos:

1.   La probabilidad de que el riesgo se valore 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ófico, serio, tolerable o insignificante.

El resultado de este proceso de análisis se debe colocar en una tabla, la cual debe estar ordenada acorde a la seriedad del riesgo. La tabla 4.5 ilustra esto para los ries­gos identificados en la tabla 4.4. Obviamente, aquí es arbitraria la valoración de la probabilidad y seriedad. En la práctica, para hacer esta valoración se necesita informa­ción detallada del proyecto, el proceso, el equipo de desarrollo y la organización.

Por supuesto, tanto la probabilidad y la valoración de los efectos de un riesgo cambia conforme se disponga de mayor información acerca del riesgo y los planes de adminis­tración del mismo se implementen. Por lo tanto, esta tabla se debe actualizar durante cada iteración del proceso de riesgos.

Tabla 4.4 Riesgos por Tipo de Riesgo

Tipo de Riesgo	Riesgos Posibles
Tecnología	La base de datos que se utiliza en el sistema no puede procesar muchas transacciones por segundo como se esperaba. Los componentes de software a reutilizarse contienen defectos que limitan su funcionalidad.
Personas	Es imposible reclutar personal con las habilidades requeridas para el proyecto. El personal clave está enfermo y no disponible en momentos críticos. La capacitación solicitada para el personal no está disponible.
Organizacional	La organización se reestructura de tal forma que una administración diferente se responsabiliza del proyecto Los problemas financieros de la organización fuerzan a reducciones en el presupuesto del proyecto.
Herramientas	Es ineficiente el código generado por las herramientas CASE. Las herramientas CASE no se pueden integrar.
Requerimientos	Se proponen cambios en los requerimientos que requieren rehacer el diseño. Los clientes no comprenden el impacto de los cambios en los requerimientos.
Estimación	El tiempo requerido para desarrollar el software está subestimado. La tasa de reparación de defectos está subestimada. El tamaño del software está subestimado.

Se pueden cuantificar los efectos de los riesgos que se identifican, multiplicando el impacto del riesgo por la probabilidad del mismo, para obtener la exposición del riesgo.

Una vez que los riesgos se hayan analizado y clasificado, se debe discernir cuáles son los más importantes que se deben considerar durante el proyecto. Este discernimiento depende de una combinación de la probabilidad del riesgo en cuestión y los efectos del mismo. En general. siempre se deben tomar en cuenta todos los riesgos catastró­ficos: así como todos los riesgos serios que tienen más que una moderada probabilidad de ocurrir.

Tabla 4.4 Análisis de Riesgos

Riesgo	Probabilidad	Efectos
Los problemas financieros de la organización fuerzan a reducir el presupuesto del proyecto.	Baja	Catastrófico
Es imposible reclutar personal con las habilidades requeridas para el proyecto.	Alta	Catastrófico
El personal clave está enfermo y no disponible en momentos críticos.	Moderada	Serio
Los componentes de software a reutilizarse contienen defectos que limitan su funcionalidad	Moderada	Serio
Se proponen cambios en los requerimientos que requieren rehacer el diseño.	Moderada	Serio
La organización se reestructura de tal forma que una administración diferente se responsabiliza del proyecto.	Alta	Serio
La base de datos que se utiliza en el sistema no puede procesar muchas transacciones por segundo como se esperaba.	Moderada	Serio
El tiempo requerido para desarrollar el software está subestimado.	Alta	Serio
Las herramientas CASE no se pueden integrar.	Alta	Tolerable
Los clientes no comprenden el impacto de los cambios en los requerimientos.	Moderada	Tolerable
La capacitación solicitada para el personal no está disponible.	Moderada	Tolerable
La tasa de reparación de defectos está subestimada.	Moderada	Tolerable
El tamaño del software está subestimado.	Alta	Tolerable
Es ineficiente el código generado por las herramientas CASE.	Moderada	Insignificante

Boehm (1991) identifica los "10 riesgos más altos" y recomienda técnicas de gestión de riesgos para localizarlos (ver el recuadro siguiente). Sin embargo, el número exacto de riesgos a supervisar debe depender del proyecto, pero debe ser manejable. Un número muy grande de riesgos requiere obtener mucha información.

LOS ITEMS DE MÁS ALTO RIESGO SEGÚN BOEHM

1.            Deficiencias del personal. Formar el plantel con personal con gran talento, equilibrar el trabajo, conformación del equipo, edificación de la moral del grupo, entrenamiento cruzado, planificación previa de las personas claves.

2.            Cronogramas y presupuestos no realistas. Estimación detallada del cronograma y de costos con múltiples orígenes, diseño conforme a los costos, desarrollo por incrementos, reutilización del software, depuración de los requerimientos.

3.            Desarrollo de funciones de software incorrectas. Análisis organizacional, análisis de la misión del sistema, formulación de conceptos de operación, estudios de los usuarios, prototipado, preparación temprana de los manuales de usuario.

4.            Desarrollo de interfaces de usuario incorrectas. Prototipado, aplicación de escenarios, análisis de tareas.

5.            Expectativas imposibles de satisfacer. Depuración de los requerimientos, prototipado, análisis costo-beneficio, diseño conforme a los costos.

6.            Constantes cambios a los requerimientos. Umbral alto para el cambio, ocultamiento de información, desarrollo por incremento (posponer los cambios hasta incrementos posteriores).

7.            Deficiencias en tareas ejecutadas externamente. Comprobación de referencias, auditorías pre-adjudicación, contratos adjudicados por cuota, diseño competitivo o prototipado, construcción del equipo.

8.            Deficiencias de componentes suministrados externamente. Pruebas comparativas (benchmarking) inspecciones, comprobación de referencias, análisis de compatibilidad.

9.            Deficiencias del funcionamiento en tiempo real. Simulación, pruebas comparativas, modelado, prototipado, instrumentación, afinado.

10.        Forzar al límite las capacidades de la informática. Análisis técnico, análisis costo-beneficio, prototipado, comprobación de referencias.

4.4.3.3 Planeación y Control de Riesgos

El análisis de riesgos ayuda a listar los riesgos en orden de prioridad asignándole la prioridad más alta al riesgo de mayor preocupación. Luego, se deben determinar los pasos para controlar los riesgos. El concepto de control reconoce que no se puede ser capaz de eliminar todos los riesgos. En lugar de ello, se puede ser capaz de minimizar el riesgo o mitigarlo, tomando las acciones para manejar el resultado no deseado en una forma aceptable. Por lo tanto, el control del riesgo involucra la reducción del riesgo, su planificación y su resolución.

Hay tres estrategias para la reducción de riesgos:

1.  Anular o evitar el riego. Reducir la probabilidad de que el riesgo surja cambiando los requerimientos de desempeño o funcionalidad. Por ejemplo, cambiar los componentes defectuosos por otros de confiabilidad probada.

2.  Disminuir o transferir el riesgo. Reducir el impacto del riesgo asignando riesgos a otros sistemas o comprando seguros para cubrir cualquier pérdida financiera. Por ejemplo, contar con varias personas que conozcan y puedan realizar el trabajo de otras para poder sustituir a un desarrollador que se enferme.

3. Planes de contingencia. Asumir el riesgo, aceptándolo y controlándolo con los recursos del proyecto. Si sucede lo peor, se está preparado para ello y se cuenta con una estrategia para abordarlo. Por ejemplo, si hay problemas de flujo de recursos financieros, contar con un plan de reducción de costos o de reducción del ritmo de trabajo.

Para colaborar con la toma de decisiones acerca de la reducción de los riesgos, se debe tener en cuenta el costo de reducción del riesgo. Se denomina influencia del riesgo a la diferencia en la exposición del riesgo dividida por el costo de reducir el riesgo. En otras palabras, la influencia en la reducción del riesgo es:

(exposición al riesgo antes de la reducción - exposición al riesgo después de la reducción)

(costo de la reducción del riesgo)

Si el valor de la influencia no es lo suficientemente alto para justificar la acción, entonces se pueden contemplar técnicas de reducción menos costosas o más efectivas.

En algunos casos, se puede elegir un proceso de desarrollo para ayudar a reducir el riesgo. Por ejemplo, los prototipos pueden mejorar la comprensión de los requerimientos y del diseño, de manera que la selección de un proceso de prototipado puede reducir muchos riesgos del proyecto.

Es útil registrar las decisiones en un plan de gestión del riesgo, de modo que tanto el cliente como el equipo de desarrollo puedan revisar cómo pueden evitarse los problemas, y también cómo deben manejarse cuando aparecen. Entonces, se debe monitorear el proyecto a medida que avanza su desarrollo, reevaluando periódicamente los riesgos, su probabilidad y su posible impacto