Ну, посмотрим в стандарт:
- формулированием требований существования элементов описания архитектуры
- Обеспечивает шаблон точки зрения и каталог точек зрения, включая: требования, функционал, развертывание, и т.д.
- Проектирование архитектуры системы должно быть оценено на соответствие критериям прослеживаемости и согласованности с требованиями к системе
- Его первичная цель состоит в декомпозировании объектов программных средств системы в компоненты и последующем распределении требований по этим компонентам.
- Точка зрения декомпозиции и распределения структурирует следующие интересы: 1. определение системных требований... 3. распределение требований по объектам.
- и т.д.
ГОСТ Р 57100-2016 Системная и программная инженерия. Описание архитектуры (по сути - перевод IS0/IEC/IEEE 42010:2011)
https://allgosts.ru/35/080/gost_r_57100-2016

Т.е., если разработчик половину рабочего времени тратит на выяснение требований, то это тоже проблема архитектуры.

Ээ, тут вообще про другой уровень архитектуры и требований пишется. И про совсем другие процессы, в этих стандартах, насколько я помню, предполагается наличие системных аналитиков, например.

И, кстати, в цитате ничего е сказано про сбор и анализ требований, а я именно про это.

Ну и, чтобы быть более точным, то 90%/10% я имел ввиду при написании кода, т.е. когда разработчик в редакторе. В редакторах с журналированием несложно собрать статистику ради спортивного интереса. Но я сильно сомневаюсь, что у вас на проекте разработчик будет вводить символы более 10% времени написания кода, со скоростью машинистки.

Хм, вряд ли у меня программист больше половины времени в IDE. Разве что фронтендер при вёрстке.

А если программист в IDE проводит 25процентов рабочего времени, то разделение внутри уже не важно.

Вопрос-то не в этом. Даже если он 50% времени в день не кодит - это просто 0.5 фокус-фактор. Во-первых, это не имеет отношения к скорости разработки, а во-вторых, 0.5, хорошо, пусть будет 0.25 - это всего лишь линейный коэффициент. А утрата контроля за сложностью имеет тенденцию приобретать форму экспоненты.

Я оспаривал другой тезис: 'Разработчик 90% времени читает код и получает представление о том, как устроена система, и это в том случае, если программа обладает хорошим внутренним качеством...
Иными словами, 90% времени осуществляется достижение коллективного понимания того, как устроена система.'
Эти тезисы ложны, значит  и выводы из них - тоже не существенны.

А если серьезнее, то velocity разработки является скорее вредной (в лучшем случае бесполезной) метрикой. Так как произвольна и не связана естественным способом с параметрами успеха компании. Таким образом не стоит обсуждение архитектуры связывать с velocity вообще.

Следуя Вашей логике, нужно еще учесть, что 8 часов в сутки разработчик спит, и исходя из этого, выводы о том, что системная архитектура непосредственно влияет на velocity, является ложной.

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

> Таким образом не стоит обсуждение архитектуры связывать с velocity вообще.

Это ваше личное мнение, имеете на него право. Вопрос лишь в том, какие будут интересы у ваших стэйкхолдеров. Про сбор метрик речь не шла.

Хм, так в процессе разработки собственно кодирование всегда занимает минимум времени. И сбор требований, кстати, часть процесса разработки.
И сводить процесс разработки только к кодированию - довольно странно.

А стейкхолдеров обычно интересуют совсем иные метрики, нежели velocity.

А вот выстраивание процесса разработки - да, вполне связано с системной архитектурой и относится к задачам архитектора (в том числе). А оптимизация кодирования при этом очень низко в списке приоритетов...

В процессе разработки кода или программного обеспечения?

Чтоб не было недопонимания, отвечу картинкой, о чем я веду речь.

> А если серьезнее, то velocity разработки является скорее вредной (в лучшем случае бесполезной) метрикой. Так как произвольна и не связана естественным способом с параметрами успеха компании. Таким образом не стоит обсуждение архитектуры связывать с velocity вообще.

Ваше мнение мне понятно.
А теперь, я хотел бы уйти от софистики и восстановить контекст разговора. Он заключался в средующем:

"В BDUF это не критично. А в итеративных разработках - критично."

Послушаем мнение, альтернативное вашему:

"At the core of understanding this argument is the software change curve. The change curve says that as the project runs, it becomes exponentially more expensive to make changes. The change curve is usually expressed in terms of phases "a change made in analysis for $1 would cost thousands to fix in production". This is ironic as most projects still work in an ad-hoc process that doesn't have an analysis phase, but the exponentiation is still there. The exponential change curve means that evolutionary design cannot possibly work. It also conveys why planned design must be done carefully because any mistakes in planned design face the same exponentiation.

The fundamental assumption underlying XP is that it is possible to flatten the change curve enough to make evolutionary design work. This flattening is both enabled by XP and exploited by XP. This is part of the coupling of the XP practices: specifically you can't do those parts of XP that exploit the flattened curve without doing those things that enable the flattening. This is a common source of the controversy over XP. Many people criticize the exploitation without understanding the enabling. Often the criticisms stem from critics' own experience where they didn't do the enabling practices that allow the exploiting practices to work. As a result they got burned and when they see XP they remember the fire."
- "Is Design Dead?" by M.Fowler
https://martinfowler.com/articles/designDead.html

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

Еще раз подчеркну самое главное: "The exponential change curve means that evolutionary design cannot possibly work."

Речь шла не о метриках, а о velocity в контексте стоимости изменения кода (о чем я говорил в т.ч. прямым текстом). И, если вы не видите в этом пользу для бизнеса, то отцы-основатели массовой итеративной разработки утверждают, что, без этого условия, "evolutionary design cannot possibly work".

Имеет ли "evolutionary design" (по сути - возможность итеративной разработки) значение для бизнеса? На эту тему можно долго дискутировать, но вывод будет однозначный - имеет, особенно в условиях скоротечно меняющейся рыночной обстановки. Проекты, утратившие гибкость и неспособные адаптироваться к новым рыночным вызовам, просто выбывают из конкурентной гонки (по крайней мере, я знаю уже несколько таких).

Выменивать — да. Бартер. Хотя явно проблемы с процессами, но это в другом ключе решать.

А "под ногами сервер" — ГОСТЫ хоть и древние, а правила игры в этом ключе определяют. Так что контекст не нужен, давно определено и дано заключение. Не мной кстати.

Хорошее сравнение но не согласен. Я в курсе уровня зп. Не всегда арх выгоднее. Не всегда он знает больше. Скорее это человнк в шапке с логотипом бизнеса. В условиях 7 лет падающего рынка может быть выгоднее на шапке написать какуюто технологию.

Какая вредная картинка.

Разработка требований(как и определение проблемы) - самое маленькое облачко, кодирование и отладка - самый большой.
Архитектура системы почему-то отдельно от разработки требований, уточнения дизайна, планирования и кодирования.

Подскажите, кто автор?

да я про эту статью и говорил. и про фаулера ) забыл даже чья статья.