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

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

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

Разновидности обзора ПО

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

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

Различные типы экспертных оценок

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

Формальные и неформальные обзоры

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

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

Общий процесс IEEE 1028 для официальных проверок

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

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

Ценность отзывов

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

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

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

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

Смотрите также

• Программирование без эго
• IEEE 1028-2008

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