Притыкин Д.А., преподаватель кафедры теоретической механики МФТИ

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

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

Если верить современной науке о происхождении человека, его, то есть человека, всегда отличала от других видов жажда деятельности. Причем не просто жажда деятельности как таковой, а стремление к совершенствованию этой деятельности, стремление к развитию, привлечению в свою деятельность новых технологий. Чем занимались деловые люди в эпоху динозавров? Самый выгодный и жизненно необходимый бизнес тех времен – охота, скажем, на мамонта. Как добывать такого крупного зверя? Это бизнес-процесс, который требовал от удачливых охотников тщательной подготовки и обучения. Но как можно было обучать подрастающее поколение в те времена, когда лексические средства были еще недостаточно выразительны, а письменности не было как таковой? В этот трудный момент на помощь человеку пришло средство, потрясающее своей простотой и выразительностью – рисунок. Процесс охоты можно было нарисовать. Конечно, поначалу не обходилось и без недоразумений, таких, например, как описаны у Р. Киплинга, но казусы происходили, только пока язык рисунка еще не сформировался полностью, пока не было понятно, что есть что, как изобразить перспективу, и как воссоздать точную схему. Так рисунок стал основным средством моделирования бизнес-процессов. Шло время, бизнес-процессы становились все разнообразнее, подтверждение чему можно обнаружить на стенах храмов древней Индии, на барельефах древней Греции, уже на папирусе в Египте и т.д. Сначала рисунок изображал лишь завершившийся процесс, то есть показывал, как принято делать что-либо в соответствии с устоявшимся распорядком. Затем рисунки стали применяться и для того, чтобы показать, как можно поменять сложившуюся структуру бизнес-процессов, с тем чтобы улучшить их, то есть рисунок стал вспомогательным средством для реинжениринга бизнес-процессов. В течение довольно продолжительного времени у рисунка был только один существенный недостаток – будучи возведенным в ранг искусства, он был подвластен лишь мастерам, которые, к тому же, тратили на каждый рисунок много времени. Затем появились книги, и нужда в рисунке, как средстве моделирования отпала, рисунок стал в лучшем случае иллюстрацией к написанному. Шло время, темп человеческой деятельности экспоненциально рос, усложнялись бизнес-процессы. В двадцатом веке бизнес-процессы стали настолько сложны, что ни один человек, работающий на более или менее крупном проекте, не в состоянии представить себе работу всего предприятия в той мере, которая необходима, для создания информационной системы или для реинжениринга бизнес-процессов.

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

Существует инструмент, который поможет ответить на все эти вопросы. Это Computer Associates BPwin, версия 4.0 которого вышла в этом году. BPwin является мощным инструментом для создания моделей, позволяющих анализировать, документировать и планировать изменения сложных бизнес-процессов. BPwin предлагает средство для сбора всей необходимой информации о работе предприятия и графического изображения этой информации в виде целостной и непротиворечивой модели. Причем, поскольку модель является некоторым графическим представлением действительности, можно утверждать, что человек вернулся к своему излюбленному средству документирования бизнес-процессов – к рисунку. Но возвращение это произошло на новом уровне – целостность и непротиворечивость модели-рисунка (качества, о которых раньше не было и речи) гарантируются рядом методологий и нотаций, которым следуют создатели модели. BPwin поддерживает три таких методологии: IDEF0, DFD и IDEF3, позволяющие анализировать ваш бизнес с трех ключевых точек зрения:

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

С точки зрения потоков информации (документооборота) в системе. Диаграммы DFD (Data Flow Diagramming) могут дополнить то, что уже отражено в модели IDEF3, поскольку они описывают потоки данных, позволяя проследить, каким образом происходит обмен информацией между бизнес-функциями внутри системы. В тоже время диаграммы DFD оставляют без внимания взаимодействие между бизнес-функциями.

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

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

IDEF0. Основной из трех методологий, поддерживаемых BPwin, является IDEF0. IDEF0, относится к семейству IDEF, которое появилось в конце шестидесятых годов под названием SADT (Structured Analysis and Design Technique). IDEF0 может быть использована для моделирования широкого класса систем. Для новых систем применение IDEF0 имеет своей целью определение требований и указание функций для последующей разработки системы, отвечающей поставленным требованиям и реализующей выделенные функции. Применительно к уже существующим системам IDEF0 может быть использована для анализа функций, выполняемых системой и отображения механизмов, посредством которых эти функции выполняются. Результатом применения IDEF0 к некоторой системе является модель этой системы, состоящая из иерархически упорядоченного набора диаграмм, текста документации и словарей, связанных друг с другом с помощью перекрестных ссылок. Двумя наиболее важными компонентами, из которых строятся диаграммы IDEF0, являются бизнес-функции или работы (представленные на диаграммах в виде прямоугольников) и данные и объекты (изображаемые в виде стрелок), связывающие между собой работы. При этом стрелки, в зависимости от того в какую грань прямоугольника работы они входят или из какой грани выходят, делятся на пять видов:

Стрелки входа (входят в левую грань работы) – изображают данные или объекты, изменяемые в ходе выполнения работы.

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

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

Стрелки механизма (входят в нижнюю грань работы) – изображают ресурсы, необходимые для выполнения работы, но не изменяющиеся в процессе работы (например, оборудование, людские ресурсы…)

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

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

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

Как видно на Рис.1, BPwin позволяет выделять работы и стрелки разными цветами, а также привязывать имена стрелок к самим стрелкам (стрелка по имени “Отчетность”), что повышает наглядность и читаемость диаграммы.

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

Рис. 2 Пример диаграммы декомпозиции

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

Всего DFD использует четыре важных элемента:

Работы. Работы в DFD обозначают функции или процессы, которые обрабатывают и изменяют информацию. Работы представлены на диаграммах в виде прямоугольников со скругленными углами. (cм. Рис.3 – “Проверить наличие товара на складе”)

Стрелки. Стрелки идут от объекта-источника к объекту-приемнику, обозначая информационные потоки в системе документооборота. (cм. Рис.3 – “Запрос на склад”)

Хранилища данных. Хранилища данных представляют собой собственно данные, к которым осуществляется доступ, эти данные также могут быть созданы или изменены работами. На одной диаграмме может присутствовать несколько копий одного и того же хранилища данных. (cм. Рис.3 – “Сведения о заказах”)

Рис.3 Пример диаграммы DFD

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

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

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

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

Модель, выполненная в IDEF3, может содержать следующие элементы:

Единицы работы (Unit of Work) - основной компонент диаграммы IDEF3 близкий по смыслу к работе IDEF0.

Связи (Links) - Связи, изображаемые стрелками, показывают взаимоотношения работ. В IDEF3 различают три типа связей:

Связь предшествования (Precedence) – показывает, что прежде чем начнется работа-приемник, должна завершиться работа-источник. Обозначается сплошной линией.

Связь отношения (Relational) - показывает связь между двумя работами или между работой и объектом ссылки. Обозначается пунктирной линией.

Поток объектов (Object Flow) – показывает участие некоторого объекта в двух или более работах, как, например, если объект производится в ходе выполнения одной работы и потребляется другой работой. Обозначается стрелкой с двумя наконечниками.

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

Перекресток слияния (Fan-in Junction) – узел, собирающий множество стрелок в одну, указывая на необходимость условия завершенности работ-источников стрелок для продолжения процесса.

Перекресток ветвления (Fan-out Junction) – узел, в котором единственная входящая в него стрелка ветвится, показывая, что работы, следующие за перекрестком, выполняются параллельно или альтернативно.

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

Рис. 4 Пример диаграммы IDEF3

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

Применение универсальных графических языков бизнес-моделирования IDEF0, IDEF3 и DFD обеспечивает логическую целостность и полноту описания, необходимую для достижения точных и непротиворечивых результатов. Посредством набора графических инструментов для отображения действий и объектов, BPwin позволяет легко построить схему процесса, на которой показаны исходные данные, результаты операций, ресурсы, необходимые для их выполнения, управляющие воздействия, взаимные связи между отдельными работами. Интерактивное выделение объектов обеспечивает постоянную визуальную обратную связь при построении модели. BРwin поддерживает ссылочную целостность, не допуская определения некорректных связей и гарантируя непротиворечивость отношений между объектами при моделировании.

BPwin обладает удобным инструментом для навигации по уровням декомпозиции модели. Это Model Explorer (см . Рис. 5), Рис. 5), который по организации очень похож на привычный всем проводник Windows. Работы IDEF0 показываются в Model Explorer зеленым цветом, DFD – желтым и IDEF3 – синим. Щелкая мышкой по любой из работ, представленных в проводнике, пользователь может переходить на диаграмму, содержащую выбранную работу. В версии BPwin 4.0 проводник модели предлагает пользователю улучшенный интерфейс, который включает в себя новую вкладку объектов (Objects), и доработанную вкладку диаграмм (Diagrams). С помощью вкладки объектов можно методом Drag&Drop размещать объекты из словаря на любой диаграмму. С помощью вкладки диаграмм можно просматривать всю иерархию диаграмм, включая Organization Chart, Node Tree, Swim Lane, FEO, и IDEF3 Scenario, о которых речь пойдет позже.

Рис. 5 Model Explorer

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

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

   Объекты ссылок;

   Атрибуты;

   Центры затрат;

   Сущности;

3. Группы ролей;

   Свойства, определяемые пользователем (UDP);

   Ключевые слова UDP.

Генератор отчетов тоже претерпел существенные модификации. Теперь BPwin имеет действительно мощный инструмент отчетов Report Template Builder, с помощью которого можно легко и быстро создавать различные отчеты о вашей модели. С его помощью можно также создавать шаблоны для отчетов, которые можно будет многократно использовать впоследствии, а также преобразовывать отчеты в формат txt (.CSV), HTML или RTF.

Были улучшены и дополнены и редакторы свойств диаграмм и объектов. Теперь, помимо тех свойств, которые были доступны в предыдущих версиях, в них включены вкладки для изменения шрифтов, цветов, ролей, стиля прямоугольников работ, колонтитулов и других параметров страницы. На вкладке Header/Footer пользователь может теперь настраивать верхний и нижний колонтитулы для каждой диаграммы в отдельности. Кнопки панели инструментов автоматически перестраиваются при переходе от одной методологии к другой. Появилась возможность выделения группы объектов и последующей работы с этой группой. Еще один подарок пользователям BPwin 4.0 – поддержка визуального сравнения диаграмм. Теперь вы можете, предварительно выбрав две диаграммы, создать файл JPEG, который покажет все различия между выбранными диаграммами. И, конечно, обновлен BPwin Online Tutorial, в котором приведены полные уроки с примерами моделей, которые помогут вам быстро освоить BPwin.

Итак, что же может предложить BPwin, кроме поддержки уже рассмотренных нами трех методологий моделирования? Конечно же, этот инструмент, ставший незаменимым в консалтинговых компаниях в России и по всему миру, не останавливается на этом. В дополнение к диаграммам IDEF0, DFD и IDEF3, BPwin поддерживает еще целый ряд вспомогательных диаграмм таких как:

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

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

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

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

Рис. 6 Пример диаграммы дерева узлов

Диаграммы только для показа (For Exposition Only {FEO} Diagram). К модели всегда можно добавить диаграмму FEO. Чаще всего это делается, для того чтобы проиллюстрировать разные сценарии развития процесса, показать модель с других точек зрения, вырезать важный кусок из сложной диаграммы (см. рис. 7), не портя при этом саму диаграмму. К любой диаграмме модели в BPwin, будь то контекстная диаграмма или одна из диаграмм декомпозиции можно добавлять произвольное число FEO диаграмм. FEO диаграммы характерны тем, что они не подлежат синтаксической проверке со стороны BPwin, поскольку, как в нашем примере, они могут являться лишь частью синтаксически правильной диаграммы.

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

Рис. 7 Пример FEO диаграммы

Диаграммы сценариев IDEF3 (IDEF3 Scenario). В BPwin 4.0 есть возможность добавлять к модели диаграммы сценариев IDEF3.

Рис. 8 Пример сценария IDEF3

Схемы организации (Organization Charts). Для того чтобы наглядно представить структуру организации к любой модели в BPwin 4.0 можно добавить схему организации. Схемы организации BPwin имеют традиционную древовидную иерархическую структуру, на вершине которой находится один прямоугольник, от которого идут ветвления к нескольким нижестоящим. Каждый прямоугольник в схеме организации соответствует конкретной роли или должности, например президента или вице-президента.

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

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

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

Рис. 9 Пример схемы организации

Swim Lane Diagrams. Это тоже нововведение, которое можно обнаружить только в BPwin 4.0. Swim Lane диаграммы можно добавлять к любой модели в BPwin для более наглядного изображения течения процесса. Эти диаграммы используют методологию IDEF3 и показывают горизонтальные полосы, которые представляют участие в процессе ролей.

Рис. 10 Пример Swim Lane диаграммы.

Но и описав вспомогательные диаграммы, мы далеко не исчерпали все возможности BPwin, поскольку этот продукт является не только мощным средством графического представления информации, но и инструментом ее анализа. Как уже говорилось выше, при реорганизации бизнес-процессов уже существующей системы строятся две модели: AS IS и TO BE. Модель AS IS призвана показать, как система функционирует в настоящий момент и является своего рода фотографией системы. А модель TO BE, которая строится исходя из результатов анализа модели AS IS, показывает, как система будет работать после реорганизации. Как же провести этот анализ? Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Признаком неэффективной деятельности могут быть бесполезные, неуправляемые и дублирующиеся работы, неэффективный документооборот (нужный документ не оказывается в нужном месте в нужное время), отсутствие обратных связей по управлению (на проведение работы не оказывает влияние ее результат) и входу (объекты или информация используются нерационально) и т.д. Кроме того, BPwin содержит ряд средств, которые помогают аналитику анализировать и исправлять модель AS IS. Прежде всего, речь идет о том, что BPwin указывает на синтаксические ошибки в модели, которые могут быть вызваны неправильной организацией системы. Когда все такие ошибки будут исправлены, перед аналитиком должна встать задача оптимизации, а для корректной постановки этой задачи, как известно, необходим критерий. Здесь BPwin снова приходит аналитику на помощь, предлагая ему то, что для оптимизатора значит ничуть не меньше, чем точка опоры для Архимеда. BPwin дает аналитику метрику - стоимостной анализ, основанный на работах (Activity Based Costing, ABC) и свойства, определяемые пользователем (User Defined Properties, UDP).

Встроенный в BPwin механизм вычисления стоимости позволяет оценивать и анализировать затраты на осуществление различных видов деловой активности. Механизм вычисления расходов на основе выполняемых действий (Activity-Based Costing, ABC) - это технология, применяемая для оценки затрат и используемых ресурсов. Она помогает распознать и выделить наиболее дорогостоящие операции для дальнейшего анализа. ABС является широко распространенной методикой, используемой международными корпорациями и государственными организациями (в том числе Департаментом обороны США) для идентификации истинных движителей затрат в организации. Стоимостной анализ представляет собой соглашение об учете, используемое для сбора затрат, связанных с работами, с целью определить общую стоимость процесса. Стоимостной анализ основан на модели работ, поскольку количественная оценка невозможна без детального понимания в функциональности предприятия. Обычно ABC применяется для того, чтобы понять происхождение выходных затрат и облегчить выбор нужной модели работ при реорганизации деятельности предприятия. С помощью стоимостного анализа можно решить такие задачи как определение действительной стоимости производства продукта, определение действительной стоимости поддержки клиента, идентификация работ, которые стоят больше всего (те, которые должны быть улучшены в первую очередь).

Механизм поддержки ABC в BPwin, хотя и учитывает стоимость выполнения каждой работы, продолжительность каждой работы по времени и сколько раз необходимо выполнить работу в течение одного цикла бизнес-процесса, все же дает довольно грубые оценки и, к тому же требует, чтобы все диаграммы, для которых производится оценка были выполнены в IDEF0. Если стоимостных показателей недостаточно, имеется возможность внесения собственных метрик - свойств, определенных пользователем (User Defined Properties, UDP). Имеется возможность задания 18 различных типов UDP, в том числе управляющих команд и массивов, объединенных по категориям. Каждой работе можно поставить в соответствие набор UDP и проанализировать результат в специальном отчете Diagram Object Report.

И, наконец, создатели BPwin очень хорошо понимают, что один в поле не воин, даже если этот “один” - BPwin 4.0, и поэтому BPwin тесно интегрируется с рядом известных продуктов Computer Associates и других компаний. Среди этих продуктов:

Широко известный инструмент моделирования данных ERwin (CA/Logic Works). Erwin не нуждается в рекомендациях. Для тех, кто уже работает с BPwin, отметим, что в версии BPwin 4.0 интерфейсы экспорта и импорта синхронизованы с Erwin 4.0. Кроме того, появилась возможность ассоциирования сущностей и атрибутов с хранилищами данных.

Система управления и хранения проектов ModelMart (CA/Logic Works), которая предоставляет репозитарий для коллективной разработки моделей. ModelMart гарантирует согласованность моделей, разграничение доступа к ним, поддержку версий и много других средств, которые так важны при командной разработке моделей. Сервер приложений для программных продуктов CA ModelMart поддерживает мощный набор инструментальных программных средств, обеспечивающих совместное (групповое) проектирование и разработку программных систем, включая механизмы объединения моделей и анализа изменений, контроль версий, возможность создания "компонент" модели и т.д. Для организации хранилища моделей в ModelMart используются СУБД на платформах Oracle, Sybase, Informix или SQL Server. Кроме того, поддерживаются прямые связи ModelMart с ERwin и BPwin.

Инструмент стоимостного анализа EasyABC (ABC Technologies).

В BPwin 4.0 стал возможен экспорт модели в систему имитационного моделирования Arena (Systems Modeling Corp.).

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

Подготовлено по материалам http://www.finexpert.ru/

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

Для установки BPwin на Windows 7 нужно настроить режим совместимости с WinXP SP3 и запустить файл BPwin4.exe от имени администратора:

1. Правой кнопкой мыши нажимаем на файл BPwin4.exe и выбираем пункт "Свойства".
2. Далее переходим на вкладку "Совместимость"
3. В диалоговом окне "Режим совместимости", устанавливаем галочку "Запустить программу в режиме совместимости с:"
4. Выбираем пункт меню "Windows XP (пакет обновления 3)"
5. Нажать "ОК"

Начнется процесс подготовки к инсталяции:

Рис 1.1. Окно BPwin 4.0 Setup

В появившемся окне BPwin 4 Setup нажимаем . Для дальнейшей установкинажимаем

Рис 1.2. Лицензионное соглашение

Указываем место установи программы. По умолчанию программа автоматически устанавливается в C:\Program Files\Computer Associates\BPwin 4.0.

Рис 1.3. Окно выбора типа установки

• Tipical отличается тем, что при таком типе установке программа устанавливает все свои компоненты (приложения).
• Compact режим необходим если на вашем жестком диске недостаточно места для всех компонентов BPwin. В таком случае будут установлены только основные компоненты необходимые для работы программы.
• Custom необходим для выбора определенных компонентов программы для установки

Для продолжения установки нажимаем .

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

После того как как установится BPwin на вашем компьютере, появится окно, «Добро пожаловать в регистрацию», в котором нужно нажать кнопку .

Рис 1.4. Окно «Добро пожаловать в регистрацию»

Затем в окне RegisterIT, которое предлагает вам зарегистрировать Вашу версию BPwin 4.0, нужно выбрать позицию Register Later и нажать кнопку .

Рис 1.5. Окно Register Later

Затем в появившемся окне нажимаем . Из появляющихся окон выбираем кнопки и .

Процесс установки завершён.

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

Для этого находим в архиве файл Keygen.exe и копируем его в каталог, куда была установлена программа BPwin (корневой каталог диска C:\СA_LIC )

Запускаем Keygen.exe расположенный в C:\СA_LIC .

В поле Product Name нужно выбрать BPwin 4.0 и нажать кнопку .

Это нужно для того, чтобы найти код программы BPwin 4.0 .

Рис 1.6. Окно Keygenerator by SlaSk/PFT

После того как ключ был сгенерирован и Вы увидели его в поле Registration ID, необходимо скопировать его.

Теперь BPwin Keygen генератор ключа можно закрыть.

Для дальнейшей работы следует запустить программу RegIT.exe из каталога CA_LIC. После запуска программы появляется окно приветствия RegIT.

Рис 1.7. Окно RegisterIT Welcome

В этом окне для продолжения работы необходимо нажать . После чего в окне RegisterIT вы выбираете пункт Register Later и нажимаете кнопку .

Рис 1.8. Окно ввода ключа

Далее появляется окно в котором в поле Product Name выбрать BPwin 4.0 , а в поле Registration ID вставляете ключ (набор цифр) ранее скопированный и нажимаете кнопку . Дальнейшего вашего участия не требуется (кроме нажатия кнопки ) программа всё сделает сама. На последнем шаге вы можете с облегчением нажать кнопку . Вот и всё программа BPwin 4.0 работоспособна.

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

CASE-средство BPwin предназначено для построения функциональных моделей с использованием методологий:

1. IDEF0 - функциональные модели любых систем;
2. IDEF3 - функциональные модели технологических процессов;
3. DFD - функциональные модели информационных систем.

Внешний вид главного окна BPwin представлен на рис.1.

Рис. 1. Интегрированная среда BPwin

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

На рис.2 приведено назначение элементов управления стандартной панели инструментов (Standard Toolbar).

Рис. 2. Стандартная панель инструментов

Для создания новой модели необходимо выбрать пункт меню "File / New" или нажать на соответствующую кнопку стандартной панели инструментов (см.рис.2). На экране появится диалоговое окно (рис.3).

Рис. 3. Диалоговое окно создания или открытия модели

В диалоговом окне необходимо выбрать радиокнопку "Create model", ввести имя модели в поле "Name" и выбрать методологию, нотация которой будет использовать при построении модели (радиокнопки "Type").
Для указания общих параметры модели необходимо выбрать пункт меню "Мodel / Model Properties" и в появившемся диалоговом окне перейти на вкладку "General" (риc.4).

Рис. 4. Вкладка "General" диалогового окна "Model Properties"

На вкладке задаются следующие параметры модели:
- имя модели (Model name);
- имя проекта (Project). Имя проекта, как правило, совпадает с именем разрабатываемой информационной системы;
- фамилия автора или наименование компании (Author);
- инициалы автора (Author initials);
- тип модели - AS-IS (как есть) или TO-BE (как будет). Подробнее см. раздел "Основы функционального анализа и проектирования систем".

После нажатия на кнопку "Ok" диалогового окна создания модели автоматически создается контекстная диаграмма. Указание параметров диаграммы, выбранной в текущий момент в панели процессов, осуществляется через диалоговое окно "Diagram Property", вызываемого через пункт меню "Diagram / Diagram Property" (рис.5).

Рис. 5. Вкладка "Name" диалогового окна "Diagram Property"

На вкладке "Status" указываются статус, дата создания и дата последней редакции диаграммы (рис.6).

Рис. 6. Вкладка "Status" диалогового окна "Diagram Property"

Типы статуса диаграммы имеют следующий смысл:
- рабочая (WORKING) - диаграмма находится в стадии разработки;
- черновик (DRAFT) - диаграмма прошла некоторые стадии рассмотрения с заказчиками, но это не окончательный вариант;
- рекомендованная (RECOMMENDED) - диаграмма прошла все стадии рассмотрения с заказчиками и отвечает формальным требованиям, но это не окончательный вариант;
- готовая или публикуемая (PUBLICATION) - окончательный вариант диаграммы.
На вкладке "Page Setup" указываются единицы измерения (Units), формат листов (Sheet Size), поля, необходимость отображения заголовка (Header) и нижнего колонтитула (Footer) (рис.7).

Рис. 7. Вкладка "Page Setup" диалогового окна "Diagram Property"

На вкладке "Header/Footer" возможно задание пользовательского (custom) вида заголовка (Header) и нижнего колонтитула (Footer) диаграммы (рис.8).

Рис. 8. Вкладка "Header/Footer" диалогового окна "Diagram Property"

Для непосредственного создания элементов диаграммы и ускоренной навигации по модели используется панель инструментов "BPwin Toolbox" (отображение или скрытие панели выполняется через пункт меню "View").

На рис.9 приведено назначение элементов управления панель инструментов "BPwin Toolbox".

Рис. 9. Панель инструментов "BPwin Toolbox"

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

В результате на экране появится диалоговое окно "Activity Properties" (рис.10).

Рис. 10. Диалоговое окно "Activity Properties"

На вкладке диалогового окна можно задать:
- имя блока (вкладка "Name");
- комментарий к блоку (вкладка "Definition");
- параметры шрифта надписи блока (вкладка "Font");
- цвет блока (вкладка "Color");
- графический примитив, используемый для отображения блока (вкладка "Box style").

Для указания аналогичных параметров стрелки используется диалоговое окно "Arrow Properties" (рис.11). Вызов диалогового окна выполняется также, как и для блока.

Рис. 11. Диалоговое окно "Arrow Properties"

Если наименование стрелки расположено удаленно от самой стрелки или возникают трудности по сопоставлению наименования стрелки с самой стрелкой (в случае высокого насыщения диаграммы элементами) можно на диаграмме отобразить ассоциацию между ними. Для этого необходимо щелкнуть по стрелке правой кнопкой мыши и в контекстном меню выбрать пункт "Squiggle".
Для указания на диаграмме произвольного комментария непосредственно к элементу используются кнопки "Задание ассоциации" и "Добавление произвольного текста".
Для навигации по модели (переходу к диаграммам) используются последние четыре кнопки панели "BPwin Toolbox".
Если на диаграмме выбран блок, для которого не существует диаграммы декомпозиции, и нажата кнопка в панели инструментов ▼, то на экране появится диалоговое окно "Activity Box Count" (рис.12).

Рис. 12. Диалоговое окно "Activity Box Count"

В этом диалоговом окне требуется выбрать методологию, в соответствии с которой будет строится диаграмма декомпозиции, и предполагаемое количество блоков на диаграмме. BPwin создаст диаграмму с указанным количеством блоков и перенесет на нее все стрелки входящие и выходящие в родительский блок.
Ниже перечислены наиболее используемые приемы редактирования диаграмм и их элементов:
- создание новой стрелки - выбрать в панели инструментов "BPwin Toolbox" кнопку →, подвести указатель мыши на диаграмме к соответствующей границе диаграммы или блока, означающей начало стрелки, нажать левую кнопку мыши, подвести указатель мыши к соответствующей границе диаграммы или блока, означающей конец стрелки, и нажать левую кнопку мыши;
- соединение имеющейся стрелки с имеющимся блоком или границей диаграммы, ветвление стрелки - выбрать в панели инструментов "BPwin Toolbox" кнопку →, подвести указатель мыши на диаграмме к соответствующей стрелке (в случае ветвления - к месту ветвления стрелки), нажать левую кнопку мыши, подвести указатель мыши к соответствующей границе диаграммы или блока, означающей конец стрелки, и нажать левую кнопку мыши;
- удаление блока - выбрать блок на диаграмме или панели процессов и нажать клавишу "Delete". При этом, кроме удаления самого блока, будут удалены все входящие и выходящие из него стрелки, а также связанные с ним диаграммы декомпозиции и их элементы;
- удаление стрелки - выбрать стрелку на диаграмме и нажать клавишу "Delete". Если удаляемая стрелка была перенесена на диаграмму в результате декомпозиции родительского блока, то она будет удалена с текущей диаграммы (диаграммы декомпозиции), а на родительской диаграмме останется и примет статус затуннелированной со стороны вхождения в родительский блок (рис.13а). Если удаляемая стрелка присутствует на диаграмме декомпозиции для блока, в который она входит или выходит, то она будет удалена с текущей диаграммы (родительской диаграммы), а на диаграмме декомпозиции примет статус затуннелированной со стороны границы этой диаграммы (рис.13б). Квадратные скобки затуннелированной стрелки означают неутвержденное (предварительное) туннелирование, круглые - утвержденное (сознательное). Для изменения статуса туннелирования (с неутверденного на утвержденное) необходимо щелкнуть по ней правой кнопкой мыши, выбрать пункт "Arrow Tunell" контекстного меню и в соответствующем диалоговом окне выбрать статус;

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

Перемещение блока или стрелки на диаграмме - выбрать в панели инструментов "BPwin Toolbox" кнопку , подвести указатель мыши на диаграмме к соответствующему элементу диаграммы, нажать левую кнопку мыши и, не отпуская ее, задать новое положение элемента.
- создание диаграммы дерева узлов - выбрать в панели процессов или на диаграмме блок (корень дерева), начиная с которого будет строится диаграмма дерева узлов, выбрать пункт меню "Diagram / Add Node Tree" и в появившемся диалоговом окне задать имя диаграммы дерева узлов и количество уровней дерева.

Рис. 14. Мастер создания диаграммы дерева узлов

Скачать книги по бизнес моделированию:

1. Марка, Д.А. Методология структурного анализа и проектирования SADT / Д.А. Марка, К. МакГоуэн. - М. : МетаТехнология, 1993. - 243 с.
2. Калянов, Г.Н. CASE. Структурный системный анализ (автоматизация и применение) / Г.Н. Калянов. - М. : Лори, 1996. - с.
3. Маклаков, С.В. BPwin и ERwin. CASE-средства разработки информационных систем / С.В. Маклаков. - М. : ДИАЛОГ-МИФИ, 2001. - 304 с.
4. Маклаков, С.В. Создание информационных систем с AllFusion Modeling Suite / С.В. Маклаков. - М. : ДИАЛОГ-МИФИ, 2005. - 432 с.
5. Дубейковский, В. И. Практика функционального моделирования с AllFusion Process Modeler 4.1. (BPwin) Где? Зачем? Как? / В.И. Дубейков-ский. - М. : ДИАЛОГ-МИФИ, 2004. - 464 с.
6. Анисимов, В.В. Проектирование информационных систем: курс лекций. В 2 ч. Ч. 1. Структурный подход / В.В. Анисимов. - Хабаровск: Изд-во ДВГУПС, 2006. - 112 с.

Для того, чтобы написать название процесса, функции или задачи, выполняемой проектируемой системой нужно два раза щелкнуть мышкой по первому функциональному блоку с номером А0, поя-вившемуся после создания новой модели. После чего появится диа-логовое окно Activity Properties, где будет предложено написать на-звание функционального блока (Рис.7).

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

Рис.7.Окно свойств функционального блока 9

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

Выбрать пункт меню «Decompose», после чего появится диалоговое окно с предложением выбрать количество блоков, на которые вы будете декомпозировать данный функциональный блок (Рис.9), либо нажать на значок

Допустимый интервал числа функций 3-6. Число блоков на диаграмме в дальнейшем можно будет изменить (добавить недостающие или удалить лишние).

Рис.9. Выбор количества функциональных блоков 10

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

Рис.10. Первый уровень декомпозиции

Функциональные блоки второго уровня декомпозиции имеют номера А1, А2, А3, А4, А5. При декомпозиции каждого из них бло-ки на следующем уровне декомпозиции будут иметь номера соот-ветственно А11, А12, А21, А22, А31, А32 и т.д. в зависимости от номера декомпозируемого функционального блока.

2. Работа со стрелками

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

В основе методологии IDEF0 лежат следующие правила:

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

с дугами связаны надписи (или метки) на естественном языке, описывающие данные, которые они представляют;

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

выходы одной функции могут быть Входами, Управлением или Исполнителями для другой;

дуги могут разветвляться и соединяться.

Рис.11. Виды связей в функциональной модели

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

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

Рис.12. Пример создания стрелок

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

Рис.13. Окно создания названий стрелок

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

Рис.14. Пример несвязных стрелок

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

Рис.15. Пример внутренних стрелок

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

Рис.16. Пример неразрешенных стрелок

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

Рис.17. Окно редактирования стрелок

Если Вы хотите, чтобы новая стрелка попала «наверх», следу-ет выбрать пункт меню Resolve it to border arrow. Если же Вы хоти-те оставить стрелку только на текущем уровне диаграммы, тогда следует выбрать пункт меню Change it to resolved rounded tunnel. Тоннельная стрелка изображается с круглыми скобками.

Практическое занятие № 1

Основные приемы работы с пакетом BPWin

Введение. 1

1. Цель работы.. 3

2. Назначение пакета BPWin. 3

3. Описание интерфейса программы BPWin. 3

4. Основные приемы работы с пакетом BPWin. 6

4.1. Работа с функциональными блоками. 6

4. 2. Работа со стрелками. 8

4.3. Проверка синтаксиса модели. 12

4.4. Формирование отчета Node Tree. 13

5. Выполнить задание. 14

Введение

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

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

Реализацию проектов по созданию ИС принято разбивать на стадии:

Ø анализа (прежде чем создавать ИС, необходимо понять и описать бизнес-логику предметной области),

Ø проектирования (необходимо определить модули и архитектуру будущей системы),

Ø непосредственного кодирования,

Ø тестирования,

Ø сопровождения.

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

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

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

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

На современном рынке средств разработки ИС достаточно много систем, в той или иной степени удовлетворяющих перечисленным требованиям. CASE-средства ERWin и BPWin входят в число лучших на сегодняшний день.

CASE-средство верхнего уровня BPWin поддерживает методологии:

Ø IDEF0 (функциональная модель),

Ø IDEF3 (WorkFlow Diagram),

Ø DFD (DataFlow Diagram).

Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей – того, к чему нужно стремиться (модель TO-BE). Методология IDEF0 предписывает построение иерархической системы диаграмм – единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция – система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. После каждого сеанса декомпозиции проводится сеанс экспертизы: каждая диаграмма проверяется экспертами предметной области, представителями заказчика, людьми, непосредственно участвующими в бизнес-процессе. Такая технология создания модели позволяет построить модель, адекватную предметной области на всех уровнях абстрагирования.

Цель работы

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

Назначение пакета BPWin

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

Функциональная модель включает в себя:

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

Ø взаимодействия этих процессов, функций, задач с внешним миром и между собой.

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

Описание интерфейса программы BPWin

После запуска программы BPWin на экране появится окно программы (рис. 1).

Рис. 1. Окно программы

Для создания новой модели необходимо вызвать диалог File/New или нажать на соответствующий значок на панели инструментов. После этого возникнет диалоговое окно, в котором следует указать название модели, выбрать методологию моделирования Business Process (IDEF0 ) и нажать OK (Рис. 2).

Рис.2. Окно создания новой модели

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

Рис.3. Окно свойств для новой модели

На появившейся странице верхнего уровня модели находится первый функциональный блок модели (Рис.4).

Рис.4. Основное окно BPWin

Основное окно программы содержит следующие части:

1. Рабочая область.

2. Панели инструментов.

3. Область модели.

Рассмотрим подробнее содержимое каждой из частей программы:

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

Панели инструментов: эти панели содержат практически все используемые при работе элементы. По умолчанию все панели отображаются на экране. При необходимости пользователь может отключить или, наоборот, включить требуемые модели, используя меню «View ». Имеются следующие панели инструментов:

Standard toolbar (рис. 5) – содержит кнопки для управления файлами (новый, открыть, сохранить, печать), кнопки отображения области свойств модели, кнопки управления масштабом изображения.

Рис.5. Стандартная панель инструментов

- BPWin Toolbox for Business Process Diagrams (IDEF0) – инструментальные кнопки создания элементов модели: функциональных блоков и связей (стрелок) (Рис.6). Содержит кнопки: стрелка – выбор объекта, создание функционального блока, создание стрелки для связи функциональных блоков с внешним миром и между собой, создание текста, редактор модели, переходы к родительской и дочерней моделям (диаграммам).

Рис.6. Панель BPWin Toolbox for Business Process Diagrams (IDEF0)

- ModelMart – панель кнопок специального инструментального средства, предназначенного для связывания пакета BPWin и пакета ERWin.

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

©2015-2019 сайт
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-04-27

1. Создание модели процессов в BPwin

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

Рис. 1.1. Интегрированная среда разработки модели BPwin 2.5

При запуске BPwin по умолчанию появляется основная панель инструментов, палитра инструментов (вид которой зависит от выбранной нотации) и, в левой части, навигатор модели - Model Explorer (рис. 1.1).

Функциональность панели инструментов доступна из основного меню Bpwin (табл. 1.1).

Таблица 1.1. Описание элементов управления основной панели инструментов Bpwin2.5

Элемент управления	Описание	Соответствующий пункт меню
	Создать новую модель	File/New
	Открыть модель	File/Open
	Сохранить модель	File/Save
	Напечатать модель	File/Print
	Выбор масштаба	View/Zoom
	Масштабирование	View/Zoom
	Проверка правописания	Tools/Spelling
	Включение и выключение навигатора модели Model Explorer	View/Model Explorer
	Включение и выключение дополнительной панели инструментов работы с ModelMart	ModelMart

При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново, или она будет открыта из файла либо из репозитория ModelMart, внести имя модели и выбрать методологию, в которой будет построена модель (рис. 1.2).

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

Рис. 1.2. Диалог создания модели

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

Установка цвета и шрифта объектов. Пункты контекстного меню Font Editor и Color Editor вызывают соответствующие диалоги для установки шрифта (в том числе его размера и стиля) и цвета объекта. Кроме того, BPwin позволяет установить шрифт по умолчанию для объектов определенного типа на диаграммах и в отчетах. Для этого следует выбрать меню Tools/Default Fonts, после чего появляется каскадное меню, каждый пункт которого служит для установки шрифтов для определенного типа объектов:

Context Activity - работа на контекстной диаграмме;

Context Arrow - стрелки на контекстной диаграмме;

Decomposition Activity - работы на диаграмме декомпозиции;

Decomposition Arrow - стрелки на диаграмме декомпозиции;

NodeTree Text - текст на диаграмме дерева узлов;

Frame User Text - текст, вносимый пользователем в каркасе диаграмм;

Frame System Text - системный текст в каркасе диаграмм;

Text Blocks - текстовые блоки;

Parent Diagram Text - текст родительской диаграммы;

Parent Diagram Title Text - текст заголовка родительской диаграммы;

Report Text - текст отчетов.

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

Наиболее удобным языком моделирования бизнес-процессов является IDEF0, предложенный более 20 лет назад Дугласом Россом (SoftTech, Inc.) и называвшийся первоначально SADT - Structured Analysis and Design Technique. (Подробно методология SADT излагается в книге Дэвида А. Марка и Клемента Мак-Гоуэна "Методология структурного анализа и проектирования SADT"M.:Meтaтexнoлoгия, 1993.) В начале 70-х годов вооруженные силы США применили подмножество SADT, касающееся моделирования процессов, для реализации проектов в рамках программы ICAM (Integrated Computer-Aided Manufacturing). В дальнейшем это подмножество SADT было принято в качестве федерального стандарта США под наименованием IDEF0. Подробные спецификации на стандарты IDEF можно найти на сайте http://www.idef.com .

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

Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы.

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

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

Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами, другими словами, мы должны определить, что мы будем в дальнейшем рассматривать как компоненты системы, а что как внешнее воздействие. На определение субъекта системы будет существенно влиять позиция, с которой рассматривается система, и цель моделирования - вопросы, на которые построенная модель должна дать ответ. Другими словами, первоначально необходимо определить область (Scope) моделирования. Описание области как системы в целом, так и ее компонентов является основой построения модели. Хотя предполагается, что в течение моделирования область может корректироваться, она должна быть в основном сформулирована изначально, поскольку именно область определяет направление моделирования и когда должна быть закончена модель. При формулировании области необходимо учитывать два компонента - широту и глубину. Широта подразумевает определение границ модели - мы определяем, что будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком уровне детализации модель является завершенной. При определении глубины системы необходимо не забывать об ограничениях времени - трудоемкость построения модели растет в геометрической прогрессии от глубины декомпозиции. После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему; поскольку все объекты модели взаимосвязаны, внесение нового объекта может быть не просто арифметической добавкой, но в состоянии изменить существующие взаимосвязи. Внесение таких изменений в готовую модель является, как правило, очень трудоемким процессом (так называемая проблема "плавающей области").

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

Почему этот процесс должен быть замоделирован?

Что должна показывать модель?

Что может получить читатель?

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

Точка зрения (Viewpoint). Хотя при построении модели учитываются мнения различных людей, модель должна строиться с единой точки зрения. Точку зрения можно представить как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования. Очевидно, что описание работы предприятия с точки зрения финансиста и технолога будет выглядеть совершенно по-разному, поэтому в течение моделирования важно оставаться на выбранной точке зрения. Как правило, выбирается точка зрения человека, ответственного за моделируемую работу в целом. Часто при выборе точки зрения на модель важно задокументировать дополнительные альтернативные точки зрения. Для этой цели обычно используют диаграммы FEO (For Exposition Only), которые будут описаны в дальнейшем.

IDEF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения. Для внесения области, цели и точки зрения в модели IDEF0 в BPwin следует выбрать пункт меню Edit/Model Properties, вызывающий диалог Model Properties (рис. 1.3). В закладке Purpose следует внести цель и точку зрения, а в закладку Definition - определение модели и описание области.

Рис. 1.3. Диалог задания свойств модели

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

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

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

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

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

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

Рис. 1.4. Отчет по модели

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

Модель может содержать четыре типа диаграмм:

Контекстную диаграмму (в каждой модели может быть только одна контекстная диаграмма);

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

Диаграммы дерева узлов;

Диаграммы только для экспозиции (FEO).

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

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

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

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

Рис. 1.6. Редактор задания свойств работы

Для внесения имени работы следует щелкнуть по работе правой кнопкой мыши, выбрать в меню Name Editor и в появившемся диалоге внести имя работы. Для описания других свойств работы служит диалог Activity Properties (рис. 1.6).

Рис. 1.5. Пример контекстной диаграммы

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

Возникает диалог Activity Box Count (рис. 1.7), в котором следует указать нотацию новой диаграммы и количество работ на ней. Остановимся пока на нотации IDEF0 и щелкнем на ОК. Появляется диаграмма декомпозиции (рис. 1.8). Допустимый интервал числа работ 2-8. Декомпозировать работу на одну работу не имеет смысла: диаграммы с количеством работ более восьми получаются перенасыщенными и плохо читаются. Для обеспечения наглядности и лучшего понимания моделируемых процессов рекомендуется использовать от трех до шести блоков на одной диаграмме.

Рис. 1.7. Диалог Activity Box Count

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

на палитре инструментов, а затем по свободному месту на диаграмме.

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

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

Рис. 1.8. Пример диаграммы декомпозиции

Каждая из работ на диаграмме декомпозиции может быть в свою очередь декомпозирована. На диаграмме декомпозиции работы нумеруются автоматически слева направо. Номер работы показывается в правом нижнем углу. В левом верхнем углу изображается небольшая диагональная черта, которая показывает, что данная работа не была декомпозирована. Так, на рис. 1.9 работа "Сборка изделия" имеет номер 3 и не была еще декомпозирована. Работа "Контроль качества" (номер 4) имеет нижний уровень декомпозиции.

Рис. 1.9. Пример декомпозируемых работ

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

В IDEF0 различают пять типов стрелок:

Вход (Input) - материал или информация, которые используются или преобразуется работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Каждый тип стрелок подходит к определенной стороне прямоугольника, изображающего работу, или выходит из нее. Стрелка входа рисуется как входящая в левую грань работы. При описании технологических процессов (для этого и был придуман IDEF0) не возникает проблем определения входов. Действительно, "Сырье" на рис. 1.5 - это нечто, что перерабатывается в процессе "Изготовление изделия" для получения результата. При моделировании ИС, когда стрелками являются не физические объекты, а данные, не все так очевидно. Например, при "Приеме пациента" карта пациента может быть и на входе и на выходе, между тем качество этих данных меняется. Другими словами, в нашем примере для того, чтобы оправдать свое назначение, стрелки входа и выхода должны быть точно определены с тем, чтобы указать на то, что данные действительно были переработаны (например, на выходе - "Заполненная карта пациента"). Очень часто сложно определить, являются ли данные входом или управлением. В этом случае подсказкой может служить то, перерабатываются/изменяются ли данные в работе или нет. Если изменяются, то скорее всего это вход, если нет - управление.

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

Выход (Output) - материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы. На рис. 1.5 стрелка "Готовое изделие" является выходом для работы "Изготовление изделия".

Механизм (Mechanism) - ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т. д. Стрелка механизма рисуется как входящая в нижнюю грань работы. На рис. 1.5 стрелка "Персонал предприятия" является механизмом для работы "Изготовление изделия". По усмотрению аналитика стрелки механизма могут не изображаться в модели.

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

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

Для внесения граничной стрелки входа следует:

Щелкнуть по кнопке с символом стрелки

в палитре инструментов перенести курсор к левой стороне экрана, пока не появится начальная штриховая полоска;

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

Вернуться в палитру инструментов и выбрать опцию редактирования стрелки

Щелкнуть правой кнопкой мыши на линии стрелки, во всплывающем меню выбрать Name Editor и добавить имя стрелки в закладке Name диалога IDEF0 Arrow Properties.

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

Имена вновь внесенных стрелок автоматически заносятся в словарь (Arrow Dictionary).

Рис. 1.10. Диалог IDEF0 Arrow Properties

ICOM-коды. Диаграмма декомпозиции предназначена для детализации работы. В отличие от моделей, отображающих структуру организации, работа на диаграмме верхнего уровня в IDEF0 - это не элемент управления нижестоящими работами. Работы нижнего уровня - это то же самое, что работы верхнего уровня, но в более детальном изложении. Как следствие этого границы работы верхнего уровня - это то же самое, что границы диаграммы декомпозиции. ICOM (аббревиатура от Input, Control, Output и Mechanism) - коды, предназначенные для идентификации граничных стрелок. Код ICOM содержит префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер (рис. 1.11).

Рис. 1.11. Фрагмент диаграммы декомпозиции с ICOM -кодами (I1, С1 и С2)

BPwin вносит ICOM-коды автоматически. Для отображения ICOM-кодов следует включить опцию Show ICOM codes на закладке Presentation диалога Model Properties (меню Edit/Model Properties).

Рис. 1.12. Словарь стрелок

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

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

Несвязанные граничные стрелки (unconnected border arrow). При декомпозиции работы входящие в нее и исходящие из нее стрелки (кроме стрелки вызова) автоматически появляются на диаграмме декомпозиции (миграция стрелок), но при этом не касаются работ. Такие стрелки называются несвязанными и воспринимаются в BPwin как синтаксическая ошибка.

Рис. 1.13. Пример несвязанных стрелок

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

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

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

Связь по входу (output-input), когда стрелка выхода вышестоящей работы (далее - просто выход) направляется на вход нижестоящей (например, на рис. 1.14 стрелка "Детали" связывает работы "Изготовление деталей" и "Сборка изделия").

Рис. 1.14. Связь по входу

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

Рис. 1.15. Связь по управлению

Обратная связь по входу (output-input feedback), когда выход нижестоящей работы направляется на вход вышестоящей. Такая связь, как правило, используется для описания циклов. На рис. 1.16 стрелка "Дрек" связывает работы "Переработка сырья" и "Контроль качества", при этом выявленный на контроле брак направляется на вторичную переработку.

Рис. 1.16. Обратная связь по входу

Обратная связь по управлению (output-control feedback), когда выход нижестоящей работы направляется на управление вышестоящей (стрелка "Рекомендации", рис. 1.17). Обратная связь по управлению часто свидетельствует об эффективности бизнес - процесса. На рис. 1.17 качество изделия может быть повышено путем непосредственного регулирования процессами изготовления деталей и сборки изделия в зависимости от результата (выхода) работы "Контроль качества"

Рис. 1.17. Обратная связь по управлению

Связь выход-механизм (output-mechanism), когда выход одной работы направляется на механизм другой. Эта взаимосвязь используется реже остальных и показывает, что одна работа подготавливает ресурсы, необходимые для проведения другой работы (рис. 1.18).

Явные стрелки. Явная стрелка имеет источником одну-единственную работу и назначением тоже одну-единственную работу.

Рис. 1.18. Связь выход-механизм

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

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

Рис. 1.19. Пример именования разветвляющейся стрелки

Если стрелка именована до разветвления, а после разветвления какая-либо из ветвей не именована, то подразумевается, что эти ветви соответствуют именованию. Если при этом какая-либо ветвь после разветвления осталась неименованной, то подразумевается, что она моделирует те же данные или объекты, что и ветвь до разветвления (рис. 1.20).

Рис. 1.20. Другой пример именования разветвляющейся стрелки

Недопустима ситуация, когда стрелка до разветвления не именована, а после разветвления не именована какая-либо из ветвей. BPwin определяет такую стрелку как синтаксическую ошибку (рис. 1.21).

Рис. 1.21. Пример неверного именования разветвляющейся стрелки

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

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

Рис. 1.22. Неразрешенная (unresolved) стрелка

Для их "перетаскивания" наверх нужно сначала выбрать кнопку

на палитре инструментов и щелкнуть по квадратным скобкам граничной стрелки. Появляется диалог Border Arrow Editor (рис. 1.23).

Рис. 1.23. Диалог Border Arrow Editor

Если щелкнуть по кнопке Resolve Border Arrow, стрелка мигрирует на диаграмму верхнего уровня, если по кнопке Change To Tunnel - стрелка будет затоннелирована и не попадет на другую диаграмму. Тоннельная стрелка изображается с круглыми скобками на конце (рис. 1.24).

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

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

Рис. 1.24. Типы тоннелирования стрелок

Все работы модели нумеруются. Номер состоит из префикса и числа. Может быть использован префикс любой длины, но обычно используют префикс А. Контекстная (корневая) работа дерева имеет номер АО. Работы i декомпозиции АО имеют номера А1, А2, A3 и т. д. Работы декомпозиции нижнего уровня имеют номер родительской работы и очередной порядковый номер, например работы декомпозиции A3 будут иметь номера А31, А32, АЗЗ, А34 и т. д. Работы образуют иерархию, где каждая работа может иметь одну родительскую и несколько дочерних работ, образуя дерево. Такое дерево называют деревом узлов, а вышеописанную нумерацию - нумерацией по узлам. Имеются незначительные варианты нумерации, которые i можно настроить в закладке Presentation диалога Model Properties (меню Edit/Model Properties).

Диаграммы IDEF0 имеют двойную нумерацию. Во-первых, диаграммы имеют номера по узлу. Контекстная диаграмма всегда имеет номер А-0, декомпозиция контекстной диаграммы - номер А0, остальные диаграммы декомпозиции - номера по соответствующему узлу (например, Al, A2, А21, А213 и т. д.). BPwin автоматически поддерживает нумерацию по узлам, т. е. при проведении декомпозиции создается новая диаграмма и ей автоматически присваивается соответствующий номер. В результате проведения экспертизы диаграммы могут уточняться и изменяться, следовательно, могут быть созданы различные версии одной и той же (с точки зрения ее расположения в дереве узлов) диаграммы декомпозиции. BPwin позволяет иметь в модели только одну диаграмму декомпозиции в данном узле. Прежние версии диаграммы можно хранить в виде бумажной копии либо как FEO-диаграмму. (К сожалению, при создании FEO-диаграмм отсутствует возможность отката, т. е. можно получить из диаграммы декомпозиции FEO, но не наоборот.) В любом случае следует отличать различные версии одной и той же диаграммы. Для этого существует специальный номер - C-number, который должен присваиваться автором модели вручную. C-number - это произвольная строка, но рекомендуется придерживаться стандарта, когда номер состоит из буквенного префикса и порядкового номера, причем в качестве префикса используются инициалы автора диаграммы, а порядковый номер отслеживается автором вручную, например МСВ00021.

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

Рис. 1.25. Диаграмма дерева узлов

Для создания диаграммы дерева узлов следует выбрать в меню пункт Insert/Node Tree. Возникает диалог формирования диаграммы дерева узлов Node Tree Definition (рис. 1.26).

Рис. 1.26. Диалог настройки диаграммы дерева узлов

В диалоге Node Tree Definition следует указать глубину дерева - Number of Levels (по умолчанию 3) и корень дерева (по умолчанию - родительская работа текущей диаграммы). По умолчанию нижний уровень декомпозиции показывается в виде списка, остальные работы - в виде прямоугольников. Для отображения всего дерева в виде прямоугольников следует выключить опцию Bullet Last Level. При создании дерева узлов следует указать имя диаграммы, поскольку, если в нескольких диаграммах в качестве корня на дереве узлов использовать одну и ту же работу, все эти диаграммы получат одинаковый номер (номер узла + постфикс N, например AON) и в списке открытых диаграмм (пункт меню Window) их можно будет различить только по имени.

Диаграммы "только для экспозиции" (FEO) часто используются в модели для иллюстрации других точек зрения, для отображения отдельных деталей, которые не поддерживаются явно синтаксисом IDEF0. Диаграммы FEO позволяют нарушить любое синтаксическое правило, поскольку по сути являются просто картинками - копиями стандартных диаграмм и не включаются в анализ синтаксиса. Например, работа на диаграмме FEO может не иметь стрелок управления и выхода. С целью обсуждения определенных аспектов модели с экспертом предметной области может быть создана диаграмма только с одной работой и одной стрелкой, поскольку стандартная диаграмма декомпозиции содержит множество деталей, не относящихся к теме обсуждения и дезориентирующих эксперта. Но если FEO используется для иллюстрации альтернативных точек зрения (альтернативный контекст), рекомендуется все-таки придерживаться синтаксиса IDEF0. Для создания диаграммы FEO следует выбрать пункт меню Insert/FEO Diagram. В возникающем диалоге Create New FEO Diagram следует указать имя диаграммы FEO и тип родительской диаграммы (рис. 1.27).

Рис. 1.27. Диалог создания FEO-диаграммы

Новая диаграмма получает номер, который генерируется автоматически (номер родительской диаграммы по узлу + постфикс F, например A1F).

На рис. 1.28 показан типичный пример диаграммы декомпозиции с граничными рамками, которые называются каркасом диаграммы.

Рис. 1.28. Пример диаграммы декомпозиции с каркасом

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

Смысл элементов каркаса приведен в табл. 1.2 и 1.3.

Таблица 1.2. Поля заголовка каркаса (слева направо)

Поле	Смысл
Used At	Используется для указания на родительскую работу в случае, если на текущую диаграмму ссылались посредством стрелки вызова
Autor, Date, Rev, Prpject	Имя создателя диаграммы, дата создания и имя проекта, в рамках которого была создана диаграмма. REV-дата последнего редактирования диаграммы
Notes 123456789 10	Используется при проведении сеанса экспертизы. Эксперт должен (на бумажной копии диаграммы) указать число замечаний, вычеркивая цифру из списка каждый раз при внесении нового замечания
Status	Статус отображает стадию создания диаграммы, отображая все этапы публикации
Working	Новая диаграмма, кардинально обновленная диаграмма или новый автор диаграммы
Draft	Диаграмма прошла первичную экспертизу и готова к дальнейшему обсуждению
Recommended	Диаграмма и все ее сопровождающие документы прошли экспертизу. Новых изменений не ожидается
Publication	Диаграмма готова к окончательной печати и публикации
Reader	Имя читателя (эксперта)
Date	Дата прочтения (экспертизы)
Context	Схема расположения работ в диаграмме верхнего уровня. Работа, являющаяся родительской, показана темным прямоугольником, остальные – светлым. На контекстной диаграмме (А-0) показана надпись ТОР. В левом нижнем углу показывается номер по узлу родительской диаграммы:

Таблица 1.3. Поля подвала каркаса (слева направо)

Значения полей каркаса задаются в диалоге Diagram Properties (меню Edit/Diagram Properties) - рис. 1.29.

Рис. 1.29. Диалог Diagram Properties

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

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

Обе сливаемые модели должны быть открыты в Bpwin.

Имя модели-источника, которое присоединяют к модели-цели, должно совпадать с именем стрелки вызова работы в модели-цели (рис. 1.30).

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

Имена контекстной работы подсоединяемой модели-источника и работы на модели-цели, к которой мы подсоединяем модель-источник, должны совпадать (рис. 1.30).

Модель-источник должна иметь по крайней мере одну диаграмму декомпозиции.

Рис. 1.30. Условия слияния моделей

Для слияния моделей нужно щелкнуть правой кнопкой мыши по работе со стрелкой вызова в модели-цели и во всплывающем меню выбрать пункт Merge Model.

Рис. 1.31. Стрелка вызова работы "Сборка изделия" модели-цели

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

Рис. 1.32. Диалог Continue with merge?

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

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

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

Рис. 1.33. Вид моделей в Model Explorer после слияния. Выделены модель-источник, и присоединенная ветвь модели-цели

В реальных диаграммах к каждой работе может подходить и от каждой может отходить около десятка стрелок. Если диаграмма содержит 6-8 работ, то она может содержать 30-40 стрелок, причем они могут сливаться, разветвляться и пресекаться. Такие диаграммы могут стать очень плохо читаемыми. В IDEF0 существуют соглашения по рисованию диаграмм, которые призваны облегчить чтение и экспертизу модели. Некоторые из этих правил BPwin поддерживает автоматически, выполнение других следует обеспечить вручную.

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

Следует максимально увеличивать расстояние между входящими или выходящими стрелками на одной грани работы. Если включить опцию Line Drawing: Automatically space arrows на закладке Layout диалога Model Properties (меню Edit/Model Properties), BPwin будет располагать стрелки нужным образом автоматически.

Следует максимально увеличить расстояние между работами, поворотами и пересечениями стрелок.

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

Обратные связи по входу рисуются "нижней" петлей, обратная связь по управлению - "верхней" (см. рис. 1.15, 1.17). BPwin автоматически рисует обратные связи нужным образом. Его можно "обмануть", но лучше этого не делать.

Циклические обратные связи следует рисовать только в случае крайней необходимости, когда подчеркивают значение повторно используемого объекта. Принято изображать такие связи на диаграмме декомпозиции. BPwip не позволяет создать циклическую обратную связь за один прием. Если все же необходимо изобразить такую связь, следует сначала создать обычную связь по входу, затем разветвить стрелку, направить новую, ветвь обратно ко входу работы-источника и, наконец, удалить старую ветвь стрелки выхода (рис. 1.34).

Рис. 1.34. Пример обратной циклической связи

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

Рис. 1.35. Минимизация пересечений и поворотов стрелок

Если нужно изобразить связь по входу, необходимо избегать "нависания" работ друг над другом. В этом случае BPwin изображает связи по входу в виде петли, что затрудняет чтение диаграмм (рис. 1.36).

Рис. 1.36. Пример правильного (справа) и неправильного (слева) расположения работ при изображении связи по входу

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

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

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

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

Читатель рецензирует папку и записывает свои комментарии. Замечания вносятся в диаграмму по определенным правилам. Если читатель решил внести замечание, он должен указать номер замечания, затем внести текст замечания и в каркасе диаграммы в разделе Notes зачеркнуть цифру, соответствующую номеру замечания (рис. 1.37).

Рис. 1.37. Внесение замечаний в диаграмму

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

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

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

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

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

Model Report. Этот отчет уже упоминался в 1.2.1. Он включает информацию о контексте модели - имя модели, точку зрения, область, цель, имя автора, дату создания и др.

Diagram Report. Отчет по конкретной диаграмме. Включает список объектов (работ, стрелок, хранилищ данных, внешних ссылок и т. д.).

Diagram Object Report. Наиболее полный отчет по модели. Может включать полный список объектов модели (работ, стрелок с указанием их типа и др.) и свойства, определяемые пользователем.

Activity Cost Report. Отчет о результатах стоимостного анализа. Будет рассмотрен ниже.

Arrow Report. Отчет по стрелкам. Может содержать информацию из словаря стрелок, информацию о работе-источнике, работе-назначении стрелки и информацию о разветвлении и слиянии стрелок.

DataUsage Report. Отчет о результатах связывания модели процессов и модели данных. (Будет рассмотрен ниже.)

Model Consistency Report. Отчет, содержащий список синтаксических ошибок модели.

Синтаксические ошибки IDEF0 с точки зрения BPwin разделяются на три типа:

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

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

Третий тип ошибок BPwin позволяет допустить, но детектирует их. Полный их список можно получить в отчете Model Consistency Report. Это единственный неопциональный отчет в BPwin. Список ошибок может содержать, например, неименованные работы и стрелки (unnamed arrow, unnamed activity), несвязанные стрелки (unconnected border arrow), неразрешенные стрелки (unresolved (square tunneled) arrow connections), работы, не имеющие по крайней мере одной стрелки выхода и одной стрелки управления (Activity "Сборка блоков" has no Control, Activity "Сборка блоков" has no Output), и т. д. Пример отчета Model Consistency Report приведен на рис. 1.38.

Рис. 1.38. Отчет Model Consistency Report

При выборе пункта меню, который соответствует какому-либо отчету, появляется диалог настройки отчета. Для каждого из семи типов отчетов он выглядит по-своему. Рассмотрим типичный диалог Arrow Report (рис. 1.39).

Рис. 1.39. Диалог Arrow Report

Раскрывающийся список Standart Reports позволяет выбрать один из стандартных отчетов. Стандартный отчет - это запоминаемая комбинация переключателей, флажков и других элементов управления диалога. Для создания собственного стандартного отчета необходимо задать опции отчета, ввести имя отчета в поле списка выбора и щелкнуть по кнопке New. BPwin сохраняет информацию о стандартном отчете в файле BPWINRPT.INI. Все определения этого файла доступны из любой модели. Единственное ограничение - свойства, определяемые пользователем (User-Defined Properties). Они сохраняются в виде указателя и поэтому доступны только из "родной" модели. Стандартный отчет можно изменить (кнопка Update) или удалить(кнопка Delete).

В правом верхнем углу диалога находится группа управляющих элементов для выбора формата отчета. Доступны следующие форматы:

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

Fixed Column - каждое поле печатается,в собственной колонке;

Tab-Comma Delimited - каждое поле печатается в собственной колонке. Колонки разделяются знаком табуляции или запятыми;

DDE Table - данные передаются по DDE приложению, например MS Word или Excel;

RPTwin - отчет создается в формате Platinum RPTwin - специализированного генератора отчетов, который входит в поставку BPwin.

Опция Ordering (на отчете по стрелкам отсутствует) сортирует данные по какому-либо значению.

Опция Multi-Valued Format регулирует вывод полей в отчете при группировке данных:

Repeating Group - детальные данные объединяются в одно поле, между значениями вставляется +.

Filled - дублирование данных для каждого заголовка группы;

Header (опция по умолчанию) - печатается заголовок группы, затем -детальная информация.

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

BPwin предоставляет аналитику два инструмента для оценки модели -стоимостный анализ, основанный на работах (Activity Based Costing, ABC), и свойства, определяемые пользователем (User Defined Properties, UDP). ABC является широко распространенной методикой, используемой международными корпорациями и государственными организациями (в том числе Департаментом обороны США) для идентификации истинных движителей затрат в организации.

Стоимостный анализ представляет собой соглашение об учете, используемое для сбора затрат, связанных с работами, с целью определить общую стоимость процесса. Стоимостный анализ основан на модели работ, потому что количественная оценка невозможна без детального понимания функциональности предприятия. Обычно ABC применяется для того, чтобы понять происхождение выходных затрат и облегчить выбор нужной модели работ при реорганизации деятельности предприятия (Business Process Reengineering, BPR). С помощью стоимостного анализа можно решить такие задачи, как определение действительной стоимости производства продукта, определение действительной стоимости поддержки клиента, идентификация работ, которые стоят больше всего (те, которые должны быть улучшены в первую очередь), обеспечение менеджеров финансовой мерой предлагаемых изменений т. д.

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

ABC включает следующие основные понятия:

объект затрат - причина, по которой работа выполняется, обычно, основной выход работы, стоимость работ есть суммарная стоимость объектов затрат ("Готовое изделие", рис. 1.40).

Рис. 1.40. Иллюстрация терминов ABC

движитель затрат - характеристики входов и управлений работы ("Сырье", "Чертеж", рис. 1.40), которые влияют на то, как выполняется и как долго длится работа;

центры затрат, которые можно трактовать как статьи расхода.

При проведении стоимостного анализа в BPwin сначала задаются единицы измерения времени и денег. Для задания единиц измерения следует вызвать диалог Model Properties (меню Edit/Model Properties), закладка ABC Units (рис. 1.41).

Если в списке выбора отсутствует необходимая валюта (например, рубль), ее можно добавить. Символ валюты по умолчанию берется из настроек Windows. Диапазон измерения времени в списке Unit of measurment достаточен для большинства случаев - от секунд до лет.

Рис. 1.41. Настройка единиц измерения валюты и времени

Затем описываются центры затрат (cost centers). Для внесения центров затрат необходимо вызвать диалог Cost Center Editor (меню Edit/ABC Cost Centers (рис. 1.42).

Каждому центру затрат следует дать подробное описание в окне Definition. Список центров затрат упорядочен. Порядок в списке можно менять при помощи стрелок, расположенных справа от списка. Задание определенной последовательности центров затрат в списке, во-первых, облегчает последующую работу при присвоении стоимости работам, а во-вторых, имеет значение при использовании единых стандартных отчетов в разных моделях. Хотя, как было указано в 1.2.5, BPwin сохраняет информацию о стандартном отчете в файле BPWINRPT.INI, информация о центрах затрат и UDP сохраняется в виде указателей, т. е. хранятся не названия центров затрат, а их номера. Поэтому, если нужно использовать один и тот же стандартный отчет в разных моделях, списки центров затрат должны быть в них одинаковы.

Рис. 1.42. Диалог Cost Center Editor

Для задания стоимости работы (для каждой работы на диаграмме декомпозиции) следует щелкнуть правой кнопкой мыши по работе и на всплывающем меню выбрать Cost Editor (рис. 1.43). В диалоге Activity Cost указывается частота проведения данной работы в рамках общего процесса (окно Frequency) и продолжительность (Duration). Затем следует выбрать в списке один из центров затрат и в окне Cost задать его стоимость. Аналогично назначаются суммы по каждому центру затрат, т. е. задается стоимость каждой работы по каждой статье расхода. Если в процессе назначения стоимости возникает необходимость внесения дополнительных центров затрат, диалог Cost Center Editor вызывается прямо из диалога Activity Cost соответствующей кнопкой.

Рис. 1.43. Задание стоимости работ в диалоге Activity Cost

Общие затраты по работе рассчитываются как сумма по всем центрам затрат. При вычислении затрат вышестоящей (родительской) работы сначала вычисляется произведение затрат дочерней работы на частоту работы (число раз, которое работа выполняется в рамках проведения родительской работы), затем результаты складываются. Если во всех работах модели включен режим Compute from Decompositions, подобные вычисления автоматически проводятся по всей иерархии работ снизу вверх (рис. 1.44).

Рис. 1.44. Вычисление затрат родительской работы

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

Для проведения более тонкого анализа можно воспользоваться специализированным средством стоимостного анализа EasyABC (ABC Technology, Inc.). BPwin имеет двунаправленный интерфейс с EasyABC. Для экспорта данных в EasyABC следует выбрать пункт меню File/Export/Node Tree , задать в диалоге Export Node Tree необходимые настройки и экспортировать дерево узлов в текстовый файл (.txt). Файл экспорта можно импортировать в EasyABC. После проведения необходимых расчетов результирующие данные можно импортировать из EasyABC в BPwin. Для импорта нужно выбрать меню File/Import/Costs и в диалоге Import Activity Costs выбрать необходимые установки.

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

Внешний осмотр - стоимость 50 руб.;

Пробное включение - стоимость 150 руб.;

Испытание на стенде - стоимость 300 руб.

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

300 руб. (Испытание на стенде)*8 +150 руб. (Пробное включение) *4 +

50 руб. (Внешний осмотр) *2 = 3100 руб.

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

50 руб. (Внешний осмотр) *8 +150 руб. (Пробное включение) *4 + + 300 руб. (Испытание на стенде) *2 = 1600 руб.

Следовательно, с целью минимизации затрат первой должна быть выполнена наиболее дешевая работа, затем - средняя по стоимости и в конце - наиболее дорогая (рис. 1.45).

Рис. 1.45. Фрагмент диаграммы декомпозиции работы "Контроль качества"

Результаты стоимостного анализа наглядно представляются на специальном отчете BPwin - Activity Cost Report (меню Report/Activity Cost Report). Отчет позволяет документировать имя, номер, определение и стоимость работ, как суммарную, так и раздельно по центрам затрат (рис. 1.46).

Рис. 1.46. Диалог настройки отчета по стоимости работ

Результаты отображаются и непосредственно на диаграммах. В левом нижнем углу прямоугольника работы может показываться либо стоимость (по умолчанию), либо продолжительность, либо частота проведения работы. Настройка отображения осуществляется в диалоге Model Properties (меню Edit/Model Properties), закладка Display, ABC Data, ABC Units.

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

Для описания UDP служит диалог User-Defined Property Name Editor (меню Edit/UDP Definition) (рис. 1.47). В верхнем окне диалога вносится имя UDP, в списке выбора Datatype описывается тип свойства. Имеется возможность задания 18 различных типов UDP, в том числе управляющих команд и массивов, объединенных по категориям. Для внесения категории следует задать имя категории в окне New Category/Member и щелкнуть по кнопке Add Category. Для присвоения свойства категории необходимо выбрать UDP из списка, затем категорию из списка категорий и щелкнуть по кнопке Update. Одна категория может объединять несколько свойств, в то же время одно свойство может входить в несколько категорий. Свойство типа List может содержать массив предварительно определенных значений. Для определения области значений UDP типа List следует задать значение свойства в окне New Category/Member и щелкнуть по кнопке Add Member. Значения из списка можно редактировать и удалять.

Рис. 1.47. Диалог описания UDP

Например, категория "Загрязнение окружающей среды" может объединять свойство "загрязнение воды" типа Real Number и свойство "загрязнение воздуха" типа Integer List с предварительно определенной областью значений (1, 2, 3, 4, 5).

Каждой работе можно поставить в соответствие набор UDP. Для этого следует щелкнуть правой кнопкой мыши по работе и выбрать пункт меню UDP Editor. В закладке UDP Values диалога IDEF0 Activity Properties можно задать значения UDP. Свойства типа List отображаются списком выбора, который заполнен предварительно определенными значениями. Свойства типа Command могут иметь в качестве значения командную строку, которая выполняется при нажатии на кнопку!!!. Например, свойство "Спецификации" категории "Дополнительная документация" может иметь значение "C:\MSOffice97\Office\WINWORD.EXE sped.doc".

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

Результат задания проанализировать в отчете Diagram Object Report (меню Report/Diagram Object Report) (рис. 1.48).

Рис. 1.48. Диалог настройки отчета Diagram Object Report

В левом нижнем углу диалога настройки отчета показывается список UDP. С помощью кнопки Activity Categories можно установить фильтр по категориям.

Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет модельную систему как сеть связанных между собой работ. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпоративных системах обработки информации. DFD описывает:

функции обработки информации (работы);

документы (стрелки, arrow), объекты, сотрудников или отделы, которые учавствуют в обработке информации;

таблицы для хранения документов (хранилище данных, data store).

В Bpwin для построения диаграмм потоков данных используется нотация Гейна-Сарсона.

Для того чтобы дополнить модель IDEF0 диаграммой DFD, нужно в процессе декомпозиции в диалоге Activity Box Count “кликнуть” по радио-кнопке DFD. В палитре инструментов на новой диаграмме DFD появляются новые кнопки:

– добавить в диаграмму хранилище данных (Data store). Хранилище данных позволяет описать данные, которые необходимо сохранить в памяти прежде, чем использовать в работах;

Рис. 1.49. Пример диаграммы DFD

В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы - движение объектов (data flow), хранение объектов (data stores), поставка и распространение объектов (external entities) (рис. 1.49).

В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, DFD рассматривает систему как совокупность предметов. Контекстная диаграмма часто включает работы и внешние ссылки. Работы обычно именуются по названию системы, например "Система обработки информации". Включение внешних ссылок в контекстную диаграмму не отменяет требования методологии четко определить цель, область и единую точку зрения на моделируемую систему.

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

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

Стрелки (Потоки данных). Стрелки описывают движение объектов из одной части системы в другую. Поскольку в DFD каждая сторона работы не имеет четкого назначения, как в IDEF0, стрелки могут подходить и выходить из любой грани прямоугольника работы. В DFD также применяются двунаправленные стрелки для описания диалогов типа "команда-ответ" между работами, между работой и внешней сущностью и между внешними сущностями (рис. 1.50).

Рис. 1.50. Внешняя сущность

Хранилище данных. В отличие от стрелок, описывающих объекты в движении, хранилища данных изображают объекты в покое (рис. 1.51).

Рис. 1.51. Хранилище данных

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

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

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

Альтернативным подходом является подход, популярный при создании программного обеспечения, называемый событийным разделением (event partitioning), в котором различные диаграммы DFD выстраивают модель системы. Во-первых, логическая модель строится как совокупность работ и документирования того, что они (эти работы) должны делать.

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

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

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

Нумерация объектов. В DFD номер каждой работы может включать префикс, номер родительской работы (А) и номер объекта. Номер объекта -это уникальный номер работы на диаграмме. Например, работа может иметь номер А.12.4. Уникальный номер имеют хранилища данных и внешние сущности независимо от их расположения на диаграмме. Каждое хранилище данных имеет префикс D и уникальный номер, например D5. Каждая внешняя сущность имеет префикс Е и уникальный номер, например Е5.

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

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

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

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

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

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

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

Единицы работы - Unit of Work (UOW). UOW, также называемые работами (activity), являются центральными компонентами модели. В IDEF3 работы изображаются прямоугольниками с прямыми углами и имеют имя, выраженное отглагольным существительным, обозначающим процесс действия, одиночным или в составе фразы, и номер (идентификатор); другое имя существительное в составе той же фразы обычно отображает основной выход (результат) работы (например, "Изготовление изделия"). Часто имя существительное в имени работы меняется в процессе моделирования, поскольку модель может уточняться и редактироваться. Идентификатор работы присваивается при создании и не меняется никогда. Даже если работа будет удалена, ее идентификатор не будет вновь использоваться для других работ. Обычно номер работы состоит из номера родительской работы и порядкового номера на текущей диаграмме.

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

Старшая (Precedence) - сплошная линия, связывающая единицы работ (UOW). Рисуется слева направо или сверху вниз. Показывает, что работа-источник должна закончиться прежде, чем работа-цель начнется.

Отношения (Relational Link)

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

Потоки объектов (Object Flow)

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

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

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

Рис. 1.52. Временная диаграмма выполнения работ

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

Смысл каждого типа приведен в табл. 1.4.

Таблица 1.4. Типы перекрестков

Все перекрестки на диаграмме нумеруются, каждый номер имеет префикс J. Можно редактировать свойства перекрестка при помощи диалога Definition Editor. В отличие от IDEF0 и DFD в IDEF3 стрелки могут сливаться и разветвляться только через перекрестки.

-(добавить в диаграмму объект ссылки - Referent) в палитре инструментов. Объект ссылки изображается в виде прямоугольника, похожего на прямоугольник работы. Имя объекта ссылки задается в диалоге Referent (пункт всплывающего меню Name Editor), в качестве имени можно использовать имя какой-либо стрелки с других диаграмм или имя сущности из модели данных. Объекты ссылки должны быть связаны с единицами работ или перекрестками пунктирными линиями. Официальная спецификация IDEF3 различает три стиля объектов ссылок - безусловные (unconditional), синхронные (synchronous) и асинхронные (asynchronous). BPwin поддерживает только безусловные объекты ссылок. Синхронные и асинхронные объекты ссылок, используемые в диаграммах переходов состояний объектов, не поддерживаются.

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

Таблица 1.5. Типы объектов ссылок

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

Рис. 1.54. Номер единицы работы (VOW)

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

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

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

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

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

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

Таблица 1.6. Диапазоны номеров работ

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

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

В результате дополнения диаграмм IDEF0 диаграммами DFD и IDEF3 может быть создана смешанная модель, которая наилучшим образом описывает все стороны деятельности предприятия (рис. 1.55). Иерархию работ в смешанной модели можно увидеть в окне Model Explorer. Работы в нотации IDEF0 изображаются зеленым цветом, IDEF3 - желтым, DFD - синим.

Рис. 1.55. Представление смешанной модели в окне Model Explorer

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

Рис. 1.56. Пример имитационной модели

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

Рис. 1.57. Фрагмент диаграммы IDEF3, соответствующий имитационной модели с рис. 1.56

Имитационная модель включает следующие основные элементы:

Источники и цели (Bourses и Destinations). Источники - это элементы, от которых в модель поступает информация или объекты. По смыслу они близки к понятиям "внешняя ссылка" на DFD-диаграМмах или "объект ссылки" на диаграммах IDEF3. Скорость поступления данных или объектов от источника обычно задается статистической функцией. Цель - это устройство для приема информации или объектов.

Очереди (Queues). Понятие очереди близко к понятию хранилища данных на DFD-диаграммах - это место, где объекты ожидают обработки. Времена обработки объектов (производительность) в разных работах могут быть разными (например, "Загрузка из бункера", "Наполнение", "Закупорка", см. рис. 1.56, 1.57). В результате перед некоторыми работами могут накапливаться объекты, ожидающие своей очереди. Часто целью имитационного моделирования является минимизация количества объектов в очередях. Тип очереди в имитационной модели может быть конкретизирован. Очередь может быть похожа на стек - пришедшие последними в очередь объекты первыми отправляются на дальнейшую обработку (LIFO: last-in-first-out). Альтернативой стеку может быть последовательная обработка, когда первыми на дальнейшую обработку отправляются объекты, пришедшие первыми (FIFO: first -in-first-out). Могут быть заданы и более сложные алгоритмы обработки очереди.

Оборудование (Facilities). Оборудование - это аналог работ в модели процессов. В имитационной модели может быть задана производительность оборудования.

BPwin не имеет собственных инструментов, позволяющих создавать имитационные модели, однако можно экспортировать модель IDEF3 в специализированное средство создания таких моделей - BPSimulator 3.0 (производитель - Systems Modeling Corporation, http://www.sm.com).

Для экспорта модели в BPSimulator необходимо настроить ODBC-источник и подготовить модель к экспорту. Для подготовки модели необходимо настроить свойства, определяемые пользователем UDP, специально включенные в BPwin для целей экспорта. Соответствующие UDP описаны в файле sinudps.bpl, который находится в директории samples/bpsim и является шаблоном модели, предназначенной для экспорта. Для использования этих свойств необходимо слить словари модели - шаблона sinudps.bpl и текущей модели. Задание соответствующих UDP (диалог IDEF3 Activity Properties, закладка UDP Values, см. рис. 1.58) позволяет автоматически установить значения и свойства объектов имитационной модели в BPSimulator.

Рис. 1.58. Диалог задания свойств, определяемых пользователем для экспорта в BPSimulator

Для экспорта модели IDEF3 в BPSimulator следует выбрать меню File/Export/в BPSimulator. Экспорт осуществляется через файл MS Excel (.xls). Для импорта данных в BPSimulator необходимо открыть новую модель и импортировать соответствующий файл.