Unidad 2.en - Es

2
Análisis de requisitos:
Conceptos
En este capítulo aprenderá a desarrollar descripciones de los servicios de redes y para
identificar y / o derivar los requisitos de red del sistema. Usted aprenderá que los
requisitos de red están acoplados a los servicios y desarrollarán una especificación de
requisitos para trazar los requisitos y ayudar a determinar sus dependencias. Usted
aprenderá cómo aplicar los conceptos tratados en el último capítulo de una variedad de
usuarios, aplicaciones y requisitos de los dispositivos y desarrollar tanto una
especificación de requisitos y un mapa de aplicaciones.
2.1 objetivos
En este capítulo ampliamos el concepto de requisitos para una red. Ajustamos el
proceso general de la ingeniería de sistemas, introducidos en el capítulo anterior, al
problema de la creación de redes. Hablaremos de diferentes tipos de requerimientos,
a partir de los componentes de usuario, aplicaciones, dispositivos y redes. Y aprenderá
acerca de la agrupación de requisitos juntos, y un mapa de localización de aplicaciones
y dispositivos. La combinación de todos los requisitos y las ubicaciones se expresa
en dos documentos: una especificación de requisitos y un mapa de requisitos.
2.1.1 Preparación
Existe poca información sobre el proceso de análisis de los requisitos que se aplica a las
redes. Sin embargo, hay algunos excelentes materiales de preparación que son de
carácter más general de ingeniería de sistemas que proporcionará una visión general del
proceso de análisis de requisitos.
58 CAPÍTULO 2: Conceptos de Análisis de Requisitos
2.2 Fondo
Como ya se habrán dado cuenta, la parte de análisis de red de este libro, que consiste en
los requisitos y análisis de flujo y riesgo, introduce muchos conceptos y directrices
nuevos y amplía varios conceptos existentes. Por lo tanto, el análisis de requisitos y
análisis de flujo se separan en tres capítulos, que abarcan los conceptos y
procedimientos, respectivamente, con el fin de hacer que este material sea más legible
y útil. Los capítulos sobre conceptos proporcionan material de referencia para cada
tema, explicando y definiendo conceptos pertinentes. Los capítulos sobre
procedimientos amplían estos conceptos para construir un proceso para que aplique a
sus arquitecturas y diseños.
Comenzamos el proceso de análisis de red con análisis de requerimientos, que es reunir
y deriver los requisitos p a r a entender los comportamientos de sistemas y de la red.
Esto consiste en identificar, runnir, derivar, y comprender de los requisitos del sistema
y sus características; el desarrollo de umbrales y límites de rendimiento para distinguir
entre los servicios de bajo y de alto rendimiento; y determinar donde mejor esfuerzo,
predecible, y los servicios garantizados pueden aplicarse en la red.
2.2.1 Requisitos y Características

Los requisitos son descripciones de las funciones de red y el rendimiento necesarios para
que la red pueda apoyar con éxito a sus usuarios, aplicaciones y dispositivos (y por tanto
el éxito del proyecto de la red). Usando esta definición, se deben cumplir todos los
requisites para que la red tenga éxito. Sin embargo, como veremos, puede haber un
montón de requisitos, de una variedad de fuentes, con diversos grados de viabilidad. Si
tenemos en cuenta todos los requisitos de todas las fuentes son necesarios para el éxito
de la red, entonces es probable que las expectativas de ajuste no se pueden cumplir. Por
lo tanto, como parte del proceso de análisis de requisitos, hay que clasificar y priorizar
necesidades, la determinación de los que son verdaderamente los requisitos para la red
y aquellos que puede ser deseable, pero no son verdaderamente requisitos.
Los requisitos que se determinen como necesarios para el éxito del proyecto de la red se
denominan requisitos básicos o fundamentales. Dado que estos requisitos son necesarios
para el éxito del proyecto, tiene que haber alguna manera de determinar el éxito. Por lo
tanto, asociado con cada requisito basico/ fundamental es uno o más métrica. Las métricas
son mediciones o demostraciones para cada requisito.
59
Ejemplo 2.1. Ejemplos de requisitos básicos y sus métricas asociadas

son:
Rendimiento: La red deberá ser capaz de proporcionar un rendimiento mínimo de
•extremo a extremo de 100 Mb / s entre los dispositivos finales. Métricas: Medición
entre dispositivos finales seleccionados (el conjunto de los cuales TBD), utilizando
aplicaciones de (Lista de aplicaciones), bajo condiciones de prueba (Lista de
condiciones).
•
Seguridad: La red debe ser capaz de filtrar paquetes basados en una lista de control de
acceso (ACL). Métricas: Demostración de filtrado de paquetes no deseados, basado
en el ACL proporcionado, inyectado en la red.
Las funciones y el rendimiento de la red que se desean pero no son necesarios
para el éxito del proyecto de la red se denominan caracteristicas. Habrá requisitos
que, como parte del proceso de análisis, se han determinado como características
para la red. Además, habrá requisitos que pueden ser considerados en una versión
posterior de la red, los que serán rechazado durante el proceso de análisis, y los
requisitos que son más informativo de lo requerido.
Como se muestra en la figura 2.1, los requisitos se separan en requisitos básicos
o fundamentales (aquellos que se consideran necesarios para esa red), las
características que son deseables para esa red, los que puede ser considerado en
una versión posterior o actualización de la red, y los requisitos que han sido
rechazadas (por ejemplo, no es realmente necesario, deseable, realista, o
ejecutables). Cada red debe tener, como mínimo, un conjunto de requisitos
basicos; es probable que también tengan un conjunto de
Requisitos básicos
para la Red
Características para la
Red
Requisitos reunidos y
Análisis de Requerimietos para
derivados de los
futuras revisiones /
usuarios, Requerimientos actualizaciones
Equipo administrativo
Requerimientos
Rechazados
Requisitos
informativos
FIGURA 2.1 Los requisitos se separan en requisitos básicos / fundamentales, características, requisitos futuros, rechazados e
informativos
requisitos informativos y pueden tener conjuntos de características, las requisitos

futuras, y los requisitos rechazado.
Los requisitos se clasifican durante el proceso de análisis de requisitos, a través de
conversaciones con los usuarios, la administración y el personal, y son aprobados
(firmados) por la administracion. En la práctica, el grupo de análisis realiza un
primer intento de categorización, presentado a la administración para determinar si
esta clasificación está en el camino correcto, y luego se desarrolló aún más con el
aporte de los usuarios, la administración y el personal.
Un método para clasificar los requisitos se basa en la práctica actual del Equipo de
Tareas de Ingenieria en Internet (IETF). RFC 2119 identifica las palabras y frases
que se pueden utilizar para describir la importancia relativa de un requisito clave.
Estas palabras y frases clave son Debe / deberan / requerida, no debe / no podrá,
debería / recomendados, no debe / no se recomienda, y Mayo / Opcional:
 Debe / deberan / requerida. Estas palabras clave indican un requisito
absoluto y se incluyen como requisitos básicos o fundamentales para la red.
 No debe / no convierte. Estos también son requisitos absolutos que indican
una restricción o prohibición de una función o tarea. Estos también se
incluyen como requisitos básicos o fundamentales para la red.
 Debería / recomendados. Estas palabras clave indican que el requisito

puede ser válida, pero que su aplicación no es absolutamente necesaria para
el éxito de la red. Tales requisitos se pueden categorizar como
características o necesidades futuras de la red.
 No debe / no se recomienda. Al
igual que con debería / recomendados, estas frases
indican que un requisito puede ser válido (en este caso, para prohibir una
función o tarea), pero que su aplicación no es absolutamente necesaria para
el éxito de la red. Tales requisitos también se pueden clasificar como
características o necesidades futuras de la red.
 Mayo / opcional. Cuando un requisito es verdaderamente opcional, puede ser

categorizado como una característica o requisite future, o puede ser
rechazado.
Mediante el uso de estos términos, usted ayuda a asegurar que no hay confusión
con respecto a los requisitos y características. Se discute la categorización de los
requisitos en mayor detalle al final del capítulo, cuando desarrollamos la
especificación de requisitos.
2.2.2 La necesidad de análisis de requerimientos
¿Por qué hacer el análisis de requisitos? Aunque el análisis de requisitos 61 es

fundamental para la arquitectura y el diseño de la red, a menudo se pasa por alto o
ignorado. ¿Por qué es este el caso? Importante motivo de ello que el análisis de
requisitos no se le da la debida consideración es el grado de dificultad. Recopilación
de requisites significa hablar con los usuarios, personal de la red, y la gestión, y la
interpretación de los resultados. Hablando a unos usuarios pueden dar lugar a N + 1
conjuntos diferentes de los requisitos del usuario. el personal y la gestión de la red a
menudo se distanciado de los usuarios y no tienen una idea clara de lo que los usuarios
quieren o necesitan. Además, el análisis de requisitos puede parecer que no ofrecen
ninguna recompensa inmediata. Por último, el análisis de requisites significa poner el
pensamiento y el tiempo en la preparación para la arquitectura y el diseño.
El no poder hacer el análisis de requisitos adecuada puede dar lugar a una arquitectura
de red y el diseño que se basa en factores distintos a lo que los usuarios, aplicaciones
o dispositivos necesitan. Por ejemplo, la red puede basarse en una tecnología cuyo
principal activo es simplemente que el diseñador se siente cómodo con él. O quizás
es una red basada en el equipo de un proveedor en particular, una vez más a menudo
que el diseñador se siente cómodo. Otro ejemplo obvio es un proyecto que tiene una
restricción de presupuesto o plazo que obliga al diseñador para hacer hacer y uso
familiar, aplique fácil de tecnologías. Los problemas con este tipo de opciones son
que no son objetivos y que las tecnologías o proveedores familiares no pueden ser las
decisiones correctas para esa red en particular.
El análisis de requerimientos ayuda al diseñador a comprender mejor el
comportamiento probable de la red que se está construyendo. Esto da lugar a varios
beneficios:
• Más objetiva, decisiones informadas de las tecnologías y servicios de red
• La capacidad de aplicar la tecnología y topología de los candidatos a las redes
• Redes y elementos de tamaño adecuado para los usuarios y las aplicaciones
• Una mejor comprensión de dónde y cómo aplicar los servicios en la red
Además, las compensaciones en la arquitectura y el diseño se deben realizar con

el cuadro total en mente. A veces esto no se aclara hasta que todos los usuarios,
la gestión y el personal han sido consultados y todos los requisitos identificados.
Muchos esfuerzos de rediseño son el resultado de un conjunto inicialmente
incompleta de requisitos.
A medida que avance a través del resto de este libro, se verá que el proceso de
análisis de los requisitos es la base sobre la cual la arquitectura de red y los
procesos de diseño se construyen.
En el proceso de análisis de los requisitos que utilizamos requisitos para distinguir

entre bajo y alto rendimiento para aplicaciones de nuestras redes; identificar los
servicios específicos; reunir los requisitos de rendimiento para su uso en análisis
de flujo; y reunir otros requisitos para ser utilizados en los procesos de análisis,
arquitectura, y diseño. Nos enteramos de que las actuaciones de baja y alta son en
relación con la red que estamos trabajando, y desarrollamos y aplicamos los
umbrales de rendimiento y los límites para ayudar a distinguir entre ellos.
Como se mencionó anteriormente, los resultados de análisis de requisitos en una
especificación de requisitos y unos requisitos mapa. UNA especificación de requisitos
es un documento que recoge y da prioridad a los requisitos recogidos para su
arquitectura y diseño. Los mapa de los requisitos muestra las dependencias de
localización entre las aplicaciones y dispositivos, que serán utilizados para el análisis
de flujo.
A lo largo de esta sección (y los otros en este libro) directrices se presentan en la
forma en que cada proceso puede ser implementado. Estas directrices son de la
experiencia práctica y se deben utilizer como punto de partida para que pueda
desarrollar su propio conjunto de directrices. A medida que avanzamos, se le anima
a pensar en cómo se podría implementar cada directriz, y cómo le adición o
modificación de la misma.
2.3 Requisitos de usuario

En el modelo de componentes de sistema en nuestro sistema genérico, el componente
de usuario está en la capa más alta. El termino usuario representa principalmente a los
usuarios finales del sistema, pero puede ser ampliado para incluir todos los
involucrados en el sistema, tales como redes y sistemas, administradores y directivos.
Requisitos de usuario comprender el conjunto de requisitos que se obtuvieron o derivan
de entrada del usuario y representan lo que se necesita por los usuarios para llevar a
cabo con éxito sus tareas en el sistema. Por lo general, cuando se reúnen los requisitos,
todos los involucrados en esa red se considera un usuario potencial. La figura 2.2
muestra algunos de los requisitos de usuario de ejemplo.
Comenzamos requisitos que describen en esta capa, lo que conducirá a la elaboración
de requisitos más específicos a medida que trabajamos a través de cada uno de los
componentes.
Desde la perspectiva del usuario, podemos preguntar: “¿Qué se necesita para hacer el
trabajo?” Esto usualmente resulta en un conjunto de requisitos cualitativos, no
cuantitativos, parte de nuestro trabajo en la recolección y derivados de necesidades de
los usuarios es hacerlos cuantitativos siempre que sea posible.
63
Usuario Requerimientos de usuarios
oportunidad
Aplicacion interactividad
confiabilidad
Calidad de presentación
adaptabilidad
Dispositivo Seguridad
Asequibilidad
Funcionalidad
Compatibilidad
Red Crecimiento futuro
Figura 2.2 Tipos de requisitos de usuario
En general, el sistema debe adaptarse a los usuarios y sus entornos, proporcionar un acceso rápido y
fiable de información y transferencia, y ofrecen servicio de calidad al usuario. Esto indica los siguientes
requisitos generales:
• Oportunidad
• interactividad
• Confiabilidad
• calidad de presentación
• Adaptabilidad
• Seguridad
• asequibilidad
• funcionalidad
• compatibilidad
• Crecimiento futuro
Los requerimientos de usuarios son los menos técnica y también son los más subjetiva.
Como se muestra en la figura 2.3, los requisitos se hacen más técnico medida que pasan
de los usuarios a la red. Todos estos requisitos se desarrollan con más detalle como se
procede a través de los componentes de aplicación, el dispositivo y la red.
Nuestra intención es utilizar estos requisitos básicos como punto de partida hacia el
desarrollo de los requisitos más objetivas y técnicas en los otros componentes. Estos
requisitos ejemplo, se presentan como una guía para su uso en el desarrollo de los requisitos
para su red, y puede cambiar, dependiendo del entorno del usuario.
64 CAPÍTULO 2 requisitos de análisis: Concepts
usuarios Nivel más alto, menos técnico
Aplicación
Dispositivo
red
Nivel más bajo, más técnicos
Servidores Switches routers
FIGURA 2.3 Requisitos vuelto más técnico medida que se acercan a los dispositivos de red
Timeless es un requisito que el usuario pueda acceder, transferir o modificar la información

dentro de un marco de tiempo aceptable. Lo que es un marco de tiempo “tolerable” es, por
supuesto, depende de la percepción del usuario de retraso en el sistema. Es esta percepción que
queremos cuantificar. Por ejemplo, un usuario puede querer descargar archivos desde un
servidor y completar cada transferencia dentro de los 10 minutos. O el usuario puede necesitar
recibir tramas de vídeo cada 30 ms. Cada uno de estos tiempos indica un retraso que tendrá la
red para proporcionar. Para puntualidad, de extremo a extremo o el retraso de ida y vuelta puede
ser una medida útil.
La interactividad es similar a la puntualidad pero se centra en un tiempo de respuesta del sistema
(así como la red) que se encuentra en el orden de los tiempos de respuesta de los usuarios. En
el ejemplo anterior los 10 minutos necesarios para descargar el archivo podría ser considerado
como el tiempo de respuesta para el sistema, y podríamos considerer también que la
transferencia de archivos es la interacción con el usuario (que lo es), pero el grado de
interactividad es muy bajo y no de mucho interés desde el punto de vista arquitectónico o de
diseño. Lo que es interesante es cuando los tiempos del sistema y la respuesta de la red están
cerca de los tiempos de respuesta de los usuarios, ya que entonces los cambios realizados en la
arquitectura y diseño de la red para optimizar los tiempos de respuesta pueden tener un impacto
directo sobre la percepción de la interactividad de los usuarios. Por lo tanto, interactividad es
una medida de los tiempos de respuesta del sistema y de red cuando están obligados a
interactuar activamente con los usuarios. Retraso de aquí el retardo de ida y vuelta, -es una
medida de la interactividad. El uso de estas descripciones de la puntualidad y la interactividad,
a continuación, la oportunidad es más probable que esté asociado con archivo granel o
transferencia de imágenes, mientras que la interactividad es probable que esté asociado con el
dispositivo de acceso remoto (por ejemplo, telnet), uso de la Web, o visualización.
Requisitos del usuario 65
Confiabilidad, es decir, la disponibilidad desde la perspectiva del usuario, es un requisito para el

servicio constantemente disponible. No sólo es necesario que el usuario podrá tener acceso a los
recursos del sistema un porcentaje muy alto de las veces, pero el nivel de servicio al usuario (en
términos de uso de la aplicación o la entrega de la información) debe ser consistente. Por lo tanto,
la fiabilidad está estrechamente relacionada con la característica de rendimiento de fiabilidad
(discutido en el capítulo 1 como parte de RMA), pero el retardo y la capacidad también son
importantes. Es probable que una combinación de todas las características de rendimiento se
utiliza para describir la fiabilidad.
La calidad de presentación se refiere a la calidad de la presentación al usuario. Esta puede ser la

percepción del usuario de pantallas de audio, vídeo y / o datos. A modo de ejemplo, considere las
capacidades actuales de Internet de videoconferencia, alimentaciones de vídeo (directo o en
diferido), y telefonía. Si bien es posible hacer todo esto en Internet, hay otros mecanismos que
actualmente proporcionan mucho mejor calidad de presentación. Que a menudo no es suficiente
para proporcionar una capacidad de más de una red, pero esa capacidad debe ser tan buena o mejor
que serán decepcionados otros mecanismos, o el usuario. arquitectos y diseñadores de red a
menudo se pierda este concepto. Medidas de calidad incluirán todas las características de
rendimiento.
Adaptabilidad es la capacidad del sistema para adaptarse a las necesidades cambiantes de los
usuarios. Algunos ejemplos de esto se pueden encontrar en la distancia a la independencia y la
movilidad. A medida que los usuarios confían cada vez más en la red, se están convirtiendo
acoplados a los servicios lógicos y desacoplados de los servidores físicos. Este desacoplamiento
significa que los usuarios no tienen que preocuparse donde se encuentran los servidores, siempre
y cuando puedan obtener los servicios que necesitan. Un resultado de esto es la computación
independiente de la distancia, en el que el usuario pierde todo el conocimiento de donde los
trabajos están siendo ejecutados, o en los que se obtienen los datos, almacenados, o migraron a
través de la red. Movilidad se refiere a la informática móvil o nómada, donde el usuario puede
accede a los servicios y recursos desde cualquier lugar, utilizando dispositivos portátiles y acceso
inalámbrico a la red. Adaptabilidad a las necesidades del usuario tales requisitos fuerzas en la
arquitectura y el diseño del sistema.
La seguridad desde la perspectiva del usuario es un requisito para garantizar la confidencialidad,
integridad y autenticidad de la información de un usuario y los recursos físicos, así como el
acceso a los recursos del usuario y del sistema. La seguridad es probablemente más cercano a
la fiabilidad de funcionamiento característico, pero tendrá un impacto en la capacidad y retrasar
así.
La asequibilidad es el requisito de que las compras de ajuste dentro de un presupuesto. A pesar
de que este requisito no es técnico, su impacto en la arquitectura y el diseño. Lo que nos
interesa en este requisito es lo que los usuarios pueden permitirse o gestión para la compra de
la red, por lo que nuestra arquitectura y el diseño no cuestan demasiado como para poner en
práctica. Como requisito del usuario, vamos a ver cómo los costos y la financiación están ligados a
los usuarios, grupos de usuarios, y la gestión. También consideramos la financiación como un
requisito de todo el sistema, desde el punto de vista del presupuesto global.
funcionalidad abarca cualquier requisito funcional que el usuario tiene para el sistema.
Las funciones que realizará el sistema a menudo están vinculados a las aplicaciones que
se utilizan en el sistema. La comprensión de la funcionalidad es importante, ya que
conduce a los requisitos de aplicación (cubiertos en la siguiente sección). Parte de la
funcionalidad de la comprensión es determinar qué aplicaciones de realidad quieren o se
aplican en su trabajo diario. No queremos analizar aplicaciones que nadie se va a utilizar.
La compatibilidad es un conjunto de características que describe qué tan bien el cliente

puede mantener la red funcionando en un rendimiento diseñado, a través de toda la gama
de escenarios de las misiones descritas por el cliente durante el proceso de análisis de
requisitos. Esto incluye cómo los usuarios quieren o necesitan ser apoyados por su personal
de operaciones de red, y cualquier interfaz que tendrán con un centro de operaciones de red
(NOC). Por ejemplo, será la necesidad de reconfigurar la red para satisfacer las necesidades
de los usuarios diferentes o cambiantes?
¿Qué aplicaciones tendrá el personal de operaciones de la red y / o NOC necesita para
proporcionar soporte a los usuarios e identificar y solucionar problemas en la network?
Información como esta se usará más adelante como entrada a la red Arquitectura de gestión
de red.
Crecimiento futuro es determinar si y cuando los usuarios están planeando desplegar y
utilizar las nuevas aplicaciones y dispositivos en la red.
Además de estos requisitos, queremos saber cuántos usuarios se espera en la red, y su
ubicación. Si es posible, hay que estimar el crecimiento de los usuarios durante los primeros
uno a tres años después de la red en funcionamiento, o durante el ciclo de vida esperada de
la red.
2.4 requerimientos de aplicacion
. Las interfaces de componente de aplicación con los componentes de usuario y

dispositivo y es una parte clave del análisis de requisitos. Requerimientos de aplicacion
son los requisitos que se determinan a partir de información de la aplicación, la
experiencia o prueba, y representan lo que se necesita por las aplicaciones para operar
con éxito en el sistema.
Figura 2.4 muestra los requerimientos de ejemplo de aplicación. requisitos de aplicación
son más técnico que las necesidades del usuario, pero todavía puede ser subjetiva.
Requisitos de la solicitud 67
usuarios
Aplicación Requerimeientos de aplicaciones
Tipos de aplicación
Dispositivo Grupos de Aplicaciones
Locaalización de aplicacion
red
FIGURA 2.4 Tipos de Requisitos de la solicitud
2.4.1 Tipos de aplicaciones

En la descripción del sistema (usuario, la aplicación, dispositivo, red), el componente de
aplicación es fundamental. Este componente es a menudo donde se determinan muchos
requisitos para la red, ya que los usuarios las aplicaciones de par y dispositivos a la red.
Aplicaciones son a menudo de extremo a extremo, entre múltiples dispositivos; por lo
tanto, sus requisitos abarcan la red subyacente.
En los primeros días de la creación de redes, las aplicaciones requieren conectividad básica
y la transferencia de datos a través de la red. Mientras que las aplicaciones todavía tienen
estos requisitos, que a menudo también se requiere que sea de alto rendimiento o tener un
comportamiento predecible o garantizados, para apoyar las necesidades del usuario para la
puntualidad, la interactividad, la fiabilidad, la calidad, la adaptabilidad y la seguridad. Por
lo tanto, los requisitos de usuario tienen un impacto en los requisitos de la aplicación.
Podemos utilizar estos requisitos de servicio y de rendimiento para distinguir entre
aplicaciones que necesitan un servicio predecible o garantizados y los que pueden utilizar el
servicio de mejor esfuerzo.
Sobre la base de los requisitos de servicio y de rendimiento, escribimos como
aplicaciones de misión crítica, la velocidad crítica, o en tiempo real / interactivo, donde
• Las aplicaciones de misión crítica tienen requisitos RMA predecible, garantizados,

y / o de alto rendimiento.
• Las aplicaciones de tasa creitica tienen requisites de capacidad predecibles,

garantizados, y/o de alto rendimiento.
• Las aplicaciones en tiempo real e interactivas tienen requisites de retardos

predecibles, garantizado, y/o alto rendimiento.
Este tipo de aplicaciones son descritos por sus requisitos y métricas de servicio.
RMA
Vamos a primer vistazo a RMA, que consiste en la fiabilidad, mantenibilidad y
disponibilidad. La fiabilidad es una medida estadística de la frecuencia de fallo de la red
y sus componentes y representa los interrupciones no programadas de servicio. La
mantenibilidad es una medida estadística de la hora de restaurar el sistema al estado en
pleno funcionamiento, una vez que se ha encontrado un error. La disponibilidad es una
medida de la relación entre la frecuencia de fallos de misión crítica y el tiempo para
restablecer el servicio. ¿Cómo estas medidas se refieren a las aplicaciones que usarán la
red?
requisitos RMA puede ser subjetiva. Muchos usuarios afirman que sus aplicaciones
requieren un alto grado de fiabilidad, facilidad de mantenimiento, y / o disponibilidad de
la red, pero hay algunas aplicaciones que deben mantener altos grados de RMA con el fin
de funcionar. Una pérdida de cualquier parte de RMA en tales aplicaciones pueden ser
graves o desastroso, tales como:
• Pérdida de ingresos o clientes. Los ejemplos incluyen las aplicaciones que manejan
una gran cantidad de transacciones y dinero, como la banca de inversión, reserva de
vuelos, o aplicaciones de procesamiento de tarjetas de crédito.
• información irrecuperable o situación. aplicaciones de procesamiento de
telemetría y de teleconferencia son buenos ejemplos de este tipo de fiabilidad.
• La pérdida de datos sensibles. Los ejemplos incluyen cliente aplicaciones

intelligencegathering ID /
facturación y.
• Pérdida de vida. Los ejemplos incluyen aplicaciones de monitoreo de transporte o

para el cuidado de la salud.
En estas situaciones, ya sea el sistema no está disponible para procesar las solicitudes de
usuario / aplicación o el sistema no está disponible para completar las transacciones que
están en curso. Para las aplicaciones de este tipo, una red que ofrece servicio sólo de mejor
esfuerzo no es probable que sea adecuada, debido a su comportamiento impredecible y
poco fiable. Estas aplicaciones requieren predecible o garantizados fiabilidad, facilidad de
mantenimiento, y la disponibilidad, que puede tomar la forma de un RMA predecible o
limitada, o un alto grado de RMA, o ambos. Las aplicaciones que requieren de RMA
predecible o alto se denominan aquí las aplicaciones de misión crítica.
Capacidad
En términos de capacidad, hay algunas aplicaciones que requieren un grado predecible,
limitada, o de alta capacidad. Este tipo de aplicaciones, denominadas aquí aplicaciones
de tasa crítica, incluir voz, vídeo sin almacenamiento intermedio, y un poco de “tele *
aplicaciones de servicio”
(Aplicaciones que proporcionan un subconjunto de voz, vídeo y datos juntos para ser
entregados al mismo tiempo a grupos de personas en varios lugares, por ejemplo, las
teleconferencias, telemedicina, y teleseminars [así la tele *]). Aplicación de tarifas
críticos pueden requerir umbrales, límites o garantías sobre mínimo, máximo, y / o
capacidades sostenidas.
Nótese la diferencia entre las aplicaciones de tasa crítica y aplicaciones de mejor esfuerzo,
como la transferencia de archivos tradicional (donde la aplicación de transferencia de
archivos no está escrito para funcionar sólo cuando un servicio predecible o garantizado está
disponible). En la transferencia de archivos (tal como en FTP que se ejecuta sobre TCP,
descrito anteriormente), la aplicación recibe cualquier capacidad disponible de la red,
basado en el estado de la red en ese momento, así como las interacciones entre TCP y las
capas inferiores.
Aunque a veces puede haber un alto grado de capacidad, es inconsistente, y no hay control
sobre los recursos en la red para predecir o garantizar una capacidad específica
(generalmente mínimo) con el fin de funcionar correctamente. Esto puede a menudo
también estar ligado al retardo de extremo a extremo de la red, como
capacidad
Retrasar impactará demora.
El aumento de la interactividad es sin duda el motor de la evolución de muchas aplicaciones.
Considere la trayectoria evolutiva de acceso a la información, a partir de telnet y FTP para
Gopher (un sistema de menús que simplifica Localización de recursos en Internet) y Archie
(una base de datos que consta de cientos de directorios de archivos) a Mosaic (el precursor
de Netscape) y Netscape, hace aún más interactivo con el uso de Java y el lenguaje de
marcado realidad virtual (VRML). Como vimos en el apartado anterior, la interactividad se
basa
La principalmente
demora en la demora
es una medida característica
de las diferencias de rendimiento.
de tiempo en la transferencia y procesamiento
de información. Hay muchas fuentes de retardo, incluyendo la propagación, la
transmisión, la puesta en cola, el procesamiento y encaminamiento. Esta sección se centra
en la de extremo a extremo y de ida y vuelta retrasos, que abarcan todos los tipos de
retardo antes mencionados. Desde una perspectiva de servicios de aplicaciones,
optimización del total, de extremo a extremo, o el retraso de ida y vuelta es por lo general
más importante que se centra en las fuentes individuales de demora. fuentes individuales
de retardo se vuelven más importantes a medida que en los componentes de capa inferior,
así como en arquitectura y diseño optimizaciones.
Históricamente, las aplicaciones utilizadas en Internet no tienen requisitos de retardo
estrictos. Se basaron en el servicio de mejor esfuerzo a través de Internet y no solicitaron
o esperan que las garantías de servicio. Otras aplicaciones, que se encuentran
principalmente en las redes privadas (con tecnologías de red propios y protocolos), han
tenido más estrictos requisitos de retardo (así como la capacidad y requisitos RMA).
Algunas redes privadas han sido eficaces en la prestación de retardo predecible o
garantizado, ya sea
por un exceso de la ingeniería de la red con capacidad de reserva, o mediante la

compensación de la interoperabilidad con otras redes. Pero ahora nos encontramos con que
las aplicaciones con requisitos de retardo están migrando al Internet, a menudo el uso de
redes privadas virtuales y las aplicaciones anteriormente dedicados a un único usuario o
dispositivo están siendo utilizados a través de Internet, forzando una reevaluación de
ofrecer servicios que no sean el mejor esfuerzo en Internet. Esto también está obligando a
una nueva evaluación de las técnicas de ingeniería de tráfico por los proveedores de
servicios.
El termino tiempo real se ha interpretado en el sentido de muchas cosas diferentes. A
menudo, en tiempo real significa “lo más rápido posible” por aquellos que no lo saben,
entender, o se preocupan por las relaciones de retardo reales entre las fuentes de tráfico y
los destinos dentro de su red. Es bastante difícil de cuantificar en tiempo real cuando se
usa de esta manera. Hay formas más significativas para describir en tiempo real, así como
la no-tiempo real, interactiva, asíncrono, explosión, y mayor. Estos son todos describen a
continuación.
aplicaciones en tiempo real son los que tienen una estricta relación de tiempos entre el origen
y el destino, con uno o más contadores de tiempo establecidos para la recepción de
información en el destino. La información recibida después de que el temporizador (s)
expiran en el destino se considera sin valor y se deja caer. Por lo tanto, esta definición de
tiempo real no significa que la información tiene que ser transferido dentro de un límite de
tiempo universalmente conocido, sino más bien que el límite de retardo se entiende por
fuente y destino, y que el destino no esperar más allá de este límite. En tiempo real podría
significar extremo a extremo retraso de 30 ms para algunas aplicaciones y 30 segundos
para otros. Un ejemplo de esto es la reproducción de vídeo no tamponada. Si el flujo de
vídeo se retrasa más allá del temporizador de reproducción, el destino se mostrará una o
más partes en blanco de marcos (que aparecen como baches en la pantalla) y soltar finales
del vídeo. Esto se hace para preservar la continuidad de tiempo del vídeo que se muestra
en el dispositivo de reproducción. Esto es lo que significa tener una estricta relación de
temporización entre el origen y el destino, que el flujo de información está sujeta a
mantener la continuidad del tiempo.
Tiempo real es el primero de varios términos que necesitamos aclarar. Estos términos se
utilizan a menudo sin cuidado, aunque, como la red de arquitecto / diseñador, tenemos
que tomar en serio. Por lo tanto, le corresponde a nosotros para asegurarse de que los
términos ambiguos se aclaran, como a lo largo de los requisitos basados en tales términos.
Este libro trata, siempre que sea posible, para proporcionar interpretaciones estrictas de
tales términos para ayudar a que sean claras.
Dada esta interpretación estricta de tiempo real, es seguro decir que no hay muchas
aplicaciones en tiempo real. Pero hay algunos (y sus números están creciendo), y es
importante ser capaz de identificar y reconocer su estricta retraso requisitos, ya que pueden
tener un fuerte impacto en la arquitectura y el diseño de la red.
Actualmente, la mayoría de las aplicaciones se consideran en tiempo no real. aplicaciones

en tiempo no real tienen diferentes requisitos de retardo de extremo a extremo, a veces
más estrictas (en términos de la cantidad de retardo) de aplicaciones en tiempo real, pero
el factor importante aquí es que el destino va a esperar (dentro de lo razonable) hasta que
se reciba la información. El tiempo que el destino va a esperar es una función de los
contadores de tiempo establecidos en las aplicaciones, en los dispositivos, y por los
protocolos utilizados. aplicaciones en tiempo no real incluyen los interactivos y
asíncronos, que representan la gran mayoría de las aplicaciones.
aplicaciones en tiempo real están en un extremo de la actuación; aplicaciones asincrónicas están
en el otro. aplicaciones asíncronas son relativamente insensibles a tiempo, suponiendo que o
bien no relación de temporización entre la fuente y de destino, o una relación de temporización
fuera de los límites de la sesión de aplicaciones. Un buen ejemplo de una aplicación de correo
electrónico es asincrónico. Cuando el correo electrónico se envía a un destinatario, todo el
conocimiento de la distribución (es decir, el momento en que el correo electrónico es recibido
en cualquier parada intermedia o en el destino final) se pierde al remitente. Sólo si hay un error
en la información del sistema o del destinatario, o si se solicita, es el remitente notificado.
Facsímil es otra aplicación asíncrona. Cuando se envía un fax (cuando se almacena
temporalmente en el dispositivo de envío), el emisor pierde ningún conocimiento de cuando
el fax llega a su destino.
Así como es importante identificar las aplicaciones en tiempo real, debido a sus estrictos requisitos
de tiempo, también es importante identificar las aplicaciones asíncronas, debido a su falta de
requisitos de tiempo. aplicaciones asíncronas tienen poco o ningún impacto en la arquitectura y el
diseño de la red y por lo general pueden ser ignorados.
Del mismo modo que no hay muchas aplicaciones en tiempo real, no hay tampoco muchas
aplicaciones asíncronas. Por lo tanto, la mayoría de las aplicaciones caen en el reino no en tiempo
real, entre en tiempo real en un extremo y asíncrona en el otro extremo. Estas aplicaciones se
denominan interactivo. Las aplicaciones interactivas asumir alguna relación de temporización entre
origen y destino, mientras que la sesión de aplicación está activa; Sin embargo, la relación de
temporización no es tan estricta como en tiempo real. Las aplicaciones interactivas son lo que
muchos considerarían normalmente en tiempo real, bajo la connotación de tiempo real como “lo
más rápido posible.” aplicación interactiva comunes, tales como Telnet, FTP y aplicaciones web,
todas ellas incluidas en este tipo.
Por último, las aplicaciones interactivas pueden ser subdivididos en tipos interactivos
de ráfaga y granel. La diferencia entre estos tipos es más sutil que con el tiempo real o
asíncrona. Para distinguir entre mayor interactivo y aplicaciones de ráfaga, necesitamos
primero entender cuando los tiempos de procesamiento de los componentes del sistema,
particularmente el componente de aplicación, abrumar el retardo de extremo a extremo o

de ida y vuelta de la red. En otras palabras, queremos distinguir entre cuando una aplicación
se frecuente y rápidamente interactuar con un usuario y cuando un usuario tendrá que
esperar largos períodos de tiempo mientras la aplicación está procesando información.
Estos tipos de retardo se resumen en la Figura 2.5. Basado en esto, aplicaciones interactivas
de ráfaga son aquellos para los que el extremo de extremo a o retardo de red de ida y vuelta
es el retardo predominante para esa aplicación. Este tipo de aplicación es importante
identificar, ya que es sensible al retardo de red. Por lo tanto, la arquitectura y el diseño de
la red deben adaptarse a los requisitos de retardo de estas aplicaciones. Un ejemplo de una
aplicación interactiva es la explosión de telnet. Durante una sesión Telnet, el retardo
predominante experimentado por el usuario es desde la red, y no de cualquier
procesamiento en los dispositivos locales o remotos. Hay muchas aplicaciones de este tipo,
donde los usuarios interactúan con las aplicaciones y los dispositivos a través de la red y
esperan respuestas “tan rápido como sea posible.”
aplicaciones interactivas a granel, por el contrario, son aquellos para los que el
procesamiento en el componente de dispositivo o aplicación es el retardo predominante.
Por lo tanto, el procesamiento de la información en uno o ambos puntos finales pueden
abrumar a los tiempos de extremo a extremo o de ida y vuelta en la red. Esto es
importante reconocer, como el requisito de retardo de red por esa aplicación se vuelve
menos importante, puesto que ya está eclipsado por la aplicación y / o retrasos del
dispositivo. Por ejemplo, cuando una aplicación tiene demoras de procesamiento altas,
por ejemplo del orden de 100s de ms o segundos, entonces tenemos una mayor
flexibilidad en el apoyo de retardo en la red que si el retardo de procesamiento eran
No en tiempo real
Tiempo real
Interactivo Asincrónico
Rafaga Interactiva Interactiva-granel
Estricto Relación de temporización entre

Suelto
origen y destino
Figura 2.5 Tipos de retardo

del orden de microsegundos. Un ejemplo de aplicaciones masivas interactivas es la

transferencia de archivos de gran tamaño (por ejemplo, FTP). Aunque FTP tiene un grado
de interacción con el usuario, puede haber ocasiones (especialmente cuando el tamaño del
archivo es grande) en las que el procesamiento de la información en el extremo receptor,
así como el tiempo total que se tarda en transferir el archivo completo, es varios órdenes de
magnitud mayor que el retardo de red de extremo a extremo o de ida y vuelta.
¿Por qué la elaborada desglose de los tipos de aplicación basada en el retraso? Como
podemos ver en la discusión anterior, hay momentos en que el requisito de una solicitud
de retraso es una consideración importante en la arquitectura de red y el diseño, y otras
veces cuando no lo es. Siempre podemos ignorar selectivamente algunas aplicaciones,
y centrarse en otros, la arquitectura de red y problemas de diseño hacerse más manejable.
En el siguiente capítulo se discuten algunos de los parámetros de tiempo asociados con la
explosión interactivo y aplicaciones a granel.
2.4.2 Grupos de aplicaciones

Hemos utilizado hasta ahora varios ejemplos de aplicaciones para transmitir los requisitos
de aplicación. A menudo es útil para aplicaciones de grupo con características de
rendimiento similares, ya que ayuda tanto en la cartografía de las características de
rendimiento y en la recopilación y la comprensión de las necesidades. Ha sido útil para mí
para formar grupos de aplicaciones y seguir añadiendo a ellos como me encuentro con
nuevas aplicaciones. Al tratar de identificar rápidamente los requisitos de red para un nuevo
cliente, he utilizado con éxito estos grupos para ayudar a identificar los requisitos, mediante
la comparación de las nuevas aplicaciones a los de los grupos que ya he desarrollado. Este
proceso es especialmente útil si usted tiene que completar los requisitos de análisis rápido
o si con frecuencia tiene nuevos clientes.
Usando el proceso de análisis de requisitos, se han identificado los grupos de
aplicaciones de abajo. Existe un cierto solapamiento entre estos grupos, y esto no es un
juego completo de los grupos. Se pretende ilustrar cómo funciona la agrupación. Se le
anima a desarrollar sus propios grupos de aplicaciones a medida que aplica el proceso
de análisis de requisitos para sus redes.
• Las aplicaciones de telemetría / comando y control. Mientras que el título puede sonar
un tanto militar, este grupo en realidad describe una variedad de aplicaciones en las
que se transmiten los datos y comandos de información entre dispositivos remotos
y una o más estaciones de control para el comando, control, seguimiento, y que
determinan el estado de los dispositivos remotos. Un dispositivo remoto puede ser
tan mundano como un automatizado
cajero (ATM), los sensores en el hogar, o un ordenador remoto, a dispositivos

esotéricos tales como vehículos teledirigidos (RPVs), nave espacial, o aviones
comerciales. aplicaciones de telemetría /-comando y control se pueden caracterizar
como teniendo en tiempo real y / o retraso interactiva, así como a menudo ser de
misión crítica.
• Las aplicaciones de visualización. Este grupo abarca desde la visualización
bidimensional de objetos a la visualización tridimensional y la realidad virtual, la
inmersión, y la manipulación de objetos. La visualización puede ser de una
simulación numérica o de los datos experimentales. Los ejemplos incluyen
visualizaciones de campos de flujo de fluido alrededor de varios objetos (por
ejemplo, modelado tiempo, aeronáutica, o medicina), simulaciones médicos,
biomédicos, y moleculares, a simulaciones de juego comerciales y militares.
aplicaciones de visualización a menudo pueden caracterizarse como de la velocidad
crítica y ráfaga interactiva.
• Las aplicaciones de computación distribuida. Aplicaciones de este grupo pueden variar
de tener los dispositivos de computación que comparten el mismo bus local (como
en la computación paralela), de ser co-situado en la misma LAN (como en un cluster
de computación), para ser distribuido a través de LAN, MAN y WAN límites (como
en la computación grid). El grado de distribución o paralelismo en la computación
también está determinado por la granularidad de la tarea y el grado de acoplamiento
entre los dispositivos de computación. Un ejemplo de computación distribuida es el
uso de las computadoras de escritorio en el entorno corporativo a altas horas de la
noche, cuando están por lo general inactivo, acoplando su capacidad de computación
para llevar a cabo grandes tareas que suelen realizarse en un mainframe. aplicaciones
de computación distribuida se pueden caracterizar como en tiempo real o la
explosión interactiva.
•
Desarrollo Web, el acceso y uso Aplicaciones. Las aplicaciones de este grupo son los
equivalents interactivos actuales de la tradicional Telnet Utilidades del dispositivo
y la información de acceso remoto y FTP. acceso a la web y el uso implican el acceso
a dispositivos remotos y descargar y / o subir información. Esto se hace con la ayuda
de las interfaces gráficas. Por lo general, las sesiones web son interactivos, y las
cantidades de información son pequeños en relación con los otros grupos de
aplicaciones (con la posible excepción de telemetría y control de comandos /). Este
grupo de aplicaciones se considera generalmente que es interactiva, una mezcla de
estallido interactivo y mayor interactiva.
• Aplicaciones de Transporte de Datos granel. Cuando las cantidades de información
deseada son relativamente grandes y las sesiones son menos interactivos (o
asíncrona), las aplicaciones pueden optimizar la velocidad de transferencia de datos
a expensas de la interactividad. El ejemplo tradicional de esto es FTP; Actualmente
las aplicaciones, más eficaces
como MFTP y ARCP están disponibles. Para obtener más información
sobre MFTP y ARCP, ver www.nas.nasa.gov. Estas aplicaciones
generalmente no tienen requisitos de alto rendimiento.
• Tele * Aplicaciones de servicio. Este grupo se describen las aplicaciones que

proporcionan un subconjunto de voz, vídeo y datos en conjunto para ser aplicada
simultáneamente a grupos de personas en varios lugares. Los ejemplos incluyen las
teleconferencias, telemedicina, y teleseminars (así la tele *). La columna vertebral de
multidifusión de Internet es un ejemplo de soporte de la red para este grupo de
aplicaciones. Tele * aplicaciones de servicio se pueden caracterizar por tener retardo en
tiempo real interactivo y y son a menudo la velocidad crítica y de misión crítica.
• Operaciones, administración, mantenimiento y aprovisionamiento de aplicaciones (OAM

& P). Se requieren aplicaciones de sistema de OAM & P para el correcto
funcionamiento y operación de la red. Los ejemplos incluyen el servicio de nombres
de dominio (DNS), servicios de correo / SMTP, servicios de noticias / NNTP, el
servicio de resolución de dirección, supervisión de la red y la gestión, seguridad de
redes, sistemas y contabilidad. Estas aplicaciones son a menudo considerados de
misión crítica e interactiva.
•
Las aplicaciones cliente-servidor. Se trata de aplicaciones cuyos flujos de tráfico se
comportan de un modo cliente-servidor, como la planificación de recursos
empresariales (ERP), gestión de la cadena de suministro (SCM) y gestión de
relaciones con clientes (CRM). Se discuten los flujos de tráfico y comportamiento
del flujo de cliente-servidor en detalle en el capítulo 4. Estas aplicaciones suelen
ser de misión crítica e interactiva.
Es posible que pueda aplicar más grupos de aplicaciones para sus redes. Si desarrolla
requisitos para múltiples redes, usted será capaz de ampliar o modificar esta lista para
satisfacer sus necesidades de análisis.
2.4.3 Ubicaciones de aplicaciones
Junto con escribir y agrupar las aplicaciones, a menudo es útil para determinar cuando
una solicitud se aplica en su entorno (o de su cliente). Por lo general hay algunas
aplicaciones que se aplican en todas partes, que todo el mundo utiliza y que residen en
casi todos los dispositivos (por ejemplo, servidores, ordenadores de sobremesa y
portátiles). Sin embargo, a menudo hay aplicaciones que se aplican sólo a determinados
usuarios, grupos de usuarios, servidores, pisos dentro de un edificio o edificios. Siempre
que sea posible, es necesario identificar este tipo de aplicaciones y donde se aplican, ya
que esto le ayudará en el tráfico de mapeo fluye durante el proceso de análisis de flujo.
ódigo de Estados Unidos Trabajo: NAAD Ch02-P370480 05/03/2007 10:03 a.m. Página: 76 Trim: 7.5in × TS: 9.25in Integra, India
Aplicación G
Aplicaciones E, F
aplicación B
Aplicación C
Aplicaciones A, D
Figura 2.6 Un ejemplo Aplicaciones Mapa
Un ejemplo de un mapa de aplicaciones, o un dibujo de donde se aplican las aplicaciones,

se muestra en la Figura 2.6. En esta figura de un entorno de campus hay tres conjuntos
de edificios, que se muestran en gris. El lugar donde se aplica cada aplicación se describe.
Esta es una estimación de las localizaciones probables para aplicaciones en un entorno,
y es el primer paso hacia la provisión de información de ubicación en el análisis de los
requisitos. En algunos casos, todas las aplicaciones se aplican en todas partes. En otros
casos no podemos determinar dónde se aplican algunas aplicaciones. Siempre que dicha
información está disponible, sin embargo, que la cartografía de información ayudará a
los requisitos y análisis de flujo.
Tipos de aplicación, sus requisitos de rendimiento, sus ubicaciones, y los grupos de
aplicaciones forman la interfaz entre el componente de aplicación y el resto del sistema.
2.5 Requisitos de los dispositivos
Pasamos ahora a los requisitos de los dispositivos que la red va a apoyar, en particular los
tipos de dispositivos, sus características de rendimiento, y su información de ubicación.
Como se verá, esta información se basa en las necesidades del usuario y la aplicación
descritos anteriormente para comenzar a ofrecer una visión global de las necesidades del
sistema. La relación del componente de dispositivo con el resto del sistema se muestra en
la Figura 2.7.
Requisitos de los dispositivos 77
usuarios
Aplicación
Dispositivo Requisitos de los dispositivos

Tipos de dispositivos
Características de rendimiento
Ubicaciones de dispositivos
red
Figura 2.7 Tipos de Requisitos de los dispositivos
2.5.1 Tipos de dispositivos
Los dispositivos se pueden agrupar en tres categorías: dispositivos genéricos de cómputo,

servidores y dispositivos especializados. dispositivos informáticos genéricos son los
ordenadores de sobremesa y portátiles que la mayoría de los usuarios tienen. Este grupo
también incluye dispositivos de mano. Los ejemplos populares incluyen diversas formas
de PC basados en Windows, ordenadores portátiles y dispositivos de mano, y Mac y
estaciones de trabajo basados en Linux y PC. Estos son los anfitriones que forman los
puntos de acceso en la red y típicamente dan servicio a un único usuario. Sus requisitos
son importantes desde una perspectiva de extremo a extremo, ya que proporcionan la
interfaz entre las aplicaciones y la red. Sus requisitos también son importantes en el
desarrollo de una plantilla para dispositivos de grupos de usuarios o todos los usuarios de
la red. Estos dispositivos finales también tienden a ser pasados por alto, una forma de
“recuadro negro” que las redes están conectadas a y aplicaciones se ejecutan en un tanto,
pero de lo contrario se ignoran.
La falta de comprensión de los dispositivos finales ha dado lugar a lo que se conoce

como el problema “último pie” en el rendimiento del sistema. Esta es una modificación
del problema “última milla”, que fue la dificultad en conseguir la infraestructura, las
redes y los servicios en un campus o edificio. El problema “último pie” está recibiendo
servicios y el rendimiento de la interfaz de red del dispositivo a través del dispositivo a
sus aplicaciones y usuarios. Esto se discute en detalle más adelante en esta sección.
Típicamente hay muchos dispositivos de computación genéricos en un sistema, y sería

muy difícil enumerar, describir, y el gráfico de cada dispositivo individual. Por lo tanto,
el desarrollo de una plantilla, o descripción estándar, por uno o más dispositivos
“estándar” en el medio ambiente puede ser útil. Tal descripción puede incluir el tipo de
dispositivo, la interfaz de red, la configuración, el rendimiento y aplicaciones residentes.
Figura 2.8 muestra un ejemplo de una plantilla.
Tipo de
Tipo de Procesador Sistema Aplicaciones
dispositivo
NIC Operativo
Pentium I Word, PP, Finance
PC de gama baja Win95/98/200
10M Ethernet
PC de gama alta 10/100M Word, PP,

Ethernet Pentiun III/IV WinPro
DB, Graphics
10/100M
PC genérica Ethernet Win95/98/2000 Word, PP,
Pentium /XP DB, Graphics
Estacion de Linux
DB, Graphics,
10/100M AMD
trabajo CAD,SC
Ethernet
Laptop 56 Kb AMD Win XP Word, PP, Others

Modem
PP - Powerpoint CAD - Dibujo Asistido por Ordenador
DB - Base de Datos SC - SW Científico
Figura 2.8 Una Plantilla Ejemplo de descripciones de dispositivo
Los servidores son los dispositivos de computacion que proporcionan un servicio a uno o
más usuarios (es decir, clientes). Por lo general son más potente, en términos de memoria,
procesamiento, redes y periféricos, que los dispositivos de sobremesa o portátiles de los
usuarios. Los ejemplos de servidores incluyen servidores de cómputo, servidores de
almacenamiento (también conocido como almacenamiento masivo o archivo sistemas), y
servidores de aplicaciones. Requisitos del servidor son importantes, ya que pueden afectar a
un gran número de usuarios. Como tal, sus requisitos garantizan una mayor atención sobre
una base por dispositivo de los dispositivos informáticos genéricos.
Los servidores también tienen requisitos de desempeño “último pie”, así como los
requisitos específicos de su función de servidor. Las funciones de un servidor a menudo
se pueden optimizar para apoyar esta función de servidor, que a su vez puede afectar el
sistema. Por ejemplo, un servidor puede estar diseñado para soportar altas prestaciones,
el acceso predecible a un gran número de usuarios. El efecto acumulativo de acceso de
los usuarios a este servidor en la red necesita ser considerado. Los servidores tienen un
impacto sobre los flujos de tráfico dentro del sistema; Esto se examina en los capítulos
de análisis de flujo.
Los dispositivos especializados son dispositivos que proporcionan funciones específicas a
sus usuarios. Una computadora paralela apoyo a un gran motor de búsqueda de base de
datos puede ser considerado un servidor o un dispositivo especializado, mientras que una
cámara de vídeo en la red sería considerado un dispositivo especializado. dispositivos
especializados generalmente no son compatibles con el acceso directo a las aplicaciones
de usuario, sino que se reúnen, producen o procesan la información que se envía a los
usuarios. Ejemplos de dispositivos especializados incluyen superordenadores, sistemas
paralelos o-computación distribuida, la recopilación de datos y sistemas de procesamiento,
dispositivos médicos, cámaras o herramientas en red, y dispositivos de mano.
Los dispositivos especializados tienden a ser dependiente de la localización. Esto es

significativo, ya que mientras en la mayoría de los entornos de dispositivos informáticos y
servidores genéricos son cada ubicación independiente, dispositivos especializados a
menudo conservan sus dependencias ubicación. Dicho esto, sin embargo, hay momentos
en los dispositivos especializados son independientes de la ubicación y los servidores o
dispositivos genéricos es dependiente del lugar. Como veremos en la recopilación de
requisitos, es importante conocer y comprender el entorno que estamos analizando, en
parte, para entender las dependencias ubicación de sus dispositivos. dispositivos
especializados son a menudo dependiente del lugar debido a los costos. Un túnel de viento
que proporciona el flujo de información para los fabricantes de automóviles es grande,
inmóvil, y costoso, por lo que es difícil de replicar. Si una red está siendo construido para
soportar esta instalación de túnel de viento, que se encuentra en Dearborn, Michigan, a
continuación, la red tiene que ser con arquitectura con acceso a Dearborn en cuenta, así
como los requisitos de funcionamiento y la ubicación del túnel de viento. Del mismo modo,
si una red se está construyendo para proporcionar acceso remoto a los productos sanitarios
(por ejemplo, escáneres CT) para los médicos, a continuación, la ubicación de estos
dispositivos se convertirían en los requisites de acceso para el sistema. Esto se ilustra en la
Figura 2.9.
Mientras túneles de viento y los escáneres de TC son muy especializados (y en el caso de
túneles de viento, bastante raro) los dispositivos, este concepto se puede ampliar a los
dispositivos más comunes, tales como cajeros automáticos, sensores de tráfico, incluso las
luces de parada. también
Centro de Investigación
Túnel de viento
Hospital
Punto de venta
Dispositivo
Equipo
medico Negocio
Red
usuario del equipo Dispositivo Video digital
portátil
FIGURA 2.9 Dispositivos especializados

considerar en la localización de información específica, de bibliotecas, universidades,

centros de gobierno, o centros médicos. Gran parte de esta información también está
estrechamente ligada a su ubicación.
2.5.2 Características de presentación
El problema “último pie” presentado anteriormente se centra en el rendimiento de varios

componentes del dispositivo: el hardware, firmware y software que proporcionan el
pegamento entre los usuarios y las aplicaciones y el resto del sistema. Para muchos
entornos, puede ser difícil determinar o medir las características de rendimiento de sus
dispositivos. Los componentes dentro de un dispositivo son propiedad, y la información
de rendimiento acerca de ellos pueden ser incompletos o no disponibles. Software y el
firmware del dispositivo de conducción, tales como el sistema operativo (OS),
controladores de dispositivos, y la interfaz de programación de aplicaciones (API), son
complejas. Por lo tanto, siempre que sea posible, la determinación de esta información
para un dispositivo “estándar” y la creación de una plantilla es una solución práctica.
Tomando el tiempo para investigar o probar uno o unos pocos dispositivos, y aplicar esta
información en una plantilla.
Tenga en cuenta que los problemas de dispositivos con frecuencia son mal interpretados
como problemas en la red. Por lo tanto, haciendo caso omiso de los requisitos del
dispositivo pueden comprometer la arquitectura y el diseño de la red. Como veremos más
adelante en el proceso de diseño, la identificación de cualquier problema con los
dispositivos que serán apoyados por la red puede hacer que el proceso de diseño más
sencillo, con resultados más deterministas.
Un diagrama simple, general de un dispositivo se presenta en la Figura 2.10. El
rendimiento de cada uno de estos componentes impacta el rendimiento global del
dispositivo. A modo de ejemplo, unidades de disco tiempos de búsqueda, los tiempos de
acceso a memoria, y la eficacia de conductor, sistema operativo o el software API todo
ello afectará la capacidad del dispositivo para procesar la información desde y hacia la
red.
Memorias/
L
Procesadores o
buffers
s
t
a
m
p
o
n
Bus de equipo e
s
d
e
m
Tarjeta de e otros
controladores m
interfaz de red o periféricos
r
i
a
/
FIGURA 2.10 Estructura del mecanismo

Al mirar a cada uno de estos componentes como parte integral del rendimiento general
del dispositivo (y del sistema), estamos aplicando la perspectiva de extremo a extremo
en el dispositivo host, en efecto, se convierte en un microcosmos del sistema. Lo que
estamos buscando en las características de rendimiento incluye
• rendimiento de almacenamiento, es decir, el flash, disco duro, o rendimiento

de la cinta
• Procesador (CPU) el rendimiento
• rendimiento de la memoria (tiempo de acceso)
• rendimiento del bus (bus de la capacidad y la eficiencia de arbitraje)
• rendimiento OS (eficacia de la pila y las API de protocolo, por ejemplo, el número de
copias de memoria en la pila de protocolos, o el coste de ejecución de un sistema
operativo dado en un procesador particular)
• rendimiento de controlador de dispositivo
Información sobre cualquiera de estos componentes puede ser útil en la estimación del
rendimiento global de un dispositivo o en la identificación de los factores que limiten en
el rendimiento del dispositivo. Por ejemplo, las pruebas de los dispositivos de
representación puede revelar que sus interfaces de red deben ser actualizados (por ejemplo,
de Ethernet de 10 Mb / s a 10/100 Mb / s Ethernet), o que las unidades de disco que ser
reemplazado, o que una actualización del sistema operativo tiene que ser realizado. A pesar
de que puede llevar mucho tiempo para comprender las implicaciones de rendimiento de
cada componente de cada tipo de dispositivo, incluso un intento simple y rápido en el
desarrollo de los requisitos de rendimiento del dispositivo puede ayudar a asegurar que no
existen cuellos de botella de rendimiento espectacular evidentes en el dispositivo. La
comprensión a nivel componente de dispositivo puede ayudar a reconocer este tipo de
cuellos de botella temprano en el proceso de análisis.
2.5.3 Ubicaciones de soporte
Conocer la ubicación de los dispositivos existentes o previstos genéricos de computación,

servidores y dispositivos especializados puede ser útil para determinar las relaciones entre
los usuarios, las aplicaciones y las redes, así como el inicio hacia la determinación de las
características de flujo de tráfico para el sistema.
La información de ubicación ayuda a determinar las relaciones entre los componentes
del sistema. Junto con los tipos y requisitos de funcionamiento de los dispositivos,
servidores y dispositivos especializados, esta información nos da una idea de lo que
deberían ser las concentraciones relativas de los usuarios y los dispositivos, su
colocación, y el nivel de red necesarias.
Las distancias entre las

LAN: 15-30 km
Campus Norte LAN
14
Campus LAN central Video
digital
servidores
60
40 45
51
servidores
67
2
Servidor de Servideor de 88
almacenamiento computo
74
14
22 Servideores de almacenamiento
Campus Sur LAN
FIGURA 2.11 Ubicaciones de soporte
Figura 2.11 ilustra un entorno de tres campus (edificios se muestran en gris). cómputo genérico,
servidores y dispositivos especializados se muestran para cada edificio. En lugar de representar
cada dispositivo de escritorio del usuario, se observó un total para cada edificio. El número de
cada servidor se muestra también.
La información de ubicación también ayuda a determinar las características del flujo de tráfico
en el sistema. En el capítulo 4 se discuten los modelos de flujo que describen cómo los flujos de
tráfico dentro del sistema, basado en las relaciones entre usuarios, aplicaciones y dispositivos, se
derivan en parte de la información sobre la ubicación de estos componentes.
Redes para las cuales la información de ubicación es particularmente importante incluyen

aquellos cuyos componentes o funciones del sistema son subcontratados; los utilizados en la
consolidación de las organizaciones, los componentes del sistema, o funciones; y los utilizados
en el traslado de componentes o funciones del sistema dentro de una organización.
Para ver un ejemplo de cómo se puede utilizar esta información, vamos a ver una organización
que es la externalización de la reubicación de sus recursos informáticos. El agente de
externalización puede o bien operar, administrar, mantener, y el suministro (OAM & P) los
recursos en el sitio del cliente, o puede eliminar los recursos de las instalaciones del cliente y
proporcionar los recursos, así como la OAM & P. En este último caso, cuando el agente de
externalización proporciona los recursos de computación, saber dónde van a ser reubicados los
recursos es importante para determinar los modelos de flujo y
Requisitos de la red 83
nivel de red necesarias. El agente de la externalización puede elegir una ubicación que
está optimizada para la administración de los recursos de computación, sin embargo, se
degrada el rendimiento general del sistema. Si se accede a los recursos informáticos de
un cliente a través de Fast O Gigabit Ethernet, y luego se separan por parte del cliente
en un entorno WAN, o bien los costos de acceso a esos recursos se elevarán (requiriendo
de alta velocidad de las conexiones WAN) o el rendimiento se degradará. En algunos
casos, moviendo el recurso de una LAN a un entorno WAN puede dar lugar a algunas
aplicaciones que se queden inutilizables.
Cuando las ubicaciones de los componentes del sistema cambian, es importante evaluar
o reevaluar los requisitos del sistema, para determinar si los requisitos de servicio (tanto
de rendimiento y funcionales) han cambiado también. Figura 2.11 ilustra que a menudo
hay dependencias ubicación entre las aplicaciones y los dispositivos, y que estas
dependencias necesitan ser identificados como parte de los requisitos del dispositivo.
Por ejemplo, si una aplicación de LAN que tiene un requisito de 100 ms de retardo de ida
y vuelta se aplica a una WAN con un retardo característico de ida y vuelta de 200 ms, la
arquitectura de red / diseño, aplicación (s), o expectativas de los usuarios tendrán que ser
modificado para soportar la nueva red.
La interfaz entre el componente de dispositivo y el resto del sistema consta de los tipos de
dispositivos, sus dependencias ubicación, y sus características de rendimiento.
2.6 Requisitos de la red

Figura 2.12 muestra la relación de la componente de dispositivo con el resto del sistema.
Usuario
Las Restricciones de las redes existentes.
Escalado esperado de las redes existentes.
Aplicación Interoperabilidad entre redes.
Redes existentes de red y servicios de apoyo.

existentes
Arquitecturas existentes y pautas de diseño.
Dispositivo esperados
Red Requisitos de la red
FIGURA 2.12 Tipos de requisitos de la red

Para el componente de red, los requisitos para una red de arquitectura / diseño deben tener
en cuenta los requisitos, los servicios y características de las redes existentes que serán
incorporados en, o con la interfaz, la nueva red.
2.6.1 Las redes existentes y Migración
La mayoría de las arquitecturas de red / diseños actuales necesitan incorporar las redes
existentes. Pocas redes hoy en día se construyen desde cero. Esto incluye las mejoras del
sistema, tales como la adición de una nueva aplicación para el sistema, la migración a
una tecnología o protocolo nuevo o diferente, o la mejora de la infraestructura de red y
la expansión o reducción del tamaño o el alcance de un sistema. A veces, la arquitectura
y el diseño de la red deben adaptarse a las dependencias y las limitaciones impuestas por
la red existente. Ejemplos incluyen los siguientes:
Escalamiento dependencias. La red existente puede afectar la forma en la red planificada

escalará. Por ejemplo, la forma en que la adición de la nueva red a la red existente cambiar
el tamaño y el alcance del sistema? Será el cambio sea dramática, como en el crecimiento
de una LAN a una WAN, o será el cambio dentro de los límites de LAN / MAN / WAN de
la red existente?
dependencias Ubicación. Dependiendo de cómo la nueva interfaz de redes con o
incorporan la red existente, o cómo se hacen las modificaciones de la red, los lugares y /
o concentraciones de otros componentes del sistema son propensos a cambiar. El mismo
se mostrará cuando desarrollamos flujos más adelante en el proceso de análisis.
restricciones de rendimiento. El rendimiento global del sistema se verá afectada por nuestra
arquitectura y diseño de la red esperado (o modificación de red), la forma en que
interactúa con la red existente, y sus niveles de rendimiento. Dado que el rendimiento de
la red existente tendrá un impacto en el rendimiento general del sistema, sus
características de rendimiento deben integrarse en los requisitos de rendimiento de la red
planificada. Dado que la red existente que ya está en su lugar, por lo general es posible
medir el desempeño de esta red. Por lo tanto, mientras que el rendimiento de la red
esperado se basa en una estimación óptima, el rendimiento de la red existente (y los
impactos potenciales de rendimiento) se puede entender mejor.
dependencias de red, sistema y servicios de apoyo. Estos incluyen redes que aborden
estrategias, la seguridad, las opciones y configuraciones de protocolos de enrutamiento, y
las estrategias de nombres, mientras que los servicios de apoyo incluyen la seguridad de
todo el sistema, la contabilidad y el seguimiento y la gestión. Los requisitos actuales y
previstas para cada uno de ellos debe ser considerado.
dependencias de interoperabilidad. dependencias de interoperabilidad entre las redes

existentes y previstas se producen en los límites entre las redes, por lo general cuando se
utilizan diferentes tecnologías o medios de comunicación. Además, mediante la adopción
de una perspectiva de extremo a extremo en el diseño, los límites entre las redes existentes
y previstas son puntos en los que la información de servicio y garantías de rendimiento
necesitan ser traducidos, o se perderán. Los requisitos deben incluir las tecnologías y los
medios de comunicación de la red existente y cualquier rendimiento y / o requisitos
funcionales de la red existente.
la obsolescencia de la red. A pesar de que puede haber partes de la red existente que se
integrará en la red planificada, estas partes, incluyendo los dispositivos de red, protocolos
y software, pueden quedar obsoletos durante el ciclo de vida de su nueva red. Siempre que
sea posible, debe tener en cuenta que tendrá que ser la transición fuera de la red planificada
partes de la red que se integrarán en la red planificada, sin embargo, están cerca del final
de su utilidad.
Además, deben tenerse en cuenta los requisitos de los usuarios, aplicaciones y dispositivos
de la red existente como parte del sistema que está siendo construido, y su análisis
requisitos realiza junto con el análisis de nuevas partes del sistema.
2.6.2 Gestión de Redes y Seguridad
Desde lo largo de los procesos de diseño y arquitectura se discuten gestión y seguridad de

la red, es útil resumir brevemente sus requisitos aquí, como un comienzo para considerarlos
en la arquitectura y el diseño. Es probable que nuestro análisis de la gestión de redes y
seguridad más adelante en los procesos de diseño y arquitectura generará nuevos requisitos
o modificar algunos que desarrollamos aquí. En este punto en el proceso de análisis que
queremos pensar en términos generales acerca de cómo podemos lograr la gestión y la
seguridad de la red en la nueva red.
Como veremos en los procesos de diseño y arquitectura, hay cuatro tipos de tareas de
gestión de red:
• Monitoreo para la notificación de eventos

• Monitorización de las métricas y la planificación
• Configuración de la red
• Solución de problemas
Vigilancia implica obtener valores para los parámetros de gestión de red de los
dispositivos de red (routers, concentradores, conmutadores, etc.) del sistema, el
procesamiento de los datos, que muestran algunos o todos de los datos a los operadores
de red, y el archivo de los datos. Monitoreo para la notificación de eventos consiste en
tomar una instantánea frecuente de la red, con el fin de comprender el estado actual de
la red y para ayudar a aislar y resolver problemas de red. Si se recogen los datos para un
análisis a largo plazo de rendimiento de la red, el control es para las métricas y capacidad,
RMA, y / o ingeniería de demora. configuración de red y resolución de problemas son
las tareas más especializadas que son modificaciones de notificación de eventos, métricas,
y la planificación.
En el seguimiento, queremos desarrollar un conjunto de características que se utilizará para
la supervisión de eventos, métricas, y la planificación. Estas características pueden ser
específicos para cada tipo de dispositivo de red, que se entenderán mejor más adelante en los
procesos de arquitectura y diseño. También debemos tener en cuenta las facilidades para
acceder a estas características, que incluyen protocolos de red de gestión, herramientas de
monitorización de extremo a extremo, y los métodos de acceso directo.
Algunas cuestiones arquitectónicas con la gestión de red incluyen la determinación de los
caminos que los datos de gestión tomarán, así como la jerarquía de gestión de flujos de
datos. datos de gestión pueden estar en la ruta del tráfico de red de los usuarios (dentro
de banda) o puede tomar un camino diferente ( fuera de banda). Para los pros y los contras
de dentro de banda en comparación con la administración fuera de banda, véase el capítulo
7 en la arquitectura de gestión de red. flujos de datos de gestión puede ser jerárquica,
indicando componentes separados de y ubicaciones para el sistema de gestión, o plana, lo
que indica que el sistema de gestión está en un solo dispositivo.
Al igual que con los demás componentes de este capítulo, las características de rendimiento
de gestión de red también deben ser considerados. En este punto, podemos empezar a
enumerar algunos requisitos potenciales de gestión de red:
• Los métodos de monitoreo

• Métodos de instrumentación. Estos incluyen los protocolos de gestión de red
(SNMPv3, CMIP, RMON), listas e parámetros (MIB), herramientas de supervisión,
y métodos de acceso.
• Conjuntos de características para el seguimiento
• Dentro de la banda frente a fuera de banda de monitoreo
• Centralizada frente a monitorización distribuida
• Requisitos de desempeño
Los
servidores Elementos
Efecto / dispositivos de
usuario Servicios
Probabilidad de red Software Datos
Acceso no
autorizado B/A C/B A/B B/C A/B
La divulgación no
C/C B/C A/B
autorizada B/C A/B
Negación de
B/B B/B B/B B/B B/B D/D
servicio
Robo B/D A/B

B/D A/B C/C
A/D
C/C A/B A/B

Corrupción D/D
A/C B/C
Los virus B/B B/B B/C D/D

B/B
Daño físico D/D D/D

A/D B/C C/C D/D
Efecto: Probabilidad:
A: Destructive C: Disruptive A: Ciertos C: Probable
B: Desactivación D: No Impact B / A
B: Es poco probable D: Imposible
FIGURA 2.13 Evaluación de riesgos de seguridad
En preparación para el desarrollo de los requisitos de seguridad para nuestra red, en primer lugar
hay que determinar los riesgos de seguridad. Vamos a realizar un análisis de riesgos tanto para
la red existente y nuestra red planificada, para recopilar información sobre la seguridad y los
requisitos para las nuevas características de seguridad actual. El análisis de riesgos es a menudo
estructurado como una lista de preguntas sobre la red existente, los problemas experimentados, y
las fuerzas de seguridad de red y debilidades. También a menudo contiene una matriz de
evaluación de riesgos, que enumera los posibles problemas de seguridad, los componentes del
sistema que necesitan ser protegidos, y la probabilidad percibida y severidad de los ataques.
Figura 2.13 muestra un ejemplo de una evaluación de riesgo de seguridad para una
organización específica. En este ejemplo, un análisis de riesgos se realizó como parte del
análisis de requisitos, y la matriz de riesgo se muestra se completó con los valores
apropiados.
Los requisitos de seguridad y los resultados del análisis de riesgos se utilizan para
desarrollar un plan de seguridad y definir las políticas de seguridad de la red.
2.7 Otros requerimientos
Hay otros requisitos que se aplican a todos los componentes del sistema, como los
requisites financieros y empresariales. No es probable que haya otros tales requisitos para
su red, y ellos se incluirían aquí.
2.7.1 Requisitos suplementarios Rendimiento
En un mundo ideal, los componentes funcionen de acuerdo a la especificación todo el

tiempo de la vida del sistema. La realidad es a menudo mucho menos ordenado. A esto le
añadimos el hecho de que los seres humanos operar y mantener los sistemas que
construimos y que su capacidad, la calidad y la moral no son siempre a su máximo significa
que hay muchas cosas que pueden afectar el rendimiento de la red una vez que está
instalado. El mundo real se entromete en el ingeniero de red cuando se mira más allá del
diseño e implementación de redes a la capacidad operativa inicial (IOC), cuando los
primeros segmentos se ponen en línea en un modo de producción. Para satisfacer a los
clientes y usuarios finales de esta creación, el ingeniero debe tener en cuenta que cuando
la fase de implementación de la red por fin está completa y el sistema está en manos de los
operadores.
Idoneidad operativa es una medida de lo bien que nuestro diseño de red se puede
configurar, supervisar, y ajustado por los operadores del cliente. supportability es una
medida de lo bien que el cliente puede mantener el rendimiento del sistema, tal como fue
diseñado, por toda la vida útil del sistema. Confianza es una medida de la capacidad de la
red para ofrecer datos sin errores o pérdida en el rendimiento requerido.
Al identificar, documentar y validar estas limitaciones con el cliente durante la fase de
análisis de requisitos, el ingeniero de la red asegura que el cliente entiende las
compensaciones entre costo y rendimiento, reconoce la eliminación temporal de los costes
totales de propiedad, y tiene la oportunidad de influir en estas decisiones. También reduce
el factor sorpresa que podría golpear cuando el propietario tiene que operar en realidad la
red. Además, los clientes que se prepara para reconocer cuando su red se ha excedido la
capacidad de diseño y por lo tanto poner en marcha una actualización o servicio de
extensión de la vida o el reemplazo. Los clientes que encargan un diseño de red para
soportar 1000 conexiones deben ser conscientes de que, cuando su necesidad se convierte
en 20.000 conexiones, que necesitan una red completamente diferente; igualmente,
Otros requisitos 89
Estos tres factores deben ser tenidos en cuenta en la contratación de servicios externos, como
MAN, WAN o conexiones ISP, hardware o servicios de mantenimiento. La velocidad a la que
ocurren los fallos y la velocidad a la que se restaura deben ser incluidos en la especificación
del servicio y debe ser factores en la selección y adjudicación de los servicios de conectividad
de terceros.
Estos factores son frecuentemente descuentan o mal entendido tanto por los ingenieros de la red y
por los propios clientes. Invariablemente, cuando los clientes se les pide a sus necesidades, estos
factores son tan fundamentales para su forma de pensar que no creen que hablar de ellos a menos
que se le pide. El ingeniero de la red debe garantizar que las preguntas adecuadas se les pide como
parte del proceso de requisitos y que las respuestas se documentan de manera que el esfuerzo de
diseño será factor adecuadamente en las decisiones acerca de la arquitectura, la selección de
componentes, la incorporación de los servicios de terceros (por ejemplo, ISP), planificación de la
implementación, las pruebas y la capacidad operativa inicial.
idoneidad operativa, compatibilidad y la confianza se describen en detalle en el capítulo 3.
2.7.2 Requisitos financieros
Un ejemplo común de un requisito de todo el sistema es para limitar los gastos al nivel de los
fondos disponibles para implementar sólo la red. Este requisito sirve para limitar la financiación
a los dispositivos y servicios de red, en lugar de incluir otras partes del sistema (por ejemplo,
ordenadores de sobremesa y servidores). Financiación es a menudo limitado por un límite de
coste global, que consiste tanto de una sola vez y los componentes recurrentes. Los gastos no
recurrentes se basan en la planificación real y la construcción de la red y se componen de
arquitectura de red, diseño, adquisición, despliegue, integración y pruebas, y todos los
componentes de hardware / software, así como la instalación inicial o establecimiento de
cualquier servicio de los proveedores de servicios. Los costos recurrentes son para tareas y
elementos que se espera que ocurran o ser reemplazado / actualizado de manera periódica. Esto
incluye OAM & P red, los costos de los proveedores de servicios, y las disposiciones para las
modificaciones a la red. Los plazos para los costos varían, impulsados por cliente / usuario final,
administrativas, financieras y de gestión de los ciclos y los ciclos de vida de la tecnología
recurrentes.
El nivel de financiación suele ser una limitación para la arquitectura y el diseño; Por lo tanto,
es importante saber lo que este nivel es tan temprano en el proceso de análisis.
como sea posible, con el fin de evitar la creación de una arquitectura y diseño que no son
económicamente viables. Al conocer las limitaciones de financiación y los requisitos para la
red, debemos ser capaces de determinar cuándo una arquitectura / diseño que se adapte a sus
necesidades será superior a los fondos disponibles. Para determinar esto temprano en el
proceso, podemos desarrollar argumentos para cambiar el nivel de financiación, los requisitos
para la red, o ambos.
Los requisitos financieros obtenidos durante el proceso de análisis se pueden combinar con los
requisitos de accesibilidad de los usuarios, para formar un cuadro financiero completo de la
red. Más adelante en este libro nos fijamos en las limitaciones de financiación a la arquitectura
y el diseño y ver cómo funcionan estos procesos para optimizar la arquitectura y el diseño con
el fin de minimizar los costos. Veremos que a menudo es beneficioso para ofrecer a los clientes
con múltiples arquitecturas de prototipos y diseños, con diferencias funcionales y financieros
bien definidos, de modo que puedan tomar decisiones claras acerca de cómo quieren gastar su
dinero.
2.7.3 Requisitos de la empresa

Puede haber momentos en los que hay que tener en cuenta los requisitos de la red que se
considera generalmente que los requerimientos de la empresa, tales como teléfono, fax,
voz y vídeo. La integración de este tipo de requisitos sobre la misma infraestructura de
transmisión como de datos se está convirtiendo en común, y tales requisitos de la empresa
deben ser considerados como parte de los requisitos generales para la red.
2.8 La especificación de requisitos y Mapa

Como se ha señalado anteriormente en este capítulo, la especificación de requisitos es un
documento que recoge y da prioridad a los requisitos recogidos para su arquitectura y
diseño, y el mapa muestra las dependencias requisitos de ubicación entre aplicaciones y
dispositivos. Ahora discutimos estos dos documentos con mayor detalle.
En pasar por el proceso de análisis de requerimientos que será la reunión, que se deriva,
y la determinación de los requisitos de una variedad de fuentes, incluidos los usuarios,
la gestión, administración y el personal, así como de los documentos sobre la red
existente, sus aplicaciones y dispositivos. Algunos de los requisitos serán tomadas
textualmente; otros tendrán que ser derivado de la información disponible, y otros
tendrán que ser estimado.
La especificación de requisitos y mapa 91
Especificación de requisitos
Ubicaciones
Identificación / Nombre Fecha Tipo Reunidos / Estado Prioridad
Descripción Derivado
FIGURA 2.14 Plantilla para la especificación de requisitos
Cuando una lista de requisitos se ha desarrollado, tendrá que determinar qué requisitos son
requisitos básicos o fundamentales; que puede considerarse características deseables para la red;
que puede ser implementado en una versión o actualización de la futura red; que han de ser
rechazado; y que en realidad proporcionar información sobre el sistema, pero no son necesariamente
las necesidades reales. También tendrá que dar prioridad a los requisitos para ayudar a determinar
dónde se gastan los fondos, el orden en que se aplican las funciones y características, y en los que
se aplican en la red.
Una especificación de requisitos enumera todos estos requisitos y especifica donde estaban reunidos
desde o la forma en que se derivaron; razones por las que los requisitos se consideran requisitos de la
base, las características, las necesidades futuras, rechazaron requisitos o requerimientos de
información; y sus niveles de prioridad.
Figura 2.14 muestra una plantilla para esta información en una base por-requisito.
Los campos de esta plantilla son las siguientes:
Identificación / Nombre. Esto puede ser un número que identifica el requisito establecido en el orden
en que fue obtenida o derivada, o el nombre de la exigencia.
Fecha. Esto indica la fecha en que se desarrolló este requisito.
Tipo. Esto representa el componente de la que llegó este requisito (Usuario, Programa, del dispositivo
de red, otro).
Descripción. Esta es una lista de los detalles, en su caso, para que ese requisito. Como parte de esta
descripción, puede indicar si el requisito es funcional o el rendimiento en la naturaleza.
Reunidos / Derivado. Si el requisito se reunieron, esta lista en la que se reunieron. Si el requisito se
deriva, esta opción indica la deriva.
Ubicaciones. Esto señala cuando este requisito se aplica en el ambiente, si se sabe.

Estado. Esto representa el estado actual de este requisito (básico o fundamental,

función, requisito futuro, rechazado, o informativo).
Prioridad. Este es un número que representa el nivel de prioridad de este requisito dentro
de su tipo de estado.
Los requisitos pueden ser administrados y seguimiento a través de un procesador de texto

y hojas de cálculo comunes. Los ejemplos que se muestran aquí fueron desarrollados
usando una aplicación de hoja de cálculo. También hay herramientas de software que están
optimizados para el seguimiento de los requisitos. La experiencia ha demostrado que la
mayoría de las aplicaciones de tratamiento de textos y de hojas de cálculo comunes son
suficiente para esta tarea.
Ejemplo 2.2. Análisis de requisitos para una LAN de la empresa.
Se hizo un primer intento de reunir los requisitos para la construcción de una red LAN.
Los resultados fueron los siguientes:
1. 150 usuarios (60 ingenieros, 15HR y Finanzas, Manufactura 30, 10 Gestión, 30

Ventas / Marketing, 5 otro).
2. Cada área en el edificio debe ser compatible con conexiones Fast Ethernet a la columna
vertebral.
3. Base de datos, aplicaciones de visualización, la fabricación y la nómina se consideran

de misión crítica para esta empresa.
4. aplicación de inventario (INV1) para los requisitos de fabricación no determinado

en este momento.
5. Aplicación de base de datos (DB1) requiere un mínimo de 150 kb / s, por sesión.
6. Los usuarios de ingeniería tienen estaciones de trabajo con GigE NIC.

7. aplicación de visualización (VIS1) para las finanzas requiere una capacidad de
hasta 40 Mb / s y 100 ms de retardo de ida y vuelta.
8. aplicación de nómina (PAY1) requiere% el tiempo de actividad 100 (mientras está en

funcionamiento) entre las finanzas y compañía de nómina exterior.
9. Compañía debe mantenerse a salvo de los ataques de Internet.
10. Compañía requiere un mínimo de acceso a Internet T1.

La especificación de requisitos y mapa 93
11. red actual será reemplazado por completo, por lo que no hay requisitos de red existente.
12. Otras aplicaciones generales: correo electrónico, procesamiento de textos, acceso a la
Web internos y externos. El primer intento de una especificación de requisitos se vería
como el de la Figura 2.15. Los requisitos son simplemente enumeran en orden, ya que no
existen niveles de estado o de prioridad asignados a este punto. Hay dos excepciones a
esto: los requisitos 1 y 11 se muestran con una
Especificación de requisitos
Identificación/
Nombre
Fecha Tipo Descripción Reunidos / Derivado Ubicaciones Estado Prioridad
distribución usuario es: 60 ingenieros, 15 HR y Finanzas,

Recopilada de
1 14Jan01 Usuario Manufactura 30, 10 Gestión, 30 Ventas / Marketing, 5 Otros ver Mapa información TBD
Gestión
Cada área del ed ificio debe ser compatible con conexiones Recopilada de
2 12Jan01 Red todos Bldgs TBD TBD
Fast Ethernet a la columna vertebral Gestión
Bases de datos, visualización, fabricación y aplicaciones

de nómina son considerados de misión crítica para esta Recopilada de
3 12Jan01 Solicitud ver Mapa TBD TBD
empresa. Más inf ormación necesaria. Gestión
aplicación de inventario (INV1) para los

Recabada deosl
4 20Jan01 Solicitud requisitos de fabr icación no determinado en usuarios
ver Mapa TBD TBD
usuarios (MAN)
este momento
aplicación de bas e de datos (DB1) requiere un mínimo Recopilada de

5 14Jan01 Solicitud TBD TBD TBD
de 150 Kb / s, por sesión diferentes usuarios
usuarios de ingeni ería tienen estaciones de trabajo con Recabada de l os

6 02Feb01 Dispositivo ver Mapa TBD TBD
GigE NIC usuarios (ENG)
aplicación de visua lización (VIS1) para las finanzas requiere una

Derivados de la
7 20Jan01 Solicitud capacidad de hast a 40 Mb / s y 100 ms de retardo de ida y vuelta ver Mapa TBD TBD
aplicación
aplicación de nómina (PAY1) requiere 100% de tiempo

Recopilada de
8 11Feb01 Solicitud (mientras está en funcionamiento) entre las finanzas y la ver Mapa TBD TBD
Gestión
empresa de nómina fuera
Compañía debe mantenerse a salvo de los ataques de Recopilada de

9 12Jan01 Red TBD TBD TBD
Internet Gestión
Empresa requier e un mínimo de acceso a Internet El personal obtenida

10 02Feb01 Red ver Mapa TBD TBD
T1 de Red
red actual será reemplazado por completo, por lo que no

El personal obt enida
11 02Feb01 Red hay requisitos de red existente N/A información TBD
de Red
Otras aplicaciones generales: correo electrónico,

El personal obtenida
12 20Jan01 Solicitud procesamiento de textos, acceso a la web interna y externa. TBD TBD TBD
de Red
Más información necesaria.
FIGURA 2.15 El comienzo de una especificación de requisitos

Edificio A, 1ª planta
Equipo de habitaciones Manufactura (30 Usuarios)

No usado
(conexión a Internet)
(aplicación de inventario)
(Fast Ethernet a BB)
El área del vestíbulo
Edificio A, segundo piso
HR / Finanzas (15 Usuarios)
(aplicación de nómina de tiempo de

Ingenieria
actividad del 100% cuando está activo)
In
geniería (60 usuarios)
(Fast Ethernet a BB) (visualización Aplicación 40 Mb
Ventas y Marketing / s, 100 ms de retardo)
(30 usuarios) (Fast

Gestión (10 Usuarios) Ethernet a BB) (GigE NIC) (Fast
(Fast Ethernet a BB) Ethernet a BB)
No usado
FIGURA 2.16 El comienzo de un mapa Requisitos
estado de información(info).Además,siemprequeseaposible,lasubicacionesdeestosrequisitossecolocanenel
mapa requisitos correspondientes. El mapa requisitos se muestra en la Figura 2.16.
2.9 conclusiones
El proceso de análisis de requisitos se trata de identificar, recoger, y la evaluación de
los requisitos de la red. Los requisitos del sistema se pueden separar en sus
componentes, donde la elección de componentes se basa en su entorno y lo que quiere
lograr con la arquitectura y el diseño de la red. En este capítulo hemos considerado
componentes basados en usuarios, aplicaciones, dispositivos y redes. Este es un punto
de partida para agrupar requisitos. A medida que desarrolla su propio proceso de análisis
de requisitos, usted debe determinar cómo va requisitos grupo tendría.
95
Requisitos forman la base sobre la que se desarrolla la arquitectura y el diseño de la red.
La experiencia demuestra que cuanto más esfuerzo que puso en el desarrollo de un buen
conjunto de requisitos y la comprensión del sistema que será apoyado por esta red, el
mejor de su arquitectura y diseño de la red será.
Al separar los requisitos del sistema en componentes, el conjunto de requisitos se hace
más viable. Al aplicar los procesos, principios y directrices de la siguiente capítulo a cada
uno de estos componentes, usted comenzará a ver cómo la comprensión cada componente
le ayuda a construir una imagen del sistema en su conjunto.
Después de haber cubierto los conceptos de análisis de requisitos, ahora estamos listos
para analizar el proceso de análisis de requisitos. A medida que trabaja a través del
siguiente capítulo, tenga en cuenta el conjunto de requisitos que hemos identificado aquí
para cada componente del sistema, y cómo se pueden combinar en una especificación
de requisitos y exigencias mapa.
2.10 Ejercicios
1. ¿Por qué es importante para la arquitectura y el diseño de la red de análisis de
requisitos? Da tres razones.
2. Categorizar cada uno de los siguientes requisitos como núcleo / fundamental,

característica, o informativo.
a. La red debe ser compatible con interfaces Ethernet Fast Ethernet y Gigabit para todos los
dispositivos de la red.
b. backbone de la red debe ser actualizable en capacidad de 10 Gb / s dentro de los dos años de
implementación.
c. departamento financiero requiere protección de cortafuegos en el servidor.
d. red existente se compone de segmentos Ethernet 10BaseT y FDDI.
e. personal de la red les gustaría ser capaz de facturar a los usuarios de servicios de red.
f. núcleo de la red no debe generar o terminar cualquier tráfico de usuarios.
g. Red debe admitir el tráfico de vídeo digital desde cámaras de vídeo a distancia, y puede soportar,
además, el sonido de estas cámaras.
3. Categorizar cada uno de los siguientes requisitos como usuario, la aplicación,

dispositivo, o red.
a. servidores de base de datos deben ejecutar software de la marca XYZ.
b. Teleconferencias requiere al menos la capacidad de 350Kb / s.
c. Los usuarios deben ser capaces de enviar trabajos de impresión de hasta 25 MB de tamaño.
d. Cada red de acceso debe ser capaz de dar servicio a 200 usuarios corporativos.
4. Dé un ejemplo de un requisito a medida que fluye desde el usuario de la aplicación al

dispositivo de red. Mostrar cómo se hace más técnica en cada componente.
96
5. ¿Qué requisitos del cliente a continuación podrían ser categorizados como de misión
crítica? A medida que la velocidad crítica? Como en tiempo real? Como ninguno de
estos? Dar razones de cada elección.
a. El procesamiento de los datos de telemetría de un lanzamiento del transbordador espacial, y
siempre que los datos de control de la misión durante el lanzamiento. (Cliente: NASA).
b. las solicitudes de procesamiento de cajeros automáticos en toda una ciudad. (Cliente:
Banco).
c. procesar las solicitudes de páginas web de sus servidores. (Cliente: proveedor de servicios
de Internet).
6. Dé un ejemplo de una aplicación de misión crítica para cada uno de estos tres entornos:
gobierno, militar, comercial. ¿Por qué cada aplicación se considerará de misión crítica?
7. La Sección 2.4.1 describe varios tipos de retardo (en tiempo real, explosión
interactiva, a granel interactiva, y asíncronos). Dar ejemplos de aplicaciones o
tipos de tráfico que tienen cada tipo de demora.
8. rendimiento Delay es cada vez más importante en apoyo de las necesidades del
usuario y de aplicaciones. Describe por
qué •retraso
Voz sobre IP (VoIP)
es importante para las siguientes aplicaciones:
• No tamponada (en tiempo real) de vídeo o audio
• teleconferencias
9. Basándose en los siguientes lugares de aplicación, desarrollar una aplicaciones

de mapa usando la plantilla proporcionada
(véase la figura 2.17).
campus LAN
Construyendo un
Edificio
Acceso
principal
edificio B externo Internet
Ingeniería
Fuera de las
edificio C
instalaciones de Datos Archivo
FIGURA 2.17 Plantilla para el ejercicio 9

ejercicios 97
a. Existe una aplicación informática distribuida entre todos los servidores de cómputo.
segundo. Existe una aplicación / el acceso al almacenamiento de datos entre todos los servidores de cómputo y los servidores de
almacenamiento en Ingeniería principal.
do. Hay una aplicación de migración de datos entre la ingeniería principal, exterior Edificio de Acceso y datos fuera del
sitio Archivo.
10. Los dispositivos que a continuación pueden ser considerados dispositivos

informáticos genéricos? Servidores? dispositivos especializados?
a. Una máquina ATM.
b. Portátiles que ejecutan sistema operativo Linux.
c. cluster de computación de IBM de 128pcs.
d. Sun Enterprise servidor de base de datos 450
e. PC de escritorio que ejecuta Windows 2000
11. Agregue los siguientes dispositivos al mapa aplicaciones desarrolladas en el
problema 4.
a. Servidores de cómputo se encuentran en los edificios A, B, y C (un servidor cada uno),
y cinco servidores informáticos se encuentran en Ingeniería principal.
b. Los servidores de almacenamiento se encuentran en Ingeniería Principal (dos
servidores), Edificio de acceso externo (un servidor), y en el lugar fuera del sitio Archivo
de Datos (un servidor).
12. Lista de las 10 aplicaciones principales que se planea utilizar en su (o su cliente) a
la red, o que se utiliza actualmente en la red existente. Enumerar las características
de rendimiento reales o estimados para cada aplicación y tratar de colocarlos en
grupos. También puede tratar de asignarlos a los grupos de aplicación que figuran
en la Sección 2.4.2.

Unidad 2.en - Es

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Unidad 2.en - Es

Diunggah oleh

Hak Cipta:

Format Tersedia

2

2.2.1 Requisitos y Características

Ejemplo 2.1. Ejemplos de requisitos básicos y sus métricas asociadas

requisitos informativos y pueden tener conjuntos de características, las requisitos

 Debería / recomendados. Estas palabras clave indican que el requisito

 Mayo / opcional. Cuando un requisito es verdaderamente opcional, puede ser

¿Por qué hacer el análisis de requisitos? Aunque el análisis de requisitos 61 es

Además, las compensaciones en la arquitectura y el diseño se deben realizar con

En el proceso de análisis de los requisitos que utilizamos requisitos para distinguir

2.3 Requisitos de usuario

Usuario Requerimientos de usuarios

Figura 2.2 Tipos de requisitos de usuario

usuarios Nivel más alto, menos técnico

Nivel más bajo, más técnicos

Servidores Switches routers

Timeless es un requisito que el usuario pueda acceder, transferir o modificar la información

Confiabilidad, es decir, la disponibilidad desde la perspectiva del usuario, es un requisito para el

La calidad de presentación se refiere a la calidad de la presentación al usuario. Esta puede ser la

La compatibilidad es un conjunto de características que describe qué tan bien el cliente

2.4 requerimientos de aplicacion

. Las interfaces de componente de aplicación con los componentes de usuario y

Aplicación Requerimeientos de aplicaciones

FIGURA 2.4 Tipos de Requisitos de la solicitud

2.4.1 Tipos de aplicaciones

• Las aplicaciones de misión crítica tienen requisitos RMA predecible, garantizados,

• Las aplicaciones de tasa creitica tienen requisites de capacidad predecibles,

• Las aplicaciones en tiempo real e interactivas tienen requisites de retardos

• La pérdida de datos sensibles. Los ejemplos incluyen cliente aplicaciones

• Pérdida de vida. Los ejemplos incluyen aplicaciones de monitoreo de transporte o

por un exceso de la ingeniería de la red con capacidad de reserva, o mediante la

Actualmente, la mayoría de las aplicaciones se consideran en tiempo no real. aplicaciones

particularmente el componente de aplicación, abrumar el retardo de extremo a extremo o

Rafaga Interactiva Interactiva-granel

Estricto Relación de temporización entre

Figura 2.5 Tipos de retardo

del orden de microsegundos. Un ejemplo de aplicaciones masivas interactivas es la

2.4.2 Grupos de aplicaciones

cajero (ATM), los sensores en el hogar, o un ordenador remoto, a dispositivos

• Tele * Aplicaciones de servicio. Este grupo se describen las aplicaciones que

• Operaciones, administración, mantenimiento y aprovisionamiento de aplicaciones (OAM

2.4.3 Ubicaciones de aplicaciones

76 CAPÍTULO 2 requisitos de análisis: Concepts

Figura 2.6 Un ejemplo Aplicaciones Mapa

Un ejemplo de un mapa de aplicaciones, o un dibujo de donde se aplican las aplicaciones,

2.5 Requisitos de los dispositivos

Requisitos de los dispositivos 77

Dispositivo Requisitos de los dispositivos

Figura 2.7 Tipos de Requisitos de los dispositivos

2.5.1 Tipos de dispositivos

Los dispositivos se pueden agrupar en tres categorías: dispositivos genéricos de cómputo,

La falta de comprensión de los dispositivos finales ha dado lugar a lo que se conoce

Típicamente hay muchos dispositivos de computación genéricos en un sistema, y sería

78 CAPÍTULO 2 requisitos de análisis: Concepts

PC de gama alta 10/100M Word, PP,

Laptop 56 Kb AMD Win XP Word, PP, Others

DB - Base de Datos SC - SW Científico

Figura 2.8 Una Plantilla Ejemplo de descripciones de dispositivo

Los dispositivos especializados tienden a ser dependiente de la localización. Esto es

usuario del equipo Dispositivo Video digital

FIGURA 2.9 Dispositivos especializados

considerar en la localización de información específica, de bibliotecas, universidades,

2.5.2 Características de presentación

El problema “último pie” presentado anteriormente se centra en el rendimiento de varios