Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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.
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
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
60 CAPÍTULO 2: Conceptos de Análisis de Requisitos
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.
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
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
oportunidad
Aplicacion interactividad
confiabilidad
Calidad de presentación
adaptabilidad
Dispositivo Seguridad
Asequibilidad
Funcionalidad
Compatibilidad
Red Crecimiento futuro
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
Aplicación
Dispositivo
red
FIGURA 2.3 Requisitos vuelto más técnico medida que se acercan a los dispositivos de red
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.
66 CAPÍTULO 2 requisitos de análisis: Concepts
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.
usuarios
Tipos de aplicación
Dispositivo Grupos de Aplicaciones
Locaalización de aplicacion
red
Este tipo de aplicaciones son descritos por sus requisitos y métricas de servicio.
68 CAPÍTULO 2: Conceptos de Análisis de Requisitos
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.
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”
Requisitos de la solicitud 69
(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
70 CAPÍTULO 2: Conceptos de Análisis de Requisitos
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.
Requisitos de la solicitud 71
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,
72 CAPÍTULO 2: Conceptos de Análisis de Requisitos
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
¿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.
• 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
74 CAPÍTULO 2 requisitos de análisis: Concepts
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.
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
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.
ódigo de Estados Unidos Trabajo: NAAD Ch02-P370480 05/03/2007 10:03 a.m. Página: 77 Trim: 7.5in × TS: 9.25in Integra, India
usuarios
Aplicación
Tipo de
Tipo de Procesador Sistema Aplicaciones
dispositivo
NIC Operativo
Pentium I Word, PP, Finance
PC de gama baja Win95/98/200
10M Ethernet
Estacion de Linux
DB, Graphics,
10/100M AMD
trabajo CAD,SC
Ethernet
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.
Requisitos de los dispositivos 79
Centro de Investigación
Túnel de viento
Hospital
Punto de venta
Dispositivo
Equipo
medico Negocio
Red
portátil
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
/
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
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.
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
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.
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.
Usuario
Las Restricciones de las redes existentes.
Escalado esperado de las redes existentes.
Aplicación Interoperabilidad entre redes.
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.
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:
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.
Requisitos de la red 85
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.
Como veremos en los procesos de diseño y arquitectura, hay cuatro tipos de tareas de
gestión de red:
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
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
Efecto: Probabilidad:
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.
88 CAPÍTULO 2: Conceptos de Análisis de Requisitos
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í.
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.
90 CAPÍTULO 2: Conceptos de Análisis de Requisitos
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.
Especificación de requisitos
Ubicaciones
Identificación / Nombre Fecha Tipo Reunidos / Estado Prioridad
Descripción Derivado
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.
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.
Se hizo un primer intento de reunir los requisitos para la construcción de una red LAN.
Los resultados fueron los siguientes:
2. Cada área en el edificio debe ser compatible con conexiones Fast Ethernet a la columna
vertebral.
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
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
Edificio A, 1ª planta
In
geniería (60 usuarios)
(Fast Ethernet a BB) (visualización Aplicación 40 Mb
Ventas y Marketing / s, 100 ms de retardo)
No usado
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.
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
campus LAN
Construyendo un
Edificio
Acceso
principal
edificio B externo Internet
Ingeniería
Fuera de las
edificio C
instalaciones de Datos Archivo
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
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.