Лекция 6. Жизненный цикл программного изделия и его модели

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

Ключевые слова: жизненный цикл программного изделия, модели жизненного цикла, артефакт, старение программ, разработка, ис­пользование, сопровождение, жизненный цикл и цикл разработки, моделирование жизненного цикла, CASE-система, последователь­ное развитие проекта, развитие проекта с итеративным наращивани­ем, декомпозиция проекта, возвратно-поступательное развитие про­екта, объектно-ориентированное проектирование, рабочие продук­ты, рабочее описание, методологии программирования, проектиро­вание, производство, декомпозиция.

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

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

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

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

Мотивация изучения жизненного цикла и его моделей

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

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

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

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

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

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

Использование Разработка

Продолжающаяся разработка

(сопровождение)

Рис. 6.1. Разработка, использование и сопровождение программного

обеспечения

продолжается после передачи его пользователю и в течение всего времени жизни программ. Деятельность, связанная с решением довольно много­численных задач такой продолжающейся разработки, получила название сопровождения программного обеспечения (см. рис. 6.1).

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

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

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

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

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

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

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

Ниже модели жизненного цикла представлены в виде, позволяющем рассматривать их, абстрагируясь от специфики разработки конкретных программных систем. Описываются традиционные модели и их развитие, приспособленное к потребностям объектно-ориентированного проекти­рования. Изложение в значительной степени основано на материалах ра­боты [22] и в соответствии с линией, которая определена в работе [16]. Тем не менее, оно не буквально следует этим работам, а дополняется и уточняется в связи с задачами менеджмента. По той же причине опуска­ется ряд деталей, несущественных в контексте этих задач.

Если деятельность разработчиков программного проекта поддержи­вается на всех основных этапах жизненного цикла, т.е. проект ведется в условиях использования некоторой так называемой CASE-системы (Computer Aided Software Engineering), то заранее установлены определен­ные рамки, включая контрольные точки, когда менеджер должен органи­зовывать управляющие воздействия. Это, естественно, ограничение ва­риантов развития проекта. И также естественно, что CASE-система навя­зывает априорное представление о жизненном цикле, фиксированное поддерживаемой моделью. В такой ситуации может возникнуть ложное впечатление о единственности модели жизненного цикла. В результате, когда приходится менять условия разработки, коллектив может оказаться не готов к этому.

* Напомним, что мы называем функцию технологической, если последовательность выполнения составляющих ее поручений не требует дополнительных разъяснений для исполнителя (см. лек­цию 2). Таким образом, технологическая функция — это не элемент некоторой технологии, а организационная или производственная функция в деятельности исполнителя. Они могут быть элементами любого производства, в частности ремесленного и мануфактурного.

Еще хуже, когда работа над проектами не подчиняется заранее ого­воренным регламентам, т.е. используемая методология складывается сти­хийно. В этом случае у разработчиков нет оснований для самоограниче­ния, и переход к стандартизованным приемам и методам, который объе­ктивно необходим, может стать болезненным до такой степени, что про­дуктивная совместная работа коллектива окажется невозможной.

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

Последовательное развитие проекта и итеративное наращивание

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

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

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

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

Понятно, что этот подход часто подвергался критике. В качестве до­статочно полного собрания аргументов против него можно указать на со­ответствующую главу в книге Г. Буча [8]. Однако до недавнего времени все предложения, которые выдвигались в противовес недостаткам после­довательного развития, на поверку оказывались лишь паллиативами, не­способными кардинально решить проблему. Реальный прогресс оказался возможным лишь тогда, когда было продемонстрировано, что средствами объектно-ориентированного программирования можно реализовать стратегию итеративного развития проектов, которая характеризуется по­степенным предоставлением необходимых пользователю средств и гиб­ким реагированием на вновь возникающие требования (см. лекцию 5).

При объектно-ориентированном подходе к проектированию про­возглашается принцип возвратно-поступательного развития, или ите­ративного наращивания системы, суть которого состоит в следующем. На каждой фазе проекта строятся работоспособные продукты, развиваемые в дальнейшем путем обогащения функциональности и интерфейса, а не в жестких рамках предварительного технического описания в целом, построенного в ходе специального этапа конструирования, предусмат­риваемого в традиционных схемах. Как следствие, фазы развития про­екта (в традиционном понимании этого слова) при выполнении отдельной итерации оказываются незавершенными, они дополняются (нара­щиваются) на последующих итерациях. Этот принцип во многом транс­формирует понятие жизненного цикла: если раньше изделие производилось лишь к концу периода разработки, то теперь на каждой итерации "появляются относительно законченные рабочие продукты. Также транс­формируется понятие документации: вместо технического описания, появляющегося как итог конструирования, разрабатывается рабочее описание, дополняемое на каждой итерации. В табл. 6.1 приводится сопоставление особенностей традиционных и объектно-ориентированных схем жизненного цикла.

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

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

В данном разделе мы рассмотрели лишь одно качество объектной ориентированности, которое позволяет охарактеризовать ее как подход, относящийся к схемам с итеративным наращиванием возможностей. Вполне правомерно предполагать, что итеративное наращивание не есть монополия объектно-ориентированного подхода. В нем лишь проявилась реальная поддержка переиспользования кода, которая может быть выбра­на в качестве основы для интерактивного наращивания. Сегодня в рамках объектно-ориентированного подхода действительно построены наиболее развитые средства поддержки этой схемы, но нет никаких оснований счи­тать, что другие подходы, например функциональный стиль программи­рования, нельзя оснастить столь же мощными средствами. Тем более что для этого стиля есть все предпосылки к такому развитию [43].

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

Жизненный цикл и методологии программирования

В конце предыдущего раздела мы затронули очень важный аспект жизненного цикла программного обеспечения: его связь с методология­ми программирования. Вообще говоря, методологии — это инструмент, с помощью которого создание программного продукта превращается в упорядоченный процесс, а работа программиста становится более про­гнозируемой и эффективной (см. лекцию 4). Для этого создается деталь­ное описание процесса разработки системы, особое место в котором за­нимает планирование (аналогично другим инженерным дисциплинам). И именно потребность в таком упорядочении породила интерес к изуче­нию понятия жизненного цикла.

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

Есть место в этом процессе и декомпозиции, т.е. разбиению задачи материального производства на подзадачи. Чертежи, где представлены отдельные элементы строительства, ложатся в основу подробного черте­жа, который позволяет определить конкретные задачи и зависимости ме­жду ними. А это, в свою очередь, дает возможность рассчитать стоимость и временные рамки строительства в целом. Кроме того, здесь же подроб­но описывается, каким образом строители должны выполнять свою ра­боту. Благодаря этому работа строителей становится еще менее интелле­ктуальной, хотя, разумеется, нередко требует очень хороших навыков ручного труда.

А правомерно ли переносить такой поход из сферы материального производства на программирование? Если да, то мы должны с самого на­чала разграничить два вида деятельности в этой области:

• проектирование, требующее креативного мышления: разбора вари­ антов решения, оптимизации и других творческих элементов;

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

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

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

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

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

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

Вариант 1

1. Жизненный цикл программного изделия — это:

□ время существования программного изделия от стадии замысла до прекращения эксплуатации

• фазы и этапы разработки проекта

• основа деятельности менеджера программного проекта: окон­чательные и промежуточные цели проекта, распределение и контроль расходования ресурсов, все остальные аспекты упра­вления развитием проекта

• окончательные и промежуточные цели, фазы и этапы разра­ботки, проекта, а также эксплуатации программного изделия и его ликвидации

• проекция пользовательского понятия «время жизни» на поня­тие разработчика «технологический цикл» (цикл разработки)

2. Последовательное развитие проекта — это:

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

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

• организация труда, при которой создаваемый продукт переда­ется от разработчика к разработчику для выполнения очеред­ного этапа

• методика, которая обеспечивает осуществимость поэтапной разработки без возвратов

• методика, при которой необходимость возврата к работам пройденных этапов рассматривается как ошибка проектирования

3. Объектно-ориентированная схема итеративного наращи­вания возможностей характеризуется тем, что:

• рабочие продукты для пользователя создаются и предъявляют­ся на каждой итерации

• рабочее (техническое) описание продукта строится как документ, дополняемый на каждой итерации

• осуществляется возвратно-поступательная разработка

• для декомпозиции системы используются наследование, пере­определение и полиморфизм, которые строятся на базе иерар­хии классов

Вариант 2

I. Контрольные точки — это:

• окончания этапов жизненного цикла программного изделия

• этапы жизненного цикла программного изделия

• моменты передачи в эксплуатацию версий и релизов про­граммного изделия

• моменты разработки, когда осуществляется подведение про­межуточных итогов, осмысление достигнутого и проверка сде­ланных ранее предположений

• моменты взаимодействия с заказчиком, в которые он прини­мает результаты проектирования

I. За счет чего любая из методологий старается повысить производительность процесса разработки?

• за счет эргономичности предоставляемого инструментария

• за счет дисциплины, которую соглашаются соблюдать разработчики при выполнении проекта

• за счет регламентов, предписаний и соглашений, которых долж­ны придерживаться разработчики при выполнении проекта

• за счет введения субординации в коллективе

• за счет строгой отчетности при сдаче выполняемых заданий

3. Отдельная итерация при итеративном наращивании воз­можностей характеризуется тем, что:

• имеет традиционные этапы, как при последовательном разви­тии проекта

• для пользователя создаются рабочие продукты, предъявляемые ему

• рабочее (техническое) описание продукта строится как доку­мент, дополняющий описание продукта на предыдущей итерации

• рабочие продукты, создаваемые при разработке на данной ите­рации, дополняют рабочие продукты, созданные на предыду­щих итерациях

• для наращивания возможностей предлагаемого продукта ис­пользуются наследование, переопределение и полиморфизм, которые строятся на базе иерархии классов