Нет, это задача разработчика и его аналитиков (как правило). Заказчик не будет прерывать производственный процесс. Он платит деньги производителю, дальше, как правило, начинается его работа.
Вообще, методологий есть много, и каждый проект по-своему уникален, но надо учитывать, что заказчик может не уметь (и как правило не умеет) формировать требования. А разработчик может не знать (и как правило не знает) специфики бизнеса заказчика. Потому между ними есть промежуточное звено — аналитики.
Нужны бизнес-требования и фукнциональные требования. Проект разбивается на фазы, требования ко всему шестилетнему, разумеется, никто не пишет.
Просто оно в работе с реальным бизнес-заказчиком слегко по-другому, чем при написании игры :-)
Надо, чтобы заказчик был уверен, что вы понимаете, чего они хочет. Что вы разобрались в специфике его предметной области (как думаете, доверят вам писать систему управления цисками, например, без спецификации, где вы детально расскажете, что вы с ними будете делать, и как?). Спецификации — средство коммуникации с заказчиком.
Спецификация также — продукт работы аналитика. Кодер не будет разбираться, можно ли в циске присваивать двум интерфейсам IP адреса из одной сети, а аналитик, в свою очередь, не будет разбираться, как это реализовать программно. Спецификации — средство коммуникации внутри команды.
Кроме того, чтобы продукт приносил выгоду обеим стороным, он должен быть закончен в срок и в каких-то пределах. Неправильно бесконечно «размывать» проект, требуя от производителя добавлять все новую и новую функциональность, которую не предусмотрели заранее, это затягивает сроки. Неправильно и «золотить» продукт, вкладывая время и ресурсы в фичи, которых не просил заказчик. Спецификация — средство определения границ проекта.
Вот, думаю, может, напишу статью про UML и спецификации как-нибудь :-)
Совершенно не согласен. Пример: огромная информационная система, проект развивается 6 лет, постоянные изменения, подстраивание под меняющиеся бизнес-процессы заказчика.
Как обеспечить «включени» в команду новых людей и передачу знаний?
Далее: как без спецификаций (хоть каких-то) формализировать и выяснять требования, когда заказчик — компания с 20000+ работниками, и информацию получаешь от десятков из них? Которая, к тому же, еще и бывает часто противоречива.
Я, вот, как раз потихоньку собираю себе домашнюю лабу. Хочется собрать ее одновременно для R&S, MPLS/BGP/QoS, Voice и Security, потому процесс пока, увы, медленно идет.
Кстати, как раз недавно прислали 2610 :) А Ваш УЦ не готов ими поделиться на каких-либо условиях? Я бы с удовольствием…
А Вы, кстати, если не секрет, как к Вашим вершинам шли? :) Самообучение, работа, преподавание в УЦ — что бы Вы назвали наиболее эффективным?
Между автономными системами. Но мы ж рассматриваем данный конкретный случай, когда нам сообщают, что легли египетские BGP neighborships. Что там делается внутри мы даже догадываться, строго говоря, не можем.
Уверен, что нет — посмотрите на график — 30 минут. У одного хорошо известного мне оператора с ближнего востока только цисок и только в access сети — больше 2500 штук, раскиданные по POP в более чем двухмилионном городе. А еще есть Хуавей, ПакетФронт, PON всякий и прочее. Заметьте, core с его мультиплексорами и усилителями, раскиданными на многие километры уже по всей стране, мы тоже не считаем.
За 30 минут выключить это все нереально совершенно даже со всеми NMS и OSS. Надо выбирать, что и как выключать.
Я бы, вот, вы знаете, все равно access отключал. Потому что это надежнее. А вот BGP — быстрее. Думаю, это тоже фактор.
Ну, и вариант muromec про фейсбук и твиттер мне тоже нравится.
Мне непонятно, я тупой :) BGP сообщает о египетских сетях всему интернету. Отключите BGP на внешний мир, и внутри, в Египте, все все равно смогут общаться и координировать действия.
А вот отключи клиентов на access уровне и оставь BGP — и связи ни у кого не будет, и весь мир не будет уверен в тотальной недоступности египетских сетей.
Есть три предположения: либо боятся кооридиации «из вне», либо не хотят, чтобы информация о событиях опадала «во вне», либо BGP отключили просто на всякий случай, как подстраховку к первому варианту.
Cisco Systems и американский оператор Intelsat уже запустили похожую технологию под названием Internet Routing in Space [1][2]. Вообще, идея пакетной маршрутизации через спутники очень и очень интересна и перспективна, да, но на сегодняшний момент она не доступна простым смертным.
В моем варианте не видят. Быть может, дело в том, что у меня реальный интерфейс — 802.11g, но это пальцем в небо. Еще возможно, что у вас как-то интересно сконфигурирован внешний интерфейс на компе, например, с двумя IP адресами.
В любом случае, мост — это решение, наиболее близкое к реальному положению вещей при связке двух сетей, плюс, дает больше гибкости в конфигурации интерфейсов.
Не знаю, не сталкивался с подобным. А что за имидж, можете дать ссылку?
Loopback интерфейс нам нужен, чтобы связать виртуальную сеть с реальной. Если повесить Cloud на внешний интерфейс, до виртуальной сети сможет добраться только ваш один компьютер, т.к. фреймы в сети адресуются по MAC адресу, а ваш компьютер по ARP не анонсирует, что на этом интерфейсе есть еще устройства (виртуальный роутер) — вы ж интерфейс не переконфигурируете.
Простыми словами: другие машины в сети не знают, куда слать фрейм, адресованный виртуальному роутеру. Только ваша машина знает, но никому не говорит :-)
А когда мы создаем loopback и мост, наш компьютер начинает анонсировать по ARP адреса всего того, что подключено к виртуальной сети, в сеть реальную, и наоборот. Вообще, стандартная функциональность мостов как устройств тех еще времен, когда Ethernet был шиной :-)
В свое время у меня был ноутбук HP510 с 2.13 GHz Pentium M и 512 Mb RAM, там удавалось запустить не больше трех роутеров. Сейчас на другом ноуте с 2.2 GHz Dual-Core и 3 Gb RAM запускается минимум 8 устройств (больше не пробовал — нет надобности). Так что ваша конфигурация будет где-то посредине :)
Вообще, методологий есть много, и каждый проект по-своему уникален, но надо учитывать, что заказчик может не уметь (и как правило не умеет) формировать требования. А разработчик может не знать (и как правило не знает) специфики бизнеса заказчика. Потому между ними есть промежуточное звено — аналитики.
Нужны бизнес-требования и фукнциональные требования. Проект разбивается на фазы, требования ко всему шестилетнему, разумеется, никто не пишет.
Просто оно в работе с реальным бизнес-заказчиком слегко по-другому, чем при написании игры :-)
Надо, чтобы заказчик был уверен, что вы понимаете, чего они хочет. Что вы разобрались в специфике его предметной области (как думаете, доверят вам писать систему управления цисками, например, без спецификации, где вы детально расскажете, что вы с ними будете делать, и как?). Спецификации — средство коммуникации с заказчиком.
Спецификация также — продукт работы аналитика. Кодер не будет разбираться, можно ли в циске присваивать двум интерфейсам IP адреса из одной сети, а аналитик, в свою очередь, не будет разбираться, как это реализовать программно. Спецификации — средство коммуникации внутри команды.
Кроме того, чтобы продукт приносил выгоду обеим стороным, он должен быть закончен в срок и в каких-то пределах. Неправильно бесконечно «размывать» проект, требуя от производителя добавлять все новую и новую функциональность, которую не предусмотрели заранее, это затягивает сроки. Неправильно и «золотить» продукт, вкладывая время и ресурсы в фичи, которых не просил заказчик. Спецификация — средство определения границ проекта.
Вот, думаю, может, напишу статью про UML и спецификации как-нибудь :-)
mrFox пишет, на мой взгляд, правильные вещи: если система простая, ее специфицировать незачем. Если сложная — ее специфицировать обязательно.
Как обеспечить «включени» в команду новых людей и передачу знаний?
Далее: как без спецификаций (хоть каких-то) формализировать и выяснять требования, когда заказчик — компания с 20000+ работниками, и информацию получаешь от десятков из них? Которая, к тому же, еще и бывает часто противоречива.
Я, вот, как раз потихоньку собираю себе домашнюю лабу. Хочется собрать ее одновременно для R&S, MPLS/BGP/QoS, Voice и Security, потому процесс пока, увы, медленно идет.
Кстати, как раз недавно прислали 2610 :) А Ваш УЦ не готов ими поделиться на каких-либо условиях? Я бы с удовольствием…
А Вы, кстати, если не секрет, как к Вашим вершинам шли? :) Самообучение, работа, преподавание в УЦ — что бы Вы назвали наиболее эффективным?
en.wikipedia.org/wiki/Crane_(machine)#Self-erecting_crane
Рекомендую для ознакомления:
en.wikipedia.org/wiki/Burj_Khalifa
За 30 минут выключить это все нереально совершенно даже со всеми NMS и OSS. Надо выбирать, что и как выключать.
Я бы, вот, вы знаете, все равно access отключал. Потому что это надежнее. А вот BGP — быстрее. Думаю, это тоже фактор.
Ну, и вариант muromec про фейсбук и твиттер мне тоже нравится.
А вот отключи клиентов на access уровне и оставь BGP — и связи ни у кого не будет, и весь мир не будет уверен в тотальной недоступности египетских сетей.
Есть три предположения: либо боятся кооридиации «из вне», либо не хотят, чтобы информация о событиях опадала «во вне», либо BGP отключили просто на всякий случай, как подстраховку к первому варианту.
Впрочем, может, сделали и то, и другое. Чтоб наверняка.
В любом случае, мост — это решение, наиболее близкое к реальному положению вещей при связке двух сетей, плюс, дает больше гибкости в конфигурации интерфейсов.
Loopback интерфейс нам нужен, чтобы связать виртуальную сеть с реальной. Если повесить Cloud на внешний интерфейс, до виртуальной сети сможет добраться только ваш один компьютер, т.к. фреймы в сети адресуются по MAC адресу, а ваш компьютер по ARP не анонсирует, что на этом интерфейсе есть еще устройства (виртуальный роутер) — вы ж интерфейс не переконфигурируете.
Простыми словами: другие машины в сети не знают, куда слать фрейм, адресованный виртуальному роутеру. Только ваша машина знает, но никому не говорит :-)
А когда мы создаем loopback и мост, наш компьютер начинает анонсировать по ARP адреса всего того, что подключено к виртуальной сети, в сеть реальную, и наоборот. Вообще, стандартная функциональность мостов как устройств тех еще времен, когда Ethernet был шиной :-)
Была похожая проблема — GNS3 не всегда корректно эмулирует особенности железа, используемые разными IOS. Попробуйте другой IOS и/или другую платформу.