Сверху вниз или восходящее проектирование? [закрытый]
3 ответа
Грубо говоря, нисходящий метод происходит из разложения проблемного пространства на подзадачи, а восходящий происходит от организации частей пространства решений в более крупные куски.
Чтобы иметь возможность эффективно использовать нисходящую систему, вам нужно очень твердое понимание проблемы, то есть иметь твердые требования. Чтобы восходящий подход был эффективным, вам нужно решить «стандартную» задачу, части которой хорошо известны, но где точная сборка может потребовать некоторых экспериментов, прежде чем вы сделаете это правильно.
Вы должны прочитать блестящую статью Парнаса Рациональный процесс проектирования и как его подделать , чтобы узнать больше об этом. Ответ: используйте и то, и другое по мере необходимости. Когда вы закончите, сделайте все так (в ваших спецификациях, проектной документации и пользовательской документации), как если бы вы делали все сверху вниз.
Вам также следует обратить внимание на принцип "Нарезка пирога", принятый в сообществе agile. Этот принцип заставляет вас сосредоточиться на добавлении бизнес-ценности для пользователя с каждой итерацией вашего приложения. Вы пытаетесь разработать и реализовать вертикальный фрагмент вашего приложения и предоставить его, затем сосредоточиться на следующем фрагменте и т.д.
Вот ссылка, которая объясняет этот принцип более подробно http://blog.energizedwork.com/2005/05/slicing-cake.html
Я думаю, ваш вопрос заслуживает длинного и артикулированного ответа. Я предлагаю прочитать старую статью Мартина Фаулера (см. "мертв ли дизайн?"), в которой говорится об отношениях между предварительным проектированием и методами agile (http://martinfowler.com/articles/designDead.html)
Мой опыт заключается в том, чтобы всегда иметь синюю печать архитектуры модулей, взаимодействий между компонентами системы. Имея этот чертеж (который в некоторых проектах может быть высокоуровневым), я начинаю проектировать/разрабатывать модули/компоненты. Некоторые из них могут быть разработаны и снизу вверх.