• Author / Uploaded
• MagnoliushkaMandarinishkova

• Categories
• Ingeniería de software
• Software
• Probabilidad
• Toma de decisiones
• Proceso de desarrollo de software

Citation preview

INTRODUCCIÓN 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, diseño inadecuado, error en la contratación, problemas de personal, problemas con la tecnología, cambio en las leyes del gobierno y problemas con el desarrollo, por nombrar sólo algunos de ellos). Según 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 lección clara sobre los

efectos de los riesgos cuando éstos nos son considerados como relevantes. “Word para

Windows, necesitó 5 años para su desarrollo, consumió 660 personas-mes de esfuerzo de desarrollo, y generó un sistema de 249.000 líneas de código” [IAN1994]. La planificación final de 5 años fue aproximadamente cinco veces mayor de la diseñada en un principio y el

proyecto experimentó un cambio de personal extremadamente alto, además de una baja calidad en las prestaciones. Existe una serie de métodos y modelos para administrar riesgos que pueden prevenir los inconvenientes mencionados anteriormente; la administración de riesgos es un tema relativamente nuevo, pero ya existe información suficiente como para tratarlo con profundidad en este documento. El objetivo de este trabajo se centra en la comparación de modelos de administración

de riesgos cuya función principal es la de identificar, estudiar y eliminar las fuentes de riesgos antes de que empiecen a amenazar la finalización satisfactoria de un proyecto de software.

Para establecer una base teórica 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 génesis, es decir, establecer una definición, 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 administración de riesgos. ¿Qué se espera de este trabajo? Un pequeño aporte que permita difundir y reconocer a

los modelos de administración riesgos como buenos métodos para el desarrollo de software, y del mismo modo infundir su utilización cuyos beneficios generarán profundas implicaciones en el logro final de un desarrollo, referidos a una menor tasa de errores, mayor aceptación por parte del usuario, mejor facilidad de mantenimiento y un menor costo y tiempo de desarrollo.

SECCIÓN 1: EL CONCEPTO RIESGO 1.1) Percepción del Riesgo La forma en que la gente percibe el riesgo en su vida diaria, es mas bien, una noción de sentido común, la cual se asocia a un sin número de factores sociales y psicológicos. 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 percepción del riesgo en la gente son: El potencial catastrófico de la fuente, el conocimiento o no de los mecanismos de ocurrencia, la incertidumbre, la posibilidad de que sea controlable y orígenes entre otros.

Por otro lado, las decisiones acerca de los riesgos pueden ser realizadas a nivel individual y/o colectivo. A nivel individual, la opción 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 decisión es más difícil y controversial - como la instalación de un vertedero en una ciudad -.

En resumen, la percepción de los riesgos es un concepto con varias aristas y su apreciación

dependerá de cada individuo y situación particular. De acuerdo a esto podemos establecer a

priori que los riesgos son intrínsicos a cualquier actividad humana, y como tal, imposibles de no considerar al momento de tomar una decisión. Conforme a esta realidad sólo nos queda reconocer la existencia de ellos y buscar los métodos y mecanismos necesarios que minimicen las consecuencias negativas de estos sobre nuestro diario vivir. Si bien en los párrafos anteriores se han esbozados algunas ideas sobre el concepto riesgo, aún 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é definición de

riesgo debemos utilizar?, ¿cuál es la naturaleza del riesgo?, ¿qué fuentes de riesgo existen?, ¿cómo podemos clasificarlos?, ¿cuáles son las implicancias de los riesgos?.

1.2) Definición de Riesgo Una noción intuitiva del riesgo es la siguiente: Eventualidad de que ocurra un hecho

capaz de producir algún daño. Sin embargo; para establecer un fundamento más amplio del concepto riesgo citaremos las siguientes definiciones proporcionadas por la literatura: “Probabilidad de un evento adverso multiplicada por la magnitud del daño que causa” [JON1998] “Implicancia de incertidumbre y pérdida” [HIG1995] “Posibilidad de pérdida o cualquier característica, objeto o acción que esta asociado con esa posibilidad” [KON1995]

“Peligro, contingencia de un daño” [LAR1981] “Evento no deseado que tiene consecuencias negativas” [LAW1995] “Suceso que puede ocurrir en el futuro; una posibilidad, no una certeza” [VAN1992] “Posibilidad de pérdida o lesión; grado de probabilidad de tal pérdida” [WEB1989] A pesar de las definiciones anteriores es necesario explicar algunos conceptos implícitos utilizados en las definiciones, en particular nos referimos a la probabilidad, incertidumbre y pérdida. Probabilidad: “Característica de un suceso del que existen razones para creer que se realizará” [LAR1981] Incertidumbre: “Falta de seguridad, certeza y convicción” [LAR1981] Pérdida: “Desgaste, mengua, perjuicio o privación de una cosa” [LAR1981]

Las definiciones para el término riesgo son abundantes y amplias. Sin embargo; en la mayoría de estas se puede desprender que la esencia del riesgo consiste en una combinación de la

noción de pérdida con la de azar o probabilidad, es por esto que nuestra definición considerará

a estos dos elementos como fundamentales, en donde la pérdida dependerá de las expectativas, las que a su vez dependerán de las personas que las evalúan.

La idea de azar es crucial: lo inevitable puede ser ciertamente desagradable pero al no tener carácter probabilístico no constituye un riesgo. De este modo el concepto riesgo para este trabajo considerará la siguiente definición: “evento que se caracteriza por su probabilidad de ocurrencia y pérdida asociada, la cual estará definida por expectativas evaluadas por personas”. Atributos del Riesgo Probabilidad

Pérdidad

Evento no Deseado

Riesgo

Materialización del riesgo

Pérdida

Figura 1.1: Concepto riesgo.

Incertidumbre

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, Modificantes y Consecuencias.

Factores

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 reducción, protección,

transferencia

y

financiamiento son aquellos que influyen en la probabilidad de que una amenaza se concrete.

Reducción: Se refiere a las acciones que pueden tomarse para eliminar el riesgo o reducir su gravedad. Protección: Se refiere a la utilización de medios físicos, para alcanzar los mismos objetivos que la reducción. Transferencia: Se refiere a la decisión 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.

Basándonos en la información proporcionada por Information & Management [INF1994] los componentes del riesgo pueden ser esquematizados de la siguiente manera: Consecuencias Amenazas

Probabilidad de Ocurrencia

Factores Modificantes

- Magnitud - Severidad

- Reducción

Recursos - Peronas

- Protección

- Activos

- Transferencia

- Ganacias

- Financiamiento

Figura 1.2: Componentes del riesgo.

1.4) Fuentes de Riesgo Aún sin analizar los diferentes componentes del concepto “pérdida”, debería reconocerse que el estar expuesto a fuentes de riesgos no es algo necesariamente malo. Los logros de la vida moderna implican la exposición a varias fuentes de riesgos, y el desarrollo alcanzado a través de la historia no sería posible sin los riesgos incurridos por nuestros antepasados. Los riesgos tienen distintos orígenes, Vaughan [VAU1982] establece como fuentes de origen las siguientes: Riesgos naturales: Aquellos originados por fenómenos de la naturaleza como las inundaciones, terremotos, erupciones volcánicas, etc. Riesgos tecnológicos: Aquellos asociados a accidentes de origen tecnológico, como el riesgo químico, el nuclear o el transporte de mercancías peligrosas.

Riesgos antrópicos: Aquellos generados por la actividad del hombre, como el transporte público, grandes concentraciones de personas, colapso de un edificio, etc. Riesgos particulares: Están relacionados con pérdidas que afectan a individuos más que a un grupo entero. Los riesgos particulares son considerados responsabilidad de los propios individuos. Estos riesgos pueden ser objeto de asegurabilidad, prevención o alguna otra técnica. Riesgos especulativos: Describen situaciones en donde existe posibilidad de pérdida, pero

también de ganancia, en este contexto el riesgo es deliberadamente creado con la esperanza de ganar (inversiones y juegos de azar).

Riegos dinámicos: Son aquellos que resultan de cambios en la economía, cambios en el nivel

de precios, en la demanda de consumidores, en la tecnología, etc. , y que pueden causar pérdida financiera a los miembros de la sociedad. Estos riesgos dinámicos normalmente tienen

impacto en la sociedad a largo plazo. Los riesgos dinámicos pueden afectar a un gran número

de individuos, pero son menos predecibles que los riesgos estáticos ya que ocurren sin ninguna regularidad. Riesgos estáticos: Estos involucran aquellas pérdidas que ocurrirían aún si no hubiera cambios en la economía, se relacionan con la deshonestidad de los individuos y con su pericia. La pérdida estática esta relacionada con la destrucción de algún bien o el cambio de su posesión como resultado del error humano. Los riesgos estáticos tienden a ocurrir con algún grado de regularidad y por lo tanto predecibles y perceptibles de aseguramiento. Riesgos fundamentales: Están relacionados con pérdidas que son impersonales en pérdida y en origen, son grupo de riesgos que son causados fundamentalmente por la economía, la sociedad

y los fenómenos políticos, así como también de los fenómenos físicos, afectan a largos

segmentos de la población o inclusive a toda ella, por ejemplo: desempleo, guerra, inflación y terremotos. Después de obtener una comprensión de la naturaleza del riesgo, el próximo paso es situar un fundamento para manejarlo. El riesgo debe segmentarse en pedazos manejables. El primer segmento es una clasificación o descomposición de riesgos en un conjunto amplio, relacionándolo 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 fácil determinar en que categoría 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 clasificación para el concepto riesgo no existe, sólo se puede contar con clasificaciones que responden a determinados autores y criterios: Según R. Dorfman [DOR1980], los riesgos en base a su impacto pueden clasificarse en: Riesgos Catastróficos o fatales para la empresa

Descripción

Aquellos que de producirse resultarían en una

descapitalización, abandono o discontinuidad a corto plazo del negocio. Aquellos que ocasionarían una pérdida

Importante o muy serio

considerable que se reflejaría en los activos

patrimoniales y obligaría a un cambio en su política de inversión.

Aquellos con impacto significativo sobre el Mediano o moderadamente serio

balance de ganancias y pérdidas, que requeriría la atención de la alta gerencia.

Mínimo y sin importancia relativa

Cualquier riesgo cuya pérdida puede ser cubierta con las reservas normales de contingencia. Cuando no se puede determinar la pérdida que

Seriedad desconocida

ocasiona el riesgo. Una vez determinada la pérdida, se debe clasificar en una de las anteriores categorías.

Tabla 1.1: Clasificación de riesgos según su impacto [DOR1980].

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

Clase II

Clase III

Descripción

Aquellos que de suceder generan pérdidas que no alteran las finanzas básicas con endeudamiento. Aquellos que generan pérdidas y que llevarán a la empresa a incurrir en endeudamiento. Aquellos que generan pérdidas mayores que la Clase I, Clase II, y que podrían llevar la empresa a la quiebra.

Tabla 1.2: Clasificación de riesgos según su gravedad [HED1961]. Robert Charette [CHA1989] propone la siguiente clasificación: Riesgos

Descripción Son aquellos que pueden descubrirse luego de una

Conocidos

minuciosa evaluación del plan del proyecto, el negocio y el ambiente técnico en el cuál el proyecto será desarrollado.

Predecibles

Impredecibles

Son aquellos que pueden ser extrapolados desde experiencias de proyectos anteriores. Son aquellos extremadamente difíciles de identificar con anticipación.

Tabla 1.3: Clasificación de riesgos según R. Charette [CHA1989].

Roger Pressman [PRE1998] organiza los riesgos en: Riesgos Proyectos

Técnicos

Descripción Aquellos riesgos que afectan al presupuesto, recursos, planificación, personal y clientes.

Se refieren a los riesgos en el diseño, implementación de interfaces, verificación y mantención de problemas. Son los que amenazan la viabilidad del producto a

Negocio

construir, y afectan a la estrategia comercial, presupuestos, mercadeo y dirección.

Genéricos

Son amenazas potenciales para todos los proyectos de software. Son aquellos que pueden ser identificados con un claro

Específicos

entendimiento de la tecnología, personal y medio ambiente específico para cada proyecto.

Tabla 1.4: Clasificación de riesgos según 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 conclusión, el riesgo implica dinamismo y multitud de facetas que pueden involucrar áreas económicas, científicas, sociales y políticas. De acuerdo a lo anterior, se puede decir, que las implicancias del riesgo son fácilmente identificables; sin embargo, las causas que propician su aparición pueden ser múltiples y de índole muy diversa. Una misma causa puede generar más 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 informático en donde mayor número de inconvenientes se pueden presentar gracias a una de sus características principales la incertidumbre”.

Con el crecimiento del software y la confianza que depositan las organizaciones en él,

también crecen las consecuencias relacionadas con sus fallas. Todas estas fallas han sido

riesgos que se materializan durante su desarrollo y podrían haberse evitado o mitigado con la aplicación de una correcta y formal política de preocupación acerca de lo que verdaderamente implica el riesgo en el desarrollo del software. No es incuestionable que el desarrollo de software en estas últimas décadas se haya

convertido en una de las actividades económicas más 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?, ¿cómo pueden ser clasificados?, ¿qué riesgos son mas relevantes?, y ¿cuál es la opinión de especialistas acerca de este tema?.

CAPÍTULO 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 relación a los plazos y presupuestos establecidos originalmente. El fundamento de esta afirmación se basa en la opinión del especialista en

ingeniería de software Roger Pressman [PRE1988] y en un estudio realizado por la empresa norteamericana de investigación de mercado Standish Group [STA1994].

Roger Pressman en su libro “Ingeniería de Software: Un enfoque práctico” reconoce la existencia de problemas en el desarrollo de software describiéndolos de la siguiente manera: “Muchos particulares y muchas compañías desarrollan todavía el software de forma muy aleatoria. De igual modo muchos profesionales y estudiantes siguen sin conocer los métodos modernos. El estado de la ingeniería del software sigue siendo un estudio muy diversificado. Las actitudes han cambiado y se ha progresado considerablemente, pero todavía 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 métodos modernos para el desarrollo de software tendría solución, la ignorancia siempre es un mal curable. Pero que podemos hacer con respecto a que la ingeniería 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 información acerca de 8.000 proyectos de desarrollo de software de un total de 352 compañías. Los resultados de este reporte son:

31% de los proyectos se cancelaron antes de su finalización.

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 pequeñas empresas. De los proyectos concluyeron exitosamente, en pequeñas empresas

Proyectos cancelados

16%

31%

9% De los proyectos concluyeron exitosamente, en grandes empresas

53% De lo proyectos excedieron sus costos

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

En pequeñas empresas sólo 16% de los proyectos de software se completaron a tiempo y en

el presupuesto. En empresas más grandes, las noticias son aún peores: sólo el 9% de sus proyectos culminan a tiempo y en el presupuesto estimado. Sin embargo; estos proyectos completados en empresas grandes sólo registran un 42% aproximadamente de los rasgos

originalmente propuestos en los requerimientos. Las empresas de menor tamaño lo hacen mucho mejor, ya que, alcanzan un 74,2% de los rasgos originales y funciones establecidos en los requerimientos. ¿Cuál es nuestra realidad?, se desconoce la existencia de algún estudio similar al anterior,

a excepción 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 señala la siguiente realidad al interior de empresas nacionales que desarrollan software: No existe medición del proceso ni registro de datos históricos.

Mal uso de herramientas automatizadas para la planificación y estimación. Excesiva e irracional presión en los calendarios. Estimaciones imprecisas de plazos y costos. Crecimiento excesivo en los requerimientos para un producto de software. No se hace gestión de riesgos formalmente. No se realiza un proceso formal de pruebas. No se realizan revisiones técnicas formales e inspección del código. Además proporcionan una estimación de los riesgos probables por áreas de práctica que pueden afectar el desarrollo de software y una lista de riesgos frecuentes:

Riesgo probable por área de prácticas Gestión de requerimientos

70 60

Planificación de proyecto

50 40 30

Seguimiento y control de proyecto

Garantía de calidad de software

20 10 0

Gestión de configuración

Figura 2.2: Riesgos probables por área de práctica [INT1998]. Los criterios de aceptación no son claros

El proyecto depende de algunos individuos

Ausencia de planificación en el proyecto

Riesgos más Frecuentes

Interferencia excesiva del cliente

No todos los involucrados comprenden los requerimientos

Función de garantía de calidad inadecuada

Figura 2.3: Riesgos más frecuentes en Chile, según INTEC [INT98].

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 planificación. 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 problemática muchas organizaciones han puesto sus esperanzas en soluciones

tecnológicas: Herramientas Case, Lenguajes de Cuarta Generación, Sistemas Expertos y Prototipos. Los desarrolladores actuales no carecen de opciones. Lamentablemente, tratar de desarrollar software considerando sólo las herramientas y técnicas es como adivinar el resultado de una mezcla de elementos.

En opinión 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 Ingeniería 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 educación necesaria para los cambios en procesos y tecnologías. Distribuir eficazmente la tecnología apropiada. Medir y comunicar la contribución de los desarrolladores a la empresa y manejar su proceso interno. A menudo las herramientas tecnológicas son consideradas como las salvadoras de los desarrolladores de software. Sin embargo, en la publicación “Ingeniería de Software para Sobrevivir en los Noventas” de la revista informática (julio de 1990) se establece la siguiente realidad: El 70% de las herramientas y técnicas no son utilizadas. El 25% de las herramientas son utilizadas por un sólo grupo. El 5% de las herramientas son ampliamente utilizadas, pero no a toda su capacidad. Michael Hammer señala que “a pesar de la explosión de técnicas, herramientas y tecnologías los problemas en el desarrollo de software no han desaparecido”. “Muchas inversiones fuertes en tecnologías de la información han arrojado resultados frustrantes". [HAM1990]

El buen desarrollo de software implica una combinación inteligente y hábil de

herramientas, conceptos y métodos 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 además está inmersa en un ambiente dinámico en el cual fructifican los riesgos, es que consideramos relevante el establecimiento de los tipos de riesgos que afectan al desarrollo de software, a través de algunas clasificaciones.

2.4) Clasificación de Riesgos en el Desarrollo de Software Según D. Karolak [KAR1996], los riesgos que afectan el desarrollo de software

pueden verse a través de dos perspectivas, la tecnológica y la comercial.

Los riesgos de la tecnología o técnicos incluyen los algoritmos, disponibilidad de tecnología 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 tecnológico y comercial, hay tres elementos de riesgo del software: Técnico, Costo y Planificación.

2.4.1) Riesgos Técnicos De acuerdo a Dale Karolak [KAR1996] los riesgos técnicos 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 diseñadas.

Calidad: El software puede satisfacer las expectativas de los clientes. Fiabilidad: La capacidad del software para funcionar dentro de los períodos de tiempo establecidos sin error. Utilidad: El software y la documentación presentan características para proporcionar una fácil implementación de los requisitos del usuario.

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

Mantención: Características del software y la documentación para ser mantenido fácilmente. Reutilización: Las características del software para ser utilizado de nuevo en una aplicación similar o diferente. La importancia de los problemas de riesgos técnicos es determinada por la percepción hecha por los clientes, gerencia y diseñador del software. 2.4.2) Riesgos del Costo Los riesgos del costo en opinión de Dale Karolak [KAR1996] están asociados con el costo del producto del software durante el desarrollo del proyecto. El costo del software involucra los siguientes tópicos: Presupuesto: La capacidad de desarrollar software, su documentación asociada y servicios dentro de un límite de gastos establecidos por la administración.

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 varían, como el costo de reproducción de software y documentación.

Costos Variables: La habilidad de identificar y manejar costos que varían con la cantidad de actividades de desarrollo del software, como el tiempo rentado de la computadora. Ganancia / Margen de Pérdida: 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 pérdida de ganancia del producto del software. La identificación, valoración y predicción de riesgos del costo influirán en el apoyo y en la inversión de la administración 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 Planificación El riesgo de la planificación esta asociado con la planificación del producto de software durante el desarrollo. La planificación del desarrollo de software, según Dale Karolak [KAR1996] involucra lo siguiente: Flexibilidad: La planificación realizada presenta características 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 técnicos para encontrar los hitos establecidos en una planificación. Realismo: La planificación refleja las expectativas de los clientes, administración y desarrolladores de software con exactitud.

Proyecto de Desarrollo de Software

Perspectiva Tecnológica

Perspectiva Comercial

  

Riesgos Técnicos Riesgos del Costo Riesgos de la Planificación

Figura 2.4: Riesgos en el desarrollo de software según D. Karolak [KAR1996]. 2.5) Riesgos en las Etapas de Desarrollo de Software La clasificación de riesgos realizada por Karolak [KAR1996] y la identificación de

riesgos típicos 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 descripción de los riesgos en cada una de las etapas del desarrollo del software nos proporcionaría un enfoque más particular sobre el tema. Para la determinación 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 clásico” o “modelo en cascada”, el modelo secuencial o lineal sugiere un enfoque sistemático, secuencial de desarrollo de software que contempla las siguientes etapas: análisis de requisitos, diseño, codificación, integración y mantenimiento.

El modelo lineal o secuencial es el paradigma más antiguo y más extensamente

utilizado en el desarrollo del software. Sin embargo; la crítica del paradigma ha puesto en

duda su eficacia [HAN1995]. Pese a las críticas el paradigma del ciclo de vida clásico tiene

un lugar definido e importante en el trabajo de la ingeniería de software. Proporciona una plantilla en la que se encuentran métodos para el análisis, diseño, codificación, integración 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) Análisis de Requisitos El proceso de reunión 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 información del software, así como la función requerida, comportamiento, rendimiento, e interconexión. Análisis de Requisitos Factor de Riesgo Estabilidad

Integridad

Validez

Claridad

Descripción Cantidad de cambios realizados en los requisitos por parte del usuario. La información proporcionada por el usuario debe ser explícita y completa.

Los datos que entrega el usuario deben ser consistentes con la realidad. La información y datos proporcionados por el usuario debe ser precisa y sin ambigüedades.

Tabla 2.5: Riesgos en la etapa de análisis de requisitos [HAI1996], [HIG1996].

2.5.2) Diseño El diseño 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 diseño traduce requisitos en una representación del software que se pueda evaluar por calidad antes de que comience la generación del código. Al igual que los requisitos, el diseño se documenta y se hace parte de la configuración del software.

Diseño Factor de Riesgo Funcionalidad

Rendimiento

Descripción El conjunto de características y capacidades del programa, la generalidad de las funciones desarrolladas y seguridad. Velocidad de procesamiento, tiempo de respuesta, consumo de recursos y eficacia. Datos que se intercambian entre módulos y características

Interfaz

del lenguaje de programación

en el que se va a

implementar el software. Las restricciones identifican los límites del software por el Restricciones del hardware

hardware externo, por la memoria disponible y otros sistemas existentes.

Tabla 2.6: Riesgos en la etapa de diseño [HAI1996], [HIG1996].

2.5.3) Codificación El diseño se debe traducir en una forma legible por la máquina. El paso de

generación de código lleva a cabo esta tarea. Si se lleva a cabo el diseño de una forma detallada, la generación de código se realiza mecánicamente. Codificación Factor de Riesgo Implementación del código Funcionamiento

Restricciones del hardware

Viabilidad Reutilización de software

Descripción Las especificaciones realizadas durante el diseño están suficientemente detalladas para escribir el código. Describe la presencia de algún problema con el rendimiento esperado o calidad del diseño. Una vez iniciado el desarrollo existe alguna limitación de hardware que impida cumplir algún requisito.

Algunas partes de la aplicación del producto no están completamente definidas por la especificación del diseño.

La reutilización del software en algunas ocasiones puede generar más problemas que el desarrollo de código.

Tabla 2.7: Riesgos en la etapa de codificación [HAI1996], [HIG1996].

2.5.4) Integración Una vez que se ha generado el código, comienza la integración del sistema. El

proceso de integración se centra en los procesos lógicos internos del software, asegurando que todas las sentencias se han comprobado, y en los procesos externos funcionales, es decir, la realización de pruebas para la detección de errores y el sentirse seguro de que la entrada definida genere resultados reales de acuerdo con los resultados requeridos. Integración Factor de Riesgo Ambiente Sistema

Descripción La existencia de hardware será suficiente para realizar una adecuada integración y prueba del software.

Se dispone de tiempo para la integración del sistema. Se dispone de un criterio bien armonizado para todos los

Producto

requisitos; por ejemplo: se conoce lo que se espera exactamente.

Tabla 2.8: Riesgos en la etapa de integración [HAI1996], [HIG1996].

2.5.5) Mantenimiento El software desarrollado sufrirá cambios después de ser entregado al cliente. Se

producirán 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 Confiabilidad Seguridad Factores humanos

Descripción El diseño del producto y la documentación son adecuados para dar mantenimiento al código. Existe confianza entre el personal que da mantenimiento. 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 Estimación y Evaluación 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 estimación:

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 estimación realizada de los riesgos.

Definir preguntas para factores de riesgos

Determinar escala de probabilidades 1

2

Determinar las consecuencias del riesgo

Definir el impacto del riesgo

3

4

Documentar la estimación efectuada 5

Figura 2.6: Actividades para la estimación de riesgos.

La escala que se desarrolle puede ser definida en términos lógicos, cualitativos o cuantitativos. Lo recomendable es desarrollar una escala cuantitativa que incluya, por ejemplo los siguientes valores numéricos: 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 afectaría y luego se les asignan prioridades. Tres factores son los que afectan al impacto: su naturaleza, su alcance y su duración. La naturaleza del riesgo indica el problema que surgirá si este se concreta. El alcance de un riesgo, mezcla la severidad con su completa distribución. (¿qué partes del desarrollo del software se verán afectados?).

La duración del riesgo considera el período en que se presenta y termina éste. Con respecto a la evaluación de riesgos, esta debe enfocarse en el logro de estimaciones lo

más exactas posibles de manera que los riesgos se puedan ordenar de acuerdo a un criterio determinado.

Para que la evaluación de riesgos sea útil, se debe definir un nivel de referencia para el

riesgo. Para R. Pressman [PRE1998] el costo, la planificación y el rendimiento son los tres niveles típicos de referencia para el riesgo. Es decir, hay un nivel de exceso de costos, de

excesiva duración o de degradación del rendimiento (o cualquier combinación de los tres) que hará que no se siga con el proyecto.

Si una combinación de riesgos crea problemas, es decir, que se excedan uno o más de esos niveles de referencia, se interrumpirá el trabajo. En el contexto de la evaluación de riesgo

del software, un nivel de referencia para el riesgo sólo tiene un punto, denominado punto de

referencia o punto de ruptura, en el que la decisión de continuar con el desarrollo o detenerse es igualmente aceptable. Exceso de la planificación temporal

Punto de Referencia (valor del costo, valor de tiempo) Tendrá lugar el abandono del proyecto

Exceso en el costo previsto

Figura 2.7: Nivel de referencia para el riesgo según R. Pressman [PRE1998].

La figura anterior representa esta situación. Si una combinación de riesgos lleva a problemas que causan excesos de costos y de planificación, habrá un nivel, representado por la curva de la figura, que cuando se sobrepase, provocará la terminación del desarrollo (la región sombreada), en el punto de referencia, las decisiones de continuar y de parar tienen igual peso. El nivel de referencia difícilmente puede ser representado como una línea nítida en el

gráfico. En la mayoría de los casos se trata de una región en la que hay áreas de incertidumbre, es decir, muchas veces es imposible predecir una decisión de gestión basada en la combinación de valores de referencia. En consecuencia, durante la evaluación de riesgos, se deben seguir los siguientes pasos:

Definir niveles de referencia del riesgo para el desarrollo de un software. Intentar desarrollar la relación entre riesgo, probabilidad y pérdida con cada uno de los niveles de referencia. Predecir el conjunto de puntos de referencia, que definen una región de interrupción del desarrollo, limitada por una curva o por áreas de incertidumbre.

Intentar predecir cómo afectarán 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 difíciles de hallar, principalmente por que estos desaparecen en conjunto con los proyectos que no llegan a buen término, esto ha generado una carencia de referencia bibliográfica importante

acerca del tema. El Instituto de Ingeniería de Software (SEI) consiente de esta limitación a

puesto a disposición pública los datos de sus múltiples experiencias en la identificación y priorización de riesgos en el desarrollo de software.

El SEI organiza la identificación de riesgos en tres grandes clases: Ingeniería del Producto, Ambiente de Desarrollo y Restricciones del Programa. La distribución global de todos los riesgos en la base a los datos de valoración dentro de estas tres clases indican una división sorprendentemente similar: 30% Ingeniería del Producto 33% Ambiente de Desarrollo

37% Restricciones del Programa El método utilizado por el SEI para evaluar riesgos, es la realización de preguntas de

riesgos para medir los factores de riesgos que están 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 numérico de posibles respuestas. Los rangos de respuesta pueden utilizar un valor numérico de 0 a través de 1. Por ejemplo, un rango de respuesta podría definirse como ninguno = 0, pequeño = 0.2, algunos = 0.5, la mayoría = 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 parámetros son: P(A) es la probabilidad del evento A. La probabilidad del evento A varía entre 0 y 1. La probabilidad total del espacio de la muestra es igual a 1, y la probabilidad de ningún 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 método del SEI asume que las probabilidades son asignadas por las experiencias

anteriores o por analogía de eventos pasados. Puesto que este proceso es subjetivo, la probabilidad asignada a un evento específico puede variar en diferentes momentos durante el ciclo de vida del software, y así la probabilidad puede variar también dependiendo de las personas que proponen la asignación.

Los valores numéricos que se utilizan son fijados por las respuestas a las preguntas de riesgo y se utilizan árboles de probabilidad simple para calcular una estadística 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 estadística se expresa matemáticamente de la siguiente manera: P(A) = w1 * P(A1) + w2 * P(A2) + ... + wn * P(An); donde wn es el peso para cada probabilidad. El método utilizado por el SEI es una manera simple y flexible para la estimación de riesgos en el desarrollo de software. Puede ser utilizada fácilmente en organizaciones pequeñas que no pueden emplear procesos más costosos y complejos. Además de

determinar los riesgos de proyectos actuales, el método puede predecir los riesgos para los proyectos futuros utilizando datos de referencia y también permite actualizaciones a lo largo del ciclo de desarrollo. Por otro lado, el número y tipo de preguntas de riesgo pueden

personalizarse para reflejar el tipo y tamaño de un proyecto, así como cualquier otra preocupación del proyecto específico.

Los datos estadísticos recolectados por el SEI, los cuales pueden ser consultados en el SERR (The Software Engineering Risk Repository) son expuestos a continuación:

Clase Ingeniería del Producto Elementos Principales de la Clase

Atributos de Cada Elemento Estabilidad = 36% Integridad = 21% Viabilidad = 14%

Requisitos = 53%

Validez = 10% Precedente = 8% Escala = 7% Claridad = 4% Desarrollo = 28% Funcionalidad = 22%

Diseño = 27%

Rendimiento = 19% Restricciones del Hardware = 15% Dificultad = 9% Interfaz = 7% Ambiente = 72%

Integración y Prueba = 14%

Integración del producto = 21% Integración del sistema = 7% Viabilidad = 33%

Codificación = 4%

Comprobación = 33%

Codificación/Implementación = 33% Especificaciones = 58% Especialidades de la ingeniería = 2%

Garantía = 25%

Mantención = 9% Seguridad = 8%

Tabla 2.11: Valoración del riesgo en la clase producto de ingeniería.

Clase Ambiente de Desarrollo Elementos Principales de la Clase

Atributos de Cada Elemento Planificación = 54%

Proceso de Administración = 37%

Organización del Proyecto = 24% Interfaz del Programa = 20% Experiencia en Administración = 2% Formalidad = 48% Control del Producto = 28%

Proceso de Desarrollo = 17%

Aplicabilidad = 13% Familiaridad = 7% Control del Proceso = 4% Administración del Personal = 45%

Métodos de Administración = 17%

Configuración de la Administración = 33% Monitoreo = 15% Control de Calidad = 7% Capacidad = 35% Aplicabilidad = 23%

Sistema de Desarrollo = 17%

Funcionalidad = 17% Familiaridad = 10% Fiabilidad = 10% Soporte del Sistema = 5% Comunicación = 74%

Ambiente de Trabajo = 12%

Actitud de Calidad = 24% Cooperación = 1% Moral = 1%

Tabla 2.12: Valoración del riesgo en la clase ambiente de desarrollo.

Clase Restricciones del Programa Elementos Principales de la Clase

Atributos de Cada Elemento Personal = 50%

Recursos = 43%

Planificación = 21% Facilidades = 18% Presupuestos = 11% Administración = 25% Retrasos = 21%

Cliente = 39%

Interfaz de Usuario = 19% Cliente Abastecedor de Recursos = 12% Ámbito/Organización = 12%

Conocimiento Técnico = 10% Subcontratantes = 25% Administración Corporativa = 25% Interfaces del Programa = 11%

Vendedores = 22,5% Primer Contratista = 15% Políticas = 12,5% Dependencia = 54%

Contrato = 7%

Tipo de Contrato = 36% Restricciones = 10%

Tabla 2.13: Valoración del riesgo en la clase restricciones del programa.

La valoración probabilística 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, específicamente a conclusiones del tipo siguiente: La muestra global de los riesgos dentro de las tres clases, Ingeniería 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 análisis de riesgo para lograr buenos resultados. La valoración para el Proceso de Administración (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 organización es sumamente importante al momento de planificar, seleccionar personal y delegar responsabilidades. Un dato sorprendente es la baja valoración para el elemento codificación (2%), al parecer las personas encargadas de esta actividad realizan su labor sin muchos inconvenientes. Los responsables de generar código generalmente se ubican en un nivel más bien inferior dentro de una organización, hecho que se contrapone con el anterior.

La alta ponderación para el elemento requisitos (53%) y cliente (39%) sólo confirman la existencia de una estrecha relación 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?, sería una pregunta lógica a esta

altura. La respuesta seria conocer y adoptar una guía que nos indicara como afrontar sistemáticamente y disciplinadamente la influencia de los riesgos. Esta guía es reconocida con el nombre de Administración de Riesgos, tema a tratar a continuación.

LA ADMINISTRACIÓN DE RIESGOS EN EL DESARROLLO DE SOFTWARE 3.1) Justificación de la Administración de Riesgos “Si no atacamos activamente a los riesgos, ellos nos atacarán 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 través de un enfoque de administración 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 opinión 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 técnicos y no técnicos 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 métodos sistemáticos y herramientas para complementar estas habilidades humanas.

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

3.2) Definición de Administración de Riesgos La revista Information & Management de 1994, proporciona la siguiente definición de administración de riesgo:

“La administración 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 límites establecidos”. Por su parte Jim McCarthy[MCC2000] nos entrega lo siguiente como definición de administración de riesgos:

“La administración de riesgos desarrolla una disciplina y un ambiente de decisiones y acciones proactivas para valorar ininterrumpidamente lo que puede fallar, determinar cuáles riesgos son importantes de enfrentar e implementar estrategias para abordarlos”. Como se ve la administración 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 administración 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 Administración 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 organización reaccionan a las consecuencias de los riesgos conforme a su ocurrencia. La estrategia de riesgo proactiva significa que la organización cuenta con un proceso visible para manejar los riesgos. Este proceso se puede medir y repetir. La prevención del riesgo es el punto de transición entre las estrategias reactivas y proactivas. La prevención ocurre en las etapas de planeación de un proyecto, cuando el

equipo puede aplicar acciones para impedir que ocurran los riesgos. Esencialmente, la prevención es todavía una estrategia reactiva para manejar riesgos; no es un remedio para la causa del riesgo, sólo una forma de evitar sus síntomas.

Para alcanzar los niveles más 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 continuación, aplicar acciones que aborden las causas de estos riesgos, no sólo sus síntomas.

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

3.4) Dificultades que Enfrenta la Administración de Riesgos Microsoft Corporation en su publicación “Estrategia y Planeación: Administración de Riesgos” [EST2000], identifica cuatro puntos principales que dificultan la administración de riesgos en el desarrollo de software: Aceptación y Reconocimiento de los Riesgos. La aceptación 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. Percepción Errónea de la Administración de Riesgos. Muchos profesionales del desarrollo de software poseen un concepto erróneo de la administración 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 administración se considere como parte de un proceso dinámico y competitivo, en lugar de sólo una actividad adicional y estática de la administración de un proyecto.

3. Comunicación 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 fácil informar de

los riesgos hacia abajo en la cadena de mando, pero es difícil 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 están a un nivel más 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 información de riesgos que deciden compartir para que no resulte demasiado negativa en relación con las expectativas de los demás integrantes.

Administración de riesgos Enfrenta

Dificultades como:

Aceptar y reconocer riesgos

Ausencia de condiciones para informar riesgos

Comunicar riesgos Percepción errónea de la administración de riesgos

Figura 3.2: Dificultades en la administración de riesgos según Microsoft Corporation [EST2000].