Описание BPwin
Общее описание интерфейса BPwin 4.1. Установка цвета и шрифта объектов. Принципы построения модели IDEF0. Рекомендации по рисованию диаграмм. Анализ методика расчета стоимости проекта. Дополнения созданной модели процессов диаграммами DFD и Workflow.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | русский |
| Дата добавления | 17.12.2009 |
| Размер файла | 168,1 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Размещено на http://www.allbest.ru/
1. Инструментальная среда BPwin 4.1.
1.1 Общее описание интерфейса BPwin 4.1.
BPwin имеет достаточно простой и интуитивно понятный интерфейс пользователя, дающий возможность аналитику создать сложные модели при минимальных усилиях.
При запуске BPwin по умолчанию появляется основная панель инструментов, палитра инструментов (вид которой зависит от выбранной нотации) и, в левой части, навигатор модели - Model Explorer. Функциональность панели инструментов доступно для основного меню BPwin (табл. 1.1).
Таблица 1.1 Описание элементов управления основной панели инструментов BPwin 4.1
|
Элементы управления |
Описание |
Соответствующий пункт меню |
|
|
Создать новую модель |
File/New |
||
|
Открыть модель |
File/Open |
||
|
Сохранить модель |
File/Save |
||
|
Напечатать модель |
File/Print |
||
|
Вызвать генератор отчетов Report Builder |
Tools/Report Builder |
||
|
Выбор масштаба |
View/Zoom |
||
|
Масштабирование |
View/Zoom |
||
|
Проверка правописания |
Tools/Spelling |
||
|
Включение и выключение навигатора модели Model Explorer |
View/Model Explorer |
||
|
Включение и выключение дополнительной панели инструментов работы с ModelMart |
ModelMart |
1.2 Создание новой модели
При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново, или она будет открыта из файла либо из хранилища ModelMart, внести имя модели и выбрать методологию, в которой будет построена модель.
Как было указано выше BPWin поддерживает три методологии - IDEF0, IDEF3, DFD, каждая из которых решает свои специфические задачи. В BPWin возможно построение смешаных моделей, т.е. модель может содержать отновременно как диаграммы IDEF0, так и диаграммы IDEF3 и DFD. Состав палитры инструментов изменяется автоматически, когда происходит переключение с одной нотации на другую, поэтому палитра инструментов будет рассмотрена позже.
После щелчка по кнопке OK появляется диалог Properties for New Models, в который следует внести свойства модели.
Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует некоторым набором данных. Работа изображается в виде прямоугольников, данные - в виде стрелок. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется всплывает контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта.
1.3 Установка цвета и шрифта объектов
Пункты контекстного меню Font и Color вызывают диалог Arrow Properties или Activity Properies для установки шрифта (в том числе его размера и стиля) и цвета объекта. В нижней части вкладки Font диалогов Arrow Properties и Activity Properies находятся группа опций Apply setting to, позволяющих изменить шрифт для всех работ или стрелок на текущей диаграмме, в модели, и группа Global, позволяющая изменить шрифт одновременно для всех элементов модели.
Кроме того, BPwin позволяет установить шрифт по умолчанию для объектов определенного типа на диаграммах и в отчетах. Для этого следует выбрать меню Model/Default Fonts, после чего появляется следующее каскадное меню, каждый пункт которого служит для установки шрифтов для определенного типа объектов:
· Context Activity - работа на контекстной диаграмме;
· Context Arrow - стрелки на контекстной диаграмме;
· Decomposition Activity - работы на диаграмме декомпозиции;
· Decomposition Arrow - стрелки на диаграмме декомпозиции;
· Node Tree Text - текст на диаграмме дерево узлов;
· Frame User Text - текст, вносимый пользователем в каркасе диаграмм;
· Frame System Text - системный текст в каркасе диаграмм;
· Text Blocks - текстовые блоки;
· Parent Diagram Text - текст родительской диаграммы;
· Parent Diagram Title Text - текст заголовка родительской диаграммы;
· Report Text - текст отчетов.
· 2. Создание модели в стандарте IDEF0
2.1 Принципы построения модели IDEF0
На начальных этапах создания ИС необходимо понять, как работает организация, которую собираются автоматизировать. Для описания работы предприятия необходимо построить модель. Такая модель должна быть адекватна предметной области; следовательно, она должна содержать в себе знания всех участников бизнес-процессов организации.
Наиболее удобным языком моделирования бизнес-процессов является IDEFO, предложенный более 20 лет назад Дугласом Россом (SoftTech, Inc.) и называвшийся первоначально SADT - Structured Analysis and Design Technique. В начале 70-х годов вооруженные силы США применили подмножество SADT, касающееся моделирования процессов, для реализации проектов в рамках программы ICAM (Integrated Computer-Aided Manufacturing). В дальнейшем это подмножество SADT было принято в качестве федерального стандарта США под наименованием IDEFO.
В IDEFO система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной - функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.
Под моделью в IDEFO понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы.
Моделируемая система рассматривается как произвольное подмножество Вселенной. Произвольное потому, что, во-первых, мы сами умозрительно определяем, будет ли некий объект компонентом системы, или мы будем его рассматривать как внешнее воздействие, и, во-вторых, оно зависит от точки зрения на систему. Система имеет границу, которая отделяет ее от остальной Вселенной. Взаимодействие системы с окружающим миром описывается как вход (нечто, что перерабатывается системой), выход (результат деятельности системы), управление (стратегии и процедуры, под управлением которых производится работа) и механизм (ресурсы, необходимые для проведения работы). Находясь под управлением, система преобразует входы в выходы, используя механизмы.
Процесс моделирования какой-либо системы в IDEFO начинается с определения контекста, т. е. наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель.
Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами; другими словами, мы должны определить, что мы будем в дальнейшем рассматривать как компоненты системы, а что как внешнее воздействие. На определение субъекта системы будет существенно влиять позиция, с которой рассматривается система, и цель моделирования - вопросы, на которые построенная модель должна дать ответ; другими словами, первоначально необходимо определить область (Scope) моделирования. Описание области как системы в целом, так и ее компонентов является основой построения модели. Хотя предполагается, что в течение моделирования область может корректироваться, она должна быть в основном сформулирована изначально, поскольку именно область определяет направление моделирования и когда должна быть закончена модель. При формулировании области необходимо учитывать два компонента - широту и глубину. Широта подразумевает определение границ модели - мы определяем, что будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком уровне детализации модель является завершенной. При определении глубины системы необходимо не забывать об ограничениях времени - трудоемкость построения модели растет в геометрической прогрессии от глубины декомпозиции.
После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему; поскольку все объекты модели взаимосвязаны, внесение нового объекта может быть не просто арифметической добавкой, но в состоянии изменить существующие взаимосвязи. Внесение таких изменений в готовую модель является, как правило, очень трудоемким процессом (так называемая проблема "плавающей области").
Цель моделирования (Purpose). Модель не может быть построена без четко сформулированной цели. Цель должна отвечать на следующие вопросы:
· Почему этот процесс должен быть замоделирован?
· Что должна показывать модель?
· Что может получить читатель?
Формулировка цели позволяет команде аналитиков сфокусировать усилия в нужном направлении. Примерами формулирования цели могут быть следующие утверждения: "Идентифицировать и определить текущие проблемы, сделать возможным анализ потенциальных улучшений", "Идентифицировать роли и ответственность служащих для написания должностных инструкций", "Описать функциональность предприятия с целью написания спецификаций ИС" и т. д.
Точка зрения (Viewpoint). Хотя при построении модели учитываются мнения различных людей, модель должна строиться с единой точки зрения. Точку зрения можно представить как взгляд человека, который видит систему в нужном для моделирования аспекте. Точка зрения должна соответствовать цели моделирования. Очевидно, что описание работы предприятия с точки зрения финансиста и технолога будет выглядеть совершенно по-разному, поэтому в течение моделирования важно оставаться на выбранной точке зрения. Как правило, выбирается точка зрения человека, ответственного за моделируемую работу в целом. Часто при выборе точки зрения на модель важно задокументировать дополнительные альтернативные точки зрения. Для этой цели обычно используют диаграммы FEO (For Exposition Only).
IDЕF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения. Для внесения области, цели и точки зрения в модели IDEFO в BPwin следует выбрать пункт меню Model/Model Properties, вызывающий диалог Model Properties. Во вкладку Purpose следует внести цель и точку зрения, а во вкладку Definition - определение модели и описание области.
Во вкладке Status того же диалога можно описать статус модели (черновой вариант, рабочий, окончательный и т. д.), время создания и последнего редактирования (отслеживается в дальнейшем автоматически по системной дате). Во вкладке Source описываются источники информации для построения модели (например, "Опрос экспертов предметной области и анализ документации"). Вкладка General служит для внесения имени проекта и модели, имени и инициалов автора и временных рамок модели - AS-IS и ТО-ВЕ.
Модели AS-IS и ТО-ВЕ. Целью построения функциональных моделей обычно является выявление наиболее слабых и уязвимых мест деятельности организации, анализ преимуществ новых бизнес-процессов и степени изменения существующей структуры организации бизнеса. Анализ недостатков и "узких мест" начинают с построения модели AS-IS (Как есть), т. е. модели существующей организации работы. Модель AS-IS может строиться на основе изучения документации (должностных инструкций, положений о предприятии, приказов, отчетов и т. п.), анкетирования и опроса служащих предприятия, создания фотографии рабочего дня и других источников. Полученная модель AS-IS служит для выявления неуправляемых работ, работ не обеспеченных ресурсами, ненужных и неэффективных работ, дублирующихся работ и других недостатков в организации деятельности предприятия. Исправление недостатков, перенаправление информационных и материальных потоков приводит к созданию модели ТО-ВЕ (Как будет) - модели идеальной организации бизнес-процессов. Как правило, строится несколько моделей ТО-ВЕ, среди которых определяют наилучший вариант. Выбор оптимальной модели может осуществляться, например, с помощью метрик BPwin (например, стоимостный анализ).
Следует указать на распространенную ошибку при создании модели AS-IS - это создание идеализированной модели. Примером может служить создание модели на основе знаний руководителя, а не конкретного исполнителя работ. Руководитель знаком с тем, как предполагается выполнение работы по руководствам и должностным инструкциям, и часто не знает, как на самом деле подчиненные выполняют рутинные работы. В результате получается приукрашенная, искаженная модель, которая несет ложную информацию и которую невозможно в дальнейшем использовать для анализа. Такая модель называется SHOULD BE (Как должно бы быть).
Технология проектирования ИС подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов, т. е. создание модели ТО-ВЕ, и только на основе модели ТО-ВЕ строится модель данных, прототип и затем окончательный вариант ИС. Построение системы на основе модели AS-IS приводит к автоматизации предприятия по принципу "все оставить как есть, только чтобы компьютеры стояли", т. е. ИС автоматизирует несовершенные бизнес-процессы и дублирует, а не заменяет существующий документооборот. В результате внедрение и эксплуатация такой системы приводит лишь к дополнительным издержкам на закупку оборудования, создание программного обеспечения и сопровождение того и другого.
Иногда текущая модель AS-IS и будущая ТО-ВЕ различаются очень сильно, так что переход от начального состояния к конечному становится неочевидным. В этом случае необходима третья модель, описывающая процесс перехода от начального к конечному состоянию системы, поскольку такой переход - это тоже бизнес-процесс.
Результат описания модели можно получить в отчете Model Report. Диалог настройки отчета по модели вызывается из пункта меню Tools/Reports/Model Report. В диалоге настройки следует выбрать необходимые поля, при этом автоматически отображается очередность вывода информации в отчете .
Диаграммы IDEFO. Основу методологии IDEFO составляет графический язык описания бизнес-процессов. Модель в нотации IDEFO представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе.
Модель может содержать четыре типа диаграмм:
1. контекстную (в каждой модели может быть только одна контекстная диаграмма);
2. декомпозиции;
3. дерева узлов;
4. только для экспозиции (FEO).
Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой самое общее описание системы и ее взаимодействия с внешней средой. После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов, называются диаграммами декомпозиции. После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие и т. д., до достижения нужного уровня подробности описания. После каждого сеанса декомпозиции проводятся сеансы экспертизы - эксперты предметной области указывают на соответствие реальных бизнес-процессов созданным диаграммам. Найденные несоответствия исправляются, и только после прохождения экспертизы без замечаний можно приступать к следующему сеансу декомпозиции. Так достигается соответствие модели реальным бизнес-процессам на любом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента одинаков во всей модели.
Диаграмма дерева узлов показывает иерархическую зависимость работ, но не взаимосвязи между работами. Диаграмм деревьев узлов может быть в модели сколь угодно много, поскольку дерево может быть построено на произвольную глубину и не обязательно с корня.
Диаграммы для экспозиции (FEO) строятся для иллюстрации отдельных фрагментов модели, для иллюстрации альтернативной точки зрения либо для специальных целей.
2.2 Работа (Activity)
Работы обозначают поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Работы изображаются в виде прямоугольников. Все работы должны быть названы и определены. Имя работы должно быть выражено сочетанием отглагольного существительного, обозначающего процесс, например: "Изготовление детали", "Прием заказа" и т.д. Работа "Изготовление детали" может иметь, например, следующее определение: "Работа относится к полному циклу изготовления изделия от контроля качества сырья до отгрузки готового изделия заказчику". При создании новой модели (меню File/New) автоматически создается контекстная диаграмма с единственной работой, изображающей систему в целом.
Для внесения имени работы следует щелкнуть по работе правой кнопкой мыши, выбрать в меню Name и в появившемся диалоге внести имя работы. Для описания других свойств работы служит диалог Activity Properties .
Диаграммы декомпозиции содержат родственные работы, т. е. дочерние работы, имеющие общую родительскую работу. Для создания диаграммы декомпозиции следует щелкнуть по кнопке. Возникает диалог Activity Box Count, в котором следует указать нотацию новой диаграммы и количество работ на ней. Остановимся пока на нотации IDEFO и щелкнем на ОК. Появляется диаграмма декомпозиции.
Допустимый интервал числа работ 2-8. Декомпозировать работу на одну работу не имеет смысла: диаграммы с количеством работ более восьми получаются перенасыщенными и плохо читаются. Для обеспечения наглядности и лучшего понимания моделируемых процессов рекомендуется использовать от 3 до 6 блоков на одной диаграмме.
Если оказывается, что количество работ недостаточно, то работу можно добавить в диаграмму, щелкнув сначала по кнопке на палитре инструментов, а затем по свободному месту на диаграмме.
Работы на диаграммах декомпозиции обычно располагаются по диагонали от левого верхнего угла к правому нижнему.
Такой порядок называется порядком доминирования. Согласно этому принципу расположения в левом верхнем углу помещается самая важная работа или работа, выполняемая по времени первой. Далее вправо вниз располагаются менее важные или выполняемые позже работы. Такое расположение облегчает чтение диаграмм, кроме того, на нем основывается понятие взаимосвязей работ (см. ниже).
Каждая из работ на диаграмме декомпозиции может быть, в свою очередь, декомпозирована. На диаграмме декомпозиции работы нумеруются автоматически слева направо. Номер работы показывается в правом нижнем углу. В левом верхнем углу изображается небольшая диагональная черта, которая показывает, что данная работа не была декомпозирована. Так, на рис. 2.8 работа "Внешний вид" имеет номер 1 и не была еще декомпозирована. Работа "испытания на стенде" (номер 2) имеет нижний уровень декомпозиции.
2.3 Стрелка (Arrow)
Взаимодействие работ с внешним миром и между собой описывается в виде стрелок. Стрелки представляют собой некую информацию и обозначаются существительными (например, "Деталь", "Заказ") или именными сочетаниями (например, "Готовое изделие").
В IDEF0 различают пять типов стрелок:
1. Вход (Input) - материал или информация, которые используются или преобразуются работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Каждый тип стрелок подходит к определенной стороне прямоугольника, изображающего работу, или выходит из нее. Стрелка входа рисуется как входящая в левую грань работы. При описании технологических процессов (для этого и был придуман IDEF0) не возникает проблем определения входов. Действительно, "Сырье"- это нечто, что перерабатывается в процессе "Изготовление изделия" для получения результата. При моделировании ИС, когда стрелками являются не физические объекты, а данные, не все так очевидно. Например, при "Заказе клиента" заказ клиента может быть и на входе и на выходе, между тем качество этих данных меняется. Другими словами, в нашем примере для того, чтобы оправдать свое назначение, стрелки входа и выхода должны быть точно определены с тем, чтобы указать на то, что данные действительно были переработаны (например, на выходе - "Оформленный заказ клиента"). Очень часто сложно определить, являются ли данные входом или управлением. В этом случае подсказкой может служить то, перерабатываются/изменяются ли данные в работе или нет. Если изменяются, то скорее всего это вход, если нет - управление.
2. Управление (Control) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы. На рис.2.4 стрелка "Заказ" - управление для работы "Изготовление изделия". Управление влияет на работу, но не преобразуется работой. Если цель работы изменить процедуру или стратегию, то такая процедура или стратегия будет для работы входом. В случае возникновения неопределенности в статусе стрелки (управление или контроль) рекомендуется рисовать стрелку управления.
3. Выход (Output) - материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы. На рис. 2.4 стрелка "Готовое изделие" является выходом для работы "Изготовление изделия".
4. Механизм (Mechanism) - ресурсы, которые выполняют работу, например персонал предприятия, станки и т. д. Стрелка механизма рисуется как входящая в нижнюю грань работы. На рис. 2.4 стрелка "Персонал предприятия" является механизмом для работы "Изготовление изделия". По усмотрению аналитика стрелки механизма могут не изображаться в модели.
5. Вызов (Call) - специальная стрелка, указывающая на другую модель работы. Стрелка механизма рисуется как исходящая из нижней грани работы. Стрелка вызова используется для указания того, что некоторая работа выполняется за пределами моделируемой системы. В BPwin стрелки вызова используются в механизме слияния и разделения моделей.
Граничные стрелки. Стрелки на контекстной диаграмме служат для описания взаимодействия системы с окружающим миром. Они могут начинаться у границы диаграммы и заканчиваться у работы и наоборот. Такие стрелки называются граничными. Для внесения граничной стрелки входа надо:
· щелкнуть по кнопке с символом стрелки в палитре инструментов и перенести курсор к левой стороне экрана, пока не появится начальная темная полоска;
· щелкнуть один раз по полоске (откуда выходит стрелка) и еще раз в левой части работы со стороны входа (где заканчивается стрелка);
· вернуться в палитру инструментов и выбрать опцию редактирования стрелки;
· щелкнуть правой кнопкой мыши на линии стрелки, во всплывающем меню выбрать Name и добавить имя стрелки во вкладке Name диалога Arrow Properties .
Стрелки управления, выхода и механизма изображаются аналогично. Для рисования стрелки выхода, например, следует щелкнуть по кнопке с символом стрелки на палитре инструментов, щелкнуть в правой части работы со стороны выхода (где начинается стрелка), перенести курсор к правой стороне экрана, пока не появится начальная штриховая полоска, и щелкнуть один раз по штриховой полоске. Имена вновь внесенных стрелок автоматически заносятся в словарь (Arrow Dictionary). ICOM-коды. Диаграмма декомпозиции предназначена для детализации работы. В отличие от моделей, отображающих структуру организации, работа на диаграмме верхнего уровня в IDEF0 - это не элемент управления нижестоящими работами. Работы нижнего уровня - это то же самое, что и работы верхнего уровня, но в более детальном изложении. Как следствие этого границы работы верхнего уровня - это то же самое, что и границы диаграммы декомпозиции. ICOM (аббревиатура от Input, Control, Output и Mechanism) - коды, предназначенные для идентификации граничных стрелок. Код ICOM содержит префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер.
BPwin вносит ICOM-коды автоматически. Для отображения ICOM-кодов следует включить опцию ICOM codes на вкладке Display диалога Model Properties (меню Model/Model Properties).
Несвязанные граничные стрелки (unconnected border arrow). При декомпозиции работы входящие в нее и исходящие из нее стрелки (кроме стрелки вызова) автоматически появляются на диаграмме декомпозиции (миграция стрелок), но при этом не касаются работ. Такие стрелки называются несвязанными и воспринимаются в BPwin как синтаксическая ошибка. Для связывания стрелок входа, управления или механизма необходимо перейти в режим редактирования стрелок, щелкнуть по наконечнику стрелки и щелкнуть по соответствующему сегменту работы. Для связывания стрелки выхода необходимо перейти в режим редактирования стрелок, щелкнуть по сегменту выхода работы и затем по стрелке.
Внутренние стрелки. Для связи работ между собой используются внутренние стрелки, т. е. стрелки, которые не касаются границы диаграммы, начинаются у одной и кончаются у другой работы.
Для рисования внутренней стрелки необходимо в режиме рисования стрелок щелкнуть по сегменту (например, выхода) одной работы и затем по сегменту (например, входа) другой.
В IDEF0 различают пять типов связей работ:
1. Связь по входу (output-input), когда стрелка выхода вышестоящей работы (далее - просто выход) направляется на вход нижестоящей.
2. Связь по управлению (output-control), когда выход вышестоящей работы направляется на управление нижестоящей. Связь по входу показывает доминирование вышестоящей работы. Данные или объекты выхода вышестоящей работы не меняются в нижестоящей
3. Обратная связь по входу (output-input feedback), когда выход нижестоящей работы направляется на вход вышестоящей. Такая связь, как правило, используется для описания циклов.
4. Обратная связь по управлению (output-control feedback), когда выход нижестоящей работы направляется на управление вышестоящей. Обратная связь по управлению часто свидетельствует об эффективности бизнес-процесса. Качество изделия может быть повышено путем непосредственного регулирования процессами изготовления деталей и сборки изделия в зависимости от результата (выхода) работы "Контроль качества".
5. Связь выход-механизм (output-mechanism), когда выход одной работы направляется на механизм другой. Эта взаимосвязь используется реже остальных и показывает, что одна работа подготавливает ресурсы, необходимые для проведения другой работы.
Явные стрелки. Явная стрелка имеет источником одну-единственную работу и назначением тоже одну-единственную работу.
Разветвляющиеся и сливающиеся стрелки. Одни и те же данные или объекты, порожденные одной работой, могут использоваться сразу в нескольких других работах. С другой стороны, стрелки, порожденные в разных работах, могут представлять собой одинаковые или однородные данные или объекты, которые в дальнейшем используются или перерабатываются в одном месте. Для моделирования таких ситуаций в IDEF0 используются разветвляющиеся и сливающиеся стрелки. Для разветвления стрелки нужно в режиме редактирования стрелки щелкнуть по фрагменту стрелки и по соответствующему сегменту работы. Для слияния двух стрелок выхода нужно в режиме редактирования стрелки сначала щелкнуть по сегменту выхода работы, а затем по соответствующему фрагменту стрелки. Смысл разветвляющихся и сливающихся стрелок передается именованием каждой ветви стрелок. Существуют определенные правила именования таких стрелок. Рассмотрим их на примере разветвляющихся стрелок. Если стрелка именована до разветвления, а после разветвления ни одна из ветвей не именована, то подразумевается, что каждая ветвь моделирует те же данные или объекты, что и ветвь до разветвления.
Если стрелка именована до разветвления, а после разветвления какая-либо из ветвей не именована, то подразумевается, что эти ветви соответствуют именованию. Если при этом какая-либо ветвь после разветвления осталась неименованной, то подразумевается, что она моделирует те же данные или объекты, что и ветвь до разветвления.
Недопустима ситуация, когда стрелка до разветвления не именована, а после разветвления не именована какая-либо из ветвей. BPwin определяет такую стрелку как синтаксическую ошибку.
Правила именования сливающихся стрелок полностью аналогичны - ошибкой будет считаться стрелка, которая после слияния не именована, а до слияния не именована какая-либо из ее ветвей. Для именования отдельной ветви разветвляющихся и сливающихся стрелок следует выделить на диаграмме только одну ветвь, после этого вызвать редактор имени и присвоить имя стрелке. Это имя будет соответствовать только выделенной ветви.
Тоннелирование стрелок. Вновь внесенные граничные стрелки на диаграмме декомпозиции нижнего уровня изображаются в квадратных скобках и автоматически не появляются на диаграмме верхнего уровня.
Для их "перетаскивания" наверх нужно сначала щелкнуть правой кнопкой мыши по квадратным скобкам граничной стрелки, затем выбрать из контекстного меню Arrow Tunnel... Появляется диалог Border Arrow Editor .
Если выбрать опцию Resolve it to border arrow, стрелка мигрирует на диаграмму верхнего уровня, а если Change it to resolved rounded tunnel - стрелка будет затоннелирована и не попадет на другую диаграмму. Тоннельная стрелка изображается с круглыми скобками на конце.
Тоннелирование может быть применено для изображения малозначимых стрелок. Если на какой-либо диаграмме нижнего уровня необходимо изобразить малозначимые данные или объекты, которые не обрабатываются или не используются работами на текущем уровне, то их необходимо направить на вышестоящий уровень (на родительскую диаграмму). Если эти данные не используются на родительской диаграмме, их нужно направить еще выше и т. д. В результате малозначимая стрелка будет изображена на всех уровнях и затруднит чтение всех диаграмм, на которых она присутствует. Выходом является тоннелирование стрелки на самом нижнем уровне. Такое тоннелирование называется "не в родительской диаграмме". Другим примером тоннелирования может быть ситуация, когда стрелка механизма мигрирует с верхнего уровня на нижний, причем на нижнем уровне этот механизм используется одинаково во всех работах без исключения. (Предполагается, что не нужно детализировать стрелку механизма, т. е. стрелка механизма на дочерней работе именована до разветвления, а после разветвления ветви не имеет собственного имени.) В этом случае стрелка механизма на нижнем уровне может быть удалена, после чего на родительской диаграмме она может быть затоннелирована, а в комментарии к стрелке или в словаре можно указать, что механизм будет использоваться во всех работах дочерней диаграммы декомпозиции. Такое тоннелирование называется "не в дочерней работе".
2.4 Нумерация работ и диаграмм
Все работы модели нумеруются. Номер состоит из префикса и числа. Может быть использован префикс любой длины, но обычно используют префикс А. Контекстная (корневая) работа дерева имеет номер А0. Работы декомпозиции А0 имеют номера Al, A2, A3 и т.д. Работы декомпозиции нижнего уровня имеют номер родительской работы и очередной порядковый номер, например работы декомпозиции A3 будут иметь номера А31, A32, АЗЗ, А34 и т. д. Работы образуют иерархию, где каждая работа может иметь одну родительскую и несколько дочерних работ, образуя дерево. Такое дерево называют деревом узлов, а вышеописанную нумерацию - нумерацией по узлам. Имеются незначительные варианты нумерации, которые можно настроить во вкладке Presentation диалога Model Properties (меню Edit/Model Properties).
Диаграммы IDEF0 имеют двойную нумерацию. Во-первых, диаграммы имеют номера по узлу. Контекстная диаграмма всегда имеет номер А-0, декомпозиция контекстной диаграммы - номер А0, остальные диаграммы декомпозиции-номера по соответствующему узлу (например, Al, A2, А21, А213 и т.д.). BPwin автоматически поддерживает нумерацию по узлам, т. е. при проведении декомпозиции создается новая диаграмма и ей автоматически присваивается соответствующий номер. В результате проведения экспертизы диаграммы могут уточняться и изменяться, следовательно, могут быть созданы различные версии одной и той же (с точки зрения ее расположения в дереве узлов) диаграммы декомпозиции. BPwin позволяет иметь в модели только одну диаграмму декомпозиции в данном узле. Прежние версии диаграммы можно хранить в виде бумажной копии либо как FEO-диаграмму. (К сожалению, при создании FEO-диаграмм отсутствует возможность отката, т. е. можно получить из диаграммы декомпозиции FEO, но не наоборот.) В любом случае следует отличать различные версии одной и той же диаграммы. Для этого существует специальный номер - С-number, который должен присваиваться автором модели вручную. C-number - это произвольная строка, но рекомендуется придерживаться стандарта, когда номер состоит из буквенного префикса и порядкового номера, причем в качестве префикса используются инициалы автора диаграммы, а порядковый номер отслеживается автором вручную, например МСВ00021.
2.5 Диаграммы дерева узлов и FEO
Диаграмма дерева узлов показывает иерархию работ в модели и позволяет рассмотреть всю модель целиком, но не показывает взаимосвязи между работами (стрелки). Процесс создания модели работ является итерационным, следовательно, работы могут менять свое расположение в дереве узлов многократно. Чтобы не запутаться и проверить способ декомпозиции, следует после каждого изменения создавать диаграмму дерева узлов. Впрочем, BPwin имеет мощный инструмент навигации по модели - Model Explorer, который позволяет представить иерархию работ и диаграмм в удобном и компактном виде, однако этот инструмент не является составляющей стандарта IDEF0.
Для создания диаграммы дерева узлов следует выбрать в меню пункт Diagram/Add Node Tree. Возникает эксперт создания диаграммы дерева узлов Node Tree Wizard. В первом диалоге эксперта необходимо внести имя диаграммы дерева узлов, узел верхнего уровня и глубину дерева - Number of Levels (по умолчанию 3). Поскольку дерево узлов не обязательно в качестве верхнего уровня должно иметь контекстную работу и произвольную глубину. В одной модели можно создавать множество диаграмм деревьев узлов. Имя дерева узлов по умолчанию совпадает с именем работы верхнего уровня, а номер диаграммы автоматически генерируется как номер узла верхнего уровня плюс литера "N", например AON. Если в модели создается два дерева узлов, имеющие в качестве верхнего уровня одну и ту же работу, то по умолчанию диаграммы получат идентичные номер и имя. Поэтому рекомендуется при создании диаграммы дерева узлов внести имя диаграммы, отличное от значения по умолчанию. Второй диалог эксперта Node Tree Wizard позволяет задать свойства диаграммы дерева узлов.
По умолчанию нижний уровень декомпозиции показывается в виде списка, остальные работы - в виде прямоугольников. Для отображения всего дерева в виде прямоугольников следует выбрать опцию Bullet Last Level. Группа Connection Style позволяет выбрать стиль соединительных линий - диагональные (по умолчанию) или ортогональные.
Диаграммы "только для экспозиции" (FEO) часто используются в модели для иллюстрации других точек зрения, для отображения отдельных деталей, которые не поддерживаются явно синтаксисом IDEF0. Диаграммы FEO позволяют нарушить любое синтаксическое правило, поскольку по сути являются просто картинками - копиями стандартных диаграмм и не включаются в анализ синтаксиса. Например, работа на диаграмме FEO может не иметь стрелок управления и выхода. С целью обсуждения определенных аспектов модели с экспертом предметной области может быть создана диаграмма только с одной работой и одной стрелкой, поскольку стандартная диаграмма декомпозиции содержит множество деталей, не относящихся к теме обсуждения и дезориентирующих эксперта. Но если FEO используется для иллюстрации альтернативных точек зрения (альтернативный контекст), рекомендуется все-таки придерживаться синтаксиса IDEF0. Для создания диаграммы FEO следует выбрать пункт меню Diagram/Add FEO Diagram. В возникающем диалоге Add New FEO Diagram следует указать имя диаграммы FEO и тип родительской диаграммы.
Новая диаграмма получает номер, который генерируется автоматически (номер родительской диаграммы по узлу + постфикс F, например А3F).
2.6 Каркас диаграммы
Каркас содержит заголовок (верхняя часть рамки) и подвал (нижняя часть рамки). Заголовок каркаса используется для отслеживания диаграммы в процессе моделирования. Нижняя часть используется для идентификации и позиционирования в иерархии диаграммы.
Смысл элементов каркаса приведен в табл. 2.1 и 2.2.
Таблица 2.1 Поля заголовка каркаса (слева направо)
|
Поля |
Смысл |
|
|
Used At |
Используется для указания на родительскую работу в случае, если на текущую диаграмму ссылались посредством стрелки вызова |
|
|
Autor, Date, Rev, Project |
Имя создателя диаграммы, дата создания и имя проекта, в рамках которого была создана диаграмма. Rev - дата последнего редактирования диаграммы. |
|
|
Notes 1 2 3 4 5 6 7 8 9 10 |
Используется при проведении сеанса экспертизы. Эксперт должен (на бумажной копии документа) указать число замечаний, вычеркивая цифру из списка каждый раз при внесении нового замечания. |
|
|
Status |
Статус отображает стадию создания диаграммы, отображая все этапы публикации. |
|
|
Working |
Новая диаграмма, кардинально обновленная диаграмма или новый автор диаграммы |
|
|
Draft |
Диаграмма прошла первичную экспертизу и готова к дальнейшему обсуждению. |
|
|
Recommended |
Диаграмма и все ее сопровождающие документы прошли экспертизу. Новых изменений не ожидается. |
|
|
Publication |
Диаграмма готова к окончательной печати и публикации |
|
|
Reader |
Имя читателя (эксперта). |
|
|
Date |
Дата прочтения (экспертизы). |
|
|
Context |
Схема расположения работ в диаграмме верхнего уровня. Работа, являющаяся родительской, показана темным прямоугольником, остальные - светлым. на контекстной диаграмме (А-0) показывается надпись TOP. В левом нижнем углу показывается номер по узлу родительской диаграммы: |
Таблица 2.2 Поля подвала каркаса (слева направо)
|
Поля |
Смысл |
|
|
Node |
Номер узла диаграммы (номер родительской работы). |
|
|
Title |
Имя диаграммы. По умолчанию - имя родительской работы. |
|
|
Number |
C-Number, уникальный номер версии диаграммы. |
|
|
Page |
Номер страницы, может использоваться как номер страницы при формировании папки |
Значение полей каркаса задаются в диалоге Diagram Properties (меню Diagram/Diagram Properties)
2.7 Слияние и расщепление моделей
Возможность слияния и расщепления моделей обеспечивает коллективную работу над проектом. Так, руководитель проекта может создать декомпозицию верхнего уровня и дать задание аналитикам продолжить декомпозицию каждой ветви дерева в виде отдельных моделей после окончания работы над отдельными ветвями все подмодели могут быть слиты в единую модель. С другой стороны, отдельная ветвь модели может быть отщеплена для использования в качестве независимой модели, для доработки или архивирования.
BPwin применяет для слияния и разветвления моделей стрелки вызова. Для слияния необходимо выполнить следующие условия:
· обе сливаемые модели должны быть открыты в BPwin;
· имя модели-источника, которое присоединяют к модели-цели, должно совпадать с именем стрелки вызова работы в модели-цели;
· стрелка вызова должна исходить из недекомпозируемой работы (работа должна иметь диагональную черту в левом верхнем углу);
· имена контекстной работы подсоединяемой модели-источника и работы на модели-цели, к которой мы присоединяем модель-источник, должны совпадать;
· модель-источник должна иметь по крайней мере одну диаграмму декомпозиции.
Для слияния моделей нужно щелкнуть правой кнопкой мыши по работе со стрелкой вызова в модели-цели и во всплывающем меню выбрать пункт Merge Model. Появляется диалог, в котором следует указать опции слияния модели. При слиянии моделей объединяются и словари стрелок и работ. В случае одинаковых определений возможна перезапись определений или принятие определений из модели-источника. То же относится к именам стрелок, хранилищам данных и внешним ссылкам. (Хранилища данных и внешние ссылки - объекты диаграмм потоков данных, DFD, будут рассмотрены ниже.) После подтверждения слияния (кнопка ОК) модель-источник подсоединяется к модели-цели, стрелка вызова исчезает, а работа, от которой отходила стрелка вызова, становится декомпозируемой - к ней подсоединяется диаграмма декомпозиции первого уровня модели-источника. Стрелки, касающиеся работы на диаграмме модели-цели, автоматически не мигрируют в декомпозицию, а отображаются как неразрешенные. Их следует тоннелировать вручную.
В процессе слияния модель-источник остается неизменной и к модели-цели подключается фактически ее копия. Не нужно путать слияние моделей с синхронизацией. Если в дальнейшем модель-источник будет редактироваться, эти изменения автоматически не попадут в соответствующую ветвь модели-цели.
Разделение моделей производится аналогично. Для отщепления ветви от модели следует щелкнуть правой кнопкой мыши по декомпозированной работе (работа не должна иметь диагональной черты в левом верхнем углу) и выбрать во всплывающем меню пункт Split Model. В появившемся диалоге Split Options следует указать имя создаваемой модели. После подтверждения расщепления в старой модели работа станет недекомпозированной (признак - диагональная черта в левом верхнем углу), будет создана стрелка вызова, причем ее имя будет совпадать с именем новой модели, и, наконец, будет создана новая модель, причем имя контекстной работы будет совпадать с именем работы, от которой была "оторвана" декомпозиция.
2.8 Рекомендации по рисованию диаграмм
В реальных диаграммах к каждой работе может подходить и от каждой может отходить около 10 стрелок. Если диаграмма содержит 6-8 работ, то она может содержать 30-40 стрелок, причем они могут сливаться, разветвляться и пересекаться. Такие диаграммы могут стать очень плохо читаемыми. В IDEF0 существуют соглашения по рисованию диаграмм, которые призваны облегчить чтение и экспертизу модели. Некоторые из этих правил BPwin поддерживает автоматически, выполнение других следует обеспечить вручную:
· Прямоугольники работ должны располагаться по диагонали с левого верхнего в правый нижний угол (порядок доминирования). При создании новой диаграммы декомпозиции BPwin автоматически располагает работы именно в таком порядке. В дальнейшем можно добавить новые работы или изменить расположение существующих, но нарушать диагональное расположение работ по возможности не следует. Порядок доминирования подчеркивает взаимосвязь работ, позволяет минимизировать изгибы и пересечения стрелок.
· Следует максимально увеличивать расстояние между входящими или выходящими стрелками на одной грани работы. Если включить опцию Automatically space arrows на вкладке Layout диалога Model Properties (меню Model/Model Properties), BPwin будет располагать стрелки нужным образом автоматически.
· Следует максимально увеличить расстояние между работами, поворотами и пересечениями стрелок.
· Если две стрелки проходят параллельно (начинаются из одной и той же грани одной работы и заканчиваются на одной и той же грани другой работы), то по возможности следует их объединить и назвать единым термином.
· Обратные связи по входу рисуются "нижней" петлей, обратная связь по управлению - "верхней".(BPwin автоматически рисует обратные связи нужным образом. Его можно "обмануть", но лучше этого не делать.
· Циклические обратные связи следует рисовать только в случае крайней необходимости, когда подчеркивают значение повторно используемого объекта. Принято изображать такие связи на диаграмме декомпозиции. BPwin не позволяет создать циклическую обратную связь за один прием. Если все же необходимо изобразить такую связь, следует сначала создать обычную связь по входу, затем разветвить стрелку, направить новую ветвь обратно ко входу работы-источника и, наконец, удалить старую ветвь стрелки выхода.
· Следует минимизировать число пересечений, петель и поворотов стрелок. Это ручная и, в случае насыщенных диаграмм, творческая работа.
· Если нужно изобразить связь по входу, необходимо избегать "нависания" работ друг над другом. В этом случае BPwin изображает связи по входу в виде петли, что затрудняет чтение диаграмм.
3. Стоимостный анализ (ABC)
3.1 Понятие стоимостного анализа
Как было указано ранее, обычно сначала строится функциональная модель существующей организации работы - AS-IS (Как есть). После построения модели AS-IS проводится анализ бизнес-процессов, потоки данных и объектов перенаправляются и улучшаются, в результате строится модель ТО-ВЕ. Как правило, строится несколько моделей ТО-ВЕ, из которых по какому-либо критерию выбирается наилучшая. Проблема состоит в том, что таких критериев много и непросто определить важнейший. Для того чтобы определить качество созданной модели с точки зрения эффективности бизнес-процессов, необходима система метрики, т. е. качество следует оценивать количественно.
BPwin предоставляет аналитику инструмент для оценки модели - стоимостный анализ, основанный на работах (Activity Based Costing, ABC). ABC является широко распространенной методикой, используемой международными корпорациями и государственными организациями (в том числе Департаментом обороны США) для идентификации истинных движителей затрат в организации.
Стоимостный анализ представляет собой соглашение об учете, используемое для сбора затрат, связанных с работами, с целью определить общую стоимость процесса. Стоимостный анализ основан на модели работ, потому что количественная оценка невозможна без детального понимания функциональности предприятия. Обычно ABC применяется для того, чтобы понять происхождение выходных затрат и облегчить выбор нужной модели работ при реорганизации деятельности предприятия (Business Process Reengineering, BPR). С помощью стоимостного анализа можно решить такие задачи, как определение действительной стоимости производства продукта, определение действительной стоимости поддержки клиента, идентификация работ, которые стоят больше всего (те, которые должны быть улучшены в первую очередь), обеспечение менеджеров финансовой мерой предлагаемых изменений и др.
ABC может проводиться только тогда, когда модель работы последовательная (следует синтаксическим правилам IDEF0), корректная (отражает бизнес), полная (охватывает всю рассматриваемую область) и стабильная (проходит цикл экспертизы без изменений), другими словами, когда создание модели работы закончено.
ABC включает следующие основные понятия:
· объект затрат - причина, по которой работа выполняется; обычно, основной выход работы, стоимость работ есть суммарная стоимость объектов затрат ("Готовое изделие").
· движитель затрат - характеристики входов и управлений работы ("Сырье", "Заказ"), которые влияют на то, как выполняется и как долго длится работа;
· центры затрат, которые можно трактовать как статьи расхода.
3.2 Методика расчета стоимости проекта
При проведении стоимостного анализа в BPwin сначала задаются единицы измерения времени и денег. Для задания единиц измерения следует вызвать диалог Model Properties (меню Model/Model Properties), вкладка ABC Units.
Если в списке выбора отсутствует необходимая валюта (например, рубль), ее можно добавить. Символ валюты по умолчанию берется из настроек Windows. Диапазон измерения времени в списке Unit of measurment достаточен для большинства случаев - от секунд до лет.
Затем описываются центры затрат (cost centers). Для внесения центров затрат необходимо вызвать диалог Cost Center Editor (меню Model /Cost Center Editor .
Каждому центру затрат следует дать подробное описание в окне Definition. Хотя, BPwin сохраняет информацию о стандартном отчете в файле BPWIN-RPT.INI, информация о центрах затрат сохраняется в виде указателей, т. е. хранятся не названия центров затрат, а их номера. Поэтому, если нужно использовать один и тот же стандартный отчет в разных моделях, списки центров затрат должны быть в них одинаковы.
Для задания стоимости работы (для каждой работы на диаграмме декомпозиции) следует щелкнуть правой кнопкой мыши по работе и на всплывающем меню выбрать Costs. Во вкладке Costs диалога Activity Properties указывается частота проведения данной работы в рамках общего процесса (окно Frequency) и продолжительность (Duration). Затем следует выбрать в списке один из центров затрат и в окне Cost задать его стоимость. Аналогично назначаются суммы по каждому центру затрат, т. е. задается стоимость каждой работы по каждой статье расхода. Если в процессе назначения стоимости возникает необходимость внесения дополнительных центров затрат, диалог Cost Center Editor вызывается прямо из диалога Activity Cost соответствующей кнопкой.
Общие затраты по работе рассчитываются как сумма по всем центрам затрат. При вычислении затрат вышестоящей (родительской) работы сначала вычисляется произведение затрат дочерней работы на частоту работы (число раз, которое работа выполняется в рамках проведения родительской работы), затем результаты складываются. Если во всех работах модели включен режим Compute from Decompositions, подобные вычисления автоматически проводятся по всей иерархии работ снизу вверх.
Этот достаточно упрощенный принцип подсчета справедлив, если работы выполняются последовательно. Встроенные возможности BPwin позволяют разрабатывать упрощенные модели стоимости, которые тем не менее оказываются чрезвычайно полезными для предварительной оценки затрат. Если схема выполнения более сложная (например, работы производятся альтернативно), можно отказаться от подсчета и задать итоговые суммы для каждой работы вручную (Override Decompositions). В этом случае результаты расчетов с нижних уровней декомпозиции будут игнорироваться, при расчетах на верхних уровнях будет учитываться сумма, заданная вручную. На любом уровне результаты расчетов сохраняются независимо от выбранного режима, поэтому при выключении опции Override Decompositions расчет снизу вверх производится обычным образом.
Результаты стоимостного анализа наглядно представляются в специальном отчете BPwin - Activity Cost Report (меню Tools/Report/Activity Cost Report). Отчет позволяет документировать имя, номер, определение и стоимость работ, как суммарную, так и раздельно по центрам затрат.
Результаты отображаются и непосредственно на диаграммах. В левом нижнем углу прямоугольника работы может показываться либо стоимость (по умолчанию), либо продолжительность, либо частота проведения работы. Настройка отображения осуществляется в диалоге Model Properties (меню Model/ Model Properties), вкладка Display, опции АВС Data и ABC Units.
Подобные документы
Обзор существующих проектных решений, их достоинства и недостатки. Обоснование необходимости разработки информационной системы. Общее описание интерфейса BPwin. Разработка концепции архитектуры построения и платформы реализации. Создание новой модели.
курсовая работа [4,3 M], добавлен 11.09.2014Построение функциональной модели IDEF0 средствами программного обеспечения BPWin. Произведение двухуровневой декомпозиции построенной диаграммы. Создание функциональной схемы программного продукта для учёта услуг, оказываемых "Интернет-центром".
лабораторная работа [339,7 K], добавлен 13.06.2014Анализ предметной области "строительная фирма". Обоснование прикладного программного обеспечения (CA ERwin Data Modeler) для моделирования процессов. Структурно-функциональная модель "Как есть" и "Как надо". Реализация модели помощью средств BPWin.
курсовая работа [539,5 K], добавлен 10.06.2014Разработка объектно-ориентированной модели ООО "Мир Компьютеров". Описание предметной области. Разработка функциональной модели системы средствами BPwin. Проектирование информационной системы средствами Rational Rose. Сопровождение информационных сетей.
курсовая работа [843,4 K], добавлен 07.01.2015Создание модели информационной системы с AllFusion Process Modeler 4.0 в стандарте IDEF0. Дополнение созданной модели процессов организационными диаграммами в нотации DFD. Резервирование номеров. Автоматизация рабочего места администратора гостиницы.
курсовая работа [1,8 M], добавлен 17.06.2013История возникновения стандарта IDEF0. Синтаксис и семантика модели, ее границы и связи, действия. Принципы ограничения сложности IDEF0-диаграмм. Особенности национальной российской практики применения функционального моделирования средствами IDEF0.
курсовая работа [50,8 K], добавлен 02.06.2015Анализ информационной системы ИНЭК "Страховщик". Описание предметной области с использованием модели "сущность-связь". Моделирование бизнес-процессов с помощью IDEF0-диаграмм. Проектирование и разработка приложения в среде Delphi и создание интерфейса.
отчет по практике [4,9 M], добавлен 28.12.2014Характеристика и организационная структура компании. Описание ее бизнес-процессов. Разработка модели организации различных видов работ, осуществляемых в магазине при помощи BPWin. Ее стоимостной анализ. Построение логической диаграммы процессов в ERWin.
курсовая работа [1,2 M], добавлен 11.04.2015Разработка функциональной модели бизнес-процессов предприятия "Партнер", занимающегося продажей автомобилей, средствами BPwin. Построение контекстной диаграммы, охватывающей всю деятельность фирмы. Создание диаграмм декомпозиции, дерева узлов и FEO.
курсовая работа [1,1 M], добавлен 19.06.2012Организационно-производственная структура и вид деятельности предприятия. Перечень входных и выходных документов. Построение функциональной и информационной модели деятельности в соответствии со стандартом IDEF1X, использование CASE – средство BPwin.
курсовая работа [3,0 M], добавлен 18.12.2011
