exámen transversal 2010
TRANSCRIPT
re
Programa de CapacitaciónAdministración de Recursos Informáticos
Alumnos : NataliaFranciscoFelipeAngelRicardoMiguel
Profesor : chavez
Santiago
2010
DuocUCInstituto ProfesionalEscuela de Informática y Telecomunicaciones Sede Antonio Varas.
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
INDICE
Introducción
- Descripción de la situación propuesta (enunciado del examen)
- Descripción de objetivos y ámbitos del proyecto
- Descripción de la metodología de desarrollo de software (justificación, descripción de las etapas y entregables a obtener en cada etapa)
- Descripción de la estructura organizacional del equipo del proyecto (organigrama, descripción de cargos)
- Descripción del plan de recursos (hardware, software, recurso humano, infraestructura, etc)
- Descripción del plan presupuestario
- Descripción plan de riesgos
- Descripción planificación general del proyecto (etapas, actividades, recursos, tiempo, entre otros)
- Descripción de la estrategia de control y seguimiento
- Carta gantt del proyecto en MsProject
- Anexos (procedimientos, documentos de seguimiento y control, etc)
1. INTRODUCCIÓN2
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
El presente documento de proyecto esta ideado con el objetivo de ser presentado en
respuesta a la publicación realizada por la Municipalidad de Santiago, relativa a la
realización de cursos de capacitación en software de productividad, este documento fue
realizado por la empresa SICOMIN en base a dicha publicación y los requerimientos en
ella contemplados.
Se describirán ciertos puntos que permitirán tomar una decisión para la realización de
este proyecto de la mejor manera posible. Se establecerán los objetivos, metodología de
desarrollo, la estructura de la organización, el plan de recursos, el plan de presupuesto, el
plan de riesgos, planificación general del proyecto, métodos de control de avance y
duración del mismo.
3
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
2. DESCRIPCIÓN DE LA SITUACIÓN PROPUESTA
La Municipalidad de Santiago, en su proceso de ayuda y de formación a la comunidad, ha
dispuesto de cursos sobre: Windows, Word, Excel, PowerPoint, Internet y correo electrónico.
Estos cursos se enmarcan en la política municipal de apoyar la inserción laboral de los
habitantes de la comunidad, por lo que tendrán un bajo costo y serán gratuitos para aquellos
habitantes que se encuentren sin fuente laboral.
Para el proceso anterior la Municipalidad solicita el desarrollo personalizado de un software de
gestión de las actividades de capacitación que realizará (cursos, calendarización, inscripciones,
relatores, etc) con el propósito de disponer de información oportuna y actualizada de la
gestión de capacitación.
4
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
3. DESCRIPCIÓN DE OBJETIVOS Y ÁMBITOS DEL PROYECTO
SICOMIN con respecto al software de gestión y en base a la necesidad propuesta por la
Municipalidad de Santiago, desarrollará una Suite de Gestión de capacitación enfocada a
cubrir esta necesidad. La solución se basa en un software compuesto por tres módulos
principales: Módulo 1 Inscripciones y Matrículas, Módulo 2 Cursos y Calendarios, Módulo 3
Profesores y Alumnos, los que serán especificados más adelante. Con respecto a la habilitación
de la sala de capacitación, se evaluará el mejor material y mano de obra disponible, de
acuerdo a los requerimientos y especificaciones entregadas por la municipalidad, que
permitan dictar los cursos en un ambiente óptimo y que permita a los alumnos disponer del
mejor material posible, lo que será considerado nuestro objetivo general.
El proyecto estará divido en 5 conjuntos de procesos (según la metodología de PMBOK) en la
que se establecerán los siguientes objetivos específicos para cada uno de ellos:
Definir el proyecto a desarrollar (inicio)
Planificar el desarrollo de software e implementación de la sala de capacitación
(planificación)
Ejecutar el desarrollo de software y habilitación de la sala de capacitación (ejecución)
Controlar el progreso y calidad del software y sala de capacitación (control)
Cerrar el proyecto (cierre)
5
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
4. DESCRIPCIÓN DE LA METODOLOGÍA DE DESARROLLO DE SOFTWARE
4.1 Introducción:
Este plan de desarrollo de software es una versión preparada por SICOMIN que se enmarca
dentro del proyecto de cursos de capacitación de formación en materia computacional. La
información que se detalla fue extraída de la licitación del proyecto a través del portal
ChileCompras.
4.2 Propuesta:
En base a la necesidad que existe por parte de la Municipalidad de Santiago, se desarrollará
una Suite de Gestión de capacitación enfocada a cubrir esta necesidad. La solución se basa en
un software compuesto por tres módulos principales:
Módulo 1 Inscripciones y Matrículas:
Procedimiento de ingreso alumno nuevo al sistema
Evaluación y clasificación de alumnos inscritos
Asignar valores (en caso corresponda) para matrículas y cuotas.
Asignar y reserva de cupo en curso seleccionado.
Controlar cantidad de alumnos por cursos y cupos de los mismos.
Módulo 2 Cursos y Calendarios:
Gestión de nuevos cursos.
Reserva de cupos en cursos, a través de la inscripción.
Gestión de consulta de cursos.
Gestión calendarización de cursos.
Gestión (mantenedor) de actividades, materias, calificaciones, asistencia por curso.
6
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
Módulo 3 Profesores y Alumnos.
Gestión (mantenedor) de información de alumnos.
Gestión (mantenedor) de información de profesores.
Todos estos interrelacionados entre sí, compartiendo la misma información y almacenados en
una sola Base de Datos, permitiéndole al usuario poder tener control absoluto sobre cada
proceso de admisión, generar informes, enviar alertas por Mail y tener historiales de
información sobre cada módulo. Esta suite será desarrollada sobre software OpenSource lo
que implica que los costos de instalación y mantención serán accesibles para el cliente.
4.3 Beneficios:
Centralización de toda la información y acceso rápido a ella. Al usar herramientas de
OpenSource los costos de desarrollo y producción se reducen drásticamente. Permitirá la
jerarquización de usuarios, generando diferentes tipos de perfiles de acuerdo a la necesidad
que se requiera. Por Ej. Un usuario que tenga privilegios solo para generar cursos, mientras
que otros tendrán acceso a matricular alumnos etc. Esto permitirá la delegación de tareas.
4.4 Metodología de desarrollo:
Para el desarrollo de la aplicación se utilizará la metodología RUP (Rational Unified Process)
cuyos principales objetivos son asegurar la producción del software de calidad dentro de
plazos y presupuestos predecibles, además se dirige a través de casos de usos, centrado en la
arquitectura, iterativo (mini proyectos) e incremental (versiones). Entre las ventajas que
posee esta metodología se podrían mencionar las siguientes:
Aumenta la productividad de los desarrolladores.
Se centra en la producción y mantenimiento de modelos de sistemas.
7
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
Sirve de guía para utilizar UML en forma más efectiva.
Posee herramientas de apoyo a todo el proceso.
Implementa mejoras prácticas en la ingeniería de software.
Fig: Esfuerzo en actividades según fase del proyecto, según RUP.
1.1 Etapas del desarrollo:
Para el desarrollo del proyecto (y como define la metodología RUP) se centrará en 4 etapas o
fases principales: Inicio – Elaboración – Construcción – Transición, cada una de estas etapas
finaliza con un hito bien definido, las cuales pueden tener una o más iteraciones.
A continuación se detalla un breve resumen de cada etapa y los hitos de cada una de ellas.
8
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
Fase Inicio:
En esta fase desarrollará los requisitos del producto desde la perspectiva del usuario, los
cuales serán establecidos en el entregable Visión. Los principales casos de uso serán
identificados y se hará un refinamiento del Plan de Desarrollo del Proyecto. La aceptación del
cliente / usuario del artefacto o entregable Visión y el Plan de Desarrollo marcan el final de
esta fase.
Fase de Elaboración:
En esta fase se analizan los requisitos y se desarrolla un prototipo de arquitectura (incluyendo
las partes más relevantes y / o críticas del sistema). Al final de esta fase, todos los casos de uso
correspondientes a requisitos que serán implementados en la primera entrega de la fase de
Construcción deben estar analizados y diseñados (en el Modelo de Análisis / Diseño). La
revisión y aceptación del prototipo de la arquitectura del sistema marca el final de esta fase.
La revisión y entrega de todos los artefactos hasta este punto de desarrollo también se incluye
como hito. La primera iteración (en caso corresponda) tendrá como objetivo la identificación y
especificación de los principales casos de uso, así como su realización preliminar en el Modelo
de Análisis / Diseño, también permitirá hacer una revisión general del estado de los artefactos
hasta este punto y ajustar si es necesario la planificación para asegurar el cumplimiento de los
objetivos.
Fase de Construcción
Durante la fase de construcción se terminan de analizar y diseñar todos los casos de uso,
refinando el Modelo de Análisis / Diseño. El producto se construye en base las iteraciones,
cada una produciendo una entrega a la cual se le aplican las pruebas y se valida con el
cliente/usuario. Se comienza la elaboración de material de apoyo al usuario. El hito que 9
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
marca el fin de esta fase es la versión de un entregable (beta), con la capacidad operacional
parcial del producto que se haya considerado como crítica, lista para ser entregada a los
usuarios para pruebas beta.
Fase de Transición
En esta fase se prepararán dos entregas para distribución, asegurando una implantación y
cambio del sistema previo de manera adecuada, incluyendo el entrenamiento de los usuarios.
El hito que marca el fin de esta fase incluye, la entrega de toda la documentación del proyecto
con los manuales de instalación y todo el material de apoyo al usuario, la finalización del
entrenamiento de los usuarios y el empaquetamiento del producto.
1.1 Entregables del desarrollo:
A continuación se indican y describen cada uno de los artefactos que serán generados y
utilizados por el proyecto y que constituyen los entregables. Esta lista constituye la
configuración de RUP desde la perspectiva de artefactos, y que se proponen para este
proyecto.
Es preciso destacar que de acuerdo a la filosofía RUP (y de todo proceso iterativo e
incremental), todos los artefactos son objeto de modificaciones a lo largo del proceso de
desarrollo, con lo cual, sólo al término del proceso se podría tener una versión definitiva y
completa de cada uno de ellos. Sin embargo, el resultado de cada iteración y los hitos del
proyecto están enfocados a conseguir un cierto grado de completitud y estabilidad de los
artefactos.
10
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
Plan de Desarrollo del Software: Es el presente documento.
Modelo de Casos de Uso del Negocio: Es un modelo de las funciones de negocio vistas desde
la perspectiva de los actores externos (Agentes de registro, solicitantes finales, otros sistemas
etc.) permite situar al sistema en el contexto organizacional haciendo énfasis en los objetivos
en este ámbito. Este modelo se representa con un Diagrama de Casos de Uso usando
estereotipos específicos para este modelo.
Modelo de Objetos del Negocio: Es un modelo que describe la realización de cada caso de
uso del negocio, estableciendo los actores internos, la información que en términos generales
manipulan y los flujos de trabajo (workflows) asociados al caso de uso del negocio. Para la
representación de este modelo se utilizan Diagramas de Colaboración (para mostrar actores
externos, internos y las entidades (información) que manipulan, un Diagrama de Clases para
mostrar gráficamente las entidades del sistema y sus relaciones, y Diagramas de Actividad
para mostrar los flujos de trabajo.
Glosario: Es un documento que define los principales términos usados en el proyecto.
Permite establecer una terminología consensuada. .
Modelo de Casos de Uso: El modelo de Casos de Uso presenta las funciones del sistema y los
actores que hacen uso de ellas. Se representa mediante Diagramas de Casos de Uso.
Visión: Este documento define la visión del producto desde la perspectiva del cliente,
especificando las necesidades y características del producto. Constituye una base de acuerdo
en cuanto a los requisitos del sistema.
Especificaciones de Casos de Uso: Para los casos de uso que lo requieran (cuya funcionalidad
no sea evidente o que no baste con una simple descripción narrativa) se realiza una
11
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
descripción detallada utilizando una plantilla de documento, donde se incluyen:
precondiciones, post-condiciones, flujo de eventos, requisitos no-funcionales asociados.
También, para casos de uso cuyo flujo de eventos sea complejo podrá adjuntarse una
representación gráfica mediante un Diagrama de Actividad.
Especificaciones Adicionales: Este documento capturará todos los requisitos que no han sido
incluidos como parte de los casos de uso y se refieren requisitos no-funcionales globales.
Dichos requisitos incluyen: requisitos legales o normas, aplicación de estándares, requisitos de
calidad del producto, tales como: confiabilidad, desempeño, etc., u otros requisitos de
ambiente, tales como: sistema operativo, requisitos de compatibilidad, etc.
Prototipos de Interfaces de Usuario: Se trata de prototipos que permiten al usuario hacerse
una idea más o menos precisa de las interfaces que proveerá el sistema y así, conseguir
retroalimentación de su parte respecto a los requisitos del sistema. Estos prototipos se
realizarán como: dibujos con alguna herramienta gráfica o prototipos ejecutables interactivos,
siguiendo ese orden de acuerdo al avance del proyecto. Sólo los de este último tipo serán
entregados al final de la fase de Elaboración, los otros serán desechados. Asimismo, este
artefacto, será desechado en la fase de Construcción en la medida que el resultado de las
iteraciones vayan desarrollando el producto final.
Modelo de Análisis y Diseño: Este modelo establece la realización de los casos de uso en
clases y pasando desde una representación en términos de análisis (sin incluir aspectos de
implementación) hacia una de diseño (incluyendo una orientación hacia el entorno de
implementación), de acuerdo al avance del proyecto.
Modelo de Datos: Previendo que la persistencia de la información del sistema será soportada
por una base de datos relacional, este modelo describe la representación lógica de los datos
12
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
persistentes, de acuerdo con el enfoque para modelado relacional de datos. Para expresar
este modelo se utiliza un Diagrama de Clases (donde se utiliza un perfil UML para Modelado
de Datos, para conseguir la representación de tablas, claves, etc.).
Modelo de Implementación: Este modelo es una colección de componentes y los subsistemas
que los contienen. Estos componentes incluyen: ficheros ejecutables, ficheros de código
fuente, y todo otro tipo de ficheros necesarios para la implantación y despliegue del sistema.
(Este modelo es sólo una versión preliminar al final de la fase de Elaboración, posteriormente
tiene bastante refinamiento).
Modelo de Despliegue: Este modelo muestra el despliegue la configuración de tipos de nodos
del sistema, en los cuales se hará el despliegue de los componentes.
Casos de Prueba: Cada prueba es especificada mediante un documento que establece las
condiciones de ejecución, las entradas de la prueba, y los resultados esperados. Estos casos de
prueba son aplicados como pruebas de regresión en cada iteración. Cada caso de prueba
llevará asociado un procedimiento de prueba con las instrucciones para realizar la prueba, y
dependiendo del tipo de prueba dicho procedimiento podrá ser automatizable mediante un
script de prueba.
Solicitud de Cambio: Los cambios propuestos para los artefactos se formalizan mediante este
documento. Mediante este documento se hace un seguimiento de los defectos detectados,
solicitud de mejoras o cambios en los requisitos del producto. Así se provee un registro de
decisiones de cambios, de su evaluación e impacto, y se asegura que éstos sean conocidos por
el equipo de desarrollo. Los cambios se establecen respecto de la última baseline (el estado
del conjunto de los artefactos en un momento determinado del proyecto) establecida. En este
caso al final de cada iteración se establecerá una baseline.
13
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
Plan de Iteración: Es un conjunto de actividades y tareas ordenadas temporalmente, con
recursos asignados, dependencias entre ellas. Se realiza para cada iteración, y para todas las
fases.
Evaluación de Iteración: Este documento incluye le evaluación de los resultados de cada
iteración, el grado en el cual se han conseguido los objetivos de la iteración, las lecciones
aprendidas y los cambios a ser realizados.
Lista de Riesgos: Este documento incluye una lista de los riesgos conocidos y vigentes en el
proyecto, ordenados en orden decreciente de importancia y con acciones específicas de
contingencia o para su mitigación.
Manual de Instalación: Este documento incluye las instrucciones para realizar la instalación
del producto.
Material de Apoyo al Usuario Final: Corresponde a un conjunto de documentos y facilidades
de uso del sistema, incluyendo: Guías del Usuario, Guías de Operación, Guías de
Mantenimiento y Sistema de Ayuda en Línea.
Producto: Los ficheros del producto empaquetados y almacenadas en un CD con los
mecanismos apropiados para facilitar su instalación. El producto, a partir de la primera
iteración de la fase de Construcción es desarrollado incremental e iterativamente,
obteniéndose una nueva release al final de cada iteración.
14
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
5. DESCRIPCIÓN DE LA ESTRUCTURA ORGANIZACIONAL DEL EQUIPO DEL
PROYECTO
5.1 Organigrama:
El siguiente diagrama ilustra la forma en que está estructurado el grupo de trabajo para el
proyecto, además corresponde al equipo de trabajo SICOMIN.
1.1 Descripción de cargos:
Jefe de Proyecto: Su función principal es la planificación y coordinación de las actividades del
proyecto. Entre éstas, se encarga de la gestión financiera y la comunicación con el cliente.
Consultor: Su función principal corresponde a apoyar a la comprensión de los temas de
administración y gestión de los cursos, además de los temas relativos a la municipalidad. Se
comunica directamente con el jefe de proyecto y puede comunicarse con el Jefe de Desarrollo
si este lo requiere.
15
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
Contraparte Cliente: Su función principal es verificar el avance desde el punto de vista del
cliente (municipalidad), además de definir los requerimientos y su prioridad. Se comunica
directamente con el Gerente de proyecto.
Jefe de desarrollo: Su función principal es coordinar el desarrollo del software, fijar las metas,
coordinar el avance, solucionar cualquier problema en que puede impedir el avance del
desarrollo y establecer que los recursos necesarios para el desarrollo estén disponible para sus
subalternos. Se comunica directamente con el gerente de proyectos, al cual debe entregar los
estados de avance y reportar los posibles problemas ó riesgos que se puedan presentar en el
desarrollo.
Arquitecto: Su función principal es la definición de la plataforma adecuada para el desarrollo
del proyecto, esto desde el punto de vista de los requerimientos de hardware y software para
el montaje. Además se encarga del modelamiento de las estructuras de clases del software,
aplicando patrones de diseño, el modelamiento del modelo en la base de datos relacional y la
instalación y optimización de la aplicación en los servidores del cliente. Se comunica
directamente con el Jefe de Desarrollo.
Analista: Su función principal es la generación de documentación necesaria para el desarrollo
del software como la generación de diagramas de casos de uso, diagramas de actividades y
modelamiento de procesos de negocio. Se comunica directamente con el Jefe de desarrollo al
cual debe entregar los modelos.
Programador: Encargados de la codificación de la aplicación en un lenguaje determinado. Se
comunica directamente con el jefe de desarrollo al cual debe entregar los programas ó scripts
finalizados.
16
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
QA Interno: Encargado de realizar las pruebas en forma interna de la aplicación, además de
verificar el cumplimiento de los requerimientos. Puede interactuar con los programadores,
Diseñador y el Analista.
Descripción del plan de Recursos
En la siguiente tabla se enumeran y detallan los recursos que se utilizaran para el desarrollo del proyecto:
Información del Proyecto
Necesidades de Recursos Humanos Software
Necesidad Recurso Cantidad
Administración del proyecto Jefe de Proyecto 372 HH
Requerimientos Analista de Sistemas 6 HH
Diseño General Analista de Sistemas 13 HH
Diseño detallado de Interfaz Usuario
Analista de Sistemas 12HH
17
Proyecto :
Desarrollo SW Gestión actividades
de capacitaciónVentana de
Tiempo Proyecto:
10-12-2010 a 07-03-2010
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
Diseño detallado de la Base de Datos
Analista de Sistemas 12 HH
Desarrollo Programadores Computacionales
240 HH
Documentación Técnica Analista de Sistemas 24 HH
Planeación de QA Analista QA 10 HH
Pruebas QA Analista QA 40 HH
Control de Cambios y Liberación
Analista de Sistemas 10 HH
Necesidades Infraestructura Software
Necesidad Recurso Cantidad
Estaciones de trabajo de desarrollo
PC 2.9 MHz, 2 gb RAM
4
Servidor DB Desarrollo 1
Estaciones de Trabajo para pruebas
2
Servidor de Pruebas 1
Software herramienta de desarrollo
Open Source
Software para Generación documentación
Open source
Proveedor de Luz Eléctrica Chilectra
Proveedor de Internet VTR
Proveedor de Teléfono VTR
Proveedor de Agua Potable Aguas Andinas
18
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
Información del Proyecto
Necesidades de Recursos Humanos Capacitaciones
Necesidad Recurso Cantidad
Administración del Personal Director de Capacitaciones
1
Capacitación SW Profesor SW productividad
4
Administración cursos Secretaria 2
Necesidades Infraestructura Capacitaciones
Necesidad Recurso Cantidad
Estación de trabajo para Profesos PC 2.9 MHz, 2 gb RAM
4
Estaciones de trabajo alumnos
Licencias software de productividad
19
Proyecto :
Capacitaciones software de
productividadVentana de Tiempo
Proyecto:
10-12-2010 a 07-03-2010
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
20
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
Descripción del plan Presupuestario
21
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
Descripción plan de Riesgo
El siguiente plan detallara como se estructurara y realizara la gestión de riesgo:
Planificación de la gestión de riesgos. Identificación de riesgos.
Análisis cualitativo de riesgos.
Análisis cuantitativo de riesgos.
Planificación de la respuesta a los riesgos.
Seguimiento y control de riesgos.
Definición para cada punto anterior.
Planificación de la gestión de riesgos
Los integrantes del equipo de proyecto deberán centrar sus esfuerzos en planificar la cantidad de riesgo existente. Cuando se planifica el proyecto el tiempo deberá estar alineado específicamente con el plan de la gerencia del riesgo, el cuál indicará al equipo como abordar el riesgo. Por ejemplo, se debería especificar el tipo de factores potenciales de riesgo que se enfrentarán en las reuniones semanales.
En organizaciones que han desarrollado consecuencia de los procesos de manipulación del riesgo, el plan se enfocará en la adopción de estos procesos dentro de un contexto específico del proyecto dado.
Identificación de riesgos
Es un proceso para descubrir los eventos potenciales de riesgo, para evitar incidentes inesperados, el cuál debería realizarse sistemáticamente. Se deben enfocar tanto los riesgos internos como externos, los predecibles versus los no predecibles, sobre los que tenemos una medida de control versus los incontrolables, y aquellos técnicos versus los no técnicos.
A medida que el equipo gana experiencia identificando riesgos, se deberían documentar los hallazgos, como mínimo deberán hacer “checklists" (listas de revisión) de los factores de riesgos que se observaran en los proyectos típicos. Si fuera posible, los diferentes factores de riesgos se deben sopesar de acuerdo a su importancia.
Análisis cualitativo de riesgos
Los modelos de escenarios de riesgo desde el punto de vista cualitativo pueden llevarnos a predecir los eventos que pueden ocurrir en nuestros proyectos, así como su impacto en el coste o en el inventario o en los recursos que se necesitan asociar a la incidencia de un evento de riesgo particular.
22
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
Análisis cuantitativo de riesgos
Ciertamente, un análisis cualitativo de riesgo bien hecho proveerá al analista de riesgo un buen sentido de lo que encontrará en sus proyectos, ellos tendrán una mejor percepción si pueden conducir un análisis cuantitativo de riesgo por el modelo de escenarios de riesgo, haciendo una serie de análisis, que lo ayudaran a predecir cosas como el impacto en el coste y la programación de los recursos que necesitan si ocurre un evento particular de riesgo.
Planificación de la respuesta a los riesgos
La identificación y el análisis de los riesgos nos proporciona un conocimiento de cómo ocurren en el proyecto, el planificador del riesgo nos construye acciones que se deben tomar para evitarlos o para frenar sus impactos. Estas estrategias incluyen: transferencia de riesgo (también llamado riesgo desviado), disminuir el riesgo, evitarlo y la aceptación del riesgo.
Con la transferencia: planeamos transferir las consecuencias de la situación de riesgo a otro lugar, comúnmente hacemos esto cuando tomamos un seguro. Otro estándar de riesgo transfiere técnicas que incluyen garantías y contratos.
La disminución del riesgo: se enfoca en reducir el riesgo ajustando problemas que puedan elevar los niveles de riesgo.
La evasión del riesgo se reconoce como la forma de navegar por lo que hay que evitar hacer cosas que nos puedan molestar.
Seguimiento y control de riesgos
Tratar de anticiparnos antes de que ocurran eventos incómodos de riesgo. Esta es la naturaleza fundamental de asumir el riesgo, un gran ejercicio intelectual. Hay que tener claro ¡El riesgo siempre existe, pero puede ser controlado o asumido!. Con la monitorización y control, tomamos conductas para delinear el riesgo y así intentar resolver los problemas que se presenten.
23