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

Срок как важнейший приоритет

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

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

Например, методика экстремального программирования (см. "Программная инженерия развивается экстремальными методами", PC Week/RE, № 35/2001, с. 36) подразумевает создание продукта фактически при непрерывном контакте с заказчиком.

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

Кроме того, подобные методики обычно допускают отклонение от бюджета и сроков, но размер этого отклонения на ранних этапах контакта с заказчиком определить очень сложно, особенно если объемы работ велики.

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

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

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

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

Далее совместными усилиями устанавливаются желаемые сроки реализации этой базовой функциональности. Формируется план, начинаются работы и отслеживается их выполнение - например, с помощью методики C/SCSC (см. "Стратегическое управление проектами", PC Week/RE, № 7/2000, с. 32).

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

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

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

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

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

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

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

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

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

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

5. Готовится план работ. Он ориентирован на сроки, определенные на третьем этапе, и нацелен на скорейшую реализацию ядра системы. Взаимодействуя с действующим прототипом, заказчик быстрее и точнее вырабатывает и уточняет дальнейшие требования и корректирует приоритеты. Чаще всего такой план составляется по методу критического пути (см. "Критические цепочки - третья революция в управлении проектами", PC Week/RE, № 45/2000, с. 50).

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

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

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

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

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

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

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