exámen transversal 2010

32
Programa de Capacitación Administración de Recursos Informáticos Alumnos : Natalia Francisco Felipe Angel Ricardo Miguel Profesor : chavez DuocUC Instituto Profesional Escuela de Informática y Telecomunicaciones Sede Antonio Varas.

Upload: natalia-cerda

Post on 30-Jun-2015

565 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: Exámen Transversal 2010

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.

Page 2: Exámen Transversal 2010

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

Page 3: Exámen Transversal 2010

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

Page 4: Exámen Transversal 2010

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

Page 5: Exámen Transversal 2010

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

Page 6: Exámen Transversal 2010

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

Page 7: Exámen Transversal 2010

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

Page 8: Exámen Transversal 2010

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

Page 9: Exámen Transversal 2010

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

Page 10: Exámen Transversal 2010

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

Page 11: Exámen Transversal 2010

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

Page 12: Exámen Transversal 2010

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

Page 13: Exámen Transversal 2010

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

Page 14: Exámen Transversal 2010

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

Page 15: Exámen Transversal 2010

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

Page 16: Exámen Transversal 2010

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

Page 17: Exámen Transversal 2010

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

Page 18: Exámen Transversal 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

Page 19: Exámen Transversal 2010

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

Page 20: Exámen Transversal 2010

Adm de Recursos InformáticosEscuela de Ingeniería

Sede Antonio Varas

20

Page 21: Exámen Transversal 2010

Adm de Recursos InformáticosEscuela de Ingeniería

Sede Antonio Varas

Descripción del plan Presupuestario

21

Page 22: Exámen Transversal 2010

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

Page 23: Exámen Transversal 2010

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