Липаев В.В. Сертификация программных средств. Учебник

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

Лекция И. Удостоверение качества и завершение...испытаний... 321

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

цией компонентов проекта;

I Исходные документы, отражающие результаты I

I предварительных испытаний и характеристики I

I сертифицируемого программного продукта: I

I - Техническое задание - требования к функциям, характеристи- I

I кам, качеству программного продукта, системы и внешней среды; I

I - Договор заказчика с производителем программного продукта; I

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

I области критериев качества процессов производства и про- I

I граммного продукта; I

I - полные тексты программ, содержание базы данных и техноло- I

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

I - комплект эксплуатационных документов, поставляемых заказ- I

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

I продукта; I

I - план. Программа и методики испытаний, применения и оценки I

I качества программного продукта; I

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

I граммного продукта; I

I - методика конфигурационного управления, утверждения, хра- I

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

I сопровождающих документов в архиве предприятия; I

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

I данных управления конфигурацией и эксплуатационную доку- I

I ментацию для тиражирования и серийного производства; I

I - руководство по генерации и инсталляции пользовательских I

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

I рактеристиками внешней среды; I

I - акт о завершении предварительных испытаний и готовности к I

I поставке и/или предъявлению для сертификационных испыта- I

I ний версии программного продукта. I

Рис. 11.3

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

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

граммного продукта;

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

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

• версия программного продукта сопровождается технологиче-

322

В.В.

Липаев. Сертификация программных средств

ской и эксплуатационной документацией, перечнем изменений, со-

держит список отчетов о дефектах, которые исправлены в версии;

Результирующие документы сертификационных испытаний

программного

продукта:

- Договор заявителя с сертифицирующей организацией на про-

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

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

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

ментации на протяжении жизненного цикла программного про-

дукта;

- отчет сертификаторов о рабочем состоянии Программы и ме-

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

с требованиями Договора

на

сертификацию с заявителем;

- результаты аттестации имитаторов внешней среды и генера-

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

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

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

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

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

заявителями;

- протоколы достигнутых при сертификационных испытаниях

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

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

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

характеристикам программного продукта;

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

обеспечения его

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

вия.

Рис. 11.4

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

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

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

результаты испытаний;

• проведены совещания, посвященные управлению незавер-

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

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

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

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

Лекция

11.

Удостоверение

качества и завершение...испытаний... 323

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

грамм на объектной ЭВМ

системе;

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

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

дежности и безопасности;

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

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

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

программный продукт, как это определено в ходе заключительного

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

казчика

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

• проведено совещание разработчиков с заказчиком и установ-

лено,

что критерии завершения предварительных испытаний про-

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

сертификационных испытаний.

Завершаются предварительные испытания предъявлением за-

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

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

сии программного продукта (см. рис. 11.3).

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

согласованию, для заказчика

пользователей следующие документы:

• документацию средств автоматизации проектирования, про-

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

программного продукта;

• тесты, сценарии и генераторы динамических тестовых дан-

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

компонентов

версии продукта

целом;

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

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

дукта

реальной внешней среде;

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

ристики достигнутого качества функционирования, а также степени

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

дукту;

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

и пользователей применению испытанной версии программного про-

дукта;

324

В. В.

Липаев. Сертификация программных средств

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

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

цию для тиражирования и серийного производства;

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

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

рактеристиками внешней среды;

• отчет о технико-экономических показателях производства за-

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

пользованных ресурсах;

• акт о завершении предварительных испытаний и готовности к

поставке

и/или

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

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

На завершающих этапах предварительных испытаний, когда,

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

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

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

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

Специалисты склонны забывать, какие соглашения и требования бы-

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

ний.

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

тестированию в соответствии с планом и Программой, она должна

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

граммного продукта [3, 11].

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

должен содержать перечень всех не устраненных дефектов, с со-

глашением и планом того, будут ли они исправлены в более поздних

версиях или же их исправление откладывается на неопределенное

время. Необходимо вести наблюдение за такими дефектами, чтобы не

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

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

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

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

товности программного продукта к поставкам:

• количество катастрофических дефектов, обнаруженных в

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

• общее количество возможных предсказуемых дефектов, кото-

рые не были исправлены;

• процентное отношение количества тестов, которые заверши-

Лекция

11.

Удостоверение

качества и завершение...испытаний... 325

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

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

Критерий выхода из предварительных испытаний и готов-

ности версии программного продукта к сертификации включают:

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

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

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

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

дукта;

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

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

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

до логического конца;

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

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

на тысячу строк программного кода достигнуто.

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

продукта к сертификации следует проводить специальные совещания

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

товности определяет группа тестирования; в других организациях со-

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

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

задачу группы тестирования и испытаний входит представление ре-

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

дукта к поставкам для сертификации.

С самого начала проекта необходимо определить, что следует

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

ний, и соответствия исходным требованиям заказчика, когда

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

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

быть комплект отчетных документов (см. рис. 11.4) и подтверждение

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

рис.

11.2 и 11.3. При сертификационных испытаниях программного

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

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

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

программного продукта дает право на присвоение ему сертификата

и знака качества.

326

В. В.

Липаев. Сертификация программных средств

Поставка пользователям сертифицированной версии

программ продукта для применения

После завершения испытаний новой версий программного

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

менения (см. рис. 11.1). Это производится, как правило, в два этапа;

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

ния ошибок в изменениях на этапе опытной эксплуатации, и/или по-

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

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

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

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

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

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

Разработчики и испытатели в этом случае получают возможность не-

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

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

ки замечаний и рекламаций, формирование квалифицированных

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

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

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

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

чение выделенной группы специалистов, ответственных за после-

дующее обучение коллективов пользователей.

В процессе жизненного цикла большое значение имеет история

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

ветствующая документация. Еще на стадии проектирования первой

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

грамм, которые в то время невозможно реализовать из-за высокой

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

чинам. Идеи изменения могут быть направлены на коренное улучше-

ние функциональных возможностей программ или некоторые «кос-

метические» улучшения реализуемых функций. Идеи небольших

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

предложений по существенному совершенствованию программного

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

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

процессе сопровождения, содержащий разделы:

• выявленные дефекты и ошибки в программном продукте;

Лекция

11.

Удостоверение

качества и завершение...

испытаний...

327

• предложения по совершенствованию функций и улучшению

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

• идеи и предполагаемая экономическая эффективность корен-

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

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

После внесения изменений в требования специалисты разраба-

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

дукта. Специалисты должны провести проверки каждого внесенного

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

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

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

изменения удовлетворяют требованиям

заказчика,

установленным в

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

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

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

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

клоненные изменения; отчет о приемке версии; отчеты о проверках и

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

продукта.

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

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

лизом, обосновывающим это решение. В анализе следует определить

и экономически обосновать: возможность сохранения устаревшей

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

менения новой версии программного продукта. При снятии про-

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

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

мить этапы работ, обеспечивающие их эффективное выполнение.

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

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

дукта.

Анализ результатов сертификации и

усовершенствование процессов испытаний

программного продукта

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

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

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

328

В. В.

Липаев. Сертификация программных средств

усовершенствовать, и в следующем проекте получить преимущества.

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

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

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

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

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

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

но,

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

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

щих решения. С целью улучшения результатов, испытатели должны

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

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

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

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

Полученные уроки, оценки измерений характеристик программ-

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

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

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

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

тестами. Наличие отвечающей современным требованиям базы

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

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

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

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

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

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

ределенное действие по совершенствованию процесса. После завер-

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

реализацию Программы сертификационных испытаний с запланиро-

ванными критериями.

Усовершенствование процессов сертификационных испыта-

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

яснять, повторялись ли те или иные дефекты и ошибки, и подтвер-

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

шенствованию испытаний. При изучении реализации Программы ис-

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

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

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

Лекция

11.

Удостоверение

качества и завершение...испытаний,,. 329

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

часть

развития культуры

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

После сбора полученных

уроков и других измерений, и определения корректирующих дейст-

вий испытатели должны оценивать эффективность Программы ис-

пытаний.

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

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

бой ложный

отрицательный

результат, означающий, что тест за-

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

было ошибки. Случаи ложных отрицательных результатов могут воз-

никать из-за изменений в программах, ошибок в настройке теста,

ошибок тестовых процедур, ошибок испытателя, логических ошибок

автоматизированного динамического теста или ошибок настройки

внешней среды. Если ряд ложных отрицательных результатов указы-

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

избежно усовершенствование процесса их создания.

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

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

эффекта ложных

положительных

результатов,

когда кажется, что

тестовая процедура выполнена успешно, но на самом деле существует

проблема, связанная с комплексом программ. Испытатели должны

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

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

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

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

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

тирования должна оценивать и осуществлять выборочную проверку

результатов тестирования даже в том случае, если тест завершился

успешно.

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

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

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

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

Если разработчики заявляют, что дефекты в определенной функ-

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

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

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

ния в программном продукте. Кроме того, анализ поможет опреде-

330 В.В. Липаев. Сертификация программных средств

лить функциональность, с которой связано наибольшее количество

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

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

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

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

го продукта. Каждый дефект обычно ранжируется в зависимости от

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

фекты, испытатели должны провести регрессионное тестирование

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

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

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

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

явлении нового отчета о проблеме.