Sei sulla pagina 1di 5

Son 3 temas y la idea es abarcar la mayor cantidad de tema porque como les comenté hoy,

el man mira es que tanta carreta uno tiene.


Santiago Casallas (Gestión de Riesgos)
Santiago Collazos y Steven R (Métricas en gestión de proyectos)
Alvaro (Herramientas de gestión de proyectos)
Hay que dejarlo listo en la noche para que Steven lo pase al formato :)

Gestión del riesgo de software

1 Identificar riesgos.
2 Diseñar planes para compensar el riesgo.
3 Prevenir proporcionalmente al riesgo (evitar al gestor paranoico).
4 Monitorizar estado de los riesgos.

Según el diccionario Webster [4] el riesgo puede definirse como la posibilidad de un daño,
desventaja o destrucción. Es un ente que algunos autores [5-9] caracterizan como
bidimensional y que representa típicamente una función de la probabilidad de ocurrencia de
un fallo y de la gravedad de sus consecuencias. Esta doble dimensión es lo que para
algunos autores [9] diferencia el riesgo y el peligro, que solo se caracteriza por una
dimensión de severidad contra las personas y los equipos. El riesgo siempre está presente
en todas las actividades humanas individuales y de grupo, incluyendo las de ingeniería, y
dentro de estas, las de desarrollo de software. Para el PMBOK [10] del Project Management
Institute el riesgo es un evento o condición incierta que si ocurre, tendrá un efecto positivo o
negativo en los objetivos del proyecto. Como puede verse, en esta definición tendrán
también cabida los efectos positivos de un evento. La tabla 2 recoge algunos matices
comunes a definiciones de riesgo extraídas de la literatura [4-13]
Los riesgos detectados en un proyecto inciden de dos formas en el mismo. A corto plazo,
van
a condicionar la decisión sobre cuál va a ser la siguiente acción a tomar, encaminada a
evitar,
contrarrestar o asumir el riesgo detectado. A medio y largo plazo, los riesgos detectados o
experimentados en proyectos pasados pueden determinar también los niveles de calidad y
las acciones que se van a exigir a los proyectos futuros.

Previo al desarrollo del objeto de estudio de esta tesis, la Gestión de Riesgos en Proyectos
de
Ingeniería de Software, se brindarán todos aquellos conceptos y definiciones propias de
ésta
práctica.
Así es que comenzamos definiendo Gestión de acuerdo a la Real Academia Española:
“Gestionar equivale a hacer diligencias conducentes al logro de un negocio o de un deseo
cualquiera.”
Sin embargo, ésta definición no se enfoca en el contexto de negocios propiamente, como
bien
lo es la industria del software, así es que podemos enriquecer la definición diciendo que,
“Gestionar implica la realización de diligencias enfocadas a la obtención de algún beneficio,
tomando a las personas que trabajan en una organización como recursos activos para el
logro
de los objetivos.”
El segundo concepto que necesitamos definir con claridad es el de Riesgo. Para ello
podemos
partir de la definición que brinda el Software Engineering Institute (SEI):
“Posibilidad de sufrir una pérdida.”
Consideremos que en un proyecto la Pérdida describe el impacto que sufre el mismo, el
cual
puede ser en forma de disminución en la calidad del producto final, incremento en los
costos,
demora en la finalización, perdida de mercado o falla.
Otra definición de Riesgo es la que se encuentra en el Libro del Conocimiento de Gestión
de
Proyectos (Project Management Book Of Knowledge – PMBOK en inglés), la cual es
interesante ya que no solo hace referencia a un riesgo como un evento negativo sino que
también puede ocurrir que sea un evento positivo,
“Evento o condición incierta que, de ocurrir, tiene un efecto positivo o negativo en al menos
uno
de los objetivos del proyecto, tal como tiempo, costo, alcance o calidad.”

Esquema General
1 Establecer un Plan General de Riesgos.
2 Identificar Riesgos.
3 Análisis Cualitativo de Riesgos.
4 Análisis Cuantitativo de Riesgos.
5 Plan de Respuesta a Riesgos.
6 Control de Riesgos.

Identificar
La actividad de identificación de riesgos consiste en descubrir factores de riesgo antes que
estos lleguen a convertirse en problemas y deriven en daños o pérdidas.

Analizar
El análisis de riesgos consiste en convertir los atributos del riesgo en información que sirva
de
base para la toma de decisiones. Esto implica establecer valores para el impacto (la perdida
o
efecto negativo en un proyecto en caso de que ocurra el riesgo); y la probabilidad (la
probabilidad de que el riesgo ocurra).

Planificar la Respuesta
La actividad de planificación de la respuesta consiste en decidir qué hacer y cuándo para
cada
uno de los riesgos identificados. La estrategia para cada riesgo puede variar según el
conocimiento del momento de los riesgos del proyecto: evitar, transferir, mitigar o aceptar el
riesgo son algunas de las posibilidades.

Evitar el riesgo significa que se deben abandonar algunos planes o tareas, aunque es difícil
quitar los riesgos adjuntos a metas. Lo que sí se puede hacer es prestar atención a riesgos
en
tareas con poca o ninguna ganancia. Por ejemplo, dejar de lado el desarrollo de una
funcionalidad que esté llena de riesgos y no sea necesaria.

Transferir un riesgo implica cambiar su responsable, su locación o reorganizar prioridades


entre tareas con la idea de transferirlo a un nuevo escenario que sea más ventajoso para la
organización. Por ejemplo, los directores de proyectos saben que rotando responsabilidades
dentro del equipo, algunos riesgos pueden ser desplazados.

Monitorear
Monitorear es el proceso que conlleva recoger, analizar y posteriormente divulgar los datos
para los riesgos que están en observación o mitigación.

Controlar
La finalidad de la actividad de control es corregir las desviaciones de los planes de
mitigación.
Además de controlar los riesgos de la lista actual del proyecto, el equipo debe estar atento a
nuevos riesgos que puedan aparecer en su entorno a medida que el proyecto avanza.
Comunicar
La finalidad de la actividad de comunicación es proporcionar información y retroalimentación
sobre las actividades de gestión del riesgo del proyecto, los riesgos actuales y los riesgos
que
puedan surgir.

Identificación del riesgo

La identificación del riesgo es un intento sistemático para especificar las amenazas al plan
del proyecto (estimaciones, planificación temporal, carga 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 categoría presentada en el apartado
anterior: genéricos y específicos del producto. Los riesgos genéricos son una amenaza
potencial para todos los proyectos de software. Los específicos de producto sólo los pueden
identificar los que tienen una clara visión de la tecnología. el personal y el entorno
específico del proyecto en cuestión. Para identificar los riesgos específicos del producto se
examinan el plan del proyecto y la declaración del ámbito del software y se desarrolla una
respuesta a la siguiente pregunta: ¿Qué características especiales de este producto pueden
estar amenazadas por nuestro plan del proyecto'?"

La lista de comprobación se puede utilizar para identificar riesgos y se enfoca en un


subconjunto de riesgos conocidos y predecibles en las siguientes subcategorías genéricas:

• Tamaño del producto: riesgos asociados con el tamaño general del software a construir o
a modificar.

• Impacto en el negocio: riesgos asociados con las limitaciones impuestas por la gestión o
por el mercado.

• Características del cliente: riesgos asociados con la sofisticación del cliente y la habilidad
del desarrollador para comunicarse con el cliente en los momentos oportunos.

• Definición del proceso: riesgos asociados con el grado de definición del proceso del
software y su seguimiento por la organización de desarrollo.

• Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de las


herramientas que se van a emplear en la construcción del producto.

• Tecnología a construir: riesgos asociados con la complejidad del sistema a construir y la


tecnología punta que contiene el sistema.
• Tamaño y experiencia de la plantilla: riesgos asociados con la experiencia técnica y de
proyectos de los ingenieros del software que van a realizar el trabajo.

Referencias

http://ocw.unican.es/ensenanzas-tecnicas/ingenieria-del-software-ii/materiales/tema7-
gestionRiesgos.pdf

http://www.redalyc.org/articulo.oa?id=43030033021

http://dis.um.es/~barzana/Informatica/IAGP/IAGP_riesgos.html

https://www.colibri.udelar.edu.uy/bitstream/123456789/2967/1/tesis-jaureche.pdf

Potrebbero piacerti anche