CC BY
75
Аппарат нечеткого вывода выполняет нечеткий логический вывод с выбранной точностью и обосновано выбранными методами активизации, аккумуляции и дефаззификации.
Предложенный подход соединения онтологий позволяет объединять онтологии одной предметной области на основе анализа интенсионалов терминов, принадлежащих терминосистеме и номенклатуре. Для этого выполняется сравнение отношений между соответствующими множествами интенсионалов, основанное на анализе отношений
неравенства, равенства, включения и пересечения множеств, представляющих элементы интенсио-нала сравниваемых терминов, с применением нечеткого логического вывода. В работе показан способ введения нечеткости и пример применения методов нечеткого регулирования.
Список литературы
1. Мельников Г.П. Основы терминоведения. - М.: Изд-во ун-та дружбы народов, 1991. - 116 с.
2. Асаи К., Ватага Д., Иваи С. и др. Прикладные нечеткие системы. / Под ред. Тэрано Т. - М.: Мир. - 1993. - 344 с.
РАЗРАБОТКА ПРОГРАММНЫХ СРЕДСТВ НА ОСНОВЕ ГИБКИХ МЕТОДОВ
В.В. Бахтизин, к.т.н., С.Н. Неборский
(Белорусский государственный университет информатики и радиоэлектроники, г. Минск)
В последнее время значительно возрос интерес к гибким методам разработки программных средств (ПС). Об этом свидетельствуют различные курсы и тренинги по гибким методам, предложения получить сертификат, удостоверяющий уровень подготовки специалиста. Все гибкие методы интуитивно близки, и выбор того метода, который оптимально решит производственную задачу - проблема не из легких. Проанализировав существующие гибкие методы разработки, можно сделать вывод, что сегодня не существует того метода, который давал бы всегда хороший результат, независимо от условий его применения и целей проекта. В данной работе показано, что нельзя опираться исключительно на один метод - в большинстве случаев необходим симбиоз. Предложена модель ролей команды, которая должна позволить эффективно разрабатывать ПС. На основе выбранного подмножества гибких методов и предложенной модели ролей команды в работе предлагается новый гибкий метод разработки ПС.
Гибкая разработка ПС - это концептуальный каркас для реализации проектов программной инженерии. Она устанавливает первостепенной ценностью непосредственно разработку ПС, а все остальные активности (написание проектной документации, поддержание моделей архитектуры ПС и т.п.) являются второстепенными. Гибкие методы ставят своей целью разработку ПС в срок, в рамках установленного бюджета и, самое важное, они стремятся создать ПС именно таким, каким его хочет видеть заказчик. Два первых постулата манифеста методологии гибкой разработки ПС гласят [1]:
- наивысший приоритет отводится удовлетворению заказчика;
- приветствуется изменение требований.
Таблица содержит характеристику наиболее распространенных гибких методов в предельно сжатой форме.
Проанализировав каждый из приведенных гибких методов, можно сделать вывод, что не существует универсального решения проблемы эффективного создания ПС в условиях постоянно изменяющихся
требований. Именно поэтому необходим некий симбиоз, некая совокупность совместно используемых методов. В качестве таких методов были выбраны гибкое моделирование (Agile Modeling), экстремальное программирование (XP) и разработка, ведомая функциями (FDD). На основе этих методов и был предложен новый метод разработки ПС.
Таблица
Метод Характеристика
Agile Modeling Метод предназначен для создания моделей ПС в условиях изменяющихся требований
XP (eXtreme Programming) Метод представляет собой большей частью набор приемов разработки ПС (например, парное программирование); изменение требований не контролируется
Scrum Метод сводится к управлению проектом, не предполагает комплексного подхода к созданию ПС; изменение требований рассматривается как уничтожение старой функциональности и создание новой
FDD (Feature- Driven Development) Опора на функции как на некоторые формализованные удобные для реализации описания требований;изменение требований допускается лишь на новом инкременте реализации ПС
DSDM (Dynamic Systems Development Method) Команда наделена существенными полномочиями; реверсивность любых изменений; фиксация требований на раннем этапе разработки ПС
TDD (Test-Driven Development) Преувеличение роли тестов; реализация определенного функционала лишь после того, как написан и проверен его тест
ASD (Adaptive Software Development) Разработка ПС - постоянный процесс адаптации к текущему состоянию проекта; предполагается, что заказчик не может точно определить своих требований, а разработчик всегда должен искать баланс между определенностью и неясностью в проекте
При необходимости создания архитектуры ПС имеет смысл использовать гибкое моделирование. Получаемые модели обладают следующими свойствами: практичность, понятность, точность и непротиворечивость, достаточная детальность, простота.
Гибкие методы разработки делают акцент непосредственно на разработке ПС. Для эффективного ведения разработки необходим набор определенных принципов и практических приемов. Именно поэтому всегда необходимо рассматривать и считаться с идеями XP. В основе XP лежат следующие четыре принципа: коммуникация, предельная простота, обратная связь, требовательность к команде разработчиков-профессионалов.
Эти принципы привели к следующим идеям, составляющим основу XP:
- парное программирование;
- всегда оставаться на связи с заказчиком;
- тестирование упреждает разработку;
- короткие итерации;
- все должно быть максимально простым;
- не разрабатывать ничего лишнего без непосредственного требования заказчика;
- коллективное владение проектом.
Безусловно, гибкое моделирование и XP способствуют эффективной разработке ПС. Существует даже такой метод, как XP масштаба предприятия (EXP - Enterprise XP), суть которого и состоит в объединении XP и гибкого моделирования [1]. Однако ни XP, ни гибкое моделирование не касаются планирования проекта. Но для заказчика важно не только качество ПС, но также время его разработки и бюджет. Без хорошего планирования вероятность успеха любого проекта снижается многократно. Разработка, ведомая функциями (FDD), добавляет необходимый элемент контроля.
Согласно FDD, функция - это такое требование, реализация которого запланирована и связана с определенной активностью по его реализации. То есть функции связывают требования с планированием. FDD предполагает наличие жестко определенных временных рамок, которые отводятся на реализацию набора функции. Эти временные рамки, набор функций (запланированных к реализации требований), их приоритеты и определяют итерацию в FDD [2].
Суммируя сказанное, предлагаем метод разработки ПС на основе:
1) метода гибкого моделирования, что позволяет создать архитектуру ПС;
2) принципов XP, что позволяет эффективно разрабатывать ПС;
3) метода FDD, что дает управление проектом.
Предлагаемый метод предполагает наличие следующих этапов реализации ПС:
- инициация - создание общей картины решаемой задачи, проектирование и планирование;
- этап итераций - процесс реализации и поставки работающего ПС, при котором на каждой итерации реализуются новые требования и, возможно, изменяются старые;
- сопровождение - исправление обнаруживаемых ошибок и реализация новых требований, возникших после поставки ПС.
На рисунке 1 приведена взаимосвязь предлагаемых этапов разработки.
Подобно существующим гибким методам, предлагаемый в данной работе метод основан на итера-
тивной разработке. Для эффективной реализации качественного ПС предлагается использовать два вида итераций: итерации с поставкой ПС заказчику и внутренние итерации, каждая из которых предназначена главным образом для команды инженеров по качеству. Внутренние итерации показывают прогресс разработки ПС и удостоверяют отсутствие ошибок в поставляемой заказчику версии ПС.
На рисунке 2 пояснена итеративность предлагаемого метода разработки ПС.
Рис. 2. Итеративность процесса разработки ПС
Описание процесса разработки ПС предполагает определение ролей команды разработчиков. Как показывает анализ литературы, для работы с гибкими методами необходимо наличие команды профессионалов [3]. Именно люди, а не технологии или методы, определяют успех проекта. Предлагаемая данным методом модель ролей команды разработчиков приведена на рисунке 3.
Модель основана на ролях команды М8Б, а также на ролях команды DSDM. Следует рассмотреть каждую из предлагаемых ролей в отдельности.
Целью работы менеджера продукта является удовлетворение требований заказчика. Его область деятельности - это маркетинг, защита заказчика, планирование проекта. В обязанности менеджера проекта входит представление интересов заказчика, формирование общей картины решения, формализация требований заказчика, принятие решений, касающихся треугольника компромиссов: функции -ресурсы - временные рамки, разработка и реализация плана коммуникации с заказчиком.
Целью менеджера проекта является доставка ПС, реализованного в заданных условиях. Его область
Менеджер проекта
Менеджер продукта
Связь: почта, телефон, система учета ошибок, обмен текстовыми | сообщениями в режиме реального/ времени
Тестировщик
Программист
Прочие роли
Рис. 3. Модель ролей команды
деятельности охватывает управление проектом, процессом обеспечения качества, администрирование. В обязанности менеджера проекта входит: управление процессом разработки, с тем чтобы продукт был поставлен вовремя; координирование коммуникации команды; распределение задач и информирование о статусе проекта; управление проектными рисками.
Целью программиста является разработка ПС согласно спецификации. В его обязанности входит: оценка времени и сложности каждой задачи; разработка (программирование) ПС; подготовка ПС к поставке.
Область деятельности тестировщика связана с планированием тестирования, тестированием и ведением отчетности по обеспечению качества. В обязанности тестировщика входит: идентификация проблемных областей ПС; разработка плана и стратегии тестирования; проведение тестирования.
Схема на рисунке 4 показывает типичный сценарий взаимодействия команды разработчика и заказчика.
X Оценивает сложность
своих задач, информи-,, Заказчик, рует о прогрессе менеджер продукта
Программист
Определяет новые требования
Реализует функции ПС, информирует тестировщика Определяет задачи разработчика Определяет задачи тестировщика
Тестирует ПС, информирует о наличии ошибок
Формализует результаты тестирования
Тестировщик
Менеджер проекта
Рис. 4. Взаимодействия команды разработчика и заказчика
Предложенные выше роли команды следует относить к основным ролям команды разработчика. В зависимости от проекта, помимо этих основных ролей, в разработке могут участвовать и прочие специалисты. Например, к ним могут относиться бизнес-аналитик (специалист предметной области в команде разработчика) или проектировщик баз данных (специалист по созданию эффективных структур и моделей данных).
Следует отметить, что приведенная модель не содержит роли архитектора ПС. Это объясняется тем, что при постоянно изменяющихся требованиях
архитектуру ПС предлагается получать исходя исключительно из требований. Определять программную архитектуру должны сами программисты и менеджер проекта. При этом должен использоваться метод гибкого моделирования. Причем на его основе должны быть созданы модели, лишь поясняющие архитектуру ПС. Детальная же архитектура должна строиться на основе требований автоматически. Тогда задача получения программной архитектуры будет сведена к получению отображения требований в компоненты программной архитектуры [4]. Требования могут быть заданы в виде множества К:
К={г. 11=1,пК } , где пК - количество требований;
Г = {аи|аие^А.|> л=1п*а} - 1-е требование; Aj - множество значений .-го атрибута; пА - количество атрибутов.
Для задания связей между требованиями используются матрицы трассируемости, или списки трасси-руемости. Трассируемость требований документирует зависимости и логические связи отдельных требований и других элементов ПС [5]. Матрица трасси-руемости может быть представлена как квадратная матрица размерностью пКх пК:
м=[т„] ,
1, если г. зависит от Г;
где т., =
11 10, если г. не зависит от г,;
Г|,г,еК - требования; К - множество требований;
пК - количество требований.
Отдельное требование или группа логически связанных требований реализуется в виде отдельного компонента ПС. Пусть С - множество таких компо-
где с1 - 1-й компонент ПС;
С={с.|1=1,пс} ,
пС - количество компонентов ПС.
Необходимо задать отображение множества требований К во множество компонентов ПС С: / „Л
С или Е=
Г1 Г2 ••• Ч
Е(Г1> ЕОгД.Л'СГпк )у
где Е(Г,)еСД=1,пк .
Приведенные рассуждения показывают возможность получения программной архитектуры на основе требований. Более того, существует возможность автоматизировать этот процесс, и автоматически получать программную архитектуру на основе требований [4]. Такой подход гарантирует целостность (согласованность) требований и их реализации.
Команда, построенная на основе предложенной модели ролей, - это команда равных, то есть все специалисты, независимо от выполняемых ими ролей, равны. Следует отметить, что лучших результатов удается добиться при создании ПС небольшой командой разработчиков (до 10 человек). Это позволяет оперативно и качественно реагировать на все запросы заказчика. Для больших проектов рекомендуется создавать команды команд, то есть малые группы специалистов, работающих параллельно.
Подводя итог, следует отметить, что в данной работе предложен метод разработки ПС. Этот метод основан на трех гибких методах разработки: гибком моделировании, экстремальном программировании и разработке, ведомой функциями. Гибкое моделирование позволяет эффективно создавать архитектуру ПС в условиях изменяющихся требований, причем получаемые модели носят концептуальный характер. Детальная же архитектура создается автоматически как прямое отображение требований в компоненты ПС. Для качественной реализации этих компонентов используются приемы и подходы экстремального программирования. Разработка, ведомая функциями, позволяет управлять созданием ПС. Предлагаемый метод определяет наличие трех этапов при создании ПС: инициации, этапа итераций и сопровождения. Итеративная разработка составляет основу предлагаемого метода, причем выделяются итерации с поставкой ПС заказчику и внутренние итерации. Однако метод разработки требует наличия не только структурированных методов и подходов,
но также определения ролей команды, которая его реализует. В данной работе была предложена модель ролей команды разработчика, состоящая из менеджера продукта, менеджера проекта, программиста и тестировщика. Практическое применение предложенного в данной работе метода позволит эффективно создавать качественное ПС в условиях неясных и постоянно изменяющихся требований, когда сроки реализации малы и ресурсы проекта ограничены.
Список литературы
1. Hunt J. Agile Software Construction - Springer-Verlag London Limited, 2006, 254 p.
2. Palmer S.R., Felsing J.M. A Practical Guide to Feature-Driven Development - Prentice Hall, 2002, 304 p.
3. Boehm B. Get Ready for Agile Methods, with Care // IEEE Software Development - Jan 2002, p. 64 - 69.
4. Бахтизин В.В., Неборский С.Н. Создание управляемой программной архитектуры // Программные продукты и системы - № 3. - 2006. - С. 2 - 5.
5. Вигерс К. Разработка требований к программному обеспечению. - Издат.-торг.дом «Русская Редакция», 2004.
МЕТОД АВТОМАТИЧЕСКОЙ КЛАСТЕРИЗАЦИИ ТЕКСТОВ И ЕГО ПРИМЕНЕНИЕ
(Работа поддерживалась компанией Яндекс, грант №102903)
М.В. Киселев, к.т.н. («Megaputer Intelligence», г. Москва); М.М. Шмулевич (МФТИ); А.И. Эрлих, д.т.н. (ВЦ РАН, г. Москва)
Объем массивов текстовых документов в научной сфере, бизнесе и других областях человеческой деятельности неуклонно растет. Этим обусловливается растущий интерес к методам автоматической текстовой кластеризации. В ряде методов кластеризации текстовых документов используются древовидные структуры, при этом часто применяется подход BoW, в котором текст рассматривается как неупорядоченный набор начальных форм слов, входящих в него (Bag of Words).
Ни один из существующих основных методов автоматической кластеризации текстов не обладает набором свойств, необходимых для быстрого и эффективного решения кластеризационных задач, в частности, иерархической кластеризации новостей [2].
Одним из перспективных направлений повышения эффективности работы алгоритмов, использующих древовидные структуры для кластеризации текстов, является расширение пространства правил, находящихся в узлах деревьев.
Помимо унитарных правил, отвечающих наличию в тексте одного определенного терма, при формировании таких древовидных структур возможно учитывать агрегированные правила, построенные на основе статистических и семантических характеристик всей совокупности выделяемых из текстовых документов термов. Предложим один из таких методов, названный островной кластеризацией. Алгоритм основан на использовании статистической меры корреляции встречаемости в текстах термов, ха-
рактеризующихся значимым превышением их частот над средним уровнем.
Начальная часть алгоритма состоит в построении так называемого графа корреляций термов. Этот граф задается матрицей парных корреляций булевых переменных а1р, отражающих наличие терма 1 в документе р, так что связь между термами 1 и j считается существующей при достаточно сильной (больше пороговой) корреляции между переменными а1 и ар. Степень корреляции между термами 1 и j определяется следующим образом. Пусть п - общее количество термов во всех документах; п1 - количество термов в документах, в которых встречается терм 1. Обозначим общее число термов j во всех текстах как а количество термов j в документах, содержащих терм 1, как Если принять гипотезу, что термы 1 и j распределены в документах независимо друг от друга, то вероятность того, что в документах, содержащих терм 1, окажется N¡1 или более термов j - это вероятность получения не менее ] успехов в серии из N испытаний при вероятности успеха одного испы-
I, равной — /— то есть PB(Njj,Nj,—L), где
N
Рв (п,]р) = X Ь(1;]р), Ь - функция биномиального
1=п
распределения.
Вероятность р-=) может быть принята в качестве основы для расчета меры корреляции
