Применения нотаций IDEF0 и IDEF3 для моделирования бизнес-процессов. Диаграммы IDEF3

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

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

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

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

Рис.3.1 Описание процесса в методологии IDEF3

Синтаксис и семантика моделей IDEF3

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

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

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

Диаграммы

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

Единица работы. Действие

Аналогично другим технологиям моделирования действие, или в терминах IDEF3 «единица работы» (Unit of Work - UOW), - другой важный компонент модели. Диаграммы IDEF3 отображают действие в виде прямоугольника. Как уже отмечалось, действия именуются с использованием глаголов или отглагольных существительных, каж­дому из действий присваивается уникальный идентификационный номер. Этот номер не используется вновь даже в том случае, если в процессе построения модели действие удаляется. В диаграммах IDEF3 номер действия обычно предваряется номером его родителя (рис. 3.2)

Рис. 3.2. Изображение и нумерация действия в диаграмме IDEF3

Связи

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

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

Изобра­жение	Название	Назначение
	Временнбе предшест­вование (Temporal pre­cedence)	Исходное действие должно завершить­ся, прежде чем конечное действие смо­жет начаться
	Объектный поток (Object flow)	Выход исходного действия является входом конечного действия. Из этого, в частности, следует, что исходное действие должно завершиться, прежде чем конечное действие сможет начаться
	Нечеткое отношение (Relationship)	Вид взаимодействия между исходным и конечным действиями задается анали­тиком отдельно для каждого случая ис­пользования такого отношения

Таблица 2.1

Рис. 3.3. Связь типа “временное предшествование” между действиями 1 и 2.

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

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

Соединения

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

• разворачивающие соединения используются для разбиения пото­ка. Завершение одного действия вызывает начало выполнения не­скольких других;
• сворачивающие соединения объединяют потоки. Завершение од­ного или нескольких действий вызывает начало выполнения другого действия.

В табл. 2.2 объединены три типа соединений .

Графическое обозначение	Название		Правила инициации
	Соединение «и»	Разворачи­вающее	Каждое конечное действие обяза­тельно инициируется
		Сворачи­вающее	Каждое исходное действие обяза­тельно должно завершиться
	Соединение «эксклюзивное "или"»	Разворачи­вающее	Одно и только одно конечное дей­ствие инициируется
		Сворачи­вающее	Одно и только одно исходное дей­ствие должно завершиться
	Соединение «или»	Развора­чивающее	Одно или несколько конечных действий инициируются
		Сворачи­вающее	Одно или несколько исходных действий должны завершиться

Таблица 3.2

Примеры разворачивающих и сворачивающих соединений приве­дены на рис. 3.4

Рис. 3.4 Два вида соединений

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

Рис. 3.5 “И” – cоединения

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

Соединение «эксклюзивное "или "». Вне зависимости от количест­ва действий, связанных со сворачивающим или разворачивающим соединением «эксклюзивное «или», инициировано будет только одно из них, и поэтому только оно будет завершено перед тем, как любое дей­ствие, следующее за сворачивающим соединением «эксклюзивное «или», сможет начаться. Если правила активации соединения извест­ны, они обязательно должны быть документированы либо в его описа­нии, либо пометкой стрелок, исходящих из разворачивающего соеди­нения, как показано на рис. 3.6

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

Рис. 3.6 Соединение «эксклюзивное “или” »

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

Указатели

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

Указатель изображается на диаграмме в виде прямоугольника, по­хожего на изображение действия. Имя указателя обычно включает его тип (например, ОБЪЕКТ, UOB и т.п.) и идентификатор (табл. 3.3).

Тип указателя	Назначение
ОБЪЕКТ (OBJECT)	Для описания того, что в действии принимает участие какой-либо заслуживающий отдельного внимания объект
	Для реализации цикличности выполнения действий. Ука­затель ССЫЛКА может относиться и к соединению
ЕДИНИЦА ДЕЙ­СТВИЯ (Unit of Behavior - UOB)	Для многократного отображения на диаграмме одного и того же действия. Например, если действие «Подсчет наличных» выполняется несколько раз, в первый раз оно создается как действие, а последующие его появления на диаграмме оформляются указателями UOB
ЗАМЕТКА (NOTE)	Для документирования любой важной информации обще­го характера, относящейся к изображенному на диаграм­мах. В этом смысле ССЫЛКА служит альтернативой методу помещения текстовых заметок непосредственно на диаграммах
УТОЧНЕНИЕ (Ela­boration - ELAB)	Для уточнения или более подробного описания изобра­женного на диаграмме. Указатель УТОЧНЕНИЕ обычно используется для описания логики ветвления у соеди­нений

Таблица 3.3

Декомпозиция действий

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

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

Требования IDEF3 к описанию бизнес-процессов

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

Определение сценария, границ моделирования, точки зрения

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

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

Определение действий и объектов

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

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

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

Таблица 3.4

Последовательность и параллельность

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

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

Читайте также: Ведомые сетью инверторы на тиристорах (на примере трехфазной однополупериодной схемы, анализ, временные диаграммы). Вопрос № 4. Фазовые равновесия в двухкомпонентных системах. Диаграммы плавкости. Правило рычага. Выделить диаграмму, на вкладке Конструктор в группе Расположение выполнить команду Переместить диаграмму Генераторы постоянного тока, энергетическая диаграмма. Классификация. Графическое изображение изменения гидростатического давления вдоль стенки в зависимости от глубины называется диаграммой распределения давления или эпюрой давления. Диаграмма направленности антенны. Способы представления: в прямоугольной системе координат; полярной системе координат; картографическое изображение.

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

• Диаграммы относящиеся к первому типу называются диаграммамиОписания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD) ,
• а ко второму - диаграммами Состояния Объекта в и его Трансформаций Процессе (Object State Transition Network, OSTN) .

Иное встречающееся название для PFDD - диаграмма работ WFD (Work Flow Diagram).

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

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

Рисунок 1. Пример PFDD диаграммы.

На рис.1 изображена диаграмма PFDD, являющаяся графическим отображение сценария обработки детали. Прямоугольники на диаграмме PFDD называются функциональными элементами или элементамиповедения (Unit of Behavior, UOB) и обозначают событие, стадию процесса или принятие решения . Каждый UOB имеет свое имя , отображаемое в глагольном наклонении и уникальный номер. Стрелки или линии являются отображением перемещения детали между UOB-блоками в ходе процесса.

Объект, обозначенный J1 - называется перекрестком (Junction). Перекрестки используются для отображения логики взаимодействия стрелок (потоков) при слиянии и разветвлении или для отображения множества событий, которые могут или должны быть завершены перед началом следующей работы. Различают перекрестки для слияния (Fan-in Junction) и разветвления (Fan-out Junction) стрелок. Перекресток не может использоваться одновременно для слияния и для разветвления .

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

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

Рисунок 2. Пример OSTN диаграммы

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

6) IDEF3-модель отвечает на вопросы "Как система это делает?" Язык IDEF3 - язык диаграмм, помогающий разработчику моделей наглядно представить моделируемые процессы. В IDEF3 входят два типа описаний:

1. процесс-ориентированные в виде последовательности операций (Process Flow Description Diagrams, PFDD);

2. объект-ориентированные, выражаемые диаграммами перехода состояний, характерными для конечно-автоматных моделей (Object State Transition Network, OSTN).

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

Рис. 1. IDEF3-диаграмма последовательности операций

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

Рис. 2. Перекрестки

На рис. 4 представлен пример объект-ориентированной IDEF3-диаграммы. В таких диаграммах имеются средства для изображения состояний системы, активностей, переходов из состояния в состояние и условий перехода.

Рис. 4. IDEF3-диаграмма перехода состояний

7)IDEF2 и IDEF3 реализуют поведенческое моделирование. Если методика IDEF0 связана с функциональными аспектами и позволяет отвечать на вопрос: "Что делает система?", то в этих методиках детализируется ответ на вопрос: "Как система это делает". В основе поведенческого моделирования лежат модели и методы имитационного моделирования систем массового обслуживания, сети Петри, возможно применение модели конечного автомата, описывающей поведение системы как последовательности смен состояний. Перечисленные методики относятся к так называемым структурным методам.

IDEF4 Объектно-ориентированное проектирование

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

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

IDEF5 Систематизация объектов приложения

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

Ontology Description Capture - Стандарт онтологического исследования сложных систем. С помощью методологии IDEF5 онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На основе этих утверждений формируются выводы о дальнейшем развитии системы и производится её оптимизация;

IDEF6 Использование рационального опыта проектирования

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

Design Rationale Capture - Обоснование проектных действий. Назначение IDEF6 состоит в облегчении получения «знаний о способе» моделирования, их представления и использования при разработке систем управления предприятиями. Под «знаниями о способе» понимаются причины, обстоятельства, скрытые мотивы, которые обуславливают выбранные методы моделирования. Проще говоря, «знания о способе» интерпретируются как ответ на вопрос: «почему модель получилась такой, какой получилась?» Большинство методов моделирования фокусируются на собственно получаемых моделях, а не на процессе их создания. Метод IDEF6 акцентирует внимание именно на процессе создания модели;

IDEF8 Взаимодействие человека и системы

IDEF8 предназначен для проектирования диалогов человека и технической системы.

User Interface Modeling - Метод разработки интерфейсов взаимодействия оператора и системы (пользовательских интерфейсов). Современные среды разработки пользовательских интерфейсов в большей степени создают внешний вид интерфейса. IDEF8 фокусирует внимание разработчиков интерфейса на программировании желаемого взаимного поведения интерфейса и пользователя на трех уровнях: выполняемой операции (что это за операция); сценарии взаимодействия, определяемом специфической ролью пользователя (по какому сценарию она должна выполняться тем или иным пользователем); и, наконец, на деталях интерфейса (какие элементы управления, предлагает интерфейс для выполнения операции);

IDEF9 Учет условий и ограничений

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

Scenario-Driven IS Design (Business Constraint Discovery method) - Метод исследования бизнес ограничений был разработан для облегчения обнаружения и анализа ограничений в условиях которых действует предприятие. Обычно, при построении моделей описанию ограничений, оказывающих влияние на протекание процессов на предприятии уделяется недостаточное внимание. Знания об основных ограничениях и характере их влияния, закладываемые в модели, в лучшем случае остаются неполными, несогласованными, распределенными нерационально, но часто их вовсе нет. Это не обязательно приводит к тому, что построенные модели нежизнеспособны, просто их реализация столкнется с непредвиденными трудностями, в результате чего их потенциал будет не реализован. Тем не менее в случаях, когда речь идет именно о совершенствовании структур или адаптации к предсказываемым изменениям, знания о существующих ограничениях имеют критическое значение;

IDEF14 Моделирование вычислительных сетей

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

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

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

Согласно обзору передовых технологий (Survey of Advanced Technology), составленному фирмой Systems Development Inc. в 1996 г. по результатам анкетирования более 1000 американских фирм, CASE-технология в настоящее время попала в разряд наиболее стабильных информационных технологий (ее использовала половина всех опрошенных пользователей более чем в трети своих проектов, из них 85% завершились успешно). Однако, несмотря на все потенциальные возможности CASE-средств, существует множество примеров их неудачного внедрения, в результате которых CASE-средства становятся "полочным" ПО (shelfware). В связи с этим необходимо отметить следующее:

· CASE-средства не обязательно дают немедленный эффект; он может быть получен только спустя какое-то время;

· реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;

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

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

· широкое разнообразие качества и возможностей CASE-средств;

· относительно небольшое время использования CASE-средств в различных организациях и недостаток опыта их применения;

· широкое разнообразие в практике внедрения различных организаций;

· отсутствие детальных метрик и данных для уже выполненных и текущих проектов;

· широкий диапазон предметных областей проектов;

· различная степень интеграции CASE-средств в различных проектах.

Среди наиболее важных проблем выделяются следующие:

· достоверная оценка отдачи от инвестиций в CASE-средства затруднительна ввиду отсутствия приемлемых метрик и данных по проектам и процессам разработки ПО;

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

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

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

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

· негативное отношение персонала к внедрению новой CASE-технологии может быть главной причиной провала проекта.

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

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

· высокий уровень технологической поддержки процессов разработки и сопровождения ПО;

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

· приемлемый уровень отдачи от инвестиций в CASE-средства.

CASE средства поддерживают 2 технологии:

All fusion (поддерживает структурную методологию, IDEF0, IDEF1 и т.д.) - datarun

Объектно-ориентированную методологию (UML). – RUP (рациональный унифицированный процесс)

Изначально методология IDEF разрабатывалась для ВВС США, затем эксплуатировалась NASA и лишь спустя некоторое время стала применяться для моделирования бизнес-процессов.

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

IDEF0

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

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

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

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

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

Самым известным российским продуктом, поддерживающим построение процессов в нотации IDEF0 , является , поддержку данной нотации имеет также Microsoft Visio .

IDEF3

Нотация IDEF3 чаще применяется для построения процессов нижнего уровня, могут также использовать при декомпозиции блоков процесса IDEF0 . В отличие отIDEF0 данная нотация не поддерживает отображение «механизмов» и «управления», зато отображает очередность выполнения работ персоналом. Несмотря на схожесть с нотацией FlowChart , имеет некоторые существенные отличия. Во-первых, весь процесс строится не сверху вниз, а слева направо и при этом, как правило, ограничен количеством используемых блоков на одну диаграмму. Во-вторых, нотация изначально предназначалась для технических специалистов, поэтому содержит специальные перекрёстки, такие как, «XOR», «Synchronous OR», «Asynchronous OR», «Synchronous AND» и «Asynchronous AND», знакомые программистам, но требующие дополнительное пояснения менеджерам предприятия.

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

• · документировать имеющиеся данные о технологии процесса, выявленные, скажем, в процессе опроса компетентных сотрудников, ответственных за организацию рассматриваемого процесса;
• · определять и анализировать точки влияния потоков сопутствующего документооборота на сценарий технологических процессов;
• · определять ситуации, в которых требуется принятие решения, влияющего на жизненный цикл процесса, например изменение конструктивных, технологических или эксплуатационных свойств конечного продукта;
• · содействовать принятию оптимальных решений при реорганизации технологических процессов;
• · разрабатывать имитационные модели технологических процессов, по принципу «КАК БУДЕТ, ЕСЛИ…».

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

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

Рис. 4.

Диаграммы относящиеся к первому типу называются диаграммами Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD), а ко второму - диаграммами Состояния Объекта в и его Трансформаций Процессе (Object State Transition Network, OSTN). Предположим, требуется описать процесс окраски детали в производственном цеху на предприятии. С помощью диаграмм PFDD документируется последовательность и описание стадий обработки детали в рамках исследуемого технологического процесса. Диаграммы OSTN используются для иллюстрации трансформаций детали, которые происходят на каждой стадии обработки.

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

Рис. 5.

На рисунке 5 изображена диаграмма PFDD, являющаяся графическим отображение сценария обработки детали. Прямоугольники на диаграмме PFDD называются функциональными элементами или элементами поведения (Unit of Behavior, UOB) и обозначают событие, стадию процесса или принятие решения. Каждый UOB имеет свое имя, отображаемое в глагольном наклонении и уникальный номер. Стрелки или линии являются отображением перемещения детали между UOB_блоками в ходе процесса. Линии бывают следующих видов:

• · Старшая (Precedence) - сплошная линия, связывающая UOB. Рисуется слева направо или сверху вниз;
• · Отношения (Relational Link) - пунктирная линия, использующаяся для изображения связей между UOB;
• · Потоки объектов (Object Flow) - стрелка с двумя наконечниками используется для описания того факта, что объект (деталь) используется в двух или более единицах работы, например, когда объект порождается в одной работе и используется в другой.

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

Таблица 1

Название перекрестков	Обозначение перекрестков	Смысл перекрестков
Схема расхождения	Схема схождения
«Исключающий ИЛИ»	Только одна последующая работа запускается	Только одна предшествующая работа должна быть завершена
	Асинхронный	Все последующие работы запускаются	Все предшествующие работы должны быть завершены
Синхронный	Все последующие работы запускаются одновременно	Все предшествующие работы должны быть завершены одновременно
	Асинхронный	Одна или несколько последующих работ запускаются	Одна или несколько предшествующих работ должны быть завершены
Синхронный	Одна или несколько последующих работ запускаются одновременно	Одна или несколько предшествующих работ должны быть завершены одновременно

Все перекрестки в PFDD диаграмме нумеруются, каждый номер имеет префикс «J». Сценарий, отображаемый на диаграмме, можно описать в следующем виде:

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

Каждый функциональный блок UOB может иметь последовательность декомпозиций, и, следовательно, может быть детализирован с любой необходимой точностью. Под декомпозицией мы понимаем представление каждого UOB с помощью отдельной IDEF3 диаграммы. Например, мы можем декомпозировать UOB «Окрасить Деталь», представив его отдельным процессом и построив для него свою PFDD диаграмму. При этом эта диаграмма будет называться дочерней, по отношению к изображенной на рис. 5, а та, соответственно родительской. Номера UOB дочерних диаграмм имеют сквозную нумерацию, т.е., если родительский UOB имеет номер «1», то блоки UOB на его декомпозиции будут соответственно иметь номера «1.1», «1.2» и т.д. Применение принципа декомпозиции в IDEF3 позволяет структурировано описывать процессы с любым требуемым уровнем детализации.

Рис. 6.

Если диаграммы PFDD технологический процесс «С точки зрения наблюдателя», то другой класс диаграмм IDEF3 OSTN позволяет рассматривать тот же самый процесс «С точки зрения объекта». Состояния объекта (в нашем случае детали) и Изменение состояния являются ключевыми понятиями OSTN диаграммы. Состояния объекта отображаются окружностями, а их изменения направленными линиями. Каждая линия имеет ссылку на соответствующий функциональный блок UOB, в результате которого произошло отображаемое ей изменение состояния объекта.

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

Рассмотрим процесс декомпозиции диаграмм IDEF3, включающий взаимодействие автора (аналитика) и одного или нескольких экспертов предметной области.

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

	Цель описания
	Описывает участие важного объекта в работе
	Инструмент циклического перехода (в повторяющейся последовательности работ), возможно на текущей диаграмме, но не обязательно. Если все работы цикла присутствуют на текущей диаграмме, цикл может также изображаться стрелкой, возвращающейся на стартовую работу. GOTO может ссылаться на перекресток
UOB (Unit of behaviour)	Применяется, когда необходимо подчеркнуть множественное использование какой-либо работы, но без цикла. Например, работа «Контроль качества» может быть использована в процессе «Изготовление изделия» несколько раз, после каждой единичной операции. Обычно этот тип ссылки не используется для моделирования автоматически запускающихся работ
	Используется для документирования важной информации, относящейся к каким-либо графическим объектам на диаграмме. NOTE является альтернативой внесению текстового объекта в диаграмму
ELAB (Elaboration)	Используется для усовершенствования графиков или их более детального описания. Обычно употребляется для детального описания разветвления и слияния стрелок на перекрестках

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

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

универсальный графический моделирование трикотажный процесс