jefe informatico

8/3/2019 jefe informatico

http://slidepdf.com/reader/full/jefe-informatico 1/36

El sistema

informáticodentro de la

organizaciónEl jefe de informática

Miquel Colobran Huguet

P03/81029/02136




Índice

Introducción .............................................................................................. 5

Objetivos ..................................................................................................... 6

1. El jefe de informática ........................................................................ 71.1. El jefe de informática y el administrador de sistemas ...................... 7

2. Los planes .............................................................................................. 92.1. Plan estratégico de la organización .................................................. 9

2.1.1. La planificación estratégica ................................................... 9

2.1.2. Metodología .......................................................................... 92.1.3. Componentes del plan estratégico ....................................... 10

2.1.4. El análisis DAFO .................................................................... 10

2.2. Plan de contingencias ....................................................................... 11

2.3. Plan de seguridad y análisis de riesgos ............................................. 12

3. Detección de necesidades de softwareen la organización .............................................................................. 153.1. Detección de necesidades ................................................................. 15

3.2. Etapa de concreción ......................................................................... 16

3.3. Etapa de análisis ............................................................................... 17

4. Implantación/diseño de aplicaciones ........................................... 184.1. Relación de requerimientos .............................................................. 20

4.2. La actualización ................................................................................ 21

4.3. Software estándar .............................................................................. 21

4.4. Software a medida ............................................................................ 22

4.5. La responsabilidad del jefe de informática ....................................... 23

5. Aspectos legales ................................................................................... 26

5.1. Problemas de seguridad .................................................................... 265.2. Software a medida ............................................................................ 29

6. Responsabilidades del jefe de informática ................................... 30

Resumen ...................................................................................................... 31

Ejercicios de autoevaluación ................................................................. 33

Solucionario ............................................................................................... 34

Glosario ....................................................................................................... 35

Bibliografía ................................................................................................ 35



© FUOC • P03/81029/02136 5 El sistema informático dentro de la organización

Introducción

En este módulo, estudiamos el cometido del jefe de informática y su relacióncon la organización y el departamento de informática. En concreto, revisare-

mos el tipo de decisiones que debe tomar y cómo se coordina con la figura del

administrador del sistema informático.

El sistema informático es la herramienta y los administradores, las figuras que

lo mantienen en funcionamiento. Sin embargo, el jefe de informática es la fi-

gura que toma las decisiones sobre la función del sistema informático dentro

de la organización. Decide qué puede hacer con los recursos de los que dispo-

ne el departamento y posee una visión de futuro sobre qué será necesario rea-

lizar. Es decir, cuál debe ser la funcionalidad del departamento de informática

dentro del conjunto de la organización en el momento presente y en el futuro.

También proporcionamos algunos criterios que pueden ayudar a tomar deci-

siones, por ejemplo, en el momento de decidir sobre la implantación desoftware,

o cómo se debe actuar ante problemas de seguridad.




Objetivos

En los materiales didácticos de este módulo incluimos los contenidos y los ins-trumentos para alcanzar los objetivos siguientes:

1. Conocer las responsabilidades del jefe de informática.

2. Comprender las decisiones que debe tomar el jefe del departamento en el

diseño de una aplicación.

3. Saber cómo se debe actuar ante un problema de seguridad.

4. Entender el concepto de plan en una organización y conocer algunos de

los que nos podemos encontrar.

5. Aprender a prever las posibles amenazas y riesgos que pueden poner en pe-

ligro el sistema informático y prepararse para minimizar las consecuencias.




1. El jefe de informática

Para poder ser eficiente, el jefe de informática debe ejercer un papel muy im-portante como transmisor de información entre el departamento de informá-

tica y la organización. Es el puente de comunicación en ambas direcciones

(técnicamente hablando).

Esto quiere decir que el jefe de informática posee información relativa a la

situación de la organización que el personal técnico no es necesario que co-

nozca. Además, el jefe se ocupa de velar por una serie de proyectos que des-

empeñan los administradores (o incluso otros departamentos o aquellos

que se encuentran contratados externamente) relativos a la informática de

la organización.

Tal y como se ve en el gráfico anterior, la figura del jefe de informática es la

que gestiona los recursos del departamento (tanto humanos, como materia-

les). Por lo tanto, debe tener un conocimiento de la organización y del depar-

tamento perfecto para conseguir que los dos elementos se desarrollen lo más

sincronizadamente posible. Debe lograr que el departamento de informática

se ajuste perfectamente a los objetivos de la organización con los recursos que

esta última le facilite. En la práctica, actúa siempre como un canal de comuni-

cación, en ambos sentidos, para detectar necesidades, obtener recursos, ajustar

objetivos, etc.

1.1. El jefe de informática y el administrador de sistemas

Como hemos comentado, el jefe de informática tiene una visión más global

de todo. Por lo tanto, necesita la figura del administrador, que es quien cuida

de los servidores. El administrador le indica la situación y la visión técnica del

El jefe de informática gestiona los recursos del departamento de infor-

mática y actúa de enlace entre el departamento y la organización.




departamento de informática en cada momento. Por lo tanto, le puede aseso-

rar para tomar muchas decisiones sobre software y hardware. En la práctica, la

mayoría de decisiones técnicas se toman con la ayuda del administrador de

sistemas.




2. Los planes

Todas las organizaciones, con el fin de estar coordinadas y preparadas paracualquier situación, siguen una serie de planes que los jefes de cada departa-

mento deben preparar, revisar y tener a punto.

2.1. Plan estratégico de la organización

El plan estratégico es una planificación, normalmente quinquenal, en que se es-

tablece la orientación de la organización para alcanzar los objetivos que se pro-

pone. Este plan estratégico de la organización se debe concretar posteriormente

en un plan estratégico para cada departamento, vinculado al global.

Dado que el jefe de informática debe establecer el plan estratégico del depar-

tamento de informática, observamos cómo es, a grandes rasgos, el plan estra-

tégico de una organización. El de cada departamento parte del plan estratégico

de la organización.

2.1.1. La planificación estratégica

Ante una sociedad cambiante, la organización debe adaptarse para cumplir sus

objetivos. La planificación estratégica es un instrumento útil y necesario para

ajustar el funcionamiento de la organización en el seno de la sociedad.

La planificación estratégica debe convertirse en un instrumento que integre

todos los departamentos dentro de unos mismos objetivos y un marco de tra-bajo común.

2.1.2. Metodología

Se debe recopilar información interna y externa. La externa proviene del aná-

lisis del entorno y se utiliza para identificar las oportunidades y amenazas.

Una planificación estratégica es un conjunto de propuestas realistas

para fijar los objetivos de la organización en un futuro.

La planificación estratégica, para minimizar riesgos y maximizar resul-

tados, debe plantear estrategias y objetivos simples, claros, alcanzables

y mesurables.

Podéis ver un poco más adelantecómo se hace un análisis DAFO.




La información interna permite identificar las fortalezas y debilidades de la

misma organización.

Entre los aspectos fundamentales que debe contener el análisis podemos in-

cluir, por ejemplo, la evaluación de los servicios que se realizan o los sistemas

de administración.

2.1.3. Componentes del plan estratégico

Declaración de la misión

La declaración de la misión simplemente intenta determinar el objetivo final

que se pretende cumplir.

Visión

Es el camino que es necesario mantener para conseguir la misión. La visión

será la guía para las acciones que se llevarán a cabo.

Problema estratégico general

Consiste en determinar los factores internos o externos que pueden afectar a

la consecución de la misión.

Solución estratégica general

Trazar estrategias que permitan alcanzar la misión y superen, por lo tanto, los

problemas estratégicos.

Objetivos y estrategias

Determinar los objetivos e implementar las estrategias es clave en la planifi-

cación. Los objetivos, al menos con respecto a los departamentos, es impor-

tante que sean de tipo cualitativo. Es decir, deben ser cuantificables para poder

medir su cumplimiento y poder formularlos en acciones estratégicas.

Presupuesto y control

Los objetivos y las acciones se deben prever en los presupuestos.

2.1.4. El análisis DAFO

En los últimos años el análisis DAFO se ha convertido en un instrumento de

diagnóstico para la dirección estratégica de la organización. Junto con el diag-

nóstico financiero y el funcional, forman las tres partes básicas para el análisis

interno de una organización.

DAFO es la sigla de: debilidades,amenazas, fortalezas y

oportunidades En inglés, SWOT:strengths, weaks, oportunities

and threats .




El objetivo es concretar en una tabla la evaluación de los puntos fuertes y dé-

biles de la organización con las amenazas y las oportunidades externas. Todo

ello partiendo de la base de que la estrategia pretende conseguir un ajuste ade-

cuado entre la capacidad interna de la organización y su posición competitiva

externa.

Lo más importante es encontrar las variables que nos permitan identificar y

medir los puntos fuertes, los puntos débiles, las oportunidades y las amena-

zas de nuestra organización, que reuniremos en esta tabla. Las fortalezas y de-

bilidades internas son muy importantes, ya que nos ayudan a entender la

posición de nuestra entidad en un entorno concreto. Cada organización debe

conocer cuáles son las variables adecuadas que determinan su posición dentro

del mercado, segmento o sociedad en la que está inmersa.

Una vez definidas estas variables, debemos construir un proceso de benchmarking

o análisis comparativo con las mejores organizaciones competidoras (es posible

que a lo largo de este proceso identifiquemos alguna oportunidad nueva).

Finalmente, construimos el gráfico que recoge las posibles estrategias. En esta

matriz DAFO, estableceremos el análisis del entorno en las columnas (1.ª co-

lumna: amenazas, 2.ª columna: oportunidades) y en las filas, el diagnóstico

de la organización (1.ª fila: puntos fuertes, 2.ª fila: puntos débiles). Cada uno

de los cuatro cuadrantes refleja las posibles estrategias que debe adoptar la or-

ganización.

El estudio de la matriz se realiza analizando aisladamente cada cuadrante.

Por ejemplo, si miramos el primer cuadrante (1-1 puntos fuertes-amenazas)

deberemos identificar cada uno de los puntos fuertes que se encuentren en la

organización, junto con cada una de las amenazas del exterior que existen. Asípues, debemos analizar cada intersección para observar las consecuencias y las

acciones que se pueden derivar de ello.

2.2. Plan de contingencias

El plan de contingencias, aplicado sólo al entorno informático, es un plan que

implica analizar los posibles riesgos a los que puede estar expuesto el equipa-

miento informático y la información que poseemos (en cualquier medio de al-

macenamiento). El objetivo es doble. Por una parte, reducir la posibilidad de

que pueda ocurrir algún percance y, por otra, si ocurre, prever las acciones y

actuaciones que es preciso poner en práctica en estas situaciones.

DAFO Amenazas Oportunidades

Puntos fuertes Estrategias defensivas Estrategias ofensivas

Puntos débiles Estrategias de supervivencia Estrategias de reorientación




Debido al riesgo de que a pesar de todas las medidas que se tomen puede ocu-

rrir un percance, el plan de contingencias incluye un plan de recuperación

de desastres, que tiene el objetivo de restaurar el servicio informático cuanto

antes y minimizar el coste y las pérdidas en la medida en que se pueda.

Para que el diseño del plan de contingencias tenga sentido, se debe presuponer

el peor caso de todos, el desastre total. De esta manera, el plan será lo más

completo posible y podrá incluir toda la casuística.

2.3. Plan de seguridad y análisis de riesgos

Este plan debe velar por la seguridad de todo el equipamiento informático de

la organización. La responsabilidad del jefe de informática es hacerlo y asegu-

rar que se aplicará correctamente.

Es necesario asegurarse de que se tienen en cuenta todas las posibles causas de

riesgos que pueden provocar problemas en el sistema. Se elabora un análisis

de los riesgos, que se basa en calcular la posibilidad de que tengan lugar he-

chos problemáticos, se obtiene una valoración económica del impacto de es-

tos sucesos negativos y se contrasta el coste de la protección con el hecho de

volverla a crear o a comprar:

• Imaginar qué puede pasar (qué puede ir mal).

• Estimar el coste que comportaría para la organización.

• Calcular la probabilidad de que se dé cada uno de los problemas posibles.

Ello permite priorizar los problemas y su coste potencial y desarrollar el

plan de acción adecuado.

El análisis de riesgos pasa, primeramente, por responder preguntas como las

siguientes:

• ¿Qué puede ir mal?

• ¿Con qué frecuencia puede ocurrir?

• ¿Cuáles serían las consecuencias?

Fundamentalmente, evaluar los riesgos representa tener claras las cuestiones

siguientes:

• ¿Qué se intenta proteger?

• ¿Qué valor le da la organización?




• ¿De qué se quiere proteger?

• ¿Cuál es la probabilidad de un ataque?

El procedimiento para realizar un plan de riesgos es el siguiente:

1) Evaluar los riesgos en una reunión del jefe de informática con el resto de

jefes de departamento para tratar sobre los puntos siguientes:

• ¿A qué riesgos, en seguridad informática, debe hacer frente la organiza-

ción?

– Al fuego, que puede destruir equipamiento e información.

– Al robo de equipos y archivos.

– A actos vandálicos que estropeen equipamiento y archivos.

– A fallos en el equipamiento que averíen archivos.

– A errores que dañen archivos.

– A virus, que estropeen el equipo y los archivos.

– A accesos no autorizados, que comprometan la información.

En cuanto se elabora la relación, se debe acordar cómo se puede actuar para

prevenir las causas y cómo para minimizar los efectos.

2) Se debe evaluar la probabilidad de que ocurra cada una de estas causas. Por

ejemplo:

¿Qué probabilidad hay de que ocurra alguna de las circunstancias mencionadas?

• El fuego, que puede destruir equipamiento e información.

– ¿La organización tiene alguna protección contra incendios?

– ¿Son necesarios sistemas de aspersión automática?

– ¿Hacen falta extintores? ¿Los hay?

– ¿Son necesarios detectores de humos? ¿Los hay?

– ¿El personal tiene alguna formación para actuar ante un incendio?

• Fallos del equipamiento que pueden estropear la información.

– ¿El personal informático realiza el mantenimiento de los equipos dentro de

los tiempos previstos?

– ¿Cuáles son las condiciones actuales del hardware?

Y de esta manera, para todas las causas que hayan aparecido en la reunión.

La lista puede ser más larga.¿Encontráis otros puntos?Comentadlos en el foro.




3) Se debe determinar la probabilidad para cada riesgo.

4) Se elabora el resumen de los riesgos ordenados por el factor de riesgo de

cada uno.

Análisis de los puntos débiles en la seguridad de la red informática

Una de las tareas del departamento de informática es estudiar el hardware y el software;su localización, su instalación, etc., todo ello con el objetivo de buscar grietas en la segu-ridad. Cualquier ordenador conectado a la red de la organización puede ser una fuentepotencial para acceder al sistema. Esto se puede aplicar tanto para portátiles, como paraordenadores con módem.

5) Se confeccionará una relación de las tareas actuales que se llevan a cabo

con respecto a la seguridad del sistema general.

• ¿Se realiza una copia diaria de los ficheros críticos de la organización?

• Evitar el robo. ¿Cierre físico de las puertas?

• Evitar el vandalismo. ¿Puerta principal siempre cerrada?

• Problema de los virus. ¿Está controlado todo elsoftware que entra? y ¿se ana-

liza con un software antivirus? Los programas de dominio público y de uso

compartido (shareware), ¿sólo se utilizan si provienen de lugares fiables?

Factores de riesgo

Muy alto

AltoMedio

Bajo

Muy bajo

Tipo de riesgo Factores de riesgo

Robo Alto

Fallos en el equipamiento Medio

Acción de virus Medio

Robo de datos Bajo

Fuego Bajo

Fraude Muy bajo

El plan de contingencias, el de seguridad y el de análisis de riesgos in-

tentan distinguir y prever las situaciones peligrosas, para estar prepara-

dos si alguna de éstas llega a suceder.




3. Detección de necesidades de software

en la organización

¿Por qué se necesita software nuevo?

Responder esta pregunta es casi una cuestión filosófica. En esencia, una orga-

nización es una entidad “viva” (en un sentido amplio). Ello quiere decir que

sus necesidades varían a lo largo del tiempo y, por lo tanto, las necesidades in-

formáticas también. Más concretamente, un software puede tener errores, o

pueden aparecer nuevas versiones que dejan anticuada la última, o a alguna

persona se le ocurren cosas nuevas que mejorarían el rendimiento o la produc-

ción, o cambia el equipo directivo o la cadena de producción, o el método deadministrar, o las leyes, y ello nos obliga a cambiar los programas contables, o

la organización es absorbida por otra más importante que trabaja de una ma-

nera muy diferente, o se cambia completamente el departamento de marke-

ting y ventas, etc. Y todas estas consideraciones son necesidades que pueden

motivar cambios profundos en el software que utilizamos o provocar que se

deba comprar software nuevo.

El hecho de darse cuenta de esta necesidad, la importancia que puede tener

para la organización y el impacto que puede representar para el sistema infor-

mático, requiere cierto tiempo. Básicamente, pasa por las etapas siguientes.

3.1. Detección de necesidades

A menudo, una necesidad es muy evidente, pero en ocasiones es muy difícilde detectar. Puede provenir de muchas fuentes, algunas de las cuales son las

siguientes:

• Desde el CAU. Por lo tanto, a partir de los usuarios que hagan peticiones.

• Desde el CAU. Mediante quejas reiteradas.

• Desde cualquier lugar de la organización que requiere algo, sin saber si es

posible o no técnicamente.

• Desde el mismo departamento de informática, para mejorar el servicio.

• Desde el mismo departamento de informática, para mejorar el rendimiento.

Cuando la informática está implantada en una organización, en mayor

o menor grado, siempre existen necesidades nuevas.

¿Conocéis motivos que hanllevado a la compra o elcambio de softwareen vuestraorganización? Comentadlos en el foro.




• Desde cualquier punto externo a la organización, pero que interacciona

con ésta y tiene problemas.

• Desde la dirección, para analizar relaciones de interorganización e intraor-

ganización.

• La misma organización, para evolucionar.

• El mismo sector informático/de telecomunicaciones, que evoluciona tec-

nológicamente.

Lo más importante, cuando se ha detectado una necesidad, es evaluar si se

puede resolver o no. Esta tarea recae en el jefe de informática que, dependien-

do de la necesidad, puede trabajar con el administrador de sistemas y elaborar

un informe de costes y de tiempo, para valorar si se pone en marcha el proyec-

to o no. El jefe de informática, junto con el consejo directivo de la organiza-

ción, si son proyectos de mucho tamaño, o con el administrador de sistemas,

si son pequeños, deciden la solución que se debe aplicar.

3.2. Etapa de concreción

Ya se ha detectado una necesidad. A pesar de ello, muchas veces se trata de una

cuestión difusa: la persona o las personas que la han generado saben más o

menos qué quieren (muy pocas veces lo saben exactamente), pero además, al

no ser expertos en informática y al no tener conocimiento de la estructura in-

formática de la organización (no deben tener, necesariamente, esta forma-

ción), la expresión de su necesidad es difusa. A pesar de que la expresan con

claridad (muchas veces ellos mismos creen que se expresan claramente), la

“traducción” de lo que dicen, de lo que quieren, etc., en términos informáti-cos y en términos de la estructura informática de la organización, no es nada

evidente.

Por lo tanto, en esta etapa es necesario una tarea que es responsabilidad, gene-

ralmente, del jefe de informática: la concreción de la necesidad. El jefe de in-

formática debe establecer conversaciones, celebrar reuniones, etc., con las per-

sonas que demandan la solución, para que concreten y formalicen su

problema y su necesidad, y se pueda así poner en marcha un estudio o plan de

viabilidad por parte del departamento de informática. También es posible que

en esta etapa tome parte, en cualquier momento, algún técnico que, una vez

más, acostumbra a ser el administrador de sistemas, aunque depende mucho

de la necesidad que se haya generado.

La aparición de una necesidad que debe cubrir el departamento de in-

formática puede llegar por muchas vías.

¿Se os ocurren otros? Podéiscomentarlos en el foro de laasignatura.




Si es posible, en esta etapa recogeremos, además, documentos, papeles, esque-

mas, etc. Sin embargo, debemos tener presente que muchas veces todas estas

necesidades que aparecen cuestan mucho de definir y de precisar, por lo que

es posible que toda la valoración inicial la realicemos sin saber exactamente

qué se quiere.

3.3. Etapa de análisis

Después de haber hablado en la etapa anterior para saber qué se quiere, en eldepartamento de informática se elabora un primer estudio de viabilidad del

proyecto, para determinar cómo puede encajar en el sistema informático ac-

tual o cuál sería la mejor manera de solucionar el problema planteado. Esto es

responsabilidad del jefe de informática, sobre todo en lo referente a los recur-

sos económicos y humanos, ya que el aspecto técnico es una tarea conjunta

del jefe de informática y el administrador de sistemas, o el responsable técnico

que sea necesario según la necesidad planteada.

Prepararemos un informe técnico preliminar en el cual se comentarán los as-

pectos de hardware, software, recursos humanos, económicos y de tiempo, deuna manera aproximada (en el caso de que sea viable). Si la dirección decide

comenzar, ya se hará un análisis bien hecho, correcto y a fondo del problema.

Es muy difícil concretar una necesidad. La comunicación con todas las

personas y departamentos relacionados directamente o indirectamente

con la necesidad puede ser clave para concretar el problema.

Determinar exactamente una necesidad es muy importante para evaluar

el impacto que puede tener en la estructura informática y en la misma or-

ganización.




4. Implantación/diseño de aplicaciones

Como ya hemos explicado en el apartado anterior, en una organización, comoconsecuencia de cambios internos (nuevas orientaciones) o cambios externos,

o, simplemente, al mejorar el funcionamiento, puede aparecer una necesidad.

Esta necesidad puede afectar hasta el punto de que sea necesario introducir

modificaciones importantes de software o incluso que se deba comprar uno

nuevo. Si éste es el caso, nos encontramos con la decisión de:

• ¿Modificar el software que tenemos (si podemos)?

• ¿Comprar software estándar?

• ¿Crearnos un software a medida?

En este apartado proporcionamos unas pautas o indicaciones que pueden ayu-

dar a resolver este problema.

Debemos percatarnos de que todos los pasos los realizan figuras técnicas, pero

con la supervisión del jefe de informática, que es quien toma las decisiones,

en estrecha coordinación con los administradores (técnicos).

Cuando se detecta una necesidad, es el jefe de informática quien toma las de-

cisiones definitivas sobre si se puede satisfacer o no. Solucionarla tiene un cos-

te y, por lo tanto, debe suponerse su viabilidad. El jefe de informática conoce

el plan estratégico de la organización, los recursos económicos, humanos, etc.,




de los que dispone. Con esta información y el informe técnico preliminar que

se ha elaborado en la etapa de análisis de la detección de necesidades, podre-

mos decidir si se puede resolver o no.

Esta necesidad puede llegar a ser compleja, ya que, si se implanta software nuevo,

afecta profundamente a toda la estructura informática y también a la organiza-

ción, dado que modifica la manera de trabajar del personal. A continuación, mos-

tramos un método para intentar ser lo más conservadores que podamos con el

software que tenemos para ajustarlo a la necesidad que se ha creado.

Cada uno de estos pasos es bastante complejo, y el jefe de informática, con-

juntamente con el administrador de sistemas, trabajan unidos para llevar a

cabo esta tarea.

Existen muchas soluciones ante el problema de una necesidad. Intentemos

buscar las que modifiquen la estructura informática lo menos posible.




4.1. Relación de requerimientos

La decisión la tomará el jefe de informática, pero la tarea de elaborar esta re-

lación de requerimientos es conjunta del jefe de informática y el administra-

dor del sistema.

Por lo tanto, después de que el informe técnico preliminar haya pasado por la

dirección y se haya decidido poner en marcha el proyecto, el jefe de informá-

tica, junto con el administrador, establece los requisitos mínimos que debe

cumplir el software. Los aspectos básicos que debe incluir esta relación con-

tendrán:

• Los servidores actuales. Si son heterogéneos, donde deba ubicarse la aplica-

ción. Pueden cambiar en un futuro próximo (planes de actualización, plan

estratégico, etc.).

• Los clientes. Son o pueden ser heterogéneos (planes de actualización, plan

estratégico, etc.). Cada vez hay más portátiles en determinados departa-

mentos. Se debe prever la posibilidad de clientes de diferentes plataformas

o tipos.

• Conexiones remotas/red. Cómo y desde dónde se debe poder acceder a la

aplicación. Cuestiones asociadas a redes locales, intranets, extranets, etc.

• Información pública/privada.

– ¿Debe hacerse parcialmente visible la aplicación?

– ¿Es necesario extraer (exportar) datos para hacerlos públicos o para intro-

ducirlos en otro software de la organización?

• Cuestiones de seguridad asociadas a la red, la información, la aplicación.

• ¿Cómo y qué usuarios pueden acceder a la aplicación? ¿Los usuarios tie-

nen niveles de seguridad o acceden a toda la aplicación cuando han entra-

do? ¿Pueden modificar cualquier información? ¿Pueden imprimir

cualquier listado?

• También es conveniente plantearse la cuestión de configuración/parame-

trización, especialmente en listados. El paso del tiempo provoca que sea ne-

cesario cambiar elementos como, por ejemplo, el logo de la organización.

Software ajustado a las necesidades

Aquí hemos hablado de un software multiusuario, en servidor, con usuarios configura-

bles, con propiedades para las redes y facilidades para extraer datos, posiblemente multi-plataforma en la parte cliente, etc. Y, seguramente, para organizaciones de un ciertotamaño es lo que se necesita. Ahora bien, si nuestra organización es de cinco personas(por ejemplo, un taller mecánico o una tienda), muchas de estas características no sonnecesarias. Ciertamente, con un software monousuario que funcione sobre una sola má-




quina (si tiene usuarios mejor), con listados configurables, que pueda funcionar en unared, pero sólo con un usuario simultáneo, y que funcione correctamente, es suficientepara resolver el problema. El otro estaría totalmente sobredimensionado para las necesi-dades reales de la organización y tendría un coste demasiado elevado. Los mismos fabri-cantes de software elaboran muchas veces el mismo programa en diferentes “medidas” yprecios, según el lugar al que se destina.

En relación con los requisitos, nos debemos plantear la cuestión de si dentrode la organización existe un software que realice, más o menos, lo que se nece-

sita funcionalmente.

4.2. La actualización

Se trata de que comprobemos si es suficiente con actualizar algún software de

los que tenemos en la organización para solucionar la necesidad que se pre-

tende cubrir. La tarea la realizará el administrador del sistema, y la decisión so-

bre la viabilidad de la actualización recaerá en el jefe de informática.

Esta tarea puede ser tan sencilla como examinar las características de la última

versión del software en papel o vía web, o tan compleja como tener que pedir

un CD-ROM de demostración y necesitar un ordenador de prueba para insta-

lar y efectuar una simulación para comprobar si se ajusta a los requerimientospedidos para resolver el problema.

4.3. Software estándar

Esta posibilidad indica que, de momento, no queremos desarrollar softwarepropio, y que buscamos uno que ya lo esté y, al mismo tiempo, que se ajuste

a las necesidades que se desean cubrir. Por lo tanto, debemos buscar, entre

todo el software que se encuentra en el mercado, aquel que se adapte a las ne-

cesidades que tiene la organización. Es una tarea que puede realizar el admi-

nistrador de sistemas, pero que debe supervisar el jefe de informática, ya que

es quien toma la decisión definitiva. Actualmente, el software es bastante pa-

rametrizable y, por lo tanto, la tarea de ver el software que existe y cómo se

puede adaptar a la organización todavía es más compleja.

Queda un último factor, muy importante, que se debe tener en cuenta. Segu-

ramente, ningún software se adapta del todo a las necesidades particulares de

la organización. Todo software estándar, por muy parametrizable que resulte,

Saber qué es necesario, técnicamente, para resolver el problema y para

integrarlo en la estructura de la organización es el primer paso.

Consideramos si algún software de los que tenemos nos sirve.




necesita un poco de esfuerzo de adaptación por parte de la organización, es de-

cir, que debe producirse un ajuste de la organización respecto al software, y del

software con la organización (en esto último consiste, precisamente, la para-

metrización).

Dado que, normalmente, se producen cambios motivados por factores externoso internos en el software, debemos estar bastante seguros de que el proveedor que

nos lo proporciona tiene una estabilidad lo bastante buena para garantizarnos el

mantenimiento del producto en nuevas versiones y la resolución de problemas.

Una vez se ha tomado la decisión, si optamos por un software estándar debe-

mos probarlo con detalle y realizar todo el proceso de implantación en servi-

dores, después, implantarlo a los usuarios, formarlos, etc., para que no resulte

problemático.

La decisión definitiva es del jefe de informática, pero la tarea de rastrear el software

que se halla en el mercado y valorar su utilidad dentro de la organización es, en

gran medida, una tarea del administrador de sistemas.

4.4. Software a medida

La segunda posibilidad implica poner en marcha un proyecto de software, un

departamento de desarrollo de software, un análisis, etc. Por lo tanto, es una

alternativa bastante más compleja para obtener al final un paquete ajustado a

las necesidades de la organización. Una vez se ha elaborado, generalmente no

se acaba la tarea, ya que, como la organización es una entidad “viva”, necesita

modificaciones prácticamente constantes. La organización se encuentra den-

tro de una sociedad que también cambia y, por lo tanto, el paquete de softwarecreado también puede necesitar mantenimiento. Esto supone que el departa-

mento de desarrollo, si es de nueva creación para este proyecto, difícilmente

pueda desaparecer, pues es posible que además del mantenimiento el paquete

vaya creciendo más y más con el paso del tiempo.

En este caso, el jefe de informática toma muchas decisiones estratégicas, ya que

debe aportar el marco de trabajo de la aplicación. El administrador de sistemas

también debe colaborar en crear el marco de trabajo de la aplicación y debe es-

tar presente en todo el proceso de creación de la aplicación. Seguramente, será

responsabilidad del jefe de informática la decisión de quién desarrolla el pro-

yecto, porque depende de si la organización cuenta con departamento de de-

sarrollo o no. Si no tiene, la tarea de desarrollar el software se crea o se contrata

Buscamos software que ya está fabricado, teniendo en cuenta que debe-

remos poner software nuevo dentro de la organización, con todas las

consecuencias que ello supone.

Existen diferentes asignaturasdedicadas a proyectos de software.Podéis consultar: Ingeniería del software e Ingeniería del software estructurado.




externamente. En este último caso, se debe negociar en un contrato la propie-

dad de las fuentes de la aplicación.

4.5. La responsabilidad del jefe de informática

Como ya hemos comentado, el jefe de informática asume la función de deter-

minar el marco sobre el que debe funcionar este software. Tanto si nos decidi-

mos por un software estándar, como si lo hacemos por uno a medida, aquí, un

poco como en el diseño del entorno de usuarios, vuelven a aparecer las cues-tiones siguientes:

• Dónde debe encontrarse la aplicación.

• En qué lugar deben hallarse los datos.

• Qué usuarios accederán a ellos.

• Con qué permisos.

• Sobre qué tecnología se desarrolla (cliente/servidor, etc.).

• Desde qué puntos de la organización se utilizará el software (dentro de la

red, intranet, extranet, etc.).

• Grado de sensibilidad de los datos.

• Nivel de integración de los datos con el resto de aplicaciones.

• ¿Se deben hacer públicos parte de estos datos en la web de la organización?

• ¿Es necesario exportar datos?

Por lo tanto, debemos volver a plantearnos una tabla de soluciones.

Decidir elaborar a medida una aplicación es la última solución, la más

costosa económica y temporalmente, pero se obtiene un software que seajusta completamente a nuestras necesidades.

Datos

Local Remoto

Aplicación Local

Remoto




Datos en remoto. En este caso, probablemente decidiremos que los datos se

ubiquen en una base de datos en un servidor. Esto facilita las copias de seguri-

dad, el mantenimiento y la implantación, especialmente si en la organización

existe un servidor de bases de datos. También facilita la integración y las buscas

futuras dentro de esta nueva base de datos. También resulta más sencillo si hay

que publicar alguna cosa (efectuar extracciones) o controlar permisos.

Software en remoto. En este punto se nos presentan dos alternativas po-

sibles.

1) Programa “tradicional” diseñado para que pueda correr en el cliente o en

el servidor, o un programa con tecnología cliente/servidor que necesita una

pequeña parte instalada en el cliente.

2) Aprovechar la tecnología cliente/servidor para crear una aplicación en la

que el programa cliente se encuentre instalado en los terminales de trabajo:un navegador.

Es el caso de las arquitecturas en las que el front-end (ordenador frontal) es un

navegador que ejerce de cliente y el servidor web ataca las bases de datos. En

medio se encuentra la aplicación servidora real.

Ventajas:

• Funciona para clientes heterogéneos. No es necesario elaborar una versión

cliente para cada plataforma.




• Funciona con portátiles. Es una buena solución para la informática móvil.

• Funciona fuera de la organización. Si existe la posibilidad de que se produz-

can problemas de seguridad se debe instalar sobre un servidor seguro

(HTTPS).

• Normalmente, se programa por módulos y no monolíticamente.

Éste es el esquema de la estructura que se acostumbra a utilizar en estos casos,

ya que es la más segura.

Como la aplicación se ubica por módulos, el mantenimiento y el desarrollo

son más sencillos y, dado que los datos se encuentran en un servidor diferente

al de la aplicación, resulta un método más seguro, porque si llegan a atacar al

servidor web con éxito, no encontrarán los datos, ya que deberían conseguir

llegar a otro servidor; todo lo cual añade una barrera de seguridad más que

traspasar. La seguridad, pues, es más elevada.

El jefe de informática también se debe preocupar de que se lleve a cabo el di-

seño de la documentación y del plan de formación de los usuarios finales, y

de proveer de recursos para poner en marcha el proyecto.

El jefe de informática debe decidir lo siguiente:

• El marco en el que se desarrollará la aplicación.

• El diseño de la documentación.

• El plan de formación.

Podéis consultar los módulos:“Administración de la web” y “Administración de la seguridad”.




5. Aspectos legales

Los aspectos legales son muchos y una vez más debemos insistir en la cuestiónde los asesores legales para consultas, ya que hoy en día la legislación cambia

a menudo.

5.1. Problemas de seguridad

Uno de los aspectos que debe conocer especialmente un jefe de informática es

cómo se debe proceder ante un problema de seguridad. Recordamos que algu-

nos de los problemas de seguridad que se pueden plantear son los siguientes:

• Destrucción/robo de información por parte del personal de la organización.

• Destrucción/robo de información externamente a la organización, por

ejemplo a través Internet.

• Abuso del sistema para finalidades no corporativas.

Cada caso prácticamente es único, y generalizar en este punto puede resultar

contraproducente. Sí que es importante distinguir las cuestiones técnicas de

las decisiones que hay que tomar ante una situación. Las figuras técnicas de-

tectan problemas y avisan sobre su existencia. La figura del jefe asume las de-

cisiones y los técnicos las ponen en práctica. Veámoslo con unos ejemplos.

Ejemplo 1: abuso del sistema por parte del personal con finalidades no

corporativas

Si se sospecha que una persona utiliza el sistema indebidamente –esto lo de-

tectan, por lo general, los administradores de sistema (figuras técnicas)– se

debe comunicar al jefe de informática y, en tal caso, la función de éste consis-tirá en establecer los procedimientos legales dentro de la organización para po-

der verificar que realmente esta persona hace un uso indebido del sistema.

Una vez puestos en marcha estos procedimientos legales, las figuras técnicas

pueden poner en práctica los mecanismos informáticos y técnicos necesarios

para reunir las pruebas y verificar que existe un problema legal. Después, se

procederá con todo el sistema legal necesario, que es responsabilidad del jefe

de departamento, con apoyo del administrador de sistemas, sies necesario.

Ejemplo 2: ataques a servidores web

Esta situación concreta es de las complejas. Según el caso, la decisión que debe

tomar el jefe de informática puede variar, porque hay muchos tipos de ata-




ques. Supongamos un ataque con intención de obtener información de la or-

ganización. Lo que podría ocurrir es lo siguiente:

El administrador de sistemas informa al jefe de informática del tipo de proble-

ma de seguridad, y éste decide hacer lo siguiente:*

• Que el administrador de sistemas ponga en marcha el protocolo técnico del

equipo. Parada, copia, restauración, etc.

• Hablar con la dirección de administración sobre el problema de seguridad

que se ha producido.

• Al mismo tiempo, el responsable de informática informa al cuerpo de po-

licía adecuado para denunciar el hecho, concretar una fecha y consultar los

datos o pruebas del sistema que se puedan necesitar.

• Los administradores de sistema elaboran un informe exhaustivo sobre lo

que ha ocurrido y aportan toda la información que consideren necesaria

en formato CD-ROM. Este informe debe contener lo que ha pasado, cómo

se ha producido la intrusión, cuánto ha durado, de qué manera se ha solu-

cionado, cuál era el problema de seguridad que lo ha provocado y a qué

personas/entidades se ha solicitado ayuda para solucionar el problema

(desde el punto de vista técnico).

• Un informe de los administradores y del jefe de informática, que contengalos desperfectos ocasionados en el sistema y una valoración de los daños

económicos y materiales que ha significado para la organización esta intru-

sión. Dependiendo de la situación real, esto lo puede elaborar un perito ex-

terno a la organización.

• En la fecha fijada, se celebra la reunión con el cuerpo de policía en la que

se presenta el informe técnico, el informe de daños (y el coste estimado),

el CD-ROM con toda la información, pruebas, etc., y el cuerpo de seguridad

se encarga de buscar a la persona que ha ocasionado el daño y actúa poli-cialmente, después judicialmente y, al final, si es necesario, penalmente.

Ahora bien, supongamos el siguiente caso: el administrador de sistemas infor-

ma al jefe de informática de que en el servidor web se ha encontrado instalado

un servidor de pornografía infantil. Como aquí nos encontramos claramente

ante un delito penal, el jefe de informática decide hacer lo siguiente:*

• No modificar nada y reunir la mayor cantidad de pruebas posibles (ficheros

de log , ficheros de datos, imágenes, páginas web, etc.). La finalidad es que

el intruso todavía no sepa que nosotros ya tenemos conocimiento de que

ha entrado en el sistema. Como acabamos de decir, esta acción la pone en

* Siempre es una orientación.

Podéis ver en el módulo“Administración de la seguridad”cuáles son los pasos.

* Siempre es una orientación.

Podéis ver en el módulo

“Administración de la seguridad”cuáles son los pasos.




marcha el jefe de informática y la llevan a término los administradores de

sistema.

• Al mismo tiempo, el jefe de informática informa al cuerpo de policía ade-

cuado para denunciar el hecho, concretar una fecha y consultar los datos

o pruebas del sistema que puedan necesitar.

• Con toda la información extraída del sistema, con la denuncia y la consul-

ta hecha al cuerpo de policía sobre la información que hay que extraer, los

administradores de sistema pueden realizar lo siguiente:

– Restaurar el sistema.

– Recuperar la información de copias de seguridad.

– Asegurar el sistema, si es necesario. Ello significa añadir fragmentos de sis-

tema operativo o de aplicación destinados a cubrir el agujero de seguridad

que pueda haber ocasionado la entrada ilegal del intruso.

Estas operaciones destruyen prácticamente todas las pruebas, pistas/ras-

tros, que haya podido dejar el intruso en el sistema. Por lo tanto, es muy

importante haber extraído antes toda la información que pueda probar al-

go, y haberlo hecho en coordinación con el cuerpo de seguridad del Estado,

para estar seguros de no perder ningún indicio importante. De esta mane-

ra, el servidor afectado vuelve a estar operativo rápidamente.

• Los administradores de sistema elaboran un informe exhaustivo sobre lo

que ha pasado y aportan toda la información que consideren necesaria enformato CD-ROM. Este informe tiene que contener qué ha pasado, cómo

ha sido la intrusión, cuánto ha durado, cómo se ha solucionado, cuál era

el problema de seguridad que la ha provocado y a qué personas/entidades

se ha solicitado ayuda para solucionar el problema (desde el punto de vista

técnico).

• Un informe elaborado por los administradores y el jefe de informática que

contiene los daños ocasionados en el sistema y una valoración de los daños

económicos y materiales que ha significado para la organización esta intru-

sión. Dependiendo de la situación real, esto lo puede realizar un perito ex-terno a la organización.

• En la fecha fijada con el cuerpo de policía, se celebra la reunión en la que

se presentan el informe técnico, el informe de daños (y el coste estimado),

el CD-ROM con toda la información, pruebas, etc., y el cuerpo de seguridad

se encarga de buscar a la persona que ha ocasionado el daño y actúa poli-

cial, después, jurídica y al final, si es necesario, penalmente.

Las dos maneras de actuar son muy parecidas; sin embargo, dependien-

do del caso en concreto, se dan variaciones. No existen, pues, reglas fijas

sobre cómo proceder ante situaciones irregulares.




5.2. Software a medida

Muchas ocasiones, el software a medida se contrata a compañías ajenas a la

misma organización. Estas compañías lo fabrican y lo implantan, pero es ne-

cesaro aclarar en el contrato, con los asesores legales correspondientes, los tér-

minos de propiedad del código fuente y hasta dónde llega éste (librerías, entreotros).

Se han dado muchos casos de compañías que han cambiado de orientación,

se han desvinculado del producto y, por lo tanto, han dejado de dar cobertura

al software que han fabricado, de manera que la organización que ha pedido

un software a medida, en realidad no tiene nada, porque nadie, ni la misma

organización contratando a programadores, será capaz de realizar el manteni-

miento de la aplicación. La compañía tiene un elemento conocido como

know-how, que es el conocimiento que ha desarrollado y que aplica a los pro-

gramas, que no tiene la obligación de facilitar, necesariamente, a la organiza-

ción, pero sobre el que es bueno llegar a algún tipo de acuerdo antes de

empezar un proyecto, de tal modo que haya alguna vía para poder mantener

la aplicación en el caso de que no lo haga la compañía que la ha creado.

El problema legal de la propiedad del código fuente (o de alguna parte

de éste) se debe negociar antes de empezar el proyecto.




6. Responsabilidades del jefe de informática

Una relación aproximada de las tareas/responsabilidades del jefe de informá-tica es la siguiente:

• Elaboración de la parte del plan estratégico del departamento, subordinado

al plan estratégico de la organización, y velar por su cumplimiento.

• Detección de necesidades.

• Concreción de necesidades con el personal de la organización.

• Decisión de implantar necesidades y el método para hacerlo.

• Planes de actualización informática.

• Plan de contingencias.

• Determinación de los permisos de los usuarios en el software.

• Supervisión de los proyectos de software.

• Actuación y respuesta ante situaciones que comprometan la seguridad del

sistema.

• Decisión ante situaciones legales.

¿Consideráis que falta algunaresponsabilidad importante?Comentadlo en el foro de la

asignatura.




Resumen

El jefe de informática es la figura que toma las decisiones estratégicas que afectenal departamento. Debe tener visión de futuro sobre cómo será la informática.

Con los planes se intenta prever qué puede ocurrir; para tomar medidas que

minimicen las consecuencias. Desde cómo evolucionará la informática para

adaptarse, hasta cómo es debido reaccionar ante un desastre.

Detectar, observar o incluso prever necesidades de la organización es casi un

arte. Concretar la necesidad es una tarea de comunicación, y elaborar un aná-

lisis y un informe es una tarea técnica.

Cuando se necesita software nuevo, intentamos adoptar la solución más con-

servadora, ya que en un primer momento parece la vía menos traumática para

la organización. El jefe de informática toma las decisiones, pese a que hay mu-

cho trabajo técnico que hacer.

Ser un buen jefe de informática implica poseer todas las facetas mencionadas

anteriormente, es decir, ser un buen técnico, un buen dialogador, un buen je-

fe, tener visión de futuro, tener capacidad de previsión y muchas cualidades

más que se hallan fuera del alcance de este temario.




Ejercicios de autoevaluación

1. Han entrado en vuestro servidor web y os han cambiado la página inicial. La primera vezla restauráis, pero a lo largo de una semana sucede tres veces. ¿Qué haríais?

2. ¿Cuáles de estas frases son ciertas y cuáles son falsas?a) Las necesidades siempre provienen del CAU.

b) Es mejor hacer a medida un programa, ya que lo podremos modificar cuando queramos.c) El jefe de informática sólo gestiona recursos, no está obligado a tener, necesariamente,grandes conocimientos técnicos.d) Siempre es mejor un software multiplataforma y multiusuario corriente en el servidor, por-que no se sabe nunca cómo crecerá la organización.

3. ¿Cuál de estas frases sobre la implantación de aplicaciones es falsa?a) El último paso es la implementación del software escogido.b) Sólo nos plantearemos crearlo a medida si no encontramos niguno estándar.c) Si la actualización sirve, la utilizaremos de base para crear el software a medida.d) La relación de requerimientos nos sirve en todo el proceso.

4. Relacionad con una flecha cada definición con el concepto que le corresponde:

5. ¿Cuál de estas tareas no es responsabilidad del jefe de informática?

a) Dar acceso a las aplicaciones corporativas.b) Elaborar la parte del plan estratégico del departamento, subordinado al plan estratégico dela organización, y velar por su cumplimiento.c) Detección de necesidades.d) Concreción de necesidades con el personal de la organización.e) Supervisión de los proyectos de software.f) Actuar y responder ante situaciones que comprometan la seguridad del sistema.

Conjunto de propuestas realistas parafijar objetivos de la organización.

DAFO

Definir el marco de una aplicaciónnueva.

Detección de necesidades

Instrumento de diagnóstico dentro de ladirección estratégica

Plan estratégico

Analizar riesgos a los que puede estar expuesto el equipamiento informático.

Plan de contingencias

Relación de requerimientos Responsabilidades del jefe




Solucionario

1. Es usual entre los intrusos intentar acceder a servidores web. Cuando lo han conseguido,una vez se dan por satisfechos, no lo intentan más. Por lo tanto, lo mejor sería restaurar lapágina inicial, mirar los ficheros de log y realizar una busca en el sistema para comprobar queno han cambiado nada más y, finalmente, buscar el agujero de seguridad y taparlo. Esta ac-ción puede comportar varios días de trabajo. Como parece que mientras se raliza esto se vuel-

ve a atacar al servidor por segunda vez, posiblemente intentan provocar al administrador,pero ya no está claro qué buscan, porque no es el procedimiento habitual. Por lo tanto, po-siblemente, lo mejor en este caso es volver a poner la página inicial, pero paralelamente em-pezar a buscar los ficheros de log , registrar las acciones, activar elementos que registrenacciones y observar qué ocurre. Cuando los intrusos atacan por tercera vez, está muy claroque buscan algo. Seguramente, creen que hay información sensible, por ejemplo, númerosde tarjetas de crédito o cuestiones similares, y por ello es posible que el ataque no se limite ala sustitución de la página inicial del servidor, sino que pretendan ir más lejos. En este punto,como ya estaremos atentos, registraremos sus acciones hasta donde queramos, puesto queahora se trata de que ellos no se den cuenta de que nosotros sí que sabemos que se hallandentro de la máquina; por lo cual, pondremos en marcha el dispositivo de registro de accio-nes. Cuando cerremos y aseguremos el servidor, será porque contamos con toda la informa-ción de lo que han hecho que consideramos necesaria para poderles localizar. Cuando sevuelva a abrir el servidor, ya estará arreglado y asegurado. Ellos ya sabrán que nosotros tene-mos conocimiento de que han entrado y, posiblemente, no lo vuelvan a intentar. Si lo hacen,

será por otro lugar o por alguna puerta escondida que hayan dejado antes, pero no a travésdel mismo sitio. Aunque nosotros ya tendremos información suficiente para actuar policial-mente en su contra (y ellos no lo saben).

2. Argumentémoslo un poco.

a) Falso. Muchas sí que provienen del CAU, pero no todas. Por ejemplo, existen necesidadesgeneradas por la dirección.b) Falso con condiciones. Siempre que hablemos de una aplicación grande. Un programa amedida tiene un coste elevado con respecto a un programa estándar. El tiempo de elabora-ción también es muy extenso. La cuestión de la facilidad de modificación es un punto nego-ciado. Podría ser cierto si la organización del departamento tiene un desarrollo propio, demanera que entonces es un proyecto interno de la misma organización.c) Falso. Por ejemplo, en el caso de un proyecto informático, se establece el marco sobre elque se efectuará la aplicación. En la definición de necesidades, también ejerce de interlocutorcon las personas implicadas. Debe poseer grandes conocimientos técnicos.d) Falso. Siempre depende del tamaño de la organización y de su plan estratégico. El softwaredebe ser valorado por la organización y respecto a sus expectativas futuras. En principio, esinformación que posee el jefe de informática.

3. c

4.

5. a




Glosario

DAFO Veáse debilidades, amenazas, fortalezas, oportunidades

debilidades, amenazas, fortalezas, oportunidades f Técnica de diagnóstico para elanálisis interno de una organización. Son las siglas que se ponen en una matriz 2 × 2.sigla: DAFO

logo m Imagen corporativa que identifica una organización. Desde el punto de vista infor-mático, normalmente, es un fichero gráfico.

monousuario adj Dicho del software en el que sólo puede trabajar un usuario cada vez. Esteadjetivo no indica nada sobre la tecnología del software (cómo está elaborado, si se encuentraen un servidor ni dónde se guardan los datos).

multiplataforma adj Dicho del software estándar que puede funcionar sobre arquitecturasdiferentes.

multiusuario adj Dicho del software en que pueden trabajar diversos usuarios a la vez. Esteadjetivo no indica nada sobre la tecnología del software, aunque parece claro que los datos sehallan centralizados en algún lugar común al cual acceden todos los usuarios cuando traba-jan de forma concurrente.

parametrización f Acción de ajustar software estándar a las necesidades particulares de laorganización mediante una configuración, que puede ser por medio de ficheros, ventanas,un programa, etc.

BibliografíaBarceló García, M; Pastor y Collado, J. (1999). Gestión de organizaciones y proyectos

informáticos. Barcelona: Universitat Oberta de Catalunya.

Microsoft Corporation (1997). Windows NT 4.0 Workstation. Kit de recursos. Madrid:McGraw-Hill.

Pfleeger, C. (1997). Security in Computing. Estados Unidos: Prentice Hall.

Piattini, M; Calvo-Manzano, J.; Cervera, J; Fernández, L. (1996). Análisis y diseñodetallado de aplicaciones informáticas de gestión. Madrid: Ra-Ma.

Tena Millán, J. (1989). Organización de la empresa: teoría y aplicaciones. Barcelona: EADA.

jefe informatico

Documents