Big design up front ( BDUF ) — это подход к разработке программного обеспечения , при котором дизайн программы должен быть завершен и усовершенствован до начала ее реализации. Его часто ассоциируют с каскадной моделью разработки программного обеспечения.
Синонимы big design up front (BDUF) — big modeling up front (BMUF) и big requirements up front (BRUF). Они рассматриваются как анти-шаблоны в рамках гибкой разработки программного обеспечения . [1]
Сторонники каскадной модели утверждают, что время, потраченное на проектирование, является стоящей инвестицией, с надеждой, что меньше времени и усилий будет потрачено на исправление ошибки на ранних этапах жизненного цикла программного продукта , чем когда та же самая ошибка найдена и должна быть исправлена позже. То есть, гораздо проще исправить ошибку требований на этапе требований, чем исправить ту же самую ошибку на этапе реализации, поскольку исправление ошибки требований на этапе реализации требует отказа по крайней мере от части работы по реализации и проектированию, которая уже была выполнена.
Джоэл Спольски , популярный интернет-комментатор по вопросам разработки программного обеспечения, решительно выступает за большую разработку дизайна на начальном этапе: [2]
«Много раз, обдумывание всего заранее избавляло нас от серьезных проблем с разработкой в дальнейшем. ... [при внесении определенного изменения в спецификацию] ... Внесение этого изменения в спецификацию заняло час или два. Если бы мы внесли это изменение в код, это добавило бы недели к графику. Я не могу вам передать, насколько сильно я верю в Big Design Up Front, который сторонники экстремального программирования считают проклятием. Я постоянно экономил время и создавал лучшие продукты, используя BDUF, и я горжусь тем, что использую его, независимо от того, что утверждают фанатики XP. Они просто неправы в этом вопросе, и я не могу выразиться яснее».
Однако несколько комментаторов [3] [4] [5] утверждают, что то, что Джоэл назвал большим проектированием на начальном этапе, не похоже на BDUF, критикуемую сторонниками XP и других гибких методологий разработки программного обеспечения, поскольку он сам утверждает, что его пример не был ни узнаваемо полным проектированием программы, ни полностью завершенным на начальном этапе: [6]
«Эта спецификация — просто отправная точка для разработки Aardvark 1.0, а не окончательный проект. Когда мы начнем создавать продукт, мы обнаружим много вещей, которые не будут работать точно так, как планировалось. Мы придумаем новые функции, изменим что-то, уточним формулировки и т. д. Мы постараемся поддерживать спецификацию в актуальном состоянии по мере изменений. Ни в коем случае не следует считать эту спецификацию неким святым, непреложным законом».
Критики (особенно те, кто практикует гибкую разработку ПО ) утверждают, что BDUF плохо адаптируется к изменяющимся требованиям и что BDUF предполагает, что проектировщики способны предвидеть проблемные области без обширного прототипирования и по крайней мере некоторых инвестиций в реализацию. Для существенных проектов требования пользователей нуждаются в уточнении в свете первоначальных результатов, а потребности бизнеса развиваются быстрее, чем завершаются крупные проекты, что делает Большой Проект устаревшим к моменту завершения системы.
Они также утверждают, что существуют накладные расходы, которые необходимо сбалансировать между временем, потраченным на планирование, и временем, которое фактически будет стоить исправление дефекта. Иногда это называют параличом анализа .
Если стоимость планирования превышает стоимость устранения неполадок , то время, потраченное на планирование, оказывается потраченным впустую.
Непрерывное развертывание , автоматические обновления и связанные с ними идеи направлены на существенное снижение стоимости дефектов в производстве, чтобы их было дешевле исправлять во время выполнения, чем планировать в начале. В действительности исправления во время выполнения обходятся намного дороже, чем исправления дизайна, поэтому критически важно использовать Agile-методы, такие как частые демонстрации и обратная связь с пользователем во время разработки, чтобы исправлять проблемы во время цикла разработки. Улучшение программного обеспечения с использованием обратной связи с пользователем, как правило, менее затратно, чем попытка предвидеть и документировать каждый аспект системы с помощью BDUF.
Кроме того, в большинстве проектов наблюдается существенный недостаток всеобъемлющих письменных (или хотя бы общеизвестных) требований. Поэтому в BDUF делается много предположений, которые впоследствии оказываются ложными, но которые разработаны и, возможно, уже закодированы. [ необходима цитата ]
Альтернативным подходом является предварительное черновое проектирование [7] [8] [9] (RDUF), при котором «достаточное» проектирование выполняется заранее, чтобы обеспечить основу, на которой можно надстраивать детали проекта по мере его реализации.
Похожий подход был назван Джошуа Кериевски достаточным проектированием : [10]
«Я говорю, что нам нужно высокое качество дизайна для вещей, которые имеют решающее значение для наших продуктов, и более низкое качество дизайна для вещей, которые не имеют решающего значения».
Сторонники Scrum ссылаются на концепцию эмерджентного проектирования : [11]
«Отличие проекта Scrum не в том, что намеренный дизайн отбрасывается, а в том, что он выполняется (как и все остальное в проекте Scrum) постепенно».
Начните с грубой идеи дизайна