Итерации по спирали

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

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

Уточнение конкретных требований выполняется итерационно, при этом на каждом витке проектной спирали создается все более точная версия, соответствующая пожеланиям заказчика. Шесть шагов спиральной модели 1. В процессе общения с заказчиком формируется общее видение проекта, а также описываются функциональные возможности, которые необходимо реализовать в определенные сроки с нужным качеством. 2. Расставляются приоритеты, задающие порядок реализации основных функциональных возможностей. 3. Согласовываются временные рамки проекта. Часто для этого применяются методики стоимостного прогнозирования. Далее исполнитель решает, сколько функциональных возможностей в соответствии с их приоритетами удастся реализовать в оговоренный срок. 4. На данном этапе определяются архитектура и ядро будущей системы.

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

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

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

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

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