Читайте также статьи и материалы о технологиях Rational и Microsoft в блоге Новичкова Александра и Шамрая Александра

Трассировка Требований

Содержание

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

• Общее руководство трассировки требований 

• Руководство для трассировки Agile проектов 

• Руководство для трассировки традиционных типов проектов
  

Трассировка Требований

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

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

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

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

Эта тема в проекте Visual Studio ALM Rangers Requirements Management Guidance обеспечит руководство для пользователей Visual Studio/Team Foundation Server, которым необходимо эффективное средство для отслеживания от высокоуровневых требований до нижнего уровня и до разработки, тестирования и элементов исходного кода. После прочтения вступления, многие могут подумать, что эта тема тяжела и загружена большим количеством дополнительной проектной документации, что не свойственно гибким проектам. Но это не так. Гибкая команда увидит реализацию трассировки, которая поддерживает разбиение продукта, и итеративное управление журналом продукта, которое более простое, но мощное в обеспечении подотчетности и уменьшения сложности анализа влияния.

Примечание: Данное руководство предполагается, что требование на бизнес уровне, реализовывается рабочим элементом «Возможность» (Feature) в Team Foundation Server. Авторы не настаивают на использовании рабочего элемента «Возможность» для этих целей и признают, что это добавляет элемент формальности, который можно не использовать для небольшой и более гибкой команды.

Общее руководство трассировки требований

Стратегия трассировки

Ниже приводится диаграмма общей трассировки, которую мы приводили в разделе Планирование Управления требованиями. Она показана снова здесь для обозначения отправной точки для различных видов информации, которая должна отслеживаться для любого проекта разработки. Как указано в разделе планирования, «золотая середина» приведенной ниже диаграммы, которая поддерживается Visual Studio и Team Foundation Server, является элемент «Потребность» (Need).

При реализации, каждый из этих элементов имеет свое место в Team Foundation Server:

Тесты и Трассировки

Visual Studio поддерживает несколько видов тестов. Каждый из них имеет свою функцию и свой тип трассировки. Мы можем разделить тесты на две основные группы (хотя некоторые тесты несколько размыты и могут быть отнесены к любой группе)

• Низкоуровневые тесты – тесты созданные разработчиками и хранятся в виде файлов проекта (как правило, вместе с тем же решением как код). Например, модульные тесты (кода или баз данных), автоматические тесты, написанные разработчиком как метод проверки программного обеспечения. К этой категории можно также отнести нагрузочные тесты, которые не являются функциональными тестами и направлены на проверку производительности, оценки масштабируемости и способности работать под высокой нагрузкой. Трассировка этих тестов несколько ограничена, т.к. их результаты несколько менее интересны на уровне бизнеса. Тесты производительности находятся между низкоуровневыми тестами и системным уровнем тестирования. Они имеют низкий уровень, т.к. они построены с использованием тестовых проектов в Visual Studio. Они на системном уровне, т.к. они проверят нефункциональные реализацию нефункциональных требований или требований качества обслуживания.
• Функциональное тестирование – функциональные тесты имеют непосредственное отношение к бизнес-требованиям. Это могут быть системные тесты, для проведения испытаний, была ли пользовательская история реализована, как было определено, или тест приемки, который проверяет, была ли данная бизнес функция реализована в соответствии с запросами на бизнес-уровне.

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

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

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

Типы связей между артефактами

В Team Foundation Server могут быть созданы различные ссылки между следующими артефактами:

• Набор изменений (Changeset) – связь между рабочим элементом и набором изменений
• Элемент версионного хранения – связь между рабочим элементом и папкой или путем в системе версионного контроль
• Рабочий элемент – тип связи между двумя рабочими элементами (см. ниже)
• Гиперссылка – ссылка из рабочего элемента к URL
• Результаты тестирования – ссылка рабочего элемента с результатами выполнения теста

Отметим, что в Visual Studio 2010 связи в рабочих элементах в настоящее время обеспечивают семантику направленности и информации о связи для обозначения родительских, дочерних и связей одного уровня для рабочих элементов. Эта функция обеспечивает лучшую трассировку, т.к. проще увидеть, как один рабочий элемент иерархически относится к другому. Это позволяет понять, каким образом требования могут быть переопределены в нескольких «дочерних» требований от первоначальных требований, которые слишком широки.

Ссылки рабочих элементов имеют типы и топологию последовательности. Доступные топологий:

• Сеть

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

• Направленная сеть

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

• Зависимость

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

• Дерево

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

Типы связей, которые определены в системе:

Типы связей, определенные в шаблонах процессов MSF:

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

Рисунок 1. Возможность->Пользовательская история->Задача

Определения тестов могут быть связаны с возможностями или пользовательскими историями в соответствии с уровнем тестирования (например, определение теста пользовательской приемки связан с возможностью, в то время как системный тестовый сценарий связан с пользовательской историей):

Рисунок 2. Возможность->UAT и Пользовательская история->системный тест

Ссылки отображаются в настраиваемой форме рабочего элемента.

Связи могут быть отфильтрованы и сгруппированы по типам.

Использование ссылок с документацией

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

Если документирование слишком подробное для описания в рабочем элементе, рабочий элемент может представлять высокоуровневый дескриптор и как указатель для более подробной информации. Документ, PowerPoint слайд(ы), Visio диаграммы, таблицы Excel и другие файлы для детализации требований могут быть сохранены на портале SharePoint командного проекта. Далее, используя ссылку для рабочего элемента, эти файлы могут быть связаны с ним с использованием ссылки «URL». В самом документе идентификатор рабочего элемента как URL в Web Access (TSWA) на рабочий элемент может быть добавлен, чтобы обеспечить двунаправленную связь.

С точки зрения исполнения, любой член команды, которому необходимо для работы или понимания деталей требования, должен видеть только требования, назначенные на него. Они открывают рабочий элемент в среде Visual Studio с помощью запросов (например, все назначены на меня рабочие элементы), а затем переходит по ссылке, которая указывает на детальное описание. Аналогичным образом, если пользователь просматривает документ, хранящийся в проекте портала, ссылка на страницу TSWA для рабочего элемента позволит ему просматривать состояние рабочего элемента и связанные с ними артефакты.

Настраиваемая трассировка

Рисунок и описание выше продемонстрируют возможности, которые есть без какой-либо настройки Team Foundation Server. Благодаря своей гибкой природе, пользователи могут настроить либо из шаблонов процессов (MSF для Agile и MSF для CMMI), которые поставляются с Team Foundation Server, скачать и настроить сторонние шаблоны процесса или создать свои собственные.

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

Управление

Тема соответствия промышленным стандартам управления или юридическим законам слишком большая, чтобы описывать в этом руководстве, но использование Team Foundation Server для трассировки может помочь команде разработчиков для достижения следующих целей:

• Соответствию CMMI Level 3 для Управления требованиями (ReqM) и Разработки Требований (RD)
• Соответствию Правилам управления пищевых продуктов и медикаментов (Food and Drug Administration (FDA)) CFR-21, части 11, которая определяет цифровую подпись
• Соответствию ISO 9000 на проверку соответствия разработки по контракту
• Закон Сарбейнса-Оксли для проверки возможности финансовых операций

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

Включите возможность версионирования в SharePoint, чтобы отслеживать историю изменений документов. Вместе с проведением полного аудита рабочих элементов поддерживаемого Team Foundation Server, это создаст дополнительные возможности аудита всех артефактов проекта.

«Неэффективные» матрицы трассировки

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

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

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

• Для электронной таблицы только один человек может изменять в один момент времени. Есть государственные организации, которые нанимают сотрудников, которые занимаются в проекте только поддержкой этой трассировки. Их работа включает обход каждого разработчика, бизнес-аналитика, менеджера проекта, и т.д. и сбор их изменений, чтобы включить их в матрицу и обеспечить анализ их воздействия для команды. Это выглядит (по мнению автора) пустой тратой государственных средств (так называемых наших налогов).
• Электронные таблицы почти бесполезны для отслеживания влияния изменений или областей, пострадавших от дефектов. В 6-месячном проекте реализуемом группой из 12-15 человек (т.е. относительно небольшая) иерархия трассировки могут включать более 20000 связей трассировки. Такая таблица становится сложной для выполнения анализа влияния. В реальности в проектных командах использующих такие матрицы разработчики даже не заглядывают в нее.
• Т.к. она разрабатывается вручную, как правило, точность этих отчетов очень низкая. В некоторых государственных проектах, этот отчет размещается вместе с высокоуровневыми данными, которые не полны в конце каждого этапа проекта водопада. Поскольку размер документа потребует дни для анализа на проверку точности, аудиторы просматривают документы на соответствие без проведения анализа.

Как можно увидеть на скриншотах рабочего элемента задачи выше, полная трассировка каждого из артефактов, как указано в примере таблицы, может быть легко определена в самом рабочем элементе и поддерживается в Team Foundation Server.

Отчеты Team Foundation Server с использованием запросов для рабочих элементов в дополнение к OLAP Cube

Следующий список представляет отчеты, которые должны быть сформированы с использованием данных, которые находятся в OLAP Cube Team Foundation Server (не в SQL) или в хранилище рабочих элементов:

• Трассировка Бизнес-Требований к Системным Требованиям – демонстрирует, что у вас есть всесторонний анализ бизнес-требований и, по крайней мере, одно функциональное требование (MSF для CMMI) или Пользовательская История (MSF для Agile) для каждого Бизнес-требования. Такой отчет (что важно) покажет, где вам не хватает трассировки. Он указывает, где необходимо провести больше аналитической работы
• Функциональные требования к техническим требованиям – демонстрирует похожее покрытие на следующем уровне ниже. Подумайте здесь: «Что такое технические требования?». Следуя промышленным стандартам, установленными IEEE, CMMI, ISO, мы будем использовать определение технических требований как нефункциональные требования, что определяет качество услуг (Производительность, Надежность и т.д.), Удобность использования (Документация пользователя, Пользовательский опыт, Помощь, Обучение, и т.д.), Ограничения (Корпоративная архитектура решение как ОС, БД, Промежуточное ПО, Архитектура приложения, и т.д.), Операционность и Поддержка (Подотчетность, Автономная обработка, Отказоустойчивость, Обеспечение непрерывности бизнеса, и т.д.). Некоторые сообщества считают, что это покрывается проектной документацией, но это мнение является заблуждением.
• Функциональные и нефункциональные требования к задачам – демонстрирует, что у вас есть планируемая деятельность для каждого из ваших требований. В примере прикрепленном здесь, я реально использовать эти данные для отражения статуса завершения задач. Шаблон «Conchango» имеет встроенную часть в обработчике событий, которая преобразует изменения оставшегося времени для задачи (элемент журнала спринта) в сценарий (элемент журнала продукта) автоматически (Cool Stuff).
• Задачи к наборами изменений, тестам и дефектам (как и наоборот) – этот отчет показывает, где «резина встречает дорогу» в плане соблюдения FDA. Это дает вам отчетность, которая касается качества исходного кода. Когда у вас есть набор изменений, который не связан с задачей (или требованием), он указывает, где кто-то, возможно, внес изменения в исходный код, который может относиться к «критически опасным » характеристикам медицинского оборудования. В финансовых системах, где вы можете выявить вредоносные попытки украсть деньги (я хотел бы сослаться на сценарий фильма Superman 3 или Office Space).
• Недостающие элементы – трассировка не только визуализирует связи между различными артефактами, но она должна также удостоверить, что элементы имеют свои желаемые микроэлементы. Например, если Возможность не имеет Пользовательский приемочный тест, то такой запрос может быть создан, чтобы показать такую Возможность. Он не обеспечит всеобъемлющее определение всех положительных и отрицательных тестов, но он покажет, где не было выполнено работы по определению Теста. На основе ссылок легко создать запрос для каждого из ссылающихся элементов и показать те, которые отсутствуют.

Примеры полезных запросов:

• Возможности без приемочных тестов
• Возможности без Пользовательских историй
• Пользовательская История без задач
• Пользовательская История без тестов

Запрос идет вразрез с текущими данными, поэтому он возвращает текущее состояние при обновлении. Это полезно, если вы заполните пробелы и определить недостающие элементы. После этого можно перезапустить запрос, чтобы узнать, что еще осталось сделать. Запрос может быть запущен внутри Visual Studio, Microsoft Excel или SharePoint Dashboard.

Примечание: отчетность Team Foundation Server с помощью Native SQL

Иногда отчет по трассировке имеет смысл лишь, если он может продемонстрировать несколько уровней иерархии. Например, если есть возможность представить отчет о наборе Бизнес-функций, показывая сценарии, которые реализовывают их имплементацию и задачи, определенные для реализации решения, в комплекте с их статусом «готово-нет» и работу, которую еще предстоит сделать для них завершения. Этот отчет непросто создать с помощью Team Foundation Server OLAP Cube. Хотя это возможно, такой же отчет может быть получен с большей гибкостью при помощи Native SQL с данными хранилища данных. В следующей таблице представлены такие запросы. Колонка слева описывает разделы запроса и где он должен быть отредактирован с учетом любых проектных особенностей трассировки иерархии и атрибутов.

• Трассировка Возможность к Требованию к Задаче –> Общий отчет по прогрессу разработки Возможностей. Этот пример отчета показывает части запроса в виде 3-хуровневого дерева трассируемых рабочих элементов. Значение этого отчета является в том, что он показывает в одном отчете организацию различных вех проекта. В частности, для традиционного жизненного цикла разработки (водопада), он может продемонстрировать трассировку от бизнес к функциональным, к техническим требованиям. Это для вехи, где окончательные оценки разработки, как правило, сделаны. Для гибкой разработки 3-хуровневый отчет трассировки обеспечивает представление от журнала продукта к журналу спринта, к тестам. Это единственный вид иерархии элементов, который может показать ход разработки в направлении завершения плана.

Пример отчета сгенерированного по вышеприведенному запросу выглядит следующим образом:

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

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

Руководство для трассировки Agile проектов

Гибкие проекты хорошо подходят к трассировке. Используя лозунг из Agile Манифеста «Работай над программным обеспечением, а не над Всеобъемлющей документацией», гибкая команда ищет иерархию трассировки с минималистским подходом. Однако, с учетом сказанного, должна быть достаточная трассировка к документации, которая гарантирует, что команда может эффективно покрыть все их требования и определить влияние изменений и новых требований в отношении существующего проекта. Следующая диаграмма показывает минималистский подход, который ложиться на общую иерархию трассировки приведенную выше.

Руководство для трассировки традиционных типов проектов

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

08.07.2010

Комментарии

• NGYtZfbaTRTK
  Автор: QdmQfZ , [url=http://ujoqflljxzru.com/]ujoqflljxzru[/url], [link=http://iluxijzkpllu.com/]iluxijzkpllu[/link], http://glxwruairtwc.com/  ·  29.12.2011 15:04:51
  QdmQfZ , [url=http://ujoqflljxzru.com/]ujoqflljxzru[/url], [link=http://iluxijzkpllu.com/]iluxijzkpllu[/link], http://glxwruairtwc.com/
• jfxnYLFmivZx
  Автор: tY1wDZ , [url=http://seamcjhpablx.com/]seamcjhpablx[/url], [link=http://tagkfqvsoysi.com/]tagkfqvsoysi[/link], http://hpvzbmygvvbw.com/  ·  27.12.2011 16:21:32
  tY1wDZ , [url=http://seamcjhpablx.com/]seamcjhpablx[/url], [link=http://tagkfqvsoysi.com/]tagkfqvsoysi[/link], http://hpvzbmygvvbw.com/
• yVbLShgjslQVRYXq
  Автор: 9rqXVj riqcoqwkxviy  ·  26.12.2011 11:59:27
  9rqXVj riqcoqwkxviy
• QvzbKWnaYmubOa
  Автор: Wowza, problem soelvd like it never happened.  ·  26.12.2011 10:18:26
  Wowza, problem soelvd like it never happened.

Добавить комментарий (анонимные комментарии не публикуются!!!)

ФИО:
E-mail:
Тема:
Комментарий:
Оценка:
Код подтверждения:

Читайте также статьи и материалы о технологиях Rational и Microsoft в блоге Новичкова Александра и Шамрая Александра

Новости и пресс-релизы СМ-Консалт

Архив "Новости и пресс-релизы СМ-Консалт"