Большой дизайн спереди - Big Design Up Front

Большой дизайн спереди (BDUF) это разработка программного обеспечения подход, при котором дизайн программы должен быть завершен и усовершенствован до того, как эта программа начнется. Часто это связано с модель водопада разработки программного обеспечения.

Аргументы за

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

Джоэл Спольски, популярный онлайн-комментатор по разработке программного обеспечения, решительно высказался в пользу Big Design Up Front:[1]

«Много раз заблаговременное обдумывание вещей впоследствии избавляло нас от серьезных головных болей при разработке. ... [при внесении конкретного изменения в спецификацию] ... Внесение этого изменения в спецификацию заняло час или два. Если бы мы внесли это изменение в кода, это добавило бы недель к расписанию. Я не могу сказать вам, насколько сильно я верю в Big Design Up Front, который сторонники экстремального программирования считают анафемой. Я постоянно экономил время и делал лучшие продукты, используя BDUF и я Я горжусь тем, что использую его, независимо от того, что утверждают фанатики XP. Они просто ошибаются в этом вопросе, и я не могу быть яснее этого ».

Однако несколько комментаторов[2][3][4] утверждали, что то, что Джоэл назвал большим дизайном, не похоже на BDUF, критикуемое сторонниками XP и другие методологии гибкой разработки программного обеспечения, потому что он сам говорит, что его пример не был ни узнаваемо полным дизайном программы, ни полностью завершенным заранее:[5]

«Эта спецификация - просто отправная точка для разработки Aardvark 1.0, а не окончательный проект. Когда мы начнем создавать продукт, мы обнаружим много вещей, которые не будут работать точно так, как планировалось. Мы будем изобретать новые функций, мы изменим вещи, мы уточним формулировки и т. д. Мы постараемся поддерживать спецификацию в актуальном состоянии по мере изменения ситуации. Ни в коем случае не следует считать эту спецификацию какой-то священной, -каменный закон ".

Аргументы против

Критики (особенно те, кто практикует гибкая разработка программного обеспечения ) утверждают, что BDUF плохо адаптируется к изменяющимся требованиям и что BDUF предполагает, что дизайнеры могут предвидеть проблемные области без обширного прототипирования и по крайней мере некоторых инвестиций в реализацию. Для крупных проектов требования пользователей нуждаются в уточнении с учетом исходных результатов, а потребности бизнеса развиваются быстрее, чем завершаются крупные проекты, в результате чего Большой Дизайн устаревает к моменту завершения системы.

Они также утверждают, что существует накладные расходы чтобы сбалансировать время, затраченное на планирование, и время, которое фактически будет стоить исправление дефекта. Иногда это называют паралич анализа.

Если стоимость планирования больше, чем стоимость ремонта тогда время, потраченное на планирование, тратится зря.

Непрерывное развертывание, автоматические обновления, и связанные с ним идеи направлены на существенное снижение стоимости дефектов в производстве, чтобы их стало дешевле исправлять во время выполнения, чем планировать вначале. На самом деле исправления во время выполнения намного дороже, чем исправления проекта, поэтому очень важно использовать Agile-методы, такие как частые демонстрации и отзывы пользователей во время разработки, чтобы исправить проблемы в течение цикла разработки. Улучшение программного обеспечения с помощью обратной связи с пользователями обычно обходится дешевле, чем попытки предвидеть и задокументировать каждый аспект системы с помощью BDUF.

Кроме того, в большинстве проектов отсутствуют подробные письменные (или даже хорошо известные) требования. Таким образом, в BDUF делается много предположений, которые позже оказываются ложными, но они разработаны и, возможно, уже закодированы.[нужна цитата ]

Альтернативы

Альтернативный подход - Черновой дизайн впереди[6][7][8] (RDUF), в котором «достаточный» дизайн завершается заранее, чтобы обеспечить основу, на которой можно строить детали проекта по мере продвижения проекта.

Похожий подход Джошуа Кериевски назвал «Достаточный дизайн»:[9]

«Я говорю, что нам нужно высокое качество дизайна для вещей, которые важны для наших продуктов, и меньшее качество дизайна для вещей, которые не критичны».

Защитники Scrum относятся к концепции Эмерджентный дизайн:[10]

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

Смотрите также

Рекомендации

  1. ^ Джоэл Спольски (2005-08-17). "Проект" Муравьед ". Джоэл о программном обеспечении. В архиве из оригинала 12 апреля 2006 г.. Получено 2006-04-26.
  2. ^ «20-страничная спецификация для трехмесячного проекта - отличная вещь! Но это не BDUF, это SDUF» Рич Роджерс[1] В архиве 2006-02-09 в Wayback Machine
  3. ^ «К сожалению, глядя на его спецификацию, кажется, что она мало связана с типом BDUF, против которого критикуют XP (экстремальное программирование) и другие гибкие программисты». Курт Сэмпсон[2] В архиве 2011-05-18 на Wayback Machine
  4. ^ «Итак, из всего, чем может быть эта спецификация, большой предварительный проектный документ не входит в их число». Кевлин Хенни[3]
  5. ^ Джоэл Спольски (2005-08-17). «Функциональная спецификация проекта Aardvark» (PDF). Джоэл о программном обеспечении. Архивировано из оригинал (PDF) на 2012-05-09. Получено 2012-07-19.
  6. ^ Таубер, Йоханнес. «... программирование, технические детали, маневренность ...» Получено 19 июля 2012.
  7. ^ "Как вы проектируете сложные системы с помощью TDD?". Начните с примерной дизайнерской идеи
  8. ^ Седли, Лиз. «Грубый предварительный дизайн».
  9. ^ Кериевский, Джошуа. «Достаточный дизайн». Промышленный блог. Получено 19 июля 2012.
  10. ^ Кон, Майк. «Гибкий дизайн: намеренное, но возникающее». Блог о программном обеспечении Mountain Goat. Получено 19 июля 2012.