El fracaso de muchos proyectos grandes de software en los 60 y

Ingeniería de Software
FCC-BUAP
Otoño 2003
Fig. 4.3 Red de Actividades de un Proyecto
Fig. 4.4 Gráfico de Gantt
44
Ingeniería de Software
FCC-BUAP
Otoño 2003
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 trabajos 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
amplitud de los posibles retrasos. Esto muestra que existe alguna flexibilidad en las fechas de
terminación de estas actividades. Si alguna de éstas no se completa a tiempo, la traye ctoria
crítica no se afectará hasta el final del periodo 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 siguientes 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 emprender 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 proyecto 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 dificultades 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.
45
Ingeniería de Software
FCC-BUAP
Otoño 2003
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 software 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
proyecto 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 comprensión si tales
nuevos requerimientos son para funciones o características con las cuales 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 suficientemente flexible para cambiar rápida y
fácilmente. La pérdida asociada a un riesgo se denomina impacto del riesgo.
2. La probabilidad de que el evento pueda ocurrir. Se debe tener alguna idea de la
probabilidad de que ocurra el evento. Por ejemplo, supongamos que un proyecto se está desarrollando 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 probabilidad 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 problema, 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
involucra 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 tengan 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
Rotación de personal
Tipo de
Riesgo
Proyecto
Descripción
Personal con experiencia abandona el proyecto antes
de que finalice.
46
Ingeniería de Software
FCC-BUAP
Otoño 2003
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 venta 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 enten der
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 producto 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
evitarlos 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 v ez 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.
47
Ingeniería de Software
FCC-BUAP
Otoño 2003
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 consecuencias 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 administrador. 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 hardware utilizadas en el sistema que se está desarrollando.
2. Riesgos de personas. Riesgos asociados con las personas en el equipo de desarrollo.
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 software 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 categorí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.
48
Ingeniería de Software
FCC-BUAP
Otoño 2003
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 informació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 pl anes de
administració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
Tecnología
Riesgos Posibles
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.
Es imposible reclutar personal con las habilidades requeridas para el p royecto.
Personas
El personal clave está enfermo y no disponible en momentos críticos.
La capacitación solicitada para el personal no está disponible.
Organizacional
Herramientas
Requerimientos
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.
Es ineficiente el código generado por las herramientas CASE.
Las herramientas CASE no se pueden integrar.
Se proponen cambios en los requerimientos que requieren rehacer el diseño.
Los clientes no comprenden el impacto de los cambios en los requerimientos.
El tiempo requerido para desarrollar el software está subestimado.
Estimación
La tasa de reparación de defectos está subestimada.
El tamaño del software está subestimado.
49
Ingeniería de Software
FCC-BUAP
Otoño 2003
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.
50
Ingeniería de Software
FCC-BUAP
Otoño 2003
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, pla nificació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 costobeneficio, 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 preadjudicació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
51
Ingeniería de Software
FCC-BUAP
Otoño 2003
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
52