ISSN 0236-235X (P)
ISSN 2311-2735 (E)

Публикационная активность

(сведения по итогам 2016 г.)
2-летний импакт-фактор РИНЦ: 0,493
2-летний импакт-фактор РИНЦ без самоцитирования: 0,389
Двухлетний импакт-фактор РИНЦ с учетом цитирования из всех
источников: 0,732
5-летний импакт-фактор РИНЦ: 0,364
5-летний импакт-фактор РИНЦ без самоцитирования: 0,303
Суммарное число цитирований журнала в РИНЦ: 5022
Пятилетний индекс Херфиндаля по цитирующим журналам: 355
Индекс Херфиндаля по организациям авторов: 499
Десятилетний индекс Хирша: 11
Место в общем рейтинге SCIENCE INDEX за 2016 год: 304
Место в рейтинге SCIENCE INDEX за 2016 год по тематике "Автоматика. Вычислительная техника": 11

Больше данных по публикационной активности нашего журнале за 2008-2016 гг. на сайте РИНЦ

Вход


Забыли пароль? / Регистрация

Добавить в закладки

Следующий номер на сайте

4
Ожидается:
16 Декабря 2017

Информационная поддержка распределенной разработки программного обеспечения на основе онтологии

Статья опубликована в выпуске журнала № 1 за 2008 год.[ 21.03.2008 ]
Аннотация:
Abstract:
Авторы: Попов Д.В. () - , ,
Ключевые слова: программное обеспечение, онтология, анализ, информационная поддержка
Keywords: the software, ontology, analysis, data support
Количество просмотров: 9798
Версия для печати
Выпуск в формате PDF (1.92Мб)

Размер шрифта:       Шрифт:

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

 

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

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

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

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

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

Решению проблемы повышения эффективности распределенной разработки ПО посвящены разработки многих крупных компаний, таких как Microsoft, IBM, Project Management Institute и большое количество работ как отечественных (В.Л. Павлов, А.А. Терехов, А.М. Сапегин, Э.В. Попов, В.Б. Тарасов и др.), так и зарубежных исследователей. Однако предлагаемые ими решения не в полной мере учитывают специфику такой деятельности.

Анализ показал, что из проблем, связанных со взаимодействием исполнителей, наиболее формализуемой является проблема поддержки коммуникаций. Рассмотренные готовые средства коммуникаций не обеспечивают открытые интерфейсы для последующей возможности интеграции со сторонними разработками, зачастую имеют высокую стоимость и предъявляют жесткие требования к аппаратно-техническому обеспечению. Наиболее подходящими для обеспечения коммуникаций на уровне данных являются различные наборы библиотек, компонент и сред для разработки, например Flash Media Server, позволяющий манипулировать потоками видео-, аудио- и текстовой информации. В то же время они не предназначены для обеспечения коммуникаций на семантическом уровне, когда разработчики используют единую базу знаний (онтологию). Существующие редакторы онтологий, в свою очередь, также не предназначены для интеграции с какими-либо средствами обеспечения совместной работы. Поэтому предлагается разработка программно-информационного обеспечения на основе интеграции методов инженерии знаний и информационно-коммуникационных технологий.

Основные положения подхода

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

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

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

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

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

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

· методологической и организационной поддержки процесса разработки ПО (разработка и онтологическое представление системно-когнитивных моделей жизненного цикла разработки ПО).

Подпись: Рис. 1. Механизм информационной поддержки при разработке ПОПредлагается интеграция перечисленных способов представления информации в рамках единой онтологической модели:

О=ОМЕТАÈОБПУПÈОПРПОÈОогрÈОПрОÈООпД,

где ОМЕТА – метаонтология; ОБПУП – онтология процессов управления проектами; ОПРПО – онтология процессов разработки ПО; Оогр – ограничения, накладываемые на роли терминов в отношениях; ОПрО – онтологии предметных областей выполняемых проектов; ООпД – оперативные данные по выполняемым проектам.

Модели и методы организации знаний

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

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

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

Подпись:

Рассмотрим процесс построения онтологии для проекта по разработке ПО. Группа задач, которые предстоит решать при выполнении проекта по разработке ПО – это согласно модели: «Составление спецификации», «Кодирование», «Проектирование», «Управление проектом» и др. Группа агентов – это множество участников проектов, каждому агенту соответствует реальный человек, например: «Кудрявцев», «Кузнецов», «Певцов» и др.

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

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

< агент, роль, задача >,

< роль, задача, входные данные > и

< задача, входные данные, выходные данные >.

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

Программная реализация

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

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


Постоянный адрес статьи:
http://swsys.ru/index.php?page=article&id=112
Версия для печати
Выпуск в формате PDF (1.92Мб)
Статья опубликована в выпуске журнала № 1 за 2008 год.

Возможно, Вас заинтересуют следующие статьи схожих тематик: