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

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

Существует много возможностей для автоматизации процедуры планирования проекта и различных видов деятельности по контролю в рамках управления проектом. Инструменты для оценки затрат и WBS-инструменты оказываются полезными для генерации рабочих продуктов по планированию. Для управления в соответствии с планом лучше использовать такие инструменты для управления и такую «панель управления» проекта, которые поддерживают текущую оценку состояния проекта в онлайновом режиме. Такой подход к автоматизации может значительно улучшить понимание множества параметров и правил отчетности (см. главу 13). Общая концепция «панели управления» проекта по созданию ПО обсуждается в разделе 13.6.

Среда.

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

Рис. 12.1. Типичные компоненты автоматизации и инструменты, которые поддерживают различные рабочие процессы.

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

Требования.

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

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

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

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

Этот подход в применении к поддержке управления требованиями имеет две составляющие:.

1.

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

2.

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

Проектирование.

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

.

Реализация.

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

Оценка и внедрение.

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