WWW.DISS.SELUK.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА
(Авторефераты, диссертации, методички, учебные программы, монографии)

 

УФИМСКИЙ ГОСУДАРСТВЕННЫЙ АВИАЦИОННЫЙ ТЕХНИЧЕСКИЙ

УНИВЕРСИТЕТ

КАФЕДРА АСУ

МОДЕЛИРОВАНИЕ ЭКОНОМИЧЕСКИХ И ПРОИЗВОДСТВЕННЫХ

ПРОЦЕССОВ ПРЕДПРИЯТИЙ С ИСПОЛЬЗОВАНИЕМ BPWin

МЕТОДИЧЕСКИЕ УКАЗАНИЯ

к лабораторным работам по курсу “Технико-экономический анализ деятельности предприятий” для подготовки инженеров по специальностям 071900 “Информационные системы в экономике и 351400 “Прикладная информатика в экономике” Составители: Г.Г. Куликов, Н.О. Никулина, Е.Б. Старцева, Э.Р.Алимбекова УДК 681.3 Моделирование экономических и производственных процессов предприятий с использованием BPWin: Методические указания к лабораторным работам по курсу "Технико-экономический анализ деятельности предприятий" / Уфимск. гос. авиац.

техн. ун-т; Сост.: Г.Г. Куликов, Н.О. Никулина, Э.Р. Алимбекова, Е.Б. Старцева. Уфа, 2001. - 33 с.

Содержатся основные сведения, необходимые для работы с одним из современных программных продуктов фирмы Platinum Technology - BPWin, предназначенным для структурного анализа и проектирования информационных систем. Рассматриваются принципы проектирования информационных систем с использованием CASE-средств, приводится подробное описание программного продукта. Обсуждается порядок проведения лабораторных работ.

Предназначены для студентов старших курсов специальностей “Информационные системы в экономике” и “Прикладная информатика в экономике”.

Табл.3 Ил. 11. Библиогр.: 1 назв.

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

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

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

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





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

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

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

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





ЛАБОРАТОРНАЯ РАБОТА

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

IDEF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения. Для внесения области, цели и точки зрения в модели IDEF0 в BPwin следует выбрать пункт меню 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 Диаграммы IDEF Основу методологии IDEF0 составляет графический язык описания бизнес-процессов.

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

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

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

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

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

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

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

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

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

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

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

2.6 Стрелки Взаимодействие работ с внешним миром и между собой описывается в виде стрелок.

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

Например, "Заготовка", "Изделие".

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

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

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

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

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

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

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

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

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

Различают пять видов связей работ:

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

Диаграммы IDEF0 имеют двойную нумерацию.

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

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

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

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

Смысл элементов каркаса приведен в таблицах 1 и 2.

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

Схема расположения работ в диаграмме верхнего уровня. Работа, являющаяся родительской, показана темным прямоугольником, Context остальные - светлым. На контекстной диаграмме показывается Node Номер узла диаграммы (номер родительской работы) Title Имя диаграммы. По умолчанию - имя родительской работы Number C-Number, уникальный номер версии диаграммы Номер страницы, может использоваться как номер страницы при Page 2.10 Слияние и расщепление моделей Возможность слияния и расщепления моделей обеспечивает коллективную работу над проектом.

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

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

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

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

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

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

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

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

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

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

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

Цикл автор-читатель содержит следующие этапы:

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

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

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

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

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

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

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

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

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

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

1) стоимостной анализ (Activity Based Costing) 2) свойства, определяемые пользователем (User Defined Properties) ABC включает следующие основные понятия:

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

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

Рисунок1 - Интегрированная среда разработки модели BPwin Процесс моделирования какой-либо системы в 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), в котором следует указать количество работ в новой диаграмме.

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

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

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

1. щелкнуть по кнопке с символом стрелки в палитре инструментов, перенести курсор к левой стороне экрана, пока не появится начальная штриховая полоска 2. щелкнуть один раз по полоске (начало стрелки) и еще раз в левой части работы со стороны входа (конец стрелки) 3. вернуться в палитру инструментов и выбрать опцию редактирования стрелки 4. щелкнуть правой кнопкой мыши на линии стрелки, во всплывающем меню выбрать Arrow Name и добавить имя стрелки в окне диалога.

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 5 - Диалог настройки диаграммы дерева узлов 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. В появившемся диалоге следует указать имя создаваемой модели.

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

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

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

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

- DDE Table - данные передаются по DDE приложению, например MS Word или Exсel - RPTwin - отчет создается в формате Platinum RPTwin - специализированного генератора отчетов, который входит в поставку BPwin Опция Ordering (отсутствует в отчете по стрелкам) сортирует данные по какому-либо значению.

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

- Repeating Group - детальные данные объединяются в одно поле, между значениями вставляется + - Filled - дублирование данных для каждого заголовка группы - Header - печатается заголовок группы, затем детальная информация Стоимостной анализ При проведении стоимостного анализа сначала задаются единицы измерения времени и денег. Для задания единиц измерения следует вызвать диалог ABC Units of Measure (меню Editor/ABC Units).

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

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

Рисунок 9 - Задание стоимости работ Рисунок 10 - Диалог настройки отчета по стоимости работ Для описания UDP служит диалог User Defined Property Name Editor (Editor/UDP Definition), показанный на рисунке 11.

В верхнем окне диалога вносится имя UDP, в списке выбора Datatype описывается тип свойств (возможно задание 18 различных типов).

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

4.1 Создание модели экономического или производственного процесса 1. Изучить методику моделирования при помощи BPWin, приведенную в п. 2;

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

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

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

5 Контрольные вопросы 1 Обоснуйте необходимость использования CASE-средств для моделирования экономических и производственных процессов.

2 Что представляет собой модель системы в нотации IDEF0?

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

4 Перечислите этапы экспертизы модели.

5 Какие виды стрелок существуют в модели, построенной с использованием BPWin?

6 Как проводится функционально-стоимостной анализ с использованием BPWin?

Список литературы 1. Маклаков С.В. BPWin и ERWin. CASE-средства разработки информационных систем. М.: ДИАЛОГ-МИФИ, 1999. - 256 с.



Похожие работы:

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ ФГБОУ ВПО СЕВЕРО-КАВКАЗСКИЙ ГОРНО-МЕТАЛЛУРГИЧЕСКИЙ ИНСТИТУТ (ГОСУДАРСТВЕННЫЙ ТЕХНОЛОГИЧЕСКИЙ УНИВЕРСИТЕТ) КАФЕДРА АВТОМАТИЗИРОВАННОЙ ОБРАБОТКИ ИНФОРМАЦИИ Методические указания к выполнению практических работ дисциплины Вычислительные системы для направления (ий) подготовки (специальности (ей)) 230100 Информатика и вычислительная техника Квалификация (степень) выпускника магистр Разработчик(и) программы: Шепилова Е.В. Владикавказ 2013 Оглавление Практическая...»

«Министерство образования Республики Беларусь Учреждение образования Белорусский государственный университет информатики и радиоэлектроники В. В. Бахтизин, Л. А. Глухова Технология разработки программного обеспечения Допущено Министерством образования Республики Беларусь в качестве учебного пособия для студентов высших учебных заведений по специальности Программное обеспечение информационных технологий Минск БГУИР 2010 УДК 004.413(075.8) ББК 32.973.26 – 018.2я73 Б30 Ре ц е н з е н ты : кафедра...»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования Томский государственный университет систем управления и радиоэлектроники (ТУСУР) Кафедра автоматизированных систем управления ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ Методические указания по самостоятельной и индивидуальной работе студентов по дисциплине Информационная безопасность направления подготовки 010400.62 Прикладная математика и информатика (квалификация...»

«Министерство образования Российской Федерации АМУРСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ Юридический факультет КУЛЬТУРОЛОГИЯ Учебное пособие Благовещенск 2001 УДК 71 (072) Печатается по решению К 90 Редакционно-издательского совета Амурского государственного университета Составители: Куляскина И.Ю., Титлина Е.Ю., Киселева О.В. КУЛЬТУРОЛОГИЯ: Учебное пособие. Благовещенск: Амурский гос. ун-т, 2001. Пособие включает краткое изложение содержания двух основных разделов курса культурологии: истории...»

«Московский государственный университет имени М. В. Ломоносова Научно-исследовательский институт ядерной физики имени Д. В. Скобельцына кафедра оптики и спектроскопии физического факультета О. Е. НАНИЙ, А. Н. ТУРКИН Оптические методы в информатике Москва Издательство Университетская книга 2010 УДК 535 ББК 22.34-я73-1 Н25 Наний О. Е., Туркин А. Н. Н25 Оптические методы в информатике : Учебное пособие / О. Е. Наний, А. Н. Туркин — М. : Университетская книга, 2010. — 112 с. : табл., ил. ISBN...»

«1 МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ Московский государственный университет геодезии и картографии (МИИГАиК) Людмила Николаевна Чабан АВТОМАТИЗИРОВАННАЯ ОБРАБОТКА АЭРОКОСМИЧЕСКОЙ ИНФОРМАЦИИ ДЛЯ КАРТОГРАФИРОВАНИЯ ГЕОПРОСТРАНСТВЕННЫХ ДАННЫХ. Учебное пособие. Москва 2013 2 УДК 528.83, 528.854, 528.856 Рецензенты: Доктор физико-математических наук, профессор Кондранин Т.В. (МФТИ) Кандидат технических наук Учаев Д.В. (МИИГАиК) Чабан Л.Н. Автоматизированная обработка...»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования Томский государственный университет систем управления и радиоэлектроники (ТУСУР) Кафедра автоматизированных систем управления ЗАЩИТА ИНФОРМАЦИИ Методические указания по самостоятельной и индивидуальной работе студентов по дисциплине Защита информации направления подготовки 230100.62 Информатика и вычислительная техника (квалификация (степень) бакалавр)...»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ Утверждаю Декан ФИнф Б.А.Гладких 2001 г. МЕТОДИЧЕСКОЕ ПОСОБИЕ по составлению бизнес-планов с использованием программного продукта “Project Expert” по курсу Экспертные системы в бизнес-планировании для специальности 351500 Математическое обеспечение и администрирование информационных систем Факультет информатики Томск Методическое пособие обсуждено на совместном заседании кафедр теоретических основ информатики и...»

«Федеральное агентство по образованию Уральский государственный технический университетУПИ И. А. Бабин, В. В. Лавров ТЕХНОЛОГИИ ОРГАНИЗАЦИИ И ПЕРЕДАЧИ ДАННЫХ В КОМПЬЮТЕРНЫХ СЕТЯХ Учебное электронное текстовое издание Подготовлено кафедрой Теплофизика и информатика в металлургии Методические указания к лабораторным работам по курсу Информационные технологии в металлургии для студентов специальности 150103 Теплофизика, автоматизация и экология промышленных печей. Методические указания содержат...»

«Министерство образования и науки Российской Федерации Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования Томский государственный университет систем управления и радиоэлектроники (ТУСУР) Кафедра автоматизации обработки информации (АОИ) УТВЕРЖДАЮ Зав. кафедрой АОИ д.т.н. профессор _Ю.П. Ехлаков МЕТОДИЧЕСКИЕ УКАЗАНИЯ К ВЫПОЛНЕНИЮ ЛАБОРАТОРНЫХ И САМОСТОЯТЕЛЬНЫХ РАБОТ по дисциплине Управление проектами для студентов направления 080700.62...»

«Сведения об учебно-методической, методической и иной документации, разработанной образовательной организацией для обеспечения образовательного процесса по специальности 230700.65 Прикладная информатика (в экономике) Наименование дисциплины по учебному Наименование учебно-методических, методических и иных материалов №п/п плану (автор, место издание, год издания, тираж) 1) Учебно-методический комплекс по дисциплине Иностранный язык, 2011г. 2) Basic English: учебное пособие./ Н.И. Киселева –...»

«МЕТОДИЧЕСКИЕ УКАЗАНИЯ для выполнения лабораторных работ по дисциплине Архитектура корпоративных информационных систем для студентов специальности 080700 – Бизнес-информатика Томск 2009 Федеральное агентство по образованию РФ ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ СИСТЕМ УПРАВЛЕНИЯ И РАДИОЭЛЕКТРОНИКИ (ТУСУР) УТВЕРЖДАЮ Зав. кафедрой АОИ д.т.н., профессор _ Ю.П. Ехлаков Методические указания для выполнения лабораторных работ по курсу АРХИТЕКТУРА КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ для студентов...»

«МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ИНСТИТУТ ЭЛЕКТРОННОЙ ТЕХНИКИ (ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ) КАФЕДРА КВАНТОВОЙ ФИЗИКИ И НАНОЭЛЕКТРОНИКИ Ю.И. Богданов Физико- статистические основы квантовой информатики Москва 2010 УДК 519+530.145 Рецензенты: доктор физико- математических наук, профессор кафедры квантовой электроники МГУ им. М.В. Ломоносова С.П. Кулик ; кандидат физико- математических наук, ведущий научный сотрудник Физикотехнологического института РАН В.В. Вьюрков Богданов Ю.И. Б.73 Физико- статистические...»

«МИНИСТЕР СТВО ОБЩЕГО И ПРО ФЕССИОНАЛЬНОГО О Б РА З О ВА Н И Я Р О С С И Й С К О Й Ф Е Д Е РА Ц И И ТА ГА Н Р О Г С К И Й Г О С УД А Р С Т В Е Н Н Ы Й РА Д И О Т Е Х Н И Ч Е С К И Й УНИВЕРСИТЕТ А.П. Дятлов СИСТЕМЫ СПУТНИКОВОЙ СВЯЗИ С ПОДВИЖНЫМИ ОБЪЕКТАМИ Таганрог 2004 УДК 621.396.931 Дятлов А.П. Системы спутниковой связи с подвижными объектами: Учебное пособие. Ч.1. Таганрог. ТРТУ. 2004. 95 с. Учебное пособие состоит из двух частей. В первой части рассмотрены классификация систем спутниковой...»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования Томский государственный университет систем управления и радиоэлектроники (ТУСУР) Кафедра автоматизированных систем управления (АСУ) Структуры и алгоритмы обработки данных в ЭВМ Методические указания по выполнению лабораторных работ студентов всех форм обучения для направления подготовки 230100.62 Информатика и вычислительная техника 2011 г. 2 Горитов А.Н....»

«Список опубликованных работ проф. Шермухамедова Аббас Таировича, д.ф-м.н. за 2009 учебный год 1. Совершенствование корпоративного управления в Узбекистане. // В тезисах докладов Двадцать вторые международные Плехановские чтения, 10 апреля 2009 г. РЭА им.Г.В.Плеханова. _М.: РЭА им.Г.В.Плеханова, 2009. – 159-160 с. 2. Информационная безопасность в банках // В материалах научно – практической конференции Хукукий информатика ва ахборот хавсизлиги сохаларини такомиллаштиришнинг долзарб масалалари...»

«ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ ИНДУСТРИАЛЬНЫЙ УНИВЕРСИТЕТ Е. А. Пушкарь ДИФФЕРЕНЦИАЛЬНЫЕ УРАВНЕНИЯ В ЗАДАЧАХ И ПРИМЕРАХ УЧЕБНО-МЕТОДИЧЕСКОЕ ПОСОБИЕ Москва 2007 ББК 22.161.6 УДК 517.9 П91 Рецензенты: В.Б. Миносцев, заслуженный работник ВШ РФ, доктор физикоматематических наук, профессор Московского государственного индустриального университета; Д.Л. Ревизников, доктор физико-математических наук, профессор Московского авиационного института (Технический...»

«МИНИСТЕРСТВО КУЛЬТУРЫ РОССИЙСКОЙ ФЕДЕРАЦИИ МОСКОВСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ КУЛЬТУРЫ И ИСКУССТВ МЕНЕДЖЕР ИНФОРМАЦИОННЫХ РЕСУРСОВ Учебно-методическое пособие Под общей редакцией профессора В.К. Клюева Рекомендовано Учебно-методическим объединением по образованию в области народной художественной культуры, социально-культурной деятельности и информационных ресурсов в качестве учебного пособия для студентов высших учебных заведений, обучающихся по специальности 071201 –...»

«Федеральное агентство по образованию Владивостокский государственный университет экономики и сервиса _ ИНЖЕНЕРНАЯ И КОМПЬЮТЕРНАЯ ГРАФИКА Учебная программа дисциплины по специальности 210305.65 Средства радиоэлектронной борьбы по направлению подготовки 210300.62 Радиотехника Владивосток Издательство ВГУЭС 2010 ББК 85.15 Учебная программа по дисциплине Инженерная и компьютерная графика составлена в соответствии с требованиями ГОС ВПО. Содержит организационно-методические указания и описание...»

«Международный консорциум Электронный университет Московский государственный университет экономики, статистики и информатики Евразийский открытый институт В.И. Хабаров Н.Ю. Попова Банковский маркетинг Учебное пособие Руководство по изучению дисциплины Учебная программа Москва 2005 УДК 336.71 ББК 65.262.1 Х 121 Хабаров В.И., Попова Н.Ю. БАНКОВСКИЙ МАРКЕТИНГ: Учебное пособие, руководство по изучению дисциплины, учебная программа / Московский государственный университет экономики, статистики и...»






 
© 2013 www.diss.seluk.ru - «Бесплатная электронная библиотека - Авторефераты, Диссертации, Монографии, Методички, учебные программы»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.