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