Главная / Каталог

Сравнительный анализ каскадной и спиральной моделей

Длительность технологического цикла
Расчет длительности производственного цикла с построением графика и оформлением решения в Word.

Спиральная модель процесса разработки

В реальной жизни оказывается, что на стадии формулировки требований заказчик не может точно определить все требования к программному продукту. Для преодоления данной проблемы во второй половине 80-х годов был предложен "спиральный" процесс создания программ (рис. 1.3), делающий упор на этапы анализа и проектирования. Разработка системы по данной методологии происходит итерациями, и после прохождения каждого витка спирали пользователь получает очередную версию системы. После получения заказчиком каждой версии уточняются цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали.

Рис 1.3. Спиральная модель

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

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

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

Шесть шагов спиральной модели

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

2. Расставляются приоритеты, задающие порядок реализации основных функциональных возможностей.

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

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

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

Этот шаг выполняется, как правило, в два и большее число итерационных циклов.

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

6. Разработка системы в соответствии с планом.

Для этого этапа характерны три типичных класса проблем:

- изменения в требованиях к проекту;

- изменения параметров самого проекта (сроков, бюджета, качества);

- временные задержки, связанные с текущими вопросами (техникой, персоналом).

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

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