Есть большая программа, с исходниками. Она содержит как самописный код, так и множество опенсорсных и прочих модулей, некоторые из которых с исходниками, другие -- нет. Отдокументирована программа средне и неравномерно, то есть, в некоторых местах комментарии более менее, в других -- односложные джавадоки.

Вопрос: каким способом и какими средствами лучше проанализировать, как это всё работает?

Если необходимо детально разобраться в приложении, то необходимо восстанавливать(создавать) архитектуру, воспользовавшись каким-нибудь UML редактором. Строить use-case модель, модель данных и т.д.

На чём написана? На яве?

Приложение какое - GUI ? WEB ? Просто для каждого варианта надо смотреть разные структуры, конфиги и прочая.

Для построения юмл модели можно воспользоватся тулзой myeclipse . В ней есть автоматизированые возможности конвертации ява кода в юмл и обратно.

Reverse Engeneering также есть в NetBeans UML плагине

По-моему UML диаграмма толком ничего не скажет о логике работы - все равно надо смотреть код. 
Проще всего найти контроллер, который реагирует на действия пользователя и смотреть реализацию команд.

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

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

Да вообщем-то вопрос насущный: получили проект, до этого кем-то левой пяткой писанный - надо разбираться. А как?
Я с таким столкнулся впервые на своём текущем проекте. Есть немалый движок сайта, коробочного типа, написанный на C#, xslt, html, javascript, php - причём ничего из этого раньше не знал. Как разбираться? Попробовал смотреть исходник - глухо.
Считаю что лучшим выходом является начать реализацию текущих задач. Начинаешь что-то добавлять, втыкаешься откуда ноги растут, запоминаешь и так по-немногу, по-тихоньку разгребаешь завалы  
ИМХО

Этот весь процесс нигде не фиксируется, человек увольняется, и повторяется все сначала 



В итоге,  следующая контора, которой он достанется, будет говорить о нем также. И где-то он загнется.
ИМХО 

Потому что программа должна документироваться и комментироваться изначально!

И что даст вам диаграмма классов ? Особенно если этих классов несколько тысяч. Также никто не мешает просто смотреть код и видеть кто является родоначальником.

Вообщем-то UML-диаграмма позволит кое-что увидеть, но логику работы - это вряд ли. Хотя в Together помниться была попытка реализовать диаграммы взаимодействия. Но их чтение, на мой взгляд, гораздо более тяжелое занятие, чем чтение кода.
Кроме того - здорово, когда вы начинаете сами создавать диаграммы. Вы можете их группировать по темам. А при обратном проектировании Вы получите одну огромную простыню с кучей классов. И все это на одном листе. И что будете делать ? Ну выделите неколько деревьев. И что дальше ?

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

Основным документов является набор UseCase, которые reverse engineering не дает.

Ну узнаете вы что есть какая-то иерархия классов и что дальше ? Вы все равно не знаете зачем она. 


Я конечно не претендую, но как я подхожу к изучению больших проектов.
1. Узнаю общее назначение системы, если есть хоть какое-то описание.
2. Запускаю, чтобы можно было исследовать его как пользователю. Собираю список функциональных возможностей. Попутно можно узнать, как все собирается, какие логи и куда пишуться. Запустить систему - большое дело. Теперь можно легко найти точку входа и раскручивать.
3. Нахожу контроллеры (т.е. места, куда приходит запрос от пользователя) и иду по логике выполнения запроса. В подавляющем большинстве приложение строится очень просто - команда от пользователя обрабатывается по какой-то цепочке и выдается ответ. Во время анализа цепочки можно выявить некоторые зависимости между классами и таблицами в базе. 
Вот эту цепочку я и накладываю на каждый пункт из списка функциональностей из п. 2.

Естьконечн и иные варианты, но их обычно гораздо меньше.

И уже зная основную архитектуру реализации каждого UseCase можно спокойно их исправлять и добавлять новые.

По идее все.

Во какую штуку нашел - разговор с Никлаусом Виртом (который Паскаль написал) - http://alenacpp.blogspot.com/2005/09/blog-post_21.html

"Как вы относитесь к UML?
Я не поклонник UML. Эти графики годятся только для выражения небольших идей."

Я попробовал сперва UML. Во-первых, StarUML, во-вторых генератор в NetBeans и JBuilder. Особого смысла я не обнаружил. Программа попросту загоняет всех членов в квадратик.  Во-первых, не факт, что это более наглядно, во-вторых, мне все члены и не нужны, только основные.

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

Пока думаю так.