Модели, учитывающие специфику разработки ПО.

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

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

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

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

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

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

2.3. Спиральная модель. Предложенная Барри Боэмом в 1988 г., она стала существенным прорывом в понимании природы разработки ПО, хотя, по большому счету, является объединением двух моделей: каскадной и на основе создания прототипов (рис. 3).

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

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

Рис. 3. Спиральная модель Боэма объединяет каскадный подход и итерационный процесс проектирования на основе создания прототипов

Дата добавления: 2015-10-21