Temario Oposición a

Técnicos Auxiliares de Informática

(BOE 03 NOV 2015)

Considerando los Reyes, de gloriosa memoria, cuánto era provechoso e honroso

que a estos sus Reinos se truxiesen libros de otras partes, para que con ellos se
ficiesen los hombres letrados, quisieron e ordenaron: que de los libros non se
pagase alcabala, y porque de pocos días a esta parte, algunos mercaderes
nuestros, naturales y extranjeros, han trahido y cada día trahen libros mucho
buenos, lo cual, por este que redunda en provecho universal de todos, e
ennoblecimiento de nuestros Reinos; por ende, ordenamos e mandamos que,
allende de la dicha franquiza, de aquí en adelante, de todos los libros que se
truxeren a estos nuestros Reinos, así por mar como por tierra, non se pida, nin se
pague, nin lleve almoxarifazgo, nin diezmo, nin portazgo, nin otros derechos algunos
por los nuestros Almoxarifes, nin los Desmeros, nin Portazgueros, nin otras
personas algunas, así como las cibdades e villas e lugares de nuestra Corona Real,
como de Señoríos e órdenes e behenias; más que de todos los dichos derechos o
almoxarifazgos sean libres e francos los dichos libros.
Orden de los Reyes Católicos

1
 TODOS LOS TEXTOS DE ESTOS APUNTES LLEVAN LA
SIGUIENTE LICENCIA, EXCEPTO SI SE INDICA LO CONTRARIO

Edición: 1ª Edición Julio 2.015

Título: Temario Oposición a Técnicos Auxiliares de Informática

Autor: http://apuntedecaramelo.blogspot.com.es/

2
 TEMA 1. ADMINISTRACIÓN DEL SO Y SOFTWARE BASE. FUNCIONES Y RESPONSABILIDADES.
CONTROL DE CAMBIOS DE LOS PROGRAMAS DE UNA INSTALACIÓN

1. INTRODUCCIÓN
2. ADMINISTRACIÓN DEL SO Y SOFTWARE BASE
3. FUNCIONES Y RESPONSABILIDADES
3.1. Rutinarias
3.1.1. Inventario
3.1.2. Distribución de sw y control de licencias. Antivirus
3.1.3. Contabilidad
3.1.4. Gestión de sistemas y comunicaciones
3.1.5. Otras funciones
3.2. Incidencias
3.3. Herramientas y protocolos
4. CONTROL DE CAMBIOS DE LOS PROGRAMAS DE UNA INSTALACIÓN

278
1. INTRODUCCIÓN
La administración de sistemas puede definirse como el conjunto de actividades orientadas a configurar y
gestionar un conjunto de equipos informáticos en su aspecto físico y lógico. Comprende también tareas
como la elaboración de documentación o el establecimiento de procedimientos. Desde el punto de vista de
la organización, se requiere autoridad y responsabilidad; desde el del usuario, servicio y cooperación.
El SO (sistema operativo) es el software interfaz entre usuario y máquina. El sw base es el conjunto de
programas que controlan e interactúan con el SO, ofreciendo control sobre el hardware y soporte a otros
programas. Mucho sw base se incluye en el SO. Por tanto, suelen usarse casi como sinónimos software de
base y de sistema, y entenderse así, el conjunto de estos programas y el SO. Ejemplos de software base
serían los demonios que controlan la temperatura de la CPU o las bibliotecas del sistema gráfico. Lo suyo
es hablar de dos tipos de software según el criterio del administrador: software de sistema (en la jerga, el
“hierro”) y de aplicación, siendo este, el dirigido al usuario.
La generalidad de acciones de la administración del software base consiste en la gestión de usuarios, el
control del rendimiento del sistema, copias de seguridad, adición de hardware, actualizaciones, etc. Una
gran dificultad es la diversidad de plataformas tecnológicas. Suelen agruparse en entornos WS y Unix y la
distribución de sistemas. Por tanto, la administración tiende a centralizar su actividad, para ganar en
homogeneidad, estandarización y control.
Otra actividad destacable es la gestión de incidencias y cambios: su registro y solución; y las herramientas y
métodos que se disponen.
Por fin, por su tendencia a la centralización, la administración del sw de sistema ya oculta otra idea, la
administración remota, que difumina la frontera entre la administración de sw de sistema y la gestión de
redes y el sw de red, para lo que se dispone, integradas herramientas de gestión y administración.
2. ADMINISTRACIÓN DEL SO Y SOFTWARE BASE
La administración del sw de sistema la realiza el rol de administrador del sistema. Se encarga de configurar
y gestionar el sistema. Lo ideal es dedicación exclusiva. De un administrador se exigen conocimientos
amplios del sistema, capacidad de decisión, filosofía de mejora continua, eficacia y responsabilidad.
Para realizar sus tareas, el administrador debe seguir una estrategia. De forma similar al ciclo de mejora de
calidad de Deming, podría identificarse esta estrategia como PDCA: planificar, hacer, verificar y mejorar.
El riesgo reside en el “hacer”. Es recomendable, tener la posibilidad de “vuelta atrás”, un cambio reversible,
contando con copias de resplado, clones de máquinas virtuales, o mecanismos similares. Del mismo modo
interesa hacer cambios pequeños e incrementales, probándose en caso que se pudiera. Para las pruebas,
es conveniente contar con un entorno de preproducción o maqueta: un entorno de prueba. Una vez
verificados los cambios, se aplicarían y se monitorizan, auditan y analizan para seguir buscando mejoras y
anticipación a problemas.
El perfil de administrador del sistema suele denominarse con el poco original nombre de “administrador” o
“superusuario”. Se le dota de todos los privilegios, lo que implica control sobre todos los archivos y
comandos. En entornos Unix también se conoce como ‘root’ y se asocia al grupo ‘root’. En entornos WS se
conoce como Administrador o Administrador de Dominio y se asocia al grupo administradores.
En entornos Unix, la herramienta sudo (hacer de superusuario, en inglés) permite a otros usuarios ejecutar
comandos con perfil de administrador. El fichero /etc/sudoers define esta funcionalidad. Al ejecutar un
comando en forma sudo se pedirá contraseña de administrador. Esto es útil ya que no debe usarse una
cuenta privilegiada para acciones rutinarias, por lo que sudo, es una opción ágil.
La administración del sw de sistema puede clasificar sus tareas, en las rutinarias, o planificadas (se
exponen en el siguiente punto) y tareas aleatorias, o incidencias. Las incidencias son situaciones anormales
en el funcionamiento del sistema. Podría decirse, irónicamente, que son más normales que anormales, por
su frecuencia. La gestión de incidencias es el proceso tendente a minimizar el impacto sobre el sistema de
un hecho que afecta a su funcionalidad y se ha materializado.
Por su “normalidad”, a veces, la gestión de incidencias, o el “soporte informático” se externaliza por parte de
una organización, lo que obliga a establecer unos acuerdos contractuales para definir responsabilidades y
niveles de atención. A este contrato o acuerdo se le llama SLA acrónimo inglés de Service Layer Agreement
o acuerdo de nivel de servicio. Si el SLA se da entre departamentos de una misma organización, como en
un grupo de empresas, puede recibir otros nombres similares.
El SLA debe recoger los objetivos a los que se compromete la función informática mediante indicadores
concretos, como el tanto por ciento de disponibilidad, tiempo y horario de respuesta, tiempo medio entre
fallos (MTBF), número de incidencias pendientes, etc. También se incluyen las responsabilidades y
penalidades en caso de incumplimiento.
279
Preguntas de EXAMEN
La siguiente pregunta de examen puede servir de ejemplo, sobre lo que conocer de este epígrafe.
Una incidencia es una situación que se da…
Sobrevenida al normal funcionamiento de un sistema informático Al producirse un cambio de versión
Cuando se produce una migración a un sistema distinto Al producirse una queja de usuario
3. FUNCIONES Y RESPONSABILIDADES
Las funciones y responsabilidades de la administración de sistemas poseen un carácter local, en cuanto que
administración de una máquina concreta y otro global, en lo que se refiere al sw de sistema del entorno de
red. La tendencia es la integración. Y suele concretarse en utilidades y herramientas con un único interfaz.
3.1. Rutinarias
Entre las funciones y responsabilidades rutinarias de la administración del sw de sistema se identifican:
3.1.1. Inventario
Una correcta gestión de sistemas comienza con un inventario de los recursos hw y sw de la organización.
De especial interés es el caso de externalización; debe reflejarse en el SLA. El nivel de detalle variará en
función de las necesidades, aunque al menos deben incluirse elementos hw, sw y de red.
Los elementos hw incluyen equipos y su configuración. El sw aplicaciones y componentes usados en cada
equipo en su respectiva versión. Los recursos de red incluirán los mapas y grupos de trabajo conectados.
Los inventarios pueden realizarse con herramientas automáticas que exploran los equipos extrayendo la
información. La instalación de nuevos componentes, o la actualización, obliga a actualizar el inventario.
3.1.2. Distribución de sw y control de licencias. Antivirus
La distribución de sw suele automatizarse con herramientas integradas, en general, con soporte a varios
tipos de entornos y redes, registro de operaciones y actualización de inventario.
En caso de sw comercial deben controlarse las licencias para no incurrir en problemas legales. La gestión
de licencias en equipos locales, puede ser más sencillo, pero en sistemas distribuidos debe verificarse que
el número de ejecuciones simultáneas no supere el número de licencias autorizadas.
Como ayuda para el control de licencias se pueden usar herramientas de inventario que indiquen cuántas
instalaciones de cada aplicación existen en los equipos. También son útiles herramientas específicas de
control de licencias, que ofrecen la posibilidad de bloquear la ejecución si se sobrepasan las condiciones del
contrato. Otras posibilidades son la reubicación de licencias entre servidores, gestión de colas de usuarios
para licencia, liberación de licencias no usadas, etc. El uso de estas herramientas reduce los costes de
adquisición de licencias y evita problemas legales.
Estos aspectos son de especial atención en antivirus, por su constante actualización, que además, suele
hacerse en entornos de red. La organización valorará el uso de antivirus en local, en servidor o ambos.
3.1.3. Contabilidad
Se entiende por contabilidad la obtención de datos y estadísticas de uso de los sistemas como puedan ser
el tiempo de conexión de usuario, uso de cuotas de almacenamiento, tiempos de acceso, carga de
procesador y de red, o similares, considerados de interés. El análisis de la información permitirá
dimensionar los sistemas, ajustándolos a las necesidades reales.
3.1.4. Gestión de sistemas y comunicaciones
La gestión de sistemas se basa en su monitorización para el control de la operativa. Su acción clave es
establecer condiciones umbral que marcan la normalidad del funcionamiento. Superados los umbrales se
pueden dar anomalías que obliguen al análisis. La situación anómala, se podrá tratar como incidencia,
siguiendo los procesos documentados (procedimientos) de la organización.
La administración de sistemas y comunicaciones genera su integración natural y la conveniencia de la
administración remota. Las herramientas gráficas de mapas de red ofrecen una visión panorámica de la
topología de red que facilitan al administrador información de gestión de red, en particular para identificar
anomalías que deriven en problemas. Las herramientas de control remoto de sistemas permiten la
centralización de la gestión, con el incremento de productividad que supone. Se engloban en lo que se
conoce como RAT (Remote Administration Tool) y el ejemplo típico es VNC (Virtual Network Computing) de
AT&T Laboratories Cambridge, de libre distribución o la propietaria PCAnywhere de Symantec.

280
 3.1.5. Otras funciones
Otras actividades relacionadas con la administración del sw de sistema, que por su extensión, no se
desarrollan aquí, son la gestión de colas de impresión e impresoras, del almacenamiento, la planificación de
copias de seguridad (backups o respaldos) o la gestión de cuentas de usuarios, por citar las más
inmediatas. Algunas de estas tareas se exponen en los temas de administración de redes de área local.
3.2. Incidencias
Cuando se dan situaciones anómalas, no necesariamente graves, la administración de sw de sistemas, el
administrador, realiza funciones y adquiere responsabilidades en relación a la situación planteada.
El punto de partida de estas funciones y responsabilidades se encuentra en el SLA, el acuerdo del nivel de
servicio, que puede ser interno o un contrato entre organizaciones. Se suelen identificar, entre otras, la:
Resolución de incidencias y cambios con seguimiento trazado de principio a fin
Información a usuarios y entidades que se establezcan de las acciones sobre el sistema
Información a la dirección sobre situaciones excepcionales o de especial gravedad
Análisis del grado de satisfacción del usuario y la calidad del servicio percibida
Estandarización y centralización de los procedimientos de gestión.
Además de las métricas de seguimiento es interesante obtener una valoración del usuario sobre la
percepción de la calidad del servicio mediante una “encuesta de satisfacción de usuarios” (CSS, Customer
Satisfaction Survey). El análisis del resultado contribuye a mejorar el servicio.
Para el trato de incidencias, se hace necesario centralizar operaciones y personal, de forma que la
categorización de incidencias asigne el personal indicado al problema concreto. La categorización de
incidencias consiste en su clasificación por criterio de gravedad, buscando la eficiencia de la respuesta. Una
categorización típica, de menor a mayor grado de gravedad puede ser la siguiente.
Categoría 4. Incidencias rutinarias o que en un futuro podrían ocasionar problemas.
Categoría 3. Incidencias de fácil solución. En el peor caso afectarían a pocos usuarios.
Categoría 2. Incidencias de riesgo grave predecible. En caso de producirse llevan asociado un largo
proceso de recuperación o podrían detener un sistema o aplicación.
Categoría 1. Incidencias urgentes. Problema complejo que paraliza la operación y afecta a muchos
usuarios. La situación puede no tener vuelta atrás o proceder de la combinación o evolución de
incidencias de categorías inferiores.
Categoría 0. Incidencias de emergencia. Situación grave que paraliza todo el servicio.
La gestión de incidencias puede automatizarse con herramientas especializadas, que permitan su apertura,
seguimiento y solución, entre otras funcionalidades. Cada incidencia se identifica con un código o, en el
argot, tique. Son herramientas comunes en los departamentos de atención al cliente y soporte técnico (help
desk). Se pueden clasificar en:
Control de llamadas. Básicas. Permiten abrir, gestionar y cerrar incidencias y la posibilidad de elaborar
estadísticas e informes.
Gestión de problemas. Disponen de una BBDD de configuración, incidencias y cambios. Permiten realizar
inventarios y responder a una escala de problemas con control de flujo.
Herramientas integradas. Son las más completas y costosas. Integran gestión de configuración e incluyen
sistemas basados en el conocimiento. Estos sistemas asesoran en la resolución de incidencias analizando
incidencias previas resueltas.
Entre las empresas que desarrollan herramientas de incidencias y cambios destacan Remedy (herramienta
ARS), Artistry, Astea, Applix y Platinum.
3.3. Herramientas y protocolos
Es difícil encontrar un sw que integre el soporte a todas las funciones y responsabilidades. Esto obliga al
administrador a manejar distintas herramientas. Pero existen plataformas de gestión muy adaptadas, con
características comunes, como el interfaz gráfico, soporte a varios protocolos estándar de monitorización y
gestión remota de dispositivos, soporte para BBDD o interfaces de programación de aplicaciones (API).
La arquitectura de gestión suele ser cliente servidor. El dispositivo monta un servidor (llamado agente), que
responde con su información a la parte cliente de la estación gestora. El servidor del dispositivo (agente)

281
puede enviar alarmas en función de la configuración de sus umbrales. Los protocolos típicos de gestión
suelen ser SNMP o CMIP.
Las plataformas permiten incrementar su funcionalidad con aplicaciones de terceros para gestionar sw de
base o dispositivos propios. En general son más potentes en entornos Unix. De las propietarias más
conocidas destacan HP Openview, Spectrum (Cabletron Systems), Tivoli (IBM), LMS (Intel, Landesk
Management Suite), SMS (Microsoft, Systems Management Server), SunNet Manager (Sun) o Unicenter de
Computer Associates. Entre las plataformas libres citar Scotty/Tkined, OpenNMS y gxsnmp.
Los protocolos de gestión establecen las normas de comunicación entre agentes y estaciones de gestión.
Hay que conocer los siguientes:
SNMP (Simple Network Management Protocol). Protocolo simple, constituido como estándar. Sus
archivos de BBDD se denominan MIBs (Management Information Base).
CMIP (Common Management Information Protocol). Cuando en 1987 se planteó el desarrollo de
protocolos para gestión de red se propuso SNMP como solución a corto plazo y CMIP a largo. Es
más formal y potente que SNMP, aunque menos usado. La implementación de CMIP sobre TCP/IP
se llama CMOT y su adaptación sobre LLC, CMOL.
DMI (Desktop Management Interface). Definido por el consorcio Desktop Management Task Force.
El objetivo es definir una arquitectura abierta para gestión de equipos y sw. Usa archivos de interfaz
de gestión (MIF, Management Information Format) para especificar características de los productos.
Es compatible con Plug and Play para configuración de archivos de BBDD y con SNMP.
Por su importancia, deben conocerse algunos aspectos de SNMP. El entorno de gestión se basa en
procesos agente (en dispositivos) y procesos gestores (en estaciones de gestión) comunicados con SNMP.
Los agentes recopilan información del dispositivo de red en que se ejecuta, creando una estructura
jerárquica de información llamada MIB. Las estaciones de gestión acceden a las MIB con operaciones de
lectura y escritura. El agente puede enviar alertas (trap) a la estación gestora para notificar incidencias.
SNMP usa los puertos 161 y 162 SNMPv2-MIB::sysDescr.0 = STRING: Hardware: x86 Family 6 Model 9 Stepping 5
UDP para recibir los trap. AT/AT COMPATIBLE - Sw: Windows 2000 v 5.1 (Build 2600 Uniprocessor Free)
Una comunidad SNMP (SNMP SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.311.1.1.3.1.1
community) es un grupo formado por DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (444424) 1:14:04.24
dispositivos y las estaciones que los
SNMPv2-MIB::sysContact.0 = STRING: idefix
gestionan. Se usa un nombre de
comunidad para identificar cada SNMPv2-MIB::sysName.0 = STRING: IDEFIX
grupo y asociar las operaciones […]
soportadas por los agentes. Los
IF-MIB::ifIndex.2 = INTEGER: 2
dispositivos pueden pertenecer a
una o varias comunidades. No IF-MIB::ifDescr.1 = STRING: MS TCP Loopback interface
responden a estaciones de otra IF-MIB::ifDescr.2 = STRING: Intel(R) PRO/Wireless LAN 2100 3B Mini PCI Adapter
comunidad a la que no pertenezcan.
IF-MIB::ifDescr.3 = STRING: NIC Fast Ethernet PCI Familia RTL8139 de Realtek
Las comunidades SNMP son […]
cadenas de texto que suelen usarse
a modo de claves de autentificación. IF-MIB::ifPhysAddress.2 = STRING: 0:4:23:66:ee:ad
Es habitual usar las comunidades IF-MIB::ifPhysAddress.3 = STRING: 0:c:6e:8a:f8:39
predeterminadas “public” (lectura) o […]
“private” (escritura).
Existen 3 versiones de SNMP: SNMPv1 fue la primera versión, v2 es la más usada y v3 se espera que sea
el futuro estándar. Los puestos de trabajo también pueden monitorizarse con SNMP. En el cuadro se
muestra un ejemplo de listado de una MIB.
Preguntas de EXAMEN
NO es responsabilidad de un administrador de SO:
Crear cuentas de usuario Controlar el acceso físico al CPD
Monitorizar la carga de los sistemas y su rendimiento Gestionar las copias de seguridad
Una tarea del administrador de sistemas es:
Crear cuentas de usuario Realizar backups
Monitorizar la carga de los sistemas Todas las anteriores

282
4. CONTROL DE CAMBIOS DE LOS PROGRAMAS DE UNA INSTALACIÓN
Es el método de evaluación y aprobación de las modificaciones realizadas a los elementos de la
configuración sw durante su ciclo de vida.
El control de cambios, comienza definiendo el concepto de elemento de configuración (EC). Es aquél
elemento de un sistema sin el cual se pierde una funcionalidad identificada. La definición de EC depende de
los gestores y podrá tener mayor o menor nivel de detalle. Hay que valorarlo. La gestión de configuración es
el control de los elementos de configuración del sistema.
Se suelen distinguir 3 tipos de control: individual, formal y de gestión. El primero se da antes de aprobarse
un nuevo elemento; el de gestión aprueba el cambio; y el formal se realiza en la fase de mantenimiento.
Control individual. O informal. Un elemento de configuración bajo control individual, permite que se cambie
la documentación sin más. Aunque se mantiene un registro informal de revisiones, no se incluyen, en
general, en la documentación. El control individual se aplica en las etapas importantes del desarrollo del
documento y se caracteriza por cambios frecuentes.
Control de gestión. Implica un procedimiento de revisión y aprobación de cada cambio en la configuración.
Como en el anterior, el control a nivel de proyecto se da en el proceso de desarrollo pero se usa después de
haberse aprobado un elemento de configuración sw. Este nivel de control de cambios se caracteriza por
tener menos cambios que el individual. Cada cambio es registrado formalmente y es visible para la gestión.
Control formal. Se da en la fase de mantenimiento del ciclo de vida sw (el producto está en producción). El
impacto de cada tarea de mantenimiento se evalúa por un Comité de Control de Cambios (CCC), que
aprueba las modificaciones de la configuración software.
A menudo se establecen mecanismos de arreglo rápido (quick-fix).
El procedimiento quick-fix no debe involucrar otros niveles de control
de cambios, pero sí proporcionar significados temporales para
modificación rápida de la configuración sw en situaciones de
emergencia.
El proceso de control de cambios se aplica, cuando un EC sw se
modifica. El flujo del proceso de control de la GCS (gestión de
configuración sw) se ilustra en la figura.
Una necesidad de cambio genera una petición. La petición se trata,
teniendo en cuenta el compromiso entre los aspectos técnicos y de
gestión y generando un informe de cambios que se evaluará por el
Comité de Control de Cambios (CCC). La petición se aprueba o
rechaza y se notifica al peticionario del cambio. Para cada cambio
aprobado, se genera una Orden de Cambio (OC), que lo describe,
teniendo en cuenta las restricciones a respetar y los criterios de
revisión y auditorías.
El Comité de Control de Cambios (CCC) es el órgano que gestiona los aspectos relacionados con la GCS.
En general, está compuesto por representantes del usuario/peticionario y del equipo de desarrollo. Para
pequeños proyectos, el CCC puede estar formado por un representante del usuario, peticionarios y
desarrolladores.
En proyectos de envergadura, el CCC puede estar organizado en una jerarquía que analice los problemas
del sistema, del hardware y del software por separado. El CCC puede llegar a formar parte del desarrollo del
proyecto software. Entre sus funciones se encuentran:
Analizar el impacto de cambios de entidad en el sistema
Categorizar y dar prioridad a los cambios conforme se
piden y aprueban
Intervenir en conflictos entre entes implicados en cambios
Garantizar que las propiedades de mantenimiento de
registro y contabilidad se cumplan  
Las auditorías de configuración se centran en comprobar que se
ha realizado el cambio conforme a la orden de cambio de
ingeniería (OCI) y se han incorporado modificaciones adicionales,  
además de comprobar que:
Se ha realizado una revisión técnica formal para comprobar la corrección técnica

283
 Se han seguido los estándares de ingeniería del software
Se marcan los cambios en el EC, indicando fecha y autor del cambio y se refleja en su identificación
Se han seguido los procedimientos para señalar el cambio, registrarlo y divulgarlo
Se han actualizado todos los EC implicados
Por fin, la generación de IEC (informes de estado de la configuración) responde a las preguntas sobre qué
ocurrió, quién realizó el cambio, cuándo ocurrió y a qué elementos ha afectado. El flujo de información del
proceso de generación de los IEC se aprecia en la figura anterior.
Preguntas de EXAMEN
En Linux en cuanto a instalaciones y desinstalaciones de software:
Un inconveniente es que se debe estar conectado para instalar sw ya que se hace uso de los comandos
apt, rpm, urpmi... que se conectan a diferentes repositorios para descargar los paquetes de instalación
Los gestores de paquetes para instalar sw como apt, rpm, urpmi necesitan definir una serie de fuentes o
repositorios desde donde descargar los paquetes de instalación, para ello, cada gestor de paquetes cuenta
con comandos orientados a su definición y actualización
Los repositorios asociados a un gestor de paquetes dependen de él y la versión del SO. Para mantener las
últimas versiones o actualizaciones sw se recomienda instalar la distribución del SO más reciente
Los gestores de paquetes para instalar sw como apt, rpm, urpmi solo permiten instalar paquetes. Para
desinstalar sw se debe conocer los directorios de los archivos. Suelen ser /bin y /sbin para borrarlos
directamente
El acrónimo que NO se corresponde con un protocolo de gestión de dispositivos es:
CMIP SNMP SMS CMOT 
Un Centro de Atención al Usuario se encarga directamente, en relación a los usuarios, de:
Realizar sus copias de seguridad Instalar sus aplicaciones
Gestionar sus incidencias Inventariar sus recursos
De la ejecución de procesos batch, para generar listados o actualizar BBDD, se encarga el área de:
Desarrollo Seguridad Comunicaciones Producción 

284