INTRODUCCIN

Los proyectos de software incluyen un conjunto amplio de riesgos que pueden causar
serios problemas durante su desarrollo (cambios en los requerimientos de usuario,
planificaciones demasiado optimistas, diseo inadecuado, error en la contratacin, problemas
de personal, problemas con la tecnologa, cambio en las leyes del gobierno y problemas con el
desarrollo, por nombrar slo algunos de ellos). Segn Caper Jones Las probabilidades de que
un proyecto complejo se cancele se aproxima a la de acertar al lanzar una moneda al aire
[JON1991].

El desarrollo de Microsoft Word para Windows 1.0 nos da una leccin clara sobre los
efectos de los riesgos cuando stos nos son considerados como relevantes. Word para
Windows, necesit 5 aos para su desarrollo, consumi 660 personas-mes de esfuerzo de
desarrollo, y gener un sistema de 249.000 lneas de cdigo [IAN1994]. La planificacin
final de 5 aos fue aproximadamente cinco veces mayor de la diseada en un principio y el
proyecto experiment un cambio de personal extremadamente alto, adems de una baja
calidad en las prestaciones.

Existe una serie de mtodos y modelos para administrar riesgos que pueden prevenir los
inconvenientes mencionados anteriormente; la administracin de riesgos es un tema
relativamente nuevo, pero ya existe informacin suficiente como para tratarlo con profundidad
en este documento.

El objetivo de este trabajo se centra en la comparacin de modelos de administracin
de riesgos cuya funcin principal es la de identificar, estudiar y eliminar las fuentes de riesgos
antes de que empiecen a amenazar la finalizacin satisfactoria de un proyecto de software.





id22809968 pdfMachine by Broadgun Software - a great PDF writer! - a great PDF creator! - http://www.pdfmachine.com http://www.broadgun.com

Para establecer una base terica que permita definir un conjunto de criterios
comparativos se hace necesario abordar en las siguientes secciones el concepto riesgo dentro
del contexto del desarrollo de software desde su gnesis, es decir, establecer una definicin,
identificar las fuentes de riesgos, clasificar los riesgos, reconocer el problema, recopilar
antecedentes nacionales e internacionales sobre el tema, identificar los riesgos que afectan al
desarrollo de software y describir los modelos de administracin de riesgos.

Qu se espera de este trabajo? Un pequeo aporte que permita difundir y reconocer a
los modelos de administracin riesgos como buenos mtodos para el desarrollo de software, y
del mismo modo infundir su utilizacin cuyos beneficios generarn profundas implicaciones
en el logro final de un desarrollo, referidos a una menor tasa de errores, mayor aceptacin por
parte del usuario, mejor facilidad de mantenimiento y un menor costo y tiempo de desarrollo.





















SECCIN 1: EL CONCEPTO RIESGO

1.1) Percepcin del Riesgo

La forma en que la gente percibe el riesgo en su vida diaria, es mas bien, una nocin de
sentido comn, la cual se asocia a un sin nmero de factores sociales y psicolgicos. Ciertas
personas perciben el riesgo en base a la posibilidad de que ocurra un evento determinado,
mientras que otras lo hacen considerando los efectos y consecuencias de ese evento.

Algunos de los factores que influyen en la percepcin del riesgo en la gente son: El potencial
catastrfico de la fuente, el conocimiento o no de los mecanismos de ocurrencia, la
incertidumbre, la posibilidad de que sea controlable y orgenes entre otros.

Por otro lado, las decisiones acerca de los riesgos pueden ser realizadas a nivel individual y/o
colectivo. A nivel individual, la opcin de tomar un riesgo - como conducir bajo la influencia
del alcohol - es personal. A nivel colectivo o social, donde el conflicto de valores y decisiones
a menudo resulta en beneficiados y perjudicados, la toma de decisin es ms difcil y
controversial - como la instalacin de un vertedero en una ciudad -.

En resumen, la percepcin de los riesgos es un concepto con varias aristas y su apreciacin
depender de cada individuo y situacin particular. De acuerdo a esto podemos establecer a
priori que los riesgos son intrnsicos a cualquier actividad humana, y como tal, imposibles de
no considerar al momento de tomar una decisin. Conforme a esta realidad slo nos queda
reconocer la existencia de ellos y buscar los mtodos y mecanismos necesarios que minimicen
las consecuencias negativas de estos sobre nuestro diario vivir.

Si bien en los prrafos anteriores se han esbozados algunas ideas sobre el concepto riesgo, an
no disponemos de un conocimiento apropiado sobre el tema. Para subsanar tal carencia es que
consideramos necesario abordar en este trabajo las siguientes inquietudes: qu definicin de
riesgo debemos utilizar?, cul es la naturaleza del riesgo?, qu fuentes de riesgo existen?,
cmo podemos clasificarlos?, cules son las implicancias de los riesgos?.


1.2) Definicin de Riesgo

Una nocin intuitiva del riesgo es la siguiente: Eventualidad de que ocurra un hecho
capaz de producir algn dao. Sin embargo; para establecer un fundamento ms amplio del
concepto riesgo citaremos las siguientes definiciones proporcionadas por la literatura:

Probabilidad de un evento adverso multiplicada por la magnitud del dao que causa
[JON1998]

Implicancia de incertidumbre y prdida [HIG1995]

Posibilidad de prdida o cualquier caracterstica, objeto o accin que esta asociado con esa
posibilidad [KON1995]

Peligro, contingencia de un dao [LAR1981]

Evento no deseado que tiene consecuencias negativas [LAW1995]

Suceso que puede ocurrir en el futuro; una posibilidad, no una certeza [VAN1992]

Posibilidad de prdida o lesin; grado de probabilidad de tal prdida [WEB1989]

A pesar de las definiciones anteriores es necesario explicar algunos conceptos implcitos
utilizados en las definiciones, en particular nos referimos a la probabilidad, incertidumbre y
prdida.

Probabilidad: Caracterstica de un suceso del que existen razones para creer que se realizar
[LAR1981]

Incertidumbre: Falta de seguridad, certeza y conviccin [LAR1981]

Prdida: Desgaste, mengua, perjuicio o privacin de una cosa [LAR1981]

Las definiciones para el trmino riesgo son abundantes y amplias. Sin embargo; en la mayora
de estas se puede desprender que la esencia del riesgo consiste en una combinacin de la
nocin de prdida con la de azar o probabilidad, es por esto que nuestra definicin considerar
a estos dos elementos como fundamentales, en donde la prdida depender de las expectativas,
las que a su vez dependern de las personas que las evalan.

La idea de azar es crucial: lo inevitable puede ser ciertamente desagradable pero al no tener
carcter probabilstico no constituye un riesgo.

De este modo el concepto riesgo para este trabajo considerar la siguiente definicin: evento
que se caracteriza por su probabilidad de ocurrencia y prdida asociada, la cual estar
definida por expectativas evaluadas por personas.















Figura 1.1: Concepto riesgo.




Probabilidad Probabilidad Prdidad Prdidad Evento no Deseado Evento no Deseado Incertidumbre Incertidumbre
Atributos del Riesgo
Riesgo Riesgo
Prdida Prdida
Materializacin del riesgo

1.3) Naturaleza del Riesgo

La revista Information & Management [INF1994] establece que la esencia o ndole del riesgo
est conformado por los siguientes cuatro elementos: Amenazas, Recursos, Factores
Modificantes y Consecuencias.

Las amenazas consideran a todas aquellas fuerzas capaces de generar consecuencias adversas.

Los recursos consisten en las personas, activos y ganancias que pueden verse afectados
por las amenazas.

Los factores modificantes como la reduccin, proteccin, transferencia y
financiamiento son aquellos que influyen en la probabilidad de que una amenaza se concrete.

Reduccin: Se refiere a las acciones que pueden tomarse para eliminar el riesgo o reducir su
gravedad.

Proteccin: Se refiere a la utilizacin de medios fsicos, para alcanzar los mismos objetivos
que la reduccin.

Transferencia: Se refiere a la decisin de trasladar parte o la totalidad del riesgo.

Financiamiento: Se refiere a la entrega de un presupuesto para el control de los riesgos.

Las consecuencias son el resultado de las amenazas materializadas, considerando el
efecto sobre los recursos y la magnitud de tales efectos.






Basndonos en la informacin proporcionada por Information & Management [INF1994] los
componentes del riesgo pueden ser esquematizados de la siguiente manera:














Figura 1.2: Componentes del riesgo.















Amenazas Amenazas
Probabilidad de
Ocurrencia
Consecuencias Consecuencias
- Magnitud
- Severidad
Recursos Recursos
- Peronas
- Activos
- Ganacias
Factores Modificantes Factores Modificantes
- Proteccin
- Reduccin
- Transferencia
- Financiamiento

1.4) Fuentes de Riesgo

An sin analizar los diferentes componentes del concepto prdida, debera
reconocerse que el estar expuesto a fuentes de riesgos no es algo necesariamente malo. Los
logros de la vida moderna implican la exposicin a varias fuentes de riesgos, y el desarrollo
alcanzado a travs de la historia no sera posible sin los riesgos incurridos por nuestros
antepasados.

Los riesgos tienen distintos orgenes, Vaughan [VAU1982] establece como fuentes de origen
las siguientes:

Riesgos naturales: Aquellos originados por fenmenos de la naturaleza como las inundaciones,
terremotos, erupciones volcnicas, etc.

Riesgos tecnolgicos: Aquellos asociados a accidentes de origen tecnolgico, como el riesgo
qumico, el nuclear o el transporte de mercancas peligrosas.

Riesgos antrpicos: Aquellos generados por la actividad del hombre, como el transporte
pblico, grandes concentraciones de personas, colapso de un edificio, etc.

Riesgos particulares: Estn relacionados con prdidas que afectan a individuos ms que a un
grupo entero. Los riesgos particulares son considerados responsabilidad de los propios
individuos. Estos riesgos pueden ser objeto de asegurabilidad, prevencin o alguna otra
tcnica.

Riesgos especulativos: Describen situaciones en donde existe posibilidad de prdida, pero
tambin de ganancia, en este contexto el riesgo es deliberadamente creado con la esperanza de
ganar (inversiones y juegos de azar).




Riegos dinmicos: Son aquellos que resultan de cambios en la economa, cambios en el nivel
de precios, en la demanda de consumidores, en la tecnologa, etc. , y que pueden causar
prdida financiera a los miembros de la sociedad. Estos riesgos dinmicos normalmente tienen
impacto en la sociedad a largo plazo. Los riesgos dinmicos pueden afectar a un gran nmero
de individuos, pero son menos predecibles que los riesgos estticos ya que ocurren sin ninguna
regularidad.

Riesgos estticos: Estos involucran aquellas prdidas que ocurriran an si no hubiera cambios
en la economa, se relacionan con la deshonestidad de los individuos y con su pericia. La
prdida esttica esta relacionada con la destruccin de algn bien o el cambio de su posesin
como resultado del error humano. Los riesgos estticos tienden a ocurrir con algn grado de
regularidad y por lo tanto predecibles y perceptibles de aseguramiento.

Riesgos fundamentales: Estn relacionados con prdidas que son impersonales en prdida y en
origen, son grupo de riesgos que son causados fundamentalmente por la economa, la sociedad
y los fenmenos polticos, as como tambin de los fenmenos fsicos, afectan a largos
segmentos de la poblacin o inclusive a toda ella, por ejemplo: desempleo, guerra, inflacin y
terremotos.

Despus de obtener una comprensin de la naturaleza del riesgo, el prximo paso es situar un
fundamento para manejarlo. El riesgo debe segmentarse en pedazos manejables. El primer
segmento es una clasificacin o descomposicin de riesgos en un conjunto amplio,
relacionndolo con su fuente.










1.5) Clasificaciones de Riesgos

Entender y clasificar riesgos requiere de un examen minucioso de la fuente del riesgo.
No siempre es fcil determinar en que categora pertenece un riesgo en particular. Sin
embargo, entendiendo la fuente del riesgo y las reas de impacto, as como la estructura que se
proporcion para examinar el riesgo permitir un manejo eficaz del riesgo.

Una clasificacin para el concepto riesgo no existe, slo se puede contar con clasificaciones
que responden a determinados autores y criterios:

Segn R. Dorfman [DOR1980], los riesgos en base a su impacto pueden clasificarse en:
Riesgos Descripcin
Catastrficos o fatales para la
empresa
Aquellos que de producirse resultaran en una
descapitalizacin, abandono o discontinuidad a
corto plazo del negocio.
Importante o muy serio
Aquellos que ocasionaran una prdida
considerable que se reflejara en los activos
patrimoniales y obligara a un cambio en su
poltica de inversin.
Mediano o moderadamente serio
Aquellos con impacto significativo sobre el
balance de ganancias y prdidas, que requerira la
atencin de la alta gerencia.
Mnimo y sin importancia relativa
Cualquier riesgo cuya prdida puede ser cubierta
con las reservas normales de contingencia.
Seriedad desconocida
Cuando no se puede determinar la prdida que
ocasiona el riesgo. Una vez determinada la
prdida, se debe clasificar en una de las anteriores
categoras.

Tabla 1.1: Clasificacin de riesgos segn su impacto [DOR1980].


Bob Hedges [HED1961] clasifica los riesgos de acuerdo a su gravedad en:

Riesgos Descripcin
Clase I
Aquellos que de suceder generan prdidas que no alteran
las finanzas bsicas con endeudamiento.
Clase II
Aquellos que generan prdidas y que llevarn a la empresa
a incurrir en endeudamiento.
Clase III
Aquellos que generan prdidas mayores que la Clase I,
Clase II, y que podran llevar la empresa a la quiebra.

Tabla 1.2: Clasificacin de riesgos segn su gravedad [HED1961].

Robert Charette [CHA1989] propone la siguiente clasificacin:

Riesgos Descripcin
Conocidos
Son aquellos que pueden descubrirse luego de una
minuciosa evaluacin del plan del proyecto, el negocio y
el ambiente tcnico en el cul el proyecto ser
desarrollado.
Predecibles
Son aquellos que pueden ser extrapolados desde
experiencias de proyectos anteriores.
Impredecibles
Son aquellos extremadamente difciles de identificar con
anticipacin.

Tabla 1.3: Clasificacin de riesgos segn R. Charette [CHA1989].







Roger Pressman [PRE1998] organiza los riesgos en:

Riesgos Descripcin
Proyectos
Aquellos riesgos que afectan al presupuesto, recursos,
planificacin, personal y clientes.
Tcnicos
Se refieren a los riesgos en el diseo, implementacin de
interfaces, verificacin y mantencin de problemas.
Negocio
Son los que amenazan la viabilidad del producto a
construir, y afectan a la estrategia comercial, presupuestos,
mercadeo y direccin.
Genricos
Son amenazas potenciales para todos los proyectos de
software.
Especficos
Son aquellos que pueden ser identificados con un claro
entendimiento de la tecnologa, personal y medio ambiente
especfico para cada proyecto.

Tabla 1.4: Clasificacin de riesgos segn R. Pressman [PRE98].















1.6) Implicancias del Riesgo

El riesgo es inherente a la vida, como los riesgos del hogar, los riesgos laborales y los
derivados de actividades recreativas, en conclusin, el riesgo implica dinamismo y multitud de
facetas que pueden involucrar reas econmicas, cientficas, sociales y polticas. De acuerdo a
lo anterior, se puede decir, que las implicancias del riesgo son fcilmente identificables; sin
embargo, las causas que propician su aparicin pueden ser mltiples y de ndole muy diversa.
Una misma causa puede generar ms de un tipo de riesgo.

El desarrollo de software como cualquier otra actividad intelectual realizada por
personas implica estar bajo la influencia de los riesgos, es mas, el desarrollo de software se
encuentra ampliamente relacionado con los riesgos, Elaine Hall [HALL1998] opina que: Es
en este tipo de servicio informtico en donde mayor nmero de inconvenientes se pueden
presentar gracias a una de sus caractersticas principales la incertidumbre.

Con el crecimiento del software y la confianza que depositan las organizaciones en l,
tambin crecen las consecuencias relacionadas con sus fallas. Todas estas fallas han sido
riesgos que se materializan durante su desarrollo y podran haberse evitado o mitigado con la
aplicacin de una correcta y formal poltica de preocupacin acerca de lo que verdaderamente
implica el riesgo en el desarrollo del software.

No es incuestionable que el desarrollo de software en estas ltimas dcadas se haya
convertido en una de las actividades econmicas ms importante en el mundo; sin embargo,
este claro xito no puede estar ajeno a experiencias en donde el desarrollo de software no
logro alcanzar sus metas y objetivos.

Es por esto que consideramos necesario preguntarnos qu antecedentes nacionales e
internacionales existen acerca de fracasos en el desarrollo de software?, qu clase de riesgos
afectan a esta actividad?, cmo pueden ser clasificados?, qu riesgos son mas relevantes?, y
cul es la opinin de especialistas acerca de este tema?.



CAPTULO 2: EL RIESGO EN EL DESARROLLO DE SOFTWARE

2.1) Reconocimiento del Problema

El desarrollo de software en ciertas ocasiones se ve afectado por problemas no previstos
que causan que los proyectos fallen en relacin a los plazos y presupuestos establecidos
originalmente. El fundamento de esta afirmacin se basa en la opinin del especialista en
ingeniera de software Roger Pressman [PRE1988] y en un estudio realizado por la empresa
norteamericana de investigacin de mercado Standish Group [STA1994].

Roger Pressman en su libro Ingeniera de Software: Un enfoque prctico reconoce la
existencia de problemas en el desarrollo de software describindolos de la siguiente
manera: Muchos particulares y muchas compaas desarrollan todava el software de
forma muy aleatoria. De igual modo muchos profesionales y estudiantes siguen sin conocer
los mtodos modernos. El estado de la ingeniera del software sigue siendo un estudio muy
diversificado. Las actitudes han cambiado y se ha progresado considerablemente, pero
todava queda mucho por hacer antes de que esta disciplina alcance su completa madurez.
[PRE1998]

Del comentario anterior proporcionado por el especialista se puede desprender que
el desconocimiento de los mtodos modernos para el desarrollo de software tendra
solucin, la ignorancia siempre es un mal curable. Pero que podemos hacer con respecto a
que la ingeniera de software es una disciplina inmadura, en realidad no mucho ya que la
madurez lamentablemente implica tiempo.








2.2) Antecedentes Sobre el Tema

La empresa Standish Group en su Reporte CHAOS [CHA1994] proporciona informacin
acerca de 8.000 proyectos de desarrollo de software de un total de 352 compaas. Los
resultados de este reporte son:

31% de los proyectos se cancelaron antes de su finalizacin.

53% de los proyectos se excedieron en un 189% sobre los costos estimados inicialmente.

9% de los proyectos se terminaron a tiempo y dentro del presupuesto, en grandes empresas.

16% de los proyectos se terminaron a tiempo y dentro del presupuesto, en pequeas
empresas.

Figura 2.1: Problemas en el desarrollo de software [CHA1994].



31%
53%
9%
16%
Proyectos cancelados
De lo proyectos excedieron sus
costos
De los proyectos
concluyeron
exitosamente, en
grandes empresas
De los proyectos
concluyeron exitosamente,
en pequeas empresas

En pequeas empresas slo 16% de los proyectos de software se completaron a tiempo y en
el presupuesto. En empresas ms grandes, las noticias son an peores: slo el 9% de sus
proyectos culminan a tiempo y en el presupuesto estimado. Sin embargo; estos proyectos
completados en empresas grandes slo registran un 42% aproximadamente de los rasgos
originalmente propuestos en los requerimientos. Las empresas de menor tamao lo hacen
mucho mejor, ya que, alcanzan un 74,2% de los rasgos originales y funciones establecidos
en los requerimientos.

Cul es nuestra realidad?, se desconoce la existencia de algn estudio similar al anterior,
a excepcin de algunos resultados preliminares del proyecto Herramientas de Mejora de la
Productiva para la Industria del Software en Chile (HMS) financiado por CORFO y
desarrollado por INTEC CHILE entre 1995 y 1998, los que permiten inferir que el caso
nacional no es muy diferente del anterior.

INTEC CHILE, en su trabajo seala la siguiente realidad al interior de empresas
nacionales que desarrollan software:

No existe medicin del proceso ni registro de datos histricos.
Mal uso de herramientas automatizadas para la planificacin y estimacin.
Excesiva e irracional presin en los calendarios.
Estimaciones imprecisas de plazos y costos.
Crecimiento excesivo en los requerimientos para un producto de software.
No se hace gestin de riesgos formalmente.
No se realiza un proceso formal de pruebas.
No se realizan revisiones tcnicas formales e inspeccin del cdigo.

Adems proporcionan una estimacin de los riesgos probables por reas de prctica que
pueden afectar el desarrollo de software y una lista de riesgos frecuentes:


Figura 2.2: Riesgos probables por rea de prctica [INT1998].















Figura 2.3: Riesgos ms frecuentes en Chile, segn INTEC [INT98].



0
10
20
30
40
50
60
70
Riesgo probable por rea de prcticas
Gestin de
requerimientos
Planificacin de
proyecto
Seguimiento y control
de proyecto
Garanta de calidad de
software
Gestin de
configuracin
Riesgos ms
Frecuentes
El proyecto depende de
algunos individuos
Los criterios de aceptacin
no son claros
Ausencia de planificacin
en el proyecto
Interferencia excesiva del
cliente
No todos los involucrados
comprenden los
requerimientos
Funcin de garanta de
calidad inadecuada

2.3) Algunas Opiniones Sobre el Riesgo en el Desarrollo del Software

Las cifras y antecedentes anteriores dejan en claro que el desarrollo de software en la
actualidad adolece de problemas como:

Retrasos considerables en la planificacin.
Excesos considerables en los presupuestos.
Poca productividad.
Baja calidad y fiabilidad del producto.

J. Kontio [KON1997] opina que estos problemas son riesgos no controlados y suceden
porque los proyectos son incapaces de enfrentar los riesgos dentro del proceso de desarrollo
de software.

Ante esta problemtica muchas organizaciones han puesto sus esperanzas en soluciones
tecnolgicas: Herramientas Case, Lenguajes de Cuarta Generacin, Sistemas Expertos y
Prototipos. Los desarrolladores actuales no carecen de opciones. Lamentablemente, tratar
de desarrollar software considerando slo las herramientas y tcnicas es como adivinar el
resultado de una mezcla de elementos.












En opinin de Howard Rubin [RUB1990], el xito en el desarrollo del software requiere de
una correcta mezcla de elementos en la cual los desarrolladores debieran preocuparse de:

Comprender el rol del proceso de la Ingeniera del software, as como los cambios en los
roles de usuario y desarrolladores derivados del cambio de paradigma en el desarrollo de
software.

Adoptar y adaptar herramientas apropiadas para las tareas concretas.

Conocer las habilidades y educacin necesaria para los cambios en procesos y tecnologas.

Distribuir eficazmente la tecnologa apropiada.

Medir y comunicar la contribucin de los desarrolladores a la empresa y manejar su
proceso interno.

A menudo las herramientas tecnolgicas son consideradas como las salvadoras de los
desarrolladores de software. Sin embargo, en la publicacin Ingeniera de Software para
Sobrevivir en los Noventas de la revista informtica (julio de 1990) se establece la
siguiente realidad:

El 70% de las herramientas y tcnicas no son utilizadas.

El 25% de las herramientas son utilizadas por un slo grupo.

El 5% de las herramientas son ampliamente utilizadas, pero no a toda su capacidad.

Michael Hammer seala que a pesar de la explosin de tcnicas, herramientas y
tecnologas los problemas en el desarrollo de software no han desaparecido. Muchas
inversiones fuertes en tecnologas de la informacin han arrojado resultados frustrantes".
[HAM1990]

El buen desarrollo de software implica una combinacin inteligente y hbil de
herramientas, conceptos y mtodos apropiados para la tarea que se enfrenta y en concreto
considerar al riesgo como un factor relevante de influencia sobre el xito; el cual
necesariamente debe ser estudiado y aceptado como parte esencial del progreso.

Luego de comprender que el desarrollo de software es una actividad inherentemente
compleja y que adems est inmersa en un ambiente dinmico en el cual fructifican los
riesgos, es que consideramos relevante el establecimiento de los tipos de riesgos que
afectan al desarrollo de software, a travs de algunas clasificaciones.























2.4) Clasificacin de Riesgos en el Desarrollo de Software

Segn D. Karolak [KAR1996], los riesgos que afectan el desarrollo de software
pueden verse a travs de dos perspectivas, la tecnolgica y la comercial.

Los riesgos de la tecnologa o tcnicos incluyen los algoritmos, disponibilidad de
tecnologa y la madurez del software.

Los riesgos comerciales incluyen la disponibilidad de los recursos (personal y equipo),
costo y problemas de presupuesto. Dentro de este mbito tecnolgico y comercial, hay tres
elementos de riesgo del software: Tcnico, Costo y Planificacin.

2.4.1) Riesgos Tcnicos

De acuerdo a Dale Karolak [KAR1996] los riesgos tcnicos son asociados con el
funcionamiento del producto de software. El funcionamiento del software involucra los
siguientes temas:

Funcionalidad: La capacidad del software para realizar sus funciones diseadas.

Calidad: El software puede satisfacer las expectativas de los clientes.

Fiabilidad: La capacidad del software para funcionar dentro de los perodos de tiempo
establecidos sin error.

Utilidad: El software y la documentacin presentan caractersticas para proporcionar una
fcil implementacin de los requisitos del usuario.

Oportunidad: El software puede realizar las funciones de una manera oportuna.


Mantencin: Caractersticas del software y la documentacin para ser mantenido
fcilmente.

Reutilizacin: Las caractersticas del software para ser utilizado de nuevo en una aplicacin
similar o diferente.

La importancia de los problemas de riesgos tcnicos es determinada por la percepcin
hecha por los clientes, gerencia y diseador del software.

2.4.2) Riesgos del Costo

Los riesgos del costo en opinin de Dale Karolak [KAR1996] estn asociados con el costo
del producto del software durante el desarrollo del proyecto. El costo del software involucra
los siguientes tpicos:

Presupuesto: La capacidad de desarrollar software, su documentacin asociada y servicios
dentro de un lmite de gastos establecidos por la administracin.

Costos No Recurrentes: Se dispone de la habilidad para identificar y manejar los costos
asociados con el desarrollo del software, como la labor de desarrollo inicial y el capital de
equipamiento.

Costos Recurrentes: Existe la capacidad para identificar y manejar los costos asociados con
el apoyo o soporte del desarrollo del software, tales como las facilidades y el
mantenimiento de costos de productos de software usados en el desarrollo.

Costos Fijos: La capacidad de identificar y manejar costos que no varan, como el costo de
reproduccin de software y documentacin.



Costos Variables: La habilidad de identificar y manejar costos que varan con la cantidad de
actividades de desarrollo del software, como el tiempo rentado de la computadora.

Ganancia / Margen de Prdida: Se puede predecir y controlar el margen de ganancia
esperado para un producto o venta.

Realismo: Se dispone de la habilidad para proyectar el costo exacto basado en conjeturas o
suposiciones dadas.

Cada uno de estos problemas de costo se asocian con riesgos de prdida de ganancia del
producto del software. La identificacin, valoracin y prediccin de riesgos del costo
influirn en el apoyo y en la inversin de la administracin dada al producto del software.
Los riesgos de costos no se definen hasta que el producto de software se entrega. Por
consiguiente, ellos existen a lo largo del ciclo de vida del desarrollo de software.

2.4.3) Riesgo de la Planificacin

El riesgo de la planificacin esta asociado con la planificacin del producto de software
durante el desarrollo. La planificacin del desarrollo de software, segn Dale Karolak
[KAR1996] involucra lo siguiente:

Flexibilidad: La planificacin realizada presenta caractersticas que permitan a esta ser
comprimida o extendida de acuerdo con las expectativas de completar las tareas.

Encontrar los Hitos Establecidos: Se dispone de la capacidad y recursos tcnicos para
encontrar los hitos establecidos en una planificacin.

Realismo: La planificacin refleja las expectativas de los clientes, administracin y
desarrolladores de software con exactitud.














Figura 2.4: Riesgos en el desarrollo de software segn D. Karolak [KAR1996].

2.5) Riesgos en las Etapas de Desarrollo de Software

La clasificacin de riesgos realizada por Karolak [KAR1996] y la identificacin de
riesgos tpicos propuestas por Jones [CAP1994] y Boehm [BOE1991], nos proporcionan un
lineamiento general de los tipos de riesgos que pueden surgir al momento de desarrollar un
programa. No obstante de lo anterior, consideramos que una descripcin de los riesgos en
cada una de las etapas del desarrollo del software nos proporcionara un enfoque ms
particular sobre el tema.

Para la determinacin de los riesgos en las etapas de desarrollo de software se ha
decidido utilizar el modelo lineal o secuencial, llamado algunas veces ciclo de vida
clsico o modelo en cascada, el modelo secuencial o lineal sugiere un enfoque
sistemtico, secuencial de desarrollo de software que contempla las siguientes etapas:
anlisis de requisitos, diseo, codificacin, integracin y mantenimiento.

El modelo lineal o secuencial es el paradigma ms antiguo y ms extensamente
utilizado en el desarrollo del software. Sin embargo; la crtica del paradigma ha puesto en
duda su eficacia [HAN1995]. Pese a las crticas el paradigma del ciclo de vida clsico tiene
Proyecto de Desarrollo
de Software
Perspectiva
Tecnolgica
Perspectiva
Comercial
! Riesgos Tcnicos
! Riesgos del Costo
! Riesgos de la Planificacin

un lugar definido e importante en el trabajo de la ingeniera de software. Proporciona una
plantilla en la que se encuentran mtodos para el anlisis, diseo, codificacin, integracin
y mantenimiento

La fuente para determinar los riesgos en cada una de las etapas en el desarrollo de
software corresponde a los trabajos realizados por los investigadores Yacov Haimes
[HAI1996] y Ronald Higuera [HIG1996]. Las razones para elegir esta fuente se basa en el
nivel de detalle de los datos obtenidos por estos investigadores como resultado de dirigir
varias valoraciones de riesgos y pruebas de campo.

2.5.1) Anlisis de Requisitos

El proceso de reunin de requisitos se intensifica y se centra especialmente en el
desarrollo de software. Para comprender la naturaleza de el (los) programa(s) a construir, el
desarrollador de software debe comprender el dominio de la informacin del software, as
como la funcin requerida, comportamiento, rendimiento, e interconexin.

Anlisis de Requisitos
Factor de Riesgo Descripcin
Estabilidad
Cantidad de cambios realizados en los requisitos por parte
del usuario.
Integridad
La informacin proporcionada por el usuario debe ser
explcita y completa.
Validez
Los datos que entrega el usuario deben ser consistentes
con la realidad.
Claridad
La informacin y datos proporcionados por el usuario
debe ser precisa y sin ambigedades.

Tabla 2.5: Riesgos en la etapa de anlisis de requisitos [HAI1996], [HIG1996].



2.5.2) Diseo

El diseo en el desarrollo de software es un proceso de muchos pasos que se centra
en cuatro atributos distintos de un programa: estructura de datos, arquitectura del software,
representaciones de interfaz y detalle procedimental (algoritmo). El diseo traduce
requisitos en una representacin del software que se pueda evaluar por calidad antes de que
comience la generacin del cdigo. Al igual que los requisitos, el diseo se documenta y se
hace parte de la configuracin del software.


Diseo
Factor de Riesgo Descripcin
Funcionalidad
El conjunto de caractersticas y capacidades del programa,
la generalidad de las funciones desarrolladas y seguridad.
Rendimiento
Velocidad de procesamiento, tiempo de respuesta,
consumo de recursos y eficacia.
Interfaz
Datos que se intercambian entre mdulos y caractersticas
del lenguaje de programacin en el que se va a
implementar el software.
Restricciones del hardware
Las restricciones identifican los lmites del software por el
hardware externo, por la memoria disponible y otros
sistemas existentes.

Tabla 2.6: Riesgos en la etapa de diseo [HAI1996], [HIG1996].








2.5.3) Codificacin

El diseo se debe traducir en una forma legible por la mquina. El paso de
generacin de cdigo lleva a cabo esta tarea. Si se lleva a cabo el diseo de una forma
detallada, la generacin de cdigo se realiza mecnicamente.

Codificacin
Factor de Riesgo Descripcin
Implementacin del cdigo
Las especificaciones realizadas durante el diseo estn
suficientemente detalladas para escribir el cdigo.
Funcionamiento
Describe la presencia de algn problema con el
rendimiento esperado o calidad del diseo.
Restricciones del hardware
Una vez iniciado el desarrollo existe alguna limitacin de
hardware que impida cumplir algn requisito.
Viabilidad
Algunas partes de la aplicacin del producto no estn
completamente definidas por la especificacin del diseo.
Reutilizacin de software
La reutilizacin del software en algunas ocasiones puede
generar ms problemas que el desarrollo de cdigo.

Tabla 2.7: Riesgos en la etapa de codificacin [HAI1996], [HIG1996].












2.5.4) Integracin

Una vez que se ha generado el cdigo, comienza la integracin del sistema. El
proceso de integracin se centra en los procesos lgicos internos del software, asegurando
que todas las sentencias se han comprobado, y en los procesos externos funcionales, es
decir, la realizacin de pruebas para la deteccin de errores y el sentirse seguro de que la
entrada definida genere resultados reales de acuerdo con los resultados requeridos.

Integracin
Factor de Riesgo Descripcin
Ambiente
La existencia de hardware ser suficiente para realizar una
adecuada integracin y prueba del software.
Sistema Se dispone de tiempo para la integracin del sistema.
Producto
Se dispone de un criterio bien armonizado para todos los
requisitos; por ejemplo: se conoce lo que se espera
exactamente.

Tabla 2.8: Riesgos en la etapa de integracin [HAI1996], [HIG1996].














2.5.5) Mantenimiento

El software desarrollado sufrir cambios despus de ser entregado al cliente. Se
producirn cambios porque se han encontrado errores, porque el software debe adaptarse
para acoplarse a los cambios de su entorno externo o porque el cliente requiere mejoras
funcionales o de rendimiento.

Mantenimiento
Factor de Riesgo Descripcin
Confiabilidad
El diseo del producto y la documentacin son adecuados
para dar mantenimiento al cdigo.
Seguridad Existe confianza entre el personal que da mantenimiento.
Factores humanos
El personal encargado de dar mantenimiento est
motivado para dar un buen servicio.

Tabla 2.9: Riesgos en la etapa de mantenimiento [HAI1996], [HIG1996].


























2.6) Importancia de la Estimacin y Evaluacin de Riesgos

Cuando se estiman riesgos, se intenta interpretar cada riesgo de la siguiente forma:

La probabilidad que el riesgo se materialize, y
Las consecuencias de los problemas asociados con el riesgo.

La persona que estime riesgos deber realizar por lo menos cinco actividades de
estimacin:

Definir un conjunto de preguntas que permitan identificar los factores de riesgo.
Definir una escala que refleje la probabilidad del riesgo.
Definir las consecuencias del riesgo.
Determinar el impacto del riesgo.
Registrar la estimacin realizada de los riesgos.















Figura 2.6: Actividades para la estimacin de riesgos.
Definir preguntas para
factores de riesgos
1
Determinar escala de
probabilidades
2
Determinar las
consecuencias del riesgo
3
Definir el impacto del
riesgo
4
Documentar la
estimacin efectuada
5

La escala que se desarrolle puede ser definida en trminos lgicos, cualitativos o
cuantitativos. Lo recomendable es desarrollar una escala cuantitativa que incluya, por
ejemplo los siguientes valores numricos:

Escala para la probabilidad de riesgos
Bastante improbable 0,1
Improbable 0,3
Moderado 0,5
Probable 0,7
Bastante probable 0,9

Tabla 2.10: Escala de probabilidades.

Por ltimo, a los riesgos se les debe asignar un peso que estar de acuerdo con el impacto
percibido sobre la actividad que afectara y luego se les asignan prioridades. Tres factores
son los que afectan al impacto: su naturaleza, su alcance y su duracin.

La naturaleza del riesgo indica el problema que surgir si este se concreta.

El alcance de un riesgo, mezcla la severidad con su completa distribucin. (qu partes del
desarrollo del software se vern afectados?).

La duracin del riesgo considera el perodo en que se presenta y termina ste.

Con respecto a la evaluacin de riesgos, esta debe enfocarse en el logro de estimaciones lo
ms exactas posibles de manera que los riesgos se puedan ordenar de acuerdo a un criterio
determinado.





Para que la evaluacin de riesgos sea til, se debe definir un nivel de referencia para el
riesgo. Para R. Pressman [PRE1998] el costo, la planificacin y el rendimiento son los tres
niveles tpicos de referencia para el riesgo. Es decir, hay un nivel de exceso de costos, de
excesiva duracin o de degradacin del rendimiento (o cualquier combinacin de los tres)
que har que no se siga con el proyecto.

Si una combinacin de riesgos crea problemas, es decir, que se excedan uno o ms de esos
niveles de referencia, se interrumpir el trabajo. En el contexto de la evaluacin de riesgo
del software, un nivel de referencia para el riesgo slo tiene un punto, denominado punto de
referencia o punto de ruptura, en el que la decisin de continuar con el desarrollo o
detenerse es igualmente aceptable.













Figura 2.7: Nivel de referencia para el riesgo segn R. Pressman [PRE1998].






Punto de Referencia (valor del costo, valor de tiempo)
Tendr lugar el abandono del proyecto
Exceso en el costo previsto
Exceso de la planificacin temporal

La figura anterior representa esta situacin. Si una combinacin de riesgos lleva a
problemas que causan excesos de costos y de planificacin, habr un nivel, representado
por la curva de la figura, que cuando se sobrepase, provocar la terminacin del desarrollo
(la regin sombreada), en el punto de referencia, las decisiones de continuar y de parar
tienen igual peso.

El nivel de referencia difcilmente puede ser representado como una lnea ntida en el
grfico. En la mayora de los casos se trata de una regin en la que hay reas de
incertidumbre, es decir, muchas veces es imposible predecir una decisin de gestin basada
en la combinacin de valores de referencia. En consecuencia, durante la evaluacin de
riesgos, se deben seguir los siguientes pasos:

Definir niveles de referencia del riesgo para el desarrollo de un software.

Intentar desarrollar la relacin entre riesgo, probabilidad y prdida con cada uno de los
niveles de referencia.

Predecir el conjunto de puntos de referencia, que definen una regin de interrupcin del
desarrollo, limitada por una curva o por reas de incertidumbre.

Intentar predecir cmo afectarn al nivel de referencia las combinaciones de los riesgos.











2.9) Una Referencia Cuantitativa

Los datos sobre estimaciones y evaluaciones de riesgos realizadas en el pasado son difciles
de hallar, principalmente por que estos desaparecen en conjunto con los proyectos que no
llegan a buen trmino, esto ha generado una carencia de referencia bibliogrfica importante
acerca del tema. El Instituto de Ingeniera de Software (SEI) consiente de esta limitacin a
puesto a disposicin pblica los datos de sus mltiples experiencias en la identificacin y
priorizacin de riesgos en el desarrollo de software.

El SEI organiza la identificacin de riesgos en tres grandes clases: Ingeniera del Producto,
Ambiente de Desarrollo y Restricciones del Programa.

La distribucin global de todos los riesgos en la base a los datos de valoracin dentro de
estas tres clases indican una divisin sorprendentemente similar:

30% Ingeniera del Producto

33% Ambiente de Desarrollo

37% Restricciones del Programa

El mtodo utilizado por el SEI para evaluar riesgos, es la realizacin de preguntas de
riesgos para medir los factores de riesgos que estn presentes en los proyectos de
desarrollo. Las respuestas a las preguntas se registran con un s o con un no (0 o 1) o con un
rango numrico de posibles respuestas. Los rangos de respuesta pueden utilizar un valor
numrico de 0 a travs de 1. Por ejemplo, un rango de respuesta podra definirse como
ninguno = 0, pequeo = 0.2, algunos = 0.5, la mayora = 0.8, y todos = 1.





Los tipos de preguntas realizadas a cada factor de riesgo se basan normalmente en las
tendencias de la industria, datos, publicaciones, y observaciones de proyectos de desarrollo
de software exitosos e infructuosos. Para cada factor se riesgo, un rango de preguntas son
efectuadas.

El SEI utiliza probabilidades simples para evaluar riesgos potenciales y sus parmetros son:

P(A) es la probabilidad del evento A.

La probabilidad del evento A vara entre 0 y 1.

La probabilidad total del espacio de la muestra es igual a 1, y la probabilidad de ningn
resultado es 0.

Si A1, A2, ..., An es una secuencia de eventos mutuamente excluyentes, entonces P(A1 *
A2 * ... * An) = P(A1) + P(A2) + ... + P(An). En otras palabras, la probabilidad de una
secuencia de eventos mutuamente excluyentes es igual a suma de las probabilidades
individuales.

El mtodo del SEI asume que las probabilidades son asignadas por las experiencias
anteriores o por analoga de eventos pasados. Puesto que este proceso es subjetivo, la
probabilidad asignada a un evento especfico puede variar en diferentes momentos durante
el ciclo de vida del software, y as la probabilidad puede variar tambin dependiendo de las
personas que proponen la asignacin.







Los valores numricos que se utilizan son fijados por las respuestas a las preguntas de
riesgo y se utilizan rboles de probabilidad simple para calcular una estadstica de riesgo
para cada factor de riesgo que es un promedio pesado de todas las respuestas a las
preguntas de riesgo asociadas con ese factor. Esta estadstica se expresa matemticamente
de la siguiente manera: P(A) = w1 * P(A1) + w2 * P(A2) + ... + wn * P(An); donde wn es
el peso para cada probabilidad.

El mtodo utilizado por el SEI es una manera simple y flexible para la estimacin de
riesgos en el desarrollo de software. Puede ser utilizada fcilmente en organizaciones
pequeas que no pueden emplear procesos ms costosos y complejos. Adems de
determinar los riesgos de proyectos actuales, el mtodo puede predecir los riesgos para los
proyectos futuros utilizando datos de referencia y tambin permite actualizaciones a lo
largo del ciclo de desarrollo. Por otro lado, el nmero y tipo de preguntas de riesgo pueden
personalizarse para reflejar el tipo y tamao de un proyecto, as como cualquier otra
preocupacin del proyecto especfico.

Los datos estadsticos recolectados por el SEI, los cuales pueden ser consultados en el
SERR (The Software Engineering Risk Repository) son expuestos a continuacin:














Clase Ingeniera del Producto

Elementos Principales de la Clase Atributos de Cada Elemento
Estabilidad = 36%
Integridad = 21%
Viabilidad = 14%
Validez = 10%
Precedente = 8%
Escala = 7%
Requisitos = 53%
Claridad = 4%
Desarrollo = 28%
Funcionalidad = 22%
Rendimiento = 19%
Restricciones del Hardware = 15%
Dificultad = 9%
Diseo = 27%
Interfaz = 7%
Ambiente = 72%
Integracin del producto = 21% Integracin y Prueba = 14%
Integracin del sistema = 7%
Viabilidad = 33%
Comprobacin = 33% Codificacin = 4%
Codificacin/Implementacin = 33%
Especificaciones = 58%
Garanta = 25%
Mantencin = 9%
Especialidades de la ingeniera = 2%
Seguridad = 8%

Tabla 2.11: Valoracin del riesgo en la clase producto de ingeniera.


Clase Ambiente de Desarrollo

Elementos Principales de la Clase Atributos de Cada Elemento
Planificacin = 54%
Organizacin del Proyecto = 24%
Interfaz del Programa = 20%
Proceso de Administracin = 37%
Experiencia en Administracin = 2%
Formalidad = 48%
Control del Producto = 28%
Aplicabilidad = 13%
Familiaridad = 7%
Proceso de Desarrollo = 17%
Control del Proceso = 4%
Administracin del Personal = 45%
Configuracin de la Administracin = 33%
Monitoreo = 15%
Mtodos de Administracin = 17%
Control de Calidad = 7%
Capacidad = 35%
Aplicabilidad = 23%
Funcionalidad = 17%
Familiaridad = 10%
Fiabilidad = 10%
Sistema de Desarrollo = 17%
Soporte del Sistema = 5%
Comunicacin = 74%
Actitud de Calidad = 24%
Cooperacin = 1%
Ambiente de Trabajo = 12%
Moral = 1%

Tabla 2.12: Valoracin del riesgo en la clase ambiente de desarrollo.


Clase Restricciones del Programa

Elementos Principales de la Clase Atributos de Cada Elemento
Personal = 50%
Planificacin = 21%
Facilidades = 18%
Recursos = 43%
Presupuestos = 11%
Administracin = 25%
Retrasos = 21%
Interfaz de Usuario = 19%
Cliente Abastecedor de Recursos = 12%
mbito/Organizacin = 12%
Cliente = 39%
Conocimiento Tcnico = 10%
Subcontratantes = 25%
Administracin Corporativa = 25%
Vendedores = 22,5%
Primer Contratista = 15%
Interfaces del Programa = 11%
Polticas = 12,5%
Dependencia = 54%
Tipo de Contrato = 36% Contrato = 7%
Restricciones = 10%

Tabla 2.13: Valoracin del riesgo en la clase restricciones del programa.








La valoracin probabilstica proporcionada por el SEI marca un precedente muy valioso
como referencia cuantitativa, ya que permite obtener diversas conclusiones acerca de los
elementos de riesgo que necesitan ser considerados para futuros desarrollos,
especficamente a conclusiones del tipo siguiente:

La muestra global de los riesgos dentro de las tres clases, Ingeniera del Producto (30%),
Ambiente de Desarrollo (33%) y Restricciones del Programa (37%) nos indican que el
riesgo se distribuye uniformemente a lo largo de todas las actividades de desarrollo.
Necesariamente se debe invertir una cantidad significativa de esfuerzo en el anlisis de
riesgo para lograr buenos resultados.

La valoracin para el Proceso de Administracin (37%) y Recursos (43%) dominan
claramente a los restantes elementos de su clase, obedeciendo a esto se concluye que la
responsabilidad de los niveles alto de la organizacin es sumamente importante al momento
de planificar, seleccionar personal y delegar responsabilidades.

Un dato sorprendente es la baja valoracin para el elemento codificacin (2%), al parecer
las personas encargadas de esta actividad realizan su labor sin muchos inconvenientes. Los
responsables de generar cdigo generalmente se ubican en un nivel ms bien inferior dentro
de una organizacin, hecho que se contrapone con el anterior.

La alta ponderacin para el elemento requisitos (53%) y cliente (39%) slo confirman la
existencia de una estrecha relacin entre ambos elementos. De acuerdo a esto, las personas
encargadas de tratar con clientes y elaborar requisitos deben desarrollar habilidades
generales para disminuir tan altas ponderaciones, ya que un error en los requisitos detectado
en etapas avanzadas del desarrollo pueden resultar fatales y siempre recordar que la
responsabilidad principal no recae tan solo en el cliente sino en la persona que acepta tales
requisitos.




Visto desde un contexto global el presente trabajo hasta el momento a querido demostrar en
base a antecedentes, estudios anteriores y opiniones personales lo siguiente: Si en el
desarrollo de software no se toma conciencia real de la influencia de los riesgos
muchas cosas pueden salir mal. Qu hacer al respecto?, sera una pregunta lgica a esta
altura. La respuesta seria conocer y adoptar una gua que nos indicara como afrontar
sistemticamente y disciplinadamente la influencia de los riesgos. Esta gua es reconocida
con el nombre de Administracin de Riesgos, tema a tratar a continuacin.












































LA ADMINISTRACIN DE RIESGOS EN EL DESARROLLO DE SOFTWARE

3.1) Justificacin de la Administracin de Riesgos

Si no atacamos activamente a los riesgos, ellos nos atacarn activamente [GILB88].

Esta frase de Tom Gilb nos induce a administrar los riesgos antes de que estos causen
inconvenientes graves en el desarrollo de software, la manera de evitar estos inconvenientes
es a travs de un enfoque de administracin de riesgos que proporcione las herramientas
necesarias para comprender y tomar decisiones acerca de los riesgos que puedan impedir el
normal desarrollo del software.

En opinin de Ronald Higuera [HIG96], la necesidad de administrar riesgos aumenta con la
complejidad de los sistemas; cuando la complejidad en el desarrollo de software aumenta,
los riesgos tcnicos y no tcnicos crecen notablemente. El conocimiento individual, el buen
discernimiento y la experiencia son suficientes para controlar riesgos menos complejos,
pero insuficientes para los de mayor complejidad, esto ha generado una necesidad creciente
por mtodos sistemticos y herramientas para complementar estas habilidades humanas.




Figura 3.1: La necesidad de administrar riesgos aumenta con la complejidad de los
sistemas.


















3.2) Definicin de Administracin de Riesgos

La revista Information & Management de 1994, proporciona la siguiente definicin de
administracin de riesgo:

La administracin de riesgos es la ciencia y arte de reconocer la existencia de amenazas,
determinando sus consecuencias sobre los recursos, aplicando modificaciones costo
efectivas sobre los factores para mantener las consecuencias adversas dentro de lmites
establecidos.

Por su parte Jim McCarthy[MCC2000] nos entrega lo siguiente como definicin de
administracin de riesgos:

La administracin de riesgos desarrolla una disciplina y un ambiente de decisiones y
acciones proactivas para valorar ininterrumpidamente lo que puede fallar, determinar cules
riesgos son importantes de enfrentar e implementar estrategias para abordarlos.

Como se ve la administracin de riesgos es un conjunto de actividades que buscan tomar
decisiones y acciones frente a posibles problemas identificados, que en un momento dado
pueden aparecer. Lo importante es que la administracin de riesgo como concepto nos
proporciona una estructura lo bastante general para cubrir el proceso de desarrollo del
software de manera integra.










3.3) Estrategias de Administracin de Riesgos

Existen dos estrategias para el riesgo. Una es reactiva y la otra proactiva. La estrategia de
riesgo reactiva significa que los integrantes de una organizacin reaccionan a las
consecuencias de los riesgos conforme a su ocurrencia. La estrategia de riesgo proactiva
significa que la organizacin cuenta con un proceso visible para manejar los riesgos. Este
proceso se puede medir y repetir.

La prevencin del riesgo es el punto de transicin entre las estrategias reactivas y
proactivas. La prevencin ocurre en las etapas de planeacin de un proyecto, cuando el
equipo puede aplicar acciones para impedir que ocurran los riesgos. Esencialmente, la
prevencin es todava una estrategia reactiva para manejar riesgos; no es un remedio para la
causa del riesgo, slo una forma de evitar sus sntomas.

Para alcanzar los niveles ms altos de la estrategia de riesgo proactiva, el equipo debe estar
dispuesto a tomar riesgos. Esto significa no temer el riesgo, sino considerarlo como un
medio para crear oportunidades adecuadas. Para conseguirlo, el equipo debe ser capaz de
evaluar imparcialmente los riesgos (y las oportunidades) y, a continuacin, aplicar acciones
que aborden las causas de estos riesgos, no slo sus sntomas.

Es importante notar que el factor determinante para tener xito no es la calidad de la
valoracin del riesgo, sino la capacidad del equipo para manejar el riesgo y la oportunidad.










3.4) Dificultades que Enfrenta la Administracin de Riesgos

Microsoft Corporation en su publicacin Estrategia y Planeacin: Administracin de
Riesgos [EST2000], identifica cuatro puntos principales que dificultan la administracin
de riesgos en el desarrollo de software:

Aceptacin y Reconocimiento de los Riesgos.

La aceptacin del riesgo es esencial para el progreso y a menudo los fracasos son una parte
fundamental del aprendizaje. Aunque algunos riesgos no se puedan evitarse, el intentar
reconocerlos y controlarlos no debe limitar las oportunidades de emplear la creatividad.

2. Percepcin Errnea de la Administracin de Riesgos.

Muchos profesionales del desarrollo de software poseen un concepto errneo de la
administracin de riesgos y en el mejor de los casos, la consideran una actividad necesaria
pero aburrida que se debe efectuar al comienzo de un proyecto antes del trabajo real de
escribir. El enfrentar los riesgos requiere que la administracin se considere como parte de
un proceso dinmico y competitivo, en lugar de slo una actividad adicional y esttica de la
administracin de un proyecto.

3. Comunicacin de los Riesgos.

Es importante tener presente que en muchas ocasiones los integrantes de un equipo conocen
los riesgos, pero no los comunican en forma adecuada. Por lo general, es fcil informar de
los riesgos hacia abajo en la cadena de mando, pero es difcil hacerlo en sentido contrario.
En todos los niveles, las personas pretenden conocer los riesgos de los niveles inferiores,
pero muchas veces no los comunican abiertamente a quienes estn a un nivel ms alto.

4. Ausencia de Condiciones para Informar Riesgos.


Cuando los riesgos se perciben como algo negativo, los integrantes de un equipo se sienten
renuentes a informar sobre ellos. En algunos proyectos, el mencionar los riesgos nuevos se
toma como una queja. En ciertas situaciones, una persona que habla de los riesgos recibe el
calificativo de conflictiva, y las reacciones se concentran en la persona, antes que en los
riesgos. Bajo estas circunstancias, los miembros de un equipo tienen reservas para
comunicar sus opiniones con libertad. Seleccionan y suavizan la informacin de riesgos que
deciden compartir para que no resulte demasiado negativa en relacin con las expectativas
de los dems integrantes.


















Figura 3.2: Dificultades en la administracin de riesgos segn Microsoft Corporation
[EST2000].

Administracin
de riesgos
Administracin
de riesgos
Enfrenta
Dificultades como: Dificultades como:
Comunicar
riesgos
Comunicar
riesgos
Aceptar y
reconocer riesgos
Aceptar y
reconocer riesgos
Percepcin errnea de la
administracin de riesgos
Percepcin errnea de la
administracin de riesgos
Ausencia de condiciones
para informar riesgos
Ausencia de condiciones
para informar riesgos