Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Ries Ope Siro PDF
Ries Ope Siro PDF
ESCUELA DE POSTGRADO
El presente proyecto nace como resultado de la necesidad que tienen las Instituciones
financieras de realizar la gestin de los riesgos debido a la incertidumbre que pasan a
partir de eventos pequeos, predecibles y frecuentes, por lo que en el mes de junio del
2004 En el nuevo Acuerdo de Capitales de BASILEA II se define lo Siguiente: el riesgo
de prdida directa debido a la inadecuacin o a fallos en los procesos, el personal y los
sistemas internos o bien a causa de acontecimientos externos. Esta definicin incluye el
riesgo legal, pero excluye el riesgo estratgico y el de reputacin,
2
Introduccin
El riesgo operativo es otro componente gestin de riesgo segn BASILEA II que son las
mejores se reunieron los 10 pases ms ricos del mundo y pensaron por que perdan
tanto y ah se defini los riesgos: Personas, procesos, tecnologa informacin y aspectos
externos en esto se basa el riesgo operacional que es la base de Basilea II.
3
1. CAPITULO 1 - Generalidades
4
principalmente para personal que no integra la Unidad de Riesgos, que est basada en el
uso de herramientas del tipo Open Source, y principalmente la flexibilidad que deba tener
la herramienta ante cambios normativos, con un adecuado soporte tcnico a nivel pas y
de costos accesibles, al no existir dicha herramienta con tales caractersticas es que se
inici la construccin de SIRO.
SIRO, debe soportar la metodologa Australiana Neocelandesa 4360, y el estndar
COSO/ERM, debe contar con el detalle funcional que se indican en las normativas
peruanas.
5
la utilizacin de un software de riesgo operacional. Esto hace que la gestin del
riesgo tenga un carcter espordico y no se tome el riesgo operacional como una
cultura organizacional, debido a que para el manejo de los riesgos se necesita
informacin de mltiples fuentes la gestin se hace tediosa y muchas veces no se
toma en serio en las organizaciones. Un inconveniente ms a la gestin de
riesgos es que el no contar con un sistema informtico que gestione el riesgo la
consolidacin de la informacin se realiza de manera manual, lo cual conlleva a
trabajos mecnicos no deseados por los profesionales en la gestin de riesgos
debido a la complejidad del tratamiento de la informacin, y todo esto hace que la
participacin de las diferentes reas y dueos de los procesos sea insuficiente y
tengan poco compromiso en la participacin de la gestin del riesgo operacional,
trayendo como consecuencia un falta de internalizacin de la metodologa, entre
las reas de auditora, logstica, negocios, sistemas, organizacin y mtodos, y as
mismo trayendo como consecuencia un mayor incremento de la provisin que se
tiene por riesgo operacional (requerimiento patrimonial); Ver Figura 2
6
Las entidades bancarias y financieras tienen muchas sucursales ubicadas dentro
del territorio nacional por lo que es necesaria la utilizacin de ancho de banda
(Internet - Segura) para enviar informacin, la herramienta a desarrollarse
permitir la conectividad por medio del browser sobre la arquitectura de las
herramientas del mercado.
7
Resolucin CGR 458-2008: Gua para la Implementacin del SCI
Adems la utilizacin de RUP es una restriccin del proyecto por ser una metodologa
de desarrollo de software que el equipo de trabajo conoce y ha utilizado en proyectos
anteriores.
8
2. CAPITULO 2 - MARCO TERICO
2.1 El Riesgo Operacional en las Entidades Financieras
9
Dado que los riesgos menos significativos se asumen como parte del negocio y
ya se han considerado al fijar el precio de los productos y servicios financieros, y
los menos frecuentes y de mayor impacto representan circunstancias muy
anmalas, el inters de la gestin se centra en los riesgos medios, distintos entre
s. La entidad dispone de informacin suficiente sobre los eventos frecuentes y
de pequea cuanta, lo que permite modelizar su distribucin de prdidas,
aplicando herramientas estadsticas.
10
que las tcnicas cuantitativas pretenden reflejar estadsticamente el
comportamiento de las prdidas, situando la prdida esperada, inesperada y
excepcional (la cola de la distribucin, que refleja los riesgos extremos), la
utilidad de los instrumentos cualitativos radica en identificar y vigilar estos
riesgos, pudiendo contribuir al desarrollo de metodologas de gestin interna que
colaboren en el desarrollo de modelos avanzados. Entre ellos destacan los
indicadores de riesgo y las redes causales.
a) Indicadores de Riesgo:
Se identifican variables representativas del funcionamiento de la entidad en
aquellos puntos que puedan derivar en prdidas operacionales, permitiendo la
identificacin, control y seguimiento del riesgo. En consecuencia, al diseo de un
Cuadro de Mando en entidades financieras tradicional debera incorporarse un
conjunto de indicadores de riesgo. Para ello, a las cuatro perspectivas
tradicionales (pero no necesariamente las nicas) propuestas por Kaplan y
Norton (clientes, proceso interno, aprendizaje y crecimiento y financiera) debe
sumarse una ms referida al riesgo o, alternativamente, incluir indicadores al
respecto en las ya existentes, pudiendo identificarlos para los cuatro drivers
citados en Basilea-II.
b) Redes causales
Son representaciones grficas de relaciones causales entre variables. Partiendo
del conocimiento previo, se trabaja con probabilidades a priori que podrn
modificarse a travs del anlisis para definir probabilidades a posteriori.
11
El pilar 2 (revisin supervisora) al verificar que el capital calculado es apropiado y
responde al perfil de riesgos de la entidad
El pilar 3 (disciplina de mercado) exigiendo que se revele la informacin relativa a
la carga de capital y mtodo aplicado.
Los mtodos para el clculo de requerimiento de capital son:
12
Con El Software de Riesgo operacional Como herramienta se permite cumplir con
uno de los requerimientos que permite gestionar el RO de modo ms eficiente y
permite la contribucin de la cultura de la gestin del RO en la Organizacin.
En la actualidad los bancos tienen base de datos de prdidas que permiten recopilar
eventos de prdidas que son desarrollos de Empresas internacionales y uno que otro
software desarrollado de manera interna que no est certificado por la SBS.
Esta informacin es obtenida de las propias pginas web de las compaas que
brindan software de Riesgo Operacional, la informacin manejada por estos software
tiene carcter de confidencial por las entidades financieras por tratarse de riesgos
operativos que no deben salir del entorno organizacional, es por ello que el software
debe tener niveles de seguridad que aseguren la privacidad de la informacin, esto es
algo que las compaas no muestran en la informacin de sus producto.
En resumen las empresas que hay en el mercado brindan una serie de herramientas
que pueden manejar el riesgo operacional y lo que hacen es adecuar las polticas de
las organizaciones al uso de la herramienta, no tienen embebidas la normativa
peruana dentro del core del software, lo que hacen es adecuar el software a la
normativa peruana con ciertos problemas que pasan a ser problemas de la
organizacin.
13
Figura 3 : Principales Software Existentes en el Mercado Nacional
- Parmetros.
- Mdulo Riesgos/Controles (COSO ERM).
- Modulo de Eventos de Prdida.
- Indicadores.
- Ayuda.
- Seguridad.
- Reportes.
- Reportes Estadsticos.
14
- Se utilizara la Metodologa RUP para el Desarrollo de Software
- El sistema permitir alternar entre el teclado y el Mouse.
- El sistema correr en plataformas Windows 2000/Windows XP y
superiores.
- El sistema deber contribuir en el ahorro de tiempo en los registros y
bsquedas.
- El sistema deber ser portable, tanto la aplicacin como la base de
datos para su uso conveniente.
- Se utilizar como gestor de base de datos PostgreSQL, con licencia
libre
- Para el manejo de la seguridad, el sistema contar con niveles y roles
de usuario para el manejo al sistema.
- El sistema deber ser portable, tanto la aplicacin como la base de
datos para su uso conveniente.
Adems de la descripcin de los requerimientos tanto funcionales como no
funcionales se ha realizado una evaluacin segn la prioridad y la
exigencia de acuerdo a la necesidad tal y como se muestra a continuacin.
Prioridad Exigencia
B: baja E: exigible
M: media D: deseable
A: alta
15
Desarrolladores, Lder del Proyecto entre otros) y el tesista que es el
responsable de toda su elaboracin con el apoyo de un asesor, el cual es
brindado por la Pontificia Universidad Catlica del Per.
Viabilidad Tcnica:
Con Referencia a los requerimientos tcnicos para la elaboracin del
proyecto de tesis, se cuenta con las herramientas necesarias para su
desarrollo, como son: IDE Netbeans 6.8, motor de Base de Datos
PostgreSQL 8.4 y 03 computadoras, 01 servidor desarrollo, 02 lap top y
como generador de reportes IReports for Jasper Report 3.7.2, para el
encriptamiento de la informacin en la base de datos se utiliza el Sistema
de Algoritmo de Encriptamiento Matemtico AES 128 bits, para la
realizacin del diseo grafico se utilizara el EXTJs, para la visualizacin de
grficos y formularios se utiliza la librera SexyLightbox 2.3, Como servidor
web se utilizar el Apache Tomcat 5.5.28. Con respecto a los posibles
problemas que surjan por el uso de estas herramientas, estas son de usos
generales y muy difundidos, por los que se cuenta con amplia informacin
para solucionar cualquier inconveniente que ocurra durante el desarrollo
del proyecto de tesis.
16
De la Tabla Anterior se puede observar que el costo para la realizacin del
presente proyecto es de alto, gran parte de estos costos han sido asumidos por el
tesista y un socio que es el profesional de riesgo operacional; Adicionalmente se
ha realizado una valorizacin de del trabajo realizado por lo que no se ha
realizado el desembolso total del dinero para este proyecto, el desarrollo en la
totalidad se ha realizado en la ciudad de Piura, para el proceso de implantacin y
puesta en marcha del proyecto se detallara en la seccin correspondiente a
implantacin.
2. Robustez:
El sistema tendr capacidad para funcionar correctamente utilizando poco
ancho de banda para enviar y/o recibir informacin, debe funcionar de
manera correcta en caso se realicen entradas de informacin errneas,
debe funcionar correctamente ante mltiples accesos de usuarios validado
en el sistema.
3. Utilidad:
El sistema ser fcil de utilizar y tendr un entorno de trabajo amigable con
referencias para los usuarios de riesgo operacional, adems ser
apropiado para cualquier usuario que tenga autorizacin de hacer uso de
l.
4. Capacidad de Configuracin:
17
El sistema ser capaz de ser configurable, parametrizado segn la
normativa de la SBS de acuerdo a la complejidad y estructura de las
operaciones de las entidades financieras lo cual permitir extender su
plazo de vida til antes de su prximo mantenimiento.
5. Capacidad de Mantenimiento:
El diseo de este sistema permitir dar mantenimiento sin
complicaciones, respetando el diseo de la interfaz lo ms que se pueda.
6. Seguridad:
El sistema mantendr segura la informacin, realizando algunos ingresos
de datos a las bases de datos de manera encriptado adems el sistema
trabaja en base a perfiles y roles de usuario permitiendo solo el acceso a
usuarios autorizados, lo cual evitar de manera eficiente cualquier
infiltracin por parte de personas ajenas al sistema, Adems se tiene
seguridad web basado en sesiones de acceso al sistema lo cual no permite
acceder al sistema sin antes haberse identificado en el sistema.
18
operacional, gestin de controles y la gestin de los eventos de prdida, con usuarios
ilimitados, adems permitir gestionar los riesgos operacionales utilizando las mejores
prcticas del mercado, tales como COSO/ERM y AS/NZS 4360:2004. Deber ser una
herramienta creada en un entorno Web logrando que la gestin de riesgos sea una
experiencia sencilla, agradable y productiva.
4. CAPITULO 4 - DISEO
Paquete General
19
El paquete General contiene los casos de uso que corresponden a la
administracin de los parmetros que se utilizan para la gestin de los riesgos,
la administracin del sistema, administracin de los riesgos, el registro de los
controles que actan como mitigadores de los riesgos, el registro de los
eventos de prdida, el registro de los indicadores por riesgo identificado, la
gestin de seguridad y gestin de alertas.
Los casos de uso incluidos en este paquete son:
Administrar sistema
Responsable de sistemas
Administrador del sistema
Gestionar Parametros
Registrar Controles
Responsable de la Gestion
Responsable del Sistema Control Interno
Gestion de seguridad
Gestor de Riesgos
Gestionar Riesgos
Gerencia Riesgos
Administrar Sistema
Gestionar Accesos
<<extend>>
Asociar Riesgos
Registrar Controles
<<extend>>
<<extend>>
Registrar evaluaciones Imprimir evaluaciones
Registro De Controles
<<extend>>
Asociar Riesgos
Registrar Controles
<<extend>>
Registrar evaluaciones
Imprimir evaluaciones 21
Figura 14: Diagrama de Casos de Uso del Paquete Registro de Controles
Paquete Registro de Eventos de Prdida
El paquete Registro de Eventos de Prdida contiene los casos de uso que
corresponden al registro de los eventos de prdida, siendo realizado por el actor
(Responsable de la gestin, Gestor de riesgos).
Los casos de uso incluidos en este paquete son:
Asociar criterios
<<extend>>
<<extend>>
Asociar Riesgos
Registrar Eventos Perdida
Gestor de Riesgos
<<extend>>
Registrar Cuantificaciones
Registrar criterios
Registrar calculo
Registrar Recuperaciones
Responsable de la Gestion
Cerrar Evento Perdida
Figura 15: Diagrama de Casos de Uso del Paquete Registro de Eventos de Prdida
Paquete Gestin de Seguridad
El paquete Gestin de Seguridad contiene los casos de uso que corresponden a
la administracin de usuarios y perfiles de usuarios para la integridad del sistema.
Los casos de uso incluidos en este paquete son:
22
Figura 15: Diagrama de Casos de Uso del Paquete Gestin de Seguridad
4.2 Arquitectura del Software
Arquitectura 3 Capas
23
La arquitectura Model-View-Controller surgi como patrn arquitectnico
para el desarrollo de interfaces grficas de usuario en entornos Smalltalk. Su
concepto se basaba en separar el modelo de datos de la aplicacin de su
representacin de cara al usuario y de la interaccin de ste con la
aplicacin, mediante la divisin de la aplicacin en tres partes
fundamentales:
24
Figura 17: Arquitectura Java
25
El sistema de gestin de base de datos PostgreSQL nace en la universidad
de Berkeley - California, en los aos 80, como un proyecto acadmico y
actualmente se encuentra en la versin 8.1, siendo permanentemente
mantenido por la comunidad Open Source. La coordinacin del desarrollo del
PostgreSQL es realizada por el Global Development Group, que est
formada por un amplio grupo de desarrolladores alrededor del mundo, que
permite al PostgreSQL evolucionar constantemente en cuanto a la correccin
de errores y la implementacin de nuevas funcionalidades.
4.4.5 Ireport
iReport puede ayudar a la gente que no conoce la sintaxis XML para generar
reportes de JasperReports.
Funcionamiento de iReport
iReport provee a los usuarios de JasperReports una interfaz visual para
construir reportes, generar archivos jasper y print de prueba. iReport naci
como una herramienta de desarrollo, pero puede utilizarse como una
herramienta de oficina para adquirir datos almacenados en una base de
datos, sin pasar a travs de alguna otra aplicacin
26
Fig
ura 18: Gestin de Reportes con Ireport
27
Figura 19: Diagrama de Secuencia Registrar Riesgo
28
4.6 Diagrama de Componentes
El Presente Diagrama de componentes muestra los distintos componentes que se utilizan desde las distintas capas implementadas en el proyecto de
desarrollo de Software
29
4.7 Diagrama de Despliegue
30
4.8 Diseo de interfaz grfica
31
Para Mayor detalle de la Parte de Diseo revisar el Anexo _RDS_Tesis_Siro
donde tambin se podr ver el modelo lgico y el modelo fsico de la base de
datos
Comentarios de Inicio
Definicin Package
Declaraciones de Import
Declaraciones de la Clase
Comentario Documentacin de la Clase
Estamento class
Atributos o Variables Estticas
public
protected
private
Atributos
public
protected
32
private
Constructores
Mtodos
33
public Plantilla() {
// implementacin
}
5.3 Despliegue.
5.4 COMPONENTES
Los componentes que se utilizaran para la instalacin del software en alguna entidad
financiera son:
http://www.oracle.com/technetwork/java/javase/downloads/in
dex.html#need
Java Runtime
JAVA 6
1 Environment Servidor
actualizacin 22
JRE https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-
CDS_Developer-Site/en_US/-/USD/ViewProductDetail-
Start?ProductRef=jre-6u22-oth-JPR@CDS-CDS_Developer
http://get.adobe.com/es/flashplayer/
Adobe Flash Player 10
2 10.1.82.76
Activex Cliente
http://www.adobe.com/support/flashplayer/downloads.html
http://tomcat.apache.org/download-55.cgi
3 Apache Tomcat 5.5.28
Servidor
http://rapidshare.com/files/360833847/apache-tomcat-
5.5.28.exe
34
http://www.postgresql.org/download/ Servidor
4 PostgreSQL 8.4
35
b) Jornada de capacitacin en aplicacin de la metodologa de Riesgos
Operacionales.
36
del cual forma parte todo el personal de La Entidad, a fin de dar
cumplimiento a lo indicado en la Resolucin SBS N 037-2008 del
10/01/2008.
Otro mbito sobre el cual tendr incidencia el trabajo de los gestores del
riesgo operacional ser precisamente en el rea donde labora, por lo que las
Gerencias de lneas, debern comunicar oficialmente a todo el personal del
establecimiento y asignacin del rol de un Gestor de Riesgo Operacional.
37
6. CAPITULO 6 - PRUEBAS
Con referencia a las pruebas de aceptacin estas sern realizadas por las
entidades que adquieran el software de acuerdo a los estndares de
pruebas y de acuerdo a los criterios propios de cada institucin, se espera
que el Sistema SIRO cumpla con los requisitos de la Normativa de la
Superintendencia de Banca y Seguros.
Propsito: Una o dos oraciones cortas sobre el aspecto del sistema que
est siendo probado. Si esto toma mucho tiempo, rompa el
caso de prueba o ponga ms informacin en las descripciones
de las caractersticas.
38
rangos de valores. El caso de prueba deber ser ejecutado
una vez por cada combinacin de valores. Estos valores se
escriben notacin de asignacin, uno por lnea. Por ejemplo:
loginID = {loginID vlido, loginID invlido, email vlido, email
invlido , vaco}
password = {vlido, invlido, vaco}
Suceso / Alternativa. Se listan una serie de sucesos, los cuales contienen los pasos
a seguir, los que determinan una situacin de la cual se tomar
la alternativa ms adecuada.
Suceso 1:
1
n.
Alternativa:
Suceso n:
1.
n.
Alternativa n:
39
PREGUNTA
40
A continuacin presentaremos un ejemplo de un caso de pruebas si desea ver mas
casos de pruebas podr referirse al anexo _Pruebas_de_Siro.
Propsito: Acceder al sistema, mediante el logeo respectivo del usuario autorizado. (Fig.
1)
Pre-requisitos: Acceder al icono del escritorio, correspondiente al sistema, haciendo doble
clic. Suponer que el usuario ya se encuentra registrado.
Datos de Prueba: loginID = {loginID vlido, loginID invlido, vaco}
clave = {vlido, invlido, vaco}
Pasos: 1. Ejecutar el sistema SIRO
2. teclear el Login
3. teclear clave
4. hacer click en Aceptar
5. ver: Pagina de Informacin Personal
6. verificar el mensaje de bienvenida si el inicio de sesin es correcto.
Notas y Debe permitir como mximo hasta 3 intentos para el inicio de sesin, en caso
Preguntas: contrario recomendarse comunicarse con el encargado del servidor.
Suceso / Suceso 1:
Alternativa. 1. Repetir la secuencia principal hasta el tem 2.
2. Clic en el botn Aceptar
41
Suceso 3:
1. Repetir la secuencia principal hasta el tem 4.
2. Si la clave de acceso, es correcta.
(Fig. 2)
(Fig. 3)
(Fig. 4)
42
7. CAPITULO 7 - GESTIN Y CONFIGURACIN DEL CAMBIO.
Los cambios dentro del desarrollo del software pueden ocurrir en cualquier
momento por lo tanto debemos estar preparados, las actividades de CGS
sirven para:
Actividades
b. Control de cambios
43
afectan estas versiones bsicas, y finalmente asegurar que los cambios
requeridos son actualmente hechos a las versiones bsicas de los productos
una vez se han aprobado.
Ante cualquier cambio que se realice al software se debe de tener en cuenta
lo siguiente:
1. Peticin de cambio
2. Evaluacin del cambio: Esfuerzo tcnico, efectos secundarios,
impacto sobre otros componentes, costos.
3. Informe de Cambios (resultados evaluacin) a la ACC (Autoridad de
Control de Cambios).
4. Se genera una OCI (Orden de Cambio de Ingeniera) para cada
cambio: qu se cambiar; restricciones, criterios de revisin y
auditora.
5. Objeto dado de baja
6. Realizacin del cambio
7. Revisin del cambio.
8. Objeto dado de alta aplicando mecanismos de control de versin.
c. Control de versiones
d. Informe de estado
44
Se debe de registrar cuales son los cambios que se han realizado a los
requerimientos ya establecidos en el sistema, as mismo indicar si algunos
de los componentes fueron afectados debidos a estos cambios.
e. Auditorias y revisiones
45
8. CAPITULO 8 - PLAN DE PROYECTO
8.1 Metodologa
46
8.2 Fases del Plan
tiempo. construccin.
Identificacin de indicadores.
47
Identificacin de reportes.
Elaboracin del diagrama de clases.
Diseo de la arquitectura.
Diseo de la interfaz grfica.
Ampliacin del diagrama de clases.
Diseo de la Base de Datos.
Seleccin de tecnologas.
Construccin de la aplicacin. La finalizacin del proyecto
Construccin de los reportes. obteniendo el sistema y la
Fase de
Elaboracin del plan de pruebas. base de datos probados y
Construccin
Elaboracin de casos de prueba. listos para su uso por el
Evaluacin de casos de prueba. usuario.
48
1.5.1. Estructura de Descomposicin del Trabajo
49
9. CAPITULO 9 - CONCLUSIONES Y RECOMENDACIONES
9.1 Conclusiones
50
9.2 Recomendaciones y trabajos futuro
51
10. Bibliografa
ESCALAR CONSULTINGMDULO
2010 Modulo de Riesgo Operativo de Power Risk de la empresa Escalar
Consulting
Consulta: Diciembre 2010
http://www.grupoescalar.com/software/riesgo_operativo.htm
METHOD WARE
2010 MeSoftware ERA de la Empresa Method Ware obtenido noviembre
Consulta : Noviembre
http://www.methodware.com/era/
AGUILAR, G. Y CAMARGO G.
2004 Anlisis de la Morosidad en las instituciones microfinancieras del
Per. En Mercado y Gestin del microcrdito en el Per.
Lima: Consorcio de Investigacin Econmica y Social. Serie:
Diagnstico y Propuestas No 12.
ALEXANDER, C.
2003 The present and future of financial Risk Management, ISMA Centre.
Oxford University
Consulta: Marzo 2010
http://jfec.oxfordjournals.org/content/3/1/3.short
52
CEMLA.ORG
2004 Comit de Basilea y Comit Tcnico de la Organizacin Internacional
Comisiones de Valores, (1997), Boletn del Cemla.
http://www.cemla.org/newsletters/newsletter-0103-basilea.htm
Jorion, Philippe.
2008 Valor en Riesgo. El nuevo paradigma para el control de riesgos con
Colombia: Editorial Limusa.
53