> Нда, далеки же вы от практики, сказки пишете.

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

> 1 Кем делиться на модули?

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

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

> Для этого роль интегратора уже не нужна?

Смотря что понимать под интегратором. Если того кто агрегирует различные куски между собой и собирает из кусков большую сущность - разумеется такие на вес золота. Как правило это делает руководитель проекта (яркий пример - Торвальдс vs pull requests, но нечто подобное в конечном итоге делает практически любой PM). А если ты про интеграторов которые заворачивают гов^W софт в красивый фантик и отдают клиенту - так они вообще не разработчики софта как таковые. А именно интеграторы - те кто собирает готовые решения в виде в котором они для юзера являют собой какую-то ценность. В этом плане - интегратору по логике вещей удобнее всего оперировать кубиками-компонентами. Более того, открытость кубиков интегратору может быть даже удобна. С точки зрения кастомизации и прочая. Например редхат можно посчитать за эдакий интегратор, который собрал кучу разного софта в форму которая являет для бизнеса некую ценность. Но за ними могут быть еще какие-то поставщики, которые например "развернут редхаты вот в этой инсталляции за отдельную мзду" (если у клиента для этого компетенции недостаточно). Ну в общем обычная такая цепочка посредников.

> 2 Кто определяет цели, требования и ограничения проекта?

Универсального ответа на этот вопрос - нет. При нормальном положении вещей - так или иначе это делает рыночная ситуация. Но это в самом общем виде. А так каждый целится во что посчитает нужным. Кто-то угадывает, кто-то нет. Нормальная ситуация.

> Для этого компетности интегратора уже не нужно?

Когда как. Для тех кто далек от специфики и не имеет своего центра компетенции - может потребоваться раскормить стороннего посредника-интегратора, разумеется. А кто-то и сами с усами.

> 3 Кто формирует соглашения, фонды и осуществляет управление проектом?
> Пользователь будет организовывать интегратора-проектного управляющего в себе?

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