Universidad Tecnolgica de Panam Facultad de Ingeniera en Sistemas Computacionales Ingeniera de Software I

Tema: Planificacin de Proyecto de Software

Profesora:

Grupo: 1LS-122

Fecha de 25 de Octubre de 2013

Introduccin

Un riesgo es aquel factor que influye negativamente en el xito del proyecto. El riesgo en un proyecto de desarrollo de software incluye componentes tcnicos y de conocimiento del mismo. Los temas de naturaleza organizacional constituyen los factores dominantes de los riesgos del proyecto, a la vez que son los que se tratan satisfactoriamente en menos de la tercera parte de los proyectos de desarrollo, entre ellos los conflictos entre departamentos, entre usuarios, el cambio del responsable ejecutivo del proyecto, volatilidad del personal, nmero de unidades de la organizacin implicadas y proyectos que involucran a mltiples proveedores. En este trabajo estudiaremos los siguientes factores que afectan la produccin y el desarrollo de un proyecto de software.

Qu es Riesgo? Es la vulnerabilidad ante esto un posible potencial de perjuicio o dao para las unidades o personas, organizaciones o entidades. Cuanto mayor es la vulnerabilidad mayor es el riesgo, pero cuanto ms factible es el perjuicio o dao, mayor es el peligro. Por tanto, el riesgo se refiere slo a la terica "posibilidad de dao" bajo determinadas circunstancias, mientras que el peligro se refiere slo a la terica "probabilidad de dao" bajo esas circunstancias. Se han producido amplios debates sobre la definicin adecuada para riesgo de software, y hay acuerdo comn en que el riesgo siempre implica dos caractersticas: Incertidumbre: el acontecimiento que caracteriza al riesgo puede o no puede ocurrir; por ejemplo, no hay riesgos de un 100 por ciento de probabilidad. Prdida: Si el riesgo se convierte en una realidad, ocurrirn consecuencias no deseadas o prdidas. Suele ser comn el confundir preocupaciones, riesgos y problemas: mientras que una preocupacin es cualquier situacin sobre la cual existen dudas en algn determinado contexto y que, por lo tanto, ser evaluada como un posible riesgo, un problema es un riesgo que efectivamente, se ha producido.

Preocupacin

Preocupacin

Preocupacin

Propsito del Plan de gestin de riesgos

El propsito del plan es identificar los riesgos que se puedan presentar en el desarrollo del proyecto, analizarlos, calcular la exposicin y en base a ello poder priorizarlos, para establecer estrategias de control y resolucin, que permitan ejercer una correcta supervisin de los mismos. Es por esta razn que, para que
4

un proyecto de desarrollo pueda llevarse a cabo dentro de los tiempos establecidos y los costos previstos, los riesgos deben ser identificados y controlados, es decir se debe realizar un adecuado Anlisis y Gestin de Riesgos.

Riesgos del Software

Aunque ha habido amplios debates sobre la definicin adecuada para riesgo de software, hay acuerdo comn en que el riesgo siempre implica dos caractersticas: 1. Incertidumbre: El acontecimiento que caracteriza al riesgo puede o no puede ocurrir; por ejemplo, no hay riesgo de un 100% de probabilidad (ya que un riesgo del 100% es una limitacin del proyecto). 2. Prdida: Si el riesgo se convierte en una realidad, ocurrirn consecuencias no deseadas o prdidas.

Riesgos del Proyecto

Amenazan al plan del proyecto, es decir, si los riesgos del proyecto se hacen realidad, es probable que la planificacin temporal del proyecto se retrase y que los costos aumenten. Los riesgos del proyecto identifican:

Problemas potenciales de presupuesto Planificacin temporal Personas (Asignacin y organizacin) Recursos Cliente, requerimientos y su impacto en el proyecto software La complejidad del proyecto Tamao y grado de incertidumbre estructural

Riesgos Tcnicos
Amenazan la calidad y la planificacin temporal del software que hay que producir. Si un riesgo se convierte en realidad, la implementacin puede llegar a ser difcil o imposible. Los riesgos tcnicos identifican problemas potenciales de:

Diseo Implementacin De interfaz Verificacin Mantenimiento Las ambigedades de especificaciones Tecnologas

Los riesgos tcnicos ocurren porque el problema es ms difcil de resolver de lo que pensbamos.

Riesgos del Negocio

Amenazan la viabilidad del software a construir. Los riesgos del negocio a menudo ponen en peligro el proyecto o producto. Los candidatos para los cinco principales riesgos del negocio son:

Construir un producto o sistema excelente que no quiere nadie en realidad (Riesgo de Mercado).

Construir un producto que no encaja en la estrategia comercial general de la compaa (Riesgo Estratgico).

Construir un producto que el departamento de ventas no sabe cmo vender.

Perder el apoyo de una gestin experta debida a cambios de enfoque o a cambios de personal (Riesgo de Direccin).

Perder presupuesto o personal asignado (Riesgo de Presupuesto).

Es

extremadamente

importante

recalcar

que

no

siempre

funciona

una

categorizacin tan sencilla. Algunos riesgos pueden pertenecer a ms de una categora o simplemente imposibles de predecir.

Identificacin y clasificacin del Riesgo

La identificacin del riesgo es un intento sistemtico para especificar las amenazas al plan de proyecto (estimaciones, planificacin temporal, cargo de recursos, etc.). Identificando los riesgos conocidos y predecibles, el gestor del proyecto da un paso adelante para evitarlos cuando sea posible y controlarlos cuando sea necesario. Existen dos tipos diferenciados de riesgos para cada categora: 1. Riesgos Genricos: Son una amenaza potencial para todos los proyectos de software. 2. Riesgos especficos: Los riesgos especficos de producto slo los pueden identificar los que tienen una clara visin de la tecnologa, el personal y el entorno especfico del proyecto en cuestin, entre los que estn:
o

Tamao del producto: Riesgos asociados con el tamao general del software a construir o a modificar.

Impacto en el negocio: Riesgos asociados con las limitaciones impuestas por la gestin o por el mercado.

Caractersticas del cliente: Riesgos asociados con la sofisticacin del cliente y la habilidad del desarrollador para comunicarse con el cliente en los momentos oportunos.

Definicin del proceso: Riesgos asociados con el grado de definicin del proceso del software y su seguimiento para la organizacin de desarrollo.

Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de las herramientas que se van a emplear en la construccin del producto.
7

Tecnologa a construir: Riesgos asociados con la complejidad del sistema a construir y la tecnologa de punta que contiene el sistema.

Tamao y experiencia de la plantilla: Riesgos asociados con la experiencia tcnica y de proyectos de los ingenieros de sw que van a realizar el trabajo.

Componentes y controladores del riesgo En el contexto de este estudio, los componentes del riesgo se definen de la siguiente manera:

Riesgo de rendimiento: el grado de incertidumbre con el que el producto encontrar sus requerimientos y se adecue para su empleo pretendido.

Riesgo de costo: El grado de incertidumbre que mantendr el presupuesto del proyecto.

Riesgo de soporte: El grado de incertidumbre de la facilidad del software. para corregirse, adaptarse y ser mejorado.

Riesgo de la planificacin temporal: El grado de incertidumbre con que se podr mantener la planificacin temporal y de que el producto se entregue a tiempo.

El impacto de cada controlador de riesgo en el componente de riesgo se divide en cuatro categoras de impacto: 1.- Despreciable 2.- Marginal 3.- Crtico 4.- Catastrfico

El siguiente cuadro muestra un ejemplo que

indica las consecuencias

potenciales de errores (filas etiquetadas con 1) o la imposibilidad de conseguir el producto deseado (filas etiquetadas con 2). La categora de impacto es elegida basndose en la caracterizacin que mejor encaja con la descripcin de la tabla
8

Rendimiento

Soporte

Costo

Planificacin Temporal

Catastrfico

Crtico

Marginal

Despreciable

1 Dejar de cumplir los Malos resultados en un aumento requerimientos provocara fracaso de costos y retrasos de la de la misin planificacin temporal con cifras que superan los costos planeados 2 Degradacin El software no Recortes Fecha de significativa responde o no financieros entrega para no poder admite soporte significativos, inalcanzable. alcanzar el presupuestos rendimiento excedidos. tcnico. 1 Dejar de cumplir los Malos resultados en retrasos requerimientos degradara el operativos y/o aumento de rendimiento del sistema hasta un costos con un valor esperado. punto donde el xito de la misin es cuestionable. 2 Alguna Pequeos Algunos Posibles disminucin en retrasos en recortes de los retrasos de la el rendimiento modificaciones recursos fecha de la tcnico. de software. financieros, entrega posibles excesos del presupuesto. 1 Dejar de cumplir los Los costos, impactos y/o requerimientos provocara la retrasos recuperables de la degradacin de la misin planificacin temporal con un secundaria. valor estimado 2 De mnima a EL soporte del Recursos Planificacin pequea software no financieros temporal reduccin en el responde. suficientes realista, rendimiento alcanzable tcnico. 1 Dejar de cumplir los Los errores provocan impactos requerimientos provocara mnimos en el costo y/o inconvenientes o impactos no planificacin temporal con un operativos. valor esperado de menor

2 No hay Software fcil Posible reduccin en el de dar soporte. supervit de rendimiento presupuesto. tcnico.

Fecha de entrega fcilmente alcanzable.

Riesgos relacionados con el cliente

No todos los clientes son iguales. Pressman y Herron tratan este aspecto cuando dicen: Los clientes tienen diferentes necesidades. Algunos saben lo que quieren; otros saben lo que no quieren. Algunos estn deseando saber todos los detalles, mientras que otros se quedan satisfechos con vagas promesas. Los clientes tienen diferentes personalidades. Algunos disfrutan siendo clientes (la tensin, la negociacin, las recompensas psicolgicas de un buen producto). Otros preferiran no ser clientes en absoluto. Algunos aceptaran felizmente cualquier cosa que se les entregara y le sacaran el mejor provecho a un producto pobre. Otros se quejarn amargamente cuando les falte calidad; algunos darn las gracias cuando la calidad es buena; unos pocos se quejarn por todo. Los clientes tambin tienen varios tipos de asociaciones con sus suministradores. Algunos conocen bien a sus proveedores y sus productos; otros no se han visto nunca las caras y se comunican siempre mediante correspondencia escrita y algunas llamadas telefnicas breves. Los clientes se contradicen a menudo. Quieren todo para ayer y gratis. A menudo, el producto se ve cogido entre las propias contraindicaciones del cliente. Un "mal" cliente puede tener un profundo impacto en la habilidad del equipo de software para completar el proyecto a tiempo y dentro de presupuesto. Un mal cliente representa una amenaza significativa al plan del proyecto y un sustancial riesgo para el jefe del proyecto. La siguiente lista de comprobacin de elementos de riesgo identifica riesgos genricos asociados con diferentes clientes: Ha trabajado con el cliente anteriormente? Tiene el cliente una idea formal de lo que se requiere? Se ha molestado en escribirlo?

10

Aceptar el cliente gastar su tiempo en reuniones formales de requisitos para identificar el mbito del proyecto? Est dispuesto el cliente a establecer una comunicacin fluida con el desarrollador? Est dispuesto el cliente a participar en las revisiones? Es sofisticado tcnicamente el rea del producto? Est dispuesto el cliente a dejar a su personal hacer el trabajo? Es decir, resistir la tentacin de mirar por encima del hombro durante el trabajo tcnico?

Entiende el cliente el proceso del software?

Si la respuesta a alguna de estas preguntas es "no", se debera hacer una investigacin ms profunda para valorar el potencial de riesgo.

Riesgos del proceso

Si el proceso del software no est bien definido; si el anlisis, diseo y pruebas se realizan sobre la marcha; si la calidad es un concepto que todo el mundo estima importante, pero por la que nadie acta de manera tangible para alcanzarla, entonces el proyecto est en peligro. Las siguientes preguntas se han extrado sobre la evaluacin de la ingeniera del software desarrollado por R. S. Pressman & Associates. Inc. Las preguntas se han adaptado del cuestionario de evaluacin del proceso del software del Instituto de Ingeniera del Software (IIS). Aspectos del proceso Apoyan sus gestores senior unas normas escritas que hagan hincapi en la importancia de un proceso estndar para el desarrollo del software? Ha desarrollado su organizacin una descripcin escrita del proceso del software a emplear en este proyecto?

11

Estn de acuerdo los miembros del personal con el proceso del software tal y como est documentado y estn dispuestos a usarlo? Se emplea este proceso del software para otros proyectos? Ha desarrollado o adquirido su organizacin cursos de formacin de ingeniera del software para jefes de proyecto y personal tcnico? Se ha proporcionado una copia de los estndares de ingeniera del software publicados a cada desarrollador y gestor de software? Se han desarrollado diseos de documentos y ejemplos para todas las entregas definidas como parte del proceso del software? Se llevan a cabo regularmente revisiones tcnicas formales de las especificaciones de requisitos, diseo y cdigo? Se llevan a cabo regularmente: revisiones tcnicas de los procedimientos de prueba y de los casos de prueba? , Se documentan todos los resultados de las revisiones tcnicas, incluyendo los errores encontrados y recursos empleados? Existe algn mecanismo para asegurarse de que el trabajo realizado en un proyecto se ajusta a los estndares de ingeniera del software? Se emplea una gestin de configuracin para mantener la consistencia entre los requisitos del sistema/software, diseo, cdigo y casos de prueba? Hay algn mecanismo de control de cambios de los requisitos del cliente que impacten en el software? Hay alguna declaracin de trabajo documentada, una especificacin de requisitos software y un plan de desarrollo del software para cada subcontratacin?

Se sigue algn procedimiento para hacer un seguimiento y revisar el rendimiento de las subcontraciones?

Aspectos tcnicos Se emplean tcnicas de especificacin de aplicaciones para ayudar en la comunicacin entre el cliente y el desarrollador? Se emplean mtodos especficos para el anlisis del software?
12

Emplea un mtodo especfico para el diseo de datos y arquitectnico? Est escrito su cdigo en ms de un 90 por ciento en lenguaje de alto nivel? Se han definido y empleado reglas especficas para la documentacin del cdigo? Emplea mtodos especficos para el diseo de casos de prueba? Se emplean herramientas de software para apoyar la planificacin y el seguimiento de las actividades? Se emplean herramientas de software de gestin de configuracin para controlar y seguir los cambios a lo largo de todo el proceso del software? Se emplean herramientas de software para apoyar los procesos de anlisis y diseo del software? Se emplean herramientas para crear prototipos software? Se emplean herramientas de software para dar soporte a los procesos de prueba? Se emplean herramientas de software para soportar la produccin y gestin de la documentacin? Se han establecido mtricas de calidad para todos los proyectos de software? Se han establecido mtricas de productividad para todos los proyectos de software?

Si la mayora de las cuestiones anteriores se han respondido negativamente, el proceso del software es dbil y el riesgo es alto.

Riesgos tecnolgicos
Alcanzar los lmites de la tecnologa es un reto excitante. Es el sueo de casi todos los tcnicos, porque fuerza al profesional a emplear su talento al mximo. Pero tambin es muy arriesgado. La ley de Murphy parece mantener su imperio en esta parte del universo del desarrollo, haciendo extremadamente difcil predecir los riesgos, y mucho menos hacer ningn plan sobre ellos. La siguiente lista de

13

comprobacin de elementos de riesgo identifica riesgos genricos asociados con la tcnica a construir. Es nueva para su organizacin la tecnologa a construir? Demandan los requisitos del cliente la creacin de nuevos algoritmos o tecnologa de entrada o salida? El software interacta con hardware nuevo o no probado? Interacta el software a construir con productos software suministrados por el vendedor que no se hayan probado? Interacta el software a construir con un sistema de base de datos cuyo funcionamiento y rendimiento no se han comprobado en esta rea de aplicacin? Demandan los requisitos del producto una interfaz de usuario especial? Demandan los requisitos del producto la creacin de componentes de programacin distintos de; los que su organizacin haya desarrollado hasta ahora? Demandan los requisitos el empleo de nuevos mtodos de anlisis, diseo o pruebas? Demandan los requisitos el empleo de mtodos de 'desarrollo del software no convencionales, tales como los mtodos formales, enfoques basados .... En IA y redes neuronales? Imponen excesivas restricciones de rendimiento los requisitos del producto? No est seguro el cliente de que la funcionalidad pedida sea factible?

Si la respuesta a alguna de estas preguntas es afirmativa, se debera realizar una investigacin ms profundidad para valorar el riesgo potencial.

Riesgos del entorno de desarrollo

Si a un carpintero se le pidiera que construyera un mueble de calidad con una simple sierra de mano, se dudara de la calidad del producto final. Las

14

herramientas inapropiadas o ineficaces pueden estropear los esfuerzos de incluso un experimentado profesional.

El entorno de ingeniera del software soporta al equipo del proyecto. Al proceso y al producto. Pero si el entono es malo. Puede ser una fuente de riesgos significativa. La siguiente lista de comprobacin de elementos de riesgo identifica riesgos genricos asociados como el entorno de desarrollo: Tenemos disponible una herramienta de gestin de proyectos de software? Tenemos disponible una herramienta de gestin del proceso del software? Existen herramientas de anlisis y diseo disponibles? Proporcionan las herramientas de anlisis y diseo, mtodos apropiados para el producto a construir? Hay disponible? compiladores o generadores de cdigo apropiados para el producto a construir? Hay disponibles herramientas de pruebas apropiadas para el producto a construir? Tenemos disponibles herramientas de gestin de configuracin software? Hace uso el entorno de bases de datos o informacin almacenada? Estn todas las herramientas de software integradas entre s? Se ha formado a los miembros del equipo del proyecto en todas las herramientas? Existen expertos disponibles para responder todas las preguntas que surjan sobre las herramientas? Es adecuada la ayuda en lnea y la documentacin de las herramientas?

Si se ha contestado negativamente a la mayora de las preguntas anteriores, el entorno de desarrollo es dbil y el riesgo es alto.

15

Riesgos asociados con el tamao de la plantilla de personal y su experiencia:

Bohem sugiere las siguientes cuestiones para valorar los riesgos asociados con el tamao de la plantilla de personal y su experiencia: Disponemos de la mejor gente? Tiene el personal todos los conocimientos adecuados? Tenemos suficiente personal? Se ha asignado al personal para toda la duracin del proyecto? Habr parte del personal del proyecto que trabaje slo durante parte de l? Dispone el personal de las expectativas correctas sobre el trabajo? Ha recibido el personal la formacin adecuada? Ser mnimo el movimiento del personal para permitir la continuidad?

Si la respuesta a alguna de estas preguntas es "no", se debera hacer una investigacin ms profunda para valorar el potencial de riesgo.

Proyeccin del riesgo

La proyeccin del riesgo, tambin denominada estimacin 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 tcnico, realiza cuatro actividades de proyeccin del riesgo: Establecer una escala que refleje la probabilidad percibida del riesgo; Definir las consecuencias del riesgo; Estimar el impacto del riesgo en el proyecto y en el producto. Apuntar la exactitud general de la proyeccin del riesgo de manera que no haya confusiones.

16

Evaluacin del impacto del riesgo

Tres factores afectan a las consecuencias probables de un riesgo, si ocurre: su naturaleza, su alcance y cuando ocurre. La naturaleza del riesgo indica los problemas probables que aparecern si ocurre. Por ejemplo, una interfaz externa mal definida para el hardware del cliente (un riesgo tcnico) impedir un diseo y pruebas tempranas y probablemente lleve a problemas de integracin ms adelante en el proyecto. El alcance de un riesgo combina la severidad (cmo de serio es el problema?) con su distribucin general (qu proporcin del proyecto se ver afectado y cuantos clientes se vern perjudicados?). Finalmente, la temporizacin de un riesgo considera cundo y por cunto tiempo se dejar sentir el impacto. En la mayora de los casos, un jefe de proyecto prefiere las "malas noticias" cuanto antes, pero en algunos casos, cuanto ms tarden, mejor. Volviendo una vez ms al enfoque del anlisis de riesgo propuesto por las Fuerzas Areas de Estados Unidos, se recomiendan los siguientes pasos para determinar las consecuencias generales de un riesgo: 1. Determinar la probabilidad media de que ocurra un valor para cada componente de riesgo. 2. Empleando la Figura 1, determinar el impacto de cada componente basndose en los criterios mostrados. 3. Completar la tabla de riesgo y analizar los resultados como se describe en las secciones precedentes. El equipo del proyecto debera volver a la tabla de riesgo a intervalos regulares, volver a evaluar cada riesgo para determinar qu nuevas circunstancias hayan podido cambiar su impacto o probabilidad. Como consecuencia de esta actividad, puede ser necesario aadir nuevos riesgos a la tabla, quitar algunos que ya no sean relevantes y cambiar la posicin relativa de otros.

Evaluacin del riesgo

En este punto del proceso de gestin del riesgo, hemos establecido un conjunto de ternas de la forma: [ri, li, xi] donde r es el riesgo, l la probabilidad del riesgo y x
17

el impacto del riesgo. Durante la evaluacin del riesgo, se sigue examinando la exactitud de las estimaciones que fueron hechas durante la proyeccin del riesgo, se intenta dar prioridades a los riesgos que no se haban cubierto y se empieza a pensar las maneras de controlar y/o impedir los riesgos que sean ms probables que aparezcan. Para que sea til la evaluacin, se debe definir un nivel de referencia de riesgo. Para la mayora de los proyectos, los componentes de riesgo estudiados anteriormente -rendimiento, coste, soporte y planificacin temporal- tambin representan niveles de referencia de riesgos. Es decir. Hay un nivel para la degradacin del rendimiento, exceso de coste, dificultades de soporte o retrasos de la planificacin temporal (o cualquier combinacin de los cuatro) que provoquen que se termine el proyecto. Si una combinacin de riesgos crea problemas de manera que uno o ms de estos niveles de referencia se excedan, se parar el trabajo. En el contexto del anlisis de riesgos del software, un nivel de referencia de riesgo tiene un solo punto, denominado punto de referencia o punto de ruptura, en el que la decisin de seguir con el proyecto o dejarlo (los problemas son demasiado graves) son igualmente aceptables. Si una combinacin de riesgos lleva a problemas que provocan excesos de coste y retrasos de la planificacin temporal, habr un nivel representado por la curva en la figura que (cuando se exceda) provocar la terminacin del proyecto (la regin sombreada). En el punto de referencia, las decisiones de seguir o abandonar son igualmente vlidas. En realidad, el nivel de referencia puede raramente representarse como una lnea ntida en el grfico. En la mayora de los casos es una regin en la que hay reas de incertidumbre (ej.: intentar predecir una decisin de gestin basndose en la combinacin de valores de referencia es a menudo imposible). Por tanto, durante la evaluacin del riesgo, se realizan los siguientes pasos: 1. Definir los niveles de referencia de riesgo para el proyecto. 2. Intentar desarrollar una relacin entre cada [ri, li, xi] y cada uno de los niveles de referencia.
18

3. Predecir el conjunto de puntos de referencia que definan la regin de abandono, limitado por una curva o reas de incertidumbre. 4. Intentar predecir cmo afectarn las combinaciones compuestas de riesgos a un nivel de referencia. 5.- Reduccin, supervisin y gestin del riesgo

Todas las actividades de anlisis de riesgo presentadas hasta ahora 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. Gestin 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 reduccin del riesgo. Por ejemplo, asuma que se ha detectado mucha movilidad de la plantilla como un riesgo del proyecto, n. Basndose en casos anteriores y en la intuicin de gestin, la probabilidad, li, de mucha movilidad se estima en un 0.70 (70 por ciento, bastante alto) y el impacto, si est previsto que tenga un impacto crtico en el coste y planificacin temporal del proyecto. Para reducir el riesgo, la gestin del proyecto debe desarrollar una estrategia para reducir la movilidad. Entre los pasos que se pueden tomar estn estos: Reunirse con la plantilla actual y determinar las causas de la movilidad (por ej.: malas condiciones de trabajo, salarios bajos, mercado laboral competitivo). Actuar para reducir esas causas que estn al alcance del control de gestin antes de que comience el proyecto

19

Una vez que comienza el proyecto, asuma que habr movilidad y desarrolle tcnicas para asegurarse la continuidad cuando se vaya la gente.

Organice los equipos del proyecto de manera que la informacin sobre cada actividad de desarrollo est ampliamente dispersa. Defina estndares de documentacin y establezca mecanismos para asegurarse de que los documentos se cumplimenten puntualmente.

Convoque reuniones de revisin de todo el trabajo de manera que ms de una persona a la vez est familia rizada con el trabajo. Defina un miembro de la plantilla como reserva para cada tcnico crtico. A medida que progresa el proyecto comienzan las actividades de supervisin del riesgo. El jefe del proyecto supervisa factores que pueden proporcionar una indicacin de si el riesgo se est haciendo ms o menos probable. En el caso de gran movilidad del personal, se pueden supervisar los siguientes factores:

Actitud general de los miembros del equipo basndose en las presiones del proyecto El grado de compenetracin del equipo. Relaciones interpersonales entre los miembros del equipo. La disponibilidad de empleo dentro y fuera de la compaa.

Adems de supervisar los factores apuntados anteriormente, el jefe del proyecto debera supervisar tambin la efectividad de los pasos de reduccin del riesgo. Por ejemplo. Un paso de reduccin del riesgo apuntado anteriormente instaba a la definicin de "estndares de documentacin y mecanismos para asegurarse de que los documentos se cumplimenten puntualmente". Este es un mecanismo para asegurarse la continuidad, en caso de que un individuo crtico abandone el proyecto. El jefe del proyecto debera comprobar los documentos cuidadosamente para asegurarse de que son vlidos y de que cada uno contiene la informacin
20

necesaria en caso de que un miembro nuevo se viera obligado a unirse al proyecto. La gestin del riesgo y los planes de contingencia asumen que los esfuerzos de reduccin han fracasado y que el riesgo se ha convertido en una realidad. Continuando con el ejemplo, suponga que el proyecto va muy retrasado y un nmero de personas anuncia que se va. Si se ha seguido la estrategia de reduccin. Tendremos reservas. La informacin est documentada y el conocimiento del proyecto se ha dispersado por todo el equipo. Adems. El jefe del proyecto puede temporalmente volver a reasignar los recursos (y reajustar la planificacin temporal del proyecto) desde las funciones que tienen todo su personal, permitiendo a los recin llegados que deben unirse al equipo que vayan "cogiendo el ritmo". A los individuos que se van se les pide que dejen lo que estn haciendo y dediquen sus ltimas semanas a "transferir sus conocimientos". Esto podra incluir la adquisicin de conocimientos por medio de vdeos, el desarrollo de "documentos con comentarios" y/o reuniones con otros miembros del equipo que permanezcan en el proyecto. Es importante advertir que los pasos RSGR provocan aumentos del coste del proyecto. Por ejemplo, emplear tiempo en conseguir una reserva de cada tcnico crtico cuesta dinero. Parte de la gestin de riesgos es evaluar cuando los beneficios obtenidos por los pasos RSGR superan los costes asociados con su implementacin. En esencia, quien planifique el proyecto realiza el clsico anlisis coste/beneficio. Si los procedimientos para evitar el riesgo de gran movilidad aumentan el coste y duracin del proyecto aproximadamente en un 15 por ciento, pero el factor coste principal es la copia de seguridad (backup), el gestor puede decidir no implementar este paso. Por otra parte si los pasos para evitar el riesgo llevan a una proyeccin de un aumento de costes del 5 por ciento y de la duracin en un 3 por ciento, la gestin probablemente lo haga. Para un proyecto grande se pueden identificar unos 30 o 40 riesgos. Si se pueden identificar entre tres y siete pasos de gestin de riesgo para cada uno, la gestin del riesgo puede convertirse en un proyecto por s misma. Por este motivo,

21

adaptamos la regla de Pareto 80-20 al riesgo del software. La experiencia dice que el 80 por ciento del riesgo total de un proyecto (p. ej.: el 80 por ciento del potencial de fracaso del proyecto) se debe solamente al 20 por ciento de los riesgos identificados. El trabajo realizado durante procesos de anlisis de riesgo anteriores ayudar al jefe de proyecto a determinar qu riesgos pertenecen a ese 20 por ciento. Por este motivo, algunos de los riesgos identificados, valorados y previstos pueden no pasar por el plan RSGR -no pertenecen al 20 por ciento crtico (los riesgos con la mayor prioridad del proyecto).

Riesgos y peligros para la seguridad

El riesgo no se limita al proyecto de software solamente. Pueden aparecer riesgos despus de haber desarrollado con xito el software y de haberlo entregado al cliente. Estos riesgos estn tpicamente asociados con las consecuencias del fallo del software una vez en el mercado. Aunque la probabilidad de fallo de un sistema de alta ingeniera es pequea, un defecto no detectado en un sistema de control y supervisin basados en ordenador podra provocar unas prdidas econmicas enormes, o peor, daos fsicos significativos o prdida de vidas humanas. Pero el coste y beneficios funcionales del control y supervisin basados en computadora a rnenudo superan al riesgo. Hoy en da, se emplean regularmente hardware y software para el control de sistemas de seguridad crtica. Cuando se emplea software como parte del sistema de control, la complejidad puede aumentar del orden de una magnitud o ms. Sutiles defectos de diseo inducidos por error humano -algo que puede descubrirse y eliminarse con controles convencionales basados en hardware- se convierte en mucho ms difciles de descubrir cuando se emplea software. La seguridad del software y el anlisis del peligro son actividades para garantizar la calidad del software que se centra en la identificacin y evaluacin de peligros potenciales que pueden impactar al software negativamente y provocar que falle el sistema entero. Si se pueden identificar los peligros al principio del proceso de ingeniera del software, se

22

pueden especificar caractersticas de diseo software que eliminen o controlen esos peligros potenciales.

El plan RSGR
Se puede incluir una estrategia de gestin de riesgo en el plan del proyecto de software o se podran organizar los pasos de gestin del riesgo en un plan diferente de reduccin, supervisin y gestin del riesgo (Plan RSGR). Todos los documentos del plan RSGR se llevan a cabo como parte del anlisis de riesgo y son empleados por el jefe del proyecto como parte del Plan del Proyecto general. A continuacin se expone un esquema del Plan RSGR.

I. Introduccin

1. Alcance y propsito del documento. 2. Visin general de los riesgos principales. 3. Responsabilidades. a. Gestin. b. Personal tcnico. II. Tabla de riesgo del proyecto. 1. Descripcin de todos los riesgos por encima de la lnea de corte. 2. Factores que influyen en la probabilidad e impacto . III. Reduccin, supervisin y gestin del riesgo n. a. Riesgo # n Reduccin Estrategia general.
23

ii. Pasos especficos. b. Supervisin i. Factores a supervisar. ii. Enfoque de supervisin. c. Gestin i. Plan de contingencia. ii. Consideraciones especiales. IV. Planificacin temporal de revisin del Plan RSGR. V. Resumen.

Una vez que se ha desarrollado el plan RSGR y el proyecto ha comenzado, empiezan los procedimientos de reduccin y supervisin del riesgo Como ya hemos dicho antes, la reduccin del riesgo es una actividad para evitar problemas La supervisin del riesgo es una actividad de seguimiento del proyecto con tres objetivos principales Valorar cuando un riesgo previsto ocurre de hecho; Asegurarse de que los procedimientos para evitar el riesgo definidos para el riesgo en cuestin se estn aplicando apropiadamente; y Recoger informacin que pueda emplearse en el futuro para analizar riesgos. En muchos casos, los problemas que ocurren durante un proyecto pueden afectar a ms de un riesgo. Otro trabajo de la supervisin de riesgos es intentar determinar el "origen" (qu riesgos ocasionaron tal problema) a lo largo de todo el proyecto.

Procedimiento de Gestin del Riesgo

24

25

Conclusin
Podemos decir que un adecuado proceso de ingeniera de requisitos tiene implicaciones positivas en la calidad del producto final, por ende, en la satisfaccin del cliente. Debido a esto el proceso de Ingeniera de requisitos tiene que estar bien definido y ser desarrollado de forma disciplinada, coherente y repetitiva, garantizando la obtencin de experiencias que permitan aplicar las mejores prcticas a la hora de desarrollar un producto de software. El tratamiento proactivo de los riesgos asociados a los requisitos del software permite al gestor adoptar, desarrollar e implementar

adecuadamente las actividades de gestin de estos, en funcin de obtener productos de calidad que satisfagan las necesidades del cliente, manteniendo el equilibrio de plazo y costo del proyecto en virtud de lograr un mejor desempeo del proceso de Ingeniera de requisitos en la pequea y mediana empresa de software.

26

Bibliografa
http://www.buenastareas.com/ensayos/Lista-De-Riesgos-En-ProyectoDe/3160891.html http://www.sitios.uach.cl/caminosfor/CristianSalazar/SIE/RS.html http://www.amicus.udesa.edu.ar/documentos/6jornada/documentos/pdf/PO NENCIA%20MISIONES%20RIESGOS%20Web2.0.pdf http://www.monografias.com/trabajos41/riesgo-etapa-requisitos/riesgoetapa-requisitos.shtml

27