Руководство по idef0

Аннотация

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

Оглавление

Содержание

“Одна картинка стоит тысячи слов.“

Народная мудрость

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

Несколько слов о преимуществах графики

Как известно, функциональные модели IDEF0 — это всегда графические схемы. У них есть свои особенности и правила составления. Об этом мы поговорим чуть-чуть позже. А сейчас я хотел бы привести пару примеров эффективности графики. Почему я делаю на этом акцент? Скорей всего, после моего утверждения о необходимости функциональной модели работы компании, очень многие подумали, что это все необязательно, можно и на словах пояснить как работает та или иная функция в компании. Вот об этом я и хочу поговорить.

И для начала сделаем небольшой экскурс в историю. Вернемся в далекий 1877 год, в период Русско-Турецкой войны. Именно тогда полиграфист Сытин впервые применил графику при описании военных действий. Сейчас для нас все это привычно, при описании любого сражения у каждого перед глазами возникают карты со стрелками, которые наглядно показывают ход сражения. А в те времена военные действия описывались словами. Для каждого боя — много-много слов. И понять в итоге, что же происходит, было очень сложно. А потому идея Сытина была поистине революционной — он начал печатать литографические копии карт с обозначением укреплений и расположений воинских частей. Назывались эти карты “Для читателей газет. Пособие”. Идея оказалась настолько актуальной, что первый же тираж “Пособий” разошелся мгновенно. И потом такие приложения были очень востребованы.

Причина очевидна. Графика помогала понять то, что при помощи одних слов разобрать было практически невозможно. Аналогичный пример беспомощности словесных описаний я могу привести также из своей практики. Один из моих заказчиков очень просил взяться за внедрение ERM-системы для его компании. На вопрос, есть ли у них какое-то техническое задание, я получил ответ: “Да, есть. Но в нем 400 страниц”. При этом клиент очень жаловался, что мои коллеги, к которым он обращался ранее, либо отказывались от проекта вообще, либо называли явно завышенные цены. После того, как я увидел, что в техническом задании действительно 400 страниц, и состоит оно исключительно из текстового описания, я понял причины поведения разработчиков. Прочитать такой объем текста, вникнуть в него, разобраться во всех нюансах только для того, чтобы понять задачу и назвать цену — это и правда очень сложно. Этому клиенту я предложил альтернативный вариант — описать все, что можно, графически в виде нотаций. Показал ему примеры моделирования. В итоге они сейчас переосмысливают свои пожелания и оформление технического задания. Знаю я также много других примеров, когда графическое моделирование бизнес-процессов помогало в работе как моим коллегам, бизнес-консультантам и разработчикам, так и самим бизнесменам

Почему это важно для моей работы

Моя работа всегда связана с внесением изменений в существующую систему. А для того, чтобы внести изменения и получить нужный результат, нужно изучить то, что существует уже сейчас. И не важно, что именно мы делаем – настраиваем или устанавливаем с нуля CRM-систему, создаем эффективную ERP-систему, занимаемся интеграцией различных систем для повышения автоматизации работы в целом. В любом случае, для начала, необходимо получить представление о существующей схеме работы, и только после этого можно предлагать какие-то изменения и продумывать варианты решения поставленной задачи.

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

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

Что такое нотация описания бизнес-процессов

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

IDEF0 — методология функционального моделирования (англ. function modeling) и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является ее акцент на соподчиненность объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временна́я последовательность (поток работ). Википедия

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

Функциональная модель компании

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

  • Входящие – вводные, которые ставят определенную задачу.
  • Исходящие – выводящие результат деятельности.
  • Управляющие (сверху вниз) – механизмы управления (положения, инструкции и пр).
  • Механизмы (снизу вверх) – что используется для того, чтобы произвести необходимую работу.

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

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

Для работы с ним существует множество инструментов, например, VISIO, BPWIN, ERWIN, Bussines studio и т.д. Кроме того, использование для создания бизнес-моделей IDEF0 — это не только удобно, это еще и правильно. Этот инструмент был разработан для бизнес-аналитики, он прошел длительную и тщательную отладку и шлифовку.

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

Есть вопросы по моделированию в IDEF0? Напишите нам или позвоните по телефону +7(495)320-50-40 и мы Вас проконсультируем.

Написать нам

Пример создания функциональной модели IDEF0

Для того чтобы понять, как работать с функциональным моделированием, я приведу пример процесса написания статьи. Основной блок – «Написать статью».

пример описания модели верхнего уровня

Входящие стрелки – «Опыт», «Информация из сторонних источников». Это те вводные, которые необходимы для начала работы. Управляющие для написания статьи – это «План публикации», «Требования издателя», «Правила русского языка».

А в роли «Механизмов» выступают автор, копирайтер, корректор и программное обеспечение. В данном случае автор создает аудиоматериал, в котором собирает все мысли и идеи, которые должны быть отражены в статье. Копирайтер – это человек, который создает на основе этого материала, руководствуясь требованиями издателя, планом публикации и правилами русского языка, готовый текст статьи.

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

Но это – только основные рамки процесса. Так описывается общая схема работы компании в целом. На самом деле, процесс создания статьи, как и любой бизнес-процесс можно и нужно детализировать. Для этого я декомпозирую общий блок «написать статью» на связанные между собой элементы. В нашем случае работа делится на 4 основных этапа:

  1. Подготовить аудио.
  2. Подготовить текст
  3. Подготовить текст к публикации.
  4. Разместить статью в издании.

IDEF0 A0

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

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

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

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

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

Как создавать нотации IDEF0

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

IDEF0

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

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

Она создается на основе первой и тех изменений, которые вы предлагаете внести в структуру работы для оптимизации и автоматизации работы компании в рамках выполнения поставленной задачи. Требования стандарта IDEF0 Базовые требования стандарта IDEF0, в принципе, я описал выше и показал на примере.

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

Сам стандарт IDEF0 описан разработчиками в документе перевод которого вы найдете в статье Перевод стандарта IDEF0 с английского на русский язык.

Точка зрения

2 основополагающих требования к модели.

В требованиях к диаграмме и построению модели в нотации IDEF0 есть требование, которое звучит так: любая диаграмма должна быть построена, исходя из точки зрения (Point of view) и цели (Scop). Именно этот вопрос, скажем так, один из основополагающих — точка зрения и цель. Соответственно, если мы хотим построить правильную диаграмму, нам необходимо выбирать правильно точку зрения. 

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

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

Второе определение:

Точка зрения определяет, что можно «увидеть „в контексте модели, с какой точки зрения или “под каким углом». В зависимости от поставленной цели могут быть приняты точки зрения, учитывающие различные аспекты объекта. На модель существует только одна точка зрения. 

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

Выбор точки зрения.

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

Первое правило: выбор места в иерархии.

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

Точка зрения: работник склада.

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

Точка зрения: руководитель склада.

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

Второе правило: выбор окружения

Отсюда же следует второй вопрос — что конкретно мы видим? Допустим, я работник склада, и я вижу то, что меня окружает: рабочее место, допустим, какой-то компьютер, доступ в какую-то систему учетную и ещё что-то в этом роде. И если я, описываю с точки зрения работника склада, работника приемки, назовём это так, то для меня эти все вещи будут важны.  

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

Соответственно, мы приходим ко второму правилу — это выбор окружения. То есть мы должны понимать, что нас окружает и выбирать из этого окружения, то, что мы будем учитывать в нашей модели.  Это второе правило.

Третье правило: приоритет.

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

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

Цель создания модели.

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

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

Цель создания модели это другими словами то для чего эта модель будет использована.

Типичные ошибки

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

Использование различных цветов

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

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

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

Слишком большое количество блоков

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

Читабельность при этом теряется. Оптимальный вариант – это детализация, достаточная для понимания вопроса, и не более того. Подробная детализация работы каждого подразделения или даже сотрудника может раскрываться при выборе подробного просмотра того или иного процесса. И создается такая структура только если это действительно нужно для работы или принятия решения.

Нарушение структуры при внесении корректировок

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

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

Правила названия управляющих элементов и блоков

Важно запомнить простое правило: управляющие стрелки называют именами существительными, блоки – глаголами. Так принято в стандарте IDEF0, и такой подход помогает избежать путаницы и ошибок. Чаще всего ошибки допускают при названии блоков. Например, вместо «Создать статью» пишут «Создание статьи». Блоки в данном подходе – это действия, а потому они должны быть всегда глаголами.

Выгоды использования IDEF0

  • Самая первая выгода очевидна – это наглядность. Вы сами начинаете понимать, как работает та или иная система, и можете также наглядно пояснить, где в этой системе «тонкие места» и как ваши решения помогут избавиться от них.
  • Взаимопонимание и отсутствие разночтений. При обсуждении работы компании с использованием функциональной модели у вас имеются наглядные и понятные интуитивно блоки задач с управляющими элементами. Кроме того, функциональное моделирование предполагает создание в случае необходимости глоссария, в котором раскрываются условные обозначения и термины. В результате вы с клиентом, руководителем, другими сотрудниками при обсуждении проблемы говорите на одном языке.
  • Простота и высокая скорость создания модели. Конечно, научиться моделированию не так просто, как кажется. Ведь схема — это, по сути, сверхплотная подача информации, что очень хорошо для понимания, но для реализации такой подачи требуется особый подход. Мозг аналитика выступает в данном случае как очень мощный пресс с одной стороны, и фильтр – с другой. Но с опытом этот процесс становится очень быстрым. В результате вы получаете инструмент, который поможет и самому разобраться, что же происходит в той или иной системе, и при помощи созданного в сжатые сроки наглядного пособия проиллюстрировать важные моменты коллегам или заказчикам.
  • Дисциплина и отсутствие ошибок. Стандарт IDEF0 предполагает строгие рамки и правила. Такой подход дисциплинирует, а привычка действовать в рамках стандарта помогает избежать ошибок по невнимательности. Любые нарушения стандарта становятся сразу заметны.

В чем трудность применения IDEF0

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

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

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

Как правильно называются стрелки в IDEF0

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

Сразу уточню, что в Рунете часто можно увидеть неправильные названия, которые приводят к путанице. 

Основные стрелки в IDEF0:

  • Input
  • Control
  • Output
  • Mechanism

Вместе этот тип элементов называют ICOM, т.е. это сокращение от названий всех типов стрелок. Именно так постоянно пишут в самом стандарте. Потому, когда вы видите упоминание ICOM, просто помните, что это значит — «Input, Control, Output, Mechanism».

Как это переводится?

  • Input — Ввод
  • Control — Контроль
  • Output — Вывод
  • Mechanism — Механизм

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

Input и Output

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

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

Но это неправильно. Input – это не Вход, а Ввод. И точно такая же ситуация со стрелкой Output, которую часто ошибочно переводят как «Выход».

 Дело в том, что мы описываем функциональную модель, и наши стрелки граничат с блоком функции (F). И, соответственно, мы должны сконцентрироваться на том, что после ее выполнения мы должны что-то получить и вывести. А для того, чтобы что-то вывести, нужно для начала что-то ввести. 

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

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

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

Кроме того, перевод Input – Ввод, а Output – Вывод, наиболее точен. Именно так эти слова переводятся с английского языка.

Control и Mechanism

Далее, ошибки в переводе слова Control также постоянно повторяются, и они столь же некорректны. Часто Control переводят как «Управление». И это неправильно.

Если мы говорим об управлении, то подразумеваем, что есть какая-то воля, что мы напрямую чем-то управляем и принимаем решения. Но если мы занимаемся функциональным анализом предприятия, то управлением здесь занимаются люди. А потому именно об управлении стоит говорить, когда вы применяете стрелки Mechanism, т.к. именно люди в данном случае – те самые инструменты, которые задействованы в вопросах управления. Именно люди занимаются тем, чтобы из ввода получить вывод.

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

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

Таким образом, контроль – это то, на что мы ориентируемся, что нами руководит, а не те решения, которые мы принимаем в процессе работы.

Если в качестве «Механизма» выступает компьютерная программа, то контроль уже заложен в ее коде. И при написании этого кода в том числе используются инструкции, правила и другие документы.

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

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

Как видите, все просто. Если вы правильно переводите термины, а именно:

  • Input — Ввод
  • Control — Контроль
  • Output — Вывод
  • Mechanism — Механизм

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

Модель работы швейного предприятия

В этом случае компания собиралась внедрять 1С. Управление производственным предприятием, и также нужно было навести порядок, чтобы каким-то образом стандартизировать и автоматизировать работу.

Цель

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

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

Описание

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

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

Я создал модель, разделил все этапы работы на функции. Далее каждую из них мы с клиентами рассматривали с точки зрения процессов и возможности автоматизации. Например, выбиралась функция «Проектирование производства», и для нее выполнялась автоматизация.

Описание работы швейной фабрики A-0
Описание работы швейной фабрики A0

Критика

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

  1. Мы видим 7 блоков. IDEF0 по стандарту требует максимум 6 блоков.
  2. В диаграмме используются такие фразы, как «исследование рынка», «проектирование». Это также ошибки. Если вы ознакомитесь с моим переводом стандарта IDEF0 на сайте Хабр, то там описывается, что функции должны называться глаголом в совершенной форме, т.е. давать ответ на вопрос «что необходимо сделать». В данном случае вместо «Исследование рынка» правильно написать «Исследовать рынок. Не «Проектирование продукции», а «Спроектировать продукцию». Не «Проектирование производства», а «Спроектировать производство» и т.д. Есть и другие ошибки в названиях. Например, при декомпозиции хорошо видно название «Производство и реализация швейных изделий». Здесь не должны объединяться два разных действия союзом «И». Должно быть либо производство, либо реализация, точнее – «произвести» или «реализовать», так как по правилам нотации не должно быть союза «и», каждый блок описывается фразой с одним глаголом, который выражает функцию.

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

Вывод: формально диаграмма неправильная, с точки зрения достижения цели – правильная.

Ещё пример моделирования в IDEF0

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

УФМТП. Универсальная функциональная модель торгового предприятия в нотации IDEF0

Бизнес-консультант с большим практическим опытом работы в России и ближайшем зарубежье. Автор
многочисленных публикаций и нескольких книг по оптимизации и автоматизации бизнеса. Живу и работаю в
Москве, руководитель компании Trinion. Делюсь опытом посредством блога на сайте trinion.org

Источник

Управление разработкой, IT-стандарты, Терминология IT

Рекомендация: подборка платных и бесплатных курсов PR-менеджеров — https://katalog-kursov.ru/

Предисловие

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

Ф. Бэкон

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

Если вы начнете свое знакомство с IDEF0, то первое, с чем вы обязательно столкнетесь, будет государственный стандарт Р 50.1.028-2001.Кроме того, вы будете встречать различные компиляции, т.е. краткие варианты документации, выжимки главного с точки зрения авторов, обзоры на этот стандарт от поставщиков ПО и различных консалтинговых компаний.

Я также публиковал в свое время обзор IDEF0, и в нем сам сделал одну концептуальную ошибку. На нее я обязательно укажу немного позже.

Ситуация с русскоязычными описаниями IDEF0. В том числе с Р 50.1.028-2001

Переводов и обзоров в Рунете много, информация в них во многом повторяется, при этом также повторяются из публикации в публикацию одни и те же ошибки. Кроме того, не существует полноценного перевода стандарта. Т.е. стандарт IDEF0 есть, множество обзоров его в Рунете существует, а самого перевода до сих пор нет.

Почему сложилась такая ситуация? Я считаю, что большинство авторов обзоров при изучении стандарта опирались на уже существующие публикации, а не англоязычный оригинал. Кроме того, на появление все новых публикаций оказал свое влияние, так называемый «рекламный шум». Люди и компании делали публикации не для того, чтобы поделиться чем-то новым и полезным, а для достижения совсем других целей. Кто-то так подтверждал свою компетентность в глазах потенциальных клиентов, кто-то переписывал чужие публикации исключительно ради сео-продвижения в поисковиках, и, как следствие, привлечения потенциальных клиентов на курсы и т.д. В результате возникла ситуация, при которой в Рунете при описании IDEF0 повторяются ошибки и множатся неточности.

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

Зачем мне это надо?

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

Важные особенности моего перевода

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

§

Стрелки

Стрелки в нотации IDEF0 могут быть нескольких типов:

  1. Input (Ввод)
  2. Output ( Вывод)
  3. Control (Контроль)
  4. Mechanism (Механизм)
  5. Call (Вызов)

Эти названия приводят практически в любом обзоре, и уже традиционно их переводят следующим образом:

  1. Input — Входящие
  2. Output — Исходящие
  3. Control – Управление (как это ни странно).
  4. Mechanism – Механизм.

Из всех четырех названий, на самом деле, правильное только одно – Механизм. Про Вызов многие и не пишут.

На самом деле, Input – это не «входящие», правильный перевод слова «ввод», т.е. это стрелка ввода или, если использовать прилагательные, вводящая стрелка. Почему это важно? Если мы с концептуальной точки зрения говорим о входящем, это значит, что у нас что-то входит. Т.е. где-то есть вход, кто-то или что-то туда входит, есть момент, когда этот кто-то или что-то находится перед входом, а потом – после входа и далее все, что с этим связано. А если мы говорим слово «ввод», подразумевается, что мы должны что-то ввести. В результате мы концентрируемся не на том, что мы входим куда-то, не на поиске входа, а на том, что именно нужно ввести.

Самый простой пример использования слова Input – это клавиатура и мышка, устройства ввода информации. Никто не называет их устройствами входящей информации или еще как-то. И мы понимаем, почему это устройства ввода, ведь с их помощью мы вводим информацию, а не входим куда-то. И сами мышка и клавиатура также никуда не входят, а только служат устройствами для ввода.

Аналогично и стрелки в IDEF0, они никуда не входят. С их помощью мы вводим в функцию данные и/или объекты. Схожая ошибка заключается в переводе Output. Стрелка никуда не исходит, она, как устройство вывода, выводит определенный результат (материальный или информацию). И здесь также мы должны концентрироваться на вопросе, что мы выводим, а не интересоваться, где выход, или изучать моменты до и после выхода. Т.е. вывод – это слово правильное и точное.

Следующая ошибка – перевод названия стрелки Control, которую почему-то все называют управляющей или стрелкой управления. Я предполагаю, что это просто ошибка, которую, кстати, я тоже в своем первом обзоре IDEF0, допустил. Но даже тогда, когда я использовал название из прочитанных ранее публикаций, у меня в голове не складывалось, почему это управление? Управление – это слишком общее и неточное понятие. Кстати, именно этот вопрос стал для меня первым шагом к изучению англоязычной документации. И тогда все стало на свои места. 

Слово Control переводится как контроль. И стрелки Control – это то, что контролирует, что ограничивает функцию. 

Говорить стрелки управления – неправильно. Ведь они на самом деле ничем не управляют. Управляет чем-то обычно человек, иногда – механизм, в животном мире – вожак стаи. Но всегда это кто-то или что-то. А если мы говорим о контроле, речь идет об ограничениях. Т.е. стрелки Control показывают, какие ограничения у нас есть (это становится понятно из текста самого стандарта).

Например, для функции «создать программу» у нас может выступать в качестве ограничения требования к скорости работы. При этом скорость работы назвать управлением несколько нелепо. Этот параметр ничем не управляет, но ограничивает наш выбор.

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

Количество блоков

Практически во всех русскоязычных обзорах IDEF0 пишут (и я сам делал эту ошибку), что блоков должно быть 7 штук. В стандарте четко указано, что диаграмма может содержать от 3 до 6 блоков. Таким образом, компиляции нас не просто дезинформируют, но вынуждают нарушать требования стандарта.

Есть множество таких ньюансов, но я не стану заострять на них внимание.

Нескорые картинки не переведены, переведу позднее.

Приятного чтения!

Перевод стандарта IDEF0.

Федеральный стандарт
по обработке информации
Публикация 183

21 Декабря 1993

Объявление стандарта

МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГО
МОДЕЛИРОВАНИЯ (IDEF0)

Федеральные стандарты обработки информации (FIPS PUBS) публикуются Национальным институтом стандартов и технологий после утверждения министром торговли в соответствии с разделом 111 (d) Закона о федеральной собственности и административных услугах 1949 года с поправками, внесенными Законом о компьютерной безопасности 1987 года, Публичный закон 100-235.

1. Название стандарта. Методология функционального моделирования (IDEF0).

2. Категория стандарта. Стандарт программного обеспечения, методы моделирования.

3. Пояснение.

Данная публикация объявляет о принятии Методологии функционального моделирования (IDEF0) в качестве Федерального стандарта обработки информации (FIPS). Настоящий стандарт основан на программе интегрированной компьютеризации производства научно-исследовательских лабораторий ВВС Райт (ICAM), Часть II, том IV Руководство по функциональному моделированию (IDEF0), Июнь 1981 года.

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

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

4. Утверждающий орган. Министр торговли.

5. Агентство по техническому обслуживанию.

6. Другие документы
     a. Архитектура ICAM, Часть II-том IV Руководство по функциональному моделированию (IDEF0), AFWAL-TR-81-4023, Лаборатория материалов, Авиационные лаборатории ВВС Райт, Командование ВВС, База ВВС Райт-Паттерсон, Огайо 45433, июнь 1981 г.

7. Сопутствующая документация
    a. Федеральные правила управления информационными ресурсами, подраздел 201.20.303 «Стандарты» и подраздел 201.39.1002 «Федеральные стандарты».
    b. Интегрированная система информационной поддержки (IISS), том V Подсистема общей модели данных, Часть 4 Руководство по информационному моделированию Idef1 Дополненное, декабрь 1985 г.
    c. Архитектура ICAM, часть II, том V Руководство по информационному моделированию (IDEF1), AFWAL-TR-81-4023, Лаборатория материалов, Авиационные лаборатории ВВС Райт, Командование ВВС, База ВВС Райт-Паттерсон, Огайо 45433, июнь 1981 г.
    d. Управление конфигурацией ICAM, том II Стандарты документации ICAM при разработке систем (SDM), AFWAL-TR-82-4157, Командование ВВС, Авиабаза Райт-Паттерсон, Огайо 45433, октябрь 1983 г.

8. Цели. Основными целями настоящего стандарта являются:
    a. Предоставить средства для полного и последовательного моделирования функций (действий, поведения, процессов, операций), требуемых системой или предприятием, а также функциональных связей и данных (информации или объектов), поддерживающих интеграцию этих функций;
     b. Предоставить методику моделирования, не зависящую от методов или инструментов компьютерной программной инженерии (CASE), но которая может быть использована в сочетании с этими методами или инструментами;
     c. Предоставить методику моделирования, обладающую следующими характеристиками:
         — Универсальность (для анализа систем различного назначения, сферы применения и сложности);
         — Определенность и точность (для производства требуемых, пригодных для использования моделей);
         — Краткость и лаконичность (для облегчения понимания, информационного обмена, согласования и проверки);
         — Концептуальность (для представления функциональных требований, а не физических или организационных вариантов);
         — Гибкость (поддержка нескольких этапов жизненного цикла проекта).

9. Применение
Использование данного стандарта настоятельно рекомендуется если в ходе реализации проектов требуется:
     a. применение методики моделирования для анализа, разработки, реинжиниринга, интеграции или приобретения информационных систем;
     b. включение метода системного или корпоративного моделирования в методологию анализа бизнес-процессов или разработки программного обеспечения.
Спецификации настоящего стандарта применяются в тех случаях, когда методы системного или корпоративного моделирования используются:
    a. в проектах, требующих IDEF0 в качестве метода моделирования;
    b. при разработке автоматизированных программных средств, реализующих методику моделирования IDEF0.

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

10. Технические характеристики

Настоящий стандарт принимает Методологию функционального моделирования (IDEF0) в качестве Федерального стандарта обработки информации (FIPS).

11. Реализация.

Реализация стандарта включает в себя два момента: приобретение разработки и интерпретация стандарта.

11.1 Приобретение пакета IDEF0.

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

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

11.2 Интерпретация настоящего Федерального стандарта обработки информации (FIPS).

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

Директору Лаборатории компьютерных систем
ВНИМАНИЕ: интерпретация FIPS IDEF0
Национальный институт по стандартизации и технологии
Гейтерсбург, Мэриленд 20899

12 Отказ от выполнения требований Стандарта.

При определенных исключительных обстоятельствах руководители федеральных ведомств и агенств могут утверждать отказы от федеральных стандартов обработки информации (FIPS).
Руководители таких учреждений могут передавать данные полномочия только старшему должностному лицу, назначенному в соответствии с разделом 3506 (b) раздела 44 Кодекса Соединенных Штатов. Запросы об отказе удовлетворяются только в том случае, если:

        a. Применение стандарта отрицательно скажется на выполнении задачи оператора Федеральной вычислительной системы

        b. Соблюдение стандарта может привести к серьезным неблагоприятным финансовым последствиям для оператора, которые не будут компенсированы за счет Государственного бюджета.

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

Директору Лаборатории компьютерных систем
ВНИМАНИЕ: интерпретация FIPS IDEF0
Национальный институт по стандартизации и технологии
Гейтерсбург, Мэриленд 20899

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

Если определение об отказе применяется к закупке оборудования и / или осуществлению услуг, уведомление о решении выдать отказе должно быть опубликовано в Commerce Business Daily как часть уведомления о предложении и приобретении или, если отказ принимается после публикации этого уведомления путем внесения изменений в такое уведомление. Копия запроса об отказе, любые подтверждающие документы, документ, подтверждающий запрос об отказе, а также подтверждающие и сопроводительные документы с исключениями, которые агентство уполномочено решает оформляются в соответствии с пунктом 5 раздела 552 (b) U. S. C. и являются частью закупочной документации и хранятся агентством.

13. Где можно приобрести данный стандарт.

Экземпляры этой публикации продаются Национальной службой технической информации Министерства торговли США, Спрингфилд, Вирджиния 22161. При оформлении заказа укажите Публикацию 183 «Федеральный стандарт обработки информации (FIPSPUB 183) и название. Оплата может быть произведена чеком, денежным переводом или депозитным счетом.

Вступление:

В информативном введении рассматриваются предыстория и принцип IDEF0 (произносится как Idef zero). Это помогает читателю ориентироваться в содержании документа и быстрее понять требования нормативных разделов.

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

Предыстория:

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

В ходе реализации программы ICAM был разработан ряд методов, известных как методы IDEF (iCAM Definition), которые включали в себя следующее:

  1. Метод IDEF0, используется для создания „функциональной модели“. Функциональная модель это структурированное представление функций, действий или процессов в моделируемой системе или объекте.
  2. Метод IDEF1, используется для создания „информационной модели“. Информационная модель представляет собой структуру и семантику информации внутри моделируемой системы или объекта.
  3. Метод IDEF2, используется для создания „динамической модели“. Динамическая модель представляет собой изменяющиеся во времени поведенческие характеристики моделируемой системы или объекта.

В 1983 году программа Интегрированной системы информационной поддержки ВВС США усовершенствовала методологию моделирования информации IDEF1, сформировав методологию семантического моделирования данных IDEF1X (расширенный IDEF1).

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

В 1991 году Национальный институт стандартизации и технологии (NIST) получил поддержку от Министерства обороны США, Департамента корпоративного управления информацией (DoD/CIM) для разработки одного или нескольких Федеральных стандартов обработки информации (FIPS)Ю определяющих методологии моделирования. Для функционального моделирования определена методология IDEF0, а для информационного моделирования IDEF1X. Документы FIPS базируются на руководствах IDEF, опубликованных ВВС США в начале 1980-х годов.

Подход IDEF0

Методология IDEF0 основана на подходе, разработанном Дугласом Т. Россом в начале 70– х годов и получившем название SADT (Structured Analysis & Design Technique метод структурного анализа и проектирования). В своем первоначальном виде IDEF0 включал в себя как определение языка графического моделирования (синтаксис и семантика), так и описание комплексной методологии разработки моделей.

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

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

Как язык функционального моделирования, IDEF0 имеет следующие характеристики:

  1. Является всеобъемлющим и выразительным методом, способным графически представлять широкий спектр деловых, производственных и других видов деятельности предприятия на любом уровне детализации.
  2. Это последовательный и простой язык, обеспечивающий строгое и точное выражение и способствующий согласованности использования и интерпретации.
  3. Улучшает обмен информацией между системными аналитиками, разработчиками и пользователями за счет простоты обучения и делает упор на иерархическую детализацию.
  4. Хорошо испытан и проверена в ходе многолетнего использования в Военно-воздушных силах и других правительственных проектах, а также в частном промышленном секторе.
  5. Она может быть создана с помощью различных инструментов компьютерной графики; многочисленные коммерческие продукты специально поддерживают разработку и анализ диаграмм и моделей IDEF0.

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

СОДЕРЖАНИЕ

  1. Общие сведения
    1. Область применения
    2. ЦЕЛЬ
  2. Определения
  3. Модели IDEF0
    1. Концепции моделей
    2. Синтаксис и семантика
      1. Синтаксис
        1. Блоки
        2. Стрелки
        3. Синтаксические правила
      2. Семантика
        1. Семантика блоков и стрелок.
        2. Имена и метки
        3. Семантические правила блоков и стрелок.
    3. Диаграммы IDEF0
      1. Типы диаграмм
        1. Контекстная диаграмма верхнего уровня
        2. Дочерняя диаграмма
        3. Родительская диаграмма
        4. Текст и глоссарий
        5. Диаграммы-иллюстрации
      2. Свойства диаграмм
        1. Стрелки как ограничения
        2. Активации блока
        3. Параллельное функционирование
        4. Стрелки как трубы
        5. Ветвление стрелок
        6. Межблочные соединения
        7. Граничные стрелки
        8. ICOM кодирование граничных стрелок
        9. Стрелки туннелирования
        10. Стрелка вызова
      3. Правила построения диаграмм
      4. Ссылочные выражения (коды)
        1. Номера блоков
        2. Номера ноды
          1. Перечень нод
          2. Дерево нод
        3. Ссылки на ноды
        4. Примечания к модели
        5. Справочная запись
    4. Модели
      1. Описание модели IDEF0
      2. Контекстные диаграммы
      3. Контекстные диаграммы высокого уровня
      4. FEO, текст и глоссарий
      5. Название модели
      6. Правила презентации

ПРИЛОЖЕНИЕ А-КОНЦЕПЦИИ IDEF0

A. 1 Предыстория

A. 2 Концепции IDEF0

A. 3 Обсуждение отдельных концепций IDEF0

A. 3.1 Графика моделирования деятельности

A. 3.2 Обмен информацией путем последовательного введения деталей

A. 3.3Дисциплинированная командная работа

ПРИЛОЖЕНИЕ В ПОСТРОЕНИЕ И ИНТЕРПРЕТАЦИЯ ДИАГРАММ IDEF0

B. 1 Чтение диаграмм IDEF0

B. 1.1 Подход к разработке модели

B. 1.2 Порядок чтения диаграммы

B. 1.3 Семантика блоков и стрелок

B.1.3.1 Ограничения не учитываются как и когда

B.1.3.2 Несколько вводов, сигналов контроля и выводов

B. 2 Руководство разработчика по созданию диаграмм IDEF0

B. 2.1 Основные шаги разработчика

B.2.1.1 Выбор контекста, точки зрения и цели

B.2.1.2 Создание контекстной диаграммы

B.2.1.3 Создание высшей диаграммы

B.2.1.4 Создание дочерних диаграмм

B.2.1.5 Создание вспомогательного материала

B.2.1.6 Выбор блока для детализации

B.2.1.7 Деятельность разработчика

B.2.1.7.1 Этап сбора данных

B.2.1.7.2 Этап структурирования

B.2.1.7.3 Этап презентации

B.2.1.7.4 Этап взаимодействия

В.2.2 Черчение диаграмм IDEF0

В.2.2.1 Генерирование функциональных блоков

В.2.2.1 Генерирование функциональных блоков

B.2.2.3 Уровень усилий

В.2.3 Повторное построение диаграмм IDEF0

B.2.3.1 Модифицирующие блоки

B.2.3.2 Связывание (объединение) стрелок

B.2.3.3 Предложение о внесении изменений в контекст

B.2.3.4 Синтаксис ICOM для подключения диаграмм

B.2.4 Графический макет

B.2.4.1 Ограничения на диаграмме

B.2.4.2 Размещение стрелок

B.2.4.3 Макет стрелки

B.2.5 Написание текста

B.2.5.1 Текст и глоссарий

B.2.5.2 Примечания и ссылки

B.3 Сбор данных для моделирования IDEF

B.3.1 Введение

В.3.2 Процесс опроса

Б.3.3 Комплекта опроса

ПРИЛОЖЕНИЕ С-ПРОЦЕДУРЫ И ФОРМЫ ЦИКЛА ОБЗОРА

C.1 IDEF Дисциплина командной работы

C.2 Цикл Комплекта IDEF

C.2.1 Роли персонала

C.2.1.1 Разработчик (Автор)

C.2.1.2 Комментатор

C.2.2.1 Руководство для читателей

C.2.2.2 Взаимодействие разработчика с комментатором

C.2.2.3 Рекомендации по проведению совещаний

C.3 Комплекты IDEF

C.3.1 Заполнение Титульного листа Комплекта

C.3.2 Подготовка стандартного Комплекта

C.4 Стандартная форма диаграммы

C.4.1 Рабочая информация

C.4.1.1 Поля „Разработчик / Дата / Проект”

C.4.1.2 Поле “Примечания читателя»

C.4.1.3 Поле «Статус»

С.4.1.4 Поле Читатель/Дата

С.4.1.4 Поле Читатель/Дата

C.4.1.6 Поле «Используется В» (“Used At”)

C.4.2 Поле » Сообщение” (“Message” )

C.4.3 Поле «Нода» (“Node” )

C.4.4 Поле «Название» (“Title” )

С.4.5 Поле «Номер» (“Number”)

C.4.5.1 Поле «Номер» (Большая область)

C.4.5.2 Поле » Номер” ( “Number” )(«Номер страницы Комплекта» Малая прямоугольная Область)

C.5 Хранение файлов

C.6 Процедура обзора модели IDEF

Приложение D Информативные определения

1. Общие сведения

1.1 Область применения

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

Данный документ содержит три нормативных раздела, Разделы 1, 2 и 3, которые определяют язык, поддерживающий моделирование IDEF0. Раздел 1, содержит обзор документа. Раздел 2 определяет ключевые термины, используемые в нормативных разделах. Раздел 3 определяет синтаксис и семантику языка.

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

Данный стандарт распространяется на IDEF0 (Руководство по методологии функционального моделирования), разработанный по Программе интегрированной компьютеризации производства ВВС США (ICAM), Июнь 1981 года и с тех пор широко применяется многими пользователями IDEF.

1.2 ЦЕЛЬ

Основными целями настоящего стандарта являются:

  1. Документировать и уточнять методологию моделирования IDEF0 и как правильно ее использовать;
  2. Обеспечить средства для полного и последовательного моделирования функций, требуемых системой или объектом, а также данных и объектов, которые связывают эти функции;
  3. Предоставить методику моделирования, не зависящую от методов или инструментов компьютерной программной инженерии (CASE), но которая может быть использована в сочетании с этими методами или инструментами;
  4. Предоставить язык моделирования, обладающий следующими характеристиками:

    a)Универсальность (для анализа систем и объектов различного назначения, объема и сложности);

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

    c)Краткость и лаконичность (для облегчения понимания, информационного обмена, согласования и проверки);

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

    d)Гибкость (поддержка нескольких этапов жизненного цикла проекта).

2. Определения

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

2.1 Диаграмма A-0: специальный вид однокомпонентной (контекстной) диаграммы IDEF0, состоящей из одного блока, описывающего функцию верхнего уровня, ее вводы, выводы, контроля, и механизмы, вместе с формулировками цели модели и точки зрения, с которой строится модель.

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

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

2.4 Сегмент стрелки:сегмент линии, который начинается или заканчивается на стороне блока, в точке ветвления или слияния, или на границе (несвязанный конец стрелки)

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

2.6 Блок:прямоугольник, содержащий имя и номер и используемый для описания функции.

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

2.8 Номер блока: число (0 6), помещаемое в правом нижнем углу блока и однозначно идентифицирующее блок на диаграмме.

2.9 Ветвление: Соединение или разделение двух или большего числа сегментов стрелок.

2.10 Связывание/развязывание: Объединение значений стрелок в составное значение (связывание в «пучок»), или разделение значений стрелок (развязывание «пучка»), выраженные синтаксисом слияния или ветвления

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

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

2.13 Дочерний блок: блок на дочерней (порожденной) диаграмме.

2.14 Дочерняя диаграмма: диаграмма, детализирующая родительский (порождающий) блок.

2.15 Контекст: окружающая среда, в которой действует функция (или набор функций на диаграмме).

2.16 Контекстная диаграмма: диаграмма, имеющая узловой номер A-n ( n ? 0 ), которая представляет контекст модели. Диаграмма A-0, состоящая из одного блока, является необходимой (обязательной) контекстной диаграммой; диаграммы с узловыми номерами A-1, A-2,… дополнительные контекстные диаграммы.

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

2.18 Декомпозиция: разделение моделируемой функции на функции компоненты.

2.19 Ссылочное выражение (DRE): Ссылка (например, номер ноды, C-номер, номер страницы), написанная под нижним правым углом блока IDEF0, чтобы показать, что она детализирована и какая диаграмма ее детализирует.

2.20 Диаграмма: часть модели IDEF0, описывающая декомпозицию блока.

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

2.22 Диаграмма-иллюстрация (FEO): Графическое описание, используемое, для сообщения специфических фактов о диаграмме IDEF0. При построении диаграмм FEO можно не придерживаться правила IDEF0. В отличие от графической диаграммы IDEF0, диаграмма FEO может не соответствовать правилам IDEF0.

2.23 Разветвление: Соединение, на котором сегмент стрелки IDEF0 (идущий от источника к пользователю) делится на два или более сегментов стрелки. Может означать «развязывание пучка»

2.24 Функция: действие, процесс или преобразование (моделируемые блоком IDEF0), идентифицируемое глаголом или глагольной формой, которая описывает, что должно быть выполнено.

2.25 Имя функции: то же, что и имя блока

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

2.27 Код ICOM: Аббревиатура (Input Ввод, Control Управление, Output Вывод, Mechanism – Механизм), код, обеспечивающий соответствие граничных стрелок дочерней диаграммы со стрелками родительского блока; используется для ссылок..

2.28 Модель IDEF0: Графическое описание системы, разработанное с определенной целью (см. 3.46) и с выбранной точки зрения. Комплект одной или более диаграмм IDEF0, которые изображают функции системы с помощью графики, текста и глоссария.

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

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

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

2.32 Соединение: Соединение, на котором сегмент стрелки IDEF0 (идущий от источника к потребителю) сливается с одним или несколькими другими сегментами стрелки, образуя единый сегмент стрелки. Может обозначать связывание значений сегмента стрелки.

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

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

2.35 Нода: Блок, порождающий дочерние блоки; родительский блок. (См.: перечень нод, дерево нод, номер ноды, ссылка ноды, номер ноды диаграммы).

2.36 Перечень нод: список, часто ступенчатый, показывающий ноды модели IDEF0 в упорядоченном виде. Имеет то же значение и содержание, что и дерево нод.

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

2.38 Ссылка ноды: Код, присвоенный диаграмме, для ее идентификации и определения положения в иерархии модели; формируется из сокращенного имени модели и номера ноды диаграммы с дополнительными расширениями.

2.39 Дерево нод: Представление отношений между родительскими и дочерними нодами модели IDEF0 в форме древовидного графа. Имеет то же значение и содержание, что и перечень нод.

2.40 Выводящая стрелка: Класс стрелок, которые отображают вывод IDEF0блока, то есть данные или материальные объекты, произведенные функцией. Выводящие стрелки связываются с правой стороной блока IDEF0.

2.41 Родительский блок: блок, который подробно описывается дочерней диаграммой.

2.42 Родительская диаграмма: диаграмма, которая содержит родительский блок.

2.43 Цель: краткая формулировка причины создания модели.

2.44 Семантика: Значение синтаксических компонентов языка.

2.45 Тильда: Небольшая ломаная (волнистая) линия, используемая для соединения метки с конкретным сегментом стрелки или примечания модели с компонентом диаграммы.

2.46 Синтаксис: Структурные компоненты или характеристики языка и правила, которые определяют отношения между ними.

2.47 Текст: Любой текстовый (не графический) комментарий к графической диаграмме IDEF0.

2.48 Название: глагол или глагольный оборот, описывающий общую функцию, представленную на диаграмме IDEF0; название дочерней диаграммы соответствует имени ее родительского блока.

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

2.50 Точка зрения: Краткое изложение перспективы модели.

3. Модели IDEF0

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

3.1 Концепции моделей

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

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

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

  1. Выполнение системного анализа и проектирования на всех уровнях систем, состоящих из людей, машин, материалов, компьютеров и информации всех видов целого предприятия, системы или объекта;
  2. Подготовку справочной документации, которая осуществляется одновременно с разработкой, что способствует интеграции новых систем и стимулирует совершенствование существующих систем;
  3. Обмен информацией между разработчиками, дизайнерами, пользователями и менеджерами;
  4. Достижение консенсуса коалиционной команды на основе единого понимания;
  5. Управление крупными и сложными проектами с использованием качественных показателей хода выполнения;
  6. Предоставление эталонной архитектуры для корпоративного анализа, информационной инженерии и управления ресурсами.

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

3.2 Синтаксис и семантика

3.2.1 Синтаксис

Структурные компоненты и особенности языка, а также правила, определяющие отношения между ними, называются синтаксисом языка. Компонентами синтаксиса IDEF0 являются блоки и стрелки, правила и диаграммы. Блоки представляют функции, определяемые как деятельность, процесс, операция, действие или преобразование. Стрелки представляют данные или материальные объекты, связанные с функциями. Правила определяют, как следует применять компоненты; диаграммы обеспечивают формат графического и словесного описания моделей. Формат образует основу для управления конфигурацией модели.

3.2.1.1 Блоки

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

  • Имя функции -это глагол или глагольный оборот.
  • Отображается номер блока.


Рисунок 1. Синтаксис блока.

3.2.1.2 Стрелки

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


Рисунок 1. Синтаксис блока.

3.2.1.3 Синтаксические правила

Блоки

  1. Размеры блоков должны быть достаточными для указания названия блоков.
  2. Блоки должны иметь прямоугольную форму.
  3. Блоки должны быть нарисованы сплошными линиями.

Стрелки

  1. Ломанные стрелки изгибаются только под углом 90 град.
  2. Стрелки должны быть нарисованы сплошными линиями.
  3. Стрелки должны быть нарисованы вертикально или горизонтально, а не по диагонали.
  4. Концы стрелок должны касаться внешнего периметра функционального блока и не должны пересекать его.
  5. Стрелки должны присоединяться к блоку на его сторонах. Присоединение в углах не допускается.

3.2.2 Семантика

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

3.2.2.1 Семантика блоков и стрелок.

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

Чтобы гарантировать точность модели, следует использовать стандартную терминологию. Блоки именуются глаголами или глагольными оборотами и эти имена разделяются и группируются в диаграммах декомпозиции. Стрелки и их сегменты, как отдельные, так и связанные в «пучок», помечаются существительными или оборотами существительного. Метки сегментов стрелок являются предписывающими, ограничивающими значение сегмента для применения исключительно к конкретным данным или объектам, которые графически представляет сегмент стрелок. Значения стрелок далее выражаются через синтаксис ветвления и слияния.

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

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

Стандартные положения стрелок показаны на Рис.3.

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


Рисунок 3. Позиции стрелок и их значение

3.2.2.2 Имена и метки

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

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

Пример размещения меток стрелок и названий блоков приведен на Рис.4.


Рисунок 4. Семантика метки и имен.

3.2.2.3 Семантические правила блоков и стрелок.

  1. Имя блока должно быть активным глаголом или глагольным оборотом.
  2. Каждая сторона функционального блока должна иметь стандартное отношение блока/стрелки:

    a) Вводящие стрелки должны подходить к левой стороне блока;

    b) Стрелки управления должны подходить к верхней стороне блока.

    c) Выводящие стрелки должны отходить от правой стороны блока;

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

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

  3. Сегменты стрелок, за исключением стрелок вызова, должны помечаться существительным или оборотом существительного, если только единственная метка стрелки несомненно не относится к стрелке в целом.
  4. Знак ««Тильда” () используется для связи стрелки с соответствующей меткой, если только связь между стрелкой и меткой не является очевидной.
  5. В метках стрелок не должны использоваться следующие термины: функция, ввод, контроль, вывод, механизм, вызов.

3.3 Диаграммы IDEF0

3.3.1. Типы диаграмм

IDEF0-модели состоят из трех типов документов: графических диаграмм, текста и глоссария. Эти документы имеют перекрестные ссылки друг на друга. Графическая диаграмма – главный компонент IDEF0-модели, содержащий блоки, стрелки, соединения блоков и стрелок и связанные с ними отношения. Блоки представляют основные функции моделируемого объекта. Эти функции могут быть разбиты (декомпозированы) на составные части и представлены в виде более подробных диаграмм; процесс декомпозиции продолжается до тех пор, пока объект не будет описан на уровне детализации, необходимом для достижения целей конкретного проекта. Диаграмма верхнего уровня в модели дает наиболее общее или абстрактное описание предмета, представленного моделью. За этой диаграммой следует ряд дочерних диаграмм, дающих более подробную информацию об объекте.

3.3.1.1 Контекстная диаграмма верхнего уровня

Каждая модель должна иметь контекстную диаграмму верхнего уровня, на которой объект моделирования представлен единственным блоком с граничными стрелками. Эта диаграмма называется А0 (произносится как минус ноль). Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой. Поскольку единственный блок представляет весь объект, его имя – общее для всего проекта. Это же справедливо и для всех стрелок интерфейса, поскольку они представляют полный комплект внешних интерфейсов объекта. Диаграмма A-0 также задает область действия модели или ее границу и ориентацию. Пример диаграммы А-0 показан на Рис.5.
Контекстная диаграмма А-0 также должна содержать краткие утверждения, определяющие точку зрения и цель модели. Эти утверждения помогают руководить разработкой модели и ввести этот процесс в определенные рамки. Точка зрения определяет, что можно „увидеть “в контексте модели и с какой точки зрения или „под углом“. В зависимости от аудитории могут быть приняты различные точки зрения, которые подчеркивают различные аспекты объекта. Аспекты, важные с одной точки зрения, могут не появиться в модели, разрабатываемой с другой точки зрения на тот же самый объект.
Формулировка цели выражает причину создания модели, т.е. содержит перечень вопросов, на которые должна отвечать модель, что в значительной мере определяет ее структуру. Наиболее важные свойства объекта обычно выявляются на верхних уровнях иерархии; по мере декомпозиции функции верхнего уровня и разбиения ее на подфункции, эти свойства уточняются. Каждая подфункция моделируется индивидуально блоком, а родительские блоки детализируются дочерними диаграммами на следующем более низком уровне. Все дочерние диаграммы должны находиться в пределах области действия контекстной диаграммы верхнего уровня.


Рисунок 5. Пример диаграммы верхнего уровня

3.3.1.2 Дочерняя диаграмма

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

3.3.1.3 Родительская диаграмма

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

  1. Хронологический номер создания, называемый „С-номером“, который должен однозначно идентифицировать конкретную версию дочерней диаграммы.
  2. Номер страницы дочерней диаграммы в опубликованном документе, в котором отображается модель.
  3. Номер ноды, ссылающейся на дочернюю диаграмму. Если существует несколько версий дочерней диаграммы, то конкретная версия не может быть указана.
  4. Номер примечания к модели, в тексте которого указаны условия выбора конкретной дочерней версии.

Рисунок 7 иллюстрирует использование номеров нод в качестве DRE. На рисунке наличие DRE под блоками 1, 2 и 3 указывает на то, что они были подробно детализированы на указанных дочерних диаграммах.


Рисунок 7. Использование специального ссылочного кода

3.3.1.4 Текст и глоссарий

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

3.3.1.5 Диаграммы-иллюстрации

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

3.3.2 Свойства диаграмм.

3.3.2.1 Стрелки как ограничения

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


Рисунок 8. Влияние ограничения

3.3.2.2 Активации блока

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

3.3.2.3 Параллельное функционирование

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

В данном случае функции 2 и 3 могут работать одновременно.

Рисунок 9. Параллельное функционирование

3.3.2.4 Стрелки как трубы

Стрелки высокого уровня можно сравнить с трубами или каналами. Стрелки высокого уровня имеют общие метки, в то время как стрелки на диаграммах более низкого уровня имеют более конкретные метки. Если стрелка разветвляется, образуя два или более новых сегмента стрелки, каждый сегмент стрелки может иметь более конкретную метку, как показано на Рис.10.

Пучок A разделяется на B и C, чтобы обеспечить управление X и Y.

Рисунок 10. Стрелка труба с разветвлением

3.3.2.5 Ветвление стрелок

Стрелка может ветвится (разветвляться или соединяться), указывая, что один и тот же тип данных или объект может быть необходим или создан более чем одной функцией. Ветви могут представлять тот же объект, либо части того же объекта. Поскольку метки указывают, что представляют сегменты стрелок, метки на ветвящихся сегментах стрелок обеспечивают детализацию содержимого стрелок так же, как диаграммы нижнего уровня обеспечивают детализацию родительских блоков.
Всё или часть содержимого стрелки может следовать по ответвлению. Разветвленная стрелка может обозначать «разделение» значений, которые были объединены более общей меткой. Соединение двух сегментов стрелки может означать „связывание“, то есть объединение отдельных значений в более общую категорию. Все данные задаются через ветви, если иное не обозначено специальной меткой на каждом сегменте стрелки. Данное правило проиллюстрировано на Рис. 11.


Рисунок 11. Конструкции разветвления и соединения

3.3.2.6 Межблочные соединения

За исключением одноблоковой контекстной диаграммы A-0, графическая диаграмма содержит минимум три и максимум шесть блоков. Блоки обычно расположены по диагонали от верхнего левого угла до нижнего правого, то есть в конфигурации „лестница“.
Любая выводящая стрелка может предоставлять некоторые или все данные или объекты ввода, управления или механизма в любой другой блок. Выводящая стрелка может передавать данные или объекты в несколько блоков с помощью механизм разветвления, как показано на Рис.12.


Рисунок 12. Межблочные соединения

Если блок на диаграмме детализирован дочерней диаграммой, каждая стрелка, связанная с родительским блоком, должна быть отображена на дочерней диаграмме, если стрелка не туннелируется рядом с ее родительским блоком (см. Раздел 3.3.2.9).
На диаграмме данные или объекты могут быть представлены внутренней стрелкой, причем оба конца (источник и потребитель) соединены с блоками, или граничной стрелкой, имеющей только один подсоединенный конец (источник или потребитель). Внутренние стрелки и граничные стрелки показаны на Рис.13. Граничные стрелки подробно описаны в разделах 3.3.2.7 и 3.3.2.8.


Рисунок 13. Граничные и внутренние стрелки

3.3.2.7 Граничные стрелки

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


Рисунок14. Граничная стрелка

3.3.2.8 ICOM кодирование граничных стрелок

Коды ICOM связывают граничные стрелки на дочерней диаграмме со стрелками на родительском блоке. Определенные условные обозначения, называемые кодами ICOM, определяют тип подсоединения. Буквы I (Input, Ввод), C (Control, Управление), O (Output, Вывод) или M (Mechanism, Механизм) указываются рядом со свободным концом каждой граничной стрелки на дочерней диаграмме. Эта кодировка определяет стрелку на родительском блоке как ввод, сигнал управления, вывод или механизм. За буквой следует цифра, указывающее относительное положение стрелки, подключенной к родительскому блоку, нумерация слева направо или сверху вниз. Например, запись “C3», на граничной стрелке дочерней диаграммы, указывает, что эта стрелка соответствует третьей стрелке управления (слева на право), входящей в родительский блок.
Это кодирование связывает каждую дочернюю диаграмму с ее собственным непосредственным родительским блоком. Если блоки на дочерней диаграмме детализированы на последующих дочерних диаграммах, то на каждой новой дочерней диаграмме назначаются новые коды ICOM, связывающие граничные стрелки этой диаграммы со стрелками на ее собственном непосредственном родительском блоке.
Иногда буквенные ICOM коды, определяющие роли граничных стрелок (ввод, управление, механизм), могут меняться при переходе от родительского блока к дочерней диаграмме. На Рисунке 14 показан общий случай, когда роли действительно совпадают, например, вводные данные родительского блока совпадают с вводными данными дочерней диаграммы. В качестве примера изменения ролей управляющая стрелка в родительском блоке может быть вводом на дочерней диаграмме. Аналогично, ввод родительского блока может быть управлением для одного или более дочерних блоков. На Рис. 15 показаны примеры изменения ролей стрелок.

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

Рисунок 15. Коды ICOM и изменение ролей стрелок

3.3.2.9 Стрелки туннелирования

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


Рисунок16. Стрелки туннелирования на подсоединенном конце

Туннелирование стрелки на неподсоединенном конце означает, что данные или объекты не являются необходимыми на следующем более высоком (родительском) уровне и, следовательно, не должны отображаться подключенными к родительскому блоку. Данный случай изображен на Рисунке 17. Поскольку эта стрелка не соответствует стрелке на родительской диаграмме, ей не присваивается код ICOM. Стрелка может иметь прикрепленное примечание к модели, содержащее ссылку на ноду и код ICOM, который определяет местоположение «другого конца» туннеля. Кодирование ICOM для стрелки возобновляется на всех последующих дочерних диаграммах.
На Рисунке 18 приведен пример стрелок туннелирования на родительской и дочерней диаграммах.


Рисунок17. Стрелки туннелирования на неподсоединенном конце


Рисунок18. Пример стрелок туннелирования

3.3.2.10 Стрелка вызова

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

3.3.3 Правила построения диаграмм

  1. Контекстные диаграммы должны иметь номера нод A-n, где n больше или равно нулю.
  2. Модель должна содержать контекстную диаграмму А-0, которая включает только один блок.
  3. Номер единственного блока на контекстной диаграмме A-0 должен быть 0.
  4. Неконтекстная диаграмма должна содержать не менее трех и не более шести блоков.
  5. Каждому блоку на неконтекстной диаграмме присваивается номер, который располагается внутри блока в нижнем правом углу. Порядок нумерации от верхнего левого к нижнему правому блоку (номера от 1 до 6).
  6. Каждый блок, подвергнутый декомпозиции, должен иметь специальный ссылочный код на дочернюю диаграмму. Ссылка GRE (например, номер ноды, C-номер или номер страницы) помещается под правым нижним углом блока.
  7. Стрелки должны быть нарисованы в виде горизонтальных и вертикальных отрезков прямой линии. Отрезки линий, расположенные по диагонали не использовать.
  8. Каждый блок должен иметь как минимум одну стрелку управления и одну выводящую стрелку.
  9. Блок должен иметь ноль или более вводящих стрелок.
  10. Блок должен иметь ноль или более стрелок механизма без вызова.
  11. Блок должен иметь 0 или 1 стрелок вызова.
  12. Обратные связи по управлению должны быть показаны как «вверх и над»

    Обратные связи по входу должны быть показаны как «вниз и под»

    Обратные связи механизма должны быть показаны как «вниз и под»

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

    Так предпочтительнее

    Чем такое решение

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

3.3.4 Ссылочные выражения (коды)

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

3.3.4.1 Номера блоков

Каждому блоку на диаграмме присваивается номер, помещаемый в нижнем правом внутреннем углу блока. Эта система нумерации необходима для однозначной идентификации блоков в пределах диаграммы и для генерации номеров нод. Эти номера используются также для ссылок на блоки в тексте и глоссарии.
На контекстной диаграмме A-0 единственному блоку присваивается номер 0 (нуль). Номера блоков на всех других графических диаграммах должны принимать значение 1, 2, 3 до максимум 6, чтобы однозначно идентифицировать от трех до шести блоков на каждой такой диаграмме. Для блоков, расположенных по диагонали на диаграмме от верхнего левого угла до нижнего правого угла, блоки нумеруются по порядку, начиная с верхнего левого угла. Если некоторые блоки на диаграмме размещены не по диагонали, то сначала нумеруются «диагональные» блоки (также начиная с левого верхнего блока), а затем – «недиагональные» блоки, начиная с нижнего правого против часовой стрелки

3.3.4.2 Номер ноды

Номер ноды базируется на положении блока в иерархии модели. Обычно номер ноды формируется добавлением номера блока к номеру диаграммы, на которой он появляется. Например, номер ноды блока 2 на диаграмме А25 равен А252. Все номера нод IDEF0 начинаются с заглавной буквы, например, «A». Когда родительский блок подробно описывается дочерней диаграммой, номера нод родительского блока и дочерней диаграммы совпадают.
Контекстные диаграммы и дочерняя диаграмма верхнего уровня являются исключениями из приведенной выше схемы нумерации нод. Каждая модель IDEF0 имеет контекстную диаграмму верхнего уровня диаграмму A-0. Эта диаграмма содержит единственный «высший блок», который является уникальным родителем всей модели и имеет уникальный номер 0 (нуль) и номер ноды A0. Каждая модель IDEF0 должна также иметь по крайней мере одну дочернюю диаграмму, содержащую декомпозицию блока А0 на 3 … 6 дочерних блоках. Этим блокам присваиваются уникальные номера нод A1, A2, A3, … A6. Таким образом, последовательность [A0, A1,…, A2,…, A3,…] начинает нумерацию нод для любой модели.
Например, модель может иметь следующие номера нод:

Номера нод также могут использоваться в качестве подробных ссылочных выражений для указания детализации родительского блока дочерней диаграммой. Если функция была декомпозирована (разложена на составляющие), то под нижним правым углом родительского блока можно записать номерноды дочерней диаграммы, в которой она подробно описана. На Рисунке 7, DRE (в данном случае номера нод) для блоков 1, 2 и 3 указывают на то, что они были детализированы и идентифицируют дочерние диаграммы.

3.3.4.2.1 Перечень нод

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


Рисунок 19. 3.3.4.2.1 Перечень нод

3.3.4.2.2 Дерево нод

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


Рисунок 20. Типичное дерево узлов

3.3.4.3 Ссылки на ноды

Каждая диаграмма в модели имеет ссылку на ноду, которая однозначно идентифицирует ее и ее положение в иерархии модели. Ссылка на ноду состоит из сокращенного названия модели (см. раздел 3.4.5) и номера ноды диаграммы (см. раздел 3.3.4.2), разделенных косой чертой (/). Например, модель с именем «Операции обеспечения качества» может иметь аббревиатуру QA, а ссылка на ноду принимает вид QA/A312. В ссылке на диаграмму той же модели можно не указывать аббревиатуру имени модели, а только номер ноды диаграммы.
Ссылка на ноду может также иметь суффикс, например, F (для FEO), T (для текста) или G (для глоссария) и номер страницы. Например, ссылка на ноду для FEO может иметь вид QA / A321F1 (см. Раздел 3.4.4).

3.3.4.4 Примечания к модели

Примечания к модели являются необязательными. Они обозначаются целым числом “n” внутри небольшого квадрата ( n ). Для данной диаграммы, номера примечаний должны образовывать последовательность, начиная с 1. Вертикальные отрезки, расположенные по бокам номера примечания (|n|), могут использоваться в качестве альтернативного обозначения.
Примечания к модели содержат информацию, относящуюся к сообщению диаграммы (и являющуюся его неотъемлемой частью), но не вписывающуюся в синтаксис прямоугольника и стрелки. Если текст примечания относится к нескольким местам или нескольким признакам диаграммы, то номер примечания в рамке (без текста) может быть скопирован и прикреплен с помощью тильды IDEF0 к каждой точке применения, но только на одной диаграмме, на которой появляется текст приложения модели.

3.3.4.5 Справочная запись

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

3.4 Модели

3.4.1 Описание модели IDEF0

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

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

3.4.2 Контекстные диаграммы

Диаграмма, в которой имеется высший блок A0, представляет контекст модели и называется контекстной диаграммой. Минимальный контекст для модели это специальная контекстная диаграмма с узловым номером A-0. Контекстная диаграмма A-0 имеет только один высший блок с именем A0 с обозначенными внешними стрелками, а также текстовые определения Точки зрения и Цели модели. (Диаграмма A-0 не имеет кодов ICOM или туннелирования на свободных концах стрелок.)

Иногда, однако, для того, чтобы обеспечить более полное представление о внешнем окружении контекста модели, приводится контекстная диаграмма А-1 (имеющая вид обычной, неконтекстной диаграммы). В контекстной диаграмме A-1 блок A0 занимает место одного из трех-шести пронумерованных блоков (другие блоки сохраняют предназначенные для них номера), поэтому эффект заключается в том, чтобы обеспечить полную родительскую диаграмму (с тремя – шестью блоками) для высшей модели-узлы A1-A6 которые все еще являются дочерними элементами первого поколения. В случае, если используется контекстная диаграмма A-1, контекстная диаграмма A-0 все равно представляется. Диаграмма А-0 по-прежнему имеет только один высший блок с именем А0 с помеченными внешними стрелками, а также текстовыми определениями Точки зрения и Цели модели.

Контекстные диаграммы это диаграммы, имеющие номера нод вида «A-n» (со знаком минус), где n больше или равно нулю. Обычные, неконтекстные диаграммы не имеют знака минус в своих номерах нод. Номер высшего блока модели (представляющего весь моделируемый объект) всегда равен 0. Блок под номером 0 должен присутствовать на обязательной контекстной диаграмме модели А-0, а также на дополнительной контекстной диаграмме А-1 (если таковая имеется), где он занимает место одного из блоков (от 1 до максимум 6) родительской диаграммы А-1 (всей модели). Таким образом, A0 всегда является (общим) номером ноды родительского блока и дочерней диаграммы для всей модели и всегда детализируется блоками с номерами нод A1, A2, A3,… A6.

При наличии только одного блока, A-0 является правильной контекстной диаграммой, но не является (правильной) родительской диаграммой. Правильные диаграммы имеют от трех до шести блоков. Родительский контекст-это то, что предоставляет или обозначает контекст для диаграммы вместо правильной родительской диаграммы. Родительский контекст диаграммы A0 это обязательный A-0, если нет контекстной диаграммы A-1. Если существует контекстная диаграмма A-1, то А-1 является правильным родителем диаграммы A0. Родительский контекст контекстной диаграммы A-0 всегда является «Высшим».

3.4.3 Контекстные диаграммы высокого уровня

Контекстные диаграммы высокого уровня имеют номера нод A-n, где n больше единицы. Таким образом, A-1 является контекстной диаграммой, правильным родителем (от A0), но не имеет высокого уровня. Для данного представления модели контекстная диаграмма высшего уровня (наибольшее n) имеет родительский контекст «NONE» (НЕТ), если только контекстная диаграмма высшего уровня не A-0.

Каждая контекстная диаграмма высокого уровня, A-n, синтаксически является обычной детализированной диаграммой, за исключением того, что один из ее трех-шести блоков имеет номер, замененный на «минус N-1». В этом случае для A-1 этот блок является высшим блоком модели A0, а модель в целом (сам блок A0, родитель дочерних блоков), по-видимому, имеет родителя A-1, прародителя A-2 и т. д.

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

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

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

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


Рисунок 21. Контекст с отрицательным номером ноды.

3.4.4 FEO, текст и глоссарий

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

Для каждой формы (FEO, текст и глоссарий) нотация расширения нумерации нод состоит из одной буквы, добавляемой к соответствующему номеру ноды. Например, номера нод для FEO должны содержать букву » F » (например, A312F).

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

Аналогичным образом, некоторые пользователи IDEF0 записывают свои текстовые комментарии в формы диаграмм IDEF0, хотя использование этой формы для текста не требуется. В этом случае текстовая страница должна содержать текстовые комментарии для конкретной связанной ноды IDEF0. Номера нод таких текстовых страниц должны содержать букву» Т » для текста (например, A312T).

Если существует более одной страницы FEO, глоссария или текста, связанной с данным узлом IDEF0, страницы должны быть обозначены дополнительным номером для уникальной идентификации каждой из них (например, A312F1, A312F2,… А312Г1, А312Г2,…, А312Т1, А312Т2, …).

3.4.5 Название модели

Каждая модель имеет уникальное описательное имя, которое отличает ее от других моделей, с которыми она может быть связана. Это имя модели обычно сокращается (уникально) для использования в ссылках на узлы. Например, название модели «Производственные операции» может быть сокращенно как MFG. Обсуждение ссылок на узлы см. в Разделе 3.3.4.3.

3.4.6 Правила презентации

  1. Когда есть текст, он должен сопровождать соответствующую графическую диаграмму.
  2. В неопубликованных моделях глоссарий, относящийся к конкретной графической диаграмме, должен сопровождать диаграмму и определять только ключевые слова, фразы и аббревиатуры, используемые с конкретным узлом.
  3. В опубликованных моделях раздел глоссария определяет для всей модели, расположенные алфавитном порядке ключевые слова, фразы и аббревиатуры.
  4. Если для модели предусмотрено оглавление, то оно должно быть представлено в виде дерева нод или перечня нод и содержать номера нод, названия диаграмм и названия блоков.

ПРИЛОЖЕНИЕ А-КОНЦЕПЦИИ IDEF0

A.1 Предыстория

Стремление ВВС США сократить расходы и сроки выполнения заказов путем оказания помощи аэрокосмической промышленности в ее усилиях по модернизации подтверждается многочисленными программами “Tech Mod” (Модернизация технологий). Аналогичная цель, но с использованием общепромышленной базы, а не отдельных компаний, была поставлена в рамках программы ICAM (Integrated Computer Aided Manufacturing, Интегрированная автоматизация производства). Целью ICAM была разработка “универсальных подсистем”, которые могли бы использоваться большим числом компаний для обеспечения значительного обновления отрасли в целом. Эти «подсистемы» обеспечивают поддержку таких общих функций, как управление информацией, планирование работы цехов и обработка материалов.

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

Для разработки архитектуры необходим “язык”, на котором можно было бы выражать свои мысли и документировать текущие операции в аэрокосмической промышленности. В начале работы над программой ICAM Военно-воздушные силы опубликовали запрос на представление предложений по созданию архитектуры. В качестве понятного и единого языка была определена методика моделирования деятельности (где деятельность определялась как производственная ячейка или операционная единица). Чтобы решать задачи, язык должен был удовлетворять следующим критериям:

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

A.2 Концепции IDEF0

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

  1. Графическое представление моделирования деятельности. Изображение «блок и стрелка» на диаграмме IDEF0 обозначают производственную операцию в виде блока, а взаимосвязи к / от при выполнении операции как стрелки, вводящие/ выводящие из блока. Чтобы иметь возможность отражать реальные производственные операции, блоки должны контактировать с другими функционирующими блоками посредством интерфейсных стрелок, обеспечивающих «ограничения» относительно того, когда и как запускаются и управляются операции.
  2. Краткость. Документация производственной архитектуры должна быть краткой, чтобы охватить предмет исследования. Линейная, многословная характеристика текста на обычном языке явно недостаточна. Двухмерная форма, предоставляемая в виде чертежа, имеет желаемую лаконичность, не теряя при этом возможности выражения таких отношений, как интерфейсы, обратная связь и пути ошибок.
  3. Обмен информацией. Существует несколько концепций IDEF0, которые предназначены для улучшения обмена информацией:
    • Диаграммы, основанные на очень простой графике блоков и стрелок.
    • Английский текст для описания назначения блоков (функции) и стрелок (данные или объекты).
    • Последовательная экспозиция деталей, отображающая иерархиею с основными функциями на верхнем уровне и подфункциями на последующих уровнях, хорошо продуманная детализация.
    • Индекс ноды для определения местоположения деталей в иерархической структуре диаграмм.
    • Ограничение детализации на каждой последующей диаграмме не более чем шестью подфункциями для удобства чтения.

    Диаграммы, сопровождаемые текстом и глоссарием, повышают точность графического представления.

  4. Строгость и точность. Правила IDEF0 обеспечивают достаточную строгость и точность для удовлетворения потребностей архитектуры ICAM без чрезмерного ограничения разработчика. Правила IDEF0 включают:
    • Тщательный контроль экспозиции на каждом уровне (правило 3-6 блоков).
    • Ограниченный контекст (никаких пропусков или дополнительных неохваченных деталей).
    • Синтаксические правила для графики (прямоугольники и стрелки).
    • Уникальность имен и меток на диаграмме.
    • Связность диаграмм (продуманный специальный ссылочный код [DRE]).
    • Взаимодействие данных / объектов (коды ICOM и стрелки туннелирования).
    • Разделение ввода и управления (правило определения роли данных или объектов).
    • Минимальный контроль функции (все функции требуют по крайней мере одного контроля).
    • Ограничение разветвления стрелки (разветвление или соединение) (метки для сегментов стрелки).
    • Требования к меткам стрелок (минимальные правила маркировки).
    • Цель и Точка зрения (все модели должны иметь формулировку цели и точки зрения).
  5. Методология. Пошаговые процедуры предусмотрены для моделирования, анализа и обсуждения задач.
  6. Организация и функции. Отделение организации от функции входит в цель модели и осуществляется путем выбора функций и меток стрелок при разработке модели. Постоянный обзор во время разработки модели гарантирует, что организационные точки зрения будут исключены.

A.3 Обсуждение отдельных концепций IDEF0

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

A.3.1 Графика моделирования деятельности

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

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

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


Рисунок А1. Функциональный блок и стрелки данных / объектов

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


Рисунок А2. Диаграммы ограничений

На рисунке A2 функция B ограничена одним вводом и двумя сигналами управления и формирует один вывод, который ограничивает функцию C.

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

A.3.2 Обмен информацией путем последовательного введения деталей

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

Структура модели IDEF0 показана на Рисунке A3. Серия из четырех диаграмм с отношением каждой диаграммы к другим.

Модель IDEF0 начинается с представления всей системы в виде одного блока со стрелками, взаимодействующими с функциями вне системы. Поскольку единственный блок представляет весь объект, его имя – общее для всего проекта. Это справедливо и для всех стрелок диаграммы, поскольку они представляют полный комплект внешних интерфейсов объекта. Диаграмма с единственным блоком называется «контекстная диаграмма» и определяет в тексте Точку зрения и Цель модели

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


Рисунок А3. Структура модели IDEF0

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

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

A.3.3 Дисциплинированная командная работа

Методология IDEF0 включает процедуры разработки и критики моделей большой группой людей, а также интеграции вспомогательных подсистем в Архитектуру IDEF0. Дополнительные вспомогательные процедуры, такие как правила и процедуры для библиотек и обзорный цикл (см. Приложение С), также включены в методологию IDEF0. (Следует отметить, что некоторые из этих правил и процедур, такие как «Цикл Комплекта» или «Цикл критики читателя-разработчика», также используются в других методиках IDEF).

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

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

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

ПРИЛОЖЕНИЕ В СОЗДАНИЕ И ИНТЕРПРЕТАЦИЯ ДИАГРАММ IDEF0

B.1 Чтение диаграмм IDEF0

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

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

При публикации модель отображается в формате «пара страниц” и порядке „перечень нод“. Формат „пара страниц“ означает, что каждая диаграмма и весь текст, связанный с ней, отображаются на паре развернутых страниц. (Рисунок В1.)


Рисунок В1. Формат » Пара страниц»

Порядок «перечень нод» означает, что все дочерние диаграммы, относящиеся к одному блоку на диаграмме, представляются перед дочерними элементами следующего блока. Это позволяет расположить связанные диаграммы в порядке, используемом в обычном оглавлении, как показано на Рисунке В2.
Меньшая диаграмма является родительской для текущей диаграммы.


Рисунок В2. Перечень узлов, определяющий порядок диаграмм

B.1.1 Подход к разработке модели

Модели представляют собой краткое описание всей системы или объекта, а также детали конкретного объекта. Чтобы прочитать модель с целью ознакомления, используйте индекс, для поиска диаграмм высокого уровня. (Рисунок B3.)

А0 Производить продукт

А1 Планировать производство

A11 Предположить структуру и метод Mfg.

А12 Оценить требуемое время и затраты на производство

А13 Разработать производственные планы

А14 Разработать план вспомогательных мероприятий

A2 Составить администрирование расписаний и бюджетов

А21 Разработать основной график

А22 Разработать график координации работ

A23 Оценивать затраты и приобретать ресурсы

A24 Следить за выполнением графика и расходом ресурсов

A3 Планировать выпуск продукции

Для подробного ознакомления с моделью воспользуйтесь индексом, чтобы найти все диаграммы, детализирующие интересующую вас тему (Рисунок В4.)

А0 Производить продукт

А1 Планировать производство

A11 Предположить структуру и метод Mfg.

А12 Оценить требуемое время и затраты на производство

А13 Разработать производственные планы

А14 Разработать план вспомогательных мероприятий

A2 Составить администрирование расписаний и бюджетов

А21 Разработать основной график

А22 Разработать график координации работ

A23 Оценивать затраты и приобретать ресурсы

A24 Следить за выполнением графика и расходом ресурсов

A3 Планировать выпуск продукции

Дальнейшую детализацию в модели можно проследить, обратившись к детальному ссылочному выражению (DRE), расположенному чуть ниже номера блока. В нем указаны номер узла, C-номер или номер страницы дочерней схемы, которая детализирует блок. В приведенном ниже примере сведения для графы 3 на диаграмме А24 можно найти на диаграмме с узловым номером А243. Если DRE отсутствует, то блок еще не детализирован.

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

B.1.2 Порядок чтения диаграммы

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

  1. Просмотрите блоки диаграммы, чтобы получить представление о том, что описывается.
  2. Вернитесь к родительской диаграмме и обратите внимание на соединения стрелок с родительским блоком. Попробуйте определить ”самый важный » ввод, сигнал управления и вывод.
  3. Изучите стрелки текущей диаграммы. Попробуйте определить, существует ли основной путь, связывающий” самый важный «ввод или сигнал управления и» самый важный » вывод.
  4. Мысленно пройдите по схеме сверху вниз слева направо, используя в качестве ориентира основной путь. Обратите внимание, как другие стрелки взаимодействуют с каждым блоком. Определите, существуют ли другие пути. Проверьте историю, рассказанную диаграммой, рассмотрев, как разрешаются знакомые ситуации.
  5. Проверьте, существует ли связанная диаграмма иллюстрация FEO.
  6. Наконец, внимательно прочтите текст и глоссарий, если таковые имеются.

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

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


Рисунок В1. Формат » Пара страниц»

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

B.1.3 Семантика блоков и стрелок

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

Рисунок В6. Пример ограничений

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

температура измерялась путем периодического отбора проб, или

текущие допуски были запрошены только тогда, когда температура увеличилась на некоторую фиксированную величину, или

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

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

B.1.3.1 Как и когда не учитываются ограничения

Любое из двух представлений:

говорит, что: действие a2 зависит от «d», которое создано или изменено действием a1.

Каждое представление определяет связь ограничений между двумя блоками. Все, что явно указано промежуточной стрелкой для любого представления, выражается следующим образом: для некоторой активации блока 2 требуется нечто, называемое «d», которое возникает при некоторой активации блока 1.

Часто диаграммы четко указывают на то, что для двух или более блоков может понадобиться содержимое стрелки. Смысл блоков и стрелок, показанных на Рисунке B7, заключается в том, что нечто, произведенное блоком 1, необходимо блоку 2 и блоку 3. Возможно, что активация “источника » стрелки (блок 1) должна предшествовать активации “пункта назначения” (блок 2 или блок 3). Может случиться так, что одной активации источника достаточно для активации любого пункта назначения. Без дополнительной информации, только блоки и стрелки позволяют выполнить толкование.


Рисунок В7. Два блока, использующие содержимое одной и той же стрелки

B.1.3.2 Несколько вводов, сигналов управления и выводов

Основная интерпретация блока, показанного ниже (Рис.B8), заключается в следующем: для получения любого подмножества данных вывода [O1, O2, O3] может потребоваться любое подмножество данных ввода [I1, I2, I3, C1, C2, C3, C4, M1, M2, M3]. В отсутствие дополнительной детализации нельзя предположить, что:

a. любой вывод может быть сформирован без данных ввода, или

b. Для формирования вывода требуются все входные данные


Рисунок В8. Иллюстрация кодирования ICOM

Частичная детализация предыдущего блока (показанного на рис. B9, как это может выглядеть на диаграмме иллюстрации FEO) указывает на то, что I3, C2, C3 и C4 не требуются для получения O1. Рисунок В9 иллюстрирует что:

a. некоторая форма дальнейшей детализации определит точное зависимость выводов от вводов и сигналов управления;

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

c. чтение диаграммы должно быть сосредоточено на стрелках, которые являются явными, а не на именах блоков, которые являются неявными.


Рисунок В9. Диаграмма-иллюстрация FEO, представляющий детализацию нескольких ICOM

B.2 Руководство разработчика по созданию диаграмм IDEF0

При создании любой диаграммы IDEF0 необходимо выполнить следующие требования:

a. её назначение и точка зрения должны соответствовать заявленной цели и точке зрения общей модели;

b. её граничные стрелки должны соответствовать стрелкам, которые соединяются с родительским блоком;

c. её содержимое должно точно соответствовать содержимому родительского блока

B.2.1 Основные этапы разработки

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

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

b. Изучить ограниченный набор объектов и сформировать возможные подфункции полной функции.

с. Определить естественные схемы соединения этих подфункций.

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

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

В 2.1.1 Выбор контекста, точки зрения и цели

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

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

Точка зрения определяет, что можно «увидеть „в контексте модели, с какой точки зрения или “под каким углом». В зависимости от поставленной цели могут быть приняты точки зрения, учитывающие различные аспекты объекта. На модель существует только одна точка зрения.

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

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

B.2.1.2 Создание контекстной диаграммы

Прежде всего необходимо создать диаграмму A-0. Нарисуйте единое блок, содержащее название функции, которая определяет всю описываемую систему. Используйте стрелки ввода, контроля и вывода, входящие и выходящие из блока, чтобы представить взаимодействие данных и объектов системы с окружением. Эта одноблоковая диаграмма ограничивает контекст всей модели и служит основой для дальнейших усилий по декомпозиции (разбиению). Сформулируйте Цель и Точку зрения по контекстной диаграмме A-0.

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

Если диаграмма А-0 начинается со слишком низкого уровня детализации, сделайте блок А-0 основой для новой диаграммы уровня А0. Поднимитесь на один уровень вверх до нового А-0 и вернитесь к утверждениям точки зрения и цели. Повторяйте этот процесс до тех пор, пока не будет достигнуто значение A-0, которое имеет достаточный объем для охвата всех аспектов системы. (Иногда такой более высокий уровень скорее расширит, чем прояснит выбранную точку зрения. Если это так, сделайте многоблоковую контекстную диаграмму A-1 и сохраните диаграмму A0 в соответствии с первоначальным назначением).

B.2.1.3 Создание высшей диаграммы

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

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

B.2.1.4 Создание дочерних диаграмм

Чтобы сформировать структуру диаграмм, детализируйте каждый блок на диаграмме A0 разбив его на три-шесть основных частей. Сформируйте новую диаграмму для каждого блока, которая охватывает ту же тему, что и родительский блок, но с большей детализацией.

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

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

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

B.2.1.5 Создание вспомогательного материала

Каждая диаграмма сопровождается страницей повествовательного текста, глоссарием и, возможно, диаграммой-иллюстрацией. Текст, связанный с диаграммой А-0, должен завершать ориентацию модели и записывается при создании диаграммы А-0. Текст дополняет контекст (выраженный в самой А-0), расширяя изложенную точку зрения и цель модели.

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

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

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

B.2.1.6 Выбор блока для детализации

Получив полную родительскую диаграмму, «доработайте» более высокие уровни, прежде чем переходить к деталям. То есть, учитывая А0, акцент делается на работу над А1, А2, А3. Декомпозиция A1 на A11, A111 должна выполняться позже. Это позволяет избежать возможных переделок в случае внесения изменений в диаграммы более высокого уровня.

Сохранение равномерной глубины не является строгим правилом. Размер глубины в любой момент времени зависит от того, позволяет ли большая глубина охвата улавливать смысл лучше, чем одна диаграмма. Не откладывайте выполнение диаграммы более низкого уровня, например, A111, а делайте эскизы, пока идеи свежи. Важно относиться ко всем таким попыткам как к наброскам, пока не будет подтвержден «горизонтальный» ровный уровень. Будьте готовы переработать материал нижнего уровня, если он конфликтует с более высоким уровнем, например, A1, A2, A3.

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

  1. Начните с ” трудной части » части, которая наименее знакома или менее понятна.
  2. Выберите блок, детализация которого даст больше информации о других блоках.

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

B.2.1.7 Деятельность разработчика

B.2.1.7.1 Этап сбора данных

Чтение предыстории: автор собирает информацию об объекте, изучая исходную информацию.

Интервью: Автор лично беседует с экспертом по данному вопросу.

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

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

B.2.1.7.2 Этап структурирования

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

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

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

B.2.1.7.3 Этап презентации

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

Обобщение: соберите любой материал, диаграммы, дерево узлов, глоссарии, текст и т. д., относящийся к данной теме. Добавьте сюда заполненный титульный лист.

B.2.1.7.4 Этап взаимодействия

Реагирование: это относится к автору, реагирующему на комментарии. Это сочетание чтения и комментирования реакции на комментарии и ответ читателям.

Собеседование: это время, потраченное на то, чтобы автор и читатель действительно собрались вместе и поговорили о реакции автора на комментарии.

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

B.2.2 Черчение диаграмм IDEF0

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

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

b. Назовите функции, которые воздействуют на перечисленные данные и начертите блоки вокруг имен.

c. Нарисуйте соответствующие стрелки. Когда блоки нарисованы, оставьте стрелки «заглушки», чтобы сделать блок более информативным. Сделайте полные соединения, когда станет ясно, что раскрывает диаграмма.

d. Набросайте макет, который представляет собой наиболее четкое расположение блоков и стрелок. Связывайте стрелки вместе, если структура слишком детализирована. Оставьте только основные элементы и измените диаграмму по мере необходимости.

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

B.2.2.1 Генерации функциональных блоков

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

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

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

Просмотрите получившийся набор функциональных блоков. Ищите оптимальный баланс между выбранными факторами. Посмотрите, можно ли сделать имена более конкретными. Используйте специальные термины и сокращения только в тех случаях, когда это необходимо для продвижения коммуникации с целевой аудиторией, и только на уровне детализированных диаграмм. Не используйте их на самых высоких уровнях (A-0 и A0). Тщательно определите специальные термины в глоссарии.

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

Блоки.

  1. В большинстве случаев располагайте блоки по диагонали от верхнего левого угла до нижнего правого. В то время как любая компоновка, в которой четко обозначены намерения автора, является приемлемой, вертикальные или горизонтальные форматы имеют тенденцию к скоплению стрелок и препятствуют хорошему структурированному стилю анализа.
  2. Блоки, расположенные в левом верхнем углу, «доминируют» над блоками, расположенными ниже и справа через управляющие стрелки, которые их связывают. Этот стандартный стиль помогает читателям понять ваш смысл.
  3. Пронумеруйте каждый блок в нижнем правом внутреннем углу. Присвойте номера блокам на диаграмме слева направо и сверху вниз. Это поможет определить номер узла для каждого блока. Начальные цифры полного номера узла блока совпадают с номером узла диаграммы. Последняя цифра номера узла это номер блока. Если блок на Рисунке B10 отображается на диаграмме A4, то полный номер узла этого блока будет A42.

    Рисунок В10. Номер блока и номер узла

  4. На рабочих или черновых копиях напишите номер узла или C-номер под нижним правым углом любого блока, который детализирован. С-номер DRE указывает на конкретную версию диаграммы, для которой он предназначен.
  5. Любая диаграмма не может содержать более шести блоков.

B.2.2.2 Создание стрелок интерфейса

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

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

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

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

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

Думайте о контроле и ограничении, а не о потоке.

Основное правило при компоновке структуры стрелки » ограничивайте, не упорядочивайте.” Т.е. сделать так, чтобы структура диаграммы отражала взаимосвязи, которые будут верны независимо от того, какая последовательность соблюдается.

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

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

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

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

Тщательно маркируйте.

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

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

Сомнительные стрелки.

Часто бывает трудно определить, показывать стрелку или нет. Самый простое решение: «Когда сомневаешься, пропусти стрелку.” Если стрелка несущественна для основной магистрали, если есть вопросы по ней, то, по всей видимости, неправильно ее включать.

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

B.2.2.3 Уровень усилий

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

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

IDEF0-это методология формирования мыслей, а не просто практика по построению диаграмм. Изложение мыслей на бумаге и кропотливый труд-это путь к успешному разрешению проблемы. Лучше задавайте хорошие вопросы, а не на представляйте “идеальные” ответы.

B.2.3 Повторное построение диаграмм IDEF0

B. 2.3.1 Модифицирующие блоки

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

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

Разделение и перестройка.

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

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

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

Кластеризация и замена.

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

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

Это признак часто появляется при разделении и является одним из самых мощных способов объяснения функций.

B.2.3.2 Связывание (объединение) стрелок

Стрелки и блоки должны иметь соответствующий уровень абстракции на диаграмме.

Этого можно достичь двумя способами:

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

Редко избыток стрелок указывает на ошибку. Может быть, потому что они точны и наносятся аккуратно. Но всегда верно то, что избыток стрелок мешает рассмотреть сообщение. Способность потребителя правильно оценивать то, что представлено, должно определять количество используемых стрелок.

B.2.3.3 Предложение о внесении изменений в контекст

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

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

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

B.2.3.4 Синтаксис ICOM для подключения диаграмм

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

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

B.2.4 Графический макет

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

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

B.2.4.1 Ограничения на диаграмме

  1. Функциональные блоки всегда должны иметь управляющие стрелки, при этом вводящие стрелки могут отсутствовать.
  2. Если вводящая стрелка выполняет функции управления и ввода, отобразить ее как стрелку управления. При наличии сомнений по данному поводу всегда выбирать стрелку управления. Стрелка, отображаемая на родительском блоке в виде стрелки управления, может появиться на следующем уровне в качестве стрелки управления или стрелки ввода или того и другого, в зависимости от ее отношения к подфункциям на этом уровне.
  3. В общем случае не разделяйте стрелку, на вводящую и управления при подключении к одному и тому же блоку. Этот момент лучше всего заметен на диаграмме нижнего уровня, где показано назначение каждой ветви и причина разделения. Если все таки необходимо разделить то выполните это на родительском уровне, промаркировав ветви, что сделает ваше решение более весомым.

  4. Итеративная деятельность (хранение в памяти или обратная связь) может быть показана как:

  5. Старайтесь избегать избыточности, например:

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

B.2.4.2 Размещение стрелок

  1. Стрелки наносятся только в виде горизонтальных и вертикальных отрезков, а не по диагонали или в виде кривых (за исключением углов).
  2. Расположите углы стрелок, пересечения и метки на разумном расстоянии от блоков.
  3. Не используйте ключевые слова, такие как «данные», «функция”, “ввод”, “вывод,“ контроль » или механизм » в названиях или метках, если это не является абсолютно необходимым.
  4. Если стрела длинная, пометьте ее дважды.

  5. Коды ICOM указывать на не подсоединенных концах стрелок.

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

  7. Разместите параллельные стрелки адекватно. За ними трудно уследить визуально, если они длинные и расположены близко друг к другу.

  8. Нарисуйте дополнительные наконечники стрел вдоль стрел, где это необходимо для ясности.

B.2.4.3 Макет стрелки

  1. Объедините стрелки, имеющие одним и тот же источник и пункт назначения, если только стрелка не имеет такой важности, что включение ее в пучок уменьшит ясность понимания.

  2. Используйте как можно меньше стрелок на любой стороне блока. Если их слишком много, скомпонуйте, присвойте соответствующую метку и разведите ветви по назначению.

  3. Обратные связи по управлению должны быть показаны как «вверх и над»


    Обратные связи по вводу должны быть показаны как «вниз и под»


    Обратные связи по вводу должны быть показаны как «вниз и под»

  4. Если стрелка разветвляется и подключается к нескольким блокам, нарисуйте ее в одном и том же относительном положении ICOM на каждом блоке, если это возможно.

  5. Расставьте стрелки так, чтобы свести к минимуму пересечения.

  6. Сведите к минимуму кривые и углы, сохраняя при этом помеченные сегменты четкими

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

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

  9. Все стрелки должны иметь изогнутые углы на стыках, разветвлениях и изгибах.

B.2.5 Написание текста

B.2.5.1 Текст и глоссарий

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

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

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

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

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

B.2.5.2 Примечания и ссылки

Есть два вида примечаний: примечания к модели и примечания читателя. Примечания к модели обсуждаются в нормативном разделе.

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

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

Примечания читателя обозначаются цифрой » n » внутри небольшого круга: n. Для любой конкретной диаграммы (и, следовательно, номера ноды) числа “n” образуют числовую последовательность, начинающуюся с “1”. Все читатели (включая разработчика, когда он комментирует что-то) должны использовать одну и ту же последовательность примечаний для диаграммы. Номера примечаний читателя для ноды никогда не должны использоваться повторно или переназначаться. Таким образом, последовательность, созданная в контексте номера ноды является постоянной записью обсуждения читателя/разработчика относительно этой ноды.

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

Например:

Данные элементы могут использоваться отдельно, если они относятся к текущей диаграмме (например, в примечаниях к модели или тексте). В противном случае им должен предшествовать номер ноды, а при необходимости и название модели. Период “.«используется для обозначения „смотреть“ определенный предмет на указанной диаграмме. Например:

MFG/A21. 3C2 означает: В модели » MFG”, на диаграмме A21, см. Блок 3
Управление 2.

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

Наиболее полная форма следующая:

ACCT/(A21=BT56).1O2 к 4C3

что означает в модели «ACCT», диаграмма А21, С-номер BT56,” см. » стрелку от Блока 1 Вывод 2 к Блоку 4 Управление 3.

Добавляйте аккуратные и полные ссылки в формулировку текста, глоссария и страниц FEO. Например: «Влияние (2o3-1c2 и 3c2) этой стоимости на конечную цену (o2) вызывает озабоченность.» Читается следующим образом: третий вывод Блока 2 через блоки 1 и 3 к граничной стрелке O2. После написания текста, пройдитесь по нему и добавьте ссылки с номерами блоков, чтобы точно привязать текст к диаграмме.

В большинстве случаев достаточно простого номера блока(“Блок3”) или ссылки на пару стрелок (“Блок 3, O1 и C2”). Когда читателю действительно нужно «увидеть» другую диаграмму, используйте».«из справочного языка.

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

Например:

A21.3C2 |2| (5) ответ

переносит предыдущий пример (“на диаграмме А21, см. Блок 3 Управление 2») на случай, когда читатель ссылается на ответ разработчика диаграммы на примечание читателя № 5 (возможно, добавленное вторым читателем диаграммы), который прокомментировал модель, авторское примечание к модели № 2, касающееся рассматриваемого Управления! В этом примере “ответ » демонстрирует использование кратких выражений естественного языка в справочном языке.

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

B.3 Сбор данных для моделирования IDEF

B.3.1 Введение

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

Можно выбрать следующий путь:

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

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

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

B.3.2 Процесс опроса

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

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

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

Обсуждение решений относительно будущих возможностей системы. Этот тип опроса используется для определения содержания будущей операционной модели.

Авторский/редакторский семинар IDEF. Этот тип опроса используется для решения проблем, возникших при построении модели IDEF.

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

B.3.3 Комплект опроса

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

  1. Титульный лист (обложка комплекта)
  2. Опрос и запись последующих действий

    (a) Имя проводящего опрос (IDEF имя автора)

    (b) Дата опроса (дата диаграммы IDEF)

    © Продолжительность опроса (Время начала, Время окончания)

    (d) Имя респондента

    (e) Должность респондента и организационная ответственность

    (f) Номер телефона респондента и другие контактные данные

    (g) Идентифицированные дополнительные источники информации

    1. Документы-название и местонахождение
    2. Другие опрошенные—Имя, Должность, Организационная Ответственность, Адрес, Номер телефона

    (h) Основные элементы информации краткое изложение ключевых моментов, затронутых в опросе.

    (i) Последующие вопросы и / или проблемные области, которые не были затронуты во время опроса или отложены

    (j) Новые термины для глоссария проекта

  3. Список действий и данных / объектов
  4. Программа опроса (разрабатывается при подготовке к опросу).
  5. Примечания к опросу и черновые схемы

ПРИЛОЖЕНИЕ С-ПРОЦЕДУРЫ И ФОРМЫ ЦИКЛА ОБЗОРА

C.1 IDEF Дисциплина командной работы

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

Для правильного чтения и понимания моделей IDEF0 требуется непродолжительное обучение и скромный опыт. Глубокое понимание темы необходимо для обеспечения гарантии качества IDEF-моделирования, предоставляемое командой. Каждый, кто достаточно глубоко продвинулся в правильном чтении, называется «читателем».

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

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

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

C.2 Цикл Комплекта IDEF

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


Рисунок С1. Цикл Комплекта

Этапы цикла Комплекта следующие:

  • Разработчик собирает материал для рецензирования в Стандартный Комплект. Заполняется титульный лист. Экземпляры Комплекта раздаются каждому читателей и автору. Оригинал предоставляется для справки.
  • В течение указанного времени отклика комментатор ознакамливается с Комплектом и пишет комментарии непосредственно на копии в виде примечаний читателя, по возможности красным цветом. Комплект возвращается автору.
  • Разработчик отвечает в письменной форме непосредственно на экземпляре каждого комментатора, по возможности синим цветом. Автор может согласиться с комментарием, поставив на нем галочку и отметив его на своем рабочем экземпляре, включить в следующую версию модели. В случае несогласия автор пишет ответную записку, приложенную к примечанию читателя (без нового номера примечания). Независимо от того, есть ли разногласия, Комплект возвращается читателю, завершая один цикл Читатель/Автор. (См. С. 4. 1. 2 относительно нумерации Примечаний читателя.)
  • Читатель изучает ответы автора и, если он удовлетворен, архивирует комплект. (Комментарии к Комплектам всегда сохраняются у читателя.) Если назначенный комментатор не согласен с ответами автора, организуется встреча с автором для устранения разногласий. Если это невозможно сделать, то перечень вопросов передается в соответствующий орган для принятия решения. Автор не обязан разрешать разногласия с каждым читателем, но комментаторы лишаются права голоса, если их проблемы не разрешаются.

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

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

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

C.2.1 Роли персонала

Роли и функции вовлеченных людей заключаются в следующем:

  • Разработчики (Авторы)
    Разработчики (авторы) модели лица, создающие IDEF0 –модели.
  • Комментаторы (эксперты или другие разработчики)
    Люди, хорошо осведомленные о моделируемом объекте, от которых авторы могли получить информацию посредством беседы, и имеющие достаточную подготовку в технике IDEF, чтобы предлагать структурированные комментарии в письменной форме. Люди, которым поручили сделать письменный комментарий Комплекта.
  • Читатели (эксперты или все, кто хочет быть в списке читателей)
    Люди, хорошо осведомленные о моделируемом объекте, от которых разработчики, возможно, получили информацию посредством беседы или опроса, которые просматривают документацию для получения информации, но не делают письменных комментариев.
  • Библиотекарь
    На данное должностное лицо возлагается обязанность вести архив документов, делать копии, распространять Комплекты и вести учет.

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

«Роль» не имеет ничего общего с должностью, и одного и того же человека могут попросить выполнять несколько ролей. Таким образом, участие каждого индивидуума, по сути, уникально и зависит от исполняемого Комплекта.

C.2.2 Руководство для разработчиков (авторов), читателей и комментаторов

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

C.2.2.1 Руководство для читателей

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

  • Делайте заметки краткими, точными и конкретными. Если разработчик понимает, что понятные вопросы для лаконичности опускаются, то это облегчает общение и уменьшает сумятицу.
  • Обозначение n в кружочке (примечание читателя) определяет комментарий. Чтобы написать n-примечание, определите порядковый номер примечания из списка ПРИМЕЧАНИЯ ЧИТАТЕЛЕЙ, присвойте примечанию номер, обведите его кружком и подключите примечание соответствующей тильдой. (См. Раздел С. 4 Стандартная форма диаграммы.)
  • Критика должна быть конструктивной. Старайтесь предлагать решения или четко указывать на источники проблем.
  • Найдите время, чтобы ознакомиться и обобщить все комментарии. Они могут быть размещены на обложке или на отдельном листе. (Не указывайте то, что уже размещено на других страницах.) Вопросы, которые должны обсуждаться на встречах Разработчиков / комментаторов могут быть обобщены. Список обсуждаемых вопросов должен быть конкретным.

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

C.2.2.2 Взаимодействие разработчика с комментатором

Когда читатель возвращает Комплект, разработчик отвечает, ставя “А » или » Х » на каждое n-примечание (Примечание читателя). “А » означает, что разработчик согласен с комментатором и учтет комментарий в следующую версию Комплекта. “X » означает, что разработчик не согласен. Разработчик должен указать причину несогласия в письменном виде, так где помещен комментарий. После того, как разработчик ответил на все замечания, Комплект возвращается для сохранения читателю.

C.2.2.3 Рекомендации по проведению совещаний

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

Назревшее совещание организуется следующим образом:

  1. Каждое совещание должно быть ограниченно по по времени.
  2. Каждая заседание должно начинаться с обсуждения определенных вопросов, которые относятся к одному или нескольким комментариям и ответам разработчиков, и заседание должно стремиться рассматривать именно эти вопросы.
  3. Каждое заседание должно заканчиваться, когда участники соглашаются с тем, что уровень производительности снизился и индивидуальные усилия будут более полезны.
  4. Каждое заседание должно заканчиваться согласованным перечнем пунктов повестки дня, которые могут включать в себя расписание последующих заседаний с конкретными повестками дня.
  5. На каждом заседании должен быть назначен “секретарь”, который обязан вести протокол и записывать предложения, решения и темы.
  6. 6. Серьезные неразрешенные проблемы следует решать профессионально, документируя обе стороны, участвующие в споре.

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

C.3 Комплекты IDEF

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

В соответствующем Титульном листе представлен материал в виде Комплекта. Титульный лист содержит поля для разработчика, даты, проекта, номера документа, названия, статуса и примечаний.

Существует два вида Комплектов IDEF

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

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

Стандартные Комплекты содержат части модели и часто представляются по мере выполнения работы. Стандартные комплекты представляются на рассмотрение в рамках Цикла комплектов IDEF и относятся к типу, упомянутому в остальной части настоящего приложения.

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

C.3.1 Заполнение Титульного листа Комплекта

В соответствующем Титульном листе представлен материал в виде Комплекта. Титульный лист содержит поля для разработчика, даты, проекта, номера документа, названия, статуса и примечаний. Подготовьте Титульный лист для каждого представленного Комплекта и заполните поля пояснительной записки, как представлено на Рисунке С2.

  • Рабочая информация
    • Разработчик или команда, создающие модель
    • Название проекта и номер задачи
    • Дата сдачи оригинала в библиотеку
    • Даты всех опубликованных редакций
    • Статус модели (рабочая, черновая, рекомендована к принятию или публикации в качестве окончательной модели)
  • Информация рецензента
    • Подача и копирование информации
    • Список рецензентов Комплекта
    • Запланируйте дату различных этапов Цикла комплекта
  • Информация о содержании
    • Оглавление Комплекта
    • Состояние каждого раздела комплекта
    • Комментарии или специальные инструкции для библиотекаря
  • Идентификационная информация
    • Имя модели (в поле Узла)
    • Название модели
    • С-номер

7075626c017800020000036d6163000000000000000000000000000000000000000000000000a8
573683424400010000014209466967757265204332000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000b7
2da828f359656474706450726f00010001000000110001000000000000000000000000000a6669
6e616c2d666970730001000400000142000200186d61633a66696e616c2d666970733a46696775
7265204332000900a700a76166706d00000000000200180039005900750095009e012a00000000
00000000000000000000000000000000000000000000000000000007737065636b6c6500000000
0000000000000000000000000000000000000000036d6163000000000000000000000000000000
0000000000000000000467756e6e00000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000ffff000001010000a8290fbb000075e980000
002005c2d64000000000000000000018a9400000000


Рисунок С3. ФОРМА СОДЕРЖАНИЯ КОМПЛЕКТА IDEF


Рисунок С3. ФОРМА СОДЕРЖАНИЯ КОМПЛЕКТА IDEF

C.3.2 Подготовка стандартного Комплекта

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

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

C. 4 Стандартная форма диаграммы

Форма диаграммы IDEF (Рисунок С4) имеет минимальную структуру и ограничения. Форма включает в себя только те функции, которые важны для структурированного анализа, а именно:

  • Определение контекста;
  • Перекрестные ссылки между частями документа;
  • Сведения о содержании каждого листа.

Форма диаграммы имеет стандартный размер для удобства передачи и копирования. Форма разделена на три основных раздела:

  • Рабочая информация (вверху)
  • Поле сообщения (в центре)
  • Идентификационные поля (внизу)

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

7075626c017800020000036d616300000000000000000000000000000000000000000000000000000000a8
573683424400010000014209466967757265204334000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000b7
2ba82916c0656474706450726f000100010000001100010000000000000000000000000000000a6669
6e616c2d666970730001000400000142000200186d61633a66696e616c2d666970733a46696775
7265204334000900a700a76166706d00000000000200180039005900750095009e012a00000000
000000000000000000000000000000000000000000000000000000000007737065636b6c6500000000
0000000000000000000000000000000000000000036d6163000000000000000000000000000000
0000000000000000000467756e6e000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000ffff000001010000a82932fa000020bf800000
02005c2d2000000000005c2d30000188a400000000

Рисунок С4. Стандартная форма диаграммы

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

C.4.1 Рабочая информация

C.4.1.1 Поля » Разработчик / Дата / Проект”

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

C.4.1.2 Поле «Примечания читателя»

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

C.4.1.3 Поле «Статус»

Классификации статусов указывают на стадии утверждения, а именно:

C.4.1.4 Поле «Читатель/Дата»

В этой области читатель должен указать свою фамилию и дату рассмотрения каждой формы.

C.4.1.5 Поле » Контекст”

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


Рисунок С5. Иллюстрация контекстного поля

Возникают следующие особые случаи: 1) Контекстное поле требуемой формы контекстной диаграммы A-0 «TOP», записанное в центре поля. 2) Контекстное поле дополнительной контекстной диаграммы высокого уровня A-1 это A-2, эскиз, если имеется такая контекстная диаграмма более высокого уровня, и аналогично для A-n, где n = 2 или более. 3) Контекстное поле для контекстной диаграммы высшего уровня, A-n, для самого большого n (= 1 или больше) «NONE». Иллюстративный пример см. на рис.21.

C.4.1.6 Поле «Используется в» (“Used At”)

Это список диаграмм, помимо родительского контекста, которые каким-либо образом используют или ссылаются на данную страницу формы диаграммы.

Чаще всего используется перечисление одной или нескольких ссылок нод на подмодели, для которых родительский блок этой дочерней диаграммы обеспечивает поддержку вызовов при детализации этого дочернего элемента. При необходимости (случай n=1 принимается условно), выражение “node_reference_expression” (которое начинается с «model_name/», за которым следует номер узла) заканчивается «Mn», n больше или равно 2, превращая ссылку в полную ICOM-кодовую ссылку на конкретную стрелку механизма высшего блока поддерживаемой подмодели. Например,” TLS/A34M2“, записанное в поле Used At для дочерней диаграммы” MN/A211“, утверждает, что родительский блок” MN/A21 “обеспечивает поддержку механизма через вторую стрелку механизма его верхнего блока для подмодели » TLS/A34.”

При такой поддержке удаленной субмодели, указанной в поле «Used At», любой дочерний блок на дочерней диаграмме (а более обще, родительский блок, предоставляющий поддержку, или любые дочерние блоки) могут быть призваны поставлять деталей для некоторого доступного дочерненго блока (рассматриваемого как верхний блок субмодели), чья ссылка на ноду появляется в поле «Used At.» Доступный дочерний блок это блок, доступный по стрелке поддержки механизма ветвления, источником которого является ICOM-код, подключенный к поддержке механизма.

Если верхняя часть диаграммы отрезана для публикации, то содержимое поля Used At должно быть скопировано в поле Message в виде n -note (примечание к модели).

C.4.2 Поле » Сообщение” (“Message”)

Поле «Сообщение» содержит основное сообщение, которое должно быть передано. Это поле обычно используется для построения диаграмм с помощью графического языка IDEF. Однако оно может быть использовано для других целей: глоссарий, контрольные списки, заметки, эскизы и т. д. Участники проекта не должны использовать никаких других документов, кроме форм диаграмм, чтобы система регистрации на основе ссылочных номеров могла обеспечить полную запись проекта. Этому может способствовать поддержка инструмента IDEF, включающего в себя электронную почту и доску объявлений, с автоматическим присвоением каждому участнику С-нумерации и «предпочтений».

C.4.3 Поле «Нода» (“Node” )

Это поле содержит полную ссылку на ноду для листа (включая model_name, косую черту, номер ноды и “F “(для FEO),” T “(для текста) или” G “(для глоссария) —с номером страницы” 1 “или” 2 » и т. д. и прилагается в конце, чтобы указать переполнение страниц, если это необходимо), так что лист однозначно определен для справочных и других целей.

C. 4. 4 Поле «Название» (“Title”)

Поле «Название» содержит название материала, представленного на Форме диаграммы. Если поле «Message» содержит диаграмму, то содержимое поля «Title» должно точно соответствовать имени, написанному в родительском блоке.

С. 4. 5 Поле «Номер» (“Number”)

C. 4. 5. 1 Поле «Номер» (Большая область)

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

Если в проекте принято решение отслеживать историю версий, то C-номер формы диаграммы, для которой этот лист является измененной версией, должен быть записан в скобках (пробел необязательный) после записи C-номера разработчика в поле «C-номер». Например, “AB34 (CD123) “означает, что этот лист (”AB34“) предназначен для замены уже существующего”CD123″.

При публикации модели номер С может быть заменен стандартным порядковым номером страницы (например, «стр. 17»).

C. 4. 5. 2 Поле » Номер” (“Number”) («Номер страницы Комплекта» Малая прямоугольная Область)

Номер страницы Комплекта записывается библиотекарем в правой части поля “Number” внутри небольшого прямоугольника. Он состоит из номера документа, за которым следует буква, идентифицирующая лист внутри документа.

C. 5 Хранение файлов

Каждый официально назначенный участник проекта ведет досье полученных документов «Читатель/Разработчик». Библиотекарь должен отслеживать официальные основные и справочные файлы проекта, архивируя каждый Комплект, представленный в ходе проекта.

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

  • Стандартный Комплект Файлов
    Обрабатывается разработчиками, комментаторами и, возможно, читателями. Титульные листы комплекта файлов в хронологическом порядке, как главный журнал, но извлекают и хранят большинство C-страниц в соответствующих моделях в порядке ссылок на узлы. Если вы сомневаетесь, оставьте лист в поданном Комплекте, возможно, добавив перекрестные ссылки на Примечания читателя на уже подшитых формах диаграмм в выбранных других местах подачи. (Каждый лист является собственностью читателя, и нумерация заметок читателя перезапускается заново для каждого листа с номером С, поэтому добавленные личные примечания читателя не могут причинить никакого вреда.)
  • Обновленные файлы текущей модели:
    Обрабатываются разработчиками, комментаторами и читателями из полученных Обновленных Комплектов. Может быть отдано предпочтение версиям Project Master по мере развития проекта.
  • чиеРабо файлы:
    Обрабатываются разработчиками и любым читателем, который инициирует специальный обмен между участниками, не имеющими официального назначенного разработчика. Титульный лист Комплекта для темы, начинаемой читателем, должен иметь предлагаемое название, чтобы упорядочение содержания комплекта в алфавитном порядке соответствовало официальным рабочим файлам моделей и т. Д.
  • Файлы проекта:
    Обрабатываются библиотекарем в соответствии со стандартами, установленными руководством проекта.

C. 6 Процедура обзора модели IDEF

В дополнение к Циклу комплектов была разработана пошаговая процедура в качестве руководства для представления информации о модели группе «рецензентов» (возможно, не имеющих опыта самостоятельного анализа моделей IDEF0 ). Она не заменяет процесс обзора цикла «Читатель/Разработчик», который является центральным для обеспечения качества моделирования IDEF0 (поясняется в C.2), но может быть полезна при периодическом использовании проекта на техническом уровне, чтобы предоставить возможность всем участникам обмениваться или разрабатывать общие интерпретации, которые могут не проявляться в индивидуальных обменах на основе Комплекта.

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

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

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

Шаг 1: Сканирование диаграммы.

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

Критерии принятия:

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

Если проблема недостаточно очевидна, критический разбор может быть отложен до следующего шага 3. Однако первое впечатление должно быть сформировано. Проблемы могут быть указаны на магнитно-маркерной доске пока не будут решены

Шаг 2: Анализ родителя.

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

Критерии принятия:

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

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

Шаг 3: Объедините родительский блок и детализированную диаграмму.

На этом шаге проверяются подсоединения стрелок интерфейса от родителя к дочерним элементам.

Критерии принятия:

  1. Нет ни пропущенных, ни лишних стрелок интерфейса.
  2. Граничные стрелки помечены соответствующими кодами ICOM.
  3. Метки дочерних стрелок это то же самое, что и метки со стрелками родителей. Метки передают правильное и полное содержание стрелок.
  4. Изучение соединительных стрелок не выявило никаких проблем в родительской диаграмме. (Добавленный интерфейс может привести к неправильному пониманию сообщения, переданного родителем).

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

Шаг 4: Проанализируйте шаблон внутренней стрелки.

Шаблон из блока и стрелок является основным представлением создаваемой модели.

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

Критерии принятия:

  1. Диаграмма не выглядит загроможденной. Количество пересечений и изгибов стрелок сведено к минимуму.
  2. Блоки сбалансированы с учетом деталей. В каждом блоке должно быть одинаковое количество деталей. Однако компромиссы по этому критерию приемлемы ради ясности.
  3. Диаграмма должна соответствовать опыту и знаниям рецензента в данной области. Обратная связь и условия возникновения ошибок должны быть показаны так, как понятно рецензенту.
  4. Уровень детализации стрелок должен соответствовать уровню детализации блоков. Следует рассмотреть возможность объединения стрелок в более общие стрелки.

Шаг 5: Ознакомьтесь со вспомогательной документацией.

На этом этапе рассматриваются вопросы, которые разработчик выделил в тексте, глоссарии и диаграмме-иллюстрации FEO.

Критерии принятия:

  1. Текст подтверждает интерпретацию, полученную при изучении самой диаграммы.
  2. Нормальные пути, обратная связь, обработка ошибок и другие функции, предлагаемые текстом, находятся на диаграмме или в диаграмме FEO (только для экспозиции).
  3. Существенные особенности диаграммы, выявленные на этапах 1-4, отражены в тексте, глоссарии или FEO.
  4. Ссылки на диаграмму достаточно подробны, чтобы связать текст, глоссарий или FEO с конкретными частями диаграммы.

Шаг 6: Установите статус диаграммы.

Установите состояние диаграммы (как определено ранее) на:

  • Рабочий
  • Проект
  • Рекомендуемый
  • Публикация

Приложение D Информативные определения

Этот раздел содержит определения, относящиеся к нормативным разделам настоящего документа. Определения нормативных разделов приведены в Разделе 2. Термин, если он определен, указан в Разделе 2 или в Приложении D, но не в обоих местах одновременно.

D.1 Уровень утверждения:

одно из следующих четырех состояний, присвоенных модели IDEF для обозначения степени рассмотрения и утверждения:

D.2 Разработчик (Автор):

лицо, которое разрабатывает и несет ответственность за любую конкретную модель IDEF или диаграмму.

D.3 Кластеризация:

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

D.4 Комментатор:

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

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

D. 5 Проект:

см. Уровень утверждения.

D.6 Эксперт:

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

D.7 Роль IDEF:

Должность в проекте IDEF. См. термины разработчик, эксперт, комментатор, читатель и библиотекарь.

D.8 Комплект:

Стандартизированный пакет диаграмм, содержащий части или законченные современные модели, подлежащие обзору. Смотрите Цикл Комплекта.

D.9 Титульный лист комплекта:

Специальная форма, используемая для контроля маршрутизации комплекта через Цикл комплекта.

G.10 Цикл комплекта:

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

D.11 Библиотекарь:

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

D.12 Поле проекта:

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

D. 13 Публикация:

см. Уровень одобрения.

D.14 Читатель:

человек с (ограниченной) подготовкой в технике IDEF, достаточной для точной интерпретации синтаксиса и основных значений, а также для чтения и записи примечаний читателя, который рассматривает часть или всю модель.

D.15 Цикл Читатель / Разработчик:

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

D.16 Примечание читателя:

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

D. 17 Рекомендуется:

См. Уровень утверждения.

D.18 Рецензент:

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

D.19 Разделение:

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

D. 20 Роль:

Тоже самое, что и роль IDEF.

D. 21 Работа:

см. Уровень одобрения.

Источник

IDEF0 (Integrated Definition) — язык проектирования функциональных моделей, включает как сам язык моделирования, так и методологию для построения и интерпретации моделей. IDEF0 является одной из первых нотаций для моделирования бизнес-процессов, которая возникла в американской аэрокосмической промышленности в 1970-ых годах.

IDEF0 — основные характеристики

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

Модель процесса в диаграмме IDF0

Модель процесса в диаграмме IDF0

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

Основной принцип моделирования в нотации IDEF0 указывает, что между функциями, которые входят в различные подсистемы, должно быть как можно меньшей связей. На одном уровне должно быть не меньше 5 и не больше 3 функций.

Диаграммы IDEF0 читают сверху вниз и слева направо. Все базовые элементы основаны на простых символах:

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

Синтаксическая модель IDF0

Синтаксическая модель IDF0

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

Сторона прямоугольника Стрелка Значение

верхняя

стрелка управления

правила, процедуры, стандарты, методы контроля

левая

стрелка входа

материал или данные

правая 

стрелка выхода

данные и материальные объекты, преобразованные функцией

нижняя

стрелка механизма

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

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

Другие правила синтаксиса

  • блок должен полностью вмещать название;

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

  • блоки должны быть нарисованы сплошными линиями;

  • изгиб стрелок должен составлять 90°;

  • сегменты стрелок должны быть отрисованы сплошными линиями;

  • нельзя рисовать стрелки по диагонали;

  • стрелки не должны пересекать границы блока;

  • стрелки нельзя присоединять к углам блока;

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

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

Виды диаграмм

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

Пример диаграммы верхнего уровня A0 в нотации IDF0

Пример диаграммы верхнего уровня A0 в нотации IDF0

Иерархия типов функций

  • деятельность — совокупность всех процессов организации;
  • бизнес-процесс — совокупность логически связанных операций;
  • операция — совокупность последовательных или параллельных действий внутри определенного потока;
  • действие— преобразование свойств какого-либо объекта.

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

Основные характеристики IDF0

  • высокий уровень детализации любых типов процессов;

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

  • упор на иерархическое отображение элементов;

  • может быть воссоздана на программном уровне.

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

Для чего используется

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

  • широко применяется в США при автоматизации машинного производства и до сих пор является частью стандарта FIPS (Federal Information Processing Standard);

  • применяется для имплементации методологий непрерывного улучшения, таких как Strategic Justification of Integrated Enterprise Technologies (SJET) и Perform Continuous Enterprise Improvement (PCEI);

  • в литературе можно найти пример описания процесса разработки стратегии на языке IDEF0.

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

Преимущества

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

  • возможность отобразить взаимосвязи между различными уровнями системы;

  • популярность среди аналитиков;

  • большое количество документации на английском языке;

  • подходит для презентаций руководству;

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

Недостатки

  • крупные производители софта постепенно отказываются от поддержки данной нотации;

  • диаграммы могут выглядеть перегруженными и визуально непривлекательными;

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

  • требует определенных навыков для адекватного проектирования диаграмм;

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

BPMN vs IDEF0

Хотя IDEF0 иногда используют для моделирования бизнес-процессов, эта нотация задумывалась как средство моделирования взаимодействия бизнес-функций, не обязательно в процессном контексте. Стрелка в BPMN показывает точную последовательность выполнения шагов процесса, а в IDEF0 стрелки входов-выходов не обязаны отображать эту последовательность. Кроме того, BPMN содержит XML-описание элементов, что значительно упрощает имплементацию на программном уровне. В отличие от IDEF0, BPMN разрабатывалась с прицелом на автоматизацию бизнес-процессов, поэтому многие элементы нотации показывают именно машинные способы передачи и обработки данных. Нотация нашла широкое применение в BPMS, ERP, CRM, SRM и других информационных системах.

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

Верхнеуровневая диаграмма в Comindware Business Application Platform

Верхнеуровневая диаграмма в Comindware Business Application Platform

Comindware Business Application Platform исправляет этот недостаток BPMN за счет конструктора для проектирования исполняемой архитектуры предприятия. Конструктор визуализирует связи между бизнес-процессами, ресурсами и способностями предприятия, не уступая по точности IDEF0. Инструмент можно использовать для создания иерархических моделей с несколькими уровнями вложений.

Ознакомьтесь с возможностями по построению процессной архитектуры в Comindware Business Application Platform

Заказать демо

Елена Гайдукова, маркетолог-аналитик. Работает в сфере BPM и автоматизации процессов с 2014 года. В настоящее время является бренд-менеджером решений на базе Comindware Business Application Platform.

Источник

Методология IDEF0 — методология описания бизнес-процессов с помощью функциональных диаграмм. Отличается широким спектром использования. Применяется практически во всех отраслях экономики, независимо от размера предприятия и производимых процессов. Позволяет детально описать процессы.

Методология IDEF0 берет своё начало в 60-х годах. Разработана известным американским ученым Дуглас России в США. В настоящее время методология IDEF0 является фундаментальной, занимает ведущую позицию. Рассмотрим более подробно ее назначение и особенности.

Несколько слов о преимуществах графики

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

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

Изображение бизнес-процесса в графическом виде

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

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

Что такое нотация описания бизнес-процессов

Нотация описание бизнес-процессов — графическое исполнение бизнес-процесса, его описание с помощью графических элементов для наиболее простого восприятия.

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

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

По аналогии с языками программирования, нотации называют языками моделирования бизнес-процессов, являются общепризнанными и понятными для всех.
Сегодня в мире наиболее популярны 3 нотации:

  • IDEF0;
  • EPC;
  • BPMN.

Наиболее популярная нотация моделирования бизнес-процессов, основанная на методологии структурного анализа SADT.

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

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

Idef0 блоки

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

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

Назначение и состав методологии

Методология IDEF0 получила свою популярность и широкое применение благодаря простому графическому исполнению и простоте восприятия.

Методология IDEF0 описания бизнес-процессов заключается в описании действий с помощью диаграмм.

Описание бизнеса-процессов происходит быстро и очень понятно. Главные составляющие — диаграммы.

Выделяют четыре типа диаграмм:

  • контекстная;
  • диаграмма декомпозиции;
  • диаграмма дерева узлов;
  • диаграмма только для экспозиции.

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

Диаграммами декомпозиции — считаются второстепенными или дочерними. Описывают составные части основной функции.

Диаграмма дерева узлов — выражает зависимость функций между собой.

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

Элементы графической нотации

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

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

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

  • Деятельность;
  • Процесс;
  • Операция;
  • Действие.

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

  • Вход;
  • Управление;
  • Механизм;
  • Выход;
  • Вызов.

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

Типы связей между функциями

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

Маркетолог предприниматель

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

Выделяют несколько типов связей:

  • Иерархическая
  • Регламентирующая связь
  • Функциональная
  • Потребительская
  • Логическая
  • Коллегиальная
  • Ресурсная
  • Информационная
  • Временная
  • Случайная.

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

Плюсы и минусы

Преимущества IDEF0:

  • Главным преимуществом методологии IDEF0 является полнота описания бизнес-процесса. Описание с помощью диаграмм (главных и второстепенных) позволяется точно описать все процессы, и указать множество взаимосвязей между ними и с внешней средой;
  • Жесткие требования к изложению информации. Это приводит к стандартизации бизнес-процессов.

Недостатки IDEF0:

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

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

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

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

Облегчить чтение модели возможно, если придерживаться определенны правил создания диаграмм IDEF0. Вот некоторые из них:

  • Первостепенно определить для себя цель бизнес-процесса. Необходимо определить тип формируемой модели, а также позицию, с точки зрения которой будет строиться модель.
  • При разработке моделей следует избегать изначальной «привязки» функций исследуемой системы к существующей организационной структуре моделируемого объекта (предприятия, фирмы).
  • На контекстной диаграмме отображается один блок, показывающий назначение системы. Для него рекомендуется отображать по 2–4 стрелки, входящие и выходящие с каждой стороны.
  • Количество блоков на диаграммах декомпозиции рекомендуется в пределах 3–6.
  • Блоки на диаграмме декомпозиции следует располагать слева направо и сверху вниз.
  • Отсутствие у функции одновременно стрелок управления и входа не допускается.
  • Обеспечить каждому блоку свой вход.
  • Постараться как можно меньше допустить поворотов в диаграмме и петель.
  • Используйте обратные дуги для изображения обратных связей.
  • Поименуйте каждый элемент диаграммы.
  • Использовать туннелирование стрелок.
  • Объединить стрелки, проходящие параллельно и дать им единое имя.
  • Нумерация блоков.

Типичные ошибки

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

Рассмотрим типичные ошибки:

  1. Использование различных цветов — не стоит пытать выделить отдельные элементы цветами, чтобы повысить наглядность. Все элементы одинаково важны.
  2. Слишком большое количество блоков — нельзя изобразить все нюансы процесса на одном листе. Для конкретизации деятельности необходимо применить детализацию каждого блока.
  3. Нарушение структуры при внесении корректировок — при внесении каких-либо изменений, например смены точки зрения, следите за тем, чтобы не возникло путаницы или процессов без входящих, исходящих и других важных элементов.
  4. Правила названия управляющих элементов и блоков — называйте стрелки именами, а блоки глаголами.

Программное обеспечение для построения диаграмм IDEF0

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

К сегодняшнему дню создано не мало программ для создания диаграмм IDEF0. Вот некоторые из них:

  • ERWin 3.5.2;
  • Design/ IDEF;
  • Dia;
  • IDEF0/EMTool;
  • BPwin.

Пример создания функциональной модели IDEF0

Рассмотрим процесс написания статьи для наглядного описания создания функциональной модели IDEF0

Основной блок называется «Написать статью».Пример создания функциональной модели IDEF0

Взаимодействие с внешней средой обозначены на схеме входящими стрелками – «Знания в области написания статьи», «Опыт», «Информация из сторонних источников». Основы, которые необходимы для описания.

Управляющие в данном случае – это «План публикации», «Требования издателя», «Правила русского языка».

А в роли «Механизмов» выступают автор, копирайтер, корректор и программное обеспечение.

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

На самом деле, процесс создания статьи, как и любой бизнес-процесс можно и нужно детализировать.

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

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



Источник

Цель работы:

  • изучение основных принципов методологии IDEF0,
  • создание нового проекта в BPWin,
  • формирование контекстной диаграммы,
  • проведение связей.

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

Методология IDEF0 предписывает построение иерархической системы диаграмм — единичных описаний фрагментов системы. Сначала проводит­ся описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная деком­позиция — система разбивается на подсистемы и каждая подсистема опи­сывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности.

Каждая IDEF0-диаграмм а содержит блоки и дуги. Блоки изображают функции моделируемой системы. Дуги связывают блоки вместе и отобра­жают взаимодействия и взаимосвязи между ними.

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

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

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

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

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

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

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

Типы стрелок

В IDEF0 различают пять типов стрелок.

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

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

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

Механизм — ресурсы, выполняющие работу. Стрелка механизма рисуется как входящая в нижнюю грань работы. По усмотрению аналитика стрелки механизма могут не изображаться на модели.

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

Статья 17 - Картинка 1

Рис. 2.1Типы стрелок

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

Статья 17 - Картинка 2

Рис. 2.2. Связь по выходу

Статья 17 - Картинка 3

Рис. 2.3. Связь по управлению

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

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

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

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

Статья 17 - Картинка 4

Рис. 2.4. Обратная связь по входу

Статья 17 - Картинка 5

Рис. 2.5. Обратная связь по управлению

Связи «выход-механизм» характерны при распределении источников ресурсов (например, требуемые инструменты, обученный персонал, физическое пространство, оборудование, финансирование, материалы).

В IDEF0 дуга редко изображает один объект. Обычно она символизирует набор объектов. Так как дуги представляют наборы объектов, они могут иметь множество начальных точек (источников) и конечных точек (назначений). Поэтому дуги могут разветвляться и соединяться различными способами. Вся дуга или ее часть может выходить из одного или нескольких блоков и заканчиваться в одном или нескольких блоках.

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

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

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

Статья 17 - Картинка 6

Рис. 2.6. Связь выход-механизм

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

Количественный анализ диаграмм

Для проведения количественного анализа диаграмм перечислим показатели модели:

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

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

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

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

Статья 17 - Картинка 7

Рис. 2.7. Пример несбалансированной диаграммы

Введем коэффициент сбалансированности диаграммы

Статья 17 - Картинка 8

Необходимо стремиться, чтобы Кь был минимален для диаграммы.

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

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

Инструментарий BPWin

При запуске BPWin по умолчанию появляется основная панель инструментов, палитра инструментов и Model Explorer.

При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново, или она будет открыта из репозитария ModelMart, внести имя модели и выбрать методологию, в которой будет построена модель (рис. 2.8).

Статья 17 - Картинка 9

Рис.2.8 Диалог создания модели

BPWin поддерживает три методологии — IDEF0, IDEF3 и DFD. В BPWin возможно построение смешанных моделей, т. е. модель может содержать одновременно как диаграммы IDEF0, так и IDEF3 и DFD. Состав палитры инструментов изменяется автоматически, когда происходит переключение с одной нотации на другую.

Модель в BPWin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется всплывающее контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта.

Пример

Построение модели системы должно начинаться с изучения всех документов, описывающих ее функциональные возможности. Одним из таких документов является техническое задание, а именно разделы «Назначение разработки», «Цели и задачи системы» и «Функциональные характеристики системы«.

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

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

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

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

Контекстная диаграмма

Таким образом, определим контекстную диаграмму системы (рис. 2.9).

Статья 17 - Картинка 10

Рис 2.9.Контекстная диаграмма системы

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

  • Определение уровня доступа в систему.
  • Выбор подсистемы.
  • Обращение к подсистеме.
  • Изменение БД (при необходимости).

Получим диаграмму, изображенную на рис. 2.10.

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

Статья 17 - Картинка 11

Рис. 2.10. Декомпозиция работы «Обслуживание, клиента системы»

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

Статья 17 - Картинка 12

Рис. 2.11. Декомпозиция работы «Определение уровня доступав систему»

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

Декомпозируем работу «Обработка запроса клиента», выполняемую подсистемой обработки запросов, определения категорий и полномочий пользователей. Перед осуществлением поиска ответа на запрос необходимо открыть БД (подключиться к ней). В общем случае БД может находиться на удаленном сервере, поэтому может потребоваться установление соединения с ней. Определим последовательность работ:

  • Открытие БД.
  • Выполнение запроса.
  • Генерация отчетов.

После открытия БД необходимо сообщить системе об установлении соединения с БД, после чего выполнить запрос и сгенерировать отчеты для пользователя (рис. 2.12).

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

Статья 17 - Картинка 13

Рис. 2.12. Декомпозиция работы «Обработка запроса клиента»

Корректировка диаграммы

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

Скорректируем диаграмму, добавив в нее стрелки «Шаблоны отчетов» и «Запросы на изменение БД» и туннельную стрелку «Клиент системы». Туннелирование «Клиента системы» применено для того, чтобы не выносить стрелку на диаграмму верхнего, так как функция выбора формы отчета не является достаточно важной для отображения ее на родительской диаграмме.

Изменение диаграммы потянет за собой корректировку всех родительских диаграмм (рис. 2.13 — 2.15).

Декомпозицию работы «Выполнение запроса» целесообразно провести при помощи диаграммы DFD (лабораторная работа № 3), так как методология IDEF0 рассматривает систему как совокупность взаимосвязанных работ, что плохо отражает процессы обработки информации.

Статья 17 - Картинка 14

Рис. 2.13. Декомпозиция работы «Обработка запроса клиента»

Статья 17 - Картинка 15

Рис. 2.14. Декомпозиция работы «Обслуживание клиента системы»(вариант 2)

Статья 17 - Картинка 16

Рис. 2.15. Контекстная диаграмма системы (вариант 2)

Перейдем к декомпозиции последнего блока «Изменение БД». С точки зрения клиента, данные системы располагаются в одной БД. Реально в системе присутствует шесть БД:

  • БД пользователей,
  • БД студентов,(вариант 2)
  • БД вакансий,
  • БД успеваемости,
  • БД тестов,
  • БД экспертных оценок,
  • БД резюме.

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

  • Определяется БД, в которой будет изменяться информация.
  • Оператором формируется временный набор данных и предоставляется администратору.
  • Администратор осуществляет контроль данных и вносит их в БД.

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

Статья 17 - Картинка 17

Рис. 2.16. Декомпозиция работы «Изменение БД»

Статья 17 - Картинка 18

Рис. 2.17. Декомпозиция работы «Изменение БД» (вариант 2) Для первого варианта, изображенного нарис. 2.12

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

Декомпозиция работы «Выполнение запроса» будет проведена в следующей лабораторной работе, иллюстрируя применение диаграмм DFD для описания процессов обработки информации.

Проведем количественный анализ моделей, изображенных на рис. 2.12 и 2.13, согласно вышеописанной методике. Рассмотрим поведение коэффициента ^ у этих моделей. У родительской диаграммы «Обработка запроса клиента» коэффициент равен 4/2 = 2, а диаграммы декомпозиции 3/3 = 1. Значение коэффициента убывает, что говорит об упрощении описания функций с понижением уровня модели.

Рассмотрим изменение коэффициента Кb у двух вариантов моделей.

Статья 17 - Картинка 19

для второго варианта

Статья 17 - Картинка 20

Коэффициент Кb не меняет своего значения, следовательно, сбалансированность диаграммы не меняется.

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

Подводя итоги рассмотренного примера необходимо отметить важность рассмотрения нескольких вариантов диаграмм при моделировании системы. Такие варианты могут возникать при корректировке диаграмм, как это было сделано с «Обработкой запроса клиента» или при создании альтернативных реализаций функций системы (декомпозиция работы «Изменение БД»). Рассмотрение вариантов позволяет выбрать наилучший и включить его в пакет диаграмм для дальнейшего рассмотрения.

Контрольные вопросы

Список Контрольных вопросов:

  1. Что представляет собой модель в нотации IDEF0?
  2. Что обозначают работы в IDEF0?
  3. Назовите порядок наименования работ?
  4. Какое количество работ должно присутствовать на одной диаграмме?
  5. Что называется порядком доминирования?
  6. Как располагаются работы по принципу доминирования?
  7. Каково назначение сторон прямоугольников работ на диаграммах?
  8. Перечислите типы стрелок.
  9. Назовите виды взаимосвязей.
  10. Что называется граничными стрелками?
  11. Объясните принцип именования разветвляющихся и сливающихся стрелок.
  12. Какие методологии поддерживаются BPWin?
  13. Перечислите основные элементы главного окна BPWin.
  14. Опишите процесс создания новой модели в BPWin.
  15. Как провести связь между работами?
  16. Как задать имя работы.
  17. Опишите процесс декомпозиции работы.
  18. Как добавить работу на диаграмму?
  19. Как разрешить туннелированные стрелки?
  20. Может ли модель BPWin содержать диаграммы нескольких методологий?
Источник

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

Контекстная диаграмма. Самая верхняя
диаграмма, на которой объект моделирования
представлен единственным блоком с
граничными стрелками. Эта диаграмма
называется A-0 (А минус нуль). Стрелки на
этой диаграмме отображают связи объекта
моделирования с окружающей средой.
Диаграмма A-0 устанавливает область
моделирования и ее границу. Пример
диаграммы A-0 (Рис.8):

Рис.8. Диаграмма A-0 нотации IDEF0

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

Доминирование. Блоки IDEF0 на
неконтекстной диаграмме должны
располагаться по диагонали – от левого
верхнего угла диаграммы до правого
нижнего в порядке присвоенных номеров.
Блоки на диаграмме, расположенные вверху
слева, «доминируют» над блоками,
расположенными внизу справа. «Доминирование»
понимается как влияние, которое блок
оказывает на другие блоки диаграммы.
Расположение блоков на листе диаграммы
отражает авторское понимание доминирования.
Таким образом, топология диаграммы
показывает, какие функции оказывают
большее влияние на остальные.

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

Используемые
графические символы

Название

Графический
символ

Описание

Процесс

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

Стрелка

Стрелки обозначают
входящие и исходящие из процесса
объекты (данные).

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

Туннелированная
стрелка

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

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

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

Внешняя ссылка

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

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

Междиаграммная
ссылка

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

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

Процесс-ссылка

Элемент обозначает
ссылку на процесс, описанный в другой
модели.

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

Параметры
типового процесса заполняются
непосредственно в свойствах типового
процесса.

Постоянный
список субъектов, принимающих участие
в выполнении типового процесса,
формируется также в свойствах типового
процесса. Список субъектов, принимающих
участие при выполнении типового
процесса в рамках вышележащего
процесса, формируется в свойствах
процесса-ссылки на типовой процесс.

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

Сноска

Выносной элемент,
предназначенный для нанесения
комментариев.

Элемент может
быть использован на диаграммах
процессов в любых нотациях.

Текст

Комментарий без
сноски.

Элемент может
быть использован на диаграммах
процессов в любых нотациях.

Информация о способах добавления
элементов на диаграмму содержится в
Руководстве пользователя (глава 4
«Создание модели бизнес-процессов в
Business Studio»).

Пример диаграммы процесса в нотации
IDEF0 (Рис.9):

Рис.9. Диаграмма процесса нотации
IDEF0

Подробнее с правилами создания диаграммы
нотации IDEF0 можно познакомиться в
источниках [1], [2].

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
Источник

Понравилась статья? Поделить с друзьями:

А вот и еще наши интересные статьи:

  • Автор руководства по острым детским инфекциям
  • Морская вода с алоэ консумед инструкция
  • Lionelo sven plus инструкция на русском
  • Prostate support инструкция по применению отзывы
  • Lg fl r900k инструкция на русском языке

    • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии