ANALISIS DE RIESGO DE PROYECTO INFORMATICO

Análisis De Riesgo De Proyecto Informático Jefferson Gonzalez Máster: RAMIREZ ANORMALIZA RICHARD IVAN 8vo, Semestre de

Views 108 Downloads 2 File size 269KB

Report DMCA / Copyright

DOWNLOAD FILE

Recommend stories

Citation preview

Análisis De Riesgo De Proyecto Informático

Jefferson Gonzalez Máster: RAMIREZ ANORMALIZA RICHARD IVAN 8vo, Semestre de Ingeniería en Sistemas.

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: a) La gestión en que los procesos intervenían en el diseño y desarrollo de los proyectos informáticos. b) La gestión de los riesgos que podían incurrir en el éxito de los objetivos del proyecto

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. La gestión de riesgo la disciplina que se aplica no es nueva, porque antes se aplicaba bajo otros nombres y desde ahí ha venido siendo utilizada por diferentes actividades. Desde que Thomas Bayes publico su ensayo sobre cómo resolver problemas en doctrinas de los cambios, en 1963, diferentes teorías han ido surgiendo y tienen renovadas aplicaciones. Como dice Elaine M. Hall, que la gestión de riesgo, puede ser un algoritmo porque son problemas en desarrollarlos, ya que son problemas matemáticos y se lo desarrolla mediante algoritmos, y el riesgo se puede desarrollar aplicando la gestión de riesgo. ¿Por qué existen riesgos en proyectos Informáticos? Porque es un arranque transitorio para crear un nuevo producto o servicio único. A diferencias de otros proyectos, ya que los proyectos informáticos tienen que cumplir con unos requisitos implícitos, y estos son: funcionales y explícitos, además pueden ser no funcionales como los tiempos de respuesta, el número máximo de usuarios que lleva el entorno informático, la aptitud de recuperación o de comunidad del servicio tras un fallo de uno o varios de sus componentes, etc. 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. El riesgo: Causas y Consecuencias. 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:  Causa 1: Que los requerimientos no estén bien definidos. 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. El análisis del entorno consiste en realizar de manera sistemática actividades de identificación y análisis de los factores claves en el entorno del proyecto. Existen diferentes tipos de entorno: 

Entorno organizacional: que comprende elementos tales como: la cultura organizacional, visión, misión, estrategias, características de la organización.



El entorno específico: el cual puede ser influenciado por el proyecto o la organización.



Entorno general: no puede ser controlado ni influenciado por el proyecto o la organización.

Este análisis se utiliza para identificar las características actuales del contexto del proyecto y también sirve para identificar las tendencias futuras del entorno que pueden influir en el proyecto. Sirve para analizar los riesgos actuales y potenciales existentes para el proyecto con el objeto de ajustarse a las nuevas características de manera eficaz. Los riesgos que pueden provenir de:

Página 4

Interrelaciones externas con proveedores, cliente, regulaciones, comunidad, gobierno, medio ambiente, etc.  Interrelaciones internas provenientes de la organización o del proyecto.  Eventos económicos, políticos, ambientales, etc.  Características tecnológicas, logísticas, temporales, de conocimiento etc. Una vez concluido nos referidos a los riesgos, es posible desarrollar un plan de gestión de riesgos para el proyecto. Exposición a riesgos 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 Algunas veces es fácil apreciar el tamaño de la perdida y te encuentras en estados de saber que probabilidad tenemos. También la estimación de pérdidas es el primer paso en la medida del riesgo. Del mismo modo consiste en la audacia de las distribuciones de probabilidades asociadas con cada uno de los riesgos. Ejemplo: Considerando 20 meses como tiempo podría saber si el proyecto se aprobará el 1 de febrero o el 1 de marzo, dependiendo del mes en que la comisión analice la propuesta del proyecto. Se supone que podría aprobarse el 1 de febrero la magnitud del riesgo para la aprobación del proyecto seria exactamente un mes. La magnitud de pérdida no es fácil apreciar directamente, se puede dividir la pérdida en pérdidas más pequeñas, ejemplo: si está utilizando tres herramientas de programación podría estimar la pérdida resultante a partir de las pérdidas que podría generar cada una. Así podría sumar las perdidas, y obtener la estimación de una forma más sencilla que la estimación global. Estimación de la probabilidad de pérdida La estimación de las probabilidades de pérdida es más relativa que la estimación de la magnitud de la perdida. Técnicas para mejorar la exactitud de esta estimación subjetiva:    

Disponer de la persona que este mas familiarizada con el sistema. Usar técnicas Delphi o de consenso en grupo. Realizar analogías con apuestas “aceptarías esta apuesta” Utilice la “calibración mediante adjetivos”

Priorización De Riesgos 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. Es una herramienta de auto información adecuada para quienes desean introducirse, de manera global, en el estudio de las condiciones de trabajo. Control De Riesgos Detallando los riesgos de su proyecto en la posibilidad de pérdidas por incumplimiento y examinado las probabilidades y magnitudes, y hay que estar preparado para controlarlos. Tres aspectos de control de riesgos:  Planificación de la gestión de riesgos.  Resolución de riesgos.  Monitorización de riesgos. Planificación de la gestión de riesgos El objetivo es decidir cómo afrontar y planificar las actividades de gestión de riesgos en el proyecto a desarrollar para que controle cada uno de los riesgos de prioridad alta. El plan de gestión de riesgos puede ser tan natural como un artículo de cada riesgo, describiendo quien, qué, cuándo y cómo se gestiona cada uno de los 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. Recordar.- Especificar los riesgo para intentos a futuros. Asuma el riesgo.- Para poder conseguir información acerca del riesgo cuando éste no es muy conocido. Comunique el riesgo.- haga saber al personal de la dirección y de marketing y a los clientes la presencia del riesgo y sus consecuencias. Intente suavizar el susto que se llevaran si llega a ocurrir.

Página 6

Controle el riesgo.- Aceptar que puede ocurrir y hacer un plan de contingencias para minimizar su exposición. Riesgo, Alto Riesgo Y Azar A veces la realidad empresarial le obliga a encargarse de un plan de desarrollo ambicioso cuando un proyecto implique muchos riesgos (vaguedad de los requisitos, personal no cualificado, arias desconocidas, elementos de investigación). Conclusión La misión de la gestión y análisis de riesgos en los proyectos informáticos es el método y herramienta que hemos explicado y puede servir de base para iniciar esta actividad, que debe mejorarse con el hábito y la base de datos de conocimiento que la experiencia acumulará.

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=oulaTcvyCsKt8AbkPyCDQ&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