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

Итеративный жизненный цикл предполагает шаги – улучшенные или расширенные версии изделия в конце каждой итерации. По этой причине итеративная модель жизненного цикла иногда называется эволюционной или пошаговой.

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

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

Классическая модель итеративного жизненного цикла – спиральная модель. Современным представителем итеративного жизненного цикла является

IBM Rational Unified Process (RUP), который создан из Rational Unified Process (RUP)]. Более современные представители итеративной модели жизненного цикла – Model Driven Architecture (МDA) и agile development – быстрая разработка.

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

Спиральная модель в действительности является метамоделью, в которой могут содержаться все другие модели жизненного цикла. Модель состоит из четырех секторов диаграммы в декартовых координатах (рис. 5.3). Сектора, следующие: планирование, анализ рисков, инженерия и оценка проекта клиентом. Первая петля спирали начинается в секторе планирования и связана с начальным сбором требований и планированием проекта. Затем проект входит в сектор анализа рисков, где проводится анализ стоимости/выгоды и угроз/благоприятных случаев, чтобы принять решение «да-пет» относительно того, следует ли входить в сектор инженерии (или отказаться от проекта как слишком опасного). Сектор инженерии – это то, где происходит разработка ПО. Результат этой разработки (конструкция, опытный образец или даже конечный продукт) подвергается оценке клиентом, после чего начинается вторая петля спирали.

 Фактически спиральная модель имеет отношение к разработке ПО только в одном из этих четырех секторов инженерии.

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

Рисунок 5.3. Спиральная модель жизненного цикла ПО

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

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

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