16+
ComputerPrice
НА ГЛАВНУЮ СТАТЬИ НОВОСТИ О НАС




Яндекс цитирования


Версия для печати

Модуль поиска не установлен.

Документирование требований к ПО (Часть 3)

16.09.2008

Сергей Крылов

Уважаемые читатели, вторую часть статьи вы можете найти в №31 «Компьютер Price».

И один в поле воин

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

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

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

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

Инспектирование спецификаций

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

Роль

Описание

Автор

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

Инспектор

Эксперт, анализирующий спецификацию на предмет обнаружения ошибок

Рецензент

Человек, ответственный за чтение спецификации во время инспекции

Секретарь

Человек, ответственный за запись результатов инспекции

Модератор

Руководитель, управляющий и организующий процесс инспектирования

Таблица 1 

Одно лицо может исполнять несколько ролей, поэтому количество членов в группе инспектирования может варьироваться.

Для начала процесса инспектирования необходимы следующие условия:

1) Наличие всех документов, на основании которых готовилась инспектируемая спецификация.

2) Члены группы должны хорошо знать стандарты документирования требований.

3) В распоряжении группы должна быть синтаксически корректная последняя версия спецификации.

Инспекция проходит в несколько этапов:

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

·           Предварительный просмотр – спецификация передается инспекционной группе, автор сообщает об особенностях инспектируемого объекта, члены группы оценивают временные затраты на инспекцию.

·           Индивидуальная подготовка – члены инспекционной группы изучают спецификацию.

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

·           Исправление ошибок – автор исправляет обнаруженные ошибки.

·           Оценка – модератор проверяет исправления и принимает решение, нужна ли повторная инспекция.

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

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

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

Трассирование спецификаций

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

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

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

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

Наиболее типичный способ представления связей между требованиями и другими элементами системами – матрица трассируемости требований, которую также называют матрицей отслеживания требований или таблицей трассируемости. Подобная матрица заполняется по мере разработки проекта.

 

Пользовательские требования

Требования к продукту

Тесты

Use case – 45

Req – 1005

Test case – 204, Test case – 206

Use case – 48

Req – 1008

Test case – 205, Test case – 208

Use case – 48

Req – 1010

Test case – 207

Use case – 55

Req – 1008

Test case – 205, Test case – 208

Таблица 2

 

Выше приведен один из типов матрицы трассируемости требований – сложносоставная таблица трассируемости пользовательских требований, требований к продукту и тестов. Названия требований и тестов чисто условные. Важно, что каждое требование/тест уникально и последовательно идентифицировано, так что в ходе работы над проектом на него можно однозначно ссылаться. В данной матрице показано, как каждое требование к продукту связано с определенным пользовательским требованием и с одним или более тестами. Разработчики вправе добавить дополнительные столбцы для расширения связей с другими рабочими материалами, например, с документацией по архитектуре системы, с функциями исходного кода и т.п. Добавление элементов трассируемости – дополнительная работа, но так мы получаем точные данные о связанных элементах ПО, что экономит массу времени при верификации и управлении изменениями. Заполнять таблицу следует по мере выполнения работы, а не в процессе планирования. То есть вводить Req-2002 в столбец «Требования к продукту» можно, только когда спецификация этого требования документирована. Матрица составляется таким образом, что заполненные ячейки указывают на работу, которая уже выполнена, а пустые – на ту, что еще предстоит сделать. Обратите внимание, что перечисление тестов для каждого требования не указывает на то, что ПО протестировано. В матрице обозначено, что определенные тесты были написаны для проверки требований в соответствующее время.

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

·           «Один к одному»: одно пользовательское требование (Use case-45) реализуется в одном требовании к продукту (Req-1005).

·           «Один ко многим»: одно требование к продукту (Req-1005) проверяется множеством тестов (Test case-204, Test case- 206).

·           «Многие ко многим»: пользовательское требование (Use case-48) порождает множество требований к продукту (Req-1008, Req-1010), а определенные требования к продукту (Req-1008) являются общими для нескольких пользовательских требований (Use case-48, Use case-55).

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

·           один тип требования с другим требованием этого же типа;

·           один тип требования с требованием другого типа;

·           один тип требования с тестом (см. табл. 3).

 

Пользовательские требования

Тесты

Test case – 204

 

Test case – 205

 

Test case – 206

 

Test case – 207

 

Test case – 208

Use case-45

x

-

x

-

-

Use case-48

-

x

-

x

x

Use case-55

-

x

-

-

x

 

 

 

 

 

 

Таблица 3

 

Выше показана матрица трассируемости пользовательских требований и тестов. Большинство ячеек матрицы имеет прочерк. Это означает, что связи между элементами, названными в заголовке строки и заголовке столбца, нет. Каждая ячейка на пересечении двух связанных компонентов помечена крестом. Можно использовать различные символы в ячейках, чтобы явно указать направление трассирования: «трассируется до» или «трассируется от», или другие взаимоотношения. В данной таблице крест указывает, что данный тест отслеживается от определенного пользовательского требования.

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

Рекомендуется придерживаться следующей последовательности действий для реализации трассирования требований:

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

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

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

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

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

6.         Определить лиц, которые будут предоставлять информацию о связях, и ответственного, координирующего трассирование и управляющего данными.

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

8.         Попросить каждого участника предоставлять информацию о трассируемости.

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

В следующей статье мы рассмотрим управление требованиями к ПО.



статьи
статьи
 / 
новости
новости
 / 
контакты
контакты