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

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

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

Разновидности обзора программного обеспечения [ править ]

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

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

Различные типы рецензий [ править ]

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

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

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

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

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

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

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

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

Ценность отзывов [ править ]

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

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

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

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

См. также [ править ]

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

Ссылки [ править ]

↑ Перейти обратно: Перейти обратно: ^а ^б Стандарт IEEE . 1028-1997, «Стандарт IEEE для проверок программного обеспечения», пункт 3.5.
^ Вигерс, Карл Э. (2001). Экспертные оценки программного обеспечения: Практическое руководство . Аддисон-Уэсли. п. 14. ISBN 0201734850 .
^ «Стандарт IEEE для проверок и аудита программного обеспечения» . IEEE STD 1028-2008 : 1–53. 15 августа 2008 г. [2008]. дои : 10.1109/IEESTD.2008.4601584 . ISBN 978-0-7381-5768-9 .
^ Фэган, Майкл Э.: «Проверка проектирования и кода для уменьшения ошибок при разработке программ», IBM Systems Journal , Vol. 15, № 3, 1976 г.; «Проверка конструкции программного обеспечения и кода», Datamation , октябрь 1977 г.; «Достижения в области проверок программного обеспечения», IEEE Transactions on Software Engineering , Vol. 12, № 7, июль 1986 г.
^ Чарльз П. Пфлигер, Шари Лоуренс Пфлигер. Безопасность в вычислениях . Четвертое издание. ISBN 0-13-239077-9

[ieee35-1] Перейти обратно: Перейти обратно: ^а ^б Стандарт IEEE . 1028-1997, «Стандарт IEEE для проверок программного обеспечения», пункт 3.5.

[2] Вигерс, Карл Э. (2001). Экспертные оценки программного обеспечения: Практическое руководство . Аддисон-Уэсли. п. 14. ISBN 0201734850 .

[3] «Стандарт IEEE для проверок и аудита программного обеспечения» . IEEE STD 1028-2008 : 1–53. 15 августа 2008 г. [2008]. дои : 10.1109/IEESTD.2008.4601584 . ISBN 978-0-7381-5768-9 .

[MFaganPapers-4] Фэган, Майкл Э.: «Проверка проектирования и кода для уменьшения ошибок при разработке программ», IBM Systems Journal , Vol. 15, № 3, 1976 г.; «Проверка конструкции программного обеспечения и кода», Datamation , октябрь 1977 г.; «Достижения в области проверок программного обеспечения», IEEE Transactions on Software Engineering , Vol. 12, № 7, июль 1986 г.

[5] Чарльз П. Пфлигер, Шари Лоуренс Пфлигер. Безопасность в вычислениях . Четвертое издание. ISBN 0-13-239077-9

[1]

[2]

[3]

[4]

[5]