Определение требований
Все большую актуальность приобретает выстраивание правильных взаимоотношений между ИТ и бизнесом, разработка и внедрение таких решений, которые дадут реальную отдачу за минимальное время и при этом будут завершены в запланированные сроки и в рамках выделенного бюджета. Первый шаг к достижению этого идеала — формальное определение требований к будущей системе.
По определению IEEE [2], требование — это «условие или возможность, необходимые пользователю для решения той или иной проблемы или достижения той или иной цели». Управление требованиями определяется аналитиками Meta Group [3] как процесс, гарантирующий, что все специалисты, вовлеченные в проект разработки, знают об определенных требованиях к программному продукту и реализуют процессы, позволяющие эти требования удовлетворить. При всей очевидности того, какое значение имеет четкое задание требований для получения качественного конечного продукта и повышения продуктивности участников разработки, этот этап — и тем более его поддержка с помощью специальных автоматизированных средств — далеко не всегда реализуется со всей необходимой тщательностью. Разработчики часто избегают формализации требований как лишней бюрократической нагрузки, мешающей главному, по их мнению, процессу — собственно программированию. Заказчики также не всегда готовы формализовать и детализировать свои проблемы, полагая, что общей постановки задачи достаточно для того, чтобы разработчики поняли их нужды. Обе стороны заблуждаются. Формальное определение требований со стороны заказчика помогает ему прояснить свои потребности и избежать неясностей в толковании постановки задачи разработчиками. Последние, в свою очередь, получают большую свободу в выборе средств и методов реализации, когда задача понятна до деталей.
Этап определения требований — основная точка для осуществления взаимодействия между заказчиком и командой проекта. Одновременно это и ключевой этап для всего жизненного цикла, непосредственно влияющий на качество программного продукта.
Практика показывает, что чем позже будут выявлены ошибки в постановке задачи и соответственно неверно реализованные функции, тем дороже обойдется их исправление.
Процесс управления требованиями необходим, чтобы соответствовать второму, «повторяемому» уровню зрелости разработки программного обеспечения по модели СММ. Использование обычных офисных программ позволяет получить формальные описания и даже стандартизовать форматы требований для разных групп проектной команды, но не дает возможности отслеживания и совместной работы с требованиями, а также ограничивает средства обработки более сложной структуры атрибутов требований. Поэтому, начиная с третьего уровня зрелости процессов управления требований, наличие специального инструментария становится абсолютно необходимым, а наиболее высокий уровень, кроме того, потребует их тесной интеграции с другими решениями, которые используются для поддержки различных этапов жизненного цикла. Минимальный набор функций для системы управления требованиями включает средства идентификации отдельных требований, сортировку, идентификацию пересмотра в группе требований, базовый интерфейс данных. Более мощные по своим возможностям системы обеспечивают отслеживание зависимостей между требованиями, поддержку совместной работы и интеграцию со средствами моделирования, разработки и тестирования.
По данным Meta Group, 75% инсталляций систем управления требованиями принадлежит Borland, IBM Rational и Telelogic. При этом все три компании — относительные новички на этом рынке, поскольку решения по управлению требованиями были приобретены ими за последние два года. Так, система CaliberRM стала частью семейства продуктов Borland в результате покупки компании Starbase. В CaliberRM формируются шаблоны для наборов требований заказчика, которые собираются в центральном репозитории. Система предоставляет встроенную поддержку обсуждения требований различными участниками процесса. Права доступа к данным требований, привилегии и ответственность пользователей определяются в системе на ролевой основе.
CaliberRM способна поддерживать различные методы разработки, как структурные, так и приобретающие все большую популярность «быстрые» (agile) методики. В частности, имеются механизмы работы с форматами требований, принятыми в экстремальном программировании. Кроме того, предусмотрены простые средства настройки ролей, уровней управления требованиями и т.д. в зависимости от среды разработки, с которой будет работать пользователь. Поскольку CaliberRM сохраняет требования в базе данных, документы с их описанием создаются с помощью встроенного механизма генерации документов Word на базе заданных шаблонов.
Система обеспечивает экспорт данных в таблицы MS Access и импорт из Word, но пока не поддерживает обмен данными на базе XML Metadata Interchange. Табличное представление требований упрощает их сортировку и задание приоритетов в зависимости от затрат на реализацию и значимости. Для каждого требования реализуется независимый контроль версий. Предоставляются глоссарии для определения специфичных для отрасли, проекта или компании терминов с целью избежать нечеткости определения и двусмысленности толкования требований. CaliberRM поддерживает различные методы визуализации зависимостей между требованиями, с помощью которых пользователь может ограничить область анализа, необходимого в случае изменения того или иного требования. Имеется модуль, который использует данные требования для оценки трудозатрат, рисков и расходов, связанных с реализацией требований.
CaliberRM обеспечивает функциональную (на базе прикладных интерфейсов) интеграцию с другими ALM-решениями Borland — системой конфигурационного управления StarTeam и средой моделирования Together, что позволяет отслеживать влияние изменений в требованиях на исходный код и гарантировать соответствие архитектуры системы задачам заказчика. Интеграция системы со средствами тестирования компании Mercury Interactive обеспечивает быстрый выбор необходимых тестовых испытаний для проверки выполнения заданных и измененных требований, а возможность экспорта данных в систему календарного планирования MS Project — отображение требований как задач проекта.
