«В.В. Липаев ТЕСТИРОВАНИЕ КОМПОНЕНТОВ И КОМПЛЕКСОВ ПРОГРАММ УЧЕБНИК СИНТЕГ® Москва - 2010 УДК 004.41(075.8) ББК 32.973.26-018я73 Л61 Липаев В.В. Тестирование компонентов и комплексов программ. Учебник. – М.: СИНТЕГ, ...»

Стандартизированные в ISO 9126 характеристики качества комплексов программ различаются по степени влияния на системную эффективность их применения по прямому назначению. Высшие приоритеты, естественно, должны присваиваться свойствам и атрибутам функциональной пригодности для достижения стратегических целей использования программного комплекса. Все остальные стандартизированные характеристики, в той или иной степени, должны способствовать обеспечению тактических целей выбранных конструктивных требований. Разработка требований к свойствам и характеристик качества, естественно, должна начинаться с определения и документирования группы показателей, непосредственно отражающих функциональную пригодность. Компоненты требований функциональной пригодности очень разнообразны и их целесообразно распределять на две части: унифицируемую по структуре и содержанию для различных по назначению комплексов программ, и уникальную – В.В. Липаев. Тестирование компонентов и комплексов программ непосредственно связанную со специфическими функциями и целями применения программного комплекса.

Для функциональных возможностей (стандарт ISO 9126) следует регистрировать приоритеты реализации соответствующих требований, а также указывать документы, где детализированы особенности этих свойств для конкретного проекта. Требования к характеристике корректность могут представляться в виде описания двух основных свойств, которым должны соответствовать все программные компоненты и комплекс в целом. Первое требование состоит в выполнении определенной степени прослеживаемости и верификации сверху вниз реализации требований технического задания при последовательной детализации описаний программных компонентов вплоть до текстов и объектного кода модулей программ. Второе требование заключается в выборе степени и стратегии покрытия тестами требований структуры и функций программных модулей и компонентов, достаточных для функционирования программного комплекса с необходимым качеством и точностью результатов при реальных ограничениях ресурсов на тестирование.

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

Документацию, формализующую требования к сложному программному комплексу, целесообразно делить на две части. Первый документ системные требования, предназначен для определения роли, назначения и функций программного комплекса в состаЛекция 1.5. Требования к допустимым рискам и к документированию… ве системы для определенной внешней среды. Он используется, прежде всего, заказчиком и менеджером главным конструктором при организации жизненного цикла сложного комплекса программ. Этот документ подлежит тщательному согласованию между заказчиком и разработчиками и утверждению заказчиком при любых изменениях требований. Второй документ определяет более детальные требования к реализации комплекса программ разработчиками. Формализация и реализация этих требований иногда частично может проходить без обязательного согласования с заказчиком, но документ должен служить основой для деятельности всего коллектива разработчиков.

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

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

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

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

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

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

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

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

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

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

В.В. Липаев. Тестирование компонентов и комплексов программ производные требования к компонентам программного комплекса и требования к интерфейсам между системными компонентами, элементами конфигурации комплекса программ и аппаратуры;

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

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

- общие требования к программному комплексу:

перечень объектов внешней среды применения программного комплекса (технологических объектов управления, подразделений предприятия и т.п.), при управлении которыми должен решаться требуемый комплекс функциональных задач;

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

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

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

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

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

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

требования к возможности адаптации функций комплекса программ к различной внешней среде и условиям применения;

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

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

источники информации и их идентификаторы;

перечень и описание входных сообщений (идентификаторы, формы представления, регламент, сроки и частота поступления данных);

перечень и описание структурных единиц информации входЛекция 1.5. Требования к допустимым рискам и к документированию… ных сообщений или ссылки на документы, содержащие эти данные;

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

назначение и потребители выходной информации;

перечень и описание содержания выходных сообщений;

регламент и периодичность выдачи результирующей информации;

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

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

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

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

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

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

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

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

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

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

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

В.В. Липаев. Тестирование компонентов и комплексов программ

ЭТАЛОНЫ ТИПОВ ТЕСТОВ И ИЗМЕНЕНИЯ

ТРЕБОВАНИЙ К КОМПЛЕКСАМ ПРОГРАММ

Формализация эталонов типов тестов программного комплекса и компонентов Объектами тестирования далее рассматриваются сложные комплексы программ для систем обработки информации и управления, разрабатываемые организованными коллективами (командами) квалифицированных специалистами разных категорий. Эталоны для тестирования включают процессы и объекты, которые определяют свойства, характеристики и качество компонентов и комплексов программ. Реализация тестирования может производиться разными методами и независимыми специалистами – программистами, интеграторами и тестировщиками, что позволяет использовать результаты их деятельности для сравнения одних и тех же описаний программ, представленных на языках программирования и на языках описания эталонов – тестов.

Первичное описание и реализация программных компонентов, а также мышление их разработчиков (программистов) осуществляется на основе требований, функций, характеристик структуры и исполнения программ. Оно существенно отличается от представлений и методов описаний тех же функций комплекса программ тестировщиками – создателями сценариев, процессов и типов эталонов тестирования. Они акцентируют свою деятельность на конкретных процедурах проверки функционирования, возможных результатах и взаимодействии компонентов комплекса программ. Это позволяет выявлять дефекты и повышать качество путем сопоставления двух методов и результатов описания одних и тех же функций и характеристик программ за счет того, что мала вероятность одинаковых ошибок в сценариях и реализациях тестов и в описаниях требований к функциям и характеристикам программ.

Лекция 1.6. Эталоны типов тестов и изменения требований… Совокупности требований и описаний типов тестов могут применяться как эталоны и вторая адекватная форма описаний функций и характеристик комплексов и компонентов программ.

Для обеспечения высокого качества программных комплексов и компонентов стратегию создания тестов различных типов целесообразно строить, основываясь на требованиях к функциям и характеристикам комплексов программ (см. рис. 1.2). При разработке сложных комплексов программ необходимо иметь пригодные для применения тестирования эталоны требования и/или сценарии использования функций программных компонентов и комплекса. Такая вторая форма описаний содержания программ должна служить для сквозной верификации спецификаций требований к тестам сверху вниз, а также сами подвергаться верификации на корректность соответствия исходным требованиям к компонентам программ разного уровня.

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

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

Для обеспечения высокого качества программного комплекса и компонента параллельно с верификацией требований и разработкой корректировок следует разрабатывать и верифицировать спецификации и сценарии тестов, отражающие методы и конкретные процедуры проверки реализации этих требований. Тестовые спецификации В.В. Липаев. Тестирование компонентов и комплексов программ могут использоваться для проверки согласованности, внутренней непротиворечивости и полноты реализации требований без исполнения программ. Для каждого требования к функциям программного комплекса (компонента), его архитектуре должна быть разработана спецификация требований к тестам, обеспечивающая проверку корректности, адекватности и возможности в последующем реализовать тестирование на соответствие этому эталону. Такая взаимная проверка корректировок функций комплексов (компонентов), отраженных в требованиях и в спецификациях тестов, обеспечивает повышение их качества, сокращение дефектов, ошибок, неоднозначностей и противоречий – рис. 1.8.

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

Тестовый эталон как инструмент содержится в требованиях официальных стандартов для планов тестирования, таких как ANSI/ IEEE 829. Это целый комплекс требований к спецификации тестовых эталонов, спецификации для самих тестов, журналам тестирования, разнообразным идентификаторам, к спецификации для тестовой процедуры, спецификациям ввода/вывода, а также специальные процедурные требования, зависимости между тестами, календарный план, описание распределения работ между персоналом, критерии приостановки и возобновления тестирования.

Лекция 1.6. Эталоны типов тестов и изменения требований… Эталоны типов тестов и изменения требований к формализацию эталонов типов тестов программного комплекса и компонентов:

программные «оракулы» – неформальные знания и представлений тестировщиков на основе опыта;

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

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

сценарии и наборы тестов от имитаторов на основе аттестованных моделей внешней среды;

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

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

технологическая документация как эталоны тестов;

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

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

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

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

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

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

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

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

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

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

В.В. Липаев. Тестирование компонентов и комплексов программ Спецификации тестов должны обеспечивать дополнительный контроль корректности спецификаций требований к функциям и верификацию взаимодействия компонентов на соответствующем уровне описания комплекса программ. Разработка спецификаций тестов (эталонов) на основе спецификаций требований, создает базу для обнаружения, какие требования не тестировались или принципиально не могут быть проверены тестированием. Таким образом, верификация спецификаций требований тестов к функциям и характеристикам программных компонентов могут использоваться с двумя целями:

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

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

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

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

- целостный комплекс требований к функциям, характеристикам, архитектуре и качеству тестов, адекватно отражающих и покрываюЛекция 1.6. Эталоны типов тестов и изменения требований… щих полный набор требований заказчика или программного менеджера проекта к программным компонентам и комплексу;

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

программные «оракулы» – неформальные знания и представлений тестировщиков на основе опыта создания предшествовавших аналогичных компонентов и комплексов программ в реализованных проектах или специальных имитационных программах и правила их формирования;

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

реальные объекты внешней среды и системы, являющиеся источниками и потребителями информации при применении комплекса программ;

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

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

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

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

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

Представление тестов программных компонентов и комплексов на базе достоверных и полных к ним требований, предполагает использование трудоемких процессов формирования таких исходных эталонов. Это может быть необходимо при разработке программных компонентов для сложных комплексов программ с требованиями обеспечения и гарантирования высокого качества, надежности и безопасности функционирования критических систем. В более проВ.В. Липаев. Тестирование компонентов и комплексов программ стых проектах широко применяется более экономичный, полуформальный метод формирования тестов и выполнения тестирования на основе применения понятия тестовый «оракул».

Тестовый «оракул» – тип эталонов тестов для предсказания и оценки корректности поведения модуля или программного компонента, предназначенный для тестирования в определенных условиях. Предполагается, что тестировщик благодаря личному опыту и квалификации знает, или имеет конкурирующую, действующую или предшествующую версию программы, которая может имитировать основные варианты корректного поведения новой программы, предназначенной для тестирования. Тестировщику доверяется принятие решения о том, является ли сообщение об ошибке при исполнении программы достоверным и ее необходимо корректировать. Большинство методов исследовательского тестирования программных компонентов опирается в определенной степени на подходы, в которых в качестве «оракула» выступает тестировщик, хотя опыт такого тестирования включает в себя также применение в качестве «оракулов» результатов функционирования предшествующих аналогичных или «пилотных» моделей.

Когда документируется система тестов, то обычно пытаются точно описывать предстоящее тестирование. Даже точный «оракул» не всегда может рассказать все, что желательно знать о поведении тестируемой программы. Это относится к тестовым сценариям, начиная с исследовательских предположений и кончая написанными с помощью детальных сценариев последовательностей действий в тестах (скриптов). Тестовые сценарии, зафиксированные в скриптах, определяют действия, данные и ожидаемые результаты с некоторой неопределенностью. Неопределенность «оракула» – это, безусловно, нежелательное свойство при определении соответствия требованиям или рисков качества. В отличие от них, однозначные эталоны (требования) тестирования поддерживают воспроизводимые тесты, что важно для регрессионного тестирования, они позволяют сделать интерпретацию результатов тестирования менее зависимыми от человека, выполняющего тесты. Их можно контролировать, а другие специалисты могут изучить средства тестирования и понять, что и как было подвергнуто тестированию.

Следующие факторы, которые способствуют повышению качества, увеличению объемов документации и сложности тестов, целесообразно учитывать при тестировании по методу «оракулов»:

Лекция 1.6. Эталоны типов тестов и изменения требований… мозг человека способен обрабатывать одновременно только конечное число элементов информации, поэтому порядок, время и данные должны быть четко организованы при тестировании, требуют исчерпывающего документирования, чтобы убедиться, что нужные события в системе происходят в нужное время;

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

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

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

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

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

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

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

Подобные модели могут фиксировать потоки управления и/или потоки данных компонента, последовательность состояний, в которых может находиться программный компонент или комплекс и последовательность их обработки.

Можно проводить оценку степени покрытия требований относительно этих моделей, проверяя, что каждому узлу и каждой связи в графе соответствует тестовый сценарий. Оценка покрытия требует В.В. Липаев. Тестирование компонентов и комплексов программ учета, в какой степени тесты нацелены на пространство требуемых функций и характеристик программного компонента или комплекса.

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

Однако точные сценарии и типы тестов на базе эталонных требований имеют обратную сторону. Описание точного тестового сценария обычно очень многословное и сложное. Чем точнее и полнее документированы требования и сценарии тестирования, тем точнее должно быть предвидение о качестве исполнения программного компонента. Точность способствует повторному использованию тестов при регрессионном тестировании и предполагает также возможность сопровождения и модернизации тестов. Чем более точно подготовлены сценарии тестирования и эталоны, тем больше усилий требуется для их изменения, когда в тестируемую программу вносятся корректировки.

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

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

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

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

Программная имитация динамических тестов внешней среды на ЭВМ в реальном времени позволяет:

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

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

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

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

Формализация документов как эталонов Эксплуатационная документация должна обеспечивать эффективное применение программного продукта и точно отражать его назначение, функции, характеристики и требования, для использования квалифицированными специалистами-пользователями. Для этого эксплуатационные документы необходимо тестировать на полное соответствие выполнения всей совокупности требований и выбранных эталонов на программный комплекс, согласованных между менеджером В.В. Липаев. Тестирование компонентов и комплексов программ разработчиков и тестировщиками. В результате эксплуатационные документы можно использовать также как отдельный, независимый при разработке эталон и тип тестов для квалификационного тестирования реализации требований к функциям и характеристикам программного комплекса. Апробирование документов пользователями при применении программ является практическим методом тестирования корректности реализации требований к программному комплексу. Разработчики этих документов должны обеспечивать комфортное и корректное применение программных продуктов пользователями на основе ясного и непротиворечивого изложения в документах технологических процедур и операций для штатного применения, функционирования и получения требуемых результатов в версиях комплексов программ.

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

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

Технологическая документация процессов производства и обеспечения всего жизненного цикла, включающая подробные технические описания, и подготавливаемая как эталон для специаЛекция 1.6. Эталоны типов тестов и изменения требований… листов, ведущих проектирование, разработку и сопровождение комплексов программ, обеспечивает возможность их отчуждения, детального освоения, развития и корректировки программ и данных.

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

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

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

Стандарты рекомендуют генерировать большое количество документов. Ценность документации как эталона определяется, в частности, тем, насколько она помогает в организации процесса тестирования и поиске дефектов и ошибок комплекса программ. Хорошая документация должна обладать следующими преимуществами:

облегчать тестирование и применение других типов эталонов;

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

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

Базой эффективного управления документированием должен быть план, в котором задачи исполнителей частных работ согласованы с выделяемыми для них ресурсами, а также между собой по результатам и срокам их достижения. Реализация плана зависит от результатов выполнения производственных работ и документов и может требовать оперативной корректировки плана. Для этого необходимо следить за ходом проекта и документирования на всем протяжении жизненного цикла и сравнивать запланированные и фактические результаты работ и документы. Контроль адекватности и качества эталонных документов является органической функцией управления проектом и должен иметь средства регулирования поведения отдельных специалистов и коллектива разработчиков в целом.

В плане управления документированием и обеспечением качества внимание специалистов должно акцентироваться на анализе достигнутых результатов разработки, методах и средствах достижения заЛекция 1.6. Эталоны типов тестов и изменения требований… данных характеристик комплекса программ. При планировании и разработке комплекс документации должен проверяться и аттестовываться на выполнимость и полноту в условиях ограниченных ресурсов, а также на корректность, адекватность и непротиворечивость отдельных документов.

Сложность, количество и полнота содержания набора документов, в первую очередь, зависят от масштаба – размера программного комплекса, что целесообразно оценивать в начале проектирования. Для решения этой задачи необходимо детально исследовать требуемые ресурсы современных процессов создания, документирования и использования программ различных классов и назначения встроенных, коммерческих, административных, учебных, уникальных. Состав и шаблоны документов целесообразно базировать на серии международных стандартов, многие из которых адаптированы как ГОСТ Р (см. Приложение 1). Эти стандарты охватывают жизненный цикл систем и программных комплексов, а также их документооборот. Стороны – участники проекта программного комплекса, ответственны за выбор экономически эффективной модели состава и структуры документации для конкретного проекта и за адаптацию производственных процессов и шаблонов документов применительно к выбранной модели документооборота проекта программного комплекса.

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

Управление изменениями требований к Управление изменениями требований – одна из ключевых задач итерационного формирования требований к комплексам программ. Функции и характеристики сложных комплексов программ обычно изменяются в течение всего жизненного цикла. Значения требований в начале разработки почти всегда отличаются от фактически достигнутых при завершении проекта и поставляемого программного продукта. Кроме того, показатели качества могут быть субъективными и отражать различные точки зрения специалистов.

Необходимо уметь определять и примирять эти различные представления требуемого качества и их изменения, чтобы управлять ими должным образом на каждом этапе жизненного цикла (см. рис. 1.8).

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

Далее изменения требований рассматриваются как автономные объекты сопровождения и управления конфигурацией. При этом делается акцент на итерационное управление изменениями требований, однако подразумевается, что за ними непосредственно следует адекватная их реализация в программном комплексе. В соответствии с требованиями заказчика и/или пользователей по развитию и модификации программного комплекса в его жизненном цикле должен быть организован процесс сопровождения требований. После поставки заказчику версии программного комплекса в соответствии с договором и предложениями о модификации или отчетами о дефектах разработЛекция 1.6. Эталоны типов тестов и изменения требований… чик должен изменять требования к соответствующим программам и документам.

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

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

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

В.В. Липаев. Тестирование компонентов и комплексов программ Поэтому изменения требований, обусловленные ошибками и выявленными дефектами, в большинстве случаев целесообразно накапливать и реализовывать, приурочивая к изменениям, регламентированным модернизациями версий.

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

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

Возможные затраты на развитие и совершенствование требований к версии комплекса программ зависят, прежде всего, от запросов и потребностей пользователей на новые функции и от готовности заказчика и разработчика удовлетворить эти потребности. Величина этих затрат определяется рыночной конъюнктурой для данного программного продукта и коммерческой целесообразностью его модификации и развития. По размеру вновь вводимых в очередную версию функций и компонентов с учетом степени новизны требований Лекция 1.6. Эталоны типов тестов и изменения требований… для их разработки могут быть оценены затраты на реализацию. Организация и качество конфигурационного управления, а также структура и интерфейсы конкретного проекта существенно влияют на эту долю затрат при сопровождении. Дополнительные затраты могут потребоваться на комплексирование и испытания новых компонентов в составе очередной версии программного комплекса, а также на доработку документации.

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

анализ предложений о модификации требований и отчетов о их дефектах;

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

разработку вариантов реализации изменения требований;

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

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

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

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

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

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

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

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

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

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

Совет руководителей проектом по управлению изменениями требований к комплексу программ должен решать, какие изменения следует реализовать, при этом:

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

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

анализ влияния изменения на проект и пользователей необходимо выполнять для каждого изменения;

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

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

На практике можно делегировать принятие некоторых детальных решений, касающихся требований разработчикам, однако ни одно соглашение, влияющее на работу системы, не должно идти в обход процесса контроля и утверждения изменений. Процесс изменений требований должен иметь быстрый путь, чтобы ускорять не рискованные и дешевые изменения в сжатом цикле принятия и реализации решений. Запрос на изменение требований должен проходить через определенные этапы на протяжении жизненного цикла комплекса программ, причем на каждом он имеет различные статусы и права (см. таблицу 1). Группа специалистов, которая подготавливает решение, может утвердить или отклонить каждое предложенное изменение для определенного компонента или всего комплекса. Руководитель проекта или менеджер, возглавляющий Совет по управлению изменениями, обладает правом принятия окончательного решения на утверждение крупных изменений версии комплекса программ.

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

Персонал сопровождения требований должен устанавливать процеЛекция 1.6. Эталоны типов тестов и изменения требований… дуры для получения, записи и сообщений о дефектах, проблемах и запросах на изменения требований от заказчика и пользователей и для обеспечения обратной связи к ним. Следует устанавливать функциональную связь с процессом управления конфигурацией для управления модификациями в существующем программном комплексе.

Организация изменений и сопровождения требований к Стратегия сопровождения требований должна быть ориентирована на людские и материальные ресурсы, необходимые и доступные для обеспечения развития и модификаций программного продукта. Этот анализ является исходным, и должен быть определен в общей стратегии сопровождения программного продукта. Анализ дефектов и модификаций требований включает оценку их влияния на организацию, существующую систему и интерфейсы системы для:

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

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

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

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

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

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

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

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

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

В.В. Липаев. Тестирование компонентов и комплексов программ определить, как будут введены предлагаемые модификации в базу данных учета конфигурации изменений требований и используемых ресурсов.

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

Для сохранения и повышения качества сложных комплексов программ необходимо регламентировать процессы модификации и совершенствования требований, а также поддерживать их контролем качества. Технология сопровождения требований должна обеспечивать итерации координированного развития множества версий программного комплекса и их компонентов, каждая из которых имеет достаточно высокое качество и специфические функции, а также, возможно, различных пользователей. Благодаря этому со временем программные комплексы должны улучшаться и совершенствоваться как по функциональным возможностям, так и по качеству решения каждой задачи.

Сопровождаемость – возможность регламентированной модификации комплекса программ является важной характеристикой, для заказчиков, поставщиков и пользователей, отражающей возможность и простоту внесения изменений в требования и в программный комплекс после его ввода в эксплуатацию (стандарт ISO 14764). Эти требования количественно можно устанавливать как изменяемость и тестируемость экономическими категориями допустимой трудоемкости и длительности реализации этих задач при некоторых средних условиях. Требуемые значения зависят от четкости концепции и архитектуры комплекса программ, от унифицированности внутренних, внешних и с пользователями интерфейсов, от качества технологической документации, а также от инструментальной оснащенности.

Обобщенно это отражается на длительности и трудоемкости подготовки и реализации типовых изменений, обусловленных необходимостью устранения дефектов и усовершенствованиями функций комЛекция 1.6. Эталоны типов тестов и изменения требований… плекса программ. Для подготовки и выполнения каждого изменения (без учета затрат времени на обнаружение и локализацию дефекта) нужно устанавливать допустимую среднюю продолжительность и суммарную трудоемкость работ специалистов при их реализации.

Сопровождаемость требований должна быть определена до начала первичной разработки проекта комплекса программ соответствующим соглашением между заказчиком и разработчиком - поставщиком. Разработчик должен подготовить план обеспечения сопровождения требований, в котором отражены конкретные методы, соответствующие ресурсы и последовательности работ. Следует определить необходимые затраты по обеспечению мониторинга и оценки сопровождаемости в процессе разработки. Требования к процессам сопровождения определяются группой основных факторов, влияющих на реализацию модификации программных комплексов, образующих концептуальную цепочку: требования на изменения – изменяемые функции – размер (масштаб) изменений – стратегия модификаций – ресурсы, необходимые для их реализации. Эта логическая схема обычно используется при последовательном анализе процессов сопровождения сложных комплексов программ. При этом основным критерием оценки сопровождения требований является совершенствование функциональной пригодности и улучшение характеристик качества программного комплекса.

Основной процесс эксплуатации в жизненном цикле может инициировать процесс сопровождения требований программного комплекса путем представления предложений о модификации (изменении) или отчетов о дефектах. Процесс сопровождения программного продукта в соответствии со стандартом ISO 12207 и детализацией этого раздела в стандарте ISO 14764 должен использовать основной стандартизированный процесс разработки комплексов программ и вспомогательные процессы документирования, управления конфигурацией, обеспечения качества, верификации, аттестации, совместного анализа, аудита и устранения дефектов. Организационные процессы управления, создания инфраструктуры и обучения должны определяться менеджером в начале сопровождения требований.

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

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

рис. 1.8). Процедуры могут быть использованы как разработчиком оригинала версии программного комплекса, так и независимым сопроводителем и охватывать:

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

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

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

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

При подготовке процесса изменения требований следует создать планы и определить процедуры, выполняемые при реализации сопровождения. План сопровождения требований целесообразно создавать параллельно с планом разработки первой версии программного продукта. При выполнении данной работы сопроводитель также должен определить необходимые организационные интерфейсы и взаимосвязи между специалистами и с другими предприятиями. Для обеспечения эффективной реализации процесса сопровождения следует разработать и документально оформить стратегию проведения сопровождения требований. При реализации этой деятельности необходимо: разработать планы и процедуры сопровождения; установить процедуры рассмотрения предложений о модификации и отчетов о дефектах; применить управление конфигурацией. Сопроводитель должен разработать, документально оформить и выполнить планы и Лекция 1.6. Эталоны типов тестов и изменения требований… процедуры для проведения работ и решения задач процесса сопровождения требований.

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

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

точность и логическая организация данных;

интерфейсы (системные, машинные и пользователей), особенно новые и перспективные интерфейсы;

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

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

неоднородность требований, определяющая простоту или сложность их трассировки и прослеживания;

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

Целенаправленная и методичная экспертная оценка возможного масштаба и ресурсов на изменения уменьшает величину ошибок, однако обычно она остается все-таки довольно большой. Для обеспечения достоверности первичное прогнозирование целесообразно проводить путем экстраполяции на базе накопленных конкретных данных об отдельных аналогичных модификациях версий программного комплекса. Важной частью концепции сопровождения требований и их реализацией является определение ресурсов и специалистов (физических или юридических), отвечающих за сопровождение. Это в равной степени справедливо и в случае внутреннего сопровождения в производственной организации. При выполнении сопровождения по соглашению с третьей стороной это должно быть отмечено в концепции. Выбор предприятия сопроводителя должен быть основан на анализе следующих факторов:

возможный срок службы программного комплекса;

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

необходимая квалификация сопровождающего персонала;

В.В. Липаев. Тестирование компонентов и комплексов программ функциональная пригодность и работоспособность исходной версии программного комплекса;

программа (график) модификаций и сопровождения;

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

Должна быть проведена оценка условий финансирования и стоимости сопровождения требований. Стоимость зависит от размера возможной области изменения характеристик программного комплекса при сопровождении. Дополнительными факторами являются стоимости: обучения как сопроводителей, так и пользователей;

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

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

Сопроводитель должен согласовать и получить подтверждение того, что внесенные изменения удовлетворяют требованиям заказчика, установленным в договоре: посредством вспомогательного процесса обеспечения качества; испытаний выполнения этого процесса;

проведения аудита функциональной и физической конфигурации. Результатами данной работы являются: новая версия, включающая в себя принятые изменения требований; отклоненные изменения; отчет о приемке версии; отчеты о проверках и аудитах; отчет о квалификационном тестировании и испытаниях. Требования к функциональным характеристикам и качеству, утвержденные после изменений требований, могут быть закреплены в техническом задании как обязательные для детального и рабочего проектирования модификации.

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

При детальном проектировании изменений может быть целесообразен контроль реализации договора и уточнение совокупности функциональных характеристик и качества модифицированных версий, а также соотношения качества и затрат ресурсов на изменения комплекса программ. Для заказчика и пользователей при сопровождении может иметь значение не только определение функциональной пригодности, но и оценка потенциального спроса на рынке конкретного комплекса, а также его конкурентоспособности с другими аналогичными по функциям программными комплексами с учетом его качества и стоимости. Это обстоятельство может определять необходимость контроля реализации и уточнения требований к отдельным характеристикам для оценивания интегрального качества новой версии, поставляемой на рынок.

В.В. Липаев. Тестирование компонентов и комплексов программ

ВЕРИФИКАЦИЯ, ТРАССИРОВАНИЕ И

ОБЕСПЕЧЕНИЕ БАЛАНСА ТРЕБОВАНИЙ К

КОМПЛЕКСАМ ПРОГРАММ

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

Удовлетворение потребностей заказчика является целью любого программного проекта. Соответственно, обеспечение качества, полноты и корректности требований в проекте невозможно представить без адекватных процессов работы с ними – начиная с верификации требований, заканчивая проверкой соответствия получаемого программного комплекса этим требованиям на всех этапах его создания (рис. 1.9) Верификация – это действия по проверке выполнения на п-ом этапе процесса разработки того, что было запланировано на (п-1)-ом этапе. Во время создания архитектуры системы и при определении требований специалист по тестированию должен сравнивать обусловленные архитектурой ресурсы с общими требованиями. Во время тестирования рабочей проектной документации тестировщик должен сверять эту документацию с документацией по архитектуре, которая была разработана на этапе высокоуровневого проектирования. Постоянно выполняемый процесс проверки того, что каждый шаг разработки является корректным, удовлетворяет потребности последующей деятельности и не является излишним, называется верификацией.

Лекция 1.7. Верификация, трассирование и обеспечение баланса… Верификация, трассирование и обеспечение баланса требований к комплексам программ должны включать:

- верификацию качества требований к комплексам программ:

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

верификацию требований к функциям системы;

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

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

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

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

направления трассировки: к требованиям компонентов и от явную и неявную трассировку требований к компонентам;

корректную матрицу трассировки требований к компонентам;

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

поэтапную разработку и уточнение спецификаций требований к комплексам программ;

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

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

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

Стандарт IEEE 1012 определяет верификацию как процесс последовательного оценивания системы, комплекса, компонента или модуля с целью определить, удовлетворяют ли их результаты условиям, наложенным на предыдущем этапе разработки.

В.В. Липаев. Тестирование компонентов и комплексов программ Таким образом, верификация в значительной мере является аналитической деятельностью, в ходе которой необходимо убедиться, что каждая стадия разработки (например, реализация в программном комплексе одного или нескольких требований) соответствует требованиям, заданным на предыдущей стадии:

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

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

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

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

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

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

обнаружение и разрешение конфликтов между требованиями;

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

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

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

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

Эффективным методом реализация корректной (правильной) системы, адекватной требованиям является использование прототипов требований и прецедентов их реализации в качестве основы архитектуры и реализации проекта. Необходимо идентифицировать все возможные источники требований, значимые для решения задач проекта. Только после этого можно верифицировать и определять их влияние на продукт. Следует оценивать степень полноты информированности источников требований и их значимость для учета влияния на цели проекта системы и комплекс программ:

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

состав и квалификацию заинтересованных лиц;

операционное и внешнее окружение среды;

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

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

Нельзя ограничиваться механическим применением верификации.

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

В.В. Липаев. Тестирование компонентов и комплексов программ Чтобы принять решение о том, какая часть системы нуждается в верификации и проверке корректности и в каком объеме, целесообразно применять анализ и оценку рисков. Это позволяет определить, для каких компонентов требований их неправильная реализация недопустима, а также разработать план действий по верификации и проверке правильности, основываясь на результатах этих оценок. На этом этапе следует привлекать к управлению требованиями и анализу их корректности, специалистов по тестированию, подключая их к планированию тестов с самого начала проекта. Группа тестирования должна разрабатывать тестовые процедуры и сценарии, которые трассируются к прецедентам, а также функциональным и конструктивным требованиям.

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

Если заказчик проекта требует гарантировать независимую верификацию всего комплекса требований, то должна быть выбрана квалифицированная организация, ответственная за выполнение полной верификации. Этой организации должны гарантироваться независимость и полномочия верификационной деятельности по обеспечению корректности совокупности требований. Должны быть определены плановые действия жизненного цикла системы и программные продукты, требующие верификации. План должен определять требуемые верификационные задачи для каждой деятельности жизненного цикла программного продукта и связанные ресурсы, обязательства и программы. Дефекты и несоответствия, обнаруженные при верификации, должны быть введены в процесс корректировки требований к комплексу программ. Результаты верификационной деятельности должны быть доступны заказчику и потребителю системы и программного продукта.

Лекция 1.7. Верификация, трассирование и обеспечение баланса… Основные регламентированные задачи верификации проектов систем и программных комплексов отражены в стандарте ISO 12207 и включают в свой состав следующие задачи и критерии (см. рис. 1.9):

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

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

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

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

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

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

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

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

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

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

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

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

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

В.В. Липаев. Тестирование компонентов и комплексов программ - верификация интеграции модулей, компонентов и комплекса программ по критериям:

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

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

- верификация документации по критериям:

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

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

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

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

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

Назначение верификации комплекса программ состоит в том, чтобы обнаружить, зарегистрировать и устранить дефекты и ошибки, которые могли быть внесены в требования во время разработки или модификации программ. Основное назначение верификации проверить, что (см. рис. 1.9):

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

Лекция 1.7. Верификация, трассирование и обеспечение баланса… требования высокого уровня к комплексу программ правильно переработаны в архитектуру комплекса и в требования к функциональным компонентам низкого уровня и модулям, которые удовлетворяют требованиям высокого уровня;

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

Цели верификации требований к комплексу программ достигаются посредством последовательного выполнения комбинаций из трассировки, анализов, разработки тестовых сценариев и процедур, и возможности последующего выполнения этих процедур. Трассировки и анализы должны обеспечивать оценку точности, полноты и верифицируемости требований, архитектуры комплекса и исходного текста программ. Тестовые сценарии предназначены для проверки внутренней непротиворечивости и полноты реализации требований. Анализ тестовых процедур должен обеспечивать демонстрацию соответствия требований к программным модулям и компонентам, исходным требованиям к программному комплексу (рис. 1.10).

В стандартах на жизненный цикл при выполнении работ по верификации комплекса программ рекомендуется следующая последовательность основных процедур:

должны быть проверены корректность и непротиворечивость исходных требований высокого уровня (контракта) и продемонстрирована трассируемость и прослеживаемость к ним последующих требований;

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

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

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

Верификация, просмотры и анализы требований высокого уровня предназначены обнаруживать, регистрировать и устранять ошибки, которые внесены в процессе разработки и преобразования требований к комплексу программ. Эти просмотры и анализы должны подтвердить корректность и согласованность требований высокого уровня, а также гарантировать, что:

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

Лекция 1.7. Верификация, трассирование и обеспечение баланса… каждое требование высокого уровня к программному комплексу является точным, однозначным и достаточно детализированным, требования не конфликтуют друг с другом;

не существует конфликтов между требованиями высокого уровня и возможностями аппаратных и программных средств реализующей ЭВМ, особенно такими, как время реакции системы и аппаратура ввода/вывода;

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

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

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

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

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

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

Верификация, просмотры и анализы тестовых вариантов, процедур и результатов должны показать, что требования к тестированию комплекса, компонентов и модулей разработаны и могут выполняться точно и полностью (см. рис. 1.10). Должно быть рассмотрено и подтверждено верификацией, что тестовые сценарии и варианты исходных данных правильно представлены в процедурах тестирования и ожидаемых результатах; гарантируют, что составы результатов тестирования требований являются корректными и что объяснимы расхождения между фактическими и ожидаемыми результатами.

Неприятным моментом верификации является то, что можно потратить время на верификационную деятельность, которая не принесет ожидаемой отдачи. Поэтому нужен способ предварительной оценки «экономической эффективности» верификационной деятельности. В той или иной степени оценкой затрат на верификацию приходится заниматься на каждой стадии разработки. Она необходима, чтобы удостовериться в правильности и затратах на переходы:

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

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

от архитектуры к модели проектирования и производства Лекция 1.7. Верификация, трассирование и обеспечение баланса… модулей, компонентов и комплекса программ;

от реализации модулей, компонентов и комплекса программ к планированию и реализации совокупности тестов (см. рис. 1.10).

Особое внимание следует уделять этапу завершения проекта.

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

Трассирование требований к сложным комплексам Поддержка верификации осуществляется путем использования методов трассировки требований, что позволяет связывать друг с другом части проекта, проводить проверку адекватности требований к прецедентам их реализации и функциям, и обратно. С помощью трассировки можно удостоверяться в том, что:

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

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

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

Если одно или несколько требований к программному компоненту создаются с целью поддержки некоторой функции, заданной в исходном документе, то требование трассируется от некоторой функции. Если некоторое требование к программному компоненту «трассируется к» определенному тестовому сценарию, то данное требование тестируется этим скриптом. То, что описание компонента «трасВ.В. Липаев. Тестирование компонентов и комплексов программ сируется от» конкретного программного требования, подразумевает, что это требование реализуется указанным компонентом.

Потребности заказчика должны отслеживаться путем анализа содержания требований, чтобы можно было определить, какие требования будут затронуты, если в течение или после разработки, потребности изменятся. Это также дает уверенность, что в спецификации требований указаны все потребности заказчика. Кроме того, можно проследить в направлении от требований к потребностям заказчика, чтобы определить происхождение каждого требования к комплексу программ. Если необходимо представить потребности заказчика в форме сценариев использования функций, то анализ должен отражать трассирование между вариантами использования и функциональными требованиями.

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

Если трассировщик обнаружит незапланированную функциональность при отсутствии соответствующего требования, то фрагмент программы может свидетельствовать, что разработчик реализовал требование, которое аналитик или заказчик может добавить к спецификации. Однако это может быть элемент программы, «украшающий» фрагмент, который не относится к комплексу. Связи трассируемости помогут сортировать подобные ситуации и получать более полное представление о том, как именно компоненты системы составляют целое, соответствующее требованиям. Сценарии верификации или тестирования, которые созданы на основе отдельных требований, которые можно проследить до этих требований, представляют собой механизм выявления нереализованных требований, поскольку нет ожидаемой функции или компонента. Не всегда необходимо определять и управлять всеми типами связей трассируемости.

Лекция 1.7. Верификация, трассирование и обеспечение баланса… Во многих проектах удается получать 80% эффекта от применения трассируемости для выявления дефектов, вложив приблизительно 20% усилий от требующихся для полного покрытия контролем заданных требований. Если нужно отслеживать тестирование системы только до функциональных требований или сценариев использования, то следует решать, какие связи уместно контролировать, и это в значительной степени будет способствовать успешной разработке и эффективной модификации комплекса. Пропуск реализации, верификации и тестирования требования может быть существенным дефектом, если заказчик не удовлетворен или в готовом продукте отсутствует функция, особо важная для обеспечения надежности или безопасности.

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

Если в ходе разработки тщательно фиксируются данные трассируемости требований, у руководителей будет точное представление о состоянии реализации запланированной функциональности и характеристик программного комплекса. Отсутствующие связи от требований указывают на компоненты, которые еще не созданы. Если тестирование дает неожиданный результат, то трассирование связей между тестами, требованиями и текстом модулей и компонентов могут указать на наиболее вероятные части программного кода, которые необходимо проверить на наличие проявления дефектов. Информация о том, какие тесты проверяют какие требования, экономит время, позволяя удалять лишние, выявлять и создавать необходимые тесты (см. рис. 1.10). Без информации трассируемости возрастает вероятность того, что из тестирования будут упущены компоненты, которые вызовут необходимость добавления, удаления или изменения определенных требований.