Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Введение
Подход к разработке программного обеспечения, при котором проектирование доводится до совершенства до начала реализации.
A software development approach where the design is perfected before implementation
Большой объем проектирования на старте (BDUF) — это подход к разработке программного обеспечения, при котором проектирование программы должно быть завершено и доведено до совершенства до начала её реализации. Он часто ассоциируется с каскадной моделью разработки программного обеспечения. Синонимами большого объема проектирования на старте (BDUF) являются большой объем моделирования на старте (BMUF) и большой объем определения требований на старте (BRUF). В гибкой разработке программного обеспечения они рассматриваются как антипаттерны.
Big design up front (BDUF) is a software development approach in which the program's design is to be completed and perfected before that program's implementation is started. It is often associated with the waterfall model of software development. Synonyms for big design up front (BDUF) are big modeling up front (BMUF) and big requirements up front (BRUF). These are viewed as anti patterns within agile software development.
Аргументы против
Критики (особенно те, кто практикует гибкую разработку программного обеспечения) утверждают, что BDUF плохо приспосабливается к меняющимся требованиям и что BDUF исходит из предположения, будто проектировщики способны предвидеть проблемные области без масштабного прототипирования и хотя бы некоторых инвестиций в реализацию. Для значительных проектов требования пользователей нуждаются в уточнении по мере получения первых результатов, а потребности бизнеса развиваются быстрее, чем завершаются крупные проекты, что делает Большой Дизайн устаревшим к моменту завершения системы. Они также утверждают, что необходимо находить баланс между временем, затраченным на планирование, и стоимостью исправления дефекта. Это иногда называют параличом анализа. Если затраты на планирование превышают стоимость исправления, то время, потраченное на планирование, расходуется впустую. Непрерывная поставка, автоматические обновления и связанные с ними концепции стремятся существенно снизить стоимость дефектов в рабочей среде, чтобы их исправление во время работы системы обходилось дешевле, чем планирование в начале. В реальности, исправления во время работы системы значительно дороже, чем исправления на этапе проектирования, поэтому крайне важно использовать гибкие методологии, такие как частые демонстрации и обратная связь от пользователей в процессе разработки, для устранения проблем в цикле разработки. Совершенствование программного обеспечения на основе отзывов пользователей, как правило, обходится дешевле, чем попытки предвидеть и задокументировать каждый аспект системы с помощью BDUF. Кроме того, в большинстве проектов наблюдается существенный недостаток полных письменных (или даже чётко сформулированных) требований. Поэтому в BDUF делается множество предположений, которые впоследствии оказываются неверными, но на их основе ведётся проектирование и, возможно, даже написание кода.
Critics (notably those who practice agile software development) argue that BDUF is poorly adaptable to changing requirements and that BDUF assumes that designers are able to foresee problem areas without extensive prototyping and at least some investment into implementation. For substantial projects, the requirements from users need refinement in light of initial deliverables, and the needs of the business evolve at a pace faster than large projects are completed in making the Big Design outdated by the time the system is completed. They also assert that there is an overhead to be balanced between the time spent planning and the time that fixing a defect would actually cost. This is sometimes termed analysis paralysis. If the cost of planning is greater than the cost of fixing then time spent planning is wasted. Continuous deployment, automatic updates, and related ideas seek to substantially reduce the cost of defects in production so that they become cheaper to fix at run time than to plan out at the beginning. In reality, run time fixes are vastly more costly than design fixes, so it is critical to use Agile methods such as frequent demonstrations and user feedback during development to fix issues during the development cycle. Improving software with the benefit of user feedback is generally less expensive than trying to anticipate and document every aspect of a system with BDUF. Also, in most projects there is a significant lack of comprehensive written (or even well known) requirements. So in BDUF a lot of assumptions are made that later prove to be false but are designed and possibly already coded.