· выявление и сбор требований к информационной системе из различных источников;
· систематизация требований;
· анализ требований для контроля их качества;
· документирование требований в документах или специализированных системах;
· согласование требований с заинтересованными лицами;
· обработка запросов на изменение требований к системе;
· изучение той или иной области на предмет внедрения и разработки прикладных информационных систем;
· участие в интервьюировании бизнес-экспертов и пользователей информационных систем на предмет изучения текущих принципов организации бизнес-процессов;
· изучение и систематизация документации по проекту в части выделения процессов, подлежащих автоматизации.
На проекте один член команды может выступать одновременно в нескольких ролях. Совмещение ролей часто встречается на небольших проектах, что позволяет снизить накладные расходы проекта. Но не все роли можно совмещать, поскольку подобное совмещение может затруднить контроль и оценку результатов проекта. Допускается совмещение таких проектных ролей, как Руководитель проекта и администратор проекта, функциональный архитектор и функциональный консультант, функциональный консультант и аналитик, менеджер разработки и разработчик, менеджер по качеству и тестировщик. Но не следует совмещать роли менеджера по качеству и разработчика, руководителя проекта и разработчика, тестировщика и разработчика. [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).
Рис. 25. Семантическая сеть онтологии «Команда ИТ-проекта»
Заключение
В ходе выполнения курсового проекта были решены следующие задачи:
1) исследованы способы представления знаний и методики проектирования онтологий предметной области;
2) осуществлен анализ программных средств разработки онтологии;
3) выполнен анализ информации о составе команды ИТ-проекта и формализован для возможности его представления в виде онтологии
4) рассмотрены основные инструменты и возможности программной среды PROTЕGЕ 4.2;
5) выполнено построение онтологии для предметной области «Команда ИТ-проекта».
Список литературы
1. Базы знаний экспертных систем. Методы представления знаний: логические модели, продукционные правила, фреймы, семантические сети [Электронный ресурс] // Режим доступа: http://daxnow.narod.ru/index/0-18, свободный.
2. Батищев, С.В. Методы и средства построения онтологий для интеллектуализации сети Интернет [Текст] / С.В. Батищев, Т.В. Искварина, П.О. Скобелев // Известия Самарского научного центра Российской академии наук. - 2002. С. 91-103.
3. Коробова, И. Л. Методы представления знаний [Текст]: Метод. указ. / И. Л. Коробова. - Тамбов: Изд-во Тамб. гос.техн. ун-та, 2003. - 24с.
4. Лапшин, В.А. Онтологии в компьютерных системах [Электронный ресурс] / В.А. Лапшин // RSDN Российский журнал для программистов. - 2010. - Режим доступа: http://rsdn.ru/article/philosophy/what-is-onto.xml, свободный.