Задания - 2022-09-04T123935.331. Занятие Структурирование действий процесса Тема Сущность процессного подхода. Алгоритм построения регламентированных процедур (п. 1 5) Задание 1
 Скачать 3.85 Mb.
|
Бланк выполнения практического задания 1Таблица 1.1 (указывается наименование процедуры согласно варианту задания)
Таблица 1.2 Общие сведения о процессе
Практическое занятие 2. Алгоритм описания процессаТема 1. Сущность процессного подхода. Алгоритм построения регламентированных процедур (п. 1.6–1.9) Задание 2 Отработать практические навыки построения алгоритма описания процесса. Нормативные документы 1. ГОСТ Р ИСО 9000-2015. СИСТЕМЫ МЕНЕДЖМЕНТА КАЧЕСТВА. Основные положения и словарь. 2. ГОСТ Р ИСО 9001-2015. СИСТЕМЫ МЕНЕДЖМЕНТА КАЧЕСТВА. Требования. 3. ПРОЦЕССНЫЙ ПОДХОД В ISO 9001-2015. 4. ISO TC 176SC 2N 544R2(r), май 2004. Руководство по концепции и использованию процессного подхода для систем менеджмента. 5. Р 50.1.028-2001. Методология функционального моделирования. 6. Р 50-601-46-2004. Рекомендации. Методика менеджмента процессов в системе качества. 7. РД IDEF 0-2000. Методология функционального моделирования IDEF0. Руководящий документ. Алгоритм выполнения практического задания 2 1. Изучить нормативные документы и теоретический материал, представленный ниже. 2. Выбранный процесс (из практического задания 1) описать в табличной форме, заполнив таблицу 2.2 в бланке выполнения задания 2. 3. Построить диаграмму выбранного процесса (из практического задания 1), согласно приведенной в бланке схеме (форма 1). Образцы способов моделирования процессов представлены в приложении Б и приложении В. Теоретический материал 2. Структура действий процесса, алгоритм построения процедуры 2.1. Структурирование процессов Схематичное изображение любого процесса и взаимосвязь элементов процесса показаны на рис. 2.1. Контрольные точки мониторинга и измерения, необходимые для управления, являются специфическими для каждого процесса и варьируются в зависимости от соответствующих рисков. Согласно рекомендации Р50-601-46-2004, выбирая поочередно для анализа какой-либо процесс, необходимо сначала рассмотреть этот процесс на макроуровне, чтобы было удобно проследить его взаимосвязь с другими процессами системы или заинтересованными сторонами, а далее осуществлять его структурирование (декомпозицию) до уровня, определяемого поставленной задачей, имеющимися в процессе проблемами, неясностями и т. п. Например, определяя участие подразделений в процессе закупок, следует детализировать весь процесс до уровня, на котором проявится их взаимодействие. Это будет первый уровень декомпозиции. Если же в какой-то части процесса возникла проблема, то эту часть необходимо детализировать до уровня, на котором будет видна причина проблемы, вплоть до отдельных операций конкретного исполнителя. Условное изображение декомпозиции процессов по уровням анализа приведено на рис. 2.2. В первую очередь и наиболее глубоко и подробно целесообразно проанализировать ключевые процессы, имеющие максимальное влияние на результаты деятельности организации. В менеджменте нет необходимости детализировать каждый процесс до элементарного уровня (в отличие, например, от задач автоматизации процесса). Критериями необходимости детализации описания и анализа процесса могут быть наличие проблемы в процессе, частые сбои в работе процесса, его низкая результативность; высокий риск возникновения ошибок в процессе; необходимость определить роль участников процесса.  Рис. 2.1. Схематичное изображение элементов процесса  Рис. 2.2. Структурирование (декомпозиция) процессов Документация, определяющая процесс, может быть оформлена в любом виде: текстовое описание, программа обучения, схематическое изображение процесса. Она может быть представлена на любом носителе и иметь вид бумажного или электронного документа, видеофильма, мультимедийного диска. Часто планирование процесса документируют в виде плана качества или плана управления. 2.2. Методы схематического изображения (структурного моделирования) процесса Схематическое изображение помогает определить процесс и в лаконичной форме представить его как в целом, так и по основным составляющим и параметрам. Особую роль схематическое изображение процесса играет: при анализе процесса (этап «планирование» цикла PDCA); обсуждении процесса группой специалистов, когда должен быть выработан единый взгляд на него; стандартизации процесса или внесении изменений в существующий процесс (этап «воздействие» цикла PDCA). Существует большое количество методов схематического изображения процесса. Каждый из них имеет свои преимущества и недостатки, обусловленные сферой распространения того или иного метода и его направленностью. Наиболее популярными стали следующие методы: блок-схема (Block-Diagram); диаграмма последовательности (алгоритм, Flow Chart); диаграмма процессов (DFD, IDEF0); методология ARIS; методология BPMN; карта процесса (Process Map); сетевой график (Activity Network Diagram); процессно-функциональная диаграмма (Process / function Diagram); диаграмма процесса принятия решения (Process Decision Program Chart); объектно-событийное описание. Перечисленные методы выделены из огромного количества методов моделирования процессов. Наряду с ними можно назвать большую группу методов моделирования систем (информационных, финансовых, механических и др.). Например, распространение в последнее время получили UML-модели (Unified Modeling Language) для моделирования и анализа сложных информационных систем. 2.3. Построение диаграммы последовательности (алгоритма) процесса Одним из эффективных и часто применяемых приемов анализа является построение схематического изображения составляющих этапов процесса с помощью определенных графических символов. Существует много систем графических символов, большая часть которых создана для процессов обработки информации. С помощью таких символов можно изобразить последовательность этапов процесса, как это показано на рис. 2.3. Для построения такого алгоритма с помощью компьютера удобно использовать программные продукты, например графический редактор VISIO. Подобный алгоритм удобно использовать для построения карты процесса.  Рис. 2.3. Возможный вариант алгоритма процесса Построенный алгоритм (диаграмму последовательности действий) можно использовать для дальнейшего анализа и планирования процесса. Приведем примеры использования алгоритма для решения задач выявления проблем и поиска их решений. Диаграмма (блок-схема) процесса выполнения программы Диаграмма процесса выполнения программы – это графическое представление логической последовательности действий при решении конкретной задачи. Диаграмма процесса выполнения аналогична блок-схемам алгоритмов компьютерных программ и применяется для анализа сроков и целесообразности проведения работ, представленных на стрелочной диаграмме. Блок-схема – это графическое отображение процесса, которое четко показывает нам, как протекает процесс. Блок-схема показывает систематическую последовательность этапов выполнения работы и то, какие группы вовлечены в процесс. Блок-схемы используются, чтобы: документировать и описывать текущий процесс; разрабатывать модификации к текущему процессу или прогнозировать возможное возникновение проблемы; разрабатывать совершенно новый процесс; измерять текущий процесс, чтобы убедиться, соответствует ли он устойчивым требованиям. Диаграмму процесса выполнения программы также называют диаграммой последовательности (flow chart). Она является одним из самых распространенных методов в области менеджмента качества. Суть метода – графическое изображение последовательности действий рассматриваемого процесса с использованием нехитрых символов (овал, прямоугольник, стрелка). Составление и анализ диаграммы PDPC (PDPC – Process Decision Program Chart) позволяет прогнозировать различные результаты запланированных действий, в том числе и нежелательные ситуации. Это дает возможность заранее провести соответствующие корректировки, а также предусмотреть различные варианты развития событий. Наиболее эффективна при разработке новых направлений развития кампании, при планировании крупных заказов, составлении перспективных программ и т. п. Пример диаграммы процесса выполнения программы приведен на рис. 2.4. Варианты реализаций (нотаций) построения диаграммы (блок-схемы) процесса выполнения программы Согласно ГОСТ 19.701-90 (ИСО 5807-85), блок-схема представляет собой графическое описание потока действий в бизнес-процессе. Ценность блок-схемы заключается в том, что обычно гораздо проще понять что-либо, рассматривая графическое представление объекта, чем изучая его словесное описание: лучше один раз увидеть, чем сто раз услышать.  Рис. 2.4. Пример диаграммы процесса Существует много способов графического представления блок-схем. Самый распространенный – использование различных символов для обозначения различных действии. Стрелки нужны для обозначения связей между различными действиями. Если говорить о самих символах, то и для их изображения есть много вариантов: от сложных рисунков до элементарных прямоугольников и линии. Важно общее понимание смысла символов блок-схемы пользователем. На рис. 2.5 показаны наиболее часто встречающиеся символы блок-схем.  Рис. 2.5. Символы блок-схем В дополнение к самому символу блок-схемы в нем можно сделать надпись, чтобы указать требуемые ресурсы или оборудование, или определить условия, в которых выполняется рассматриваемое действие. Блок-схема процесса поставки приведена на рис. 2.6. На рис. 2.7 показано, как из обычной блок-схемы, представленной на рис. 2.6, с помощью добавления некоторых деталей можно получить межфункциональную блок-схему. Добавление указанной информации не требует много времени в отличие от работ по определению всей последовательности действий. Однако составление такой схемы делает процесс гораздо более наглядным и облегчает понимание его хода. Общая рекомендация заключается в использовании именно межфункциональной блок-схемы. Как правило, работа по составлению такой блок-схемы существенно облегчается, если в качестве базы использовать обычную блок-схему.  Рис. 2.6. Блок-схема процесса поставки На межфункциональной блок-схеме тоже можно указывать дополнительную информацию. Эта информация располагается либо вдоль вертикальной оси, если использован книжный формат листа, либо вдоль горизонтальной оси, если использован альбомный формат листа. Такой дополнительной информацией служит, например: текущее время процесса; затраты на текущий момент времени; добавленная ценность; степень завершенности. Таким образом, построение межфункциональной блок-схемы может дать гораздо больше информации, чем просто определение последовательности действий процесса. Добавление все новой и новой информации, особенно для сложного процесса, может привести к затруднению восприятия схемы, по крайней мере на первый взгляд. Выход – в построении так называемой многоуровневой блок-схемы.  Рис. 2.7. Пример межфункциональной блок-схемы Рассмотрим еще один вариант нотаций представления блок-схем. Он включает две блок-схемы (общая схема процесса и детальная схема процесса), для каждой схемы существует своя система обозначения и правила ее построения. Общая схема процесса предназначена для представления основных концепций административного процесса. Схема не подходит для воспроизведения информационных потоков, однако может использоваться в качестве основы для описания частей (подпроцессов), которые составляют административный бизнес-процесс. Свойства. Общая схема процесса воспроизводит основную модель отношений между различными частями административного бизнес-процесса. Общая схема процесса особенно хорошо проявляет себя, когда части могут быть представлены в определенной последовательности. Если полностью отсутствует последовательная упорядоченность, тогда отношения различных частей могут быть лучше изображены схематически при использовании иерархического обзора или общего обзора. В принципе, позиции задачи для каждой организационной единицы представлены без углубления в детали. Отделы: Филиал компании. Главный офис. Учета затрат. Финансовых вопросов. Представитель. Процесс – учет затрат. На рис. 2.8 представлен способ управления издержками в произвольном филиале организации. Каждый раздел схемы обозначает часть операций в рамках отдела. Для каждого раздела приведено короткое пояснение. Разделам присваиваются три номера, которые отражают соответственно код отдела, код административного бизнес-процесса и порядковый номер. При помощи кода можно классифицировать базовые детальные описания как отделов, так и процессов. Эти детальные описания для каждого раздела будут, в зависимости от цели документирования, отличаться схемами движения форм.  5.1.1.  Рис. 2.8. Общая схема процесса управления выплатами Схема представлена последовательностью действий: получение счета на приобретение материальных ценностей в филиале; разрешение и кодирование; контроль счета, запись; создание платежного поручения; контроль кодов; контроль счета и платежного поручения; доверенность; запись в реестре; разделить на два отдельных потока обработки: • дальнейшая обработка платежей и обработка счетов, на сумму более $25000, а также счетов с периодическими и срочными платежами; • дальнейшая обработка других счетов. Естественно, количество факторов, которые могут быть представлены при помощи общей схемы процесса, ограничено: могут быть представлены основные принципы, последовательность и отношения действий, а также вовлеченные отделы и сотрудники. Общая схема процесса принадлежит к категории свободных схем. Для нее не существует обязательных правил в отношении размещения, методики, разработки, использования символов и т. д. Для того чтобы схема сохраняла ясность и хорошую организацию, рекомендуем использовать как можно меньше символов. В этой схеме не требуется детальных описаний. Таблица 2
На практике обычно оказывается достаточно символов, приведенных в таблице 2. Разделы (и базовые описания) также свободно номеруются. Следует стремиться к тому, чтобы код указывал на административный бизнес-процесс, на последовательность разделов и на отдел. Детальная схема процесса обеспечивает понимание последовательности мероприятий/действий и документопотока административного бизнес-процесса. Схема процесса, или блок-схема, особенно подходит для достижения понимания и проведения анализа административных бизнес-процессов. Свойства. Детальная схема процесса показывает последовательность мероприятий/действий административного бизнес-процесса. Для каждого мероприятия/действия указаны имеющие значение документы или файлы, однако содержание схемы все же определяется последовательностью мероприятий/действий. Также может быть указан отдел (или сотрудник), выполняющий мероприятия/действия. Часто даже возможно нарисовать индивидуальную схему процесса в рамках административной системы таким образом, чтобы схемы отражали мероприятия/действия, приходящиеся на отдел. Однако, как только это оказывается невозможным (например из-за большого количества контактов или сильного документопотока между отделами), необходимо провести общий обзор процессов и отделов для того, чтобы разобраться в каждом процессе отдельно для каждого отдела. Хорошим шагом на пути к построению обзора всех индивидуальных детальных схем процесса может стать составление общего обзора. В этом случае каждый символ или раздел в общей схеме процесса должен соответствовать символу или разделу в детальной схеме процесса. В наиболее часто применяемых формах может быть представлено ограниченное число факторов. Последовательность мероприятий/действий и соответствующие источники данных могут быть наглядно представлены в схемах процесса. Другие факторы, играющие определенную роль в рассматриваемом административном бизнес-процессе, должны быть задокументированы отдельно. Среди этих факторов можно назвать количество, финансовую значимость, периодичность, элементы времени и т. д.   Рис. 2.9. Пример детальной схемы процесса ИСО разработала международный стандарт символов, используемых при составлении блок-схем, которые мы также называем детальными схемами процессов, – ГОСТ 19.701-90 (ИСО 5807-85). Таблица 3
Этот стандарт отмечает, что концепция блок-схем также включает так называемые блок-схемы системы, блок-схемы программы, функциональные блок-схемы и блок-схемы конфигурации. Символы различаются в зависимости от типа и в соответствии с требованиями мероприятий/действий, информации, логического решения или связи между символами или инструментами, для изображения которых они используются (таблица 3). В качестве обшей рекомендации: схемы должны составляться таким образом, чтобы их можно было читать слева направо и сверху вниз. Прежде всего, для уточнения степени и последовательности участия подразделений и должностных лиц в процессе целесообразно построить его алгоритм, распределив этапы процесса по его участникам, как это показано на рис. 2.10. Такое наглядное изображение поможет наиболее рационально распределить ответственность и последовательность действий участников процесса и за счет этого сократить время его выполнения и снизить издержки.  Рис. 2.10. Пример алгоритма процесса с распределением действий по исполнителям (алгоритм процесса рентгеновского обследования) Один из наиболее распространенных вариантов – представление процессов в виде Flow-Chart диаграмм. Пример такого описания процесса приведен на рис. 2.11.  Рис. 2.11. Пример диаграммы одного из процессов СМК (Процесс корректирующих действий) Также можно построить диаграмму выбранного процесса по форме, приведенной ниже (рис. 2.12). Диаграмма процесса (указывается наименование процесса)
 Рис. 2.12. Форма диаграммы процесса 2.4. Методология IDEF0 и ее применение для регламентирования процесса Согласно РД IDEF 0-2000, основу подхода и, как следствие, методологии IDEF0, составляет графический язык описания (моделирования) систем, обладающий следующими свойствами (Методология IDEF0 основана на подходе, разработанном Дугласом Т. Россом в начале 70-х годов и получившем название SADT (Structured Analysis & Design Technique – метод структурного анализа и проектирования)): графический язык – полное и выразительное средство, способное наглядно представлять широкий спектр деловых, производственных и других процессов и операций предприятия на любом уровне детализации; язык обеспечивает точное и лаконичное описание моделируемых объектов, удобство использования и интерпретации этого описания; язык облегчает взаимодействие и взаимопонимание системных аналитиков, разработчиков и персонала изучаемого объекта (фирмы, предприятия), т. е. служит средством «информационного общения» большого числа специалистов и рабочих групп, занятых в одном проекте, в процессе обсуждения, рецензирования, критики и утверждения результатов; язык прошел многолетнюю проверку и продемонстрировал работоспособность как в проектах ВВС США, так и в других проектах, выполнявшихся государственными и частными промышленными компаниями; язык легок и прост в изучении и освоении; язык может генерироваться рядом инструментальных средств машинной графики. Известны коммерческие программные продукты, поддерживающие разработку и анализ моделей – диаграмм IDEF0. Перечисленные свойства языка предопределили выбор методологии IDEF0 в качестве базового средства анализа и синтеза производственно-технических и организационно-экономических систем Блочное моделирование и его графическое представление. Основной концептуальный принцип методологии IDEF – представление любой изучаемой системы в виде набора взаимодействующих и взаимосвязанных блоков, отображающих процессы, операции, действия (определения см. ниже), происходящие в изучаемой системе. В IDEF0 все, что происходит в системе и ее элементах, принято называть функциями. Каждой функции ставится в соответствие блок. На IDEF0-диаграмме, основном документе при анализе и проектировании систем, блок представляет собой прямоугольник. Интерфейсы, посредством которых блок взаимодействует с другими блоками или с внешней по отношению к моделируемой системе средой, представляются стрелками, входящими в блок или выходящими из него. Входящие стрелки показывают, какие условия должны быть одновременно выполнены, чтобы функция, описываемая блоком, осуществилась. Синтаксис графического языка IDEF0 Набор структурных компонентов языка, их характеристики и правила, определяющие связи между компонентами, представляют собой синтаксис языка. Компоненты синтаксиса IDEF0 – блоки, стрелки, диаграммы и правила. Блоки представляют функции, определяемые как деятельность, процесс, операция, действие или преобразование (см. ниже). Стрелки представляют данные или материальные объекты, связанные с функциями. Правила определяют, как следует применять компоненты; диаграммы обеспечивают формат графического и словесного описания моделей. Формат образует основу для управления конфигурацией модели. Блок описывает функцию. Типичный блок показан на рис. 2.13. Внутри каждого блока помещается его имя и номер. Имя должно быть активным глаголом или глагольным оборотом, описывающим функцию. Номер блока размещается в правом нижнем углу. Номера блоков используются для их идентификации на диаграмме и в соответствующем тексте.  Рис. 2.13. Типичный блок IDEF0 Размеры блоков должны быть достаточными для того, чтобы включить имя блока. Блоки должны быть прямоугольными, с прямыми углами. Блоки должны быть нарисованы сплошными линиями. Стрелка формируется из одного или более отрезков прямых и наконечника на одном конце. Как показано на рис. 2.14, сегменты стрелок могут быть прямыми или ломаными. В последнем случае горизонтальные и вертикальные отрезки стрелки сопрягаются дугами, имеющими угол 90о. Стрелки не представляют поток или последовательность событий, как в традиционных блок-схемах потоков или процессов. Они лишь показывают, какие данные или материальные объекты должны поступить на вход функции для того, чтобы эта функция могла выполняться.  Рис. 2.14. Синтаксис стрелок Синтаксис стрелок 1. Ломаные стрелки изменяют направление только под углом 90 град. 2. Стрелки должны быть нарисованы сплошными линиями различной толщины. 3. Стрелки могут состоять только из вертикальных или горизонтальных отрезков; отрезки, направленные по диагонали, не допускаются. 4. Концы стрелок должны касаться внешней границы функционального блока, но не должны пересекать ее. 5. Стрелки должны присоединяться к блоку на его сторонах. Присоединение в углах не допускается. Поскольку IDEF0 есть методология функционального моделирования, имя блока, описывающее функцию, должно быть глаголом или глагольным оборотом. Например, имя блока «Выполнить проверку» означает, что блок с таким именем превращает непроверенные детали в проверенные. После присваивания блоку имени к соответствующим его сторонам присоединяются входные, выходные и управляющие стрелки, а также стрелки механизма. Чтобы гарантировать точность модели, следует использовать стандартную терминологию. Блоки именуются глаголами или глагольными оборотами, и эти имена сохраняются при декомпозиции. Стрелки и их сегменты, как отдельные, так и связанные в «пучок», помечаются существительными или оборотами существительного. Стрелки, входящие в левую сторону блока, – входы. Входы преобразуются или расходуются функцией, чтобы создать то, что появится на ее выходе. Стрелки, входящие в блок сверху, – управления. Управления определяют условия, необходимые функции, чтобы произвести правильный выход. Стрелки, покидающие блок справа, – выходы, т. е. данные или материальные объекты, произведенные функцией. Стрелки, подключенные к нижней стороне блока, представляют механизмы. Стрелки, направленные вверх, идентифицируют средства, поддерживающие выполнение функции. Стандартное расположение стрелок показано на рис. 2.15.  Рис. 2.15. Стандартное расположение стрелок Имена и метки. Как указывалось, имена функций – глаголы или глагольные обороты. Примеры таких имен: «Производить детали»; «Планировать ресурсы»; «Наблюдать за выполнением»; «Проектировать систему»; «Эксплуатировать»; «Разработать детальные чертежи»; «Изготовить компонент»; «Проверять деталь». Стрелки идентифицируют данные или материальные объекты, необходимые для выполнения функции или производимые ею. Каждая стрелка должна быть помечена существительным или оборотом существительного, например: «Спецификации»; «Отчет об испытаниях»; «Бюджет»; «Конструкторские требования»; «Конструкция детали»; «Директива»; «Инженер-конструктор»; «Плата в сборе»; «Требования». Пример размещения меток стрелок и имени блока показан на рис. 2.16.  Рис. 2.16. Пример размещения меток стрелок и имени блока Диаграммы IDEF0 Графическая диаграмма – главный компонент IDEF0-модели, содержащий блоки, стрелки, соединения блоков и стрелок и ассоциированные с ними отношения. Блоки представляют основные функции моделируемого объекта. Эти функции могут быть разбиты (декомпозированы) на составные части и представлены в виде более подробных диаграмм. Процесс декомпозиции продолжается до тех пор, пока объект не будет описан на уровне детализации, необходимом для достижения целей конкретного проекта. Диаграмма верхнего уровня обеспечивает наиболее общее, или абстрактное, описание объекта моделирования. За этой диаграммой следует серия дочерних диаграмм, дающих более детальное представление об объекте. Контекстная диаграмма верхнего уровня Каждая модель должна иметь контекстную диаграмму верхнего уровня, на которой объект моделирования представлен единственным блоком с граничными стрелками. Эта диаграмма называется A – 0 (А минус ноль). Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой. Поскольку единственный блок представляет весь объект, его имя – общее для всего проекта. Это же справедливо и для всех стрелок диаграммы, поскольку они представляют полный комплект внешних интерфейсов объекта. Диаграмма A – 0 устанавливает область моделирования и ее границу. Пример диаграммы A – 0 показан на рис. 2.17.  Рис. 2.17. Пример диаграммы A – 0 Схематическое изображение связей преобразующего блока в соответствии с соглашениями системы IDEF0 показано на рис. 2.18, 2.19. Дочерняя диаграмма Единственная функция, представленная на контекстной диаграмме верхнего уровня, может быть разложена на основные подфункции посредством создания дочерней диаграммы. В свою очередь, каждая из этих подфункций может быть разложена на составные части посредством создания дочерней диаграммы следующего, более низкого уровня, на которой некоторые или все функции также могут быть разложены на составные части. Каждая дочерняя диаграмма содержит дочерние блоки и стрелки, обеспечивающие дополнительную детализацию родительского блока.  Рис. 2.18. Схематическое изображение связей преобразующего блока  Рис. 2.19. Пример диаграммы для процесса производства Дочерняя диаграмма, создаваемая при декомпозиции, охватывает ту же область, что и родительский блок, но описывает ее более подробно. Таким образом, дочерняя диаграмма как бы вложена в свой родительский блок. Эта структура иллюстрируется рис. 2.20. Стрелки на диаграмме IDEF0, представляя данные или материальные объекты, одновременно задают своего рода ограничения (условия). Входные и управляющие стрелки блока, соединяющие его с другими блоками или с внешней средой, по сути описывают условия, которые должны быть выполнены для того, чтобы реализовалась функция, записанная в качестве имени блока.  Рис. 2.20. Основное иерархическое отношение между родительским блоком и дочерней диаграммой  Рис. 2.21. «Функция 3» может быть выполнена только после получения данных, выработанных «функцией 1» и «функцией 2» Рис. 2.21 иллюстрирует случай, при котором «функция 3» может быть выполнена только после получения данных, выработанных «функцией 1» и «функцией 2». Ветвление и слияние стрелок призвано уменьшить загруженность диаграмм графическими элементами (линиями). Непомеченные сегменты (рис. 2.22) содержат все объекты, указанные в метке стрелки перед ветвлением (т. е. все объекты принадлежат каждому из сегментов).  Рис. 2.22. Ветвление стрелок Отношения блоков на диаграммах В методологии IDEF0 существует 6 (шесть) типов отношений между блоками в пределах одной диаграммы: доминирование; управление; выход-вход; обратная связь по управлению; обратная связь по входу; выход – механизм. Первое из перечисленных отношений определяется взаимным расположением блоков на диаграмме. Предполагается, что блоки, расположенные на диаграмме выше и левее, «доминируют» над блоками, расположенными ниже и правее. «Доминирование» понимается как влияние, которое один блок оказывает на другие блоки диаграммы. Остальные пять отношений описывают связи между блоками и изображаются соответствующими стрелками. ICOM-кодирование граничных стрелок ICOM-коды связывают граничные стрелки на дочерней диаграмме со стрелками родительского блока. Нотация, названная ICOM-кодом, определяет значения соединений. Буквы I, C, O или M, написанные около несвязанного конца граничной стрелки на дочерней диаграмме, идентифицируют стрелку как Вход (Input), Управление (Control), Выход (Output) или Механизм (Mechanism) в родительском блоке. Правила построения диаграмм 1. В составе модели должна присутствовать контекстная диаграмма A – 0, которая содержит только один блок. Номер единственного блока на контекстной диаграмме A – 0 должен быть 0. 2. Блоки на диаграмме должны располагаться по диагонали – от левого верхнего угла диаграммы до правого нижнего в порядке присвоенных номеров. Блоки на диаграмме, расположенные вверху слева, «доминируют» над блоками, расположенными внизу справа. 3. Неконтекстные диаграммы должны содержать не менее трех и не более шести блоков. Эти ограничения поддерживают сложность диаграмм на уровне, доступном для чтения, понимания и использования. 4. Каждый блок неконтекстной диаграммы получает номер, помещаемый в правом нижнем углу; порядок нумерации – от верхнего левого к нижнему правому блоку (номера от 1 до 6). 5. Каждый блок, подвергнутый декомпозиции, должен иметь ссылку на дочернюю диаграмму. Ссылка (например узловой номер, C-номер или номер страницы) помещается под правым нижним углом блока. 6. Имена блоков (выполняемых функций) и метки стрелок должны быть уникальными. Если метки стрелок совпадают, это значит, что стрелки отображают тождественные данные. Типизация функциональных моделей и IDEF0-диаграмм Эффективность и производительность труда разработчиков функциональных моделей могут быть повышены за счет применения типовых моделей и отдельных диаграмм, ориентированных на применение в конкретных предметных областях. Так, на основе представлений о жизненном цикле продукции (изделия) можно предложить типовую диаграмму уровня А0 для промышленного предприятия, которая может иметь вид, схематически показанный на рис. 2.23.  Рис. 2.23. Типовая диаграмма для промышленного предприятия На рис. 2.24 типовая IDEF0-диаграмма показана вместе с находящейся на ее полях служебной информацией, которая состоит из хорошо выделенных верхнего и нижнего колонтитулов (заголовка и «подвала»). Элементы заголовка используются для отслеживания процесса создания модели. Элементы «подвала» отображают наименование модели, к которой относится диаграмма, и показывают ее расположение относительно других диаграмм модели.  Рис. 2.24. IDEF0-диаграмма со служебной информацией на полях Примеры диаграмм процессов SADT/IDEF0 показаны на рис. 2.25а, 2.25б.  Рис. 2.25а. Модель процессов ВУЗа (1 часть)  Рис. 2.25б. Модель процессов ВУЗа (2 часть) Создание IDEF0-диаграмм При создании любой IDEF0-диаграммы должны быть удовлетворены следующие требования: a) цель и точка зрения диаграммы должны соответствовать установленным цели и точке зрения всей модели; б) граничные стрелки (дуги) должны соответствовать дугам на родительской диаграмме; в) содержание диаграммы должно точно соответствовать содержанию родительского блока. Основные этапы построения диаграммы Поэтапный порядок построения диаграмм позволяет создавать диаграммы, образующие взаимосвязанные модели. Необходимо соблюдать следующую последовательность: 1. Определите суть проблемы более точно, чем это предложено в названии функционального блока. Это можно сделать с помощью списка данных (объектов или информации), которые воздействуют на функцию или обрабатываются ею. 2. Изучите определенное таким образом содержание и сформируйте возможные подфункции общей функции. 3. Постарайтесь соединить эти подфункции естественными связями. 4. Разъедините и скомбинируйте подфункции для образования других блоков. 5. Нарисуйте окончательный вариант диаграммы, уделяя особое внимание размещению деталей и ясности изображения. Построение контекстной диаграммы Моделирование следует начинать с построения диаграммы А – 0. Нарисуйте один блок, содержащий имя функции, которая охватывает всю сферу деятельности описываемой системы. Используйте дуги, входящие в блок и выходящие из него, чтобы представить обмен данными системы и ее окружения. Эта диаграмма с единственным блоком определяет контекст всей модели и образует основу для дальнейшей декомпозиции. Построение диаграммы верхнего уровня Все функции системы содержатся в единственном блоке, показанном на диаграмме А – 0. Диаграмма очерчивает границы контекста системы. Диаграмма А0 декомпозирует диаграмму А – 0 на подфункции (от 3 до 6). Настоящая «вершина» модели – диаграмма А0. Она является первым и наиболее важным выражением точки зрения модели. Ее структура ясно показывает, что пытается «сказать» диаграмма А-0. Термины и структура диаграммы А0 ограничивают и каждый последующий уровень, поскольку она является полным описанием выбранного объекта. Нижние уровни описывают каждую из функций (блоков) А0. Чтобы достичь цели модели, эта цепочка детализации должна тщательно прослеживаться на каждом шаге. Построение последовательных диаграмм Для формирования иерархии диаграмм декомпозируйте каждый блок диаграммы А0 на его основные части. Постройте новую диаграмму, на которой представлено то же, что на родительском блоке, но более подробно. Для декомпозиции каждого блока на 3–6 блоков соберите дополнительную информацию. Сделайте первую диаграмму-набросок, перечислив все виды данных, содержащихся в декомпозируемом блоке. Стремитесь к тому, чтобы эти данные охватывали всю тематику родительского блока, без потери каких-либо частей при декомпозиции. Начертите блоки, основанные на этих перечнях, и начертите интерфейсные дуги между блоками. Примерный план действий при создании IDEF0-диаграмм: 1. Составьте относящийся к делу, но еще не структурированный перечень данных, а также список первых появившихся соображений (в контексте родительского блока). Близкие по смыслу вещи по возможности объединяйте. 2. Дайте имена функциям, которые воздействуют на перечисленные данные, и нарисуйте блоки вокруг имен. 3. Набросайте соответствующие дуги. В процессе создания блока рисуйте только «зачатки» дуг, чтобы лучше выделить блок. Закончите соединения, когда смысл диаграммы прояснится. 4. Выберите такое расположение блоков и дуг, которое максимально проявляет их взаимосвязи. Объединяйте дуги вместе, если структура слишком детализирована. Оставьте только существенные элементы и преобразуйте диаграмму. |
