Thesis

Instituto Tecnol
ogico Superior de los R
os
Academia de Ingeniera en Sistemas
Computacionales
Sistema para Captura y
Seguimiento de Riesgos
Organizacionales
Tesis que presenta:
Bulmaro Lopez Narvaez
Para obtener el grado de:
Ingeniero en Sistemas Computacionales
Director de la Tesis:
Ing. Luis Antonio Lopez G omez
Balancan, Tabasco, Mexico Diciembre, 2013
c Derechos reservados por
2013
Esta investigacion fue nanciada mediante el proyecto No. TAB-2010-C19-144199 del Fondo Mixto
CONACYT-Gobierno del Estado de Tabasco.
This research was funded by project number TAB-2010-C19-144199 from Fondo Mixto
Conacyt-Gobierno del Estado de Tabasco
La tesis presentada por Bulmaro L opez Narvaez fue aprobada por:
Ing. Jorge Maga na Govea
Lic. Manuel Segovia Lopez
Ing. Luis Antonio Lopez G omez, Director
Balancan, Tabasco, Mexico, Diciembre, 2013
Con mucho amor para mis padres, por su apoyo incondicional
Agradecimientos
Doy gracias a dios por haberme permitido alcanzar este logro, por estar conmigo en todo
momento.
A mi familia por apoyarme en las diferentes etapas de mi formaci on profesional.
Doy gracias a mis compa neros, por compartir sus buenos y malos momentos a lo largo del
proyecto. Fue un placer trabajar con ustedes.
Agradezco a mi asesor, Ing. Luis Antonio L opez Gomez por haberme ayudado y apoyado a
alcanzar este logro.
Sin el apoyo de ustedes, no hubiera podido llevar a cabo este trabajo. A todos, muchas gracias.
Indice General
Indice General I
Indice de Figuras V
Indice de Tablas VII
Indice de Algoritmos IX
Resumen XI
1. Introduccion 1
1.1. Contexto del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Descripci on del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3.1. Objetivos particulares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4. Organizaci on de la tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Marco teorico 5
2.1. Conceptos basicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. IDE Visual Studio Ultimate 2010 . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2. Que es un servicio Web? . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3. Que es una aplicacion Web? . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.4. Que es Silverlight? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.5. XAML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2. Limitaciones de las aplicaciones Web . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1. Usos actuales de aplicaciones como servicios Web . . . . . . . . . . . . . . 11
2.2.2. Futuros de los servicios Web . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3. Sistemas que brindan servicios Web actuales . . . . . . . . . . . . . . . . . . . . . 13
2.3.1. @RISK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2. SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.3. CALIPSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.1. Que es el Sistema para Captura y Seguimiento de Riesgos Organizacionales? 17
2.5. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3. Enfoque sobre la Administracion de Riesgos 21
3.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2. Actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
i
3.3. Planicaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4. Identicar Riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5. Evaluar los riesgos (Cualicaci on y Cuanticacion) . . . . . . . . . . . . . . . . . . 28
3.5.1. Analisis cualitativo de riesgos . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.5.2. Planeamiento de la Respuesta. . . . . . . . . . . . . . . . . . . . . . . . . 30
3.5.3. Estrategias de Riesgos negativos o Amenazas. . . . . . . . . . . . . . . . . 31
3.5.4. Evitar el Riesgo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.5.5. Transferir el Riesgo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.5.6. Mitigar el Riesgo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.6. Estrategias de Riesgos positivos u oportunidades . . . . . . . . . . . . . . . . . . . 33
3.6.1. Explotar el Riesgo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.6.2. Compartir el Riesgo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.6.3. Mejorar el Riesgo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.6.4. Aceptar el Riesgo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.7. Monitoreo y Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.8. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4. Desarrollo del Sistema 39
4.1. Metodologa de trabajo para el desarrollo del sistema . . . . . . . . . . . . . . . . . 39
4.2. Estudio de factibilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.1. Tecnico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.1.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.1.2. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2.2. Economico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3. Descripci on del desarrollo de la aplicacion . . . . . . . . . . . . . . . . . . . . . . . 42
4.3.1. Preparacion previa sobre las herramientas a utilizar . . . . . . . . . . . . . . 42
4.3.2. Denir la funcionalidad de los nuevos m odulos de la aplicaci on. . . . . . . . 43
4.3.3. Seleccionar el software de desarrollo y el lenguaje de programaci on. . . . . . 43
4.3.4. Analizar los ECUS (Especicaci on de casos de uso) del sistema de Riesgos. . 44
4.3.5. Crear el proyecto principal a nivel de programacion sobre el IDE elegido. . . . 44
4.3.6. Creacion de la Base de Datos en MySql. . . . . . . . . . . . . . . . . . . . 45
4.3.7. Desarrollar los servicios Web. . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3.8. Crear la interfaz que sera mostrada al usuario nal. . . . . . . . . . . . . . . 48
4.3.9. Consumir los servicios Web del sistema . . . . . . . . . . . . . . . . . . . . 49
4.3.10. Detallar la presentacion de la aplicaci on. . . . . . . . . . . . . . . . . . . . 51
4.3.11. Realizar pruebas y depurar el sistema para probar su correcto funcionamiento. 51
4.3.12. Despliegue del sistema en el servidor de produccion. . . . . . . . . . . . . . 52
4.3.13. Llevar a cabo la documentaci on del sistema. . . . . . . . . . . . . . . . . . 53
5. Resultados y evaluacion de resultados 55
5.1. Etapas y evoluci on de la aplicacion . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1.1. Consulta de riesgos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1.2. Consulta de los seguimientos de un riesgo. . . . . . . . . . . . . . . . . . . 56
ii
5.1.3. Actualizaci on de los datos de seguimiento de un riesgo. . . . . . . . . . . . 58
5.1.4. Nivel de exposici on individual del riesgo. . . . . . . . . . . . . . . . . . . . 61
5.1.5. Nivel de exposici on general del riesgo. . . . . . . . . . . . . . . . . . . . . . 62
5.1.6. Graca de trazabilidad del seguimiento de riesgos. . . . . . . . . . . . . . . 63
5.1.7. Presentacion nal del m odulo de consulta de riesgos. . . . . . . . . . . . . . 64
5.2. Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6. Conclusiones y trabajo futuro 67
6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
A. Diagramas 69
A.1. Diagrama de Caso de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
A.2. Diagrama de Clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Bibliografa 75
iii
Indice de Figuras
3.1. Actividades para la administracion de Riesgos. . . . . . . . . . . . . . . . . . . . . 22
3.2. Categorias para Riesgos relacionados con proyectos. . . . . . . . . . . . . . . . . . 26
3.3. Estrategias de Riesgos negativos o amenazas. . . . . . . . . . . . . . . . . . . . . . 31
4.1. Estructura general del proyecto por capas. . . . . . . . . . . . . . . . . . . . . . . 45
4.2. Servicios web expuestos para el uso del sistema. . . . . . . . . . . . . . . . . . . . 48
4.3. Creaci on de un nuevo elemento para la interfaz de la aplicaci on. . . . . . . . . . . . 49
4.4. Conguraci on basica del IIS que contiene los servicios web en ejecucion. . . . . . . . 50
4.5. Ejemplo de validaci on sobre campos vacos. . . . . . . . . . . . . . . . . . . . . . . 52
4.6. Acceso al servidor de producci on a traves del escritorio remoto. . . . . . . . . . . . 53
5.1. Lista de riesgos registrados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.2. Actividades de tratamiento del riesgo seleccionado. . . . . . . . . . . . . . . . . . . 57
5.3. Lista de riesgos registrados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.4. Lista de seguimientos del riesgo seleccionado. . . . . . . . . . . . . . . . . . . . . . 58
5.5. Actualizar el seguimiento de un riesgo. . . . . . . . . . . . . . . . . . . . . . . . . 59
5.6. Datos del seguimiento del riesgo seleccionado. . . . . . . . . . . . . . . . . . . . . 59
5.7. Mensaje de conrmaci on de actualizaci on del seguimiento de un riesgo. . . . . . . . 60
5.8. Matriz de riesgo de color respecto a la probabilidad y el impacto del riesgo. . . . . . 61
5.9. Color que se le debe dar al semaforo del riesgo de acuerdo al nivel de exposicion
general calculado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.10. Exposici on general del riesgo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.11. Trazabilidad del riesgo seleccionado. . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.12. Integracion nal del m odulo de captura y seguimiento Riesgos. . . . . . . . . . . . . 65
A.1. Diagrama de caso de usos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
A.2. Administraci on de Riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
A.3. Servicios Web del Riesgo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
A.4. Consultar usuario Riesgo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
A.5. Registrar usuario responsable del Riesgo . . . . . . . . . . . . . . . . . . . . . . . . 73
A.6. Asignar usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
v
Indice de Tablas
3.1. Clasicaci on de alto nivel de las fuentes de un riesgo. . . . . . . . . . . . . . . . . 27
3.2. Escala de impacto para Amenazas. . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3. Escala de impacto para Oportunidades. . . . . . . . . . . . . . . . . . . . . . . . . 29
vii
Indice de Algoritmos
1. Fragmento de c odigo para generar el esquema base de datos. . . . . . . . . . . . . 46
2. Fragmento de c odigo que representa una tabla en una base de datos. . . . . . . . . 46
ix
Resumen
Sistema para Captura y Seguimiento de Riesgos
Organizacionales
por
Ingeniero en Sistemas Computacionales de la Academia de Ingeniera en Sistemas Computacionales
Instituto Tecnol ogico Superior de los Ros, 2013
Ing. Luis Antonio Lopez G omez, Director
Las empresas de hoy en da viven en un mundo global competitivo que necesitan aplicaciones
para satisfacer las necesidades de negocio que son cada vez mas complejas. Con el avance de
las tecnologas web y la Internet se han abierto nuevas oportunidades para los desarrolladores de
aplicaciones empresariales permitiendoles el uso de las nuevas tecnologas web en el desarrollo de
aplicaciones mucho mas robustas, escalables y con un mayor rendimiento.
Actualmente la empresa Integra IT Soluciones se enfrenta a la necesidad de administrar y
controlar todas las actividades que se realizan dentro de la misma, tales como desarrollo de Software,
innovacion, entre otras, asi como la planicacion y realizacion de proyectos de diferente ndole, y
mantenerse alerta en caso de riesgos en los procesos.

Esta necesidad puede cubrirse mediante el
desarrollo de un Sistema para Captura y Seguimiento de Riesgos Organizacionales utilizando nuevas
tecnologas para el desarrollo de aplicaciones web.
En este trabajo de tesis se desarrolla un Sistema para Captura y Seguimiento de Riesgos
Organizacionales a traves de aplicaciones web, que permita la planicaci on, identicaci on y evaluaci on
de Riesgos que amenazen a la organizacion, asi como llevar un control bien documentado y un
seguimiento de los Riesgos ya sea que suceden o que nunca lleguen a darse. Esto permitira determinar
cuales son los riesgos mas probables que afectan el proyecto y documentar sus caractersticas.
xi
1
Introduccion
En este Captulo vamos a analizar la problematica y justicacion planteada, los objetivos generales
y especcos que se desean alcanzar y los alcances y limitaciones que abarca el desarrollo de esta
aplicacion; nalmente analizaremos de forma breve la organizacion de la tesis.
1.1 Contexto del proyecto
Las empresas de la actualidad, debido a la gran cantidad de informacion que manejan, no solo
de los empleados que tienen sino tambien de los procesos internos que en esta se realizan, se ven
en la necesidad de administrarse de la mejor manera para llevar un control general y tomar medidas
en caso de que haya alg un imprevisto no planeado, sobre todo si trabajan con proyectos a corto,
mediano o largo plazo.
Es por eso que, Integra IT Soluciones realiz o una aplicaci on llamada Sistema para Captura
y Seguimiento de Riesgos Organizacionales. El objetivo de esta aplicaci on es optimizar el grado
del cumplimiento de los objetivos, as como el rendimiento de las actividades de una empresa en
1
2 1.2. Descripcion del problema
terminos de su plan estrategico haciendo uso de un sistema de control de Riesgos que mediante
indicadores, gracas y pantallas de consulta, permita llevar un control exacto de cada uno de los
riesgos que pudieran surgir en un determinado periodo de tiempo, y mitigarlos para que no afecten
a la organizacion. Todo esto mediante una interfaz intuitiva y amigable y sobre todo facil de usar
para el usuario nal.
El Sistema para Captura y Seguimiento de Riesgos Organizacionales es una aplicacion de tipo
Web que sera utilizada por empresas generalmente del tipo Pyme, ya que este sistema esta orientado
principalmente a este tipo de empresas, la raz on de esto es porque en la actualidad existen servicios
similares pero solo para empresas grandes.
La aplicaci on sera desarrollada con Silverlight y .Net, sera una aplicaci on compatible con cualquier
navegador y tambien con m ultiples sistemas operativos. Las empresas que hagan uso de esta
aplicacion solo tendran que descargar e instalar el plug-in de Silverlight que no pesa mas de 5
Mb y acceder al sistema va Web.
1.2 Descripcion del problema
La principal raz on para crear esta aplicaci on es que en las empresas se ha tenido un gran impacto
negativo al no controlar los riesgos organizacionales que se dan por diferentes factores, por lo cual
Integra IT Soluciones ha decidido realizar este sistema, el cual tiene como funcion principal, mitigar
estos riesgos lo cual sera de gran utilidad a las empresas y al usuario nal.
Este sistema benecia principalmente a las PYMEs ya que podran hacer una planeaci on
estrategica correcta y ejecutarla en tiempo y forma siguiendo su plan estrategico y llevando un
control mediante el sistema de seguimiento de Riesgos organizacionales.
El hecho de que las empresas no cuenten con una herramienta de este tipo, seg un estudios
realizados por Integra IT Soluciones, afecta principalmente el rendimiento de la organizaci on,
1. Introduccion 3
disminucion de la calidad y en consecuencia la perdida de clientes, es por eso que es de suma
importancia que se lleve a cabo con exito el desarrollo de este sistema.
1.3 Objetivos
Desarrollar un sistema de software (Sistema para Captura y Seguimiento de Riesgos
Organizacionales) para el control y gesti on de riesgos, mediante la captura y seguimiento de estos.
1.3.1 Objetivos particulares
Con la nalidad de cumplir con el objetivo general, se denieron los siguientes objetivos
particulares:
1. Denir la funcionalidad de los m odulos del sistema.
2. Seleccionar el software de desarrollo y el lenguaje de programaci on.
3. Analizar los ECUS (Especicaci on de casos de uso) del sistema de Riesgos.
4. Crear el proyecto principal a nivel de programacion sobre el IDE elegido.
5. Creaci on de la Base de Datos en MySql.
6. Desarrollar los servicios web.
7. Crear la interfaz que sera mostrada al usuario nal.
8. Consumir los servicios Web para que la aplicaci on pueda funcionar.
9. Detallar la presentaci on de la aplicaci on.
10. Realizar pruebas y depurar el sistema para probar su correcto funcionamiento.
11. Hacer un despliegue del sistema en el servidor de producci on.
12. Llevar a cabo la documentacion del sistema.
4 1.4. Organizacion de la tesis
1.4 Organizacion de la tesis
Este documento se compone de 5 captulos y 2 apendices, los cuales tienen la siguiente
distribuci on:
La seccion 2 explica a detalle la arquitectura de software, se describen las aplicaciones que ofrecen
un servicio similar y las diferencias, se dan a conocer las tecnologas para la realizacion de sistema tales
como .Net, Silverlight, MySql, y se muestra una breve rese na sobre los servicios web y la importancia
que tienen en la actualidad, en el captulo 3 se describe la metodologa usada para el desarrollo del
sistema; esto comprende todo lo relacionado a validaciones, dise no de interfaz, creaci on de Servicios
web entre otros, en el captulo 4 se presentan los resultados obtenidos del sistema as como las
secci ones que se llevaron a cabo para culminar con el proyecto, en el captulo 5 se presentan las
conclusiones y trabajos futuros, en el Apendice A se presentan los casos de uso necesarios en esta
aplicacion.
1.5 Resumen
En este captulo se describieron algunas de las tendencias y necesidades de negocio de las empresas
de hoy en da para poder permanecer en un mundo global competitivo, as como las oportunidades que
proveen las nuevas tecnologas de desarrollo web a los desarrolladores de aplicaciones empresariales;
tambien se describi o la necesidad que tiene Integra IT Soluciones de desarrollar esta aplicaci on para
uso dentro de la misma empresa y como software rentable hacia otras organizaciones.
Finalmente se plantea como objetivo general desarrollar un Sistema para Captura y Seguimiento
de Riesgos Organizacionales a traves de aplicaciones web utilizando diversas tecnologas como
Silverlight y C# bajo el entorno de desarollo de Visual Studio 2012.
2
Marco teorico
En el desarrollo de este captulo, se hablara del marco te orico, el cual fundamenta esta
investigaci on y proporciona los conceptos basicos y complementarios que aportaran al lector una
idea mas clara acerca de este tema.
2.1 Conceptos basicos
En esa secci on se deniran los conceptos basicos mas relevantes de este proyecto, los cuales son
indispensables para que el lector tenga una idea mas clara de como se desarroll o el sistema y de las
herramientas de programaci on que se utilizaron.
2.1.1 IDE Visual Studio Ultimate 2010
Visual Studio Ultimate 2010 es una soluci on de desarrollo de vanguardia que permite a los equipos
de todos los tama nos dise nar y crear aplicaciones atractivas del gusto de los usuarios. Las herramientas
de planeacion agiles y exibles, como planeaci on de la capacidad, paneles de tareas y administracion
de trabajos pendientes permiten usar tecnicas de desarrollo incremental y metodologas agiles al
5
6 2.1. Conceptos basicos
ritmo del desarrollador sin menor esfuerzo.
Visual Studio utiliza herramientas avanzadas de modelado, deteccion y arquitectura para describir
el sistema y asegurase de que se conserva la visi on de la arquitectura en la implementaci on. A une
equipos de desarrollo y operaciones mediante el uso de IntelliTrace en producci on, Conector de
Operations Manager y Preemptive Analytics. Mejora la calidad y reduce el tiempo de resoluci on
generando errores interactivos del software implementado, permite trabajar ecazmente con el equipo
de operaciones para proporcionar datos que ofrezcan a los desarrolladores una perspectiva mas amplia
de los problemas de produccion.
Las novedades que brinda este IDE son muy variadas y es compatible con otras muchas tecnologas
de desarrollo de interfaces muy amigables como Silverlight, Telerik, entre otras.
2.1.2 Que es un servicio Web?
Hay tantas deniciones de servicios Web como compa nas que los construyen, una posible sera
hablar de ellos como un conjunto de aplicaciones o de tecnologas con capacidad para interoperar en
la Web. Estas aplicaciones o tecnologas intercambian datos entre s con el objetivo de ofrecer unos
servicios. Los proveedores ofrecen sus servicios como procedimientos remotos y los usuarios solicitan
un servicio llamando a estos procedimientos a traves de la Web.
Para ampliar un poco mejor el concepto de servicios Web citaremos una exposici on del Doctor
Marcos Escobar: Un Web Service es un componente de software que se comunica con otras
aplicaciones codicando los mensaje en XML y enviando estos mensaje a traves de protocolos
estandares de Internet tales como el HTTP [4]. Intuitivamente un servicio Web es similar a un
sitio Web que no cuenta con un interfaz de usuario y que da servicio a las aplicaciones en vez de a
las personas.
2. Marco teorico 7
Un servicio web, en vez de obtener solicitudes desde el navegador y retornar paginas Web como
respuesta, lo que hace es recibir solicitudes a traves de un mensaje formateado en XML desde una
aplicacion, realiza una tarea y devuelve un mensaje de respuesta tambien formateado en XML.
2.1.3 Que es una aplicaci on Web?
Cuando hablamos de una aplicacion Web nos referimos a aquellas herramientas que el usuario
puede utilizar accediendo a un servidor web a traves de internet mediante el uso de una computadora
personal, y como es obvio utilizado un navegador Web.
En los primeros tiempos de la computaci on, cada aplicaci on tena su propio programa cliente
que serva como interfaz de usuario que tena que ser instalado por separado en cada computadora
personal de cada usuario. El cliente realizaba peticiones a otro programa, en este caso a un servidor
que le daba respuesta. Una mejora en el servidor, como parte de la aplicacion, requera normalmente
una mejora de los clientes instalados en cada computadora personal, a nadiendo un coste de soporte
tecnico y disminuyendo la productividad, esto hacia que las empresas gastaran mas y era una de las
principales inconveniencias en ese tipo de aplicaciones [7].
A diferencia de lo anterior, las aplicaciones Web generan dinamicamente una serie de paginas
en un formato estandar, como HTML o XHTML, soportados por los navegadores Web comunes.
Se utilizan lenguajes interpretados en el lado del cliente, directamente o a traves de pulg-ins tales
como JavaScript, Java, Silverlight, etc., para a nadir elementos dinamicos a la interfaz de usuario.
Generalmente cada pagina Web en particular se enva al cliente como un documento estatico, pero
la secuencia de paginas ofrece al usuario una experiencia interactiva. Durante la sesi on, el navegador
Web interpreta y muestra en pantalla las paginas, actuando como cliente para cualquier aplicacion
web.
Las aplicaciones web son populares debido que los navegadores de hoy en da, como es de esperarse
son realmente sencillos de utilizar y tienen muchas ventajas como por ejemplo la independencia del
sistema operativo, as como la facilidad para actualizar y mantener aplicaciones web sin distribuir e
instalar software a miles de usuarios potenciales, esto los convierte en una herramienta muy capaz y
de gran utilidad para las corporaciones de hoy en da. Una estrategia que esta emergiendo para las
empresas proveedoras de software consiste en proveer acceso va web al software. Para aplicaciones
previamente distribuidas, como las aplicaciones de escritorio, se puede optar por desarrollar una
aplicacion totalmente nueva o simplemente por adaptar la aplicaci on para ser usada con una interfaz
web. Estos ultimos programas permiten al usuario pagar una cuota mensual o anual para usar la
aplicacion, sin necesidad de instalarla en la computadora del usuario y esta es una gran ventaja. A
esta estrategia de uso se la denomina Software como servicio y a las compa nas desarrolladoras se
les denomina Proveedores de Aplicaciones de Servicio (ASP por sus siglas en ingles), un modelo de
negocio que esta atrayendo la atencion de la industria del software.
2.1.4 Que es Silverlight?
Silverlight es una poderosa herramienta de desarrollo para la creaci on de interfaces de usuario
atractivas e interactivas para la Web y aplicaciones m oviles. Silverlight es un plug-in gratuito,
impulsado por el framework. NET y compatible con m ultiples navegadores, dispositivos y sistemas
operativos, ofreciendo un nuevo nivel de interactividad donde funciona la Web. La principal raz on
por la que se eligi o desarrollar la interfaz de usuario con Silverlight es porque es una herramienta muy
sencilla de utilizar, y con la cual se pueden crear interfaces realmente robustas, cumpliendo as las
exigencias de los usuarios nales.
Silverlight permite utilizar el lenguaje al que el lector esta acostumbrado para programar cosas
nuevas. Nuevas interfaces, basadas en los avances del lenguaje XAML, que ahora se encuentra
totalmente soportado por Visual Studio 2010 (incluyendo su dise nador visual), de la misma forma
que la ultima versi on de Expression Blend (4.0) soporta la edicion de c odigo en C#, algo que no
2. Marco teorico 9
estaba disponible cuando en versiones anteriores del lenguaje.
Para la ejecuci on de un sistema como el que se presenta solo basta con instalar el plug-in de
Silverlight que pesa no mas de 5 Mb y con esto como unico requisito ya podemos correr la aplicaci on
en cualquier sistema con cualquier navegador Web.
Las principales ventajas de Silverlight son las siguientes:
Lenguaje mas potente, basado en WPF y .Net fx 3.0
Herramientas de desarrollo mas completas: Visual Studio y Expression Suite.
Aceleraci on por hardware mediante el uso de DirectX.
Silverlight, a diferencia de otras tecnologas Web del lado del Servidor (por ejemplo: ASP.NET,
PHP, etc.), es una tecnologa del lado del Cliente, es decir, todo el c omputo y ejecuci on de las
aplicaciones sucede en el equipo del usuario, tal y como si se tratase de cualquier tipo de aplicaci on
instalada. Esto es una gran ventaja ya que Silverlight puede sacar provecho de las caractersticas de
procesamiento del hardware en donde esta instalado. Con lo anterior podemos deducir que Silverlight
es una gran apuesta para ser una tecnologa que sea capaz de ejecutar de la misma manera, en
diferentes lugares: en los tres tipos de pantalla mas comunes en la vida de las personas hoy en
da (equipos de computo tradicionales como PCs o Laptops, Televisores y telefonos moviles). Un
mismo codigo ejecutando en diferentes dispositivos, con diferentes resoluciones, con caractersticas
de hardware diferente.
Es de gran importancia esto ya que los desarrolladores podran reutilizar sus conocimientos
existentes en tecnologa .NET para poder construir soluciones que lleguen a mas personas y en
lugares donde antes esto no era posible.
2.1.5 XAML
XAML es el subconjunto de WPF que dene los elementos en el navegador para crear la interfaz
de usuario. Esto supone crear gracos, animaciones y elementos multimedia, y otras caractersticas de
cliente enriquecido, permitiendo ir mas alla de lo que HTML permite, es el lenguaje de programacion
de interfaces por excelencia de Silverlight.
El lenguaje de marcado de aplicaciones extensibles o XAML es un lenguaje de marcado basado
en XML desarrollado por Microsoft. XAML es el lenguaje que se usa para la presentaci on visual de
las aplicaciones desarrolladas con Silverlight y otras herramientas como Microsoft Expression Blend,
del mismo modo que HTML es el lenguaje que se usa para la presentacion visual de las paginas Web.
La creaci on de aplicaciones en Silverlight supone tener que escribir c odigo XAML, ya sea de forma
manual o visualmente mediante la vista de dise no de Visual Studio Ultimate 2010.
Una de las ventajas principales de este lenguaje es que no es necesario comprender el c odigo
XAML para crear aplicaciones en Silverlight si se trabaja en la vista Dise no, ya que los controles que
emplea son muy faciles de utilizar y por lo tanto es muy sencillo crear una aplicacion muy amigable
con este lenguaje de programacion.
XAML fue dise nado para soportar las clases y metodos de la plataforma de desarrollo .NET
que tienen relaci on con la interacci on con el usuario, en especial el despliegue en pantalla. El
acr onimo XAML originalmente signicaba Extensible Avalon Markup Language, Lenguaje Extensible
de Formato de Avalon; habiendo sido Avalon el nombre clave original de la Base de Presentacion de
Windows, nombre que engloba a este grupo de clases de .NET.
2. Marco teorico 11
2.2 Limitaciones de las aplicaciones Web
Una de la de las principales limitaciones a las que se ven sometidas las aplicaciones Web es
que su estructura y desarrollo tiene que ser muy sosticado en cuanto a seguridad ya que al estar
alojadas en la red de internet, de alguna manera se puede decir que estan vulnerables. Otra limitante
o desventaja es que habitualmente ofrecen menos funcionalidades que las aplicaciones de escritorio.
Se debe a que las funcionalidades que se pueden realizar desde un navegador son mas limitadas
que las que se pueden realizar desde el sistema operativo. Pero cada vez los navegadores estan mas
preparados para mejorar en este aspecto.
La aparici on de lenguajes de programaci on para interfaces Web como HTML 5 representa un hito
en este sentido. Es posible a nadir funcionalidades a estas aplicaciones gracias al uso de Aplicaciones
de Internet Enriquecidas.
Otra desventaja importante es que la disponibilidad depende de un tercero, el proveedor de la
conexi on a internet o el que provee el enlace entre el servidor de la aplicacion y el cliente. As que
la disponibilidad del servicio esta supeditada al proveedor. Cabe mencionar que al depender de una
conexi on a internet, si esta se interrumpe, la aplicaci on dejara de funcionar momentaneamente, sin
embargo las empresas de hoy en da contrarrestan estas desventajas ofreciendo cada vez un servicio
de internet mas sosticado y eciente.
2.2.1 Usos actuales de aplicaciones como servicios Web
Los servicios mas comunes que en la actualidad utilizamos son muy variados, pero por mencionar
unos cuantos, se encuentra entre ellos las muy conocidas cuentas de correo electronico, que las
empresas mismas pueden personalizar con un dominio propio para uso de sus trabajadores.
Otro uso muy com un es el hecho de almacenar datos en la Web en sitios que ofrecen servicios
12 2.2. Limitaciones de las aplicaciones Web
como Dropbox. El servicio cliente de Dropboxpermite a los usuarios dejar cualquier archivo en
una carpeta designada. Ese archivo es sincronizado en la nube o en la Web y en todas las demas
computadoras del cliente de Dropbox [5]. Los archivos en la carpeta de Dropbox pueden entonces
ser compartidos con otros usuarios de Dropbox, ser accedidos desde la pagina Web de Dropbox o
bien ser consultados desde el enlace de descarga directa que puede ser consultado tanto de la versi on
web como desde la ubicacion original del archivo en cualquiera de las computadoras en las que se
encuentre. Asimismo, los usuarios pueden grabar archivos manualmente por medio de un navegador
web [3].
Este servicio es uno de los mas populares, ya que el usuario no tiene que traer una computadora
consigo para tener siempre al alcance todos sus archivos y su informaci on personal, basta con una
conexi on a internet para manipular todos sus datos personales y demas.
Al igual que Dropbox hay muchos servicios mas que son ofrecidos a traves de la Web y que
son muy faciles de utilizar, la simplicidad de estos servicios es lo que hace que sean tan populares
y que las empresas los adopten para utilizarlos como plataformas para su desempe no diario y para
administrase en el espacio laboral.
2.2.2 Futuros de los servicios Web
El trabajo sobre la plataforma de servicios Web continuara en el futuro, y apareceran mejoras en
tres areas fundamentales. En primer lugar, se a nadiran servicios de mas alto nivel. Todo el mundo
esta de acuerdo en que debe existir un modo estandar de seguridad de servicios Web, enrutar
mensajes, garantizar una entrega able de mensajes, denir semantica transaccional, etc. Estas
caractersticas de prop osito general se expanden mas alla de los dominios del problema y no hay
ninguna raz on por la que cada desarrollador de servicios Web deba implementarlas individualmente.
En segundo lugar, seguiran estandarizandose especicaciones. El ciclo de vida de las
2. Marco teorico 13
especicaciones de servicios Web tpicamente progresa desde una propuesta hasta un estandar de
facto y desde este hasta un estandar real. Las empresas siguen proponiendo nuevas especicaciones
como a nadidos a la plataforma de servicios Web y la industria en su conjunto necesitara acordar
cuales adoptar. Esas especicaciones necesitaran a continuacion ser estandarizadas.
En tercer lugar, los kits de herramientas y marcos de trabajo seguiran mejorando. Ademas
de servicios de mas alto nivel como la seguridad y los objetos adjuntos, se a nadira soporte para
protocolos de transporte alternativos como SMTP o TCP [2]. De modo mas importante, los modelos
de programacion migraran desde los servicios de tipo RPC hacia servicios centrados en documentos,
para promover un acoplamiento debil. Todos estos cambios ocurriran en paralelo, mientras los
desarrolladores contin uan desarrollando e implantando sistemas basados en servicios Web.
2.3 Sistemas que brindan servicios Web actuales
En la actualidad encontramos una gran variedad de sistemas que brindan servicios Web, sin
embargo los que estan dise nados para la administraci on de una empresa, como para darle seguimiento
a una planeaci on estrategica o llevar un control de riesgos son muy escasos y si los hay son demasiado
caros, y para una empresa del tipo PYME le es muy costoso invertir en un servicio de este tipo, a
continuaci on se mencionan algunos ejemplos de sistemas que se utilizan como servicios Web que se
enfocan en la administracion estrategica de una unidad organizacional.
2.3.1 @RISK
@RISK es un sistema que realiza el analisis de riesgo de una empresa utilizando simulaci on
de Monte Carlo [6] para mostrar una gran cantidad de escenarios posibles en una hoja de Excel;
tambien informa al usuario que tan factibles son estos escenarios. Gracias a esto los empresarios
pueden evaluar que riesgos tomar y cuales evitar. De esta forma con @RISK una empresa se puede
contestar preguntas como las siguientes: Cual es la probabilidad de que las utilidades sean mas de
$10 millones? Cuales son las posibilidades de perder dinero en cierto proyecto?, todo esto es lo que
14 2.3. Sistemas que brindan servicios Web actuales
las empresas esperan de sistemas de software como el que se ha desarrollado, sin embargo @RISK es
un sistema muy caro y una empresa peque na no podra invertir en una herramienta como esta.
Por otra parte cabe mencionar que el analisis de riesgo es uno de los puntos mas importantes
en los que se enfocan las empresas de hoy en da, El analisis de riesgo es el uso sistematico de la
informaci on disponible para determinar la frecuencia con la que determinados eventos se pueden
producir y la magnitud de sus consecuencias.
Los riesgos normalmente se denen como eventos negativos, como puede ser la perdida de dinero
en una empresa o una tormenta que genera un gran n umero de reclamaciones de seguro. Sin embargo,
durante el proceso de analisis de riesgo tambien se pueden descubrir resultados potenciales positivos.
Mediante la exploracion de todo el espacio de posibles resultados para una situaci on determinada,
un buen analisis de riesgo puede identicar peligros y descubrir oportunidades.
2.3.2 SAP
SAP (Sistemas, Aplicaciones y Productos para Procesamiento de Datos) es un software para
aplicaciones de negocios que, por la colaboracion con ejecutivos de negocios e IT y teniendo socios
en todo el mundo SAP desarroll o una forma unica de comprender los desafos encontrados en la
implementaci on de soluciones tecnologicas para usuarios de negocios, desarrollando software que
puede ayudar las compa nas a integrar sus procesos de negocios ayudando a toda la empresa a
funcionar mas ordenadamente. Los sistemas versatiles y modulares pueden ser rapida y facilmente
adaptados a nuevos procesos de negocios de forma que crezca su capacidad a medida que crece el
negocio.
El SAP es un sistema considerado como una herramienta esencial en industrias como la del
petroleo, la qumica, productos de consumo y alta tecnologa y electr onica, sin embargo una de sus
principales desventajas al igual que la mayora de los sistemas que cumplen este n es su precio
2. Marco teorico 15
elevado el cual evita que empresas peque nas puedan adquirirlo.
2.3.3 CALIPSO
Calipso es una compa na dedicada al desarrollo y comercializacion de software de gesti on para
empresas, mismo que es utilizado como un servicio para otras empresas que necesitan mejorar,
llevando un control estricto de sus planeaciones y gestion de riesgos.
Desde sus comienzos, se focaliza en brindar a sus clientes soluciones en las que prevalece el
concepto de exibilidad y adaptabilidad, posibilitandose as, un desarrollo optimo dentro de un
mercado altamente competitivo y en constante evolucion.
Los servicios que brinda la empresa para benecio de otras organizaciones son muy variados pero
entre ellos se encuentran:
Comercio Local e Internacional
Consultora
Investigaci on y desarrollo de Software
Implementaci on de proyectos
Administraci on y operaciones
De estas divisiones funcionales se desprende una vasta labor por construir una s olida estructura
no solamente en el plano comercial, sino tambien para la atencion de clientes y la puesta en marcha
de los proyectos.
En Calipso se dedican principalmente a mejorar el desempe no y gerenciamiento para poder ofrecer
un producto que compita a nivel internacional, no solo en el aspecto tecnol ogico, sino tambien en
lo profesional, dando a las organizaciones una herramienta de vital importancia para subsistir en el
campo laboral de la actualidad.
16 2.4. Antecedentes
2.4 Antecedentes
En la actualidad la forma de vida que se esta adoptando para mantenerse en un nivel competitivo
principalmente por las empresas es muy sosticado, el internet se ha convertido en el principal puente
de comunicacion entre las empresas y los servicios que estas utilizan, por otra parte la mayora de
los servicio que las empresas utilizan son servicios que se encuentran alojados en internet, de ah el
nombre de servicios Web.
Normalmente los servicios web no son para uso p ublico o no estan facilmente accesibles para jugar
con ellos. Son las aplicaciones las que acceden internamente para transmitir datos. Los sistemas que
se desarrollan en la actualidad van enfocados a este tipos de servicios y de esta manera se logra que
una empresa no tenga que comprar un software o un sistema, sino mas bien la empresa solo compra
el servicio y este siempre se encuentra en internet esperando a que cualquiera conecte con el para
solicitarle datos y es de esta manera como las empresas se comunican y se administran ecazmente
y en todo momento, solo con tener acceso a internet.
Sin embargo nada de esto sera posible sin las computadoras ya que gracias a estas poderosas
maquinas, se pueden llevar a cabo grades tareas, que es casi imposible hacerlas sin la intervenci on de
un equipo de c omputo. La historia de las computadoras se remonta hasta antes de la introducci on
del microprocesador a principios de los a nos 1970, para esa epoca las computadoras generalmente
eran sistemas grandes y costosos cuyos due nos eran grandes corporaciones, universidades,
agencias gubernamentales, e instituciones de tama no similar. Los usuarios nales generalmente no
interactuaban directamente con la maquina, sino que preparaban tareas para el computador, en
equipos fuera de lnea como perforadoras de tarjetas. Varias asignaciones para la computadora seran
recogidas y procesadas en proceso por lotes. Despues de que el trabajo hubiera terminado, los usuarios
podan recoger los resultados. En algunos casos podra tardar horas o das entre someter un trabajo
al centro de computaci on y la recepci on de la salida.
2. Marco teorico 17
Una forma mas interactiva de uso de la computadora se desarroll o comercialmente por mediados
de los a nos 1960. En un sistema de tiempo compartido, m ultiples terminales permitieron a mucha
gente compartir el uso de un procesador de computadora mainframe. Esto era com un en aplicaciones
empresariales y en ciencia e ingeniera. Un modelo diferente del uso de la computadora fue presagiado
en la manera en que fueron usadas las tempranas computadoras experimentales pre-comerciales,
donde un usuario tena uso exclusivo de un procesador [1].
A partir de ese momento las computadoras han ido evolucionando hasta convertirse en lo que
ahora son, y las empresas de la actualidad se valen de estos dispositivos tan poderosos para llevar a
cabo la mayora de sus tareas comunes. Ahora bien, desde el momento en que los usuarios comenzaron
a utilizar las computadoras en su vida diaria se tuvo la necesidad de desarrollar sistemas con los que
las empresas pudieran llevar a cabo sus tareas mas comunes, estos se han ido modernizando da tras
da y lo mas comunes han sido los servicios Web, los cuales permiten llevar un control detallado de
una empresa con solo tener acceso a internet, lo que benecia en gran medida a las organizaciones
porque solo necesitan tener acceso a internet y contar con un equipo de c omputo para poder trabajar,
de esta manera las empresas solo tienen que pagar por el servicio que se le brinda y tener acceso
total a todos los servicios disponibles por el sistema.
2.4.1 Que es el Sistema para Captura y Seguimiento de Riesgos
Organizacionales?
El Sistema para Captura y Seguimiento de Riesgos Organizacionales es una poderosa herramienta
de gesti on empresarial que apoya en la ejecuci on de los objetivos nancieros y que da cabida a
los objetivos organizacionales que verdaderamente generan valor en una empresa, esta herramienta
permite gestionar los aspectos clave del negocio incorporando una metodologa que permite mitigar
los Riesgos organizacionales mediante la monitorizaci on de objetivos estrategicos y de las actividades
realizadas en la empresa.
18 2.4. Antecedentes
Las principales caractersticas del Sistema para Captura y Seguimiento de Riesgos
Organizacionales son las siguientes:
Claricar y comunicar el rumbo de la organizaci on, as como los objetivos clave que debe lograr
para materializar la visi on organizacional.
Gestionar las estrategias competitivas, para la creacion de una posici on unica y valiosa de una
empresa.
Conseguir la alineaci on de esfuerzos de todas las areas hacia el logro de los objetivos estrategicos
de la organizaci on.
Garantizar el exito de la empresa a traves del acoplamiento entre las actividades estrategicas,
y vigilar el cumplimiento e integraci on entre ellas.
Mitigar el riesgo de paralisis en las estrategias por fallas organizacionales.
Agilizar la toma de decisiones enfocandose en la sustentabilidad del negocio.
Difundir y coordinar los esfuerzos clave para la creaci on de valor al cliente.
La aplicaci on se encuentra desarrollada en un sistema por capas, en el cual cada capa de desarrollo
ofrece una gran ventaja al programador para poder administrar el sistema en desarrollo de una manera
muy factible. Una de las capas mas importantes es la de persistencia de datos, en ella se llevan a cabo
todo lo referente a las conexiones con la base de datos con la que se comunica el sistema, mismo
que es creado utilizando un framework llamado Spring.Net que permite un facil manejo de datos, al
igual que una librera muy popular llamada NHibernate que permite el mapeo de objeto relacional
del modelo de datos a las entidades de negocio de la aplicaci on. Por otro lado es importante se nalar
que la aplicacion esta desarrollada en el entorno Web con el IDE de Visual Studio Ultimate 2010
bajo el lenguaje de programacion de C# y Silverlight para el entorno visual.
2. Marco teorico 19
2.5 Resumen
Actualmente existe una gran variedad de tecnologas, herramientas y arquitecturas de
programaci on web que dan lugar al desarrollo eciente de nuevas aplicaciones web. En este captulo se
describi o la arquitectura general del proyecto, asi como una breve rese na de lo que se pretende hacer y
se pofundizo en los temas sobre las herramientas a utilizar. De igual modo se mencionaron las diversas
tecnologas para creaci on de aplicaciones web utilizadas en el desarrollo del sistema anteriormente
mencionado, se mencionaron algunos ejemplos de sistemas que brindan servicios similiares y se
explicaron las ventajas y el porque desarrollar este sistema.
As tambien se describieron las caractersticas del sistema y las ventajas que ofrece al ser una
aplicacion de tipo web que pueda ser utilizada como un servicio, siguiendo la tendencia a la que
apuntan las tecnologas web de la actualidad.
3
Enfoque sobre la Administracion de Riesgos
Este captulo describe brevemente el funcionamiento del sistema de Riesgos desde las perspectiva
de las empresas, asi como las pautas pricipales que se deben de seguir para que se pueda llevar a
cabo una buena administracion de los mismos y para que el lector conozca las funcionalides internas
antes de demostrar el funcionamiento del sistema a nivel de programaci on.
3.1 Objetivos
Los objetivos son lo mas importante para levantar los requerimientos de un Riesgo, los puntos
que se tomaran en cuenta son los siguientes.
Identicar los riesgos que presenta el proyecto.
Asegurar que cada riesgo es evaluado para saber su probabilidad de ocurrencia e impacto.
Elaborar y establecer los planes de contingencia y fallo del proyecto.
Asegurar que las acciones establecidas en los planes de contingencia son ejecutadas cuando un
riesgo se presenta en el proyecto.
21
22 3.2. Actividades
Debe tomar en cuenta que cualquier riesgo identicado debera ser procesado por este
procedimiento, siempre y cuando as se especique en el Plan de Proyecto.
3.2 Actividades
La gura 3.1 nos muestra las actividades que se tomaran en cuenta para la administraci on de los
Riesgos descritos en este captulo, y a continuacion se describiran cada una de ellas.
Figura 3.1: Actividades para la administraci on de Riesgos.
3.3 Planicacion
Si el proyecto no se ha formalizado, las actividades de planicaci on, identicacion, evaluaci on
y en general la administracion de riesgos es realizada por la persona que elabora la propuesta de
la gerencia de Comercializacion, a partir de la formalizaci on esta responsabilidad pasara a cargo
del Responsable de Administracion de Proyectos Especcos (RAPE) designado. En las
actividades de este proceso, se hace referencia a este rol como el Responsable de Administrar
los Riesgos. En ambos casos, el Responsable de Gesti on de Procesos (RGP) y el Responsable de
Gesti on de Proyectos (RGPY) validaran que las actividades de administraci on de riesgo, se esten
realizando.
Las estrategias de riesgos de las oportunidades deben establecerse en el Plan de Ventas, as como
para los proyectos de mantenimiento se realizara una estrategia de riesgos que debera incluirse en el
Plan de Gesti on de Proyectos.
Para la administraci on de riesgos de los procesos se realizara una estrategia de riesgos incluida
en el Plan de Procesos.
El Responsable de Administrar los Riesgos, debe denir los siguientes elementos de la estrategia
para administrar los riesgos del proyecto. Este debera quedar documentado dentro de la seccion Plan
de Manejo de Riesgos, contenido en el Plan correspondiente. La estrategia de administracion de
riesgos debera ser revisada con el RGPY. En caso de los Procesos, con el Resposable de Gestion de
Negocios (RGN).
Esta estrategia debera contener:
C omo y con que herramientas se realizara la gesti on de riesgos.
Roles y responsabilidades: Quien se encargara de gestionar los riesgos. La estrategia de
administracion de riesgos debera ser revisada con el Cliente y los involucrados que esten
marcados como principales dentro de la Lista de Involucrados (stakeholders).
Los mecanismos para mantener informados a los diferentes grupos involucrados sobre los
principales riesgos del proyecto a lo largo del proyecto, as como el mecanismo de comunicaci on
de las acciones y responsabilidades genericas a tomar para cada plan de contingencia y fallo
de los riesgos (planes de administracion de riesgos).
Los indicadores del calendario, avance del proyecto, o desviaciones signicativas, que serviran
como disparadores para escalar los riesgos y solicitar la participaci on de la Coordinacion de
Proyectos e incluso la de la Gerencia General.
Denir la periodicidad, indicando cuando y con que frecuencia se realizara el proceso de gestion
de riesgos durante el ciclo de vida del proyecto, y establece las actividades de gesti on de riesgos
que se incluiran en el cronograma del proyecto.
24 3.4. Identicar Riesgos
3.4 Identicar Riesgos
Un riesgo es un evento o condicion incierto que, si se produce, tendra un efecto positivo o negativo
sobre al menos un objetivo del proyecto, como tiempo, coste, alcance o calidad.
Se recomienda que la actividad sea ejecutada a partir de la detecci on de la oportunidad de negocio
y durante las fases del ciclo de vida.
El Responsable de Administrar los Riesgos deben empezar el proceso de identicacion
revisando la documentaci on, y la informacion reciente e hist orica relacionada a la organizaci on,
y los supuestos que pueden afectar el proyecto o la oportunidad.
La identicaci on de riesgos consiste en determinar cuales son los riesgos mas probables que afectan
el proyecto y documentar sus caractersticas. Esta actividad debe realizarse por cada actividad o caso
de uso identicado. De igual manera pueden utilizar diferentes tecnicas para identicar los riesgos.
Las cinco tecnicas mas utilizadas son: la tormenta de ideas, el metodo Delphi, las entrevistas, el
analisis causa efecto, y el analisis FODA (Fortalezas, debilidades, oportunidades, y amenazas).
El Responsable de Administrar los Riesgos debe tambien identicar el tipo de riesgo, es decir, si
es una amenaza o es una oportunidad.
Los riesgos que son amenazas para el proyecto pueden ser aceptados si el riesgo esta en equilibrio
con el benecio que puede obtenerse al tomarlo.
Los riesgos que constituyen oportunidades, como la aceleraci on del trabajo que puede lograrse
asignando personal adicional, pueden ser monitorizados para beneciar los objetivos del proyecto.
Antes de ser analizados, los riesgos identicados deben ser registrados en el formato
correspondiente de Plan de Riesgos. Los riesgos deberan ser expuestos de forma clara de tal forma
que los miembros del equipo sean capaces de entender exactamente el riesgo cuando haya pasado
un tiempo. En la descripci on del riesgo se debera incluir el evento relacionado, el momento en que
ocurri o y el impacto del mismo.
Para redactar correctamente un Riesgo se recomienda hacer uso de las siguientes frases:
Debido a (CAUSA)
Puede Ocurrir (RIESGO)
Lo que conllevara a (EFECTOS)
Ejemplo:
Dedibo a Desconocimiento de la capacidad operativa puede ocurrir una Planeacion inadecuada del
ciclo de desarrollo lo que conllevara a retrasos o deciencia en la realizaci on de la aplicaci on. Por
otro lado, el Responsable de Administrar los Riesgos debe identicar y documentar los disparadores
de cada uno de ellos.
Los disparadores, a menudo llamados sntomas del riesgo o se nales de aviso, son indicadores de
que un riesgo ha ocurrido o esta a punto de ocurrir y por lo tanto es necesario buscar un remedio.
Los disparadores pueden ser eventos especcos como por ejemplo, no cumplir ciertos hitos puede ser
un disparador de un inminente retraso en el programa de trabajo. Estos disparadores tambien pueden
ser umbrales predenidos como por ejemplo, que una estimaci on en el desarrollo de un producto
exceda el 10 % de lo planicado en las primeras cuatro primeras semanas indica que se ha detectado
un riesgo.
El estado del riesgo nos permite comunicar el estado actual del riesgo. Los estados por los que
puede cursar un riesgo son:
Identicado: el riesgo ha sido identicado pero no ha sido analizado ni evaluado.
Evaluado: un riesgo identicado que actualmente no tiene un plan de contingencia o fallo.
26 3.4. Identicar Riesgos
Planicado: un riesgo identicado con un plan de contingencia o fallo.
En proceso: un riesgo donde la respuesta al riesgo esta siendo ejecutada.
Cerrado: un riesgo que ocurrio y que ha sido cerrado.
No ocurrido: un riesgo que fue identicado pero que no ocurrio. Este estado es utilizado para
diferenciar entre aquellos riesgos que fueron identicados, evaluados y gestionados hasta su
cierre y aquellos que fueron identicados pero que nunca ocurrieron.
Los riesgos relacionados con proyectos se deben de categorizar por fuentes de riesgo, utilizando
la estructura que se muestra en la gura 3.2.
Figura 3.2: Categorias para Riesgos relacionados con proyectos.
Los riesgos relacionados con procesos pueden utilizar la misma estructura o utilizar la siguiente
tabla clasicada a un alto nivel de las fuentes de riesgo.
CATEGORIA TIPO
PERSONAS
Usuarios nales
Patrocinadores
Participantes
Personal
Organizaci on
Conocimientos
Polticas
Moral
PROCESO
Misi on y metas
Toma de decisiones
Caractersticas del proyecto
Presupuesto, costo y programaci on
Requerimientos
Dise no
Creaci on
Pruebas
Implementaci on de metodos
TECNOLOG
IA
Seguridad
Entorno de desarrollo
Herramientas
Implementaci on
Soporte Tecnico
Entorno Operativo
Disponibilidad
ENTORNO
Legal
Normativo
Competencia
Econ omico
Tecnologa
Organizacional
Tabla 3.1: Clasicacion de alto nivel de las fuentes de un riesgo.
La informacion mnima requerida que debe ser registrada para cada riesgo durante esta etapa de
identicaci on es la descripci on del riesgo, categora, disparador y el estado del riesgo.
28 3.5. Evaluar los riesgos (Cualicacion y Cuanticacion)
3.5 Evaluar los riesgos (Cualicacion y Cuanticacion)
Una vez identicados los posibles riesgos en el proyecto, el Responsable de Evaluar los riesgos
debera valorar la probabilidad y el impacto de los riesgos identicados.
La evaluaci on de los riesgos identicados en la fase anterior se realiza para determinar la
probabilidad de que ocurran, el impacto del riesgo, el impacto acumulativo de m ultiples riesgos
y la prioridad de cada riesgo.
Las actividades relacionadas con la evaluacion de riesgos estan divididas en dos categoras:
Analisis cualitativo de riesgos: evaluaci on del impacto y la probabilidad de ocurrencia de
los riesgos sobre las salidas del proyecto utilizando metodos cualitativos.
Analisis cuantitativo de riesgos: evaluacion matematica de la probabilidad de ocurrencia de
cada riesgo y sus consecuencias en las salidas del proyecto.
3.5.1 Analisis cualitativo de riesgos
Las bases que se consideran para evaluar los riesgos son bajo, medio, alto y muy alto, los cuales
estan asociadas con la probabilidad de que ocurra un riesgo.
Se debe determinar el impacto y probabilidad de ocurrencia de riesgos de forma cualitativa
siguiendo las tabla 3.2 y 3.3 respectivamente.
Interpretacion Valor Descripcion
Muy Alto
10 Proyecto Fallido
9 Encima del 40 % del presupuesto o retraso de mas del 40 %
Alto
8 Encima del 30 % del presupuesto o retraso del 30 % al 40 %
7 Encima del 20 % del presupuesto o retraso del 20 % al 30 %
Medio - Alto
6 Encima del 10 % al 20 % del presupuesto
5 Presupuesto limitado
Medio
4 Alta reducci on de reserva de tiempo o costo.
3 Mediana reduccion de reserva de tiempo o costo.
Bajo
2 Peque na reduccion de reserva de tiempo o costo.
1 No tiene un impacto real.
Tabla 3.2: Escala de impacto para Amenazas.
Interpretacion Valor Descripcion
Muy Alto
10 Oportunidad Exitosa
9 Mas del 40 % de probabilidad de exito de la oportunidad
Alto
8 Probabilidad del 30 % al 40 % de exito de la oportunidad
Medio - Alto
5 Presupuesto limitado
Medio
4 Alto aumento de reserva de tiempo o costo.
3 Mediano aumento de reserva de tiempo o costo.
Bajo
2 Peque no aumento de reserva de tiempo o costo.
1 No es una oportunidad.
Tabla 3.3: Escala de impacto para Oportunidades.
Es conveniente que si un riesgo es alto y su severidad es alta y su severidad va de media a alta
debe ser monitoreado por el Coordinador de Proyectos. Si el riesgo es alto, y su severidad es alta,
este debe ser monitoreado tambien por la gerencia general.
Si el riesgo tiene una probabilidad alta y una severidad alta; se debe tomar como un hecho.
Si el riesgo tiene una probabilidad media y severidad alta al menos debe tener un plan de
contingencia y fallo.
El responsable de evaluar los riesgos debera incluir el nivel de evaluaci on de riesgo en el Plan de
Proyecto. En caso de tratarse de la evaluaci on de riesgo en una propuesta, se elaborara un reporte
de evaluacion del riesgo del proyecto incluyendo los comentarios generales. El responsable de evaluar
los riesgos debera entregar este reporte al Gerente de Proyectos (GPY), y en caso de que el proyecto
sea evaluado de riesgo alto tambien se le proporcionara una copia al Gerente general.
Una vez evaluados los riesgos el GPY no solo debera validar esta actividad sino que revisara los
planes de contingencia y fallo para los riesgos crticos de esta actividad. Al realizar esta actividad, los
riesgos se eval uan, se analizan y se priorizan con base en su impacto en el proyecto. La evaluaci on
debera ser ajustada a lo largo del ciclo de vida del proyecto. Al analizar cada uno de los riesgos se
debera establecer el impacto total en el proyecto.
3.5.2 Planeamiento de la Respuesta.
El Responsable de Administrar los Riesgos, debe documentar los riesgos identicados dentro del
Control de Riesgos del proyecto. Para ello debera documentar dentro de este:
El tipo y descripci on del riesgo.
La severidad y probabilidad de ocurrencia.
Las consecuencias o impactos del riesgo en el proyecto en caso de presentarse.
En base al impacto y consecuencias identicadas, para cada uno de los riesgos, as como en
la severidad y probabilidad de los riesgos de ocurrir, el Responsable de Administrar los Riesgos
determinara si es justicable elaborar un plan de mitigacion (contingencia y/o fallo) para el riesgo.
Existen distintas estrategias de respuesta a los riesgos. Es importante seleccionar la mas efectiva
dentro de cada proyecto. El responsable de administrar riesgos debe establecer la estrategia de
respuesta del riesgo (amenaza u oportunidad), de acuerdo a la probabilidad y al impacto.
3.5.3 Estrategias de Riesgos negativos o Amenazas.
Existen tres estrategias que normalmente se ocupan de las amenazas o los riesgos que pueden
tener impactos negativos sobre los objetivos del proyecto en caso de ocurrir. Estas estrategias son
evitar, transferir o mitigar y se pueden apreciar en la 3.3.
Figura 3.3: Estrategias de Riesgos negativos o amenazas.
3.5.4 Evitar el Riesgo
Con esta estrategia se intenta cambiar el plan de gesti on del proyecto para eliminar la amenaza,
aislar los objetivos del proyecto de los impactos del riesgo, relajar el objetivo que esta en peligro.
Ejemplo:
Ampliaci on del tiempo de la actividad, reduccion del alcance, aclaraci on de los requerimientos.
3.5.5 Transferir el Riesgo
Implica trasladar el impacto negativo de una amenaza, junto con la propiedad de la respuesta a
un tercero. Le da a la otra parte la responsabilidad de la gestion no lo elimina. Se usa frecuentemente
cuando existe exposici on al riesgo nanciero. Es necesario pagar una prima de riesgo a la parte que
toma el riesgo.
Ejemplo:
Uso de seguros
Garantas
Certicados de garanta
Contratos especcos
3.5.6 Mitigar el Riesgo
Implica reducir la probabilidad y/o el impacto de un evento de riesgo adverso a un umbral
aceptable. Reduccion de la probabilidad de ocurrencia, adoptar acciones tempranas es mejor que
reparar los da nos.
Ejemplo:
Adoptar procesos menos complejos
Realizar mas pruebas
Seleccionar un proveedor estable
Desarrollo de prototipos
Reducci on del impacto del riesgo
Dise no de sistemas redundantes, para fallas del sistema original
3.6 Estrategias de Riesgos positivos u oportunidades
Se sugieren tres respuestas para tratar los riesgos que tienen posibles impactos positivos sobre
los objetivos del proyecto. Estas estrategias son explotar, compartir o mejorar.
3.6.1 Explotar el Riesgo
Esta estrategia busca eliminar la incertidumbre asociada con un riesgo del lado positivo
en particular haciendo que la oportunidad denitivamente se concrete. Explotar las respuestas
directamente incluye asignar recursos mas talentosos al proyecto para reducir el tiempo hasta la
conclusi on, o para ofrecer una mejor calidad que la planicada originalmente.
3.6.2 Compartir el Riesgo
Compartir un riesgo positivo implica asignar la propiedad a un tercero que esta mejor capacitado
para capturar la oportunidad para benecio del proyecto. Entre los ejemplos de acciones para
compartir se incluyen: formar asociaciones de riesgo conjunto, equipos, empresas con nalidades
especiales o uniones temporales de empresas, que se pueden establecer con la nalidad expresa de
gestionar oportunidades.
34 3.6. Estrategias de Riesgos positivos u oportunidades
3.6.3 Mejorar el Riesgo
Esta estrategia modica el tama no de una oportunidad, aumentando la probabilidad y/o los
impactos positivos, e identicando y maximizando las fuerzas impulsoras clave de estos riesgos de
impacto positivo. Buscar facilitar o fortalecer la causa de la oportunidad, y dirigirse de forma proactiva
a las condiciones que la disparan y reforzarlas, puede aumentar la probabilidad.
3.6.4 Aceptar el Riesgo
Esta estrategia se adopta debido a que rara vez es posible eliminar todo el riesgo de un proyecto.
Esta estrategia indica que el equipo del proyecto ha decidido no cambiar el plan de gesti on del
proyecto para hacer frente a un riesgo, o no ha podido identicar ninguna otra estrategia de respuesta
adecuada, y puede ser adoptada tanto para las amenazas como para las oportunidades. Esta estrategia
puede ser pasiva o activa. La aceptaci on pasiva no requiere acci on alguna, dejando en manos del
equipo del proyecto la gesti on de las amenazas o las oportunidades a medida que se producen. La
estrategia de aceptaci on activa mas com un es establecer una reserva para contingencias, que incluya
la cantidad de tiempo, dinero o recursos necesarios para manejar las amenazas o las oportunidades
conocidas, o incluso tambien las posibles y desconocidas.
El Responsable de Administrar Riesgos establecera un plan de contingencia en los siguientes
casos:
Cuando dentro de las consecuencias exista una perdida de mas del 10 % del costo por fase del
proyecto.
Cuando exista un retraso de mas del 10 % en el calendario del proyecto.
Cuando se dependa de las pruebas del proyecto de un cierto recurso o servicio proporcionado
por un externo.
Cuando sea necesaria la compra o establecimiento de ambientes de pruebas, producci on o
equipo especializado para el buen funcionamiento del proyecto.
El Responsable de Administrar los Riesgos, debera establecer para los riesgos seleccionados, un
plan de contingencia para aminorar la probabilidad de ocurrencia de los riesgos, as como un plan de
fallo para hacer frente a riesgos que puedan ocurrir durante el proyecto y que so fueron controlados
por el plan de contigencia. Ambos planes deberan contener no solo las acciones sino tambien los
responsables y tiempos compromiso para ejecutar dichas acciones.
El Responsable de Administrar los Riesgos, durante las revisiones con su Equipo de Trabajo,
debera identicar y evaluar las areas de alto riesgo, y se deberan actualizar, en caso de ser necesario,
los planes de contencion y/o contingencia.
En los proyectos de mesa de ayuda de mantenimiento, se deberan establecer/actualizar los planes
de contingencia por grupo de sistemas. El RGPY debe revisar los planes de contingencia y contencion
tomando en cuenta el costo de cada uno de ellos (ya sea en recursos o bienes necesarios para poder
realizarlos).
Las alternativas de solucion frente al riesgo son:
Evitarlo
Es importante en el momento de hacer proyectos y programas de una empresa. Ej.
Construcci on de una fabrica en zona costera, buscar un lugar menos expuesto a huracanes,
vientos fuertes, penetraciones del mar, etc.
Eliminar sus causas y reducir los efectos
Puede ser factible o no, ya que es poco probable que se puedan eliminar totalmente
los riesgos, sino algunas de sus causas. Si podemos tener en cuenta que los efectos de la
ocurrencia de un riesgo, si puede ser reducida en mayor o menor grado, todo lo anterior
36 3.7. Monitoreo y Control
estara en dependencia directa de la calidad del riesgo de que se trate y de c omo afecte este
a los procesos. Ej. : Protecciones contra incendios, rejas para la seguridad, entubar cables
electricos, etc.
Retenerlo (asumirlo)
Debe realizarse de manera consciente y activa, se reere a perdidas frecuentes y de
bajo impacto nanciero que la empresa como tal puede asumir. Ejemplo: Custodios, serenos,
medidas de seguridad, etc.
Transferirlo
Los efectos adversos de los riesgos se trasladan a otra entidad que los asume.
3.7 Monitoreo y Control
El Responsable de Administrar los Riesgos debera ejecutar los planes de contingencia y en caso de
que ocurra un riesgo el plan de fallo que se haya establecido, para mitigar o eliminar las consecuencias
del riesgo. Asimismo debera adecuar los planes de contenci on y de contingencia para dar respuesta
a los riesgos que se presenten, en caso de que estos no hayan sido anticipados, o el efecto sea mayor
al esperado.
El Responsable de Administrar los Riesgos debe documentar en el Control de Riesgos, las
adecuaciones y cambios realizados a los planes.
El Lder de Proyecto debera ejecutar los planes de contencion, y en caso de que ocurra un
riesgo, de contingencia que se haya establecido. De igual manera, se deberan adecuar los planes de
contenci on y de contingencia para dar respuesta a los riesgos que se presenten, en caso de que estos
no hayan sido anticipados, o el efecto sea mayor al esperado. Documentar en el Control de riesgos
las adecuaciones y cambios realizados a los planes y actualizar el tablero de control del proyecto.
El Lder de Proyecto debe informar al Responsable de Gesti on de Proyectos de las acciones
realizadas durante la ejecucion del plan de contencion y de contingencia.
En los proyectos de mesa de ayuda de mantenimiento, se debera dar seguimiento a los planes de
contingencia por grupo de sistemas.
El Responsable de Evaluar los Riesgos debera tener pleno conocimiento de cada uno de los riesgos
que evaluara en la respectiva matriz de riesgos, en el momento que el responsable de evaluar riesgos
detecte que los planes de contingencia no estan resultando del todo satisfactorio estos deberan ser
trasladados al procedimiento de controlar asuntos en donde el responsable dara seguimiento a dicho
asunto, y donde formulara los compromisos para mitigar el impacto que pudiera tener en el proyecto.
Para nalizar el RGPY debe vericar peri odicamente la correcta implantacion de las actividades
de este procedimiento en los proyectos a su cargo y debe mantener informado en caso de riesgos
crticos del proyecto al Gerente General. Asimismo analiza la informacion que le brinde el Responsable
de Administracion de Proyectos Especcos (RAPE), por medio del reporte de avance y tablero de
control.
El Responsable de Gesti on de Proyectos (RGP) debe realiza revisiones de adherencia de las
actividades y productos de trabajo de este procedimiento y reportar los resultados al RAPE y RGPY.
En caso de que exista un evento de relevancia se lo reporta al Gerente General.
El RGP tambien verica periodicamente las actividades y productos del proceso para evaluar:
Que se lleve una adecuada identicacion y evaluacion de los riesgos.
Que se actualicen y monitoreen adecuadamente los riesgos del proyecto.
Que se realicen las revisiones al proyecto establecidas en este proceso.
38 3.8. Resumen
3.8 Resumen
En este captulo se describio un enfoque mas amplio y detallado sobre las caractersticas y la
funcionalidad en general del sistema, se mostr o una visi on general acerca de la construcci on del
software y cada una de las partes que lo componen, asi como la forma en que se estructura cada
parte del mismo y los roles que juegan los administradores del sistema a la hora de tomar desiciones
sobre los Riesgos.
Vimos tambien la clasicaci on de los Riesgos, y el tratamiento que se sugiere de acuerdo a cada
situaci on planteada, asi como la forma de afrontar cualquier escenario dentro del desarrollo de un
proyecto especico, haciendo uso de este Sistema.
4
Desarrollo del Sistema
En este captulo se dara a conocer la metodologa utilizada en la realizacion del proyecto, as como
los pasos detallados que se llevaron a cabo para la culminacion del mismo, de igual manera se veran
asuntos relacionados con la empresa tales como la disposici on de los diferentes recursos, tiempo,
entre otros.
4.1 Metodologa de trabajo para el desarrollo del sistema
Para el desarrollo del proyecto, la metodologa a emplear debe permitir y/o ser compatible con la
implementaci on de procesos de la norma Moprosoft, debido a las polticas de calidad de la empresa.
As como la estructuracion de proyectos con dependencia de Internet y el manejo de capas en
el mismo. Por ello se ha elegido el modelo basado en cascada provisto por S. Pressman, Roger.
Ingeniera del Software: Un enfoque practico, 3ra Edicion. Donde se elaboraran desde la etapa de
Dise no del programa hasta la etapa de Pruebas. Esto por el inconveniente del tiempo en el que el
proyecto debe realizarse y la cantidad de requisitos necesarios para su terminacion.
39
40 4.2. Estudio de factibilidad
El modelo en cascada sugiere un enfoque sistematico, secuencial hacia el desarrollo del software,
que se inicia con la especicaci on de requerimientos del cliente y que contin ua con la planeaci on, el
modelado, la construccion y el despliegue para culminar en el soporte del software terminado. Sirve
pues, como un modelo de proceso util en situaciones donde los requerimientos estan jos y donde el
trabajo se realiza, hasta su conclusion, de una manera lineal; consta de las siguientes etapas:
Comunicacion: Inicio del proyecto y recopilaci on de requisitos.
Planeacion: Estimacion, itinerario y seguimiento.
Modelado: Analisis y dise no.
Construccion: C odigo y prueba.
Despliegue: Entrega, soporte y retroalimentaci on.
Como el modelo sugiere, antes de poder avanzar a la siguiente etapa es necesario haber nalizado
completamente la etapa anterior. Asociada con cada etapa del proceso, existen hilos y documentos,
de la forma que se puede utilizar el modelo para comprobar los avances del proyecto y para estimar
cuanto falta para su nalizaci on.
4.2 Estudio de factibilidad
El estudio de factibilidad se realiza para tener una perspectiva concreta de los recursos que se
necesitan, as mismo saber si se cuenta con ellos y si sera posible llevar a cabo el proyecto de acuerdo
a la disponibilidad de los recursos con los que cuenta la empresa.
4.2.1 Tecnico
4.2.1.1. Hardware
Los recursos materiales que se utilizaron para llevar a cabo la realizaci on de este proyecto fueron
los siguientes:
Laptop
Mouse
Servidor de produccion
Impresora multifuncional
4.2.1.2. Software
El software que se utilz o para realizar el proyecto se lista a continuacion:
Windows 8
Microsoft Oce 2013
Microsoft Visio
Enterprise Architect
Visual Studio 2012
MySql Server
Librerias de Controles Silverlight
4.2.2 Economico
Para poder llevar a cabo este proyecto la empresa invirti o en una computadora portatil por
cada nuevo integrante al proyecto en cuesti on y de acuerdo a las caractersticas de los equipos estos
costaron $8,000.00 cada uno, en total se compraron 4 computadoras portatiles. En cuanto al software
de desarrollo, ya se contaba con las licencias, y al ser los equipos totalmente nuevos, tampoco se
gast o en comprar licencias de sistemas operativos.
42 4.3. Descripcion del desarrollo de la aplicacion
De igual manera la empresa proporciono un antivirus Kaspersky que ellos ya haban adquirido
desde antes y del cual ya no se tuvo que comprar una licencia. Por otro lado para la realizaci on de
pruebas y el correcto funcionamiento de la aplicacion, se nos proporcion o un servidor de producci on,
mismo que es utilizado por la organizacion en la actualidad para alojar la mayora de sus proyectos
de tipo Web, esto sin costo adicional al ser este propiedad de Integra IT Soluciones.
4.3 Descripcion del desarrollo de la aplicacion
Para el desarrollo del Sistema para Captura y Seguimiento de Riesgos Organizacionales se utiliza
el IDE Visual Studio 2010 en conjunto con la tecnologa Silverlight 4, como lenguaje de programaci on
y dise no XAML y para el acceso a los objetos el lenguaje de programacion C#.
El sistema utiliza la tecnologa de Microsoft .NET Framework para desarrollar e implementar
la soluci on. NET Framework es una nueva plataforma informatica que simplica el desarrollo de
aplicaciones en un entorno altamente distribuido como es Internet.
4.3.1 Preparacion previa sobre las herramientas a utilizar
Antes de iniciar con el desarrollo del proyecto, se tuvo la necesidad de tomar un curso sobre con
las herramientas de desarrollo que se iba a utilizar, esto, debido a que la mayora de los desarrolladores
implicados aun no tenan conocimiento ni experiencia el de desarrollo de aplicaciones de este tipo
con Silverlight y algunos a un no haban utilizado el IDE de Visual Studio.
En este curso se vieron temas sobre la utilizacion de las herramientas de Silverlight y su integraci on
con Visual Studio, as tambien se realizaron ejemplos de mapeo de clases en una base de datos y
desarrollo de clases e interfaces de programaci on. Se realizaron ejercicios practicos utilizando controles
de Silverlight para el desarrollo visual, y programaci on en C# para el funcionamiento de la interfaz,
se crearon ejemplos de validaciones y reglas de negocio, estructura de los proyectos desarrollados
en .NET, estructuras de sistemas empresariales, y se analiz o el sistema que se haba creado con
anterioridad, entre otros.
En el curso de Silverlight tambien se estudiaron las libreras que se iban a estar utilizando, por lo
general, libreras del sistema con extension .dll, tales como la de NHibernate.dll que es una librera
indispensable para llevar a cabo el mapeo de objetos y de esta manera crear nuestro esquema de
base de datos de una manera muy sencilla, otra herramienta que tambien se incluyo en el curso
fue el framework de Spring.Net que de igual forma hace que la integracion de una interfaz visual se
conecte con una base de datos de una forma muy intuitiva y facil.
4.3.2 Denir la funcionalidad de los nuevos modulos de la aplicacion.
Para denir la funcionalidades de los nuevos m odulos se llevaron a cabo varias reuniones de
trabajo con el gerente de le empresa, los analistas y los desarrolladores, de antemano se hizo un
previo estudio y se tomaron en cuenta la recaudaci on de los datos proporcionados por el cliente, en
esta etapa tambien se analizaron los requerimientos que deba cumplir el sistema y el modelo de
programaci on a utilizar as como la elecci on de las herramientas necesarias en hardware y software
para su realizaci on.
4.3.3 Seleccionar el software de desarrollo y el lenguaje de
programacion.
En esta seccion se eligi o el software que se utilizara en el desarrollo del sistema, mismo que
fue discutido en el punto anterior al llevar a cabo las reuniones con los analistas, el gerente y los
desarrolladores.
El IDE por excelencia elegido fue el Visual Studio Ultimate 2010, ya que con este, es muy
facil la integraci on de Silverlight y otras herramientas de terceros para alcanzar un desarrollo
robusto y una interfaz excelente. Como se haba mencionado en captulos anteriores, el lenguaje
de programaci on a utilizar fue C#, un lenguaje de programacion orientado a objetos con el cual se
pueden construir aplicaciones de gran alcance, de igual manera, para el desarrollo de la interfaz de
usuario, decidio utilizarse Silverlight ya que cuando el sistema estuviera listo, el usuario nal solo
necesitara del plug-in de Silverlight para empezar a utilizar la nueva herramienta.
4.3.4 Analizar los ECUS (Especicacion de casos de uso) del sistema de
Riesgos.
Una vez que se haba seleccionado el IDE de desarrollo y las herramientas a utilizar y habiendose
analizado y discutido la funcionalidad de los nuevos m odulos, se procedi o a revisar detalladamente
las especicaciones de casos de uso proporcionadas por los analistas de sistemas.
En esta etapa se encontraron varias incoherencias en cuanto a los requerimientos que los
analistas haban plasmado no solo en la funcionalidad del sistema sino tambien en cuanto a dise no y
estructuraci on, sin embargo con el analisis exhaustivo por parte de los desarrolladores se hicieron los
cambios pertinentes para que se pudiera empezar a trabajar sobre estos casos de usos y a desarrollar
el sistema lo mas pronto posible. Despues de que cada integrante del proyecto termino de analizar
sus casos de uso correspondientes y habiendo quedado en completo acuerdo con los analistas en
cuanto a los cambios realizados se procedi o a trabajar sobre el modelo que fue planteado por todos
los conformantes del proyecto.
4.3.5 Crear el proyecto principal a nivel de programacion sobre el IDE
elegido.
La tarea de importaci on del sistema anterior no fue muy laboriosa, en realidad este proyecto
se encontraba en perfecto funcionamiento, solo se hicieron algunas modicaciones pertinentes en
cuanto a sus estructura por capas, ya que al ser este ahora un sistema mas grande se tena que
contar con una mejor estructuraci on para que no tuvieramos problemas al momento de empezar a
trabajar e integrar los nuevos m odulos. En la gura 4.1 se muestra la estructura general por capas
del sistema desarrollado, a nivel de programaci on.
Figura 4.1: Estructura general del proyecto por capas.
4.3.6 Creacion de la Base de Datos en MySql.
La creacion de la base de datos implica trabajar directamente con las clases que haran la funcion
de identicar una tabla de la base de datos, como era de esperarse ya se contaba con un numero
especico de clases, archivos de mapeo, e incluso ya haba una base de datos que se estaba utilizando
hasta el momento, sin embargo, en esta etapa se modic o ese esquema para agregar las nuevas tablas
para los nuevos m odulos que seran implementados.
Para generar el esquema de Base de Datos, se creo un metodo especial que se muestra en el
algoritmo 1, al ejecutar este metodo, automaticamente la herramienta de NHibernate crea el esquema
en el servidor de MySql y ya podemos continuar trabajando con la creaci on de las demas tablas,
mediante los archivos de mapeo respectivos, mismos que se explicaran a continuacion.
Algorithm 1 Fragmento de codigo para generar el esquema base de datos.
01 namespace IntegraIt.StraTarget.SchemaExport
02 {
03 [TestFixture]
04 public class SchemaExport
05 {
06 [Test]
07 public void GenerarEsquema()
08 {
09 Configuration config = new Configuration();
10 // para la generacion del esquema de bd, empleadmos el hibernate.cfg.xml
11 config.Configure();
12 new SchemaExport(config).Execute(true, false, false);
13 }
14 }
15 }
En la misma capa de dominio es donde se llevaron a cabo estas operaciones de modicacion de
la base de datos, en el fragmento de codigo que se muestra en el algoritmo 2, podemos observar de
que manera se estructura el mapeo de una clase que va a representar una tabla en la base de datos.
Algorithm 2 Fragmento de codigo que representa una tabla en una base de datos.
01 <?xml version="1.0" encoding="utf-8" ?>
02 <hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
03 assembly="IntegraIt.StraTarget.BackEnd.Domain"
04 namespace="IntegraIt.StraTarget.BackEnd.Domain.AdmonRiesgo">
05 <class name="Riesgo" table="RIESGO">
06 <id name ="Id" type="Int64">
07 <column name="ID_RIESGO" not-null="true"/>
08 <generator class="native"/>
09 </id>
10 <many-to-one name="ObjetivoPertenece"
11 class="IntegraIt.StraTarget.BackEnd.Domain.Objetivo" fetch="join">
12 <column name="ID_OBJETIVO"/>
13 </many-to-one>
14 <many-to-one name="ActividadProcesoPertenece"
15 class="IntegraIt.StraTarget.BackEnd.Domain.Bpm.ActividadProceso" fetch="join">
16 <column name="ID_ACTIVIDAD_PROCESO"/>
17 </many-to-one>
18 <many-to-one name="IniciativaPertenece"
19 class="IntegraIt.StraTarget.BackEnd.Domain.Initiative.Iniciativa" fetch="join">
20 <column name="ID_INICIATIVA"/>
21 </many-to-one>
22 </class>
23 </hibernate-mapping>
En el archivo de mapeo anterior podemos observar varios puntos importantes, en el encabezado
encontramos el ensamblado principal y el espacio de nombres que mas bien representan la ubicacion
exacta en el que se encuentra la clase de C# que representa a esta tabla, mas abajo tenemos el
nombre de la clase y el nombre de la tabla. Esto quiere decir que debemos de tener una clase que se
llame en este caso Riesgo y que al generar el esquema de base de datos, en la base de datos se
va a crear una tabla con el nombre de RIESGO, con may usculas y con todos los atributos que se
le esten asignado en este archivo de mapeo, tales como tipos de datos, relaciones entre las tablas,
entre otros.
De esta manera se crean todos los archivos de mapeo y las clases para que despues al compilarse
y usando un archivo de conguracion que se vera mas adelante, construiran la base de datos que
sera la responsable de almacenar toda la informacion del sistema.
4.3.7 Desarrollar los servicios Web.
El de desarrollo de los servicios web que seran expuestos para uso del sistema implica que se
debieron de crear el mapeo de objetos relacional, las clases necesarias, y los metodos que realizaran
las transacciones de la base de datos del sistema, incluyendo operaciones basicas como actualizar,
guardar, eliminar, listar elementos, y operaciones mas complejas como, calcular el nivel de exposici on
individual de un Riesgo, medir la probabilidad de que cierta accion o proceso pueda o no llevarse a
cabo, todas estas contempladas dentro del desarrollo del sistema.
Con la nalidad de que los metodos funcionaran perfectamente y de que no hubiera errores en
su implementaci on se cre o una peque na soluci on de pruebas, para hacer un test de cada uno de los
metodos que los servicios web utilizaran.
Una vez terminado esto, se procedi o a la programacion de los servicios web de cada uno de los
m odulos, con la implementacion de todos los metodos necesarios. Estos servicios web ahora estaran
listos para ser alojados en un servidor web y ser utilizados por nuestra aplicaci on de forma local o en
un sistema ejecutandose desde el servidor de produccion. En la gura 4.2, se muestra la estructura
en la que se encuentran los servicios web, para esto fue necesaria una nueva capa en el modelo
de programaci on, llamada capa de servicio o tambien conocida por algunos autores como capa de
negocio.
Figura 4.2: Servicios web expuestos para el uso del sistema.
4.3.8 Crear la interfaz que sera mostrada al usuario nal.
En este apartado se describe la realizacion de la interfaz de usuario desarrollada con Silverlight,
la cual fue pensada de acuerdo a las especicaciones del usuario. Para la creaci on de la interfaz
se comenzo con crear un nuevo elemento de tipo Silverlight Aplication en el cual se comenzara a
desarrollar el modelo de interfaz especicado en los analisis llevados a cabo previamente.
Cabe mencionar que cada elemento que ese creado como interfaz, tiene un archivo de c odigo de
C# que es mediante el cual se le da la funcionalidad a la vista que se este desarrollando. Tambien
es importante se nalar que el lenguaje que utiliza Silverlight para el desarrollo es el lenguaje XAML,
una variante de XML que ya se haba mencionado en captulos anteriores.
Cada vista del sistema fue dise nado siguiendo la estructura mostrada hasta el momento y la que
se mostrara a continuaci on mediante el asistente de Visual Studio para la creacion de una aplicaci on
de tipo Silverlight.
A continuacion en la gura 4.3 podemos ver el cuadro de herramientas para la creacion de un
nuevo elemento de tipo Silverlight Aplication.
Figura 4.3: Creaci on de un nuevo elemento para la interfaz de la aplicaci on.
4.3.9 Consumir los servicios Web del sistema
Consumir los servicios web signica darle funcionalidad a la interfaz que se esta creando, para
esto se tiene que hacer uso de los servicios que fueron expuestos en los puntos anteriores.
Antes de comenzar a darle funcionalidad a la aplicaci on, estos servicios deben de congurarse
como un sitio Web en el servidor local con el IIS (Internet Imformation Services), en la gura 4.4
podemos ver las conguraciones para un sitio web local, en el que montamos los servicios para lograr
el correcto funcionamiento del sistema.
Figura 4.4: Conguraci on basica del IIS que contiene los servicios web en ejecucion.
Es importante se nalar que la conguraci on que se hace en el IIS del servidor local es similar a
la que se hace en el servidor de produccion cuando se hace un despliegue del sistema, la diferencias
radican en que en vez de usar localhost como pagina de inicio al sistema, se cambia por la pagina
de Integra IT Soluciones www.integraitsoluciones.com, de igual forma, en lugar de usar el puerto
local que es el 84, se usa el puerto 443 u otro diferente denido por la empresa, y en cuanto al tipo
de conexi on, en el servidor de producci on se conguran ciertos certicados de seguridad y se usa el
protocolo https de conexi on segura.
4.3.10 Detallar la presentacion de la aplicacion.
En esta etapa se perfecciono la aplicaci on agregandole todos los detalles necesarios para que
fuera un sistema amigable y presentable ante los usuarios nales.
En la parte del tablero de control en lo referente a la consulta del plan de riesgos y seguimiento de
los mismos, se agregaron plantillas personalizadas que hacen que las tablas que administran el registro
y tratamientos de riesgos de una organizacion sean agradables desde la perspectiva del usuario nal.
Se agregaron nuevos estilos y se reordenaron las partes que conformaban el modulo de tal forma que
estuvieran organizados de una forma facil de entender y sobretodo facil de utilizar, cumpliendo de
esta manera con todos los requisitos planteados al principio de la planeaci on del sistema.
Es importante se nalar que en el transcurso del desarrollo de los m odulos del sistema, se le iban
mostrando avances al usuario nal y si haba algo que deseara modicar, se cambiaba, de esta manera
se fue detallando la aplicacion hasta quedar totalmente terminada y estando en total acuerdo con el
cliente sobre los resultados que se iban obteniendo.
4.3.11 Realizar pruebas y depurar el sistema para probar su correcto
funcionamiento.
La realizaci on de pruebas fue una etapa de suma importancia, para esto, tanto los analistas como
un Tester se dieron a la tarea de empezar a utilizar el sistema y detectar en que parte podra fallar,
o en donde, el usuario nal podra hacer que el sistema no funcionara.
De acuerdo a las pruebas, fuimos creando reglas de validaci on y se analiz o una y otra vez cada
m odulo del sistema hasta que quedara funcionando como se esperaba. En la gura 4.5 se puede
observar un ejemplo de validacion, de acuerdo las reglas de negocio que se plantearon desde el
principio por los analistas y los responsables del proyecto.
Figura 4.5: Ejemplo de validaci on sobre campos vacos.
4.3.12 Despliegue del sistema en el servidor de produccion.
Como se mencion o en puntos anteriores hacer un despliegue del sistema es sumamente sencillo,
el servidor de producci on cuenta con el sistema de base de datos de MySql y el Internet Imformation
Services (IIS) del cual ya se haba tratado anteriormente. Para acceder al servidor de producci on
se hace uso del escritorio remoto en el cual nos autenticamos y ya podemos hacer un despliegue
completo, en la gura 4.6 se muestra la ventana de acceso al servido remoto, solo necesitamos la
direcci on ip del servidor, el nombre de usuario y la contrase na del mismo para subir el sistema a
internet.
Al momento de hacer el despliegue de la aplicaci on, como el sistema ya se encontraba en uso, se
tuvo que detener por algunas horas el servicio, en esta lapso de tiempo se a nadieron al sistema en
producci on las nuevas tablas de las bases de datos vacas, y se le agregaron los campos necesarios a
las tablas ya existentes, todo sin alterar la informaci on que ya se encontraba en el sistema, un vez
concluida esta actividad el sistema vuelve a la normalidad pero ahora con un nuevo dise no y con las
nuevas caractersticas que fueron desarrolladas.
Figura 4.6: Acceso al servidor de producci on a traves del escritorio remoto.
4.3.13 Llevar a cabo la documentacion del sistema.
En lo referente a la documentaci on del sistema, se llev o a cabo la realizaci on de diagramas de
secuencia, modelo entidad relacion de la base de datos completa, diagramas de clases, reportes de
analisis y pruebas, reportes unitarios, manual de uso del sistema, entre otros. Por lo cual cada persona
responsable de un m odulo especico tuvo que responsabilizarse por la entrega en tiempo y forma de
toda la documentacion necesaria.
Una vez terminada la documentacion y el despliegue del sistema, el proyecto a practicamente ha
nalizado, solo falta la etapa de evaluaci on, esta se vera en el captulo siguiente.
5
Resultados y evaluacion de resultados
En este cuarto captulo se muestran los resultados obtenidos en cada una de las etapas de
desarrollo que integran el modulo de consulta de riesgos y el resultado nal ya implementado en el
servidor de produccion.
5.1 Etapas y evolucion de la aplicacion
A continuacion se muestra cada una de las etapas en el orden en que se fueron desarrollando
para la construcci on del m odulo de consulta de riesgos.
5.1.1 Consulta de riesgos.
En el m odulo de consulta de riesgos, el Consultor o Consultor BPM tiene como prop osito consultar
el estado de los riesgos de objetivos, iniciativas y procesos, y registrar su probabilidad e impacto en
las fechas determinadas por la periodicidad del seguimiento o en las fechas en las que se dispare el
riesgo.
55
56 5.1. Etapas y evolucion de la aplicacion
Dentro de una unidad organizacional, un Consultor representa a la comunidad de usuarios que
tienen privilegios de consulta de Mapas Estrategicos, los cuales no pueden registrar, modicar o
eliminar informaci on de dichos mapas. Por su parte el consultor de BPM representa a los usuarios
que tienen los privilegios unicamente de consulta de procesos, los cuales de igual manera no pueden
registrar, copiar diagramas, modicar o eliminar informacion relacionada con procesos. Dicho esto,
en la gurav 5.1, se muestra una tabla la cual sera rellenada con los datos de los registros de riesgos
que se encuentren en la base de datos.
Figura 5.1: Lista de riesgos registrados.
La tabla anterior es mostrada como prototipo antes de ser implementada, hasta este momento
a un no se le ha terminado de dar funcionalidad a la misma.
5.1.2 Consulta de los seguimientos de un riesgo.
Despues que se lleva a cabo la consulta de la lista de riesgos, cuando el usuario selecciona un
elemento, se muestra en otra tabla los seguimientos que se le dan al riesgo seleccionado. Al momento
de dar de alta un riesgo, se especica la periodicidad en la que se va a dar tratamiento al mismo,
en esta etapa se deben evaluar varias condiciones, primero al registrar un nuevo riesgo se establecen
condiciones mediante el uso de disparadores, los cuales tienen la funci on de que cuando el riesgo
sobrepase el nivel de exposicion individual que se especique, el sistema debe cambiar el estado
del riesgo a En proceso, de igual manera debe de enviar un correo al responsable del riesgo para
noticar que se ha superado el lmite y la condici on del disparador.
A continuacion en la gura 5.2, se muestra la tabla que contiene los datos del riesgo que fue
seleccionado en la consulta anterior.
Figura 5.2: Actividades de tratamiento del riesgo seleccionado.
Con el n de representar de una manera mas clara este proceso de consulta de riesgos se
presentaran dos imagenes, la primera, es la gura 5.3, y muestra la lista de riesgos, la gura 5.4,
muestra el tratamiento que se le esta dando en las fechas correspondientes a ese riesgo. Ambas
imagenes son la implementaci on de los prototipos mostrados anteriormente y que despues de las
pruebas se ha llegado a la conclusion de ya pueden estar ejecutandose en el servidor para su
implementaci on en la vida real hacia las empresas que utilizan este sistema.
De esta manera se le va dando seguimiento a los riesgos que se van registrando en el sistema
de acuerdo al elemento seleccionado y de acuerdo a la periodicidad con la que haya sido registrado
dicho riesgo.
Figura 5.3: Lista de riesgos registrados.
Figura 5.4: Lista de seguimientos del riesgo seleccionado.
Tambien es importante mencionar que si el usuario que accedi o al sistema no es el responsable
de los riesgos registrados, solo podra consultar los datos y no podra hacer modicaciones de ning un
tipo, la unica persona que puede modicar esa informaci on es el responsable del seguimiento de los
riesgos.
5.1.3 Actualizacion de los datos de seguimiento de un riesgo.
Siguiendo con el orden en el desarrollo y tratamiento de los riesgos organizacionales que administra
el Sistema para Captura y Seguimiento de Riesgos Organizacionales, en esta seccion se muestra
el espacio de trabajo en el cual se puede modicar el seguimiento de un riesgo de acuerdo al
cumplimiento de la solucion planteada para el mismo. Ver gura 5.5.
Figura 5.5: Actualizar el seguimiento de un riesgo.
Habiendo seleccionado un riesgo, y posteriormente un seguimiento, y solo si el responsable de la
unidad organizacional es el responsable del seguimiento del riesgo, esta area aparece habilitada para
dar seguimiento al elemento seleccionado. Para ejemplicar de una manera mas clara, si seleccionamos
el primer elemento de la gura 5.4 la siguiente tabla se llenara con los siguientes datos. Ver gura
5.6.
Figura 5.6: Datos del seguimiento del riesgo seleccionado.
En esta seccion podemos cambiar los datos del seguimiento de acuerdo al cumplimento de los
objetivos o metas establecidas, de esta manera se tiene un control sobre los posibles riesgos de una
organizaci on.
De igual manera, como se puede apreciar en la gura anterior al momento de seleccionar los
valores de impacto y probabilidad el sistema muestra la descripci on del valor indicado, los cuales
deben ser entre 1 a 10.
1-2 = Bajo
3-4 = Medio
5-6 = Medio Alto
7-8 = Alto
9-10 = Muy Alto
A continuaci on, al momento de que el usuario hace los cambios pertinentes en el avance del
seguimiento del riesgo y presiona el bot on guardar, el sistema muestra la conrmacion de guardado,
tal y como se muestra en la gura 5.7.
Figura 5.7: Mensaje de conrmaci on de actualizaci on del seguimiento de un riesgo.
Cada que el usuario hace un cambio en el registro de avance del seguimiento de un riesgo,
o cuando se agrega un nuevo riesgo en la primera tabla, se actualizan los datos de la exposicion
individual del riesgo y la graca de trazabilidad del mismo, estos se detallan a continuacion.
5.1.4 Nivel de exposicion individual del riesgo.
El nivel de exposicion individual del riesgo se calcula en base a la probabilidad y el impacto que
se especique, con la siguiente formula y dependiendo del resultado se ubica en la siguiente matriz
de riesgo el color que le corresponda: Ver gura 5.8.
Probabilidad + Impacto / 2 * 10 = Nivel de Exposicion individual del riesgo. Ejemplo: probabilidad
4 + impacto 5 = 9 / 2 = 4.5 * 10 = 45 (Nivel de Exposici on individual del riesgo: 45 Equivale al
color verde)
Figura 5.8: Matriz de riesgo de color respecto a la probabilidad y el impacto del riesgo.
La formula utilizada anteriormente nos sirve para calcular el nivel de exposicion individual cada
vez que modicamos el seguimiento de un riesgo, sin embargo ese calculo se realiza por el sistema
pero no se representa de manera visual, solo se guarda y se utiliza despues para calcular la exposicion
general que en este sistema es la que mas nos interesa.
5.1.5 Nivel de exposicion general del riesgo.
De acuerdo a lo anterior el nivel de exposicion general del riesgo se muestra mediante un semaforo,
el cual cambia cada vez que se registra un nuevo riesgo o cada vez que se altera la probabilidad y el
impacto del seguimiento del riesgo, el semaforo en cuesti on se debe rellenar con los datos recabados
por el calculo realizado en base a la media de los niveles de exposici on individual de los riesgos del
objetivo, proceso o iniciativa de la que se trate, divididos entre el n umero total riesgos registrados,
lo que da como resultado el nivel de exposici on general del riesgo. Ademas contiene una descripcion
que le da al usuario nal una idea mas clara del rumbo que esta tomando el avance del seguimiento
del riesgo.
Se debe localizar a traves de la gura 5.9, cual color darle al semaforo general, de acuerdo al
porcentaje de exposici on general que se haya calculado:
Figura 5.9: Color que se le debe dar al semaforo del riesgo de acuerdo al nivel de exposicion general
calculado.
Con toda esta informaci on recabada procedemos a mostrar en la gura 5.10 la exposicion general
del riesgo y la descripcion que toma de acuerdo al color y al valor calculado con la f ormula propuesta
anteriormente, misma que es presentada dentro del dise no general del sistema de consulta de Riesgos.
Figura 5.10: Exposici on general del riesgo.
Este semaforo tiene que ver primero con la exposicion individual de los riesgos, luego con el
total de riesgos registrados y nalmente con los cambios que se realicen en la continuidad que se le
este dando a los seguimientos de los riesgos seleccionados.
De igual forma cada que se cambia los datos de probabilidad o impacto en el seguimiento de
un riesgo, se actualiza la graca de trazabilidad del seguimiento de los mismos, esta se analizara a
continuaci on.
5.1.6 Graca de trazabilidad del seguimiento de riesgos.
La graca de trazabilidad no debe contener datos hasta que se seleccione un riesgo, entonces se
debe mostrar la trazabilidad del mismo.
La trazabilidad debe estar compuesta por:
Eje Y: Escala de porcentaje de 0 a 100.
Eje X: Fechas de reporte de seguimiento del riesgo, agrupadas por los estados en los que ha
estado el riesgo en dichas fechas.
Series: Porcentajes del nivel de exposici on individual del riesgo en las fechas de seguimiento
capturadas.
Con lo anterior podemos deducir que la graca de trazabilidad tambien esta vinculada con cada
transacci on que se realice dentro del m odulo de consulta de plan de riesgos, y que su comportamiento
depende de la periodicidad y de las fechas de capturas de los datos del seguimiento, as como de la
probabilidad e impacto que se tenga en ciertas fechas. Ver gura 5.11.
Figura 5.11: Trazabilidad del riesgo seleccionado.
En esta graca podemos observar el comportamiento y el avance en el seguimiento de los riesgos
registrados y de esta manera el usuario nal tiene una perspectiva mas amplia en cuanto al esfuerzo
realizado por solucionar o mitigar los riesgos que han sido previstos en la organizacion.
5.1.7 Presentacion nal del modulo de consulta de riesgos.
En esta secci on presentamos la versi on nal de la aplicaci on, con todas las partes del m odulo
organizadas y conjuntas en una sola y ejecutandose en conjunto a los demas modulos que integran
el Sistema para Captura y Seguimiento de Riesgos Organizacionales.
En la gura 5.12 se puede observar el esquema nal del m odulo de captura y seguimiento de
Riesgos.
Figura 5.12: Integraci on nal del modulo de captura y seguimiento Riesgos.
De esta manera se culmina con la integracion de todas las partes que conforman el modulo de
consulta de plan de riesgos, el cual contiene una tabla con la lista de riesgos registrados, otra tabla
con los seguimientos que se le esten dado al riesgo seleccionado, un formulario de captura para
actualizar los seguimientos del riesgo de acuerdo a las fechas registradas, un area que muestra la
exposicion general del riesgo y la descripci on de acuerdo al color que indica c omo va el seguimiento
del mismo, y por ultimo una graca que muestra la trazabilidad o el avance en el cumplimiento de
los objetivos para mitigar el riesgo previsto por la organizaci on previamente.
66 5.2. Resumen
5.2 Resumen
En este captulo se describieron los resultados obtenidos al utilizar las tecnologas de Silverlight
y .Net usando Visual Studio 2012 como entorno de desarrollado en el sistema, de igual forma se
mencionaron las ventajas de utilizar estas herramientas para desarrollo de interfaces Web.
Se analizo cada parte que integra al sistema y se fue siguiendo y describiendo paso a paso cada
una de las secciones hasta terminar con la integraci on nal, se analizaron ejemplos de validacion,
mapeo de clases, despliegue del sistema, entre otras cosas y se mostraron ejemplos sobre la creacion
de nuevas interfaces utilizando la tecnologa de Silverlight.
6
Conclusiones y trabajo futuro
6.1 Conclusiones
Silverlight y .NET son sin duda una buena combinacion cuando se habla de desarrollo web ya
que ofrecen una serie de caractersticas que hacen posible el desarrollo de aplicaciones potentes,
exibles, extensibles, ligeras, entre otras, elimina en gran medida la complejidad de desarrollo y
permite la reutilizaci on de codigo ademas incorpora anotaciones mediante la plataforma para facilitar
el desarrollo de aplicaciones.
Por otra parte es importante que a la aplicacion del Sistema que se realiz o pueda tener una
revisi on en los proximos meses, esto se centra en dos puntos importantes:
Los procesos de gesti on y administraci on tienen que adecuarse al tama no, orden y necesidades
de la empresa; es decir, que con el caminar de la empresa, van a surgir mas y/u otras
necesidades, para ello, el sistema debe estar preparado para ser sujeto a mantenimiento, y
que pueda ser extensible en funcionalidades de una manera rapida y ecaz.
67
68 6.2. Trabajo futuro
Es bien sabido que los avances Tecnologicos son abrumadoramente rapidos, por lo que de igual
manera el Sistema para Captura y Seguimiento de Riesgos Organizacionales, debe soporta una
o varias posibles migraciones de plataforma, de entornos de programacion; ademas de poder
estar al alcance de cada uno de los involucrados en sus procesos de gesti on y al propio personal
que labora all.
Ademas, es de relevante importancia que las personas involucradas en este desarrollo, cuenten con
las herramientas mas innovadoras al momento, as como poder ofrecer un producto diferente, esto
en el sentido que pueda ser un producto que por su arquitectura de desarrollo pueda ser reconocida;
aunque claro esta, depende en gran medida de la visi on y de la disponibilidad de la empresa.
Finalmente se recomienda enormemente al lector que se instruya con mucho animo y j ubilo en
el camino al que la profesi on de Tecnologas de la Informacion y Comunicacion se reere; a pesar de
que hoy en da, no es reconocida como debiera ser.
6.2 Trabajo futuro
Como trabajo futuro se plantea implementar el Sistema para Captura y Seguimiento de Riesgos
Organizacionales primero dentro de la misma organizacion y despues darlo a conocer hacia otras
organizaciones con la nalidad de convertilo en un sistema rentable como servicio web y que las
demas empresas puedan beneciarse de esta potente herramienta para hacer posible la tarea de llevar
un control mas detallado de los Riesgos que en su momento amenacen los objetivos organizacionales
de la empresa.
A
Diagramas
A.1 Diagrama de Caso de Uso
Figura A.1: Diagrama de caso de usos
69
70 A.2. Diagrama de Clases
A.2 Diagrama de Clases
Figura A.2: Administraci on de Riesgos
A. Diagramas 71
Figura A.3: Servicios Web del Riesgo
Figura A.4: Consultar usuario Riesgo
A. Diagramas 73
Figura A.5: Registrar usuario responsable del Riesgo
Figura A.6: Asignar usuario
Bibliografa
[1] Ralston Anthony. Encyclopedia of Computer Science. Editorial Van Nostrand Reinhold, 3 edition,
1993.
[2] M. Rose C. Mellon. Dover Beach Consulting. Editorial Universidad Tecnol ogica Nacional, 2
edition, 1997.
[3] Scott Dunn. Dropbox File Sync Service. PC World, 1 edition, 2008.
[4] J. Klein P. Hallam-Baker. Web Services Security (WSSecurity). IBM, 3 edition, 2009.
[5] Ryan Paul. How Dropbox ended my search for seamless sync on Linux. Ars Technical, 2 edition,
2009.
[6] Daniel Pe na Sanchez de Rivera. Deducci on de distribuciones: el metodo de Monte Carlo. Editorial
Universidad Autonoma de Madrid, 2 edition, 2010.
[7] Lujan Mora Sergio. Programaci on en Internet. Editorial Club Universitario, 1 edition, 1992.
75

Thesis

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Thesis

Загружено:

Авторское право:

Доступные форматы

Instituto Tecnol

ogico Superior de los R

Indice de Tablas VII

Вам также может понравиться