1.

26 4 Examen final
Otoo. 2001
Directrices para el examen:
1. Dispo nd r de tres ho ras para realizar el examen.
2. Si tiene preguntas o necesita alguna aclaracin, dirjase a la persona que vigila el examen.
3. Escriba las respuestas en el cuadernillo de examen que se le ha entregado.
4. Puede utilizar apuntes.
5. No se pueden consultar libros de referencia.
6. No est permitido el uso de ordenadores porttiles.
7. No est permitido el uso de telfonos mviles o dispositivos de mensajera.
Apague cualq uie r e quipo de e stas c arac te rsticas que ten ga.
8. No es necesario el uso de calculadoras: no estn permitidas.
9. 100 puntos en total (20 puntos por cada una de las 5 preguntas).
10. Escriba su nombre y su direccin de correo electrnico en el cuadernillo de examen.
11. Respuestas a las preguntas breves: la extensin de las respuestas est limitada a un
mximo d e 2-4 frases, suficientes para c onte star a cu alqui era de las pregu ntas; n o
es necesario escribir 4 frases. Demuestre que ha entendido los principio y los puntos
clave. Recibir la mxima calificacin por las respuestas que se ajusten de forma
ms precisa a la pregunta en cuestin. No es necesario incluir detalles.
1 de 15
1. Proceso de software. (20 puntos)
Chris era el encargado de la versin 1 del sistema de inventario de productos
qumicos del MIT, el MITCIS. Con la creciente necesidad de seguridad en la
actualidad, el MIT se dio cuenta de que su sistema informal de realizacin de
pedidos, envos y entregas de productos qumicos necesitaba evolucionar. Chris tena
una idea general de las capacidades necesarias, ya que haba realizado el curso 1.264
y haba asistido a la primera reunin del comit directivo del MIT para el proyecto.
Dave, el presidente del comit, le plante la siguiente pregunta:
Chris, cunto tardar el MITCIS en conseguirlo?.
Creo que se tardar unos 9 meses, pero ten en cuenta que es un clculo
aproximado, contest Chris.
No puede ser, argument Dave. Esperaba que me dijeses 3 4 meses como
mucho. Es imprescindible que podamos disponer del MITCIS en un periodo de 6
meses; no podemos permitirnos riesgos de seguridad ms de 6 meses, en el peor de
los casos. Eres consciente de la gravedad del problema, verdad? Podras hacerlo en
6 meses?
No e stoy s egu ro , c ontes t Chris c on sincerid ad. T e ndra que analizar el proyecto
co n ms de te nimie nto, p ero har todo lo pos ible por terminarlo e n 6 meses .
Perfecto, entonces marcamos 6 meses como objetivo, dijo Dave. De todas
formas, no podemos permitirnos ms tiempo. El resto del comit estuvo de
acuerdo.
En la semana 5, la carga de trabajo adicional de los requisitos del sistema sirvi para
que Chris se diese cuenta de que los 9 meses que l haba calculado era un periodo
mucho ms realista que los 6 meses, pero confi en que, con un poco de suerte, podra
terminarlo en 7 u 8 meses. No quera que el resto del comit pensase que no quera
colaborar o que no era competente y quera a toda costa que las cosas fuesen bien, ya
que el resultado de este encargo sera decisivo para su promocin en la empresa y
para los futuros trabajos.
El equipo de Chris realiz grandes progresos pero los requisitos eran mucho ms
amplios de lo que habran esperado. Cada laboratorio y departamento tena una forma
distinta de hacer las cosas y llegar a acuerdos y a un enfoque comn no fue sencillo.
Haban pasado ya 3 de los 6 meses y le dijo a Dave lo siguiente: Es imposible que
podamos terminar lo que queda en 3 meses. Aadi que necesitaban una ampliacin
de 2 meses y reorganizarlo todo para 8. Siendo realista, crea que podra terminarlo en
9 10 meses, pero estaba seguro de que no podra planterselo al comit.
Semanas ms tarde, Chris se dio cuenta de que los diseos de la base de datos, de la
pgina web y del programa iban mucho ms despacio de lo programado.
Implementad las partes ms sencillas, instruy al equipo. Ya nos encargaremos de
las partes ms complicadas cuando lleguen.
2 de 15
Chris se reuni con el comit directivo del MIT y anunci lo siguiente: Llevamos 7
de los 8 meses del proyecto. El diseo detallado casi est terminado y estamos
progresando, pero no podremos terminarlo en 8 meses. Le solicit a Dave una
segunda ampliacin a 10 meses. ste se quej y pidi a Carl una forma de poder
volver a los 8 meses programados.
Al llegar el noveno mes, el equipo haba terminado el diseo detallado, pero el
desarrollo del programa an no haba comenzado en algunas partes del sistema. Era
evidente que el equipo tampoco podra cumplir la programacin de 10 meses. Chris
anunci una tercera ampliacin a 12 meses. La cara de Dave cambi de color al
escucharlo y las presiones del comit del MIT eran cada vez mayores. Chris
empez a preocuparse por su puesto de trabajo.
La creacin del cdigo iba relativamente bien, pero era preciso rescribir el cdigo y
el diseo de algunas reas. El equipo no haba coordinado bien los detalles de diseo
de los subequipos de la pgina web, la base de datos y Visual Basic, y algunas de las
implementaciones generaban conflictos. En la reunin del comit en el mes 11, Chris
pidi una cuarta ampliacin del plazo, a lo que Dave, enfurecido, respondi: Pero
sabes lo que ests haciendo? Resulta evidente que no tienes ni idea de cundo
podrs terminar el proyecto! O lo terminas para el mes 12 o irs a la calle! T y tu
equipo trabajaris 80 horas por semana hasta que lo hayis terminado. Chris sinti
cmo le suba la tensin, sobre todo ante el hecho de que Dave le haba presionado
desde el principio con una fecha de entrega inviable. Pero saba que tras cuatro
solicitudes de ampliacin de plazo, su credibilidad era nula.
Chris inform a su equipo de la reunin. Trabajaron muy duro y consiguieron
entregar el software poco despus del mes 13.
a. Enumere al menos 5 errores cometidos por el equipo de
desarrollo en la ejecucin del proyecto. (7 puntos)
1. No se realizaron clculos de recursos (puntos de funcin,
lneas de cdigo, meses programados, personas-mes) al
comienzo del proyecto. Chris dio un clculo sin pensar
demasiado cuando se lo pidieron en la primera reunin.
2. No se comunic ningn grado de incertidumbre al comit.
Chris dio un clculo de puntos pero no tuvo en cuenta
datos como el tamao del proyecto, la complejidad de los
requisitos, etc.
3. No se mantuvo ninguna reunin para tratar las funciones o
el tamao del equipo necesario para cumplir la fecha de 6
meses. Chris debera haberlo hecho al ver que los
requisitos se complicaban incluso al principio del
proyecto.
4. Chris no comunic la programacin realista a medida que
avanzaba el proyecto. Los clculos reales se omitieron y
no se ofreci ninguna informacin actualizada hasta que
hubo problemas.
3 de 15
Si los requisitos terminaron siendo el doble de lo que se
esperaba, era de suponer que el resto del proyecto tambin
se retrasara, pero no se inform sobre ello.
5. El equipo no utiliz el modelo de la espiral (o cualquier
otro modelo adecuado, como la realizacin de prototipos
de evolucin, etc.). Utilizaron un modelo cascada, que no
es apropiado para el desarrollo. Y el proyecto dejaba claro
que la tarea principal era el desarrollo.
6. El diseo no se coordin correctamente, ya que las piezas
terminaron por no encajar. Estamos ante un claro ejemplo
de mala gestin y posible mal uso de las herramientas.
7. La integracin comenz demasiado tarde en el proceso
de d ise o y de co dificacin . Dejar las p arte s ms difciles
para el final es un grave error, ya que la integracin nunca
ser b uen a.
b. Resuma los pasos clave en el clculo de recursos que debera haber
utilizado el equipo para evitar estos errores/problemas. Enumere al
menos 5 pasos; describa cada uno de ellos en 1-2 frases. (6 puntos)
1. Calcular rpidamente el nmero de pginas web (o
pantallas de VB), tablas de bases de datos e interfaces
externas (si es necesario) que hay que crear.
2. Calcular los puntos de funcin de cada una.
3. Segn el tipo de software que se vaya a emplear (base de
datos, VB, etc.) para cada parte del sistema, calcular las
lneas de cdigo.
4. Calcular la programacin y las personas-mes necesarios
para el tipo de proyecto (negocio) y la madurez del
software (nominal sera la mejor opcin).
5. Aplicar un rango de incertidumbre basado en cada
fase del proyecto.
c. Resuma los pasos clave del desarrollo de software que debera haber
utilizado el equipo para evitar estos errores/problemas. Enumere al
menos 5 pasos; describa cada uno de ellos en 1-2 frases. Incluya un
desarrollo temporal aproximado para obtener un sistema entregable
en el sexto mes. (7 puntos)
1. Utilizar el mo delo de e spiral (o cu alqui er otro mod elo de evol uci n ).
2. Utilizar espirales de 3 meses para garantizar que el sistema
puede entregarse en el punto del tercer mes (uno muy
simple, pero que garantice la integracin) y en el punto del
se xto mes (tambin , co n tod a probab ilidad , mu y simple).
3. Realizar los requisitos de las primeras tres semanas de la
espiral 1, en vez de dejar pasar 3 meses. Comenzar con el
cdigo con un conjunto aproximado de requisitos para la
primera espiral, ya que se debern detectar todos los
problemas de los datos, las pginas, interfaces, etc. Los
requisitos deben ser aproximadamente del esfuerzo de
un a espiral.
4 de 15
4. Realizar el diseo en las 3 semanas siguientes. Debera
suponer tambin de cada espiral. El diseo se prolong
durante 6 meses (!!) en el proyecto: el tiempo total
estimado para la totalidad del mismo.
5. Crear un prototipo inicial, parecido al que se hizo en el
curso 1.264, en unas 4-5 semanas. Comprobar que todo est
correctamente integrado. Se puede hacer mejor que en el
curso, ya que se dispone de ms tiempo y ms
conocimientos.
6. Probar, revisar y depurar los errores de dos semanas en la
espiral 1 y mostrar un producto inicial al comit al llegar al
tercer mes. Si es preciso llegar al cuarto mes, no pasa nada,
aunque revelar que el producto no estar terminado hasta
el sptimo mes, ya que el nmero mnimo de espirales es 3
por mes.
7. Si el c omit ve con su s p rop io s ojos u n pro to tipo funcional
en el tercer o el cuarto mes, ser ms comprensivo y aceptar
de mejor grad o lo s posibles cambios de los requisitos.
5 de 15
2. Mo delo de datos. (20 punto s)
Lo s datos que se le facilitan re lacionados con las reglas de l nu evo sistema
de informacin d e produc to s qu micos del MIT , e l MIT CIS, so n:
a. El MITCIS trabaja con 150 laboratorios del MIT en sus departamentos,
centros de investigacin y administracin (asistencia). La informacin se
mantiene por nombre de laboratorio, nmero de telfono, direccin postal
y direccin de correo electrnico del MIT. Cada laboratorio tiene un ID
nico. Cada laboratorio se encuentra en una de las 5 regiones del MIT,
segn su ubicacin; las regiones son Central, Este, Oeste, Norte y
Noroeste.
b. Cada laboratorio tiene una empresa propietaria (departamento, centro de
investigacin o administracin). El MIT cuenta con tablas de
departamentos, centros de investigacin y departamentos administrativos.
Cada una de las tres tablas contiene elementos comunes: un ID nico,
nombre, direccin postal y nmero de telfono. Tambin tienen atributos
nicos:
i. Los departamentos incluyen la escuela del MIT a la que
p erten ec en.
ii. Los centros de inve stigac in tienen limitacin de c r dito s.
iii. Los departamentos administrativos requieren un nmero de cuenta.
c. Hay dos ubicaciones en las que el inventario de productos qumicos se
mantiene en el MIT. Una se encarga del servicio de Central y Oeste. La
otra, de Central, Este, Norte y Noroeste. Las ubicaciones se llaman A y
B. Disponen de direccin postal y nmero de telfono. No necesita
modelar su nivel de inventario.
d. El MIT cuenta con personal para la distribucin de productos qumicos.
Todos son empleados del MIT. Cada uno tiene asignada una regin. El
nombre, el ID nico de empleado, la direccin de correo electrnico y la
direccin postal de cada empleado se guardan en un registro.
e. Un laboratorio recibe el servicio de, al menos, un empleado, aunque
normalmente son varios los empleados que estn al cargo. Cada
empleado de laboratorio desempea un papel: asistencia primaria,
asistencia secundaria o especialista. Un empleado puede encargarse de
varios laboratorios. Los papeles deben validarse.
f. Los laboratorios realizan los pedidos por telfono o a travs de una pgina
web. Cada pedido tiene un nmero nico, un laboratorio y una fecha de
pedido. Cada uno de ellos se asigna a un empleado de asistencia de
productos qumicos que se encarga de realizar un seguimiento del estado.
g. El pedido puede tener muchos artculos. Cada lnea tiene un ID de
artculo (que es el ID de un producto qumico) y una cantidad.
Existen otras tablas con productos qumicos, etc, pero no necesitar modelarlas. Tenga
en cuenta que hay ms de una relacin entre laboratorio y empleado y esto podra crear
ms complicaciones y confusiones en un sistema real como el del MITCIS, aunque son
bastante frecuentes.
6 de 15
Deber crear un modelo de datos que se corresponda con este conjunto de reglas
de negocio. Siga estos pasos. Slo deber entregar un diagrama con todos los
elementos incluidos en los pasos a-e.
a. Incluya un cuadro para cada entidad: nmbrelo correctamente. Si hay
demasiadas relaciones entre distintos elementos del modelo, muestre la
entidad asociativa (intermedia) explcitamente. (5 puntos)
b. Enumere los atributos del cuadro de ca da entidad. (5 puntos )
c. Indique la clave principal de cada entidad con las letras (CP)
junto al nombre. (2 puntos)
d. Establezca todas las relaciones entre las entidades del modelo.
Indique las claves externas con las letras (CE) junto a los atributos
que son c la ves externas . (5 puntos )
e. Indique la cardinalidad de la relacin: varias-varias, varias-una o
una-una. Utilice notacin de patas de gallo; si utiliza cualquier otra
notacin, defnala previamente. (3 puntos)
Recordatorio: slo ne cesitar entre gar un diagra ma que c on todo s lo s elementos
incluidos en los pa sos a-e a nteriores .
7 de 15
Departmento
CP IDO rg.
Escuela
CentroInvestig.
PK IDOrg.
LmC rdito
DepAdmin
CP IDOrg.
NombreAdmin.
DireccAdmin.
EmailAdmin.
Regin
CP IDRegin
DescrRegin
Lab.
CP IDLab
NombrLab
PersLab
TelfLab
DireccLab
EmailLab
CP1 IDRegin
C P2 ID Org.
Organizacin
CP IDOrg
NombreOrg
DireccOrg
TelfOrg
RegionLocation
CP,CA1 IDRegin
CP,CA2 NombreUbic.
Ubicacin
CP NombreUbic.
QuimEnMano
QuimPorPedido
Empleado
CP EmpID
NombrEmp
EmailEmp
DirecEmp
CP1 IDRegin
PedidoQuim
LabEmpleado
CP,CA1 IDEmp
CP,CA2 IDLab
AC3 Papel
Papel
CP Papel
DescrPapel
CP IDPedido
FechPed
CP1 IDEmp
CP2 IDLab
DetallePedido
CP IDArtic
CP,CA1 IDPedido
Cantidad
8 de 15
3. Base de datos. (20 puntos)
Basndose en el modelo de datos de la pregunta 2, crear una base de datos en la que
las tablas, los atributos y las relaciones se correspondan exactamente con la estructura
del modelo de datos. Se le pide que escriba las siguientes consultas SQL en su base de
datos. Puede utilizar SQL estndar o sintaxis SQL de MS Access. Indique cul utiliza.
Brevemente, defina cualquier variable que vaya a utilizar y que no resulte obvia.
a. Enumere los nombres de los laboratorios de cada empleado, para
todos los empleados. Muestre el DI de empleado, el papel del
empleado y el nombre del laboratorio. Ordene todo por ID de
emple ado. (6 puntos )
SQL estndar:
SELECT EmpleadoLab.IDEmp, EmpleadoLab.Papel, Lab.NombreLab
FROM Lab , EmpleadoLab
WHERE Lab.IDLab= EmpleadoLab .IDLab
ORDER BY EmpleadoLab.IDEmp;
SQL de Acce ss:
SELECT EmpleadoLab.IDEmp, EmpleadoLab.Papel, Lab.NombreLab
FROM Lab INNER JOIN EmpleadoLab ON Lab.IDLab = EmpleadoLab.IDLab
ORDER BY EmpleadoLab.IDEmp;
b. Incluya una lista de nmeros de artculos con la cantidad mxima de
cada pedido. Incluya tambin el nmero y cantidad de artculos y el
nmero de pedido. (Omita las restricciones de Access que limita a una
sola columna la operacin mxima que puede mostrarse en el
conjunto de resultados si recurre al uso de sintaxis SQL de Access).
(7 puntos)
SQL estndar:
SELECT Max(DetallePedido.Cantidad), DetallePedido.IDPedido, DetallePedido.IDArt
FROM DetallePedido
GROUP BY DetallePedido.IDPedido;
SQL de Acce ss:
SELECT Max(DetallePedido.Cantidad), DetallePedido.IDPedido, DetallePedido.IDArt
FROM DetallePedido
GROUP BY DetallePedido.IDPedido;
9 de 15
c. Elimine los empleados que no se encargan de ningn
laboratorio (es decir, aquellos ID de empleado que no se
muestran en la tabla laboratorio-empleado). (Asuma que estos
empleados no estn en los pedidos que evitaran que se
pudiesen eliminar de la tabla de empleados). (7 puntos)
SQL estndar, SQL de Access:
DELET E Empleado.*
FROM Empleado
WHERE Empleado.IDEmp NOT IN (SELECT EmpleadoLab.IDEmp FROM
EmpleadoLab);
10 de 15
11 de 15
4. World Wide Web. (20 puntos)
Para cada una de las siguientes preguntas, redacte una respuesta corta (2-4 frases):
a. TCP/IP se desconecta despus de cada respuesta y peticin HTTP?
Por qu? Por qu no? (4 puntos)
S, se desconecta despus de cada respuesta y peticin HTTP. Si la sesin se mantuviese
durante todas las respuestas y peticiones, se ocuparan demasiados recursos en el
servidor. Tambin debera desconectarse una vez superado un tiempo de espera si el
usuario no la cierra explcitamente (en realidad, esto es slo un ejemplo del uso excesivo
de recursos por conexiones conservadas).
b. SSL se desconecta despus de cada respuesta y peticin HTTP? Por
qu? Por qu no? (4 puntos)
No, no se desconecta. Como la negociacin entre el cliente y el servidor es cara, implica
claves pblicas para generar claves de sesin y analizar certificados, se realiza una sola
vez al inicio de una sesin. Si se desconectase con cada peticin y respuesta, el proceso
sera muy lento. Aadir complicaciones como sta al SSL aumentara tambin el riesgo
de errores y se convertira en un agujero de seguridad.
c. Qu diferencia existe entre una peticin HTTP POST y GET? Se
pueden enviar los datos desde el navegador hacia el servidor HTTP
con ambas peticiones? (4 puntos)
Una p etic i n GET enva un URL y distin to s par metros des pu s de u n delimitado r ? Se
preten de "obtene r" la siguiente p gina web, p osibleme nte basn dos e en los par metro s.
La lnea en blanco finaliza la peticin GET. Las peticiones POST estn diseadas para
enviar datos a un URL. Despus de la lnea en blanco, el servidor espera recibir todos los
datos enviados, por lo que el POST funciona mejor cuando se envan muchos datos.
Tanto la peticin GET como la peticin POST son, a menudo, intercambiables.
d. Puede una pgina Active Server enviar un archivo de comandos
para que se ejecute en un navegador? De ser as, cmo distingue
entre archivos de comandos ejecutados en el servidor y ejecutados en
el navegador? (2 puntos)
S, ASP puede enviar un archivo de comandos de navegador. En ASP, los archivos de
comandos encerrados entre las etiquetas <% %> o <SERVER> y </SERVER> se ejecutan
en el servidor. Asimismo, los complementos del lado del servidor, que estn delimitados por
< -- ! -- !> se ejecutan en el servidor. Los archivos de comandos delimitados por
<SCRIPT> y </SCRIPT> se envan al navegador para que se ejecuten en l.
e. Supongamos que un formulario HTML contiene un rea de dibujo
en la que el usuario puede dibujar algo con el ratn y, a continuacin,
enviarlo co n un POST y su base de datos puede almacenar la imagen
12 de 15
directamente (como un objeto binario) en una tabla: podra una
pgina Active Server e scribir la image n en la base de datos? Puede
asumir que la imagen es un archivo .gift. Por qu? Por qu no?
Si es posible , describa bre ve me nte cmo lo hara. (6 puntos)
Nota sobre el apartado e: en el MITCIS se desea que la persona que presta el servicio
pueda dibujar un diagrama de procedimientos de seguridad para una demostracin de
productos qumicos, por ejemplo, el equipo necesaria si hay una fuga, distancias
requeridas de aislamiento, etc. Una imagen sencilla suele ser muy eficaz y el sistema del
MITCIS debera ser capaz de generar este tipo de imgenes en el navegador y
almacenarlas posteriormente en el servidor.
Respuesta:
Puede enviar un archivo .gif con POST. La peticin HTTP POST contendra el URL de
la pgina Active Server que procesa el .gif. El cuerpo del gif debera enviarse despus de
una lnea en blanco en la peticin HTTP como archivo binario representado por datos de
caracteres. (Seguro que ha visto alguna vez archivos adjuntos que no se procesan
correctamente y que se muestran como pginas de caracteres aleatorios). La pgina
Active Server que recibe la peticin POST debera tener VBScript o cualquier otro
cdigo para leer el archivo .gif lnea por lnea, transformarlo si es necesario y escribirlo
en un archivo en el servidor.
13 de 15
5. Redes de telecomunicaciones. (20 puntos)
El sistema del MITCIS se implementar a travs de la intranet del MIT, que cuenta con
enlaces de capa 1 de fibra, de cobre e inalmbricos.
a. Describa dos forma s ra zonables me diante la s cuales el MI T pue de
ampliar su intranet a los grupos y oficinas residentes en el centro
urbano de Boston, al otro lado del ro Charles. La distancia
aproximada es 3 km. Los grupos constan de unas 40 personas cada
uno; hay aproximadamente 15 repartidos en 5 oficinas. Casi todos se
ubican unos al lado de otros. El MIT no puede desplegar cableado de
ningn tipo entre el campus del MIT y estos emplazamientos, ya que
no cuenta con los permisos correspondientes. (4 puntos)
DSL: 3 kilmetros son 1,9 millas o unos 10.000 pis, que est dentro del rango de
distancias de DSL. Se trata de ancho de banda econmico y sera el indicado. Las
distintas lneas DSL se ofreceran a cada grupo y a cada oficina.
Microondas: como la distancia es corta y no hay edificios que la obstaculicen, la opcin
de las microondas tambin es factible. Para limitar el nmero de transmisores y
receptores, la red Ethernet se ejecutara entre grupos y oficinas colindantes en la zona de
Boston.
Cable-mdem: similar al DSL, pero al ser compartido, la seguridad podra plantear
problemas importantes. El trfico debera estar cifrado y, como consecuencia, se
reducira la velocidad.
RDSI: es otra opcin, aunque cara y de banda estrecha. No es demasiado atractiva.
b. De las opciones que ha definido en el apartado anterior,
cul es la que recomendara? Por qu? (4 puntos)
DSL es, en principio, la ms factible, ya que cada grupo de viviendas y oficina tiene
su propia conexin de banda ancha relativamente segura, propia y dedicada. DSL es,
probablemente, la mejor recomendacin.
La solucin de las microondas tambin es posible, pero requerira varios sitios en Boston,
ya que el MIT no puede conectarse con su propio cableado a sitios que no sean
colindantes.
El cable-mdem es similar al DSL, pero requerira cifrado, por lo que el rendimiento
sera menor.
c. El MIT desea implementar el protocolo IPSec (IP segura). A qu
capa o capas afecta esta implementacin? Sera necesario
modificar el resto de las capas? Considere nicamente las capas
1, 2, 3, 4 y 7, tal como hemos hecho en clase. (4 puntos)
IPSec, o IP segura, afecta nicamente a la capa 3, la capa IP. No sera necesario
realizar cambios en el resto de las capas; el modelo de capas ofrece exactamente la
independencia que se pide en el ejercicio y sta es la razn por la que se implement
este modelo de capas.
14 de 15
d. Si el MIT implementa el protocolo IPSec tal como ha descrito en
el apartado c, qu software se debera modificar en los clientes
(PC, estaciones de trabajo) y en los servidores? (4 puntos)
El MIT necesitara cambiar el software de TCP/IP de cada PC, estacin de trabajo,
servidor y el resto de dispositivos de la red. Siendo totalmente estrictos, slo sera
necesario cambiar el software de IP, pero casi siempre va unido al de TCP/IP
(incluyendo UDP/IP, que no hemos tratado en clase).
e. Si el MIT e limina to dos los e nlace s de c apa 1 de cobre y los
convierte en enlaces de fibra o en inalmbricos en su red principal,
qu software y hardware se debera modificar en los clientes (PC,
estaciones de trabajo) y en los servidores? Deber asumir que los PC
estn conectados mediante cable 10BaseT o 100BaseT a
routers/concentradores, o que estn conectados de forma
inalmbrica. La red principal es la que conecta los puentes, routers
y servidores entre da y con los puntos de acceso a Internet. Asuma
tambin que el protocolo es Ethernet sobre cobre que, despus, pasa
a Ethernet sobre fibra o inalmbrico. (4 puntos)
Las tarjetas de capa 2 (normalmente de Ethernet) que estn actualmente conectadas a los
enlaces de capa 1 de cobre deberan cambiarse por tarjetas que funcionen con fibra o con
enlaces inalmbricos. No sera necesario realizar ninguna modificacin en el software.
15 de 15