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

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

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

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

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

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

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

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

Процесс пошаговой разработки имеет целый ряд достоинств.

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

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

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

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

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

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