Professional Documents
Culture Documents
Informático
Jefferson Gonzalez
15/02/2011
Análisis De Riesgo De Proyecto Informático
Introducción:
También los riesgos de seguridad de información deben ser precisos y claro en todo
negocio, y las interrelaciones con otras actitudes de negocios, tales como recursos
humanos, desarrollo, producción, operaciones, administración, TI, finanzas, etc. y los
clientes deben ser identificados para lograr una imagen global y completa de estos
riesgos personales y de negocio.
El régimen del riesgo informático es la meta principal de: “proteger y ayudar a todas las
organizaciones con sus habilidades de manejar o operar, exigir su misión” no solamente
en la protección sino también en la administración de todo lo relacionado con el régimen
que se está tratando de los elementos informáticos. Además, el proceso no solo debe de
ser tratado o manipulado por experto sino ser tratado con una función técnica, generada
por los expertos en tecnología que manipulan y administran los sistemas, sino como una
función esencial de administración por parte de toda la organización.
Cuando se va hacer el análisis de las fases, hay que alcanzar un proceso de un
proyecto, y poder visualizar el enfoque global a causa de los proyectos en las
organizaciones o en la labor profesional, que permitirá aclarar la importancia de agregar a
las tareas empresariales un desarrollo profesional, sean estas pequeñas o grandes. Con
la comprensión de los fundamentos sobre la Administración de Proyectos, debe
estudiarse las herramientas que permiten identificar e iniciar un proyecto.
El objetivo de la gestión y análisis de riesgos en los proyectos informáticos consiste en
adelantarse a lo previsto y a lo imprevistos que pueden causas de desviaciones de uno o
varios proyecto de sus metas, para ello tenemos las herramienta informática o personas
capacitada que permita considerar el riesgo de cada uno de su proyecto, de riesgo que
amenazan la formación del ajuste del proyecto informático con todas sus
especificaciones.
La Gestión De Riesgos:
Hace 10 años atrás se hablaba de la crisis del software al confirmar que una gran parte
de los grandes proyectos informáticos no obtenían a ponerse nunca en producción. Las
conclusiones eran varias. A veces estas dudas eran demasiado para el negocio, ya que la
táctica de las empresas se renovaba a grandes ritmo, produciendo la obsolescencia de
sus obligaciones iníciales comparados con las necesidades al final del proyecto.
No sabían que a veces eran problemas técnicos, bien por la velocidad de evolución de los
nuevos sistemas, o proporcionado por la variedad de entornos diferentes que no lograban
ser sometidos por los técnicos. Y averiguar cuales fueran las razones, para manifestar en
que había que buscar las medidas de servicio que nos permitieran emprender los
proyectos informáticos con más convencimiento de triunfo.
Hay dos respuestas que hay básicamente en la gestión de riesgos y estas son:
Página 2
En la primera gestión de proceso se aplica diferentes esquemas reales y por la cual
investiga a comprimir la variabilidad innecesaria que surge habitualmente cuando se
produce un producto o cuando se presta un servicio.
Y en la gestión de riesgo, es cómo explicar, de cómo perfeccionar a un evento potencial y
no queriendo que se produzca e impacte en el objetivo del proyecto. Tampoco es una
disciplina que se aplique solo en proyectos informáticos, ya que está dispuesto cada vez
más abierto en disciplinas de diferentes sectores de la actividad y muchos tipos de
proyectos.
Los proyectos informáticos requieren una actividad intelectual y creativa, que son
desarrollados por personas, que poseen un presupuesto finito a una fecha de inicio y una
fecha prevista de puesta en marcha y para conseguir metas.
En la vida de un proyecto informático pueden provocarse errores por causas humanas,
por tardar más en hacer una actividad que creíamos bien estimada, y por no terminar a
tiempo un elemento que retrasa una integración con otros elementos, etc.
El análisis de riesgo puede adelantarse a algunos problemas, y afirmarnos que si se
produce su impacto en los objetivos de proyectos será menor posible.
A veces son pocos los autorizados en los proyectos, en la cual documentan las causas
reales o fracasos de sus proyectos, haciendo que muchos directivos de los proyectos
cometan errores similares. La razón por la cual considero que las causas de cada
decepción o significativo en la gestión de proyectos, debe investigarse o documentarse y
repartirse alrededor de todos los miembros de la comunidad de proyectos informáticos.
Los riesgos tienen causas y consecuencias, si conforme para un mismo riesgo varias
causas pueden poseer la misma consecuencia. Antes de emprender un proyecto el gestor
de riesgo investiga que riesgos potenciales pueden darse. Y los detecta como riesgo
principal, y en la demora de la entrega del proyecto y satisface que tardanza puede ser
debido a varias causas:
Página 3
Causa 2: Que el jefe del proyecto no sea muy experto.
Causa 3: Que el equipo del proyecto no esté bien formado en el entorno
tecnológico del proyecto.
Como prever con anticipación el tipo de riesgo que hemos detectado antes que el
proyecto esté en marcha o empiece y como disminuirlo.
Si los requisitos no están bien definidos y debemos poner mayor esfuerzo en la
definición de estos requisitos.
Si el proyecto no es muy experto, buscamos un jefe de proyecto experto y con
experiencia exitosa.
Análisis De Riesgo
Una vez que haya reconocido los riesgos nos toca a todos estudiar planificar y adecuar el
grado determinación de su impacto de la organización de su proyecto. Puede utilizar el
análisis de riesgo para preferir un análisis a fondo y preciso para esclarecer toda clase de
riesgo de la planificación es más natural.
Si en la transcurso anterior hemos averiguados los riesgos potenciales que pueden
impresionar al proyecto, y en el transcurso tiene como objeto aclarar un análisis de
riesgo, es decir, de cómo valorar la jerarquía del riesgo, tanto desde el punto de vista
cualitativo como cuantitativo.
Fundamentalmente los dos elementos solo se los diferencia en la precisión de la
evaluación y en el ajuste de la formula de valoración de cada factor y de cada evento, o
condición o atributo.
El objetivo del análisis de riesgo es calcular o evaluar el valor que presente del riesgo
global del proyecto. Por eso se parte de una estructura arborescente como antes
indicada. Ya que los proyectos informáticos son proyectos intelectuales, y por lo tanto
siempre con riesgos. Pero el análisis de riesgos tiene como objetivo asegurarse de que el
riesgo está en el nivel aceptable para la empresa, por lo que una base de datos que
acumule la experiencia de detección de riesgos, planes desarrollados, efectividad e
impacto es vital.
Página 4
Interrelaciones externas con proveedores, cliente, regulaciones, comunidad, gobierno,
medio ambiente, etc.
Un régimen útil pero muy comprometedor porque estamos hablando sobre los riesgos de
una empresa y en determinar la “exposición a riesgos” de cada uno que haya identificado.
Una definición de riesgo es “perdida no esperada”, o la muestra al riesgo es igual a la
probabilidad de perdida no esperada multiplicada por la magnitud de la perdida, ejemplo:
si piensa que la probabilidad puede ser del 25% y puede haber un retraso de cuatro
semanas sobre la duración del proyecto, la exposición al riesgo seria 25% multiplicado por
cuatro semanas, es decir una semana.
Estimación de la magnitud de la Pérdida
Sirve para aclarar los criterios para anticipar los riesgos y establecer actividades de
control de sus operaciones con el fin de mantener o disminuir el riesgo una vez que haya
creado la lista de los riesgos de la planificación, el paso siguiente es prevalecer los
riesgos donde se va ajustar el esfuerzo para la gestión de riesgo. Los proyectos gastan el
80% de su presupuesto en arreglar el 20% de sus problemas es útil poder centrarse en
este 20% más importante.
Página 5
La responsabilidad es más fácil si se solo se razona los riesgos de planificación que se
va centrar en todos los tipos de riesgos.
El periodo que haya recolectado o calculado la exposición de riesgo multiplicando la
probabilidad de perdida por la magnitud de la perdida, ordene los riesgos según la
exposición a riesgos en su tabla de estimación de riesgos.
Facilita información para cada sector de actividad sobre los principales riesgos existentes,
indicando la importancia relativa de cada uno de ellos y también informa de las medidas
preventivas básicas que se deben adoptar para minimizar cada riesgo.
Control De Riesgos
Resolución de riesgo
Depende mucho del riesgo específico, los métodos que controlan un diseño inadecuado
no se adaptan bien al riesgo de que su equipo sea expulsado de sus oficinas y a
continuación tenemos algunos métodos relacionados con los riesgos del diseño y del
lugar de trabajo:
Evite el riesgo.- es decir, no realizar actividades arriesgadas cambiando el plan del
proyecto.
Eliminar el origen.- Ósea es el riesgo que puede cometer, si el diseño de una parte del
sistema es demasiado arriesgado.
Asuma el riesgo.- Para poder conseguir información acerca del riesgo cuando éste no
es muy conocido.
Página 6
Controle el riesgo.- Aceptar que puede ocurrir y hacer un plan de contingencias para
minimizar su exposición.
Conclusión
Anexo:
Página 7
Referencias bibliográficas
Software Engineering Risk Management. Dale Walter Karolak. IEEE Computer Society
Magerit - Metodología de análisis y gestión de riesgos en los sistemas de información.
http://www.monografias.com/trabajos73/gestion-riesgos/gestion-riesgos4.shtml
http://www.google.com/imgres?imgurl=http://www.impalarisk.com/images/enfoque
_gestion_riesgos_oport.jpg&imgrefurl=http://www.impalarisk.com/servicios/&usg=
__sAgYogeul9qV58YKYeMM4cbaQfY=&h=321&w=373&sz=23&hl=es&start=7&zoom
=1&tbnid=U5ziO0kjP3_G-M:&tbnh=105&tbnw=122&ei=oulaTcvyCsKt8Abk-
PyCDQ&prev=/images%3Fq%3DLa%2Bgesti%25C3%25B3n%2Bde%2Blos%2Briesg
os%26um%3D1%26hl%3Des%26sa%3DN%26gbv%3D2%26tbs%3Disch:1&um=1&it
bs=1
http://pages.ebay.es/internationaltrading/buyermngrisks.html
LIBRO:
Ingeniería de software
Edición: Sexta Edición
Autor: PH.D ROGER S. PRESSSMAN
AÑO PUBLICACION: 2006
Página 8