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

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

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

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

Рис. 11.2. Стандартная организация проекта и распределение обязанностей

Рис. 11.3. Виды деятельности команды управления проектом.

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

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

Команда по архитектуре ПО.

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

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

Рис. 11.4. Виды деятельности команды по архитектуре ПО.

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

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

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

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

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

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

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

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

Рис. 11.5. Виды деятельности команды по разработке.

Команда по разработке ПО.

На рис. 11.5 показано то, чему команда по разработке ПО должна уделять внимание на протяжении всего жизненного цикла.

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

■ Коммерческие компоненты: специалисты с детальным знанием коммерческих компонентов, занимающих центральное место в архитектуре системы.

■ Базы данных: специалисты с опытом организации, хранения и поиска данных.

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

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

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

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

Команда по оценке ПО.

На рис. 11.6 показано то, чему команда по оценке ПО должна уделять внимание на протяжении жизненного цикла проекта.

Существуют две причины использования независимой команды для оценки ПО. Первая касается гарантий независимости оценки качества. Этот часто обсуждаемый подход имеет свои «за» (например, гарантии того, что предубеждения авторов, коими являются разработчики, не исказят качество оценки) и «против» (например, освобождение команды по разработке ПО от ответственности за качество — до некоторой степени), Более серьезной причиной применения независимой команды тестирования является возможность осуществления различных видов

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

Рис. 11.6. Виды деятельности команды по оценке.

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

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

1.

Спецификаций версии (план и критерии оценки версии).

2.

Описания версии (результаты версии).

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

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

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

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