Размещено на http://www.allbest.ru/

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ

«НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ

«ВЫСШАЯ ШКОЛА ЭКОНОМИКИ»

Факультет бизнеса и менеджмента

Выпускная квалификационная работа

по направлению подготовки 38.03.05 «Бизнес-Информатика»

образовательная программа «Бизнес-Информатика»

Разработка системы управления знаниями для проектно-ориентированных компаний

Трушин Виктор

Москва 2018



СОДЕРЖАНИЕ

• ВВЕДЕНИЕ
• ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ УПРАВЛЕНИЯ ЗНАНИЯМИ В ПРОЕКТНО-ОРИЕНТИРОВАННЫХ КОМПАНИЯХ
• ГЛАВА 2. РАЗРАБОТКА СИСТЕМЫ УПРАВЛЕНИЯ ЗНАНИЯМИ
• 2.1 Проектирование системы
• 2.1.1 Функциональные требования системы
• 2.1.2 Проектирование пользовательского взаимодействия
• 2.1.3 Разработка архитектура системы
• 2.2 Разработка базы данных
• 2.3 Серверная часть системы
• 2.3.1 Настройка подключения к базе данных
• 2.3.2 Аутентификация и авторизация пользователей в системе
• 2.3.3 Проектирование и реализация программного интерфейса
• 2.4 Клиентская часть системы
• 2.4.1 Схема страниц клиентской части системы
• 2.4.2 Разработка интерфейса клиентской части
• 2.4.3 Реализация функционала клиентской части
• 2.5 Сборка и развертывание системы управления знаниями
• ГЛАВА 3. ОСОБЕННОСТИ ВНЕДРЕНИЯ СИСТЕМЫ УПРАВЛЕНИЯ ЗНАНИЯМИ
• ЗАКЛЮЧЕНИЕ
• СПИСОК ЛИТЕРАТУРЫ


ВВЕДЕНИЕ

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

Также стоит отметить, что наибольшую потребность в эффективном управлении знаниями испытывают проектно-ориентированные компании. Одним из основных инструментов по реализации управления знаниями на практике является система управления знаниями - корпоративная информационная система, в задачи которой входит поддержание процессов хранения, поиска и создания новых интеллектуальных ресурсов. Данная работа посвящена разработке системы управления знаниями для проектно-ориентированных компаний, поскольку проектно-ориентированные компании наиболее подвержены влиянию внешней среды, а потому нуждаются в применении практик управления знаниями и соответствующего инструментария [1]. На данный момент существуют системы управления знаниями, предоставляющие доступ компаниям по подписке с размещением системы на серверах сервиса. Однако часто возникает потребность в размещении информационной системы на собственных мощностях компании с целью защиты хранимых с ее помощью данных. Решения, существующие на рынке, обладают в таком случае рядом недостатков: высокая стоимость решения при его развертывании на собственных мощностях компании, слабая интеграция с существующей ИТ-инфраструктурой компании и слабо проработанный методологический базис по управлению знаниями, поддержку которого осуществляет система управления знаниями. По этой причине разработка системы управления знаниями на основе существующих методик по управлению знаниями в проектно-ориентированных компаниях в качестве коробочного решения является актуальной.

Таким образом, объектом данного исследования является управление знаниями. Предметом исследования является управление знаниями, применяемое в проектно-ориентированных компаниях.

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

1. Изучить основы управления знаниями, а также особенности управления знаниями в проектно-ориентированных компаниях.

2. Выявить функциональные требования системы управления знаниями

3. Спроектировать основные сценарии пользовательского взаимодействия с системой

4. Разработать архитектуру системы управления знаниями

5. Разработать базу данных

6. Спроектировать и разработать серверную часть системы

7. Спроектировать и разработать клиентскую часть системы

8. Настроить сборку системы управления знаниями в качестве коробочного решения

9. Разработать план внедрения системы в проектно-ориентированных компаниях и выявить особенности процесса внедрения

Методы исследования включают в себя теоретические методы, а именно анализ, изучение и обобщение. Также были применены практические методы, включающие методы проектирования схем реляционных баз данных, методы объектно-ориентированного и реактивного программирования.

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

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

ГЛАВА 1. ТЕОРЕТИЧЕСКИЕ ОСНОВЫ УПРАВЛЕНИЯ ЗНАНИЯМИ В ПРОЕКТНО-ОРИЕНТИРОВАННЫХ КОМПАНИЯХ

Управление знаниями устоялось как научная дисциплина в последнем десятилетии 20-ого века благодаря вкладу таких исследователей, как И. Нонака, Х. Такеучи и Т. Дэвенпорт. Данное направление в сфере менеджмента в дальнейшем было изучено с различных сторон, включая связь управления знаниями с культурными, социальными и другими особенностями компании.

Дэвенпорт и Прусак [2] определяют знания, как смесь опыта, ценностей, контекста и экспертных оценок, которые формируют подход к оцениванию и применению нового опыта и информации. Знания часто отражены в виде документов и регламентов, или посредством организационных процедур, процессов, практик и норм. Также стоит отметить, что знания можно разделить по типу на явные (explicit) и неявные (tacit). Нонака [3] определяет явные знания как знания, которые могут быть выражены словами или числами в то время, как неявные знания состоят из опыта людей, который не может быть с легкостью формализован. Неявные знания по своей сути являются ноу-хау, приобретенные посредством человеческого опыта.

При изучении управления знаниями важно понимать различие между информацией, данными и знаниями, которые зачастую путают между собой. Данные представляют собой необработанный набор фактов без контекста. Данные сами по себе не имеют большой ценности для организаций. Однако при агрегировании данные трансформируются в информацию, которая затем преобразуется в знания при помощи формирования логичного и легко понятного контекста [4].

Согласно Алави и Лейднеру [5], управление знаниями представляет собой системный и организационно определенный процесс приобретения, организации и передачи как явных, так и неявных знаний сотрудников, чтобы другие сотрудники могли использовать его для повышения собственной эффективности и результативности. Также стоит отметить, что знания не статичны - они имеют тенденцию трансформироваться и изменяться от явных к неявным и обратно. Изучение таких процессов и составляет основную направленность управления знаниями как научной дисциплины. Процесс трансформации знаний условно можно разделить на 6 производных процессов: управление знание пользовательский архитектура

· Создание знаний. Знания преимущественно создаются за счет опыта и умений сотрудников в процессе выявления инновационных способов создания продуктов или разработки ноу-хау. Также знания могут быть получены вне деятельности организации за счет внешних источников.

· Выявление знаний. Созданные знания необходимо выделить и сохранить в том или ином виде для дальнейшего использования.

· Уточнение знаний. Инновационные знания должны быть использованы в определенном контексте. На этом этапе неявные знания сотрудников формализуются и трансформируются в явные.

· Сохранение знаний. Формализованные в явном виде знания необходимо сохранить в некоторого рода базах данных для их дальнейшего использования.

· Управление знаниями. Знания должны периодически быть пересмотрены для поддержания актуальности и точности интеллектуальных ресурсов компании. Стоит отметить, что многие компании содержат департаменты, в задачи которых входит именно поддержание актуальности интеллектуальных ресурсов.

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

Для описания приведенных выше процессов трансформации знаний, Нонака, Тойама и Конно [6] разработали SECI модель, состоящую из 4-х этапов: социализация, экстернализация, комбинация и интернализация. Данная модель является одной из фундаментальных моделей в управлении знаниями.

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

· Меж-проектная коммуникация и распределение знаний

· Формализация интеллектуальных ресурсов, полученных в процессе деятельности проекта, для дальнейшего использования в смежных или подобных проектах

· Риски, связанные с уходом из компании квалифицированных работников

· Риски, связанные с быстрым расширением проектов и необходимостью найма и обучения новых сотрудников

· Эффективное формирование проектных команд по компетенциям сотрудников и их опыту

· Сохранение и переиспользование интеллектуальных ресурсов, созданных в процессе жизненного цикла проекта

· Поддержание актуальности интеллектуальных ресурсов компании

Все вышеперечисленные проблемы решаемы за счет применения методик по управлению знаниями. В сфере управления знаниями было проведено немало исследований в области применения техник по управлению знаниями в проектно-ориентированных компаниях такими исследователями, как Аджамал М. М. [7] и Алексеев А. [8]. Отдельно следует выделить исследование механизмов управления знаниями в проектных компаниях, проведенное исследователями Лоури-Федида, Мессионер и Саглиетто в 2014 году [9]. В рамках исследования были выделены 3 основные проблемы, с которыми сталкиваются компании при управлении знаниями:

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

2. Компании слабо адоптируют механизмы по выявлению и сохранению знаний, полученных в результате проектной деятельности

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

В рамках своего исследования авторы провели анализ проектной деятельности 4-х компаний: IBM, Hewlett-Packard, Arkopharma и Temex. В результате авторы вывели 8 механизмов управления знаниями, используемых в представленных компаниях:

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

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

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

4. Профессиональные группы - коллаборация сотрудников компании со сходными профессиональными интересами. При этом разработка новых знаний ведется вне проектной деятельности при изучении сотрудниками различных тематик.

5. Физическая близость взаимодействующих субъектов проекта. Исследуемые компании направляли усилия для размещения взаимодействующих субъектов в рамках одного проекта как можно ближе друг к другу, что дает свои преимущества в процессе коммуникации между сотрудниками.

6. Меж-проектные встречи - возможность сравнения проектной деятельности, выявления и передачи проектного опыта между различными командами.

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

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

Приведенные выше механизмы так или иначе могут быть использованы в любых проектно-ориентированных компаниях, что позволит компаниям повысить конкурентоспособность продуктов, а также улучшить устойчивость на рынке. В основе большинства процессов и практик по управлению знаниями в компаниях лежит формализация знаний в том или ином виде и их передача. Для этих целей крупные проектные компании, такие как HP и IBM используют внутренние системы управления знаниями, которые специально адаптированы под внутренние процессы компаний. На данный момент существует также некоторое количество систем управления знаниями, доступных для использования по подписке. Среди них стоит отметить Sabio, Confluence [11] и KBPublisher. Однако все перечисленные продукты имеют ряд недостатков:

· Высокая стоимость подписки, неоправданная для использования в малых компаниях

· Слабая реализация методик и практик по управлению знаниями применимо к проектно-ориентированным компаниям

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

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

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



ГЛАВА 2. РАЗРАБОТКА СИСТЕМЫ УПРАВЛЕНИЯ ЗНАНИЯМИ

2.1 Проектирование системы

2.1.1 Функциональные требования системы

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

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

· Разграничение прав доступа к интеллектуальным ресурсам. Управление правами доступа к информации крайне важно при управлении знаниями, поскольку позволяет как уменьшить риски, связанные с утечкой знаний, так и упростить поиск необходимой информации.

· Комментирование и прикрепление заметок к хранимым единицам. Этот пункт требований относится к коммуникативным техникам, реализуемым системой. Однако очевидно, что основное общение и обмен знаниями должны производиться вне системы управления знаниями. Комментирование и прикрепление заметок призвано дать обратную связь менеджерам по наличию неточностей в интеллектуальных ресурсах.

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

· Масштабируемость системы в плане расширения функционала и в плане интеграции с внешними системами и сервисами. Масштабируемость системы крайне важна при изменении ИТ-инфраструктуры компании или в процессе интеграции новых информационных систем.

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

· Гибкая и настраиваемая структура контента. Результатом формализации интеллектуальных ресурсов компании может послужить сложная структура взаимозависимых документов. Для отражения возможной структуры необходимо предоставить возможность пользователям системы реализовывать вложение документов и их ветвление.

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

· Реализация СУЗ в качестве коробочного решения. Сохранность интеллектуальных ресурсов компании - важнейшая задача обеспечения безопасности компании. Реализация СУЗ в качестве коробочного решения позволит интегрировать систему в интранет компании, изолированный от внешней среды, что позволит хеджировать риски по утечке критически важных знаний, хранимых в системе. Кроме того, реализация СУЗ в качестве коробочного решения позволит с минимальными трудозатратами реализовать облачный сервис по управлению знаниями, которым могли бы пользоваться малые компании с получением доступа по подписке.

· Удобный текстовый редактор. Очевидно, что наиболее часто пользователи будут создавать и редактировать новые документы. Поэтому крайне важно реализовать удобный текстовый редактор для набора и редактирования текстов для того, чтобы сократить время, которое сотрудник тратит на взаимодействие с системой и, в свою очередь, мог бы использовать для проектной деятельности.

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

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

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

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

После выделения базового и дополнительного наборов функциональных возможностей системы был составлен план их реализации:

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

2. Проектирование базы данных системы. База данных должна соответствовать требованиям архитектуры и выделенного ранее функционала. Также важно оптимизировать схему базы данных для более эффективного хранения и выборки данных.

3. Проектирование и разработка серверной части приложения. На этом этапе следует разработать программный интерфейс, по которому клиентская часть приложения будет взаимодействовать с серверной частью и, затем, реализовать его.

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

5. Размещение системы управления знаниями на сервере. Заключительный этап процесса разработки системы заключается в его упаковке в качестве коробочного решения и размещения на сервере для дальнейшего тестирования системы и применения на практике реализованного функционала.

Результатом процесса разработки системы будет служить система управления знаниями, представленная коробочным решением, реализующим набор функций необходимых для соответствия концепции Minimal Viable Product (MVP). При этом MVP должен в обязательном порядке соответствовать базовому набору требований и реализовывать дополнительный функционал, выделенный выше. Реализация СУЗ в формате MVP позволить проверить востребованность системы на практике и получить обратную связь от компаний по дальнейшему направлению развития и совершенствования системы. Также стоит отметить, что разработанная в рамках текущей работы система в дальнейшем может быть использована для создания онлайн-сервиса, предоставляющего платформу для управления знаниями в малых проектно-ориентированных компаниях. Также сервис может предоставить возможность компаниям автоматизированное развертывание СУЗ в ИТ инфраструктуре компании.

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

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

В процессе проектирования было выделено несколько основных сценариев взаимодействия пользователя с системой:

· Авторизация и регистрация сотрудников в системе

· Навигация по системе и поиск необходимого материала

· Написание и редактирование документов

· Управление настройками системы

Далее подробнее рассмотрим каждый из сценариев в отдельности.

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

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

Авторизация сотрудников в системе должна производиться со страницы авторизации при введении соответствующих данных аккаунта: почтового адреса, использованного для регистрации, и пароля. В случае, если введенные данные верны, пользователь будет перенаправлен на главную страницу СУЗ.

Такая схема авторизации пользователей является наиболее простой в реализации и потому была выбрана для реализации MVP продукта. Однако при дальнейшем развитии системы стоит добавить функционал двухфакторной аутентификации, что позволит добавить еще одну прослойку для защиты хранимой в системе информации.

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

· Боковое меню навигации - содержит ссылки на основные страницы системы, а также на проекты, участником которых является пользователь

· Форма поиска. При введении поискового запроса пользователю будут предложены различные варианты выдачи, при нажатии на которые он будет перенаправлен в соответствующий раздел системы

· Окно оповещений - содержит список оповещений системы, связанных с пользователем, при нажатии на которые он будет перенаправлен в соответствующий раздел системы

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

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

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

2.1.3 Разработка архитектура системы

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

В процессе проектирования информационных объектов системы были выделены следующие основные элементы:

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

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

· Документы. Документы в системе представляют собой текстовые описания знаний, отчетов, практик и др., используемых в рамках проекта. Также к документам есть возможность прикрепления файлов различных форматов. Для аудита релевантности данных, хранимых в документе, реализована возможность комментирования документов. Также для удобства создания документов реализована возможность создания шаблонов документов

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

· Frontend - интерфейс системы, задача которого состоит во взаимодействии с пользователем, отправке запросов на сервер и отображении ответа от сервера. При этом интерфейс системы, в свою очередь, состоит из множества страниц и функциональных компонентов, которые детально будут описаны далее в отчете.

· Backend - серверная часть приложения, состоящая из следующих составных частей:

o Internal API - программный интерфейс для взаимодействия с интерфейсом системы

o External API - программный интерфейс для взаимодействия со внешними информационными системами, необходимый для возможности интеграции коробочного решения в инфраструктуру компании

o Database - база данных системы, хранящая данные о пользователях системы, проектах и документы

o File storage - система хранения файлов, прикрепленных к документам в системе.

Ниже на рисунке 1 приведена схема взаимодействия данных компонентов.

Рисунок 1. Архитектура системы управления знаниями.

Как видно на приведенном выше рисунке, некоторые компоненты системы также делятся на внутренние компоненты, архитектура построения которых приведена далее в работе.

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

2.2 Разработка базы данных

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

В рамках текущей работы использовалась реляционная система управления базами данных (СУБД) PostgreSQL.

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

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

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

· users - содержит основную информацию пользователей (email, пароль и т.д.)

· user_roles, roles, role_permissions, permissions - таблицы для управления доступом к функционалу на уровне системы

· refresh_tokens - токены для обновления доступа к системе. Имеют ограниченный срок жизни

· invite_tokens - токены для приглашения на регистрацию в системе. Имеют ограниченный срок жизни

· user_competences, competences - таблицы для хранения компетенций сотрудников

· notifications_read, notifications - таблицы для хранения пользовательских оповещений

Рисунок 2. Таблицы пользовательской секции.

На рисунке 2 представлены таблицы пользовательской секции в нотации IDEF1X. Стоит обратить внимание на следующие особенности схемы, отражающие реализованные требования к системе:

1. Пользователь имеет как минимум одну роль для доступа к функционалу системы

2. Роли связаны как минимум с одним разрешением системы

3. Таблица notifications_read связана один-к-одному с таблицей пользователей.

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

· quick_links - быстрые ссылки на документы в пределах проекта, на другие проекты или на внешние ресурсы

· followed_projects - список проектов, за которыми следит пользователь. При любых изменениях на таких проектах пользователь будет получать соответствующее оповещение

· bookmarks - закладки на документы в системе

· last_seen_documents - история просмотра документов

· document_likes - хранит ссылки на понравившиеся пользователю документы

Рисунок 3. Таблицы рабочей секции.

На рисунке 3 представлены связи таблиц рабочей секции с таблицей пользователей.

Проектная секция включает в себя таблицы для хранения информации о проектах. Ниже приведено описание соответствующих таблиц и их размещение на схеме (рисунок 4):

· project_team - команда проекта с указанием должности в рамках проекта и прав доступа

· project_roles, project_role_permissions, project_permissions - управление доступом пользователей к отдельно взятым проектам

· projects - таблица с информацией по проектам (название, описание, цель, даты запуска и завершения и т.д.)

· activity - активность пользователей на проекте. В данную таблицу будет заноситься информация об изменениях, внесенных в документы проектной командой

Рисунок 4. Таблицы проектной секции.

Секция документов содержит таблицы для хранения документов и их шаблонов. Ниже приведено описание соответствующих таблиц и их размещение на схеме (рисунок 5):

· template_types - набор типов шаблонов используемых в системе. Некоторые шаблоны при этом могут быть системными, что означает, что их содержимое используется не для формирования документов, а для создания статических страниц или частей страниц в системе.

· templates - таблица для хранения шаблонов документов

· template_text - текст шаблона, вынесенный в отдельную таблицу для сохранения истории изменений

· documents - таблица для хранения проектных документов (формализованных интеллектуальных ресурсов)

· document_text - текст документов, вынесенный в отдельную таблицу для сохранения истории изменений

· comments, comment_likes - комментарии к документам системы

· attachments - ссылки на файлы, прикрепленные к документам



Рисунок 5. Таблицы секции документов.

После проектирования схемы базы данных в ПО Navicat Premium для всех полей были указаны типы данных, а для связей - инструкции, выполняемые при удалении и обновлении записей в таблицах.

Следующий этап разработки базы данных заключался в настройке полнотекстового поиска [13]. Полнотекстовой поиск предоставляет возможность выделить документы на естественном языке, которые удовлетворяют введенному поисковому запросу и, при необходимости, отсортировать их по релевантности относительно запроса. В рамках текущей работы использовалось два подхода по реализации полнотекстового поиска.

Первый подход был применен для шаблонов и документов и заключался в их предварительной обработке и сохранении результата в полях template_tsv и document_tsv соответственно. Предварительная обработка заключается в выделении лексем из текста и их сохранении в соответствующих полях с типом tsvector. Лексемы представляют собой базовые формы слов без префиксов и окончаний. При этом в процессе выделения лексем при помощи функции to_tsquery игнорируются предлоги, союзы и пунктуация. Также при обработке документов есть возможность сформировать набор лексем из нескольких исходных полей с указанием веса полей при помощи функции setweight. Таким образом, для реализации предварительной подготовки документов и шаблонов для поиска решено было использовать триггеры, срабатывающие при создании или изменении записей и автоматически обновляющие соответствующие поисковые поля. На рисунке 6 приведен пример триггера для обновления поля document_tsv в таблице documents.

Рисунок 6. Триггер для обновления поля document_tsv.

Также для оптимизации поисковых запросов необходимо использовать возможности СУБД по индексации текстовых полей. Для этих целей в PostgreSQL предусмотрены несколько типов индексов, среди них GIST и GIN. Для индексации поисковых полей было решено использовать индекс GIN, поскольку при его использовании скорость выполнения запросов на выборку выше, чем при использовании индекса GIST. Пример поискового запроса по документам приведена ниже на рисунке 7.

Рисунок 7. Поисковой запрос по документам.

Второй подход был использован для реализации поиска по остальным сущностям базы данных, таких как проекты, компетенции и др. Данный подход заключается в использовании так называемых триграмм, которые представляют собой набор трехсимвольных строк, созданных из исходного текста последовательным смещением на одну позицию. Использование триграмм предоставляет возможность полнотекстового поиска даже при наличии опечаток в тексте запроса. Для использования триграмм в СУБД PostgreSQL было установлено расширение pg_trgm [14], добавляющее новые функции и процедуры для данного типа полнотекстового поиска. Для поисковых полей в данном случае, как и в первом подходе, был использован индекс GIN. Также стоит отметить, что было решено не использовать триграммы при поиске по документам из-за специфики хранения документов в системе и невозможности оптимизации поиска сразу по нескольким текстовым полям с указанием веса полей.

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

2.3 Серверная часть системы

2.3.1 Настройка подключения к базе данных

За основу для реализации системы управления знаниями был взят фреймворк ASP.NET Core, являющийся кроссплатформенной версией фреймворка ASP.NET и предоставляющий богатый инструментарий для реализации API с использованием языка программирования C#. При изучении данного фреймворка использовались источники [15], [16] и [17].

Первый этап разработки серверной части СУЗ заключался в подготовке среды разработки. Для этого был установлен dotnet SDK, загруженный с официального сайта фреймворка. SDK предоставляет функционал по сборке проекта, написанного на фреймворке dotnet core, а также по управлению зависимостями и используемыми пакетами. Для создания проекта в консоли была выполнена команда “dotnet new webapi -o kms”. При этом была создана директория kms с подготовленными файлами для создания API.

Следующий шаг после создания проекта - настройка подключения к базе данных. Для взаимодействия с базой данных было решено использовать два инструмента, а именно Entity Framework Core [18] и Dapper [19]. Entity Framework Core предоставляет инструментарий для преобразования LINQ запросов в запросы на языке SQL. Данный фреймворк весьма полезен при реализации простых запросов, не требующих оптимизации или использования специальных команд СУБД. Однако в процессе разработки было выяснено, что в нем отсутствует возможность по реализации полнотекстового поиска. По этой причине было решено в качестве дополнительного инструмента использовать Dapper, который позволяет выполнять запросы на языке SQL к различным СУБД и затем трансформировать ответ сервера в наборы объектов моделей на языке C#. Также для подключения к СУБД PostgreSQL перечисленные инструменты используют пакет Npgsql [20], который необходимо дополнительно установить. Ниже на рисунке 7 приведены команды, выполненные для загрузки и установки необходимых пакетов:

Рисунок 7. Команды для установки пакетов для взаимодействия с СУБД.

Работа с базой данных при помощи Entity Framework Core может быть произведена двумя различными способами: code first и database first. При code first в качестве отправной точки для формирования схемы базы данных используются классы языка C#, а подход database first заключается в подключении к уже существующей базе данных со схемой, сформированной другими программными средствами. Каждый из подходов имеет свои преимущества и недостатки. В рамках текущей работы был выбран подход database first, поскольку code first, реализованный в Entity Framework Core не дает необходимых возможностей по настройке базы данных, а именно настройке полнотекстового поиска и индексации для использования триграмм.

После установки необходимых пакетов была произведена автоматическая генерация классов моделей, соответствующих таблицам базы данных. Для этого была выполнена следующая команда, представленная на рисунке 8.

Рисунок 8. Консольная команда для создания моделей.

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

Поскольку система хранит в базе данных некоторые внутренние настройки, такие как идентификаторы доступа к функционалу и типы шаблонов, необходимо обеспечить проверку целостности базы данных и генерацию необходимых записей при их отсутствии. При использовании подхода code first, Entity Framework Core предоставляет такой функционал, как миграции и сидирование базы данных, которые можно было бы использовать для целей этих. Однако поскольку в данной работе было решено придерживаться подхода database first, был реализован отдельный функционал по проверке целостности базы данных и наличия необходимых записей. Для этого в созданной директории «Data/Seed» был создан класс «DBSeeder», содержащий метод расширения для контекста базы данных, названный «EnsureSeeded». Данный метод производит проверку наличия необходимых записей в базе данных и их создание, при необходимости. Также в этой директории были созданы json файлы, содержащие записи по правам доступа в систему и системным шаблонам. На рисунке 9 приведен код метода «EnsureSeeded», а также дополнительного метода по созданию типов шаблонов.

Рисунок 9. Метод расширения EnsureSeeded.

Приведенный выше метод затем вызывается в методе «Configure» файла «Startup.cs», в котором производится настройка системы при запуске. Таким образом, при каждом запуске серверной части СУЗ, база данных будет проверяться на наличие необходимых для работы системы записей.

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

1. При помощи LINQ запросов, используя средства Entity Framework Core. Такие запросы реализованы напрямую в методах контроллеров, поскольку они довольно просты и не требуют выделения в отдельные классы

2. Посредством пакета Dapper напрямую SQL запросами. Таким способом осуществляются поисковые запросы. Недостаток такого подхода заключается в усложненном процессе масштабирования системы, поскольку изменения в схеме базы данных могут повлечь за собой необходимость корректировки SQL запросов. При этом велика вероятность возникновения ошибки в работе системы по причине недостаточной корректировки запроса. При первом варианте, в свою очередь, такого рода ошибки отлавливаются на стадии сборки проекта. Для удобства поддержки системы такие запросы были вынесены в отдельный класс «SearchRepository», который затем был инициализирован как сервис и использован в контроллерах системы для реализации функций поиска.

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

2.3.2 Аутентификация и авторизация пользователей в системе

Правильная настройка аутентификации и авторизации пользователей в системе крайне важна, поскольку уязвимости в системе предоставления доступа к интеллектуальным ресурсам компании, хранимым в СУЗ, могут привести к значительным потерям. Фреймворк ASP.NET Core содержит встроенный инструментарий для реализации аутентификации и авторизации пользователей, называемый ASP.NET Core Identity [21]. Данное расширение фреймворка ASP.NET Core предоставляет возможности по созданию учетных записей, аутентификации, управлению учетными записями и использованию для входа в си систему учетные записи внешних провайдеров, таких как Facebook, Google и других. Однако использование ASP.NET Core Identity в его полной редакции влечет за собой необходимость использования подхода code first для инициализации необходимых для расширения таблиц. Но поскольку в рамках текущей работы было решено придерживаться подхода database first, было также решено использовать иной способ аутентификации пользователей, а именно с использованием JSON Web Tokens (JWT) [22].

JWT представляет собой открытый стандарт RFC 7519, который определяет способ передачи данных о пользователе в формате JSON в зашифрованном виде. JWT-токен согласно стандарту состоит из трех частей, разделенных точкой:

· Header - объект в формате JSON, содержащий информацию о типе токена и алгоритме его шифрования

· Payload - объект в формате JSON, содержащий учетные данные пользователя и другую служебную информацию, определяющую уровень доступа пользователя

· Signature - строка, создающаяся путем шифрования Header, Payload и заранее заданного секретного ключа

Использование JWT дает ряд преимуществ, а именно:

· Использование JWT не требует хранения на сервере дополнительной информации о выданных токенах с их постоянной проверкой, что значительно снижает нагрузку на базу данных

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

· Создание токенов может производиться во внешнем источнике

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

Фреймворк ASP.NET Core предоставляет встроенные возможности по использованию JWT, которые были использованы в текущей работе. Настройка системы для использования JWT заключается в вызове соответствующих методов в файле «Startup.cs». На рисунке 10 приведен код конфигурации системы для использования JWT.

Рисунок 10. Конфигурирование системы для использования JWT.



Также в методе «Configure» файла «Startup.cs» необходимо выполнить команду «app.UseAuthentication()», которая добавляет в систему возможность контроля доступа к методам контроллеров.

...