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

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

Появление строгих и более мощных нотаций для описания требований и проекта, которые поддерживают упреждающую разработку архитектуры, явилось большим технологическим достижением. В частности, Unified Modeling Language превратился в удобный формат представления, а именно, в визуальные модели с четко определенными синтаксисом и семантикой для рабочих продуктов, связанных с требованиями и проектированием. Визуальное моделирование с использованием UML — это простая нотация для рабочих продуктов ранних этапов жизненного цикла. Комплекты продуктов показаны на рис. 6.1; их цели и нотации обсуждаются ниже.

Рис. 6.1. Обзор комплектов продуктов.

6.1.1 Комплект управления.

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

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

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

■ Рассмотрение соответствующими заинтересованными сторонами.

■ Анализ изменений, т.е. отличий текущей версии продукта от предыдущей версии (тенденции управления и тенденции изменения хода выполнения проекта в терминах стоимости, сроков и качества).

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

6.1.2 Комплекты разработки.

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

Комплект требований.

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

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

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

■ Анализ непротиворечивости по отношению к спецификациям версий из комплекта управления.

■ Анализ непротиворечивости между общей концепцией и моделями требований.

I.

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

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

■ Субъективное рассмотрение других составляющих качества.

Комплект проектирования.

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

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

■ Анализ внутренней непротиворечивости и качества проектной модели.

■ Анализ непротиворечивости по отношению к моделям требований.

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

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

■ Субъективное рассмотрение других составляющих качества.

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

Комплект, реализации.

Комплект реализации включает в себя исходный код (запись на языке программирования), который представляет собой реализации компонентов (их форму, интерфейс и зависимости), и все требуемые для автономного тестирования компонентов исполняемые файлы. Исполняемые файлы являются простыми составными частями, необходимыми для создания конечного продукта, включая компоненты, созданные на заказ, программные интерфейсы (API) коммерческих компонентов, а также API компонентов повторного использования или компонентов, имеющихся в исходном языке программирования (например, в Ada 95, C++, Visual Basic, Java или Assembly). Рабочие продукты комплекта также можно транслировать (скомпилировать и отредактировать связи) в подмножество комплекта внедрения (исполняемые файлы в окончательном виде). Конкретные рабочие продукты включают в себя самодокументируемый исходный код продукта и связанные с ним файлы (сценарии компиляции, инфраструктура для управления конфигурацией, файлы с данными), самодокументируемый тестовый исходный код и связанные с ним файлы (файлы с входными данными для тестирования, файлы с результатами тестирования), исполняемые файлы для независимого запуска компонентов и файлы для проведения тестирования компонентов.

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

■ Анализ непротиворечивости по отношению к проектным моделям.

■ Перевод в нотации комплекта внедрения (например, компиляция и редактирование связей) для определения непротиворечивости и полноты различных комплектов рабочих продуктов.

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

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

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

■ Субъективное рассмотрение других составляющих качества Комплект, внедрения.

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

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

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

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

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

■ Анализ изменений в текущей версии комплекта внедрения по сравнению с предыдущими версиями (тенденции уменьшения количества дефектов, изменения в производительности).

■ Субъективное рассмотрение других составляющих качества.

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

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

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

Большинство из современных инструментов разработки ПО почти точно соответствует одному из пяти комплектов рабочих продуктов.

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

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

2.

Требования: инструменты для управления требованиями.

3.

Проектирование: инструменты для визуального моделирования.

4.

Реализация: инструменты для компиляции/отладки, анализа кода, тестового покрытия и инструменты для управления тестированием.

5.

Внедрение: инструменты для анализа тестового покрытия и автоматизации тестирования, средства управления сетями, коммерческие компоненты (операционные системы, GUI, СУБД, сети, промежуточное ПО), средства инсталляции.

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

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

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

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

■ Эффекты от оптимизации при компиляции/редактировании связей (такие, как оптимизация использования памяти вместо оптимизации быстродействия).

■ Производительность при конкретной стратегии размещения (централизованная против распределенной, главные и вторичные процессы, динамическое распределение загрузки, немедленное резервное копирование против контрольных точек/отката).

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

■ Параллелизм на уровне процессов (тупиковые ситуации и борьба за ресурсы).

■ Различия в производительности или поведении в зависимости от платформы.

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

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

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

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

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

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

Внедрение коммерческих продуктов у заказчиков может также охватывать широкий диапазон тестовых и рабочих конфигураций. Например, продукты класса промежуточного ПО являются быстродействующими надежными посредниками при запросе объектов (object request brokers), которые поставляются в реализациях для различных платформ, включая операционные системы рабочих станций, «голые» бортовые процессоры, операционные системы больших машин и различные операционные системы реального времени. Конфигурации продукта поддерживают различные компиляторы и языки, а также различные реализации сетевого ПО. Гетерогенный характер возможных конфигураций приводит к необходимости иметь чрезвычайно изощренную структуру исходного кода и гигантский набор различных рабочих продуктов внедрения.

6.1.3 Эволюция рабочих продуктов в течение жизненного цикла.

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

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

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

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

Рис. б.З. Эволюция комплектов рабочих продуктов в течение жизненного цикла.

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

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

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

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

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

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

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

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

,.

■ Рабочие продукты тестирования должны создаваться параллельно с продуктом от начала до внедрения. Таким образом, тестирование — , это деятельность, присущая всему жизненному циклу, а не только.

его поздним этапам.

.

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

■ Рабочие продукты тестирования реализуются в программируемом и воспроизводимом форматах (как и ПО).

■ Рабочие продукты тестирования документируются тем же образом, * что и сам продукт.

.

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

процесс обучения, что и разработчики ПО, создающие основной продукт.

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

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

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

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

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

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

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

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

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

■ Комплект внедрения. В него включаются исполняемые версии тестовых компонентов, тестовых драйверов и файлы с данными.

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