Большой дизайн впереди

редактировать

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

Содержание

  • 1 Аргументы в пользу
  • 2 Аргументы против
  • 3 Альтернативы
  • 4 См. Также
  • 5 Ссылки

Аргументы в пользу

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

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

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

Однако несколько комментаторов утверждали, что то, что Джоэл назвал« Большой дизайн впереди », не похоже на BDUF, критикуемый сторонниками XP и другие методологии гибкой разработки программного обеспечения, потому что он сам утверждает, что его пример не был очевидно, полный дизайн программы и не завершен полностью заранее:

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

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

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

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

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

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

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

Альтернативным подходом является (RDUF), в котором `` достаточный '' дизайн является завершено заранее, чтобы обеспечить основу, на которой можно будет строить детали проекта по мере продвижения проекта.

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

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

Сторонники Scrum ссылаются на концепцию Emergent Design :

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

См. также

Ссылки

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