Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Хорошо. Итак, на том, что инженеры должны ответить на вопрос, сколько это будет примерно стоить, мы согласны.
PD>Тогда вопрос, к которому я и вел : каким образом инженеры будут оценивать эту стоимость ?
Традиционно — суммированием произведений количества на цену. В чём вопрос-то?

PD>И зря ты не ответил на мой вопрос. Повторяю его, и надеюсь все же ответ получить
PD>Что, если заказчик поставит в проекте требование решить мимоходом задачу NP-полную ?
Получит неприемлемые оценки для быстродействия и закроет проект
PD>Но только инженер сможет сказать, при каких условиях ее все же можно решать полным перебором, а при каких задача неразрешима при текущем уровне железа.
Опять смешение мух и котлет. Работа инженера — дать оценки стоимости, как асимптотические, так и в терминах конкретного времени.
А "можно или нельзя" — это вопрос бизнеса. NP-полнота — это ж не бабайка, которой детишек пугают. Это совершенно конкретная вещь, когда в асимптотике времени исполнения есть экспонента.
Ну, да, можно иногда ограничиться низкими степенями и всё ещё уложиться в нормативы — например, если мы возьмёмся факторизовывать маленькие числа, то несмотря на NP-полноту получим приемлемое время работы.
Но приемлемость определяется не инженерами, а обратно бизнесом. Хороший инженер, конечно же, помогает бизнесу с этим определением. Потому что бизнес не всегда имеет экспертизу в UX, а инженеру, если он берётся рассуждать о требованиях, такая экспертиза крайне полезна.

Вот, кстати, даже в формулировке задачи прозвучало "Приближенные решения не годятся, допустим". Откуда взялось это требование? Его что, инженер придумал?
Нет, это бизнес по какой-то своей, бизнесу ведомой причине потребовал точных решений. Скажем, если мы там подбираем простые делители для криптографии, то нас будет интересовать точное решение.
А для задачи коммивояжёра приближённое решение устроит примерно любой бизнес. То есть — приемлемость приближений зависит не от инженерных свойств (потому что математически все NP-полные задачи сводимы друг к другу), а от потребностей бизнеса. Почему эта простая мысль вызывает такие трудности в освоении?

PD>Да даже и не NP-полная — пусть там совсем не бог весть что по требованиям, но для Z1 надо потратить столько, что денег у заказчика не хватит.
Я вроде бы русским языком пишу. Вот цитата:

Если ни один из вариантов по Z0, Z1, T0, и Y не укладывается в неравенство — значит, проект не имеет экономического смысла, и мы его закрываем.

Какой из пунктов непонятен? Вы же пишете ровно то же самое, только другими словами. "Денег у заказчика не хватит" — ну вот это и означает, что предел стоимости проекта определяет не инженер, а заказчик.
Откуда инженер знает, хватит или нет у заказчика денег?

PD>Цитирую
>>Но пока пишем в блокнотик просто Y.
PD>Y — прямо зависит от Z, только с учетом времени на окупаемость, так как X — текущие расходы, это константа, уже данная.
Y зависит от Z косвенно. Потому что можно за очень большой Z сделать систему со вполне себе стрёмным Y — в том числе, и выше, чем X.
А иногда с невеликим Z можно получить систему с хорошим Y.
Бывает, что уменьшение Y на считанные проценты требует кратного роста Z.
Но чаще всего у нас получается ряд вариантов с примерно одинаковым Z, которые дают существенно разные Y (что опровергает гипотезу о существовании зависимости Y от Z), и парочка экстремальных вариантов — "для бедных", с низким Z и высоким Y, и "наилучший" — с приемлемым Z и хорошим Y.

PD>Да не в принциапх бизнес-планирования дело. Бизнес может, конечно, на основе этих принципов определить желаемую цену проекта. А вот насколько это реальная цена с точки зрения разработчиков ?
Ну так это пусть разработчики скажут. Ещё раз поясню простую вещь, которая от вашего понимания почему-то ускользает: бизнес выставляет требования. Например — уложиться в стоимость Z.
Если эти требования нереалистичны — ну ок, пусть нереалистичны. Просто проект не будет стартован. Всё. Иногда эти требования нежёсткие — ну там, посчитали, Z в полтора раза выше, чем хотел заказчик. Тот консультируется с финдиром, оценивает риски и доп.расходы — и берёт кредит. Если получится нужный Y, то кредит можно будет отдать. Если нет, то такой тип деятельности называется "прожектом".
Но в топике-то речь не об убыточных проектах, а о том, почему программисты не понимают причин выбора более низких Z, когда можно же потратить гораздо больше. А ответ обычно прост — непонимание это формировалось в эпоху, когда Z0 >> Z1, поэтому потратить втрое больше времени на программирование для получения 10% выигрыша в производительности всё ещё окупалось.
А сейчас уже Z0 < Z1, а иногда и << Z1, поэтому лучше потратить $2000 на ещё одну машинку, а не $5000 на ещё один человеко-месяц с неизвестным заранее выхлопом.

PD>Кстати, зря ты так уверен, что, скажем, T — это константа планирования.
(вздох). Я же написал: изложена упрощённая модель, для детского сада. Когда её усвоите, можно будет обсуждать более сложные вещи — такие, как эластичность, NPV, а так же вероятностные модели и работу с неопределённостями.

PD>Бизнес хочет, чтобы это окупилось за T. Обсудили с инженерами, стоимость выходит в 2 раза больше, и за T не окупится. Но, возможно, окупится за 2T. Бизнес обдумывает ситуацию. Возможно, и согласится. Если T=1 год, как бизнес хотел бы, то, может, его и устроит 2 года.
Всё верно. А может — не устроит. Инженерам об этом узнать неоткуда. Именно бизнес определяет, устроит или не устроит.