A continuación, se describen los resultados que arrojó el

desarrollo del Sistema Integral según las fases descritas en el

capitulo anterior, las cuales estuvieron sustentadas por la

metodología de Senn (1992) y Kendall (1991).

Fase 1: Determinación de Problemas, Oportunidades y

Objetivos.

La solicitud para recibir ayuda de un sistema puede

originarse por varias razones; sin importar cuales sean éstas,

el proceso se inicia siempre con la petición de una persona,

administrador, empleado o especialista en sistemas (Senn,

1999).

En éste caso la petición de ayuda para la solución de los

problemas en el área de operaciones del BOD mediante un

sistema, se originó de un especialista asesor de la institución,

quien conoce perfectamente la situación actual y las

dificultades que atraviesa la empresa, siendo éste aspecto de

gran importancia a la hora de diseñar o desarrollar una

aplicación, debido a que, para dar comienzo a un proyecto

debe examinarse con claridad lo que el solicitante desea, con

la finalidad de llevar a cabo la petición con las ideas

98
 99

totalmente analizadas y evaluadas para contribuir a un mejor

desempeño durante el desarrollo del sistema.

Una vez entendido el problema presentado desde la

perspectiva de dicho especialista, se realizaron

recomendaciones que no fueron expuestas en la solicitud del

sistema, pero, que ayudarían a mejorar aspectos en cuanto a

la integración de susbsistemas y la automatización de

procesos que optimizarían los tiempos de respuestas a los

problemas presentados en algún momento.

Por otra parte, los objetivos perseguidos por la

organización con la realización del sistema y por consiguiente

con la solución de los problemas, son los siguientes:

• Servir de apoyo a los operadores.

• Minimizar los tiempos de atención de los servicios

prestados por la institución.

• Ofrecer una forma más fácil y efectiva para los

operadores de captar los problemas inherentes a la

plataforma que controla lo relacionado con el dinero

electrónico de la institución.
 100

Factibilidad Técnica.

El desarrollo del Sistema Integral en el Banco Occidental

de Descuento es técnicamente factible, ya que, la institución

cuenta con todos los equipos y herramientas necesarias tanto

de hardware como de software para instrumentar una

solución ajustada a los requerimientos de la situación

planteada.

Factibilidad Económica.

El Banco Occidental de Descuento como institución con

avanzada tecnología computacional cuenta con los equipos

necesarios para el desarrollo del Sistema, los cuales fueron

colocados a total disposición para la realización de éste

proyecto. Lo que indica que la inversión para tal fin es

mínima en comparación con los beneficios que el Sistema

Integral brindará tanto a los Operadores de Aplicaciones como

a los de Telecomunicaciones, entre estos se encuentran:

captar los problemas de forma rápida y entendible brindando

soluciones automatizadas que disminuyan los tiempos de

respuesta y el margen de error humano.

 101

A continuación se muestran los recursos usados y costos

asociados tanto de hardware como de software, así como

también, adiestramientos y mantenimiento del sistema.

Recursos de Hardware.

TABLA #4. Hardware y costos asociados.

HARDWARE COSTO

Computador Personal DELL, con 64Mb de

memoria RAM, Monitor 14”, Disco Duro 6Gb,

Procesador Pentium III 500 Mhz. 1142,8 $

Servidor Himalaya NSK (NonStop Kernel)

modelo S7000, con 512 Mb de memoria RAM, 2

Procesadores Multifuntion, 5 Discos Internos de

los cuales 3 son de 4,2 Gigabyte y 2 son de 8,8

Gigabyte, 1 unidad de cinta y cartuchos, 2 350.000 $

controladores Ethernet, 2 controladores Token

Ring, Sistema de consola, 4 concentradores

WAN.

Sistema Operativo Guardian y todos sus

componentes.
 102

Recursos de Software.

TABLA #5. Software y costos asociados.

SOFTWARE COSTO

Windows 95 28,5 $

Windows 2000 57,14 $

Outside View 332,85 $

Adiestramiento.

Para la realización del Sistema Integral, se invirtió una

gran cantidad de tiempo (1 año) y dinero, en el aprendizaje de

las distintas herramientas de desarrollo de aplicaciones y el

conocimiento de todos los aspectos que intervienen en los

procesos de la institución. Durante ese año la empresa aportó

90.000 Bs, mensuales con motivo de la realización del

proyecto y 10.000 Bs mensuales por gastos de papelería.

Expresado de la siguiente manera: (90.000 Bs + 10.000 Bs x

12 meses), significa que el Banco Occidental de Descuento

invirtió 1.200.000 Bs, en el aprendizaje de los recursos

necesarios para realizar el sistema integral.

También, como parte del desarrollo de la investigación, a

los usuarios del sistema se les brindará un adiestramiento

 103

completo sobre el funcionamiento del mismo, el cual no

tendrá costo alguno.

Mantenimiento.

El mantenimiento del sistema integral no requiere de

ningún aporte de dinero especial ya que se hará por el

personal interno de la institución, por lo que, en función a los

costos anteriormente mencionados se establece que el

Sistema Integral requiere una inversión sumamente alta,

pero, dado que la empresa cuenta con todo el recurso

necesario como se dijo anteriormente, el proyecto se hace

económicamente factible.

Factibilidad Operacional.

En muchos casos la resistencia que se tiene al cambio es

inevitable, principalmente, por el miedo que se siente a lo

desconocido, pero en esta ocasión, la forma operativa de llevar

los procesos cambia muy poco, y precisamente esas

diferencias son las que favorecen el trabajo de los operadores,

debido a que la aplicación está desarrollada para brindar

soporte en el cumplimiento efectivo de las labores diarias que

se manejan en el banco, tanto en el área de aplicaciones como

 104

en la de telecomunicaciones. Es por eso que el Sistema

Integral es operacionalmente factible.

Fase 2: Determinación de los requerimientos del sistema.

En ésta fase se realizaron una serie de visitas al área de

operaciones del BOD y utilizando como herramientas el

cuestionario y la entrevista, se interactuó en gran medida con

las personas que laboran en esa área (Operadores), con la

finalidad de captar y detallar un poco mas las necesidades y

requerimientos de la institución. Además, los operadores

ofrecieron su punto de vista del problema, el cual, vale

destacar es de mucha importancia para el correcto diseño del

sistema por ser a ellos los futuros usuarios directos del

mismo.

Para examinar en detalle los requerimientos del sistema se

realizó un pequeño cuestionario tomado de Senn(1999), que

fue presentado a los operadores tanto de operaciones como de

aplicaciones y aplica para todos los procesos que se realizan

en dichas áreas, algunas de éstas preguntas fueron:

1. ¿Qué es lo que se hace?

2. ¿Cómo se hace?

3. ¿Con que frecuencia se presenta?

 105

4. ¿Qué tan grande es el volumen de transacciones?

5. ¿Cuál es el grado de eficiencia con el que se efectúan las

tareas?

6. ¿Existe algún problema?

7. Si existe algún problema. ¿qué tan serio es?

8. ¿Cuál es la causa que origina el problema?

9. ¿Cuáles son las hasta ahora soluciones aplicadas a los

problemas?

Para contestar dichas preguntas fue necesario conversar

con varias personas para reunir detalles relacionados con los

procesos de la empresa, sus opiniones sobre por que ocurren

las cosas, las soluciones que proponen y sus ideas para

cambiar el proceso. Asimismo, para detallar la investigación

se requirió el estudio de los manuales de Base24 y ICE, la

observación en condiciones reales de las actividades de

trabajo, así como, en algunas ocasiones, muestras de formas,

documentos con el fin de comprender el proceso en su

totalidad.

Conforme se reunieron los detalles, se verificaron los

requerimientos tanto a nivel administrativo como en el ámbito

técnico, con la finalidad, de identificar las características que

debía tener el sistema, incluyendo la información que debe

 106

producir junto con características operacionales tales como

controles de procesamiento, tiempo de respuestas y métodos

de entrada y salida.

A nivel Administrativo:

Se requiere un Sistema Integral, que tenga la capacidad de

centralizar en una sola aplicación todos los susbsistemas que

controlan el ambiente de banca electrónica.

A nivel Técnico:

Es necesaria la automatización de los procesos que

envuelve n al departamento de operaciones del Banco

Occidental de Descuento, tales como:

• Mantener operativos y en funcionamiento los servicios de

banca electrónica prestados por la institución, además, de

reducir el tiempo de respuesta en la atención de los

mismos.

• Proporcionar una forma más amigable y sobre todo

entendible de captar los problemas en el área de

operaciones.

• Brindar soporte a los operadores mediante mensajes que

 107

indiquen lo que está sucediendo y las acciones a tomar en

un momento dado.

• Resolver las dificultades operativas de banca electrónica,

mediante el sistema integral y dejando solo los problemas

de carácter físico a los operadores.

La información anteriormente mencionada permitió que el

sistema integral cumpliera de forma optima y eficaz con todos

los requisitos expuestos por el Departamento de Operaciones

del Banco Occidental de Descuento.

Fase 3: Diseño del Sistema.

Como se hizo referencia en el capitulo anterior, los

especialistas llaman a esta etapa Diseño Lógico del Sistema,

donde comienza, entre otras cosas, el proceso de entender, así

como, analizar de que manera son procesados, almacenados,

distribuidos los datos, el flujo y los requerimientos de

procesamiento de los mismos.

Para tal fin, se hizo necesario comprender la arquitectura

de mensajería y producción de eventos basados en la

plataforma de sistemas bajo ambiente NSK (Non-Stop Kernel)

que maneja la institución, la cual, sustentado en previas

 108

investigaciones realizadas en el manual electrónico de

Compaq EMS Components and architecture (2000), consiste en

un grupo de susbsistemas desarrollados para cumplir

funciones muy puntuales, bien sea de monitoreo, control o

administración que informan sobre todas sus operaciones a

un ente central denominado como Log de mensajes ó log de

eventos.

La función principal de éste log de mensajes ó log de

eventos, es almacenar y dar a conocer todo lo que esta

sucediendo bajo el ambiente NSK que maneja todo lo

referente a la banca electrónica de la institución, además, de

ser fuente de información para los operadores y entrada de

datos principal para el Sistema Integral, es decir, el mismo se

encarga de recoger toda la data producida en el log de eventos

para su posterior procesamiento y/o análisis.

Una vez entendido esto, el diseño comenzó precisamente

en mejorar la estructura y formato a los eventos producidos

en el log, dado que los mismos son poco entendibles y

estructuralmente desorganizados.

Diseño de Eventos.
 109

El formato de los eventos, fue diseñado justificado en la

necesidad de los usuarios en cambiar el formato actual (no

entendible fácilmente) en el que se reciben los mismos, por

otra parte, nos basamos también en lo descrito por Kendall y

Kendall (1991), donde relata que debe mantenerse un

estándar en la forma en la que los eventos serán mostrados.

Para esto, además, se tomaron en cuenta las opiniones de

especialistas y operadores futuros usuarios del sistema, con

la finalidad, de cubrir con las expectativas de la organización

en cuanto a la parte visual que deben tener los mensajes.

Una vez que el Sistema Integral captura los eventos

producidos por los subsistemas y son procesados, los

mensajes cambian su formato y estructura hacia una forma

en que los operadores pueden entender de forma clara y

sencilla cualquier situación suscitada y los detalles de la

misma, dado que proporciona:

• Fecha y Hora en la que se presento el problema.

• Nombre del subsistema que genero el evento, y por

consiguiente el que necesita de atención.

• Proceso sobre el cual corre el subsistema que genero el

evento.

• Codigo de error, para su posterior documentación.

 110

• Nombre del objeto que requiere atención y sus

diferentes estados.

Especifica el objeto o la
aplicación de la cual
Campo que hace referencia al
proviene el mensaje.
objeto (en caso de existir) sobre
el cual se esta aplicando una
acción o necesita de la misma.

<> Objeto/Aplicación/Subsistema <>

Fecha/Hora: 00/12/12 21:05:02

Objeto: AAAAAAA
Proceso: $XYZ
Subsistema: XXXX-XXX-XX
Estado Actual: $$$$$$$$ From: xxxxxxx
Codigo : 1111111 Estado Previo: &&&&&&& Re: zzzzzzz

Identifica del error mediante un Origen y destino del mensaje

numero. (Depende del subsistema que
Muestra el subsistema que envía emita el mensaje).
el evento al logger.
Especifica el nombre del proceso
sobre el cual corre la entidad que Campos que identifican las
envia el mensaje. maquinas de estado de los
objetos.
Muestra la fecha y hora en la que
el evento fue producido.

FIGURA #18. DISEÑO DEL FORMATO DE EVENTOS.

Se diseñaron 2 tipos de mensajes, el primero fue el

presentado anteriormente, el cual es un mensaje netamente

informativo, el segundo, es un tipo de mensaje de alerta el

cual mantiene el mismo formato que el mensaje informativo

solo que cambia de color de tal manera que llame la atención

de los operadores cuando sea necesario. El mensaje de alerta,

presenta información mucho más especifica sobre lo que está

sucediendo y las medidas a tomar.

Diseño de la Base de Datos:

 111

Se diseño una base de datos, sustentados en la creación

de archivos convencionales que explica Kendall y Kendall

(1991), para almacenar la configuración que en ese momento

tienen los cajeros automáticos y sus líneas de comunicación,

que contempla los siguientes campos:

TABLA #6. Definición de campos de la base de datos.

CAMPOS TAMAÑO Y TIPO DESCRIPCIÓN

ESTAC ION. Carácter. Nombre lógico de la

10 estación o ATM
LINEA LOGICA Carácter. Identifica el medio
20 lógico por medio del
cual las estaciones
conversan.
PU (Unidad Física) . Carácter. Controlador físico
10 de las estaciones,
basado en
comunicaciones
SNA.
LINEA FÍSICA Carácter. Identifica el medio
10 netamente físico,
configurado
asíncronamente
para permitir el
flujo de datos entre
el ATM y el S7000.
PUERTO DEL ZWAN Carácter. Identifica el puerto
(Concentrador 10 donde se
WAN). encuentran
conectadas las
líneas físicas.

Una vez que el sistema integral se ejecuta, recoge toda

esta información la cual es necesaria para poder atender los

 112

problemas en cuanto a cajeros automáticos se refiere: caídas

de estación, línea lógica, línea física, entre otros, el resto de

los procesos atendidos por el sistema integral no se

establecen mediante una base de datos, sino que son

elementos tomados en línea desde el computador central

S7000.

Vale destacar, que el lenguaje utilizado para manejar esta

herramienta no opera bases de datos, por lo que la

información anteriormente mencionada es almacenada en un

archivo editable para su fácil recuperación. Este fue uno de

los principales problemas presentados a la hora de diseñar

dicha base de datos, dado que se tuvo que crear una pequeña

aplicación la cual se incluyó como parte del sistema integral,

que se encargara de recolectar toda esa información.

Diseño de la Interfaz.

Como lo describe Kendall y Kendall (1991), existen varios

tipos de interfaces para usuarios, que incluyen las de

Lenguaje Natural, las consultas de preguntas y respuestas,

menúes, formas de entrada/salida, el lenguaje por comandos

y el manejado con el mouse.

 113

El diseño de la interfaz del sistema integral se creó en un

ambiente poco agradable visualmente, esto, por las

restricciones gráficas tanto del sistema operativo Guardian

como de la herramienta de programación TACL, pero

funcional en un alto porcentaje, dada la robustez y

flexibilidad del lenguaje.

El uso del mouse en este caso queda anulado, ya que el

sistema operativo solo utiliza el teclado y la interfaz mediante

menúes por medio del lenguaje natural, como medio de

interacción entre el usuario y el S.O, ya que el mismo esta

orientado a la forma de trabajo de otros S.O como Unix y MS-

DOS (Ver Anexos).

Diseño de Acceso al Sistema.

El diseño del acceso al sistema o seguridad del mismo, se

realiza mediante claves de acceso para ser utilizadas solo por

el personal de operaciones del Banco Occidental y el

administrador de la aplicación. (Ver Anexos)

Diseño de Diagramas de Flujo de Datos.

Una vez diseñados los formatos de salidas, mensajes, base

de datos, claves de acceso, se realizaron diagramas de flujo de

 114

cómo el sistema integral funcionaría una vez finalizada su

construcción.

Kendall (1991), maneja la creación de diagramas de flujos

de datos con la finalidad de diseñar y documentar tanto los

sistemas como los programas, además, ayuda a la

codificación del mismo dado que en ésta caso, muestra en

forma general todos los procesos, entidades y objetos que

intervienen, desde que el mensaje es capturado por el sistema

integral hasta la solución de problemas por medio del mismo

(Ver Anexos).

Fase 4: Construcción o Desarrollo del Sistema.

Según lo expresado por Senn (1992), el desarrollo de un

software puede consistir en la instalación ó modificación y

después instalación de softwares comprado a terceros, así

como también, el diseño de programas a la medida del

solicitante. La elección depende del costo de cada alternativa,

del tiempo disponible para escribir el software y de la

disponibilidad de los programadores.

Dado que el Banco Occidental de Descuento posee una

plataforma tecnológica muy particular y unos problemas en

ella muy puntuales, fue que se decidió desarrollar el software

 115

dentro de la empresa mediante herramientas previamente

adquiridas como lo es la herramienta TACL (Tandem

Advanced Command Lenguje) bajo ambiente NSK, el cual es

una lenguaje nativo del S.O Guardian. De esta forma el costo

de la aplicación disminuiría en gran cantidad y los posibles

cambios en los planteamientos iniciales se atenderían de

forma inmediata.

Una vez completada la etapa de diseño, se procedió a

realizar un análisis de construcción de software estructurado,

sustentado por Kendall y Kendall (1991), sobre la forma más

eficaz de codificar el sistema de acuerdo a las herramientas

existentes y del tiempo disponible para realizar el mismo. Una

de las primeras cosas importantes que se evaluaron y

codificaron fue la forma en la que se recibirían los eventos de

los diferentes subsistemas de la organización que controlan

los ambientes de Aplicaciones y Telecomunicaciones (Ver

Anexos).

El diagrama presenta un colector de mensajes llamado

($0), el cual, es capaz de recoger todos los eventos suscitados

tanto en el ambiente de Telecomunicaciones como en el de

Aplicaciones, es decir, en este colector se almacena cualquier

situación que ocurra en los subsistemas que manejan dichos

 116

ambientes. Los mensajes una vez almacenados en el colector

primario mediante los criterios de la arquitectura S7000,

pueden ser filtrados mediante mecanismos de S.O para

seleccionar solo la recepción de eventos de subsistemas

específicos, o bien, solo mensajes de gravedad, entre otros.

Una vez filtrados o no, los eventos pasan del colector ($0)

hacia un archivo de tipo log, donde se almacenan los datos

sin estructura alguna, para luego ser accesados por los

distribuidores. Estos últimos son de 3 tipos Fowarding,

Consumer y Printing, se encargan de enviar los mensajes

hacia sus destinos finales. Cada uno de ellos cumple con

entregar los eventos a entes diferentes, por ejemplo, el

Fowarding, esta creado para enviar mensajes a colectores

secundarios que se encuentren en otros nodos, es decir, en

forma remota.

En nuestro caso el distribuidor utilizado fue el Printing, el

mismo cumple con la función de entregar los eventos tanto a

Terminales como a Impresoras, Procesos o Archivos. El

distribuidor en este proyecto, entrega los mensajes al Sistema

Integral, donde, pasan por un proceso de formato, el cual, se

explico en la fase de diseño.

 117

Una vez que los mensajes se encuentra en poder de la

aplicación se establecieron jerarquías de los objetos tanto de

aplicaciones como de telecomunicaciones, como lo son, las

Estaciones, Líneas, Procesos, entre otros.

Mencionada jerarquía tuvo que ser implementada,

atendiendo las siguientes reglas que facilitan la codificación,

con el fin de atacar de una forma optima los problemas en el

ámbito aplicativo:

1. El objeto de más bajo nivel dentro del ambiente de

Aplicaciones son las estaciones.

2. Todas las estaciones mantienen una línea lógica de

comunicación adjuntadas a ellas.

3. Las estaciones están comunicacionalmente formadas

por elementos SNA (System Network Architecture) de

mayor nivel como lo son: los PU, RLU y APPN.

4. Tanto las lineas logicas como las estaciones, los PU,

RLU y APPN, están montados sobre una línea física

que es creada bajo los estándares del protocolo SDLC

(Control de Enlace de Datos Sincronos).

5. Dichas líneas físicas, están conectadas en un equipo

llamado ZWAN, que funciona como un conmutador

 118

wan de muy alto nivel, y es donde están conectados

todos los ATM de la institución.

Estas reglas ayudaron en gran medida en el proceso de

atención a los problemas que el sistema integral debe atender

en un momento dado, el cual se codifico en forma modular

para así atender los diferentes casos que se presenten en los

ambientes de Aplicaciones y Telecomunicaciones en forma

independiente.

Los módulos creados en el sistema propuesto son los

siguientes:

• Modulo Base24: éste modulo se encarga de atender

los requerimientos de aplicación, entendiendo como

esto, todo lo relacionado con la parte administrativa y

funcional del ambiente de banca electrónica del BOD.

Aquí se controlan en forma lógica todos los elementos

tales como: Estaciones, Líneas, Procesos, Enlaces

Lógicos, entre otros. Todo este modulo es manejado

mediante un subsistema llamado NCPCOM (Network

Control Point Communications).

• Modulo ICE: éste es el modulo encargado de manejar

toda la parte de telecomunicaciones de la institución

 119

referentes al S7000 y los elementos como ATM’s,

conectados a él. Este modulo es controlado en forma

Inline mediante 2 subsistemas llamados NOF (Node

Operator Facility) y SCF (Subsistem Control Facility),

de los cuales se hizo referencia en el capitulo 2.

En otro orden de ideas, pero siguiendo con el proceso de

construcción del software, durante la codificación del

prototipo se realizaron pruebas bajo un ambiente lógico

propio de la aplicación Base24 llamado TEST, el cual está

creado en el BOD con la finalidad de realizar pruebas de tipo

operativas y aplicativas. Dentro de este ambiente existen

cajeros, puntos de ventas, aplicaciones, líneas de

comunicación, procesos, entre otros, construidos

específicamente para evaluar las aplicaciones y nuevas

tecnologías que no afecten en lo absoluto el ambiente de

producción del banco.

Durante el desarrollo de estas pruebas se detectaron

problemas, en cuanto a la representación de ciertos

caracteres ASCII (American Standard Code for Information

Interchange) sobre los terminales, por lo que se tuvo que

recurrir a la realización de rutinas de evaluación de

caracteres de tipo ASCII, para corregir este inconveniente.

 120

Fase 5: Pruebas y Mantenimiento del Sistema.

Esta fase se dividió en 2 partes, la primera consistió en

colocar el sistema en funcionamiento bajo el ambiente TEST

anteriormente mencionado y probarlo mediante un script

(grupo de pruebas) de evaluación, el cual, se empleó para

identificar problemas en la programación del sistema, en los

mensajes y tipos de errores arrojados por el mismo, es decir,

este tipo de prueba se realizó para verificar el funcionamiento

de sistema como unidad de programación. A continuación el

script utilizado para esta fase:

1. Abortar los “PU” de una Línea de forma Abrupta.

2. Hacer que una línea quede Down, para que todas las

estaciones queden en un estado inestable.

3. Abortar el enlace con Suiche7b.

4. Terminar de forma abrupta el enlace con Consorcio

Credit Card.

5. Colocar en estado inestable uno de los puertos del

Zwan.

6. Recargar los procesadores del S7000 para observar los

mensajes de alerta.
 121

Los resultados de éstas pruebas, revelaron una deficiencia

en la manera en la que el sistema integral informa a los

operadores sobre cualquier eventualidad, dado, que la

información suministrada a los mismos es escasa, por lo que

se realizó una reestructuración de los mensajes con la

finalidad abordar con mayor exactitud y claridad la

información proporcionada a los operadores.

En la segunda fase, el sistema integral se empleó de forma

experimental, para asegurar que su funcionalidad cumpliese

con las especificaciones y trabajaría en la forma que los

usuarios esperen que lo haga, además, el mismo se alimentó

con datos de reales durante periodos de tiempo relativo

(dependiendo del tipo de prueba), y después se examinaron

los resultados de la pruebas. En algunos casos se permitió

que los usuarios utilizaran el sistema, con la finalidad de

observar si su uso se empleaba de acuerdo a la forma

prevista, pues es mejor descubrir cualquier inconveniente

antes que la organización implante el sistema y sea

dependiente del mismo.

TABLA #7. Pruebas Realizadas al Sistema Integral.

Tipo de Prueba
- Evaluación del tiempo de
respuesta del Sistema Integral.
- Estimación de los recursos de
maquina (CPU) exigidos por el
Sistema Integral sobre el S7000.
- Comunicación entre módulos.
Duración Periodicidad Resultados
* En situaciones normales donde la cantidad de
problemas es considerable el sistema responde
2 Semanas Cada 6 Meses
en un corto periodo de tiempo (segundos).
* En situaciones Extremas aumenta pero no en
forma notable el tiempo de respuesta.
* En situaciones normales el sistema consume
1 Semana de 1 a 2% de los recursos de CPU.
Cada 3 Meses
* En situaciones extremas el sistema consume
de 5 a 9% de los recursos de CPU, lo cual si se
toma en cuenta la cantidad de programas que
pudiesen estar ejecutandose en ese momento, el
consumo si es considerablemente alto.
La comunicación entre los diferentes modulos
que conforman el sistema, se realiza de forma
1 Semana Cada 6 Meses
eficiente, gracias a su estructura independiente
y unificación.
122