Заметки консультанта

Шамрай Александр Владимирович

Archive for the ‘Requirements Management Guidance’ Category

Руководство по управлению требованиями VS TFS 2010 – Контрольные списки для разработки требований

Posted by Шамрай Александр на Ноябрь 30, 2010

<<Содержание

  1. Планирование приемочного тестирования
  2. Оценка результатов приемочного тестирования
  3. Запросы на изменения
  4. Декомпозиция работ
  5. Рецензирование проектирования верхнего уровня
  6. Рецензирование детального проектирования
  7. Рецензирование документов
  8. Формальная проверка проекта
  9. Инспекция документации
  10. Приемка продукта
  11. Определение вех проекта
  12. Проверка требований
  13. Стиль требований
  14. Сценарии или процедуры тестирования
  15. Проектирование тестов
  16. Рецензирование плана тестирования
  17. План управления тестированием
  18. Рецензирование вариантов использования

Планирование приемочного тестирования
Предполагаемое использование списка Для команды проекта или менеджера закупки ПО при планировании приемочных испытаний. Этот список вопросов позволит включить важные пункты для организации эффективного приемочного тестирования продукта.
ID

Вопрос

1 Решались ли проблемы с предыдущими поставками от этого поставщика, которые могут быть включены при планировании этих приемочных тестов?
2 Определены методы проверки по каждому требованию (инспекции, анализ, демонстрации или тесты)?
3 Критерии принятия задокументированы?
4 Трассировка Требований обеспечена и все требования были учтены? (Пользовательские требования — процедура тестирования)
5 Задокументированы условия испытаний для каждой среды?
6 Определено и согласовано специальное оборудование для тестирования?
7 Если необходимо восстановление данных, то инструменты, оборудование и люди для этого определены и согласованы?
8 Есть ли люди с необходимой специализацией для проведения тестов и люди, которые имеют эту специализацию, согласованы?
9 Разработаны детальные пошаговые процедуры для каждого теста?
10 Если пользователь должен подтвердить процедуру для теста, сделал ли он это?
11 Если необходимо применение QA, запланированы ли работы для отдела QA?
12 Если пользователь (или заказчик) должен заверить тесты, это запланировано?
13 Есть ли ограничения тестирования или результатов тестирования со стороны поставщиков, которые говорят, что специальные тесты должны быть выполнены во время приемочных тестов? Если это так, они включены в план?
14 Были ли определены возможные аномалии тестирования вместе с условиями, при которых они могут возникнуть, и методы работы с ними?
15 Определены процессы работы с отклонениями от тестовых процедур?
16 Определен процесс работы с дефектами до их закрытия?
17 Процедуры и инструменты тестирования позволяют выполнять удобное регрессионное тестирование?
18 Есть ли согласованный процесс для хранения результатов тестирования, в том числе, ответственный за журнал тестирования?
19 Другое

Оценка результатов приемочного тестирования
Предполагаемое использование списка Для команды проекта или менеджера закупки ПО при планировании приемочных испытаний. Этот список вопросов позволит включить важные пункты для организации эффективного приемочного тестирования продукта.
ID

Вопрос

1 Все тестовые процедуры выполнены?
2 Аномалии были проанализированы, чтобы подтвердить правильность тестов?
3 Тесты были проведены при надлежащих условиях?
4 Тесты были заверены соответствующими людьми?
5 Восстановление данных было выполнено и проверено соответствующими лицами?
6 Отклонения были проанализированы и адресованы соответствующим лицам?
7 Все необходимые повторные тесты были выполнены без ошибок?
8 Если продукт был изменен в период тестирования, соответствующие лица проверили изменения на необходимость регрессионного тестирования?
9 ПО правильно работает с ограничениями других систем или платформ?
10 Приемочные тесты демонстрируют адекватность пользовательской документации?
11 Приемочные тесты демонстрируют адекватность обучения поставщика?
12 Приемочные тесты демонстрируют все необходимые характеристики качества?
13 Другое

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

Вопрос

Информация, предоставляемая поставщиком Запроса на Изменение
1 Уникальный идентификатор для запроса
2 Дата запроса
3 Кто внес запрос?
4 Тип запроса (например, дефект, улучшение, проблема и т.д.)
5 Запрос для какого продукта?
6 Запрос для какой версии?
7 Во время какой фазы обнаружен? (например, сборка, тестирование, внедрение, эксплуатация и т.д.)
8 Описание запроса
9 Важность для пользователя (пользовательский приоритет и уровень важности)
10 Другие
Информация, заполняемая экспертом
11 Имя эксперта
12 Дата экспертизы
13 Описание экспертизы
14 Если это дефект, наименование части жизненного цикла, в которую дефект был вставлен.
15 Если это дефект, наименование части жизненного цикла, в которой дефект был обнаружен.
16 Описание исправления
17 Время на исправление
18 Основные причины
19 Влияние изменения (описать все применяемые области)
Влияние на размер
Влияние на границы
Влияние на бюджет
Влияние на разработку
Влияние на график
Влияние на качество
Другое влияние
20 Влияние, если не будет исправлено
21 Приоритет разработки (приоритет для разработчика)
22 Рекомендуемая реализация
23 Рекомендуемое распоряжение
24 Другое
Параметры отслеживания запроса
25 Состояние запроса (например, открыт, на экспертизе, утвержден/отклонен, в процессе, завершен, закрыт и т.д.)
25 Дата утверждения/отклонения
25 Кем утвержден
25 Дата завершения
25 Дата закрытия
25 Кем закрыт
25 Другое

Структура декомпозиции работ
Предполагаемое использование списка Для команды проекта, менеджера и/или наставника для разработки или проверки структуры декомпозиции работ.
Руководства декомпозиции работ Декомпозиция работ предполагает разделение основных работ проекта на небольшие, более управляемые компоненты до тех пор, пока эти работы не будут достаточны для поддержки задач будущего проекта (планирование, исполнение, контроль и закрытие)
ID

Вопрос

1 Все работы представлены в плане?
2 Каждый рабочий элемент связан с одной задачей в плане?
3 Каждая задача имеет определенные критерии окончания?
4 Каждая задача имеет единственный связанный рабочий элемент?
5 Каждая задача требует небольшое количество людей для реализации?
6 Каждая задача настолько мала, что позволяет быстро обнаружить проблему для ее быстрого исправления?
7 Декомпозиция задач уточняется при выполнении проекта?
8 Задачи были декомпозированы корректно?
Элементы нижнего уровня необходимы и достаточны для выполнения декомпозируемого элемента? Если нет, составные элементы должны быть модифицированы (добавлены к, удалены из или пересмотрены).
Каждый элемент четко и полностью определен? Если нет, то описания должны быть модифицированы или расширены.
Возможно ли на каждый элемент надлежащим образом определены плановые сроки и бюджет? Возможно ли на каждый элемент соответствующим образом назначить специальную организационную единицу (например, отдел, группа или лицо), которая будет нести ответственность за удовлетворительное завершение этого элемента? Если нет, то необходимо внести изменения, чтобы обеспечить адекватный контроль для управления.
9 Элементы декомпозиции часто забываются
Верификация и валидация включены?
Управление проектом и администрирование включены?
Анализ обеспечения качества включен?
Управление конфигурациями включено?
Документация (руководства, процедуры) включены?
Разработка тренингов и тренинги включены?

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

Тип дефекта

Вопрос

Организация и Структура Документации
1 Стандарты Каждый компонент спецификации соответствует стандартам организации?
2 Стандарты Целевая аудитория определена?
Полнота и корректность
3 Неполный Все элементы проекта верхнего уровня включены?
4 Неполный Все предложения проектирования включены в спецификацию?
5 Некорректный Документ не имеет фактических ошибок?
6 Неполный Основные альтернативные пути и их оценки представлены? Компромиссные проекты и критерии выбора задокументированы?
7 Неполный Критерии или условия, необходимые для разработки эффективного решения, адекватно описаны? Разумны ли они?
8 Неполный Проект отражает действительную операционную среду, аппаратное и программное обеспечение?
9 Неполный Вопросы производительности затронуты?
10 Неполный Все возможные состояния и сценарии рассмотрены?
11 Неполный Требования к хранению данных определены?
12 Неполный Проект описывает обнаружение ошибок и восстановление?
13 Неполный Есть ли модель пользовательского интерфейса?
14 Неполный Есть ли модели для других интерфейсов?
15 Неполный Количество и сложность интерфейсов задокументированы?
16 Неполный Есть ли функциональная модель высокого уровня?
17 Неполный Есть ли концептуальное представление для всех составных элементов данных?
18 Неполный Управление и использование общих данных описано?
Последовательность и прозрачность
19 Неоднозначный Документ имеет неоднозначные и слова, имеющие различные варианты интерпретации?
20 Непоследовательный Документ последователен между своими компонентами?
21 Неоднозначный Границы и ограничения проекта ясны, и в документе четко указано, какие функции будут (и не будут) обеспечены и какие ожидания будут (и не будут) удовлетворены?
22 Неоднозначный Существуют ли ограничения и последствия, если таковые имеются, в этом решении ясно описано?
23 Непроверяемый Может проект быть поэтапно протестирован и интегрирован?
24 Непоследовательный Проект соответствует установленным бизнес практикам и стандартам?
Трассируемость
25 Другое — Трассируемость Проект имеет связь с требованиями?
26 Другое — Трассируемость Требования имеют связь с проектом?
Интерфейсы
27 Другое – Качество Дизайна Документ удовлетворяет потребности аудитории?
28 Другое – Качество Дизайна Проект адаптивен к будущим изменениям?
29 Другое – Качество Дизайна Проект модульный?
30 Другое – Качество Дизайна Модули имеют сильное зацепление и слабую связанность?
31 Другое – Качество Дизайна Проект отражает систему, которую просто поддерживать?
32 Другое – Качество Дизайна Есть разумные доводы того, что люди, которые разработали проект, задали правильные вопросы и действительно поняли потребности и проблемы клиентов?

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

Тип дефекта

Вопрос

Организация и Структура Документации
1 Стандарты Каждый компонент спецификации соответствует организационным стандартам?
2 Стандарты Документ прост в использовании и поддержке?
Полнота и корректность
3 Неполный Все компоненты или интерфейсы, которые необходимы для этой части архитектуры системы, выявлены и полны?
4 Неполный Каждый компонент проектной спецификации внутренне полон? Это задокументировано адекватно?
Последовательность и прозрачность
5 Непроверяемый Каждый элемент дизайна тестируемый или как-то иначе проверяемый?
6 Непроверяемый Каждый элемент может быть протестирован, продемонстрирован или проанализирован на соответствие требованиям и, следовательно, проверен?
7 Непоследовательный Детализируемые компоненты и их интерфейсы согласованы с друг с другом?
8 Непоследовательный Спецификация каждого компонента последовательна внутри?
Данные
9 Данные Все внутренние данные, которые необходимы для каждого компонента, определены?
10 Данные Все элементы данных имеют наименование и используются согласовано в проекте?
11 Данные Все внешнее использование общих данных идентифицировано?
12 Данные Все внешнее использование общих данных определено?
13 Данные Существуют какие-либо конфликтные использования данных?
14 Данные Переменные инициализируются и их значения проверяются перед использованием?
Интерфейсы
15 Интерфейс Детальный проект связан с проектом высокого уровня?

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

Тип дефекта

Вопрос

Организация и структура документации
1 Стандарты Цели документа определены?
2 Стандарты Технический уровень соответствует выбранной аудитории и целям?
3 Стандарты Формат документа последователен?
4 Стандарты Документ отвечает стандартам документации?
5 Стандарты Организация документа способствует простому поиску информации?
Полнота и корректность
6 Неполный Все фазы жизненного цикла документа были пройдены?
7 Неполный Отзывы пользователей были получены?
8 Неполный Адекватны ли условия для поставки документации и последующих изменений?
9 Неполный Все содержание документа адекватно?
10 Неполный Все важные темы присутствуют?
11 Некорректный Документация не имеет актуальных ошибок?
12 Неполный Есть ли глоссарий, если необходимо? Он полон?
13 Некорректный Определения верны?
14 Неполный Есть ли лист содержания, если необходимо?
15 Некорректный Лист содержания корректный и легкодоступен?
16 Неполный Разделы руководства включены, если необходимо?
17 Некорректный Примеры, диаграммы, рисунки и другие визуальные материалы корректны?
18 Неполный Есть ли индекс, если необходимо? Он легкодоступен?
19 Неполный Индекс адекватно детализирован
20 Некорректный Номера страниц в индексе совпадают?
21 Неполный Все ли элементы, которые могут искать различные пользователи, включены в индекс?
Последовательность и прозрачность
22 Неоднозначный Цели документа четко определены?
23 Непоследовательный В документе отсутствуют противоречия?
24 Неоднозначный Верна ли терминология? Она соответствует аудитории и целям?
25 Непоследовательный Терминология непротиворечива в документе?
26 Неоднозначный Стиль написания понятен? Отдельные параграфы отражают только одну мысль или связанные мысли?
27 Неоднозначный Примеры, диаграммы, рисунки и другие визуальные материалы понятны?
28 Непоследовательный Примеры, диаграммы, рисунки и другие визуальные материалы необходимы и относятся к тому месту, где используются?
29 Непоследовательный Индексы находятся под правильными разделами?

Формальная проверка проекта
Предполагаемое использование списка Выполняя формальную проверку проекта, рецензент может использовать эти вопросы.
ID

Вопрос

Статическая документация
1 Описание проекта (назначение, границы и цели)
2 Основные заинтересованные лица, включая спонсоров
3 Основные поставки, включая бизнес цели и выгоду
4 Архитектурные диаграммы высокого уровня, отражающие организационные и системные интерфейсы
5 Команда проекта
Промежуточная версия документации
6 Описание проекта (назначение/границы/цели)
7 Основные заинтересованные лица, включая спонсоров
8 Основные поставки, включая бизнес цели и выгоду
9 Архитектурные диаграммы высокого уровня, отражающие организационные и системные интерфейсы
10 Команда проекта
Документация по рискам
11 Основные проблемы и вопросы
12 Основные риски
13 Основные зависимости, особенно которые в ожидании или в риске
Планируемая на последующие шаги документация
14 Основные промежуточные корректировки, связанные с требованиями, кадровым обеспечением и зависимостью изменений
15 Основной план рисков (стратегия снижения и план последствий)
16 Следующие шаги
17 Запрос помощи от исполнителей, если требуется
18 Специализированная отчетность только по этому проекту (добавление любых необходимых отчетов для последующего использования)

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

Тип дефекта

Вопрос

1 Прозрачность Некоторые элементы документа сложны восприятия или весь документ сложно читать.
2 Полнота Некоторые необходимые компоненты пропущены.
3 Сложность Некоторые части документа необходимо упростить для целевой аудитории.
4 Последовательность Некоторые части документа конфликтуют с другими связанными документами.
5 Корректность Документ имеет ошибки.
6 Определение Определения пропущены, ошибочны или лишние.
7 Формат Документ не соответствует предопределенному формату организации для этого типа документа.
8 Грамматика Присутствуют грамматические ошибки в документе
9 Организация Порядок, в котором представлен документ, неудобен и неэффективен.
11 Излишество Некоторые части документа избыточны и не соответствуют целям документа.
12 Пунктуация Присутствуют несоответствия в пунктуации и выделениях в документе.
13 Стандарты Документ не соответствует стандарту документации для этого типа документа.
14 Стиль Документ в некоторых моментах не соответствует руководству организации по стилям документации.
15 Версия Нигде нет информации о версии или она не соответствует стандартам организации.

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

Вопрос

1 Результаты приемочных тестов проанализированы?
2 Поставляемые материалы соответствуют всем функциональным требованиям?
3 Поставляемые материалы соответствуют всем требованиям к продукту?
4 Готова ли документация по эксплуатации?
5 Соответствующие люди проверили и утвердили документацию (заказчик, покупатель и поставщик)?
6 Документация соответствует конечному продукту?
7 Информация о релизе описывает дефекты и методы их обхода?
8 Если существуют требования обязывающие принять продукт «как есть», соответствующие документы были оформлены и утверждены?
9 Все ли поставки, описанные в контракте, были предоставлены поставщиком?
10 Все ли поставки, описанные в контракте, были обновлены до последней версии?
11 Описаны ли процедуры обработки ошибок после поставки продукта?
12 Если предусмотрено контрактом, программное обеспечение и другие необходимые артефакты были помещены под условное хранение?
13 Если продукт будет поддерживаться поставщиком, существует ли соответствующие последующее соглашение, которое позволяет закрыть текущее соглашение?
14 Все ли нерешенные вопросы, связанные с продуктом или контрактом, были обработаны и закрыты?
15 Другое

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

Вопрос

Документ Границы Проекта на достаточном уровне описывает, что проект должен достичь и в какой среде? Следующие пункты должны быть определены:
1 Общие Границы Проекта
2 Элементы вне границ
3 Бизнес Цели/Потребности
4 Бизнес и Технические Ограничения
5 Разделы по Изменениям в Бизнес Процессе/Получение Подтверждения Изменений
6 Основные Интерфейсы/Интеграционные Требования
7 Основные Системные Возможности и Функции с указанными потенциальными релизами продукта
8 Затрагиваемые Организации и Подразделения
Альтернативы Продукта определены и рассмотрены? Компоненты могут включать:
9 Технико-экономическое обоснование
10 Оценка Альтернативных Решений (включая существующие приложения и/или компоненты)
11 Потенциальные Продукты Поставщика
12 Анализ необходимости Покупки или Разработки
Условия Развертывания были задокументированы и рассмотрены соответствующими участниками?
13 Все основные вопросы, поступившие от рецензентов, были решены?
План проекта это включает?
14 Высокоуровневую оценку по стоимости и трудозатратам для всего проекта
15 Детальную оценку стоимости трудозатрат, стоимости, плана и планируемых трудовых ресурсов для фазы Анализа
16 Предлагаемый жизненный цикл
17 Проектные роли и ответственности
18 Начальный набор проектных рисков и планы снижения
Анализ оценки рентабельности выполнен?
19 Какой приоритет у проекта по сравнению с другими проектами, которые находятся в очереди ожидающих разработку проектов?

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

Тип дефекта

Вопрос

Организация и структура документа
1 Стандарты Соответствующие стандарты документирования требований выдержаны?
2 Стандарты Все рисунки, таблицы и диаграммы подписаны и имеют ссылку?
3 Стандарты Все термины и единицы измерений определены?
4 Стандарты Все требования описаны последовательно и на соответствующем уровне детализации?
5 Стандарты Отдельные требования имеют ранг с описанием установленного приоритета?
6 Непроверяемое Требования обеспечивают адекватный базис для разработки и системного тестирования?
Полнота и корректность
7 Корректность Все ли внутренние перекрестные связи с другими требованиями корректны? (Для модифируемости минимизируйте перекрестные связи)
8 Неполное Все классы пользователей описаны? Все пользовательские характеристики описаны?
9 Неполное Спецификация включает все известные потребности заказчика или системы? Все ли задачи, которые необходимо выполнять пользователям, указаны?
10 Неполное Каждое функциональное требование описывает вход, выход и функцию, если это необходимо?
11 Неполное Все зависимости от других систем определены? Включены другие приложения или интерфейсы приложений, базы данных, связующие подсистемы, сеть и т.д.
12 Неполное Требования к документации и обучению определены?
13 Неполное Аппаратная и программная среда указана?
14 Неполное Все поставляемые требования были включены? Здесь включаются те, которые подразумевают системные и программные требования, которые в основном ограничивают разработку или верификациию.
15 Неполное Полный жизненный цикл определен, включая поддержку?
16 Неполное Какие либо ограничения разработки и реализации описаны?
17 Неполное Все требования к надежности, восстанавливаемости (непрерывности бизнеса) и производительности правильно указаны??
18 Неполное Все требования к безопасности правильно указаны?
19 Неполное Все требования к защищенности правильно указаны?
20 Неполное Все требования к конфиденциальности данных указаны?
21 Неполное Определены ли критичные ко времени/длительности функции, и критерии определения времени указаны для них?
22 Неполное Нормативные, законодательные и требования на основе стандартов были указаны?
23 Неполное Все атрибуты (характеристики) качества были правильно указаны (например, эффективность, гибкость, совместимость, возможность поддержки, мобильность, возможность многократного использования, удобство и доступность)?
24 Неполное Требования к непрерывности бизнес процесса и восстановлению после сбоев были учтены?
25 Интерфейс Требования к интерфейсам взаимодействия с пользователем были учтены? Они корректны?
26 Интерфейс Все внешние аппаратные, программные и коммуникационные интерфейсы определены? Они корректны?
Последовательность и прозрачность
27 Противоречивое Спецификация согласуется с соответствующими документами верхнего уровня?
28 Противоречивое Требования имеют дубликаты или конфликты с другими требованиями?
29 Противоречивое Все требования написаны последовательно, понятно и лаконично?
30 Неоднозначное Каждое требование имеет только одну интерпретацию? Если термины имеют несколько значений, это указано?
31 Непроверяемое Каждое требование может быть проверено через тест, демонстрацию, рецензию или анализ?
32 Непроверяемое Существуют измеряемые критерии приемки для каждого функционального или нефункционального требования?
Трассируемость
33 Интерфейс Каждое требование уникально и корректно идентифицировано?
34 Интерфейс Каждое требование имеет связь с его источником (включая производные требования)?
35 Другое Каждое требования в границах проекта?

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

Вопрос

1 Каждое требование должно включать слова должно быть или должно.
2 Каждое требование должно быть написано в кратком предложении и с использованием простых терминов.
3 Каждое предложение должно включать только одно требование.
4 Каждое требование должно четко совпадать с содержанием, приведенным в предложении.
5 Обобщающие термины (такие как все, каждый, никогда и всегда) не должны использоваться в требованиях, если требование должно быть проверяемым.
6 Неопределенные термины (такие как будет определено в дальнейшем, будет описано в дальнейшем и т.д.) не должны использоваться в требованиях, кроме случаев, когда будут выполнены согласования и утверждения для каждого такого термина.
7 Каждое требование должно быть написано в утвердительной форме.
8 Каждое требование должно быть грамматически правильным.
9 Объединение И показывает, что все элементы в требовании должны быть в значении «истина», чтоб удовлетворять назначению требования.
10 Каждое требование, которое включает объединение ИЛИ должно четко показывать где «включаемое или» или «исключаемое или». «Включаемое или» позволяет одному или обеим альтернативам быть в значении «истина», а «исключаемое или» позволяет только одной альтернативе быть в значении «истина».
11 Использование косой черты , например, и/или или проводник/земля не должны использоваться в требованиях.
12 Каждое требование должно быть в границах проекта.
13 Термины и сокращения должны быть определены в глоссарии, списке или в тексте.

Сценарии или процедуры тестирования
Предполагаемое использование списка При разработке сценариев или процедур тестирования автор может использовать этот список для оценки качества законченного продукта. Рецензент может использовать эти вопросы для оценки сценариев и процедур тестирования через формальные инспекции или другие типы рецензирования.
ID

Тип дефекта

Вопрос

Организация и стандарты
1 Стандарты Соответствующие заинтересованные лица были вовлечены в разработку и утверждение сценариев тестирования и процедур тестирования?
2 Стандарты Люди, которые разрабатывают тестовые сценарии или процедуры, имеют глубокий опыт в области приложений, технической среды и техник тестирования, чтоб быть достаточно способными для разработки адекватных тестов?
3 Стандарты Тестовые процедуры или сценарии отвечают стандартам организации?
Полнота и корректность
4 Неполный Когда выполняется оценка всего пакета тестов, сценарии или процедур тестирования охватывают все типы необходимых тестов (например, тестирование функциональности приложения, тестирование производительности, тестирование удобства использования, тестирование на нескольких платформах, он-лайн помощи, тестирование документации пользователя и т.д.)
5 Неполный В каждом тесте полностью указаны все необходимые входные параметры, альтернативные пути и ожидаемый результат?
6 Другое Отдельные тесты возможны и выполнимы?
7 Неполный Описание целей каждого теста полное?
8 Другое Описание целей каждого теста точное?
9 Неполный Ожидаемый результат для каждого шага каждого теста описан, даже если входные параметры вне требуемого диапазона?
10 Неполный Тестовые сценарии демонстрируют реакцию системы на неправильные или конфликтующие входные параметры?
11 Неполный Зависимости тестовых процедур идентифицированы?
12 Неполный Каждая процедура тестирования определяет предшествование вовлеченных тестов?
Последовательность и прозрачность
13 Другое Пользовательские инструкции подробны и понятны для выполнения каждого тестового сценария?
14 Другое Инструкции для каждого теста представляют пошаговое и упорядоченное выполнение?
15 Неоднозначный Критерии успешного выполнения или провала теста понятны и однозначны?
16 Противоречивый Глубина и основательность тестирования (т.е. процент детального покрытия, которые обеспечивает тест) для каждой возможности совпадает с операционным профилем этой возможности?
17 Противоречивый Величина функционального покрытия соответствует рискам продукта?
18 Противоречивый Процедуры тестирования совместимы с возможностями средств тестирования?
Трассируемость
19 Интерфейс Тестовые сценарии обратно связанны с требованиями?
20 Интерфейс Есть ли перекрестная связь между сценариями тестирования и тестируемыми возможностями?

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

Тип дефекта

Вопрос

Организация и стандарты
1 Стандарты Соответствующие заинтересованные лица были вовлечены в разработку и утверждение?
2 Стандарты Люди, которые разрабатывают тесты, имеют глубокий опыт в области приложений, технической среды и техник тестирования, чтоб быть достаточно способными для разработки адекватных тестов?
3 Стандарты Тестовые процедуры или сценарии отвечают стандартам организации?
Полнота и корректность
4 Неполный Границы проекта тестирования охватывают все типы тестов, которые необходимы, как указано в плане тестирования?
5 Неполный Проект тестирования включает методы определения ответа системы на неправильные и конфликтующие входные параметры?
6 Неполный Проект тестирования содержит критерии успешного выполнения или провала теста для каждой тестируемой возможности
7 Неполный Все ли поддерживаемые тестовые сценарии перечислены в спецификации проекта тестирования?
8 Неполный Каждый перечисленный тестовый сценарий имеет процедуры, определяющие его использование?
Последовательность и прозрачность
9 Противоречивый Глубина и основательность методов тестирования для каждой возможности совпадает с операционным профилем этой возможности?
10 Непонятный Критерии для теста «успешен-провален» понятны и однозначны?
11 Противоречивый Элементы, которые будут тестироваться, непротиворечивы с тестируемыми возможностями?
12 Противоречивый Величина функционального покрытия соответствует рискам продукта?
13 Противоречивый Возможности (или комбинация возможностей), которые будут тестироваться в этом проекте, совпадают с теми, которые были указаны в плане тестирования для этого теста?
14 Противоречивый Все тестовые элементы этого проекта тестирования соответствуют тем, которые идентифицированы в плане или планах тестирования?
15 Противоречивый Этот проект связывает каждую возможность (или комбинацию возможностей), которая будет тестироваться в этом проекте тестирования, с одним или более описанием требований или дизайна?
16 Противоречивый Этот проект связывает каждую возможность (или комбинацию возможностей), которая будет тестироваться в этом проекте тестирования, со всеми связанными описаниями требований или дизайна?

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

Тип дефекта

Вопрос

Организация и стандарты
1 Стандарты План тестирования соответствует шаблону плана тестирования или каким-то другим стандартам?
2 Стандарты Существуют ли перекрестные ссылки между планом тестирования и планом проекта для проекта, продукт которого будет тестироваться?
3 Стандарты Все ли заинтересованные лица вовлечены в разработку и утверждение плана тестирования?
Полнота и корректность
4 Неполный План определяет, что нужно тестировать и что не нужно тестировать?
5 Неполный План определяет критерии приемки?
6 Неполный Результирующие артефакты тестирования определены в плане?
7 Неполный Стратегия тестирования явно описана?
8 Неполный Все необходимые фазы тестирования указаны в плане тестирования?
8 Неполный План описывает ресурсы необходимые для выполнения плана?
9 Неполный Ресурсы назначены рационально по объему, доступности и уровню?
10 Неполный Риски, связанные с качеством продукта, определены в плане тестирования?
11 Неполный План содержит мероприятия по управлению рисками?
Последовательность и прозрачность
12 Противоречивый Заданные границы трассируются с требованиями к продукту?
13 Противоречивый Если некоторые возможности не тестируются или тестируются незначительно, это оправдано?
14 Противоречивый Если тест для нового релиза или обновления существующей системы, регрессионное тестирование не противоречит этой частной ситуации?
15 Противоречивый Логистика соответствует стратегии и ресурсам, определенным в плане?
16 Противоречивый Планируемый объем работ по тестированию пропорционален объему трудозатрат разработки и поддержки проекта?
Элементы, связанные с План Управления Тестированием
Полнота и корректность
17 Неполный План тестирования определяет критические факторы успешности продукта?
18 Неполный Документ явно определяет пользовательские (заказчика) критерии приемочного тестирования?
19 Неполный Общие цели тестирования явно определены?
20 Неполный План включает мероприятия по обеспечению качества для работ по тестированию?
21 Неполный План включает или ссылается на процессы управления конфигурацией?
22 Неполный План включает описание организации команды тестирования, включая структуру отчетности?
23 Неполный План явно идентифицирует какие фазы и цели тестирования должны быть выполнены?
24 Неполный Если тест для нового релиза или обновления существующей системы, опыт взаимодействия с системой и ее история предыдущих ошибок отражена в плане для тестовых сценариев?
Элементы, связанные с Детальным Планом Тестирования
Полнота и корректность
25 Неполный Задачи тестирования указаны в плане тестирования?
26 Неполный План описывает инструменты, которые должны использоваться для тестирования продукта?
27 Неполный План обучения инструментам (если необходимо) оговариваются планом?
28 Неполный Задачи по подготовке среды тестирования включены в план?
Последовательность и прозрачность
29 Противоречивый Глубина и основательность тестирования (например, процент детального покрытия, которые обеспечивает тест) совпадает с рисками продукта?
30 Неоднозначный Критерии успешного выполнения или провала теста понятны и однозначны?

План управления тестированием
Предполагаемое использование списка Для команды тестирования при оценке их программных (или системных) планов тестирования для определения или соответствующие элементы покрыты.
ID

Вопрос

1 План тестирования соответствует общему плану проекта?
2 Главные функции запланированы для тестирования на ранних стадиях цикла тестирования?
3 График тестирования явно определен?
4 Ресурсы тестирования (свободное место, оборудование и персонал) уже доступны или планируется их доступность, когда это необходимо?
5 Инструменты тестирования уже доступны или они будут доступны, когда будет необходимо?
6 Механизм хранения результатов тестирования установлен?
7 Все соответствующие фазы тестирования, роли и ответственности в плане установлены (тесты модульные, системные, альфа, беты, приемочные и т.д.)?
8 Если необходимо, указаны и запланированы тесты по миграции данных, больших объемов данных, нагрузочному и стрессовому тестированию?
9 Если необходимо, производительность будет выполняться согласно спецификации продукта?
10 Все требования тестирования, которые указаны в документе по требованиям, затронуты?
11 Критерии приемки для продукта были определены?
12 Риски для плана тестирования определены, и планы смягчения разработаны?
13 Существует ли планы реакции для рисков, которые могут осуществиться?
14 Мероприятия по управлению рисками отслеживаемы?
15 Есть ли полный список того, что не будет тестироваться?
16 Другое

Рецензирование вариантов использования
Предполагаемое использование списка Когда рассматривается вариант использования, рецензент может использовать следующие вопросы для определения или вариант использования адекватен для последующей инспекции и другого типа рецензирования.
ID

Тип дефекта

Вопрос

Организация и стандарты
1 Стандарты Вариант использования самостоятельная, дискретная задача?
2 Стандарты Вариант использования написан на необходимом уровне, а не как конкретные сценарии?
3 Стандарты Вариант использования не имеет описания разработки или реализации?
4 Стандарты Вариант использования ограничен 10 шагами или менее?
5 Стандарты Варианты использования именуются фразой в виде глагола целевого действия, что указывает на цель основного актора?
Полнота и корректность
6 Неполный Цели всех акторов затронуты?
7 Неполный Все акторы представлены (прямо или косвенно)?
8 Неполный Все ожидаемые альтернативные варианты задокументированы?
9 Неполный Все известные условия исключений задокументированы?
10 Неполный Последовательности диалога для каждого курса полны?
11 Некорректный Главный актор в каждом варианте использования подходит для выполнения этой задачи?
12 Некорректный Описанный курс в варианте использования выполним?
13 Некорректный Каждый шаг в варианте использования подходит для достижения цели варианта использования?
14 Некорректный У основного актора есть верное поведение?
Последовательность и прозрачность
15 Неоднозначный Цели или измеряемое значение варианта использования понятны?
16 Неоднозначный Понятно какой атор или акторы получают выгоду от варианта использования?
17 Неоднозначный Всевозможные общие последовательности действий были заложены в отдельные варианты использования?
18 Неоднозначный Последовательность диалога для каждого курса описана понятно и однозначно?
19 Непроверяемый Каждый курс, описанный в варианте использования, проверяем?
Реклама

Posted in Microsoft, Requirements Management Guidance, Team Foundation Server, Visual Studio | Отмечено: , , , , , , , , | 1 Comment »

Руководство по управлению требованиями VS TFS 2010

Posted by Шамрай Александр на Июль 27, 2010

Перевел очередное руководство проекта Visual Studio ALM Rangers «Visual Studio 2010 Team Foundation Server Requirements Management Guidance«, которое рассказывает о возможностях TFS 2010 для организации эффективного процесса управления требованиями. Изначально это руководство готовилось для реализации процесса на TFS 2010 Beta1, поэтому есть один момент, который будет отличаться для релизной версии TFS 2010. Этот момент заключается в использовании рабочего элемента Возможность (Feature): в TFS 2010 Beta1 это был отдельный рабочий элемент, а уже в окончательной редакции он является просто отдельным типом Возможность рабочего элемента Требование. Поэтому при реализации у себя в организации изложенных в этом руководстве практик, учтите этот момент.

Содержание руководства:

  1. Введение в Управление требованиями с использованием Team Foundation Server. Целью данного руководства является предоставление формализованного опыта Microsoft в виде рекомендованных процедур и процессов, конфигураций Visual Studio Team System и Team Foundation Server, а также развитие навыков по дисциплине Инженерия требований вашего жизненного цикла разработки ПО. Ввиду изменчивости и вопреки методик, используемых в индустрии, в этом руководстве эти задачи приведены тремя способами.
    • Общие Руководство по Разработке
    • Традиционная разработка
    • Гибкая разработка
  2. Планирование управления требованиями. План управления требованиями должен быть разработан для определения и механизмов контроля информации, которая будет собираться и использоваться для сбора метрик, отчетности и контроля изменений требований к продукту.
  3. Трассировка Требований. Трассировка, вероятно, наиболее важный аспект в инженерии требований, который обеспечивает подотчетность команды разработки. Кроме этого, она помогает:
    • Идентифицировать источник и важность требований
    • Управлять масштабом проекта
    • Управлять изменениями требований
    • Оценить воздействие на проект изменения требований или других элементов проекта
    • Оценить влияние провала тестирования требований (например, не пройденный тест может означать, что требование не выполнено)
    • Убедиться, что все требования к системе будут выполнены при реализации
    • Убедиться, что приложение делает то, для чего оно предназначено
    • Дать разработчику контекст требований для задачи
  4. Анализ и Декомпозиция. Анализ и Валидация выполняются для:
    • Установки рабочей концепции и сценариев (требования продукта – например, пользовательские цели и контекстные диаграммы; требования компонента продукта – например, технические ограничения и рабочая концепция)
    • Установки и поддержки определения необходимых функциональных возможностей (функциональная архитектура, диаграммы деятельности и сценарий использования, объектно-ориентированный анализ с идентифицированными сервисами)
    • Анализа требований (дефекность/изменчивость требований, изменения требований, технические критерии качества выполнения, оценка рисков)
    • Валидации требований со всесторонними методами (Отчет о методах анализа и результатах)
  5. Выявление требований. Этот документ описывает выявление требований на каждом из своих эволюционных уровней в рамках параметров двух различных методологий: традиционной разработки приложений и гибкой методологии. Visual Studio и Team Foundation Server обеспечивают общую технологию для двух типов методологий и служат для планирования, хранения, отслеживания и отчетности в хранилище для всех стадий выявления.
  6. Спецификация требований. Независимо от уровня иерархии при выявлении требований (бизнес, системные или реализация), существуют некоторые основные свойства Team Foundation Server 2010, которые необходимо понимать для определения требований и их проверки. Этот раздел рассказывает о документировании различных элементов требований в виде рабочих элементов и использовании других методов.
  7. Валидация требований. Валидация представляет собой процесс оценки, будет ли конечный продукт удовлетворять требованиям заказчика, и помогает удостовериться, что требования были правильно поняты. Такой подход к поставке в последнее время называют «Test-First Development» или «Requirements-Based Testing».
  8. Управление изменениями и утверждение требований. Управление изменениями требований и утверждение описывает, как участник процесса формально получает утверждение для новых требований или изменений/расширений существующих требований. Фокус в этом разделе будет сделан на описании действий процесса изменения требований, управления базовыми линиями требований и разрешения на продолжение работ по реализации требования. Также будет уделяться большое внимание к соблюдению промышленных стандартов таких, как CMMI и ITIL, соответствие отраслевым нормам такие, как FDA CFR-21, Часть 11 и закону Сарбейнса-Оксли.
  9. Анализ влияния. Анализ влияния выполняется для:
    • Оценки в рамках задач, которые обеспечивают соответствие изменений всем техническим и проектным требованиям
    • Оценки влияния изменений за пределами непосредственного проекта или контракта требований (изменения в элементах, использующихся в нескольких продуктах, может решить текущую проблему, но вызывать проблему в других приложениях)
    • Определение влияния, которое изменения будут иметь для рабочих продуктов, связанных рабочих продуктов, рабочих графиков и стоимости проекта
  10. Дополнительные интеграции. Различные производители программного обеспечения и партнеры Microsoft разработали интеграции с Visual Studio, которые предоставляют возможности не очень хорошо реализованные в Visual Studio Team Suite. В частности, они имеют встроенные возможности в следующих областях: выявление, спецификации, валидации и управления изменениями. Тут список некоторых из наиболее тесно интегрированных решений.
  11. Контрольные списки для разработки требований. Контрольные списки, которые помогают улучшить качество разрабатываемых требований.

Дополнительная информация:

  • Visual Studio TFS Branching Guide 2010 – руководство по ветвлению для Team Foundation Server 2010 разработанное сообществом VSTS Rangers. Это руководство основано на практике использования для Team Foundation Server различных моделей ветвления и слияния.
  • TFS 2008 Branching Guide 2.0 – руководство по ветвлению для Team Foundation Server 2008 разработанное сообществом VSTS Rangers. Это руководство основано на практике использования для Team Foundation Server различных моделей ветвления и слияния.

Posted in Microsoft, Requirements Management Guidance, Team Foundation Server, Visual Studio | Отмечено: , , , , , , , , , | 2 комментария »

Руководство по управлению требованиями VS TFS 2010 – Введение в Управление требованиями с использованием Team Foundation Server

Posted by Шамрай Александр на Июль 13, 2010

<<Содержание

Добро пожаловать в Руководство по управлению требованиями Team Foundation Server! На TechReady7 (внутренние технические встречи Microsoft) в июле 2008 года, практики проголосовали за проекты Visual Studio ALM Rangers, в которых, по их мнению, они больше всего нуждаются. Разработка требований была признана одним из двух самых важных. В этом документе будут рассмотрены люди, процессы и руководство по технологиям для Разработки требований с использованием Team Foundation Server.

Целью данного руководства является предоставление формализованного опыта Microsoft в виде рекомендованных процедур и процессов, конфигураций Visual Studio Team System и Team Foundation Server, а также развитие навыков по дисциплине Инженерия требований вашего жизненного цикла разработки ПО. Ввиду изменчивости и вопреки методик, используемых в индустрии, в этом руководстве эти задачи приведены тремя способами.

  • Общие Руководство по Разработке Требований – есть практики инженерии требований, которые реализуются, независимо от используемой методологии. Например, общее развитие представления бизнес уровня к функциональным возможностям, качеству обслуживания определено в любом случае, выполняет разработку организация по традиционному водопаду в соответствии со стандартами института инженеров по электротехнике и радиоэлектронике (IEEE) или выполняется экстремальное программирование с гибкими методами. Руководство приведено на концептуальном уровне, по возможности с использованием конкретных примеров на Visual Studio/Team Foundation Server.
  • Традиционная разработка – руководство будет приведено в основном в соответствии со стандартами IEEE по инженерии требований. В руководстве будут описаны конкретные указания по выявлению бизнес требований, спецификации, а также валидации спецификаций функциональных и технических требований.
  • Гибкая разработка – даже в рамках гибких методов есть несколько методологий, которые подчеркивают или выделяют различные практики в рамках этой темы. Руководство сосредоточено в основном на Scrum в качестве выбранной методологии и ссылается при необходимости на другие методологии.

Сценарий Разработки Требований

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

  • Бизнес-требования и их приемо-сдаточные испытания;
  • Функциональные требования и их тестовые сценарий;
  • Технические требования и их нефункциональные ограничения, качество обслуживания;
  • Разработка спецификации и их тесты компонентов архитектуры приложения;
  • Исходный код и его модульные тесты;
  • Документация пользователя.

Это руководство описывает этот список более подробно в разделах по планированию управления требованиями и трассировки. Сейчас мы используем этот список как основу для описания сценария инженерии требований. Этот сценарий начинается с выявления требований уровня бизнеса вплоть до выполнения тестов по сборкам. Далее будут показаны цели каждого этапа этого процесса и как Team Foundation Server может быть использован для этих шагов.

Этот сценарий будет служить основой для описания на протяжении всего этого руководства, и мы будем на него ссылаться при описании альтернатив на основе Общей, Традиционной и Agile практик, используемых в Microsoft и в индустрии в целом. В каждом шаге сценариев, описанных ниже, указано в какой части руководство можно найти более детальную информацию о его поддержке в Visual Studio Team System и Team Foundation Server.

  1. Анализ Проблемы и Целей и определение Видения – бизнес-руководители спонсируют проект для решения некоторых бизнес-проблем и достижения бизнес-цели. Бизнес-аналитик будет выявлять их в качестве требований к продукту в виде набора возможностей или бизнес-требований. Мы можем хранить их в Team Foundation Server в виде рабочего элемента «Возможность».
    1. Первоначально выявление будет направлено на бизнес-руководителей. После того, как возможности продукта будут выявлены, специалисты по бизнес-областям будут дополнять этот набор функций. (Разделы Планирование управления требованиями и Выявление)
    2. Валидация на этом уровне будет проверять не только точность описанных функции, но и определять их влияние на решение проблем бизнеса и достижения бизнес-целей. (Раздел Валидация требований)
    3. Проблемы и цели, как правило, хранятся в виде документа бизнес-сценарий, где, в нормальной ИТ организации спонсируемой CIO, менеджер проекта собирает предварительную смету расходов на решение этой проблемы в проекте разработки и выполняет анализ экономических выгод. Этот вид деятельности находится вне области инженерии требований этого руководства. Анализа экономического обоснования и дальнейшего выявление спонсоров и экспертов в этой области приводит к бизнес-требованиям или возможностям продукта, которые будут определены в документах по проекту; обычно в документе Спецификация бизнес требований. (Разделы Планирование управления требованиями и Спецификация требований)
  2. Переход к функциям – выполняя анализ возможностей, аналитик получает функциональную контекстную модель или диаграмму вариантов использования для всех функциональных сценариев, реализующих функции. Мы можем хранить их в качестве рабочего элемента «Пользовательское описание функциональности» (MSF для Agile) или «Требование» с типом «Функциональное» (MSF для CMMI) и связать их с каждой возможностью, которую они реализуют.
    1. Планирование требований – описано в разделе Планирование управления требованиями
    2. Аналитик анализирует возможности и готовится к выявлению функциональных требований пользователей заинтересованных сторон и бизнес экспертов по конкретным областям. Их анализ поможет им выявить правильные функциональные требования, задокументировать и выполнить их валидацию на точность. (Разделы Выявление, Анализ и Валидация требований)
    3. Полученные функциональные требования и возможности связываются – описано в разделе Трассировка требований
  3. Переход к качеству обслуживания и нефункциональным требованиям – проводится дальнейший анализ возможностей и функциональных требований. Аналитик, работая с другими составляющими продукта (инфраструктура, операции, архитектура и администраторы баз данных, удобство использования, эксперты по безопасности, управление и обеспечение соблюдения требований и т.д.), определяет нефункциональные требования и качества обслуживания. Опять же, мы можем хранить их в качестве рабочих элементов в Team Foundation Server и привязать их к каждой возможности или функции, из которых они получены.
    1. Анализ функциональных требований для получения качества обслуживания и нефункциональные требований – разделы Выявление, Анализ и Спецификация требований
    2. Валидация свойств и нефункциональных требований на точность (Раздел Валидация требований)
    3. Полученные требования и функциональные требования связываются – описано в разделе Трассировка требований
  4. Планирование работ – менеджер проекта определяет с командой разработчиков задачи разработки (будь то гибкий проект или водопад или что-нибудь между ними, задачи определяются и по-прежнему с оценкой трудозатрат определенным образом) на функциональные и нефункциональные требования. Их можно хранить как рабочие элементы «Задача» и связывать с функциональными или нефункциональным требованиям, для которых они были запланированы.
    1. Планирование разработки и тестирования – описано в разделе Анализ
  5. Разработка Приложения и Тестов — команда разработчиков может разрабатывать код проекта приложения и модульные тесты (и тесты производительности) и связать их с исходным кодом. Во время регистрации (check-in) изменений, они связывают их с задачей, и мы можем даже заставить их это делать.
    1. Наборы изменений (Change Sets) связываются с задачами и требованиями – описано в разделе Трассировка требований
  6. Проверка качества приложения — Мы выполняем модульные тесты, и мы с помощью отчета, который связан со сборкой, можем продемонстрировать, какие наборы изменений вошли в эту сборку и какие рабочие элементы были связаны с этими зарегистрированными наборами изменений. И мы можем это сделать с помощью Team Foundation Server. Мы выполняем Ручные или Web функциональные тесты, а также можно использовать общие тесты, которые доступны из внешних систем функционального тестирования (например, Quick Test Professional) и опубликовать результаты. Отчеты будут демонстрировать, что рабочие элементы покрыты всеми видами тестов, с использованием Team Foundation Server Data warehouse.
    1. Выполнить тесты, публиковать результаты, сгенерировать отчеты покрытия – описано в разделе Трассировка требований
  7. Планирование тестирования – почему планирование тестирования включено в темы инжиниринга требования? Что ж, планирование тестирования гарантирует, что валидация имеет место. Влидация предусматривает проверку, которая позволяет убедиться, что команда проекта понимает цели требований и может достичь согласования с источником требования (бизнес-спонсором или заинтересованным лицом). Проверка предусматривает тесты, которые команда предоставила и согласовала для поставки. Планирование тестирования обеспечивает хранилище и трассируемость всех работ, связанных с управлением тестирования. Таким образом, после шага (1), но до шага (2), мы теперь имеем надежный механизм для планирования приемо-сдаточных тестов для функциональных требований. На самом деле, планирование тестирования на каждом уровне может быть выполнено с помощью Visual Studio 2010 Test and Lab Manager edition. Таким образом, мы можем создать несколько тестовых планов и тестовых наборов в Test and Lab Manager, которые обеспечивают разработку устойчивого отчета плана тестирования, который показывает, какие тесты не были запланированы, какие были запланированы, но не реализованы, какие были реализованы, но не выполняются, какие были выполнены, но провалены и какие были выполнены и прошли. Все эти данные есть, а у нас теперь есть возможность получить такой отчет и сортировать результаты по рабочим элементам, к которым они принадлежат.
    1. Планирование тестирования для системных требований — описано в разделах Трассировка требований, Валидация требований и Спецификация требований

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

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

Отступление

В 20-тилетней карьере лидера в области разработки, практик, внедрения передового опыта, обучения, коучинга по управлению жизненным циклом разработки для своих клиентов, мы установили, что Инженерия требования, как правило, наиболее сложная дисциплина в рамках программного обеспечения и сообществ разработки систем. Таким образом, это руководство было разработано с подходом, который напрашивается на критику и изменение. Команда из более 20 практиков из Microsoft Consulting Services, Product Management и программы MVP собрались вместе для обсуждения и определения предложения руководства, которое учитывает передовые практики индустрии и лучшие практики Microsoft в дисциплине разработки требований.

Visual Studio ALM Rangers

Эта руководство было разработано в проекте Visual Studio ALM Ranger. Visual Studio ALM Rangers особая группа в составе представителей Visual Studio Product group и Microsoft Services. Их миссия заключается в предоставлении решений для отсутствующих возможностей или руководств.

Целевая аудитория этого руководства это Microsoft пользователи Team Foundation Server «уровня 200-300». Целевая группа рассматривается как промежуточная к опытным пользователям Team Foundation Server, глубоко понимающим возможности продукта в реальном мире. Части этого руководства могут быть полезными для новичков и экспертов Team Foundation Server, но пользователи этих уровней не фокусируются во внимание этого руководства.

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

Мы надеемся, что данное руководство охватывает более 80% нужд сегмента инженерии требований. В дополнение к этому руководство вы найдете отдельные методологические сценарии, Q&A, учебные пособия и обновление трассировки и документацию по стратегии. Мы призываем участников нашего сообщества предоставлять идеи для новых сценариев, которые мы будем добавлять в пакеты. Эти новые пакеты будут доступны на CodePlex или MSDN и будут обновлены на основе отзывов пользователей.

Словарь

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

Термин Определение
Анализ требований

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

Активный дизайн (Participatory Design)

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

Аппаратное требование

Требование, которым должно соответствовать аппаратное обеспечение.

Артефакт (рабочий продукт)

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

Атрибуты

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

Базовая линия

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

Базовая линия требований

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

Бизнес-правила

Правила и ограничения, регулирующие отдельные бизнес-процессы и работы.

Валидация требований

Валидация фокусирует внимание на определении, работает ли продукт как ожидалось. Валидация требований предусматривает проверку связи между тестами (и результаты тестов) и тестируемой системой. Удовлетворяет ли построенная система требованиям?

Вариант использования

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

Взаимодействие

Атрибут: возможность взаимодействия одной программной системы с другой.

Гибкость

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

Группа контроля за изменениями

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

Группа пользователей

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

Двунаправленная трассировка

Ассоциации между двумя или более логических объектов, которая видна в любом направлении (т. е. в и от сущности). (См. также Трассировка требований).

Дефектное требование

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

Диаграммы взаимодействия

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

Доступность

Степень, в которой система функционирует и доступна, когда она требуется для использования.

Жизненный цикл разработки программного обеспечения

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

Заинтересованное лицо

Лицо, которое будет затронуто продуктом и имеет прямое или косвенное влияние на требования к продукту.

Интервью

Сессия один на один с пользователем на его рабочем месте.

Контекстно-независимые вопросы

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

Коробочное решение

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

Корректность

Атрибут: соответствие стандартам и техническим условиям.

Круг пользователей

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

Мета-вопрос

Вопрос о вопросах. Обычно используется в интервью, чтобы определить или собеседник понимает цель собеседования. Пример мета-вопроса: Мои вопросы актуальны? Понятны ли Вам мои вопросы? Ваши ответы официальны?

Моделирование требований

Работы, направленные на превращение набора требований в графическое и/или текстовое представление модели системы, как она будет работать, если требования были выполнены.

Надежность

Атрибут: работа без сбоев в течение определенного периода времени.

Нетехнические ограничения

Требования, связанные с продуктом, поставкой и выпуском (например, стоимость и сроки).

Однозначное требование

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

Повторное использование

Атрибут: возможность переработки для использования в другом приложении.

Покупатель

Тот, кто приобретает продукт для пользователей.

Пользователь

Тот, кто будет использовать продукт.

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

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

Портативность

Атрибут: возможность перемещения для использования в другой среде.

Представитель пользователей

Один человек, который представляет пользователей для разработчиков продукта.

Приемочные тесты

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

Приоритетность требований

Метод ранжирования важности требований на более и менее важные.

Проверяемое требование

Это требование, которое может быть проверено с помощью анализа, демонстрации, инспекции или тестирования.

Прототип

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

Разработка программного продукта

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

Разработка требований

Дисциплинированные применения принципов, методов и инструментов для описания предлагаемого поведения системы и ограничения по всему жизненному циклу продукта/проекта.

Раскадровка

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

Сбор требований

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

Сессия совместного дизайна приложения (Joint Application Design (JAD))

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

Сценарий

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

Системные требования

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

Спецификация требований

Документация, определяющая, как продукт будет построен, и описывающая ее внешнее поведение.

Спонсор

Лицо, которое выполняет финансирование этого проекта.

Тестируемость

Атрибут: возможность проверить (протестировать) указанную операцию и производительность.

Тестируемое требование

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

Техника Фокус-группы

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

Технические ограничения

Характеристики среды продукта, которые влияют на выполнение и/или дизайн продукта.

Техническая рецензия

Рассмотрение экспертами по конкретным вопросам правильности технического содержания артефакта, находящего на рецензии.

Техническое требование

Свойства продукта для условий, в которых разрабатывается продукт.

Трассировка требования

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

Трассируемое требование

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

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

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

Требование к системным интерфейсам

Требование, описывающее передачу данных, обработку, питание или другие интерфейсы между подсистемами.

Удобство использования

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

Управление изменениями

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

Управление требованиями

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

Функциональное требование

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

Целостность

Атрибут: (использование) безотказная работа при несанкционированном доступе; (данные) сохранение содержания и порядка данных и артефактов.

Эффективность

Атрибутов: относительное использование ресурсов (памяти, времени, пропускной способности сети).

Эксплуатационная надежность

Атрибут: простота обнаружения и исправления неисправности в период времени (во время использования).

Unified Modeling Language (UML)

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

<<Содержание

Posted in Microsoft, Requirements Management Guidance, Team Foundation Server, Visual Studio | Отмечено: , , , , , , , , , | Leave a Comment »

Руководство по управлению требованиями VS TFS 2010 – Выявление требований

Posted by Шамрай Александр на Июль 2, 2010

<<Содержание

В 1992 году было опубликовано следующее высказывание, на 17 лет раньше, чем Visual Studio ALM Ranger начали разрабатывать руководство по инжинирингу требований:

1«Многие из проблем в создании и поддержке системы можно связать с проблемами выявления. Тем не менее, большая часть исследований, проводимых по инженерии требований, игнорируют выявление, руководитель Лейте (автор) заявил, ссылаясь на обследование анализа требований в 1987, что состояние дел в области анализа требований не сильно отличается от того, что было в конце 1970-х. Он утверждает, что исследования в этой области сконцентрированы на точность, представление, методы моделирования, верификации и утверждения, а не на улучшение выявления потребностей. Он приходит к выводу, что ‘усилия исследований должны быть направлены на методы и инструменты, необходимые для улучшения процесса анализа требований, и, в частности, на те, которые оказывают большую поддержку выявлению требований'».

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

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

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

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

Общие темы выявления

Планирование выявления

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

Планирование выявления обеспечивается 3-мя основными уровнями: ранний сбор информации, представление требований и анализ, валидация.

Сбор информации включает в себя определение всех соответствующих сторон и сбора инициирующих требований («списков пожеланий») от них. Через приоритеты, основанные на политических, экономических, окружающей среды и т.д. факторах, эти требования передаются на следующую итерацию выявления требований.

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

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

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

  • Выявление всех соответствующих сторон, которые являются источниками требований.
    Эта и следующая работа направлены на определение «Персонажей» приложения. Один из ключевых элементов Microsoft Solution Framework (MSF). Участник может быть конечным пользователем, интерфейсом системы или фактором среды. Несмотря на то, какие роли определены в любой нетипичной организации, ниже приведен типовой список возможных ролей:
    • Бизнес – человек или люди, обеспечивающие финансирование проекта
    • Пользователь – человек или люди, которые в конечном итоге будут использовать систему
    • Администратор – тоже, что и  пользователь, но особенность в том, что он обеспечивает безопасность, потоки данных, а также новых пользователей, продукты, цены и другую информацию в приложениях.
    • Инфраструктура – IT организация, которая обеспечивает оборудование и информационную поддержку на площадке, где приложение будет установлено. С точки зрения независимых поставщиков или сайта хостинговой компании, например SalesForce.Com, это люди, которые должны определить производительность оборудования и требования к пропускной способности для поддержки конечных пользователей, которые будут использовать приложения, размещенные на сайтах SalesForce.Com.
    • Операционная поддержка — люди или группа, которые будут оказывать операционную поддержку конечных пользователей. Они поддерживают аппаратное и программное обеспечение в рабочем состоянии в течение всего периода использования. Они также представляют службу поддержки пользователей, которые периодически сталкиваются с дефектами или отключениями.
  • Определение профиля соответствующих сторон, для которых требования будут собираться.
    Это включает в себя определение трудозатрат, необходимых для работы с ними, чтобы получить требования и риски для этих требований точно и однозначно. Например, типичный конечный пользователь в страховой организации будет описывать свои потребности в рамках непосредственно своего рабочего места. Снимки экрана для них предоставляются на бумаге и, когда они готовы (в редких случаях пользователь беспокоится, как это происходит), только тогда они могут подтвердить, что это было сделано правильно. Если сравнить с Директором информационной службы, который дает бюджет для проекта разработки приложения, предназначенного для повышения эффективности процессов страховых выплат, то их потребности описываются низкой стоимостью реализации, повышения производительности труда в денежном выражении и экономии времени, а также в утверждениях, которые приводят к увеличению прибыли.
  • Определение методов выявления (следующий раздел).
    Соответствующая техника выявления для каждого профиля будет зависеть от рабочего графика, ограничения времени, ограничения глубины знаний, возможной точности и других факторов. Использование этих факторов позволит выделить задачи с оценкой трудозатрат по выявлению требований для каждого источника.

Чтобы планировать эти три этапа, можно использовать электронную таблицу или план работ MS Project и синхронизировать с рабочим элементом TFS Задача. Следующие шаги демонстрируют, как сделать это с помощью MS Project:

  • Откройте MS Project и установите правильные атрибуты соответствия, выбрав TFS Team Project из пункта меню «Team»:

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

  • Далее введите задачи выявления с оценками, основанными на анализе каждого человека, который представляет собой персонаж для вашего приложения:

  • Чтобы опубликовать, обязательно нужно включить и указать в колонке выбора Тип рабочего элемента. После завершения опубликуйте задачи в TFS. Убедитесь, что атрибуты отображаются также, как на снимке экрана ниже:

  • Вот как это выглядит в TFS после публикации:

Методы выявления

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

Семинары по выявлению

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

Семинары по требованиям не нуждаются в поддержке Visual Studio/TFS, но их результаты могут покрываться этой технологией.

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

Другие примеры внешних источников для требований:

  • Постановка работы
  • Запрос на предложение
  • Миссия
  • Постановка задачи
  • Бизнес-правила
  • Законы и нормативные акты
  • Юридические системы
  • Бизнес-модели

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

Семинар по требованиям является одним из наиболее эффективных экономически и по времени средств в смысле получения обратной связи. Такая же концепция применяется в сессиях JAD (Joint Application Development) или RAD (Rapid Application Development) . Вот некоторые из преимуществ семинара:

  • Ускорение процесса выявления
  • Сбор всех заинтересованных сторон на интенсивную, сосредоточенную встречу
  • Содействие обеспечению направленности и прогресса
  • Все мнения будут выслушаны
  • Результаты доступны немедленно
  • Обеспечение основы для применения других методов выявления
Механизм семинара

Как правило, для крупных проектов семинар может длиться от 3-х до 5-ти рабочих дней. Ниже показан высокий уровень выполнения семинара по требованиям.

  • Предварительное планирование семинара – перед семинаром бизнес-аналитик должен будет подготовить все материалы, выявить все заинтересованные стороны, послать приглашение участникам, подготовить темы для повестки дня,  правила и направление действий для семинара. Вот перечень мероприятий, которые должны быть выполнены:
    • Предложение семинара – некоторые заинтересованные стороны не хотят идти на семинар по различным причинам. Нужно подготовить пункты с выгодами для каждой из заинтересованных сторон, которые учитывают их потребности.
    • Создание команды – выявление всех заинтересованных сторон и посредников. Подготовка окон в их расписании для семинара.
    • Определение логистики – зарезервировать конференц-залы и комнаты для перерывов. Планирование заказов блюд, напитков и легких закусок. Убедитесь, что доступны Интернет, проекторы, доски, стикеры, маркеры и т.д.
    • Отправка материалов предварительного чтения и предпосылочных материалов – заинтересованные стороны должны иметь всю имеющуюся информацию, а также время для её рассмотрения. Отправьте их с четкой инструкцией о том, как подготовиться к семинару.
    • Подготовка повестки дня – используйте расписание (обычно с шагом в полдня, разделенным на 2-а перерыва по 15 минут в течение каждой сессии), сформируйте повестку дня для каждого из семинаров. Например, в результате оценки ALM, мы создали семинар, состоящий из:
      • Введение -> Понедельник: 8:00-12:00 – Введение для всех заинтересованных сторон, их ролей, а также открытое обсуждение желаемых целей семинара.
      • Сессия 1 – Дисциплина инженерии требований -> Понедельник: 1:00-5:00 – 30 минут введение в проблемы инженерии требований, выявленных в ходе оценки, 1 час дискуссии с использованием причинно-следственных диаграмм, 15-30 минут присвоение приоритетов проблемам, 1 час мозговой штурм по решению, 15-30 минут выставление приоритетов и сведение результатов.
      • Сессия 2 – Дисциплина управления изменениями и конфигурациями -> Вторник: 8:00-12:00 – тот же формат, что и для сессии 1
      • Сессия 3 – Управление и мониторинг Agile-проекта и Дисциплина контроля -> Вторник: 1:00-5:00 – Формат скорее как обсуждение «Моделирование вариантов использования». Описать все сценарии команды Agile, определить роли, определить действия, определить рабочие продукты; больше описание процесса, которому будут следовать, и мозговой штурм на проблемных областях
      • Сессия 4 – Дисциплина повторного использования Программного обеспечения / Архитектура -> Среда: 8:00-12:00, так же как сессия 1
      • Закрытие -> Среда: 1:00-3:00 – Подведение итогов каждой сессии, определение предстоящей работы и описание последующих действий.
  • Сессии семинаров – выполнение семинара, согласно некоторым из основ:
    • Содействие – вы или кто-то вами определенный поддерживает темп сессий. Этот человек не будет вводить свое мнение, но будет привносить предложения, если сессия становится нудной, чтобы вернуть ее в нужное русло.
    • Поддержание темпа – также, как предыдущий пункт.
    • Запись выводов – организатору может быть сложно документировать результаты каждой сессии. Рассмотрите вопрос о найме специального человека (писателя) для этой цели. Очень важно, чтоб все понимали, что информация должна быть учтена и документирована. Это не простая задача.
    • Краткие выводы – в конце каждой сессии, работа с заинтересованными сторонами с целью обобщения каких-либо выводов или решений, которые были сделаны. Убедитесь, что все участники сессии поняли все варианты, которые были представлены, и все необходимые действия были предприняты в отношении результатов.
  • Выпуск результатов – найдите время для подведения итогов, их анализа и организации.
    • Обобщить выводы – организуйте результаты в формате, который можно проанализировать.
    • Объединить информацию – после проведения анализа, консолидируйте информацию таким образом, чтоб она могла быть представлена заинтересованным сторонам для последующих действий.
  • Передача
    • Представить результаты для заказчика
    • Определить следующие шаги и действия для реализации окончательного набора требований.

Мозговой штурм

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

«Мозговой штурм означает проведение с группой короткого промежутка времени, скажем, 15 минут, когда всем в комнате разрешено говорить все, что они считают важным для проекта. После этого организатор переключает группу на организацию и выставление приоритетов для результатов» 3.

Техника мозгового штурма

  • Начните с четкой установки цели мозгового штурма.
  • Сгенерируйте такое количество идей, насколько это возможно.
  • Не ограничивайте ваше воображение.
  • Не допускайте критики или обсуждения на время сбора информации.
  • После сбора информации комбинируйте и объединяйте идеи.

Для генерации идей есть несколько полезных для использования методов:

  • Стикеры и маркеры — каждый участник получает маркер и комплект стикеров. Они могут свободно записать такое количество идей, насколько это возможно для них, и прикрепить их к стенке. Роль организатора состоит в том, чтобы прочитать каждую заметку и объединить их как можно лучше по тематическим областям. После истечения срока, скажем, 15 минут, остановите сбор идей и затем попросите остальных участников помочь в распределении стикеров на стене. Это самый быстрый способ получить собранную и организованную информацию.
  • Белая доска или мольберт — либо каждый участник поднимает руку, и организатор записывает их идеи на мольберт или доску, либо каждый участник получает маркер, и они  по очереди пишут на доске до окончания срока. Этим методом сложно организовать информацию после выполнения сбора.

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

Другие методы уменьшения количества найденных идей:

  • Дайте каждому возможность проголосовать.
  • Пусть каждый определит приоритеты каждой идеи по категориям (например, критическая, важно и неплохо, если будет), которые имеют свой вес (например, 3, 2, 1). Суммы из приоритетов для каждой идеи скажут вам её важность по отношению к другим.
  • Дайте каждому участнику 100$ для голосования (нереальных денег), и пусть они покупают свои идеи за необходимую, по их мнению, стоимость. Это позволит не только выявить наиболее популярные идеи, но и определит приоритеты для всех идеи, которые были сгенерированы.

Документация по результатам

Независимо от метода, используемого для генерации идей, его результаты должны быть документально зафиксированы и сохранены. TFS можно использовать в качестве предварительного хранилища для этих идей в рабочих элементах типов «Возможность», «Пользовательское описание функциональности» или «Требование», в зависимости от используемых шаблонов процесса; MSF для Agile или MSF для CMMI.

Организатор добавляет рабочий элемент для каждого утвержденного «стикера» и указывает для него атрибуты, такие, как вес (значение в долларах или важность высокая, средняя или низкая). Эти возможности могут быть отправной точкой для дальнейших методов анализа и выявления.

Интервью

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

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

Контекстно-свободные вопросы:

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

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

Общий процесс для проведения интервью:

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

Во время интервью используйте «активное слушание». Практика активного слушания – когда один «Пытается понять, а не быть понятым». Для этого случая некоторые рекомендации:

  1. Задайте вопрос
  2. Прослушайте ответ
  3. Повторите ответ, чтобы удостовериться, что вы услышали правильно
  4. Повторите ответ своими словами, чтобы показать, что вы поняли, что вы слышали.

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

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

Не готовьте вопросник, который имеет столько вопросов, что будет трудно наладить контакт. Если вы хорошо работаете с интервью, у вас будет хорошее понимание предметной области и её проблем. После этого можно задокументировать результаты в шаблон, который может быть использован для формирования требований в качестве рабочих элементов в TFS.

Примеры контекстно-свободных вопросов используемых для поиска пользователей и интерфейсов системы:

  • Кто является заказчиком?
  • Кто является пользователем?
  • Они имеют различные потребности?
  • Каковы их особенности, возможности, условия работы?

Примеры контекстно-свободные вопросы, которые помогут вам понять бизнес-процессы:

  • В чем заключается проблема?
  • Что является основанием для желающих решения этой проблемы?
  • Существуют ли другие причины для стремления решить эту проблему?
  • Какая польза успешного решения?
  • Как можно решить проблему?
  • Какой компромисс между временем и пользой?
  • Как еще можно обеспечить решение этой проблемы?

Примеры контекстно-свободных вопросов, которые помогут вам понять требования к системе или разрабатываемому продукту:

  • Какую проблему решает этот продукт?
  • Какие бизнес-задачи может создать этот продукт?
  • Какие опасности могут существовать для пользователей?
  • В какой среде продукт будет работать?
  • Каковы ваши ожидания по удобству использования?
  • Каковы ваши ожидания по надежности?
  • Какая производительность/точность требуется?

Примеры контекстно-свободных мета-вопросов:

  • Я задаю слишком много вопросов?
  • Мои вопросы представляются актуальными?
  • Вы тот человек, который может ответить на эти вопросы?
  • Ваши ответы требования?
  • Могу ли я задать дополнительные вопросы позже?
  • Вы бы хотели принять участие в обзоре требования?
  • Есть ли что-нибудь еще, о чем я должен спросить вас?

Пример не контекстно-свободных вопросов, которых следует избегать:

  • Наводящие вопросы: «Вы хотите большой экран, не так ли?»
  • Вопросы с ответом: «Если будет 50 пунктов, так будет нормально?
  • Контрольные высказывания: «Можем ли мы вернуться к моим вопросам?»
  • Слишком длинные и слишком сложные: «Этот вопрос из трех частей …»

При разработке комплекса вопросов вам также необходимо учитывать следующее:

  • Не просить людей описать вещи, которые они обычно не описывают.
  • Не задавайте вопросы предполагающие, что пользователи могут описать различные комплексные задачи. Пример: методы завязывания ваших шнурков.
  • В целом, люди могут делать многие вещи, которые они не могут описать.
  • Эмпирические данные – плохое соотношение.
  • Спрашивайте открытые вопросы.
  • Избегайте вопросов, которые начинаются с «почему?», поскольку такие вопросы могут вызвать оборонительную реакцию.

При проведении сессии интервью помните:

  • Не ждите простых ответов.
  • Не торопите собеседника.
  • Слушайте, слушайте, слушайте!

Документация по результатам собеседования

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

Диаграммы причинно-следственных связей (Fishbone Diagrams)

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

Схема диаграммы причинно-следственных связей может быть описана так же, как кости рыб, после того, как мясо было съедено. «Голова» и «позвоночник» рыбы представляют собой описание исходной задачи. Каждая «кость» от основы является причиной или главной причиной этой проблемы. Первоначальный набор «хребта» затем анализируется на важность и актуальность этой проблемы. Главные 20% из причин потом анализируются по своим собственным диаграммам «рыбным скелетам» пока проблемы не будет достаточно проанализированы.

Это хорошая техника, потому что она вовлекает заинтересованных сторон в определение их собственных причин их проблем.

Разработка раскадровки, каркасов и прототипов

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

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

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

Как документировать раскадровку

Раскадровка может быть низко-технологичной в виде текста и рисунков или может быть анимированной и довольно сложной в виде прототипа с использованием HTML страниц в виде каркаса.

Вот несколько примеров:

  • Бумага эскизы или рисунки
  • Растровые инструменты рисования
  • Индекс карты
  • PowerPoint слайды
  • Скриншоты (если пользовательский интерфейс или прототип пользовательского интерфейса существует)

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

Несколько слов о каркасах и прототипах

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

Примеры возможных форматов:

  • Проект Expression Blend SketchFlow
  • Горизонтальные прототипы, написанные с использованием решений Web,WPF и Windows Forms
  • PowerPoint слайды с дополнительной анимацией или логикой навигации

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

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

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

Переход от раскадровки к рабочим элементам

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

Рисунок 1. Соответствие частей раскадровки рабочим элементам

Более комплексный способ объединения прототипов и рабочих элементов является документирование сценариев использования в Visual Studio Architect Edition и создание прототипов с использованием Expression Blend SketchFlow. Диаграммы вариантов использования содержат визуальное описание того, как пользователи взаимодействуют с программным обеспечением, а также могут включать ссылки на другие артефакты внутри вашего решения Visual Studio. Эти так называемые элементы Артефакты могут использоваться для подключения информации к диаграмме, например, для справки. Это то, где SketchFlow начинает действовать.

SketchFlow, который входит в состав Expression Blend 3, представляет собой инструмент для создания экранных прототипов для приложений WPF и Silverlight. Решения, созданные с SketchFlow, могут быть открыты и отредактированы в Visual Studio и наоборот. На рисунке 2 показано решение Visual Studio, которое содержит проект модели с диаграммой варианта использования и проект SketchFlow под названием «UsecasesTestScreens». Последний был создан раньше в Expression Blend SketchFlow.

Рисунок 2. Проекты SketchFlow могут быть импортированы в Visual Studio

После открытия проекта SketchFlow в Visual Studio и создания диаграмм вариантов использования в решении, можно просто перетащить экраны, выполненные в SketchFlow, в диаграммы вариантов использования. Файлы, перемещенные в диаграмму, будут автоматически преобразованы в элемент артефакт и использоваться, как и любой другой элемент внутри диаграммы варианта использования (см. Рисунок 3).

Рисунок 3. Перемещение экрана пользовательского интерфейса на диаграмме варианта использования преобразует ее в артефакт

При двойном нажатии на артефакт-снимок откроется связанный Xaml-файл с выбранным вами средством просмотра XML, например, Internet Explorer. Таким образом, можно непосредственно связать диаграммы варианта использования с UI, предоставляя разработчикам возможность лучше понять проект и одновременного включения идей дизайнеров пользовательского интерфейса.

Наблюдение

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

Результатом наблюдения может быть диаграмма бизнес-активностей или последовательность шагов, представляющих рабочие процедуры (сценарии использования). Эта документация должна храниться в библиотеке требований документации TFS для использования в ходе анализа для выявления наиболее значимых функциональных требований. Смотрите раздел «Анализ и Декомпозиция» для более конкретных рекомендаций.

Рецензирование существующих требований

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

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

Механизмы формального рецензирования требований:

  1. Распространение документации, которая должна быть рассмотрена, каждому из заинтересованных лиц для проверки.
  2. Попросите каждого участника рассмотреть документ с их точки зрения и документировать или выделить любые вопросы, дополнительные или упущенные требования или ограничения относительно возможности осуществления этого требования. Их точка зрения определяется той ролью, которую они выполняют, то есть инженер испытаний должен иметь возможность определить тесты для требований в документации. Архитектор инфраструктуры должен сопоставить новые функциональные возможности своей производительности для гарантированной поддержки больших приложений на оборудование предприятия или DBA необходимо определить, есть ли какая-либо информация, которая приведет к требованиям увеличения хранилищ для корпоративных баз данных.
  3. Используйте контрольные списки для проверки каждого документа на покрытие каждой точки зрения. Смотрите раздел руководства «Валидация требований«.
  4. После предоставления заинтересованным сторонам времени для самостоятельного рецензирования, соберите их вместе для обсуждения своих выводов. Это даст им возможность проверить свои выводы со всеми участниками, а также возможность выявить недостающие требования.
  5. Результаты анализа должны быть отмечены в качестве рабочих элементов либо требования, либо запроса на изменение или задачи для дальнейшего анализа или утверждения.

Тема выявления в Agile

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

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

  1. Создание журнала продукта – для гибких команд (Scrum), журнал продукта представляет собой все требования, которые должны быть разработаны командой разработчиков. Владелец продукта несет ответственность за создание этого списка. Он может использовать многие из описанных выше методов для руководства в формировании списка. Однако основное различие заключается в том, что он обычно не обеспечивает формальности для этого. Планирование рассчитывается на очень короткий период времени, и вся группа заинтересованных лиц рассматривается в качестве однородной группы источников для различных требований, которые поставляются в журнал продукта. Качество журнала не столь высокое, как в традиционных проектах. Это не является ни риском, ни недостатком, потому что гибкая команда вновь будет пересматривать его с владельцем продукта и другими заинтересованными сторонами, чтобы углубиться в детали, когда придет время.
    Журнал продукта должен храниться в TFS как рабочие элементы «Требование», «Сценарий» или «Качество обслуживания».
  2. Анализ Журнала итераций – как только «кусок» журнала продукта утвержден в качестве цели для итерации, члены команды разработчиков будут использовать в основном техники интервью и неофициальных раскадровок для конкретизации деталей пользовательского описания функциональности, опираясь на владельца продукта или его делегата для предоставления детализации. Документация используется по минимуму. Этого достаточно, чтобы позволить членам команды разработать и сопоставить поведение требований к архитектуре предприятия/приложения, написать свои тесты и код и выполнить приемо-сдаточные испытания для них.
    Для хранения элемент журнала, как правило, представляется в виде рабочего элемента «Требование» в шаблоне процесса MSF для CMMI , или «Сценарий» шаблона процесса MSF для Agile.

Руководство по выявлению для традиционной разработки

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

В TFS, шаблон процесса MSF для CMMI обеспечивает поддержку для управления требованиями и разработку требований, которые компания может использовать для организации их в соответствии модели качества CMMI уровня 3. В рамках этого руководства шаблона процесса Microsoft определил «персонажи», которые могут быть использованы для определения пользователей, которые помогут выявить функциональные требования.

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

Дополнительные комментарии по традиционному выявлению

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

Для того чтобы обеспечить такую поддержку, используются следующие правила:

  1. Если вы собираетесь получить требования от заинтересованных сторон:
    1. Планируйте работы и используйте рабочие элементы «Задача» для оценки и отслеживания работ выявления.
    2. Разработайте и применяйте контрольные списки к конкретным областям и работам по выявлению, которые должны быть выполнены. Храните шаблон контрольного списка в TFS в шаблонах требований библиотеки документации.
    3. Измените название шаблона, заполните его, добавьте свою контактную информацию и дату, когда он использовался, а затем сохраните результат в библиотеке документации артефактов Требований в TFS.
    4. Связывайте любые результирующие рабочие элементы с артефактами в библиотеке документации.
  2. Если вы выявляете требования из ранее сформированной документации:
    1. Планируйте работы и используйте рабочие элементы «Задача» для оценки и отслеживания работ выявления.
    2. Разработайте и применяйте контрольные списки к конкретным областям и работам по выявлению, которые должны быть выполнены. Храните шаблон контрольного списка в TFS в шаблонах требований библиотеки документации.
    3. Измените название шаблона, заполните его, добавьте свою контактную информацию и дату, когда он использовался, а затем сохраните результат в библиотеке документации артефактов Требований в TFS.
    4. Связывайте любые результирующие рабочие элементы с артефактами в библиотеке документации.
  3. Если по итогам интервью, «мозгового штурма» или другой сессии в рамках семинара по требованиям:
    1. Планируйте работы и используйте рабочие элементы «Задача» для оценки и отслеживания работ выявления.
    2. Разработайте и применяйте контрольные списки и шаблоны для документирования результатов работы. Храните их в шаблонах документации библиотеки TFS Team Project.
    3. Заполните шаблон, измените его название, добавьте имена и роли всех участников, а также добавьте даты события в документ перед его сохранением в библиотеке документации артефактов требований в TFS Team Project.
    4. Связывайте любые результирующие рабочие элементы с артефактами в библиотеке документации.
  4. Если вы создаете больше, чем просто рабочий элемент для представления набора требований:
    1. Разработайте и используйте шаблон, который доступен для всей организации (хранится в шаблонах библиотеки документации TFS Team Project)
    2. Храните итоговые документы, таблицы, графики и т.д. в библиотеке документации требований TFS Team Project
    3. Связывайте результирующий файл с соответствующими рабочими элементами через URL ссылки в TFS.

1 — ChrKang92, p. 4 — Christel, M. G., & Kang, K. C. (1992). Issues in Requirements Elicitation. Pittsburgh, PA: Software Engineering Institute.
2 — SEI 91, p.26 — Software Engineering Institute. (1991). Requirements Engineering and Analysis Workshop Proceedings, Technical Report. Software Engineering Institute Requirements Engineering Project. Pittsburgh, PA: Software Engineering Institute.
3 — Rat99 — Rational Software Corporation. (1999). Guideline: Brainstorming and Idea Reduction. The Rational Unified Process . Rational Software Corporation.

<<Содержание

Posted in Microsoft, Requirements Management Guidance, Team Foundation Server, Visual Studio | Отмечено: , , , , , , , , , | 2 комментария »

Руководство по управлению требованиями VS TFS 2010 – Дополнительные интеграции

Posted by Шамрай Александр на Июнь 17, 2010

<<Содержание

Различные производители программного обеспечения и партнеры Microsoft разработали интеграции с Visual Studio, которые предоставляют возможности не очень хорошо реализованные в Visual Studio Team Suite. В частности, они имеют встроенные возможности в следующих областях: выявление, спецификации, валидации и управления изменениями. Вот список некоторых из наиболее тесно интегрированных решений.

TeamSpec

TeamSolutions является компанией, которая разработала интеграцию между Microsoft Word и VisualStudio. TeamSpec позволяет вести спецификацию требований в Team Foundation Server с помощью интеграции, которая позволяет организовать синхронизацию заголовков и абзацев в Word с рабочими элементами в Visual Studio.

Для дополнительной информации:

TeamSpec компании TeamSolutions

http://www.teamsystemsolutions.com/teamspec

Joe Buys – jbuys@personifydesign.com

stpSoft

Компания stpSoft разработала подобную интеграции, но также поддерживает интеграцию для Visio и VisualStudio, которая связывает сценарии использования и диаграмм деятельности с рабочими элементами в VisualStudio. Их интеграция конкретно обеспечивает раскадровки как техники выявления.

Для дополнительной информации:

stpSoft

http://www.stpsoft.co.uk/stpbadeveloper1.html

Badr Khan – badrk@stpsoft.co.uk

Ravenflow

Ravenflow предоставляет приложение, поддерживающее выявление требований, спецификацию и валидацию. Благодаря интеграции с Visual Studio, команды разработчиков могут придать импульс их разработке с требованиями, которые представлены как прокси для Raven.

Для дополнительной информации:

Ravenflow

1900 Powell Street, Suite 500

Emeryvill, CA 94608

510-285-4600

http://www.ravenflow.com

IBM DOORs

DOORs – это мощная среда для управления требованиями, которая обеспечивает выявление, спецификацию, управление изменениями и утверждение требований. Его интеграция разработана для двунаправленной синхронизации с Visual Studio.

Для дополнительной информации:

Jared Pulham – jared.pulham@uk.ibm.com

http://www-01.ibm.com/software/awdtools/doors/

<<Содержание

Posted in Microsoft, Requirements Management Guidance, Team Foundation Server, Visual Studio | Отмечено: , , , , , , , , , | Leave a Comment »

Руководство по управлению требованиями VS TFS 2010 – Анализ влияния

Posted by Шамрай Александр на Апрель 20, 2010

<<Содержание

«Запросы на изменения могут не только показывать новые или изменившиеся требования, но также и сбои, дефекты в рабочих продуктах. Запросы на изменение анализируются, чтобы определить влияние изменения на рабочий продукт, связанных рабочих продуктов, а также сроки и стоимость.» – CMMI, Guidelines for Process Integration and Product Improvement, Chrissis, Konrad, Shrum.

Анализ влияния выполняется для:

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

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

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

Описание оценки влияния

Процесс анализа влияния – Процедурное руководство от анализа влияния до изменения

  • Процесс рассмотрения изменений и их зависимостей, а также документирование их результатов влияния.
    Когда изменения внесены, то это либо запрос от заказчика, который выходит за рамки проекта, или это неправильно понятые требования, которые должны быть переписаны для удаления недоразумения. Сначала это запрос на расширение, потом это дефект требования. То же самое применимо для разработки и тестирования изменений. Они, по сути, вновь открывшиеся обстоятельства, которые влияют на границы и поставки проекта.
    Для этих изменений важно, чтобы была сохранена Трассировка в ходе реализации проекта и процесс Управление изменениями и утверждения был внедрен и выполнялся. Смотрите соответствующие разделы для детального описания. Эти разделы описывают использование Team Foundation Server для создания и отслеживания трассировки между рабочими элементами и другими активами, а также управления изменениями, базовыми линиями и сравнения, которые необходимы для понимания влияния изменений.
    Смотрите отчеты, описанные в Трассировке требований, как вспомогательные для работ анализа влияния.

Процесс Анализа влияния

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

Рассмотрение Запроса на расширение

Эта задача похожа на бизнес-анализ или анализ границ. Задача аналитика – понять, что точно запрос значит для заказчика. Смотрите раздел Анализа и декомпозиции для более детальной информации. В основе лежит связывание запроса с рабочим элементом Возможность (Feature), Пользовательская история (User Story) или Требование (Requirement) (в зависимости от того, что используется MSF for Agile и MSF for CMMI), либо связывание Запроса на изменение с рабочим элементом Проблема(Issue)/Ошибка(bug), или создание Возможности (Feature), Пользовательской истории (User Story) или Требования (Requirement) непосредственно для его описания.

Ответственный: Менеджер проекта/Администратор

Следующий рисунок отображает рабочий элемент Возможность (Feature) (ID # 54), который необходимо изменить (Новая проблема). Пользователь Team Foundation Server находится в середине установления связи между рабочим элементом Проблема (Issue) и рабочим элементом Возможность (Feature).

Определение затрагиваемых функциональных областей

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

  1. Изменение для добавления новой функциональности
  2. Изменение для удаления функциональности
  3. Изменение для изменения существующей функциональности
  4. Добавление нефункциональных требований (например, производительность, надежность, операционная поддержка)

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

  • Сначала создается запрос для всех функциональных требований.
  • Сканируется список кандидатов требований и те, что похожи на новые функциональные возможности, изолируются. Самый простой способ заключается в просмотре требований Пользовательских историй, которые представляют Возможность, для определения влияния на них Запроса на изменение. На следующем рисунке рабочий элемент Возможность связанный с подсвеченной Пользовательской историей (# 55), которая, как представляется, затрагивается изменениями.

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

  • Для каждого из функциональных изменений создается рабочий элемент Требование (Requirement) и ссылка на документ, из которого он найден с помощью типа связи URL. Каждый новый рабочий элемент требование или пользовательская история будет иметь ссылку на тот же документ, показанный выше, и, возможно, другие документы в той же библиотеке документов на портале SharePoint.

Ответственный: Бизнес-аналитик

Определение затрагиваемых тестов

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

Ответственный: Ведущий тестер

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

И следующий рисунок показывает пользовательскую историю (# 55) и системные тесты, которые должны быть в регрессии:

Определение затрагиваемого Исходного кода

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

Ответственный: Разработчик / Архитектор

На следующем рисунке подсвечена затронутая пользовательская история и показаны ее ссылки «Реализации» (Implementation). Ссылки реализации – это задачи, которые необходимо выполнить для того, чтобы реализовать требование или пользовательскую историю.

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

Следующий рисунок показывается задача (# 78) и набор ее изменений показывает необходимые исходные файлы для изменения.

Оценка трудозатрат

Эта задача выполняется в два шага:

  1. Определить выполняемые задачи – разработчик и архитектор анализируют новые или измененные функциональные возможности и определяют новые задачи, необходимые для осуществления изменения. Задачи должны быть связаны с помощью типа связи Реализация (Implementation) (родительская/дочерняя иерархия). Рисунок ниже показывает специальный запрос, где возможность, которую необходимо изменить, была выделена в итерацию «Запрос на изменение» (change request). Используя тип запроса дерево, мы можем определить все требования, которые реализуют эту возможность в качестве кандидатов на эти изменения. Как видно из предыдущего анализа влияния, известно, что затрагивается только пользовательская история # 55, она и ее задачи реализации подчеркнуты на рисунке. Новые задачи должны быть описаны для осуществления изменений, в то время как по старым выполненным задачам будут определены исходные файлы, которые должны быть изменены.
  2. Определить задачи управления тестированием – для каждого нового требования, определяются новые тесты, которые будут проверять новые требования. Смотрите раздел Валидация для идей о комплексных подходах с положительными и отрицательными тестовыми сценариями. Свяжите новые тестовые сценарии, используя тип связи Тест (Test). Для каждого существующего требования, которое должно быть изменено, просматриваются их связанные тесты, чтобы убедиться, что их реализация покрывает изменения. После выявления тестов определяются рабочие элементы Задача (task), которые представляют собой работы, необходимые для внесения соответствующих изменений в тестовые модели. Эти задачи будут оцениваться и отслеживаться в ходе реализации изменения.

Отчет о влиянии и ожидание разрешение на осуществление

На данный момент все необходимые воздействия были выявлены. Собираются рабочие элементы и создается отчет, отражающий необходимую работу. Рекомендуемый способ сделать – это пометить каждый новый и существующий рабочий элемент с использованием значений атрибута «Область» (Area) или общей «Итерации» (Iteration), которая представляет собой усилия необходимые для изменений. Далее отчет просто создается с помощью фильтра для всех рабочих элементов на основе этого значения. При использовании итерационных моделей разработки, «Область» (Area) должна использоваться для выявления всех затрагиваемых рабочих элементов по общему запросу на изменение, оставляя остальную итерацию открытой для новых рабочих элементов по данной итерации, в противном случае полной итерации для изменения было бы достаточно.

Заключение

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

<<Содержание

Posted in Microsoft, Requirements Management Guidance, Team Foundation Server, Visual Studio | Отмечено: , , , , , , , , , | Leave a Comment »

Руководство по управлению требованиями VS TFS 2010 – Трассировка Требований

Posted by Шамрай Александр на Апрель 20, 2010

<<Содержание

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

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

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

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

Эта тема в проекте 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:

Artifact Team Foundation Server Representation
Возможность (Feature) Тип рабочего элемента Возможности системы (MSF for CMMI)
Функция (Function) Тип рабочего элемента Требование с типом = Функциональное (Functional) для MSF for CMMI 

Пользовательская история (User Story) для MSF for Agile

Качество обслуживания (QoS (Quality of Service)) Тип рабочего элемента Требование с типом = Качество обслуживания (Quality of Service) для MSF for CMMI 

Пользовательская история (User Story) для MSF for Agile

Тестовый сценарий (Test Case) Тип рабочего элемента тестовый сценария (MSF for Agile и MSF for CMMI). Этот рабочий элемент представляет собой контейнер в Microsoft Test и Lab Manger. Он включает в себя Общие Шаги (Shared Steps), которые могут копироваться из сценария в сценарий для часто выполняющейся общей функциональности, например, процедуры входа в систему.
Тест (Test) Тест проекта тестирования в Visual Studio 2010, который представляет модульный или нагрузочный тест на уровне разработки или для «Test Driven Development» (TDD). Функциональные тесты (ручные или автоматические) теперь элементы рабочего элемента Тестового сценария, которые реализовывают шаги процедуры тестирования и тоже могут быть автоматизированы.
Задача Реализации (Implementation Task) Рабочий элемент Задача (Task) в MSF for Agile и MSF for CMMI
Код (Code) Проект (Проводник решений, Версионный контроль)

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

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

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

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

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

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

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

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

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

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

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

  • Сеть

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

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

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

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

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

  • Дерево

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

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

Прямая ссылка Обратная ссылка Имя ссылки для типа связи Топология
Последователь Предшественник System.LinkTypes.Dependency Зависимость
Дочерняя Родительская System.LinkTypes.Hierarchy Дерево
Связанный Связанный System.LinkTypes.Related Сеть

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

Прямая ссылка Обратная ссылка Имя ссылки для типа связи Topology
Тестируется Тестирует Microsoft.VSTS.Common.TestedBy Зависимость
Тестовый сценарий Общие шаги Microsoft.VSTS.TestCase.SharedStepReferencedBy Зависимость

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

Рисунок 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 соответствие означает демонстрацию, что проект может трассировать все бизнес-требования к функциональным требованиям, к техническим требованиям, к тестам и, в конечном счете, к исходному коду и дефектам. Следующая таблица является простой демонстрацией типичной ручной или с помощью электронных таблиц реализацией матрицы трассировки:

БИД Бизнес-требование. ФИД Функциональное требование. ТИД Техническое требование ТСИД Тестовый сценарий Исходный код
\\sharedlibrary\project_doc\Requirements\My Project Business Requirements.doc
BR-1 Приложение должны улучшить впечатление клиентов при покупке нашей продукции, что дает нам повышение уровень удовлетворенности клиентов (CUST-SAT) и повысит наши доходы. UC-1 \\sharedlibrary\project_doc\Requirements\Customer_Self_Service_Purchase_Use_Case.doc
TR-1 Поддержка этой функции для 200000 одновременно работающих пользователей без снижения производительности TC-1 Проверить, длительность транзакции для одного пользователя и сравнить со средней продолжительностью при 200000 одновременных транзакций \\my_workspace\source\my_source.cs
 

\\my_workspace\source\my_source2.cs

Т.д.

TR-2 Разработка руководств по эксплуатации и устранения неисправностей для службы технической поддержки. TC-2 Проверить ля, ля, ля \\my_workspace\source\my_source.cs
 

\\my_workspace\source\my_source2.cs

Т.д.

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

  • Для электронной таблицы только один человек может изменять в один момент времени. Есть государственные организации, которые нанимают сотрудников, которые занимаются в проекте только поддержкой этой трассировки. Их работа включает обход каждого разработчика, бизнес-аналитика, менеджера проекта, и т.д. и сбор их изменений, чтобы включить их в матрицу и обеспечить анализ их воздействия для команды. Это выглядит (по мнению автора) пустой тратой государственных средств (так называемых наших налогов).
  • Электронные таблицы почти бесполезны для отслеживания влияния изменений или областей, пострадавших от дефектов. В 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 Манифеста «Работай над программным обеспечением, а не над Всеобъемлющей документацией», гибкая команда ищет иерархию трассировки с минималистским подходом. Однако, с учетом сказанного, должна быть достаточная трассировка к документации, которая гарантирует, что команда может эффективно покрыть все их требования и определить влияние изменений и новых требований в отношении существующего проекта. Следующая диаграмма показывает минималистский подход, который ложиться на общую иерархию трассировки приведенную выше.

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

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

<<Содержание

Posted in Microsoft, Requirements Management Guidance, Team Foundation Server, Visual Studio | Отмечено: , , , , , , , , , , | Leave a Comment »

Руководство по управлению требованиями VS TFS 2010 – Управление изменениями и утверждение требований

Posted by Шамрай Александр на Апрель 14, 2010

<<Содержание

«Базовая линия – это набор спецификаций или рабочих элементов, который был формально рассмотрен и согласован и впоследствии служит основой для дальнейшей разработки, и который может быть изменен только с использованием процедур контроля изменений. Базовая линия представляет собой назначенный идентификатор для элементов конфигурации и связанных с ней сущностей. «- CMMI, Guidelines for Process Integration and Product Improvement, Chrissis, Konrad, Shrum.

Управление изменениями требований осуществляется для:

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

Управление изменениями требований и утверждение описывает, как участник процесса формально получает утверждение для новых требований или изменений/расширений существующих требований. Фокус в этом разделе будет сделан на описании действий процесса изменения требований, управления базовыми линиями требований и разрешения на продолжение работ по реализации требования. Также будет уделяться большое внимание к соблюдению промышленных стандартов таких, как CMMI и ITIL, соответствие отраслевым нормам такие, как FDA CFR-21, Часть 11 и закона Сарбейнса-Оксли, тоже может рассматриваться.

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

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

Управление изменениями и утверждения — Общие сценарии

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

Новые требования

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

Запрос на расширение

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

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

Дефекты требований

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

  • Элементы Запрос на изменение – эти запросы на изменение должны включать в себя данные, необходимые для проведения анализа влияния изменений, а также обеспечивать оценки затрат и утверждение. Эти вопросы можно отнести к неверному пониманию требований определенными заинтересованными лицами в проекте. Как правило, они обеспечивают изменения в первоначальные требования, но также могут быть введены новые требования или открыты требование, которые были помечены как устаревшие и на удаление.
  • Последовательность работ — каждый запрос на изменение должен обеспечить механизмы для обследования, утверждения, назначения, анализа, разработки и проверки нового запроса в ходе жизненного цикла. Этот процесс более строгий для традиционного водопадного проекта и менее формален для гибкого проекта, для гибкой команды существуют правила для внедрения новых требований.
  • Утверждение — этап утверждения необходим для каждого состояния (или «Ворот») рабочего процесса для традиционного проекта. Утверждение на окончании этапа или окончании цикла релиза необходимо для контроля для всех проектов. Релиз для традиционного проекта означает развертывание в конце проекта, а релиз для гибкого проекта выполняется в конце каждой итерации на протяжении всего проекта.

Обнаруженные «на лету»

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

Управление изменениями и утверждение – Поддержка сценариев в Team Foundation Server

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

Изменения требований в традиционной водопадной модели также просты, но только в механизмах создания, сравнения и утверждения базовой линии. Управление изменениями требований на лету немного сложнее, потому что методика водопада требует не только оценки изменений в требованиях, но и изменения в контексте ВСЕХ других проектных артефактов, плана проекта, последовательности выполнения, проектных зависимостей, качества обслуживания и т.д. Таким образом, управление изменениями и утверждение для традиционного проекта требует дополнительных работ и жесткой привязки к его «воротам» (условиям окончания). Даже при такой политике, предсказуемость гораздо труднее обеспечить для традиционных проектов.

Подготовка управления базовой линии

Требования описаны с помощью конкретных типов рабочих элементов в Team Foundation Server (например, типы рабочего элемента сценарий или пользовательское описание функциональности). Документация (технические характеристики и прототипы) хранятся на SharePoint-сайте проекта. Рабочие элементы связываются с документами сайта проекта с помощью гиперссылок. Эти гиперссылки могут быть размещены и в рабочих элементах, которые задают определенную часть работы в области разработки для разработчика.

Библиотека документов командного сайта построена так, чтобы отражать гибкость подхода, которая соблюдается. В библиотеке Requirements создаются папки как система записей. Это хорошая практика, когда различные виды активов организованы в их собственные папки. Например, требования описания (Stories) должны быть в одной папке, а нефункциональные (Quality of Service) требования должны быть в другой. Документы общие для всего проекта, такие как видение продукта, ограничения продукта или дополнительные характеристики нефункциональных требований, должны быть сохранены в корне папки требований.

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

Рисунок 1. Представление документов в Team Explorer и WSS

На скриншоте выше слева в Team Explorer открыта папка библиотеки документов, отображающая требования и описания. Те же документы отражены в правой части в двух представлениях портала Windows SharePoint Services (WSS). Это сравнение показывает, что члены команды Team Foundation Server могут использовать документы в любом приложении, в зависимости от того, где они больше работают. Разработчики и аналитики, например, могут работать в Team Explorer, в то время как менеджеры и бизнес-аналитики могут использовать портал.

Рисунок 2. Установка связи между рабочими элментами и документами

Документы, хранящиеся на командном сайте также доступны прямо из Visual Studio IDE. Team Foundation Server предоставляет мощный механизм для связывания документов и других артефактов на основе файлов с рабочими элементами. Если документы размещены в библиотеке документации с включенным пунктом «Versioning» в портале для изменений в документах, то связанный рабочий элемент с типом связи «гиперссылка» всегда будет ссылаться на последнюю версию.

Участники проекта могут сравнивать последнюю версию документа с его предшественниками помощью функциональности сравнения в Word, которая осуществляется с помощью возможности «Revision Tracking» версионного хранения портала SharePoint.

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

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

Продвижение базовой линии

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

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

Это руководство описывает оба типа базовых линий в следующих двух подразделах.

Управление внутрифазовыми базовыми линиями

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

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

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

В целях создания базовой линии, все важные артефакты должны быть получены и сохранены в местах, отведенных для базовой линии. Рекомендуется создать библиотеку документов «Project Milestones» с отдельными директориями для каждого этапа. Тут «Iteration 0», «Iteration 1», «Iteration 2» и т.д. Важные артефакты, находящиеся здесь, демонстрируют полною трассировку иерархии от требований бизнеса до кода и результатов тестов, созданных в этой вехе:

  • Выбранные Бизнес-требования – используя запросы для рабочих элементов с фильтром для рабочих элементов «Возможность» (Feature) со всеми атрибутами, которые способствуют решению для разработки приложений, можно выбрать весь набор в Excel таблицу и сохранить в каталоге вехи.
  • Выбранные Сценарии – используя запрос для рабочих элементов с фильтром по рабочим элементам «Сценарий» (Scenario), связанные только с вехой (например, «Iteration Path = Iteration 0»), со всеми их атрибутами, можно извлечь весь набор в Excel таблицу и сохранить в каталог вехи.
  • Выбранные Задачи – то же, что сценарии, но только фильтр по рабочим элементам «Задача» (Task) для итерации.
  • Описания – каждый документ, который представляет собой фрагмент сценария итерации, должен быть скопирован в каталог вехи. Хотя ревизия истории в SharePoint позволяет сравнивать документы от версии к версии, эта копия позволит легче сравнивать принятую «базовую версию» и текущие изменения. Без этой копии будет трудно понять, какой документ нужно сравнивать.
  • Другие документы — любые другие документы такие, как спецификация проектирования, документ видение, архитектура и характеристика инфраструктуры и т.д., должны быть скопированы в каталог вехи.
  • Отчет сборки — снимок окончательной сборки позволит установить связь между документацией (рабочими элементами и файлами) для базовой линии и исходными файлами, тестами и результатами тестов для той же базовой линии. Отчет по сборке – это отчет, который поставляется как стандарт с шаблонами процессов «MSF for Agile» «и «MSF for CMMI». Это список всех сборок, хранящихся в системе. Только одна имеет значение, которая является окончательной сборкой для итерации, представляющую базовую линию. Эта информация должна храниться в виде файла в папке вехи итерации.

Рисунок 3. Файлы для базовой линии итерации

Рисунок 4. Финальный отчет для сборки итерации

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

Утверждение базовой линии

Многие методики, особенно которые используют отраслевые стандарты (CMMI) или государственные регулирования (FDA, закон Сарбейнса-Оксли), требуют пересмотра и утверждения базовых линий. При создании базовых линий, как описано выше, WSS может поддерживать такой цикл утверждения.

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

Рисунок 5. Группа управления запросами на изменение

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

Рисунок 6. Утверждение базовой линии

Методы сравнения 2-х базовых линий

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

  • Веха документирования бизнес-требований (BRD) – бизнес-требования были утверждены и приняты за основу.
  • Веха документирования функциональных требований (FRD) – функциональные требования были утверждены и приняты за основу.
  • Веха документирования технических требований (TRD) – технические требования были утверждены и приняты за основу.

В проекте Agile утверждаются и принимаются за основу журнал продукта и журнал итерации.

Каждый тип требования (представленный в виде типа рабочего элемента в Team Foundation Server) должен быть выгружен из Team Foundation Server в электронную таблицу Excel. Структура всех трассируемых атрибутов для рабочих элементов должна быть задана в запросе по рабочим элементам перед началом процедуры экспорта:

На рисунке выше показан результат запроса Требования к продукту и все применимые атрибуты. Это будет служить в качестве основы для базовой линии Требований к продукту. Подобный список с задачами по проекту может быть экспортирован в дополнение к требованиям.

На следующем шаге создание Excel таблицы на основе этого списка. Функция, которая это делает, выделена красным цветом на рисунке выше. Результат будет выглядеть следующим образом:

Эта таблица должна быть сохранена с именем соответствующей вехи. Например, может называться «Итерация 1– Базовая линия требований к продукту». Дополнительный лист книги может называться «Итерация 1 – Базовая линия задач».

Храниться каждый файлов, относящийся к базовой линии, в папке вехи проекта в библиотеки документов, созданной для хранения базовой линии. ВСЕ файлы, связанные с требованиями, которые входят в базовую линию, должны храниться в той же библиотеке документов в качестве базовой линии требований. Из-за особенностей этой базовой линии, такой механизм обеспечит хранение всех документов в SharePoint с фиксированием времени и идентификации пользователя, который сохранил их там. Если организация требует соблюдения правил, таких как FDA CFR-21, часть 11, то документ для подписи можно создать и хранить в общем комплекте или он может быть сгруппирован в пакет, который будет поставлен в средство, поддерживающее цифровую подпись пакета документов.

Если анализ должен проводиться для определения изменчивости требований или просто для понимания изменений от одной вехи к следующей, то можно использовать инструменты сравнения такие как Excel Compare от Formula Software, Inc. (http://www.formulasoft.com), которые позволят сравнить однотипные требования базовой линии от одной вехи к другой (Т. е. Iteration 0 Feature Baseline.xlsx и Iteration 1 Feature Baseline.xlsx).

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

Для традиционных проектов контроль не как естественное. Изменения требуют рабочего процесса, который включает в себя принятие незапланированного времени в процессе разработки для анализа влияния изменений, оценки рабочих затрат, а затем постановка и получение утверждения для внесения изменений в проект. Более формальные организации используют системы управления изменениями для поддержки их циклов изменений и утверждения. С помощью Team Foundation Server тип рабочего элемента Запрос на изменение может реализовывать процесс управления изменениями, где он может иметь жизненный цикл на основании состояний, что позволяет организовать переходы для анализа, оценки, постановки и утверждения. После утверждения команда может включать изменения в свою разработку. Рабочий элемент Запрос на изменение может быть связан, используя тех же механизмы ссылок, описанные выше для трассировки к требованиям или требований, которые добавляются или обновляются на основании запроса.

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

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

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

Процесс управления изменениями

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

Рисунок 7. Процесс управления изменениями для гибких проектов

Бизнес требует изменение

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

Новое требование

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

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

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

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

Изменение для текущего требования в журнале

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

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

Требование в журнале будет иметь статус утверждения Черновик и младший номер версии.

Рисунок 8. Требование в журнале

Рисунок 9. Регистрация требования с младшим номером

Изменение текущих разрабатываемых требований

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

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

Должны быть определены следующие параметры:

Может ли этот запрос на изменение рассматриваться просто в качестве уточнения по требованию?

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

Рисунок 10. Версионная история документа для уточнения

Рисунок 11. Комментарий должен быть добавлен на вкладке истории рабочего документа

Требование остается полезным без изменений?

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

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

Рисунок 12. Задача, запланированная на итерацию 1

Рисунок 13. Задача более не назначена и находится в журнале

Процесс управления изменениями, характерный для традиционных проектов

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

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

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

Рисунок 14. Подробное описание в истории об изменениях очень важно

Процесс утверждения

Процесс утверждения, который представлен ниже, важен даже для гибких проектов.

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

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

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

Рисунок 15. «Легкий» процесс утверждения

Настройка сайта команды для поддержки процесса утверждения

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

Рисунок 16. Включение управления версиями и утверждения

Рисунок 17. Настройка библиотеки документов

Рисунок 18. Рекомендуемые настройки

Рисунок 19. Автор документа публикует документ с основной версией – состояние утверждения «Черновик»

Рисунок 20. Утверждение документа

Рисунок 21. Состояние утверждения документа

Заключение

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

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

  • Уменьшение «Изменчивости границ»
  • Улучшение Анализа влияния
  • Всесторонний охват тестирования требований
  • Совершенствование и повышение эффективности командной коммуникации

<<Содержание

Posted in Microsoft, Requirements Management Guidance, Team Foundation Server, Visual Studio | Отмечено: , , , , , , , , , | Leave a Comment »

Руководство по управлению требованиями VS TFS 2010 – Валидация требований

Posted by Шамрай Александр на Апрель 7, 2010

<<Содержание

«Валидация гарантирует, что требования отвечают желаемым характеристикам правильно поставленных требований (полнота, правильность, возможность, необходимость, приоритеты, однозначность и проверяемость), а также правильной спецификации требований (полнота, последовательность, модифицируемость и трассируемость)» – Software requirements second edition, Karl E. Wiegers.

Валидация представляет собой процесс оценки, будет ли конечный продукт удовлетворять требованиям заказчика, и помогает удостовериться, что требования были правильно поняты. Такой подход к поставке в последнее время называют » Test-First Development » или » Requirements-Based Testing «. С валидацией участник проекта устанавливает критерии приемки для достижения соглашения с заинтересованными лицами о том, что будет поставлено. Это включает в себя проверку бизнес-требований, функциональных требований, нефункциональных требований, сценариев использования, моделей, прототипов и т.д.

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

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

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

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

Методы

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

Планы тестирования

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

Рисунок 1. V-модель для управления тестированием

При разработке каждого уровня требований, которые находятся по левую сторону, правила валидации с использованием методов, описанных выше, будут помогать в разработке тестов, которые будут использоваться для проверки после поставки приложения, компоненты или системы. Лучшие процессы, которым нужно следовать – это «Test First Development» или «Requirements-Based Testing», где составляющая часть не рассматривается как готовая, пока определенные тесты не выполняются и не проходят успешно.

Итак, на основе V-модели описанной выше, следующий сценарий может быть применен на этапах развития всех описанных элементов:

  • Определено бизнес-требования, но оно не готово для анализа на функциональные и нефункциональные требований, пока его приемочные тесты не будут установлены и подтверждены. Определите пользовательские приемосдаточные тесты (User Acceptance Test Cases) и свяжите с требованием Возможность (Feature Requirement).
    • Откройте форму Возможность (Feature) в проекте Team Foundation Server. Перейдите на вкладку Links, чтобы увидеть дочерние пользовательские истории (если вы откроете Возможность из шаблона процесса MSF Agile).
    • Из меню Team или панели инструментов на вкладке Links выберите Add New Linked Work Item …. В появившемся диалоговом окне выберите тип связи Tested by и рабочий элемент Test Case. Затем добавьте название для нового рабочего элемента. Можно также добавить комментарий.
    • Новый рабочий элемент позволяет тестировщику планировать, разрабатывать и вести вместе с разработкой модель тестирования для проекта разработки. На вкладке Steps пользователь может определить шаги для выполнения ручного тестирования. Мы не будем показывать это здесь, но этот рабочий элемент, при открытии в клиенте Microsoft Test and Lab Manager, позволяет запускать приложения для тестирования с просмотром этих шагов и отмечать успех или неудачу для каждого шага, а также с просмотром наблюдаемых результатов (которые можно включать в стек вызовов!).
    • Поле Summary Task такое же, как и поле описания любого другого рабочего элемента. Здесь вводится высокоуровневое описание ожидания заказчика. Можно задать следующий вопрос заказчику, для того, чтоб быть уверенными, что заказчика правильно поняли: «Если будет сделана эта функция, что покажет, что она сделана правильно?» Ответ клиента, с небольшой доработкой аналитика, должен быть главным описанием процедуры приемочного теста.
    • Вкладка Tested Work Items отображает ссылку на Возможность (Feature), которая была только что связана:
    • Сохраните рабочий элемент, а затем дважды щелкните на Возможности (Feature) и выберите ее вкладку связей, чтобы увидеть новый тестовый сценарий связанный с ней.
  • Требования к функционалу и качеству обслуживания не могут быть переданы дизайнерам и архитекторам, пока их тестовые сценарии не определены (не обязательно записаны) и не утверждены. Опишите высокоуровневые шаги тестового сценария
    • Открыть дочернее требование одного из рабочих элементов возможности. Это будет рабочий элемент либо Требование (Requirement) или Пользовательское описание функциональности (User Story), в зависимости от используемого шаблона процесса. Выберите вкладку Test Cases, чтобы начать определение тестов. Выберите Add New Linked Work Item … как показано в окне ниже.
    • В появившемся диалоговом окне введите название для нового сценария тестирования. Только один вариант доступен как тип ссылки Tested By и тип рабочего элемента Тестовый сценарий (Test Case), поэтому никаких других атрибутов выбирать не нужно.
    • Результирующий рабочий элемент, как и в предыдущий процедуре, связывается с пользовательской историей, также как тестовый сценарий связывается с возможностью. Есть одно концептуальное отличие. Тестовый сценарий связанный с возможностью является Пользовательским приемочным тестом (User Acceptance Test case), а тестовый сценарий связанный с рабочим элементом системного требования является Системным тестом (System Test case).
  • Разработка приложения не может быть передана разработчикам, пока каждый компонент не имеет интеграционных тестов и тесты по методу «черный ящик» не определены и не утверждены.
    • разработчик может разрабатывать связанные модульные тесты для его кода с целью написания тестируемого кода
  • Код должен пройти весь набор написанных модульных тестов, прежде чем мы перейдем в правую часть модели.
  • После того, модульные тесты проходят, компонент, который инкапсулируется протестированным кодом, может быть протестирован. Мы можем сделать это эффективно, поскольку интеграционные тесты и тесты по методу «черного ящика» были определены в ходе разработки.
  • Как только интеграционные и тесты по методу «черного ящика» проходят, системные функциональные и нефункциональные тесты могут быть выполнены. Опять же, мы можем сделать это эффективно, потому что функциональные и нефункциональные тесты были определены и утверждены в рамках спецификации требований. Т.к. ранее были описаны функциональные шаги для каждого рабочего элемента тестового сценария, мы можем просматривать их и создавать тестовые комплекты в клиенте Visual Studio Test and Lab Manager.
  • Далее, как только системные тесты проходят, не нужно ожидать пользовательских приемочных тестов, потому что они уже определены и утверждены во время спецификации бизнес-требований.
    • Пользовательские приемочные тесты могут быть организованы в тестовые комплекты в Visual Studio Test and Lab Manager.

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

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

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

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

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

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

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

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

Модель, показанная ниже, отображает структуру Team Foundation Server, которая поддерживается V-моделью, описанной на предыдущем рисунке. Как видно, Возможность (Feature или бизнес-требование) используется как дополнение к тесту, определенного в тестовом проекте в Visual Studio. Team Foundation Server позволяет пользователю установить связь между рабочим элементом и тестом в тестовом проекте. Более тесная интеграция устанавливается, когда инженер-тестировщик регистрирует изменения проекта тестирования в системе контроля версий. При регистрации изменений, связывание рабочего элемента с набором изменений может быть выполнено в принудительном режиме с использованием политик регистрации Team Foundation Server.

Аналогичный механизм Team Foundation Server поддерживается для Сценариев (Scenario, функциональные) или QoS (качество обслуживания или нефункциональные) требования.

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

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

Контрольные списки

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

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

  • Product Acceptance Checklist – используется в качестве вехи для проверки, что все требования были охвачены необходимой документацией, дизайном, кодом, тестом и других критичными необходимыми артефактами.
  • Requirements Review Checklist – используется в качестве руководства при рецензировании спецификации бизнес-требований, спецификации функциональных требований или спецификации технических требований. Оно проверяет, что стандарты документации были соблюдены и требования правильно сформированы (как описано выше).
  • Requirements Style Checklist – по аналогии с предыдущим.
  • Use Case Review Checklist – Используется для обзора требований сценария и его детального описания, которое должно включать в себя все шаги потоков, графические изображения для них и любые дополнительные сопроводительные данные. В тот же список применяется для пользовательских описаний функциональности гибких проектов или традиционных функциональных требований.
  • High Level Design Review – Используется для проверки, что реализуемые требования на высоком уровне отвечают выбранной архитектуре.
  • Acceptance Test Planning, Results, Change Requests, WBS и другие списки покрывают другие требования и обязанности для проекта.

Обратите внимание, что даже присутствует список » Checklist for a Checklist » в этом пакете.

Используйте шаблон документа «Non-Functional Requirements Template» в качестве контрольного листа для выявления и проверки качества обслуживания (производительности, масштабируемости, бизнес-цикла, обслуживания, поддержки, размещения и т.д.).

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

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

Хороший процесс выполнения инспекций приведен ниже:

  1. Отправлять материалы, которые будут рассмотрены, независимо для каждого рецензента.
  2. Укажите, что каждый рецензент должен анализировать при инспектировании составляющих. Например, тестер должен определить тестируемость составляющих. То есть, могут ли быть тесты написаны и выполнены по завершению. Скажите им внести в документацию пометки, комментарии и критические замечания. Если они находят ошибки, они должны быть готовы для определения альтернативы по этой ошибке.
  3. Наметьте встречи, выделяя участникам достаточно времени для ознакомления с материалом. Неделю, как правило, достаточно времени для этого.
  4. Рассматривайте только те проблемы, которые были определены. Таким образом, совещания эффективно обеспечат, что рецензии будут завершены без потерь чьего-либо времени. Важно отметить, что рецензирование требований или инспекция это не мозговой штурм и сессия генерации идей. Объясните участникам важность их готовности.
  5. Документируйте любые расхождения и определите задачи для авторов на исправление и повторное внесение на инспекцию.

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

Техническая поддержка

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

Специфика CMMI

«Анализируйте требования для определения риска связанного с тем, что конечный продукт не будет работать правильно в его предполагаемой среде использования» – CMMI, Guidelines for Process Integration and Product Improvement, Chrissis, Konrad, Shrum.

<<Содержание

Posted in Microsoft, Requirements Management Guidance, Team Foundation Server, Visual Studio | Отмечено: , , , , , , , , , , | Leave a Comment »

Руководство по управлению требованиями VS TFS 2010 – Спецификация требований

Posted by Шамрай Александр на Февраль 25, 2010

<<Содержание

Описание процесса ввода требований как рабочих элементов для каждой роли и типа рабочих элементов.

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

Требования определяют, что продукт должен делать, чтобы решить проблему клиента. Некоторые из видов требований: сценарий, качество обслуживания, требования безопасности, функциональные требования, операционные требования и требования к интерфейсу. Требование должно начинаться с состояния Предложено, а затем, когда будет принято, оно переходит в состояние Активно, из которого после выполнения и тестирования поставленных задач, оно переходит в состояние Решено, и в конце переходит в Закрыто после проверки. Такой жизненный цикл имеет рабочий элемент требования в шаблоне процесса MSF. Вы можете определить свой жизненный цикл, который подходит Вашему процессу и последовательности работ.

В зависимости от вашего процесса, вы можете создать рабочий элемент для требования как сценарий (функциональные требования для MSF Agile), качество обслуживания (нефункциональные требования для MSF Agile), как история (XP), сценарий использования (RUP) или как требование (MSF для CMMI или Традиционный). Рабочие элементы используются для определения и отслеживания требования. Это позволяет отображать их в вашем журнале, ранжировать, проверять, назначать и формировать отчетность.

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

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

Определение требований (Основы)

Независимо от уровня иерархии при выявлении требований (бизнес, системные или реализация), существуют некоторые основные свойства Team Foundation Server 2010, которые необходимо понимать  для определения требований и их проверки.

Создание рабочих элементов для требований

Для создания рабочих элементов можно использовать Microsoft Project, Microsoft Excel, клиент Team Foundation, Web Access или ваш собственный инструмент с использованием объектной модели Team Foundation. Шаги по созданию рабочих элементов помощью клиента Team Foundation и регистрации вашего требования заключаются в следующем:

  1. Выберите проект в клиенте Team Foundation.
  2. В меню выберите Team | Add Work Item
  3. Выберите тип рабочего элемента – Пользовательское описание функциональности, Качество обслуживания, Требование, и т.д. …

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

Например, для MSF CMMI рабочий элемент требования может определяться как на рисунке ниже (см. Рисунок 1).

Рисунок 1. Регистрация рабочего элемента Требование

Тип рабочего элемента Тестовый сценарий является новым свойством в Visual Studio2010. Этот тип рабочего элемента (РЭ) может быть связан с типом РЭ Требование следующим образом:

Связывание Тестового сценария с Рабочим элементом

Как только вы связали свои требования с РЭ, Вы можете добавить ссылку на сценарий тестирования. Чтобы связать Тестовый сценарий:

  • Откройте рабочий элемент требования, перейдите на вкладку тестирования, нажмите кнопку «Добавить».

Рисунок 2. Добавление ссылки на тестовый сценарий для РЭ требования

  • Выберите тип ссылки Тестируется (см. Рисунок 2) и перейдите к ID рабочего элемента. Можно добавить комментарий для обеспечения прозрачности. Ниже в диалоговом окне отображается рабочий элемент и его связь с Тестовым сценарием. После внесения всех деталей, нажмите кнопку ОК. Результат должен быть как на рисунке ниже (см. Рисунок 3).

Рисунок 3. Добавление тестового сценария для рабочего элемента требование

Эта процедура показывает определение рабочего элемента требования и рабочего элемента тестового сценария для проверки требования. Такая же процедура применяется независимо от типа рабочего элемента или типа связи. Основы определения и отслеживания рабочих элементов работает для каждого уровня иерархии развития.

Границы Спецификации

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

Независимо от методологии, масштаб проекта диктуется новыми или расширяющими возможностями, их уровнем детализации и оценки. Возможность описывается как рабочий элемент, его детали в виде отдельных документов Word, диаграммы Visio, презентации PowerPoint и других файлов. Валидация возможности описывается в виде рабочего элемента тестовый сценарий, а системные требования определяются как Требования (MSF для CMMI) или Пользовательское описание функциональности (MSF для Agile).

Для шаблона MSF CMMI тип рабочего элемента Возможность был добавлен как часть релиза Team Foundation Server 2010. При использовании шаблона MSF для Agile, Возможность не существует, поэтому наша рекомендация следующая: используйте бизнес требования как тип рабочего элемента Возможность в целях отслеживания трассировки от бизнес границ до системных границ.

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

Процедура:

  • Выбрать пункт меню Team->Add Work Item->Feature

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

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

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

Детальная информация тестового сценария определяется в Microsoft Test and Lab Manager

Спецификация системных требований

Системные требования представляют собой те требования, для которых команда будет выполнять разработку и реализацию. В MSF для CMMI они представлены рабочим элементом Требование (Requirement), который представляет собой функциональные и нефункциональные требования. Их разграничение определяется путем выбора конкретного атрибута типа требования рабочего элемента. В MSF для Agile, рабочий элемент Пользовательское описание функциональности (User Story) представляет собой функциональные требования, а также нефункциональные требования. В предыдущем выпуске шаблонов процессов рабочий элемент «Качество обслуживания» (Quality of Service) представлял нефункциональные требования. Причиной консолидации является согласованное более тесное взаимодействие метафоры пользовательского описания функциональности многих гибких методов. Пользовательское описание функциональности представляет собой «нечто, что должно быть выполнено».

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

  • В ходе анализа каждой возможности, определите каждое из системных требований, которые должны быть реализованы и опишите их. Выберите Возможность, для которого вы выполняете анализ. Выберите вкладку «Связи», затем выберите значок инструмента «Добавить новый связанный рабочий элемент …». Откроется диалоговое окно для создания связанного рабочего элемента. Выберите «Дочерний» как тип ссылки и Пользовательское описание функциональности (при использовании MSF для Agile) или Требование (при использовании MSF для CMMI) как тип рабочего элемента. Обратите внимание на визуализацию связей представленных в нижней части диалогового окна. Тип связь реализации отличается от связи тестового сценария, показанной ранее. Для дополнительной информации о новых типах связей представленных в Team Foundation Server 2010 смотрите раздел Трассировка и Отчетность.

Заметьте также, что на этом рисунке требование к системе (в данном случае пользовательская история) показано как дочерняя ссылка. Тест, который мы создали для этой возможности, показан как тип Тестируется. Эта новая таксономия обеспечивает более эффективное анализ и представление выполнения работ.

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

Спецификация реализации

Реализация выполняется командой набором задач, которые направлены на разработку исходного кода и юнит-тестов, тестовых сценариев и скриптов, документации или других поставок, которые направлены на достижение цели и завершения проекта. Тип связи Реализация – это типа связи, который используется для описания результатов анализа реализации; анализ направлен на определение задач и их оценки. Мы использовали связь реализации выше, когда указывали системные требования для возможности системы. Это отображается как «дочерние». На самом деле, есть две части для типа связи реализации: дочерний для рабочего элемента, что будет реализовываться, и родительский для требования, что представляет реализацию. Независимо от определений, типы связей позволяют визуализировать иерархию требования как родительский <- -> дочерний <- -> дочерний <- -> т.д. рабочий элемент в преставлении выборки рабочих элементов в виде дерева иерархии.

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

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

  1. Опишите детали для каждого системного требования в поле «Описание» в виде текста. Иногда этого достаточно для ясности, но зачастую наши требования могут стать настолько сложными, что для их ясности нужно будет формировать графики, длинные описания и сценарии. По этой причине, следующий пункт описывает более эффективный механизм для подробного описания.
  2. Опишите подробные требования к системе в виде отдельного файла. Если детализация выполнена в UML, то UML проект в Visual Studio будет полезен для этих целей. Посмотрите раздел Анализа и декомпозиции для более детальной информации для создания UML конструкций к конкретным требованиям. Visual Studio для архитектора обеспечивает механизмы для создания диаграмм сценариев использования, диаграмм деятельности и диаграмм последовательности. Возможности Sketchflow обеспечивают механизм для проектирования структурной раскадровки и веб-реализаций. Затем с помощью Word, Excel, PowerPoint можно обеспечить более подробное описание системных требований. Один из наиболее популярных видов являются Пользовательское описание функциональности или Сценарий использования, которые добавляют подробное описание «потока событий». Сохраните документ в библиотеку документов для командного проекта и затем свяжите его SharePoint URL с требованием, используя тип связи «гиперссылку».

Заключение

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

<<Содержание

Posted in Microsoft, Requirements Management Guidance, Team Foundation Server, Visual Studio | Отмечено: , , , , , , , , | Leave a Comment »

 
%d такие блоггеры, как: