Главная · Монтаж · IDEF0: что такое и как используется. Методология IDEF0

IDEF0: что такое и как используется. Методология IDEF0

Размещено на http://www.allbest.ru/

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

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

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

Главной целью курсовой работы является разработка информационной системы для учета компьютерной техники предприятия, с использованием методологии функционального моделирования и графической нотации IDEF0, диаграмм потоков данных DFD и стандарта документирования процессов IDEF3, посредством программного продукта Computer Associates AllFusion Process Modeler r7.3. 2

2.1 Анализ программных продуктов 8

ВВЕДЕНИЕ

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

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

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

Главной целью курсовой работы является разработка информационной системы для учета компьютерной техники предприятия, с использованием методологии функционального моделирования и графической нотации IDEF0, диаграмм потоков данных DFD и стандарта документирования процессов IDEF3, посредством программного продукта Computer Associates AllFusion Process Modeler r7.3.

Для достижения этой цели необходимо решить следующие задачи:

    Анализ программных продуктов;

    Изучение методов проектирования информационных систем;

    Функциональное моделирование контекстной диаграммы и диаграмм декомпозиций бизнес – процесса (IDEF0) «Учет компьютерной техники предприятия»;

    Проектирование информационной системы с использованием диаграмм потоков данных (DFD);

    Использование методологии моделирования и стандарта документирования процессов IDEF3.

информационный поликлиника документирование программный

1. МЕТОДЫ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

В современной практике моделирования управленческой и производственной деятельности для обозначения объектов моделирования принято использовать термин «бизнес – процесс». При моделировании бизнес – процессов следует уделить внимание ряду факторов:

    Корректная постановка целей;

    Грамотная информированность персонала организации относительно целей и результатов проекта;

    Эффективное применение инструментов моделирования;

    Наличие корпоративных стандартов описания и регламентации бизнес – процессов.

Для моделирования бизнес - процессов используется несколько различных методов. Их основой являются как структурный, так и объектно-ориентированный подходы к моделированию. Наиболее развитые методы используют элементы обоих подходов. К числу наиболее распространенных методов можно отнести:

    метод функционального моделирования SADT (IDEF0);

    метод моделирования процессов IDEF3;

    моделирование потоков данных DFD;

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

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

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

В соответствии с этим методом бизнес – модель должна выглядеть следующим образом:

    Верхний уровень модели должен отражать только контекст системы, то есть её взаимодействие с внешним миром.

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

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

    Описание элементарной бизнес – операций осуществляется с помощью задания алгоритма ее выполнения.

Метод моделирования потоков данных DFD (Data Flow Diagrams)- диаграммы потоков данных. Основное средство моделирования функциональных требований к проектируемой системе.

Компоненты модели: диаграммы; словарь данных; спецификации процессов.

Элементы диаграмм: поток данных; хранилище; внешняя сущность.

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

Внешняя сущность-объект\субъект вне контекста системы, который является.

Хранилище – срез потоков данных во времени, содержащий данные, которые нужно сохранить между процессами.

Основные преимущества:

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

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

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

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

    существуют и поддерживаются рядом CASE-инструментов алгоритмы автоматического преобразования иерархии DFD в структурные карты, демонстрирующие межсистемные, внутрисистемные связи и иерархию систем

Недостатки:

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

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

Метод моделирования процессов IDEF3 (Integrated DEFinition for Process Description Capture Method) – методология моделирования и стандарт документирования процессов, происходящих в системе. Метод документирования технологических процессов предоставляет механизм документирования и сбора информации о процессах. IDEF3 показывает причинно-следственные связи между ситуациями и событиями в понятной эксперту форме, используя структурный метод выражения знаний о том, как функционирует система, процесс или предприятие.

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

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

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

2.1 Анализ программных продуктов

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

    Программное обеспеченье IT Invent (it-invent.ru)

    Программное обеспеченье Hardware Inspector (hwinspector.com)

    Конфигурация 1С:Учёт компьютеров и оборудования 8.1 (odineskin.ru)

Первая ИС, IT Invent, это не только учет компьютеров, принтеров, программ и комплектующих. Это так же учет ремонтов и обслуживаний, работ по поддержке техники, заказов поставщикам, поступлений и перемещений оборудования, учет контрагентов, сотрудников и многое другое. Основная форма программы IT Invent показана на рисунке 1.

Рисунок 1 «IT Invent»

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

    Поддержка базы данных MS Access и MS SQL Server.

    Многопользовательский режим работы - все филиалы работают с единой базой.

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

    Учет выполнения работ любых видов внутри организации.

    Уникальная система создания и печати инвентарных этикеток. Поддержка принтеров штрих-кодов.

    Поддержка работы со сканером штрих-кодов. Поиск записей в базе по штрих-коду.

    Ведение истории изменений по оборудованию.

    Учет ремонтов и профилактических обслуживаний оборудования и компьютеров.

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

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

    Закрепление учетных единиц за сотрудниками организации. Акты приёма-передачи.

    Ведение базы поставщиков, сервисных организаций и прочих контрагентов.

    Гибкое разграничение прав доступа для пользователей системы.

    Настройка E-Mail оповещений по событиям в программе.

    Большое количество встроенных печатных форм и отчетов с возможностью их редактирования.

    Импорт и просмотр данных напрямую из Active Directory.

Программа IT Invent является сетевой. Для работы по сети с единой базой данных, необходимо у каждого пользователя программы в файле "DBPath.ini" прописать путь для подключения к файлу базы данных или указать этот путь выбрав пункт меню "Файл" -> "Выбор базы данных". При этом нужно не забыть выставить каталогу с базой данных права на чтение и запись для всех пользователей программы.

Вторая ИС, это программа Hardware Inspector. Программа предназначена для автоматизированного учета и инвентаризации компьютерной техники и иного оборудования в организациях. Уникальность программы Hardware Inspector заключается в возможности вести учет не просто текущего состояния параметров компьютера, а всей истории жизни отдельных комплектующих. На рисунке 2, показано наглядное представление устройств в дереве рабочих мест.

Рисунок 2 «Hardware Inspector»

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

    Детальный учёт компьютеров и ПО;

    Жизненный цикл учетных объектов;

    Импорт устройств, ПО, рабочих мест и настроек сети;

    Автоматизированный аудит рабочих мест;

    Кроссировка сети;

    Учет и планирование расходных материалов;

    Учет заявок от пользователей;

    Инвентаризация учетных объектов;

    Гибкое разграничение доступа;

    Поиск информации;

    Более 30 встроенных настраиваемых отчетов;

    Подробные справочники по всем аспектам учета;

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

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

На рисунке 3 показана основная форма конфигурации 1С.

Рисунок 3 «1С:Учёт компьютеров и оборудования 8.1»

Основные характеристики продукта:

    Учёт любой техники, мебели, программного обеспечения,

    Учёт серийных, инвентарных номеров оборудования,

    Импорт из системы аппаратного аудита Everest (автоматический сбор данных)

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

    Учёт заявок поставщикам

Критерий

«Hardware Inspector»

Конфигурация 1С

Функциональность

Многофункциональна

Многофункциональна

Многофункциональна

Интерфейс

Интуитивно понятный

Простой – интуитивно понятный

Максимально удобный

Приемлемый

Стандартный

Удобство для пользователя

Проста в использовании

Индивидуальные наборы настроек

Достоинства

Работает по сети

    Работает по локальной сети

    Обновление 2 раза в месяц

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

Действует бесплатная линия консультаций по электронной почте и ICQ, а в случае необходимости консультации по телефону.

Недостатки

Программа платная

Программа платная

Программа платная

    Учёт заявок пользователей и работы с ними

    Учёт расходных материалов

    Автоматический поиск при сканировании

    Индивидуальные наборы настроек и др.

Сравним выбранные информационные системы в Таблице 1 по следующим критериям: Функциональность, Интерфейс, Дизайн, Удобство для пользователя, Достоинства и недостатки;

Таблица 1 - Сравнение информационных систем

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

2.2 Описание Диаграмм бизнес процесса «Учет компьютерной техники предприятия»

2.2.1 Описание IDEF0 диаграммы

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

    Контекстная

    Функциональная декомпозиция

    Декомпозиция каждой работы

Рисунок 1 - Контекстная диаграмма «Учет компьютерной техники предприятия»

На рисунке 1 представлена контекстная диаграмма бизнес процесса «Учет компьютерной техники предприятия». Она отображает систему в целом и ее взаимодействие с основными внешними потоками информации.

На контекстной диаграмме обозначены стрелки.

Виды стрелок:

Входная информация для обработки:

Компьютеры – ПК (персональные компьютеры) находящиеся на предприятии

Комплектующие – материалы, необходимые для модернизации компьютеров (видеокарты, материнские платы, процессоры, корпуса, блоки питания, модули памяти)

Выходные потоки:

Отчет – готовый отчет по учету компьютерной техники предприятия

Входные управления:

Правила – условия, которые необходимо соблюсти, что бы достичь поставленной цели.

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

Руководители – директора и главные управляющие предприятием.

Входные ресурсы:

ПК – компьютеры, с помощью которых ведется учёт.

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

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

Рисунок 2 - Функциональная декомпозиция «Учет компьютерной техники предприятия»

Были выделены следующие виды работ:

    Оформление поставок – процесс, в котором происходит присвоение id товару, отправка на хранение, на склад и занесение информации о товаре в программу.

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

Стрелка связь по входу между работами Оформление поставок и Обслуживание компьютера (компьютер);

Стрелки входа, выхода, управления повторяются в последующих работах.

    Обслуживание компьютера – процесс, в котором происходит сборка, ремонт и модернизация компьютеров.

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

Стрелка управление – правила, приказы, руководитель;

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

    Расстановка – процесс, в котором происходит расстановка компьютеров по офисам (кабинетам).

Стрелки управление – правила, приказы, руководитель;

Стрелка механизма – сотрудники;

Стрелка связь по входу между Расстановка и Составление отчета (присвоение id);

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

Затем каждая подсистема разбивается на более мелкие декомпозиции и так далее, до достижения нужной степени подробности.

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

В результате детализации были выделены основные функции. В раздел «Оформление поставок» входит семь главных стрелок (вход, выход, управление, механизм).

Стрелка входа – компьютеры и комплектующие;

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

Стрелки механизма, разветвляющие – ПК, сотрудники;

Стрелки входа, управления, механизмы повторяются во всех работах.

    Присвоение номера – присвоение индивидуального номера компьютерам и комплектующим.

Стрелки входа – компьютеры и комплектующие. Стрелка компьютеры повторяется в последующих работах, кроме составления отчета;

Стрелки управления – правила, приказы и руководитель;

Стрелки механизма – ПК и Сотрудники;

Стрелка связь по входу между работами Присвоение номера и Отправка товара на склад (перемещение), между «Присвоение номера» и «Постановка на баланс» (внесение в базу);

    Отправка товара на склад – оправка товара с присвоенным номером на склад.

Стрелка выхода – компьютер;

Стрелки управления – правила, приказы и руководитель.

Стрелка связь по входу между работами «Отправка товара на склад» и «Постановка на баланс» (количество);

    Постановка на баланс – занесение информации в компьютер.

Стрелки управления – правила, приказы и руководитель;

Стрелки механизма – ПК и Сотрудники;

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

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

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

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

Стрелка входа – компьютеры;

Стрелки управления – правила, приказы и руководитель;

Стрелки механизма – Сотрудники;

Стрелка связь по входу между работами: «Сборка компьютеров» и «Ремонт компьютеров» (компьютер);

    Ремонт компьютеров – сборка утвержденных к улучшению компьютеров.

Стрелка входа – компьютеры;

Стрелка выхода – занесение в базу;

Стрелки управления – правила, приказы и руководитель;

Стрелки механизма – Сотрудники;

Стрелки входа, выхода, управления, механизма являются разветвляющимися;

Стрелка связь по входу между работами: «Ремонт компьютеров» и «Upgrade» (комплектующие);

    Upgrade – усовершенствование, улучшение, обновление компьютера.

Стрелка выхода – занесение в базу;

Стрелки управления – правила, приказы и руководитель;

Стрелки механизма – Сотрудники;

Стрелки управления, механизма являются разветвляющимися;

На рисунке 5 представлена диаграмма «Составление отчета» более подробно. В декомпозицию работы Составление отчета входит 4 граничных стрелки (вход, выход, управление, механизмы). Внутренние стрелки (обратная связь по входу, связь по входу).

В результате работы были выведены следующие функции:

    Сбор данных – сбор информации для анализа и принятия решений.

Стрелка входа – присвоение id;

Стрелки управления – правила, приказы и руководитель;

Стрелки входа, управления, механизма являются разветвляющимися;

Стрелка связь по входу между работами: Сбор данных и Проверка данных (записи);

    Проверка данных – проверка информации и отправка ее на составление отчета.

Стрелка входа – присвоение id, занесение данных в базу;

Стрелка выхода – Отчет;

Стрелки управления – правила, приказы и руководитель;

Стрелки механизма – Сотрудники, ПК;

Стрелки входа (присвоение id), управления, механизма являются разветвляющимися;

Стрелкой обратной связи по входу с «Проверки данных» на «Сбор данных» (повторная проверка).

IDEF0: что такое и как используется

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

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

Преимущество графики

Что представляет собой модели IDEF0? Графические схемы со своими особенностями и правила их построения. Почему именно графика? Потому что она эффективна. В этом можно убедиться на нескольких примерах.

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

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

Преимущества IDEF0 для IT -специалистов

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

Так как же доступно донести суть, не прибегая к объемным текстам? Графика! Именно она позволяет сократить написанное, наглядно демонстрируя нужную информацию. Ведь одно изображение способно заменить сотни слов. И применительно к использованию графики при описании бизнес-процессов – это на 100% верно.

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

Нотация описания бизнес-процессов: что это такое

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

IDEF0 – это…

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

Функциональная модель компании

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

Типы стрелок

Входящими ставятся задачи.

Исходящими выводят результат деятельности.

Управляющие (стрелки сверху вниз) – это механизмы управления.

Механизмы (стрелки снизу вверх) используются для проведения необходимых работ.

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

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

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

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

Как создается функциональная модель

Разберем создание функциональной модели на примере написания статьи.

Основной блок будет так и называться «Написание статьи».

То, что необходимо для написания статьи, отражается на входящих стрелках – «Опыт», «Дополнительная литература».

Управляющие стрелки для написания статьи – «План статьи», «Требования к оформлению», «Правила русского языка».

Механизмы – это непосредственно сам автор, копирайтер, редактор, программное обеспечение. Как организуется работа этих механизмов? Автор создает текст, записывая его аудиоверсию. Копирайтер переносит текст в текстовый формат, ориентируясь на план публикации, соблюдая требования издателя и правила русского языка. Затем к работе подключается редактор, который проверяет статью, исправляя речевые, орфографические и пунктуационные ошибки. Программное обеспечение – это те программы и инструменты, которыми пользовались участники процесса при создании статьи.

Все вышеописанное – только общая схема работы, поэтому ее нужно детализировать.

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

Так, весь процесс написания статьи можно разделить на 4 этапа:

  1. Подготовить аудиоверсию.
  2. Подготовить текст в печатном виде.
  3. Редактирование и подготовка текста к печати.
  4. Публикация статьи.

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

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

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

Процесс создания нотации IDEF0

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

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

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

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

Стандарт IDEF0 и его требования

О базовых требованиях IDEF0 мы говорили чуть выше.

  1. Главный элемент – в верхнем левом углу.
  2. Каждый элемент должен иметь входящие и исходящие стрелки. Причем входящие стрелки находятся слева, справа – исходящие.
  3. Сверху располагаются управляющие элементы, снизу – механизмы.
  4. При расположении нескольких блоков на одном листе или экране последующие размещаются справа внизу от предыдущего.
  5. Схемы следует создавать так, чтобы стрелки пересекались минимальное количество раз.
Естественно, в стандарте IDEF0 есть общепринятые нормы, требования и обозначения. Подробно на них останавливаться не будем, при желании эту информацию несложно найти.

Ошибки при работе с IDEF0

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

Использование нескольких цветов

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

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

Большое количество блоков

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

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

Изменение структуры при исправлении ошибок

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

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

Название блоков и управляющих элементов

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

Преимущества использования IDEF0

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

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

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

Минимальная вероятность ошибки. Работа по стандарту IDEF0 требует строгого следования его правилам. Это дисциплинирует исполнителя и исключает возможность возникновения ошибки. К тому же любое несоответствие стандарту сразу же становится заметным.

И напоследок

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

На наш взгляд, инструмент IDEF0 будет полезен не только профессиональным бизнес-аналитикам, но и тем, кто непосредственно анализирует свой бизнес и стремится построить эффективную систему управления.

Основной из трех методологий, поддерживаемых BPwin, является IDEF0. IDEF0, относится к семейству IDEF, которое появилось в конце шестидесятых годов под названием SADT (Structured Analysis and Design Technique). IDEF0 может быть использована для моделирования широкого класса систем. Для новых систем применение IDEF0 имеет своей целью определение требований и указание функций для последующей разработки системы, отвечающей поставленным требованиям и реализующей выделенные функции. Применительно к уже существующим системам IDEF0 может быть использована для анализа функций, выполняемых системой и отображения механизмов, посредством которых эти функции выполняются. Результатом применения IDEF0 к некоторой системе является модель этой системы, состоящая из иерархически упорядоченного набора диаграмм, текста документации и словарей, связанных друг с другом с помощью перекрестных ссылок. Двумя наиболее важными компонентами, из которых строятся диаграммы IDEF0, являются бизнес-функции или работы (представленные на диаграммах в виде прямоугольников) и данные и объекты (изображаемые в виде стрелок), связывающие между собой работы. При этом стрелки, в зависимости от того в какую грань прямоугольника работы они входят или из какой грани выходят, делятся на пять видов:

    Стрелки входа (входят в левую грань работы) - изображают данные или объекты, изменяемые в ходе выполнения работы.

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

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

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

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

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

Рисунок 7.1. Функциональный блок и интерфейсные дуги

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

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

После того как контекст описан, проводится построение следующих диаграмм в иерархии. Каждая последующая диаграмма является более подробным описанием (декомпозицией) одной из работ на вышестоящей диаграмме. Пример декомпозиции контекстной работы показан на Рис.7.2 и Рис.7.4. Описание каждой подсистемы проводится аналитиком совместно с экспертом предметной области. Обычно экспертом является человек, отвечающий за эту подсистему и, поэтому, досконально знающий все ее функции. Таким образом, вся система разбивается на подсистемы до нужного уровня детализации, и получается модель, аппроксимирующая систему с заданным уровнем точности. Получив модель, адекватно отображающую текущие бизнес-процессы (так называемую модель AS IS), аналитик с легкостью может увидеть все наиболее уязвимые места системы. После этого, с учетом выявленных недостатков, можно строить модель новой организации бизнес-процессов (модель TO BE).

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

На рисунке 7.2, где приведены три диаграммы и их взаимосвязи, показана структура IDEF0.-модели. Каждый компонент модели может быть декомпозирован на другой диаграмме. Каждая диаграмма иллюстрирует "внутреннее строение" блока на родительской диаграмме.

Рисунок 7.2 - Пример контекстной диаграммы

Как видно на Рис.7.2, BPwin позволяет выделять работы и стрелки разными цветами, а также привязывать имена стрелок к самим стрелкам (стрелка по имени “Отчетность”), что повышает наглядность и читаемость диаграммы.

Рисунок 7.3 - Пример диаграммы декомпозиции

Рисунок 7 . 4 - Пример контекстной диаграммы

Рисунок 7.5 - Пример диаграммы декомпозиции

Иерархия диаграмм

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

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

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

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

Рисунк 7.6 - Структура SADT-модели. Декомпозиция диаграмм

Рисунок 7.7 - Соответствие должно быть полным и непротиворечивым

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

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

Рис. 7.8. Пример механизма

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

Для того, чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок 1 на диаграмме А2. Аналогично, А2 детализирует блок 2 на диаграмме А0, которая является самой верхней диаграммой модели. На рисунке 7.9 показано типичное дерево диаграмм.

Рисунок 7.9 - Иерархия диаграмм

Лекция 8. Методологии DFD и IDEF 3

IDEF0 Diagrams Software - Create IDEF0 diagrams and business diagrams rapidly with rich examples and templates. Provide some IDEF0 knowledge.

IDEF Definition

IDEF is based on the Structured Analysis and Design Technique (SADT), a graphical approach to system description, introduced by Douglas T. Ross in the early 1970s. Since then, system analysts at Softech, Inc. have refined and used SADT in a wide variety of problems. In 1981, the U.S. Air Force Program for Integrated Computer-Aided Manufacturing (ICAM) standardized and made public a subset of SADT, called IDEF.

Was originally used to apply structured methods to better understand how to improve manufacturing productivity. IDEF0 was initially created at Northrop Corporation in 1966, and first available commercially by SofTek in 1972. An IDEF0 activity diagram contains one level of decomposition of a process. Boxes within a diagram show the subprocesses of the parent process named by the diagram. Arrows between the boxes show the flow of products between processes.

Innovative IDEF0 Software

Edraw Max is an easy to use IDEF0 diagrams software, which creates IDEF0 diagrams and business diagrams rapidly with rich examples and templates.

Build hierarchical diagrams using IEDF0 process charting models for model configuration management, need and benefit analyses, requirements definitions, and continuous improvement models.

System Requirements

Works on Windows 7, 8, 10, XP, Vista and Citrix

Works on 32 and 64 bit Windows

Works on Mac OS X 10.2 or later

Software Features

Edraw is:
  1. state of the art
  2. vector-based
  3. more than just IDEF0, IDEF1, IDEF2 Diagrams which can make over 200 kinds of diagrams
  4. easy to use with drag and drop interface, premade symbols and automatic formatting tools
  5. accompanied by a plethora of well-designed templates and examples
  6. designed with broad file format compatibility

IDEF0 diagrams typically include the following components:

Context diagram - The topmost diagram in an IDEF0 model.

Parent/child diagram - An IDEF0 decomposition hierarchy using parent/child relationships.

Node trees - Tree-like structures of nodes rooted at a chosen node, and used to represent a full IDEF0 decomposition in a single diagram.

The Benefits of Using IDEF0 to Model Business Processes

  1. Understanding - modeling helps discover the nature of the business being modeled; that is, what is being done in the business.
  2. Communication - once understanding has been reached, the nature of the business process es can be documented and these documents easily communicated.
  3. Enlightenment - modeling helps to uncover anomalies, redundancies deficiencies and inefficiencies in the existing (as-is) business process.
  4. Improvement - a model allows you to select deficient areas of the business and its processes and improve them.
  5. Redesign - a model provides a tangible basis for redesigning the process, performing simulations of the redesigned (to-be) business process as defined by the strategy. This means that strategies can be tested before implementation takes place.

The IDEF0 Modeling Techniques

An IDEF0 model represents the activities of the business from the point of view of the business, how those business activities interrelate, resources used to conduct each activity, and the result or output of each activity. The model consists of graphics and associated text supporting the graphics.

The IDEF0 modeling technique consists of a graphic language and a modeling process that can be used to develop a rich process description. It is an intuitive way to define, analyze and document the business as a whole and the processes of the business.

Цель работы:

  • изучение основных принципов методологии IDEF0,
  • создание нового проекта в BPWin,
  • формирование контекстной диаграммы,
  • проведение связей.

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

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

Каждая IDEF0-диаграмм а содержит блоки и дуги. Блоки изображают функции моделируемой системы. Дуги связывают блоки вместе и отобра­жают взаимодействия и взаимосвязи между ними.

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

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

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

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

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

Расположение блоков на странице отражает авторское определение доминирования. Таким образом, топология диаграммы показывает, какие функции оказывают большее влияние на остальные. Чтобы подчеркнуть это, аналитик может перенумеровать блоки в соответствии с порядком их доминирования. Порядок доминирования может обозначаться цифрой, размещенной в правом нижнем углу каждого прямоугольника: 1 будет указывать на наибольшее доминирование, 2 - на следующее и т. д.

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

Типы стрелок

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

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

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

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

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

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

Рис. 2.1 Типы стрелок

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

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

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

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

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

Обратная связь по управлению возникает тогда; когда выход некоторого блока влияет на блок с большим доминированием.

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

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

Рис. 2.5. Обратная связь по управлению

Связи «выход-механизм» характерны при распределении источников ресурсов (например, требуемые инструменты, обученный персонал, физическое пространство, оборудование, финансирование, материалы).

В IDEF0 дуга редко изображает один объект. Обычно она символизирует набор объектов. Так как дуги представляют наборы объектов, они могут иметь множество начальных точек (источников) и конечных точек (назначений). Поэтому дуги могут разветвляться и соединяться различными способами. Вся дуга или ее часть может выходить из одного или нескольких блоков и заканчиваться в одном или нескольких блоках.

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

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

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

Рис. 2.6. Связь выход-механизм

  • непомеченные ветви содержат вес объекты, указанные в общей меткедуги после слияния;
  • помеченные перед слиянием ветви содержат все или некоторые объекты из перечисленных в общей метке после слияния,

Количественный анализ диаграмм

Для проведения количественного анализа диаграмм перечислим показатели модели:

  • количество блоков на диаграмме - N;
  • уровень декомпозиции диаграммы - L ;
  • сбалансированность диаграммы - В;
  • число стрелок, соединяющихся с блоком, - А

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

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

Диаграммы должны быть сбалансированы. Это означает, что в рамках одной диаграммы не должно происходить ситуации, изображенной на рис. 2.7: у работы 1 входящих стрелок и стрелок управления значительно больше, чем выходящих. Следует отметить, что данная рекомендация может не выполняться в моделях, описывающих производственные процессы. Например, при описании процедуры сборки в блок может входить множество стрелок, описывающих компоненты изделия, а выходить одна стрелка -- готовое изделие.

Рис. 2.7. Пример несбалансированной диаграммы

Введем коэффициент сбалансированности диаграммы

Необходимо стремиться, чтобы Кь был минимален для диаграммы.

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

После формирования словаря и составления пакета диаграмм системы необходимо рассмотреть нижний уровень модели. Если на нем обнаружатся совпадения названий блоков диаграмм и слов из словаря, то это говорит, что достаточный уровень декомпозиции достигнут. Коэффициент, количественно отражающий данный критерий, можно записать как L*C - произведение уровня модели на число совпадений имен блоков со словами из словаря. Чем ниже уровень модели (больше L), тем ценнее совпадения.

Инструментарий BPWin

При запуске BPWin по умолчанию появляется основная панель инструментов, палитра инструментов и Model Explorer.

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

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

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

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

Пример

Построение модели системы должно начинаться с изучения всех документов, описывающих ее функциональные возможности. Одним из таких документов является техническое задание, а именно разделы "Назначение разработки", "Цели и задачи системы" и "Функциональные характеристики системы " .

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

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

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

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

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

Таким образом, определим контекстную диаграмму системы (рис. 2.9).

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

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

  • Определение уровня доступа в систему.
  • Выбор подсистемы.
  • Обращение к подсистеме.
  • Изменение БД (при необходимости).

Получим диаграмму, изображенную на рис. 2.10.

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

Рис. 2.10. Декомпозиция работы «Обслуживание, клиента системы»

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

Рис. 2.11. Декомпозиция работы «Определение уровня доступав систему»

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

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

  • Открытие БД.
  • Выполнение запроса.
  • Генерация отчетов.

После открытия БД необходимо сообщить системе об установлении соединения с БД, после чего выполнить запрос и сгенерировать отчеты для пользователя (рис. 2.12).

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

Рис. 2.12.

Корректировка диаграммы

При анализе полученной диаграммы возникает вопрос, по каким правилам происходит генерация отчетов? Необходимо наличие заранее сформированных шаблонов, по которым будет производиться выборка из БД, причем эти шаблоны должны соответствовать запросам и должны быть заранее определены. Кроме того, клиенту должна быть предоставлена возможность выбора формы отчета.

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

Изменение диаграммы потянет за собой корректировку всех родительских диаграмм (рис. 2.13 - 2.15).

Декомпозицию работы «Выполнение запроса» целесообразно провести при помощи диаграммы DFD (лабораторная работа № 3), так как методология IDEF0 рассматривает систему как совокупность взаимосвязанных работ, что плохо отражает процессы обработки информации.

Рис. 2.13. Декомпозиция работы «Обработка запроса клиента»

Рис. 2.14. Декомпозиция работы «Обслуживание клиента системы»(вариант 2)

Рис. 2.15. Контекстная диаграмма системы (вариант 2)

Перейдем к декомпозиции последнего блока «Изменение БД». С точки зрения клиента, данные системы располагаются в одной БД. Реально в системе присутствует шесть БД:

  • БД пользователей,
  • БД студентов,(вариант 2)
  • БД вакансий,
  • БД успеваемости,
  • БД тестов,
  • БД экспертных оценок,
  • БД резюме.

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

  • Определяется БД, в которой будет изменяться информация.
  • Оператором формируется временный набор данных и предоставляется администратору.
  • Администратор осуществляет контроль данных и вносит их в БД.

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

Рис. 2.16. Декомпозиция работы «Изменение БД»

Рис. 2.17. Декомпозиция работы «Изменение БД» (вариант 2) Для первого варианта, изображенного нарис. 2.12

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

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

Проведем количественный анализ моделей, изображенных на рис. 2.12 и 2.13, согласно вышеописанной методике. Рассмотрим поведение коэффициента ^ у этих моделей. У родительской диаграммы «Обработка запроса клиента» коэффициент равен 4/2 = 2, а диаграммы декомпозиции 3/3 = 1. Значение коэффициента убывает, что говорит об упрощении описания функций с понижением уровня модели.

Рассмотрим изменение коэффициента К b у двух вариантов моделей.

для второго варианта

Коэффициент К b не меняет своего значения, следовательно, сбалансированность диаграммы не меняется.

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

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

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

Список Контрольных вопросов :

  1. Что представляет собой модель в нотации IDEF0?
  2. Что обозначают работы в IDEF0?
  3. Назовите порядок наименования работ?
  4. Какое количество работ должно присутствовать на одной диаграмме?
  5. Что называется порядком доминирования?
  6. Как располагаются работы по принципу доминирования?
  7. Каково назначение сторон прямоугольников работ на диаграммах?
  8. Перечислите типы стрелок.
  9. Назовите виды взаимосвязей.
  10. Что называется граничными стрелками?
  11. Объясните принцип именования разветвляющихся и сливающихся стрелок.
  12. Какие методологии поддерживаются BPWin?
  13. Перечислите основные элементы главного окна BPWin.
  14. Опишите процесс создания новой модели в BPWin.
  15. Как провести связь между работами?
  16. Как задать имя работы.
  17. Опишите процесс декомпозиции работы.
  18. Как добавить работу на диаграмму?
  19. Как разрешить туннелированные стрелки?
  20. Может ли модель BPWin содержать диаграммы нескольких методологий?