Una taxonomía para la identificación de riesgos en los proyectos de desarrollo de software

Transcripción

1 Taxonomía de Riesgos 1 Una taxonomía para la identificación de riesgos en los proyectos de desarrollo de software Taxonomía de Riesgos en Proyectos de Ingeniería de Software. Blanca Estrada Renteríablancage@gmail.com Daniel Barajasalengot@hotmail.com Juana Bonillashadow.angel.rouse@gmail.com Roberto Rodrigo Muñoz Hernández rrmhdz@gmail.com Universidad Autónoma de Aguascalientes

2 Taxonomía de Riesgos 2 Abstract La Gestión de los Riesgos es esencial para asegurar la calidad y éxito de los proyectos de desarrollo de software. En muchas empresas de desarrollos de proyectos, una de las principales causas de los fracasos de los mismos es la falta de administrar y evaluar de manera clara y oportuna los riesgos que se tiene en cada uno de los proyectos de desarrollo de software que emprende. Existen numerosas empresas de desarrollo donde no se cuenta con modelos, herramientas y técnicas adecuadas para el manejo y medición del riesgo, debido a ello este artículo, desarrolla una taxonomía para la identificación de riesgos en proyectos de desarrollo de software, se basa en la taxonomía de identificación de riesgos del Instituto de Ingeniería de Software (SEI) de la Carnegie Mellon University de los Estados Unidos.

3 Taxonomía de Riesgos 3 Taxonomía de Riesgos en Proyectos de Ingeniería de Software. Introducción: Según el PMBOK (PMI, 2004), el Riesgo de un proyecto es un evento o condición incierto que, si se produce, tiene un efecto positivo o negativo sobre al menos uno de los objetivos del proyecto, en tiempo, coste, alcance o calidad. Un riesgo puede tener una o más causas y, si se produce, uno o más impactos. Datos de 12 reportes publicados entre 1994 y 2006, indican que más de 262 proyectos de software fueron cancelados en el mundo (Khled, 2008). En (Ramos, 2005) se recoge un estudio realizado por KLCI referente a la aplicación de la gestión de riesgos cuyo resultado arroja que el 3% no utilizaba ningún marco de gestión del riesgo, el 18 % utilizaba un marco propio para identificar sus riesgos, el 37% de los participantes habían utilizado algún marco informal, el 28% utilizaban procedimientos repetitivos y solo un 14% utilizaba un enfoque formal para identificar los riesgos. El riesgo del proyecto tiene su origen en la incertidumbre que está presente en todos los proyectos. Las organizaciones perciben los riesgos por su relación con las amenazas al éxito del proyecto, por lo que se debe desarrollar un enfoque consistente hacia el riesgo que cumpla con los requisitos de la organización, con una comunicación transparente acerca del riesgo y su tratamiento. La meta de la Gestión del riesgo es alejar la incertidumbre del riesgo y acercarla a la certeza total, tal y como se muestra en la siguiente figura.

4 Taxonomía de Riesgos 4 Aquí se presenta una taxonomía para identificar y evaluar los riesgos en proyectos de desarrollo de software. Descripción de e implementación de la Taxonomía Procesos de la Gestión de Riesgos El PMBOK (PMI, 2004) divide la Gestión del Riesgos en 6 procesos: 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 la Respuesta a los Riesgos, y Seguimiento y Control de Riesgos. En la figura siguiente se muestra el diagrama del proceso total de la Gestión de Riesgos.

5 Taxonomía de Riesgos 5 Esta taxonomía, similar a la del SEI, organiza las características del desarrollo de software en 3 niveles: Clase, Elemento y Atributo. La identificación de los riesgos puede basarse entonces en 4 grandes clases gestión de proyectos

6 Taxonomía de Riesgos 6 ingeniería del producto Ambiente de desarrollo restricciones del programa La clase gestión de proyectos comprende las áreas de conocimiento de la gestión de proyectos (gestión de integración, gestión de alcance, gestión del tiempo, gestión del costo, gestión de calidad, gestión de recursos humanos, gestión de las comunicaciones, gestión de riesgos y gestión de adquisiciones) involucradas en los grupos de procesos de iniciación, planificación, ejecución, seguimiento y control, y cierre del proyecto. Aborda las prácticas reconocidas que funcionan internacionalmente en la mayoría de los proyectos, además de la consecuente adaptación al desarrollo de software y a las normas establecidas en la UCI para ello en cuanto a los lineamientos de calidad que disponen artefactos y prácticas a usar en la gestión de proyectos, entre otras áreas de actuación. Los elementos y atributos de esta clase se pueden consultar en la tabla 1. Los riesgos asociados a esta clase están asociados a una inadecuada aplicación e integración de los grupos de procesos de gestión de proyecto (iniciación, planificación, ejecución, seguimiento y control, y cierre) para cumplir los objetivos del proyecto que comprenden los procesos organizados en las áreas de conocimiento. Pueden manifestarse mediante una incorrecta identificación de requerimientos; una inadecuada adaptación de las especificaciones, planes, y enfoques a las diferentes expectativas y preocupaciones de los diferentes involucrados; y al balancear incorrectamente las demandas de calidad, alcance, tiempo y costo. La clase ingeniería del producto hace referencia a las actividades de ingeniería de sistema e ingeniería de software involucradas en la creación de un sistema que satisfaga los requerimientos especificados y las expectativas del cliente. Estas actividades incluyen especificación y análisis de requerimientos de sistema (requerimientos no funcionales) y requerimientos del software (requerimientos funcionales), diseño e implementación del software, integración de componentes de software y hardware, y pruebas de software y de sistema. Los elementos de esta clase cubren las actividades tradicionales de ingeniería de software. Estas comprenden los factores técnicos asociados con la entrega del producto en sí, independiente de los procesos o herramientas

7 Taxonomía de Riesgos 7 utilizadas para producirlo o de las restricciones impuestas por recursos finitos o factores externos fuera del alcance del control del proyecto. La tabla 2 recoge los elementos y atributos de esta clase. Los riesgos de ingeniería del producto generalmente son el resultado de requerimientos que son técnicamente difíciles o imposible de implementar. A menudo están relacionados con la incapacidad de negociar la disminución de la complejidad de los requerimientos o de cambiar el presupuesto y cronograma. Son producto de un inadecuado análisis de los requerimientos o especificación de diseño; o de una baja calidad del diseño o especificación del código. La clase entorno de desarrollo comprende el entorno del proyecto y el proceso usado para la ingeniería de un producto de software. Incluye el proceso y los sistemas de desarrollo y el entorno de trabajo. Los elementos del ambiente están caracterizados por sus atributos. En la tabla 3 se muestran los elementos y atributos de esta clase. La clase restricciones del programa se refiere a los eventos externos al proyecto. Son los factores que pueden estar fuera del control del proyecto, pero pueden tener importantes efectos en su éxito o constituyen fuentes de riesgos sustanciales. La tabla 4 comprende los elementos y atributos de esta clase. Por ser los atributos el nivel inferior de la taxonomía, es decir, la parte más pequeña que aborda el desarrollo de software, se realizan sobre ellos las preguntas en un cuestionario asociado para la detección de los riesgos. El cuestionario contiene un conjunto de preguntas para hacer más fácil el proceso de identificación de riesgos de acuerdo a la taxonomía, que, aunque no cubre todos los elementos y atributos abarca la mayoría de ellos ofreciendo un punto de partida importante (Medina, 2009). Clase: Gestión de Proyectos Elemento Gestión de la integración del proyecto Atributo Desarrollar el acta constitutiva del proyecto Desarrollar el plan de gestión del proyecto Dirección y gestión de la ejecución del proyecto Supervisar y controlar el trabajo del proyecto

8 Taxonomía de Riesgos 8 Gestión del alcance del proyecto Gestión del tiempo del proyecto Gestión de la calidad del proyecto Gestión de las personas del proyecto Gestión de las comunicaciones Gestión de riesgos del proyecto Cierre del proyecto por fase Obtención de los requerimientos del proyecto Definición del alcance del proyecto Creación de un tablero de desglose del trabajo del proyecto Verificación del alcance del proyecto Control del alcance del proyecto Definición de las actividades del proyecto Establecimiento de la secuencia de actividades del proyecto Estimación de recursos de las actividades del proyecto Estimación de la duración de las actividades Desarrollo del cronograma del proyecto Planificación de la calidad del proyecto Realización del aseguramiento de la calidad del proyecto Planificación de los recursos humanos Adquisición del equipo de trabajo del proyecto Gestión del equipo del proyecto Identificación de los involucrados en el proyecto Planificación de cómo se lleva a cabo la comunicación del personal dentro del proyecto Canal de distribución de información del proyecto Información del rendimiento / estado del proyecto Planificación de la gestión de los riesgos Identificación de riesgos Realización de análisis cualitativo de los riesgos Realización de análisis cuantitativo de los riesgos Planificación de la respuesta a los riesgos Seguimiento y control de los riesgos Clase: Ingeniería del Producto Negocio Requerimientos Modelo de negocio Glosario de términos Estabilidad Completitud Claridad Validez Factibilidad

9 Taxonomía de Riesgos 9 Diseño Gestión de pruebas Codificación Arquitectura Precedentes Escalabilidad Funcionalidad Dificultad Interfaces Rendimiento Capacidad de probarse Restricciones de hardware Software de terceras partes Planificación de pruebas Diseño de casos de prueba Desarrollo de listas de chequeo Tratamiento de evaluaciones y elementos no conformes Pruebas de unidad Factibilidad de las pruebas de unidad Ambiente de integración y pruebas Integración del producto Factibilidad Pruebas Codificación / implementación Implementación y satisfacción de la seguridad Experiencia para implementar los niveles de seguridad Interfaz de usuario Especificaciones Definición de la arquitectura de software Arquitectura de información Clase: Entorno de desarrollo Proceso de desarrollo Sistemas de desarrollo Formalidad Adecuación Control del proceso Familiaridad Control del producto Capacidad Adecuación Usabilidad

10 Taxonomía de Riesgos 10 Entorno de trabajo Fiabilidad Soporte Entregas Herramientas de desarrollo Actitud ante la calidad Cooperación Comunicación Clase: Restricciones del programa Recursos Interfaces del programa Cronograma Personal Presupuesto Facilidades Cliente Integrador Proveedor Ejemplo de estructura y análisis de proceso

11 Taxonomía de Riesgos 11 Ejemplo de herramientas que automatizan el proceso Para la gestión de Riesgos en Ingeniería de Software tenemos tres programas que incluyen la evaluación del riesgo. - Realiza análisis de riesgo utilizando la simulación para mostrar múltiples resultados posibles en un modelo de hoja de cálculo, y le indica qué probabilidad hay de que se produzcan. Computa y controla matemática y objetivamente gran número de escenarios futuros posibles, y luego le indica las probabilidades y riesgos asociados con cada uno. Esto quiere decir que usted podrá decidir qué riesgos desea tomar y cuáles prefiere evitar, tomando la mejor decisión en situaciones de incertidumbre. Versión Demo y Paga. 2. SE Risk. - Contempla todos los aspectos del proceso de gestión de riesgos, desde la identificación inicial del riesgo, pasando por la evaluación y análisis, hasta la mitigación y el monitoreo, administrando los incidentes y garantizando la ejecución de las acciones y la debida comunicación. El software se adecúa en varios departamentos de la organización, lo que significa que la gestión de riesgo automáticamente estará presente en los proyectos, procesos y estrategias de la empresa; en el desarrollo de productos; medio ambiente, salud y seguridad; en las prácticas de gobernanza; en la gestión de TI; y muchos otros. Software de Paga, incluye demostración en línea de su uso. 3. TALAIA OpenPPM. Es una herramienta de gestión de carteras de proyectos para cualquier tipo de empresa. No tiene costo por licenciamiento y mantenimiento de software. Es un producto Open-Source. Su coste es muy inferior a las herramientas similares que existen en el mercado, tanto en su formato estándar (de implantación en la empresa) como en la solución como servicio ( SaaS ) que no requiere instalación. Incluye módulo de Gestión de riesgos, cambios y KPI s. Fáciles de usar y disponibles para su utilización a prueba o con un costo mínimo.

12 Taxonomía de Riesgos 12 Conclusiones La definición de una metodología de gestión de riesgos debe ser acorde al tamaño de la empresa, al nivel de madurez de la gestión de sus procesos, y al nivel de madurez de la gestión de proyectos propiamente. La gestión de riesgos brinda un mayor grado de credibilidad y profesionalismo a la gestión de proyectos frente a la gerencia y a los clientes, al brindar respuestas proactivas de manera sistemática frente a la incertidumbre. Referencias KHALED EL EMAM, A. G. K. A Replicated Survey of IT Software Project Failures. 2008, Disponible en: ieeexplore.ieee.org/iel5/52/ / pdf?arnumber= FERNANDEZ, A. Gestión de Riesgo como herramienta de toma de decisión para invertir en nuevos proyectos de tecnología en la investigación y la comunicación aplicados al e-business. Tesina. Universidad para la Cooperación Internacional. Maestría en Administración de Proyectos. Costa Rica, p.