Evaluación Arquitectónica de Aplicaciones Críticas en Producción

UNIVERSIDAD SIMÓN BOLÍVAR
Ingeniería de la Computación
Evaluación Arquitectónica de Aplicaciones Críticas en Producción
Plataforma Visual Banker
por: Irene Akela García Sánchez
INFORME FINAL DE CURSOS EN COOPERACIÓN
Presentado ante la Ilustre Universidad Simón Bolívar
Como Requisito Parcial para Optar al Título de
Ingeniero en Computación
Sartenejas, Octubre 2006
i
ii
UNIVERSIDAD SIMÓN BOLÍVAR
Ingeniería de la Computación
Evaluación Arquitectónica de Aplicaciones Críticas en Producción
Plataforma Visual Banker
Informe de pasantía realizado en:
Banesco, Banco Universal.
Autor: Irene Akela García Sánchez
Carnet Nº: 01-33903
Tutor Académico: Prof. Edumilis Méndez.
Tutor Industrial: Ing. Marlon Moreno
Sartenejas, Octubre 2006
iii
iv
vi
Evaluación Arquitectónica de Aplicaciones Críticas en Producción - Plataforma Visual Banker
Realizado por: Irene García S.
RESUMEN
Banesco, como parte del proyecto “Masificación de Rupcorb 2006” se planteó durante este año
realizar la evaluación arquitectónica de aplicaciones consideradas críticas para la organización y que ya
se encuentran en producción. Para el desarrollo de la pasantía se contó con el apoyo del área de Calidad
en Informática, cuya gerente es la Lic. Nora Rodríguez y del área de Plataforma, cuya gerente es la Ing.
Sara García. El apoyo de la primera gerencia fue fundamental ya que la misma ha tenido un mayor
contacto con la metodología Rupcorb desde su implantación dentro del banco. La segunda gerencia
prestó soporte durante todo el proceso de evaluación e implementación, ya que una gran parte de la
aplicación fue desarrollada por esta área. De igual manera, se contó con el apoyo del Laboratorio de
Investigación en Sistemas de Información (LISI) de la USB, el cual dio su apoyo constante durante el
proceso de evaluación arquitectónica por el amplio conocimiento que tiene sobre este tema, además de
la experiencia en proyectos similares realizados en el país.
La aplicación con la que se trabajó es de tipo cliente-servidor y se denomina Visual Banker. La
misma fue desarrollada como un framework utilizado para dar soporte a todas las agencias del banco a
nivel nacional. El lenguaje de programación empleado fue Visual Age for Smalltalk v.3.0.
El objetivo fundamental de la pasantía fue realizar la evaluación arquitectónica de dicha
aplicación, empleando para ello la metodología Rupcorb y el método ATAM como parte del proceso.
Rupcorb fue utilizada para documentar y conocer la arquitectura actual a través de la elaboración de los
artefactos que la misma propone; ATAM fue empleado específicamente para el proceso de evaluación
arquitectónica. Una vez realizada la evaluación se efectuó el análisis que permitió identificar los atributos
de calidad que se encontraban inhibidos dentro de la arquitectura actual, con el fin de elaborar las
propuestas que permitieran la transformación de la misma. Una vez analizadas las propuestas se planteó
y llevó a cabo la implementación de un porcentaje de ellas sujeto a la disponibilidad de recursos
existentes y a la prioridad e importancia otorgada por la Gerencia de Plataforma. Por último, se
plantearon las conclusiones y recomendaciones a tomar en cuenta por la organización.
vii
viii
ÍNDICE GENERAL
RESUMEN................................................................................................................................................... VII
ÍNDICE GENERAL ....................................................................................................................................... IX
ÍNDICE DE TABLAS .................................................................................................................................... XI
ÍNDICE DE FIGURAS ................................................................................................................................. XII
LISTA DE SÍMBOLOS Y ABREVIATURAS ............................................................................................... XIII
CAPÍTULO 1 MARCO REFERENCIAL..........................................................................................................1
1.1. INTRODUCCIÓN ............................................................................................................................1
1.2. OBJETIVOS ..................................................................................................................................2
Objetivo General ........................................................................................................................2
Objetivos Específicos .................................................................................................................2
1.3. JUSTIFICACIÓN.............................................................................................................................3
1.4. ALCANCE DE LA PASANTÍA ............................................................................................................4
1.5. ENTORNO EMPRESARIAL ..............................................................................................................5
1.6. PLANTEAMIENTO DEL PROBLEMA ..................................................................................................8
CAPÍTULO 2 MARCO TEÓRICO................................................................................................................ 10
2.1. DOMINIO DEL PROBLEMA ............................................................................................................10
2.2. DOMINIO DE LA APLICACIÓN........................................................................................................16
CAPÍTULO 3 MARCO METODOLÓGICO .................................................................................................. 22
3.1. ASPECTOS METODOLÓGICOS - RESUMEN RUPCORB....................................................................22
3.2. ASPECTOS METODOLÓGICOS - RESUMEN ATAM.........................................................................26
CAPÍTULO 4 DESARROLLO: RUPCORB.................................................................................................. 30
4.1. DOCUMENTO DE ESPECIFICACIONES DE REQUERIMIENTOS DE SOFTWARE (ERS) .........................30
4.2. DOCUMENTO DE ARQUITECTURA DE SOFTWARE (DAS) ...............................................................34
CAPÍTULO 5 DESARROLLO: ATAM.......................................................................................................... 41
Paso 1. Presentación del ATAM ............................................................................................. 41
Paso 2. Presentar las reglas del Negocio del Proyecto.......................................................... 41
Paso 3. Presentar la Arquitectura ........................................................................................... 42
Paso 4. Identificar las propuestas de la Arquitectura.............................................................. 42
Paso 5. Árbol de Utilidad (Utility Tree) .................................................................................... 42
ix
Paso 6. Analizar las propuestas arquitectónicas (ABAS)........................................................ 45
Paso 7. Priorización de Escenarios......................................................................................... 50
Paso 8. Analizar las propuestas de la Arquitectura................................................................. 50
Paso 9. Presentación de resultados........................................................................................ 50
CAPÍTULO 6 ANÁLISIS DE LA ARQUITECTURA PARA LA TRANSFORMACIÓN.................................. 51
6.1. ESCENARIOS Y PROPUESTAS ......................................................................................................55
6.2. JUSTIFICACIÓN DE ESCENARIOS IMPLEMENTADOS........................................................................59
CAPÍTULO 7 RESULTADOS DE LA IMPLEMENTACIÓN ......................................................................... 66
CAPÍTULO 8 CONCLUSIONES Y RECOMENDACIONES ........................................................................ 73
REFERENCIAS BIBLIOGRÁFICAS ............................................................................................................ 77
APÉNDICE A ESPECIFICACIONES DE REQUERIMIENTOS DEL SOFTWARE ..................................... 80
APÉNDICE B DOCUMENTO DE ARQUITECTURA DE SOFTWARE ..................................................... 119
APÉNDICE C GLOSARIO DE TRANSACCIONES Y PRODUCTOS ....................................................... 145
APÉNDICE D UTILITY TREE Y ABAS PARA CADA ESCENARIO ......................................................... 148
APÉNDICE E NORMAS DE CALIDAD ISO 9126 .................................................................................... 174
APÉNDICE F VISIÓN DEL SISTEMA ....................................................................................................... 178
APÉNDICE G ESPECIFICACIONES DE REQUERIMIENTOS DEL SOFTWARE................................... 190
APÉNDICE H DOCUMENTO DE ARQUITECTURA DE SOFTWARE PROPUESTO ............................. 199
APÉNDICE I - PANTALLAS DESARROLLADAS ..................................................................................... 216
x
ÍNDICE DE TABLAS
Tabla 4.1: Tabla de Especificaciones Suplementarias – Seguridad Interna .............................................. 31
Tabla 4.2: Lista de Casos de Uso ............................................................................................................... 32
Tabla 4.3: Caso de Uso “Buscar Cliente” – Módulo de Plataforma ............................................................ 34
Tabla 5.1: Elementos de la descripción de Escenarios [Kazman, Klein, 99].............................................. 45
Tabla 5.2: ABAS del Escenario #11............................................................................................................ 46
Tabla 5.3: ABAS del Escenario #17............................................................................................................ 48
Tabla 5.4: ABAS del Escenario #19............................................................................................................ 49
Tabla 6.1: Porcentaje de cumplimiento de los atributos de Calidad ........................................................... 52
Tabla 6.2: Resumen de Escenarios – Decisiones actuales y propuestas .................................................. 59
xi
ÍNDICE DE FIGURAS
Figura 1.1: Directiva de la Organización [Banesco, 2006] ............................................................................ 6
Figura 1.2: Organigrama V.P.E Desarrollo de Tecnología [Banesco, 2006]................................................. 7
Figura 1.3: Organigrama V.P.E Banca Electrónica y Soporte Tecnológico [Banesco, 2006]....................... 8
Figura 2.1: Dominio del Problema ............................................................................................................... 16
Figura 2.2: Modelo Conceptual de la Aplicación ......................................................................................... 19
Figura 2.3: Modelo Conceptual - Módulo de Plataforma............................................................................. 20
Figura 2.4: Modelo Conceptual - Módulo de Mantenimiento....................................................................... 20
Figura 2.5: Modelo Conceptual - Módulo de Taquilla.................................................................................. 21
Figura 3.1: Fases de Rupcorb [Banesco, Rupcorb] .................................................................................... 24
Figura 4.1: 4 + 1 Vistas Krutchen [Krutchen, 95]........................................................................................ 35
Figura 4.2: Modelo de Casos de Uso – Plataforma .................................................................................... 36
Figura 4.3: Vista Lógica – Plataforma ......................................................................................................... 37
Figura 4.4: Vista de Implementación [Banesco-IBM] .................................................................................. 38
Figura 4.5: Vista de Implantación – Una Agencia ....................................................................................... 39
Figura 5.1: Árbol de Utilidad Visual Banker................................................................................................. 44
Figura 7.1: Pantallas de Implementación – Funcionalidad.......................................................................... 68
Figura 7.2 Pantallas de Implementación – Portabilidad .............................................................................. 69
Figura 7.3 Pantallas de Implementación – Seguridad................................................................................. 70
Figura 7.4 Pantallas de Implementación – Seguridad................................................................................. 71
xii
LISTA DE SÍMBOLOS Y ABREVIATURAS
Lista de Símbolos
ƒ Build: archivo ejecutable instalado en cada estación de trabajo dentro de las agencias.
ƒ Framework: estructura de soporte definida en la cual otro proyecto de Software puede ser
organizado y desarrollado.
ƒ Hardware: conjunto de elementos materiales que componen un computador.
ƒ Software: componentes intangibles de una computadora, es decir, conjunto de programas y
procedimientos necesarios para hacer posible la realización de una tarea específica.
ƒ Stakeholders: toda persona interesada en el éxito del sistema e involucrado en el mismo.
ƒ Token Ring: arquitectura de red desarrollada por IBM en los años 70 con topología lógica en
anillo y técnica de acceso de paso de testigo. Es recogida en el estándar IEEE 802.5.
ƒ Utility Tree: árbol de utilidad.
ƒ Workflows: el flujo de trabajo es el estudio de los aspectos operacionales de una actividad de
trabajo: cómo se estructuran las tareas, cómo se realizan, cuál es su orden correlativo, cómo se
sincronizan, cómo fluye la información que soporta las tareas y cómo se le hace seguimiento al
cumplimiento de las mismas.
Lista de Abreviaturas
ƒ ABAS Attributed Based Architectural Styles.
ƒ MOSCA Modelo Sistémico de Calidad.
ATAM Architecture Tradeoff Analysis Method.
ƒ RUP Rational Unified Process.
ƒ DAS Documento de Arquitectura de Software.
ƒ Rupcorb RUP Corporativo Banesco.
ƒ ERS Documento de Especificación de
ƒ SNA System Network Architecture.
Requerimientos de Software.
ƒ Sw. Software.
ƒ Hw. Hardware.
ƒ UT Utility Tree.
xiii
CAPÍTULO 1 MARCO REFERENCIAL
1.1. Introducción
El siguiente informe tiene como objetivo fundamental presentar los resultados obtenidos durante
el desarrollo de la pasantía larga realizada en la organización Banesco, en el período Abril-Septiembre
2006. Para ello, se muestra en primera instancia un modelo conceptual que contiene aspectos
relacionados con el tema de evaluación arquitectónica, además de otro modelo conceptual que plantea
aspectos propios de la aplicación evaluada. Cada modelo se explica en detalle presentando en forma
oportuna la relación y dependencia existente entre los conceptos allí planteados.
De igual manera, se realiza una breve introducción sobre la metodología Rupcorb (RUP
Corporativo Banesco) empleada durante el desarrolló de la pasantía; así como una breve introducción
sobre el método ATAM, a través del cual se llevó a cabo la evaluación arquitectónica de Visual Banker.
Para cada uno de los casos se presentan los resultados obtenidos durante el proceso de desarrollo y
evaluación. Además de mostrarse, a través de los apéndices, todos los documentos generados en el
transcurso de la pasantía.
Por último, se plantean los cambios propuestos a la arquitectura de Visual Banker en base a los
resultados obtenidos durante el proceso de evaluación. Así mismo, se muestra la implementación de un
porcentaje de dichos cambios en un entorno de desarrollo real. El libro finaliza con las conclusiones y
recomendaciones planteadas.
En forma puntual cada capítulo se compone de la siguiente manera:
ƒ
Capítulo I: capitulo actual, breve introducción sobre el contenido del informe, objetivos
generales y específicos de la pasantía, justificación, alcance, entorno empresarial y
planteamiento del problema.
ƒ
Capítulo II: presentación del dominio del problema y dominio de la aplicación. Descripción
del proceso de evaluación arquitectónica, así como de la aplicación evaluada. Modelos
conceptuales de los puntos antes mencionados, además del modelo para cada módulo de
Visual Banker.
1
ƒ
Capítulo III: presentación de los aspectos metodológicos, breve descripción de la
metodología Rupcorb, así como del método ATAM empleado para la evaluación
arquitectónica.
ƒ
Capítulo IV: desarrollo Rupcorb. Presentación de resultados obtenidos al aplicar la
metodología:
Documento
de
Arquitectura
de
Software
(DAS)
y
Documento
de
Especificaciones de Requerimientos de Software (ERS).
ƒ
Capítulo V: desarrollo ATAM. Presentación de los resultados obtenidos a través del método
de evaluación arquitectónica: Utility Tree, ABAS.
ƒ
Capítulo VI: análisis de la arquitectura para la transformación. Propuesta de mejoras a la
arquitectura en base a los resultados obtenidos durante el proceso de evaluación.
ƒ
Capítulo VII: presentación de los cambios implementados dentro de Visual Banker.
Arquitectura con las nuevas propuestas.
ƒ
Capítulo VIII: conclusiones y recomendaciones.
1.2. Objetivos
Objetivo General
Evaluación arquitectónica de una aplicación crítica en producción, así como la implementación de
un porcentaje de las propuestas de mejora realizadas una vez finalizado el proceso de evaluación.
Objetivos Específicos
ƒ
Utilización de la metodología Rupcorb como mecanismo principal para la documentación y
análisis de la arquitectura actual de Visual Banker. Empleo de Rupcorb para realizar el
diseño de la nueva arquitectura.
ƒ
Uso de las herramientas Rational de IBM para la elaboración de los artefactos necesarios
durante el desarrollo de la pasantía.
ƒ
2
Ejecución del método ATAM para llevar a cabo la evaluación arquitectónica de Visual Banker.
ƒ
Complementación del Método ATAM con el método Bosch para lograr la transformación de la
arquitectura.
ƒ
Generación del informe de evaluación y aplicación del método, además de recomendaciones
para mejorar la calidad.
ƒ
Implementación de un porcentaje de las propuestas para mejorar la calidad de la arquitectura
actual. Dicho porcentaje está sujeto a la disponibilidad de tiempo, recursos y participación de
otras áreas.
1.3. Justificación
Las necesidades actuales que tienen diferentes organizaciones implican la creación de grandes y
complejos sistemas de Software que le ayuden a alcanzar sus objetivos. Dichos sistemas suelen requerir
la combinación de diferentes tecnologías y plataformas de Hardware y Software para lograr un
funcionamiento que permita satisfacer todas las necesidades de la empresa. Esto ocasiona que se tenga
que prestar una gran atención y cuidado al diseño de la arquitectura bajo la cual se soportará el correcto
funcionamiento de los sistemas desarrollados.
Si una arquitectura de Software se encuentra deficiente en su concepto o diseño se tendrá
grandes posibilidades de poseer un sistema que no alcanza el total de los requerimientos establecidos
[Hernández, 2006]. Esto, indudablemente, generará un trabajo complicado para poder adaptar al sistema
a las necesidades para las cuales fue originalmente planteado o, peor aún, se tendrá el fracaso del
sistema de Software cuando el mismo se encuentre en operación.
Por esta razón, el proceso de evaluación arquitectónica es sumamente importante pues el mismo
permite conocer cómo se encuentra la arquitectura de un sistema en términos de las decisiones
arquitectónicas tomadas, y la influencia de las mismas sobre los atributos de calidad con los cuales debe
cumplir la aplicación. Esto nos lleva a una verdad fundamental sobre la evaluación arquitectónica:
“…si las decisiones arquitectónicas determinan los atributos de calidad del sistema, entonces es
posible evaluar las decisiones arquitectónicas con respecto a su impacto sobre dichos atributos…”
[Clements, Kazman, Klein, 2002]
3
La idea es verificar si las decisiones arquitectónicas tomadas en un momento determinado fueron
las correctas. En caso de que no sea así la evaluación permitirá hacer una propuesta que permita el
correcto funcionamiento del sistema garantizando el cumplimiento de todas las especificaciones
suplementarias. Una mala arquitectura puede llevar a un proyecto al fracaso ya que es posible que todos
los requerimientos de calidad queden insatisfechos. Una evaluación es útil para entender el sistema en
términos generales, y saber si este cumple con los requerimientos de calidad y comportamiento para los
cuales fue creado.
“…sin embargo, son pocos los profesionales que conocen lo que en realidad abarca este tema y
cómo debe diseñarse la arquitectura de un sistema de Software, lo cual se debe al desconocimiento
generalizado de esta importante etapa del ciclo de vida. Regularmente, se pasa de la especificación de
requerimientos a un diseño somero y a la codificación del sistema...” [Hernández, 2006].
Esto indica que durante el proceso de desarrollo hay que prestar mayor atención al diseño de la
arquitectura pues la misma forma las bases a través de las cuales se sustentará el resto de la aplicación.
Si las bases son débiles no se puede contar con una aplicación robusta que se adapte a las necesidades
de la organización que la implante.
El proceso de evaluación arquitectónica es fundamental para garantizar el correcto
funcionamiento de la aplicación, ya que el mismo no sólo permite identificar los elementos de la
arquitectura que poseen algún tipo de falla, sino que también permite definir una nueva arquitectura que
satisfaga las necesidades para las cuales fue concebido inicialmente el sistema. Es necesario recordar
que Visual Banker es una aplicación relativamente vieja y que no fue empleada una metodología
específica para su desarrollo. Posiblemente muchas de las decisiones tomadas en aquel momento ya
quedaron obsoletas; este proceso permite conocer cuáles son sus posibles fallas y proponer las mejoras
que se consideren pertinentes.
1.4. Alcance de la Pasantía
El desarrollo de la pasantía implica realizar, en primera instancia, un proceso de documentación
y análisis de la Arquitectura actual de Visual Banker en base a las diferentes vistas arquitectónicas. De
4
igual manera involucra la especificación de los requerimientos funcionales y no funcionales de la
aplicación, la descripción de los casos de uso y la definición de las metas arquitectónicas a las que da
soporte la misma. Para llevar a cabo estas actividades se emplea la metodología Rupcorb, recopilándose
toda la información necesaria a través de documentación ya existente, entrevistas con Stakeholders e
interacción directa con el sistema.
Una vez obtenida toda la información se produce la evaluación arquitectónica propiamente dicha,
realizando para ello los pasos correspondientes al método ATAM y complementándolo con el método
Bosch [Bosch, 2000]. Esta proceso comprende, entre otras cosas, la elaboración del Utility Tree y de los
ABAS para cada escenario planteado. A través de estos artefactos se documentan las decisiones
existentes dentro de la arquitectura actual y se realiza un análisis que permita elaborar las propuestas
para mejorarla.
Posteriormente se procede a documentar la arquitectura en aquellas partes afectadas como
consecuencia de los nuevos desarrollos y luego se realiza la implementación de un porcentaje de las
mejorar propuestas, sujeto a la disponibilidad de recursos, tiempo y prioridad otorgada por la gerencia.
Por último, se presentan las conclusiones y recomendaciones generales de la pasantía.
En términos generales, el resultado de la pasantía implica la documentación de la arquitectura de
la aplicación evaluada, las conclusiones y recomendaciones para la transformación (realizadas una vez
finalice el proceso de evaluación arquitectónica), documentación de la arquitectura propuesta, así como
la implementación de un porcentaje de las mejoras propuestas para la arquitectura actual de Visual
Banker.
1.5. Entorno Empresarial
Banesco es un grupo e institución financiera venezolana establecida en la ciudad de Caracas que
posee más de 400 agencias alrededor de todo el país. El banco es actualmente uno de los mayores
grupos bancarios de Venezuela (en competencia con otras instituciones financieras), que maneja además
una aseguradora y un sistema de banca privada, así como otros negocios menores.
Esta institución se convirtió en uno de los primeros bancos venezolanos de total capital nacional,
5
al surgir en el año 1977 con el nombre de Banco Agroindustrial Venezolano, nombre que mantiene hasta
el año 1987 cuando lo cambia por Banco Financiero. En el año 1992, luego de 2 años de haber cambiado
su nombre nuevamente a Bancentro, el banco es adquirido por la casa de bolsa Banesco propiedad de
su actual presidente, Juan Carlos Escotet, denominándose definitivamente Banesco.
Actualmente la institución es un banco universal luego de haberse fusionado con Banesco Fondo
de Activos Líquidos y Banesco Arrendamiento Financiero en el año 1997. Para el año 2002 el banco
adquiere su mayor importancia luego de concretar en conjunto con Unibanca una de las mayores
fusiones bancarias del país. Banesco, inspirado en los principios de Imaginación Creativa y Eficiencia que
siempre lo han caracterizado y con el afán de encontrar nuevos caminos que lo impulsen a vivir su Visión
y Misión, ha asumido el compromiso de vivir los Valores que lo constituyen, preservando la esencia de lo
que lo ha hecho exitoso. La misión de la organización es descrita por la misma de la siguiente manera:
”…somos una Organización de servicios financieros integrales, dedicada a conocer las
necesidades de nuestros clientes, y satisfacerles a través de relaciones basadas en confianza mutua,
facilidad de acceso y excelencia en calidad de servicio. Somos líderes en los sectores de Persona y
Comercio, combinando tradición e innovación, con el mejor talento humano y avanzada tecnología.
Estamos comprometidos a generar la mayor rentabilidad al accionista y bienestar a nuestra comunidad…”
[Banesco, 2006].
En la Figura 1.1 se presenta la organización general de Banesco. En el mismo se especifican los
representantes de los escalafones más altos definidos dentro de la organización.
Presidente de la Junta Directiva
Juan Carlos Escotet Rodríguez
Presidente Ejecutivo:
Luis Xavier Luján Puigbó
Consultor Jurídico y Representante Judicial:
Marco Tulio Ortega Vargas
Representante Judicial Suplente:
Directores:
ƒ Juan Carlos Escotet Rodríguez
ƒ Luis Xavier Luján Puigbó
ƒ Jorge Caraballo Rodríguez
ƒ María Josefina Fernández Maroño
ƒ Gonzalo Clemente Rincón
ƒ Salvador Cores González
María Milagros Briceño Ruiz
ƒ Fernando Crespo Suñer
Secretario de la Junta Directiva:
ƒ Nelson Becerra Méndez
Marco Tulio Ortega Vargas
ƒ Carlos Acosta López
ƒ Oswaldo Padrón Amaré
Figura 1.1: Directiva de la Organización [Banesco, 2006]
6
Sin embargo, es importante mencionar que el contexto de la pasantía se llevó a cabo
específicamente dentro de la Gerencia de Calidad en Informática la cual es liderizada por la Licenciada
Nora Rodríguez. Dicha gerencia de división forma parte de la Vicepresidencia Ejecutiva de Desarrollo de
Tecnología que está supervisada por el Sr. Juan Ignacio Uría. Esta área ha sido pionera en el proceso de
masificación de Rupcorb dentro del Banco y es la encargada de llevar los proyectos relacionados con
Evaluación Arquitectónica. En la Figura 1.2 se presenta la ubicación de la gerencia en la que fue
asignada la pasante dentro de la organización.
V.P.E. DE DESARROLLO DE TECNOLOGÍA
V.P. EJECUTIVA
DESARROLLLO DE
TECNOLOGÍA
J. I. URIA
V.P. AUTOM.
PROCESO,
CONTROL GESTION
GCIA. DIV. INTELIG.
DE
NEGOCIOS
GCIA DPTO
INFORMACION
EJECUTIVA
GCIA DPTO. CRM
ELIZABETH BARRIOS
GCIA. DPTO.
ADMINISTRACION
CALIDAD DE DATOS
V.P. SISTEMAS
FINANCIEROS
Y. W. NG
GCIA. DIV. CREDITO
Y
SEGURO
GCIA DPTO.
SEGUROS
L. MEZA
GCIA. DPTO
CREDITO
N. PEREZ
GCIA. DIV. CALIDAD
EN INFORMATICA
N. RODRIGUEZ
V.P. FIDEICOMISO,
FINANZAS
Y TESORERÍA
GCIA. DPTO AUTOM.
SERVICIO AL CLIENTE
M. CARRILLO
GCIA.DPTO AUTOM.
FIDEICOMISO
G. ABREU
GCIA.DPTO AUTOM.
PASIVO A PLAZO Y
M/E
GCIA.DPTO AUTOM.
MERCADO
CAPITALES
GCIA. DPTO.AUTM.
SERVIC.
CONTABILIDAD
GCIA.DPTO AUTM
J. GARCÍA
V.P. DE
AUTOMATIZACIÓN
DE TDC
GCIA. DIV.
EMISOR
J. LEGON
GCIA.DPTO
ADQUIRIENTE/
INTERCAMBIO
GCIA.DPTO AUTOM.
LPH,
IMPUESTOS
GCIA DPTO. AUTOM.
GCIA. DE DPTO.
ADMINISTRACION DE
BASE DE DATOS
Figura 1.2: Organigrama V.P.E Desarrollo de Tecnología [Banesco, 2006]
La segunda gerencia de la que se obtuvo apoyo se refiere a la gerencia de Plataforma, la cual se
encuentra liderizada por la Ing. Sara García. Ésta forma parte de la Vicepresidencia Ejecutiva de Banca
Electrónica y Soporte, así como de la Vicepresidencia de Administración de Plataforma. La relación con
esta área se produjo principalmente porque en la misma se tiene un amplio conocimiento sobre la
7
aplicación a la cual se le realizó la Evaluación Arquitectónica, pues muchos de los analistas que trabajan
allí formaron parte del grupo de desarrollo y actualmente dan soporte a la misma.
En la Figura 1.3 se presenta el organigrama que ubica al área de Plataforma dentro del contexto
general de la Vicepresidencia a la que pertenece y su relación con otras áreas del banco. Es posible
distinguirla observando el color rojo que la rodea.
V.P.E. DE BANCA ELECTRÓNICA Y SOPORTE TECNOLÓGICO
V.P. EJECUTIVA
BANCA ELECTRONICA Y
SOPORTE TECNOLOGICO
J. PERDOMO
V.P. BANCA
VIRTUAL
P. RAGO
GCIA. DPTO
BANCA VIRTUAL
V.P. AUTOM. DE
DOCUMENTOS
L. LECUONA
V.P. DE BANCA
ELECTRÓNICA
M. FLORES
V.P. SOPORTE,
REDES
Y ALTA DISPONIBI.
N. VAZQUEZ
GCIA DPTO.
AUTOM.
PROCESOS
COLABORATORI
OS
GCIA. DPTO
BANCA
ELECTRONICA.
GCIA. DPTO
SERV.
ALTA
SPONIBILIDAD
GCIA.DPTO.
INTERC. ELECT.
GCIA DPTO.
ADM. Y RRHH.
N. MAJETIC
GCIA.DPTO
AUTORIZA.Y
SOPORTE.
GCIA.DPTO
PRODUCTOS
GCIA. DPTO
GESTION
DIGITALIZ. DE
DOCUMENTOS
GCIA. DPTO
AUTOMATIZACI
ON
ATM / POS .
GCIA DPTO
REDES Y
MICRO.
GCIA DPTO
MANTENIMIENT
O.
GCIA DPTO
PLANIFICACION Y
CONTROL
V.P. DE
AD MINISTRACIÓN
DE PLATAFORMA
A. MARTINEZ
GCIA DIVISION
INFRAESTRUCTURA
DE SERVIDORES
GCIA . DPTO
SERV.
SERVIDORES
R. VERONESSE
GCIA DPTO ARQT.
OPERACIONES
PROYECTOS
GCIA. DPTO
DESARROLLO
PLATAFORMA
S. GARCÍA
GCIA. DPTO
SOPORTE
AGENCIAS
J. G. GARRIDO
GCIA DPTO
MENSAJERIA Y
GROUPWARE
Figura 1.3: Organigrama V.P.E Banca Electrónica y Soporte Tecnológico [Banesco, 2006]
Es importante destacar que las dos vicepresidencias ejecutivas a las cuales pertenecen las
gerencias con las que se trabajó durante el desarrollo de la pasantía, pertenecen a la Dirección Ejecutiva
de Tecnología y Procesos liderizada por el Sr. Nelson Becerra.
1.6. Planteamiento del Problema
Como parte del proyecto Masificación de la metodología Rupcorb para el año 2006, Banesco
planteó realizar la evaluación arquitectónica de diferentes aplicaciones críticas que ya se encuentran en
8
producción. La idea fundamental es analizar la arquitectura existente en cada una de ellas y comprobar si
la misma cumple con los requerimientos funcionales y no funcionales (calidad) para los cuales fue
concebida. Dicho proceso de evaluación se lleva a cabo a través del método ATAM, el cual permite de
alguna manera definir los puntos sensibles o de riesgo que se encuentran en la arquitectura actual,
además de definir aquellos elementos que pueden afectar a otros.
Actualmente la organización cuenta con un grupo de aplicaciones que son de gran importancia y
que se encuentran desarrolladas. Sin embargo, dicho desarrollo no fue realizado siguiendo una
metodología específica, por lo que muchas de las mejores prácticas no fueron tomadas en cuenta y
tampoco se realizaron los artefactos correspondientes que permitieran tener una documentación clara del
sistema. De la poca documentación que se elaboró, sin seguir ningún tipo de estándar, gran parte de ella
se perdió durante la mudanza.
A través de la metodología Rupcorb es posible lograr la documentación de la aplicación
seleccionada, con el fin de tener una base para realizar posteriormente la evaluación arquitectónica.
Para el banco es de gran importancia contar con un mecanismo a través del cual sea posible
evaluar las diferentas aplicaciones desarrolladas y validar que las mismas cumplen con los estándares de
calidad definidos por la organización.
Para el proyecto de pasantía se seleccionó la aplicación Visual Banker la cual es de tipo clienteservidor y fue desarrollada en el lenguaje de programación Visual Age for Smalltalk v.3.0. Esta aplicación
fue comprada por el Banco en el año 1996 para dar soporte a todas las agencias a nivel nacional y
actualmente es mantenida por el área de Plataforma. Una parte del desarrollo ha sido llevado a cabo por
los Analistas de dicha Gerencia. Sin embargo, nunca se ha realizado un análisis exhaustivo de la
aplicación que permita identificar los atributos de calidad que debe cumplir; por esta razón la misma fue
seleccionada como candidata para ser analizada a través de este proyecto.
9
CAPÍTULO 2 MARCO TEÓRICO
Este capítulo crea un contexto a través del cual sea posible comprender, de forma sencilla, de
que trata el proceso de evaluación arquitectónica así como el conjunto de elementos que componen a la
aplicación a la cual se le realizó dicha evaluación.
En primer lugar se presenta una breve descripción del proceso de evaluación, además de un
modelo conceptual que permite identificar y relacionar los conceptos más importantes mencionados
durante la explicación. Posteriormente se presenta el modelo conceptual de la aplicación con su
respectiva descripción.
2.1. Dominio del Problema
La evaluación arquitectónica es un mecanismo que permite identificar en las etapas tempranas
del desarrollo de todo sistema aspectos de la arquitectura de Software que no están bien definidos o que
pueden ocasionar inconvenientes a posteriori. Sin embargo, es importante destacar que este mecanismo
no se emplea únicamente en aquellos sistemas que aún no han sido desarrollados, pues también es
perfectamente aplicable a aquellos sistemas que ya se encuentran en producción. Más aún, existen dos
momentos claramente identificados en los cuales es posible realizar una evaluación arquitectónica, estos
momentos son: temprano y tarde. Se realiza una evaluación arquitectónica temprana cuando la
arquitectura no está completamente especificada, mientras que la evaluación tardía toma lugar cuando la
arquitectura está completamente definida y la implementación ya ha sido realizada.
La motivación principal para realizar una evaluación arquitectónica a un sistema ya desarrollado
se basa principalmente en la necesidad de conocer cuáles elementos de la arquitectura no están
funcionando correctamente, qué parámetros de calidad y requerimientos no se están cumpliendo y qué
puede mejorarse dentro del sistema. De igual manera, este procedimiento permite que los nuevos
usuarios o dueños de la aplicación comprendan perfectamente el funcionamiento del sistema y sus
posibles debilidades.
Como su nombre lo indica, la evaluación arquitectónica se realiza sobre una arquitectura
específica, entendiéndose por arquitectura aquel elemento que describe todos los componentes y la
10
estructura del sistema, así como la relación que existe entre los mismos. La arquitectura de Software
también se podría considerar como una vía de comunicación entre los Stakeholders (a través de un
lenguaje común que todos pueden hablar y entender), una manifestación de las primeras decisiones de
diseño o simplemente una abstracción del sistema que no refleja información específica. En términos más
generales, la arquitectura de Software de un sistema o programa se define como:
“…la estructura o estructuras del sistema, que comprenden elementos de Software, las
propiedades visibles desde afuera de dichos componentes y las relaciones existentes entre ellos…”
[Bass, Kazman, Clementes, 2003]
Según la IEEE 1471-2000 la arquitectura de Software no es más que “…la organización
fundamental de un sistema encarnada en sus componentes, las relaciones entre ellos y el ambiente y los
principios que orientan su diseño y evolución…” [IEEE Std 1471-2000].
Como se muestra en la definición anterior, una estructura de Software comprende ciertos
componentes así como la relación entre los mismos. Dichos componentes se podrían considerar como
los bloques de construcción que conforman las partes de un sistema de Software [Camacho, Cardeso,
Nuñez, 2004], mientras que la relación o relaciones, se refieren a la conexión entre esos componentes.
Sin embargo es importante aclarar que existe un tercer concepto fundamental en esta definición, que es
el de conectores, ya que es a través de ellos se concretan las relaciones.
Volviendo al punto en el que se indicaba que una arquitectura de Software podría ser
considerada un canal de comunicación entre todas las personas involucradas con el proyecto e
interesadas en el éxito del mismo (Stakeholders), es que surge el concepto de vista. Una vista no es
más que un plano específico del proyecto que permite separar conceptos y considerar a la arquitectura
desde diferentes perspectivas. Como el grupo de participantes puede ser muy variado, cada uno de ellos
va a querer concentrarse en sus propios objetivos. Por ejemplo, el usuario va a querer un sistema fácil de
usar y rico en funcionalidad, mientras que el desarrollador va a querer un sistema fácil de construir.
Las vistas arquitectónicas de alguna manera facilitan el trabajo al permitir que cada especialista
se enfoque en una vista determinada para alcanzar ciertos objetivos; siempre y cuando no se descuiden
el resto de vistas existentes que también forman parte del sistema y que deben ser consultadas y
11
tomadas en cuenta durante la evaluación y desarrollo del mismo.
Las vistas arquitectónicas más
comunes son [Clements, Kazman, Klein, 2002]:
ƒ
Vista Funcional: se presenta una abstracción de las funciones del sistema y la relación entre
ellas.
ƒ
Vista de Concurrencia: en el caso de sistemas complejos, se suelen dividir en hilos o
procesos. Esta vista provee el razonamiento necesario para poder identificar que hilos o
procesos van a ser creados y como se van a comunicar.
ƒ
Vista de Código: es la vista empleada por el programador, sus componentes son
fundamentalmente clases, objetos, procedimientos, funciones, etc.
ƒ
Vista de Desarrollo: es una estructura del código fuente como un repositorio que varios
usuarios crean, modifican y manipulan. Sus componentes son archivos y directorios.
ƒ
Vista Física: construcción del sistema en términos de los elementos de Hardware, CPU,
sensores, etc.
La descripción arquitectónica es sumamente importante pues como fue mencionado
anteriormente, la misma permite que todos los Stakeholders se mantengan comunicados; lo cual se
convierte en un aspecto fundamental para lograr el éxito de la arquitectura. Por ésta razón, se han
realizado grandes esfuerzos para diseñar lenguajes específicos que puedan dar soporte a estas tareas.
Estos lenguajes se conocen con el nombre de ADL´s (Architectural Description Languages) y han
tenido sus éxitos, así como sus fracasos. El éxito se ha visto reflejado principalmente en el uso que se le
ha dado tanto en ambientes académicos como en proyectos del mundo real. Cada uno de estos
lenguajes se ha concentrado en una faceta diferente de la descripción arquitectónica. Sin embargo, el
fracaso de los mismos se ha dado por el hecho de que ninguno ha sido ampliamente adoptado.
Por ser la arquitectura un producto de las decisiones tempranas de diseño, su efecto sobre el
sistema o proyecto son profundas. La misma determina algunos de los atributos de calidad del sistema,
los cuales se definen como las propiedades de un servicio que presta el sistema a sus usuarios
[Barbacci, 95]. Algunos de estos atributos se refieren específicamente a aspectos como disponibilidad,
12
confidencialidad, funcionalidad, desempeño, seguridad, mantenibilidad, portabilidad, etc. Sin embargo,
existen otra serie de atributos, como la usabilidad, que se mantienen al margen de la arquitectura y
pueden ser afectados por otros elementos. Como las decisiones arquitectónicas condicionan los atributos
de calidad del sistema, entonces es posible enfocar la evaluación arquitectónica hacia el impacto que
dichas decisiones ejercen sobre los atributos de calidad. Aquí radica la importancia de la evaluación
arquitectónica, pues ella permitirá saber para que conjunto de objetivos arquitectónicos la arquitectura
planteada es conveniente y para que otro conjunto la misma es problemática. De igual manera, permite
tener en cuenta que alguno de estos objetivos puede estar en conflicto con otros e incluso que alguno de
ellos va a ser más importante que otro(s).
Los atributos de calidad forman la base para la evaluación arquitectónica, pero nombrarlos o
especificarlos no es suficiente para juzgar una arquitectura, puesto que estos no constituyen cantidades
absolutas sino que tienen sentido en un contexto determinado y con objetivos específicos. Además, en la
mayoría de los casos los requerimientos de calidad se expresan de forma ambigua e incluso incompleta,
muchas veces la documentación correspondiente a dichos requerimientos ni siquiera es escrita. En ese
sentido se hace necesario preguntar por parte del equipo evaluador, a los Stakeholders, cuales son esos
requerimientos y que se quiere alcanzar con cada uno de ellos. Uno de los mecanismos a través del cual
se logra realizar el levantamiento de información es el de los escenarios.
Los escenarios pueden ser considerados como una pequeña oración que describe la interacción
entre alguno de los Stakeholders con el sistema, dirigiéndose al mismo tiempo hacia un atributo de
calidad específico. También pueden ser vistos como el equivalente no funcional de los casos de uso.
Cada uno de ellos presenta tres partes fundamentales denominadas estímulo (qué ocasiona que se
produzca el escenario), ambiente (condiciones existentes en el momento en el que se produce) y
respuesta (resultado de la ocurrencia del escenario). De igual manera, es importante destacar que
existen varios tipos de escenarios, los mismos son: escenarios de casos de uso, escenarios de
crecimiento y escenarios exploratorios. En las secciones siguientes se hablará de este concepto en
forma más detallada.
13
Como se especificó anteriormente, los atributos de calidad por si solos no son suficientes para
realizar la evaluación arquitectónica de algún sistema, es por esta razón que se emplean ciertos métodos
de evaluación arquitectónica que hacen uso de los atributos de calidad, pero que se conforman de otra
serie de pasos que complementan el proceso. Gracias a los mismos es que la evaluación arquitectónica
se ha convertido en un paso estándar dentro de cualquier paradigma de desarrollo [Clements, Kazman,
Klein, 2002]. Los métodos principales son Architecture Tradeoff Analysis Method (ATAM), Software
Architecture Analysis Method (SAAM) y Active Reviews for Intermediate Designs (ARID). Para el caso de
estudio planteado el método utilizado es ATAM.
Estos conjunto de métodos poseen características en común, por ejemplo el hecho de trazar un
mapa de accesos a atributos de calidad, así como identificar el conjunto de riesgos (decisiones
arquitectónicas potencialmente problemáticas) y no riesgos (decisiones correctas) dentro de la
arquitectura. Sin embargo, existen ciertos aspectos que solo son considerados dentro del método ATAM
propiamente dicho; esto se refiere a los puntos de sensibilidad y de Tradeoff. Los puntos de sensibilidad
pueden ser definidos como una propiedad de uno o más componentes que son consideradas críticas
para alcanzar una respuesta de un atributo de calidad particular, son aquellos aspectos que se pueden
convertir en riesgos. Mientras que los puntos de Tradeoff son propiedades que afectan a más de un
atributo y que representan un punto de sensibilidad para más de uno de ellos.
Otro de los elementos importantes generados durante el desarrollo del método ATAM, se refiere
al Utility Tree o árbol de utilidad. En el mismo se especifican los diferentes atributos de calidad que van a
ser evaluados dentro de la aplicación y se proponen diferentes escenarios que de alguna manera reflejen
como se comporta el sistema en cada uno de los casos. Una vez especificados los escenarios
correspondientes se realiza un ABAS (Attribute Based Architectural Style) para cada uno de ellos.
En las secciones siguientes se hablará de forma más detallada sobre el método ATAM,
empleado durante la evaluación arquitectónica de Visual Banker, así como de ciertos conceptos
importantes relacionados con el mismo y las razones que impulsaron a su uso.
Por último, es importante señalar cuáles son los beneficios y los costos principales de realizar
una evaluación arquitectónica. El principal y más obvio beneficio es que es posible descubrir ciertos
14
problemas o inconvenientes que de ser descubiertos posteriormente, sería muchísimo más costoso de
corregir o resolver. Esto significa de alguna manera que la evaluación arquitectónica permite construir
arquitecturas mucho mejores en términos de calidad [Clements, Kazman, Klein, 2002]. Existe otro grupo
de beneficios que usualmente son observados durante la evaluación arquitectónica. Según Clements,
Kazman y Klein estos son:
ƒ
Permite que el conjunto de Stakeholders se reúnan en un mismo lugar y se conozcan unos
a otros. De esta manera es posible que entre ellos se expliquen sus objetivos y motivaciones
de forma que logren entenderse a pesar de estar ubicados en diferentes perspectivas.
ƒ
Permite que se definan los objetivos a satisfacer en cuanto a los atributos de calidad o
evaluar a los ya existentes. Los escenarios proveen ciertas pruebas patrón para evaluar a los
mismos.
ƒ
Permite priorizar los objetivos que se encuentran en conflicto. Si por alguna razón, el
arquitecto no puede satisfacer todos los objetivos conflictivos, podrá recibir una guía clara por
parte de los Stakeholders que le permita identificar cuáles son considerados más
importantes.
ƒ
Permite obtener una clara explicación sobre la arquitectura, pues el arquitecto está en la
obligación de explicar la misma al resto del grupo de trabajo.
ƒ
Se mejora la calidad de la documentación arquitectónica, la cual muchas veces es
necesitada y ni siquiera existe.
Es importante destacar que existe la posibilidad de que todos estos beneficios no apliquen para
todos los casos. Por ejemplo, si se trata de una empresa pequeña es factible que los Stakeholders se
conozcan previamente. En lo que respecta a los costos, para el caso de evaluación arquitectónica los
costos principales se encuentran relacionados con gastos en el personal y oportunidades del grupo de
trabajo que va a participar en el proceso de evaluación.
En la Figura 2.1 se pretende agrupar y relacionar al conjunto de conceptos que fueron
desarrollados en la sección anterior, permitiendo de esta manera que se observe de forma más clara la
15
asociación e interacción existente entre los mismos.
Algunos de los conceptos allí reflejados son desarrollados con más detalle en las secciones
posteriores debido a la importancia que los mismos poseen para el desarrollo de la pasantía.
COMPONENTES
CONECTORES
RELACIONES
ATRIBUTOS
DE CALIDAD
permiten
generar
determina
ARQUITECTURA
DE SOFTWARE
UTILITY TREE
posee
relacionada con
VISTAS
ADL’s
ESTILOS
ARQUITECTÓNICOS
se definen
utilizan
se realiza
sobre
STAKEHOLDERS
ESCENARIOS
EVALUACIÓN
ARQUITECTÓNICA
se produce
participan
en
EQUIPO EVALUADOR
RIESGOS/
NO RIESGOS
realiza
emplea
TRADEOFF
ABAS
PUNTOS DE
SENSIBILIDAD
MÉTODOS
determina
SCENARIOS
BRAINSTORMING
ATAM
SAAM
ARID
Figura 2.1: Dominio del Problema
2.2. Dominio de la Aplicación
La aplicación Visual Banker fue adquirida por la organización en el año 1996, con el objetivo
principal de dar soporte a las operaciones que se realizan diariamente dentro de todas las agencias
bancarias pertenecientes a Banesco. En un principio fue concebida como un framework que fue
desarrollado conjuntamente entre personal interno y personal de otra compañía a la cual se le pagó por
sus servicios. Posteriormente la aplicación fue adaptada a las necesidades que la organización
presentaba para el momento en el que fue implantada en las agencias y actualmente la Gerencia de
16
Plataforma le da el mantenimiento respectivo.
Visual Banker es una aplicación cliente-servidor desarrollada en un lenguaje orientado a objetos
denominado Visual Age for Smalltalk v3.0. La misma posee una estructura modular, lo que permite que
dichos módulos engloben funcionalidades específicas dentro de la aplicación.
Sus dos principales fuertes lo constituyen los módulos de Taquilla y Plataforma, pues es a través
de ellos que se realizan las transacciones relacionadas con
pago de cheques, retiros, depósitos,
traspasos, tarjetas de créditos, pago a proveedores, pago de servicios, cheques de gerencia,
pensionados, manejo de personas naturales y jurídicas, venta de productos, registro de nuevos clientes,
digitalización de firmas, entre otras. Dichos módulos son empleados por los cajeros y por los promotores
respectivamente; aunque los promotores tienen acceso en cualquier momento a las opciones ofrecidas
por el módulo de Taquilla, pero no al contrario.
Existe un tercer módulo denominado Mantenimiento, el cual es manipulado por un administrador.
A través del mismo es posible realizar todo el manejo de usuarios de la aplicación y de la base de datos
local (por agencia). Es en esta parte de la aplicación donde se especifican los permisos de cada uno de
los perfiles, en cuanto a nivel de acceso y tipo de transacciones que puede realizar.
El sistema como un todo se compone, aparte de la aplicación propiamente dicha, por ciertos
elementos de Software (Sw) y Hardware (Hw) que contribuyen y complementan la funcionalidad que el
mismo provee.
En lo que corresponde al Sw, la base de datos utilizada en la red de agencias es DB/2 de IBM
versión 2.1.2. Esta base de datos no contiene información personal de los clientes ni de sus productos en
el banco; en ella simplemente se almacena la información de uso local correspondiente a los perfiles de
los usuarios y sus claves, operaciones contenidas en el Jornal y últimas impresiones y transacciones
realizadas por la agencia. Es importante destacar que se trata de una Base de Datos transaccional en la
que todos los datos relevantes no son almacenados en forma local sino en el servidor principal (AS400)
que se encuentra ubicado en la sede de Bello Monte (Caracas). En total se cuenta con 134 tablas dentro
de la BD. Por otra parte, el Sistema de Operación que se tiene en los servidores es OS/2 Warp for ebussines de IBM versión 4.5, mientras que en las estaciones de trabajo se tiene OS/2 Warp 4.0
17
Workstation de IBM y Fixes 5, 13 y 15. También existe Software relacionado con otras aplicaciones que
trabajan en conjunto con Visual Banker, estas son Lotus Notes Server 4.5 y Cliente 4.5.2, Emulación
Personal Comunications 4.5, Comunications Manager 6 e IBM Browser 2.0.
En lo que corresponde al Hw se cuenta tanto con servidores como con dispositivos y equipos que
se encuentran distribuidos en todas las agencias bancarias a lo largo y ancho del país. Un 60 % de los
servidores son Netfinity 5600 y 5100 con Pentium 3 de 750 mhz o inferior; un 30 % son Netfinity 5000 y
un 10% son PC Server 330 con Pentium 1 y Netfinity 3500 Pentium 3. Los dispositivos con los que se
cuenta son principalmente validadoras e impresoras láser. En taquilla se tienen equipos que varían desde
Pentium 1 de 166 mhz (aprox. 65%) hasta Pentium 3 de 1 Ghz (35%), mientras que en plataforma se
cuenta con Pentium 1 de 166 mhz (10%), Pentium 2 y 3 menores a 350 mhz (35%) hasta Pentium 3
mayores a 750 mhz (55%). Si se desea obtener mayor información sobre la distribución física de todos
los equipos y dispositivos, véase la Vista de Implantación contenida en el Documento de Arquitectura de
Software de Visual Banker (APÉNDICE B).
El mecanismo a través del cual se comunican los elementos que conforman al sistema, está
constituido por los protocolos de comunicación. Para comunicar los módulos de plataforma y taquilla se
emplea un protocolo denominado SNA/APPC, el cual ofrece ciertos niveles de seguridad al trabajar con
códigos de página (no es encriptamiento propiamente dicho pero garantiza cierta confidencialidad). El
protocolo TCP/IP se emplea para las aplicaciones Lotus Notes, Emulación y Tivoli. Por último se emplea
NetBios para compartir recursos como directorios e impresoras. Es importante destacar que 50% de las
agencias trabajan con un mínimo de ancho de banda de 64 kbps, mientras que el 50% restante han sido
migradas a 128 kbps.
En la figura 2.2 se presentan los diferentes elementos que componen a la aplicación, así como la
relación existente entre los mismos.
18
TRANSACCIONES
manejada por
SISTEMA DE
OPERACIÓN
PROTOCOLO DE
COMUNICACIÓN
BASE DE DATOS
SOFTWARE
comunica
posee
HARDWARE
tiene
VISUAL BANKER
(FRAMEWORK)
se compone de
DISPOSITIVOS
MÓDULOS
MANTENIMIENTO
TAQUILLA
EQUIPOS
SERVIDOR
PLATAFORMA
Figura 2.2: Modelo Conceptual de la Aplicación
El diagrama conceptual presentado solo engloba los conceptos relevantes, omitiendo de esta
manera cualquier información sumamente detallada. Como se aprecia en la figura anterior, el sistema se
compone principalmente de tres módulos. Por considerarse de gran importancia será presentado un
modelo conceptual que permita comprender de forma más detallada cuál es la composición de cada uno.
El primer módulo que se presenta es el de Plataforma y puede ser observado en la Figura 2.3. En
este módulo se realizan las transacciones relacionadas con registro de nuevos clientes, venta de
productos a los mismos, captura de firmas, uso de calculadoras especiales, etc. Además es posible
manejar desde este punto toda la información relacionada con cualquiera de los clientes, información que
va desde los datos demográficos, pasando por el conjunto de productos que la persona tiene con la
institución financiera y por los datos de las sesiones que se han realizado con el mismo en cualquiera de
las agencias. Para ver mayor información sobre el conjunto de operación que pueden ser llevadas a cabo
a través de dicho módulo véase el DAS de Visual Banker (APÉNDICE B).
19
maneja
manejada
por
PLATAFORMA
CATÁLOGO DE
PRODUCTOS
PROMOTOR
PLANES
utiliza
CALCULADORA DE
AHORRO
utiliza
contiene
atiende
CALCULADORA DE
F. DE VENC.
utiliza
TARJETAS
CERTIFICADOS
MATRIZ DE
SELECCIÓN DE P.
compra
CLIENTES
DATOS
DEMOGRÁFICOS
PRODUCTOS
CUENTAS
posee
SEGUROS
CARPETA
FINACIERA
FICHA
MONEDA
EXTRANJERA
RESUMEN
BANESCO
SERVICIOS
Figura 2.3: Modelo Conceptual - Módulo de Plataforma
El segundo módulo de la aplicación se denomina Mantenimiento (Figura 2.4). El mismo es
manejado por un administrador que se encarga de definir a todos los usuarios que pueden tener acceso a
la aplicación, con sus respectivos perfiles. Para ver más información véase el DAS de Visual Banker
(APÉNDICE B).
manejado
por
MANTENIMIENTO
ADMINISTRADOR
define
USUARIOS
posee
PERFILES
Figura 2.4: Modelo Conceptual - Módulo de Mantenimiento
20
El tercer módulo perteneciente a la aplicación se denomina Taquilla (Figura 2.5). En el mismo es
posible ejecutar todas las transacciones relacionadas con depósitos, retiros, traspasos, pago de servicios,
cheques de gerencia, etc. Este módulo es manejado por un taquillero, que es la persona encargada de
atender a los clientes. Para ver mayor información véase el DAS de Visual Banker (APÉNDICE B).
manejado
por
TAQUILLA
atiende
TAQUILLERO
CLIENTE
TRASPASOS
maneja
PAGO DE
IMPUESTOS
controlan
TRANSACCIONES
PAGO DE PROM.
OPCIONES
PAGO DE
PROVEEDORES
PENSIONADOS
IVSS
RETIROS
TARJETAS DE
CRÉDITO
CHEQUES
RECIBIDOS
AHORRO
HABITACIONAL
REVERSO
GENERAL DE T.
CONSULTAS Y
MOVIMIENTOS
BLOQUOS Y
DIFERIDOS
DEPÓSITOS
EMISIÓN DE
CHEQUES DE G.
PAGO DE
SERVICIOS
TOTALES
NOTAS
MÚLTIPLES.
PAGO DE
CHEQUES
Figura 2.5: Modelo Conceptual - Módulo de Taquilla
21
CAPÍTULO 3 MARCO METODOLÓGICO
En este capítulo se da una aproximación de las metodologías y métodos empleados durante la
realización de la evaluación arquitectónica. Para ello se presenta una breve introducción sobre los
conceptos más relevantes de la metodología Rupcorb, empleada principalmente para el proceso de
comprensión, documentación y propuesta de la arquitectura; además del método ATAM, empleado para
el proceso de evaluación arquitectónica propiamente dicho.
En los siguientes capítulos se explica qué partes de cada uno fueron consideradas dentro de la
pasantía, así como los resultados obtenidos en cada caso.
3.1. Aspectos Metodológicos - Resumen Rupcorb
Durante el desarrollo de la pasantía se utilizó la metodología Rupcorb como un mecanismo que
permitió alcanzar varios de los objetivos planteados. Dicha metodología no es más que la conocida
metodología RUP (Rational Unified Process) pero adaptada a la organización en la cual fue realizada la
evaluación arquitectónica. Ésta se encuentra compuesta por las mismas fases, actividades, Workflows y
artefactos presentes en la metodología original.
En términos más específicos el Proceso Racional Unificado Corporativo Banesco o Rupcorb es
un proceso de desarrollo de Software que junto con el Lenguaje Unificado de Modelado UML, constituye
la metodología estándar más utilizada para el desarrollo de sistemas orientados a objetos. Esta
metodología se caracteriza por ser iterativa e incremental, además de estar centrada en la arquitectura y
guiada por los casos de uso. A través de la misma, se busca cumplir con las mejores prácticas de
Ingeniería de Software definidas como: desarrollo iterativo, administración de requerimientos, uso de
arquitectura basada en componentes, control de cambios, modelado visual del Software y verificación
continua de la calidad de Software.
La ventaja que tiene esta metodología es que se trata de un proceso de Software genérico que
puede ser utilizado para una gran cantidad de tipos de sistemas, para diferentes áreas de aplicación,
diferentes tipos de organizaciones, diferentes niveles de competencia y diferentes tamaños de proyectos.
22
Existen ciertos conceptos importantes que se manejan dentro de Rupcorb, dichos conceptos se
refieren a los Artefactos, Roles, Actividades y Workflows. Los artefactos representan los productos
tangibles del proceso, mientras que los roles se refieren al papel que desempeña una persona en un
determinado momento. Por su parte una actividad se refiere a una unidad de trabajo que puede pedirse
que desarrolle un rol [RUP® Glossary, 2003] y un workflow a una secuencia de actividades
desarrolladas en un negocio que producen un resultado de valor observable a un actor individual del
negocio [RUP® Glossary, 2003]. De igual manera, es importante destacar que la metodología posee 4
fases claramente identificadas y definidas, estas son:
Inicio: esta fase tiene como propósito definir y acordar el alcance del proyecto con los
Stakeholders, identificar los riesgos asociados al proyecto, proponer una visión muy general de la
arquitectura de Software y producir el plan de las fases y el de iteraciones. Se hace un plan de fases,
identificándose los principales casos de uso y riesgos. A partir del modelo de casos de uso y de la lista de
riesgos, se puede determinar qué casos de uso deben implementarse primero para atacar los riesgos de
mayor exposición. El plan de pruebas puede planearse en esta fase, ejecutarse desde la primera
iteración de la fase de elaboración y refinarse sucesivamente durante el ciclo de vida del proyecto.
Elaboración: los casos de uso seleccionados para desarrollarse en esta fase permiten definir la
arquitectura del sistema. En esta etapa se realiza la especificación de los casos de uso seleccionados y
el primer análisis del dominio del problema, se diseña la solución preliminar del problema y comienza la
ejecución del plan de manejo de riesgos, según las prioridades definidas en él. Al finalizar esta fase se
determina si se puede continuar con el desarrollo del proyecto, de ser afirmativa la respuesta se
describen los planes de trabajo de las etapas de construcción y transición.
Construcción: se concentra en la elaboración de un producto totalmente operativo y eficiente y
el manual de usuario. El propósito fundamental de esta fase es completar la funcionalidad del sistema,
clarificando los requerimientos pendientes, realizando cambios a los artefactos construidos y ejecutando
el plan de administración de recursos y mejoras en el proceso de desarrollo para el proyecto.
Transición: se implementa el producto en el cliente y se entrena a los usuarios. Como
consecuencia de esto suelen surgir nuevos requerimientos a ser analizados. El propósito de esta fase es
23
asegurar que el Software esté disponible para los usuarios finales, ajustar los errores y defectos
encontrados, capacitar a los usuarios y proveer el soporte técnico necesario.
Las fases presentadas anteriormente se dividen en iteraciones, cada una de las cuales produce
una pieza de Software demostrable. La duración de cada iteración puede extenderse desde dos
semanas hasta seis meses [Rupcorb, 2004]. A través de las fases se desarrollan en paralelo nueve
Workflows o disciplinas denominadas: Modelado de Negocios, Requerimientos, Análisis & Diseño,
Implementación, Prueba, Implantación, Gerencia de Configuración & Cambio, Gerencia de Proyectos y
Ambiente.
En la Figura 3.1 es posible identificar cada uno de los Workflows presentes en la metodología,
así como las fases que la caracterizan. El eje horizontal representa tiempo y demuestra los aspectos del
ciclo de vida del proceso que revela.
Figura 3.1: Fases de Rupcorb [Banesco, Rupcorb]
Un punto perfectamente aplicable en esta oportunidad es el hecho de que muchas personas
creen que este tipo de metodología sirve únicamente para el desarrollo de sistemas desde cero y que no
puede ser empleada en el caso de sistemas que ya se encuentran en producción. Como muy bien lo
explica Philippe Kruchten en su artículo “Using the RUP to evolve a legacy system” se tiene que:
24
“…algunas personas consideran que el proceso racional unificado (RUP) es sólo útil para el
desarrollo de sistemas nuevos o aplicaciones desarrolladas desde cero. Ellos afirman que esta
metodología no puede ser utilizada para el desarrollo o evolución de sistemas que ya se encuentran en
producción. Estoy en total desacuerdo: sé que grandes partes de RUP pueden ser usadas para
evolucionar sistemas existentes. En realidad, aproximadamente el 80 por ciento de los sitios donde el
RUP es usado hoy, incluye alguna forma ya de producción…” [Kruchten, 2003].
Esta afirmación de alguna manera apoya el hecho de que la metodología es perfectamente
aplicable en el caso de sistemas ya existentes, utilizándola como un mecanismo para aplicar ingeniería
de reverso, como ocurre en esta oportunidad específicamente con la aplicación con la que se trabajó, .
De esta manera, la metodología permitió formar una base sólida a partir de la cual se realizó la
evaluación arquitectónica de la aplicación, pues sin la documentación arrojada por Rupcorb, hubiese sido
muy difícil tener una clara comprensión y conocimiento de los diferentes elementos que componen al
sistema. Este proceso facilitó tanto la identificación de posibles fallas como la propuesta de mejoras y
cambios dentro de la aplicación.
En términos generales la organización adoptó este marco metodológico principalmente para:
ƒ
Contribuir a mejorar la calidad de los productos tecnológicos sobre la cual se soporta
Banesco.
ƒ
Mejorar los tiempos de entrega de nuevos productos y servicios a sus clientes.
ƒ
Capitalizar y resguardar el conocimiento en Banesco.
ƒ
Ayudar a planificar y ejecutar los proyectos a tiempo y ajustados a presupuesto. Esto
garantiza el éxito y por lo tanto genera mayores ventajas competitivas que permiten ganar
nuevas oportunidades de negocios.
ƒ
Incrementar la productividad evitando el retrabajo, fortalecer la cultura corporativa y mejorar
la sinergia entre los integrantes de los equipos de proyectos por la distribución de tareas de
acuerdo a los perfiles de cada quien, entre otros.
25
Toda esta información fue tomada de la Intranet de la Organización. Por último, es importante
destacar que Banesco posee todas las licencias necesarias para poder hacer uso de las diferentes
herramientas Rational provistas por IBM para la elaboración de artefactos, diagramas, etc.; además de
contarse con las plantillas e información necesaria sobre la metodología Rupcorb. Esto contribuyó en
gran medida a alcanzar los objetivos planteados en cada una de las fases.
Es importante destacar que el método ATAM de alguna manera requiere que tener la
documentación de la aplicación. Sin embargo, éste no precisa como debe documentarse la arquitectura,
por lo que en esta oportunidad se escogió la metodología Rupcorb, pues es la metodología definida
dentro de la empresa.
3.2. Aspectos Metodológicos - Resumen ATAM
Como fue mencionado anteriormente, ATAM (Architecture Tradeoff Análisis Method) es uno de
los métodos a través del cual es posible realizar la evaluación arquitectónica de sistemas. Como su
nombre lo indica su función no sólo es especificar que tan bien una arquitectura satisface ciertos atributos
de calidad, sino también especificar cuáles de esos atributos de calidad interactúan con otros. Esto es
posible a través de lo que se conoce como los puntos de Tradeoff o negociación, los cuales fueron
definidos previamente como aquellas propiedades que afectan a más de un atributo, convirtiéndose en un
punto de sensibilidad para más de uno de ellos. Tanto los puntos de sensibilidad como los de
negociación son característicos de ATAM y no se presentan en ningún otro método. Esto se convierte en
una ventaja pues al momento de realizar la evaluación se toma en cuenta y se analiza como una decisión
arquitectónica puede beneficiar a cierta característica y perjudicar a otra, lo que va a permitir decidir entre
diferentes opciones y preferir aquella que de alguna manera no afecte a un atributo de calidad prioritario.
Durante el proceso de evaluación arquitectónica se empleó ATAM .La decisión se tomó contando
con la ayuda y opinión de la Prof. Anna Griman (LISI) quien ha tenido experiencia en el empleo de éste
método como mecanismo para realizar evaluaciones arquitectónicas, obteniendo buenos resultados.
Lo más común es que la evaluación se realice en sistemas que aún no han sido desarrollados;
sin embargo, ATAM también puede ser empleado para analizar sistemas que ya han sido implementados
26
y puestos en producción, como es el caso de Visual Banker. Esta necesidad surge principalmente cuando
el sistema a evaluar requiere de ciertas modificaciones como: integración con otros sistemas o
aplicaciones, evolución, migración u otro tipo de cambio que sea considerado como importante. Es
necesario mencionar que uno de los proyectos planteados para este año dentro del área de Plataforma
se trata de la migración de Visual Banker a otra plataforma de Software completamente diferente.
Aplicando este método es posible identificar aquellos elementos de la arquitectura que no se encuentran
bien definidos en la actualidad y que deben ser mejorados cuando se produzca la migración, pues aplicar
ATAM se traduce en una mayor comprensión de los atributos de calidad del sistema [Kazman, 98].
A continuación se presentan los pasos que conforman el método, así como la explicación de las
actividades y productos que deben generase en cada uno de ellos [Kazman, 98].
Paso 1. Presentar el método ATAM: en este paso se describe el método a todos los participantes de la
evaluación arquitectónica, dando respuesta a las posibles dudas existentes.
Paso 2. Presentar las reglas del Negocio del Proyecto: se especifican las reglas del negocio o drivers
arquitectónicos que esperan ser alcanzados o soportados a través de la aplicación.
Paso 3. Presentar la Arquitectura: el arquitecto presenta la arquitectura de la aplicación, enfocándose
principalmente en aquellos elementos que soportan las reglas del negocio.
Paso 4. Identificar las propuestas de la Arquitectura: se identifican las propuestas arquitectónicas que
se encuentran actualmente dentro de la arquitectura. Las mismas son capturadas sin ser analizadas.
Paso 5. Generar el árbol de atributos de calidad (Utility Tree): elaboración del UT correspondiente a la
aplicación, con la definición de cada uno de los escenarios por atributos.
Paso 6. Analizar las propuestas de la Arquitectura: se analizan los escenarios propuestos,
identificando los puntos de sensibilidad, Tradeoff, riesgos, no-riesgos y decisiones arquitectónicas a
través de los ABASs (Attribute Based Architectural Styles). Se realizan las nuevas propuestas
arquitectónicas.
Paso 7. Tormenta de ideas y priorización de los escenarios: priorización de los escenarios propuestos
en el UT, por parte de todos los Stakeholders. Si se descubren nuevos escenarios guía estos también
27
son una salida importante y deben ser considerados.
Paso 8. Analizar las propuestas de la Arquitectura: se realiza una revisión de los escenarios (como en
el paso 6) pero considerando principalmente aquellos que poseen una gran importancia después de
haber sido priorizados. Como este es un paso de prueba, se espera que poca información sea
descubierta.
Paso 9. Presentar los resultados: en base a toda la información recolectada durante el proceso de
evaluación se presentan los resultados y problemas encontrados en la arquitectura a los Stakeholders.
En esta presentación el líder de la evaluación recapitula los pasos del ATAM y toda la información
recogida en cada paso, incluyendo el contexto del negocio, los requerimientos guías, las restricciones, y
la arquitectura.
Estos nueve pasos del método se producen en cuatro etapas fundamentales dentro del proceso
de evaluación [Kazman, 98]. Las mismas son:
ƒ
PresentaciónÆ se intercambia información (incluye a los pasos 1,2 y 3)
ƒ
Investigación y análisis Æ se valoran los atributos claves de calidad requeridos, uno a uno
con las propuestas arquitectónicas (incluye a los pasos 4,5 y 6)
ƒ
Pruebas Æ se revisan los resultados obtenidos contra las necesidades relevantes de los
Stakeholders (pasos 7 y 8).
ƒ
Informes Æ se presentan los resultados de la evaluación aplicando ATAM (paso 9).
Un aspecto importante a considerar es que este método de alguna manera posee ciertas
limitaciones, pues no permite realizar la transformación de la arquitectura una vez que se efectúa el
análisis, centrándose únicamente en la evaluación. Como es mencionado por Clements, Kazman y Klein:
“…Lo importante es tener claro que esta evaluación no establece una respuesta puntual en
términos del algo “bueno” o “malo” o dentro de una escala específica, simplemente indica aquellos puntos
en los cuales existen riesgos...” [Clements, Kazman, Klein, 2002].
Esto quiere decir que una vez finalizado el proceso, no se evalúan las características propiciadas
28
e inhibidas (en caso de que existan) en la arquitectura actual con el fin de realizar un nuevo diseño capaz
de satisfacer todos los atributos de calidad.
Por la razón antes expuesta, fue necesario apoyar el proceso de evaluación arquitectónica con el
método propuesto por Bosch en el año 2000 [Bosch, 2000]. A través del mismo es posible llegar a la
transformación de la arquitectura, en caso de que algún atributo de calidad quede insatisfecho.
Más aún, este método se compone de dos Fases claramente identificadas. En la primera de ellas
se elabora una versión de la arquitectura sin considerar los atributos de calidad. Posteriormente este
diseño es evaluado respecto a los requerimientos de calidad. Cada atributo es estimado según un valor y
los mismos son comparados con lo valores otorgados en las especificaciones de requerimientos de
calidad. Si todos los valores son iguales o mejores a los requeridos, entonces el proceso de diseño
finaliza. En caso contrario se produce un segundo paso a través del cual se transforma la arquitectura
inicial en base a los atributos de calidad que deben ser cumplidos, mejorando en este proceso alguno de
los ya existentes. Esta nueva arquitectura es evaluada y el proceso se repite iterativamente hasta que se
satisfagan todos los requerimientos de calidad o hasta que el arquitecto indique que no es posible
satisfacerlos. [Losavio, 2002]
De alguna manera el método ATAM se parece a esta segunda fase del método de Bosch
[Losavio, 2002] sin llegar al punto de transformación de la arquitectura. Sin embargo, como el sistema
evaluado ya está completamente desarrollado, no tiene sentido aplicar el método Bosch en su totalidad
pues la primera fase no se llevaría a cabo. Por esta razón se hizo la adaptación con el fin de
complementar el método ATAM y llevar a cabo el proceso de evaluación arquitectónica de la manera más
completa posible.
29
CAPÍTULO 4 DESARROLLO: RUPCORB
La pasantía desarrollada se enfocó principalmente en la las fases de Inicio y Elaboración de la
metodología Rupcorb (tal y como fueron descritas anteriormente) haciendo énfasis en los Workflows
relacionados con Requerimientos y Análisis y Diseño. Esto principalmente por tratarse de una aplicación
ya implementada a la cual se iba a realizar una evaluación arquitectónica.
Como artefactos principales de esta fase se obtuvieron los documentos correspondientes a
Especificaciones de Requerimientos de Software de Visual Banker (APÉNDICE A) y Documento de
Arquitectura de Software de Visual Banker (APÉNDICE B). Las plantillas para la generación de los
mismos fueron tomadas de Rupcorb.
Es importante mencionar que la fase de construcción no requería ser aplicada en esta etapa de la
pasantía pues el sistema con el que se trabajó ya estaba completamente desarrollado y lo que se
buscaba era documentar la arquitectura existente para proceder al análisis de la misma. Sin embargo,
una vez finalizado el proceso de evaluación se procedió al desarrollo de parte de las soluciones
propuestas como resultado del análisis. A partir de ese momento se tuvo que trabajar en las disciplinas
de Implementación y Pruebas. Los resultados obtenidos durante esta fase serán presentados en los
capítulos posteriores cuando se hable de la implementación propiamente dicha.
El objetivo fundamental de este capítulo es mostrar los resultados obtenidos al emplear la
metodología Rupcorb como parte de los objetivos propuestos dentro de la pasantía.
4.1. Documento de Especificaciones de Requerimientos de Software (ERS)
El documento de Especificaciones de Requerimientos de Software se obtuvo como artefacto
resultante del desarrollo de la disciplina denominada Requerimientos. Este artefacto permite capturar
requerimientos del sistema que no se capturan fácilmente en artefactos del comportamiento de los
requerimientos, tales como especificaciones de casos de uso. [Rupcorb, 2004]. El ERS contiene
puntualmente: las especificaciones funcionales de Visual Banker, los casos de uso iniciales (con su
respectiva descripción), la lista de actores de los casos de uso y las especificaciones no funcionales de la
aplicación; es decir, aquellas relacionadas con los atributos de calidad.
30
Uno de los mecanismos empleados para el levantamiento de la información correspondiente a las
especificaciones funcionales y suplementarias fue el de entrevistas. Esto se debió principalmente a que
no existía ningún tipo de documentación que de alguna manera especificara los requerimientos
asociados a funcionalidad, seguridad, eficiencia, fiabilidad, etc. Por esta razón, fue necesario hablar con
un grupo de personas especializadas en cada uno de los atributos de calidad para realizar la recopilación
de información partiendo desde cero.
Es importante mencionar que dicha información no abarcó únicamente las condiciones que
presentaba la aplicación en un principio, sino también aquellos aspectos que podrían cambiarse o
añadirse en el diseño actual. Esto de alguna manera permitió dar un indicio sobre los elementos que
deberían ser tratados con mayor prioridad dentro de la arquitectura, ya que podrían requerir algún tipo de
cambio o mejora. Como ejemplo de la especificación de los requerimientos suplementarios de Visual
Banker se muestra a continuación la Tabla 4.1 que contiene una parte de los requerimientos definidos
para el atributo de “Seguridad Interna”. La misma puede ser consultada en el ERS (APÉNDICE A).
Atributo: Seguridad Interna
Lo que hace
Existe un administrador del sistema cuya clave
es conocida y no posee mayores niveles de
seguridad. Además, dentro del módulo de
taquilla los passwords se encuentran cifrados
mientras que en el módulo de plataforma no se
cifra esa información.
El acceso a las bases de datos locales NO se
encuentra restringido. De igual manera, el
acceso se realiza a través de un usuario
genérico.
Se tiene un manejo de usuarios y perfiles que
permite delimitar los niveles de acceso que tiene
cada persona y la información que la misma
puede manipular, así como las transacciones
que pueden ser realizadas. Sin embargo, el
control definitivo lo tiene el servidor pues
siempre se hace una autentificación contra el
mismo para poder acceder a la aplicación.
El control de acceso a la base de datos principal
es riguroso, pues es allí donde realmente se
encuentra toda la información.
Lo que debería hacer
Sería conveniente contar con mecanismos de
encriptamiento
que permiten enviar
la
información por la red de forma mucho más
segura, evitando que a través de posibles
ataques la misma deje de ser confidencial.
Sería conveniente que la conexión a la BD local
no se realizara a través de un usuario genérico,
con el fin de restringir el acceso a esos datos y
mantener la confidencialidad.
Actualmente existen tablas de los Journal que
contiene ráfagas (información de todas las
transacciones realizadas) que no tienen ningún
tipo de control de acceso. Es conveniente que
dicha información no pueda ser accedida por
cualquier usuario sin la debida autorización.
Tabla 4.1: Tabla de Especificaciones Suplementarias – Seguridad Interna
Como se muestra en la tabla anterior, para cada uno de los atributos de calidad planteados en el
documento se tomaron en cuenta las especificaciones actuales, así como las futuras.
31
En términos generales, las características no funcionales que fueron consideradas en el
documento son las especificadas en la Guía de Estudio de Arquitectura de Software [Camacho, Cardeso,
Nuñez, 2004]. En la misma se establece un conjunto de atributos de calidad bastante amplio, que
permitió tener una visión mucho más clara sobre los requerimientos suplementarios. Sin embargo, más
adelante será mostrado como se realizó la unificación de este conjunto de características y
subcaracterísticas con las establecidas por la norma ISO 9126 [ISO, 00]. El resto de especificaciones
suplementarias pueden ser consultadas en el ERS (APÉNDICE A).
Una vez definidas las especificaciones funcionales y no funcionales, se procedió a realizar el
levantamiento de información correspondiente a los casos de uso de Visual Banker. Debido a la
extensión de la aplicación sólo se tomaron en cuenta los casos de uso más relevantes dentro de la
misma, especificándolos a través de la interacción directa con la aplicación. La Tabla 4.2 contiene una
lista de todos los casos de uso presentes en el documento ERS, con sus respectivos actores.
Caso de Uso
Entrar al Sistema
Salir del Sistema
Buscar Cliente
Mostrar Catálogo de Productos
Mostrar Producto para la Compra
Comparar Producto
Imprimir Hoja del Producto
Ver Diapositiva de Presentación del
Producto
Vender Producto
Iniciar Sesión
Actor
Agente
Agente
Promotor
Promotor
Promotor
Promotor
Promotor
Promotor
Caso de Uso
Ver Presolicitudes de Crédito
Aplicar Encuesta
Registrar Cliente
Comparar Inversiones
Usar Matriz de Selección de Productos
Consultar Firma
Buscar Transacción
Cambiar Password
Actor
Promotor
Promotor
Promotor
Promotor
Promotor
Promotor
Taquillero
Taquillero
Promotor
Promotor
Taquillero
Taquillero
Cerrar Sesión
Promotor
Utilizar Calculadora de Ahorro
Utilizar Calculadora Fecha de
Vencimiento
Ver Ficha Cliente
Ver Datos Demográficos
Ver Resumen Banesco
Ver Carpeta Financiera
Promotor
Promotor
Ejecutar Transacción
Seleccionar pago de servicios
Depósitos Propios
Seleccionar pago de servicios
Consulta de Saldo CANTV
Seleccionar pago de servicios CANTV
Seleccionar pago de servicios
Taquillero
Taquillero
Promotor
Promotor
Promotor
Promotor
Utilizar Calculadora
Crear Usuario
Modificar Usuario
Eliminar Usuario
Taquillero
Administrador
Administrador
Administrador
Taquillero
Tabla 4.2: Lista de Casos de Uso
Cada uno de los actores que se presenta en la figura anterior se define de la siguiente manera:
Administrador: persona que está en la capacidad de entrar al módulo de mantenimiento y
efectuar cambios correspondientes al grupo de usuarios que se encuentran definidos dentro del sistema.
32
Dichos cambios abarcan desde la creación de nuevos usuarios, pasando por la modificación de los ya
existentes hasta llegar al borrado de los mismos.
Cliente: cualquiera de los clientes de la organización, tanto personas naturales como jurídicas.
Tiene entablada una relación comercial con Banesco y ha adquirido al menos un producto del banco y un
conjunto de servicios asociados al mismo. No incluye a los aplicantes (clientes potenciales).
Promotor: plataformista encargado de brindar información y asesoría sobre los productos de la
organización. Esta asesoría está orientada a la venta de productos según las necesidades del cliente y
los requisitos del banco. El promotor tiene reducida su acción de venta a un cierto grupo de productos.
Taquillero: persona que se encuentra manejando el módulo de taquilla y que atiende a los
clientes en cuanto a servicios relacionados con depósitos, retiros, cobro de cheques, traspasos, tarjetas
de crédito, pago a proveedores, cheques de gerencia, pensiones, etc.
Agente: representación general de cualquier empleado de la organización que tiene trato con los
clientes y que por lo tanto interactuará con Visual Banker.
Es importante destacar que para cada uno de los casos de uso antes mencionados, se realizó la
descripción de los mismos en términos de una plantilla en la cual se identificaron los diferentes elementos
que lo componen. Dichos elementos se refieren al nombre del caso de uso, actor que lo realiza,
requerimientos funcionales asociados al mismo, precondición que debe existir para que el caso de uso se
pueda llevar a cabo, descripción del caso de uso propiamente dicho (en curso normal y alterno en caso
de que exista) y postcondición; es decir, lo que ocurre una vez que el caso de uso es llevado a cabo.
En la Tabla 4.3 es posible visualizar la descripción de uno de los casos de uso más
representativos dentro de la aplicación. Se trata del correspondiente a “Buscar Cliente”, el cual puede ser
llevado a cabo a través del módulo de Plataforma. El mismo representa la acción de buscar a un cliente
específico perteneciente a la organización, por parte de un plataformista. Una vez que se lleva a cabo es
posible derivar en la realización de otros casos de uso como. “Buscar Cliente” también presenta un curso
alterno que ocurre cuando el cliente solicitado por el promotor no se encuentra registrado en el sistema.
En ese caso, el sistema ofrece automáticamente la opción de registro para el mismo; por esta razón, para
33
poder registrar a un cliente es necesario que se ejecute primero este caso de uso.
CASO DE USO
Buscar Cliente
ACTOR
Promotor
DESCRIPCIÓN
Permite que el promotor busque a un cliente específico, indicando para ello el criterio
de búsqueda. Debe suministrar la nacionalidad y número de CI si es una persona
natural y la nacionalidad y el RIF en caso de tratarse de una persona jurídica.
REQUERIMIENTOS
ASOCIADOS
F15, F16
PRECONDICIÓN
El promotor debe estar conectado y autenticado en el sistema.
CURSO NORMAL
ACTOR
SISTEMA
1. El promotor presiona el icono
denominado Buscar Cliente.
2. El sistema muestra la pantalla para introducir los
datos correspondientes a criterio de búsqueda,
3. El promotor rellena los nacionalidad y CI del cliente.
campos solicitados y presiona el
botón Buscar.
4. El sistema lista al cliente que corresponde con los
datos introducidos por el promotor.
CURSO ALTERNO
ACTOR
SISTEMA
En el paso 4 del curso normal:
4. El sistema indica que el cliente buscado no está
registrado y ofrece la opción de registro para el
promotor.
POSTCONDICIÓN
El cliente buscado es mostrado por el sistema, indicando además si el mismo está
presente en la Lista Negra y/o Sicri.
Tabla 4.3: Caso de Uso “Buscar Cliente” – Módulo de Plataforma
Para obtener todos los casos de uso iniciales fue necesario interactuar directamente con la
aplicación y observar las respuestas dadas por el sistema una vez que se llevaban a cabo los mismos. El
documento con el resto de las especificaciones de los casos de uso puede ser consultado en la sección
de apéndices bajo el nombre APÉNDICE A: Documento de ERS de Visual Banker.
4.2. Documento de Arquitectura de Software (DAS)
Luego de haber cumplido con el hito fundamental de la fase de Inicio (examinación de los
objetivos del ciclo de vida del proyecto), se procedió con la fase de Elaboración especificada en Rupcorb,
cuyo hito fundamental se basa en definir la arquitectura del sistema. Por esta razón, se elaboró el
artefacto correspondiente al Documento de Arquitectura de Software de Visual Banker, el cual
proporciona una descripción arquitectónica del sistema, usando diferentes vistas para representar
34
diversos aspectos de la aplicación. Según lo especifica la metodología:
“…Este documento proporciona una descripción comprensiva de la arquitectura del sistema de
Software. Sirve como medio de comunicación entre el arquitecto del Software y otros miembros del
equipo del proyecto con respecto a las decisiones arquitectónicas significativas que se han tomado en el
mismo…” [Rupcorb, 2004].
Para la elaboración del DAS, se empleó el modelo de las 4 + 1 vistas propuesto por Krutchen en
1995; que contempla la Vista de Casos de Uso, la Vista Lógica, la Vista de Implementación, la Vista de
Procesos y la Vista de Implantación. En la Figura 4.1, es posible observar la representación de dicho
modelo.
VISTA LÓGICA
VISTA IMPLEMENTACIÓN
CASOS DE USO
VISTA DE PROCESO
VISTA DE DESPLIEGUE
Figura 4.1: 4 + 1 Vistas Krutchen [Krutchen, 95]
La primera vista desarrollada se refiere a la vista de casos de uso que describe el
comportamiento del sistema como es visto por los usuarios y agentes externos. Gracias a ella es posible
descubrir diferentes elementos de la arquitectura durante el diseño [Krutchen, 95].Como fue mencionado
anteriormente, por ser una vista enfocada en la funcionalidad para la creación de la misma fue necesario
interactuar con la aplicación. En el DAS propiamente dicho solo se contemplan los diagramas de casos
de uso de cada uno de los módulos, representándose a través de los mismos los casos de uso iniciales
detallados en el ERS.
35
El diagrama que se presenta a continuación corresponde al módulo de plataforma. En el mismo
es posible observar los casos de uso relacionados con Inicio de Sesión, Cierre de Sesión, Apertura de
Cuentas, Entrar al Sistema, Salir del Sistema, Matriz de Selección de Productos, Vender Productos, Ver
Ficha del Cliente; entre otros. Como se mostró en la Tabla 4.2, el actor que lleva a cabo los casos de uso
de Plataforma es el promotor de las agencias, pues es el usuario que posee el perfil correspondiente para
realizar las transacciones asociadas dicho módulo.
Figura 4.2: Modelo de Casos de Uso – Plataforma
El resto de los diagramas de casos de uso y la descripción detallada de los mismos puede ser
consultada en el DAS de Visual Banker, APÉNDICE B. De igual manera, el glosario de Transacciones y
Productos que fueron presentados de forma general en algunos de los casos de uso, puede ser
consultado en el APÉNDICE C.
36
La segunda vista desarrollada en el DAS se refiere a la Vista Lógica, la cual da soporte a los
requerimientos funcionales. En la misma se descompone el sistema en un conjunto de abstracciones
clave tomadas del dominio del problema en forma de objetos y clases; se concentra en la abstracción, el
encapsulamiento y la uniformidad [Krutchen, 95]. Dentro del documento se encuentran tres modelos
lógicos correspondientes a cada uno de los módulos que conforman la aplicación. Es importante destacar
que por la naturaleza y dimensiones de la aplicación, solo se especificaron en los mismos las clases más
relevantes con sus respectivas relaciones y atributos.
En la Figura 4.3 se presenta la Vista Lógica del módulo de Plataforma, el cual pudo ser
expresado de forma más amplia que el resto. Allí se manejan conceptos importantes de la aplicación
como lo son los clientes naturales (BcPerson) y jurídicos (BcEnterprise), los productos que los mismos
tienen con la organización (BcAgreement Banesco), su teléfono (FcPhoneNumber) y dirección
(BcVenezuelaAddress), entre otros.
Figura 4.3: Vista Lógica – Plataforma
37
La tercera vista considerada se refiere a la de implementación. Ésta se enfoca en la organización
modular real del Software en el entorno de desarrollo. Tiene en cuenta los requerimientos internos
relacionados con la facilidad de implementación, administración de Software, reutilización, y las
restricciones impuestas por las herramientas de desarrollo [Krutchen, 95].
En la Figura 4.2.4 es posible observar que la aplicación posee 4 capas diferentes cada una de las
cuales contiene diversos servicios o aplicaciones. Dentro de la Vista de Implementación del DAS
(APÉNDICE B) se encuentra una descripción detallada de cada una de estas capas y de las aplicaciones
contenidas en las mismas.
APLICACIÓN
VISUAL BANKER
Aplicación
Salidas
Formateadas
Modelo
de Negocios
Interface
a Usuarios
Servicios
de Aplicación
Autenticación
Servicios
ARQUITECTURA
DE SOFTWARE
Arquitectura
Sistema
Operativo
Herram. de
Cont. de Vers.
Visual Age
Comunicaciones
Base de
Datos
Implementación
Figura 4.4: Vista de Implementación [Banesco-IBM]
Por su parte, la cuarta vista se refiere a la vista de procesos que representa la descomposición de
la aplicación en flujos de ejecución (proceso, threads, tareas, etc.), la sincronización entre flujos y la
asignación de los objetos y las clases dentro de los diferentes flujos. La vista de procesos también se
preocupa de la disponibilidad del sistema, de la fiabilidad de las aplicaciones y del rendimiento.
38
“…esta vista es definida para manejar tanto los aspectos concurrentes del sistema a tiempo de
ejecución como las interacciones que ocurren entre ellos. Se manejan aspectos tales como concurrencia
y paralelismo, inicio o culminación del sistema, tolerancia a fallas y deadlocks….” [Krutchen, 95].
Sin embargo, debido a la ausencia de concurrencia en la aplicación esta vista no fue desarrollada
dentro del documento de Arquitectura de Software.
Por último, se encuentra la vista de implantación o despliegue. En la misma se tiene en cuenta
los requerimientos no funcionales del sistema tales como disponibilidad, confiabilidad (tolerancia a fallas),
rendimiento (throughput), y escalabilidad. Además se identifican los elementos (redes, procesos, tareas, y
objetos) que conforman la topología del Hardware usado [Krutchen, 95]. El diagrama que se muestra a
continuación (Figura 4.2.5) representa la vista de despliegue para una agencia.
Figura 4.5: Vista de Implantación – Una Agencia
En la figura anterior, es posible observar la disposición de las diferentes estaciones de trabajo,
así como de los dispositivos y periféricos existentes en cada una de las agencias. Todos estos elementos
se comunican entre sí a través de una red LAN que posee una velocidad de 16 Mbps y una topología
Token Ring. Las agencias se comunican entre sí y con el servidor principal a través de una red WAN que
posee una velocidad de 64 Kbps y que también es de tipo Token Ring. En la vista de implantación del
39
DAS (APÉNDICE B) es posible observar la disposición de los elementos para un conjunto de agencias.
Una vez elaboradas todas las vistas correspondientes al documento de Arquitectura, se
definieron las características de calidad con las que debía cumplir la aplicación, según lo establecido por
la norma ISO 9126 [ISO, 00] (APÉNDICE E). En la última sección del DAS (APÉNDICE B) se especificó
a través de qué vista y de qué elementos arquitectónicos se podrían ver reflejados dichos atributos dentro
de la arquitectura.
Como se pudo observar en esta sección, durante la puesta en marcha de la metodología Rupcorb
se generaron una serie de artefactos que fueron de gran utilidad para comprender la arquitectura actual
de Visual Banker y formar las bases que permitieron realizar un análisis profundo de la misma. Sin la
ayuda de esta metodología hubiera sido muy difícil comprender la situación actual de la arquitectura y
proponer mejoras en aquellos elementos que no funcionaban correctamente.
Alguna de la información reflejada en estos artefactos se tomó de documentos suministrados por
el banco. Sin embargo, fue necesario realizar ingeniería de reverso para poder completar y actualizar la
información pues una gran parte de ella había sido recopilada cuando se implantó la aplicación y nunca
más se le hizo mantenimiento. Además, la misma había sido levantada sin seguir ningún tipo de
metodología por lo que hubo que adaptarla a los estándares específicos definidos dentro de Rupcorb.
Esto conllevó a la realización de un esfuerzo bastante significativo para poder recopilar, organizar y
analizar toda la información necesaria con el fin de comenzar con la evaluación arquitectónica.
40
CAPÍTULO 5 DESARROLLO: ATAM
En el siguiente capítulo se pretende mostrar los resultados obtenidos al aplicar el método ATAM
como parte del proceso de evaluación arquitectónica de Visual Banker. Como fue mencionado
anteriormente este método se compone de una serie de pasos y etapas que permiten llevarlo a cabo de
forma sencilla. Durante el desarrollo de la pasantía se hizo énfasis en la etapa de Investigación y Análisis
(pasos 4, 5 y 6) pues en la misma se elaboraron los artefactos correspondientes a Utility Tree y ABAS. El
resto de los pasos también fueron llevados a cabo pero de forma menos exhaustiva.
Una vez generada los artefactos se procedió a la priorización de los escenarios y atributos de
calidad con la ayuda y participación de varios Stakeholders. Además se realizó el análisis de las
decisiones arquitectónicas existentes, se evaluaron las características de calidad propiciadas e inhibidas
en la arquitectura actual y se elaboró el planteamiento de las nuevas propuestas arquitectónicas que
permitirían la transformación de la misma en aquellos aspectos en los que se consiguieron fallas.
A continuación se presenta una breve descripción de los resultados obtenidos en cada uno de
los pasos del ATAM, así como de las actividades realizadas en los mismos.
Paso 1. Presentación del ATAM
Se realizó una reunión con Stakeholders de diferentes áreas (específicamente Plataforma y
Calidad en Informática) dando una introducción sobre el método de evaluación y los conceptos más
importantes presentes en el mismo. La presentación fue realizada por el pasante con ayuda y
participación de las profesoras del LISI (Laboratorio de Investigación de Sistemas de Información – USB).
Paso 2. Presentar las reglas del Negocio del Proyecto
Este paso fue llevado a cabo a través de una sesión de entrevistas con el gerente del área de
Plataforma. El mismo indicó los drivers arquitectónicos o metas del negocio que se encontraban vigentes
y debían ser apoyadas por la aplicación al momento en el que la misma fue desarrollada.
En términos generales, se estableció que los atributos relacionados con eficiencia, seguridad y
disponibilidad de la aplicación son muy importantes para su correcto funcionamiento pues por la
naturaleza de la misma se debe procesar un número de transacciones muy alto, garantizando que en
41
todos los envíos realizados los datos suministrados mantengan el carácter de confidencialidad e
integridad. Como la aplicación da soporte a todas las agencias a nivel nacional, el porcentaje de
disponibilidad de la misma también debe mantenerse alto pues un fallo implica la pérdida de grandes
cantidades de dinero para la organización. Todas estas metas pueden ser consultadas en el Documento
de Arquitectura de Software inicial de Visual Banker (APÉNDICE B).
Paso 3. Presentar la Arquitectura
El arquitecto de la aplicación no realizó una presentación como tal en la que se ofrecieran
detalles específicos de la arquitectura de Visual Banker. Sin embargo, se suministró toda la información
escrita que se poseía sobre la aplicación para que fuera estudiada y analizada. Mucha de la información
contenida en esa documentación fue tomada como base para la realización de los artefactos
correspondientes a ERS y DAS. La obtención de la misma fue importante pues permitió una mayor
comprensión de la arquitectura con la que se estaba trabajando. Además, permitió explicar al resto de
Stakeholders involucrados toda la arquitectura de la aplicación de una manera sencilla pues los mismos
no pertenecían necesariamente a áreas técnicas.
Paso 4. Identificar las propuestas de la Arquitectura
Se recopilaron las propuestas arquitectónicas que se encontraban definidas inicialmente en la
arquitectura, realizándose anotaciones en cada uno de los casos. Se aclararon las posibles dudas
encontradas, contando para ello con la ayuda de diferentes Analistas del área de Plataforma.
Paso 5. Árbol de Utilidad (Utility Tree)
En este paso se elaboró el árbol de utilidad correspondiente a Visual Banker, considerando para
ello algunos de los atributos de calidad definidos en la norma ISO 9126 [ISO, 00]. Dicha norma posee
otras características y subcaracterísticas (como Facilidad de Uso) que no fueron considerados como
parte del UT, pues por la naturaleza de la aplicación y necesidades especificadas por la gerencia los
mismos no eran considerados como relevantes. De igual manera, se modificaron y añadieron ciertas
subcaracterísticas que no estaban representadas en la norma propiamente dicha, pero que aplicaban
perfectamente al tipo de sistema evaluado. Tal es el caso de “Cantidad de Transacciones”.
42
En primer lugar, se formó la raíz del árbol con un atributo denominado utilidad. Posteriormente se
formó el segundo nivel con los atributos correspondientes a la norma antes mencionada. El tercer nivel
fue constituido por subcaracterísticas de cada uno de los atributos, mientras que al cuarto nivel lo
constituyeron los escenarios que fueron planteados en cada subcaracterística. Los mismos englobaron
situaciones que están presentes actualmente en la arquitectura, otras que no están presentes en lo
absoluto y otras que están presentes pero de alguna manera pueden ser mejoradas.
Para poder clasificar los escenarios y los atributos de calidad fue necesario realizar una serie de
reuniones con Stakeholders de diferentes áreas (auditoria, usuario final, seguridad, plataforma, etc.) con
el fin priorizar las situaciones planteadas (a través de una tormenta de ideas y de cuestionarios), desde
perspectivas variadas. Cada uno de los escenarios fue ponderado bajo dos dimensiones. La primera de
ellas se refiere a la importancia que tiene el escenario para el éxito del sistema, mientras que la segunda
se refiere al grado de dificultad existente para que éste pueda ser implementado. Cada una de las
dimensiones fue ponderada en términos de High (H), Medium (M) y Low (L), considerando a H como el
valor más alto, M como el valor medio y L como el valor más bajo.
La clasificación de los escenarios en la 1era dimensión contó con la participación de todos los
invitados, mientras que la 2da dimensión sólo fue ponderada por los analistas de plataforma pues son
ellos quienes conocen la dificultad que puede tener la implementación de la propuesta. Cada participante
realizó la votación correspondiente desde su punto de vista y una vez totalizados los votos se procedió a
clasificarlos según los resultados obtenidos. Esta reunión tuvo que ser manejada con mucho cuidado
pues no se podía perder el objetivo fundamental de la misma (llegar a un consenso sobre la priorización
de los escenarios), entre las necesidades que poseían cada una de las personas allí presentes.
Posteriormente, cada uno de los atributos presentes en el segundo nivel del árbol de utilidad fue
ponderado. En este caso fueron evaluados en términos de una escala numérica contemplada desde el
número 1 hasta el número 5. El atributo que contiene el valor 1 es considerado como el más importante y
con una necesidad mayor de ser atacado actualmente, mientras que el atributo con el valor 5 es al que se
le otorga una menor importancia o prioridad. Para esta clasificación participaron todos los Stakeholders.
43
Este paso se considera crucial para el resto del análisis. Sin esta guía, el evaluador puede perder
su tiempo analizando aspectos de la arquitectura que no son de interés para los Stakeholders. De esta
forma el evaluador y los Stakeholders concentran su atención en los aspectos de la arquitectura que son
más críticos para el éxito del sistema. El árbol de utilidad provee un mecanismo que en forma directa y
eficiente traduce las pautas del negocio del sistema en escenarios concretos de los atributos de calidad.
El resultado final de este paso se muestra en la Figura 5.1, en la cual es posible observar la
distribución del UT en cada uno de los niveles antes mencionados, así como la ponderación que obtuvo
cada uno de los escenarios propuestos, además de los atributos de calidad.
Cantidad de
Transacciones
Eficiencia
(1)
Mantenibilidad
(3)
Tiempo de
Respuesta
Facilidad de
Cambio
Seguridad
de los Datos
Utility
Funcionalidad
(2)
Integridad de los
Datos
Seguridad Física
Ajuste a los
propósitos
Portabilidad
(5)
Facilidad de
Instalación
Adaptabilidad
Madurez
Recuperabilidad
Fiabilidad
(4)
Tolerancia a
Fallas
Disponibilidad
1. Se requiere que el sistema maneje un alto volumen de
transacciones. (H, L)
2. Se requiere hacer mantenimiento al Journal dentro de la BD local
para liberar espacio y mejorar los tiempos de respuesta. (M, M)
3. Se solicita autorización remota a un funcionario válido que no se
encuentra en su puesto de trabajo. (H, H)
4. Se realiza una transacción y se requiere conocer el estatus. (M, H)
5. Se agrega una nueva funcionalidad a la aplicación. (H, L)
6. Se requiere hacer un cambio de interfaz dentro de la aplicación.
(M, H)
7. Se desea que todas las transacciones sean capaces de trabajar en
otro canal de comunicación. (H, L)
8. Se intenta realizar un acceso no autorizado dentro de la
aplicación. (H, L)
9. Una persona accede al módulo de Mantenimiento como usuario
genérico. (M, L)
10. Se desea tener un archivo de log que permita registrar todas las
operaciones realizadas por los usuarios en la BD. (H, H)
11. Se requiere que los cambios en los passwords de los usuarios
se realicen constante mente y que su deducción sea difícil. (H, M)
12. Se requiere que la data viaje encriptada. (H, H)
13. Se consulta una firma digitalizada. (H,M)
14. Ocurre el mecanismo de RollBack dentro de la BD. (M, L)
15. Ocurre una modificación en la firma de un cliente. (M, L)
16. Se desea que los servidores locales se encuentren replicados
en el servidor principal. (M, H)
17. Se desea que todos los requerimientos de funcionalidad que
presenta la aplicación, se encuentren cubiertos. (H, M)
18. Se desea hacer la instalación de una nueva versión en todas las
agencias. (M, M)
19. Ocurre una falla en el refrescamiento de una de las máquinas
de una agencia. (H, L)
20. Se desea que la aplicación se ejecute en otro sistema de
operación. ( M, H)
21. Se desea que la aplicación se adapte a otro manejador de BD.
(M, M)
22. El Software intenta acceder a dispositivos I/O que no se
encuentran conectados. (L, H)
23. Ocurre una falla durante la ejecución de una transacción. (M, M)
24. Ocurre una falla en la aplicación (H, M)
25. Se desea que la aplicación permita hacer backups en diferentes
dispositivos, indicando donde va a ser almacenado. (H, L)
26. Ocurre una falla en el canal principal de comunicación. (M, L)
27. El servidor principal sufre una falla crítica de Sw. (Offline) (M, H)
Figura 5.1: Árbol de Utilidad Visual Banker
44
Paso 6. Analizar las propuestas arquitectónicas (ABAS)
En este paso se analizaron todos los escenarios contenidos en el árbol de utilidad, mencionado
las decisiones arquitectónicas existentes en cada uno de los casos y especificando las posibles
decisiones arquitectónicas para lograr las mejoras. Para cada decisión se establecieron los puntos de
sensibilidad (cuando la decisión afecta sólo una característica de calidad), riesgos (desventajas), no
riesgos (ventajas) y Tradeoff (cuando la decisión afecta más de una característica de calidad)
correspondientes.
El objetivo se alcanzó a través de la elaboración de los ABAS para cada uno de los escenarios
del UT. Estos estilos arquitectónicos basados en atributos fueron propuestos por Kazman y Klein
[Kazman, Klein, 99] con la intención de asociar a la definición del estilo arquitectónico un framework de
razonamiento basado en modelos de atributos específicos. Cada ABAS se compone de diferentes
elementos, algunos de ellos se presentan en la Tabla 5.1:
Elemento
Estímulo
Fuente del estímulo
Respuesta
Ambiente
Artefacto estimulado
Medida de la respuesta
Breve Descripción
Es una condición que necesita ser considerada cuando llega al sistema. Algunas de
las fallas pueden ser de omisión, de choque, de cronometraje y de respuesta.
Es una entidad humana, del sistema o algún actor que genera el estímulo.
Es la actividad emprendida después de la llegada del estímulo. Bass, Kazman y
Clements [Bass, Kazman, Clements, 2003] señalan que éstas son las posibles
reacciones a las fallas de un sistema.
Es la condición del sistema cuando ocurre el estímulo; por ejemplo, sobrecargado,
ejecutándose, etc. El ambiente puede estar en operación normal, o en operación
degradada.
Algún artefacto que es estimulado; puede ser todo el sistema o parte de éste.
La respuesta al estímulo tiene que ser medible en algún modo tal que el
requerimiento pueda ser probado.
Tabla 5.1: Elementos de la descripción de Escenarios [Kazman, Klein, 99]
Existen dos elementos importantes de los ABAS que no se encuentran contemplados en la tabla
anterior y que se refieren específicamente a las decisiones arquitectónicas (solución o soluciones
actuales presentes en la arquitectura, a través de las cuales se refleja el escenario planteado) y al
diagrama arquitectónico (representa gráficamente la parte de la arquitectura en la cual se ve reflejada la
decisión arquitectónica actual). Como fue mencionado anteriormente, cada decisión arquitectónica se
encuentra atada a sus respectivos puntos de negociación, riesgos, no riesgos y puntos de sensibilidad;
aunque es posible que no todas las decisiones cuenten con todos los elementos.
45
Es importante aclarar que para cada decisión arquitectónica presente en los ABAS, se empleó el
símbolo (A) para indicar que la decisión arquitectónica está actualmente implementada en Visual Banker
y (P) para indicar que la decisión arquitectónica es propuesta como solución.
A continuación se presentan tres ABAS que corresponden a diferentes escenarios contemplados
en el Utility Tree y que serán implementados como parte del alcance de la pasantía.
Escenario #: 11
Escenario: se requiere que los cambios en los passwords de los usuarios se realicen
constantemente y que su deducción sea difícil.
Atributo(s): funcionalidad (seguridad de los datos).
Ambiente: operación normal.
Estimulo: se intenta deducir la clave de uno de los usuarios de la aplicación.
Fuente del Estímulo: externa al sistema.
Respuesta: se establecen mecanismos dentro de la aplicación que obliguen a los usuarios a especificar
claves mucho más robustas (con un mínimo de caracteres y con combinación de números y letras) y que las
mismas sean cambiadas constantemente.
Artefacto Estimulado: Sistema.
Medida de la Respuesta: presencia de un mecanismo que garantice la creación de claves robustas y que
registre los datos de la creación para indicar a los usuarios cuando debe producirse el cambio de clave.
Debe recordar las últimas claves suministradas para evitar repeticiones.
Decisión Arquitectónica
Sensibilidad
Tradeoff
D1
NR1, NR2
D1(A) Método de verificación y validación de usuarios y contraseñas contra
los registros guardados en la BD local de cada agencia.
D2(P) Método de verificación contra la BD local, además de método que
garantice la creación de claves robustas al exigir un número mínimo de
caracteres, combinación de letras y números. Método que registre fecha de
creación de las claves para hacer validaciones de vencimiento y necesidad
de cambio de las mismas.
R1 No garantiza el cambio constante de las claves de los usuarios por lo que
pueden durar con las mismas un tiempo considerable e incluso nunca
cambiarlas.
R2 El método no garantiza la creación de claves robustas por lo q las
mismas pueden ser deducidas con gran facilidad.
NR1 Se garantiza el cambio constante de las claves al realizar avisos de
vencimiento en un período de tiempo determinado.
NR2 Se garantiza la creación de claves robustas.
Diagrama
Tabla 5.2: ABAS del Escenario #11
46
No Riesgo
R1, R2
D2
Explicación
Riesgo
El primer escenario (Tabla 5.2) corresponde al atributo de calidad denominado “funcionalidad” y
se encuentra relacionado específicamente con la subcaracterística “seguridad de los datos”. Según lo
que se puede observar en la figura anterior el estímulo producido para que ocurra el escenario se refiere
al intento de deducción de la clave de acceso de alguno de los usuarios. Por esta razón, la respuesta del
sistema se basa en la creación de mecanismos capaces de garantizar que las claves generadas por los
usuarios sean seguras y que el cambio de las mismas se realice constantemente para evitar que sean
descubiertas.
A través del diagrama es posible observar que la decisión actual se basa únicamente en el
registro y validación de los datos suministrados contra la BD local, sin garantizar ningún tipo de robustez
al momento de generar una nueva clave. En ese punto es donde se encuentra la falla pues las claves
seleccionadas por los usuarios son sumamente frágiles al no tener ningún tipo de estándar para la
creación de las mismas. De igual manera, los usuarios en la actualidad pueden tener la misma clave por
un tiempo ilimitado sin necesidad de cambiarla. Esto ocasiona que los passwords sean mucho más
sensibles pues se tiene un mayor tiempo para su análisis y posterior deducción.
Esto quiere decir que la decisión arquitectónica actual no permite alcanzar el objetivo de
seguridad planteado por la organización. Por esta razón, la propuesta se basa en la implementación de
métodos que garanticen la creación de claves robustas y que obliguen a los usuarios el cambio continuo
de sus passwords, por ejemplo, en un lapso no mayor a los 30 días. Estos mecanismos deben ser
implementados en los tres módulos fundamentales: Mantenimiento, Taquilla y Plataforma si se desea que
el grado de seguridad de los datos aumente dentro de la aplicación.
El segundo escenario (Tabla 5.3) también pertenece al atributo de “funcionalidad”, pero esta vez
está relacionado con la subcaracterística “Ajuste a los Propósitos”. Este escenario fue propuesto ya que
de alguna manera era necesario garantizar que todos los requerimientos funcionales de la arquitectura se
encontraran cubiertos. El resultado del análisis fue que existían requerimientos funcionales que habían
sido especificados en el ERS que no estaban reflejados actualmente en la aplicación. La decisión
arquitectónica propuesta en esta oportunidad se refiere a la implementación de los requerimientos que
aún no han sido desarrollados. El ABAS correspondiente a este escenario se presenta a continuación.
47
Escenario #: 17
Escenario: se desea que todos los requerimientos de funcionalidad que presenta la
aplicación, se encuentren cubiertos.
Atributo(s): funcionalidad (ajuste a los propósitos).
Ambiente: operación normal.
Estimulo: se agrega una nueva funcionalidad a la aplicación.
Fuente del Estímulo: interna al sistema.
Respuesta: todos los requerimientos contenidos en el documento ERS tienen una correspondencia dentro
de la aplicación.
Artefacto Estimulado: Sistema.
Medida de la Respuesta: existencia de un componente que permita el cumplimiento de todos los
requerimientos funcionales.
Decisión Arquitectónica
Sensibilidad
Tradeoff
D1
Explicación
Diagrama
Riesgo
No Riesgo
NR1
D1(P) Implementación de los requerimientos funcionales presentes en el
documento ERS que todavía no han sido desarrollados.
NR1 La aplicación tendría nuevas funcionalidades que prestar a los usuarios
y clientes.
Actualmente no existe ninguna decisión tomada que pueda verse reflejada
en la arquitectura.
Tabla 5.3: ABAS del Escenario #17
Por último, en la Tabla 5.4, se presenta el ABAS perteneciente al escenario #19 el cual trata de
reflejar las fallas que ocurren cuando no se produce el refrescamiento (actualización con la nueva versión
de la aplicación) de una máquina dentro de cualquier agencia. Como respuesta al estímulo producido se
tiene que el sistema continúa funcionando normalmente pero sin presentar las actualizaciones a sus
usuarios, por lo que es muy difícil darse cuenta que la misma no se llevó a cabo. El usuario generalmente
se percata cuando requiere hacer uso de alguna aplicación y ésta no se encuentra presente o disponible.
Para facilitar la labor del área de Plataforma, quienes son los encargados de solventar este tipo
de situaciones, se plantea una opción fácil y rápida a través de la cual el usuario pueda validar el tamaño
y fecha del Build que tiene instalado en su máquina. Con solo presionar un botón, es posible verificar si
la versión no ha sido actualizada y se procederá a una nueva distribución del Build para poder obtener
los cambios correspondientes. Esto permitirá descartar otros posibles inconvenientes cuando el problema
real es una máquina desactualizada. Parte de la solución implica la creación de un archivo “.ini” que
contenga los datos de tamaño y fecha de actualización y que debe ser distribuido junto con el ejecutable.
48
Escenario #: 19
Escenario: ocurre una falla en el refrescamiento de una máquina en una agencia.
Atributo(s): portabilidad
Ambiente: operación normal.
Estimulo: la nueva versión de la aplicación no se refresca correctamente en una de las máquinas de una
agencia.
Fuente del Estímulo: interna al sistema.
Respuesta: el sistema sigue funcionando normalmente pero sin presentar las opciones agregadas a la
nueva versión instalada.
Artefacto Estimulado: Sistema.
Medida de la Respuesta: existencia de un mecanismo que permita el refrescamiento manual o automático
de cada una de las estaciones de trabajo para evitar versiones obsoletas.
Decisión Arquitectónica
Sensibilidad
Tradeoff
D1
Riesgo
R1, R2
D2
NR1
D3
Explicación
No Riesgo
R2
D1(A) Script de actualización de versiones encargado de copiar la nueva
versión existente de la aplicación en cada una de las estaciones de trabajo.
D2(P) Script de actualización que además genere un archivo de log en el que se
indique la fecha/hora y máquinas en las cuales se llevó a cabo el
refrescamiento, así como los archivos actualizados en cada una.
D3(P) Script de actualización además de un botón que permita al usuario
verificar la fecha y tamaño del Build instalado en su máquina para saber si se
produjo o no la actualización.
R1 No se tiene garantía ni conocimiento si el Script se ejecutó correctamente.
R2 No se tiene registro de las máquinas actualizadas ni de los archivos
actualizados en cada uno de los casos.
NR1 Se tiene información puntual sobre las máquinas actualizadas
correctamente en cada una de las agencias.
Diagrama
Tabla 5.4: ABAS del Escenario #19
El resto de los ABAS definidos pueden ser consultados en el APÉNDICE D: Utility Tree y ABAS
para cada escenario. Una vez especificados todos los escenarios se procedió a la realización de pruebas
que permitieran corroborar como se estaban llevando a cabo los mismos, principalmente para el caso de
aquellos que ya se estaban cumpliendo dentro de la aplicación. Esto permitió verificar que las decisiones
arquitectónicas actuales se ejecutaban como efectivamente habían sido planteadas.
49
Paso 7. Priorización de Escenarios
Este punto se basa en la priorización de los escenarios propuestos en el UT. Los resultados
obtenidos en el mismo fueron presentados en el paso 5 (elaboración del Utility Tree) que se encuentra
explicado en este capítulo ya que los dos se realizaron de manera consecutiva, antes de ser
especificados los ABAS. Durante la tormenta de ideas no surgieron escenarios diferentes a los que
habían sido propuestos en primera instancia.
Paso 8. Analizar las propuestas de la Arquitectura
En este punto se revisaron todos los escenarios definidos, algunos de los que ya habían sido
planteados se fusionaron con otros por tratarse del mismo tema o referirse a la misma característica de
calidad. Sin embargo, no surgieron propuestas diferentes a las que ya habían sido especificadas en un
primer momento.
Paso 9. Presentación de resultados
En este paso del método se mostraron los resultados obtenidos durante el proceso de evaluación
a todos los Stakeholders involucrados. En este punto se presentó la versión final tanto del Utility Tree
como de los ABAS para cada escenario, con sus respectivos puntos de Sensibilidad, Negociación,
Riesgos y No riesgos.
50
CAPÍTULO 6 ANÁLISIS DE LA ARQUITECTURA PARA LA TRANSFORMACIÓN
En el siguiente capítulo se presentan los resultados del seguimiento de la segunda fase
propuesta por el método Bosch, a través de la cual es posible lograr la transformación de la arquitectura.
La misma fue realizada como complemento al método ATAM el cual se limita únicamente a la evaluación.
En primer lugar, se realiza un análisis profundo a través del cual se pueden validar los atributos
de calidad propiciados e inhibidos por las decisiones arquitectónicas que fueron tomadas inicialmente. De
igual manera, se revisan uno a uno los escenarios planteados para hacer la propuesta de mejora más
adecuada en el caso en el que corresponda. Así mismo se especifican y justifican aquellos escenarios
que van a ser implementados como parte del alcance de la pasantía.
6.1. Análisis
Una vez finalizado el proceso de evaluación arquitectónica fue necesario realizar el análisis de los
resultados obtenidos durante el desarrollo del mismo; con el fin de presentar una propuesta adecuada a
través de la cual se lograra la transformación de la arquitectura principalmente en aquellas características
inhibidas dentro de la arquitectura actual.
El análisis comenzó especificando en que porcentaje se estaba cumpliendo cada uno de los
atributos de calidad, con el fin de identificar que propiedad debía ser atacada primero al momento de
realizar la transformación.
Para poder llevar a cabo este procedimiento se realizó un análisis de características por juicio de
experto. Este mecanismo se basa en preguntar a los expertos de la aplicación su opinión sobre el
cumplimiento de cada uno de los escenarios propuestos en el UT. En primer lugar, se consultó cuáles de
los escenarios planteados se cumplían de forma satisfactoria, de forma regular o no se cumplían en lo
absoluto. A los escenarios en los que la decisión(es) arquitectónica actual era óptima se les otorgó un
porcentaje de satisfacción y cumplimiento del 100%, a aquellos en los que existía una decisión actual que
lo cubría, pero que podía ser mejorada, se les asignó un porcentaje de satisfacción del 50%. Por último,
se consideraron aquellos escenarios en los cuales no existía actualmente una decisión arquitectónica que
los soportara; el grado de satisfacción en este caso se fijó en un 0%. De esta manera, se clasificó a cada
51
uno bajo la terminología antes mencionada y se le asignó el porcentaje correspondiente.
Es importante destacar que este análisis es considerado como poco confiable pero eficiente,
pues sólo se requiere plantear escenarios y reunir a los expertos para obtener su opinión en cada uno de
los casos. Sin embargo, la clave se encuentra en garantizar que todos los expertos a los cuales se
consultó son los indicados y los más conocedores del tema, como ocurrió en esta oportunidad pues la
evaluación se hizo en base a la experiencia de analistas desarrolladores de la aplicación, usuario final,
área de auditoria, área de seguridad, entre otras.
En base a la clasificación de los escenarios se procedió a obtener el porcentaje de cumplimiento
para cada subcaracterística. Para ello se sumaron todos los porcentajes de los escenarios pertenecientes
a la misma, dividiendo la cantidad obtenida entre el número total de escenarios de dicha
subcaracterística. Por ejemplo: para el caso de “Tiempo de respuesta” (véase Figura 5.1) se obtuvo que
dos escenarios se cumplían de manera Regular por lo q se le asignó a cada uno un 50%. El tercer
escenario no se cumplía en lo absoluto por lo que se le asignó un
0%. De esta manera la
subcaracterística “Tiempo de Respuesta” se cumple en un 33% pues se tiene que: 50%(escenario 1) +
50%(escenario 2) + 0%(escenario 3) = 100 => 100% / 3 (cantidad de escenarios) = 33%. Este
procedimiento fue realizado para cada una de las propiedades reflejadas en el tercer nivel del árbol de
utilidad. En la Tabla 6.1 es posible observar el cumplimiento de cada subcaracterística según los cálculos
realizados anteriormente, en donde E.O significa Escenario Óptimo, E.R significa Escenario Regular y
E.NC significa Escenario que no se cumple.
Característica
Eficiencia
Mantenibilidad
Funcionalidad
Portabilidad
Fiabilidad
Subcaracterísticas
E.O
(100%)
Cantidad de Transacciones
Tiempo de Respuesta
Facilidad de Cambio
Seguridad de Datos
Integridad de Datos
Seguridad Física
Ajuste a los Propósitos
Facilidad de Instalación
Adaptabilidad
Madurez
Recuperabilidad
Tolerancia a Fallas
Disponibilidad
1
1
1
E.R
(50%)
E.NC
(0%)
2
3
4
1
Total
Esc.
% Subc.
1
3
3
6
2
1
1
2
2
1
1
3
1
100%
33%
50%
50%
50%
0%
0%
50%
0%
50%
50%
50%
0%
1
1
1
1
2
2
1
1
3
1
Tabla 6.1: Porcentaje de cumplimiento de los atributos de Calidad
52
Una vez ponderado cuantitativamente el tercer nivel, se procedió a evaluar el cumplimiento o no
de las características de calidad definidas en el UT, según lo propone el prototipo de modelo de calidad
MOSCA. El algoritmo de MOSCA establece que para que un atributo de calidad se encuentre presente
en la arquitectura, es necesario que al menos el 75% de las subcaracterísticas que lo componen se
encuentren altamente satisfechas, es decir que se cumplan en un 75% [Mendoza, Pérez, Grimán, 2004].
Para el caso de la categoría Eficiencia es posible observar, en la Tabla 6.1, que sólo una de las
dos subcaracterísticas que lo componen se encuentra altamente satisfecha (Cantidad de Transacciones
con 100%), lo que implica que dentro de Visual Banker no se cumple esta categoría. Para que esto
ocurra es necesario que al menos el 75% (1.5 ≈ 2) de las subcaracterísticas se mantengan altamente
satisfechas.
Respecto a la característica Mantenibilidad, ésta posee una única subcaracterística, por lo que el
75% viene representado por la satisfacción total de la misma. Sin embargo, según los resultados
obtenidos ésta característica no se encuentra altamente satisfecha pues solo se cumple en un 50%. Por
tal motivo la característica de Mantenibilidad tampoco se encuentra presente.
En cuanto a Funcionalidad, se tiene que la misma posee cuatro subcaracterísticas, por lo que
para que ésta se cumpla es necesario que se encuentren altamente satisfechas tres de ellas. Sin
embargo, dos de las subcaracterísticas se cumplen en un 50% mientras que las dos restantes no se
cumplen. Esto nos indica que la categoría de Funcionalidad tampoco se encuentra presente.
Portabilidad posee dos subcaracterísticas por lo que la presencia de la misma en la arquitectura
viene sujeto al cumplimiento de ambas.
Sin embargo, ninguna de las dos se encuentra altamente
satisfecha, pues poseen valores del 50% y 0% respectivamente.
Por último se tiene la característica de Fiabilidad. La misma se compone de cuatro
subcaracterísticas por lo que el 75% viene representado por el cumplimiento de tres de ellas. Sin
embargo, ninguna de las subcaracterísticas se encuentra altamente satisfechas (al menos con un 75% de
cumplimiento) lo que ocasiona que la categoría no se encuentre presente en el producto de Software.
Según lo establecido por el modelo MOSCA, ninguna de las Características de calidad evaluadas
53
se cumplen actualmente dentro de la aplicación. El mismo indica que cuando la característica de
funcionalidad no se cumple se considera que la calidad del producto de software es nula.
Sin embargo, a pesar de que ninguna de las categorías está presente existen ciertas
características que resultan más inhibidas dentro del grupo. Las mismas corresponden a Funcionalidad y
Portabilidad, al poseer el porcentaje de satisfacción más bajo. Las características de Mantenibilidad y
Eficiencia presentan un grado de satisfacción mayor acercándose al grado deseado.
En este punto lo importante es atacar aquellas características que se encuentran más inhibidas
dentro de la arquitectura; lo que en este caso corresponde a los atributos de Portabilidad y Funcionalidad.
En lo que respecta a la característica de Portabilidad, es necesario mencionar que muchos de los
escenarios propuestos para ese aspecto van a ser cumplidos una vez se lleve a cabo el proyecto de
migración de Visual Banker. Además, el valor de importancia otorgado a la Portabilidad (5) por parte de
los Stakeholders, es mucho menor al valor de importancia otorgado a la Funcionalidad (2).
Por las razones antes expuestas, el esfuerzo debería centrarse principalmente en resolver los
problemas relacionados con los escenarios correspondientes a este último atributo, pues el mismo posee
un porcentaje de satisfacción muy bajo y una importancia muy alta para el éxito del sistema.
Específicamente de Funcionalidad, serán implementados dos escenarios como parte del alcance de la
pasantía. Posteriormente se explicará en términos generales cuáles de los escenarios serán
implementados, cuáles no y por qué.
Por su parte, el atributo de Fiabilidad también posee un porcentaje de satisfacción relativamente
bajo, pero el grado de importancia otorgado al mismo también es bajo.
Al llevar a cabo la implementación de algunos escenarios es importante considerar que existen
decisiones arquitectónicas en los mismos que poseen un Tradeoff con otros atributos. En ese caso es
necesario analizar profundamente si vale la pena implementar un escenario que afecta negativamente a
un atributo de calidad que fue ponderado como importante. Tal es el caso de algunos de los escenarios
de Fiabilidad, específicamente los escenarios 25, 26 y 27. En los mismos se tiene un Tradeoff con
Seguridad (Funcionalidad) la cual fue catalogada por los Stakeholders como una subcaracterística de
gran importancia. En esta situación la gerencia debe definir si vale la pena implementarlos, arriesgando la
54
seguridad, o son descartados por afectar un punto tan sensible. En esta oportunidad, las propuestas
realizadas para mejorar esta característica no serán implementadas sino que se dejarán planteadas para
que el equipo de Plataforma junto con el resto de las áreas involucradas las ataque cuando considere
conveniente y cuente con los recursos necesarios para llevarlas a cabo.
En términos generales todas las propuestas planteadas tienen un gran impacto en la arquitectura
actual de la aplicación, pues implican una transformación dentro de la misma. Si todas las propuestas son
llevadas a cabo en algún momento, las vistas arquitectónicas se verían afectadas en diferentes maneras
y grados. Aquellas soluciones en las cuales se propone la creación de nuevos objetos, atributos, métodos
o clases implican una modificación de la vista lógica y de la vista de datos de los módulos que se vean
afectados o que vayan a hacer uso de los nuevos elementos creados. De igual manera, la
implementación del escenario en el que se propone la implantación de servidores regionales como parte
de la solución, afectará a la vista de despliegue que se tiene actualmente a nivel de las agencias. Si se
crean nuevos paquetes (o aplicaciones como se conocen en Smalltalk), la vista de implementación se
verá afectada. Por último, al agregar nuevas funcionalidades al sistema es posible que se produzcan
nuevos casos que ocasionarán la modificación de la vista que los engloba.
Como se puede apreciar en la explicación anterior las propuestas realizadas tienen un alto
impacto en la arquitectura, pues la idea es adaptar a la arquitectura existente para que cumpla con los
requerimientos funcionales y no funcionales que se encontraban especificados cuando la misma fue
desarrollada e incluso que cumpla con nuevos requerimientos que han surgido en la actualidad.
6.2. Escenarios y Propuestas
A continuación se presenta la Tabla 6.2 que contiene todos los escenarios con su respectiva
decisión o decisiones arquitectónicas actuales, así como las propuestas de mejora planteadas en cada
caso una vez finalizado el proceso de evaluación.
Nº
Escenario
1
Se requiere que el sistema
D1(A) Dispatcher capaz de manejar múltiples
Decisión Actual
maneje un alto volumen de
transacciones y protocolos de comunicación. (Permite
transacciones.
manejar del lado del servidor transacciones
Propuestas
simultáneas sin degradar el rendimiento).
D2(A) Línea activa en las agencias. (Permite que las
55
agencias se encuentren en todo momento procesando
transacciones).
2
Se requiere hacer
D1(A) Script de mantenimiento que se corre todos los
D2(P) Alertas inteligentes (que avisen cuando el
mantenimiento al Journal
días.
tamaño de la BD se encuentra cerca de un estado
dentro de la BD local para
crítico y así realizar el mantenimiento).
liberar espacio y mejorar
D3(P) Procesos de monitoreo por parte de la
los tiempos de respuesta.
aplicación. (la aplicación se encarga de realizar un
monitoreo constante del estado de la BD).
3
Se solicita autorización
D1(A) Objeto de envío de autorización remota (Objeto
D2(P) Objeto de interrupción de autorización
remota a un funcionario
particular de Visual Banker que permite hacer el envío
remota. Creación de un objeto que permita
válido que no se encuentra
de la autorización remota).
interrumpir la autorización remota si no se recibe
en su puesto de trabajo.
respuesta en un tiempo determinado y que la misma
se redireccione a otro funcionario.
4
Se realiza una transacción
D1(P) Clase genérica de Visual Banker que pueda
y se requiere conocer el
ser invocada desde diferentes puntos de la
estatus.
aplicación y que se encargue de mostrar los
mensajes de aviso y confirmación.
5
Se agrega una nueva
D1(A) La aplicación se presenta en una sola capa,
D2(P) Separación de la aplicación en capas, lo que
funcionalidad a la
como un cuerpo monolítico.
permite trabajar únicamente con la parte necesaria
aplicación.
6
sin afectar al resto.
Se requiere hacer un
D1(A) Clases de tipo Views y Formas reusables, que
D2(P) Separación de las capas lógica y de
cambio de interfaz dentro
se encuentran acopladas con el resto de la aplicación,
comunicación, de la capa de presentación. Se
de la aplicación
en forma monolítica.
trabajaría con archivos “.dll” que ya se encuentran
Ocurre una contingencia y
D1(A) Archivo plano que contiene las transacciones
D2(P) Switch automático por parte de las
se desea que todas las
que pueden trabajar bajo TCP/IP en caso de
transacciones para que comiencen a trabajar por
transacciones sean
contingencia.
TCP/IP. Ellas al detectar una falla en el canal de
precompilados.
7
capaces de trabajar en otro
comunicación comienzan a enviar los datos por el
canal de comunicación.
canal de contingencia, siempre y cuando los puertos
se encuentren liberados.
8
Se intenta realizar un
D1(A) Mecanismo de validación de usuario y
D2(P) Validación de usuario y password contra la
acceso no autorizado
password contra la BD local contenida en el servidor
BD local pero teniendo un archivo de log que
dentro de la aplicación.
de cada agencia.
permita registrar las modificaciones realizadas en la
BD (creación de nuevos usuarios, cambio de
passwords), así como el usuario que las realizó. Se
deben registrar los intentos fallidos de conexión por
usuarios o contraseñas no válidas.
9
Una persona accede al
D1(A) Mecanismo de validación del usuario genérico
D2(P) Se elimina el usuario genérico como
módulo de Mantenimiento
contra la BD local.
mecanismo de acceso al módulo de mantenimiento,
como usuario genérico.
manteniéndose únicamente como medida de
contingencia que se activa en caso de que todos los
usuarios de la agencia se queden bloqueados. La
creación del mismo se realizaría remotamente y en
forma centralizada a través de un Script. Tan pronto
el servidor sea reiniciado el usuario se elimina
automáticamente.
D3(P) Eliminación total del usuario genérico, el
acceso se hace por usuarios válidos que posean
ciertos perfiles. En caso de que todos los usuarios
permanezcan bloqueados los mismos se activan
remotamente.
10
56
Se desea tener un archivo
D1(A) Tabla en la BD que registra todas las
D2(P) Inserts en la tabla de Journal pero agregando
de log que permita registrar
transacciones fallidas y no fallidas realizadas en la BD
otros campos al registro como: IP de la máquina
todas las operaciones
(inserts en la tabla de Journal).
que envió la transacción, indicador sobre si la
realizadas por los usuarios
transacción fue local o remota, etc.
en la BD.
11
Se requiere que los
D1(A) Método de verificación y validación de usuarios
D2(P) Método de verificación contra la BD local,
cambios en los passwords
y contraseñas contra los registros guardados en la BD
además de método que garantice la creación de
de los usuarios se realicen
local de cada agencia.
claves robustas al exigir un número mínimo de
constantemente y que su
caracteres, combinación de letras y números.
deducción sea difícil.
Método que registre fecha de creación de las claves
para hacer validaciones de vencimiento y necesidad
de cambio de las mismas.
12
Se requiere que la data
D1(A) Método encargado de encriptar la data antes de
viaje encriptada.
ser enviada y desencriptarla al llegar al lugar de origen
(todo el proceso bajo un algoritmo de encriptamiento).
13
Se consulta una firma
D1(A) Llamada a un archivo ejecutable independiente
D2(P) Llamada a un ejecutable pero teniendo el
digitalizada.
de VB y externo a la aplicación.
código dentro de Visual Banker. (No tener un
ejecutable externo).
D3(P) Llamada a un ejecutable externo pero
solicitando un parámetro más de Usuario y
Password válido registrado dentro de Visual Banker.
Manteniendo una traza de todas las operaciones
aún cuando se ejecute fuera de la aplicación.
14
15
Ocurre el mecanismo de
D1(A) Dispatcher encargado de hacer el mecanismo
RollBack dentro de la BD.
de RollBack.
Ocurre una modificación en
D1(P) Registro de consulta y modificación de firma
la firma de un cliente.
para auditoria. Si se desea modificar la firma es
necesario presionar un botón a través del cual va a
ser posible registrar la modificación; es decir, la
aplicación no permite que la firma se edite
directamente, a menos que se presione el botón
correspondiente. Una vez enviada la solicitud, para
poder procesarla es necesario indicar el usuario y
clave de un supervisor.
16
Se desea que los
D1(A) Mecanismo que permita copiar diariamente todo
servidores locales se
lo que se encuentra en la base de datos local de cada
encuentren replicados en
agencia, en el AS400.
el servidor principal para
evitar pérdida de
información en caso de
fallas.
17
Se requiere que todos los
D1(P) Implementación de los requerimientos
requerimientos de
funcionales presentes en el documento ERS que
funcionalidad que presenta
todavía no han sido desarrollados.
la aplicación, se
encuentren cubiertos.
18
Se desea hacer la
D1(A) Paquete de IBM Tivoli que permite hacer la
D2(P) Tener servidores regionales (no uno por
instalación de una nueva
distribución remota del ejecutable al servidor de cada
agencia) a los cuales distribuir la nueva versión.
versión en todas las
una de las agencias. Al reiniciar cada estación de
Cada estación de trabajo copiaría directamente
agencias.
trabajo se realiza el refrescamiento local actualizando
desde el servidor que le corresponde (según su
cada versión.
ubicación física). Se eliminarían los servidores
locales.
19
Ocurre una falla en el
D1(A) Script de actualización de versiones encargado
D2(P) Script de actualización que además genere
57
refrescamiento de una
de copiar la nueva versión existente de la aplicación
un archivo de log en el que se indique la fecha/hora
máquina en una agencia.
en cada una de las estaciones de trabajo.
y máquinas en las cuales se llevó a cabo el
refrescamiento, así como los archivos actualizados
en cada una.
D3(P) Script de actualización además de un botón
que permita al usuario verificar la fecha y tamaño
del build instalado en su máquina para saber si se
produjo o no la actualización.
20
Se desea que la aplicación
D1(P) Encapsulamiento de los componentes que
se ejecute en otro sistema
son dependientes del Sistema de Operación.
de operación.
21
Se desea que la aplicación
D1(P) Encapsulamiento de los componentes
se adapte a otro manejador
dependientes del manteador de BD.
de BD.
22
El software intenta acceder
D1(A) Clase de Visual Banker encargada de manejar
D2(P) Mantener la clase que maneja las
a dispositivos I/O que no
los mensajes de error que se producen en los intentos
excepciones, pero además permitir que el sistema
se encuentran conectados.
fallidos de conexión a un dispositivo.
reconozca el dispositivo al cual se encuentra
conectado. En caso de algún error en la conexión él
reconoce automáticamente otro dispositivo
conectándose al mismo para enviar nuevamente la
solicitud de impresión.
23
Ocurre una falla durante la
D1(A) Dispatcher encargado de hacer RollBack.
D2(P) Dispatcher encargado de hacer RollBack,
ejecución de una
enviando transacciones por lotes en donde solo se
transacción
consideren en primera instancia aquellas que se
pueden reversar, si ese grupo pasa exitosamente,
se envían el resto de transacciones.
D3(P) Dispatcher encargado de hacer RollBack,
enviando todas las transacciones juntas pero
revisando el orden en el que el Disptacher acepta
dichas transacciones. Aquellas que no tienen
reverso se ejecutan al final, si alguna de las
anteriores falla, esas no llegan a ejecutarse.
24
Ocurre una falla en la
D1(A) El AS400 indica las transacciones que no
D2(P) Una vez que la aplicación recibe un error
aplicación.
pueden ser ejecutadas. Desde Visual Banker las
específico (de una transacción fallida no por datos
transacciones siempre son enviadas, por lo que en
incorrectos sino por la transacción propiamente
caso de que exista un error, se produce del lado del
dicha), ésta debe ser capaz de deshabilitar dicha
servidor.
transacción por un tiempo determinado para evitar
que esas peticiones salgan de VB al servidor, aún
cuando se sabe que no pueden ser ejecutadas.
25
Se desea que la aplicación
D1(A) Script de almacenamiento que realiza un export
D2(P) Script de almacenamiento que permita indicar
permita hacer backups en
de la BD y guarda el respaldo en una ruta estática ya
dinámicamente la ruta donde va a ser almacenado
diferentes dispositivos,
especificada, sin opción a cambiarla.
el respaldo de la Base de Datos.
Ocurre una falla en el canal
D1(P) Protocolos de comunicación, a través de los
D2(P) Crear perfiles de usuario para cada protocolo
principal de comunicación.
puertos, programas que se pueden correr, filtros
(SNA o TCP/IP). La aplicación debe reconocer el
estipulados, etc. La aplicación reconoce
perfil con el que se conecta cada usuario y
automáticamente cuando debe cambiar de canal.
dependiendo del mismo, enviar los datos por el
indicando donde va a ser
almacenado.
26
canal de comunicación que corresponde en cada
caso.
58
27
El servidor principal sufre
D1(P) Creación de una clase que detecte si se tiene
una falla crítica de
o no línea. Si la respuesta es negativa, activa
software. (Offline)
aquellas transacciones con las que se pueda
trabajar fuera de línea. En la noche cuando las
agencias se encuentren cerradas, se encarga de
enviar el lote de transacciones para que sean
efectivamente ejecutadas en el AS400.
Tabla 6.2: Resumen de Escenarios – Decisiones actuales y propuestas
6.3. Justificación de Escenarios Implementados
A continuación se presenta un breve análisis en el que se indica cuál de las propuestas de mejora
es la más indicada para cada escenario, así como las razones por las que algunos de ellos serán
implementados y otros no.
Escenario 1. Este escenario se cumple de manera satisfactoria dentro de la aplicación y no requiere
ningún tipo de cambio o mejora. Esto indica que en Visual Banker el atributo de Eficiencia en la
característica correspondiente a “Cantidad de Transacciones”, se está cumpliendo según los
requerimientos establecidos.
Escenario 2. Entre las soluciones planteadas para este escenario se considera que la decisión más
conveniente es la implementación de alertas inteligentes que indiquen el momento en el cual la tabla
llegó a un nivel crítico, sin la necesidad de esperar a que la BD colapse. Sin embargo, por su naturaleza,
la implementación de la solución requiere la participación activa del área de Base de Datos, pues la
misma es la que se encarga del mantenimiento y control de todas las tablas. De igual manera, implica
realizar un análisis estadístico sobre el número de registros que se insertan diariamente en el Journal y el
espacio que es efectivamente utilizado dentro de la tabla. Sin estos datos es prácticamente imposible fijar
un límite realista que permita que una vez que el mismo sea sobrepasado se dispare la alerta de
mantenimiento de forma automática.
Escenario 3. La opción propuesta en este escenario es permitir que la autorización escale a un
funcionario de rango superior; es decir, en caso de no recibirse respuesta en un tiempo determinado
automáticamente la solicitud será redireccionada. Esto permite minimizar el tiempo de espera requerido
para obtener una aprobación remota. Actualmente el área de PAO (Política y Autonomía Operativa) es la
59
encargada de llevar a cabo este procedimiento tal y como está siendo planteado. Por la razón antes
mencionada, no será implementada esta solución como parte de la pasantía.
Escenario 4. La solución planteada se basa en mostrar al usuario una pantalla en la cual se indique que
la transacción ya está siendo ejecutada. En caso de que se vuelva a enviar la misma transacción, el
sistema debe validar si se refiere a la misma solicitud; de ser así pide una confirmación por parte del
usuario indicando que una transacción similar se envió recientemente y está siendo ejecutada. La idea
principal es evitar que se envíen transacciones duplicadas, perdiéndose tiempo en la ejecución de las
mismas, cuando realmente no son necesarias. Además, permite mantener al usuario informado sobre la
ejecución de las transacciones. Esta solución es de alto impacto pues involucra a un conjunto de clases y
métodos ya definidos dentro de Visual Banker. Por el poco conocimiento que se tiene de la aplicación
propiamente dicha y de las relaciones existentes entre cada una de las clases y aplicaciones, es una
propuesta que no puede llevarse a cabo con la disponibilidad de tiempo que se tiene antes de la
culminación de la pasantía. La propuesta será tomada por el equipo de Plataforma para ser desarrollada
por los Analista de esta área.
Escenarios 5 y 6. Ambos escenarios son de alto impacto pues actualmente no existe separación en
capas de la aplicación, por lo que cualquier modificación en una parte afecta al resto del sistema. La
propuesta es trabajar con archivos “.dll” que ya se encuentren precompilados. A la hora de hacer alguna
modificación, bien sea de funcionalidad o de interfaz, el resto de la aplicación se verá afectada lo menos
posible. La separación en capas haría incluso mucho más fácil el proceso de pruebas y distribución
(mejor aprovechamiento del ancho de banda pues solo se envía lo que fue modificado). La solución
planteada no puede ser implementada durante el desarrollo de la pasantía por la poca disponibilidad de
tiempo con el que se cuenta y por tratarse de una modificación del alto impacto. El área de Plataforma
tomará las medidas pertinentes para formular un proyecto en el cual se lleve a cabo esta recomendación.
Escenario 7. La mejor opción para este escenario se refiere al Switch automático de las transacciones a
otro canal de comunicación. Sin embargo, este punto va a estar solucionado una vez que se realice la
migración total de la aplicación del protocolo SNA a protocolo de comunicación TCP/IP, proyecto que se
encuentra planteado para finales de este año.
60
Escenario 8. En este punto es fundamental que no solo se realice una comparación entre los datos
suministrados por el usuario y los almacenados en la BD para permitir el acceso, sino que también se
lleve un registro de los intentos fallidos de conexión (como consecuencia de claves o usuarios no
válidos), así como de las modificaciones de perfiles, usuarios y claves realizadas dentro de la BD. Toda la
información registrada en el archivo de log es empleada principalmente por Auditoria; esto quiere decir
que lo ideal sería tener un servidor dedicado (o disco duro dependiendo del espacio requerido) para esta
área en el que se guarde el log, pues conseguir espacio en el servidor AS400 es sumamente difícil y
costoso. Queda de parte del área de Auditoria facilitar los recursos para poder implementar la propuesta.
Escenario 9. De las propuestas arquitectónicas realizadas la que se consideró más conveniente en ésta
oportunidad es la de eliminación del usuario genérico, pero con la opción de poder crearlo y eliminarlo en
un momento determinado como medida de contingencia. Esto quiere decir que no se permitirá el acceso
normal a través de dicho usuario, sino únicamente en el caso en el que en una agencia todos los
usuarios se borren o queden bloqueados. En esa situación se creará un usuario genérico temporal a
través de un Script y el mismo será eliminado una vez el servidor sea reiniciado. Esta consideración
involucra no sólo a Plataforma sino también a las áreas de Soporte de Agencia y Base de Datos, por lo
que no se tomará en cuenta dentro de las opciones de implementación de la pasantía.
Escenario 10. Como en el caso del escenario número 8, la solución propuesta en esta oportunidad se
basa en trabajar con un archivo de Log. La idea es agregarle al mismo ciertos campos que permitan tener
un mayor control sobre las transacciones en aspectos puntuales como: el IP de la máquina de la cual
salió la transacción y si la autorización de la misma se realizó en forma local o remota. Nuevamente
involucra al área de Auditoria, la cual tiene que suministrar los recursos para poder hacer las mejoras
correspondientes. El área de Plataforma también se ve involucrada pues es ella la que realiza la
implementación; sin embargo, la parte de la aplicación que se ve involucrada para poder implementar la
solución es sumamente compleja por lo que se escapa del alcance de la pasantía.
Escenario 11. Este escenario va a ser atacado como parte de la fase de implementación de la pasantía.
Se basa principalmente en la creación de un mecanismo encargado de recordar a los usuarios la
renovación constante de sus claves (indicando la fecha de vencimiento de las mismas), asegurando que
61
se cambien constantemente. Además se implementará otro mecanismo que garantice la creación de
claves robustas; es decir, que exija un número mínimo de caracteres así como la combinación de
números y letras.
Escenario 12. Para este escenario no se realizó ninguna propuesta pues ya se cumple correctamente.
Escenario 13. Por tratarse de un Software propietario, de las dos propuestas planteadas para este
escenario se consideró que lo ideal es mantener de forma externa el archivo ejecutable de consulta de
firmas, pero pasándole otros parámetros (como el usuario y la clave) con el fin de garantizar que quien
esté corriendo el archivo sea un usuario válido. De ésta manera no importa el lugar desde el cual sea
invocado el ejecutable (Visual Banker o externamente) ya que siempre se tendrá control de acceso y
registro de las consultas realizadas. Para llevar a cabo la implementación de esta solución, es necesario
contactar al propietario de HFirmas con el fin de que realice las modificaciones necesarias planteadas en
la recomendación.
Escenario 14. Para este escenario no se realizó ninguna propuesta pues ya se cumple correctamente.
Escenario 15. Actualmente no existe ningún mecanismo que permita detectar cuando una firma fue
modificada. El planteamiento se basa en no permitir que la firma sea editada directamente; es decir, que
se cree un botón de edición que sea indispensable presionar para poder realizar la modificación. De esta
manera se podría llevar un control de los usuarios que tuvieron acceso o modificaron alguna de las
firmas. Este planteamiento está siendo considerado y corresponde a un área de la organización
denominada HIPER, por lo que no forma parte de las propuestas de implementación de la pasantía.
Escenario 16. Actualmente los servidores locales no se encuentran replicados en el servidor principal.
La propuesta debe ser estudiada por diferentes áreas de la organización puesto que involucra aspectos
relacionados con el costo, disponibilidad de espacio y mantenimiento de los mismos. Es necesario valorar
si realmente es indispensable replicar esa información (empleada principalmente por el área de Auditoria
en caso de fraudes) o si esto representa una opción más costosa que el problema propiamente dicho.
Escenario 17. La propuesta realizada se basa en la implementación de todos los requerimientos
funcionales que actualmente no se encuentran cubiertos. Por razones de tiempo, solo se escogió uno de
62
esos requerimientos para ser implementado como parte del alcance de la pasantía. El mismo se trata de
la creación de una transacción de recaudaciones para un cliente específico del banco denominado
“Droguería Nena”. En el capitulo de Implementación serán presentados todos los detalles.
Escenario 18. La solución planteada se basa en la instalación de servidores regionales, disminuyendo de
esta manera la cantidad de servidores locales a los cuales hay que distribuir la versión. Sin embargo, por
razones de costo y logística esta solución no puede ser llevada a cabo actualmente, pues es necesario
que la solicitud pase por todo un proceso de análisis para su posterior aprobación.
Escenario 19. La recomendación propuesta en este escenario va a ser implementada como parte del
alcance de la Pasantía. Se basa principalmente en establecer en las pantallas de taquilla y plataforma un
pequeño botón que permita al usuario (taquillero o promotor) verificar la versión, tamaño y fecha del
Build que se encuentra instalado en su estación de trabajo, para poder corroborar en cualquier momento
si el refrescamiento se hizo efectivo o no. Esto ayuda en gran medida al área de Plataforma, pues al
reportarse un error lo primero que se debe verificar es la versión del archivo, en caso de tener una
versión incorrecta se descartan el resto de posibles problemas y se procede a su actualización.
Escenarios 20 y 21. Ambos escenarios serán cubiertos cuando se realice la migración de Visual Banker.
Escenario 22. La solución propuesta involucra grandes modificaciones a la aplicación para permitir que
la misma sea capaz de reconocer automáticamente los dispositivos I/O, además de cambiar de
dispositivo en el momento que ocurra una falla. Debido a la complejidad de la solución y a la
disponibilidad de tiempo con la que se cuenta en la pasantía, esta propuesta será tomada en cuenta por
el área de Plataforma para ser implementada por ellos mismos.
Escenario 23. Las dos decisiones arquitectónicas planteadas, además de la decisión arquitectónica
existente, implican una reingeniería total de aquellas transacciones que no se pueden reversar. Esto
ocasiona un alto impacto dentro de la aplicación, lo cual consumiría más tiempo del que se tiene
disponible para la culminación de la pasantía.
Escenario 24.
La solución planteada involucra la participación del área de AS400, pues son ellos
quienes tienen que indicar cuanto tiempo debería permanecer la transacción deshabilitada del lado de
63
Visual Banker, antes de que el servidor pueda volver a ejecutarla. Por esta razón no va a ser
implementado, pues involucra a otra área que no cuenta actualmente con los recursos necesarios para
llevar a cabo el desarrollo.
Escenario 25. La decisión planteada involucra la participación del área de auditoria, la cual debe facilitar
los recursos (disco, servidor, etc.) para poder ofrecer otras opciones de almacenamiento de la réplica. Sin
la existencia de los mismos no tiene sentido realizar la modificación del Script, ya que de todas maneras
no se contaría con diferentes unidades físicas en las que hacer el respaldo.
Escenario 26. Una vez que se lleve a cabo el proyecto de migración de Visual Banker, el canal de
comunicación que va a ser empleado es TCP/IP. Este escenario quedaría cubierto una vez se lleve a
cabo dicho proyecto.
Escenario 27. Este escenario es de gran importancia pues tiene un punto de Tradeoff con el atributo de
seguridad. Según la opinión de diferentes áreas de la organización no es conveniente implementar la
propuesta realizada pues el atributo de seguridad es considerado muy importante por el Banco, por lo
que no debería ser amenazado por ninguno de los otros atributos de calidad. Es preferible tener la falla
en fiabilidad, si de esta manera se garantiza un mayor porcentaje de seguridad.
Como se puede observar en la explicación de los escenarios, las propuestas efectivas de
implementación consideradas dentro del alcance de la pasantía se reducen a tres. Sin embargo, es
importante destacar que los escenarios fueron seleccionados tomando en cuenta diferentes criterios.
El primero de ellos se basó en escoger aquellos escenarios que podían ser implementados
dentro del tiempo restante de la pasantía. Existían diferentes escenarios planteados que por la
complejidad de la aplicación no podían ser implementados en las semanas que quedaban, pues la
plataforma con la que se debió trabajar era bastante cerrada y habría que profundizar en la misma para
poder llevar a cabo el desarrollo. Esto implicaría invertir una cantidad considerable de tiempo que no
había sido dispuesto, para poder llevar a cabo dicho proceso.
El segundo criterio considerado se basó en la importancia que tenía la implementación del
mismo para el éxito del sistema; por esta razón se tomaron en cuenta las ponderaciones otorgadas por
64
los Stakeholders cuando los escenarios fueron priorizados.
Por último, se filtraron aquellos escenarios que impactaban o requerían la participación activa de
otras áreas de la organización, pues las mismas ya tenían comprometidos sus recursos en los proyectos
que habían sido planificados desde el año anterior. Esta situación limitó la participación de dichas áreas
pues dentro del banco se trabaja a través de un sistema de planificación de proyectos que permite
especificar aquellos que deben ser cumplidos en un período de tiempo determinado y que no pueden ser
pospuestos por nuevos proyectos a menos que se lleve a cabo un proceso de solicitud y aprobación por
parte de la alta gerencia.
En términos generales, los escenarios que fueron escogidos podían ser implementados en el
tiempo restante de pasantía, poseían una alta importancia para el proyecto y no involucraban a otras
áreas diferentes al área de Plataforma. Dos de los escenarios pertenecían al atributo de funcionalidad
que tiene una gran importancia y alta prioridad otorgada por los Stakeholders y que se encuentra
sumamente inhibido. El tercer escenario pertenecía al atributo de portabilidad, que aunque no le fue
otorgada una importancia tan grande como a funcionalidad, poseía un porcentaje de satisfacción
bastante bajo.
65
CAPÍTULO 7 RESULTADOS DE LA IMPLEMENTACIÓN
En el siguiente capítulo se pretende dar una aproximación sobre el proceso de implementación
que fue llevado a cabo durante la pasantía. En el mismo se muestran los resultados del desarrollo de
cada uno de los escenarios que fueron escogidos, así como la información contenida en los diferentes
artefactos que fueron realizados para documentar la nueva arquitectura.
En primer lugar, para poder llevar a cabo la implementación, fue necesario comprender el
funcionamiento del entorno de desarrollo, así como la sintaxis del lenguaje de programación utilizado. Por
esta razón, se dedicaron dos semanas de la pasantía para conocer un poco más sobre Visual Age for
Smalltalk v 3.0, además de la aplicación propiamente dicha y de todos los elementos que la componen.
Este proceso no se encontraba definido en la planificación original de la pasantía por lo que fue necesario
compartir el tiempo disponible e ir realizando actividades en forma paralela. El estudio de la plataforma se
basó principalmente en la familiarización con los diferentes paquetes y clases de cada uno de los
módulos con los que se trabajó durante el desarrollo, mientras que el estudio del lenguaje se basó en la
realización de ejercicios sencillos para conocer y comprender la sintaxis del mismo.
En ese sentido fue importante el apoyo de la Gerencia de Plataforma, pues los Analistas que
trabajan en la misma poseen amplios conocimientos sobre la aplicación. Todas las dudas e
inconvenientes surgidos fueron solucionados gracias a la ayuda brindada por los mismos.
Es importante mencionar que durante esta etapa de la pasantía se realizó un esfuerzo para
cumplir con las actividades de Implementación y Pruebas definidas en la metodología Rupcorb como
parte de la fase de Construcción. Para ello fue necesario realizar el Documento Visión de la nueva parte
implementada dentro de Visual Banker, con el fin de identificar los problemas que iban a ser solucionados
con el nuevo desarrollo, además de los Stakeholders y usuarios involucrados en el proyecto, así como
diversas características de la nueva arquitectura. Dicho documento puede ser consultado a través del
APÉNDICE F.
Posteriormente, se realizó un documento de Especificaciones de Requerimientos de Software en
el cual se detallaron los requerimientos funcionales asociados a cada uno de los escenarios, así como los
66
nuevos casos de uso que reflejaban las diferentes funcionalidades que iban a ser implementadas. El ERS
para la nueva arquitectura puede ser consultado en el APÉNDICE G.
Por último se elaboró un nuevo Documento de Arquitectura a través del cual se registraron los
cambios sufridos en las diferentes vistas arquitectónicas de la aplicación original. En dicho documento
sólo se hace referencia a las vistas que sufrieron algún tipo de cambio, las que permanecen igual no son
mencionadas. El DAS Propuesto de Visual Banker puede ser consultado a través del APÉNDICE H.
En términos generales, todos estos artefactos permitieron documentar la nueva arquitectura y
dejar asentada toda la información sobre la misma para que pueda ser usada por el área de Plataforma
cuando considere necesario.
Una vez levantada la información, se procedió con la implementación propiamente dicha. El
primer escenario atacado fue el relacionado con el atributo de Funcionalidad, específicamente con la
característica Ajuste a los Propósitos. Para ello se creó un módulo a través del cual se pudieran realizar
las recaudaciones pertenecientes a un cliente de la organización denominado “Droguería Nena”.
En la imagen de la izquierda de la Figura 7.1 es posible observar la pantalla general del módulo
de Taquilla en la que se debe seleccionar la opción “Pago de Servicios” y la transacción “Recaudaciones
(6496)” para poder ingresar a la funcionalidad desarrollada. En la imagen de la derecha se muestra la
pantalla a la que se llega una vez seleccionada la opción y la transacción antes mencionada. En la misma
se puede observar la lista que contiene los diferentes clientes asociados a la transacción, presentándose
en la última posición “Droguería Nena”.
Los campos que se manejan para este cliente particular se refieren a: Código de Cliente
(corresponde al código asignado al cliente por el departamento de cobranzas de Droguería Nena), #
Documento (corresponde al número del documento o factura a cancelar por el cliente) e Importe (monto
a cancelar para el documento o factura), además de los datos necesarios que se solicitan dependiendo
del tipo de forma de pago permitido para cada cliente. En este caso los pagos permitidos son Cheque
Otros Bancos, Cargo en Cuenta y Efectivo /Cheque Banesco. Los campos asociados a los mismos se
refieren a CI Depositante, Nacionalidad, Código de Cuenta del Cliente, Monto Efectivo, Monto Total,
Referencia, entre otros.
67
Por su parte, los procedimientos desarrollados para “Droguería Nena” fueron: validación de los
campos (únicamente números y longitudes correctas para cada uno), que solo se pudieran ingresar como
máximo 4 elementos dentro del contenedor (pares #documento, importe), que no se agregara un #
documento sin un importe asociado, que los montos de total y subtotal suministrados coincidieran,
método para el cálculo del subtotal, método para ingresar y eliminar del container, validación del código
de cliente a través del algoritmo Módulo 11 suministrado por “Droguería Nena”, entre otros.
Figura 7.1: Pantallas de Implementación – Funcionalidad
Con la implementación realizada se cumple el escenario de “Ajuste a los Propósitos” pues fue
cubierta una funcionalidad específica de la aplicación que no se cumplía anteriormente. De esta manera
el banco puede satisfacer las necesidades de sus clientes, resolviendo de manera rápida y eficiente las
solicitudes realizadas por los mismos.
El segundo escenario implementado se refiere al escenario correspondiente a las versiones
actualizadas dentro de las estaciones de trabajo de cada agencia el cual se encuentra relacionado con el
atributo de Portabilidad. En este escenario no se tenia seguridad sobre la actualización del Build
distribuido, por lo que se implementó un mecanismo sencillo que permitiera a cada uno de los usuarios
de la aplicación saber el tamaño y fecha del Build instalado en su máquina para poder determinar si se
tenía la versión correcta y si la actualización había sido efectiva.
La implementación realizada beneficia en gran medida al proceso de distribución y además
contribuye con la continuidad de operaciones dentro de las agencias, pues permite detectar rápidamente
68
cuáles son las máquinas que no se actualizaron correctamente. De esta manera no se pierde tiempo
tratando de averiguar cuál es el error y se procede a realizar una nueva distribución remota que permita a
los usuarios contar con las actualizaciones correspondientes y seguir prestando el servicio a los clientes.
Esto permite que el banco continúe con sus operaciones normales y que no se pierdan grandes
cantidades de dinero como consecuencia de errores en las diferentes estaciones de trabajo. El hecho de
que una agencia permanezca cerrada o trabajando con una capacidad menor a la que posee ocasiona a
la organización pérdidas millonarias.
En la Figura 7.2 se muestra la pantalla principal de Taquilla que contiene el botón a través del
cual se activa el mecanismo para mostrar la versión. En la imagen de la izquierda se muestra el mensaje
con la información, mientras que en la imagen de la derecha se muestra el mensaje de error que aparece
cuando no se consigue el archivo “.ini” que contiene los datos que deben ser mostrados al usuario.
Figura 7.2 Pantallas de Implementación – Portabilidad
Este escenario también fue desarrollado para el módulo de Plataforma. La funcionalidad es la
misma que la mostrada en el módulo de Taquilla pues se basa en abrir una pantalla a través de la cual se
muestra la información del tamaño y fecha de actualización del ejecutable instalado en esa máquina. Sin
embargo, la implementación realizada en este caso se encuentra adaptada a las pantallas de dicho
módulo.
El tercer escenario implementado corresponde al cambio constante de los passwords de los
usuarios y a la creación de claves robustas por parte de los mismos; éste se relaciona con el atributo de
69
calidad denominado Funcionalidad. En este caso, la solución planteada se enfocó en la implementación
de mecanismos que permitieran alcanzar dichos objetivos, garantizando mayores niveles de seguridad en
las agencias en cuanto a la información confidencial que allí se maneja.
El primero de los mecanismos se basó en la verificación de que las claves seleccionadas por los
usuarios tuvieran cierto grado de seguridad; es decir, un número mínimo de caracteres (8), combinación
de letras y números, presencia de letras mayúsculas, etc. El segundo método se basó en validar que la
clave suministrada por el usuario no se encontrara vencida; es decir, que el tiempo que tenía la clave de
creada no fuera mayor al tiempo de expiración definido. Dicho tiempo de expiración fue manejado dentro
de la aplicación como un parámetro configurable que puede ser especificado en un archivo “.ini”, el cual
es distribuido junto con el Build a todas las agencias. Se decidió realizarlo de esa manera pues en
primera instancia no se tiene conocimiento sobre el impacto que va a tener la implementación y puesta
en marcha de este escenario en todas las estaciones de trabajo de las agencias ya que los usuarios no
están acostumbrados a trabajar de esa manera y actualmente pueden tener el mismo password por un
tiempo ilimitado.
Algunas de las pantallas desarrolladas para este caso se muestran en las Figuras 7.3 y 7.4. En la
primera de ellas se presenta, a mano izquierda, el mensaje mostrado al usuario cuando el mismo va a
iniciar sesión y su clave ya expiró. Inmediatamente el sistema lo redirecciona a la pantalla que se
encuentra a mano derecha, a través de la cual el usuario puede y debe realizar el cambio de su clave
para poder ingresar a la aplicación.
Figura 7.3 Pantallas de Implementación – Seguridad
Dentro de esta última ventana se encuentran definidas ciertas validaciones como el hecho de que
la clave nueva clave y la confirmación coincidan.
70
En las pantallas de la Figura 7.4 se presentan algunas de las validaciones realizadas para
garantizar la creación de claves robustas. Este método es llamado cuando el usuario va a realizar el
cambio de password por expiración o cuando el usuario decide cambiar su clave por voluntad propia. El
resto de las pantallas elaboradas durante la implementación de las soluciones propuestas para este y el
resto de los escenarios, pueden ser consultadas a través del APÉNDICE I: Pantallas.
Figura 7.4 Pantallas de Implementación – Seguridad
Con la implementación de esta solución se logró incrementar el porcentaje de cumplimiento del
atributo Funcionalidad, específicamente en la subcaracterística Seguridad. Esto permitirá aumentar el
grado de seguridad de los datos manejados dentro de todas las agencias, además de crear conciencia
por parte de los usuarios de la aplicación para comprender la importancia de la selección de claves
robustas y del cambio continuo de las mismas. De igual manera, esto ocasionará que los clientes de la
organización posean una mayor confianza y que realicen sus inversiones y negocios con tranquilidad, al
saber que la institución cuenta con mecanismos seguros a través de los cuales se respaldan los intereses
de todos sus clientes.
Actualmente este escenario no se encuentra implementado en el módulo de Plataforma pues se
presentaron ciertos inconvenientes que retrasaron la planificación e impidieron su desarrollo. Sin
embargo, se espera que para el día de la presentación final de la pasantía el mismo ya se encuentre
completamente implementado y pueda ser mostrado en pleno funcionamiento.
Por último, es importante mencionar que el diseño de todas las pantallas generadas se realizó
siguiendo el estándar establecido por la gerencia, manteniendo el mismo formato que había sido definido
en un principio dentro de cada uno de los módulos.
71
Después de realizar la implementación propiamente dicha, se procedió con la disciplina de
Pruebas. La misma fue llevada a cabo con la participación de una Analista del área de Calidad y
Procesos, quien se encargó de realizar las pruebas integrales así como las pruebas certificadas con el
usuario para que una vez aprobadas las mismas se pudiera realizar el pase a producción.
Durante esta etapa fue necesario contar con el apoyo de diferentes áreas, especialmente con el
área de AS400, que tuvieron una participación activa durante el proceso de evaluación y prueba de las
implementaciones realizadas. En varias oportunidades la planificación se vio afectada por la dependencia
que existía con las mismas ya que si ellas no suministraban la información necesaria o no cumplían con
sus responsabilidades, todo el trabajo se retrasaba. En este sentido fue importante la coordinación con
todas las personas y áreas involucradas para concretar diferentes reuniones que permitieran llevar a
cabo este proceso de manera satisfactoria.
72
CAPÍTULO 8 CONCLUSIONES Y RECOMENDACIONES
La evaluación arquitectónica de una aplicación que ya se encuentra en producción requiere de un
proceso meticuloso que permita analizar la arquitectura actual e identificar los puntos sensibles de la
misma, para poder realizar las propuestas de mejora en aquellos aspectos de calidad que no se cumplan
correctamente. Después de llevar a cabo la evaluación arquitectónica de Visual Banker es posible
concluir lo siguiente:
ƒ Las características de calidad más deseadas en la arquitectura de Visual Banker se refieren a
Eficiencia y Funcionalidad. Esta decisión fue tomada por los Stakeholders principalmente por la cantidad
de transacciones que deben ser manejadas diariamente por la aplicación, porque los tiempos de
respuesta deben ser lo más pequeños posible, porque garantizar la seguridad de las operaciones y datos
es sumamente importante para el negocio y porque se deben satisfacer las necesidades de un gran
número de clientes.
ƒ Después de realizar el análisis de características por juicio de experto y apoyados por el modelo de
calidad MOSCA, es posible afirmar que ninguna de las características de calidad definidas en el UT se
encuentra presente en la arquitectura actual. Así mismo, las características más propiciadas dentro del
grupo (aunque no lleguen al porcentaje de satisfacción deseado) se refieren a Eficiencia y Mantenibilidad,
mientras que las más inhibidas son Funcionalidad y Portabilidad.
ƒ La metodología Rupcorb puede ser empleada como mecanismo para realizar el análisis y
documentación de la arquitectura de un sistema ya desarrollado.
ƒ A pesar de que la naturaleza de la metodología se basa en el desarrollo de software, la misma
también puede ser empleada en sistemas ya desarrollados, aplicando ingeniería de reverso. En
este caso en particular, Rupcorb permitió la creación de diferentes artefactos que ayudaron a
comprender la estructura y composición del sistema antes de dar inicio a la evaluación.
ƒ La generación de la documentación fue de gran importancia pues permitió definir las metas del
negocio y los objetivos arquitectónicos que debían ser satisfechos por la aplicación, además de las
especificaciones funcionales y no funcionales y las vistas arquitectónicas de visual Banker.
73
ƒ Así mismo, como el proceso involucró a personas de diferentes áreas (no necesariamente
técnicas), los artefactos se comportaron como un elemento a través del cual fue posible explicar
fácilmente la arquitectura a todos los participantes.
ƒ Rupcorb se comporta como un marco metodológico perfecto para el diseño e implementación de la
nueva arquitectura de la aplicación una vez finalizado el proceso de evaluación. De esta manera se
cumple el objetivo fundamental de la misma: desarrollo de software.
ƒ El método ATAM permitió obtener los requerimientos de los atributos de calidad que eran importantes
para lograr las metas del negocio, a través de la especificación de los escenarios en el Utility Tree. Sin
embargo, es importante considerar que:
ƒ Se enfoca únicamente en el proceso de evaluación, sin llegar al análisis de la arquitectura para la
transformación. Podría dar buenos resultados en situaciones en las que la arquitectura no presente
ninguna falla en cuanto a los atributos de calidad. Sin embargo, en caso de que algo no funcione
correctamente, el método no propone ningún mecanismo a través del cual sea posible diseñar una
nueva arquitectura que permita solventar el problema. En ese sentido el método Bosch es mucho
más completo pues abarca tanto la evaluación como la transformación.
ƒ No es un método tan robusto como lo sería un método estadístico pues para determinar el grado
de cumplimiento de los escenarios se basa en el análisis de características por juicio de experto, lo
que se traduce en un mecanismo poco confiable si los expertos escogidos no son los más
indicados.
ƒ Posee ciertas ventajas sobre otros métodos de evaluación arquitectónica como ARID y SAAM,
pues el mismo contempla dos conceptos importantes que no son considerados en los otros
métodos. Estos se refieren a los puntos de sensibilidad y de Tradeoff, los cuales permiten no solo
evaluar la arquitectura en base a ciertos atributos de calidad, sino también identificar que atributos
interactúan con otros.
ƒ Se cubrió tanto el objetivo general como los objetivos específicos que fueron planteados al inicio del
proyecto. El área de plataforma y la organización en general cuentan con los resultados obtenidos luego
74
de haber realizado la evaluación arquitectónica de Visual Banker, encontrándose en la capacidad de
plantear proyectos futuros que de alguna manera permitieran representar tangiblemente las mejoras
propuestas como resultado del proyecto.
ƒ Se obtuvo un logro adicional que se basó en aprender y conocer tanto el lenguaje de programación
como la plataforma, los cuales eran completamente desconocidos antes de dar inicio al proyecto. Esto se
convirtió en uno de los principales retos que hubo que superar para poder seguir adelante y cumplir con
los objetivos propuestos ya que la aplicación con la que se trabajó es realmente compleja pues se
constituye como una plataforma sumamente cerrada que se compone de una gran cantidad de elementos
que deben ser estudiados minuciosamente para que puedan ser comprendidos.
Recomendaciones
ƒ Como primera recomendación para la institución y áreas que la componen, se recuerda la importancia
que tiene mantener actualizada la documentación generada como parte del proceso de desarrollo, pues
la misma puede ser de gran utilidad en otros proyectos que requieran tener un amplio conocimiento sobre
la aplicación. Es por esta razón que todos los artefactos deben ser mantenidos y actualizados pues
facilitan notablemente el trabajo, además de ser la única manera de garantizar que no se va a perder el
esfuerzo realizado durante la creación de los mismos.
ƒ Es importante tener en cuenta que el proceso de evaluación y transformación de la arquitectura es una
tarea difícil pues ésta requiere del compromiso de todos los Stakeholders. Para futuras evaluaciones la
organización debe tener en cuenta que lo más importante es contar con la participación activa de todas
las áreas involucradas, así como con la comprensión por parte de ellas sobre el proceso de evaluación y
la convicción sobre la importancia que tiene el mismo como mecanismo para garantizar sistemas de
información que cumplan con los objetivos y reglas de calidad establecidas por el banco.
ƒ Para futuras pasantías que hagan uso del método ATAM como mecanismo para llevar a cabo la
evaluación arquitectónica, es posible plantear como alcance especial la evaluación del método utilizado
en base a los resultados obtenidos. Esto con el fin de determinar si efectivamente es el más indicado
para llevar a cabo este tipo de proyectos.
75
ƒ Para futuras pasantía considerar dentro de la planificación tiempo suficiente para poder interactuar tanto
con el lenguaje de programación utilizado como con la plataforma sobre la que se sustenta la aplicación.
ƒ Por último y como recomendación personal, es importante recordar que los Stakeholders dieron al
atributo de Fiabilidad la ponderación más baja dentro de la clasificación. Sin embargo, es recomendable
considerar a este atributo como parte de las características de calidad más importantes pues por la
naturaleza de la aplicación y los servicios que presta, la misma juega un papel fundamental. Fallas en la
disponibilidad, recuperabilidad o madurez de la aplicación, podrían ocasionar grandes pérdidas a la
organización, al dejar de prestar sus servicios.
76
REFERENCIAS BIBLIOGRÁFICAS
[Barbacci, 95] Barbacci, M.; Klein, M.; Longstaff, T. y Weinstock, C.,”Quality Attributes”, Carnegie Mellon
University. Technical Report. Consultado en Mayo 2006 en el sitio Web:
http://www.sei.cmu.edu/publications/documents/ 95.reports/95.tr.021.htm, 1995.
[Bass, Kazman, Clements, 2003] Bass, L.; Kazman, R. y Clements, P., “Software Architecture in
Practice”, Editorial Addison-Wesley, 2003.
[Bosch, 2000] Bosch J. “Design and Use of Software Architecture”, Addison Wesley, 2000.
[Camacho, Cardeso, Nuñez, 2004] Camacho, E.; Cardeso, F. y Nuñez G., “Arquitectura de Software
Guía de Estudio”, Abril 2004.
[Clements, Kazman, Klein, 2002] Clements, P.; Kazman, R. y Klein, M., “Evaluating Software
Architectures, Methods and Case Studies”, Editorial Addison-Wesley, 2002.
[Dávila, Germán, Crutas, García, 2004] Dávila, M.; Germán, M.; Crutas, D. y García, A., “Evaluación de
Arquitecturas de Software”, 2004.
[Hernández, 2006] Hernández, J., “Arquitectura de Software: importancia de su ciclo de vida", 2006.
[IEEE Std 1471-2000] IEEE Estándar 1471-2000, “Recommended Practice for Architectural Description of
Software-Intensive Systems”.
[ISO, 00] ISO 9126-1, “Software Engineering – product quality – part 1: Quality Model”, 2000.
[Kazman, 98] Kazman, R.; Klein, M.; Barbacci, M.; Longstaff, T.; Lipson, H. y Carriere J., “The
Architecture Tradeoff Analysis Method”, 1998. Consultado en Junio 2006 en el sitio Web:
http://www.sei.cmu.edu/pub/documents/98.reports/pdf/98tr008.pdf
[Kazman, Klein, 99] Kazman, R.; Klein, M., “Attribute-Based Architectural Styles”, 1999. Consultado en:
http://www.sei.cmu.edu/pub/documents/99.reports/pdf/99tr022.pdf#search=%22AttributeBased%20Architectural%20Styles%20kazman%2099%22
[Krutchen, 95] Kruchten, P., “Architectural Blueprints—The “4+1” View Model of Software Architecture”.
Consultado en Mayo 2006 en el sitio Web: http://www.win.tue.nl/~mchaudro/sa2004/Kruchten4+1.pdf
77
[Kruchten, 2003] Kruchten, P., “Using the RUP to evolve a legacy system”, 18 Nov 2003. Consultado en
Julio 2006 en el sistio Web: http://www-128.ibm.com/developerworks/rational/library/389.html
[Losavio, 2002] Losavio, F., “Quality Models to Design Software Architecture”, 2002. Consultado Agosto
2006 en: http://www.jot.fm/issues/issue_2002_09/article4
[Mendoza, Pérez, Grimán, 2004] Mendoza, L.; Pérez, M. y Grimán, A., “Prototipo de Modelo Sistémico
de Calidad (MOSCA) del Software”, 2004. Consultado en Septiembre 2006 en el sitio Web:
http://www.ejournal.unam.mx/compuysistemas/vol0803/CYS08304.pdf#search=%22modelo%20calidad%20MOSCA%22
[RUP® Glossary, 2003] RUP Glossary (Versión 2003.06.01), [Programa de computación]:Rational, 2003.
[Rupcorb, 2004] Rational Unified Process Corporativo Banesco, Basado en RUP (Versión 2003.06.01)
[Programa de computación] : Rational, 2004.
Otra Bibliografía consultada:
ƒ Grupo de Investigación en Ingeniería de Software, “La importancia de la Arquitectura en el Desarrollo
de Software de Calidad”, Febrero 2005. Consultado en Agosto 2006 en:
http://www.eafit.edu.co/NR/rdonlyres/223A8F47-27B5-4EB8-B6954097F745D701/0/Arquitectura.pdf#search=%22ATAM%20%2B%20arquitectura%22
ƒ Pérez, M.; Griman, A.; Valdosera, L.; Mendoza, L. y Méndez E., “Issues for evaluating Reliability in
Software Architectures”, 2926-2931, (2005).
ƒ Pérez, M.; Mendoza, L.; Parada, D. y Di Paula, G., “Evaluación Arquitectónica de un Software Basado
en Componentes”, Universidad Simón Bolívar, Caracas – Venezuela, Universidad Nacional Experimental
Politécnica de la Fuerza Armada Nacional –UNEFA-Caracas – Venezuela.
ƒ Quintanilla, G., “Mejores prácticas de desarrollo de Software”. Consultado en Junio 2006 en:
http://www.tidap.gob.mx/Presentaciones/talleres/p_quintanilla.ppt
ƒ Reynoso, B., “Introducción a la Arquitectura de Software”. Consultado en Junio 2006 en:
http://download.microsoft.com/download/4/F/F/4FF88340-43CC-4C5B-8E50-09002969D0DD/2005112278
ARC-BA.ppt#1
ƒ Reynoso, C. y Kicillof, N., “Estilos y Patrones en la Estrategia de Arquitectura de Microsoft”, 2004.
Consultado en Julio 2006 en: http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/style.asp
79
APÉNDICE A
Visual Banker
Especificaciones de Requerimientos del Software
Versión 1.0
80
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
Versión: 1.0
Fecha: 08/05/2006
Historia de Revisiones
Fecha
Versión
Descripción
Autor
08/05/2006
1.0
Inicio del documento
Irene García
81
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
Versión: 1.0
Fecha: 08/05/2006
Tabla de Contenido
1. INTRODUCCIÓN..................................................................................................................................... 83
1.1 ALCANCE ....................................................................................................................................83
1.2 DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS ..............................................................................83
1.3 REFERENCIAS .............................................................................................................................83
2. ESPECIFICACIONES FUNCIONALES................................................................................................... 84
3. CASOS DE USO ..................................................................................................................................... 85
3.1 RESUMEN DE CASOS DE USO Y ACTORES ....................................................................................85
3.2 ESPECIFICACIONES DE CASOS DE USO ........................................................................................87
CASOS DE USO GENERALES ..............................................................................................................87
CASOS DE USO MÓDULO DE PLATAFORMA .........................................................................................88
CASOS DE USO MÓDULO DE TAQUILLA .............................................................................................102
CASOS DE USO MÓDULO DE MANTENIMIENTO ..................................................................................107
3.3 DIAGRAMAS DE CASOS DE USO ..................................................................................................109
4. ESPECIFICACIONES SUPLEMENTARIAS ......................................................................................... 109
4.1 DISPONIBILIDAD (AVAILABILITY)..................................................................................................109
4.3 DESEMPEÑO (PERFORMANCE)...................................................................................................110
4.4 CONFIABILIDAD (RELIABILITY) ....................................................................................................111
4.5 SEGURIDAD EXTERNA (SAFETY) ................................................................................................112
4.6 SEGURIDAD INTERNA (SECURITY) ..............................................................................................113
4.7 CONFIGURABILIDAD (CONFIGURABILITY) .....................................................................................114
4.8 INTEGRABILIDAD (INTEGRABILITY)...............................................................................................114
4.9 INTEGRIDAD (INTEGRITY) ...........................................................................................................115
4.10 INTEROPERABILIDAD (INTEROPERABILITY).................................................................................115
4.11 MODIFICABILIDAD (MODIFIABILITY) ...........................................................................................115
4.12 MANTENIBILIDAD (MAINTAINABILITY).........................................................................................116
4.13 PORTABILIDAD (PORTABILITY)..................................................................................................116
4.14 REUSABILIDAD (REUSABILITY)..................................................................................................117
4.15 ESCALABILIDAD (SCALABILITY).................................................................................................117
4.16 CAPACIDAD DE PRUEBA (TESTABILITY).....................................................................................118
4.17 FUNCIONALIDAD (FUNCIONALITY) .............................................................................................118
82
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
Versión: 1.0
Fecha: 08/05/2006
Especificaciones de Requerimientos del Software
1. Introducción
El documento que se presenta a continuación pretende mostrar las especificaciones
suplementarias y funcionales correspondientes a la aplicación Visual Banker. Por tratarse de un sistema
ya existente, fue necesario emplear ingeniería de reverso para poder obtener toda la información
relacionada con el tema. El mecanismo empleado fue el de Entrevistas las cuales fueron realizadas a las
personas con conocimientos específicos sobre cada uno de los puntos que aquí se muestran.
1.1 Alcance
En el documento se muestra la información correspondiente a especificaciones funcionales y no
funcionales de Visual Banker, así como la descripción de los casos de uso presentes en la aplicación. El
Modelo de Casos de Uso del Sistema será desarrollado en el Documento de Arquitectura de Software de
Visual Banker y mostrado a través de la Vista de Casos de Uso.
1.2 Definiciones, Acrónimos y Abreviaturas
En esta sección se especifican las definiciones, acrónimos y abreviaciones utilizadas a lo largo
del documento para lograr una comprensión del mismo.
9
Fx: representa un identificador para cada una de las especificaciones funcionales mostradas
en la sección que recibe el mismo nombre. La letra F representa una abreviación de
Funcionalidad, mientras que “x” representa
un número natural que identifica a cada
especificación allí señalada.
9
DAS: Documento de Arquitectura de Software.
1.3 Referencias
En el presente documento se hace referencia al DAS de Visual Banker. De igual manera, se hace
referencia a la Guía de Estudio de Arquitectura de Software, elaborada en Abril de 2004 por Erika
Camacho, Fabio Cardeso y Gabriel Nuñez.
83
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
Versión: 1.0
Fecha: 08/05/2006
2. Especificaciones Funcionales
En el cuadro que se presenta a continuación, se muestra el conjunto de especificaciones
funcionales con las que debe cumplir el Software, además de la identificación y una breve descripción de
las misas.
ID
F1
Nombre del Requerimiento
Apertura de Cuentas
Descripción
La aplicación permite abrir una cuenta correspondiente a
cualquiera de los clientes de la organización.
F2
Venta de Certificados
La aplicación permite la venta de certificados.
F3
Venta de Pólizas de Seguros
La aplicación permite la venta de pólizas de seguros.
F4
Consulta de Fideicomisos
La aplicación permite la realización de consultas sobre los
fideicomisos.
F5
Afiliación de Tarjetas de Crédito
La aplicación permite la afiliación de tarjetas de crédito.
F6
Operaciones con Moneda
La
Extranjera
operaciones con moneda extranjera.
Afiliación de Empresas al LPH
La aplicación permite la afiliación de diferentes empresas a
F7
aplicación
permite
la
realización
de
diferentes
la Ley de Política Habitacional.
F8
Operaciones de Taquilla
La aplicación permite la realización de las operaciones
básicas de taquilla como lo son: depósitos, retiros,
consultas, pago de cheques, emisión de cheques de
gerencia,
aportes
de
LPH,
pago
de
servicios,
recaudaciones, etc.
F9
Manejo de Usuarios
La aplicación permite, por medio de un administrador,
tener el control sobre la creación, modificación y borrado
de los usuarios que pueden tener acceso a la misma. De
igual manera permite el manejo de las claves de los
usuarios.
F10
Verificación de Status
La aplicación permite verificar cual es el status actual del
usuario, indicando si está Activo o Inactivo, así como el
inicio y cierre de sesión para permitir el cambio de estado.
F11
Venta y consulta de Productos
La aplicación permite que se realice la venta de diferentes
productos, además de permitir que en cualquier momento
sea posible ver la lista de los productos ofrecidos por el
banco a sus clientes, sin necesidad de comprarlos.
F12
Consulta de Firmas
La aplicación permite que se consulte la firma de
cualquiera de los clientes en cualquier momento.
84
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
Versión: 1.0
Fecha: 08/05/2006
F13
Pago de TC
La aplicación permite el pago de las tarjetas de crédito.
F14
Generar Reportes
La aplicación permite generar en la actualidad un total de
250 reportes.
F15
Búsqueda de Clientes
La aplicación permite la búsqueda de clientes bien sea por
CI o por RIF, cuando se trate de personas naturales o
jurídicas respectivamente.
F16
Datos de Clientes
La aplicación permite que en todo momento sea posible
consultar los datos que se tengan registrados sobre un
cliente específico.
F17
Descripciones de los productos
El sistema provee un mecanismo a través del cual se
e impresión de la información.
puede observar una presentación de el(los) producto(s)
ofrecido(s) por el banco, teniendo al mismo tiempo la
opción de imprimir dicha información.
F18
Agregar Nuevos Clientes
El sistema está en la capacidad de agregar nuevos clientes
a la organización.
F19
Depósitos Propios y
El sistema debe permitir que diferentes empresas que
Recaudaciones
tengan productos con el banco, posean un módulo de
depósitos
propios
que
permita
la
realización
de
recaudaciones en forma personalizada.
F20
Ingresar y salir del sistema.
El sistema permite que los usuarios acreditados para ello
puedan entrar y salir del sistema una vez suministrado el
login y password correspondiente.
F21
Reverso de Transacciones
La aplicación permite el reverso de alguna de las
transacciones que fueron ejecutadas.
3. Casos de Uso
3.1 Resumen de Casos de Uso y Actores
En la siguiente sección se muestra una breve explicación de cada uno de los actores que realizan
los casos de uso, así como la especificación de cada uno de los casos de uso presentes en la aplicación.
Por razones de tiempo y complejidad de la aplicación solo se consideraron los casos de uso iniciales y de
mayor relevancia. El modelo de casos de uso será presentado en el Documento de Arquitectura.
En el cuadro que se muestra a continuación se presenta un resumen de todos los casos de uso
con los respectivos actores que los ejecutan.
85
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
Versión: 1.0
Fecha: 08/05/2006
Caso de Uso
Entrar al Sistema
Actor
Agente
Caso de Uso
Ver Presolicitudes de Crédito
Actor
Promotor
Salir del Sistema
Agente
Aplicar Encuesta
Promotor
Buscar Cliente
Promotor
Registrar Cliente
Promotor
Mostrar Catálogo de Productos
Promotor
Comparar Inversiones
Promotor
Mostrar Producto para la Compra
Promotor
Usar
Matriz
de
Selección
de Promotor
Productos
Comparar Producto
Promotor
Consultar Firma
Promotor
Imprimir Hoja del Producto
Promotor
Buscar Transacción
Taquillero
Cambiar Password
Taquillero
Taquillero
Ver Diapositiva de Presentación Promotor
del Producto
Vender Producto
Promotor
Ejecutar Transacción
Iniciar Sesión
Promotor
Seleccionar
pago
de
servicios Taquillero
de
servicios Taquillero
Depósitos Propios
Cerrar Sesión
Promotor
Seleccionar
pago
Consulta de Saldo CANTV
Utilizar Calculadora de Ahorro
Promotor
Seleccionar pago de servicios CANTV
Utilizar Calculadora Fecha de Promotor
Seleccionar
pago
Vencimiento
Recaudaciones
de
Taquillero
servicios Taquillero
Ver Ficha Cliente
Promotor
Utilizar Calculadora
Taquillero
Ver Datos Demográficos
Promotor
Crear Usuario
Administrador
Ver Resumen Banesco
Promotor
Modificar Usuario
Administrador
Ver Carpeta Financiera
Promotor
Eliminar Usuario
Administrador
Especificación de los Actores
Administrador: se refiere a la persona que está en la capacidad de entrar al módulo de
mantenimiento y efectuar cambios correspondientes al grupo de usuarios que se encuentran definidos
dentro del sistema. Dichos cambios abarcan desde la creación de nuevos usuarios, pasando por la
modificación de los ya existentes hasta llegar al borrado de los mismos.
Cliente: se refiere a cualquiera de los clientes de la organización, tanto personas naturales como
jurídicas. Tiene entablada una relación comercial con Banesco y ha adquirido al menos un producto del
banco y un conjunto de servicios asociados al mismo. No incluye a los aplicantes (clientes potenciales).
86
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
Versión: 1.0
Fecha: 08/05/2006
Promotor: se refiere a un plataformista encargado de brindar información y asesoría sobre los
productos de la organización. Esta asesoría está orientada a la venta de productos según las
necesidades del cliente y los requisitos del banco. El promotor tiene reducida su acción de venta a un
cierto grupo de productos. [Plataforma Visual Banker, Banesco].
Taquillero: se refiere a la persona que se encuentra manejando el módulo de taquilla y que
atiende a los clientes en cuanto a servicios relacionados con depósitos, retiros, cobro de cheques,
traspasos, tarjetas de crédito, pago a proveedores, cheques de gerencia, pensiones, etc.
Agente: representación general de cualquier empleado de la organización que tiene trato con los
clientes y que por lo tanto interactuará con Visual Banker.
3.2 Especificaciones de Casos de Uso
Casos de Uso Generales
CASO DE USO
Entrar al Sistema
ACTOR
Agente
DESCRIPCIÓN
Permite a los agentes ingresar al sistema, indicando su login y password.
REQUERIMIENTOS
F20
ASOCIADOS
PRECONDICIÓN
El agente debe estar registrado en el sistema y poseer un nombre de
usuario y clave válidos.
CURSO NORMAL
ACTOR
SISTEMA
1. El agente abre la
aplicación e introduce los
datos correspondientes a
login y password y presiona
2. El sistema procesa y valida los datos
suministrados y permite que el usuario
ingrese a la aplicación.
el botón Aceptar.
CURSO ALTERNO
ACTOR
SISTEMA
En el paso 2 del curso normal:
2. El sistema indica que el usuario y/o clave
introducidos no son correctos.
87
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
Versión: 1.0
Fecha: 08/05/2006
3. El agente ingresa
nuevamente los datos
solicitados y presiona el
4. El sistema verifica los datos suministrados
botón Aceptar.
y permite el acceso al usuario.
POSTCONDICIÓN
El agente entra a la aplicación y comienza a hacer uso de la misma.
CASO DE USO
Salir del Sistema
ACTOR
Agente
DESCRIPCIÓN
Permite que los agentes salgan de la aplicación.
REQUERIMIENTOS
F20
ASOCIADOS
PRECONDICIÓN
El agente debe haber entrado al sistema previamente.
CURSO NORMAL
ACTOR
SISTEMA
1. El agente presiona el
botón Salir.
2. El sistema pregunta si realmente se desea
salir de la aplicación.
3. El agente presiona OK y
sale del sistema.
CURSO ALTERNO
ACTOR
SISTEMA
En el paso 3 del curso
normal:
3. El agente presiona
Cancelar y regresa a la
pantalla donde se
encontraba.
POSTCONDICIÓN
El agente sale de la aplicación.
Casos de Uso Módulo de Plataforma
CASO DE USO
Buscar Cliente
ACTOR
Promotor
88
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
DESCRIPCIÓN
Versión: 1.0
Fecha: 08/05/2006
Permite que el promotor busque a un cliente específico, indicando para ello
el criterio de búsqueda. Debe suministrar la nacionalidad y número de CI si
es una persona natural y la nacionalidad y el RIF en caso de tratarse de una
persona jurídica.
REQUERIMIENTOS
F15, F16
ASOCIADOS
PRECONDICIÓN
El promotor debe estar conectado y autenticado en el sistema
CURSO NORMAL
ACTOR
SISTEMA
1. El promotor presiona el
icono denominado Buscar
2. El sistema muestra la pantalla para
introducir los datos correspondientes a criterio
Cliente.
de búsqueda, nacionalidad y CI del cliente.
3. El promotor rellena los
campos solicitados y
presiona el botón Buscar.
CURSO ALTERNO
4. El sistema lista al cliente que corresponde
con los datos introducidos por el promotor.
ACTOR
SISTEMA
En el paso 4 del curso normal:
4. El sistema indica que el cliente buscado no
está registrado y ofrece la opción de registro
para el promotor.
POSTCONDICIÓN
El cliente buscado es mostrado por el sistema, indicando además si el
mismo está presente en la Lista Negra y Sicri.
CASO DE USO
Mostrar Catálogo de Productos
ACTOR
Promotor
DESCRIPCIÓN
Permite al promotor observar la lista de productos que pueden ser ofrecidos
a los clientes y que podrían concretarse en una compra. Ofreciendo
además, la opción de mostrar las presentaciones de los mismos, realizar la
comparación entre productos, imprimir folletos y seleccionar para la venta.
REQUERIMIENTOS
F11
ASOCIADOS
PRECONDICIÓN
El promotor debe estar conectado y autenticado en el sistema
89
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
Versión: 1.0
Fecha: 08/05/2006
CURSO NORMAL
SISTEMA
ACTOR
1. El promotor presiona el
icono denominado Catálogo
de Productos.
2. El sistema muestra la pantalla en la que se
listan todos los productos que pueden ser
ofrecidos a los clientes.
3. El promotor selecciona el
producto sobre el cual quiere
obtener más información y
ver sus subproductos.
POSTCONDICIÓN
4. El sistema muestra la lista de subproductos
asociados a dicho producto, que pueden ser
vendidos.
El promotor obtiene la lista de los grupos de productos y productos
propiamente dichos que pueden ser ofrecidos a los clientes.
CASO DE USO
Marcar Producto para la Compra
<extend> Mostrar Catálogo de Productos.
ACTOR
Promotor
DESCRIPCIÓN
Permite que el promotor agregue a una compra un producto específico de
los listados a través del caso de uso Mostrar Catálogo de Productos.
REQUERIMIENTOS
F11, F2, F3, F4, F5, F6, F7
ASOCIADOS
PRECONDICIÓN
El promotor debe estar conectado y autenticado en el sistema
CURSO NORMAL
ACTOR
SISTEMA
1. El actor inicia el caso de
uso Mostrar Catálogo de
Productos y selecciona la
opción de Marcar para la
Compra.
2. El sistema indica que el producto
seleccionado por el promotor fue agregado a
la compra del cliente actual o del próximo
cliente que sea puesto en contexto (en caso
de que no se encuentre uno actualmente).
POSTCONDICIÓN
El producto del catálogo seleccionado por el promotor queda marcado para
la compra.
CASO DE USO
Comparar Producto
<extend> Mostrar Catálogo de Productos.
ACTOR
Promotor
90
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
DESCRIPCIÓN
Versión: 1.0
Fecha: 08/05/2006
Permite que el promotor compare alguno de los productos listados a través
del caso de uso Mostrar Catálogo de productos.
REQUERIMIENTOS
F11, F2, F3, F4, F5, F6, F7, F1
ASOCIADOS
PRECONDICIÓN
El promotor debe estar conectado y autenticado en el sistema
CURSO NORMAL
ACTOR
SISTEMA
1. El actor inicia el caso de
uso Mostrar Catálogo de
Productos y una vez
finalizado selecciona la
2. El sistema muestra la pantalla donde se
deben indicar los puntos de comparación
entre los productos.
opción de Comparar
Producto.
3. El promotor establece los
puntos de comparación.
4. El sistema efectúa la comparación y ofrece
los resultados al actor.
POSTCONDICIÓN
Se realiza la comparación entre dos productos a través de ciertos puntos de
comparación establecidos por el actor.
CASO DE USO
Imprimir Hoja del Producto
<extend> Mostrar Catálogo de Productos.
ACTOR
Promotor
DESCRIPCIÓN
Permite que el promotor imprima la hoja de alguno de los productos listados
a través del caso de uso Mostrar Catálogo de Productos.
REQUERIMIENTOS
F17
ASOCIADOS
PRECONDICIÓN
CURSO NORMAL
El promotor debe estar conectado y autenticado en el sistema
ACTOR
SISTEMA
1. El actor inicia el caso de
uso Mostrar Catálogo de
2. El sistema imprime la hoja del producto del
Productos y una vez
91
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
finalizado selecciona la
Versión: 1.0
Fecha: 08/05/2006
catálogo seleccionado por el promotor.
opción de Imprimir Hoja del
Producto.
POSTCONDICIÓN
La hoja correspondiente al producto del catálogo seleccionado por el
promotor es impresa.
CASO DE USO
Ver Diapositiva de Presentación del Producto
<extend> Mostrar Catálogo de Productos.
ACTOR
Promotor
DESCRIPCIÓN
Permite que el promotor observe las diapositivas correspondientes a la
presentación de alguno de los productos listados a través del caso de uso
Mostrar Catálogo de Productos.
REQUERIMIENTOS
F17
ASOCIADOS
PRECONDICIÓN
El promotor debe estar conectado y autenticado en el sistema.
CURSO NORMAL
ACTOR
SISTEMA
1. El actor inicia el caso de
uso Mostrar Catálogo de
Productos y una vez
finalizado selecciona la
2. El sistema inicia la presentación
correspondiente al producto del catálogo
seleccionado por el promotor.
opción de Diapositiva de
Presentación del Producto.
POSTCONDICIÓN
Es mostrada la presentación del producto seleccionado por el promotor.
CASO DE USO
Vender Producto.
ACTOR
Promotor
DESCRIPCIÓN
Permite que el promotor efectúe la venta de alguno de los productos
ofrecidos por el banco, a un cliente específico.
REQUERIMIENTOS
F11, F2, F3, F4, F5, F6, F7, F1
ASOCIADOS
PRECONDICIÓN
El promotor debe estar conectado y autenticado en el sistema
92
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
CURSO NORMAL
ACTOR
Versión: 1.0
Fecha: 08/05/2006
SISTEMA
1. El promotor busca el cliente
al cual se le va a realizar la
venta del producto y lo coloca
en contexto.
2. El promotor abre la sesión e
incluye al cliente en la misma y
selecciona la opción Venta de
3.El sistema despliega la pantalla
correspondiente a la venta y ofrece las
opciones de Eliminar o Agregar producto
Productos.
4. El promotor selecciona
Agregar producto.
6. EL promotor selecciona el
producto que va a ser vendido y
presiona Marcar para la
Compra.
5. El sistema lo redirecciona al catálogo de
productos.
7. El sistema agrega el producto
seleccionado a la lista de productos
ofrecidos para ese cliente y muestra dicha
lista.
8. El promotor selecciona OK y
se efectúa la venta del producto
para el cliente.
CURSO ALTERNO
ACTOR
SISTEMA
En el paso 1 del curso normal:
2. El promotor selecciona la
opción Venta de Productos.
3. El sistema indica que no se ha iniciado
sesión o agregado un cliente a la misma y
por lo tanto no es posible seguir con la
venta.
POSTCONDICIÓN
Se efectúa la venta de un producto del catálogo por parte del promotor, a un
cliente específico.
CASO DE USO
Iniciar Sesión
ACTOR
Promotor
DESCRIPCIÓN
Permite que el promotor inicie una sesión dentro del sistema.
93
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
REQUERIMIENTOS
Versión: 1.0
Fecha: 08/05/2006
F10
ASOCIADOS
PRECONDICIÓN
El promotor debe estar conectado y autenticado en el sistema
CURSO NORMAL
ACTOR
SISTEMA
1. El promotor selecciona el
botón verde de Inicio de
2. El sistema registra la fecha y hora de inicio
y habilita ciertas funcionalidades para el
Sesión.
promotor, que no pueden ser realizadas sin el
previo inicio de sesión.
3. El estado del promotor pasa a “Activo”
POSTCONDICIÓN
La fecha y hora del inicio de la sesión quedan registradas.
CASO DE USO
Cerrar Sesión
<include> Iniciar Sesión
ACTOR
Promotor
DESCRIPCIÓN
Permite que el promotor cierre la sesión que previamente fue iniciada.
REQUERIMIENTOS
F10
ASOCIADOS
PRECONDICIÓN
El promotor debe estar conectado y autenticado en el sistema
CURSO NORMAL
ACTOR
SISTEMA
1. El promotor selecciona el
botón rojo de Cierre de
Sesión.
2. El sistema pregunta si se desea dejar una
nota y registra la fecha de finalización así
como la duración de la sesión.
3. Elimina del contexto a los clientes con los
cuales se estaba trabajando y cambia el
estado del promotor a “Inactivo”.
POSTCONDICIÓN
Se registran clientes involucrados, la hora de finalización y la duración de la
sesión.
94
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
Versión: 1.0
Fecha: 08/05/2006
CASO DE USO
Utilizar Calculadora de Ahorro.
ACTOR
Promotor
DESCRIPCIÓN
Permite que el promotor emplee la calculadora de ahorro que provee la
aplicación, para poder realizar recomendaciones a los clientes basándose en
los requerimientos de los mismos.
REQUERIMIENTOS
ASOCIADOS
PRECONDICIÓN
El promotor debe estar conectado y autenticado en el sistema
CURSO NORMAL
ACTOR
SISTEMA
1. El promotor selecciona la
opción Calculadora de
2. El sistema muestra la ventana
correspondiente a la calculadora y los
Ahorro.
respectivos datos para las opciones Metas de
3. El promotor selecciona la
Ahorro, Ahorros Actuales y Sumas Globales.
opción deseada e ingresa los
datos solicitados.
4. El sistema realiza los cálculos
correspondientes al total de ahorros de
capitalización y muestra los resultados.
POSTCONDICIÓN
Se efectúan los cálculos correspondientes al total de ahorros de
capitalización, según los parámetros de entrada suministrados.
CASO DE USO
Utilizar Calculadora Fecha de Vencimiento.
ACTOR
Promotor
DESCRIPCIÓN
Permite que el promotor emplee la calculadora de fecha de vencimiento que
provee la aplicación, para poder realizar recomendaciones a los clientes
según los requerimientos que los mismos presenten.
REQUERIMIENTOS
ASOCIADOS
PRECONDICIÓN
CURSO NORMAL
El promotor debe estar conectado y autenticado en el sistema
ACTOR
SISTEMA
1. El promotor selecciona la
opción Calculadora Fecha de
2. El sistema muestra la ventana
correspondiente a la calculadora y los
95
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
Vencimiento.
Versión: 1.0
Fecha: 08/05/2006
campos de los datos que deben ser
suministrados.
3. El promotor ingresa los
datos correspondientes a la
4. El sistema recibe la información, realiza los
Fecha de Compra, Plazo de
cálculos y muestra los resultados obtenidos.
Duración y Fecha de
Vencimiento.
POSTCONDICIÓN
Se efectúan los cálculos correspondientes a la fecha de vencimiento, según
los parámetros de entrada suministrados.
CASO DE USO
Ver Ficha Cliente.
<extend> Buscar Cliente.
ACTOR
Promotor
DESCRIPCIÓN
Permite que el promotor tenga acceso a la ficha del cliente en la cual se
manejan datos personales (demográficos), financieros y referentes a los
negocios que la persona tiene establecidos con la organización.
REQUERIMIENTOS
F16
ASOCIADOS
PRECONDICIÓN
El promotor debe estar conectado y autenticado en el sistema
CURSO NORMAL
ACTOR
SISTEMA
1. El promotor inicia el caso
de uso Buscar Cliente y
selecciona con el botón
derecho la opción Ver Ficha
2. El sistema carga la ficha correspondiente al
cliente buscado y presenta diferentes
opciones. .
del Cliente.
POSTCONDICIÓN
La ficha de un cliente específico es mostrada al promotor.
CASO DE USO
Ver Datos Demográficos.
<extend> Ver Ficha Cliente.
ACTOR
Promotor
DESCRIPCIÓN
Permite que el promotor tenga acceso a los datos personales (demográficos)
de un cliente específico.
96
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
REQUERIMIENTOS
Versión: 1.0
Fecha: 08/05/2006
F16
ASOCIADOS
PRECONDICIÓN
El promotor debe estar conectado y autenticado en el sistema
CURSO NORMAL
ACTOR
SISTEMA
1. El promotor inicia el caso
de uso Ver Ficha Cliente y
selecciona con el botón
derecho la opción Datos
2. El sistema carga los datos demográficos
(nombre, apellido, fecha nac., etc.)
correspondientes al cliente seleccionado.
Demográficos.
POSTCONDICIÓN
Los datos personales de un cliente específico son mostrados al promotor.
CASO DE USO
Ver Resumen Banesco.
<extend> Ver Ficha Cliente.
ACTOR
Promotor
DESCRIPCIÓN
Permite que el promotor tenga acceso al registro de todas las sesiones en
las cuales a participado el cliente.
REQUERIMIENTOS
F16
ASOCIADOS
PRECONDICIÓN
El promotor debe estar conectado y autenticado en el sistema
CURSO NORMAL
ACTOR
SISTEMA
1. El promotor inicia el caso
de uso Ver Ficha Cliente y
selecciona con el botón
2. El sistema carga los correspondientes a
última sesión del cliente seleccionado.
derecho la opción Resumen
Banesco.
POSTCONDICIÓN
Los de la última sesión de un cliente específico son mostrados al promotor.
CASO DE USO
Ver Carpeta Financiera.
<extend> Ver Ficha Cliente.
ACTOR
Promotor
97
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
DESCRIPCIÓN
Versión: 1.0
Fecha: 08/05/2006
Permite que el promotor tenga acceso a los diferentes negocios y productos
que la persona tiene establecidos con la organización.
REQUERIMIENTOS
F16
ASOCIADOS
PRECONDICIÓN
El promotor debe estar conectado y autenticado en el sistema
CURSO NORMAL
ACTOR
SISTEMA
1. El promotor inicia el caso
de uso Ver Ficha Cliente y
selecciona la opción Carpeta
Financiera.
2. El sistema carga los datos
correspondientes a los productos y negocios
que el cliente tiene con la compañía.
POSTCONDICIÓN
Se muestran al promotor los productos que el cliente tiene con la empresa.
CASO DE USO
Ver Presolicitudes de Crédito.
<extend> Buscar Cliente.
ACTOR
Promotor
DESCRIPCIÓN
Permite que el promotor tenga acceso a las solicitudes de crédito que ha
realizado el cliente.
REQUERIMIENTOS
ASOCIADOS
PRECONDICIÓN
CURSO NORMAL
El promotor debe estar conectado y autenticado en el sistema
ACTOR
SISTEMA
1. El promotor inicia el caso
de uso Buscar Cliente y
selecciona con el botón
derecho la opción
Presolicitudes de Crédito.
2. El sistema carga la ventana
correspondiente que posee datos referentes
a presolicitudes anteriores de crédito, tipos de
crédito, formas de pago y plazo en meses, de
un cliente específico.
POSTCONDICIÓN
Se muestran al promotor las presolicitudes de crédito que ha realizado un
cliente específico.
98
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
CASO DE USO
Versión: 1.0
Fecha: 08/05/2006
Aplicar Encuesta.
<include> Buscar Cliente.
ACTOR
Promotor
DESCRIPCIÓN
Permite que el promotor aplique una de las encuestas ya especificadas a
alguno de los clientes que todavía no ha sido encuestado.
REQUERIMIENTOS
ASOCIADOS
PRECONDICIÓN
El promotor debe estar conectado y autenticado en el sistema.
CURSO NORMAL
ACTOR
SISTEMA
1. El promotor inicia el caso
de uso Buscar Cliente.
2. El sistema indica que el cliente consultado
no ha sido encuestado y pregunta al promotor
3. El promotor selecciona la
si desea realizar una encuesta al mismo.
opción “OK”.
4. El sistema muestra la pantalla en la cual se
5. El promotor selecciona la
indican las encuestas disponibles para ser
encuesta que va a aplicar.
aplicadas.
5. El sistema muestra la pantalla con las
preguntas que el promotor debe realizar al
cliente.
POSTCONDICIÓN
Se aplica una encuesta predeterminada a un cliente específico.
CASO DE USO
Registrar Cliente.
<include> Buscar Cliente.
ACTOR
Promotor
DESCRIPCIÓN
Permite que el promotor registre a un nuevo cliente dentro del Banco.
REQUERIMIENTOS
F18
ASOCIADOS
PRECONDICIÓN
CURSO NORMAL
El promotor debe estar conectado y autenticado en el sistema
ACTOR
SISTEMA
1. El promotor inicia el caso
2. El sistema indica que el cliente buscado no
99
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
de uso Buscar Cliente.
Versión: 1.0
Fecha: 08/05/2006
se encuentra registrado todavía, presentando
la opción de registro.
3. El promotor presiona “OK”
4. El sistema muestra la pantalla con los
datos que deben ser llenados por el promotor
para completar el registro del cliente.
POSTCONDICIÓN
Se registra un nuevo cliente dentro de la organización.
CASO DE USO
Comparar Inversiones.
ACTOR
Promotor
DESCRIPCIÓN
Permite que el promotor realice una comparación de inversiones.
REQUERIMIENTOS
ASOCIADOS
PRECONDICIÓN
El promotor debe estar conectado y autenticado en el sistema
CURSO NORMAL
ACTOR
SISTEMA
1. El promotor selecciona la
opción “Comparar
Inversiones”.
2. El sistema muestra la pantalla
correspondiente a la opción seleccionada.
3. El promotor llena los datos
solicitados y presiona el
botón Aceptar
POSTCONDICIÓN
4. El sistema procesa la solicitud y muestra la
comparación realizada.
El promotor realiza la comparación entre varias inversiones posibles que
puede realizar el cliente.
CASO DE USO
Matriz de Selección de Productos.
<include> Iniciar Sesión.
ACTOR
Promotor
DESCRIPCIÓN
Permite que el promotor sea guiado por el sistema para la venta de ciertos
productos que pueden adaptarse al perfil del cliente que se está atendiendo
en un momento determinado. Para ello se vale de una lista de preguntas que
indican hacia que tipo de productos es necesario enfocarse.
100
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
Versión: 1.0
Fecha: 08/05/2006
REQUERIMIENTOS
ASOCIADOS
PRECONDICIÓN
El promotor debe estar conectado y autenticado en el sistema.
CURSO NORMAL
ACTOR
SISTEMA
1. El promotor inicia el caso
de uso Iniciar Sesión y
selecciona la opción Matriz
de Selección de Productos.
2. El sistema muestra la pantalla en la cual
se presentan una serie de preguntas que
deben ser realizadas por el promotor al
cliente.
3. El promotor selecciona la
respuesta a cada pregunta
según la información
suministrada por el cliente.
4. Al finalizar el cuestionario el sistema
procesa la información y ofrece una lista de
productos sugeridos que deben ser ofrecidos
al cliente, según el perfil que éste presenta.
POSTCONDICIÓN
El promotor es guiado sobre el grupo de productos que deben ser ofrecidos
al cliente según el perfil que el mismo presenta.
CASO DE USO
Consultar Firma
ACTOR
Promotor
DESCRIPCIÓN
Permite que el promotor consulte la firma de alguno de los clientes ya
registrados dentro de la organización.
REQUERIMIENTOS
F12
ASOCIADOS
PRECONDICIÓN
CURSO NORMAL
El promotor debe estar conectado y autenticado en el sistema
ACTOR
SISTEMA
1. El promotor selecciona el
cliente al cual le quiere
consultar la firma.
2. El sistema busca la firma correspondiente
al cliente suministrado y la muestra al
promotor.
POSTCONDICIÓN
La firma de un cliente específico es consultada por un promotor.
101
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
Versión: 1.0
Fecha: 08/05/2006
Casos de Uso Módulo de Taquilla
CASO DE USO
Buscar Transacción.
ACTOR
Taquillero
DESCRIPCIÓN
El taquillero busca directamente una transacción a través de un código, sin
necesidad de ubicar primero la opción a la cual pertenece.
REQUERIMIENTOS
ASOCIADOS
PRECONDICIÓN
El taquillero debe estar conectado y autenticado en el sistema
CURSO NORMAL
ACTOR
SISTEMA
1. El taquillero escribe en el
campo correspondiente el
código de la transacción que
2. El sistema recibe los datos y carga el
nombre de la transacción solicitada.
desea buscar.
POSTCONDICIÓN
Se muestra al taquillero el código y nombre de la transacción que fue
buscada.
CASO DE USO
Cambiar Password
ACTOR
Taquillero
DESCRIPCIÓN
Un usuario del módulo de Taquilla realiza el cambio de su clave de acceso a
la aplicación.
REQUERIMIENTOS
F9
ASOCIADOS
PRECONDICIÓN
CURSO NORMAL
El taquillero debe estar conectado y autenticado en el sistema
ACTOR
SISTEMA
1. El taquillero presiona el
botón Password.
2. El sistema muestra la pantalla a través de
la cual se debe realizar el cambio de la clave.
3. El taquillero rellena los
campos correspondientes a
4. El sistema realiza la verificación y registra
clave actual, clave nueva y
los datos introducidos, efectuando el cambio
confirmación, y presiona el
de clave para el usuario solicitado.
102
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
Versión: 1.0
Fecha: 08/05/2006
botón Aceptar.
CURSO ALTERNO
ACTOR
SISTEMA
En el paso 4 del curso normal:
4. Al realizar la verificación de la clave actual
ingresada, el sistema indica que no es
5. El taquillero vuelve a
correcta.
introducir los datos y
presiona el botón Aceptar.
6. El sistema realiza la validación y registra
los datos introducidos, efectuando el cambio
de clave para el usuario solicitado.
POSTCONDICIÓN
Es modificada la clave de acceso para la aplicación, de un taquillero
específico.
CASO DE USO
Ejecutar Transacción
ACTOR
Taquillero
DESCRIPCIÓN
El taquillero selecciona la opción que contiene la transacción que desea
ejecutar en un momento determinado.
REQUERIMIENTOS
F8
ASOCIADOS
PRECONDICIÓN
El taquillero debe estar conectado y autenticado en el sistema.
CURSO NORMAL
ACTOR
SISTEMA
1. El taquillero selecciona
uno de los ítems que están
desplegados en la lista de
el conjunto de transacciones que asociadas a
la opción seleccionada.
Opciones.
CURSO ALTERNO
2. El sistema muestra en una lista adyacente
ACTOR
SISTEMA
En el paso 2 del curso
normal:
3. El taquillero se da cuenta
que esa no es la transacción
correcta y presiona el botón
Cancelar.
103
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
Versión: 1.0
Fecha: 08/05/2006
.4. Selecciona una nueva
5. El sistema muestra la pantalla
opción de la lista.
correspondiente a la transacción y con sus
respectivos datos.
POSTCONDICIÓN
Es seleccionada una de las transacciones para ser ejecutada.
CASO DE USO
Seleccionar Pago de Servicios Depósitos Propios
<include> Ejecutar Transacción
ACTOR
Taquillero
DESCRIPCIÓN
El taquillero selecciona la opción que contiene la transacción que desea
ejecutar en un momento determinado.
REQUERIMIENTOS
F8, F19
ASOCIADOS
PRECONDICIÓN
El taquillero debe estar conectado y autenticado en el sistema
CURSO NORMAL
ACTOR
SISTEMA
1. Se inicia el caso de uso
“Ejecutar Transacción”
seleccionando la opción
“Pago de Servicios”.
2. El sistema muestra en una lista adyacente
el conjunto de transacciones que se
encuentran asociadas a la opción
seleccionada.
3. El taquillero selecciona la
opción “Depósitos Propios”.
4. El sistema abre la ventana correspondiente
a la transacción que se desea ejecutar,
5. El taquillero llena los datos indicando los datos que deben ser llenados.
correspondientes y presiona
el botón Aceptar.
6. El sistema registra los datos suministrados
y ejecuta la transacción.
POSTCONDICIÓN
Se ejecuta la transacción correspondiente a “Depósitos Propios”
perteneciente a la opción “Pago de Servicios”.
CASO DE USO
Seleccionar Pago de Servicios Consulta de Saldos CANTV
<include> Ejecutar Transacción
ACTOR
Taquillero
104
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
DESCRIPCIÓN
Versión: 1.0
Fecha: 08/05/2006
El taquillero selecciona la opción que contiene la transacción que desea
ejecutar en un momento determinado.
REQUERIMIENTOS
F8
ASOCIADOS
PRECONDICIÓN
El taquillero debe estar conectado y autenticado en el sistema
CURSO NORMAL
ACTOR
SISTEMA
1. Se inicia el caso de uso
“Ejecutar Transacción”
seleccionando la opción
“Pago de Servicios”.
2. El sistema muestra en una lista adyacente
el conjunto de transacciones que se
encuentran asociadas a la opción
seleccionada.
3. El taquillero selecciona de
la lista la opción “Consulta de
4. El sistema abre la ventana correspondiente
a la transacción que se desea ejecutar,
Saldos CANTV”.
indicando los datos que deben ser llenados.
5. El taquillero llena los datos
correspondientes y presiona
y ejecuta la transacción.
el botón Aceptar.
POSTCONDICIÓN
Se
ejecuta
la
6. El sistema registra los datos suministrados
transacción
correspondiente
a
“Depósitos
Propios”
perteneciente a la opción “Consulta de Saldos CANTV”.
CASO DE USO
Seleccionar Pago de Servicios CANTV
<include> Ejecutar Transacción
ACTOR
Taquillero
DESCRIPCIÓN
El taquillero selecciona la opción que contiene la transacción que desea
ejecutar en un momento determinado.
REQUERIMIENTOS
F8
ASOCIADOS
PRECONDICIÓN
CURSO NORMAL
El taquillero debe estar conectado y autenticado en el sistema
ACTOR
SISTEMA
1. Se inicia el caso de uso
“Ejecutar Transacción”
seleccionando la opción
2. El sistema muestra en una lista adyacente
el conjunto de transacciones que se
105
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
“Pago de Servicios”.
Versión: 1.0
Fecha: 08/05/2006
encuentran asociadas a la opción
seleccionada.
3. El taquillero selecciona de
la lista la opción “CANTV”.
4. El sistema abre la ventana correspondiente
a la transacción que se desea ejecutar,
5. El taquillero llena los datos
indicando los datos que deben ser llenados.
correspondientes y presiona
el botón Aceptar.
6. El sistema registra los datos suministrados
y ejecuta la transacción.
POSTCONDICIÓN
Se ejecuta la transacción correspondiente a “CANTV” perteneciente a la
opción “Pago de Servicios”.
CASO DE USO
Seleccionar Pago de Servicios Recaudaciones
<include> Ejecutar Transacción
ACTOR
Taquillero
DESCRIPCIÓN
El taquillero selecciona la opción que contiene la transacción que desea
ejecutar en un momento determinado.
REQUERIMIENTOS
F8
ASOCIADOS
PRECONDICIÓN
CURSO NORMAL
El taquillero debe estar conectado y autenticado en el sistema.
ACTOR
SISTEMA
1. Se inicia el caso de uso
“Ejecutar Transacción”
seleccionando la opción
“Pago de Servicios”.
2. El sistema muestra en una lista adyacente
el conjunto de transacciones que se
encuentran asociadas a la opción
seleccionada.
3. El taquillero selecciona de
la lista la opción
“Recaudaciones”.
4. El sistema abre la ventana correspondiente
a la transacción que se desea ejecutar,
indicando los datos que deben ser llenados.
5. El taquillero llena los datos
correspondientes y presiona
el botón Aceptar.
6. El sistema registra los datos suministrados
y ejecuta la transacción.
106
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
POSTCONDICIÓN
Versión: 1.0
Fecha: 08/05/2006
Se ejecuta la transacción correspondiente a “Recaudaciones” perteneciente
a la opción “Pago de Servicios”.
CASO DE USO
Utilizar Calculadora
ACTOR
Taquillero
DESCRIPCIÓN
El taquillero tiene la posibilidad de utilizar la calculadora que provee la
aplicación para realizar algún cálculo en un momento determinado.
REQUERIMIENTOS
ASOCIADOS
PRECONDICIÓN
El taquillero debe estar conectado y autenticado en el sistema
CURSO NORMAL
ACTOR
SISTEMA
1. El taquillero hace clic
sobre el botón Calculadora.
2. El sistema despliega la pantalla que
muestra las funcionalidades presentes en la
calculadora.
POSTCONDICIÓN
Uno de los usuarios del sistema emplea la calculadora.
Casos de Uso Módulo de Mantenimiento
CASO DE USO
Agregar Usuario
ACTOR
Administrador
DESCRIPCIÓN
El administrador agrega a un nuevo usuario con un perfil específico, para
que tenga acceso a la aplicación.
REQUERIMIENTOS
F9
ASOCIADOS
PRECONDICIÓN
CURSO NORMAL
El administrador debe estar conectado y autenticado en el sistema
ACTOR
SISTEMA
1. El administrador hace clic
sobre el botón Agregar.
2. El sistema desbloquea las casillas
correspondientes a los datos que deben ser
3. El administrador completa especificados para el nuevo usuario
107
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
Versión: 1.0
Fecha: 08/05/2006
los campos de usuario,
4. El sistema registra la información
usuario IBS, clave, en uso,
suministrada y agrega a la lista de usuarios
consecutivo y perfil (cajero
existentes el nuevo usuario creado.
petrolero, cajero principal,
promotor, etc.), y presiona el
botón Guardar.
POSTCONDICIÓN
Se agrega un nuevo usuario a la lista de usuarios ya existentes.
CASO DE USO
Modificar Usuario
ACTOR
Administrador
DESCRIPCIÓN
El administrador puede modificar cualquiera de los datos de los usuarios que
se encuentren registrados dentro del sistema.
REQUERIMIENTOS
F9
ASOCIADOS
PRECONDICIÓN
CURSO NORMAL
El administrador debe estar conectado y autenticado en el sistema
ACTOR
SISTEMA
1. El administrador selecciona
de la lista de usuarios
existentes aquel que va a ser
modificado y hace clic sobre el
2. El sistema carga en la forma los datos
del usuario que va a ser modificado.
botón Modificar.
3. El administrador realiza los
cambios necesarios y hace clic 4. El sistema registra los cambios.
sobre el botón Guardar.
POSTCONDICIÓN
Los datos de un usuario existente son modificados.
CASO DE USO
Eliminar Usuario
ACTOR
Administrador
DESCRIPCIÓN
El administrador puede eliminar a cualquiera de los usuarios que se
encuentren registrados dentro del sistema.
108
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
REQUERIMIENTOS
Versión: 1.0
Fecha: 08/05/2006
F9
ASOCIADOS
PRECONDICIÓN
El administrador debe estar conectado y autenticado en el sistema
CURSO NORMAL
ACTOR
SISTEMA
1. El administrador
selecciona de la lista de
usuarios existentes aquel
2.
El sistema efectúa la pregunta de
confirmación.
que va a eliminado y hace
clic sobre el botón Eliminar.
3. El administrador presiona
el botón OK.
4. El sistema elimina el registro del usuario
seleccionado.
POSTCONDICIÓN
Se elimina el usuario seleccionado.
3.3 Diagramas de Casos de uso
Revisar Vista de Casos de Uso del documento de Arquitectura de Software de Visual Banker.
4. Especificaciones Suplementarias
En la siguiente sección se muestran las especificaciones suplementarias para la Aplicación Visual
Banker. Cada una de las especificaciones va a ser presentada en una sección diferente, indicando en
cada caso los aspectos que se cumplen actualmente en la aplicación, así como los aspectos que
deberían cumplirse.
4.1 Disponibilidad (Availability)
Medida de disponibilidad del sistema para el uso. Porción de tiempo en la que el sistema está
“levantado” y corriendo. Cantidad de tiempo que transcurre entre una falla y otra, qué tan rápido el
sistema puede seguir con la ejecución de una tarea después de que se produjo la falla [Camacho,
Cardeso, Nuñez, 2004].
109
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
Versión: 1.0
Fecha: 08/05/2006
Lo que hace
Lo que debería hacer
Actualmente la disponibilidad se mantiene en un
Se debe minimizar al máximo la cantidad de
aproximado del 99.9 %; sin embargo existen
tiempo que el sistema se encuentra fuera de
agencias en las cuales la disponibilidad no
operación después de que ocurre una falla
supera el 97%. [Medidores de disponibilidad
puesto que esto implica la pérdida de grandes
publicados en la IntraNet].
cantidades de dinero para la organización.
4.2 Confidencialidad (Confidenciality)
Ausencia de acceso no autorizado a la información [Camacho, Cardeso, Nuñez, 2004].
Lo que hace
Lo que debería hacer
El acceso a las bases de datos de las agencias
Se debe restringir el acceso a la base de datos
no se encuentra restringido actualmente.
para que la información contenida en las
mismas conserve el carácter de confidencial.
El tipo de reporte que puede ser generado por
usuario depende del perfil del mismo. Limitando
de esta manera el acceso a la información.
4.3 Desempeño (Performance)
Grado en el cual un sistema o componente cumple con sus funciones designadas, dentro de
ciertas restricciones dadas, como velocidad, exactitud o uso de memoria. Se refiere a capacidad de
respuesta, ya sea el tiempo requerido para responder a aspectos específicos o el número de eventos
procesados en un intervalo de tiempo. Se refiere además a la cantidad de comunicación e interacción
existente entre los componentes del sistema [Camacho, Cardeso, Nuñez, 2004].
Lo que hace
Lo que debería hacer
Tiempo máximo de espera por una transacción
en Taquilla es de 60 seg.
Tiempo máximo de espera por una transacción
en plataforma es de 90 seg.
Tiempo de respuesta de una transacción simple
es en promedio de 0.5 seg. y máximo de 1 seg.
Tiempo de respuesta de una transacción
múltiple es en promedio de 1 seg. y máximo de
110
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
Versión: 1.0
Fecha: 08/05/2006
2 seg.
Tiempo de respuesta de una transacción
múltiple con información en diversos módulos es
en promedio de 10 seg. Y máximo de 30 seg.
En el módulo de taquilla se ejecutan aprox. 230
transacciones por segundo (Trxs).
En el módulo de plataforma se ejecutan:
•
Módulo de cliente 45 Trxs.
•
Venta de productos 220 Trxs.
•
Catálogo de Aplicaciones 55 Trxs.
4.4 Confiabilidad (Reliability)
Medida de la habilidad de un sistema a mantenerse operativo a lo largo del tiempo y grado de
tolerancia que tiene ante las fallas [Camacho, Cardeso, Nuñez, 2004]. Es importante catalogar los tipos
de fallas existentes dentro del contexto con el que se está trabajando:
Falla Crítica: aquella en la que la agencia no pueda trabajar por una inhabilidad completa de las
funcionalidades del sistema.
Falla Importante: aquella en la que se afecte una parte considerable de las funcionalidades del sistema.
Falla de Menor Importancia: aquella que afecte una pequeña funcionalidad del sistema pero que no
impida seguir utilizando la aplicación.
Lo que hace
Lo que debería hacer
El porcentaje de fallas críticas es realmente
MUY BAJO pues se realizan pruebas en
servidores
o
agencias
piloto
antes
de
comenzar con la masificación de la aplicación.
Una vez probada la aplicación y con cierto
tiempo de funcionamiento sin fallas en la
agencia piloto, se implanta en el resto de las
agencias.
La ocurrencia de las fallas de tipo Importante
es de aproximadamente 2 por año.
111
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
Versión: 1.0
Fecha: 08/05/2006
La ocurrencia de fallas de menor importancia
es más frecuente que el resto.
El tiempo de espera para recuperar o reparar
el sistema después de una falla de tipo Crítica
es de 1 a 2 horas (se emplean mecanismos
de RollBack instalando la versión anterior que
se encontraba en funcionamiento), mientras
que para el caso de fallas de menor
importancia transcurre un tiempo mínimo de 3
a 5 días para poder reparar la falla.
4.5 Seguridad Externa (Safety)
Ausencia de consecuencias catastróficas en el ambiente. Es la medida de ausencia de errores
que generan pérdidas de información [Camacho, Cardeso, Nuñez, 2004]. Es importante considerar todo
tipo de amenazas.
Lo que hace
Lo que debería hacer
El servidor principal se encuentra replicado. El
A pesar de que el servidor principal se encuentra
original se encuentra ubicado en Ciudad
replicado, sería conveniente tener un espejo en
Banesco, mientras que el espejo se encuentra
otra Ciudad del País pues en caso de alguna
ubicado en la sede de El Rosal (Chacao,
catástrofe
Vzla.).
servidores podrían verse perjudicados.
Actualmente no existe replicación de los
Seria conveniente replicar los servidores que se
servidores dentro de las agencias, si alguno de
encuentran en cada una de las agencias si no se
ellos se daña la agencia no puede seguir
desea perder la información contenida en los
funcionando y se pierde toda la información.
mismos en caso de alguna falla.
que
ocurra
en
Caracas
ambos
La BD de las agencias no se encuentra
replicada
por
contener
información
insignificante para el sistema central, pues al
tratarse
de
una
aplicación
de
carácter
transaccional toda la información se guarda en
el AS400 que es el servidor principal.
Se cuenta con más de un proveedor de
servicios para el caso de las líneas de
comunicación (CANTV y Movistar). En caso de
112
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
Versión: 1.0
Fecha: 08/05/2006
problemas con alguno de los proveedores se
tiene el otro como backup para poder continuar
con la comunicación.
4.6 Seguridad Interna (Security)
Medida de la habilidad del sistema para resistir a intentos de uso no autorizados y negación del
servicio, mientras se sirve a usuarios legítimos [Camacho, Cardeso, Nuñez, 2004].
Lo que hace
Lo que debería hacer
Existe un administrador del sistema cuya clave
Sería conveniente contar con mecanismos de
es conocida y no posee mayores niveles de
encripción que permiten enviar la información
seguridad. Además, dentro del módulo de
por la red de forma mucho más segura, evitando
taquilla los passwords se encuentran cifrados
que a través de posibles ataques la misma deje
mientras que en el módulo de plataforma no se
de ser confidencial.
cifra esa información.
El acceso a las bases de datos locales NO se
Sería conveniente que la conexión a la base de
encuentra restringido. De igual manera, el
datos local no se reallizara a través de un
acceso se realiza a través de un usuario
usuario genérico, con el fin de restringir el
genérico.
acceso
a
esos
datos
y
mantener
la
confidencialidad.
Se tiene un manejo de usuarios y perfiles que
Actualmente existen tablas de los Journal que
permite delimitar los niveles de acceso que tiene
contiene ráfagas (información de todas las
cada persona y la información que la misma
transacciones realizadas) que no tienen ningún
puede manipular, así como las transacciones
tipo de control de acceso. Es conveniente que
que pueden ser realizadas. Sin embargo, el
dicha información no pueda ser accedida por
control definitivo lo tiene el servidor pues
cualquier usuario sin la debida autorización.
siempre se hace una autentificación contra el
mismo para poder acceder a la aplicación.
El control de acceso a la base de datos principal
es riguroso, pues es allí donde realmente se
encuentra toda la información.
El protocolo de comunicación SNA trabaja con
códigos de páginas, no es un mecanismo de
encripción propiamente dicho pero es más
seguro que enviar la información sin ningún tipo
113
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
Versión: 1.0
Fecha: 08/05/2006
de seguridad. Sin embargo, cualquier persona
que conozca del tema podría descifrar la
codificación del algoritmo. Por su parte TCP/IP
no hace código de página sino que pasa
directamente a código binario.
4.7 Configurabilidad (Configurability)
Posibilidad que se otorga a un usuario experto a realizar ciertos cambios al Sistema. [Camacho,
Cardeso, Nuñez, 2004].
Lo que hace
Lo que debería hacer
Actualmente la aplicación permite que se
La aplicación debería permitir la configuración
configuren parámetros como el Banco, el tipo de
de los reportes a nivel de usuario, pudiendo
moneda y el lenguaje de la aplicación, a través
especificar el tipo de información que va a ser
de las opciones de multibanco, multimoneda y
mostrada con la generación del reporte.
multilenguaje respectivamente.
También es posible configurar el tipo de
La aplicación debería permitir que algunas de
productos que se pueden vender dentro de la
las transacciones puedan ser configuradas,
funcionalidad “Venta de Productos”.
indicando los datos que van a ser empleadas en
cada una como por ejemplo: #cuenta, monto,
fecha, etc.
Sería conveniente que la aplicación pudiese
trabajar Offline para algunas transacciones.
Está opción debe ser configurable.
4.8 Integrabilidad (Integrability)
Medida en que trabajan correctamente componentes del sistema (desarrollados en forma
independiente), al ser integrados [Camacho, Cardeso, Nuñez, 2004].
Lo que hace
Lo que debería hacer
Todas las partes del sistema que fueron
La aplicación debería estar en la capacidad de
desarrolladas por separado a través de grupos
integrarse con el Software de los bancos
de
internacionales
4
o
5
personas,
se
integraron
completamente. En algunos casos se utilizó un
que
pertenecen
a
la
organización. De esta manera se tendría una
114
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
Versión: 1.0
Fecha: 08/05/2006
repositorio en el cual todos los integrantes del
única aplicación que funcione en todos los
grupo trabajaron y en otros se esperaba a que
bancos nacionales e internacionales de la
una parte específica estuviera lista para que el
compañía.
resto de los equipos avanzaran.
4.9 Integridad (Integrity)
Ausencia de alteraciones inapropiadas de la información [Camacho, Cardeso, Nuñez, 2004].
Garantizar integridad y consistencia de los datos a través de algún mecanismo.
Lo que hace
Lo que debería hacer
Se tiene la garantía de que la aplicación guarda
los datos en la BD según procedimientos de
estandarización que aseguran la integridad y
consistencia de la información allí registrada.
4.10 Interoperabilidad (Interoperability)
Medida de la habilidad de que un grupo de partes del sistema trabajen con otro sistema. Podría
considerarse un tipo especial de Integrabilidad [Camacho, Cardeso, Nuñez, 2004].
Lo que hace
Lo que debería hacer
Él sistema está en la capacidad de conectarse e
interactuar con la Intranet de la organización, así
como con Emulación, Lotus Notes e Internet.
4.11 Modificabilidad (Modifiability)
Habilidad de realizar cambios futuros al sistema, con una poca inversión de esfuerzo y dinero
[Camacho, Cardeso, Nuñez, 2004].
Lo que hace
Lo que debería hacer
El sistema se basa en una estructura modular, lo
que facilita de alguna manera los casos en los
cuales hay que realizar ciertas modificaciones.
Sin embargo, el grado de dificultad (en términos
115
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
Versión: 1.0
Fecha: 08/05/2006
de tiempo, dinero y esfuerzo) para realizar
modificaciones a la aplicación, es directamente
proporcional al grado de importancia que tiene
el
aspecto
que
va
a
ser
modificado.
Categorizando se obtiene:
• 1 Monto Transaccional
• 2 Journal
• 3 Acceso a la aplicación
(Seguridad)
• 4 Resto de clases y módulos.
• 5 Desarrollos Nuevos.
Donde 1 representa el aspecto más importante y
a la vez más difícil de modificar y 5 representa al
aspecto de menor relevancia.
4.12 Mantenibilidad (Maintainability)
Capacidad de someter a un sistema a reparaciones y evolución. Capacidad de modificar el
sistema de manera rápida y a bajo costo [Camacho, Cardeso, Nuñez, 2004].
Lo que hace
Lo que debería hacer
El sistema está en la capacidad de soportar
cambios que pueden deberse bien sea a
reparaciones o a adaptaciones necesarias para
cumplir con nuevas necesidades que surjan en
un momento determinado. Sin embargo esto se
ve afectado por el aspecto
necesaria
(tiempo,
dinero,
la inversión
esfuerzo)
está
determinada por el aspecto que vaya a ser
modificado o mejorado, de la misma manera que
ocurre en el punto de Modificabilidad.
4.13 Portabilidad (Portability)
Habilidad del sistema para ser ejecutado en diferentes ambientes de computación. Estos
ambientes pueden ser Hardware, Software o una combinación de los dos. Si la portabilidad requiere
116
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
Versión: 1.0
Fecha: 08/05/2006
algún tipo de cambio, entonces se convierte en una especie de modificabilidad [Camacho, Cardeso,
Nuñez, 2004].
Lo que hace
Lo que debería hacer
Actualmente la aplicación no presenta ningún
La aplicación debería correr en diferentes
tipo de portabilidad, pues únicamente corre en
sistemas de operación como por ejemplo
el sistema operativo OS/2, con la base de datos
Windows.
DB2. Además está realizado con el lenguaje de
programación
Smalltalk
V3,
empleando
el
protocolo de comunicación SNA.
La aplicación debería permitir el uso de
diferentes protocolos de comunicación como por
ejemplo TCP/IP.
La aplicación debería permitir que se utilice otro
manejador de base de datos, diferente al que
emplea en la actualidad.
Se debería considerar el hecho de emplear otro
lenguaje de programación que le ofrezca más
beneficios a la aplicación.
4.14 Reusabilidad (Reusability)
Capacidad de diseñar un sistema de forma tal que su estructura o parte de sus componentes
puedan ser reutilizados en futuras aplicaciones [Camacho, Cardeso, Nuñez, 2004].
Lo que hace
Lo que debería hacer
Debido a la estructuración del código en
módulos, es posible la reutilización interna (para
la misma aplicación) de muchas de las clases,
métodos y procedimientos implementados. De
igual manera existen partes que pueden ser
reutilizadas por otras aplicaciones.
4.15 Escalabilidad (Scalability)
Grado con el que se pueden ampliar el diseño arquitectónico, de datos o procedimental
117
Evaluación Arquitectónica de Visual Banker
Documento de Especificaciones de Requerimientos de Software
Versión: 1.0
Fecha: 08/05/2006
[Camacho, Cardeso, Nuñez, 2004].Podría considerarse también en términos de nuevos usuarios y
equipos.
Lo que hace
Lo que debería hacer
La aplicación permite una gran cantidad de
usuarios y una gran cantidad de equipos
trabajando de forma simultánea sin degradar el
desempeño. Esto se ve apoyado por presentar
una arquitectura de tipo cliente-servidor.
4.16 Capacidad de Prueba (Testability)
Medida de la facilidad con la que el Software, al ser sometido a una serie de pruebas, puede
demostrar sus fallas. Es la probabilidad de que, asumiendo que tiene al menos una falla, el Software
fallará en su próxima ejecución de prueba [Camacho, Cardeso, Nuñez, 2004].
Lo que hace
Lo que debería hacer
En algunos módulos es fácil realizar pruebas
Se debe facilitar la generación de pruebas que
que permitan verificar posibles fallas dentro del
permitan ver de una forma rápida y precisa los
sistema. En otros módulos se hace complicado
posibles fallos que muestre la aplicación. Esto
pues surgen errores que se tarda mucho tiempo
podría ser logrado a través de la generación de
en descubrir y comprender.
casos de prueba puntuales.
Se hace complicado hacer las simulaciones
correspondientes para que la aplicación muestre
una falla específica.
4.17 Funcionalidad (Funcionality)
Habilidad del sistema para realizar el trabajo para el cual fue concebido. Aparte de las
especificaciones funcionales descritas en las secciones anteriores, actualmente existen diversos
requerimientos funcionales que no se encuentran cubiertos dentro de la aplicación.[Camacho, Cardeso,
Nuñez, 2004].
118
APÉNDICE B
Visual Banker
Documento de Arquitectura de Software
Versión 1.0
119
Evaluación Arquitectónica de Visual Banker
Documento de Arquitectura de Software de Visual Banker
Versión: 1.0
Fecha: 15/05/06
Historia de Revisiones
Fecha
Versión
Descripción
Autor
15/05/06
1.0
Inicio del documento
Irene García
120
Evaluación Arquitectónica de Visual Banker
Documento de Arquitectura de Software de Visual Banker
Versión: 1.0
Fecha: 15/05/06
Tabla de Contenido
DOCUMENTO DE ARQUITECTURA DE SOFTWARE............................................................................ 122
1. INTRODUCCIÓN .................................................................................................................................. 122
1.1 PROPÓSITO DE ESTE DOCUMENTO ......................................................................................................122
1.2 ALCANCE ...........................................................................................................................................122
1.3 DEFINICIONES, SIGLAS, Y ABREVIACIONES...........................................................................................122
1.4 REFERENCIAS ....................................................................................................................................122
1.5 VISTA GLOBAL ...................................................................................................................................123
2. REPRESENTACIÓN ARQUITECTÓNICA............................................................................................ 123
3. METAS Y RESTRICCIONES ARQUITECTÓNICAS ............................................................................ 124
4. VISTA DE CASOS DE USO.................................................................................................................. 125
MODELO DE CASOS DE USO PARA EL MÓDULO DE PLATAFORMA ................................................................126
MODELO DE CASOS DE USO PARA EL MÓDULO DE TAQUILLA ......................................................................128
MODELO DE CASOS DE USO MÓDULO DE MANTENIMIENTO ........................................................................130
MODELO PLATAFORMA ............................................................................................................................131
DESCRIPCIÓN DE LAS CLASES DE PLATAFORMA .........................................................................................132
MODELO TAQUILLA ...................................................................................................................................133
DESCRIPCIÓN DE CLASES DE TAQUILLA .....................................................................................................134
MODELO DE MANTENIMIENTO ...................................................................................................................134
DESCRIPCIÓN DE CLASES DE MANTENIMIENTO ..........................................................................................135
5.1 PAQUETES DE DISEÑO ARQUITECTÓNICAMENTE SIGNIFICATIVOS .........................................................135
6. VISTA DE PROCESOS......................................................................................................................... 137
7. VISTA DE IMPLANTACIÓN .................................................................................................................. 137
VISTA DE IMPLANTACIÓN PARA UNA AGENCIA .............................................................................................137
VISTA DE IMPLANTACIÓN PARA UN CONJUNTO DE AGENCIAS .......................................................................139
8. VISTA DE IMPLEMENTACIÓN............................................................................................................. 139
8.1 VISTA GENERAL .................................................................................................................................139
8.2 CAPAS ...............................................................................................................................................140
9.CALIDAD ................................................................................................................................................ 144
121
Evaluación Arquitectónica de Visual Banker
Documento de Arquitectura de Software de Visual Banker
Versión: 1.0
Fecha: 15/05/06
Documento de Arquitectura de Software
1. Introducción
1.1 Propósito de este documento
El documento de la arquitectura del Software proporciona una descripción arquitectónica
comprensiva del sistema Visual Banker y sus respectivos módulos, usando vistas arquitectónicas para
representar diversos aspectos del sistema. Este documento sirve como medio de comunicación entre los
miembros del equipo del proyecto con relación a las decisiones arquitectónicas significativas que se han
tomado en el proyecto. Dicho documento provee una visión general de las diferentes vistas
arquitectónicas presentes en el sistema evaluado.
1.2 Alcance
El DAS apoya el desarrollo de una visión de la arquitectura del sistema, explorando y evaluando
las opciones arquitectónicas de alto nivel. Propicia que se llegue a un acuerdo con el líder del proyecto,
los equipos de desarrollo y otros Stakeholders en cuanto a la estructura de alto nivel del sistema.
Refleja las decisiones y suposiciones de trabajo en la implementación de la Visión, así como las
decisiones en relación a la arquitectura física y lógica y a los requerimientos no funcionales del sistema.
Conceptualmente ilustra la naturaleza esencial de la solución propuesta, centrándose en los
componentes principales e incluyendo los principales bloques de construcción. Se obtendrá información
acerca del ambiente actual considerando el alcance del sistema y la funcionalidad general requerida.
1.3 Definiciones, Siglas, y Abreviaciones
ƒ DAS: Documento de Arquitectura de Software.
ƒ ERS: Documento de Especificaciones de Requerimientos de Software.
1.4 Referencias
Para la elaboración de este documento se tomó en cuenta la información contenida en el ERS de
Visual Banker. También fue utilizada la información correspondiente a las metas tecnológicas las cuales
fueron suministradas por uno de los gerentes que posee una amplia relación con la aplicación evaluada.
Específicamente se empleó información contenida en los siguientes documentos:
ERS, elaborado en mayo de 2006.
Metas Tecnológicas.
122
Evaluación Arquitectónica de Visual Banker
Documento de Arquitectura de Software de Visual Banker
Versión: 1.0
Fecha: 15/05/06
1.5 Vista Global
En el documento serán desarrollados específicamente los puntos correspondientes a la
representación arquitectónica, metas y restricciones arquitectónicas, vista de casos de uso, vista lógica,
vista de implantación, vista de implementación, vista de datos y calidad. Para cada uno de los puntos
antes mencionados se presentará una breve descripción y se mostrarán los diferentes modelos o
diagramas en caso de que sea necesario.
2. Representación Arquitectónica
La tabla que se muestra a continuación pretende indicar las vistas existentes dentro del sistema,
así como los elementos de modelado que contiene cada una de ellas. Para ello se hará una lista donde
se va a representar el conjunto de elementos presentes en cada una de las vistas, además de una breve
descripción del significado de cada uno de ellos. Las vistas que no van a ser tratadas en el documento,
tampoco serán mostradas en el siguiente cuadro.
Vista
Vista de Casos
Elemento de modelado
Actor
de Uso
Descripción
Permite representar a un agente externo que tenga
algún tipo de interacción con la aplicación. Dicho
agente puede ser una persona u otro sistema.
Caso de Uso
Permite representar una funcionalidad específica que
cumple la aplicación.
Especialización/
Representa un tipo de relación entre dos casos de uso
Generalización
a través de la cual se conecta un caso de uso
genérico (la generalización) con uno o más casos de
uso específicos.
Extend
Representa un tipo de relación que se puede
establecer entre dos casos de uso, la cual indica que
un caso de uso completa la funcionalidad expresada
por el otro, sin que sea obligatoria su inclusión para
cumplir con el caso de uso que se está extendiendo.
Include
Representa un tipo de relación que se puede
establecer entre dos casos de uso, la cual indica que
un caso de uso utiliza a otro, esto significa que el caso
123
Evaluación Arquitectónica de Visual Banker
Documento de Arquitectura de Software de Visual Banker
Versión: 1.0
Fecha: 15/05/06
de uso que es usado siempre debe incluirlo en el que
lo usa.
Vista Lógica
Clases
Representa un concepto fundamental dentro del
sistema, que posee ciertos atributos y métodos a
través de los cuales puede ser accedido.
Asociaciones
Permite establecer la conexión existente entre dos o
más clases. Estas asociaciones pueden representar
generalización, especialización, agregación, entre
otras.
Vista de
Componentes
Implementación
Vista de
Unidad básica dentro de la vista que representa un
concepto relevante.
Relaciones
Representan una asociación entre los componentes.
Interfaz
Conexión existente entre 2 o más elementos.
Nodos
Representan cualquier elemento físico como por
Implantación
ejemplo estaciones de trabajo, servidores, routers y
otros dispositivos.
Asociación
Representan la relación existente entre dos o más
nodos.
Vista de Datos
Entidades
Representan un concepto fundamental dentro del
dominio del problema.
Relaciones
Representan la relación existente entre dos o más
entidades pertenecientes al modelo.
3. Metas y Restricciones Arquitectónicas
Uno de los aspectos más importantes que son considerados dentro de la aplicación y que forma
parte de los requerimientos y objetivos del Software, se refiere a todo lo relacionado con el desempeño
(eficiencia). Aproximadamente 80 millones de transacciones anuales pasan a través de Visual Banker, lo
que requiere que la aplicación tenga una capacidad de procesamiento bastante grande y que ofrezca
tiempos de respuesta que no superen el minuto después de haber cargado toda la data requerida y haber
presionado el botón. La disponibilidad y confiabilidad también son elementos importantes, pues al tratarse
de la aplicación que da soporte a las 400 agencias (contando unidades administrativas) y a las Bancas
especializadas (Agrícola, Gobierno, Privada, Corporativa, Petrolera, etc.) se debe garantizar que la mayor
124
Evaluación Arquitectónica de Visual Banker
Documento de Arquitectura de Software de Visual Banker
Versión: 1.0
Fecha: 15/05/06
parte del tiempo el sistema se encuentre corriendo y en pleno funcionamiento, prestando los servicios
para los cuales fue creado. El tiempo que transcurre entre una falla y el levantamiento del sistema no
puede superar las 5 horas (3-5) en caso de que se trate de una falla crítica, pues sin el funcionamiento
correcto de la aplicación las agencias se quedan paralizadas y no pueden prestar ningún tipo de servicio.
De alguna manera la disponibilidad se provee a través de la modularidad de la aplicación, pues es
posible aislar los errores en ciertas transacciones y permitir que las demás sigan funcionando sin ningún
tipo de problema y de forma independiente. Incluso puede darse el caso de que ciertos módulos de la
aplicación sigan funcionando aunque sea en forma degradada.
El aspecto relacionado con portabilidad está teniendo un impacto importante dentro de la
aplicación pues se tiene planteado un proyecto bastante amplio de migración, que permita al sistema
presentar cierto grado de portabilidad al correr en otro sistema operativo (Windows) completamente
diferente al que corre en la actualidad; con otro manejador de base de datos (DB2 v8.0) y en otro
lenguaje de programación (Smalltalk v6.0). Actualmente estos aspectos no son cubiertos por la
aplicación, pero una de las metas es llegar a ese punto y conseguir un mejor desempeño de la misma en
diferentes ambientes de Hardware y Software. De igual manera, la modificabilidad juega un papel
importante, pues de alguna manera garantiza que todos los cambios que deben hacerse para poder
alcanzar la portabilidad, se lleven a cabo con una pequeña inversión de esfuerzo y dinero.
Por último, es importante mencionar que el atributo de seguridad se constituye actualmente como
una de las mayores preocupaciones dentro de la aplicación, pues existen un conjunto de fallas
relacionadas con este aspecto. Lo ideal sería conseguir que este atributo sea mucho más robusto y que
no ocurran tantas violaciones en el acceso al sistema. Por el tipo de aplicación y los datos que la misma
maneja, la confidencialidad e integridad de los datos allí registrados es sumamente importante.
4. Vista de Casos de Uso
El sistema analizado está compuesto principalmente por tres subsistemas que engloban
características y funcionalidades diferentes dentro de la aplicación. Por esta razón, la vista de casos de
uso que se presenta a continuación se encuentra dividida y enfocada en los casos de uso
correspondientes a cada uno de estos subsistemas; representados por el módulo de Plataforma, módulo
125
Evaluación Arquitectónica de Visual Banker
Documento de Arquitectura de Software de Visual Banker
Versión: 1.0
Fecha: 15/05/06
de Taquilla y módulo de Mantenimiento respectivamente.
Si se desea obtener mayor información sobre los casos de uso o actores, véase el documento de
Especificaciones de Software de Visual Banker. En este se presenta una descripción detallada de cada
uno de los casos de uso de los módulos de la aplicación, así como de los casos de uso generales y los
actores que participan en los mismos.
Modelo de Casos de Uso para el Módulo de Plataforma
El módulo de plataforma engloba todas aquellas funcionalidades que tienen que ver con el
registro de nuevos clientes o consulta de datos personales y/o financieros de los ya existentes, venta de
diferentes productos (cuentas, seguros, tarjetas, etc.) a los mismos, uso de calculadoras especiales, inicio
de sesión, cierre de sesión, entre otras. Dicho módulo es manejado por un promotor, quien se convierte
en el actor principal para todos los casos de uso relacionados con esta parte del sistema. En la Figura 1,
se presenta el modelo de casos de uso para el módulo de la aplicación antes mencionado.
Figura 1 [Modelo de Casos de Uso – Módulo de Plataforma]
126
Evaluación Arquitectónica de Visual Banker
Documento de Arquitectura de Software de Visual Banker
Versión: 1.0
Fecha: 15/05/06
La lista de los productos y subproductos asociados al caso de uso “Mostrar Catálogo de
Productos” puede ser consultada en el: Glosario de Transacciones y Productos de Visual Banker.
De igual manera, es importante destacar que en el modelo anterior solo se contemplan dos
niveles de casos de uso, pues simplemente fueron considerados los aspectos más importantes de toda la
funcionalidad que presenta la aplicación. Sin embargo, el caso de uso denominado “Ver Ficha Cliente”
fue desarrollado en un nivel más de detalle por considerarse de gran importancia al englobar otro grupo
de funcionalidades que no deben ser obviadas y que pueden producirse una vez se inicia el caso de uso
antes mencionado. Dichas funcionalidades se refieren a “Ver datos demográficos”, “Ver resumen
Banesco” y “Ver carpeta financiera”. El modelo de casos de uso correspondiente se presenta a
continuación.
Figura 2 [Modelo de Casos de Uso – Ver Ficha Cliente]
Una vez que se consulta la ficha el cliente, es posible ver todo lo relacionado con los datos
demográficos del mismo, la carpeta financiera y el resumen de Banesco. Los datos demográficos se
refieren a los datos personales del cliente, bien sea una persona natural o jurídica. La carpeta financiera
permite ver todos los productos que a adquirido el cliente dentro del banco, como por ejemplo las cuentas
que posee dentro de la organización.
Por último, el resumen Banesco muestra los datos relacionados con las sesiones en las cuales
ha estado presente el cliente. Este último punto se emplea más para uso interno pues es posible ver la
127
Evaluación Arquitectónica de Visual Banker
Documento de Arquitectura de Software de Visual Banker
Versión: 1.0
Fecha: 15/05/06
fecha de la última sesión, la duración, los productos adquiridos y ofrecidos en dicha sesión, etc. Sin
embargo, es importante tener en cuenta que estas funcionalidades lo que hacen es complementar el
caso de uso “Ver ficha cliente” ya que las mismas son opcionales; es decir, cuando se ve la ficha de un
cliente no es obligatorio hacer ninguna de estas consultas.
Modelo de Casos de Uso para el Módulo de Taquilla
En el módulo de taquilla se manejan todas las funcionalidades relacionadas con los depósitos,
retiros, traspasos, pagos de tarjeta, emisión de cheques de gerencia, pago de servicios, pago a
proveedores, afiliación a L.P.H. (Ley de Política Habitacional), pago de cheques, pagos de impuestos,
pago de promociones especiales, entre otras. Además de las transacciones antes mencionadas, el
taquillero está en la capacidad de cambiar su clave de usuario, usar la calculadora para realizar algún
tipo de cuenta o buscar una transacción de manera inmediata indicando únicamente el número de la
misma. Como para el resto de los módulos, también se encuentran los casos de uso relacionados con la
entrada y salida del sistema.
Figura 3 [Modelo de Casos de Uso – Módulo de Taquilla]
128
Evaluación Arquitectónica de Visual Banker
Documento de Arquitectura de Software de Visual Banker
Versión: 1.0
Fecha: 15/05/06
El caso de uso “Ejecutar Transacción” es considerado de gran importancia para este módulo ya
que representa todas las transacciones que pueden ser ejecutadas desde Taquilla. Por esta razón, el
mismo será presentado en mayor nivel de detalle que el resto de los casos de uso. Es importante
destacar que existen una gran cantidad de casos de uso asociados a “Ejecutar Transacción” pero sólo
serán mostrados aquellos que se consideren de mayor importancia para la aplicación y que en algunos
casos no se cumplen actualmente. El conjunto total de transacciones que son representadas a través de
este caso de uso pueden ser consultadas en el Glosario de la aplicación.
Figura 4 [Modelo de Casos de Uso Taquilla - Ejecutar Transacción]
Los casos de uso correspondientes a “Seleccionar Pago de Servicios Depósitos Propios”,
“Seleccionar Pago de Servicios Consulta de Saldos CANTV”, “Seleccionar Pago de Servicios
Recaudaciones” y “Seleccionar Pago de Servicios CANTV”, pertenecen a la transacción denominada
“Pago de Servicios” y los mismos sólo pueden producirse una vez que se inicie el caso de uso “Ejecutar
Transacción”.
Pago de servicios solamente representa una de las diferentes transacciones que pueden ser
ejecutadas desde el módulo de Taquilla. Sin embargo, fue considerada en esta oportunidad ya que
actualmente algunas de las funcionalidades de la misma no se encuentran completamente
129
Evaluación Arquitectónica de Visual Banker
Documento de Arquitectura de Software de Visual Banker
Versión: 1.0
Fecha: 15/05/06
implementadas como es el caso de la opción de “Recaudaciones”. Existe un requerimiento funcional
específico asociado a esta opción.
Modelo de Casos de Uso Módulo de Mantenimiento
En el módulo correspondiente a mantenimiento se engloban las funcionalidades que tienen que
ver con el manejo de usuarios de la aplicación. El mismo es controlado por un administrador que puede
crear nuevos usuarios, además de eliminar o modificar a los ya existentes. De esta manera se determina
quienes pueden tener acceso a la aplicación y el rol que podrán ejercer una vez que se defina su perfil.
Figura 5 [Modelo de Casos de Uso – Módulo de Taquilla]
5. Vista Lógica
A continuación se presenta el Modelo Lógico para cada uno de los módulos de la aplicación. Es
importante destacar que en cada caso solo se tomaron en cuenta las clases más relevantes y que
poseen métodos que son empleados por otras clases, debido a la gran extensión que posee la
aplicación. Para cada uno de los modelos lógicos se realizará la explicación del significado de las clases
que se muestren en el mismo.
130
Evaluación Arquitectónica de Visual Banker
Documento de Arquitectura de Software de Visual Banker
Versión: 1.0
Fecha: 15/05/06
Modelo Plataforma
Figura 6 [Vista Lógica – Módulo de Plataforma]
131
Evaluación Arquitectónica de Visual Banker
Documento de Arquitectura de Software de Visual Banker
Versión: 1.0
Fecha: 15/05/06
Descripción de las Clases de Plataforma
Clase
FcPhoneNumber
Descripción
Número de teléfono de una persona natural o jurídica.
FcAddress
Dirección de una persona natural o jurídica.
BcVenezuelaAddress
Clase desarrollada dentro de la organización que extiende de
FcAddress y que contiene otro tipo de datos que son
considerados dentro de las direcciones venezolanas.
FcEconomicEntity
Cualquier cliente de la organización bien sea una persona
natural o jurídica.
FcPerson
Sublcase de FCEconomicEntity que representa a los clientes
naturales.
FcEnterprise
Sublcase de FCEconomicEntity que representa a los clientes
jurídicos.
FcPersonName
Nombre y otros datos de una persona (cliente natural).
FcEnterpriseName
Nombre y otros datos de una empresa (cliente jurídico).
BcPerson
Sublcase de FcPerson desarrollada dentro de la organización,
la cual contiene otro tipo de atributos que no fueron
considerados en la clase padre.
BcEnterprise
Sublcase de FcEnterprise desarrollada dentro de la
organización, la cual contiene otro tipo de atributos que no
fueron considerados en la clase padre.
BcPersonName
Subclase de la clase BcPersonName que contiene información
sobre el nombre de los clientes naturales, además de otros
atributos no considerados en la clase padre.
FcProperty
Clase que representa las propiedades adquiridas por los
clientes.
BcProperty
Subclase de FcProperty que representa las propiedades
adquiridas por un cliente del banco.
BcAgreementBanesco
Cualquier tipo de producto que un cliente natural o jurídico
mantiene con la organización.
BcAgent
Persona encargada de manejar el módulo de Plataforma
(agente).
BcPlan
Plan que tiene asignado un cliente específico dentro del Banco.
BcLocalAgreement
Productos internos que mantiene el cliente con la organización.
BcExternalAgreement
Productos externos que mantiene el cliente con la
organización.
132
Evaluación Arquitectónica de Visual Banker
Documento de Arquitectura de Software de Visual Banker
BcChequeGerencia
Versión: 1.0
Fecha: 15/05/06
Producto ofrecido por el banco a sus clientes, denominado
Cheque de Gerencia.
BcCreditos
Producto ofrecido por el banco a sus clientes, denominado
Crédito.
BcServicio
Servicios ofrecidos por el Banco a sus clientes.
BcSeguros
Seguros ofrecidos por el Banco como un tipo de producto.
BcCertificado
Certificados ofrecidos por el Banco como un tipo de producto.
BcCuenta
Tipos de cuentas ofrecidas por el Banco a sus clientes como
un tipo de producto.
BcMonedaExtranjera
Moneda Extranjera como un tipo de producto ofrecido.
BcSolicitudTarjetaDeCredito
Tarjetas de Crédito como un tipo de producto ofrecido.
Modelo Taquilla
Figura 7 [Vista Lógica – Módulo de Taquilla]
133
Evaluación Arquitectónica de Visual Banker
Documento de Arquitectura de Software de Visual Banker
Versión: 1.0
Fecha: 15/05/06
Descripción de Clases de Taquilla
Clase
BcValidarCuenta
Descripción
Clase que permite validar la cuenta de los clientes al momento de
hacer una transacción.
BcValidarMonto
Clase que permite validar un monto a la hora de efectuar una
transacción.
BcJournal
Clase que permite registrar todas las operaciones realizadas dentro
de la aplicación, sean satisfactorias o no.
BcOperadorTaquilla
Clase que representa a la persona que maneja el módulo de
taquilla.
BcImpresiónTaquilla
Clase que permite llevar a cabo la impresión de los comprobantes.
BcMovimientoCuenta
Clase que representa todos los movimientos realizados en una
cuenta específica de alguno de los clientes del banco.
BcMovimientosSeniat
Clase que representa todos los movimientos relacionados con el
Seniat.
BcDiferidosCuenta
Clase que representa el saldo que se encuentra diferido en una
cuenta específica.
BcNotasMultiples
Clase que registra las diferentes notas múltiples realizadas.
BcRafaga
Clase a través de la cual se registran todos los datos enviados y
recibidos del AS400 como una ráfaga de información.
BcConsultaSaldos
Clase que representa la consulta de saldo de cualquier cliente sobre
alguna de sus cuentas.
BcConsultaSaldosCtaAhorro
Clase que hereda de “BcConsultaDeSaldos” y que se refiere
específicamente a la consulta en una cuenta de ahorro.
BcConsultaSaldosCtaCorriente
Clase que hereda de “BcConsultaDeSaldos” y que se refiere
específicamente a la consulta en una cuenta de corriente.
BcConsultaSaldosCANTV
Clase que hereda de “BcConsultaDeSaldos” y que se refiere
específicamente a la consulta de saldos de CANTV.
BcConsultaSaldosMovimientos
Clase que hereda de “BcConsultaDeSaldos” y que se refiere
específicamente a la consulta de saldos de Calos movimientos
realizados.
Modelo de Mantenimiento
Para el modelo de mantenimiento solo fueron consideradas las tres clases más relevantes dentro
del módulo y que de alguna manera representan la lógica del mismo.
134
Evaluación Arquitectónica de Visual Banker
Documento de Arquitectura de Software de Visual Banker
Versión: 1.0
Fecha: 15/05/06
Figura 8 [Vista Lógica – Módulo de Plataforma]
Descripción de Clases de Mantenimiento
Clase
BcUsuariosView
Descripción
Clase visual que representa el menú principal de mantenimiento a
través del cual se pueden llevar a cabo los casos de uso planteados
para este módulo.
BcLoginDeMantenimientoView
Clase visual que permite a los usuarios entrar al módulo de
mantenimiento, ingresando para ello su usuario y password
correspondientes.
BcMovimientoHistorico
Clase que permite llevar un registro de todas las transacciones y
operaciones realizadas a través del módulo.
5.1 Paquetes de Diseño Arquitectónicamente Significativos
Como se mencionó anteriormente, la aplicación se compone fundamentalmente por tres módulos
denominados Plataforma, Taquilla y Mantenimiento. Por esta razón, los mismos son considerados como
paquetes significativos dentro del sistema, pues cada uno posee un conjunto de clases (con sus
respectivos atributos y métodos) que le dan sentido a la parte de la aplicación que representan.
En el diagrama que se muestra a continuación se pretende especificar la relación existente entre
cada uno de los paquetes. El paquete de plataforma y el de taquilla están estrechamente relacionados,
pues todo promotor que maneje el módulo de plataforma puede hacer uso de las funcionalidades de
taquilla pero no en forma contraria. De igual manera, ambos módulos se relacionan con el de
mantenimiento, pues es en este último en donde se definen los usuarios con sus respectivos roles, que le
van a permitir o negar el acceso a la aplicación.
135
Evaluación Arquitectónica de Visual Banker
Documento de Arquitectura de Software de Visual Banker
Versión: 1.0
Fecha: 15/05/06
Figura 9 [Paquetes de Diseño Visual Banker]
Plataforma Æ Contiene las clases métodos y atributos correspondientes al módulo de plataforma.
Taquilla Æ Contiene las clases métodos y atributos correspondientes al módulo de taquilla.
Mantenimiento Æ Contiene las clases métodos y atributos correspondientes al módulo de
mantenimiento.
Estos paquetes engloban de forma general a toda la aplicación y a su vez están constituidos por
otro grupo de paquetes que contienen las diferentes clases que conforman al sistema. Alguno de estos
paquetes se refieren a el paquete de las Forms (representa a las formas reusables que pueden ser
utilizadas dentro de diferentes vistas), el paquete de las Views (representa a las clases gráficas o
interfaces) y el paquete de los Models (clase de comunicación con el AS400). Los módulos de Taquilla,
Plataforma y Mantenimiento poseen a cada uno de estos paquetes, entre otros. Sin embargo, sólo se
nombraron aquellos que permiten representar a la aplicación de manera generalizada.
Figura 10 [Paquetes de Visual Banker]
136
Evaluación Arquitectónica de Visual Banker
Documento de Arquitectura de Software de Visual Banker
Versión: 1.0
Fecha: 15/05/06
6. Vista de Procesos
Esta vista no aplica para el tipo de sistema que está siendo evaluado pues en el mismo no se
presenta paralelismo entre los procesos.
7. Vista de Implantación
En las vistas de implantación que se muestran a continuación se indica la distribución física que
debe tener la aplicación para su correcto funcionamiento. Es importante destacar que se muestran dos
vistas diferentes porque la primera de ellas corresponde a la distribución dentro de cada una de las
agencias bancarias a las cuales da soporte la aplicación. La segunda vista muestra la interacción de
todas las agencias entre si y con el servidor principal (AS400).
Vista de Implantación para una Agencia
En el diagrama que se presenta a continuación se muestran todos los elementos que están
presentes dentro de cada una de las agencias y que permiten el correcto funcionamiento de la aplicación.
Figura 10 [Implantación en una Agencia]
En primer lugar se cuenta con las estaciones de trabajo, las cuales difieren en algunas
características dependiendo si se encuentran en plataforma (utilizadas por los promotores) o en taquilla
(usadas por los cajeros). Las de taquilla varían en un rango que va desde Pentium 1 de 166 mhz (aprox.
137
Evaluación Arquitectónica de Visual Banker
Documento de Arquitectura de Software de Visual Banker
Versión: 1.0
Fecha: 15/05/06
el 65%) hasta Pentium 3 de 1 Ghz (aprox. el 35%). Por su parte las estaciones de Plataforma varían
desde Pentium 1 de 166 mhz (aprox. el 10%), Pentium 2 y 3 menores a 350 mhz (aprox. el 35%) hasta
Pentium 3 mayores a 750 mhz (aprox. el 55). El número de estaciones de trabajo puede ser diferente
dentro de cada agencia, pues este parámetro va a depender de la cantidad de personal con la que se
cuente. Sin embargo, el desempeño de la aplicación no se ve afectado por un incremento en el número
de estaciones.
También se cuenta con ciertos dispositivos como los son las impresoras láser y las validadoras.
Las impresoras láser son Delcop o Multifuncionales, mientras que las validadotes son IBM 9068, IBM
4722 y Siemens 4915. Por su parte los servidores también presentan un rango de variación en cuando al
modelo y velocidad. El 60% de los servidores de las agencias son Netfinity 5600 y 5100 con Pentium 3 de
750 mhz o inferior. Aproximadamente el 30 % son Netfinity 5000 y el 10% restante son PC Server 330
con Pentium 1 y Netfinity 3500 Pentium 3. Es importante destacar que la información que se guarda en el
servidor local (por agencia) es la referente a las transacciones realizadas día a día (para poder
reversarlas en caso de errores), además del conjunto de usuarios y los perfiles de esa agencia en
particular; pero no se maneja información referente a los clientes ni de los productos que los mismos
mantienen con la organización. Todo lo relacionado con esos aspectos es almacenado en el servidor
principal AS400, del cual se hablará más adelante.
Todos los equipos (incluyendo estaciones, dispositivos y servidores) se comunican entre sí a
través de una red LAN (Local Area Network) de tipo Token Ring (anillo) con una velocidad de 16 Mbps.
Toda la información entra a la LAN o sale hacia el servidor principal a través de un Router conectado a
una red Ethernet con una velocidad de 64 Kbps.
Para los módulos de plataforma y taquilla se emplea el protocolo de comunicación SNA/APPC,
mientras que para el resto de las aplicaciones ubicadas en las estaciones de trabajo (Lotus notes, Tivoli,
etc) se emplea el protocolo TCP/IP. Es importante destacar que aproximadamente un 50% de las
agencias trabajan con un mínimo de ancho de banda de 64 Kbps mientras que el resto han sido migradas
a 128 Kbps.
138
Evaluación Arquitectónica de Visual Banker
Documento de Arquitectura de Software de Visual Banker
Versión: 1.0
Fecha: 15/05/06
Vista de Implantación para un conjunto de Agencias
El modelo que se presenta a continuación representa cómo se comunican el conjunto de
agencias entre sí y con el servidor principal que lleva el registro de todos los clientes y los productos
adquiridos por los mismos. Dicho servidor se encuentra ubicado en la sede principal, con una replicación
en otro edificio ubicado en la misma ciudad. Cada uno de los anillos que representa a las agencias se
comunica a una red WAN (Wide Area Network) a través de la cual se puede tener acceso al servidor
principal. El pase de la información de una red a otra se hace a través de los Routers estratégicamente
colocados. Dicha red WAN posee una topología tipo Token Ring con una velocidad de 64 kbps.
Figura 11 [Implantación en un grupo de agencias-WAN]
8. Vista de Implementación
8.1 Vista General
La aplicación está constituida por cuatro capas diferentes cada una de las cuales cumple con una
función específica. Dichas capas son Aplicación, Servicios, Arquitectura e Implementación.
La capa de Aplicación extiende los servicios principales provistos por las otras capas, utilizando
estructuras reusables y extensibles (framewoks) para áreas específicas. En forma general, esta capa
contiene frameworks para acceder, ingresar y manipular la información del cliente, presentar productos,
concretar una venta, etc. La capa de Servicios está compuesta por los dominios que proveen servicios a
139
Evaluación Arquitectónica de Visual Banker
Documento de Arquitectura de Software de Visual Banker
Versión: 1.0
Fecha: 15/05/06
las aplicaciones. Controla, por ejemplo, las múltiples sesiones de usuario y provee facilidades de
representación de objetos del negocio.
Por su parte, la capa de Arquitectura de Software envuelve distintos subsistemas que se
encargan de proveer servicios de bajo nivel, extremadamente reusables y que se abstraen y extienden la
capa de implementación. Por último, la capa de implementación, está compuesta por sistemas básicos
que soportan bases de datos, comunicaciones, lenguaje de programación, entre otros.
En el diagrama que se muestra a continuación, es posible observar la distribución de las capas
de la aplicación, así como la interacción de todos los subsistemas que se presentan en cada una.
APLICACIÓN
VISUAL BANKER
Aplicación
Salidas
Formateadas
Interface
a Usuarios
Modelo
de Negocios
Servicios
de Aplicación
Autenticación
Servicios
ARQUITECTURA
DE SOFTWARE
Arquitectura
Herram. de
Cont. de Vers.
Sistema
Operativo
Visual Age
Comunicaciones
Base de
Datos
Implementación
Figura 12 [Capas de la Arquitectura – Visual Banker]
8.2 Capas
Capas
Aplicación
Susbsistemas
Administración de
Descripción
Aplicación que permite crear, eliminar y modificar
Agentes
usuarios y grupos en el sistema, así como la
permisología que poseen los mismos. Dicha
permisología se maneja a través de tokens, los
cuales son asignados a cada uno de los grupos de
agentes creados. Cuando un agente forma parte
140
Evaluación Arquitectónica de Visual Banker
Documento de Arquitectura de Software de Visual Banker
Versión: 1.0
Fecha: 15/05/06
de un grupo, este recibe inmediatamente los
tokens que el grupo tenga. Un agente sin tokens
asignados tiene privilegios básicos.
Búsqueda de Clientes
Permite acceder a la información de los clientes
utilizando
diferentes
criterios
de
búsqueda.
Además de recuperar la información básica del
cliente (nombre, apellido, etc) indica si la misma se
encuentra en Lista Negra y Sicri.
Ficha de Cliente
Simula en el sistema la carpeta que las agencias
mantienen
por
cada
cliente.
La
información
contenida en la misma incluye información de
Banesco, demográfica y financiera.
Administración de
Formada por un conjunto de aplicaciones que
Ofrecimientos
permiten crear, modificar y eliminar presentaciones
de productos y datos de comparación de los
mismos.
Catálogo de
Aplicación
que
permite
mostrar
todos
los
Productos
ofrecimientos, las presentaciones de los mismos,
realizar la comparación entre productos, imprimir
folletos y seleccionar para la venta.
Herramientas de
Conjunto de calculadoras financieras que permiten
Ventas
realizar recomendaciones a los clientes basándose
en los requerimientos de los mismos.
Sesión con el Cliente
Le permite registrar al agente automáticamente,
actividades de mercadeo y de venta. Estas
actividades
son
empleadas
para
medir
el
rendimiento del agente.
Venta de Productos
Aplicación que permite realizar la venta de los
productos
que
el
cliente
desee.
Todos
los
ofrecimientos que se hayan marcado para la
compra aparecerán en esta aplicación para que la
venta de este sea completada.
Planes de Venta
Está formado por el conjunto de aplicaciones:
Administración de Planes de Venta, Duración de
Sesión, Reportes de Planes de Venta y Status de
Productos.
141
Evaluación Arquitectónica de Visual Banker
Documento de Arquitectura de Software de Visual Banker
Aplicaciones Externas
Versión: 1.0
Fecha: 15/05/06
Permite al agente ejecutar aplicaciones que no se
encuentren integradas en el ejecutable binario de
Visual Banker; es decir, programas que se pueden
ejecutar de forma independiente. Ej. Lotus Notes.
Stock de Números de
Los números de documentos que se requieren
Documentos
administrar en las agencias
consultados
y
son almacenados,
eliminados,
utilizando
las
aplicaciones pertenecientes a este subsistema.
Matriz de Productos
Aplicación que proporciona al agente la facilidad de
obtener una lista de productos que pueden ser
adquiridos por el cliente, mediante la realización de
una serie de preguntas.
Reversos de
Permite al agente realizar los reversos de las
Transacciones
transacciones realizadas durante el día en curso.
Utilitarios
Forman parte de este subsistema, el conjunto de
pequeñas
aplicaciones
que
permiten
realizar
actividades utilitarias dentro de Visual Banker. Ej.
Cambio de Consecutivo, Cambio de Password,
Cerrar Agencia, etc.
Servicios
Modelo de Negocio
El dominio de negocio abstrae el comportamiento y
las relaciones de los objetos del mundo real y
soporta funciones específicas para proveer un
modelo de la industria financiera. El núcleo del
mismo es el Business Model, el cual representa
clases y objetos del mundo real, agrupados en
subsistemas de funcionalidad común.
Salidas Formateadas
Este subsistema extrae información de los objetos
del modelo y se la envía a distintos motores de
presentación.
Autenticación
Este subsistema provee la interface que verifica la
identidad
de
los
usuarios
y
determina
sus
privilegios de acceso.
Servicios de
Son subsistemas definidos con el objetivo de
Aplicación
soportar
la
capa
compuestos
por
subsistemas
de
de
aplicaciones.
subsistemas
servicios
de
Están
gráficos,
notificables
y
142
Evaluación Arquitectónica de Visual Banker
Documento de Arquitectura de Software de Visual Banker
Versión: 1.0
Fecha: 15/05/06
subsistemas de registro de eventos, entre otros.
Interface de Usuario
Este subsistema extiende y define subsistemas
que se encargan de facilitar el manejo de la
interface con el usuario de las aplicaciones.
Arquitectura
Registro
El subsistema de registro provee un nivel de
desacoplamiento
entre
el
consumidor
y
el
administrador de una entidad. Si se desea asociar
una nueva entidad global con el identificador
público desconocido, este subsistema permite que
la nueva entidad global sea registrada bajo ese
identificador.
Persistencia
Permite, en forma transparente, hacer que el
modelo de negocio sea guardado a una estructura
de datos persistente.
Relaciones
Provee un modelo semántico de relaciones.
Administra las relaciones entre las clases del
modelo de objetos, asegurando que se mantenga
la integridad de las mismas durante la operación
del sistema.
Unidad de Trabajo
Provee un mecanismo o forma conveniente para
que los programadores puedan actualizar la
información.
Restricciones y
Provee los mecanismos para definir restricciones
Validaciones
en los atributos de los objetos y para verificar que
los atributos respeten dichas restricciones.
Administrador de
Permite administrar colecciones dentro de una
Colecciones
aplicación cliente, almacenar eventos y controlar
cambios en las colecciones así como en los
elementos de la colección.
Excepciones
Administra errores encontrados por otros dominios
de Visual Banker
y aplicaciones extendidas
basadas en Visual Banker. Provee un mecanismo
eficiente para reportar errores en forma consistente
y completa.
143
Evaluación Arquitectónica de Visual Banker
Documento de Arquitectura de Software de Visual Banker
Localización
Versión: 1.0
Fecha: 15/05/06
Provee a Visual Banker una forma de obtener,
liberar y almacenar recursos externos. Con él, las
aplicaciones se pueden crear independientemente
del lenguaje, conjunto de caracteres, formato de
fecha/hora, etc.
Implementación
Esta capa está compuesta por sistemas básicos
que soportan BD, comunicaciones, herramientas
de control de versiones, SO y lenguajes de
programación.
9. Calidad
Req. de Calidad
Funcionalidad
Sub-característica
Vista
Elemento arquitectónico
Adecuación
Vista de
Casos de Uso.
Corrección
Implantación.
Perfiles y claves de
Interoperabilidad
Vista de Casos de
Usuario.
Conformidad
Uso.
Replicación de BD local.
Madurez
Vista de
Canales de Comunicación
Recuperabilidad
Implantación.
alternos.
Facilidad de Aprendizaje
Vista de
Módulos.
Facilidad de Comprensión
Implementación.
Capas.
Comportamiento Temporal
Vista de Casos de
Casos de Uso.
Utilización de Recursos
Uso.
Estabilidad
Vista de
Módulos.
Analizabilidad
Implementación.
Formas Reusables
Facilidad de Instalación
Vista de
Canales de Comunicación.
Adecuación
Implementación
Seguridad
Fiabilidad
Tolerancia a Fallas
Facilidad de Uso
Operatividad
Eficiencia
Mantenibilidad
Cambiabilidad
Facilidad de Prueba
Portabilidad
Remplazabilidad
Adaptabilidad
144
Evaluación Arquitectónica de Visual Banker
Glosario de Transacciones y Productos
Versión: 1.0
Fecha: 25/05/06
APÉNDICE C- Glosario de Transacciones y Productos
ƒ En el módulo de Plataforma se cuenta con los productos y subproductos que se muestran a
continuación. El caso de uso “Mostrar Catálogo” aplica para cualquiera de los productos contenidos en la
siguiente lista:
Producto
Tarjetas
Sub-producto
Tarjeta respaldada.
Producto
Moneda Extranjera
Tarjeta privada.
Sub-producto
Venta de transferencias.
Venta de cheques de
gerencia.
Servicios
Tarjeta Master Card.
Travellers al cobro.
Tarjeta Visa.
Compra de efectivo.
Tarjeta de servicio Plan
Venta de cheques de
Estrella.
gerencia genéricos.
Cheques de Gerencia.
Cheques al cobro.
Cajas de Seguridad.
Compra de cheques de
viajero.
Tarjeta Siste+ Banesco y/o
Compra Visa Travel Money.
adicional.
Certificados
Participaciones intereses por
Seguros
Póliza de vida integral en
adelantado.
USD.
Participaciones tradicionales.
Póliza de vida integral.
Certificados de ahorro.
Combinado residencial
especial.
Depósito a plazo fijo.
Planes
Participaciones flexibles
Planes años dorados.
Plan 1era clase.
dólares.
Cuentas
Participaciones flexibles.
Plan comercio.
Cuenta F.A.L
Plan crecimiento.
Cuenta Corriente Plan Estrella.
Plan empresa.
Afiliación a L.P.H
Plan despegue.
Cuenta Corriente c/intereses.
Cuenta de Ahorro.
Moneda Extranjera
Venta de transferencias.
Venta de cheques de
gerencia.
Cuenta Electrónica.
Travellers al cobro.
145
Evaluación Arquitectónica de Visual Banker
Glosario de Transacciones y Productos
Versión: 1.0
Fecha: 25/05/06
ƒ El módulo de Taquilla posee las opciones y transacciones que se muestran en el siguiente cuadro. El
caso de uso “Ejecutar Transacción” se refiere a cualquiera de las transacciones que aparecen en la lista
que se muestra a continuación.
Opción
Ahorro Habitacional
Transacción
Aporte a cargo en cuenta.
Aporte en efectivo/cheque otros bancos.
Total de pagos realizados por Agencia.
Bloqueos y Diferidos
Bloqueo de fondos.
Desbloqueo de fondos.
Cuenta corriente sin intereses – desglose de cheques
recibidos.
Cuenta de ahorros – desglose de cheques recibidos.
Cuenta corriente con intereses – desglose de cheques
recibidos.
Cuenta F.A.L – desglose de cheques recibidos.
Cuenta de ahorro migración Unibanca – desglose de cheques
recibidos.
Cheques recibidos en Depósitos
Cuenta corriente con intereses – cheques recibidos en
depósitos.
Cuenta corriente sin intereses – cheques recibidos en
depósitos.
Cheque de Gerencia – recibido en depósito.
Consulta y Movimientos
Consulta de firmas.
Consulta remota del funcionario.
Cuenta corriente sin intereses – consulta de diferidos.
Consulta última transacción del cajero.
Cuenta de ahorros - consulta de diferidos.
Cuenta de ahorros – actualización de libretas.
Cuenta corriente con intereses – consulta de diferidos.
Cuenta F.A.L – consulta de diferidos.
Cuenta F.A.L – actualización de libreta.
Consulta de saldo.
Consulta de saldo cuentas castigadas.
Cuenta de ahorro migración Unibanca – consulta de diferidos.
Cuenta de ahorro migración Unibanca – actualización de
146
Evaluación Arquitectónica de Visual Banker
Glosario de Transacciones y Productos
Versión: 1.0
Fecha: 25/05/06
libreta.
Conversión de cuentas de otros bancos.
Depósitos
Cuenta Electrónica – depósitos
Depósitos.
Emisión de cheques de Gerencia
Cancelación cuentas/sust. Cheques/clientes exentos.
En efectivo.
Con cargo en cuenta.
Con cheque Banesco.
Pago de Cheques
Cuenta corriente – pago de cheques.
Cheque de gerencia – pago de cheques.
Pago de Promociones Especiales
Brahma – pago de ticket
Pago de Proveedores
Pago de proveedores.
Pago de Servicios
Depósitos propios.
Consulta de saldos CANTV.
CANTV.
Recaudaciones - Pago de servicios.
Pensionados IVSS
Cuenta de ahorro pensionados – actualización de libreta
pensionados.
Cuenta de ahorro pensionados – retiro pensionados.
Retiros
Retiro.
Cuenta electrónica – retiro.
Reverso General de Transacciones
Reverso general de transacciones.
Tarjetas de Crédito
Avance de efectivo – depósitos de comercio.
Pago de tarjetas de crédito.
Avance con abono en cuenta.
Totales
Totales del cajero.
Traspasos
Cuadre de efectivo en cofre.
Ingresos misceláneos.
Egresos misceláneos.
Ingresos de bóveda.
Egresos de bóveda.
147
Evaluación Arquitectónica de Visual Banker
Utility Tree y ABAS
Versión: 1.0
Fecha: 05/06/06
APÉNDICE D – Utility Tree y ABAS para cada Escenario
1. Introducción
El siguiente documento tiene como objetivo fundamental presentar el árbol de utilidad (UT) de
Visual Banker, así como los ABAS correspondientes a cada uno de los escenarios contemplados dentro
del mismo.
El UT lo que busca es representar a través de diferentes escenarios como es el comportamiento
del sistema, no a tiempo de ejecución sino en cuanto a los atributos de calidad que éste debe poseer.
Para ello se contemplan escenarios que se cumplen actualmente, otros que no se cumplen en lo absoluto
y otros que se cumplen pero que pueden ser mejorados.
De igual manera, algunos de estos escenarios son de crecimiento, es decir, representan como
debe evolucionar el sistema con el transcurso del tiempo; otros son escenarios de casos de uso, que
representan la interacción de un usuario con el sistema y otros son escenarios de tipo exploratorio, los
cuales representan situaciones en las que el sistema es estresado para poder ver su comportamiento.
2. Alcance
En el documento se presenta el árbol de utilidad con todos los escenarios, así como la
ponderación de cada uno de ellos y de los atributos de calidad por parte de los Stakeholders. De igual
manera se presenta un ABAS por cada uno de los escenarios contenidos en el UT.
3. Leyenda
a. Utility Tree
1. (H) Mayor importancia (parámetro 1), mayor dificultad de implementación (parámetro 2).
2. (M) Importancia media (parámetro 1), dificultad de implementación media (parámetro 2).
3. (L) Importancia baja (parámetro 1), dificultad de implementación baja (parámetro 2).
4. Los valores que poseen los atributos de calidad del segundo nivel del árbol, corresponden al
orden de importancia asignado por los Stakeholders, considerando el valor 1 como el más
148
Evaluación Arquitectónica de Visual Banker
Utility Tree y ABAS
Versión: 1.0
Fecha: 05/06/06
importante y el valor 5 como el menos importante.
b. ABAS
1. (A) Decisión arquitectónica existente actualmente en Visual Banker.
2. (P) Decisión arquitectónica propuesta como solución para Visual Banker.
Cantidad de
Transacciones
Eficiencia
(1)
Tiempo de
Respuesta
Facilidad de
Cambio
Mantenibilidad
(3)
Seguridad
de los Datos
Utility
Funcionalidad
(2)
8. Se intenta realizar un acceso no autorizado dentro de la
aplicación. (H, L)
9. Una persona accede al módulo de Mantenimiento como usuario
genérico. (M, L)
10. Se desea tener un archivo de log que permita registrar todas las
operaciones realizadas por los usuarios en la BD. (H, H)
11. Se requiere que los cambios en los passwords de los usuarios
se realicen constante mente y que su deducción sea difícil. (H, M)
12. Se requiere que la data viaje encriptada. (H, H)
13. Se consulta una firma digitalizada. (H,M)
14. Ocurre el mecanismo de RollBack dentro de la BD. (M, L)
15. Ocurre una modificación en la firma de un cliente. (M, L)
Seguridad Física
16. Se desea que los servidores locales se encuentren replicados
en el servidor principal. (M, H)
Facilidad de
Instalación
Adaptabilidad
Madurez
Recuperabilidad
Fiabilidad
(4)
5. Se agrega una nueva funcionalidad a la aplicación. (H, L)
6. Se requiere hacer un cambio de interfaz dentro de la aplicación.
(M, H)
7. Se desea que todas las transacciones sean capaces de trabajar en
otro canal de comunicación. (H, L)
Integridad de los
Datos
Ajuste a los
propóstios
Portabilidad
(5)
1. Se requiere que el sistema maneje un alto volumen de
transacciones. (H, L)
2. Se requiere hacer mantenimiento al Journal dentro de la BD local
para liberar espacio y mejorar los tiempos de respuesta. (M, M)
3. Se solicita autorización remota a un funcionario válido que no se
encuentra en su puesto de trabajo. (H, H)
4. Se realiza una transacción y se requiere conocer el estatus. (M, H)
Tolerancia a
Fallas
Disponibilidad
17. Se desea que todos los requerimientos de funcionalidad que
presenta la aplicación, se encuentren cubiertos. (H, M)
18. Se desea hacer la instalación de una nueva versión en todas las
agencias.(M, M)
19. Ocurre una falla en el refrescamiento de una de las máquinas
de una agencia. (H, L)
20. Se desea que la aplicación se ejecute en otro sistema de
operación. ( M, H)
21. Se desea que la aplicación se adapte a otro manejador de BD.
(M, M)
22. El Software intenta acceder a dispositivos I/O que no se
encuentran conectados. (L, H)
23. Ocurre una falla durante la ejecución de una transacción. (M, M)
24. Ocurre una falla en la aplicación (H, M)
25. Se desea que la aplicación permita hacer backups en diferentes
dispositivos, indicando donde va a ser almacenado. (H, L)
26. Ocurre una falla en el canal principal de comunicación.(M, L)
27. El servidor principal sufre una falla crítica de Sw. (Offline) (M, H)
Figura 1.1 Utility Tree de Visual Banker [Elaboración propia]
149
Evaluación Arquitectónica de Visual Banker
Utility Tree y ABAS
Escenario #: 1
Versión: 1.0
Fecha: 05/06/06
Escenario: se requiere que el sistema maneje un alto volumen de transacciones.
Atributo(s): eficiencia (cantidad de transacciones).
Ambiente: operación normal.
Estimulo: alto volumen de transacciones.
Fuente del Estímulo: interna al sistema.
Respuesta: el sistema funciona sin degradar su rendimiento.
Artefacto Estimulado: Sistema.
Medida de la Respuesta: presencia de un componente que permita mantener el desempeño de la
aplicación independientemente de la cantidad de transacciones que ésta tenga que manejar.
Decisión Arquitectónica
Sensibilidad
D1
S1
D2
Explicación
Tradeoff
Riesgo
No Riesgo
NR1
T1
R1, R2
D1(A) Dispatcher capaz de manejar múltiples transacciones y protocolos
de comunicación. (Permite manejar del lado del servidor transacciones
simultáneas sin degradar el rendimiento).
D2(A) Línea activa en las agencias. (Permite que las agencias se
encuentren en todo momento procesando transacciones).
S1 Tamaño de la trama en el protocolo de comunicación es muy pequeño.
T1 En caso de que la línea falle afecta la disponibilidad de la aplicación.
R1 No es posible enviar tanta cantidad de datos por el tamaño reducido
de la trama.
R2 En caso de que la línea falle no es posible procesar ninguna
transacción. (Las agencias no pueden trabajar sin línea pues es imposible
ejecutar alguna transacción sin la misma).
NR1 Ofrece robustez a la aplicación y mayor aprovechamiento del ancho
de banda (por múltiples transacciones).
Diagrama
Escenario #: 2
Escenario: se requiere hacer mantenimiento al Journal dentro de la BD local para
liberar espacio y mejorar los tiempos de respuesta.
Atributo(s): eficiencia (tiempo de respuesta).
Ambiente: operación normal.
150
Evaluación Arquitectónica de Visual Banker
Utility Tree y ABAS
Versión: 1.0
Fecha: 05/06/06
Estimulo: se llena el Journal dentro de la BD local.
Fuente del Estímulo: interna al sistema.
Respuesta: se hace mantenimiento del Journal liberando espacio para registrar nuevas transacciones.
Artefacto Estimulado: Sistema (BD local).
Medida de la Respuesta: existencia de un componente que realice el mantenimiento del Journal de
forma automática para liberar espacio.
Decisión Arquitectónica
Sensibilidad
Tradeoff
Riesgo
D1
S1
T1
R1
D2
No Riesgo
NR1, NR2
D3
T2
NR1, NR2
D1(A) Script de mantenimiento que se corre todos los días.
Explicación
D2(P) Alertas inteligentes (que avisen cuando el tamaño de la BD se
encuentra cerca de un estado crítico y así realizar el mantenimiento).
D3(P) Procesos de monitoreo por parte de la aplicación. (la aplicación se
encarga de realizar un monitoreo constante del estado de la BD).
S1 Es posible que el Script de mantenimiento no se coloque físicamente
donde debe estar.
T1 Si el Script
no se ejecuta correctamente, afecta a la Fiabilidad
específicamente en el punto de tolerancia a fallas.
T2 El proceso de monitoreo continuo por parte de la aplicación puede
afectar la Eficiencia de la misma.
R1 No se tiene conocimiento sobre la ejecución correcta o incorrecta del
Script.
NR1 Mantiene informado al usuario y no se espera a que la BD colapse.
NR2 Se tiene garantía del mantenimiento.
Diagrama
Escenario #: 3
Escenario: se solicita autorización remota a un funcionario válido que no se
encuentra en su puesto de trabajo.
Atributo(s): eficiencia (tiempo de respuesta).
Ambiente: operación normal.
151
Evaluación Arquitectónica de Visual Banker
Utility Tree y ABAS
Versión: 1.0
Fecha: 05/06/06
Estimulo: solicitud de autorización remota a usuario válido que no está presente.
Fuente del Estímulo: interna al sistema.
Respuesta: no se recibe respuesta por parte del nodo y se espera que ocurra el Time-Out para poder
solicitar una nueva autorización.
Artefacto Estimulado: Sistema.
Medida de la Respuesta: presencia de un componente arquitectónico que realice monitoreo, produzca
el Time-Out y permita hacer una nueva solicitud o redireccionar la que ya fue enviada.
Decisión Arquitectónica
Sensibilidad
Tradeoff
D1
Riesgo
No Riesgo
R1
D2
NR1, NR2
D1(A) Objeto de envío de autorización remota (Objeto particular de
Explicación
Visual Banker que permite hacer el envío de la autorización remota).
D2(P) Objeto de interrupción de autorización remota. Creación de un
objeto que permita interrumpir la autorización remota si no se recibe
respuesta en un tiempo determinado y que la misma se redireccione a
otro funcionario.
R1 Es necesario esperar el Time-Out para poder hacer una nueva
solicitud y no se redirecciona automáticamente.
NR1 Una vez que ocurre la interrupción el sistema sigue funcionando
(sin degradar su rendimiento).
NR2 Se redirecciona automáticamente la solicitud a otro funcionario de
grado superior; es decir, no hay que enviarla nuevamente.
Diagrama
Escenario #: 4
Escenario: se realiza una transacción y se requiere conocer el estatus.
Atributo(s): eficiencia (tiempo de respuesta).
Ambiente: operación normal.
Estimulo: ejecución de una transacción.
Fuente del Estímulo: interna al sistema.
Respuesta: se indica con un mensaje que la transacción ya comenzó con su ejecución.
Artefacto Estimulado: Sistema.
152
Evaluación Arquitectónica de Visual Banker
Utility Tree y ABAS
Versión: 1.0
Fecha: 05/06/06
Medida de la Respuesta: existencia de un mecanismo que indique que la transacción ya comenzó a
ejecutarse.
Decisión Arquitectónica
Sensibilidad
Tradeoff
D1
Riesgo
T1
No Riesgo
NR1, NR2
D1(P) Clase genérica de Visual Banker que pueda ser invocada desde
Explicación
diferentes puntos de la aplicación y que se encargue de mostrar los
mensajes de aviso y confirmación.
T1 Se puede ver afectada la fiabilidad específicamente en la
subcaracterística de madurez pues si la clase principal se ve afectada y
falla, todas las clases que hagan uso de la misma van a fallar.
NR1 Al ser una clase genérica puede ser invocada desde cualquier parte
de la aplicación sin necesidad de repetir código.
NR2 Evita que el usuario envíe transacciones duplicadas por ausencia
de la respuesta.
Actualmente no existe ninguna decisión tomada que pueda verse
Diagrama
reflejada en la arquitectura.
Escenario #: 5
Escenario: se agrega una nueva funcionalidad a la aplicación.
Atributo(s): mantenibilidad (facilidad de cambio).
Ambiente: durante un mantenimiento correctivo.
Estimulo: agregar nueva funcionalidad.
Fuente del Estímulo: interna al sistema.
Respuesta: toma un tiempo considerable realizar el cambio en la aplicación.
Artefacto Estimulado: Arquitectura.
Medida de la Respuesta: complejidad de los componentes y de la relación entre los mismos,
existencia de componentes acoplados, cohesivos y grado de modularidad de la arquitectura.
Decisión Arquitectónica
Sensibilidad
Tradeoff
D1
D2
Explicación
Riesgo
No Riesgo
R1, R2
S1
T1
NR1
D1(A) La aplicación se presenta en una sola capa, como un cuerpo
monolítico.
D2(P) Separación de la aplicación en capas, lo que permite trabajar
únicamente con la parte necesaria sin afectar al resto.
S1 Puede que la comunicación entre las diferentes capas que se
establezcan sea muy difícil o complicada.
153
Evaluación Arquitectónica de Visual Banker
Utility Tree y ABAS
Versión: 1.0
Fecha: 05/06/06
T1 El atributo relacionado con fiabilidad (madurez) puede verse afectado,
pues al realizar la separación en capas la aplicación es más propensa a
fallas.
R1 Al momento de realizar las pruebas de la aplicación, es necesario
probar todo; es decir, no es posible trabajar en forma modular.
R2 Independientemente del tamaño de la parte que fue modificada o
evolucionada, es necesario construir un ejecutable completo.
NR1 Solo es necesario compilar la parte nueva que fue modificada, ya que
el resto del ejecutable no se ve afectado. Mucho menos tiempo para llevar
a producción.
Diagrama
Escenario #: 6
Escenario: se requiere hacer un cambio de interfaz dentro de la aplicación
Atributo(s): mantenibilidad (facilidad de cambio).
Ambiente: durante un mantenimiento correctivo.
Estimulo: cambio en alguna de las interfaces de la aplicación.
Fuente del Estímulo: interna al sistema.
Respuesta: bajo impacto en los tiempos de desarrollo y distribución.
Artefacto Estimulado: Arquitectura
Medida de la Respuesta: grado de desacoplamiento de la interfaz con el resto de la lógica de la
aplicación.
Decisión Arquitectónica
Sensibilidad
Tradeoff
D1
D2
Explicación
Riesgo
No Riesgo
R1
S1
T1
NR1, NR2
D1(A) Clases de tipo Views y Formas reusables, que se encuentran
acopladas con el resto de la aplicación, en forma monolítica.
D2(P) Separación de las capas lógica y de comunicación, de la capa de
presentación. Se trabajaría con archivos “.dll” que ya se encuentran
precompilados.
S1 Puede que la comunicación entre las capas establecidas sea muy
complicada.
154
Evaluación Arquitectónica de Visual Banker
Utility Tree y ABAS
Versión: 1.0
Fecha: 05/06/06
T1 La subcaracterística de madurez puede verse afectada ya que la
aplicación es más propensa a fallas.
R1 Se encuentra todo compacto y un cambio en cualquiera de los
elementos afecta en gran medida al resto.
NR1 Una modificación en la capa de presentación afecta en lo más
mínimo al resto de las capas de la aplicación.
NR2 Se mejora la portabilidad del sistema, haciéndolo más adaptable a
los posibles cambios.
Diagrama
Escenario #: 7
Escenario: ocurre una contingencia y se desea que todas las transacciones sean
capaces de trabajar en otro canal de comunicación.
Atributo(s): mantenibilidad (facilidad de cambio).
Ambiente: durante un mantenimiento correctivo.
Estimulo: el canal de comunicación principal deja de funcionar.
Fuente del Estímulo: externa al sistema.
Respuesta: todas las transacciones de la aplicación comienzan a funcionar a través de otro canal de
comunicación y empiezan a enviar los datos por ese medio.
Artefacto Estimulado: Arquitectura.
Medida de la Respuesta: existencia de un componente que indique que transacciones pueden trabajar
a través del canal de contingencia, además de monitorear el canal de comunicación y redireccionar a
las transacciones en caso de falla.
Decisión Arquitectónica
Sensibilidad
Tradeoff
Riesgo
No Riesgo
D1
S1
T1
R1
NR1, NR2
D2
Explicación
NR3
D1(A) Archivo plano que contiene las transacciones que pueden trabajar
bajo TCP/IP en caso de contingencia.
D2(P) Switch automático por parte de las transacciones para que
comiencen a trabajar por TCP/IP. Ellas al detectar una falla en el canal
de comunicación comienzan a enviar los datos por el canal de
contingencia, siempre y cuando los puertos se encuentren liberados.
S1 En caso de que surjan un gran número de nuevas transacciones y se
155
Evaluación Arquitectónica de Visual Banker
Utility Tree y ABAS
Versión: 1.0
Fecha: 05/06/06
tengan que incluir todas, el archivo puede crecer considerablemente.
T1 Se puede ver afectado el atributo de eficiencia en cuanto al manejo
de recursos, pues la aplicación puede trabajar más lento si tiene que leer
todo el archivo de configuración y este es muy grande.
R1 El archivo de configuración puede sufrir modificaciones o
corromperse lo que no permitiría que las transacciones trabajen
correctamente en caso de contingencia.
NR1 Es fácil de filtrar el tipo de transacciones que pueden o no pueden
trabajar en otro canal de comunicación.
NR2 Actualmente el archivo es fácil de distribuir entre todas las
estaciones de trabajo por su tamaño reducido.
NR3 El cambio se hace automático por parte de las transacciones sin la
necesidad de leer un archivo que puede estar corrupto o mal
configurado.
Diagrama
Escenario #: 8
Escenario: se intenta realizar un acceso no autorizado dentro de la aplicación.
Atributo(s): funcionalidad (seguridad de los datos).
Ambiente: operación normal.
Estimulo: un usuario no autorizado intenta acceder a la aplicación.
Fuente del Estímulo: interna al sistema.
Respuesta: se establecen controles de acceso mucho más fuertes como consecuencia de los intentos
de acceso no autorizado.
Artefacto Estimulado: Sistema.
Medida de la Respuesta: presencia de un componente que realice el control de acceso y que solo
permita el mismo a usuarios válidos registrados dentro de la aplicación. Debe llevar un registro de todos
los intentos fallidos de conexión y de posibles modificaciones dentro de la BD.
Decisión Arquitectónica
Sensibilidad
Tradeoff
D1
D2
Explicación
156
Riesgo
No Riesgo
R1
T1
NR1
D1(A) Mecanismo de validación de usuario y password contra la BD local
Evaluación Arquitectónica de Visual Banker
Utility Tree y ABAS
Versión: 1.0
Fecha: 05/06/06
contenida en el servidor de cada agencia.
D2(P) Validación de usuario y password contra la BD local pero teniendo
un archivo de log que permita registrar las modificaciones realizadas en
la BD (creación de nuevos usuarios, cambio de passwords), así como el
usuario que las realizó. Se deben registrar los intentos fallidos de
conexión por usuarios o contraseñas no válidas.
T1 La eficiencia puede verse afectada, pues la decisión planteada
implica un mayor uso de recursos por parte de la aplicación para poder
mantener y guardar el archivo de Log.
R1 No queda registro de intentos fallidos a la BD, ni de los cambios
realizados dentro de la misma por algún usuario.
NR1 Se tiene registro de todos los accesos (fallidos o no) a la BD, así
como las modificaciones realizadas a la misma.
Diagrama
Escenario #: 9
Escenario: una persona accede al módulo de Mantenimiento como usuario
genérico.
Atributo(s): funcionalidad (seguridad de los datos).
Ambiente: durante el mantenimiento.
Estimulo: usuario no autorizado accede al módulo de Mantenimiento como usuario genérico.
Fuente del Estímulo: interna al sistema.
Respuesta: se cuenta con un mecanismo confiable que controla el acceso al módulo de Mantenimiento
Artefacto Estimulado: Sistema.
Medida de la Respuesta: existencia de un mecanismo de validación que verifique cada uno de los
usuarios que accedan a la BD local y que no permita el acceso a través del usuario genérico. Que el
sistema permita la creación de usuarios con privilegios para acceder al módulo de mantenimiento,
deshabilitando el usuario genérico.
Decisión Arquitectónica
D1
Sensibilidad
Tradeoff
Riesgo
No Riesgo
R1
D2
NR1
D3
NR1
157
Evaluación Arquitectónica de Visual Banker
Utility Tree y ABAS
Versión: 1.0
Fecha: 05/06/06
D1(A) Mecanismo de validación del usuario genérico contra la BD local.
Explicación
D2(P) Se elimina el usuario genérico como mecanismo de acceso al
módulo de mantenimiento, manteniéndose únicamente como medida de
contingencia que se activa en caso de que todos los usuarios de la
agencia se queden bloqueados. La creación del mismo se realizaría
remotamente y en forma centralizada a través de un Script. Tan pronto el
servidor sea reiniciado el usuario se elimina automáticamente.
D3(P) Eliminación total del usuario genérico, el acceso se hace por
usuarios válidos que posean ciertos perfiles. En caso de que todos los
usuarios permanezcan bloqueados los mismos se activan remotamente.
R1 Cualquier usuario no autorizado puede tener acceso si conoce el
usuario genérico.
NR1 No se tiene un usuario genérico conocido por cualquier persona,
permite que el control de acceso sea mucho más robusto.
Diagrama
Escenario #: 10
Escenario: se desea tener un archivo de log que permita registrar todas las
operaciones realizadas por los usuarios en la BD.
Atributo(s): funcionalidad (seguridad de los datos).
Ambiente: operación normal.
Estimulo: se realiza una operación a través de la aplicación.
Fuente del Estímulo: interna al sistema.
Respuesta: se ejecuta la operación dentro de la aplicación y se registra en el archivo de log los datos
de las transacciones involucradas, las transacciones propiamente dichas, el usuario que las realizó, así
como otros datos relevantes de fecha y hora, número de intentos, etc.
Artefacto Estimulado: Sistema.
Medida de la Respuesta: existencia de un componente arquitectónico que permita manejar el archivo y
registrar los datos en el mismo.
Decisión Arquitectónica
158
Sensibilidad
Tradeoff
Riesgo
D1
T1
R1, R2
D2
T1
R1
No Riesgo
NR1
Evaluación Arquitectónica de Visual Banker
Utility Tree y ABAS
Versión: 1.0
Fecha: 05/06/06
D1(A) Tabla en la BD que registra todas las transacciones fallidas y no
Explicación
fallidas realizadas en la BD (inserts en la tabla de Journal).
D2(P) Inserts en la tabla de Journal pero agregando otros campos al
registro como: IP de la máquina que envió la transacción, indicador sobre
si la transacción fue local o remota, etc.
T1 La eficiencia puede verse afectada si la tabla de Journal dentro de la
BD crece considerablemente. Relacionado con el uso de recursos.
R1 El archivo resultante es difícil de recorrer y revisar por la cantidad de
información que posee y la forma como es guardada.
R2 Existen datos importantes de las transacciones que no están siendo
almacenados como por ejemplo el IP de la máquina de donde salió.
NR1 Se tiene mayor información sobre las transacciones para el
momento en el cual se realice la auditoria.
Diagrama
Escenario #: 11
Escenario: se requiere que los cambios en los passwords de los usuarios se
realicen constantemente y que su deducción sea difícil.
Atributo(s): funcionalidad (seguridad de los datos).
Ambiente: operación normal.
Estimulo: se intenta deducir la clave de uno de los usuarios de la aplicación.
Fuente del Estímulo: externa al sistema.
Respuesta: se establecen mecanismos dentro de la aplicación que obliguen a los usuarios a
especificar claves mucho más robustas (con un mínimo de caracteres y con combinación de números y
letras) y que las mismas sean cambiadas constantemente.
Artefacto Estimulado: Sistema.
Medida de la Respuesta: presencia de un mecanismo que garantice la creación de claves robustas y
que registre los datos de la creación para indicar a los usuarios cuando debe producirse el cambio de
clave. Debe recordar las últimas claves suministradas para evitar repeticiones.
Decisión Arquitectónica
D1
D2
Explicación
Sensibilidad
Tradeoff
Riesgo
No Riesgo
R1, R2
NR1, NR2
D1(A) Método de verificación y validación de usuarios y contraseñas
159
Evaluación Arquitectónica de Visual Banker
Utility Tree y ABAS
Versión: 1.0
Fecha: 05/06/06
contra los registros guardados en la BD local de cada agencia.
D2(P) Método de verificación contra la BD local, además de método que
garantice la creación de claves robustas al exigir un número mínimo de
caracteres, combinación de letras y números. Método que registre fecha
de creación de las claves para hacer validaciones de vencimiento y
necesidad de cambio de las mismas.
R1 No garantiza el cambio constante de las claves de los usuarios por lo
que pueden durar con las mismas un tiempo considerable e incluso
nunca cambiarlas.
R2 El método no garantiza la creación de claves robustas por lo q las
mismas pueden ser deducidas con gran facilidad.
NR1 Se garantiza el cambio constante de las claves al realizar avisos de
vencimiento en un período de tiempo determinado.
NR2 Se garantiza la creación de claves robustas.
Diagrama
Escenario #: 12
Escenario: se requiere que la data viaje encriptada.
Atributo(s): funcionalidad (seguridad de los datos).
Ambiente: operación normal.
Estimulo: se envían datos e información de las transacciones a través del canal de comunicación y los
mismos son interceptados.
Fuente del Estímulo: interna al sistema.
Respuesta: se establecen algoritmos de encripción que permiten que la data viaje encriptada y que en
caso de ser interceptada no pueda ser empleada por usuarios no autorizados.
Artefacto Estimulado: Sistema.
Medida de la Respuesta: existencia de un componente arquitectónico encargado de encriptar los
datos antes de que los mismos viajen por la red y desencriptarlos en su lugar de destino; verificando la
inegridad de la data transmitida.
Decisión Arquitectónica
D1
Explicación
160
Sensibilidad
Tradeoff
T1
Riesgo
No Riesgo
NR1
D1(A) Método encargado de encriptar la data antes de ser enviada y
Evaluación Arquitectónica de Visual Banker
Utility Tree y ABAS
Versión: 1.0
Fecha: 05/06/06
desencriptarla al llegar al lugar de origen (todo el proceso bajo un
algoritmo de encriptamiento).
T1 La eficiencia puede verse afectada ya que se consume una cantidad
considerable de tiempo al encriptar y desencriptar los datos.
NR1 los datos viajan seguros y en caso de ser interceptados no pueden
ser utilizados por personas no autorizadas.
Diagrama
Escenario #: 13
Escenario: se consulta una firma digitalizada.
Atributo(s): funcionalidad (seguridad de los datos).
Ambiente: operación normal.
Estimulo: consulta de la firma de un cliente.
Fuente del Estímulo: interna al sistema.
Respuesta: el sistema revisa si la firma se encuentra localmente (porque fue usada recientemente) y
sino se encuentra la busca en el AS400. en caso de que se encuentre localmente revisa cuanto tiempo
lleva almacenada y en caso de que sea muy vieja la busca en el servidor.
Artefacto Estimulado: Sistema.
Medida de la Respuesta: presencia de un componente que permita manejar las firmas, buscarlas local
o remotamente y mostrarlas cuando sea necesario.
Decisión Arquitectónica
Sensibilidad
D1
Explicación
Tradeoff
Riesgo
T1
R1, R2, R3
No Riesgo
D2
R2
NR1, NR2
D3
R2
NR2
D1(A) Llamada a un archivo ejecutable independiente de VB y externo a
la aplicación.
D2(P) Llamada a un ejecutable pero teniendo el código dentro de Visual
Banker. (No tener un ejecutable externo).
D3(P) Llamada a un ejecutable externo pero solicitando un parámetro
más de Usuario y Password válido registrado dentro de Visual Banker.
Manteniendo una traza de todas las operaciones aún cuando se ejecute
fuera de la aplicación.
T1 Puede verse afectada la seguridad al ser manipulado el ejecutable
161
Evaluación Arquitectónica de Visual Banker
Utility Tree y ABAS
Versión: 1.0
Fecha: 05/06/06
desde afuera de la aplicación para revisar información confidencial, ya
que no se pide ningún tipo de autenticación.
R1 Es posible tener acceso al ejecutable sin tener que pasar por la
aplicación.
R2 No se tiene el código fuente del ejecutable ya que es de un
propietario,
cualquier
modificación
requerida
implica
tener
que
contactarlos.
R3 Si se ejecuta el archivo desde afuera de VB no queda traza de las
operaciones realizadas a través del mismo.
NR1 Es obligatorio autenticarse a través de Visual Banker para poder
realizar la consulta de firmas. (Pasar por la aplicación).
NR2 Se obtiene traza de todas las operaciones realizadas a través del
código de consulta de firmas.
Diagrama
Escenario #: 14
Escenario: ocurre el mecanismo de RollBack dentro de la BD.
Atributo(s): funcionalidad (integridad de los datos).
Ambiente: operación normal.
Estimulo: ocurre el mecanismo de RollBack dentro de la BD local.
Fuente del Estímulo: interna al sistema.
Respuesta: se reversan las transacciones que fueron ejecutadas y se verifica la última transacción
realizada en taquilla para garantizar la consistencia e integridad de los datos contenidos en la BD.
Artefacto Estimulado: Sistema.
Medida de la Respuesta: existencia de un componente arquitectónico que ejecute el mecanismo de
Rollback garantizando la integridad y consistencia de los datos.
Decisión Arquitectónica
Sensibilidad
Tradeoff
D1
Explicación
Riesgo
No Riesgo
NR1
D1(A) Dispatcher encargado de hacer el mecanismo de RollBack.
NR1 Garantiza la consistencia e integridad de los datos una vez
ejecutado el procedimiento de RollBack.
162
Evaluación Arquitectónica de Visual Banker
Utility Tree y ABAS
Versión: 1.0
Fecha: 05/06/06
Diagrama
Escenario #: 15
Escenario: ocurre una modificación en la firma de un cliente.
Atributo(s): funcionalidad (integridad de los datos).
Ambiente: operación normal.
Estimulo: la firma de un cliente es modificada después de ser capturada.
Fuente del Estímulo: interna al sistema.
Respuesta: el sistema produce notificaciones o alertas sobre los cambios realizados.
Artefacto Estimulado: Sistema.
Medida de la Respuesta: existencia o no de un componente arquitectónico que registre e indique
cuándo alguno de los datos ha sido modificado, así como el usuario que realizó dichos cambios.
Decisión Arquitectónica
Sensibilidad
Tradeoff
Riesgo
D1
No Riesgo
NR1
D1(P) Registro de consulta y modificación de firma para auditoria. Si se
Explicación
desea modificar la firma es necesario presionar un botón a través del
cual va a ser posible registrar la modificación; es decir, la aplicación no
permite que la firma se edite directamente, a menos que se presione el
botón correspondiente. Una vez enviada la solicitud, para poder
procesarla es necesario indicar el usuario y clave de un supervisor.
NR1 Queda un registro de todas las consultas y posibles modificaciones
realizadas a las firmas de los clientes.
Actualmente no existe ninguna decisión tomada que pueda verse
Diagrama
reflejada en la arquitectura.
Escenario #: 16
Escenario: se desea que los servidores locales se encuentren replicados en el
servidor principal para evitar pérdida de información en caso de fallas.
Atributo(s): funcionalidad (seguridad física).
Ambiente: operación normal.
Estimulo: ocurre una falla en uno de los servidores como consecuencia de un daño en el equipo.
Fuente del Estímulo: externa al sistema.
163
Evaluación Arquitectónica de Visual Banker
Utility Tree y ABAS
Versión: 1.0
Fecha: 05/06/06
Respuesta: el sistema realiza una copia de la BD local y la envía al AS400 para evitar la pérdida de
información.
Artefacto Estimulado: Sistema.
Medida de la Respuesta: presencia de un componente arquitectónico que permita hacer la replicación
de las bases de datos locales en la base de datos principal.
Decisión Arquitectónica
Sensibilidad
Tradeoff
D1
S1
T1
Riesgo
No Riesgo
D1(A) Mecanismo que permita copiar diariamente todo lo que se
Explicación
encuentra en la base de datos local de cada agencia, en el AS400.
S1 Puede ser mucho más costoso guardar toda esa información en el
servidor principal, que perderla.
T1 la eficiencia puede verse afecta, específicamente en el punto
relacionado con el uso de los recursos ya que se requiere mayor espacio
en disco para realizar las réplicas.
Diagrama
Escenario #: 17
Escenario: se desea que todos los requerimientos de funcionalidad que presenta
la aplicación, se encuentren cubiertos.
Atributo(s): funcionalidad (ajuste a los propósitos).
Ambiente: operación normal.
Estimulo: se agrega una nueva funcionalidad a la aplicación.
Fuente del Estímulo: interna al sistema.
Respuesta: todos los requerimientos contenidos en el documento ERS tienen una correspondencia
dentro de la aplicación.
Artefacto Estimulado: Sistema.
Medida de la Respuesta: existencia de un componente que permita el cumplimiento de todos los
requerimientos funcionales.
Decisión Arquitectónica
D1
164
Sensibilidad
Tradeoff
Riesgo
No Riesgo
NR1
Evaluación Arquitectónica de Visual Banker
Utility Tree y ABAS
Versión: 1.0
Fecha: 05/06/06
D1(P) Implementación de los requerimientos funcionales presentes en el
Explicación
documento ERS que todavía no han sido desarrollados.
NR1 La aplicación tendría nuevas funcionalidades que prestar a los
usuarios y clientes.
Actualmente no existe ninguna decisión tomada que pueda verse
Diagrama
reflejada en la arquitectura.
Escenario #: 18
Escenario: se desea hacer la instalación de una nueva versión en todas las
agencias.
Atributo(s): portabilidad
Ambiente: durante reemplazo.
Estimulo: se instala una nueva versión de la aplicación en las agencias.
Fuente del Estímulo: externa al sistema.
Respuesta: se logra en total de las actualizaciones e un plazo menor de 48 horas.
Artefacto Estimulado: Sistema.
Medida de la Respuesta: existencia de un componente arquitectónico que permita realizar la
distribución e implantación de la nueva versión en las agencias de una manera rápida y sencilla.
Decisión Arquitectónica
Sensibilidad
Tradeoff
D1
S1, S2
T1
D2
Explicación
Riesgo
No Riesgo
NR1
R1
NR2
D1(A) Paquete de IBM Tivoli que permite hacer la distribución remota del
ejecutable al servidor de cada una de las agencias. Al reiniciar cada
estación de trabajo se realiza el refrescamiento local actualizando cada
versión.
D2(P) Tener servidores regionales (no uno por agencia) a los cuales
distribuir la nueva versión. Cada estación de trabajo copiaría
directamente desde el servidor que le corresponde (según su ubicación
física). Se eliminarían los servidores locales.
S1 El aumento considerable de servidores a los cuales hay que distribuir
la versión (por un alto crecimiento en el número de agencias) hace que
cada vez se requiera mayor ancho de banda para hacer la distribución.
S2 El envío a través de Tivoli sólo se puede realizar de forma secuencial
(uno a uno).
T1 La eficiencia puede verse afectada, específicamente en el punto
relacionado con tiempo de respuesta, pues la transmisión puede ser muy
165
Evaluación Arquitectónica de Visual Banker
Utility Tree y ABAS
Versión: 1.0
Fecha: 05/06/06
lenta.
R1 En caso de una falla en el envío a un servidor regional el número de
agencias que se ven perjudicadas es mucho mayor.
NR1 En caso de que ocurra una falla en el envío, solo se ve afectada la
agencia en la cual se produjo la misma.
NR2 El número de servidores a los cuales hay que distribuir la nueva
versión es mucho más pequeño.
Diagrama
Escenario #: 19
Escenario: ocurre una falla en el refrescamiento de una máquina en una agencia.
Atributo(s): portabilidad
Ambiente: operación normal.
Estimulo: la nueva versión de la aplicación no se refresca correctamente en una de las máquinas de
una agencia.
Fuente del Estímulo: interna al sistema.
Respuesta: el sistema sigue funcionando normalmente pero sin presentar las opciones agregadas a la
nueva versión instalada.
Artefacto Estimulado: Sistema.
Medida de la Respuesta: existencia de un mecanismo que permita el refrescamiento manual o
automático de cada una de las estaciones de trabajo para evitar versiones obsoletas.
Decisión Arquitectónica
Sensibilidad
D1
Tradeoff
Riesgo
R1, R2
D2
NR1
D3
Explicación
No Riesgo
R2
D1(A) Script de actualización de versiones encargado de copiar la nueva
versión existente de la aplicación en cada una de las estaciones de
trabajo.
D2(P) Script de actualización que además genere un archivo de log en el
que se indique la fecha/hora y máquinas en las cuales se llevó a cabo el
166
Evaluación Arquitectónica de Visual Banker
Utility Tree y ABAS
Versión: 1.0
Fecha: 05/06/06
refrescamiento, así como los archivos actualizados en cada una.
D3(P) Script de actualización además de un botón que permita al usuario
verificar la fecha y tamaño del Build instalado en su máquina para saber si se
produjo o no la actualización.
R1 No se tiene garantía ni conocimiento si el Script se ejecutó
correctamente.
R2 No se tiene registro de las máquinas actualizadas ni de los archivos
actualizados en cada uno de los casos.
NR1 Se tiene información puntual sobre las máquinas actualizadas
correctamente en cada una de las agencias.
Diagrama
Escenario #: 20
Escenario: se desea que la aplicación se ejecute en otro sistema de operación.
Atributo(s): portabilidad
Ambiente: durante mantenimiento adaptativo.
Estimulo: la aplicación se migra a otro sistema de operación.
Fuente del Estímulo: interna al sistema.
Respuesta: el sistema sigue prestando los servicios sin degradar su rendimiento.
Artefacto Estimulado: Sistema.
Medida de la Respuesta: existencia de una capa de portabilidad que contenga todos los parámetros
dependientes del Sistema de Operación.
Decisión Arquitectónica
Sensibilidad
Tradeoff
D1
Explicación
Riesgo
T1
No Riesgo
NR1, NR2
D1(P) Encapsulamiento de los componentes que son dependientes del
Sistema de Operación.
T1 Se podría ver afectada la madurez dentro de la aplicación.
NR1 Mayor compatibilidad con dispositivos actuales.
NR2 Mayor interacción con otras aplicaciones.
Diagrama
Actualmente no existe ninguna decisión tomada que pueda verse
reflejada en la arquitectura.
167
Evaluación Arquitectónica de Visual Banker
Utility Tree y ABAS
Escenario #: 21
Versión: 1.0
Fecha: 05/06/06
Escenario: se desea que la aplicación se adapte a otro manejador de BD.
Atributo(s): portabilidad
Ambiente: durante mantenimiento adaptativo.
Estimulo: la aplicación trabaja con un nuevo manejador de base de datos.
Fuente del Estímulo: interna al sistema.
Respuesta: el sistema sigue prestando los servicios sin degradar su rendimiento.
Artefacto Estimulado: Sistema.
Medida de la Respuesta: lógica de la aplicación en una capa individual, cantidad de elementos
dependientes del manejador de BD que se esté usando.
Decisión Arquitectónica
Sensibilidad
Tradeoff
Riesgo
D1
No Riesgo
NR1
D1(P)
Explicación
Encapsulamiento
de
los
componentes
dependientes
del
manteador de BD.
NR1 Mayor compatibilidad con otros dispositivos y aplicaciones.
Actualmente no existe ninguna decisión tomada que pueda verse
Diagrama
reflejada en la arquitectura.
Escenario #: 22
Escenario: el Software intenta acceder a dispositivos I/O que no se encuentran
conectados.
Atributo(s): fiabilidad.
Ambiente: operación normal.
Estimulo: acceso a dispositivos I/O que no se encuentran conectados.
Fuente del Estímulo: interna al sistema.
Respuesta: el sistema no responde a la solicitud de acceso al dispositivo, presentando un error.
Artefacto Estimulado: Sistema.
Medida de la Respuesta: presencia de un componente que monitoree a los dispositivos I/O, envíe
mensajes en caso de error en el intento de conexión, y que permita que la aplicación siga funcionando.
Decisión Arquitectónica
Sensibilidad
D1
Tradeoff
Riesgo
No Riesgo
R1
D2
Explicación
D1(A) Clase de Visual Banker encargada de manejar los mensajes de
error que se producen en los intentos fallidos de conexión a un
dispositivo.
D2(P) Mantener la clase que maneja las excepciones, pero además
168
Evaluación Arquitectónica de Visual Banker
Utility Tree y ABAS
Versión: 1.0
Fecha: 05/06/06
permitir que el sistema reconozca el dispositivo al cual se encuentra
conectado. En caso de algún error en la conexión él reconoce
automáticamente otro dispositivo conectándose al mismo para enviar
nuevamente la solicitud de impresión.
R1 No se tiene la opción de almacenar temporalmente el archivo que se
desea imprimir, en caso de fallo en la conexión se pierde el archivo.
Diagrama
Escenario #: 23
Escenario: ocurre una falla durante la ejecución de una transacción
Atributo(s): fiabilidad.
Ambiente: operación normal.
Estimulo: ocurre una falla en la ejecución de una transacción.
Fuente del Estímulo: interna al sistema.
Respuesta: el sistema recupera la transacción que se estaba ejecutando.
Artefacto Estimulado: Sistema.
Medida de la Respuesta: existencia de un componente arquitectónico que permita recuperar las
transacciones en caso de fallas garantizando la integridad y consistencia de los datos.
Decisión Arquitectónica
Sensibilidad
D1
Explicación
Tradeoff
Riesgo
No Riesgo
R1
D2
NR1, NR2
D3
NR1, NR2
D1(A) Dispatcher encargado de hacer RollBack.
D2(P) Dispatcher encargado de hacer RollBack, enviando transacciones
por lotes en donde solo se consideren en primera instancia aquellas que
se pueden reversar, si ese grupo pasa exitosamente, se envían el resto
de transacciones.
D3(P) Dispatcher encargado de hacer RollBack, enviando todas las
transacciones juntas pero revisando el orden en el que el Disptacher
acepta dichas transacciones. Aquellas que no tienen reverso se ejecutan
169
Evaluación Arquitectónica de Visual Banker
Utility Tree y ABAS
Versión: 1.0
Fecha: 05/06/06
al final, si alguna de las anteriores falla, esas no llegan a ejecutarse.
R1 Es posible que la data quede inconsistente como consecuencia de
las transacciones que no se pueden reversar. No hay atomocidad.
NR1 Se garantiza atomicidad gracias al mecanismo de RollBack, o se
ejecutan todas las transacciones o no se ejecuta ninguna.
NR2 Se garantiza que las transacciones que no tienen reverso se van a
ejecutar únicamente si el resto de transacciones no falla, por lo que no
va a haber inconsistencia.
Diagrama
Escenario #: 24
Escenario: ocurre una falla en la aplicación.
Atributo(s): fiabilidad.
Ambiente: operación normal.
Estimulo: ocurre una falla en la aplicación.
Fuente del Estímulo: interna al sistema.
Respuesta: el sistema notifica al usuario y continua funcionando pero en modo degradado.
Artefacto Estimulado: Sistema.
Medida de la Respuesta: presencia de un componente que permita manejar la falla, enviar mensajes
de los errores producidos y continuar con el funcionamiento en modo degradado, evitando que se
envíen transacciones hacia el servidor, que no pueden ser ejecutadas.
Decisión Arquitectónica
Sensibilidad
D1
Riesgo
No Riesgo
R1
D2
Explicación
Tradeoff
NR1
D1(A) El AS400 indica las transacciones que no pueden ser ejecutadas.
Desde Visual Banker las transacciones siempre son enviadas, por lo que
en caso de que exista un error, se produce del lado del servidor.
D2(P) Una vez que la aplicación recibe un error específico (de una
transacción fallida no por datos incorrectos sino por la transacción
propiamente dicha), ésta debe ser capaz de deshabilitar dicha
transacción por un tiempo determinado para evitar que esas peticiones
salgan de VB al servidor, aún cuando se sabe que no pueden ser
ejecutadas.
170
Evaluación Arquitectónica de Visual Banker
Utility Tree y ABAS
Versión: 1.0
Fecha: 05/06/06
R1 Muchas transacciones son disparadas desde Visual Banker, aún
cuando las mismas no pueden ser ejecutadas del lado del servidor. Se
pierde el viaje de la transacción y se congestiona el canal de
comunicación enviando transacciones fallidas.
NR1 No se envían transacciones que la aplicación sabe que van a fallar.
Esto disminuye notablemente el volumen de transacciones que tienen
que ser tendidas, garantizando que todas las enviadas van a poder
ejecutarse.
Diagrama
Escenario #: 25
Escenario: se desea que la aplicación permita hacer backups en diferentes
dispositivos, indicando donde va a ser almacenado.
Atributo(s): fiabilidad.
Ambiente: durante un respaldo.
Estimulo: se realiza el backup de la BD local de una agencia.
Fuente del Estímulo: externa al sistema.
Respuesta: el sistema permite indicar en que lugar se va a guardar el respaldo de la BD.
Artefacto Estimulado: Sistema.
Medida de la Respuesta: existencia de un método que indique diferentes alternativas de
almacenamiento para los respaldos.
Decisión Arquitectónica
Explicación
Sensibilidad
Tradeoff
Riesgo
D1
T1
R1
D2
T1
No Riesgo
NR1
D1(A) Script de almacenamiento que realiza un export de la BD y guarda
el respaldo en una ruta estática ya especificada, sin opción a cambiarla.
D2(P) Script de almacenamiento que permita indicar dinámicamente la
ruta donde va a ser almacenado el respaldo de la Base de Datos.
T1 La seguridad puede verse afectada ya que los archivos de respaldo
son archivos de texto plano que pueden ser accedidos por usuarios no
autorizados.
R1 Los datos son altamente vulnerables. Si se cae el servidor se pierde
171
Evaluación Arquitectónica de Visual Banker
Utility Tree y ABAS
Versión: 1.0
Fecha: 05/06/06
el archivo original y el de respaldo por estar ubicados en el mismo lugar.
NR1 Los archivos no se van a encontrar en el mismo lugar físico, es
posible recuperar uno en caso de que el otro se pierda.
Diagrama
Escenario #: 26
Escenario: ocurre una falla en el canal principal de comunicación.
Atributo(s): fiabilidad.
Ambiente: operación normal.
Estimulo: falla el canal principal de comunicación.
Fuente del Estímulo: externa al sistema.
Respuesta: el sistema libera los puertos para poder iniciar la comunicación por otra vía.
Artefacto Estimulado: Sistema.
Medida de la Respuesta: existencia de un mecanismo que permita a la aplicación hacer el cambio de
canal de comunicación.
Decisión Arquitectónica
Sensibilidad
Tradeoff
D1
D2
Explicación
S1
T1
Riesgo
No Riesgo
R1
NR1
R1
NR1
D1(P) Protocolos de comunicación, a través de los puertos, programas
que se pueden correr, filtros estipulados, etc. La aplicación reconoce
automáticamente cuando debe cambiar de canal.
D2(P) Crear perfiles de usuario para cada protocolo (SNA o TCP/IP). La
aplicación debe reconocer el perfil con el que se conecta cada usuario y
dependiendo del mismo, enviar los datos por el canal de comunicación
que corresponde en cada caso
S1 Existe un punto de sensibilidad en cuanto al formato de transmisión
de los datos, al combinar ambos tipos de protocolos.
T1 La seguridad puede verse afectada con esta decisión arquitectónica.
R1 Se mezclan las transacciones. Algunas van a ser enviadas por el
canal TCP/IP y otras por el SNA (diferentes protocolos), esto ocasiona
que se pierda el orden y el control de las mismas.
172
Evaluación Arquitectónica de Visual Banker
Utility Tree y ABAS
Versión: 1.0
Fecha: 05/06/06
NR1 La aplicación reconoce automáticamente por donde enviar las
transacciones.
Actualmente no existe ninguna decisión tomada que pueda verse
Diagrama
reflejada en la arquitectura.
Escenario #: 27
Escenario: el servidor principal sufre una falla crítica de Software. (Offline)
Atributo(s): fiabilidad.
Ambiente: operación normal.
Estimulo: falla en el servidor principal.
Fuente del Estímulo: externa al sistema.
Respuesta: el sistema comienza a trabajar offline para algunas transacciones.
Artefacto Estimulado: Sistema.
Medida de la Respuesta: existencia de un componente arquitectónico que permita al sistema
cambiarse a un modo de trabajo Offline. Existencia de la estructura de la data replicada localmente.
Decisión Arquitectónica
D1
Explicación
Sensibilidad
Tradeoff
Riesgo
T1, T2
No Riesgo
NR1
D1(P) Creación de una clase que detecte si se tiene o no línea. Si la
respuesta es negativa, activa aquellas transacciones con las que se
pueda trabajar fuera de línea. En la noche cuando las agencias se
encuentren cerradas, se encarga de enviar el lote de transacciones para
que sean efectivamente ejecutadas en el AS400.
T1 La seguridad puede verse afectada si se colocan cierto tipo de
transacciones delicadas para que trabajen fuera de línea.
T2 También la funcionalidad en términos de precisión pues se puede
perder la consistencia de los datos. Por ejemplo: si se paga un cheque
de una cuenta que no tiene fondos.
NR1 Se ofrece continuidad en el servicio dentro de las agencias.
Diagrama
Actualmente no existe ninguna decisión tomada que pueda verse
reflejada en la arquitectura.
173
Evaluación Arquitectónica de Visual Banker
Normas de Calidad ISO 9126
Versión: 1.0
Fecha: 28/05/06
APÉNDICE E – Normas de Calidad ISO 9126
174
APÉNDICE F
Visión del Sistema
Visual Banker- Nueva Arquitectura
Versión 1.0
175
Evaluación Arquitectónica de Visual Banker
Visión del Sistema
Versión: 1.0
Fecha: 08/08/2006
Historia de Revisiones
Fecha
Versión
Descripción
Autor
08/08/2006
1.0
Inicio del Documento
Irene García
176
Evaluación Arquitectónica de Visual Banker
Visión del Sistema
Versión: 1.0
Fecha: 08/08/2006
Tabla de Contenidos
VISIÓN DEL SISTEMA ............................................................................................................................. 178
1. INTRODUCCIÓN .................................................................................................................................. 178
1.1 PROPÓSITO ..............................................................................................................................178
1.2 ALCANCE ..................................................................................................................................178
1.3 DEFINICIONES, SIGLAS Y ABREVIACIONES ..................................................................................178
1.4 REFERENCIAS ...........................................................................................................................179
2. POSICIONAMIENTO ............................................................................................................................ 179
2.1 OPORTUNIDADES DE NEGOCIO ..................................................................................................179
2.2 DECLARACIÓN DEL PROBLEMA ..................................................................................................179
2.3 DECLARACIÓN DEL POSICIONAMIENTO DEL SISTEMA ...................................................................181
3. DESCRIPCIONES DE LOS STAKEHOLDERS Y USUARIOS............................................................. 183
3.1 DEMOGRAFÍA DEL MERCADO .....................................................................................................183
3.2 AMBIENTE USUARIO ..................................................................................................................184
3.3 PERFIL DEL STAKEHOLDER ........................................................................................................185
3.4 PERFIL DEL USUARIO ................................................................................................................186
3.5 NECESIDADES DE LOS STAKEHOLDER O USUARIOS .....................................................................187
4. DESCRIPCIÓN DEL SISTEMA............................................................................................................. 188
4.1 PERSPECTIVA DEL SISTEMA.......................................................................................................188
4.2 RESUMEN DE CAPACIDADES ......................................................................................................188
4.3 ASPECTOS ASUMIDOS
Y DEPENDENCIAS....................................................................................188
4.4 LICENCIAS E INSTALACIÓN .........................................................................................................188
5. CARACTERÍSTICAS DEL SISTEMA.................................................................................................... 189
6. RANGOS DE CALIDAD ........................................................................................................................ 189
7. OTROS REQUERIMIENTOS DEL SISTEMA....................................................................................... 189
8. REQUERIMIENTOS DE DOCUMENTACIÓN ...................................................................................... 189
8.1MANUAL DE USUARIO.................................................................................................................189
8.2AYUDA EN LÍNEA ........................................................................................................................189
8.3GUÍAS DE INSTALACIÓN, CONFIGURACIÓN Y ARCHIVOS READ ME .................................................189
8.4ETIQUETAS Y PAQUETES ............................................................................................................189
177
Evaluación Arquitectónica de Visual Banker
Visión del Sistema
Versión: 1.0
Fecha: 08/08/2006
Visión del Sistema
1. Introducción
1.1Propósito
El propósito de este documento es recolectar, analizar y definir las necesidades a un alto nivel y
aspectos relevantes de las implementaciones realizadas en Visual Banker, una vez finalizada la
evaluación arquitectónica del mismo.
1.2 Alcance
En este documento se especifican los Stakeholders y los usuarios principales del sistema, las
necesidades de cada uno de ellos así como las razones que justifican dichas necesidades.
Adicionalmente este documento contiene las características del sistema, incluyendo restricciones y
criterios de aceptación aplicables al caso.
Los detalles de cómo Visual Banker cumple con esas necesidades son detallados en el Modelo de
Casos de Uso y en las Especificaciones Suplementarias contenidas en los documentos DAS Propuesto
y ERS respectivamente.
Es importante mencionar que en este documento sólo será desarrollada la Visión del sistema
para la parte correspondiente a la nueva implementación que será realizada una vez finalizado el proceso
de Evaluación Arquitectónica de Visual Banker.
1.3 Definiciones, Siglas y Abreviaciones
ƒ Clave Robusta: aquella clave que posee como mínimo 8 caracteres, combinación de letras y
números y al menos un carácter en mayúscula.
ƒ Cliente Especial: aquel cliente del banco que maneja grandes cantidades de dinero
mensualmente, superando en gran medida a la cantidad estándar de movimientos realizados.
ƒ Cliente Normal: aquel cliente del banco que realiza mensualmente una cantidad estándar de
movimientos, perteneciendo al promedio.
ƒ DAS: Documento de Arquitectura de Software de Visual Banker.
ƒ ERS: Documento de Especificaciones de Requerimientos de Software.
178
Evaluación Arquitectónica de Visual Banker
Visión del Sistema
Versión: 1.0
Fecha: 08/08/2006
1.4 Referencias
En el documento se hace referencia al Documento de Arquitectura de Software inicial de Visual
Banker y al Documento de Especificaciones de Requerimientos de Software de Visual Banker.
2. Posicionamiento
2.1 Oportunidades de Negocio
El motivo fundamental para el desarrollo del sistema, se basa principalmente en el soporte que el
mismo ofrece a las 400 agencias a nivel nacional que pertenecen a la organización. Visual Banker
permite que diariamente se ejecuten las transacciones correspondientes a depósitos, retiros, pago de
cheques, pago de servicios, pago de proveedores, etc. que le generan al banco un gran capital y que
permite el desarrollo del mismo a través de la captación de nuevos clientes. La aplicación permite de
alguna manera el crecimiento de la organización, al favorecer la creación de nuevos negocios entre el
banco y sus clientes.
La meta que se está alcanzando corresponde al desarrollo sostenido de la
organización, a través del servicio ofrecido a los clientes existentes y a la creación de nuevos clientes.
La idea principal es permitir la evolución del sistema y realizar mejoras en aquellos aspectos que
presenten algún tipo de falla o que requieran ser modificados y adaptados a las nuevas necesidades que
presenta la institución.
2.2 Declaración del Problema
En la siguiente sección van a ser descritos los problemas específicos que serán atacados durante
la implementación de las mejoras propuestas para Visual Banker. De igual manera se mencionará a las
personas que se ven afectadas por los mismos, el impacto que el problema tiene sobre ellas y la solución
que se plantea para poder solventarlo.
El problema de
carencia de un módulo que permita que clientes
especiales de la organización posean una transacción
de recaudaciones a través de la cual sea posible
registrar todos los depósitos realizados sobre su cuenta.
179
Evaluación Arquitectónica de Visual Banker
Visión del Sistema
Afecta a
Versión: 1.0
Fecha: 08/08/2006
el cliente externo de Droguería Nena, además de los
taquilleros de las agencias.
Cuyo impacto es
que los taquilleros actualmente deben procesar las
operaciones pertenecientes al cliente como si se tratara
de cualquier otro depósito, lo que perjudica su trabajo al
hacer el proceso más lento. Además de que el cliente
no cuenta con una transacción personalizada a través
de la cual se manejen únicamente los productos que
posee el mismo con el banco.
Una solución exitosa sería
la implementación de un módulo a través del cual sea
posible manejar la transacción de recaudaciones de
dicho cliente en forma personalizada, agilizando de esta
manera el trabajo realizado por el personal de taquilla.
El problema de
falta de seguridad en las agencias, al no existir
mecanismos que garanticen la creación de claves
robustas por parte de los usuarios y que obliguen al
cambio constante de las mismas.
Afecta a
la institución bancaria como un todo, especialmente al
área de Seguridad.
Cuyo impacto es
bajos niveles de seguridad y posible acceso de
personas no autorizadas a información confidencial.
Mayor facilidad para deducir las claves por ser éstas
muy sencillas y no ser cambiadas constantemente.
Una solución exitosa sería
implementación de mecanismos que garanticen la
creación de claves robustas y que obliguen al cambio
de las mismas en un lapso de tiempo configurable.
El problema de
inconvenientes constantes que se presentan en las
agencias por no saber si la nueva versión del ejecutable
fue instalada correctamente en todas las estaciones de
trabajo. Esto ocasiona que no se cuente con todas las
funcionalidades disponibles que posee la aplicación.
Afecta a
los agentes de las agencias (taquilleros y promotores),
además del área de Plataforma encargada de solventar
180
Evaluación Arquitectónica de Visual Banker
Visión del Sistema
Versión: 1.0
Fecha: 08/08/2006
los problemas cuando los mismos son reportados por
cualquier agencia a nivel nacional.
Cuyo impacto es
retraso en el trabajo realizado por los agentes al no
contar con todas las funcionalidades disponibles en la
nueva versión de la aplicación, además de otro tipo de
fallas que se producen como consecuencia de la falta
de actualización. Retraso en la Gerencia de Plataforma
al tener que invertir grandes cantidades de tiempo para
poder determinar cual es el problema, además de
atenderlo y solventarlo una vez que haya sido
identificado.
Una solución exitosa sería
contar con un mecanismo que permitiera saber de
manera rápida y sencilla la fecha de actualización y
tamaño del Build instalado en cada máquina para
poder determinar si se instaló la versión correcta. Esto
permitiría descartar otra serie de inconvenientes y
ahorrar tiempo al momento de identificar el problema y
llevar a cabo la solución.
2.3 Declaración del Posicionamiento del Sistema
Para
los taquilleros que trabajan en las diferentes agencias a
nivel nacional.
Quiénes
requieren realizar su trabajo de forma más eficiente y
sencilla,
agilizando
las
operaciones
que
procesan
diariamente, mejorando notablemente sus tiempos de
respuesta en la atención al público.
El módulo de pago de
es un módulo perteneciente a Visual Banker que trabaja
servicios - recaudaciones
de forma Cliente-Servidor y que posee una serie de
transacciones que pueden ser ejecutadas desde Taquilla.
Qué
permite el manejo de depósitos especializados para un
cliente específico del banco que maneja grandes
cantidades de dinero y sobre cuyos productos se hacen
constantes movimientos, facilitando el trabajo realizado
por los taquilleros al presentar una interfaz sencilla a
través de la cual se procesen todas las transacciones.
Se diferencia de
N/A
181
Evaluación Arquitectónica de Visual Banker
Visión del Sistema
Nuestro Sistema
Versión: 1.0
Fecha: 08/08/2006
facilitará el manejo de los depósitos realizados sobre la
cuenta de dicho cliente, permitiendo la cancelación de
múltiples facturas en forma simultánea y con 3 formas de
pago diferentes, por parte de todos los clientes de
Droguería Nena.
Para
los taquilleros y promotores que trabajan en las diferentes
agencias a nivel nacional, así como los gerentes y demás
empleados.
Quiénes
hacen uso diario de la aplicación Visual Banker y sus
diferentes
módulos
para
procesar
las
operaciones
solicitadas por los clientes de la institución, manejando
información confidencial sobre los mismos y los productos
que éstos poseen en el banco.
El mecanismo de
es un procedimiento perteneciente a Visual Banker que
validación de claves
trabaja de forma Cliente-Servidor.
Qué
permite la realización de un conjunto de validaciones
necesarias para garantizar la robustez de las claves
creadas por los usuarios así como el cambio continuo de
las mismas.
Se diferencia de
la forma como se está haciendo actualmente, en la que
no existe ningún tipo de verificación o estándar para la
creación de passwords.
Nuestro Sistema
permitirá una mayor seguridad dentro de las agencias al
garantizar la creación de claves más difíciles de deducir
por parte de personas no autorizadas, además de validar
que las mismas tengan un mínimo de 8 caracteres,
combinación de números y letras y al menos un caracter
en mayúscula. De igual manera antes de iniciar sesión
verificará que la clave de acceso no se encuentre
vencida, en caso contrario informará al usuario y obligará
a su cambio para poder ingresar al sistema.
Para
los usuarios de Visual Banker que laboran en las
agencias, además de la Gerencia de Plataforma.
Quiénes
182
emplean diariamente la aplicación para procesar las
Evaluación Arquitectónica de Visual Banker
Visión del Sistema
Versión: 1.0
Fecha: 08/08/2006
operaciones solicitadas por los usuarios y muchas veces
no cuentan con todas las funcionalidades disponibles
como consecuencia de una actualización incorrecta.
Además de la Gerencia de Plataforma que tiene que dar
soporte
a
la
aplicación
en
caso
de
posibles
inconvenientes, determinando cuál es el problema para
poder solucionarlo.
El mecanismo de
es un procedimiento perteneciente a la aplicación Visual
verificación de versión
Banker la cual trabaja de forma Cliente-Servidor.
Qué
permitirá a todos los usuarios conocer en forma rápida y
sencilla el tamaño y fecha de actualización del Build
instalado
en
sus
máquinas
para
determinar
si
efectivamente fueron actualizadas, además de facilitar el
trabajo de la gerencia de Plataforma al poder saber
rápidamente cual es el inconveniente causado y proceder
a solventarlo.
Se diferencia de
la forma como se está haciendo actualmente, en la que
no hay manera de saber de forma inmediata si la última
versión fue instalada correctamente.
Nuestro Sistema
leerá de un archivo “.ini”, distribuido junto con el Build, el
tamaño y fecha de actualización del ejecutable para poder
comparar si se tiene la última versión instalada. El
mecanismo podrá ser activado simplemente presionando
un botón por parte de los usuarios. Esto permitirá que la
actividad de instalación sea mucho más fácil, así como la
verificación de posibles errores producidos durante la
misma.
3. Descripciones de los Stakeholders y Usuarios
3.1 Demografía del Mercado
El segmento del mercado que se quiere satisfacer con la implementación de estas soluciones se
basa principalmente en los empleados de las agencias a nivel nacional, pues los mismos se verán
beneficiados al tener un desarrollo más eficiente de su trabajo así como en una mayor seguridad en sus
cuentas de usuario. Este grupo involucra a Administradores, Taquilleros, Promotores, Gerentes y
183
Evaluación Arquitectónica de Visual Banker
Visión del Sistema
Versión: 1.0
Fecha: 08/08/2006
personal que tenga acceso a la aplicación Visual Banker y que representan a los usuarios potenciales de
la aplicación en las 400 agencias que se encuentran desplegadas a lo largo y ancho del país.
De igual manera, la Institución como un todo se beneficiará de este desarrollo al conseguir
mayores funcionalidades para la aplicación con la creación del módulo de Droguería Nena, mayores
niveles de seguridad de la información
y mejoras en la portabilidad al beneficiar la característica
asociada a facilidad de instalación. Todos estos elementos permitirán mantener a los clientes mucho más
satisfechos, ofreciéndoles una mayor confianza al garantizar que sus datos se encontrarán bien
protegidos.
La Gerencia de Plataforma obtendrá una ganancia en la medida en la que será mucho más fácil
determinar los inconvenientes producidos en las agencias como consecuencia de la actualización
incorrecta de las estaciones de trabajo. Esto les permitirá ahorrar tiempo invertido para poder determinar
el problema y ser más eficientes en el desarrollo de sus actividades diarias.
Estos elementos ayudan al soporte de las metas estratégicas al realizar mejoras en los atributos
de calidad que se constituyen como un objetivo que debe ser alcanzado por todas las áreas del banco.
3.2 Ambiente Usuario
La aplicación Visual Banker es de tipo Cliente/Servidor, corriendo en el sistema operativo OS/2
Warp for e/bussines de IBM v.4.5 del lado del servidor y en el sistema operativo OS/2 Warp 4.0
workstation de IBM y Fixes 5,13 y 15 del lado del cliente. El canal de comunicación que se usa
actualmente es SNA y la base de datos es DB/2 de IBM v.2.1.2. El ejecutable es distribuido a los
servidores de cada agencia, los cuales a su vez distribuyen la versión a través de un Script, instalándola
en cada una de las estaciones de trabajo.
Con la implementación actual no se pretende realizar ninguna modificación a la plataforma
empleada, sin embargo, existe un proyecto a mediano plazo en el que se pretende realizar la migración
del sistema operativo de OS/2 a Windows XP, con el protocolo de comunicación TCP/IP.
Existen un conjunto de aplicaciones que actualmente se comunican con Visual Banker, pero que
no se van a ver afectadas por el desarrollo realizado. Dichas aplicaciones se refieren a Lotus Notes,
Emulación Personal Communications, Communications Manager, Tivoli e IBM Web Browser.
184
Evaluación Arquitectónica de Visual Banker
Visión del Sistema
Versión: 1.0
Fecha: 08/08/2006
3.3 Perfil del Stakeholder
Representatividad
Gerencia de Plataforma.
Descripción
Analistas pertenecientes a la Gerencia. Conocen en profundidad a la
aplicación pues han participado en su desarrollo. Ofrecen mantenimiento y
soporte.
Tipo
Usuario Experto, Desarrollador.
Responsabilidad
- Desarrollo y mantenimiento de la aplicación.
- Soporte a usuarios en caso de inconvenientes con la misma.
- Velar por la buena marcha del proyecto.
Criterios de Éxito
Cumplimiento de todas las especificaciones suplementarias y funcionales
que fueron definidas. Obtención de un producto de calidad con los
recursos y esfuerzos estimados en la planificación.
Nivel de
Provee toda la información necesaria para poder llevar a cabo el proyecto
participación
aparte de apoyar la planificación y el desarrollo del mismo.
Entregables
No aplica.
Comentarios/otros
No aplica.
aspectos
Representatividad
Gerencia de Auditoria de Sistemas de Banesco.
Descripción
Sólidos conocimientos en auditoria de sistemas, para que aporte
recomendaciones necesarias a considerar en el desarrollo y certificación
de la solución.
Tipo
Experto en Auditoria de Sistemas.
Responsabilidad
- Control de cumplimiento de las reglas de negocio por parte de la
aplicación, certifica que la misma cumpla con los lineamientos
organizacionales en materia de auditorias.
Criterios de Éxito
Obtención de un producto de calidad que cumpla con las reglas
establecidas.
Nivel de
Participa en la toma de decisiones y ofrece consultoría.
participación
Entregables
Resultado de las pruebas integrales.
Comentarios/otros
No aplica.
aspectos
Representatividad
Gerencia de División de Consultoría y manejo de incidentes de Seguridad.
Descripción
Expertos en seguridad de sistemas y en las reglas que deben ser
185
Evaluación Arquitectónica de Visual Banker
Visión del Sistema
Versión: 1.0
Fecha: 08/08/2006
cumplidas para que la misma sea garantizada. Sólidos conocimientos en
las políticas de seguridad y mejores prácticas.
Tipo
Especialista en procesos y políticas de seguridad.
Responsabilidad
- Velar por el cumplimiento de las políticas.
- Ofrecer recomendaciones sobre mejores prácticas.
Criterios de Éxito
Obtención de un producto de calidad que cumpla con las reglas
establecidas.
Nivel
de
Participa en la toma de decisiones y ofrece consultoría en ámbitos
participación
relacionados con seguridad.
Entregables
No aplica.
Comentarios/otros
No aplica.
aspectos
Representatividad
Gerencia de Calidad en Informática.
Descripción
Sólidos conocimientos en la metodología Rupcorb, así como en las
actividades
y
fases
de
la
misma.
Participará
como
facilitador
metodológico.
Tipo
Experto en metodología para desarrollo de Software.
Responsabilidad
- Brindar apoyo en las actividades de la metodología Rupcorb, así como
cualquier tipo de consultoría requerida.
- Levantar alertas ante posibles desviaciones que puedan generarse en la
ejecución de la solución.
Criterios de Éxito
Obtención de un producto de calidad que cumpla con las reglas
establecidas.
Nivel de
Apoya el desarrollo del proyecto así como la planificación. Participa en la
participación
toma de decisiones.
Entregables
Documentación (DAS, ERS, etc.)
Comentarios/otros
No aplica.
aspectos
3.4 Perfil del Usuario
Representatividad
Agentes de las agencias bancarias a nivel nacional
Descripción
Personas que poseen el perfil de taquilleros, promotores o usuarios
habituales de la aplicación que hacen uso de la misma diariamente.
Tipo
186
Usuario Experto – Usuario con dominio técnico.
Evaluación Arquitectónica de Visual Banker
Visión del Sistema
Responsabilidad
Versión: 1.0
Fecha: 08/08/2006
- Manejo de los diferentes módulos de la aplicación y de las transacciones
o procedimientos que serán implementados.
- Indicar observaciones o sugerencias respecto al producto final.
Criterios de Éxito
Ser capaces de emplear la aplicación y todas sus funcionalidades.
Nivel de
Señala posibles mejoras que pueden ser realizadas a la aplicación.
participación
Entregables
No aplica.
Comentarios/otros
No aplica.
aspectos
3.5 Necesidades de los Stakeholder o Usuarios
Necesidad
Existencia de un
Prioridad
Alta
Problema que
origina la necesidad
Solución Actual
Soluciones Propuestas
Actualmente no existe
Las operaciones
Creación de un módulo a
modulo
ningún módulo
asociadas a un cliente
través del cual solo se
personalizado a
especializado para
especial son tratadas a
manejen las operaciones
través del cual se
manejar las
través del mismo
asociadas a dicho cliente
manejen todas las
transacciones
módulo de un cliente
y en la que los clientes de
operaciones
asociadas con ese
normal. No existe
Droguería Nena puedan
realizadas sobre
cliente. Esto retrasa el
ningún tipo de
cancelar sus facturas
los productos de un
trabajo de los agentes
distinción.
contando con diferentes
cliente especial.
dentro de las
formas de pago.
agencias.
Mayor control de
Alta
Las claves creadas
Al momento de ingreso
Implementación de un
acceso de
por los usuarios son
a la aplicación
mecanismo a través del
personas no
muy débiles y pueden
simplemente se valida
cual sea posible validar la
autorizadas a
ser deducidas
contra la BD local y
creación de claves
información
fácilmente. Además
cuando se crea una
robustas y que las mismas
confidencial.
no se obliga al cambio
nueva clave no se
posean fecha de
constante de las
garantiza que sea
vencimiento para obligar a
mismas.
robusta y se cambie
los usuarios a cambiarlas.
constantemente.
Detección y
No es fácil detectar
Actualmente es
Mecanismo que permita
solución inmediata
cual es el
imposible saber si
determinar rápidamente si
de inconvenientes
inconveniente que
efectivamente la
la versión instalada es la
reportados en las
surge en una estación
versión fue instalada
correcta, en caso contrario
agencias por una
de trabajo de una
de manera correcta en
se podrá proceder de
actualización
agencia.
todas las máquinas.
forma inmediata para
incorrecta.
Alta
solventar el problema.
187
Evaluación Arquitectónica de Visual Banker
Visión del Sistema
Versión: 1.0
Fecha: 08/08/2006
4. Descripción del Sistema
4.1 Perspectiva del Sistema
Con el nuevo desarrollo se mantiene la misma interrelación con otras aplicaciones y
configuración del sistema que fue descrita en el punto 3.2 Ambiente de Usuario.
4.2 Resumen de Capacidades
Necesidades del Cliente
Macro-Características del Sistema
Existencia de un modulo
Validación del código del cliente, validación de número máximo de
personalizado a través del cual
facturas que pueden ser canceladas por el cliente, validación de que
se manejen todas las
los montos de total y subtotal coincidan, validación de ingreso de #
operaciones realizadas sobre los
productos de un cliente especial.
documento con un importe asociado. Manejo de todos los depósitos
realizados sobre las cuentas de Droguería Nena, permitiendo 3
formas de pago diferentes que pueden ser simultáneas.
Mayor control de acceso de
Validación de creación de claves con un mínimo de 8 caracteres,
personas no autorizadas a
combinación de letras y números, al menos dos dígitos numéricos no
información confidencial.
ubicados al inicio o fin de la clave, al menos un carácter en
mayúscula. Registro de la última fecha de actualización y
comparación constante de la misma para poder determinar si se
encuentra vencida, el tiempo de expiración es configurable.
Detección y solución inmediata
Verificación de tamaño y fecha de actualización del ejecutable
de inconvenientes reportados en
instalado en cada máquina. El mecanismo se activa con solo
las agencias como consecuencia
presionar un botón.
de una actualización incorrecta.
4.3 Aspectos asumidos y Dependencias
A continuación se especifican las principales suposiciones y dependencias para los procesos que
fueron desarrollados.
ƒ Todas las estaciones de trabajo deben tener Visual Banker instalado.
ƒ Debe existir una conexión tanto con el servidor local como con el AS400
ƒ Los archivos “.ini” que fueron creados deben ser distribuidos junto con el ejecutable e instalados
correctamente en cada máquina para poder ser leídos cuando sea necesario.
4.4 Licencias e Instalación
La instalación se realiza mediante la distribución del ejecutable a todos los servidores locales de
las agencias a través del servicio Tivoli. Una vez distribuidos a los servidores, los archivos son copiados a
188
Evaluación Arquitectónica de Visual Banker
Visión del Sistema
Versión: 1.0
Fecha: 08/08/2006
través de un Script en cada máquina, siempre y cuando se encuentren diferencias entre la versión actual
y la nueva versión. Si el Script no es colocado en el lugar correcto no se llevará a cabo la actualización.
5. Características del Sistema
Se mantienen las macro características que fueron descritas en el cuadro 4.2 considerando una
prioridad alta para cada una de ellas.
6. Rangos de Calidad
Los rangos de calidad y características suplementarias se encuentran definidas en el documento
ERS de Visual Banker.
7. Otros Requerimientos del Sistema
Los requerimientos correspondientes a Hardware, Red, Software; entre otros, se encuentran
definidos en la Vista de Implantación contenido en el DAS inicial de Visual Banker. En el mismo se
especifican claramente los diferentes estándares de red aplicables (TCP/IP - SNA) así como los
estándares y restricciones de plataforma (OS2).
8. Requerimientos de Documentación
8.1 Manual de Usuario
El manual de usuario correspondiente a la funcionalidad de “Droguería Nena”, está siendo
desarrollado por el área de Calidad y Procesos, la cual se encarga de elaborar todo ese tipo de
documentación para los nuevos desarrollos.
8.2 Ayuda en Línea
N/A
8.3 Guías de Instalación, Configuración y archivos Read Me
Se mantienen las mismas guías de instalación que habían sido definidas en un principio para
Visual Banker. El nuevo desarrollo no afecta la configuración ni archivos Read Me originales.
8.4 Etiquetas y Paquetes
N/A
189
APÉNDICE G
Visual Banker
Especificaciones de Requerimientos del Software
Versión 1.0
190
Evaluación Arquitectónica de Visual Banker
ERS Nuevo Desarrollo
Versión: 1.0
Fecha: 10/08/2006
Historia de Revisiones
Fecha
Versión
Descripción
Autor
08/08/2006
1.0
Inicio del documento. Documento ERS
Irene García
para la nueva implementación.
191
Evaluación Arquitectónica de Visual Banker
ERS Nuevo Desarrollo
Versión: 1.0
Fecha: 10/08/2006
Tabla de Contenido
1. INTRODUCCIÓN................................................................................................................................... 193
1.1 ALCANCE ..................................................................................................................................193
1.2 DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS ............................................................................193
1.3 REFERENCIAS ...........................................................................................................................193
2. ESPECIFICACIONES FUNCIONALES................................................................................................. 193
3. CASOS DE USO ................................................................................................................................... 194
3.1RESUMEN DE CASOS DE USO Y ACTORES ...................................................................................194
3.2ESPECIFICACIONES DE CASOS DE USO .......................................................................................194
3.3DIAGRAMA DE CASO DE USO.......................................................................................................198
192
Evaluación Arquitectónica de Visual Banker
ERS Nuevo Desarrollo
Versión: 1.0
Fecha: 10/08/2006
Especificaciones de Requerimientos del Software
1. Introducción
Este documento detalla los requerimientos de Software para la nueva implementación que va a
ser realizada dentro de la aplicación Visual Banker.
1.1 Alcance
El alcance de este documento es la Especificación de los Requerimientos de Software para los
escenarios que van a ser implementados dentro de Visual Banker, una vez que finalizó el proceso de
evaluación arquitectónica del mismo. Dichas especificaciones incluyen a los requerimientos funcionales
así como a los casos de uso que van a ser definidos a partir de los mismos. Aquellos casos de uso
originales que se vean afectados como consecuencia de la implementación, serán explicados en el
Documento de Arquitectura de Software Propuesto.
1.2 Definiciones, Acrónimos y Abreviaturas
DAS Documento de Arquitectura de Software.
ERS Documento de Especificaciones de Requerimientos de Software.
1.3 Referencias
En este documento se hace referencia al DAS propuesto, así como al ERS inicial.
2. Especificaciones Funcionales
A continuación se muestran las especificaciones funcionales definidas para los tres escenarios
que serán implementados como parte de la nueva arquitectura de la aplicación.
ID
F1
Nombre del Requerimiento
Módulo exclusivo para el cliente
Descripción
El cliente poseerá un módulo de depósito exclusivo para su
Droguería Nena.
recaudación, el mismo deberá capturar los siguientes
campos: Código del Cliente, Total a Depositar: Efectivo,
Cheque Banesco, Cheque Otros Bancos, Fecha de la
operación, No. De Depósito. Cuenta Recaudadora, No. De
documento, Importe.
F2
Validación módulo 11
Se debe emplear el algoritmo Módulo 11 para validar el
193
Evaluación Arquitectónica de Visual Banker
ERS Nuevo Desarrollo
Versión: 1.0
Fecha: 10/08/2006
código de cliente suministrado. Dicho algoritmo será
facilitado por Droguería Nena.
F3
Formas de Pago
La transacción de recaudación aceptara los siguientes
modos de depósito: Efectivo/Cheques Banesco, Cheques
de Otros Bancos, Cheques de Gerencia de Banesco,
Cheques de Gerencia de otros bancos y Cargo en Cuenta.
F4
Validación de Robustez
Se debe validar que las claves ingresadas por los usuarios
sean lo suficientemente robustas; es decir, contengan un
mínimo de 8 caracteres, combinación de letras y números,
al menos un caracter en mayúscula y que no comiencen ni
terminen con números.
F5
Cambio continuo de Password
La
aplicación
debe
registrar
la
última
fecha
de
actualización de la clave y no permitir el ingreso de los
usuarios cuando la resta de la fecha actual menos la fecha
de actualización supere el tiempo de expiración.
F6
F7
Tiempo de Expiración
El tiempo de expiración asignado para las claves debe ser
Configurable
configurable.
Mostrar Versión
Tanto el módulo de taquilla como el de plataforma deben
contar con un mecanismo sencillo a través del cual los
usuarios puedan revisar la fecha y tamaño del Build
instalado en sus máquinas.
3. Casos de Uso
3.1 Resumen de Casos de Uso y Actores
En la siguiente tabla se muestran los nuevos casos de uso que fueron generados como
consecuencia de los requerimientos funcionales mostrados en la tabla anterior.
Caso de Uso
Ejecutar Transacción Droguería Nena
Taquillero
Actor
Cambiar Password
Taquillero/Promotor
Mostrar Versión
Taquillero/Promotor
3.2 Especificaciones de Casos de Uso
CASO DE USO
Ejecutar Transacción Droguería Nena
ACTOR
Taquillero
194
Evaluación Arquitectónica de Visual Banker
ERS Nuevo Desarrollo
DESCRIPCIÓN
Versión: 1.0
Fecha: 10/08/2006
Permite a los taquilleros manejar las recaudaciones de un cliente específico
de la organización, denominado Droguería Nena.
REQUERIMIENTOS
F1, F2, F3
ASOCIADOS
PRECONDICIÓN
El taquillero debe estar registrado en el sistema y poseer un nombre de
usuario y clave válidos.
CURSO NORMAL
ACTOR
SISTEMA
1. El taquillero abre la venta
principal de Taquilla y
selecciona la Operación
“Pago de Servicios”.
3. El taquillero selecciona la
opción Recaudaciones.
5. El taquillero seleccionada
de la lista de clientes la
opción de Droguería Nena.
7. El taquillero llena los
datos correspondientes y
2. El sistema procesa la solicitud y muestra la
lista de transacciones asociadas a la
operación seleccionada.
4. El sistema abre la ventana correspondiente
a la transacción solicitada.
6. El sistema muestra el formulario
correspondiente con los datos que deben ser
llenados.
8. El sistema verifica los datos suministrados
y ejecuta la transacción seleccionada.
presiona el botón Aceptar.
CURSO ALTERNO
ACTOR
SISTEMA
En el paso 8 del curso normal:
8. El sistema valida los datos suministrados e
indica que el código de cliente introducido no
9. El usuario ingresa un
es válido.
cliente válido y presiona el
botón Aceptar.
10. El sistema verifica los datos
suministrados y ejecuta la transacción.
POSTCONDICIÓN
El taquillero procesa la transacción de recaudaciones correspondiente al
cliente Droguería Nena.
CASO DE USO
Cambiar Password
ACTOR
Agente (Taquillero/ Promotor)
195
Evaluación Arquitectónica de Visual Banker
ERS Nuevo Desarrollo
Versión: 1.0
Fecha: 10/08/2006
DESCRIPCIÓN
Un usuario de la aplicación realiza el cambio de su clave de acceso.
REQUERIMIENTOS
F4, F5, F6
ASOCIADOS
PRECONDICIÓN
El agente debe estar conectado y autenticado en el sistema
CURSO NORMAL
ACTOR
SISTEMA
1. El agente seleccionada la
opción para el cambio de
2. El sistema muestra la pantalla a través de
la cual se debe realizar el cambio de la
clave.
misma.
3. El agente rellena los
campos correspondientes a
clave actual, clave nueva y
confirmación, y presiona el
botón Aceptar.
CURSO ALTERNO
4. El sistema realiza la verificación y registra
los datos introducidos, modificando la fecha
de actualización y efectuando el cambio de
clave para el usuario solicitado.
ACTOR
SISTEMA
En el paso 4 del curso normal:
4. Al realizar la verificación de la nueva clave
5. El agente realiza las
el sistema indica que la misma no tiene el
modificaciones, volviendo a
mínimo de caracteres requeridos.
introducir la clave nueva y la
verificación y presiona el
botón Aceptar.
6. El sistema valida los campos introducidos
y realiza el cambio, modificando la fecha de
actualización de la clave.
POSTCONDICIÓN
Se modifica la clave de acceso de un de un usuario específico de la
aplicación Visual Banker.
CASO DE USO
Ejecutar Transacción Droguería Nena
ACTOR
Taquillero
DESCRIPCIÓN
Permite a los taquilleros manejar las recaudaciones de un cliente específico
de la organización, denominado Droguería Nena.
REQUERIMIENTOS
F7
ASOCIADOS
PRECONDICIÓN
196
El agente debe estar registrado en el sistema y poseer un nombre de
Evaluación Arquitectónica de Visual Banker
ERS Nuevo Desarrollo
Versión: 1.0
Fecha: 10/08/2006
usuario y clave válidos.
CURSO NORMAL
ACTOR
SISTEMA
1. El agente selecciona la
opción para verificar la
versión del Build que tiene
de la cual se puede validar el tamaño y fecha
de actualización del ejecutable.
instalada.
CURSO ALTERNO
2. El sistema muestra una ventana a través
ACTOR
SISTEMA
En el paso 2 del curso normal:
2. El sistema indica que el archivo “.ini” que
contiene los datos que deben ser mostraos no
se encuentra en la ruta correcta.
POSTCONDICIÓN
El agente verifica el tamaño y fecha de actualización del Build instalado.
CASO DE USO
Mostrar Versión
ACTOR
Agente (Taquillero/ Promotor)
DESCRIPCIÓN
Un usuario de la aplicación verifica el tamaño y fecha de actualización del
Build que tiene instalado en su máquina.
REQUERIMIENTOS
F6, F7
ASOCIADOS
PRECONDICIÓN
El agente debe estar conectado y autenticado en el sistema
CURSO NORMAL
ACTOR
SISTEMA
1. El agente seleccionada la
opción para el cambio de
2. El sistema muestra la pantalla a través de
la cual se debe realizar el cambio de la
clave.
misma.
3. El agente rellena los
campos correspondientes a
clave actual, clave nueva y
confirmación, y presiona el
botón Aceptar.
CURSO ALTERNO
ACTOR
4. El sistema realiza la verificación y registra
los datos introducidos, modificando la fecha
de actualización y efectuando el cambio de
clave para el usuario solicitado.
SISTEMA
En el paso 4 del curso normal:
197
Evaluación Arquitectónica de Visual Banker
ERS Nuevo Desarrollo
Versión: 1.0
Fecha: 10/08/2006
5. El agente realiza las
4. Al realizar la verificación de la nueva clave
modificaciones, volviendo a
el sistema indica que la misma no tiene el
introducir la clave nueva y la
mínimo de caracteres requeridos.
verificación y presiona el
botón Aceptar.
6. El sistema valida los campos introducidos
y realiza el cambio, modificando la fecha de
actualización de la clave.
POSTCONDICIÓN
Se modifica la clave de acceso de un de un usuario específico de la
aplicación Visual Banker.
3.3 Diagrama de Caso de uso
Figura 1 [Diagrama de Casos de Uso – Elaboración Propia]
En el diagrama anterior es posible verificar los tres casos de uso planteados como parte de la
nueva implementación. Es importante destacar que los mismos no se muestran en el contexto general de
todos los casos de uso anteriores sino que solamente se muestra la interacción que existe entre ellos. El
caso de uso Ejecutar Transacción Droguería Nena es específico del módulo de Taquilla y se representa
como una extensión del caso de uso “Seleccionar Pago de Servicios Recaudaciones” que se encuentra
definido en la vista lógica del DAS original de Visual Banker, así como en el ERS inicial. El caso de uso
“Cambiar Password” también se encuentra definido en el ERS original pero sufrió una modificación como
consecuencia de la implementación realizada en cuanto a la validación de passwords robustos. En la
Vista de Casos de Uso del DAS propuesto se explicará con más detalle los cambios producidos.
198
APÉNDICE H
Visual Banker
Documento de Arquitectura de Software Propuesto
Versión 1.0
199
Evaluación Arquitectónica de Visual Banker
DAS Propuesto – Nuevo Desarrollo
Versión: 1.0
Fecha: 25/08/2006
Historia de Revisiones
Fecha
Versión
Descripción
Autor
25/08/2006
1.0
Modificaciones realizadas al
Irene García
Documento de Arquitectura original de
Visual Banker como consecuencia de
nuevas implementaciones.
200
Evaluación Arquitectónica de Visual Banker
DAS Propuesto – Nuevo Desarrollo
Versión: 1.0
Fecha: 25/08/2006
Tabla de Contenido
1.INTRODUCCIÓN ................................................................................................................................... 202
1.1PROPÓSITO DE ESTE DOCUMENTO ..............................................................................................202
1.2ALCANCE ..................................................................................................................................202
1.3DEFINICIONES, SIGLAS, Y ABREVIACIONES ..................................................................................202
1.4REFERENCIAS ...........................................................................................................................202
1.5VISTA GLOBAL ...........................................................................................................................202
2.REPRESENTACIÓN ARQUITECTÓNICA............................................................................................. 202
3.METAS Y RESTRICCIONES ARQUITECTÓNICAS ............................................................................. 203
4.VISTA DE CASOS DE USO................................................................................................................... 203
5.VISTA LÓGICA ...................................................................................................................................... 204
5.1VISIÓN GENERAL ........................................................................................................................204
5.2PAQUETES DE DISEÑO ARQUITECTÓNICAMENTE SIGNIFICATIVOS ................................................212
6.VISTA DE PROCESOS.......................................................................................................................... 214
7.VISTA DE IMPLANTACIÓN ................................................................................................................... 214
8.VISTA DE IMPLEMENTACIÓN.............................................................................................................. 215
9 CALIDAD ................................................................................................................................................ 215
201
Evaluación Arquitectónica de Visual Banker
DAS Propuesto – Nuevo Desarrollo
Versión: 1.0
Fecha: 25/08/2006
DOCUMENTO DE ARQUITECTURA DE SOFTWARE
1. Introducción
1.1 Propósito de este documento
El siguiente documento tiene como objetivo fundamental presentar las modificaciones realizadas
en las diferentes vistas arquitectónicas, como consecuencia del proceso de implementación de una parte
de las mejoras propuestas para Visual Banker. Lo que se busca es actualizar el Documento de
Arquitectura de Software inicial, a través del registro de las modificaciones realizadas en la arquitectura
como resultado del proceso de evaluación arquitectónica.
1.2 Alcance
Solo se presentarán las vistas arquitectónicas que sufrieron algún tipo de cambio. Los puntos que
se mantienen iguales que en el documento de arquitectura inicial no serán mencionados en este
documento.
1.3 Definiciones, Siglas, y Abreviaciones
ƒ DAS Documento de Arquitectura de Software.
ƒ UT Utility Tree.
1.4 Referencias
En el documento se hace referencia al DAS inicial de Visual Banker, el cual fue desarrollado el
15/05/2006. De igual manera, se hace referencia al documento correspondiente a Utility Tree y ABAS.
1.5 Vista Global
Serán presentadas las modificaciones en cada una de las vistas que se vieron afectadas al
realizar la implementación de algunas de las propuestas planteadas durante la evaluación arquitectónica
de Visual Banker.
2. Representación Arquitectónica
Se mantiene la misa representación arquitectónica definida en el Documento de Arquitectura de
Software inicial de Visual Banker.
202
Evaluación Arquitectónica de Visual Banker
DAS Propuesto – Nuevo Desarrollo
Versión: 1.0
Fecha: 25/08/2006
3. Metas y Restricciones Arquitectónicas
Se mantienen las mismas que fueron definidas en el Documento de Arquitectura de Software inicial
de Visual Banker.
4. Vista de Casos de Uso
En términos generales la vista de Casos de Uso sufrió pocas modificaciones en relación con la
vista inicial que se encuentra descrita en el Documento de Arquitectura de Visual Banker original. Existen
casos de uso puntuales que de alguna manera se vieron afectados en su descripción. Por ejemplo, el
caso de uso general denominado “Entrar al Sistema” cuenta con un nuevo curso alterno, que se produce
cuando la clave introducida por el usuario se encuentra vencida. En esa situación, el sistema advierte que
la clave se venció y que debe ser cambiada, redireccionando al usuario a la pantalla para el cambio de
password. Una vez ingresados y validados los datos correspondientes el sistema permitirá el acceso de
los usuarios.
De igual manera, el caso de uso perteneciente a Taquilla denominado “Cambiar Password”
presenta un curso alterno, que se produce cuando el usuario coloca una clave nueva que no es lo
suficientemente robusta. En esa situación, el sistema validad las condiciones que debe tener la clave e
informa al usuario que la misma no es válida, indicando los motivos. Hasta que el usuario no ingrese una
clave segura, el sistema no permitirá que se realice el cambio. La descripción específica del mismo se
encuentra definida en el ERS de la nueva arquitectura de Visual Banker.
También es importante mencionar que el caso de uso denominado “Pago de Servicios
Recaudaciones”, se cumple actualmente en la aplicación y presenta un caso de uso asociado
denominado “Ejecutar Transacción Droguería Nena”, que representa la situación específica para las
recaudaciones asociadas el cliente al que se le realizó el nuevo módulo. La descripción exacta del mismo
se encuentra definida igualmente en el documento ERS de la nueva arquitectura.
Por último, surgió un nuevo caso de uso denominado “Mostrar Versión” que representa la acción
a través de la cual el usuario puede validar el tamaño y fecha de actualización del Build instalado en su
máquina. Este caso de uso se encuentra asociado al escenario número 19 que se encuentra descrito en
el UT.
203
Evaluación Arquitectónica de Visual Banker
DAS Propuesto – Nuevo Desarrollo
Versión: 1.0
Fecha: 25/08/2006
5. Vista Lógica
5.1 Visión general
Una vez finalizado el proceso de evaluación arquitectónica se llevó a cabo la implementación de
un porcentaje de los cambios propuestos. Durante esta etapa se generaron nuevas clases, atributos y
procedimientos que de alguna manera afectaron la vista lógica inicial de Visual Banker. El objetivo de la
siguiente sección es documentar los cambios producidos en cada uno de los módulos, mostrando para
ello las clases nuevas que fueron creadas así como aquellas clases que se vieron afectadas por el nuevo
desarrollo. De igual manera se mostrarán los atributos asociados a cada clase, así como los
procedimientos o funciones que las mismas poseen y que son relevantes para el proyecto.
Las modificaciones estarán enfocadas hacia los escenarios que fueron implementados y cómo
los mismos afectaron a cada uno de los módulos.
Módulo de Taquilla
Este módulo se vio afectado como consecuencia de la implementación de las decisiones
arquitectónicas propuestas para los tres escenarios del árbol de utilidad que fueron implementados. El
primero de ellos relacionado con la característica de Seguridad, el segundo con la característica de
Ajuste a los Propósitos y el tercero con la característica de Facilidad de Instalación. A continuación se
presenta las modificaciones como consecuencia del desarrollo realizado.
Escenario # 11: se requiere que los cambios en los passwords de los usuarios se realicen
constantemente y que su deducción sea difícil.
La solución para este escenario se basó en la implementación de mecanismos que garantizaran
la creación de claves robustas y que validaran constantemente que la clave del usuario no se encontrara
vencida. El tiempo de expiración de la misma se manejó como un parámetro configurable por no
conocerse de antemano el impacto que podría tener la implantación de estos mecanismos dentro de las
agencias. A continuación se presenta el modelo a través del cual se muestran las clases modificadas.
204
Evaluación Arquitectónica de Visual Banker
DAS Propuesto – Nuevo Desarrollo
Versión: 1.0
Fecha: 25/08/2006
Figura Modelo Lógico Modificado – Módulo Taquilla
Descripción de las clases
BcOperadorTaquilla
Descripción
Atributo
Representa al usuario que tiene acceso al módulo
En esta clase se agregó el atributo FechaCreacion
de Taquilla.
a través del cual es posible determinar si la clave
del usuario se encuentra vencida.
BcOperadorTaquillaDBConverter
Descripción
Métodos
Clase a través del cual se realizan las consultas
convertirRegistro(): permite leer las columnas de
que permiten leer de la Base de Datos así como
la tabla usuarios y asignar los valores de los
actualizar la misma.
atributos a un objeto de tipo BcOperadorTaquilla.
convertirModelo(): permite actualizar todas las
columnas de la tabla usuario una vez que los
atributos fueron modificados.
BcLoginView
Descripción
Métodos
Forma gráfica a través de la cual el usuario puede
verificaOperador(): método a través del cual es
loguearse para tener acceso a la taquilla,
posible validar que el usuario que está ingresando
suministrando su USERID y PASSWORD.
es válido. Aquí se realiza la verificación de que la
clave no se encuentra vencida.
BcCambiarPasswordView
Descripción
Métodos
Forma gráfica a través de la cual, cualquier
validarPassword(): método a través del cual se
usuario puede hacer el cambio o actualización
validad que la nueva clave seleccionada por el
205
Evaluación Arquitectónica de Visual Banker
DAS Propuesto – Nuevo Desarrollo
de su clave.
Versión: 1.0
Fecha: 25/08/2006
usuario sea robusta. Este método fue creado desde
cero pues anteriormente no existía.
actualizarPassword(): método a través del cual se
hace la actualización de la nueva clave del usuario.
Escenario # 17: se requiere que todos los requerimientos de funcionalidad que presenta la aplicación se
encuentren cubiertos.
Este escenario se enfocó en el desarrollo de la funcionalidad correspondiente a “Pago de
Servicios – Recaudaciones” que no se encontraba cubierta para un cliente específico denominado
“Droguería Nena”. En la figura que se muestra a continuación se presenta una parte del modelo lógico de
Taquilla que engloba las clases que fueron creadas y las que fueron modificadas.
Figura Modelo Lógico Modificado – Módulo Taquilla
206
Evaluación Arquitectónica de Visual Banker
DAS Propuesto – Nuevo Desarrollo
Versión: 1.0
Fecha: 25/08/2006
Descripción de las clases
BcCodigoClienteDocImporteForm
Descripción
Atributos
Métodos
Clase que contiene los diferentes
CodigoCliente: código del
CalcularSubtotal(): método a
campos solicitados cuando se va
cliente que realiza la operación.
través del cual es posible
a realizar un depósito propio
NumDocumento: número del
calcular el subtotal que va a ser
correspondiente a “Droguería la
documento o factura a cancelar
cancelado por el cliente.
Nena”. Representa una interfaz,
por el cliente.
EliminarContainer(): método
una clase gráfica.
Importe: importe manejado en
que permite eliminar elementos
la operación, asociado a un
del contenedor.
documento.
IngresarContainer(): método a
Registros: arreglo que contiene
través del cual se agregan los
los pares correspondiente a
elementos al contenedor.
documento e importe.
Permite una inserción máxima
de 4 elementos.
LimpiarCampos(): limpia
todos los campos de la forma.
ValidarCódigoCliente():
verifica que el código del
cliente sólo sean números y
posea una longitud exacta de 5
dígitos.
ValidarDocumento(): verifica
que el documento sólo sean
números y posea una longitud
exacta de 11 dígitos.
ValidarImporte(): verifica que
no se pueda agregar un
documento al container sin
tener un importe asociado.
BcDepositosPropioPagoMultiplesModel
Descripción
Atributos
Métodos
Modelo a través del cual se
CodigoEmpresa: código de la
ArmarListaRegistrosEnvioDN
registran todos los atributos que
empresa.
(): permite armar la lista de los
van a ser enviados al AS400 y
CodigoCupon: código del
registros que van a ser
207
Evaluación Arquitectónica de Visual Banker
DAS Propuesto – Nuevo Desarrollo
Versión: 1.0
Fecha: 25/08/2006
que van a ser recibidos como
cupón a través del cual se hace
enviados al AS400 para cada
respuesta. Es una clase de
la transferencia.
uno de los casos de las formas
comunicación.
Nacionalidad: nacionalidad del
de pago. Es específico para
cliente.
Droguería la Nena.
CedulaRif: cédula o rif del
Inicializar(): permite inicializar
cliente, según aplique.
los registros del modelo, tanto
NombreEmpresa: nombre de la
el lo referente a documento
empresa.
como a importe.
CuentaEmpresa: número de
MapperRegistroDN(): permite
cuenta de la empresa.
inicializar los atributos
Referencia: referencia.
comunes que tienen los
Monto: monto de la transacción.
registros de las diferentes
MontoTotal: monto total de la
formas de pago.
transacción.
Rellenar(): permite inicializar
los atributos de los registros
que son comunes para todas
las formas de pago.
ArmarListaRegistrosRecibid
os(): permite ubicar a cada uno
de los registros en el grupo
correspondiente que contiene
los datos que van a ser
otorgados como respuesta por
parte del servidor.
AlgoritmoModulo11():
algoritmo suministrado por el
cliente que permite validar que
el Código de Cliente
introducido es correcto.
BcDepositosPropioPagoMultiplesForm
Descripción
Clase general que contiene las
diferentes formas reusables de los
clientes que poseen un módulo de
depósito propio dentro del banco.
208
Atributos
Métodos
Evaluación Arquitectónica de Visual Banker
DAS Propuesto – Nuevo Desarrollo
Versión: 1.0
Fecha: 25/08/2006
En ella está incluida la forma de
“Droguería la Nena”.
BcDepositosPropioPagoMultiplesView
Descripción
Atributos
Métodos
Atributos
Métodos
Corresponde a la clase que
representa a la interfaz de
depósitos propios (recaudaciones)
y que contiene a la forma
“BcDepositosPropioPagoMultiples
Form”.
BcReg3296E
Descripción
Clase correspondiente al registro
CodigoEmpresa, CodigoCliente,
Se generaron los métodos de
3296E en la cual se especifica
Referencia, Efectivo, Monto.
GET y SET correspondientes
que debe enviarse al servidor en
para cada atributo.
la transacción cuando la forma de
pago es Efectivo/Cheque.
BcReg3296R
Descripción
Atributos
Métodos
Clase correspondiente al registro
NombreEmpresa,
Se generaron los métodos de
3296R en la cual se especifica
CuentaEmpresa, ImpuestoAIDb
GET y SET correspondientes
que debe recibirse desde el
(impuesto al debido bancario).
para cada atributo.
servidor cuando la forma de pago
es Efectivo/Cheque.
BcReg3297E
Descripción
Atributos
Métodos
Clase correspondiente al registro
Empresa, CodigoCliente,
Se generaron los métodos de
3297E en la cual se especifica
Nacionalidad, CedulaRif:
GET y SET correspondientes
que debe enviarse al servidor
NumeroCuenta, Referencia,
para cada atributo.
cuando la forma de pago es
Monto.
Cargo en Cuenta.
209
Evaluación Arquitectónica de Visual Banker
DAS Propuesto – Nuevo Desarrollo
Versión: 1.0
Fecha: 25/08/2006
BcReg3297R
Descripción
Atributos
Métodos
Corresponde a la clase a través
NombreEmpresa,
Se generaron los métodos de
de la cual se recibe la respuesta
CuentaEmpresa,
GET y SET correspondientes
del AS400 para el caso en el que
NombreCliente, ImpuestoAIDb
para cada atributo.
la forma de pago es Cargo en
(impuesto al débito bancario).
Cuenta. Representa al registro
3297R.
BcReg3298E
Descripción
Atributos
Métodos
Clase correspondiente al registro
CodigoEmpresa, CodigoCliente,
Se generaron los métodos de
3298E en la cual se especifica
Monto,Indicador, Documento1,
GET y SET correspondientes
que debe enviarse al servidor
Importe1, Documento2,
para cada atributo.
cuando la forma de pago es
Importe2, Documento3,
Cheque Otros Bancos. Los
Importe3, Documento4,
campos correspondientes a
Importe4, MontoTotalImporte.
Importe y Documento siempre
viajan independientemente de
que esta forma de pago sea
seleccionada, el indicador es el
que informa si Cheque Otros
Bancos fue seleccionado o no.
BcReg3298R
Descripción
Atributos
Métodos
Corresponde a la clase a través
NombreEmpresa: nombre de la
Se generaron los métodos de
de la cual se recibe la respuesta
empresa.
GET y SET correspondientes
del AS400 para el caso en el que
CuentaEmpresa: cuenta
para cada atributo.
la forma de pago es Cheque
bancaria de la empresa.
Otros Bancos. Representa al
registro 3298R.
Escenario # 19: ocurre una falla en el refrescamiento de una de las máquinas de una agencia.
En la figura que se presenta a continuación se muestra la clase afectada después de realizar la
210
Evaluación Arquitectónica de Visual Banker
DAS Propuesto – Nuevo Desarrollo
Versión: 1.0
Fecha: 25/08/2006
implementación para este escenario. La solución se basó en crear una ventana de mensaje que
permitiera a los usuarios saber el tamaño y la fecha de creación del Build que tenían instalado en su
máquina para poder determinar si se instaló la versión correcta o no.
Figura Clase Modificada – Módulo Taquilla
BcMenu PrincipalView
Descripción
Métodos
Esta clase representa el menú principal del módulo
mostrarVersion(): método a través del cual se
de taquilla. Es una clase gráfica donde se encuentra
lee de la base de datos el tamaño y fecha de
definido el botón que debe ser presionado para ver
creación del Build instalado y se muestra el
el mensaje con la información sobre el Build.
mensaje al usuario con dicha información para
poder determinar si se llevó a cabo o no la
actualización en su máquina.
Módulo de Plataforma
En esta oportunidad el módulo de Plataforma sólo se vio afectado por la implementación de las
soluciones para los escenarios número 11 y número 19. A continuación se presentan las clases creadas
o modificadas en cada uno de los casos.
Escenario # 11: este ya se encuentra completamente implementado y operativo.
Escenario # 19:
Figura Modelo Lógico Modificado – Módulo Plataforma
211
Evaluación Arquitectónica de Visual Banker
DAS Propuesto – Nuevo Desarrollo
Versión: 1.0
Fecha: 25/08/2006
BaAhorroProgramadoView
Descripción
Métodos
Forma visual a través de la cual se muestran
registerServices(): método a través del cual
diferentes opciones contenidas en el módulo de
es posible registrar los servicios que van a
plataforma.
estar presentes en esta forma.
BcAhoProgAfiliacionView
Descripción
Métodos
Forma visual a través de la cual se muestran
versión(): método que permite leer del archivo
diferentes opciones contenidas en el módulo de
“.ini” el tamaño y fecha del Build instalado en
plataforma.
cada una de las máquinas para poder
determinar si la actualización fue efectiva.
De igual manera, es importante mencionar que el archivo “.ini” mencionado anteriormente se creó
para ser utilizado tanto en el módulo de Taquilla como en el de Plataforma. A través del mismo se lee la
información correspondiente al tamaño y fecha de creación del Build instalado en cada máquina. Dicho
archivo, denominado “version.ini”, va a ser distribuido junto con la nueva versión del Build en todas las
agencias.
Mantenimiento
El módulo de mantenimiento sólo se vio afectado por la implementación de la solución
correspondiente al escenario número 11. En el mismo lo que se hace es actualizar la fecha de creación
de una clave que haya sido modificada o creada por el administrador fuera de los módulos de Taquilla o
Plataforma, para garantizar de esta manera que el usuario pueda entrar al sistema. Si esta actualización
no se lleva a cabo, el usuario siempre tendrá una clave vencida.
5.2 Paquetes de Diseño Arquitectónicamente Significativos
En el documento de Arquitectura original se presentaron los paquetes correspondientes a cada
uno de los módulos que conforman la aplicación (Taquilla, Plataforma y Mantenimiento), además de los
paquetes generales correspondientes a las Formas, Views y Modelos. Sin embargo, varios de los
paquetes mostrados en el modelo inicial se vieron afectados una vez que se llevó a cabo el proceso de
212
Evaluación Arquitectónica de Visual Banker
DAS Propuesto – Nuevo Desarrollo
Versión: 1.0
Fecha: 25/08/2006
implementación de nuevas clases o modificación de clases ya existentes dentro de los mismos. De igual
manera, otros paquetes que no fueron considerados inicialmente también sufrieron algún tipo de
modificación.
El objetivo de esta sección es mostrar el efecto producido en cada paquete una vez que se llevó
a cabo el desarrollo de las soluciones propuestas durante la evaluación arquitectónica.
Paquetes de Taquilla
En esta oportunidad se consideró importante profundizar un poco más en la constitución del
paquete correspondiente a Taquilla que fue presentado en el DAS inicial de Visual Banker, ya que varios
de los paquetes que lo componen se vieron afectados al realizar la implementación. Ese es el caso de los
paquetes correspondientes a BaTaquillaModels (que contiene todos los modelos pertenecientes al
módulo de Taquilla; es decir, las clases empleadas para la comunicación), BaTaquillaViews y
BaTaquillaForms, los cuales contienen las interfaces y las formas reusables respectivamente. Alguno de
ellos se vieron afectados por la creación de nuevas clases dentro de los mismos, otros se vieron
afectados por la modificación de clases ya existentes. Otro de los paquetes generales que se vio
afectado es el que corresponde a BaTellerRecords, en el cual se guardan todos los registros con los
atributos que van a ser enviados por la aplicación y recibidos como respuesta por parte del AS400. En el
mismo fueron creados un grupo de clases que representaban los registros correspondientes a las
diferentes formas de pago para el depósito propio de “Droguería la Nena”.
De manera más específica, dentro del paquete correspondiente a Modelos, se modificó la clase
“BcDepositosPropioPagoMultiplesModel”, en el paquete de Formas se creó una clase nueva denominada
“BcCodigoClienteDocImporteForm”
y
“BcDepositosPropioPagoMultiplesForm”,
se
en
modificó
el
paquete
la
de
clase
Vistas
correspondiente
se
modificó
la
a
clase
“BcDepositosPropioPagoMultiplesView” y por último, en el paquete correspondiente a registros se
agregaron las clases denominada “BcReg3296E”, “BcReg3296R”, “BcReg3297E”, “BcReg3297R”,
“BcReg3298E” y “BcReg3298R”.
Como consecuencia de la implementación de los otros escenarios, también fueron modificadas
otras clases dentro del paquete BaTaquillaViews, dichas clases corresponden específicamente a
213
Evaluación Arquitectónica de Visual Banker
DAS Propuesto – Nuevo Desarrollo
Versión: 1.0
Fecha: 25/08/2006
BcMenuPrincipalView, BcLoginView y BcCambiarPasswordView. El paquete correspondiente a
BaTellerGeneralClasesRIBS se vio afectado cuando se realizó la implementación del escenario
correspondiente a los “passwords robustos”. Dicho paquete se compone a la vez de otra serie de
paquetes, pero los que fueron modificados en esta oportunidad se refieren a BaModelsRIBS
(específicamente se cambió la clase BcOperadorTaquilla) y BaDataBaseAccessSupportVersionCANTV
(donde se modificó la clase BcOperadorTaquillaDBConcerter). En la figura que se presenta a
continuación, se muestra la representación gráfica de todos los paquetes que se vieron afectados.
Figura Paquetes Arquitectónicamente Significativos de Taquilla [Elaboración propia]
Paquetes de Plataforma
El paquete modificado en esta oportunidad corresponde a BaAhorroProgramadoView, la clase
afectada dentro del mismo se refiere a BcAhoProgAfiliaciónView. Es en esta clase donde se realizaron
las modificaciones correspondientes al escenario de la versión.
6 Vista de Procesos
N/A ya que en el sistema no existe concurrencia.
7 Vista de Implantación
Se mantiene igual que en el documento de arquitectura inicial de Visual Banker.
214
Evaluación Arquitectónica de Visual Banker
DAS Propuesto – Nuevo Desarrollo
Versión: 1.0
Fecha: 25/08/2006
8 Vista de Implementación
Se mantiene igual que en el documento de arquitectura inicial de Visual Banker.
9 Calidad
Se mantiene igual que en el documento de arquitectura inicial de Visual Banker.
215
Evaluación Arquitectónica de Visual Banker
Pantallas Desarrolladas
Versión: 1.0
Fecha: 25/08/2006
APÉNDICE I - Pantallas desarrolladas
1)Droguería Nena: pantalla principal de acceso a recaudaciones, pertenece al módulo de Taquilla.
2)Droguería Nena: pantalla de recaudaciones, seleccionando la opción de Droguería la Nena.
216
Evaluación Arquitectónica de Visual Banker
Pantallas Desarrolladas
Versión: 1.0
Fecha: 25/08/2006
3) Droguería Nena: llenando los datos solicitados por el formulario (código de cliente, # documento,
importe)
4) Droguería Nena: llenando los datos el formulario, en la parte correspondiente a pagos.
217
Evaluación Arquitectónica de Visual Banker
Pantallas Desarrolladas
Versión: 1.0
Fecha: 25/08/2006
5) Droguería Nena: opción de pago por Cargo en cuenta, se llenan los datos solicitados por el
formulario.
6) Droguería Nena: error en el pago Cargo en Cuenta, el código de cliente introducido no es válido.
218
Evaluación Arquitectónica de Visual Banker
Pantallas Desarrolladas
Versión: 1.0
Fecha: 25/08/2006
7) Droguería Nena: error en Código de Cliente, el valor introducido no es válido. Fue verificado con el
algoritmo Módulo11.
8) Droguería Nena: error al enviar la transacción, el monto correspondiente a Subtotal y Total no
concuerdan.
219
Evaluación Arquitectónica de Visual Banker
Pantallas Desarrolladas
Versión: 1.0
Fecha: 25/08/2006
9) Droguería Nena: antes de enviar la transacción como Cargo en Cuenta el sistema pregunta si se
desea consultar la firma del cliente.
10) Droguería Nena: opción de pago por Cheque Otros Bancos, se llenan los datos solicitados en el
formulario.
.
220
Evaluación Arquitectónica de Visual Banker
Pantallas Desarrolladas
Versión: 1.0
Fecha: 25/08/2006
11) Droguería Nena: opción de pago con Efectivo/Cheque del Banco, se valida que todos los datos
estén completos.
12) Droguería Nena: opción de pago con Efectivo/Cheque del Banco, se llenan todos los datos
solicitados por el formulario.
221
Evaluación Arquitectónica de Visual Banker
Pantallas Desarrolladas
Versión: 1.0
Fecha: 25/08/2006
13) Droguería Nena: se valida que la referencia introducida no se encuentre duplicada.
14) Droguería Nena: todas las opciones de pago seleccionadas. Se llenan los datos de todos los
formularios.
222
Evaluación Arquitectónica de Visual Banker
Pantallas Desarrolladas
Versión: 1.0
Fecha: 25/08/2006
15) Droguería Nena: se llenan todos los datos solicitados en los formularios de las diferentes formas de
pago.
16) Droguería Nena: validación del número de documento introducido. El # documento NO puede estar
repetido.
223
Evaluación Arquitectónica de Visual Banker
Pantallas Desarrolladas
Versión: 1.0
Fecha: 25/08/2006
17) Droguería Nena: validación, la longitud del campo # documento debe ser exactamente 11 dígitos.
18) Droguería Nena: validación, la longitud del campo Código Cliente debe ser exactamente 5 dígitos.
224
Evaluación Arquitectónica de Visual Banker
Pantallas Desarrolladas
Versión: 1.0
Fecha: 25/08/2006
19) Droguería Nena: validación, el campo importe obligatorio, no se puede ingresar un documento sin un
importe.
20) Droguería Nena: validación, no se pueden agregar más de cuatro elementos (pares #documento,
importe).
225
Evaluación Arquitectónica de Visual Banker
Pantallas Desarrolladas
Versión: 1.0
Fecha: 25/08/2006
21) Passwords: ventana de inicio de sesión en taquilla y ventana de validación de la clave introducida.
22) Passwords: ventana de validación de clave vencida, ventana para realizar el cambio de clave.
23) Passwords: ventanas de validación de clave robusta.
24) Passwords: ventana de validación de clave robusta, ventana de verificación de clave nueva y
confirmación.
226
Evaluación Arquitectónica de Visual Banker
Pantallas Desarrolladas
Versión: 1.0
Fecha: 25/08/2006
25) Passwords: una vez validada la clave es posible ingresar a Taquilla; también puede ser cambiada la
clave por el usuario de forma directa sólo con presionar el botón Password ubicado en la pantalla
principal de Taquilla (imagen de la derecha).
227