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

Fagan inspection

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

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

Примеры

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

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

использование

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

Критерии

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

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

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

Типичные операции

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

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

Следовать за

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

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

Роли

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

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

Преимущества и результаты

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

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

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

Улучшения

Хотя метод проверки Фэгана оказался очень эффективным,[нужна цитата] улучшения были предложены несколькими исследователями. Genuchten[ВОЗ?] например, исследовал использование Электронная система встреч (EMS) для повышения продуктивности встреч с положительными результатами [5]

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

Рекомендации

  1. ^ а б Фэган, М. Э. (1976). «Проверка дизайна и кода для уменьшения ошибок при разработке программ». Журнал IBM Systems. 15 (3): 182–211. Дои:10.1147 / sj.153.0182. ISSN 0018-8670.
  2. ^ а б c d е Фэган, Майкл Э (2001) [1986]. «Достижения в области проверки программного обеспечения» (PDF). Пионеры и их вклад в разработку программного обеспечения. С. 335–360. Дои:10.1007/978-3-642-48354-7_14. ISBN 978-3-540-42290-7.
  3. ^ M.E., Фэган (1976). «Проверка дизайна и кода для уменьшения ошибок при разработке программы» (PDF). Журнал IBM Systems. 15 (3): 182–211. Дои:10.1147 / sj.153.0182.
  4. ^ Эйкельманн, Н. Руффоло, F; Байк, Дж; Анант, А (2003). «Эмпирическое исследование изменения процесса проверки Фэгана и результирующих основных эффектов и эффектов взаимодействия между обнаруженными дефектами, необходимыми усилиями, скоростью подготовки и проверки, количеством членов группы и качеством продукции при первом проходе» 27-й ежегодный семинар NASA Goddard / IEEE Software Engineering Workshop, 2002 г. Труды. п. 58. Дои:10.1109 / SEW.2002.1199450. ISBN 978-0-7695-1855-8.
  5. ^ Генухтен, М; Корнелиссен, Вт; Ван Дейк, К. (зима 1997–1998 гг.). «Сопровождение проверок с помощью электронной системы встреч». Журнал информационных систем управления. 14 (3): 165–179. Дои:10.1080/07421222.1997.11518179.
  6. ^ Дулан, Э. (Февраль 1992 г.). «Опыт работы с методом проверки Фэгана». Программное обеспечение - практика и опыт. 22 (2): 173–182. Дои:10.1002 / spe.4380220205.