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