Далее мы рассмотрим еще две модели жизненного цикла,
которые представляют собой усложненную комбинацию
их этапов, — это спиральная модель и модель синхронизации
и стабилизации или модель Microsoft.
Что касается спиральной модели. Модель была разработана
Бари Боэмом в 87 году, в конце 80-х годов. И по сути дела
она воплощает в себя лучшие черты с одной стороны документной
управляемой каскадной модели или водопадной модели,
с другой стороны модели циклической или итерационной,
скажем эволюционной разработки с возможностью инкрементального
расширения программных продуктов.
В чем состоят особенности этой модели? Прежде всего,
ведется постоянный мониторинг рисков на каждой стадии
разработки и оценка этих рисков оценка альтернатив
является важной составляющей каждого шага разработки.
По сути дела модель представляет собой спираль разработки,
каждый виток которой представляет собой 4 фазы. Это определение
целей, оценка альтернатив, разработка и верификация
программного обеспечения и планирование следующей
фазы. Чуть позже мы увидим это на иллюстрации и более
подробно расскажем о каждом из этих этапов.
Какие преимущества несет собой спиральная модель
разработки? Прежде всего, это экономия за счет высокого
процента повторного использования тех функций, которые уже
были разработаны ранее на предыдущих витках, и
существенное экономия за счет того, что мы можем
на основе оценки рисков понять, куда двигаться
дальше, как развивать продукт. На самом деле здесь следует
сделать важное замечание, что если будет признано,
что разработка продукта нецелесообразна, мы можем
вообще от нее отказаться. Это тоже достаточно важное
решение в кризис, мы признаем, что те средства, которые
были вложены, имеет смысл далее не инвестировать,
а просто прекратить проект. Это будет экономически
целесообразно. Спиральная модель за счет гибкой и
многоступенчатой оценки рисков такую возможность
дает. Кроме того анализ рисков позволяет нам вести
обоснованное тестирование, т. е. понимать какие именно
фрагменты программного продукта являются наиболее
критичными и какие именно фрагменты имеет смысл тестировать
наиболее интенсивно, а какие, так сказать, можно
тестировать более поверхностно, поскольку они не вносят
существенных рисков, а может быть и вообще не будут
включены в финальный релиз или будут включены в довольно
ограниченном виде. И бесшовное, плавное сопровождение
за счет циклического, инкрементального ввода в эксплуатацию программного
продукта. Это созвучно инкрементальной модели.
С другой стороны существенные недостатки также имеют
своей причиной оценку рисков. Прежде всего, речь идет
о том, что мы ведем корпоративную разработку, существенные
риски могут существенно коррелировать с бизнес-целями
корпорации и, вообще говоря, открывать некую стратегически
значимую информацию. Если разработчики являются
сторонниками компании, может получиться так, что
это стратегическая информация оказывается в руках конкурентов.
Поэтому, вообще говоря, хорошим решением, наилучшим
решением в том числе и в кризис является разработка
внутри корпорации, когда и компания, и заказчик,
скажем главная компания холдинга и компания разработчик
— IT интегратор — находятся под одной корпоративной
крышей и обеспечивают решение общих задач. В этих условиях,
как правило, бизнес-критичная информация не проникает
за стены корпорации и не оказывается в руках конкурентов.