Proceso de Gestión de riesgos para proyectos de desarrollo de software de Softel.

114  Descargar (0)

Texto completo

(1)

Título:

Proceso de Gestión de riesgos para

proyectos de desarrollo de software de Softel.

Tesis para optar por el Título Académico de Master en Gestión de Proyectos Informáticos

Autor: Ana Silvia Valladares Arenas Tutor: DrC. Rolando Alfredo Hernández León

Ciudad de la Habana 29 de Junio de 2010

(2)

“Si conoces al enemigo y te conoces a ti mismo, no tendrás que temer el resultado de cien batallas”

Sun Tzu, general chino que vivió hace 2.500 años

Para el Jefe de proyectos de software, el enemigo es el riesgo.

Roger S. Pressman

“Identificando y tratando con los riesgos desde el inicio del desarrollo disminuye los costos en términos de tiempo y ayuda a prevenir los desastres del software.”

Boehm

(3)

Agradecimientos.

A mi familia por el apoyo permanente que le dan a mi desarrollo profesional, fundamentalmente a mi esposo e hijos. A mi mamá por toda la ayuda brindada sobre todo en los momentos en que más necesitaba concentrarme en mi investigación. A Elena por ayudarme también en muchos momentos.

Agradezco a todos mis compañeros de trabajo, los cuales asumen con entusiasmo y dedicación los retos que nos hemos puesto para lograr la mejora continua de los procesos de gestión que lleva a cabo Softel.

Al Profesor Rolando por haber sembrado en mi un nuevo afán por el mundo de la investigación científica.

A todos los que me rodean y contribuyen a luchar por ser mejor cada día.

(4)

Resumen.

En el presente trabajo, a partir de identificar que el proceso que se realiza actualmente en Softel para la gestión de los riesgos en los proyectos de software que se ejecutan no se corresponde con las necesidades reales de la empresa, se traza como objetivo definir dicho proceso. Para ello se hace un estudio del proceso de gestión de riesgos para la ejecución de proyectos de desarrollo de software en diferentes entidades de Ciudad Habana para detectar las principales dificultades que se están enfrentando, su incidencia en la gestión de proyectos y obtener la información suficiente que permita definir una proceso que se ajuste más a las necesidades reales de Softel. Se sigue el procedimiento establecido en la bibliografía consultada para elaborar el cuestionario que se utiliza y seleccionar una muestra representativa de los especialistas vinculados a la gestión de riesgos en proyectos de software y, a partir de la información obtenida, se define un proceso para realizar la gestión de riesgos con mayores posibilidades de éxito. El proceso definido se aplica actualmente en la empresa Softel, donde se ha podido evaluar utilizando un método de experto. Después de terminada la investigación y evaluado el proceso de gestión de riesgos se ha llegado a la conclusión que en la actualidad no existe ningún proceso para gestión de riesgos en proyectos de software que se ajuste a las necesidades de Softel. De las entidades estudiadas, sólo la UCI tiene establecido un proceso para la gestión de riesgos y el resultado obtenido confirma que el proceso definido se corresponde con las necesidades de Softel, por lo que se propone continuar con su aplicación en esta empresa y proponer su generalización al resto de las entidades que tengan condiciones semejantes.

Palabras claves: Riesgos, Gestión de Riesgos, Plan de Mitigación, Plan de Contingencia, Análisis de riesgos, Evaluación de probabilidad e impacto.

(5)

ÍNDICE.

Introducción. ... 7

Capítulo I. Fundamentos teóricos de la gestión de riesgos... 14

Introducción... 14

1.1 Riesgo... 14

1.2 Gestión de Riesgos. ... 15

1.3 Estrategias de riesgo reactivas y proactivas... 17

1.4 Algunos antecedentes sobre los riesgos del software y su gestión... 17

1.5 Los riesgos en el contexto empresarial... 20

1.6 Necesidad de gestionar los riesgos. ... 23

1.7 Marcos para la gestión de riesgos. ... 24

1.7.1 Generaciones. ... 24

1.7.2 McFarlan. ... 25

1.7.3 Boehm... 26

1.7.4 Gestión de riesgos de proyectos de PMI. ... 26

1.7.5 Programa de gestión de riesgos del SEI... 27

1.7.6 Modelo de Hall... 28

1.7.7 Modelo SERIM de Karolak (IEEE). ... 29

1.7.8 Modelo de Barki... 29

1.7.9 Pressman. ... 29

1.7.10 IEEE Computer Society. ... 30

1.7.11 Richard Fairley (IEEE). ... 31

1.7.12 Microsoft Solutions Frameworks (MSF). ... 31

1.7.13 MAGERIT. ... 31

1.7.14 Dirección Nacional de Aduanas de Chile. ... 32

1.7.15 Modelo Gestión Riesgos en Proyectos de Desarrollo de Software (MoGeRi). ... 33

1.7.16 La Evaluación de Riesgos del Sistema de Control Interno... 34

1.7.17 Modelos de Calidad... 35

1.8 Algunas herramientas y técnicas. ... 37

1.8.1 Para la identificación de riesgos. ... 37

1.8.2 Para el control de las organizaciones: Matriz de Control Interno... 39

1.9 Experiencia de la Universitat Politècnica de Catalunya (UPC). Proyecto PRISMA. ... 39

1.10 Estudios sobre la gestión de riesgos en Cuba... 40

(6)

Conclusiones parciales... 41

Capítulo II. Diagnóstico del estado actual... 42

Introducción... 42

2.1 Métodos Científicos de Investigación. ... 42

2.2 Estado actual de la gestión de riesgos en entidades cubanas... 45

2.2.1 Encuestas... 45

2.3 Estado actual de la gestión de riesgos en los proyectos de desarrollo de software de Softel... 49

2.3.1 Caracterización de la Factoría de Software de Softel. ... 51

2.3.2 Entrevistas... 53

Conclusiones parciales... 59

Capítulo III. Definición del Proceso para la gestión de riesgos y evaluación del proceso. ... 61

Introducción... 61

3.1 Proceso de gestión de riesgos para los proyectos de desarrollo de software de Softel. .. 61

3.1.1. Elementos tenidos en cuenta para la obtención del proceso. ... 61

3.1.2. Proceso de Gestión de Riesgos. ... 66

3.2 Preparación para la introducción del proceso propuesto. ... 79

3.3 Análisis de los resultados de la evaluación del proceso de gestión de riesgos definido... 81

3.4 Otros resultados alcanzados. ... 85

Conclusiones parciales... 86

Conclusiones. ... 87

Recomendaciones. ... 88

Referencia Bibliográfica. ... 89

Glosario de Términos y Acrónimos... 94

Anexos... 99

Anexo 1. Encuesta sobre gestión de riesgos... 99

Anexo 2. Componentes claves de la Entrevista Apreciativa. ... 101

Anexo 3. Entrevista Apreciativa... 102

Anexo 4. Plantilla del Plan de Gestión de Riesgos (DG-32.01). ... 104

Anexo 5. Plantilla del Registro de Riesgos (DG-32.02). ... 109

Anexo 6. Cuestionario para asignación de peso a los criterios... 113

Anexo 7. Cuestionario para la evaluación cuantitativa y cualitativa del proceso definido... 114

(7)

Introducción.

La gran mayoría de las empresas pequeñas son muy optimistas al planear sus proyectos. En estas empresas es común suponer que las actividades se realizarán conforme al plan y sin imprevistos. Las empresas pequeñas que intentan llevar a cabo actividades de gestión de riesgos, identifican sólo algunos riesgos altamente visibles al principio del proyecto. Es poco frecuente que estas empresas monitoreen los riesgos identificados o busquen encontrar nuevos riesgos durante la ejecución o finalización del proyecto. El proceso de gestión de riesgos es un proceso iterativo y como tal debe seguirse para lograr los resultados esperados, refinando dichos resultados en cada iteración (Pérez, 2007). A pesar de ser un proceso que se puede explicar relativamente fácil a los ingenieros y profesionales del software, con sólo estudiar la teoría descrita en la literatura, existen grandes imperfecciones en su gestión y los ingenieros de software sienten temor a este vocablo y a la ardua tarea de gestión permanente que el mismo conlleva, donde la constancia y la disciplina son factores decisivos.

Aunque se reconocen avances en el estudio de la gestión de riesgos, es importante destacar que ningún proyecto es exactamente igual a otro y ninguna institución es exactamente igual a otra, así que los resultados, herramientas y experiencias de algunos no pueden convertirse, necesariamente, en recetas para otros. La gestión de riesgos es un proceso inherente a cada proyecto e institución, aunque si se desarrolla en la empresa la capacidad de aprender de otros y adaptar rápidamente a la realidad del proyecto de la empresa, se estará acortando el camino para alcanzar el éxito.

En Cuba existen características propias que generan riesgos a los proyectos, aunque algunas de ellas pueden estar presentes en muchos países de América Latina y en otros subdesarrollados. Cuba ha tenido que hacer ingentes esfuerzos para lograr los escasos, aunque en ascenso, niveles de informatización del país, debido a los pocos recursos materiales y tecnológicos que posee y lo difícil que se hace, muchas veces, el acceso a las tecnologías de la información y las comunicaciones, vitales para desarrollar la industria del software y preparar a las instituciones estatales para recibir la informatización. Se lucha constantemente por evitar la dependencia tecnológica que genera la transferencia de tecnología proveniente del exterior, de la cual Cuba es consumidora por necesidad. El bloqueo económico es un factor que impone la necesidad permanente de buscar soluciones propias sostenibles con los recursos con los que cuenta el país. Esta situación trae necesariamente riesgos a los proyectos, los cuales exigen una concepción integral: recursos humanos y materiales para el desarrollo, implantación y

(8)

soporte del software, preparación de las instituciones para recibir la informatización, establecimiento de las comunicaciones necesarias para la transferencia bidireccional de información entre las instituciones y sus niveles de dirección a nivel de municipio, provincia y país.

En el año 2003 el Ministerio de Salud Pública (MINSAP), como organismo rector del Sistema Nacional de Salud (SNS), define como una prioridad su informatización, para esto, en conjunto con la alta dirección del país, ha trazado políticas y estrategias para lograr incorporar de forma ambiciosa las Tecnologías de la Informática y las Comunicaciones (TIC) en la salud cubana, todo esto persiguiendo un único objetivo, la búsqueda de nuevas formas que brinden una atención con mejor calidad al pueblo, incrementando la eficiencia y calidad en los servicios. El proceso de informatización es dirigido por el MINSAP y el Ministerio de la Informática y las Comunicaciones (MIC), jugando un papel fundamental la empresa Softel.

Entre los objetivos del MIC se encuentra la producción de soluciones informáticas para lograr la informatización de la sociedad, garantizando la invulnerabilidad y la independencia tecnológica.

Softel es una empresa del MIC a la cual le ha correspondido el cumplimiento de dicho objetivo en el campo de la salud, para lo cual se ha propuesto, entre otros, implementar un sistema de excelencia para el desarrollo y mantenimiento de productos de software especializados de salud (Softel, 2009), a partir de las prioridades establecidas por el MINSAP. Para el logro de este objetivo tiene, en su estructura, a la Dirección de Desarrollo de Software, siendo la Factoría de Software uno de los Grupos de Trabajo diseñados para ello (Softel, 2009).

Softel, además, trabaja en la elaboración del Expediente de Perfeccionamiento Empresarial y en la implantación, cada vez más profunda, de la Resolución 297/03 del Ministerio de Finanzas y Precios (MFP). Como parte de este proceso, trabaja en la definición y perfeccionamiento de los procedimientos de trabajo y procesos de cada una de sus Direcciones y aspira a la Certificación ISO 9000 de sus áreas. Además de ello, ha estudiado el modelo de calidad CMMI, como un patrón, ya que el mismo constituye un marco de referencia de la capacidad de las organizaciones de desarrollo de software en el desempeño de sus diferentes procesos, proporcionando una base para la evaluación de la madurez de las mismas y una guía para implementar una estrategia para su mejora continua.

Softel, con el objetivo de hacer eficiente y mejorar la calidad de sus productos y la prestación de servicios realizó, en el año 2008, un diagnóstico a diferentes procesos y áreas de la empresa.

Ello incluyó la Factoría de Software. Como resultado, se obtuvo el mapa de algunos de los

(9)

principales procesos de las áreas de la empresa, se realizó la descripción y la determinación de algunos de los problemas que afectan dichos procesos y las áreas donde los mismos intervienen (Martínez C.D, 2008). Los mismos se han tomado como base para lograr la mejora de algunos procesos y sobre ellos se han basado algunas de las Tesis de Maestría presentadas por Especialistas de la empresa en el año 2009. Es importante destacar que algunos de los problemas identificados en este estudio todavía se mantienen debido a la carencia de un proceso de gestión de riesgos. Otros han sido resueltos parcial o totalmente por acciones concretas que se han venido realizando pero sin un proceso formal y ordenado de gestión de riesgos.

En el curso escolar 2006-2007, se realizaron en la Universidad de las Ciencias Informáticas (UCI) cinco Trabajos de Diploma relacionados con el tema de la gestión de riesgos. Dos de ellos contaron con tutores de Softel, debido a la importancia que la empresa está dando a este proceso. En particular, el trabajo de Figueredo define la propuesta de la metodología PMI (Project Management Institute) para el desarrollo del proceso de gestión de riesgos para el proyecto Atención Primaria de Salud (APS) (Figueredo, 2007). También se realizaron otras tesis donde fueron entrevistados especialistas de la empresa debido a la experiencia acumulada en la gestión y desarrollo de proyectos de software. Zulueta, en su Tesis de Maestría, hace una valoración acerca de los cinco Trabajos de Diploma mencionados. Plantea que aunque se han dado algunos pasos en el estudio y aplicación de la gestión de riesgos al calor del desarrollo de los Trabajos de Diplomas mencionados, en las entrevistas y encuestas realizadas durante la investigación a los involucrados con Proyectos de Software (gestores, ingenieros de software, clientes, estudiantes, profesores), se reconoce la carencia de conocimientos sobre los marcos para la gestión de riesgos y por tanto de su aplicación. De cierta forma, se conocen informalmente los riesgos que podrían afectar el trabajo, pero estos no son registrados y mucho menos se procede a su análisis o gestión. No obstante, debe reconocerse que la asignación de los temas de riesgos para los trabajos de diploma ha constituido un factor impulsor de los estudios y aplicación de la gestión de riesgos en la Universidad de las Ciencias Informáticas (UCI) (Zulueta, 2007a).

Del Castillo (2009) y Bernaza (2009), ambas de Softel, en sus Tesis de Maestría incluyen la gestión de riesgos de dos proyectos que constituyen soluciones informáticas destinadas a la informatización de los Bancos de Sangre y Policlínicos del país. Las mismas dan la medida de la toma de conciencia que va teniendo este tema en los proyectos que se llevan a cabo en la empresa (Bernaza, 2009; del Castillo, 2009). Además, tres de las cinco Tesis de Maestría de

(10)

Softel del 2009, siguieron las prácticas de PMBoK (Project Management Body of Knowledge).

Del Castillo (2009) siguió las buenas prácticas de PMBoK para los procesos de Gestión de la Integración enmarcados dentro de cada uno de los Grupos de Procesos de la Dirección de Proyectos y de las Fases del Ciclo de Vida propuesto para el mismo (Concepción, Elaboración, Ejecución, y Cierre), lo cual permitió definir la Solución propuesta a partir de los resultados obtenidos del diagnóstico de la situación actual de los Bancos de Sangre para la evaluación de las necesidades del proyecto e implantar la misma (del Castillo, 2009). Bernaza (2009), para el proceso de Gestión de la Integración de la Solución Informática para los Policlínicos, que es un área de conocimiento de PMBoK para la dirección del proyecto, adaptó la implementación de sus siete procesos, enmarcados dentro de cada una de las fases del ciclo de vida de ese proyecto, lográndose su culminación exitosa (Bernaza, 2009). Cabrera (2009) decidió utilizar la propuesta del PMI con la Guía del PMBoK como un modelo formal, consistente y ajustable, que da la posibilidad de trabajar con equipos grandes y geográficamente dispersos, que requieren de una comunicación formal; características propias del proyecto de investigación, profundizando en la Gestión de la Integración del Proyecto, para cumplir los objetivos y lograr proyectos disciplinados y exitosos (Cabrera, 2009).

Cué (2009) en su Tesis de Maestría realiza una investigación sobre el proceso de mejora, llegándose a definir un modelo para organizar la mejora continua en la empresa, en el cual se integran estándares y normas internacionales de la familia ISO y el modelo CMMI, así como los métodos IDEAL y Seis Sigma. En la plantilla propuesta para el Plan de Mejora se incluyen los Riesgos del proyecto con el objetivo de identificar los riesgos que pudieran impedir la ejecución del proyecto de mejora, establecer cómo mitigarlos o un plan de contingencia (Cué, 2009). Esto resalta la importancia de tener definido en la empresa un proceso de gestión de riesgos que se adecue a las características propias de la empresa y que puede seguir su evolución aplicando este modelo de mejora propuesto.

A pesar de que la empresa Softel ha comenzado a dar pasos en la mejora de la gestión de los riesgos este tema no se ha colocado conscientemente como parte de la gestión de los proyectos de desarrollo de software, aunque de forma empírica se han mitigado y hasta eliminado muchos de ellos. Una de las causas fundamentales es la falta de preparación de los especialistas en este tema, que no es muy difícil de lograr desde el punto de vista teórico, pero su desconocimiento hace que no se manifieste conscientemente en la práctica. La falta de definición de un proceso de gestión de riesgos en la empresa o la aplicación de alguno existente ha impedido que se hayan realizado las actividades de identificación, análisis,

(11)

planificación de respuestas y seguimiento y control de los riesgos a los proyectos. A lo sumo se han identificado algunos riesgos que han sido resueltos, mitigados o que se mantienen iguales o peores por la falta de planes que contribuyan a su control.

Actualmente Softel, en su Factoría de Software, cuenta con un numeroso grupo de productos que se encuentran en fase de mantenimiento. Una parte de ellos son sistemas heredados, los cuales llevan años funcionando establemente en hospitales, bancos de sangre y policlínicos cubanos con un negocio sólido, ya que durante el tiempo que llevan en explotación han seguido evolucionando a partir de la interacción directa y permanente con los clientes. La otra parte fueron desarrollados utilizando arquitectura SOA (arquitectura orientada a servicios) y basados en componentes, usando software libre. Tienen algunos años desde el inicio de su desarrollo y el equipo de proyecto original ya no existe. También las herramientas de desarrollo (libres) empleadas en aquel momento han seguido evolucionando, sin garantizar la compatibilidad total con sus versiones anteriores. Además, de los productos que se encuentran en fase de mantenimiento, existe un gran número de productos que se encuentran en fase de desarrollo;

algunos en su primera versión y otros como nueva versión de los sistemas heredados. En su mayoría, son para arquitectura SOA (orientados a servicios) y basados en componentes, lo cual introduce complejidades importantes a estos nuevos desarrollos. Se emplean, además, herramientas inteligentes para la generación de código como GeneXus y Java como lenguaje de programación para complementar estos desarrollos, además de otros que se encuentran libres en el mercado. Se utilizan también herramientas de software libre para la generación de reportes y sincronización de aplicaciones, entre otras.

Para el desarrollo y mantenimiento de los productos de software y lograr el cumplimiento de las prioridades establecidas por el MINSAP, Softel necesita gestionar adecuadamente sus proyectos con la seriedad y constancia requeridas. Esto incluye la gestión de los equipos de proyecto que intervienen, del cronograma de tareas del proyecto, de la tecnología que se emplea para el desarrollo y mantenimiento de las aplicaciones, del entorno de desarrollo que garantiza el ambiente de integración y despliegue y del dominio del negocio a informatizar, entre otros. En la Factoría de Software, todavía la gestión de proyectos no se realiza con el rigor necesario, debido a que sus equipos de proyecto han sido recientemente reestructurados con personal muy bien preparado técnicamente, pero con poca experiencia profesional, en sistemas integrados, empleo de arquitectura SOA, conocimiento de GeneXus y en el negocio que se está informatizando. Aunque se han ido mejorando los resultados que se esperan, los Jefes de Proyecto tienen que invertir mucho tiempo en el análisis y diseño de sistemas, en la integración

(12)

y pruebas de las aplicaciones y en la formación de los nuevos integrantes. Ello tiene un alto impacto en el incumplimiento de los cronogramas de trabajo. También hay falta de datos históricos, por la poca trazabilidad de las tareas y documentación que se registra, que permita la adopción de métricas necesarias para planificarlas. Además, como los equipos de proyecto están en proceso de consolidación, la productividad todavía no se encuentra en los niveles deseados, aunque se ha elevado en el transcurso del tiempo.

Aunque la Factoría de Software se encuentra en un proceso de maduración y consolidación en ascenso permanente, existen características y necesidades propias que hacen que la empresa necesite definir e implantar un grupo de procesos y herramientas que contribuyan al cumplimiento de su misión. Entre los procesos a definir, la gestión de riesgos, puede contribuir al fortalecimiento de la gestión de proyectos y, como consecuencia, al cumplimiento de los objetivos que se han ido trazando para cada uno de ellos.

Por todo lo anterior, se define el siguiente problema: El proceso que se realiza actualmente en Softel para la gestión de los riesgos en los proyectos de software que se ejecutan no se corresponde con las necesidades reales de la empresa.

Con vistas a la solución del problema planteado, se define el proceso de gestión de proyectos como el objeto de estudio de la investigación.

El objetivo de esta investigación es definir un proceso para la gestión de los riesgos en los proyectos de software que se ejecutan que se corresponda con las necesidades reales de Softel, siendo el campo de acción la gestión de riesgos en los proyectos de Softel.

La hipótesis de la investigación es: si se evalúan las condiciones actuales de la gestión de riesgos en los proyectos que se ejecutan en Softel se podrá definir un proceso para su gestión que se corresponda con las necesidades reales de la empresa.

Para lograr el objetivo y contrastar la hipótesis se propusieron los siguientes Objetivos Específicos:

1. Elaborar el marco teórico de la investigación.

2. Diagnosticar el estado actual de la gestión de riesgos en los proyectos de desarrollo de software de Softel.

3. Definir el proceso de gestión de riesgos para los proyectos de desarrollo de software de Softel.

(13)

4. Evaluar el proceso definido de gestión de riesgos para los proyectos de desarrollo de software de Softel utilizando criterios de expertos.

Con el resultado alcanzado la empresa contará con un proceso que podrá ser aplicado a los proyectos de software que desarrolla para mejorar la gestión de riesgos, lo cual traerá como consecuencia que sean desarrollados proyectos encaminados a resolver las problemáticas concretas del cliente en la situación actual de Cuba, contribuyendo a una mejor informatización del sector de la salud. En el futuro, con la aplicación y mejora continua de este proceso se acumularán experiencias que permitirán seguir mejorando el mismo y contribuirán a mejorar este proceso también en otras empresas e instituciones que desarrollan software, trayendo beneficios a otros sectores, además de la salud.

Estructura y contenido de la tesis.

En el Capítulo I: Fundamentos teóricos de la gestión de riesgos, se establece el fundamento teórico de la investigación a partir de hacer un análisis crítico de la bibliografía existente, lo que permite sustentar teóricamente la investigación.

En el Capítulo II: Diagnóstico del estado actual, se exponen los métodos científicos utilizados en la investigación. Se realiza el diagnóstico del estado actual de la gestión de riesgos en entidades cubanas, fundamentalmente en Softel y de la gestión de riesgos en los proyectos de desarrollo de software de la empresa. Se hace un análisis de los resultados obtenidos en cada caso, empleando la Taxonomía Ajustada (Maniasi, 2005) para agrupar los riesgos en categorías y conocer cuáles son los que más inciden, y se demuestra que no existe un proceso formal ni se realiza adecuadamente la gestión de riesgos en los proyectos de desarrollo de software de la empresa.

En el Capítulo III: Definición del Proceso para la gestión de riesgos y evaluación del proceso propuesto, se define el proceso para la Gestión de Riesgos de los proyectos de desarrollo de software de Softel, para lo cual se determina los elementos tomados de los marcos de gestión de riesgos analizados en el Capítulo I. Además, se exponen las actividades de preparación realizadas en la empresa para elevar la cultura sobre riesgos y su gestión y preparar a la organización en el proceso definido. Se realiza la evaluación teórica del mismo utilizando criterios de expertos con el objetivo de determinar si el proceso garantiza una adecuada gestión de los proyectos de software de Softel, entre otras contribuciones. Al final del capítulo se resumen algunos resultados que se han obtenido en los proyectos de la Factoría de Software de Softel.

(14)

Capítulo I. Fundamentos teóricos de la gestión de riesgos.

Introducción.

En este capítulo se establece el fundamento teórico de la investigación a partir de hacer un análisis crítico de la bibliografía existente, lo que permite sustentar teóricamente la investigación. Se formalizan los conceptos de riesgo y su gestión ofrecidos por varios autores, se narran algunos de sus antecedentes, se analizan los riesgos en el contexto empresarial y la importancia de gestionar los mismos. Se evalúan, además, diferentes marcos para la gestión de riesgos, así como herramientas, técnicas, experiencias alcanzadas y estudios sobre la gestión de riesgos en Cuba.

1.1 Riesgo.

Robert Charette (1989) expone la siguiente definición de riesgo: “En primer lugar, el riesgo concierne a lo que ocurra en el futuro. El hoy y el ayer no nos conciernen realmente, porque ahora ya estamos recogiendo los frutos de lo que sembramos en el pasado. La cuestión es si podemos, entonces, modificando nuestras acciones en este momento, crear una oportunidad para una situación diferente y más esperanzadora de nuestro mañana. Esto significa, en segundo lugar, que el riesgo implica un cambio, que puede venir dado por cambio de opiniones, acciones o lugares. En tercer lugar, el riesgo implica una elección, y la falta de certeza de que la elección sea correcta. Así, paradójicamente, el riesgo como la muerte o los impuestos, es una de las pocas cosas inevitables de la vida” (Charette, 1989).

El SEI (Software Engineering Institute) expresa la definición de riesgo como la posibilidad de sufrir una pérdida, como una medida de la posibilidad de que una amenaza conlleve a una pérdida con un impacto asociado (Audrey, 2009).

MSF (Microsoft Solution Frameworks) plantea que suele ser común el confundir preocupaciones, riesgos y problemas: una preocupación es cualquier situación sobre la cual existen dudas al respecto en algún determinado contexto y que, por lo tanto, será evaluada como un posible riesgo, un problema es un riesgo que, efectivamente, se ha producido (Figura 1.1) (Microsoft, 2002).

Figura 1.1. Preocupaciones, Riesgos y Problemas.

Preocupación Riesgo Problema

(15)

Según Rosenberg (1999), un riesgo se describe mediante una expresión en lenguaje natural que expresa la relación entre una situación real de proyecto y otra situación no realizada. La primera parte de la definición se denomina condición y representa una situación existente en el proyecto que el equipo prevé que puede resultar en una pérdida o en una reducción de beneficios; mientras que la segunda parte de la declaración se denomina consecuencia y describe la situación no deseable para el proyecto que puede derivarse de la ocurrencia de la condición. Las dos oraciones deben unirse a través de algún indicador de relación que de idea de incertidumbre y que, a su vez, implique una relación de tipo causal, tales como “por lo tanto”

o “como consecuencia” (Figura 1.2) (Rosenberg, 1999).

Figura 1.2. Descripción de Riesgos.

Una frase para describir un riesgo debe ser lo suficientemente completa y directa como para posibilitar el análisis de su causa raíz, discutir su impacto y desarrollar un conjunto de respuestas o acciones para prevenirlo o reducir sus consecuencias. En las frases empleadas se debe evitar el uso de abreviaciones o acrónimos que resulten difíciles de comprender y las generalizaciones y detalles irrelevantes. En algunos casos, puede ser útil agregar información de contexto a un riesgo para facilitar su entendimiento a personas que puedan no conocer todos los detalles del proyecto (ya sea en la actualidad como en el futuro) (Rosenberg, 1999).

1.2 Gestión de Riesgos.

Un efectivo proceso de gestión de riesgos es un importante componente en todo proyecto de desarrollo de software exitoso. La gestión de riesgos permite definir en forma estructurada, operacional y organizacional, una serie de actividades para gestionar los riesgos de los proyectos a lo largo de todas las fases de su ciclo de vida de desarrollo de software. Esto se traduce en la creación de planes tendientes a impedir que los riesgos se transformen en problemas o a minimizar su probabilidad de ocurrencia o impacto (Maniasi, 2005).

Para MSF (Microsoft Solution Frameworks), la gestión de riesgos es el proceso para identificar, analizar y dirigir los riesgos del proyecto proactivamente. El objetivo de la gestión de riesgos es maximizar los impactos positivos (oportunidades) mientras se minimizan los impactos negativos

Descripción del Riesgo Causa

Raíz

Pérdida Total

Condición Conse-

cuencia

(16)

(pérdidas) asociados con los riesgos del proyecto. Microsoft expone los principios básicos sobre los cuales se debería basar un proceso de gestión de riesgos, incluyendo la necesidad de potenciar la comunicación, aprender de todas las experiencias, ser proactivos y valorar continuamente los riesgos, entre otros (Microsoft, 2002).

Aún cuando la gestión de riesgos es fundamental para proyectos de cualquier tipo, para los proyectos de desarrollo de software, la gestión de riesgos constituye una actividad fundamental debido a que dichos emprendimientos se ven caracterizados por aspectos particulares que incrementan la presión sobre el proyecto a medida que dificultan la toma de decisiones, entre ellos: constantes presiones internas y externas; cambios normativos y evolución de las técnicas que pueden derivar en una alteración de los planes y de las estrategias; continuos y comunes cambios en los requerimientos de los usuarios; nuevas herramientas y tecnologías existentes en el mercado; periódicas amenazas de seguridad; variabilidad de los equipos de proyecto (Maniasi, 2005).

El SEI define la gestión de riesgos como el proceso formal en el que los factores de riesgos son sistemáticamente identificados, evaluados y mitigados; se inicia en la primera etapa de un proyecto de software (durante la exploración de conceptos) y se desarrolla a lo largo de todo su ciclo de vida (hasta la aceptación del producto del proyecto) (Higuera, 1996).

Rosenberg plantea que la gestión de riesgos es importante debido a que ayuda a evitar desastres, re-trabajo y sobre-trabajo, pero aún más importante, porque estimula la generación de situaciones del tipo ganar-ganar. Una correcta gestión de riesgos posibilita el aprovechamiento óptimo de recursos, el aumento de ganancias y la disminución de pérdidas. La ausencia de una apropiada gestión de riesgos conlleva a la imposibilidad de lograr el control efectivo de un proyecto, afectando su adecuada gestión. Por ello, la gestión de riesgos debe ser enfatizada y considerada como una actividad clave en todo tipo de proyectos y, particularmente, en proyectos de desarrollo de software (Rosenberg, 1999).

La Dirección Nacional de Aduanas de Chile, de forma muy similar a otras organizaciones e instituciones, ha definido su proceso de gestión de riesgos como el proceso de toma de decisiones en un ambiente de incertidumbre sobre un acción que va a suceder y sobre las consecuencias que existirán si esta acción ocurre (Dirección Nacional de Aduanas, 2007).

La Gestión de Riesgos es la práctica compuesta de procesos, métodos y herramientas que posibilita la gestión de los riesgos en un proyecto y que provee de un entorno disciplinado para

(17)

la toma de decisiones preactiva en base a determinar constantemente qué puede ir mal, identificar los riesgos más importantes en los cuales enfocarse e implementar estrategias para gestionarlos; se inicia en la primera etapa de un proyecto y se desarrolla a lo largo de su ciclo de vida. La Identificación de Riesgos en proyectos de software consiste en la determinación de elementos de riesgos potenciales mediante la utilización de algún método consistente y estructurado (Maniasi, 2005).

La Gestión de Riesgos en base a Taxonomías implica el utilizar una estructura agrupadora de los mismos de acuerdo a sus diferentes clases como una lista de consulta durante la actividad de Identificación de los Riesgos (Maniasi, 2005).

1.3 Estrategias de riesgo reactivas y proactivas.

Según Pressman (2005), en el mejor de los casos, la estrategia reactiva supervisa el proyecto en previsión de posibles riesgos. Los recursos se ponen aparte, en caso de que pudieran convertirse en problemas reales. Lo más frecuente es que el equipo de software no haga nada respecto a los riesgos hasta que algo va mal. Después el equipo vuela para corregir el problema rápidamente. Este es el método denominado a menudo "de bomberos". Cuando falla, "la gestión de crisis" entra en acción y el proyecto se encuentra en peligro real. Es por ello que una estrategia considerablemente más inteligente para el control del riesgo es ser proactivo.

Empieza mucho antes de que comiencen los trabajos técnicos. Se identifican los riesgos potenciales, se valoran su probabilidad e impacto y se establece una prioridad según su importancia. Después el equipo de software establece un plan para controlar el riesgo. El primer objetivo es evitar el riesgo, poco común es que se pueden evitar todos los riesgos. El equipo trabaja para desarrollar un plan de contingencia que le permita responder de una manera eficaz y controlada (Pressman, 2005; Universidad de Murcia, 2006).

1.4 Algunos antecedentes sobre los riesgos del software y su gestión.

Boehm (1991) plantea que como en muchos campos en sus etapas tempranas, el campo del software ha tenido su porción de desastres en proyectos. La frecuencia de los desastres del software es una preocupación seria: un estudio de seiscientas empresas indicó que 35% de ellas tenían, al menos, un proyecto de software clandestino. Muchos de los desastres de los proyectos de software después de muertos, han indicado que sus problemas se habrían evitado o reducido fuertemente, si hubiese existido una temprana preocupación explícita relacionada con la identificación y solución de sus elementos de alto riesgo. Frecuentemente, estos proyectos fueron barridos a lo largo de la marea de entusiasmo optimista durante sus fases

(18)

tempranas por omitir problemas de alto riesgo que demostraron ser después su fracaso (Boehm, 1991).

Un modelo que surgió muy fuertemente fue que los gestores de proyecto exitosos eran buenos gestores de riesgo. Aunque generalmente no se usaron los términos de “identificación de riesgo”, “evaluación de riesgo”, “plan para gestionar el riesgo” o “monitoreo del riesgo”, se utilizó un concepto general de exposición al riesgo (pérdida potencial por la probabilidad de pérdida) para guiar sus prioridades y acciones. Esto provocó que los proyectos tendieran a evitar trampas y produjeran buenos productos (Boehm, 1991).

En la tesis desarrollada por Matsuo (1999), sobre la evaluación de riesgos en el desarrollo de software incremental, plantea que con el crecimiento de la tecnología en proporciones exponenciales y la explosión de aplicaciones de software con funcionalidades complejas, el proceso de desarrollo de software se ha vuelto sumamente complicado y difícil de manejar. En 1994, un estudio de más de ochocientos treinta proyectos comerciales de software intensivo encontró la mayor cantidad de proyectos por encima del presupuesto, detrás de la planificación, o que tenían pocas características o funciones que las originalmente especificadas. En 1995, por encima de un cuarto de trillón dólares fue gastado en más de siento sesenta y cinco mil proyectos de software a lo largo de los Estados Unidos. Un cuarto de ese dinero fue gastado en los desbordamientos del costo y otro tercio en proyectos cancelados. Estos resultados se pueden haber atribuido a la falta de gestión de riesgos. No obstante, la aplicación de la gestión de riesgos a los proyectos de desarrollo de software no actúa como una “bala plateada”, sino que ayuda a resolver y mitigar muchos problemas que los gestores de proyecto encuentran.

Existen directivas que muestran el énfasis en la gestión de riesgos. Por ejemplo, el estándar EIA/IEEE en su sección 5.19.1 define: “El desarrollador debe ejecutar la gestión de riesgos a través de todo el proceso de desarrollo. Los desarrolladores deberán identificar, analizar y priorizar las áreas del proyecto de desarrollo de software en las cuales existen riesgos potenciales (riesgos técnicos, costos o calendario); desarrollando las estrategias para gestionar dichos riesgos, recopilándolos en el plan de desarrollo e implementando las estrategias de acuerdo al plan” (Matsuo, 1999).

Esteves (2005) refiere que aunque los diversos enfoques de gestión del riesgo aparecieron hace más de una década, sigue siendo evidente la poca utilización de sus técnicas en los proyectos de desarrollo de software actuales. La investigación en la gestión de riesgos en el ámbito del software procura formalizar conocimiento orientado a minimizar o evitar riesgos en

(19)

proyectos de desarrollo de software, mediante la generación de principios y buenas prácticas de aplicación realista. Hasta el momento se han propuesto y utilizado diferentes enfoques de gestión del riesgo desde que Boehm (1991) atrajo a la comunidad de ingeniería del software hacia la gestión del riesgo. Sin embargo, es evidente que pocas organizaciones utilizan todavía de una forma explícita y sistemática métodos específicos para gestionar los riesgos en sus proyectos de software. Así, por ejemplo, KLCI (2001) realizó y publicó un estudio con doscientas sesenta y ocho organizaciones de todo el mundo y el resultado fue que: el 3% no utilizaba ningún marco de gestión del riesgo, el 18% utilizaba algún marco caótico para identificar sus riesgos, el 37% de los participantes habían utilizado algún marco informal, el 28%

utilizaban procedimientos repetitivos y sólo un 14% utilizaba un enfoque formal para identificar riesgos. Según este estudio, las razones más comunes para utilizar un marco informal son: falta de procedimientos, necesidades del proyecto no adecuadas, organización inmadura y compromiso del equipo. Según Hoffman (1998), aunque algunas organizaciones usen procesos formales de gestión del riesgo para otras partes de su negocio, demuestran una gestión de riesgos pobre en el ámbito general de los sistemas de información. Kontio y Basili (1997) creen que hay tres razones principales para la baja tasa de divulgación de tecnologías de gestión del riesgo: falta de conocimiento sobre posibles métodos y herramientas, limitaciones prácticas y teóricas de los marcos de gestión de riesgos que entorpecen la facilidad de uso de estos métodos, y tercero, todavía hay pocos informes con evaluaciones sistemáticas o científicas que proporcionen feedback empírico sobre su viabilidad y beneficios (Esteves, 2005).

El riesgo en un proyecto de desarrollo de software incluye componentes técnicos y de conocimiento del riesgo. Diferentes estudios han mostrado que la mayoría de los proyectos fallan sobre todo en gestión, no tecnológicamente. Además, son los temas de naturaleza organizacional los factores de riesgos del proyecto más dominantes a la vez que son los que se tratan satisfactoriamente en menos de la tercera parte de los proyectos de desarrollo. Schmidt, Lyytinen y Keil (2001) han observado que jefes de proyecto exitosos puntúan bajo aquellos factores sobre los que no tienen control o influencia como: conflictos entre departamentos, usuarios, cambio del propietario o responsable ejecutivo del proyecto, volatilidad del personal, número de unidades de la organización implicadas y proyectos que involucran a múltiples proveedores. Otro aspecto que influye es la falta de reconocimiento sobre la importancia de los aspectos organizacionales que existe en gran parte de la comunidad profesional y académica vinculada a las tecnologías de la información y la comunicación (Esteves, 2005).

(20)

Fairley (2006) plantea que algunos proyectos de software fallan en la entrega de sistemas aceptables dentro del horario y presupuesto y que muchos de estos fracasos se podrían haber evitado si el equipo de proyecto hubiese evaluado y mitigado debidamente los factores de riesgo, aún cuando la gestión de riesgos es raramente aplicada como una actividad explícita de gestión de proyectos (Fairley, 2006).

Según Boehm (1991), los diez factores de riesgo que más se presentan en los proyectos de software son: insuficiencias del personal; presupuestos y planificaciones poco realistas;

desarrollo de funciones y propiedades erróneas; desarrollo de una mala interfaz de usuario, incorporación de funciones o características innecesarias; cambios continuos en los requerimientos; insuficiencias en los componentes suministrados externamente; insuficiencias en las tareas ejecutadas externamente; insuficiencias en la ejecución en tiempo real y tensionadas las capacidades de la ciencia de la computación (Boehm, 1991).

Según Barki (1993), los factores de riesgo que intervienen en la evaluación de riesgos en proyectos de desarrollo de software son: Tecnológico, Tamaño de la aplicación, Falta de experiencia, Complejidad de la aplicación y Ambiente organizacional (Zulueta, 2007a).

Matos (2009) en una entrevista realizada en abril del 2009 al gurú del software Capers Jones, plantea que las cuatro razones principales por la que fracasan los proyectos son: las estimaciones tempranas son inexactas y rechazadas por los clientes; el control de calidad no es muy bueno; el control de cambio no es muy bueno; el rastreo del progreso es sumamente malo.

Además plantea que el control de la calidad es la clave del éxito en los proyectos de software.

Ante la pregunta, ¿Considera que los mismos problemas que generan fracasos están mejorando o empeorando?, respondió: “Hasta la recesión del 2008, los proyectos que usaron Agile, TSP, RUP o habían encabezado el nivel 3 en CMM fueron hechos bastante bien. Ahora que la recesión es mundial y el crecimiento desacelerado, habrá tantos fracasos de negocios y despidos que el futuro ya no es previsible. Lo que me preocupa es que las empresas y los proyectos intentarán y escatimarán en el control de calidad, y naturalmente esta acción incrementará la probabilidad de fracasos” (Matos, 2009).

1.5 Los riesgos en el contexto empresarial.

La gestión de riesgos empresariales está siendo reconocida por el mundo como una actividad útil necesaria e independiente sobre la base de que posee una técnica propicia de aplicación, rápidamente identificable con los procesos que tienen que ver con la identificación, reducción y transferencia de riesgos (Iglesias, 2006).

(21)

La gestión de riesgos es parte fundamental de la estrategia y del proceso de toma de decisiones en la empresa y, por tanto, ha de contribuir a la creación de valor en todos los niveles, siendo imprescindible que la alta dirección lidere el proceso (González-Cueto, 2002).

Cuando hablamos de riesgos nos referimos también al contexto empresarial donde muchos de ellos se desarrollan, mantienen y soportan. Los riesgos a los cuales están expuestas las empresas son muchos y los mismos deben imperiosamente ponerse bajo control. El constante avance que en los diversos países hace la burocracia estatal y para-estatal sobre los entes privados, ha llevado a éstos a la búsqueda de herramientas o instrumentos que permitan suprimir y/o disminuir significativamente los riesgos a los cuales se encuentran expuestos. Una empresa está expuesta a errores internos de buena fe y a acciones que, de manera accidental o no, exponen a la misma a pérdidas y hasta ponen en riesgo su continuidad (Lefcovich, 2003).

Muy pocas empresas tienen políticas, planes y metodologías sistemáticamente conformadas para evitar los riesgos. Generalmente accionan por experiencia, intuición o planifican de manera parcializada. Actualmente ninguna empresa seria, que aspire o no a la excelencia, puede continuar operando de tal forma. Una de las gravísimas falencias de las auditorías externas está justamente en no controlar y evaluar apropiadamente los controles internos en su totalidad, como así tampoco evaluar desde un punto de vista sistémico a las empresas auditadas. Se propone como herramienta de control, para las auditorías internas y externas, la Matriz de Control Interno. La misma es una forma de pensar, de planificar, de delegar, de adoptar decisiones y resolver problemas, y de ver la organización en su totalidad (Lefcovich, 2003).

La Treadway Commission’s Committee of Sponsoring Organizations (COSO), emitió en el 2004 una plataforma integrada para la Gestión de Riesgos Empresariales (ERM) después de completar un proyecto de desarrollo que duró tres años, para satisfacer sus necesidades de control interno y moverse hacia un proceso más abarcador de gestión de riesgos (Protiviti, 2007). La plataforma integrada suministra ocho componentes para ser utilizadas cuando se está evaluando la Gestión de Riesgos Empresariales: ambiente interno; definición de objetivos;

identificación de eventos; evaluación del riesgo; respuesta al riesgo; actividades de control;

información y comunicación; monitoreo (COSO, 2004).

En Cuba, el Ministerio de Finanzas y Precios, puso en vigor la Resolución No. 297 del 2003 que comprende la definición de Control Interno, el contenido de los componentes y las normas para su implementación y evaluación. Posee 5 componentes que son: Ambiente de Control, Evaluación de Riesgos, Actividades de Control, Información y Comunicación y Supervisión y

(22)

Monitoreo (del Toro Ríos, 2005). El componente “Evaluación de riesgos” aporta mucho a las organizaciones, ya que las mismas, cualquiera sea su tamaño, se enfrentan a diversos riesgos de origen externos e internos que deben ser evaluados. La evaluación de los riesgos consiste en la identificación y el análisis de los riesgos relevantes para lograr los objetivos, y sirve de base para determinar cómo han de ser gestionados los riesgos. Debido a que las condiciones económicas, industriales, legislativas y operativas continuarán cambiando continuamente, es necesario disponer de mecanismos para identificar y afrontar los riesgos asociados con el cambio. La evaluación del riesgo debe ser un proceso continuo, una actividad básica de la organización, como la evaluación continua de la utilización de los sistemas de información o la mejora continua de los procesos.

Los procesos de evaluación del riesgo deben estar orientados al futuro, permitiendo a la dirección anticipar los nuevos riesgos y adoptar las medidas oportunas para minimizar y/o eliminar el impacto de los mismos en el logro de los resultados esperados. La evaluación del riesgo tiene un carácter preventivo y se debe convertir en parte natural del proceso de planificación de la empresa (Solórzano, 2006).

La resolución 297/03 del MFP no ofrece una metodología o procedimientos para que todas las entidades puedan gestionar efectivamente los riesgos a que están expuestas. En octubre de 2009, la Contraloría General de la República de Cuba publicó una Guía de Autocontrol destinada a las empresas, donde define un grupo de preguntas para que las mismas puedan evaluar el estado actual de su control interno. Se incluyen las preguntas relacionadas con el componente Evaluación de Riesgos (Contraloría General de la República de Cuba, 2009).

Quincosa (2007) plantea que una gestión de riesgos eficiente se traduce en efectos económicos incalculables para cualquier organización, constituyendo una herramienta imprescindible para la toma de decisiones. La gestión de riesgos ha pasado a ocupar un importante papel en la empresa moderna, contribuyendo cada vez más al cumplimiento de los objetivos y metas previstas en la organización hasta el punto que no se concibe una organización que pretenda avanzar con pasos firmes hacia el éxito sin contar con la actividad de gestionar los riesgos bien organizada. Propone una metodología para la gestión de riesgos empresariales, resumida en once operaciones fundamentales a realizar, la cual integra de una manera armónica los requisitos comprendidos en la Resolución 297/03 del Ministerio de Finanzas y Precios, los requisitos de la gestión de la calidad y la secuencia lógica para la aplicación de los sistemas de análisis de peligros y puntos críticos de control (APPCC), estos adaptados a las expectativas

(23)

que demandan los sistemas de control interno. La misma puede ser empleada como una herramienta para gestionar riesgos al nivel de toda la organización (Quincosa, 2006).

1.6 Necesidad de gestionar los riesgos.

La necesidad de gestionar los riesgos se incrementa con la complejidad del sistema: cuando se incrementan los riesgos técnicos y no técnicos (costo y planificación). Existe una necesidad creciente de métodos más sistemáticos y herramientas para complementar el conocimiento individual, el juicio y la experiencia. Muchos gerentes creen que están gestionando el riesgo en sus dimensiones multifacéticos, cuando en realidad están gestionando meramente el costo y la planificación con casos aislados de riesgos técnicos. El Programa de Riesgos del SEI proporciona un proceso estructurado, soportado por métodos y herramientas, para identificar, analizar y mitigar las incertidumbres encontradas. Muchos de los problemas más serios encontrados en la adquisición del sistema son el resultado de riesgos que han permanecido sin ser reconocidos y/o ignorados hasta que han provocado consecuencias serias. Este enfoque en la gestión de riesgo es importante porque estructuró técnicas, que pueden ser efectivas en la identificación del riesgo, procedimientos y técnicas que existen para la mitigación de riesgo (Higuera, 1996).

La experiencia ha mostrado que sólo unos pocos programas están gestionando el riesgo de una manera sistemática, y que el acercamiento de los programas a gestionar el riesgo tiende a ser ad hoc, indocumentado e incompleto. Los equipos del SEI también han encontrado que el riesgo del software está entre el menos medido o gestionado en un sistema (Higuera, 1996).

Según Walsh, a pesar del progreso significativo que han tenido las metodologías de desarrollo de software, continúan existiendo fallos en los proyectos de software. El trabajo realizado hasta el momento en la gestión de riesgos ha encontrado varios factores de riesgo y ha desarrollado métodos para evitar aquellos que causan fallos en los proyectos de software. Sin embargo, el desarrollo de software sigue siendo una tarea arriesgada donde deben tomarse decisiones sin poseer la información completa (Walsh, 2002).

Christopher Alberts y Audrey Dorofee del SEI, en el año 2006, definen algunos elementos que impactan en el análisis de riesgo para organizaciones de alto desempeño. Primeramente describen los cambios que han ocurrido en el ambiente operacional: del control de los procesos de gestión centralizados al control de los procesos de gestión distribuidos; de tecnologías aisladas y dedicadas a tecnologías conectadas en redes e interoperables; de la empresa permanente, definida por una estructura organizacional a empresas virtuales, definidas por una

(24)

misión; de un equipo y una misión a muchos equipos y una misión; de una vista compartimentada de los riesgos (por ejemplo, proyecto, seguridad) a una vista integrada de los riesgos. Debido a ello se hacen necesarias técnicas de riesgo más avanzadas. El ambiente operacional es más complejo (por ejemplo, los procesos distribuidos), apareciendo nuevos tipos de riesgo: riesgos heredados, nuevas fuentes de riesgo, riesgos de efectos combinados, riesgos de consecuencias en cascada, riesgos de amenazas emergentes (Alberts, 2006).

Las empresas se enfrentan con situaciones o sucesos que constituyen oportunidades para obtener beneficios o amenazas para sus éxitos. La gestión eficaz permite aprovechar las oportunidades y evitar las amenazas (O. N. Normalización, Cuba, 2008).

El desafío actual de la economía global, las oportunidades de negocio y los riesgos están en constante cambio. Existe la necesidad de identificar, evaluar y monitorear las oportunidades de negocio y los riesgos de la organización. Por lo tanto, es importante para una organización conocer cómo seguir pasos prácticos para integrar las oportunidades y los riesgos cuando se administran los negocios, así como qué hacer para gestionar los riesgos (Protiviti, 2007).

La adquisición, desarrollo y despliegue de los programas continúan sufriendo costos elevados, retrasos en las planificaciones y pobre ejecución técnica. Generalmente, esto es el resultado de un tratamiento inapropiado de la incertidumbre en la adquisición y desarrollo de sistemas de software intensivos y dependientes complejos. A la adquisición y las comunidades de desarrollo les falta una manera sistemática de identificar, comunicar, y resolver la incertidumbre técnica. A menudo la atención está en los síntomas de sobrepaso del costo y retrasos en la planificación en lugar de la raíz de las causas de la adquisición y desarrollo del producto. Todas las áreas en el desarrollo de los sistemas son fuentes potenciales de riesgos del software debido a que involucra tecnología, hardware, software, personas, costo y planificación (Higuera, 1996).

1.7 Marcos para la gestión de riesgos.

1.7.1 Generaciones.

Marcelo, en su estudio exploratorio sobre los métodos de gestión de proyectos de alto riesgo, muestra una clasificación de la gestión de riesgos para exponer mejor las características y evolución de cada una. Dichas generaciones son las siguientes (Marcelo, 2003):

G1. Casuística: Identificación de riesgos en los sistemas de los setenta y la previa en los negocios, todas basadas en cuestionarios.

(25)

G2. Taxonómica: Análisis de riesgo en los proyectos. Traduce a ese sector el análisis de riesgos en los sistemas, desarrollado en los 80 junto a intentos poco articulados de análisis de riesgo en los negocios. Ejemplos: McFarlan, Boehm, PMI, SEI, Hall, SPR, SERIM.

G3. Causal o Emergente: Es la primera que puede calificarse como gestión de riesgos en proyectos, aprovecha los métodos de gestión de riesgos usados en los sistemas. Referida en particular a proyectos informáticos. Nace de forma simultánea en Europa y en EE.UU., partiendo de la preocupación por proyectos de tanto riesgo como la adquisición o el desarrollo de software. Su enfoque, más completo y sistemático que el de la G2, ha seguido básicamente en Europa dos líneas paralelas, una financiada por la Comisión Europea (RiskMan, DriveSPI, RiskDriver) que parece haberse estancado; y otra impulsada por la propia Comisión para la Gestión de sus Compras (Eurométodo, ISPL (Information Services Procurement Library)), en cuyos desarrollos los autores han participado de forma continuada. Pone un énfasis particular en la evaluación de los modelos de riesgos y en la estimación de los recursos. Estos métodos de la G3, nacidos a mediados de los años noventa y actualmente aún en plena discusión, se apoyan en modelos sistémicos, relacionales (redes de causas-efectos) y proactivos en el aseguramiento de los proyectos (es decir, con resultados más predecibles). Tienden a superar así los modelos G1 de la primera generación, limitados a modelos casuísticos (listas de incidencias y de las medidas para contrarrestarlas); y los G2 de la segunda, meramente reactivos, con unas relaciones de causa-efecto basadas sólo en una confianza que parte de experiencias poco validadas.

1.7.2 McFarlan.

Puede considerarse como adelanto muy simplificado de la generación G3. Tras considerar las 5 consecuencias clásicas del riesgo (fracaso en beneficios, coste, plazo del proyecto;

rendimiento; compatibilidad con otros sistemas), se centra en 3 factores de riesgo que afectan a su implantación (tras usar los medios adecuados), ordenados por su influencia (Marcelo, 2001, , 2003):

? Inexperiencia en la tecnología como factor subjetivo interno del equipo de realización

? Intransferencia del proyecto desde el usuario-cliente como factor subjetivo externo al equipo

? Envergadura del proyecto como factor objetivo.

McFarlan no se asume porque no define explícitamente un proceso para gestionar riesgos.

(26)

1.7.3 Boehm.

Según Boehm, la gestión de riesgos involucra dos pasos primarios, cada uno de los cuales tiene tres pasos subsiguientes. Ellos son (Boehm, 1991):

1. Evaluación de riesgos: Incluye:

a. Identificación de los riesgos. Produce las listas de elementos de riesgo del proyecto.

b. Análisis de riesgos. Evalúa la probabilidad de ocurrencia y la magnitud del impacto para cada elemento de riesgo identificado.

c. Priorización de los riesgos. Produce una lista ordenada de los elementos de riesgo identificados y analizados.

2. Control del riesgo: Involucra:

a. Plan de gestión del riesgo. Ayuda en la preparación para dirigir cada elemento de riesgo (por ejemplo, la vía para obtener información, anular el riesgo, transferir el riesgo o reducir el riesgo), incluyendo la coordinación de los planes de los elementos de riesgo individuales entre sí y con el plan del proyecto global.

b. Resolución de riesgos. Los elementos de riesgo son eliminados o, de lo contrario, resueltos (por ejemplo, la anulación de un riesgo a través de la relajación de requisitos).

c. Monitoreo del riesgo. Seguimiento del progreso del proyecto hacia la solución de sus elementos de riesgo y tomando acciones correctivas donde sea apropiado.

No se asume a Boehm por no incluir la Comunicación como parte del proceso, ni los riesgos empresariales, ni definir explícitamente una plantilla para la planificación y registro de riesgos.

1.7.4 Gestión de riesgos de proyectos de PMI.

La metodología de gestión de proyectos de PMI, el Project Management Body of Knowledge (PMBoK), es la suma del conocimiento dentro de la profesión de dirección del proyecto. El cuerpo del conocimiento se apoya en los practicantes y académicos que lo aplican y le aportan.

Incluye prácticas tradicionales demostradas que son ampliamente aplicadas, así como prácticas innovadoras que están surgiendo, incluyendo las publicadas y el material inédito. Como resultado, el PMBoK está evolucionando constantemente. Incluye los procesos relacionados a la Planificación de la gestión de riesgos, Identificación de Riesgos, Análisis cualitativo de riesgos, Análisis cuantitativo de riesgos, Planificación de respuestas a los riesgos y Seguimiento y control de los riesgos. Los objetivos de la Gestión de Riesgos del Proyecto son incrementar la probabilidad y el impacto de los eventos positivos y disminuir la probabilidad y el impacto de los eventos adversos al proyecto (PMI, 2004).

(27)

La metodología propuesta por PMI a través del PMBoK no se ajusta completamente a las necesidades de Softel, ya que no incluye la Comunicación como parte del proceso, ni aporta las plantillas para el plan de gestión de riesgos ni el registro de riesgos.

1.7.5 Programa de gestión de riesgos del SEI.

En su esfuerzo por responder a los problemas que presenta la gestión de riesgos, el objetivo del Programa de Riesgo del SEI es mejorar el proceso para la adquisición y desarrollo de sistemas de software intensivos. Para ello ha desarrollado una metodología para la Gestión de los Riesgos del Software (Software Risk Management – SRM) dirigida al ciclo de vida completo del software: adquisición, desarrollo y mantenimiento. Está soportado por tres grupos de prácticas:

Evaluación del Riesgo del Software (SRE), Gestión Continua del Riesgo (CRM) y la Gestión del Equipo de Riesgo (TRM). Los mismos están soportados en tres estructuras básicas o construcciones que son: Paradigma para la Gestión de Riesgos, Taxonomía del Riesgo y Clínica del Riesgo.

El Paradigma para la Gestión de Riesgos está compuesto por las actividades: Identificación, Análisis, Planificación, Seguimiento, Control y Comunicación (Figura 1.3).

La Taxonomía de riesgos del SEI provee un marco para organizar los datos y la información. Se utiliza con el objetivo de identificar los riesgos. El modelo SW-CMM proporciona, a las organizaciones de software, una guía de cómo ganar control de sus procesos para desarrollar y mantener el software y cómo evolucionar hacia una cultura de excelencia en la ingeniería de software. El modelo SA-CMM está basado en los principios del SW-CMM. Describe cinco niveles de madurez para la adquisición de software organizacional (Higuera, 1996).

Figura 1.3. Paradigma para la Gestión de Riesgos.

El SEI no se asume como proceso para Softel porque no propone explícitamente un proceso

(28)

para planificar la gestión de riesgos. Su taxonomía responde fundamentalmente a riesgos típicos que existen en organizaciones grandes, generalmente militares, con proyectos de desarrollo de software también grandes y no incluye los factores organizacionales de riesgo.

1.7.6 Modelo de Hall.

Define dos actividades principales: la evaluación y el control del riesgo. La gestión de riesgos genera estrategias para decidir qué hacer en cada momento y está basada en nueve teorías (Marcelo, 2001, , 2003):

? Razona sobre la vulnerabilidad -probabilidad de riesgo- usando las Teorías de probabilidad, de incertidumbre y la de portfolio.

? Razona sobre el impacto -consecuencia del riesgo-, usando las Teorías de la utilidad, de juegos, del caos y/o la creatividad.

? Combina vulnerabilidad e impacto en el tiempo, usando la Teoría de la decisión y el Teorema de Bayes para elecciones dinámicas.

El modelo 6-D, de las 6 disciplinas PPMMDD (Planear, Producir, Medir, Mejorar, Diseñar, Descubrir) soporta la mejora continua del proceso SEI o modelo de madurez de procesos en el desarrollo de software CMM (Capability Maturity Model) (Marcelo, 2001, , 2003):

? Diseñar. Transformar ideas en objetivos, creando y difundiendo la visión organizacional (CMM nivel 1).

? Planear. Confrontar los recursos disponibles y los requerimientos derivados de los objetivos del proyecto (CMM nivel 2).

? Producir. Implementar el plan para lograr el producto (CMM nivel 3).

? Medir. Comparar los resultados esperados y los realiza (CMM nivel 4).

? Mejorar. Aprender de experiencias como cambiar el plan (CMM nivel 5).

? Descubrir. Concienciar sobre el futuro, razona sobre posibilidades con resultados inciertos buenos (oportunidades) o malos (riesgos).

Este modelo amplía el concepto del riesgo en sentido revolucionario de oportunidad (consecuencias positivas) y soporta la mejora continua (modelo basado en la conciencia del pasado) y la reingeniería (modelo basado en la conciencia de futuro) (Marcelo, 2003).

No se asume el modelo de Hall porque no se definen explícitamente los procesos asociados a la planificación de la gestión de riesgos y a la comunicación.

(29)

1.7.7 Modelo SERIM de Karolak (IEEE).

Karolak aporta una visión integral del riesgo en la gestión empresarial y en el desarrollo tecnológico de los proyectos. Su manual SERIM de Gestión del Riesgo en Ingeniería de Software distingue los riesgos en el negocio (coste, plazo) y la tecnología, pero los vincula más a ésta, al estudiarlos en las seis Etapas del ciclo clásico de desarrollo (pre-requisitos, requisitos, diseño, codificación, pruebas, implantación/entrega/mantenimiento), con cuatro Etapas progresivas (Identificar, Estimar, Planear, Reducir los Riesgos) y dos Etapas realimentadoras del modelo (Informar, Predecir los riesgos) (Marcelo, 2003).

No se asume el modelo SERIM porque no se definen explícitamente la comunicación.

1.7.8 Modelo de Barki.

El Modelo ‘integrativo’ de ‘contingencia’ de Barki toma como hipótesis la influencia de dos variables: Nivel de Exposición al riesgo del proyecto y Perfil de la Gestión de su riesgo (cómo se maneja) en el Rendimiento del proyecto. El modelo emplea, como variable de intermediación, la adecuación de la Gestión respecto a la Exposición. Barki resume como hipótesis central que “el Rendimiento del proyecto será tanto mayor cuanto mejor se acople el Perfil de Gestión del Riesgo al nivel de su Exposición”. Además la gestión de un proyecto de alto riesgo requiere:

mucha integración interna y altos niveles de planificación formal (con alta capacidad de proceso de información) si se busca el cumplimiento de presupuesto; y/o mucha integración externa (participación del usuario), si se busca la calidad del producto (Marcelo, 2003).

No se asume el modelo de Barki porque no se definen explícitamente los procesos asociados a la gestión de riesgos. El mismo depende de la adecuación de la gestión respecto a la exposición, para lo cual se necesitan altos niveles de planificación formal, no existentes actualmente en Softel.

1.7.9 Pressman.

Pressman (2005) define un proceso para gestionar los riesgos de un proyecto de software que incluye la identificación (evaluación global del riesgo, componentes y controladores del riesgo);

la proyección o estimación del riesgo (tabla de riesgo, evaluación del impacto del riesgo, evaluación del riesgo); el refinamiento del riesgo y la reducción, supervisión y gestión del riesgo (evitar, supervisar y gestionar el riesgo, además de los planes de contingencia). Se refiere al método de la Lista de comprobación de los elementos de riesgo para identificar riesgos. Expone algunas preguntas que se pueden hacer para saber qué tan grave puede ser el riesgo y poder

(30)

realizar la evaluación global de riesgos del proyecto, así como el formato y contenido de la tabla que se puede emplear para ello (Pressman, 2005).

Para la estimación del riesgo, se puede emplear la Tabla de riesgos, en la cual se listan y categorizan todos los riesgos, se determina su probabilidad de aparición e impacto. Los riesgos de alta probabilidad y alto impacto pasan a lo alto de la tabla. Para poder priorizar los riesgos de primer orden, se debe estudiar la tabla ya ordenada, dibujando una línea de corte, de forma horizontal desde un punto en la tabla. Esto implicará que sólo a los riesgos que queden por encima de esta línea de corte, se les prestará atención en adelante y se les definirá el Plan de reducción, supervisión y gestión del riesgo (Pressman, 2005).

No se asume Pressman como proceso, pues el mismo no profundiza en todas las actividades asociados a la gestión de riesgos y no incluye la planificación de la gestión de riesgos ni la comunicación.

1.7.10 IEEE Computer Society.

La IEEE Computer Society (Computer Society of the Institute of Electrical and Electronics Engineers) y otras organizaciones están conduciendo una cantidad de proyectos que dependen de la evolución de la Guía SWEBOK (SoftWare Engineering Body Of Knowledge). La Guía 2004 es la edición actual de una guía que continuará evolucionando para encontrar las necesidades de la comunidad de ingeniería de software. Establece por primera vez una línea base para el cuerpo de conocimientos en el campo de la ingeniería de software. Posee 10 Áreas de Conocimiento (KAs). Como un tópico del Plan de Proyecto de Software se encuentra la Administración de Riesgos. Incluye la identificación y análisis de riesgo y la evaluación de riesgos críticos, la mitigación de riesgo y los planes de contingencia. Durante la actividad

“Proceso de Monitoreo”, el perfil de riesgos del proyecto es vuelto a visitar y es evaluada la adherencia para los requisitos de calidad. La exposición e influencia del riesgo son recalculados y se vuelven a ejecutar los árboles de decisión y las simulaciones de acuerdo a los nuevos datos. Durante la actividad “Proceso de Control”, se realizan los cambios al proyecto de acuerdo a los resultados obtenidos durante el Proceso de Monitoreo. Por lo tanto, es aquí donde el impacto y los riesgos asociados son modelados y administrados. Pueden incorporarse nuevas contingencias y hasta decidir que se debe abandonar el proyecto (IEEE, 2004).

No se asume la Guía SWEBOK de la IEEE ya que no incluye la planificación de la gestión de riesgos ni la comunicación. Además no incluye plantillas para el registro de riesgos ni es rico en herramientas y técnicas para el proceso.

Figure

Actualización...

Referencias

Actualización...