Инспекция Фэгана

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

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

• 1 Примеры
• 2 Использование
  • 2.1 Критерии
  • 2.2 Типовые операции
  • 2.3 Последующие действия
• 3 роли
• 4 Преимущества и результаты
• 5 Улучшения
• 6 Ссылки

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

• Спецификация требований
• Архитектура программного обеспечения / информационной системы (например, DYA)
• Программирование (например, для итераций в XP или DSDM )
• Тестирование программного обеспечения (например, при создании тестовых сценариев))

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

Критерии

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

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

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

Типовые операции

Типичная проверка Фагана состоит из следующих операций:

• Планирование
  • Подготовка материалов
  • Организация участников
  • Организация места встречи
• Обзор
  • Групповое обучение участников по рассматриваемым материалам
  • Распределение ролей
• Подготовка
  • Участники рассматривают предмет для проверки и вспомогательные материалы для подготовки к встрече, отмечая любые вопросы или возможные дефекты
  • Участники готовят свои роли
• Инспекционное собрание
  • Фактическое обнаружение дефекта
• Доработка
  • Доработка - это этап проверки программного обеспечения, на котором обнаруживаются дефекты, обнаруженные во время инспекционного собрания. решается автором, дизайнером или программистом. На основе списка дефектов низкоуровневый документ корректируется до тех пор, пока не будут выполнены требования высокоуровневого документа.
• Последующие действия
  • На последующем этапе проверки программного обеспечения все дефекты обнаруженные на инспекционном совещании должны быть исправлены (так как они были исправлены на этапе доработки). Модератор отвечает за проверку того, что это действительно так. Они должны удостовериться, что все дефекты исправлены и не добавлены новые дефекты, пытаясь исправить первоначальные дефекты. Крайне важно исправить все дефекты, так как затраты на их исправление на более позднем этапе проекта могут быть в 10-100 раз выше, чем текущие затраты.

Последующие действия

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

Если проверка не удалась, вернитесь к процессу доработки.

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

• Автор / Дизайнер / Кодер: человек, написавший документ низкого уровня
• Читатель: перефразирует документ низкого уровня
• Рецензенты: рассматривает низкоуровневый документ с точки зрения тестирования
• Модератор: отвечает за сеанс проверки, выполняет функции наставника

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

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

На практике крупные корпорации, такие как IBM, сообщают об очень положительных результатах, указывающих на то, что можно найти от 80% до 90% дефектов и достичь экономии ресурсов до 25%.

Хотя метод проверки Фагана оказался очень эффективным, многие исследователи предложили улучшения. Генухтен, например, исследовал использование электронной системы встреч (EMS) для повышения продуктивности встреч с положительными результатами

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