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

Стр 1 из 5Следующая ⇒

Федеральное агентство по образованию

Государственное образовательное учреждение высшего профессионального образования

«Восточно-Сибирский государственный технологический университет»

(ГОУ ВПО ВСГТУ)

______________________________________________

МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ С ИСПОЛЬЗОВАНИЕМ МЕТОДОЛОГИИ IDEF0

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

«Проектирование информационных систем»

Для студентов очной и заочной форм обучения специальностей

Прикладная информатика (в экономике)»,

Бизнес-информатика»

Составители:

Будаев Е.С.

Сунграпова И.С.

Улан-Удэ

Издательство ВСГТУ

2010

Данные методические указания предназначены для самостоятельного выполнения лабораторных занятий по дисциплине «Проектирование информационных систем». В работе приведен алгоритм выполнения лабораторных работ, рассмотрены теоретические и практические аспекты методологии IDEF0 с использованием специализированного программного продукта Process Modeler компании AllFusion, а также программных продуктов Microsoft Visio и Design/IDEF.

Ключевые слова: проектирование, IDEF0, DFD, информационные системы, методические указания, лабораторные работы.

Рецензент: к.т.н. Андронов В.В.

ВВЕДЕНИЕ

Целью самостоятельной работы студентов по дисциплине «Проектирование информационных систем» является использование теоретических знаний по методологии IDEF0 для создания моделей бизнес-процессов с использованием специализированного программного продукта Process Modeler компании AllFusion (ранее продукт назывался BPwin и выпускался под маркой компании Computer Associates), а также программных продуктов Microsoft Visio и Design/IDEF.

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

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

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

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

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

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

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

На современном рынке средств разработки ИС достаточно много систем, в той или иной степени удовлетворяющих перечисленным требованиям. CASE-средства ERwin и BPwin, разработанные фирмой Logic Works, а ныне принадлежащие компании AllFusion входят в число лучших на сегодняшний день. CASE -средство верхнего уровня BPwin (настоящее имя Process Modeler) поддерживает методологии IDEF0 (функциональная модель), IDEF3 (WorkFlow Diagram) и DFD (DataFlow Diagram). Функциональная модель предназначена для описания существующих бизнес-процессов на предприятии (так называемая модель AS-IS) и идеального положения вещей - того, к чему нужно стремиться (модель TO-BE). Методология IDEF0 предписывает построение иерархической системы диаграмм - единичных описаний фрагментов системы. Сначала проводится описание системы в целом и ее взаимодействия с окружающим миром (контекстная диаграмма), после чего проводится функциональная декомпозиция - система разбивается на подсистемы и каждая подсистема описывается отдельно (диаграммы декомпозиции). Затем каждая подсистема разбивается на более мелкие и так далее до достижения нужной степени подробности. После каждого сеанса декомпозиции проводится сеанс экспертизы: каждая диаграмма проверяется экспертами предметной области, представителями заказчика, людьми, непосредственно участвующими в бизнес-процессе. Такая технология создания модели позволяет построить модель, адекватную предметной области на всех уровнях абстрагирования. Если в процессе моделирования нужно осветить специфические стороны технологии предприятия, Process Modeler позволяет переключиться на любой ветви модели на нотацию IDEF3 или DFD и создать смешанную модель. Нотация DFD включает такие понятия, как внешняя ссылка и хранилище данных, что делает ее более удобной (по сравнению с IDEF0) для моделирования документооборота. Методология IDEF3 включает элемент "перекресток", что позволяет описать логику взаимодействия компонентов системы.

ЦЕЛЬ РАБОТЫ

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

ТЕОРЕТИЧЕСКИЕ СВЕДЕНИЯ

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

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

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

2.1 Цель моделирования

При построении модели должна быть поставлена цель, отвечающая на следующие вопросы:

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

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

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

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

2.2 Точка зрения

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

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

2.3 Модели AS-IS и TO-BE

Обычно сначала строится модель существующей организации работы - AS-IS (как есть). Анализ функциональной модели позволяет определить:

- наиболее слабые места - преимущества новых бизнес-процессов

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

Признаками неэффективной работы деятельности могут быть:

- бесполезные, неуправляемые и дублирующиеся работы;

- неэффективный документооборот;

- отсутствие обратных связей по управлению;

- отсутствие обратных связей по входу.

Найденные в модели AS-IS недостатки можно исправить при создании модели TO-BE (как будет) – модели новой организации бизнес-процессов. Модель TO-BE нужна для анализа альтернативных путей выполнения работы и документирования того, как компания будет делать бизнес в будущем.

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

2.4 Диаграммы IDEF0

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

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

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

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

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

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

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

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

2.5 Работы

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

2.6 Стрелки

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

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

2. Управление (Control) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Управление влияет на работу, но не преобразуется работой.

3. Выход (Output) - материал или информация, которые производятся работой. Работа без результата не имеет смысла и не должна моделироваться.

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

5. Вызов (Call) - специальная стрелка, указывающая на другую модель работы. Стрелка вызова используется для указания того, что некоторая работа выполняется за пределами моделируемой системы. В Process Modeler стрелки вызова используются в механизме слияния и разделения моделей.

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

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

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

1. связь по входу – стрелка выхода вышестоящей работы направляется на вход нижестоящей;

2. связь по управлению – выход вышестоящей работы направляется на управление нижестоящей;

3. обратная связь по входу – выход нижестоящей работы направляется на вход вышестоящей;

4. обратная связь по управлению – выход нижестоящей работы направляется на управление вышестоящей;

5. связь выход-механизм – выход одной работы направляется на механизм другой.

2.7 Нумерация работ и диаграмм

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

1. Диаграммы имеют номера по узлу. Контекстная диаграмма всегда имеет номер А-0, декомпозиция контекстной диаграммы - номер А0, остальные диаграммы декомпозиции - номера по соответствующему узлу (например, А1, А2, А12 и т.д.).

2. В результате проведения экспертизы диаграммы могут уточняться и изменяться, следовательно, могут быть созданы различные одной и той же (с точки зрения ее расположения в дереве узлов) диаграммы декомпозиции. Process Modeler позволяет иметь в модели только одну диаграмму декомпозиции в данном узле. Прежние версии диаграммы можно хранить в виде бумажной копии либо как FEO-диаграмму. Для того, чтобы отличать различные версии одной и той же диаграммы, существует специальный номер - C-number, который должен присваиваться автором модели вручную. C-number - это произвольная строка, но рекомендуется придерживаться стандарта, когда номер состоит из буквенного префикса и порядкового номера, причем в качестве префикса используются инициалы автора диаграммы, а порядковый номер отслеживается автором вручную, например MCB00021.

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

Диаграмма дерева узлов показывает иерархию работ в модели и позволяет рассмотреть всю модель целиком, но не показывает взаимосвязи между работами (стрелки). Работы могут менять свое расположение в дереве узлов многократно. Следует после каждого изменения создавать диаграмму дерева узлов. Process Modeler имеет мощный инструмент навигации по модели - Model Explorer, который позволяет представить иерархию работ и диаграмм в удобном и компактном виде.

2.9 Каркас диаграммы

Каркас диаграммы содержит заголовок (верхняя часть рамки) и подвал (нижняя часть). Смысл элементов каркаса приведен в таблицах 1 и 2.

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

Поле	Смысл
Used At	Используют для указания на родительскую работу, если на диаграмму ссылались стрелкой вызова
Author, Date, Rev, Project	Имя создателя диаграммы, дата создания и имя проекта, в рамках которого была создана диаграмма. Rev - дата последнего редактирования диаграммы.
Notes 1 2 3 4 5 6 7 8 9 10	Используется при проведении сеанса экспертизы. Эксперт должен (на бумажной копии диаграммы) указать число замечаний, вычеркивая цифру из списка каждый раз при внесении нового замечания.
Status	Статус отображает стадию создания диаграммы, отображая все этапы публикации.
Working	Новая диаграмма, кардинально обновленная диаграмма или новый автор диаграммы.
Draft	Диаграмма прошла первичную экспертизу и готова к дальнейшему обсуждению.
Recommended	Диаграмма и все ее сопровождающие документы прошли экспертизу. Новых изменений не ожидается.
Publication	Диаграмма готова к окончательной печати и публикации.
Reader	Имя читателя (эксперта).
Date	Дата прочтения (экспертизы).
Context	Схема расположения работ в диаграмме верхнего уровня. Работа, являющаяся родительской, показана темным прямоугольником, остальные - светлым. На контекстной диаграмме показывается надпись TOP.
Node	Номер узла диаграммы (номер родительской работы)
Title	Имя диаграммы. По умолчанию - имя родительской работы
Number	C-Number, уникальный номер версии диаграммы
Page	Номер страницы, может использоваться как номер страницы при формировании папки

2.10 Слияние и расщепление моделей

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

Для слияния необходимо выполнять следующие условия:

1) обе модели должны быть открыты в Process Modeler;

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

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

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

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

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

2.11 Рекомендации по рисованию диаграмм

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

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

- следует максимально увеличивать расстояние между входящими или выходящими стрелками на одной грани работы

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

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

- обратные связи по входу рисуются "нижней" петлей, обратная связь по управлению -" верхней"

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

- следует минимизировать число пересечений, петель и поворотов стрелок

- если нужно изобразить связь по входу, необходимо избегать " нависания" работ друг над другом. В этом случае Process Modeler изображает связи по входу в виде петли, что затрудняет чтение диаграмм.

2.12 Проведение экспертизы

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

- аналитик создает диаграмму на основе общих знаний, анализа документации и опроса экспертов;

- диаграмма должна быть помещена в архив библиотекарем;

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

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

- папка возвращается библиотекарю для регистрации и передачи автору;

- автор вносит ответ на замечания и изменения в модель;

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

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

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

2.13 Создание отчетов

Всего имеется семь типов отчетов. Они представлены в таблице 3.

Таблица 3. Виды отчетов Process Modeler

Наименование	Описание
Model Report (Отчет по модели)	Включает информацию о контексте модели, точку зрения, область, цель, имя автора, дату создания и др.
Diagram Report (Отчет по конкретной диаграмме)	Включает список объектов (работ, стрелок, хранилищ данных, внешних ссылок и т. д.).
Diagram Object Report (Наиболее полный отчет по модели)	Включает полный список объектов модели (работ, стрелок и т.д.) и свойства, определяемые пользователем.
Activity Cost Report (Отчет о результатах стоимостного анализа)	Содержит имя, номер, определение и стоимость работ, как суммарную, так и раздельно по центрам затрат.
Arrow Report (Отчет по стрелкам)	Содержит информацию из словаря стрелок, информацию о работе-источнике, работе-назначении стрелки и информацию о разветвлении и слиянии стрелок.
Data Usage Report (Отчет о результатах связывания модели процессов и модели данных)
Model Consistency Report (Отчет о синтаксических ошибках)	Содержит список синтаксических ошибок модели.

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

1. Ошибки, которые Process Modeler выявить не в состоянии. Например, проверка чтобы имя работы было выражено отглагольным существительным, а имя стрелки существительным, - это ручная работа, которая должна выполняться аналитиками.

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

3. Ошибки, которые Process Modeler позволяет допустить, но детектирует их. Полный их список можно получить в отчете Model Consistency Report.

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

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

Аналитику предоставляются два инструмента для оценки модели:

1) стоимостной анализ (Activity Based Costing)

2) свойства, определяемые пользователем (User Defined Properties).

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

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

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

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

ОПИСАНИЕ РАБОТЫ С ПАКЕТОМ

3.1 Определение контекста

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

Рис.1. Интегрированная среда разработки модели Process Modeler.

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

1. Project Name - название проекта, которое будет показано в верхней части рамки диаграммы;

2. Model Name - название модели;

3. Model Definition - описание модели;

4. Model Scope - диапазон модели. Диапазон модели содержит информацию о том, что отражено в модели. Диапазон описывает ширину и глубину раскрытия процесса, описываемого моделью. Пример: «Технологические, финансовые и управленческие аспекты деятельности предприятия».

5. Model Viewpoint - точка зрения Содержит информацию об эксперте, точка зрения которого рассматривается как основная при построении модели. Пример: «Руководитель предприятия».

6. Model Status - статус модели;

7. Model Time Frame - вид модели;

8. Purpose - цель моделирования Пример: «Описать функциональность предприятия с целью написания спецификаций информационной системы»;

9. Source - источники информации, используемой при моделировании;

10. Creation and Revision Dates - дата создания и последнего изменения модели;

11. Author Name and Initials - фамилия и инициалы автора модели.

3.2 Рисование диаграммы

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

1. Activity Name - наименование работы (если не определено ранее);

2. Definition - описание работы;

3. Source - источник информации о работе;

4. Status - статус работы (Working, Draft, Recommended, Publication, или Other);

5. Author Name - имя автора (в поле автоматически вписываются данные из описания модели).

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

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

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

На контекстной диаграмме изображаются граничные стрелки. Для внесения граничной стрелки входа надо:

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

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

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

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

Рис. 3. Диалог словаря стрелок.

Стрелки управления, выхода, механизма и выхода изображаются аналогично. Имена вновь внесенных стрелок автоматически заносятся в словарь Arrow Dictionary. Для отображения ICOM-кодов следует включить опцию Show ICOM-codes в окне Model Presentation Editor. Необходимо определить стрелки в словаре стрелок (пункт меню Editor/Arrow Dictionary) (см. рис.3).

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

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

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

Диалог Border Arrow Editor содержит следующую информацию:

· Resolve Border Arrow - стрелка мигрирует на диаграмму верхнего уровня.

· Change To Tunnel - стрелка станет тоннельной и будет отмечена круглыми скобками на конце.

После каждого изменения диаграммы необходимо создавать диаграмму дерева узлов. Для ее создания следует выбрать в меню пункт File/Create Node Tree. Возникает диалог Node Tree Definition (см. рис.5).

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

1. В поле "Diagram Name" указать наименование диаграммы.

2. Указать корень дерева в поле «Top Activity» (по умолчанию - родительская работа текущей диаграммы).

3. Указать глубину дерева в поле «Number of Levels» (по умолчанию -3).

4. Опция «Bullet Last Level» позволяет отобразить все дерево в виде прямоугольников.

5. Опция «Draw Node Numbers» позволяет отобразить номер для каждой работы.

6. Опция «Draw Boxes» позволяет отобразить прямоугольник вокруг каждой работы.

7. Необходимо выбрать требуемый размер прямоугольника: Fit each box to text - размер зависит от длины названия работы One size per row - одинаковый размер для каждого уровня. All one size - все прямоугольники одного размера.

8. Опция «Include Kit» позволяет отобразить рамку вокруг дерева.

9. Опция «Include Title» позволяет отобразить наименование диаграммы. Если поле «Diagram Name» не заполнено, то наименование работы, находящейся в корне дерева, является наименованием диаграммы. Диаграмма дерева узлов показана на рисунке 6.

Слияние и расщепление моделей.

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

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

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

Создание отчетов.

При выборе пункта меню, который соответствует какому-либо отчету, появляется диалог настройки отчета. Диалог Arrow Report показан на рисунке 7. Для выбранного отчета доступны следующие форматы:

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

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

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

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

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

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

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

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

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

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

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

При проведении стоимостного анализа сначала задаются единицы измерения времени и денег. Для задания единиц измерения следует вызвать диалог ABC Units of Measure (меню Editor/ABC Units).

Каждому центру затрат необходимо дать описание в Cost Centers Editor (пункт Editor/ABC Cost Centers (рис.8).

Рис. 8. Диалог описания центров затрат

Рис. 9. Задание стоимости работ.

Для задания стоимости работы (для каждой работы на диаграмме) следует щелкнуть правой кнопкой мыши по работе и на всплывающем меню выбрать Activity Cost. В диалоге (см. рис.9) указывается частота проведения данной работы в рамках общего процесса (Frequency) и продолжительность (Duration). Результаты стоимостного анализа наглядно представляются на специальном отчете Activity Based Costing Report (меню Report/Activity Cost Report). Отчет позволяет документировать имя, номер, определение и стоимость работ, как суммарную, так и разделенную по центрам затрат (рис.10).

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

Для описания UDP служит диалог User Defined Property Name Editor (Editor/UDP Definition), показанный на рисунке 11. В верхнем окне диалога вносится имя UDP, в списке выбора Datatype описывается тип свойств (возможно задание 18 различных типов).

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

4 Порядок выполнения работы

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

4.1 Создание модели экономического или производственного процесса

1. Изучить методику моделирования при помощи Process Modeler, приведенную в п. 2;

2. Провести анализ данных, полученных в п. 4:

- определить цели моделирования;

- определить точку зрения на модель;

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

- определить основные этапы выполнения заданного процесса.

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

4. Оценить экономическую эффективность заданного процесса, используя ABC- метод.

Дата добавления: 2018-02-15; просмотров: 1639; Мы поможем в написании вашей работы!

Поделиться с друзьями:

12 3 4 5 Следующая ⇒

Мы поможем в написании ваших работ!