Разработка редактора бизнес-процессов с использованием нотации IDEF0

Разработка редактора бизнес-процессов с использованием нотации IDEF0

Введение

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

Методология IDEF0 представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель IDEF0 отображает функциональную структуру объекта, то есть производимые им действия и связи между этими действиями. Функциональную модель иначе называют функциональной архитектурой объекта (системы). Методология IDEF0 может применяться для моделирования широкого круга систем включающих в себя любую комбинацию технических средств, программного обеспечения и персонала. При создании новых систем методология IDЕF0 может использоваться сначала для определения требований и функций, а затем для разработки самой системы удовлетворяющей требованиям и реализующей функции.

Для действующих систем методология IDEF0 может использоваться для анализа функций, выполняемых системой, а также для наглядного представления “механизмов”, посредством которых эти функции осуществляются.

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

В методе IDEF0 можно выделить следующие составляющие:

концепция метода;

графический язык;

процедура чтения диаграммы;

метод построения модели;

критерии оценки качества;

процедуры контроля качества модели;

метод объединения модели.

В организационную поддержку метода IDEF0 входят:

метод групповой работы;

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

процедуры согласования и утверждения модели; способ ведения личных архивов моделей; процедура сбора данных.

Целью выполнения моей курсовой работы является разработка редактора бизнес-процессов с использованием нотации IDEF0.

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

Инструментарий - Microsoft Visio 2012, Microsoft Word.

1.1 История возникновения стандарта IDEF0

Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Teqnique). В процессе практической реализации, участники программы ICAM столкнулись с необходимостью разработки новых методов анализа процессов взаимодействия в промышленных системах. При этом кроме усовершенствованного набора функций для описания бизнес-процессов, одним из требований к новому стандарту было наличие эффективной методологии взаимодействия в рамках «аналитик-специалист». Другими словами, новый метод должен был обеспечить групповую работу над созданием модели, с непосредственным участием всех аналитиков и специалистов, занятых в рамках проекта. В результате поиска соответствующих решений родилась методология функционального моделирования IDEF0. C 1981 года стандарт IDEF0 претерпел несколько незначительных изменения, в основном ограничивающего характера, и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом по Стандартам и Технологиям США (NIST).

1.2 Синтаксис и семантика модели IDEF0

1.2.1 Модели IDEF0сочетает в себе небольшую по объему графическую нота­цию (она содержит только два обозначения: блоки и стрелки) со стро­гими и четко определенными рекомендациями, в совокупности пред­назначенными для построения качественной и понятной модели системы.

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

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

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

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

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

Действия

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

Границы и связи

Чтобы быть полезным, описание любого блока должно, как мини­мум, включать в себя описание объектов, которые блок создает в ре­зультате своей работы (’’выхода”), и объектов, которые блок потреб­ляет или преобразует (’’вход”).

В IDEF0 также моделируются управление и механизмы испол­нения. Под управлением понимаются объекты, воздействующие на способ, которым блок преобразует вход в выход. Механизм ис­полнения - объекты, которые непосредственно выполняют преобра­зование входа в выход, но не потребляются при этом сами по себе.

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

С (Control) - управление - ограничения и инструкции, влияю­щие на ход выполнения процесса;

О (Output) - выход - нечто, являющееся результатом выполне­ния процесса;

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

Рисунок 1. Каждый тип стрелки соединяется со своей стороной функционального блока

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

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

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

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

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

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

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

Комбинированные стрелки. В IDEF0 существует пять основных видов комбинированных стрелок: выход - вход, выход - управле­ние, выход - механизм исполнения, выход - обратная связь на управление и выход - обратная связь на вход.

Понятие «глоссарий»

Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0: диаграмм, функциональных блоков, интерфейсных дуг существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т. д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Например, для управляющей интерфейсной дуги «распоряжение об оплате» глоссарий может содержать перечень полей соответствующего дуге документа, необходимый набор виз и т. д. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.

.3 Принципы ограничения сложности IDEF0-диаграмм

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

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

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

Разумеется, строго следовать этим ограничениям вовсе необязательно, одна «к» «»о, как показывает опыт, они являются весьма практичными в реальной работе.

.4 Дисциплина групповой работы над разработкой IDEF0-модели

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

Создание модели группой специалистов, относящихся к различным сферам деятельности предприятия. Эта группа в терминах IDEF0 называется авторами (Authors). Построение первоначальной модели является динамическим процессом, в течение которого авторы опрашивают компетентных лиц о структуре различных процессов. На основе имеющихся положений, документов и результатов опросов создается черновик (Model Draft) модели.

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

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

1.6 Особенности национальной практики применения функционального моделирования средствами IDEF0

В последние годы интерес в России к методологиям семейства IDEF неуклонно растет. При этом интерес к таким стандартам, как IDEF3-5 Геннадий Верников называет теоретическим, а к IDEF0 вполне практически обоснованным. Собственно говоря, первые Case-средства, позволяющие строить DFD и IDEF0 диаграммы появились на российском рынке еще в 1996 году, одновременно с выходом популярной книги по принципам моделирования в стандартах SADT. Тем не менее, большинство руководителей до сих пор расценивают практическое применение моделирования в стандартах IDEF скорее как дань моде, нежели чем эффективный путь оптимизации существующей системы управления бизнесом. стандарты IDEF в понимании большинства стали условно неотделимы от внедрения информационных технологий, хотя с их помощью порой можно эффективно решать даже небольшие локальные задачи, буквально при помощи карандаша и бумаги.

редактор бизнес процесс модель

Заключение

В ходе выполнения курсовой работы мною были освоены знание таких элементов IDEF0 как: синтаксис графического языка, семантика языка, правила построения графических диаграмм модели, а также получены практические навыки построения модели при помощи программного инструментария AllFusion Process Modeler 7.1.1. Была разработана модель вымышленного агентства недвижимости, проведен полный анализ и полное описание всех процессов. Были выявлены все закономерности и связи, учтена иерархичность всех рассматриваемых процессов в модели. Для более наглядного отображения структуры модели было построено дерево узлов. Модель построена по типу «to be», то есть по принципу «так как должно быть». В процессе создания модели мною были исправлены некоторые недостатки, которые могут присутствовать в действительной модели агентства недвижимости. Полученная модель будет полезна лишь для руководства и сотрудников агентства, она сможет помочь выработать последовательность и правильность выполнения всех операций.