Никуда без трассировки: практические советы по внедрению трассируемости

Томас Беренс, технический директор, Alpheus Solutions

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

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

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

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

Теория: основополагающие правила

Давайте начнем с теории, которая лежит в основе трассируемости технических требований.

Что такое трассируемость?

В соответствии со стандартным компьютерным словарем IEEE Standard Computer Dictionary² трассируемость определяется как "степень, с которой установлено отношение между двумя или более продуктами в процессе разработки, особенно продуктами, состоящими в таких отношениях как предшествующий-последующий элемент или ведущий-ведомый."

Rational Unified Process (RUP) определяет понятие трассируемости более общим способом, как "способность соотнести какой-либо элемент проекта с другим, связанным с проектом элементом, особенно с теми, которые имеют отношение к техническим требованиям."

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

Зачем нужна трассируемость?

Трассируемость служит двум основным целям:

Обеспечению качества продукта через придание ему всех тех возможностей, которые затребовал заказчик, а также обязательное отсутствие тех качеств, которые не были им запрошены ("создание правильного продукта"). Другой аспект качества заключается в обеспечении правильного функционирования всех затребованных возможностей ("Построение правильного продукта"). Параметр "достоверность" ³ трассирует различные уровни абстракции или детализации во время разработки относительно друг друга. Трассировка "верификации (формальной правильности)" отслеживает требования, анализ и реализацию рабочих продуктов по сравнению с соответствующими тестами. Эти два параметра - "достоверность" и "формальная правильность" трассируемости по отношению к основным дисциплинам RUP проиллюстрированы на рисунке 1.
Анализу влияния изменений через определение затронутых требований, проектных решений и артефактов реализации, а также связанных с ними тестов.

Рисунок 1: Аспекты трассируемости

Кроме достижения этих двух целей существует ощутимая побочная польза, в основном связанная с улучшением отчетности и оценки статуса проекта: ⁴

Каков процент реализованных требований?
Каков общий процент удачно реализованных (то есть протестированных) требований?
Какое количество тестов на приемлемость для пользователя мне необходимо провести, если я изменю некоторые параметры реализации?

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

Каковы необходимые предварительные условия для трассируемости?

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

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

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

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

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

Рисунок 2: Трассируемость отношений

Как трассируются требования?

Технические требования трассируются эксплицитно и имплицитно. Эксплицитная трассируемость требует от вас вручную установить отношение между двумя типами требований. Имплицитная трассируемость является результатом внутренне присущих отношений между трассируемыми объектами (то есть вашими типами технических требований) - например, по-настоящему иерархичными требованиями или через автоматически применяемые трансформации к вашим рабочим продуктам ⁸ .

В большинстве случаев трассируемостью управляют эксплицитно.

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

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

Вариант 1 часто называется "навязанная трассируемость," так как требование и трассируемость определяются в одном месте. Варианты 2 и 3 называются также "ненавязанная трассируемость," так как трассируемость поддерживается отдельно от требования.

Давайте быстро оценим различные варианты: вариант 1 отбрасываем сразу. Такой документ не только очень быстро становится сложно поддерживать, читатель отвлекается на информацию о трассируемости внутри текста, поэтому этот документ трудно читать. Более того, трассируемость - не единственная метаинформация, которую необходимо зафиксировать для технических требований. Необходимо также поддерживать другую информацию, например о приоритетности, статусе или рисках. Вариант 2 представляет компромисс и может, если стратегия обеспечивает трассировку с объекта только внутри документа или к стабильным документам. Это делает вариант 3 наиболее приемлемым подходом к трассируемости. Таблицы, конечно, удлиняют работу, однако специальные инструменты управления требованиями, например IBM Rational RequisitePro, созданы как раз для управления этим типом информации.

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

Кто это делает и когда?

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

Реальная трассируемость

Принимая во внимание то, что основные правила внедрения и поддержки трассируемости просты, кажется трудно понять, почему множество проектов пренебрегают трассируемостью. Этот симптом часто оправдывают такими причинами, как "слишком большие усилия" и "выгоды не очевидны." Это можно объяснить следующими основными причинами :

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

Передовой опыт

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

Установите соответствующий уровень трассировки. Не переоценивайте свои силы. Я видел проекты, в которых пытались осуществлять трассировку до уровня детализации, который не соответствовал ни временным рамкам, ни конкретному варианту использования. В своем первом проекте не пытайтесь выполнить трассировку до уровня конкретного варианта использования. Вы должны иметь хорошо продуманную стратегию трассируемости и оправдание для своих (огромных!) усилий. [1]

Распределяйте ваши усилия равномерно. Включите внедрение трассируемости в документирование технических требований. Не превращайте это в отдельное действие. Зачастую если это действие откладывается, и даже если оно откладывается только для определенного набора требований, трассируемость становится несистематической и поэтому бесполезной. [2, 3]

Применяйте контроль качества по отношению также и к трассируемости.. Когда вы выполняете проверки или обзоры, проверьте трассируемость. Она может быть и неправильной. Прежде всего контроль качества обеспечивает наличие трассируемости, а уж затем подтверждается её правильность до начала её применения, что увеличивает вашу уверенность при её использовании. [2, 3]

Отрегулируйте и заново пересмотрите вашу стратегию трассируемости. Нельзя ожидать, что стратегия трассируемости, которая была удачно использована в прошлом, может оставаться правильной навсегда. Выполнение проектов приводит к организационным изменениям. Типы проектов различны. Разным проектам требуются различные типы требований и/или различные типы отношений, определяемые для трассируемости. Переход от разработки собственными силами для внутренних нужд к проекту интеграции с посторонним поставщиком вероятно приведет к появлению новой документации. Переход от чисто традиционного (декларативного) способа формулирования технических требований к подходу, основанному на конкретном варианте использования, влечет за собой введение новых типов технических требований. Ваша стратегия трассируемости должна отвечать этим изменениям ¹⁰ . [1]

Занимайтесь повышением квалификации вашей команды. Трассируемость является результатом коллективных усилий. Команда, ответственная за организацию выполнения проекта, должна быть соответствующим образом подготовлена к определению подхода к трассируемости для проекта. Им нужно понимать и ценить то, что одинаково важно как трассировать требование к его источнику, так и написать хорошее определение требования к качеству. [1, 2]

Приведите контрпример. Если имеется участник проекта со стороны, занимающийся потребностями в трассируемости вашего проекта, позвольте этому сотруднику провести анализ последствий для следующего запроса на изменение. Это может оказаться более понятным. [2, 3]

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

Продумайте все как следует, но превращайте это в лишнюю проблему. Будьте прилежны и внимательны при определении информации о трассируемости, но не позволяйте трассируемости стать основным предметом обсуждения на собраниях вашей группы (или "жить ей своей жизнью"). Закон Парето применим также и к поддержке трассируемости. Если же вы сомневаетесь, в тех случаях, когда аргументы можно интерпретировать двояко, внедрите цепочку трассируемости. Это будет преимуществом в комплексном анализе последствий, обеспечивающим нахождение всех связанных разработанных требований. [1]

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

Функция, обеспечивающая, чтобы "общяя сумма всех неоплаченных счетов клиента не превышала предельную сумму кредита", может быть отнесена к некоторому количеству вариантов использования, например "(Клиент) Размещение заказа" или "(Менеджер бюджета) Регулирование лимита кредита", как этап с каком-либо варианте использования. В качестве альтернативы её можно задокументировать в описании базового понятия "Клиент" как ограничение. Это не только делает документирование удобнее, есть возможность улучшить также и трассируемость. Вместо того, чтобы выполнять трассировку с многочисленными этапами вариантов использования, можно выполнять трассировку с одним базовым понятием "Клиент", и этого будет совершенно достаточно; или же, с более точным уровнем детализации, можно выполнять трассировку с атрибутом "общее количество всех неоплаченных счетов" ¹¹ . [1, 3]

Усильте инструментальную поддержку. Инструменты не являются панацеей. Они не устраняют необходимость принимать решения относительно стратегии трассируемости, и не могут подтвердить, правильная ли трассировка и завершена ли она. Тем не менее, инструменты управления требованиями, такие как IBM Rational RequisitePro, позволяют вам:

Легко внедрять и поддерживать трассируемость по всему набору определенных требований любым ненавязчивым способом
В некоторой степени усиливать определенную стратегию трассируемости
Поддерживать распространение изменений по всей иерархии требований посредством определения требований, которые могут быть затронуты изменениями, основываясь на установленной трассируемости
Выполнять визуализацию и составлять отчёты о трассируемости (см. Рисунок 3).

Следовательно, эти возможности RequisitePro сокращают общее количество ручной работы и увеличивают надежность трассируемости. [1]

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

Рисунок 3: Матрица трассируемости, доступная в IBM Rational RequisitePro, позволяет выполнять визуализацию и составлять отчёты о трассируемости.

Выводы

Итеративный и поэтапный способ осуществления проектов, который предвосхищает и позволяет вносить значительные изменения в проект, значительно увеличивает потребность в трассируемости по сравнению с традиционными методами разработки программного обеспечения. Поэтому любые потенциально высокие, заранее определенные затраты гораздо легче возвращаются в ходе проекта (см. врезку). Способность трассировать свои требования корректно является важнейшим условием управления совместимостью в вашей корпоративной среде. Трассируемость является важнейшим понятием Модели зрелости процессов разработки (Capability Maturity Model).

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

Если трассировать, так трассировать!

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

Мораль всей этой истории такова: трассируемость не может быть внедрена "наполовину". Если вы не доверяете информации о трассируемости, лучше всего не тратьте на неё свои усилия.

Примечания

¹ Если это не предписывается правилами, установленными, например, такими организациями как Министерство обороны или Управление по контролю за продуктами и лекарствами.

² Институт инженеров по электротехнике и радиоэлектронике. Стандартный компьютерный словарь IEEE: компиляция стандартных глоссариев IEEE по компьютерной технике. Нью-Йорк, NY: 1990 г.

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

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

⁵ Как можно видеть из использованной терминологии ("трассировать с" и "трассировать от"), нам часто нужно использовать трассируемость в обоих направлениях для того, чтобы достигнуть цели трассируемости, то есть нужно иметь ответы на такие вопросы как "Реализована ли функция?", смотря сверху вниз (трассировать с), и вопросы типа "Как это влияет на результат, если мы не можем реализовать этот вариант использования?", смотря снизу вверх (трассировать от). Хорошая новость состоит в том, что вы можете создавать одно направление из другого.

⁶ То есть "или" в смысле "и/или", а не "или/или."

⁷ Относительно рисунка 2: существует более элегантный способ смоделировать ограничивающие условие через обобщение, но эксплицитное ограничивающее условие имеет большое значение.

⁸ Примером для иерархических отношений была бы трассировка от одних вариантов использования с этапами других вариантов использования, поддержанная соответствующей идентификацией. Трансформация является понятием из подхода архитектуры, управляемой моделями (model-driven architecture - MDA), при котором одна модель транслируется в другую. Это, однако, более применимо на практике в областях проектирования и реализации. См. более детальную информацию о MDA на сайте OMG Website: http://www.omg.org/mda/

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

¹⁰ Прекрасный анализ различных стратегий трассируемости, их преимуществ и недостатков может найден в техническом описании Спенса и Пробаско "Стратегии трассируемости для управления требованиями в конкретных вариантах использования", 1998 г., которая до сих пор доступна в последней версии RUP. Я настоятельно рекомендую эту статью каждому, кто отвечает за определение потребностей в трассировке для проекта, в котором применяется подход к требованиям, основанный на конкретных вариантах использования

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

¹² См. Rational Business Driven Development for Compliance , IBM Redbook, SG24-7244-00, 18 октября 2006 г. (черновик).

Ссылки

Иен Спенс и Лесли Пробаско, "Стратегии трассируемости для управления требованиями с вариантами использования," 1998 г., авторитетная статья, которая до сих пор доступна в последней версии RUP
Дин Леффингвелл, "Функции, варианты использования, требования. О, Боже!," в The Rational Edge , декабрь 2000 г.
Леффингвелл и Уидриг, Управление требованиями к программному обеспечению , Addison Wesley, 1999 г.
Для получения более детальной информации об архитектуре, управляемой моделями см. http://www.omg.org/mda/
Rational Business Driven Development for Compliance, IBM Redbook, SG24-7244-00, 18 октября 2006 г. (черновик).

Ссылки по теме