Gestión del Riesgo e Ingeniería de Software basada en Componentes

El riesgo afecta a los futuros acontecimientos. Cuando se considera el riesgo en el contexto de la ingeniería del software, los tres pilares conceptuales de Charette se hacen continuamente evidentes. El futuro es lo que nos preocupa, ¿qué riesgos podrían hacer que nuestro proyecto fracasará? El cambio es nuestra preocupación ¿cómo afectarán los cambios en los requisitos del cliente, en las tecnologías de desarrollo, en los ordenadores a las que van dirigidas, el proyecto y todas las entidades relacionadas con él, al cumplimiento de la planificación temporal y al éxito en general? Para terminar, nos enfrentamos con elecciones ¿qué métodos y herramientas deberíamos emplear, cuánta gente debería estar implicada, qué importancia hay que darle a la calidad? .

Peter Drucker dijo una vez: "Mientras que es inútil intentar eliminar el riesgo y cuestionable el poder minimizarlo, es esencial que los riesgos que se tomen sean los riesgos adecuados". Antes de poder identificar los "riesgos adecuados" que se pueden tomar en un proyecto de software, es importante poder identificar todos los riesgos que sean obvios a jefes de proyectos y profesionales del software.

Estrategias de Riesgo Reactivas y Proactivas

Reactiva: supervisa el proyecto en prevención de posibles riesgos. Los recursos se ponen aparte, en caso de que pudieran convertirse en problemas. Lo mas frecuente es que el equipo de software no haga nada respecto a los riesgos hasta que algo va mal.

Proactiva: empieza mucho antes de que comiencen los trabajos técnicos. Se identifican los riesgos potenciales, se valoran su probabilidad y su impacto y se establece una prioridad según su importancia. Después el equipo de software establece un plan para controlar el riesgo.

Riesgos del Software

El riesgo siempre implica dos características:

Incertidumbre: el acontecimiento que caracteriza al riego puede o no ocurrir.

Pérdida: si el riesgo se convierte en una realidad, ocurrirán consecuencias no deseadas ó pérdidas.

Cuando se analizan los riegos es importante cuantificar el nivel de incertidumbre y grado de pérdida asociados a cada riego. Para hacerlo se consideran diferentes categorías de riesgos:

• Riesgos del proyecto: si se hacen realidad , es posible que la planificación temporal del proyecto se retrase y que los costos aumenten. Identifican problemas potenciales de presupuesto, calendario, personal, recursos,etc.

• Riesgos técnicos: amenazan la calidad y la planificación temporal del software (problemas de diseño, implementación, interfaz, verificación, mantenimiento, ambigüedades de especificaciones, incertidumbres técnica, etc).

• Riesgos del negocio: amenazan la viabilidad del soft a construir. A menudo ponen en peligro el proyecto o el producto.

Otra categorización general de los riesgos ha sido propuesta por Charette:

Los riesgos conocidos: son todos aquellos que se pueden descubrir después de una cuidadosa evaluación del plan del proyecto, del entorno técnico y comercial en el que se desarrolla el proyecto y otras fuentes de información fiables (por ejemplo: fechas de entrega poco realistas, falta de especificación de requisitos o de ámbito del software, o un entorno pobre de desarrollo). 

Los riesgos predecibles: se extrapolan de la experiencia en proyectos anteriores (por ejemplo: cambio de personal, mala comunicación con el cliente, disminución del esfuerzo del personal a medida que atienden peticiones de mantenimiento). 

Los riesgos impredecibles: son el comodín de la baraja. Pueden ocurrir, pero son extremadamente difíciles de identificar por adelantado.

Identificación de Riesgos

La principal técnica para identificar los riesgos es la lista de comprobación de riesgos. Esta lista se construye a partir de información histórica. La ventaja es que permite una identificación de riesgos rápida y relativamente sencilla, pero la desventaja es que es prácticamente imposible tener una lista que incluye todos los posibles riesgos en un proyecto software. Los riesgos más habituales en proyectos software son los siguientes:

• Cambio de requisitos
• Meticulosidad en requisitos o de los desarrolladores
• Escatimar en la calidad
• Planificaciones demasiado optimistas
• Diseño inadecuado
• Síndrome de la panacea (“esta herramienta ahorrará la mitad del trabajo”)
• Desarrollo orientado a la investigación (proyectos muy novedosos, más propios de investigación que de desarrollo)
• Personal mediocre
• Errores en la contratación
• Diferencias con los clientes

Proyección del Riesgo

La proyección del riesgo, también denominada estimación del riesgo, intenta medir cada riesgo de dos maneras: la probabilidad de que el riesgo sea real y las consecuencias de los problemas asociados con el riesgo, si ocurriera. El jefe del proyecto, junto con otros gestores y personal técnico, realiza cuatro actividades de proyección del riesgo: 

1. Establecer una escala que refleje la probabilidad percibida del riesgo
2. Definir las consecuencias del riesgo
3. Estimar el impacto del riesgo en el proyecto y en el producto
4. Apuntar la exactitud general de la proyección del riesgo de manera que no haya confusiones.

Reducción, Supervisión y Gestión del riesgo

Todas las actividades de análisis de riesgo tienen un solo objetivo: ayudar al equipo del proyecto a desarrollar una estrategia para tratar los riesgos. Una estrategia eficaz debe considerar tres aspectos: 

• Evitar el riesgo.
• Supervisar el riesgo.
• Gestión del riesgo y planes de contingencia.

Si un equipo de software adopta un enfoque proactivo frente al riesgo, evitarlo es siempre la mejor estrategia. Esto se consigue desarrollando un plan de reducción del riesgo.

A medida que progresa el proyecto comienzan las actividades de supervisión del riesgo. El jefe del proyecto supervisa factores que pueden proporcionar una indicación de si el riesgo se está haciendo más o menos probable.

La gestión del riesgo y los planes de contingencia asumen que los esfuerzos de reducción han fracasado y que el riesgo se ha convertido en una realidad.

Ingeniería de Software basada en Componentes.

El desarrollo de software basado en componentes permite reutilizar piezas de código pre-elaborado que permiten realizar diversas tareas, conllevando a diversos beneficios como las mejoras a la calidad, la reducción del ciclo de desarrollo y el mayor retorno sobre la inversión.

La reutilización de software es un proceso de la Ingeniería de Software que conlleva al uso recurrente de activos de software en la especificación, análisis, diseño, implementación y pruebas de una aplicación o sistema de software.

Un componente es una unidad de composición de aplicaciones software, que posee un conjunto de interfaces y un conjunto de requisitos, y que ha de poder ser desarrollado, adquirido, incorporado al sistema y compuesto con otros componentes de forma independiente, en tiempo y espacio.

Proceso de la Ingeniería de Software basada en Componentes (ISBC).

El proceso de la ISBC, identifica los componentes candidatos y cualifica la interfaz de cada componente, adapta los componentes para eliminar las equivocaciones arquitectónicas, ensambla los componentes en un estilo arquitectónico seleccionado y actualiza los componentes conforme los requisitos del sistema cambian. Desataca las pistas paralelas en las cuales la ingeniería del software se lleva a cabo de manera concurrente con el desarrollo basado en componentes.

La Ingeniería del Dominio.

Crea un modelo del dominio de aplicación que se utiliza como base para realizar los requisitos del usuario ene l flujo de ingeniería del software, la finalidad es identificar, construir, catalogar y diseminar un conjunto de componentes de software que sean aplicables para el software existente y futuro en un dominio de aplicación particular. trata de encontrar aspectos comunes entre los sistemas para identificar los componentes que sea posible aplicar en muchos sistemas y para identificar familias de programas que se posiciones para sacar la mayor ventaja de dichos componentes.

Desarrollo basado en componentes

El modelo de desarrollo basado en componentes conduce a la reutilización del software, y la reutilización proporciona beneficios a los ingenieros de software. El ensamblaje de componentes lleva a una reducción del 70 % del ciclo de desarrollo un 84% del coste del proyecto y un índice de productividad del 26.2. No hay duda que el ensamblaje de componentes proporciona ventajas significativas para los ingenieros del software.

El proceso unificado de desarrollo de software representa un número de modelos de desarrollo basado en componentes que han sido propuestos en la industria. El lenguaje de modelado unificado define los componentes. Utilizando una combinación del desarrollo incremental e interactivo, el proceso unificado define la función del sistema aplicando un enfoque basado en escenarios.

El desarrollo de software basado en componentes se ha convertido actualmente en uno de los mecanismos más efectivos para la construcción de grandes sistemas y aplicaciones de software.