В период, когда «быстрые» методы разработки получают все более широкое распространение, некоторые считают итеративную, эволюционную и инкрементальную разработку «современным» решением, пришедшим на смену последовательной модели, тогда как корни данного подхода можно проследить в прошлом. Разумеется, это известно исследователям систем разработки программного обеспечения, но, как ни странно, многие и по сей день проявляют на этот счет полную неосведомленность. Многие примеры относятся к 70-м и 80-м годам — наиболее активным и наименее известным периодам истории IID.

Мы отказались от схемы глубокого сравнительного анализа и представили рассматриваемые подходы в хронологическом порядке. Описываемые методы разработки различаются в таких аспектах, как продолжительность итераций и использование жестких ограничений по времени. Но несмотря на все различия эти подходы имеют нечто общее: стремление отойти от последовательных, основанных на использовании детального документирования методов разработки «в один проход».

Наконец, одно замечание по поводу терминологии. Некоторые люди предпочитают сводить смысл выражения «итеративная разработка» к исправлению уже сделанного. Между тем, в контексте современных методов быстрой разработки этот термин означает нечто иное: не просто пересмотр проделанной работы, но и эволюционное продвижение вперед; в таком значении этот термин используется, по меньшей мере, с 1968 года.

До 70-х годов

Истоки концепции IID прослеживаются в относящихся к 30-м годам работах эксперта по проблемам качества продукции Уолтера Шеварта [1] из Bell Labs, который предложил ориентированную на повышение качества методику, состоящую из серии коротких циклов шагов по планированию, реализации, изучению и действию (plan-do-study-act, PDSA). С 40-х годов энергичным поборником PDSA стал известный авторитет в области качества Эдвардс Деминг, который затем описал эту методику в своей книге [2]. В более поздних работах Том Гилб [3] и Ричард Залтнер [4] исследовали PDSA применительно к разработке программного обеспечения.

Важная веха в истории IID — осуществленный в 50-е годы проект по разработке сверхзвукового реактивного самолета X-15 [5]. По мнению участников этих работ, применение данной методики в значительной степени определило успех проекта. Проектирование X-15 не имело отношения к разработке программного обеспечения. Однако о нем стоит упомянуть хотя бы потому, что некоторые его участники — а следовательно, и накопленный ими опыт в области IID — в начале 60-х годов были задействованы в проекте Project Mercury, осуществлявшемся в рамках NASA, где данная методика использовалась уже в контексте разработки программного обеспечения. Кроме того, некоторые из них перешли в подразделение корпорации IBM Federal Systems Division, где методика IID быстро получила признание.

Представление о методах работы, практиковавшихся в рассматриваемый период, можно почерпнуть из воспоминаний участника проекта Джеральда Уайнберга: «Мы применяли метод инкрементальной разработки еще в 1957 году, под руководством Берни Димсдейла в IBM Service Bureau Corporation. Он был коллегой Джона фон Неймана и, вероятно, познакомился с этой методикой именно при работе с ним или считал ее абсолютно естественной. Я также хорошо помню, как Херб Джейкобс занимался масштабным моделированием для Motorola. Он использовал этот прием, и, насколько я могу судить, методика была неотличима от XP.

Когда в 1958 году наша команда почти в том же составе вновь собралась для участия в Project Mercury, у нас была новая операционная система Share Operating System, допускавшая символьную модификацию и модульную сборку систем. Это позволило проектировать систему приращениями — что мы и сделали, добившись при этом большого успеха. Project Mercury — та питательная среда, из которой возникло подразделение IBM Federal Systems Division. Оно впитало в себя историю и традиции инкрементальной разработки.

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

Самым первым из обнаруженных нами текстов, специально посвященных описанию итеративной разработки и рекомендующим ее, был датированный 1968 годом доклад Брайана Рэнделла и Ф.В. Зерчера, сотрудников исследовательского центра IBM T.J. Watson Research Center [6]. Позднее М.М. Леман описал эту работу, положительно отозвавшись об инкрементальной разработке в своем составленном в сентябре 1969 года внутреннем докладе руководству IBM, который был посвящен рекомендациям по методике разработки [7]:

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

Еще одно относящееся к 60-м годам упоминание о рассматриваемом предмете вышло из-под пера Роберта Гласса [8]: «Автор полагает, что инкрементальная разработка дает положительный результат; она обеспечивает возможность более тщательного испытания системы и позволяет избежать осложнений, препятствующих ее внедрению и управлению».

70-е годы

В 1970 году Уинстон Ройс опубликовал получившую широкую известность статью Managing the Development of Large Software Systems. В ней он излагал свое мнение о методике, которая позднее получила название «модель водопада» (waterfall model), в контексте ограничений, налагавшихся на разработчиков государственными контрактами того времени [9]. Многие авторы ошибочно полагают, что в своей статье Ройс выступает в защиту однопроходной последовательной схемы. На самом же деле он рекомендовал подход, несколько отличный от того, который в конечном итоге вылился в сегодняшнюю концепцию «водопада» с ее строгой последовательностью фаз анализа требований, проектирования и разработки. Ройс предлагал выполнять эти операции дважды: «Если рассматриваемая компьютерная программа разрабатывается впервые, поставьте дело так, чтобы версия, в конечном итоге предоставляемая заказчику для оперативного развертывания, фактически была второй версией в том, что касается критических участков проектирования/функционирования».

Далее Ройс писал, что в рамках проекта со сроком реализации 30 месяцев можно строить рассчитанную на 10 месяцев пилотную модель, и доказывал ее необходимость в случаях, когда проект содержит новаторские элементы и неизвестные факторы (едва ли такие случаи можно считать уникальными). Таким образом, в статье Ройса мы видим ростки концепций итеративной разработки, обратной связи и адаптации. Итеративный и предусматривающий учет ранее полученных результатов процесс в концепции Ройса теряется почти во всех пересказах его модели, хотя и понятно, что она не совпадает с классической моделью IID.

Но какому же подходу отдал предпочтение Ройс, когда он узнал о последнем из названных методов? Уокер Ройс, его сын и один из создателей популярных в 90-е годы вариантов IID, в одном из писем пишет о своем отце и о его статье следующее:

«Он всегда был сторонником итеративной, инкрементальной, эволюционной разработки. В его статье модель водопада фигурирует как простейшее описание, пригодное лишь для самых простых проектов. Остальные разделы его статьи посвящены описанию итеративных методов в контексте принятых в 60-е и 70-е годы моделей контрактов с федеральными ведомствами, которые представляли собой серьезный набор ограничений».

Это была парадоксальная мысль, если учесть влияние его статьи, ставшей священной для тех, кто проповедовал строго последовательный жизненный цикл для крупных и сложных проектов. Авторство следующего по времени упоминания рассматриваемого нами метода принадлежит Харлану Миллсу, сотруднику IBM Federal Systems Division, который в 70-е годы был ведущим теоретиком технологий программирования. В своей известной работе Top-Down Programming in Large Systems Миллс отстаивал идеи итеративной разработки. Он рекомендовал начинать проектирование со структур управления верхнего уровня и двигаться в направлении сверху вниз; пожалуй, меньшее влияние оказала рекомендация Миллса относительно создания системы путем многократных расширений ее модели [10]:

«... существует возможность генерирования серии промежуточных систем и функциональных подспецификаций так, чтобы на каждом этапе корректность каждой [промежуточной] системы могла быть верифицирована...»

Понятно, что Миллс говорил об итеративном усовершенствовании модели на этапе разработки. Но он не упоминал о необходимости воздерживаться от подготовки всеобъемлющих спецификаций на первом этапе проектирования, не указывал, сколь продолжительной должна быть итерация, и не подчеркивал важности таких аспектов разработки, как учет ранее полученных результатов и адаптация модели при каждой итерации. Впрочем, в конце 70-х он все же ставил эти вопросы. Учитывая место работы Миллса, мы подозреваем, что его идеи формировались под влиянием классических IID-проектов, которые осуществлялись в IBM в начале 70-х годов; однако найти подтверждение этого предположения у его коллег нам не удалось.

Первые опыты более современной трактовки IID, предполагающие уточнение модели на основе ранее полученных результатов с участием заказчика и четко определенные итерации, проводились под руководством Майка Дайера, Боба Макгенри, Дона О?Нейла и других в период их работы в IBM Federal Systems Division. История этого подразделения захватывает: в рассматриваемый период оно было активно вовлечено в проектирование крупных космических и авиационных систем для Министерства обороны США и прекрасно справилось с поставленными задачами.

Первый из известных нам крупных документированных проектов IBM Federal Systems Division с применением методики IID был осуществлен в 1972 году. Разработку системы нужно было завершить к указанному сроку; в противном случае IBM пришлось бы платить штраф за просрочку из расчета 100 тыс. долл. в день. Разработчики разбили проект на четыре итерации с жесткими ограничениями по времени; на каждую итерацию выделялось примерно по полгода. На первом этапе проектирования были все же составлены объемные спецификации, и итерация заняла больше времени, чем полагается по сегодняшним представлениям. Требования в какой-то степени изменялись, поскольку проектировщики учитывали опыт предшествующей работы. Такой подход позволил принимать во внимание сложность и риски, связанные с разработкой крупномасштабной системы [11].

В том же 1972 году конкурент IBM — компания TRW использовала методику IID в работе над другим крупным заданием — программным проектом стоимостью 100 млн. долл. для управления баллистическими ракетами. Работы по проекту начались в феврале 1972 года, и после пяти итераций команда TRW завершила разработку. Первая модель отслеживала один объект, а с выпуском пятой итерации несколькими годами позднее система была готова полностью. Итерации не были жестко ограничены по времени, и на первом этапе проектирования была проведена значительная работа по составлению спецификаций; разработчики вносили усовершенствования в каждую итерацию с учетом показателей предшествующей модели [12].

Как и в IBM Federal Systems Division, в TRW (где работал Ройс) одними из первых приняли на вооружение методы IID. Между прочим, Барри Боэм, создавший в середине 80-х годов спиралевидную модель IID, был главным научным сотрудником TRW.

В середине 70-х годов отделение IBM Federal Systems Division реализовало еще один исключительно масштабный проект с использованием IID. Речь идет о разработке легкой бортовой многоцелевой системы (Light Airborne Multipurpose System, LAMPS), предназначенной для размещаемых на вертолетах ВМС США систем «воздух — корабль». На создание LAMPS ушло четыре года. Она вобрала в себя 200 человеко-лет и была реализована с приращениями в серии из 45 жестко ограниченных по времени итераций (по месяцу на итерацию). Это был самый первый из известных нам проектов, где продолжительность итерации колебалась в пределах от одной до шести недель (именно такие сроки рекомендуют популярные ныне варианты IID). Проект был вполне успешным. Миллс писал о нем: «Все продукты выпускались вовремя и в рамках выделенных смет» [13]. В 1975 году Вик Базили и Джо Тернер опубликовали статью, в которой четко описывались классические принципы IID [14]:

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

В 1976 году была опубликована работа Тома Гилба Software Metrics, где, кстати сказать, впервые использовался и сам этот термин. В ней автор описал свой опыт по использованию методики IID — эволюционное управление проектами — и ввел в лексикон разработчиков новые слова «эволюция» и «эволюционный». Это первая из известных нам книг, в которой ясно излагались и отстаивались принципы IID, особенно в части, касающейся сдачи заказчику эволюционирующих версий системы [3]:

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

Гилб — один из первых и наиболее активных последователей и поборников методики IID. Он приступил к работе в этой сфере в начале 60-х годов, и именно ему довелось установить несколько вех на пути развития этого подхода. В его работах, пожалуй, впервые четко проводится идея быстрых, легких и адаптивных итераций, оперативно приносящих результаты, — идея, столь созвучная более новым методам IID. К 1976 году Миллс сформулировал более радикальное представление о IID [15]: На материалах осуществлявшегося в течение трех лет проекта по разработке системы учета он показал сомнительность самой идеи составления требований или подготовки проектных спецификаций на первом этапе проектирования:

«... к тому же здесь кроются определенные опасности, в частности, в реализации этих стадий [модели водопада] непосредственно друг за другом, а не в форме итераций — т. е., когда разработка осуществляется в рамках одного открытого цикла, а не в закрытом цикле, предусматривающем обратную связь с пользователем в промежутках между итерациями. Опасность такого последовательного подхода в том, что проект из грандиозного превращается в неподъемный, т. е. для организации управления проектом уже недостаточно интеллектуальных возможностей человека».

И, возможно, отражая продолжавшийся не один год опыт наблюдения за реализацией методики IID, Миллс ставил вопрос: «Почему предприятия все еще готовы мириться со всеми срывами и сложностями, которые сопутствуют подобному [последовательному] методу разработки?»

В 1977 году в IBM Federal Systems Division включили применявшийся при работе над проектом Trident подход, который предполагал интеграцию всех программных компонентов по завершении каждого цикла, в свою «официальную» методологию программирования. Макгенри назвал этот подход «интеграционной инженерией» (integration engineering). В роли инициаторов данного шага выступали некоторые участники проекта Trident, а также Миллс [16]. Интеграционная инженерия стала достоянием 2500 инженеров-программистов корпорации, а идея IID как альтернатива модели водопада вызвала значительный интерес в других подразделениях IBM, а также в высших эшелонах организаций-заказчиков и среди конкурентов корпорации.

Рассматриваемый период явил еще один удивительный пример крупного успеха методики IID. Она была применена и в процессе разработки важнейших компонентов проектировавшегося по заказу NASA программного обеспечения «космических челноков». В IBM создали эту систему в период с 1977-го по 1980 год. Участники проекта применили методику IID в серии из 17 итераций, растянувшейся на 31 месяц. В среднем на одну итерацию уходило по восемь недель [17]. Причиной, побудившей разработчиков отказаться от последовательного жизненного цикла, послужило то обстоятельство, что требования к программному обеспечению «челнока» менялись в ходе процесса разработки. Любопытно (с высоты сегодняшних знаний, разумеется), что, когда авторы объясняют, почему им пришлось отказаться от «идеальной» последовательной модели и взять на вооружение IID, у них проскальзывают чуть ли не извиняющиеся нотки:

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

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

Первая из обнаруженных нами дискуссия по проблемам IID на страницах широкой печати началась в 1978 году, когда Том Гилб начал вести колонку в английском еженедельнике Computer Weekly. В колонке регулярно появлялись материалы, пропагандирующие метод IID, а также эволюционный подход к управлению проектами разработки. В своей колонке от 6 апреля 1978 года Гилб писал:

«Управление не предполагает точной оценки степени завершенности, необходимого времени и денег для всего проекта. Каждый небольшой итеративный шаг должен отвечать одному из следующих критериев (в порядке приоритетности): (a) давать запланированную прибыль на вложенный капитал; если это невозможно, (b) выводить проект на безубыточный уровень; или, по меньшей мере, (c) приносить некоторую поддающуюся измерению выгоду для пользователя; или, наконец, (d) обеспечивать пользователя некоторой обратной связью и возможностью усвоить нечто новое».

Упомянем еще об одной дискуссии, посвященной проблемам инкрементальной разработки. Ее материалы были опубликованы в 1984 году, но связана она была с реализованным корпорацией System Development проектом по созданию системы противовоздушной обороны, начатым в 1977 году и завершенным в 1980 году. В этом проекте сочетались такие особенности, как значительный объем подготовленных на начальном этапе спецификаций и инкрементальный подход к разработке и конструированию. По всей видимости, проект должен был соответствовать принятым в Пентагоне «однопроходным» стандартам, в соответствии с которыми тестирование и интеграция выполнялись на завершающем этапе. Вот что пишет Кэролин Вонг о нереалистичности этого подхода и о том, что разработчикам нужно было перейти к модели инкрементальной разработки [18]:

«Модель водопада была принята потому, что проектирование осуществлялось по принятым в Министерстве обороны стандартам... На самом деле, разработка программ — это сложный, непрерывный, итерационный и повторяющийся процесс. Модель водопада не отражает всей этой сложности».

80-е годы

В 1980 году Уайнберг посвятил проблемам IID статью Adaptive Programming: The New Religion, опубликованную в еженедельнике Australasian Computerworld. Резюмируя содержание статьи, он писал: «Фундаментальная идея состояла в том, чтобы продвигаться вперед малыми шагами, и каждый такой шаг совершать после усвоения информации, поступающей от заказчика по каналам обратной связи». Год спустя Том Гилб опубликовал более подробное описание концепции эволюционной разработки [19].

В том же году Дэниэл Маккрэкен и Майкл Джексон выступили в защиту концепции IID и против «сводящей на нет усилия разработчиков модели водопада» в главе, вошедшей в статью по технологии программирования под редакцией Уильяма Коттермана. Заголовок главы A Minority Dissenting Position (что можно перевести как «Особое мнение меньшинства» — прим. перев.) свидетельствует о том, что в то время позиции сторонников концепции IID были слабее, чем у приверженцев «классической» модели [20]. В 1982 году полемика продолжилась статьей Life-Cycle Concept Considered Harmful [21], в названии которой перепевается заголовок опубликованной в конце 60-х годов классической работы Эдсгера Дийкстры Go To Statement Considered Harmful [22] (Использование выражения «жизненный цикл» в качестве синонима модели водопада свидетельствует, что в рассматриваемый период последняя несомненно занимала господствующее положение; в 90-е годы применялись уже более четко определяемые понятия: «последовательный жизненный цикл» и «итеративный жизненный цикл»).

В 1982 году Уильям Свартаут и Роберт Бальцер высказали идею о неизбежном влиянии друг на друга спецификаций и процесса проектирования и выступили в защиту итерационного и эволюционного подхода к формированию требований и разработке [23]. В том же году в печати появилось первое упоминание об успешной разработке очень крупной прикладной системы с использованием эволюционного прототипирования — IID-метода, который обычно не ассоциируется с жестко ограниченными по времени итерациями. Этот проект по созданию военной системы управления и контроля стоимостью в 100 млн. долл. был реализован с использованием разработанной корпорацией IBM технологии Customer Information Control System [24].

В 1983 году была опубликована работа Грэди Буча Software Engineering with Ada [25], в которой автор описывает итеративный процесс создания объектно-ориентированной системы. Впрочем, причина популярности этой книги была не столько в том, что в тексте содержались рекомендации по применению итеративного процесса, а в том, что автор описывал метод объектно-ориентированного проектирования.

В начале 80-х активно предпринимались попытки проектирования систем искусственного интеллекта, экспертных систем и т.д., главным образом на машинах Lisp. Участвовавшие в этих работах исследователи, как правило, придерживались методики IID с использованием эволюционного прототипирования [26]. В середине 80-х годов Гилб вновь поставил под вопрос модель последовательного жизненного цикла. В статье "Evolutionary Delivery versus the Waterfall Model" он предложил более «энергичную» стратегию, нежели другие сторонники метода IID. Гилб считал целесообразным чаще — скажем, один раз в несколько недель — предоставлять заказчикам определенные результаты [27].

Очередной вехой в истории публикаций, посвященных проблематике IID, стала вышедшая в свет в 1985 году статья Барри Боэма A Spiral Model of Software Development and Enhancement [28]. Есть основания полагать, что спиралевидная модель — не первый пример того, как проектировщики устанавливают первоочередность циклов разработки в соответствии со степенью риска: так, в IBM Federal Systems Division еще раньше реализовывали на практике или высказывались в защиту различных вариантов этой идеи. Однако нужно признать, что в контексте спиралевидной модели была формализована концепция итераций, определяемых степенью риска, а также была осознана необходимость осуществления в ходе каждой итерации четко обозначенных мер по оценке рисков. В 1986 году Фредерик Брукс, являвшийся в 70-е и 80-е годы признанным теоретиком технологий программирования, написал свою классическую работу No Silver Bullet, в которой превозносились достоинства IID [29]:

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

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

В 1986 году Дэвид Парнас и Пол Клементс опубликовали статью A Rational Design Process: How and Why to Fake It. В ней говорилось, что, хотя авторы верят в идеал последовательной модели (т.е. в подробные, корректные и четкие спецификации, составленные до начала проектирования), с практической точки зрения эта модель непригодна. Свой вывод Парнас и Клементс обосновывают множеством причин. Среди них следующие.

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

Авторы заключают: «Представление о том, будто разработчик программного обеспечения создает свое изделие рациональным и свободным от ошибок образом на основе документа с изложением требований, абсолютно нереалистично».

В 1987 году в TRW приступили к реализации растянувшегося на четыре года проекта по модернизации информационной системы командного центра Command Center Processing and Display System Replacement с использованием методов IID [31]. Разработчики осуществили шесть жестко ограниченных по времени итераций, каждая из которых заняла порядка шести месяцев. Их подход согласовывался с идеями, которые позднее получили известность под названием Rational Unified Process (в разработку этих идей внес свой вклад и Уокер Ройс), а именно — предполагал внимание к высоким рискам и базовой архитектуре уже в ходе первых итераций.

В статье Билла Куртиса с соавторами [32] излагались результаты исследований 19 крупных проектов. Авторы указали, что нормативная модель водопада имела целью удовлетворить цели отчетности управления. В статье отмечалось, что проектирование программного обеспечения — это не последовательно развивающийся «производственный процесс». Успех разработки в большой степени определяется циклическим процессом обучения, важную роль в котором играют навыки сотрудников, общий взгляд на проблему и вопросы взаимопонимания. Авторы статьи, в частности, писали:

«По итогам проведенных исследований мы со всей определенностью пришли к следующему выводу: процесс проектирования крупных программных систем, или, по крайней мере, часть этого процесса, надо рассматривать как процесс обучения и коммуникаций».

В 1987 году Миллс, Дайер и Рик Лингер в рамках развернутой в IBM программы Software Engineering Practices продолжили работы по дальнейшему развитию методики IID. Они разработали метод Cleanroom («чистая комната»), в котором принципы эволюционной разработки сочетались с более формализованными методами спецификации и доказательства; последнее обстоятельство отражало сильное влияние на соавторов со стороны математика Миллса [33].

К концу 80-х годов Министерство обороны США начало испытывать серьезные трудности с разработкой программного обеспечения в соответствии с жесткой, основанной на директивных документах и предусматривающей один проход модели, как это требовалось стандартом DoD-Std-2167. Проведенная в 1999 году проверка по выборке ранее утвержденных в Министерстве обороны проектов дала удручающие результаты. «Из общего числа входящих в выборку проектов, на реализацию которых было выделено 37 млрд. долл., 75% проектов закончились неудачей или выделенные на них средства не были использованы, и только 2% выделенных средств были использованы без значительной модификации проектов» [34]. В результате в конце 1987 года министерство отступило от стандартов на базе модели водопада и допустило применение IID. В основу решения были положены рекомендации, содержащиеся в подготовленном в октябре 1987 года докладе о программных средствах военного назначения рабочей группы Совета по оборонным наукам, которую возглавлял Брукс. Доклад содержал рекомендацию заменить доказавшую свою несостоятельность при реализации многих крупных оборонных проектов модель методом итеративной разработки:

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

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

Как специалисты по истории Министерства обороны, так и подрядчики часто уподобляют обновленный стандарт DoD-Std-2167A, выпущенный в феврале 1988 года, краткому изложению спецификации модели водопада. Между тем, его авторы рассматривали документ как «поправку» (отсюда и буква A — amendment — в его названии). Поправка должна была придать выражению «жизненный цикл» нейтральное значение и тем самым допустить применение IID-альтернатив:

«Настоящий стандарт не имеет своей целью рекомендовать или не рекомендовать к использованию какой-либо конкретный метод разработки программного обеспечения. Ответственность за выбор методов проектирования (например, метода быстрого прототипирования), в наибольшей степени отвечающих задаче выполнения требований контракта, ложится на подрядчика».

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

Любопытно, что в разговоре, имевшем место почти десять лет спустя, главный автор стандарта DoD-Std-2167 выразил сожаление по поводу того, что создал стандарт, столь жестко ориентированный на модель водопада. Он заявил, что в то время ему была известна только однопроходная и основанная на четком следовании первоначальным спецификациям модель. Специалисты, с которыми он консультировался, утверждали, что это прекрасная методика; то же говорилось и в изученной им литературе, а об итеративной разработке он и не слышал. Автор стандарта сказал, что если бы он располагал полной информацией, то обязательно бы настоятельно рекомендовал не модель водопада, а IID.

Опубликованный в 1988 году труд Тома Гилба Principles of Software Engineering Management был первой книгой, значительная часть которой была посвящена рассмотрению и пропаганде IID [35]. Автор вновь и вновь повторял и развивал положения IID, содержащиеся в работе Software Metrics. Гилб описал метод Evo, отличительные особенности которого состояли в том, что в процессе проектирования разработчики часто создают эволюционные модели и делают упор на постановке количественно измеряемых целей, а также на последующем измерении результатов, фактически получаемых в ходе каждой итерации с жесткими временными рамками.

От 90-х до настоящего времени

В 90-е годы — и особенно в конце десятилетия — признаки того, что IID завоевывает в среде разработчиков ведущие позиции, стали появляться все чаще. Были изданы сотни книг и статей, главной или второй по значению темой которых стала пропаганда IID. Появились десятки новых методов IID; их общей отличительной особенностью стала все более явственно прослеживающаяся тенденция отдавать предпочтение жестко ограниченным по времени итерациям продолжительностью от одной до шести недель.

Минобороны США по-прежнему терпело неудачу за неудачей в процессе реализации проектов, основанных на «водопадном менталитете». С тем чтобы выправить это положение и еще раз указать на необходимость замены последовательной модели методикой IID, входящая в состав совета по оборонным наукам рабочая группа по программному обеспечению оборонного назначения под руководством Пола Камински в июне 1994 года опубликовала доклад, в котором без обиняков говорилось: «Минобороны должно управлять программами с помощью итеративной разработки. Применять эволюционную разработку с быстрым развертыванием минимального набора функциональных возможностей».

В результате в декабре 1994 года во изменение стандарта 2167A был принят стандарт Mil-Std-498. В статье Джорджа Ньюберри, суммирующей изменения, содержался раздел «Ликвидация водопадного уклона», в которой автор описывал цель — переход на применение IID [36]:

«Стандарт Mil-Std-498 описывает разработку программного обеспечения посредством создания нескольких вариантов содержащих приращения. Каждый вариант реализует определенное подмножество заданных функций. Этапы процесса повторяются для каждого варианта, и внутри каждого варианта этапы могут частично перекрывать друг друга и повторяться».

В самом документе Mil-Std-498 четко излагаются присущие IID основные приемы эволюционного формирования требований и проектирования через приращения по мере реализации проекта:

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

Между тем, в коммерческом секторе сотрудники компании Easel Джефф Сазерленд и Кен Швабер уже начали применять методику, позднее получившую название «метод Scrum»; она предполагала разбиение проекта на жестко ограниченные по времени итерации продолжительностью в 30 дней. Разработчики метода опирались на опыт реализованных в 80-е годы в Японии IID-проектов по разработке не имеющих отношения к программному обеспечению продуктов в корпорациях Honda, Canon и Fujitsu; на опыт использования Shashimi («ломтиков», или итераций) и на его разновидность Scrum, описанную в 1986 году [37]. В статье, опубликованной в 1999 году, дальнейшие усовершенствования метода тоже именовались Scrum [38].

В январе 1994 года группа из 16 специалистов, занятых вопросами быстрой разработки приложений (rapid application development, RAD) собрались в Англии для обсуждения стандартного итеративного процесса, который можно было бы применять при ведении разработок. Члены группы опирались на идеи в области RAD, выдвинутые Джеймсом Мартином. Мартин же, в свою очередь, формировал свои концепции на основе опыта, почерпнутого им в процессе работ с жестким контролем времени в корпорации Dupont, проводившихся под руководством Скотта Шульца в середине 80-х. Принятое этой группой экспертов определение процесса эволюционировало в метод, известный сегодня как Dynamic Systems Development Method (DSDM). На первых порах у него было больше сторонников в Европе, но с тех пор он получил широкое распространение [39].

В начале 90-х годов консорциум компаний начал работу над проектом по созданию автоматизированной системы контроля за воздушным движением Canadian Automated Air Traffic Control System с использованием метода, управляемого в зависимости от рисков. Проект, выполнявшийся под руководством Филиппа Крачтена, был разбит на несколько итераций продолжительностью в 6 месяцев каждая, что по сегодняшним стандартам является довольно большим сроком. Проект увенчался успехом, хотя первоначально, когда в его основу была положена модель водопада, он был весьма близок к провалу [40].

В середине 90-х годов ряд сотрудников компании Rational (в их числе были и Крачтен с Уокером Ройсом) в сотрудничестве с клиентами компании создали завоевавший сегодня значительную популярность метод Rational Unified Process. Важным событием 1995 года стало активное продвижение теста daily build and smoke, введенного корпорацией Microsoft и получившего широкое признание метода, предусматривающего выполнение микроитераций продолжительностью всего в один день [41].

В 1996 году Кент Бек вошел в группу специалистов, работающих над проектом по созданию «зарплатной» системы Chrysler C3. Именно в рамках этого проекта был доведен до состояния зрелости набор методов «экстремального программирования» (extreme programming, XP). На отдельных этапах в работе принимал участие Рон Джеффрис. Проектировщики пользовались результатами проведенных в начале 80-х годов работ в компании Tektronix при участии Уорда Каннингэма. Методы XP и далее привлекали значительное внимание общественности, поскольку в них упор делался на коммуникации, простоту и тестирование, поскольку они постоянно ориентировались на потребности разработчика и получили необычное название [42].

В 1997 году проект по созданию крупной логистической системы в Сингапуре, который реализовывался в рамках каскадной модели, оказался на грани срыва. Разработчики под руководством Питера Коуда и Джеффа Де Лука буквально воскресили его и довели до успешного завершения на основе методики IID. Де Лука создал общее описание итеративного процесса — Feature-Driven Development (FDD), — в основу которого были также положены некоторые идеи Коуда [43].

В 1998 году аналитики Standish Group подготовили часто цитируемый доклад CHAOS: Charting the Seas of Information Technology, в котором анализировались итоги 23 тыс. различных проектов с целью выявления факторов, влияющих на неудачу проекта. Так вот, по данным этого доклада, основные причины неудачного завершения проектов были связаны с применением последовательных методов. Еще один вывод состоял в том, что использование IID обычно помогало выправить положение. Одна из основных рекомендаций доклада состояла в том, что нужно брать на вооружение методы IID:

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

В 2000 году Министерство обороны заменило стандарт Mil-Std-498 другим стандартом — DoD 5000.2. В нем тоже содержатся рекомендации принять эволюционный принцип и методы IID:

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

В 2001 году Алан Маккормак опубликовал исследование, в котором анализировались основные факторы успеха недавно реализованных проектов. Первым из этих факторов значилось принятие на вооружение итеративного жизненного цикла [44]:

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

В феврале 2001 года группа из 17 заинтересованных в продвижении современных, простых методов и принципов IID экспертов по процессам — представляющих DSDM, XP, Scrum, FDD и другие направления — собралась для выработки общей платформы. Именно в ходе этой встречи на свет появилось объединение Agile Alliance (www.agilealliance.org) и столь популярная в наши дни фраза «шустрые методы» (agile methods); все эти методы подразумевают использование методики IID. А уже в 2002 году Алистер Кокберн, один из участников встречи, опубликовал книгу, в названии которой использовался новый термин [45].

***

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

  • Эту идею легко объяснить и легко запомнить. "Выполни требования, потом проектируй, а потом реализуй". IID труднее и понять, и описать. Даже оригинальная концепция Уинстона Ройса о двух итерациях в изложении других применявших ее разработчиков и описывающих ее авторов немедленно превратилась в один последовательный процесс.
  • Она создает иллюзию упорядоченного, объяснимого и обеспечивающего возможность измерений процесса, размеченного простыми вехами, взятыми из документов (например, "стадия выполнения требований завершена").
  • Эта идея продвигалась во множестве документов и курсов, посвященных технологии программирования, программной инженерии и управлению, а также консультантами. Ее называли адекватной, а то и идеальной; при этом авторы подобных характеристик, по-видимому, не имели представления ни об истории вопроса, ни о статистически обоснованных результатах исследований, свидетельствующих в пользу IID.

Наша «краткая история» показывает, что концепции IID были и остаются предпочтительными с точки зрения ведущих представителей программной индустрии каждого из прошедших десятилетий; данный метод применялся во многих завершившихся успехом крупных проектах и рекомендован стандартизирующими организациями.

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

Литература
  1. W. Shewhart, Statistical Method from the Viewpoint of Quality Control, Dover, 1986 (reprint from 1939).
  2. W.E. Deming, Out of the Crisis, SPC Press, 1982; reprinted in paperback by MIT Press, 2003.
  3. T. Gilb, Software Metrics, Little, Brown, and Co., 1976 (out of print).
  4. R. Zultner, "The Deming Approach to Quality Software Engineering", Quality Progress, vol. 21, no. 11, 1988.
  5. W.H. Dana, The X-15 Lessons Learned, tech. report, NASA Dryden Research Facility, 1993.
  6. B. Randell, F.W. Zurcher, "Iterative Multi-Level Modeling: A Methodology for Computer System Design", Proc. IFIP, IEEE CS Press, 1968.
  7. M.M. Lehman, "The Programming Process", internal IBM report, 1969; reprinted in Program Evolution-Processes of Software Change, Academic Press, 1985.
  8. R. Glass, "Elementary Level Discussion of Compiler/Interpreter Writing", ACM Computing Surveys, Mar. 1969.
  9. W. Royce, "Managing the Development of Large Software Systems", Proc. Westcon, IEEE CS Press, 1970.
  10. H. Mills, "Debugging Techniques in Large Systems," Software Productivity, Dorset House, 1988.
  11. D. O'Neill, "Integration Engineering Perspective", J. Systems and Software, no. 3, 1983.
  12. R.D. Williams, "Managing the Development of Reliable Software", Proc. Int'l Conf. Reliable Software, ACM Press, 1975.
  13. H. Mills, "Principles of Software Engineering", IBM Systems J., vol. 19, no. 4, 1980.
  14. V. Basili, J. Turner, "Iterative Enhancement: A Practical Technique for Software Development", IEEE Trans. Software Eng., Dec. 1975.
  15. H. Mills, "Software Development", IEEE Trans. Software Eng., Dec. 1976.
  16. D. O'Neill, "The Management of Software Engineering", IBM Systems J., vol. 19, no. 4, 1980.
  17. W. Madden, K. Rone, "Design, Development, Integration: Space Shuttle Flight Software System", Comm. ACM, Sept. 1984.
  18. C. Wong, "A Successful Software Development", IEEE Trans. Software Eng., no. 3, 1984.
  19. T. Gilb, "Evolutionary Development," ACM Software Eng. Notes, Apr. 1981, p. 17.
  20. W.W. Cotterman et al., eds., Systems Analysis and Design: A Foundation for the 1980's, North-Holland, 1981.
  21. D. McCracken and M. Jackson, "Life-Cycle Concept Considered Harmful", ACM Software Eng. Notes, Apr. 1982.
  22. E. Dijkstra, "Go To Statement Considered Harmful", Comm. ACM, Mar. 1968.
  23. W. Swartout, R. Balzer, "On the Inevitable Intertwining of Specification and Implementation", Comm. ACM, July 1982.
  24. D. Tamanaha, "An Integrated Rapid Prototyping Methodology for Command and Control Systems: Experience and Insight", ACM Software Eng. Notes, Dec. 1982.
  25. G. Booch, Software Engineering with Ada, Benjamin-Cummings, 1983.
  26. R. Budde et al., eds., Approaches to Prototyping, Springer Verlag, 1984.
  27. T. Gilb, "Evolutionary Delivery versus the 'Waterfall Model'," ACM Software Requirements Eng. Notes, July 1985.
  28. B. Boehm, "A Spiral Model of Software Development and Enhancement", Proc. Int'l Workshop Software Process and Software Environments, ACM Press, 1985.
  29. F. Brooks, "No Silver Bullet: Essence and Accidents of Software Engineering", Proc. IFIP, IEEE CS Press, 1987.
  30. D. Parnas, P. Clements, "A Rational Design Process: How and Why to Fake It", IEEE Trans. Software Eng., Feb. 1986.
  31. W. Royce, Software Project Management, Addison-Wesley, 1998.
  32. W. Curtis et al., "On Building Software Process Models under the Lamppost", Proc. Int'l Conf. Software Eng., IEEE CS Press, 1987.
  33. H. Mills et al., "Cleanroom Software Engineering", IEEE Software, Sept. 1987.
  34. S. Jarzombek, Proc. Joint Aerospace Weapons Systems Support, Sensors and Simulation Symp., Gov't Printing Office Press, 1999.
  35. T. Gilb, Principles of Software Engineering Management, Addison Wesley Longman, 1989.
  36. G.A. Newberry, "Changes from DOD-STD-2167A to MIL-STD-498", Crosstalk: J. Defense Software Eng., Apr. 1995; www.stsc.hill.af.mil/crosstalk/ frames.asp?uri=1995/04/Changes.asp.
  37. H. Takeuchi, I. Nonaka, "The New New Product Development Game", Harvard Business Rev., Jan. 1986.
  38. M. Beedle et al., "Scrum: An Extension Pattern Language for Hyperproductive Software Development", Pattern Languages of Program Design, vol. 4, 1999.
  39. J. Stapleton, DSDM: Dynamic Systems Development Method, Addison-Wesley, 1997.
  40. P. Kruchten, "Rational Development Process", Crosstalk: J. Defense Software Eng., July 1996; www.stsc.hill.af.mil/crosstalk/frames.asp?uri=1996/07/ rational.asp.
  41. J. McCarthy, Dynamics of Software Development, Microsoft Press, 1995.
  42. K. Beck, Extreme Programming Explained: Embrace Change, Addison-Wesley, 1999.
  43. P. Coad et al., "Feature-Driven Development", in Java Modeling in Color with UML, Prentice Hall, 1999.
  44. A. MacCormack, "Product-Development Practices That Work", MIT Sloan Management Rev., vol. 42, no. 2, 2001.
  45. A. Cockburn, Agile Software Development, Addison-Wesley, 2002.

Крейг Ларман (craig@craiglarman.com) — главный научный сотрудник компании Valtech. Выступает с лекциями и оказывает консультационные услуги по всему миру. Автор книги Agile and Iterative Development: A Managers Guide (Addison-Wesley, 2003). Виктор Базили (basili@cs.umd.edu) — профессор Университета штата Мэриленд и исполнительный директор Центра Фраунхофера. Специализируется на вопросах измерения, оценки и совершенствования процесса разработки программных продуктов.

Craig Larman, Victor Basili. Iterative and Incremental Development: A Brief History. IEEE Computer, June 2003. IEEE Computer Society, 2003, All rights reserved. Reprinted with permission.