Моделирование процессов - Process modeling

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

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

Уровень абстракции для процессов[1]

Обзор

Модели процессов процессы одного и того же характера, которые вместе классифицируются в модель. Таким образом, модель процесса - это описание процесса на уровне типа. Поскольку модель процесса находится на уровне типа, процесс является ее экземпляром. Одна и та же модель процесса многократно используется для разработки многих приложений и, таким образом, имеет множество экземпляров. Одно из возможных применений модели процесса - предписать, как что-то должно / должно / могло быть сделано в отличие от самого процесса, который действительно происходит. Модель процесса - это примерно предвосхищение того, как будет выглядеть процесс. Каким будет этот процесс, будет определено во время реальной разработки системы.[2]

Цели модели процесса:

  • Описательный
    • Отслеживайте, что на самом деле происходит во время процесса
    • Возьмите точку зрения внешнего наблюдателя, который смотрит на то, как выполняется процесс, и определяет улучшения, которые необходимо внести, чтобы сделать его более эффективным или результативным.
  • Предписывающий
    • Определите желаемые процессы и то, как они должны / могут / могли бы выполняться.
    • Установите правила, руководящие принципы и модели поведения, которые, если им следовать, приведут к желаемой производительности процесса. Они могут варьироваться от строгого соблюдения до гибкого руководства.
  • Пояснительный
    • Дайте объяснения относительно обоснования процессов.
    • Изучите и оцените несколько возможных вариантов действий на основе рациональных аргументы.
    • Установите явную связь между процессами и требованиями, которым должна соответствовать модель.
    • Предварительно определяет точки, в которых данные могут быть извлечены для целей отчетности.

Цель

С теоретической точки зрения моделирование метапроцессов объясняет ключевые концепции, необходимые для описания того, что происходит в процессе разработки, что, когда это происходит и почему. С операционной точки зрения, моделирование метапроцессов направлено на предоставление рекомендаций для инженеров-методистов и разработчиков приложений.[1]

Деятельность моделирование бизнеса процесс обычно предполагает необходимость изменения процессов или выявления проблем, которые необходимо исправить. Это преобразование может потребовать, а может и не потребовать участия ИТ-специалистов, хотя это общий фактор, требующий моделирования бизнес-процесса. Управление изменениями программы желательны для реализации процессов на практике. С развитием технологий от более крупных поставщиков платформ представление о том, что модели бизнес-процессов (BPM) становятся полностью выполнимыми (с возможностью проектирования в оба конца), с каждым днем ​​становится все ближе к реальности. Вспомогательные технологии включают Единый язык моделирования (UML), управляемая моделями архитектура, и Сервис-Ориентированная Архитектура.

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

Моделирование процессов всегда было ключевым аспектом процесс реорганизации бизнеса, и подходы к постоянному совершенствованию, представленные в Шесть Сигм.

Классификация моделей процессов

По охвату

Существует пять типов покрытия, в которых термин «модель процесса» определяется по-разному:[3]

  • Ориентированный на деятельность: связанный набор действий, проводимых для конкретной цели определения продукта; набор частично упорядоченных шагов, предназначенных для достижения цели.[4]
  • Ориентированный на продукт: серия действий, которые приводят к изменению чувствительного продукта для достижения желаемого продукта.[5]
  • Ориентированный на принятие решений: набор связанных решений, принимаемых для конкретной цели определения продукта.
  • Контекстно-ориентированный: последовательность контекстов, вызывающая последовательные преобразования продукта под влиянием решения, принятого в контексте.
  • Ориентированный на стратегию: позволяет создавать модели, представляющие процессы с несколькими подходами, и планировать различные возможные способы разработки продукта на основе концепции намерения и стратегии.[6]

По выравниванию

Процессы бывают разных видов.[2] Эти определения «соответствуют различным способам моделирования процесса».

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

По степени детализации

Гранулярность относится к уровню детализации модели процесса и влияет на вид руководства, объяснения и трассировки, которые могут быть предоставлены. Грубая детализация ограничивает их довольно ограниченным уровнем детализации, тогда как мелкая детализация обеспечивает более детальные возможности. Необходимая детализация зависит от ситуации.[2]

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

Хотя обозначения для мелкозернистых моделей существуют, большинство традиционных моделей процессов представляют собой грубые описания. В идеале модели процессов должны обеспечивать широкий диапазон детализации (например, Process Weaver).[2][7]

По гибкости

Гибкость подходов к построению метода [8]

Было обнаружено, что хотя модели процессов носят предписывающий характер, на практике могут иметь место отклонения от предписаний.[6] Таким образом, рамки для принятия методов развивались так, чтобы методы разработки систем соответствовали конкретным организационным ситуациям и тем самым повышали их полезность. Разработка таких фреймворков также называется ситуационной. методология.

Подходы к построению методов могут быть организованы в диапазоне гибкости от «низкого» до «высокого».[8]

На «нижнем» конце этого спектра находятся жесткие методы, а на «верхнем» уровне - модульное построение методов. Жесткие методы полностью предопределены и оставляют мало возможностей для их адаптации к текущей ситуации. С другой стороны, модульные методы могут быть изменены и дополнены в соответствии с конкретной ситуацией. Выбор жестких методов позволяет каждому проекту выбрать свой метод из панели жестких, предопределенных методов, тогда как выбор пути внутри метода состоит из выбора подходящего пути для данной ситуации. Наконец, выбор и настройка метода позволяет каждому проекту выбирать методы из разных подходов и настраивать их в соответствии с потребностями проекта ». [9]

Качество методов

Поскольку в этой статье обсуждается качество моделей процессов, существует необходимость в разработке качества методов моделирования как важной составляющей качества моделей процессов. В большинстве существующих структур, созданных для понимания качества, граница между качеством методов моделирования и качеством моделей в результате применения этих методов четко не проводится. Этот отчет будет сосредоточен как на качестве методов моделирования процессов, так и на качестве моделей процессов, чтобы четко различать эти две модели. Для помощи в понимании качества методов моделирования процессов были разработаны различные структуры, одним из примеров является структура оценки моделирования на основе качества или известная как Q-Me структура, которая утверждала, чтобы предоставить набор четко определенных качественных свойств и процедур, чтобы сделать возможной объективную оценку этих свойств.[10]Эта структура также имеет преимущества предоставления единообразного и формального описания элемента модели в пределах одного или разных типов моделей с использованием одной техники моделирования.[10]Короче говоря, это может сделать оценку как качества продукта, так и качества процесса с помощью методов моделирования в отношении набора свойств, которые были определены ранее.

Качественные свойства, относящиеся к моделирование бизнес-процессов методы, обсуждаемые в [10] находятся:

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

Оценить качество фреймворка Q-ME; он используется для иллюстрации качества методов динамического моделирования основных элементов организации (DEMO).

Утверждается, что оценка структуры Q-ME для методов моделирования DEMO выявила недостатки Q-ME. Одна особенность заключается в том, что он не включает количественную метрику для выражения качества техники бизнес-моделирования, что затрудняет сравнение качества различных методов в общем рейтинге.

Существует также систематический подход к измерению качества методов моделирования, известный как метрики сложности, предложенный Росси и др. (1996). Методы метамодели используются в качестве основы для вычисления этих показателей сложности. По сравнению с рамками качества, предложенными Krogstie, измерение качества больше фокусируется на техническом уровне, а не на уровне отдельной модели.[11]

Авторы (Cardoso, Mendling, Neuman and Reijers, 2006) использовали показатели сложности для измерения простоты и понятности дизайна. Это подтверждается более поздними исследованиями, проведенными Мендлингом. и другие. который утверждал, что без использования показателей качества, чтобы поставить под сомнение качественные свойства модели, простой процесс можно смоделировать сложным и неподходящим способом. Это, в свою очередь, может привести к меньшей понятности, более высокой стоимости обслуживания и, возможно, к неэффективному выполнению рассматриваемого процесса.[12]

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

Качество моделей

Самые ранние модели процессов отражали динамику процесса с практическим процессом, полученным путем создания экземпляров, с точки зрения соответствующих концепций, доступных технологий, конкретных сред реализации, ограничений процесса и так далее.[13]

Было проведено огромное количество исследований качества моделей, но меньше внимания уделялось качеству моделей процессов. Проблемы качества моделей процессов не могут быть оценены исчерпывающе, однако на практике для этого есть четыре основных принципа и основы. Это: нисходящие рамки качества, восходящие метрики, относящиеся к аспектам качества, эмпирические опросы, связанные с методами моделирования, и прагматические рекомендации.[14]

Hommes процитировал Ванга и другие. (1994)[11] что все основные характеристики качества моделей можно сгруппировать в 2 группы, а именно: правильность и полезность модели, правильность варьируется от соответствия модели явлению, которое моделируется, до его соответствия синтаксическим правилам моделирования, а также является независимой цели, для которой используется модель.

Принимая во внимание, что полезность может рассматриваться как полезность модели для конкретной цели, для которой модель построена в первую очередь. Hommes также проводит дальнейшее различие между внутренней правильностью (эмпирическое, синтаксическое и семантическое качество) и внешней правильностью (валидностью).

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

Кроме того, более широкий подход должен быть основан на семиотике, а не на лингвистике, как это было сделано Krogstie с использованием нисходящей структуры качества, известной как SEQUAL.[15][16] Он определяет несколько аспектов качества, основанных на отношениях между моделью, экстернализацией знаний, предметной областью, языком моделирования и действиями по обучению, выполнению действий и моделированию.

Тем не менее, структура не предоставляет способов определения различных степеней качества, но широко использовалась для моделирования бизнес-процессов в проведенных эмпирических тестах [17]Согласно предыдущему исследованию, проведенному Moody и другие.[18] с использованием концептуальной модели качества, предложенной Линдландом и другие. (1994) для оценки качества модели процесса, три уровня качества[19] были определены:

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

В ходе исследования было замечено, что структура качества оказалась одновременно простой в использовании и полезной при оценке качества моделей процессов, однако она имела ограничения в отношении надежности и сложности для выявления дефектов. Эти ограничения привели к уточнению структуры посредством последующих исследований, проведенных Krogstie. Этот фреймворк называется Krogstie фреймворком SEQUEL. и другие. 1995 г. (дополнительно уточнено Krogstie & Jørgensen, 2002), который включал еще три аспекта качества.

  • Физическое качество: является ли экстернализованная модель устойчивой и доступной для понимания аудитории.
  • Эмпирическое качество: моделируется ли модель в соответствии с установленными правилами для данного языка.
  • Социальное качество: это касается соглашения между заинтересованными сторонами в области моделирования.

Измерения концептуальной основы качества[20]Домен моделирования - это набор всех утверждений, релевантных и правильных для описания предметной области, расширение языка - это набор всех утверждений, которые возможны с учетом грамматики и словаря используемых языков моделирования. Модель Экстернализация - это концептуальное представление предметной области.

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

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

В более поздних работах Krogstie et al.[15] заявил, что, хотя расширение структуры SEQUAL устранило некоторые ограничения исходной структуры, однако другие ограничения остаются. В частности, структура слишком статична с точки зрения семантического качества, в основном рассматривая модели, а не действия по моделированию, и сравнивая эти модели в статическую область, а не рассматривать модель как помощник для изменения области.

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

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

Дальнейшие работы Krogstie и другие. (2006) пересмотреть структуру SEQUAL, чтобы она больше подходила для моделей активных процессов, переопределив физическое качество с более узкой интерпретацией, чем предыдущие исследования.[15]

Другая используемая структура - Guidelines of Modeling (GoM). [21] Основанные на общих принципах бухгалтерского учета, включают шесть принципов: Корректность, Ясность касается понятности и ясности (системного описания) модельных систем. Понятность относится к графическому расположению информационных объектов и, следовательно, поддерживает способность модели понимать. модели и представляемой ситуации. Сопоставимость включает в себя способность сравнивать модели, то есть семантическое сравнение двух моделей: экономическая эффективность; произведенные затраты на процесс проектирования должны по крайней мере покрываться за счет предлагаемого сокращения затрат и увеличения доходов.

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

Две структуры SEQUAL и GOM имеют ограничение использования в том, что они не могут использоваться людьми, не компетентными в моделировании. Они предоставляют основные показатели качества, но их нелегко применить неспециалистам.

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

Большинство проведенных экспериментов касаются взаимосвязи между показателями и аспектами качества, и эти работы были выполнены разными авторами индивидуально: Canfora et al. изучать связь, в основном, между метриками подсчета (например, количеством задач или разделений - и ремонтопригодностью моделей программных процессов);[22] Кардосо подтверждает корреляцию между сложностью потока управления и воспринимаемой сложностью; и Mendling et al. использовать метрики для прогнозирования ошибок потока управления, например тупиковых ситуаций в моделях процессов.[12][23]

Результаты показывают, что увеличение размера модели снижает ее качество и понятность. Дальнейшая работа Mendling et al. исследует связь между метриками и пониманием [24] и[25] В то время как некоторые метрики подтверждены относительно их эффекта, также личные факторы моделировщика, такие как компетентность, оказываются важными для понимания моделей.

Несколько проведенных эмпирических исследований до сих пор не дают четких руководящих принципов или способов оценки качества моделей процессов, но необходимо иметь четкий набор руководящих принципов, которыми могли бы руководствоваться разработчики моделей в этой задаче. Прагматические рекомендации были предложены разными практиками, хотя трудно дать исчерпывающий отчет о таких рекомендациях на практике.[26] Обобщены 10 советов по моделированию процессов, дано множество технических определений и правил, но они не учит, как создавать модели процессов, которые эффективны в их основной миссии - максимизации общего понимания процесса как есть или как будет. руководящие принципы нелегко применить на практике, но правило «обозначать действия глагол – существительное» было предложено другими практиками раньше и проанализировано эмпирически. На основе исследования.[27] Ценность моделей процессов зависит не только от выбора графических конструкций, но и от их аннотации с текстовыми метками, которые необходимо анализировать. Было обнаружено, что это приводит к лучшим моделям с точки зрения понимания, чем альтернативные стили маркировки.

Из более ранних исследований и способов оценки качества модели процесса было замечено, что размер модели процесса, структура, опыт моделиста и модульность влияют на ее общую понятность.[24][28] На основе этого был представлен набор рекомендаций.[29] 7 Руководство по моделированию процессов (7PMG). В этом руководстве используется стиль «глагол-объект», а также рекомендации по количеству элементов в модели, применению структурированного моделирования и декомпозиции модели процесса. Рекомендации следующие:

  • G1 Минимизировать количество элементов в модели
  • G2 Минимизируйте пути маршрутизации на элемент
  • G3 Используйте одно начальное и одно конечное событие
  • Модель G4 максимально структурирована
  • G5 Избегайте элементов маршрутизации OR
  • G6 Использовать метки действий глагол-объект
  • G7 Разобрать модель с более чем 50 элементами

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

Это можно рассматривать, с одной стороны, как необходимость более широкого привлечения опыта разработчиков моделей процессов, но также возникает вопрос, какие альтернативные подходы могут быть доступны для выработки руководящих указаний по приоритизации?[29]

Смотрите также

Рекомендации

  1. ^ а б Колетт Роллан (1993). Моделирование процесса разработки требований. 3-й европейско-японский семинар по информационному моделированию и базам знаний.
  2. ^ а б c d Колетт Роллан и Перничи, К. Танос (1998). Комплексный взгляд на технологический процесс. Материалы 10-й Международной конференции CAiSE'98.. Б. Конспект лекций по информатике 1413. Springer.
  3. ^ М. Доусон (1998). Итерация в программном процессе, Proc 9th Int. Конф. по программной инженерии.
  4. ^ P.H. Фейлер и W.S. Хамфри. (1993). Разработка и внедрение программного процесса: концепции и определения, Proc. 2-й Int. Конф. по «Программному процессу»
  5. ^ Sianipar, C.P.M .; Юдоко, G .; Dowaki, K .; Адхиутама, А. (2014). «Физиологическая концепция: визуальное моделирование для осуществимого дизайна». Прикладная механика и материалы. 493: 432–437. Дои:10.4028 / www.scientific.net / AMM.493.432. S2CID  109776405.
  6. ^ а б Колетт Роллан (1994). Многомодельный взгляд на моделирование процессов. Разработка требований. Том 4, № 4. Springer-Verlag.
  7. ^ К. Фернстрем и Л. Олссон (1991). Потребности в интеграции в технологических средах, Proc. 1-й Int. Конф. о программном процессе. Пресса компьютерного общества IEEE.
  8. ^ а б А.Ф. Хармсен, Сяак Бринкемпер и J.L.H. Оэй (1994). Ситуационная разработка методов для информационных систем проектных подходов. Северная Голландия
  9. ^ Колетт Роллан (1997). «Учебник по методологии. Материалы конференции ИНФОРСИД.
  10. ^ а б c Б.Дж. Хоммес, В. Ван Рейсвуд, Оценка качества методов моделирования бизнес-процессов - Материалы 33-й Гавайской международной конференции по системным наукам - 2000
  11. ^ а б Барт-Ян Хоммес, Оценка методик моделирования бизнес-процессов, кандидатская диссертация ТУ Делфт 2004
  12. ^ а б Дж. Мендлинг, М. Мозер, Дж. Нойман, Х. Вербеек, Б. Донген, В. ван дер Аалст, Количественный анализ неисправных EPC в эталонной модели SAP, Отчет BPM-центра BPM-06-08, BPMCenter.org , 2006.
  13. ^ Материалы 9-й международной конференции по программной инженерии
  14. ^ Mendling, J .; Reijers, H.A .; ван дер Аалст, В. М. П. (2010). «Семь руководств по моделированию процессов (7PMG)». Информационные и программные технологии. 52 (2): 127–136. CiteSeerX  10.1.1.150.7953. Дои:10.1016 / j.infsof.2009.08.004.
  15. ^ а б c Krogstie, J .; Sindre, G .; Йоргенсен, Х. (2006). «Модели процессов, представляющие знания для действий: пересмотренные рамки качества». Европейский журнал информационных систем. 15 (1): 91–102. Дои:10.1057 / palgrave.ejis.3000598. S2CID  16574846.
  16. ^ Lindland, O .; Sindre, G .; Сёльвберг, А. (1994). «Понимание качества в концептуальном моделировании». Программное обеспечение IEEE. 11 (2): 42–49. Дои:10.1109/52.268955. S2CID  14677730.
  17. ^ Д. Муди, Г. Синдре, Т. Брасетвик и А. Сёльвберг, Оценка качества моделей процессов: эмпирическое тестирование структуры качества. В: S. Spaccapietra, S.T. Марч и Ю. Камбаяши, редакторы, Концептуальное моделирование - ER 2002, 21-я Международная конференция по концептуальному моделированию, Тампере, Финляндия, 7–11 октября 2002 г., Материалы лекций по информатике, т. 2503, Springer (2002), стр. 380–396.
  18. ^ Дэниел Л. Муди, Г. Синдре, Т. Брасетвик, А. Сёльвберг. Оценка качества моделей процессов: эмпирическое тестирование структуры качества
  19. ^ Моррис, К. У. (1970). Основы теории знаков. Чикаго: Издательство Чикагского университета.
  20. ^ J. Krogstie, О. Линдланд, Г. Синдре, Определение аспектов качества для концептуальных моделей, в: Proc. IFIP8.1 Рабочая конференция по концепциям информационных систем: на пути к консолидации взглядов, Марбург, Германия, 1995.
  21. ^ Дж. Беккер, М. Роземанн и К. Утманн, Руководящие принципы моделирования бизнес-процессов. В: W. van der Aalst, J. Desel и A. Oberweis, редакторы, Business Process Management. Модели, методы и эмпирические исследования, Springer, Berlin (2000), стр. 30–49.
  22. ^ Canfora, G .; Garcia, F .; Piattini, M .; Руис, Ф .; Визаджио, К. (2005). «Семейство экспериментов для проверки показателей для моделей программных процессов». Журнал систем и программного обеспечения. 77 (2): 113–129. Дои:10.1016 / j.jss.2004.11.007.
  23. ^ Дж. Мендлинг, Обнаружение и прогнозирование ошибок в моделях бизнес-процессов epc, Ph.D. дипломная работа Венского университета экономики и делового администрирования, http://wi.wu-wien.ac.at/home/mendling/publications/Mendling%20Doctoral%20thesis.pdf В архиве 2011-07-17 на Wayback Machine, 2007.
  24. ^ а б Дж. Мендлинг, Х.А. Рейджерс и Дж. Кардосо, Что делает модели процессов понятными? В: Г. Алонсо, П. Дадам и М. Роземанн, редакторы, Business Process Management, 5-я международная конференция, BPM 2007, Брисбен, Австралия, 24–28 сентября 2007 г., Proceedings, Lecture Notes in Computer Science vol. 4714, Springer, Брисбен, Австралия (2007), стр. 48–63.
  25. ^ Дж. Мендлинг и М. Стрембек, Факторы влияния на понимание моделей бизнес-процессов. В: В. Абрамович и Д.Фенсель, редакторы, Труды 11-й Международной конференции по системам бизнес-информации (BIS 2008), Lecture Notes in Business Information Processing vol. 7, Springer-Verlag (2008), стр. 142153.
  26. ^ Б. Сильвер, Десять советов по эффективному моделированию процессов, BPMInstitute.org, <http://www.bpminstitute.org/articles/article/article/bpms-watch-ten-tips-for-effective-process-modeling.html >, Среда, 30 января 2008 г.
  27. ^ Дж. Мендлинг, Х.А. Рейджерс, Дж. Реккер, Маркировка деятельности в моделировании процессов: эмпирические наблюдения и рекомендации, информационные системы. URL: <http://eprints.qut.edu.au/19625/ >
  28. ^ H. A. Reijers, J. Mendling, Модульность в моделях процессов: обзор и эффекты в: M. Dumas, M. Reichert, M.-C. Шан (ред.), Управление бизнес-процессами BPM 2008, Vol. 5240 конспектов лекций по информатике, Springer, Милан, Италия, 2008 г., стр. 20-35
  29. ^ а б Дж. Мендлинг, Х. А. Рейерс, В. М. П. ван дер Аалст, Семь рекомендаций по моделированию процессов (7pmg), отчет QUT ePrints 12340, Технологический университет Квинсленда (2008)

внешняя ссылка