Методические указания к выполнению лабораторной работы для студентов дневной формы обучения специальности 230201 «Информационные системы и технологии» Брянск 2007

Вид материалаМетодические указания

Содержание


1. Цель работы
2. Основные теоретические положения
3. Основные приемы работы с пакетом BPwin
Создание Функциональных Блоков
Добавление текста к функциональному блоку
Декомпозирование Функционального Блока
4. Последовательность выполнения работы
5. Форма отчетности
6. Контрольные вопросы
Список рекомендуемой литературы
Глоссарий терминов
Диаграмма верхнего уровня A0I3 –
Операция (Activity) –
Affinity matrix (матрица подобий) –
Activity prefix (префикс операций) –
Arrow association (дуга связи) –
Arrow Stab (метка дуги) –
BPX – формат файла BPwin. Используется для экспорта объектов и информации атрибута в Erwin. Branch arrow (дуга перехода) –
Function (lеловая функция) –
Business process (бизнес
...
Полное содержание
Подобный материал:




«УТВЕРЖДАЮ»

Ректор университета

_________________А.В. Лагерев

«________»_____________2007 г.


Информационные технологии


Проектирование систем с использованием SADT-методологии.


Методические указания

к выполнению лабораторной работы для студентов дневной формы обучения специальности 230201 – «Информационные системы и технологии»


Брянск 2007

УДК 004.43


Проектирование систем с использованием SADT-методологии. Методические указания к выполнению лабораторной работы для студентов дневной формы обучения специальности 230201 – «Информационные системы и технологии».– Брянск: БГТУ, 2006. – 27 с.


Разработали: Ю.М. Казаков, к.т.н., доцент


Рекомендовано кафедрой «Компьютерные технологии и системы» БГТУ (протокол №__ от ___.___.07 г.)


Научный редактор Ю.М.Рытов

Редактор издательства Т.И.Королева

Компьютерный набор Ю.М.Казаков


Темплан 2007 г., п.




Подписано в печать

Формат 60 х 84 1/16. Бумага офсетная. Офсетная печать.

Усл. печ. л. 5,98. Уч. – изд. л. 5,23. Тираж 100 экз. Заказ. Бесплатно




Брянский государственный технический университет

241035, Брянск, бульвар 50-летия Октября, 7, тел. 54-90-49

Лаборатория оперативной полиграфии БГТУ, ул. Институтская, 16

Брянск, бульвар им. 50- летия Октября, 7, тел. 55-90-49

Лаборатория оперативной полиграфии БГТУ, ул. Институтская, 16

ВВЕДЕНИЕ



Много организаций сегодня постоянно пересматривают свою бизнес-стратегию (BPR - Business Process Reengineering). Исследование существующих на текущий день процессов и полнофункциональное вовлечение служащих фирмы - важный шаг в улучшение эффективности компании в целом. Простой процесс документирования работы указывает области, где усовершенствование необходимо. Если вырисовываются глобальные изменения в бизнесе на уровне корпораций, модель текущего состояния бизнеса позволяет Вам лучше оценить воздействие этих изменений.

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

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

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

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

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

1. ЦЕЛЬ РАБОТЫ



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

Продолжительность лабораторной работы – 4 часа. Первые два часа отводятся на ознакомление с методическими указаниями (п. 2-4) и [1]. На третьем и четвертом часе занятий необходимо теоретически решить задачи, представленные в п. 2-4, и оформить отчет по проделанной лабораторной работе – п. 4.

Результаты, полученные при выполнении работы, могут быть использованы также студентами специальностей 220300 – «Системы автоматизированного проектирования», 220400 – «Программное обеспечение вычислительной техники и автоматизированных систем» для решения задачи по декомпозиции систем в курсовом и дипломном проектировании.

2. Основные теоретические положения



Методология IDEF0 (более известная как методология SADT-Structure Analysis and Design Technique) предназначена для представления функций системы и анализа требований к системам и является одной из самых известных и широко используемых методологий проектирования автоматизированных систем управления.

В терминах IDEF0 система представляется в виде комбинации блоков и дуг. Блоки используются для представления функций системы и сопровождаются текстами на естественном языке. Кроме функциональных блоков другим ключевым элементом методологии является дуга. Дуги представляют множества объектов(как физических, так и информационных) или действия, которые образуют связи между функциональными блоками. Место соединения дуги с блоком определяет тип интерфейса. Управляющие выполнением функции данные входят в блок сверху, в то время как информация, которая подвергается воздействию функции, показана с левой стороны блока; результаты выхода показаны с правой стороны. Механизм (человек или автоматизированная система), который осуществляет функцию, представляется дугой, входящей в блок снизу (рис. 1).



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


В основе методологии IDEF0 лежат следующие правила:
  • Функциональный блок (или Функция) преобразует Входы в Выходы (т.е. входную информацию в выходную), Управление определяет, когда и как это преобразование может или должно произойти Исполнители непосредственно осуществляют это преобразование.
  • С дугами связаны надписи (или метки) на естественном языке, описывающие данные, которые они представляют.
  • Дуги показывают, как функции между собой взаимосвязаны, как они обмениваются данными и осуществляют управление друг другом.
  • Выходы одной функции могут быть Входами, Управлением или Исполнителями для другой.
  • Дуги могут разветвляться и соединяться.
  • Функциональный блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных между собой интерфейсными дугами.
  • Эти блоки представляют основные подфункции (подмодули) единого исходного модуля.
  • Данная декомпозиция выявляет полный набор подмодулей, каждый из которых представлен как блок, границы которого определены интерфейсными дугами.
  • Каждый из этих подмодулей может быть декомпозирован подобным же образом для более детального представления.



3. Основные приемы работы с пакетом BPwin



Активизируйте файл BРwin. Выберите тип методологии (по умолчанию IDEF0), наберите имя модели "STUDENT" и нажмите – OK (рис. 2).



Рис. 2. Назначение имени и выбор типа модели


Создается единственный блок на странице. Начальная установка нотации для блока высшего уровня в BPwin – "A0". Вы можете иметь только одну страницу высшего уровня в модели (рис. 3).


Создание Функциональных Блоков


Есть два пути создания функциональных блоков на IDEF-странице:
  • размещая их как группу или;
  • рисуя их один за другим.


Размещение Группы Блоков


Команда Разместить Блоки (Create or go to child diagram) в IDEF0-меню позволяет Вам расположить указанное число блоков на странице. Максимальное число блоков, которое Вы можете разместить, и их размер определяются в диалоге Атрибутов (меню-IDEF0).

Выберите Разместить Блоки (Create or go to child diagram) в IDEF0 меню. В диалоге наберите число блоков для размещения на текущей странице (рис. 4). Нажмите кнопку OK




Рис. 3.Страница высшего порядка – А-0




Рис. 4. Выбор типа нотации и количества блоков декомпозиции


Блоки появляются на странице равномерно от левого верхнего угла к правому нижнему углу страницы (рис. 5).




Рис. 5. Декомпозиция системы в нотации IDEF0 на 4 блока


Создание стрелок


Выберите Стрелку (Arrow) .

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

Тяните инструмент стрелки через границу исходного блока или ярлыка до ярлыка или блока места назначения.

Нажмите левую кнопку "мыши", чтобы закончить стрелку (рис. 6).

BPwin рисует стрелку к стороне объекта, ближайшей к точке срабатывания "мыши".



Рис. 6. Изображение стрелок в нотациях IDEF0, IDEF3, DFD


Добавление текста к функциональному блоку


Текст в функциональном блоке содержится в пределах единственного графического объекта. Для того чтобы ввести текст в функциональный блок, необходимо активизировать правой кнопкой "мыши" свойства функционального блока и выбрать опцию "Name Editor" (рис. 7). В появившемся окне "Name" (рис. 8), в строку поля имени блока введите название блока. Например, "ОБУЧЕНИЕ В УНИВЕРСИТЕТЕ". В строку поля "AUTHOR" введите фамилию автора проекта. Например, "Иванов". Нажмите кнопку "ОK".

Когда вы делаете режим текста активным, тогда возможно создать, редактировать, форматировать, выбирать и искать текст.


Декомпозирование Функционального Блока


Смотри "Размещение Группы Блоков".




Рис. 7. Выбор меню для редактирования Рис. 8. Меню редактирования

названия блока диаграммы названия блока диаграммы


Функционально-стоимостный анализ (ФСА) (Activity Based Costing - ABC)


BPwin предоставляет аналитику два инструмента для оценки модели – стоимостной анализ, основанный на работах (Activity Based Costing, ABC) и свойства, определяемые пользователем (User Defined Properties, UDP). ABС является широко распространенной методикой, используемой международными корпорациями и государственными организациями (в том числе Департаментом обороны США) для идентификации истинных движителей затрат в организации.

Стоимостной анализ представляет собой соглашение об учете, используемое для сбора затрат, связанных с работами, с целью определить общую стоимость процесса. Стоимостной анализ основан на модели работ, поскольку количественная оценка невозможна без детального понимания в функциональности предприятия. Обычно ABC применяется для того, чтобы понять происхождение выходных затрат и облегчить выбор нужной модели работ при реорганизации деятельности предприятия (Business Process Re-engineering, BPR). С помощью стоимостного анализа можно решить такие задачи, как определение действительной стоимости производства продукта, определение действительной стоимости поддержки клиента, идентификация работ, которые стоят больше всего (те, которые должны быть улучшены в первую очередь), обеспечение менеджеров финансовой мерой предлагаемых изменений т.д.

ABC может проводиться только когда модель работы последовательная (следует синтаксическим правилам IDEF0), корректная (отражает бизнес), полная (охватывает всю рассматриваемую область) и стабильная (проходит цикл экспертизы без изменений). Эта методика включает основные понятия: объект затрат (причина, по которой работа выполняется, обычно, основной выход работы, стоимость работ есть стоимость объектов затрат), движитель затрат (характеристики входов и управлений работы, которые влияют на то, как выполняется и как долго длится работа) и центры затрат (центры затрат можно трактовать как статьи расхода). При проведении стоимостного анализа в BPwin сначала задаются единицы времени и денег, затем описываются центры затрат (cost centers) и, наконец для каждой работы на диаграмме декомпозиции назначаются продолжительность (duration), частота проведения данной работы в рамках общего процесса (frequency) и суммы по каждому центру затрат, то есть задается стоимость каждой работы по каждой статье расхода (рис. 9). Затраты вышестоящей работы определяются как сумма затрат дочерних работ по каждому центру затрат (режим Compute from Decompositions). Это достаточно упрощенный принцип подсчета справедлив, если работы выполняются последовательно. Если схема выполнения более сложная, можно отказаться от подсчета и задать итоговые суммы вручную (Override Decompositions) или воспользоваться специализированным средством стоимостного анализа EasyABC. Результаты стоимостного анализа наглядно представляются на специальном отчете BPwin - Activity Cost Report.

ABC позволяет оценить стоимостные и временные характеристики системы. Если стоимостных показателей недостаточно, имеется возможность внесения собственных метрик - свойств, определенных пользователем (User Defined Properties, UDP). Имеется возможность задания 18 различных типов UDP, в том числе управляющих команд и массивов, объединенных по категориям. Например, категория «Загрязнение окружающей среды», может объединять свойство «загрязнение воды» типа Real Number и свойство «загрязнение воздуха» типа Integer List с предварительно определенной областью значений (1, 2, 3, 4, 5). Каждой работе можно поставить в соответствие набор UDP и проанализировать результат в специальном отчете Diagram Object Report.



Рис. 9. Задание стоимости работ в диалоге Activity Cost


4. Последовательность выполнения работы



Лабораторная работа выполняется в следующей последовательности:
  1. Изучить методику составления модели с помощью пакета BPwin.
  2. Составить схему функциональной модели в соответствии с заданным вариантом.
  3. Принять в качестве гипертекста вариант задания, привязанный к нулевому уровню модели. Данные для вариантов приведены в таблице. Для декомпозированных и новых функциональных блоков получить данные у преподавателя.
  4. Записать модель на диск с именем: шифр группы_номер, варианта_подгруппа. Например 467_1_3.idd.



5. Форма отчетности



Отчет по лабораторной работе представляется в виде файла с именем в соответствии с п.4 и расширением *.idd. В состав файла входят:
  • собственно модель;
  • гипертекст;
  • глоссарий с данными ФСА.



6. Контрольные вопросы



1. Какое назначение имеет функциональная модель в процессе проектирования автоматизированной системы управления?

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

3. Опишите правила формирования функциональных блоков (иерархия, нумерация, обозначение).

4. Опишите правила создания стрелок (направление, тип интерфейса, обозначение).

5. Объясните принцип работы и порядок создания гипертекста.

6. Как выполняется функционально-стоимостной анализ по функциональной модели IDEF0 (принципы, порядок, интерпретация)?

Таблица

Задания для выполнения лабораторной работы

1

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

2

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

3

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

4

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

5

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

6

Создать функциональную модель работы лазерного принтера

7

Создать функциональную модель монитора компьютера

8

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

10

Создать функциональную модель деревянной модели изделия в модельном цехе машиностроительного производства

11

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

12

Создать функциональную модель информационных технологий

13

Создать функциональную модель создания частного предприятия, с учётом приобретения необходимого оборудования, лицензирования деятельности и набора персонала

14

Создать функциональную модель внедрения рационализаторского предложения на производстве

15

Создать функциональную модель хранения информации



Список рекомендуемой литературы




  1. Зиндер Е.З. Бизнес-реинжиниринг и технологии системного проектирования. Учеб. пособие. – М.: Центр информационных технологий, 1996.
  2. Калянов Г.Н. CASE. Структурный системный анализ (автоматизация и применение). – М.: "Лори", 1996.
  3. Марка Д.А., МакГоуэн К. Методология структурного анализа и проектирования. – М.: "МетаТехнология", 1993.
  4. Новоженов Ю.В. Объектно-ориентированные технологии разработки сложных программных систем. – М.: "МетаТехнология", 1996.
  5. Панащук С.А. Разработка информационных систем с использованием CASE-системы Silverrun // СУБД. – 1995. – №3.
  6. Горин С.В., Тандоев А.Ю. Применение CASE-средства Erwin 2.0 для информационного моделирования в системах обработки данных // СУБД. – 1995. – №3.



Глоссарий терминов



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

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

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

Операция (Activity) – термин, принятый для описания действия, которое обрабатывает или преобразует данные или ресурсы (например: Process orders - Распоряжения, Run Video Store - Работа видео хранилища). Модель IDEF0 подсвечивает неактивные операции (которые не имеют средств управления и-или выходов) и облегчает этап повторного проектирования бизнес-процесса. Операция IDEF3, также называемая модулем режима или UOW, описывает процесс, действие, решение или другую процедуру, имеющуюся в системе или бизнесе. Операция DFD описывает действие, которое обрабатывает или преобразует данные.

Affinity matrix (матрица подобий) – таблица, которая облегчает анализ системы и процесс ее проектирования посредством введения: 1) стрелок в модели, 2) связанных с дугами в модели объектов и атрибутов и 3) присвоения для каждой дуги статуса IRUN или CRUD.

Activity prefix (префикс операций) – символ (обычно "A"), который предшествует номеру операций (например, 1.2).

Arrow (дуга) – дуга на IDEF0 диаграмме, предназначена для отображения входа, управления, выхода или механизма (ICOM) операций. В IDEF3 дуги предназначены для отображения порядка или присвоения старшинства операций (сплошная линия), связи (пунктирная линии) или потоком объектов (сплошная двойная дуга). В DFD дуга предназначена для отображения потока данных между операциями, сохранения данных и внешних ссылок.

Arrow association (дуга связи) – данные CRUD или IRUN объекта и-или атрибута, который назначен для дуги IDEF0.

Arrow segment (сегмент дуги) – часть дуги: головка, середина или хвост расщепляющейся или сливающейся дуги разбиения.

Arrow Stab (метка дуги) – часть созданной BPwin дуги для показа существования незавершенных постраничных ссылок или неопределенной дуги.

AS-IS MDEL (модель КАК ЕСТЬ) – модель, основанная на работе бизнеса или организация в настоящий момент.

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

Author (автор) – имя человека, отдела или наименование бизнеса, который ввел в диаграмму BPwin или оригинал документа IDEF0, IDEF3 или DFD операцию, дугу, базу данных или информацию внешней ссылки.

border arrow (дуга рамки) – дуга, соединяющая операцию и рамку диаграммы.

BPSimulator – инструмент моделирования, в котором Вы можете повторно использовать ваши модели BPwin для просмотра динамически взаимодействий (взаимодействий во времени) вашего бизнес-процесса. Затем для достижения намеченных бизнес-целей проводится выявление ресурсов и оптимизация потоков процессов.

BPX – формат файла BPwin. Используется для экспорта объектов и информации атрибута в Erwin.

Branch arrow (дуга перехода) – дуга, которая ответвляется от другой дуги.

Function (lеловая функция) – термин, используемый для описания выполняемых в ходе бизнес-процесса операций. IDEF0 обеспечивает поддержку моделирования деловых функций через систему обозначений, которую поддерживают операции и ICOM.

Business process (бизнес-процесс) – термин, используемый для описания хода выполняемых бизнес-процессом операций. IDEF3 обеспечивает поддержку моделирования бизнес-процессов через систему обозначений, которые поддерживают принципы синхронизации операций и старшинства.

C-number (с-номер) – хронологический номер. Присваивается каждой диаграмме один раз и позволяет проследить хронологию. С-номер может использоваться в качестве Detail Reference Expression (индивидуальный номер спецификации), что позволяет определить отдельную версию диаграммы.

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

Child diagram (диаграмма-потомок) – диаграмма, которая содержит два или более подпроцесса внутри одиночной родительской операции. Диаграмма-потомок также называется диаграммой декомпозиции.

Color palette (цветовая палитра) – набор цветов, принятых в BPwin и используемых для приведения в соответствие присвоения цвета в наборе связанных диаграмм.

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

Context diagram (контекстная диаграмма) – диаграмма, описывающая операцию самого высокого уровня в модели. Контекстная диаграмма представляет границу процесса при анализе с учетом цели, пределов и точки зрения.

Control arrow (дуга управления) – дуга, которая вводит верхнюю часть IDEF0 рамки операции, которая представляет собой ограничение на действие относительно того, как, когда, и-или, при условии, если действие находится в процессе выполнения (например, правила, упорядочивание, алгоритм распределения, процедуры, стандарты). Смоделированные как средства управления функцией данные или объекты не преобразуются. Дуги управления связаны с верхней стороной рамки IDEF0.

Cost (стоимость) – стоимость является частью центра стоимости. Для получения общей стоимости необходимо стоимость каждого центра умножить на частоту операций.

Cost center (центр стоимости) – любой выделенный модуль бизнес-процесса, функция или условие (например, трудоемкость, материалы, производство, управление или непроизводительные затраты), которые формируют фактическую стоимость по завершении операции.

Child box (дочернее поле) – рамка на диаграмме-потомке.

Context (контекст) – непосредственная операционная среда, в которой работает функция (или набор функций на диаграмме).

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

Data flow (поток данных) – дуга, проходящая между символами на диаграмме потока, для обозначения потока данных. Каждая дуга должна иметь и источник и адресат. В отличие от стрелок IDEF0 (ICOMs) дуги DFD могут вводить или выходить с любой стороны операций.

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

Datastore (база данных) – способ задания функций, который используется в DFD для показа потока данных в направлении к и от таблицы базы данных и-или объекта ERwin.

Decompose (разложение на составные части) – разбиение операции на составные части или подпроцессы.

Decomposition (декомпозиция) – выделение разделов смоделированной функции в функции компонентов.

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

Definition (определение) – определение или цель модели бизнес процесса.

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

DFD – диаграмма потока. Графическое представление (блок-схема) системы обработки данных, которое описывает данные системы и операций, а затем их обрабатывает или преобразует.

Diagram (диаграмма) – одиночный модуль модели IDEF0, IDEF3 или DFD. Модель IDEF0 содержит детали операции. Модель IDEF0 включает четыре типа базисных диаграмм: контекст, декомпозиция, дерево узлов и FEO.

Draft status (черновое состояние) – состояние, когда диаграмма имеет рабочий уровень утверждения проекта несколькими разработчиками. Далее “черновиком” называется диаграмма с незначительными изменениями по сравнению с предыдущей диаграммой. Это состояние не будет подвергаться усовершенствованию до тех пор, пока не будет решения официального комитета по пересмотру.

Duration (продолжительность) – средний отрезок времени, необходимый для завершения операции.

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

ERwin – программный продукт компании Logic Works inc., являющийся инструментом моделирования данных.

Entity (объект) – логическое представление таблицы базы данных. Объект может быть создан в BPwin или программе моделирования данных ERwin компании Logic Works.

External reference (внешняя ссылка) – координаты расположения, объект, человек или отдел, который является источником или адресатом данных, расположенный, однако вне пределов диаграммы потока (DFD). Внешняя ссылка может быть внутренней по отношению к компании, типа “ Accounts Payable ” (счета на оплату) или внешней, как-то “Vendor ” (продавец) или “Bank” (банк). Понятие «внешняя ссылка» совпадает по значению с понятием «внешний объект», принятым в системе обозначений Gane и Sarson.

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

Fan-in (коэффициент объединения по входу) – переход, который описывает соединение или совпадение различных путей обработки в единый процесс.

Fan-out (разветвление на выходе) – переход, который описывает разбиение или дивергенцию процесса на различные варианты обработки.

FEO – диаграмма “ Только для просмотра ” (FEO) используется как инструмент для пояснения пути процесса, отображения отличной точки зрения или выделения подсветкой других функциональных деталей, которые не поддерживаются синтаксисом IDEF0. Диаграммы FEO могут аннотироваться дополнительным объяснительным текстом, в котором не требуется соблюдение правил IDEF0.

Frequency (частота) – среднее число раз использования операции для каждого разового вхождения родительской операции.

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

Go-to referent (переход к) – ссылка (то, с чем соотносится), которая позволяет диаграмме охватить несколько страниц и поддерживает выполнение цикла между диаграммами и цикла возврата к UOW, проходившего ранее в диаграмме. Указывает UOW или переход, который инициализируется после завершения вызванного процесса.

Guest (гость) – параметр защиты пользователя ModelMart, который присваивается по умолчанию новым пользователям. Параметр защиты пользователя не накладывает никаких ограничений.

ICOM – акроним категорий информации (ввод, вывод, управление или механизм) собранных в модели IDEF0. Акронимы представляют собой ряд объектов, воздействующих на операцию, начиная с сырья и заканчивая готовой продукцией, расходуемые и нерасходуемые ресурсы, оборудование и правила управления операцией. «При управлении, операция преобразует входы в выходы посредством механизмов».

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

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

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

IDL – стандартный формат файла, используемый для импорта и экспорта данных модели IDEF0.

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

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

Internal arrow (внутренняя дуга) – вход, управление или дуга выхода, начинающаяся и заканчивающаяся (источник и обработка) на рамке диаграммы.

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

Join (объединение) – переход, в котором сегмент дуги IDEF0 (идущий от источника к обработке) объединяется с одним или несколькими сегментами дуги в форме одиночного сегмента дуги. Может обозначать связь значений сегмента дуги.

Junction (переход) – конструкция IDEF3, которая отображает переход процесса. Для отображения доступны различные типы перехода, а именно: условия И или ИЛИ и ИСКЛЮЧАЮЩЕЕ ИЛИ, а так же дальнейшая подсветка синхронизации (синхронное или асинхронное начало и-или завершение) связанных операций.

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

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

Leaf corner (угол листа) – линия по диагонали поперек верхнего левого угла операции IDEF0. Наносится для указания отсутствия каких-либо связанных диаграмм декомпозиции.

Leaf level activity (уровень операции листа) – нерасчлененная операция IDEF0 или IDEF3 UOW. Уровень операции обозначается "/" в верхнем левом углу операции или UOW.

Link (связь) – Дуга IDEF3. Связь старшинства (сплошная дуга) описывает важную командную связь среди операций (UOB) – поток объектов или старшинство операций. Реляционная связь (пунктирная дуга) отображает связь между операциями. Связь потока объектов (двойная дуга) указывает на участие объекта в двух операциях.

Mechanism arrow (дуга механизма) – дуга, входящая в нижнюю часть рамки операций IDEF0, которая отображает человека, машину или другой нерасходуемый ресурс, необходимый для выполнения действия. Под это определение подходит и специальный вид Call Arrow (дуги обращения).

Model (модель) – набор диаграмм и вспомогательной текстовой информации или глоссария, который требуется для подробного пояснения бизнес-процесса и-или функции. Модель IDEF0 имеет определенную границу, цель и точку зрения и состоит из одной части. A-0 контекстная диаграмма является связанной с ней диаграммой (диаграммами) декомпозиции.

Model note (примечание модели) – текстовый комментарий, который является частью диаграммы IDEF0; используется для записи факта никак иначе не описанного.

Model dictionary (словарь модели) – структурная часть BPwin, которая сохраняет имя, состояние, имя автора, определения, примечания, источник, цвет и шрифт для каждого объекта IDEF0 и-или модели DFD.

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

Name (имя) – имя, присвоенное операции диаграммы, UOW, внешней ссылке или базе данных.

Node (узел) – рамка создания дочерних рамок; родительская рамка. Смотрите алфавитный указатель по следующим терминам: node (узел), node tree (дерево узлов), node number (номер узла), diagram node reference (справочный номер узла диаграммы).

Node index (указатель узлов) – список, зачастую с выравниванием, отображающий узлы модели IDEF0 иерархическом порядке.

Node number (номер узла) – номер диаграммы, который соответствует номеру операций родительской диаграммы.

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

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

Note referent (необязательная ссылка) – дополнительная информация, связанная с объектом потока работ.

Object (объект) – любая диаграмма операции, UOW, внешняя ссылка или база данных.

Object referent (ссылка по объекту) – ссылка (то, с чем соотносится), которая подчеркивает участие особых объектов или отношений в UOW (например, видеолента в видео хранилище).

Objects (объекты) – раздел детальной разработки документа IDEF3, который содержит перечень участвующих в процессе UOW физических объектов. Из описания объектов UOW должно быть ясно, является ли объект фактором (исполняющим процесс), изменен ли процессом, участвует ли без выполнения процесса или был преобразован процессом, создан или разрушен в течение процесса.

Off-page reference (постраничная ссылка) – ссылка от одной операций до связанной с ней операцией другой диаграммы модели (например, между процессом номер 2.4 и процессом номер 5.3.3).

OSTN diagram (диаграмма OSTN) – акроним диаграммы переходов состояний объектов; используется для моделирования состояния объекта особым образом или посредством потока данных.

Other status (другое состояние) – состояние, определенное отдельными модулями бизнес процесса.

Output (выход) – дуга, выходящая справа рамки операций IDEF0; представляет собой материал или информацию, полученную по прошествии операции.

Parent activity (родительская операция) – расчлененная в диаграмму-потомок операция, содержащая два или более подпроцесса.

Parent box (родительская рамка) – рамка, содержащая диаграмму-потомок.

Parent diagram (родительская диаграмма) – диаграмма, которая содержит родительскую рамку.

Persistent numbers (постоянные числа) – относительный номер и постоянный номер, который может быть присвоен каждому действию вашей IDEF0 диаграммы. Постоянные номера остаются неизменными в течение всего срока существования модели независимо от того, где появляется операция в диаграмме. В свою очередь, относительный номер изменяется в зависимости от положения операции в диаграмме.

Publication status (состояние публикации) – состояние, когда работа над диаграммой закончена и форма ее одобрена всеми заинтересованными сторонами.

Purge (очистка) – операция BPwin, которая устраняет неиспользуемую операцию, базу данных, внешнюю ссылку или наименования дуги из словаря модели.

Purpose (цель) – объяснение причины изучения процесса, содержания модели и какие действия может производить с ней пользователь.

Recommended status (рекомендуемое состояние) – состояние, когда диаграмма и вспомогательная текстовая информация была рассмотрена и официально одобрена.

Referent – внешняя ссылка, которая используется в IDEF3 для поддержки выполнения цикла, постраничной ссылки, ограничения на переходы или ссылки между блок-схемами процесса и диаграммам перехода состояния объектов.

Scenario (сценарий) – термин сценария IDEF3 текущей диаграммы потока работ (больше, чем AB).

Scope (пределы) – ширина (боковые рамки в плоскости) и глубина (уровень подробности) внешних границ модели объекта.

Source (источник) – имя человека, отдела или род бизнеса, от которого получена информация об операции, дуге, базе данных или информация внешней ссылки.

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

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

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

Subprocess (подпроцесс) – процесс, который происходит внутри контекста большего процесса.

Text (текст) – полный текстовый (неграфический) комментарий по графической диаграмме IDEF0.

TO-BE model (будущая модель) – схема моделирования работы процесса в будущем.

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

UOW – акроним IDEF3 Unit of Work (рабочего модуля). UOW (также называемый модулем поведения) описывает процесс, действие, решение или другую процедуру, происходящую в системе или бизнес-процессе внутри модели потока данных.

UOW referent – ссылка, относящаяся к предыдущему термину UOW, однако не дублирует его, а указывает на появление другого UOW на каком-либо определённом этапе процессе (без обратного цикла).

Unit of measure (модуль меры) – модуль вычисления продолжительности или частоты вхождения операции. Модули меры задействуются на определённое время и служат в качестве справочной информации.

Unresolved arrow (неопределенная дуга) – дуга рамки дочерней декомпозиции без эквивалентной ссылки в родительской диаграмме или дуга рамки родительской диаграммы без эквивалентной ссылки в дочерней декомпозиции.

User-defined property (определяемое пользователем свойство) – определяемое пользователем свойство (UDP) ,создается разработчиком модели для связи информации, характеризующий бизнес-процесс с операцией или дугой. BPwin поддерживает различные типы UDP, включая нисходящие списки “организаций” или “ уровня автоматизации ”. Команда UDP присоединяет мультимедийные ссылки и текстовые списки, сохраняя в памяти “основополагающие факторы успеха".

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

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


Оглавление


ВВЕДЕНИЕ 2

1. ЦЕЛЬ РАБОТЫ 4

2. Основные теоретические положения 4

3. Основные приемы работы с пакетом BPwin 6

4. Последовательность выполнения работы 12

5. Форма отчетности 13

6. Контрольные вопросы 13

Список рекомендуемой литературы 14

Глоссарий терминов 15