Экономические преимущества, сопутствующие переходу от традиционной водопадной модели к итерационному процессу разработки, значительны, но трудно поддаются количественному определению. В качестве одной из возможных точек отсчета для вычисления ожидаемого экономического эффекта от улучшения процесса можно рассмотреть.
экспоненциальные параметры процесса в модели СОСОМО II (см. приложение В). Эта экспонента может находиться в диапазоне от 1.01 (практически отсутствует плата за большой масштаб) до 1.26 (существенная плата за большой масштаб). К параметрам, определяющим значение экспоненты процесса, относятся наличие прецедентов для приложений, гибкость процесса, разрешение архитектурных рисков, сплоченность команды и зрелость процесса создания ПО.
Ниже показано, какие параметры экспоненты процесса по СОСО МО II соответствуют моим 10 наиважнейшим принципам современного процесса.
■ Наличие прецедентов приложений. Опыт в конкретной области является критичным фактором для понимания того, как планировать и выполнять проект. Для систем, не имеющих прецедентов, одной из ключевых задач является определение рисков и создание прецедентов на ранних этапах, пусть даже они будут незаконченными или экспериментальными. Это одна из главных причин, по которой индустрия ПО перешла к итерационным процессам жизненного цикла. Итерации, выполняемые на ранних стадиях жизненного цикла, создают прецеденты, на основе которых продукт, процесс и планы могут разрабатываться со все возрастающей степенью детализации.
■ Гибкость процесса. Разработка современного ПО характеризуется таким широким пространством решений и таким большим количеством взаимосвязанных понятий, что возникает необходимость постоянного внесения изменений. Эти изменения могут быть присущи пониманию проблемы, пространству решений или планированию. Для эффективного управления изменениями рабочие продукты проекта должны иметь поддержку среды, соразмерную требованиям проекта. Как чересчур жесткие процессы, так и процессы с хаотическими изменениями обречены на провал, за исключением наиболее тривиальных случаев. Для достижения возврата инвестиций в ПО необходим настраиваемый процесс, который позволяет приспособить общую схему для целого спектра проектов.
■ Разрешение рисков, связанных с архитектурой. В основе успешного итерационного процесса разработки лежит упреждающая разработка архитектуры. Команда разработчиков создает и добивается стабильности архитектуры до того, как приступить к разработке всего набора компонентов приложений. Подход с упреждающей разработкой архитектуры, основанный на компонентах, требует, чтобы инфраструктура, общие и управляющие механизмы были созданы на ранних стадиях жизненного цикла, и включает принятие решений о создании/покупке компонентов в процесс определения архитектуры. Такой подход инициирует начало интеграции на ранних стадиях жизненного цикла и верификации процесса разработки и продукта. Он также заставляет настроить и испытать среду разработки на ранних ее стадиях, способствуя таким образом раннему привлечению внимания к вопросам тестирования и оценок, основанных на демонстрации.
■ Сплоченность команды. Успешные команды сплочены, а сплоченные команды успешны. Нельзя с уверенностью утверждать, что является причиной, а что — следствием, но и сплоченные, и успешные команды имеют общие цели и приоритеты. Сплоченные команды избегают всего, что может стать источником проблем и роста энтропии проекта, являющегося результатом трудностей, которые возникают при попытке синхронизации требований различных заинтересованных сторон. Существует множество возможных причин для такого рода возмущений, но одной из основных является недостаток взаимодействия, в частности, обмен информацией исключительно посредством бумажных документов,, представляющих информацию субъективно. Достижения технологии (такие, как языки программирования, UML и визуальное моделирование) привели к появлению более строгих и понятных нотаций для обмена информацией, касающейся разработки ПО, особенно в части материалов по требованиям и по разработке, которые раньше были узкоспециализированными и целиком основывались на обмене бумагами. Форматы, основанные на моделях, оказались также способны поддерживать «круговую» разработку, необходимую для облегчения внесения изменений, что требуется для развития представлений проекта.
■ Зрелость процесса создания ПО. В качестве общепринятой точки отсчета при оценке процесса создания ПО используется предложенная Институтом программной инженерии (SEI) модель технологической зрелости (Capability Maturity Model, СММ). Подобно тому, как опыт в конкретной области знаний критичен и позволяет избегать рисков и использовать ценные качества и полученные уроки, так и технологическая зрелость процесса создания ПО критична и позволяет избегать рисков при разработке ПО и использовать ценные качества и полученные уроки в рамках данной организации. («За» и «против» СММ подробно обсуждаются в приложении Е.) Одной из ключевых тем данной книги является то, что действительно зрелый процесс может возникать только в рамках интегрированной среды, которая обеспечивает адекватный уровень автоматизации процесса для объективного контроля качества.