Gestin de Riesgos del software:

Principios y prcticas
Barry W. Boehm, TRW
1. Introduccin
Como muchos campos en sus primeras etapas, el campo del software ha
tenido su parte de los desastres del proyecto: los equivalentes de
software de la catedral de Beauvais, el SS Titanic, y el "galopante Gertie"
Tacoma Narrows Bridge. La frecuencia de estos proyectos de desastres
es una preocupacin seria: una reciente encuesta de 600 empresas se
indica que el 35% de ellos tena al menos un "proyecto de software fuera
de control" [1].
La mayora de las autopsias de estos proyectos de desastre software han
indicado que se habran evitado sus problemas o muy reducido si se
haba producido una de las primeras preocupaciones explcito con la
identificacin y solucin de sus elementos de alto riesgo. Con frecuencia,
estos proyectos fueron arrastrados por una ola de entusiasmo optimista
durante sus primeras fases, lo que provoc que se perdieran algunas
seales claras de temas de alto riesgo, que result ser la cada del
proyecto ms adelante.
El entusiasmo por las nuevas capacidades de software es una buena
cosa. Pero tiene que ser templado con una preocupacin por la
identificacin y resolucin de elementos de alto riesgo de un proyecto
temprano, as que la gente puede conseguir stos resuelvan pronto y
luego centrar su entusiasmo y energa en los aspectos positivos de su
producto de software.
Los enfoques actuales para el proceso de software hacen que sea muy
fcil para los proyectos de software para hacer compromisos de alto
riesgo que van a arrepentir ms tarde. El modelo de proceso "cascada"
documento impulsado secuencial tienta a la gente a prometer
capacidades de software en el contrato vinculante especificaciones de
requisitos antes de entender sus implicaciones de riesgo. El modelo de
proceso de desarrollo evolutivo cdigo impulsada tienta a la gente diga:
"Aqu estn algunas ideas aseadas que me gustara poner en este
sistema. Voy a codificarlos, y si no se ajustan a las ideas de otros, vamos
a simplemente evolucionar las cosas hasta que funcionen ". Este tipo de
enfoque funciona bien en algunos mini-dominios bien apoyado, como las
aplicaciones de hojas de clculo, pero en los dominios de aplicacin ms
complejos, lo ms a menudo crea o descuida elementos de alto riesgo
intrnsecos y lidera el proyecto por el camino al desastre.
En TRW y en otros lugares, he tenido la suerte de observar muchos
gerentes de proyectos de software en el trabajo de primera mano, y
para tratar de comprender y aplicar los factores que distinguan a los
directores de proyectos ms exitosos de los menos
que tienen xito. Algunos fueron capaces de utilizar con xito un
enfoque de cascada, otros utilizaron con xito un enfoque de desarrollo
evolutivo, y otros orquestados con xito mezclas complejas de estos y
otros enfoques que implican la creacin de prototipos, simulacin,
software comercial, especificaciones ejecutables, equipos tigre,
concursos de diseo, subcontratacin, y varios tipo de costo-beneficio
anlisis.
Un patrn que surgi con mucha fuerza fue que los directores de
proyectos exitosos fueron buenos gestores de riesgos. A pesar de que en
general no utilizan trminos tales como la identificacin de riesgos,
evaluacin de riesgos, la planificacin de la gestin de riesgos, o de
seguimiento de riesgos, eso es lo que estaban haciendo. Y sus proyectos
tendan a evitar las trampas y producir buenos productos.
La disciplina que ha surgido recientemente de la gestin del riesgo de
software representa un intento de formalizar estos correlatos orientados
al riesgo de xito en un conjunto de fcil aplicacin de los principios y
prcticas. Sus objetivos son identificar, abordar y eliminar los elementos
de riesgo de software antes de que se conviertan en amenazas para la
operacin sea exitosa o software de las principales fuentes de retrabajo
software.
Pasos de Gestin de Riesgos
Como se observa en la Figura 1, la prctica de la gestin del riesgo
implica dos pasos principales, Evaluacin de Riesgos y Control de
Riesgos, cada uno con tres pasos subsidiarios. Evaluacin de riesgos
consiste en la identificacin de riesgos, anlisis de riesgos, y la
priorizacin de riesgos. Control de Riesgos consiste en la planificacin de
gestin de riesgos, la resolucin de riesgo y seguimiento del riesgo.
Identificacin de Riesgos produce listas de los elementos de riesgo
especficos para el proyecto que puedan poner en peligro el resultado
satisfactorio de un proyecto. Las tcnicas tpicas de identificacin de
riesgos incluyen listas de verificacin, la descomposicin, la
comparacin con la experiencia, y el examen de los conductores de
toma.
Anlisis de Riesgos produce evaluaciones de la de probabilidad de
prdidas y lossmagnitude asociado con cada uno de los elementos de
riesgo identificados, y las evaluaciones de riesgos compuestos
implicados en las interacciones del riesgo-tem. Tcnicas tpicas incluyen
el anlisis de redes, rboles de decisin, modelos de costos, modelos de
rendimiento, y el anlisis de decisin estadstica.
Priorizacin de riesgos produce una ordenacin priorizada de los
elementos de riesgo identificados y analizados. Las tcnicas tpicas
incluyen el anlisis de riesgo de apalancamiento reduccin, con especial
participacin de anlisis de costo-beneficio, y Delphi o tcnicas
groupconsensus.
Planificacin de la Gestin de Riesgos produce planes para hacer frente
a cada elemento de riesgo (por ejemplo, a travs de la cobertura de
riesgos, la transferencia del riesgo, reduccin de riesgos, o informacin
de la compra), incluyendo la coordinacin de los planes de riesgos
individuales de los elementos entre s y con el plan general del proyecto.
Tcnicas tpicas incluyen listas de control de riesgos

tcnicas de resolucin, el anlisis de costo-beneficio, y el plan de gestin

de riesgos norma resume, formas y elementos.
Resolucin de riesgo produce una situacin en la que los elementos de
riesgo son eliminados o no resueltos (por ejemplo, la cobertura de
riesgos a travs de la relajacin de los requisitos). Tcnicas tpicas
incluyen prototipos, simulaciones, puntos de referencia, anlisis de
misin, los acuerdos relativos al personal clave, los enfoques de diseo a
costos y desarrollo incremental.
Seguimiento de Riesgos implica el seguimiento de los progresos del
proyecto hacia la resolucin de sus elementos de riesgo y tomar
medidas correctivas cuando corresponda. Las tcnicas tpicas incluyen el
seguimiento hito plan de gestin de riesgos y un Top Ten de la lista de
artculos de riesgos que se destaca en cada, mensual o revisin semanal
proyecto hito.
Adems, la gestin de riesgos proporciona una forma mejorada de
direccionamiento y la organizacin del ciclo de vida del software.
Enfoques de riesgo impulsada, como el Modelo Espiral del proceso de
software [2], evitar muchas de las dificultades encontradas en los
modelos de procesos anteriores, como el modelo de cascada y el modelo
de desarrollo evolutivo. Tales enfoques impulsados por riesgo tambin
muestran cmo y dnde incorporar las nuevas tecnologas de software,
como el prototipado rpido, idiomas fourthgeneration, y productos de
software comercial en el ciclo de vida del software.
La siguiente seccin de este artculo proporciona las definiciones de los
trminos de gestin del riesgo de software y conceptos bsicos. La
siguiente seccin describe e ilustra algunos de los principios de gestin
del riesgo de software primario y prcticas identificadas en la Figura 1.
En la ltima seccin ofrece una visin general del uso de la gestin de
riesgos en todo el ciclo de vida del software, y se presenta un resumen
general de los puntos clave del artculo. A continuacin, el artculo que
acompaa a ste [3] se debatir la aplicacin de los principios y
prcticas de gestin de riesgos para una aplicacin de software intensivo
grande: el Sistema de Automatizacin Avanzada FAA.
2. Definiciones de Gestin de Riesgos y conceptos bsicos
definiciones
Webster define "riesgo" como "la posibilidad de prdida o lesin." Esta
definicin se puede traducir en el concepto fundamental de la gestin de
riesgos: el concepto de la exposicin al riesgo (RE), a veces tambin
llamado impacto del riesgo. Exposicin al Riesgo se define por la
relacin.
RE= Prob(UO)*Loss(UO)
donde Prob (UO) es la probabilidad de un resultado insatisfactorio y
Prdida (UO) es la prdida de las partes afectadas si el resultado no es
satisfactorio.
Para relacionar esta definicin a las situaciones de proyectos de
software, necesitamos una definicin de "resultado satisfactorio". Dado
que los proyectos de software implican varias clases de participantes
(cliente, desarrollador, usuario, mantenedor), cada uno con un poco
diferentes, pero muy importantes criterios de satisfaccin, podemos ver
que "resultado insatisfactorio" es multidimensional. Para los clientes y
desarrolladores, excesos de presupuesto y boletas de programacin no
son satisfactorios. Para los usuarios, los productos con la funcionalidad
mal, dficit de interfaz de usuario, los dficit de rendimiento, o dficit de
confiabilidad no son satisfactorios. Para mantenedores, software pobre
qualitv no es satisfactoria.
Estos componentes de un resultado insatisfactorio proporcionan una
lista de control de alto nivel para identificar y valorar los elementos de
riesgo de software. Listas de verificacin ms detalladas sern cubiertos
bajo Identificacin de Riesgos a continuacin.
Conceptos bsicos: exposicin al riesgo y rboles de decisin
Uno de los paradigmas fundamentales de anlisis de riesgos es el rbol
de decisin. Un ejemplo se muestra en la Figura 2. Se ilustra una
situacin potencialmente peligrosa que implica el software que controla
un experimento de nave espacial. El software ha estado en desarrollo
por el equipo de experimento, que entienden su experimento bien, pero
no tienen experiencia y algo informal sobre el desarrollo de software.
Como resultado, el gestor de la plataforma por satlite ha obtenido una
estimacin de que hay una probabilidad P (UO) de 0.4 que el software de
los experimentadores tendr un error crtico: una que acabar con todo
el experimento y causar una prdida asociada L (UO ) de la inversin
total de US $ 20 millones en el experimento.
El gestor de la plataforma por satlite identifica dos grandes opciones
para reducir el riesgo de perder el experimento:
Convencer y ayudando al equipo experimento de aplicar mejores
mtodos de desarrollo de software. Esto incurre en ningn coste
adicional, y de la experiencia previa del gerente estima que esto
reducir la probabilidad de error P (U0) a 0,1.
La contratacin de un contratista para verificar y validar de forma
independiente (IV y V) el software. Esto cuesta un adicional de $
500.000; basado en los resultados de los esfuerzos similares IV y V, el
gerente estima que esto reducir la probabilidad de error P (U0) de 0,04.
El rbol de decisiones de la Figura 2 a continuacin muestra, para cada
una de las dos opciones de decisin importantes, los resultados posibles;
sus probabilidades; las prdidas asociadas con cada resultado, la
exposicin al riesgo asociado a cada resultado, y la exposicin total al
riesgo (o prdida esperada) asociados con cada opcin decisin. En este
caso, la exposicin total al riesgo asociado a la opcin experimento de
equipo es de $ 2M. Para la opcin de IV y V, la exposicin total al riesgo
es de slo $ 1,3 millones; por lo tanto, representa la opcin ms
atractiva.

Adems de proporcionar soluciones individuales para situaciones de

gestin de riesgos, el rbol de decisin tambin proporciona un marco
para analizar la sensibilidad de las soluciones preferidas para los
parmetros de exposicin al riesgo. As, por ejemplo, se prefiere la
opcin experimentteam si la prdida debido a un error de software
crtico eran menos de $ 13 millones, si el equipo experimento podra
reducir su probabilidad de-software-error crtico a menos de 0.065, si el
costo de equipo de IV y V ms de $ 1,2 M, si el equipo IV y V fueron
incapaces de reducir la probabilidad de error crtico a menos de 0.075, o
si haba varias combinaciones parciales de estas posibilidades.
Incluso con este tipo de anlisis de sensibilidad, puede que no haya
suficiente informacin disponible para cuantificar los parmetros de
exposicin al riesgo lo suficientemente bien como para realizar un
anlisis preciso. Sin embargo, el marco de la exposicin al riesgo es
compatible con algunos enfoques ms aproximados pero sigue siendo
muy tiles, como estimacin de la distancia y la estimacin de escala-
de-10, que ser discutido en la prxima seccin.
3. Los seis pasos en la gestin de riesgos Software
La figura 1 resume los principales pasos y tcnicas que intervienen en la
gestin del riesgo de software. Dentro de los lmites de este artculo de
revisin, no tenemos espacio para cubrir la totalidad de las tcnicas de
gestin de riesgos que se indican en la Figura 1. Por lo tanto, vamos a
discutir cuatro de los subgrupos ms significativos de las tcnicas de
gestin de riesgos: listas de control de identificacin de riesgos,
priorizacin del riesgo, de riesgo planificacin de la gestin y
seguimiento del riesgo. Tratamiento ms detallado de las otras tcnicas
se proporciona en la Referencia 4.
La identificacin de riesgos listas de verificacin
Una lista de verificacin de la identificacin de riesgos de nivel superior
es la lista que se muestra en la Figura 3, que muestra los 10 principales
fuentes de riesgo en proyectos de software, basado en una encuesta a
un nmero de gestores de proyectos con experiencia. La lista puede ser
utilizada por los administradores e ingenieros de sistemas en un
proyecto de software de prxima para ayudar a identificar y resolver los
elementos de riesgo ms graves en el proyecto. Tambin proporciona un
conjunto correspondiente de las tcnicas de gestin de riesgos que han
tenido ms xito hasta la fecha en evitar o resolver la fuente de riesgo.
Un ejemplo de la aplicacin de esta lista para un proyecto de software a
gran escala se proporciona en el artculo de esta edicin [3].
Si nos centramos en el punto 2 del top 10 lista en la figura 3, "Horarios
poco realistas y Presupuestos", entonces podemos pasar a un ejemplo
de una lista de comprobacin siguiente nivel: la tabla de probabilidad de
riesgo en la Figura 4 para evaluar la probabilidad de que un proyecto de
software ser invadido su presupuesto. La figura 4 es una de varias de
esas listas de control en un excelente manual de la Fuerza Area de
Estados Unidos (Referencia 5) sobre la reduccin del riesgo de software.
Uso de la lista de verificacin, se puede evaluar el estado de un proyecto
de software con respecto a los atributos individuales asociados con los
requisitos del proyecto, personal, software reutilizables, herramientas y
entorno de apoyo (por ejemplo, en la figura 4, la disponibilidad del
medio ambiente, o el riesgo de que el medio ambiente no estarn
disponibles
cuando sea necesario). Estas calificaciones apoyarn una estimacin
rango de probabilidad de que el proyecto tiene un relativamente bajo
(0,0-0,3), medio (0,4-0,6) o alto (0.71.0) probabilidad de rebasamiento
su presupuesto. (El acrnimo PDSS en la figura 4 representa Publicar
Desarrollo de soporte de software, a menudo llamado el mantenimiento
del software.) Referencias 4 y 5 contienen una serie de listas de control
de identificacin de riesgos adicionales tiles.
Otro punto significativo con respecto a la parte superior-1 0 lista es que
la mayora de los elementos crticos de riesgo tienen que ver con el
dficit en la comprensin de dominio y en la determinacin del alcance
adecuadamente el trabajo de software que hacer - las reas que son
generalmente poco nfasis en la literatura informtica y educacin.
Riesgo Analvsis y Priorizacin
Despus de usar todas las diversas listas de control de identificacin de
riesgos, adems de las otras tcnicas de identificacin de riesgos
involucrados en el anlisis de conductor de decisiones, anlisis
supuesto, y la descomposicin, un riesgo muy real es que el proyecto
identificar tantos elementos de riesgo del proyecto que el proyecto
podra pasar aos slo investigarlos. Aqu es donde la priorizacin de
riesgos y sus actividades de anlisis de riesgo asociado se vuelven
esenciales.
La tcnica ms eficaz para la priorizacin del riesgo consiste en la
cantidad de exposicin al riesgo que hemos comentado anteriormente.
Nos permite pedir los artculos de riesgo candidato identificados y
determinar cules son los ms importantes para abordar.
Una dificultad con la cantidad RE es el problema de hacer estimaciones
precisas de la probabilidad y la prdida asociada a un resultado
insatisfactorio. Las listas de verificacin como la figura 4 proporcionan
un poco de ayuda en la evaluacin de la probabilidad de ocurrencia de
un elemento de riesgo dado, pero es claro en la Figura 4 que los rangos
de probabilidad en las tres columnas no son compatibles con la
estimacin de la probabilidad exacta. Esfuerzos anlisis de riesgo
completo que implican la creacin de prototipos, el benchmarking,
simulacin, etc., suelen proporcionar una mejor estimacin de la
probabilidad y de prdida, pero que pueden ser ms caro y lento que la
situacin lo amerita. Otras tcnicas, como analogas de apuestas y
tcnicas de consenso del grupo, se han utilizado para mejorar la
probabilidad de estimacin del riesgo, pero por el bien de priorizacin
del riesgo a menudo se pueden tomar un curso ms simple: la
evaluacin de las probabilidades y las prdidas por riesgo en una escala
relativa de 0 a 10 .
Las figuras 5 y 6 ilustran este proceso de priorizacin de riesgos,
mediante el uso de algn experimento satlite artculos de riesgo
proyecto de software potenciales como ejemplos. La Figura 5 muestra un
resumen tabular de una serie de resultados insatisfactorios (UO) con sus
calificaciones correspondientes para Prob (UO), Prdida (UO), y sus
resultantes estimaciones de exposicin al riesgo. Figura 6 parcelas cada
UO con respecto a un conjunto de contornos constante exposicin al
riesgo.
Tres puntos clave emergen de las figuras 5 y 6. En primer lugar, los
proyectos a menudo se centran en factores que tengan una alta Prob
(U0) o una alta prdida (UO), pero stas pueden no ser los factores clave
con una combinacin de alta RE. Una de la ms alta Prob (U0) 's
procede de (errores de software de reduccin de datos) del punto G,
pero el hecho de que estos errores son clientes potenciales recuperables
y no de misin crtica a un bajo factor de prdida y un bajo RE resultante
de 8. Del mismo modo, el punto I (memoria insuficiente) tiene un alto
potencial prdida, pero su baja probabilidad conduce a una baja de RE 7.
Por otro lado, un elemento relativamente lowprofile como material
(dficit de interfaz de usuario) H se convierte en un elemento de riesgo
relativamente alta prioridad debido a su combinacin de factores
moderadamente alta probabilidad y la prdida de rendimiento de una RE
de 30.
Un segundo punto relacionado es que las cantidades de ER proporcionan
una base para la priorizacin de V & V y las actividades de ensayo
relacionados dando a cada clase de error un peso significativo. Con
frecuencia, todos los errores son tratados con el mismo peso, poniendo
mucho esfuerzo en los errores relativamente triviales.
El tercer punto clave que emerge de las figuras 5 y 6 se refiere a los
rangos de calificacin de probabilidad dada por los puntos A, B y C. A
menudo ocurre que hay una buena dosis de incertidumbre en la
estimacin de la probabilidad o la prdida asociada a un resultado
insatisfactorio. (Las evaluaciones son a menudo subjetiva, y son a
menudo el producto de la agrimensura varios expertos en dominios
diferentes.) La cantidad de incertidumbre es en s misma una fuente
importante de riesgo, que debe reducirse lo ms pronto posible. El
ejemplo principal en las figuras 5 y 6 es la incertidumbre en el punto C
sobre si las caractersticas de tolerancia a fallos de software se va a
causar una degradacin inaceptable en el rendimiento en tiempo real. Si
Prob (UO) tiene una potencia de 4, este artculo tiene solamente una
exposicin al riesgo moderado de 28; pero si Prob (UO) es 8, el RE tiene
una calificacin mxima prioridad de 56.
Una de las mejores formas de reducir esta fuente de riesgo debido a la
incertidumbre es comprar informacin sobre la situacin real. Para el
tema de la tolerancia a fallos dispone vs. rendimiento, una buena
manera de comprar informacin sera invertir en un prototipo, para
entender mejor el impacto en el rendimiento de las diversas
caractersticas de tolerancia a fallos. Vamos a profundizar en esta Ley de
Planificacin de la Gestin de Riesgos siguiente.
Planificacin de la Gestin de Riesgos
Una vez que el Riesgo de las actividades de evaluacin determinan los
principales elementos de riesgo de un proyecto y sus prioridades
relativas, tenemos que establecer una serie de funciones de Control de
Riesgos para que los elementos de riesgo bajo control. El primer paso en
este proceso es el desarrollo de un conjunto de planes de gestin de
riesgo que se extenda a cabo las actividades necesarias para llevar a
los elementos de riesgo bajo control.
Una ayuda en hacer esto es el Top-10 lista de verificacin en la figura 3,
que identifica las tcnicas de gestin de riesgo de mayor xito para los
elementos de riesgo ms comunes en un proyecto de software. A modo
de ejemplo, la incertidumbre en impacto en el rendimiento de la
tolerancia de software caractersticas est cubierta en el punto 9 de la
figura 3, del escaso rendimiento en tiempo real. Las tcnicas de gestin
de riesgos correspondientes incluyen la simulacin, la evaluacin
comparativa, el modelado, prototipado, instrumentacin y puesta a
punto. Supongamos, por ejemplo, que un prototipo de caractersticas de
seguridad de representacin es la manera ms rentable para determinar
y reducir su impacto en el rendimiento del sistema.
El siguiente paso en la planificacin de la gestin del riesgo es el
desarrollo de planes de gestin de riesgos individuales para cada
elemento de riesgo. Figura 7 muestra el plan individual para el prototipo
de las caractersticas de tolerancia a fallas y determinar su impacto en el
rendimiento. El plan est organizado en torno a un formato estndar
para los planes de software, orientado alrededor de las respuestas a las
preguntas estndar de "por qu, qu, cundo, quin, dnde, cmo y
cunto." Esta organizacin plan permite que los planes para ser conciso
(por ejemplo, encajando en una sola pgina), orientado a la accin, fcil
de entender y fcil de controlar.
El ltimo paso en la planificacin de la gestin de riesgos es integrar los
planes de gestin de riesgos individuales para cada elemento de riesgo
entre s y con el plan general del proyecto. Cada uno de los otros
elementos de riesgo de alta prioridad o inciertos tendr un Plan de
Gestin de Riesgos; puede resultar, por ejemplo, que la tolerancia a
fallos caractersticas prototipo por este concepto de riesgo tambin
podra ser til como parte de la estrategia para reducir la incertidumbre
en los puntos A y B (errores de software matar el experimento o la
prdida de datos de experimento crtico). Adems, con respecto al plan
general del proyecto, la necesidad de un desarrollo de prototipos de 10
semanas y el perodo de ejercicio debe tenerse en cuenta en el
calendario general para el proyecto con el fin de mantenerlo realista.
Resolucin de Riesgo y Vigilancia
Una vez que se han establecido un buen conjunto de planes de gestin
de riesgos, el proceso de resolucin de riesgos consiste en la aplicacin
de lo prototipos, simulaciones, puntos de referencia, encuestas u otras
tcnicas de reduccin de riesgos se pide en los planes. Seguimiento del
riesgo asegura que este es un proceso de circuito cerrado mediante el
seguimiento de progreso en la reduccin de riesgos y la aplicacin de
cualquier accin correctiva es necesaria para mantener el proceso de
resolucin de riesgo en la pista.
La gestin del riesgo proporciona a los administradores con una nueva
tcnica de mantenimiento muy eficaz para en la parte superior de los
proyectos bajo su control: Proyecto Top-10 Riesgo de artculos de
seguimiento. Esta tcnica se centra la atencin en la gestin de los de
alto riesgo, de gran influencia factores crticos de xito en lugar de
inundar revisiones por la direccin con grandes cantidades de detalles
de baja prioridad. Como gerente, he encontrado que este tipo de
revisin de riesgos tems orientados ahorra mucho tiempo, reduce las
sorpresas de gestin, y se pone usted se centr en las cuestiones de
gran influencia donde se puede hacer una diferencia como gerente.
Seguimiento de elementos entre los 10 riesgos del proyecto incluye los
siguientes pasos:
Clasificacin elementos de riesgo ms significativos del proyecto.
Establecer un horario regular para mayores revisiones por la direccin
de la marcha del proyecto. La revisin debe estar presidido por el
equivalente a jefe del jefe de proyecto. Para los proyectos grandes (ms
de 20 personas), las revisiones deberan celebrarse mensual.
A partir de cada reunin de revisin del proyecto con un resumen de
los progresos realizados en los 10 primeros elementos de riesgo. (El
nmero podra ser 7 o 12 sin prdida de
El resumen intencin.) debe incluir actual ranking de cada elemento de
riesgo entre los 10, su rango en el comentario anterior, el nmero de
veces que ha estado en la lista de 10, y un resumen de los avances en la
resolucin del tema de riesgos desde la anterior opinin.
Enfoque de la reunin de revisin del proyecto sobre el tratamiento de
cualquier problema en la resolucin de los elementos de riesgo.
Figura 8 muestra como un top-1 0 Lista proyecto podra haber estado
trabajando para el proyecto experimento vehculos espaciales, a partir
del mes 3 del proyecto. Superior elemento de riesgo del proyecto en
meses 3 es un problema crtico de personal. Destacando que en la
reunin de revisin mensual estimular la discusin de las opciones de
dotacin de personal por el equipo del proyecto y el jefe (hacer que la
persona clave "disponible" disponible, el personal del proyecto
Remodelacin, buscar nuevas personas dentro o fuera de la
organizacin). Esto debera dar lugar a una asignacin de puntos de
accin a seguir a travs de las opciones preferidas elegidos, incluidos
posibles acciones por el jefe del jefe de proyecto.
El elemento de riesgo # 2 en la Figura 8, retrasos en la entrega de
hardware de destino, es tambin aquella en la que el jefe del jefe de
proyecto puede ser capaz de ayudar a acelerar una solucin - cortando a
travs de la burocracia corporativa-procurement, por ejemplo, o por la
escalada VENDEDOR retrasar problemas con la alta direccin del
vendedor.
Como se ve en la figura 8, algunos elementos de riesgo estn bajando
prioridad o salirse de la lista, mientras que otros estn escalando hacia
arriba o viene en la lista. Los que van abajo en la lista, como el diseo de
V & V de personal, creacin de prototipos tolerancia a fallos, y la interfaz
de usuario de prototipos, an necesitan ser monitoreados, pero con
frecuencia no necesitan medidas de manejo especial. Los van hacia
arriba o en la lista, como los buses de datos cambios de diseo y las
definiciones de interfaz banco de pruebas, son generalmente los que
necesitan mayor atencin de la administracin para ayudar en lo que les
resuelven rpidamente.
Como se puede ver en este ejemplo, la lista de elementos de riesgo
entre los 10 es una forma muy efectiva para enfocar mayor atencin a la
gestin de los factores crticos de xito del proyecto. Tambin es muy
eficiente con respecto al tiempo de gestin; la revisin mensual normal
pasa la mayor parte de su tiempo en cosas el gerente superior no puede
hacer nada al respecto. Adems, si el administrador superior superficies
una preocupacin adicional, es fcil para aadirlo a la lista de elementos
de riesgo entre los 10 a ser destacado en futuras revisiones.
Gestin de Riesgos 4. Implementacin de Software
La implementacin de la gestin del riesgo de software consiste en la
insercin de los principios y prcticas de gestin de riesgos en las
prcticas de gestin del ciclo de vida de software existentes de uno. La
plena aplicacin de la gestin de riesgos implica el uso de modelos de
procesos de software impulsado por riesgo tales como el modelo espiral
[2], en el que las consideraciones de riesgo determinan la secuencia
general de las actividades del ciclo de vida, el uso de prototipos y otras
tcnicas de resolucin de riesgo, y el grado de detalle de los planos y
especificaciones. Sin embargo, la mejor estrategia de implementacin es
un incremento
uno, lo que permite que la cultura de una organizacin se adapte
gradualmente a las prcticas de gestin orientadas al riesgo y modelos
de procesos impulsados por riesgo.
Una buena manera de empezar es establecer un proceso de seguimiento
de elementos de riesgo 0 top-1. Es fcil y barato de implementar,
proporciona mejoras tempranas, y comienza estableciendo una
familiaridad con los dems principios y prcticas de gestin de riesgos.
Otra buena manera de ganar familiaridad es a travs de la reciente
volumen tutorial IEEE-CS sobre Gestin de Riesgos Software [4], que
contiene la Reduccin de Riesgos folleto Fuerza Area [5] y otros buenos
artculos sobre los diversos aspectos de la implementacin de la gestin
del riesgo de software.
Un siguiente paso eficaz es identificar un proyecto inicial apropiada para
la implementacin de un plan de gestin de riesgos del ciclo de vida de
nivel superior. Una vez que la organizacin ha acumulado cierta
experiencia en la gestin de riesgos en este proyecto inicial, los pasos
siguientes pueden profundizar la sofisticacin de las tcnicas de gestin
de riesgos y ampliar su aplicacin a las clases ms amplias de
proyectos.
Figura 9 proporciona un esquema para la implementacin de un plan de
gestin de riesgos del ciclo de vida de software de nivel superior. Se
presenta en el contexto de un software de adquisicin contractual, pero
se puede adaptar a una organizacin interna de desarrollo de software
tambin.
El Plan de Gestin del Ciclo de Vida Riesgo software puede ser
organizado como una elaboracin del "por qu, qu, cundo, quin,
dnde, cmo, cunto" marco dado en la Figura 7. Se trata
principalmente de la responsabilidad del cliente, pero es muy til
involucrar a la comunidad de desarrolladores en su preparacin tambin.
Se dirige no slo a los riesgos de desarrollo que han sido el tema
principal de este artculo, sino tambin las operaciones y los riesgos de
mantenimiento. Estos incluyen elementos tales como la dotacin de
personal y la capacitacin del personal de mantenimiento;
discontinuidades en el corte y cambio del viejo al nuevo sistema;
responsabilidades no definidas para las operaciones e instalaciones de
mantenimiento y funciones; y el presupuesto insuficiente para la mejora
del ciclo de vida previstos o para correctivo, adaptativo y perfectivo de
mantenimiento de software.
El otro punto destacado en la Figura 9 es la importancia de los planes de
gestin de riesgo desarrollador propuestas en la evaluacin y seleccin
de fuente competitiva. Haciendo hincapi en el realismo y la eficacia del
plan de gestin de riesgos de un postor aumenta la probabilidad de que
el cliente seleccione un postor que entiende claramente los factores
crticos de xito del proyecto, y que ha establecido un enfoque de
desarrollo que satisfactoriamente se dirige a ellos. (Si el desarrollador es
una organizacin interna no competitivo, es igualmente importante para
el cliente interno para requerir y revisar un plan de gestin de riesgo
promotor.)
Un ejemplo de la utilizacin de este marco plan de aplicacin de gestin
de riesgos de nivel superior se proporciona en el siguiente artculo de
esta cuestin [3].
5. Resumen
Lo ms importante para un proyecto de software a hacer es conseguir
centrado en los factores crticos de xito.
Por varias razones, incluyendo la influencia de las directrices de gestin
de software basados en documentos anteriores, los proyectos reciben
centrado en actividades que no son crticas para su xito. Estos incluyen
con frecuencia escribir documentos repetitivo, explorando cuestiones
tcnicas intrigantes pero perifricos, jugar a la poltica, y tratando de
vender "el sistema final."
En el proceso, los factores crticos de xito se descuidan, el proyecto
fracasa, y nadie gana.
La contribucin clave de la gestin de riesgos del software es crear este
enfoque en los factores crticos de xito - y proporcionar las tcnicas que
permiten el proyecto para tratar con ellos. Las tcnicas de evaluacin y
control de riesgos presentados en este artculo, y con ms detalle en
referencia 4, proporcionan la capa base de las capacidades necesarias
para aplicar el enfoque orientado al riesgo.
Sin embargo, la gestin de riesgos no es un libro de cocina. Para hacer
frente a todas las personas, orientada hacia complejas y factores de
xito basadas en la tecnologa involucrados en proyectos de software, se
requiere una gran medida del juicio humano.
La gente buena, con buenas habilidades y buen juicio, son los que hacen
los proyectos de software de trabajo. La gestin de riesgos puede
proporcionarle algunas de las habilidades, el nfasis en conseguir
buenas personas, y un buen marco conceptual para el afilado de su
juicio. Espero que encuentre estos tiles en su prximo proyecto de
software.
Referencias
1. J. Rothfeder, "Es tarde, costoso, y Incompetente - pero trate de
disparo de un sistema informtico," Business Week, 7 de noviembre de
1988, pp 164-1 65..
2. BW Boehm, "Un modelo espiral de Desarrollo de Software y Mejora,"
Computer, mayo de 1988, pp. 61 -72.
3. V.R. Basili, B. W. Boehm, y AE Salwin, "Ada Gestin de Riesgos: Un
Ejemplo LargeProject," Software, (TBD).
4. B. W. Boehm, Tutorial: Software de Gestin de Riesgos, IEEE Computer
Society, nmero de catlogo ISBN-86-8906-4 0-81, 1989.
5. Estados Unidos de la Fuerza Area Sistemas de Mando, "Reduccin del
Riesgo de software", AFSCIAFLC folleto 800-45, 1988.