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

Итеративная и инкрементная разработка

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

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

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

Спиральная модель

Спиральная модель, предложенная Барри Боэмом в 1988 году (Boehm 88), дает хороший пример итеративного и инкрементного подхода.1

1Процесс Боэма не был первой итеративной моделью, но он первым популя%

ризировал и подчеркнул значение итерации.

Пошаговый прогресс

ние/написание

Рис. 22.4. Спиральная модель

Планирование

Происходит рецензирование проекта и составляются планы для очередного цикла спирали.

Методологии ускоренной разработки

Они появились как реакция на бюрократические и тяжеловесные мето% дологии, сковывавшие процесс разработки программного обеспечения. Те, кто занимается ускоренным программированием, исходят из того, что разработку программного обеспечения трудно сделать предсказуе% мым процессом; они утверждают, что программирование сильно отлича% ется от известных инженерных процедур типа проектирования моста.1 Старомодные монументальные методологии только мешают тем, кто старается писать хорошие программы, и потому их нужно отбросить.

Ускоренные методологии – это собирательный термин для целого ряда процессов разработки, включая разрекламированное экстремальное программирование, а также Crystal Clear и Scrum. Ускоренные про% цессы сосредоточены на быстроте и сокращении рисков, а не на долго% срочном планировании и достижении (мнимой) предсказуемости.

Ускоренные процессы основываются на следующих догмах:

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

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

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

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

•Подчеркнуть важность человеческого фактора и облегчить возмож% ность общения – предпочтительно личного, а не посредством доку%

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

для этого зрелости и жесткости данная отрасль пока не достигла.

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

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

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

Другие процессы разработки

Есть много других процессов разработки, являющихся вариациями на те же темы, но с характерными особенностями. Есть модифицирован% ные каскадные процессы с перекрытием фаз или с вложенными проек% тами, управляемыми как миниатюрные каскадные. Метод создания

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

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

Вускоренной разработке приложений (Rapid Application Development, RAD) делается акцент на участие пользователя и небольшую числен% ность команд разработчиков, активно применяются прототипы и сред% ства автоматизации. В качестве некоторого реверанса в сторону дру% гих процессов временны]е рамки разработки устанавливаются заранее и считаются неизменными. После этого в проект включается столько функций, чтобы уложиться в заданный срок; некоторые функции мо% гут оказаться принесенными в жертву.

Унифицированный процесс компании Rational (RUP)1 – примечатель% ная коммерческая методология от IBM, идущая от Objectory Process Айвара Джекобсона (Ivar Jacobson, 1987). Это тяжелый, но гибкий объектно%ориентированный процесс, активно применяющий UML%диа%

1Джим Арлоу, Айла Нейштадт «UML 2 и Унифицированный процесс»,

2%е издание. – Пер. с англ. – СПб: Символ%Плюс, 2007.