ТЕМА 1. АНАЛИЗ ДЕЯТЕЛЬНОСТИ ПРЕДПРИЯТИЙ

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

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ «ИВАНОВСКИЙ ИНСТИТУТ ГОСУДАРСТВЕННОЙ ПРОТИВОПОЖАРНОЙ СЛУЖБЫ МИНИСТЕРСТВА РОССИЙСКОЙ ФЕДЕРАЦИИ ПО ДЕЛАМ ГРАЖДАНСКОЙ ОБОРОНЫ, ЧРЕЗВЫЧАЙНЫМ СИТУАЦИЯМ И ЛИКВИДАЦИИ ПОСЛЕДСТВИЙ СТИХИЙНЫХ БЕДСТВИЙ»

Кафедраэкономики, государственного

и муниципального управления

В.Ю. Волынский

Задания и методические указания по выполнению

расчетно-графической работы по дисциплине

«Информационные технологии в управлении»

Учебное пособие

Иваново

2014

УДК 351+352+65.01

Волынский В.Ю. Задания и методические рекомендации по выполнению расчетно-графической работы по дисциплине «Информационные технологии в управлении». Учебное пособие. Иваново, 2014.- 70 с.

Учебное пособие предназначено для обучающихся по направлению 38.03.04 «Государственное и муниципальное управление».

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

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

Рецензенты:

д.э.н., профессор кафедры экономики и финансов ФГБОУ ВПО «Ивановский государственный химико-технологический университет»

ОГЛАВЛЕНИЕ

		Стр.
	Введение……………………………………………………………..
I.	Общие указания по выполнению расчетно-графической работы…………………………………………………………………….
II.	Методические указания по описанию и функционально-стоимостному анализу процессов………………………………….
III.	Задание для выполнения расчетно-графической работы в системе AllFusion Process Modeler …………………......……………
	Список рекомендуемой литературы……………………………..
	Приложения…………………………………………………………

Введение

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

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

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

Выполнение расчетно-графической работы обучающимися преследует следующие учебно-воспитательные цели:

- закрепление знаний, полученных на лекциях и практических занятиях по теме «Информационные процессы в менеджменте»;

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

I. Общие указания по выполнению расчетно-графической работы

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

Расчетно-графические работы могут быть оформлены как в ученических тетрадях в объеме не более 18 листов рукописного текста, так и на листах формата А-4, в объеме не более 20 листов, компьютерным набором, ориентация книжная.

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

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

- ориентация страниц – книжная;

- титульный лист оформляется в соответствии с Приложением 1;

- поля: левое – 3 см, верхнее и нижнее – 2 см, правое – 1, 5 см;

- интервал между строками - одинарный;

- красная строка 1, 5 см от левой границы текста;

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

- шрифт Times New Roman, кегль - 14;

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

- работа скрепляется в папку-скоросшиватель.

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

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

II. МетодиЧЕСКИЕ УКАЗАНИЯ ПО ОПИСАНИЮ И ФУНКЦИОНАЛЬНО-СТОИМОСТНОМУ АНАЛИЗУ ПРОЦЕССОВ

ТЕМА 1. АНАЛИЗ ДЕЯТЕЛЬНОСТИ ПРЕДПРИЯТИЙ

ТЕМА 2. СОЗДАНИЕ МОДЕЛИ ПРОЦЕССОВ В ALLFUSION PROCESS MODELER

Рис. 8. Интерфейс пакета AllFusion Process Modeler

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

Таблица 1 ).

Таблица 1.

Рис. 9. Стартовый диалог AllFusion Process Modeler

Модель в AllFusion Process Modeler, построенная на основе нотаций IDEF0 и IDEF3, рассматривается как совокупность «работ», каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников или функциональных блоков, данные - в виде стрелок или интерфейсных дуг. Если дважды щелкнуть по любому объекту модели левой кнопкой мыши (или один раз правой и затем выбрать из контекстного меню), появляется диалог Activity Properties, каждая страница которого соответствует редактору какого-либо свойства объекта. Например, для установки шрифта (Font) (в том числе его размера и стиля) и цвета (Color) объекта вызываются соответствующие страницы диалога Activity Properties (Рис.10).

Рис. 10. Страницы диалога Activity Properties для редактирования шрифта и цвета

Кроме того, AllFusion Process Modeler позволяет установить шрифт по умолчанию для объектов определенного типа на диаграммах и в отчетах. Для этого следует выбрать меню Model - Default Fonts, после чего появляется каскадное меню (Рис.11), каждый пункт которого служит для установки шрифтов для определенного типа объектов:

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

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

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

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

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

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

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

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

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

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

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

Рис. 11. Доступ к пунктам меню для установки в модели шрифтов по умолчанию

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

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

Таблица 2.

Таблица 3.

Методология IDEF0

С помощью моделирования различных областей деятельности можно достаточно эффективно анализировать «узкие места» в управлении и оптимизировать общую схему бизнеса.

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

Графический язык IDEF0 использует четыре основных понятия:

1). Функциональный блок (Activity Box), который изображают как прямоугольник (Рис.12). Он обозначает конкретную функцию в рамках рассматриваемой системы. Название каждого функционального блока формулируют в глагольном наклонении (например, «оказать услуги»).

Каждая из сторон функционального блока имеет определенное значение (роль):

Верхняя сторона - «Управление» (Control);
Левая сторона - «Вход» (Input);
Правая сторона - «Выход» (Output);
Нижняя сторона - «Механизм» (Mechanism).

Каждый функциональный блок в рамках единой системы должен иметь уникальный идентификационный номер.

Рис. 12. Функциональный блок.

2). Интерфейсная дуга (Arrow), которую также называют потоком или стрелкой. Интерфейсная дуга – это элемент системы, который обрабатывает функциональный блок или оказывает иное влияние на функцию, отображенную данным функциональным блоком.

Графически интерфейсная дуга - однонаправленная стрелка. Каждая интерфейсная дуга имеет уникальное наименование (Arrow Label), которое должно быть оборотом существительного.

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

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

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

· материальные потоки (детали, товары, сырье и т.д.),

· финансовые потоки (наличные и безналичные, инвестиции и т.д.),

· потоки документов (коммерческие, финансовые и организационные документы),

· потоки информации (информация, данные о намерениях, устные распоряжения и т.д.)

· ресурсы (сотрудники, станки, машины и т.д.).

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

3). Третьим понятием стандарта IDEF0 является декомпозиция (Decomposition). Этот принцип применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

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

Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором «А-0».

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

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

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

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

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

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

Примеры формулирования цели:

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

· Идентифицировать роли и ответственность служащих для написания должностных инструкций,

· Описать функциональность предприятия с целью написания спецификаций информационной системы.

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

Для внесения области, цели и точки зрения в модели IDEF0 средствами AllFusion Process Modeler выбирают пункт меню Model - Model Properties, вызывающий диалог Model Properties. В закладке Purpose следует внести цель и точку зрения (Рис. 13), а в закладку Definition - определение модели и описание области (Рис.14).

Рис. 13. Диалог Model Properties, закладка Purpose

Рис. 14. Диалог Model Properties, закладка Definition

В закладке Status того же диалога можно описать статус модели (черновой вариант, рабочий, окончательный и т. д.), время создания и последнего редактирования (отслеживается в дальнейшем автоматически по системной дате). В закладке Source (Рис.15) описываются источники информации для построения модели (например, " Опрос экспертов предметной области и анализ документации" ).

Рис. 15. Диалог Model Properties, закладка Source

Закладка General служит для внесения имени проекта и модели, имени и инициалов автора и временных рамок модели - AS-IS и ТО-ВЕ (Рис.16).

Рис. 16. Диалог Model Properties, закладка General

В процессе декомпозиции, функциональный блок контекстной диаграммы, отображающий систему как единое целое, детализируется на другой диаграмме. Диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции контекстной диаграммы и называется дочерней (Child diagram) по отношению к нему. Каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком – Child Box. Функциональный блок - предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. В каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0–модели (Рис.17).

Рис. 17. Декомпозиция функциональных блоков

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

В случаях, когда отдельные интерфейсные дуги не имеет смысла в дочерних диаграммах ниже или выше какого-то уровня в иерархии, используют понятие туннелирования. Его также применяют, когда нужно избавиться от отдельных «концептуальных» интерфейсных дуг и не детализировать их глубже некоторого уровня. Обозначение «туннеля» (Arrow Tunnel) в виде двух скобок вокруг начала интерфейсной дуги обозначает, что она не была унаследована от функционального родительского блока и появилась (из «туннеля») только на этой диаграмме. Такое же обозначение вокруг конца стрелки вблизи от блока – приёмника означает, что в дочерней по отношению к этому блоку диаграмме эта дуга отображаться и рассматриваться не будет. Если отдельные объекты и соответствующие им интерфейсные дуги не рассматриваются на некоторых промежуточных уровнях иерархии, то они сначала «погружаются в туннель», а затем, при необходимости «возвращаются из туннеля».

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

IDEF0-модели содержат сложную информацию. Для ограничения перегруженности и удобства чтения в методологии приняты ограничения сложности:

· На диаграмме может быть от трех до шести функциональных блоков.

· Один функциональный блок соединен не более чем с четырьмя интерфейсными дугами.

Разработка IDEF0-модели

Процесс разработки модели итеративный и состоит из условных этапов:

· Создание модели авторами (Authors). Построение модели – это динамический процесс, опроса авторами компетентных лиц о структуре различных процессов. На основе имеющихся положений, документов и результатов опросов авторы создают черновик модели (Model Draft).

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

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

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

· Что поступает в подразделение «на входе»?

· Какие функции, и в какой последовательности выполняются в рамках подразделения?

· Кто отвечает за выполнение каждой функции?

· Чем руководствуется исполнитель при выполнении каждой из функций?

· Что является результатом работы подразделения «на выходе»?

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

Описание модели отражается в отчете Model Report. Диалог настройки отчета по модели вызывается из пункта меню Tools – Reports – Model Report (

Рис. 1 18).

Рис. 18. Вызов диалога настройки отчета модели

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

Рис. 19. Настройка отчета модели

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

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

Функциональные блоки (Activity box) или «Работы» - это поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Их изображают в виде прямоугольников и они должны быть названы. Имя «работы» выражают глаголом, глагольной фразой или отглагольным существительным, обозначающим действие, например, «Изготовление детали», «Прием заказа». Каждый функциональный блок модели должен иметь определение (Definition). Например, функциональный блок «Изготовление детали» имеет следующее определение: «Работа относится к полному циклу изготовления изделия от контроля качества сырья до отгрузки готового упакованного изделия».Для внесения имени (определения) работы следует щелкнуть по работе правой кнопкой мыши, выбрать в меню Name (Definition) и в появившемся диалоге Activity Properties внести имя (определение) работы (

Рис.20).

Рис. 20. Диалог «Свойства функционального блока»

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

Рис. 21).

Рис. 21. Контекстная диаграмма

Как уже отмечалось выше, контекстная диаграмма показывает взаимодействие системы с внешним миром в терминах управления, входов, механизмов и выходов. Следующим шагом в создании модели является детализация рассматриваемого функционального блока. Детализация осуществляется таким образом, чтобы на первой декомпозиции были отражены основные деятельности системы и их взаимосвязи. Для создания диаграммы декомпозиции в левом окне - Model Explorer – выбирают режим просмотра Activity, нажимают правую кнопку мыши и выбирают Decompose или, выделив мышкой работу, нажимают кнопку на панели инструментов (

Рис.22).

Рис. 22. Создание дочерней диаграммы – декомпозиция

В диалоге Activity Box Count (

Рис. 23) указывают нотацию новой диаграммы и количество «работ» в ней.

Рис.23. Диалог выбора нотации числа работ для диаграммы декомпозиции

Появляется диаграмма декомпозиции. Допустимый интервал числа работ от 2 до 8. Для наглядности и лучшего понимания моделируемых процессов рекомендуется использовать от трех до шести блоков на одной диаграмме.

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

Рис.24).

Рис. 24. Декомпозиция контекстной диаграммы

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

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

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

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

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

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

2). Управление (Control) – это правила или стратегии, процедуры или стандарты, инструкции или законы, которым подчиняется «работа». Каждая «работа» должна иметь хотя бы одну стрелку управления. Стрелка управления примыкает к верхней грани функционального блока. Управление влияет на «работу», но не преобразуется ею. Если данные изменяются после обработки функциональным блоком, то они обозначаются как вход. Если они остаются неизменными, то – как управление. В случае возникновения неопределенности в статусе стрелки (управление или вход) рекомендуется рисовать стрелку управления.

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

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

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

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

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

· щелкнуть на панели инструментов по кнопке с символом стрелки ;

· перенести курсор к левой стороне экрана, пока не появится начальная темная полоска (Рис. 25а);

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

а) б)

Рис. 25. Создание стрелки входа

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

· щелкнуть правой кнопкой мыши на линии стрелки, выбрать в контекстном меню Name (Definition) и добавить имя (определение) стрелки.

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

Рис. 26. Вызов словаря стрелок

Словарь (Dictionary) в программе AllFusion Process Modeler решает очень важную задачу. Диаграммы создаются аналитиком для того, чтобы провести сеанс экспертизы, т.е. обсудить диаграмму со специалистом предметной области. В любой предметной области формируется профессиональный жаргон, причем очень часто жаргонные выражения имеют нечеткий смысл и воспринимаются разными специалистами по-разному. В то же время аналитик - автор диаграмм должен употреблять те выражения, которые наиболее понятны экспертам. Поскольку формальные определения часто сложны для восприятия, аналитик вынужден употреблять профессиональный жаргон, а, чтобы не возникло неоднозначных трактовок, в словаре каждому понятию можно дать расширенное и, если это необходимо, формальное определение. Для того чтобы просмотреть или редактировать содержимое словаря, необходимо выбрать пункт меню Dictionary и далее необходимый объект, например, стрелки ( Ошибка! Источник ссылки не найден. ).

Содержимое словаря можно распечатать в виде отчета. Для этого надо выбрать пункт меню Tools – Reports и далее необходимый вид отчета. Например, чтобы распечатать словарь стрелок надо выбрать пункт меню Tools – Reports – Arrow Report и получить толковый словарь терминов предметной области, использующихся в модели.

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

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

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

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

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

В IDEF0 различают пять типов связей «работ».

1). Связь по входу (output-input), когда стрелка выхода вышестоящей «работы» (выход) является входом нижестоящей (Рис. 28).

Рис. 28. Пример связи по входу

2). Связь по управлению (output-control), когда выход вышестоящей работы является управлением нижестоящей (Рис. 29).

Рис. 29. Пример связи по управлению

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

3). Обратная связь по входу (output-input feedback), когда выход нижестоящей работы направляется на вход вышестоящей (Рис. 30).

Рис. 30. Пример обратной связи по входу

Такая связь, как правило, используется для описания циклов.

4). Обратная связь по управлению (output-control feedback), когда выход нижестоящей «работы» направляется на управление вышестоящей (Рис. 31).

Рис. 31. Пример обратной связи по управлению

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

5). Связь выход-механизм (output-mechanism) - это когда выход одной «работы» формирует механизм другой (Рис. 32).

Рис. 32. Пример связи выход-механизм

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

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

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