Сетевые ограничения. Сетевой проект должен удовлетворить множеству условий и ограничений, которые существуют в сетях ЭВМ. Например, провайдер услуг frame relay может обеспечивать передачу данных только по каналам T1, а не по волоконно-оптическим; так же и два узла, связанных соединением, должны иметь поддержку общего канального протокола, соответствующего типу этого соединения.

Не следует смешивать сетевые ограничения и ограничения конструктивные. Под последними понимаются условия, которым должен удовлетворить сетевой проект. Конструктивные ограничения выражаются в терминах качества услуг, максимальных издержек и т. д.

Библиотеки компонентов. С быстрым развитием компьютерных и телекоммуникационных технологий все острее встает потребность своевременного освоения новых технологий и компонентов с учетом их характеристик и особенностей применения. Важно иметь библиотеки для концептов всех перечисленных типов. Каждая библиотека концептов должна содержать наиболее распространенные их образцы. Кроме того, в библиотеке должна сохраняться и соответствующая техническая информация, имеющая отношение к образцу концепта. Например, маршрутизатор является образцом в библиотеке узлов, а его технические спецификации (отбраковка, скорость передачи и т. д.) – часть списка атрибутов для данного типа узла.

Пользователи могут к каждой библиотеке добавлять новые образцы. Например, пользователь может добавить новую топологию в библиотеку топологий, если новая ЛВС должна иметь топологию, описание которой в библиотеке отсутствует.

2.6. Процедура разработки

Излагаемый далее материал представляет собой прототип базовой процедуры сетевого проектирования, а также верификации и усовершенствования выполненного проекта.

Имеются три сценария проектирования сети, при которых использование методики может оказаться полезным:

•Модернизация существующей сети предприятий (наиболее общий

случай).

•Моделирование сети предприятия "как есть".

•Проектирование сети предприятия с самого начала.

При описании прототипа процедуры создания, проверки и совершенствования сетевого проекта следует подробно остановиться на наиболее общем случае, т. е. на наращивании вычислительных мощностей уже существующей корпоративной сети. При этом данная процедура будет включать в себя решение следующих трех основных задач:

1)фиксации состояния существующей сети;

2)определения рабочей нагрузки сети "как должно быть".

30

3) проектирования сети "как должно быть".

Второй и третий сценарии – подмножества первого. Для второго сценария использования методики, т. е. моделирования сети "как есть", требуется только первая из базовых задач. С другой стороны, третий сценарий использования требует решения второй и третьей задач.

Рассматриваемая процедура рассчитана на масштабные конструкторские работы и подразумевает наличие группы разработчиков. Реальные проекты обычно бывают более узкими и могут не требовать проведения всех работ, описанных далее. Применение данной процедуры, как и любой другой методики, в значительной степени зависит от цели, для которой она используется.

Сетевой дизайн – эволюционный процесс, посредством которого моделируются существующие сети, собираются требования, создаются, оцениваются, верифицируются, документируются и совершенствуются разрабатываемые проекты. В общем случае при использовании методики необходимо рекурсивно выполнить следующие фазы:

1.Обследование – накопление информации о существующих сетевых компонентах, требованиях и существующих технологиях.

2.Классификация – идентификация сетевых концептов (метатипов), таких как типы узлов, типы соединений, типы топологий (так же, как и элементов данных типов).

3.Создание "гипотезы" сети – постулирование предлагаемой сети исходя из собранных данных и фактов.

4.Верификация – удостоверение в том, что модель сети "как есть" правильна и все условия и ограничения в проекте были соблюдены.

5.Анализ – создание моделей формирования очередей, надежности,

истоимости сетевого проекта, проверка правильности этих моделей и их анализ.

6.Обсуждение – подключение специалистов по проблемной области к процессу проверки правильности выводов, сделанных проектировщиками.

7.Совершенствование – фильтрация, улучшение, корректировка и добавление деталей к сетевому проекту.

Перечисленные фазы воплощены в прототипе описываемой процедуры. Однако их следует рассматривать скорее как "образ мыслей", а не как строго последовательные шаги, и проектировщики не должны стараться применить указанные действия, неукоснительно следуя приведенной последовательности. Кроме того, они не должны ожидать, что организация работы в виде фаз проекта обязательно определяет сроки начала и окончания конкретных действий. Скорее, фазы отражают, какие из шагов являются преобладающими в течение данного интервала времени. Таким образом, эти шаги могут быть систематизированы в фазы лишь для облегчения менеджмента проекта. Далее описываются шаги, составляющие процедуру рассматриваемой методики, что позволяет установить базисный каркас для сетевых конструкторских работ.

31

Определение цели – важный начальный шаг в сетевых конструкторских работах. Если цель считается само собой разумеющейся или вообще игнорируется, то проектировщики скорее всего обнаружат, что все их усилия по разработке будут проигнорированы клиентом, поскольку при отсутствии цели единственными критериями, определяющими завершение работы, остаются бюджет и время. Если же цель работы ясно определена и регулярно уточняется, проект чаще всего может быть завершен досрочно, а значит, и с экономией отведенного на него бюджета. Определение назначения разработок включает:

•составление списка установленных потребностей клиента и источников каждой из них (например, отдельные персоны, проекты или вся организация);

•установление информационных целей проекта в терминах использования сетевого проекта;

•выяснение приоритетов между ними.

Процесс утверждения цели может быть облегчен посредством списка вопросов, на которые должен ответить клиент. Например:

1.Признаки каких проблем, какие трудности или возможности представляют наибольший интерес для клиента?

2.Кто должен получить наибольшую пользу от внедрения новой сети?

3.В решении каких задач нуждается клиент?

4.Какие причины стоят за необходимостью проектирования сети?

5.Какие рассуждения должны использоваться при выборе проекта

сети?

Определение области – шаг, не менее важный в сетевых конструкторских разработках. Как только определена цель работы, становится возможной фиксация и области (контекста) приложения проекта. Определение контекста начинается с выделения тех подсетей предприятия,

вкоторых должны быть сделаны изменения и фиксация их в качестве ограничителей области. В идеальном случае в определение контекста должны входить только те области, которые точно соответствуют потребностям клиента. Однако при работе корпоративной сети изменения одной подсети часто воздействуют на другие. Следовательно, должны быть определены и те подсети, которые вообще не должны затрагиваться проектом.

2.6.2.Шаг 1. Создание группы разработчиков

иорганизация сбора данных

Если начальная цель проекта и контекст были определены, нужно организовать сбор необходимой информации. На этом этапе сетевого проекта выполняются три действия: утверждение состава группы проектирования; распределение должностей среди ее членов; распределение между этими членами обязанностей по разработке.

При создании группы проектирования сети обычно используются следующие должности или, вернее сказать, "роли":

33

•проектировщик – эксперт в сфере сетевого проектирования, который будет являться основным разработчиком моделей проекта;

•заказчик или представитель заказчика – человек или организация, по требованию которых осуществляется развитие проекта;

•эксперт предметной области – источник специальных знаний, сотрудник сетевого отдела клиента;

•контактер – сотрудник, играющий роль интерфейса между аналитиком и специалистом по проблемной области;

•руководитель (менеджер) проекта – человек, в конечном счете ответственный за все сетевые конструкторские работы;

•рецензенты – люди, хорошо осведомленные в предметной области и/или методике проектирования сетей, ответственные за рассмотрение и одобрение черновых моделей и документов. Рецензенты, уполномоченные делать письменный критический анализ проекта, являются комментаторами, остальные – читателями. Рецензентами могут являться все члены группы проектирования, включая экспертов предметной области;

•библиотекарь – сотрудник, ответственный за регистрацию и хранение исходных и разрабатываемых материалов, документов, файлов, создание копий, а также за своевременное распространение необходимой информации между остальными членами группы;

•все остальные (рядовые) сотрудники, выполняющие работы, связанные с сетевым проектированием.

В больших проектах должность библиотекаря необходима, в менее масштабных эту роль может исполнять аналитик. Утверждая должность библиотекаря, руководитель проекта возлагает на соответствующего сотрудника ответственность за сбор, каталогизацию, проверку и распределение исходных материалов, комплектов документации, справочников, файлов и т. д. на всем протяжении разработки. Дополнительно библиотекарь ответствен за сбор справочных моделей и материалов из внешних источников, которые могут использоваться для помощи разработчикам. Библиотекарь также может вести глоссарий терминов в качестве гарантии того, что все аналитики используют одинаковую терминологию. Поддерживаемый ли библиотекарем или неофициально формируемый и совместно используемый аналитиками глоссарий будет расти и подвергаться уточнениям по мере развития проекта.

Стержневая задача в организации деятельности по сбору данных состоит в определении ключевых источников знаний и информации о проблемной области. Работая в сотрудничестве с контактером, лидер проекта или аналитик составляет список экспертов, которых необходимо проинтервьюировать. При создании такого списка полезно получить основную информацию относительно каждого эксперта: занимаемой им должности, текущих обязанностях, а также о тех сферах внутри предметной области (и связанных с ними), в которых данный эксперт имеет опыт. Разумеется, необходимо фиксировать имена, адреса и телефоны привлекаемых экспертов.

34

При сборе информации будут определяться и другие ценные ее источники. К ним можно отнести инструкции, методические руководства, справочники персонала, правила, стратегические руководства, файлы проектов, формальные модели многократного использования и модели, полученные при использовании других методик и технологий. Эти элементы часто выявляют наличие ограничений или имеют ссылки на определенные факты предметной области. Например, отчет о неисправностях сети помогает установить требования по надежности к сети "как должно быть".

Наряду с организацией структуры группы лидер проекта должен заниматься организацией и ее деятельности. Она может начаться с приведения общей методики сетевого проектирования к виду прикладного руководства, адаптированного к конкретным условиям проекта. Прикладное руководство выделяет подходящие для данного проекта приложения методики и используется аналитиками, входящими в группу. Руководство должно включать ключевые моменты стандартов по интервьюированию специалистов по проблемной области, спецификации взаимодействия методов и инструментов, процедуру использования библиотеки проекта, а также стандартный глоссарий терминов. Это руководство может сопровождаться планом проекта. Типичный план проекта очерчивает фазы деятельности с ясно поставленными задачами и контрольными точками, предварительные и окончательные результаты, индивидуальные обязанности членов группы, структуру неформальных и формальных отчетов и т. п.

2.6.3. Шаг 2. Сбор и анализ информации

После того как рабочая группа создана и вчерне определен подход к созданию сети, группа начинает сбор информации. Непосредственно взаимодействуя с персоналом сетевого и EDP-отделов, члены группы документируют замечания и собирают информацию, относящуюся к существующим сетям и требованиям к новой сети; эта информация будет позже проанализирована и использована как базис для получения сетевого проекта.

Подготовка к опросу – начальная стадия сбора информации. Опрос (интервью) – наиболее ценный механизм сбора данных. Интервью с сетевым и коммуникационным персоналом корпорации дают возможность накопить информацию о конфигурации и параметрах существующей сети, а также о связанных с ней проблемах. Интервью с сетевым персоналом и пользователями сети позволяют собрать требования, предъявляемые к новым услугам и качеству обслуживания в сети "как должно быть".

Хотя обычно подход к интервью и его формат могут быть различными в разных проектах, рекомендуется использовать ряд общих принципов. Перед опросом аналитик должен подготовить его примерный план и ряд тех специальных вопросов, которые он должен содержать. Хорошо, если аналитик предварительно сделает краткий очерк следующих моментов:

35

цель интервью; темы, которые будут затронуты; виды интересующей информации; имеющиеся полномочия для проведения опроса и пробные вопросы, которые могут использоваться в начале беседы. В больших проектах руководитель может требовать внесения более формализованных принципов подготовки интервью и стандартов в прикладное руководство, включая стандартные формы для плана интервью, шаблоны вопросов, глоссарий терминов и т. д.

Конечный успех интервью в значительной степени зависит от подготовки к нему, сделанной аналитиком. В свою очередь, успешной подготовке способствует ряд действий:

•планирование интервью и подготовка необходимой логистики;

•установление цели или целей опроса;

•определение и проработка вопросов, которые необходимо задать;

•принятие во внимание вероятности встречных вопросов и проблем интервьюируемого и готовность к их разрешению.

Как только список экспертов, которых следует опросить, составлен, можно разрабатывать расписание интервью. Интервью обычно планируются контактером со специалистами по проблемной области. Аналитик должен удостовериться, что планируемые время и длительность интервью оговорены с соответствующим экспертом или его руководством. Для успеха опроса также важно дополнительное внимание к логистике, в частности, резервирование для проведения интервью подходящего помещения и принятие мер к тому, чтобы была обеспечена комфортная среда для переговоров.

Цель интервью должна быть установлена заранее. При выработке целей интервью аналитики определяют, для чего планируется интервью, и какую информацию необходимо получить от эксперта предметной области. Подготовка краткой формулировки целей часто может оказаться полезной для выработки главного направления, в русле которого будут задаваться вопросы.

Если цель интервью уже установлена, можно начать формулировать список вопросов, которые необходимо задать. Запись этих предварительных вопросов должна организовывать логическую последовательность. Вопросы должны быть ясными по смыслу, в них должны использоваться слова и обороты речи, соответствующие подготовке опрашиваемого эксперта и скорее располагающие к ответу, чем его требующие. При подготовке примерных вопросов, часто полезно иметь в виду следующие общие темы:

1. Каковы конфигурация и параметры существующей сети?

2. Какие проблемы связаны с существующей сетью?

3. Исчезновение или минимизацию каких неотложных проблем ожидает интервьюируемый после внедрения проекта новой сети?

4. Какие дополнительные возможности хотелось бы видеть эксперту в проекте новой сети?

Важный элемент подготовки, часто пропускаемой неопытными аналитиками, – это необходимость объяснить, для чего опрашиваются

36

эксперты, как будет использоваться предоставленная ими информация, и что они могут ожидать взамен. Каждое интервью должно обеспечить взаимное понимание этих трех моментов, чтобы удовлетворить информационные потребности аналитика.

Ключевым моментом рассматриваемого шага является опрос специалистов проблемной области. Разработки графика проведения опросов должна подразумевать одну или несколько из следующих целей:

•сбор дополнительной информации;

•подтверждение и/или пояснение ранее собранной информации;

•проверку экспертами предметной области правильности описаний;

•получение указаний для приобретения дополнительной информации.

Для сбора и каталогизации важных источников информации по мере необходимости проектировщики должны запрашивать копии существующих документов, инструкций, руководств, моделей сети, проектов, которые являются частью существующей сети, отчетов о неисправностях сети, файлов регистрации проблем и т. д. Эти источники могут предоставляться как на электронном, так и на бумажном носителях. Если информационные источники находятся в электронном виде, группа проектирования должна получить права на доступ (чтение) к информации.

На этапе анализа собранных данных осуществляется компиляция собранных данных и материалов интервью, начальные результаты которой каталогизируются в списки, называемые объединениями. "Узел", "связь" и "топология" – метатипы сетевых компонентов, поскольку они включают в себя различные типы сетевых компонентов/топологий, причем каждый тип имеет различные атрибуты. Объединения должны существовать для каждого типа. Следующие два процесса осуществляются итерационно:

1.Создание типов узлов (компьютер, терминал, мост, коммутатор и т. д.), соединений (витая пара, коаксиальный кабель, линия беспроводной связи и т. д.) и топологий (шина, кольцо, двойная шина и т. д.).

2.Заполнение объединений, соответствующих существующим типам, соотнесенным с собранными данными. В некоторых случаях (особенно для узлов и соединений) заполняемые объединения будут включать данные конкретных продуктов и спецификации установленного оборудования и доступных услуг.

2.6.4. Шаг 3. Модель сети "как есть" и характеристика рабочей нагрузки

Для непосредственного моделирования сети "как есть" проектировщик должен применять графический язык, используя элементы из объединений, которые должны быть составлены до начала работы по построению иллюстративной модели. Таким же способом должна быть

37