iscrafm
а кто НИР оплачивает?
Заказчик.

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

Все смешано в одну кучу.
Результатом ТЗ должен быть опытный образец ПО (программного изделия, системы), а не прототип.
Он проходит стадию опытной эксплуатации (ОЭ) , в ходе которой выявляются не только программисткие ошибки, но алгортмические и иные. Результатом ОЭ является решение о доработке и устранении выявленных замечаний и, возможно, о дальнейшем развитии системы (следующий этап).
До опытной эксплуатации система, в зависимости от сложности, может пройти этапы аванпроекта, эскизного проекта, технического проекта, макета (прототипа) и только потом опытного образца.
Заказчика интересует опытный образц и за него он платит деньги, а не за макеты (прототипы).
Отрабатывать макеты (прототипы) вы можете и на чужих программных средствах, в том числе и предназначенных специально для моделирования.

iscrafm...У меня больше клиентов, у которых за этот год БП 10 раз поменяются, ...Поэтому, если принято решение, к примеру, об изменении структуры бизнеса, то никто не будет ждать, пока под новую структуру составят ТЗ на разработку, проведут НИР и т.п.
Просто другой стиль работы, возможно вам и непонятный. Не осуждаемо.

Да, описанный вами стиль работы ("водопадный", "предсерийная" модель и т. п.) мы не используем.
Если заранее известно (и в ТЗ это специально оговорено), что система будет подвергаться различным перестройкам, то она и проектируется с учетом этого требования.
Все параметры, алгоритмы и т. п. выносятся из кода программ в специальные конфигурационные файлы.
Сборка системы выполняется под разными конфигурационными макросами.
Система проектируется таким образом, чтобы вновь вводимая (добавляемая) функциональность
легко встраивалась в существующую систему с помощью простой операции Upgrade.

1 К вопросу “Кто в России пишет по ТЗ”?
Ответ на этот философский вопрос однозначен:
“Не только в России, но и во всем мире пишут по ТЗ”.
Был такой философ – Гегель – который открыл фундаментальный закон:
“Любой материальный объект (стол, автомобиль, книга, программа и т. п.) не создаются сами по себе. Их появлению всегда в мозгу человека предшествует план (схема, идея) реализации (создания) этого материального объекта.
Ни один объект не может быть создан без предварительного обдумывния его создателем”.
В этом философском смысле все системы (программы) всегда создаются по ТЗ, т. е. план создания системы всегда есть у кого-то в голове.
Оформляется ли этот план в виде нормативного или иного документа, согласовывается он или утверждается – все это вторичные технические вопросы.
Чтобы получить правильный ответ, нужно корректно формулировать вопрос:
“Оформляет ли кто в России план (идею) создания системы в виде бумажного документа”?

Небольшое отступление. Распространяя свой фундаментальный закон на весь материальный мир, Гегель пришел к ественному выводу: “Окружающий нас материальный мир (вода, горы, леса – вся планета Земля) тоже были созданы в результате реализации некой идеи. Он обозначил ее как АБСОЛЮТНАЯ ИДЕЯ. Но он никогда не говорил, что это был БОГ – это ему приписали советские ученые.

2 К вопросу, какой метод проектирпования (каскадный (по этапам) или итерационный) следует использовать.
В российских условиях выбор метода проектирования в большинстве случаев определяется не техническими критериями, а организационно-правовыми.
Если ПО разрабатывет коммерческая фирма на свои деньги (типа создает новую ОС, СУБД, прикладной пакет и т. п.) для последующего тиражирования и продаж, она сама формулирует функционнальные спецификации, ориентируясь на некоего абстрактного пользователя, сама формирует сроки и длительность работ (т. е. является одновременно и Заказчиком и Исполнителем). В этом случае, если в процессе разработки вдруг возникло озарение и фирма может выделить пару-тройку миллиончиков на переделку ПО, то итеративный процесс очень даже подходит.
Совсем иная картина при госбюджетном финансировании и при большом количестве участников разработки (соисполнителей, субподрядчиков). В этом случае четко должны быть прописаны планы и функционал для каждого соисполнителя разработки, сетевой план-график (кто, когда, что должен успеть – чтобы одни не ждали других ) и т. п.
Фокус с итерацинным проектированием здесь не пройдет.
На ваше предложение типа “у нас родилась новая замечательная идея как улучшить систему - дайте пару-тройку миллиончиков и откорректиируте сроки” вас в лучшем случае пошлют на 3 последние буквы из слова “заштрихуй”. Деньги в бюджете веделены на соглассованую сумму и статьи расходов на озарение там нет.
Несмотрая на ваше восхищение и преклонение итерационым стилем проектирования вы будете использовать каскадный. Или за вас это будет делать другой Исполнитель.
Поэтому правы те, кто ратует за итерацинный подход и правы те, кто применяет каскадный. Просто каждый судит по своей колокольне.
Раз уж пошел философский разговор, то вот философская притча.
К философу пришел мужик и говорит;
- Я два года назад дал соседу деньги взаймы. Но он мне долг не возвратил и не собирается это делать. Мне самому сейчас очень нужны деньги. Если я пойду и заберу у него корову, я буду прав?
- Разумеется, ты будешь прав.
Приходит другой мужик.
- Я у соседа взял в долг деньги, а возвратить пока не могу. Он хочет забрать у меня корову, единственную кормилицу нашнй семьи. Если он заберет её, то мы все умрем с голода. Поэтому я не отдам ему корову. Я буду прав?
- Разумеется, ты будешь прав.
Этот разговор услышала соседка.
- Ну как же так? У тебя и тот прав, и другой. Так не может быть! Разве я не права?
И ты права,

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