Аис1

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

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

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

объекты, которые участвуют при выполнении сценария;

роли, которые выполняют эти объекты (например, агент, транспорт и т.д.);

отношения между работами в ходе выполнения сценария процесса;

состояния и изменения, которым подвергаются объекты;

время выполнения и контрольные точки синхронизации работ;

ресурсы, которые необходимы для выполнения работ.

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

позволяют:

записывать в терминах системного анализа сырые данные, полученные в ходе интервью.

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

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

управлять конфигурацией данных и изменять правила контроля.

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

создавать имитационные модели.

Стандарт IDEF3, IDEF3-диаграмма

91

СТАНДАРТ IDEF3

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

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

IDEF3 рассматривает поведенческие аспекты существующих или проектируемых систем. Знания о процессах структурированы в виде контекстных сценариев, что делает IDEF3 удобным инструментом сбора данных для описания системы. IDEF3 аккумулирует в себе временные зависимости и связи между процессами, происходящими на предприятии. В результате создается структурированная база знаний для построения аналитических и проектировочных моделей. В отличие от других языков моделирования (таких, как SIMAN, SLAM, GPSS, WITNESS), которые строят прогностические математические модели, IDEF3 позволяет создавать структурные описания. Эти описания содержат информацию о том, что на самом деле происходит или будет происходить в системе, а также отражают точки зрения различных пользователей.

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

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

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

анализировать существующие процессы и разрабатывать новые;

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

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

содействовать принятию оптимальных решений при реорганизации процессов;

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

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

IDEF3-ДИАГРАММА

IDEF3-ДИАГРАММА (диаграмма потока, process flow diagram, IDEF3-diagram, workflow) -

основная единица описания в IDEF3, являющаяся графическим представлением назначения системы или процесса и применяются для анализа завершенности процесса обработки информации (проверка модели ИС на целостность). Обычно IDEF3-диаграммы являются

92

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

Сценарии, IDEF3-диаграмма сценария

93

СЦЕНАРИЙ

СЦЕНАРИЙ (Scenario) - описание последовательности изменений свойств объекта, в рамках рассматриваемого процесса (например, описание последовательности этапов обработки детали в цеху и изменение её свойств после прохождения каждого этапа). Метод IDEF3 использует сценарии для упрощения структуры описаний сложного многоэтапного процесса. Сценарии определяют граничные условия описания и представляют собой повторяющуюся по-следовательность ситуаций или действий, которые описывают типичный класс проблем, при-сутствующих в организации или системе, описание последовательности изменений свойств объекта, в рамках рассматриваемого процесса (например, описание последовательности обработки менеджером заявки). Использование сценариев упрощает структуру описаний сложного многоэтапного процесса.

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

IDEF3-ДИАГРАММА СЦЕНАРИЯ

IDEF3-ДИАГРАММА СЦЕНАРИЯ (scenario diagram) -- это специфический вид диаграммы, которая создается для иллюстрации сценария типа what if – «что будет, если» для декомпози-ционных IDEF3-диаграмм. Для сценария номер декомпозиции всегда больше единицы.

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

Создание сценариев путем декомпозиции IDEF3-диаграммы должно производиться при непосредственном участии автора и экспертов в предметной области. Алгоритм совместной работы имеет вид:

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

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

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

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

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

94

информации.

PFDD и OSTN диаграммы

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

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

process-centered strategy – стратегия описания процесса как последовательности выпол--няемых действий. Диаграммы этого типа получили название Process Flow Description Dia-grams (PFDD) – диаграммы потокового описания последовательности выполнения этапов процесса "с точки зрения наблюдателя". Поток процессов содержит знания о том, «как это происходит» в организации, т.е. описание того, что происходит с изделием, когда оно проходит через этапы производственного процесса. Диаграммы PFDD описывают процесс, фиксируют весь временный, старшинство, и информация отношений причинно-следственной связи относительно набора процессов в технологическом маршруте. Ключевыми понятиями диаграммы Описания Последовательности Действий являются понятия,

процесс и логика процесса;

object-centered strategy - стратегия описания процесса как последовательности изменений состояний объекта, над которым выполняются действия. Диаграммы такого типа получили название Object State Transition Network (OSTN) – диаграммы последовательности измене-ний состояний объекта и его трансформаций процессом. OSTN позволяет рассматривать процесс "с точки зрения объекта" и используются для иллюстрации трансформаций объекта, которые происходят на каждой стадии выполнения соответствующих UOW. Объектные сети изменений состояния фиксируют центрированные объектом представления процессов, суммируя допустимые изменения состояния, которым объекты могут подвергнуться повсюду специфического технологического маршрута. Сеть описания изменений состояния объектов рассматривает возможные изменения, которые происходят с объектами в ходе отдельного процесса, поэтому ключевыми понятиями OSTN диаграммы являются состояние объекта и изменение состояния.

Описание процесса в IDEF3 может содержать диаграммы PFDD и OSTN или диаграммы какого-либо одного типа.

PFDD-диаграммы

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

95

устанавливает ориентацию и границы описания.

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

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

Ссылка

ССЫЛКА (Referents, ссылка, объект ссылки). Ссылка на диаграмме IDEF3 является особым объектом, предназначенным для отображения некоей идеи, концепции или данных, которые не могут быть непосредственно связаны с функцией, стрелкой, перекрестком или UOW (рис. 1). Ссылки расширяют границы понимания диаграммы и упрощают конструкцию описания (тем самым исключают неоднозначность). Ссылкой могут быть дополнительные факты, ограничения или какие-то логические построения, которые позволяют произвести дополнительное описание действия функции. Ссылки расширяют границы понимания диаграммы и упрощают конструкцию описания (тем самым исключают неоднозначность).

Ссылки предназначены для:

обращения к предварительно определенному функциональному элементу UOW, без дублирования его определения;

передачи управления или организации возвратных циклов при выполнении процесса;

организации связи между диаграммами описания процесса PFDD и OSTN

объектными диа-граммами.

Согласно нотации IDEF3 могут применяться ссылки трех видов: unconditional - безусловные, synchronous - синхронные, asynchronous - асинхронные.

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

Каждый из представленных видов ссылки может быть типа «UOB», «SCENARIO», «TS» или «GO TO». Очевидно, что ссылки типа UOB ссылаются на функциональный модуль «UOB», типа «SCENARIO» ссылаются на соответствующий сценарий, типа «TS» (Transition Schematic) – на соответствующую схему, типа «GO TO» - на любой из структурных элементов IDEF3: функциональный модуль, сценарий или узел. При этом, в основном поле символа ссылки указывается её тип и через дробь уникальное наименование блока, сценария, схемы или функции узла. В поле «Locator» указывается уникальный номер идентификатор элемента, указанного в ссылке. Пример использования ссылок показан на рисунке 2.

96

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

ELAB (elaboration) - используется для усовершенствования графиков или их более детального описания. Обычно употребляется для детального описания разветвления и слияния стрелок на перекрестках.

Помимо деления на виды, методология IDEF3 определяет два вида ссылок по способу запуска. На Рис 2 представлены их условные обозначения. Использование ссылки «Вызвать и продолжить» (Call and Continue Referent) указывает, что элемент, указанный в ссылке, должен быть активизирован до завершения выполнения действия модулем, к которому относится ссылка. Использование ссылки «Вызвать и ждать» (Call and Wait Referent), указывает, что элемент, указанный в ссылке, должен начать и закончить выполнение действия до завершения действия модулем, к которому относится ссылка.

Разделение на ссылку "Запустить и продолжить" и "Запустить и ждать" позволяет описать временные границы выполнения ссылки. Так использование ссылки "Запустить и продолжить" указывает, что упомянутый элемент ссылки должен лишь инициализироваться (активизироваться) раньше, чем выполнение элемента IDEF3, вызывающего элемент ссылку, будет завершено. Для такой ситуации возможно развитие событий представлено на Рис 3.

Использование ссылки "Запустить и ждать" указывает, что упомянутая ссылка должна и активизироваться и завершиться прежде, чем элемент его вызвавший завершит свое выполнение. Если используется ссылка "Запустить и продолжить", которая имеет тип UOW, SCENARIO или GO-TO, то на выходе такого элемента не может использоваться стрелка старшинства. Это утверждение становиться очевидным, если изучить график запуска на Рис. 5. 23.

При использовании после Ссылки "Запустить и продолжить" стрелки старшинства получаем неопределенную, непоследовательную и противоречивую ситуацию. Существует противоречие в совместном использовании ссылки "Запустить и продолжить" и стрелки старшинства.

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

Если используется ссылку типа Scenario, то соответственно его название должно совпа-

98

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

Если тип ссылки UOW или SCENARIO, то такой элемент может являться источником для связи старшинства. Другой особенностью ссылки "Запустить и Ждать" является невозможность использования GO-TO ссылки.

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

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

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

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

UOB или UOW

UOB (Unit Of Behavior, единица поведения) или UOW (Unit Of Work, activity, единица работы)

99

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

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

просто выписать требование;

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

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

На IDEF3-диаграммах UOW изображаются прямоугольниками с прямыми углами и имеют идентифицирующие их атрибуты, расположенные в специальных полях, как

показано на рисун-ке 5:

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

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

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

OBJECTS (объекты) - часть документа, в котором перечислены физические объекты, являющиеся составной частью UOW. Описания объектов UOW позволяет определить, когда объект: является агентом, а не процессом; изменяется в результате процесса; участвует в процессе без влияния на него или создается/удаляется в процессе. Например, объектами редуктора являются: верхняя и нижняя крышка редуктора, тихоходный и быстроходный валы, крышки подшипников, уплотнитель-ные детали, резьбовые детали и т.д.;

FACTS (факты) - часть документа, в котором перечислены сведения о UOW или объектах, входящих в UOW, включая их свойства, и отношения, которые существуют или создаются во время моделируемого процесса. Факты UOW могут также содержать такие свойства, как длительность, частота и или стоимость процесса. Например, «наличие ОС Windows, MS Office»

DESCRIPTION (описание) - часть документа, в котором содержится дополнительное текстовое описание UOW, которое впоследствии будет использоваться в глоссарии

100