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

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

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

Введение

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. Методология функционального моделирования IDEF0

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 представляют систему как множе-ство иерархических (вложенных) функций, в первую очередь должна быть определена функция, описывающая систему в целом -- контек-стная функция. Функции изображаются на диаграммах как поимено-ванные прямоугольники, или функциональные блоки. Имена функ-ций в IDEF0 подбираются по сходным правилам с именами действий в IDEF3 -- с использованием глаголов или отглагольных существи-тельных. Важно подбирать имена таким образом, чтобы они отражали систему так, как если бы она обозревалась с точки зрения, выбранной для моделирования.

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

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

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

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

I (Input) -- вход -- нечто, что потребляется в ходе выполнения процесса;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

Размещено на Allbest.ru