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

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

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

2. Спиральная модель разработки в которой весь процесс создания ПО, от начального эскиза системы до ее конечной реализации, разворачивается по спирали.

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

Модель пошаговой разработки

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

Модель пошаговой разработки находится где-то между этими моделями и объединяет их достоинства. Эта модель была предложена Миллсом (Mills) как попытка уменьшить количество повторно выполняемых работ в процессе создания ПО и увели­чить для заказчика временной период окончательного принятия решения обо всех дета­лях системных требований.

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

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