Элементы верхнего колонтитула диаграммы
Поможем в ✍️ написании учебной работы
Поможем с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой
Поле Назначение
Used AT Используется для отражения внешних ссылок на данную диаграмму (заполняется на печатном документе вручную)
Author, date, project Содержит ФИО автора диаграммы, дату создания, дату последнего внесения изменений, наименование проекта, в рамках которого она создавалась
Notes 1…10 При ручном редактировании диаграмм пользователи могут зачеркивать цифру каждый раз, когда они вносят очередное исправление
Status: Статус отражает состояние разработки или утверждения данной диаграммы. Это поле используется для реализации формального процесса итерации пересмотра и утверждения
Working   Новая диаграмма, глобальные изменения или новый автор для существующей диаграммы

Окончание таблицы 3.1

Поле Назначение
Draft Диаграмма достигла некоторого приемлемого для читателей уровня и готова для представления на утверждение
Recommended   Диаграмма одобрена и утверждена. Какие-либо изменения не предвидятся
Publication Диаграмма готова для окончательной печати и публикации
Reader ФИО читателя
Date Дата знакомства читателя с диаграммой
Context Схематическое изображение функциональных блоков на родительской диаграмме, на котором подсвечен декомпозируемый данной диаграммой блок. Для диаграммы самого верхнего уровня (контекстной диаграммы) в поле помещается контекст ТОР

 

Таблица 3.2

Элементы нижнего колонтитула диаграммы

Поле Назначение
Mode Номер диаграммы, совпадающий с номером родительского функционального блока. Имя родительского функционального блока
Title Имя родительского функционального блока
Number (C-Number) Уникальный идентификатор данной версии данной диаграммы

 

Цикл «эксперт – аналитик »

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

Формально механизм рецензирования и модификации диаграмм поддерживается полями Status и нумерацией диаграмм (см. табл. 3.1).

 

Построение моделей

 

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

- Почему моделируется данный процесс?

- Что выявит данная модель?

- Как можно применить созданную модель?

Для этого формулируются цели моделирования, в которых необходимо:

- выявить задачи каждого работника предприятия;

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

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

 

Точка зрения

 

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

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

 

Границы моделирования

 

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

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

Чтобы облегчить правильное определение границ моделирования при разработке IDEF0-моделей, существенные усилия затрачиваются на разработку и рецензирование контекстной диаграммы IDEF0 (диаграммы «самого верхнего» уровня). Иногда даже прибегают к построению дополнительной диаграммы для отображения уровня более высокого, чем контекстный для данной модели, что позволяет обозначить систему, внутри которой располагается объект для моделирования. Существенные затраты на разработку контекстной диаграммы вполне оправданны, поскольку она является своего рода «точкой отсчета» для остальных диаграмм модели, и вносимые в нее изменения каскадом отражаются на всех лежащих ниже уровнях.

Когда границы моделирования понятны, также становится ясным, какие объекты системы по тем или иным причинам не вошли в модель.

 

Дата: 2019-03-06, просмотров: 187.