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

© PC Week/RE 02/04
© Планета КИС
© Сергей Бобровский

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

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

Например, методика экстремального программирования (см. "Программная инженерия развивается экстремальными методами", PC Week/RE NN 35,36/2001) подразумевает создание продукта фактически в непрерывном контакте с заказчиком. Она полезна для малых и средних задач и небольших групп разработчиков, но менее успешна, когда объем проекта велик, а заказчик представляет собой достаточно крупную организацию, у специалистов которой нет времени на длительные контакты с подрядчиком. Кроме того, подобные методики обычно допускают отклонение от бюджета и сроков, но размер этого отклонения на ранних этапах контакта с заказчиком определить очень сложно, особенно если объемы работ велики.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



Опубликовал admin
25 Июл, Воскресенье 2004г.



Программирование для чайников.