Разработка программного обеспечения и систем (стр. 4 )

7.3.3.5        Рецензия на основе сценария

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

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

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

7.3.4        Групповое принятие решений

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

ПРИМЕЧАНИЕ. При определении наиболее квалифицированных членов применяются различные критерии в зависимости от типа рабочего продукта и цели обзора.

Приложение

(Обязательное)

Обзорная документация

A.1 Краткий обзор

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

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

В таблице А.1 приведены нормативные требования к этим статьям для информации, которая уникальна для каждого документа. Примеры каждого из этих типов документов приведены в Приложении B.

Таблица A.1 - Сводная информация о нормативных требованиях к обзорной документации

Информационные элементы (ISO/IEC 20246)	Нормативные требования
A.2  Протокол ошибки
i) Уникальный идентификатор	Должен
ii) Дата и время	Должен
iii) Описание	Должен
iv) Строгость	Должен
v) Состояние проблемы	Должен
vi) Назначение проблемы	Должен
vii) Разрешение проблемы	Может
A.3  Отчет об инциденте
i) Информация о сроках	Должен
ii) Инициатор	Должен
iii) контекст	Должен
iv) Описание инцидента	Должен
v) Строгость	Должен
vi) Приоритет	Должен
vii) Риск	Должен
viii) Статус инцидента	Должен
A.4 Обзорный отчет
i) Описание рабочего продукта	Должен
ii) участники	в случае если
iii) Резюме результатов обзора	Должен
iv) Обзор показателей	Может
v) Оценка рабочего продукта	Должен

A.2 Протокол ошибки

A.2.1 Краткий обзор

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

A.2.2        О конкретном документе

A.2.2.1  Краткий обзор

Эта информация идентифицирует документ и описывает его происхождение и историю.

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

A.2.2.2        Уникальная идентификация документа

Уникально идентифицирует версию документа.

ПРИМЕР Уникальный идентификатор может включать заголовок документа, дату выпуска, версию и / или статус документа (например, черновик, обзор, исправление, окончательный).

A.2.2.3        Организация-эмитент

Указывает организацию, ответственную за подготовку и выпуск документа. Он может также включать автора (ов) и тестера (ов), если они не совпадают.

A.2.2.4        Орган утверждения

Определяет назначенное лицо (лица), которое несет / несет ответственность за рассмотрение и отключение документа (возможно, в электронном виде). Он может также включать рецензентов и соответствующих менеджеров.

A.2.2.5        История изменений

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

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

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

A.2.3 Введение

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

A.2.3.1        Общие положения

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

A.2.3.2        Рекомендации

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

A.2.3.3        Глоссарий

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

ПРИМЕЧАНИЕ. Этот раздел может быть приложением или может ссылаться на другой документ, содержащий общий глоссарий. Все или часть глоссария и / или сокращенного списка могут быть онлайн, в качестве отдельного тестового конкретного глоссария или включены в более крупный организационный глоссарий (включая больше терминов, чем те, которые связаны с тестированием).

A.2.4 Вопросы

A.2.4.1        Краткий обзор

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

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

A.2.4.2        Уникальный идентификатор

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

A.2.4.3        Дата и время

Определяет дату и время, когда проблема была идентифицирована.

A.2.4.4        Описание

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

ПРИМЕЧАНИЕ. Описание проблемы может включать предлагаемое решение.

A.2.4.5        Строгость

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

ПРИМЕЧАНИЕ 1. Артефактом может быть рассматриваемый рабочий продукт или подтверждающая документация, такая как общеорганизационный стандарт.

ПРИМЕЧАНИЕ 2. Суть проблемы может быть использована для перечисления проблем в журнале проблем в порядке приоритетности для адресации.

A.2.4.6        Состояние проблемы

Указывает статус проблемы, которая обычно назначается во время операции «Сообщение о связи и анализ» (см. 6.4.4).

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

A.2.4.7        Назначение проблемы

Указывает, кому была поручена ответственность за решение проблемы.

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

A.2.4.8        Разрешение проблемы

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

ПРИМЕЧАНИЕ. Это может потребоваться, если более подробный анализ проблемы указывает на то, что ранее согласованное действие по рассмотрению было признано неуместным или недостаточным.

A.3 Отчет об инциденте

A.3.1 Краткий обзор

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

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

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

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

ПРИМЕЧАНИЕ 1. Инциденты могут встречаться и сообщаться в других контекстах, например, во время динамического тестирования.

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

A.3.2        Информация о конкретном документе

A.3.2.1        Краткий обзор

Эта информация идентифицирует документ и описывает его происхождение и историю.