Обзор программного обеспечения

Обзор программного обеспечения — это «процесс или встреча, в ходе которой программный продукт изучается персоналом проекта, менеджерами, пользователями, клиентами, представителями пользователей или другими заинтересованными сторонами для получения комментариев или одобрения» ^{[1] .}

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

Обзоры программного обеспечения можно разделить на три категории:

• Экспертные оценки программного обеспечения проводятся одним или несколькими коллегами автора для оценки технического содержания и/или качества работы. ^[2]
• Представители руководства проводят обзоры управления программным обеспечением для оценки состояния выполненной работы и принятия решений относительно последующих действий.
• Аудиты программного обеспечения проводятся внешним персоналом, не участвующим в проекте по разработке программного обеспечения, для оценки соответствия спецификациям, стандартам, договорным соглашениям или другим критериям.

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

«Формальность» определяет степень, в которой деятельность регулируется согласованными (письменными) правилами. Процессы обзора программного обеспечения существуют в спектре формальности, с относительно неструктурированными действиями, такими как «проверка товарищей» на одном конце спектра, и более формальными подходами, такими как пошаговые инструкции, технические обзоры и проверки программного обеспечения, на другом. IEEE Std. 1028-1997 определяет формальные структуры, роли и процессы для каждого из последних трех («формальные экспертные оценки»), вместе с аудитами программного обеспечения . ^[1] IEEE 1028-1997 был заменен IEEE 1028-2008. ^[3]

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

IEEE 1028 определяет общий набор действий для «формальных» обзоров (с некоторыми вариациями, особенно для аудита программного обеспечения). Этот стандарт применяет различия между обзором руководства , техническим обзором , инспекцией , сквозным просмотром , аудитом и т. д.

Предусмотренная последовательность стандартных действий в значительной степени основана на процессе проверки программного обеспечения, первоначально разработанном в IBM Майклом Фейганом . ^[4] Различные типы проверки могут применять эту структуру с разной степенью строгости, но все действия являются обязательными для проверки:

• 0. [Оценка вступительного экзамена]: Руководитель проверки использует стандартный контрольный список критериев вступительного экзамена, чтобы гарантировать наличие оптимальных условий для успешного прохождения проверки.
• 1. Подготовка руководства: Ответственное руководство гарантирует, что обзор будет надлежащим образом обеспечен персоналом, временем, материалами и инструментами и будет проводиться в соответствии с политиками, стандартами или другими соответствующими критериями.
• 2. Планирование обзора: руководитель обзора определяет или подтверждает цели обзора, организует группу обзорщиков и обеспечивает, чтобы группа была оснащена всеми необходимыми ресурсами для проведения обзора.
• 3. Обзор процедур рецензирования: Руководитель рецензирования или другое квалифицированное лицо обеспечивает (на собрании, если необходимо), чтобы все рецензенты понимали цели рецензирования, процедуры рецензирования, доступные им материалы и процедуры проведения рецензирования.
• 4. [Индивидуальная] Подготовка: Рецензенты индивидуально готовятся к групповой проверке рецензируемой работы, тщательно проверяя ее на предмет «аномалий» (потенциальных дефектов), характер которых будет зависеть от типа проверки и ее целей.
• 5. [Групповое] рассмотрение: рецензенты встречаются в запланированное время, чтобы объединить результаты своей подготовительной деятельности и прийти к консенсусу относительно статуса рассматриваемого документа (или деятельности).
• 6. Переделка/последующие действия: Автор рабочего продукта (или другое назначенное лицо) предпринимает все необходимые действия для исправления дефектов или иного удовлетворения требований, согласованных на экзаменационном совещании. Руководитель проверки проверяет, что все пункты действий закрыты.
• 7. [Выходная оценка]: Руководитель проверки проверяет, что все мероприятия, необходимые для успешной проверки, выполнены и что все результаты, соответствующие типу проверки, были завершены.

Наиболее очевидная ценность обзоров программного обеспечения (особенно формальных обзоров) заключается в том, что они могут выявлять проблемы раньше и с меньшими затратами, чем при тестировании или использовании в полевых условиях («процесс обнаружения дефектов») ^{[ требуется цитата ]} . Стоимость поиска и исправления дефекта при хорошо проведенном обзоре может быть на один или два порядка меньше, чем при обнаружении того же дефекта при выполнении теста или в полевых условиях. ^{[ требуется цитата ]}

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

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

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

• Качество программного обеспечения
• Список философий разработки программного обеспечения