# data[].attributes.body
Un riesgo es un evento o condición incierta que, si ocurre, tiene un efecto positivo o negativo en uno o más objetivos. Los riesgos que tienen un efecto positivo en los objetivos se denominan oportunidades y los que afectan negativamente se denominan amenazas.

# data[].attributes.body
Este se define como cualquier tipo de vulnerabilidad en el sistema que pueda potencialmente devenir en pérdidas de datos, accesos no autorizados, ruptura de la integridad y caídas del sistema.

# data[].attributes.body
El riesgo de información es un cálculo basado en la probabilidad de que un usuario no autorizado afecte negativamente la confidencialidad, integridad y disponibilidad de los datos que recopila, transmite o almacena.

Hay que asegurar la confidencialidad, disponibilidad y la integridad

# data[].attributes.body
What is risk management? - YouTube

¿Qué es la gestión de riesgos? La gestión de riesgos ayuda a las organizaciones a establecer estrategias, lograr objetivos y tomar decisiones informadas.

El enfoque de riesgo varia entre las organizaciones pero un marco de gestión de riesgos debe documentar la tolerancia al riesgo, los niveles de toma de riesgos que son aceptables para lograr un objetivo especifico

# data[].attributes.body
·       Es la forma en la que se protegen interna y externamente.

·       La gestión de riesgos es el proceso de identificar, analizar y responder a factores de riesgo a lo largo de la vida de un proyecto y en beneficio de sus objetivos. La gestión de riesgos adecuada implica el control de posibles eventos futuros.

·       La gestión de riesgos: Un proceso continuo

·       Una vez que el equipo de proyectos identifica todos los posibles riesgos que pueden perjudicar el éxito del proyecto, debe escoger los que tienen más probabilidades de suceder. Basará su decisión en las experiencias pasadas respecto de la probabilidad de ocurrencia, su intuición, las lecciones aprendidas, los datos históricos, entre otros.

·       La importancia es que la oportunidad y el riesgo por lo general permanecen relativamente altos durante la planificación del proyecto (al inicio del ciclo de vida), pero debido al relativo bajo nivel de inversión en este punto, lo que está en juego permanece bajo. Por el contrario, durante la ejecución del proyecto, el riesgo cae de forma progresiva a niveles inferiores a medida que lo desconocido se convierte en conocido.

Respuesta a los riesgos

La respuesta a los riesgos por lo general incluye:

Prevención: Eliminación de una amenaza específica, a menudo al eliminar la causa.

Mitigación: Reducción del valor monetario estimado de un riesgo al reducir la probabilidad de ocurrencia.

Aceptación: Aceptar las consecuencias del riesgo. Con frecuencia, esto se cumple al desarrollar un plan de contingencia para ejecutar si el riesgo llega a ocurrir.

El propósito de la gestión de riesgos es la siguiente:

Identificar posibles riesgos

Reducir o dividir los riesgos

Proporcionar una base racional para la toma de decisiones en relación con todos los riesgos

Planificar

Garantizar que los riesgos de mayor prioridad sean gestionados de forma agresiva y que todos los riesgos sean gestionados, cuidando los costos, a lo largo del proyecto.

Proporcionar gestión en todos los niveles con la información necesaria para tomar decisiones informadas en problemas críticos para el éxito del proyecto.

Tomado de: https://gerens.pe/blog/gestion-de-riesgos/

GESTION:

·       Identificar

·       Analizar

·       Responder

·       Inicio: se procede con la fijación del alcance del proyecto y su correspondiente aprobación.

·       Planificación: se programan las distintas etapas de la gestión en cuestión.

·       Ejecución práctica: se llevan a cabo todas las tareas establecidas en la etapa anterior, con la finalidad de completar eficientemente cada uno de los entregables.

·       Seguimiento de gestión y control pertinente: se realizan las tareas de supervisión y se efectúa un procedimiento comparativo entre las acciones programadas y las que se realizaron. En el caso de que existieran discrepancias, se deben aplicar las contramedidas necesarias para neutralizar su desviación.

·       Finalización: se produce la culminación formal del proyecto con la consecuente liberación de los recursos, tanto humanos como materiales. Posteriormente, se debe efectuar una evaluación y una retroalimentación de lo realizado a lo largo del proyecto.

Las normas ISO 31 000 se pueden utilizar como marco de gestión de riesgos para las empresas, independientemente de cuál sea el sector. Estas normas ayudan a las empresas a implementar un plan para gestionarlos de forma sistemática.

Gestión de riesgos de TI

En el caso de la TI, los riesgos provienen de la posibilidad de pérdidas o daños si una amenaza aprovecha un punto vulnerable de seguridad en sus sistemas de hardware o software. Los puntos vulnerables y las exposiciones comunes (CVE), una lista de fallas de seguridad que se encuentra disponible para todo el público, permiten que los especialistas en TI coordinen sus esfuerzos para priorizar y solucionar estos puntos vulnerables y mejorar la seguridad de los sistemas informáticos.

La forma en que desarrollamos, implementamos, integramos y gestionamos la TI está cambiando considerablemente. La seguridad de la TI debe formar parte de la infraestructura y del ciclo de vida del producto desde el comienzo, y debe incorporarse a la estrategia de gestión de riesgos para que su empresa sea proactiva y reactiva.

Tomado de: https://www.redhat.com/es/topics/management/what-is-risk-management

# data[].attributes.headline
Contexto General ¿Qué busca la gestión de riesgos? 

# data[].attributes.subject
Contexto General ¿Qué busca la gestión de riesgos? 

# data[].attributes.body
Mapeo general del riesgo para evitar el fracaso de una organización.

Cultura organizacional de manejar y gestionar los riesgos de manera adecuada para el éxito de una empresa.

Analizar las variables del riesgo, la probabilidad de que se materialice y el impacto que tendría si este es materializado. Así mismo valorizar cada uno.

Se puede convivir con el riesgo

Plan para mitigar los riesgos y minimizar los impactos

https://www.youtube.com/watch?v=X8AA5DEUGQY

# data[].attributes.body
https://www.piranirisk.com/es/academia/especiales/guia-del-sistema-de-gestion-de-riesgos-iso-31000

Es el proceso que se realiza para identificar y gestionar los riesgos a los que puede estar expuesta la organización, además, para validar la eficiencia de los controles y crear planes de acción que ayude a mitigarlos, aprovecharlos o en caso de que no se puedan prevenir contar con una estrategia que permita reducir las pérdidas.

Contar con un adecuado sistema de gestión de riesgos, permite a las organizaciones cumplir sus objetivos de negocio.

# data[].attributes.headline
¿Por qué es importante la Gestión de Riesgos?

# data[].attributes.subject
¿Por qué es importante la Gestión de Riesgos?

# data[].attributes.body
- Podemos disminuir la ocurrencia de accidentes, ataques y fallas.
- Es más barato tomar medidas para prevenir brechas que contenerlas, esto incluye horas de trabajo, continuidad del negocio y reputación de marca.
- Si se tiene un plan o protocolo para responder ante eventualidades las respuestas serán más rápidas y efectivas puesto a que la toma de decisiones ya está realizada (cuando se realiza el plan de contingencia). Esto me gusta porque es similar al entrenamiento que reciben los policias y personal de emergencia en el que entrenan cómo responder ante situaciones que a una persona normal dejarían en shock; la preparación y entrenamiento que reciben estas personas les ayuda a reaccionar apropiadamente a situaciones de emergencia. Esta analogía funciona en una empresa que tenga un roles asignados para responder ante evenualidades y hayan ciertos protocolos a seguir según si lo que sucedió fue un accidente laboral, robo de información, una pérdida del servicio entre otros; desde luego que cada situación es diferente y los planes no pueden proveer las soluciones pero sí pueden proveer un marco de trabajo que facilite la toma de decisiones o ciertas acciones que deban hacerse cuando el tiempo es clave.

# data[].attributes.body
¿Por qué manejar el riesgo?

Cuidar recursos: Personas, ingresos, propiedades, tiempo.

Proteger la imagen publica.

Proteger a las personas de posibles daños.

Prevenir/Reducir la responsabilidad legal.

Proteger el ambiente.

Proceso gestión de riesgos

1. Identificar posibles exposiciones a pérdidas

2. Medir la frecuencia y la gravedad

3. Examinar alternativas

4. Decidir que alternativas usar

5. Implementar las técnicas escogidas

6. Monitorear resultados

# data[].attributes.body
La gestión de riesgos es el proceso de identificar, evaluar y controlar las amenazas al capital y las ganancias de una organización. Estas amenazas o riesgos podrían provenir de una amplia variedad de fuentes, incluida la incertidumbre financiera, las responsabilidades legales, los errores de gestión estratégica, los accidentes y los desastres naturales. Las amenazas a la seguridad de TI y los riesgos relacionados con los datos, y las estrategias de gestión de riesgos para aliviarlos, se han convertido en una prioridad para las empresas digitalizadas. Como resultado, un plan de gestión de riesgos incluye cada vez más los procesos de las empresas para identificar y controlar las amenazas a sus activos digitales, incluidos los datos corporativos patentados, la información de identificación personal (PII) de un cliente y la propiedad intelectual.

Toda empresa y organización se enfrenta al riesgo de eventos inesperados y dañinos que pueden costarle dinero a la empresa o hacer que cierre permanentemente. La gestión de riesgos permite a las organizaciones intentar prepararse para lo inesperado minimizando los riesgos y los costes adicionales antes de que sucedan.

Importancia
Al implementar un plan de gestión de riesgos y considerar los diversos riesgos o eventos potenciales antes de que ocurran, una organización puede ahorrar dinero y proteger su futuro. Esto se debe a que un plan de gestión de riesgos sólido ayudará a una empresa a establecer procedimientos para evitar amenazas potenciales, minimizar su impacto en caso de que ocurran y hacer frente a los resultados. Esta capacidad de comprender y controlar el riesgo permite a las organizaciones tener más confianza en sus decisiones comerciales. Además, los principios sólidos de gobierno corporativo que se centran específicamente en la gestión de riesgos pueden ayudar a una empresa a alcanzar sus objetivos.

# data[].attributes.body
La respuesta a los riesgos suele adoptar una de las siguientes formas:
Evitación : una empresa se esfuerza por eliminar un riesgo particular deshaciéndose de su causa.
Mitigación : Disminuir el valor financiero proyectado asociado con un riesgo al disminuir la posibilidad de que ocurra el riesgo.
Aceptación : en algunos casos, una empresa puede verse obligada a aceptar un riesgo. Esta opción es posible si una entidad comercial desarrolla contingencias para mitigar el impacto del riesgo, en caso de que ocurra.

Al crear contingencias, una empresa debe adoptar un enfoque de resolución de problemas. El resultado es un plan bien detallado que se puede ejecutar tan pronto como surja la necesidad.

IMPORTANCIA DE GESTION DE RIESGOS:

La gestión de riesgos es un proceso importante porque otorga a una empresa las herramientas necesarias para que pueda identificar y tratar adecuadamente los riesgos potenciales. Una vez que se ha identificado un riesgo, es fácil mitigarlo. Además, la gestión de riesgos proporciona a la empresa una base sobre la que puede emprender una toma de decisiones sensata.

# data[].attributes.headline
Principales razones de la generación de los riesgos informáticos

# data[].attributes.subject
Principales razones de la generación de los riesgos informáticos

# data[].attributes.body
Errores humanos, principalmente por parte del personal TI y en especial cuando no está lo suficientemente calificado. Estos errores pueden producirse por programación deficiente o por una administración incorrecta de los recursos.

Accidentes, desastres y robos a nivel de hardware. Desde destrucción accidental de pendrives con información importante hasta hurtos y desastres naturales.

Amenazas e intrusiones a nivel de software. Los ciberataques, la intrusión no autorizada de terceros a los sistemas informáticos de la empresa o la acción de programas maliciosos pueden ocasionar daños irreparables.

Todos estos casos ocasionan problemas a nivel de producción y de optimización, afectando a la eficiencia de toda la organización.

# data[].attributes.body
Pasos para la gestión de riesgos:
- Establecer contexto
- Identificar riesgos
- Analizar riesgos
- Integrar riesgos
- Priorizar riesgos
- Combinar riesgos
- Monitorear riesgos

# data[].attributes.body
La identificación y el establecimiento de medidas para contrarrestar las posibles amenazas y vulnerabilidades a las que se enfrenta una organización, se lleva a cabo a través de un plan de gestión de riesgos informáticos.

Para establecer un sistema de gestión de riesgos informáticos es necesario en primer lugar identificar todas las posibles vulnerabilidades de la organización a este respecto. El ámbito de la empresa, así como la naturaleza de sus actividades determinarán qué tipo de riesgos existen y el nivel crítico de cada uno de ellos. También es interesante establecer el posible impacto que tendría cada uno de ellos sobre la organización.
Algunos tipos de Riesgos son:

# data[].attributes.body
Confidentiality: Sólo las personas destinadas a acceder y manipular la información tienen acceso a ella.
Integrity: La información no se deja alterar de forma inautorizada, esto también incluye tolerancia a alteraciones no maliciosas (error de software o hardware).
Availability: La información puede ser accedida siempre que se requiera.

# data[].attributes.headline
Risk Management: Harvard Business Review

# data[].attributes.subject
Risk Management: Harvard Business Review

# data[].attributes.attachment_link.readable_text
Risk management is too often treated as a compliance issue that can be solved by drawing up lots of rules and making sure that all employees follow them. Many such rules, of course, are sensible and do reduce some risks that could severely damage a company. But rules-based risk management will not diminish either the likelihood or the impact of a disaster such as Deepwater Horizon, just as it did not prevent the failure of many financial institutions during the 2007-2008 credit crisis.

In this article, Robert S. Kaplan and Anette Mikes present a categorization of risk that allows executives to understand the qualitative distinctions between the types of risks that organizations face. Preventable risks, arising from within the organization, are controllable and ought to be eliminated or avoided. Examples are the risks from employees' and managers' unauthorized, unethical, or inappropriate actions and the risks from breakdowns in routine operational processes. Strategy risks are those a company voluntarily assumes in order to generate superior returns from its strategy. External risks arise from events outside the company and are beyond its influence or control. Sources of these risks include natural and political disasters and major macroeconomic shifts. Risk events from any category can be fatal to a company's strategy and even to its survival.

Companies should tailor their risk management processes to these different risk categories. A rules-based approach is effective for managing preventable risks, whereas strategy risks require a fundamentally different approach based on open and explicit risk discussions. To anticipate and mitigate the impact of major external risks, companies can call on tools such as war-gaming and scenario analysis.

# data[].attributes.attachment_link.description
Risk management is too often treated as a compliance issue that can be solved by drawing up lots of rules and making sure that all employees follow them. Many such rules, of course, are sensible and do reduce some risks that could severely damage a company.

# data[].attributes.body
Apuntes Gestión de riesgos en Informática. Seguridad. Criptografia. Rafael Barzanallana. IAGP (um.es)

# data[].attributes.attachment_link.readable_text
1.- Introduccin

En su libro sobre anlisis y gestin del riesgo, Robert Charette presenta la siguiente definicin de riesgo:

En primer lugar, el riesgo afecta a los futuros acontecimientos. El hoy y el ayer estn ms all de lo que nos pueda preocupar, pues ya estamos cosechando lo que sembramos previamente con nuestras acciones del pasado. La pregunta es, podemos por tanto, cambiando nuestras acciones actuales, crear una oportunidad para una situacin diferente y, con suerte, mejor para nosotros en el futuro. Esto significa, en segundo lugar, que el riesgo implica cambio, que puede venir dado por cambios de opinin, de acciones, de lugares... En tercer lugar, el riesgo implica eleccin y la incertidumbre que entraa la eleccin. Por tanto, el riesgo, como la muerte, es una de las pocas cosas inevitables de la vida.

Cuando se considera el riesgo en el contexto de la ingeniera del software, los tres pilares conceptuales de Charette se hacen continuamente evidentes. El futuro es lo que nos preocupa, qu riesgos podran hacer que nuestro proyecto fracasara? El cambio es nuestra preocupacin cmo afectarn los cambios en los requisitos del cliente, en las tecnologas de desarrollo, en los ordenadores a las que van dirigidas, el proyecto y todas las entidades relacionadas con l, al cumplimiento de la planificacin temporal y al xito en general? Para terminar, nos enfrentamos con elecciones qu mtodos y herramientas deberamos emplear, cunta gente debera estar implicada, qu importancia hay que darle a la calidad?

Peter Drucker dijo una vez: "Mientras que es intil 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
Las estrategias de riesgo reactivas se han denominado humorsticamente "Escuela de gestin del riesgo de Indiana Jones". En las pelculas, Indiana Jones, cuando se enfrentaba a una dificultad insuperable, siempre deca "No te preocupes, pensar en algo!". Nunca se preocupaba de los problemas hasta que ocurran, entonces reaccionaba como un hroe.

Como el jefe del proyecto de software normalmente no es Indiana Jones y los miembros de su equipo no son sus fiables colaboradores, la mayora de los equipos de software confan solamente en las estrategias de riesgo reactivas. En el mejor de los casos, la estrategia reactiva supervisa el proyecto en previsin de posibles riesgos. Los recursos se ponen aparte, en caso de que pudieran convertirse en problemas reales. Pero lo ms frecuente es que el equipo de software no haga nada respecto a los riesgos hasta que algo va mal. Despus el equipo vuela para corregir el problema rpidamente. ste es el mtodo denominado a menudo "de bomberos". Cuando falla, "la gestin de crisis" entra en accin y el proyecto se encuentra en peligro real.

Una estrategia considerablemente ms inteligente para el control del riesgo es ser proactivo. La estrategia proactiva empieza mucho antes de que comiencen los trabajos tcnicos. Se identifican los riesgos potenciales, se valoran su probabilidad y su impacto y se establece una prioridad segn su importancia. Despus el equipo de software establece un plan para controlar el riesgo. El primer objetivo es evitar el riesgo, poco comn no se pueden evitar todos los riesgos. el equipo trabaja para desarrollar un plan de contingencia que le permita responder de una manera eficaz y controlada. A lo largo de lo que queda de este capitulo, estudiamos la estrategia proactiva para el control de riesgos.

2.- 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:

* 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.

Cuando se analizan los riesgos es importante cuantificar el nivel de incertidumbre y el grado de prdidas asociado con cada riesgo. Para hacerlo, se consideran diferentes categoras de riesgos.

Los 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 los problemas potenciales de presupuesto, planificacin temporal, personal (asignacin y organizacin), recursos. cliente y requisitos y su impacto en un proyecto de software.

Los riesgos tcnicos amenazan la calidad y la planificacin temporal del software que hay que producir. Si un riesgo tcnico 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 y de mantenimiento. Adems. las ambigedades de especificaciones, incertidumbre tcnica, tcnicas anticuadas y las "tecnologas punta" son tambin factores de riesgo. Los riesgos tcnicos ocurren porque el problema es ms difcil de resolver de lo que pensbamos.

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

1. Construir un producto o sistema excelente que no quiere nadie en realidad (riesgo de mercado),

2. Construir un producto que no encaja en la estrategia comercial general de la compaa (riesgo estratgico),

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

4. Perder el apoyo de una gestin experta debido a cambios de enfoque o a cambios de personal (riesgo de direccin)

5. Perder presupuesto o personal asignado (riesgos de presupuesto).
Es extremadamente importante recalcar que no siempre funciona una categorizacin tan sencilla. Algunos riesgos son simplemente imposibles de predecir.

Otra categorizacin general de los riesgos ha sido propuesta por Charette. Los riesgos conocidos son todos aquellos que se pueden descubrir despus de una cuidadosa evaluacin del plan del proyecto. del entorno tcnico y comercial en el que se desarrolla el proyecto y otras fuentes de informacin fables (p. ej.: fechas de entrega poco realistas. falta de especificacin de requisitos o de mbito del software. o un entorno pobre de desarrollo), los riesgos predecibles se extrapolan de la experiencia en proyectos anteriores (ej.: cambio de personal, mala comunicacin con el cliente. disminucin del esfuerzo del personal a medida que atienden peticiones de mantenimiento). Pueden ocurrir pero son extremadamente difciles de identificar por adelantado.

3.- Identificacin del riesgo

La identificacin del riesgo es un intento sistemtico para especificar las amenazas al plan del proyecto (estimaciones, planificacin 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 categora presentada en el apartado anterior: genricos y especficos del producto. Los riesgos genricos son una amenaza potencial para todos los proyectos de software. Los especficos de producto slo los pueden identificar los que tienen una clara visin de la tecnologa. el personal y el entomo especfico del proyecto en cuestin. Para identificar los riesgos especficos del producto se examinan el plan del proyecto y la declaracin del mbito del software y se desarrolla una respuesta a la siguiente pregunta: Qu caractersticas especiales de este producto pueden estar amenazadas por nuestro plan del proyecto'?"

Tanto los riesgos genricos como los especficos del producto se deberan identificar sistemticamente. Tom Gilb tiene toda la razn cuando dice: "Si no atacas activamente a los riesgos. ellos te atacarn activamente a ti", Un mtodo para identificar riesgos es crear una lista de comprobacin de elementos de riesgo. La lista de comprobacin se puede utilizar para identificar riesgos y se enfoca en un subconjunto de riesgos conocidos y predecibles en las siguientes subcategoras genricas:

* 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 por 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.

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

* Tamao y experiencia de la plantilla: riesgos asociados con la experiencia tcnica y de proyectos de los ingenieros del software que van a realizar el trabajo.

La lista de comprobacin de elementos de riesgo puede organizarse de diferentes maneras. Se pueden responder a cuestiones relevantes de cada uno de los temas apuntados anteriormente para cada proyecto de software. Las respuestas a estas preguntas permiten al planificador del proyecto estimar el impacto del riesgo. Un formato diferente de lista de comprobacin de elementos de riesgo contiene simplemente las caractersticas relevantes para cada subcategora genrica. Finalmente, se lista un conjunto de "componentes y controladores del riesgo" junto con sus probabilidades de aparicin. Los controladores del rendimiento, el soporte, el coste y la planificacin temporal del proyecto se estudian como respuesta a preguntas posteriores.

3.1.- Riesgos del tamao del producto
Pocos gestores experimentados discutiran la siguiente frase: El riesgo del proyecto es directamente proporcional al tamao dcl producto. La siguiente lista de comprobacin de elementos de riesgo identifica riesgos genricos asociados con el tamao del producto (software):
En cada caso, la informacin del producto a desarrollar debe compararse con la experiencia anterior. Si ocurre una gran desviacin del porcentaje o si las magnitudes son similares. pero si los resultados anteriores fueron poco satisfactorios, el riesgo es grande.

3.2.- Riesgos del impacto en el negocio
Un gestor de ingeniera (algo magufo) de una gran compaa de software coloc una placa con el texto: "dios me concedi el cerebro para ser un buen jefe de proyectos y el sentido comn para correr como un diablo cuando marketing establece las fechas lmite del proyecto!". Al departamento de marketing le guan las consideraciones del negocio, y stas entran a veces en conflicto directo con las realidades tcnicas. La siguiente lista de comprobacin de elementos de riesgo identifica riesgos genricos asociados con el impacto en el negocio:
Cada respuesta para el producto a desarrollar debe compararse con la experiencia anterior. Si se obtiene una gran desviacin del porcentaje o si las magnitudes son similares, pero los resultados anteriores fueron poco satisfactorios, el riesgo es grande.

3.3.- 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:

3.4.- 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
Aspectos tcnicos
Si la mayora de las cuestiones anteriores se han respondido negativamente, el proceso del software es dbil y el riesgo es alto.

3.5.- 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 comprobacin de elementos de riesgo identifica riesgos genricos asociados con la tcnica a construir.

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

3.6.- 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 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 entomo es malo. puede ser una fuente de riesgos significativa. La siguiente lista de comprobacin de elementos de riesgo identifica riesgos genricos asociados com el entomo de desarrollo:

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

3.7.- 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:

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

3.8.- Componentes y controladores del riesgo

Las Fuerzas Areas de Estados Unidos han redactado un documento que contiene excelentes directrices para identificar riesgos software y evitarlos. El enfoque de las Fuerzas Areas requiere que el gestor del proyecto identifique los controladores del riesgo que afectan a los componentes de riesgo software (rendimiento, coste, soporte y planificacin temporal). En el contexto de este estudio, los componentes de riesgo se definen de la siguiente manera:

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

* Riesgo de coste: 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 -despreciable. marginal, crtico y catastrfico. La figura 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.

4.- 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: (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; y (4) apuntar la exactitud general de la proyeccin del riesgo de manera que no haya confusiones.

4.1.- Desarrollo de una tabla de riesgo

Una tabla de riesgo le proporciona al jefe del proyecto una sencilla tcnica para la proyeccin del riesgo'. En la Figura se ilustra una tabla de riesgo como ejemplo.

Un equipo de proyecto empieza por listar todos los riesgos (no importa lo remotos que sean) en la primera columna de la tabla. Se puede hacer con la ayuda de la lista de comprobacin de elementos de riesgo presentada en la Seccin 6.3.

Cada riesgo es categorizado en la segunda columna (p. ej.: PS implica un riesgo del tamao del proyecto. BU implica un riesgo de negocio). La probabilidad de aparicin de cada riesgo se introduce en. la siguiente columna de la tabla. El valor de la probabilidad de cada riesgo puede estimarse por cada miembro del equipo individualmente. De los valores individuales se obtiene la media para obtener una probabilidad consensuada. A continuacin se valora el impacto de cada riesgo.

Cada componente de riesgo se valora usando la caracterizacin presentada en la primera figura, y se determina una categora de impacto. Las categoras para cada uno de los cuatro componentes de riesgo -rendimiento, soporte, coste y planificacin temporal- son promediados para determinar un valor general de impacto.

Una vez que se han completado las cuatro primeras columnas de la tabla de riesgo, la tabla es ordenada por probabilidad y por impacto. Los riesgos de alta probabilidad y de alto impacto pasan a lo alto de la tabla, y los riesgos de baja probabilidad caen a la parte de abajo. Esto consigue una priorizacin del riesgo de primer orden.

El jefe del proyecto estudia la tabla ordenada resultante y define una lnea de corte. La lnea de corte (dibujada horizontalmente)implica que slo a los riesgos que quedan por encima de la lnea se les prestar atencin en adelante. Los riesgos que caen por debajo de la lnea son reevaluados para conseguir una priorizacin de segundo orden.

El impacto del riesgo y la probabilidad tienen diferente influencia en la gestin como se ve en la siguiente figura. Un factor de riesgo que tenga un gran impacto pero muy poca probabilidad de que ocurra, no debera absorber una cantidad significativa de tiempo de gestin. Sin embargo, los riesgos de gran impacto con una probabilidad , moderada a alta y los riesgos de poco impacto pero de gran probabilidad deberan tenerse en cuenta en los procedimientos de gestin que se estudian a continuacin.

Todos los riesgos que se encuentran por encima de la lnea de corte deben ser considerados. La columna etiquetada RSGR contiene una referencia que apunta hacia un plan de reduccin, supervisin y gestin del riesgo desarrollado para todos los que se encuentran por encima de la lnea de corte.

La probabilidad de riesgo puede determinarse haciendo estimaciones individuales y desarrollando despus un nico valor de consenso. Aunque este enfoque es factible, se han desarrollado tcnicas ms sofisticadas para determinar la probabilidad de riesgo.

Los controladores de riesgo pueden valorarse en una escala de probabilidad cualitativa que tiene los siguientes valores: imposible, improbable, probable y frecuente. Despus puede asociarse una probabilidad matemtica con cada valor cualitativo (p. ej: una probabilidad del 0.7 al 1.0 implica un riesgo muy probable).

4.2.- 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.

La proyeccin del riesgo y las tcnicas de anlisis descritas en las Secciones 5.4.1 y 5.4.2 se aplican reiteradamente a medida que progresa el proyecto de software. 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.

4.3.- 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 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.

La figura representa esta situacin grficamente. 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.

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 como 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.

* Gestion 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.

* 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 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, 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).

6.- 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 convierten 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 pueden especificar caractersticas de diseo software que eliminen o controlen esos peligros potenciales.

7.- 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 es;quema 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. Riesgo # n

a. Reduccin
i.Estrategia general.
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 (1) valorar cuando un riesgo previsto ocurre de hecho; (2) asegurarse de que los procedimientos para evitar el riesgo definidos para el riesgo en cuestin se estn aplicando apropiadamente; y (3) 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.

# data[].attributes.attachment_link.title
Apuntes Gestin de riesgos en Informtica. Seguridad. Criptografia. Rafael Barzanallana. IAGP

# data[].attributes.attachment_link.description
1.- Introduccin En su libro sobre anlisis y gestin del riesgo, Robert Charette presenta la siguiente definicin de riesgo: En primer lugar, el riesgo afecta a los futuros acontecimientos. El hoy y el ayer estn ms all de lo que nos pueda preocupar, pues ya estamos cosechando lo que sembramos previamente con nuestras acciones del pasado.

# data[].attributes.headline
Guía de Risk Management para la dirección de proyectos

# data[].attributes.subject
Guía de Risk Management para la dirección de proyectos

# data[].attributes.body
https://topodata.com/wp-content/uploads/2019/10/GUIA_PMBok.pdf

Les comparto una guía que contiene los fundamentos, estándares y prácticas para la dirección de proyectos.

En el capítulo 11 encontrarán la sección de gestión del riesgo que contempla temas sobre la identificación del riesgo, el análisis cuantitativo y cualitativo del mismo, la planificación de respuestas, etc.

# data[].attributes.body
Son 3 opciones luego de haber identificado los  riesgos potenciales de una compañia, siendo:
1. Evitar: Siendo que la empresa utiliza recursos, capacitaciones, etc con el fin de eliminar un riesgo en particula, deshaciendose desde la causa de ese potencial riesgo.
2. Mitigacion: Al igual que con evitar, en este caso, se decide capacitar a empleados, contratar otras empresas, etc para disminuir lo mas posible las posibilidades de que ocurra uno de los escenarios identificados como riesgo.
3.Aceptar: En algunos casos las empresas no pueden deshacerce de un riesgo en particilas, siendo en este caso, la necesidad de aceptar ese riesgo, y proceder a crear un plan de accion a ejecutar, el dia que se presente el escenario no deseado.

Link:
https://corporatefinanceinstitute.com/resources/knowledge/strategy/risk-management/

# data[].attributes.attachment_link.readable_text
What Is Risk Management?

Risk management encompasses the identification, analysis, and response to risk factors that form part of the life of a business Business Life Cycle . Effective risk management means attempting to control, as much as possible, future outcomes by acting proactively rather than reactively. Therefore, effective risk management offers the potential to reduce both the possibility of a risk occurring and its potential impact.

Risks Management Structures

Risk management structures are tailored to do more than just point out existing risks. A good risk management structure should also calculate the uncertainties and predict their influence on a business. Consequently, the result is a choice between accepting risks or rejecting them. Acceptance or rejection of risks is dependent on the tolerance levels that a business has already defined for itself.

If a business sets up risk management as a disciplined and continuous process for the purpose of identifying and resolving risks, then the risk management structures can be used to support other risk mitigation systems. They include planning, organization, cost control, and . In such a case, the business will not usually experience many surprises, because the focus is on proactive risk management.

Response to Risks

Response to risks usually takes one of the following forms:

Avoidance: A business strives to eliminate a particular risk by getting rid of its cause.

Mitigation: Decreasing the projected financial valueTypes of Financial Models associated with a risk by lowering the possibility of the occurrence of the risk.

Acceptance: In some cases, a business may be forced to accept a risk. This option is possible if a business entity develops contingencies to mitigate the impact of the risk, should it occur.

When creating contingencies, a business needs to engage in a problem-solving approach. The result is a well-detailed plan that can be executed as soon as the need arises. Such a plan will enable a business organization Types of Organizations to handle barriers or blockage to its success, because it can deal with risks as soon as they arise.

Importance of Risk Management

Risks management is an important process because it empowers a business with the necessary tools so that it can adequately identify and deal with potential risks. Once a risk's been identified, it is then easy to mitigate it. In addition, risk management provides a business with a basis upon which it can undertake sound decision-making.

For a business, assessment and management of risks is the best way to prepare for eventualities that may come in the way of progress and growth. When a business evaluates its plan for handling potential threats and then develops structures to address them, it improves its odds of becoming a successful entity.

In addition, progressive risk management ensures risks of a high priority are dealt with as aggressively as possible. Moreover, the management will have the necessary information that they can use to make informed decisions and ensure that the business remains profitable.

Risk Analysis Process

Risks analysis is a qualitative problem-solving approach that uses various tools of assessment to work out and rank risks for the purpose of assessing and resolving them. Here is the risk analysis process:

1. Identify existing risks

Risk identification mainly involves brainstorming. A business gathers its employees together so that they can review all the various sources of risk. The next step is to arrange all the identified risks in order of priority. Because it is not possible to mitigate all existing risks, prioritization ensures that those risks that can affect a business significantly are dealt with more urgently.

2. Assess the risks

In many cases, problem resolution involves identifying the problem and then finding an appropriate solution. However, prior to figuring out how best to handle risks, a business should locate the cause of the risks by asking the question, "What caused such a risk and how could it influence the business?"

3. Develop an appropriate response

Once a business entity is set on assessing likely remedies to mitigate identified risks and prevent their recurrence, it needs to ask the following questions: What measures can be taken to prevent the identified risk from recurring? In addition, what is the best thing to do if it does recur?

4. Develop preventive mechanisms for identified risks

Here, the ideas that were found to be useful in mitigating risks are developed into a number of tasks and then into contingency plans that can be deployed in the future. If risks occur, the plans can be put to action.

Summary

Our business ventures encounter many risks that can affect their survival and growth. As a result, it is important to understand the basic principles of risk management and how it can be used to help mitigate the effects of risks on business entities.

More Resources

CFI offers the FMVA® Certification Financial Modeling & Valuation Analyst (FMVA)™

# data[].attributes.attachment_link.title
Risk Management - Overview, Importance and Processes

# data[].attributes.attachment_link.description
Risk management encompasses the identification, analysis, and response to risk factors that form part of the life of a business Business Life Cycle . Effective risk management means attempting to control, as much as possible, future outcomes by acting proactively rather than reactively.

# data[].attributes.body
- Políticas
- Planes
- Tolerancia a riesgo
- Cambio constante

6 preguntas básicas:
1.- ¿Qué quiero lograr?
2.- ¿Cómo me afectará?
3.- ¿Cuáles respuestas de la segunda pregunta me afectan más?
4.- ¿Qué se puede hacer al respecto de las respuestas de la tercera pregunta?
5.- ¿Las respuestas de la cuarta pregunta sirvieron?
6.- ¿Qué cambió?

# data[].attributes.attachment_link.title
Risk management basics: What exactly is it?

# data[].attributes.headline
5 pasos para realizar un proceso efectivo de risk management 

# data[].attributes.subject
5 pasos para realizar un proceso efectivo de risk management 

# data[].attributes.body
1. Identificar el riesgo

2. Analizar el riesgo

3. Priorizar el riesgo

4. Tratar, manejar el riesgo

5. Monitorear el riesgo

# data[].attributes.body
La gestión de riesgos se basa en tres procesos.
1. Conocimiento del Riesgo: Se compone de la identificación de escenarios de riesgo, el análisis y evaluación del riesgo, el monitoreo y seguimiento del riesgo y sus componentes y la comunicación para promover una mayor conciencia del mismo que alimenta los procesos de reducción del riesgo y de manejo de desastre.
2. Reducción del Riesgo: Se compone de la intervención dirigida a modificar o disminuir las condiciones de riesgo existentes y a evitar nuevo riesgo en el territorio. Son medidas de mitigación y prevención que se adoptan con antelación para reducir la amenaza, la exposición y disminuir la vulnerabilidad de las personas, los medios de subsistencia, los bienes, la infraestructura y los recursos ambientales, para evitar o minimizar los daños y pérdidas en caso de producirse los eventos físicos peligrosos. La reducción del riesgo la componen la intervención correctiva del riesgo existente, la intervención prospectiva de nuevo riesgo y la protección financiera.
3. Manejo del Desastre: Compuesto por la preparación para la respuesta a emergencias, la preparación para la recuperación posdesastre, la ejecución de dicha respuesta y la ejecución de la respectiva recuperación.

# data[].attributes.attachment_link.readable_text
De acuerdo a la Ley 1523 de 2012, la Gestión del riesgo de desastres es un proceso social orientado a la formulación, ejecución, seguimiento y evaluación de políticas, estrategias, planes, programas, regulaciones, instrumentos, medidas y acciones permanentes para el conocimiento y la reducción del riesgo y para el manejo de desastres, con el propósito explícito de contribuir a la seguridad, el bienestar, la calidad de vida de las personas y al desarrollo sostenible.
Así, la gestión del riesgo es responsabilidad de todas las autoridades a través de la implementación de los procesos de la gestión del riesgo y de los habitantes del territorio colombiano al actuar con precaución, solidaridad y autoprotección así como con el acatamiento de lo dispuesto por las autoridades
El riesgo de desastres se deriva de procesos de uso y ocupación insostenible del territorio, por tanto, la explotación racional de los recursos naturales y la protección del medio ambiente constituyen características irreductibles de sostenibilidad ambiental y contribuyen a la gestión del riesgo de desastres.
La gestión del riesgo se basa en tres procesos:
1. Conocimiento del Riesgo: Es el proceso de la gestión del riesgo compuesto por la identificación de escenarios de riesgo, el análisis y evaluación del riesgo, el monitoreo y seguimiento del riesgo y sus componentes y la comunicación para promover una mayor conciencia del mismo que alimenta los procesos de reducción del riesgo y de manejo de desastre.
2. Reducción del Riesgo: Es el proceso de la gestión del riesgo, está compuesto por la intervención dirigida a modificar o disminuir las condiciones de riesgo existentes, entiéndase: mitigación del riesgo y a evitar nuevo riesgo en el territorio, entiéndase: prevención del riesgo. Son medidas de mitigación y prevención que se adoptan con antelación para reducir la amenaza, la exposición y disminuir la vulnerabilidad de las personas, los medios de subsistencia, los bienes, la infraestructura y los recursos ambientales, para evitar o minimizar los daños y pérdidas en caso de producirse los eventos físicos peligrosos. La reducción del riesgo la componen la intervención correctiva del riesgo existente, la intervención prospectiva de nuevo riesgo y la protección financiera.
3. Manejo del Desastre: Es el proceso de la gestión del riesgo compuesto por la preparación para la respuesta a emergencias, la preparación para la recuperación posdesastre, la ejecución de dicha respuesta y la ejecución de la respectiva recuperación, entiéndase: rehabilitación y recuperación.
El riesgo corresponde a los daños o pérdidas potenciales que pueden presentarse debido a los eventos físicos peligrosos de origen natural, socio-natural, tecnológico, biosanitario o humano no intencional, en un período de tiempo específico y que son determinados por la vulnerabilidad de los elementos expuestos; por consiguiente, el riesgo de desastres se deriva de la combinación de la amenaza y la vulnerabilidad (Ley 1523 de 2012).
Es así como la amenaza, es el peligro latente de que un evento físico de origen natural, o causado, o inducido por la acción humana de manera accidental, se presente con una severidad suficiente para causar pérdida de vidas, lesiones u otros impactos en la salud, así como también daños y pérdidas en los bienes, la infraestructura, los medios de sustento, la prestación de servicios y los recursos ambientales.
Las amenazas pueden ser de origen natural, socio natural o antrópico. Las amenazas naturales, están asociadas a fenómenos naturales como la erosión costera, tsunamis, terremotos o huracanes; las amenazas de origen socionatural están relacionadas con la presencia fenómenos físicos cuya existencia está relacionada con procesos de degradación o transformación ambiental y/o de intervención humana en los ecosistemas, ejemplo las inundaciones por afectación de las coberturas vegetales de las cuencas. Por su parte, las amenazas antrópicas son las que han sido generadas por la actividad humana en la producción, distribución, transporte y consumo de bienes y servicios y en la construcción y uso de infraestructura y edificios.
De otro lado, la vulnerabilidad la susceptibilidad o fragilidad física, económica, social, ambiental o institucional que tiene una comunidad de ser afectada o de sufrir efectos adversos en caso de que un evento físico peligroso se presente. Corresponde a la predisposición a sufrir pérdidas o daños de los seres humanos y sus medios de subsistencia, así como de sus sistemas físicos, sociales, económicos y de apoyo que pueden ser afectados por eventos físicos peligrosos.

# data[].attributes.attachment_link.title
Gestión del Riesgo de Desastres | Ministerio de Ambiente y Desarrollo Sostenible

# data[].attributes.attachment_link.description
De acuerdo a la Ley 1523 de 2012, la Gestión del riesgo de desastres es un proceso social orientado a la formulación, ejecución, seguimiento y evaluación de políticas, estrategias, planes, programas, regulaciones, instrumentos, medidas y acciones permanentes para el conocimiento y la reducción del riesgo y para el manejo de

# data[].attributes.headline
Risk Management in Software Development and Software Engineering Projects

# data[].attributes.subject
Risk Management in Software Development and Software Engineering Projects

# data[].attributes.body
https://www.castsoftware.com/research-labs/risk-management-in-software-development-and-software-engineering-projects

Podemos ver algunos tipos de riesgos que se pueden encontrar en proyectos de software como lo son:

New, unproven technologies

User and functional requirements

Application and system architecture

Performance

Organizational

# data[].attributes.attachment_link.readable_text
Understanding Risk Management in Software Development

Software development is activity that uses a variety of technological advancements and requires high levels of knowledge. Because of these and other factors, every software development project contains elements of uncertainty. This is known as project risk. The success of a software development project depends quite heavily on the amount of risk that corresponds to each project activity. As a project manager, it's not enough to merely be aware of the risks. To achieve a successful outcome, project leadership must identify, assess, prioritize, and manage all of the major risks.

The goal of most software development and software engineering projects is to be distinctive-often through new features, more efficiency, or exploiting advancements in software engineering. Any software project executive will agree that the pursuit of such opportunities cannot move forward without risk.

Because risks are painfully real and quite prevalent on all software projects, it's critically necessary that stakeholders work hard to identify, understand, and mitigate any risks that might threaten the success of a project. For projects that have time and cost constraints, our experience shows most clearly that successful software development efforts are those in which risk mitigation is a central management activity.

What Is Risk In Software Engineering?

Very simply, a risk is a potential problem. It's an activity or event that may compromise the success of a software development project. Risk is the possibility of suffering loss, and total risk exposure to a specific project will account for both the probability and the size of the potential loss.

Guesswork and crisis-management are never effective. Identifying and aggregating risks is the only predictive method for capturing the probability that a software development project will experience unplanned or inadmissible events. These include terminations, discontinuities, schedule delays, cost underestimation, and overrun of project resources

What Is Risk Management In Software Engineering?

Risk management means risk containment and mitigation. First, you've got to identify and plan. Then be ready to act when a risk arises, drawing upon the experience and knowledge of the entire team to minimize the impact to the project.

Risk management includes the following tasks:

Identify risks and their triggers

Classify and prioritize all risks

Craft a plan that links each risk to a mitigation

Monitor for risk triggers during the project

Implement the mitigating action if any risk materializes

Communicate risk status throughout project

Identify and Classify Risks

Most software engineering projects are inherently risky because of the variety potential problems that might arise. Experience from other software engineering projects can help managers classify risk. The importance here is not the elegance or range of classification, but rather to precisely identify and describe all of the real threats to project success. A simple but effective classification scheme is to arrange risks according to the areas of impact.

Five Types of Risk In Software Project Management

For most software development projects, we can define five main risk impact areas:

New, unproven technologies

User and functional requirements

Application and system architecture

Performance

Organizational

New, unproven technologies. The majority of software projects entail the use of new technologies. Ever-changing tools, techniques, protocols, standards, and development systems increase the probability that technology risks will arise in virtually any substantial software engineering effort. Training and knowledge are of critical importance, and the improper use of new technology most often leads directly to project failure.

User and functional requirements. Software requirements capture all user needs with respect to the software system features, functions, and quality of service. Too often, the process of requirements definition is lengthy, tedious, and complex. Moreover, requirements usually change with discovery, prototyping, and integration activities. Change in elemental requirements will likely propagate throughout the entire project, and modifications to user requirements might not translate to functional requirements. These disruptions often lead to one or more critical failures of a poorly-planned software development project.

Application and system architecture. Taking the wrong direction with a platform, component, or architecture can have disastrous consequences. As with the technological risks, it is vital that the team includes experts who understand the architecture and have the capability to make sound design choices.

Performance. It's important to ensure that any risk management plan encompasses user and partner expectations on performance. Consideration must be given to benchmarks and threshold testing throughout the project to ensure that the work products are moving in the right direction.

Organizational. Organizational problems may have adverse effects on project outcomes. Project management must plan for efficient execution of the project, and find a balance between the needs of the development team and the expectations of the customers. Of course, adequate staffing includes choosing team members with skill sets that are a good match with the project.
Risk Management Plan
After cataloging all of the risks according to type, the software development project manager should craft a risk management plan. As part of a larger, comprehensive project plan, the risk management plan outlines the response that will be taken for each risk-if it materializes.
Monitor and Mitigate
To be effective, software risk monitoring has to be integral with most project activities. Essentially, this means frequent checking during project meetings and critical events.

Monitoring includes:

Publish project status reports and include risk management issues

Revise risk plans according to any major changes in project schedule

Review and reprioritize risks, eliminating those with lowest probability

Brainstorm on potentially new risks after changes to project schedule or scope

When a risk occurs, the corresponding mitigation response should be taken from the risk management plan.

Mitigating options include:

Accept: Acknowledge that a risk is impacting the project. Make an explicit decision to accept the risk without any changes to the project. Project management approval is mandatory here.

Avoid: Adjust project scope, schedule, or constraints to minimize the effects of the risk.

Control: Take action to minimize the impact or reduce the intensification of the risk.

Transfer: Implement an organizational shift in accountability, responsibility, or authority to other stakeholders that will accept the risk.

Continue Monitoring: Often suitable for low-impact risks, monitor the project environment for potentially increasing impact of the risk.

Communicate
Throughout the project, it's vital to ensure effective communication among all stakeholders, managers, developers, QA-especially marketing and customer representatives. Sharing information and getting feedback about risks will greatly increase the probability of project success.
Summary
Risk management is an extensive discipline, and we've only given an overview here. We leave you with a checklist of best practices for managing risk on your software development and software engineering projects:

Always be forward-thinking about risk management. Otherwise, the project team will be driven from one crisis to the next.

Use checklists, and compare with similar previous projects.

Prioritize risks, ranking each according to the severity of exposure.

Develop a top-10 or top-20 risk list for your project. Like most project managers, you can probably reuse this list on the next project!

Vigorously watch for surfacing risks by meeting with key stakeholders-especially with the marketing team and the customer.

As practicable, split larger risks into smaller, easily recognizable and readily-manageable risks.

Strongly encourage stakeholders to think proactively and communicate about risks throughout the entire project.

# data[].attributes.attachment_link.title
Risk Management in Software Development and Software Engineering Projects

# data[].attributes.attachment_link.description
Software development is activity that uses a variety of technological advancements and requires high levels of knowledge. Because of these and other factors, every software development project contains elements of uncertainty. This is known as project risk. The success of a software development project depends quite heavily on the amount of risk that corresponds to each project activity.

# data[].attributes.headline
Gestión de riesgos de software: principios y mejores prácticas

# data[].attributes.subject
Gestión de riesgos de software: principios y mejores prácticas

# data[].attributes.body
Identifique las áreas y componentes de mayor riesgo dentro de sus aplicaciones y sistemas.

Identificar la causa raíz de la mayoría de los defectos que resultan en fallas del sistema (es decir, los "defectos asesinos")

Comprender la importancia de cuantificar el riesgo de transacciones y objetos además de las pruebas basadas en riesgos.

Aprenda a optimizar la eficiencia de sus pruebas mientras amplía su cobertura

Aproveche el análisis de calidad estructural para complementar sus pruebas basadas en riesgos

Comprender la complejidad de los componentes subyacentes del sistema.

Cuantificar el grado en que han cambiado los componentes complejos del sistema.

Asegúrese de tener un cuadro de mando o tablero para medir y rastrear los niveles de riesgo de software en cada versión de sus aplicaciones más críticas.

# data[].attributes.headline
Partes que se ven en la gestión de riesgos

# data[].attributes.subject
Partes que se ven en la gestión de riesgos

# data[].attributes.body
En cuanto a la gestión de riesgos se tiene que identificar los posibles riesgos, donde se deben hacer pruebas con el fin de identificar posibles brechas en las diferentes brechas en el proceso.

Tambien se debe tener en cuenta la valoración de riesgos, ya que no todos tienen el mismo nivel de importancia.

Luego se debe tener en cuenta que las politicas presentan una manera de intentar solucionar los problemas.

Y para finalizar se tiene toda la monitorización de como se puede generar una gestión de indicadores.

# data[].attributes.body
The Casualty Actuarial Society (CAS) ERM Framework

Framework de administración de riesgos de la Sociedad Actuarial de Accidentes que define 4 tipos de riesgo:

1. Riesgos amenazantes

2. Riesgos financieros

3. Riesgos operacionales

4. Riesgos estratégicos

y siete pasos....

+ The COSO ERM Integrated Framework

+ The ISO 31000 ERM Framework
+ The COBIT ERM Framework
+ The NIST ERM Framework
+ RIMS Risk Maturity Model ERM Framework