WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     || 2 | 3 |
УФИМСКИЙ ГОСУДАРСТВЕННЫЙ АВИАЦИОННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ КАФЕДРА АСУ МОДЕЛИРОВАНИЕ ЭКОНОМИЧЕСКИХ И ПРОИЗВОДСТВЕННЫХ ПРОЦЕССОВ ПРЕДПРИЯТИЙ С ИСПОЛЬЗОВАНИЕМ 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). Код содержит префикс, соответствующий типу стрелки. Коды вносятся автоматически.

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

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

Pages:     || 2 | 3 |










© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

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