Общие методические указания по выполнению и оформлению контрольной работы

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ

УНИВЕРСИТЕТ СЕРВИСА И ЭКОНОМИКИ

--------------------------------------------------------------------------------------------

Кафедра «Технология обслуживания транспортных средств»

А.А. Коричев

Автоматизированные системы управления предприятиями автосервиса

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

Санкт-Петербург

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

 

 

САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ

УНИВЕРСИТЕТ СЕРВИСА И ЭКОНОМИКИ

--------------------------------------------------------------------------------------------

Кафедра «Технология обслуживания транспортных средств»

 

 

А.А. Коричев

 

 

Автоматизированные системы управления предприятиями автосервиса

 

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

 

 

Санкт-Петербург

УДК 639.37.631.43.068 (075.8)

 

 

Одобрено на заседании кафедры «Технология обслуживания транспортных средств» СПбГУСЭ, протокол № 10 от 9 июня 2011 года. УМС по направлению подготовки 190600 протокол № от июня 2011 года.

 

Коричев А.А. Автоматизированные системы управления предприятиями автосервиса. Методические указания по выполнению курсовой работы. СПб.: Изд-во СПбГУСЭ, 2011. 164 с.

 

Учебное пособие по выполнению курсовой работы предназначено для студентов всех форм обучений, ко­торые в процессе учебы в СПб ГУСЭ изучают дисциплину: «Автоматизированные системы управления предприятиями автосервиса» для направления подготовки 190600.62. «Эксплуатация транспортных машин и транспортно-технологических комплексов» и других специальностей.

 

 

ISBN © Санкт-Петербургский государственный университет

сервиса и экономики, 2011 г.

© Коричев А.А. 2011 г.

ОГЛАВЛЕНИЕ

 

1.Введение

2. Общие методические указания по оформлению и выполнению работы.

3. Общая постановка задачи.

4. Основы BPWin.

5. Заключение.

6. список использованной литературы.

7. Приложения.

 

 

Введение

 

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

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

- исполнительных систем;

- управляющих информационных систем;

- систем поддержки принятия решения;

- систем автоматизированного делопроизводства;

- систем диалоговой обработки запросов;

- баз данных.

Автоматизированная система(АС): Система, состоящая из персонала и комплекса средств автоматизации деятельности, реализующая информационную технологию выполнения установленных функций.

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

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

Основные задачи контрольной работы:

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

 

Общие методические указания по выполнению и оформлению контрольной работы

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

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

Курсовая работа должна быть выполнена и распечатана на листах формата А4. И представлена в виде пояснительной записки (прил.2), объёмом 20-30 страниц в соответствии с ГОСТ 7.32 – 2001 «Отчет о научно-исследовательской работе. Структура и правила оформления» (с изменениями 2005 г.)

Структура глав работы следующая:

1.Общее описание выбранного предприятия, производственного процесса, организации управления, использование информационных и программных ресурсов.

2. Построение функциональной модели существующего процесса на предприятии автосервиса.

3. Описание недостатков и предложение по автоматизации.

4. Мнемосхема предлагаемого процесса.

5. Функциональная модель предлагаемого процесса.

6. Модель предлагаемого процесса.

7. Обоснование выбора программного обеспечения для реализации.

8. Заключение.

 

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

 

2.Общая постановка задачи.

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

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

Организационно-экономическая сущность задачи:

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

- цель решения;

- назначение (для каких объектов подразделений и пользователей предназначена);

- периодичность решения и требования к срокам решения;

- источники и способы поступления данных;

- потребители результатной информации и способы ее отправки;

- информационная связь с другими задачами.

Описание исходной (входной) информации:

- перечень исходной информации;

- формы представления (документ) по каждой позиции перечня; примеры заполнения документов;

- количество документов (информации) в единицу времени, количество строк в документе (массиве);

- описание структурных единиц информации (каждого элемента данных, реквизита);

- точное и полное наименование, идентификатор, максимальная разрядность в знаках;

- способы контроля исходных данных:

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

- контроль интервала значений реквизита;

- контроль соответствия списку значений;

- балансовый или расчетный метод контроля количественных значений реквизитов;

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

Описание используемой условно-постоянной информации:

- перечень условно-постоянной информации (классификаторов, справочников, таблиц, списков с указанием их полных наименование);

- формы представления;

- описание структурных единиц информации (по аналогии с исходными записями);

- способы взаимодействия с переменной информацией.

Описание результатной (выходной) информации:

- перечень результатной информации;

- формы представления (печатная сводка, видеограмма, машинный носитель и его макет и т.д.);

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

- количество документов (информации) в единицу времени, количество строк в документе (массиве);

- перечень пользователей результатной информацией (подразделение и персонал);

- перечень регламентной и запросной информации;

- описание структурных единиц информации (каждого элемента данных, реквизита) по аналогии с исходными данными;

- способы контроля результатной информации:

- контроль разрядности;

- контроль интервала значений реквизита;

- контроль соответствия списку значений;

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

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

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

Идентификатор - условное обозначение, с помощью которого можно оперировать значением реквизита, сокращенное наименование реквизита.

Разрядность реквизита указывается количеством знаков (алфавитных, цифровых и алфавитно-цифровых).

Описание алгоритма решения задачи (последовательности действий и логики решения задачи):

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

- описание связей между частями, операциями, формулами алгоритма;

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

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

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

 

3. Основы (инструментальная среда) BPwin

 

BPwin имеет достаточно простой и интуитивно понятный интерфейс пользователя. При запуске BPwin по умолчанию появляется основная панель инструментов, палитра инструментов (вид которой зависит от выбранной нотации) и, в левой части, навигатор модели — Model Explorer (рис. 1).

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

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

 

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

Рис. 2. Диалог создания модели

 

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

Построение модели IDEF0

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

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

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

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

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

Цель моделирования определяется из ответов на следующие вопросы:

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

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

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

Точка зрения (Viewpoint).

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

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

 

Рис. 3. Диалог задания свойств модели

 

В закладке Status того же диалога можно описать статус модели (черновой вариант, рабочий, окончательный и т. д.), время создания и последнего редактирования (отслеживается в дальнейшем автоматически по системной дате). В закладке Source описываются источники информации для построения модели (например, "Опрос экспертов предметной области и анализ документации"). Закладка General служит для внесения имени проекта и модели, имени и инициалов автора и временных рамок модели — AS-IS и ТО-ВЕ.

Модели AS-IS и ТО-ВЕ. Обычно сначала строится модель существующей организации работы — AS-IS (как есть). Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) — модели новой организации бизнес-процессов.

Технология проектирования ИС подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов, то есть создание модели ТО-ВЕ, и только на основе модели ТО-ВЕ строится модель данных, прототип и затем окончательный вариант ИС.

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

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

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

 

Рис.4. Диалоговое окно для формирования отчета по модели

На рис. 5 представлен отчет, сформированный по вышеуказанным полям.

 

Рис.5. Предварительный просмотр отчета

 

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

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

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

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

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

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

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

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

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

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

 

Рис.6. Пример контекстной диаграммы

 

Для внесения имени работы следует щелкнуть по работе правой кнопкой мыши, выбрать в меню Name Editor и в появившемся диалоге внести имя работы. Для описания других свойств работы служит диалог Activity Properties (рис.7).

 

Рис. 7. Редактор задания свойств работы

 

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

Возникает диалог Activity Box Count (рис. 8), в котором следует указать нотацию новой диаграммы и количество работ на ней. Остановимся пока на нотации IDEF0 и щелкнем на ОК. Появляется диаграмма декомпозиции (рис.9). Допустимый интервал числа работ — 2-8. Декомпозировать работу на одну работу не имеет смысла: диаграммы с количеством работ более восьми получаются перенасыщенными и плохо читаются. Для обеспечения наглядности и лучшего понимания моделируемых процессов рекомендуется использовать от трех до шести блоков на одной диаграмме.

 

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

 

Рис. 9. Пример диаграммы декомпозиции

 

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

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

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

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

Стрелки(Arrow) описывают взаимодействие работ и представляют собой некую информацию, выраженную существительными.(Например, "Звонки клиентов", "Правила и процедуры", "Бухгалтерская система".)

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

Вход(Input) — материал или информация, которые используются или преобразуются работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Каждый тип стрелок подходит к определенной стороне прямоугольника, изображающего работу, или выходит из нее. Стрелка входа рисуется как входящая в левую грань работы. При описании технологических процессов (для этого и был придуман IDEF0) не возникает проблем определения входов. Действительно, "Звонки клиентов" на рис.6 — это нечто, что перерабатывается в процессе "Деятельность компании" для получения результата. При моделировании ИС, когда стрелками являются не физические объекты, а данные, не все так очевидно. Например, при "Приеме пациента" карта пациента может быть и на входе и на выходе, между тем качество этих данных меняется. Другими словами, в нашем примере для того, чтобы оправдать свое назначение, стрелки входа и выхода должны быть точно определены с тем, чтобы указать на то, что данные действительно были переработаны (например, на выходе — "Заполненная карта пациента"). Очень часто сложно определить, являются ли данные входом или управлением. В этом случае подсказкой может служить информация о том, перерабатываются/изменяются ли данные в работе или нет. Если изменяются, то, скорее всего, это вход, если нет — управление.

Управление(Control) — правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы. На рис.6 стрелка "Правила и процедуры" — управление для работы "Деятельность компании". Управление влияет на работу, но не преобразуется работой. Если цель работы — изменить процедуру или стратегию, то такая процедура или стратегия будет для работы входом. В случае возникновения неопределенности в статусе стрелки (управление или вход) рекомендуется рисовать стрелку управления.

Выход(Output) — материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы. На рис.6 стрелки "Маркетинговые материалы" и "Проданные продукты" являются выходом для работы "Деятельность компании".

Механизм(Mechanism) — ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т. д. Стрелка механизма рисуется как входящая в нижнюю грань работы. На рис.6 стрелка "Бухгалтерская система" является механизмом для работы "Деятельность компании". По усмотрению аналитика стрелки механизма могут не изображаться в модели.

Вызов(Call) — специальная стрелка, указывающая на другую модель работы. Стрелка вызова рисуется как исходящая из нижней грани работы. На рис.10 стрелка "Другая модель работы" является вызовом для работы "Изготовление изделия". Стрелка вызова используется для указания того, что некоторая работа выполняется за пределами моделируемой системы. В BPwin стрелки вызова используются в механизме слияния и разделения моделей.

Рис.10. Стрелка вызова, появляющаяся при расщеплении модели

 

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

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

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

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

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

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

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

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

 

Рис.11. Диалог IDEF0 Arrow Properties

 

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

BPwin вносит ICOM-коды автоматически. Для отображения ICOM-кодов следует включить опцию ICOM codes на закладке Display диалога Model Properties (меню Model/Model Properties) (рис.12).

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

 

Рис.12. Включение опции ICOM codes на закладке Display

 

Рис.13. Редактирование словаря стрелок

 

Содержимое словаря стрелок можно распечатать в виде отчета (меню Tools/ Report /Arrow Report...) и получить толковый словарь терминов предметной области, использующихся в модели.

Несвязанные граничные стрелки (unconnected border arrow). При декомпозиции работы входящие в нее и исходящие из нее стрелки (кроме стрелки вызова) автоматически появляются на диаграмме декомпозиции (миграция стрелок), но при этом не касаются работ. Такие стрелки называются несвязанными и воспринимаются в BPwin как синтаксическая ошибка.

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

 

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

 

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

Для рисования внутренней стрелки необходимо в режиме рисования стрелок щелкнуть по сегменту (например, выхода) одной работы и затем по сегменту (например, входа) другой. В IDEF0 различают пять типов связей работ. Связь по входу(output-input), когда стрелка выхода вышестоящей работы (далее — просто выход) направляется на вход нижестоящей (например, на рис.15 стрелка "Собранные компьютеры" связывает работы "Сборка и тестирование компьютеров" и "Отгрузка и получение").

Рис.15. Связь по входу

Связь по управлению(output-control), когда выход вышестоящей работы направляется на управление нижестоящей. Связь по управлению показывает доминирование вышестоящей работы. Данные или объекты выхода вышестоящей работы не меняются в нижестоящей. На рис.16 стрелка "Заказы клиентов" связывает работы "Продажи и маркетинг" и "Сборка и тестирование компьютеров".

 

Рис.16. Связь по управлению

 

Обратная связь по входу(output-input feedback), когда выход нижестоящей работы направляется на вход вышестоящей. Такая связь, как правило, используется для описания циклов. На рис.17 стрелка "Результаты тестирования" связывает работы "Тестирование компьютеров" и "Отслеживание расписания и управление сборкой и тестированием".

 

Рис.17. Обратная связь по входу

 

Обратная связь по управлению(output-control feedback), когда выход нижестоящей работы направляется на управление вышестоящей (стрелка "Результаты сборки и тестирования", рис.18). Обратная связь по управлению часто свидетельствует об эффективности бизнес-процесса. На объем продаж может быть повышен путем непосредственного регулирования процессов сборки и тестирования компьютеров (выхода) работы "Сборки и тестирование компьютеров".

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

Явные стрелки. Явная стрелка имеет источником одну-единственную работу и назначением тоже одну-единственную работу.

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

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