Metodologa para la Evaluacin del Desempeo de una

Unidad Informtica

La Metodologa que se va a exponer, constituye un conjunto de mtodos
que siguen varias reglas de interconexin y varias tcnicas que se
proponen para evaluar los sistemas de computacin. La Metodologa
nace de la necesidad de contar con una herramienta probada, que
permita a los estudiantes de ingeniera de sistemas, realizar prcticas de
evaluacin del desempeo de una unidad informtica. El trabajo expuesto
es el resultado de cuatro aos de aplicacin de tcnicas, basadas en los
estudios de Domenico Ferrari, Giuseppe Serazzi y Alessanddro Zeigner.

La Caracterizacin de la Empresa como entrada del proceso de evalua-
cin. Con un claro conocimiento del sitio de trabajo se definieron los ele-
mentos que constituyen el Objeto de la evaluacin: el Sistema de Com-
putacin (caracterizado por su carga, evaluado por sus ndices de desem-
peo y medido con las herramientas propias del sistema operativo), el
Software y los Recursos Humanos Tcnicos.

El planteamiento de la Metodologa constituir, por lo tanto, el conjunto de
pasos y acciones a seguirse para atacar el Objeto de la Evaluacin. El
Sistema de Computacin ya debe estar instalado (etapa de mejora) y se
necesita conocer la configuracin actual (topologa de la red), as como la
administracin de la red (con todos los factores involucrados como
seguridades, mantenimiento, etc.).


Identificacin para una evaluacin: necesidad y ventajas

NECESIDAD: la evaluacin de los sistemas de informacin es una actividad
fundamental, debido a la necesidad de optimizar el desempeo de los siste-
mas con la menor inversin posible. Por otro lado, siempre ser importante
conocer cmo se estn cumpliendo las metas propuestas por la organiza-
cin.

El factor econmico hace prcticamente imposible renovar constantemente
los equipos o programas, por lo que la evaluacin, cuyo objetivo fundamen-
tal es mejorar el desempeo de los sistemas de computacin, cobra mayor
importancia.







VENTAJAS:

-Permite evaluar la eficiencia y la efectividad de las aplicaciones y del
hardware existente.
-Permite optimizar el sistema de computacin desde el punto de vista de
hardware y sistema operativo.
-Permite optimizar el sistema de computacin desde el punto de vista de
seguridad y administracin de la informacin.
-Facilita el mejor aprovechamiento de los recursos de la red.
-Facilita la deteccin de cuellos de botella.
-Ayuda a mejorar el desempeo de la red: tiempos de respuesta,
balanceo de la carga, calendarizacin de actividades, control de las colas
de impresin, control de los terminales remotos, etc.
-Permite prever contingencias al poder monitorear la carga y su
tendencia, la saturacin de los componentes de la red y/o el incremento
en el nmero de usuarios.
-Da una clara idea del trabajo de los tcnicos, para ayudar a la
administracin a planificar las actividades.
-Ayuda al administrador de la red en el conocimiento del funcionamiento
de los sistemas, en relacin a los recursos instalados.


Consideraciones para el desarrollo de la Metodologa

La Metodologa no es una exposicin doctrinal completamente nueva, del
tratamiento de las evaluaciones de las redes de computacin o de los
sistemas de informacin. Se apoya en la experiencia conseguida, durante
cuatro aos, en la aplicacin de un conjunto de mtodos que ayudan a la
realizacin de las mencionadas evaluaciones.

La Metodologa guiar al novel evaluador a:
-Conocer el ambiente de trabajo y su relacin con los sistemas de
computacin.
-Obtener la informacin sobre la topologa de la red y la carga que corre en
el Sistema.
-Analizar el software de base y de aplicacin, as como las herramientas de
evaluacin disponibles.
-Investigar sobre la capacitacin, actualizacin, motivacin y dems factores
que afectan el rendimiento del recurso humano.
-Planificar las Sesiones de Medida y analizar los resultados obtenidos.
-Elaborar los informes finales con calidad.

Si bien es cierto, la mayora de los sistemas operativos usados actualmente
disponen de herramientas de ayuda para evaluar, stas se limitan al sistema
de computacin, pero descuidan factores importantes como la interaccin del
recurso humano. La Metodologa propuesta busca incluir todos los factores
adicionales en el tratamiento de la informacin del rendimiento de los
sistemas, as como la necesidad de considerar el desempeo de la
organizacin en funcin a su Plan Estratgico, es decir, en relacin a sus
objetivos planteados.

Como se ha probado en el transcurso de los aos, la Metodologa propuesta
es completamente aplicable a las nuevas tendencias de las Tecnologas de
la Informacin: Intranets, Internet y Comercio Electrnico.

Por otro lado, la tendencia actual es a contratar servicios de Outsourcing
para soporte informtico y computacional de las empresas. Tambin en estos
casos la Metodologa es til, tanto para las empresas que proveen el servicio
como para las que contratan.
Pasos que constituyen la Metodologa de Evaluacin

A.Preparacin de la Evaluacin
B.Caracterizacin de la Empresa
C.Determinacin de los objetivos de la evaluacin
D.Caracterizacin del sistema
E.Caracterizacin de la carga
F.Planteamiento de los problemas encontrados
G.Formulacin de las hiptesis
H.Planteamiento de las sesiones de medida
I.Interpretacin de los resultados
J.Elaboracin de los informes finales


A. Preparacin De La Evaluacin

La evaluacin genera un sentimiento de rechazo, aunque sea inconsciente,
en las personas que forman parte de la Unidad Informtica. Es necesario mi-
nimizar el impacto de la evaluacin:
B. CARACTERIZACIN DE LA EMPRESA

Caracterizar la empresa o institucin, significa definir claramente el mbito de
trabajo de la misma, con un conocimiento cabal de su misin, visin y
objetivos.

Descripcin Histrica
Actividades Principales y Objetivos de Automatizacin de la Empresa
La Unidad Informtica en la Organizacin


DPTO A DPTO B DPTO C DPTO D DPTO N
U.I.

DIRECTORIO
GERENCIA GENERAL


En la investigacin realizada, se encontr que el Nivel de Decisin no
corresponda al orgnico-funcional, en la mayora de los casos; es decir,
aunque en ciertas empresas estaba bien ubicada la unidad informtica,
en la prctica no tena un verdadero poder de decisin, y en otras, aunque
tena incidencia directa en las decisiones, en el orgnico funcional estaba
ubicada al mismo nivel de otros departamentos (muchas veces como parte
de otro).

Es importante que en la planificacin de la empresa est presente el
Director de la Unidad Informtica, y aunque ste debe trabajar
armnicamente con todos los departamentos o reas de la empresa; no
debera tener un orden jerrquico menor que el de otros departamentos.

II.2.4 Estructura de la Unidad Informtica

El desempeo del Sistema de Informacin depende de una buena
estructura de la Unidad Informtica, la misma est en relacin al tipo de
empresa y sus objetivos. Sin embargo, se puede considerar como una
estructura bsica la del Grfico 3:

DIRECCION
AREA DE
DESARROLLO
AREA DE
MANTENIMIENTO
AREA DE
PRODUCCION
Grfico No. 3: Estructura Bsica de la U.I.

Cuando se est evaluando el sistema de informacin, no es una buena
idea sugerir una estructura, a menos que nos sea solicitada; es ms
conveniente investigar sobre la existente en la empresa, el problema est
en no tener ninguna estructura o tener una en el papel, muy diferente a la
que se constata que existe en la prctica.

Dentro de la estructura de la Unidad Informtica es necesario definir otra
estructura, donde se tomar en cuenta, principalmente, la permanente
comunicacin e intercambio de informacin entre los usuarios beneficiarios
de los sistemas y el personal tcnico involucrado en el desarrollo de las
aplicaciones.

II.2.5 Seguridad de la Unidad Informtica

Un punto muy importante que tiene que ver directamente con el
desempeo del sistema de informacin, es la seguridad:

-Fsica, comenzando con el acceso a la Unidad Informtica, con la
correcta distribucin de los componentes de la red, con las medidas
preventivas contra problemas de salud de los empleados, incendios,
inundaciones, asaltos o sabotajes, erupciones volcnicas, etc.

-Lgica, que tiene que ver con la correcta definicin de los perfiles de
usuario, de los login y de las passwords; as como el control de acceso que
deben tener, principalmente, las aplicaciones que se manejan en la red, las
bases de datos, los archivos y el sistema de mensajera.
-Legal, como el establecimiento de seguros, de contratos de
mantenimiento y de soporte para casos emergentes.

-De datos, ya que el elemento fundamental para el funcionamiento de
todo sistema, que depende de una red de computadores, son los datos. Al
respecto se debe mencionar que, no basta sacar respaldos de los datos,
es necesario mantener una poltica de backups que incluya en relacin a
los respaldos:

-Las veces y horas en que se deben sacar.
-La forma en que se deben sacar.
-El lugar donde se deben almacenar.
-La forma en que se verificar su contenido.
-La utilizacin de los datos en simulacros, por ejemplo de prdida de
informacin.

En cuanto a las Polticas de Respaldo (ver Anexo 1) se encontr que slo
un 45.802% de las empresas las tenan.




II.2.6 Funciones de la Unidad Informtica

Aunque las funciones de la Unidad Informtica dependen, en gran
medida, del tipo de empresa, de su visin, de su misin y de sus
objetivos; es importante que entre ellas se considere (los datos que
aparecen entre parntesis corresponden a los obtenidos del Anexo 1,
de la investigacin realizada):

-Participar en la elaboracin del Plan estratgico de la Empresa.

-Elaborar el Plan Informtico que contenga la Planificacin y
Ejecucin de las Polticas Informticas (15.909%)

-Planificar, Organizar, Dirigir y Controlar el Procesamiento Automtico
de Datos (19.697%) considerando: el Desarrollo de Proyectos (3.03%),
el Desarrollo de Aplicaciones (53.03%), y, el Desarrollo y la
Actualizacin de la BDD (3.03%).

-Seleccionar el Personal Tcnico idneo y participar en las Adquisiciones y/o
Contrataciones de Hardware y Software de la empresa (10.606%).

-Administrar la Red (35.606%): determinar las Prioridades de Trabajo,
garantizar la Utilizacin Adecuada de los Equipos (6.061%), Instalar el
Hardware y Software (17.424%).

-Establecer Polticas de Seguridades en la empresa para: controlar la
Integridad de los Datos (6.818%); controlar las Comunicaciones (0.758%);
elaborar, proponer y ejecutar el Plan de Contingencias (15.909%); realizar
Mantenimiento de Hardware y Software (48.485%); y, Manejar Respaldos.

-Establecer Programas de Capacitacin y Actualizacin de Conocimiento, y
de Soporte Tcnico (45.455%).

-Asesorar y dar Asistencia Tcnica a los diferentes departamentos y
usuarios de la Unidad Informtica.
-Evaluar peridicamente el Desempeo del Sistema Computacional
(8.333%), y
-Emitir Informes Tcnicos, Normas, Manuales, Documentacin y Reportes
(19.697%) a los diferentes Niveles de Decisin de la Empresa.

II.3 DETERMINACIN DE LOS OBJETIVOS DE LA EVALUACIN (Paso C)

La correcta definicin de los objetivos de la evaluacin, permitir romper la
resistencia del personal que trabaja en la Unidad Informtica. Los objetivos de
la evaluacin deben ser planteados junto con los niveles estratgicos de la
empresa, y ser correctamente difundidos entre el personal que trabaja en la
Unidad. Si la gente est convencida que la evaluacin significa ayuda y mejora
en el procesamiento automatizado, sin duda colaborar en las tareas
planteadas. Si las personas no perciben un afn exclusivo de sancionar para,
por ejemplo, despedir gente; estarn dispuestas a colaborar con el evaluador.


II.3.1 Objetivos del trabajo

-Evaluar el Desempeo del Sistema de Informacin, dando una visin real
de cmo estn siendo utilizados cada uno de los componentes del sistema
de computacin, por medio de la medida de los ndices de desempeo.
-Plantear los Posibles Problemas que estn afectando el desempeo del
sistema de informacin.
-Formular las Hiptesis que generan los problemas planteados.
-Identificar Cuellos de Botella con la medida de los ndices.
-Elaborar un informe tcnico con conclusiones y recomendaciones de la
evaluacin realizada.
-Elaborar un informe ejecutivo para conocimiento de la gerencia.
-Recibir una Carta de Respuesta de la Empresa, que sirva como
Realimentacin del trabajo realizado.

La evaluacin como tal debe efectuarse bajo un marco de conceptos
claros, para de este modo realizar un trabajo objetivo y que tenga como
resultado soluciones prcticas.1


II.3.2 Alcance del Trabajo

Si bien es cierto, la evaluacin puede considerar todos los elementos que
conforman el sistema de computacin; es necesario definir su alcance
previo al desarrollo de la evaluacin. Por ejemplo, una red puede tener
varios servidores, pero se considera prioritario conocer el funcionamiento
de uno de ellos -como el servidor de aplicaciones-, entonces el alcance
podra limitarse a dicho servidor. Para definir el alcance se debe tomar en
cuenta: el tiempo lmite disponible, las herramientas instaladas, el personal
tcnico y los objetivos de la evaluacin.

CAPTULO III: CARACTERIZACIN DEL SISTEMA Y
CARACTERIZACIN DE LA CARGA

III.1 CARACTERIZACIN DEL SISTEMA (Paso D)

Es importante considerar a la Organizacin como un Sistema (I.2) y
obtener todos los datos relacionados con sus componentes. Por lo tanto es
necesario una configuracin del sistema de procesamiento de datos.


Un sistema de informacin es un conjunto de componentes humanos, de
hardware y de software. Los componentes suelen ser llamados recursos
del sistema, y cada uno de ellos tiene sus propios atributos
(parmetros).

Para caracterizar el sistema es importante utilizar las encuestas, las
entrevistas y la observacin; para comprender cmo se relacionan todos
los recursos con que cuenta la organizacin.
III.1.1 Los Recursos Humanos

Las personas que trabajan en la Unidad Informtica, tanto tcnicas como
no tcnicas, influyen en el desempeo del sistema; su actitud y motivacin
estn en relacin directa con la consecucin de los objetivos de la misma.

Dado que las personas producen programas; ingresan, modifican y
eliminan datos; ejecutan comandos u opciones de aplicaciones; obtienen
reportes; realizan backups y dan mantenimiento a los componentes del
sistema; es muy importante su seleccin, capacitacin y actualizacin.

Entre el personal tcnico se puede incluir:
Administrador de la red.
Personal de desarrollo.
Personal de mantenimiento.
Personal de operacin.
Personal de capacitacin.
Por otro lado, tambin debe darse importancia a la ubicacin fsica de cada
uno de los tcnicos, en relacin a la distribucin fsica de la empresa y su
Unidad Informtica.

Es muy importante considerar los siguientes aspectos, en el potencial
humano requerido:

-Formacin acadmica afn al trabajo que desempea. Como se explic en el
Captulo I, la tendencia creciente es a contratar ingenieros de sistemas,
sobre todo en lo que tiene que ver con la Administracin de la Unidad
Informtica.
-Experiencia en el uso de equipos y programas disponibles.
-Conocimientos actualizados.
-Incentivos econmicos adecuados al perfil y al nivel de responsabilidad del
tcnico.


III.1.2 Los Equipos

El hardware de un sistema de computacin incluye el procesador central,
los procesadores de entrada y salida, los dispositivos de memoria -RAM,
disco duro,etc.-, los perifricos, las interfases, los buses, las
interconexiones (que antes era mayoritariamente realizada con par
trenzado o cable coaxial, y actualmente es en su mayora UTP nivel 5) y
dems dispositivos fsicos de la red.

Es muy importante conocer la arquitectura del equipo y si cumple con los
requerimientos y/o propsitos de la empresa.

La Metodologa sugiere obtener un grfico de la topologa de la red (De
acuerdo a lo investigado, el 36.364% es tipo estrella, el 27.273% es tipo bus
y el 11.3636% es tipo anillo), que nos permita tener una clara idea de cmo
estn dispuestos los diferentes componentes fsicos de la misma; ya que
todo tipo de modificacin de equipo produce un sistema distinto al anterior,
con nuevas caractersticas y nuevos elementos que analizar. Por lo tanto,
todo cambio en la topologa de la red amerita una nueva evaluacin.


III.1.3 Los Programas

Es importante conocer los tipos de programas que existen en el sistema
de computacin:

III.1.3.1 De soporte, con los cuales se trabaja, pueden tener un impacto
en la cuantificacin de los ndices, entre los ms importantes estn:

-Los sistemas operativos.
-Los lenguajes de programacin.
-Los administradores de bases de datos, etc.

III.1.3.2 De control, es necesario conocer que software se est
empleando para controlar las actividades del sistema, si se emplea el
sistema operativo exclusivamente o si adicionalmente se utilizan
programas para controlar las actividades, como por ejemplo: el Spectrum
o el SMS.

III.1.3.3 De aplicaciones, los programas de aplicacin son los dirigidos a los
usuarios y constituyen la carga ms importante que se maneja en una
empresa. Por esto se deben identificar las mismas, para lo cual es
necesario: conocer cmo fueron desarrollados: con qu lenguaje o
herramienta, con qu tcnicas de programacin, a medida o no, por la
Unidad Informtica o por empresas externas,etc. Cundo fueron
implantados, cul es su documentacin tcnica y de operacin, si se
dispone o no de los programas fuente -para realizar mantenimiento- y si se
tiene o no licencias para su uso.

III.1.3.4 De desarrollo, lo fundamental es verificar si el software de
desarrollo es tecnolgicamente adecuado, si dispone de licencias y si es el
ms indicado para el tipo de empresa y los objetivos que persigue.

III.1.3.5 De evaluacin, Todo sistema operativo dispone de herramientas de
evaluacin. Se debe tener un cabal conocimiento de las herramientas,
adicionalmente varios comandos del sistema operativo permiten obtener
informacin bsica del rendimiento del sistema de computacin (Anexo 3).
Se debe verificar si los programas que se utilizan son los adecuados, y si
siendo adecuados estn siendo utilizados correctamente
III.2 CARACTERIZACIN DE LA CARGA (Paso E)

Caracterizar la carga, se dijo, es describir en forma cualitativa y cuantitativa
la carga del sistema, en funcin de los objetivos planteados. La
caracterizacin de la carga se ve en ltima instancia, mediante la
cuantificacin de los ndices. Para esto es importante contestarse las
siguientes preguntas relacionadas con el proceso de la carga:
-Quin?
-Cundo?
-Dnde?
-Cmo?
-Para qu?
-Por qu?

-Quin o quines utilizan la red de computacin, es decir, los usuarios de la
red, ya sean internos o externos; cundo utilizan la red, durante qu tiempo y
en qu momento comienzan o terminan su trabajo; dnde, es decir, en qu
terminal y en qu rea o departamento utilizan la red; cmo estn realizando
su trabajo: ingresan, consultan, modifican, imprimen o eliminan datos; para
qu accesan a la red: para consultar, operar, calcular, imprimir, etc.; por qu
ingresan a la red: cul es su perfil de usuario, cul es su password y cul es
su login.
Es conveniente en el grfico de la topologa de la red, agregar los datos
obtenidos de las preguntas contestadas, en el prrafo anterior. De esta
forma, se puede visualizar la red y sus componentes -incluido los recursos
humanos-.

Caracterizar la carga, es tener una clara idea del funcionamiento de la red y
de la empresa, en lo que tiene que ver con la Unidad Informtica o con la
empresa que est dando servicio externo a la organizacin. Lo que ayuda a
comprender los ndices de desempeo del sistema de computacin. En otras
palabras es describir la carga del sistema.

Un problema es la subjetividad en la caracterizacin. Aunque se definan
variables sin ambigedad; a veces su medicin es difcil, por un lado, y por
otro el escogitamiento y el peso que se da a estas variables es subjetivo.

Para caracterizar la carga es importante determinar las aspiraciones no
satisfechas de procesamiento de datos, es decir, conocer en qu medida la
red o redes- de computacin es aceptada por los usuarios. Desde el punto
de vista de evaluacin, las principales razones por las cuales existe
insatisfaccin son1:

Sistema de computacin obsoleto, es decir, el hardware y/o software
disponibles no satisfacen las necesidades de procesamiento de datos, no
permiten cumplir los objetivos y no poseen tecnolgicamente las herramientas
indispensables para satisfacer a futuro las necesidades mencionadas.

La administracin de la Unidad Informtica, si sucede lo anterior, debe plantear
soluciones sin esperar que le exijan.

Subdimensionamiento, que se da cuando se tienen equipos
tecnolgicamente adecuados, pero se requiere mayor capacidad en algunos
dispositivos fsicos como: el procesador, la memoria central, el disco duro, los
terminales, las lneas de comunicacin, etc.

En cuanto al software se deben considerar elementos como: el administrador
de base de datos, los paquetes de comunicaciones, la ayuda para las
aplicaciones, las herramientas CASE y el acceso a Internet.

Es importante considerar el subdimensionamiento en relacin con el personal
tcnico trabajando en la Unidad Informtica, ya que an teniendo los equipos y
el software adecuado, si no se tiene personal suficiente la productividad no ser
buena.

Capacitacin, ya que muchas veces el personal existente no se actualiza
continuamente o no dispone de una planificada capacitacin, lo que causa un
rendimiento bajo. En varios casos debido a esta falta de capacitacin, el uso
del recurso sistema de computacin no es el ms adecuado, aunque aqul
sea muy moderno. La falta de capacitacin puede causar que el desarrollo de
los programas de aplicacin, no cumplan con las etapas necesarias o que
sean desarrollados con tcnicas de programacin inadecuadas.

III.2.1 Determinacin del (los) Perodo (s) Representativo (s)
Las llamadas horas pico, que para efectos de trabajo en el sistema de
computacin pueden representar das, semanas o meses; constituyen una
parte fundamental en la caracterizacin de la carga.

Hay que hacer el anlisis de la carga en el transcurso del tiempo, para
identificar el perodo ms representativo. Se puede tener uno o varios perodos
representativos en el transcurso de un ao, es decir, el perodo de tiempo en el
cual la carga es ms representativa. En el Grfico 4 se puede ver una
diferencia muy marcada entre los perodos representativos y el
comportamiento general de la carga.

Por ejemplo, si el sistema estuviera subdimensionado, un objetivo sera saber
en cunto aumentar su capacidad para que la carga se estabilice.



Es necesario analizar, tambin, si es posible distribuir la carga en el
transcurso del tiempo, para evitar cualquier futuro sobredimensionamiento
del equipo, que implicara un costo extra, que suele ser muy alto.

INDICE
Tiempo

Grfico No. 4 : Variacin de un ndice en el tiempo
III.2.2 Tipos de Carga

Existen varios tipos de carga:
-Batch.
-Interactiva.
-De monoprogramacin.
-De multiprogramacin.
-De procesos distribuidos.
-De usuarios remotos.

Sin embargo, las cargas fundamentales que interactan en un sistema
suelen ser interactivas y batch. Se debe determinar el tipo de carga ya
que cada uno tiene sus ndices de desempeo ms representativos; por
ejemplo, el tiempo de retorno para los procesos batch y el tiempo de
respuesta para los procesos interactivos. En todos los sistemas hay una
combinacin de tipos de carga que puede ser calculada en porcentaje.

Hay ndices relacionados con los dos tipos de carga fundamentales:
batch e interactiva, por lo que es importante determinar la caracterstica
de la carga en el momento de la cuantificacin.
Tambin interesa saber el tipo de programacin utilizada, ya que esto
influye en la evolucin del sistema, para lo cual debe tomarse la relacin
de la carga y observar, por ejemplo, cuntos procesos se realizan al
mismo tiempo y cuntos usuarios interactan con dichos procesos.

III.2.3 Etapas de Desarrollo de la Carga

Generalmente la carga en un sistema de computacin, tiene un
comportamiento similar a la funcin de distribucin de Gauss. Para la
evaluacin es importante determinar en qu etapa de desarrollo se
encuentra la carga1:

-Etapa de crecimiento: al iniciar el sistema su trabajo, la carga es mas
bien pequea y los usuarios reciben un servicio acorde con sus
expectativas. En este perodo no se puede hablar de un equipo
sobredimensionado, porque hay que entender que el equipo seguir
tomando carga. El crecimiento en esta etapa suele ser pronunciado, hasta
que llega a una etapa de estabilizacin. En esta etapa la evaluacin
determinar las demandas y las necesidades.

-Etapa de estabilizacin, en esta etapa se supone que todas o la mayora
de las reas o departamentos estn automatizados y que el sistema de
computacin se encuentra trabajando a su mxima carga. En la etapa de
estabilizacin es necesario definir qu nuevas perspectivas tiene la entidad
y, en base a stas, se debe planificar un posible crecimiento del sistema.
En esta etapa, si el equipo y los programas de aplicacin no han sido
actualizados convenientemente, los usuarios empiezan a sentirse
insatisfechos con los resultados por razones como: el tiempo de respuesta
alto, las herramientas de software y las interfaces inadecuadas, etc. En
esta etapa la evaluacin determinar el nivel de satisfaccin de los
usuarios.

-Etapa de decrecimiento: si se dan los problemas antes mencionados, el
sistema comienza a saturarse, y el usuario empieza a no utilizar el sistema
para satisfacer sus necesidades debido a la lentitud. La demanda decrece,
la carga disminuye y el sistema deja de satisfacer los requerimientos del
usuario. En esta etapa la evaluacin determinar el grado de utilizacin de
la red.


III.2.4 Proyeccin de la Carga

La carga debe proyectarse en funcin de la capacidad del sistema, la
misma que depende de:

-Las caractersticas de los recursos individuales.
-La interconexin (configuracin) de los recursos.
-La forma de uso de los recursos.

En la definicin de la capacidad se deben incluir los objetivos de servicio
al usuario. La capacidad puede definirse a distintos niveles:

-Terica, que depende de los datos proporcionados por el fabricante.
-Disponible, que est relacionada con la cantidad de trabajo mximo
que el sistema puede ejecutar.
-Utilizable, que est en relacin con la cantidad de trabajo til que se
puede obtener del sistema.

Las principales actividades en planificacin de la capacidad del sistema
dependen de la caracterizacin de la carga y del pronstico (proyeccin) de
la carga, y son:

-Definir los objetivos de servicio de las instalaciones.
-Medir y analizar los datos.
-Planificar en base al crecimiento de la carga y los recursos disponibles.
-Reportar con informes adecuados a los distintos niveles de decisin.

El Grfico 5 representa la caracterizacin cualitativa de la composicin de la
carga en el tiempo2:





3
2
1
Tiempo (aos) 0 1 2 3 4 5 6 7
Grfico No. 5: Caracterizacin cualitativa de la composicin de la carga
Programas en produccin por algn tiempo.
Programas nuevos.
Programas a desarrollarse o depurarse.

Para realizar pronsticos es til distinguir las aplicaciones actuales de las
nuevas: similares a las ya existentes o totalmente nuevas.

III.2.4.1 Pasos para Proyectar la Carga

-Definir los objetivos del uso del Sistema de Computacin.
-Contabilizar la carga producida, para cada categora de programas.
-Establecer el tiempo para las proyecciones a corto, mediano o largo plazo.
-Establecer las tcnicas de proyeccin, de acuerdo al horizonte de planificacin
y a la dinmica de la carga: estacional, cclica, con picos semanales, con picos
mensuales, etc.
-Observar el comportamiento de la carga por medio de ventanas -que permiten
mirar parte de la carga ms representativa-, o de acuerdo al perfil por
aplicacin -que depende del volumen de datos que se va a procesar-.
-Considerar las tendencias de la carga, con respecto a todos los recursos.
-Evaluar la utilizacin futura de los recursos, tanto a nivel de toda la carga
como de sus componentes,

-Considerar las migraciones de recursos.
-Considerar las modificaciones impredecibles de la composicin de la carga,
debido a la carga latente, es decir, la parte de la carga que, debido a
restricciones del sistema, no es sometida a l. Ejemplo 1, determinar cmo
crecera la carga en lnea, con el aumento del nmero de terminales. Ejemplo
2, determinar cmo aumentara el grado de multiprogramacin, con el tamao
de la memoria.
-Formular hiptesis razonables, para mejorar la confiabilidad de las
predicciones, incorporando el criterio de los usuarios, de los programadores, de
los analistas, de los administradores y de los planificadores.
-Estudiar las tendencias temporales de algunos ndice de desempeo, para
entender la dinmica de la carga: tiempo de respuesta, tiempo de retorno, tasa
de ejecucin de las transacciones, tasa de ejecucin de los programas, etc.

Es aconsejable no usar un nico mtodo, es mejor integrar en una nica
metodologa, como la que se est desarrollando, las distintas tcnicas
existentes.

Uno de los problemas ms significativos es tener que estimar la carga de una
aplicacin nueva, debido a que no se dispone de informacin histrica y no
sirven las mediciones existentes, pues no hay manera de verificar la similitud
posible con la carga pasada.


Para esto se sugiere:
Particionar en mdulos la carga nueva.
Tomar los mdulos caractersticos y aplicar los datos conocidos de la
carga actual.
Extrapolar, en base a mediciones hechas de la carga producida por la nueva
aplicacin, cuando est en etapa de desarrollo y depuracin. Sin embargo, el
riesgo de error es elevado.

III.3 Consideraciones Econmicas

Los estudios de evaluacin del desempeo de un sistema se realizan
principalmente para reducir la relacin costo/beneficio. Este es el objetivo
ms comnmente establecido, sin embargo, la deteccin de cuellos de
botella, la prediccin de efectos producidos por cambios futuros, la demora
en la adquisicin nuevos equipos, el mejoramiento de la utilizacin de ciertas
unidades, etc., son objetivos que tambin pueden considerarse bajo una sola
meta: reducir la relacin costo/beneficio1.

Para evaluar los riesgos de una inversin, es necesario cuantificar todos los
valores involucrados lo ms precisamente posible y en orden de importancia.
En otras palabras se deben convertir los ndices de desempeo de trminos
tcnicos a trminos econmicos.





En la evaluacin econmica los costos actuales se comparan con los
beneficios actuales. Los costos se pueden estimar con una exactitud
razonable, pero varios beneficios todava pueden ser difciles de medir.

La evaluacin econmica puede ser til ms all de la aplicacin
especfica examinada. Para propsitos administrativos, la evaluacin
puede ayudar en la toma futura de decisiones para identificar los costos
de las aplicaciones para las cuales un retorno (rendimiento) econmico no
era esperado o no se puede estimar:

Ordenada por ley o por cambio en los sistemas externos (el
ejemplo ms reciente fue el problema del y2k, y el que
est latente es el problema de la erupcin del Volcn Guagua
Pichincha).
Requerida para equiparar la competencia.
Necesaria para mantener o establecer una ventaja con la
competencia.
Necesaria para mejorar el desempeo de la organizacin.

III.3.1 Criterios Generales a Considerarse

-Buscar la mxima relacin resultado/esfuerzo.

-Identificar las principales causas de problemas o ineficiencias (cuellos de
botella).

-Limitar las variables medidas a las estrictamente necesarias, para verificar
las hiptesis formuladas en la metodologa.

-Cada requerimiento de inversin debe ser soportado por la
documentacin sobre los costos en los que se va a incurrir, los beneficios a
obtenerse y el riesgo involucrado.

-Una descripcin de las necesidades existentes y de cmo una mejora del
desempeo puede satisfacerlas, debe incluirse siempre en la propuesta.
Por lo tanto debe tener una justificacin econmica.

-La justificacin econmica incluye todos los costos y beneficios tangibles.
Los beneficios intangibles deben mencionarse, pero no son parte del
anlisis.

III.3.2 Principales Componentes del Costo de una Unidad
Informtica

-Personal: evaluadores, programadores del sistema, programadores de
aplicaciones, consultores, entre otros.

-Adquisiciones y mantenimiento de herramientas e instrumentos de
medicin: monitores para hardware, monitores para software, paquetes de
contabilidad, simuladores, paquetes con modelos analticos, instalacin,
mantenimiento, etc.

-Recoleccin y reduccin de datos, como el consumo de: CPU, de
espacio de memoria, de operaciones de entrada y salida, de
almacenamiento secundario; nmero de procesos, nmero de usuarios, etc.

-Modificaciones del sistema: mejora, expansin y/o reconfiguracin.

CAPTULO IV: PLANTEAMIENTO DE PROBLEMAS, FORMULACIN
DE HIPTESIS Y SESIONES DE MEDIDA

IV.1 PLANTEAMIENTO DE LOS PROBLEMAS ENCONTRADOS (Paso F)
En esta metodologa se sugiere identificar, a priori, los problemas
encontrados; ya que se ha demostrado que es importante tener una clara idea
de lo que est pasando en la Unidad Informtica, para enfocar el estudio de
evaluacin. Los posibles problemas sern corroborados despus de realizar
las mediciones; para esto, es fundamental observar el trabajo de la Unidad
Informtica, sobre todo si el evaluador es externo a la empresa. Se sugiere
visitas peridicas a la empresa, entrevistas con los administradores y
elaboracin de encuestas; para obtener la informacin que permita un
conocimiento preliminar del sistema de informacin (Anexo 5).

IV.1.1 De Acuerdo al Evaluador
La experiencia del evaluador es bsica para poder percibir en corto tiempo, la
situacin de la Unidad Informtica. No es una buena idea iniciar con la
revisin de evaluaciones anteriores; primero, porque esto puede condicionar
el criterio del evaluador; segundo, porque puede generar desconfianza en las
personas que trabajan en la empresa; y, tercero, porque lo ms probable es
que no representen la realidad actual.



Para plantear los posibles problemas se inicia planteando aquellos que o
son evidentes o parecen serlo, despus de haber realizado varias visitas a la
empresa. El criterio del evaluador ser lo ms imparcial posible, se sujetar
al tiempo previamente establecido y se enmarcar dentro de los objetivos
planteados.

IV.1.2 De Acuerdo al Director de la Unidad Informtica

Es importante antes de formular los problemas, que pueden haberse
percibido en el paso anterior, conocer el punto de vista del Director de la
Unidad Informtica, estableciendo requisitos fundamentales en los que se
basa su accionar: Plan Estratgico, Plan Informtico y Plan de
Contingencias.

El criterio del Director ayudar a entender toda la estructura del Sistema de
Informacin, y fundamentalmente del sistema de computacin. Por otro lado,
ayudar a que ste tenga conocimiento del trabajo que se est realizando.

IV.1.3 De Acuerdo a los Usuarios Internos

Muchas veces los usuarios internos o empleados de la empresa, tienen una
particular y diferente forma de ver la ayuda que brinda el sistema de
computacin; cuando son muchos usuarios es conveniente aplicar una
encuesta, o cuando las personas no tienen confianza para expresar sus
puntos de vista.

Los criterios de los usuarios deben cruzarse con los del Director, de acuerdo
al punto de vista del evaluador.

IV.1.4 De Acuerdo a los Usuarios Externos

Las empresas que dan servicios, que dependen de su sistema de
computacin, deben satisfacer las demandas de sus clientes. Por esta razn
es muy importante conocer el punto de vista de los usuarios externos
(clientes).

Muchas veces los problemas mencionados por los clientes no son percibidos
por los usuarios internos o tcnicos que trabajan en la empresa. Este es otro
elemento fundamental para plantear los posibles problemas encontrados en
el trabajo del sistema de computacin.

IV.2 FORMULACIN DE LAS HIPTESIS (Paso G)

Una vez que se plantearon los posibles problemas que afectan el
desempeo del sistema de informacin, es necesario plantear las posibles
causas que los generaron. Este es un elemento bsico para realizar las
sesiones de medida, ya que dar una gua de qu se debera medir y por
qu.

Al final del trabajo se demostrar si las hiptesis fueron o no verdaderas.

IV.2.1 En Base a la Opinin de los Usuarios

Las hiptesis deben ser expuestas tomando el criterio de los usuarios, de
tal forma que la evaluacin tenga el apoyo de los mismos, si los usuarios
estn de acuerdo con las hiptesis planteadas, con seguridad, colaborarn
para la demostracin de las mismas.


IV.2.3 De Acuerdo a los Requerimientos de la Empresa

Por ms que las hiptesis sean lgicas y estn de acuerdo al punto de vista
de los usuarios, no hay que olvidar cules fueron los objetivos de la
evaluacin, ya que stos forman parte de los requerimientos de la Empresa.

Poco se conseguira si no se validara, entre las hiptesis, aquellas que
fueron el motivo fundamental de la evaluacin.

IV.3 PLANTEAMIENTO DE LAS SESIONES DE MEDIDA (Paso H)

Las sesiones de medida deben ser planificadas tomando en cuenta los
siguientes criterios:

-Objetivos, pues no se debe perder de vista las hiptesis que queremos
validar, en relacin a los objetivos propuestos para la evaluacin.
-Disponibilidad, para el uso del servidor o las estaciones de trabajo, desde
las cuales se realizar la evaluacin. Tambin, de tiempo, ya que se
requiere monitorear el sistema por algunos minutos.
-Herramientas disponibles, ya que depende del tipo de software disponible
para evaluacin, los ndices que se van a medir.
-Tipo de carga, ya que los ndices seleccionados dependern del tipo de
carga que se corre en el sistema de computacin.
Perodo representativo, es decir, las medidas debern planificarse
fundamentalmente en aquellos perodos en los cuales la carga refleja
claramente el trabajo primordial de la empresa. Sin embargo, siempre ser
importante tener una idea de la utilizacin de la red, tambin en perodos de
carga bajos.

IV.3.1 ndices de Desempeo

Existen muchos ndices cuya ponderacin vara, dependiendo de:

-El analista.
-Los objetivos.
-La herramienta, y
-El tiempo.

Los ndices pueden ser directamente medidos, calculados o estimados. La
medida de los mismos adquiere importancia, una vez que el equipo ha sido
escogido e instalado.
IV.3.2 Clasificacin de los ndices

Los ndices pueden ser:

-Internos, si cuantifican la eficiencia en la utilizacin de cada componente.
-Externos, si miden la eficiencia en el uso del sistema.

Los ndices internos dependen fundamentalmente de las caractersticas del
equipo y son:

-Utilizacin de CPU, se refiere al porcentaje total que se utiliza la CPU, del
tiempo total que el sistema est energizado.
-Brechas de CPU, que son los perodos de tiempo durante los cuales la
CPU no est realizando ninguna actividad.
-Operaciones de entrada/salida, que indica el perodo de tiempo que el
sistema se dedica a atender procesos de lectura y escritura.
-Brechas de entrada/salida, que indica los perodos de tiempo durante los
cuales no se realiza ninguna operacin de transferencia.
-Sobreposicin de actividades, que tiene que ver con las actividades de
tiempo compartido del sistema.


-Factor de multiprogramacin, establece la degradacin del sistema
exclusivamente debido a la multiprogramacin, esta medida puede ser
hecha corriendo un solo programa con un solo usuario y, luego,
corriendo la misma aplicacin con varios usuarios.
-Tasa de paginacin, es el porcentaje de tiempo que la CPU se
dedica a satisfacer las necesidades de paginamiento. Incide
directamente en el nmero de procesos activos y puede ser
directamente observable.
-Tiempo de reaccin, es el tiempo que transcurre desde cuando se
usa un comando y la CPU empieza a ejecutar dicho comando.

Los parmetros que pueden ser medidos para cada uno de los ndices
se explican en el numeral IV.4.1
Los ndices externos dependen tambin del modo de uso del sistema,
es decir, del factor humano, y son:
Tiempo de retorno, es el intervalo de tiempo entre el instante en que un
programa es sometido a procesamiento batch, y el instante en que su
ejecucin termina.
T = E L
T = tiempo de retorno
E = momento de finalizacin de la escritura de los resultados del proceso.
L =momento de inicio de la lectura del programa.

Deben distinguirse dos tiempos de retorno:

-Externo, si se incluye las operaciones manuales de ingreso y retiro de la
aplicacin.
-Interno, si se considera slo el tiempo requerido por el sistema para el
procesamiento.

El tiempo medio de retorno (Tm), suele ser un ndice importante, para darnos
una idea de la carga:


n = nmero de medidas.
i = 1,2,...,n


( )
i i
L E
n
Tm =
1
El ndice Tm es un indicador de la eficiencia del procesamiento. Sin
embargo, no siempre es el mejor ndice, a veces se prefiere medias
ponderadas. El tiempo ponderado de retorno (Tw) es:





Tp = tiempo de proceso de programa.

Con la expresin anterior se puede construir un ndice de desempeo ms
real, el tiempo medio ponderado de retorno (Twm):





Este ndice es afectado por las polticas de administracin del sistema, es
decir, las disciplinas de servicio; y es un indicador del nivel de satisfaccin
del cliente.

p
w
T
T
T =
wi wm
T
n
T
1
=

-Tiempo de respuesta, es un ndice para los sistemas interactivos, y
es, para un comando dado, el intervalo de tiempo entre el instante en
que es iniciado el comando desde el terminal, y el instante en que el
terminal empieza a sacar la respuesta.

Como en el caso del tiempo de retorno, ni el tiempo de respuesta para
un comando aislado, ni la media suelen ser representativos; por ello se
prefieren otros descriptores estadsticos como:

-La desviacin estndar,
-Los percentiles de distribucin de los tiempos de respuesta,
-La mediana, que es el valor medio de todas las medidas tomadas.
-La desviacin total, que es la diferencia entre los valores extremos de
los tiempos de respuesta medidos.
-Las distribuciones acumulativas, etc.

Cuando la desviacin estndar es mayor que la media, se puede decir
que el sistema tiene una variabilidad insoportable, debido a que est
cargado inadecuadamente o est subdimensionado.

Se distinguen dos tipos de comandos:

-Ligeros, cuando requieren un tiempo de CPU inferior a la duracin de un
quantum; por ejemplo, los comandos de edicin, de ingreso, de salida, de
tiempo y de fecha.
-Pesados, cuando requieren ms de un quantum; por ejemplo, los
comandos de compilacin, de ejecucin, de ensamblaje y de ordenacin.

El tiempo de respuesta se ve afectado por la dinmica del sistema y es
mayor en las horas pico, como se mencion en III.2.1

Igual que en el caso del tiempo de retorno, sobre el tiempo de respuesta
afectan factores como:

-Los sistemas operativos.
-Las caractersticas de los terminales.
-Las disciplinas de servicio.
-El nmero de usuarios en el sistema.
-La carga no interactiva que soporta no concurrentemente.



-Rendimiento, o productividad del sistema, es la cantidad de trabajo
realizada por el sistema en una unidad de tiempo. Su valor puede
expresarse por unidad de tiempo de varias formas:

-Nmero de programas ejecutados.
-Cantidad de datos procesados.
-Nmero de transacciones procesadas.
-Nmero de usuarios conectados concurrentemente, etc.

La importancia de la productividad como ndice de desempeo se debe
al hecho de que su valor est estrechamente correlacionado con el costo
del uso del sistema. Su definicin puede aplicarse a cada uno de los
componentes del sistema, por ejemplo, de la CPU o de los canales de
entrada y salida.






La productividad del sistema viene dada por:







X = Productividad.
Np = nmero de programas procesados.
Ttot = tiempo total de proceso.

La productividad da una idea de la velocidad de ejecucin para el
conjunto de programas Np (la carga), pero no representa informacin
alguna sobre la eficiencia con que cada programa individual es
procesado. Por esta razn, es fundamental caracterizar la carga.

La productividad del sistema es usualmente menor que el valor terico o
capacidad del sistema.

tot
p
t
n
X =
Algunos de los factores que influyen sobre el ndice de rendimiento del
sistema son:

-Las caractersticas de la carga.
-La configuracin del sistema: hardware y software.
-El grado de multiprogramacin permitido por el hardware.
-Los algoritmos de administracin y asignacin de recursos.
-La velocidad de los componentes hardware y software.

Los factores anteriormente mencionados pueden influir sobre la
productividad con distintos peso. Es decir, unos son ms sensibles que
otros.

Como la productividad es un ndice externo, su optimizacin puede ir en
desmedro de algunos ndices internos o viceversa.

Ejemplo, la productividad del subsistema de entrada/salida incluye: reas
de buffers, canales de transmisin, unidades de control, unidades
perifricas, etc. Si el programa usa un nico archivo, la productividad de
entrada y salida (Xio) sera:

( )
seg
bits
V
b
T
b
x
io
r
io
|
|
.
|

\
|
+
=
b = nmero promedio de bits en un registro.
Tr = tiempo promedio de acceso a un registro.
Vio= nmero de bits transmitidos por segundo.

Esta ecuacin muestra que el rendimiento del subsistema de entrada/salida,
est en funcin de la longitud de los registros, la velocidad del hardware, la
organizacin del archivo y la velocidad de transmisin de los canales.


-Capacidad, es la mxima cantidad de trabajo que el sistema es capaz
de realizar por unidad de tiempo, dada una carga determinada -
analizado en el numeral III.2.4-. La capacidad est relacionada con lo
que el sistema podra hacer.

-Disponibilidad, se refiere al nmero de horas que el usuario puede
hacer uso del sistema. Este factor est relacionado tambin con la
probabilidad real de que el usuario pueda terminar su trabajo en el
tiempo requerido.

-Confiabilidad, se refiere al perodo promedio en que el usuario puede
utilizar el sistema, del tiempo de vida total del sistema, sin que tenga
ningn problema con los datos o procesos que utiliza.

IV.3.3 Niveles de Inters en la Evaluacin del Desempeo

El Grfico 6 muestra los principales niveles de inters en la evaluacin
del desempeo del sistema de computacin3.

DISEADORES DEL SISTEMA























NIVEL 1

ADMINISTRADORES DE LA INSTALACION
















NIVEL 2



ANALISTAS Y PROGRAMADORES



NIVEL 3
Grfico No. 6
Mientras ms se acerca al Nivel 3, ms estrechos y especficos son los
objetivos. Mientras ms se acerca al Nivel 1, ms limitadas son las
posibilidades de mejora del desempeo en forma directa.

Para cada uno de los niveles existe un objetivo fundamental:

-Para el diseador del sistema, el objetivo es lograr el ptimo
funcionamiento de todos los componentes.

-Para el administrador de la instalacin, es importante el balance y el uso
efectivo (costo/beneficio) de los componentes del sistema.

-Para el usuario, lo ms importante es la eficiencia en el procesamiento, es
decir, el tiempo de ejecucin y el costo.

Bsicamente las tcnicas de evaluacin, es decir, los mtodos para obtener
los ndices, pueden dividirse en dos grandes categoras:

-La medicin directa de los ndices, utilizando las herramientas de
evaluacin, analizadas en el numeral IV.4, y
-Las tcnicas de modelizacin, analizadas en el numeral IV.5


IV.3.4 Recoleccin de Datos

Independiente de la herramienta que utilicemos, o de los comandos que
empleemos, se deben recoger datos que reflejen el comportamiento del
sistema de computacin. No hay que olvidar que la evaluacin siempre debe
tomar en cuenta el objetivo de la empresa, su visin y cmo se estn
alcanzando las metas.

Los datos que se pueden tomar con las herramientas son:

-Utilizacin de la CPU, identificando si el sistema est:
-Corriendo en modo usuario con threads activos. Todo el cdigo de
aplicaciones y subsistemas se ejecuta en modo usuario.
-Corriendo en modo de sistema.
-Esperando o desocupado.


-Porcentaje de tiempo que el procesador est ocupado. Es la fraccin
de tiempo empleada en trabajo til.
-Velocidad del procesador.
-Nmero de procesos del servidor.
-Porcentaje de tiempo de interrupcin, que es el porcentaje de tiempo
que el procesador ha empleado atendiendo interrupciones de
hardware.
-Interrupciones por segundo. Un dispositivo interrumpe al procesador
cuando ha terminado una tarea o cuando requiere atencin.
-Fallos de pgina.

-Utilizacin de la Memoria Principal:
-Promedio de pginas disponibles para procesos de usuarios.
-Porcentaje de uso de la RAM.
-Bytes disponibles.
-Nmero de bytes asignados en uso, que es la proporcin de bytes en
uso con respecto al lmite de asignacin. Representa la memoria
virtual en uso.
-Pginas por segundo a ser ledas o escritas del disco.



-Utilidad de los buffers:
-Transferencia entre buffers del sistema y del disco.
-Acceso a buffers del sistema.
-Transferencia a travs de dispositivos fsicos.

-Utilizacin del disco duro:
-Particiones lgicas del disco duro.
-Porcentaje de tiempo que est ocupado el dispositivo.
-Promedio de solicitudes de lectura y escritura.
-Bytes transferidos.
-Utilizacin del dispositivo.
-Bloques de disco disponibles para procesos de swapping.
-Longitud promedio de cola de disco.
-Espacio libre, que es la proporcin entre el espacio libre disponible en la
unidad de disco lgica y el espacio total utilizable proporcionado por la
unidad de disco lgica seleccionada.

-Actividades de mensajes:
-Mensajes enviados y recibidos por segundo.
-Semforos activos por segundo.
-Nmero de tareas que pueden emplear el recurso al mismo tiempo.
-Nmero de estaciones de trabajo que pueden correr un programa al mismo
tiempo.

-Llamadas del sistema:
-Llamadas de lectura.
-Llamadas de escritura.
-Caracteres transferidos por llamadas de lectura.
-Caracteres transferidos por llamadas de escritura.

-Promedio de colas ocupadas:
-Porcentaje de procesos en cola.
-Nmero de solicitudes de disco que el servidor est esperando
atender.

-Comunicaciones:
-Conexiones remotas.
-Conexiones individuales para un usuario determinado.
-Tiempo que el usuario est conectado a la red.
-Nmero de solicitudes que la conexin ha realizado al servidor.
-Kilobytes que la conexin ha utilizado para la lectura.
-Kilobytes que la conexin ha utilizado para la escritura.
-Nmero de registros lgicos de seguridad de una conexin.

-Estado de la Memoria Cach:
-Porcentaje de utilizacin.
-Porcentaje de aciertos.
-Lecturas de copia por segundo.
-Lecturas de fijacin por segundo.
-Pginas de escritura lenta por segundo.

Cuando no se puede recoger los datos en lnea, debido a que el sistema
est muy saturado, o a que no existe disponibilidad de equipos, se sugiere
utilizar el Registro de Informacin (Bitcora) del Sistema, que almacena la
informacin histrica referente a los objetos y computadores seleccionados
en archivos como el Log del Unix. Este archivo puede ser ledo (siempre
que no tenga ningn error de escritura) y evaluado despus, incluso en otro
sistema. Sin embargo, muchas veces el formato del archivo histrico puede
causar problemas al ser ledo en otro equipo.

IV.3.5 Seleccin de los Datos ms Representativos

Para seleccionar los datos ms representativos se debe primero cuantificar
los ndices, para lo cual se debe determinar en forma cuantitativa los ndices
basndose en procesos estadsticos. La cuantificacin de los ndices
generalmente debe hacrselo en el perodo representativo de la carga,
puesto que los valores en este perodo son los que reflejan el
comportamiento del sistema, esto permitir obtener la funcin de densidad y
en base a sta la desviacin estndar. Para la cuantificacin es conveniente
considerar perodos largos y no hacerlo en forma parcial.

La cuantificacin de los ndices depende del sistema de computacin.
Generalmente se tiene la informacin grabada en un archivo para luego ser
procesada, sin embargo, cuando se puede correr la herramienta en lnea, se
obtiene un valor agregado a la medida, y es, fundamentalmente, saber qu
se estaba haciendo el momento de tomar los datos. Tambin, se deben
establecer las condiciones de la instalacin al momento de cuantificar los
ndices. En resumen, la cuantificacin de los ndices depende del entorno de
trabajo que se tiene en el momento de realizarla.

Cuando en el reporte del sistema no constan los ndices que deseamos,
se podra escribir un programa benchmark- con determinadas
caractersticas para obtenerlos. Ejemplo, los estudiantes escribieron un
programa en C para calcular el tiempo de respuesta de un conjunto de
operaciones, ejecutadas desde cada diferente terminal, comprobando que
habia una marcada diferencia debido a los diferentes paths de acceso.

La cuantificacin de los ndices debe hacerse, en lo posible, en base a la
informacin obtenida del sistema operativo, caso contrario, el error puede
ser apreciable.

Para poder cuantificar los ndices:

Debe familiarizarse con el sistema operativo.
Descubrir cmo se pueden obtener los ndices, cmo
procesarlos, y en base a los datos estadsticos obtener la
desviacin estndar.

En caso de disponer de los datos del sistema operativo:

- Observe la curva de carga y establezca si se encuentra en un
momento de carga creciente o decreciente.
- Determine en qu espacio de tiempo se realiza el trabajo.

Si no se dispone de datos histricos, se debe elaborar un cuestionario
(Anexo 6) y/o establecer entrevistas con las persona ms familiarizadas con
la instalacin. Entre las preguntas que se deben hacer estn:

- En qu fecha se corren el mayor nmero de programas?
- Cundo se realizaron las medidas?
- El tiempo de respuesta es confiable y en qu porcentaje es
mayor o menor al normal?
- La distribucin de la carga es factible, de acuerdo al tipo de trabajo de la
empresa?

En algunos casos la herramienta no es grfica y es necesario migrar los datos
a una hoja electrnica, para lo cual se sugiere utilizar los tipos de grfico
explicados en el numeral V.1.

IV.3.6 PLANTEAMIENTO DE MODELOS
Siempre conviene mantener la eficiencia del procesamiento bajo control, pues
el desempeo depende tanto de la carga como de los modos de uso del
sistema.

Se necesita mantener el sistema en niveles aceptables, sin que ello cueste
mucho. El mantener un seguimiento continuo permitir rpidamente detectar
fallas y causas de ineficiencia, facilitando la adopcin de las mejores
soluciones.

La evaluacin puede hacerse durante:
-El diseo.
-La bsqueda y el ensamblaje.
-La venta.
-El uso y mejora.
-La planificacin de capacidad -prediccin-.

La evaluacin es un proceso interactivo y consta de dos fases: diagnstico
y terapia, como puede verse en el Grfico 7
4
:

La Metodologa propuesta, centra su atencin en la evaluacin durante el
uso y mejora del sistema de computacin; as como la planificacin de la
capacidad. El principal objetivo de la misma es mejorar la eficiencia del
sistema, reduciendo el tiempo del mismo, por hora y por usuario; esto
mejorar la relacin costo/beneficio, es decir, acercar al sistema a lo
ptimo.

IV.3.6.1 Tcnicas de Modelizacin

Las tcnicas de modelizacin no requieren de la existencia y
disponibilidad del sistema, por ello muchas veces son las nicas factibles,
por ejemplo, en la etapa de diseo. Son de dos tipos: de simulacin y
analticas; una desventaja es que suelen ser una aproximacin de la
realidad, por lo tanto el error puede ser apreciable.

Tipo Objeto Medicin Simulacin Analtica
Diseo Sistema I A A
Programa I A I
Bsqueda Sistema A A I
Programa A A I
P.D.C. Sistema I A A
Mejora Sistema A A A
Programa A A A
P.D.C. = Planificacin de la Capacidad
A = Adecuado
I = Inadecuado

En la Metodologa propuesta se tratar exclusivamente de los modelos
que se pueden aplicar para la etapa de Mejora y la Planificacin de la
Capacidad.

APLICACIN DE LAS TCNICAS DE EVALUACIN PARA
DIFERENTES TIPOS DE ESTUDIO5
Tcnicas de Evaluacin

Modelizacin
IV.3.6.2 Implementacin de Modelos

Los modelos de carga pueden consistir en un conjunto de componentes
(programas, pasos de programas, etc.) pueden ser instrucciones
mixtas o trazados.

Las operaciones necesarias para la implementacin de modelos de
carga, pueden ser agrupadas dentro de tres fases:

-De Formulacin, que consiste en las vas de decisin/ejecucin. La
definicin de los componentes de la carga, que es, la identificacin de
los niveles ms bajo de detalle que estn siendo modelados y el
conjunto de parmetros a ser usados para su descripcin, est entre las
primera operaciones a ser ejecutadas.



De acuerdo al criterio del evaluador, al tipo de carga, a la disponibilidad y
a las herramientas disponibles; se pueden seleccionar los componentes
bsicos:
-Aplicaciones.
-Programas.
-Pasos de programas.
-Scripts.
-Comandos.
-Instrucciones del nivel fuente.
-Instrucciones de mquina, etc.

Lo ms alto es el nivel de los componentes bsicos, lo ms bajo es el
detalle con el cual la carga es descrita.

El anlisis de los propsitos de uso de un modelo nos permitir definir los
componentes bsicos y consecuentemente influenciar en la seleccin de
los parmetros a ser usados en la descripcin cuantitativa.

Es necesario prestar atencin particular a la seleccin del nmero de
parmetros que sern usados y a la homogeneidad de sus valores.

-De Construccin, que consiste en cuatro operaciones fundamentales:
-El anlisis de los parmetros.
-La extraccin de los valores representativos.
-La asignacin de dichos valores a los componentes del modelo.
-La construccin de las mezclas de los componentes significativos.

Puede ser til considerar los parmetros como la relacin de dos clases
dependientes:

-La representacin de los valores globales, que son los ms
populares: tiempo de CPU, nmero de operaciones de entrada/salida,
espacio de memoria requerido, etc. Y

-La secuencia de valores para cada componente bsico, que reflejan,
aunque incompletamente, la dinmica de la ejecucin de los
componentes: secuencia de brechas de CPU, las brechas entre las
operaciones de entrada/salida, la longitud de los bloques transferidos
entre dos niveles de memoria, los procesos que se estn corriendo
desde cada terminal, etc.

En vista de que la cantidad de datos resultantes es generalmente
considerable, su anlisis para propsitos de identificar grupos de
componentes con caractersticas similares, tendr que ser ejecutado con
tcnicas estadsticas que trabajan con mltiples factores.

Para pocos factores puede aplicarse:

-Tcnicas clsicas de anlisis de datos.
-Tests fundamentales de distribucin.
-Anlisis de correlacin.
-Anlisis de regresin.

-De Validacin, que permite establecer la validez del modelo
implementado. En esta fase no solamente evaluaremos la
representatividad del modelo, con su conjunto particular de parmetros que
estn siendo considerados, sino que tendremos que ejecutar tests para
determinar la validez de los dominios del modelo.

El diseo y la implementacin de modelos de carga ejecutables se
sintetizar en el Grfico 8
6
:


IV.3.6.3 Mtodos Estadsticos para la Evaluacin de los
ndices


-Muestreo de distribucin de parmetro nico, consiste en la
evaluacin de los parmetros por medio del muestreo de sus
distribuciones en forma separada.

-Muestreo de los componentes de carga, es un muestreo de la carga
misma.

-Algoritmos de agrupamiento, permiten clasificar los componentes
similares en grupos.

-Reduccin de la distribucin de probabilidad conjunta de los
parmetros, se obtiene construyendo la distribucin de probabilidad
conjunta de todos los parmetros de valor nico, a partir de lo cual se van
extrayendo los componentes del modelo, de tal forma que se siga
conservando dicha distribucin conjunta.



-Modelos de Markov, permiten construir la matriz de probabilidades de
transicin de las componentes de la carga actual, despus de haber
definido el estado de cada una de sus componentes. De la matriz de
probabilidades se obtendrn, luego, los valores de los parmetros.

-Anlisis de los componentes principales, permite, usando la
correlacin entre los parmetros entre los parmetros de la carga,
encontrar un espacio de menor dimensin que concentre la magnitud
deseada, de la varianza total generada en el espacio original. El
nmero de componentes es fundamental, ya que influye directamente
en la representatividad e inversamente en la compactabilidad.

IV.3.6.4 Implementacin de un Modelo de Carga

Para implementar un modelo de carga se siguen bsicamente los
siguientes pasos:

-Transformacin de los valores de los parmetros de cada componente
del modelo, en componentes ejecutables del modelo.

-Reproduccin en el modelo, de las mezclas de componentes encontradas
en la carga real.

Los componentes ejecutables del modelo pueden ser:

-Reales.
-Nucleares o no paramtricos.
-Paramtricos o sintticos.

Para construir los modelos ejecutables de cargas interactivas, se siguen
procedimientos que dependen de los niveles de caracterizacin de la carga,
como puede verse en el siguiente cuadro:7

IV.3.6.5 Modelo de Carga Interactiva basada en el Criterio
Orientado al desempeo del Sistema

Un modelo ejecutable de una carga interactiva consiste en un conjunto de
scripts, cada uno de siendo un conjunto de comandos desde un terminal, y
de tiempos para pensar entre cada par de comandos.

-El modelo usa los ndices de rendimiento como los parmetros que
caracterizan la carga.
-El modelo toma en cuenta el comportamiento dinmico de la carga real,
mediante la reproduccin de algunas mezclas de comandos
caractersticos del sistema.

La duracin de una interaccin en un modelo simple de dilogo, es la
suma de los siguientes cuatro intervalos:

-Ingreso.
-Clculo.
-Salida,
-Tiempo para pensar.

La componente bsica es el intervalo, que es un conjunto de scripts que
son ejecutados concurrentemente. El comienzo y el fin de un intervalo
puede escogerse como el correspondiente al momento en que se
completan las interacciones. El Grfico 9, ilustra los tiempos que
caracteriza el procesamiento de un programa en un sistema MBRS
8
:
O
p
e
r
a
c
i
o
n
e
s

M
a
n
u
a
l
e
s

L
e
c
t
u
r
a

CPU Espera
CPU o E/S
Espera CPU
Espera
E/S
Espera
CPU o E/S
Slo tiempo de procesamiento

Tiempo de procesamiento
Tiempo de retorno
Tiempo de retorno externo
Comienza ejecucin Termina ejecucin
R
P
E
s
p
e
r
a

e
n

l
a
s

c
o
l
a
s

d
e

s
a
l
i
d
a

Grfico No. 9: Tiempos que caracterizan el procesamiento de un
programa en un sistema MBRS

Cada intervalo se caracteriza por el valor de los ndices de desempeo Pi,
donde
i = 1,2,3,...,l; y puede ser considerado como un punto en el espacio l
dimensional.

Los pasos bsicos para construir el modelo son:

.Medir los ndices de desempeo que interesan, y obtener la informacin de
la carga a ser modelada.
.Escoger el nmero de acciones que completan las interacciones por
intervalo, y computar los ndices para cada intervalo.
.Agrupar los intervalos en grupos.
.Seleccionar los grupos representativos.
.Correr los intervalos en forma independiente. Medir los valores de los
ndices de desempeo que ellos producen, y evaluar el ndice global del
sistema.




CAPTULO V: EVALUACIN DE RESULTADOS

V.1 INTERPRETACIN DE LOS RESULTADOS (Paso I)

Para interpretar los resultados, se debe tomar en cuenta los diferentes tipos
de grfico que se pueden emplear, de acuerdo a los ndices medidos; as
como las variables estadsticas que ayudan a dar una clara idea del
comportamiento del sistema:

-Grficos de pastel, que sern utilizados para representar el comporta-
miento global del sistema; por ejemplo, la utilizacin de la CPU, del Disco
Duro y de la Memoria Principal.

-Grficos de barras, que permiten comparar ndices; por ejemplo, los
procesos activos y los porcentajes de uso de procesador para cada proceso.

-Grficos de lnea, que dan una clara idea de la variacin en la medida de
cada ndice, lo que ayuda a entender la dinmica del sistema; por ejemplo, la
variacin en el porcentaje de uso de CPU y la actividad de entrada/salida del
sistema.

V.1.1 En Base a los Datos Representativos

Con los datos representados grficamente, se puede observar el
comportamiento del sistema, independiente del criterio inicial que hayamos
tenido, de los problemas previamente detectados e incluso de la
experiencia del evaluador.

En base a los datos representativos, se debe obtener la desviacin de
estndar de los ndices que representan variacin en el tiempo, como por
ejemplo, la utilizacin de la CPU, con el fin de determinar la disposicin de
las mediciones dentro de una distribucin. El valor promedio puede ser
importante, cuando los procesos que corren son similares, y estamos
calculando, por ejemplo, el tiempo de respuesta.

La representacin de los datos relacionados con la utilizacin de la CPU,
de la RAM y del Disco Duro puede hacerse en percentiles, es decir, en
porcentaje con la escala a 100. Utilizar una escala menor o mayor,
distorsionara la salida.

Para la interpretacin de los ndices, se debe en este punto, agregar la
informacin de los dems recursos involucrados en el sistema de
informacin, fundamentalmente de los recursos humanos tcnicos. Se
debera considerar como afecta:

-El nmero de tcnicos trabajando.
-El grado de entrenamiento y capacitacin del personal tcnico.
-La administracin tcnica de la red.
-El grado de motivacin de los usuarios, etc.

IV.1.2 En Base a las Hiptesis Planteadas

Una vez que tenemos una clara idea del comportamiento del sistema,
debemos referirnos a las hiptesis planteadas, ya que la realidad detectada
guarda relacin, en la mayora de los casos, con los problemas inicialmente
detectados.

Toda hiptesis planteada debe ser demostrada, ya sea utilizando los ndices
medidos, las encuestas realizadas, las entrevistas efectuadas o el grado de
experiencia del evaluador. En el peor de los casos, si una hiptesis no pudo
ser demostrada, deben constar las causas en los informes finales emitidos.



V.2 CMO ESTABLECER LAS CONCLUSIONES

No hay que olvidar que la parte medular de la evaluacin son las
conclusiones del trabajo realizado, la Metodologa recomienda:

-Plantear las conclusiones de la manera ms clara posible. Expresando las
ideas en trminos que puedan ser fcilmente comprendidos por todos los
niveles de la empresa.

-Evitar utilizar calificativos como malo, indeseable, incapacitado, etc. Para
describir una realidad.

-Resaltar los puntos positivos que se encontraron durante la evaluacin.

-Expresar las ideas que previamente han sido analizadas con el personal de
la Unidad Informtica, sobre todo, cuando la evaluacin es externa.
V.2.1 De la Evaluacin

Las conclusiones deben ser presentadas en base al desarrollo de la
evaluacin, sin embargo, los resultados se deben centrar sobre los ndices
medidos, ya que stos son independientes del punto de vista del evaluador.


Hay varias formas de presentar las conclusiones de la evaluacin:

-Despus de presentar las medidas de los ndices, la seleccin de los datos
representativos y la interpretacin de los resultados.
-Intercalando los grficos en cada grupo de conclusiones relacionadas.
-Ligando a las conclusiones con las respectivas recomendaciones.

V.3 CMO ESTABLECER LAS RECOMENDACIONES

En verdad, lo que ms interesa a los mandos gerenciales de las empresas,
es las recomendaciones que se puedan hacer de la evaluacin realizada. En
muchos casos, concluir sobre la realidad del sistema de informacin puede
no ser suficiente para la intencin de la Empresa; mientras no se
desemboque en algo operativo y prctico, el trabajo puede perder validez.
Para recomendar:

-No hay que perder de vista la realidad de la empresa.
-Hay que ceirse a los datos validados.
-Tiene que plantearse soluciones prcticas y sencillas, que permitan
establecer alternativas de solucin.
-Se debe identificar y justificar la mejor solucin, en lo tcnico y en lo
econmico: Es posible que una solucin tcnica sea econmicamente
irrealizable, eminentemente terica.1
-Hay que evitar hacer muchas recomendaciones.

V.3.1 Relacin entre Conclusiones y Recomendaciones

Debe haber una relacin directa entre las conclusiones y las
recomendaciones, no es aconsejable incluir recomendaciones que no se
fundamentan en el trabajo realizado.

Las recomendaciones no tienen, necesariamente, una relacin uno a uno
con las conclusiones planteadas.

Por otro lado, no hay que olvidar que las recomendaciones deben ser
fcilmente comprendidas por los niveles gerenciales, aunque stos no
tengan mayor conocimiento de sistemas.


V.4 ELABORACIN DE LOS INFORMES FINALES (Paso J)

Hay diferentes niveles a los cuales debe llegar el trabajo realizado de una
evaluacin, pero por supuesto, a ninguno de ellos debe llegarles informacin
contradictoria. Esto quiere decir, que parte del trabajo puede tener mayor
utilidad para el nivel gerencial que para el tcnico, pero de ninguna manera
se podr decir cosas diferentes en los distintos informes, y, menos an,
alejadas de la verdad.

Aunque muchas veces se haya tenido que usar una gran cantidad de material
para producir la evaluacin, en los informes finales hay que limitarse a
presentar lo realmente sustancial. Por supuesto la calidad del informe es
fundamental, y esto implica: un seguimiento claro de la Metodologa, una
presentacin ntida de los grficos y un planteamiento objetivo de las
conclusiones y recomendaciones.

Se sugiere elaborar los siguientes documentos:

-Una Carta Final, donde -en el caso de los practicantes- se agradece por la
prctica realizada, se puntualiza en los aspectos relevantes del trabajo
realizado y se pone a consideracin el Informe Ejecutivo y El Estudio Tcnico.


-El Estudio Tcnico, que contiene toda la aplicacin de la Metodologa, un
ndice del trabajo y la bibliografa o fuentes de documentacin (V.4.1), y

-El Informe Ejecutivo, que bsicamente contiene una breve introduccin
sobre el trabajo realizado, las dificultades encontradas (de haber existido),
las facilidades prestadas para realizar el trabajo y las Conclusiones y
Recomendaciones planteadas en el Estudio Tcnico (V.4.2).

V.4.1 Presentacin del Estudio Tcnico

El Estudio Tcnico debe contener:

-El nombre del trabajo realizado, puntualizando el alcance del mismo; por
ejemplo, Evaluacin del Desempeo del Servidor de Aplicaciones de la
Empresa X.
-Un ndice, de todo el trabajo realizado, vale decir de la Metodologa
empleada, que incluya la Bibliografa y los Anexos necesarios.
-La Caracterizacin de la Empresa.
-La Caracterizacin de la Carga.
-Las Medidas realizadas.
-Las interpretaciones de los medidas y/o de las encuestas y entrevistas.

-Las conclusiones, y
-Las recomendaciones.

V.4.2 Elaboracin del Informe Ejecutivo

El Informe Ejecutivo debe se lo ms conciso posible, y totalmente ajustado
a la realidad; conteniendo:

-Una descripcin del desarrollo de la Evaluacin, puntualizado las fortalezas
y las debilidades para la realizacin del trabajo.
-Las Conclusiones y las Recomendaciones de la Evaluacin, que sern las
mismas que constan en el Estudio Ejecutivo.

V.4.3 Consideraciones para la Ejecucin de las Recomendaciones

Como se dijo anteriormente, es importante considerar la disponibilidad
econmica de la empresa, ya que de esta depende la ejecucin de las
recomendaciones. Muchas veces puede haberse detectado la necesidad de
cambiar el sistema de computacin, sin embargo, econmicamente resulta
imposible; entonces, se debe sugerir qu componentes son los ms crticos,
y cules podran cambiarse con el menor costo posible.

Las recomendaciones que tienen que ver con la administracin de la red, la
configuracin de la misma, la motivacin del personal o la capacitacin; son
las ms aconsejables en los perodos de recesin econmica.

En el caso de las prcticas; se prioriza la necesidad de demostrar que el
personal tcnico es un aporte para el mejor desempeo de las empresas, y
nunca un costo que podra suprimirse.

V.4.4 Carta de Respuesta
Como la Metodologa es una herramienta para la realizacin de
evaluaciones del desempeo de los sistemas de computacin, se pide como
requisito la entrega de una carta de respuesta de la empresa en donde se
realiz el trabajo, para:

-Conocer qu piensan los tcnicos y los directivos de la empresa, en
relacin al trabajo realizado.
-Detectar los posibles errores cometidos, para eliminarlos en una futura
evaluacin.
-Asegurar que la empresa entienda la necesidad de realizar evaluaciones,
as como guardar la informacin tcnica relacionada, para planificar la
actividad informtica futura.


La Carta de Respuesta, es un requisito indispensable de retroalimentacin
que garantiza un proceso de Calidad, y el mejoramiento continuo del proceso
de Evaluacin.

CAPTULO VI. EVALUACIN DE LOS RESULTADOS DE LA
METODOLOGA

Como se mencion en la Introduccin, se ha realizado una amplia
investigacin de la aplicabilidad de la Metodologa propuesta. A ms de los
resultados presentados en los Anexos 1 y 2; este Captulo tiene como objetivo
analizar, uno a uno, los diez pasos propuestos.

A.Preparacin de la evaluacin:

-Inicialmente, en la mayora de las empresas las personas se sintieron
molestas al saber que se iba a realizar una evaluacin; por un lado los
tcnicos que teman ser cuestionados por la forma en que realizaban sus
actividades, y por otro lado, los no tcnicos que suponan podran ser
despedidos.
-El problema anteriormente mencionado se disminuy en un 80%, siguiendo
las acciones propuestas en el numeral 1.5.1; por ejemplo, Explicando
claramente, desde un inicio, los objetivos de la evaluacin, tanto a los
niveles directivos como operativos.

-A pesar de que las acciones propuestas han resultado efectivas, mucho
depende de la particularidad de la organizacin, el grado de impacto que
causa una evaluacin del desempeo de una unidad informtica.

B.Caracterizacin de la Empresa:

-La aplicacin de la Metodologa en este punto, tuvo mayor xito cuando los
evaluadores tenan previamente un conocimiento de la Empresa; ya sea
porque trabajaban ah o porque eran usuarios de la misma.

-Otro aspecto relevante fue el hecho de que mientras ms se involucraba al
personal de la Empresa, se obtena ms rpida y confiablemente la
informacin necesaria para la evaluacin.

-Fue evidente que este paso, como est propuesto, no se lo consideraba en
el 95% de las empresas evaluadas.
C. Determinacin de los objetivos de la evaluacin:

-El 75 % de las empresas desconocan el verdadero alcance de la
evaluacin y tenan muchas confusiones respecto a los objetivos, por lo
que las acciones propuestas en los numerales II.2.1 y II.2.2 resultaron
efectivas en el 90% de los casos tratados.

D. Caracterizacin del sistema:

-La Metodologa result ser muy eficaz, en lo que hace relacin con el
anlisis, fundamentalmente del recurso humano, como parte bsica del
desempeo de la unidad informtica. El 60% de las empresas evaluadas
no daba importancia a este aspecto.

-Fue sorprenderte constatar cmo ms del 50% de los directores o jefes de
las unidades informticas, desconocan a cabalidad los recursos de
hardware y software con los que contaban.

E.Caracterizacin de la carga:

-Las preguntas del numeral III.2, resumen los datos que debe saber el
evaluador. Tom un tiempo sintetizar las ideas propuestas en este paso,
pero se comprob que el contestar las mismas ayudaban sustancialmente
en la comprensin del sistema que se iba a evaluar.

-Determinar los perodos representativos y entender bien el nivel de
satisfaccin de los usuarios, ayud en un 60% en el paso que involucra la
toma de medidas y la interpretacin de los resultados.

-Otro punto fundamental que fue difcil transmitir, es el hecho de que la
etapa de desarrollo de la carga influye notablemente en la evaluacin; as
como el evaluar no slo en relacin a lo que est haciendo la Empresa, sino
tambin a lo que aspira a hacer. El 85% de las empresas evaluadas
olvidaba considerar la Visin de su Organizacin, el momento de presentar
las conclusiones y recomendaciones del trabajo.

-Se demostr que la determinacin de los costos involucrados en el
desempeo eficiente de la unidad informtica, era uno de los objetivos que
busca toda empresa.

F. Planteamiento de los problemas encontrados:

-Se pudo validar que, plantear a priori los posibles problemas de la unidad
informtica, ayudaba en un 70% a la evaluacin; as como, la participacin
en la formulacin de los mismos, por la gente de la Empresa facilitaba el
trabajo.

G. Formulacin de las hiptesis:

-Este es otro paso propuesto, que sirvi para guiar al evaluador en el
planteamiento de las sesiones de medida, as como en la seleccin de los
ndices adecuados a las necesidades de la evaluacin.

H. Planteamiento de las sesiones de medida:

-El 80% de las empresas desconoca la verdadera potencialidad de las
herramientas de evaluacin (ms de la mitad ni siquiera saba que disponan
de herramientas o que podan, por medio de comandos del sistema
operativo, monitorear su red de computacin). La sugerencia principal en
este paso, es por lo tanto, estudiar y usar las herramientas disponibles; cosa
que dio excelentes resultados en las evaluaciones realizadas.

-En el Anexo 8 se presentan comparaciones entre las ventajas y
desventajas de usar monitores de hardware y de software, para ilustrar los
conocimientos que debe tener el evaluador para realizar su trabajo.
-El conocimiento de los modelos, es un aporte de la Metodologa de Ferrari
y ha sido mantenido en esta propuesta.

I. Interpretacin de los resultados:

-Este es el paso que requiere de una mayor ayuda del Evaluador Jefe; la
Metodologa permiti verificar que no es recomendable realizar ninguna
evaluacin, sin la direccin de un tcnico con experiencia.
-En ms del 60% de las evaluaciones, pese a que los pasos se siguieron
correctamente, se encontraron dificultades a la hora de interpretar los
resultados.
-Las acciones seguidas por esta Metodologa lograron minimizar la
necesidad de contar con experiencia previa para realizar el trabajo.


J. Elaboracin de los informes finales.

-El aporte bsico en el paso final, tiene que ver con la necesidad de
retroalimentar la evaluacin, para lo cual se da mucho valor a la Carta de
Respuesta de la Empresa.

-El 70% de las empresas, acept el trabajo tcnico realizado bajo la
Metodologa propuesta (un 50% de stas sin ninguna observacin); un 25%
sugiri hacerlo ms detalladamente (con mayor precisin o en mayor
tiempo) y un 5% consider que el trabajo no era satisfactorio (en la muchos
casos no contaban con personal tcnico adecuado).


CAPTULO VII: CONCLUSIONES Y RECOMENDACIONES

VII.1 CONCLUSIONES

-La Metodologa propuesta est basada en el libro Tcnicas de
Evaluacin y Medicin del Desempeo de Sistemas de Computacin,
pero fundamentalmente en el trabajo de investigacin realizado con la
valiosa ayuda de los estudiantes de la Facultad de Ingeniera de
Sistemas de la Escuela Politcnica Nacional; por esta razn trata de un
conjunto de tcnicas prcticas que se pueden emplear durante el
transcurso de la primera experiencia del evaluador de sistemas. La
Metodologa tiene implcita una intencionada repeticin de ciertos
trminos que buscan fundamentar las ideas sobre las reglas de
interpretacin de la Metodologa, as como de los conceptos y criterios
fundamentales, las interconexiones entre las tcnicas y la heurstica
empleadas.


-En el Anexo 6 se encuentra un Manual de la Metodologa, que ayudar
a recordar los pasos fundamentales para la realizacin de la Evaluacin
de un Sistema de Informacin, dado que se ha probado su eficacia en la
aplicacin en empresas de muy variada ndole, tanto en el sector pblico
como en el privado.

-El contar con una Metodologa para la Evaluacin del Desempeo de
una Unidad Informtica, ayuda a la productividad de la Empresa. En el
caso particular, sta puede fcilmente adaptarse a las cambiantes
realidades de las tecnologas de la informacin; por ejemplo, ante el
avance del Internet, lo nico que habra que hacer es cambiar los
documentos de trabajo, los parmetros a medirse y/o las herramientas
empleadas. Otro ejemplo constituye la tendencia actual a no formar
unidades informticas en las empresas, sino a contratar servicios
externos de soporte en el rea computacional e informtica.

-Toda Metodologa debe ser validada; en el caso de la propuesta, se
aplic la misma durante cuatro aos del dictado de la materia Tcnicas
de Evaluacin de Sistemas, afinndose la misma a las cambiantes
realidades de las unidades informticas.

-No se puede obtener una Metodologa que sea lo suficientemente general,
que pueda aplicarse en cualquier caso; ni esta debe ser tan especfica que
impida su aplicacin en situaciones similares.

-La experiencia del tcnico es fundamental en la evaluacin, ya que hay
muchos factores que son difciles de transmitir en un conjunto de mtodos a
aplicarse.

-El conocimiento del sistema operativo y sus herramientas, es fundamental
para la evaluacin; as como el conocimiento de la empresa,
fundamentalmente de las personas que trabajan en la Unidad Informtica.

-La aplicacin de la Metodologa ha ayudado a determinar los procesos
comunes, independientes de las plataformas instaladas, que pueden seguirse
para evaluar sistemas; buscando generalizar lo que es razonablemente
posible.

-La subjetividad es un gran limitante en el momento de interpretar los
resultados, sobre todo de aquellos que no son medibles; es decir, de aquellos
que dependen menos del sistema de computacin.


VII.2 RECOMENDACIONES

-Si bien es cierto, la Metodologa propuesta ha sido probada durante cuatro
aos de realizar prcticas en las empresas del medio, y validada en varios
trabajos de pregrado (Tesis de Pregrado terminadas), sto no quiere decir
que est absolutamente depurada o que constituya un camino sine quanum
para realizar evaluacin de sistemas de informacin. Con seguridad habr
que seguir investigando y ajustando la Metodologa al incesante cambio de
la informtica y de la computacin en el mundo (Tesis de Pregrado por
terminarse y en desarrollo).

-Es conveniente investigar sobre las nuevas herramientas de evaluacin,
para validar la Metodologa.

-Es importante aadir las caractersticas para Internet, en la Metodologa
propuesta, ya que, si bien es cierto, su aplicacin es considerada, no se han
realizado prcticas, exclusivamente, en Intranets.

-Sera interesante considerar el Afinamiento de los sistemas, como una
etapa necesaria de la evaluacin de los sistemas de computacin.