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

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



...

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

Основное назначение средств бизнес-моделирования — возможность обеспечения понимания функционирования бизнес-процессов организации на всех ее уровнях. Бизнес-модель может дать целостную картину жизнедеятельности компании, согласовывать разные точки зрения на постоянно развивающуюся ее деятельность. Для наглядной демонстрации бизнес-процессов компании, анализа её архитектуры в целом и принятия решений об оптимизации её деятельности имеются специальные методики и языки моделирования. Сегодня повсеместно наблюдается появление множества других языков или методологий, которые ориентированы на описание бизнес-процессов [8]. При этом такие методологии содержат собственный отличный язык. Такое количество методологий привело к некоторому замешательству среди конечных пользователей, применяющие таки е технологии для своей организации. Поэтому и возникает кажущаяся сложность применения процессных технологий.
В конце 1990-х Ивар Якобсон, позже один из авторов Унифицированного Языка Моделирования (UML), в первый раз сформулировал методику визуального моделирования для описания сценариев использования. В начале он применял несколько другие определения -англ. Usage scenarios и usage case, но ни один из них не был привычным для английского языка. И в финале он пришел к термину UC сценарий использования или вариант использования. После создания им методики моделирования юзкейсов многие продолжили его начинания, улучшая эту методику. Одни из них были: Курта Биттнера, Алистера Кокберна, Ганнэра Овергарда, и Джери Шнайдера.
В течение 1990-ых юзкейсы стали любимым методом и одной из самых известных методик документирования функциональных требований, особенно в объектно-ориентированной среде, откуда они и произошли. Но их использование этим не ограничивается, поскольку варианты использования не являются объектно-ориентированными по своей природе.

















1. Применение концепции UC для моделирования бизнес-процессов.

Бизнес-процесс может определяться логически завершённым набором взаимосвязано - взаимодействующих видов деятельности, поддерживающим функционирование компании и реализующим её политику, которая направлена на решение конкретных задач и достижение поставленных целей [4].
Бизнес-модель представляет из себя формализованное (графическое, табличное, текстовое, символьное) описание бизнес-процессов, которое отражает деятельность предприятия, которая в действительности существует или предполагается [4].
В настоящее время существует большое количество методологий описания бизнес процессов, рассмотрим ниже некоторые из них. Для начала рассмотрим концепцию UC описания бизнес процессов с помощью текста на основе которой мы и будем смотреть на другие методики.
Основная цель описания бизнес процесса – это соответствие некоторым требованиям проектируемого процесса. К примеру, у заказчика есть ряд требований, которые должен исполнять бизнес процесс. Моделирование бизнес процесса – это и есть понятное описание. Понятное разным группам, используемых бизнес-процесс. В итоге модели создавались и создаются для более правильного и четкого понимания всех участников бизнес процесса на базе выбранной модели. Помимо «понятности для всех», модель должна быть удобной для изменений (чтобы незначительные изменения не стали причиной составления всей модели заново),
Управление требованиями — процесс, который включает идентификацию, выявление, документацию, анализ, отслеживание, пиритизацию требований, достижение соглашений по требованиям и затем управление изменениями и уведомление заинтересованных лиц. Управление требованиями — непрерывный процесс на протяжении всего его жизненного цикла.
Требование — это всевозможное условие, которому необходимо соответствие разрабатываемой системы или бизнес процесса. Под требованием понимается возможность, которой система обладает, и ограничение, которому она удовлетворяет[9].
Существует 3 основных подхода к описанию бизнес-процессов: текстовый, табличный, графический.
Текстовый подход.
Для более точного выявления правильного хода работы системы, все чаще используется описание функциональности системы через варианты использования (Use Case или прецеденты).
UC (далее UC) –с перевода, с английского языка, вариант использования.
Вариант использования (или сценарий использования) – это форма описания в виде набора сценариев в зависимости от определенных запросов и условий, описывающих поведение рассматриваемой системы(SuD), когда действующее лицо взаимодействует с системой. Системой может быть прикладная программа, предприятие, автомобиль и т.д. Пример, если вариант использования описывает требование к поведению части программного обеспечения (ПО): здесь SuD – компьютерная программа
Менее формальное определение может быть таким: сценарий использования – это список шагов, который определяет, как пользователь взаимодействует с бизнесом или системой, имея в виду значение, которое это взаимодействие обеспечивает пользователю или другим заинтересованным сторонам. Еще проще: сценарий использования – это история о том, как бизнес или система и пользователи взаимодействуют.
Для представления структуры варианта использования, Коберн предложил модель «полосатых брюк» (рисунок 1.1). «Ремень брюк» – цель варианта использования, которая «держит» все сценарии. «Полосы» – индивидуальные сценарии, характеризуемые условием их наступления и результатом. Множество «Полосы» разделены на две группы – достигающие цели и не достигающие цели. Основным сценарием в данной модели является наиболее простой сценарий, в котором все промежуточные цели достигаются. Все остальные сценарии являются альтернативными. Альтернативные сценарии делятся на восстанавливаемые (если одна или несколько промежуточных целей не были достигнуты, но итоговая цель была достигнута) и неудачные (итоговая цель не была достигнута).

- Область действия (Scope): какова на самом деле рассматриваемая цель?- Предусловия и гарантии (Preconditions and guarantees): то, что должно быть истинным до и после реализации варианта использования.- Основной сценарий (Main success scenario): вариант, в котором не возникает никаких ошибок.- Расширения (Extensions): различные отклонения от основного сценария. Номера расширений соответствуют номерам шагов основного сценария, в которых обнаруживаются данные отклонения (в дальнейшем примере будет понятно).Когда один вариант использования ссылается на другой, последний подчеркивается.Каждый сценарий использования сосредотачивается на описании того, как достигнуть цели или задачи. Для большинства бизнес проектов это означает, что потребуется множество сценариев использования чтобы определитьнеобходимый набор свойств новой системы. Степень формальности программного проекта и его стадии будет влиять на необходимый уровень детализации, для каждого сценария использования. Сценарии использования не должны путаться с понятием свойств системы Сценарий использования может быть связан с одним или более свойством системы, и свойство может быть связано с одним или более сценарием использования. Сценарии использования рассматривают систему как «черный ящик», и взаимодействия с системой, включая системные ответы, описываются с точки зрения внешнего наблюдателя. Это — преднамеренная политика, потому что это вынуждает автора сосредоточиться на том, что система должна сделать, а не, как это должно быть сделано, и позволяет избегать создания предположений о том, как функциональные возможности будут реализованы.Сценарии использования могут быть описаны на абстрактном уровне (деловой сценарий использования, иногда называемый ключевым сценарием использования), или на системном уровне (системный сценарий использования). Различия между ними — в деталях.Деловой сценарий использования не затрагивает технологий, рассматривает систему как «черный ящик и описывает бизнес-процесс, который используется действующими лицами (людьми, или системами, внешними бизнесу) для достижения своих целей (например, обработка оплаты, одобрение авансового отчета, управляет корпоративным недвижимым имуществом). Деловой сценарий использования описывает процесс, ценный для делового агента, описывает что именно делает процесс.Системный сценарий использования обычно описывается на уровне функций системы (например, создайте ваучер), и определяет функцию или сервис, предоставляемые системой для пользователя. Системный сценарий использования описывает что актер может сделать, взаимодействуя с системой. По этой причине рекомендуется, чтобы системные случаи использования началась с глагола (например, создайте ваучер, выберите платежи, отмените ваучер).Приведем пример сценария бизнес-процесса. SuD – это работа компании. Это основной сценарий Пример 1.[1]Пример 1. Обработка заявленияОбласть действия: работа страховой компанииУровень: обобщенный для бизнесаВерсия: будущаяСтатус: набросокРевизия: текущаяКонтекст использования: оценщик обрабатывает заявлениеПредусловия: понесен ущербТриггер: заявление подано в страховую компаниюОсновной сценарий:1.Стороная заявителя, знающая о событии, регистрирует ущерб в страховой компании.2.Служащий принимает и распределяет заявление оценщику.3. Назначенный оценщик: проводит расследованиеоценивает сумму возмещения ущербаопределяет резервыведет переговоры по заявлениюдоговаривается о сумме возмещения и закрывает заявлениеРасширения: последуют в дальнейшемГарантия успеха: устанавливается сумма возмещения и дело закрываетсяМинимальная гарантия: нетУчастники и интересы:Подразделения страховой компании, продающие ее страховые полисыКлиенты страховой компании, покупающие полисыМинистерство страхования, осуществляющее руководство рынком страховых услугПретенденты, понесшие ущерб в результате действия застрахованного лицаОтдел заявлений страховой компанииБудущие клиентыПример 2.Ниже следует еще один вариант использования, в котором область действия всё еще является работой компании. Однако цель находится на более низком уровне, чем в прошлом примере. Здесь описывается работа оценщика.Область действия: работа страховой компанииУровень: обобщенный для бизнесаВерсия: будущаяСтатус: набросокРевизия: текущаяКонтекст использования: оценщик производит всестороннюю оценкуПредусловия: заявление принятоТриггер: заявление принятоОсновной сценарий:1.Оценщик просматривает и оценивает медицинские отчеты, документы, не арестованное имущество, процент выплат на данное имущество. 2.Оценщик определяет сумму возмещения3.Оценщик проверяет резервы, чтобы справиться о состоянии уплатить сумму.4.Оценщик приобщает к делу документы5. Оценщик прикладывает к делу документы 6. Оценщик посылает документацию заинтересованным людямРасширения: Частота событий: оценивается каждое заявление; это может происходить несколько раз в день.Гарантия успеха: заявление оценивается и определяются пределы величины возмещения.Минимальная гарантия: прежде чем начнется повторная оценка заявления для урегулирования претензий, будет произведено дополнительное расследование или составлено медицинское заключение.Участники и интересы:Претендент – хочет получить максимальную выгоду возмещения.Оценщик – хочет установить минимально допустимую сумму возмещения.Страховая компания – то же самое.Поверенный (защита и обвинение).Государственная служба отслеживания соблюдения законности и строгого соблюдения процедур.Как видно из примера 2. Каждый UC указывает основное действующее лицо- участника процесса, преследующего некоторую цель и инициировавшего для этого взаимодействие с системой.Преимущество и недостатки текстовой нотации в сравнении со стандартными графическими нотациями.Чтобы сравнивать текстовую нотацию с графической, для начала перечислим преимущества текстовой нотации на базе UC (UC). Проанализируем удобство работы с набором UC для лиц, имеющих разные роли в проекте.Руководитель проектаСам по себе UC — это удобный способ описывать диалог, он понятен человеку без подготовки UC и обычно не содержит деталей реализации и пишется на языке целей пользователей. Поэтому UC удобно показывать Заказчику. В отличие от планирования работы и сдачи результатов в виде отдельных функций (сохранять, предоставлять доступ) или элементов архитектуры (платформа, подсистема хранения данных, подсистема обработки данных, подсистема пользовательского интерфейса), согласование работ на основе UC гораздо прозрачнее для заказчика. Во-первых, каждый UC несет конечную бизнес-ценность, понятную заказчику, во-вторых, даже технически неподкованный заказчик может убедиться в наличии реализации того или иного UC в системе, в отличие от наличия отдельных подсистем или функций, никак не отображающихся на пользовательском интерфейсе.То, что набор UC состоит из меньшего количества элементов — обычно от 5 до 20, — чем набор отдельных функциональных требований, экономит время на согласование проекта с заказчиком, а то, что заказчику понятна бизнес-ценность каждого UC, сильно упростит выставление приоритетов между ними.ТестировщикДля тестировщиков UC являются отличной базой для формирования тестовых сценариев — test case, — так как они описывают в каком контексте должно производиться каждое действие пользователя. UC, по умолчанию, являются тестируемыми требованиями так как в них всегда указана цель, которой нужно достигнуть и какие шаги надо для этого воспроизвести.Проектировщик интерфейсовПрофессиональный проектировщик интерфейсов всегда предпочитает ориентироваться на цели-ориентированные сценарии работы пользователя с системой, нежели на описание отдельных функций, к которым должен иметь доступ пользователь. Это позволяет проектировщику:- делать специализированный интерфейс для каждой роли пользователя,- выводить на первый план интерфейса элементы, соответствующие более приоритетным целям пользователя,- делать интерфейс более лаконичным и простым для восприятия, увеличивая скорость обучения.РазработчикРазработчик гораздо лучше понимает ограничения, которые накладываются на реализацию той или иной функции, — требование — это всегда ограничение, — когда он видит не отдельное «система должна…», а контекст использования той или иной функции. Какие функции будут выполнены, прежде чем будет вызвана эта? В каком виде и почему будут введены данные? Можно ли менять этот реализованный класс или это отразится на согласованных сценариях работы пользователя с системой?Это понимание позволит разработчику лучше планировать работу над реализацией отдельных объектов и функций, а также снимет часть вопросов о используемых форматах данных.Технический писательТакже как заказчику гораздо легче обсуждать и приоритизировать функциональность системы на основании UC, пользователю легче учиться работать с системой, если в пользовательской документации описаны не множество отдельных действий, которые можно выполнять в интерфейсе, например, «Выбрать объект», а на основе их конечных целей, например «Изменить информацию о клиенте». Поэтому технические писатели также должны формировать документацию на основе описанных и согласованных ранее UC.Аналитик и менеджер продуктаДля аналитика и менеджера продукта, как наиболее частых авторов, UC это отличный инструмент:- разработки и обеспечения полноты функциональных требований,- выявления других видов информации (нефункциональных требований), которая необходима для работы над проектом: ограничений;атрибутов качества;требований к пользовательскому интерфейсу;внутренних правил работы в предметной области (бизнес-правил);обеспечения трассировки требований между исходными требованиями заказчика (бизнес-требованиями) и техническими требованиями (не только функциональными).Как уже говорилось выше, хороший набор UC позволяет обеспечить полноту функциональных требований, следующих из потребностей пользователей.В процессе проектирования взаимодействия с системой в виде UC и согласования их с заказчиком, аналитик и руководитель проекта узнают много сопутствующей информации: роли пользователей, внутренние правила работы потенциальных пользователей, которые влияют на логику UC и являются бизнес-правилами. В процессе расстановки приоритетов и выявления критичности тех или других UC формируются требования к пользовательскому интерфейсу. При определении частоты выполнения того или иного действия пользователя в системе, описанного в виде UC, формируются требования к производительности системы.Так как UC полностью покрывают набор таких функциональных требований, и в то же время согласуются с бизнес-целями заказчика, они позволяют проследить связь от бизнес-целей заказчика до отдельной функции и Но UC не обеспечивают полноту всех функциональных требований, если в систему должна быть заложена сложная бизнес-логика, т.е. обработка информации в системе зависит не только и не столько от действий пользователей, сколько от внутренних правил взаимодействия объектов.Например, работа с системами типа «тасктрекер» задается достаточно простыми и стандартными UC: «Создать задачу», «Назначить задачу», «Пометить задачу, как выполненную». Однако тасктрекеров существует огромное множество, и это оправдано тем, что в каждом есть свои возможности по заданию жизненных циклов задач, их типов и взаимосвязей. И эту внутреннюю логику работы с задачами нет смысла описывать в виде UC.То же касается бухгалтерских программ, систем поддержки принятия решения, профессиональных систем для проектирования и дизайна. UC важны для них, но не покроют и пятой части требований к функциональности.Сгруппируем описанное выше и дополнительно добавим информации.Преимущества использования UC следующие:UC удобны для описания функциональных требований к системе.Применение UC препятствует преждевременному дизайну системы.Правильно организованные UC, трассируемые (отслеживается взаимосвязь между ними и другими артефактами системы требований).UC могут быть использованы основой для оценки трудозатрат, планирования и валидации результатов реализации системы.UC повторно используемы. Вариант использования может служить на различных итерациях таких, как сбор требований, разработка системы, тестирование и написание документации пользователя.Альтернативные пути выполнения варианта использования описывают дополнительное (не основное) поведение системы, что повышает ее устойчивость.UC удобны для определения стадий и объемов работы. Применение ваирантов использования делает возможным итеративный выпуск продукта, с удобной приоритезацией функций системы.UC понятны для бизнес-пользователей (в частности, аудитория экспертов предметной области и заказчиков), тем самым обеспечивая удобный способ коммуникации между разработчиками и конечными пользователями.При описании UC не используется специфический язык. Они могут быть написаны множеством стилей для достижения задач отдельного проекта. UC позволяют нам повествовать истории. Очень просто описать вариант использования в конкретной ситуации описывая ее как историю либо сценарий. UC сконцентрированы на описании взаимодействия пользователя и системы. Применение UC делает возможным вовлечение дизайнеров пользовательского интерфейса в работу до- либо параллельно с работой программистов.Вариант использования помещает требования в контекст, где требования четко определены задачами бизнеса.Изменения в системе более управляемы если описаны в виде UC.Дополнительно.Диаграммы UC (Use Case Diagrams) помогают заинтересованным сторонам (Stakeholders) понять природу и объем предметной области системы, находящейся в разработке.Диаграммы UC могут быть описаны на языке UML, который поддерживается большим количеством CASE-средств.UC и их диаграммы могут быть интегрированы с прочими результатами анализа и дизайна, производыми CASE-средствами, для создания завершенных требований и дизайна.Недостатки использования UC следующие:UC не удобны при описании нефункциональных требований системы.Шаблон варианта использования не обеспечивает ясность изложения требований. Ясность требований зависит от уровня квалификации автора.UC не очень удобны при описании требований к системам критичным к безопасности, а также к системам реального времени, где необходим высокий уровень точности.UC имеют кривую обучения, которая позволяет точно интерпретировать их конечными пользователями и разработчиками лишь со временем.Сторонники экстремального программирования рассматривают UC как ненужные или документа-ориентированные, предпочитая использовать более простые пользовательские истории (User Stories).Авторы UC зачастую затрудняются определить степень вовлеченности пользовательского интерфейса при описании требований. Тем не менее, теория рекомендует не отражать особенности пользовательского интерфейса при написании UC. Что многие находят неудобным, так как данный подход затрудняет визуализацию требований.Недостатки побороть нам помогают графические типы нотаций, который, в свою очередь, имеют свои недостатки по сравнению с текстовой нотацией. Организация связи между разнородными элементами модели бизнес-процесса (аналогично трассировке требований в рамках Rational RequisitePro)Use case (вариант использования) имеет один результат основного сценария и отвечает на вопрос: что произойдет, если сценарий будет успешно выполнен. Например, имеем процесс: Описание Заказчик хочет пополнить свой баланс и нажимает кнопку «Пополнить счет» на странице «Мой счет», после открываются окна, где он последовательно выбирает способ оплаты, сумму пополнения и прочие параметры платежа, совершает платеж.Устанавливаем предисловия, которые описывают ожидаемое состояние системы перед началом Сценария использования. Предусловие в варианте использования объясняет в каком состоянии должна находится система, чтобы данный вариант использования мог начать выполняться. Нужно быть внимательным и осторожным в описании состояния системы. Избегать описания деталей других, случайных действий, которые могут иметь место в данном случае.ПредусловияЗаказчик авторизован в системеЗаказчик находится на странице «Мой счет»Постусловие варианта использования перечисляет возможные состояния, в которые система может перейти в конце выполнения варианта использования. При этом система должна быть в одном из этих состояний. Постусловие также устанавливает те действия, которые система должна выполнить в конце варианта использования, независимо от того, что происходит в течение выполнения варианта использования. Постусловия могут быть классифицированы как минимальные гарантии или гарантии успеха. Минимальная гарантия представляет условие, которое будет истинным при окончании варианта использования, независимо от того, как он завершается. Гарантия успеха представляет условие, которое будет истинным, если вариант использования завершается успешно, независимо от того, каким образом это произошло (какой путь при этом был выбран).Ни предусловия, ни постусловия не следует использовать для создания последовательности вариантов использования. Как правило такая ситуация может возникнуть, когда мы вынуждены выполнить один вариант использования, а затем другой в некотором многозначном потоке событий.