- •Таблица 1.1
- •Стандарты проектирования информационных систем
- •2.3. Основы методики
- •2.6. Процедура разработки
- •2.6.6. Шаг 5. Разработка сети "как должно быть"
- •Рис. 2.5. Описание процедуры шага 5
- •2.6.7. Шаг 6. Реализация проекта
- •2.7. Используемые средства проектирования
- •2.7.1. Графический язык проектирования
- •2.8. Возможности расширения методики
- •Таблица 5.1
- •5.3.2. Компоненты моделей
- •Таблица 5.3
- •1. Объекты, входящие в состав узлов:
- •Таблица 5.4
- •Таблица 5.5
- •Таблица 5.6
смоделирована характеристика рабочей нагрузки каждого центра обслуживания.
Модель существующей сети должна быть верифицирована. Проверка правильности сначала выполняется членами группы, а затем – экспертами проекта. Как только сетевая модель "как есть" утверждена, входящие в нее элементы и их параметры в обязательном порядке фиксируются, чтобы отличать их от новых элементов, которые появятся в моделях "как должно быть".
2.6.5.Шаг 4. Модификация объединений в соответствии
ссуществующими технологиями
Сетевые проектировщики расширяют объединения за счет компонентов и услуг, которые потенциально могут использоваться при проектировании сети "как должно быть". Однако источники для наполнения объединений в этом случае иные. Прежде всего, новые компоненты и услуги, которые в них добавляются, – отражение опыта и экспертных оценок членов группы проектирования. В общем случае информация о новых компонентах берется из каталогов изделий, журналов, связанных с сетевыми и информационными системами, материалов соответствующих телеконференций и посредством живого общения. Информация о новых и еще не используемых в проекте услугах исходит от местных и удаленных операторов телекоммуникаций и из вычислительных сетей, обслуживающих территории, на которых расположено предприятие.
Необходимо накопить как можно больше информации (имеются в виду параметры элементов объединений) о технологиях, которые используются или потенциально применимы для построения корпоративной сети, поскольку на основании этих данных будут генерироваться модели формирования очередей, надежности и модели стоимости для различных вариантов проекта.
2.6.6. Шаг 5. Разработка сети "как должно быть"
Разработка перспективного проекта сети включает действия, предпринимаемые для создания различных его вариантов и выбора из них наиболее подходящего. Первая стадия на данном шаге – создание нового или изменение существующего проекта. Результаты последующих стадий могут привести к необходимости возврата к первой стадии. Процессы, выполняемые на шаге 5, показаны на рис. 2.5.
Создание первого наброска проекта или изменение существующего
проектировщиками выполняется на основе собственного опыта. В частности, на этой стадии из объединений добавляются (либо используются для замены существующих) новые компоненты или услуги.
38
Необходимо, чтобы все добавления или изменения строго соответствовали сетевым ограничениям. Также должны быть определены все параметры компонентов и услуг проекта, чтобы обеспечить корректность моделей формирования очередей, надежности и стоимости.
Генерация моделей формирования очередей, надежности и стоимости заключается в следующем. Модели формируются для рассматриваемого на данном этапе варианта проекта, таким образом, они будут сгенерированы для всех сопоставляемых его вариантов.
При проверке правильности сетевого проекта и сгенерированных моделей на ее первом этапе разработчики должны убедиться, что в проекте соблюдены все сетевые ограничения. Затем построенные модели должны быть верифицированы. Ошибки в моделях могут быть вызваны как невнимательностью их разработчиков, так и неполнотой или отсутствием характеристик используемых в проекте сетевых компонентов и услуг. Проект сети, приведший к генерации ошибочных моделей, должен быть скорректирован.
Создание |
|
Генерация |
|
Верификация |
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
||||||
(изменение) |
|
моделей |
|
моделей |
|
|
Х |
|
|
|
|||
|
|
|
|
|
|
|
|||||||
проекта |
|
|
|
|
|
|
|
||||||
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1 |
|
|
2 |
|
|
3 |
|
|
|
П1 |
Анализ |
||
|
|
|
|
|
|
|
|
|
|
|
|
разработки |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Документация |
|
Выбор |
|
|
|
|
7 |
|
||
|
|
|
|
|
|
|
|
|
|||||
|
|
|
обоснования |
|
(утверждение) |
|
|
Х |
|
|
|
||
|
|
|
|
|
|
|
|
|
|||||
|
|
|
проекта |
|
проекта |
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
5 |
|
|
6 |
|
|
|
П3 |
Создание |
||
|
|
|
|
|
|
||||||||
|
Х |
|
|
|
|
|
|
|
|
|
|
(изменение) |
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
проекта |
|||||
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
П2 Создание
(изменение) проекта
Рис. 2.5. Описание процедуры шага 5
Следующий этап разработки – ее анализ и его проверка. Анализ моделей формирования очередей, надежности и стоимости требуется для того, чтобы оценить эффективность, надежность и характеристики стоимости проекта. Проведенный анализ должен проверяться теми
39