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

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

254 Глава 6

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

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

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

щего, что каждый компонент корректно реализует предъяв-

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

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

рификация

проектов тес-

тов для V&V

компонента 4, 3, 2

интеграции 4, 3, 2, 1

системы 4, 3, 2, 1

приемки

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

Для уровней ниже 3 достаточно проверить, что Проекты

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

компонентов, интеграции, системы и приемки ПС, отвеча-

ют требованиям соответствующих планов тестирования и

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

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

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

системы и приемки.

4, 3, 2

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

рификация

тестовых набо-

ров для V&V

компонента 4, 3, 2

интеграции 4, 3, 2, 1

системы 4, 3, 2, 1

приемки

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

ПО.

Для уровней ниже 3 достаточно проверить, что Наборы

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

компонентов, интеграции, системы и приемки ПС, отвеча-

ют соответствующим проектам тестов и могут быть про-

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

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

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

системы и приемки.

4, 3, 2

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

рификация тес-

товых проце-

дур для V&V

компонента 4, 3, 2

интеграции 4, 3, 2, 1

системы

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

ПО.

Для уровней ниже 3 достаточно проверить, что Тестовые

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

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

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

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

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

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

грации и системы. Подтвердить их соответствие планам.

4, 3, 2, 1

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

рификация тес-

товых проце-

дур для V&V

приемки

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

ПО.

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

цедуры приемки, построенные разработчиками, отвечают

соответствующим наборам тестов и могут быть прослеже-

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

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

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

дить их соответствие планам.

4, 3, 2

Выполнение /

верификация

тестов для

V&V компо-

нентов

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

ПО.

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

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

процедуры тестирования компонентов подтвердить, что ПО

удовлетворяет критерию приемочного тестирования.

4, 3, 2

Глава 6 255

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

Для уровней 3 и 4 нужно провести тестирование компо-

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

ПО корректно реализует проект. Подтвердить, что резуль-

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

сированным в планах. Документировать результаты тести-

рования в соответствии с требованиями, описанными в

Плане тестирования, указывая отклонения результатов от

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

подтверждения того, что ПО удовлетворяет установленно-

му критерию приемочного тестирования.

Выполнение /

верификация

тестов для

V&V интегра-

ции

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

ПО.

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

4, 3, 2, 1

Выполнение /

верификация

тестов для

V&V системы

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

ПО.

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

4, 3, 2, 1

Выполнение /

верификация

тестов для

V&V приемки

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

ПО.

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

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

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

летворяет критерию приемочного тестирования.

Для уровней 3 и 4 нужно провести тестирование прием-

ки, проанализировать результаты и подтвердить, что ПО

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

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

зафиксированным в планах. Документировать результаты

тестирования.

4, 3, 2

Аудит инстал-

ляционной

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

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

ствие ПО.

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

корректной инсталляции и применения ПО, присутствуют в

инсталляционном пакете. Подтверждается, что все завися-

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

корректно учтены.

4, 3

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

ствие ПО.

Проводится анализ или выполняются тесты для проверки

того, что инсталлированное ПО соответствует тому, кото-

рое должно быть подвергнуто V&V. Подтверждается, что

программный код и база данных запускаются, работают и

завершаются корректно. При переходе от одной версии ПО

к другой подтверждается, что ПО может быть демонтиро-

вано без нарушения функционирования оставшихся компо-

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

4, 3

256 Глава 6

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

Генерация за-

ключительного

отчета о V&V

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

ствие ПО.

Нужно подытожить все работы по V&V, выполненные

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

ние обнаруженных аномалий и их состояние (степень уст-

ранения). Провести оценивание качества всего ПО и выра-

ботать рекомендации.

4, 3, 2

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

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

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

тельно их взаимного влияния. Удовлетворяют ли они потребностям деловой сферы;

– проверке внутренней непротиворечивости требований к компонентам об-

щесистемного и специального (разрабатываемого) ПО, а также согласованности с

внешними требованиями к ПС.

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

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

горитмов, режимов/состояний, входов/выходов, обработки исключительных ситуа-

ций, составления отчетов и др.), а также требования к технологическому процессу и

регламенту использования ПС;

– проверке, описаны ли интерфейсы с общесистемным ПО, техническими

средствами и пользователями;

– проверке, установлены ли критерии эффективности ПС (например, ско-

рость обработки сообщений, точность) и обеспечены ли средства контроля и отка-

зоустойчивости ПС (контроль входных данных, откат транзакций и др.);

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

предъявляемым к ним процедурами управления конфигурацией.

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

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

ления текстовой информации требованиям со стороны технических средств.

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

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

но, и отвечает ли профессиональному уровню круга ее читателей;

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

циальные символы.

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

на проверке наличия объективных критериев приемки для подтверждения каждого

из положений документированных требований.

Задача создания/верификации плана тестирования с целью V&V системы

выполняется по-разному, в зависимости от уровня целостности ПС.

Для ПС с уровнем целостности 1 или 2 выполнение этой задачи заключается

в верификации соответствия Плана тестирования системы (System test plan), соз-

данного группой разработки в ходе выполнения основного процесса «тестирование

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

ний (например, ДСТУ 2851-94 или IEEE Std. 829:1998). Проверяется, охватывает ли

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

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

Глава 6 257

сована ли форма представления), осуществимо ли квалификационное тестирование

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

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

работчиком, недостаточно. Должен быть построен самостоятельный план тестиро-

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

ее программному обеспечению.

Задачи верификации и валидации проекта ПС с низкой критичностью.

Деятельность по V&V проекта касается проверки проектных решений, принятых по

каждому компоненту ПО, хранилищам данных и интерфейсам (внешним для ПО,

между компонентами ПО и между отдельными модулями). Цели V&V – продемон-

стрировать, что требования к ПС корректно, точно и в полном объеме трансформи-

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

предусмотренных требованиями. В ходе рассмотрения документов проекта (описа-

ния проекта ПС и описания проекта интерфейса) решаются три задачи верифика-

ции и валидации:

– оценка проекта ПС,

– создание / верификация проектов тестов для V&V интеграции,

– создание / верификация проектов тестов для V&V системы.

Оценка проекта ПС заключается в анализе корректности, согласованности,

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

женных в документах. Для проверки и подтверждения правильности (по существу

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

терии и принципы, что и при оценке требований к ПС.

Нужно заметить, что рекомендации по описанию проектов (SDD, Software

Design Description) сформулированы в стандарте IEEE Std. 1016 [5] и отражают со-

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

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

димой детализации проектных решений

Стандарт IEEE Std. 1012 в части оценки проекта ПС также предполагает, что

проверка проекта по указанным выше критериям осуществляется на всех уровнях

декомпозиции проекта вплоть до описания модулей (например, на псевдокоде). Не

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

екта нужно оценить:

• соответствие методов проектирования и стандартов требованиям проекта;

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

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

точности);

• внутреннюю согласованность компонентов проекта;

• наличие в описании проекта проектных решений по всем функциям, про-

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

Этих рекомендаций нет в стандартах серии ГОСТ 34, устанавливающих требования

к документам стадий эскизного и технического проектирования. Выделение и специфика-

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

ментации системы.

258 Глава 6

(не разрабатываемыми) компонентами ПО, а также по обеспечению контроля вход-

ных данных и отказоустойчивости ПС и др.;

• возможность проследить (трассировать) каждое проектное решение к

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

для подтверждения каждого элемента проекта ПО и системы.

Задачи создания / верификации проектов тестирования с целью V&V инте-

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

ПС.

Для ПС с уровнем целостности 1 или 2 выполнение этих задач заключается в

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

выполнения основного процесса «тестирование ПО», соответствующим планам

интеграционного (системного) тестирования и требованиям стандартов документи-

рования испытаний (например, ДСТУ 2851 или IEEE Std. 829).

Для более высоких уровней целостности ПС проверка проектов тестов, соз-

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

соответствующих планам тестирования интеграции (системы) и прослеживаемых к

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

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

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

Деятельность по V&V исходного кода касается проверки корректности, точности и

полноты трансформации принятых проектных решений в исходный и выполнимый

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

екта (описания проекта ПС и описания проекта интерфейса), документации поль-

зователя, документации исходного кода и стандартов кодирования решаются сле-

дующие задачи верификации и валидации:

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

– создание / верификация наборов тестов для V&V интеграции,

– создание / верификация наборов тестов для V&V системы,

– создание / верификация тестовых процедур для V&V интеграции,

– создание / верификация тестовых процедур для V&V системы.

Оценка исходного кода и документации исходного кода ПС заключается в

анализе корректности, согласованности, полноты, точности, читабельности и тес-

топригодности компонентов исходного кода (документации исходного кода). Пре-

жде всего, проверяется:

• реализует ли исходный код ПС проектные решения, описанные в доку-

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

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

ничения со стороны технических средств (разрешающая способность экрана, раз-

рядность, правила усечения (округления) чисел и др.);

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

ствуют ли экранные формы и отчеты (внешне и содержательно) ожиданиям поль-

зователя);

• отвечает ли исходный код действующим стандартам (стандартам языка

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

дартам используемой операционной системы);

• существуют ли объективные критерии приемки каждого компонента ис-

ходного кода и можно ли протестировать код на соответствие этим критериям.

Глава 6 259

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

кументации дают стандарты IEEE Std. 1063 (пользовательская документация ПО)

[6], ISO/IEC 9127 (пользовательская документация в пакетах ПО) [7], ISO/IEC 6592

(руководство по документированию компьютерных прикладных систем) [8].

Задачи создания / верификации наборов тестов с целью V&V интеграции

(системы) выполняются по-разному, в зависимости от уровня целостности ПС.

Для ПС с уровнем целостности 1 или 2 выполнение этих задач заключается в

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

выполнения основного процесса «тестирование ПО», соответствующим проектам

тестов для интеграционного (системного) тестирования и требованиям стандартов

документирования испытаний (например, ДСТУ 2851 или IEEE Std. 829).

Для более высоких уровней целостности ПС проверка наборов тестов, соз-

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

ствующих проектам тестирования интеграции (системы) и прослеживаемым к пла-

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

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

темы.

Задачи создания / верификации тестовых процедур с целью V&V интеграции

(системы) выполняются по-разному, в зависимости от уровня целостности ПС.

Для ПС с уровнем целостности 1 или 2 выполнение этих задач заключается в

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

ходе выполнения основного процесса «тестирование ПО», соответствующим набо-

рам тестов для интеграционного (системного) тестирования и требованиям стан-

дартов документирования испытаний (например, ДСТУ 2851 или IEEE Std. 829).

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

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

ответствующих наборам тестов для тестирования интеграции (системы) и просле-

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

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

граммному обеспечению системы.

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

стью. Деятельность по V&V испытаний касается проверки правильности интегра-

ции компонентов ПС (между собой, а также с общесистемным ПО и техническими

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

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

полнения интеграционного, системного и приемочного тестирования (для уровней

целостности 1 и 2) или выполнении дополнительного тестирования (для уровней

целостности 3 и 4). Включает решение двух задач:

- выполнение / верификация тестов для V&V интеграции,

- выполнение / верификация тестов для V&V системы.

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

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

мый код ПС.

Структура и содержание планов, проектов, наборов и процедур тестирования,

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

приемки ПС подробно рассматриваются в главе 7.

260 Глава 6

6.1.3. Управление верификацией и валидацией

Управление действиями по V&V при выполнении основных процессов ЖЦ,

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

организационного процесса ЖЦ – процесса управления.

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

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

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

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

дством проекта.

Задачи управления верификацией и валидацией. В задачи управления V&V

входит постоянный анализ деятельности по V&V, построение плана SVVP и его

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

тов V&V с процессом разработки и другими поддерживающими процессами –

SQA, управление конфигурацией, совместный просмотр и аудит.

В ходе управления V&V оценивается каждое предложенное изменение в сис-

теме и ПО, определяются требования к ПО, которых могут касаться изменения, и

планируется выполнение задач V&V, связанных с проверкой внесенных изменений.

По каждому предложенному изменению устанавливается, не приведет ли оно к по-

явлению каких-либо новых угроз или рисков для ПО, и как оно отразится на уров-

нях целостности ПО. При изменении уровней целостности планы V&V пересмат-

риваются – могут добавляться новые задачи V&V или расширяться сфера примене-

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

В контрольных точках проекта результаты V&V оцениваются, и принимается

решение о переходе к следующей стадии (или множеству действий) в процессе раз-

работки. Может быть инициировано повторное выполнение V&V.

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

цессов ЖЦ ПС и могут обновляться по требованию заказчика (потребителя) (при

выполнении им процессов приобретения ПС) или разработчика (поставщика) (при

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

нении процесса сопровождения).

Исходной информацией для построения (обновления) SVVP являются ре-

зультаты выполнения работ (выходы) по проверяемому процессу, планы поставщи-

ка ПС, графики проекта ПС, а также выходы выполняемого процесса V&V. Изна-

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

жду заказчиком и разработчиком и концепции ПС (базовый план SVVP).

Организовать деятельность по V&V можно по-разному. Выбор формы орга-

низации работ в процессах V&V определяется масштабом, сложностью и критич-

ностью системы. Действия по V&V могут выполняться только разработчиками,

равными в правах, группой разработки (менеджерами и разработчиками), группой

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

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

Процессы V&V, выполняемые организацией (подразделением), имеющей оп-

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

сти от организации-разработчика (подразделения-разработчика), называют незави-

симой верификацией и валидацией (IV&V, Independent V&V), а такую организа-

цию (подразделение) – органом (группой) IV&V.

Глава 6 261

IV&V целесообразно применять к крупным дорогостоящим проектам или

проектам критических по безопасности функционирования систем (safety critical

system) для достижения объективности проверок и снижения риска разработки.

Выбирая IV&V, как форму организации V&V проекта, заказчик полагается на ор-

ган IV&V как на объективную и незаинтересованную сторону для получения ин-

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

тах на его выполнение.

Техническая независимость группы IV&V состоит в том, что ее члены не

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

ботки систем данного класса и компетентны в принятии решений, касающихся тех-

нических аспектов ПС. Они не подвержены влиянию или давлению со стороны

группы разработки при выполнении V&V. Техническая независимость обеспечива-

ет возможность тщательно изучить тонкости принятых разработчиками решений и

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

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

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

средств, чтобы гарантировать, что они не маскируют ошибок в анализируемом и

тестируемом ПО. По возможности, группа IV&V должна применять или разраба-

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

Административная независимость означает, что IV&V выполняется органи-

зацией, административно не связанной ни с разработчиком, ни с заказчиком. Орган

IV&V вправе по своему усмотрению выбирать те части системы, для которых про-

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

по V&V. Результаты проверки доводятся как до заказчика, так и до разработчика

ПС. Координировать работы органа IV&V с заинтересованными организациями

может третья сторона – организация-координатор.

Финансовая независимость означает, что финансирование работ по IV&V, а

также контроль их выполнения осуществляется организацией, не зависящей от ор-

ганизации-разработчика ПС (например, заказчиком). Эта независимость защищает

орган IV&V от неправильного распределения денежных средств или других форм

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

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

IV&V, обладающую полной технической, административной и финансовой

независимостью, называют классической IV&V.

Структура и содержание плана верификации и валидации. В плане SVVP

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

действий и задач по V&V в ходе ЖЦ ПС. Примерная структура плана показана на

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

хранения содержания плана.

Разъяснения по составлению плана SVVP содержатся в стандарте IEEE Std.

1012 [4] и вкратце приводятся ниже применительно к основным пунктам плана.

Если по какому-то из пунктов плана информация не предоставляется, это должно

указываться фразой «данная тема не охватывается планом» и обосновываться. В

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

262 Глава 6

План верификации и валидации ПС

1. Назначение

2. Ссылки

3. Определения

4. Организация работы по V&V

4.1. Организация

4.2. График работ

4.3. Схема назначения уровней целостности ПО

4.4. Распределение ресурсов

4.5. Ответственности

4.6. Инструменты, методологии и методы

5. Процессы и действия по V&V

5.1. Процесс: Управление

5.1.1. Действие: Управление V&V

5.2. Процесс: Приобретение

5.2.1. Действие: V&V поддержки приобретения

5.3. Процесс: Поставка

5.3.1. Действие: V&V планирования

5.4. Процесс: Разработки

5.4.1. Действие: V&V Концепции

5.4.2. Действие: V&V Требований

5.4.3. Действие: V&V Проекта

5.4.4. Действие: V&V Реализации

5.4.5. Действие: V&V Испытаний

5.4.6. Действие: V&V Ввода в действие

5.5. Процесс: Эксплуатация

5.5.1. Действие: V&V Эксплуатации

5.6. Процесс: Сопровождение

5.6.1. Действие: V&V Сопровождения

6. Требования к отчетным документам V&V

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

7.1. Регистрация и принятие решений по аномалиям

7.2. Политика итерации задач

7.3. Регулирование отклонений от плана

7.4. Процедуры контроля

7.5. Стандарты, практические руководства и соглашения

8. Требования к документированию V&V

Рис. 6.2. Структура плана SVVP

Организация работы по V&V. В этом разделе должны быть описаны:

• вид V&V (IV&V), взаимосвязь процессов V&V с другими процессами

ЖЦ. Должны быть четко определены связи (форма взаимодействия) между органи-

зацией (группой), выполняющей V&V, и разработчиком, полномочия для решения

проблем, возникающих при выполнении задач V&V, и для приемки и утверждения

результатов V&V;

• общий план выполнения действий, контрольные точки в V&V и механизм

обратной связи с процессом разработки. Должна быть описана принятая модель

ЖЦ разработки, этапы выполнения работ, включая даты завершения каждого этапа,

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

Глава 6 263

выполнения действий по 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 c указанием порядка их выполнения (критерия завершения),

входов и выходов. Одна и та же задача может выполняться для компонентов ПО

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

документирования выходов;

• методы и процедуры выполнения каждой задачи, а также критерии оцени-

вания их результатов;

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

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