Моделирование бизнес-процессов в рамках текстовой нотации, базирующейся на использовании концепции use cases А. Коберна.

Оглавление
Введение 3
1. Применение концепции UC для моделирования бизнес-процессов. 5
2. Преимущество и недостатки текстовой нотации в сравнении со стандартными графическими нотациями. 23
3. Организация связи между разнородными элементами модели бизнес-процесса (аналогично трассировке требований в рамках Rational RequisitePro) 29
4. Разработка шаблона для создания текстового описания процесса. 35
5 Заключение 43
6 Список литературы 44

Постусловия могут быть классифицированы как минимальные гарантии или гарантии успеха. Минимальная гарантия представляет условие, которое будет истинным при окончании варианта использования, независимо от того, как он завершается. Гарантия успеха представляет условие, которое будет истинным, если вариант использования завершается успешно, независимо от того, каким образом это произошло (какой путь при этом был выбран).Ни предусловия, ни постусловия не следует использовать для создания последовательности вариантов использования. Как правило такая ситуация может возникнуть, когда мы вынуждены выполнить один вариант использования, а затем другой в некотором многозначном потоке событий. ПостусловияСистема ожидает взаимодействия с пользователемСобытие, после которого начинается сценарий использования – Триггер. Он должен закончить фразу «Этот сценарий использования начинается когда..»ТриггерЗаказчик нажимает кнопку «Пополнить счет»Основной сценарий не содержит каких-либо условий или ветвлений.Основной сценарийЗаказчик видит форму, содержащую нажимаемые кнопки способов оплат и кнопки «Далее» (не активна до выбора способа оплаты) и «Отмена», с предложением выбрать удобный для него способ оплаты, варианты: а) Банковская карта, б) Яндекс Деньги, в) наличными.…РезультатСчет Заказчика пополнен на указанную им сумму.Хорошо. Но что мы будем делать, если у нас несколько сценариев и, следовательно, несколько конечных результатов?Когда у нас несколько конечных результатов при различных сценариях, тогда мы имеем несколько сценариев использования. Исключения описывают те ситуации, которые нарушают протекание определенного (в нашем случае основного) сценария использования. Продолжим.Исключения (или Расширения)5а Заказчик не заполнил необходимые параметры платежа и нажал «Оплатить».5а1 Заказчик видит сообщение «Введите необходимые параметры»5б Заказчик вновь видит форму Параметров платежа, на которой необходимые, но не заполненные, поля выделены красным.5в Не удалось провести платеж – Заказчик видит сообщение о неудачной проводке. Баланс Заказчика не изменяется.Чтобы описать процесс после выбора события не соответствующего основному варианту использования (к примеру, процесс после нажатия кнопки «Отмена»,) пишем другой другой вариант использования. А связь с основного варианта использования с альтернативными вариантами осуществляется через ссылку на другой вариант подчеркиванием. Например, пользователь сохраняет отчёт (значит есть альтернативный вариант «Сохранить отчет»). На условие запуска альтернативного варианта указывает триггер в каждом варианте.Альтернативные вариантыа). Заказчик нажимает кнопку «Отмена».б). Заказчик перенаправляется на страницу «Мой счет».с). Заказчик нажимает кнопку «Назад»Поскольку, исследуя каждое требование более детально, мы можем найти большое количество изменений. Усложнение конечного результата и изменения в одном UC, моделирующем требования, приводит к изменениям в других. Следовательно, нужно выбрать гибкий и эффективный метод написанияUC, для полного исключения ненужной работы и переписывания.Итеративный подход, гдеUC непрерывно оцениваются перед добавлением деталей, является эффективным способом написания таких UC. В данном подходе затрагиваются два аспекта: написание набора (группы) UC и написание конкретного UC.Написание набора (группы) вариантов использованияВарианты использованиясуществуя в группе, образуют довольно тесные и важные для анализа отношения между различными юзкейсамии действующими лицами. Узнавая больше о системных взаимодействиях, мы получаем больше информации о действующих лицах, и наоборот. Можно сделать вывод, что написание нескольких юзкейсов одновременно (совместно) является более эффективным методом, чем последовательное их написание. Группировать можно, к примеру: по действующему лицу, по версии, по предметной области.Написание конкретных (отдельных) вариантов использования.Подобным образом стоит писать и каждый отдельный юзкейс, т.е. итеративно. Начиная с основного сценария, затем мы устанавливаем различные альтернативные потоки (альтернативные варианты) и потоки исключений (исключения, которым вариант использования иногда следует), далее мы оцениваем, правим или вовсе исключаем их и, наконец, добавляем подробности (детали) для уже существующих сценариев.Как определить альтернативные сценарииВариант использования состоит из набора сценариев, каждый из которых в свою очередь представляет собойконкретный случай, соответствующий особенным входам от действующего лица либо особенным условиям внешней среды. Каждый сценарий описывает альтернативный сценарий, которому система должна следовать, либо провальный, либо исключительный вариант - исключения.Когда мы детализируем основной сценарий, то попытаемся установить альтернативные сценарии, задаваясь следующими вопросами:- Существуют ли какие-нибудь различные доступные функции, которые зависят от того, какое действие совершит действующее лицо (какие данные введет действующее лицо либо какой выбор он сделает)? (К примеру, что произойдет, если действующее лицо введет неправильный PIN код при авторизации в банкомате)- Какие бизнес-правила могут считаться полезными и нужными? (К примеру, действующее лицо запрашивает в банкомате сумму большую, чем доступную для списания с его счета)- Что могло бы иметь неправильный ход развития? (Здесь идет речь о таких случаях, как например, отсутствие сетевого соединения на момент запроса выполнения какой-либо операции)Самым эффективным способом разработки таких сценариев является итеративный способ, где необходимо начинать с их определения (выявления). Нужно исследовать любой возможный вариант сценарий для того, чтобы понять,может ли он являться важным, уместным, отличным от других, имеющим ожидаемый результат и отношение к рассматриваемой теме. Требуется исключить повторяющиеся или лишние сценарии, а потом приступить к подробной проработкенаиболее важных сценариев.Нужно структурировать каждый юзкейс в соответствии сценариям. Это может упростить распространение и поддержание вариантов использования, а также разрешить их реализацию итеративно.В добавлении к структурированию вариантов использования в соответствии со сценариями, нередко бывает полезным структурировать сами сценарии по подпотокам (вариант использования CRUID). Это может обеспечивать дополнительный уровень градации при планировании работ и отслеживании прогресса. Если только подпоток не затрагивает незначительную часть законченного потока событий, которые часто описываются в теле потока, то рекомендуется описывать каждый подпоток в отдельном разделе общего раздела потока событий. Примеры подпотоков, которые размещаются в отдельном разделе:Подпотоки, занимающие большую часть в потоке событий.Альтернативные потоки событий и потоки исключений. Это поможет отделить основной поток событий варианта использования от дополнительных потоков более четко.Любой подпоток, который выполняется в различные интервалы времени в том же самом потоке событий.Особые требованияК тому же следует включить всевозможные требования, которые относятся к варианту использования, но не учитываются при анализе потока событий. Такие требования, возможно, считаются нефункциональными.В основном нефункциональные требования, относящиеся к специфичному варианту использования, располагают в разделе особых требований такого варианта использования. Вносит требования в систему человек. Если требование в той или иной формулировке уже присутствует в системе, то заново его не заносят, а отмечают, как дублирующее. Так как поиск схожих требований вручную является сложной и довольно затратной задачей, требующей постоянного участия аналитика, то в процессе управления требованиями именно автоматизирование этого процесса необходимо сделать в первую очередь. Для реализации возможности поиска и повторного использования требований необходима разработка методики идентификации требований, которые представлены текстом на естественном языке. Тогда, представив требование еще и как совокупность некоторых понятий, станет возможным выполнение поиска сходных требований и использование повторно созданных артефактов в ходе реализации требований – в данном случае под артефактами понимается жизненный цикл требования, а не только исходный код, использование которого повторно иногда невозможно из-за специфики задач. При разработке нескольких продуктов для одной предметной области это становится актуально. К примеру, при работе системы электронного документооборота на разных предприятиях иногда имеет место ситуация, где на нескольких предприятиях разные документы проходят одинаковые маршруты в процессе жизненного цикла, и функциональность, реализующая такие маршруты могла бы быть использована повторно, даже без полного копирования.Разработкашаблонадлясозданиятекстовогоописанияпроцесса.Нет никакого готового стандартного шаблона для документации детальных сценариев использования. Всё зависит от проекта. Попробуем с учетом рекомендаций [1] составить шаблон.Номер:например, UC2.1Название:покупка товараОсновное действующее лицо:например, ПокупательОбласть действия:например, работа магазинаУровень:например,обобщенныйВерсия:например,1-яКонтекст использования:например, Покупатель хочет купить товарПредусловия:например, магазин открытПостусловия:например, отбит чекТриггер:например, Покупатель заходит в магазинОсновной сценарий:1.2.n.Расширения:Частота событий: например, много раз в деньРезультат успеха:например, Покупка сделана, получен чек, Покупатель выходит из магазинаМинимальная гарантия:Участники и интересы:Бизнес правила: например,Фрукты и овощи не обмениваются.Используемые описания данных:Владелец:Открытые вопросы:например,Сколько человек требуется в очереди, чтобы подключить для расчета вторую кассуШаблон мы написали, теперь попробуем составить текстовую нотацию нашего собственного бизнес-процесса по написанному выше шаблону. Рассмотрим, для примера, предприятие в котором используется ERPсистема 1С.Требуется фиксировать заявки пользователей по любым вопросам, связанным с не нормальной работой компьютерного оборудования. Предварительно была нарисована нотация в ARIS в нотации EPC[12] (файл приложен к заданию) и рассмотрен данный бизнес процесс в моделях IDEF0 и IDEF3 раньше в данной работы. Обзор бизнес-процесса в разных моделях позволит намсравнить методики моделирования по отношению к текстовой нотации. (рисунок 4.1). Предполагается несколько вариантов: общий и детализированные.Номер:UC2.1Название:Обработка заявки пользователейОсновное действующее лицо:Инициатор запросаОбласть действия:Предприятие СтройпаркУровень:обобщенныйВерсия:1.0Участники и интересы: Инициатор запроса хочет наибыстрейшее решение проблемы.Компания хочет понимать какие проблемы, текущие у пользователейСотрудникподдержки хочет уложиться в сроки решения заявкиПредусловия:Инициатор запроса не смог получить помощь среди близких коллег. Сотрудник поддержки должен просматривать заявки периодически. Постусловия:Получено сообщение из системы со статусом «Решено»Минимальные гарантии: Заявки попадают в общую базу, зарегистрированы и обязаны быть рассмотрены группой поддержки по внутренним правилам компании.Триггер:возникла проблемаОсновной сценарий:Инициатор запроса: инициирует заявкуСотрудник поддержки: изучает заявку3.Сотрудник поддержки:решает заявку в рамках допустимого фиксированного времени.4. Сотрудник поддержки:закрывает заявку.5. Инициатор запроса проверяет решение и подтверждает решение заявки.6. Компания: фиксирует в базе данных заявку. Расширения:1а.Инициатор запроса не знает, что делать при проблеме – спросить коллегу в своем или в соседнем кабинете.1б. Инициатор запроса звонит по телефону сотруднику поддержки и требует решить проблему – отказывать и просить не отклоняться от процесса, кроме серьезных проблем.2a. Сотрудник поддержки не знает, как решить заявку – спросить у коллег.2б. Сотрудник поддержки понимает, что проблема требует вмешательства программиста и переводит заявку на программиста.2в. Сотрудник поддержки понимает, что заявку решить технически невозможно или нельзя по каким-либо причинам – отклонение заявки.3а. У сотрудника поддержки во время решения заявки возникают вопросы к инициатору запроса – звонит по телефону, пишет в комментариях в форме заявки.3б. Сотрудник поддержки не успел решить заявку в срок – вопрос открыт5а. Решение не устраивает инициатора запроса – звонит по телефону и просит поправить или пишет электронное письмо сотруднику поддержки, отклоняет решение заявки, и заявка возвращается в обработку.Частота событий: много раз в деньОсновной канал для основного действующего лица: Электронная почта MSOutlookРезультат успеха:Проблема решена.Результат неуспеха: проблема решается больше времени регламентаБизнес правила: Правила подачи заявки пользователем строго определены и однозначны в соответствии с регламентом компанииИспользуемые описания данных:Владелец данного процесса: Самойлов О.Г.Дополнительные каналы связи для действующих лиц: телефон, почтаВызывающие варианты использования:инициация заявки, решение заявки, закрытие заявки, перевод заявки на другого сотрудника, подтверждение заявки, отклонение заявки.Открытые вопросы:Что является серьезным инцидентом, а что не является?Сотрудник поддержки не успел решить заявку в срок.Рисунок 4.1 – Модель в ARISв нотации EPCТаблица 4.1. №Критерий сравненияIDEF0IDEF3ARIS (нотация EPC)Текстоваянотация1Строгая параллельность событийНет Есть. Операторы: и, или, искл.или. Также двойная стрелка показывает синхронность.НетНет. Но можно написать в тексте, что те или иные события должны выполняться параллельно.2Альтернативный процессНетНетЕсть. Есть. Расширения3Используемое оборудование и участники процессаЕсть. Стрелка снизуНетЕсть блок для действующих лицДействующее лицо, участники процесса.4Контроль выполнения процедурыЕсть. Стрелка сверхуНетНет.Нет5Требуется делить процесс. Кол-во функциональных блоков вмещается на определенном уровне штук 9Процесс, как правило, описывается вертикально, поэтому достаточно блоков можно вместитьПроцесс описывается в определенном месте: Основной сценарий и Расширения. 6УсловияНетНетУсловий нет, в качестве условий служат функциональные блоки: с одним течением события и блок с другим течением события.Есть. Расширения.7Удобство интерфейсаДа, визуально видно с первого взгляда откуда и куда движется процесс по модели.Визуально, зная и соблюдая правила и ограничения метода EPC, понятен процесс.Нет. Чтобы понять процесс, требуется последовательно пройтись по модели.5 ЗаключениеВ результате данной работы мы смоделировали наш бизнес-процесс в двух графических методологиях: IDEF0, IDEF3 и построили текстовую модель. Во время построения моделей, мы сравнили их, различия выписав в таблицу. После проделанной работы, напрашивается вывод, что нет лучшей или худшей методологии моделирования, есть определенные бизнес-процессы, к которым подходит та или иная нотация.Следовательно, выбирая средства моделирования бизнес-процессов, следует исходить из определенной сложившейся ситуации, которая будет подвергаться моделированию. При этом необходимо учитывать требования, которые предъявляются конкретно в данной ситуации отдельно к методу, отдельно к применяемой нотации в моделировании, а также отдельно к инструментальному средству.6Список литературыСовременные методы описания функциональных требований к системам. АлистерКоберн, 2001 г.https://habrahabr.ru/post/74330/http://www.caseclub.ru/articles/use_case.htmlПроцессорный подход к управлению. Репин В.В., Елиферов В.Г. Процессный подход к управлению/«Стандарты и качество», 2004.Введение в формальные методы описания бизнес-процессов. Кулябов Д.С., Королькова А.В./РУДН.2008 г.Черемных С. В., Семёнов И. О., Ручкин В. С. Структурный анализ систем: IDEF-технологии. — М.: Финансы и статистика, 2001.Методы и средства моделирования бизнес-процессов(обзор). Jet infoИнформационный бюллетень №10(137)/2004 г.Вендров А.М. CASE-технологииКоберн А. Современные методы описания функциональных требований к системам.Бондаренко М.Ф. Маторин С.И. Моделирование и проектирование безнсе-систем: методы, стандарты, технологии. /Компания СМИТ, 2004 г, 272 с.http://ecm-journal.ru/post/Glava-2-Notacija-IDEF0-ili-matrjoshka-dlja-biznes-analitika.aspxАвгуст – Вильгельм Шеер. ARIS – Моделирование бизнес-процессов., 2008 г.ОсновыработысAllFusionProcessModeler.http://venec.ulstu.ru/lib/disk/2015/46.pdfФаулер М., Скот К. UML в кратком изложении. Применение стандартного языка объектного моделирования/ Пер.сангл-М.:Мир, 1999.-191 с.