Методические рекомендации по выполнению лабораторных работ по курсу «Управление процессами» для студентов специальности 220501. 65 «Управление качеством» (стр. 3 из 10)
1.2.4 Туннели
Понятие «связанные стрелки» используется для управления уровнем детализации диаграмм. Если одна из стрелок диаграммы отсутствует на родительской диаграмме (например, ввиду своей несущественности для родительского уровня) и не связана с другими стрелками той же диаграммы, точка входа этой стрелки на диаграмму или выхода с нее обозначается туннелем, помещается в круглые скобки. На рисунке 9, например, стрелка «корпоративная информационная система» - важный механизм исполнения для данной диаграммы, но, возможно, она более нигде не используется в модели. Туннель в данном случае используется как альтернатива загромождению родительских диаграмм помещением на них несущественных для их уровня стрелок.
Рисунок 9 – Пример применения туннеля
Кроме того, туннели применяются для отражения ситуации, когда стрелка, присутствующая на родительской диаграмме, отсутствует в диаграмме декомпозиции соответствующего блока. На рисунке 10 туннель у стрелки «модуль производственного отдела» обозначает, что на диаграмме декомпозиции производственного отдела отсутствует стрелка механизма управления с соответствующим наименованием.
Рисунок 10 – Пример применения туннеля
1.3 Построение моделей IDEF0
1.3.1 Диаграммы
На рисунке 11 типовая диаграмма IDEF0 показана вместе с находящейся на ее полях служебной информацией. Служебная информация состоит из хорошо выделенных верхнего и нижнего колонтитулов.
Рисунок 11 – IDEF0-диаграмма со служебной информацией на полях
Элементы верхнего колонтитула используются для отслеживания процесса создания модели. Элементы нижнего отображают наименование модели, к которой относится диаграмма, и показывают ее расположение относительно других диаграмм модели. Все элементы диаграммы перечислены в таблице 1.
Таблица 1 – Элементы диаграммы IDEF0
| Поле | Назначение |
| 1 | 2 |
| USED AT | Используется для отражения внешних ссылок на данную диаграмму (заполняется на печатном документе вручную) |
Продолжение таблицы 1
| 1 | 2 |
| Author, date, Project | Содержит фамилию и инициалы автора диаграммы, дату создания, дату последнего внесения изменений, наименование проекта, в рамках которого она создавалась |
| Notes 1...10 | При ручном редактировании диаграмм пользователи могут зачеркивать цифру каждый раз, когда они вносят очередное исправление |
| Status | Статус отражает состояние разработки или утверждения данной диаграммы. Это поле используется для реализации формального процесса публикации с шагами пересмотра и утверждения |
| Working | Новая диаграмма, глобальные изменения или новый автор для существующей диаграммы |
| Draft | Диаграмма достигла некоторого приемлемого для читателей уровня и готова для представления на утверждение |
| Recommended | Диаграмма одобрена и утверждена. Какие-либо изменения не предвидятся |
| Publication | Диаграмма готова для окончательной печати и публикации |
| Reader | Фамилия и инициалы читателя |
| Date | Дата знакомства читателя с диаграммой |
| Node | Номер диаграммы, совпадающий с номером родительского функционального блока |
| Title | Имя родительского функционального блока |
| C Number | Уникальный идентификатор данной версии данной диаграммы. Таким образом, каждая новая версия данной диаграммы будет иметь новое значение в этом поле |
1.3.2 Построение моделей
Ни одна модель не должна строиться без ясного осознания объекта и целей моделирования. Выбранное определение цели моделирования должно отвечать на следующие вопросы:
– Почему моделируется данный процесс?
– Что выявит данная модель?
– Как ознакомившиеся с этой моделью смогут ее применить?
Сформулированная цель моделирования содержит вопросы, на которые должна отвечать модель. Когда становится возможным получение ответов на них с помощью модели, модель считается удовлетворяющей поставленным требованиям и рассматривается как завершенная. При построении декомпозиции первого уровня нужно следить за тем, чтобы все блоки на диаграмме лежали внутри определенных ранее границ моделирования. Перед декомпозированием блока нужно удостовериться, не приведет ли это к превышению установленной ранее глубины детализации для данной модели.
При необходимости дальнейшей детализации отдельных процессов могут быть использованы диаграммы IDEF3, DFD.
Точка зрения. С методической точки зрения при моделировании полезно использовать мнение экспертов, имеющих разные взгляды на предметную область, однако каждая отдельно взятая модель должна разрабатываться исходя из единственной заранее определенной точки зрения. Часто другие точки зрения вкратце документируются в прикрепленных диаграммах FEO (презентационные диаграммы, см. далее) исключительно для наглядности изложения.
Точку зрения нужно подбирать достаточно аккуратно, основой для выбора должна служить поставленная цель моделирования. Наименованием точки зрения может быть наименование должности, подразделения или роли (например, руководитель отдела или менеджер по продажам). Как и в случае с определением цели моделирования, четкое определение точки зрения необходимо для обеспечения внутренней целостности модели и предотвращения постоянного изменения ее структуры. Может оказаться необходимым построение моделей с разных точек зрения для детального отражения всех особенностей выделенных в системе функциональных блоков.
Границы моделирования. Одним из положительных результатов построения функциональных моделей оказывается прояснение границ моделирования системы в целом и ее основных компонентов. Как и при определении цели моделирования, отсутствие границ затрудняет оценку степени завершенности модели, поскольку границы моделирования имеют тенденцию к расширению с ростом размеров модели.
Границы моделирования имеют два компонента: ширину охвата и глубину детализации. Ширина охвата обозначает внешние границы моделируемой системы. Глубина детализации определяет степень подробности, с которой нужно проводить декомпозицию функциональных блоков.
Чтобы облегчить правильное определение границ моделирования при разработке моделей IDEF0, существенные усилия затрачиваются на разработку и рецензирование контекстной диаграммы IDEF0 (диаграммы «самого верхнего» уровня). Иногда даже прибегают к построению дополнительной диаграммы для отображения уровня, более высокого, чем контекстный, для данной модели, что позволяет обозначить систему, внутри которой располагается объект для моделирования.
Выбор наименования контекстного блока. Рекомендуемой последовательностью действий при построении модели «с нуля» являются: формулирование цели моделирования, выбор точки зрения, определение границ моделирования, наименование контекстного блока – функционального блока самого высокого уровня. Правила подбора имени для контекстного блока в целом не отличаются от общих правил наименования функциональных блоков, поэтому для них обычно подбирают обобщающие названия типа «Управление отделом по работе с клиентами», «Обработка заказов» и т.п.
Определение стрелок на контекстной диаграмме. Стрелки диаграмм IDEF0 обычно проще проектировать в следующем порядке: выход, вход, механизм исполнения, управление.
Определение выходов. После идентификации возможных выходов полезно провести анализ модели на предмет покрытия ею всех возможных сценариев поведения процесса. Это означает, что если существует вероятность возникновения той или иной ситуации в ходе процесса, модель отражает возможность возникновения такой ситуации. Иногда забывают отразить негативные результаты работы функциональных блоков, которые часто используются в качестве обратных связей.
Определение входов. Входы можно рассматривать как особым образом преобразуемые функциональными блоками для производства выхода сырье или информацию. В производственных отраслях определить, как входное сырье преобразуется в готовую продукцию, обычно довольно просто. Однако при моделировании информационных потоков входной поток данных может представляться не потребляемым и не обрабатываемым вообще. Случаи, когда входящие и исходящие стрелки называются в точности одинаково, крайне редки и, в основном, указывают на бесполезность данного блока для системы в целом или на некорректный выбор имени для исходящей стрелки. Решением может служить применение более подробного описания для входящих и исходящих потоков данных.
Определение механизмов исполнения. После создания входов и выходов можно приступить к рассмотрению механизмов исполнения, или ресурсов, относящихся к функциональному блоку. В понятие механизма исполнения входят персонал, оборудование, информационные системы и т.п. Как правило, определить механизмы исполнения для функциональных блоков довольно просто.