Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем

Подождите немного. Документ загружается.

244 Глава 6

На практике процессы верификации и валидации обычно выполняются со-

вместно, начиная с ранних стадий ЖЦ и применительно к установленному множе-

ству рабочих продуктов проекта. Они определены в стандарте раздельно, скорее из

соображений соблюдения «принципа модульности» архитектуры процессов [2, 3].

Подробнее задачи, решаемые при выполнении процессов верификации и ва-

лидации, рассматриваются в п.6.1.2.

Назначение процесса совместного просмотра, в соответствии с ISO/IEC

12207, состоит в том, чтобы «поддерживать должный уровень понимания заказчи-

ком того, как проект продвигается к целям договора, и того, какие именно допол-

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

ботки продукта, который его удовлетворит. Совместные просмотры проводятся как

на уровне управления проектом, так и на техническом уровне, и в течение всего

жизненного цикла проекта. В результате успешного осуществления процесса:

• периодические просмотры будут производиться в заранее определенные

сроки;

• состояние и продукты деятельности процесса будут оцениваться в ходе

выполнения совместного просмотра при участии заказчиков, поставщиков и других

ответственных лиц и пользователей;

• результаты просмотра будут доводиться до всех сторон, которых они ка-

саются;

• мероприятия, решение о выполнении которых принято при просмотрах,

будут отслеживаться до их завершения;

• проблемы будут идентифицироваться и решаться».

В ходе подготовки совместного просмотра должны быть определены сфера

просмотра, темы, участники, график работы и требования к ресурсам, и установле-

ны критерии просмотра. Критерии просмотра касаются способа выявления про-

блемы и ее решения, а также согласования результата просмотра его участниками.

Цель периодических совместных просмотров на уровне управления проектом

– оценить состояние проекта по отношению к утвержденным планам, графикам,

стандартам и руководствам, установить, нет ли необходимости в изменении пла-

нов, правильно ли распределены ресурсы, выполняется ли управление рисками.

Цель периодических совместных просмотров на техническом уровне – оце-

нить состояние рабочих продуктов ПС по отношению к требованиям заказчика и

критериям приемки, зафиксированным в договоре. В ходе технических просмотров

нужно установить, ведется ли разработка рабочих продуктов по плану, соответст-

вует ли степень их завершенности запланированной, соответствуют ли они стан-

дартам и спецификациям, все ли изменения в них вносятся надлежащим образом и

касаются только тех областей, которые определены процессом управления конфи-

гурацией.

Цель внутренних периодических совместных просмотров процесса – оценить

его состоятельность и пригодность для проекта.

Проблемы, обнаруженные при просмотре, упорядочиваются по степени серь-

езности для проекта и фиксируются в отчете наряду с предлагаемыми мероприя-

тиями по их решению. Отчет направляется на согласование всем участникам про-

смотра и затем передается процессу решения проблем. Выполнение мероприятий

контролируется.

Глава 6 245

Назначение процесса аудита, согласно ISO/IEC 12207, состоит в «независи-

мом установлении соответствия выбранных продуктов и процессов требованиям,

планам и договору. В результате успешного осуществления процесса:

• будет разработана и внедрена стратегия аудита;

• аудиты будут проводиться;

• согласованность выбранных рабочих продуктов ПС и/или услуг или про-

цессов с требованиями, планами и договором будет устанавливаться в соответствии

со стратегией аудита;

• проведение аудитов пригодной для этого независимой стороной будет ор-

ганизовано;

• проблемы, обнаруженные во время аудита, будут идентифицированы, до-

ведены до тех, кто несет ответственность за мероприятия по корректировке, и ре-

шены».

Стандарт определяет рабочие продукты и результаты деятельности по про-

цессам ЖЦ, подлежащие аудиту:

– соответствие кода программного продукта проектной документации;

– адекватность требований к приемочным просмотрам и испытаниям, за-

фиксированных в документации, приемке программного продукта;

– соответствие тестовых данных спецификации;

– успешность испытаний программного продукта и его соответствие специ-

фикации;

– корректность отчетов об испытаниях;

– устранение расхождений между фактическими и ожидаемыми результа-

тами;

– соответствие документации пользователя установленным стандартам;

– соответствие выполненных действий применимым к ним требованиям,

планам и договору;

– соответствие затрат и сроков плановым.

Аудит проводится в заранее установленные сроки. При подготовке плана ау-

дита устанавливается сфера применения аудита, темы, участники, критерии начала

и завершения аудита, график и нужные ресурсы.

Кроме аудитов разработки ПС могут также проводиться аудиты управления

проектом и аудиты выполнения процессов, с целью определения их состоятельно-

сти и пригодности для проекта.

По результатам аудита составляется аудиторский отчет. В нем фиксируются

проблемы, обнаруженные в процессе аудита, и предлагаемые мероприятия по их

решению. Отчет распространяется среди участников аудита и направляется процес-

су решения проблем. Выполнение мероприятий контролируется.

Каждый из рассмотренных выше процессов должен синхронизироваться с

основными процессами ЖЦ, для проверки рабочих продуктов которых он подклю-

чается (в контрольных точках проекта), и координироваться с процессом SQA от-

носительно видов и способов проверок.

Уровень и масштаб планирования и выполнения проверок варьируется в за-

висимости от особенностей ПС и условий ее разработки – выбранной модели ЖЦ,

исходных требований к ПС, используемых организационных подходов и процедур,

размера, критичности и типа ПС, количества персонала проекта и участвующих в

проекте сторон. Эти факторы определяют, какие из пяти процессов поддержки ка-

246 Глава 6

чества будут включены в модель процессов ЖЦ проекта в виде отдельных процес-

сов, и какие задачи из других процессов будут дополнительно в них решаться. Так,

в простейшем случае, для проекта может быть выбран, например, только процесс

SQA, в который включены задачи процесса совместного просмотра, а процессы

верификации и валидации, а также аудита – не использоваться. Однако для круп-

ных проектов разработки критических ПС могут понадобиться и независимая ве-

рификация и валидация (IV&V), и периодические совместные просмотры, и ауди-

торские проверки третьей стороной.

Упомянутые выше факторы обусловливают и выбор методов для решения

задач в рассматриваемых процессах – в зависимости от специфики проекта и тре-

бований к продукту проверки могут быть индивидуальными или коллективными,

проводиться коллегами по проекту или независимыми экспертами и отличаться

формой организации работ. Одни и те же методы могут использоваться в разных

процессах. Стандарт ISO/IEC 12207 указывает лишь на то, ЧТО (какие действия)

должны выполняться в рамках процессов, но не на то, КАК (какими методами) их

выполнять. Часто возникает путаница из-за наличия одноименных процессов и ме-

тодов, а также неточности перевода отдельных терминов. Так, процесс верифика-

ции иногда связывают исключительно с методом формальной верификации (дока-

зательством корректности), а процесс совместного просмотра (joint review) путают

с методом коллегиальной проверки (peer review) или технического обзора (technical

review). Эти и другие статические методы выполнения проверок в различных про-

цессах поддержки подробно рассматриваются в разделах 6.2 и 6.3, а динамические

методы проверки – методы тестирования – в главе 7.

Рассматриваемые в этой главе методы проверки регламентируются следую-

щими стандартами

• IEEE Std. 1012 «IEEE Standard for Software Verification and Validation»

(стандарт 1998 года). Это новая редакция стандарта 1986 года «IEEE Standard for

Software Verification and Validation Plans»,

• IEEE Std. 1059 «IEEE Guide for Software Verification and Validation Plans»

(стандарт 1993 года),

• IEEE Std. 1012a «Supplement to IEEE Standard for Software Verification and

Validation: Content Map to IEEE/EIA 12207.1-1997»,

• IEEE Std. 1028 «IEEE Standard for Software Reviews» (стандарт 1997 года).

Новая редакция стандарта 1988 г. «IEEE Standard for Software Reviews and Audits».

6.1.2. Цели и задачи верификации и валидации

Роль процессов верификации и валидации заключается в выполнении про-

верки и оценивании состояния рабочих продуктов ПС на протяжении процесса раз-

работки

с целью своевременного выявления проблем проекта.

Часто встречаются ссылки на разные редакции стандартов IEEE, а также на уже

отмененные стандарты. Справку о статусе стандартов IEEE можно получить по адресу в

Интернете: http://standards.ieee.org/db/status/.

Вообще говоря, V&V может применяться на протяжении всего ЖЦ ПС и привле-

каться для проверки рабочих продуктов процессов приобретения, поставки, разработки,

эксплуатации и сопровождения. Однако далее рассматриваются в основном задачи V&V

для процесса разработки.

Глава 6 247

В то время как SQA в большей степени акцентирует внимание на проверке

соблюдения стандартов и действенности процессов, V&V сосредотачивается на

технических аспектах разработки, отраженных в документах или компонентах ПС

(договоре, исходных требованиях, проекте, коде, интегрированной ПС).

Цель V&V – проверить и подтвердить, что требования, предъявляемые к ПС,

являются полными, точными, согласованными, корректно установленными и тес-

топригодными, а программные рабочие продукты - корректно их реализуют.

Процессы V&V оценивают элементы программного обеспечения в контек-

сте системы, частью которой оно является, с учетом требований со стороны опе-

рационного окружения (среды эксплуатации), технических средств (hardware), ин-

терфейсов, обслуживающего персонала системы и непосредственных пользовате-

лей программных продуктов.

Состав объектов проверки, критериев проверки, задач V&V, а также интен-

сивность и тщательность выполнения процессов V&V определяется уровнем цело-

стности разрабатываемой системы (уровнями критичности ее компонентов).

Связь и отличие процессов верификации и валидации. Суть отличий про-

цессов верификации и валидации удобнее сформулировать применительно к кас-

кадной модели ЖЦ и традиционным стадиям разработки программного обеспече-

ния систем (определение концепции, анализ требований, проектирование, реализа-

ция (построение), интеграция и тестирование, ввод в действие (инсталляция)).

Верификация означает проверку соответствия конкретных выходных рабочих

продуктов каждой стадии требованиям к ним, установленным на предыдущей ста-

дии. Оценивается корректность, полнота и точность реализации требований, а так-

же приверженность действующим стандартам и нормам передовой практики. Ве-

рификация выполняется с целью своевременного обнаружения и устранения допу-

щенных ошибок и обеспечения руководства проекта объективными сведениями,

необходимыми для управления риском проекта. Результаты верификации служат

базисом для оценки завершенности текущей стадии и принятия решения о переходе

к следующей стадии проекта.

Валидация означает подтверждение того, что (те же) рабочие продукты ПО

удовлетворяют системным требованиям, делегированным ПО (то есть, той части

требований к системе, которая будет реализована программными продуктами), и

отвечают потребностям системы (например, алгоритмы корректно моделируют фи-

зические законы системы; или, модели данных, функций, состояний и процессов

адекватны деловым процессам банковской системы).

Если бы исходные требования к программному обеспечению системы полно-

стью охватывались в начале проекта и были неизменны (что и предполагается при

выборе каскадной модели разработки), процесс валидации можно было бы связы-

вать только с исходными требованиями, тестами и конечным программным про-

дуктом. В этом случае было бы оправданным бытующее мнение о том, что валида-

ция отождествляется с тестированием при приемочных испытаниях. Однако, на

практике, требования изменяются по ходу разработки. Да и современные CASE-

среды позволяют сохранять и «тестировать» (трассировать к исходным требовани-

ям) промежуточные продукты разработки.

Таким образом, и верификация, и валидация необходимы и возможны на всех

стадиях создания ПО. Вопрос состоит только в правильном оценивании уровня це-

лостности ПО и надлежащего объема V&V.

248 Глава 6

V&V поддерживает основные процессы ЖЦ и, как указывается в стандарте

IEEE Std. 1012, «наиболее эффективна, когда применяется параллельно с процесса-

ми разработки ПО; в противном случае цели V&V могут не быть достигнуты. В

этом стандарте процессы V&V рассматриваются совместно, поскольку их действия

и задачи пересекаются и взаимно дополняют друг друга» [4]. Должен быть опреде-

лен круг основных процессов в проекте, с которыми будет ассоциироваться V&V, и

для них выбрано минимально необходимое множество задач проверки, определяе-

мое уровнем целостности, установленным для программного обеспечения системы.

Уровни целостности программного обеспечения. Уровни целостности ПО

системы связываются с диапазоном значений критических характеристик ПО (на-

дежности, безопасности функционирования, защиты информации, производитель-

ности, сложности и др.), которые позволяют удерживать риски в приемлемых пре-

делах. Критическое высокоцелостное ПО требует V&V, большей по объему и стро-

гости, чем не критическое.

Уровни целостности могут назначаться для требований к программному

обеспечению, функций, групп функций, программных компонентов или подсистем

на самых ранних стадиях проекта, согласовываться всеми заинтересованными сто-

ронами и изменяться по мере эволюции разработки в связи с выбором организаци-

ей-разработчиком или заказчиком определенных стратегий и методологий разра-

ботки и управления риском. Контроль и изменение уровня целостности – задача

анализа критичности (V&V criticality analysis) в ходе процесса разработки.

Стандарт использует 4-уровневую схему целостности ПО как метод для оп-

ределения минимума задач V&V в рамках уровня (таблица 6.1).

Таблица 6.1. Уровни целостности ПО

Критичность Описание Уровень

Высокая Выбранная функция служит критическим фактором для эф-

фективной работы системы

Большая Выбранная функция важна для эффективной работы системы 3

Умеренная Выбранная функция влияет на работу системы, но могут быть

реализованы стратегии обхода для компенсации потери эф-

фективности

Низкая Выбранная функция вносит существенный вклад в работу

системы. Если она не будет выполняться надлежащим обра-

зом, пользователь испытает неудобства

Если уровень целостности ПС или отдельных компонентов программного

обеспечения системы ниже первого, применение V&V для них необязательно.

Ассоциация поуровневой схемы целостности с минимумом задач V&V опи-

сывается в Плане верификации и валидации (SVVP) (от Software Verification and

Validation Plan), а обоснование назначения определенных уровней целостности

проверяемым компонентам ПО - в Отчете о задаче V&V и в Заключительном от-

чете о V&V.

Нужно заметить, что предыдущая редакция стандарта IEEE Std. 1012 (1986

года) была «продукто-ориентированной»

и определяла структуру и содержание

Это касается и большинства стандартов IEEE по программной инженерии, вышед-

ших до 1996 года (то есть до появления ISO/IEC 12207) и теперь пересмотренных.

Глава 6 249

SVVP. Ныне действующий стандарт (1998 года) поддерживает процессо-

ориентированный подход к разработке ПС и определяет процессы V&V в терминах

действий и задач, а также устанавливает требования к управлению V&V, плану

SVVP и отчетным документам.

Задачи V&V на стадиях разработки программной системы. В стандарте

IEEE Std. 1012 приведен перечень и описание минимального набора задач V&V для

всех основных процессов и уровней целостности программного обеспечения сис-

тем. На рисунке 6.1 показаны только задачи процесса разработки наряду с входя-

щей информацией для их решения (входами V&V) и исходящей информацией –

результатом их решения (выходами V&V), а в таблице 6.2 кратко описаны те же

задачи с указанием номеров уровней целостности ПО, на которых они решаются.

Учитывая то, что задачи по V&V, которые должны решаться для ПС с низкой

критичностью (первый уровень целостности), представляют наиболее широкий ин-

терес, мы рассматриваем их далее подробнее.

Задачи верификации и валидации требований к ПС с низкой критично-

стью. Требования к ПС отражаются в документах описания концепции ПС, специ-

фикации требований к ПС, а также спецификации требований к интерфейсам ПС

В ходе рассмотрения этих документов решаются две задачи верификации и валида-

ции: оценка требований к ПС и создание/верификация плана тестирования для

V&V системы.

Оценка требований к ПС заключается в анализе всех видов требований с це-

лью проверки и подтверждения их корректности, согласованности, полноты, точ-

ности, читабельности и тестопригодности.

Подтверждение корректности требований к ПС должно быть основано на:

– проверке, правильно ли распределены функции ПС по компонентам обще-

системного и специального (разрабатываемого) программного обеспечения, и

удовлетворяют ли они требования заказчика к ПС;

– проверке, согласуются ли требования к ПС с действующими в отрасли

стандартами, нормами, положениями и правилами ведения бизнеса;

– анализе логики событий и потоков данных в деловом процессе и подтвер-

ждении, что последовательности смены состояний системы отвечают принципам,

действующим в проблемной области, и другим нормам;

– проверке, удовлетворяют ли описания потоков данных и управления в ПС

требованиям к ее функциям и производительности

;

– проверке правильности использования (обработки) данных и их форматов.

Структура и содержание документов описания требований к ПС могут регламенти-

роваться, например, стандартами IEEE Std. 830, IEEE Std. 1233, ГОСТ 34.602.

Сложившаяся практика, к сожалению такова, что описание деловых процессов, по-

токов управления и форматов данных выполняется лишь на стадии технического проекти-

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

Действия по V&V

концепции

Действия по V&V

требований

Действия по V&V

проекта

Действия по V&V

реализации

Действия по V&V

испытаний

Действия по V&V

инсталляции и пуску

Документы принятой

концепции

Спецификация треб. к ПО

Спецификация требований к

интерфейсам

Отчет о критичности задачи

Документация пользователя

План испытаний системы

План приемочных испытаний

Документация процесса

упр. конфигурацией ПО

Отчет об анализе угроз

Планы и графики разработки

Рез. решения задач V&V

Описание концепции

системы

Планы и графики

разработки

Потребности

пользователей

Потребности заказчика

Назначение уровней

целостности

Отчет об анализе угроз

Результаты решения

задач V&V

Входы V&V Входы V&V Входы V&V

Спецификация треб. к ПО

Описание проекта ПО

Спецификация требований

к интерфейсам

Документ проекта

интерфейса

Стандарты проектирования

Документация концепции

Отчет о критичности задачи

Проекты и планы испытаний

Документация пользователя

Отчет об анализе угроз

Планы и граф. разработки

Рез. решения задач V&V

Описание проекта ПО

Документ проекта интерф.

Исходный код

Стандарты кодирования

Документация пользователя

Документация концепции

Отчет о критичности задачи

Проекты / наборы тестов

Процедуры тестирования

Результаты тестирования

компонентов

Отчет об анализе угроз

Планы и граф. разработки

Рез. решения задач V&V

Входы V&V

Планы, проекты, наборы и

процедуры тестирования

Описание проекта ПО

Документ проекта

интерфейса

Исходный и

исполнительный код

Документация

пользователя

Результаты тестирования

компонентов

Отчет об анализе угроз

Планы и граф. разработки

Рез. решения задач V&V

Входы V&V Входы V&V

Пакет инсталляции

Документация пользователя

Отчет об анализе угроз

Планы и графики разработки

Результаты решения задач

V&V

Итоговые отчеты о

действиях по V&V

Задачи V&V

Оценка документа

концепции

Анализ критичности

Анализ распределения

требований (к ТО / ПО /

пользователю)

Анализ трассируемости

Анализ угроз

Анализ риска

Задачи V&V

Анализ трассируемости

Оценка требований к ПО

Анализ интерфейсов

Анализ критичности

Создание / верификация

плана тестирования для

V&V системы (С)

Создание / верификация

плана тестирования для

V&V приемки (П)

Оценивание состояния

управления конфигурацией

Анализ угроз

Анализ риска

Задачи V&V

Анализ трассируемости

Оценка проекта ПО

Анализ интерфейсов

Анализ критичности

Создание / верификация

плана тестирования для

V&V компонентов (К)

Создание / верификация

плана тестирования для

V&V интеграции (И)

Создание / верификация

проектов тестов для V&V

Анализ угроз

Анализ риска

Анализ трассируемости

Оценка исходного кода и

документации исходного кода

Анализ интерфейсов

Анализ критичности

Создание / верификация

тестовых наборов для V&V

Создание / верификация

тестовых процедур для V&V

Выполнение / верификация

тестов компонентов

Анализ угроз

Анализ риска

Задачи V&V

Анализ трассируемости

Создание / верификация

тестовых процедур для

V&V приемки

Выполнение/верификация

тестов для V&V интеграции

Выполнение / верификация

тестов для V&V системы

Выполнение / верификация

тестов для V&V приемки

Анализ угроз

Анализ риска

Задачи V&V

Аудит инсталляционной

конфигурации

Пробный пуск

Анализ угроз

Анализ риска

Генерация заключительного

отчета о V&V

Выходы V&V

Отчеты о задачах

Отчеты об аномалиях

Наборы тестов для V&V

К / И / С / П

Процедуры тестирования для

V&V К / И / С

Выходы V&V

Отчеты о задачах

Отчеты об аномалиях

Планы тестирования для V&V

К / И

Проекты тестов для V&V

К / И / С / П

Выходы V&V

Отчеты о задачах

Отчеты об аномалиях

Планы тестирования для

V&V системы/приемки

Выходы V&V

Отчеты о задачах

Отчеты об аномалиях

Отчеты о задачах

Отчеты об аномалиях

Процедуры тестирования

для V&V приемки

Выходы V&V

Отчеты о задачах

Отчеты об аномалиях

Заключительный отчет

о V&V

Рис. 6.1.

Задачи V&V для процессов разработки

Глава 6 251

Таблица 6.2. Характеристика задач V&V

Задача Описание задачи Уровни

Анализ кри-

тичности

Задача выполняется в составе работ по V&V концепции,

требований, проекта и реализации ПО системы.

Проверяется корректность назначения уровней целост-

ности требованиям, функциям, подсистемам, модулям ПО.

Если частные уровни целостности не назначены – присваи-

вается уровень целостности, назначенный системным тре-

бованиям. Если какому-либо компоненту назначен самый

высокий уровень критичности, всем «влияющим» на него

компонентам присваивается тот же уровень. Уровни цело-

стности документируются в отчете о выполнении V&V.

При каждой последующей проверке отчет пересматрива-

ется и обновляется по результатам анализа новых докумен-

тов (описания требований, описания проекта и др.).

4, 3, 2

Анализ рас-

пределения

системных

требований

Задача выполняется в составе работ по V&V концепции.

Проверяется корректность, точность и полнота распреде-

ления системных требований по компонентам технического

и программного обеспечения, а также пользовательским

интерфейсам в контексте требований пользователей.

Проверяется, обеспечит ли схема распределения нужную

производительность работы, удовлетворяют ли форматы

данных, частота и протоколы передачи информации поль-

зовательским требованиям к интерфейсам, предусмотрены

ли механизмы обеспечения отказоустойчивости и восста-

навливаемости приложений, отражены ли требования поль-

зователей к сопровождению системы.

Анализ про-

слеживаемости

Задача выполняется в составе работ по V&V концепции,

требований, проекта, реализации и испытаний ПО.

Изначально в документе описания концепции идентифи-

цируются все системные требования, которые полностью

или частично будут реализованы программно. Проверяется,

прослеживаются ли системные требования к требованиям

заказчика. Критерий прослеживаемости – корректность,

согласованность в деталях, полнота и точность отражения

требований заказчика в требованиях к системе.

На последующих стадиях разработки проверяется, соот-

ветственно, прослеживаются ли требования к ПО к сис-

темным требованиям (при V&V требований), элементы

проекта ПО к требованиям к ПО (при V&V проекта), ком-

поненты исходного кода к соответствующим специфика-

циям в проекте и наоборот (при V&V реализации), а все

тестовые процедуры – к планам тестирования (при

V&Vиспытаний).

4, 3, 2

Анализ угроз Задача выполняется в составе работ по V&V концепции,

требований, проекта, реализации, испытаний и ввода в

действие ПО системы.

Изначально по документу описания концепции опреде-

ляется, существуют ли потенциальные угрозы системе или

со стороны системы.

4, 3

252 Глава 6

Задача Описание задачи Уровни

Оценивается вероятность появления каждой угрозы и ее

серьезность, идентифицируются стратегии устранения уг-

роз. Составляется отчет об анализе угроз. При последую-

щих проверках уточняется, какие требования к ПО (проект-

ные решения, особенности реализации) вносят вклад в каж-

дую из ранее обнаруженных угроз.

Анализ риска Задача выполняется в составе работ по V&V концепции,

требований, проекта, реализации, испытаний и ввода в

действие ПО системы.

Изначально по документу описания концепции, планам-

графикам разработки и отчету об анализе угроз идентифи-

цируются технические риски, а также риски управления

проектом. Даются рекомендации по устранению, снижению

или наблюдению рисков. Составляется отчет об их анализе.

При последующих проверках анализ рисков возобновля-

ется, риски пересматриваются и даются новые рекоменда-

ции по их устранению, снижению или наблюдению.

4, 3

Анализ интер-

фейсов

Задача выполняется в составе работ по V&V требований,

проекта и реализации ПО системы.

Изначально по документам описания концепции, описа-

ния требований к ПО и описания интерфейсов проверяется

и подтверждается, что требования к интерфейсам ПО с ТО,

пользователем, оператором и другими системами:

- корректны. Правильно определены требования к внеш-

ним и внутренним интерфейсам,

- согласованы. Непротиворечивы описания интерфейсов

в документе спецификации требований и документе специ-

фикаций интерфейсов,

- полны. Описаны форматы данных и критерии произво-

дительности каждого интерфейса,

- точны. Каждый интерфейс обеспечивает передачу ин-

формации с нужной точностью, и

- тестопригодны. Существуют объективные критерии

приемки для подтверждения требований.

При V&V проекта по тем же критериям проверяются все

проектные решения относительно интерфейсов с ТО, ПО,

пользователем, оператором и другими системами.

При V&V реализации по тем же критериям проверяется

и подтверждается правильность программно реализованных

интерфейсов.

4, 3, 2

Оценка доку-

мента описа-

ния концепции

Задача выполняется в составе работ по V&V концепции

ПО системы.

Проверяется, насколько документация концепции удовле-

творяет требования пользователей и соответствует потреб-

ностям заказчика. Подтверждается, что функции системы,

цикл ее использования, степень реализуемости и тестопри-

годности, функциональные требования, концептуальный

проект архитектуры системы, требования к эксплуатации и

сопровождению, а также требования к миграции наработок

из старой системы в новую удовлетворяют пользователей.

4, 3, 2

Глава 6 253

Задача Описание задачи Уровни

Оценка требо-

ваний к ПО

Задача выполняется в составе работ по V&V требований к

ПО. Описана отдельно

4, 3, 2, 1

Оценка проек-

та ПО

Задача выполняется в составе работ по V&V проекта ПО.

Описана отдельно

4, 3, 2, 1

Оценка исход-

ного кода

Задача выполняется в составе работ по V&V реализации

ПО. Описана отдельно

4, 3, 2, 1

Оценивание

состояния

управления

конфигурацией

Задача выполняется в составе работ по V&V требований к

ПО.

Проверяется полнота и адекватность процесса управле-

ния конфигурацией (СМ, от Configuration Management),

описанного в документации по процессу. Поддерживающий

процесс CM должен отвечать требованиям стандартов и

соответствовать сложности, размеру и целостности ПС, а

также планам проекта и чаяниям пользователей.

4, 3

Создание / ве-

рификация

плана тестиро-

вания для V&V

приемки

Задача выполняется в составе работ по V&V требований к

ПО.

Для уровня целостности 2 достаточно проверить, что

План тестирования приемки, созданный группой разработ-

ки ПС при выполнении основного процесса «тестирование

ПО», удовлетворяет потребностям проекта и стандартам.

Для уровней целостности 3 и 4 должен быть разработан

самостоятельный план тестирования приемки, подтвер-

ждающего, что ПО корректно реализует программные и

системные требования в среде эксплуатации.

4, 3, 2

Создание / ве-

рификация

плана тестиро-

вания для V&V

системы

Задача выполняется в составе работ по V&V требований к

ПО.

Описана отдельно

4, 3, 2, 1

Создание / ве-

рификация

плана тестиро-

вания для V&V

интеграции

Задача выполняется в составе работ по V&V проекта ПО.

Для уровня 2 достаточно проверить, что План тестирова-

ния интеграции, созданный группой разработки ПС при

выполнении основного процесса «тестирование ПО», удов-

летворяет потребностям проекта и стандартам (в частности,

обеспечивает прослеживаемость интеграции к системным

требованиям).

Для уровней 3 и 4 должен быть разработан самостоятель-

ный план интеграционного тестирования, подтверждаю-

щего, что ПО, создаваемое путем постепенной интеграции

отдельных проверенных компонентов, корректно реализует

требования.

4, 3, 2

Создание / ве-

рификация

плана тестиро-

вания для

V&V компо-

нентов

Задача выполняется в составе работ по V&V проекта ПО.

Для уровня 2 достаточно проверить, что План тестирова-

ния компонентов, созданный группой разработки ПС при

выполнении основного процесса «тестирование ПО», удов-

летворяет потребностям проекта и используемым стандар-

там (в частности, обеспечивает прослеживаемость компо-

нентов к требованиям к ПО и проекту ПО).

4, 3, 2