Este documento describe los pasos para el diseño de redes corporativas utilizando una metodología descendente. Explica que el diseño de redes debe comenzar analizando los requerimientos y metas del negocio, así como las restricciones. Luego, se debe realizar un diseño lógico de la red antes de pasar al diseño físico. Finalmente, se prueba, optimiza y documenta el diseño.
All the content of this website is informative and non-commercial, does not imply a commitment to develop, launch or schedule delivery of any feature or functionality, should not rely on it in making decisions, incorporate or take it as a reference in a contract or academic matters. Likewise, the use, distribution and reproduction by any means, in whole or in part, without the authorization of the author and / or third-party copyright holders, as applicable, is prohibited.
.- La frase “Eso no se puede hacer por Protección de Datos” suele aparecer como algo sobrevenido e inesperado en muchos procesos cuando ya están desplegados. Ello lleva a abordar “procesos de adaptación a la LOPD”, que suelen consistir en asegurar el cumplimiento formal de determinados requisitos legales. Por esta razón, muchos desarrolladores e ingenieros de sistemas suelen percibir la Protección de Datos como un estorbo, una “piedra en el engranaje” que solo supone dificultades.
.- El reciente paradigma de diseño basado en los principios de Privacidad por Diseño (PbD, por las siglas en Inglés de “Privacy by Design”) pretende darle la vuelta a estos planteamientos y adoptar una visión proactiva de la Protección de Datos.
- Nos enseña a incorporar en la arquitectura de nuestras aplicaciones los requisitos de garantía de privacidad de las personas cuyos datos de carácter personal se tratan en ellos,
- de la misma forma que ya hoy en día se han incorporado los requisitos de seguridad, modularidad, usabilidad, accesibilidad, etc.
.- Este enfoque se ve complementado con otras tendencias recientes, como son:
- la elaboración de Análisis de Impacto sobre la Privacidad (PIA, “Privacy Impact Assesment”)
- la utilización de Técnicas de Mejora de la Privacidad (PET, “Privacy-Enhancing Technologies”)
All the content of this website is informative and non-commercial, does not imply a commitment to develop, launch or schedule delivery of any feature or functionality, should not rely on it in making decisions, incorporate or take it as a reference in a contract or academic matters. Likewise, the use, distribution and reproduction by any means, in whole or in part, without the authorization of the author and / or third-party copyright holders, as applicable, is prohibited.
.- La frase “Eso no se puede hacer por Protección de Datos” suele aparecer como algo sobrevenido e inesperado en muchos procesos cuando ya están desplegados. Ello lleva a abordar “procesos de adaptación a la LOPD”, que suelen consistir en asegurar el cumplimiento formal de determinados requisitos legales. Por esta razón, muchos desarrolladores e ingenieros de sistemas suelen percibir la Protección de Datos como un estorbo, una “piedra en el engranaje” que solo supone dificultades.
.- El reciente paradigma de diseño basado en los principios de Privacidad por Diseño (PbD, por las siglas en Inglés de “Privacy by Design”) pretende darle la vuelta a estos planteamientos y adoptar una visión proactiva de la Protección de Datos.
- Nos enseña a incorporar en la arquitectura de nuestras aplicaciones los requisitos de garantía de privacidad de las personas cuyos datos de carácter personal se tratan en ellos,
- de la misma forma que ya hoy en día se han incorporado los requisitos de seguridad, modularidad, usabilidad, accesibilidad, etc.
.- Este enfoque se ve complementado con otras tendencias recientes, como son:
- la elaboración de Análisis de Impacto sobre la Privacidad (PIA, “Privacy Impact Assesment”)
- la utilización de Técnicas de Mejora de la Privacidad (PET, “Privacy-Enhancing Technologies”)
Esta presentación aborda en la nueva forma de educación del siglo XXI: el "aula virtual", sus características, ventajas y la implementación del Plan Ceibal en Uruguay como estartegia de cambio educativo
Breve descripción del concepto de la Miopia de Marketing de Theodore Levitt.
Short description about Marketing Myopia concept developped by Thedore Levitt. "Make it easy" business learning.
Pasos para iniciar tu propio negocio y/o proyecto. Aquí encontraran como hacer un plan de negocios y las opciones de financiamiento que existen en el mercado de los que crean aplicaciones.
Esta presentación aborda en la nueva forma de educación del siglo XXI: el "aula virtual", sus características, ventajas y la implementación del Plan Ceibal en Uruguay como estartegia de cambio educativo
Breve descripción del concepto de la Miopia de Marketing de Theodore Levitt.
Short description about Marketing Myopia concept developped by Thedore Levitt. "Make it easy" business learning.
Pasos para iniciar tu propio negocio y/o proyecto. Aquí encontraran como hacer un plan de negocios y las opciones de financiamiento que existen en el mercado de los que crean aplicaciones.
Especificación de Arquitectura de SoftwareSoftware Guru
El objetivo de la plática es mostrar con un ejemplo como especificar la arquitectura de un sistema.
Hoy en día hay varios libros de Arquitectura de software que nos muestran: Que debemos hacer, Que podemos usar pero pocos nos dan un ejemplo concreto.
Esta platica está dirigida a aquellos colegas que quieren iniciar en el rol de Arquitecto de Software, que tienen la experiencia y conocimientos pero tienen duda de como plasmar sus decisiones de diseño ó se preguntan si su diseño es suficiente y correcto.
En esta platica se desarrolla en 2 partes:
En la 1ª. se repasaran algunos conceptos relativos a la práctica de Arquitectura tales como objetivo, requerimientos no funcionales, riesgos, restricciones, patrones, vistas, etc.
En la 2ª. parte se mostrará como hacer una especificación de Arquitectura de un caso real pero acotado.
Al final espero que el participante se quede con una referencia que sirva para mejorar su práctica de Diseño de Arquitectura.
All the content of this website is informative and non-commercial, does not imply a commitment to develop, launch or schedule delivery of any feature or functionality, should not rely on it in making decisions, incorporate or take it as a reference in a contract or academic matters. Likewise, the use, distribution and reproduction by any means, in whole or in part, without the authorization of the author and / or third-party copyright holders, as applicable, is prohibited.
Curso: Redes y comunicaciones II: 01 Cloud computing.
Dictado en la Universidad Tecnológica del Perú, Lima - Perú, ciclos 2011-3 (octubre/2011) y 2012-1 (abril/2012).
Requisitos No Funcionales
• Son aquellos que no se asimilan a las funciones del sistema como tal.
• Especifican restricciones sobre cómo que limiten las elecciones para
construir una solución.
• Son menos números que los RF.
• Conciernen a aspectos como:
➢ Calidad: usabilidad, confiabilidad, eficiencia.
➢ Implementación: plataforma de software, lenguaje de
programación, hardware.
➢ Ambiente: seguridad, privacidad, confidencialidad.
El nuevo paradigma Cloud está cambiando la forma en la que entendemos el desarrollo de software. Simplifica notablemente el manejo de la infraestructura para que puedas centrarte exclusivamente en tu negocio. El IaaS Cloud da una vuelta de tuerca a la instalación de arquitecturas y reduce el tiempo de setup, provisioning y puesta en marcha de semanas a horas o minutos.
En este documento se encuentra conglomerado las tareas expedidas por la instructora Lisbeth Jaquez, en el transcurso del desarrollo de Introducción a la Gerencia de Proyectos.
Descubra en este webinar las ventajas que le aportará el diseño y definición de una hoja de ruta SOA durante la implantación de una arquitectura orientada a servicios. El diseño de la hoja de ruta está basado en el análisis de indicadores que muestran el nivel de madurez dentro del Modelo de Referencia de Madurez SOA.
-Resumen del capitulo 1 de Computación en la nube_Luis Joyanes Aguilar
-Universidad Nacional Autónoma de Honduras en el Valle de Sula UNAH-VS
-Carrera: Informática Administrativa
-Presentado por: David Salomón Sandobal
-Asignatura: Perspectiva de la Tecnología Informática
-Catedrático: Guillermo Brand
-II Periodo Académico 2016
-San Pedro Sula, Cortés, Honduras C.A.
Similar a Ucv sesion 15 diseño optimiz -redes (20)
2. 2
DATOS GENERALES
1.1 Unidad Académico : Escuela Académico Profesional de
Ingeniería Sistemas
1.2 Semestre académico : 2014-I
1.3 Asignatura : Redes y Comunicaciones I
1.4 Ciclo de estudios : VI
1.5 Horas semanales : 05 (HT03/HP02)
1.6 Duración (semanas) : 17
1.7 inicio y termino : 31/03/2014 al 26/07/2014
1.8 Docente : Ing. CIP Pedro P. Díaz Vilela
5. 5
Diseño Descendente de Redes
• El diseño de redes debe ser un proceso
completo, que asocie las necesidades del
negocio a la tecnología disponible, para
generar un sistema que maximice el éxito de
una organización.
En el área de Redes Locales (LAN) es más
que comprar unos pocos dispositivos
En Redes de Área Extendida (WAN) es más
que llamar a la compañía telefónica
6. 6
Comenzar por Arriba
• No comenzar conectando direcciones IP
• Analizar las metas, técnicas y de negocio
primero.
• Explorar las estructuras de grupos y
divisiones para encontrar a quiénes sirve la
red y dónde residen.
• Determinar qué aplicaciones se ejecutarán y
cómo se comportan esas aplicaciones en una
red.
• Enfocarse primero en la capa 7 o más arriba.
7. 7
Capas del Modelo OSI
Aplicación
Presentación
Sesión
Transporte
Red
Enlace
FísicaCapa 1
Capa 7
Capa 6
Capa 5
Capa 4
Capa 3
Capa 2
8. 8
Diseño Estructurado
• Se enfoca en entender los flujos de datos, tipos de
datos y procesos que acceden a los datos y los
modifican.
• Se enfoca en entender la ubicación y las necesidades
de las comunidades de usuarios que acceden o
cambian datos y procesos.
• Pueden usarse varias técnicas y modelos para
caracterizar el sistema existente, los nuevos
requerimientos de los usuarios y una estructura para el
sistema futuro.
• Se desarrolla un modelo lógico antes del modelo físico.
– El modelo lógico representa los elementos básicos,
divididos por funciones y la estructura del sistema.
– El modelo físico representa los dispositivos, las
tecnologías específicas y la implementación.
9. 9
Ciclo de Vida del Desarrollo de Sistemas
• En inglés: SDLC.
• ¡En este curso SDLC no significa
Synchronous Data Link Control!
• Los sistemas típicamente se
desarrollan y continúan existiendo
durante un cierto período de
tiempo, llamado frecuentemente
Ciclo de Vida del Desarrollo del
Sistema.
11. 11
• Fase 1:
– Analizar Requerimientos.
–Analizar metas de negocio y restricciones.
–Analizar metas técnicas, pros y contras.
–Caracterizar la red existente.
–Caracterizar el tráfico de la red.
Fases del Diseño de Redes
12. 12
• Fase 2:
– Diseño Lógico de la Red.
–Diseñar una topología de la red.
–Diseñar modelos de direccionamiento y
nombres.
–Seleccionar protocolos de conmutación
(switching) y enrutamiento (routing).
–Desarrollar estrategias de seguridad para la
red.
–Desarrollar estrategias para el mantenimiento
de la red.
Fases del Diseño de Redes
13. 13
• Fase 3:
– Diseño Físico de la Red.
–Seleccionar tecnologías y dispositivos para las
redes de cada campus.
–Seleccionar tecnologías y dispositivos para la
red corporativa (de la empresa u organización).
Fases del Diseño de Redes
14. 14
Fases del Diseño de Redes
• Fase 4:
– Probar, Optimizar y Documentar el Diseño de
la Red.
–Probar el diseño de la red.
–Optimizar el diseño de la red.
–Documentar el diseño de la red.
16. 16
Metas del Negocio
Incrementar las ganancias:
• Reducir costos de operación.
• Mejorar las comunicaciones.
• Acortar el ciclo de desarrollo de productos.
• Expandirse a mercados internacionales.
• Hacer asociaciones con otras compañías.
• Ofrecer mejor soporte al cliente o crear
nuevos servicios.
17. 17
Nuevas Prioridades de Negocio
• Mobilidad.
• Seguridad.
• Robustez (Tolerancia a fallas).
• Continuidad después de un desastre.
• Los proyectos de red deben priorizarse con
base en metas fiscales.
• Las redes deben ofrecer un retardo bajo,
requerido para aplicaciones de tiempo real
como VoIP.
19. 19
Recabar información antes de la
primera reunión
• Antes de reunirse con el cliente, sea éste interno
o externo, recaba alguna información básica
relacionada con el negocio.
• Información como:
–Productos o servicios que se ofrecen.
–Viabilidad financiera.
–Clientes, suplidores, competencia.
–Ventajas competitivas.
20. 20
• Intenta obtener
–Un resumen conciso de las metas
del proyecto.
• ¿Qué problemas quieren
resolver?
• ¿Cómo puede ayudar la
tecnología a hacer el negocio
más exitoso?
• ¿Qué debería pasar para que el
proyecto tenga éxito?
Reunión con el Cliente
21. 21
• ¿Qué pasaría si el proyecto falla?
–¿Tiene impacto sobre una función crítica del
negocio?
–¿Este proyecto es visible para la alta
gerencia?
–¿Quién está de tu lado?
Reunión con el Cliente
22. 22
• Descubre cualquier sesgo
–Por ejemplo:
• ¿Sólo usarán productos
de ciertas compañías?
• ¿Evitarán usar ciertas
tecnologías?
• ¿Existen diferencias
entre la gente de
informática y el resto de
la organización?
–Habla con el personal
técnico y gerencial.
Reunión con el Cliente
23. 23
– Obtén una copia del organigrama:
• Nos mostrará la estructura general de la organización
• Sabremos los usuarios que debemos tomar en cuenta
• Sabremos las ubicaciones geográficas que debemos tomar
en cuenta.
Reunión con el Cliente
24. 24
Reunión con el Cliente
– Obtén una copia de la política de seguridad.
• ¿Cómo afectaría esta política un nuevo diseño?
• ¿Cómo impactaría un nuevo diseño en la
política?
• ¿La política es tan estricta que impide al
diseñador de la red hacer su trabajo?
– Comienza catalogando los recursos de red que la
política de seguridad debería proteger.
• Hardware, software, aplicaciones y datos.
• Menos obvio, pero quizás más importante,
propiedad intelectual, secretos de negocio y
cualquier información que pueda ser usada en
contra de la reputación de la compañía.
25. 25
Alcance del Proyecto de Diseño
• ¿De corto alcance?
– Por ejemplo, permitir que la gente de ventas puedan
acceder vía una VPN
• ¿De largo alcance?
– Por ejemplo, un rediseño completo de la red de la
empresa
• Use el modelo OSI para aclarar el alcance
– Por ejemplo: una nueva aplicación de reporte
financiero vs un nuevo protocolo de enrutamiento vs
nuevos enlaces de datos (digamos inalámbricos)
• ¿El alcance está dentro del presupuesto, la capacidad
del personal, la agenda de la empresa?
26. 26
Recabar información más detallada
• Aplicaciones.
–Ahora y después de terminar el proyecto.
–Incluir aplicaciones de productividad y de
gestión de sistemas.
• Comunidades de usuarios.
• Almacenamiento de datos.
• Protocolos.
• Arquitecturas lógica y física actuales.
• Rendimiento actual.
27. 27
Resumen
• Método sistemático.
• Enfocarse primero en los requerimientos
del negocio, las restricciones y las
aplicaciones.
• Entender la estructura corporativa del
cliente.
• Entender el estilo de negocio del cliente.
28. 28
Repaso
• ¿Cuáles son las fases principales del diseño
de redes, en una metodología descendente?
• ¿Cuáles son las fases principales del diseño
de redes en una metodología PDIOO?
• ¿Por qué es importante conocer el estilo de
negocio del cliente?
• Mencione algunas metas típicas de un negocio
hoy en día.