Без заголовка

Все эти соображения как раз рассматриваются при рекомендации практики пересмотров выделения ресурсов, и на каждое такое соображение приводится свой собственный ответ. Например, ответ "в реале это не..." сводится к тому, что в реале пересмотра выделения ресурсов "по норме" не происходит, а происходят какие-то другие действия. Например, один наш клиент с удивлением обнаружил, что очень похожие на пересмотр выделения ресурсов мероприятия (обратите внимание, какие я использую родовые слова для "пересмотра" -- "практика", "мероприятия", "дела". Это не случайно!) выполняются неформально, в виде кулуарных совещаний, а не совещаний формальных "под протокол". И этих "тайных вечерь" не штуки три-четыре за время разработки, а ровно две -- в начале и в конце при постоянных жалобах на то, что никакие другие "авральные" совещания по факту не влияют на ход проекта, хотя идут непрерывно. Конечно, в реале не выполняется эта практика потому как мало кто этим выполнением озабочен, выгоды этого выполнения не понимаются. Пересмотр выделения ресурсов не стоит путать с работой внутри стадии, где непрерывно происходит подготовка этого пересмотра -- предложение и оценка альтернатив (trade-off analysis, мы предлагаем переводить как "прохождение развилок", это образно и уже более менее закрепилось в речи -- http://yandex.ru/yandsearch?text=прохождение+%2F%2B1+развилок). Как я понял, весь вопрос, в каких точках происходит пересмотр выделения ресурсов и смена базиса (rebaselining) -- ISO 15288 предлагает считать, что это определяется формой жиненного цикла, и как раз такие решения отделяют одну стадию ЖЦ от другой. Политическое мероприятие -- а как же! Это ведь владельцы ресурсов участвуют, их решения обычно определяются отнюдь не технической целесообразностью, а межвременнЫми предпочтениями. Из-за разности этих межвременнЫх предпочтений заинтересованных сторон (stakeholders) могут возникать нешуточные споры. Насчет интеграции -- конечно, на графиках "выгоды" наверняка будет горб. Как я понимаю, авторы методов управления жизненным циклом системной инженерии (в отличие от авторов методов управления жизненным циклом софта) не настаивают на непрерывной интеграции, но предлагают иметь эту интеграцию как минимум несколько раз в ходе разработки, причем интеграцию эту делать на разных уровнях готовности описаний: начальных проанализированных на совместимость требований, архитектуры, рабочего проекта и т.д. Не непрерывно, но и не только в момент окончательной сборки "в железе". Никакой самоцели, токмо проверка целостности в момент выделения ресурсов -- чтобы ресурсы выделялись на пиджачок, а не на набор несовместимых друг с другом пуговиц, рукавов и полочек (знаменитое "к пуговицам претензий нет, но пиджачок не сидит!"). Так что предложения стандартов -- вводить праткику пересмотра выделения ресурсов. И в обоснование они приводят многочисленные успешные проекты, где такая практика выполнялась (хотя, конечно, доказать успешность этих проектов именно от проведения этой практики невозможно. Но рассуждения мне кажутся убедительными и полностью соответствуют моему опыту и опыту моих клиентов: там, где удавалось к этому идеалу приблизиться, успеха было больше, чем неудач). Насчет проектов, заглохающих на стадиях прототипа: вот-вот. Один из предписанных результатов пересмотра выделения ресурсов -- заткнуть неудачный проект на как можно более ранней стадии.