Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ТСПП - Основы SWEBOK.doc
Скачиваний:
957
Добавлен:
25.03.2015
Размер:
3 Мб
Скачать
☆

5. Аудит конфигураций (Software Configuration Auditing)

Аудит программного обеспечения – деятельность, выполняемая для независимой оценки программных продуктов и процессов на <формальное> соответствие (conformance) применимым в данном случае инструкциям, стандартам, руководящим документам, планам и процедурам (см. IEEE 1028-97 “Standard for Software Reviews”). Аудиты проводятся в <строгом> соответствии с четко определенными процессами, содержащими и определяющими различные роли аудиторов и из обязанности. Каждый аудит должен быть, в свою очередь, четко спланирован и может требовать привлечения многих специалистов для выполнения различных задач (определяемых процедурой аудита) за достаточно короткий промежуток времени. Автоматизированные средства, обеспечивающие поддержку планирования и проведения аудита, могут существенно облегчить и ускорить этот процесс. SWEBOK отмечает, что рекомендации по проведению аудита можно найти во многих источниках, в том числе, включая стандарт IEEE 1028-97 “Standard for Software Reviews”.

Деятельность по аудиту программных конфигураций определяет степень, в которой элемент <конфигурации> (SCI) удовлетворяет заданным (например, на уровне требований и/или запросов на изменения) функциональным и физическим характеристикам. Неформальный аудит такого типа может быть связан с ключевыми точками жизненного цикла (вехами проекта, в терминах управления проектами - milestones). Существует два достаточно распространенных типа  формального аудита (требуемого определенными категориями контрактов, например, на создание критически-важного программного обеспечения): функциональный аудитконфигураций (Functional Configuration Audit, FCA) ифизический аудитконфигураций (Physical Configuration Audit, PCA). Успешное (в терминах соответствия результатов заданным условиям) завершение этих аудитов  может быть обязательным требованиям для фиксирования базовой линии продукта. В то же время, если сравнивать контекст FCA и PCA для программного и аппаратного обеспечения, перед их выполнением необходимо четко оценивать реальные потребности в таких видах аудита (так как они требуют существенных, иногда, просто “неподъемных” затратах ресурсов, если оценивать их в рамках заданных ограничений проекта).

5.1 Функциональный аудит программных конфигураций (Software Functional Configuration Audit)

Цель FCA состоит в том, чтобы убедиться, что контролируемый программный элемент полностью соответствует заданным спецификациям. “Выход”, то есть результат проверки и аттестации (V&V, verification and validation) программного обеспечения является ключевым “входом” (исходными данными) для проведения этого аудита.

5.2 Физический аудит программных конфигураций (Software Physical Configuration Audit)

Цель PCA состоит в том, чтобы убедиться, что дизайн и документация точно согласуются с самим программным продуктом.

5.3 Внутренние аудиты базовых линий (In-process Audits of Software Baseline)

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