n недостаточное управление требованиями, увлечение производством кода в ущерб дизайну ПО;

n ошибки в оценках, недостаток мониторинга процессов, разобщенность программистов;

n низкая продуктивность, отсутствие оценочных факторов, низкая надежность (ошибки);

n слишком сильная привязка к оборудованию, невозможность повторного использования кода;

n высокая стоимость разработки».

Звучит знакомо, не правда ли? Уже предпринимались попытки решения этих проблем путем смены парадигмы программирования. В истории можно выделить несколько моделей: стиль IBM (совершенствование классической схемы; 1960-70-е годы), японский стиль («фабрики ПО», стабильные команды программистов, отлаженные процедуры, максимальное повторное использование кода; 1970-80-е) и стиль, предлагаемый SEI[SEI - Software Engineering Institute] (главным образом состоит в предварительном ранжировании требований к разработке и контроле соответствия этим требованиям на каждом этапе, с 80-х; в настоящее время предлагается уже пятая версия документа).

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

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