METODOLOGÍAS PARA LA GESTIÓN DE RIESGOS EN PROYECTOS DE SOFTWARE Y SU ADAPTACIÓN EN STEFANINI AUTOR: RUTH ALEXANDRA FAJARDO BUITRAGO

Transcripción

1 METODOLOGÍAS PARA LA GESTIÓN DE RIESGOS EN PROYECTOS DE SOFTWARE Y SU ADAPTACIÓN EN STEFANINI AUTOR: RUTH ALEANDRA FAJARDO BUITRAGO UNIVERSIDAD MILITAR NUEVA GRANADA ESPECIALIZACIÓN EN GERENCIA INTEGRAL DE PROYECTOS ARTICULO DE GRADO BOGOTA, AGOSTO DE 2014

2 METODOLOGÍAS PARA LA GESTIÓN DE RIESGOS EN PROYECTOS DE SOFTWARE Y SU ADAPTACIÓN EN STEFANINI METHODOLOGIES FOR RISK MANAGEMENT IN SOFTWARE PROJECTS AND ITS ADAPTATION IN STEFANINI Ruth Alexandra Fajardo Buitrago Ingeniera en Redes de Computadores Technical Consultant Sophos Banking Bogotá, Colombia rualfabu@gmail.com RESUMEN Los proyectos de software al igual que cualquier otro tipo de proyectos tienen riesgos que pueden ser materializados durante su ejecución. El desarrollo de software es una actividad muy compleja e impredecible. El Standish International en el 2013 indicaba que el 43% de los proyectos de software no se pudieron entregar a tiempo, dentro del presupuesto, y con la funciones requeridas, mientras que el 18% de los proyectos de software fueron cancelados (Standish Group International, 2012). Las empresas invierten recursos sustanciales y esfuerzo en el desarrollo de software, en consecuencia, el control de los riesgos asociado a los proyectos es vital para garantizar resultados exitosos. La comprensión de la naturaleza de los distintos riesgos y su relación con el rendimiento del proyecto es cada vez más importante. Este artículo recopila las metodologías más conocidas para la gestión de riesgos, validando la existencia de métodos cuantitativos y cualitativos, estadísticos, matemáticos, sistemáticos que guíen todo este proceso y evaluándolos en función de la implementación del más acertado para una empresa de desarrollo de Software como Informática & Tecnología Stefanini, en donde sus gerentes de proyectos reconocen constantemente la necesidad de mejorar la manera de hacer dicha gestión, como parte de las lecciones aprendidas. Palabras clave: Gestión de Proyectos de Software, Riesgo, Gestión de Riesgos, Métodos sistemáticos, incertidumbre. ABSTRACT Software projects, like any other type of projects, have risks that can be materialized during their implementation. Software development is a complex and unexpected activity. In 2013, The Standish International indicated that 43% of software projects could not be presented on time, required more budget or did not match the required features, while 18% of such projects were canceled (Standish Group International,

3 2013). Companies invest substantial resources and efforts in software development, consequently, control risks related with the projects becomes vital to ensure successful results. Understanding the nature of the different risks and their relevance in project performance is becoming a very important topic. This article collects the most known methodologies for risk management validating the existence of statistical, mathematical and systematical methods for guiding all this process, and evaluating them by implementation of the most accurate one for a software development company such as Informática & Tecnología Stefanini, where project managers have recognized the need of improve the way they do risk management, as part of their own experience. Keywords: Software project management, risk, risk management, systematic methods, uncertainty. INTRODUCCIÓN Los Proyectos de desarrollo de software a menudo se enfrentan a problemas imprevistos que plantean riesgos potenciales dentro del entorno de desarrollo. El control de estos riesgos surge tanto de los componentes técnicos y no técnicos del desarrollo y tener control de ellos desde las primeras etapas del desarrollo es crucial para lograr un proyecto exitoso. Por lo tanto, la gestión del riesgo de desarrollo de software está siendo reconocido como la mejor práctica en la industria del software para reducir estos riesgos antes de que ocurran. (Islam, 2009) El software es un componente crucial del entorno empresarial de hoy en día, por ello se requiere un esfuerzo superior de gestión de riesgos para dirigir con habilidad los proyectos de desarrollo del mismo. En la comunidad académica se genera un interrogante: La gestión de riesgos contribuye al desarrollo exitoso de los proyectos de TI?.En los últimos 10 años, mucho se ha conocido sobre las causas que hacen que los proyectos de TI fallen, sin embargo, todavía hay muy poca evidencia empírica de que este conocimiento se utiliza realmente como apoyo a la gestión de riesgos en los proyectos de TI. (De Bakker, Boonstra, & Wortmann, 2010) El análisis de diferentes investigaciones realizadas en la Universidad de las Ciencias Informáticas (UCI) ofrece como resultado que, el desarrollo de la Gestión de Riesgos (GR) en muchos de los proyectos productivos es ineficiente, pues estos no tienen en cuenta alguna de las metodologías o modelos establecidos y reconocidos mundialmente para realizar este proceso. (Infante, Rabí, & Díaz, 2013) Informática & Tecnología Stefanini S.A., se ha consolidado como una empresa de servicios de tecnología con énfasis en el desarrollo, soporte y administración de sistemas de información en Colombia. Ellos entienden la calidad en el desarrollo de software como el conjunto de características asociadas al producto final pero logrado durante su proceso, por tal razón, al igual que muchas empresas del sector, han implementado un sistema de calidad evaluado con el modelo CMMI DEV vs 1.3,

4 otorgado por el Software Engineering Institute SEI y la universidad Carnegie Mellon, el cual proporciona un conjunto completo e integrado de guías para desarrollar productos y servicios (Padilla, 2014). Durante este proceso de evaluación y como parte de las oportunidades de mejora sugeridas por la empresa evaluadora, se confirma la necesidad de realizar mejoras sustanciales en la definición de estrategias para gestión de riesgos, por tal razón se requiere conocer y validar cuales son las metodologías existentes e identificar cual es la más adecuada. 2. MATERIALES Y MÉTODOS La investigación desarrollada es de tipo exploratoria considerando que aunque la importancia de gestionar los riesgos en proyectos de Software es conocida, no lo son las metodologías para realizar esta labor y no se conoce como las empresas en Colombia realizan esta gestión. Por tal razón fuentes de información trabajadas son: La fuente primaria de la investigación son las entrevistas a los gerentes de proyectos que trabajan en Informática & Tecnología Stefanini para establecer de qué manera realizan la identificación y gestión de riesgos y las sugerencias frente al tema junto con entrevistas a personas del área de Calidad que se encargan de levantar, documentar y socializar las políticas y procedimientos a seguir en todos los proyectos. La segunda fuente ha sido la búsqueda en Internet de publicaciones, referencia de libros, artículos y metodologías en las cuales se pueda evidenciar resultados de proyectos que incluyeron el uso o no de metodologías en la gestión de riesgos detectando rasgos comunes, sugerencias y guías para su implementación los cuales puedan ser considerados como experiencia para la adaptación en Informática & Tecnología Stefanini 3. MARCO TEÓRICO 3.1. Definición de Riesgo Según el PMBOOK, el riesgo de un proyecto es un evento o condición incierta que, de producirse, tiene un efecto positivo o negativo en uno o más de los objetivos del proyecto, tales como el alcance, el cronograma, el costo y la calidad. Un riesgo puede tener una o más causas y, de materializarse, uno o más impactos. Una causa puede ser un requisito especificado o potencial, un supuesto, una restricción o una condición que crea la posibilidad de consecuencias tanto negativas como positivas Que es la gestión de Riesgos

5 Comprende todas las actividades que se realizan para reducir las incertidumbres asociadas con ciertas tareas, o eventos. En el contexto de los proyectos, la gestión del riesgo reduce los impactos de los eventos no deseados en el proyecto. La gestión de riesgos en cualquier proyecto requiere la realización de las actividades del proceso de toma de decisiones Categorización de Riesgos en proyectos de Software Los riesgos pueden ser agrupados en 3 categorías: Riesgos del Negocio Comprenden todo lo que puede afectar el cumplimiento de los objetivos del proyecto, deben ser gestionados por la empresa y no se pueden trasferir, tales como riesgos de mercado, de estrategia, de ventas, de gestión y/o de presupuesto Riesgos Técnicos: Son aquellos que se pueden identificar de acuerdo al ciclo de vida de desarrollo de software (SDLC) y deben ser gestionados por las personas responsables de cada etapa del SDLC Riesgos Externos Corresponden todos los riesgos que no se pueden controlar desde el proyecto como los es la legislación Mediciones de Riesgo El desarrollo de una gestión de riesgos eficaz y adecuada depende de la comprensión de dos componentes básicos: probabilidad de ocurrencia y el impacto en el proyecto. La probabilidad de ocurrencia de cada riesgo en proyectos de software es diferente y su grado de impacto en el costo del proyecto. Por lo tanto, estos dos componentes del riesgo de software Son de vital importancia para desarrollar una buena gestión de riesgos Evaluación de Riesgos en Proyectos de Software Los avances en las técnicas de gestión del riesgo han permito a algunas organizaciones de software implementarlas y fortalecer su gestión de riesgo. Técnicas de modelado y métodos de pensamiento como lluvia de ideas son las más usadas para dicha gestión. Estas técnicas se utilizan para comprender el riesgo e incluyen técnicas cualitativas, semi-cuantitativas y cuantitativas. Estos métodos se aplican con frecuencia en el lugar de trabajo por si mismos o en conjunto con otras técnicas Métodos Cualitativos.

6 Se caracterizan por no recurrir a cálculos numéricos. Pueden ser métodos comparativos y métodos generalizados. - Lluvia de ideas - Análisis SWOT también conocido como análisis DOFA - Mapas - Listas de verificación y cuestionarios - Entrevistas con pares Métodos Cuantitativos Introducen una valoración cuantitativa respecto a las frecuencias de ocurrencia de un determinado suceso y se denominan métodos para la determinación de frecuencias, o bien se caracterizan por recurrir a una clasificación de las áreas de una instalación con base a una serie de índices que cuantifican daños: índices de riesgo. Modelos Simbólicos Hacen uso de enunciados matemáticos y estadísticos para presentar el problema Análisis de probabilidad El cálculo de riesgo requiere el uso de datos de probabilidad la cual es calculada con base a información histórica y la experiencia. Dado que hay incertidumbre (definida esta como ausencia de información) es importante que todos los riesgos que afectan el desarrollo del proyecto y por ende el proceso de toma de decisiones sean evaluados. Este método se basa en eventos y el cálculo de la probabilidad de ocurrencia de esos eventos. Un evento es algo que puede o no ocurrir en donde si se tiene la certeza que ocurrirá la probabilidad es 1.0 y, si dicho evento sin duda no pasara la probabilidad es =0. En muchos casos los eventos no ocurren por sí mismos y dependen de otros eventos, para lo cual se calcula la probabilidad en función del evento del cual depende. Análisis de consecuencias Consiste en la realización de una evaluación inicial de los hechos y los posibles problemas y/o causas para posteriormente analizar las consecuencias. Consecuencia 1 Evento Análisis Consecuencia 2 Consecuencia 3 Problema Causas

7 Figura 1: Ilustración de la técnica de análisis de consecuencias Fuente: McManus, J. (2012). Risk management in software development projects: Routledge. Arboles de decisión Ofrecen una es estructura específica para la exploración de alternativas de acción para resolver situaciones complejas. Los pasos para construir un árbol de decisión son: - Describir y comprender el problema - Identificar todas las opciones posibles - Identificar todos los posibles resultados derivados de cada opción. - Plasmarlos en estructura de árbol (Nodos de decisión, ramas, nodos de posibilidad, resultados) - Asignar a cada resultado la probabilidad de que ocurran (0-1) y una preferencia por que ocurran la cual está dada entre o y 100 P(Satisfactorio)= 0.60 Realizar Valor esperado $ 400 M P(Falla)= 0.40 PROYECTO Y P(Satisfactorio)= 0.60 Abandonar Valor esperado $ 300 M Figura 2: Ilustración arboles de decisión P(Falla)= 0.40 Fuente: McManus, J. (2012). Risk management in software development projects: Routledge. Análisis de Monte Carlo Es un método que permite incorporar detalles sobre la incertidumbre. Se inicia seleccionando las variables inciertas definiendo un rango de valores posibles con una distribución de probabilidad la cual se determina de acuerdo a las condiciones que rodean a cada variable. El tipo de distribución de probabilidad puede ser normal,

8 triangular, uniforme o logarítmica, sin desconocer que existen otras distribuciones de probabilidad las cuales se emplean con base al análisis que se requiera. Con este método los gerentes pueden por ejemplo determinar la probabilidad que una actividad se encuentre en la ruta crítica Monetización de Riesgos La capacidad de monetizar los riesgos en proyectos de desarrollo de software puede beneficiar en diversos aspectos la toma de decisiones. (Appari & Benaroch, 2010) los autores presentan un método de valoración del riesgo que estima dos parámetros para cada factor de riesgo individual: costo adicional incurrido por unidad de exposición, y la sensibilidad del proyecto. Dado que la variabilidad es una medida ampliamente utilizada de riesgo en finanzas y ciencias, el método de fijación de precios se deriva de parámetros de riesgo al relacionar la variabilidad en los factores de riesgo a la variación de los costos del proyecto. (Appari & Benaroch, 2010) 4. RESULTADOS El Standish International en el 2013 indicaba que el 43% de los proyectos de software no se pudieron entregar a tiempo, dentro del presupuesto, y con la funciones requeridas, mientras que el 18% de los proyectos de software fueron cancelados (Standish Group International, 2013). Figura 3: Resultado en proyectos de Software en el 2012 Fuente: CHAOS MANIFESTO 2013, The Standish Group International Existen factores de alta importancia que afectan de forma general los productos que se desarrollan en los proyectos informáticos, como son el desconocimiento de las herramientas y lenguajes de programación empleados, incumplimiento del cronograma de trabajo por parte de los desarrolladores, uso de las tecnologías de forma indebida, inexistencia de información histórica en el proyecto, necesidad de mayores recursos de hardware, mal desempeño por parte de los miembros del equipo de los roles asignados a los mismos, estos factores pueden ocasionar consecuencias

9 no previstas inicialmente y que por tanto alterarán el buen término del proyecto. Estas sorpresas o eventos que pueden ocasionar daños no son más que los riesgos. (Infante et al., 2013) La gestión de riesgos permite definir en forma estructurada, operacional y organizacional, una serie de actividades para darle tratamiento a los riesgos de los proyectos a lo largo de todas las fases de su ciclo de vida de desarrollo de software. En la mayor parte de los casos, 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, Britos, & Diez, 2006) La preparación de una evaluación detalla del riesgo de un proyecto de software es costoso y consume mucho tiempo, sin embargo en el largo plazo los beneficios que se obtienen normalmente superan los costos involucrados. Expertos en gestión de riesgos de software coinciden en que los costos asociados con la toma de algunas medidas preventivas desde el comienzo son insignificantes en comparación con los costos dramáticos en los que se puede incurrir cuando se descuidan las técnicas adecuadas de gestión de riesgos. (McManus, 2012). Existen varios modelos de administración de riesgos y las empresas e su mayoría coinciden en seguir principalmente los pasos especificados en la figura 2. Identificación Control Análisis Documentación y Comunicación Seguimiento Planificación Figura 4: Modelo de administración de Riesgos Fuente: Autor de acuerdo a la investigación e información publicada Gestión de Riesgos en CCMI El CMMI (Capability Maturity Model Integrated) se ha convertido en el nuevo estándar a nivel mundial para la medición de la calidad de los procesos de desarrollo de software

10 y presenta como una de sus Áreas de proceso fundamentales la Administración de Riesgos. El propósito de la Gestión de Riesgos (RSKM) es identificar problemas potenciales antes que presenten, para que las actividades de tratamiento de riesgos puedan planificarse e invocarse según sea necesario a lo largo de la vida del producto o del proyecto para mitigar los impactos adversos sobre la consecución de objetivos. La gestión de riesgos se puede dividir en las siguientes partes: Definir una estrategia de gestión de riesgos. Identificar y analizar los riesgos. Tratar los riesgos identificados, incluyendo la implementación de planes de mitigación, según sea necesario Las metas y prácticas que especifica CMMI que se deben cumplir son: Meta 1: Preparar la gestión de riesgos. Practica 1.1 Determinar las fuentes y las categorías de riesgos. Practica 1.2 Definir los parámetros de riesgos. Practica 1.3 Establecer una estrategia de gestión de riesgos. Meta 2: Identificar y analizar los riesgos. Practica 2.1 Identificar los riesgos. Practica 2.2 E valuar, clasificar y priorizar los riesgos. Meta 3: Mitigar los riesgos. Practica 3.1 Desarrollar los planes de mitigación de riesgos. Practica 3.2 Implementar los planes de mitigación de riesgos. Tabla 1: Área de proceso Gestión de Riesgos Fuente: SEI Administrative Agent,(2009) Spanish Technical Report CMMI V 1 3 El área de proceso Gestión de riesgos describe una evolución de estas prácticas específicas para planificar, prevenir y mitigar los riesgos sistemáticamente a fin de minimizar proactivamente su impacto sobre el proyecto. Aunque el énfasis principal del área de proceso Gestión de Riesgos se realiza sobre el proyecto, estos conceptos también pueden aplicarse para gestionar los riesgos de la organización Gestión de Riesgos bajo la metodología Microsoft Solutions Framework Microsoft Solutions Framework (MSF) ha desarrollado un proceso para identificar y valorar ininterrumpidamente los riesgos de un proyecto, dar prioridad a estos riesgos e implementar las estrategias para tratar estos riesgos de forma proactiva a lo largo del ciclo de vida del proyecto, tal como se define en el Modelo de procesos de MSF. Las principales características de la disciplina de administración de riesgos de MSF son las siguientes:

11 Carácter global que incluye todos los elementos de un proyecto: personas, procesos y elementos de tecnología. Incorpora un proceso intuitivo, sistemático y reproducible para la administración de riesgos de los proyectos. Se aplica ininterrumpidamente durante el ciclo de vida de los proyectos. Su tendencia es proactiva en lugar de reactiva. Fomenta el aprendizaje individual y colectivo. Es muy flexible y puede adaptarse a una gran variedad de análisis de riesgos cuantitativos y cualitativos Gestión de Riesgos con Rational Unified Process (RUP) Uno de los objetivos de RUP, metodología implementada por la empresa Rational Software, actualmente propiedad de IBM, es asegurar que las expectativas de todas las partes son sincronizadas y consistentes. Esto es asegurado a través de evaluaciones periódicas durante el ciclo de vida del proyecto, y es documentado en el Reporte de Evaluación de Status. Este reporte es utilizado para hacer un seguimiento a información acerca de recursos (humano y financiero), mayores riesgos, progreso técnico medido a través de métricas y resultados de hitos principales. (Romero, Lovera, & YARINGANO, 2007) El equipo se junta para crear una lista de todos los posibles riesgos que en algún momento pudieran afectar al proyecto. Esta lista nace a partir de un análisis del proyecto, tanto general como por cada paquete de trabajo, y así localizar las principales fuentes generadoras de riesgo. En RUP existen dos tipos de riesgos: - Directos: el personal tiene cierto control sobre ellos. - Indirectos: no pueden ser controlados. Además se cuenta con los riesgos generados a partir de los recursos del proyecto: Organización Falta de compromiso del personal hacia el proyecto. Falta de planeación y definición en el proceso de ingeniería de software. El proyecto es el más largo antes intentado. Recursos Falta de recursos para completar el proyecto. Limitaciones de presupuesto: el sistema debe ser entregado en un costo fijo o se va a cancelar. Los estimados de costos sean inexactos. Personal Falta de personal disponible para el proyecto. El personal no tiene las habilidades y experiencia necesarias. El personal no cree en el proyecto. -no hay expertos en el área disponibles.

12 Tiempo La agenda no es realista. No hay tiempo para hacerlo bien. Otros de los riesgos que pueden aparecer en el proyecto son los técnicos, dentro de los cuales se consideran: Alcance. El éxito no puede ser medido. Los requerimientos no son estables ni entendibles. Los tiempos de desarrollo son inflexibles y limitados. Tecnológicos. El éxito del proyecto dependa de productos, servicios, tecnologías nuevos que no hayan sido probados antes. Dependencias del sistema con otros sistemas externos, y que estos fallen. Requerimientos de disponibilidad y seguridad inflexibles. El proyecto es inalcanzable (muy complejo o enorme como para trabajar apropiadamente). Dependencia externa. El proyecto depende de proyectos en desarrollo paralelo. El éxito depende de la integración de herramientas de desarrollo (compiladores, herramientas de diseño, etc.), tecnologías de implementación (sistema operativo, bases de datos, etc.). RUP propone la construcción de una matriz de respuesta a riesgos la cual contiene la respuesta que se le daría al riesgo en caso de materializarse, el plan de acciones que se llevaría a cabo en caso de ser activado y la persona responsable del riesgo Gestión de Riesgos con según las Norma ISO En noviembre de 2009, la Organización Internacional de Normalización (ISO) publico la norma ISO Gestión de Riesgos la cual ofrece principios y directrices genéricas sobre gestión de riesgos. La norma no es específica de ninguna industria o sector y puede ser utilizada por cualquier organización pública o privada y aplicarse a cualquier tipo de riesgo en una amplia serie de actividades y operaciones. ISO es la referencia mundial en sistemas de gestión de riesgos De acuerdo a la norma la gestión de riesgos es considerada como el proceso de ponderación de las distintas opciones en base a los resultados de la valoración de riesgos. Procesos para aumentar la probabilidad e impacto de las oportunidades y reducir la probabilidad e impacto de las amenazas. (Purdy, 2010) El enfoque está estructurado en tres elementos claves para una efectiva gestión de riesgos: Los principios de gestión del riesgo El marco de trabajo (framework) para la gestión del riesgo El proceso de gestión del riesgo

13 Los principios básicos para la gestión del Riesgo son: - Crear valor - Está integrada en los procesos de una organización - Forma parte de la toma de decisiones - Trata explícitamente la incertidumbre - Es sistemática, estructurada y adecuada - Está basada en la mejor información disponible - Está hecha a medida - Tiene en cuenta factores humanos y culturales - Es transparente e inclusiva - Es dinámica, iterativa y sensible al cambio - Facilita la mejora continua de la organización 5. DISCUSIÓN Los teóricos y muchos profesionales están de acuerdo en que hay una creciente necesidad de métodos más sistemáticos y herramientas para complementar el conocimiento individual, juicio y experiencia, en relación con el manejo del riesgo. Los estándares de la industria pueden ayudar en el momento de determinar cómo prevenir o mitigar riesgos específicos comúnmente encontrados en una industria particular. Ciertos riesgos pueden ser gestionados o mitigados proactivamente mediante la revisión de buenas prácticas y las lecciones aprendidas considerando la prevención como una de las principales herramientas en nuevos proyectos. Un reciente estudio de PricewaterhouseCoopers (Pwc) revela que el 75% de los ejecutivos reporta un incremento de riesgos en la organización, eso significa que si hasta el año pasado tenía 5 riesgos identificados hoy tiene el doble. Dado lo mencionado anteriormente es importante crear una cultura de concientización del riesgo y las empresas pueden adaptarse de acuerdo a su negocio y a las características propias de cada proyecto. La importancia de la priorización de los riesgos se hace necesaria si se quiere tener un mayor grado de exactitud y eficiencia en un proyecto dado. Sin embargo, no existe una solución adecuada para que las organizaciones apliquen de manera sencilla la priorización de riesgos. Para realizarla es necesario determinar el impacto y probabilidad de ocurrencia para priorizarlos riesgos, y así controlar mejor los imprevistos del proyecto. Informática & Tecnología Stefanini ha definido un procedimiento para la gestión de riesgos: PC-PP-03 Gestión de Riesgos y Problemas el cual se ha complementado a lo largo del proceso de certificación que la compañía ha llevado a cabo en los últimos años. En la tabla No. 2 se presentan los riesgos más comunes que se presentan en proyectos de software y como Stefanini los considera dentro de su gestión:

14 NR. RIESGO APLICA OBSERVACIONES Planeación: SI NO 1 Manejo ineficiente de recursos La obtención de los recursos siempre es acordes al desarrollo del proyecto. 2 Estimaciones imprecisas Las estimaciones en gran medida son a juicio de expertos y la realidad de los proyectos ha demostrado que las desviaciones entre lo estimado y lo ejecutado son considerables. 3 Planeación inadecuada Los gerentes de proyecto establecen cada uno de los planes requeridos: Plan de comunicación, Plan de gestión de la configuración, entre otros. 4 Problemas de comunicación Se realizan seguimientos continuos para garantizar una comunicación constante entre los involucrados en el proyecto. 5 Personal no preparado Depende de la disponibilidad de los adecuadamente para las recursos. En algunas ocasiones los actividades de la fase recursos no son propios de un único proyecto. 6 Mala definición de entregables Estos son definidos en conjunto con el 7 Gestión contractual no apropiada 8 Deficiencias en la definición e involucramiento de los interesados del proyecto. 9 Discrepancias entre los líderes del proyecto Análisis de requerimientos: cliente al inicio del proyecto. La responsabilidad de la gestión contractual recae en personas distintas a los ejecutores del proyecto. Es común y el riesgo principalmente se presenta cuando el cliente no asigna a las personas indicadas. Cuando se presentan diferencias en conjunto se hace un análisis de pros y contras de cada alternativa y para los casos que sean decisiones importantes se sigue un proceso de toma de decisiones establecido por la empresa. 10 Desconocimiento de metodologías y mejores practicas 11 Herramientas Case inadecuadas 12 Personal no preparado adecuadamente para las actividades de la fase Se ha presentado porque en algunos proyectos se debe seguir la metodología del cliente que ha implicado un mayor impacto en tiempo y costo. Las herramientas que actualmente se manejan son reconocidas en el mercado. Cada vez que un nuevo integrante ingresa al equipo de trabajo del proyecto se evalúa su desempeño y

15 13 El tamaño del equipo no es el adecuado 14 Falta de conocimiento de procesos de negocio 15 Los usuarios que participan no son los indicados 16 Falta de claridad en la definición de requerimientos por parte de los usuarios 17 No especificación de requerimientos no funcionales 18 Información no real suministrada por los usuarios resultados de acuerdo al rol que cumple. Depende de la disponibilidad de recursos y la empresa cuenta con un alto grado de rotación de personal. Los usuarios pueden ser personas que no llevan mucho tiempo en la compañía o no tienen un perfil que tiene claro lo que necesita el cliente. Desde el inicio del proyecto se explica al cliente la importancia de que los usuarios que participen en el proyecto sean los indicados. Como parte del proceso se establece que un líder del área debe ser la persona que realice la aprobación del documento de requerimientos con el fin de corroborar la información entregada por los usuarios. Como parte de la plantilla del documento de requerimientos está incluida la sección de Requerimientos No funcionales. Como parte del proceso se establece que un líder del área debe ser la persona que realice la aprobación del documento de requerimientos con el fin de corroborar la información entregada por los usuarios. Diseño 19 Arquitectura inapropiada Puede suceder que el cliente ya tiene establecida esta arquitectura por tal razón una de las actividades iniciales es hacer una evaluación de la misma. 20 Herramientas inapropiadas Las herramientas que actualmente se manejan son reconocidas en el mercado. 21 Diseño lógico pobremente definido 22 Diseño físico pobremente definido 23 Diseño de interfaces pobremente definido El diseño lógico es sometido a revisión de pares y aprobación del cliente. El diseño físico es sometido a revisión de pares y aprobación del cliente. El diseño de interfaces es sometido a revisión de pares y aprobación del cliente. 24 Falta de visión El líder del proyecto asignado siempre es una persona con experiencia comprobada en su rol ya sea en la misma empresa o en otras. Desarrollo

16 25 Lenguaje de desarrollo inapropiado 26 Estándares de documentación inapropiados 27 Falta de conocimiento del conjunto de herramientas a usar 28 Dependencia de una herramienta en particular 29 Manejo de liberación de versiones inadecuado 30 Gestión de configuración inadecuada 31 Malas especificaciones de construcción Pruebas 32 Criterios de aceptación inadecuados 33 Herramientas de pruebas inadecuadas 34 Metodología de pruebas inadecuada 35 No se involucra al usuario en las pruebas de aceptación Las herramientas que actualmente se manejan son reconocidas en el mercado. Se tiene definido estándares y lineamientos de codificación. La empresa promueve capacitaciones continuas para mitigar este riesgo. La empresa cuenta con diversas líneas de negocio que garantiza el conocimiento y experticia en distintas herramientas. Actualmente se está implementando el uso de nuevas herramientas para el control de versiones que mejoren esta gestión. Como parte de la metodología esta definido el proceso de gestión de la configuración y al inicio de cada proyecto se acuerda con el cliente y se incluye en el plan de proyecto. Se programan inspecciones de código para que el líder o un par del equipo puedan validar el cumplimiento de los lineamientos definidos. Como parte de la metodología criterios de aceptación son definidos en conjunto con el cliente. Las herramientas con las cuales trabaja actualmente la compañía son de licenciamiento libre. Como parte de la metodología se establece un plan de pruebas donde se define todo el proceso de las pruebas como los tipos de pruebas que se realiza, el registro de incidentes, entre otras. Las pruebas de aceptación las realiza el cliente. El equipo del proyecto realizar una labor de acompañamiento. 36 Falta de soporte interno Los ambientes pueden ser compartidos por varios proyectos lo cual genera inconvenientes. 37 No se realizan pruebas de stress 38 Sobre dependencia de las pruebas Beta Se ha iniciado la implementación de herramientas que apoyen la ejecución de pruebas de stress, la empresa es consciente de la importancia de realizarlas. No hace parte de los proyectos la generación de una versión beta.

17 39 Dependencia de analistas de pruebas por su experiencia Siempre se busca que el equipo de trabajo sea el apropiado para el proyecto considerando que cada proyecto es único y la dependencia de un único recurso no es lo más conveniente. Implementación. 40 Problemas de comunicación Se realizan seguimientos continuos para garantizar una comunicación constante entre los involucrados en el proyecto. 41 Falta de planeación Estas actividades se definen en conjunto con el cliente y su disponibilidad. 42 No hay una definición de la estrategia de implementación 43 Falta de capacitación a los usuarios 44 Falta de tiempo para la implementación 45 No se completan las transferencias entre los grupos 46 Manuales de usuario deficientes La empresa incluye un plan de gestión del cambio el cual está en proceso de definición para determinar su alcance. Siempre se incluye un plan de capacitaciones: Técnica y funcional. Antes de iniciar la implementación se reevalúa el tiempo establecido y si no es suficiente se acuerda con el cliente los ajustes necesarios. Se acuerda con el cliente según el proyecto si hace parte del alcance del mismo o no. La empresa tiene establecidos formatos con el contenido de los manuales y estos son validados por pares del proyecto. 47 Manuales Técnicos deficientes La empresa tiene establecidos formatos con el contenido de los manuales y estos son validados por pares del proyecto 48 No se realizan pruebas en sitio o son muy deficientes 49 El Soporte posterior a la implementación es pobre. Se busca garantizar que el ambiente de pruebas que proporciona el cliente para pruebas de aceptación sea lo más similar posible al ambiente de producción. En conjunto con el cliente se establecen Acuerdos de Niveles de Servicio para estas actividades de soporte. El proceso definido por Stefanini para la gestión de riesgos es sistemático, no se basa únicamente en una sola metodología, cubre los pasos de identificación, clasificación, cuantificación y definición del plan de respuesta estableciendo probabilidad e impacto como se presenta a continuación:

18 Probabilidad MA A M B MB MB B M A MA Impacto Donde MB= Muy Bajo, B= Bajo, M= Medio, A= Alto, MA= Muy Alto Tabla No. 3 Fuente: PC-PP-03 Gestión de Riesgos y Problemas Informática & tecnología Los gerentes de proyecto que trabajan en la compañía coinciden que realizar el seguimiento a los riesgos es una de las tareas que toma mucho tiempo dado la magnitud de los mismos. Dado el tamaño de los proyectos en donde la cantidad de riesgos es alta, el seguimiento debe ser constante y considerando la importancia de hacer una medición de riesgos se propone hacer una priorización de los riesgos con el fin de tener un mayor control sobre aquello riesgos cuyo impacto es alto considerando el método de análisis de probabilidad descrito anteriormente para lo cual se asigna una calificación la probabilidad: Probabilidad Calificación Muy Alta 90% Alta 70% Moderado 50% Baja 30% Muy Baja 10% No ocurre 0% Tabla No. 4 Fuente: Autor basada enpc-pp-03 Gestión de Riesgos y Problemas Informática & tecnología Y una escala numérica al impacto como se muestra a continuación:

19 Escala relativa o numérica Muy Bajo (1) Bajo (2) Moderado (3) Alto (4) Muy Alto (5) Descripción Insignificante incremento en costo, alcance, calidad Incremento en el costo <5% en costo, alcance, calidad Incremento en el costo 5% - 10% en costo, alcance, calidad Incremento en el costo 10% - 20% en costo, alcance, calidad Incremento en el costo >20% en costo, alcance, calidad Tabla No. 5 Fuente: Autor basada enpc-pp-03 Gestión de Riesgos y Problemas Informática & tecnología Para realizar la priorización de los riesgos se toma la información obtenida para la valoración del impacto y la probabilidad de ocurrencia, realizando el siguiente calculo: Prioridad = Probabilidad *Impacto Como referencia se puede utilizar la siguiente definición para la priorización, la cual puede ser modificada para un proyecto en particular: Prioridad Límite Inferior Límite Superior Muy Baja 0,01 0,03 Baja 0,04 0,09 Media 0,1 0,25 Alta 0,26 0,49 Muy Alta 0,5 0,81 Tabla No. 6 Fuente: Autor basada enpc-pp-03 Gestión de Riesgos y Problemas Informática & tecnología Los riesgos clasificados con una prioridad muy alta y alta requieren la definición de un plan de contingencia y mitigación. Para los riesgos de prioridad media deberá realizarse una valoración y determinar si se establece o no un plan de contingencia. En el caso de los riesgos de prioridad baja aunque no se definan estos planes deben ser tenidos en cuenta en los seguimientos para detectar cambios en su probabilidad de ocurrencia e impacto.

20 Complementar la metodología actual de la compañía con esta priorización permitirá realizar otros análisis o acciones posteriores, evaluando y combinando su probabilidad de ocurrencia y su impacto. 6. CONCLUSIONES Y RECOMENDACIONES El Proceso de Gestión de Riesgos de Proyectos describe las necesidades de identificar, evaluar, documentar y administrar los riesgos de un proyecto que pueden o no tener un impacto en los costos, tiempos, recursos y el plan del proyecto. La aplicación de la metodología de gestión de riesgos en todas las empresas permitirá que se preparen proactivamente contra las amenazas que afectan el éxito del proyecto y por ende la rentabilidad. La política de riesgos de la empresa nace desde la intención de la gerencia y la participación de todos los integrantes de la organización basados en procesos de concienciación y concientización sobre el manejo del riesgo. Informática & Tecnología Stefanini es una empresa consiente de la necesidad de un mejoramiento de procesos para la gestión de proyectos, por ello se preocupa de manera sistemática y permanente en adelantar un excelente proceso de gestión de riesgos La información obtenida mediante la aplicación de metodologías para adelantar la gestión de riesgos permite a cualquier empresa hacer un adecuado proceso de toma de decisiones favorable a los objetivos de la empresa Es recomendable que la compañía implemente un sistema para el registro de toda la gestión de riesgos, que permita generar estadísticas de los más comunes o los que más impactan dado que se evidencia que algunos son reiterativos, esto también permitirá cuantificar y valorar el riesgo más acertadamente con el fin de evitar sobrecostos en los que se debe incurrir durante la mitigación de los mismos. También es recomendable que la compañía incluya dentro del proceso la priorización de los riesgos de acuerdo al impacto y probabilidad establecidos con el fin de controlar en mayor medida aquellos de gran incertidumbre y que puedan afectar significativamente el avance del proyecto. 7. REFERENCIAS BIBLIOGRÁFICAS Appari, A., & Benaroch, M. (2010). Monetary pricing of software development risks: A method and empirical illustration. Journal of Systems and Software, 83(11),

21 De Bakker, K., Boonstra, A., & Wortmann, H. (2010). Does risk management contribute to IT project success? A meta-analysis of empirical evidence. International Journal of Project Management, 28(5), Infante, L. M. I., Rabí, D. E. A., & Díaz, M. M. (2013). Exposición a los Riesgos en un proyecto de Software: aplicación del modelo Mogeri. Serie Científica, 6(6). Islam, S. (2009). Software development risk management model: a goal driven approach. Paper presented at the Proceedings of the doctoral symposium for ESEC/FSE on Doctoral symposium. Maniasi, S., Britos, M. I. P., & Diez, M. I. E. (2006). Identificación de Riesgos de Proyectos de Software en Base a Taxonomías. Tesis de Magister en Ingeniería del Software. Escuela de Postgrado. ITBA. McManus, J. (2012). Risk management in software development projects: Routledge. Padilla, N. Y. L. (2014). Ranking mundial en certificaciones CMMI-DEV ver. 1.3 año Revista Iberoamericana de Producción Académica y Gestión Educativa, 1(1). Purdy, G. (2010). ISO 31000: 2009 setting a new standard for risk management. Risk analysis, 30(6), Romero, A., Lovera, D., & YARINGANO, S. (2007). Gestión de riesgos con CMMI, RUP e ISO en Ingeniería de Software Minero. Rev. Inst. investig. Fac. minas metal cienc. geogr, 10(19), SEI Administrative Agent,(2009) Spanish Technical Report CMMI V 1 3 Standish Group International, Inc., (2013).Third Quarter Research Report.