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