Разработка системы управления знаниями в проектной консалтинговой организации
Цель управления знаниями в проектной деятельности. Онтологический подход к проектированию системы управления знаниями (СУЗ). Разработка методики построения и развития онтологий, учитывающих особенности проектной деятельности в области ИТ-консалтинга.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | магистерская работа |
| Язык | русский |
| Дата добавления | 22.01.2016 |
| Размер файла | 1,4 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru
СОДЕРЖАНИЕ
- Введение
- Глава 1. Теоретические предпосылки исследования
- 1.1 Методологические предпосылки исследования
- 1.2 Предмет, объект, цель и задачи исследования
- 1.3 Постановка проблемы
- Глава 2. Методы и инструментальные средства решения поставленных задач
- 2.1 Обзор подходов к построению СУЗ
- 2.2 Обзор методик построения онтологии
- 2.3 Выбор методики построения онтологии
- 2.4 Элементы теоретической новизны и практической значимости предложенного подхода
- Глава 3. Практическая реализация онтологического подхода к разработке СУЗ
- 3.1 Определение требований к СУЗ проектной организации
- 3.2 Разработка верхнеуровневой архитектуры СУЗ
- 3.3 Проектирование онтологий
- Вариант 1. Онтология для эффективных запросов к СУЗ
- Вариант 2. Строгая логическая модель категорий верхнего уровня
- Вариант 3. Ассоциативная индивидуальная онтология
- 3.4 Сравнительный анализ спроектированных онтологий
- 3.5 Детальная проработка выбранного варианта онтологии
- 3.6 Решение пользовательских задач с помощью построенной онтологии корпоративной СУЗ
- Заключение
- Список используемой литературы
- Приложения
- Приложение 1. Схемы типовых бизнес-процессов
- Приложение 2. Перечень типовых запросов к онтологии
- Приложение 3. Диаграммы онтологий
- Онтология 1. Онтология для эффективных запросов к СУЗ
- Онтология 2. Логическая модель категорий верхнего уровня
- Онтология 3. Ассоциативная индивидуальная онтология
- Приложение 4. Реализация запросов к онтологии на языке SPARQL
- Приложение 5. Бизнес-процесс управления онтологией
ВВЕДЕНИЕ
Исследование посвящено разработке системы управления знаниями в проектной консалтинговой организации.
Проекты существовали всегда на протяжении истории человечества там, где возникали временные мероприятия, требовавшие координации усилий и знаний людей. На профессиональный уровень управление проектами вышло совсем недавно. Так, международный институт бизнес-анализа был основан в 1969 году, став крупнейшим профессиональным объединением по управлению проектами, программами и портфелями проектов [1]. Несмотря на то, что наука управления проектами существует не так давно, её основные понятия были сформулированы ещё в конце XIX века [2]. Например, диаграммы Ганта, без которых сложно представить современное управление проектами, появились в начале XX века [2]. За это время управление проектами стремительно развивалось. Появлялись программные продукты, предназначавшиеся для управления проектами. Первая коммерческая версия одного из лидеров на рынке программных продуктов по управлению проектами -- Microsoft Project [3] -- была представлена рынку в 1990 году [4].
Одновременно с управлением проектами развивалась смежная научная область -- управление знаниями. Сложно назвать конкретную дату, когда эта дисциплина возникла. Термин «информационный работник» (knowledge worker) впервые ввёл П.Друкер [5]. Вот что пишет П.Друкер об информационных работниках: «каждый информационный работник принимает экономические решения …, чтобы принимать верные решения, информационный работник должен знать, какая эффективность и какие результаты нужны …, он должен видеть, какой вклад в бизнес дают его знания и усилия» [5, стр.208]. В конце 1990 года была опубликована статья И.Нонака «Компания, создающая знания» [6]. Автор доказывает, что единственным источником устойчивого конкурентного преимущества в современном мире повышенной неопределённости может быть только знание, процессами создания и развития которого компании должны целенаправленно управлять [6].
В последние годы возрастает интерес к управлению знаниями в проектных организациях и в управлении проектами. Была предложена концепция аутопоэтической системы управления знаниями в проектных организациях [25]. Edward von Wasielewski предложил использовать эмпирические данные о завершённых проектах для сравнения проектов [22]. Предложенную им технику сравнения проектов (Project Comparison Technique) он включает в концепцию управления знаниями в проектах. В том же году Anthony Yeong предложил подход к интеграции управления знаниями с управлением проектами в своей статье [7]. В статье даётся обоснование того, что управление знаниями в проектах позволяет устранить часть неопределённости, уменьшить проектные риски, снизить издержки за счёт использования накопленного опыта, ускорить выполнение проектов, снизить время на нахождение решений для текущих задач и повысить качество за счёт использования лучших доступных практик.
Формализация и автоматизация процессов управления знаниями в организации требует использования современных информационных технологий. Перед организацей встаёт множество задач по управлению знаниями, среди которых выявление знаний, их формализация и интеграция, управление коммуникациями, как машинными, так и человеческими, которые реализуются в СУЗ. Современные СУЗ без онтологий не выдерживают критики, поэтому данное исследование сосредоточено на использовании онтологического подхода. Использование онтологий для управления знаниями в проектном менеджменте состоит в следующем: в проектах возникает потребность в обучении (предметная область заказчика, новые технологии реализации проектных решений), и для этого требуется инвентаризация знаний, их сбор и интеграция этих знаний в общую структуру знаний организации. Онтология является концептуальной моделью, которая позволяет достичь целей управления знаниями в проектной деятельности [23]. Для решения задач управления знаниями необходимо использовать онтологический подход к проектированию СУЗ, разработав методику построения и развития онтологий, учитывающую особенности проектной деятельности в области ИТ-консалтинга, что определяет актуальность выбранной темы магистерской диссертации
В первой главе рассматриваются теоретические аспекты управления знаниями в контексте ИТ-проектов, даются методологические предпосылки исследования, определяются предмет, объект, цель и задачи исследования, приводится постановка проблемы.
Во второй главе определяются методы и инструментальные средства для решения задач исследования. На основе результатов обзора подходов к построению СУЗ и методик построения онтологий осуществляется выбор методики решения задач исследования. В конце главы приводится обоснование теоретической новизны и практической ценности данного исследования. знание проектный онтология консалтинг
В третьей главе приведена практическая реализация поставленных задач исследования. Определяются требования к СУЗ проектной организации в области ИТ-консалтинга, на основе которых выстраивается целевая архитектура компании и система метрик для сравнения онтологий. В рамках предложенной архитектуры проектируются различные варианты онтологии для управления знаниями организации, которые затем сравниваются по степени соответствия требованиям к СУЗ. Завершает третью главу реализация типовых запросов к системе, которые позволяют повысить эффективность процессов управления знаниями в проектной организации.
ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ ПРЕДПОСЫЛКИ ИССЛЕДОВАНИЯ
1.1 Методологические предпосылки исследования
Исследование посвящено управлению знаниями в консалтинговых организациях, для которых главной формой организации деятельности является проект. Свод знаний по управлению проектами, или Project Management Body of Knowledge, определяет проект как временное мероприятие, предпринятое для создания уникального продукта, услуги или результата [8].
Типичными ограничениями проекта являются: границы проекта (scope), качество, время, бюджет, ресурсы и риски [8]. Эти ограничения задают пространство выбора управления для достижения целей проекта.
Свод знаний уделяет некоторое внимание управлению знаниями, но ограничивается корпоративной базой знаний [8]. Корпоративная база знаний включает в себя активы организационного процесса, финансовую информацию, историческую информацию, базы дефектов и ошибок, статистику метрик процессов, проектную документацию. По-сути, такая база представляет собой большой репозиторий данных. До полноценной системы управления знаниями недостаёт концептуальных моделей предметных областей, в пространстве которых осуществляется реализация проекта.
ИТ-проект -- это проект в области информационных технологий. К ИТ проектам относятся проекты: разработки программного обеспечения, внедрения программных продуктов, разработки и развития корпоративных хранилищ и баз данных. ИТ-проект характеризуется низкой долей научно-исследовательских работ (в противоположность инновационным проектам, для которых может даже не существовать готовой теории), но высокой долей опытно-конструкторских работ (если речь идёт не о внедрении готового коробочного решения, а о разработке, в том числе и через прототипирование), относительно малыми по сравнению с научными проектами сроками, не превышающими трёх лет, большим количеством используемых готовых решений и командами, обычно не превышающими по численности сто человек. Это характеризует ИТ-проекты как хорошо формализуемые и структурируемые, что способствует высокой отдаче от применения систем управления знаниями.
С точки зрения управления знаниями ИТ-проекты также имеют свои особенности. С одной стороны, ИТ-решения требуют знаний и компетенций в области компьютерных наук, что облегчает задачу управления знаниями, поскольку данная предметная область хорошо формализуется. С другой стороны, ИТ-решения применяются для автоматизации бизнес-процессов в самых разных областях человеческой деятельности, для чего требуется обширное знание этих предметных областей, которое должно быть формализовано для использования широким кругом стейкхолдеров.
PMBOK не рассматривает системы управления знаниями, ограничиваясь упоминанием важности управления знаниями в управлении проектами в целом.
Проекты длительное время выполнялись без достаточного внимания вопросам управления проектными знаниями. Точно то же самое справедливо в отношении проектных организаций в целом. Тем не менее, управление знаниями важно для успеха проекта по ряду причин. A.Yeong указывает три основных аспекта управления знаниями: культура, процессы и технологии. Культурные различия осложняют коммуникации и негативно сказываются на сроках и качестве проектного решения. В наибольшей степени это справедливо для международных проектов, в которых наблюдаются существенные культурные и образовательные различия между участниками проектных команд [7].
Информационные ресурсы активно используются в управлении бизнес-процессами (Business Process Management) и необходимы для успешного выполнения процессов. Качество информации прямо сказывается на сроках и эффективности, поскольку неточная, нерелевантная или несвоевременная информация делает невозможным выполнение некоторых процессов. Наконец, использование современных технологий требует постоянно поддерживаемого и обновляемого знания об их использовании у всех исполнителей и владельцев процессов. Рынок ИТ-технологий развивается стремительными темпами, так что важность информации о технологиях и об особенностях их применения важна для проектов в ИТ-сфере [7].
Центральным методом построения СУЗ в данном исследовании служит онтологический подход, использующий онтологии для формализации концептов и отношений между ними, автоматической классификации понятий, а также для вывода новых знаний, что расширяет границы возможностей онтологий за пределы глоссариев и таксономий, делая их полноценным инструментом управления знаниями.
Термин онтология происходит из древнегреческой философии и обозначает науку о бытии. В приложении к компьютерным наукам под онтологией понимается формальная (концептуальная) модель структуры системы, т.е. сущности и связи между ними, релевантные задачам моделирования [9]. Онтология представляет собой концептуальную модель, отношения в которой представлены унарными и бинарными предикатами. Основой онтологии является генерализующая/детализирующая иерархия концептов, т.е. таксономия. Но, как было сказано ранее, онтологии выходит за границы таксономии, позволяя построение сложных сетей, использующих логику первого порядка для автоматической классификации понятий.
Т.Грубер [10], являющийся одним из основоположников управления знаниями и применения онтологического подхода, определяет онтологию, как множество примитивов представления (representational primitives) для моделирования домена знаний. Сравнивая онтологии с моделями баз данных, Грубер отмечает, что онтологии представляют собой семантическую модель в противовес логической или физической модели базы данных.
Martin Serrano определяет онтологию как спецификацию набора концептов с использованием формального языка для определения и описания сущностей и связей [24].
Другие авторы понимают под онтологией абстрактное формализованное описание фрагмента предметной области, используемое для систематизации знаний в организациях и поддерживающее поиск, стандартизацию и категоризацию информации.
Все эти определения близки -- их отличает лишь контекст, в котором авторы используют онтологии в своих исследованиях. В контексте управления знаниями удобно понимать под онтологией компьютерное представление концептуальной модели знаний о предметной области.
Staab и Studer отмечают, что для систем искусственного интеллекта существует только то, что может быть отображено [9]. Это утверждение имеет важные следствия для управления знаниями, поскольку управление знаниями опирается на онтологии -- только теми знаниями можно целенаправленно и планомерно управлять, которые можно формализовать в виде концептуальной модели. Все аспекты реальности, о которых существуют только неформальные знания, безусловно, не перестают существовать, но они лежат вне досягаемости систем управления знаниями. При построении онтологий разумно руководствоваться этим утверждением, признавая существующим только формализуемое. В области искусственного интеллекта онтологии выступают в роли единой концептуальной модели. Согласно B.Chandrasekaran и John R.Josephson [11], теории ИИ попадают в две широкие категории: теории механизма (mechanism theory) и теории контента (content theory). В рамках второй группы теорий и исследуются онтологии.
Помимо общих суждений о пользе управления знаниями для проектного менеджмента, некоторыми исследователями [12] проверялись гипотезы о наличии положительной корреляции между применением практик по управлению знаниями в проектах и результатами этих проектов. Исследователи установили положительную связь между использованием управления знаниями и улучшением проектного управления. Они объясняют это улучшение двумя факторами: осведомлённостью (awareness) стейкхолдеров и доступностью (accessability) информации. Авторы также отмечают, что эти факторы повышают качество управления рисками за счёт устранения части неопределённости. Кроме того, управление знаниями, по мнению авторов, уменьшает затраты времени на переделку и на планирование проекта, позволяет поставлять «нужное знание» «правильным участникам» в «подходящее время».
Наконец, успешный опыт разработки системы управления знаниями в рамках внутреннего проекта организации, занимающейся проектами в области ИТ-консалтинга, открывает перед организацией возможности выхода на рынок консалтинга в сфере управления знаниями. Разработка повторно используемой онтологии, то есть шаблонной онтологии (pattern-based ontology [13]) позволяет ИТ-компании использовать эту онтологию не только для внутреннего управления знаниями, но и генерировать из неё целевые онтологии для проектов по внедрению систем управления знаниями в компаниях-заказчиках. За счёт такого снижения издержек компания получает конкурентное преимущество на рынке.
Таким образом, построение онтологий в СУЗ обеспечивает поддержку процессов управления знаниями, снижает издержки компании за счёт использования общих знаний и время выполнения бизнес-процессов, использующих знания.
1.2 Предмет, объект, цель и задачи исследования
Объект исследования - процессы управление знаниями в проектной организации в области ИТ-консалтинга.
Предмет исследования - методы создания и развития систем управления знаниями на основе онтологического подхода.
Консалтинговая проектная ИТ-организация имеет ряд специфичных характеристик, которые должны быть отражены в проектируемой СУЗ. К таким особенностям относятся:
1. использование знаний из нескольких предметных областей, определяемых направлениями деятельности заказчиков;
2. высокий уровень экспертизы в сфере консалтинговой деятельности, проектного управления и ИТ-разработки;
3. большая доля опытно-конструкторских работ, необходимость которых вызвана проектным характером деятельности организации
Цель исследования - повышение эффективности бизнес-процессов проектной организации в области ИТ-консалтинга за счёт автоматизации процессов управления знаниями при помощи системы управления знаниями на основе онтологий.
Задачи исследования в области применения онтологий к проектированию и развитию СУЗ:
определение типовых требований к системе;
разработка верхнеуровневой архитектуры;
разработка и сравнительный анализ вариантов онтологий;
разработка методов создания и развития онтологий для поддержки процессов управления знаниями;
классификация и разработка методов решения типовых задач управления знаниями.
На начальном этапе данного исследования осуществляется сбор и формирование требований к проектируемой СУЗ проектной организации в области ИТ-консалтинга. На основе требований не только осуществляется разработка архитектуры системы, но и формируются критерии для оценки построенных онтологий, что является необходимым шагом на пути к разработке методики построения и развития онтологий в проектном ИТ-консалтинге.
1.3 Постановка проблемы
Разработка СУЗ в организации представляет собой многоаспектный проект, уникальный для каждой организации, задачи которого были определены в главе 1.2. Ключевая проблема разработки СУЗ для организации заключается в формировании перечня требований, которым разрабатываемая система должна соответствовать.
Собранные требования используются для выбора концептуальной формы представления знаний и построения процессов управления знаниями, автоматизируемых при помощи СУЗ, проектируемой на основе онтологического подхода.
Наибольшую сложность представляет подбор вариантов реализации системы. На данный момент не существует единых методов построения онтологий для корпоративных СУЗ. Актуальна проблема разработки соответствующих методов, для решения которой необходимо прототипирование. Прототипирование онтологий позволяет провести сравнение нескольких вариантов для их верификации, проверки процессов формализации и вывода знаний, а также выявления и устранения недостатков созданных прототипов. Этот фактор необходимо учитывать при разработке СУЗ, в противном случае повышаются риски не достижения целей проекта по разработке СУЗ на основе онтологического подхода.
Крупные транснациональные консалтинговые компании используют различные варианты автоматизации процессов по управлению знаниями, различные системы управления знаниями. Рассмотрение примеров позволит улучшить результаты этапа сбора требований к проектируемой СУЗ.
Выше была показана актуальность использования онтологий при построении корпоративной СУЗ проектной организации в области ИТ-консалтинга. Для решения задач магистерской диссертации необходимо сформировать требования к целевой СУЗ и выбрать подход к разработке онтологий. Перед исследованием стоит задача разработки архитектуры целевой системы, которая включает в себя выявление ключевых элементов системы и определение методов их взаимодействия. В рамках выбранных подходов и разработанной архитектуры создаются варианты онтологий для отбора финальной версии. Результатом процесса анализа и сравнения созданных вариантов онтологии является методика управления знаниями с использованием онтологий. Проверка эффективности реализации онтологий включает в себя использование онтологии для решения задач пользователей в соответствии с вариантами использования, определёнными на этапе сбора требований.
ГЛАВА 2. МЕТОДЫ И ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА РЕШЕНИЯ ПОСТАВЛЕННЫХ ЗАДАЧ
2.1 Обзор подходов к построению СУЗ
В настоящее время известны следующие методологии управления знаниями [14]:
1. Know-Net -- методология создания и управления СУЗ, состоящая из концептуальной схемы, методики, и инструментов;
2. Пятифазная модель создания и управления знаниями Нонака и Такеучи;
3. Методология CommonKADS, основанная на построении набора моделей управления знаниями;
4. DECOR -- методологическое руководство для ведения проекта по УЗ, на основе CommonKADS и IDEF5;
5. Методология Карла Виига, выделяющая уровень объектов знаний и уровень управления этими объектами;
6. On-To-Knowledge (OTK) -- процессно-ориентированная методология Университета Карлсруэ, использующая онтологии.
В рамках методологии OTK выделяют два процесса [9]: «мета-процесс знаний» («Knowledge Meta Process»), направленный на идентификацию знаний, и «процесс знаний» («Knowledge Process»), направленный на создание знаний. Первый процесс включает в себя разработку онтологий. Второй процесс предназначен для создания знаний при поддержке первого процесса на стадии промышленной эксплуатации СУЗ. Знания в организации являются ресурсом. Поскольку онтологии, создаваемые в ходе выполнения первого процесса, используются для создания знаний, авторы предлагают рассматривать их в качестве активов организации.
Верхнеуровневый «мета-процесс знаний» состоит из следующих процессов [9]:
1. оценка возможностей и задач;
2. сбор требований и разработка документа спецификации требований к онтологии (ORSD -- ontology requirements specification document);
3. уточнение и доработка;
4. оценка;
5. применение.
С точки зрения архитектуры СУЗ проектной организации в области ИТ-консалтинга, ключевыми компонентами системы являются компоненты, решающие следующие задачи:
1. Хранение источников знаний и ссылок на информационные ресурсы;
2. Хранение проектных шаблонов (бизнес-анализа, разработки, тестирования, управления);
3. Ведение журналов\реестров итоговых и промежуточных проектных результатов (реестр проектов, журнал ошибок и инцидентов и т. д.);
4. Формализация знаний отдельных сотрудников;
5. Интеграция знаний в единую систему знаний компании;
6. Вывод новых знаний на уровне интегрированных знаний компании.
Первые три задачи решаются применением распространённых технологий wiki-порталов и баз данных. Для решения всех озвученных задач требуется специфический инструмент такой, как онтология, обеспечиывающий интегрированное представление формализованных знаний сотрудников в единой модели с поддержкой возможности вывода новых знаний.
Альтернативными решениями для перечисленных задач могут служить базы знаний экспертных систем и системы бизнес-правил. Онтологический подход является более фундаментальным, поскольку и базы знаний и бизнес-правила нуждаются в единой системе категорий, которые они описывают. Это делает онтологии незаменимыми в управлении знаниями, вследствии перечисленных причин.
В корпоративном секторе существуют собственные разработки в области управления знаний, учитывающие специфику организации. Одним из примеров является система управления знаниями и поддержки принятия решений K-World [15], построенная консалтинговой компанией KPMG, входящей в большую четвёрку консалтинговых компаний. Авторы статьи обращают внимание на то, что основные активы консалтинговой организации это активы знаний. Для поддержки операций на международном рынке компании необходимо было разработать единую систему управления знаниями, которая получила название K-World. СУЗ KPMG содержала информацию их различных источников и включала в себя финансовую, отчётную, аудиторскую информацию, а также различные обучающие материалы. Ключевая роль в организации знаний в системе была отведена таксономиям [15]. Разработчики K-World заметили, что лишь 30% корпоративной таксономии требует кастомизации -- остальные 70% представляют собой универсальный язык бизнеса.
Важно подчеркнуть роль культурных транформаций, которые потребовалось провести компании, чтобы перевести сотрудников из отделений по всему миру на использование СУЗ.
Таким образом, общими положениями, характерными для всех рассмотренных методик, является общирное использование концептуальных моделей знаний, наиболее полным вариантом которых является онтология, что подчёркивает важность развития онтологического подхода к построению СУЗ, попытка которого предпринята в данном исследовании.
2.2 Обзор методик построения онтологии
В практике проектирования систем управления знаниями проявляется тенденция в использовании онтологий. Современную СУЗ сложно представить без формального описания предметной области, для которой разрабатывается СУЗ.
Онтологии являются не единственных методом формализации знаний о предметной области. Известно широкое применение таксономий, то есть иерархий категорий, используемых для классификации информации, доступной о моделируемом объекте [16]. Однако, онтологии имеют ряд преимуществ перед таксономиями. В отличие от таксономий, онтологии позволяют образовывать разные типы отношений между концептами [16], лучше описывая предметную область, которая не ограничивается простым отношением подчинения между категориями. Таксономия, таким образом, является частью онтологии, о чём указано в словаре баз данных [10], где таксономии и тезаурусы приводятся в качестве примеров т. н. «легковесных онтологий». Ещё одно смежное с онтологией понятие -- тезаурус. В тезаурусе отражены отношения синонимии, антиномии, включения и ассоциации. В онтологии могут быть созданы любые типы отношений, что делает их надмножеством тезауруса.
Онтологии отличает от таксономий также и то, что они являются не просто методом классификации знаний, но и информационным ресурсом.
Использование онтологий даёт преимущества проектируемой СУЗ. Авторы выделяют три фундаментальных процесса управления знаниями [16]: коммуникация (communication), интеграция (integration) и вывод (reasoning). Помимо процессов, выделенных авторами, можно выделить процессы фильтрации, процессы сбора знаний, а также процессы отбора знаний под конкретные цели в рамках регламентных процессов.
Онтологии способствуют выполнению всех трёх процессов. После создания онтологии её можно использовать в коммуникациях, путём точного поиска по целевому домену. Онтологии облегчают интерпретацию сообщений посредством задания соответствующего контекста. Онтологии позволяют интегрировать знания на стыке различных областей и выводить новые знания через поиск связей и бизнес-правил. Авторы исследования [16] отмечают важность онтологий не только для межличностных коммуникаций или обучения сотрудников, но и для машинных коммуникаций в рамках автоматизации процессов управления знаниями.
В своей статье Thomas R. Gruber [17] рассматривает проблему передачи знаний от эксперта в предметной области к СУЗ. С точки зрения автора автоматизации процесса передачи знаний мешает различие между представлением знаний памяти эксперта и в системе. Автор предлагает для решения этой проблемы использовать фреймворк, выделяющий три аспекта расхождения представлений знаний: модельный, операционный и генерализизационный уровни.
Известные японские специалисты в области управления организационным знанием Нонака и Такеучи в своём классическом труде [18] выделяют четыре способа трансформации знания:
1. социализация (из неформализованного в неформализованное);
2. экстернализация (формализация);
3. комбинация (из формализованного в формализованное);
4. интернализация (из формализованного в неформализованное).
Второй способ -- экстернализация -- предполагает использование методов формализации знаний. Таким методом может являться онтология. Онтологии также применимы для комбинации и интеграции формализованных знаний. Пользователи могут использовать онтологии для извлечения знаний, что способствует их интернализации. Таким образом, онтологии поддерживают три из четырёх способов трансформации знания. Для поддержания процесса создания и распространения знания в организации каждый из способов необходим. Это лишний раз доказывает важность онтологий в управлении знаниями.
При классификации онтологий по цели создания выделяют четыре уровня онтологий [14]:
· онтологии представления -- концепт формализмов представления знаний;
· онтологии верхнего уровня -- повторно используемая в разных предметных областях;
· онтологии предметных областей -- повторно используемая в одной предметной области;
· прикладные онтологии -- нет возможности повторно использовать.
Рисунок 1. Взаимодействие уровней онтологий
Семантика языков разработки онтологий, например, OWL, уже содержит в себе онтологию представления. К ней относятся базовые категории вида класс, индивид, свойство, связь и т. д.
Онтология верхнего уровня содержит общие для нескольких предметных областей понятия. Такая онтология необходима для СУЗ проектной консалтинговой организации, которая работает с проектами в различных предметных областях, эксплицитный список которых заранее не известен. Очевидно, что разрабатываемая онтология должна содержать только базовые категории, общие для любого наперёд неизвестного набора предметных областей. Онтология верхнего уровня для проектной организации должны быть минимальной и простой. Поэтому имеет смысл строить онтологию верхнего уровня на основе паттернов.
Онтологий предметных областей потребуется разработать несколько. Одна онтология (главная) должна описывать предметную область деятельности самой консалтинговой проектной организации. Остальные онтологии должны описывать предметные области отраслей, в которых компания ведёт проекты. Все эти онтологии должны служить продолжением онтологии верхнего уровня.
Наконец, прикладные онтологии разрабатываются локально для каждого конкретного проекта в той или иной предметной области.
Первые три вида онтологий повторно используются -- на их основе строятся нижележащие, более детальные онтологии. Если к разработке прикладных онтологий подходить с использованием паттернов проектирования онтологий, можно будет повторно использовать их части, снизив общие издержки на разработку детальных онтологий для каждого предпринимаемого проекта.
При построении онтологий необходимо учитывать тот факт, что онтологии, как и прочие продукты, имеют собственный жизненный цикл: они проектируются, разрабатываются, оцениваются, корректируются, используются и повторно используются. Aldo Gangemi и Valentina Presutti отмечают особую роль повторного использования онтологий и их реинжиниринга [14]. Альтернатива реинжинирингу состоит в использовании референтных онтологий, но авторы скептически относятся к этому подходу, ввиду большой сложности и общих размеров таких онтологий. Воодушевлённые успехом применения простых и малых онтологий, легко переносимых и адаптируемых, авторы предлагают свой подход, суть которого заключается в использовании маленьких строительных блоков при проектировании онтологий, которые авторы называют шаблонами проектирования онтологий контента (Content Ontology Design Patterns, CP). Такие шаблоны разрабатываются в виде небольших общего характера онтологий на основе лучших практик.
Помимо шаблонов проектирования онтологий контента, авторы выделяют ещё 5 семейств шаблонов проектирования онтологий (Ontology Design Patterns, OP) [14]:
· Структурные шаблоны проектирования (Structural OPs);
· Шаблоны корреспонденции (Correspondence OPs), включающие в себя шаблоны реинжиниринга и маппинга;
· Шаблоны логического вывода (Reasoning OPs);
· Презентационные шаблоны (Presentation OPs), обеспечивающие более удобное взаимодействие конечного пользователя с содержимым всей онтологии;
· Лексико-синтаксические шаблоны (Lexico-Syntactic OPs).
Из этих шаблонов строится итоговая онтология.
Помимо пользовательских аспектов проектирования онтологии необходимо рассматривать и аспекты разработки информационных систем как таковых. Авторы Гаврилова Т.А. и Хорошевский В.Ф. обращают внимание на следующие четыре свойства, по которым выстраиваются показатели оценки эффективности результатов разработки программного обеспечения [19]:
1. Модифицируемость;
2. Эффективность;
3. Надёжность;
4. Понимаемость.
Таким образом, один из критериев успешности разработанной онтологии строится на основе выполнимости этих четырёх свойств. Применение паттернов даёт хорошие результаты по трём из четырёх критериев. Построенная из готовых микро-решений онтология легко модифицируется -- достаточно убрать один паттерн и поставить на его место другой, развив его в детализации требуемым образом. Паттерны надёжны и устойчивы, поскольку представляют собой набор лучших практик в проектировании онтологий. Паттерны онтологий хорошо задокументированы, и каждый паттерн решает небольшую часть задачи. По этой причине можно говорить о достаточной лёгкости понимания онтологий, построенных на основе паттернов.
Недостатком паттерн-ориентированного подхода является риск необоснованно высоких трудозатрат. Чем сильнее описываемая онтологией предметная область отличается от типовых, тем больше потребуется доработок. Доработки готовых решений в таких случаях снижают общую эффективность онтологии, что становится критичным для больших и сложных онтологий. Для СУЗ важны такие пользовательские свойства, как время обработки запроса к СУЗ и сложность написания самих запросов к СУЗ. В некоторых случаях применение паттернов может сильно ухудшить эти показатели из-за изначально нецелевого и не оптимизированного под задачу решения. В контексте онтологий проектных организаций, это серьёзный недостаток, но преимущества применения паттернов, состоящие в трёх названных свойствах, достаточны, чтобы придерживаться паттерн-ориентированного подхода в разработке онтологий.
Следует отметить, что использование паттернов проектирования онтологий возможно не во всех проектах разработки онтологий. В данном исследовании рассматривается только использование онтологий для построения корпоративных СУЗ для управления проектами, что сказывается на применяемых средствах.
Одним из распространённых применений онтологий является семантический веб (semantic Web) [9]. Семантический веб предназначен для стандартизации информации для машинной обработки. В рамках этой задачи паттерны проектирования онтологий эффективны. Однако, для цели хранения и вывода знаний в рамках СУЗ требуется более строгая логическая модель представления знаний, хорошо отражающая связи между знаниями. Шаблоны проектирования для этой цели не столь эффективны.
В магистерской диссертации предлагается создать методику построения и развития прикладных онтологий, учитывающих такие особенности проектных организаций в области ИТ-консалтинга, как высокий уровень экспертизы в нескольких предметных областях, повышенная роль обмена знаниями в межпроектном взаимодействии и высокая скорость решения задачи, определяемая сжатыми проектными сроками.
2.3 Выбор методики построения онтологии
Можно выделить шесть этапов проекта разработки СУЗ [14]:
1. инициация проекта;
2. диагностика и анализ знаний;
3. разработка и реализация пилотных проектов;
4. проектирование и планирование;
5. реализация мероприятий по разработке и внедрению СУЗ;
6. оценка деятельности в области знаний.
Данные этапы в полной мере соответствуют проекту разработки СУЗ на основе онтологического подхода для проектной организации в области ИТ-консалтинга.
В рамках исследования рассматривается несколько пилотных проектов -- вариантов онтологий, которые проверяются на предмет соответствия требованиям и вариантам использования, после чего сравниваются между собой. Это необходимо, чтобы выявить преимущества и недостатки полученных вариантов онтологий, удовлетворяющих требованиям, для осуществления финального отбора конкретного единственного варианта в качестве основы для реализации СУЗ.
Для выбора варианта онтологии используется список требований, определяемых в главе 3.1, и вариантов использования проектируемой целевой системы.
В исследовании анализируется несколько подходов к построению онтологии. Эффективная методика разработки и развития онтологии строится на основе сравнения пилотных проектов. Таким образом, суть исследования заключается в создании эффективной методики построения и развития онтологий в рамках корпоративной СУЗ для управления знаниями в сфере проектной консалтинговой ИТ-деятельности.
При построении иерархии категорий для интеграции индивидуальных онтологий возник вопрос в части представления измерений (dimensions) онтологии. Анализ показал, что возможны несколько способов моделирования многомерной онтологии:
1. Вертикальное представление;
2. Горизонтальное представление по измерениям;
3. Горизонтальное представление плоское;
Вертикальное представление предполагает иерархическую структуру, отражающую таксономию категорий предметной области. Пример такой онтологии имеет следующий вид:
1. Банковская карта
1. Кредитная карта
1. Классическая кредитная карта
1. Классическая зарплатная кредитная карта
1. Классическая зарплатная кредитная карта с грейс-периодом
2. Классическая зарплатная кредитная карта без грейс-периода
2. Классическая незарплатная кредитная карта
1. Классическая незарплатная кредитная карта с грейс-периодом
2. Классическая незарплатная кредитная карта без грейс-периода
2. Золотая кредитная карта
2. Дебетовая карта
Этот способ имеет недостаток, который показывает следующее рассуждение. Например, понятие «Платиновая карта» в этой онтологии остутствует. Оно существует только в привязке к кредитной или дебетовой карте, да ещё требует указания принадлежности к з/п проекту и наличие грейс-периода. Очевидно, что такое представление негативно сказывается на выразительной способности онтологии, когда требуется использование понятия в ограниченном окружении. Столь запутанное определение понятия «платиновая карта» осложняет работы в рамках регламентного процесса развития онтологии.
Другой способ представления многомерных понятий предполагает встраивание оснований классификации непосредственно в иерархическую структуру. Пример такого подхода к решению задачи моделирования многомерных понятий представлен на следующем примере:
У этого подхода очевиден недостаток иного рода. Иерархический тип связи в онтологии подразумевает понятия супер-класса и под-класса. Иными словами, онтологическая модель знаний должна позволять давать определения посредством деления. Например, «золотая карта это вид банковской карты». Предложенный вариант онтологии вынуждает пользователя онтологии давать бессмысленное определение вида «золотая карта это банковская карта по типу пластика, банковская карта». Это важный аспект, поскольку он нарушает логическую целостность модели знаний. Вертикальное представление, описанное выше, не имеет этого недостатка: «классическая зарплатная кредитная карта с грейс-периодом -- это классическая зарплатная кредитная карта, классическая кредитная карта, кредитная карта, банковская карта». С другой стороны становится понятно, что определение классической карты дать не получится, поскольку такое понятие в вертикальном представлении отсутствует.
Третий вариант располагает категории, относящиеся к разным основаниям классификации, на одном уровне в качестве прямых потомков общего над-класса. В такой реализации на одном уровне располагаются в том числе и те категории, которые не являются взаимоисключающими. На следующем примере показана реализация данного подхода:
Такой вариант кажется некорректным, поскольку платиновая карта находится на одном уровне иерархии с дебетовой картой, имея общего родителя. При этом эти понятия не взаимоисключающие, а наоборот, характеризуют разные аспекты одного объекта. Получается, что в таком виде плоское горизонтальное представления многомерного понятия нарушает логическую целостность онтологии. Но этого помогает избежать применение ограничений, которые отражаются в виде выражений дескриптивной логики, например:
Банковская_карта subClassOf (Дебетовая_карта or Кредитная_карта)
and (Золотая_карта or Платиновая_карта or Карта_Black_Edition or Классическая_карта);
Также необходимо указать несовместимость (disjoint) понятий одного измерения.
В учётом ограничений полученная модель позволяет корректно классифицировать экземпляры, поддерживая логическую целостность онтологии.
Также следует отметить, что оба «горизонтальных» варианта требуют отнесения экземпляра к нескольким классам. Если имеется экземпляр «зарплатная кредитная классическая карта», его необходимо отнести сразу к нескольким категориям.
Среди рассмотренных методов моделирования многомерных категорий был выбран подход, распологающий на одном уровне иерархии в качестве потомков одного родителя категории, относящиеся к разным основаниям классификации. Использование данного подхода позволяет давать строгие определения посредством деления, поддерживать логическую целостность концептуальной модели и выполнять задачи пользователей.
2.4 Элементы теоретической новизны и практической значимости предложенного подхода
Существует множество методик построения СУЗ, в том числе с использованием онтологического подхода. Данное исследование сосредоточено вокруг совершенствования применения онтологического подхода к построению систем управления знаниями. Теоретическая новизна данного исследования заключается в построении классификации различных методов разработки онтологий с отнесением их к различным уровням онтологий СУЗ. Ранее была приведена классификация онтологий по типу использования, разделяющая онтологии на четыре уровня. Данное исследование обосновывает эффективность применения разработанной онтологии в рамках корпоративной СУЗ для решения задач управления знаниями. Другой элемент новизны заключается в разработке методики построения СУЗ на основе онтологического подхода для управления проектами в ИТ-консалтинге.
Практическая значимость данного исследования заключается в том, что полученные результаты и созданная методика позволяют проектировать СУЗ консалтинговых организаций в области ИТ-проектов. В рамках исследования создаётся пошаговое методическое руководство, которое можно применить в практике разработки СУЗ. С другой стороны, построенная методика свободна от специфики конкретной организации, что позволяет применять её для широкого класса консалтинговых организаций, ведущих ИТ-проекты.
В главе 1 были озвучены преимущества использования СУЗ на основе онтологий для проектной деятельности. Предложенные онтологии позволяют повысить качество бизнес-процессов, уменьшить время выполнения итерации бизнес-процессов, что в контексте консалтинга с оплатой по трудозатратам означает большую маржинальность, обеспечить адаптивность организации к развитию предметных областей и к изменяющейся информационной внешней и внутренней среде.
В ходе исследования была решена частная проблема моделирования многомерных данных в рамках онтологического подхода. Данный результат используется в самом исследовании при построении финальной версии онтологии. Решение проблемы категорий с измерениями может быть использовано не только в рамках предложенной методики построения онтологий, но и в прочих задачах по построению онтологий.
Одна из задач исследования заключается в создании методики разработки и развития онтологий корпоративной СУЗ. На основе полученной методики предлагается выстроить процесс управления знаниями, протекающий вокруг онтологий и с использованием их. Таким образом, практическая значимость исследования включает в себя также и возможность применения его результатов не только в качестве методических рекомендаций к построению СУЗ, но и в качестве описания полноценного процесса, который может быть развёрнут в целевой организации.
ГЛАВА 3. ПРАКТИЧЕСКАЯ РЕАЛИЗАЦИЯ ОНТОЛОГИЧЕСКОГО ПОДХОДА К РАЗРАБОТКЕ СУЗ
3.1 Определение требований к СУЗ проектной организации
В семантическом вебе выделяют следующие варианты использования онтологий [20]:
1. Общий словарь (usage as a common vocabulary);
2. Поиск (usage for search);
3. Индексирование (usage as an index);
4. Построение схемы данных (usage as a data scheme);
5. Среда обмена знаниями (usage as a media for knowledge sharing);
6. Семантический анализ (usage for a semantic analysis);
7. Извлечение информации (usage for information extraction);
8. Набор правил для моделей знаний (usage as a rule set for knowledge models);
9. Систематизация знаний (usage for systematizing knowledge).
К онтологии корпоративной СУЗ предъявляются схожие требования, в том числе ведение общего словаря, обмен знаниями, вывод информации и систематизация знаний. Остальные приложения онтологий в семантическом вебе факультативны для корпоративной СУЗ. Так, поиск и индексация данных может осуществляться сотрудниками компании в поисковых системах глобальной сети, которые в свою очередь и используют технологии семантического веба. Модели данных в компании определяются информационными потоками и бизнес-процессами, лишь частично пересекающимися с знаниями компании. Таким образом, два основных требования к разрабатываемой онтологии заключаются в выполнении функций общего словаря и в выводе новых знаний на основе существующих.
Функциональные и нефункциональные, а также технические требования, включающие в себя пользовательские интерфейсы, интеграцию с существующими системами, производительность и другое, относятся ко всей СУЗ в целом. В данном исследовании основное внимание уделяется центральной части СУЗ, которой является онтология (вопросы архитектуры более детально освещены в главе 3.2). Детальные требования к онтологии строятся на основе вариантов использования и типовых пользовательских запросов к системе. В свою очередь, варианты использования системы определяются существующими и целевыми бизнес-процессами организации. Диаграмма вариантов использования онтологической СУЗ консалтинговой организации в области ИТ-проектов приведена на следующем рисунке:
Рисунок 2 Диаграмма вариантов использования СУЗ
Основные процессы проектной организации в области ИТ-консалтинга сосредоточены на проектной деятельности и на найме персонала:
1. Процесс поиска и найма персонала (онтология используется при формировании требований к вакансиям и вопросам для собеседований);
2. Процессы управления требованиями (см. процессы BABOK), в т.ч.
1. Процесс анализа и сбора требований (онтология отображает категории знаний и связи между ними для полного учёта требований);
2. Процесс согласования требований (онтология выполняет роль словаря для коммуникации);
3. Процессы разработки, т.ч.
1. Процесс разработки и согласования ТЗ (онтология содержит ссылки на источники знаний, выполняет роль словаря для коммуникации);
2. Процесс разработки решения (онтология содержит ссылки на источники знаний);
4. Процесс тестирования (онтология определяет связи между категориями и логические ограничения, которые используются при тестировании качества данных в соответствующих бизнес-сущностях);
5. Процесс управления проектом (см. процессы PMBOK);
Из перечисленных процессов именно процессы управления требованиями потребляют и создают наибольшее количество знаний. Подробные схемы процессов приведены в Приложении 1.
Помимо перечисленных выше процессов, специфичных для консалтинга в области ИТ-проектов, проектируемая СУЗ будет полезна для следующих процессов проектного управления, предлагаемых в PMBOK:
1. Управление интеграцией (онтология определяет связи между проектами на уровне знаний);
2. Управление границами проектного решения (онтология определяет затрагиваемые области знаний);
3. Управление человеческими ресурсами (онтология указывает на распределение знаний по сотрудникам);
4. Управление коммуникациями (онтология выполняет роль единого словаря);
Следующие процессы бизнес-анализа из BABOK также выигрывают от применения проектируемой онтологии:
1. Планирование бизнес-анализа (онтология позволяет провести планирование по областям знаний);
2. Сбор требований (онтология позволяет учесть связи между знаниями, провести анализ по областям знаний);
3. Управление требованиями и коммуникациями (онтология выполняет роль единого словаря);
4. Анализ предприятия (онтология способствует анализу по областям знаний, учитывает связи между знаниями)
5. Анализ требований (см. анализ предприятия);
Следует отметить, что онтологическая СУЗ может быть использована для всех процессов проектного управления и бизнес-анализа, но перечислены лишь те процессы, в которых выгода от использования СУЗ очевидно велика.
Также требования определяются типовыми бизнес-задачами, которые должны решать пользователи. Список возможных задач, решаемых с помощью онтологии приведён ниже:
1. Показать окружение понятия (контекст для бизнес-анализа)
1. Показать все понятия, следующие за понятием;
2. Показать все понятия, из которых следует данное;
3. Показать полное окружение понятия заданной глубины;
2. Показать все понятия данной предметной области (скоуп бизнес-анализа);
3. Показать все понятия данной категории или все понятия, связанные с понятием в данной категории (детальный контекст для бизнес-анализа);
4. Показать знания сотрудников (подбор персонала);
5. Показать источники знаний для категории (решение прикладных задач разработки);
6. Показать семантическое окружение понятия (функции тезауруса).
Список типовых задач СУЗ с детальным описанием и разбором элементов СУЗ приведён в Приложении 2.
Таким образом, ключевые бизнес-требования к системе можно свести к следующему списку:
1. Отражение всех знаний организации;
2. Классификация знаний;
3. Возможность добавления новых знаний организации (новые знания старых сотрудников или знания новых сотрудников);
4. Возможность вывода знаний на основе действующей модели.
Дополнительно к системе предъявляются нефункциональные требования:
5. Масштабируемость;
6. Возможность интеграции знаний отдельных сотрудников в единую систему самими пользователями;
7. Реализация пользовательских запросов к онтологии;
3.2 Разработка верхнеуровневой архитектуры СУЗ
Схема архитектуры проектируемой корпоративной СУЗ приведена в Приложении 3. СУЗ строится на основе двух групп элементов. Первая группа состоит из инструментов работы с онтологиями, которые включают в себя инструмент логического вывода и автоматической классификации объектов (OWL-reasoner) и обработчик запросов SPARQL. Вторая группа включает в себя интерфейсы выгрузки данных из Корпоративного Хранилища Данных (КХД), корпоративный wiki-портал, систему поддержки принятия решений, реестры и прочие активы организационного процесса. Наконец, онтологии включают в себя ссылки на информационные ресурсы, представленные wiki-порталом, реестрами и активами организационного процесса. Диаграмма архитектуры представлена на следующем рисунке.
Подобные документы
Проблема представления знаний в компьютерных системах – одна из основных проблем в области искусственного интеллекта. Исследование различных моделей представления знаний. Определения их понятия. Разработка операции над знаниями в логической модели.
курсовая работа [51,9 K], добавлен 18.02.2011Управление запасами: содержание, ключевые параметры. Моделирование системы управления запасами. Разработка проектной документации на создание информационной системы управления запасами склада, алгоритмическое обеспечение, детальное проектирование.
дипломная работа [1,1 M], добавлен 14.11.2017Описание предпроектной (разработка технико-экономического обоснования) и проектной (создание технического и рабочего проекта) стадий разработки автоматической системы управления, ввод ее в эксплуатацию путем проведения монтажных и пусконаладочных работ.
реферат [28,0 K], добавлен 25.10.2010Сущность метода проектов и виды проектной деятельности. Изучение особенности wiki-среды и системы связывания метода проектов с программными механизмами, такими как MediaWiki. Оценка степени влияния использования wiki-среды на качество процесса обучения.
курсовая работа [1,2 M], добавлен 23.06.2014Реализация компьютерных технологий в проектной деятельности школьников. Применение информационных технологий в учебном процессе и в управлении образовательным учреждением. Использование мультимедиа учебников и Интернет-технологии в процессе обучения.
контрольная работа [16,8 K], добавлен 30.09.2011Принципы управления знаниями на современном промышленном предприятии, совершенствование методов поиска и обработки информации. Оптимизация баз данных. Обоснования необходимости и цели использования вычислительной техники, программное обеспечение.
дипломная работа [129,5 K], добавлен 21.08.2014Паспорт проекта: идентификация, назначение, исполнители, контрагенты, официальные документы. Объем проекта, ограничения и условия, риски, стадии разработки. Устав, матрица ответственности. Иерархическая структура работ по разработке Web-приложения.
курсовая работа [180,1 K], добавлен 14.08.2011Роль электронных систем управления в деятельности предприятий и организаций. Повышение качества основных процессов муниципального управления культуры Нефтеюганского района; разработка электронной системы управления информацией, оценка ее эффективности.
дипломная работа [2,3 M], добавлен 10.03.2012Анализ предметной области и разработка проекта информационной системы по поддержке пользователей на базе 1С: Предприятие. Проведение формализации логических моделей информационных процессов и процедур в проектной системе. Реализация функций системы 1С.
дипломная работа [1,9 M], добавлен 27.01.2013Анализ предметной области. Обеспечение качества проектной документации. Построение инфологической (концептуальной) модели предметной области. Проектирование физической структуры базы данных. Разработка интерфейса, организация ввода и поиска данных.
курсовая работа [2,5 M], добавлен 10.01.2016
