Sistema de Gestión de Requerimientos de Información para GCIF

Transcription

IMPLEMENTACIÓN DE UN SISTEMA DE GESTIÓN DE REQUERIMIENTOS DE
INFORMACIÓN PARA LA GERENCIA DEL CENTRO DE INFORMACIÓN
FINANCIERA DEL BANCO DE BOGOTÁ
TULIO ARMANDO NIÑO BALLESTEROS
JUAN CARLOS LOZANO RAMÍREZ
FERLEYN ANDRÉS DUARTE
UNIVERSIDAD DE SAN BUENAVENTURA
FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS
BOGOTÁ D. C.
2007
IMPLEMENTACIÓN DE UN SISTEMA DE GESTIÓN DE REQUERIMIENTOS DE
INFORMACIÓN PARA LA GERENCIA DEL CENTRO DE INFORMACIÓN
FINANCIERA DEL BANCO DE BOGOTÁ
TULIO ARMANDO NIÑO BALLESTEROS
JUAN CARLOS LOZANO RAMÍREZ
FERLEYN ANDRÉS DUARTE
Proyecto de Grado como requisito para optar
al Título de Ingeniero de Sistemas
Sandra Lucía Guañarita Fernández
UNIVERSIDAD DE SAN BUENAVENTURA
FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS
BOGOTÁ D. C.
2007
Nota de Aceptación:
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
_________________________________
FIRMA
_________________________________
FIRMA
_________________________________
FIRMA
Bogotá D. C., 26 de mayo de 2007
DEDICATORIA
Queremos dedicarle este logro a Dios, por permitirnos llegar a este punto y a
nuestros padres, por su motivación y apoyo.
AGRADECIMIENTOS
Queremos agradecer a todas las personas que nos apoyaron y guiaron durante el
desarrollo
del
proyecto;
agradecemos
su
conocimientos, pero lo más importante… su fé.
ayuda,
su
comprensión,
sus
ABSTRACT
El término WorkFlow surgió en los años 80 para resolver las necesidades que
tenían muchas empresas con respecto al movimiento de sus documentos dentro
de las compañías. En aquel momento el término WorkFlow fue asociado a
productos de gestión de imágenes (todo el mundo quería eliminar el papel y se
produjo el boom del escaneado de documentos). Pero estos productos de
entonces requerían un hardware y un software propietario, algo muy distinto a lo
que ocurre ahora, que las herramientas de WorkFlow son abiertas e integradoras
de cualquier producto.
The term WorkFlow arose in years 80 to solve the necessities that had many
companies with respect to the movement of their documents within the companies.
At that time the term WorkFlow was associated to products of management of
images (everybody wanted to eliminate the paper and the boom of the document
scanned one took place). But these products of then required a hardware and a
propietary software, something very different from which it happens now, that the
tools of WorkFlow are opened and integrating of any product.
CONTENIDO
Pág.
LISTA DE TABLAS...............................................................................................................9
LISTA DE FIGURAS ..........................................................................................................10
LISTA DE ANEXOS ...........................................................................................................12
INTRODUCCIÓN................................................................................................................13
1.
PLANTEAMIENTO DEL PROBLEMA ..................................................................15
1.1.
ANTECEDENTES.................................................................................................15
1.2.
DESCRIPCIÓN Y FORMULACIÓN DEL PROBLEMA.........................................17
1.3.
JUSTIFICACIÓN...................................................................................................17
1.4.
OBJETIVOS DE LA INVESTIGACIÓN .................................................................18
1.4.1.
OBJETIVO GENERAL..........................................................................................18
1.4.2.
OBJETIVOS ESPECÍFICOS ................................................................................19
1.5.
ALCANCES Y LIMITACIONES DEL PROYECTO ...............................................19
1.5.1.
ALCANCES ..........................................................................................................19
1.5.2.
LIMITACIONES ....................................................................................................20
2.
MARCO DE REFERENCIA ..................................................................................21
2.1.
MARCO CONCEPTUAL.......................................................................................21
2.2.
MARCO LEGAL O NORMATIVO .........................................................................22
2.3.
MARCO TEÓRICO ...............................................................................................27
3.
METODOLOGÍA ...................................................................................................41
3.1.
HIPÓTESIS...........................................................................................................41
3.2.
VARIABLES..........................................................................................................41
3.2.1.
VARIABLES INDEPENDIENTES .........................................................................41
3.2.2.
VARIABLES DEPENDIENTES.............................................................................41
4.
DESARROLLO INGENIERIL...............................................................................42
4.1.
ANÁLISIS..............................................................................................................42
4.1.1.
ANÁLISIS SISTEMA ACTUAL..............................................................................42
4.1.2.
ANÁLISIS SOLUCIÓN PROPUESTA...................................................................46
4.1.3.
ESPECIFICACIÓN DE REQUERIMIENTOS........................................................54
-7-
4.2.
DISEÑO ................................................................................................................55
4.2.1.
DIAGRAMA DE CLASES .....................................................................................57
4.2.2.
DISEÑO CONCEPTUAL DE LA BASE DE DATOS .............................................58
4.2.3.
DISEÑO FÍSICO DE LA BASE DE DATOS..........................................................60
4.2.4.
DICCIONARIO DE LA BASE DE DATOS ............................................................62
4.2.5.
DICCIONARIO DE RELACIONES DE LA BASE DE DATOS ..............................63
4.2.6.
TABLAS ESTRUCTURALES DEL WORKFLOW .................................................63
4.2.7.
DICCIONARIO DE PROCEDIMIENTOS ALMACENADOS .................................65
4.3.
IMPLEMENTACIÓN .............................................................................................68
4.3.1.
INTERFAZ DE USUARIO.....................................................................................74
4.3.2.
MAPA DEL SITIO .................................................................................................86
4.3.3.
ESQUEMA DE PRUEBAS....................................................................................88
5.
CONCLUSIONES .................................................................................................92
6.
BIBLIOGRAFÍA.....................................................................................................94
-8-
LISTA DE TABLAS
Pág.
TABLA 1. DICCIONARIO DE LA BASE DE DATOS..........................................................62
TABLA 2. DICCIONARIO DE RELACIONES DE LA BASE DE DATOS............................63
TABLA 3. TABLA ESTRUCTURAL DE ESTADO ..............................................................63
TABLA 4. TABLA ESTRUCTURAL DE ROL......................................................................63
TABLA 5. TABLA ESTRUCTURAL DE ESTADOEVENTO................................................64
TABLA 6. TABLA ESTRUCTURAL DE EVENTO ..............................................................64
TABLA 7. TABLA ESTRUCTURAL DE TIPOARCHIVOADJUNTO ...................................64
TABLA 8. DICCIONARIO DE PROCEDIMIENTOS ALMACENADOS...............................65
-9-
LISTA DE FIGURAS
Pág.
FIGURA 1. DIAGRAMA DE CONTEXTO SISTEMA ACTUAL...........................................44
FIGURA 2. DIAGRAMA NIVEL 1 SISTEMA ACTUAL .......................................................45
FIGURA 3. DIAGRAMA DE FLUJO SISTEMA PROPUESTO ...........................................48
FIGURA 4. CAPAS DEL APLICATIVO WEB .....................................................................49
FIGURA 5. MODELO CLIENTE – SERVIDOR EN MV ......................................................50
FIGURA 6. CASOS DE USO: ADMINISTRADOR .............................................................52
FIGURA 7. CASOS DE USO: ANALISTA ..........................................................................53
FIGURA 8. CASOS DE USO: USUARIO ...........................................................................53
FIGURA 9. PROTOTIPO – WEB INICIO SESIÓN .............................................................56
FIGURA 10. PROTOTIPO – WEB CREAR SOLICITUD....................................................56
FIGURA 11. PROTOTIPO – WEB CONSULTAR SOLICITUD ..........................................56
FIGURA 12. PROTOTIPO – WEB DESCARGAR ARCHIVOS ..........................................57
FIGURA 13. DIAGRAMA DE CLASES...............................................................................57
FIGURA 14. DISEÑO CONCEPTUAL BD (ENTIDADES Y ATRIBUTO CLAVE) ..............58
FIGURA 15. DIAGRAMA DE LA BASE DE DATOS ..........................................................60
FIGURA 16. FLUJO DE TRABAJO APLICATIVO WEB.....................................................69
FIGURA 17. FINAL – WEB INICIO SESIÓN NO AUTORIZADO .......................................74
FIGURA 18. FINAL – WEB MENSAJE DE ALERTAS .......................................................74
FIGURA 19. FINAL – WEB CREAR SOLICITUD...............................................................75
FIGURA 20. FINAL – WEB CONSULTAR SOLICITUD .....................................................76
FIGURA 21. FINAL – WEB VER DETALLES DE SOLICITUD...........................................76
FIGURA 22. FINAL – WEB VER HISTORIAL DE SOLICITUDES .....................................77
FIGURA 23. FINAL – WEB DE DESCARGA DE ARCHIVOS ADJUNTOS .......................78
FIGURA 24. FINAL – WEB INTERFAZ DE DESCARGA...................................................78
FIGURA 25. FINAL – WEB DE REPORTES......................................................................79
FIGURA 26. FINAL – WEB ARCHIVOS ADJUNTOS ........................................................79
FIGURA 27. FINAL – WEB ÁREA......................................................................................80
FIGURA 28. FINAL – WEB ESTADO EVENTO .................................................................80
- 10 -
FIGURA 29. FINAL – WEB EVENTOS ..............................................................................81
FIGURA 30. FINAL – WEB HISTORIAL SOLICITUD ........................................................82
FIGURA 31. FINAL – WEB ROL ........................................................................................82
FIGURA 32. FINAL – WEB SOLICITUD ............................................................................83
FIGURA 33. FINAL – WEB TIPO ARCHIVO ADJUNTO....................................................83
FIGURA 34. FINAL – WEB USUARIO ...............................................................................84
FIGURA 35. FINAL – WEB WORKFLOW ..........................................................................84
FIGURA 36. FINAL – WEB AYUDA ...................................................................................85
FIGURA 37. MAPA DEL SITIO ADMINISTRADOR ...........................................................86
FIGURA 38. MAPA DEL SITIO ANALISTA ........................................................................87
FIGURA 39. MAPA DEL SITIO USUARIO .........................................................................87
- 11 -
LISTA DE ANEXOS
Pág.
ANEXO A. CARTA DE AUTORIZACIÓN DEL BANCO DE BOGOTÁ ...............................96
ANEXO B. FORMATO DE ENTREVISTA ..........................................................................98
ANEXO C. MANUAL TÉCNICO .......................................................................................100
- 12 -
INTRODUCCIÓN
Se podría definir un proceso como una serie de actividades, en las que varias
entidades (personas, máquinas, etc.) colaboran para conseguir un objetivo
concreto. Por ejemplo, un proceso típico en una empresa podría consistir en el
conjunto de actividades necesarias para responder a una solicitud de compra por
parte de un cliente (negociación de precios y fechas de envío, facturación, envío
de los bienes al cliente, etc.) El proceso puede ser visto también como una cadena
de actividades coherentes que resulta en la creación de valor (ya sea material o
inmaterial) para alguien.
Un proceso de negocio es un tipo especial de proceso que describe, desde un
punto de vista orientado al mercado, las actividades de una organización. El
principal objetivo de los procesos de negocio es satisfacer necesidades de los
clientes.
El modelado de procesos de negocio resulta útil en una gran variedad de
situaciones, que pueden ser clasificadas en tres grupos: descripción del proceso,
análisis del proceso e implementación del proceso. Actualmente se utilizan
diversas técnicas de modelado, como diagramas de actividad de UML y otros
lenguajes, fundamentalmente gráficos y formales.
Un concepto relacionado con el de proceso de negocio es el de workflow. Se
define workflow como la automatización de un proceso de negocio, total o parcial,
durante la cual se pasan documentos, información o tareas de un participante a
otro para realizar una acción, de acuerdo con un conjunto de reglas de
procedimiento. Estas reglas se establecen en la definición del proceso.
- 13 -
Esta automatización la suele llevar a cabo un sistema de gestión de workflow, que
es un sistema que define, crea y gestiona la ejecución de workflows mediante la
ejecución de software en una o más máquinas, siendo capaz de interpretar la
definición del proceso, interactuar con los participantes del workflow y cuando así
se requiera, ejecutar otras herramientas y aplicaciones.
Las técnicas de modelado de procesos de negocio son muy importantes en un
sistema de workflow, ya que permiten definir formalmente procesos, de tal forma
que puedan ser interpretados y ejecutados correctamente por el sistema de
gestión de workflow.
Además, una parte de los participantes en un sistema de workflow serán máquinas
(en general, aplicaciones), y el resto, humanos. Para facilitar la participación de
humanos en el sistema, éste debe proporcionar las interfaces de usuario
adecuadas.
- 14 -
1. PLANTEAMIENTO DEL PROBLEMA
1.1. ANTECEDENTES
En la década de los 80 las empresas aplicaron tecnologías de la información a la
automatización de los procesos administrativos y de gestión. Las grandes
preocupaciones de aquellos años eran el control de los costes operativos, la
mejora de la productividad y el logro de servicios más competitivos 1 .
En cambio, en el momento actual, el interés de muchas empresas, al menos de
las más innovadoras, se centra en el rediseño de los procesos de trabajo y de
información con el fin de mejorar la rentabilidad y hacerlos más eficaces. Para
lograr estos objetivos, muchas organizaciones empresariales están incorporando
mecanismos de workflow que enlazan los procesos de negocio con los sistemas
de información con el fin de conseguir:
•
Trabajar sin papeles.
•
Saber cuánto cuesta cada proceso de trabajo.
•
Reducir el tiempo empleado en cada una de las tareas.
•
Aprovechar el “conocimiento” de la organización.
Sin embargo, para que una organización implante con éxito un sistema de
workflow necesita cumplir unos requisitos básicos. En primer lugar debe contar
con una sólida infraestructura de ordenadores, redes, servidores, bases de datos y
correo electrónico, es decir, debe tener una madurez tecnológica.
1
Información extraída de la revista Pc World publicada en noviembre de 2003
- 15 -
En segundo lugar, sus responsables deben estar sensibilizados respecto al valor
de la información y familiarizados con la circulación de la información electrónica.
El tercer requisito está relacionado con la aceptación del sistema por parte de los
usuarios, que en muchas ocasiones ven en él más inconvenientes que ventajas al
relacionarlo con un controlador o un reestructurador de la plantilla de la empresa
más que con un guía.
Otro elemento importante a tener en cuenta es que, a diferencia de otras, el
workflow no es una herramienta informática que se entrega al departamento de
sistemas de información para que la aplique sin más. La implantación de workflow
debe considerarse más como un proyecto de gestión que como uno informático, lo
que supone un esfuerzo de análisis previo de la situación de la organización, de
manera que se estudie la circulación de los documentos, su naturaleza y
tratamiento, así como la asignación de normas y tareas y el orden de ejecución.
Por tanto, para que la herramienta de workflow pueda guiar y controlar en cada
uno de los procesos de trabajo y de información, es necesario que previamente se
haga el diseño de los mismos, y es aquí donde está una de las claves del éxito del
workflow, en el trabajo previo de análisis de la organización y de sus procesos, y
que en la mayoría de las ocasiones suele requerir consultoría.
Si bien es cierto que esta tecnología ha despertado gran interés entre las grandes
empresas, éstas deben ser conscientes de que su implantación supone un período
relativamente largo y complejo que requiere no sólo el convencimiento y apoyo de
la alta dirección, sino además la aceptación de ciertos cambios por parte de los
usuarios implicados.
- 16 -
1.2. DESCRIPCIÓN Y FORMULACIÓN DEL PROBLEMA
La Gerencia Centro de Información Financiera del Banco de Bogotá tiene la misión
de entregar información oportuna y de calidad a todos los usuarios internos que la
requieran, actualmente no existe una manera adecuada de administrar la gestión
que realiza el GCIF en el Banco. En el proceso de control y seguimiento se han
detectado alteraciones en las solicitudes, generando conflictos entre los usuarios y
el GCIF.
¿Cómo implementar una solución a nivel aplicativo que permita gestionar los
procesos de entrega de información realizada por el GCIF del Banco de Bogotá?
1.3. JUSTIFICACIÓN
Proporcionar al GCIF una solución que se ajuste a la organización a nivel de
infraestructura, implementación, mantenimiento y por supuesto satisfaciendo las
necesidades de la entidad, permitiendo a los usuarios internos realizar solicitudes
de información fácilmente, para obtener resultados en menor tiempo al que se esta
trabajando actualmente.
A continuación se describen los beneficios que ofrece el aplicativo:
• Herramienta desarrollada a la medida: Aplicación que se ajuste a las
necesidades y a la infraestructura tecnológica de la Entidad Banco de
Bogotá.
• Generación de consecutivos que permitan el control y seguimiento: Se busca
ofrecer controles para la realización de auditorias y garantizar el
- 17 -
correspondiente seguimiento por parte del Usuario o Administrador sobre las
solicitudes.
• Mejora en los tiempos de respuesta: Gracias a la obtención de consecutivos
y generación de alertas por parte del aplicativo se garantiza tiempos de
respuesta más cortos.
• Generación de informes y estadísticas de acuerdo a las necesidades del
GCIF: Con la información consolidada en una base de datos, la generación
de reportes personalizados es más fácil.
• Entorno amigable y moderno para el usuario: La interfaz gráfica desarrollada
con tecnología de punta, ofrece al usuario facilidad en la creación y
seguimiento de solicitudes de información.
• Sólida administración del GCIF: Información de calidad en una base de datos
robusta que se ajusta a la entidad, y una interfaz realizando la gestión de
GCIF.
1.4. OBJETIVOS DE LA INVESTIGACIÓN
1.4.1.
Objetivo General
Desarrollar un sistema de gestión de requerimientos de información para la
Gerencia del Centro de Información Financiera del Banco de Bogotá.
- 18 -
1.4.2.
Objetivos Específicos
Analizar el proceso actual de gestión de solicitudes para establecer sus
necesidades e identificar las falencias, con el fin de determinar los
requerimientos.
Diseñar la base de datos y la interfaz de usuario.
Implementar la base de datos y los formularios web en ambiente Cliente –
Servidor, para simular un escenario de trabajo acorde al real.
Realizar un esquema de pruebas basados en el escenario de trabajo,
planteando diferentes situaciones que se podrían presentar eventualmente en el
escenario real.
1.5. ALCANCES Y LIMITACIONES DEL PROYECTO
1.5.1.
Alcances
El Sistema Gestión de Requerimientos de Información para la Gerencia Centro
de Información Financiera ofrece una herramienta capaz de registrar y controlar
los requerimientos realizados por los usuarios, brindando a la Gerencia poder
de análisis para la toma de decisiones.
Se hará entrega al finalizar este proyecto de:
•
Un aplicativo para
la
administración, recepción y seguimiento de
solicitudes de información con el Manual del Usuario vinculado en
formato de videos.
- 19 -
•
1.5.2.
Manual Técnico.
Limitaciones
El Banco de Bogotá posee una infraestructura tecnológica basada en
arquitectura ASP.NET, igualmente la Gerencia Centro de Información
Financiera cuenta con un servidor propio con motor de base de datos de
Microsoft SQL Server 2000.
Por otra parte la decisión de implantación depende del Banco, toda vez que la
Gerencia de Sistemas debe realizar una serie de análisis e identificar como el
sistema afecta el entorno de trabajo actual.
- 20 -
2. MARCO DE REFERENCIA
2.1.
MARCO CONCEPTUAL
Es preciso determinar que se entiende por un concepto, para poder aplicarlo y
evitar confusiones a las que podrían llevar a otras interpretaciones teóricas. Este
apartado busca definir y, se espera, aclarar los conceptos elementales del
proyecto.
La búsqueda de la eficiencia viene acompañada de cambios y/o mejoras en la
tecnología que soporta los procesos de negocios. La implementación de
soluciones sin duda requiere de un esfuerzo importante para poner en
funcionamiento la aplicación métodos, medidas, ya que no solo se debe trabajar
en el flanco de hacer definiciones en el plano de procesos, tablas y organización;
sino que también, se debe interactuar con la organización.
Dentro de una organización todas las áreas tienen como función realizar
actividades afines para alcanzar un objetivo que busque el crecimiento de ella,
trabajando de forma sincronizada con las otras áreas, áreas
dinámicamente
relacionadas entre sí, como un sistema.
Hoy en día la información es el elemento más importante al interior de una
organización, ya que ésta es el conjunto de elementos (datos, códigos,
investigaciones, experiencias) que permiten la toma de decisiones sobre las
situaciones que se presentan en cualquier medio; a partir de establecer relaciones
entre los elementos y el problema o situación dada.
- 21 -
Durante el desarrollo de aplicaciones web que cumplan con el objetivo de la
compañía es común que aparezcan bugs o errores que hacen que el desarrollador
intervenga para erradicar dichos bugs.
Para un buen desarrollo hay que tener en cuenta diferentes modelos o
arquitecturas de software y analizar cada una de las capas que nos ofrecen estas
arquitecturas.
Una vez adoptado la arquitectura que mejor resultados nos pueda generar,
debemos seguir una metodología secuencial para así dar cumplimiento a todos los
objetivos propuestos, esta metodología debe estar involucrada en todos los
procesos que hacen parte de este sistema
El usuario es parte primordial dentro del proceso de desarrollo, sobre todo cuando
se diseña un sistema con procesos síncronos ya que estos dependen de un
acontecimiento externo, generalmente un usuario para así continuar con el
proceso.
2.2.
MARCO LEGAL O NORMATIVO
Un elemento crítico para el éxito y supervivencia de las organizaciones, es la
administración efectiva de la información y definición de nuevas alternativas que le
permitan mantenerse dentro del medio en constante cambio. Como punto de
apoyo básico a estos cambios, se encuentra el desarrollo de proyectos que genera
las nuevas aplicaciones necesarias para soportar el Plan Estratégico que definen
las organizaciones, los cuales requieren de una adecuada administración de los
recursos disponibles.
- 22 -
Es importante tener en cuenta la normatividad que tiene el Banco de Bogotá,
respecto al desarrollo de software (aplicaciones) y su respectiva entrega.
POLÍTICAS PARA EL DESARROLLO DE PROYECTOS EN EL BANCO DE
BOGOTÁ
• Para dar inicio al desarrollo de un proyecto, debe haber un requerimiento
escrito del área usuaria interesada, una evaluación del impacto del mismo
(alternativas de solución, recursos requeridos, tiempo requerido, impacto en
el plan de trabajo de la División).
• Todo proyecto debe tener un Líder Técnico, un Líder Usuario, un Gerente de
Proyecto y un equipo de trabajo.
• Todo proyecto debe contar con la siguiente documentación:
Etapa
Documentación
Requerimiento
Planificación
Objetivo
Alcance e impacto
Cronograma
Relación de interfaces
Definición de requerimientos
Requerimientos de controles funcionales
Recomendaciones sobre seguridades, perfiles y privilegios
Diseño conceptual o funcional del proyecto
Diseño
Diseño físico / lógico o diseño técnico detallado
Control de cambios (al diseño inicial)
Pruebas
Documentación
Plan de pruebas
Manuales técnicos del producto
Manuales de usuario del producto
- 23 -
• Las actividades de ingeniería de software posteriores a su instalación o
mantenimiento, deben preverse con anticipación, es decir, el desarrollo del
software debe facilitar su propio mantenimiento garantizando que no se
degrade como resultado de este proceso. Por lo tanto, el software construido
debe propender por:
•
Ser modular y de codificación simple.
•
Ser parametrizable.
•
Estar perfectamente documentado.
•
Tener registros de pruebas.
POLÍTICAS PARA ENTREGA DE APLICACIONES
OBJETIVOS
• Establecer un marco general de referencia metodológico que permita
identificar los requisitos para la realización de Cambios en las diferentes
plataformas que se administran.
• Ayudar a garantizar el correcto funcionamiento del sistema, mediante la
disminución de los errores de operación de la aplicación y la definición de
acciones a tomar en caso de mensajes de error.
• Facilitar el desarrollo de versiones de una aplicación.
• Permitir a la División de Sistemas y de Operaciones, tener una
documentación estándar.
- 24 -
• Facilitar la consulta de información relacionada con aplicaciones
desarrolladas.
• Ayudar a la capacitación de los funcionarios de la División y a los
usuarios del sistema.
NORMAS GENERALES
• Cualquier sistema realizado por la División de Sistemas y de
Operaciones,
Sistemas
Corporativos
o
contratado
su
desarrollo
externamente por el Banco de Bogotá, deberá estar soportado por los
manuales de usuario, operación, control y técnico y deberá cumplir con
los estándares definidos.
• El líder del Proyecto o líder técnico o funcional para el caso de
requerimientos, es el encargado de llevar el cambio, al Comité de
Cambios de la División de Sistemas y Operaciones, donde se autoriza la
fecha final para la realización del mismo.
• Para los paquetes adquiridos por el Banco y que tengan unos estándares
preestablecidos debe continuarse con los mismos, en caso contrario,
utilizar los mencionados en este capítulo.
• El Líder del proyecto, debe asegurar como parte de la planeación, que se
cuenta con los recursos necesarios para la realización exitosa del plan,
en lo que tiene que ver con recursos de hardware, software o espacio
adicional de almacenamiento que se deba conseguir si el que existe en
ambiente de Producción no es suficiente, tramitando las aprobaciones y
- 25 -
compras que se requieran por intermedio de la Gerencia de Investigación
y Desarrollo.
• Toda modificación realizada a un sistema deberá documentarse tanto en
los programas fuentes como en los manuales ya existentes y éstos
deberán ser enviados a las diferentes áreas usuarias.
• La Gerencia de Tecnología procede a realizar una revisión de los
cambios
enviados,
emite
sus
comentarios
y
recomendaciones
necesarias, que den lugar a mejoras. Si el cambio da lugar a
correcciones, no se debe continuar con el proceso de instalación.
• Cuando un proceso ejecutado en el área de Procesamiento tenga alguna
implicación en los Centros de Operaciones, las Gerencias de Desarrollo
deben generar un(os) instructivo(s) y enviarlo(s) a la Sección de Soporte
Técnico para coordinar su distribución.
• La entrega de nuevas aplicaciones y actualizaciones debe ir con Acta de
Entrega respectiva.
• Las actualizaciones de nuevas versiones, no deben efectuarse los días
lunes, después de festivo, fin de mes, quincena o fin de año, ya que la
oportunidad de la entrega de la información a las oficinas y clientes se
pueden ver afectadas por errores en el cambio de los programas
instalados.
• Buscando prestar un buen soporte en producción, la entrega de nuevas
aplicaciones debe integrar un plan de capacitación.
- 26 -
MANUALES Y PLANILLAS
Para ejecutar una aplicación en el ambiente de Producción deben entregarse
previamente los siguientes manuales y planillas (ó la actualización de los
mismos):
• Planillas de Operación: Dirigido a los funcionarios del centro de cómputo.
Deben generarse dos copias para el área de Procesamiento y Centro de
Cómputo.
• Manual de Control: Dirigido a los funcionarios encargados de realizar el
cuadre de las aplicaciones y verificar su correcto funcionamiento. Deben
generarse dos copias para el área de Procesamiento.
• Manual del Usuario: Dirigido al área usuaria de la aplicación.
• Manual Técnico: Dirigido a las Gerencias de Desarrollo y Tecnología.
Los manuales deben contener en parte inferior izquierda de la última línea la
fecha de realización o modificación según sea el caso, en formato: MES
(alfabético) Día/Año.
2.3.
MARCO TEÓRICO
Para el óptimo desarrollo de un aplicativo que solucione el problema que tiene la
Gerencia Centro de Información Financiera del Banco de Bogotá en el proceso de
gestión de requerimientos de información, debemos plantear una base teórica
fundamentada en la versatilidad que nos proporcionan las aplicaciones web en el
marco presentado por el mismo.
- 27 -
UML
El Lenguaje Unificado de Modelado preescribe un conjunto de notaciones y
diagramas estándar para modelar sistemas orientados a objetos, y describe la
semántica esencial de lo que estos diagramas y símbolos significan. Mientras
que ha habido muchas notaciones y métodos usados para el diseño orientado a
objetos, ahora los modeladores sólo tienen que aprender una única notación.
UML se puede usar para modelar distintos tipos de sistemas: sistemas de
software, sistemas de hardware, y organizaciones del mundo real. UML ofrece
nueve diagramas en los cuales modelar sistemas.
• Diagramas de Casos de Uso para modelar los procesos 'business'.
• Diagramas de Secuencia para modelar el paso de mensajes entre objetos.
• Diagramas de Colaboración para modelar interacciones entre objetos.
• Diagramas de Estado para modelar el comportamiento de los objetos en el
sistema.
• Diagramas de Actividad para modelar el comportamiento de los Casos de
Uso, objetos u operaciones.
• Diagramas de Clases para modelar la estructura estática de las clases en
el sistema.
• Diagramas de Objetos para modelar la estructura estática de los objetos
en el sistema.
- 28 -
• Diagramas de Componentes para modelar componentes.
• Diagramas de Implementación para modelar la distribución del sistema.
UML es una consolidación de muchas de las notaciones y conceptos más
usadas orientados a objetos. Empezó como una consolidación del trabajo de
Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las
metodologías orientadas a objetos más populares.
En 1996, el Object Management Group (OMG), un pilar estándar para la
comunidad del diseño orientado a objetos, publicó una petición con propósito de
un metamodelo orientado a objetos de semántica y notación estándares. UML,
en su versión 1.0, fue propuesto como una respuesta a esta petición en enero
de 1997. Hubo otras cinco propuestas rivales. Durante el transcurso de 1997,
los seis promotores de las propuestas, unieron su trabajo y presentaron al OMG
un documento revisado de UML, llamado UML versión 1.1. Este documento fue
aprobado por el OMG en Noviembre de 1997. El OMG llama a este documento
OMG UML versión 1.1.
Aplicaciones Web
Una
aplicación
web
es
una
interface
entre
un
formulario
diseñado
específicamente para cubrir con las necesidades de un negocio y su
información,
como
pueden
ser
sistemas
administrativos,
inventarios,
facturación, cuentas por cobrar, productos, etc. (la información puede ser de
dominio público o restringida a ciertas personas a través de un nombre de
usuario y contraseña) con el objetivo de que cualquier persona pueda
consultarla e interactuar con ella desde Internet.
- 29 -
En ingeniería de software una aplicación web es aquella que los usuarios usan
accediendo a un servidor web a través de internet o de una intranet. Las
aplicaciones web son populares debido a la practicidad del navegador web
como cliente ligero. La habilidad para actualizar y mantener aplicaciones web
sin distribuir e instalar software en miles de potenciales clientes es otra razón de
su popularidad.
En los primeros tiempos de la computación cliente - servidor, cada aplicación
tenía su propio programa cliente y su interfaz de usuario, estos tenían que ser
instalados separadamente en cada estación de trabajo de los usuarios. Una
mejora al servidor, como parte de la aplicación, requería típicamente una
mejora de los clientes instalados en cada una de las estaciones de trabajo,
añadiendo un costo de soporte técnico y disminuyendo la eficiencia del
personal.
En contraste, las aplicaciones web generan dinámicamente una serie de
páginas en un formato estándar, soportado por navegadores web comunes
como HTML (acrónimo inglés de HyperText Markup Language), lenguaje de
marcación diseñado para estructurar textos y presentarlos en forma de
hipertexto, que es el formato estándar de las páginas web o XHTML (acrónimo
inglés de eXtensible Hypertext Markup Language), es el lenguaje de marcado
pensado para sustituir a HTML como estándar para las páginas web. XHTML es
la versión XML de HTML, por lo que tiene, básicamente, las mismas
funcionalidades, pero cumple las especificaciones, más estrictas, de XML. Su
objetivo es avanzar en el proyecto del World Wide Web Consortium de lograr
una web semántica, donde la información, y la forma de presentarla estén
claramente separadas. Se utilizan lenguajes interpretados del lado del cliente,
tales como JavaScript, para añadir elementos dinámicos a la interfaz de
usuario. Generalmente cada página web individual es enviada al cliente como
- 30 -
un documento estático, pero la secuencia de páginas provee de una
experiencia interactiva.
Las aplicaciones web como ya se mencionó, vienen acompañadas de unos
beneficios entre los cuales se pueden mencionar 2 :
1. Compatibilidad multiplataforma: Las aplicaciones web tienen un camino
mucho más sencillo para la compatibilidad multiplataforma que las
aplicaciones de software descargables. Varias tecnologías incluyendo Java,
Flash, ASP y Ajax permiten un desarrollo efectivo de programas soportando
todos los sistemas operativos principales.
2. Actualización: Las aplicaciones basadas en web están siempre actualizadas
con el último lanzamiento sin requerir que el usuario tome acciones pro activas, y sin necesitar llamar la atención del usuario o interferir con sus
hábitos de trabajo con la esperanza de que va a iniciar nuevas descargas y
procedimientos de instalación (algunas veces imposible cuando usted está
trabajando dentro de grandes organizaciones).
3. Inmediatez de acceso: Las aplicaciones basadas en web no necesitan ser
descargadas, instaladas y configuradas. Usted accede a su cuenta online y
están listas para trabajar sin importar cuál es su configuración o su
hardware.
4. Facilidad de prueba: Finalmente no habrá más obstáculos para permitir
pruebas sencillas y efectivas de herramientas y aplicaciones antes de
cargar su tarjeta de crédito. Actualmente, especialmente cuando hablamos
de software costoso, hay todavía una gran cantidad de funcionalidades y
2
Información extraída de
www.informaticamilenium.com.mx/Paginas/espanol/desarrollo_sistemas_web.htm
- 31 -
pequeños detalles que no pueden ser totalmente probados descubiertos
antes de comprometer dinero en alguna compra total.
5. Menos requerimientos de memoria: Las aplicaciones basadas en web
tienen muchas más razonables demandas de memoria RAM de parte del
usuario final que los programas instalados localmente. Al residir y correr en
los servidores del proveedor, a esas aplicaciones basadas en web usa en
muchos casos la memoria de las computadoras que ellos corren, dejando
más espacio para correr múltiples aplicaciones del mismo tiempo sin incurrir
en frustrantes deterioros en el rendimiento.
6. Menos Bugs: Las aplicaciones basadas en web deberían ser menos
propensas a colgarse y crear problemas técnicos debido a software o
conflictos de hardware con otras aplicaciones existentes, protocolos o
software personal interno. Con aplicaciones basadas en web, todos utilizan
la misma versión, y todos los bugs pueden ser corregido tan pronto como
son descubiertos. Esta es la razón por la cual las aplicaciones basadas en
web deberían tener mucho menos bugs que el software de escritorio
descargable tradicional.
7. Precio: Las aplicaciones basadas en web no requieren la infraestructura de
distribución, soporte técnico y marketing requerido por el software
descargable tradicional. Esto permite que las aplicaciones online cuesten
una fracción de sus contrapartes descargables si no totalmente gratuitas,
mientras que ofrecen componentes adicionales y servicios premium como
una opción.
8. Los datos también van online: Por supuesto con el desplazamiento de las
aplicaciones locales a aquellas basadas en web también los datos que
creamos y accedemos van a necesitar experimentar profundos cambios.
- 32 -
9. Múltiples usuarios concurrentes: Las aplicaciones basadas en web pueden
realmente ser utilizada por múltiples usuarios al mismo tiempo. No hay más
necesidad de compartir pantallas o enviar instantáneas cuando múltiples
usuarios pueden ver e incluso editar el mismo documento de manera
conjunta. Las compañías de conferencia web y colaboración online están
involucradas algunas transformaciones claves y los usuarios necesitan
explorar que significa realmente trabajar efectivamente y co - editar
documentos juntos.
10. Los datos son más seguros: Si bien la ruptura de discos no va a
desaparecer, es probable que los usuarios escuchen mucho menos del
tema. A medida que las compañías se hagan cargo del almacenamiento de
los datos del usuario, granjas de almacenamiento de datos redundantes,
altamente fiables, serán la norma más que la excepción, y los usuarios van
a tener mucho menos riesgo de perder sus datos debido a una ruptura de
disco impredecible o a un virus de la computadora. Las compañías que
provee aplicaciones basadas en web van a brindar amplios servicios de
resguardo de datos ya sea como una parte integral del servicio básico o
como una opción paga. Usted puede imaginar que si una compañía
comercial pierde los datos de la gente será puesta de rodillas
(financieramente) en cuestión de días.
11. Desarrollar aplicaciones en el lenguaje que usted quiera: Una vez que las
aplicaciones han sido separadas de computadoras locales y sistemas
operativos específicos esa pueden también ser escritas en prácticamente
cualquier lenguaje de programación. Ya que las aplicaciones web son
esencialmente una colección de programas más que un simple programa,
ellas podrían ser escritas en cualquier lenguaje de programación que esté
por ahí. Mientras que para software escritorio usted está limitado a usar el
- 33 -
mismo lenguaje que el sistema operativo subyacente este no es el caso
cuando la aplicación de software es independiente del sistema operativo.
Microsoft .NET Frameworks
Win Forms es el espacio de nombre de .NET Framework destinado a la
programación de la IU del cliente de Windows. Comparte los mismos principios
de diseño que el paquete ASP+ IU, conocido como Web Forms, pero las clases
y las implementaciones son completamente diferentes. No existen clases que
se transformen por arte de magia entre la API de Microsoft Win32 y los
componentes Web. Sin embargo, como ocurre en todas las aplicaciones de
.NET Framework, la coherencia constituye una prioridad. El objetivo principal de
los desarrolladores de Win Forms es sentirse cómodos escribiendo código en
Web Forms y el de los desarrolladores de Web Forms, sentirse cómodos
escribiendo código en Win Forms. Por ejemplo, los dos espacios de nombre
tendrán
una
clase
Button
que
contendrá
texto,
un
evento
OnClick
predeterminado y las propiedades ForeColor, BackColor y Font.
AJAX Framework.Net
AJAX parece ser la palabra de moda en el mundo del desarrollo de aplicaciones
Web, AJAX no es una tecnología, sino la unión de varias tecnologías que juntas
pueden lograr cosas realmente impresionantes.
Hace un tiempo AJAX parece ser la palabra de moda en el “mundo” del
desarrollo de aplicaciones Web; de hecho muchos lo escuchan nombrar pero
pocos saben que es realmente y, menos aún, saben en donde buscar
información clara sobre que es esta nueva “maravilla” de la tecnología que
Jesse James Garret publicó en un artículo en Inglés excelente que vale la pena
traducir por completo.
- 34 -
Por qué es tan interesante AJAX? Porque en realidad AJAX no es una
tecnología, sino la unión de varias tecnologías que juntas pueden lograr cosas
realmente impresionantes como GoogleMaps, Gmail el Outlook Web Access o
algunas otras aplicaciones muy conocidas.
AJAX, en resumen, es el acrónimo para Asynchronous JavaScript + XML y el
concepto es: Cargar y renderizar una página, luego mantenerse en esa página
mientras scripts y rutinas van al servidor buscando, en background, los datos
que son usados para actualizar la página solo re-renderizando la página y
mostrando u ocultando porciones de la misma.
Microsoft Windows Workflow Foundation (WWF)
Es un framework extensible para desarrollar soluciones de workflow sobre la
plataforma Windows. Como parte del próximo Microsoft WinFX, Windows
Workflow Foundation provee una API y herramientas para el desarrollo y la
ejecución de aplicaciones basadas en workflow. Windows Workflow Foundation
provee un único modelo unificado para crear soluciones de punta a punta que
abarcan categorías de aplicaciones, incluyendo workflows tanto humanos como
de sistemas.
Un workflow es un modelo de proceso humano o de sistema que es definido
como un mapa de actividades. Una actividad es un paso en un workflow y es la
unidad de ejecución. El mapa de actividades expresa reglas, acciones, estados
y sus relaciones. Diseñadas las secuencias de actividades, un workflow de
Windows Workflow Foundation es, entonces, compilado en un assembly .NET,
y es ejecutado sobre el runtime del workflow y el CLR (Common Language
Runtime).
- 35 -
Esta tecnología de WWF complementa al Framework .NET con un grupo de
componentes basados en workflows que brindan a los desarrolladores la
habilidad de definirlos, compilarlos, instanciarlos, depurarlos y rastrearlos.
Esta tecnología será parte de WinFX junto con Windows Presentation
Foundation (Avalon) y Windows Communication Foundation (Indigo).
Usando Windows Workflow Foundation (WWF), los desarrolladores pueden
incorporar conceptos tales como scheduling, coordinación de tareas y
escalabilidad en sus aplicaciones existentes sin costo alguno. WWF provee la
plataforma base donde se pueden desarrollar aplicaciones con muchos
procesos.
Dentro de Microsoft Visual Studio 2005, y luego de instalar el runtime de WinFX
y el pack de WWF, se encontrarán algunas capacidades muy interesantes, tales
como el diseñador visual, Visual Studio Workflow Templates y depurador visual,
lo cual ayuda a desarrollar aplicaciones ricas en workflows. Estos workflows se
desarrollan usando XML y un archivo code-behind sólo en C# o VB.NET. Una
librería workflow, cuando se compila, requiere una aplicación que la contenga
(aplicación Host) para ejecutarse.
Las aplicaciones Host pueden ser de consola (exe), Servicios Windows,
módulos http o aplicaciones de servidor, como SharePoint Services. Otros
productos como Microsoft BizTalk Server planean usar la plataforma WWF en
futuros lanzamientos.
- 36 -
Estructura
Aunque
muchas
variaciones
son
posibles,
una
aplicación
web
está
comúnmente estructurada como una aplicación de tres capas 3 . En su forma
más común, el navegador web es la primera capa, un motor usando alguna
tecnología web dinámica (ejemplo: CGI, PHP, Java Servlets o ASP) es la capa
de en medio, y una base de datos como última capa. El navegador web manda
peticiones a la capa media, que la entrega valiéndose de consultas y
actualizaciones a la base de datos generando una interfaz de usuario.
Al presentar cada uno de los diferentes elementos mencionados anteriormente
y basándonos que hoy en día la gran mayoría de los aplicativos esta dirigido al
manejo web podemos encontrar que se realiza un diseño de tres capas.
•
Capa de datos
•
Capa de negocio
•
Capa de presentación
Al conectarse al aplicativo se está utilizando un diseño de tres capaz,
•
Al enviar o llenar un formulario de solicitud (Presentación)
•
Verificación de la información y manejo de la misma por parte del aplicativo
(Negocio)
•
Almacenamiento de la información enviada (Datos)
3
Para obtener más información acerca de la estructura web aplicada al proyecto de solicitudes
consultar: http://msdn2.microsoft.com/en-us/library/ms978496.aspx
- 37 -
CAPA DE DATOS
La capa de datos esta compuesta por los siguientes elementos:
•
Bases de datos
•
Tablas
•
Procedimientos almacenados
•
Componentes de datos
Se utilizaron las siguientes tecnologías Microsoft:
•
SQL 2000
•
ADO .NET
•
Componentes VISUAL VB , C#
•
XML
•
Procedimientos almacenados
•
Framework 2.0
•
Windows Workflow Foundation
CAPA DE NEGOCIOS
Compuesta por los siguientes elementos que permiten establecer que se va a
hacer con la información, y estos son:
•
Reglas del negocio
•
Validaciones
•
Flujos y procesos
•
Cálculos
- 38 -
Se utilizaron las siguientes tecnologías Microsoft para trabajarlas:
•
Lenguajes de componentes VB y c#
•
Componentes locales
•
Componentes Web
•
Comunicación entre componentes, a través de XML
•
Framework 2.0
•
•
Webservices
Mediante los Webservices se logró la publicación de las reglas de negocio de
nuestro aplicativo en un servidor web y es la mejor manera de comunicación
entre componentes.
CAPA DE PRESENTACION
Es la forma como se presenta el aplicativo al usuario o la interfaz de usuario,
básicamente es la manera de garantizar que el usuario tenga acceso al
aplicativo y a la información, se considera básicamente en tres puntos.
•
Formularios
•
Informes
•
Respuestas al usuario
Se utilizaron las siguientes tecnologías Microsoft para la realización de esta
capa:
•
ASP .NET
•
ASP
- 39 -
•
XML, XSL
•
Framework 2.0
•
- 40 -
3. METODOLOGÍA
3.1. HIPÓTESIS
El Sistema de Gestión de Requerimientos de Información para la Gerencia Centro
de Información Financiera del Banco de Bogotá, es una aplicación que coadyuva
en la optimización de los procesos realizados al interior del GCIF proporcionando
menor tiempo de respuesta, un control de la información generada y un
seguimiento al desempeño del centro.
3.2. VARIABLES
3.2.1.
Variables Independientes
• El número de usuarios en el Sistema.
• Arquitectura del Sistema.
3.2.2.
Variables Dependientes
• Porcentaje de satisfacción de los usuarios.
• Reducción de tiempo en el desarrollo de los procesos del GCIF.
- 41 -
4. DESARROLLO INGENIERIL
4.1. Análisis
El tipo de información que suministra GCIF se puede referir a productos bancarios,
clientes, cifras presupuestales, cifras estadísticas, transacciones, etc, ya sea por
total Banco, unidad de negocio u oficina ó centros de Dirección General (Gerencia
Contabilidad, Gerencia de Mercadeo, Gerencia Banca Corporativa, etc).
GCIF se divide en tres secciones las cuales se denominan Sección Administrativa,
Sección de Producción y Sección de Desarrollo, esta última es la encargada de
gestionar las solicitudes de información que se realizan diariamente por los
usuarios internos del Banco.
4.1.1.
Análisis Sistema Actual
A continuación se describe el proceso actual establecido en GCIF para realizar
la gestión de solicitudes de información:
El usuario remite un correo electrónico al Jefe de la Sección de Desarrollo,
donde manifiesta el tipo de información y la estructura en la cual la requiere. Ej:
El analista x de la Gerencia de Mercadeo solicita información de las cuentas de
ahorros aperturadas en la Oficina Unicentro durante el mes de enero de 2007.
Se requiere fecha de apertura, tipo de identificación, identificación, nombre del
cliente y saldo inicial.
- 42 -
El Jefe de la Sección de Desarrollo radica la solicitud en un archivo de Microsoft
Excel el cual cumple la función de Base de Datos almacenando información
como la fecha de la solicitud, nombre de quien solicita, área a la que pertenece,
fecha de respuesta y a la vez se le asigna un consecutivo. Igualmente el Jefe
analiza dicha solicitud y determina si esta le atañe a GCIF.
Si la solicitud le corresponde a GCIF, el Jefe reenvía el correo electrónico del
usuario a uno de los analistas, asignándoselo para que éste se haga
responsable de suministrar información de calidad en los tiempos requeridos
por el usuario.
Si la solicitud no le corresponde a GCIF, el Jefe responde el correo electrónico
al usuario indicándole las causas por las cuales no se proporciona información.
Los analistas deben extraer la información de los aplicativos del Banco,
basándose en los parámetros requeridos por el usuario, ellos no están
autorizados para enviar más ó menos de lo que el usuario esta solicitando.
Los analistas generan la información en archivos planos o en archivos de
Microsoft Excel, dependiendo del tamaño de la misma, adjuntando al correo
electrónico y reenviando al usuario interesado con copia al Jefe de la Sección
de Desarrollo.
Cabe señalar que no siempre se remite la información completa ya sea por la
complejidad del proceso que se debe realizar por el tiempo que dispone el
analista, entonces se procede a remitir al usuario parciales de la información.
El Jefe de la Sección de Desarrollo al recibir el correo electrónico procede a dar
por terminada la solicitud y de acuerdo al consecutivo dado inicialmente ubica el
- 43 -
requerimiento en el control que maneja en Microsoft Excel y lo cierra colocando
una “bandera” en el registro correspondiente.
Semanalmente el Jefe de la Sección de Desarrollo realiza filtros en el archivo
control de Microsoft Excel, para establecer la gestión que se desarrolló durante
la semana y presentar las estadísticas los días viernes al gerente de GCFI,
donde evalúan las falencias que se presentaron durante la semana con el fin de
encontrar soluciones y posteriormente ser mas eficaces.
Figura 1. Diagrama de contexto sistema actual
Elaborado en Microsoft Visio 2003
- 44 -
Figura 2. Diagrama nivel 1 sistema actual
- 45 -
4.1.2.
Análisis Solución Propuesta
A continuación se describe el proceso propuesto para realizar la gestión de
solicitudes de información:
El usuario al requerir información financiera deberá entrar a la intranet del
Banco y hacer clic sobre el link que lo llevará a la aplicación. Esta no le
solicitará el nombre de usuario y contraseña toda vez que esta información se
extrae de Active Directory al momento de entrar a intranet.
El usuario al realizar una solicitud debe diligenciar un Text Box explicando lo
que necesita y colocar una bandera la cual indica la prioridad que se le debe
dar a dicha solicitud.
La aplicación al recibir un nuevo registro (una solicitud de información), remite
automáticamente un correo electrónico al Administrador en el cual se detalla la
fecha de la solicitud, nombre del usuario que requiere información (Active
Directory), nombre del área a la que pertenece el usuario (Active Directory) y
prioridad, permitiendo al Administrador analizar y determinar si esta le atañe al
GCIF.
Si la solicitud le corresponde a GCIF, el Administrador podrá asignársela a uno
de sus Analistas y agregarle una descripción si este lo cree necesario.
Si la solicitud no le corresponde a GCIF, el Administrador podrá responder al
usuario indicándole las causas por las cuales no se proporciona información.
La aplicación remitirá un correo electrónico al Analista que el Administrador
haya seleccionado, donde se indica los detalles anteriormente mencionados
más la descripción y prioridad dadas por el Administrador.
- 46 -
El Analista al recibir el correo electrónico extraerá la información solicitada
accesando a las aplicaciones del Banco, basándose en los parámetros
requeridos por el usuario generará la información en archivos planos o en
archivos de Microsoft Excel, dependiendo del tamaño de la misma.
En el correo electrónico remitido a los Analistas se encuentra un link, el cual al
hacer clic abrirá un formulario web para que el Analista adjunte los archivos que
contienen la información requerida y determine si la solicitud pasa de un estado
Pendiente a un estado Terminado ó Parcial , posteriormente la aplicación
enviará automáticamente al usuario un correo electrónico informando que su
solicitud ha sido tramitada y la ubicación de los archivos generados, igualmente
enviará copia al Administrador para que éste quede enterado del estado de la
solicitud.
El Administrador podrá generar los siguientes reportes, para establecer la
gestión que se desarrolló durante la semana y presentarlos de forma rápida y
apropiada al Gerente de GCIF:
• Informe pendientes, parciales y terminados entre un rango de fechas.
• Informe de solicitudes radicadas por áreas del Banco.
• Informe que suministre la cantidad de días que se utilizaron para responder
cada solicitud entre un rango de fechas.
- 47 -
Figura 3. Diagrama de flujo sistema propuesto
Usuario
Diagrama de Flujo Sistema Propuesto
ESTADO
INICIAL
SOLICITUD
CREAR SOLICITUD
Administrador
REASIGNAR
SOLICITUD
ASIGNAR/
RECHAZAR
CASO 1
CASO 2
ESTADO
INICIAL
ASIGNAR
ASIGNAR
SOLICITUD
ASIGNAR
SOLICITUD
CASO 3
SOLICITUD
ASIGNADA/
REASIGNADA
CERRAR
SOLICITUD
RECHAZAR
FIN
Analista
CASO 1: RECHAZAR ASIGNACION
ESTADO
INICIAL
ACTUALIZAR
SOLICITUD
SOLICITUD
COMPLETAR
SOLICITUD
CASO 2
CASO 3
- 48 -
Figura 4. Capas del Aplicativo Web
Extraído de www.MSDN2.Microsoft.com
El aplicativo de Gestión de Solicitudes esta diseñado bajo tres capas:
Capa de Datos: Esta estructurada en SQL Server 2000, la cual se conecta con
los formularios Web a través de Datasets permitiendo consultar, agregar y
modificar información.
Capa de Procesos: Esta estructurada en Windows Workflow Foundation,
permitiendo realizar procesos de manera secuencial, es decir, requiriendo la
intervención del usuario para pasar de un estado a otro.
- 49 -
Capa de Presentación: Esta desarrollada en Visual Studio 2005, suministrando
diferentes herramientas para el desarrollo del aplicativo, igualmente mejorando
la web con efectos visuales los cuales se obtienen con AJAX 1.0
Figura 5. Modelo Cliente – Servidor en MV
La solución propuesta se basa en un modelo Cliente – Servidor el cual es una
relación entre procesos corriendo en máquinas separadas, así:
Presentación Distribuida:
• Se distribuye la interfaz entre el cliente y la plataforma servidora.
• La aplicación y los datos están ambos en el servidor.
• El PC del usuario se aprovecha solo para mejorar la interfaz gráfica.
- 50 -
Presentación Remota:
• La interfaz para el usuario esta completamente en el cliente.
• La aplicación y los datos están en el servidor.
Lógica Distribuida:
• La interfaz esta en el cliente.
• La base de datos esta en el servidor.
• La lógica de la aplicación esta distribuida entre el cliente y el servidor.
Administración de Datos Remota:
• En el cliente residen tanto la interfaz como los procesos de la aplicación.
• Las bases de datos están en el servidor.
• Es lo que comúnmente imaginamos como aplicación cliente servidor
Base de Datos Distribuida:
• La interfaz, los procesos de la aplicación y parte de los datos de la base de
datos están en cliente.
• El resto de los datos están en el servidor.
- 51 -
La solución propuesta consta de tres actores (Administrador, Analista y Usuario)
los cuales se describen a continuación por medio de casos de uso
representados en UML Versión 1.0:
Figura 6. Casos de Uso: Administrador
- 52 -
Figura 7. Casos de Uso: Analista
Figura 8. Casos de Uso: Usuario
- 53 -
4.1.3.
Especificación de requerimientos
Requerimientos funcionales del software:
El sistema debe permitir al Usuario interno ingresar,
consultar y cancelar
solicitudes.
El sistema debe permitir al Administrador asignar, consultar, cerrar, reabrir,
reasignar y rechazar solicitudes.
El sistema debe permitir a los Analistas consultar, actualizar, terminar y
rechazar solicitudes.
El sistema debe permitir adjuntar la información generada en archivos planos.
El sistema debe permitir la generación de informes.
Detalle de requerimientos:
Se requiere desarrollar formas para que el Usuario pueda ingresar, consultar y
cancelar solicitudes de información.
Se requiere desarrollar formas para que el Administrador pueda asignar,
consultar, cerrar, reabrir, reasignar y rechazar solicitudes de información.
Se requiere desarrollar formas para que los Analistas puedan consultar,
actualizar, terminar y rechazar solicitudes de información.
Se requiere desarrollar una forma para que los Analistas adjunten archivos
planos.
- 54 -
Se requiere de los siguientes reportes:
• Informe para el Administrador de pendientes, parciales y terminados entre un
rango de fechas.
• Informe para el Administrador de solicitudes radicadas por áreas del Banco.
• Informe para Analistas de solicitudes pendientes.
4.2. Diseño
Para desarrollar la aplicación de solicitudes se realizó una entrevista a diferentes
usuarios de GCIF, donde dieron a conocer diferentes puntos de vista acerca de la
gestión que esta Gerencia tiene como misión (Ver Anexo B).
Inicialmente para el desarrollo del aplicativo se generó un prototipo con las formas
más importantes las cuales como mínimo, la versión final debería contener.
A continuación se presentan los diferentes formularios que componen el aplicativo
en su versión prototipo:
- 55 -
Figura 9. Prototipo – Web inicio sesión
Al
iniciar
muestra
el
una
aplicativo
pantalla
de
acceso para que el usuario
ingrese
su
usuario
nombre
y
de
respectiva
contraseña.
Figura 10. Prototipo – Web crear solicitud
Formulario
de
Usuario.
Permite al usuario realizar
las solicitudes de información
seleccionando el nivel de
importancia,
para
posteriormente
que
GCIF
gestione.
Figura 11. Prototipo – Web consultar solicitud
Formulario
Analista
de
y
Usuario,
Administrador.
Permite realizar consultas de
las solicitudes de acuerdo al
estado
Cancelada,
etc).
- 56 -
(Pendiente,
Reasignada,
Figura 12. Prototipo – Web descargar archivos
Formulario
Permite
de
Usuario.
descargar
los
archivos que GCIF genera
como parte de la solución a
la solicitud de información.
4.2.1.
Diagrama de Clases
Figura 13. Diagrama de Clases
Elaborado en Microsoft Visual Studio 2005
- 57 -
4.2.2.
Diseño Conceptual de la Base de Datos
Figura 14. Diseño conceptual BD (Entidades y Atributo Clave)
Nombre
IdTipoArchivo
ArchivosAdjuntos
IdRol
Número
Username
Identificación
Puede poseer
IdEstado
E-mail
Descripción
Rol
Pertenece
Usuario
Procesa
Id
Solicitud
Fecha Inicio
IdSolicitud
Id
Pertenece
Posee
Historial
IdEstado
Nombre
Id
Nombre
Area
IdUsuario
Id
Estado
Fecha Cambio
Estado
Estado
Nombre
Puede poseer
Id
Id
Eventos
Existe
EstadoEvento
En la creación del modelo entidad relación, se debe determinar cuales son las
entidades y cuales los atributos, así mismo, la relación entre cada una de las
diferentes entidades. Esta tarea prácticamente determina como es el diseño de
la base de datos. El esquema conceptual requiere entonces el uso que de cada
una de las entidades se realice dentro de la organización. Esto nos lleva a
determinar cuales son los datos necesarios en la base de datos y así mismo
- 58 -
nos comienza a ayudar a identificar la determinar la dependencia funcional.
Para conocer este elemento es necesario conocer a fondo y a detalle cada uno
de los pasos que se utilizan para el manejo y el acceso a la información es por
eso que se afirma que la dependencia funcional esta es dada por las
restricciones de la realidad.
Por eso al analizar varios casos del esquema conceptual se encuentra que:
• El usuario en diferentes etapas y al colocar una solicitud el aplicativo o un
usuario le puede informar del estado, de los avances, de la culminación, de la
aceptación o rechazo de una solicitud.
• Un administrador puede recibir esta solicitud y asignarla, cancelarla y
comentarla.
• Un analista puede aceptar o no la solicitud, procesarla, informar los avances.
• Y nuevamente el administrador o el usuario pueden determinar el estado de
la misma solicitud.
Analizando detalladamente se encuentra que la dependencia funcional dentro
de cada uno de los actores de la base de datos, exige que exista una
transitividad, ya que encontramos que la creación de entidades débiles en esta
base de datos en algunos momentos por el mismo diseño de la base de datos y
por la tecnología de WWF que se está utilizando es bastante complejo, para
lograr mantener la instancia y la independencia de cada una de ellas.
Es importante aclarar que las dependencias funcionales nos pueden llevar a
otras realidades que no estaban dentro del diseño inicial pero que pueden
afectar o no el comportamiento de la base de datos y pueden generar entidades
débiles o entidades fuertes.
- 59 -
4.2.3.
Diseño Físico de la Base de Datos
Figura 15. Diagrama de la Base de Datos
Elaborado en Microsoft SQL Server 2000
En el desarrollo de la base de datos se tomaron en cuenta diferentes conceptos
que son los que permiten que este diseño sea el ideal para el funcionamiento
del aplicativo.
Partiendo inicialmente del concepto del workflow en el cual cada una de las
solicitudes que se realicen en este aplicativo son tratadas como una instancia
independiente y que la información que este allí almacenada, gracias a la
- 60 -
serialización y deserialización de la información nos va a permitir un ahorro en
almacenamiento.
Así
mismo
encontramos
como
basado
en
la
dependencia
funcional
encontramos que el historial del trabajo depende de la instancia de la solicitud
que se quiera analizar y no de los tipos de solicitud o los estados que pueda
llegar a tener una solicitud.
La tabla workflow es aquella sobre la que básicamente funciona el GCIF, ya que
en esta se almacena cada una de las solicitudes dentro de la instancia y nos va
a garantizar que la información va a estar completa para consulta, acceder,
trabajar o cerrar en cualquier momento sin importar cuanto tiempo estuvo
inactiva una solicitud.
En el campo de la seguridad ningún usuario requiere de roles dentro de la base
de datos, ya que el aplicativo utiliza El aplicativo Web accede a la base de datos
por medio de un usuario denominado Solicitudesuser el cual posee permisos de
propietario de la base de datos (Owner), es decir, los usuarios al ingresar al
aplicativo ingresan con la seguridad de Windows pero el aplicativo internamente
accede a la base de datos, lo cual ofrece un ciento por ciento de
confidencialidad e integridad a las tablas, toda vez que los usuarios no accedan
físicamente a la Base de Datos a realizar operación alguna.
- 61 -
4.2.4.
Diccionario de la Base de Datos
Tabla 1. Diccionario de la base de datos
No.
Nombre de la Tabla
Tipo de
Llave
PK
1
Area
PK
2
Eventos
PK
3
Rol
PK
4
5
Estado
EstadoEvento
9
11
Varchar
50
Descripcion
Varchar
100
Id
Int
4
Nombre
Varchar
50
Descripcion
Varchar
100
Id
Int
4
Nombre
Varchar
50
Descripcion
Varchar
100
Id
Int
50
PK
Id
Int
FK
IdEstado
Int
4
FK
IdEvento
Int
4
IdTipoUsuarioPermitido
Int
4
Id
Int
4
Nombre
Varchar
50
Descripcion
Varchar
100
Id
Int
4
FK
IdRol
Int
4
Workflow
IdArea
Int
4
UserName
Varchar
50
Password
Varchar
50
dpto
Varchar
50
50
Email
Varchar
RecibeNotificacionesDe
Bit
1
EsClienteWindows
Bit
1
Id
Int
4
Guid
Nvarchar
50
WorkflowSerializado
Image
16
1
EstaBloqueado
Bit
PK
Id
Int
4
FK
IdWorkflow
Int
4
FK
IdUsuarioAutor
Int
4
FK
IdUsuarioAsignado
Int
4
FK
IdEstado
Int
4
Descripcion Solicitud
Text
16
ContieneArchivosAdjuntos
Bit
1
Solicitud
ArcivosAdjuntos
Observaciones
Aquí se almacena la informacion referente a las areas de
GCIF
Guarda los eventos o acciones que pueden realizar los
usuarios (Crear, Cancelar, Asignar, Rechazar y Aprobar
Solicitud).
♦
Aquí se almacena la informacion referente a los roles
(Administrador, Analista,Usuario) involucrados en el proceso
de solicitudes del Banco de Bogota
♦
Almacena los diferentes estado en los que puede estar una
solicitud
4
PK
Usuario
Nulo?
4
100
TipoArchivoAdjunto
HistoriaSolicitud
Nombre
Varchar
PK
10
4
Varchar
PK
8
Tamaño
Descripcion
FK
7
Tipo de Datos
Int
Nombre
PK
6
Nombre del Campo
Id
FechaInicio
DateTime
8
DiasVencimiento
Int
4
PosiblesEstadosSiguientes
Varchar
255
PosiblesEventosDisponibles
Varchar
255
Id
Int
4
IdSolicitud
Int
4
IdTipoArchivoAdjunto
Int
4
ArchivoAdjunto
Image
16
50
NombreArchivo
Varchar
PK
Id
Int
4
FK
IdSolicitud
Int
4
FK
IdEstado
Int
4
FK
IdUsuario
Int
4
FechaCambioEstado
DateTime
8
- 62 -
Guarda la asignación de los eventos que cada usuario puede
realizar dentro de la aplicación (Crear, Cancelar, Asignar,
Rechazar y Aprobar Solicitud).
Almacena informacion referente al tipo del archivo adjunto
♦
♦
♦
En esta tabla se almacena la informacion mas relevante de
los Usuarios que hacen parte del proceso de solicitudes,
dichos usuarios no necesariamente deben existir en el
Directorio Activo, toda vez que se cuenta con autenticación
mixta (SQL y Windows).
Es la tabla encargada de gestionar las solicitudes por medio
de Id's automáticos que esta asigna
♦
♦
En esta tabla se realiza el almacenamiento de la información
correspondiente al proceso de cada solicutud.
♦
♦
Aquí se almacena la informacion referente al Archivo adjunto
♦
♦
Aquí se encuentra el consolidado de las solicitudes realizadas
al GCIF
4.2.5.
Diccionario de Relaciones de la Base de Datos
Tabla 2. Diccionario de relaciones de la Base de Datos
Claves Principales (PK)
No.
Tabla
Campo
1
Area
Id
1
---
2
Eventos
Id
1
---
3
Estado
Id
1
---
4
Rol
Id
1
---
5
TipoArchivoAdjunto
Id
1
---
6
Workflow
Id
1
---
7
Usuario
Id
1
---
8
Estado
Id
1
---
9
Solicitud
Id
1
---
10
Solicitud
Id
1
---
4.2.6.
Claves Secundarias (FK)
TIPO DE
RELACION
∞
∞
∞
∞
∞
∞
∞
∞
∞
∞
Tabla
Usuario
Campo
IdArea
EstadoEvento
IdEvento
EstadoEvento
IdEstado
Usuario
IdRol
ArchivosAdjuntos
IdTipoArchivoAdjunto
Solicitud
IdWorkflow
Solicitud
IdUsuarioAutor
Solicitud
IdEstado
ArchivosAdjuntos
IdSolicitud
HistorialSolicitud
IdSolicitud
Tablas Estructurales del WorkFlow
Tabla 3. Tabla Estructural de Estado
No
1
Estado
Descripción
Asignada
Sucede al estar asignada
2
Cerrada
Estado Final de la solicitud
3
Creada
Sucede al crear una solicitud
4
En Curso
Sucede al estar en proceso de solución
5
Pendiente Asignacion
Sucede al esperar asignacion
6
Pendiente Cancelacion
Sucede al esperar cancelación
7
Pendiente Reasignacion
Sucede al esperar reasignacion
8
Solicitud Cancelada
Sucede al aprobar la cancelación de la solicitud
9
Solicitud Completada
Sucede al completar la solicitud
Tabla 4. Tabla Estructural de Rol
No
Rol
Descripción
1
Administrador
Usuario administrador de la aplicación
2
Analista
Usuario administrador de la aplicación
3
Usuario
Usuario que crea la solicitud
- 63 -
Tabla 5. Tabla Estructural de EstadoEvento
No
Estado Evento
Descripción
1
Creada
Crear Solicitud Usuario
2
Estado Raiz
Cancelar Solicitud Usuario
3
Estado Raiz
Cancelar Solicitud Administrador
4
Estado Raiz
Cancelar Solicitud Analista
5
Pendiente Asignacion
Asignar Solicitud Administrador
6
Aprobar Cancelacion Administrador
7
Rechazar Cancelacion Administrador
8
Pendiente Reasignacion
Reasignar Solicitud Administrador
Asignacion Analista
9
Asignada Rechazar
10
Asignada Aceptar
Asignacion Analista
11
En Curso
Actualizar Analista
12
En Curso
Completar Analista
13
Solicitud Completada
Cerrar Solicitud Administrador
14
Solicitud Cancelada
Cerrar Solicitud Administrador
Tabla 6. Tabla Estructural de Evento
No
1
Eventos
Aceptar Asignacion
Descripción
Ocurre al aceptar la asignación de una solicitud
2
Actualizar
Ocurre al actualizar el estado de una solicitud
3
Aprobar Cancelacion
Evento para aprobar la cancelación una solicitud
4
Asignar Solicitud
Evento para asignar una solicitud
5
Cancelar Solicitud
Ocurre al aceptar la cancelación de una solicitud
6
Cerrar Solicitud
Ocurre al cerrar una solicitud
7
Completar
Ocurre al completar una solicitud
8
Crear Solicitud
Evento para crear una solicitud
Evento para reasignar una solicitud
9
Reasignar Solicitud
10
Rechazar Asignacion
Ocurre al rechazar la asignación de una solicitud
11
Rechazar Cancelacion
Ocurre cuando se rechaza una cancelación
Tabla 7. Tabla Estructural de TipoArchivoAdjunto
No
Rol
Descripción
1
Al Actualizar
Ocurre cuando se adjunta un archivo en la actualización de la solicitud
2
Al Cerrar
Ocurre cuando se adjunta un archivo en la finalización de la solicitud
3
Al Crear
Ocurre cuando se adjunta un archivo en la creación de la solicitud
- 64 -
4.2.7.
Diccionario de Procedimientos Almacenados
Para optimizar la aplicación de solicitudes los eventos que esta realiza a la base
de datos (crear, modificar, eliminar, consultar, etc), no se incorporaron dentro
del código de la aplicación sino que se explotó al máximo las funcionalidades de
los Procedimientos Almacenados que posee SQL Server, de esta manera se
mejora el rendimiento y se da una mejor administración en los recursos del
sistema.
Tabla 8. Diccionario de procedimientos almacenados
No.
1
Nombre del Procedimiento Almacenado
Observaciones
3
ArchivosAdjuntos_Get_List
Elimina un registro en la tabla de ArchivosAdjuntos
Busca registros en la tabla ArchivosAdjuntos partiendo de parámetros de
nulidad
Obtiene todos los registros de la tabla ArchivosAdjuntos
4
ArchivosAdjuntos_GetById
Seleccionar los registros de la tabla ArchivosAdjuntos a través del Id
2
5
6
7
ArchivosAdjuntos_delete
ArchivosAdjuntos_Find
Seleccionar los registros de la tabla ArchivosAdjuntos a través de la llave
foranea IdSolicitud
ArchivosAdjuntos_GetByIdTipoArchivoAdju Seleccionar los registros de la tabla ArchivosAdjuntos a través de la llave
nto
foranea IdTipoArchivoAdjunto
ArchivosAdjuntos_GetByIdSolicitud
ArchivosAdjuntos_GetPaged
Obtiene los registros de la tabla ArchivosAdjuntos haciendo un idexado y
verificando los parámetros que existan en el procedimiento
8
ArchivosAdjuntos_Insert
Inserta un registro en la tabla de ArchivosAdjuntos
9
ArchivosAdjuntos_Update
Actualiza un registro en la tabla de ArchivosAdjuntos
10
Area_Delete
Elimina un registro en la tabla de Area
11
Area_Find
Busca registros en la tabla Area partiendo de parámetros de nulidad
12
Area_Get_List
Obtiene todos los registros de la tabla Area
13
Area_GetById
Seleccionar los registros de la tabla de Area a través del Id
Seleccionar los registros de la tabla de Area a través del Nombre
Obtiene los registros de la tabla Area haciendo un idexado y verificando
los parámetros que existan en el procedimiento
Inserta un registro en la tabla de Area
14
Area_GetByNombre
15
Area_GetPaged
16
Area_Insert
17
Area_Update
Actualiza un registro en la tabla de Area
18
Estado_Delete
Elimina un registro en la tabla de Estado
19
Estado_Find
Busca registros en la tabla Estado partiendo de parámetros de nulidad
20
Estado_Get_List
Obtiene todos los registros de la tabla Estado
21
Estado_GetByEstado
Seleccionar los registros de la tabla Estado a través del campo Estado
22
Estado_GetById
23
24
Seleccionar los registros de la tabla Estado a través del campo Id
Seleccionar los registros de la tabla Estado partiendo de una validación
Estado_GetByidEventoFromEstadoEvento
respecto al campo IdEvento de la tabla EstadoEvento
Estado_GetByidTipoUsuarioPermitidoFrom Seleccionar los registros de la tabla Estado partiendo de una validación
EstadoEvento
respecto al campo IdTipoUsuarioPermitido de la tabla EstadoEvento
- 65 -
No.
Observaciones
25
Estado_GetPaged
26
Estado_Insert
Obtiene los registros de la tabla Estado haciendo un idexado y verificando
Inserta un registro en la tabla de Estado
27
Estado_Update
Actualiza un registro en la tabla de Estado
28
EstadoEvento_Delete
29
EstadoEvento_Find
30
EstadoEvento_Get_List
Elimina un registro en la tabla de EstadoEvento
Busca registros en la tabla EstadoEvento partiendo de parámetros de
nulidad
Obtiene todos los registros de la tabla EstadoEvento
31
EstadoEvento_GetById
37
Seleccionar los registros de la tabla EstadoEventos a través del Id
Seleccionar los registros de la tabla EstadoEvento a través de la llave
EstadoEvento_GetByIdEstado
foranea IdEstado
EstadoEvento_GetByIdEstadoIdEventoIdTi Selecciona los registros de la tabla de EstadoEvento por medio de un
índice
poUsuarioPermitido
Seleccionar los registros de la tabla EstadoEvento a través de la llave
EstadoEvento_GetByIdEvento
foranea IdEvento
EstadoEvento_GetByIdTipoUsuarioPermiti Seleccionar los registros de la tabla EstadoEvento a través del campo
do
IdTipoUsuarioPermitido
Obtiene los registros de la tabla EstadoEvento haciendo un idexado y
EstadoEvento_GetPaged
EstadoEvento_Insert
Inserta un registro en la tabla EstadoEvento
38
EstadoEvento_Update
Actualiza un registro en la tabla EstadoEvento
39
Eventos_Delete
Elimina un registro en la tabla de Eventos
40
Eventos_Find
Busca registros en la tabla Eventos partiendo de parámetros de nulidad
41
Eventos_Get_List
Obtiene todos los registros de la tabla Eventos
42
Eventos_GetById
43
Eventos_GetByidEstadoFromEstadoEvento
Seleccionar los registros de la tabla Eventos a través del Id
Seleccionar los registros de la tabla Eventos partiendo de una validación
respecto al campo IdEstado de la tabla EstadoEvento
44
Eventos_GetByidTipoUsuarioPermitidoFro Seleccionar los registros de la tabla Eventos partiendo de una validación
mEstadoEvento
respecto al campo IdTipoUsuarioPermitido de la tabla EstadoEvento
45
Eventos_GetByNombre
46
Eventos_GetPaged
47
Eventos_Insert
Obtiene los registros de la tabla Eventos haciendo un idexado y
Inserta un registro en la tabla Eventos
48
Eventos_Update
Actualiza un registro en la tabla Eventos
49
HistorialSolicitud_Delete
50
HistorialSolicitud_Find
51
HistorialSolicitud_Get_List
Elimina un registro en la tabla de HistorialSolicitud
Busca registros en la tabla HistorialSolicitud partiendo de parámetros de
nulidad
Obtiene todos los registros de la tabla HIstorialSolicitud
52
HistorialSolicitud_GetById
53
HistorialSolicitud_GetByIdSolicitud
54
HistorialSolicitud_GetPaged
55
HistorialSolicitud_Insert
Inserta un registro en la tabla HistorialSolicitud
56
HistorialSolicitud_Update
Actualiza un registro en la tabla HistorialSolicitud
32
33
34
35
36
Seleccionar los registros de la tabla Eventos a través del campo Nombre
Seleccionar los registros de la tabla HIstorialSolicitud a través del Id
Seleccionar los registros de la tabla HistorialSolicitud a través de la llave
foranea IdSolicitud
Obtiene los registros de la tabla HistorialSolicitud haciendo un idexado y
- 66 -
No.
Observaciones
57
Rol_Delete
Elimina un registro en la tabla de Rol
58
Rol_Find
Busca registros en la tabla Rol partiendo de parámetros de nulidad
59
Rol_Get_List
Obtiene todos los registros de la tabla Rol
60
Rol_GetById
61
Rol_GetByidEstadoFromEstadoEvento
62
Rol_GetByidEventoFromEstadoEvento
63
Rol_GetByNombre
64
Rol_GetPaged
65
Rol_Insert
Seleccionar los registros de la tabla Rol a través del Id
Seleccionar los registros de la tabla Rol partiendo de una validación
respecto al campo IdEstado de la tabla EstadoEvento
Seleccionar los registros de la tabla Rol partiendo de una validación
respecto al campo IdEvento de la tabla EstadoEvento
Seleccionar los registros de la tabla Rol a través del campo Nombre
Obtiene los registros de la tabla Rol haciendo un idexado y verificando los
parámetros que existan en el procedimiento
Inserta un registro en la tabla Rol
66
Rol_Update
Actualiza un registro en la tabla Rol
67
Solicitud_Delete
Elimina un registro en la tabla de Solicitud
68
Solicitud_Find
Busca registros en la tabla Solicitud partiendo de parámetros de nulidad
69
Solicitud_Get_List
Obtiene todos los registros de la tabla Solicitud
70
Solicitud_GetById
71
Solicitud_GetByIdEstado
72
Solicitud_GetByIdUsuarioAsignado
73
Solicitud_GetByIdUsuarioAutor
74
Solicitud_GetByIdWorkflow
75
Solicitud_GetPaged
76
Solicitud_Insert
Seleccionar los registros de la tabla Solicitud a través del Id
Seleccionar los registros de la tabla Solicitud a través de la llave foranea
IdEstado
IdUsuarioAsignado
IdUsuarioAutor
IdWorkflow
Obtiene los registros de la tabla Solicitud haciendo un idexado y
Inserta un registro en la tabla Solicitud
77
Solicitud_Update
Actualiza un registro en la tabla Solicitud
78
TipoArchivoAdjunto_Delete
79
TipoArchivoAdjunto_Find
80
TipoArchivoAdjunto_Get_List
Elimina un registro en la tabla de TipoArchivoAdjunto
Busca registros en la tabla TipoArchivoAdjunto partiendo de parámetros
de nulidad
Obtiene todos los registros de la tabla TipoArchivoAdjunto
81
TipoArchivoAdjunto_GetById
Seleccionar los registros de la tabla TipoArchivoAdjunto a través del Id
82
TipoArchivoAdjunto_GetByNombre
Seleccionar los registros de la tabla TipoArchivoAdjunto a través del
campo Nombre
83
TipoArchivoAdjunto_GetPaged
Obtiene los registros de la tabla TipoArchivoAdjunto haciendo un idexado
y verificando los parámetros que existan en el procedimiento
84
TipoArchivoAdjunto_Insert
Inserta un registro en la tabla TipoArchivoAdjunto
85
TipoArchivoAdjunto_Update
Actualiza un registro en la tabla TipoArchivoAdjunto
86
Usuario_Delete
Elimina un registro en la tabla de Usuario
87
Usuario_Find
Busca registros en la tabla Usuario partiendo de parámetros de nulidad
88
Usuario_Get_List
Obtiene todos los registros de la tabla Usuario
- 67 -
4.3.
No.
89
Usuario_GetById
90
Usuario_GetByIdArea
91
Usuario_GetByIdRol
92
Usuario_GetPaged
93
Usuario_Insert
Observaciones
Seleccionar los registros de la tabla Usuario a través del Id
Seleccionar los registros de la tabla Usuario a través de la llave foranea
IdArea
Seleccionar los registros de la tabla Usuario a través de la llave foranea
IdRol
Obtiene los registros de la tabla Usuario haciendo un idexado y verificando
Inserta un registro en la tabla Usuario
94
Usuario_Update
Actualiza un registro en la tabla Usuario
95
Workflow_Delete
Elimina un registro en la tabla de Workflow
96
Workflow_Find
Busca registros en la tabla Workflow partiendo de parámetros de nulidad
97
Workflow_Get_List
Obtiene todos los registros de la tabla Workflow
98
Workflow_GetById
99
Workflow_GetPaged
100 Workflow_Insert
Seleccionar los registros de la tabla Workflow a través del Id
Obtiene los registros de la tabla Workflow haciendo un idexado y
Inserta un registro en la tabla Workflow
101 Workflow_Update
Actualiza un registro en la tabla Workflow
Implementación
La aplicación de solicitudes se desarrolló con la herramienta Windows Workflow
Foundation que es el modelo de programación de Microsoft que permite crear
aplicaciones con funcionalidad de workflow.
Las actividades son los elementos que componen los flujos de trabajo. Las
soluciones de flujo de trabajo se crean generando actividades en el diseñador de
Visual Studio 2005. Al igual que los controles de servidor de ASP.NET y los
controles de Windows Forms, las actividades de flujo de trabajo constituyen la
esencia de la solución y forman la principal base de herramientas de desarrollo.
Windows Workflow Foundation incluye una serie de actividades para cubrir la
mayoría de las necesidades habituales.
Inicialmente con las herramientas de Windows Workflow Foundation se elaboró el
flujo de trabajo, estableciendo cada uno de los estados y puntos donde el flujo se
debe detener para que el usuario realice intervención manual, igualmente se
- 68 -
parametrizó cada uno de los estados para que el sistema administre
automáticamente cada uno de los posibles eventos futuros.
Figura 16. Flujo de Trabajo Aplicativo Web
Elaborado en Microsoft Visual Studio 2005
Posteriormente
Visual
Studio
2005
genera
automáticamente
un
archivo
denominado web.config el cual guarda las configuraciones del aplicativo web, este
archivo se programa en lenguaje XML, así:
Configuración del Correo Electrónico:
<mailConfiguration>
Indica si se habilita la función de Correo Electrónico
<add key="activarAlertaCorreo" value="true"/>
- 69 -
<add key="requiereAutenticacion" value="true"/>
Correo Electrónico asignado al aplicativo:
<add key="mailFrom" value="[email protected]"/>
Nombre del servidor del Correo Electrónico:
<add key="servidorCorreo" value="BANBOGOTA.NET"/>
Nombre del usuario del Correo Electrónico asignado al aplicativo:
<add key="usuarioCorreo" value="[email protected]"/>
Contraseña del Correo Electrónico asignado al aplicativo:
<add key="passwordCorreo" value="Abcdef1234"/>
Personalización de los textos remitidos a todos los actores de acuerdo al evento:
<add key="solCreadaAdmon" value="Señor Administrador: Se encuentra disponible una
nueva solicitud:"/>
<add key="solCreadaUsuario" value="Señor Usuario: Su Solicitud ha sido creada
exitosamente:"/>
<add key="solAsignadaAdmon" value="Señor Usuario: Su Solicitud ha sido asignada"/>
<add key="solAsignadaAnalista" value="Señor Analista: Una nueva solicitud ha
sido asignada a su cuenta, por favor revise el sistema."/>
<add key="solCanceladaAdmon" value="Señor Administrador: Una Solicitud se encuentra
esperando por cancelación"/>
<add key="solCanceladaUsuario" value="Señor Usuario: Su Solicitud ha recibido una
petición de cancelación"/>
<add key="solPendienteAsignacionAdmon" value="Señor Administrador: Una solicitud se
encuentra pendiente de asignación."/>
<add key="solPendienteAsignacionUsuario" value="Señor Usuario: Una solicitud fue
rechazada la solicitud de cancelación"/>
<add key="solCompletadaAdmon" value="Señor Administrador: Una solicitud ha sido
completada exitosamente y espera cierre."/>
<add key="solCompletadaUsuario" value="Señor Usuario: Su Solicitud ha sido completada
exitosamente"/>
<add key="solCompletadaAnalista" value="Señor Analista: Una solicitud fue completada
exitosamente"/>
<add key="solCerradaAdmon" value="Señor Administrador: Una solicitud fue cerrada con
exito."/>
<add key="solCerradaUsuario" value="Señor Usuario: Una solicitud ha sido cerrada
exitosamente"/>
- 70 -
<add key="solCerradaAnalista" value="Señor Analista: Una solicitud ha sido completada
exitosamente"/>
<add key="solEnCursoUsuario" value="Señor Usuario: Su Solicitud ha sido asignada y
aceptada exitosamente"/>
<add key="solEnCursoAnalista" value="Señor Analista: Una Solicitud ha sido completada
exitosamente"/>
<add key="solPendienteReasignacionUsuario" value="Señor Administrador: Una Solicitud
esta esperando reasignacion"/>
<add key="solPendienteReasignacionAnalista" value="Señor Usuario: Una Solicitud espera
reasignacion"/>
</mailConfiguration>
Configuración ActiveDirectory:
<activeDirectoryConfiguration>
Extrae del directorio activo el nombre del usuario que accede al aplicativo
<add key="EquivalenteLogin" value="name"/>
Extrae del directorio activo el nombre del departamento al que pertenece el usuario que
accede al aplicativo
<add key="EquivalenteDepto" value="Department"/>
Extrae del directorio activo el Correo Electrónico del usuario que accede al aplicativo
<add key="EquivalenteEMail" value="mail"/>
Nombre del Servidor de Dominio
<add key="DirectorioBusquedaUsuarios"value="LDAP://BANBOGOTA.NET"/>
</activeDirectoryConfiguration>
Configuración Días de Notificaciones:
<commonConfiguration>
Determina desde cuantos días empieza a enviar notificaciones de solicitudes vencidas
<add key="maximoDiasVencimiento" value="5"/>
</commonConfiguration>
- 71 -
Configuración de la Conexión a la Base de Datos:
<connectionStrings>
Establece el nombre del servidor donde se aloja la base de datos, el nombre de la base de
datos, nombre de usuario en la base de datos y la respectiva contraseña
<add name="Solicitudes.Data.ConnectionString" connectionString="data
source=.;database=Solicitudes2000;user id=solicitudesuser;password=123456;Connect
Timeout=30"/>
</connectionStrings>
Configuración del Usuario Default:
Nombre y contraseña del usuario Administrador del Servidor donde se instala el aplicativo
<identity impersonate="true" userName="Administrador" password="123456789"/>
Una vez establecido el archivo de configuración se procede a desarrollar la página
maestra (MasterPage), la cual se denominó admin.master, en ella esta elaborado
el formato visual del aplicativo web (tipo de letra, color de fondo, etc), este tipo de
página sirve para anidar varios formularios sin tener que diseñar el formato en
cada uno de ellos.
Una vez establecidos los formularios que se alojarían en MasterPage se procede a
generar el mapa del sitio, el cual nos permite navegar de una página a otra a
través de un control denominado SiteMapDataSource que requiere como fuente
un archivo en lenguaje XML denominado Web.SiteMap, así:
<?xml version="1.0" encoding="utf-8" ?>
<siteMap xmlns="http://schemas.microsoft.com/AspNet/SiteMap-File-1.0" >
<siteMapNode url=""title="Home"description="">
<siteMapNode url="~/Admin/Default.aspx"title="Admin
Home"description="Site Administrador">
<siteMapNode url="~/Admin/ArchivosAdjuntos.aspx"title="Archivos Adjuntos"
description=""/>
<siteMapNode url="~/Admin/Area.aspx"title="Area"description=""/>
<siteMapNode url="~/Admin/Estado.aspx"title="Estado"description=""/>
- 72 -
<siteMapNode url="~/Admin/EstadoEvento.aspx"title="Estado Evento"
description=""/>
<siteMapNode url="~/Admin/Eventos.aspx"title="Eventos"description=""/>
<siteMapNode url="~/Admin/HistorialSolicitud.aspx"title="Historial
Solicitud"description=""/>
<siteMapNode url="~/Admin/Rol.aspx"title="Rol"description=""/>
<siteMapNode url="~/Admin/Solicitud.aspx"title="Solicitud"
description=""/>
<siteMapNode url="~/Admin/TipoArchivoAdjunto.aspx"title="Tipo Archivo
Adjunto"description=""/>
<siteMapNode url="~/Admin/Usuario.aspx"title="Usuario"description=""/>
<siteMapNode url="~/Admin/Workflow.aspx"title="Workflow"description=""/>
</siteMapNode>
<siteMapNode url="~/Default.aspx"title="Solicitudes
Home"description="Site Solicitudes">
<siteMapNode url="~/Solicitudes/CrearSolicitud.aspx"title="Crear
Solicitud"description=""></siteMapNode>
<siteMapNode url="~/Solicitudes/ConsultarSolicitudes.aspx"
title="Consultar Solicitudes"description=""></siteMapNode>
<siteMapNode url="~/Solicitudes/Reportes/default.aspx"title="Reportes"
description=""></siteMapNode>
</siteMapNode >
<siteMapNode url="~/ayudas.aspx" title="Ayuda" description="Site Ayudas">
</siteMapNode >
</siteMapNode >
</siteMap>
- 73 -
4.3.1.
Interfaz de Usuario
A continuación se presentan los diferentes formularios que componen el
aplicativo en su versión final:
Figura 17. Final – Web inicio sesión no autorizado
El formulario web se muestra cuando un usuario intenta acceder sintener conexión
al directorio activo del servidor de dominio, toda vez que el sistema valida el
usuario y contraseña al ingresar a la intranet.
Figura 18. Final – Web mensaje de alertas
Al iniciar, el aplicativo muestra un mensaje informativo con la cantidad de
solicitudes que se encuentran pendientes para cada usuario.
- 74 -
Para actualizar los días de vencimiento de las solicitudes se creó un JOB en SQL
Server el cual funciona así:
diasVencimiento=diasVencimiento-1
Esta operación la realiza todos los días a las 12:00 am
Figura 19. Final – Web crear solicitud
Formulario de Administrador y Usuario. Está disponible para realizar solicitudes de
información, tiene la opción de adjuntar archivos de cualquier tipo y tamaño,
igualmente de asignar la cantidad de días para que GCIF suministre la
información.
- 75 -
Figura 20. Final – Web consultar solicitud
Formulario de Administrador, Analista y Usuario. Permite ver las solicitudes que se
encuentran
es
estado
Pendiente
Asignación y
Pendiente Reasignación,
igualmente muestra los archivos adjuntos correspondientes al requerimiento.
Figura 21. Final – Web ver detalles de solicitud
- 76 -
Formulario de Administrador y Usuario. Muestra detalles de la solicitud realizada
por un usuario (los posibles estados y eventos, fecha de creación, Analista
asignado, etc.). En este formulario se puede observar una de las características de
AJAX, ya que trae un formulario en forma Modal y apaga el fondo del explorador
web.
Figura 22. Final – Web ver historial de solicitudes
Formulario de Administrador y Usuario. Muestra el historial de la solicitud dentro
de la cadena del workflow. En este formulario se puede observar una de las
características de AJAX, ya que trae un formulario en forma Modal y apaga el
fondo del explorador web.
- 77 -
Figura 23. Final – Web de descarga de archivos adjuntos
Formulario que permite realizar la descarga de los archivos adjuntos.
Figura 24. Final – Web interfaz de descarga
Cuadro de diálogo que permite abrir o guardar los archivos adjuntos.
- 78 -
Figura 25. Final – Web de reportes
Formulario de Administrador que permite seleccionar e imprimir los reportes. Tiene
la opción de generar información de acuerdo a un rango de fechas.
Figura 26. Final – Web archivos adjuntos
Formulario de Administrador. Permite parametrizar en que evento se debe realizar
- 79 -
el attachment de archivos.
Figura 27. Final – Web área
Formulario de Administrador. Permite personalizar las distintas áreas que
componen GCIF.
Figura 28. Final – Web estado evento
- 80 -
Formulario de Administrador. Permite asignar a cada usuario los eventos que
pueden realizar dentro de la aplicación (Crear, Cancelar, Asignar, Rechazar y
Aprobar Solicitud).
Figura 29. Final – Web eventos
Formulario de Administrador. Permite crear y modificar los eventos que pueden
realizar los usuarios (Crear, Cancelar, Asignar, Rechazar y Aprobar Solicitud).
- 81 -
Figura 30. Final – Web historial solicitud
Formulario de Administrador. Permite ver todas las solicitudes terminadas y
modificarlas si es necesario.
Figura 31. Final – Web rol
Formulario de Administrador. Permite la creación y modificación de roles dentro de
la aplicación.
- 82 -
Figura 32. Final – Web solicitud
Formulario de Administrador. Permite ver todas las solicitudes en estado
pendiente y asignarlas a los Analistas.
Figura 33. Final – Web tipo archivo adjunto
Formulario de Administrador. Permite parametrizar en que momento se adjuntan
archivos.
- 83 -
Figura 34. Final – Web usuario
Formulario de Administrador. Permite parametrizar los usuarios que tienen un
acceso diferente a Usuario en la aplicación.
Figura 35. Final – Web Workflow
Formulario de Administrador. Permite ver todos los códigos asignados a las
solicitudes.
- 84 -
Figura 36. Final – Web Ayuda
Formulario de Administrador, Analista y usuario. Permite ver las ayudas del
aplicativo en una ventana de Windows Media.
- 85 -
4.3.2.
Mapa del Sitio
En un aplicativo web es importante conocer las diferentes rutas que el usuario
puede tomar de acuerdo al rol que tenga asignado. Para el proyecto de
workflow de solicitudes se manejan tres roles diferentes (Administrador, Analista
y Usuario) cada uno cuenta con diferentes opciones de navegación, las cuales
se presentan a continuación:
Figura 37. Mapa del Sitio Administrador
- 86 -
Figura 38. Mapa del Sitio Analista
Figura 39. Mapa del Sitio Usuario
Crear Solicitud
Solicitudes Home
Consultar Solicitudes
Detalles e
Historial de
Solicitud
Página de Ayudas
Videos de
Ayuda
Mensaje de Alerta
Ayuda
- 87 -
4.3.3.
Esquema de Pruebas
Propósito:
• Comprobar la eficiencia del sistema frente a la administración de las
solicitudes de información realizadas al GCIF.
• Probar diferentes situaciones para validar el comportamiento del sistema.
Prerrequisitos:
• El usuario que intenta acceder al aplicativo debe tener una cuenta de usuario
en el directorio activo.
Datos de Prueba:
• Esta el usuario como un usuario autenticado o es un usuario desconocido
para el dominio.
• Si es un usuario desconocido debe presentar las respectivas credenciales
para acceder al aplicativo.
• Después de garantizar su identidad se establece cual de los roles
corresponde el usuario.
• Verificar los diferentes roles que puede tomar un usuario y las diferentes
acciones que puede realizar dependiendo del rol que tenga asignado.
• Verificar que el usuario, el analista y el administrador estén al día con los
diferentes requerimientos y los estados de cada evento.
- 88 -
• Determinar los diferentes estados que puede tener un requerimiento y el
control que se tiene sobre cada requerimiento.
Pasos:
• Se inició con un usuario desde una máquina que no pertenece al dominio y
solicita identificación.
• Se inicia con un usuario autenticado y el aplicativo es accesado.
• Una vez en el aplicativo, si el usuario ha creado solicitudes anteriormente
saldrá una notificación de las solicitudes pendientes próximas a vencer, al
darle aceptar se accede a las solicitudes pendientes, en el caso de darle
cancelar se accede al panel de usuario. Si el usuario no tiene solicitudes
muestra el panel del usuario.
• Una vez en el panel el usuario puede crear una solicitud, consultar las
solicitudes propias y solicitar la cancelación de una solicitud.
• Para esta prueba se crea una solicitud, en donde se requiere adjuntar un
archivo con la información requerida y con un plazo de entrega de 10 días, al
momento de ingresar el numero de los días se realizo la prueba de ingresar
0 días y arrojo un mensaje que informaba que era un valor invalido, un valor
de 1 a 60.
• Una vez creada la solicitud se asigno un identificador para la solicitud y se
genero un correo electrónico notificando que la solicitud fue creada
satisfactoriamente.
- 89 -
• Posteriormente se dispuso consultar la solicitud, ya realizada la consulta se
realizaron pruebas con los filtros dando resultados satisfactorios.
• En este momento se realizo cambio de usuario ingresando al sistema como
administrador.
• Respecto a la solicitud el administrador puede asignar la solicitud a un
analista o puede cancelarla.
• Se realizo la asignación de la solicitud, comprobando que las solicitud si
fuera asignada correctamente y sin perdida de información a un usuario del
GCIF.
• También se realizaron pruebas sobre Admin Home. Se editaron valores de
Área, donde se creo un área llamada Producción.
• Posteriormente se realizo el cambio de usuario a Analista para poder seguir
el flujo de la solicitud.
• El analista puede tomar la decisión de aceptar o rechazar la asignación.
• Se procedió a probar que el analista aceptara la asignación y el usuario es
notificado de quien quedo a cargo de su requerimiento.
• Se procedió a rechazar una asignación por parte del analista siendo vista por
el administrador.
• Se aceptó una cancelación o rechazo por parte del administrador.
- 90 -
• Se terminó un requerimiento y fue cerrado por parte del analista, se le
notifica al administrador y al usuario.
Debido a que la información que va a ser administrada por el aplicativo Web es
de carácter confidencial la Gerencia Centro de Información Financiera no
permitió la realización de pruebas que implicaran tener dos sistemas paralelos
para realizar la gestión de las solicitudes de información por no estar incluidas
en los procesos internos del Banco de Bogotá.
- 91 -
5. CONCLUSIONES
La nueva generación de tecnología workflow se apoya en organizaciones
tecnológicamente maduras en las que se comparte la información y se aprovecha
el conocimiento de sus empleados, organizaciones con una estructura horizontal
donde existen pocas jerarquías y pocos niveles gerenciales.
Los estudios de prospectiva más recientes sobre incorporación de tecnologías a
las empresas señalan que la última generación del workflow va a revolucionar la
forma de interactuar de éstas con sus clientes: workflow en entorno web. De
hecho, la Workflow Management Coalition está trabajando en la elaboración de
estándares y protocolos como Swap (Simple workflow access protocol), basados
en http, para conseguir la gestión de procesos de negocio en el entorno internet,
una trayectoria similar a la que han seguido las aplicaciones de groupware con
respecto a las intranets con tecnología web.
Una de las principales razones por las que escasean casos de aplicación de este
tipo de sistemas se encuentra en la problemática de su implantación, que viene
dada por la complejidad misma de diseño y definición de procesos. Esto supone
un freno para muchas compañías, que se sienten abrumadas por el trabajo previo
que requiere dicha implantación y que en la mayoría de las ocasiones debe
solicitar ayuda externa en forma de consultoría.
Esta tecnología permite saber y conocer el orden lógico como se ejecutan los
requerimientos de información y las relaciones que existen entre ellos, lo que va a
facilitar determinar el flujo del sistema, el flujo humano y el flujo de los documentos
y de la información.
- 92 -
Windows Workflow Foundation permitió conocer todo el flujo de la información y
escribirla en un código lo que permitió crear una interacción entre el sistema y el
usuario, en la cual hay procesos que realiza el sistema y otros el usuario,
adicionalmente está tecnología permite una mejor integración del aplicativo con los
procesos y servicios Windows mediante la utilización de webforms, web services,
etc.
Adicionalmente al utilizar el concepto de serialización y deserialización de
información, se pudo comprobar que la capacidad de almacenamiento y
rendimiento de la Base de Datos se optimizó ya que los datos se almacenan en
forma binaria.
En el Banco de Bogota para la solicitud de información financiera no existía hasta
el presente aplicativo, uno que permitiera de manera rápida y certera saber en que
estado se encontraba una determinada solicitud y así mismo, se perdía mucho
tiempo mientras se recolectaba la información.
Una vez realizado el esquema de pruebas se pudo establecer que con el aplicativo
de Gestión de Solicitudes se ofrece una herramienta que mejora los
procedimientos para realizar solicitudes de información y reducir los tiempos de
espera para el usuario.
Gracias a la utilización de esta tecnología (workflow), en el momento que se
implemente finalmente el Sistema de Gestión de Solicitudes (GCIF) va a facilitar a
los usuarios conocer a ciencia cierta toda la información requerida de una solicitud
en cualquier momento desde su inicio hasta el final de la misma.
Con un aplicativo distribuido se obtiene un alto rendimiento en la red LAN,
ofreciendo a todos los usuarios una herramienta eficaz y de fácil interacción con el
usuario final.
- 93 -
6. BIBLIOGRAFÍA
• Banco de Bogotá. Metodología de desarrollo de proyectos
DS Título III Capítulo 3. Enero 24 de 2002
• Banco de Bogotá. Políticas para la entrega de aplicaciones
DS Titulo V Capitulo 2. Octubre 26 de 2005
• Banco de Bogotá. Metodología para la elaboración y actualización de
manuales de operación
AD Título V Capítulo 1. Septiembre 15 de 2006
• MSDN Microsoft Corporation. Designing Data Tier Components and Passing
Data Through Tiers. [Artículo de internet].
http://msdn2.microsoft.com/en-us/library/ms978496.aspx [Consulta: 30 de
abril de 2007].
• ASP.NET. AJAX 1.0. [Artículo de internet].
http://ajax.asp.net/default.aspx?tabid=47 [Consulta: 15 de abril de 2007].
• Microsoft Corporation. ASP.NET 2.0 Data Tutorials. [Artículo de internet].
http://www.asp.net/learn/dataaccess/default.aspx?tabid=63 [Consulta: 27 de
marzo de 2007].
• UML Resource Page [Artículo de Internet].
http://www.uml.org [Consulta: 14 de marzo de 2007].
- 94 -
ANEXOS
- 95 -
Anexo A. Carta de autorización del Banco de Bogotá
- 96 -
- 97 -
Anexo B. Formato de Entrevista
- 98 -
FORMATO DE ENTREVISTA INICIAL PARA DETECCIÓN DE NECESIDADES EN LA
GESTIÓN DE SOLICITUDES DE INFORMACIÓN DEL GCIF
GERENCIA CENTRO DE INFORMACIÓN FINANCIERA - BANCO DE BOGOTÁ
DEPENDENCIA:
HORA INICIO:
HORA FINALIZACION:
FECHA
DIA
MES
AÑO
Entrevistados
1.
Cuáles son los aspectos más importantes a tener en cuenta para que GCIF gestione las solicitudes
de manera adecuada y oportuna?
2.
Cómo cree usted que un aplicativo puede solucionar la necesidad de gestionar y administrar con
calidad las solicitudes de información?
3.
Qué incidentes en la gestión de información han ocurrido en el área?
4.
Cuáles consideran que pueden ser nuestros aportes para mejorar el flujo de solicitudes de
información?
5.
Según el consenso de los asistentes cuales son los riesgos más significativos en el área?
Firmas
- 99 -
Anexo C. Manual Técnico
- 100 -
MANUAL TÉCNICO
Requerimientos Mínimos:
Para realizar la instalación del aplicativo de Gestión de Solicitudes GCIF se
requiere 1 o varios servidores con el siguiente software:
• Microsoft Windows 2003 Server
• Internet Information Server
• Active Directory
• Microsoft SQL Server 2000 o posterior
• Microsoft Exchange 2003 o posterior
En el servidor donde se instale el aplicativo debe poseer como requisito mínimo
los siguientes componentes:
• .Net Framework 2.0
- 101 -
Configuración de la Base de Datos
La base de datos se encuentra en los archivos denominados:
SOLICITUDES2000.mdf
SOLICITUDES2000_log.ldf
Se debe cargar o recuperar la base de datos en Microsoft SQL Server con el
nombre
Solicitudes2000,
posteriormente
debe
crear
un
usuario
llamado
SolicitudesUser con permisos de Owner.
A
continuación
se
ActualizacionVencimientos
debe
el
crear
cual
un
cumple
Trabajo
la
(Job)
función
automáticamente un día de plazo a las solicitudes pendientes, así:
- 102 -
denominado
de
descontar
Finalmente se debe programar para que suceda todos los días a las 12:00 am
- 103 -
Instalación del Software
Paso 1:
Una
vez
instalados
los
requisitos mínimos, hacer doble
clic sobre el archivo Setup.exe
el cual guiará al usuario a través
de un asistente.
Paso 2:
El asistente inicia con la pantalla
de presentación.
para
continuar
presionar
el
botón Siguiente.
- 104 -
Paso 3:
Selecciona la ubicación y el
nombre del sitio para acceder
posteriormente a la aplicación
por
el
Browser
(Internet
Explorer, Netscape, etc). Ej:
http://localhost/Workflow/Default
.aspx
Para
continuar
presionar
el
confirmación
de
botón Siguiente.
Paso 4:
Pantalla
de
instalación.
Para
continuar
presionar
el
botón Siguiente.
- 105 -
Paso 5:
Pantalla
de
avance
de
instalación del aplicativo.
Para
continuar
presionar
el
botón Siguiente.
Paso 6:
Pantalla
de
finalización
de
instalación del aplicativo
Para
continuar
presionar
el
botón Cerrar.
- 106 -
Paso 7:
Una vez instalado el software se
debe
configurar
el
tipo
de
acceso autenticado con el cual
los usuarios se conectarán al
sitio Web.
Para realizar esta tarea se
requiere
abrir
Internet
Information Server (IIS) en las
propiedades
seleccionar
Seguridad
del
la
de
sitio
Web
pestaña
Directorios
de
y
presionar el botón Modificar.
Aparecerá la siguiente pantalla
la cual debe configurar como lo
muestra la imagen.
Presionar el botón Aceptar.
- 107 -
Paso 8:
Finalmente en propiedades del
sitio
Web,
seleccionar
la
pestaña ASP.NET y verificar
que la versión disponible sea la
2.0.50727
Presionar el botón Aceptar.
- 108 -
Configuración del archivo Web.Config
El archivo Web.Config es el encargado de guardar la configuración del aplicativo,
en él se puede establecer varios aspectos del sistema los cuales se dividen así:
1. Configuración del Correo Electrónico:
<mailConfiguration>
Indica si se habilita la función de Correo Electrónico
<add key="activarAlertaCorreo" value="true"/>
<add key="requiereAutenticacion" value="true"/>
Correo Electrónico asignado al aplicativo:
<add key="mailFrom" value="[email protected]"/>
Nombre del servidor del Correo Electrónico:
<add key="servidorCorreo" value="BANBOGOTA.NET"/>
Nombre del usuario del Correo Electrónico asignado al aplicativo:
<add key="usuarioCorreo" value="[email protected]"/>
Contraseña del Correo Electrónico asignado al aplicativo:
<add key="passwordCorreo" value="Abcdef1234"/>
Personalización de los textos remitidos a todos los actores de acuerdo al evento:
<add key="solCreadaAdmon" value="Señor Administrador: Se encuentra disponible una
nueva solicitud:"/>
<add key="solCreadaUsuario" value="Señor Usuario: Su Solicitud ha sido creada
exitosamente:"/>
<add key="solAsignadaAdmon" value="Señor Usuario: Su Solicitud ha sido asignada"/>
<add key="solAsignadaAnalista" value="Señor Analista: Una nueva solicitud ha
sido asignada a su cuenta, por favor revise el sistema."/>
<add key="solCanceladaAdmon" value="Señor Administrador: Una Solicitud se encuentra
esperando por cancelación"/>
<add key="solCanceladaUsuario" value="Señor Usuario: Su Solicitud ha recibido una
petición de cancelación"/>
<add key="solPendienteAsignacionAdmon" value="Señor Administrador: Una solicitud se
encuentra pendiente de asignación."/>
- 109 -
<add key="solPendienteAsignacionUsuario" value="Señor Usuario: Una solicitud fue
rechazada la solicitud de cancelación"/>
<add key="solCompletadaAdmon" value="Señor Administrador: Una solicitud ha sido
completada exitosamente y espera cierre."/>
<add key="solCompletadaUsuario" value="Señor Usuario: Su Solicitud ha sido completada
exitosamente"/>
<add key="solCompletadaAnalista" value="Señor Analista: Una solicitud fue completada
exitosamente"/>
<add key="solCerradaAdmon" value="Señor Administrador: Una solicitud fue cerrada con
exito."/>
<add key="solCerradaUsuario" value="Señor Usuario: Una solicitud ha sido cerrada
exitosamente"/>
<add key="solCerradaAnalista" value="Señor Analista: Una solicitud ha sido completada
exitosamente"/>
<add key="solEnCursoUsuario" value="Señor Usuario: Su Solicitud ha sido asignada y
aceptada exitosamente"/>
<add key="solEnCursoAnalista" value="Señor Analista: Una Solicitud ha sido completada
exitosamente"/>
<add key="solPendienteReasignacionUsuario" value="Señor Administrador: Una Solicitud
esta esperando reasignacion"/>
<add key="solPendienteReasignacionAnalista" value="Señor Usuario: Una Solicitud espera
reasignacion"/>
</mailConfiguration>
2. Configuración ActiveDirectory:
<activeDirectoryConfiguration>
Extrae del directorio activo el nombre del usuario que accede al aplicativo
<add key="EquivalenteLogin" value="name"/>
Extrae del directorio activo el nombre del departamento al que pertenece el usuario que
accede al aplicativo
<add key="EquivalenteDepto" value="Department"/>
Extrae del directorio activo el Correo Electrónico del usuario que accede al aplicativo
<add key="EquivalenteEMail" value="mail"/>
- 110 -
Nombre del Servidor de Dominio
<add key="DirectorioBusquedaUsuarios"value="LDAP://BANBOGOTA.NET"/>
</activeDirectoryConfiguration>
3. Configuración Días de Notificaciones:
<commonConfiguration>
Determina desde cuantos días empieza a enviar notificaciones de solicitudes vencidas
<add key="maximoDiasVencimiento" value="5"/>
</commonConfiguration>
4. Configuración de la Conexión a la Base de Datos:
<connectionStrings>
Establece el nombre del servidor donde se aloja la base de datos, el nombre de la base de
datos, nombre de usuario en la base de datos y la respectiva contraseña
<add name="Solicitudes.Data.ConnectionString" connectionString="data
source=.;database=Solicitudes2000;user id=solicitudesuser;password=123456;Connect
Timeout=30"/>
</connectionStrings>
5. Configuración del Usuario Default:
Nombre y contraseña del usuario Administrador del Servidor donde se instala el aplicativo
<identity impersonate="true" userName="Administrador" password="123456789"/>
- 111 -

Sistema de Gestión de Requerimientos de Información para GCIF

Transcription

Similar documents

WEEK OF JULY 15, 2013

Cocina Mexicana_Book3_final

universidad nacional experimental de guayana

EUROPE`S FINEST RECIPE BOOK

Revista Nº15 - Colegio de Administradores de Fincas de Cantabria

Tutorial JSF`S(Java Server Faces)

New York State Insurance Fund

Secundaria - Goose Creek CISD

Guía de Evaluación de Insumos para la Salud

Viking Professional Stand Mixer

gDownload the PDF

Guía del usuario de la 2 interfaz de la línea de

Programa de Gestión Documental - Superintendencia Financiera de

Guía de integración de Pasarela integral

gaceta de la propiedad industrial - Superintendencia de Industria y

Nombramientos y Credenciales - Centro Nacional de Registros