IDEF0 относится к семейству IDEF, которое появилось в конце 60-х гг. XX в. под названием SADT (Structured Analysis and Design Technique). IDEES может быть использована для моделирования широкого класса систем.
Для новых систем применение IDEE) направлено на определение требований и указание функций для последующей разработки системы, отвечающей поставленным требованиям и реализующей выделенные функции. Применительно к уже существующим системам IDEE) может быть использована для анализа функций, выполняемых системой, и отображения механизмов, посредством которых: эти функции выполняются. Результатом применения IDEE) к некоторой системе является модель этой системы, состоящая из иерархически упорядоченного набора диаграмм, текста документации и словарей, связанных друг с другом с помощью перекрестных ссылок. Двумя наиболее важными компонентами, из которых строятся диаграммы IDEE), являются бизнес-функции, или работы (блоки), и данные, или объекты (дуги), связывающие между собой работы и отображающие взаимодействия и взаимосвязи между ними.
Описание бизнес-процесса
При этом дуги (стрелки), представляя множества объектов, в зависимости от того, в какую грань блока (прямоугольника работы) они входят или из какой грани выходят, делятся на пять видов:
• входа (входят в левую грань работы) — изображают данные или объекты, изменяемые в ходе выполнения работы;
• управления (входят в верхнюю грань работы) — изображают правила и ограничения, согласно которым выполняется работа;
• выхода (выходят из правой грани работы) — изображают данные или объекты, появляющиеся в результате выполнения работы;
• механизма (входят в нижнюю грань работы) — изображают ресурсы, необходимые для выполнения работы, но не изменяющиеся в процессе работы (например, оборудование, людские ресурсы и т.д.);
• вызова (выходят из нижней грани работы) — изображают связи между разными диаграммами или моделями, указывая на некоторую диаграмму, где данная работа рассмотрена более подробно.
Входные дуги изображают объекты, используемые и преобразуемые функциями. Управленческие дуги представляют информацию, управляющую действиями функций. Выходные дуги изображают объекты, в которЬге преобразуются входы. Дуги механизмов IDEES изображают физические аспекты функции (склады, людей, организации, приборы). Таким образом, стороны блока графически сортируют объекты, изображаемые касающимися блока дугами.
Все работы и стрелки должны быть именованы. Первая диаграмма в иерархии диаграмм IDEES всегда изображает функционирование системы в целом. Такие диаграммы называются контекстными.
В контекст входят описание цели моделирования, области (описание того, что будет рассматриваться как компонент системы, а что — как внешнее воздействие) и точка зрения (позиция, с которой будет строиться модель). Обычно в качестве точки зрения выбирается точка зрения лица или объекта, ответственного за работу моделируемой системы в целом.
После описания контекста строят следующие диаграммы в иерархии. Каждая последующая диаграмма является более подробным описанием (декомпозицией) одной из работ на вышестоящей диаграмме (рис. 3.1). Описание каждой подсистемы проводится аналитиком совместно с экспертом предметной области.
Понятия | Взаимосвязи блоков IDEF0
Обычно экспертом является человек, отвечающий за эту подсистему, и поэтому досконально знающий все ее функции. Таким образом, вся система разбивается на подсистемы до нужного уровня детализации, и получается модель, аппроксимирующая систему с заданным уровнем точности. Получив модель, адекватно отображающую текущие бизнес- процессы (так называемую модель AS-IS), аналитик может увидеть все наиболее уязвимые места системы. После этого с учетом выявленных недостатков можно строить модель новой организации бизнес-процессов (модель ТО-ВЕ).
Увидеть эти уязвимые места в системе можно, например, с помощью функционально-стоимостного анализа (ФСА) — методологии непрерывного совершенствования продукции, производственных технологий и организационных структур.
Задачей ФСА является снижение всех видов затрат при одновременном сохранении или повышении качества. Функционально-стоимостный подход к рассмотрению объекта обоснован тем, что потребителя интересует не объект сам по себе, а его функции, качество их выполнения и затраты на приобретение этого качества. Основным критерием совершенства (конкурентоспособности) объекта с позиции ФСА является его потребительная стоимость, определяемая соотношением качества (полезности) объекта и затрат потребителя.
В частности, с помощью ФСА можно решать задачи: анализа затрат (выявление зон неоправданно высоких затрат на всем жизненном цикле объекта); оценки решений (программное обеспечение для количественной оценки новых идей и проектов); оценки конкурентоспособности (определение конкурентоспособной цены и т.д.).
В /МТЮ-моделях используются как естественный, так и графический языки. Графический язык IDEE) организует естествен-
ный язык определенным и однозначным образом. Это позволяет создавать модели систем с требуемой степенью детализации. Сбор информации (опрос) является первым этапом на пути создания модели бизнес-процессов. После этого формируется перечень вопросов, на которые должна ответить модель. Затем определяются цель и «точка зрения» модели.
Выбор цели осуществляется с учетом составленного перечня вопросов, а выбор точки зрения — в соответствии с выбором позиции, с которой описывается система.
Функциональная модель представляет систему функций, реализуемых в системе через взаимоотношения ее объектов. IDEFG- модель имеет единственную цель и единственный субъект. Цель модели — получение ответов на определенную совокупность вопросов. Субъект — это сама система. Методология IDEE) требует, чтобы создаваемая модель системы рассматривалась всегда с одной и той же позиции, или точки зрения.
После определения точки зрения, с которой описывается модель, создается список данных, а потом список функций. Начать следует с выделения всех основных групп и категорий данных, используемых и генерируемых системой.
При этом лучше записать много, чем провести неполный анализ. Закончив список данных, можно приступить с его помощью к составлению списка функций. Для этого представляются функции процесса, использующие тот или иной класс (тип) или набор данных. Несколько различных типов данных может использоваться одной функцией.
Далее начинается процесс моделирования по методологии IDEF0. Конечным результатом этого процесса является набор взаимосогласованных описаний (диаграмм) — от описания самого верхнего уровня всей системы, представленного контекстной диаграммой, до подробного описания деталей или операций системы. /ДЕ/Ю-модель объединяет и организует диаграммы в иерархические структуры, в которых диаграммы верхних уровней менее детализированы, чем диаграммы нижних уровней.
Диаграммы IDEF0-модели оформляются стандартным образом на бланках. При последовательных приближениях в процессе создания IDÈF0-модели одна и та же диаграмма вместе с ее блоками и дугами может перечерчиваться несколько раз, что приводит к появлению ее различных вариантов. Для идентификации версий диаграмм в IDEFG используется схема контроля конфигурации диаграмм, основанная на хронологических номерах, или С-номерах.
Каждый блок диаграммы IDEE)-модели может быть детализирован на другой диаграмме. Поскольку каждый блок понимается как отдельный, полностью определенный объект, разделение такого объекта на его структурные части (блоки и дуги, составляющие диаграмму) называется декомпозицией. Декомпозиция формирует границы, и каждый блок в IDEE) рассматривается как формальная граница некоторой части описываемой системы, т.е. блок и касающиеся его дуги определяют точную границу диаграммы, представляющей декомпозицию этого блока. Эта диаграмма, называемая диаграммой-потомком, описывает все, связанное с этим блоком и его дугами, и не описывает ничего вне этой границы.
Декомпозируемый блок называется родительским блоком, а содержащая его диаграмма — соответственно родительской диаграммой. Таким образом, /1)£Я)-диаграмма является декомпозицией некоторого ограниченного объекта. Принцип ограничения объекта встречается на каждом уровне. Диаграмма, состоящая из одного блока и его дуг, определяет границу системы и называется контекстной диаграммой модели. Таким образом, этот блок изображает границу системы: все, лежащее внутри него, является частью описываемой системы, а все, лежащее вне его, образует среду системы.
IDEE) требует, чтобы все внешние дуги (ведущие к краю страницы) диаграммы были согласованы с дугами, образующими границу этой диаграммы, т.е. диаграмма должна быть «состыкована» со своей родительской диаграммой посредством согласования по числу и наименованию дуг.
Одним из важных моментов при проектировании ИС с помощью методологии IDEM) является точная согласованность типов связей между функциональными блоками. В методологии, например, можно выделить взаимосвязи типов: обратная связь по управлению, обратная связь по входу и выход-механизм. Обратные связи по управлению и входу представляют итерацию или рекурсию, а связи выход-механизм характерны при распределении источников ресурсов.
Поскольку дуги в IDEF0 обычно символизируют наборы объектов, они могут иметь множество начальных точек (источников) и конечных точек (приемников), поэтому дуги могут разветвляться и соединяться различными способами.
Разветвления дуг и их соединения — это синтаксис, позволяющий описывать декомпозицию содержимого дуг, т.е. разветвляющиеся и соединяющиеся дуги отражают иерархию объектов, представленных этими дугами.
Для каждого из элементов IDEF0-диаграмм, функциональных блоков, интерфейсных дуг — существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента.
Одна из наиболее частых проблем, возникающих в процессе моделирования, — определение момента завершения построения модели процесса. Рекомендуется прекращать моделирование, когда уровень детализации модели удовлетворяет ее цели.
Существуют некоторые критерии для определения момента завершения моделирования:
а) блок содержит достаточно деталей;
б) необходимо изменить уровень абстракции, чтобы достичь большей детализации блока;
в) необходимо изменить точку зрения, чтобы детализировать блок;
г) блок очень похож на другой блок той же модели;
д) блок очень похож на блок другой модели;
е) блок представляет тривиальную функцию.
Подводя итог приведенному краткому представлению методологии IDEFG, следует отметить, что она может служить единой методологической основой совершенствования управления системой. IDEM)-моделирование поддерживается, например, С45£-средствами BPWin и IDEFO/EM Tool.
Источник: finances.social
Описание функциональных блоков в стандарте IDEF0
Стандарт IDEF0 представляет совокупность методов, правил и процедур, предназначенных для построения функциональной модели, являющейся иерархически связанным структурным представлением действия (или множества действий) некоторого объекта, а также вещественных и информационных объектов (данных), необходимых для функционирования или являющихся результатом этого функционирования.
Функциональная модель бизнес-процессов состоит из диаграмм, фрагментов текста и глоссария, имеющих ссылки друг на друга. Диаграммы — главные компоненты модели, которые отображают последовательности взаимосвязанных через общие объекты функций (операций, действий, работ — activity) бизнес-процесса. Достоинство функциональной модели заключается в простоте графического представления, которое использует всего два конструктивных элемента:
— функциональный блок — описание функций, операций, действий, работ;
— интерфейсная дуга — линия, связывающая функциональные блоки и описывающая объекты (потоки объектов).
Функциональные блоки и интерфейсные дуги будут подробно рассмотрены позднее. Однако у вас может возникнуть вопрос: а почему, критикуя функциональный подход, мы должны рассматривать функциональное моделирование? Здесь под термином «функциональное моделирование» понимается моделирование процессов функционирования. А вот само функционирование должно строиться исходя из процессного подхода.
Методология IDEF0 основана на следующих концептуальных положениях:
Цели моделирования. Модель разрабатывается для понимания, анализа и принятия решений о реорганизации (реинжиниринге) или замене существующего либо проектировании нового БП. Модель описывает, что происходит в БП, как им управляют, какие сущности он преобразует, какие ресурсы использует и что производит, частями (элементами) БП могут быть любые комбинации разнообразных сущностей, включающие людей, информацию, программное обеспечение, оборудование, изделия, сырье или энергию (энергоносители).
Блочное моделирование и его графическое представление. Изучаемый БП представляется в виде набора взаимодействующих и взаимосвязанных блоков, отображающих работы, операции, действия. В IDEF0 работы, операции, действия, происходящие в БП и его элементах, принято называть функциями. Каждой функции ставится в соответствие блок.
На IDEF0-диаграмме, основном документе при анализе и проектировании БП, блок представляется прямоугольником. Интерфейсы, посредством которых блок взаимодействует с другими блоками или с внешним по отношению к моделируемому БП окружению, представляются стрелками, входящими в блок или выходящими из него.
Лаконичность и точность. Документация, описывающая БП, должна быть точной и лаконичной. Многословные характеристики, изложенные в форме традиционных текстов, неудобны. Графический язык позволяет лаконично, однозначно и точно показать все блоки БП и все отношения и связи между ними, выявить ошибочные, лишние или дублирующие связи.
Передача информации. Средства IDEF0 облегчают передачу информации от одного участника разработки модели (разработчика или рабочей группы) к другому. К числу таких средств относятся:
· диаграммы, основанные на простой графике блоков и стрелок, легко читаемые и понимаемые;
· метки на естественном языке для описания блоков и стрелок, а также глоссарий и сопроводительный текст для уточнения смысла элементов диаграммы;
· последовательная декомпозиция диаграмм, строящаяся по иерархическому принципу, при котором на верхнем уровне отображаются основные функции, а затем, на нижних уровнях, происходит их детализация и уточнение;
· древовидные схемы иерархии диаграмм и блоков, обеспечивающие обозримость модели в целом и всех входящих в нее деталей.
Строгость и формализм. Разработка моделей IDEF0 требует соблюдения ряда строгих формальных правил, обеспечивающих преимущества методологии в отношении однозначности, точности и целостности сложных многоуровневых моделей. Эти правила рассмотрим позднее. Здесь приводится только основное из них:
все стадии и этапы разработки и корректировки модели должны строго, формально документироваться для того, чтобы при ее эксплуатации не возникало вопросов, связанных с неполнотой или некорректностью документации.
Итерационное моделирование. Разработка модели в IDEF0 представляет собой пошаговую, итерационную процедуру. На каждом шаге итерации разработчик предлагает вариант модели, который подвергают обсуждению, рецензированию и последующему редактированию, после чего цикл повторяется. Такая организация работы способствует оптимальному использованию знаний системного аналитика, владеющего методологией и техникой IDEF0, и знаний специалистов — экспертов в предметной области, к которой относится объект моделирования.
Отделение «организации» от «функции». При разработке моделей следует избегать изначальной «привязки» функций исследуемой системы к существующей организационной структуре моделируемого объекта (организации, предприятия, фирмы, компании). Это помогает избежать субъективной точки зрения, навязанной организационной структурой и ее руководством. Организационная структура должна явиться результатом использования (применения) модели. Сравнение результата с существующей структурой позволяет, во-первых, оценить адекватность модели, а во-вторых, предложить решения, направленные на совершенствование этой структуры.
Компонентами синтаксиса IDEF0 являются:
блоки — представляют функции, определяемые как деятельность, процесс, операция, действие или преобразование;
стрелки — представляют данные или материальные объекты, связанные с функциями;
диаграммы — обеспечивают формат графического и словесного описания моделей.
Достоинство функциональной модели заключается в простоте графического представления, которое использует всего два конструктивных элемента: «блок» и «стрелки».
Семантика языка IDEF0 устанавливает правила отображения при помощи блоков и стрелок моделируемых функций, работ, операций, действий, и их интерфейсов.
Более подробно вопросы синтаксиса и семантики диаграмм IDEF0 будут рассмотрены в следующих темах (см. темы 7-9).
Итоги по теме
1. Сущность функционального подхода к моделированию бизнес-процессов сводится к построению схемы процесса в виде последовательности работ, на входе и выходе которых отражаются объекты различной природы (материальные и информационные объекты, используемые ресурсы, организационные единицы. ), необходимые для функционирования или являющиеся результатом функционирования.
2. Основными компонентами функционального моделирования являются диаграммы, содержащие графические элементы и текстовые описания.
3. Основными графическими компонентами функционального моделирования являются блоки, представляющие функции, и интерфейсные дуги, представляющие потоки объектов различной природы.
Описание функциональных блоков в стандарте IDEF0
Функциональный блок изображается в виде прямоугольника и представляет функцию или активную часть процесса, продуцирующую действие. Поэтому
названиями блоков должны быть глаголы в неопределенной форме с последующим дополнением,
например, «принять заказ», «определить потребность» и т.д. Название записывается внутри прямоугольника, поэтому должно быть кратким, но в то же время отражать суть процесса. Как правило, название дается по названию действия, обеспечивающего основной выходной результат процесса.
Блоки на диаграмме нумеруются. Номер проставляется в правом нижнем углу. Номера блоков используются для их идентификации на диаграмме и в соответствующем тексте. Пример графического изображения, обозначения и нумерации блока представлен на рис.11.
Синтаксические правила для функциональных блоков:
1. Блоки должны быть прямоугольниками с прямыми углами.
2. Размеры блоков должны быть достаточными для того, чтобы включать имя блока.
3. Имя блока должно отражать сущность процесса.
4. Блоки должны быть нарисованы сплошными линиями.
5. Цвета линий различных блоков могут быть различными.
Число блоков на одной диаграмме должно быть от двух до семи. Ограничение снизу выбрано из соображений здравого смысла для обеспечения информативности декомпозиции. Ограничение сверху определяется возможностями человеческого восприятия и поддерживает сложность диаграммы и модели на уровне, доступном для чтения, понимания и использования.
Блоки размещают на диаграмме в определенном порядке — по степени важности или по порядку очередности выполнения. Этот порядок называется доминированием.
Доминирование можно понимать как влияние, которое один блок оказывает на другие блоки диаграммы. Например, самым доминирующим блоком на диаграмме может быть либо первая из требуемой последовательности действий функция, либо планирующая или контролирующая функция.
Более доминирующие блоки размещаются выше и левее относительно менее доминирующих.
В результате получается ступенчатая схема, показывающая, какие функции оказывают большее влияние на остальные. Размещать блоки в произвольном порядке не рекомендуется. Тем более что и в жизни всегда можно выделить четкий порядок следования либо подчинения различных действий. Поэтому если блоки размещаются в порядке доминирования, то это один из критериев правильности их выделения.
Рекомендованный принцип размещения блоков в порядке доминирования представлен в таблице (таблица 3).
Каждый блок при необходимости может подвергаться декомпозиции, т.е. разделяться на составляющие действия. Декомпозиция порождает очередную диаграмму модели, которая детализирует родительский блок. У порождающего блока может быть только одна диаграмма декомпозиции.
Отметим, что в ходе разработки модели могут возникать различные альтернативные варианты декомпозиции. Такие варианты должны особым образом обозначаться (как правило, в виде префикса FEO (от первых букв английского выражения «For Exposition Only») к номеру диаграммы).
Связи блоков и детализирующих их диаграмм можно проследить по соответствующим номерам. Для нумерации диаграмм применяется правило наращивания номера. Пример нумерации дерева диаграмм, изображенного ранее (см. рис. 10), представлен на рис. 12.
Такой способ нумерации обеспечивает уникальность номеров блоков во всей модели. Допускается ставить точки между цифрами при наращивании номеров.
Каждая сторона функционального блока имеет определенное назначение (см. рис. 13):
— левая предназначена для входов;
— верхняя — для управления;
— правая — для выходов;
— нижняя — для механизмов (исполнителей).
Рис. 13. Спецификация сторон функциональных блоков в стандарте IDEF0
Такая спецификация отражает определенные системные принципы, принятые при построении диаграмм модели в стандарте IDEF0:
— входы преобразуются в выходы;
— управление предписывает или ограничивает условия выполнения преобразований. Управление в ходе выполнения БП, как правило, остается неизменным;
— механизмы (исполнители) показывают, кто или что выполняет преобразование. По завершении БП механизмы (исполнители) могут покидать (выводиться) из БП практически в неизменном состоянии.
Эти принципы могут быть записаны следующим образом:
в результате выполнения процесса, «вход» под воздействием «управления» преобразуется в «выход» посредством «механизма» (исполнителя).
И вот для того, чтобы четко выделить такую спецификацию сторон функциональных блоков, углы прямоугольников не должны закругляться!
Выходы одного блока могут быть входами, или управлениями, или механизмами (исполнителями) для других. Взаимосвязи блоков друг с Другом и с внешней средой отражаются интерфейсными дугами.
Итоги по теме
1.Функция или активная часть процесса изображается в виде Прямоугольника (блока).
2.Стороны блока имеют определенное назначение: вход, управление, выход, механизм.
3.На диаграмме блоки размещаются в порядке доминирования.
4.На одной диаграмме помещаются не менее двух и не более семи блоков.
Источник: poisk-ru.ru
Методологии моделирования предметной области
Процесс бизнес-моделирования может быть реализован в рамках различных методик, отличающихся прежде всего своим подходом к тому, что представляет собой моделируемая организация. В соответствии с различными представлениями об организации методики принято делить на объектные и функциональные (структурные).
Объектные методики рассматривают моделируемую организацию как набор взаимодействующих объектов – производственных единиц. Объект определяется как осязаемая реальность – предмет или явление, имеющие четко определяемое поведение. Целью применения данной методики является выделение объектов, составляющих организацию, и распределение между ними ответственностей за выполняемые действия.
Функциональные методики , наиболее известной из которых является методика IDEF , рассматривают организацию как набор функций , преобразующий поступающий поток информации в выходной поток. Процесс преобразования информации потребляет определенные ресурсы. Основное отличие от объектной методики заключается в четком отделении функций (методов обработки данных) от самих данных.
С точки зрения бизнес-моделирования каждый из представленных подходов обладает своими преимуществами. Объектный подход позволяет построить более устойчивую к изменениям систему, лучше соответствует существующим структурам организации . Функциональное моделирование хорошо показывает себя в тех случаях, когда организационная структура находится в процессе изменения или вообще слабо оформлена. Подход от выполняемых функций интуитивно лучше понимается исполнителями при получении от них информации об их текущей работе.
Функциональная методика IDEF0
Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT ( Structured Analysis and Design Technique ). Исторически IDEF0 как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing ). Семейство стандартов IDEF унаследовало свое обозначение от названия этой программы ( IDEF = Icam DEFinition), и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США ( NIST ).
Целью методики является построение функциональной схемы исследуемой системы, описывающей все необходимые процессы с точностью, достаточной для однозначного моделирования деятельности системы.
В основе методологии лежат четыре основных понятия: функциональный блок, интерфейсная дуга, декомпозиция, глоссарий.
Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, «производить услуги»). На диаграмме функциональный блок изображается прямоугольником (рис. 6.1). Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом:
- верхняя сторона имеет значение «Управление» (Control);
- левая сторона имеет значение «Вход» (Input);
- правая сторона имеет значение «Выход» (Output);
- нижняя сторона имеет значение «Механизм» ( Mechanism ).
Рис. 6.1. Функциональный блок
Интерфейсная дуга (Arrow) отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию , представленную данным функциональным блоком. Интерфейсные дуги часто называют потоками или стрелками.
С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Такими объектами могут быть элементы реального мира (детали, вагоны, сотрудники и т.д.) или потоки данных и информации (документы, данные, инструкции и т.д.).
В зависимости от того, к какой из сторон функционального блока подходит данная интерфейсная дуга, она носит название «входящей», «исходящей» или «управляющей».
Необходимо отметить, что любой функциональный блок по требованиям стандарта должен иметь, по крайней мере, одну управляющую интерфейсную дугу и одну исходящую. Это и понятно – каждый процесс должен происходить по каким-то правилам (отображаемым управляющей дугой) и должен выдавать некоторый результат (выходящая дуга), иначе его рассмотрение не имеет никакого смысла.
Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD ( Data Flow Diagram ) и WFD (Work Flow Diagram).
Декомпозиция ( Decomposition ) является основным понятием стандарта IDEF0 . Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции . При этом уровень детализации процесса определяется непосредственно разработчиком модели.
Декомпозиция позволяет постепенно и структурировано представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой.
Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0 — диаграмм, функциональных блоков, интерфейсных дуг — существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.
Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой.
В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).
Определение и формализация цели разработки IDEF0 -модели является крайне важным моментом. Фактически цель определяет соответствующие области в исследуемой системе, на которых необходимо фокусироваться в первую очередь.
Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему. Правильный выбор точки зрения существенно сокращает временные затраты на построение конечной модели.
Выделение подпроцессов . В процессе декомпозиции функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы , и называется дочерней (Child Diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме, соответственно называется дочерним блоком – Child Box).
В свою очередь, функциональный блок — предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. В каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок или исходящие из него, фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0 –модели.
Иногда отдельные интерфейсные дуги высшего уровня не имеет смысла продолжать рассматривать на диаграммах нижнего уровня, или наоборот — отдельные дуги нижнего отражать на диаграммах более высоких уровней – это будет только перегружать диаграммы и делать их сложными для восприятия. Для решения подобных задач в стандарте IDEF0 предусмотрено понятие туннелирования . Обозначение » туннеля » (Arrow Tunnel ) в виде двух круглых скобок вокруг начала интерфейсной дуги обозначает, что эта дуга не была унаследована от функционального родительского блока и появилась (из » туннеля «) только на этой диаграмме. В свою очередь, такое же обозначение вокруг конца (стрелки) интерфейсной дуги в непосредственной близи от блока–приемника означает тот факт, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Чаще всего бывает, что отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии, – в таком случае они сначала «погружаются в туннель «, а затем при необходимости «возвращаются из туннеля «.
Обычно IDEF0 -модели несут в себе сложную и концентрированную информацию, и для того, чтобы ограничить их перегруженность и сделать удобочитаемыми , в стандарте приняты соответствующие ограничения сложности.
Рекомендуется представлять на диаграмме от трех до шести функциональных блоков, при этом количество подходящих к одному функциональному блоку (выходящих из одного функционального блока) интерфейсных дуг предполагается не более четырех.
Стандарт IDEF0 содержит набор процедур, позволяющих разрабатывать и согласовывать модель большой группой людей, принадлежащих к разным областям деятельности моделируемой системы. Обычно процесс разработки является итеративным и состоит из следующих условных этапов:
- Создание модели группой специалистов, относящихся к различным сферам деятельности предприятия. Эта группа в терминах IDEF0 называется авторами (Authors). Построение первоначальной модели является динамическим процессом, в течение которого авторы опрашивают компетентных лиц о структуре различных процессов, создавая модели деятельности подразделений. При этом их интересуют ответы на следующие вопросы: Что поступает в подразделение «на входе»?
- Какие функции и в какой последовательности выполняются в рамках подразделения?
- Кто является ответственным за выполнение каждой из функций ?
- Чем руководствуется исполнитель при выполнении каждой из функций ?
- Что является результатом работы подразделения (на выходе)?
На основе имеющихся положений, документов и результатов опросов создается черновик (Model Draft) модели.
Наглядность графического языка IDEF0 делает модель вполне читаемой и для лиц, которые не принимали участия в проекте ее создания, а также эффективной для проведения показов и презентаций. В дальнейшем на базе построенной модели могут быть организованы новые проекты, нацеленные на производство изменений в модели.
Источник: intuit.ru
