Как проектировать и управлять сложностью ПО?

Я бы выделил два основополагающих подхода к решению этой (основной) проблемы разработки ПО:
- Основанный на представлениях о том, "что такое хорошо и что такое плохо": наборы всяческих принципов, правил (иногда довольно ясных, но чаще очень нечетких), паттернов и антипаттернов, представлений о хорошей архитектуре, о плохой архитектуре, а хорошем дизайне, о признаках (запахах) плохого дизайна и т.д.
- Прагматичный: реализуй как можно проще необходимый минимум, обеспечивая возможность при необходимости (а она будет всегда) быстро изменять (улучшать) свой код. На мой взгляд наиболее удачная попытка формализовать и обобщить данный подход — это Test-Driven Development в самом общем виде (речь о синтезе "классического" TDD и Mockist-ского — aka Behavior-Driven Development — подходов). Мой личный выбор — именно TDD с небольшими вкраплениями наиболее ясных принципов из предыдущего пункта.

На все эти вопросы есть как минимум один ответ - экстремальное программирование.
Ищите в поисковиках, материала очень много.

p.s. по-поводу UML диаграмм. Помогут, но только как подсказка для решения какой-либо конкретной задачи.
Не нужно воспринимать диаграмму как некую строгую документацию, которую нужно сначала разработать, а затем закодировать.
UML диаграмма - это скорее черновик, который поможет определить ключевые аспекты решения конкретной задачи (допустим выявить основные классы их методы для того или иного модуля). В процессе раздумий над задачей диаграмма будет меняться, в процессе написания кода, вероятно, тоже. После реализации модуля диаграмму можно сохранить как некую документацию вашего модуля, либо просто стереть с доски\выбросить.
В связи с этим, разумеется, не нужно пытаться спроектировать конечную архитектуру программы и набор всех классов на бумаге - это лишнее. Вместо этого нужно выявить конкретную небольшу задачу, при необходимости порисовать решение на бумаге, написать тесты, затем, возможно, отрефактирить.
И так по-очереди с каждой задачей. При грамотной организации кода и соблюдении принципов SOLID вы увидите, что внесения изменения в один модуль не затрагивают другие, поэтому его изменения будут достаточно безболезненными, а пройденные тесты подтвердят, что вы не испортили остальной код.
Обо всём этом рассказывает экстремальное программирование и другие методики гибкой разработки.