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

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

Лекция 8. Организация сертификационных испытаний... 241

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

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

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

ошибок. Для выполнения этих работ иногда используется коллектив

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

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

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

низацию трудно разделить. Для широко тиражируемых программных

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

тив,

не проводивший первичную разработку.

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

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

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

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

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

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

цию,

реализацию и финансирование. Выявленные ошибки в компо-

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

ций,

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

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

устраняться за счет разработчика. Модификацию и расширение функ-

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

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

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

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

чиком.

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

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

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

(поставщиков) программного продукта возлагаются затраты на анализ и

локализацию источников и причин дефектов и их устранение. Эти затра-

ты зависят от характеристик выявляемых дефектов, от масштаба ком-

плекса программ, организации и технологии его разработки, инструмен-

тальной оснащенности сопровождения, квалификации специалистов, а

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

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

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

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

242

В. В.

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

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

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

мо-

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

предшествующих версий.

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

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

ций,

разработчик или поставщик

обязан

удовлетворять требования

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

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

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

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

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

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

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

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

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

лью удовлетворения этих требований.

Лекция 9. Подготовка сертификационных испытаний.., 243

Лекция 9

ПОДГОТОВКА СЕРТИФИКАЦИОННЫХ

ИСПЫТАНИЙ ПРОГРАММНЫХ ПРОДУКТОВ

Требования

квалификации испытателей

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

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

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

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

многообразием знаний, опыта, стимулов и потребностей. Быстрый

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

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

к специалистам, обеспечивающим этапы испытаний в жизненном

цикле ПС. Специалисты в соот-ветствии со своей квалификацией и

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

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

прогнозировании эффективности процессов испытаний - рис. 9.1.

Непрерывно повышаются размеры и сложность комплексов про-

грамм, что вызывает возрастание затрат творческого труда на едини-

цу размера программного продукта. Разработка сложных комплексов,

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

сокой долей творческого труда. Дефекты, трудоемкость и длитель-

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

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

конкретного проекта. В перспективе, несмотря на автоматизацию и

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

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

программных продуктов возрастает. Даже при сокращении суммар-

ных затрат на разработку программных компонентов за счет автома-

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

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

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

ностям испытателей.

244

В. В.

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

Требования к квалификации испытателей сложных

программных продуктов:

- испытатели должны обладать аналитическим складом ума,

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

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

сти;

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

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

ний;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис.

9.1

Недостатки или отсутствие достоверного обоснования необхо-

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

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

Поэтому целесообразно активно привлекать заказчиков к управле-

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

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

Уровень квалификации заказчика и корректность требований техни-

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

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

ний комплекса программ. При этом первоначальное техническое

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

подвергается в дальнейшем многократным изменениям. Этому же

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

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

Лекция 9. Подготовка сертификационных испытаний... 245

затрат на реализацию дополнительных требований. Особенно сильно

на достоверность технического задания и возрастание затрат может

влиять попытка заказчика форсировать сроки разработки версий

программного продукта. Даже квалифицированные заказчики вынуж-

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

управления проектом, что может влиять на увеличение затрат на 10 -

20%.

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

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

вие дефектов исходных требований заказчика.

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

прежде всего, необходима организация и тесное взаимодействие

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

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

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

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

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

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

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

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

фликтам. Организация четкого взаимодействия и сокращение этих

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

тий и контактов по обмену знаниями, взаимному повышению квали-

фикации и обучению.

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

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

отражается на успехе проекта. Лидером испытаний программного

продукта может быть: менеджер продукта, менеджер проектирова-

ния, руководитель проекта. Лидер должен [4, 7, 16]:

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

ний к функциям программного продукта, подлежащим испытаниям;

• рассматривать конфликтующие пожелания, поступающие от

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

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

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

ла участников проекта, прежде всего, заказчика и пользователей;

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

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

246

В. В.

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

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

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

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

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

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

функций программного продукта;

• осуществлять управление изменением приоритетов испыта-

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

функций комплекса программ.

Коллектив испытателей должен иметь в своем составе квалифи-

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

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

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

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

ные аналитики сложных ПС должны иметь, прежде всего, хорошую

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

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

нию крупных разработок и испытаниям программ. Им необходима

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

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

организовать коллектив для решения общей целевой задачи реализа-

ции продукта. Это позволит на ранних этапах исключать или сокра-

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

задач комплекса программ, а также показателей качества.

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

ных продуктов играют испытатели - тестировщики. Они долж-

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

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

гию,

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

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

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

ний.

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

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

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

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

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

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

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

стниками процесса тестирования [8, 19]. Испытатели должны обла-

Лекция 9. Подготовка сертификационных испытаний... 247

дать специфической квалификацией для разработки эффективной

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

ям в необходимом и достаточном объеме.

Хороший испытатель должен обладать аналитическим скла-

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

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

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

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

иметь опыт работы с различными платформами, операционными сис-

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

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

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

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

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

Личные качества испытателей комплексов программ и от-

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

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

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

вает гораздо большее влияние на эффективность и качество, чем лю-

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

рис.

9.1). Ни один специалист не может быть носителем всех необхо-

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

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

чество требуемых качеств [7]:

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

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

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

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

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

• уметь критиковать и корректно воспринимать критику, так

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

слов их можно было устранить;

• уметь противостоять внешнему давлению руководства, так

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

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

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

• быть терпеливым и готовым выполнять исполнение тестов

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

248

В. В.

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

дефект, после чего повторно выполнить регрессионные тесты, чтобы

убедиться в корректном его устранении;

• обладать гибким мышлением - быть способным быстро пере-

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

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

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

• обладать способностью видеть общую панораму развития

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

иметь широкий, и динамичный кругозор.

С учетом сложности тестирования в клиент-серверной или мно-

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

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

работы с различными платформами, операционными системами, при-

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

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

Для сокращения и устранения дефектов разработки посред-

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

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

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

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

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

тов.

Этому должна способствовать утвержденная дисциплина и ие-

рархия принятия решений на координированные изменения компо-

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

методами и средствами защиты от несанкционированного доступа

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

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

на разных уровнях проекта.

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

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

ровок на каждом уровне разработчиков изменений (см. таблицу 3.1).

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

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

работать запрос на изменение; проследить изменение; распределить

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

тации. Изменения, которые воздействуют на программный продукт,

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

Лекция 9. Подготовка сертификационных испытаний.,. 249

казчику в соответствии с установленными контрактом формами и

процедурами.

На основе проведенного анализа и испытаний персонал должен

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

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

менений; результаты их анализа и варианты реализации изменений,

оценку их влияния на функциональную пригодность. Следует со-

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

ний в соответствии с договором. Регистрация и учет истории этого

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

становления выполненных изменений (отката) документов для вы-

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

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

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

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

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

В процессах разработки и испытаний программного продукта

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

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

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

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

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

цией программного продукта. Менеджер проекта является высшим

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

нию изменений и корректировке требований и конфигурации слож-

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

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

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

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

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

ного продукта. При организации сложного проекта следует иденти-

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

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

зователям, и любые изменения к ним.

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

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

соответствующего их отбора, подготовки и обучения. Должны

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

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

250

В. В.

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

включая документы, используемые для обучения (см. ISO 19759 и

ISO 15504). Персонал, ответственный за выполнение конкретных за-

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

быть аттестован, если это необходимо, на основе соответствующе-

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

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

со специфической (проблемно-ориентированной) областью, в кото-

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

лификации в этой области. Требования к квалификации и обучению

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

проект.

Методы подготовки тестов для испытаний

программных продуктов

Ручная пошаговая подготовка сценариев и содержания тес-

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

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

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

ва. Как правило, разработчиками моделей автоматизированной гене-

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

гается необходимость детализации к ним требований (рис. 9.2). Реа-

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

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

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

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

са.

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

только формой описания их содержания: функциональным (процесс-

ным) или событийным (сценариями и результатами исполнения) (см.

лекцию 8). Генерация тестов особенно сложна (также как и требова-

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

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

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

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

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

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

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

полную обработку результатов тестирования.