Разработка системы управления и защиты проектной организации в области информационно-технологического консалтинга

Таким образом, ключевые бизнес-требования к системе можно свести к следующему списку:

1. Отражение всех знаний организации;

2. Классификация знаний;

3. Возможность добавления новых знаний организации (новые знания старых сотрудников или знания новых сотрудников);

4. Возможность вывода знаний на основе действующей модели.

Дополнительно к системе предъявляются нефункциональные требования:

5. Масштабируемость;

6. Возможность интеграции знаний отдельных сотрудников в единую систему самими пользователями;

7. Реализация пользовательских запросов к онтологии;

• 3.2 Разработка верхнеуровневой архитектуры СУЗ
• Схема архитектуры проектируемой корпоративной СУЗ приведена в Приложении 3. СУЗ строится на основе двух групп элементов. Первая группа состоит из инструментов работы с онтологиями, которые включают в себя инструмент логического вывода и автоматической классификации объектов (OWL-reasoner) и обработчик запросов SPARQL. Вторая группа включает в себя интерфейсы выгрузки данных из Корпоративного Хранилища Данных (КХД), корпоративный wiki-портал, систему поддержки принятия решений, реестры и прочие активы организационного процесса. Наконец, онтологии включают в себя ссылки на информационные ресурсы, представленные wiki-порталом, реестрами и активами организационного процесса. Диаграмма архитектуры представлена на следующем рисунке.

Рисунок 3. Верхнеуровневая архитектура

В предлагаемой модели СУЗ задействованы три группы онтологий:

1. мета-онтология, которая состоит из:

1. онтологии представления деятельности;

2. онтологии верхнего уровня;

2. онтологии компании, которая состоит из:

1. онтологии представления консалтинговой предметной области;

2. прикладной онтологии деятельности компании;

3. онтологий проектов, в том числе:

1. онтологий представления предметных областей для портфелей и программ проектов;

2. прикладных онтологий отдельных проектов.

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

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

Задачи вывода знаний включают в себя:

1. нахождение скрытых (неявных) связей;

2. установление связей по аналогии;

Ранее упоминалась СУЗ K-World компании KPMG. Как было замечено, до 70% категорий таксономии относятся к универсальным категориям бизнеса [15]. В предложенной архитектуре СУЗ универсальные категории бизнеса отражены в следующих элементах онтологии:

1. Онтология представления деятельности;

2. Онтология верхнего уровня экономической деятельности;

3. Онтология представления консалтинговой предметной области;

4. Онтологии представления предметных областей заказчиков.

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

• 3.3 Проектирование онтологий
• В рамках данного исследования построение онтологий осуществляется на языке OWL в среде Protege. Как было сказано выше, в данной главе разрабатывается несколько прототипов онтологий для их последующего сравнения и выбора наилучшего варианта для детальной проработки.
• 3.4 Вариант 1. Онтология для эффективных запросов к СУЗ
• Первый вариант онтологии построен с целью повышения эффективности пользовательских запросов, включающих в себя запросы из Приложения 2 (запросы к СУЗ в целом), и содержит следующую иерархию классов (в примере приведена только предметная область проектов в банковской сфере):
• · Документы
• ? Внутренние документы
• ? Проектные документы
• ? Экспертиза
• · Знания субъектов
• · Ошибки
• ? Ошибки по роду деятельности
• ? Ошибки анализа
• ? Ошибки разработки
• ? Ошибки тестирования
• ? Ошибки управления
• · Предметная область
• · Продукты
• ? Банковские продукты
• ? Банковские карты
• ? Депозиты
• ? Кредиты
• ? Прочие банковские продукты
• · Проекты
• ? Внешние проекты
• ? Внутренние проекты
• · Процессы
• ? Банковские процессы
• · Роли
• ? Внешние роли
• ? Внутренние роли
• ? Исполнительские роли
• ? Управленческие роли
• · Субъекты
• ? Персонал
• ? Аналитики
• ? Констультанты
• ? Руководители проектов
• ? Предприятия
• · Сфера деятельности
• В онтологии реализованы следующие виды отношений (объектных свойств):
• · виновен
• · включает
• · владеет
• · допущена
• · имеет носитель
• · исполняет роль
• · нанимает
• · осуществляет деятельность в сфере
• · относится к проекту
• · работает в
• · разрабатывает
• · распространяется на
• · связан с
• · согласует
• · требует знаний
• · участвует в
• Отличительной особенностью данного варианта онтологии является то, что он проектировался исходя из представления концептуальной модели базы данных. Данная онтология представляет собой модель сущностей и связей, представленную в форме иерархической структуры с отдельными связями, нарушающими иерархию, и связывающими элементы структуры. По-сути, данный вариант является эквивалентным типовой ER-модели данных. Являясь традиционным подходом к хранению данных, такое решение нельзя считать заведомо наилучшим в вопросах структурирования знаний в рамках СУЗ, проектируемой на основе онтологического подхода.
• 3.5 Вариант 2. Строгая логическая модель категорий верхнего уровня
• Второй вариант онтологии представляет собой целостную непротиворечивую систему категорий, поддерживающую логический вывод. Такой подход имеет смысл в рамках исследования, поскольку такая модель предполагает возможность автоматизированной классификации объектов знаний, добавляемых в онтологию. Онтология построена на мета-онтологии, состоящей из десяти базовых категорий. Все логически-производные от основных категории реализованы в форме классов-определений (defined class) через отношение эквиваленции. В данной прототипе онтологии измерения, по которым классифицируются понятия (фактически, это измерения многомерного куба категорий), заданы при помощи категорий Качества, Количества и Состояния. Далее приведены построенные категории:
• · Деятельность
• ? Действие
• ? Ошибочное действие
• ? Эталонное действие
• ? Итерация процесса
• ? Завершённая итерация
• ? Планируемая итерация
• ? Текущая итерация
• ? Проект
• ? Коммерческий проект
• · Завершённый коммерческий проект
• ? Неуспешный коммерческий проект
• ? Успешный коммерческий проект
• · Планируемый коммерческий проект
• · Текущий коммерческий проект
• ? Некоммерческий проект
• · Завершённый некоммерческий проект
• ? Неуспешный некоммерческий проект
• ? Успешный некоммерческий проект
• · Планируемый некоммерческий проект
• · Текущий некоммерческий проект
• ? Процесс
• ? Завершённый процесс
• · Неуспешно завершённый процесс
• · Успешно завершённый процесс
• ? Планируемый процесс
• ? Текущий процесс
• ? Этап проекта
• · Качество
• ? Временной статус
• ? Будущий
• ? Прошедний
• ? Текущий
• ? Правильность
• ? Ошибочный
• ? Эталонный
• ? Фиктивность
• ? Настоящий
• ? Фиктивный
• ? Цикличность
• ? Повторяемый
• ? Разовый
• · Количество
• ? Множественность
• ? Много
• ? Один
• · Состояние
• ? Результат
• ? Не целевой результат
• ? Целевой результат
• ? Статус
• ? Статус согласования
• · На рассмотрении
• · Утверждённый
• · Отклонённый
• ? Цель
• ? Коммерческая цель
• ? Некоммерческая цель
• ? Роль
• ? Автор
• ? Должность
• ? Проектная роль
• ? Согласующий
• · Сущность
• ? Дух
• ? Идея
• ? Информация
• ? Материя
• ? Объект
• · Документ
• ? Не требующий согласования документ
• ? Требующий согласования документ
• ? Проектный документ
• ? Согласуемый внутренний документ
• ? Субъект
• · Государство
• · Группа лиц
• · Индивидуальное лицо
• ? Физическое лицо
• ? Юридическое лицо
• Таким образом, данный вариант онтологии отличает построение строгой формальной иерархической структуры, берущей начало с базовых абстрактных понятий. Особенностью такой концептуальной модели является повышенное внимание иерархическим связям, частично в ущерб связям семантическим и ассоциативным, которым уделено внимание в следующем варианте онтологии.
• 3.6 Вариант 3. Ассоциативная индивидуальная онтология
• Третий вариант онтологии сильно отличается от первых двух. В третьем используется ассоциативный подход, то есть одной из предпосылок для данной онтологии является ассоциативность человеческого мышления и человеческой памяти. Поскольку у самой организации независимых от сотрудников знаний нет, все знания организации формируются сотрудниками. Рассматриваемый прототип представляет собой ассоциативную сеть, реализованную в форме онтологии, построенную на индивидуальных понятиях, то есть экземплярах классов, а не самих классах.
• Диаграмма связей элементов онтологии приведена в Приложении 4. На диаграмме отражены только те элементы, которые состоят в связи. Элементы принадлежат категориям Банковские технологии и Проектные технологии. Сами категории, то есть классы выполняют функцию директорий для размещения экземпляров.
• В прототипе использовался только один тип связей, поскольку написание запросов обычными пользователями, когда число видов связей велико, является крайне сложной задачей. Таким образом, с целью повышения удобства использования проектируемой онтологии, как элемента СУЗ, используется только один вид связей, а именно связь connectedWith. Отдельно следует заметить, что ограничение на количество типов связей применяется на начальном этапе развития онтологии, и помех для внедрения новых типов связей при последующих доработках модели нет.
• 3.7 Сравнительный анализ спроектированных онтологий
• Первый прототип онтологии был построен с целью повышения эффективности выполнения запросов. Однако, этот вариант не позволяет осуществлять вывод знаний, поскольку не имеет соответствующей системы категорий. В данном прототипе реализуются запросы к реестрам, но с точки зрения архитектурного решения, онтологии не должны пересекаться с реестрами и журналами (например, реестр проектов, журнал ошибок, реестр компетенций сотрудников). С этой точки зрения первый прототип представляет собой интересное решение, но не подходящее для текущего исследования в части пользовательских запросов к СУЗ.
• Второй прототип, подобно первому, реализует категории для запросов к реестрам и прочей информации, хранение которой корректнее реализовать в реляционной схеме, а не онтологии. В отличие от первого прототипа, второй построен с поддержкой автоматизированной классификации индивидуальных понятий. Тем не менее, этот вариант также не годится на роль онтологии в рамках предложенной архитектуры.
• Третий прототип спроектирован в виде ассоциативной онтологии, что позволяет писать ключевые запросы к онтологии, незаменимые другими подсистемами СУЗ. Этот факт делает этот вариант наиболее перспективным для дальнейшей проработки, которая выполнена в главе 3.5.

• 3.8 Детальная проработка выбранного варианта онтологии
• Среди трёх вариантов построения онтологии была выбрана ассоциативная онтология, состоящая из экземпляров без классов. Фактически, такая онтология представляет собой отражение индивидуальных ассоциаций экспертов. Поскольку целью данной работы является разработка корпоративной СУЗ, индивидуальные онтологии должны быть некоторым образом интегрированы в общую систему знаний компании. Индивидуальные онтологии, таким образом, являются промежуточным звеном в процессе построения единой онтологии, а не целевой моделью.
• Авторы Гаврилова Т.А. и Хорошевский В.Ф. для выявления знаний [19] предлагают использовать понятие "поле знаний", под которым понимается субъективное неформализованное множество понятий и связей между ними. В данном исследовании полю знаний соответствует индивидуальная ассоциативная сеть. Авторы называют процесс извлечения знаний "узким местом" в проектировании СУЗ. Поэтому при разработке СУЗ необходимо детально прорабатывать процесс сбора знаний, который будет применяться при промышленной эксплуатации системы. При построении процесса развития онтологии требуется учесть возможные типы преобразования знаний.
• Авторы И.Нонака и Х.Такеучи выделяли четыре типа преобразований знаний [18]:
• 1. Неформализованное > Неформализованное;
• 2. Неформализованное > Формализованное;
• 3. Формализованное > Формализованное;
• 4. Формализованное > Неформализованное;
• Точное отражение всех знаний экспертов о предметной области за один проход маловероятно. Для построения онтологии целесообразно применять итеративный подход. Более того, появление новых экспертов и развитие индивидуальных знаний вынуждает подходить к построению онтологии как к бизнес-процессу, а не как в разовому проекту.
• На основе четырёх типов преобразований знаний Нонака и Такеучи можно предложить следующий бизнес-процесс развития онтологии компании:
• 1. подготовка опросных листов по предметным областям;
• 2. сбор ключевых понятий в отобранных предметных областях у сотрудников;
• 3. подготовка опросных листов для сбора ассоциаций по ключевым понятиям;
• 4. сбор ассоциаций для ключевых понятий у сотрудников;
• 5. анализ семантических связей: синонимии, омонимии, ...
• 6. формализация индивидуальных ассоциаций и их интеграция в общую онтологию;
• 7. детализация типов связей (object properties);
• 8. обогащение онтологии свойствами понятий (data properties);
• 9. проработка логических ограничений и тестирование логической целостности;
• 10. работа с онтологией: извлечение/вывод знаний;
• Схема бизнес-процесса представлена в Приложении 5.
• Возможный вариант заполненного опросного листа для сбора ассоциаций представлен в следующей таблице:

Предметная область	Ключевые понятия области
Банковская предметная область	кредит, депозит, банковская карта, риск-менеджмент, CRM, коммуникация, финансы, коллекторская служба, процентная ставка, ЦБ, ценные бумаги, валюта, РКО, кредитный конвейер, брокерское обслуживание, ставка рефинансирования, кредитный договор, ...
Предметная область интеллектуальных ИС	КХД, BI, Data mining, мастер-система, ETL, DMSS, статистика, аналитика, ...
Предметная область телеком	…

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

Понятие	Ассоциированные понятия
Кредитная карта	кредит, банковская карта, процессинг, кредитный договор, карточный договор, овердрафт, перевыпуск, зарплатная карта, зарплатный проект, карточная иерархия, платиновая карта, пакет обслуживания, платёжная система, дебетовая карта, кредитный лимит, мастер-счёт, пин-код, карточная транзакция, …
Коммуникация	лид, канал, локатор, телефон, e-mail, АТМ, нотификация, …
Кредитный конвейер	кредит, заявка на кредит, протокол, отказ, СПЗ, скоринг, кредитная история, НБКИ, …
Депозит	депозитный договор, текущий счёт, пассив, договор иррегулярной поклажи, норма резервирования, депозит до востребования, целевой депозит, ипотечный вклад, пролонгация, вклад, сберегательный счёт, собственные средства, дебетовая карта, …
Брокерское обслуживание	счёт ДЕПО, маржинальная торговля, стоп-лосс, реестр акционеров, собрание акционеров, национальный депозитарий, текущий счёт, торговая система, торговый терминал, …
...	...

• Для формализации индивидуальных ассоциаций удобно использовать предложенную ранее ассоциативную онтологию, в которой эксперт по анализируемой предметной области должен указать связи и иерархию предложенных понятий. Совместная работа эксперта и инженера онтологии позволяет помимо установления связей выполнить задачу верификации, то есть проверки правильности отражения понимания знаний эксперта онтологическим инженером.
• Возможный результат проработки индивидуальной онтологии для приведённых выше заполненных опросных листов представлен на рисунке 1. На этом этапе используется один тип связей (object property).

Рисунок 4: Индивидуальная онтология

На следующем шаге индивидуальная онтология интегрируется в единую онтологию. На рисунке 2 представлен пример интеграции построенной выше индивидуальной онтологии в единую онтологию:

Рисунок 5: Интеграция индивидуальных онтологий

В соответствии с предложенной ранее иерархией онтологий необходимо провести интеграцию предложенного процесса с онтологическим ядром архитектуры СУЗ. Для этого требуется детальный анализ каждого уровня архитектуры с точки зрения построения процесса сбора знаний и их формализации в единой онтологии.

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

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

• 3.9 Решение пользовательских задач с помощью построенной онтологии корпоративной СУЗ
• В приложении 4 приведены примеры запросов построенной ассоциативной онтологии. Типовые запросы можно формализовать, облегчив работу пользователей с онтологией.
• На практике предлагается следующая методика использования онтологии. Приведённая онтология (вариант 3) представляет собой пример индивидуальной онтологии, то есть онтологии, отражающий ассоциативную сеть одного сотрудника. Предлагается под руководством специалиста по управлению знаниями собирать такие онтологии со всех сотрудников, обладающих ценной экспертизой, после чего объединять эти ассоциативные сети в единую онтологии.
• Построенная таким образом из множества индивидуальных онтологий единая онтология позволяет осуществлять навигацию по знаниям, выполнять запросы к знаниям и, самое главное, осуществлять вывод знаний.
• Вывод знаний в такой онтологии выполняется через выявление новых связей между тесно связанными узлами. Теснота связей между двумя концептами определяется через их общие связи с учётом направлений.
• Полученная единая онтология позволяет выводить окружение любого интересующего понятия. Так, можно вывести все предшествующие и последующие понятия в иерархии, а также все понятия, с которыми интересующее понятие связано.
• Также следует заметить, что для корректной отработки запросов на вывод связанных понятий необходимо разделять аксиомы под-классов (split subClass axioms) на отдельные атомарные аксиомы. Альтернативный вариант заключается в изначальном написании аксиом в атомарном виде.
• В процессе реализации методики создаётся несколько онтологий: индивидуальные онтологии для анализа индивидуальной ассоциативной сети для решения задач интеграции и единая интегрированная онтология. Запросы на языке SPARQL могут применяться на разных стадиях методики к разным онтологиям. Запросы можно классифицировать следующим образом:
• · отображение ассоциативного окружения;
• · отображение количественных метрик онтологии (например, мощность исходящих/входящих понятий или расстояние между понятиями);
• · поиск понятий по онтологии;
• · поиск понятийных кластеров с использованием метрик;
• · другое.
• Примеры запросов, демонстрирующие гибкость языка SPARQL для решения пользовательских задач, приведены в Приложении 4. Типовые пользовательские запросы приведены в Приложении 2.
• 
• Заключение
• В рамках магистерской диссертации на тему "Разработка СУЗ консалтинговой проектной организации".была разработана архитектура СУЗ и спроектированы несколько вариантов онтологий. Спроектированные варианты онтологий были проанализированы, был отобран вариант, в наибольшей степени соответствующий сформулированным ранее требованиям, после чего была создана методика разработки и развития онтологии.
• Разработанная архитектура СУЗ задействует онтологический подход, в контексте которого онтологии выполняют интегрирующую роль, объединяя прочие источники знаний в единой формальной структуре иерархической понятийной классификации.
• Были рассмотрены несколько подходов к проектированию онтологий. Подход к онтологии, как к базе данных, позволяет быстро построить целевую онтологию, поскольку используется широко распространённое знание реляционной теории баз данных. Был выявлен недостаток такого подхода, заключающейся одновременно в трудности решения пользовательских задач на такой онтологии и в невозможности представления индивидуальных знаний. Был рассмотрен подход к онтологии, как формальной иерархии, в рамках которого онтология использовалась в качестве таксономии, то есть данный подход не задействовал возможностей онтологии, выходящих за границы таксономий. В таком подходе был выявлен недостаток возможностей отражения индивидуальных ассоциаций и вывода знаний. Был разработан ассоциативный подход, в основе которого лежит представление о знаниях агентов, как ассоциативной сети. Сбор индивидуальных ассоциаций над полем категорий позволяет отразить в онтологии актуальную систему связей между категориями. Собранные индивидуальные сети ассоциаций интегрируются в единую онтологию, приводятся к формальной иерархической структуре, дополняется логическими ограничениями в форме дескриптивной логики и обогащается семантическими связями. Построенная таким образом онтология легко модифицируется, что является необходимым требованием к СУЗ проектной организации в области ИТ-консалтинга.
• На основе рассмотренных вариантов онтологий была разработана методика построения и развития онтологий для корпоративной СУЗ. В основании данной методики находятся процессы сбора индивидуальных ассоциаций, интегрируемых в единую онтологию. Предложенная методика позволяет реализацию в качесте процесса управления .корпоративными знаниями, что определяет особую практическую значимость проведённого исследования.
• При построении онтологий была решена частная задача моделирования многомерных знаний. Предложенное решение предполагает горизонтальное одноуровневое представление категорий в качестве прямых потомков одной родительской категории, относящихся к разным основаниям классификации, но имеющих общего понятийного предка.
• Онтология в контексте СУЗ предназначена для сбора знаний, формализации индивидуальных знаний, предоставления знаний в ответ на запросы бизнес-пользователей, а также вывода новых знаний.
• В магистерской диссертации были изучены и проанализированы существующие подходы к работе с корпоративными знаниями, рассмотрены варианты использования и проектирования СУЗ на основе онтологий.
• Полученные результаты имеют практическую и научную ценность. Научная ценность заключается в применении ассоциативных онтологий для моделирования знаний, что может найти отражение как в областях управления знаниями, так и в области разработок искусственного интеллекта. Помимо этого научную ценность имеет решение проблемы многомерных категорий.
• Практическая ценность исследования заключается в том, что были сформулированы требования к СУЗ, разработана онтология и создана методика разработки онтологий для управления корпоративными знаниями в проектной организации в области ИТ-консалтинга.

• Список используемой литературы

1. http://www.pmi.org/About-Us.aspx

2. http://office.microsoft.com/ru-ru/project-help/HA010351563.aspx

3. http://www.gartner.com/newsroom/id/2481915

4. http://www.computerliteracy.co.uk/microsoft_project_versions.html

5. P.F.Drucker. Managing for Results. Economic Tasks and Risk-taking Decisions. -- Heinemann Professional Publishing. 1964. -- 224p

6. Harvard Business Review, 69, November-December (1991)

7. Kaj U. Koskinen. Autopoietic Knowledge Systems in Project-Based Companies. -- Palgrave Macmillan. 2010. -- 227p.

8. C. Bentley. Prince2. A Practical Handbook. -- Elsevier Ltd. 2010. -- 322p.

9. Journal of Project, Program & Portfolio Management Vol 1 No 2 (2010)

10. A Guide to the Project Management Body of Knowledge (PMBOK Guide). -- PMI, Inc. 2013. -- 590p.

11. Steffen Staab, Rudi Studer. Handbook on Ontologies. -- Springer-Verlag. 2009. -- 811p.

12. Ling Liu, M.Tamer Цzsu. Encyclopedia of Database Systems. -- Springer. 2009. -- 3749p

13. B.Chandrasekaran, John R.Josephson. What Are Ontologies, and Why Do We Need Them? -- IEEE Intelligent Systems. 1999. -- pp.20-26.

14. Ibima Business Review, Vol 3 (2009)

15. Information Resources Management Association. Organizational Learning and Knowledge: Concepts. Methodologies, Tools, and Applications. Volume 1. -- Information Science Reference. 2012. -- 3164p.

16. Кудрявцев Д.В. Системы управления знаниями и применение онтологий. СПБ.:Изд-во Политехн. ун-та. 2010. -- 344с

17. F.Burstein, C.W.Holsapple. Handbook on Decision Support Systems. -- Springer. 2008. -- 798p.

18. R.Kishore, R.Ramesh. Ontologies. A Handbook of Principles, Concepts, and Applications in Information Systems. -- Springer. 2007. -- 930p

19. T. R. Gruber. Automated Knowledge Acquisition for Strategic Knowledge. Machine Learning, Kluwer Academic Publishers, 293-336, 1989.

20. Нонака Икуджиро, Такеучи Хиротака. Компания -- создатель знания. Зарождение и развитие инновация в японских фирмах./Пер с анлг. А Трактин. -- М.: ЗАО "Олимп-Бизнес", 2011. -- 384с.

21. Т.А.Гаврилова, В.Ф.Хорошевский. Базы знаний интеллектуальных систем. -- СПБ.Питер. 2001. -- 384с.

22. Kozaki K., Hayashi Y., Sasajima M., Tarumi S., Mizoguchi R. Understanding Semantic Web Applications. Proc. of the 3rd Asian Semantic Web Conference (ASWC 2008), December 8-11, Bangkok, Thailand, 2008. -- 572p.

23. Edward von Wasielewski. Project Knowledge Management. Systematic Learning with Project Comparison Technique. Trans. Lore Mair. -- Springer. 2010. - 175p.

24. Igor Jurisica, John Mylopoulos, Eric Yu, Annual Conference of the American Society for Information Science, Washington, D.C., November 1-4, 1999.

25. J.Martin Serrano Orozco. Applied Ontology Engineering in Cloud Services, Networks and Management Systems. -- Springer. 2012. -- 189p.

26. Domingue J, Anutariya Ch. 3rd Asian Semantic Web Conference (ASWC 2008), Bangkok, Thailand, December 8-11, 2008. -- 556p.

27. Тельнов Ю.Ф. Интеллектуальные информационные системы. Московский международный институт эконометрики, информатики, финансов и права. - М., 2004. - 82с.

28. Тельнов Ю.Ф., Казаков В. Проектирование систем управления знаниями. М.:Издательский центр ЕАОИ, 2011. - 208с.



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

Рисунок 6 Процесс найма персонала Ч1.

Рисунок 7 Процесс найма персонала Ч2

Процесс проведения интервью для выявления знаний представлен на следующих рисунках.

Рисунок 8 Процесс интервьюирования Ч1

Рисунок 9 Процесс интервьюирования Ч2

Рисунок 10 Процесс интервьюирования Ч3

Процесс анализа требований, разработки и согласования экспертизы приведён далее.

Размещено на Allbest.ru

Рисунок 11 Анализ требований и Экспертиза Ч1

Рисунок 12 Анализ требований и Экспертиза Ч2

Рисунок 13 Анализ требований и Экспертиза Ч3

Процесс найма персонала представлен на следующих рисунках.

Рисунок 14 Процесс тестирования Ч1

Рисунок 15 Процесс тестирования Ч2



• Приложение 2. Перечень типовых запросов к онтологии
• В приложении приведены типовые запросы пользователей к СУЗ, сформулированные в бизнес-терминах.
• 1. Вывести знания об определённой предметной области всех сотрудников данного заказчика, которые согласуют некоторый документ по рассматриваемому проекту
• 2. Вывести все ошибки, которые допускает некоторая категория сотрудников при выполнении определённых работ в рассматриваемых проектах, упорядочить по частоте.
• 3. Вывести все знания о некотором продукте, необходимые для определённого проекта.
• 4. Вывести лучшие практики по рассматриваемому виду активности, которые охватывают знания, необходимые для выполнение некоторого проекта.
• 5. Вывести всех сотрудников, которые обладают необходимыми знаниями для проведения тестирования в рамках определённого проекта.
• 6. Вывести знания, отсутствие которых вызвало топ-5 по числу ошибок на проектах рассматриваемого направления.
• 7. Вывести все руководства и книги, которые способствуют либо необходимы для получения сертификата по определённому продукту.
• 8. Вывести всех сотрудников компании, которые имеют целевые сертификаты.
• Перечисленные запросы не относятся к онтологии, поскольку реализуются другими частями архитектуры СУЗ.
• Вся информация о сертификатах, руководствах, книгах и ссылках на лучшие практики может хранится на корпоративном wiki-портале. Но онтология в качестве экземпляров может хранить адресные ссылки на реальные источники знаний.
• Разнообразные реестры ошибок, сотрудников и проектов наиболее естественным образом укладываются в реляционную схему. Необходимости включить их в онтологию нет.
• Эти факты задают границы разрабатываемой онтологии, поскольку часть требований к СУЗ выполняется вне онтологии.
• 
• Приложение 3. Диаграммы онтологий
• Онтология 1. Онтология для эффективных запросов к СУЗ
• На диаграмме отображены классы и связи между ними (отношения subClassOf не показаны). На следующем рисунке отображены только те классы, которые связаны отношениями.

Рисунок 16 Онтология версии 1

• Онтология 2. Логическая модель категорий верхнего уровня
• На диаграмме показан пример определяемых категорий:

Рисунок 17 Онтология вариант 2



Онтология 3. Ассоциативная индивидуальная онтология

На следующем рисунке приведена диаграмма ассоциаций третьего прототипа онтологии.

Рисунок 18 Ассоциативная онтология



• Приложение 4. Реализация запросов к онтологии на языке SPARQL
• Следующий запрос выводит ближайшее окружение понятия (на примере понятия "Кредит"):
• PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
• PREFIX owl: <http://www.w3.org/2002/07/owl#>
• PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
• PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
• PREFIX : <http://www.semanticweb.org/evgeny/ontologies/2015/1/untitled-ontology-66#>
• SELECT * {
• {SELECT ('понятие Кредит связано с' as ?connection) (?sub as ?area) {
• ?super :connectedWith+ ?sub.
• filter (?super != ?sub && ?super = :Кредит)
• } order by ?super ?sub}
• UNION
• {SELECT ('с понятием Кредит связано понятие' as ?connection) (?super as ?area) {
• ?super :connectedWith+ ?sub.
• filter (?super != ?sub && ?sub = :Кредит)
• } order by ?super ?sub}}
• Запрос выдаёт следующий результат:

Таблица 1: Вывод окружения понятия

Описание связи	Связанная категория
понятие Кредит связано с понятием	Кредитный договор
с понятием Кредит связано понятие	Кредитная карта
с понятием Кредит связано понятие	Возобновляемая кредитная линия
с понятием Кредит связано понятие	Страховка



Вывод ассоциаций, связанных с экземплярами подклассов класса "Проектные_технологии":

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

PREFIX owl: <http://www.w3.org/2002/07/owl#>

PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

PREFIX : <http://www.semanticweb.org/evgeny/ontologies/2015/1/untitled-ontology-66#>

SELECT distinct ?super ?sub {

?super :connectedWith* ?mid.

?mid :connectedWith+ ?sub.

?s rdfs:subClassOf+ :Проектные_технологии.

?super a ?s.

filter(?super != ?sub)

}

order by ?super ?sub

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

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

PREFIX owl: <http://www.w3.org/2002/07/owl#>

PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

PREFIX : <http://www.semanticweb.org/evgeny/ontologies/2015/1/untitled-ontology-58#>

SELECT ?super (count(?sub) as ?power) {

?super :connectedWith+ ?sub.

filter(?super != ?sub)

}

group by ?super

order by desc(?power) ?super



• Приложение 5. Бизнес-процесс управления онтологией
• На следующем рисунке представлен бизнес-процесс по построению и развитию онтологии.

Рисунок 19 Процесс управления онтологией

Размещено на Allbest.ru

...