Home

Автор: Melinda-Carol Ballou

Спонсор: Compuware
Перевод: RedRoxx Technologies

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

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

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

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

Как повысить качество требований?

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

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

Как повысить качество требований?

IDC придерживается далеко не нового взгляда на процесс разработки ПО, согласно которому определение требований и тестирование выполняется одновременно. За счет чего достигается эффект?

Когда готова первая порция требований, тестировщик уже может приступать к написанию тестовых случаев (или тест-кейсов / планов или сценариев (вариантов) использования). Если требования некачественные — противоречивые, двусмысленные, неполные и т.п. — тестировщик выявит это в процессе написания тестов, потому что методики, которые он использует, направлены на покрытие всего множества состояний и переходов, входных данных и ситуаций отказа. Тестировщик как-бы строит модель будущей системы по имеющимся требованиям и составляет тесты для проверки этой модели. Если модель описана не полностью, либо ее кусочки не складываются в единую картину, эту модель невозможно будет проверить. Другими словами, написание тестов дает обратную связь о качестве требований.

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

Рыночные тенденции требуют визуализировать требования

Что делают успешные компании, для того, чтобы выживать в конкурентной борьбе? Они наблюдают за рыночными тенденциями и стараются изменяться в соответствии с ними.

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

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

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

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

Основными факторами, способствовавшими появлению именно таких инструментов, стало увеличение числа задач, выполняемых офшорными командами или отданными в аутсорсинг, что требует более плотной и строгой координации между этими и внутренними ИТ-командами; введение отраслевых и законодательных нормативов, таких как Sarbanes-Oxley, напрямую требующих более строгих и прозрачых процессов разработки ПО; распространение сервис-ориентированной архитектуры (SOA), требующей совместной работы бизнес-заказчиков и ИТ, и как следствие, — единого языка между ними.

В следущем разделе будут представлены решения Compuware, которые адресованы рассмотренным ранее проблемам: параллельному анализу и тестированию и визуализации требований.

Решения Compuware

Compuware присоединилась к группе поставщиков современных средств управления требованиями во втором квартале 2006 года, когда она приобрела ирландскую компанию SteelTrace. Будучи уже хорошо зарекомендовавшей себя в сфере тестирования, компания очень быстро интегрировала приобретенный продукт со своей линейкой инструментов для тестирования QACenter и переименовала SteelTrace в OptimalTrace (в 4-м квартале 2006).

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

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

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

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

В Optimal Trace можно видеть все изменения, а также видеть влияние изменений на связанные требования.

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

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

Кроме того, OptimalTrace автоматизирует документирование, облегчая использование и поддержку приложения.

В OptimalTrace заложена возможность присоединять к требованиям снимки экранов, чтобы пользователи могли представлять вид будущего приложения по мере готовности интерфейсов.

Интеграция с QACenter способствует использованию тестирования, основанного на оценке рисков, за счет связи тестов с требованиями; обеспечивает прозрачность и автоматизацию процесса управления тестированием — выполнение тестов, результаты выполнения, регистрация дефектов, отчетность.

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

IDC предполагает, что приобретение SteelTrace усилит позиции Compuware на рынке продуктов для ИТ-подразделений компаний.

Резюме

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

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