examen transversal 2010
TRANSCRIPT
re
Programa de Capacitación
Administració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
1. INTRODUCCIÓN
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.
2
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.
3
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)
4
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.2Propuesta:
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.
5
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
• Gestión (mantenedor) de actividades, materias, calificaciones,
asistencia por curso.
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.3Beneficios:
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.4Metodologí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
6
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
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.
• 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.
4.5 Etapas del desarrollo:
7
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
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.
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
8
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
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 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.
4.6 Entregables del desarrollo:
9
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
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.
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 10
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
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 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. 11
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
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 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
12
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
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.
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.
13
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
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.
Jefe de Proyecto
Consultor Contraparte Cliente
Jefe de Desarrollo Arquitecto
Programador ProgramadorAnalista QA Interno
5.2 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
15
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
relativos a la municipalidad. Se comunica directamente con el jefe de
proyecto y puede comunicarse con el Jefe de Desarrollo si este lo requiere.
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.
16
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
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.
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
18
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
Proveedor de Agua Potable
Aguas Andinas
19
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
20
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
21
Adm de Recursos InformáticosEscuela de Ingeniería
Sede Antonio Varas
Descripción del plan Presupuestario
22
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.
23
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.
24