Аис1

Ключевые понятия IDEF0-методологии

Основное понятие IDEF0-методологии – это понятие «модель». IDEF0-модель – это ис-- кусственный объект, представляющий собой виртуальный образ системы и ее компонентов, в виде функциональной структуры объекта (совокупность диаграмм), отображающих производимые им действия и связи между этими действиями. Модель разрабатывают для понимания, анализа и принятия решений о реконструкции (реинжиниринге) или замене существующей, либо проектировании новой ИС. IDEFO-модели состоят из трех типов документов: графических диаграмм, текста и глоссария. Эти документы имеют перекрестные ссылки друг на друга.

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

В IDEFO система представляется как совокупность взаимодействующих процессов или функций. Такая чисто функциональная ориентация является принципиальной - функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации. Поэтому исследование или разработка любой сложной системы должна начинаться с функционального анализа и моделирования как системы в целом, так и всех ее подсистем. Основу представления системы представляет целевая функция. Фeyrwbz, согласно стандарту IDEF0 – это совокупность взаимосвязанных и взаимодействующих видов деятельности, преобразующая входы в выходы, в которой входами к процессу обычно являются выходы других процессов. Такое формализованное представление функции является необходимым и достаточным ее определением для целей планирования, обеспечения, управления и улучшения. В результате моделирования системе на основе ее функций разрабатывается функциональная модель.

Функциональная модель - модель, ориентированную на функции и представляющая собой структурированное изображение функций системы или среды (блоки), информации и объектов (стрелки), связывающих эти функции.

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

К важным понятиям IDEF0 является термин бизнес-правила. Модель деловых процессов позволяет выявить и точно определить бизнес-правила, используемые в деятельности предприятия. Если при разработке ИС не будут учтены существующие на предприятия бизнес-правила, доказавшие свою жизнеспособность и эффективность, то такая система будет функ-ционировать неадекватно. Очень часто бизнес-правила на предприятии не записаны в инструкциях или стандартах предприятия: они как бы есть, но и их как бы нет. В

21

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

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

Область моделирования– это основа построения модели, представляющая собой описание как системы в целом, так и ее компонентов. Область моделирования включает в себя точку зрения системного аналитика - позицию, с которой рассматривается система, и цель моделирования - вопросы, на которые построенная модель должна дать ответ. Родительский блок (Parent Box)- функциональный блок, - подлежащий декомпозиции. По отношению к дочерней диаграмме – блок-предок.

Родительская диаграмма (Parent Diagram)– диаграмма, содержащая один или более родительских блоков.

Дочерняя диаграмма (Child diagram)- диаграмма второго уровня, содержащая функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы.

Дочерний блок (Child Box)- любой функциональный блок на дочерней диаграмме. Диаграмма декомпозиции - полученный при декомпозиции родительских блоков набор тщательно взаимосогласованных описаний.

Диаграмма с потоками- диаграмма, описывающая все, связанное с декомпозируемым блоком и его стрелками. При декомпозиции интерфейсные стрелки, присоединенные к блоку, через ICOM коды переносятся на диаграмму-потомок. Таким образом, родительский блок и его интерфейсные дуги определяют контекст для диаграммы-потомка.

Глоссарий. Для каждого из элементов IDEF0: диаграмм, функциональных блоков, интерфейсных стрелок стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Например, для управляющей стрелки «распоряжение об оплате» глоссарий может содержать перечень полей соответствующего дуге документа, необходимый набор виз и т.д. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.

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

Функциональное моделирование

Под моделью в IDEFO понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы. IDEF0-модель это процессная модель, т.к. основывается на процессах/функциях (activity) системы.

22

Моделируемая система рассматривается как произвольное подмножество Вселенной потому что:

автор/авторы сами умозрительно определяют, будет ли некий объект компонентом системы, или он рассматривается как внешнее воздействие;

оно зависит от точки зрения на систему.

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

Наилучшим способом моделирования является функциональная стратегия, которая базируется на функциональных взаимоотношениях действий системы, т.к. она заставляет автора точно определить: что делает система, независимо от того, как она работает. Такая чисто функциональная ориентация является принципиальной - функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоде-лировать логику и взаимодействие процессов организации.

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

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

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

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

охватывать все стадии жизненного цикла продукции, относящиеся к сфере деятельности предприятия.

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

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

Процесс в функциональной модели есть преобразование входных материалов или информации в продукт на выходе с использованием ресурсов в виде механизма и при выполнении условий, представленных в виде управления. Такую интерпретацию часто называют бизнес-правилом описания процесса. Функциональная модель процессов, разработанная в такой интерпретации, позволяет точно описать бизнес – правила организации, проанализировать их. А затем, выявив «узкие» места и внося изменения в деловой процесс, оценить степень влияния предлагаемых изменений на существующие бизнес - правила.

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

23

использовании соответствующего программного обеспечения).

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

IDEFO-диаграммы следует разрабатывать в точном соответствии с IDEFOметодологией;

при моделировании должен быть организован итеративный процесс рецензирования каждого фрагмента модели и модели в целом;

начинать следующий уровень декомпозиции можно лишь после полного завершения

работы над родительской диаграммой, т.е. после присвоения ей статуса «Публикация».

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

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

Формальное электронное описания процессов предприятия в виде функциональной модели является основой для проведения анализа существующих процессов. Полученная модель позволяет:

определить какие объекты или информация служат сырьем для процессов, и какие ресурсы для этого необходимы;

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

узнать, какие факторы являются управляющими;

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

Внастоящее время функциональная модель обычно используется для описания существующих процессов моделируемого объекта (модель AS-IS), а также для описания идеальных взаимоотношений в моделируемой системе (модель TO-BE).

Функциональная модель AS-IS

Модель AS-IS – это модель «как есть», т.е. модель уже существующего процесса/функции. Обследование процессов является обязательной частью любого проекта создания или развития системы. Построение функциональной модели AS-IS позволяет четко зафиксировать, какие процессы осуществляются на предприятии, какие информационные объекты используются при выполнении функций различного уровня детализации.

На основе модели AS-IS достигается консенсус между различными этапами процесса по тому, «кто что сделал» и что каждый этап добавляет в процесс. Функциональная модель AS-IS является отправной точкой для анализа потребностей предприятия, выявления проблем и “узких” мест и разработки проекта совершенствования деловых процессов. Модель AS-IS позволяет выяснить, «что и как мы делаем сейчас» перед тем, как определить то, «что и как будет делаться завтра». Анализ функциональной модели AS-IS позволяет понять, где находится проблемная ситуация, в чем будут состоять преимущества новых процессов и каким изменениям подвергнется существующая структура организации процесса. Исследование необходимости реструктуризации (выявление и ликвидация недостатков) в существующих процессах достигается за счет применения декомпозиции (анализа), производящаяся даже там, где функциональность на первый взгляд является очевидной. Так,

например, признаками неэффективности существующих процессов могут быть:

бесполезные, неуправляемые и дублирующиеся функции;

26

неэффективный документооборот (нужный документ не оказывается в нужном месте в нужное время);

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

При создании модели AS-IS неопытным аналитиком может возникать достаточно распространенная ошибка - это создание идеализированной модели, особенно в том случае, когда модель создается под влиянием знаний (точки зрения) руководителя. Обычно руководитель знаком с тем, как предполагается выполнение функции по руководствам и должностным инструкциям и часто не знает, как на самом деле подчиненные выполняют требуемые функции. Поэтому могут создаваться модели, называемые SHOULD BE (как должно бы быть), и несущие ложную информацию и которую невозможно в дальнейшем использовать для анализа.

Функциональная модель TO-BE

Найденные в модели AS-IS недостатки исправляются путем создания модели ТО-ВЕ (как будет), т.е. модели новой организации процессов на предприятии. Создание и внедрение ИС приводит к изменению условий выполнения отдельных операций, структуры процессов и предприятия в целом. Это приводит к необходимости изменения системы правил, используемых на предприятии, модификации должностных инструкций сотрудников. Функциональная модель TO-BE позволяет уже на стадии проектирования будущей ИС определить эти изменения. Применение функциональной модели TO-BE позволяет не только сократить сроки внедрения информационной системы, но также снизить риски,

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

Функциональная модель TO-BE позволит четко определить распределение ресурсов между операциями делового процесса, что дает возможность оценить эффективность использования ресурсов после предлагаемого реинжиниринга.

Дополнительные функции и возможности при построении функциональной модели процессов в модели TO-BE:

модель позволяет идентифицировать все информационные объекты, которыми оперирует предприятие в своей деятельности. В отличие от информационных моделей (Data Flow Dia-grams, IDEF1X) функциональная модель IDEF0 отражает, как именно используются инфор-мационные объекты в рамках деловых процессов;

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

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

Общепринятая технология проектирования ИС подразумевает сначала создание модели AS-IS, затем на основе ее анализа определяются направления улучшение процессов, т. е. создание модели ТО-ВЕ. Только на основе разработанной модели ТО-ВЕ в дальнейшем происхо-дит построение модели данных, прототипа и затем окончательного вариант ИС. Если в основу автоматизации предприятия будет изначально заложена модель AS-IS, то создаваемая «новая» ИС будет выполняться по принципу «все оставить, как есть», и вместо информати-зации предприятия на основе новых ИТ, произойдет (в лучшем случае) простая компьютери-зация несовершенных процессов. В результате внедрение и эксплуатация такой

27

«новой» ИС приведет к дополнительным издержкам на закупку оборудования, создание программного обеспечения и их сопровождение.

Декомпозиция и диаграммы декомпозиций

Ориентация модели (ее контекст, точка зрения и цель) должна быть направлена так, чтобы результирующие структурные описания предоставили исходные данные для их использования методологиями имитационного моделирования, проектирования баз данных или структурного программного проектирования. Важной особенностью методологии IDEF0 является постепенное введение уровней детализации по мере создания модели. IDEF-диаграммы строятся в соответствии с той информацией, которую они несут. Это позволяет представлять информацию о системе таким образом, что пользователь (читатель) получает хорошо очерченные порции новой информации, анализируя каждую следующую диаграмму. Для такого разделения на составляющие применяется термин «анализ», означающее разложение на составляющие, из которого получается обоснование термина «структурный анализ». Но декомпозиция не только анализ, это больше чем разложение на части, декомпозиция включает в себя также синтез. Полная декомпозиция заключается как в начальном разделении объекта на более мелкие части, так и в последующем их соединении для более детального описания объекта. Применяя принцип декомпозиции неоднократно, возможно структурировать описание процесса до любого уровня подробности. Модель, полученная в результате декомпозиции, показывает результат взаимодействия анализа и синтеза.

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

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

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

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

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

28

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

Модель уточняется за счет использования дополнительных текстовых диаграмм и глоссария. Диаграммы более высокого уровня (А-0, А0,) – являются наиболее общим описанием про-цесса, представленным в виде отдельных блоков. Декомпозиция этих блоков на других диаграммах позволяет обеспечить требуемый уровень детализации описания процесса.

Декомпозиция диаграмм

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

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

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

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

Процесс декомпозиции ограниченного объекта

Процесс декомпозиции ограниченного объекта обычно состоит из следующих шагов:

1.Выбор блока диаграммы.

2.Рассмотрение объекта, определенного этим блоком.

3.Создание новой диаграммы.

4.Выявление недостатков новой диаграммы.

5.Создание альтернативных декомпозиций.

6.Корректировка новой диаграммы.

7.Корректировка всех связанных с ней диаграмм.

Шаги 1-3 представляют созидательную часть процесса. Выполняя их, аналитик концентрирует свои усилия, связанные с выявлением новой информации об объекте, на более высоком уровне детализации, чтобы достичь ясности изложения. Шаги 4-7 составляют этап самостоятельного рецензирования, в ходе которого аналитик, создав новую диаграмму, проверяет, какую она несет информацию и в каком она находится отношении с

29

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

Перед декомпозицией блоков родительской диаграммы необходимо очень хорошо изучить ее функции, чтобы свести до минимума повторную работу при возможных изменениях в диаграммах верхних уровней. Опираясь на хорошо проработанную диаграмму А0, можно сосредоточиться на построении диаграмм А1, А2, А3..., не пытаясь максимально декомпозир-вать одну функцию, строя, например, диаграммы А11, А111 или А21, А211.

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

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

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

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

В процесс проведения декомпозиции иногда возникает желание произвести декомпозицию какой-либо функции/данных на большое количество подсистем (более 6), но, как показывает опыт, всегда есть возможность произвести объединение нескольких 2-3 функций в одну. Диаграммы с количеством блоков более шести сложны для восприятия читателями и вызывают у автора трудности при внесении в нее всех необходимых графических объектов и меток. Однако при объединении функций и данных желательно ограничиваться разумным уровнем сложности: четыре-пять функциональных блоков, как правило, лучше всего. Слишком много данных и функций часто содержат слишком много информации. Это приводит к запутанным диаграммам. Наоборот, небольшое число блоков дает слишком мало, и диаграмма становится почти бесполезной. Если автор уверен, что достиг желаемого баланса, следует проверить, во всех ли отношениях созданное описание адекватно объекту, определенному блоком и его граничными стрелками на родительской диаграмме. Только после этого можно считать, что уже имеется все необходимое для построения диаграммы. Поэтому для построения модели, адекватной предметной области на всех уровнях абстрагирования после каждого сеанса декомпозиции обязательно проводится сеанс экспертизы - каждая диаграмма проверяется экспертами в данной предметной области, и/или представителями заказчика, и/или людьми, непосредственно участвующими в процессе разработки модели. В дальнейшем аналитик под влиянием коллективных знаний экспертов, читательской аудитории, а также других авторов сможет создать полноценное описание, которое после детализации будет удовлетворять цели модели.

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

Цель моделирования и точка зрения на создание модели

30