Управление проектами со спиральными жизненными циклами

	Водопадная разработка	Разработка со спиральным жизненным циклом
I	Анализ технический требований	I	II
II	Проектирование
Разработка элементов
Интеграция в систему	IV	III
III	Тестирование
IV	Оценка результатов

Предмет в заголовке – новое развивающиеся направление. Развиваемая концепция напоминает масштабно-концептуальную декомпозицию. Проекты со спиральными ЖЦ противопоставляются традиционным с «водопадной» организацией. Процесс спиральной разработки является итерационным с возвратом к первому этапу. На начальных витках спирали выполняются все этапы I-IV, но глубина их проработки ограничена и увеличивается на следующих витках. В результате, наиболее важные и принципиальные решения можно обосновать при комплексном, совместном учёте всех этапов.В случае разработки ПО,одна из форм укрупнённости выступает в виде так называемых «заглушек» - блоков программ, имеющих интерфейс к другим блокам, но с укрупнённо разработанным внутренним кодом (функциональностью).

В случае машиностроения укрупнёнными являются этапы проекты: ТЗ, технический проект, рабочий проект и т.д. Виткам спирали соответствуют версии и поколения ПО. Спиральное проектирование исключает возврат к ранним фазам разработки из-за неудачности поздних этапов, что является «бичом» традиционной водопадной схемы (водопадная – потому что вода не может двигаться вверх).

По словам У. Ройса, замечательным качеством ПО является его гибкость: запрограммировать можно практически, всё что угодно. Неприятным качеством ПО также является гибкость, приводящая к тому, что легко сделать то, что делать было не нужно. Лишь около 10% разработок оказывались успешными. Ройс предложил ряд основных принципов управления проектами разработки ПО:

1. Упреждающая разработка архитектуры разрабатываемого ПО (архитектура – состав и связи основных блоков-функций)

2. Нарастание степени понимания устройства и функций ПО в итерация жизненного цикла

3. Принципиальная важность разработки интерфейсов между блоками и со средой (вопрос интерфейса удобно решать с позиции МК-декомпозиции)

4. Специальная программная среда для поддержки изменений, вносимых в предмет разработки

5. Вместо бумажных использовать электронные документы

6. Широкое применение средств визуализации, моделирования, анимации, особенно для взаимодействия с заказчиком.

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

(кол-во метрик от времени)