Geum.ru

Законы существования текстов в обществе 32

Вид материалаЗакон
Глава 5. Универсальность онтологического описания БП
Сравнительная характеристика двух подходов к разработке ПО
Практический аспект использования онтологии
Подобный материал:
1   ...   14   15   16   17   18   19   20   21   22

Глава 5. Универсальность онтологического

описания БП

Новые возможности, связанные с использованием онтологии:

не только разработка ПО


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

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

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

Хорошо спроектированная онтология бизнес-процесса содержит его целостное представление. Таким образом, она является основой для порождения различных артефактов, в первую очередь это:
  • нейтральные по отношению системам управления бизнес-процессами (Business Process Management Systems, BPMS) описания: бизнес-процесс может быть автоматически представлен в виде блок-схем, которые будут полезны при обсуждении и документировании проекта;
  • зависящие от BPMS описания: на рынке существует огромное количество BPMS, многие из которых используют свой собственный синтаксис. При условии, что в BPMS есть возможность импорта описания БП (в каком-либо формате), это описание может быть автоматически получено из онтологии, импортировано и использовано в BPMS;
  • диаграммы классов UML: Описанные в онтологии классы и их связи могут быть автоматически проанализированы и импортированы в CASE-средства через распространённый интерфейс XMI (XML Metadata Interface);
  • в принципе, могут быть порождены описания бизнес-процессов для любых программных средств, так или иначе их использующих.

С точки зрения разработки программного обеспечения, использование онтологии БП как основы проекта приведёт к следующему:


Таблица 1.

Сравнительная характеристика двух подходов к разработке ПО

Существующий подход
Подход, основанный на онтологии

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

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

Программный код и описывающие

архитектуру артефакты создаются

в средах разработки.
Создание архитектурных артефактов и через них кода, основано на машинно-обрабатываемом описании процесса.

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

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

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



Практический аспект использования онтологии


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

Если вновь обратиться к перечню основных причин неудач софтверных проектов, то окажется, что использование «онтологического» подхода позволяет решить такие проблемы, как «неполнота требований» (13.1%), «изменяющиеся во время разработки требования» (8.7%), «недостаточное планирование» (8.1%), и возможно, частично снять проблемы «недостаточного участия пользователей» (12.4%) и «нереалистичных ожиданий» (9.9%). В сумме это может составить 30% и более. Разумеется, это не гарантирует увеличение числа успешных проектов на 30%, но, тем не менее, заметно снижает вероятность неудачи.

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


Резюме


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




Рис. 6. Варианты использования онтологии бизнес-процесса