Модульный подход к построению систем управления требованиями Текст научной статьи по специальности «Компьютерные и информационные науки»

МОДУЛЬНЫЙ ПОДХОД К ПОСТРОЕНИЮ СИСТЕМ УПРАВЛЕНИЯ ТРЕБОВАНИЯМИ

А.Ю. Зырянов Научный руководитель - к.т.н., доцент Н.Ф. Гусарова

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

Введение

Аналитические исследования и обзоры в области разработки программного обеспечения показывают, что большая часть проектов завершается с опозданиями, превышениями бюджетов, в них не реализуются в полном объеме или аннулируются до завершения требуемые функции. Так, по данным аналитических исследований компании The Standish Group, за последние десять лет не более 30% программных проектов завершаются в положенный срок и в рамках бюджета [1]. При этом проблемы более чем трети программных проектов непосредственно связаны с работой с требованиями. Сюда относятся:

• недостаток исходной информации от клиента;

• неполные требования и спецификации;

• изменение требований и спецификаций.

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

Основным же следствием проблем с требованиями является переделка того, что, как казалось, уже готово. На это расходуется от 30 до 50% общего бюджета разработки, а ошибка в требованиях стоят от 70 до 85% стоимости переделки. По данным компаний Hewlett-Packard, IBM, Hughes Aircraft, TRW [2], исправление ошибки до начала этапа конструирования обходится в 10-100 раз дешевле, чем ее устранение в конце работы над проектом, во время тестирования приложения или после его выпуска. В десятках компаний было обнаружено, что политика раннего исправления дефектов может в два и более раз снизить финансовые и временные затраты на разработку [2].

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

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

• снижение стоимости модификации;

• ускорение разработки;

• уменьшение разобщенности разработчиков и «расползания границ» проекта;

• более точные оценки при тестировании,

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

Управление требованиями

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

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

• полнота;

• ясность;

• корректность;

• согласованность;

• верифицируемость;

• необходимость;

• полезность при эксплуатации;

• осуществимость;

• модифицируемость;

• трассируемость;

• упорядоченность по важности и стабильности;

• наличие количественной метрики.

Процессы по работе с требованиями разделяются на две области - разработка требований и управление требованиями. В частности, методология усовершенствования процессов CMMI (Capability Maturity Model Integration) относит «управление требованиями» (Requirements Management) к процессам второго уровня зрелости, а «разработку требований» (Requirements Development) - к третьему [4].

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

• управление версиями и изменениями;

• хранение атрибутов требований;

• облегчение анализа воздействия (за счет хранения связей между требованиями);

• трассировка статусов требований;

• контролируемый доступ;

• связь со всеми заинтересованными в проекте лицами;

• повторное использование требований;

• интеграция с другими средствами управление проектами;

• сбор и обработка статистики требований.

Подходы к управлению требованиями

Широко распространен поход работы с требованиями с помощью создания структурированных документов (ТЗ, Software Requirements Specification, RUP Visio и т.д.). В лучшем случае такие документы размещаются в репозиториях с контролем версий. Данный подход имеет ряд существенных ограничений:

• трудность хранения дополнительной информации (атрибутов) для каждого требований;

• трудность определения взаимосвязей между требованиями разного уровня и другими элементами системы;

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

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

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

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

Инструментальные средства первой группы обладают широким спектром предоставляемых возможностей и богатым пользовательским интерфейсов. Лидерами среди таких продуктов являются Borland CaliberRM, IBM RequisitePro, Telelogic Doors. По мнению экспертов [5], одной из проблем подхода применяемого в данных инструментах является излишняя обобщенность. Зачастую крупные и средние компании разработчики уже имеют вполне определенные процесс по работе с требованиями, и в качестве основного средства настройки инструментов под процесс предлагается создание новых типов требований с заданными атрибутами. При этом интерпретация этих атрибутов возлагается на пользователя.

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

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

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

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

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

Разработанная система позволяет изменять свой функционал за счет установки новых модулей. Новый модуль устанавливается на серверной стороне и представляет собой zip-архив, который состоит из манифеста модуля и компонент (рис. 1). Манифест - это файл в формате XML, который содержит необходимые описания для установщика модулей, например импортируемые элементы управления (Controls). Компонентами являются любые сущности платформы ASP.NET, например страницы, элементы управления, сборки и т.д.

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

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

Рис. 1. Расширяемость за счет модулей

PortalPage PortalTem plate

< 1 ► 1

PortalControl PlaceHolder

\

/ '

/

PortalControl помещается на PlaceHolder

Рис. 2. Основные классы пользовательского интерфейса

Динамическая компоновка страниц делает задачу взаимодействия элементов управления на странице более сложной. Так, элементы управления не имеют информации от других элементах на скомпонованной странице и не могут вызывать их методов. Для решения данной проблемы предлагается использовать типовое решение «дополнительный модуль» (Plugin) [6], которое позволяет связывать классы во время исполнения, а не во время компиляции. Например, некоторому элементу на странице необходимо отображать требования, а за отображение требования отвечает другой элемент управления (рис. 3). Классы отделаются за счет выноса интерфейса, а их связывание производит после компоновки страницы.

«interface» IRequirementView

UserControl \

/

+Show(e requirement)

Рис. 3. Типовое решение «дополнительный модуль»

Классы элементов управления декларативно публикуют реализуемое ими поведение с помощью атрибутов Export.

[Export(typeof(IViewRequirement))]

public partial class ViewRequirement : PortalControl, IViewRequirement

{

protected void Show(Requirement req) {

//...

InitWebForm(req);

//...

}

}

Аналогично элементы публикуют необходимое поведение через свойства класса с атрибутами Import.

public partial class UserControl : PortalControl

{

[Import()]

public IViewRequirement view { get; set; }

protected void Page Load(object sender, EventArgs e) {

Requirement r = GetLastRequirement();

view.Show(r);

}

}

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

На рис. 4 изображен пример пользовательского интерфейса редактирования требований. В левой части интерфейса расположено дерево пользовательских требованиями, в правой - редактор атрибутов требований.

Рис. 4. Интерфейс редактирования требований Заключение

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

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

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

Литература

1. Elizabeth Hull, Ken Jackson, Jeremy Dick. Requirement Engineering - Springer, 2005.

2. Макконелл С. Совершенный код. Мастер-класс. - СПб: Питер, 2008.

3. Вигерс К. Разработка требований к программному обеспечению - М.: Русская редакция, 2004.

4. Мильман К., Мильман С. CMMI - шаг в будущее. Часть 3. Разработка управления требованиями // Открытые системы. - 2005. - №9.

5. Anthony Finkelstein, Wolfgang Emmerich. The Future of Requirements Management Tools - Режим доступа:

http://www.cs.ucl.ac.uk/staff/W.Emmerich/publications/OeCG/traunpaper.pdf

6. Фаулер М. Архитектура корпоративных программных приложений. - М.: Издательский дом «Вильямс», 2007.

7. Леффиигуэлл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход - М.: Вильямс, 2002.

8. Орлик С., Булуй Ю. Введение в программную инженерию и управление жизненным циклом ПО. Программная инженерия. Программные требования. - Режим доступа: http://www.sorlik.ru/swebok/3-1-software_engineering_requirements.pdf