UNIDAD 4. ARQUITECTURA DE PROTOTIPOS EMPRESARIALES

¿QUE ES UN RIESGO PARA UN PROYECTO DE SOFTWARE?

Un riesgo es aquel factor que influye negativamente en el éxito del proyecto. El riesgo en un proyecto de desarrollo de software incluye componentes técnicos 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, número de unidades de la organización implicadas y proyectos que involucran a múltiples proveedores.

¿CUAL ES LA IMPORTANCIA DE LA GESTION DE RIESGOS?

Para lograr producir aquello que el cliente requiere, en el plazo solicitado y ajustados al presupuesto asignado, se necesita desarrollar un proceso que incluya desde la etapa más temprana la gestión de los riesgos asociados a los requisitos, de forma que se contribuya al mejoramiento gradual del proceso de desarrollo y la gestión de un proyecto de software que logre la satisfacción del cliente.

La identificación y gestión de los riesgos asociados a los requisitos del software, individuales y a grupos de ellos, desde la fase de ingeniería de requisitos puede permitir minimizarlos, evadirlos y controlarlos. El enfrentamiento proactivo de los riesgos que pueden afectar al desarrollo o a la calidad de los requisitos y las acciones para evitarlos, permitirían minimizar problemas que persisten en el desarrollo de software. Son de mayor importancia los riesgos asociados a las principales características de calidad de los requisitos.

¿DEFINE LAS ETAPAS DEL MODELO DE GESTION DE RIESGOS?

· IDENTIFICACION DE RIESGOS

El Tratar de identificar riesgos es un criterio proactivo que busca identificar posibles factores de riesgo y tomar medidas de factores de riesgos y tomar medidas de aseguramiento o planes de contingencia para contrarrestarlos a ellos y a sus efectos.

Al realizar esta identificación podría hablarse de riesgos genéricos y riesgos específicos del producto.

LISTADO DE RIESGOS POTENCIALES

TIPO DE RIESGO	INDICADORES POTENCIALES
Tecnológico	Entrega retrasada del hardware o de la ayuda al software, muchos problemas tecnológicos reportados.
Personal	Baja moral del personal, malas relaciones entre los miembros del equipo, disponibilidad de empleo.
Organizacional	Chismorreo organizacional, falta de acciones por el administrador principal.
Herramientas	Rechazo de los miembros del equipo para utilizar herramientas, quejas acerca de las herramientas CASE, peticiones de estaciones de trabajo mas potentes.
Requerimientos	Peticiones de muchos cambios en los requerimientos, quejas del cliente.
Estimación	Fracaso en el cumplimiento de los tiempos acordados, y en la eliminación de defectos reportados.

ANALISIS DE RIEGOS

Durante este proceso, se considera por separado cada riesgo identificado y se decide acerca de la probabilidad y la seriedad del mismo.

No existe una forma fácil de hacer esto, Recae en la opinión del administrador del proyecto. No se hace una valoración con números precisos sino en intervalos.

RIESGO	PROBABILIDAD	EFECTOS
Los problemas financieros de la organización fuerzan a reducir el presupuesto del proyecto.	Baja	Catastrófico
Es imposible reclutar personal con las habilidades requeridas para el proyecto.	Alta	Catastrófico
El personal clave esta enfermo y no disponible en momentos críticos.	Moderada	Serio
Los componentes de software a reutilizarse contienen defectos que limitan su funcionalidad.	Moderada	Serio
Se proponen cambios en los requerimientos que requieren rehacer el diseño.	Moderada	Serio
La organización se reestructura de tal forma que una administración diferente se responsabiliza del proyecto.	Alta	Serio
La BD que se utiliza en el sistema no puede procesar muchas transacciones por segundo como se esperaba.	Moderada	Serio
El tiempo requerido para desarrollar el software esta subestimado.	Alta	Serio
Las herramientas CASE no se pueden integrar.	Alta	Tolerable
Los clientes no comprenden el impacto de los cambios en los requerimientos.	Moderada	Tolerable
La capacitación solicitada para el personal no esta disponible.	Moderada	Tolerable
La tasa de reparación de defectos esta subestimada.	Moderada	Tolerable
El tamaño del software esta subestimado.	Alta	Tolerable

PLANEACION DE RIESGOS

Se establece un plan de gestión del riesgo para cada uno de los riesgos clave identificados.

Depende del conocimiento y la experiencia del gestor del proyecto.

• Estrategias de anulación o prevención.
• Estrategias de disminución o minimización
• Planes de contingencia.

RIESGO	ESTRATEGIA
Problemas financieros de la organización	Preparar un documento breve para el administrador principal que muestre que el proyecto hace contribuciones muy importantes a las metas del negocio.
Problemas de reclutamiento	Alertar al cliente de las dificultades potenciales y las posibilidades de retraso, investigar los componentes comprados.
Enfermedad del personal	Reorganizar el equipo de tal forma que haya traslape en el trabajo y las personas comprendan en de los demás.
Componentes defectuosos	Reemplazar los componentes defectuosos con los comprados de fiabilidad conocida.
Cambios en los requerimientos	Rastrear la información para valorar el impacto de los requerimientos, maximizar la información oculta en ellos.
Restructuración organizacional	Preparar un documento breve para el administrador principal que muestre que el proyecto hace contribuciones muy importantes a las metas del negocio.
Desempeño de la base de datos	Investigar la posibilidad de comprar una BD con alto desempeño
Tiempo de desarrollo subestimado	Investigar los componentes comprados y la utilización de una generador de programas.

SUPERVICION DEL RIESGO

Valora cada uno de los riesgos identificados para decidir si este es más o menos probable y cuando los efectos del mismo han cambiado.

• Se hace una valoración después de alcanzar cada hito principal.
• Encargado de riesgos:
• Alertar sobre los riesgos del proyecto y evitar que los administradores y desarrolladores los ignoren en la planificación.
• Buscar todas las razones por las cuales el proyecto puede fallar.
• Supervisar la efectividad de los planes de reducción de riesgos.

Realizar el clásico análisis costo-beneficio para la prevención o el plan de contingencia del riesgo.

La supervisión del riesgo debe ser un proceso continuo y en cada revisión del progreso de la administración cada uno de los riesgos clave debe ser considerado por separado y discutido.