Методология IDEF. Средство автоматизированного проектирования BPWin 4.0

Министерство образования РФ Пермский государственный технический университет Кафедра автоматики и телемеханики МЕТОДОЛОГИЯ IDEF0 СРЕДСТВО АВТОМАТИЗИРОВАННОГО ПРОЕКТИРОВАНИЯ BPWin 4.0 Методическое пособие Для студентов специальности 210100 «Управление и информатика в технических системах» Пермь 2004 СОДЕРЖАНИЕ 1.Теоретические сведения о методологии IDEF0 3 2. Синтаксис IDEF0 5 2.1 Блок. 5 2.2. Стрелка. 6 2.3 Синтаксические правила. 6 2.3.1 Блоки 6 2.3.2 Стрелки 6 3. Семантика языка IDEF0. 7 3.1 Семантика блоков и стрелок 7 3.2 Имена и метки. 8 3.3 Семантические правила блоков и стрелок 8 3.4 Диаграммы IDEF0. 8 3.5 Контекстная диаграмма верхнего уровня. 9 3.6 Дочерняя диаграмма . 10 3.7 Родительская диаграмма 10 4. Создание контекстной диаграммы на основе IDEF0 11 5. Средство автоматизированного проектирования BPwin 4.0 15 6. Описание лабораторной работы 15 6.1 Методические указания к выполнению работы 15 6.1.1 Создание функциональной модели 15 6.1.2 Создание диаграммы декомпозиции 23 6.1.3 Создание диаграммы декомпозиции А2 29 6.2 Требование к отчету 32 6.3 Контрольные вопросы 32 Методическое пособие для проведения лабораторной работы по теме: «Моделирование процессов на основе методологии IDEF0» Цель лабораторной работы: познакомиться с основными характеристиками и возможностями автоматизированного средства проектирования BPWin 4.0; изучить методологию IDEF0, познакомиться с ее семантикой и синтаксисом. 1.Теоретические сведения о методологии IDEF0 Постоянное усложнение производственно-технических и организационно-экономических систем – фирм, предприятий, производств, и др. субъектов производственно-хозяйственной деятельности - и необходимость их анализа с целью совершенствования функционирования и повышения эффективности обусловливают необходимость применения специальных средств описания и анализа таких систем. Эта проблема приобретает особую актуальность в связи с появлением интегрированных компьютеризированных производств и автоматизированных предприятий. В США это обстоятельство было осознано еще в конце 70-ых годов, когда ВВС США предложили и реализовали Программу интегрированной компьютеризации производства ICAM (ICAM - Integrated Computer Aided Manufacturing),направленную на увеличение эффективности промышленных предприятий посредством широкого внедрения компьютерных (информационных) технологий. Реализация программы ICAM потребовала создания адекватных методованализа и проектирования производственных систем и способов обмена информацией между специалистами, занимающимися такими проблемами. Для удовлетворения этой потребности в рамках программы ICAM была разработана методология IDEF (ICAM Definition), позволяющая исследовать структуру, параметры и характеристики производственно-технических и организационно-экономических систем (в дальнейшем, там, где это не вызывает недоразумений – систем). Общая методология IDEF состоит из трех частных методологий моделирования, основанных на графическом представлении систем: • IDEF0 используется для создания функциональной модели, отображающей структуру и функции системы, а также потоки информации и материальных объектов, связывающие эти функции; • IDEF1 применяется для построения информационной модели, отображающей структуру и содержание информационных потоков, необходимых для поддержки функций системы; • IDEF2 позволяет построить динамическую модель меняющихся во времени поведения функций, информации и ресурсов системы. К настоящему времени наибольшее распространение и применение имеют методологии IDEF0 и IDEF1 (IDEF1X), получившие в США статус федеральных стандартов. [1 ,2 ]. Методология IDEF0, особенности и приемы применения основана на подходе, разработанном Дугласом Т. Россом в начале 70–ых годов и получившем название SADT (Structured Analysis & Design Technique - метод структурного анализа и проектирования). Основу подхода и, как следствие, методологии IDEF0, составляет графический язык описания (моделирования) систем, обладающий следующими свойствами. • Графический язык - полное и выразительное средство, способное наглядно представлять широкий спектр деловых, производственных и других процессов и операций предприятия на любом уровне детализации; • Язык обеспечивает точное и лаконичное описание моделируемых объектов, удобство использования и интерпретации этого описания; • Язык облегчает взаимодействие и взаимопонимание системных аналитиков, разработчиков и персонала изучаемого объекта (фирмы, предприятия), т.е. служит средством «информационного общения» большого числа специалистов и рабочих групп, занятых в одном проекте, в процессе обсуждения, рецензирования, критики и утверждения результатов; • · Язык прошел многолетнюю проверку и продемонстрировал работоспособность как в проектах ВВС США, так и в других проектах, выполнявшихся государственными и частными промышленными компаниями; • · Язык легок и прост в изучении и освоении; • · Язык может генерироваться рядом инструментальных средств машинной графики; известны коммерческие программные продукты, поддерживающие разработку и анализ моделей - диаграмм IDEF0, например, продукт Design/IDEF 3.7 (и более поздние версии) фирмы Meta Software Corporation (США). Перечисленные свойства языка предопределили выбор методологии IDEF0 в качестве базового средства анализа и синтеза производственно-технических и организационно-экономических систем, что нашло свое отражение в упомянутых федеральных стандартах США. Методология IDEF0 основана на следующих концептуальных положениях. 1.1 Модель – искусственный объект, представляющий собой отображение (образ) системы и ее компонентов. М моделирует А, если М отвечает на вопросы относительно А. Здесь М – модель, А – моделируемый объект (оригинал). Модель разрабатывают для понимания, анализа и принятия решений о реконструкции (реинжиниринге) или замене существующей, либо проектировании новой системы. Система представляет собой совокупность взаимосвязанных и взаимодействующих частей, выполняющих некоторую полезную работу. Частями (элементами) системы могут быть любые комбинации разнообразных сущностей, включающие людей, информацию, программное обеспечение, оборудование, изделия, сырье или энергию (энергоносители). Модель описывает, что происходит в системе, как ею управляют, какие сущности она преобразует, какие средства использует для выполнения своих функций и что производит. 1.2 Блочное моделирование и его графическое представление. Основной концептуальный принцип методологии IDEF – представление любой изучаемой системы в виде набора взаимодействующих и взаимосвязанных блоков, отображающих процессы, операции, действия (определения – см. ниже), происходящие в изучаемой системе. В IDEF0 все, что происходит в системе и ее элементах, принято называть функциями. Каждой функции ставится в соответствие блок. На IDEF0 –диаграмме, основном документе при анализе и проектировании систем, блок представляет собой прямо- угольник. Интерфейсы, посредством которых блок взаимодействует с другими блоками или с внешней по отношению к моделируемой системе средой, представляются стрелками ), входящими в блок или выходящими из него. Входящие стрелки показывают, какие условия должны быть одновременно выполнены, чтобы функция, описываемая блоком, осуществилась. 1.3 Лаконичность и точность. Документация, описывающая систему, должна быть точной и лаконичной. Многословные характеристики, изложенные в форме традиционных текстов, неудовлетворительны. Графический язык позволяет лаконично, однозначно и точно показать все элементы (блоки) системы и все отношения и связи между ними, выявить ошибочные, лишние или дублирующие связи и т.д.. 1.4 Передача информации. Средства IDEF0 облегчают передачу информации от одного участника разработки модели (отдельного разработчика или рабочей группы) к другому. К числу таких средств относятся: · диаграммы, основанные на простой графике блоков и стрелок, легко читаемые и понимаемые; · метки на естественном языке для описания блоков и стрелок, а также глоссарий и сопроводительный текст для уточнения смысла элементов диаграммы; · последовательная декомпозиция диаграмм, строящаяся по иерархическому принципу, при котором на верхнем уровне отображаются основные функции, а затем происходит их детализация и уточнение; · древовидные схемы иерархии диаграмм и блоков , обеспечивающие обозримость модели в целом и входящих в нее деталей. 1.5 Строгость и формализм. Разработка моделей IDEF0 требует соблюдения ряда строгих формальных правил, обеспечивающих преимущества методологии в отношении однозначности, точности и целостности сложных многоуровневых моделей. Эти правила описываются ниже. Здесь отмечается только основное из них: все стадии и этапы разработки и корректировки модели должны строго, формально документироваться с тем, чтобы при ее эксплуатации не возникало вопросов , связанных с неполнотой или некорректностью документации. 1.6 Итеративное моделирование. Разработка модели в IDEF0 представляет собой пошаговую, итеративную процедуру. На каждом шаге итерации разработчик предлагает вариант модели, который подвергают обсуждению, рецензированию и последующему редактированию, после чего цикл повторяется. Такая организация работы способствует оптимальному использованию знаний системного аналитика, владеющего методологией и техникой IDEF0, и знаний специалистов – экспертов в предметной области, к которой относится объект моделирования. 1.7 Отделение «организации» от «функций». При разработке моделей следует избегать изначальной «привязки» функций исследуемой системы к существующей организационной структуре моделируемого объекта (предприятия, фирмы). Это помогает избежать субъективной точки зрения, навязанной организацией и ее руководством. Организационная структура должна явиться результатом использования (применения) модели. Сравнение результата с существующей структурой позволяет, во-первых, оценить адекватность модели, а во-вторых – предложить решения, направленные на совершенствование этой структуры. 2. Синтаксис IDEF0 Набор структурных компонентов языка, их характеристики и правила, определяющие связи между компонентами, представляют собой синтаксис языка. Компоненты синтаксиса IDEF0 – блоки, стрелки, диаграммы и правила. Блоки представляют функции, определяемые как деятельность, процесс, операция, действие или преобразование (см. ниже). Стрелки представляют данные или материальные объекты, связанные с функциями. Правила определяют, как следует применять компоненты; диаграммы обеспечивают формат графического и словесного описания моделей. Формат образует основу для управления конфигурацией модели. 2.1 Блок. Блок описывает функцию. Типичный блок показан на рис. 2.1. Внутри каждого блока помещается его имя и номер. Имя должно быть активным глаголом или глагольным оборотом, описывающим функцию. Номер блока размещается в правом нижнем углу. Номера блоков используются для их идентификации на диаграмме и в соответствующем тексте. Рис. 2.1 2.2. Стрелка. Стрелка формируется из одного или более отрезков прямых и наконечника на одном конце. Как показано на рис. 2.2, сегменты стрелок могут быть прямыми или ломаными; в последнем случае горизонтальные и вертикальные отрезки стрелки сопрягаются дугами, имеющими угол 90о. Стрелки не представляют поток или последовательность событий, как в традиционных блок-схемах потоков или процессов. Они лишь показывают, какие данные или материальные объекты должны поступить на вход функции для того, чтобы эта функция могла выполняться. Рис. 2.2 Синтаксис стрелок. 2.3 Синтаксические правила. Рис. 2.2 2.3.1 Блоки 1.Размеры блоков должны быть достаточными для того, чтобы включить имя блока. 2.Блоки должны быть прямоугольными, с прямыми углами. 3.Блоки должны быть нарисованы сплошными линиями. 2.3.2 Стрелки 1. Ломаные стрелки изменяют направление только под углом 90 град. 2. Стрелки должны быть нарисованы сплошными линиями различной толщины. 3. Стрелки могут состоять только из вертикальных или горизонтальных отрезков; отрезки, направленные по диагонали , не допускаются. 4. Концы стрелок должны касаться внешней границы функционального блока, но не должны пересекать ее. 5.Стрелки должны присоединяться к блоку на его сторонах. Присоединение в углах не допускается. 3. Семантика языка IDEF0. Семантика определяет содержание (значение) синтаксических компонентов языка и способствует правильности их интерпретации. Интерпретация устанавливает соответствие между блоками и стрелками с одной стороны и функциями и их интерфейсами – с другой. 3.1 Семантика блоков и стрелок Поскольку IDEF0 есть методология функционального моделирования, имя блока, описывающее функцию, должно быть глаголом или глагольным оборотом; например, имя блока "Выполнить проверку", означает, что блок с таким именем превращает непроверенные детали в проверенные. После присваивания блоку имени, к соответствующим его сторонам присоединяются входные, выходные и управляющие стрелки, а также стрелки механизма, что и определяет наглядность и выразительность изображения блока IDEF0. Чтобы гарантировать точность модели, следует использовать стандартную терминологию. Блоки именуются глаголами или глагольными оборотами и эти имена сохраняются при декомпозиции Стрелки и их сегменты, как отдельные, так и связанные в «пучок», помечаются существительными или оборотами существительного. Метки сегментов позволяют конкретизировать данные или материальные объекты, передаваемые этими сегментами, с соблюдением синтаксиса ветвлений и слияний. Каждая сторона функционального блока имеет стандартное значение с точки зрения связи блок/стрелки, В свою очередь, сторона блока, к которой присоединена стрелка, однозначно определяет ее роль. Стрелки, входящие в левую сторону блока - входы. Входы преобразуются или расходуются функцией, чтобы создать то, что появится на ее выходе. Стрелки, входящие в блок сверху - управления. Управления определяют условия, необходимые функции, чтобы произвести правильный выход. Стрелки, покидающие блок справа – выходы, т.е. данные или материальные объекты, произведенные функцией. Стрелки, подключенные к нижней стороне блока, представляют механизмы. Стрелки, направленные вверх, идентифицируют средства, поддерживающие выполнение функции. Другие средства могут наследоваться из родительского блока. Стрелки механизма, направленные вниз, являются стрелками вызова. Стрелки вызова обозначают обращение из данной модели или из данной части модели к блоку, входящему в состав другой модели или другой части модели, обеспечивая их связь, т.е. разные модели или разные части одной и той же модели могут совместно использовать один и тот же элемент (блок). Стандартное расположение стрелок показано на рис.3.1 Рис 3.1 3.2 Имена и метки. Как указывалось, имена функций – глаголы или глагольные обороты. Примеры таких имен: Стрелки идентифицируют данные или материальные объекты, необходимые для выполнения функции или производимые ею. Каждая стрелка должна быть помечена существительным или оборотом существительного, например: Пример размещения меток стрелок и имени блока показан на рис. 3.2. 3.3 Семантические правила блоков и стрелок 1. Имя блока должно быть активным глаголом или глагольным оборотом. 2. Каждая сторона функционального блока должна иметь стандартное отношение блок/стрелки: а) входные стрелки должны связываться с левой стороной блока; б) управляющие стрелки должны связываться с верхней стороной блока; в) выходные стрелки должны связываться с правой стороной блока; г) стрелки механизма (кроме стрелок вызова) должны указывать вверх и подключаться к нижней стороне блока. д) стрелки вызова механизма должны указывать вниз, подключаться к нижней стороне блока, и помечаться ссылкой на вызываемый блок. Рис. 3.2 3. Сегменты стрелок, за исключением стрелок вызова, должны помечаться существительным или оборотом существительного, если только единственная метка стрелки несомненно не относится к стрелке в целом. 4. Чтобы связать стрелку с меткой, следует использовать "тильду" () 5. В метках стрелок не должны использоваться следующие термины: функция, вход, управление, выход, механизм, вызов. 3.4 Диаграммы IDEF0. IDEF0-модели состоят из трех типов документов: графических диаграмм, текста и глоссария. Эти документы имеют перекрестные ссылки друг на друга. Графическая диаграмма – главный компонент IDEF0-модели, содержащий блоки, стрелки, соединения блоков и стрелок и ассоциированные с ними отношения. Блоки представляют основные функции моделируемого объекта. Эти функции могут быть разбиты (декомпозированы) на составные части и представлены в виде более подробных диаграмм; процесс декомпозиции продолжается до тех пор, пока объект не будет описан на уровне детализации, необходимом для достижения целей конкретного проекта. Диаграмма верхнего уровня обеспечивает наиболее общее или абстрактное описание объекта моделирования. За этой диаграммой следует серия дочерних диаграмм, дающих более детальное представление об объекте. 3.5 Контекстная диаграмма верхнего уровня. Каждая модель должна иметь контекстную диаграмму верхнего уровня, на которой объект моделирования представлен единственным блоком с граничными стрелками. Эта диаграмма называется A-0 (А минус нуль). Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой. Поскольку единственный блок представляет весь объект, его имя общее для всего проекта. Это же справедливо и для всех стрелок диаграммы, поскольку они представляют полный комплект внешних интерфейсов объекта. Диаграмма A-0 устанавливает область моделирования и ее границу. Пример диаграммы A-0 показан на рис. 3.3. Рис. 3.3 Контекстная диаграмма A-0 также должна содержать краткие утверждения, определяющие точку зрения должностного лица или подразделения, с позиций которого создается модель, и цель, для достижения которой ее разрабатывают. Эти утверждения помогают руководить разработкой модели и ввести этот процесс в определенные рамки. Точка зрения определяет, что и в каком разрезе можно увидеть в пределах контекста модели. Изменение точки зрения, приводит к рассмотрению других аспектов объекта. Аспекты, важные с одной точки зрения, могут не появиться в модели, разрабатываемой с другой точки зрения на тот же самый объект. Формулировка цели выражает причину создания модели, т.е. содержит перечень вопросов, на которые должна отвечать модель, что в значительной мере определяет ее структуру. Наиболее важные свойства объекта обычно выявляются на верхних уровнях иерархии; по мере декомпозиции функции верхнего уровня и разбиения ее на подфункции, эти свойства уточняются. Каждая подфункция, в свою очередь, декомпозируется на элементы следующего уровня, и так происходит до тех пор, пока не будет получена релевантная структура, позволяющая ответить на вопросы, сформулированные в цели моделирования. Каждая подфункция моделируется отдельным блоком. Каждый родительский блок подробно описывается дочерней диаграммой на более низком уровне. Все дочерние диаграммы должны быть в пределах области контекстной диаграммы верхнего уровня. 3.6 Дочерняя диаграмма . Единственная функция, представленная на контекстной диаграмме верхнего уровня, может быть разложена на основные подфункции посредством создания дочерней диаграммы. В свою очередь, каждая из этих подфункций может быть разложена на составные части посредством создания дочерней диаграммы следующего, более низкого уровня, на которой некоторые или все функции также могут быть разложены на составные части. Каждая дочерняя диаграмма содержит дочерние блоки и стрелки, обеспечивающие дополнительную детализацию родительского блока. Дочерняя диаграмма, создаваемая при декомпозиции, охватывает ту же область, что и родительский блок, но описывает ее более подробно. Таким образом, дочерняя диаграмма как бы вложена в свой родительский блок. Эта структура иллюстрируется рис. 3.4. 3.7 Родительская диаграмма Родительская диаграмма – та, которая содержит один или более родительских блоков. Каждая обычная (не-контекстная) диаграмма является также дочерней диаграммой, поскольку, по определению, она подробно описывает некоторый родительский блок. Таким образом, любая диаграмма может быть как родительской диаграммой (содержать родительские блоки), так и дочерней (подробно описывать собственный родительский блок). Аналогично, блок может быть как родительским (подробно описываться дочерней диаграммой) так и дочерним (появляющимся на дочерней диаграмме). Основное иерархическое отношение существует между родительским блоком и дочерней диаграммой, которая его подробно описывает (рис.3.4). То, что блок является дочерним и раскрывает содержание родительского блока на диаграмме предшествующего уровня, указывается специальным ссылочным кодом, написанным ниже правого нижнего угла блока. Этот ссылочный код может формироваться несколькими способами, из которых самый простой заключается в том, что код , начинающийся с буквы А(по имени диаграммы А-0), содержит цифры, определяемые номерами родительских блоков. Например, показанные на рис.7 коды означают, что диаграмма является декомпозицией 1-го блока диаграммы, которая, в свою очередь является декомпозицией 6-го блока диаграммы А0, а сами коды образуются присоединением номера блока. Таким образом, код формируется так: Рис. 3.4 4. Создание контекстной диаграммы на основе IDEF0 1. В составе модели должна присутствовать контекстная диаграмма A-0, которая содержит только один блок. Номер единственного блока на контекстной диаграмме A-0 должен быть 0. 2. Блоки на диаграмме должны располагаться по диагонали – от левого верхнего угла диаграммы до правого нижнего в порядке присвоенных номеров. Блоки на диаграмме, расположенные вверху слева «доминируют» над блоками, расположенными внизу справа. «Доминирование» понимается как влияние, которое блок оказывает на другие блоки диаграммы. Расположение блоков на листе диаграммы отражает авторское понимание доминирования. Таким образом, топология диаграммы показывает, какие функции оказывают большее влияние на остальные. 3. Неконтекстные диаграммы должны содержать не менее трех и не более шести блоков. Эти ограничения поддерживают сложность диаграмм на уровне, доступном для чтения, понимания и использования. Диаграммы с количеством блоков менее трех вызывают серьезные сомнения в необходимости декомпозиции родительской функции. Диаграммы с количеством блоков более шести сложны для восприятия читателями и вызывают у автора трудности при внесении в нее всех необходимых графических объектов и меток. 4. Каждый блок неконтекстной диаграммы получает номер, помещаемый в правом нижнем углу; порядок нумерации - от верхнего левого к нижнему правому блоку (номера от 1 до 6). 5. Каждый блок, подвергнутый декомпозиции, должен иметь ссылку на дочернюю диаграмму; ссылка (например, узловой номер, C-номер или номер страницы) помещается под правым нижним углом блока. 6. Имена блоков (выполняемых функций) и метки стрелок должны быть уникальными. Если метки стрелок совпадают, это значит, что стрелки отображают тождественные данные. 7. При наличии стрелок со сложной топологией целесообразно повторить метку для удобства ее идентификации. 8. Следует обеспечить максимальное расстояние между блоками и поворотами стрелок, а также между блоками и пересечениями стрелок для облегчения чтения диаграммы. Одновременно уменьшается вероятность перепутать две разные стрелки. 9. Блоки всегда должны иметь хотя бы одну управляющую и одну выходную стрелку, но могут не иметь входных стрелок. 10. Если одни и те же данные служат и для управления, и для входа, вычерчивается только стрелка управления. Этим подчеркивается управляющий характер данных и уменьшается сложность диаграммы. 11. Максимально увеличенное расстояние между параллельными стрелками облегчает размещения меток, их чтение и позволяет проследить пути стрелок. Рис. 4.1 12. Стрелки связываются (сливаются), если они представляют сходные данные и их источник не указан на диаграмме (рис. 4.2). Рис. 4.2 13. Обратные связи по управлению должны быть показаны как "вверх и над" (рис. 4.3, а): Рис. 4.3 Обратные связи по входу должны быть показаны как "вниз и под" (рис. 4.3,б). Так же показываются обратные связи посредством механизма. Таким образом обеспечивается показ обратной связи при минимальном числе линий и пересечений. 14. Циклические обратные связи для одного и того же блока изображаются только для того, чтобы их выделить. Обычно обратную связь изображают на диаграмме, декомпозирующей блок. Однако иногда требуется выделить повторно используемые объекты (рис.4.4). Рис 4.4 15. Стрелки объединяются, если они имеют общий источник или приемник, или они представляют связанные данные. Общее название лучше описывает суть данных. Следует минимизировать число стрелок, касающихся каждой стороны блока, если, конечно, природа данных не слишком разнородна (рис. 4.5). Рис 4.5 16. Если возможно, стрелки присоединяются к блокам в одной и той же позиции. Тогда соединение стрелок конкретного типа с блоками будет согласованным и чтение диаграммы упростится. Рис. 4.6 17. При соединении большого числа блоков необходимо избегать необязательных пересечений стрелок. Следует минимизировать число петель и поворотов каждой стрелки. Рис 4.7 Рис 4.8 18. Блоки (функции) являются сопряженными через среду, если они имеют связи с источником, генерирующим данные, без конкретного определения отношения отдельной части данных к какому-либо блоку. Рис. 4.9 19. Две или более функций являются сопряженными через запись, если они связаны с набором данных и не обязательно зависят от того, представлены ли все возможные интерфейсы как сопряжение через среду. Тип интерфейса, показанный на рисунке 34, предпочтителен, поскольку определяются отношения конкретных элементов данных к каждому блоку. Рис. 4.10 20. Необходимо использовать (где это целесообразно) выразительные возможности ветвящихся стрелок. Рис 4.11 5. Средство автоматизированного проектирования BPwin 4.0 BPwin-CASE-средство, позволяющее документировать бизнес-процедуры графически. Описание бизнес-процедур на языке IDEF-диаграмм будет одновременно и формально строгим, и достаточно лаконичным. PLATINUM BPwin - мощный инструмент моделирования, который используется для анализа, документирования и реорганизации сложных бизнес-процессов. Модель, созданная средствами BPwin, позволяет четко документировать различные аспекты деятельности - действия, которые необходимо предпринять, способы их осуществления, требующиеся для этого ресурсы и др. Таким образом, формируется целостная картина деятельности предприятия от моделей организации работы в маленьких отделах до сложных иерархических структур. При разработке или закупке программного обеспечения модели бизнес-процессов служат прекрасным средством документирования потребностей, помогая обеспечить высокую эффективность инвестиций в IT-технологии. 6. Описание лабораторной работы В качестве примера рассматривается деятельность вымышленной компании «Computer Word». Компания занимается в основном сборкой и продажей настольных компьютеров и ноутбуков. Компания не производит компоненты самостоятельно, а только собирает и тестирует компьютеры. Основные виды работ в компании таковы: • продавцы принимают заказы клиентов; • операторы группируют заказы по типам компьютеров; • операторы собирают и тестируют компьютеры; • операторы упаковывают компьютеры согласно заказам; • кладовщик отгружает клиентам заказы. Компания использует лицензионную бухгалтерскую информационную систему, которая позволяет оформить заказ, счет и отследить платежи по счетам 6.1 Методические указания к выполнению работы 6.1.1 Создание функциональной модели 1 Запустите BPwin. (Кнопка Start /BPwin ). 2 Если появляется диалог ModelMart Connection Manager, нажмите на кнопку Cancel (Отмена). 3 Щелкните по кнопке . Появляется диалоговое окно I would like to (рисунок 5.1). Внесите в текстовое поле Name имя модели "Деятельность компании" и выберите Туре – Business Process (IDEF0). Нажмите кнопку ОК. Рисунок 6.1 4 Откроется диалоговое окно Properties for New Models (Свойства новой модели) (рисунок 5.2). Рисунок 6.2 Введите в текстовое поле Author (Автор) имя автора модели и в текстовое поле Author initials его инициалы. Нажмите последовательно кнопки Apply и ОК. 5 Автоматически создается незаполненная контекстная диаграмма (рисунок 6.3). Рисунок 6.3 6 Обратите внимание на кнопку на панели инструментов. Эта кнопка включает и выключает инструмент просмотра и навигации - Model Explorer (Браузер модели). Model Explorer имеет три вкладки –Activities (), Diagrams () и Objects (). Во вкладке Activities щелчок правой кнопкой по объекту в браузере модели позволяет выбрать опции редактирования его свойств (рисунок 6.4). Рисунок 6.4 7 Если вам непонятно, как выполнить то или иное действие, вы можете вызвать контекстную помощь - клавиша F1 или воспользоваться меню Help. 8 Перейдите в меню Model/Model Properties. Во вкладке General диалогового окна Model Properties в текстовое поле Model name следует внести имя модели "Деятельность компании", а в текстовое поле Project имя проекта "Модель деятельности компании", и, наконец, в текстовое Time Frame (Временной охват) - AS-IS (Как есть) (рисунок 6.5). 9 Во вкладке Purpose диалогового окна Model Properties в текстовое поле Purpose (цель) внесите данные о цели разработки модели - " Моделировать текущие (AS-IS) бизнес-процессы компании", а в текстовое поле Viewpoint (точка зрения) - "Директор". Рисунок 6.5 Рисунок 6.6 10 Во вкладке Definition диалогового окна Model Properties в текстовое поле Definition (Определение) внесите "Это учебная модель, описывающая деятельность компании" и в текстовое поле Scope (охват) - " Общее управление бизнесом компании: исследование рынка, закупка компонентов, сборка, тестирование и продажа продуктов". Рисунок 6.7 11 Перейдите на контекстную диаграмму и правой кнопкой мыши щелкните по прямоугольнику представляющему, в нотации IDEF0, условное графическое обозначение работы. В контекстном меню выберите опцию Name (рисунок 6.8). Во вкладке Name внесите имя "Деятельность компании" (рисунок 6.9). Рисунок 6.8 Рисунок 6.9 Во вкладке Definition диалогового окна Activity Properties в текстовое поле Definition (Определение) внесите "Текущие бизнес-процессы компании" (рисунок 6.10). Текстовое поле Note (Примечания) оставьте незаполненным. Рисунок 6.10 12 Создайте ICOM-стрелки на контекстной диаграмме (таблица 6.1). Таблица 6.1 - Стрелки контекстной диаграммы Название стрелки (Arrow Name) Определение стрелки (Arrow Definition) Тип стрелки (Arrow Type) Звонки клиентов Запросы информации, заказы, техподдержка и т. д. Input Правила и процедуры Правила продаж, инструкции по сборке, процедуры тестирования, критерии производительности и т. д. Control Проданные продукты Настольные и портативные компьютеры Output Бухгалтерская система Оформление счетов, оплата счетов, работа с заказами Mechanism 13. С помощью кнопки внесите текст в поле диаграммы - точку зрения и цель (рисунок 6.11). Рисунок 6.11 Результат показан на рисунке 6.12. Рисунок 6.12 Создайте отчет по модели. В меню Tools/Reports/Model Report (рисунок 6.13) задайте опции генерирования отчета (установите галочки) и нажмите кнопку Preview (Предварительный просмотр) (рисунок 6.14). Рисунок 6.13 Рисунок 6.14 6.1.2 Создание диаграммы декомпозиции 1 Выберите кнопку перехода на нижний уровень в палитре инструментов и в диалоговом окне Activity Box Count (рисунок 6.15) установите число работ на диаграмме нижнего уровня - 3 - и нажмите кнопку ОК. Рисунок 6.15 2 Автоматически будет создана диаграмма декомпозиции (рисунок 6.16). Рисунок 6.16 Правой кнопкой мыши щелкните по работе расположенной в левом верхнем углу области редактирования модели, выберите в контекстном меню опцию Name и внесите имя работы. Повторите операцию для оставшихся двух работ. Затем внесите определение, статус и источник для каждой работы согласно данным таблицы 6.2. Таблица 6. Название работы (Activity Name) Определение работы (Activity Definition) Продажи и маркетинг Телемаркетинг и презентации, выставки Сборка и тестирование компьютеров Сборка и тестирование настольных и портативных компьютеров Отгрузка и получение Отгрузка заказов клиентам и получение компонентов от поставщиков Диаграмма декомпозиции примет вид представленный на рисунке 6.17. Рисунок 6.17 3 Для изменения свойств работ после их внесения в диаграмму можно воспользоваться словарем работ (рисунок 6.18). Вызов словаря производится при помощи пункта главного меню Dictionary /Activity. Рисунок 6.18 Если описать имя и свойства работы в словаре, ее можно будет внести в диаграмму позже с помощью кнопки в палитре инструментов. Невозможно удалить работу из словаря, если она используется на какой-либо диаграмме. Если работа удаляется из диаграммы, из словаря она не удаляется. Имя и описание такой работы может быть использовано в дальнейшем. Для добавления работы в словарь необходимо перейти в конец списка и щелкнуть правой кнопкой по последней строке. Возникает новая строка, в которой нужно внести имя и свойства работы. Для удаления всех имен работ, не использующихся в модели, щелкните по кнопке (Purge (Чистить)). 4 Перейдите в режим рисования стрелок и свяжите граничные стрелки, воспользовавшись кнопкой на палитре инструментов так, как это показано на рисунке 6.19. Рисунок 6.19 5 Правой кнопкой мыши щелкните по ветви стрелки управления работы "Сборка и тестирование компьютеров" и переименуйте ее в "Правила сборки и тестирования" (рисунок 6.20). Рисунок 6.20 Внесите определение для новой ветви: "Инструкции по сборке, процедуры тестирования, критерии производительности и т. д." Правой кнопкой мыши щелкните по ветви стрелки механизма работы "Продажи и маркетинг" и переименуйте ее как "Система оформления заказов" (рисунок 6.21). Рисунок 6.21 Альтернативный метод внесения имен и свойств стрелок - использование словаря стрелок (вызов словаря - меню Dictionary/ Arrow). Если внести имя и свойства стрелки в словарь (рисунок 6.22), ее можно будет внести в диаграмму позже. Рисунок 6.22 Стрелку нельзя удалить из словаря, если она используется на какой-либо диаграмме. Если удалить стрелку из диаграммы, из словаря она не удаляется. Имя и описание такой стрелки может быть использовано в дальнейшем. Для добавления стрелки необходимо перейти в конец списка и щелкнуть правой кнопкой по последней строке. Возникает новая строка, в которой нужно внести имя и свойства стрелки. 6 Создайте новые внутренние стрелки так, как показано на рисунке 6.23. Рисунок 6.23 Создайте стрелку обратной связи (по управлению) "Результаты сборки и тестирования", идущую от работы "Сборка и тестирование компьютеров" к работе "Продажи и маркетинг". Измените, при необходимости, стиль стрелки (толщина линий) и установите опцию Extra Arrowhead (Дополнительный Наконечник стрелы) (из контекстного меню). Методом drag&drop перенесите имена стрелок так, чтобы их было удобнее читать. Если необходимо, установите из контекстного меню Squiggle (Загогулину). Результат возможных изменений показан на рисунке 6.24. Рисунок 6.24 Создайте новую граничную стрелку выхода "Маркетинговые материалы", выходящую из работы "Продажи и маркетинг". Эта стрелка автоматически не попадает на диаграмму верхнего уровня и имеет квадратные скобки на наконечнике (рисунок 6.25). Рисунок 6.25 Щелкните правой кнопкой мыши по квадратным скобкам и выберите пункт меню Arrow Tunnel (рисунок 6.26). Рисунок 6.26 В диалоговом окне Border Arrow Editor (Редактор Граничных Стрелок) выберите опцию Resolve it to Border Arrow (Разрешить как Граничную Стрелку) (рисунок 6.27). Рисунок 6.27 Для стрелки "Маркетинговые материалы" выберите опцию Trim (Упорядочить) из контекстного меню. Результат показан на рис. 6.28. Рисунок 6.28 6.1.3 Создание диаграммы декомпозиции А2 Декомпозируем работу "Сборка и тестирование компьютеров". В результате проведения экспертизы получена следующая информация. Производственный отдел получает заказы клиентов от отдела продаж по мере их поступления. Диспетчер координирует работу сборщиков, сортирует заказы, группирует их и дает указание на отгрузку компьютеров, когда они готовы. Каждые 2 часа диспетчер группирует заказы - отдельно для настольных компьютеров и ноутбуков - и направляет на участок сборки. Сотрудники участка сборки собирают компьютеры согласно спецификациям заказа и инструкциям по сборке. Когда группа компьютеров, соответствующая группе заказов, собрана, она направляется на тестирование. Тестировщики тестируют каждый компьютер и в случае необходимости заменяют неисправные компоненты. Тестировщики направляют результаты тестирования диспетчеру, который на основании этой информации принимает решение о передаче компьютеров, соответствующих группе заказов, на отгрузку. 1 На основе этой информации внесите новые работы и стрелки (таблица 6.3 и 6.4). Таблица 6.3 Название работы (Activity Name) Определение работы (Activity Definition) Отслеживание расписания и управление сборкой и тестированием Просмотр заказов, установка расписания выполнения заказов, просмотр результатов тестирования, формирование групп заказов на сборку и отгрузку Сборка настольных компьютеров Сборка настольных компьютеров в соответствии с инструкциями и указаниями диспетчера Сборка ноутбуков Сборка ноутбуков в соответствии с инструкциями и указаниями диспетчера Тестирование компьютеров Тестирование компьютеров и компонентов. Замена неработающих компонентов Таблица 6.4 Наименование стрелки (Arrow Name) Источник стрелки (Arrow Source) Тип стрелки источника (Arrow Source Type) Приемник стрелки (Arrow Dest.) Тип стрелки приемника (Arrow Dest. Type) Диспетчер Персонал производственного отдела Отслеживание расписания и управление сборкой и тестированием Mechanism Заказы клиентов Граница диаграммы Control Отслеживание расписания и управление сборкой и тестированием Control Заказы на настольные компьютеры Отслеживание расписания и управление сборкой и тестированием Output Сборка настольных компьютеров Control Заказы на ноутбуки Отслеживание расписания и управление сборкой и тестированием Output Сборка ноутбуков Control Компоненты "Tunnel" Input Сборка настольных компьютеров Input Сборка ноутбуков Input Тестирование компьютеров Input Настольные компьютеры Сборка настольных компьютеров Output Тестирование компьютеров Input Ноутбуки Сборка ноутбуков Output Тестирование компьютеров Input Продолжение таблица 6.4 Наименование стрелки (Arrow Name Источник стрелки (Arrow Source) Тип источника стрелки (Arrow Source Type) Пункт назначения стрелки (Arrow Dest.) Тип стрелки пункта назначения (Arrow Dest. Type) Персонал производственного отдела "Tunnel" Сборка настольных компьютеров Mechanism Сборка ноутбуков Mechanism Правила сборки и тестирования Граница диаграммы Сборка настольных компьютеров Control Сборка ноутбуков Control Тестирование компьютеров Control Результаты сборки и тестирования Сборка настольных компьютеров Output Граница диаграммы Output Сборка ноутбуков Output Тестирование компьютеров Output Результаты тестирования Тестирование компьютеров Output Отслеживание расписания и управление сборкой и тестированием Input Собранные компьютеры Тестирование компьютеров Output Граница диаграммы Output Тестировщик Персонал производственного отдела Тестирование компьютеров Mechanism Указание передать компьютеры на отгрузку Отслеживание расписания и управление сборкой и тестированием Output Тестирование компьютеров Control 2 Туннелируйте и свяжите на верхнем уровне граничные стрелки, если это необходимо. Результат показан на рисунке 6.29. Рисунок 6.29