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

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

Построение онтологии «Команда ИТ-проекта» в среде Protege

Введение

онтология protеgе семантический фрейм

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

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

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

1. Исследование способов представления знаний

Одним из компонентов экспертных систем (ЭС) является база знаний (БЗ), предназначенная для хранения долгосрочных данных, описывающих определенную предметную область, и правил, описывающих целесообразные преобразования данных этой области. [1] При создании базы знаний необходимо описать смысловое содержание предметной области. Следует иметь такую форму описания знаний, которая гарантирует их обработку формальными методами. [1]

Создание БЗ осуществляется в несколько этапов.

На первом этапе проводится определение предметной области, по которой разрабатывается база знаний. [1]

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

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

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

На следующем этапе полученные знания описываются на одном из языков представления знаний. [1]

Наиболее общими методами представления знаний являются:

· правила;

· семантические сети;

· фреймы;

· нечеткие высказывания.

1.1 Представление знаний в виде правил

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

В ЭС, основанных на правилах, предметные знания представляются набором правил, которые проверяются на группе фактов и знаний о текущей ситуации (входной информации). Когда часть правила ЕСЛИ удовлетворяет фактам, то действия, указанные в части ТО, выполняется. Когда это происходит, то говорят, что правило срабатывает. Интерпретатор правил сопоставляет части правил ЕСЛИ с фактами и выполняет то правило, часть ЕСЛИ которого сходится с фактами, т.е. интерпретатор правил работает в цикле "Сопоставить - выполнить", формируя последовательность действий (Рис. 1). [3]

Рис. 1. Представление знаний в виде правил

Действия правил могут состоять:

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

· во взаимодействии с внешней средой (например, "Вызвать пожарную команду"). [3]

Процесс сопоставления с фактами частей ЕСЛИ порождает цепочку выводов. Эта цепочка выводов показывает как система, используя правила, выводит заключение. Цепочки выводов ЭС могут быть предъявлены пользователю, что помогает понять как система достигает свои заключения. [3]

Правила, по сравнению с другими способами представления знания имеют следующие преимущества:

1) модульность;

2) единообразие структуры;

3) естественность (вывод заключения в такой системе аналогичен процессу рассуждения эксперта);

4) гибкость иерархии понятий, которая поддерживается только как связи между правилами (изменив правило, можно изменить иерархию).

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

1) процесс вывода менее эффективен, чем при других способах представления, так как большая часть времени затрачивается на непроизводительную проверку применимости правил;

2) этот процесс трудно поддается управлению;

3) сложно представить иерархию понятий. [3]

1.2 Представление знаний с использованием фреймов

Представление знаний, основанных на фреймах, является альтернативным по отношению к системам, основанным на правилах: оно дает возможность хранить иерархию понятий в базе знаний в явной форме. [3]

Фреймовая модель основана на концепции Марвина Мински (Marvin Minsky) - профессора Массачусетского технологического института, основателя лаборатории искусственного интеллекта, автора ряда фундаментальных работ. Фреймовая модель представляет собой систематизированную психологическую модель памяти человека и его сознания. [10]

Фрейм (англ. frame - рамка, каркас) - структура данных для представления некоторого концептуального объекта. Информация, относящаяся к фрейму, содержится в составляющих его слотах. [10]

Слот (англ. slot - щель, прорезь) может быть терминальным (листом иерархии) или представлять собой фрейм нижнего уровня. [10]

Каждый фрейм состоит из произвольного числа слотов, причем несколько из них обычно определяются самой системой для выполнения специфических функций, а остальные определяются пользователем (Рис. 2). [10]

Рис. 2. Представление фрейма

Имя фрейма - это идентификатор, присваиваемый фрейму. Фрейм должен иметь имя, единственное в данной фреймовой модели (уникальное имя). [10]

Имя слота - это идентификатор, присваиваемый слоту. Слот должен иметь уникальное имя во фрейме, к которому он принадлежит. Обычно имя слота не несет никакой смысловой нагрузки и является лишь идентификатором данного слота, но в некоторых случаях оно может иметь специфический смысл. [10]

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

Указатель атрибутов - указатель типа данных слота. К таким типам относятся: FRAME (указатель), INTEGER (целое), REAL (вещественное), BOOL (булево), LISP (присоединенная процедура), TEXT (текст), LIST (список), TABLE (таблица), EXPRESSION (выражение) и другие. [10]

Значение слота - значение, соответствующее типу данных слота и удовлетворяющее условиям наследования. [10]

Демон - процедура, автоматически запускаемая при выполнении некоторого условия. Демоны запускаются при обращении к конкретному слоту фреймовой модели. Например, демон IF-NEEDED запускается, если в момент обращения к слоту его значение не было установлено,IF-ADDED запускается при подстановке в слот значения, IF-REMOVED запускается при стирании значения слота. [10]

Пример фреймовой модели иерархического типа представлен на Рис. 3.

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



Рис. 3. Пример фреймовой модели представления знаний.

Формально фрейм - это тип данных вида:

F = < N, S₁, S₂, S₃ >,

где

N - имя объекта;

S₁ - множество слотов, содержащих факты, определяющие декларативную семантику фрейма;

S₂ - множество слотов, обеспечивающих связи с другими фреймами (каузальные, семантические и т. д.);

S₃ - множество слотов, обеспечивающих преобразования, определяющие процедурную семантику фрейма. [10]

Фреймы подразделяются на:

· фрейм-экземпляр - конкретная реализация фрейма, описывающая текущее состояние в предметной области;

· фрейм-образец - шаблон для описания объектов или допустимых ситуаций предметной области;

· фрейм-класс - фрейм верхнего уровня для представления совокупности фреймов образцов. [10]

Состав фреймов и слотов в каждой конкретной фреймовой модели может быть разный, однако в рамках одной системы целесообразно единое представление для устранения лишнего усложнения. [10]

В целом фреймовая модель допускает представление всех свойств декларативных и процедурных знаний. Глубина вложенности слотов во фрейме (число уровней) зависит от предметной области и языка, реализующего модель. [10]

1.3 Представление знаний с использованием семантических сетей

Термин "семантическая сеть" используется для описания метода представления знаний, основанного на сетевой структуре. Этот метод является одним из наиболее эффективных методов хранения знаний. [3]

В инженерии знаний под семантической сетью подразумевается граф, отображающий смысл целостного образа. Узлы графа соответствуют понятиям и объектам, а дуги - отношениям между объектами. [9] Формально сеть можно задать в следующем виде:

H = <I, C, G >,

где

I - множество информационных единиц;

C - множество типов связей между информационными единицами;

G - отображение, задающее конкретные отношения из имеющихся типов C между элементами I. [9]

Семантическая сеть как модель наиболее часто используется для представления декларативных знаний. С помощью этой модели реализуются такие свойства системы знаний, как интерпретируемость и связность, в том числе по отношениям IS-A и PART-OF. За счет этих свойств семантическая сеть позволяет снизить объем хранимых данных, обеспечивает вывод умозаключений по ассоциативным связям. [9]

Как правило, различают экстенсиональные и интенсиональные семантические сети. Экстенсиональная семантическая сеть описывает конкретные отношения данной ситуации. Интенсиональная - имена классов объектов, а не индивидуальные имена объектов. Связи в интенсиональной сети отражают те отношения, которые всегда присущи объектам данного класса. [9]

Примером семантической сети может служить фрагмент описания вычислительной техники, показанный на Рис. 4.

Рис. 4. Фрагмент семантический сети описания вычислительной техники.

С помощью такой сети, используя отношение IS-A и PART-OF, можно вывести факты: «Багет-11» - это ЭВМ; IBM PC имеет процессор и т.д. Для отображения процедурных знаний используются процедурные семантические сети. В этом случае факты, отношения и процедуры представлены как вершины, а связи объединяют их в единое понятие. [9]

1.4 Представление знаний в виде нечетких высказываний

Методы построения математических моделей часто основаны хотя и на неточной, но в целом объективной информации об объекте. Однако возможны ситуации, когда при построении моделей решающее значение имеют сведения, полученные от эксперта, обычно качественного характера. Они отражают содержательные особенности изучаемого объекта и формулируются на естественном языке. Описание объекта в таком случае носит нечеткий характер. При использовании для отображения знаний теории нечетких множеств булева алгебра распространена на действительные числа. В булевой алгебре 1 представляет истину, а 0 - ложь. То же имеет место и в нечеткой логике, но кроме того используются также все дроби между 0 и 1, чтобы указать на частичную истинность. Так запись "µ(высокий(Х)) = 0,75" говорит о том, что предположение "Х - высокий" в некотором смысле на три четверти истинно, а на одну четверть ложно. Для комбинирования нецелочисленных значений истинности в нечеткой логике определяются эквиваленты логических операций: [3]

Таким образом, обрывочные сведения можно комбинировать на основе строгих и согласованных методов. Слабым моментом в применении нечеткой логики является отображение (функция принадлежности). Предположим, возраст Х - 40 лет. Насколько истинно предположение, что Х - старый. Равна ли эта величина 0,5, поскольку Х прожил примерно полжизни, или величины 0,4 и 0,6 более реалистичны. Кто-то должен решить, какую функцию лучше использовать для отображения возраста в интервал от 0 до 1. Чем, например, кривая, изображенная на Рис. 5 лучше, чем линейная зависимость. Для предпочтения одной формы функции другой нет объективных обоснований, поэтому в реальной задаче будут присутствовать десятки и сотни подобных функций, каждая из которых до некоторой степени является произвольной. Значит в системах, основанных на нечеткой логике, необходимо предусмотреть средства, позволяющие модифицировать функции принадлежности. [3]

Рис. 5. Кривая отображения возраста в интервале от 0 до 1.

2. Методология и инструментальные средства построения онтологий

2.1 Представление знаний в виде онтологий

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

Термин "онтология" впервые появился в работе Томаса Грубера, в которой рассматривались различные аспекты взаимодействия интеллектуальных систем между собой и с человеком. [4]

Онтология по Груберу представляет собой описание декларативных знаний, сделанное в виде классов с отношением иерархии между ними. [4]

Онтология состоит из примитивов представления знаний предметной области (определений основных понятий, таких как имена индивидуумов, классы, функции и другие сущности), а также различного рода семантических связей, поддерживаемых между ними. [7]

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

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

Под формальной моделью онтологии О часто понимают упорядоченную тройку вида О = <С, R, F>, где C - конечное множество концептов (понятий) предметной области, которую определяет онтология О; R - конечное множество отношений между концептами (понятиями) предметной области, F - конечное множество функций интерпретации (аксиоматизация), заданных на концептах и/или отношениях онтологии О. Естественными ограничениями, накладываемыми на множество С являются конечность и не пустота. Что касается множеств R и F, то они могут быть пустыми, что соответствует частным видам онтологии, когда она вырождается в простой словарь, таксономию понятий и т.д. [2]

В настоящее время средства формального описания онтологии включают несколько альтернатив:

· представление онтологии предметной области в виде набора элементов метаданных «Дублинского ядра» (Dublin Core, DC);

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

· представление онтологии предметной области с использованием стандарта языка описания онтологии - OWL (Ontology Web Language) для информационных ресурсов Web второго поколения на платформе XML. [7]

Дублинское ядро (Dublin Core, DC) - это набор элементов метаданных для представления онтологии предметной области. В терминах значений этих элементов можно описывать содержание различного рода текстовых документов и документов, представленных в иных средах. Привлекательность такого подхода связана с его простотой, что, оборачивается ограниченностью его возможностей. [7]

Формальное описание онтологии предметной области на языках логики первого порядка допускает возможности логического вывода. Довольно широкое распространение для представления онтологии получил язык указанной категории KIF (Knowledge Interchange Format), разработанный в начале 90-х гг. в Лаборатории систем знаний (KSL) Стэнфордского университета. Первоначально он разрабатывался как формальный язык для обеспечения обмена знаниями между различными системами, основанными на знаниях. [7]

На основе расширения языка KJF в той же лаборатории была создана исследовательская система Ontolingua, поддерживающая формирование и представление онтологии в некотором каноническом формате, благодаря чему обеспечивается их совместное использование и/или переносимость в среды различных оперирующих с ними систем. Онтологию, заданную в каноническом формате, можно легко транслировать в разнообразные системы, использующие различный синтаксис для представления знаний и обладающие различными возможностями рассуждений. [7]

Стандарт языка описания онтологии для информационных ресурсов Web - OWL (Ontology Web Language) разрабатывается рабочей группой по онтологиям для Web консорциума W3C с 2001г. Язык OWL основан на логиках описаний и предназначен для интеллектуальных систем поиска информационных ресурсов в среде Web второго поколения. [7]

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

Еще одним способом описания онтологии предметной области, широко используемым в исследовательских и коммерческих системах текстового поиска, является представление ее в форме тезауруса предметной области. [7]

2.2 Методология построения онтологий

Цель создания онтологий - обеспечить поддержку деятельности по накоплению, разделению и повторному использованию знаний. Исходя из этой цели, введен ряд критериев, которым должна отвечать онтология. [2]

Прозрачность - онтология должна эффективно передавать подразумеваемое значение определенного термина. [2]

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

Расширяемость - онтология должна быть разработана с возможностью использования разделяемого и пополняемого словаря.

Независимость от синтаксиса - концептуализация должна быть специфицирована на уровне знания максимально независимо от представления понятий на уровне символов. [2]

Минимальный базис при высокой выразительности - онтология должна вводить минимальный базовый набор понятий, но их должно быть достаточно, чтобы моделировать мир в требуемых целях и создавать сложные сцены. [2]

2.3 Инструменты для построения онтологий

Инженерию онтологий можно определить как совокупность действий, касающихся:

· процесса разработки онтологий;

· жизненного цикла онтологий;

· методов и методологий построения онтологий;

· набора инструментов и языков для их построения и поддержки. [6]

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

Ниже приведены наиболее известные инструменты инженерии онтологий. [6]

Система Ontolingua была разработана в KSL (Knowledge Systems Laboratory) Стенфордского университета и стала первым инструментом инженерии онтологий. Она состоит из сервера и языка представления знаний. [6]

Сервер Ontolingua организован в виде набора онтологий, относящихся к Web-приложениям, которые надстраиваются над системой представления знаний Ontolingua. Редактор онтологий - наиболее важное приложение сервера Ontolingua, является Web-приложением на основе форм HTML. Кроме редактора онтологий Сервер Ontolingua включает сетевое приложение Webster (получение определений концептов), сервер OKBC (доступ к онтологиям Ontolingua по протоколу OKBC) и Chimaera (анализ, объединение, интегрирование онтологий). Все приложения, кроме сервера OKBC, реализованы на основе форм HTML. Система представления знаний реализована на Lisp. [6]

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

Protеgе - локальная, свободно распространяемая Java-программа, разработанная группой медицинской информатики Стенфордского университета. Программа предназначена для построения (создания, редактирования и просмотра) онтологий прикладной области. Её первоначальная цель - помочь разработчикам программного обеспечения в создании и поддержке явных моделей предметной области и включение этих моделей непосредственно в программный код. Protеgе включает редактор онтологий, позволяющий проектировать онтологии разворачивая иерархическую структуру абстрактных или конкретных классов и слотов. Структура онтологии сделана аналогично иерархической структуре каталога. На основе сформированной онтологии, Protеgе может генерировать формы получения знаний для введения экземпляров классов и подклассов. Инструмент имеет графический интерфейс, удобный для использования неопытными пользователями, снабжен справками и примерами. [6]

Protеgе основан на фреймовой модели представления знания OKBC (Open Knowledge Base Connectivity) и снабжен рядом плагинов, что позволяет его адаптировать для редактирования моделей хранимых в разных форматах (стандартный текстовый, в базе данных JDBC, UML, языков XML, XOL, SHOE, RDF и RDFS, DAML+OIL, OWL). [6]

OntoEdit первоначально был разработан в институте AIFB (Institute of Applied Informatics and Formal Description Methods) Университета Karlsruhe (сейчас коммерциализован Ontoprise GmbH) выполняет проверку, просмотр, кодирование и модификацию онтологий. В настоящее время OntoEdit поддерживает языки представления: FLogic, включая машину вывода, OIL, расширение RDFS и внутреннюю, основанную на XML, сериализацию модели онтологии используя OXML - язык представления знаний OntoEdit (OntoEdit's XML-based Ontology representation Language). К достоинствам инструмента можно отнести удобство использования; разработку онтологии под руководством методологии и с помощью процесса логического вывода; разработку аксиом; расширяемую структуру посредством плагинов, а также очень хорошую документацию. [6]

Так же как и Protеgе, OntoEdit - автономное Java-приложение, которое можно локально установить на компьютере, но его коды закрыты. [6]

Существует две версии OntoEdit: свободно распространяемая OntoEdit Free (ограничена 50 концептами, 50 отношениями и 50 экземплярами) и лицензированная OntoEdit Professional (нет ограничений на размер). Естественно, что OntoEdit Professional имеет более широкий набор функций и возможностей (например, машину вывода, графический инструмент запросов, больше модулей экспорта и импорта, графический редактор правил, поддержка баз данных JDBC и т.д.). [6]

OilEd - автономный графический редактор онтологий, разработан в Манчестерском университете в рамках европейского IST проекта On-To-Knowledge. Инструмент основан на языке OIL (сейчас адаптирован для DAML+OIL, в перспективе - OWL), который сочетает в себе фреймовую структуру и выразительность дескриптивной логики (Description Logics) с сервисами рассуждения. Что позволило обеспечить понятный и интуитивный стиль интерфейса пользователя и преимущества поддержки рассуждения (обнаружение логически противоречивых классов и скрытых отношений подкласса). [6]

Из недостатков можно выделить отсутствие поддержки экземпляров. Существующая версия не обеспечивает полную среду разработки - не поддерживается разработка онтологий большого масштаба, миграция и интеграция онтологий, контроль версий и т.д. OilEd можно рассматривать как “NotePad” редакторов онтологий, предлагающий достаточную функциональность, чтобы позволить пользователям строить онтологии и продемонстрировать, как можно использовать механизм рассуждения FaCT для проверки онтологии на непротиворечивость. [6]

WebOnto разработан для Tadzebao - инструмента исследования онтологий и предназначен для поддержки совместного просмотра, создания и редактирования онтологий. Его цель - предоставление средств масштабирования для построения больших онтологий. [6]

Для моделирования онтологий WebOnto использует язык OCML (Operational Conceptual Modeling Language). В WebOnto пользователь может создавать структуры, включая классы с множественным наследованием, что можно выполнять графически. Все слоты наследуются корректно. Инструмент проверяет вновь вводимые данные контролем целостности кода OCML. [6]

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

3. Исследование предметной области «Команда ИТ проекта»

Роль в проекте (проектная роль) - определенный набор функций и полномочий в проекте, созданный с целью распределения обязанностей между членами команды проекта. Проектную роль можно рассматривать как временную должность в организации (компании). [5]

Команда проекта - временная рабочая группа, выполняющая работы по проекту и ответственная перед Руководителем проекта за их выполнение. Команда проекта состоит из команды управления проектом, участников проекта, выполняющих работы в рамках проекта, - Исполнителей проекта. [5]

Команда управления проектом (КУП) - члены команды проекта, уполномоченные принимать управленческие решения по управлению проектом. [5]

Участники проекта - организации Заказчика и Исполнителя и специалисты от организаций Заказчика и Исполнителя, а также другие организации и лица, которые участвуют в работе проекта или чьи интересы могут быть затронуты при исполнении или завершении проекта. Участники оказывают влияние на проект и его результаты. [5]

Команда управления проектом

Формируя команду управления проектом, необходимо определить ключевых лиц проекта, принимающих решения. [5]

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

· Руководитель проекта;

· Куратор проекта (Спонсор);

· Архитектор системы;

· Администратор проекта. [5]



Рис. 6. Подчиненности членов команды управления проектом внедрения ИС

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

Состав команды управления должен быть достаточным, чтобы осуществлять:

· Управление ресурсами проекта, в том числе:

o определение требуемых для достижения целей проекта ресурсов

o подготовка предложений по изменению состава группы управления проектом;

o утверждение персональных изменений в составе рабочих групп проекта;

o оценка стоимости проекта, подготовка бюджетов проекта и отчетов об исполнении бюджетов.

· Управление сроками выполнения проекта, в том числе:

o подготовка плана работ проекта;

o контроль над выполнением проекта;

o подготовка отчетов о ходе работ проекта.

· Управление качеством проекта, в том числе:

o контроль соответствия разрабатываемых проектных решений Техническому заданию;

o организация экспертизы проектных решений.

· Управление рисками проекта, в том числе:

o анализ рисков проекта;

o разработка планов мероприятий по снижению рисков;

o реализация мероприятий по снижению рисков.

· Управление проблемами проекта, в том числе:

o анализ проблем проекта;

o разработка мероприятий по разрешению проблем проекта;

o реализация мероприятий по разрешению проблем проекта.

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

o согласование отчетов о ходе работ;

o контроль над функционированием системы сбора и распределения информации;

o контроль документирования проектных результатов. [5]

Персональный состав команды управления проектом определяется Уставом проекта. [5]

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

· какие цели стоят перед сотрудником, назначенным на данную роль;

· кому подчиняется сотрудник, назначенный на ту или иную роль;

· каковы его функции, обязанности, полномочия. [5]

Функции и полномочия проектных ролей команды управления проектом

Куратор проекта (Спонсор) - проектная роль должностного лица, отвечающего за стратегическое управление ходом реализации проекта. Куратор принимает решение по стратегическим вопросам проекта, осуществляет утверждение основных изменений в объеме работ, сроках, этапах, в бюджете проекта, находящихся вне компетенции Руководителя проекта. Как правило, Куратором проекта (Спонсором) является менеджер высшего звена организации. [5]

Основные функции:

· общее руководство ходом реализации проекта;

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

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

· получение и анализ сводной отчетности о ходе реализации проекта;

· управление изменениями базовых параметров проекта и решение проблем, находящихся вне компетенции Руководителя проекта. [5]

Основные полномочия:

· утверждение целей проекта;

· согласование назначения Руководителя проекта;

· утверждение общего плана и бюджета проекта;

· получение от Руководителя проекта сводной отчетности о ходе его выполнения;

· принятие принципиальных решений при возникновении критических изменений, влияющих на сроки, стоимость и качество результатов проекта. [5]

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

Основные функции:

· формирование команды проекта и команды управления проектом;

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

· распределение ресурсов проекта и организация взаимодействия команды проекта в процессе его выполнения;

· организация взаимодействия с Заказчиком и обеспечение всех необходимых коммуникационных связей с другими участниками проекта;

· учет фактических затрат ресурсов по исполнению проекта;

· формирование и предоставление Куратору отчетности по проекту. [5]

Основные полномочия:

· назначение задач команде проекта (отдельным ее членам) и контроль их выполнения;

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

· подтверждение или отклонение отчетов о фактических затратах исполнителей проекта;

· обоснование необходимости и запрос Куратору проекта на выделение дополнительных ресурсов на проект;

· обращение к Куратору за поддержкой в случае необходимости. [5]

Архитектор системы - проектная роль должностного лица, отвечающего за предметную область проекта. Архитектор системы подчиняется непосредственно Руководителю проекта. [5]

Архитектор системы непосредственно отвечает за разработку информационной системы в соответствии с плановыми сроками проекта и с заданным уровнем качества. [5]

На роль Архитектора системы назначается специалист, наиболее компетентный по внедряемой информационной системе. Архитектор системы должен знать методологии и технологии построения ИС, стандарты и нормативные документы в области проектирования и создания ИС, разработки и оформления технической документации. [5]

Основные функции:

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

· определение ресурсов, которые необходимы для разработки и внедрения ИС в рамках, заданных условиями проекта;

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

· обеспечение целостности функциональной архитектуры внедряемой информационной системы;

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

· планирование и согласование фактических трудозатрат специалистов при исполнении проекта;

· формирование и предоставление руководителю проекта необходимой отчетности;

· анализ хода выполнения и промежуточных результатов создания ИС;

· организация, проведение и документирование процедур передачи Заказчику разработанной ИС. [5]

Основные полномочия:

· участие в календарном планировании работ по созданию ИС;

· назначение задач рабочим группам проекта и контроль их выполнения;

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

· обоснование необходимости и запрос руководителю проекта на выделение дополнительных ресурсов на проект. [5]

Администратор проекта - проектная роль должностного лица, отвечающего за информационное обеспечение руководителя проекта, организацию и ведение документооборота по проекту. Администратор проекта функционально закрепляется за конкретным проектом и подчиняется непосредственно Руководителю проекта. [5]

Основные функции:

· обеспечение Руководителя проекта структурированной информацией, обеспечивающей возможность контроля за проектом, планами, ресурсами и приоритетами;

· ведение протоколов совещаний;

· обеспечение своевременной подготовки, движения и архивации документов по проекту. [5]

Основные полномочия:

· передача и получение от участников проекта необходимой документации по проекту;

· контроль соблюдения участниками проекта установленной системы документооборота;

· затребование от конкретных исполнителей по проекту оперативной информации и отчетов о ходе работ по проекту. [5]

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

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

Основные функции:

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

· определение ресурсов, которые необходимы для разработки и внедрения ИС в рамках, заданных условиями проекта;

· обеспечение целостности функциональной архитектуры внедряемой информационной системы;

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

Основные полномочия:

· назначение задач рабочим группам проекта и контроль их выполнения;

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

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

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

Основные функции:

· разработка проектной документации;

· формирование ТЗ для разработчика;

· конфигурирование системы.

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

Основные функции:

· реализация технических заданий.

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

Основные функции:

· администрирование внедряемой системы.

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

Основные функции:

· тестирование внедряемой системы.

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

Основные функции:

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

· разработка программ и сценариев тестирования.

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

Основные функции:

· выявление и сбор требований к информационной системе из различных источников;

· систематизация требований;

· анализ требований для контроля их качества;

· документирование требований в документах или специализированных системах;

· согласование требований с заинтересованными лицами;

· обработка запросов на изменение требований к системе;

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

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

· изучение и систематизация документации по проекту в части выделения процессов, подлежащих автоматизации.

На проекте один член команды может выступать одновременно в нескольких ролях. Совмещение ролей часто встречается на небольших проектах, что позволяет снизить накладные расходы проекта. Но не все роли можно совмещать, поскольку подобное совмещение может затруднить контроль и оценку результатов проекта. Допускается совмещение таких проектных ролей, как Руководитель проекта и администратор проекта, функциональный архитектор и функциональный консультант, функциональный консультант и аналитик, менеджер разработки и разработчик, менеджер по качеству и тестировщик. Но не следует совмещать роли менеджера по качеству и разработчика, руководителя проекта и разработчика, тестировщика и разработчика. [5]

4. Построение онтологии предметной области «Команда ИТ-проекта» в PROTЕGЕ 4.2

Для реализации онтологии было выбрано средство PROTЕGЕ, версия 4.2.

Онтология состоит из отдельных индивидов, свойств и классов.

Индивиды (Individuals) представляют собой конкретные объекты интересующей предметной области. [8]

Свойства (Properties) - это бинарные отношения на индивидах или классах. Другими словами, свойства соединяют двух индивидов или два класса. [8]

Классы (Classes) интерпретируются как множества, элементами которых являются индивиды. Они описываются, используя формальные (математические) конструкции, которые декларируют требования для членства в классе. [8] Классы могут быть организованы в иерархию отношений вида «подкласс-суперкласс», которая также известна как таксономия. Подклассы специализируют (т.е. являются подмножествами) своего суперкласса. Слово понятие (или сущность) иногда используется вместо слова класс. Классы - конкретное представление понятий. [8]

Виды свойств.

Обратные свойства (inverse) - каждое свойство может иметь соответствующее обратное свойство. Если некоторое свойство связывает индивид a с некоторым индивидом b, то его обратное свойство связывает индивид b с индивидом a.

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

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

Транзитивные свойства (transitive) если свойство транзитивное и свойство связывает индивида a и индивида b, а также индивида b связывает с индивидом c, то мы можем вывести, что этот индивид а связан с индивидом c через это свойство.

Симметричные свойства (Simmetric) если свойство p симметричное, и свойство связывает индивида а с индивидом b, то индивид b связан также с индивидом а через свойство р.

Асимметричные свойства (Asimmetric) если свойство p асимметричное, и свойство связывает индивида а с индивидом b, то индивид b не может быть связан с индивидом a через свойство p.

Рефлексивные свойства (Reflexive) Свойство Р называется рефлексивным, когда индивид а должен быть связан с собой.

Иррефлексивные свойства (irreflexive) Если свойство p иррефлексивное, то оно может быть охарактеризовано как свойство, которое связывает индивида а с индивидом b, где индивид а и индивид b обязательно разные.

Домены и диапазоны свойств. Свойства могут иметь домен и указанный диапазон. Свойства связывают индивидов из доменов с индивидами в диапазонах.

Описание реализации приведено далее по тексту.

Реализованная онтология включает элементы, описанные ниже.

1. Иерархию классов (Рис. 7):

· Project_team - Проектная команда;

o Project_management - Команда управления проектом;

o Developers - Команда разработчиков;

· Role_of_project - Роль в проекте;

o M_Project_Manager - Руководитель проекта

o M_Curator - Куратор проекта

o M_System_Architect - Архитектор системы

o M_Project_Administrator - Администратор системы

o D_Functional_Architect - Функциональный архитектор

o D_Functional_Сonsultant - Функциональный консультант

o D_Developer - Разработкчик

o D_Tester - Тестировщик

o D_Quality_Manager - Менеджер по качеству

o D_Systems_Analyst - Системный аналитик

Рис. 7. Иерархия классов

2. Свойства (Рис. 8):

· Part_of - Входит в состав (является частью);

· Consist_of - Состоит из;

· Responsible_to - В подчинении (подчиняется);

· To_manage - Руководит (является руководителем).



Рис. 8. Свойства онтологии

Более подробное описание свойств онтологии «Команда ИТ-проекта» приведено ниже.

Свойство Part_of - «Является частью»(Рис. 9) является транзитивным Для данного свойства обратным свойством является свойство Consist_of.

Рис. 9. Характеристики свойства Part_of.

Свойство Consist_of - «Состоит из» (Рис. 10) является транзитивным свойством. Для данного свойства обратным свойством является свойство Part_of.



Рис. 10. Характеристики свойства Consist_of.

Свойство Responsible_to - «В подчинении» (Рис. 11) является транзитивным свойством. Для данного свойства обратным свойством является свойство To_manage.

Рис. 11. Характеристики свойства Responsible_to.

Свойство To_manage - «Является руководителем» (Рис. 12) является транзитивным свойством. Для данного свойства обратным свойством является свойство Responsible_to.



Рис. 12. Характеристики свойства To_manage.

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

Описание связей:

1. Команда разработчиков состоит из Функционального архитектора, Функционального консультанта, Тестировщика, Системного аналитика, Разработчика, Менеджера по качеству. С точки зрения классов и связей в разрабатываемой онтологии (Рис. 13):

Developers Consist_of some D_Functional_Architect;

Developers Consist_of some D_Functional_Сonsultant;

Developers Consist_of some D_Systems_Analyst;

Developers Consist_of some D_Developer;

Developers Consist_of some D_Quality_Manager.

Рис. 13. Связи класса Developers с остальными классами.

Команда разработчиков в подчинении у руководителя проекта. С точки зрения классов и связей в разрабатываемой онтологии (Рис. 13):

Developers Responsible_to only M_Project_Manager.

2. Команда управления проектом состоит из Архитектора системы, Администратора проекта, Руководителя проекта, Куратора. С точки зрения классов и связей в разрабатываемой онтологии (Рис. 14):

Project_management Consist_of some M_System_Architect;

Project_management Consist_of some M_Project_Administrator;

Project_management Consist_of some M_Project_Manager;

Project_management Consist_of some M_Curator.

Рис. 14. Связи класса Project_management с остальными классами.

3. Разработчик является частью команды разработчиков. Данная связь является обратной связи из пункта 1. С точки зрения классов и связей в разрабатываемой онтологии (Рис. 15):

D_Developer Part_of some Developers.

Рис. 15. Связи класса D_Developer с остальными классами.

4. Функциональный архитектор является частью команды разработчиков. Данная связь является обратной связи из пункта 1. С точки зрения классов и связей в разрабатываемой онтологии (Рис. 16):

D_Functional_Architect Part_of some Developers.

Рис. 16. Связи класса D_Functional_Architect с остальными классами.

5. Функциональный консультант является частью команды разработчиков. Данная связь является обратной связи из пункта 1. С точки зрения классов и связей в разрабатываемой онтологии (Рис. 17):

D_Functional_Сonsultant Part_of some Developers.

Рис. 17. Связи класса D_Functional_ Сonsultant с остальными классами.

6. Менеджер по качеству является частью команды разработчиков. Данная связь является обратной связи из пункта 1. С точки зрения классов и связей в разрабатываемой онтологии (Рис. 18):

D_Quality_Manager Part_of some Developers.

Рис. 18. Связи класса D_Quality_Manager с остальными классами.

7. Системный аналитик является частью команды разработчиков. Данная связь является обратной связи из пункта 1. С точки зрения классов и связей в разрабатываемой онтологии (Рис. 19):

D_Systems_Analyst Part_of some Developers.

Рис. 19. Связи класса D_Systems_Analyst с остальными классами.

8. Тестировщик является частью команды разработчиков. Данная связь является обратной связи из пункта 1. С точки зрения классов и связей в разрабатываемой онтологии (Рис. 20):

D_Tester Part_of some Developers.

Рис. 20. Связи класса D_Tester с остальными классами.

9. Куратор является частью команды управления проектом. Данная связь является обратной связи из пункта 3. С точки зрения классов и связей в разрабатываемой онтологии (Рис. 21):

M_Curator Part_of some Project_management.

Рис. 21. Связи класса M_Curator с остальными классами.

10. Куратор является руководителем Руководителя проекта. С точки зрения классов и связей в разрабатываемой онтологии (Рис. 21):

M_Curator To_manage some M_project_manager.

11. Администратор проекта является частью команды управления проектом. Данная связь является обратной связи из пункта 3. С точки зрения классов и связей в разрабатываемой онтологии (Рис. 22):

M_Project_Administrator Part_of some Project_management.

Рис. 22. Связи класса M_Project_Administrator с остальными классами.

12. Администратор проекта находится в подчинении у Руководителя проекта. С точки зрения классов и связей в разрабатываемой онтологии (Рис. 22):

M_Project_Administrator Responsible_to some M_project_manager.

13. Руководитель проекта находится в подчинении у Куратора проекта. Данная связь является обратной связи из пункта 11. С точки зрения классов и связей в разрабатываемой онтологии (Рис. 23):

M_Project_Manager Responsible_to some M_Curator.

Рис. 23. Связи класса M_Project_Manager с остальными классами.

Руководитель проекта является частью команды управления проектом. Данная связь является обратной связи из пункта 3. С точки зрения классов и связей в разрабатываемой онтологии (Рис. 23):

M_Project_Manager Part_of some Project_management.

14. Руководитель проекта является руководителем для Архитектора системы, Администратора проекта, Группы разработчиков.С точки зрения классов и связей в разрабатываемой онтологии (Рис. 23):

M_Project_Manager To_manage some M_System_Architect;

M_Project_Manager To_manage some M_Project_Administrator;

M_Project_Manager To_manage some Developers.

15. Архитектор системы является частью Команды управления проектом. Данная связь является обратной связи из пункта 3. С точки зрения классов и связей в разрабатываемой онтологии (Рис. 24):

M_System_Architect Part_of some Project_management.

Рис. 24. Связи класса M_System_Architect с остальными классами.

16. Архитектор системы находится в подчинении у Руководителя проекта. Данная связь является обратной связи из пункта 16. С точки зрения классов и связей в разрабатываемой онтологии (Рис. 24):

M_System_Architect Responsible_to some M_Project_Manager.

Редактор PROTЕGЕ дает возможность представить созданную онтологию в формате семантической сети. Для того что бы представить созданную онтологию в виде семантической сети следует использовать PROTЕGЕ-плагины, которые представляют возможность визуализации онтологии. В рамках данного курсового проекта используется плагин OntoGraf для представления разработанной онтологии в виде семантической сети (Рис. 25).