Раздел 3.2 посвящен усовершенствованиям процесса, которые позволяют уменьшить количество отбраковок и доработок, исключить некоторые шаги и минимизировать число итераций. Другой формой совершенствования процесса является повышение эффективности конкретных шагов. Здесь свой важнейший вклад должна внести среда, а именно: требуется автоматизировать задачи, выполнение которых вручную неэффективно или чревато ошибками. Переход к более зрелому процессу создания ПО приводит к появлению новых решений и возможностей в области контроля, осуществляемого менеджерами, над параллельными видами деятельности для достижения осязаемого прогресса и для оценки качества. Опыт выполнения проектов показал, что интегрированная в высокой степени среда является необходимой как для упрощения, так и для усиления контроля за процессом, осуществляемого менеджерами. Среда, обеспечивающая семантическую интеграцию (при которой среде понятен в деталях смысл результатов разработки) и автоматизацию процесса, может способствовать росту производительности, повышению качества ПО и ускорению процесса освоения современных методов. Среда, которая поддерживает пошаговую компиляцию, автоматизированное построение системы и интегрированное регрессионное тестирование, может обеспечить ускорение цикла при итерационной разработке и позволяет командам разработчиков выполнять итерации более свободно.
Серьезное внимание при современном подходе уделяется определению среды разработки и сопровождения как предмету первой необходимости для процесса разработки. Стабильная интегрированная среда разработки обязана поддерживать автоматизацию процесса разработки. Такая среда должна включать в себя управление требованиями, автоматизацию документирования, исходные/целевые (host/target) средства программирования, автоматизированное регрессионное тестирование, постоянное и интегрированное управление изменениями и отслеживание дефектов. Основная линия для успешного хода проекта заключается в найме хороших исполнителей и в обеспечении их хорошими инструментами для выполнения своей работы. Автоматизация процесса разработки позволяет получить выигрыш в качестве, в возможности оценки стоимости и сроков и в общей продуктивности при использовании меньшей команды. Интегрированные наборы инструментов играют все более важную роль в пошаговой/итерационной разработке, позволяя разработчикам быстро ориентироваться в получаемых продуктах и своевременно вносить в них изменения.
Разработка по «круговому» (round-trip) принципу - это термин, используемый для описания ключевых возможностей среды, которая поддерживает итерационный подход. По мере того как различные продукты разработки оказываются размещенными в различных хранилищах информации, возникает необходимость в гарантии эффективного и безошибочного переноса данных из одних продуктов в другие. Прямое проектирование (forward engineering) — это автоматизация процесса получения некоторого продукта из более абстрактного представления. Например, компиляторы и загрузчики обеспечивают автоматическое преобразование исходного кода в выполняемый код. Обратное проектирование (reverse.
engineering) — это генерация или модификация более абстрактного представления из существующего продукта (например, создание визуальной модели из исходного кода).
«Круговая» разработка описывает такую поддержку среды, которая позволяет свободно вносить изменения в отдельные продукты. При этом остальные продукты автоматически изменяются таким образом, чтобы весь набор продуктов, связанных с требованиями, разработкой, реализацией и вводом в действие, сохранял свою непротиворечивость (см. главу 12).
По мере того как в архитектуре стали использоваться разнородные компоненты, платформы и языки, сложность создания, управления и сопровождения крупномасштабных сетей компонентов привела к появлению новых потребностей в области управления конфигурацией и автоматизации управления процессом создания. Однако степень поддержки автоматизации существующих на сегодняшний день сред далека от желаемой. Например, автоматизированное построение тестового варианта из описаний варианта использования и сценария до сих пор находится на такой стадии развития, при которой не поддерживается ничего, кроме наиболее тривиальных случаев, таких как сценарии для тестирования отдельных элементов.
Описывая экономические выгоды, связанные с инструментарием и различными средами, следует сделать одно предостережение. Зачастую поставщики инструментов дают относительно точные индивидуальные оценки потенциального экономического эффекта от использования их инструментов в течение всего жизненного цикла. Например, в какой-нибудь отдельной «инструментальной» нише часто можно встретить подобные утверждения:.
■ На анализ требований и деятельность, направленную на развитие, тратится 40% общих затрат в жизненном цикле.
■ Деятельность по разработке ПО оказывает влияние на более чем 50% ресурсов.
■ Этапы кодирования и тестирования составляют свыше 50% от всей работы и занимают более 50% всего времени.
■ Проведение тестирования может потребовать до 50% всех ресурсов проекта.
■ Управление конфигурацией и изменениями — это критичные виды деятельности, на которые может расходоваться до 25% ресурсов крупномасштабного проекта.
■ На создание документации может тратиться более 30% ресурсов, отпущенных на разработку проекта.
■ Управление проектом, бизнес-администрирование и оценка прогресса могут стоить до 30% от бюджета проекта.
Если рассматривать их по отдельности, то каждое из них нельзя назвать неправильным, они просто слишком примитивны. (Если верить им всем, то оказывается, что на выполнение большинства проектов требуется до 275% времени и денег!) Объединенные вместе, эти утверждения могут ввести в заблуждение. Остерегайтесь заключений такого рода:.
Данный инструмент для тестирования позволяет увеличить продуктивность тестирования на 20%. Поскольку выполнение тестирования занимает 50% от всего жизненного цикла, то чистый выигрыш в производительности для проекта в целом составит 10%. При общем бюджете в один миллион долларов на инструменты для тестирования можно потратить $100 ООО.
Взаимоотношения между всеми видами деятельности по разработке ПО оказываются слишком сложными для того, чтобы такие простые рассуждения могли быть верными. По моему опыту, суммарный эффект от использования всех инструментов обычно ниже 40%, и большая часть этого выигрыша не может быть получена без внесения соответствующих изменений в процесс. Маловероятно, чтобы какой-либо отдельный инструмент мог повысить общую производительность проекта более чем на 5%. Вообще говоря, лучше относить большинство утверждений поставщиков к виртуальным 275%, чем к суммарным 100%, с которыми приходится иметь дело в реальной жизни.