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

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

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

Примеры

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

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

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

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

Критерии

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

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

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

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

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

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

Следовать за

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

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

Роли

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

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

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

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

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

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

Улучшения

Хотя метод проверки Фэгана оказался очень эффективным, ^{[ нужна ссылка ]} улучшения были предложены многими исследователями. М. Генухтен ^[5] например, исследовал использование электронной системы совещаний (EMS) для повышения продуктивности встреч с положительными результатами. ^[6]

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

Ссылки

^ Перейти обратно: ^а ^б Фэган, Мэн (1976). «Проверки дизайна и кода для уменьшения ошибок при разработке программ». IBM Systems Journal . 15 (3): 182–211. дои : 10.1147/sj.153.0182 . ISSN 0018-8670 .
^ Перейти обратно: ^а ^б ^с ^д ^и Фэган, Майкл Э. (2001) [1986]. «Достижения в области проверок программного обеспечения». Пионеры и их вклад в разработку программного обеспечения . стр. 335–360. дои : 10.1007/978-3-642-48354-7_14 . ISBN 978-3-540-42290-7 .
^ МЭ, Фэган (1976). «Проверки дизайна и кода для уменьшения ошибок при разработке программ» (PDF) . IBM Systems Journal . 15 (3): 182–211. дои : 10.1147/sj.153.0182 .
^ Эйкельманн, Н.С.; Руффоло, Ф; Байк, Дж; Анант, А (2003). «Эмпирическое исследование модификации процесса проверки Фэгана и вытекающих из этого основных эффектов и эффектов взаимодействия между обнаруженными дефектами, требуемыми усилиями, скоростью подготовки и проверки, количеством членов команды и качеством первого прохода продукта». 27-й ежегодный семинар НАСА по разработке программного обеспечения Годдарда / IEEE, 2002 г. Материалы . п. 58. дои : 10.1109/SEW.2002.1199450 . ISBN 978-0-7695-1855-8 . S2CID 114935466 .
^ https://ieeexplore.ieee.org/author/37621969200 ^{[ только URL ]}
^ Генухтен, М; Корнелиссен, В; Ван Дейк, C (зима 1997–1998 гг.). «Поддержка проверок с помощью системы электронных встреч». Журнал информационных систем управления . 14 (3): 165–179. дои : 10.1080/07421222.1997.11518179 .
^ Дулан, Е.П. (февраль 1992 г.). «Опыт использования метода проверки Фэгана». Программное обеспечение: практика и опыт . 22 (2): 173–182. дои : 10.1002/спе.4380220205 . S2CID 942973 .

Рон Радис, Высококачественные и недорогие проверки программного обеспечения, Издательство Paradoxicon (21 сентября 2001 г.)

[Fagan_1976_182–211-1] Перейти обратно: ^а ^б Фэган, Мэн (1976). «Проверки дизайна и кода для уменьшения ошибок при разработке программ». IBM Systems Journal . 15 (3): 182–211. дои : 10.1147/sj.153.0182 . ISSN 0018-8670 .

[fagan86-2] Перейти обратно: ^а ^б ^с ^д ^и Фэган, Майкл Э. (2001) [1986]. «Достижения в области проверок программного обеспечения». Пионеры и их вклад в разработку программного обеспечения . стр. 335–360. дои : 10.1007/978-3-642-48354-7_14 . ISBN 978-3-540-42290-7 .

[3] МЭ, Фэган (1976). «Проверки дизайна и кода для уменьшения ошибок при разработке программ» (PDF) . IBM Systems Journal . 15 (3): 182–211. дои : 10.1147/sj.153.0182 .

[4] Эйкельманн, Н.С.; Руффоло, Ф; Байк, Дж; Анант, А (2003). «Эмпирическое исследование модификации процесса проверки Фэгана и вытекающих из этого основных эффектов и эффектов взаимодействия между обнаруженными дефектами, требуемыми усилиями, скоростью подготовки и проверки, количеством членов команды и качеством первого прохода продукта». 27-й ежегодный семинар НАСА по разработке программного обеспечения Годдарда / IEEE, 2002 г. Материалы . п. 58. дои : 10.1109/SEW.2002.1199450 . ISBN 978-0-7695-1855-8 . S2CID 114935466 .

[5] ttps://ieeexplore.ieee.org/author/37621969200 ^{[ только URL ]}

[6] Генухтен, М; Корнелиссен, В; Ван Дейк, C (зима 1997–1998 гг.). «Поддержка проверок с помощью системы электронных встреч». Журнал информационных систем управления . 14 (3): 165–179. дои : 10.1080/07421222.1997.11518179 .

[7] Дулан, Е.П. (февраль 1992 г.). «Опыт использования метода проверки Фэгана». Программное обеспечение: практика и опыт . 22 (2): 173–182. дои : 10.1002/спе.4380220205 . S2CID 942973 .

[1]

[2]

[3]

[4]

[5]

[6]

[7]