Escaneando La Informática

Escaneando la Informática
Escaneando la
Informática
Maria Jesús Marco Galindo

Josep Maria Marco Simó
Josep Prieto Blázquez
Ramon Segret Sala (eds.)
Primera edición en lengua castellana: julio 2010
© Joan Arnedo Moreno, Jordi Cabot Sagrera, Isabel Guitart Hormigo, Francisco Javier Noguera Otero,
Rafael Macau Nadal, Maria Jesús Marco Galindo, Josep Maria Marco Simó, Joan Antoni Pastor Collado,
Josep Prieto Blázquez, Daniel Riera Terrén, Jordi Tubella Murgadas, José Ramón Rodríguez Bermúdez,
M.Elena Rodríguez González, Ramon Segret Sala, del texto
© Imagen de la cubierta: Istockphoto

© Editorial UOC, de esta edición
Rambla del Poblenou, 156
08018 Barcelona
www.editorialuoc.com
© Realización editorial: Sònia Poch (spoch44@gmail.com)
ISBN: 978-84-9788-925-4
Depósito legal:
Impresión:
Ninguna parte de esta publicación, incluyendo el diseño general y de portada, no puede ser copiada, reproducida, alma-
cenada o transmitida de ninguna forma ni por ningún medio, tanto si es eléctrico, como químico, mecánico, óptico,
de grabación, de fotocopia, o por otros medios, sin la autorización previa por escrito de los titulares del copyright.
Autores
Joan Arnedo Moreno

Ingeniero Informático y Doctor en Informática por la UPC, desde 2004 es profesor de los Estudios
de Informática, Multimedia y Telecomunicación de la UOC, en el área de redes y seguridad.
Actualmente es también coordinador académico el master Cisco Networking Academy Program y
Instructor oficial Cisco (CCAI, Cisco Certified Academy Instructor)
Jordi Cabot Sagrera

Licenciado y Doctor en Informática por la UPC, desde 2004 es profesor propio a los Estudios de
Informática, Multimedia y Telecomunicación de la UOC, coordinando diversas asignaturas dentro
del área de Ingeniería del software y co-dirigiendo el Posgrado del mismo nombre. También ha sido
investigador visitante al Politecnico di Milano y en la University of Toronto. Investiga en temas de
modelización y calidad del software, generación automática de código e ingeniería web entre otros.
Hace difusión de todos estos temas desde su portal sobre lenguajes de modelización: modeling-lan-
guages.com
Isabel Guitart Hormigo

Licenciada en Informática y Diploma de Estudios Avanzados por la UPC. Master en comunicación
y liderazgo por la UPF. Desde 2002 es profesora del área de Sistemas de Información en los Estudios
de Informática, Multimedia y Telecomunicación de la UOC. Ha ejercido de consultora en la UOC
(2000-2003) en asignaturas del área de ingeniería del software. Ha diseñado, dirigido y coordinado
programas de formación continua del Instituto Internacional de Posgrado de la UOC (2005-2010).
Actualmente es directora académica del Master de SAP Solutions y coordinadora académica del
Master en Business Intelligence de la UOC. Anteriormente ha ejercido como analista de sistemas en
el departamento de informática de la EUETIT.
Francisco Javier Noguera Otero

Ingeniero en informática por la UAB es actualmente Chief SW Engineer en Techideas.com y ha par-
ticipado en múltiples proyectos de investigación financiados por la Unión Europea. Sus ámbitos de
especialización incluyen la comunicación distribuida P2P y los sistemas encastados en Linux.
Colabora con la UOC desde el año 2005, ejerciendo de consultor en las asignaturas Programación
Orientada a Objetos, Taller de Java y dirigiendo proyectos de Comercio Electrónico en Entornos de
software Libre.
Rafael Macau Nadal

Licenciado en Matemáticas, Informática y Periodismo, es profesor y director de los Estudios, de
Informática, Multimedia y Telecomunicación de la UOC desde 2001. Ha desarrollado diferentes car-
gos ejecutivos y de dirección de sistemas y tecnologías de información tanto en el sector privado
como en el público. Sus intereses de investigación y docencia están centrados en los sistemas de
información, la ingeniería de los servicios, y la administración de personas, en especial en compa-
ñías de servicios intensivas en conocimiento.

Licenciada en Informática, master en Dirección y Organización de Empresas por la UPC y master
en Sociedades de la Información y el Conocimiento por la UOC, ha ejercido como profesional de
la informática en el sector de banca y ha sido profesora del departamento de Lenguajes y Sistemas
Informáticos de la UPC. Desde 1999 es profesora de los Estudios de Informática, Multimedia y
Telecomunicación de la UOC donde ha sido también directora de los programas de Ingeniería
Técnica en Informática de Gestión y de Ingeniería en Informática.
Licenciado en Informática por la UPC y Master en Sociedad de la Información y el Conocimiento por
la UOC, ha ejercido como profesional informático en el ámbito del control industrial y, ya en la UOC,
ejerció de consultor, por los Estudios de Informática, Multimedia y Telecomunicación, del área de
Bases de Datos desde 2000, incorporándose como profesor en 2001. Desde 2003 es director de progra-
ma de la Ingeniería Técnica en Informática de Gestión. Su docencia está relacionada actualmente con
la organización y desarrollo de los sistemas de información, y con la administración de organizacio-
nes. Sus intereses de investigación giran alrededor de la adquisición y organización de los sistemas de
información, en especial en el sector público.
Joan Antoni Pastor Collado

Licenciado y Doctor Ingeniero en Informática por la UPC, graduado por el Global Senior
Management Program de la Graduate School of Business de la University of Chicago y de la IE
Business School, y Master en Liderazgo y Gestión de la Ciencia y la Innovación por las universida-
des UB, UAB y UPF. Es profesor de la UOC desde 2007, universidad de la que ya había sido consul-
tor y autor anteriormente, y también profesor de la UPC desde 1987. Ha desarrollado diferentes car-
gos de dirección y gestión universitaria y actualmente lidera el grupo de investigación en Servicios
y Sistemas de Información en la UOC, también en colaboración con el Grupo de Investigación
Consolidado MPI y el GMC de la UPC. Su tarea tanto docente como de investigación gira en torno
a los sistemas de información, su dirección, gestión, provisión, ingeniería e implantación, así como
más recientemente la ingeniería y gestión de servicios y la innovación curricular en el ámbito TIC.

Licenciado en Informática por la UPC y Doctor por la UOC. Desde 1998 trabaja como profesor pro-
pio de los Estudios de Informática, Multimedia y Telecomunicación de la UOC, desde el año 2001
es director de programa de la Ingeniería Tècnica Informática de Sistemas y desde el año 2008 es sub-
director de los mismos estudios. Su línea de investigación se centra principalmente en la prospecti-
va y aplicaciones tecnológicas a nivel de las TIC, habiendo participado en diversos proyectos de
comunicaciones sin hilos, herramientas de aprendizaje en entornos virtuales y más concretamente,
en el diseño y desarrollo de los Laboratorios Virtuales de la UOC.
Daniel Riera Terrén

Ingeniero y Doctor Ingeniero en Informática por la UAB, es director del Grado de Ingeniería
Informática de la UOC. Trabaja en esta universidad como profesor propio desde septiembre de 2005,
fue consultor de la asignatura de Estructura de la Información entre los años 2002 y 2006 y ha ejer-
cido como Director de Programa de la Ingeniería en Informática desde 2007. Adicionalmente, ha
sido profesor de Algoritmos y Programación, y de Lenguajes de programación en la UAB. Su ámbi-
to de investigación es la Optimización y Simulación con herramientas de Programación con
Restricciones.
Jordi Tubella Murgadas

Licenciado y Doctor en Informática para|por la UPC, es Profesor Titular de Universidad en la UPC
y Profesor Consultor en la UOC desde 1997. A nivel de docencia ha sido profesor responsable de las
asignaturas de tipo introductorio dentro del área de arquitectura de computadores. Actualmente es
el Jefe de Estudios de la Fase de Selección en la FIB (Facultad de Informática de Barcelona de la UPC).
Forma parte del grupo de investigación ARCO (Arquitectura i Compiladors), especializándose en el
diseño de procesadores con el objetivo de elevar las prestaciones en cuanto a rendimiento y de dis-
minuir el consumo que requieren.
José Ramón Rodríguez Bermúdez
Licenciado en Filosofía y Letras, PDG (Programa de Dirección general) del IESE y Cuerpo Técnico
de la Seguridad Social. Tiene más 25 años de experiencia como consultor y directivo en empresas
de sistemas y tecnologías de la información, como Ernst&Young (actual CapGemini),
PricewaterhouseCoopers (actual IBM) y el Ayuntamiento de Barcelona, donde fue gerente de
Organización y Sistemas y consejero delegado del IMI. Desde 2003 es autor y colaborador docente
de la UOC en las materias de Gestión de proyectos informáticos y Dirección de tecnologías de la
información.
M. Elena Rodríguez González

Licenciada en Informática por la UPC. Vinculada al área de bases de datos, ha sido consultora en la
UOC desde el año 1998 al 2001, cuando se incorpora como profesora de los Estudios de Informática,
Multimedia y Telecomunicación de la UOC. También es profesora asociada en el Departamento de
Ingeniería de Servicios y Sistemas de Información de la UPC. Ha sido autora de materiales didácti-
cos relacionados con las bases de datos. Sus intereses de investigación incluyen la descripción de
materiales de aprendizaje de acuerdo a estándares y mediante el uso de ontologías con el objetivo
de facilitar el proceso de aprendizaje tanto en entornos virtuales como semipresenciales.
Ramon Segret Sala

Ingeniero Industrial y licenciado en Informática por la UPC, ha ejercido como profesional de la
informática especializado en base de datos en IBM y ha sido profesor del departamento de
Lenguajes y Sistemas Informáticos de la UPC. Hasta el 2004 fue profesor de los Estudios de
Informática, Multimedia y Telecomunicación y director de programa de la Ingeniería en
Informática de la UOC.
© Editorial UOC 9 Índice
Índice
Prólogo ...................................................................................................... 15
Presentación ................................................................................................ 19
Capítulo I. Visión general de la informática,

Ramon Segret Sala ...................................................................................... 23
1. Introducción ........................................................................................ 23
2. La actividad profesional relacionada con la informática ...................... 28
3. La ciencia informática............................................................................ 30
4. La tecnología informática ...................................................................... 32
4.1. Tecnología del hardware .............................................................. 32
4.2. Tecnología del software ................................................................ 35
5. Reparación, formación, consultoría, auditoría y peritaje .................... 40
6. Dirección de empresas, departamentos y equipos informáticos .......... 43
7. Comercialización de productos y servicios informáticos ........................ 44
Resumen ................................................................................................ 45
Capítulo II. Arquitectura de los sistemas informáticos,

Jordi Tubella Murgadas ................................................................................ 47
1. Introducción ........................................................................................ 47
2. Software de los sistemas informáticos .................................................. 49
2.1. Aplicaciones web .......................................................................... 49
2.2. Sistemas distribuidos .................................................................... 52
2.3. Sistema operativo ........................................................................ 54
3. Hardware de los sistemas informáticos ................................................ 56
3.1. Unidad central de proceso .......................................................... 57
3.2. Subsistema de memoria .............................................................. 59
3.3. Subsistema de entrada/salida ...................................................... 60
© Editorial UOC 10 Escaneando la Informática
3.4. Buses ............................................................................................ 62

4. El sistema binario .................................................................................. 63
5. Historia .................................................................................................. 65
6. Salidas profesionales ............................................................................ 69
Capítulo III. Redes de comunicaciones,

Joan Arnedo Moreno .................................................................................... 71
1. Introducción ........................................................................................ 71
2. Una visión general de las redes de comunicaciones ................................ 72
3. Las redes y nuestro entorno ................................................................ 73
4. La red de redes: Internet ...................................................................... 75
4.1. World Wide Web .......................................................................... 76
5. Las redes de área local .......................................................................... 80
5.1. Principios de la red Ethernet ...................................................... 80
5.2. Dispositivos en la red Ethernet .................................................... 82
6. Las redes de área extensa ...................................................................... 83
6.1. Tipos de enlace en una WAN ...................................................... 84
7. Las redes de comunicaciones sin hilos ................................................ 85
8. Las redes de comunicaciones y la seguridad ........................................ 87
8.1. ¿Hacker o cracker? ........................................................................ 88
8.2. Principales problemas .................................................................. 89
8.3. Servicios y mecanismos de seguridad .......................................... 90
8.4. Un ejemplo sencillo y actual: Wardriving .................................. 91
9. La carrera del experto en redes de comunicaciones.............................. 93
9.1. El estudio de las redes de comunicaciones .................................. 94
9.2. Perspectivas profesionales ............................................................ 94
9.3. El reciclaje profesional ................................................................ 99
Capítulo IV. Programación,

Francisco Javier Noguera Otero y Daniel Riera Terrén .................................... 101
1. Introducción ........................................................................................ 101

2. ¿Qué es un programa? ¿Quién programa? .......................................... 102
3. Historia .................................................................................................. 103
3.1. La primera programadora ............................................................ 104
3.2. Prehistoria de la programación .................................................... 105
3.3. El primer programa en la memoria ............................................ 106

3.4. Generaciones ................................................................................ 108
4. Algorítmica ............................................................................................ 114
4.1. Las bases ...................................................................................... 115
4.2. Conceptos avanzados .................................................................. 120
5. Traducción de código fuente a código máquina .................................. 122
5.1. La compilación ............................................................................ 122
5.2. La interpretación .......................................................................... 123
5.3. Código intermedio ...................................................................... 123
6. Paradigmas de programación .............................................................. 124
6.1. Programación desestructurada o spaghetti .................................. 124
6.2. Programación procedimental (o imperativa) .............................. 125
6.3. Programación orientada a objetos .............................................. 125
6.4. Programación orientada a aspectos ............................................ 125
6.5. Otros paradigmas ........................................................................ 126
7. Lenguajes de programación .................................................................. 127
7.1. Los lenguajes más utilizados ........................................................ 128
8. Software libre ........................................................................................ 133
9. El mundo laboral .................................................................................. 134
10. Apéndice .............................................................................................. 135
10.1. Premios A. M. Turing .................................................................. 135
10.2. Ejemplo de código de programación ofuscada en C .................... 137
Capítulo V. Gestión de datos: bases de datos y sistemas gestores

de bases de datos, M. Elena Rodríguez González .................................... 139
1. Introducción ........................................................................................ 139

2. Concepto de base de datos .................................................................. 139
3. Evolución del área de bases de datos .................................................. 142
3.1. Los modelos de datos prerrelacionales ........................................ 142
3.2. El modelo de datos relacional ...................................................... 144
3.3. Los modelos de datos posrelacionales ........................................ 147
3.4. Otras tendencias .......................................................................... 148
4. Objetivos de los sistemas de gestión de bases de datos ............................ 149
4.1. Ejecución de operaciones no predefinidas y complejas .................. 149
4.2. Flexibilidad e independencia .............................................................. 151
4.3. Integridad ante los cambios ................................................................ 151
4.4. Concurrencia y recuperación .............................................................. 153

4.5. Acceso eficiente .................................................................................... 156
4.6. Seguridad .............................................................................................. 157
5. Las bases de datos relacionales .................................................................. 159
5.1. Fundamentos del modelo de datos relacional .................................. 159
5.2. Manipulación de bases de datos relacionales con SQL .................... 161
6. Salidas profesionales .................................................................................... 165
6.1. Diseñadores de bases de datos ............................................................ 166
6.2. Programadores de aplicaciones de bases de datos ............................ 167
6.3. Administradores de bases de datos .................................................... 168
Capítulo VI. Ingeniería del software,

Jordi Cabot Sagrera ...................................................................................... 169
1. Introducción ........................................................................................ 169

2. ¿Qué es la ingeniería del software? ...................................................... 170
3. Evolución histórica .............................................................................. 174
4. Presente de la IS .................................................................................... 176
4.1. El Unified Process.......................................................................... 177
4.2. El UML (Unified Modeling Language) ........................................ 181
5. Tendencias.............................................................................................. 189
5.1. Ingeniería web .............................................................................. 189
5.2. Desarrollo de software dirigido por modelos ................................ 190
5.3. Reutilización ................................................................................ 191
5.4. Verificación y validación .............................................................. 192
5.5. Métodos de desarrollo ágiles ........................................................ 194
5.6. Lenguajes específicos de dominio .............................................. 195
6. Salidas profesionales ............................................................................ 196
Capítulo VII. Sistemas de información (en lasorganizaciones),

Josep Maria Marco Simó, Maria Jesús Marco Galindo, Rafael Macau Nadal,
Joan Antoni Pastor Collado, José Ramon Rodríguez Bermúdez
e Isabel Guitart Hormigo .............................................................................. 199
1. Introducción .......................................................................................... 199

2. Una definición de Sistema de Información .......................................... 201
3. Un par de clasificaciones elementales de los SI .................................... 204
4. Profundizando en el papel de los SI en las organizaciones .................. 206

5. La evolución (histórica y tipo) de los SI en las organizaciones ............ 209
6. Un catálogo de los SI ............................................................................ 213
6.1. SI operacionales (o transaccionales) .............................................. 215
6.2. SI decisionales (tácticos y estratégicos) .......................................... 217
6.3. Otros SI especializados .................................................................... 220
7. Los roles profesionales de los SI ............................................................ 223
7.1. Los roles de dirección y de gestión (de management) de los SI ...... 223
7.2. Los roles para la gestión funcional de los SI .................................. 231
8. La estructura y la organización del departamento de SI ...................... 236
9. ¿Conclusiones? ...................................................................................... 240
Glosario ...................................................................................................... 243
Bibliografía ................................................................................................ 253

© Editorial UOC 15 Prólogo
Prólogo
Nos guste o no, el hecho es que nos encontramos en un mundo en cambio

constante, un mundo en rápida evolución que, muy a menudo, nos descoloca
e incluso nos preocupa. De hecho el mundo siempre ha sido cambiante porque
toda una serie de acontecimientos y de descubrimientos han impulsado y des-
encadenado este cambio. Pero si bien es cierto que la aparición de las herra-
mientas, el invento de la rueda, la generalización del uso de la energía y de los
motores nos llevaron a la sociedad industrial, es también evidente que aquello
que nombramos sociedad de la información ha abierto las puertas a un nuevo
mundo global e interdependiente en explosiva expansión... ¿Cuál es la herra-
mienta de base que ha hecho posible y practicable este cambio? Sin ningún tipo
de duda, y como todos sabemos bastante bien, la informática.
La informática, en su sentido más amplio, la encontramos por todas partes;
está –hoy– en la mayoría de los dispositivos y sistemas que nos rodean y que
utilizamos, o que nos condicionan. Obviamente es la herramienta fundamental
y básica para la concepción y desarrollo de los ordenadores y de los sistemas de
comunicación o de los equipos multimedia, pero, además, es casi omnipresen-
te. Es como una capa a menudo escondida o invisible de muchos de los dispo-
sitivos de uso diario o de aplicación comercial o industrial que nos rodean.
Todo lo que acabo de exponer implica que los puntos de vista para definir y
concretar los campos de aplicación y las especialidades que forman parte, o que
podemos definir como pertenecientes al campo de la informática, son muy
diversas.
Escaneando la Informàtica nos da una visión global y sistemática del alcance
y diversidad de los diversos campos profesionales y científicos de la informáti-
ca. Tal como dicen de forma clara los autores “Este libro pretende hacer una
modesta contribución a la necesidad de difundir y explicar, con una visión
divulgativa y apta para todos los públicos, las disciplinas de la informática, sus
técnicas y las profesiones que se asocian. Posiblemente cómo lo hace un escá-
ner de documentos: con una foto lo suficientemente detallada aunque sólo de
la superficie.”
Es evidente que se han alcanzado plenamente los objetivos planificados. El

libro que tenéis en las manos no es un tratado tradicional, más o menos
extenso, de informática, sino una introducción a los ámbitos y las profesiones
de la informática desde una perspectiva práctica y útil para estudiantes nove-
les y lectores en general, que los ayude a definir y perfilar su trayectoria aca-
démica de acuerdo con sus objetivos, en el caso de los primeros, o simplemen-
te a tener una idea más amplia de la informática, en el caso de los segundos.
Para poder dar esta visión amplia y diversa del alcance y campos de operación
de la informática y de los expertos y profesionales que la desarrollan y apli-
can, la UOC ha hecho lo que hacía falta: ha constituido un equipo de profe-
sores de los Estudios de Informática, Multimedia y Telecomunicación, cada
uno de ellos con experiencias diversas, tanto en el ámbito profesional como
en el de la docencia.
Si a este perfil de experiencia personal en campos diferenciados de la infor-
mática, sumamos la visión particular del concepto de formación alcanzada a la
UOC, después de más de diez años de ejercer como profesores, el resultado es
previsible: un texto claro, pensando en el usuario, que en este caso tiene que asi-
milar aquello que es la informática y no, en esta etapa inicial, aprender infor-
mática. A partir de esta visión global inicial y de su trayectoria académica y pro-
fesional en que se implique, tiempo tendrá para definir con más precisión las
opciones académicas que mejor se adapten a sus necesidades.
Desde el Capítulo primero, que ofrece una visión general de la informática
hasta el último Capítulo, el séptimo, que trata de los sistemas de información
en las organizaciones, los autores van exponiendo de forma metódica y simple,
sin grandes elucubraciones teóricas, los aspectos fundamentales de la arquitec-
tura de los sistemas informáticos, de las redes de comunicaciones, de la progra-
mación y de la gestión de datos. Todos o parte de estos ámbitos pueden ser des-
arrollados posteriormente por el estudiante, mediante las adecuadas materias, o
para el lector en general a partir de la bibliografía propuesta.
Tengo que decir que para mí ha sido una satisfacción prologar este libro que
ofrece una visión panorámica de una materia básica como es hoy la informá-
tica. La informática fue la pieza clave para concebir, hace quince años, un
nuevo modelo de enseñanza a distancia –sin distancias, decía yo– con el fin de
poder superar las barreras del tiempo y del espacio, también de poder garanti-
zar la formación a lo largo de la vida, la formación ajustada a las necesidades
de cada persona.
© Editorial UOC 17 Prólogo
Eso me ha dado la oportunidad de restablecer el contacto con personas que

me ayudaron a sacar adelante el proyecto, a hacerlo realidad. Nada se habría
podido hacer sin la ayuda de personas imaginativas, abiertas al futuro y con un
real sentido pedagógico como los autores y las autoras de este libro. Mi más cor-
dial felicitación por la iniciativa y por el resultado, que ha catalizado y dirigido
el también estimado amigo y colaborador, el profesor Rafael Macau, director de
los Estudios de Informática, Multimedia y Telecomunicación de la UOC
Gabriel Ferraté i Pascual

© Editorial UOC 19 Presentación
Presentación
A menudo, los que de una manera u otra ostentamos la etiqueta de informá-

ticos somos requeridos por amigos, familiares y conocidos para todo tipo de
tareas relativas a los PC, a las conexiones a Internet, a los ataques de virus infor-
máticos, a la edición digital de fotografía, a la elección del mejor programa
informático para un negocio concreto... Se supone que entendemos de todo y
que podemos aconsejar sobre cualquier tipo de incidencias o situaciones, con
independencia de si somos autodidactas en el uso de los ordenadores o si hemos
llegado a estudiar un doctorado en informática... ¿Quién no ha oído una sen-
tencia como ésta: “No hay nada como tener un informático en la familia” (ade-
más de un médico o un manitas)?
Es cierto que estas situaciones también suceden en otras profesiones, pero así
como todo el mundo sabe más o menos que un médico tiene una especialidad
y no vamos a la consulta del oftalmólogo cuando nos rompemos una pierna,
los informáticos todavía no hemos tenido tiempo de transmitir esta idea de una
profesión especializada. Y eso, por una parte, decepciona a algunos de los que
esperan mucho de nosotros y, por otra, exaspera a muchos informáticos. De
hecho, no hace mucho, vimos uno que lucía una camiseta en la que se leía:
“No. ¡No pienso arreglar tu ordenador!”.
Este libro pretende hacer una modesta contribución a la necesidad de difun-
dir y explicar, con una visión sencilla y apta para todos los públicos, las disci-
plinas de la informática, sus técnicas y las profesiones asociadas a ella.
Posiblemente como lo hace un escáner de documentos: con una foto suficien-
temente detallada aunque sólo de la superfície.
Nuestra intención original era escribir un texto dirigido a los no iniciados o
a los que quisieran echar una ojeada a alguna parte de esta disciplina. Sin
embargo, a medida que pensábamos, descubrimos que podría ser de utilidad
también para aquellos que quisieran convertirse en informáticos y que todavía
tuvieran una visión borrosa, parcial o incompleta de esta disciplina. De hecho,
nuestra experiencia, como estudiantes de informática primero y como profeso-
res universitarios después, nos dice que muchos estudiantes de informática de
un primer curso de cualquier nivel de estudios (un ciclo formativo, una carrera
universitaria oficial, un programa de reciclaje...) no conocen las diferentes caras
que presenta la informática, o lo que es peor, no tienen claro cuál les resultará
más estimulante o cuál encajará más con sus competencias/habilidades. Para
ellos, y también para sus profesores, que tienen que poder ayudarlos explican-
do los diferentes aspectos de la disciplina, creemos que este texto puede resul-
tar útil.
Así pues, en las páginas que siguen hemos intentado dibujar un mapa de la
informática, desde la perspectiva del profesorado de los Estudios de Informática,
Multimedia y Telecomunicación de la UOC, ahora que tenemos a las espaldas
más de diez años de experiencia formativa en esta materia y que hemos ido per-
filando nuestra idea de qué significa hacer de informático en este rincón de
Europa.
Para dibujar este mapa, empezaremos el primer capítulo con una perspecti-
va aérea, con un viaje que desgrana los nombres y los mundos de este ámbito
dejando claro que es ciencia y técnica, pero también servicios de instalación,
comerciales o de dirección. Por eso consideramos que este primer capítulo es
imprescindible para todo el mundo que se acerque a este libro, ya que conden-
sa su motivación.
Lo siguen un conjunto de capítulos que, organizados según un mismo esque-
ma, desarrollan los diferentes aspectos presentados en el primero. Son capítulos
introductorios, divulgativos, algunos con más conceptos teóricos y otros con
más explicaciones técnicas y prácticas. En todos se incluye también una pince-
lada de la evolución histórica (que explica el momento actual) y de las profesio-
nes relacionadas con ésta. Creemos que todos los capítulos son interesantes
para un neófito, pero es cierto que existe la posibilidad de que el lector escoja
sólo aquel que prefiere leer. Para los que opten por esto, hay que advertir que
los capítulos siguen un cierto orden y que, en los últimos, se puede dar por sen-
tado que se han leído los anteriores y que algunos aspectos ya son conocidos y
se han comprendido.
También queremos aclarar que, aunque demos una visión amplia, no es
completa: hay aspectos que no mencionamos conscientemente (y que coinci-
den con los que tradicionalmente no hemos incluido en nuestros planes de
estudio). Entre éstos se encuentran tanto los que son tan nuevos que no consi-
deramos todavía definidos de manera estable, como los que pertenecen a profe-
siones informáticas que difícilmente tienen demanda en nuestro entorno.
© Editorial UOC 21 Presentación
Un aviso final: en todos los capítulos se puede observar una diferencia de

estilo. Es fruto no sólo del hecho de que hay diversos autores detrás de ellos
(todos profesores de informática en la UOC), sino porque cada uno de ellos
representa a un tipo de informático diferente. Así se confirma la idea que trata-
mos de una disciplina rica, diversa y compleja. Como editores, podríamos
haber buscado una mayor uniformización de estilos –la estructura de cada
capítulo ya sigue un esquema predeterminado, como hemos dicho–, pero estu-
vimos de acuerdo en que la homogeneización podría enmascarar la diversidad,
que es una realidad patente. Muchas veces, en realidad, los propios informáti-
cos nos encasillamos y nos diferenciamos los unos de los otros con una cierta
ironía: los de corbata y los pelacables, los de letras y los de sistemas, los teóri-
cos y los freakies...
No pretendemos que éste se convierta en el libro enciclopédico de informá-
tica del lector. Ahora bien, sí que nos haría ilusión que, cuando queráis recor-
dar o explicar a alguien a grandes rasgos qué se esconde detrás de alguno de los
conceptos básicos de nuestro ámbito –porque, por ejemplo, está decidiendo
hacia dónde orientar sus estudios o su trayectoria profesional–, penséis en este
texto y volváis a él, con la curiosidad de recordar lo que explicaban sobre ellos
mismos unos informáticos que, por azares de la vida, también trabajan como
profesores de informática (un tipo de informático que quizá se merece un esca-
neo a parte...).

Ramon Segret Sala
© Editorial UOC 23 Visión general de la informática
Capítulo I
Visión general de la informática

Ramon Segret Sala
1. Introducción
Podemos empezar preguntándonos: ¿Qué es la informática? Como punto de

partida aceptaremos la respuesta siguiente: La informática es el conjunto de cono-
cimientos que actualmente tenemos respecto a un artilugio tecnológico al que lla-
mamos ordenador. En la historia de los grandes hallazgos técnicos de la humanidad
el ordenador es un invento relativamente reciente. Estamos hablando de un inven-
to de hacia mediados del siglo XX, es decir, de hace poco más de unos cincuenta
años. Pero a pesar de su juventud el conjunto de conocimientos relativos a este arti-
lugio es enorme. Y cuando decimos conjunto de conocimientos nos referimos a
conceptos como ciencia, tecnología, negocio e implicaciones de todo tipo para el
individuo y la sociedad, como son los aspectos ergonómicos, éticos y políticos, por
ejemplo. Podemos decir que en torno al ordenador se ha construido un entretejido
de conocimientos que, según los teóricos de la técnica, constituyen lo que ellos lla-
man un sistema técnico.1
1. Sistema técnico es un concepto que el historiador francés de la ciencia y sobre todo de la técni-
ca, Bertrand Gille (1920-1980), introdujo en su obra Histoire des techniques. Para Gille un sistema téc-
nico es el conjunto de coherencias que entrelazan las diferentes tecnologías de cada época y que
constituyen un estadio más o menos durable de la evolución de las técnicas. Este autor concibe la
historia como la sucesión de los diferentes sistemas técnicos que han existido.
Como ejemplo pensemos en la navegación transoceánica. Durante la Edad Moderna el sistema téc-
nico que la permitió se fundamentaba, entre otras tecnologías, en el barco de madera y la energía
del viento aprovechada por el conjunto de las velas. A lo largo del siglo XIX este sistema técnico es
sustituido por otro basado en la sinergia de unas nuevas tecnologías: el trabajo y el uso del hierro
a gran escala que permitió construir fuselajes metálicos, la energía del vapor a partir de la experien-
cia de las primeras máquinas de vapor y evidentemente la explotación masiva de los yacimientos
de carbón para poder disponer de esta fuente de energía de origen fósil.
En la actualidad podemos ver cómo la sinergia entre la electrónica, la informática y las comunica-
Aunque posiblemente sabéis qué es y cómo funciona un ordenador, recordé-

moslo brevemente. El ordenador en esencia es una máquina que manipula sím-
bolos. Estos símbolos son los que entendemos los humanos: letras, números,
notas musicales, píxeles que forman dibujos, imágenes o vídeos. Internamente
el ordenador convierte todos estos símbolos en bits (ceros o unos), es decir, los
digitaliza, y las manipulaciones que hace son sencillas: aritmética y lógica ele-
mental. Pero como la velocidad de manipulación interna del ordenador es enor-
me, a base de combinar las operaciones sencillas, nos da la sensación de que está
haciendo operaciones mucho más complejas y éstas son las que nos interesan a
los usuarios humanos: procesar un texto, sumar números, reproducir una melo-
día, proyectar una fotografía, etc.
De lo dicho en el párrafo anterior se deduce que el ordenador, además de la
unidad interna de manipulación, debe tener unas unidades periféricas para
poder dialogar con los humanos. Así encontramos teclados, pantallas, impreso-
ras, escáneres, altavoces, entre otros. Otro tipo necesario de unidades que un
ordenador debe tener son las de almacenaje. En efecto, almacenando una gran
cantidad de símbolos (llamados normalmente datos) el ordenador nos ahorra el
trabajo de tenerlos que introducir más de una vez y además nos sirve de archi-
vador. Estas dos funciones son también tan importantes que podríamos añadir-
las a la definición elemental que hemos dado antes y así nos queda que el orde-
nador es una máquina que manipula símbolos, los almacena y los intercambia
con el exterior.
Otra característica básica del ordenador es que todo eso lo hace de una mane-
ra general. Un ordenador no está pensado para resolver un tipo concreto de acti-
vidad o función sino para resolver un amplio conjunto de actividades y funcio-
nes. No tenemos, por ejemplo, el ordenador que sólo puede realizar la matricu-
lación de alumnos en la UOC. Sino que ese ordenador, además de eso, soporta
ciones ha cambiado profundamente la manera de trabajar, hacer negocios e incluso disfrutar de

nuestro tiempo personal. ¿Es éste el sistema técnico de nuestro tiempo?
Para quien quiera profundizar sobre este concepto es interesante mencionar que el concepto de “sis-
tema técnico” en el campo de la técnica se corresponde con otro concepto en el campo de la cien-
cia. Es el de paradigma, explicado por el filósofo de la ciencia, el norteamericano Thomas S. Kuhn
(1922-1996), en su obra primordial The Structure of Scientific Revolutions (1962). Para Kuhn paradig-
ma es el conjunto de teorías científicas, su enseñanza, la literatura científica asociada, la mentali-
dad que todo eso crea, incluso el conjunto de aparatos para investigar estas teorías y los conoci-
mientos técnicos derivados de todo ello. Y todo eso en una época histórica determinada. En esta
visión también un nuevo paradigma acaba desbancando al anterior y la historia aparece como una
sucesión de paradigmas científicos. Pensemos en la química que hacia el siglo XVIII desbancó a la
alquimia o en el evolucionismo que el siglo XIX sustituye –con fatigas– al creacionismo.
el correo electrónico entre los alumnos y el consultor de un aula virtual y tam-

bién controla el expediente académico de cada alumno, por ejemplo. Para
poder hacerlo, el ordenador debe tener un diseño flexible. Este diseño se basa
en unas operaciones de manipulación de símbolos muy básicas, como se ha
dicho antes, y en la existencia de una pieza clave y específica de los ordenado-
res: el programa.
Un programa es una secuencia detallada de instrucciones, escrita en princi-
pio por una persona, que indica al ordenador qué tiene que hacer para resolver
una necesidad concreta, como sería la matriculación, el correo electrónico o la
gestión de expedientes. Así pues, no es que tengamos diferentes tipos de orde-
nadores para diferentes necesidades, como ya se ha dicho antes. Lo que tene-
mos es un ordenador que con diferentes programas efectuará las diferentes fun-
ciones que nos interesen. Resulta así una máquina muy flexible con aplicacio-
nes muy generales.
Llegados a este punto es muy tentador, y es algo que se ha hecho muchas
veces, comparar el funcionamiento del ordenador con el de nuestro cerebro.2 En
efecto, nuestro cerebro se comunica con el exterior mediante órganos como los
ojos, las orejas, las cuerdas vocales, las manos, que vendrían a ser nuestros peri-
féricos. Con ellos captamos y producimos sonidos, imágenes, sensaciones y ele-
mentos culturales más complejos como la escritura. Todas estas señales son pro-
cesadas y almacenadas por el cerebro. Así cerebro y ordenador tienen en común
las funciones de manipulación de señales o símbolos, de almacenaje y de comu-
nicación con el exterior.
También el cerebro tiene un diseño generalista. Precisamente, según muchos
antropólogos, el éxito de la especie humana se basa en la muy escasa especiali-
zación de nuestra naturaleza, lo cual nos ha permitido ir amoldándonos a con-
diciones cambiantes y así poder subsistir con éxito. Esta capacidad generalista
de nuestro cerebro quiere decir que una persona puede dedicarse a las activida-
des más variadas, lo cual es bien palpable en una sociedad tan compleja como
la actual.
Ahora bien, este diseño generalista de nuestro cerebro también necesita,
como en el caso del ordenador, un programa que lo rija y que lo lleve a pro-
ducir acciones útiles. En nuestro caso este programa es la cultura, entendido
2. Incluso, años atrás, se conocía a los ordenadores con el nombre de cerebros electrónicos.
este concepto de forma muy amplia.3,4 Sólo tenemos que pensar en lo inde-
fenso que es un bebé y cuánto tiempo tarda en asimilar los componentes cul-
turales mínimos de su sociedad para poder moverse con autonomía. De
hecho la cultura no sería un programa, sino más bien un conjunto de pro-
gramas, de los más comunes a los más especializados. Todos los humanos,
cada uno dentro de su sociedad, recibe y aprende un primer programa de las
funciones más básicas: comportamientos, lengua, relaciones con los demás,
etc., y después a lo largo de la vida irá recibiendo y aprendiendo programas
más especializados que le permitirán desarrollar actividades específicas:
habrá quien sea cirujano, quien sea albañil y quien sea periodista, por ejem-
plo.
Con todas estas similitudes: manipulación de signos, almacenaje, comu-
nicación con el exterior, diseño generalista, multiplicidad de programas para
poder actuar, nos puede surgir una especie de pesar, como humanos, al ver
que una simple máquina, el ordenador, se nos parece demasiado. De hecho,
ha habido quien ha sostenido que el ordenador podrá llegar a hacer todas las
funciones de una mente humana, y eso, evidentemente, nos inquieta. Pero
por otra parte hay también muchos pensadores que dicen claramente que
muchas de las funciones que consideramos superiores del ser humano nunca
3. Rita Levi Montalcini, nacida en Turín en 1909, investigadora del sistema nervioso y premio Nobel
de Medicina en 1986, desarrolla estas ideas en el libro La galaxia mente, publicado por Crítica en el
2000. En la página 172 nos dice:
“Los hijos del hombre difieren de los demás mamíferos en la lentitud de su desarrollo somático e
intelectual, lo que les hace depender de sus padres o sustitutos durante el periodo comprendido
entre el nacimiento y la pubertad.”
Y en la página 116 nos copia una cita de E. Boncinelli (A caccia di geni, 1997), que quizás todavía es
más gráfica:
“Con la especie humana, la evolución biológica se ha superado a sí misma y se ha caído en una
especie de paradoja. En efecto, en nuestro caso la dotación genética, ama casi absoluta de la vida y
el comportamiento de los animales inferiores, ha abdicado voluntariamente, por decirlo de alguna
manera, dejando un margen muy amplio a la acción del medio circundante, al aprendizaje y a la
educación.”
4. Con respecto a qué es la cultura lo podemos ilustrar con dos definiciones de dos antropólogos.
La primera, más conceptual, se debe a Alfred L. Kroeber (1876-1960), creador del Museo de
Antropología de San Francisco (EE.UU.). La segunda, más enumerativa, es de Edward B. Tylor (1832-
1917), primer profesor de antropología de la Universidad de Oxford (Reino Unido).
“La cultura consiste en formas de comportamiento, explícitas o implícitas, adquiridas y transmiti-
das mediante símbolos y constituye el patrimonio singularizador de los grupos humanos...”
“La cultura [...] incluye el conocimiento, las creencias, el arte, la moral, el derecho, las costumbres
y cualesquiera otros hábitos y capacidades adquiridos por el hombre como miembro de la socie-
dad.”
podrán ser producidas por un ordenador. Nos estamos refiriendo a las emo-
ciones, al proceso creativo y a los juicios éticos y estéticos.5
Y es que hay que tener presente que el ordenador no crea, no inventa, no
improvisa. En realidad sigue las instrucciones de un programa que ha sido en
último término concebido por un humano. Colocándonos ahora en el otro
extremo de donde nos poníamos en el párrafo anterior podemos preguntarnos:
¿Qué nos proporciona el ordenador que no podamos hacer nosotros? Bien,
todos lo sabemos pero repitámoslo aquí. El ordenador es inmejorable a la hora
de realizar tareas repetitivas. Una vez alguien ha diseñado un proceso y lo ha
explicado al ordenador éste lo repetirá hasta la saciedad sin desfallecer, sin equi-
vocarse, ya que no se cansa, y a una velocidad vertiginosa. Todo eso, acompa-
ñado de su gran capacidad de almacenaje y de recuperación veloz de la infor-
mación, hace que esta máquina sea uno de nuestros mejores auxiliares en la
actualidad.
Para acabar esta introducción nos fijaremos en un último punto. Hasta ahora
hemos hablado de un ordenador, como si fuera una unidad independiente que
sólo se comunica con nosotros. De hecho eso no es así hoy día, aunque sí que
lo fue en los orígenes de esta máquina. En la actualidad lo que hay no es un con-
junto de ordenadores independientes sino redes inmensas que comunican un
gran número de ordenadores entre sí. Desde nuestro ordenador personal, que
cuando queremos lo conectamos a Internet y accedemos a datos y programas
almacenados en otros ordenadores, a los conjuntos de superordenadores que
suman sus capacidades para llevar a cabo cálculos ingentes (meteorología, con-
trol de viajes espaciales), nos encontramos con que el paradigma actual de la
informática no es el ordenador aislado sino la red de ordenadores. Siguiendo
con la comparación que hacíamos con el cerebro humano es como si hoy en día
no tuviéramos un conjunto de mentes humanas aisladas, cada una con sus
maravillosas funciones, sino toda una sociedad humana compuesta de personas
que constantemente se están intercambiando información.
5. Volviendo a citar La galaxia mente, de Rita Levi, encontramos que en la página 184 nos dice:
“El ordenador se inventó para ayudar a los seres humanos en operaciones para las que estamos bas-
tante limitados (velocidad de elaboración, estabilidad de memoria, exactitud de ejecución), y poco
a poco ha ido adquiriendo propiedades que lo han hecho comparable al cerebro de los seres vivos.
[...]
Pero el cerebro no es un ordenador convencional, ni funciona igual. Como señala acertadamente
Oliver Sacks: ‘Los procesos mentales, que constituyen nuestro ser y nuestra vida, no son abstractos
y mecánicos, también son personales, y como tales implican no sólo la clasificación y la ordena-
ción en categorías, sino también una actividad continua de juicio y sentimiento’.”
Aunque la realidad de este artilugio ha cambiado, todo lo que hemos ido

comentando hasta aquí sigue siendo válido en este nuevo paradigma. Sólo que
quizás sí que hay que añadir a aquella corta lista de capacidades básicas del
ordenador la de la comunicación de los ordenadores entre sí a través de los
canales que la tecnología de las comunicaciones ofrecen en la actualidad.
Cuando hablemos de todo este conjunto no será extraño, pues, que nos refira-
mos a él como el mundo de las TIC (tecnologías de la información y de las
comunicaciones).
2. La actividad profesional relacionada con la informática
En la lista anterior del sistema técnico de la informática6 nos hemos deja-

do un elemento muy importante para todos nosotros que se supone que tra-
bajamos, hemos trabajado o queremos trabajar con ordenadores. Nos estamos
refiriendo a la profesión informática. Ahora bien, ¿existe una profesión infor-
mática? Todos conocemos a amigos o familiares que son informáticos, o
incluso lo podemos ser nosotros mismos. ¿Todos esos informáticos que cono-
cemos hacen lo mismo? ¿Necesitan los mismos conocimientos? ¿Han desarro-
llado las mismas habilidades? Me parece que la respuesta a todas estas pregun-
tas es negativa. Unos programan, otros arreglan las diversas máquinas infor-
máticas. Unos tienen una carrera universitaria informática, otros han asistido
a unos cursillos. Unos tienen una visión amplia de la informática, otros sólo
conocen un paquete como el Office, aunque son expertos en él. En fin, ya
vemos que hay una gran variedad de trabajos y empleos relacionados con el
sistema informático y a todo el que los realiza se le llama, de forma laxa, infor-
mático.
Esta situación no es exclusiva de la profesión informática. Para compren-
der lo que decimos exploraremos un símil muy conocido de nuestra vida dia-
ria: el mundo profesional de la medicina. Nosotros consideramos médico a
todo aquel que ha cursado la carrera de medicina y ha acreditado un conoci-
6. En el primer párrafo de la introducción.

miento suficiente para aprobarla. Ahora bien, cuando tenemos que consultar
a un médico no vamos a ver a cualquiera sino a aquel que consideramos ade-
cuado para el tipo de consulta que queremos realizar. Si nos tienen que gra-
duar la vista vamos al oftalmólogo, si llevamos a un niño pequeño vamos al
pediatra y en caso de ansiedad vamos a un psiquiatra. También hay médicos
que sólo hacen análisis clínicos e incluso hay otros que gestionan una mutua
de salud privada o que dirigen un hospital de la Seguridad Social. Así vemos
que una misma titulación, en este caso académica, da pie a ejercer profesio-
nes diferentes. Y decimos diferentes porque a nosotros no se nos ocurriría ir
al otorrino por un dolor de estómago o bien al dentista por un dolor muscu-
lar. Y es que cada uno de estos médicos ha desarrollado a través de los estu-
dios y de la práctica profesional una serie específica de conocimientos y expe-
riencias que hacen que le confiemos nuestro problema concreto de salud.
Ahora bien, aunque como decíamos en el párrafo anterior ésta no sea una
situación sólo de la informática, la verdad es que en esta profesión la diversifi-
cación de actividades posibles parece todavía mayor. Las razones las podríamos
encontrar en que es una profesión joven, poco reglamentada y por eso precisa-
mente la etiqueta o el título de informático en nuestra sociedad no la da sólo el
hecho de haber superado unos estudios universitarios sino que de una forma
mucho más laxa, para el mercado, se es informático si se han hecho unos cur-
sillos o bien si hace un cierto tiempo que se trabaja en este campo y se tiene una
cierta experiencia, o por otras razones similares.
Dejando de lado la discusión sobre la idoneidad de esta situación para la
profesión de la informática, sí que pensamos que para los propósitos de esta
introducción la relación de las diferentes actividades que los informáticos lle-
van a cabo en nuestro mercado nos puede ser útil como punto de partida para
describir las diversas áreas de conocimiento necesarias para cada una de estas
actividades. Dicho de otra manera: pensamos que viendo qué hacen los infor-
máticos llegaremos a entender, de una forma más global, qué es la informáti-
ca. Por eso a continuación encontraréis un conjunto de informaciones que
siguen el mismo esquema: primero la explicación de una cierta área de cono-
cimientos dentro de la informática, después los rasgos principales de los pro-
fesionales que se dedican a esta área y finalmente la relación de asignaturas
de las titulaciones informáticas de la UOC en las que se estudian estos cono-
cimientos. Después de todo este conjunto de puntos introductorios de las
diferentes áreas de conocimiento encontraréis en módulos posteriores la des-
cripción mucho más profundizada de algunas áreas, concretamente de aque-
llas consideradas más importantes en el momento actual en nuestro país y

que por eso son tratadas con más extensión y profundidad en diferentes asig-
naturas de las titulaciones de los Estudios de Informática de la UOC.
Antes de pasar a la relación de las diversas actividades informáticas, aún una
última puntualización. Al empezar este apartado hablábamos de los profesiona-
les de la informática como las personas que trabajan “con” ordenadores.
Debemos matizarlo. En realidad hoy en día casi todas las personas en el mundo
laboral trabajan con ordenadores, por no mencionar otros usos de este artilu-
gio, más caseros, que hacen que prácticamente todo el mundo sea usuario en la
actualidad. El matiz es que en los puntos que siguen no tendremos en cuenta
las actividades que las personas llevamos a cabo como “meros usuarios” de los
ordenadores sino sólo aquellas actividades realizadas por personas cuya ocupa-
ción profesional y laboral se encuadra precisamente dentro del mundo de los
ordenadores.
3. La ciencia informática
Aunque la percepción que tenemos de la informática y de las comunicacio-

nes sea tecnológica o perteneciente a la ingeniería, detrás de la tecnología hay
unos principios científicos que son las bases que han ayudado a desarrollarla. Es
un principio general de nuestra época. En la revolución científica del siglo XVII y
la industrial del XVIII, ciencia y técnica todavía podían ir por separado, pero cada
vez más, y es así desde principios del XX, ciencia y tecnología se basan mutua-
mente y no existe una sin la otra. Es el tiempo de la llamada tecnociencia.
Los conocimientos científicos de la informática constituyen un corpus que
es lo que los anglosajones llaman computer science. Una relación, evidentemen-
te no exhaustiva, de estos temas de conocimiento científico incluye el álgebra
de Boole, las teorías de la calculabilidad y de la complejidad, la optimización
de algoritmos, los lenguajes formales y las gramáticas regulares, los autómatas,
los grafos, la lógica y la deducción formal, los algoritmos de codificación y
compresión, los conocimientos del campo de la criptografía, los modelos de
bases de datos, como por ejemplo el modelo relacional y la teoría de la norma-
lización. Esta lista debe completarse con los conocimientos más específicos del
campo de las comunicaciones como, por ejemplo, la teoría ondulatoria y el

análisis de Fourier, así como también con los más generales, pero de aplicación
en la informática, como las bases de numeración, la teoría de colas o la teoría
de errores.
Como ya hemos mencionado antes, hoy día los adelantos en la ciencia se
aplican rápidamente a la tecnología. Así es que los conocimientos científicos
informáticos de la lista anterior tienen una aplicación inmediata tanto en las
funciones básicas de la industria informática como en sus campos más espe-
cíficos. Cuando hablamos de las funciones básicas nos referimos al hecho de
que muchos de los estudios teóricos anteriores sirven para diseñar los elemen-
tos constitutivos de los sistemas informáticos, esto es las máquinas, las cone-
xiones, los programas y las estructuras de datos. Y no sólo diseñarlos sino
hacerlo de la forma más óptima posible. Como aplicaciones más específicas
que han surgido a partir de trabajos teóricos podemos señalar áreas tan impor-
tantes hoy como la compresión y la búsqueda de la información, así como su
transmisión segura por las redes de ordenadores o la optimización de la distri-
bución de cálculo y datos entre diversas máquinas. No olvidemos tampoco el
diseño de lenguajes informáticos, la construcción de compiladores y la vali-
dación de la corrección de algoritmos y programas.
También aquí podríamos incluir la inteligencia artificial (IA). La IA a lo
largo de los años de desarrollo de la informática ha investigado una serie de
temas considerados punteros en su momento y que no tenían cabida en los
tópicos más asentados de la informática. Muchos de estos temas, con el tiem-
po, se han independizado y han constituido áreas de conocimiento lo bastan-
te importantes y con carta de naturaleza propia. La IA ha estudiado, entre
otras, cuestiones como la robótica, el conocimiento: cómo adquirirlo, cómo
representarlo y cómo consultarlo, el aprendizaje, etc. Son áreas situadas en el
límite de lo que hacen los ordenadores en un momento determinado y que
parecen próximas a las capacidades más propias de los humanos. La IA es,
pues, un campo amplio de estudio teórico que pretende concretar en aplica-
ciones prácticas el bagaje de conocimientos adquiridos. Querríamos subrayar
esta última idea para mostrar que el cultivo de la ciencia informática no es un
campo cerrado que se justifique en sí mismo sino que se aplica constantemen-
te en el avance de la industria informática. Es pues un área muy importante e
indispensable.
En nuestro país los profesionales que se dedican a este campo los encontra-
mos principalmente en las universidades, en los departamentos de informática
teórica o de fundamentos teóricos de la informática. Su trabajo consiste en la

investigación de estos temas y en la enseñanza. También encontramos a estos
profesionales en los departamentos de investigación de empresas informáticas
importantes, aunque desgraciadamente eso se da en países más adelantados en
temas de investigación que el nuestro.
4. La tecnología informática
La tecnología informática engloba a todos aquellos conocimientos que permi-

ten el diseño y la construcción de los sistemas informáticos. Como ya hemos
visto en la introducción, y además es cosa sabida por todo el mundo, los siste-
mas informáticos constan fundamentalmente de una parte física: las máquinas
de los diferentes ordenadores y las conexiones entre ellas, y de una parte que no
lo es: el conjunto de programas; son las dos partes que se conocen genéricamen-
te con los nombres de hardware y software. Así pues, la tecnología la veremos tam-
bién asociada a cada uno de estos dos componentes.
4.1. Tecnología del hardware
Como ya hemos dicho en el párrafo anterior, la tecnología nos tiene que per-
mitir diseñar y construir. Veremos, pues, las áreas de conocimiento asociadas al
diseño del hardware, concepto que muchas veces es designado con el nombre
de arquitectura, y su construcción. Además la arquitectura, para más claridad,
la dividiremos en dos: la del ordenador y la del sistema informático o red de
ordenadores.
4.1.1. La arquitectura del ordenador
Artilugios para calcular, si consideramos que el ábaco es uno de ellos, pode-

mos decir que han existido desde tiempo inmemorial. Ahora bien, es con la
revolución científica del siglo XVII cuando aparecen las primeras máquinas
mecánicas que realizan operaciones aritméticas. Y es mucho más tarde, hacia

finales de la Segunda Guerra Mundial, cuando este tipo de máquinas reciben un
interés renovado en la Gran Bretaña y sobre todo en los Estados Unidos. Con
los adelantos de la ciencia y de la técnica se necesitaba una gran capacidad de
cálculo, pero en aquellos momentos bélicos existía además el deseo de superar
al enemigo y ganar la guerra. Estamos hablando de cálculos balísticos o de des-
ciframiento de mensajes cifrados, por ejemplo, y estamos hablando de las pri-
meras máquinas de calcular u ordenadores electrónicos, no mecánicos, como el
británico Colossus, construido por Alan Turing, o el americano ENIAC, cons-
truido entre 1943 y 1946. Es en el proyecto del ENIAC donde encontramos,
junto con otros científicos, al húngaro nacionalizado norteamericano John von
Neumann. A este prestigioso científico se le atribuyen las ideas básicas que a
partir de la experiencia del ENIAC configuraron el diseño de una nueva máqui-
na, que en sus líneas más básicas sigue siendo la arquitectura de los ordenado-
res actuales. Las ideas atribuidas a Von Neumann, publicadas en 1945, que
podríamos considerar la fecha simbólica del nacimiento del ordenador, eran la
representación binaria, la secuenciación de operaciones y sobre todo el almace-
namiento del programa en la memoria principal del ordenador.
Si la arquitectura básica del ordenador: unidad de control, unidad aritmeti-
cológica, memoria principal que almacena datos y programas, y periféricos, no
ha cambiado en más de sesenta años, tenemos que buscar las incuestionables
inmensas mejoras de esta máquina en otras direcciones. En efecto, en el campo
de la arquitectura del ordenador se ha trabajado de forma constante para ganar
tiempo de funcionamiento a base de eliminar tiempos muertos de espera. Lo
cual se ha hecho descomponiendo las operaciones en operaciones más elemen-
tales que se pueden solapar entre ellas, así los tiempos de espera ocasionados
por las partes más lentas son aprovechados para ejecutar otros trozos de opera-
ciones. Otra técnica muy utilizada ha sido la duplicación de unidades y compo-
nentes elementales varias veces y permitir el funcionamiento en paralelo. Con
estas mejoras de la arquitectura básica se puede procesar al mismo tiempo una
gran cantidad de datos y la velocidad de ejecución de la máquina resulta muy
aumentada.
Como es natural, los profesionales que se dedican a este campo trabajan funda-
mentalmente en las empresas constructoras de ordenadores, pero cualquier profe-
sional informático que deba tomar decisiones sobre la comparación, la compra y
el uso de estas máquinas debería tener un conocimiento general, aunque suficien-
temente preciso, de estos temas arquitecturales.
4.1.2. La arquitectura de la red de ordenadores
Ya hemos visto en la introducción que hoy día los ordenadores no trabajan

casi nunca como máquinas aisladas sino que están conectados entre ellos for-
mando redes, compartiendo datos y programas, cosa prácticamente indispen-
sable para poder hacer nuestro trabajo. “Arquitecturar” todo este conjunto es
tomar una serie de decisiones a la hora de conectar los ordenadores para ase-
gurar su funcionalidad adecuada sin olvidar sacar el máximo de rendimiento,
disponibilidad, flexibilidad y otras cualidades que son las que en definitiva nos
darán la utilidad del sistema informático resultante.
Cuando hablamos de las decisiones de la arquitectura de la red de ordena-
dores nos referimos a cosas como la topología de la red, la jerarquía y la fun-
cionalidad de las diversas máquinas de la red, la tecnología de comunicaciones
que utilizaremos o el ancho de la banda.
Esta es un área importante de conocimientos informáticos o, mejor dicho,
de conocimientos telemáticos, a caballo entre la informática y las comunica-
ciones. Los profesionales que se dedican a este tipo de diseño, de forma para-
lela a los que diseñan ordenadores, trabajan también fundamentalmente en las
empresas constructoras de equipos informático (hardware), tanto de ordenado-
res como de los diferentes elementos físicos de las redes. En este mundo abier-
to en que toda máquina se tiene que poder conectar en red adquiere una espe-
cial relevancia la cuestión de los estándares. Las empresas constructoras inten-
tan que su manera de resolver las diferentes opciones arquitecturales se con-
vierta en un estándar de facto, obligando así a los demás competidores a adop-
tar sus soluciones. En esta lucha de los estándares no sólo las empresas cons-
tructoras tienen voz sino que muchas veces es la universidad la que compara
soluciones y propone estándares así como también las asociaciones de empre-
sas usuarias que participan en su adopción.
Tanto por lo que acabamos de decir como por el hecho de que las empresas
tienen que poder decidir, montar y explotar la red de ordenadores de forma
óptima para sus necesidades, los informáticos con buenos conocimientos en
este campo los encontramos también hoy día en prácticamente cualquier ins-
talación informática de cierta importancia.
4.1.3. La fabricación del hardware y de los elementos de comunicaciones
Los ordenadores y los diferentes elementos de la red, una vez diseñados tal
como hemos visto en el apartado anterior, se fabrican. El proceso de fabricación
lo podemos visualizar, al menos conceptualmente, compuesto de una primera
etapa de construcción de componentes y de una segunda de ensamblaje. La base
de los componentes es la electrónica de estado sólido, uno de los otros grandes
avances tecnocientíficos de la segunda mitad del siglo XX, que junto con una
avanzada tecnología de fabricación permite disponer de diferentes circuitos
miniaturizados para realizar funciones logicomatemáticas distintas: los chips.
Combinando chips se obtienen componentes que realizan las más variadas y
complejas funciones. Por último estos componentes son parecidos a lo que los
anglosajones llaman boxes, las cajas, que constituirán los diferentes aparatos
informáticos o telemáticos del mercado: direccionadores, concentradores, servi-
dores, ordenadores personales, etc.
Este proceso de fabricación lo controlan las empresas constructoras de hardwa-
re, normalmente grandes multinacionales, que son las que acaban estampando su
marca en las cajas. Para hacerlo, y visto el estadio de globalización alcanzado hoy
día, no es necesario que todos los componentes hayan sido fabricados por estas
empresas (¡a veces no hay ninguno!), pero sí que normalmente se parecerán a
ellos y sobre todo los someterán a un riguroso control de calidad que es lo que
garantiza el nivel de calidad que el mercado asocia con estas marcas.
Los profesionales que se dedican a estos trabajos trabajan en las plantas de
fabricación de las empresas constructoras y su actividad se relaciona más con las
diferentes áreas de conocimiento de un ingeniero de fabricación que de un
informático tal como normalmente lo entendemos.
4.2. Tecnología del software
Ayudándonos de lo que hemos visto en la tecnología del hardware y aprove-

chando el paralelismo entre este último y el software definiremos la tecnología
del software como el diseño y la construcción de todos los programas que se eje-
cutarán en las “cajas” (boxes) que hemos visto en el apartado anterior, para que
la red de ordenadores realice las diferentes funciones para las que ha sido con-
cebida. Tenemos que pensar que el hardware, aunque variado, tiene un diseño
abierto y generalista (ya lo hemos visto al hablar de qué era un ordenador en la
introducción) y que entonces es el software, los diferentes programas y sus com-

binaciones, lo que proporciona las ilimitadas posibilidades de realizar las diver-
sas funciones que quieren los usuarios.
Para poder disponer de este software en primer lugar se hará el diseño que
fijará la funcionalidad de los diferentes programas y que establecerá también
como éstos, situados en máquinas diferentes conectadas por la red, se entende-
rán entre sí. El diseño de un conjunto de funcionalidades más o menos cohe-
rente y completo, designado normalmente por las palabras aplicación, sistema
informático o similares, dará como resultado unas especificaciones detalladas
que serán el punto inicial para la construcción del software, que es la fase que
vendrá a continuación.
Llegados a este punto tenemos que plantear, sin embargo, una aparente con-
tradicción para justificar el camino que seguiremos para mostrar cómo es este
mundo del software. Pensemos que lo que se diseña y construye con la tecno-
logía del software no es ningún elemento físico, contrariamente a lo que hemos
visto en el caso del hardware. Por eso las actividades de diseño y construcción
de software quedan posiblemente más imbricadas e inseparables formando una
única área de conocimiento, que es la conocida como ingeniería del software, de
la que hablaremos a continuación. Tampoco tiene sentido diferenciar en este
proceso entre diseño y construcción de software para el ordenador y para el con-
trol de la red, ya que los procedimientos de la ingeniería del software para estas
dos partes del sistema informático son similares, si no idénticos.
Así pues, no desglosaremos unas actividades separadas como hemos hecho
en el mundo del hardware y hablaremos de la ingeniería del software como de
una sola disciplina, que es la que posibilita la tecnología del software. Pero esta
aparente uniformidad, e incluso podríamos pensar que sencillez, no debe enga-
ñarnos, ya que la ingeniería del software es un área de conocimientos bastante
amplia, con múltiples implicaciones y, en otro orden de cosas, es generadora de
múltiples puestos de trabajo en el mercado laboral informático de nuestro país.
4.2.1. La ingeniería del software
Como ya hemos ido viendo, la ingeniería del software, como cualquier otra
ingeniería, es un conjunto de conocimientos y procedimientos que ayudan a
diseñar, construir y poner en marcha o en funcionamiento un sistema, que es
el objeto de la ingeniería mencionada. En el caso que nos ocupa, este sistema es
un conjunto de programas que tienen que realizar las funciones para las que
han sido pensados y lo tienen que hacer de forma segura y eficiente.
Todo el proceso de construir un conjunto de programas se emprende nor-
malmente como un proyecto y como tal está estructurado o dividido en varias
etapas. Las etapas o fases clásicas de un proyecto de ingeniería del software son
las de diseño, construcción de los programas o programación, pruebas de los
programas, ensamblaje de los programas para constituir el sistema total, prue-
bas de este sistema, puesta a punto, documentación de todo el proceso y del
producto resultante, formación de los usuarios para que exploten el sistema con
el máximo de utilidad; y todo ello acompañado del control de la calidad de cada
una de estas etapas y de sus productos intermedios.
Otra característica de este proceso es que es intensivo en trabajo humano. En
efecto, tareas como el diseño, la programación o el control de calidad, por men-
cionar sólo tres, implican el trabajo personal de profesionales con los conoci-
mientos específicos para llevarlas a cabo con éxito. De todas maneras esta disci-
plina de la ingeniería del software dispone también de varias ayudas para encau-
zar el trabajo en la línea de una ingeniería cualquiera. Nos estamos refiriendo a
ayudas informáticas (programas o sistemas de programas pensados para ayudar
en la construcción de los sistemas informáticos), recapitulaciones de los cono-
cimientos y maneras de hacer que se han probado con éxito en otros proyectos
(es lo que en inglés se llaman las best practices), estándares, etc.
Los profesionales informáticos que se dedican a este amplio, variado y com-
plejo campo de la ingeniería del software ya os podéis imaginar que tienen tam-
bién diversas cualificaciones y pertenecen a campos de especialización diferen-
tes. Por una parte es lógico pensar que hay una especialización por fases del des-
arrollo del proyecto informático. Así, desde este punto de vista, el mercado ha
distinguido tradicionalmente entre analistas y programadores. Los primeros son
los profesionales más volcados en hablar con los usuarios del futuro sistema
informático, en entender y sistematizar las especificaciones y a partir de éstas
diseñarlo. Los segundos son los constructores de los programas del sistema
informático utilizando las técnicas de programación.
La realidad, sin embargo, es bastante más compleja. Por una parte se ha com-
probado que la frontera entre el diseño y la programación no es nítida. Hay
tareas que se encuentran entre estas dos actividades y tanto los conocimientos
necesarios como muchas de las ayudas informáticas del proceso de la ingenie-
ría del software hacen que la diferenciación clara entre analistas y programado-
res no sea actualmente tan aceptada. Y por otra parte se ha visto que una apli-
cación informática se puede dividir conceptualmente en tres partes o frentes: la

interfaz del usuario, el proceso y los datos. Esta división es posiblemente más
apropiada para hablar de perfiles profesionales y de conocimientos diferentes en
esta área de la ingeniería del software.
Así que tenemos profesionales dedicados a crear las interfaces de la aplicación
con los usuarios, un aspecto de vital importancia ya que será finalmente el usua-
rio de la aplicación quien la utilice con eficacia o la acabará abandonando,
dependiendo en primer lugar de la facilidad o la dificultad para comunicarse y
entenderla. Sólo hay que pensar en las múltiples webs existentes hoy día.
En segundo lugar tenemos a los profesionales dedicados a la gestión eficien-
te de los datos, que representan hoy día otra amplia área de trabajo. Son los res-
ponsables de la agrupación segura y eficiente de los datos (primero ficheros, des-
pués bases de datos y actualmente los grandes almacenes de datos) y de su ges-
tión. También son los especialistas en la explotación de los datos: hay que
ponerlos, así como su significación (la información), al servicio de programas y
de usuarios de todo tipo que los necesiten.
Por último tenemos a los profesionales dedicados al proceso. Son los que uti-
lizarán las técnicas de los diferentes sistemas o paradigmas de programación para
construir los programas.
Como es un área tan extensa los profesionales que se dedican a ella suelen
ser bastante numerosos en nuestro país. Son los que diseñan y construyen los
sistemas de software, según las especializaciones mencionadas. Trabajan nor-
malmente en las empresas que se dedican a esta actividad. Pero los podemos
encontrar también en cualquier otra empresa como profesionales que reciben,
validan y mantienen los sistemas informáticos encargados fuera. Y en estas
empresas usuarias los podemos encontrar incluso como desarrolladores de solu-
ciones a medida o adaptaciones.
4.2.2. Otras características del software y de su ingeniería
Aunque conceptualmente el proceso de la ingeniería del software sea lo

mismo para todas las posibles aplicaciones que se quieran construir, si lo mira-
mos desde el punto de vista de las organizaciones o empresas usuarias de estas
aplicaciones y de sus profesionales informáticos creemos que será esclarecedor
hacer una pequeña digresión. Se trata de hablar de la clásica división entre soft-
ware básico y software de aplicaciones. El software básico es la capa de software
más próxima al hardware, normalmente construida y comercializada por

empresas especializadas y que hace que el hardware sea realmente útil para los
usuarios. En un inicio este software básico fueron los sistemas operativos pero
con el tiempo el mercado ha ido ofreciendo paquetes de software estándar para
resolver muchas otras funciones y necesidades, como los sistemas de gestión de
bases de datos y las aplicaciones más típicas, que van desde la ofimática de los
ordenadores personales hasta los sistemas ERP (sistemas complejos para resolver
las tareas habituales de las empresas comerciales). Así hoy día, más que hablar
de software básico, esta categoría engloba el software estándar o software que se
puede adquirir en el mercado para resolver las necesidades más habituales de los
diferentes usuarios de ordenadores.
Esta oferta de software con funcionalidades cada vez más amplias la encon-
tramos también en el mundo de la gestión de los datos. Nos estamos refiriendo
a los sistemas de ayuda en la toma de decisiones, que son sistemas de informa-
ción pensados para el nivel estratégico de las empresas, o a los paquetes de
minería de datos, que proporcionan la explotación inteligente de cantidades
ingentes de datos para poder extraer la máxima información de ellos.
A pesar de que hemos visto que este software básico o que se puede adquirir
en el mercado se ha ido ampliando con el tiempo, todavía quedan todas aque-
llas aplicaciones que se tienen que hacer a medida porque tienen que resolver
necesidades específicas de una organización: aplicaciones que gestionan las ope-
raciones de la central y de las oficinas de los grandes bancos o aplicaciones que
tienen que resolver las tareas de fabricación industrial o de control de procesos
(la llamada informática industrial y la robótica), por poner un par de ejemplos.
Este hecho nos lleva a comentar una cuestión típica e importante en la gestión
de la informática de las empresas. Ante la necesidad de mecanizar una nueva
área o conjunto de funciones se plantea la disyuntiva de comprar aplicaciones
estándar o desarrollarlas a medida. Normalmente la solución es comprar si
encontramos en el mercado un paquete informático que nos resuelve nuestro
problema o desarrollarlo a medida si no lo encontramos. Hay también una solu-
ción conceptualmente intermedia que es comprar y adaptar. Es cuando no hay
en el mercado exactamente lo que necesitamos pero sí alguna cosa a partir de
la cual, con retoques, ampliaciones o combinaciones, llegaremos a tener lo que
necesitamos.
Todo eso tiene importancia para el trabajo concreto de los profesionales
informáticos implicados en estas decisiones y tareas. Si bien es cierto que el
informático que desarrolla un sistema en principio utilizará la misma discipli-
na, la ingeniería del software, tanto si se trata de un sistema operativo, de un

programa de ofimática o de una aplicación a medida (aunque en cada caso los
conocimientos propios de cada uno de estos tres ejemplos le serán de gran uti-
lidad), es igualmente cierto que la actuación y los conocimientos de los profe-
sionales implicados en la disyuntiva de comprar, adaptar o construir un sistema
informático serán diferentes. Si la empresa ha comprado un software sus profe-
sionales deberán tener un conocimiento de las funcionalidades de este software
y posiblemente lo tendrán que instalar, afinar (el tuning) para sacar el máximo
rendimiento y ayudar a los usuarios a usarlo. Si por el contrario se decide des-
arrollar a medida el software entonces los informáticos tendrán que ser compe-
tentes en todos los conocimientos y técnicas de la ingeniería del software para
construir el sistema informático. Y si por último la solución está en la vía de
comprar y adaptar, en este caso los conocimientos y tareas de los informáticos
son una suma de las requeridas en los dos casos anteriores: tienen que conocer
lo que se compra, tienen que saber desarrollar pequeñas partes, tienen que saber
ensamblar el conjunto resultante (es el system integration), tienen que saber ins-
talarlo y afinarlo, probar que al final todo funciona según las previsiones y nece-
sidades y enseñar a los usuarios a usarlo.
Los profesionales que se dedican a este campo tan amplio son necesarios en
cualquier instalación informática ya que en todas, en un momento u otro, se tie-
nen que instalar sistemas informáticos. Y como podéis ver los conocimientos son
variados. Además de la clásica diferenciación entre analistas y programadores, y
de la diferencia entre especialistas en interfaces, procesos y datos, que hemos
visto anteriormente, también hay que añadir esos conjuntos de conocimientos
ligados a las decisiones empresariales de comprar, adaptar y desarrollar.
5. Reparación, formación, consultoría, auditoría y peritaje
Después de lo que hemos ido viendo hasta aquí podemos dar por sentado
que los usuarios, desde un individuo en su casa hasta la gran empresa u organi-
zación, utilizan los diferentes sistemas informáticos para sus actividades diarias.
En este uso de la informática no sólo quieren que el sistema funcione, no se
estropee, sino que también quieren sacarle el máximo rendimiento posible.
Nos encontramos ante un área amplia y diversa de actividades profesionales

dirigidas al máximo aprovechamiento del sistema informático por parte del
usuario. En el nivel más básico estarían las actividades relacionadas con la repa-
ración y corrección de malos funcionamientos y errores en el hardware o en el
software. Generalmente la misma empresa a la que se ha comprado el hardwa-
re o bien un representante suyo será quien se encargue de esta reparación, que
casi siempre será el cambio de algún componente. Si se trata de software será
también la empresa en la que lo hemos comprado o bien que nos ha construi-
do el sistema la que normalmente corrija el error proporcionándonos la mayor
parte de las veces una nueva versión del software que falla. Los profesionales que
detectan estos fallos y los arreglan, cada vez más, utilizan de una manera bas-
tante mecánica sistemas sofisticados como detección y corrección. Estos siste-
mas han sido concebidos y construidos en el mismo proceso de diseño y cons-
trucción del hardware y software correspondientes.
Otra área de actividad profesional es la formación de los usuarios en la utili-
zación, sobre todo, de los programas, ya que ellos son los que controlan la inter-
faz persona-máquina. Esta formación puede hacerse con cursos estándar nor-
malmente impartidos en academias de informática o a medida en casa del clien-
te y para el sistema informático en concreto que tiene que utilizar. Tanto en un
caso como en el otro podríamos decir que no hay propiamente una especializa-
ción de “formador” informático. Acostumbran a ser las mismas personas espe-
cialistas en el software concreto, porque lo han hecho o bien porque lo venden
o instalan, las que enseñan a los diferentes usuarios cómo utilizarlo.
Ahora bien, si pensamos sobre todo en instalaciones grandes, en empresas u
organizaciones de cualquier tipo y en la complejidad que pueden llegar a tener
los sistemas informáticos, entonces es fácil imaginarnos que muchas veces los
responsables de estos sistemas ante algún problema busquen el asesoramiento
y el diagnóstico de un profesional informático de alto nivel para saber hacia
dónde se tiene que encaminar la solución. Creemos Pensemos que los proble-
mas que mencionamos pueden ser de todos tipos y normalmente con una fuer-
te implicación económica detrás. Por ejemplo, relacionado con el dilema de
comprar o desarrollar que hemos visto antes, se pueden plantear la cuestión de
si hay en el mercado algún producto adecuado para sus necesidades, qué coste
tiene, y si lo hay, entonces, qué arquitectura de productos, qué marca de pro-
ductos será la más idónea, y otras cuestiones generales que hay que responder
antes de comprar, encargar o construir a medida la solución a la necesidad que
se tiene. Este trabajo se acostumbra a llamar consultoría.
La auditoría, aunque muy relacionada con la consultoría, es una actividad

dirigida no tanto al asesoramiento para la resolución de un problema concre-
to sino dirigida al asesoramiento para establecer el estado de un área más
amplia de los sistemas informáticos de una organización. Sería, por ejemplo,
el caso en que los responsables de una empresa quisieran saber cómo se des-
arrollan las aplicaciones informáticas en su casa: si se utilizan las técnicas
adecuadas, si se sigue la metodología prescrita, si los costes son aceptables,
etc. Otro ejemplo podría ser revisar todos los aspectos relacionados con la
seguridad del sistema informático. Son estudios que pueden ser verdadera-
mente complejos. Pensemos, con respecto a este último ejemplo, en la gran
cantidad de disciplinas que intervienen para calibrar la seguridad: desde
temas informáticos como las copias de seguridad de archivos hasta temas de
ingeniería civil como la resistencia de las instalaciones ante un terremoto o
unas inundaciones.
En último lugar, la actividad informática tiene también implicaciones
jurídicas ya que puede ocasionar conflictos que se terminan dirimiendo en
un juicio. Los profesionales informáticos que estudian uno de estos casos y
presentan sus pruebas y conclusiones en un juicio son los peritos informáti-
cos y su trabajo es el peritaje informático.
Consultores, auditores y peritos son normalmente informáticos séniores
que por un lado han adquirido una sólida experiencia en diferentes aspectos
de la profesión informática tal como los hemos ido viendo hasta ahora y por
otra se han formado en las técnicas específicas de cada una de estas activida-
des. Es decir, combinan conocimientos profundos de varias áreas informáti-
cas con otros específicos como pueden ser los aspectos legales relacionados
con las cuestiones informáticas o los diferentes estándares del mundo infor-
mático. Estos últimos son muy importantes, sobre todo en auditoría, porque
dan normalmente una base con la cual comparar el estado del área empresa-
rial que se tiene que auditar. Consultores, auditores y peritos muchas veces
combinan todas estas actividades. Son profesionales que encontraremos tra-
bajando en empresas especializadas en estos servicios o bien como freelance,
o a veces combinando también las dos actuaciones.
6. Dirección de empresas, departamentos

y equipos informáticos
En el mundo laboral encontraremos también informáticos que se dedican a

tareas de dirección. Pueden dirigir empresas que producen o distribuyen pro-
ductos y servicios informáticos, por ejemplo venta de componentes de hardwa-
re, producción y venta de paquetes de software, construcción de aplicaciones a
medida para los clientes, asesoría para empresas, etc. Estos profesionales pueden
igualmente estar al frente de los departamentos de informática de las diferentes
empresas, por ejemplo director de informática de un banco o de una fábrica de
automóviles o de una empresa de distribución eléctrica. Esta persona es la res-
ponsable del servicio que la informática proporciona a la empresa. Este servicio,
que podemos decir que cada día es más importante para el buen funcionamien-
to de la empresa, tiene que ser el adecuado, sin interrupciones, sin errores y pro-
porcionando todas las funciones necesarias.
Estos profesionales deben tener un perfil que combine conocimientos infor-
máticos con otros de gestión y dirección. Los primeros, aunque puedan ser
generales, tienen que ser suficientes para entender la problemática que tienen
entre manos. Los segundos comprenden temas como la dirección de grupos de
personas, gestión y control de presupuestos, estudios de oportunidad y estrate-
gia empresarial, etc.
Dentro de este tipo de actividad profesional tiene una relevancia especial la
dirección y la gestión de proyectos informáticos, especialmente los relaciona-
dos con la ingeniería del software. En efecto, muchas actividades informáticas
se suelen llevar a cabo estructurándolas como un proyecto, es decir, con una
definición precisa del alcance del trabajo que se tiene que hacer, una asigna-
ción de recursos y un control estricto del progreso del trabajo hasta llegar a
tener el producto final deseado. Pensemos en proyectos como la puesta a
punto de una aplicación para mecanizar unas tareas concretas de una empre-
sa; la instalación de un sistema informático, hardware, comunicaciones y soft-
ware, en una nueva sucursal bancaria; y tantos otros ejemplos que podríamos
poner. Es lógico que todos estos proyectos tengan que estar bien planificados
y dirigidos para asegurar el éxito. De hecho muchos informáticos se han espe-
cializado en este tipo de dirección y trabajan como directores de proyectos
informáticos. Son profesionales que tienen conocimientos informáticos gene-
rales para conocer bien lo que están gestionando y además utilizan conoci-
mientos que les permiten planificar y gestionar el día a día de los proyectos.
Como ya hemos visto antes, estos informáticos tienen que poder dirigir equi-
pos humanos y controlar gastos con la ayuda de presupuestos, entre otras
cosas, pero además tienen que ser especialistas en herramientas de planifica-
ción y seguimiento de los proyectos y en caso de que éstos sean de desarrollo
de software tienen que conocer muy bien las técnicas y metodologías que nos
enseña la ingeniería del software.
7. Comercialización de productos y servicios informáticos
Por último debemos decir que también hay una parte de los informáticos
que se dedica a la venta de los productos y servicios informáticos de los que
hemos ido hablando en los apartados anteriores. Hemos visto que hay todo un
tejido de empresas, de las más grandes a las más pequeñas, que se dedican a pro-
ducir hardware, software y servicios asociados a la instalación y el uso de los pri-
meros. Es evidente que en el mundo en que vivimos, dominado por la oferta, la
publicidad y el marketing, los productos y servicios informáticos se tienen que
dar a conocer en el mercado y tiene que haber informáticos especializados en
su venta. Podemos encontrar profesionales que sólo se dedican a la comerciali-
zación y la venta y otros que combinan esta tarea comercial con la más técnica
del servicio posventa del producto, o bien la combinan con la dirección del pro-
yecto subsiguiente para la puesta en marcha del producto o servicio que el clien-
te ha adquirido. Todo dependerá de la dimensión de la empresa y de la comple-
jidad técnica del producto. Cuanto más grande sea una empresa probablemen-
te más definidas y separadas estén las responsabilidades de los empleados entre
vendedores y técnicos, y al revés, cuanto más pequeña sea la empresa más fácil
será que los mismos informáticos hagan todas las tareas de un contrato con el
cliente: venta, dirección y ejecución de la puesta en marcha de lo que se ha ven-
dido. Por otra parte cuanto más complejo y avanzado sea el producto que una
empresa quiere vender más necesitará que un técnico que entienda intervenga
también en las tareas relacionadas con la venta.
Los profesionales que se dedican a comercializar productos y servicios infor-
máticos combinan los conocimientos de las técnicas comerciales (publicidad,
aspectos legales y contractuales, técnicas de venta y seguimiento de clientes)

con el conocimiento general del producto o servicio vendido.
Resumen
En este punto damos por acabada esta exposición de las diferentes activida-
des profesionales de los informáticos y de los conjuntos de conocimientos aso-
ciados con cada una de ellas. A continuación, en módulos posteriores, encon-
traréis una descripción bastante más detallada y profundizada de algunos de
estos conjuntos o áreas de conocimiento.
© Editorial UOC 47 Arquitectura de los sistemas informáticos
Capítulo II
Arquitectura de los sistemas informáticos

Jordi Tubella Murgadas
1. Introducción
Los sistemas informáticos constituyen, hoy día, un pilar fundamental en el

que se sustentan organizaciones de todo tipo para dar apoyo a sus actividades,
organizaciones que van desde grandes compañías o ministerios públicos a
pequeñas asociaciones de personas o microempresas. Aquí nos referiremos a los
sistemas informáticos como los conjuntos de computadores, periféricos, redes y
programas que interactúan para dar un servicio o producto concreto. El compo-
nente computacional tiene que permitir introducir, almacenar, procesar y visua-
lizar la información que gestiona y los servicios y productos que proporciona,
no sólo de la manera más correcta y efectiva, sino también de la manera más
cómoda e intuitiva para las personas que interactúan.
Los computadores nos proporcionan la capacidad de poder procesar la
información con vistas a conseguir la más variada posibilidad de aplicaciones
informáticas. En este contexto, cuando hablamos de un computador debemos
entender que es un dispositivo electrónico capaz de ejecutar aplicaciones de
propósito general. Así, por ejemplo, tanto puede ayudar a editar vídeo como
a resolver problemas contables.
La flexibilidad de uso de los computadores es lo que ha hecho que sean atrac-
tivos para una multitud de usuarios, que se pudieran abaratar costes y que salga
rentable investigar en nuevas tecnologías. Este círculo es básico para entender
el gran dinamismo que se da en este campo. De esta forma se está consiguien-
do que la capacidad de proceso se vaya incrementando progresivamente, de
manera que se duplica cada dos años, según establece la Ley de Moore (podéis
consultar la referencia en http://es.wikipedia.org/ wiki/Ley_de_Moore para ver los
detalles). También se incrementa la capacidad de almacenaje, de la misma
manera que disminuye la potencia que consumen y, como consecuencia, la

temperatura que disipan cada vez es menor.
Hay segmentos de mercado tan importantes que han conseguido que sea fac-
tible que los computadores se especialicen en procesar ciertas aplicaciones especí-
ficas. Así, han aparecido dispositivos electrónicos que realizan una determinada
función, como teléfonos móviles, consolas de videojuegos, reproductores de
audio y de vídeo, etc. La cantidad de dispositivos existentes y que pueden apare-
cer en el futuro es muy destacable. De hecho, las posibilidades son múltiples tanto
con respecto a la aparición de nuevos dispositivos como para unir diversos dispo-
sitivos individuales para que converjan según pide el mercado. Por ejemplo, es
factible pensar ya en dispositivos que integren la telefonía, la radio y la televisión.
La cantidad de procesamiento digital que requieren estos sistemas es enorme.
En este capítulo se describe la arquitectura que conforman los sistemas infor-
máticos y se hace especial hincapié en los sistemas distribuidos. En este contex-
to, entendemos el término arquitectura como los elementos o bloques que cons-
tituyen estos sistemas. Describiremos las diferentes capas del software, desde el
nivel de las aplicaciones que nos permite ejecutar programas hasta el nivel del
sistema operativo, que contiene el software para controlar los recursos del com-
putador.
Con la infraestructura de red adecuada, estos computadores se pueden
conectar entre sí para construir un sistema distribuido, en el que la comunica-
ción y la coordinación a través de la red se hacen mediante el paso de mensa-
jes. Además, un computador genérico está compuesto por una unidad central
de proceso, también llamada simplemente procesador, una memoria que alma-
cenará el programa que se tiene que ejecutar, y unos elementos de entrada/sali-
da que permitirán interaccionar con el exterior. Todos estos bloques están
conectados por buses, que no son más que los caminos de comunicación entre
estos elementos.
Todo ello nos permite diseñar estos sistemas informáticos, que ofrecen
actualmente una notable capacidad de proceso y permiten la comunicación
desde cualquier lugar del planeta.
Intentaremos entrar en el detalle de estos sistemas informáticos siguiendo
una visión top-down, es decir, empezaremos por su funcionalidad principal e ire-
mos bajando descriptivamente hasta la explicación de los elementos básicos
que los constituyen.
2. Software de los sistemas informáticos
Hoy en día los computadores, sean personal o portátiles, tienen unas capa-
cidades de proceso muy elevadas y están cada vez más introducidos en la vida
cotidiana de las personas. La generación actual de computadores nace, por una
parte, con el desarrollo del microprocesador (procesador integrado en un único
chip), que permitió reducir el tamaño y el coste de los computadores, aumentó
sus prestaciones y permitió el acceso a un mayor número de personas, y por otra
parte, con el desarrollo de las redes de área local y de comunicaciones, que per-
mitieron conectar computadores con posibilidad de transferir datos a gran velo-
cidad.
En este contexto ha aparecido el concepto de sistemas distribuidos, que tiene
como ámbito de estudio todos aquellos sistemas informáticos constituidos en
red, tanto Internet como las redes de telefonía móvil, las redes corporativas u
otras.
Hay infinidad de ejemplos de aplicaciones que podemos considerar sistemas
distribuidos.1 Entre otros, podemos citar:
• Acceso a páginas web, al correo electrónico y a bases de datos para buscar
información, que están habitualmente presentes en todos los sistemas
informáticos.
• Capacidad de compartir todo tipo de archivos.
• Juegos en red.
• Videoconferencias, mensajería instantánea.
• Sistemas de reserva de billetes de líneas aéreas, aplicaciones bancarias, etc.
En general, compras comerciales a través de Internet (e-commerce).
• Enseñanza asistida por ordenador.
En esta sección, primero haremos un repaso de las aplicaciones web más uti-
lizadas y, posteriormente, pasaremos a describir las características principales de
la arquitectura en el ámbito del software de los sistemas distribuidos.
2.1. Aplicaciones web
El acceso a las páginas web, el correo electrónico y la búsqueda de informa-

ción constituyen tal vez las aplicaciones web que son más populares.
2.1.1. Acceso a la web
Las páginas web ofrecen un contenido multimedia que puede incluir texto,
imagen y sonido, así como referencias a otros elementos de información
siguiendo el modelo de los sistemas hipertexto. La navegación siguiendo los
hipertextos consiste en presentar en un documento un enlace a un recurso dife-
rente y ofrecer mecanismos para acceder de manera inmediata.
El servicio web sigue el modelo cliente/servidor. En el modelo cliente/servidor de

un sistema distribuido hay un cliente que solicita un determinado servicio a tra-
vés de un computador y un servidor que proporciona ese servicio desde otro com-
putador.
Las páginas web contienen básicamente dos elementos: la información y la

manera como se tiene que presentar esta información. Esta información se espe-
cifica siguiendo el estándar HTML. El servidor de la página web tiene la infor-
mación almacenada. El cliente se encarga de solicitarla y presentarla al usuario
a medida que la va obteniendo. Hay diferentes servidores y clientes web. Los
clientes más conocidos son: Mozilla (que es de código abierto y es continuación
de Netscape) y el MS-Internet Explorer. El servidor más utilizado es Apache, un
servidor de software libre (www.apache.org).
La comunicación entre el cliente web y el servidor web se hace a través del
protocolo HTTP. Este protocolo permite tanto que el cliente baje datos del ser-
vidor (operación de consulta de páginas web) como que el cliente envíe datos
al servidor (p. ej. cuando se llena un formulario o cualquier otra información
que se envía al servidor).
Las páginas que almacenan los servidores en un primer momento eran estáti-
cas (siempre son iguales y se presentan de la misma manera). Una primera evolu-
ción fueron las páginas dinámicas, que consisten en que la página que se devuel-
ve al usuario que accede al servidor web se genera en el momento del acceso. Esto
es así porque en realidad no se está accediendo a un fichero (como es el caso de
las páginas estáticas) sino a un programa que formatea el resultado de su ejecu-
ción como si fuera una página web. Esta manera de funcionar es la que utilizan
las aplicaciones que tienen una interfaz web (p. ej. el campus virtual de la UOC).
El siguiente paso fue conseguir que la página que recibe el navegador incluya un
código que permite que la página se presente de manera diferente según el clien-
te que lo ejecute. Lo cual ha dado mucha más potencia a la hora de utilizar la web
como interfaz de aplicaciones.
2.1.2. Correo electrónico
Al igual que el correo tradicional, el correo electrónico es un medio de comuni-

cación asíncrono, en el que la gente envía y recibe mensajes cuando le conviene
hacerlo, sin tener que coordinarse con nadie más. A diferencia del correo tradicio-
nal, es rápido, fácil de distribuir y barato. Utilizando listas de distribución, un men-
saje se puede enviar a miles de receptores de una sola vez. Además, los mensajes de
correo electrónico modernos incluyen adjunciones, hiperenlaces, texto formatea-
do en HTML, imágenes, sonido, vídeo y applets –pequeños programas escritos en
Java, un lenguaje de programación concreto.
El correo electrónico también se gestiona utilizando el modelo cliente/servi-
dor. El cliente de correo envía el mensaje al servidor de correo utilizando el pro-
tocolo SMTP. El receptor obtiene el correo del servidor utilizando uno de los dos
protocolos siguientes:
• POP3: En este caso el correo se copia en el ordenador del receptor y el men-
saje se borra del servidor. Antes de poder acceder a un mensaje nuevo, el
receptor tiene que haber recibido todo el correo pendiente.
• IMAP: En este caso el receptor recibe la información sobre la cabecera de los
mensajes. El contenido del mensaje llega al receptor sólo en caso de que éste
lo quiera leer. Los mensajes no se borran del servidor si el cliente no lo indi-
ca explícitamente. De esta manera se puede acceder rápidamente al correo
desde muchos ordenadores diferentes.
Otra modalidad de correo es la que ofrecen los gestores de correo vía web. En
este caso, se accede al correo como si se accediera a una página web. Tanto si es
en el caso del emisor como en el del receptor, el usuario utiliza el navegador que
tiene instalado en el ordenador para enviar o recibir correo utilizando el proto-
colo HTTP. Ejemplos de correo vía web son el correo del campus virtual de la
UOC o los correos que proporcionan sitios web como Yahoo o Hotmail.
En cuanto al correo electrónico hay otros aspectos importantes: los virus y los
filtros para el correo no deseado (spam). Los virus ya se han asociado al correo
electrónico. Por una parte, porque se reciben ficheros que pueden estar infecta-
dos (programas ejecutables o ficheros que tienen la capacidad de ejecutarse, p. ej.
los macros de los programas de ofimática de MS-Office) y, sobre todo últimamen-
te, por problemas de seguridad de los clientes de correo, que permiten ejecutar
el código que llega en un mensaje. El correo no solicitado, también llamado
spam, es un problema que cada vez se va haciendo más patente. A diferencia del
correo no solicitado que recibimos en papel en casa, el correo electrónico no

tiene ningún coste para el emisor, mientras que el receptor tiene que dedicar un
tiempo tanto para conectarse como para borrarlo. Para hacer frente a este proble-
ma, existen los programas de tipo filtro que se encargan de analizar los mensajes
para detectar y marcar el spam o incluso borrarlo directamente.
2.1.3. Sistemas de búsqueda en Internet
El número de páginas web sigue creciendo de forma constante. La gran can-

tidad de información disponible es un atractivo más de la red Internet, a pesar
de los problemas evidentes de mantenimiento y de fiabilidad de esta informa-
ción. Este hecho determina que uno de los principales usos que los usuarios
hacen de Internet sea la búsqueda de información por palabras clave. Se pueden
destacar varios sistemas de búsqueda: Yahoo, Lycos, Altavista y el más utilizado,
Google, debido a su mayor rapidez y al mayor número de páginas encontradas.
También hay otros sistemas de búsqueda que se llaman metabuscadores, siste-
mas que utilizan más de un buscador y muestran sus resultados de forma resu-
mida y ordenada.
2.2. Sistemas distribuidos
Los sistemas distribuidos son sistemas informáticos en los que los componentes
de hardware y software están conectados en red y comunican y coordinan sus
acciones mediante el paso de mensajes. La comunicación se establece a través de
un protocolo prefijado, como el esquema cliente-servidor, de igual a igual, o
puede ser definido de forma particular por la aplicación, como en la ejecución
paralela de aplicaciones.
En la sección anterior ya hemos comentado brevemente al modelo

cliente/servidor, en el cual el cliente hace una petición de servicio, y los servi-
dores, una vez recibidas estas peticiones, las resuelven y devuelven el resultado
al cliente.
Aparte del modelo cliente/servidor, se utiliza también el modelo de igual a igual

(peer-to-peer, P2P). En este caso no hay nodos (ordenadores) cliente y nodos servidor
sino que todos los nodos del sistema se comportan de la misma manera y son al
mismo tiempo clientes y servidores. También se acostumbra a llamarlo “modelo

punto a punto” o “entre iguales”.
Este tipo de redes son muy utilizadas para compartir ficheros entre los usua-
rios. Las redes P2P son objeto de mucho interés en los medios de comunicación
por cuestiones legales cuando los ficheros que se intercambian los usuarios
están sometidos a derechos de autor. En cualquier caso, el número de ficheros
de audio y vídeo que se intercambian con estas redes no deja de aumentar día
a día. La forma de poder saber dónde se encuentra la información es a través de
nodos que contienen una especie de índices hacia el lugar donde está esta infor-
mación. Actualmente, se utilizan programas basados en algoritmos totalmente
descentralizados para identificar la información.
Otro ejemplo de las aplicaciones de igual a igual que se están popularizando
muy rápidamente entre los usuarios de Internet es la mensajería instantánea. Ya
empieza a ser habitual que muchos internautas tengan activa durante todo el
día la aplicación de mensajería instantánea y se comuniquen con sus amigos,
conocidos o compañeros de trabajo.
En el modelo cliente/servidor y en el modelo de igual a igual hay una peti-
ción que hace un nodo que es servida por un servidor u otros nodos del siste-
ma. Hay un modelo intermedio llamado publicación/suscripción, en que el
productor de la información anuncia la disponibilidad de esta información y el
consumidor de la información se suscribe a los canales que difunden la infor-
mación y entonces puede decidir dónde ir a buscarla.
A la hora de diseñar estos sistemas distribuidos hay que tener en cuenta los
siguientes aspectos:
• Heterogeneidad. El sistema distribuido está formado por una variedad de
redes, sistemas operativos, lenguajes de programación o hardwares del
ordenador. Es necesario que todos estos diferentes elementos puedan inter-
actuar entre sí.
• Apertura. Es deseable que el sistema se pueda extender fácilmente, es decir,
que se puedan añadir nuevos recursos y servicios compartidos y que éstos
estén a disposición de todos los componentes del sistema.
• Seguridad. Es un aspecto crítico poder saber la identidad de los usuarios o
agentes que intervienen en el sistema.
• Escalabilidad. Un sistema es escalable si mantiene la eficiencia cuando se
aumentan los recursos y el número de usuarios.
• Tolerancia a fallos del sistema. Cuando un componente del sistema falla,

tendría que seguir funcionando el sistema global sin problemas.
• Concurrencia. Los diferentes componentes de un sistema distribuido pue-
den pedir acceder a un recurso simultáneamente. Es preciso que el sistema
esté diseñado para permitirlo.
• Transparencia. La transparencia persigue que ciertos aspectos del sistema
estén ocultos en las aplicaciones, como por ejemplo la ubicación de un
recurso o la replicación de los datos.
2.3. Sistema operativo
La última capa de software está formada por el sistema operativo. El sistema ope-
rativo se encarga de coordinar el hardware del computador y la entrada y la sali-
da, el almacenaje y el procesamiento.
Cada computador debe tener un componente de software que se tiene que

activar cuando el computador se pone en marcha. Este componente puede
residir en la memoria ROM, en el disco duro o bien en un disco externo que
se inserta en el momento inicial. Los primeros computadores tenían cada uno
un sistema operativo propio, por lo cual los programas diseñados para una
máquina en concreto no se podían ejecutar en un modelo diferente.
La universalización de los sistemas operativos empieza con el sistema ope-
rativo UNIX. Los orígenes se remontan a 1968. Tras un intento que no crista-
lizó, en 1969 Ken Thompson y Dennis Ritchie consiguieron completar este
sistema operativo y fue el primer escrito totalmente en un lenguaje de alto
nivel, el lenguaje C.2 Eso permitió trasladar fácilmente este sistema operativo
a otras máquinas e hizo aumentar la popularidad de la filosofía UNIX.
También hay que mencionar que a partir del primer computador personal
(IBM-PC en 1971) la empresa Microsoft diseñó un sistema operativo para esta
máquina (PC-DOS) y para cualquier computador PC compatible (MS-DOS).
Eso constituyó un punto de inflexión para extender el uso de los computado-
2. El lenguaje de programación C es el más usado en el desarrollo de sistemas operativos, así como

en el desarrollo de aplicaciones, aunque en este punto cada vez se opta más por sus lenguajes suce-
sores C++ y Java. Se combina la robustez de los lenguajes de alto nivel con la eficiencia de poder
trabajar muy cerca de los lenguajes máquina de los computadores. Todo esto se explica en profun-
didad en el capítulo “Programación”.
res y ha hecho de Microsoft una de las empresas más importantes del mundo.
EL MS-DOS ha ido evolucionando hacia múltiples versiones hasta llegar a la
que actualmente está disponible en el mercado, llamada MS Windows Vista.
Por otra parte, un estudiante finlandés, llamado Linus Torvalds, tuvo en
cuenta la filosofía UNIX para desarrollar un sistema operativo que estuviera
disponible para todo el mundo que estuviera interesado en él, lo cual abrió la
puerta a lo que actualmente se llama software libre. Este sistema operativo se
llama GNU/Linux y actualmente está bastante extendido dado que su licen-
cia (GNU Public License, GPL) garantiza la libertad de distribución (entre otras
libertades) a todos sus usuarios.3
Entrando en un poco más de detalle, las tareas de un sistema operativo
son:
• Asignar y controlar los recursos del sistema, definiendo qué aplicación y
en qué orden se tienen que ejecutar.
• Gestionar la memoria del sistema, que es compartida por todas las apli-
caciones.
• Gestionar los sistemas de entrada/salida, incluyendo los discos duros, las
impresoras y todo tipo de puertos.
• Enviar mensajes de estado a las aplicaciones, al administrador del siste-
ma o al usuario sobre cualquier error o información necesaria para que el
sistema trabaje de una forma estable.
Teniendo en cuenta que el paso de mensajes es la forma de comunicación

en los sistemas distribuidos, la parte del sistema operativo encargada de con-
trolarlo sigue la familia de protocolos de Internet llamada TCP/IP. Esta fami-
lia de protocolos permite dividir y ordenar la información que tiene que
transportarse en paquetes de tamaño más pequeño y establecer el direcciona-
miento de la información a través de la red Internet.
3. Si queréis saber más cosas sobre el software libre y la GPL... Podéis consultar el sitio web de la Free
software Foundation (FSF): http://www.fsf.org/
3. Hardware de los sistemas informáticos
En la introducción hemos definido la arquitectura Von Neumann como el

modelo que constituye el pilar básico de los ordenadores actuales. De acuerdo con
este modelo de arquitectura Von Neumann, un computador consta de un proce-
sador, de un subsistema de memoria y de un subsistema de entrada/salida.
Arquitectura Von Neumann
La memoria contiene tanto los datos como las instrucciones de los progra-
mas. El procesador, formado por una unidad de proceso (UP) y una unidad de
control (UC), tiene la tarea de extraer las instrucciones de la memoria, desco-
dificarlas (es decir, entender qué operación desean hacer) y ejecutarlas. Las ins-
trucciones son ejecutadas en secuencia (es decir, una detrás de la otra y en el
orden en que están almacenadas) y sólo las instrucciones de salto pueden rom-
per esta secuencia. El subsistema de entrada/salida (E/S) permite la comunica-
ción con el exterior, sea con otros computadores o con los usuarios que inter-
accionan. Con este subsistema y la infraestructura de red adecuada, los com-
putadores se comunican entre sí.
El estilo de programación que se adapta mejor a este modelo es el procedimen-
tal. Cualquier programa tiene que ser descrito a la máquina como una secuen-
cia de instrucciones. La máquina espera un programa que le dice qué tiene que
hacer en cada instante de tiempo.
Podríamos hacer una analogía del funcionamiento de un computador con
el sistema nervioso del cuerpo humano. La memoria y el procesador estarían
localizados en el cerebro, y el sistema de E/S serían los diferentes sentidos
–oído, vista, gusto, tacto y olfato– más el sistema del habla como salida.
3.1. Unidad central de proceso
La unidad central de proceso (CPU), también llamada simplemente procesador,

es el elemento del computador encargado de ejecutar el programa guardado en la
memoria. En realidad, ejecutar no es más que interpretar el conjunto de instruc-
ciones que conforman el programa almacenado en un momento determinado en
la memoria de la máquina.
Una instrucción tiene una medida determinada (medida en número de bits o

de grupos de 8 bits –el byte– que ocupa) y está organizada en una serie de partes
fijas (denominadas campos) cada una de las cuales contiene un tipo de informa-
ción. Así, generalmente, el primer campo es el código de operación, un número que
identifica la operación que hay que hacer (sumar, restar... o cualquier operación
que permita el procesador). Los otros campos que siguen al código de operación son,
generalmente, los operandos, que indican cuáles son o dónde están los datos sobre
los que se tiene que aplicar la operación y dónde hay que guardar el resultado.
Las fases que el procesador tiene que realizar para interpretar las instruccio-
nes son las siguientes:
• Extraer la instrucción correspondiente de la memoria (fase de búsque-
da). Según la medida y el formato de las instrucciones, la búsqueda será más
o menos compleja. Por ejemplo, las máquinas RISC (reduced instruction set
computer) tienen todas las instrucciones del mismo tamaño. De esta mane-
ra, la circuitería necesaria es más sencilla y rápida. La contrapartida son las
máquinas CISC (complex instruction set computer) en las que las instrucciones
son de tamaño variable.
• Determinar qué operación tiene que realizar la instrucción (fase de des-
codificación). Aquí también es fundamental el formato de las instrucciones.
El hecho de que el código de operación ocupe una posición concreta dentro
de la instrucción y que tenga un tamaño concreto facilita esta descodifica-
ción. Las máquinas RISC, además, tienen pocas instrucciones en el reperto-
rio, lo cual facilita todavía más esta tarea. De forma opuesta, una máquina
CISC contiene un gran número de instrucciones.
• Obtener los datos con que se tiene que operar (fase de búsqueda de operan-
dos). El formato de las instrucciones determina cuántos operandos se permi-
te que tengan. Los operandos pueden ser fuente, es decir contener o indicar
los valores sobre los cuales se tiene que realizar la operación, o destino, es
decir, indicar dónde se tiene que guardar el resultado de la operación,
Pueden ser 3 (dos operandos fuente y uno de destino), 2 (caso en el que el
destino coincide con uno de los operandos fuente) o, incluso 1, en el caso

de operaciones de un solo operando fuente que se hace coincidir con el des-
tino del resultado. También determina el lugar en el que están guardados,
ya sea en la memoria, en la misma instrucción o en registros. Los registros
son elementos de almacenaje de información con un tiempo de acceso más
pequeño que la memoria.
• Realizar la operación correspondiente (fase de ejecución). Durante esta fase
se realiza la operación. Normalmente, según el tipo de procesador, tendre-
mos las 4 operaciones aritméticas básicas (suma, resta, producto y división)
sobre datos de tipo entero y real, y operaciones lógicas que realizan la com-
plementación (NOT), la suma lógica inclusiva (OR) y exclusiva (XOR), y el
producto lógico (AND) del álgebra booleana.
• Almacenar el resultado de la operación (fase de escritura). Al igual que
para los operandos fuente, la instrucción especifica también el lugar en que
se tiene que guardar el resultado calculado.
• Identificar la instrucción siguiente que hay que ejecutar (control de la
secuenciación). La secuenciación de las instrucciones es implícita, es decir,
que después de ejecutar una instrucción se tiene que ejecutar la que hay
justo a continuación de la memoria. Esta secuenciación se puede romper en
cualquier momento por la existencia de instrucciones de salto, que permi-
ten especificar de forma explícita la dirección de memoria donde reside la
próxima instrucción que se tiene que ejecutar. Estos saltos pueden ser
incondicionales o condicionales. De esta manera podemos ejecutar diferen-
tes fragmentos del código de un programa en función de los resultados pre-
cedentes de las instrucciones (lo que se correspondería con las sentencias
condicionales de los programas de alto nivel) o bien saltar atrás en el pro-
grama para poder realizar bucles y reaprovechar el código del programa para
operar con otros datos (lo que se correspondería con las sentencias iterati-
vas de los programas de alto nivel).
Con esta secuencia realmente simple de fases, repetida ad infinitum, el pro-

cesador es capaz de ejecutar programas de cualquier complejidad.4
4. Los procesadores superescalares, como el Intel Pentium, siguen este modelo del ciclo de ejecu-
ción de las instrucciones, pero disponen de optimizaciones arquitectónicas que aumentan sus pres-
taciones: son capaces de encabalgar la ejecución de una instrucción con las siguientes y permiten
iniciar la ejecución de más de una instrucción en cada ciclo.
Conviene que sepamos que el procesador está constituido internamente por

dos unidades:
• La unidad de proceso (UP). Contiene los registros, que guardan datos del
programa; la unidad que realiza las operaciones que mandan hacer las ins-
trucciones; y los buses, que permiten interconectar todos los elementos
entre sí.
• La unidad de control (UC). Se encarga de generar las señales de control
para ejecutar las instrucciones. Para cada instrucción, genera una secuen-
ciación de señales que se envían a la unidad de proceso y que permiten rea-
lizar las fases mencionadas anteriormente.
3.2. Subsistema de memoria
La memoria almacena las instrucciones y los datos, incluyendo los resultados fina-
les e intermedios, de los programas. Está formada por un espacio de un solo nivel de
direcciones con una organización lineal de las palabras. Sobre la memoria, el proce-
sador puede efectuar operaciones de lectura y de escritura.
La comunicación entre el procesador y la memoria es, desde los primeros

computadores, uno de los principales cuellos de botella del modelo Von
Neumann. La situación ideal sería un sistema de memoria de gran capacidad,
gran ancho de banda, tiempo de acceso pequeño y bajo coste.
Desgraciadamente, el tiempo de acceso es inversamente proporcional a la capa-
cidad y el ancho de banda está limitado por las conexiones del procesador con
el exterior así como por la organización de la memoria, mientras que el coste
limita todos los factores.
En la práctica hay una diferencia considerable entre la velocidad del proce-
sador y la de la memoria. Esta tendencia no hace más que crecer con el tiempo,
ya que los avances tecnológicos son más rápidos en los procesadores que en la
memoria. Para resolver este problema se dispone de una organización jerárqui-
ca de la memoria. La memoria está formada por diferentes niveles. Los niveles
que están más cerca del procesador, con respecto a la interconexión, son muy
rápidos de acceder pero de medida limitada ya que son muy costosos. En cada
nivel posterior –o más alejado del procesador– se tiene más capacidad pero tam-
bién se tarda más en acceder al contenido. La idea es que la información que se
utilice a menudo se guarde en los niveles más rápidos, sabiendo que en el peor
de los casos siempre se podrá encontrar cualquier información en el último

nivel de la jerarquía.
Dentro de la jerarquía de memoria, el nivel más rápido de acceso son los regis-
tros, que forman parte de la unidad de proceso dentro del procesador. El nivel
siguiente se llama antememoria (memoria caché) y debemos tener en cuenta que
puede haber más de uno en función del rendimiento/coste con que se diseñe un
computador. Los siguientes niveles de la jerarquía están formados por elementos
de almacenaje de tipo memoria RAM y almacenaje magnético u óptico (que
incluye el disco duro, las unidades de CD y DVD, etc.).
Memoria RAM y disco duro: dos niveles dentro

de la jerarquía de la memoria de un computador
3.3. Subsistema de entrada/salida
El subsistema de entrada/salida (E/S) sirve para comunicar el computador con el

exterior, es decir, con los dispositivos de E/S, también llamados periféricos.
Los dispositivos de E/S se pueden clasificar en dispositivos de entrada de

información, de salida de información, o bien, dispositivos que permiten la
bidireccionalidad. Ejemplos típicos de dispositivos de entrada son el teclado, el
ratón y el escáner, entre otros. Por otra parte, la pantalla y la impresora son los
dos periféricos de salida más representativos. Los dispositivos que actúan como
entrada y salida al mismo tiempo corresponden a puertos de comunicación con
otros sistemas computadores. También se engloban dentro de esta posibilidad
los dispositivos que almacenan la información como los discos duros.
Los periféricos son básicos para interaccionar

con los sistemas informáticos
Formando parte de este subsistema dentro del computador encontramos los

controladores o drivers de los dispositivos de E/S. Estos controladores ofrecen
una interfaz de control uniforme y simple de los dispositivos de E/S por parte
del procesador. Si el procesador tuviera que tratar cada uno de los posibles
modelos existentes en el mercado de los dispositivos de E/S, la programación se
haría muy compleja y poco flexible ante los cambios de estos dispositivos. Para
resolver este inconveniente, el procesador controla los periféricos a través de
unos registros ubicados dentro del controlador de cada periférico. Estos registros
sirven para conocer la disponibilidad de la transmisión de información (el dis-
positivo, como es más lento, podría no estar preparado todavía), para indicar
que se haga la transferencia y para guardar o recibir el dato que se transfiere.
3.4. Buses
Los diferentes elementos del computador se tienen que comunicar entre sí para
pasarse información. Los buses son los caminos de comunicación entre estos ele-
mentos. Cada bus está constituido por varias líneas, cada una de éstas permite
transmitir una señal binaria.
Un computador puede tener diferentes tipos de buses que proporcionan

comunicación entre sus componentes. Cuando esta comunicación es entre sus
tres componentes principales –procesador, memoria y entrada/salida–, se llama
bus del sistema.5
Dentro de un mismo bus podemos clasificar a la vez las líneas según la fun-
cionalidad que tengan asignadas. Así, están las líneas que permiten transferir
datos entre los componentes (bus de datos), las líneas que designan el lugar en
que se tiene que leer o escribir el dato dentro de la memoria o el registro de los
controladores de E/S (bus de direcciones), y las líneas que se utilizan para coor-
dinar el dato y la dirección en cada transferencia (bus de control). El número de
líneas del bus de datos y de direcciones suele coincidir en los computadores
actuales. Hoy por hoy la medida más extendida es la de 32 bits y empiezan a apa-
recer las arquitecturas de 64 bits que se convertirán en estándar en un futuro
bien próximo.
El parámetro más importante que debemos tener en cuenta cuando estudia-
mos un bus del computador es el ancho de banda. Se refiere a la velocidad máxi-
ma con que se pueden transferir datos por el bus. Normalmente, se mide este
ancho de banda por el número de bits o de bytes por segundo, independiente-
mente de cual sea la medida del bus de datos.
5. PCI ha sido y sigue siendo un estándar de bus en los computadores personales. Es un bus paralelo
(hasta 32 bits de datos) de conexión de dispositivos de E/S en la placa base del computador, con velo-
cidades de hasta 133 MB/s.
Más recientes, USB y Firewire son dos buses serie (los datos se transmiten bit a bit) que conectan dispo-
sitivos al computador y que comparten prestaciones similares, con velocidades pico de 480 Mbit/s y
800 Mbit/s, respectivamente, en las versiones actuales.
4. El sistema binario
La información que gestiona el computador son por una parte las instruccio-
nes, que indican la operación que se tiene que llevar a cabo, y por otra parte los
datos, con los que se tienen que hacer estas operaciones. Para que el computa-
dor pueda reconocer esta información se tiene que representar en un sistema
capaz de ser interpretado electrónicamente.
El fundamento físico de los computadores electrónicos es la capacidad de deter-

minar si hay o no tensión de alimentación en una línea o, en otras palabras, si cir-
cula corriente eléctrica. El sistema que se adapta perfectamente es el sistema bina-
rio, en el que se utilizan únicamente dos dígitos (bits): 0 y 1. El 0 significa que no
hay tensión, mientras que el 1 significa que sí que la hay. Por lo tanto, interna-
mente, dentro del computador, toda la información estará representada median-
te el sistema binario.
Sin embargo, para las personas es muy dificultoso trabajar con este sistema.
Hay que tener en cuenta que, actualmente, la medida habitual de los datos es de
32 bits y la tendencia es ir hacia arquitecturas de 64 bits cada vez más extendi-
das. Si tenemos que definir o interpretar los datos en binario, nos podemos equi-
vocar fácilmente si tenemos que escribir 32 (o 64) bits. Por eso, en nuestra arit-
mética cotidiana utilizamos el sistema decimal, que es el que solemos utilizar
para escribir los números. En informática también es usual escribir los números
en el sistema hexadecimal, en el que cada 4 bits se corresponden a 1 dígito hexa-
decimal, lo cual permite reducir el número de dígitos con que representamos los
datos y, de esta manera, podemos minimizar los errores de transcripción.
Hay diferentes tipos de datos en los programas: números naturales, números
enteros, números reales, vectores, matrices, etc. Hay que tener en cuenta que en
la memoria únicamente almacenaremos el valor del dato en el formato de repre-
sentación que se defina por convenio para cada tipo de dato. Eso implica que la
simple inspección del contenido de la memoria no nos da ninguna información
sobre el tipo de dato que hay almacenado.
Al igual que para los datos, un programa contiene instrucciones en lengua-
je máquina que el procesador es capaz de interpretar, escritas utilizando los bits
0 y 1. Las instrucciones contienen una serie de campos, como el código de ope-
ración y la especificación de dónde se encuentran los operandos. La descodifi-
cación de la instrucción determina qué tipo de datos se corresponden con los
operandos. Como podéis imaginar, programar utilizando el lenguaje máquina

de unos y ceros es muy pesado para las personas. Por eso los programadores
utilizan una representación textual del programa en que se utilizan unos códi-
gos mnemotécnicos para indicar el código de operación y los operandos. Los
programas escritos de esta manera utilizan el llamado lenguaje de ensambla-
dor. Debe existir un proceso de traducción de los programas escritos en lengua-
je de ensamblador a lenguaje máquina antes de poder almacenarlos en la
memoria del computador para ser ejecutado.
En la tabla siguiente se dan algunos ejemplos de datos e instrucciones tal
como se definen en un programa hecho con lenguaje de ensamblador y tal
como se representan en el computador (suponiendo que disponemos de 16 bits
de medida para los datos y las instrucciones).
Lenguaje de Lenguaje máquina Significado

ensamblador
a: .word 10 0000000000001010 Declaración o creación de la variable de nombre a, que se

(binario) inicializa al valor entero 10. Los enteros se representan en
el formato denominado complemento a 2.
000A (hexadecimal)
b: .word -2 1111111111111110 Declaración de la variable b, inicializada al valor entero -

(binario) 2.
FFFE (hexadecimal)
ADD R3, R1, R2 0101001100010010 Instrucción que suma el contenido de los registros R1 y R2
(binario) y deja el resultado en R3. El formato de la instrucción
determina que los primeros 4 bits son el código de opera-
5312 (hexadecimal) ción, que los operandos son registros y que cada registro se
especifica en 4 bits.
ADDI R1, R1, #1 0111000100010001 Instrucción que incrementa el contenido del registro R1. El
(binario) formato de esta instrucción determina que hay un registro
fuente especificado en 4 bits, un registro destino<A[desti-
7111 (hexadecimal) nación|destino]>, también de 4 bits, y un dato constante
también de 4 bits que se guarda en la misma instrucción
en los bits de más a la derecha.
A modo de ejemplo también os mostramos un pequeño programa escrito en

lenguaje de ensamblador que muestra por pantalla los números cuadrados
desde el 12 hasta el 102.
LOADI R1, #0
bucle: INC R1
SUBI R2, R1, #10
BG final
MUL R2, R1, R1
OUT R2
BR bucle
final: .end
Cualquier componente dentro del hardware de los computadores se realiza

mediante unos dispositivos electrónicos básicos que se llaman puertas lógicas.
Hay cuatro operaciones lógicas básicas: NOT, OR, AND y XOR. No es el objeti-
vo de este capítulo definir el hardware de la unidad de proceso y de la unidad
de control de un procesador. En cualquier caso, podemos intuir que el número
de puertas lógicas es elevadísimo y diseñar todo el hardware únicamente a este
nivel es impracticable. Para diseñar un computador se diseñan circuitos lógicos
a partir de las puertas lógicas que llevan a cabo tareas comunes y que pueden
después ser reutilizados en el diseño global. De esta manera, a partir de compo-
nentes más sencillos se van diseñando componentes más complejos hasta lle-
gar al diseño final de todo el procesador.
Haremos una última referencia a la capacidad de almacenaje de los compu-
tadores, la memoria. Las puertas lógicas por sí solas no permiten guardar infor-
mación. Si cambia el valor de la señal en la entrada de la puerta cambia auto-
máticamente el valor de la salida. Hay un componente electrónico, el biestable,
que permite guardar 1 bit de información y que es el punto de partida de los
registros y de la memoria RAM, elementos que conforman la capacidad de alma-
cenaje de los computadores.
5. Historia
Los computadores, tal como los hemos descrito aquí, son el resultado de una
evolución tecnológica de la que, llegados a este punto, querríamos hacer una
pequeña aproximación histórica.
Desde hace mucho tiempo se ha querido acelerar la capacidad y la corrección
del procesamiento. Tenemos que tener en cuenta que las matemáticas constitu-
yen una base necesaria para el conjunto de la sociedad. El hecho de poder

sumar, restar, multiplicar o dividir está presente en la vida cotidiana.
La primera referencia histórica que tenemos en este aspecto es el ábaco, de
procedencia china y con indicios que pueden fechar su realización desde el siglo
XI a. C.
Sin embargo se considera que es en el siglo XVII cuando se inicia la construc-
ción de los primeros computadores mecánicos. El científico francés Blaise Pascal
diseñó y fabricó una calculadora que permitía sumar y restar de forma total-
mente mecánica.
Habrá que esperar un par de siglos más hasta que Charles Babbage diseñe la
llamada máquina analítica. La importancia que ha tenido esta máquina radica
en el hecho de que su estructura mecánica ya coincidía con la que tienen actual-
mente los computadores: disponía de un molino capaz de calcular, de un alma-
cén para guardar información, de una sección de entrada de datos y de otra de
salida de datos.
Diseño de la máquina analítica de Babbage
Aunque hay otros intentos que seguramente también merecerían ser desta-
cados, para simplificar podemos señalar el paso del computador mecánico al
computador electrónico como el siguiente hito notable en esta historia. La cre-
ación de las válvulas de vacío marca el inicio de la primera generación de los
computadores actuales.
El primer computador que contiene ya elementos electromecánicos es el

MARK1, diseñado en 1944 en la Universidad de Harvard. El equipo era impre-
sionante, medía 16 metros de longitud por 2,5 metros de altura, contenía
800.000 piezas y más de 800 kilómetros de cableado y pesaba 5 toneladas. Hacía
sumas de hasta 23 dígitos en medio segundo, multiplicaciones en 3 segundos y
operaciones logarítmicas en poco más de un minuto. Todo un sueño hecho rea-
lidad.
MARK1: El primer computador electromecánico
El estímulo para construir los primeros computadores electrónicos fue la

Segunda Guerra Mundial. En aquella época se necesitaban máquinas que fueran
capaces de descifrar mensajes en clave de los enemigos, así como calcular hasta
dónde podrían llegar las piezas de artillería. El ENIAC (Electronic Numerical
Integrator And Computer), que se empezó a construir en 1943 y se acabó en 1946
en la Universidad de Pensilvania, ya se considera un computador totalmente
electrónico. Pesaba 30 toneladas, ocupaba un espacio de 450 m2, contenía
18.000 válvulas y consumía una gran cantidad de electricidad. La programación
se hacía manualmente a través de 3 tableros con más de 6.000 interruptores. Los
datos se representaban en decimal. Introducir un programa era muy costoso y
se podían necesitar días o semanas. Como curiosidad tristemente célebre, hay

que añadir que uno de los primeros programas que funcionaron en el ENIAC
estaba relacionado con el diseño de la bomba de hidrógeno.
El siguiente paso fue el EDVAC en 1947, diseñado por J. P. Eckert y J. W.
Mauchly a los que, posteriormente, se añadió John von Neumann. Esta máqui-
na constituye el primer computador que incorpora el concepto de almacenaje
de la información. Tanto los datos como los programas se representaban en
binario. La posibilidad de poder guardar los programas dio flexibilidad a los
computadores, que podrían ser utilizados para ejecutar diferentes aplicaciones
cargando el programa adecuado en cada caso. De hecho, los computadores
actuales siguen la misma arquitectura iniciada con este computador, si bien, evi-
dentemente, con muchas optimizaciones y mejoras. Por este motivo utilizamos
la denominación de arquitectura Von Neumann para referirnos a la forma en
que está organizado internamiento un computador actual.
Para acabar esta pequeña introducción a la evolución histórica haremos un
breve repaso de los acontecimientos que marcan el inicio de las cuatro genera-
ciones de computadores hasta llegar a la actualidad. La primera (1946-1955),
mencionada anteriormente, está integrada por los computadores basados en la
válvula de vacío y que se programan en lenguaje máquina o en lenguaje de
ensamblador. La segunda generación (1955-1965) se inicia con la invención del
transistor y se caracteriza por la disminución del espacio físico del hardware y
la utilización de lenguajes de programación de alto nivel. La tercera generación
(1965-1980) se basa en la integración de los circuitos electrónicos mediante el
uso de los materiales semiconductores y la posibilidad de procesar información
en tiempo compartido, es decir, de ejecutar diferentes programas de manera
concurrente. La cuarta generación (desde 1980) integra todo el procesador en
un solo chip y se caracteriza por el desarrollo de las primeras redes de computa-
dores.6
6. Si tenéis interés en conocer un poco más a fondo estos aspectos de la historia de los computado-
res, podéis consultar la página web http://www.thocp.net. Encontraréis un montón de anécdotas
que complementarán vuestros conocimientos.
6. Salidas profesionales
Los sistemas informáticos están presentes en todos los sectores de la activi-

dad económica y, por lo tanto, hay muchos campos laborales que los requieren.
Las salidas profesionales en el campo del software se abordan en el capítulo
sobre programación de esta misma obra. Hay que destacar que la tarea de pro-
gramador se tiene que entender tanto en el indiscutible contexto del desarrollo
de aplicaciones (web, distribuidas), como en el contexto del desarrollo de soft-
ware de sistemas (sistemas operativos, controladores de dispositivos...) o de apli-
caciones de uso transversal (paquetes ofimáticos, navegadores, gestores de
correo...). En este sentido la implantación de soluciones basadas en software
libre ha hecho realidad la demanda laboral en estos contextos tradicionalmen-
te reservados a grandes corporaciones y a otros entornos geográficos.
Con respecto al hardware, cada vez hay más empresas instaladas en nuestro
territorio dedicadas a la investigación en nuevas tecnologías que permiten des-
arrollar arquitecturas más potentes y con menos consumo. Las salidas como
investigador en laboratorios de investigación han pasado de ser una utopía a una
realidad hoy día. También en el campo del hardware encontramos a los técnicos
en integración de sistemas, con tareas de diseño del sistema de una organización,
incluidas la configuración y la instalación de los sistemas operativos y de las
redes necesarias.
© Editorial UOC 71 Redes de comunicaciones
Capítulo III
Redes de comunicaciones
Joan Arnedo Moreno
1. Introducció
En los últimos años, las tecnologías de redes de comunicaciones han adqui-

rido gran importancia en nuestro entorno. Su alcance va desde los millones de
usuarios domésticos que acceden a Internet simplemente para actividades rela-
cionadas con el ocio (foros, chats, correo electrónico, música o vídeo bajo
demanda, compras vía web, etc.) hasta los usuarios corporativos que necesitan
compartir información vital para el funcionamiento de la empresa desde dife-
rentes ubicaciones geográficas. El caso es que hoy día ya no es posible hacerse
la idea de volver a un mundo en el que no se puedan utilizar las redes de comu-
nicaciones.
Precisamente, uno de los éxitos de esta área es su capacidad de haber atrave-
sado la frontera del usuario especializado en tecnología y haber llegado en algu-
nos puntos a ser parte del conocimiento de toda la sociedad. Internet es la pala-
bra mágica que ya todo el mundo conoce, aunque sólo sea por el nombre. Pero
más allá de Internet, no puede olvidarse nunca que las redes de comunicacio-
nes también incluyen otros fenómenos que han visto una enorme expansión en
los últimos años, como la telefonía móvil o sistemas no tan obvios pero tam-
bién de gran importancia, como los de posicionamiento global (GPS, Global
Positioning System).
A medida que se hace más necesario ser capaz de aprovechar las tecnologías
de red, también crece la demanda de profesionales con capacidad de poder dise-
ñar y desarrollar soluciones dentro de este ámbito. Con el incremento de la ubi-
cuidad de las redes, cada vez más sistemas dependen de este tipo de tecnología
para su funcionamiento. Eso hace indispensable que cualquier ingeniero infor-
mático, dentro de su formación generalista, disponga de unos conocimientos
básicos sobre redes de comunicaciones. Éstos le serán de gran utilidad aunque

no tenga que convertirse en especialista en la materia.
Este capítulo presenta los aspectos básicos necesarios para conocer en qué
consisten las redes de comunicaciones y qué caminos puede seguir quien quie-
ra convertirse en un profesional en la materia.
2. Una visión general de las redes de comunicaciones
Este capítulo resume los aspectos más básicos de las redes de comunicacio-
nes, de manera que el lector pueda disponer de un mínimo de contexto en la
materia. Para empezar, una definición de red de comunicaciones podría ser la
siguiente:
“Conjunto de enlaces de comunicaciones dispuestos de manera que es posi-
ble el envío de mensajes mediante su paso a través de muchos de aquéllos, con
el fin de comunicar a un emisor y un receptor”.
Hay que observar que dentro de la definición de red de comunicaciones no
se especifica qué hay en el extremo de los enlaces. Eso dependerá del tipo de red:
ordenadores, teléfonos fijos o móviles, etc. Lo cual se debe al hecho de que el
concepto de red de comunicaciones en realidad se remonta al siglo XIX, con
inventos como el telégrafo o el teléfono. En contraposición, la aparición de los
primeros ordenadores programables es bastante posterior, un siglo más tarde.
Aun así, es precisamente la aparición de los ordenadores lo que conforma el
punto de partida de la explosión de las redes de comunicaciones. Aparece el
fenómeno de la convergencia digital: la fusión gradual entre las tecnologías de
comunicaciones y los ordenadores de manera que se genera un nuevo entorno
en el que es posible intercambiar información entre diferentes tipos de disposi-
tivos. Una vez cualquier dispositivo basado en procesador adquiere la capacidad
de comunicarse con otros, las posibilidades se multiplican.
Llegado al punto en que dos partes, como pueden ser dos ordenadores, se tie-
nen que comunicar entre sí de manera autónoma, se hace imprescindible un
protocolo de comunicaciones.
Un protocolo de comunicaciones es el conjunto de normas que definen el
formato y el orden de los mensajes intercambiados entre dos o más entidades
que se comunican entre sí, así como el conjunto de acciones que se toman
durante la transmisión y la recepción de estos mensajes.
En realidad, siempre que dos entidades se quieren comunicar entre sí tienen
que establecer un protocolo. Una analogía muy sencilla de esta definición es la
comunicación que podrían tener dos personas con walkie-talkies. A fin de que
la comunicación sea fluida hay que seguir dos normas: cuando se quiere ceder
el turno de palabra se dice la palabra “cambio” y cuando se quiere cerrar la con-
versación se dice “cambio y cierro”. Eso en sí es un protocolo de comunicacio-
nes, aunque muy sencillo.
Con el fin de categorizar las redes de comunicaciones, hay diferentes siste-
mas: por el área de alcance, por el tipo de conexión, por la manera como se
interconectan los diferentes dispositivos, por el tipo de servicios provistos, etc.
Como hilo inicial conductor, se utilizará la división por área de alcance:
• Red de área personal (PAN, Personal Area Network).
• Red de área local (LAN, Local Area Network).
• Red de área metropolitana (MAN, Metropolitan Area Network).
• Red de área extensa (WAN, Wide Area Network).
En concreto, este capítulo dará especial importancia a las LAN y las WAN.
En primer lugar, se hará hincapié en qué aspectos han cambiado en el
mundo en que vivimos debido al impacto de las redes de comunicaciones y se
dará una visión general sobre cómo funciona Internet. A continuación, se verá
con más detalle cuáles son las piezas fundamentales para que funcione, concre-
tamente mediante las LAN y las WAN cableadas. Finalmente, se mostrará lo que,
hasta ahora, ha sido el último paso dentro de la revolución de las redes de
comunicación: las redes sin hilos.
3. Las redes y nuestro entorno
Las redes han modificado profundamente el día a día de todas las personas,
hasta el punto de que han ido más allá de los aspectos puramente técnicos y
han provocado cambios sociales. Hemos llegado a la generación que siempre
está conectada con el resto de su entorno. A continuación veremos algunos de

los puntos más evidentes de esta revolución.
La telefonía móvil: Si hay un fenómeno que ha experimentado una expan-
sión gigantesca en nuestro entorno ha sido el de la telefonía móvil.
Actualmente, en España, ya hay más teléfonos móviles que fijos. Una rueda pin-
chada en el coche ya no es un problema cuando tenemos la posibilidad de
comunicarnos con cualquier lugar en cualquier momento.
Mensajería y redes sociales: El tópico de que estar delante del ordenador
implica menos relaciones personales ha pasado a la historia. Otro avance alcan-
zado con las redes de comunicaciones es la opción de poder estar siempre
conectados con las personas con quienes queremos mantener contacto, o cono-
cer a gente nueva con gustos afines. En los primeros pasos de las redes de comu-
nicaciones se puede encontrar el correo electrónico, que en la actualidad ya se
ha convertido en una pieza más dentro de cualquier proceso de una empresa y
con tanta vigencia como un número de teléfono. Actualmente, todo eso ha sido
superado y hay fenómenos como la mensajería instantánea (incluso con voz e
imagen). Todo permite crear círculos de relaciones que pueden ir más allá de
nuestro alcance más inmediato.
Distribución de contenidos: Toda la industria basada en el control de la dis-
tribución de contenidos despertó de golpe de su sueño plácido con la aparición
de Napster en junio de 1999. Mediante este programa, cualquier persona con
conexión a Internet podía intercambiar música con otros usuarios.
Evidentemente, los lobbies de la industria discográfica no tardaron mucho en
prohibir el uso por vía legal, pero la idea ya estaba sobre la mesa y nada lo ha
podido detener. Las cosas no volverán a ser iguales.
Napster, el inicio de una nueva era en Internet

Internet ha cambiado totalmente nuestra manera de actuar y amenaza con

enviar a la obsolescencia a todos los negocios de distribución de contenidos
basados en modelos tradicionales. Las distribuidoras ya no pueden restringir
artificialmente el acceso a la información, ya que ahora cualquier persona
tiene la posibilidad de reproducir y distribuir contenidos como libros, música
o películas por un coste ínfimo. Todo lo que se puede representar en bits es
susceptible de ser distribuido por Internet. Aquellos que se empeñen en igno-
rar este hecho y sigan soñando con volver atrás en el tiempo están condena-
dos al fracaso.
Cálculo distribuido: La posibilidad de interconectar miles (o millones) de
equipos da paso a la opción de poder ejecutar programas que requieren gran
potencia de cálculo de manera distribuida. Cuando se tiene que resolver un
problema, se dividen los cálculos en partes más pequeñas, que se reparten
entre diferentes ordenadores. Uno de los precursores de esta posibilidad fue el
proyecto SETI@Home, que daba la opción a todo el que lo deseara de instalar-
se un programa que procesaba señales recibidas del espacio en el momento en
que el ahorro de pantalla estaba en marcha.
4. La red de redes: Internet
El hecho de que la Unión Soviética tomara la iniciativa en la carrera espa-

cial desembocó en la creación en los Estados Unidos de la Advanced Research
Projects Agency (ARPA) en 1958, con el objetivo de recuperar la supremacía
tecnológica. Con el fin de proveer este departamento de una red de comuni-
caciones, en 1969 nació ARPANET. Esta red se basaba en el principio de ser
totalmente distribuida, es decir, basada en la agregación de redes indepen-
dientes de menor envergadura. De esta manera, se intentaba que fuera sufi-
cientemente robusta ante los ataques, ya que si una o varias de las redes
menores dejaba de operar, Internet puede seguir funcionando, aunque fuera
con una capacidad reducida. Pero no se detendría completamente.
4.1. World Wide Web
Hay que hacer hincapié en que Internet y la World Wide Web no son lo
mismo. Internet se refiere a un conjunto de dispositivos interconectados, mien-
tras que la segunda es el conjunto de documentos enlazados entre sí mediante
hipervínculos. Vía Internet se accede a la World Wide Web. La participación
activa de la universidad desde el planteamiento inicial del proyecto y la poste-
rior aparición de la World Wide Web en 1990 hizo que evolucionara y fuera
ganando aceptación hasta convertirse en lo que hoy conocemos como Internet:
una red pública accesible a escala mundial que posibilita la comunicación entre
dispositivos y ofrece todo tipo de servicios.
Para poder concebir esta red de comunicaciones, sus creadores tuvieron que
tener en cuenta una serie de aspectos. Estos son generales a la hora de crear cual-
quier red:
• Aspectos físicos. Cómo se conectan físicamente los dispositivos entre sí y
cómo se envían los datos en forma de señales.
• Aspectos de protocolo. Qué formato tiene que seguir la información que se
quiere transmitir y qué hay que hacer ante errores o situaciones anómalas
durante la transmisión.
• Identificadores. Cómo identificar los dispositivos dentro de la red, con el fin
de poder distinguir el origen y el destino de un mensaje durante su trayec-
to dentro de la red. Este aspecto es idéntico a establecer una numeración
telefónica o un sistema de direcciones y códigos postales.
Otra de las propuestas iniciales de arquitectura en capas, muy ampliamente

referenciada, es la torre OSI (Open Systems Interconnection). En esta, las capas
se dividen en diferentes niveles: aplicación, presentación, sesión, transporte,
red, enlace y físico.
Dado que abordar estos aspectos directamente y de una manera global es
inviable, ya que corresponden a temáticas muy diferentes, se decidió crear un
modelo arquitectónico estructurado por niveles o capas. Cada nivel contendría
sus propios mecanismos y protocolos para gestionar cada una de estas tareas y
colaboraría con el resto de los niveles para llevar a cabo la transmisión de extre-
mo a extremo. En el caso de Internet, la propuesta de modelo planteado se bau-
tizó como pila TCP/IP.
Si bien esta explicación es un poco técnica, si nos detenemos a pensar, este
planteamiento no deja de ser el equivalente a establecer una jerarquía de res-
ponsabilidades para dividir las tareas de cualquier organización.
Supongamos que el director de una delegación de una empresa de cierta enver-
gadura quiere enviar un documento a un colega suyo de otra delegación distan-
te. Si hay una jerarquía de responsabilidades, el proceso podría ser el siguiente:
• El director crea el documento, le da un formato determinado y lo entrega
a su administrador, dándole el nombre del destinatario final. El director no
tiene que saber en qué sede está ubicado físicamente este destinatario, sólo
necesita el nombre. Una vez hecho eso, se desentiende del resto del proce-
so y da por sentado que, de alguna manera, tarde o temprano, llegará a su
destino.
• El administrador entrega el documento al responsable de logística, dán-
dole el nombre de la persona a quien va dirigido. Durante todo el pro-
ceso, su tarea será encargarse de monitorizar cuál es el estado de tráfico
del documento (si realmente ya ha llegado al destinatario o si todavía
está en camino, porque puede tardar demasiado en llegar, etc.). Si, des-
graciadamente, el documento se pierde o resulta estropeado, será el res-
ponsable de imprimir una nueva copia y volver a poner en marcha el
proceso de envío. De esta manera, el director de la oficina realmente se
puede desentender de todo.
• El responsable de logística mete el documento dentro de un sobre
correctamente empaquetado y como conoce en que sede está ubicado el
destinatario con el nombre que le han dado, escribe la dirección com-
pleta correspondiente (calle, número, ciudad, etc.). Una vez el paquete
está listo, lo entrega al mensajero motorizado.
• El mensajero coge su moto, lleva personalmente el paquete hasta la otra

sede y llega al departamento de logística de la sede de destino.
Una vez llegado a este punto, el camino haría el recorrido contrario. El

responsable de logística avisaría al administrador de que tiene un paquete
para su responsable. Éste lo iría a recoger, lo abriría, miraría que todo esté
correcto, avisaría al administrador de su origen de que todo ha llegado bien
y, por último, entregaría el documento a su director.
Volviendo al mundo de las redes, la pila TCP/IP también se divide en cua-
tro capas, que gestionan desde los aspectos de más bajo nivel, dependientes
del hardware, hasta los de más alto nivel y abstractos. Cada uno de los ele-
mentos que interactúan a la hora de transmitir datos se encargará de llevar a
cabo las tareas de alguna de estas capas.
Modelo arquitectónico TCP/IP

Aplicación
Transporte
Internet
Red
Los aspectos gestionados en cada nivel son los siguientes:

Nivel de red: Gestiona todos los aspectos vinculados a la conexión de equi-
pos y a la transmisión de los datos en forma de señal. Dado que Internet es una
red heterogénea, los aspectos concretos dependen del tipo de red de comunica-
ciones sobre la que se opera. En nuestra analogía sería el equivalente al mensa-
jero y su moto.
Nivel de Internet (o IP): Gestiona los aspectos de direccionamiento e iden-
tificación de los dispositivos que forman parte de la red y proporciona una capa
independiente del hardware real que hay por debajo de las aplicaciones. Dentro
de nuestra analogía, sería el equivalente al encargado de logística de cada ofici-
na, que es el responsable final de organizar adónde se envía realmente cada
cosa.
Normalmente, las direcciones IP se representan en notación decimal por cada

byte, separados por un punto. Así pues, un ejemplo de dirección IP podría ser:
213.73.36.242.
Nivel de transporte: En el caso de Internet, todos los equipos tienen un

identificador único llamado “dirección IP”, que se compone de 4 bytes. Este
identificador sería similar a un número de teléfono. Si no sabemos la dirección
IP del dispositivo con que nos queremos comunicar, no lo podremos hacer. El
protocolo principal de esta capa, que utiliza estos identificadores para alcanzar
la comunicación de extremo a extremo, se conoce como “protocolo IP”. Ésta es
la piedra angular de Internet.
Nivel de aplicación: Gestiona la fiabilidad de la transmisión y el control
de errores. Este nivel de fiabilidad sólo se establece de extremo a extremo, no
entre puntos intermedios. En nuestra analogía, estaría representado por el
administrador, que es la entidad que hace de nexo entre el director y el siste-
ma de logística y se responsabiliza de garantizar que el envío se hace correc-
tamente, incluso si se da el caso de que el paquete se pierde por el camino o
se estropea.
Engloba todos los aspectos relacionados con las aplicaciones que tienen
capacidad para acceder a la red. Dentro de este nivel se engloba toda una
serie de protocolos de comunicación que utilizan los diferentes tipos de
clientes y servidores que operan en Internet. Algunos ejemplos significativos
son FTP (transmisión de ficheros), HTTP (navegadores web), SMTP (envío de
correos electrónicos), etc. En nuestra analogía sería el equivalente al director
de la oficina, que sabe qué datos tiene que enviar y cuál tiene que ser el for-
mato correcto para que su interlocutor los entienda, pero que se desentiende
una vez los entrega al administrador. Los protocolos de este nivel se corres-
ponderían con diferentes formatos de documentos, con finalidades e inter-
pretaciones diferentes: contratos, órdenes de compra, avisos, etc.
¿Dónde están el director y el administrador? En un PC típico, las tareas de
la capa aplicación las llevan a cabo los programas finales; las capas TCP y IP, el
sistema operativo; y la capa física, la tarjeta de red. Mediante este modelo
arquitectónico, al igual que el director envía documentos sin tener que saber
cómo funciona todo el sistema de logística de la organización, un programa-
dor puede desarrollar aplicaciones sin tener que saber cómo se transmite real-
mente la información dentro de la red. Recíprocamente, un diseñador de redes
puede interconectar equipos con la confianza de que sus decisiones no harán
que el conjunto de aplicaciones que las utilicen deje de funcionar, de la misma
manera que el mensajero o el responsable de logística no necesitan saber qué
hay dentro del paquete para poder llevarlo a su destino. Eso permite que real-
mente Internet pueda ser una red de redes.
5. Las redes de área local
Las redes de área local (LAN) surgen ante la necesidad de conectar ordenado-
res en un área limitada, normalmente dentro de un mismo edificio. En este
apartado nos centraremos en aquellos aspectos relativos a las redes de comuni-
caciones cableadas y más adelante veremos las particularidades de las redes sin
hilos. El funcionamiento del nivel de red del modelo TCP/IP será diferente
según el tipo de LAN.
CP/M y DOSCP/M (Control Program / (for) Microcomputers) fue un sistema
operativo para ordenadores basados en procesadores Intel 8080/85 y Zilog que
apareció en 1974. Su imitador más logrado fue DOS, indudablemente catapul-
tado por su elección como sistema operativo en la plataforma IBM PC. Dado
que en los inicios de la informática los sistemas se basaban en un único orde-
nador principal al que se conectaban varias terminales, no había necesidad de
LAN. No fue hasta finales de los años setenta cuando empezaron a aparecer,
impulsadas por la popularización del ordenador personal gracias a los sistemas
operativos CP/M y DOS. El objetivo principal era poder compartir recursos
caros en aquella época, como impresoras o espacio de disco.
Desgraciadamente, la popularización de las LAN también implicó la aparición
de muchos tipos de redes locales diferentes, incompatibles entre sí.
A mediados de los años setenta, la compañía Xerox, con la ayuda de DEC e
Intel, lanzó su propuesta: la red Ethernet. Dado que era un tipo de red con com-
ponentes baratos y fáciles de instalar (en comparación con lo demás que había
en aquel momento), poco a poco fue ganando adeptos.
Para poder enviar información directamente entre dos dispositivos físicos,
hace falta un medio de transmisión.
Un “medio de transmisión” es cualquier soporte físico por el cual se puede
propagar una señal, en forma de ondas o energía.
5.1. Principios de la red Ethernet
En el caso de la red Ethernet, este medio de transmisión es el cable, por el

que se envía la información en forma de señal eléctrica. Inicialmente, el tipo
de cable utilizado era el coaxial, pero actualmente se utiliza el par trenzado de
cobre, más conocido como UTP (Unshielded Twisted Pair). Las características
de este medio lo hacen fácil de conectar y evitan buena parte de las posibles
interferencias.
Cable coaxial y par trenzado
En la red Ethernet la señal se transmite mediante el mecanismo de difusión:

el medio de transmisión es compartido, de manera que cuando un dispositivo
transmite, todas las estaciones reciben la señal eléctrica. Sólo el destinatario real
del mensaje se lo queda y el resto lo descarta. Es idéntico a un conjunto de per-
sonas que hablan en una habitación (donde el medio de transmisión sería el
aire).
Si dos dispositivos transmiten al mismo tiempo, la señal eléctrica se super-
pondrá y nadie podrá entender el mensaje que se está transmitiendo, por lo cual
hay que establecer una política de acceso al medio. Retomando el ejemplo de
un conjunto de personas en una habitación, si dos (o más) personas hablan al
mismo tiempo, nadie podrá oír bien lo que están diciendo.
En el caso de la red Ethernet, los dispositivos escuchan el medio y si captan
la señal que alguien está transmitiendo, esperan. Si, en cambio, ven que el
medio está libre, entonces inician la transmisión. Si dos dispositivos deciden
empezar a transmitir en el mismo momento, se produce lo que se llama una
colisión. En este caso, existe un mecanismo de desempate para resolver quién
será el primero que realmente transmitirá y quién esperará, basado en la direc-
ción MAC de cada dispositivo. Esta política de acceso se conoce como
CSMA/CD (Carrier Sense Multiple Access/Collission Detection). La dirección MAC
es un identificador único en el mundo de 48 bits incorporado por el fabricante
en cualquier hardware de red.
5.2. Dispositivos en la red Ethernet
Hay dos tipos de equipos que permiten interconectar dispositivos mediante

una red Ethernet, de manera que la gestión del cableado sea sencilla. En ambos
casos, los equipos se conectan por medio de un único cable a diferentes bocas
(o puertos) del equipo y generan una topología lógica de estrella. Aun así, no
hay que olvidar que a nivel físico, el medio es compartido.
Conexión mediante topología en estrella
Concentrador o hub: Se trata simplemente de un repetidor de la señal. Los

diferentes dispositivos se conectan con un cable UTP. Siempre que recibe la
señal a través de una conexión, la reenvía por el resto de los cables conectados.
Conmutador o switch: Son equipos más avanzados que en vez de repetir la
señal por todas las conexiones, son capaces de averiguar en qué conexión se
encuentra el destinatario real y sólo lo repiten por esta conexión. Este hecho
permite evitar colisiones y, por lo tanto, hacer más eficiente la transmisión.
Por sus características, siempre será deseable usar un conmutador para des-
plegar una red Ethernet. El único factor limitador es el precio, al ser un tipo de
equipo más complejo.
Actualmente, la red Ethernet se encuentra normalizada según el estándar
IEEE 802.3 y es la que se puede encontrar en prácticamente cualquier instala-
ción; se ha impuesto de manera absolutamente abrumadora frente a de todos
sus competidores dentro del campo de las LAN. Su estandarización permite que
cualquier fabricante pueda crear hardware para redes Ethernet, cosa que le ha
permitido evolucionar hasta velocidades de transmisión que ni siquiera sus cre-
adores podían imaginar.
6. Las redes de área extensa
En contraposición a las LAN, las redes de área extensa (o WAN, Wide Area
Network) son redes de comunicaciones que cubren grandes zonas geográficas.
Bajo el modelo descrito de Internet, las WAN sirven para interconectar las dife-
rentes LAN, de manera que los dispositivos de una LAN pueden comunicarse
con los de otra red a pesar de no compartir el mismo medio de transmisión.
Cuando dos dispositivos dentro de una LAN se quieren comunicar, al com-
partir un mismo medio de transmisión pueden enviarse directamente los men-
sajes en forma de señal. En el momento en que emisor y receptor no compar-
ten este medio, como están en diferentes LAN, hará falta un intermediario que
haga llegar la señal a la red donde se encuentra el receptor, de manera que lo
pueda captar. El dispositivo que se encarga de retransmitir el mensaje a otras
redes se llama direccionador (o router).
Los direccionadores de las diferentes LAN que conforman una WAN se
encuentran interconectados de manera que siempre es posible establecer algún
camino entre la red de origen y la de destino. El mensaje se va reenviando desde
un router a otro hasta llegar al que está conectado a la red de destino. Entonces,
el direccionador final ya puede transmitirlo al destinatario directamente
mediante la LAN. De esta manera es posible permitir la comunicación entre dis-
positivos físicamente separados a grandes distancias.
Reenvío de mensajes a través de direccionadores
Este dispositivo es exactamente el que instalan los operadores en casa del

abonado cuando contrata una línea de banda ancha (como, por ejemplo,
ADSL). A través de este dispositivo podemos tener conexión desde la red domés-
tica con el resto de Internet. La gestión de los mecanismos utilizados para que
los diferentes direccionadores estén interconectados entre sí es una tarea de los
operadores.
6.1. Tipos de enlace en una WAN
Hay diferentes mecanismos que pueden utilizar los operadores para estable-
cer la comunicación entre direccionadores en un enlace WAN.
Enlace punto a punto: En este sistema se dispone de una línea exclusiva de
comunicaciones que está disponible el cien por cien del tiempo y su comporta-
miento es equivalente a un cable que conectara directamente los direccionado-
res. Los operadores cobran según el ancho de banda que permite el enlace. Un
ejemplo de este mecanismo es PPP (Point-to-Point Protocol), que permite
conectar máquinas directamente, como por ejemplo mediante el puerto en
serie.
Las velocidades de transmisión se indican mediante las iniciales del número de
bits por segundo transmitidos. Así pues, tenemos kbps (kilobits per second) o Mbps
(megabits per second). Para este tipo de medida en concreto, se considera que un
kilobit son 1.000 bits (no 1.024) y un megabit son 1.000.000 bits.
Circuito conmutado: Se trata de una conexión de extremo a extremo que
tiene que ser establecida antes de su uso y que hay que cerrar correctamente de
alguna manera al acabar la transmisión. Eso implica unos ciertos retrasos. Su com-
portamiento sería equivalente al de una línea telefónica normal, en la que prime-
ro hay que marcar el número (establecimiento de conexión) y al acabar se tiene
que colgar (cierre de la conexión). Otro ejemplo de este mecanismo es la RDSI
(Red Digital de Servicios Integrados), una tecnología que permite usar la línea tele-
fónica para transmisión de datos de hasta 128 kbps. Actualmente esta tecnología
ya está desfasada en favor del ADSL, si bien se suele usar como mecanismo de
emergencia.
Conmutación de paquetes: En este tipo de conexión, las diferentes LAN
comparten los recursos del operador y pueden enviar datos sin tener que espe-
rar a establecer una conexión previa. En este sentido, la red del operador se
comporta como si fuera una LAN: un medio compartido al que están conecta-
dos directamente todos los elementos que lo usan. Este sistema permite tanto la
comunicación 1-1 como la 1-N. Un ejemplo de este sistema es la tecnología
Frame Relay, la precursora del ADSL para enviar grandes volúmenes de datos a
través de un operador.
Envío de celdas: En realidad se trata de un caso concreto de conmutación
de paquetes, optimizado para soportar transmisiones a gran velocidad (lo nor-
mal es 155 Mbps, pero puede llegar a más de 600 Mbps). Vale la pena la diferen-
ciación, ya que un ejemplo de este sistema es la tecnología ATM, que es la que
actualmente usan las líneas ADSL.
Así pues, es la unión de las LAN más los enlaces WAN entre éstas lo que posibi-
lita que dispositivos situados en ubicaciones geográficas separadas se puedan llegar
a comunicar en Internet.
7. Las redes de comunicaciones sin hilos
No siempre es posible o económicamente viable la creación de una infraes-

tructura de cableado previa: en palabras más sencillas, el hecho de tener que
agujerear las paredes o el suelo antes de implantar una red de comunicaciones.
Otro factor importante es que el entorno cableado también implica una limita-
ción de la movilidad de los extremos que hay que comunicar.
Este problema no tan sólo se plantea en el diseño inicial, sino que aparece
cada vez que se quiere ampliar la red; la única solución posible es su sobredi-
mensionamiento durante el diseño, a partir de estimaciones de crecimiento.
Aunque acertemos a la primera, puede darse el caso de que no sea sencillo hacer
llegar el cable a todas las partes en buenas condiciones (instalaciones no prepa-
radas para recibir cableado, entornos hostiles, etc.).
Teniendo en cuenta este factor limitador, era lógico pensar que la tecnología
de redes finalmente seguiría los pasos de sus predecesores, y al igual que la tele-
fonía ha pasado a ser sin hilos, también ha surgido la posibilidad de crear redes
sin hilos. En el momento en que el aire se convierte en el medio de transmisión
se establecen principalmente tres mecanismos para poder enviar la información:
Infrarrojos: Este mecanismo funciona exactamente igual que la mayoría de
los mandos a distancia de los televisores y se basa en luz no visible por el ojo
humano. Su alcance es muy corto, por lo que normalmente queda limitado a
las PAN y necesita línea de visión para funcionar.
Radiofrecuencia: Es lo que utiliza una emisora de radio AM o FM. Este sis-

tema es omnidireccional y puede atravesar la mayoría de los obstáculos. Es el
más utilizado por los diferentes dispositivos sin hilos.
Microondas: Este mecanismo direccional normalmente se usa para enlaces de
larga distancia, como los que hay entre un satélite y una estación base en la Tierra.
Recordemos que su uso para transmitir datos es bastante anterior al de calentar
comida.
De hecho, la invención del horno microondas fue posible porque, en el año
1945, Percy Spencer, que participaba en un experimento de transmisión por
radar, se dio cuenta de que una barra de cacahuete que llevaba en el bolsillo se
había fundido al pasar por delante del emisor de microondas.
Cuando se habla de redes sin hilos, podemos encontrar dos entornos clara-
mente diferenciados, con características propias: los de larga distancia y los de
corta distancia. Dentro de los entornos a larga distancia se encuentran los dife-
rentes sistemas de alcance global, como la telefonía móvil de primera, segunda
(GSM, GPRS) o tercera (UMTS) generación, o los mecanismos de posicionamien-
to global (GPS). Los entornos a corta distancia incluyen desde sistemas PAN
como Bluetooth, con un alcance de 10 metros y orientado a dispositivos de bol-
sillo, hasta sistemas LAN como WiFi, con un alcance de unos 100 metros y
orientado a la interconexión de ordenadores. A estos últimos sistemas se los
conoce normalmente como WLAN (Wireless LAN).
Las redes sin hilos pueden operar según dos mecanismos básicos de funcio-
namiento:
Modo adhoc: En este modo, cada dispositivo se puede comunicar directa-
mente con el resto, pero sólo con los que estén dentro de su zona de alcance.
Por ejemplo, intercambiar agendas entre dos teléfonos móviles vía infrarrojos.
Modo infraestructura: En este modo se instalan unos dispositivos especia-
les llamados puntos de acceso. Todos los dispositivos de la red envían la infor-
mación que quieren transmitir a los puntos de acceso, los cuales se encargan de
reenviarla al destinatario final. Los puntos de acceso también permiten ampliar
el área de captación de la red, ya que actúan como repetidores. Cuando un dis-
positivo quiere enviar datos a través de un punto de acceso, hace falta que antes
se asocie a él. Si bien esta nomenclatura se usa especialmente dentro de las LAN,
otro ejemplo de punto de acceso podría ser un repetidor de telefonía móvil.
Los puntos de acceso también permiten hacer de puente entre una red cable-
ada y una sin hilos. Lo cual capacita que una red local sin hilos se pueda con-
cebir como una prolongación de una red cableada existente. En este sentido,
permite que las redes sin hilos no sean necesariamente una tecnología sustitu-
toria de las redes cableadas, sino que se puedan utilizar para dar un valor aña-
dido a una red existente y ya en explotación.
Modos sin hilos
El punto más importante, y que nunca puede olvidarse, es que la necesi-

dad de una red sin hilos no se fundamenta en la investigación de la mejora la
velocidad de transmisión, de la fiabilidad o de la eficiencia de las comunica-
ciones, sino única y exclusivamente en la comodidad para el usuario final y
en facilitar tanto el desarrollo como el crecimiento posterior.
8. Las redes de comunicaciones y la seguridad
Si bien los problemas de seguridad siempre han existido dentro del mundo
de los ordenadores, en general debido a errores en la programación de los siste-
mas, la aparición de las redes hace todavía más patente esta problemática.
Desde el momento en que se puede acceder a un conjunto de información y
manipularla desde cualquier lugar, nos tenemos que asegurar de que sólo las
personas autorizadas lo puedan hacer.
La expansión de las redes y la creación de un mundo en que todos los siste-
mas están interconectados y dependen los unos de los otros para acceder a la
información ha multiplicado la problemática de la seguridad hasta el punto de
convertirla en una disciplina independiente, actualmente muy valorada, dentro

de la ingeniería informática. Las complicaciones a la hora de crear una red de
cierta envergadura que sea segura, junto con el hecho de que el usuario domés-
tico tenga un desconocimiento absoluto sobre esta materia, ha convertido en
un tópico decir que el concepto de “seguridad de redes” es un oxímoron.
Dentro de este escenario, un problema añadido es que, en su concepción ini-
cial, los protocolos de red no fueron diseñados pensando en la seguridad. En su
momento ya suponía bastantes dificultades conseguir otros aspectos como la efi-
ciencia o el coste de fabricación de los elementos de la red. Por eso, nos encontra-
mos con vulnerabilidad que no se debe realmente a errores reales de diseño, sino
que es inherente al mismo protocolo, y que por lo tanto no se pueden arreglar o
corregir directamente. Se tiene que aprender a convivir con este hecho y ver qué
vías tenemos al alcance para minimizar los efectos.
8.1. ¿Hacker o cracker?
Si bien actualmente la palabra hacker está totalmente establecida, se trata de

un término incorrecto. Originariamente, definía a los programadores con un
gran dominio de los sistemas informáticos. Era un término positivo. Si se quie-
re ser purista, la denominación correcta para designar a una persona que irrum-
pe en los sistemas sería cracker. Es bastante revelador que haya un montón de
películas de Hollywood en las que la seguridad de las redes tiene un papel fun-
damental. Desde Juegos de guerra (1983), en que un módem, ahora ya anticua-
do, permite acceder a un superordenador militar, hasta Firewall (2006), en que
el título ya hace referencia a un tipo de dispositivo físico de seguridad, pasando
por La red (1995), en la que la referencia a las redes también es obvia. Otras refe-
rencias dentro de películas o series, sin entrar en su calidad, las podemos encon-
trar en Superman 3 (1985), Los fisgones (1992), Ghost in the Shell (1995) Goldeneye
(1995), Hackers (1995), Independence Day (1996), The Matrix (1999), Takedown
(2000), Operación Swordfish (2001), Battle Programmer Shirase (2003) o The Net 2.0
(2006), entre otras. Sin duda la figura del hacker, como el que irrumpe en siste-
mas ajenos, está plenamente presente en los medios de comunicación de masas.
Por todos estos motivos es por lo que cualquier profesional que trabaje en el
campo de las redes también tiene que ser consciente de esta problemática, ya que,
desgraciadamente, formará parte de su día a día. En este apartado veremos unas
pinceladas de los conceptos básicos de seguridad que hay que tener en cuenta.
8.2. Principales problemas
Cada una de las capas del modelo TCP/IP se encuentra sujeta a la posibilidad
de una serie de ataques de los que hay que ser consciente. Los enumeramos a
continuación.
Nivel físico: Nada impide “pinchar” el cable para poder hacer una escucha
(igual que una escucha telefónica). Además, dado que la red Ethernet se basa en
un mecanismo de difusión para transmitir la señal, todos los equipos conectados
reciben los mensajes que se envían por la red. Todo el mundo lo ignora, menos el
destinatario real. Pero si un equipo decide recopilar todos los mensajes en vez de
descartarlos, es posible leer la información que envían todos los equipos de la red.
Nivel de Internet y transporte: La comunicación entre equipos se basa en
el envío de mensajes entre éstos. Inicialmente, nada impide que un equipo fal-
sifique mensajes y se haga pasar por otro, o que responda mensajes de los que
no era el destinatario. Únicamente hay que saber el identificador (la dirección
IP) de las partes que se están comunicando. Comoquiera que Internet se basa en
el hecho de que un mensaje irá dando múltiples saltos por diferentes dispositi-
vos de red antes de llegar al destinatario final, nada impide tampoco que un dis-
positivo intermedio intercepte o modifique el contenido del mensaje.
Nivel de aplicación: Cada tipo de aplicación tiene diferente vulnerabilidad
según la implementación del protocolo de capa de la aplicación que usa.
Normalmente, este hecho puede dar lugar al acceso a datos que se suponían
seguros o a la ejecución de programas no autorizados en el equipo del
cliente/servidor.
Por lo tanto, cualquier persona que esté familiarizada con el funcionamien-
to de cada nivel del modelo arquitectónico y conozca la vulnerabilidad, podrá
intentar realizar un ataque en la red. Aparte de la vulnerabilidad propia de los
protocolos y de los dispositivos que conforman una red de comunicaciones,
otro problema inevitable es la utilización de la propia red para maximizar la
difusión de programas con metas malévolas: virus (programas con la capacidad
de autopropagarse) y troyanos (programas que aparentan hacer algo diferente
de lo que realmente hacen).
Otras problemáticas ya entran en el ámbito social, pero utilizan las redes
para alcanzar su meta, como por ejemplo el correo basura (spam).
El hecho más importante es que estas problemáticas no se deben a errores en
el diseño o a una mala implementación de los protocolos de comunicaciones,
sino que son inherentes al hecho de poder disponer de la capacidad de enviar
información a cualquier lugar del mundo de manera trivial. En realidad, son

problemas sociales, no tecnológicos.
8.3. Servicios y mecanismos de seguridad
Siempre que se desarrolla un sistema, hay que decidir qué se considera

necesario lograr dentro de la materia de seguridad de la red de manera formal:
qué servicios de seguridad se quieren implantar. Dentro de una red, los posi-
bles servicios de seguridad que se pueden implantar son los siguientes:
Autenticidad: Garantizar la identidad de las partes implicadas en un inter-
cambio de datos.
Privacidad: Garantizar que sólo las partes autorizadas podrán acceder a un
conjunto de datos, tanto en su origen/destino como durante su tráfico por la
red.
Integridad: Poder detectar si un conjunto de datos ha sido modificado,
tanto en su origen/destino como durante su tráfico por la red.
Disponibilidad: Garantizar que un sistema estará en marcha y se podrá acce-
der a él correctamente. Hay diferentes sistemas para poder implantar estos ser-
vicios, llamados mecanismos de seguridad. Algunos de estos sistemas son apli-
caciones o protocolos específicos y otros son dispositivos físicos que se pueden
conectar a una red de comunicaciones.
Mediante un cifrado de información podemos garantizar la privacidad de las
comunicaciones. Eso protege la red contra escuchas de terceras personas. Hay
versiones seguras de algunos protocolos que permiten cifrar las comunicacio-
nes, como por ejemplo IPSec, la versión segura del protocolo IP, o SSL, que opera
en el nivel de aplicación.
Los sistemas cortafuegos son un mecanismo que opera en el nivel de red y
que nos permite separar nuestra red (que consideramos de confianza) del
mundo exterior. Todos los mensajes que son enviados del exterior a nuestra red
son inspeccionados y si no cumplen un conjunto de requisitos (por ejemplo,
que provengan de ciertas direcciones IP origen) se descartan. De esta manera, se
puede denegar el acceso a dispositivos no autorizados.
Los sistemas IDS inspeccionan el tráfico que circula por la red y permiten
detectar usos anómalos o intentos de ataque. Si bien no se trata de una medida
preventiva sino de detección, hay que tener en cuenta que siempre existe la
posibilidad de que a pesar de los esfuerzos utilizados, alguien haya podido ata-
car con éxito la red. Sin embargo, otro aspecto importante es el hecho de que
nada impide que los mismos habitantes de nuestra red, en la que en principio
confiamos, sean los que hagan los ataques.
Hemos dejado para el final uno de los temas clave para lograr la seguridad de
una red. Dado que la resistencia de una cadena es igual a la del eslabón más
débil, en una red hay que tener siempre en cuenta el eslabón más débil: el usua-
rio final. Todo eso no sirve de nada si es el propio usuario quien da libre acceso
a los atacantes sin saberlo. Por ello cualquier intento de crear seguridad en una
red de comunicaciones pasará por formar y concienciar correctamente a todos
los que la usarán. Nunca puede hacerse bastante énfasis en este punto.
El quid de la cuestión es que no hay una bala de plata que permita arreglar
todos los problemas. Sólo la combinación correcta de todos los mecanismos de
seguridad existentes puede minimizar el riesgo.
8.4. Un ejemplo sencillo y actual: Wardriving
La expansión de las redes sin hilos ha propiciado la aparición de nuevas

posibilidades para los interesados en poner a prueba la seguridad. En el medio
sin hilos, todo el mundo que puede captar la señal, que se extiende más allá de
las paredes del edificio, tiene acceso a la red sin necesidad de entrar en las ins-
talaciones físicas. Exactamente igual que cualquier persona con una radio
puede sintonizar cualquier emisora, sin que nadie lo pueda evitar. Eso hace que
éste sea un ejemplo especialmente revelador sobre cómo el funcionamiento de
las redes puede hacerlas inherentemente vulnerables.
Si el punto de acceso a la red sin hilos no está convenientemente protegido,
cualquier dispositivo sin hilos puede asociarse a él y, por lo tanto, transmitir a
través de él. Wardriving se refiere a la búsqueda de puntos de acceso y al inten-
to de asociarse mientras se circula en un vehículo en movimiento. De esta
manera, se puede peinar rápidamente una zona geográfica de dimensiones con-
siderables y obtener un mapa de todas las posibles conexiones disponibles.
Fruto de todo eso, ha surgido una simbología que permite dar a conocer si
en los alrededores de una ubicación hay conexiones abiertas que pueden ser
aprovechadas. Se trata de una nueva tipología de grafito llamada walkchalking.
Como puede verse en la figura, incluso se prevé la posibilidad de publicar enla-

ces protegidos, pero dando la opción de ponerse en contacto con su propietario
legítimo.
Hay que saber que a España realquilar accesos a Internet va contra la ley.
Walkchalking
Actualmente incluso hay campeonatos de wardriving. En enero de 2005 se

celebró el primer campeonato de Cataluña, eso sí, desde una vertiente pura-
mente deportiva.
La rápida expansión de los sistemas sin hilos como mecanismo de acceso a
los servicios de banda ancha (ADSL) por parte de los operadores, que muchas
veces están configurados por defecto, sólo ha hecho que agravarlo. Unas reglas
básicas y simples que se pueden aplicar en el punto de acceso para evitar que
alguien poco experto pueda acceder a la conexión son las siguientes:
Habilitar cifrado de datos: Como los datos se transmiten por el aire, el
estándar que rige las WLAN especifica mecanismos para cifrar la información
de manera que sólo quien conozca una contraseña pueda descifrarla y asociar-
se a un punto de acceso. El primer mecanismo de cifrado que surgió fue WEP
(Wired Equivalent Privacy). Desgraciadamente, se ha demostrado que es un sis-
tema inseguro (se puede descubrir la contraseña sólo escuchando la red en
menos de 50 horas, si hay tráfico moderado). Por lo tanto, es mejor usar otros
sistemas más modernos como WPA (Wi-Fi Protected Access), si los soporta el
punto de acceso. Otra cosa importante: hay que usar una contraseña compli-
cada, especialmente una que no pueda aparecer en ningún diccionario de nin-

gún idioma. En caso contrario, se es susceptible a ataques de prueba y error
desde una lista de palabras. A este tipo de ataques se los conoce habitualmen-
te como “ataques de diccionario”.
Habilitar filtrado para MAC: Todos los dispositivos en red tienen una direc-
ción única asociada con el hardware de red: la dirección MAC (Media Access
Control). Hay que configurar el punto de acceso de manera que sólo acepte aso-
ciarse con las MAC de nuestros equipos.
Para evitar que alguien pueda acceder a la red sin hilos más allá de nuestras
paredes, siempre se puede bloquear la señal de alguna manera. Actualmente, en
los Estados Unidos se están desarrollando pinturas especiales que permiten
hacerlo, crean jaulas de Faraday.
Eso no garantiza una seguridad inexpugnable, pero sí que nos protegerá de la
mayoría de los casos. En cualquier caso, hay que tener presente que nada evitará
totalmente que terceras personas conozcan la existencia de un punto de acceso y
que, por lo tanto, puedan intentar atacarlo para acceder a la red.
Así pues, el lector que disponga de una conexión sin hilos para acceder a su
línea de banda ancha tiene que ser consciente de que quizás la está “compar-
tiendo” de manera inadvertida con alguna otra persona. Si alguna vez veis un
símbolo parecido a los que hemos mostrado aquí en una pared cercana a vues-
tro domicilio, entonces habrá llegado el momento de actuar. Desde otro punto
de vista, la situación inversa también es cierta. Puede ser interesante buscar si se
está evaluando comprar una nueva vivienda. Pero la moral de la historia es sim-
ple: en el momento en que se despliega una red de comunicaciones, la seguri-
dad es muy importante.
9. La carrera del experto en redes de comunicaciones
En este apartado veremos cuál es el camino que sigue la persona que quie-
re dedicar su carrera académica y profesional a la disciplina de las redes de
comunicaciones. Así, obtendremos una visión general de los aspectos que ten-
drá que afrontar como estudiante y, según la especialización deseada, qué
otras disciplinas pueden complementar su formación.
9.1. El estudio de las redes de comunicaciones
Como se ha visto en los apartados anteriores, el estudio de las redes englo-

ba una serie de aspectos bastante diferentes entre sí. Así pues, para tener una
visión completa de cómo funcionan las redes de comunicaciones hace falta
tener los siguientes conocimientos:
• Fundamentos físicos. Cómo transformar los datos binarios en señales y
cómo transmitir estos datos dentro de un medio de transmisión, de
manera que sea posible enviar la información de origen a su destino.
• Hardware y cableado. Cuáles son los dispositivos necesarios para el fun-
cionamiento de los diferentes tipos de redes de comunicaciones y cómo
conectarlos entre sí.
• Programación. Cómo implementar sistemas que pueden ofrecer servi-
cios en red o conectarse a ellos.
• Sistemas operativos. Cómo configurar dispositivos de red para que ope-
ren correctamente. Despliegue de clientes y servidores (correo electróni-
co, web, etc.).
Básicamente, para cada nivel del modelo arquitectónico nos encontramos

con una o varias áreas temáticas diferentes.
9.2. Perspectivas profesionales
Como se ha visto a lo largo de este capítulo, la importancia de las redes en

la vida cotidiana de las personas crece cada día más. Por eso, cada vez se nece-
sita a más profesionales en este campo o, en cualquier caso, es necesario que
los técnicos tengan unos conocimientos mínimos en este campo. Una gran
cantidad de tecnologías están convergiendo con las redes.
A principios de 2006 se publicó el primer estudio IDC, encargado por Cisco
Systems, principal fabricante mundial de equipos de red, sobre la carencia de
profesionales especializados en redes de telecomunicaciones en 39 países del
mundo. Según este estudio, se estima que en el año 2008 faltarán cerca de
medio millón de especialistas en este campo en toda Europa con las aptitudes
mínimas para poder desarrollar tareas relevantes en este sector. En el caso con-
creto de España, la desproporción puede llegar a 40.000 profesionales en el año
2008.
De hecho, actualmente el 20 por ciento de los nuevos puestos de trabajo

dentro del área de tecnología son de redes, y cada vez más trabajos relacionados
requieren conocimientos en esta materia. Ahora mismo, se trata de un mercado
emergente. En la gráfica siguiente podemos ver una evolución de la oferta y la
demanda de este tipo de profesionales en este mercado desde 1999 hasta 2004.
Diferencia entre oferta y demanda de profesionales: 1999-2004
Las empresas consideran preocupante esta falta de especialistas, dado que el

60 por ciento afirma utilizar las redes para realizar sus operaciones comerciales
y al menos el 80 por ciento admite la importancia de utilizarlas. En concreto, se
llama la atención con respecto a la falta de expertos en tres campos que se con-
sideran decisivos en los próximos años:
• La telefonía IP: el 57 por ciento de las empresas cree que será una tecnolo-
gía importante.
• La seguridad: el 70 por ciento de las empresas cree que es un tema vital.
• Las redes sin hilos, apoyadas por el 69 por ciento de las empresas encues-
tadas.
En conclusión, las redes de comunicaciones todavía se encuentran en un

momento plenamente emergente, especialmente potenciado por la aparición de
tecnologías innovadoras o de campos a los que se empieza a dar una gran impor-
tancia. Incluso los estudiantes que no quieran especializarse totalmente en redes

encontrarán gran utilidad en los conocimientos adquiridos, ya que actualmente
dentro del mundo profesional de otras disciplinas ya se considera fundamental
tener una base sólida en el campo de las redes de comunicaciones.
9.2.1. Las funciones del especialista en redes
Una vez acabados los estudios, ¿qué puede esperar el especialista en redes de
comunicaciones? Según lo que se ha podido ver, las perspectivas profesionales
a medio plazo son buenas, pero hay que diferenciar cuáles son los diferentes
papeles que puede adoptar el experto en redes de comunicaciones.
Hay que tener en cuenta que las explicaciones se centrarán en los aspectos
específicos de los conocimientos de redes de comunicaciones. Se da por senta-
do que existe todo un conjunto de otras competencias que debe tener un inge-
niero: capacidad analítica y de trabajo en equipo, saber gestionar recursos, etc.
9.2.2. Gestor de redes
La función más directa de la persona especializada en redes de comunicacio-

nes se encuentra en el diseño, la implantación y la gestión de redes. Así pues,
dentro de este papel, podemos encontrar desde un profesional que se dedica a
desarrollar redes de área local en empresas de diferente envergadura, ya sean
grandes o pequeñas, hasta la persona que trabaja directamente en un gran ope-
rador de telefonía o en empresas fabricantes de dispositivos de red de ámbito
internacional.
Cualquier empresa que necesite implantar o disponer de una red puede
incluir a un profesional con esta función dentro de su plantilla, ya sea porque
su negocio se basa directamente en la infraestructura de red o simplemente
como mecanismo de intercambio de información y eficiencia en el ámbito
logístico. Eso, hoy en día, equivale prácticamente a decir todas las empresas del
mundo: desde Telefónica, Cisco Systems o la propia UOC, para el primer caso,
hasta empresas de alimentación, consultoras o firmas de abogados o arquitectos
para el segundo. Las posibilidades son ilimitadas.
Dentro de esta función se pueden englobar diferentes niveles, desde perso-
nal técnico especializado de mantenimiento hasta jefes de área o de proyectos.
Las posibilidades de progresión de la carrera profesional dependerán del tipo de

empresa. Para cada caso, las tareas estarán focalizadas en diferentes ramas.
Un gestor de redes deberá tener, en mayor o menor medida, las siguientes
capacidades:
• Estar al día de los diferentes dispositivos que existen en la actualidad y
conocer sus características.
• Ser capaz de diseñar una infraestructura de red de comunicaciones o
ampliar una existente, escogiendo las mejores soluciones a su alcance.
• Saber cómo conectar y configurar los diferentes equipos y servicios de
comunicaciones.
9.2.3. Experto en seguridad o auditor
En primer lugar es preciso poner de manifiesto que, actualmente, cualquier

rol profesional debe tener un cierto grado de pericia en aspectos vinculados a la
seguridad. Este hecho cada vez se valora más y eventualmente se convertirá en
imprescindible dentro del mundo profesional. Aun así, también existe el papel
del auditor experto en este tema.
Las responsabilidades inherentes a este cargo son poder evaluar la seguridad
de una red y poder establecer los mecanismos necesarios para que las empresas
alcancen certificaciones de estándares internacionales de seguridad (como, por
ejemplo, ISO 17799 o ISO 27001). La adopción de estos estándares no sólo es una
medida de prestigio, sino que es obligatoria en algunos casos, como por ejemplo
en el caso de empresas estrechamente vinculadas a la Administración pública.
Normalmente, sólo las empresas de cierta envergadura o las muy especializa-
das en ofrecer servicios de telecomunicaciones, como los operadores, tienen en
plantilla personas específicamente vinculadas a la seguridad de la red. En
empresas más pequeñas, esta función se combina con la del gestor de redes. Aun
así, existe todo un conglomerado de empresas que ofrecen este tipo de servicio,
como pueden ser la mayoría de las consultoras importantes.
Un experto de seguridad tendrá que poder:
• Ser consciente de las debilidades de las redes de comunicaciones y actuali-
zar constantemente sus conocimientos sobre la nueva vulnerabilidad que
aparezca.
• Conocer los diferentes dispositivos, estándares y herramientas de seguridad
de red.
• Ser capaz de evaluar cuál es el grado de seguridad de una red y proponer

soluciones para alcanzar un nivel aceptable de seguridad.
• Desplegar servicios y mecanismos de seguridad.
9.2.4. Desarrollador de aplicaciones en red
El fenómeno que ha desembocado en la explosión de las redes ha sido la

posibilidad de acceder a servicios como la mensajería instantánea, el vídeo bajo
demanda o los entornos colaborativos. Sin estos servicios, el usuario doméstico
no tiene ninguna necesidad de conexiones de gran ancho de banda. Por lo
tanto, y muy ligado al campo del desarrollo del software, existe el papel del pro-
fesional que se dedica a crear las aplicaciones que sólo tienen sentido dentro de
un entorno en red.
Hay que tener en cuenta que esta función no engloba simplemente a los des-
arrolladores de aplicaciones que, circunstancialmente, se distribuyen por la red,
como programadores web o de juegos para teléfono móvil, sino a las personas
encargadas de crear aplicaciones que realmente son conscientes de su operación
en red y que lo deben tener totalmente en cuenta para su operación. Estamos
hablando de Napster o Bittorrent (para compartir ficheros), Skype (telefonía por
Internet) o el proyecto SETI@Home (cálculo distribuido).
Un desarrollador de aplicaciones en red deberá:
• Tener un cierto nivel con respecto a las disciplinas de programación e inge-
niería del software.
• Conocer cómo funciona el protocolo IP y los diferentes protocolos de la
capa de aplicación.
• Saber diseñar nuevos protocolos de capa de aplicación.
• Dominar los diferentes mecanismos para resolver los problemas intrínsecos
de una aplicación distribuida y las limitaciones de los diferentes entornos
de red. Precisamente éste es el factor diferencial de un experto en aplica-
ciones en red con respecto a un programador cualquiera.
9.3. El reciclaje profesional
Por último, es importante subrayar la importancia del reciclaje continuo en

un mundo en que la tecnología avanza constantemente y las cosas cambian a
un ritmo vertiginoso.
Para lograr esta meta, hay dos vías. Por una parte, la opción de los másteres
o de los posgrados vinculados a la materia que ofrecen diferentes universidades.
Por otra, también puede resultar muy interesante tener en cuenta que algunas
de las compañías más importantes en este sector ofrecen programas propios de
certificación oficial que permiten ampliar los conocimientos y la pericia en
redes de comunicaciones, o especializarse en aspectos mucho más concretos, no
tan académicos y mucho más orientados a lo que se puede encontrar en el
mundo profesional.
Aun así, la mayoría de los programas de certificación oficiales sólo implican
la realización de un examen y dejan la preparación al estudiante. De todas
maneras, hay una extensa bibliografía de apoyo para preparar estos exámenes.
Sólo a modo de ejemplo, uno de los títulos mejor valorados actualmente
por las empresas es el programa de certificaciones ofrecido por Cisco Systems:
el CCNA (Cisco Certified Networking Associate). Este programa ofrece la posibili-
dad de obtener el certificado de diferentes niveles y especializaciones según el
grado de pericia deseado. Uno de los aspectos interesantes de este programa es
que algunas de las certificaciones asociadas a él disponen de programas de for-
mación oficial.
Algunas de las certificaciones de este programa son las siguientes:
CCNA: Nivel básico-intermedio. Engloba todos los fundamentos básicos
sobre redes de comunicaciones: principios teóricos y configuración de disposi-
tivos para redes de pequeño alcance. Es el punto de entrada a todo el programa
de certificaciones.
CCNP: Nivel alto. Capacita al profesional para desarrollar redes de gran
envergadura.
CCIE: Nivel experto. Actualmente hay un número muy limitado de personas
con esta certificación, que implica el máximo nivel dentro del mundo profesio-
nal.
Especialista: Hay diferentes certificaciones de especialista en aspectos como
voz IP, comunicaciones sin hilos o seguridad.
Hay que decir, sin embargo, que una parte importante de la formación está
orientada, comprensiblemente, a la configuración de equipos de este fabricante
en concreto.
© Editorial UOC 101 Programación
Capítulo IV
Programación
Francisco Javier Noguera Otero y Daniel Riera Terrén
1. Introducción
Como ya se ha dicho anteriormente, un ordenador es una máquina capaz de

ejecutar algoritmos (programas). Esta definición une los conceptos de hardware
y software. Estos son conceptos antagónicos, pero complementarios, ya que no
tienen sentido el uno sin el otro.
La programación es la fase final –entendida como objetivo– del desarrollo del
software, que se concreta en la ingeniería del software (véase el capítulo 6). Para ase-
gurar la buena calidad de éste, antes se tienen que hacer unos buenos análisis y
diseño, y después, una buena depuración de errores y una implantación correcta,
así como un buen mantenimiento posterior. Todas estas fases se complementan y
giran en torno a la realización de un software que resuelva un problema concreto.
Antiguamente, cuando se detectaba un problema, se programaba directa-
mente la solución. Actualmente, debido a la complejidad creciente de los pro-
gramas, las necesidades referentes al funcionamiento correcto de éstos y la exi-
gencia de ciertos niveles de rendimiento, ha ido surgiendo toda una metodolo-
gía para asegurar el buen desarrollo del software.
Este texto se centra en lo que algunos autores se han atrevido a bautizar
como el arte de la programación. Para adentrarnos en este mundo, primeramen-
te, presentaremos la historia, que está directamente relacionada con la apari-
ción y la evolución de los diferentes lenguajes. Así, los lenguajes de programa-
ción que se van proponiendo tienen a menudo una relación directa con las
necesidades históricas del momento. La primera parte termina mostrando los
lenguajes que más se utilizan en la actualidad. Presentamos las razones por las
que han alcanzado su estatus actual y, por otra parte, sus debilidades. Por últi-
mo, se discuten los grandes fracasos del mundo de la programación.
Aunque no se pretende profundizar en la programación en sí misma, sí que

se introducen las bases: componentes de un programa, manera de estructurar-
los y una cata de la manera de medir su calidad. Igualmente, se presentan los
paradigmas existentes y las características propias de cada uno, así como algu-
nos conceptos del software libre y las diferencias con el software propietario.
2. ¿Qué es un programa? ¿Quién programa?
Aunque quizás no tengamos una idea clara de a qué nos referimos cuando
hablamos de programar, sin ser conscientes de ello, a lo largo de nuestras vidas
lo hacemos bastante a menudo y de maneras diversas. Así, programamos el
vídeo para que se active a una hora determinada y grabe, programamos la hora
a la que tiene que sonar el despertador, e incluso, hacemos viajes programados.
¿Pero, realmente, tiene todo eso alguna relación con los programas de ordena-
dor?
Al contratar un viaje programado nos ofrecen la lista de los lugares adonde
iremos, qué día iremos, qué visitaremos y qué actividades realizaremos. Así, el
programa, en este caso, es una especificación detallada previa del acontecimien-
to. Aunque eso ya nos va dando ciertas pistas de lo que se considera un progra-
ma en el mundo de la informática, más cercanos aún son los otros dos ejem-
plos. Cuando programamos el despertador o el vídeo, le damos una orden –o un
conjunto de órdenes– que en un cierto momento del futuro ejecutará automá-
ticamente.
Reuniendo estas ideas, podemos acercarnos a la idea de programa, ahora ya
desde el punto de vista informático. Diremos, hoy por hoy, que un programa es
un conjunto de órdenes ordenadas que la máquina ejecutará para llevar a cabo
una tarea determinada.
Si buscamos la definición en el diccionario, vemos que es bastante parecida
a lo que acabamos de decir: “Conjunto unitario de instrucciones que permite a
un ordenador realizar diversas funciones, como el tratamiento de textos, el dise-
ño de gráficos, la resolución de problemas matemáticos, el tratamiento de ban-
cos de datos, etc.”. Así, las órdenes que damos al ordenador se llaman instruc-
ciones y la ejecución de éstas hace que el ordenador cumpla ciertos objetivos.
Un programador, por tanto, será la persona capacitada para decirle al orde-

nador qué tiene que hacer y especificarle cómo lo tiene que hacer. Así, tiene que
conocer las instrucciones que se pueden utilizar para que el ordenador las
entienda y las pueda ejecutar. Para hacerlo, como veremos más adelante, tiene
que ser capaz, primero, de escribir un algoritmo (conjunto de pasos) para solu-
cionar el problema, y después traducirlo a un programa utilizando un lenguaje
de programación. El hecho de traducir un algoritmo a un programa (que deno-
minaremos código fuente o simplemente código) se llama programar o codifi-
car.
Aunque el trabajo de la programación, hoy día, es bastante cómodo –vistas
las facilidades que ofrecen las herramientas de apoyo–, es interesante ver cómo
ha ido evolucionando hasta llegar al punto donde nos encontramos.
3. Historia
A finales de 1976, los tripulantes de un flamante caza F16 de las fuerzas aére-
as de los Estados Unidos vieron sorprendidos que, en determinados momentos,
el avión giraba 180 grados y quedaba cabeza abajo. Después de analizar cuál
podía ser el problema, detectaron que provenía de un signo menos mal coloca-
do dentro del programa de navegación del aparato. Este error hacía que el apa-
rato girara cada vez que cruzaba el ecuador. Menos mal que estas primeras prue-
bas las hicieron sobre simulador, ya que si no el susto, sin duda, hubiera sido
mucho mayor.
Es curioso que un programa de algunos miles de líneas (y por lo tanto, de
varios millones de caracteres) pueda depender de un solo signo, pero la progra-
mación no es un ejercicio simple y cualquier programa, por sencillo que sea, es
susceptible de tener errores. Precisamente para evitar los errores y facilitar la
programación, los lenguajes y los paradigmas de programación han ido evolu-
cionando continuamente. Veamos, pues, cómo ha sido esta evolución.
Las diferencias entre los primeros programas y lenguajes, llamados de prime-
ra generación, y los que se utilizan actualmente es muy grande, no sólo por el
cambio de tipos de problemas que hay que resolver sino por las estrategias
seguidas para la simplificación, el diseño, la división en subproblemas, etc.
Los lenguajes de programación evolucionan buscando la simplificación de la

tarea de programar y la reducción de la probabilidad de cometer errores.
3.1. La primera programadora
Charles Babbage (1719-1871) es considerado uno de los padres de la infor-

mática por su diseño de la “máquina analítica”. Ada Lovelace (1815--1852), hija
de Anabella y Lord Byron, es reconocida por los historiadores como la primera
persona que hizo un programa para ordenador. Fue su madre, Anabella, quien
introdujo a Ada en las matemáticas, quien, tras conocer a Charles Babbage, tra-
dujo y amplió una descripción de su máquina analítica.
Ada Lovelace (1815-1852): la primera programadora
Los “números de Bernoulli” son una secuencia de números racionales con

unas ciertas propiedades complejas que los relacionan. Babbage nunca pudo
completar la construcción de ninguno de sus diseños, principalmente por la
falta de tecnología y herramientas de precisión de la época. Sin embargo, el tra-
bajo que Ada llevó a cabo con este modelo le ha hecho ganarse el título de pri-
mera programadora de computadores del mundo. El primer programa que hizo
calculaba números de Bernoulli. El nombre del lenguaje de programación “Ada”
se escogió para rendir homenaje a esta programadora.
3.2. Prehistoria de la programación
Después de los intentos y los consiguientes fracasos de Babbage para acabar

su máquina analítica, no hubo mucho interés en la construcción de ordenado-
res hasta la Segunda Guerra Mundial. Las máquinas que se construían entonces
eran gigantescas y tenían decenas de miles de válvulas de vacío. La programa-
ción se hacía construyendo cableados particulares para controlar las funciones
básicas del aparato. De hecho, se desconocían, propiamente dichos, los lengua-
jes de programación y la programación en sí. Hoy día, cuando un programa
tiene un error, se dice que tiene un “bug” (en castellano, bicho). Aunque nor-
malmente se relaciona este término con el hecho de que los antiguos ordena-
dores fallaban algunas veces porque los bichos quedaban atrapados en los
relays, parece que el concepto es anterior. Thomas Edison (1847-1931) ya habla
de bugs en sus diseños, refiriéndose a errores o dificultades.
Personas cargando programas en el ordenador UNIVAC 120
La forma de trabajar era la siguiente: el “programador" pedía tanda para uti-

lizar la máquina durante un cierto intervalo de tiempo. Cuando le tocaba, iba a
la habitación donde estaba el ordenador, insertaba su tablero de conexiones y
empezaba a rezar para que ninguna de las válvulas de vacío se fundiera duran-
te la ejecución. Evidentemente, si había algún error, no se tenía ninguna pista
de dónde se había equivocado.
A finales de los cincuenta aparecieron las primeras tarjetas perforadas, que

significaron una mejora importante a la hora de “leer” los programas. Cada tar-
jeta contenía una instrucción y era importante que el bloque de tarjetas no se
cayera porque después volver a ordenarlas podía significar una odisea. El orde-
nador era capaz de ir leyendo los agujeros mecánicamente y así traducirlos a
instrucciones.
Tarjeta perforada en blanco (Imagen bajo licencia GFDL)
3.3. El primer programa en la memoria
Hasta aquel momento, para ejecutar un programa entero, lo que se hacía era
ir cargando una tarjeta por instrucción. Así, hasta que no se había acabado la
ejecución de la actual, no se retiraba y se introducía la siguiente.
Las siglas ENIAC significan Electronic Numerical Integrator And Computer. Los
primero programas que se utilizaron en el ENIAC estaban relacionados con el
diseño de la bomba de hidrógeno. Los aclamados como primeros ordenadores,
como por ejemplo el ENIAC, no tenían algunas de las características que hoy
día se consideran indispensables en un ordenador. Eran máquinas bastante rígi-
das. En cambio, en la Universidad de Manchester, se crearon una serie de
máquinas que incluían tanto la posibilidad de almacenar programas en la
memoria como de introducir el programa mediante un teclado en vez de recon-
figurar circuitos (tarea que podía durar días).
El tubo Williams fue desarrollado por Freddie Williams (1911-1977) y Tom

Kilburn (1921-2001). El almacenamiento de programas se consiguió gracias a la
introducción de un tipo de memoria llamado “tubo Williams”. Era un tubo de
rayos catódicos, cuyo fósforo guardaba la información y se iba refrescando para
que no se perdiera. En diciembre de 1947 ya se podían guardar 2.048 bits en un
tubo de 6 pulgadas.
Con esta memoria se construyó una máquina llamada SSEM (Small Scale
Experimental Machine), también conocida con el nombre de Baby. La informa-
ción para programar el Baby era la siguiente:
• Constaba de un par de tubos auxiliares para guardar un acumulador A1 y
otro para la instrucción actual PI (Present Instruction) y su dirección (posi-
ción) en la memoria CI (Control Instruction).
• Las instrucciones tenían reservados 12 bits para la dirección de memoria, 3
para la instrucción y había 16 sin usar (véase la imagen de abajo).
Formato de las instrucciones del Baby
• Sólo por curiosidad, a continuación podemos ver las siete instrucciones

(por eso se codifica usando 3 bits) que se podían utilizar para hacer un pro-
grama:
– 000 Hace que la instrucción actual apunte a la dirección almacenada
en S (CI=S).
– 001 Resta en el acumulador el contenido de S (A=A-S).
– 010 Carga el acumulador con el contenido de la dirección S cambian-
do de signo (A=-S).
– 011 Si A es negativo, se salta la instrucción siguiente (si A<0,CI=CI+1).
– 100 Incrementa el contador de instrucción en la cantidad almacena-
da en S (CI=CI+S).
1. Un acumulador es un sitio de la memoria del ordenador que se utiliza de manera auxiliar para
hacer operaciones intermedias aparte de la memoria principal (un tubo Williams de 32x32).
– 101 Se repite la 010 (A=-S).

– 110 Carga en la dirección S el contenido del acumulador (S=A).
– 111 Interrumpe el programa.
El primer programa fue escrito por el propio Tom Kilburn y fue ejecutado el
día 21 de junio de 1948. Este programa calculaba el factor máximo de un núme-
ro. En la imagen siguiente podemos ver el “diseño” a mano del primer progra-
ma.
Anotaciones a mano del primer programa que se hizo para el Baby
3.4. Generaciones
A lo largo de los años, se han ido clasificando los lenguajes en generaciones

según la proximidad al lenguaje natural –utilizado por los humanos– y otras
características que permiten agruparlos.
3.4.1. Primera generación: Código máquina
Los lenguajes de primera generación, también llamados lenguajes máquina,

se caracterizan por utilizar ceros (0) y unos (1) para describir los programas.
Estos, en sus inicios, eran introducidos en el ordenador mediante interruptores
del tablero frontal del aparato.
Ejemplo de línea de código máquina:
10110000 01100001 Esta línea contiene una instrucción que mueve un valor (61 en hexadecimal)
en el registro2 del procesador al. Como se puede ver, no es muy comprensi-
ble desde el punto de vista humano (de hecho, es realmente misteriosa).
La ventaja principal de este tipo de lenguajes es que utilizan instrucciones

que pueden ser ejecutadas directamente por el procesador y, por lo tanto, son
muy rápidos. Por otra parte, son mucho más complejos de aprender, utilizar y,
sobre todo, depurar para buscar errores. Aparte, también encontramos que la
portabilidad de estos lenguajes es prácticamente nula: para reutilizar un progra-
ma de un ordenador en otro hay que rescribirlo completamente ya que es posi-
ble que los procesadores acepten lenguajes máquina diferentes o incluso que
tengan arquitecturas diferentes.
La gran mayoría de los lenguajes que fueron surgiendo posteriormente, al
final y de forma transparente para el programador, acaban traduciendo de una
manera u otra el código a código máquina. Eso se hace para superar las dificul-
tades enunciadas anteriormente.
“Hello World” es un programa que presenta por pantalla el mismo mensaje.
Se utiliza en los manuales introductorios como la mayoría de los lenguajes por
su sencillez. La primera vez que se utilizó fue en el año 1974 en un memorán-
dum interno de Brian Kernighan para Bell Laboratories (“Programming in C: A
Tutorial”). Una aplicación que sólo mostrara por pantalla la frase “Hello World”
en código máquina tendría el código que se muestra a continuación. Este ejem-
plo está escrito para ensamblador de un procesador Intel x86 con DOS y utili-
zando TASM. Hay que advertir que está escrito en hexadecimal, ya que en bina-
rio ocupa cuatro veces más.
2. Un registro es una zona de memoria del procesador donde se guarda información.

4D5A2F00 02000100 20000200 FFFF0300 10000000 00000000

3E000000 0100FB71 6A720000 00000000 00000000 00000000
00000000 00000000 00000000 00000100 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 B802008E D8BA0000 B409CD21 B8004CCD
21000000 00000000 00000000 00000000 48656C6C 6F2C2077
6F726C64 210D24
Como hemos visto, comprender el código máquina es realmente complejo.

Aun así, en la película The Matrix, vemos que Cypher, Morpheus, Neo y algún
otro tripulante del Nebuchadnezzar son capaces de ver la realidad directamente
en el código (de hecho, en este caso, el código de Matrix no es binario, o hexa-
decimal, sino formado por símbolos parecidos a un alfabeto oriental). Queda
claro que son grandes programadores.
3.4.2. Segunda generación: Lenguaje ensamblador
Para evitar tener que utilizar el alfabeto de la máquina (ceros “0” y unos “1”),
que está muy lejos de lo que entendemos nosotros, se crearon los llamados len-
guajes ensamblador. Éstos cartografían directamente cada instrucción en el con-

junto de ceros y unos correspondientes. Eso se hace mediante una herramienta
llamada ensamblador (assembler).
La arquitectura de un ordenador se refiere normalmente a la estructura inter-
na del procesador. Los lenguajes ensamblador son totalmente dependientes de
la familia del procesador y de su arquitectura, igual que el código máquina (por
ejemplo, un programa hecho para Intel no sirve para AMD o Motorola, ya que
son diferentes fabricantes de procesadores).
Ejemplo de línea de código ensamblador:
mov al, 061h Esta línea contiene la instrucción mov, que mueve un byte (61 en hexadecimal) en el
registro al. Esta manera de escribir código es más comprensible que la que hemos
visto anteriormente.
Aunque claramente la introducción de los lenguajes ensamblador implicaba

una mejora importante en la legibilidad del programa, apareció una nueva
necesidad entre los programadores: poder programar pensando más en cómo
solucionar el problema desde el punto de vista humano que en el funciona-
miento interno del ordenador. De ahí surgen los conceptos de lenguajes de pro-
gramación de bajo y de alto nivel. Cuanto más de alto nivel se considera un len-
guaje, más cerca se sitúa del lenguaje natural y de la manera humana de razo-
nar.
Las principales aplicaciones de estos lenguajes son los kernels (los núcleos de
los sistemas operativos), los drivers de los dispositivos (programas que permiten
al sistema operativo comunicarse con los periféricos) y las librerías de sistemas
(introducidas más adelante, en este mismo capítulo).
El “Hello World” para lenguaje ensamblador tendría el código que se presen-
ta a continuación. Este ejemplo está escrito para ensamblador de un procesador
Intel x86 con DOS y utilizando TASM.
MODEL SMALL
IDEAL
STACK 100H
DATASEG
MSG DB ‘Hello, world!’, 13, ‘$’
CODESEG
Start:
MOV AX, @data
MOV DS, AX
MOV DX, OFFSET MSG
MOV AH, 09H ; DOS: output ASCII$ string
INT 21H
MOV AX, 4C00H
INT 21H
END Start
Es normal que, a simple vista, no se entienda, ya que estamos trabajando en

las partes y los mecanismos internos del procesador de un ordenador (por ej. los
registros). Por eso se llaman lenguajes de bajo nivel, porque se baja al nivel de
la máquina.
3.4.3. Tercera generación: Lenguajes de alto nivel
Viendo la complejidad de programar con los lenguajes que había hasta

entonces, empezaron a aparecer los lenguajes de alto nivel. Como ya hemos
comentado, éstos aportan una legibilidad mucho más próxima al lenguaje natu-
ral y ahorran al programador el tener que pensar en cada orden mínima que
tiene que ejecutar el ordenador.
Cualquier instrucción de este tipo de lenguajes equivale a unas cuantas líne-
as de código máquina o ensamblador.
Ejemplo de línea de código C:
if (x>0) factorial(x) Esta línea comprueba si x es mayor que cero (0). En caso de que así sea
llama a una parte del programa que calcula el factorial de x.
Así, a partir del código escrito en un lenguaje de este grupo, se utiliza una
herramienta (de hecho hay diferentes maneras de hacerlo) que “traduce” el
código a código máquina. Normalmente se hace mediante un compilador, aun-
que puede utilizarse un intérprete o incluso una máquina virtual (conceptos
que veremos más adelante).
La mayor parte de los lenguajes que se utilizan hoy día para la programación
de aplicaciones son de tercera generación (por ej. C, C++ y Java).
3.4.4. Cuarta generación (4GL): Lenguajes casi naturales
Son lenguajes de programación que no son de propósito general, como los

que había habido hasta ahora, sino que están diseñados para algún propósito
específico (por ej. Sculptor, Dbase, SAS, PHP, etc.).
Los lenguajes de tercera generación habían conseguido facilitar mucho la
comunicación entre el hombre y la máquina, y habían mejorado claramente el
desarrollo del software desde sus predecesores. Aun así, la tarea de programar se
seguía considerando frustrante, lenta y propensa a errores. Lo cual llevó a la pri-
mera gran crisis del software, ya que la cantidad de trabajo que se esperaba que
hicieran los programadores superaba con creces el tiempo que tenían para lle-
varla a cabo. Para solucionar el problema, se tomaron varias medidas, entre
éstas encontramos la definición de la ingeniería del software y el diseño de len-
guajes de programación según los tipos de problemas que debían resolverse.
Ejemplo de línea de código de SQL:
Esta línea busca en una base de datos todos los registros que tienen
SELECT * FROM USUARIS
como campo de nombre BOB. Se puede ver que es casi como el len-
WHERE NAME=”BOB”
guaje natural (en este caso, el inglés).
Estos lenguajes están diseñados para reducir el esfuerzo de programación, el

tiempo y el coste de desarrollo. Pero no se puede errar en la elección del lengua-
je, ya que si no el proyecto se convierte muy probablemente en un fracaso.
No hay lenguajes mejores ni peores. Lo que puede facilitar o complicar la
programación de una aplicación es la idoneidad del lenguaje elegido para codi-
ficar.
Algunos tipos de lenguajes de cuarta generación son:
• Tratamiento de bases de datos (por ej. SQL y FOCUS)
• Generadores de informes (por ej. PostScript, BuildProfessional y Gauss)
• Manipuladores y analizadores de datos (por ej. Informix-4GL,
Mathematica y SAS)
• Tratamiento de flujo de datos (por ej. APE y AVS)
• Generación y dibujo de pantallas (por ej. Oracle Forms y Unify Accell)
• Generadores de interfaces gráficas de usuario (por ej. Borland Delphi,
Visual Basic’s form editor, Windows Forms y OpenROAD)
• Desarrollo web (por ej. PHP y ASP)
3.4.5. Quinta generación (5GL): No nos ponemos de acuerdo
Diferentes fuentes definen la quinta generación de lenguajes de diversas

maneras. Entre éstas, las dos principales son:
Lenguajes para inteligencia artificial

Son aquellos basados en la resolución de problemas que utilizan restriccio-
nes para modelarlos, sin programar un algoritmo que lo haga. La mayoría son
lenguajes lógicos, basados en restricciones, y/o declarativos (por ej. Prolog,
ILOG o eCLiPse). El programador no se tiene que preocupar por CÓMO resol-
ver sino de QUÉ resolver. Se hicieron bastantes inversiones en estos lenguajes a
lo largo de los años noventa, con la idea de sustituir los lenguajes de alto nivel,
pero fue un fracaso y actualmente se utilizan sólo en círculos académicos.
hermano(X,Y):- madreOpadre(X,Z), Esta línea dice que X e Y son hermanos si comparten padre o
madreOpadre(Y,Z). madre.
En el ejemplo anterior se utiliza una regla. Los lenguajes lógicos utilizan

hechos y reglas para modelar la realidad y a partir de ésta, poder inferir las res-
puestas a posibles preguntas.
Lenguajes con GUI (Graphical User Interface)

Otros presentan los 5GL como los que utilizan una interfaz gráfica o visual
de usuario para crear un código fuente que se compila posteriormente con un
compilador de lenguajes de tercera o cuarta generación. Compañías como
Borland, Microsoft e IBM elaboran este tipo de productos de programación
visual para el desarrollo de aplicaciones en Java, por ejemplo.
4. Algorítmica
Hasta ahora hemos revisado un poco la evolución de los lenguajes hasta lle-
gar a los que utilizamos hoy día. Pero exactamente, ¿cómo son estos lenguajes?
¿Qué tipo de problemas nos permiten resolver y de qué manera? Pronto vere-
mos algunas de las características comunes a todos ellos.
La palabra “algoritmo” proviene del nombre del matemático musulmán

persa del siglo IX, Abu Abdullah Muhammad ibn Musa al-Juarismi. Pero antes
de empezar, volvamos a la definición de programa que habíamos visto. Un pro-
grama era un conjunto de órdenes que el ordenador podía entender y que resol-
vían un problema o hacían una tarea concreta. Un buen programador, antes de
escribir estas órdenes inteligibles para el ordenador (lo que llamaremos “códi-
go”), escribirá lo que se llama “algoritmo”. Los algoritmos son el resultado de
aplicar el razonamiento a un problema: los pasos que hay que seguir para resol-
ver aquella situación en concreto. Estos pasos los vamos generando y aplican-
do, sin ser conscientes, en nuestra vida diaria cada vez que tenemos que resol-
ver una situación de cualquier tipo (por ejemplo, hacer la compra, freír un
huevo, conducir, etc.).
Por lo tanto, la capacidad de pensar algoritmos la tenemos todos los seres
humanos. La cuestión, a la hora de programar, es hacer entender nuestra
solución a un ordenador. Para ser un buen programador, se tiene que ser
capaz, como veremos seguidamente, de formular un algoritmo que resuelva
el problema en un tiempo aceptable y con unas necesidades de recursos
alcanzables; y después, traducir ese algoritmo a un lenguaje que entienda el
ordenador.
4.1. Las bases
Una de las máximas más famosas de la programación es la de Niclaus Wirth:

“Algoritmos + estructuras de datos = programas”. Esta ecuación explica que los
programas se basan en una combinación de los algoritmos que pensamos para
resolver el problema y la manera como guardamos los datos. Profundicemos un
poco en esta idea.
Como ya habíamos dicho, cuando tenemos un problema que queremos
resolver con un programa, lo primero que necesitamos es un algoritmo. Esto es,
el conjunto de pasos necesarios para resolver aquel problema. Un ejemplo clá-
sico de algoritmo (debe quedar claro que no es un programa porque no se puede
resolver con un ordenador) es el de la tortilla de patatas: “Tenemos un invitado
en casa y queremos hacer una tortilla de patatas para dos personas”.
Algoritmo de la tortilla de patatas
1) Batir el contenido de 4 huevos (clara y yema) en un cuenco con la ayuda

del tenedor.
2) Mientras queden patatas:
Pelar las patatas con el cuchillo.
Cortar las patatas con el cuchillo, en trozos pequeños de no más de 2
cm.
3) Sumergir las patatas 10 minutos en aceite caliente pero que no llegue a
humear.
4) Introducir las patatas fritas en el cuenco y mezclarlas con el huevo con la
ayuda del tenedor.
5) Encender el fuego a media potencia y colocar la sartén.
6) Echar dentro de la sartén una cucharada sopera de aceite de oliva.
7) Echar en el cuenco una cucharadita rasa de sal.
8) Verter el contenido del cuenco en la sartén.
9) Esperar sin remover durante 2 minutos.
10) Si se ha pegado o se quema, bajar el fuego y despegarla.
11) Esperar sin remover durante 3 minutos.
12) Darle la vuelta a la tortilla con ayuda de un plato de diámetro mayor que
la sartén.
13) Esperar 5 minutos más.
14) Retirar la tortilla.
Acabamos de definir los pasos que hay que seguir para, a partir de unos
ingredientes y unas herramientas que tenemos en casa, llegar a hacer una torti-
lla de patatas para dos personas. Estos pasos definirán el algoritmo. Cuando
queremos resolver un problema con el ordenador, la mecánica es parecida: tene-
mos un estado inicial y queremos hacer alguna tarea. Tenemos que preparar un
algoritmo, traducirlo a un lenguaje de programación (programar) y ejecutarlo
sobre el ordenador. Así, si es correcto, el ordenador cumplirá la tarea definida
inicialmente.
Para escribir un algoritmo, sin darnos cuenta, utilizamos tres estructuras con
las que se puede resolver cualquier problema. Así, un buen programador, ante
un problema, tiene que ser capaz, inmediatamente, de ver cuáles de estas estruc-
turas combinará para resolverlo. Veamos cuáles son.
4.1.1. Estructuras
La estructura básica de ejecución de un algoritmo es la llamada “estructura

secuencial”, que se define como la aplicación consecutiva de las órdenes.
Posibles algoritmos que siguen esta estructura serían las instrucciones para
montar un mueble o una receta de cocina como la que acabamos de ver.
Pero una vez tenemos la posibilidad de solucionar el problema ejecutando
orden tras orden, nos preguntamos si nos podríamos encontrar con otra situa-
ción. La siguiente necesidad es la toma de decisiones. A veces, la secuencia de
órdenes que hay que ejecutar depende de una determinada condición que se
produce en el sistema. Por ejemplo, en la Fórmula 1, si los mecánicos tienen que
cambiar los neumáticos de un coche, no deben ejecutar los mismos pasos si
llueve o si no llueve. El hecho de que llueva o no es un dato que debe tenerse
en cuenta en este caso. Se aplica lo siguiente:
si llueve entonces preparar neumáticos_de_lluvia

si no preparar neumáticos_de_seco
Así, estamos condicionando la ejecución de una acción u otra según el esta-

do del sistema. En este caso hemos utilizado una “estructura condicional”.
En el algoritmo de la tortilla de patatas, vemos una estructura condicional en
el paso 10, en el que la ejecución de una acción depende de si la tortilla se ha
pegado o se quema.
Por último, nos encontramos con una última estructura, que se aplica cuan-
do una acción o un conjunto de acciones se tienen que ejecutar múltiples veces.
Ésta se llama “estructura iterativa”. Un ejemplo claro es lo que hace un profe-
sor cuando tiene que corregir exámenes:
para cada examen hacer

corregir examen
En este caso, la orden “corregir examen” se repetirá tantas veces como exá-
menes tenga el profesor. Si tiene treinta estudiantes, estas dos líneas equivalen
a escribir treinta veces la orden “corregir examen”.
En el algoritmo de la tortilla de patatas, vemos una estructura iterativa en el
paso 2, ya que se van repitiendo dos acciones, mientras quedan patatas.
Cualquier algoritmo se puede escribir utilizando una combinación de tres

estructuras: secuencial, condicional e iterativa.
4.1.2. Datos
Hasta ahora hemos visto que para resolver un problema se tiene que pensar
un algoritmo y –en el caso de que se tenga que ejecutar en un ordenador–, pos-
teriormente, traducirlo a un lenguaje de programación. Ahora bien, recordando
lo que nos decía Wirth, los programas no son simplemente algoritmos, sino una
combinación de éstos con estructuras de datos. Pero ¿qué son los datos?
Consideramos que el estado está definido por la situación de los elementos
con los que trabaja el algoritmo en un instante concreto. Ya hemos dicho que
un algoritmo (o un programa) nos lleva de un estado inicial a un estado final.
Así, antes de aplicar el algoritmo de la tortilla de patatas, el estado es: estamos
en la cocina de casa, tenemos huevos, aceite, patatas, etc. En cambio, una vez
hemos aplicado el algoritmo, tenemos una tortilla, y algunas cosas que tirar a la
basura. Es fácil ver que cada paso del algoritmo que vamos ejecutando produce
un cambio de estado.
Cuando programamos, estos estados se tienen que guardar de alguna mane-
ra, ya que cada paso del algoritmo tiene sentido si se aplica sobre un/os cierto/s
elemento/s, y en un cierto estado. Un ejemplo claro es, por ejemplo, el segun-
do paso del algoritmo de la tortilla de patatas: pelar las patatas. Esto sólo tiene
sentido si las patatas todavía no están peladas. En este caso, consideramos que
tenemos un dato (patata) que está en un estado (pelada). Otros posibles estados
para el dato “patata” serían “sin pelar”, “cortada”, etc.
Estos datos, cuando hablamos de programas, quedan guardados en la memo-
ria del ordenador y determinan el estado de ejecución del programa en cada ins-
tante.
Recordemos así lo que decía Wirth: “Algoritmos + Estructuras de datos =
Programas”. Efectivamente, cualquier programa contendrá un conjunto de ins-
trucciones ordenadas (un algoritmo) y un conjunto de datos sobre los cuales se
aplican las instrucciones.
4.1.3. Organización de los programas (divide and conquer)
Centrándonos en la programación de ordenadores con las estructuras que

hemos visto (secuencial, condicional e iterativa), como ya hemos subrayado,
puede escribirse cualquier algoritmo. En los ejemplos que hemos escrito, no lo
hemos tenido en cuenta, pero normalmente, un programa hecho por una
empresa, por ejemplo, se extenderá miles o incluso millones de líneas. Eso hace
que haya que poner un poco de orden en los programas. Así, por cuestión de
legibilidad y de reutilización, se tiene que evitar escribir los algoritmos en un
solo bloque. Por eso intentaremos de una manera u otra unir instrucciones que
hagan una subtarea de lo que al final queremos hacer.
Estos trozos de código se llaman funciones, procedimientos, objetos, etc.,
según el tipo de lenguaje con el que se programa y la organización del bloque.
Efectivamente, por una parte, cuando estamos escribiendo un programa, es
posible que haya partes del código que se tengan que repetir a lo largo del algo-
ritmo. En vez de repetirlas, se escriben dando a su conjunto un nombre que se
podrá utilizar desde cualquier parte del programa. Por ejemplo, si tengo el blo-
que siguiente, que llamaré “cambia_neumático”:
cambia_neumático:
quita neumático_gastado
pon neumático_nuevo
comprueba neumático
fin cambia_neumático
ahora puedo utilizar el bloque a lo largo del algoritmo sin volver a escribir
cada orden:
para cada neumático

hacer cambia_neumático
De esta manera, vemos que será más legible el código, ya que queda claro
qué hace sin tener que leer todas las líneas. Si ya sé que uno de estos bloques
funciona correctamente, no hace falta que lo revise si después mi programa
tiene errores. Eso facilita también la fase de búsqueda de errores, dado que es
más fácil ir aislando los errores que se produzcan.
Así, y volviendo al ejemplo de la tortilla, una vez tenemos el algoritmo para

hacerla, si queremos hacer un algoritmo para hacer una cena completa, pode-
mos poner el de la tortilla de patatas en un módulo y llamarlo desde la cena
para no tener que escribirlo todo otra vez.
4.2. Conceptos avanzados
4.2.1. Complejidad algorítmica
Cuando se escribe un algoritmo para resolver un problema, una de las exi-

gencias es que sea capaz de acabar algún día. Considerando, pues, que todos los
algoritmos aceptables son finitos, nos encontramos con un nuevo objetivo un
poco más ambicioso: conseguir diseñar el mejor algoritmo posible para un pro-
blema dado.
Para conseguirlo, lo primero que hace falta es una manera de medir esta
“cualidad”. Así, en el mundo de la programación se consideran típicamente dos
variables que hay que medir para determinarla: el tiempo y el espacio. El prime-
ro da una idea del tiempo necesario para resolver el problema aplicando aquel
algoritmo y el segundo mide los recursos (normalmente, la cantidad de memo-
ria) necesarios para guardar los datos del problema.
Con respecto a la complejidad temporal, la idea es que los problemas se pue-
dan resolver en el mínimo tiempo posible con respecto a los datos de entrada.
Así, por ejemplo, si tenemos que ordenar unas tarjetas de visita siguiendo el
orden alfabético, consideramos que los datos de entrada son las tarjetas. El
número de movimientos que tenemos que hacer para ordenar n tarjetas nos
dará la complejidad del algoritmo.
Fijémonos en el comportamiento (temporal) de algunos algoritmos según la
diferente cantidad de tarjetas que hay que ordenar:
Complejidad n=10 n=100 n=1000 n=10000 n=105 n=106
lg n 3.32 6.64 9.96 13.28 16.6 19.93
n 10 100 1000 10000 105 106
50·n 500 5000 50000 5·105 5·106 50·106
n2 100 10000 106 108 1010 1012
n3 1000 106 109 1012 1015 1018

Cada línea de la tabla anterior presenta los resultados para un algoritmo dife-
rente. Si nos fijamos, por ejemplo, en la última línea, vemos que dado este algo-
ritmo, si se tienen que ordenar 10 tarjetas (n=10), hay que hacer 1.000 movi-
mientos para conseguirlo.
De esta manera, los tres primeros (con complejidades lg n, n y 50·n) se con-
sideran algoritmos aceptables para solucionar el problema. Los otros no son lo
bastante eficientes.
El Clay Mathematics Institute ofrece un millón de dólares a las personas que
resuelvan una serie de problemas matemáticos altamente complejos. Uno de
ellos es ¿P=NP?. El último que se solucionó fue la demostración del último
Teorema de Fermat.
Yendo un poco más allá, también se clasifican los problemas según la exis-
tencia o no (hasta ahora) de algoritmos que los resuelvan en tiempo polinomial
(problemas P) o no (problemas NP). Así, un problema P es el que tiene un algo-
ritmo conocido con complejidad polinómica que lo resuelve. Una de las gran-
des incógnitas a que actualmente se enfrenta la comunidad científica es, como
hemos comentado, si todos los problemas son P. Eso se resume normalmente
con la pregunta ¿P=NP?.
4.2.2. Recursividad
Este es un recurso que se utiliza a veces a la hora de programar para sustituir

una estructura iterativa. La recursividad consiste en la definición de una fun-
ción sobre ella misma. Para verlo más claro ponemos un ejemplo de ello:
El factorial de un número n se define matemáticamente como n!=n·(n-
1)!=n·(n-1)...2·1. Por ejemplo, el factorial de 6 es
6!=6·5!=6·5·4!=...=6·5·4·3·2·1=720. Queremos calcular el factorial de un número
N. Una solución recursiva sería definir la función siguiente:
factorial calcula_factorial (N):

si N és 0 factorial = 1
sinó factorial = N x calcula_factorial (N-1)
retorna factorial
fi calcula_factorial
Esta función recibe un número N y devuelve su factorial. Para hacerlo, defi-

ne el factorial de N como N multiplicado por el factorial de N-1. Eso determina
la recursividad, pero se tiene que tener en cuenta que ésta tiene que acabar (si
no el algoritmo no sería finito). Para hacerlo se añade una condición final (en
este caso, cuando N es 0).
5. Traducción de código fuente a código máquina
Los lenguajes de programación nos facilitan la comunicación con los orde-

nadores, ya que nos ahorran tener que saber escribir código máquina. Éste es
muy complejo y tiene más en cuenta la estructura y la arquitectura del ordena-
dor que el tipo de problema que se tiene que resolver.
Por eso hay herramientas que traducen los lenguajes de programación que
nosotros conocemos a este código máquina. Hay diferentes estrategias para
hacerlo, que describiremos a continuación.
5.1. La compilación
La compilación es el proceso mediante el cual el código fuente, legible por

los humanos, se transforma en código máquina, legible por los ordenadores. El
resultado de la compilación puede ser o bien un programa ejecutable o bien una
biblioteca.
Una biblioteca es un conjunto de bloques de código (como ya hemos visto
antes) que se utiliza para construir software. Las bibliotecas se utilizan normal-
mente para evitar repetir escribir una y otra vez lo mismo. Así si, por ejemplo,
compramos un robot y lo queremos programar, es común que el fabricante del
robot nos provea también de una biblioteca que contenga las funciones para
comunicarnos con él. Igualmente, para programar aplicaciones de comunica-
ción en red, hay bibliotecas de funciones que nos facilitan mucho esta tarea.
Cada tipo de ordenador puede leer y entender un código máquina diferente.
Por ello hay compiladores diferentes para cada arquitectura (por ej. x86, Sparc,
PPC, etc.).
Así, la compilación se puede entender como la traducción automática de un
texto de un idioma a otro, a fin de que alguien lo pueda entender.
En una reunión de los protagonistas de la película Hackers, hablan de sus

biblias de programación, seguridad, etc. Entre éstas, mencionan el “Libro del
dragón” (Dragon Book en inglés), que es un libro de programación de compila-
dores muy utilizado en las facultades de informática de todo el mundo. El
Dragon Book se llama así porque su portada muestra a un caballero y un dragón
en una batalla. Hay dos versiones (A. Aho, 1977 y 1986), una primera con el dra-
gón de color verde (Green Dragon Book o Old Dragon Book) y la segunda (Red
Dragon Book o New Dragon Book). La contraportada muestra de manera humo-
rística la lucha de Don Quijote contra los molinos.
Si bien la versión de 1977 está un poco desfasada, todavía se puede utilizar
para temas prácticos. Incluye el tratamiento de todas las fases de la compilación
con bastante detalle algorítmico para que un estudiante pueda construir un
pequeño compilador en un solo curso.
5.2. La interpretación
Un intérprete es un programa que puede ejecutar directamente el código

fuente sin necesidad de transformaciones. El código fuente no se transforma
sino que se ejecuta línea a línea, por lo que el proceso de interpretación debe
repetirse cada vez que se quiere ejecutar el programa.
La ejecución de un programa interpretado es siempre más lenta que la ejecu-
ción del mismo programa en código máquina, pero nos proporciona otras ven-
tajas, como son la sencillez de programación o la facilidad para detectar errores.
Si la compilación era una especie de traducción automática de un texto, la
interpretación está más próxima a la interpretación que se haría en las Naciones
Unidas de una charla de un jefe de Estado. Se hace en tiempo real. No se gene-
ra ningún documento.
5.3. Código intermedio
Para poder conseguir una independencia de arquitectura, hay lenguajes de

programación que combinan el proceso de compilación y de interpretación. El
código fuente se transforma, mediante la compilación, en un código interme-
dio parecido al código máquina pero más sencillo. Este código intermedio tiene
que ser interpretado por cada arquitectura diferente.
Como todas las arquitecturas interpretan el mismo código intermedio, los

programas pueden escribirse, compilarse y ejecutarse en plataformas diferentes,
sin los problemas de incompatibilidad que normalmente se derivan del tipo de
arquitectura o sistema operativo.
Por otra parte, algunos lenguajes de programación generan, como resultado
de la compilación, código fuente escrito en otro lenguaje. Este código resultan-
te tiene que ser compilado nuevamente con el compilador adecuado.
Esta técnica permite desarrollar nuevos lenguajes de programación sin tener
que programar previamente complicados intérpretes o compiladores, ya que se
utilizan herramientas existentes.
Como se ha dicho, esta técnica combina las anteriores. Buscando otra vez un
símil, se puede entender como una lengua franca intermedia de la que hay
muchos intérpretes en cualquier lengua. Pero hay que realizar un paso anterior:
pasar de la lengua inicial a esta lengua intermedia, lo cual se hace generando
una traducción automática.
6. Paradigmas de programación
Un paradigma de programación es un estilo de programación que provee y

determina la visión que el programador tiene de la ejecución del programa. Hay
lenguajes que soportan un paradigma y otros que soportan múltiples paradig-
mas.
Mientras que el “paradigma de programación” se relaciona con programa-
ción, la “metodología de programación” se relaciona con la aplicación de inge-
niería del software.
6.1. Programación desestructurada o spaghetti
Uno de los lenguajes desestructurados por antonomasia es el BASIC, princi-

palmente por su instrucción GOTO, que da un salto incondicional de una parte
del programa a otra. El código del programa se presenta en una serie de instruc-
ciones, una detrás de otra, en un único bloque, sin estructura. Este tipo de pro-
gramación, utilizada con los primeros lenguajes, hace que el programa sea difí-
cil de entender, corregir o modificar para añadir una nueva funcionalidad. Otro
problema es la dificultad que tiene el programador en reaprovechar el código.
Algunos ejemplos de este tipo de lenguajes son: BASIC, FORTRAN y algunos
lenguajes de scripting.
Los paradigmas que veremos a partir de ahora se consideran estructurados, ya
que la programación desestructurada plantea algunos problemas.
6.2. Programación procedimental (o imperativa)
El código del programa está dividido en diferentes bloques llamados funcio-

nes o procedimientos. Cada uno de estos bloques se encarga de realizar una tarea
específica y puede ser llamado varias veces desde otros puntos del programa.
Este tipo de programación permite ver un programa como la ejecución de
una serie de tareas complicadas, lo cual disminuye la complejidad de la progra-
mación. Está claramente basado en la idea de divide and conquer.
Algunos ejemplos de este tipo de lenguajes son: Ada, C, Delphi y Pascal.
6.3. Programación orientada a objetos
Un programa está formado por un conjunto de objetos independientes que

interactúan entre ellos. Cada objeto contiene su propio código y sus datos, tiene
la capacidad de recibir peticiones (mensajes de otros objetos) para hacer alguna
tarea, procesar datos y enviar peticiones (mensajes) a otros objetos.
El resultado es un programa mucho más sencillo y fácil de modificar. Esta
sencillez y el hecho de que los objetos se puedan reaprovechar para diferentes
aplicaciones han hecho que este sea el paradigma más utilizado en la actualidad
para la programación de aplicaciones.
Algunos ejemplos de este tipo de lenguajes son: Smalltalk, PHP, C++ y Java.
6.4. Programación orientada a aspectos
El programa se divide según la funcionalidad que se quiere proporcionar,

intentando que cada parte sea lo más independiente posible del resto. Se utili-
zan módulos llamados “aspectos” para codificar la funcionalidad compartida

entre módulos y “puntos de unión” para definir cuándo se tiene que ejecutar
un aspecto determinado.
El objetivo es poder cambiar el comportamiento del programa haciendo los
mínimos cambios posibles.
El ejemplo más claro de este tipo de lenguaje es AspectJ.
6.5. Otros paradigmas
Hasta aquí tenemos los paradigmas de programación más utilizados, pero

hay muchos otros que se podrían comentar. Entre ellos, destacamos los siguien-
tes:
6.5.1. Programación funcional
La programación funcional concibe la computación como una evaluación de

funciones matemáticas y evita utilizar datos que vayan cambiando de valor a lo
largo de la ejecución del programa. Por lo tanto, no definirá los cambios de esta-
do a lo largo de la ejecución del programa.
Algunos ejemplos de este tipo de lenguajes son: Erlang, R, APL, Lisp y ML.
6.5.2. Programación lógica
Los programas implementados siguiendo este paradigma suelen definir

hechos, que son considerados ciertos siempre, y reglas, que no explican cómo
se tiene que solucionar un problema, sino qué relaciones hay entre las entida-
des que se modelan.
El ejemplo más claro de este tipo de lenguaje es Prolog.
7. Lenguajes de programación
Como ya hemos visto, en los inicios de la informática, los programas se escri-

bían directamente en código máquina y requerían un conocimiento profundo
del ordenador. Un científico que quisiera resolver un problema matemático ayu-
dándose del ordenador tenía entonces dos problemas más: cómo generar un
algoritmo que resolviera el problema y cómo traducir ese algoritmo a código
máquina.
El hardware es la parte física de un ordenador: el procesador, la memoria, los
dispositivos, etc. Pero ¿se podría crear un lenguaje que permitiera leer y modi-
ficar los programas fácilmente sin preocuparse del hardware? Veamos si eso se
ha conseguido, analizando los lenguajes más importantes históricamente y en
la actualidad.
Uno de los primeros lenguajes conocidos y utilizados en todo el mundo fue
FORTRAN. Posteriormente se crearon COBOL y LISP. Estos tres han sido los
padres de los lenguajes de programación y han servido de base para el desarro-
llo de muchos otros.
Yahoo! Store, la primera versión de la tienda virtual de Yahoo! fue programa-
da en LISP, un lenguaje que normalmente no se utiliza para este tipo de desarro-
llo pero que redujo el tiempo de programación. Lejos de quedar en el olvido,
hoy día se utilizan versiones revisadas de estos primeros lenguajes de programa-
ción. FORTRAN se utiliza en aplicaciones científicas y de cálculo numérico. El
software de bancos y cajas está principalmente escrito en COBOL, ya que des-
pués de años de programación han conseguido unas bibliotecas libres de error
(error free). LISP todavía se utiliza en el ámbito de la inteligencia artificial y en
muchas otras aplicaciones comerciales.
En la imagen siguiente podemos ver una línea temporal que representa la
aparición de los lenguajes de programación más importantes hasta la actuali-
dad.
Línea de tiempo de los lenguajes de programación más importantes
7.1. Los lenguajes más utilizados
Hay un índice, llamado TIBOE-PCI (Programming Community Index), que pre-

senta los lenguajes de programación más utilizados o populares. Esta “popula-
ridad” se basa en los cursos de programación que se ofrecen, en los requisitos
que se piden en las ofertas de trabajo, en los productos que se venden, etc. La
recopilación de estos datos se hace mensualmente utilizando los buscadores de
Internet más conocidos (véase la imagen siguiente).
Índice TIBOE, enero 2010
7.1.1. BASIC
En los primeros años en que se utilizó, las líneas del programa tenían que
estar numeradas. Esta numeración normalmente se hacía de diez en diez (10,
20, 30, etc.) dejando así un espacio entre instrucción e instrucción por si se tení-
an que añadir líneas posteriormente. El lenguaje de programación BASIC
(Beginner’s All-purpose Symbolic Instruction Code) fue diseñado e implementado
en el Dartmouth College (EE.UU.) para facilitar a los estudiantes de letras el
acceso al ordenador. Por extensión, cualquier persona sin conocimientos cien-
tíficos podía utilizar un sencillo juego de instrucciones para escribir un progra-
ma.
El BASIC se hizo popular a partir de la aparición de los ordenadores domés-
ticos que, a diferencia de los grandes computadores que había en las universi-
dades y en las industrias, disponían de muy poca memoria y espacio de disco.
Requería menos recursos para ejecutarse que el resto de los lenguajes de la
época, lo que lo hacía ideal para este tipo de ordenadores. Esta necesidad míni-
ma de recursos y el hecho de que fuera sencillo de aprender hizo que la mayo-
ría de los ordenadores domésticos llevaran incorporado un intérprete de BASIC.
Precisamente fue en esta época y gracias a BASIC, cuando se fundó la com-
pañía Microsoft. Bill Gates y sus socios desarrollaron un intérprete de BASIC
para el primer ordenador doméstico, el Altaif 8800. En 1975 pusieron en venta
Altair BASIC y posteriormente desarrollaron nuevas versiones de Microsoft
Basic para otras plataformas (Apple, IBM, etc.). Treinta años después es la mayor
compañía de software del mundo.
El código del “Hello World” en BASIC es el siguiente:
10 PRINT “Hello World!”
7.1.2. C
Los lenguajes anteriores a la aparición de C eran ampliamente utilizados para

resolver problemas, pero no ofrecían un buen rendimiento ni eran aptos para la
creación de un sistema operativo. Los sistemas operativos estaban programados
en código ensamblador, lo cual implicaba que había que desarrollar uno especí-
fico para cada arquitectura.
Se dice que el lenguaje C fue creado por el equipo de desarrollo de UNIX para
poder jugar al juego Space Travel. Este juego estaba programado en ensamblador
(como el sistema operativo), hecho que obligaba al equipo a volver a codificar-
lo nuevamente cuando querían jugar en otro tipo de ordenador. En vez de eso
crearon un nuevo lenguaje (llamado C) a partir de uno ya existente llamado B.
El nuevo lenguaje era bastante flexible para permitir combinar las programacio-
nes en bajo y alto nivel. Mediante un compilador específico para cada arquitec-
tura (que traducía de C al ensamblador de la máquina) podían obtener progra-
mas ejecutables para diferentes ordenadores sin tener que cambiar el código
fuente. En el año 1973 el código de UNIX se rescribió utilizando C. De esta
manera, fue el primer sistema operativo no escrito en ensamblador. Eso aceleró
y simplificó la programación para este sistema, lo cual se tradujo en un impor-
tante avance en el desarrollo.
El hecho de que, a pesar de ser propiamente un lenguaje de alto nivel, ofrez-
ca la posibilidad de codificar también en bajo nivel para poder acceder a todos
los recursos del ordenador, hace que C sea un lenguaje peligroso para princi-
piantes. Aun así, su potencia lo ha convertido en uno de los más utilizados.
La sintaxis de C se muy permisiva. Tanto es así que incluso hay concursos de
“programación ofuscada”, es decir, concursos en que se valora que el código
fuente no pueda leerse o incluso que forme bonitos dibujos de caracteres (véase
un ejemplo en el anexo 2 de este capítulo).
El código del “Hello World” en C es el siguiente:
#include <stdio.h>
int main (void)
{
printf ("Hello world!\n");
return 0;
}
7.1.3. C++
Como se explica más adelante, la orientación a objetos es un paradigma de

programación en el que el programa se divide en objetos que interactúan entre
sí. Once años después de la aparición de C, Bjarne Stroustrup modificó el len-
guaje más popular de la época para incluir la orientación a objetos, y creó así el
C++ (C más más). En su página personal, Stroustrup explica que el nombre de
C++ se debe a que es una evolución de C, pero sin que los cambios sean tan
importantes como para llamarlo D.
Como ya hemos visto, la programación procedimental es una metodología
de programación en la que el programa se divide en funciones o procedimien-
tos que se encargan de resolver partes de los problemas. Aunque C++ ofrece la
posibilidad de programar utilizando el paradigma orientado a objetos, no supri-
me la posibilidad de utilizar las antiguas características de C, lo cual permite el

reaprovechamiento de recursos escritos en C y la combinación de los paradig-
mas “orientación a objetos” y “programación procedimental”, hecho que ha
generado bastantes críticas.
También ha recibido críticas por ofrecer una excesiva complejidad. Incluso
en Internet hay una entrevista ficticia a Stroustrup en la que dice: “Se suponía
que todo era una broma. Nunca pensé que la gente se tomaría mi libro en serio.
Cualquiera con dos dedos de frente puede ver que la programación orientada a
objetos no es intuitiva, además de ilógica e ineficiente”. Insistimos: es una
entrevista que nunca se produjo, o por lo menos eso es lo que defiende el pre-
sunto autor.
El código del “Hello World” en C++ es el siguiente:
#include <iostream>
using namespace std;
class HelloWorld
{
public: HelloWorld () {}
~HelloWorld () {}
void sayHello { cout << "Hello World!" << endl;}
};
int main (void)
{
HelloWorld hw;
hw.sayHello();
return 0;
}
7.1.4. Java
JAVA fue desarrollado por Sun Microsystems en los años noventa. En argot
norteamericano JAVA quiere decir “café” y la historia cuenta que el equipo que
desarrollaba este lenguaje escogió este nombre en torno a una taza de café. Por
eso, su logotipo es una taza de café y los objetos que utiliza para encapsular
información (agrupar en bloques) se llaman “Java Beans” (granos de café). Aún
podemos encontrar otra referencia al café en su código, ya que si abrimos cual-
quier clase compilada de JAVA con un editor hexadecimal, veremos que todas
las clases empiezan con los cuatro primeros bytes hexadecimales CA FE BA BE.
JAVA es un lenguaje orientado a objetos que ofrece, en la misma base del len-
guaje, apoyo para la utilización de redes y la ejecución remota de código (fue
creado durante el boom de Internet). Sintácticamente, JAVA es muy parecido a
C y C++, pero mucho más simple, ya que tiene reglas menos permisivas. Eso
implica limitar las diferentes maneras de hacer lo mismo (cosa que da lugar a
ambigüedades), no permitir ciertas estructuras que puedan generar errores, etc.
Un programa escrito con JAVA puede ejecutarse en cualquier ordenador y sis-
tema operativo sin tener que modificar ninguna línea de código y sin volver a
compilar. La idea “codifica una vez, ejecuta en cualquier lugar” junto con el
hecho de proporcionar un entorno seguro a la hora de ejecutar código han
hecho que sea uno de los lenguajes más utilizados actualmente.
La Máquina Virtual Java (Java Virtual Machine, JVM) es una capa que se
podrá poner por encima de cualquier máquina para que así pueda ejecutarse el
mismo código, independientemente de ésta. Por eso, al compilar, se genera
código intermedio, interpretable por la JVM. Las mayores críticas a JAVA provie-
nen de su velocidad de ejecución y la cantidad de memoria que utiliza para la
ejecución. Es un lenguaje que se compila y genera un código intermedio que
después tiene que ser interpretado por la Máquina Virtual Java. Por eso, la eje-
cución de los programas de las primeras versiones de JAVA era mucho más lenta
que la de otros similares hechos en C o C++. Actualmente la diferencia ya no es
tan grande.
El código del “Hello World” en JAVA es el siguiente:
public class HelloWorld {

public static void main (String args[])
{
System.out.println ("Hello World");
}
}
7.1.5. PHP
Lenguajes de scripting son lenguajes normalmente creados para facilitar el

proceso de editar, compilar y ejecutar programas. PHP es un lenguaje creado
para ser utilizado en un servidor web. Se utiliza principalmente para escribir
páginas HTML dinámicas (la página se genera personalizada para cada usuario
que se conecta y después se envía) a partir de información de una base de datos,

aunque también puede ser utilizado desde la línea de órdenes principalmente
como lenguaje de scripting. Hay que añadir que también soporta el paradigma
de orientación a objetos.
Uno de sus puntos fuertes es la comunidad OpenSource, que lo utiliza y lo
hace evolucionar. Esta comunidad de usuarios proporciona multitud de bibliote-
cas que los programadores de PHP pueden utilizar libremente en sus programas.
PHP es uno de los miembros principales del LAMP (Linux Apache MySQL y
PHP). LAMP es el nombre con que se conoce un entorno de trabajo para la web
en el que el sistema operativo es GNU/Linux, el servidor de páginas web es
Apache, la base de datos, MySQL, y el lenguaje de programación, PHP.
Actualmente, muchos desarrollos orientados a Internet (blogs, wikis, tiendas en
línea, páginas de noticias, etc.) utilizan este tipo de plataforma.
El código del “Hello World” en PHP es el siguiente:
<?php echo "Hello World!" ?>
8. Software libre
La idea del software libre surgió a partir de un problema que tuvo Richard
Stallman con una impresora. El software que la controlaba no se podía modifi-
car y él quería mejorarlo para evitar unos problemas que se le planteaban. Así
el concepto “software libre” nace en 1984 cuando Stallman inicia el proyecto
GNU y crea la Free software Foundation (FSF). Este proyecto tiene por objetivo
crear un sistema operativo totalmente libre. Antes de esta fecha también había
muchas aplicaciones que se distribuían con el código fuente o de forma gratui-
ta, pero no es hasta ese momento cuando se crean unas normas y emerge la
conciencia identitaria y de pertenencia. GNU es una palabra que se define recur-
sivamente. Quiere decir: “GNU’s Not UNIX”.
Un software se considera libre si garantiza las cuatro libertades siguientes:
• La libertad de ejecutar el programa para cualquier propósito.
• La libertad de estudiar cómo trabaja el programa y de adaptarlo a las nece-
sidades propias. El acceso al código fuente es una condición previa.
• La libertad de redistribuir copias para poder ayudar a vuestros vecinos.

• La libertad de mejorar el programa y de difundir vuestras mejoras al públi-
co, para que toda la comunidad pueda beneficiarse. El acceso al código
fuente es una condición previa.
Así pues, el software libre se puede redistribuir y modificar, bien de forma gra-
tuita o cobrando por esta distribución.
Uno de los proyectos de software libre más conocidos es, sin duda, el núcleo
(kernel) Linux, programado por Linus Torvals en el año 1991. GNU/Linux es la
implementación abierta del sistema operativo Unix para computadores perso-
nales, con Linux de núcleo. El proyecto GNU/Linux lo inició Richard M.
Stallman en el año 1984 con el objetivo de crear un clon del sistema operativo
Unix, pero garantizando las cuatro libertades mencionadas más arriba.
Los proyectos de código abierto y la creación de software libre se caracterizan
por que en su elaboración participan decenas a miles de personas de todo el
mundo. Un grupo reducido de personas toma las decisiones de diseño y de pro-
gramación mientras que un gran número de programadores detectan y corrigen
errores y añaden nueva funcionalidad.
9. El mundo laboral
En el mundo laboral hay diferentes funciones directamente relacionadas con

la programación a las que normalmente pueden acceder los informáticos (inge-
nieros o ingenieros técnicos). Por descontado, hay muchas otras funciones
–relacionadas con otras áreas como la seguridad, las bases de datos, etc.– para
las que las exigencias de conocimientos de programación son elevadas. A con-
tinuación sólo presentaremos las que están directa y exclusivamente relaciona-
das con la programación:
• Programador júnior: Es un programador con menos de tres años de expe-
riencia, normalmente realiza tareas de programación repetitiva o poco ima-
ginativas.
• Programador sénior: Tiene amplios conocimientos de los lenguajes de pro-
gramación, de los paradigmas de programación y de las tecnologías en
general (por ej. protocolos, comunicación, bases de datos, estructuras de

datos, etc.).
• Analista-programador: Es el encargado de analizar un problema para
encontrar una solución automatizada. En otras palabras, es la persona
encargada de organizar el trabajo de programación a partir de los requisi-
tos del cliente.
• Director de proyecto: Es el encargado de planificar y controlar el proyecto.
Es la persona que tiene que dirigir el equipo (analistas, programadores,
diseñadores, etc.) y mantener la relación con el cliente para que el proyec-
to esté acabado y los objetivos se hayan cumplido en la fecha señalada.
10. Apéndice
10.1. Premios A. M. Turing
Son los premios que concede anualmente la ACM (Association for

Computing Machinery) a aquellas personas que han contribuido con excelen-
cia a la comunidad científica informática.
Esta es la lista de algunas de las personas premiadas en el ámbito de la pro-
gramación y la razón por la que se les concedió la mención:
• Alan J. Perlis. Por su influencia en el área de las técnicas avanzadas de pro-
gramación y construcción de compiladores.
• Edsger Dijkstra. Fue el principal desarrollador de ALGOL a finales de los
años cincuenta, un lenguaje de alto nivel que ha sido un modelo de clari-
dad y rigor matemático. Es uno de los principales exponentes de la ciencia
y el arte de los lenguajes de programación en general y ha contribuido a la
comprensión de su estructura y su implementación.
• Donald E. Knuth. Por su aportación al análisis de algoritmos y el diseño
de lenguajes de programación, y en particular por sus contribuciones al
“arte de la programación de ordenadores” a través de su serie de libros que
llevan ese título.
• Niklaus Wirth. Por desarrollar una serie de lenguajes innovadores: EULER,
ALGOL-W, MODULA y PASCAL.
• Richard M. Karp. Por su contribución continuada a la teoría algorítmica

incluido el desarrollo de algoritmos eficientes por flujo de datos a redes y
otros problemas de optimización combinatorios. Por la identificación de
computabilidad polinomial en tiempo con las nociones intuitivas de efi-
ciencia algorítmica, y, muy notablemente, por la teoría de NP-completitud.
• Ole-Johan Dahl y Kristen Nygaard. Por sus ideas fundamentales para la
emergencia de la programación orientada a objetos, a través del diseño de
los lenguajes de programación Simula I y Simula 67.
• Alan Kay. Por ser el pionero de múltiples ideas para las bases de los lengua-
jes orientados a objetos, en calidad de director del equipo que desarrolló
Smalltalk.
• Peter Naur. Por sus contribuciones fundamentales al diseño de lenguajes
de programación y la definición de Algol 60, el diseño de compiladores y
el arte y la práctica de programación de ordenadores.
Otros programadores premiados han sido John Backus (1977), Robert W.

Floyd (1978), Kenneth E. Iverson (1979), C. Antony R. Hoare (1980), Stephen A.
Cook (1982), John Hopcroft y Robert Tarjan (1986), y Jures Hartmanis y Richard
E. Stearns (1993).
10.2. Ejemplo de código de programación ofuscada en C

© Editorial UOC 139 Gestión de datos
Capítulo V
Gestión de datos: bases de datos y sistemas gestores de

bases de datos
M. Elena Rodríguez González
1. Introducción
Este texto pretende que los lectores se puedan introducir en los mecanis-
mos que permiten gestionar los datos que se encuentran guardados en dispo-
sitivos de almacenamiento permanente (como los discos magnéticos) y que
son requeridos por el conjunto de programas de aplicación que las empresas
y organizaciones utilizan en su actividad cotidiana.
Aunque hay diferentes mecanismos para guardar los datos de manera per-
manente, el más potente en cuanto a prestaciones son las bases de datos, que
son gestionadas por un software específico que recibe el nombre de sistema
de gestión de bases de datos. Precisamente por eso, estos elementos serán el
núcleo central de interés de este texto.
2. Concepto de base de datos
La información se ha convertido en uno de los activos más importantes de

todas las empresas y organizaciones, con independencia de cuáles sean sus
ámbitos de negocio o actuación. Para obtener esta información, sus sistemas
informáticos (SI), en general, necesitan acceder a diferentes fuentes de datos
guardadas en dispositivos de almacenamiento permanente. Frecuentemente
estas fuentes de datos habrán sido desarrolladas de manera independiente,
podrán representar tanto información estructurada como semiestructurada y

estarán distribuidas en diferentes ordenadores, accesibles a través de una red de
comunicaciones.
Para acceder a estas fuentes de datos, debe haber herramientas que simplifi-
quen su gestión y que ayuden a extraer información útil en un tiempo razona-
ble. De lo contrario, el coste de adquisición y gestión de los datos puede exce-
der el valor que se pueda derivar de ellos.
A día de hoy, el mecanismo más habitual que se utiliza con el fin de almace-
nar y acceder a grandes volúmenes de datos estructurados son las bases de
datos.
Una base de datos (BD) es la representación de una colección de datos estructu-

rada que describe las actividades de una organización.1 Esta representación inclu-
ye entidades del mundo real y sus interrelaciones y tiene que permitir diversas uti-
lizaciones.
Un sistema de gestión de bases de datos2 (SGBD) es un software específicamente

diseñado y desarrollado para asistir en la creación, la manipulación y el manteni-
miento de las BD.
Ejemplo de BD y de SGBD
En el contexto de una universidad, como es el caso de la UOC, una BD podría conte-
ner datos en torno a diferentes entidades del mundo real y de interrelaciones entre
estas entidades como:
• Diferentes entidades, como estudiantes, profesores, titulaciones y asignaturas, así
como materiales didácticos.
• Interrelaciones entre estas entidades, como las asignaturas en que se matriculan los
estudiantes en diferentes semestres, así como las calificaciones obtenidas, las asig-
naturas que conforman cada titulación, las asignaturas que imparte cada profesor,
los materiales didácticos asociados a cada asignatura, etc.
Por ejemplo, podemos representar gráficamente las entidades estudiantes y asigna-
turas, así como una posible interrelación entre las dos entidades de la manera
siguiente:
1. A veces, la BD puede describir las actividades de varias organizaciones relacionadas.

2. Ejemplos de SGBD serían productos como Oracle, Infomix o PostgreSQL.
Las dos cajas anteriores representan entidades del mundo real, como por ejemplo
estudiantes y asignaturas. Por ejemplo, la caja de arriba representa la entidad estu-
diante, que contiene estudiantes concretos como Pedro Río, Diana Pérez, Elena
Campos y Víctor Gabete; la caja de abajo representa la entidad asignatura, que con-
tiene asignaturas concretas, por ejemplo, la asignatura de Álgebra, Uso de Bases de
Datos, Estadística y Estructura de Computadores.
Entre estas dos entidades del mundo real podemos establecer diferentes interrelaciones;
en nuestro ejemplo concreto, la interrelación establecida representa las asignaturas en
que se matricula cada estudiante en el semestre en curso. Así pues, podemos ver, siguien-
do las líneas, que Pedro Río está matriculado de la asignatura de Álgebra, que Diana Pérez
está matriculada en Uso de Bases Datos y Estadística, que Elena Campos está matricula-
da en Estadística y Estructura de Computadores, y que Víctor Gabete está matriculado
en Uso de Bases de Datos y Estructura de Computadores.
Diferentes usuarios pueden estar interesados en acceder, con diferentes propósitos, a
la BD que almacena todos estos datos. El encargado de posibilitar este acceso a la BD
será el SGBD. Algunos ejemplos de posibles funcionalidades que tiene que resolver el
SGBD podrían ser las siguientes:
• Los estudiantes pueden estar interesados en consultar su expediente académico.
• Los profesores necesitan poder consultar qué estudiantes se han matriculado en las
asignaturas que imparten cada semestre, y también tienen que poder introducir sus
calificaciones.
• El personal de gestión académica necesita consultar las asignaturas en que se han
matriculado cada semestre los estudiantes a los efectos de pago de matrícula y envío
de materiales didácticos.
• El personal de recursos humanos necesita saber las asignaturas que imparte cada
profesor y el tipo de vinculación profesional con la institución, con el fin de poder
llevar a cabo el pago de nóminas.
Es importante destacar que el área de BD y de SGBD es un microcosmos den-

tro de la ciencia informática. Los aspectos tratados y las técnicas aplicadas abar-
can un amplio espectro como, por ejemplo, las metodologías para el análisis y
el diseño de BD, el desarrollo de lenguajes para permitir la definición y mani-
pulación de las BD, así como sus compiladores y analizadores, sistemas operati-
vos, programación concurrente, estructuras de datos y algoritmos para la repre-
sentación interna de BD, sistemas distribuidos, técnicas estadísticas, mecanis-
mos de seguridad, etc.
Como veremos con más detalle posteriormente, el análisis y el diseño de BD
se incluye dentro de un proceso más genérico de desarrollo de sistemas infor-
máticos y cubierto por el área de ingeniería del software.
3. Evolución del área de bases de datos
A continuación se exponen de manera esquemática los principales hitos que

han posibilitado el desarrollo del área de las BD y de los SGBD desde sus oríge-
nes hasta la actualidad, tomando como criterio de esta evolución los diferentes
modelos de datos que hay detrás de estos SGBD.
3.1. Los modelos de datos prerrelacionales
Desde los inicios de la ciencia informática, el almacenaje y la manipulación de

datos han sido uno de los focos de aplicación y de investigación más importantes.
Las aplicaciones informáticas que requerían ficheros sencillos implementaron las
operaciones de acceso a estos ficheros durante mucho tiempo. Estos ficheros sen-
cillos servían para guardar datos estructurados de manera permanente, mediante
la aplicación de unas reglas bastante simples que se pueden resumir de la siguien-
te manera:
• El fichero almacena datos que corresponden a las instancias de una misma
entidad; estos datos se estructuran en una colección de registros. Por ejem-
plo, podemos tener un fichero que almacene datos de estudiantes, de
manera tal que cada registro del fichero represente los datos de un estu-
diante concreto, como sería el caso de un estudiante que se llamara Juan

Gómez Pino.
• Cada registro es una colección de campos, uno para cada atributo de la
entidad. De nuevo, en nuestro ejemplo, para el registro que corresponde al
estudiante Juan Gómez Pino podemos tener diferentes campos, como su
DNI (46742366 H), su nombre y apellidos (Juan Gómez Pino), su fecha de
nacimiento (31-3-1976), etc.
Pero a medida que se requerían ficheros más complejos como, por ejemplo,
ficheros que tenían que almacenar datos de más de una entidad, esta misma
complejidad llevó a la decisión de ocultar el tratamiento de los ficheros en pro-
gramas especializados, separados del resto de aplicaciones informáticas. De esta
manera apareció el software de gestión de ficheros, que sería el núcleo y el ori-
gen de los SGBD actuales.
El que se considera el primer SGBD es el Integrated Data Store (IDS), diseñado por
Charles Bachman3 en la General Electric en 1964. Este producto fue el núcleo sobre
el que se basó el modelo de datos en red, convertido posteriormente en estándar
gracias al trabajo de CODASYL (Conference on Data Systems and Languages).
Aunque el IDS fue el primer SGBD, el primer SGBD comercial con inciden-
cia real en el mercado fue el IMS de IBM, del que se entregó la primera versión
en 1969. El IMS se configuró como SGBD de uso general, desde las primeras
aplicaciones en el mundo de la aviación, para las que nació, hasta el uso masi-
vo en los grandes bancos de todo el mundo. El modelo de datos subyacente a
este SGBD es el llamado modelo de datos jerárquico.
Tanto en el modelo de datos jerárquico como en el modelo de datos en red,
las estructuras que se proporcionan para representar los datos constan de dos
elementos básicos, los registros de datos y las interrelaciones entre los registros
de datos. Mientras que el modelo de datos jerárquico estructura registros inte-
rrelacionados mediante jerarquías (árboles) de registros, de tal manera que cada
registro “hijo” sólo puede tener un registro “padre”, el modelo de datos en red
estructura registros interrelacionados en forma de grafo, lo cual permite interre-
lacionar un mismo registro “hijo” con diferentes registros “padre”, tal como
muestra la siguiente figura:
3. C. Bachman obtuvo el premio A. M. Turing otorgado por el ACM en el año 1973 por sus contri-
buciones a la tecnología de BD. Este galardón es el premio más prestigioso que se concede dentro
de la ciencia informática.
3.2. El modelo de datos relacional
En 1970, Edgar F. Codd, que entonces trabajaba en el laboratorio de inves-

tigación de IBM en San José presentó4 un nuevo marco de representación de
los datos llamado el modelo de datos relacional. A diferencia de los modelos
anteriores, que no disponían de una definición formal, este nuevo modelo de
datos se presenta completamente formalizado, tanto en la estructura de los
datos como en las operaciones definidas. La influencia matemática, tanto del
álgebra de conjuntos como de la lógica, es patente en este modelo.
El modelo de datos relacional utiliza como unidad de modelado funda-
mental las relaciones que permiten modelar tanto las entidades como las inte-
rrelaciones entre entidades. Las relaciones se ajustan al concepto matemático
de conjunto e incorporan una serie de atributos, que denotan el esquema (o
intensión) de la relación. Adicionalmente, cada relación guarda un conjunto
de tuplas que constituye la extensión de la relación.
4. La cita bibliográfica correspondiente al artículo que presenta el modelo de datos relacional es

la siguiente: Codd, E. F. “A relational model for large shared data banks”, Communications of the
ACM, 13(6), pág. 377-387, 1970.
E. F. Codd obtuvo el premio A. M. Turing en 1981 por sus contribuciones teóricas y prácticas a
los SGBD, especialmente a las BD relacionales.
Ejemplo de relación
A continuación mostramos un ejemplo de relación que representa los datos de la
entidad asignaturas, con su esquema y un posible conjunto de tuplas:
Es importante destacar que a veces la terminología utilizada puede cambiar

como consecuencia de la representación tabular previa, de manera tal que tabla,
columna y fila se usan como sinónimos de relación, atributo y tupla, respecti-
vamente.
Detrás de esta sencilla estructura conceptual de datos, hay una compleja
estructura física de almacenaje de los datos que permite una rápida respuesta a
una gran variedad de consultas. Sin embargo, a diferencia de los modelos de
datos anteriormente descritos y sus SGBD, el usuario no trata con esta comple-
ja estructura física de los datos; es más, los usuarios disponen de un lenguaje
nativo de alto nivel, bastante declarativo y sencillo, que les permite aislarse de
esta complejidad; este lenguaje, como veremos posteriormente, es el SQL y su
sencillez es una de las claves del éxito del modelo de datos relacional. Es el
SGBD (en este caso, el SGBD relacional) el que trata y resuelve todos los aspec-
tos relacionados con las estructuras de almacenaje. Por todo ello, se dice que los
SGBD relacionales proveen de lo que se denomina independencia de los datos.
Más adelante, en este mismo texto, explicaremos más detalladamente este con-
cepto.
El modelo relacional despertó el interés de la comunidad científica del área
de las BD y el desarrollo de SGBD, y cambió gradualmente, y para siempre, el
paisaje comercial existente hasta entonces, de tal manera que, hoy día, todavía
constituye el paradigma predominante de SGBD.
Directa o indirectamente, con relación al modelo de datos relacional y los
SGBD relacionales, es importante destacar los siguientes hechos:
1) A principios de la década de los setenta (1972-1973) se inician, más o
menos en paralelo, el proyecto System/R en IBM en el laboratorio de investiga-
ción de San José, y el proyecto Ingres en la Universidad de Berkeley bajo el lide-

razgo de Michael Stonebraker. En 1974, fruto de la investigación en torno al
System/R, aparece un primer lenguaje para BD relacionales; este lenguaje es el
SEQUEL (Structured English Query Language). Por razones legales, este lenguaje al
final se acabó denominando SQL (Structured Query Language).
2) En los años 1981 y 1982 aparecen los primeros SGBD relacionales comer-
ciales y sus lenguajes: Oracle con el lenguaje SQL e Ingres con el lenguaje QUEL.
Por su parte, en el año 1983, IBM lanza su primer SGBD relacional comercial, el
DB2, como culminación del trabajo desarrollado en el proyecto System/R.
En el año 1982 el ANSI encarga a uno de sus comités (el comité X3H2) la defi-
nición de un lenguaje de BD relacionales, con el objetivo de que se convirtiera
en estándar. Este comité, tras evaluar diferentes lenguajes, y ante la aceptación
comercial del SQL, escogió como lenguaje estándar un lenguaje basado en el SQL
casi en su totalidad. El SQL se convirtió oficialmente en el lenguaje estándar de
ANSI en el año 1986, y de ISO (International Standards Organization) en el año
1987. Desde entonces, el SQL estándar ha sido objeto de diferentes revisiones y
ampliaciones, y ha dado lugar, sucesivamente, al SQL:1992, al SQL:1999, al
SQL:2003 y al SQL:2008,5 que es la última versión. El hecho de que el SQL sea el
lenguaje estándar para BD relacionales quiere decir que todos los fabricantes de
SGBD relacionales se comprometen a implementar el mismo lenguaje, lo cual
facilita el mantenimiento de los SI que utilizan las BD y el cambio o la existen-
cia de diferentes SGBD relacionales dentro de cada organización.
Al margen de los SGBD relacionales comerciales ya citados, podemos desta-
car otros como, por ejemplo, Informix o el SQL Server. Informix tiene sus raíces
en el trabajo desarrollado en el proyecto Ingres y también ha influenciado el
desarrollo del SQL Server. Informix, tras haber funcionado como compañía
independiente desde principios de la década de los ochenta, fue adquirida por
IBM en el año 2001. SQL Server tiene sus orígenes en el trabajo iniciado en 1987
por la compañía Sybase Corporation, que posteriormente cooperó con
Microsoft (periodo 1988-1993) con el fin de desarrollar versiones de SQL Server
para plataformas Windows. Hoy día, Sybase, para distinguir su SGBD relacional
de SQL Server de Microsoft, ha rebautizado a su producto como Adaptative
Server Enterprise.
5. El SQL:2008 es la última versión estándar de SQL en el momento de escribir este texto, pero segu-
ro que en el futuro saldrán nuevas versiones.
Por último, como SGBD relacionales de código fuente abierto podemos citar
a Ingres, Firebird, MySQL y PostgreSQL. En el caso de PostgreSQL, es importan-
te destacar que surge de las evoluciones sucesivas del proyecto Ingres y que,
posiblemente, de todos los productos de código fuente abierto citados, es el más
potente en cuanto a prestaciones.
3.3. Los modelos de datos posrelacionales
Alrededor de los principios de la década de los noventa aparecen dos mani-

fiestos, firmados por profesionales de prestigio en el área de las BD, que preten-
den indicar hacia dónde tenían que evolucionar los SGBD.
El primer manifiesto, publicado en 1989 y titulado Manifiesto de los sistemas
de bases de datos orientadas al objeto, relaciona una serie de características que
deben tener los SGBD para poder soportar todo tipo de aplicaciones. Estas carac-
terísticas están claramente orientadas al objeto como, por ejemplo, el soporte
para objetos de cualquier complejidad, identificador de objeto, clases de obje-
tos, encapsulación y herencia de clases. La idea básica de fondo es dotar de per-
sistencia los lenguajes de programación orientados al objeto y añadir las funcio-
nalidades proporcionadas por los SGBD.
El segundo manifiesto, titulado Manifiesto de los sistemas de bases de datos de
tercera generación, de 1990, da la vuelta al dilema y propugna extender los SGBD
relacionales añadiendo aquellas características de la orientación al objeto que
sean necesarias, con el fin de acabar proveyendo de funcionalidades similares a
las BD orientadas al objeto. En definitiva, se trata de conservar el esfuerzo de
desarrollo acumulado por los SGBD relacionales, que han demostrado durante
mucho tiempo su validez y solidez en el mercado.
Los SGBD que han seguido la línea del primero de los manifiestos reciben el
nombre de SGBD orientados al objeto, mientras que los que han seguido la
línea del segundo de los manifiestos reciben el nombre de SGBD objeto-rela-
cional. Obviamente, entre los segundos, y a partir del año 1995, encontramos
la mayoría de los productos mencionados en el apartado anterior como SGBD
relacionales. Por ejemplo, Oracle se considera un SGBD objeto-relacional desde
la versión 8, Informix desde la versión 9 y DB2 desde la versión 6. En el caso de
PostgreSQL, es importante observar que nace directamente con la definición de
SGBD objeto-relacional.
Los SGBD orientados al objeto se han quedado restringidos a lo que se cono-

ce como nichos de mercado, es decir, entornos de aplicación muy concretos.
Por ejemplo, aplicaciones CASE, CAD/CAM o CIM. Una de las principales críti-
cas es que su modelo de datos no está apoyado, a diferencia del modelo de datos
relacional, por ninguna teoría elaborada. En cualquier caso, también han hecho
un esfuerzo importante de modelización y de estandarización. Este proceso ha
sido liderado por el ODMG (Object Database Management Group), que integra a
vendedores de SGBD orientados al objeto y a Sun Microsystems. A su vez el
ODMG está vinculado al Object Management Group (OMG).6 El ODMG ha defi-
nido un estándar de persistencia (la última versión es el ODMG 3.0 del año
2000), que entre otros, especifica el lenguaje OQL (Object Query Language) que
busca una potencia y sencillez similares a la del SQL.
Uno de los primeros SGBD orientados al objeto de mercado ha sido
GemStone (1987) y entre los más conocidos podemos encontrar ObjectStore,
Objectivity DB y Versant.
3.4. Otras tendencias
Para acabar esta evolución, es importante mencionar otras áreas en las que
las BD y los SGBD tienen una participación importante:
1) La rápida adopción de la web en los SI requiere que los SGBD incorporen
recursos para ser servidores de páginas web, de manera que los datos almacena-
dos en las BD puedan ser mostrados en documentos XML,7 y a la inversa, es
decir, que dentro de las BD se puedan almacenar documentos XML.
2) A lo largo de los años las empresas han trabajado con BD de varias aplica-
ciones, de manera que han ido acumulando gran cantidad de datos de todo
tipo. Si estos datos se analizan adecuadamente, pueden proporcionar informa-
ción valiosa. Se trata, pues, de mantener una gran BD con información proce-
dente de toda clase de aplicaciones de la empresa (e incluso de fuera). Los datos
de este gran almacén de datos (data warehouse) se obtienen como reproducción
(más o menos sofisticada) de los datos que hay en las BD que se utilizan en la
6. El OMG se estableció en 1989, y entre sus estándares más conocidos están CORBA y UML.
7. El XML (eXtensible Markup Language) es un lenguaje de marcaje de propósito general, propues-
to por el W3C, y que sirve para describir diferentes tipos de datos, especialmente los datos semies-
tructurados que se encuentran en las páginas web.
tarea cotidiana de la empresa. Estos almacenes de datos se utilizan para que

hagan estudios los analistas financieros, los analistas de mercado, etc., y sirvan
para tomar decisiones.
3) Los SGBD también tienen que dar apoyo para conectar diferentes compo-
nentes especializados para diferentes campos de aplicación. Por ejemplo, la
posibilidad de almacenar datos multimedia (como imagen, vídeo y sonido), los
datos topográficos que necesitan incorporar los sistemas de información geográ-
fica o la incorporación del tiempo como elemento fundamental de caracteriza-
ción de la información que requieren las BD temporales.
4) Por último, los SGBD también tienen que proporcionar mecanismos que
permitan la interoperabilidad entre diferentes SGBD (del mismo fabricante o de
otros fabricantes) y las BD que gestionan. Puede ser que estas BD hayan sido
desarrolladas de manera independiente y, en la medida de lo posible, hay que
proveer de acceso integrado a estas BD que están distribuidas como si se trata-
ra de una sola BD. Todo este campo, que puede incluir realidades muy diferen-
tes, recibe el nombre genérico de bases de datos distribuidas (BDD).
4. Objetivos de los sistemas de gestión de bases de datos
A continuación se describen los principales objetivos que tiene que proporcio-

nar un SGBD. Adicionalmente, cuando proceda, se mencionará cómo logran estos
objetivos los SGBD relacionales (y en consecuencia los SGBD objeto-relacional).
4.1. Ejecución de operaciones no predefinidas y complejas
Los usuarios tienen que poder realizar operaciones sobre la BD de cualquier tipo
y complejidad directamente en el SGBD. Éste tendrá que responder inmediata-
mente sin que las operaciones estén preestablecidas, es decir, sin que se tenga que
escribir, compilar y ejecutar un programa específico para cada operación.
Ejemplos de operaciones sobre una BD

Sobre nuestra BD, algunos ejemplos de operaciones podrían ser:
• Se quiere saber el número de estudiantes de más de veinticinco años que han aprobado
la asignatura de Uso de Bases de Datos y se han matriculado en la asignatura de Estructura
de Computadores.
• De cada estudiante matriculado en menos de tres asignaturas, se quiere obtener el
nombre del estudiante, el nombre de las asignaturas matriculadas y el nombre de
los profesores que imparten las asignaturas.
• Se quiere subir el sueldo de los profesores en un 5%.
Adicionalmente, los usuarios tienen que poder formular las operaciones con
un lenguaje sencillo y el SGBD lo tiene que interpretar directamente. Eso no
quiere decir, sin embargo, que no se puedan escribir programas específicos que
incorporen sentencias de acceso a la BD como, por ejemplo, para procesos repe-
titivos.
Como hemos dicho, en el caso de los SGBD relacionales, el lenguaje están-
dar que permite definir y manipular (ya sea para su consulta o modificación)
tanto la estructura como el contenido de la BD es el SQL.
Los usuarios, mediante el uso del SQL, pueden consultar directamente la BD
con algún tipo de herramienta que tenga una interfaz de usuario adecuada (por
ejemplo, basada en ventanas), facilitada por el mismo fabricante de SGBD rela-
cional. También es posible acceder a las BD desde programas desarrollados con
lenguajes de programación como C o Java.
Por último es importante destacar que también se pueden almacenar procedi-
mientos junto con los datos que se almacenan dentro de la BD y bajo el control
del SGBD. Estos procedimientos, conocidos como procedimientos almacena-
dos,8 son especialmente útiles para ejecutar procesos repetitivos. Los procedi-
mientos almacenados se pueden escribir con lenguajes específicos de cada fabri-
cante de SGBD (normalmente estos lenguajes extienden las funcionalidades de
SQL incorporando, por ejemplo, sentencias condicionales e iterativas) e incluso se
pueden almacenar dentro de la BD procedimientos escritos con un lenguaje de
programación específico.
8. Los procedimientos almacenados, que en el SQL estándar se llaman Persistent Stored Modules
(PSM), forman parte del estándar desde el SQL:1999.
4.2. Flexibilidad e independencia
La complejidad de las BD y la necesidad de ir adaptándolas a la evolución de

las necesidades de los SI que las utilizan hacen que un objetivo básico de los
SGBD sea dar flexibilidad a los cambios.
Interesa obtener la máxima independencia posible entre los datos y los programas
de aplicación que usan estos datos para que se puedan hacer todo tipo de cambios
tecnológicos y variaciones en la descripción de la BD, sin que se tengan que modi-
ficar los programas de aplicación ya escritos ni cambiar la manera de escribir las
operaciones que acceden a la BD.
También se quiere que los usuarios de la BD puedan tener visiones diferentes de
una misma BD, ajustadas a sus necesidades, y que estas visiones se puedan man-
tener independientes de la propia BD y entre ellas.
Independencia de los datos

En el contexto de la BD de la UOC podemos poner los siguientes ejemplos de inde-
pendencia de los datos:
1) Se decide ampliar la longitud del atributo nombre de los estudiantes de 30 a 50
caracteres. No haría falta modificar los programas escritos si no importa que los valo-
res obtenidos tengan sólo los primeros 30 caracteres.
2) A los profesores probablemente no les interesa conocer los datos personales de los
estudiantes matriculados en sus asignaturas, como, por ejemplo, el domicilio o el
teléfono. En cambio, para el personal de secretaría estos datos son relevantes a efec-
tos de envío de los materiales didácticos. En otras palabras, la visión del estudiante
que necesitan tener los profesores y el personal de secretaría son bastante diferentes.
La BD tiene que dar apoyo a las dos visiones.
4.3. Integridad ante los cambios
Los SGBD tienen que garantizar el mantenimiento de la calidad de los

datos, es decir, su integridad en cualquier circunstancia. Hay varias causas que
pueden comprometer la integridad de los datos: el acceso simultáneo de varios
usuarios a una misma BD, una situación de avería, el hecho de que se haya deci-
dido tener datos replicados para mejorar el rendimiento del acceso a la BD o que
una operación pueda comprometer una regla de integridad definida sobre la
BD. En este apartado nos interesa esta última situación.
Al diseñar una BD para un SI concreto y escribir el esquema, no sólo hay que defi-
nir las estructuras de datos, sino también las reglas de integridad que queremos
que el SGBD haga cumplir.
Hay dos tipos de reglas de integridad. Por una parte, las reglas de integridad de
usuario, es decir, aquellas reglas que son propias de la realidad que intenta repre-
sentar la BD que se quiere crear; y por otra las reglas de integridad inherentes al
modelo de datos que utilice el SGBD.
Cuando el SGBD detecte que un programa o usuario quiere hacer una operación
que va en contra de las reglas de integridad establecidas al definir la BD, no debe-
rá permitírselo.
Ejemplos de reglas de integridad

En el caso de la BD de la UOC, algunos ejemplos de reglas de integridad podrían
ser:
1) Reglas de integridad de usuario: podemos declarar que el atributo calificación
de los estudiantes sólo adquiera valor dentro de un rango de valores permitidos;
podemos limitar el número máximo de estudiantes por profesor consultor y
asignatura a 60 estudiantes; podemos definir que el sueldo de los profesores no
pueda ser rebajado, que la fecha de finalización de los estudios de cada estu-
diante, si la hay, sea posterior a la fecha de inicio de sus estudios, que las exis-
tencias del material didáctico estén siempre por encima de un cierto valor, etc.
2) Reglas de integridad inherentes al modelo de datos: suponiendo que utiliza-
mos el modelo de datos relacional, dado que las relaciones se ajustan al concep-
to de conjunto, habrá que garantizar que en la extensión de cada relación no
haya tuplas repetidas. Eso se consigue diciendo qué atributo o conjunto de atri-
butos dentro de cada relación no admite valores repetidos. Por ejemplo, en la
relación de asignaturas, podemos asignar un atributo código de asignatura dife-
rente para cada una. Con esta regla conseguiremos que no haya tuplas duplica-
das en la relación de asignaturas, dado que como mínimo cada tupla tendrá un
valor diferente para el atributo código de asignatura.
En el caso de los SGBD relacionales, el SQL ofrece diferentes mecanismos

para definir reglas de integridad. Es posible definir reglas de integridad en
cada relación que conforme la BD y también reglas de integridad que afecten
a más de una relación. De entre los mecanismos más potentes, desde el
SQL:1999, se dispone de los disparadores (triggers en inglés).
Los disparadores son ejecutados por el SGBD de manera automática, es
decir, sin la intervención de una persona, cuando sobre la BD se ejecutan
ciertas operaciones de cambio (inserción, borrado o modificación de los
datos) que pueden comprometer una regla de integridad.
Ejemplo de disparador
En la BD de ejemplo de la UOC, una regla de integridad candidata a ser definida
mediante un disparador sería la de garantizar que las existencias de cada material
didáctico estén siempre por encima de un cierto valor. Supongamos que este valor de
existencias mínimo para cualquier material didáctico es de 50 unidades, y que en
caso de que las existencias bajen por debajo de este valor, se piden 100 nuevas uni-
dades. Sin entrar en aspectos formales, hay que destacar:
1) La operación sobre la BD que hace que el disparador se ejecute es que un usuario o
programa haga una modificación del valor del atributo existencias en la relación de
materiales didácticos.
2) Una vez se ha producido la operación, el SGBD deberá comprobar si el valor del atri-
buto existencias ha sido disminuido, y si lo ha sido, si se encuentra por debajo de las
50 unidades.
3) En el caso de que las existencias estén por debajo de las 50 unidades, el SGBD tendrá
que lanzar un aviso a fin de que se haga el pedido de 100 nuevas unidades del material
didáctico en cuestión.
4.4. Concurrencia y recuperación
Un objetivo fundamental de los SGBD es permitir que varios usuarios y/o

programas puedan acceder simultáneamente (de forma concurrente) a una
misma BD. Es más, cada usuario o programa individual debe tener la sensación
de que sólo él está trabajando con la BD, es decir, hay que evitar problemas de
interferencias entre los diferentes usuarios o programas que acceden simultáne-
amente a la misma BD. Para tratar los accesos concurrentes, los SGBD utilizan
el concepto de transacción.9
Una transacción es un conjunto de operaciones sobre la BD que se ejecutan como

una unidad indivisible de trabajo. Los SGBD tienen que conseguir que el conjun-
to de operaciones de una transacción nunca se ejecute parcialmente. O se ejecu-
tan todas o no se ejecuta ninguna.
9. J. Gray ha sido unos de los investigadores e implementadores de referencia en el área del proce-
samiento de transacciones en SGBD. Por su trabajo, recibió el premio A. M. Turing en 1998.
Ejemplos de transacciones
En la BD de ejemplo de la UOC, algunos ejemplos de transacciones serían los
siguientes:
1) Imaginemos que se quiere subir el sueldo de todos los profesores de la UOC en
un determinado porcentaje. Conceptualmente esta subida tiene que ser una
unidad de ejecución atómica, es decir, o se suben los sueldos de todos los pro-
fesores o no se sube ningún sueldo. Es un proceso sobre la BD que no puede
quedar a medias.
2) La preparación de los materiales didácticos que hay que enviar a los estudian-
tes, en función de las asignaturas en que se han matriculado, también tiene que
ser una transacción, es decir, hay que hacer un único envío que incluya todos
los materiales, en vez de un envío individual para cada asignatura matriculada.
Las transacciones pueden acabar su ejecución de dos maneras. En caso de

que la ejecución haya sido correcta, la transacción finalizará su ejecución con
una petición de confirmación de resultados. Esta petición hará que el
SGBD garantice que cualquier cambio que se haya podido producir pase a ser
definitivo sobre la BD. Por otro lado, en caso de que el conjunto de operacio-
nes que conforman la transacción sólo se haya ejecutado parcialmente, por
ejemplo, debido a un error de ejecución (imaginemos que se ha violado una
regla de integridad), la transacción emitirá una petición de cancelación de
resultados. Esta petición hará que el SGBD automáticamente anule todos los
cambios que la transacción haya podido producir sobre la BD, de manera que
la BD volverá al estado en que se encontraba justo antes de empezar la eje-
cución de la transacción que se ha cancelado.
Es importante destacar que sólo se pueden producir problemas de interfe-
rencias entre diferentes usuarios (o programas) que están accediendo simul-
táneamente a la BD cuando, como mínimo, uno de ellos está haciendo cam-
bios en los datos. Además, el uso de transacciones no garantiza que no se pro-
duzcan problemas de interferencias.
Consecuencias de interferencias entre transacciones

Imaginemos que una transacción que consulta el saldo de una cuenta X se ejecu-
ta simultáneamente con una transacción que realiza un reintegro de 20 de la
misma cuenta X. Supongamos que antes de comenzar la ejecución de las transac-
ciones el saldo de la cuenta X es de 100 . Si, casualmente, la ejecución simultánea
de las dos transacciones es tal y como se muestra a continuación, se pueden pro-
ducir resultados incorrectos:
La transacción de reintegro sobre la cuenta X ha interferido en la ejecución de la

transacción que consulta el saldo de la cuenta X. Si las transacciones se hubiesen eje-
cutado de manera aislada, la transacción de consulta del saldo de la cuenta X habría
encontrado en ambas consultas el mismo valor de saldo para la cuenta X (100 si se
hubiese ejecutado antes de la transacción de reintegro o 80 si se hubiese ejecutado
después).
Para conseguir que las transacciones estén correctamente aisladas entre sí, ade-
más de las transacciones, los SGBD utilizan varias técnicas, la más conocida de
ellas es la basada en el bloqueo (en inglés, lock) de los datos. El bloqueo de unos
datos en beneficio de una transacción consiste en poner limitaciones en el acce-
so que otras transacciones podrán hacer sobre estos mismos datos. Cuando se pro-
vocan bloqueos se producen esperas en las transacciones y, en consecuencia, el
rendimiento global de los sistema es menor. Uno de los objetivos de los SGBD es
intentar minimizar estos efectos negativos.
Intuitivamente, los bloqueos entre las transacciones actúan de manera simi-
lar a los semáforos de tráfico que regulan, por ejemplo, el acceso de peatones y
vehículos a un recurso compartido, como sería el uso de las calzadas por donde
circulan los vehículos, y que los peatones necesitan cruzar, con el fin de evitar
que se produzcan accidentes.
Por último, para acabar este apartado, hay que apuntar el concepto de recu-
peración: el SGBD también tiene que dar herramientas para poder reconstruir o
restaurar los datos estropeados por cualquier tipo de incidente, como sería el
caso, por ejemplo, de que se produzcan casos de errores o desastres. Ejemplos de
errores o desastres podrían ser que el disco que almacena la BD esté parcialmen-
te inutilizado debido a una avería de hardware, que se produzca un corte de luz
en plena actividad sobre la BD, o incluso que en nuestra empresa se produzca
un incendio que provoque la destrucción total de la BD.
Los procesos de recuperación de que dispone cualquier SGBD permiten recons-

truir y/o restaurar la BD y darle el estado consistente, correcto, anterior al inciden-
te. Eso se consigue gracias a la realización de copias de seguridad (en inglés, bac-
kup) de los datos y mediante el mantenimiento continuo de un diario (log en
inglés) en el que el SGBD, entre otros, anota todas las escrituras que se realizan en
la BD.
4.5. Acceso eficiente
Los SGBD tienen que proveerse de un conjunto variado de técnicas sofisticadas

para almacenar y recuperar los datos de manera eficiente.
Este objetivo está íntimamente relacionado con los objetivos de ejecución

de operaciones no predefinidas y complejas, y de independencia de los datos.
Los usuarios tienen que poder expresar qué quieren, es decir, qué datos dese-
an y qué condiciones tienen que cumplir esos datos. El SGBD es el que tiene
que decidir cómo encontrar los datos que los usuarios necesitan. Por lo tanto,
el SGBD necesita poder encontrar una estrategia de ejecución para las peticio-
nes que formulan los usuarios; es más, no sirve cualquier estrategia, sino que
los SGBD tienen que saber encontrar la mejor estrategia, es decir, la estrategia
óptima.
Para resolver eficientemente el acceso a los datos, ya sea para su consulta o
actualización, los SGBD se basan en unas estructuras de datos auxiliares, llama-
das índices, que permiten encontrar rápidamente en el disco los datos que nece-
sita un usuario o programa de aplicación.
De manera intuitiva, se puede establecer un paralelismo entre los índices uti-
lizados en una BD con los índices de conceptos claves que podemos encontrar
al final de cualquier libro de texto. La idea es organizar (de manera alfabética en
el caso del índice del libro) una serie de valores de interés (los conceptos claves
escogidos en el caso del libro), junto con las páginas físicas (las páginas del
libro) que contienen datos con el valor que está siendo indexado (en el caso del
libro, se indican las páginas del libro que hablan sobre cada concepto clave que
se decide indexar).
Ejemplo de uso de índices

Imaginemos que en la BD de la UOC estamos interesados en encontrar los datos per-
sonales de los profesores cuya titulación es graduado en matemáticas.
1) Una posibilidad para resolver la petición será mirar uno a uno todos los profesores
de la UOC y quedarnos únicamente con aquellos que sean graduados en matemá-
ticas.
2) Imaginemos que en la relación de profesores se ha definido un índice, más concre-
tamente sobre el atributo titulación. En este caso, se podría utilizar el índice para
encontrar única y exclusivamente a los profesores que verifiquen la condición
deseada (ser graduado en matemáticas) y obviar al resto de los profesores.
Posiblemente, sobre todo en el caso de que el número de profesores que son gra-
duados en matemáticas sea minoritario, será más eficiente utilizar el índice que
acceder al global de profesores. Es más, es el SGBD el que decide qué estrategia
tiene que utilizarse, y obviamente, se decantará por la más óptima, es decir, por la
que le permita resolver la petición formulada por el usuario accediendo al míni-
mo de datos (o alternativamente accediendo al mínimo número de páginas de
disco) imprescindible.
Aunque el uso de índices mejora el rendimiento de la consulta de datos de

una BD, hay que tener en cuenta que hay asociado un coste de mantenimiento
ante cambios de los datos, por lo cual hay que estudiar minuciosamente cuán-
tos y qué índices hay que crear en una BD.
4.6. Seguridad
El término seguridad se ha utilizado en diferentes sentidos a lo largo de la

historia de la informática.
En el campo de los SGBD, el término seguridad se utiliza para hacer referencia a

los términos relativos a la confidencialidad, las autorizaciones, los derechos de
acceso a los datos almacenados en la BD, etc.
Estas cuestiones siempre han sido importantes en SI con exigencias altísimas

de seguridad (pensemos en SI de ámbito militar o agencias estatales, por ejem-
plo), pero desde los años noventa, con la proliferación de las redes de comuni-
cación, han ido adquiriendo importancia en cualquier SI que almacene datos

sobre personas.10
Con relación a la seguridad en BD, es preciso que los SGBD sean capaces de:
1) Incorporar mecanismos que posibiliten la identificación y la autentica-
ción de usuarios. Mientras que la identificación permite distinguir entre
usuarios diferentes, la autenticación permite garantizar que un usuario es
quien realmente pretende ser. Estos mecanismos pueden incluir desde el
uso de nombres de usuario (para identificar) y contraseñas (para autenti-
car) hasta mecanismos más sofisticados como la utilización de caracterís-
ticas físicas del usuario (retina, voz, huella digital, etc.) que permiten al
mismo tiempo su identificación y autenticación. También es preciso que
los SGBD incorporen mecanismos para hacer estudios estadísticos sobre
los porcentajes de identificaciones y autenticaciones fallidas.
2) Posibilitar el almacenaje de datos y su transferencia a través de la red con
una codificación secreta, es decir, mediante técnicas de encriptación.
3) Definir autorizaciones de acceso a los datos. Una autorización es el privi-
legio que se otorga a un usuario (o grupo de usuarios) para hacer una
determinada operación sobre un cierto elemento de la BD. En el caso de
un SGBD relacional, ejemplos de elementos sobre los que se puede otor-
gar autorizaciones podrían ser una relación, un conjunto de atributos de
una relación, un procedimiento almacenado, etc., mientras que ejemplos
de operaciones pueden ser una consulta, una inserción, la alteración de
una relación (para añadir o eliminar atributos, por ejemplo), la ejecución
de un procedimiento almacenado, etc.
Ejemplos de autorizaciones
Tenemos que pensar que no hay ninguna razón para que todos los usuarios vean toda
la BD y que incluso, dependiendo del tipo de usuario, estarán permitidas sólo un cier-
to tipo de operaciones. En el ejemplo de la BD de la UOC, por ejemplo podría ser así:
1) Sólo los empleados del Departamento de Recursos Humanos tienen derecho a
modificar el atributo sueldo de los diferentes empleados de la UOC, como conse-
cuencia de un proceso de negociación.
2) Cada empleado de la UOC sólo puede ver su sueldo, y sólo lo tiene que poder con-
sultar.
10. Recordemos la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter

Personal (BOE núm. 298, de 12/12/1999, pág. 43088-43099).
5. Las bases de datos relacionales
En los apartados anteriores hemos visto breves pinceladas del sistema rela-
cional. Pero vista su importancia actual, en esta sección se quiere profundizar
un poco en las BD relacionales. Por eso, veremos de manera sucinta los funda-
mentos del modelo de datos relacional y presentaremos algunos ejemplos de
uso del lenguaje SQL.
5.1. Fundamentos del modelo de datos relacional
Como se ha comentado anteriormente, el modelo de datos relacional cons-

tituye un marco formal de representación de la estructura de los datos basado
en el álgebra de conjuntos y la lógica.
De manera esquemática, los rasgos fundamentales del modelo de datos
relacional son:
• Los elementos estructurales son las relaciones, los atributos y las tuplas, res-
pectivamente, popularizados por el SQL como tablas, columnas y filas. Las
relaciones agrupan una serie de atributos que denotan el esquema (o inten-
sión) de la relación. El conjunto de tuplas de cada relación constituye la
extensión de la relación.
• Sobre estos elementos se define un conjunto de operaciones procedimen-
tales, que da lugar al álgebra relacional. Las principales operaciones son la
unión, la intersección, la diferencia, el producto cartesiano, la selección, la
proyección y la combinación (en inglés, la operación de combinación se
llama join). Las cuatro primeras operaciones pertenecen al álgebra de con-
juntos. En cambio, las operaciones de selección, proyección y combinación
son operaciones específicas del modelo de datos relacional.
• También se proporciona un lenguaje declarativo de alto nivel, basado en el
cálculo de predicados, el lenguaje SQL, que incluye un conjunto de sen-
tencias que permiten crear y manipular BD relacionales.
Adicionalmente, el modelo de datos relacional también proporciona meca-

nismos para definir reglas de integridad, ya sean inherentes al modelo, como
las propias de los usuarios. A continuación se mencionan las reglas de inte-
gridad inherentes al modelo de datos relacional:
a) Cada relación tiene un atributo o conjunto de atributos, llamado clave

primaria de la relación. La clave primaria tiene un valor diferente para
cada tupla y sirve para identificarla. En consecuencia, en una relación
no puede haber dos tuplas idénticas. Adicionalmente, el valor de clave
primaria no puede ser desconocido (nulo en terminología del modelo
de datos relacional).
b) Los atributos no pueden tomar más de un valor en una tupla.
c) El orden de las tuplas de la relación y el orden de los atributos dentro
de la tupla son irrelevantes.
d) La interrelación entre dos relaciones (R y T) se lleva a cabo mediante
claves foráneas. Una clave foránea es un atributo o conjunto de atribu-
tos en una relación (por ejemplo, T), de manera que los valores que
toman para una tupla determinada coinciden con el valor de clave pri-
maria de una tupla en la otra relación (en este caso R). Esta igualdad de
valores permite pasar de una relación a otra (de R a S y de S a R).
Ejemplo de relaciones, atributos y tuplas

Sobre nuestra BD de la UOC podemos definir los siguientes esquemas de relacio-
nes:
Asignaturas (código_asig, nombre_asig, créditos, modelo_eval)
La relación de asignaturas incorpora una serie de atributos: el código (que es la
clave primaria y se ha subrayado), el nombre de la asignatura, los créditos asigna-
dos a la asignatura y su modelo de evaluación.
Materiales (código_mat, nombre_mat, soporte_mat, existencias)
La relación de materiales didácticos incorpora como atributos el código (que es la
clave primaria y se ha subrayado), el nombre del material, el tipo de soporte en
que se encuentra el material y las existencias disponibles del material didáctico en
el almacén.
Materiales_Asignatura (código_mat, código_asig)
{código_mat} es clave foránea que referencia a Materiales
{código_asig} es clave foránea que referencia a Asignaturas
La relación de materiales por asignatura nos indica los materiales didácticos que
se utilizan en las diferentes asignaturas. En este caso la clave primaria es compues-
ta, lo que indica que una asignatura puede utilizar varios materiales y que un
mismo material didáctico puede ser utilizado en diferentes asignaturas. Con res-
pecto al código de los materiales de esta relación, obviamente, tienen que ser
materiales existentes en la relación de materiales, y lo mismo pasa con el código
de las asignaturas. Por eso estos atributos son clave foránea.
Podemos representar el conjunto de tuplas (extensión) que conforman cada relación,

además del esquema de las relaciones, de manera tabular, tal como se muestra a con-
tinuación:
5.2. Manipulación de bases de datos relacionales con SQL
A continuación se muestran, sin entrar formalmente en su sintaxis, algunos

ejemplos de cómo el lenguaje SQL permite definir y manipular BD relacionales.
5.2.1 Creación de tablas e inserción de filas
En la terminología del SQL, las relaciones o las tablas se crean mediante la

ejecución de la sentencia SQL CREATE TABLE. Tomando como ejemplo la BD de
la UOC, sería posible crear las siguientes tablas:
CREATE TABLE Asignaturas

(codigo_asig CHAR(6),
nombre_asig VARCHAR(50) NOT NULL,
creditos DECIMAL (2,1) NOT NULL,
modelo_eval VARCHAR(40),
PRIMARY KEY(codigo_asig),
CHECK (creditos IN (6, 12))
);
CREATE TABLE Materiales
(codigo_mat CHAR(16),
nombre_mat VARCHAR(50) NOT NULL,
soporte_mat VARCHAR(10) NOT NULL,
existencias INTEGER NOT NULL,
PRIMARY KEY(codigo_mat),
CHECK (soporte_mat IN ('Papel', 'CD', 'Web')),
CHECK (existencias>0)
);
CREATE TABLE Materiales_Asignatura
(codigo_mat CHAR(16),
codigo_asig CHAR(6),
PRIMARY KEY(codigo_mat, codigo_asig),
FOREIGN KEY (codigo_mat) REFERENCES
Materiales(codigo_mat),
FOREIGN KEY(codigo_asig) REFERENCES
Asignaturas(codigo_asig)
);
Como puede verse la creación de tablas incluye la definición de sus atribu-

tos (columnas en terminología del SQL) con el tipo datos y la especificación de
todo un conjunto de reglas de integridad, como la clave primaria de cada tabla,
las posibles claves foráneas, así como las reglas de integridad que regulan el
rango de valores permitidos para una determinada columna o el hecho de que

una columna no pueda tomar valor nulo.
Para insertar tuplas de datos (filas en términos del SQL) en una tabla, el SQL
proporciona la sentencia INSERT. Las siguientes sentencias dan de alta el con-
junto de filas que representa la extensión de las tablas previamente definidas.
Por razones de espacio, sólo se muestran un par de sentencias de INSERT por
tabla, las que corresponden a la primera y última fila de las extensiones de ejem-
plo.
INSERT INTO Asignaturas VALUES

('UBD', 'Uso de Bases de Datos', 6,'(ExFp + Pr) + AC');
...
INSERT INTO Asignaturas VALUES
('EST', 'Estadística', 6,'(AC + Pr) + PV ó (ExFp + Pr)');
INSERT INTO Materiales VALUES

('XP05/UBD/00492', 'Uso de Bases de Datos', 'Papel', 200);
...
INSERT INTO Materiales VALUES
('C03/EST/01295', 'Minitab','CD', 80);
INSERT INTO Materiales_Asignatura VALUES

('XP05/UBD/00492 'UBD');
...
INSERT INTO Materiales_Asignatura VALUES
('C03/EST/01295 'EST');
5.2.2. Consulta de tablas
Para consultar los datos, el SQL nos proporciona la sentencia SELECT. A par-
tir de las tablas creadas en el apartado anterior y las filas que se insertan, se pro-
ponen los ejemplos (en orden de dificultad creciente) de las siguientes consul-
tas SQL:
1) Consulta de todos los datos de la tabla de asignaturas:
SELECT * FROM Asignaturas;

2) Consulta del código, nombre y existencias de todos los materiales:
SELECT codigo_mat, nombre_mat, existencias

FROM Materiales;
En este caso, se está ejecutando una operación de proyección sobre la BD; la

operación de proyección consiste en coger una parte de las columnas de una
tabla.
3) Consulta del código y el nombre de las asignaturas que tienen algún mate-
rial didáctico asociado con unas existencias superiores a las 100 unidades:
Como resultado de la consulta se obtendrían los códigos de asignatura UBD y FP que

corresponden, respectivamente, a las asignaturas de Uso de Bases de Datos y
Fundamentos de Programación.
SELECT DISTINCT a.codigo_asig, a.nombre_asig

FROM (Asignaturas a JOIN Materiales_Asignatura ma
ON a.codigo_asig=ma.codigo_asig)
JOIN Materiales m ON m.codigo_mat=ma.codigo_mat
WHERE m.existencias>100;
En esta consulta es importante destacar que se ha hecho una operación de

combinación de las tres tablas definidas, dado que las existencias se guardan en
la tabla de materiales, los datos de cómo se asocian los materiales a las asigna-
turas se encuentran en la tabla de materiales por asignatura, y algunos de los
datos pedidos como salida de la consulta (nombre de la asignatura) se encuen-
tran en la tabla de asignaturas. Fijaos que ha sido posible pasar de una tabla a
otra a través de las claves foráneas definidas en la tabla de materiales por asig-
natura. La consulta también ejecuta una operación de selección; esta operación
consiste en coger aquellos datos que verifican una cierta condición (en este
caso, que las existencias estén por encima de 100). Para acabar, dado que no se
muestran todas las columnas de las tablas implicadas en la consulta, también se
está aplicando una operación de proyección.
4) Consulta del código de las asignaturas que no tienen ningún material aso-
ciado en formato web:
Como resultado de la consulta se obtendrían los códigos de asignatura UBD y FP.

SELECT DISTINCT ma.codigo_asig

FROM Materiales_Asignatura ma
WHERE ma.codigo_asig NOT IN
(SELECT ma1.codigo_asig
FROM Materiales m JOIN Materiales_Asignatura ma1
ON m.codigo_mat=ma1.codigo_mat
WHERE m.soporte_mat LIKE 'Web');
En el caso de esta consulta es importante destacar que el resultado se ha obte-

nido como consecuencia de aplicar una operación de diferencia de conjuntos.
La consulta más interna (llamada subconsulta en términos de SQL) encuentra
el conjunto de asignaturas que tienen asociado algún material didáctico en
soporte web (en concreto, coge el código de estas asignaturas), mientras que la
consulta externa se queda con las asignaturas (de nuevo coge sólo su código)
que precisamente no verifican la condición previa.
Hay una gran variedad de personas asociadas con la creación y el uso de BD.
En un extremo están los implementadores de SGBD,11 que son los que partici-
pan en la construcción del software especializado que incorpora los SGBD, y en
el otro extremo están los usuarios finales, que son los que usan los datos alma-
cenados en las BD mediante las interfaces de usuario adecuadas. Estos usuarios
finales pueden tener una procedencia formativa muy diversa, pero vista la
importancia de los datos como activo dentro de las empresas, tener unos cier-
tos conocimientos en BD se considera cada vez más importante.
Entre estos dos extremos de tipos de usuarios, se hallan los usuarios especia-
lizados, como serían los diseñadores de BD, los programadores de aplicaciones
que acceden a BD y los administradores de BD.
11. Hoy día, los implementadores de SGBD trabajan para grandes fabricantes como Oracle, IBM,
Microsoft, etc.
6.1. Diseñadores de bases de datos
La tarea de los diseñadores de BD se estructura en tres etapas que consisten en

la elaboración del diseño conceptual, el diseño lógico y el diseño físico de la BD.
El diseño conceptual de la BD consiste en obtener una estructura de los datos
de la futura BD independientemente de la tecnología que hay que utilizar. No
se tiene en cuenta qué tipo de BD se utilizará (relacional, orientada al objeto,
jerárquica, etc.). En consecuencia tampoco se tiene en cuenta con qué SGBD ni
con qué lenguaje concreto se creará y se manipulará la BD. Así pues, esta etapa
sólo se concentra en la problemática de la estructuración de los datos y en la
detección de las entidades de interés (con sus atributos) y sus interrelaciones. El
resultado de esta etapa se expresa mediante algún modelo de datos de alto nivel
o semántico. Entre los más utilizados está el modelo entidad-interrelación
extendido12 y los diagramas de clases del UML.13
El diseño lógico de la BD consiste en la transformación del diseño concep-
tual obtenido en la etapa previa con el fin de adaptarlo a la tecnología que se
tiene que utilizar. Por ejemplo, si queremos trabajar con BD relacionales, esta
etapa obtendrá el conjunto de relaciones que se deriva del diseño conceptual de
la BD con sus atributos, así como la especificación de las reglas de integridad de
la BD, ya sean las reglas de integridad inherentes al modelo de datos relacional
o las reglas de integridad de usuario.
Por último, el diseño físico de la BD transforma la estructura obtenida en la
etapa de diseño lógico con el objetivo de conseguir una mayor eficiencia y, ade-
más, se completa con aspectos de implementación física que dependerán del
SGBD que se quiere utilizar.
Por ejemplo, en el caso de una BD relacional, la transformación puede con-
sistir en los siguientes hechos: tener almacenada en disco alguna relación que
resulte de la combinación de varias relaciones del diseño lógico, fragmentar en
disco alguna relación del diseño lógico en varias relaciones, incorporar nuevos
atributos a una relación por cuestiones de eficiencia en la consulta de datos,
decidir qué disparadores y procedimientos almacenados hay que crear, etc.
12. La primera versión del modelo entidad-interrelación (modelo ER, del acrónimo en inglés,
Entity-Relationship) es obra de Peter Chen y data de 1976.
13. El Unified Modeling Language es un modelo para la construcción de software orientado al obje-
to que ha sido propuesto como estándar ISO por el OMG. La especificación actual (UML 2.0) data
del año 2003.
Por último, con el objetivo de obtener un buen rendimiento de la BD, deben

tenerse en cuenta las características de las operaciones (procesos) que se puedan
prever que consultarán y actualizarán la BD, los caminos de acceso que utilizan
y su frecuencia de ejecución, con el fin de tomar decisiones en la creación de
índices. También hay que prever los volúmenes de datos que hay que almace-
nar en las diferentes relaciones que conforman la BD.
Es importante destacar que este proceso de diseño de BD estructurado en eta-
pas se tiene que llevar a cabo dentro de un proceso más genérico de desarrollo
de SI y cubierto por el área de ingeniería del software. En otras palabras, el pro-
ceso de diseño de BD forma parte del mismo proceso de desarrollo del software.
De hecho, y utilizando conceptos propios de la ingeniería del software, el dise-
ño conceptual de BD está metido dentro de la fase de análisis; el diseño lógico
de BD pertenece a la fase de diseño; y, por último, el diseño físico de BD está a
caballo entre las etapas de diseño y programación.
6.2. Programadores de aplicaciones de bases de datos
Los programadores de aplicaciones que acceden a BD desarrollan paque-

tes de software que facilitan el desarrollo de las aplicaciones con las que interac-
túan los usuarios finales. Como se ha comentado anteriormente, los usuarios
finales pueden no ser profesionales informáticos.
Para escribir estos paquetes de software especializado en el acceso a BD, en
general, los programadores de BD utilizan lenguajes de acceso y de herramien-
tas de software que comercializan los fabricantes de SGBD. Estas herramientas de
software pueden incluir generadores de informes (para poder construir y mostrar
el resultado de consultas complejas sobre la BD), hojas de cálculo, paquetes esta-
dísticos, etc.
Para poder escribir programas de aplicación, los programadores de aplicacio-
nes de BD también deben conocer las principales técnicas de programación con
BD. Por ejemplo, en el caso de SGBD relacionales, teniendo en cuenta que el
SQL es el lenguaje estándar, es imprescindible que los programadores, además
de conocer el SQL, estén también al día de las principales técnicas que permi-
ten incorporar sentencias SQL dentro de los programas de aplicación, así como
las extensiones de SQL que los fabricantes de SGBD relacionales proveen con el
fin de poder escribir procedimientos almacenados en la BD.
6.3. Administradores de bases de datos
Los administradores de BD (ABD) son los responsables del funcionamiento

correcto de la BD y vigilan que siempre se mantenga operativa. Intervienen en
situaciones problemáticas o de emergencia, pero su responsabilidad principal es
velar para que no se produzcan incidentes. Algunas de las tareas típicas de los
ABD son las siguientes:
1) Mantener, administrar y controlar los elementos que conforman la BD.
Comunicar los cambios a los usuarios.
2) Asegurar la máxima disponibilidad de los datos, por ejemplo, haciendo
copias de seguridad de los datos, administrando los dietarios, etc.
3) Resolver emergencias.
4) Vigilar la integridad y la calidad de los datos.
5) Diseñar el nivel físico de la BD, las estrategias de caminos de acceso y las
reestructuraciones.
6) Controlar el rendimiento y las decisiones relativas a las modificaciones en
los elementos que conforman la BD y/o parámetros del SGBD y del sistema ope-
rativo.
7) Establecer normativas y asesorar a los programadores y los usuarios fina-
les sobre la utilización de la BD.
8) Controlar y administrar la seguridad: gestión de usuarios, concesión y
revocación de autorizaciones, etc.
© Editorial UOC 169 Ingeniería del software
Capítulo VI
Ingeniería del software

Jordi Cabot Sagrera
1. Introducción
La ingeniería del software (IS) estudia cuál es la mejor manera de producir

software de calidad. Con esta finalidad, la IS propone la aplicación de una serie
de métodos, notaciones, técnicas, etc., que permiten asegurar la calidad final del
software desarrollado.
Desgraciadamente, hoy día la aplicación de los principios de la IS durante el
desarrollo de software no está todavía generalizada dentro de la comunidad de
desarrolladores. Frecuentemente, el mismo concepto de qué es la IS no se tiene
claro. A veces se asocia la IS con alguna de las técnicas específicas que se utili-
zan o se reduce la IP al arte de hacer “dibujos” o “planos” del software (con rec-
tángulos, rayas, óvalos...) sin acabar de entender cuál es su importancia ni su
utilidad dentro del proceso de desarrollo.
Así, pues, este capítulo pretende exponer al lector los conocimientos necesa-
rios para entender qué es y para qué sirve la IS, así como algunos de los méto-
dos y técnicas que forman parte de ella. Al final del capítulo esperamos haber
convencido de los beneficios de aplicar la IS (en mayor o menor grado) a todos
los proyectos de desarrollo de software que el lector tenga que emprender en el
futuro.
2. ¿Qué es la ingeniería del software?
Para contestar a esta pregunta nada mejor que exponer en primer lugar algu-
nas de las definiciones existentes más populares y ver qué tienen en común.
La ingeniería del software (IS)1 es:

a) El establecimiento y el uso de principios de ingeniería sólidos con el fin de obte-
ner un software económico, fiable y que funcione eficientemente. NATO
Conference.
b) La aplicación de una aproximación sistemática, disciplinada y cuantificable al
desarrollo, el uso y el mantenimiento del software. IEEE software Engineering
Terminology.
c) Es una disciplina de la ingeniería que se preocupa de todos los aspectos de la
producción de software. Ian Sommerville.
De estas definiciones se pueden extraer tres ideas importantes:

1. La IS es una ingeniería. Eso implica que las técnicas que forman parte de
ella tienen que estar bien fundamentadas, ya sea teórica o empíricamen-
te.
2. El objetivo de la IS no es tan sólo producir un software que “funcione” sino
producir un software de calidad (eficiente, libre de errores, usable...). Eso se
consigue mediante la aplicación de las técnicas del punto anterior.
3. IS≠Programación. La IS se ocupa de todas las etapas del desarrollo del soft-
ware, tanto las que deben hacerse antes de empezar la programación
(como el análisis y el diseño) como las que vienen después (pruebas y
mantenimiento).
Este hincapié en convertir la IS en una ingeniería surgió como una de las

respuestas a la “crisis del software”, expresión con la que se conocía al hecho
de que, al principio, la mayoría de los proyectos de software acababa tarde y
excedía el importe presupuestado, con errores y sin satisfacer plenamente las
necesidades de los clientes. Se vio que debido a la complejidad del proceso
de desarrollo se tenía que afrontar la construcción del software utilizando téc-
nicas de ingeniería (análogamente a como se hace en el resto de las ingenie-
1. La expresión “ingeniería del software” se popularizó en la NATO software Engineering Conference

del año 1968.
rías). Hoy día, gracias a las técnicas actuales y a la madurez del área, se ha
conseguido minimizar mucho estos problemas y se puede considerar que la
crisis, a pesar de que no solucionada completamente, como mínimo está ya
en fase de superación, gracias, entre otros, a las aportaciones de la ingeniería
del software.
Ejemplos de errores causados por mal funcionamientos del software desarrollado2

• Explosión de la nave espacial Ariane 5 debido a la excepción generada (y no trata-
da) tras el intento de conversión de un número demasiado grande (1996).
• Interrupción de los servicios de larga distancia de AT&T durante nueve horas debi-
do a una instrucción break errónea dentro de un programa escrito en C (1990).
• Retraso de dieciséis meses en la inauguración del aeropuerto de Denver por proble-
mas con el sistema automatizado de gestión del equipaje (1995).
• Un banco alemán pierde 2.300 millones de pesetas cuando un ejecutivo en prácti-
cas pulsó la tecla equivocada y el software transformó el dinero ficticio del ejercicio
en dinero real que se envió al mercado de valores.
La IS divide el desarrollo de cualquier software en una serie de etapas (tam-

bién llamadas fases).3
– Análisis o especificación de requisitos: se definen los requisitos del software;
qué tiene que hacer para satisfacer las necesidades del cliente.
– Diseño del software: se define cómo da respuesta el software a lo que se tiene
que hacer, definido en la etapa anterior. El cómo depende en parte de qué
tecnología (lenguaje, plataforma...) se escoja para la implementación pos-
terior del sistema (por ejemplo, el diseño varía según si se opta por utilizar
una base de datos relacional o un sistema de ficheros para guardar los datos
que el software tiene que gestionar).
– Programación o codificación: se implementa el diseño previo.
– Pruebas: se verifica el buen funcionamiento de cada componente del soft-
ware aisladamente (pruebas unitarias) y en interacción con el resto de los
componentes (pruebas de integración).
2. Podéis encontrar una lista completa de errores en: http://www5.informatik. tu-muenchen.de/

~huckle/bugse.html (visitada en octubre de 2006).
3. En este capítulo nos centraremos en las etapas de especificación y diseño. Otras etapas son trata-
das en diferentes capítulos de este mismo libro.
– Mantenimiento: se ocupa de los cambios en el software causados por errores,

peticiones de mejoras solicitadas por el cliente o simplemente por variacio-
nes en elementos externos (como cambios del sistema operativo o del sis-
tema gestor de la base de datos) que obligan a hacer una adaptación del
software desarrollado.
Fijaos en que saber cuáles son las etapas del desarrollo no nos da informa-
ción sobre cómo tenemos que actuar con el fin de lograr con éxito el desarro-
llo de un nuevo software (¿en qué orden tenemos que hacer las etapas?, ¿las
podemos solapar o hay que hacerlas una a una?, ¿cuáles son las técnicas útiles
en cada una de las etapas?). La respuesta a estas preguntas depende del méto-
do de desarrollo de software (software development process en inglés) que esco-
jamos. Un método de desarrollo nos indica cuáles son las actividades (y su
resultado) que deben aplicarse en cada fase del ciclo de vida y cómo se tienen
que estructurar y organizar estas fases y sus actividades con el fin de producir
con éxito el software deseado.
Inicialmente, se propuso un método secuencial o en cascada (waterfall model
en inglés), en el que cada fase se completaba en su totalidad antes de iniciar la
fase siguiente. Si se encontraba algún error existía la posibilidad de volver a la
fase anterior para corregirlo y seguir a continuación con el proceso secuencial.
Pero enseguida se vio que era casi imposible aplicar este modelo a los proyectos
reales ya que raramente el cliente era capaz de comunicar todos los requisitos al
principio del proyecto. Además, el cliente tampoco veía ningún resultado hasta
el final del proceso, por lo que no había ningún tipo de feedback por su parte.
En el peor de los casos, el software generado no satisfacía las expectativas del
cliente y se tenía que empezar de nuevo todo el proceso. Como alternativa sur-
gieron posteriormente métodos basados en el prototipado (se muestra primero
un prototipo al cliente con el fin de obtener su visto bueno antes de desarrollar
el software completo) y los métodos iterativos e incrementales (en los que el soft-
ware se desarrolla de forma incremental; en cada iteración se produce una parte
del software final, lo cual da al cliente la oportunidad de ir evaluando las partes
del proyecto que se van completando).
El papel del cliente

Para asegurar la calidad es imprescindible que el cliente intervenga en todas las eta-
pas del proceso de desarrollo. Si el cliente no es el único usuario final del sistema, es
importante que el resto de los usuarios también intervengan en él.
Figura 1. Método en cascada (a) y método iterativo (b)

a) b)
Casi tan importante como la selección del método de desarrollo es escoger la

notación que se ha de utilizar en las diferentes fases del desarrollo. Si, por ejem-
plo, el método nos indica que en la fase de análisis “hay que modelar el dominio
del software” (es decir, la información que tiene que gestionar el software con el
fin de poder realizar sus funciones) se tendrá que acordar el lenguaje de mode-
lización que se usará para modelar esta información (¿el UML?, ¿el ER?). De lo
contrario será imposible que los diferentes integrantes del equipo de desarrollo
se comuniquen correctamente.
La necesidad de establecer una notación común

En el año 1999 la nave espacial Mars Climate Orbiter se estrelló durante el proceso
de entrada a la órbita marciana debido a un error del sistema de navegación. Todo
indica que este error se produjo porque dos de los sistemas de navegación encarga-
dos de controlar las maniobras de la nave utilizaban notaciones (unidades de medi-
da, en este caso) diferentes. Uno asumía que los valores numéricos se expresaban uti-
lizando el sistema métrico decimal mientras que el otro asumía que hacían referen-
cia a pies y pulgadas (sistema métrico inglés). Este error de comunicación entre los
dos software costó 125 millones de dólares (aparte de un atraso en las misiones en este
planeta).
Finalmente, es también importante destacar la necesidad de disponer de

herramientas de apoyo durante todo el proceso de desarrollo. Sin estas herra-
mientas es mucho más difícil aplicar el método de desarrollo escogido y se corre
el riesgo de no usarlo. Por ejemplo, necesitamos herramientas que nos permi-
tan modelar fácilmente usando la notación escogida, que comprueben que lo
estamos usando correctamente, que nos ayuden a gestionar el proyecto (cuáles
de las tareas del método hemos finalizado, quién ha intervenido en ellas), etc.
3. Evolución histórica
Aunque la IS aparece a finales de los años sesenta y principios de los seten-

ta, se puede considerar todavía un disciplina muy nueva, sobre todo si la com-
paramos con otros tipos de ingenierías.
La evolución de la IS ha ido muy ligada a la evolución de los lenguajes de
programación usados en la implementación del software. Al igual que los len-
guajes de programación han pasado de ser lenguajes estructurados a lenguajes
orientados a objetos, podemos dividir también los métodos utilizados en la IS
en métodos estructurados y en métodos orientados a objetos. Esta distinción
hace referencia a las técnicas utilizadas en cada una de las fases del desarrollo
(principalmente en las fases de análisis y diseño) y no tanto a cómo se organi-
zan estas fases entre sí. En lo relativo a esta organización, ya hemos comentado
en el punto anterior que en un principio las fases se organizaban secuencial-
mente y que rápidamente se fue evolucionado hasta los métodos iterativos e
incrementales, que son los vigentes hoy día.
La principal característica de los métodos de análisis y diseño estructurados
es que diferencian claramente las técnicas para la especificación de los proce-
sos (funciones) del software de las técnicas para la especificación de la infor-
mación (los datos) que tiene que gestionar el software. No hay una integra-
ción entre ambas vertientes. Además, muchos de estos métodos siguen una
aproximación top-down en la que se parte del problema entero para ir descom-
poniéndolo progresivamente hasta obtener partes más pequeñas y tratables
(similarmente a como se desarrolla un programa siguiendo el paradigma de la
programación estructurada). Estos métodos surgen en la década de los seten-
ta de la mano de autores como E. Yourdon, L. L. Constatine o M. A. Jackson.
Algunos de los diagramas más conocidos son el diagrama entidad relación
(especificación de los datos), el diagrama de flujo de datos (especificación de
las funciones), el diagrama de estructura de Jackson (que, entre otras cosas,
modela la estructura de los datos que se pasan entre los diferentes flujos de
datos o que sirven de entrada y/o salida para el usuario) y los STC (structured
chart, para modelar la descomposición modular de las funciones especificadas
en los diagramas de flujos y las relaciones entre los diferentes módulos).
Con la aparición del paradigma de la programación orientada a objetos,
estos métodos quedaron bastante desfasados, aunque todavía hay algunas
empresas que los utilizan. La programación orientada a objetos mezcla dentro
de un mismo concepto (la clase) la parte funcional y de datos, por lo tanto tener
una especificación separada de ambos conceptos (como pasa con los métodos
de análisis y diseño estructurados) dificultaba mucho el desarrollo del software
orientado a objetos.
A raíz de eso, a finales de los ochenta y principios de los noventa, surgieron
los métodos de análisis y diseño orientados a objetos. Estos métodos intentan
aplicar los conceptos (y las ventajas) de la orientación a objetos ya en las fases
de análisis y diseño de la aplicación, por lo que se consigue una transición
mucho más suave entre las diferentes etapas del desarrollo. Algunos de los
métodos orientados a objetos más conocidos son el OOD (Object-Oriented
Design; G. Booch), el OMT (Object Modeling Technique, J. Rumbaugh) y el OOSE
(Object-Oriented Software Engineering; I. Jacobson). Posteriormente, todos estos
métodos (y muchos otros) se han diluido dentro del UML (Unified Modeling
Language), al cual dedicaremos toda una sección en este mismo capítulo. La pri-
mera versión del UML apareció en 1997. Desde entonces se han ido generado
diferentes versiones hasta llegar a la versión 2.0 (finales de 2004), que es la ver-
sión que se utiliza actualmente. El UML es una especificación estándar del
OMG.4
Es importante destacar que, de hecho, realmente lo que se ha unificado no
son los métodos en sí sino las notaciones de los diferentes métodos. Es decir, el
UML nos permite modelar aspectos del software de forma que todos los ingenie-
ros de software puedan captar la misma semántica del modelo. No obstante, el
UML no nos dice cuáles son los aspectos del software que es importante mode-
lar, ni con qué nivel de detalle, ni en qué fase hay que definirlos... por lo tanto
no se puede considerar un método de desarrollo de software, un error común,
por abuso del lenguaje, entre muchos miembros de la comunidad. Actualmente,
no hay un método de desarrollo orientado a objetos único, aunque el UP
(Unified Process), propuesto por los mismos autores del UML, es uno de los más
comunes.
Una unificación interesada

Esta unificación fue favorecida por la empresa Rational software Corporation (ahora
parte de IBM) que contrató a Booch, Rumbaugh y Jacobson con el fin de trabajar en
4. El OMG (Object Management Group) es un consorcio de empresas que persigue la definición de

estándares tanto de tecnologías de programación (como CORBA) como de especificación (como el
UML).
un método unificado. Poco después, sin embargo, vieron más factible proponer un
lenguaje (notación) unificado como respuesta a la petición del OMG de encontrar un
lenguaje de modelización orientado a objetos estándar. A continuación Rational sacó
la herramienta Rational Rose, que durante muchos años ha sido una de las herramien-
tas de modelización en UML más utilizadas.
En paralelo a todos estos métodos (tanto estructurados como orientados a

objetos) se han ido proponiendo diversos métodos formales. Estos métodos pro-
ponen la especificación del software en términos de un modelo matemático
riguroso que permita verificar la corrección de estas especificaciones. Aunque
conseguirlo sería claramente un beneficio importante (podríamos detectar
todos los errores ya en la fase de análisis y por lo tanto evitaríamos perder el
tiempo y el dinero que cuesta encontrar errores durante la implementación),
estos métodos nunca han tenido un éxito destacable debido a su poca usabili-
dad (es mucho más complicado especificar el software con uno de estos méto-
dos que hacerlo en UML) y a su limitada expresividad (las notaciones utilizadas
en estos métodos ofrecen un conjunto de elementos de especificación más
pobre que el que ofrece el UML). Ejemplos de lenguajes de especificación forma-
les son Z, VDM (Vienna Development Method) o el ASM (Abstract State Machines).
4. Presente de la IS
Sin ningún tipo de duda el UML es el lenguaje de uso común en la inmen-

sa mayoría de los proyectos de desarrollo que se llevan a cabo hoy día (apar-
te de ser un lenguaje estándar según el OMG). Eso ha hecho que este lengua-
je sea ampliamente soportado por todas las herramientas CASE5 actuales (de
rebote eso fuerza a los usuarios de estas herramientas a utilizar el UML como
notación en sus proyectos y por lo tanto amplía la base de usuarios del len-
guaje UML).
5. Las herramientas CASE (Computer Aided software Engineering) son todas las que nos ayudan
durante el desarrollo de software. En www.objectsbydesign.com se puede encontrar una lista de
herramientas CASE útiles para métodos de desarrollo que utilicen la notación UML (visitado en
octubre de 2006).
Como ya hemos comentado anteriormente, no podemos decir lo mismo res-

peto a ningún método de desarrollo. Dicho eso, el UP6 es el método orientado
a objetos que ha tenido un mayor impacto en la comunidad y, de alguna forma,
ha inspirado la gran mayoría de los métodos de desarrollo utilizados por las
diferentes empresas, que acostumbran a ser métodos adhoc (es decir, métodos
propios, adaptaciones de algún método conocido, como el mismo UP, a las
características específicas de los proyectos que desarrolla la empresa).
El resto de esta sección se dedica, pues, a presentar brevemente el UML y el
UP como representantes de las técnicas más usadas dentro de la IS en la actua-
lidad. Para más información consultad la bibliografía que encontraréis al final
del capítulo.
Para ilustrar estos conceptos, presentamos a continuación un pequeño ejem-
plo que utilizaremos a lo largo de esta sección. Así pues, supondremos que nos
encargan el desarrollo de un software para gestionar los clientes (y las compras
que estos hacen) de un pequeño comercio local. Obviamente, por razones de
espacio, se utilizará una versión muy simplificada del problema.
La tienda VamosAComprar
Nos piden que desarrollemos un software que permita gestionar los clientes habitua-
les de la tienda VamosAComprar. En concreto se quiere recoger los datos de los clien-
tes habituales y de las compras (ventas desde el punto de vista de la tienda) que
hacen. Un cliente es habitual cuando hace como mínimo una compra al mes. De
cada venta que se hace a un cliente se necesita el importe total y los productos que
forman parte de ella (sólo hay que saber los productos, no cuántas unidades de cada
producto se han vendido). Algunos clientes se clasifican temporalmente como moro-
sos si tienen alguna compra pendiente de pagar. Aparte de poder gestionar toda esta
información, el software tiene que generar un listado semanal con el resumen de ven-
tas agrupado según el cliente.
4.1 El Unified Process
El UP nace en el año 1998 a partir de las aportaciones de G. Booch y J.

Rumbaugh al método de desarrollo Objectory creado por I. Jacobson. Más que un
único método de desarrollo, el UP pretende ser un marco de trabajo (framework en
6. También conocido como RUP (Rational Unified Process) debido a que sus tres creadores trabaja-
ban en Rational en el momento de definir el método.
inglés) general que se pueda especializar según las necesidades de cada empresa
(los métodos adhoc que comentábamos antes).
Sus principales características son:
– Es un método dirigido por los requisitos del sistema, expresados en la
forma de casos de uso (se dice que el proceso es use-case driven). Cada caso
de uso representa una de las funcionalidades del sistema que el usuario
necesita (y que, por lo tanto, el software final tendrá que implementar).
Partiendo de esta especificación inicial de los casos de uso, se lleva a cabo
todas las demás actividades de desarrollo.
– Es iterativo e incremental. El proyecto no se desarrolla todo de golpe sino
que el desarrollo se divide en una serie de iteraciones, en la que cada itera-
ción genera (o amplía) una parte del software final (que, por lo tanto, va
creciendo de forma incremental, primero se crea una primera versión del
software con una sola funcionalidad, después se añade una segunda y así
sucesivamente). En cada iteración, los desarrolladores tienen que escoger
cuáles son los requisitos (casos de uso) que quieren tratar dentro de la ite-
ración. Al final de ésta, se habrá generado la parte del sistema que imple-
menta los casos de uso incluidos dentro de la iteración.
– Reconoce la importancia de definir la arquitectura de software.7 En la sección
1 ya hemos comentado que la fase de diseño es necesaria con el fin de
adaptar la especificación del software a la plataforma tecnológica con la que
se quiere implementar y ejecutar el sistema. El UP defiende que los arqui-
tectos estén plenamente involucrados en todas las fases de desarrollo del
proyecto.
– Uso de un lenguaje de modelización visual, necesario para facilitar la
comunicación entre los miembros del proyecto. Abogan por el uso del
UML.
– Calidad del software generado. La calidad se contempla como una parte del
mismo método y no como una etapa al final del desarrollo.
– Integración de la gestión, la configuración y los cambios en el proyecto
dentro de las iteraciones. Proponen tener en cuenta estos aspectos en cada
una de las iteraciones.
7. La arquitectura de software define la estructura del software en función de sus componentes, la

relación entre ellos, la interacción con los sistemas externos, la plataforma tecnológica y los requi-
sitos no funcionales (eficiencia, seguridad...).
El UP organiza el desarrollo del proyecto en dos dimensiones (véase la figu-

ra 2). El eje horizontal representa el tiempo y muestra el aspecto dinámico del
proceso de desarrollo. El eje vertical representa el aspecto estático y muestra las
diferentes actividades que se realizan en cada instante de tiempo.
Figura 2. Visión general del Unified Process.
Temporalmente, el proyecto se divide en cuatro fases: inicio, elaboración,

construcción y transición. Al final de cada fase hay una meta que permite decidir
si podemos pasar a la fase siguiente.
En la fase de inicio se delimita el ámbito del proyecto: se identifican las enti-
dades externas que interactúan (lo que se denominan actores) y, a alto nivel,
cuál será la interacción de cada uno de ellos con el software. Al final de esta fase
se debe tener una visión general de los requisitos del software que deben desarro-
llarse. En el caso de la tienda VamosAComprar, en esta fase hay que decidir si el
tendero es el único que interactuará con la aplicación o si también lo podrán
hacer algunos de sus trabajadores. También se tiene que haber determinado cuá-
les son las funcionalidades (es decir, los requisitos) que tendrá que ofrecer el
software (por ej. a la hora de vender los productos ¿se pueden aplicar descuen-
tos o no?).
En la fase de elaboración se perfeccionan más los requisitos, se define ya la
arquitectura de software y se implementan (es decir, se analizan, se diseñan, se
codifican y se prueban) algunos casos de uso críticos, de forma que también
sirva como “prototipo” para ver cuáles son los riesgos del proyecto y si las deci-
siones tomadas hasta aquel momento son correctas. En nuestro caso, podríamos
escoger como ejemplo crítico el caso de uso de gestionar clientes (de hecho, la
elección debería tener en cuenta la opinión del cliente, es decir, el tendero en
nuestro caso) y desarrollarlo completamente. El resultado se le muestra al ten-
dero para que nos dé su opinión. Así podemos ver si “vamos por el buen cami-
no” antes de seguir desarrollando el resto de los casos de uso.
En la fase de construcción se desarrolla el resto de los casos de uso y se prueba
todo el sistema a fondo. En esta fase se implementarían el resto de los casos de
uso no desarrollados ya en la etapa anterior (teniendo en cuenta el feedback que
hemos recibido).
Por último, en la fase de transición se facilita a la comunidad de usuarios el
cambio del viejo sistema al nuevo.8 Eso incluye pruebas de versiones beta del
software por parte de un subconjunto de usuarios, ejecución en paralelo de los
dos sistemas para detectar errores, migración de los datos del sistema viejo al
nuevo (si hace falta), formación a los usuarios, completar la documentación,
etc. En nuestro ejemplo, dentro de esta fase, se le enseñaría al tendero el fun-
cionamiento del nuevo programa y se dejaría todo a punto para empezar a uti-
lizarlo (eso incluye, si es necesario, migrar los datos existentes del formato anti-
guo utilizado por el anterior programa al formato utilizado por el nuevo).
Dentro de cada fase se pueden hacer n iteraciones. En cada iteración se hacen
todas (o algunas) de las posibles actividades definidas por el método (core work-
flows, según la terminología de UP). Las principales actividades según este méto-
do (figura 2) son la recogida de requisitos,9 el análisis, el diseño, la implementa-
ción y las pruebas. Aparte de éstas, UP también define las tareas de apoyo
siguientes (core supporting workflows): configuración y gestión de los cambios,
gestión del proyecto y gestión del entorno, que pretenden ayudar a asegurar la
calidad del software y minimizar los riesgos durante su construcción, dos de los
objetivos más importantes dentro de la ingeniería del software.
Según la iteración, cada actividad tendrá más o menos importancia. Por
ejemplo, en las iteraciones más iniciales, la recogida de requisitos y el análisis
tendrán más importancia que la construcción del sistema, tendencia que se
invierte a medida que vamos avanzando en el tiempo. Sin embargo, es impor-
8. Actualmente la gran mayoría de las empresas ya están informatizadas, por lo tanto la mayoría de
los proyectos tienen como objetivo reemplazar un sistema obsoleto por uno nuevo.
9. Fijaos en que este método separa la recogida de requisitos de su especificación “formal” en la fase
de análisis.
tante recalcar que incluso las iteraciones finales también incluyen, aunque sea
mínimamente, la parte de análisis y diseño ya que podemos necesitar perfeccio-
narlo a raíz de problemas o cambios descubiertos durante la iteración.
Siguiendo un razonamiento similar, se puede ver que la gestión de los cambios
es más importante en las últimas iteraciones (en las que ya tenemos un softwa-
re desarrollado y en las que, por tanto, el usuario puede ver más fácilmente si el
producto se ajusta o no a sus necesidades) que al principio, aunque también al
inicio se debe tener en cuenta (hablando con el cliente en la fase de análisis no
es raro descubrir que algunos de los requisitos que nos dio se entendieron de
forma errónea y que por lo tanto se tiene que rehacer la parte del análisis corres-
pondiente).
4.2 El UML (Unified Modeling Language)
Según sus propios impulsores, el UML es “un lenguaje gráfico para visualizar,
especificar, construir y documentar los artefactos (componentes) de sistemas
que involucran una gran cantidad de software”. El UML es un lenguaje muy
expresivo y que permite definir todas las vistas (perspectivas)10 necesarias para
desarrollar software (la vista de los datos que hay que gestionar, la vista del com-
portamiento del software, la vista de la arquitectura...), por tanto cubre la espe-
cificación de todas las decisiones de análisis, diseño e implementación necesa-
rios. Además, el mismo lenguaje también define un mecanismo de extensión
que permite adaptar el UML a entornos con necesidades muy específicas.
La importancia del UML radica en que detrás de cada elemento gráfico que
forma parte del lenguaje hay una semántica bien definida que permite que una
especificación UML escrita por un desarrollador pueda ser perfectamente enten-
dida por otro, sin ambigüedades. Por lo tanto, hay que ser muy preciso en el uso
de los diferentes elementos gráficos disponibles y escoger en cada momento el
que mejor representa la semántica que se quiere expresar.
El UML no es un lenguaje formal pero sí que define una serie de reglas que
tienen que cumplir todas las especificaciones definidas en UML a fin de que
éstas puedan ser consideradas sintácticamente correctas.
10. Una vista es una abstracción que permite concentrarnos en algún aspecto concreto del softwa-
re e ignorar el resto.
A continuación se presentan, a modo de ejemplo, algunos de los elemen-

tos que forman la notación UML. Estos elementos normalmente se agrupan
en diagramas, en los que cada diagrama se utiliza para representar una vista
particular del software. Para mostrar los diferentes diagramas seguiremos el
ejemplo presentado al inicio de la sección.
Como el UML no es un método de desarrollo, el orden en que introducire-
mos los diagramas necesarios con el fin de solucionar el ejemplo de la tienda
VamosAComprar no lo define el propio lenguaje. Aquí los iremos introducien-
do siguiendo un orden que nos parece suficientemente intuitivo como para
que se entienda el ejemplo (el lector puede dirigirse a cualquier método de
desarrollo, como el anterior UP, para ver en qué orden y en qué nivel de deta-
lle proponen utilizar los diferentes diagramas). En concreto, veremos breve-
mente el diagrama de casos de uso, el diagrama de clases, el diagrama de
secuencia y el diagrama de estados. Se puede consultar la bibliografía disponi-
ble al final del capítulo para conocer el resto de los diagramas y elementos que
forman parte del lenguaje.
4.2.1 Diagrama de casos de uso
El diagrama de casos de uso permite visualizar fácilmente el conjunto de

requisitos del software. Como su nombre indica, el diagrama está formado por
un conjunto de casos de uso, en que cada uno representa una funcionalidad
(“escenario de utilización”) que tiene que proveer el sistema. Aparte de los
casos de uso, el otro elemento básico del diagrama son los actores. Un actor es
un elemento externo al sistema de software que queremos desarrollar pero que
tiene algún tipo de interacción. Un actor puede ser humano (como el usuario
del software) pero también puede ser otro sistema externo con el que el nues-
tro se tenga que comunicar.
El diagrama de la figura 3 muestra algunas de las funcionalidades necesa-
rias para desarrollar el software de VamosAComprar. En este caso sólo hay un
tipo de usuario externo, el tendero, que es el encargado de utilizar las diferen-
tes funcionalidades (gestionar clientes, crear nueva venta, cobrar venta atra-
sada y generar listado ventas).
Figura 3. Ejemplo de diagrama de casos de uso
Hay que observar que cada caso de uso se define como un óvalo con el nom-
bre del caso de uso y que el actor se define usando un stick man. Esta represen-
tación no nos la inventamos nosotros sino que la define el mismo UML (y por
lo tanto cualquier desarrollador que conozca el UML entenderá correctamente
el diagrama, aunque no lo haya hecho él). Es posible definir relaciones entre los
diferentes casos de uso cuando, por ejemplo, uno puede reutilizar la funciona-
lidad definida por el otro. Este es el caso de la relación entre los casos de uso
crear nueva venta y cobrar venta. La funcionalidad de cobrar venta puede ser eje-
cutada directamente por el tendero para cobrar una venta retrasada, pero tam-
bién se puede reutilizar esta funcionalidad para gestionar el cobro de una nueva
venta. Por ello se define una relación de inclusión entre los dos. De esta mane-
ra nos ahorramos duplicar la definición del proceso de cobro como parte del
caso de uso crear una nueva venta.
A cada caso de uso no trivial se asocia también una descripción textual en la
que se explica con más detalle la funcionalidad representada por el caso de uso.
4.2.2 Diagrama de clases
El diagrama de clases recoge todos los conceptos significativos en el dominio

de la aplicación, o dicho de otra manera, define cuál es la información (los
“datos”) que necesita conocer (y guardar) el software con el fin de dar respuesta
a las peticiones del usuario. El diagrama de clases da la visión estática del siste-
ma.
La figura 4 muestra el diagrama de clases para VamosAComprar. Lo utilizare-
mos para ir explicando los principales elementos que pueden aparecer en este
tipo de diagramas: clases, atributos, relaciones de asociación y relaciones de
herencia.
Figura 4. Ejemplo de diagrama de clases.
El diagrama incluye cuatro clases: cliente, cliente moroso, venta y producto.

Fijaos en que utilizamos las clases para agrupar toda la información relevante de
cada uno de los conceptos que aparecen en el dominio de la tienda
VamosAComprar. Así pues, las clases de la figura 4 permiten guardar información
sobre quiénes son los clientes, quiénes son los clientes morosos, qué ventas ha
hecho la tienda y qué productos ofrece, respectivamente.
Para cada clase definimos una serie de atributos. Cada atributo representa
una “pieza” de información que queremos conocer. Por ejemplo, de los clientes
se quiere saber el DNI, el nombre y la edad. De las ventas, se quiere saber el
importe total, la fecha de venta y si la venta ha sido pagada o no. De los clien-
tes morosos, queremos guardar el valor de la deuda que tienen pendiente. De
los productos, se guardan el nombre y el precio.
El tendero también tiene que saber cuáles son las ventas que se han hecho a
cada cliente en particular. Como venta y cliente ya son clases existentes dentro
del diagrama, para guardar esta información hay que relacionar la clase Cliente
con la clase Venta a través de la asociación HaComprado. Como propiedades de
esta asociación podemos definir que cualquier cliente ha hecho como mínimo
una compra (venta desde el punto de vista del tendero) pero que no hay un
máximo definido (el cliente puede hacer todas las compras que quiera). Eso se
indica añadiendo la multiplicidad “1..*” al lado de la clase Venta (la notación
UML define que el asterisco indica que no hay límite superior en la relación).
De la misma manera, definimos que toda venta pertenece a un único cliente
añadiendo un “1” al lado de la clase Cliente. En cambio la relación entre Venta
y Producto es “1..*” en el lado de producto (una venta puede contener muchos
productos pero como mínimo tiene que contener uno) y es “0..*” en el lado de
venta (puede ser que nos llegue un producto nuevo; por lo tanto, este produc-
to no estaría todavía relacionado con ninguna venta).
El diagrama también incluye una relación de herencia (también llamada
relación de generalización) entre las clases Cliente y Cliente moroso. Con esta
relación indicamos que los clientes morosos son un tipo especial de clientes
(todos los clientes morosos son de hecho clientes pero, afortunadamente, no
todos los clientes son clientes morosos). Por lo tanto de un cliente moroso guar-
daremos toda la información definida en la clase Cliente (por eso no repetimos
los atributos de cliente cuando dibujamos la clase Cliente moroso) más la infor-
mación del atributo pendiente, que es un atributo específico de los clientes
morosos.
La barra inclinada delante de pendiente indica que el valor de este atributo
es derivado. Eso quiere decir que su valor se puede calcular a partir de otras pie-
zas de información ya existentes dentro del diagrama. En este caso, el valor de
pendiente de un cliente se define como la suma del importe de las ventas del
cliente aún no pagadas. Esta definición se puede hacer simplemente en lengua-
je natural o se puede formalizar utilizando un lenguaje formal como el OCL
(Object Constraint Language).11
De forma parecida, también tenemos que añadir al diagrama todas las res-
tricciones de integridad que corresponda. Las restricciones de integridad nos sir-
11. El OCL es un lenguaje textual que permite complementar los diagramas UML con toda la infor-
mación que no se puede expresar gráficamente.
ven para definir estados incorrectos de los datos del software. Podemos ver las
restricciones como una condición booleana que tiene que ser cierta siempre.
Cuando una de estas condiciones se convierte en falsa quiere decir que hay un
error en los datos del sistema. Un ejemplo de restricción sería “todos los produc-
tos tendrán un precio >5”. En este caso, cada vez que damos de alta (o actuali-
zamos) un producto de forma que su nuevo precio sea inferior a cinco el soft-
ware tiene que detectarlo y avisar al usuario del error. Fijaos en que la multipli-
cidad de las asociaciones es también un tipo de restricción (por ej. definen el
número máximo y mínimo de relaciones entre clientes y ventas). En general,
sin embargo, las restricciones no se pueden definir gráficamente sino que hay
que hacerlo textualmente, ya sea en lenguaje natural o en OCL.
4.2.3 Diagrama de secuencia
El diagrama de secuencia es uno de los diagramas que permiten modelar el

comportamiento dinámico del sistema. En concreto, permite definir cómo
interactúan y colaboran los diferentes elementos del software que se tiene que
desarrollar con el fin de llevar a cabo las funcionalidades requeridas.
En concreto, el diagrama de secuencia muestra el conjunto de mensajes
(interacciones) que se generan desde el momento en que el actor empieza la eje-
cución de la funcionalidad hasta que ésta se acaba. El diagrama hace hincapié
en mostrar fácilmente la ordenación temporal de los mensajes (la ordenación se
muestra verticalmente, si un mensaje se encuentra más abajo que otro en el dia-
grama quiere decir que el primer mensaje es posterior al segundo).
La figura 5 muestra un posible diagrama de secuencia para el caso de uso
entrar una nueva venta del diagrama de casos de uso.
En la figura se ve que el actor (el tendero) interactúa con la clase formulario
nueva venta (que representa el formulario de la interfaz gráfica donde el tende-
ro entra los datos de la venta) con el fin de crear la nueva venta. Después se
busca el cliente al que pertenece la venta con la ayuda del formulario búsqueda
del cliente. Por último, se asigna la nueva venta al cliente recuperado por el for-
mulario con el fin de asociar al cliente con la nueva venta. Aunque, por simpli-
cidad, no se ha contemplado dentro del diagrama, también habría que asociar
la venta con los productos que forman parte de ésta.
Figura 5. Ejemplo de diagrama de secuencia
Puede suceder que a la hora de dibujar el diagrama de secuencia nos encon-

tremos con que necesitamos definir clases que todavía no habíamos especifica-
do dentro del diagrama de clases. Así pues, en este caso, habría que hacer una
nueva iteración sobre el diagrama de clases anterior con el fin de incluir las nue-
vas clases.
Además, para cada mensaje que aparezca en este diagrama hay que definir
una nueva operación dentro de la clase correspondiente (es decir, la que recibe
el mensaje). Esta operación sería la encargada de procesar la petición del men-
saje. Se tiene que especificar el comportamiento de todas las operaciones (es
decir, “qué” tiene que hacer la operación). Eso podemos definirlo descriptiva-
mente en lenguaje natural, especificarlo formalmente con contractos en OCL o
escribiendo directamente cómo tendría que ser el código de la operación.
4.2.4 Diagrama de estados
El diagrama de estados muestra el comportamiento dinámico de un elemen-

to en concreto. Más específicamente, permite ver los diferentes estados por los
que pasa un objeto (un cliente, una venta...) a lo largo de su ciclo de vida. Por
ejemplo, el diagrama de estados de la figura 6 permite modelar cuando un clien-
te pasa de ser un cliente normal a un cliente moroso y al revés.
Figura 6. Ejemplo de diagrama de estados.
En el ejemplo de la figura 6 se ve que inicialmente un cliente se encuentra

en el estado “buen cliente” (el círculo negro marca cuál es el estado inicial).
Cuando se crea una nueva venta por parte del cliente y la venta queda pendien-
te de pago, el cliente pasa al estado de “cliente moroso”. Posteriormente, cuan-
do el cliente paga la venta puede devolver al estado de “buen cliente” (siempre
que con este cobro el importe pendiente del cliente quede a cero, es decir, cuan-
do no haya otras ventas todavía pendientes).
5. Tendencias
Para acabar el capítulo presentamos una serie de técnicas y métodos que

todavía no tienen un uso generalizado en la industria de desarrollo del software
pero que, en nuestra opinión, adquirirán cada vez un mayor protagonismo en
los próximos años. El horizonte temporal varía para cada propuesta; algunas
propuestas están ya lo bastante maduras mientras que otras todavía están
actualmente en fase de investigación.
En concreto presentaremos las propuestas siguientes: desarrollo de software
dirigido por modelos, ingeniería web, reutilización, verificación y validación de
modelos y métodos ágiles. Las diferentes propuestas se pueden combinar entre
sí, lo cual maximiza sus ventajas. Por ejemplo, se podría partir de un modelo
UML verificado y validado a la hora de seguir un proceso de desarrollo dirigido
por modelos con vistas a generar un software basado en web.
5.1. Ingeniería web
La ingeniería web se puede definir como la especialización de la IS para el

caso específico del desarrollo de software basado en tecnologías web. Por lo
tanto, la ingeniería web no es un nuevo paradigma o un nuevo tipo de ingenie-
ría. Los métodos de desarrollo web toman (y especializan) aquellas técnicas de
la IS más útiles para el caso concreto del software web.12
Por ejemplo, aparte de otros diagramas (como el diagrama de clases, el de
casos de uso, etc., vistos en el punto anterior), todos estos métodos utilizan lo
que denominamos modelo de navegación. Este modelo permite representar las
diferentes páginas webs que forman el software web, el contenido de cada pági-
na (qué datos muestra y cómo los muestra), los enlaces entre ellas, así como (en
algunos de los métodos) las operaciones que se tienen que “ejecutar” cuando el
usuario navega de una página a otra. La figura 7 muestra una parte del posible
modelo de navegación (especificado usando el lenguaje WebML) para el softwa-
12. En el año 2000 un grupo de expertos se reunió en la 22 International Conference on software

Engineering para plantear los temas de futuro de la ingeniería del software. Sus trabajos se pueden
encontrar en: http://www.cs.ucl.ac.uk/staff/A.Finkelstein/fose/future.html (visitada en noviembre
de 2006). Muchos de ellos todavía son plenamente vigentes hoy día. Ejemplos de métodos web son:
WebML, OO-Method, OOH, UWE, OOHDM o Strudel.
re de la tienda VamosAComprar si el tendero pidiera la opción de permitir com-

pras por Internet. La página login permite a los clientes registrarse en el sistema.
A partir de ahí el cliente puede ir a la página NuevaVenta. Una vez entrados los
datos necesarios para dar de alta la venta (por ejemplo el código y la fecha,
suponiendo que no se generen automáticamente), el usuario navega hasta la
página AñadirProducto. Durante la navegación se crea el nuevo objeto venta
(operación InsertVenta) y la relación entre esta venta y el cliente
(InsertHaComprado). Desde la página AñadirProducto el cliente puede ir indican-
do los productos que quiere comprar (cada vez que añade uno, se crea el víncu-
lo entre la venta y el producto, operación InsertIncluye, y se vuelve a la misma
página para añadir otra nuevo si es necesario). Cuando todos los productos han
sido añadidos el cliente ya puede dirigirse a la página Checkout.
Algunos de estos métodos utilizan la notación UML (con algunas extensio-
nes) mientras que otros utilizan su propia notación.
Figura 7. Ejemplo de modelo de navegación
5.2. Desarrollo de software dirigido por modelos
El desarrollo de software dirigido por modelos13 pretende utilizar la informa-

ción contenida en los modelos especificados durante las fases de análisis (espe-
cialmente) y de diseño con el fin de automatizar todo lo posible la fase de codi-
13. Model-driven development (MDD), en inglés.

ficación del software, evitando así la necesidad de invertir esfuerzos en su pro-

gramación final (con lo que además se evitan posibles errores introducidos
involuntariamente por los programadores en esta fase). Imaginad las ventajas
de poder generar automáticamente el software de la tienda VamosAComprar a
partir de diagramas UML como los vistos en la sección anterior.
Esta posibilidad es ampliamente utilizada dentro de la comunidad de bases
de datos con el fin de generar automáticamente las tablas de la base de datos a
partir de, por ejemplo, un diagrama de clases UML, pero no ha sido hasta los
últimos años cuando este tema ha tomado vuelo dentro de la IS. A modo de
ejemplo, actualmente todas las herramientas CASE se anuncian mencionando
sus avanzadas capacidades de generación automática de código. Incluso el OMG
ha presentado el estándar MDA (Model-Driven Architecture) como marco general
para estos tipos de métodos. El MDA propone que a partir de los modelos de la
fase de análisis se generen (semiautomáticamente) los modelos de la fase de
diseño y que a partir de éstos se genere directamente la implementación de la
aplicación.
Aunque en la parte estática del software (los datos), el mecanismo de genera-
ción automática está más o menos establecido (es fácil imaginar qué clases Java
serían necesarias para implementar el diagrama de clases del punto 3.2.2, sobre
todo si obviamos la parte textual del diagrama), en la parte dinámica (el com-
portamiento) todavía no está del todo claro cómo se tiene que llevar a cabo y/o
hasta qué punto es posible hacerlo.
5.3. Reutilización
Una de las supuestas ventajas de la programación orientada a objetos (el

paradigma imperante en la actualidad) es la facilidad de reutilización del códi-
go, con el ahorro de tiempo (¡y de dinero!) que eso comporta. Sin embargo,
todavía no se ha conseguido que la reutilización funcione a gran escala. Con el
incremento de madurez del área de IS están surgiendo una serie de propuestas
que pretenden mejorar el porcentaje de reutilización en el desarrollo de nuevos
proyectos.
Por una parte hay propuestas para la reutilización del conocimiento median-
te el uso de patrones. Los patrones son soluciones genéricas a problemas habi-
tuales en el desarrollo de software. Por lo tanto, una vez nos encontramos el
problema, en vez de intentar solucionarlo nosotros mismos, podemos ver si
alguien que se ha encontrado con él anteriormente ya ha propuesto cómo solu-

cionarlo (y si se puede adaptar su solución a nuestro contexto). Hay patrones
para cualquiera de las actividades (y fases) del proceso de desarrollo.
Otra opción es usar métodos de desarrollo basados en componentes. Una
vez hecho el análisis de requisitos del sistema, estos métodos proponen mirar si
alguna de las partes del sistema puede estar ya desarrollada (por ejemplo, por
alguna empresa externa). La idea es ir hacia la creación de mercados de compo-
nentes, en los que una empresa pueda ir a buscar el componente que necesite.
Este tipo de componentes se llaman componentes COTS (commercial off-the-
shelf). Con el fin de generalizar este tipo de mercados, todavía hay que trabajar
en temas como por ejemplo asegurar la calidad de los componentes, cómo bus-
car los componentes adecuados y cómo integrarlos fácilmente con el resto del
sistema.
5.4. Verificación y validación
Debido a la creciente importancia de los diferentes modelos de análisis y

diseño en el desarrollo de software (por ejemplo, pueden servir para la genera-
ción automática de la implementación del sistema, como hemos comentado en
el punto 4.2), es cada vez más importante verificar y validar estos modelos.
La verificación de un modelo hace referencia al proceso por el cual se com-
prueba que el modelo cumple una serie de propiedades que permiten conside-
rarlo correcto. Un modelo es correcto si está especificado de forma coherente
con la notación que usa, si no tiene redundancias, si es consistente (no hay dos
partes del modelo que definen cosas contrarias), etc. Por ejemplo, un diagrama
de clases especificado en UML tiene que ser ante todo sintácticamente correcto.
Eso quiere decir que tiene que cumplir con las reglas de “escritura” que define
el lenguaje UML, tanto con respecto a los símbolos utilizados como con respec-
to a las relaciones entre estos símbolos (a modo de ejemplo, una de las reglas
prohíbe que una clase sea subclase de ella misma).
Sin embargo, eso no es suficiente para asegurar que el modelo es correcto;
hay que hacer otros tipos de comprobaciones. Por ejemplo, el diagrama de la
figura 8 es perfecto sintácticamente hablando, pero no es correcto. La clase
Persona tiene una relación consigo misma, donde dice que toda persona tiene
como mínimo un padre/madre y que puede tener cero o más hijos. ¿Cuál es el
problema? Fijaos qué pasa si intentamos dar de alta a la persona “Georgina”.
Como toda persona tiene como mínimo un padre/madre, nos vemos obligados
a entrar también a Julia que es la madre de la Georgina. Pero, claro, al entrar a
Julia nos vemos obligados a entrar también a la madre de Julia... Para evitar este
elemento recursivo infinito tenemos que cambiar el diagrama de clases con el
fin de permitir que dentro de nuestro sistema haya personas sin padre (es decir,
personas de quienes, por el motivo que sea, no nos interesa saber quiénes son
sus padres). Hay que tener en cuenta también estos posibles errores a la hora de
verificar un modelo, de lo contrario cuando lo hayamos implementado y empe-
cemos a ejecutar el software resultante nos podemos encontrar con sorpresas
desagradables (y entonces ya será más costoso arreglar los errores).
Figura 8. Ejemplo de modelo incorrecto
Muchas veces la verificación se lleva a cabo transformando el modelo UML

en un lenguaje formal y comprobando la corrección del modelo resultante de
la transformación utilizando técnicas (matemáticas y/o lógicas) propias del len-
guaje formal.
La validación consiste en comprobar que el modelo expresa realmente lo
que el cliente nos ha pedido (es decir, que realmente refleja sus necesidades).
Desgraciadamente, no hay una forma automática de validar un modelo ya que
es el cliente quien tiene que dar el visto bueno. Además, como el cliente proba-
blemente no será capaz de leer los modelos tampoco los puede validar directa-
mente. Las técnicas de validación más habituales incluyen algún tipo de simu-
lación o animación de los modelos, de manera que el cliente pueda hacerse una
idea de cómo se comportará el sistema una vez esté implementado. El cliente
valida indirectamente el modelo cuando valida la simulación.
5.5. Métodos de desarrollo ágiles
Para determinados proyectos, la rigidez y la meticulosidad impuesta por los

métodos de desarrollo actuales (como el UP) puede ser excesiva; es posible que
no sea realmente necesario hacer todas las actividades propuestas y/o con el
nivel de detalle requerido por el método.
Como reacción a estos métodos estrictos han surgido los métodos ágiles. Los
métodos ágiles14 se basan en los valores expresados en el Agile Manifesto:15 Se
valoran más 1. los individuos y sus interacciones que el proceso de desarrollo y
las herramientas; 2. el desarrollo de un software que realmente funcione que una
buena documentación; 3. la colaboración con el cliente que la elaboración de
un contrato; y 4. la capacidad de responder a los cambios que el seguimiento de
una planificación. Como veis, estos principios intentan romper con la rigidez
de los métodos “tradicionales” y dar una respuesta más rápida (más “ágil”) a las
necesidades cambiantes del entorno.
De acuerdo con estos principios, cada método ágil propone una serie de téc-
nicas que se pueden aplicar. Por ejemplo, el XP (eXtreme Programming), sin duda
el método ágil más popular, propone la aplicación, entre otras, de las siguientes
técnicas:
– Diseño simple. Hay que utilizar el diseño más simple posible mientras solu-
cione el problema.
– Pruebas intensivas. Las pruebas se escriben antes del propio código. Eso
obliga a los programadores a pensar en lo que puede fallar antes de escri-
bir el código. Además, se verifica continua y automáticamente que el códi-
go supera todas las pruebas definidas hasta después de cada cambio.
– Refactorización. Mejora continua del código. Incluso el código que ya se ha
considerado bueno se tiene que mejorar si vemos la oportunidad de ello. A
la larga eso mejora la calidad de todo el sistema de software.
– Programación por parejas. Se consigue una mejor calidad si siempre se traba-
ja por parejas (uno de los miembros de la pareja escribe el código y el otro revi-
sa lo que se va escribiendo; los papeles se intercambian al cabo de un rato).
14. Ejemplos de métodos ágiles, aparte de XP, son: SCRUM, Dyanmic Systems Development
Method, Crystal Methodologies, Feature- Driven Development y Adaptive software Development.
15. El Agile Manifesto es un conjunto de principios y valores que tienen que cumplir todos los
métodos “ágiles” y que surgieron a raíz de una reunión que tuvieron los principales representantes
de cada método en el año 2001.
Otro aspecto importante del XP es que defiende que de las cuatro variables
que pueden definir un proyecto (coste en inversión y recursos, tiempo, calidad
y conjunto de funcionalidades) sólo tres las puede escoger el cliente y/o el jefe
de proyectos. La cuarta es responsabilidad del equipo de desarrollo (si se mar-
can los recursos, la calidad y las funcionalidades, el equipo de desarrollo indica-
rá el tiempo que tardará en desarrollar aquellas funcionalidades con los recur-
sos y los plazos previstos).
5.6 Lenguajes específicos de dominio
El UML es un lenguaje generalista, es decir, está pensado para ser útil inde-
pendientemente de cuál sea el dominio del sistema de software que tenemos que
construir (comercios, bancos, asseguradores,…). Precisamente por éstos motivo,
como ya hemos comentado anteriormente, el UML es el lenguaje de modeliza-
ción más usado, con diferencia, hoy en día. De todos modos, esta misma voca-
ción generalista hace del UML un lenguaje muy amplio y complejo de dominar
en la su totalidad. Eso ha hecho que ciertas comunidades que desarrollan soft-
ware para dominios muy concretos, como por ejemplo el sector de la automo-
ción, prefieran desarrollar y utilizar lenguajes de modelización más pequeños y
mejor adaptados a los conceptos y semántica de aquel dominio.16 Este tipo de
lenguajes son los que denominamos lenguajes específicos de dominio (domain-
specific languages en inglés).
La ventaja de este tipo de lenguajes es que permiten modelar utilizando direc-
tamente la terminología y los conceptos utilizados en aquel dominio concreto
cosa que facilita el trabajo de los analistas y diseñadores y también la compren-
sión de los modelos por parte del cliente. El inconveniente es, obviamente, el
coste de crear estos nuevos lenguajes (y las herramientas por manipularlos) ya
que en la gran mayoría de los casos estos lenguajes no están estandarizados sino
que se tienen que diseñar partiendo de cero. Por suerte, tecnologías actuales
como EMF (Eclipse Modeling Framework) y GMF (Graphical Modeling Framework)
facilitan la definición de lenguajes específicos de dominio y la creación automá-
tica de entornos de modelización para los mismos.
16. El propio UML también ofrece la posibilidad de adaptar su semántica a dominios específicos
mediante el uso de profilas pero sólo de una forma limitada.
No hay ninguna regla de oro que permita decidir cuándo es mejor utilizar un
lenguaje reconocido pero generalista como el UML y cuándo es mejor crearse un
mismo un lenguaje más adaptado a nuestras propias necesidades. Aconsejaría
utilizar el UML siempre que sea posible y sólo cuando realmente el UML no se
adapte bien al dominio para el cual tenemos que desarrollar el software en cues-
tión tomar la decisión de adoptar un lenguaje específico de dominio.
Las perspectivas laborales de los expertos en IS son mucho buenas.17 Los dife-
rentes perfiles profesionales coinciden básicamente con las diferentes fases del
ciclo de vida del desarrollo del software (programador, analista, jefe de proyec-
tos...). La evolución laboral de un/a ingeniero/a de software dentro de la empre-
sa se acostumbra a producir en el sentido inverso al orden de las correspondien-
tes etapas dentro del ciclo de vida del desarrollo del software.
Así pues, se acostumbra a empezar trabajando como programador. Dada una
especificación parcial del sistema que tiene que desarrollarse, el programador es
el encargado de implementar aquella parte del sistema utilizando el lenguaje de
programación y el tipo de plataforma escogido.
El responsable de definir esta especificación se llama analista. A partir de un
conjunto de requisitos dados por el cliente, el analista define qué tiene que
hacer el sistema (qué funcionalidad tiene que ofrecer, qué información tiene
que gestionar...) con el fin de dar respuesta a estos requisitos. Esta especifica-
ción se define usando el método y la notación escogidos (por ejemplo, UP
como método y UML como notación).
Es importante subrayar que la figura del diseñador no acostumbra a existir
como tal. Las tareas propias de la fase de diseño (adaptar el análisis a las capa-
cidades del lenguaje y la plataforma tecnológica con la que se quiere implemen-
tar el sistema) se asignan o bien al programador o bien al analista (o bien al
administrador de la base de datos para la parte que tiene que ver con la gestión
17. El ingeniero de software es la profesión más valorada en los Estados Unidos, según la revista
Money. http://money.cnn.com/magazines/moneymag/bestjobs/. Visitada en noviembre de 2006.
de los datos del sistema). En muchos casos, se opta también por buscar directa-
mente a un profesional con el perfil de analista/programador. En estos casos
se espera que la misma persona sea capaz de realizar las tareas de analista y de
programador. Normalmente, en estos casos se indica ya explícitamente cuál es
el lenguaje con el que se implementará el sistema, por ej: “Analista/programa-
dor en Java EE”, ya que conocer el lenguaje de implementación elegido es un
requisito indispensable para poder ocupar este perfil.
Para concluir, la última opción es ser jefe de proyectos. El trabajo principal
de un jefe de proyectos es planificar el proyecto de desarrollo y gestionar el
grupo humano que tiene a sus órdenes con el fin de asegurar que el desarrollo
cumple los plazos establecidos con la máxima calidad posible. Es el responsable
de calcular y fijar estos plazos18 en función de la complejidad de los requisitos
expresados por el cliente y de los recursos de que disponga.
Cada paso en la evolución laboral nos aleja más de las tareas puramente tec-
nológicas. Una alternativa es evolucionar hacia la especialización máxima en
una tecnología determinada. Por ejemplo, se podría ser un experto en tecnolo-
gías Java EE, de forma que cualquier proyecto de desarrollo que tuviera que uti-
lizar Java EE pudiera requerir nuestro conocimiento a la hora de decidir qué
arquitectura sería la mejor para el proyecto, qué tecnologías Java EE
18. Desgraciadamente, es frecuente que esta decisión se vea parcialmente condicionada por otras
áreas de la misma empresa, que quieren asegurar que el cliente acabe aceptando la propuesta, a ries-
go de tener dificultades posteriores para poder cumplir los plazos.
© Editorial UOC 199 Sistemas de información (en las organizaciones)
Capítulo VII
Sistemas de información (en las organizaciones)

Josep Maria Marco Simó, Maria Jesús Marco Galindo, Rafael Macau Nadal, Joan
Antoni Pastor Collado, José Ramon Rodríguez Bermúdez, Isabel Guitart Hormigo
1. Introducción
En los capítulos anteriores nos hemos centrado en la tecnología del hardware

(las máquinas, las redes y sus arquitecturas) y en el desarrollo del software (los
procesos o programas, los datos y la ingeniería que facilita su fabricación).
Podemos decir que nos hemos centrado en los activos o recursos informáticos
(a los que bautizaremos genéricamente en este capítulo como Tecnologías de la
Información), en los que se apoyan todo tipo de organizaciones: una empresa,
una asociación de vecinos, una escuela, una ONG, un ayuntamiento...
Es evidente que estos recursos no son un objetivo en sí mismos (las organiza-
ciones, normalmente, no invierten en Tecnologías de la Información para lucirse
o para estar a la última) sino que cobran sentido en cuanto que están al servicio
de la organización: dentro de ésta van conformando un conjunto cuyo objetivo
es prestarle el servicio informático que necesita. Este conjunto, por las interrela-
ciones que se establecen y por la lógica que lo rige, se convierte en realidad en algo
más complejo: se convierte en un sistema que organiza los recursos informáticos
y que intenta asegurar la transformación y la disponibilidad de la información a
partir de los procedimientos que lo rigen. Es lo que conocemos como Sistema de
Información, indisolublemente ligado, desde nuestra perspectiva, a las tecnologí-
as de la información que las que se apoya.
Este sistema es suficientemente importante como para esperar que se autoor-
ganice espontánea y eficientemente por alguna extraña ley de la informática. Al
no haberse demostrado hasta ahora la existencia de ninguna ley de este estilo,
nos hace falta una función adicional en el abanico de las profesiones de la infor-
mática: la del management de todo ello.
Y no utilizamos la palabra inglesa management por esnobismo sino porque en

este idioma tiene un sentido muy amplio e integrador. En nuestra lengua, en cam-
bio, se suele traducir indistintamente mediante dos términos (dirección y ges-
tión). Ambos términos parecen referirse a la misma actividad y en ámbitos no
especializados así se utilizan. Sin embargo, en el terreno de las organizaciones está
claro que no es así: en este ámbito la dirección tiene que ver con la conceptualiza-
ción de la estrategia, el diseño organizativo que le da apoyo y el ejercicio del lide-
razgo a partir de acciones estratégicas, mientras que la gestión tiene que ver con
la implementación y el control de aquel diseño organizativo. El concepto inglés de
management agrupa, como mínimo, estas dos vertientes. Y, quizás de alguna
manera, representa la estrecha relación que existe entre ellas, posiblemente la
indisolubilidad que las une. Por ello nos gusta. En este capítulo, intentaremos
transmitir la idea de que el management de los sistemas de información va
desde la conceptualización de la estrategia hasta el impulso (o incluso hasta la eje-
cución directa) de acciones relacionadas con esta estrategia, pasando por el dise-
ño organizativo de todo el conjunto.
Y no va a resultar fácil, lo avisamos desde ahora. Porque mientras que en la
mayoría de los capítulos anteriores, los términos, las clasificaciones y las fron-
teras conceptuales son muy sólidos, claros y generalmente aceptados, en este
ámbito de los sistemas de información las palabras se han venido utilizando
muy intuitivamente, sobrecargándolas a menudo y generando una pequeña
nebulosa de conceptos y clasificaciones. Tenemos la excusa de que el ámbito
está a caballo entre la informática y el negocio y de que no hace tanto que habla-
mos de ello sin complejos desde las facultades y escuelas de informática de esta
parte del mundo. De todos modos, intentaremos ser útiles, y allí donde haga
falta explicaremos las diferentes interpretaciones de los conceptos o discutire-
mos la nitidez de las clasificaciones. Eso sí: el lector tendrá que poner de su parte
y aceptar esta laxitud. En definitiva, no son tan importantes los nombres que
demos a las cosas como entender las ideas a las que nos referimos.
Leída esta introducción, tendría que quedar claro que en este capítulo nos
alejaremos de las interioridades de la tecnología y que abordaremos su uso
como un todo al servicio de una organización: definiremos los sistemas de
información, centraremos su importancia, intentaremos clasificarlos y catalo-
garlos y, una vez hecho eso, hablaremos de las personas que los dirigen, que los
gestionan y que los utilizan.
Por eso, invitamos a la lectura de este capítulo avisando del salto hacia una
dimensión mucho más conceptual –más de filosofía y letras, según algunos, pero
terriblemente práctica– y pidiendo una predisposición para entender que la

informática supera la propia tecnología y que establece, en un extremo de la
profesión, una frontera con el mundo de las organizaciones.
2. Una definición de Sistema de Información
Antes de definir formalmente qué es un sistema de información nos referire-

mos a los conceptos de datos y conocimiento y los relacionaremos con el de
información (siguiendo el hilo argumental del libro de Simon):
• Los datos son valores, hechos, evidencias sobre un aspecto concreto de un
objeto o concepto: si queremos comprar un piso, la antigüedad del edificio
donde está, la reforma a la que se sometió o los materiales de construcción,
son datos de los que podemos disponer.
• Cuando estos datos se combinan de tal manera que en conjunto dan una
idea elaborada sobre aquel objeto o concepto, entonces decimos que tene-
mos información: en nuestro ejemplo, esos datos ordenados y relaciona-
dos nos dan la descripción del edificio donde está el piso que queremos
comprar.
• Cuando esta información, además, resulta ser útil porque, aparte de ser
desconocida hasta aquel momento, ayuda a comprender una situación real
y/o a tomar una decisión, entonces tenemos conocimiento: si el edificio es
antiguo pero en él se han realizado suficientes reformas, ese es un conoci-
miento que nos puede ayudar a tomar nuestra decisión de compra.
El conocimiento, a diferencia de los datos y de la información, no es tan
evidente que sea descriptible, representable, almacenable: es un concepto
esencialmente abstracto que tiene que ver con la información de la que se
dispone y con las personas o (¿por qué no?) con la forma en que las orga-
nizaciones la incorporan, la relacionan y la utilizan con su bagaje previo.
Una vez presentados estos tres conceptos (datos, información y conocimien-

to), nos falta todavía una definición de sistema. Tomemos una clásica: “conjun-
to de elementos interrelacionados complejamente entre sí y con su entorno con
una utilidad determinada”.
Ahora ya es casi trivial atreverse a elaborar una definición (ya hemos avisa-
do: es sólo nuestra definición) de Sistema de Información (de ahora en ade-
lante SI) en la que se mencionan las cuatro palabras que acabamos de definir:
“Un conjunto de elementos interrelacionados que garantiza la transformación de

datos en información, así como su disponibilidad para las personas (y para las organi-
zaciones) que la utilizarán siguiendo sus procedimientos para incrementar su conoci-
miento y actuar en consecuencia”.
De los conceptos “disponibilidad” y “transformación”, podemos derivar que

el SI recoge datos, los almacena, los procesa y los distribuye en forma de infor-
mación entre las personas de la organización a la que sirve. Y añadamos a eso
que tiene su razón de ser precisamente porque está al servicio de esa organiza-
ción (y de sus personas). La relación que se establece entre el SI y las personas
(y sus organizaciones) es tan estrecha que para algunos autores es lo mismo, es
decir, que tanto las personas como los procedimientos que éstas utilizan forman
parte también del propio SI.
Hasta aquí no hemos mencionado las tecnologías de la información de las que
hablábamos en la introducción. Y eso es así porque, tal como dice Olivé en el
primer capítulo de su libro sobre modelización de SI, los SI existen desde mucho
antes que la informática: siempre ha habido personas de un entorno concreto
que mediante procedimientos han gestionado datos e información para incre-
mentar su conocimiento. Sin embargo, resulta claro que con la llegada de la
informática y las telecomunicaciones, la potencia y la presencia de los SI se ha
visto incrementada hasta un grado casi incontable. De hecho, actualmente nos
parece inverosímil, anecdótico, casi prehistórico, un SI que carezca del soporte
de alguna tecnología de la información. Por eso, no hablaremos de los SI no
basados en las tecnologías de la información.
Volvamos a nuestra definición de SI y ubiquemos las tecnologías de la informa-
ción: los elementos interrelacionados que menciona incluyen estos activos o recursos
informáticos que hemos explicado en los capítulos anteriores y que ahora bautiza-
mos genéricamente y formalmente como Tecnologías de la Información (TI). Es
decir que, en definitiva entendemos por TI:
“Todo tipo de artefactos, activos y recursos informáticos (ordenadores, sistemas ope-

rativos, sistemas gestores de bases de datos, sistemas de seguridad, protocolos de
redes, drivers, aplicaciones ofimáticas, software de aplicación, herramientas y portales
web...) disponibles para un sistema de información en cada momento según el estado
de la tecnología.”
Esta definición de TI, como veis, agrupa todo el hardware y el software, las
infraestructuras de base en forma de redes e incluso los documentos para hacer-
lo funcionar todo. Considera, pues, las TI como un todo, porque lo importante
es que estén disponibles para el SI, y, transitivamente, para la organización.
Puesto que posiblemente una imagen valga más que mil palabras, en la figu-
ra 1 adoptamos y adaptamos el esquema de Simon, que resume todo lo dicho
hasta ahora.
Figura 1. Definición de Sistema de Información
Pero ya dijimos en la introducción que no sería todo tan fácil. Muchos auto-
res se encuentran más cómodos dibujando los SI y las TI como una especie de
dualidad interdependiente (salvando las distancias, como el yin y el yang orien-
tales, eso sí, omitiendo la idea de oposición inherente a este concepto). Es decir,
no es tanto que los SI incluyan y usen las TI, sino que ambos forman parte de
lo mismo. De hecho, en entornos anglosajones, todavía se va más lejos y se
habla casi indistintamente de information technology y de information systems...
Por todo ello, fijaos que, en un ejercicio de permeabilidad, hemos pintado los
límites de los diferentes conjuntos (procedimientos, TI, SI) con líneas disconti-
nuas (y algunos incluso en forma de nube). Son y los consideramos conjuntos
conceptualmente claros, pero no son espacios estrictamente delimitados, sino
más bien áreas porosas donde unas pueden filtrarse en las otras...
Para no complicarlo, en el resto del capítulo intentaremos seguir los concep-
tos tal como aparecen en la figura 1. Sin embargo, más adelante tendremos que
volver a hablar de otra acepción de Sistema de Información.
3. Un par de clasificaciones elementales de los SI
Como hemos indicado en el anterior apartado, los sistemas de información

tienen que permitir ayudar a tomar decisiones a las organizaciones. ¿Cómo son
estas decisiones (y las acciones que de ellas se derivan)? Para empezar, tradicio-
nalmente se considera que se producen en un nivel de responsabilidad diferen-
te y son, pues, de diferente nivel según presentamos en la figura 2.
Figura 2. Niveles de decisión en las organizaciones

La cúpula directiva se centra en el largo plazo y establece las directrices

estratégicas hacia las que debe encaminarse la organización, cuál es su finali-
dad última y cuáles son, en cada momento, los objetivos para atender a esta
finalidad. La dirección intermedia, centrada a medio plazo, implementa la
táctica de la organización, convirtiendo en planos de acción concretos los
objetivos y directivas de la cúpula, es decir, los traspasa del terreno de las ideas
al de la viabilidad real. Para cumplir estos planes tácticos, en el nivel inferior
la dirección operativa toma decisiones sobre el día a día de la actividad de la
organización atendiendo al corto plazo y a las condiciones de cada momento.
En este nivel, que también llamamos transaccional, es donde se producen los
datos (originados en forma de transacción como diremos más adelante) y la
información que después contribuye a condicionar decisiones futuras de los
niveles superiores.
Puesto que ya tenemos una clasificación de las decisiones que se toman en las
organizaciones, la extrapolaremos como clasificación de los SI ya que, como
decíamos en la definición, los SI tienen que ayudar a tomar decisiones sean del
nivel que sean. Así, esencialmente diremos que existen SI estratégicos, SI tácticos
y SI operacionales. De hecho, como se desprende de la figura anterior, en una orga-
nización lo bastante madura, tendríamos que encontrar un sistema de informa-
ción global formado por tres subsistemas de información, uno para cada uno
de estos tres niveles: estratégico, táctico y operacional. Las fuertes interrelacio-
nes que tendrían que guardar estos tres subsistemas entre sí son las que darían
pie al sistema de información global de la organización.
Pero fijaos que de nuevo en la figura 2 hemos utilizado líneas discontinuas
entre los tres niveles. Volveremos ahora a adentrarnos en la nebulosa a la que
nos referíamos en la introducción: en la realidad actual, los tres niveles de deci-
sión están muy interconectados. De hecho, un buen directivo, una vez tomadas
las decisiones estratégicas, tiene que llevar a cabo acciones tácticas y operativas;
de este modo no está sólo centrado en el largo plazo, sino también en el medio
y en el corto. Además no tiene por qué haber tres personas diferentes en los tres
niveles de decisión. Incluso algunos autores defienden ya que el nivel táctico
está desapareciendo. Por todo ello, tampoco hace falta confundirse y creer que
las decisiones y acciones operativas son menos relevantes que las estratégicas.
En muchos casos, si no fuera por las primeras, las segundas no pasarían de ser
una idea en un papel.
Por eso, una alternativa más simple en la clasificación de los SI es la de con-
siderar que hay sistemas decisionales (que englobarían los niveles táctico y
estratégico de la pirámide clásica) y sistemas transaccionales u operacionales

(que corresponderían al nivel de la base de la pirámide).
Esta clasificación simplificada será la que utilizaremos más adelante para
catalogar las soluciones de SI que existen en el mercado.
4. Profundizando en el papel de los SI en las organizaciones
De las clasificaciones elementales anteriores, se desprende la importancia de

los SI en las organizaciones, ya que afectan a todos los niveles de decisión (y a
las acciones que de ello se derivan). Michael Porter, ya en 1985 y mediante su
teoría sobre la cadena de valor, lo formalizó desde una perspectiva muy clara y
que hoy sigue siendo un referente:
Figura 3. La cadena de valor de Porter
Las organizaciones se estructuran en a) un conjunto de procesos básicos en

los que se produce el valor añadido (la cadena de valor primaria: la de la parte
superior de la figura 3) y b) un conjunto de procesos de apoyo necesarios para
alimentar o soportar la cadena de valor primaria (la de la parte inferior de la
figura 3). Y entre esos procesos de apoyo, y afectando a todos los demás, apare-
ce el SI (figura 4).
Figura 4. El SI en la cadena de valor
El esquema de Porter se va contextualizado en empresas de producción,

pero es fácil adaptarlo a cualquier tipo de organización del ámbito de los ser-
vicios. Actualmente, además, ya aceptamos que los SI afectan no sólo a los
procesos internos de la organización, sino a los de los agentes externos con
los que interactúa: proveedores, clientes, administraciones públicas... Y así
hablamos de la cadena de valor externa o extendida.
Demos ahora un paso adelante. Las conclusiones de Porter sobre que los
SI afectan a todos los procesos de las organizaciones, las tenemos hoy tan
asumidas por nuestra experiencia diaria que nos pueden parecer casi trivia-
les. Lo que quizás no sea tan intuitivo para nosotros es el impacto que tienen
en la estrategia de las organizaciones y las oportunidades que abren en este
sentido. McFarlan y McKenney, al principio de los años ochenta presentaron
la matriz de impacto de los SI en la estrategia (y en las operaciones) de
las organizaciones. En la figura 5 presentamos la versión de Ward y Peppard
de 2003:
Figura 5. Matriz de impacto de los SI de McFarlan y McKenney
Los cuadrantes inferiores corresponden al impacto en las operaciones. El cua-

drante 1 incluye los SI de apoyo, es decir, aquellos que proporcionan apoyo a los
procesos de negocio secundarios de la cadena de valor y que no proporcionan
ventaja competitiva (por ejemplo, la contabilidad). En el cuadrante 2 encontra-
mos los SI clave de las operaciones, es decir, aquellos que proporcionan apoyo a
los procesos centrales del negocio, por ejemplo la atención al cliente o la gestión
de pedidos.
Por su parte, los dos cuadrantes superiores son los que explican el impacto
en la estrategia, que es el aspecto sobre el que queríamos llamar la atención
aquí:
El cuadrante 3 incluye los SI estratégicos: los que soportan negocios o proce-
sos que proporcionan la mayor rentabilidad, posicionamiento o valor que se
persigue en el negocio o actividad actual (por ejemplo, en una compañía de dis-
tribución, la nueva red de terminales de punto de venta). Aquí, de alguna
manera, los SI responden a la estrategia ya marcada por la organización.
Finalmente, el cuadrante 4 acoge los SI de alto potencial, es decir, aquellos
que pueden ofrecer eventualmente una gran oportunidad de negocio, pero que
todavía se desconoce (por ejemplo, cuando los bancos españoles lanzaron las
redes de cajeros automáticos, nadie suponía un grado de éxito tan elevado, com-
parado con la situación en otros países). Este cuarto cuadrante es el que requie-
re una gran amplitud de miras, una receptividad a las posibilidades tecnológicas,
una observación creativa e innovadora de lo que sucede en nuestro entorno. Y
aquí la estrategia de la organización, a diferencia del cuadrante 3, se puede ver
modificada, alimentada y mejorada por las posibilidades que se derivan de los SI.
Llegados a este punto, es decir, una vez contrastado el papel fundamental
que tienen en la actualidad los SI en las organizaciones, tanto en los proce-
sos de todo tipo (todos dependen de los SI) como en la estrategia (la conoci-
da y la que está por descubrir), la implicación es clara: el management (la
dirección y gestión) de los SI en las organizaciones no puede quedarse al mar-
gen de la organización, como si fuera sólo un anexo a ésta, algo que se puede
olvidar o dejar en manos de (cualquier) tercero, sin una vigilancia estrecha...
Es decir, se trata de alinear la estrategia de negocio (“a qué clientes servi-
mos, con qué productos, a dónde se dirige nuestro negocio”) con la estrate-
gia de SI (“qué SI necesitamos para soportar nuestros procesos de negocio y
nuestra estrategia, qué información necesitamos para tomar decisiones y qué
TI nos permite implementar todo ello”).
La idea de hacer convergir la estrategia de SI con la de la organización es lo
que se ha bautizado como alineación estratégica de los SI y surgió de las observa-
ciones del profesor Morton en el MIT (Massachusetts Institute of Technology):
las empresas que no obtenían beneficios para el negocio de sus inversiones en
TI eran aquellas en las que no existía un “ajuste” entre las estrategias de nego-
cio y las estrategias de SI y TI. Hoy en día, es un análisis que se utiliza amplia-
mente para diagnosticar el estado actual de los SI en una organización y para
realizar planes de futuro.
5. La evolución (histórica y tipo) de los SI en las organizaciones
Para hacernos una idea de la evolución histórica de los SI apoyados en TI,

resulta muy adecuada la que propone Applegate. Esta visión parte de un cuadro
(que adaptamos en la tabla 1) en el que califica cuatro etapas en función de seis
dimensiones: el grado de centralización, la focalización, la estandarización, la
interconexión, la velocidad y el rol protagonista.
Tabla 1. Evolución histórica de los SI de Applegate
El mainframe Microordenadores Informática distri- Ubicuidad

(1950-1970) (1970-1980) buida (1980-1990) (1990-actual)
Grado de Centralizado Descentralizado Cliente/servidor Ubicua
centralización
Focalización Aplicaciones Datos Negocio Conocimiento

Estandarización Propietaria Propietaria Abierta Muy abierta
Interconexión Redes WAN Redes LAN Integración Internet
Velocidad Muy lenta Lenta Rápida Muy rápida
Rol protagonista Profesional TI Especialista en Usuario final Cliente interno
apoyo al usuario y externo
• En su origen y hasta finales de los años sesenta, el objetivo de los SI era dar
apoyo a los departamentos, especialmente en funciones como la contabili-
dad o la administración de personal. Se automatizaron los procesos, general-
mente como aplicaciones denominadas corporativas, de un solo uso. Redes pro-
pias de cada empresa conectaban los sistemas centrales con terminales de telepro-
ceso (pantallas “simples”). A esta época corresponde el desarrollo de “grandes” sis-
temas de hardware (mainframe), con bases de datos, sistemas operativos y lengua-
jes de desarrollo propios de estos sistemas (sistemas denominados propietarios),
siempre en un entorno centralizado, único y operado mediante especialistas.
• La segunda etapa, el mundo de los microordenadores (años setenta y prin-
cipios de los ochenta), fue en realidad una variante de la anterior. Permitió
extender la filosofía del mainframe a negocios separados o en territorios
alejados geográficamente. Los usuarios empezaron a ganar conocimiento y
poder sobre los SI y la organización de la función informática se volvió más des-
centralizada o, por lo menos, más “federal”.
• Durante los años ochenta y entrados los noventa, los negocios indepen-
dientes y los grandes departamentos empezaron a disponer de sus propios siste-
mas y los usuarios aumentaron su autonomía y su capacidad de proceso.
Aparecieron los primeros sistemas estándar, independientes de proveedor
(Unix) y, sobre todo, el PC. Se desarrollaron arquitecturas cliente/servidor, sobre
redes más pequeñas y con mayor capacidad. Es la época de la informática dis-
tribuida. La informática se pone ya al servicio de los directivos y los usua-
rios. Aparecen herramientas de análisis y de ayuda a la toma de decisiones, y
paquetes de software integrados por la gestión integral de las organizaciones.
• Desde finales de los noventa hasta ahora, la información se ha con-

vertido en un objeto central de valor para la organización y sus relacio-
nes (clientes, proveedores, distribuidores...). Las nuevas tecnologías de las
comunicaciones, y en particular la de Internet, modifican la organización
interna y externa de la organización. La informática se orienta hacia el clien-
te interno (la organización a la que sirve) y, sobre todo, hacia el externo. Es la
época de la integración y de la conectividad entre aplicaciones, las arquitec-
turas multicapa, los sistemas de inteligencia de negocio y de gestión de las
relaciones con los clientes. El abaratamiento de los costes de proceso, comu-
nicación y almacenamiento; el aumento de la velocidad de transmisión; la
convergencia y ubicuidad de las tecnologías y la capacitación de los usuarios
por medio de herramientas más fáciles de manejar y más extendidas; la gran
facilidad de acceso a la información... Todos estos elementos modifican com-
pletamente el rol de la informática, hasta unos niveles difíciles de prever. Esta
época constituye un salto incluso económico, sociológico o antropológico, lo
que el profesor Castells ha denominado la “era de la información y el conoci-
miento”.
En definitiva, el camino recorrido históricamente se inicia en la fase inicial

de procesamiento de datos y apoyo a los procesos administrativos y llega
hasta la fase actual, en la que se pone el acento en el uso de la información y
la aportación de valor desde la informática.
Esta evolución histórica nos gusta porque tiene una virtud adicional:
parece extrapolable a la historia tipo de los SI en una organización con-
creta (de aquí el título de esta sección). Es decir, una organización empieza
centrando sus esfuerzos en SI en el procesamiento de datos y en los procesos
administrativos, para pasar, a medida que madura, a una etapa en la que la
información le permite tomar decisiones y llegar finalmente a una etapa de
plena madurez, en la que el SI impacta sobre la estrategia de la organización.
Se puede resumir esta evolución a partir de las representaciones de Porter y
Miler por un lado y de Earl por otro1 y que reproducimos en la figura 6.
1. De hecho, Nolan es el precursor de este modelo. Su propuesta es mucho más detallada y hoy es
perfectamente vigente, aunque su detalle se escapa de los objetivos de este texto.
Figura 6. La evolución tipo de los SI en una organización
Esta evolución tipo de las organizaciones prácticamente ha servido y sirve

para explicar lo que sucede en la mayoría de organizaciones tradicionales. Pero
es necesaria otra matización, insistiendo en que no todo cuadra tan bien: qui-
zás hoy ya no afecta a organizaciones jóvenes que nacen con suficiente espíri-
tu innovador desde el primer momento y son conscientes del papel fundamen-
tal que tienen los SI. El caso más claro entre éstas son las organizaciones
intensivas en el uso de las TI, es decir, donde su negocio (su servicio o pro-
ducto) está basado totalmente en las posibilidades de las TI y que trabajan en
la red y para la red (Internet como base, terminales distribuidos de todo tipo,
uso de aplicaciones y servicios de valor disponibles en cualquier lugar...). En
éstas, los SI y las TI ya se perciben “genéticamente” como una herramienta
para dar valor a la empresa y a los clientes. Hoy, que se etiqueta como nativas
digitales a las generaciones nacidas durante la evolución vertiginosa de las TI
de finales del siglo xx, estas organizaciones serían su equivalente: las podría-
mos etiquetar como organizaciones nativas digitales. Y eso en contraposición
a las organizaciones adoptantes o emigrantes digitales que, como las generaciones
previas a la explosión tecnológica y etiquetadas equivalentemente como emi-

grantes digitales, han venido incorporando las posibilidades de la tecnología
según ésta les sobrevenía, las sorprendía y las superaba.
Para ayudar a digerir todo lo que hemos expuesto hasta aquí, recordemos una
obviedad: estos SI tan potentes e importantes para las organizaciones, existen
porque las TI han progresado meteóricamente en las últimas décadas (sobrepa-
sando, en muchas organizaciones, la capacidad para gestionar este cambio). Si no
hubiera sido así, la evolución tipo de la figura 7 quizás todavía se hallaría en la
primera de las etapas o en la segunda como mucho. Es decir, la potencia y la
capacidad del concepto sistema de información está indisolublemente liga-
do a la potencia de la tecnología de la información en cada momento. Quizás
como aquel tipo de yin y yang que mencionábamos al presentar la definición de
SI...
6. Un catálogo de los SI
En el segundo apartado de este capítulo hemos presentado un par de clasifi-

caciones de los SI atendiendo a los niveles de decisión a los que correspondían.
Vamos a elaborar ahora un catálogo de los SI a partir de esta clasificación. Es
decir, vamos a enumerar los tipos de productos (las soluciones informáticas)
que se encuentran en el mercado y que las organizaciones pueden incorporar
para construir su SI.
Pero antes tenemos que volver a dar una nueva explicación acerca del uso
del concepto de sistema de información, tal como avisábamos al final de aquel
apartado. Las soluciones informáticas a las que nos referiremos aquí son, bási-
camente, soluciones de software más o menos complejas. Pero puesto que dan
solución a un problema de SI se las denomina muy a menudo (y también)
sistema de información. Ello no encaja con nuestra definición, en la que el SI
es un sistema global que incluye toda la TI –tanto de software como de hardwa-
re–. En realidad, siguiendo nuestra clasificación, estos productos serían una de
las partes de software de las TI (el software de aplicación, el que no es de base).
Si lo intentáramos, quizás le podríamos encontrar un nombre o una etiqueta,
aunque no es trivial (“TI de software de aplicación”, “sistema de información
software”...). Pero hemos dicho que intentaríamos ponerlo fácil. Así que no nos
inventaremos ningún nombre y os pediremos que si oís hablar de SI en el con-
texto de soluciones informáticas, tengáis presente que normalmente se están
refiriendo a los productos o soluciones software (es decir, un componente de TI)
que cubren una parte más o menos completa del SI de una organización.
Nosotros nos referiremos a este producto software en cursiva (SI) para
intentar diferenciarlo del concepto general de sistema de información.
¿Cómo son estas soluciones software? Pueden ser soluciones individuales o
soluciones integradas.
Las soluciones individuales todavía existen para temas muy específicos de un
negocio, pero para temas muy comunes ya están cayendo en desuso a favor de las
soluciones integradas. Estas soluciones individuales se conciben tan aisladamen-
te y focalizadamente que cuando hace falta que interactúen entre sí (es decir,
cuando es necesario que la información de salida que genera una de ellas sea tra-
tada como la entrada de otra) entonces es necesario traspasar los datos entre los
SI, a menudo después de haberlos transformado mediante un software específico
a modo de puente entre ambos productos (aunque también es cierto que la apari-
ción de estándares de intercambio de información –como el XML– ayudan cada
vez más a prescindir de tales puentes). Es decir, los sistemas no forman un todo,
ni están directamente integrados entre sí. Tradicionalmente, estos sistemas indi-
viduales suelen denominarse aplicaciones informáticas o aplicativos.
Desde hace más de dos décadas, en un intento por integrar los diferentes apli-
cativos (y las funcionalidades a las que responden) y evitar los puentes entre
ellos, ya disponemos de SI (productos) más complejos y globales con un ámbi-
to de acción muy amplio. Son los que denominaremos SI integrados (y que
también se conocen con nombres del estilo de soluciones integradas o paque-
tes integrados).
Los SI integrados se venden como modulares y adaptables a cada organización
que quiere utilizarlos. Acerca de esta adaptación al cliente (o parametrización o
“customización” como también se conoce) existe un negocio, un conjunto de
prácticas y un conjunto de teorías que encajan en la implantación de sistemas,
puesto que no se trata de desarrollo de software propiamente dicho, sino de la
adaptación de soluciones de software ya existentes, a partir de su ajuste al ámbi-
to de aplicación de la organización y de ponerlas en marcha (implantarlas) en
ese ámbito.
Estos SI, fruto de la evolución tecnológica y con independencia de si son SI
integrados o aplicativos, hoy por hoy pueden presentarse en diferentes formas:
software instalable a partir de un CD o de una descarga web, plataformas confi-

gurables residentes o no en la propia organización y accesibles remotamente...:
de aquí la nube en la que los hemos dibujado en la figura 1.
Todavía algo más: muchos de estos sistemas de software tenían inicialmente
una aplicación directa en uno de los tres niveles básicos de decisión (y acción)
de la figura 2: operacional, táctico o estratégico. Sin embargo, con el tiempo, y
fruto de la explosión tecnológica a la que nos hemos referido antes, muchos de
ellos abarcan más de un ámbito.
Por eso, aunque los catalogaremos a continuación atendiendo a los niveles
de decisión, ésta vuelve a no poder ser una clasificación tajante, sino un inten-
to de poner un poco de orden en la enumeración de etiquetas y tipos de SI. De
hecho, utilizaremos la versión simplificada de la clasificación: trataremos los
operacionales o transaccionales por un lado, y por el otro los decisionales ya que,
tácticos o estratégicos, comparten muchos aspectos conceptuales.
Atendiendo a esta división intentaremos ahora enumerar los tipos de SI
más comunes y las etiquetas (siglas, acrónimos, nombres) que se les asignan,
las cuales, una vez más, son numerosas, no siempre disjuntas y no siempre
bien definidas.
6.1. SI operacionales (o transaccionales)
El primer nivel de la figura 2 se basa en los SI operacionales. Su objeto es la

transacción (de aquí el segundo nombre de estos sistemas), es decir, el registro
de todas las actividades y acciones particulares y formales de la organiza-
ción con su entorno y dentro de sí misma. Toda compra, todo movimiento
bancario, toda factura, pero también toda orden de fabricación, toda planifica-
ción, toda asignación de recursos internos..., fruto de las actividades de la orga-
nización, suponen un intercambio y/o una generación de información: son
transacciones que hay que registrar detalladamente.2
Estas transacciones pueden implicar en un futuro nuevas transacciones (una
factura tendría que acabar en un cobro; una orden de fabricación tendría que aca-
bar con la llegada de un producto a un almacén...). Y, por otra parte, estas trans-
acciones, tal como veremos posteriormente, terminan por constituir, una vez
2. En el capítulo sobre bases de datos se ha hablado ampliamente y con detalle de las transacciones
de datos.
agregadas y visualizadas desde diferentes perspectivas, la base para la toma de

decisiones de nivel superior (es decir, son la materia prima de los SI decisionales).
Haremos un apunte, ahora sí, de las siglas más conocidas de estos SI opera-
cionales (y que corresponden, en realidad, a SI integrados):
• Los ERP (Enterprise Resource Planning) conceptualmente pretenden inte-
grar el tratamiento de todas las transacciones entre las diferentes actividades
internas de la organización (organizada en torno a lo que se conoce como los pro-
cesos de negocio en el contexto empresarial): adquisición, producción o suminis-
tro del servicio, distribución, facturación, contabilidad... Originalmente, pues, se
centran en el back-office, es decir, no están en contacto directo con los agentes
externos de la organización (clientes y proveedores, principalmente), aunque,
evidentemente, el origen primero y el destino último de muchos de los datos que
maneja están en transacción con el exterior. El fabricante más conocido de estos
sistemas es SAP. Pero entre las empresas fabricantes principales también está
Oracle (con Oracle Applications) o Microsoft (con el antiguo Navision, ahora ya
Microsoft Dymanics NAV para organizaciones medianas o Microsoft Dynamics
AX para grandes organizaciones).
• Los CRM (Customer Relationships Management) conceptualmente se
encargan del front-office con los clientes. A partir de esta interacción con los clien-
tes, tienen que mantener toda la información necesaria para conocer los intereses
potenciales de cada uno de ellos, sus preferencias de adquisición y su historial en
relación con la organización, con la finalidad de personalizar al máximo el servi-
cio que se le da. Dan apoyo, pues, a funcionalidades para el marketing (localiza-
ción e incorporación de nuevos clientes) y para el servicio posvenda (para la fide-
lización del cliente, la adecuación del servicio suministrado a su perfil o la identi-
ficación de futuros intereses de compra). Siebel de Oracle, Salesforce o Microsoft
Dynamics CRM son algunos de los fabricantes más conocidos.
• Los SCM (Supply Chain Management) se centran en todos los procesos
que van desde la adquisición de las materias primas a los proveedores, su
almacenamiento inicial, su distribución para el proceso de fabricación, su
transformación en los procesos productivos y su almacenaje como producto
final a punto para ser consumido por el cliente. Evidentemente en esta des-
cripción quedan claramente recogidas actividades de organizaciones dedica-
das a la producción de bienes, no tanto de servicios. Entre los fabricantes más
conocidos podemos mencionar Manugistics o SAP-SCM.
• Los SRM (Supplier Relationships Management) conceptualmente preten-
den ser el equivalente a los CRM, pero por el lado del proveedor. Aunque ya hay
algunos fabricantes que incorporan estas siglas (por ejemplo SAP-SRM), no son
todavía demasiado reconocidos y suelen ser una versión de los SCM orientada
a los proveedores y/o a organizaciones del sector de servicios (no tanto del sec-
tor de producción de bienes y artículos, como es el caso de los SCM).
Como hemos dicho, todas estas categorías son SI integrados. Inicialmente son
más caros que los aplicativos individuales (a pesar de que a medio y a largo plazo,
pueden no resultarlo tanto) y requieren un esfuerzo de inversión de tiempo y
dinero para su implantación, que muchas organizaciones pequeñas o sin grandes
recursos económicos no se pueden permitir. Sin embargo, con el tiempo están
apareciendo soluciones integradas dirigidas a estas organizaciones, bien desde la
propia industria formal –que se da cuenta de que no puede dejar escapar este
mercado–, pero también desde el terreno del software libre (como OpenERP o
OpenBravo).
En cualquier caso, antes de finalizar este apartado, tenemos que volver a
hablar de la laxitud actual de estas etiquetas: muchas de las soluciones exis-
tentes, a pesar de identificarse con una de ellas, la exceden tanto desde el
punto de vista de la actuación (por ejemplo, muchos ERP incluyen funciona-
lidades propias de los CRM o de los SCM) como de la decisión (tienen módu-
los que superan la gestión de transacciones y dan servicios de decisión tácti-
ca o estratégica).
6.2. SI decisionales (tácticos y estratégicos)
Como hemos dicho en el anterior apartado, las transacciones constituyen la

base sobre la que descansan los sistemas que dan apoyo a la toma de decisio-
nes de nivel superior (tácticos pero también estratégicos). Son la materia
prima. Por ejemplo, una transacción que recoge la compra X de un cliente Y de
una mercancía Z no nos permite sacar muchas conclusiones. Ahora bien, la suma
y el filtrado de la información contenida en cada una de las transacciones de este
tipo sí nos permitirá saber si Z se está vendiendo bien, si Y es un buen cliente o
si las compras de tipo X se han incrementado. Y nos ayudará a actuar en conse-
cuencia. Son su agregación y su transformación (empezando sencillamente a par-
tir de indicadores estadísticos básicos) las que dan una perspectiva de lo que sig-
nifican en conjunto y las que, en consecuencia, facilitan a los responsables la
toma de sus decisiones.
Sin embargo, debemos ser cautelosos porque las transacciones diarias son
muy numerosas y si no se agregan, si no se tratan o si no se presentan adecua-
damente, pueden producir un efecto de sobreinformación o, incluso, generar
información incorrecta que puede resultar perjudicial. Los sistemas decisiona-
les, pues, tienen que aplanar, cocinar, domesticar estos volúmenes de datos y
convertirlos en información útil.
En contraste con las tareas operativas transaccionales típicas, a menudo de
carácter manual, los procesos a partir del que se toman decisiones son tareas
intelectuales humanas mucho más complejas y difíciles de definir en toda su
extensión y detalle, y, consecuentemente, imposibles de automatizar comple-
tamente con un SI. Ante tal imposibilidad, lo que hace falta es potenciar la
actuación humana, apoyando su tarea de decisión. Eso es lo que pretenden
hacer los SI decisionales.
Existe un conjunto de tecnologías de software que está en el centro de todos
estos SI decisionales, como OLAP, datawharehouse, datamining o information
navigation. Junto con los diferentes tipos de SI decisionales, configuran la nube
en la que giran las soluciones llamadas de Business Intelligence (BI).
El BI se define como un conjunto de estrategias y herramientas que permite
gestionar y crear conocimiento mediante el análisis de los datos existentes en
una organización para dar apoyo a la toma de decisiones sobre el negocio. Una
solución BI completa permite: a) observar lo que está pasando; b) entender por
qué está pasando; c) predecir lo que pasará; d) ayudar a elaborar una propuesta
sobre lo que tendría que hacer el equipo; y e) ayudar a decidir qué camino debe
seguirse.
El mercado de BI es bastante maduro y entre las soluciones comerciales líde-
res en BI que incluyen, con más o menos extensión, los niveles táctico y estra-
tégico, tenemos IBM Cognos, Business Objects y las de Oracle y Microsoft. En
menor grado se encuentran Information Builders, MicroStrategy y las de SAP y
SAS.
Estas soluciones responden de una u otra manera a las clasificaciones con-
ceptuales de SI que presentamos a continuación. Decimos que las siguientes son
clasificaciones conceptuales porque no son universalmente utilizadas por la
industria para explicar o etiquetar sus productos:
SIATD o DSS (SI de Ayuda en la Toma de Decisiones o Decision Support

System)
Un SIATD es un SI decisional táctico que da apoyo a las decisiones de un
ámbito específico (elección de proveedores o inversiones, por ejemplo, o simu-
lación de escenarios), mediante funcionalidades que permiten a) facilitar el
acceso de los datos relevantes para la decisión concreta; b) ofrecer capacidad de
cálculo para estimaciones (mediante modelos estadísticos, de simulación, de
logística...); c) facilitar la presentación e interacción de los dos componentes
anteriores a partir de entornos gráficos y dinámicos.
SEG o MES (SI Experto para la Gestión o Management Expert System)

Un sistema experto es un sistema que, mediante la aplicación de mecanis-
mos de inteligencia artificial, está diseñado para proponer soluciones a proble-
mas de decisión en una situación o aspecto concreto y limitado, simulando
tareas humanas de razonamiento y deducción, recomendando opciones, pre-
sentando razonamientos y procurando igualar la eficacia de los expertos huma-
nos. Ejemplos de tipos de problemas a los que se han orientado tradicionalmen-
te los sistemas expertos son el diagnóstico de enfermedades o la detección y la
reparación de averías en todo tipo de sistemas.
Los SEG son sistemas expertos aplicados a problemas de gestión de organiza-
ciones. Son, básicamente, SI decisionales del ámbito táctico –las decisiones y la
pericia requeridas tienen que ser abarcables para el software y, en consecuencia,
tienen que seguir razonamientos suficientemente prefijables–.
SIE o EIS (SI para Ejecutivos o Executive Information System)

Un SIE es un SI decisional estratégico concebido para que los directivos de
una organización mejoren la calidad de su trabajo, en sus diferentes componen-
tes y en especial en el de decisión estratégica. Para ello: a) facilita el acceso a las
informaciones más relevantes, a menudo de tipo histórico; b) mejora la comu-
nicación de los directivos dentro de la propia organización tanto en sentido des-
cendente de autoridad como ascendente de responsabilidad; y c) permite una
mejor comprensión del entorno en la actividad de la organización. Un SIE, a
diferencia de un SEG o de un SIATD, tiene un ámbito de actuación más general
en la organización y no tan específico como el de aquellos.
No puede ser, pues, sólo un front-end amigable para que los directivos acce-
dan a la información interna de la organización: como hemos dicho, les tiene
que servir también para comunicarse con los demás. Por eso, no puede ser un
sistema aislado y para su uso particular. Ni tampoco –y decimos ahora una

obviedad– puede dirigir de forma informática la organización, ni sustituir al
propio directivo.
SI para BSC (Cuadro de Mando Integral o Balanced Scorecard)

El BSC es un modelo publicado por Kaplan y Norton en 1996 que permite
definir y monitorizar los objetivos concretos de una organización y de sus
diferentes áreas. El modelo ayuda a las organizaciones a transformar su estra-
tegia en resultados, disminuyendo el gap existente entre el plan estratégico
definido y el trabajo diario de las personas, es decir, dando apoyo a la gestión
de la estrategia de la organización.
Dado su éxito y su implantación en muchas organizaciones, han aparecido
muchas soluciones SI que responden a las exigencias del BSC relativas a la reco-
gida de datos, a su análisis y a la generación de informes. El modelo no es muy
complejo, y muchas organizaciones utilizan herramientas ofimáticas para su
gestión. Pero las que lo utilizan en diferentes niveles y necesitan la integración
de los resultados disponen de un buen recurso en estos SI de BSC.
6.3. Otros SI especializados
La separación entre SI decisionales y SI transaccionales ha sido suficiente

durante mucho tiempo. Ahora bien, la emergencia de nuevas posibilidades tec-
nológicas y de nuevas necesidades de trabajo y de organización ha llevado a la
aparición de SI que se escapan de esta clasificación. Así que una vez más, nos
detendremos un poco al margen del hilo argumental y presentaremos otros
tipos de SI de uso ya corriente, aunque no aparecerán en absoluto todos los que
este entorno en continua evolución está produciendo, proponiendo y proban-
do. También tenemos que volver a avisar de que las fronteras entre éstos a
menudo se superponen a las soluciones reales existentes en el mercado.
SI para el trabajo en equipo y la comunicación

Estos son sistemas que pretenden dar apoyo a los grupos de personas de la
propia organización en sus tareas de trabajo en equipo, de comunicación inter-
na y de difusión de información, incluso facilitando la interacción con otras
personas de otras organizaciones del entorno (en lo que hemos apuntado como
cadena de valor extendida: proveedores, clientes, administraciones públicas...).
Entre sus propósitos está el de aumentar la eficacia y la efectividad del traba-

jo que realizan personas a menudo alejadas física y temporalmente; pero tam-
bién el de aumentar el nivel de emotividad organizativa en beneficio del ambien-
te y de la motivación del trabajo conjunto. Por todo ello, incluyen entre otras
herramientas las de calendario/agenda, mensajería, compartición (y control de
versiones) de documentos, construcción colectiva de contenidos, comunicación
síncrona para reuniones entre personas alejadas (teleconferencias con vídeo y/o
audio y control remoto de ordenadores y escritorios), coordinación del trabajo
y toma de decisiones del grupo...
Entre las etiquetas comerciales que se dan en estos SI están las de groupware y
teamware. Para mencionar sólo algunas, se pueden incluir en este grupo las solu-
ciones Zimbra (originada en el mundo del software libre), Groove (de Microsoft)
o, incluso, un subconjunto de las utilidades de Google (Google Aps) que podrí-
an organizarse como un portal de trabajo en equipo.
SI para la Gestión del Conocimiento (ECM, KM)

En el primer apartado de este capítulo, al definir qué es un sistema de infor-
mación y representarlo en la figura 1, ya hemos hablado de conocimiento como
uno de sus elementos. Las teorías acerca del conocimiento lo consideran como
uno de los principales activos de las organizaciones: los procedimientos de tra-
bajo interno, el comportamiento de los clientes o de los proveedores, las condi-
ciones que se dan en el entorno... Todo este conocimiento, que se halla en la base
de las decisiones que se toman, es tan valioso que incluso se plantea su incorpo-
ración a los balances contables. Y su origen, pero sobre todo su retención, está
en las personas: sus comportamientos, sus acciones y su memoria. La dependen-
cia que las organizaciones pueden llegar a tener de estas personas es tan fuerte
que su desaparición –por cambio generacional o por problemas de contratación,
por ejemplo– puede llegar a significar la desaparición de la organización.
Además, hay muchas organizaciones cuya principal actividad es la generación y
la difusión de conocimiento, con lo cual éste se convierte en su producto y, como
tal, necesita poder ser gestionado.
Existen soluciones informáticas en torno a las siglas KM (Knowledge
Management, la etiqueta formal para hablar de gestión del conocimiento desde
todos los ámbitos) y más recientemente en torno a ECM (Enterprise Content
Management), que pretenden atender, en mayor o menor medida, a esta necesi-
dad de tener el conocimiento de una organización retenido o reflejado en algún
otro lugar a parte de las personas. Entre sus funcionalidades está la captura del
conocimiento (desde un escaneado a una grabación de audio, pasando por un

formulario manual de entrada de datos); el almacenaje seguro (con copias de
seguridad y réplica); la gestión y la difusión de estos documentos; la represen-
tación de los procesos de negocio y de la estructura de la organización; y el
seguimiento y la difusión de estos procesos y estructura.
Algunos SI que se comercializan bajo estas etiquetas son Documentum u
OpenKM. Pero hay una pequeña constelación de aplicaciones en torno a estos
conceptos. De hecho, para muchos autores, la gestión del conocimiento no se
hace todavía a partir de una solución informática única e integrada, sino a par-
tir de una estrategia de uso de diferentes funcionalidades y tecnologías disponi-
bles en cada momento.
Sistemas de Gestión de Contenidos (CMS) y mantenimiento de portales web

Con el objetivo principal de poner a disposición de terceros el conjunto de
información pública generada dentro de la propia organización, aparecen los sis-
temas de gestión de contenidos (Content Management Systems o CMS). La mane-
ra actual más natural de poner a disposición esta información es a partir de por-
tales web corporativos que incluyen desde la descripción de la organización, en
información comercial para clientes, hasta el acceso en su sistema de compra
electrónica.
La diferencia entre los CMS y los sistemas de KM/ECM es que los primeros se
consideran orientados a la difusión hacia el exterior de la organización de la
información pública que ella misma genera y necesita difundir, mientras que
los KM/ECM tienen que gestionar el conocimiento de la organización, conoci-
miento que en parte es público, pero en parte no (incluso puede llegar a ser casi
secreto). Sin embargo, es evidente que los puntos de contacto entre estas dos
tipologías son numerosos. De hecho, ECM acaba igual que empieza CMS... Y la
misma Wikipedia considera los CMS como una categoría de la que los ECM son
una subcategoría...
Vignette (ahora ya OpenText), MS-CMS o OpenCMS están entre las solucio-
nes CMS más utilizadas.
Para terminar, dejamos abierta una reflexión final sobre la incuestionable
importancia actual de los portales web: cuando un usuario de la banca electró-
nica o de una agencia de viajes web o de una universidad en línea se registra
en el sistema, adquiere un producto o un servicio, o contesta una encuesta de
satisfacción, está originando una interacción que, en cadena, activa un con-
junto de procesos internos en la organización que repercuten en su función de
comunicación, en su facturación y también en su conocimiento (todo eso

organizado en torno a los diferentes SI que hemos intentado explicar hasta
aquí). Y todo a partir de un “modesto” acceso web...: Entonces, ¿se merece este
acceso la consideración de simple portal, de sólo punto de entrada? ¿No des-
encadena todos los procesos nucleares? ¿No contribuye a la base de informa-
ción a partir de la cual se tomarán decisiones operativas, pero también, por
agregación, estratégicas? ¿Es, pues, sólo una aplicación más de un SI, o es una
de las aplicaciones clave de SI? O incluso, ¿no deberíamos considerarlo parte
del producto/servicio o el producto/servicio en sí mismo que ofrece la organiza-
ción?...
En definitiva, visto todo el catálogo expuesto, su alcance y la interrelación y
el solapamiento entre las diferentes soluciones, resulta difícil decir cuáles de los
SI descritos tienen mayor importancia o impacto en las organizaciones. Lo que
es incuestionable es que todos ellos son fundamentales para su funcionamiento
tanto operativo como táctico y estratégico.
7. Los roles profesionales de los SI
Una vez dada una definición de sistema de información, descrita su impor-

tancia y realizada una propuesta de clasificación y de catalogación, llega el
momento de enfocar nuestro relato hacia las personas que diseñan, hacen fun-
cionar y utilizan los SI. En este apartado intentaremos realizar una clasificación
de los roles de estas personas, tanto en la esfera directiva como en la funcional.
Una vez más, esta clasificación será discutible; pero esperamos que, desde un
punto de vista descriptivo, también sea útil.
7.1. Los roles de dirección y de gestión (de management) de los SI
Antes de entrar en los roles de management de los SI, planteamos una breve
discusión sobre el significado de “dirigir”. Nosotros nos acogemos a las defini-
ciones que indican que las funciones clásicas atribuidas a la dirección de cual-
quier área son:
a) Planificar: dibujar a largo, medio y (también) corto plazo el rumbo de su

área.
b) Organizar: diseñar la estructura y los procesos que atenderán a las necesi-
dades de su área.
c) Ejecutar: realizar acciones concretas atendiendo a la planificación (a) y sir-
viéndose de la organización (b) construida por su área.
d) Controlar: observar y analizar los resultados de las acciones ejecutadas (c)
y su desviación respecto a los resultados previstos para introducir los cam-
bios que afecten a (c) pero también a (b) y a (a).
Ello, como intenta reflejar la figura 7, básicamente significa que el directivo

no sólo se queda en el plano de las ideas y de las definiciones de la estrategia,
de los objetivos y del diseño (las funciones a y b), sino que también actúa direc-
tamente en las esferas de ejecución y de control (las funciones c y d).
Evidentemente, eso lo tiene que hacer desde su posición. Por ejemplo, no tiene
que encargarse de cerrar tratos de compras en general, pero sí tener en cuenta
que una compra concreta a un proveedor determinado (relevante en el momen-
to actual o futuro y con quien se quiere establecer una relación win-win a partir
de la que se abrirán otras puertas) puede ser terriblemente estratégica y posible-
mente requiera su implicación (aunque pueda parecer que abandona su posi-
ción privilegiada o que interfiere en un ámbito que no es el suyo). En definiti-
va, creemos que se puede decir que en la esfera de la dirección, lo verdadera-
mente estratégico es ejecutar en sentido estratégico.
Figura 7. Roles de la dirección

Por todo ello, las clasificaciones sobre los roles de management que plantea-
mos a continuación pretenden sólo facilitar la explicación. Las presentamos por
separado, pero en ningún caso queremos decir que los roles tengan que ser ejer-
cidos cartesianamente por personas diferentes, o que un rol no interfiera en el
otro. No pretendemos realizar una división clasista de los roles (un director estra-
tégico frente a un jefe de proyecto o frente a un jefe de área funcional). Con lo que
hemos dicho en el párrafo anterior, queda claro que cualquier director tiene que
bajar a la ejecución en algún momento y que su acción estratégica en temas con-
cretos (y también su ejemplo) son claves en el funcionamiento real de su área.
Hecha esta aclaración, pasamos a explicar los roles de management de SI.
Hemos dicho en la presentación de este capítulo que para conceptualizar, organi-
zar y gestionar los SI y sus TI, hace falta una función clara de dirección y gestión.
Pero ¿cuáles son exactamente estas funciones? ¿Quién las tiene que ejecutar? ¿Y
bajo qué etiqueta identificamos estos roles?
7.1.1. El CIO
Volvemos de nuevo a la figura 2, es decir, a la pirámide que clasificaba las

decisiones que se toman en una organización en los tres niveles: estratégico,
táctico y operativo. La función informática en una organización se estructura en
torno a un grupo de personas (que pueden configurar lo que describiremos más
adelante como departamento de SI), que podemos considerar una pequeña
organización en sí misma y donde, por lo tanto, las decisiones que se toman son
también de los tres niveles mencionados: estratégico, táctico y operativo.
Las decisiones estratégicas de SI son aquellas que resultan críticas para el
negocio o que influyen de una manera determinante sobre las operaciones o
sobre la estrategia de la empresa (recordad la matriz de McFarlan y McKenney de
la figura 5). Normalmente implican volúmenes económicos muy significativos y
con consecuencias relevantes en el balance y en la cuenta de resultados. Como
decíamos en el apartado 2, tendrían que tender, pues, hacia la alineación estra-
tégica con la organización. ¿Qué nombre es uno de los más aceptados por las per-
sonas que desarrollan este rol de director estratégico de SI? El de CIO o Chief
Information Officer.
En la tabla 2 detallamos un posible listado de estas acciones y decisiones de
dirección estratégica, que incluyen según las cuatro funciones básicas de la direc-
ción que comentábamos más arriba.
El CIO, además de transmitir estas decisiones a los que dependen de él, tam-
bién las tiene que comunicar y compartir con la alta dirección de la organiza-
ción. Y, a menudo, tienen que ser tomadas en el marco de la dirección general
de la organización (el consejo de administración, el comité de dirección o la
forma que adopte la cúpula directiva). De hecho, muchas organizaciones ya han
entendido que tienen que incluir a los CIO en este consejo de administración
(junto con el director general, el jefe de marketing, el jefe de finanzas o el jefe
de personal, entre otros) y no sólo invitarlo puntualmente a presentar sus pro-
puestas. Es posiblemente una de las mejores formas de facilitar la alineación
estratégica.
Tabla 2. Un posible listado de acciones y decisiones de dirección estratégica
• Realizar prospectiva, analizar y apostar por las innovaciones tecnológicas emergentes con posibilidades
futuras a medio o largo plazo.
• Determinar el portfolio (o cartera) de proyectos de TI para asegurar su ejecución y su impacto.
• Potenciar nuevos negocios, nuevos modelos de gestión interna y nuevos modelos de relación entre
clientes y proveedores, basados en las TI.
• Descubrir las necesidades reales de información y de SI (SI en cursiva, es decir, de soluciones software
para atender a estas necesidades de información), descartando los apriorismos sobre necesidades de
información y SI que nadie en la organización puede justificar realmente. Ello es vital tanto al afrontar la
construcción de un SI nuevo –por un acontecimiento singular y único, por ejemplo, dónde hay que evi-
tar inversiones inútiles–, como al rediseñar un SI existente –para incrementar su eficiencia global–.
• Estructurar la función informática de la organización y, en especial, las decisiones sobre las funciones
que se mantienen internamente y las que se suministran externamente (mediante políticas de outsour-
cing, subcontratación, externalización...).
• Potenciar los negocios actuales, mejorando e innovando los procesos de gestión y el acceso a los mer-
cados.
• Fijar los criterios y decidir acerca del nivel de servicio, la seguridad, la privacidad y la protección de
la información.
• Priorizar las decisiones de inversión en TI.
• Garantizar que se reconozcan y aprovechen las oportunidades que las TI ofrecen a la organización.
Lo que es imprescindible es que la organización y la dirección estratégica de

SI tengan un marco de interacción muy claro. Y para ello es vital luchar para
asegurar la comprensión, un enfoque y un lenguaje común con los demás altos
directivos (que lideran, de hecho, las áreas clientes del departamento de SI). En
materia de informática, tanto o más que en otras áreas funcionales, se ha des-
arrollado un argot propio de tecnólogos (vendedores y compradores de tecno-
logía, en realidad) totalmente alejado del lenguaje de los otros directivos (es
decir, ¡de los clientes!), argot que no ayuda para nada a este lenguaje común.
Además, habitualmente los directivos no tienen ni la formación (hasta hace

poco a los MBA no se les enseñaba casi nada al respecto) ni la experiencia para
mantener un diálogo fluido con el CIO. Y ello aunque tengan que entender qué
es lo que la tecnología puede hacer en cada momento y qué relación puede esta-
blecerse entre el impacto de esta tecnología y su coste. La creación de este
ambiente transparente y abierto, de confianza y comunicación con los usua-
rios/clientes (el “apostolado” del papel de los SI, en definitiva) es quizás en este
momento una de las tareas más importantes de una dirección de SI realmente
estratégica, como dice Earl.
El CIO, pues, tiene que ser el principal contribuidor a la conceptualización
de la estrategia de SI y de las TI que le darán apoyo. Pero una vez hecho eso, es
necesario que establezca los mecanismos para implementarla, mediante accio-
nes coordinables y dirigidas, convirtiendo en planes concretos los objetivos y
las directrices de la cúpula. Es decir, hace falta que tome decisiones de gestión
estratégica o de planificación estratégica de SI. Un catálogo de estos tipos de
decisiones podría ser el que resumimos en la tabla 3.
Tabla 3. Un posible listado de acciones y decisiones de gestión o planificación estratégica
• Transformar las estrategias de SI en proyectos específicos, viables (en términos de capacidades

cuantitativas y cualitativas de ejecución) y realistas (en términos de riesgos); dotarlas de recursos ade-
cuados; y monitorizar su ejecución.
• Establecer y ensayar estrategias de implantación y planes de transición en los diferentes proyectos.
Priorizar las decisiones de inversión en TI.
• Asegurar la consistencia entre la estrategia de SI y las operaciones y los proyectos derivados (la
estructura del portfolio y la tecnología que le tiene que prestar apoyo).
• Asegurar la venta interna de los proyectos de TI, el compromiso y el liderazgo compartido de los
directivos principales y la implicación de la dirección general cuando haga falta.
• Establecer mecanismos para revisar y refinar los planes, a partir de un diálogo fluido con los res-
ponsables de la organización.
La gestión estratégica de los SI se concreta en la creación de un plan estra-

tégico de SI/TI (por eso también se conoce la gestión estratégica como planifi-
cación estratégica). El proceso de elaboración de este plan, por sí mismo, favore-
ce este diálogo con el consejo de administración que comentábamos más arri-
ba y tiene un valor pedagógico para todas las partes.
La elaboración del plan estratégico de SI tendría que ser un proceso realiza-
do con mucho esmero y con un resultado suficientemente genérico como para
ser muy estable, es decir, como para que no haya que rehacerlo de nuevo tan
pronto como se produzca un mínimo cambio. En realidad, durante la ejecución
del plan estratégico es habitual entrar en un proceso de adaptación y refina-

miento, debido a:
• Cambios en el entorno.
• Cambios en las prioridades del negocio.
• Ajuste a las condiciones reales del día a día.
• Y porque, en definitiva, las grandes decisiones y proyectos de SI se ejecu-
tan durante largos periodos y son relativamente estables, mientras que las
demandas del negocio son más cambiantes y, a menudo, más espasmódi-
cas.
Sin embargo, eso no invalida la necesidad de este plan, sino que reclama que
el plan:
• Disponga de mecanismos previstos de ajuste y autocorrección que asegu-
ren su consistencia, pero también la aplicación de buenas dosis de realis-
mo, sentido común, creatividad, innovación, oportunismo y pensamiento
informal, como apuntan Ward y Peppard;
• Refleje lo mejor posible, lo que son las necesidades más permanentes, los
temas de fondo (que normalmente coinciden con los procesos nucleares
del negocio). Con ello, durante su desarrollo se pueden producir cambios
de velocidad en algunos proyectos o de énfasis en algunas orientaciones,
pero no un gran cambio en su contenido u orientación principal.
7.1.2 El jefe de proyecto
El plan estratégico tiene un resultado muy tangible: un portfolio o cartera de

proyectos de TI que debe dirigirse y gestionarse individualmente. Y de ello se
encarga el segundo rol sobre el que queremos detenernos: el del gerente o jefe de
proyecto.
Volvemos a la figura 2. ¿En qué nivel se hallan las decisiones del jefe de
proyecto? Pues normalmente, tanto en la esfera táctica como en la operati-
va, puesto que, por una parte elaboran los planes de proyecto (táctica) y por
otra los implementan hasta alcanzar sus objetivos (operativa). Ahora bien,
no hay que descartar, como hemos dicho más arriba, que haya proyectos que
puedan ser estratégicos (vitales para la implementación de la estrategia de la
que el CIO es responsable y donde éste se puede querer implicar directamen-
te).
El rol de gestor de proyectos no es exclusivo del ámbito de SI. Pero la dis-

ciplina de la gestión de proyectos ayuda mucho al todavía poco maduro
terreno de los proyectos TI (sobre todo los de desarrollo de software), ya que
proporciona un método general para abordar cualquier tipo de proyecto.
Demos, pues, una ojeada a las generalidades de esta disciplina.
Un proyecto es:
• un conjunto de actividades...
• ...desarrolladas durante un tiempo...
• ...por un conjunto de personas...
• ...con un presupuesto económico determinado...
• ...para obtener un producto, un servicio o un resultado único.
De aquí tenemos que extraer que la temporalidad, la elaboración progre-

siva y la creación de un resultado único es lo que distingue al proyecto de las
operaciones ordinarias de la organización.
Además, todo proyecto tiene un cliente y un nivel esperado y detallado de
calidad del resultado. Alcance, calidad (funcionalidades del resultado y ade-
cuación a los requisitos del cliente), duración y presupuesto son las cuatro
magnitudes sobre las que el jefe de proyecto tendrá que dar explicacio-
nes y, por lo tanto, son magnitudes que tiene que controlar y saber dominar,
puesto que él es el responsable último del éxito o del fracaso del proyecto,
tanto desde un punto de vista técnico como económico.
La gestión de proyectos es una disciplina muy amplia y compleja, que
incluye diferentes áreas de conocimiento experto: las propias de la gestión de
proyectos, las del área técnica, funcional o sectorial en la que se desarrolla el
trabajo y las de la gestión de organizaciones y de las relacionas interpersona-
les. El PMBoK (Project Management Body of Knowledge o Cuerpo de Conocimiento
de la Gestión de Proyectos) es el estándar de facto de gestión de proyectos reco-
nocido internacionalmente que aborda esta amplitud. Se aplica en todo tipo
de sectores y de ámbitos técnicos, incluidas las industrias de TI.
Este cuerpo de conocimiento pretende ayudar a:
a) Que los proyectos se completen satisfactoriamente y consigan sus resul-
tados últimos, únicos y esperados.
b) Predecir y controlar la evolución del proyecto, responder a los cambios
y explicarlos satisfactoriamente a los clientes (y al propio equipo).
Es bien sabido que muchos proyectos fallan.3 Es decir, que no cumplen algu-
nas o todas las magnitudes que mencionábamos más arriba. Pero en muchos
casos ello es debido a una gestión inadecuada más que a un producto que no
funciona. Entre las causas hay algunas clásicas: 1) la falta de participación y de
compromiso entre el cliente y los usuarios, 2) la falta de apoyo desde la direc-
ción, y 3) la falta de una definición clara de los objetivos y del alcance del pro-
yecto. Por ello, la gestión de proyectos y el rol de jefe de proyectos son tan
importantes.
Para finalizar este apartado sobre los roles en el management de los SI y enla-
zando con los temas de la formación necesaria para desarrollarlos, proponemos
ahora una pequeña reflexión sobre el origen de estos profesionales.
¿Tienen que ser informáticos los que estén al frente de las tareas de
management? El profesional ideal debería tener un gran conocimiento de las
tecnologías, pero también claras habilidades para la participación activa en el
mando de la organización o, por lo menos, de una parte fundamental de ésta.
Este perfil híbrido, junto con la habitual inclinación hacia la tecnología de la
mayoría de los profesionales informáticos, explican por qué, a menudo, estas
responsabilidades han recaído en profesionales formados principalmente en
gestión y dirección de empresas, con más o menos conocimientos sobre la tec-
nología y sus posibilidades. El perfil opuesto, el del ingeniero tecnólogo con
más o menos conocimientos sobre gestión y dirección, se ha ido incorporando
posteriormente.
Así pues, habría que apostar por un profesional que haya recibido una for-
mación que integre indisolublemente, como mínimo, ambas disciplinas. Es lo
que, siguiendo los currículos universitarios propuestos por la ACM, ya empie-
za a aparecer en algunas facultades como las especialidades de a) Sistemas de
Información (para la vertiente de dirección) y b) Tecnologías de la Información
(para la vertiente de gestión técnica). Además de estas especialidades, está
emergiendo también la Ingeniería de Servicios y Sistemas de Información (con
esta misma denominación u otras parecidas) que, conceptualmente, ya integra
desde buen principio las perspectivas tecnológicas y de management, entrela-
zándolas para formar un profesional híbrido (y rehuyendo así al profesional
formado básicamente en uno de los dos ámbitos y con conocimientos del
otro).
3. En el Standish Report que se publica anualmente se pueden encontrar datos detallados.

Aún una breve reflexión final. Como decíamos, muchos profesionales infor-
máticos –una vez fuera de las escuelas donde los han formado muy técnicamen-
te– no se sienten atraídos inicialmente por este tipo de responsabilidades. Pero
a menudo, una trayectoria profesional estable y dilatada en el tiempo dentro de
una organización acaba llevando al profesional informático a estas responsabi-
lidades o a que, como mínimo, se las ofrezcan. ¿Cuántos jefes de proyecto no
han sido antes programadores o instaladores de redes? ¿Y cuántos CIO no han
sido antes jefes de proyecto?
7.2. Los roles para la gestión funcional de los SI
En el apartado anterior hemos visto cuáles son las funciones de dirección y

gestión de SI y los roles que las ejecutan. Es evidente que los CIO y los jefes de
proyecto no trabajan solos, sino que dirigen y coordinan un equipo diverso que
participa en diferentes proyectos y/o que tiene tareas concretas longitudinales
en el tiempo. Los miembros de este equipo están implicados con lo que pode-
mos clasificar como la gestión funcional de los SI. Pero volvemos a insistir en que
la función directiva en algún momento determinado y justificado puede actuar
directamente en la gestión funcional; y, de hecho, la gestión funcional también
contribuye a la acción directiva, ya que algunos de sus miembros tienen que
compartir periódicamente con los CIO y los jefes de proyecto su visión más cer-
cana al funcionamiento diario, visión que tiene que influir en las decisiones de
aquéllos. Es decir, una vez más, los roles de management y los roles funcionales
no son compartimentos estancos.
Los roles funcionales se caracterizan por estar relacionados con respon-
sabilidades técnicas. Estas responsabilidades podemos considerarlas concep-
tualmente organizadas, como mínimo, en torno a las siguientes áreas de actua-
ción (y la siguiente vuelve a ser una clasificación que no pretende ser incuestio-
nable):
Área de desarrollo y mantenimiento de SI

En esta área se “construyen” y “mantienen” (amplían, actualizan o corrigen)
los SI (otra vez en cursiva, es decir, entendidos como la parte de software de apli-
cación de las TI).
Básicamente, las tareas del área relacionadas con el desarrollo (o “construc-
ción”) de SI incluyen proyectos de los tipos siguientes:
• Proyectos de creación de nuevos SI (desarrollo de software o implantación

de SI integrados), que hay que encajar con los que ya existen.
• Proyectos de adaptación de SI preexistentes a las necesidades cambiantes de
las áreas funcionales que los acogen.
• Proyectos de renovación de la cartera de SI cuando, por razones funciona-
les o tecnológicas, los SI están a punto de llegar al final de su vida útil y
pueden pasar a dar muchos más problemas que beneficios. En este punto,
las áreas de desarrollo se suelen mover entre el dilema de hacer duraderos
los SI para que éstos sean rentables, retrasando la incorporación de nuevas
TI más ventajosas, o precipitar la renovación de SI, desperdiciando inver-
siones importantes ya efectuadas.
Las tareas del área relacionadas con el mantenimiento de SI ocupan una alta
proporción de la dedicación de esta área. La convivencia en la misma área del
desarrollo y el mantenimiento permite disponer de una visión completa de los
problemas y de las posibilidades de los SI y también tener cerca, para hacerse
cargo del mantenimiento, a los equipos que participaron en el desarrollo del
proyecto.
Las actividades relacionadas con el desarrollo y el mantenimiento de SI
requieren un alto componente de creatividad orientada al negocio o actividad
de la organización, tanto si hablamos de roles de analista como de programador
(en los capítulos dedicados a ingeniería del software, programación y gestión de
datos, ya hemos tratado detalladamente estos perfiles). En cualquier caso,
requieren unos profesionales que sepan sacar el máximo partido de los usuarios
de SI (de todos los ámbitos de la organización y de todos los niveles de respon-
sabilidad), cuya colaboración es fundamental para el buen funcionamiento de
estas actividades. Se trata de un trabajo que normalmente se hace en equipo,
muy estructurado y lleno de detalles, en el que son importantes los aspectos de
administración del trabajo, de comunicación interpersonal y de liderazgo y que
requiere una visión global de las dimensionas técnica, funcional y de negocio.
Área de operaciones, producción o explotación

Esta área es la responsable del funcionamiento (operación, producción) coti-
diano de los SI en uso (en explotación) y del control de los recursos de hardwa-
re e infraestructuras de las TI. Asegura la continuidad del servicio que presta la
función informática a la organización, es decir, de ella depende el día a día de
la actividad de la organización y cualquier incidencia puede dejar a muchos
usuarios de todos los ámbitos sin posibilidad de realizar su trabajo. Así, esta
área depende muy estrechamente de la calidad de los SI en funcionamiento que
se han producido en el área de desarrollo.
Podemos agrupar los elementos que gestiona en:
a) Equipamientos de hardware: desde los grandes ordenadores centralizados
(mainframe) y servidores de aplicaciones hasta los ordenadores personales
de despacho y portátiles, pasando por los miniordenadores y todo tipo de
periféricos (impresoras, pantallas, lectores...). Estos elementos se suelen
encontrar combinados y conectados en red, y el área de producción es res-
ponsable de su buen funcionamiento conjunto.
b) Entornos de producción y de desarrollo: con la finalidad de que convivan sin
interferencias destacables las actividades de explotación de los SI en uso
con las actividades de desarrollo de nuevos SI, normalmente las organiza-
ciones disponen de un entorno de producción (el real, donde se ejecutan
los SI en uso) y de un entorno de desarrollo (donde el personal del área de
desarrollo y mantenimiento realiza sus tareas con el software en desarrollo
hasta que lo da por finalizado y se tiene que incorporar nuevamente a pro-
ducción).
c) Recursos técnicos lógicos: incluyen el control y aseguramiento de la capaci-
dad de procesamiento, de la utilización de la memoria central, de la capa-
cidad de almacenamiento y de las comunicaciones.
d) Procedimientos de explotación: nos referimos aquí a los procesos informáti-
cos preprogramados que el área de producción tiene que ejecutar periódi-
camente, o bajo determinadas circunstancias, para cubrir la operativa de
los SI. Ponemos dos ejemplos: a) en el ámbito de las aplicaciones, las
actualizaciones por lotes o las integraciones masivas de datos; y b) en el
ámbito de soporte: la puesta en marcha y el paro de procesos de seguridad
o de actualización de software de base, la programación temporal de pro-
cesos de migración de datos, o las copias de seguridad.
Las actividades del área de producción a menudo se han asociado a la ejecu-

ción de tareas repetitivas y sencillas y, en consecuencia, a las de los profesiona-
les informáticos de calificación más baja. De hecho, es cierto que con el nivel
de automatización que permiten el hardware y el software de base actual en rela-
ción con su operación, la simplificación de estas tareas es notable. Ahora bien,
también es necesaria una especialización técnica importante (como mínimo la
descrita en los capítulos de Arquitectura de sistemas informáticos, Redes de
comunicaciones y Gestión de datos) y un contacto directo con usuarios, a

menudo en momentos críticos de caída del nivel de servicio. Este contexto
requiere una actitud positiva y buena capacidad de comunicación; unos niveles
de exigencia y de rigor altos en el control del uso de los recursos; y una capaci-
dad de gestión elevada del gran número y diversidad de elementos tratados (que
a menudo derivan también en complejidades logísticas si la organización está
distribuida geográficamente).
Área técnica de sistemas

Está especializada en el estudio, la selección, la puesta en marcha y el man-
tenimiento de todas las nuevas TI (que no son SI: hardware, infraestructura y
software de base) que se utilizan en la organización y en particular del software
de base (los SGBD, los sistemas operativos, etc.). Es decir, a partir de un trabajo
claro de prospectiva tecnológica propone evoluciones de las TI de hardware,
infraestructura y software de base utilizados en cada momento.
Es bastante peculiar en cuanto a su gestión, ya que se encuentra muy deter-
minada por sus características técnicas y por su función de apoyo y servicio a
las otras dos áreas: el área de operaciones y el área de desarrollo y mantenimien-
to de SI. De hecho, entre los “servicios” que les presta está el de evaluar si los
procedimientos de explotación de la primera, y el software desarrollado por la
segunda, son optimizables con las evolucionas tecnológicas que aparecen en el
mercado. En el mismo sentido, también ejerce a menudo un papel de arbitraje
ante conflictos entre producción y desarrollo.
Tradicionalmente, el área técnica de sistemas se encarga también del trabajo
en otros ámbitos más transversales en el departamento y en la organización (a
pesar de que actualmente, teniendo en cuenta la relevancia de estos ámbitos
transversales, muchas organizaciones ya han creado otras áreas funcionales para
atenderlos). Entre estos ámbitos mencionamos dos muy relevantes:
– Administración y gestión de datos: trata de responsabilizarse del recurso
“información” de la organización, considerándolo desde una perspectiva
global (es decir, integrándolo en un todo y salvando la fragmentación a la
que está sometido por la separación departamental), asegurando su uso y
entendiendo su consideración de activo fundamental, su importancia
estratégica (como base a SI decisionales) y las posibilidades que abre en
cada momento a la organización. En consecuencia, se trata de asegurar los
tres niveles en los que se apoya el recurso “información”: el físico (el deri-
vado del uso de un SGBD concreto), el lógico (la visión parcial que del
modelo general de información tienen los diferentes usuarios) y el corpo-

rativo (la definición del modelo general de información de la organiza-
ción). Está claramente ligado, pues, a la función de organización del SI glo-
bal (diseño y análisis de la información que necesita la organización y que
hemos atribuido más arriba al CIO) e, incluso, a la implementación de la
gestión del conocimiento (que hemos mencionado al catalogar los SI).
– Administración y gestión de la seguridad: trata de responsabilizarse de la
seguridad de las TI, con especial dedicación a las de infraestructuras y al
hardware. Ello incluye también el control de acceso a todas las instalacio-
nes informáticas, especialmente a las centrales o a las que son más críticas,
y la seguridad lógica, es decir, a restringir los accesos al recurso “informa-
ción” y a los SI que la pueden manipular.
En el perfil individual del profesional del área técnica de sistemas, la dimen-

sión tecnológica tiene mucha importancia. Globalmente, se necesitan más per-
files de calificación elevada que de bajo nivel, como programadores de sistemas
(ya que hay pocos desarrollos o mantenimiento de elementos de software de
base, incluso en el caso de que la organización utilice software libre). Esta califi-
cación elevada le tiene que dar capacidades de evaluación de prioridades y de
análisis a largo plazo; de trabajo continuado en un entorno en el que deben rea-
lizarse muchas tareas diferentes a la vez; de trabajo en equipos pluridisciplina-
res; de autogestión temporal y de flexibilidad y empatía en la asunción de las
necesidades que le plantean las otras dos áreas.
Para finalizar este apartado sobre los perfiles para la gestión funcional, debe-
mos recordar, cómo hemos ido diciendo, que las responsabilidades y tareas téc-
nicas que desarrollan4 ya han sido comentadas sobradamente en todos los capí-
tulos precedentes: ingeniería del software, programación y gestión de datos por
la parte de software; arquitectura de sistemas informáticos y redes de comunica-
ciones por la parte de hardware. Es decir, parece natural que los diferentes pro-
fesionales especialistas en cada ámbito acaben desarrollando el rol que les
corresponda en su área técnica de un departamento de SI. Pero no hay que olvi-
dar que alguien tiene que ocupar los roles de management, y los candidatos, evi-
dentemente, pueden tener su origen en cualquiera de estas diferentes áreas.
4. A pesar de no ser el único marco de referencia, ITIL es un conjunto de conceptos y buenas prác-
ticas en torno a los servicios, el desarrollo y las operaciones de SI ampliamente utilizado en la ges-
tión funcional y que refleja estas responsabilidades y tareas técnicas.
8. La estructura y la organización del departamento de SI
Todos los roles que hemos explicado en los anteriores apartados se organizan
habitualmente, como hemos ido apuntando, dentro del departamento de SI. Los
nombres que recibe este departamento son muy variados: de sistemas, de SI/TI, de
TI, de TIC... Nosotros utilizaremos el de “Departamento de SI”, puesto que es el
concepto que da nombre a este capítulo, pero todos los demás son igualmente
corrientes en todo tipo de organizaciones.
Tradicionalmente, los departamentos de SI se encargaban principalmente de
los aspectos de gestión funcional que hemos visto (adquisición, desarrollo,
mantenimiento, integración de TI en la organización, así como de la gestión de
todos los recursos necesarios para conseguirlo, incluidos los recursos humanos).
A medida que las organizaciones han ido incorporando los roles de management
de SI (el CIO y los jefes de proyecto), éstos también han quedado incluidos en
la jerarquía del departamento de SI.
Los departamentos de SI han adoptado a lo largo del tiempo diversas for-
mas y posicionamientos en las estructuras organizativas, como resultado
tanto de la evolución histórica de la propia función de SI en la organización
(recordad la figura 7) como de situaciones circunstanciales y de presión de la
cultura corporativa, entre otras posibles razones. Además, las diversas formas
y posicionamientos pueden ser más o menos apropiados para una organiza-
ción determinada en un momento concreto de su historia y no serlo en otro
momento.
La discusión sobre la forma del organigrama del departamento de SI
(jerárquico, funcional, matricial) no es muy diferente a la que se aplica a
otros departamentos de una organización y necesita considerar las motivacio-
nes, las ventajas y los inconvenientes de cada uno. La discusión que sí conside-
ramos muy relevante y específica trata sobre la distribución del SI (y de las
TI que le dan apoyo) en la organización y su nivel de descentralización (o
centralización). Ésta es antigua, no es obvia y puede condicionar claramente el
organigrama del departamento de SI. No hay un modelo ideal y cada organiza-
ción tiene que encontrar el suyo.
¿Qué aspectos pueden influir en el modelo del departamento de SI? Algunos
pueden ser:
– La propia filosofía estructural de la organización, es decir, el nivel de
dependencia y centralización que tienen los demás departamentos o uni-
dades de negocio. Los departamentos de SI pueden emular la lógica de los

otros departamentos.
– La cartera de negocios y su tipología: la dispersión geográfica de los clien-
tes o la dispersión técnica de los proyectos y su nivel de criticidad puede
facilitar una tendencia a modelos más descentralizados.
– La dispersión geográfica de la organización y el nivel de autonomía de sus
diferentes unidades geográficas, en especial en compañías globales o globa-
lizadas.
– El nivel de servicio o mantenimiento que requieran los sistemas.
– El nivel de estandarización de las plataformas, en particular la utilización
de soluciones integradas (ERP, CRM, CMS...) mantenidas por proveedores
externos.
– Hasta qué punto necesita ser compartida la información crítica para el
negocio y hasta qué punto se pone al alcance de los agentes externos
(clientes, proveedores, socios...).
Si el departamento de SI puede ser centralizado o descentralizado, su

función informática también. Algunos procesos de la cadena de valor se pue-
den mantener centralizados (la planificación o la definición de las arquitecturas
de información y tecnología, por ejemplo), mientras que otros se pueden des-
centralizar (la gestión de la infraestructura de operaciones, por ejemplo). En
líneas generales:
– La función informática centralizada facilita la integración, la integridad y
la calidad de la información y la estandarización de la tecnología, y tendría
que permitir gestionar mejor los recursos y las capacidades críticas y, por lo
tanto, los costes.
– La función informática descentralizada facilita que las diferentes unidades y
directivos funcionales tengan un sentido de propiedad y un compromiso
con las oportunidades y los costes de la informática y puede permitir una
respuesta más rápida, fresca y adaptada a las necesidades de las unidades.
En la práctica, y a partir de cierto volumen, se produce cierta combinación

de procesos centralizados y de otros descentralizados. Lo importante es la deci-
sión de qué recursos y qué capacidades críticas deseamos liderar y mantener de
manera central y según qué criterios.
Como una evolución natural de la distribución de la función informática y
del departamento de SI que lo acoge, aparece la posibilidad de contratar en el
exterior –fuera de la propia organización, a una tercera empresa– puntualmen-

te o permanente para uno o más procesos de la cadena de valor del SI. Es lo que
se llama provisión externa de servicios, externalización o outsourcing.
Podemos definir la externalización como la delegación a un proveedor exter-
no de la totalidad o de una parte de los recursos (técnicos, humanos) del SI,
incluidas las responsabilidades de gestión, mediante un contrato.
La subcontratación de trabajos en el exterior ha sido habitual en los departa-
mentos de SI para atender cargas de trabajo adicionales o tareas especializadas
que no se podían realizar puntualmente con recursos propios. Es una etapa nor-
malmente previa a la externalizació, en la que además de las tareas concretas,
también se cede la responsabilidad de éstas, como hemos dicho.
Muchas organizaciones llegan al outsourcing tras intentar mantener departa-
mentos de SI con bastante capacidad tecnológica. La imposibilidad o el coste de
hacerlo dada la velocidad de la evolución tecnológica, puede acabar llevando a
la organización a decidir deshacerse de estos recursos en una primera etapa de
venta al exterior (a la empresa que les proveerá el servicio a partir de aquel
momento) o sencillamente de eliminación. En una segunda etapa, la contratación
externa de los servicios se convierte en la forma de funcionamiento normal del
departamento de SI. De alguna manera se intenta hacer como con otros servi-
cios de menor valor añadido de la organización –limpieza, seguridad, manteni-
miento de instalaciones, servicios de restauración para los trabajadores... –, aun-
que es evidente que los servicios informáticos son mucho más complejos y no
pueden tratarse con tanta facilidad. Muchas organizaciones modernas han ido
directamente a esta segunda etapa, es decir, no han tenido departamentos de SI
tecnológicamente potentes en algunos ámbitos sino que siempre han confiado
en la provisión externa.
Este componente de transferencia de responsabilidad en el proveedor del ser-
vicio; la complejidad, la fluidez y la interrelación de las tareas que comprende
el acuerdo entre las dos partes; el impacto sobre el negocio y sobre la organiza-
ción del SI y las TI asociadas; la duración y la voluntad de continuidad de los
contratos, los costes de salida o de cambio de proveedor; y, en resumidas cuen-
tas, la naturaleza de la relación, hacen que la externalización sea mucho más
que un contrato y que se parezca mucho más a una alianza estratégica. Como
indica McFarlan, la externalización se parece al matrimonio: es relativamente
fácil entrar, pero es mucho más difícil mantenerlo o, incluso, romperlo.
El negocio de la externalización ha experimentado una explosión importante
en los últimos años y también ha ido madurando. Se ha aprendido, por ejemplo,
a partir de grandes casos de fracaso, que las organizaciones que externalizan no

pueden olvidarse de lo que adquieren fuera, y que hace falta que lideren y contro-
len el proceso de suministro del servicio en todas sus etapas. La incorporación de
nuevos sectores industriales (por ejemplo, el sector público), la extensión a activi-
dades de TI de mayor valor añadido (no sólo la producción de software o la insta-
lación de infraestructuras, sino también las de análisis) y la invención de nuevos
modelos de gestión (contratos de más riesgo, contratos a demanda, etc.) son sig-
nos de que el aprovisionamiento externo de servicios de TI todavía tiene mucho
camino por recorrer y muchas lecciones por aprender.
En esta línea de adquisición externa, no querríamos acabar sin hacer referen-
cia a dos servicios habituales en la profesión informática en torno a los SI. Los
esbozamos a partir de las ideas de Gil:
Consultoría de SI
Intenta hacer frente a la velocidad de las transformaciones tecnológicas y al
incremento de la dificultad y la complejidad de los problemas, sirviendo allí
donde el propio departamento de sistemas no puede llegar. El consultor de SI
debería ser un profesional altamente cualificado, que combinara formación y
experiencia, lo que hace difícil su localización e incorporación permanente en
la organización. Las empresas consultoras permiten la contratación temporal de
equipos profesionales (en principio) altamente especializados en aspectos técni-
cos pero también organizativos. Podríamos decir que intentan dar un servicio
de valor añadido que supera el suministro de servicio informático propiamente
dicho y son un resultado claro de la generalización de las políticas de outsour-
cing que hemos explicado. Pero en algún momento, determinadas compañías
de consultoría han llevado al extremo este concepto y han tendido a presentar
como consultores expertos a personal insuficientemente cualificado y con pocas
horas de trabajo real, lo cual ha acondicionado, en algunas organizaciones y
departamentos de SI, la percepción que se tiene de ellas y de la calidad de sus
servicios.
Auditoría de SI
Durante mucho tiempo se ha vivido con una especie de inmunidad total res-
pecto a cómo se hacían las cosas dentro del propio departamento de SI, a la cali-
dad de los procedimientos y a la evaluación de los resultados (en términos de
eficiencia económica o productividad). Pero es evidente que es necesario garan-
tizar y vigilar las inversiones en tecnología. Este es el papel de los auditores (nor-
malmente externos a la organización) de SI. Tendrían que ser instrumentos de

mejora y de aseguramiento de que los procedimientos (de todo tipo: infraestruc-
turas, desarrollo de SI, seguridad, gestión de datos...) se hacen según las buenas
prácticas o los estándares metodológicos y los marcos legales existentes.
Tendrían que ayudar a descubrir funcionamientos incorrectos y sus causas y dar
pautas para su mejora. Es decir, el auditor ejerce, desde una perspectiva alejada
del propio departamento, una visión crítica de su funcionamiento, buscando
los puntos débiles (y confirmando los fuertes) para ayudar a la mejora futura.5
Sobra decir que, por estos motivos, a menudo no son muy bien vistos por los
miembros del departamento, aunque la asunción de los principios de calidad
por parte de todos hace que, poco a poco, se vaya cambiando la percepción que
se tiene de ellos.
9. ¿Conclusiones?
Más allá de todo lo que hemos expuesto en este capítulo, hay una idea clara
y que determina que hayamos puesto un signo de interrogación en el título de
este apartado final: la disciplina en torno a los sistemas de información –su defi-
nición y su management en las organizaciones a las que sirve– sigue evolucio-
nando, no está cerrada y, aunque tiene un nivel de madurez destacable, hasta
hace poco no ha contado con la aportación decisiva de las personas formadas
principalmente en el sector de las TI.
Es posible que estas aportaciones ayuden a ordenar funciones, a establecer
procedimientos o, por lo menos, a aclarar denominaciones y a seguir definien-
do las fronteras de todo el ámbito. Para los informáticos no tiene que represen-
tar ningún problema entrar sin complejos en un ámbito en el que casi todas las
definiciones y categorizaciones –y lo hemos repetido hasta la saciedad– no son
todavía definitivas. La informática ha sido y sigue siendo una profesión some-
tida a vertiginosas evoluciones, acostumbrada a atender a clientes y ámbitos de
todo tipo, y que ya se ha ido acercando a otras áreas de conocimiento y fun-
5. A pesar de no ser el único marco de referencia, COBIT es una recopilación de buenas prácticas
para el management de SÍ, especialmente utilizado en auditoría.
diendo con ellas (la medicina o el diseño, por ejemplo, por decir sólo algunas
que nos son muy cercanas), de modo que, el de las organizaciones, es sólo un
campo más.
Por eso hemos puesto el interrogante en el título: lejos de reflejar incerti-
dumbre sobre todo lo que hemos dicho aquí, querríamos que representara el
estímulo que significa tener un territorio por explorar para unos profesionales
acostumbrados a aterrizar en todo tipo de islas, continentes o, incluso, plane-
tas...
© Editorial UOC 243 Glosario
Glosario
Capítulo II: Arquitectura de los sistemas distribuidos
antememoria Tipo de memoria de un computador, también llamada caché,

caracterizada por su alta velocidad de acceso y coste en comparación con la
memoria RAM.
arquitectura Se refiere a la descripción de todos los elementos que constituyen
un computador. Normalmente hay que indicar el nivel de interacción con el
computador en el que se hace la descripción: en el lenguaje máquina, en el
sistema operativo, en una aplicación concreta, etc.
biestable Dispositivo electrónico que es capaz de almacenar 1 bit de informa-
ción durante un tiempo indefinido. Forma la base lógica de los dispositivos
de almacenamiento de la información basados en semiconductores.
chip Circuito integrado. Dispositivo electrónico, base del hardware de todos los
computadores.
ensamblador Programa que traduce el código de bajo nivel, basado en elemen-
tos mnemotécnicos para indicar las instrucciones, al código en lenguaje
máquina que es capaz de interpretar un computador. También se suele usar
este término para referirse al lenguaje de bajo nivel.
Firewire Tipo de bus serie que permite conectar dispositivos externos a un com-
putador.
hardware Es el conjunto de elementos físicos que forman parte de un compu-
tador.
HTML HyperText Markup Language. Lenguaje con el que se escriben las páginas
de la web.
HTTP HyperText Transfer Protocol. Protocolo de transferencia de hipertextos.
Protocolo utilizado para acceder a las páginas de la web.
IMAP Internet Message Access Protocol. Protocolo que permite obtener los men-
sajes de correo electrónico almacenados en un servidor. Ofrece más ventajas
que el protocolo POP3, pero es más complejo.
PCI Peripheral Component Interconnect. Tipo de bus de un computador que per-

mite comunicar la placa base con las tarjetas de expansión.
POP3 Post Office Protocol. Protocolo que permite obtener los mensajes de correo
electrónico almacenados en un servidor. Es más sencillo que el protocolo
IMAP, por lo que es utilizado más frecuentemente en el ámbito doméstico.
RAM Random Access Memory. Memoria de acceso aleatorio. Tipo de memoria de
semiconductor caracterizada por que todos los accesos a su contenido son inde-
pendientes entre sí.
software Es el conjunto de todos los elementos intangibles de un computador,
básicamente programas y datos.
USB Universal Serial Bus. Tipo de bus serie que permite conectar dispositivos
externos a un computador.
web Es el conjunto de todas las páginas a las que se puede acceder en Internet.
Capítulo III: Redes de computadores
ADSL Tecnología para la transmisión de información digital con un gran ancho

de banda sobre las líneas telefónicas convencionales.
analógico/a Dicho de la señal, información o parámetro cuya variación puede
tomar un valor cualquiera dentro de un conjunto infinito de valores. Son
ejemplos todos los parámetros físicos, como la posición, la velocidad, la tem-
peratura, etc.
ancho de banda Dentro del contexto de la transmisión de datos digitales, se
llama así a la cantidad de datos que se pueden transmitir (bits, kilobits,
megabits, etc.) por unidad de tiempo.
aplicación distribuida Aplicación (programa) cuyas diferentes partes se
encuentran en ordenadores diferentes que utilizan las redes de comunicacio-
nes para interaccionar entre sí.
digital Dicho de la señal, información o parámetro cuya variación puede tomar
un valor cualquiera dentro de un conjunto finito de valores.
hacker Argot. Individuo que se dedica a entrar en sistemas ajenos mediante la
red, aprovechando defectos de su configuración o gestión, o bien defectos de
los sistemas que la componen. El término originalmente no tenía este signi-
ficado, por lo que es preferible usar cracker.
ISO International Standard Organization. Organización internacional para la nor-
malización.
LAN Local Area Network. Red de área local. Red de área extensa. Red que permi-
te interconectar dispositivos que están próximos físicamente (a centenares
de metros).
MAN Metropolitan Area Network. Red de área metropolitana. Permite interconec-
tar dispositivos que no están físicamente próximos, pero dentro del ámbito
de un área relativamente limitada (como una ciudad o distrito).
medio de transmisión Apoyo físico por el que se puede propagar una señal, en
forma de ondas o energía.
modelo cliente/servidor Modelo para representar aplicaciones locales y distribui-
das en que se define una parte servidora (que es la que proporciona los servi-
cios) a la que accede una parte siguiendo las indicaciones de un usuario huma-
no a través de una interfaz de usuario u otra aplicación.
PAN Personal Area Network. Red de área personal. Red ideada para interconectar dis-
positivos a muy corta distancia (normalmente, como máximo unos 10 metros).
PDA Personal Digital Assistant. Dispositivo pequeño y móvil que proporciona
capacidad de procesamiento y almacenamiento de información.
protocolo de comunicaciones Formato y conjunto de reglas que se definen
para el intercambio de información entre dos entidades del mismo nivel
dentro de una arquitectura de comunicaciones.
TCP/IP Transmission Control Protocol / Internet Protocol. Protocolo de comunica-
ción que es la base de funcionamiento de Internet.
WAN Wide Area Network. Red de área extensa. Red que permite interconectar
dispositivos que no están próximos físicamente, en cualquier lugar del
mundo.
WLAN Wireless Local Area Network. Red de área local basada en comunicaciones
sin hilos.
WEP Wired Equivalent Privacy. Algoritmo que pretende proporcionar las propie-
dades de confidencialidad e integridad en el estándar IEEE 802.11, que rige
en las redes de comunicaciones sin hilos.
Capítulo IV: Programación
algoritmo Conjunto explícito de reglas para resolver un problema en un núme-

ro finito de pasos.
biblioteca Conjunto de funciones preprogramadas por un lenguaje determina-
do, que pueden ser reutilizadas en otros programas.
ensamblador Herramienta que traduce código escrito en lenguaje ensamblador

a código máquina.
codificación Traducción de un algoritmo a un lenguaje de programación.
código intermedio Código que puede ser interpretado por una máquina vir-
tual.
código máquina Código escrito utilizando lenguaje máquina o generado a par-
tir de compilar otro lenguaje.
compilador Herramienta que traduce código de un cierto lenguaje a código
máquina.
computador Autómata de cálculo gobernado por un programa.
datos Son las entidades que definen el estado de un problema. Al ir aplicando
las instrucciones de un algoritmo a los datos, éstas se van cambiando.
estado Descripción del entorno en un momento determinado.
estructura condicional Estructura que permite la aplicación condicional de
órdenes en un algoritmo.
estructura iterativa Estructura que permite la repetición controlada de un con-
junto de órdenes en un algoritmo.
estructura secuencial Aplicación consecutiva de órdenes en un algoritmo
intérprete Herramienta que puede ejecutar directamente código en un cierto
lenguaje, traduciéndolo a código máquina en tiempo de ejecución.
lenguaje algorítmico Lenguaje artificial que se utiliza para expresar algoritmos.
lenguajes de alto nivel Son aquellos lenguajes próximos al lenguaje natural.
Facilitan la comprensión de los programas y mediante un mecanismo de tra-
ducción se genera código que puede entender el ordenador.
lenguajes de bajo nivel Son aquellos lenguajes más próximos a la manera de
programar la máquina. Se consideran lenguajes de bajo nivel el lenguaje
máquina y el ensamblador.
lenguaje de programación Lenguaje creado para expresar programas y que es
capaz de ser interpretado por un ordenador.
lenguaje máquina Es el lenguaje de programación que entiende el ordenador.
Normalmente se representa en código binario o hexadecimal.
lenguaje natural Cualquier lenguaje que se utiliza de forma natural como comu-
nicación: catalán, castellano, inglés, etc.
máquina virtual Herramienta que está por encima del hardware de un ordena-
dor que es capaz de interpretar código intermedio. Generando una máquina
virtual para cada arquitectura diferente se puede ejecutar el mismo programa
sobre cualquiera de éstas.
ordenador Véase computador.

programa Codificación de un algoritmo en un lenguaje de programación que
entienda el ordenador.
programación orientada a aspectos Paradigma de programación en el que el
programa se estructura según la funcionalidad que se quiere proporcionar.
programación orientada a objetos Paradigma de programación en el que el
programa se estructura en clases y objetos independientes capaces de inter-
actuar entre sí.
programación procedimental Paradigma de programación en el que el progra-
ma se estructura en funciones y procedimientos.
software libre Aquel que da libertad de ejecución, estudio, mejora y redistribu-
ción del programa.
recursividad véase recursividad.
sintaxis Reglas de estructura de un lenguaje.
semántica Significado de los símbolos de un lenguaje.
Capítulo V: Gestión de datos: bases de datos y sistemas gestores

de bases de datos
administrador de bases de datos (ABD) Perfil profesional del área de bases de

datos (BD) que realiza funciones centralizadas de administración y control
que aseguran que la explotación de la BD es correcta.
base de datos (BD) Representación de una colección de datos estructurada que
describe las actividades de una organización. Esta representación incluye
entidades y sus interrelaciones y tiene que permitir diversas utilizaciones.
esquema Descripción o definición de la BD. Esta descripción está separada de
los programas y es utilizada por el sistema de gestión de base de datos (SGBD)
para saber cómo es la BD con la que tiene que trabajar.
modelo de datos Mecanismo conceptual para representar el almacenaje de
datos.
modelo de datos jerárquico Modelo de BD que estructura los datos en jerar-
quías o árboles. Es el modelo soportado principalmente por el producto IMS
de la compañía IBM.
modelo de datos orientado al objeto Modelo de datos, y posteriormente
modelo de BD, que modela la realidad como un conjunto de objetos de cual-
quier complejidad.
modelo de datos relacional Modelo de BD que estructura los datos en relacio-

nes, atributos y tuplas y sigue las indicaciones de la propuesta seminal de E.
F. Codd.
modelo de datos en red Modelo de BD que estructura los datos en red. Fue
estandarizado por CODASYL. El IDS se basa en este modelo.
sistema de gestión de bases de datos (SGBD) software específicamente diseña-
do y desarrollado para asistir en la creación, la manipulación y el manteni-
miento de BD.
Structured Query Language (SQL) Lenguaje de BD relacionales. Creado por
IBM en la década de los setenta y estandarizado por ANSI (1986) e ISO
(1987). La última versión estándar es del año 2008. Actualmente es el len-
guaje utilizado por los principales SGBD relacionales.
Capítulo VI: Ingeniería del software
análisis Etapa del ciclo de vida en que se definen los requerimientos del softwa-
re que se tiene que desarrollar (es decir, “qué” tiene que hacer el software).
ciclo de vida Conjunto de etapas que se siguen durante el desarrollo de un soft-
ware.
diseño Etapa del ciclo de vida en que se define cómo llevará a cabo el software
los requerimientos especificados durante la fase de análisis.
Entidad/relación (ER) Lenguaje de modelización para la parte estática del soft-
ware, muy popular dentro de la comunidad de bases de datos.
Extreme Programming (XP) Método ágil de desarrollo de software, especial-
mente útil en proyectos pequeños o medios.
Object Constraint Language (OCL) Lenguaje textual que permite complemen-
tar los modelos especificados en UML con toda la información que no se
puede expresar gráficamente.
Unified Modeling Language (UML) Lenguaje visual de modelización de siste-
mas de software. Es el lenguaje más utilizado hoy día.
Unified Process (UP) Método de desarrollo de software creado por G. Booch, J.
Rumbaugh e I. Jacobson. También conocido como RUP.
Capítulo VII: Sistema de información (en las organizaciones)
Ya hemos dicho a lo largo del capítulo que algunos de los conceptos y de las
definiciones que hemos dado no son universales. Este glosario, en estos casos,
dará nuestras definiciones.
Aplicación: Aquel programa uso específico para una tarea de negocio y que ha
sido diseñado y fabricado individualmente sin prever su interconexión con
otros programas.
BI: Business Intelligence. de estrategias y soluciones SI permiten gestionar y crear
conocimiento mediante el análisis de los datos existentes en una organiza-
ción para apoyar a la toma de decisiones sobre el negocio. Se consideran, SI
ales.
BSC: Ballanced Score Card. que permite definir y monitoritzar los objetivos con-
cretos de una organización, ayudando a transformar su estrategia en resulta-
dos, a partir de disminuir el gapexistente entre el plan estratégico definido y
el trabajo diario de las personas. Existen diferentes SI decisionales que imple-
mentan sus funciones de recogida de datos, su análisis y la generación de
informes.
CIO: Chief Information Officer. Jefe principal de la función informática en la
organización a quien corresponde el liderazgo de la dirección estratégica de
los SI.
CMS: Content Management System. SI en poner a disposición de terceros, normal-
mente a partir de portales web, la información pública generada dentro de la
propia organización.
Conocimiento: Conjunto de información que resulta ser útil porque, además
de ser desconocida hasta aquel momento, ayuda a 1) comprender una situa-
ción real (un objeto o concepto) y/o 2) a tomar una decisión.
CRM: Customer Relationship Management. SI operacional que se encarga de man-
tener toda la información a cerca de los clientes y de su interrelación con la
organización (historial de actividad, incidencias, preferencias...) dando fun-
cionalidades de front-office hacia ellos.
Datos: Valores, hechos, evidencias sobre un aspecto concreto de un objeto o
concepto.
Dirigir: Conceptualizarla estrategia de la organización/departamento/grupo, el
diseño organizativo que le dé soporte y el ejercicio del liderazgo a partir de
acciones estratégicas. En general, la dirección implica también planificar,
organizar, ejecutar y controlar, siempre de acuerdo a su nivel (en la ejecución

y control, por ejemplo, no se refiere a intervenir en cada detalle, pero sí en
aquellos que son estratégicos).
DSS (SIAPD): Decision support systems (SI para la ayuda a la toma de decisiones) SI
de nivel táctico que apoya la toma decisiones de un ámbito muy específico.
ECM: Enterprise Content Management. SI especializado en retener y representar
conocimiento de una organización (y de sus personas), para evitar la depen-
dencia a las mismas. Entre sus funcionalidades hay la captura conocimiento;
su almacenamiento seguro; su gestión y difusión; la representación de los
procesos de negocio y de la estructura de la organización; y el seguimiento y
difusión de estos procesos y estructura.
EIS (SIE): Executive information system. SI de nivel estratégico que facilita a los
ejecutivos su actividad de decisión estratégica, dando acceso a la informa-
ción relevante, mejorando la comunicación entre los ejecutivos y ayudándo-
los a la comprensión de las situaciones.
ERP: Entreprise Resource Planning. SI que integra el tratamiento de todas las trans-
acciones entre las diferentes actividades internas de la organización (los pro-
cesos de negocio).
Estrategia: En el entorno de las organizaciones se entiende como la determina-
ción de sus metas y objetivos. Normalmente se promueve desde el alta direc-
ción (a pesar de que esto no quiere decir que no se tenga que contar con
otros niveles de la organización para determinarla), en el nivel que hemos
definido como nivel estratégico. Puede concretarse en un plan estratégico faci-
lite esta concreción y su difusión en la organización. Tiene que incluir ideas
sobre hacia dónde va la organización, cuáles son los productos o servicios que ofre-
ce y a qué clientes o usuarios se dirige.
Funcional: En el entorno de las organizaciones y de los SI se entiende como la
gestión o las acciones dirigidas a alguno de los ámbitos en que se divide el
funcionamiento de la organización (comercial, producción, financiero..).
Gestionar: Contribuira la implementación y controlar diseño organizativo mar-
cado por la dirección.
Información: Combinación elaborada de datos que nos permiten describir y
comprender con más o menos detalle un objeto o concepto.
Management: Término inglés que incluye los conceptos de dirigir y gestionar.
Incluye desde la conceptualización de la estrategia al impulso (o incluso a la
ejecución directa) de acciones alrededor de esta estrategia, pasando por el
diseño organizativo de todo ello.
MES (SEG): Management Expert System (SI Experto para la gestión). SI decisional
del ámbito táctico que propone soluciones a un problema de gestión concre-
to y limitado.
Operacional: En el entorno de las organizaciones se entiende como el conjun-
to de acciones y métodos utilizados para realizar las tareas u operaciones
habituales o corrientes (compras, órdenes de servicio o fabricación, pagos...).
Queda recogido en el nivel que hemos definido como nivel operativo o trans-
accional.
Organizar: Como tarea directiva, la referida a la realización del diseño de la
organización/departamento/grupo que tiene que dar respuesta a la estrategia
planteada. Este diseño incluye la estructuración, la definición y flujo de los
procesos y la interacción entre las personas implicadas.
Software de base: Aquel que no es de utilización directa por el usuario final del
SI o TI. Hace funcionar la infraestructura de red, de hardware y de software
sobre la que se sustenta el software de aplicación. Incluye los sistemas ope-
rativos, los sistemas gestores de bases de datos, los sistemas de seguridad, los
protocolos de redes, los drivers de hardware...
Software de aplicación: Aquel que es de utilización directa por el usuario final
del SI o TI en cuánto le da apoyo o le permite realizar las funciones o traba-
jos que tiene asignadas a la organización.
Proyecto: Conjunto de actividades previstas de desarrollar durante un periodo
de tiempo por un conjunto de personas con un presupuesto económico
determinado para crear un producto, servicio o resultado único.
SCM: Supply Chain Management. SI que se centra en todos los procesos alrededor
del ciclo productivo (adquisición de las materias primeras a los proveedores,
almacenamiento inicial, transformación en los procesos productivos y alma-
cenamiento como producto final a punto para ser consumido por el cliente).
SI: Sistema de Información. Conjunto de elementos interrelacionados que
garantiza la transformación de datos en información, así como su disponibi-
lidad para las personas (y las organizaciones) que las utilizarán siguiendo sus
procedimientos para incrementar su conocimientoy actuar en consecuencia.
En la actualidad no se entienden sin las TI (Tecnologías de la Información)
que son las herramientas fundamentales para su función.
SI (En cursiva): Sistema de Información. En el contexto de soluciones informáti-
cas, se refiere a los productos software (es decir, un componente de TI) existen-
tes en el mercado que cubren una parte más o menos completa del SI de una
organización. Nosotros nos referiremos a este producto software en cursiva
(SI) para intentar diferenciarlo del concepto general de sistema de informa-

ción.
Sistema integrado: Aquel SI que forma parte del conjunto del software de apli-
cación y que incluye múltiples funcionalidades de uno o más ámbitos per-
fectamente interconectadas, supliendo los aplicativos y la necesidad de esta-
blecer puentes entre ellos para compartir información.
Soluciones/productos: Concepto que se refiere habitualmente a las ofertas
concretas existentes en el mercado (comerciales o no) de un software de apli-
cación (integrado o no).
Táctica: En el entorno de las organizaciones se entiende como el conjunto de
acciones y métodos utilizados para lograr algún objetivo (marcado normal-
mente por la estrategia de la organización). Se acostumbra a relacionar con
la dirección intermedia, en el nivel que hemos definido como nivel táctico.
TI: Tecnologías de la Información. Todo tipo de artefactos, activos y recursos
informáticos (ordenadores, sistemas operativos, sistemas gestores de bases de
datos, sistemas de seguridad, protocolos de redes, drivers, aplicaciones ofi-
máticas, software de aplicación, herramientas y portales web...) disponibles
para un SI (Sistema de Información) cada momento según el estado de la tec-
nología. Incluye, pues, el hardware y software, las infrastructuras de base, e
incluso la documentación de uso y proceso de todo ello.
© Editorial UOC 253 Bibliografía
Bibliografía
Capítulo I. Visión general de la informàtica
Hay infinidad de libros introductorios al mundo de la informática, pero

muchas veces detrás de ellos se esconden auténticos manuales de la materia con
intención enciclopédica. Por este motivo haremos sólo una recomendación
bibliográfica que cumple ser una introducción muy llana, bastante moderna y
con un diseño muy atractivo que justifica su extensión:
Williams, B.K. i Sawyer, S.C. (2007) Using information technology. A practical

introduction to computers and communications. (7ª ed.) Mc-Graw Hill. Irving
Capítulo II. Arquitectura de los sistemas informáticos
Cada uno de los siguientes libros sirve para profundizar en los temas de
arquitectura de computadores, de sistemas distribuidos y de redes, respectiva-
mente. No olvidéis tampoco consultar la información a la propia Internet, por
ejemplo a través de wikipedia.
Stallings, W. (2006) Organización y arquitectura de computadores (7ª ed.)

PrenticeHall.
Coulouris, G.; Dollimore, J.; Kindberg, T. (2001) Sistemas distribuidos.

Conceptos y diseño (3ª ed.) Addison-Wesley.
Kurose, J. F.; Ross, K. W. (2003) Computer Networking: A Top-Down Approach

Featuring the Internet. Addison-Wesley.
Wikipedia http://www.wikipedia.org.
Capítulo III. Redes de computadores
Los siguientes libros pueden servir para profundizar dentro del mundo de las
redes. De especial importancia es el primero, al estar precisamente orientado
desde una perspectiva top-down:
F. Kurose, James; W. Ross, Keith. (2004) Redes de Computadores. Un enfoque

descendente basado en Internet. Pearson, Addison-Wesley
Cisco Systems Inc. (2004) Guía del primer año. CCNA 1 y 2 (3a Ed). Cisco Press,
Pearson Educación
Cisco Systems Inc. (2004) Guía del segundo año. CCNA 3 y 4 (3a Ed). Cisco
Press, Pearson Educación
Tanenbaum, A.S. (2003) Redes de Computadoras (4a Ed), Pearson Educación
Stallings, W. (2002) Wireless Communications and Networks, Prentice Hall
Stallings, W. (2000) Comunicaciones y redes de datos (6a Ed), Prentice Hall
Si se quiere entrar con más detalle en el campo de la seguridad, los siguien-

tes libros pueden ser de gran utilidad:
McClure, Stuart;Scambray, Joel;Kurtz, George. (2005) Hacking Exposed,

McGraw-Hill Osborne Media
Oppliger, Rolf. (2000) Security technologies for the World Wide Web, Artech
House
Singh, Simon. (1999) The Code book : the science of secrecy from ancient Egypt to
quantum cryptography, Fourth Estate
Schneier, Bruce. (1996) Applied cryptography: protocols, algorithms, and source

code in C, John Wiley & Sons
Finalmente, no sería justo dejar de referenciar la gran enciclopedia on-line,

un ejemplo claro de todo lo que se ha visto en este capítulo:
Wikipedia http://www.wikipedia.org
Capítulo IV. Programación
Wirth, N. (1976) Algorithms + Data Structures = Programs, Prentice-Hall (Edició

espanyola: Algoritmos + Estructuras de Datos = Programas, Ediciones del Castillo,
1980)
Aho, A.; Ullmann, Jeffrey D. (1977) Compilers. Principles, Techniques and

Tools, Addison-Wesley
Aho, A.; Sethi, Ravi; Ullmann, Jeffrey D. (1986) Compilers. Principles,

Techniques and Tools, Addison-Wesley (Edició espanyola: Compiladores,
Principios, Herramientas y Técnicas, 1990)
Aho, A.; Hopcroft, John E.; Ullmann, Jeffrey D. (1988) Data Structures
and Algorithms, Addison-Wesley (Edició espanyola: Estructuras de Datos y
Algoritmos, 1988)
Capítulo V. Gestión de Datos: bases de datos y sistemas gestores

de bases de datos
Todos los libros de texto relacionados con las BD y los SGBD incorporan
capítulos introductorios que incluyen contenidos similares a los presentados en
este texto. En cualquier caso, se quieren destacar los siguientes:
Connolly, T.; Begg, C. (2005). Sistemas de bases de datos: un enfoque práctico

para el diseño, implementación y gestión. Addison-Wesley.
Ramakrishnan, R.; Gehrke, J. (2003). Database Management Systems (Third

Edition). McGraw-Hill.
Ullman, J.D.; Widom, J. (2002). A First Course in Database Systems (Second

Edition). Prentice-Hall.
Igualmente destacar que este texto no se habría podido elaborar sin la con-
sulta y uso de los materiales siguientes:
Sistac Planas, J. (coordinador). (2005). Bases de dades I (Tercera Edició).

Fundació per la Universitat Oberta de Catalunya.
Sistac Planas, J. (coordinador). (2004). Bases de dades II (Segona Edició).

Sistac Planas, J. (coordinador). (2001). Sistemes de gestió de bases de dades.

Capítulo VI. Ingeniería del software
El abanico de libros que tratan aspectos de EP es anchísimo. Dicho esto, se

propone la selección de libros siguiente (en la medida del posible se recomien-
da consultar la versión inglesa, siempre más actualizada):
Beck, K. Extreme Programming Explained: Embrace Change. Boston: Addison-

Wesley.
Booch, G.; Rumbaugh J.; Jacobson, I. El lenguaje unificado de modelado.

Addison Wesely
Jacobson, I.; Booch, G.; Rumbaugh J. El proceso unificado de desarrollo de

software. Addison Wesely
Larman, C. UML y patrones, introducción al análisis y diseño orientado a objetos.

Prentice Hall.
Pressman, R. Ingeniería del sofware, un enfoque práctico. McGraw Hill.
Sommerville, I. Ingeniería del software. Pearson Education.

Warmer, J.; Kleppe, A. The Object Constraint Language: Getting Your Models
Ready for MDA, Addison-Wesley
Igualmente destacar que este capítulo no se habría podido elaborar sin la

consulta de los materiales didácticos de la UOC siguientes:
Campderrich, B.; Recerca Informàtica SL. (2003). Enginyeria del

Programari. Fundació per a la Universitat Oberta de Catalunya.
Cabot, J.; Guitart, I. (coordinadores); Fernández, J.; Pradel, J.; Raya, J.A.
(autors) (2005). Enginyeria del programari orientat a l'objecte. Fundació per a la
Universitat Oberta de Catalunya.
Cabot, J. (coordinador); Camps, J.M.; Ceballos, J.; Durán, F.J.; Moreno,

N.; Romero, J.R.; Vallecillo, A. (autors) (2006). Enginyeria del programari de
components i sistemes distribuïts. Fundació per a la Universitat Oberta de
Catalunya.
Capítulo VII. Sistemas de información (en las organizaciones)
Las referencias que hemos mencionado en el capítulo son las siguientes:
Applegate, L. M.; Austin, R. D.; McFarlan, F. W. (2003). Corporate

Information Strategy and Management: Text and Cases. (6.ª ed.). Boston: McGraw-
Hill.
Castells, M. (2000). La sociedad red (2a. edició). Madrid: Alianza Editorial.
Earl, M. (2000). “Every business is an information business”. Mastering
Information Management. Londres: Financial Time - Prentice Hall.
Gil Pechuán, I. (1996): Sistemas y tecnologías de la información para la gestión.
Madrid: McGraw-Hill.
Kaplan, R.; Norton, D. (1997). Cuadro de mando integral (The Balanced
Scorecard). Barcelona: Ediciones Gestión 2000.
McFarlan, F.W. (2003). “Organizing and Leading the IT Function”. A:
Applegate i altres. Corporate Information Strategy and Management: Text and Cases.
(6.ª ed.). Boston: McGraw-Hill.
Olivé, A. (2001): “Introducció a la modelització conceptual de sistemes d’infor-

mació”. A: Olivé, A. Modelització conceptual de sistemes d’informació (Cap.1.).
Barcelona: Edicions UPC.
Porter, M.E., , V.E. (1985), “How information gives you advantage”, Harvard
Business Review, Vol. 63 No.4, pp.149-60.
Simon, J. (2001). Introduction to information systems. New York: John Wiley &
Sons, Inc.
Ward, J.; Peppard, J. (2003). Strategic Planning for Information Systems.
London: Ed. John Wiley and Sons Ltd.
Otras referencias muy adecuadas para profundizar en una visión actual de

estos temas son:
Valor, J. y otros (2005). Los sistemas de información en la empresa actual.
Madrid: McGraw Hill.
O’Brien, J.; Marakas, G. (2006). Management Information Systems. (Cap. 1.)
New York: McGraw-Hill Irwin.
Porter, M. (2008). “The five competitive forces that shape strategy”. Harvard
Business Review, January 2008, p78-93
Porter, M. (2001). “Strategy and the Internet”. Harvard Business Review, March
2001, p63-78
Adicionalmente, los siguientes materiales didácticos de la UOC han sido uti-

lizados para la redacción de este capítulo:
Pastor, J.A (2002). Gestión de organizaciones y proyectos informáticos. Barcelona,
Editorial UOC.
Rodríguez, J.R. (2009) Dirección estratégica de sistemas y tecnologías de la infor-
mación. Barcelona, Editorial UOC.
Finalmente recomendamos por pura diversión una novela que, adoptando la

forma de esperpento, refleja la profesión de consultor de TI de una manera hila-
rante y excesiva (aunque inspirada en situaciones claramente cercanas a la rea-
lidad).
Miranda, J. (2005). “No he venido aquí a hacer amigos. Memorias de un
Consultor TI.” Madrid, Editorial Lengua de Trapo.

Escaneando La Informática

Cargado por

Copyright:

Formatos disponibles

Escaneando La Informática

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Escaneando La Informática

Cargado por

Copyright:

Formatos disponibles

Escaneando la Informática

Maria Jesús Marco Galindo

© Imagen de la cubierta: Istockphoto

© Realización editorial: Sònia Poch (spoch44@gmail.com)

Joan Arnedo Moreno

Jordi Cabot Sagrera

Isabel Guitart Hormigo

Francisco Javier Noguera Otero

Rafael Macau Nadal

Maria Jesús Marco Galindo

Joan Antoni Pastor Collado

Josep Prieto Blázquez

Daniel Riera Terrén

Jordi Tubella Murgadas

M. Elena Rodríguez González

Ramon Segret Sala

Capítulo I. Visión general de la informática,

Capítulo II. Arquitectura de los sistemas informáticos,

3.4. Buses ............................................................................................ 62

Capítulo III. Redes de comunicaciones,

Capítulo IV. Programación,

1. Introducción ........................................................................................ 101

3.3. El primer programa en la memoria ............................................ 106

Capítulo V. Gestión de datos: bases de datos y sistemas gestores

1. Introducción ........................................................................................ 139

4.4. Concurrencia y recuperación .............................................................. 153

Capítulo VI. Ingeniería del software,

1. Introducción ........................................................................................ 169

Capítulo VII. Sistemas de información (en lasorganizaciones),

1. Introducción .......................................................................................... 199

4. Profundizando en el papel de los SI en las organizaciones .................. 206

Glosario ...................................................................................................... 243

Bibliografía ................................................................................................ 253

Nos guste o no, el hecho es que nos encontramos en un mundo en cambio

Es evidente que se han alcanzado plenamente los objetivos planificados. El

Eso me ha dado la oportunidad de restablecer el contacto con personas que

Gabriel Ferraté i Pascual

A menudo, los que de una manera u otra ostentamos la etiqueta de informá-

Un aviso final: en todos los capítulos se puede observar una diferencia de

Maria Jesús Marco Galindo

Visión general de la informática

Podemos empezar preguntándonos: ¿Qué es la informática? Como punto de

Aunque posiblemente sabéis qué es y cómo funciona un ordenador, recordé-

ciones ha cambiado profundamente la manera de trabajar, hacer negocios e incluso disfrutar de

el correo electrónico entre los alumnos y el consultor de un aula virtual y tam-

Aunque la realidad de este artilugio ha cambiado, todo lo que hemos ido

2. La actividad profesional relacionada con la informática

En la lista anterior del sistema técnico de la informática6 nos hemos deja-

6. En el primer párrafo de la introducción.

llas consideradas más importantes en el momento actual en nuestro país y

Aunque la percepción que tenemos de la informática y de las comunicacio-

campo de las comunicaciones como, por ejemplo, la teoría ondulatoria y el

teórica o de fundamentos teóricos de la informática. Su trabajo consiste en la

La tecnología informática engloba a todos aquellos conocimientos que permi-

4.1. Tecnología del hardware

4.1.1. La arquitectura del ordenador

Artilugios para calcular, si consideramos que el ábaco es uno de ellos, pode-

mecánicas que realizan operaciones aritméticas. Y es mucho más tarde, hacia

4.1.2. La arquitectura de la red de ordenadores

Ya hemos visto en la introducción que hoy día los ordenadores no trabajan