Gestin de Riesgo.

Una tarea importante del gestor de proyecto es anticipar los riesgos que podran
afectar a la programacin del proyecto o a la calidad del software a desarrollar y
emprender acciones para evitar esos riesgos. Los resultados de este anlisis de riesgo
se deben documentar a los largo del plan del proyecto junto con el anlisis de
consecuencias cuando el riesgo ocurra. Identificar stos y crear planes para minimiar sus
efectos en el proyecto se llama gestin de riesgos.
!e forma simple" se puede concebir un riesgo como una probabilidad de que una
circunstancia adversa ocurra. Los riesgos son una amenaa para el proyecto" para el
software que se esta desarrollando y para la organiacin. #stas categoras de riesgos se
definen como se muestra a continuacin$
%. &iesgo del proyecto$ ' #stos afectan la calendariacin o los recursos del proyecto.
Un ejemplo podria ser la perdida de un dise(ador e)perimentado.
*. &iesgos del producto$ '#stos afectan a la calidad o al rendimiento del software que
se esta desarrollando. Un ejemplo podria ser que el rendimiento en un
componente que +emos comprando sea menor que el esperado.
,. &iesgos del negocio$ ' -stos afectan a la organiacin que desarrolla o suministra
el software. .or ejemplo" que un competidor introduca un producto es un riesgo
de negocio.
.or supuesto" estos tipos no son e)clusivos entre s. /i un programador e)perto
abandona el proyecto" esto es un riesgo para el proyecto0 debido a que la entrega del
sistema se puede retrasar1" para el producto 0 debido a que un sustituto puede no ser tan
e)perto y cometer muc+oes errores1 y para el negocio 0 debido a que sea e)periencia
puede no contribuir a negocios futuros1.
Los riesgos que pueden afectar a un proyecto depende del propio proyecto y del
entorno organiacional donde se desarrolla. /in embargo" muc+os riesgos son
universales.La siguiente tabla muestra algunos de estos riesgos.
&otacin del personal .royecto .ersonal con e)periencia abandona el proyecto
antes de que finalice.
2ambio de gestin .royecto 3abr un cambio de gestin organiacional don
diferentes prioridades.
4o disponibilidad del
+w
.royecto #l 3w esencial para el proyecto no ser entregado
a tiempo.
2ambio de
requerimientos
.royecto y
producto
3abr ms cambio en los requerimientos de lo
esperado.
&etrasos en la
especificacin
.royecto y
producto
Las especificaciones de las interfaces esenciales
no estarn a tiempo.
/ubestimacin del
tama(o
.royecto y
producto
#l tama(o del sistema se +a subestimado.
5ajo rendimiento de la
+erramienta 26/#
.roducto Las +erramientas 26/# que ayudan al proyecto
no tienen el rendimiento esperado.
2ambio de tecnologa 4egocio Un producto competitivo se pone en venta antes
de que el sistema se complete.
2ompetencia del
producto
4egocio La tecnologa fundamento sobre la que se
construir el sistema se sustituye por nueva
tecnologa.
La gestin de riesgos es importante particularmente para los proyectos de software
debido a las incertidumbres in+erentes con las que se enfrentan muc+os proyectos. #stas
incertidumbre son el resultado de los requerimientos ambiguamente definidos" las
dificultades en la estimacin de tiempos y los recursos para el desarrollo del software" la
dependencia en las +abilidades individuales" y los cambios en los requerimientos debidos
a los cambios en las necesidades del cliente. #s preciso 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. #n el caso de que ocurran" se deben crear planes de
contingencia para que sea posible aplicar acciones de recuperacin.
#l proceso de gestin de riesgos. #ste 2omprende varias etapas$
%. Identificacin de riesgos$' identificar los posibles riesgos para el proyecto" el
producto y los negocios.
*. 6nlisis de riesgos$' 7alorar las probabilidades y consecuencias de estos riesgos.
,. .lanificacin de riesgos$ ' 2rear planes para abordar los riesgos" ya se para
evitarlos o minimiar sus efectos en el proyecto.
8. /upervisin de riesgos$ '7alorar los riesgos de forma constante y revisar los
planes para la mitigacin de riesgos tan pronto como la informacin de los riesgos
est disponibles.

#l proceso de gestin de riesgos" como otros de planificacin de proyectos" es un
proceso iterativo que se aplica a lo largo de todo el proyecto. Una ve que se genera un
conjunto de planes inciales" se supervisa la situacin. #n cuanto surjan ms informacin
acerca de los riesgos" stos deben analiarse nuevamente y se deben establecer nuevas
prioridades. La prevencin de riesgos y los planes de contingencia se deben modificar tan
pronto como surja nueva informacin de los riesgos.
Los resultados del proceso de gestin de riesgos se deben documentar en un plan
de gestin de riesgos. -ste debe incluir un estudio de los riesgos a los que se enfrenta el
proyecto" un anlisis de stos y los planes requeridos para su gestin. /i es necesario"
puede incluir algunos resultados de la gestin de riesgos$ por ejemplo" planes especficos
de contingencias que se activan si aparecen dic+os riesgos.
Identificacin de riesgos.
-sta es la primera etapa de la gestin de riesgos. 2omprende el descubrimiento
de los posibles riesgos del proyecto. #n principio" no +ay que valorarlos o darles prioridad
en esta etapa aunque" en la prctica" por lo general no se consideran los riesgos con
consecuencias menores o con baja probabilidad.
#sta identificacin se puede llevar a cabo a travs de un proceso de grupo utiliando
un enfoque de tormenta de ideas o simplemente puede basarse en la e)periencia. .ara
ayudar el proceso" se utilia una lista de posibles tipos de riesgos. 3ay al menos seis tipos
de riesgos que pueden aparecer$
%. &iesgos de tecnologa. /e derivan de las tecnologas de software o de +ardware
utiliadas en el sistema que se sta desarrollando.
*. &iesgos de personal. &iesgos asociados con las personas del equipo de
desarrollo.
,. &iesgos organiacionales. /e derivan del entorno organiacional donde el
software se est desarrollando.
8. &iesgos de +erramientas. /e derivan de +erramientas 26/# y de otro software de
apoyo utiliando para desarrollar el sistema.
9. &iesgos de requerimientos. /e derivan de los cambios de los requerimientos del
cliente y el proceso de gestionar dic+o cambio.
:. &iesgos de estimacin. /e derivan de los estimados administrativos de las
caractersticas del sistema y los recursos requeridos para construir dic+os
sistemas.
#n la siguiente tabla proporciona algunos ejemplos de riesgos posibles en cada una
de estas categoras. #l resultado de este proceso debe ser una larga lista de riesgos que
podran presentarse y afectar al producto" al proceso o al negocio.
;ipo de &iesgos !escripcin
;ecnologa. La base de datos que se utilia en el sistema no puede procesar
muc+as transacciones por segundo como se esperaba. Los
componentes de software que deben reutiliarse contienen defectos
que limitan su funcionalidad.
.ersonal #s imposible reclutar personal con las +abilidades requeridas para el
proyecto . #l personal clave est enfermo y no disponible en
momentos crticos. La capacitacin solicitada para el personal no
est disponible.
<rganiacional La organiacin se reestructura de tal forma que una gestin
diferente se responsabilia del proyecto. Los problemas financieros
de la organiacin fueran a reducciones en le presupuesto del
proyecto.
3erramientas #s ineficiente el cdigo generado por las +erramientas 26/#.
Las +erramientas 26/# no se pueden integrar.
&equerimientos /e proponen cambios en los requerimientos que requieren re+acer el
dise(o. Los clientes no comprenden el impacto de los cambios en los
requerimientos.
#stimacin #l tiempo requerido para desarrollar el software esta subestimado.
La tasa de reparacin de defectos esta subestimada.
#l tama(o del software esta subestimado.
Anlisis de Riesgos.
!urante este procese" se considera por separado cada riesgo identificado y se decide
acerca de la probabilidad y la seriedad del mismo. 4o e)iste una forma fcil de +acer esto
= recae en la opinin y e)periencia del gestor del proyecto. 4o se +ace una valoracin son
n>meros precisos sino en intervalos$
La probabilidad del riesgos se puede valorar como muy bajo 0 ? %@ A1" bajo 0%@'*9
A1" moderado 0 *9'9@ A1" alto 0 9@=B9 A1 o muy alto 0CB9 A1.
Los efectos del riesgos pueden ser valorados como catastrfico" serio" tolerable o
insignificante.
#l resultado de este proceso de anlisis se debe colocar en una tabla" la cual debe
estar ordenada seg>n la seriedad del riesgo. #n la tabla siguiente ilustra esto para los
riesgos identificados en la tabla anterior. <bviamente" aqu es arbitraria la valoracin de la
probabilidad y seriedad. #n la prctica" para +acer esta valoracin se necesita informacin
detallada del proyecto" el proceso" el equipo de desarrollo y la organiacin.
.or supuesto" tanto la probabilidad como la valoracin de los efectos de un riesgo
cambian conforme se disponga de mayor informacin acerca del riesgo y los planes de
gestin del mismo se implementen. .or lo tanto" esta tabla se debe actualiar durante
cada iteracin del proceso de riesgos.
Una ve que los riesgos se +ayan analiado y clasificados" se deben discernir
cuales son los ms importante que se deben considerar durante el proyecto. #ste
discernimiento debe depender de una combinacin de la probabilidad de aparicin del
riesgo y de los efectos del mismo. #n general" siempre se deben tener en cuenta todos
los riesgos catastrficos" as como todos los riesgos serios que tienen ms que una
moderada probabilidad de ocurrir.
Planificacin del riesgo.
#l proceso de planificacin del riesgo considera cada uno de los riesgos clave que +an
sido identificados" as como las estrategias para gestionarlos. <tra ve" no e)iste un
proceso sencillo que nos permita establecer los planes de gestin de riesgos. !epende el
juicio y de la e)periencia de gestor del proyecto. #stas estrategias seguidas pueden
dividirse en tres categoras$
%. #strategia de prevencin. /iguiendo estas estrategias" la probabilidad de que el
riesgo apareca se reduce. Un ejemplo de este tipo de estrategia es la estrategia
de evitacin de defecto en componentes.
*. #strategia de minimiacin. /iguiendo estas estrategias se reducir el impacto del
riesgo. U ejemplo de esto es la estrategia frente a enfermedad del personal.
,. .lanes de contingencia. /eguir estas estrategias es estar preparado para lo peor y
tener una estrategia para cada caso. Un ejemplo de este tipo de estrategia para
problemas financieros.
#n la tabla siguiente muestra posibles estrategias para los riesgos que +an sido
identificados.
.uede verse aqu una analoga con las estrategias utiliadas en sistemas crticos
para asegurar fiabilidad" proteccin y seguridad. 5sicamente" es mejor usar una
estrategia para evitar el riesgo. /i esto no es posible" utiliar una parte reducir los efectos
serios de los riesgos. Dinalmente tener estrategias para reducir el impacto del riesgo en el
proyecto y en el producto.
Supervisin de riesgos.
La supervisin de riesgos normalmente valora cada uno de los riesgos
identificados para decidir si ste es ms o menos probable y si +an cambiando sus
efectos. .or supuesto" esto 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.
<bviamente" estos factores dependen de los tipos de riesgos. La supervisin de riesgos
debe ser un proceso continuo y" en cada revisin del progreso de gestin" cada uno de los
riesgos clave debe ser considerado y analiado por separado. #n la tabla siguiente da
algunos ejemplos de los factores que ayudan en la valoracin de estos tipos de riesgos.
Control de la calidad.
#l control de la calidad implica vigilar el proceso de desarrollo de software para
asegurar que se siguen los procedimientos y los estndares de garantas de calidad. #n el
proceso de calidad del proyecto se comprueba que las entregas cumplan los estndares
definidos.
#)isten dos enfoques complementarios que se utilian para comprobar la calidad de
las entregas de un proyecto$
%. &evisin de la calidad donde el software" su documentacin y los procesos
utiliados en su desarrollo son revisados por el grupo de personas. /e encargan
de comprobar que se +an seguido los estndares del proyecto y el software y los
documentos concuerdan con estos estndares. /e toma nota de las desviaciones
de los estndares y se comunican el gestos del proyecto.
*. 7aloracin automtica del software en la que el software y los documentos
producidos se procesan por alg>n programa y se comparan con los estndares
que se aplican a ese proyecto de desarrollo en particular. #sta valoracin
automtica comprende una medida cuantitativa de algunos atributos el software.
La medicin y las mtricas del software.
Revisiones de la calidad.
Las revisiones son el mtodo ms utiliado para validar la calidad del un proceso o
de un producto. Involucran a un grupo de personas que e)aminan todo o parte del
proceso software" los sistemas o su documentacin asociada para descubrir problemas
potenciales. Las conclusiones se registran formalmente y se pasan al autor o a quien sea
responsable de corregir los problemas descubiertos.
La tabla siguiente describe varios tipos de revisiones" entre ellas las revisiones de
gestin de la calidad. Las revisiones de progreso son parte del proceso de gestin y los
diversos procesos de revisin tienen muc+as cosas en com>n.
#l equipo de revisiones debe tener un n>cleo de tres o cuatro personas como
revisores principales. Uno debe ser el dise(ador principal" el cual tendr la
responsabilidad de tomar las decisiones tcnicas. Los revisores principales pueden invitar
a otros miembros del proyecto" como a los dise(adores de los subsistemas" para que
colaboren en la revisin. #llos no se involucran en la revisin de todo el documento. Es
bien" se concentran en aquellas partes que afectan a su trabajo. !e forma alternativa" el
equipo de revisin +ace circular el documento a revisar y solicita comentarios escritos de
otros miembros del proyecto.
Los documentos a revisar deben distribuirse con anterioridad a la revisin para dar
tiempo a los revisores a que los lean y los comprendan. 6unque esto puede interrumpir el
proceso de desarrollo. La revisin no es efica si el equipo de revisin no comprende
adecuadamente los documentos antes de que tenga lugar la revisin.
La revisin mismo es relativamente corta 0 dos +oras a lo ms1. #l autor del
documento en revisin debe seguir e documento junto con el equipo de revisin. Un
miembro del equipo preside la revisin y otro registra formalmente todas las decisiones de
la revisin. !urante esta" el presidente es responsable de asegurar que se consideren
todos los comentarios escritos. #l responsable de la revisin firmara el registro de la
reunin" donde aparecern todos los comentarios y las decisiones tomadas. #ste registro
pasara a formar parte de la documentacin formal del proyecto. /i solo se descubren
problemas menores" no es necesaria ninguna revisin adicional. #l presidente es
responsable de asegurar que se +agan todos los cambios requeridos. /i se requieren
cambios importantes" +abr que +acer un seguimiento posterior de la revisin.